Comments 41
"с тем же успехом ФБР может взять iPhone террориста и скачать с него всё, а затем взломать за гораздо меньшее время, чем требуется для борьбы с Apple в судах."
Джон Маккафи, об этом давно уже сказал, и даже объяснил как он вытащит данные с iphone, хоть они и говорят, что честно-честно будут использовать его только для одного конретного iphone
Очевидно, что ФБР нужен глобальный бэкдор для доступа к любому iphone. И при этом глобальный бэкдор, попав к black hat хакерам (а любой бэкдор в 100% случаях попадает в их руки) просто уничтожит репутацию apple
Либо Apple нужно показать какие они неприклонные в вопросах безоапасности их пользователей.
ФБР не нужен инструмент, нужна легализация этого процесса… плюс потребовать сделать это за бесплатно дешевле, чем тратить средства на те же зарплаты хакерам :)
Маккафи наговорил абсолютно эпических глупостей. Вот реально, из серии "как публично сесть в лужу и выставить себя полным идиотом".
http://arstechnica.com/security/2016/03/john-mcafee-better-prepare-to-eat-a-shoe-because-he-doesnt-know-how-iphones-work/
http://arstechnica.com/security/2016/03/john-mcafee-better-prepare-to-eat-a-shoe-because-he-doesnt-know-how-iphones-work/
Данные можно и не копировать…
По мотивам Взлом пароля на Mac с Arduino и OpenCV
Ничего не мешает сделать копию памяти, сделать ПЛИС, которая будет служить буфером, передающим команды записи
на другой чип (например), подключить плис к любому ПК (сойдет и малинка), который будет включать/выключать/сбрасывать, подключенного к кнопке питания и вебкамере.
Теоретически можно и без ПЛИС, если IOS не будет падать при замыкании контакта WP на памяти.
Не удивлюсь если в каталоге "Гаджетов от АНБ" есть готовое устройство.
По мотивам Взлом пароля на Mac с Arduino и OpenCV
Ничего не мешает сделать копию памяти, сделать ПЛИС, которая будет служить буфером, передающим команды записи
на другой чип (например), подключить плис к любому ПК (сойдет и малинка), который будет включать/выключать/сбрасывать, подключенного к кнопке питания и вебкамере.
Теоретически можно и без ПЛИС, если IOS не будет падать при замыкании контакта WP на памяти.
Не удивлюсь если в каталоге "Гаджетов от АНБ" есть готовое устройство.
Да как бы… боян?
Новости о подборе пароля — уже год. Почти ровно год. Мысль проста — выключить питание ДО того, как система запишет что попытка неудачная.
Уже может и не работать.
Но Ваш вариант с обманом записи мне нравится больше.
Новости о подборе пароля — уже год. Почти ровно год. Мысль проста — выключить питание ДО того, как система запишет что попытка неудачная.
Уже может и не работать.
Но Ваш вариант с обманом записи мне нравится больше.
Да, это как раз пример программной ошибки, но тот баян ( CVE-2014-4451 ) был исправлен в 8.1.1, а тут установлена iOS 9: http://web.archive.org/web/20141228085715/http://support.apple.com/en-us/HT6590 "In some circumstances, the failed passcode attempt limit was not enforced. This issue was addressed through additional enforcement of this limit."
Это будет работать, если счетчик попыток лежит на флешке, а не в EEPROM прямо в SOC. Тогда ой.
А не, данные хранят таки на флешке, но если я правильно понял, в самом SOC есть счетчик записи, что бы защититься от такой аттаки:
Additionally, data that is saved to the file system by the Secure Enclave is encrypted
with a key entangled with the UID and an anti-replay counter
(https://www.apple.com/business/docs/iOS_Security_Guide.pdf)
Additionally, data that is saved to the file system by the Secure Enclave is encrypted
with a key entangled with the UID and an anti-replay counter
(https://www.apple.com/business/docs/iOS_Security_Guide.pdf)
Скорее всего в данных SoC (Apple A6, Apple Ax) нет EEPROM (зато они есть в других чипах).
https://www.chipworks.com/about-chipworks/overview/blog/inside-apple-a7-iphone-5s-updated "Since there’s no NVM module that I know of in any 28-nm process (other than one-time programmable memory)"
UID key вероятно записан в OTP eFuse или antifuse — память без возможности перезаписи в SoC. Счетчик, реализованный в OTP, невозможно сбросить, и при такой реализации у каждого iPhone/iPad было бы глобальное ограничение попыток ввода passcode, после которых аппарат становился бы кирпичом.
https://www.chipworks.com/about-chipworks/overview/blog/inside-apple-a7-iphone-5s-updated "Since there’s no NVM module that I know of in any 28-nm process (other than one-time programmable memory)"
UID key вероятно записан в OTP eFuse или antifuse — память без возможности перезаписи в SoC. Счетчик, реализованный в OTP, невозможно сбросить, и при такой реализации у каждого iPhone/iPad было бы глобальное ограничение попыток ввода passcode, после которых аппарат становился бы кирпичом.
Может быть конкретно эту модель iPhone и можно взломать, скачав память. Но в недавней статье говорилось, что в новых моделях на карте памяти лежат зашифрованные данные, а ключ хранится на Secure Enclave и его оттуда просто так не вытащить.
Смысл не в скачивании памяти — а в возможности сброса состояния телефона к заранее сохраненному. Таким образом можно обойти ограничение по числу попыток ввода пароля — а значит, этот самый пароль можно попросту перебрать.
Память криптопроцессора находится внутри SOC и до неё просто так не добраться.
Даже если отключить счётчик неверных попыток с текущим алгоритмом полный перебор шестизначного кода займёт более 5 лет.
Даже если отключить счётчик неверных попыток с текущим алгоритмом полный перебор шестизначного кода займёт более 5 лет.
Перебор можно ускорить распараллеливанием. С SOC все сложнее...
Распараллелить можно расшифровку дампа чипов, но там сроки ещё хуже из-за AES.
Насколько я понимаю, ФБР хотят сервисный интерфейс, через который можно долбить криптопроцессор заранее сгенерёнными хэшами от паскода без всяких ограничений.
Насколько я понимаю, ФБР хотят сервисный интерфейс, через который можно долбить криптопроцессор заранее сгенерёнными хэшами от паскода без всяких ограничений.
На практике перебор ключа для AES-256 невозможен. Совсем. Из-за энергетических ограничений. http://everything2.com/title/Thermodynamics+limits+on+cryptanalysis "...brute force attacks against 256-bit keys will be infeasible until computers are built from something other than matter and occupy something other than space". — ---Bruce Schneier"
(Гипотетически, квантовый переборщик смог бы уменьшить сложность перебора в два раза — если считать в битах — т.е. с 2^256 до 2^128 квантовых вычислений AES, т.е. более 10^38 операций. Это что-то порядка триллионов лет для машин, совершающих экзаоперацию в секунду, и миллионов лет для йоттаопераций в секунду.)
(Гипотетически, квантовый переборщик смог бы уменьшить сложность перебора в два раза — если считать в битах — т.е. с 2^256 до 2^128 квантовых вычислений AES, т.е. более 10^38 операций. Это что-то порядка триллионов лет для машин, совершающих экзаоперацию в секунду, и миллионов лет для йоттаопераций в секунду.)
Если ломать хэш, то да, а если перебирать, допустим, числовой пароль, то сроки вполне реальные для машинного перебора
Чтобы ломать числовой пароль ("passcode") нужен уникальный 256-битный ключ, которого нет.
Этот ключ — UID — https://www.theiphonewiki.com/wiki/UID_key, зашит непосредственно в SoC (процессор Apple A6), заявлен как несохраняемый и недоступный для вычитывания через софт, SE и JTAG (https://www.theiphonewiki.com/wiki/GID_Key "The UID is unique to each device and is not recorded by Apple or any of its suppliers.… Integrating these keys into the silicon helps prevent them from being tampered with or bypassed, or accessed outside the AES engine. The UID and GID are also not available via JTAG or other debugging interfaces.").
Перебирать этот UID key возможности нет. Вытаскивать его микроскопом — очень сложно и очень дорого (десятки тысяч USD только чтобы приблизительно понять где на чипе хранится этот ключ); нет гарантий успеха вычитывания; данный процесс связан с разрушением данного аппарата и риском безвозвратного уничтожения ключа и, следовательно, улики (следствие/суд может быть против).
Если одиночные eFuse (электромиграция в поликремнии) по 90 нм еще читались на Transmission Electron Micrograph — http://paris.utdallas.edu/ssiri08/Tonti_SSIRI_eFuse_V2.pdf, то для antifuse (пробой оксидного слоя в транзисторе) заявлена более высокая стойкость http://chipdesignmag.com/display.php?articleId=5045 "oxide breakdown occurs in a random location within the gate oxide and logic poly region and is extremely small. Thus, it is difficult to locate the oxide breakdown using chemical etching or mechanical polishing." Краткое введение в физические атаки на чипы прошлого века от Dr. Sergei Skorobogatov — http://www.cl.cam.ac.uk/~sps32/PartII_030214.pdf слайд 29 и далее, защита — 54: "glue logic design makes reverse engineering much harder; multiple metal layers block any direct access; small size of transistors makes attacks less feasible"
Кстати, есть общий комментарий Сергея о данном деле — http://www.usatoday.com/story/tech/news/2016/02/24/apple-iphone-hacks-encryption-san-bernardino-hardware-fbi/80812466/ "companies that specialize in reverse-engineering chips to check for patent infringement. These companies would likely know where, in general, to look on an iPhone 5C for the codes, said Sergei Skorobogatov… polished down, micrometer by micrometer layer, in a procedure called de-processing… At this level, it’s sometimes possible to actually see which transistors are burned on or off"
Ключ UID key используется как для шифрования всей ФС на NAND (дешифратор стоит прямо в DMA встроенного контроллера NAND; т.е. без него не получить никаких данных с дампа NAND), так и для получения из passcode (числового кода блокировки) ключа "passcode key", которым закрыто хранилище Keybag с ключами шифрования для пользовательских данных.
Вот иллюстрация из "iPhone Data Protection in Depth" Sogeti, 2011 http://www.slideshare.net/seguridadapple/iphone-data-protection-in-depth http://esec-lab.sogeti.com/static/publications/11-hitbamsterdam-iphonedataprotection.pdf (16/59)
Серым показаны операции, выполняющиеся на выделенных аппаратных блоках, и ключ UID, хранящийся в процессоре (SoC):
Без наличия UID key вне устройства (телефона) перебирать passcode не получится (нет возможности KDF passcode -> passcode key; нет AES decrypt, т.к. нет 0x835). Операция KDF настроена так, чтобы занимать около 80 мс на телефоне, для проверки каждого passcode нужно сделать KDF, decrypt, получить class key и попробовать воспользоваться им для расшифровки пользовательского файла (а сам зашифрованный на class key файл с фс можно получить лишь имея key0x89b, получаемый опять же из UID — http://www.darthnull.org/2014/10/06/ios-encryption "Key0x89b is used in encrypting the device’s flash disk… key0x89b is tied to the device (being derived from UID)").
В http://blog.cryptographyengineering.com/2014/10/why-cant-apple-decrypt-your-iphone.html пишут о недоступности UID для софта: "The UID appears to be connected to the AES circuitry by a dedicated path, so software can set it as a key, but never extract it. Moreover this appears to be the same for both the Secure Enclave (SE) and older pre-A7 chips." и предполагают, что для защиты от подобных требований в новых версиях SE/Apple_Ax возможно будет добавлена необходимость wipe при обновлении SE.
Этот ключ — UID — https://www.theiphonewiki.com/wiki/UID_key, зашит непосредственно в SoC (процессор Apple A6), заявлен как несохраняемый и недоступный для вычитывания через софт, SE и JTAG (https://www.theiphonewiki.com/wiki/GID_Key "The UID is unique to each device and is not recorded by Apple or any of its suppliers.… Integrating these keys into the silicon helps prevent them from being tampered with or bypassed, or accessed outside the AES engine. The UID and GID are also not available via JTAG or other debugging interfaces.").
Перебирать этот UID key возможности нет. Вытаскивать его микроскопом — очень сложно и очень дорого (десятки тысяч USD только чтобы приблизительно понять где на чипе хранится этот ключ); нет гарантий успеха вычитывания; данный процесс связан с разрушением данного аппарата и риском безвозвратного уничтожения ключа и, следовательно, улики (следствие/суд может быть против).
Если одиночные eFuse (электромиграция в поликремнии) по 90 нм еще читались на Transmission Electron Micrograph — http://paris.utdallas.edu/ssiri08/Tonti_SSIRI_eFuse_V2.pdf, то для antifuse (пробой оксидного слоя в транзисторе) заявлена более высокая стойкость http://chipdesignmag.com/display.php?articleId=5045 "oxide breakdown occurs in a random location within the gate oxide and logic poly region and is extremely small. Thus, it is difficult to locate the oxide breakdown using chemical etching or mechanical polishing." Краткое введение в физические атаки на чипы прошлого века от Dr. Sergei Skorobogatov — http://www.cl.cam.ac.uk/~sps32/PartII_030214.pdf слайд 29 и далее, защита — 54: "glue logic design makes reverse engineering much harder; multiple metal layers block any direct access; small size of transistors makes attacks less feasible"
Кстати, есть общий комментарий Сергея о данном деле — http://www.usatoday.com/story/tech/news/2016/02/24/apple-iphone-hacks-encryption-san-bernardino-hardware-fbi/80812466/ "companies that specialize in reverse-engineering chips to check for patent infringement. These companies would likely know where, in general, to look on an iPhone 5C for the codes, said Sergei Skorobogatov… polished down, micrometer by micrometer layer, in a procedure called de-processing… At this level, it’s sometimes possible to actually see which transistors are burned on or off"
Ключ UID key используется как для шифрования всей ФС на NAND (дешифратор стоит прямо в DMA встроенного контроллера NAND; т.е. без него не получить никаких данных с дампа NAND), так и для получения из passcode (числового кода блокировки) ключа "passcode key", которым закрыто хранилище Keybag с ключами шифрования для пользовательских данных.
Вот иллюстрация из "iPhone Data Protection in Depth" Sogeti, 2011 http://www.slideshare.net/seguridadapple/iphone-data-protection-in-depth http://esec-lab.sogeti.com/static/publications/11-hitbamsterdam-iphonedataprotection.pdf (16/59)
Серым показаны операции, выполняющиеся на выделенных аппаратных блоках, и ключ UID, хранящийся в процессоре (SoC):
Без наличия UID key вне устройства (телефона) перебирать passcode не получится (нет возможности KDF passcode -> passcode key; нет AES decrypt, т.к. нет 0x835). Операция KDF настроена так, чтобы занимать около 80 мс на телефоне, для проверки каждого passcode нужно сделать KDF, decrypt, получить class key и попробовать воспользоваться им для расшифровки пользовательского файла (а сам зашифрованный на class key файл с фс можно получить лишь имея key0x89b, получаемый опять же из UID — http://www.darthnull.org/2014/10/06/ios-encryption "Key0x89b is used in encrypting the device’s flash disk… key0x89b is tied to the device (being derived from UID)").
В http://blog.cryptographyengineering.com/2014/10/why-cant-apple-decrypt-your-iphone.html пишут о недоступности UID для софта: "The UID appears to be connected to the AES circuitry by a dedicated path, so software can set it as a key, but never extract it. Moreover this appears to be the same for both the Secure Enclave (SE) and older pre-A7 chips." и предполагают, что для защиты от подобных требований в новых версиях SE/Apple_Ax возможно будет добавлена необходимость wipe при обновлении SE.
И как его можно ускорить распараллеливанием?
В том гипотетическом случае, когда есть возможность полностью откатиться к сохраненному состоянию телефона — можно это самое состояние переписать на другой телефон.
Подбор пароля на двух телефонах одновременно будет в два раза быстрее чем на одном.
Подбор пароля на двух телефонах одновременно будет в два раза быстрее чем на одном.
Вроде как нельзя, там что-то связаное с криптопроцессором, т.е. есть привязка к конкретному железу.
В данном случае телефон Iphone 5C, без криптопроцессора, криптография там на программном уровне.
SE — Secure Enclave — это всего лишь вариация на тему ARM TrustZone — аппаратно изолированный режим ARM процессоров со своей ОС (у ARM это дополнительный режим ядер http://www.arm.com/products/processors/technologies/trustzone/: "within a CPU, software either resides in the secure world or the non-secure world with a switch between these two worlds accomplished by a secure monitor (application processors)"; у Apple неясно, является ли оно еще одним физическим ядром или просто режимом для существующих ядер).
В SE работает прошивка на базе микроядра L4, отдельная от основной iOS, со своими подписями и дополнительной защитой данных в памяти и на NAND. https://www.apple.com/business/docs/iOS_Security_Guide.pdf#page=7
Такое разделение iOS/SE не позволяет получить доступ к привилегированным операциям (получению промежуточных ключей, настройке ключей в AES шифраторе в DMA контроллера NAND) после jailbreak. Без SE запросы к аппаратному AES-блоку с доступом к UID key совершались из iOS и можно было программным образом запускать операции шифрования-дешифрования на UID key и получать их результаты (но не вычитывать сами ключи в процессор)
http://www.darthnull.org/2014/10/06/ios-encryption "… you extract key0x89b
(which may be possible on jailbroken devices — but if you’ve jailbroken the device, you already have access to the decrypted filesystem anyway)", при этом key0x89b — это
http://esec-lab.sogeti.com/static/publications/11-hitbamsterdam-iphonedataprotection.pdf "key0x89B = AES(UID, "183e99676bb03c546fa468f51c0cbd49")… iPhone crypto Embedded AES keys… IOAESAccelerator kernel extension • Requires kernel patch to use UID key from userland"
В http://blog.cryptographyengineering.com/2014/10/why-cant-apple-decrypt-your-iphone.html с ссылкой на comex (https://news.ycombinator.com/item?id=8410819) пишут о недоступности самих GID/UID для софта, они лишь выведены в отдельный аппаратный блок AES (вне зависимости от наличия SE, во всех Apple Ax, т.е. примерно с 2010 года):
В SE работает прошивка на базе микроядра L4, отдельная от основной iOS, со своими подписями и дополнительной защитой данных в памяти и на NAND. https://www.apple.com/business/docs/iOS_Security_Guide.pdf#page=7
The Secure Enclave is a coprocessor fabricated in the Apple A7 or later A-series processor. It utilizes its own secure boot and personalized software update separate from the application processor. It provides all cryptographic operations for Data Protection key management and maintains the integrity of Data Protection even if the kernel has been compromised.
The Secure Enclave uses encrypted memory and includes a hardware random number generator. Its microkernel is based on the L4 family, with modifications by Apple. Communication between the Secure Enclave and the application processor is isolated to an interrupt-driven mailbox and shared memory data buffers.
The Secure Enclave is responsible for processing fingerprint data from the Touch ID sensor
Такое разделение iOS/SE не позволяет получить доступ к привилегированным операциям (получению промежуточных ключей, настройке ключей в AES шифраторе в DMA контроллера NAND) после jailbreak. Без SE запросы к аппаратному AES-блоку с доступом к UID key совершались из iOS и можно было программным образом запускать операции шифрования-дешифрования на UID key и получать их результаты (но не вычитывать сами ключи в процессор)
http://www.darthnull.org/2014/10/06/ios-encryption "… you extract key0x89b
(which may be possible on jailbroken devices — but if you’ve jailbroken the device, you already have access to the decrypted filesystem anyway)", при этом key0x89b — это
http://esec-lab.sogeti.com/static/publications/11-hitbamsterdam-iphonedataprotection.pdf "key0x89B = AES(UID, "183e99676bb03c546fa468f51c0cbd49")… iPhone crypto Embedded AES keys… IOAESAccelerator kernel extension • Requires kernel patch to use UID key from userland"
В http://blog.cryptographyengineering.com/2014/10/why-cant-apple-decrypt-your-iphone.html с ссылкой на comex (https://news.ycombinator.com/item?id=8410819) пишут о недоступности самих GID/UID для софта, они лишь выведены в отдельный аппаратный блок AES (вне зависимости от наличия SE, во всех Apple Ax, т.е. примерно с 2010 года):
> The Secure Enclave is designed to prevent exfiltration of the UID key. On earlier Apple devices this key lived in the application processor itself, and could (allegedly) be extracted if the device was jailbroken and kernel patched.
Speaking as a jailbreaker, this is actually incorrect. At least as of previous revisions, the UID key lives in hardware — you can ask the hardware AES engine to encrypt or decrypt using the key, but not what it is. Thus far, neither any device's UID key or (what would be useful to jailbreakers) the shared GID key has been publicly extracted; what gets extracted are secondary keys derived from the UID and GID keys, but as the whitepaper says, the passcode lock key derivation is designed so that you actually have to run a decryption with the UID to try a given passcode. Although I haven't looked into the newer devices, most likely this remains true, since there would be no reason to decrease security by handing the keys to software (even running on a supposedly secure coprocessor).
отдельный аппаратный блок AES
начиная с iPhone 3GS — почти везде, где работает iOS 4 (2010):
https://www.trailofbits.com/resources/ios4_security_evaluation_paper.pdf Apple iOS 4 Security Evaluation, Trail of Bits LLC
Hardware Encryption
The iPhone 3GS and later devices include a hardware AES cryptographic accelerator. This crypto accelerator is used for realtime filesystem encryption and various other encryption tasks by iOS. In addition to providing high-performance data encryption and decryption capabilities, it also provides many security services through its use of hardware-protected AES keys.
The AES accelerator includes both a unique per-device key (referred to as the UID Key) and a globally shared key (referred to as the GID Key) that are not accessible to the CPU. They may only be used for encryption or decryption through the AES accelerator itself. The GID Key is primarily used to decrypt iOS firmware images provided by Apple. The UID Key is used to derive a number of device-specific AES keys that are used to encrypt the filesystem metadata, files, and Keychain items.
The iPhone 3GS and later devices use the embedded encryption accelerators to perform block-level encryption on both the System and Data partitions. This is primarily to support a quick remote wipe operation. On earlier versions of iOS, the remote wipe command would force the device to overwrite each block of the flash storage, which could take hours to complete. Now, the entire filesystem can be rendered unreadable by simply wiping a single encryption key (referred to here as the File System Key).
Уточнение: 5 лет для полного перебора пароля из шести букв и цифр из-за 80 мс на получение ключей из passcode. Тип пароля обычно виден сразу на экране блокировки.
Для 4 цифр на старых ОС (4-8), без ограничения в 10 попыток заявляли 10-40 минут — www.elcomsoft.com/eift.html "simple 4-digit passcodes in 10-40 minutes"; www.elcomsoft.com/ios_forensic_toolkit_faq.html#20 цифробуквенные пароли оценивались как редко используемые — "passcode may contain all printable characters, and may have any length. This situation is very rare simply because the user would have to enter the passcode every time when unlocking the device. The good news is that the type of a passcode is stored in the system"
The iteration count is calibrated so that one attempt takes approximately 80 milliseconds. This means it would take more than 5½ years to try all combinations of a six-character alphanumeric passcode with lowercase letters and numbers
Для 4 цифр на старых ОС (4-8), без ограничения в 10 попыток заявляли 10-40 минут — www.elcomsoft.com/eift.html "simple 4-digit passcodes in 10-40 minutes"; www.elcomsoft.com/ios_forensic_toolkit_faq.html#20 цифробуквенные пароли оценивались как редко используемые — "passcode may contain all printable characters, and may have any length. This situation is very rare simply because the user would have to enter the passcode every time when unlocking the device. The good news is that the type of a passcode is stored in the system"
Но перезапись дампа назад в телефон не моментальна (кто-то называл цифру в 4 минуты).
Это что же, получается, что это всего лишь рекламная компания от Тима Кукана? Вот это да, кто бы мог подумать?!!!
Мне уже давно кажется, что американцы извели всех своих хакеров и сотрудники фбр, может и закончили Стенфорд, но не в состоянии повторить операцию из китайских ларьков.
И как эти китайцы будут ломать 128-битный(?) AES, которым зашифровано "сырое" содержимое памяти?
Они сожмут всю свою узкоглазую волю в кулак и прочитают новость аж до четвертого абзаца.
256-битный… Никак.
https://www.apple.com/business/docs/iOS_Security_Guide.pdf#page=10
https://www.apple.com/business/docs/iOS_Security_Guide.pdf#page=10
Every iOS device has a dedicated AES 256 crypto engine built into the DMA path
between the flash storage and main system memory, making file encryption highly
efficient.
Исследователь в области информационной безопасности Джонатан Zdziarski, консультант правоохранительных органов, привёл в качестве одной из возможностейivansychev, у вас ссылка на источник потерялась. Верните, пожалуйста.
P.S. На вас это не похоже. Новые инструкции от начальства?
Спасибо за внимательность! Добавил ссылку с фразы "пишет Bloomberg".
Вся эта история дурно пахнет. Эппл пытается делать дураков из своих пользователей, разыгрывая перед ними сцену как она страдает за их приватность. Прекрасно понимая, что никакой приватности нет.
Почему нет? Даже если вы можете переписать дамп памяти из одного ЗУ в другое, это еще не говорит о том, что вы сможете его прочитать. Это просто свап. Вы меняете один чип на другой, при этом информация бит-в-бит на них идентичная. И зашифрованная. Чем она вам поможет? Если бы вы потрудились почитать статью аж до 4го абзаца, то поняли бы, что спецслужбам поможет дамп памяти только тем, что позволит перебирать пароль множество раз. Лично я считаю, что защита в iphone офигенски сильная.
А можно ли загрузить содержимое памяти в некий софтварный эмулятор и там просто вырубить проверку счётчика и задержку при переборе пароля?
Нет (https://www.blackhat.com/docs/sp-14/materials/arsenal/sp-14-Belenko-IOS-Forensics-Slides.pdf#page=13 — "Offline bruteforce not possible" #page=16 "Must be done on device; cannot bruteforce offline").
Тяжело выгрузить всю необходимую для "софтварной" эмуляции память, т.к. в iPhone программно-аппаратное решение по шифрованию, с аппаратным шифрователем и аппаратным хранилищем ключа.
В iPhone есть NAND флеш-память в виде отдельной микросхемы, её легко отпаять и вычитать на подходящем программаторе, а также есть PoP SoC (package-on-package, system on a chip: Apple A6 или иной Apple Ax) — сборка в одном корпусе из чипа SoC (процессор, GPU, контроллер DDR, контроллер NAND и еще 17-28 неопознанных цифровых блоков) и из чипа LPDDR2 RAM памяти (см разбор от iFixit — https://www.ifixit.com/Teardown/Apple+A4+Teardown/2204#s11273). Содержимое RAM вычитать сложно, вынуть "планки памяти" или вычитать по DMA вряд ли получится.
Самый важный для эмуляции элемент — уникальный 256 битный ключ шифрования UID key (https://www.theiphonewiki.com/wiki/UID_key; UID+ ??), зашитый непосредственно в кристалл SoC при изготовлении (вероятно по технологии eFuse/antiFuse), не выведенный на чтение в софт или в JTAG и заявленный как не сохраняемый у Apple. При помощи этого ключа зашифрована вся файловая система на NAND флеш-памяти, т.е. без него дамп флешки не прочитать. Также при помощи этого ключа производится получение из passcode (кода блокировки) ключей шифрования пользовательских файлов (необходимых следствию улик).
По словам comex, автора одного из jailbreak, https://news.ycombinator.com/item?id=8410819 — ключи UID и сходный GID еще не удавалось считать ни из одного чипа Apple Ax. Чтение eFuse/antiFuse микроскопом — долгая, дорогая, трудоемкая операция без гарантий результата (получения полного ключа), но с разрушением чипа и, следовательно, улик.
Если предположить, что UID смогли бы получить, то одна из задержке при переборе все равно останется: для получения passcode key из passcode требуется несколько сотен операций AES-шифрования на UID; в железе на это уходит 80 мс, в софте это тоже потребует какого-то времени, но при наличии UID можно будет распараллеливать. Также нужен дамп флеш-памяти для проверки корректности passcode key.
Из-за этого дела Apple может дополнительно усложнить защиту в следующих чипах, чтобы у них больше не было возможности подготовить прошивку, с фичами, требуемыми ФБР ("GovtOS" — см. https://cdn2.vox-cdn.com/uploads/chorus_asset/file/6106157/apple-motion-to-vacate.0.pdf стр 48-60, заявление Erik Neuenschwander — выключение wipe после 10 попыток, отключение программных минутных задержек, электронный ввод passcode). Например, добавить в SoC выжигаемые при обновлении Secure Enclave биты eFuse, и добавив необходимость wipe при подобном обновлении (заиспользовать эти биты в подписывании SE — в SE bootROM и процедурах расшифровки keybag). При обновлении пользователь будет вынужден делать полный backup либо в iTunes, либо в облаке Apple (рекомендуемый Apple вариант) и восстановление после обновления.
Тяжело выгрузить всю необходимую для "софтварной" эмуляции память, т.к. в iPhone программно-аппаратное решение по шифрованию, с аппаратным шифрователем и аппаратным хранилищем ключа.
В iPhone есть NAND флеш-память в виде отдельной микросхемы, её легко отпаять и вычитать на подходящем программаторе, а также есть PoP SoC (package-on-package, system on a chip: Apple A6 или иной Apple Ax) — сборка в одном корпусе из чипа SoC (процессор, GPU, контроллер DDR, контроллер NAND и еще 17-28 неопознанных цифровых блоков) и из чипа LPDDR2 RAM памяти (см разбор от iFixit — https://www.ifixit.com/Teardown/Apple+A4+Teardown/2204#s11273). Содержимое RAM вычитать сложно, вынуть "планки памяти" или вычитать по DMA вряд ли получится.
Самый важный для эмуляции элемент — уникальный 256 битный ключ шифрования UID key (https://www.theiphonewiki.com/wiki/UID_key; UID+ ??), зашитый непосредственно в кристалл SoC при изготовлении (вероятно по технологии eFuse/antiFuse), не выведенный на чтение в софт или в JTAG и заявленный как не сохраняемый у Apple. При помощи этого ключа зашифрована вся файловая система на NAND флеш-памяти, т.е. без него дамп флешки не прочитать. Также при помощи этого ключа производится получение из passcode (кода блокировки) ключей шифрования пользовательских файлов (необходимых следствию улик).
По словам comex, автора одного из jailbreak, https://news.ycombinator.com/item?id=8410819 — ключи UID и сходный GID еще не удавалось считать ни из одного чипа Apple Ax. Чтение eFuse/antiFuse микроскопом — долгая, дорогая, трудоемкая операция без гарантий результата (получения полного ключа), но с разрушением чипа и, следовательно, улик.
Если предположить, что UID смогли бы получить, то одна из задержке при переборе все равно останется: для получения passcode key из passcode требуется несколько сотен операций AES-шифрования на UID; в железе на это уходит 80 мс, в софте это тоже потребует какого-то времени, но при наличии UID можно будет распараллеливать. Также нужен дамп флеш-памяти для проверки корректности passcode key.
Из-за этого дела Apple может дополнительно усложнить защиту в следующих чипах, чтобы у них больше не было возможности подготовить прошивку, с фичами, требуемыми ФБР ("GovtOS" — см. https://cdn2.vox-cdn.com/uploads/chorus_asset/file/6106157/apple-motion-to-vacate.0.pdf стр 48-60, заявление Erik Neuenschwander — выключение wipe после 10 попыток, отключение программных минутных задержек, электронный ввод passcode). Например, добавить в SoC выжигаемые при обновлении Secure Enclave биты eFuse, и добавив необходимость wipe при подобном обновлении (заиспользовать эти биты в подписывании SE — в SE bootROM и процедурах расшифровки keybag). При обновлении пользователь будет вынужден делать полный backup либо в iTunes, либо в облаке Apple (рекомендуемый Apple вариант) и восстановление после обновления.
Sign up to leave a comment.
ФБР может без помощи Apple взламывать айфоны