Android verified boot что это

Русские Блоги

Android Verified Boot 2.0

AVB2.0 (Android Verified Boot2.0) — это недавно разработанный проверенный процесс загрузки Google, используемый для защиты целостности некоторых защищенных разделов, таких как boot / recovery / system / vendor. На платформе MTK dtbo не использует защиту AVB2.0. Встроенный dtbo — это метод подписи avb2.0. Когда вызывается сценарий подписи, dtbo изменится на обычный метод подписи (dtbo используется для инициализации lcm. Невозможно отобразить состояние желтый / оранжевый / красный), а другие изображения (предварительный загрузчик, lk, логотип, тройник и т. Д.) Все еще используют поток проверки MTK. В версии Android P, если используемая платформой версия ядра больше или равна 4.9, необходимо включить AVB2.0.

раздел vbmeta

AVB2.0 добавляет раздел vbmeta. Соответствующий файл vbmeta.img компилируется и генерируется инструментом make_vbmeta_image. Он состоит в основном из следующих трех частей:

• vbmeta image header(256 Bytes)
• authentication data
  • hash
  • signature
• auxiliary data
  • public key
  • public key metadata
  • descriptors
    • hash descriptors
    • hashtree descriptors
    • chain partition descriptors

Раздел vbmeta содержит всю информацию о защищенном разделе.Каждый раздел, защищенный avb2.0, имеет структуру vbmeta. Структура vbmeta содержит несколько дескрипторов (и других метаданных), и все эти данные зашифрованы и подписаны

Защищенный раздел может быть настроен как хеш-раздел или цепочка (цепочка):

1. Раздел хеша: проверка хеша, проверьте целевой раздел с помощью хеша в дескрипторе хеша (хранится в структуре vbmeta раздела vbmeta)
2. Разделение цепочки: проверка ключа, используйте открытый ключ в дескрипторе раздела цепочки (хранится в структуре vbmeta раздела vbmeta), чтобы проверить целостность структуры vbmeta целевого раздела (vbmeta подписывается закрытым ключом)

структура vbmeta в vbmeta.img

Перебрать все дескрипторы в основном vbmeta

• дескриптор раздела цепи
  • Сохраните открытый ключ, используемый для проверки структуры vbmeta целевого раздела.
  • Если проверка структуры vbmeta целевого раздела не удалась, он не запустится
• дескриптор хеш-таблицы
  • Структура целевого раздела vbmeta не используется, игнорировать
• дескриптор хеша
  • Если это не введено в функцию входа avb2.0 в «required_partitions»: avb_slot_verify (), в противном случае структура целевой ветки vbmeta игнорируется

vbmeta связан с загрузкой / восстановлением / системой / вендором

• Настроен как хеш-раздел: должен быть обновлен с помощью основного vbmeta
• Настроен как цепной раздел: если структура vbmeta целевого раздела ненормальная, даже если этот раздел не используется в текущем режиме запуска, устройство не запустится.
  • Например, если раздел восстановления настроен как цепной раздел, если восстановление происходит ненормально, обычная загрузка не запускается
  • После того, как раздел восстановления настроен как хэш-раздел, его нельзя изменить на конфигурацию цепного раздела через OTA.

Включить функцию AVB2.0

• lk：vendor/mediatek/proprietary/bootable/bootloader/lk/project/

Настроить раздел avb

Настройте открытый и закрытый ключи vbmeta.img

• Публичный ключ: /vendor/mediatek/purantetary/bootable/bootloader/lk/target/$ndomproject‹/inc/avbkey.h
• Закрытый ключ: устройство / mediatek / common / oem_prvk.pem
  • Настройте в устройстве / mediatek / common / device.mk: BOARD_AVB_KEY_PATH: = устройство / mediatek / common / oem_prvk.pem

vbmeta.img подписывается oem_prvk.pem с помощью закрытого ключа. На этапе запуска lk использует открытый ключ в avbkey.h для проверки vbmeta.img. И этот ключ, и безопасная загрузка подтверждают, что ключи других разделов не совпадают, а файлы конфигурации не совпадают, но их можно настроить как один и тот же набор ключей.

Настроить защищенный раздел

Если он не настроен по умолчанию, защищенный раздел принимает метод хеш-раздела, а если его необходимо настроить как метод цепного раздела, то применяется следующий метод:

• Настроил системный раздел как цепной раздел
• Алгоритм SHA256_RSA2048
• Закрытый ключ — устройство / mediatek / common / system_prvk.pem
• Если макрос MAIN_VBMETA_IN_BOOT — нет, настройте раздел восстановления как цепной раздел

MTK платформа AVB2.0, безопасная загрузка и Dm-verity

Когда AVB2.0, Безопасная загрузка и Dm-verity включены одновременно, предварительный загрузчик использует метод безопасной загрузки для проверки надежности tee / lk и других разделов во время запуска системы, а метод безопасной загрузки — для проверки надежности dtbo / logo и других разделов во время фазы lk Используйте AVB для проверки надежности раздела vbmeta и надежности загрузочного раздела (или раздела восстановления). На этапе процесса инициализации, если образ поставщика или системы настроен как хеш-раздел, для проверки надежности поставщика или системного раздела используется оригинальный метод Dm-verity (при использовании проверки AVB обнаруживается, что раздел настроен как хеш-раздел, который будет пропускаться Метод Dm-verify), если он настроен как метод разбиения цепочки, затем использовать метод AVB для проверки его надежности.

Источник

Русские Блоги

Анализ корневого принципа Magisk 2: Android Verified Boot (AVB)

1. Знакомство с проверенной загрузкой Android (AVB) или проверенной загрузкой 2.0

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

AVB 2.0 представляет новый раздел: vbmeta.img (проверенные метаданные загрузки), который содержит хеш раздела,

Ниже приводится информация, анализируемая avbtool.

Он вычисляет содержимое, которое необходимо проверить во время компиляции, и упаковывает его в этот раздел.В процессе загрузки BootLoader требуется только проверить vbmeta.img, чтобы подтвердить достоверность данных в vbmeta. Затем используйте данные в vbmeta для сравнения boot.img, dtbo, system.img, vendor.img

2. Процесс калибровки

Структура VBMeta в разделе vbmeta зашифрована и подписана. На этапе запуска он проверит подпись, чтобы убедиться, что раздел vbmeta заслуживает доверия, тем самым доверяя хэш-значениям загрузочного, системного разделов и разделов поставщика. Меньшие разделы такие как boot и dtbo, напрямую хранят. Хеш-значение и другие более крупные разделы хранятся в форме хэш-дерева, и только корневой хэш хеш-дерева хранится в VBMeta.

После проверки подлинности vbmeta для разделов boot и dtbo загрузите весь образ в память и напрямую вычислите соответствующее значение хеш-функции и сравните его со значением в vameta. Если проверка не удалась, загрузка не может быть продолжена.

Для больших разделов, таких как system и vendor, прямая загрузка их в память для проверки хэша занимает много времени и не является преобразованием. Для проверки используется хеш-дерево, и проверка будет выполняться при загрузке данных в память. процесс продолжается. Система вычисляет корневой хеш-код хеш-дерева во время выполнения и сравнивает его с корневым хеш-кодом в vameta. Если вычисленное корневое хеш-значение в определенный момент времени несовместимо с ожидаемым корневым хеш-значением, данные не будут будет использоваться системой, и на Android произойдет ошибка. Эта проверка предназначена для использованияdm-verityдостигать

3. Процесс запуска

При запуске сначала проверяется состояние запуска устройства.Состояние устройства используется, чтобы указать, насколько свободно программное обеспечение может быть загружено на устройство и требуется ли принудительная проверка. Статус устройства LOCKED с UNLOCKED . Статус LOCKED Устройство запрещает вам прошивать новое программное обеспечение на устройство, и статус UNLOCKED Устройство позволяет доработать. Вот почему устройство необходимо разблокировать перед рутированием.

Когда устройство включено, загрузчик сначала проверит состояние устройства. LOCKED все еще UNLOCKED . Если статус устройства UNLOCKED , Загрузчик отобразит предупреждение для пользователя, а затем продолжит загрузку, даже если загруженная операционная система не прошла проверку.

Проблемы при запуске проверки делятся на следующие категории:

Зеленый: устройство уже LOCKED И не использует корень доверия, который может быть установлен пользователем.

Желтый: экран предупреждения для заблокированных устройств с настраиваемым корнем доверия.

Оранжевый: экран предупреждения для разблокированных устройств.

Красный (EIO): экран предупреждения о повреждении dm-verity

Красный (ОС не найдена): действующая операционная система не найдена.

Подробный процесс

На этапе lk он проверяет состояние запуска устройства, то есть находится ли оно в состоянии блокировки, если оно находится в состоянии блокировки, если проверка не удалась, система не сможет запуститься, если она находится в состоянии разблокировки, он будет продолжать запускаться, даже если будет ошибка проверки, разблокировка здесь fastboot flashing unlock

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

Передайте состояние ядру через командную строку, вот проверенное состояние загрузки, а также передает другую информацию в vbmeta

После запуска ядра init сначала прочитает переданное значение Verifiedbootstate, чтобы определить состояние устройства во время проверки. Этот процесс обработки более сложен, но это лишь приблизительный вид и требует дальнейшего изучения в будущем.

После запуска Android вы также можете увидеть статус устройства через свойства

Если есть ошибка, поправьте меня и обсудите

Источник

Android Oreo: безопасности много не бывает

Константин Иванов

Android Oreo буквально напичкан усовершенствованиями в области безопасности. В течение последних месяцев много рассказывалось, что делалось в этой области на платформе Android и в ее приложениях: от возможности более безопасно ставить приложения, отказа от ненадежных сетевых протоколов, обеспечения большего пользовательского контроля над идентификаторами, защиты ядра, упрощения получения обновлений Android и до удвоения выплат по Android Security Rewards. Теперь, когда вышел Oreo, настало время взглянуть изнутри, чего удалось достичь в целом.

Расширенная поддержка аппаратной безопасности

Android уже поддерживал доверенную загрузку (Verified Boot), которая создана специально для того, чтобы не давать устройствам загружаться с поддельным софтом. А в Android Oreo была добавлена эталонная реализация для Verified Boot, работающая с Project Treble, она получила название Android Verified Boot 2.0 (AVB). В AVB есть пара классных функций, чтобы упростить получение обновлений и сделать их более безопасными. К ним относится в том числе защита от отката. Защита от отката разработана для того, чтобы устройство не могло загрузиться, если версию ОС откатили к более старой, что может сделать его уязвимым для угроз. Для того, чтобы это стало возможным, устройства сохраняют версию ОС при помощи безопасной среды исполнения (Trusted Execution Environment,TEE), подписывая данные. Pixel 2 и Pixel 2 XL обладают этой защитой, а другим производителям устройств рекомендуется добавлять эту функцию в свои новые аппараты.

Oreo также включает в себя новый слой аппаратных абстракций (Hardware Abstraction Layer, HAL) OEM Lock, который дает производителям устройств большую свободу в выборе того, как защитить устройство, будь оно заблокированным, разблокированным или без возможности блокировки. К примеру, новые устройства Pixel используют этот HAL, чтобы передавать команды в загрузчик. Загрузчик анализирует эти команды, когда устройство загружается в следующий раз, и определяет, должны ли произойти изменения в блокировке, которые надежно хранятся в RPMB (Replay Protected Memory Block). Если ваше устройство украли, эти меры призваны помочь сохранить ваши данные и помешать перезагрузить аппарат. Этот новый HAL поддерживает даже перенос блокировки при смене «железа».

Что касается аппаратной части, Google вкладывает средства в поддержку защищенного от взлома «железа», например, модуля безопасности, который стоит в любом Pixel 2 и Pixel 2 XL. Это физический чип, который способен предотвратить многие программные и аппаратные атаки, а также устойчив к физическому проникновению. Модуль безопасности предотвращает получение кода шифрования без наличия пароля к устройству и ограничивает число попыток разблокировки, что делает невозможными многие попытки взлома в силу временных ограничений.

В то время как аппараты Pixel обладают специальным модулем безопасности, все новые устройства с сервисами Google и Android Oreo на борту должны проходить аттестацию ключа. Это предоставляет механизм жесткой проверки идентификаторов, таких как идентификаторы устройств и компонентов.

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

Повышение безопасности платформы и изоляция процессов

В рамках Project Treble фреймворк Android был переработан, чтобы процесс получения обновлений был проще и стоил меньше для производителей устройств. Это разделение кода платформы и модифицированного кода производителя также было осуществлено для повышения безопасности. Следуя принципу минимальной привилегии, эти HAL работают в собственной среде и имеют доступ только к абсолютно необходимым драйверам и разрешениям.

Далее в продолжение работы над защитой хранилища медиа, начатой в Android Nougat, в Oreo убрали большую часть прямого доступа к аппаратной части из медиа фреймворков, результатом стала лучшая изоляция. Более того, для всех медиакомпонентов была внедрена CFI (Control Flow Integrity). Большая часть уязвимостей сейчас реализуется посредством разрушения нормального потока управления приложения, которое начинает проявлять вредоносную активность, используя все свои привилегии. CFI – это мощный механизм безопасности, который не позволяет вносить произвольные изменения в исходный граф потока управления скомпилированного двоичного файла, что значительно осложняет осуществление подобных атак.

Вдобавок к этим изменениям в архитектуре и CFI в Android Oreo есть еще ряд полезных усовершенствований безопасности платформы:

• Фильтрация Seccomp: делает ряд неиспользуемых системных вызовов недоступными для приложений, так что они не могут быть использованы потенциально вредоносными приложениями;
• Защищенная пользовательская копия: недавнее исследование уязвимых мест в безопасности на Android показало, что недействительная или отсутствующая проверка границ имела место примерно в 45% уязвимостей ядра. Поэтому функцию проверки границ портировали в ядра Android от 3.18 и выше, что затрудняет использование уязвимостей, а также помогает разработчикам выявлять проблемы и исправлять баги в своем коде;
• Эмуляция PAN (Privileged Access Never): также портирована в ядра от 3.18 и выше, функция не позволяет ядру получать доступ напрямую к пользовательскому пространству и гарантирует, что разработчики будут использовать для доступа к нему защищенные функции;
• Рандомизация размещения адресного пространства в ядре (Kernel Address Space Layout Randomization, KASLR): поскольку Android много лет поддерживает в пользовательском пространстве рандомизацию размещения адресного пространства, KASLR была портирована для того, чтобы уменьшить уязвимости в ядрах Android от 4.4 и выше. Работа KASLR состоит в том, чтобы случайным образом изменяя место кода ядра при каждой загрузке, сделать атаки, основанные на повторном использовании кода, менее вероятными и труднее осуществимыми, в особенности удаленно.

Безопасность приложений и изменения в идентификаторе устройства

Приложения Android с мгновенным запуском (Instant Apps) работают в ограниченном пространстве, ограничивающем разрешения и возможности, такие как чтение списка приложений на устройстве или передача чистого трафика. Будучи представленными во время релиза Android Oreo, Instant Apps поддерживают устройства на Android Lollipop и выше.

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

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

Перенос статических значений Android ID и Widevine в значения приложений, что позволяет ограничить использование атрибутов устройства и неперенастраиваемых идентификаторов.

В соответствии с требованием по анонимности IETF RFC 7844, значение net.hostname теперь пустое и DHCP клиент больше не отправляет имя хоста.

Для приложений, которые требуют ID устройства, был создан Build.getSerial() API, который защищает его помимо разрешений.

Вместе со специалистами по безопасности из Лионского университета и ряда других организаций была разработана надежная система рандомизации МАС адресов для сканирования траффика Wi-Fi на множестве аппаратных платформ.

Разработчики Android Oreo обещают в дальнейшем продолжить усовершенствования системы безопасности, в том числе и на основе отзывов и предложений пользователей.

Источник