Безопасность iOS (часть II)

В прошлой статье шла речь о базовых механизмах безопасности операционной системы iOS. Базовые механизмы включают в себя цепочку доверенной загрузки, персонализацию системного ПО, подписание кода сообщений, выполнение приложений в песочнице и с правами непривилегированного пользователя, права доступа (entitlements), ASLR и ARM’s Execute Never. Но, допустим, что случилось страшное: нарушителю удалось каким-то образом обойти базовые механизмы безопасности, и конфиденциальная информация пользователя теперь находится под угрозой. Но и тогда нарушителю может помешать последний, практически нерушимый, оплот безопасности – механизмы шифрования и защиты данных.

Аппаратный уровень

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

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

Каждое устройство с iOS имеет встроенный чип, в котором реализован алгоритм AES-256. Расположение чипа на пути от флеш-памяти к оперативной памяти заметно снижает энергозатраты на шифрование/дешифрование. На аппаратном уровне также реализован алгоритм SHA-1.

При производстве в процессор зашиваются два 256-битных ключа AES: UID (уникальный идентификатор устройства) и GID (групповой идентификатор устройства). Никакое программно-аппаратное обеспечение не может напрямую прочитать ключи AES; можно только прочитать результаты шифрования/дешифрования на этих ключах. Ключ UID уникален для каждого устройства, и он неизвестен даже Apple. Не стоит путать UID и ECID; ECID – это тоже уникальный и тоже идентификатор, который имеет вид 00000XXXXXXXXXXX, где X – шестнадцатеричная цифра; а UID, как уже говорилось выше, 256-битный ключ. Ключ GID одинаков для всех процессоров одного семейства (например, у всех процессоров A5 GID одинаковый).

При загрузке ядра служба IOAESAccelerator вычисляет еще пять ключей на основе UID и GID:

Рисунок 1. Ключи, генерируемые на основе UID и GID

В дальнейшем нас будут интересовать только ключи 0x835, 0x89A и 0x89B.

На аппаратном уровне также реализован генератор псевдослучайной последовательности. Генератор получает энтропию на основе длительности прерываний во время загрузки, а также от внутренних датчиков.

Быстрое и безопасное удаление ключей настолько же важно, как и их генерация. Для решения подобной проблемы на устройствах под управлением iOS существует специальная область под названием Effaceable Storage. Область занимает 1 блок (~ 1Мб) во flash-памяти и содержит три ключа: зашифрованный ключ EMF, зашифрованный ключ DKey и ключ BAG1 (подробнее об этих ключах чуть ниже). Технология Effaceable Storage позволяет при необходимости быстро стереть все ключи, сделав всю информацию на устройстве пользователя недоступной.

Механизм защиты данных

Наряду с технологиями аппаратного уровня, для защиты данных пользователя во flash-памяти также используется механизм Data Protection. Механизм ориентирован на мобильные устройства и позволяет пользователю, например, отвечать на входящие звонки без расшифровки конфиденциальных данных, или в фоновом режиме скачивать информацию даже когда устройство заблокировано. Контроль доступа к каждому фалу осуществляется на основе класса защиты, то есть каждому файлу присваивается определенный класс защиты, в зависимости от того, когда может потребоваться доступ к этому файлу (например, только после разблокировки устройства, или даже если устройство заблокировано). У каждого класса защиты есть отдельный ключ, на котором шифруется ключ файла, принадлежащего конкретному классу защиты.
Рассмотрим теперь подробнее, какие действия происходят при создании файла, и как организована его защита. Все очень просто.

Чтобы расшифровать файл нужно проделать все в обратном порядке: сначала расшифровать ключ EMF, затем расшифровать метаданные необходимого файла и прочитать из них зашифрованный FileKey; расшифровать FileKey и, наконец, расшифровать весь файл.
Итак, на данный момент иерархия криптографических ключей iOS выглядит следующим образом:

Рисунок 2. Первоначальный вариант иерархии ключей

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

Пароль пользователя

На своем устройстве пользователь может установить пароль (Passcode). Всего возможно три вида паролей:

На основе UID устройства и пароля пользователя с помощью специальной функции (PBKDF2) вычисляется парольный ключ (Passkey):

Рисунок 3. Вычисление парольного ключа

Чтобы усложнить нарушителю атаку перебором, вычисление парольного ключа намеренно замедляется и в среднем занимает около 80 миллисекунд, причем после каждой неудачной попытке ввода пароля временная задержка до следующей попытки увеличивается. Кроме того, пользователь может включить опцию, благодаря которой после определенного числа неправильных попыток ввода пароля вся информация с устройства будет стерта. Заметим еще, что благодаря тому, что в вычислении парольного ключа участвует UID, парольный ключ для разных устройств с одинаковым паролем все равно будет различаться. Вообще, парольный ключ играет одну очень важную функцию, о которой будет рассказано чуть позже. Известно также, что, начиная с iOS 5, в процессе вычисления парольного ключа участвует еще один аппаратный ключ UID+, но, к сожалению, более подробной информации об этом ключе мне найти не удалось

Ключи классов защиты

Всего в iOS существует 11 классов защиты, причем 5 классов используются для защиты данных (ключи классов защиты данных), а 6 для защиты элементов связок ключей (ключи классов защиты элементов связки ключей). Сначала рассмотрим ключи классов защиты данных.

Таблица 1. Ключи классов защиты данных

Полная защита (NSFileProtectionComplete, Class A): Если для данных установлен такой класс защиты, то спустя некоторое время после блокировки устройства расшифрованный ключ класса полной защиты стирается из оперативной памяти, делая тем самым данные класса NSFilePotectionComplete недоступными до тех пор, пока пользователь снова не разблокирует устройство и не введет пароль.

Доступ для записи при блокировке (NSFileProtectionCompleteUnlessOpen, Class B): Для некоторых файлов требуется, чтобы информация в них могла записываться, даже когда устройство заблокировано. Подобное условие выполняется следующим образом:

 

Данные недоступны только до первой аутентификации пользователя (NSFileProtectionCompleteUntilFirstUserAuthentication, Class C): В отличие от класса полной защиты ключ класса защиты NSFileProtectionCompleteUntilFirstUserAuthentication не удаляется из памяти после блокировки устройства, следовательно пользователь будет иметь доступ к данным класса С, начиная с момента первой разблокировки устройства и ввода пароля вплоть до перезагрузки устройства.

Защита отсутствует (NSFileProtectionNone, Class D): Этот класс по умолчанию присваивается данным, если им не присваивается какой-либо другой класс. На самом деле ключ NSFileProtectionNone хранится в Effaceable Storage: это и есть тот самый ключ Dkey, зашифрованный ключом 0x835, т.е. Dkey! = AES_ENC(0x835, DKey). Таким образом, даже если файлу не присвоен какой-либо класс защиты, файл все равно шифруется.

Связка ключей

Многие приложения должны хранить собственные данные (например, пароли приложения, Wi-Fi пароли, почтовые аккаунты, сертификаты и.т.п.) в безопасности. Безопасность конфиденциальных данных приложений достигается за счет так называемой “связки ключей” (Keychain). По своей сути связка ключей – это база данных SQLite, хранящаяся в файловой системе устройства и имеющая класс защиты NoProtection. Доступ к базе осуществляется при помощи демона securityd, именно этот демон решает какое приложение или процесс к какому элементу связки ключей (записи в базе данных) может обратиться.

Хотя сама база и имеет класс защиты NoProtection, элементы связки ключей имеют собственные классы защиты, а соответственно и ключи классов защиты, в дальнейшем такие ключи будут называться ключи классов защиты элементов связки ключей. В Таблице 2 представлены все 6 возможных ключей классов защиты элементов связки ключей:

Таблица 2. Ключи классов защиты элементов связки ключей

Заметим, что половина ключей классов защиты связки ключей имеет постфикс “ThisDeviceOnly”. Дело в том, что в iOS 5 появилась возможность перемещать элементы связки ключей с одного устройства на другое. Элементы, которые имеют класс защиты с постфиксом “ThisDeviceOnly” дополнительно защищаются UID устройства, и поэтому на другом устройстве их просто не получится расшифровать.
Каждый элемент связки ключей имеет следующую структуру (начиная с iOS 5):

Рисунок 4. Структура элемента связки ключей

access group: группа доступа, т.е. приложения, процессы, которые могут получить доступ к элементу связки ключей;

Сумки с ключами

(Слева от абзаца 5_dollars.png) Все ключи классов защиты объединяются в еще одну сущность под названием “сумка с ключами” (Keybag). Всего существует 4 разновидности сумок с ключами: Системная сумка с ключами (System Keybag), Резервная сумка с ключами (Backup Keybag), Депонированная сумка с ключами (Escrow Keybag), Резервная сумка с ключами iCloud (iCloud Backup Keybag). Все сумки имеют одинаковую структуру, которая представлена на Рисунке 5:

Рисунок 5. Структура сумки с ключами

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

Системная сумка с ключами. Системная сумка хранится непосредственно на устройстве в файле /private/var/keybags/systembag.kb. Файл системной сумки зашифрован на ключе BAG1, который, как уже известно, находится в Effaceable Storage. Нужно отметить, что после каждой смены пароля меняется и ключ BAG1. После расшифровки файла мы получим системную сумку с ключами, но она будет находиться в заблокированном состоянии, то есть все ключи классов защиты в сумке по-прежнему будут зашифрованы. Каждый ключ зашифрован одним из трех способов: либо только на ключе UID, либо только на парольном ключе, либо одновременно на парольном ключи и на UID. За конкретный тип шифрования отвечает поле Wrapping type.

Рисунок 6. Разблокировка системной сумки с ключами

В шифровании ключей классов защиты элементов связки ключей “…ThisDeviceOnly” всегда участвует ключ UID, для того чтобы на другом устройстве эти ключи расшифровать бы не получилось.

Резервная сумка с ключами. Каждый раз, когда пользователь делает резервную копию устройства в iTunes, на компьютере пользователя создается резервная сумка с ключами. Ключи классов защиты в резервной сумке отличаются от ключей классов защиты в системной сумке, поэтому все файлы бэкапа перешифровываются на новых ключах. Файлы бэкапа шифруются, конечно же, алгоритмом AES 256 в режиме CBC на уникальном ключе и нулевом IV.

Всего возможно два вида бэкапов: обычный и зашифрованный. Различия между ними следующие:

Согласно такой схеме резервного копирования элементы связки ключей “…ThisDeviceOnly” перебросить с одного устройства на другое никак не получится, а перемещаемые элементы связки ключей можно, простите за тавтологию, переместить только в зашифрованном бэкапе.
Депонированная сумка с ключами. Депонированная сумка позволяет синхронизированному устройству (например, компьютеру, на котором установлен iTunes) разблокировать устройство с iOS, не требуя каждый раз пароля от пользователя. Когда устройство подключается к компьютеру, iTunes просит пользователя ввести пароль. После правильного ввода пароля создается депонированная сумка (ключи классов защиты в ней точно такие же, как и в системной сумке) и сохраняется на компьютере. Депонированная сумка зашифрована на 256-битном случайно сгенерированном ключе. Ключ, в свою очередь, хранится в файле на устройстве в папке /private/var/root/Library/Lockdown/escrow_records. Файл имеет класс защиты NSFileProtectionCompleteUntilFirstUserAuthentication.

Резервная сумка с ключами iCloud. Эта сумка во многом схожа с простой резервной сумкой, но в iCloud-сумке все ключи ассиметричные, благодаря чему резервное копирование в iCloud может производиться в фоновом режиме. Закрытые ключи классов защиты данных шифруются ключами облачного хранилища, а закрытые ключи классов защиты элементов связки ключей, как и в обычном бэкапе, зашифрованы на ключе 0x835.

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

Рисунок 7. Иерархия ключей

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

В заключение статьи опишем возможные атаки на механизм защиты данных

Атаки на механизм защиты данных

Допустим, нарушитель все-таки хочет извлечь конфиденциальную информацию из устройства пользователя. Нарушителю может потребоваться файл целиком (например, какой-нибудь сверхсекретный документ), или какие-либо атрибуты безопасности приложений (Wi-Fi пароль, сертификаты, закрытые ключи приложений и.т.п.). В первом случае необходимо знать ключ EMF, а также соответствующий ключ класса защиты данных. Ключ EMF зашифрован на ключе 0x89B, который, в свою очередь, вычислен на основе UID. Для шифрования ключей классов защиты данных используются ключи BAG1, UID и/или парольный ключ. Во втором случае элементы связки ключей зашифрованы на соответствующих ключах классов защиты элементов связки ключей, и для их (ключей классов защиты) расшифровки также необходимо знать ключи BAG1, UID и/или парольный ключ.

Следует сказать, что на данный момент известных способов извлечь аппаратные ключи UID и GID не существует. Но не все так плохо. Специально для программно-технической экспертизы устройств с iOS компания Sogeti Labs выпустила пакет утилит, позволяющих извлечь практически все ключи (кроме аппаратных) из устройства. Ключи можно прочитать, благодаря пропатчиванию службы ядра IOAESAccelerator. Именно эта служба при загрузке ядра вычисляет ключи 0x835, 0x89A и 0x89B (см. Рисунок 1), а зная их, можно получить ключи Dkey, EMF и BAG1 (BAG1 вообще хранится незашифрованным). Для пропатчивания на устройстве, безусловно, должен быть сделан jailbreak. Код утилит от Sogeti Labs открыт, и при желании их легко можно найти в Интернете.

Таким образом, обычно всё упирается в знание парольного ключа, т.е. пароля. Ниже описано несколько возможных способов извлечения конфиденциальной информации. Тривиальный случай, когда нарушитель завладел устройством без пароля, рассматривать не будем.
Случай 1: Нарушитель имеет физический доступ к устройству с паролем. В таком случае, если пароль состоит из 4 цифр, то можно за разумное время перебрать все возможные пароли, разблокировать устройство и получить полный доступ к информации пользователя.

Меры противодействия:

Случай 2: Эксплуатация Депонированной сумки с ключами. Как известно ключи классов защиты из депонированной сумки ничем не отличаются от ключей в системной сумке. Если нарушитель будет иметь доступ к устройству и компьютеру пользователя, то он сможет извлечь из устройства ключ, на котором зашифрована депонированная сумка (подбор 256-битного ключа займет достаточно много времени), расшифровать сумку и извлечь все ключи классов защиты. В результате нарушитель получит доступ некоторым данным и атрибутам безопасности.

Меры противодействия:

Случай 3: Эксплуатация обычного бэкапа. В обычных бэкапах все ключи классов защиты элементов связки ключей зашифрованы на ключе 0x835. Следовательно, имея доступ к компьютеру с бэкапом и устройству пользователя, можно с помощью утилит Sogeti Labs извлечь ключ 0x835 и расшифровать все элементы связки ключей из бэкапа.

Меры противодействия:

Случай 4: Эксплуатация зашифрованного бэкапа. В отличие от предыдущего способа часть ключей сейчас (с 6 по 8) зашифровано на парольном ключе резервной копии, а другая часть (с 9 по 11) на парольном ключе резервной копии и ключе 0x835. Если пароль резервной копии достаточно слабый, то его можно подобрать, а дальнейшие действия ничем не отличаются от предыдущего способа.

Меры противодействия:

Но не стоит думать, что достаточно сложный пароль будет панацеей от всех атак. Даже самый стойкий пароль не устоит перед социальной инженерией или внедрением вируса в устройства (при условии, что на устройстве сделан jailbreak).

Итак, в этой статье были описаны механизмы iOS, которые на аппаратном и программном уровне защищают данные пользователя, также была показана иерархия криптографических ключей, актуальная для iOS 5. В заключении статьи приведены некоторые возможные атаки, которые позволяют получить доступ к конфиденциальной информации пользователя в обход механизма защиты данных. Надеюсь, что объяснил все более-менее понятно. Следующая, последняя, статья будет носить более информационный и ознакомительный характер, в ней речь пойдет о механизмах, обеспечивающих сетевую безопасность, а также еще о некоторых вспомогательных функциях безопасности.

Основные источники

1. http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf
2. http://theiphonewiki.com/wiki/
3.http://ensiwiki.ensimag.fr/images/4/4d/4MMSR-2011-2012-student_seminar-iPhone_data_protection_in_depth_-_Jean-Baptiste_Bedrune,_Jean_Sigwald_-_HITB_Amsterdam_2011.pdf
4. http://www.slideshare.net/andrey.belenko/ios-forensics-overcoming-iphone-data-protection
5. http://code.google.com/p/iphone-dataprotection/wiki/EncryptionKeys
6. www.exploit-db.com/download_pdf/19767/
7. http://code.google.com/p/iphone-dataprotection/wiki/iTunesBackups