Удаленное предоставление ключей Google будет обязательным в Android 13, но это сложная тема. Вот что это будет значить для вас.
Аттестация ключей Android является основой многих надежных служб на наших смартфонах, включая SafetyNet, Digital Car Key и API учетных данных удостоверения. Он был необходим как часть Android начиная с Android 8 Oreo и зависел от корневого ключа, установленного на устройстве на заводе. Предоставление этих ключей требовало предельной секретности со стороны производителя, и если утечка ключа произошла, это означало бы, что ключ необходимо будет отозвать. Это приведет к тому, что потребитель не сможет использовать ни одну из этих доверенных служб, что было бы прискорбно, если бы когда-либо возникла уязвимость, которая могла бы его раскрыть. Предоставление удаленных ключей, которое будет обязательным в Андроид 13, призван решить эту проблему.
Компоненты, составляющие текущую цепочку доверия на Android
Прежде чем объяснять, как работает новая система, важно представить контекст того, как
старый (и до сих пор действует для многих устройств) система работает. Многие телефоны в настоящее время используют аппаратную аттестацию ключей, которая, возможно, вам знакома как гвоздь в гроб для любого обхода SafetyNet. Существует несколько концепций, которые важно понимать для текущего состояния аттестации ключей.Именно сочетание этих концепций гарантирует, что разработчик может быть уверен, что устройство не было взломано, и может обрабатывать конфиденциальную информацию в TEE.
Доверенная среда выполнения
Доверенная среда выполнения (TEE) — это безопасная область на SoC, которая используется для обработки критически важных данных. TEE является обязательным на устройствах с Android 8 Oreo и выше, а это означает, что он есть на любом последнем смартфоне. Все, что находится за пределами TEE, считается «ненадежным» и может видеть только зашифрованный контент. Например, контент, защищенный DRM, шифруется ключами, доступ к которым возможен только с помощью программного обеспечения, работающего на TEE. Главный процессор может видеть только поток зашифрованного контента, тогда как контент может быть расшифрован TEE и затем отображен пользователю.
Трастовая зона ARM
Trusty — это безопасная операционная система, которая обеспечивает TEE на Android, а в системах ARM она использует Trustzone ARM. Trusty выполняется на том же процессоре, что и основная операционная система, и имеет доступ ко всей мощности устройства, но полностью изолирован от остальной части телефона. В состав Трасти входят:
- Небольшое ядро ОС, полученное из Маленькое ядро
- Драйвер ядра Linux для передачи данных между безопасной средой и Android.
- Библиотека пользовательского пространства Android для взаимодействия с доверенными приложениями (то есть безопасными задачами/службами) через драйвер ядра.
Преимущество его перед проприетарными системами TEE заключается в том, что эти системы TEE могут быть дорогостоящими, а также создавать нестабильность в экосистеме Android. Trusty предоставляется OEM-партнерам Google бесплатно и имеет открытый исходный код. Android поддерживает другие системы TEE, но Google продвигает Trusty больше всего.
Сейф
Устройства StrongBox представляют собой полностью отдельные, специально созданные и сертифицированные безопасные процессоры. Они могут включать встроенные элементы безопасности (eSE) или защищенный процессор (SPU) на SoC. Google сообщает, что StrongBox в настоящее время «настоятельно рекомендуется» поставлять с устройствами, запускаемыми с Андроид 12 (согласно документу определения совместимости), поскольку это, вероятно, станет требованием в будущей версии Android. По сути, это более строгая реализация аппаратного хранилища ключей, которую можно реализовать вместе с TrustZone. Примером реализации StrongBox является чип Titan M в смартфонах Pixel. Не многие телефоны используют StrongBox, а большинство использует Trustzone ARM.
Ключник ТА
Keymaster Trusted Application (TA) — это безопасный мастер ключей, который управляет всеми операциями хранилища ключей и выполняет их. Он может работать, например, в TrustZone ARM.
Как аттестация ключей меняется в Android 12 и Android 13
Если на смартфоне Android обнаружен ключ, Google обязан отозвать его. Это создает проблему для любого устройства, в которое встроен ключ на заводе: любая утечка, приводящая к раскрытию ключа, будет означать, что пользователи не смогут получить доступ к определенному защищенному контенту. Это может даже включать отзыв доступа к таким сервисам, как Google Pay, на который полагаются многие люди. Это досадно для потребителей, поскольку, если бы ваш телефон не был отремонтирован производителем, у вас не было бы возможности починить его самостоятельно.
Войдите в предоставление удаленного ключа. Начиная с Android 12, Google заменяет заводскую настройку закрытого ключа комбинацией Извлечение открытого ключа на заводе и предоставление сертификатов по беспроводной сети с кратковременным сроком действия. сертификаты. Эта схема потребуется в Android 13, и у нее есть несколько преимуществ. Прежде всего, это избавляет OEM- и ODM-производителей от необходимости управлять секретностью ключей на заводе. Во-вторых, это позволяет восстанавливать устройства в случае компрометации их ключей, а это означает, что потребители не потеряют навсегда доступ к защищенным сервисам. Теперь вместо использования сертификата, рассчитанного с использованием ключа, который находится на устройстве и может быть утечка через уязвимости, временный сертификат запрашивается у Google каждый раз, когда служба, требующая аттестации, использовал.
Что касается того, как это работает, то это достаточно просто. Каждое устройство генерирует уникальную статическую пару ключей, а общедоступная часть этой пары ключей извлекается OEM-производителем на его заводе и отправляется на серверы Google. Там они будут служить основой доверия для дальнейшего обеспечения. Закрытый ключ никогда не покидает безопасную среду, в которой он создан.
Когда устройство впервые используется для подключения к Интернету, оно генерирует запрос на подпись сертификата для сгенерированные им ключи, подписывая их закрытым ключом, который соответствует открытому ключу, собранному в фабрика. Внутренние серверы Google проверят подлинность запроса, а затем подпишут открытые ключи, вернув цепочки сертификатов. Затем хранилище ключей на устройстве будет хранить эти цепочки сертификатов, назначая их приложениям всякий раз, когда запрашивается аттестация. Это может быть что угодно, от Google Pay до Pokemon Go.
Эта точная цепочка запросов сертификатов будет происходить регулярно после истечения срока действия сертификатов или исчерпания текущего запаса ключей. Каждое приложение получает отдельный ключ подтверждения, а сами ключи регулярно меняются, что обеспечивает конфиденциальность. Кроме того, серверные серверы Google сегментированы таким образом, что сервер, проверяющий открытый ключ устройства, не видит прикрепленные ключи подтверждения. Это означает, что Google не может сопоставить ключи подтверждения с конкретным устройством, которое их запросило.
По мнению Google, конечные пользователи не заметят никаких изменений, хотя разработчикам следует обратить внимание на следующее.
- Структура цепочки сертификатов
- Из-за особенностей нашей новой инфраструктуры онлайн-обеспечения длина цепочки стала длиннее, чем была раньше, и может быть изменена.
- Корень доверия
- Корень доверия в конечном итоге будет обновлен с текущего ключа RSA на ключ ECDSA.
- Прекращение поддержки аттестации RSA
- Все ключи, сгенерированные и заверенные KeyMint, будут подписаны ключом ECDSA и соответствующей цепочкой сертификатов. Раньше асимметричные ключи подписывались соответствующим алгоритмом.
- Кратковременные сертификаты и ключи аттестации
- Сертификаты, предоставленные устройствам, обычно действительны в течение двух месяцев до истечения срока их действия и ротации.
Мы связались с Google и спросили, имеет ли это какое-либо отношение к Widevine DRM и как некоторые пользователи Pixel сообщили о понижении их уровня DRM при заблокированном загрузчике. Мы также спросили, можно ли теперь распространить это обновление среди пользователей в качестве OTA-обновления через сервисы Google Play. Мы обязательно обновим эту статью, если получим ответ. Неясно, какие компоненты нынешней цепочки доверия будут затронуты и каким образом.
Источник: Google