Для дальнейшего повышения доверия к ОС Android мы обязуемся перечислять в нашем журнале прозрачности каждый модуль ОС Android (называемый Mainline ), предлагаемый в качестве обновления через Google Play. Мы публикуем журнал прозрачности , чтобы подтвердить заявления, которые мы делаем об этих модулях. Предустановленные модули явно не указываются, поскольку они уже охвачены программой Pixel Binary Transparency .
Модель угроз
Системы прозрачности могут использоваться для обнаружения и, следовательно, предотвращения атак на цепочки поставок. Проиллюстрируем это несколькими примерами.
Предположим, злоумышленник намеренно модифицирует основной модуль (который может быть файлом APEX или APK ) и даже подписывает его ключом подписи, используемым для распространения через Google Play. Любой, кто получит сомнительный модуль, может запросить журнал прозрачности бинарных файлов, чтобы проверить подлинность модуля. Он обнаружит, что Google не добавил соответствующие метаданные модуля в журнал, и поймет, что не следует доверять скомпрометированному модулю операционной системы.
Поскольку публикация в журнале — это отдельный процесс от процесса выпуска с подписыванием, это повышает планку для злоумышленника, выходя за рамки простого взлома ключа.
Хотя мы планируем также интегрировать этот журнал в общедоступную сеть свидетелей, используя стандартный протокол свидетелей , мы призываем внешние независимые стороны контролировать целостность этого общедоступного журнала. Эти стороны могут подтвердить свойство журнала «только добавление» и сообщить о любых попытках его изменения.
Наличие такой системы прозрачности и дополнительная возможность обнаружения атак препятствуют вредоносной деятельности. Если модуль операционной системы скомпрометирован, но пользователи доверяют только тем данным, которые содержатся в журнале, скомпрометированный модуль необходимо будет публично раскрыть. Это повышает вероятность обнаружения существования скомпрометированного модуля и принятия мер по его удалению.
Модель заявителя
Модель заявителя — это структура, используемая для определения ролей и артефактов в проверяемой системе. В случае прозрачности основных модулей Android мы утверждаем, что хеш файла модуля, записанный в этом журнале, представляет собой конкретную версию официального модуля Android, предназначенного для публичного использования.
- Утверждение MainlineModule : (Я, Google, утверждаю, что
$hashModuleпредназначен для$mainlineModule), где:-
$hashModule— это криптографический хеш (например, SHA256) файла модуля операционной системы для конкретной версии$mainlineModule. -
$mainlineModule— это либо APEX-файл , либо Android-пакет ( APK ), представляющий собой модуль операционной системы, который Google создает, подписывает и распространяет.
-
Любой, у кого есть копия $mainlineModule может проверить это утверждение. На странице проверки приведены подробные инструкции по этому процессу. Эти шаги применимы как к обычным APK-файлам, так и к модулям Mainline (которые могут быть как APK-файлами, так и APEX-файлами).
Содержимое журнала
Когда Google выпускает новую версию основного модуля, в журнал прозрачности основных модулей добавляется соответствующая запись.
Каждая запись в этом журнале содержит четыре элемента метаданных:
- Хэш APK или APEX подписанного модуля Android Mainline. Это шестнадцатеричная строка дайджеста SHA256 всего файла.
- Приведенное выше описание типа хеша. Это строка.
- Название пакета модуля. Это строка.
- Номер версии ( versionCode ) модуля. Это ненулевое целое число.
Формат записи в журнале представляет собой объединение четырех элементов информации символом новой строки ( \n ), как показано ниже:
hash\nhash_description\npackage_name\npackage_version\n
Поскольку основной модуль может представлять собой либо APK-файл, либо APEX-файл, описание хеша может быть либо SHA256(APK) , либо SHA256(APEX) .