Безопасность Apple Mobile Devices. Продолжение следует… 12 лет спустя

23 июня 2014 года я закончил статью про безопасность мобильных устройств Apple словами "Продолжение следует...", после чего, как это иногда бывает с действительно интересными техническими вопросами, слегка увлекся другими вещами.

Прошло двенадцать лет.

И, перечитав сейчас тот текст, я обнаружил забавную вещь: несмотря на некоторое количество неизбежных для 2014 года упрощений, главную архитектурную идею я тогда ухватил довольно точно.

Безопасность iPhone была построена не вокруг существования какого-то одного особенно секретного ключа или особенно хитрого алгоритма, а вокруг цепочки взаимно зависимых состояний, где каждый следующий уровень можно получить только после того, как предыдущий доказал свое право существовать.

Кащеева смерть действительно была на игле.

Просто с тех пор Apple засунула эту иглу еще в несколько яиц, уток, зайцев, аппаратных криптографических блоков и отдельный компьютер внутри компьютера.

Начнем, однако, ровно с того места, на котором мы остановились.

В 2014 году задача выглядела следующим образом: в процессоре существует аппаратный AES GID key, сам ключ наружу не отдается, зато код, работающий достаточно рано в процессе загрузки, способен попросить железо выполнить с его помощью криптографическую операцию, следовательно, если мы получим контроль над BootROM, LLB или iBoot, мы потенциально сможем использовать сам телефон как криптографический оракул.

Именно поэтому jailbreak тех лет так сильно напоминал восхождение по загрузочной цепочке снизу вверх.

BootROM доверяет следующему загрузчику, тот доверяет iBoot, iBoot доверяет kernel, kernel доверяет подписанным процессам, а наша задача состояла не столько в том, чтобы "сломать шифрование", сколько в том, чтобы в подходящем месте подменить ответ на вопрос "этому коду можно доверять?".

Современная Apple по-прежнему описывает загрузку iPhone практически теми же терминами: первым выполняется неизменяемый Boot ROM, содержащий корневой публичный ключ Apple, после чего каждый следующий компонент криптографически проверяет следующий, вплоть до iBoot и ядра системы.

То есть скелет архитектуры не поменялся.

Изменилось количество органов вокруг него.

Дыра, которую нельзя исправить

Самое красивое продолжение той старой истории случилось в 2019 году.

Если уязвимость находится в обычном приложении, Apple выпускает обновление.

Если она находится в kernel, Apple выпускает обновление.

Если она находится в iBoot, Apple выпускает обновление.

Но что делать, если ошибка находится в том самом первом неизменяемом коде, который был физически записан в кристалл при производстве процессора?

Ничего.

Можно только выпустить новый процессор.

В сентябре 2019 года была опубликована уязвимость, получившая название checkm8. Ошибка находилась в обработчике USB DFU режима BootROM и затрагивала несколько поколений Apple SoC, приблизительно от A5 до A11. Поскольку BootROM физически неизменяем, уже произведенные устройства нельзя было исправить обновлением iOS.

Получился почти идеальный ответ на мой вопрос из 2014 года.

Да, если получить исполнение кода на достаточно ранней стадии загрузки, можно заставить устройство делать вещи, которые Apple совершенно не собиралась вам разрешать.

Но здесь произошел важный архитектурный поворот.

В 2014 году такое поражение загрузочной цепочки казалось почти эквивалентным поражению устройства.

К 2019 году это уже было не так.

Потому что к этому моменту внутри iPhone фактически жил второй компьютер.

Компьютер внутри компьютера

Secure Enclave появился еще в iPhone 5s, то есть буквально за год до моей первой статьи, но тогда было не до конца очевидно, насколько фундаментальным окажется этот архитектурный ход.

Сегодня Secure Enclave представляет собой отдельную защищенную подсистему внутри SoC, со своим процессором, своей Boot ROM, собственным AES engine, генератором случайных чисел, защищенной памятью и собственной операционной системой sepOS.

Причем, что особенно красиво, Apple использует там кастомизированный микроядерный L4.

В результате компрометация основного Application Processor, даже на уровне kernel, уже не означает автоматическую компрометацию наиболее чувствительных секретов устройства. Apple прямо проектирует Secure Enclave исходя из предположения, что основное ядро может быть взломано.

Это очень важное изменение самой философии безопасности.

Раньше можно было представить устройство как замок:

нашел способ открыть замок, оказался внутри.

Теперь это скорее здание, внутри которого стоит банковское хранилище.

Вы можете разбить окно, попасть внутрь, выключить камеры, получить root, заменить половину операционной системы, но это еще совершенно не означает, что дверь хранилища открылась.

И вот здесь особенно интересно вернуться к тому самому AES GID key, с которого началась моя история.

Он никуда не исчез.

Современные Apple SoC по-прежнему имеют GID, общий для устройств одного семейства процессоров, и UID, уникальный для конкретного устройства. Но сами hardware keys никогда не выдаются программному обеспечению как значения. Программное обеспечение может попросить аппаратный AES engine выполнить операцию, однако ключ остается внутри аппаратного блока.

То есть идея "не хранить секрет так, чтобы его можно было прочитать, а дать железу возможность выполнять операцию с секретом" пережила двенадцать лет практически без изменений.

Но вокруг нее выросла куда более интересная система.

Главного ключа больше нет

В старом тексте я несколько раз употреблял выражение вроде "ключ, которым зашифрован диск".

Сегодня это уже слишком грубое упрощение.

Современная Data Protection в Apple представляет собой целую иерархию ключей.

Файл получает собственный ключ.

Этот ключ заворачивается class key.

Class key связан с политикой доступа к данным.

Дальше в конструкции участвует аппаратный UID устройства, а для некоторых классов еще и пользовательский passcode.

Метаданные файловой системы также шифруются отдельно.

Причем обработка wrapped file keys происходит через Secure Enclave, а сами долговременные ключи не обязаны когда-либо появляться в памяти Application Processor в открытом виде.

В результате вопрос:

"Какой ключ надо украсть, чтобы расшифровать iPhone?"

оказывается поставлен неправильно.

Нужно не украсть ключ.

Нужно воспроизвести допустимое состояние машины, при котором несколько независимых компонентов согласны последовательно раскрыть друг другу необходимые секреты.

И вот это уже гораздо интереснее.

Потому что безопасность превращается из хранения тайны в управление допустимыми переходами состояний.

Пароль как часть вычисления

Еще один важный момент, который в 2014 году не был столь очевиден: пользовательский пароль не просто открывает UI телефона.

Он участвует в криптографической иерархии.

Secure Enclave использует аппаратно уникальный UID, пользовательский passcode и другие аппаратно защищенные компоненты для получения ключевого материала, необходимого для разблокировки определенных классов данных. Современная реализация дополнительно использует anti-replay механизмы и secure storage, чтобы нельзя было просто сохранить состояние, перебрать миллионы паролей и потом вернуть устройство назад.

Это означает, что украденный NAND уже почти бесполезен.

Вы не можете выпаять память, подключить ее к другому процессору и продолжить атаку там, потому что часть криптографической структуры привязана к UID конкретного SoC.

Apple прямо приводит этот пример: перенос внутреннего накопителя в другое устройство не дает доступа к данным, поскольку соответствующая иерархия ключей связана с уникальным аппаратным UID.

В 2014 году я сравнивал это с TPM.

Сегодня аналогия одновременно стала точнее и хуже.

Точнее, потому что корень доверия действительно окончательно переехал в железо.

Хуже, потому что Secure Enclave давно перестал быть просто аналогом TPM.

Это полноценный изолированный вычислительный домен.

Даже root теперь не root

Вот здесь, пожалуй, произошла самая интересная эволюция jailbreak.

Когда-то получить root означало практически выиграть игру.

Сегодня root означает примерно "поздравляю, вы прошли первый уровень".

Современные Apple SoC защищают уже не только код на диске, но и структуру исполняемой памяти.

Например, Pointer Authentication Codes, PAC, криптографически подписывают чувствительные указатели, включая адреса возврата функций и function pointers, чтобы обычная memory corruption уязвимость не превращалась автоматически в произвольный control flow.

К этому добавляются аппаратные механизмы защиты областей памяти ядра, отдельные политики исполнения кода, sandbox, entitlements, code signing и ряд других границ, каждая из которых заставляет современную эксплуатационную цепочку состоять не из одной "дырки", а зачастую из нескольких совершенно разных уязвимостей, последовательно повышающих уровень контроля.

Более того, Apple теперь старается связывать ключи не только с конкретным железом, но и с состоянием загруженного программного обеспечения.

Sealed Key Protection позволяет включать измерения software state в процесс защиты ключевого материала, то есть принцип постепенно становится совсем кащеевским:

секрет доступен не потому, что вы знаете адрес, где он лежит, а потому, что железо считает текущую конфигурацию устройства допустимой.

И вот здесь я бы сегодня сформулировал все иначе

В 2014 году мне казалось, что центральная задача защиты выглядит примерно так:

"Как не дать атакующему получить секретный ключ?"

В 2026 году мне кажется, что настоящий вопрос звучит иначе:

"Как сделать так, чтобы секрет вообще никогда не существовал в форме, которую достаточно украсть?"

В этом смысле архитектура современных Apple устройств является очень красивым примером общей эволюции computer security.

Секрет превращается в capability.

Capability превращается в допустимый transition.

А допустимый transition зависит от аппаратного состояния, подписанного software state, пользовательской аутентификации, истории предыдущих состояний и нескольких независимых вычислительных доменов.

Ключ уже не лежит в сундуке.

Ключ существует несколько микросекунд как результат правильно исполненного протокола между участниками, причем часть этих участников физически не позволяет прочитать собственные секреты.

А что же Find My iPhone?

И вот тут история замыкается особенно красиво, потому что именно с него начиналась первая статья.

Тогда меня заинтересовал довольно простой вопрос: если Activation Lock делает украденный телефон практически бесполезным, можно ли этот lock технически обойти?

За прошедшие годы Apple фактически превратила эту идею из отдельной функции iCloud в часть намного более широкой модели, в которой ценность украденного устройства определяется уже не только возможностью загрузить чужую систему.

Даже серьезный boot exploit сам по себе не дает вам автоматически пользовательские данные.

Kernel exploit не дает автоматически ключи Secure Enclave.

Физический доступ к NAND не дает автоматически расшифровку.

А обход одного слоя не превращает остальные слои в бессмысленные.

Это, возможно, и есть главный инженерный результат всех прошедших лет.

Apple не построила невзламываемый телефон.

Таких систем вообще не бывает.

Она построила систему, в которой цена компрометации все чаще определяется не стоимостью одной найденной уязвимости, а количеством независимых архитектурных предположений, которые атакующий должен сломать одновременно.

Именно поэтому checkm8 был одновременно катастрофической уязвимостью и прекрасной демонстрацией того, насколько далеко ушла архитектура.

BootROM скомпрометирован навсегда.

Корень доверия основного процессора фактически проиграл.

Но пользовательские данные от этого магическим образом не расшифровались.

Двенадцать лет назад я закончил статью намерением найти AES GID key и, возможно, сделать собственный jailbreak.

Теперь ответ наконец можно сформулировать.

Найти сам ключ было не нужно тогда.

И тем более бессмысленно искать его сейчас.

Самое интересное место во всей этой архитектуре находится не там, где Apple хранит секрет.

Оно находится там, где система решает, кому, когда и в каком состоянии разрешено воспользоваться результатом вычисления, зависящего от этого секрета.

И, пожалуй, именно это я тогда пытался нащупать, еще не зная подходящих слов.

Мы искали ключ.

А нужно было изучать машину состояний.

Продолжение следует.

На этот раз постараюсь уложиться быстрее, чем в двенадцать лет.