Russian Chinese (Simplified) English
Войти

Пожалуй начну по-тихоньку цикл статей про безопасность ОС Android. Начнем рассматривать доверенную загрузку. Оригинал темы и обсуждение на 4PDA.
Насколько мне известно, механизм контроля целостности как таковой в Андроиде появился в версии 4.4 (KitKat). Реализован он, как мне кажется, пока что в экспериментальном режиме, т.к. я не видел и не слышал еще о официальных прошивках с включенным Secure Boot.
Итак, мне стало интересно как он работает и есть ли его аналоги. Практическую часть я пока не затрагивал, разбираюсь в теории, надеюсь кому нибудь тоже станет интересно ;)


Первое что попалось на глаза когда стал изучать вопрос - конечно же официальная документация от Google, но более полезными я для себя нашел статьи разработчика Николая Неленкова. Одна из них так и называется - KitKat verified boot. Из нее я выделил основные моменты и перевел ее.

 

Мой перевод статьи Николая Неленкова


Начиная с Android 4.4, появилась экспериментальная версия механизма контроля целостности при загрузке – Android's verified boot (Secure Boot). Он основан на проверке Device mapper,ом целостности блочных устройств с помощью механизма dm-verify. Device mapper (dm) - подсистема (модуль) ядра Linux, позволяющая создавать виртуальные блочные устройства (ВБУ). При обращении к таким устройствам выполняется ряд действий, в число которых обычно входит чтение/запись данных с других блочных устройств (БУ). Подсистема используется для реализации менеджера логических томов LVM, программного RAID, системы шифрования дисков dm-crypt.
Механизм dm-verify – это прозрачный контроль целостности каждого отдельного блока БУ. Если блок проверен и целостность не нарушена, операция чтения производится без проблем, а если целостность нарушена – при операции чтения выдается ошибка ввода / вывода, также как если бы блок был физически поврежден. Проверка dm-verify осуществляется с помощью предварительно рассчитанного хеш-дерева, которое включает в себя хеши всех блоков устройства. Листовые узлы дерева включают хеши физических блоков устройства, в то время как промежуточные узлы хеши их дочерних узлов (хеши хешей). Корневой узел называется корневой хеш-суммой и основан на всех хешах более низких уровней (рис. 1). Таким образом, изменение даже в одном блоке устройства приведет к изменению корневой хеш-суммы. Поэтому для того, чтобы проверить целостность БУ нужно проверить только корневую хеш-сумму этого БУ. Во время работы, dm-verify вычисляет хеш каждого блока при чтении и проверяет его с помощью предварительно рассчитанного хеш-дерева.

Рис.1

В момент проверки БУ должно быть смонтировано только в режиме чтения. Данный механизм отлично подходит для проверки статичных системных разделов, в которых файлы меняются только при обновлении. Любое другое изменение указывает на повреждение диска или появление вредоносной программы, которая пытается внести изменения в ОС или маскироваться под системный файл. Механизм dm-verify согласуется с моделью безопасности ОС Android, согласно которой, системные разделы смонтированы только на чтение.
Изначально, механизм dm-verify был разработан в целях реализации проверенной загрузки в Chrome OS, и был интегрирован в ядро Linux начиная с версии 3.4. Как и Chrome OS, Android 4.4 использует dm-verify в тех же целях, но криптографическая проверка корневой хеш-суммы разделов реализована по-другому.
Для проверки dm-verity mapping table (таблицы хеш-сумм), используется открытый ключ RSA (verity_key), который встроен в загрузочный раздел(Bootloader). Таблица соответствия и её цифровая подпись являются частью проверочного мета-блока который записывается на диск сразу после последнего блока файловой системы целевого устройства. Раздел помечается как проверяемый, путем добавления флага проверки fs_mgr, в файл fstab. Когда менеджер файловой системы Android,  обнаруживает флаг проверки в fstab, он загружает проверочные метаданные от блочного устройства, указанного в fstab и проверяет его подпись с помощью verity_key. Если проверка подписи проходит успешно, менеджер файловой системы анализирует таблицу dm-verity mapping table и передает его device-mapper, который использует информацию, содержащуюся в таблице для создания виртуального блочного устройства dm-verify. Это виртуальное блочное устройство монтируется в точке подключения, указанного в fstab, в месте, соответствующем физическому устройству. В результате, все данные считываются из основного физического устройства, проверяются  с помощью предварительно сгенерированного хеш дерева. Изменение или добавление файлов, или даже перемонтирование раздела в режим чтения-записи, приводит к ошибке проверки целостности и ошибки ввода / вывода.
Важно отметить, что открытый ключ должен храниться в загрузочном разделе неподдающемся изменению. Именно поэтому ключ обычно вшивают в Bootloader(загрузчик).

 

Все ссылки на использованные ресурсы ниже:

Документация от Google

Документация по Device mapper (dm)

Документация по DM Verify

Оригинал статьи Николая Неленкова. KitKat verified boot