Эта страница переведена с помощью Cloud Translation API.

Проверка пар аппаратных ключей с помощью аттестации ключей

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

Перед началом работы: убедитесь, что ваше устройство поддерживает аттестацию ключей на аппаратном уровне.

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

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

Получите и проверьте пару ключей, поддерживаемую аппаратным обеспечением.

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

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

Для внедрения аттестации ключей выполните следующие шаги:

Используйте метод getCertificateChain() объекта KeyStore , чтобы получить ссылку на цепочку сертификатов X.509, связанных с аппаратным хранилищем ключей.
Отправьте сертификаты на отдельный сервер, которому вы доверяете, для проверки.
Внимание: Не выполняйте следующую проверку на одном и том же устройстве. Если система Android на этом устройстве скомпрометирована, это может привести к тому, что в процессе проверки будет доверено что-то ненадежное.
Получите ссылку на библиотеку для анализа и проверки цепочек сертификатов X.509, наиболее подходящую для вашего набора инструментов. Убедитесь, что корневой открытый сертификат является надежным и что каждый сертификат подписывает следующий сертификат в цепочке.
Проверьте статус отзыва каждого сертификата, чтобы убедиться, что ни один из сертификатов не был отозван.
При желании можно проверить расширение сертификата, содержащее информацию о предоставлении доступа, которое присутствует только в более новых цепочках сертификатов.
Получите ссылку на библиотеку парсера CBOR, наиболее подходящую для вашего набора инструментов. Найдите ближайший к корневому сертификату, содержащий расширение сертификата с информацией о предоставлении доступа . Используйте парсер для извлечения данных расширения сертификата с информацией о предоставлении доступа из этого сертификата.
Более подробную информацию см. в разделе, посвященном расширению информации о предоставлении ресурсов .
Получите ссылку на библиотеку парсера ASN.1, наиболее подходящую для вашего набора инструментов. Найдите ближайший к корневому сертификат, содержащий расширение сертификата подтверждения ключа . Если расширение сертификата информации о предоставлении ресурсов присутствовало, расширение сертификата подтверждения ключа должно присутствовать в непосредственно следующем сертификате. Используйте парсер для извлечения данных расширения сертификата подтверждения ключа из этого сертификата.
Внимание: Не следует предполагать, что расширение сертификата подтверждения ключа находится в конечном сертификате цепочки. Доверять можно только первому вхождению расширения в цепочке. Любые последующие экземпляры расширения не были выпущены защищенным оборудованием и могли быть выпущены злоумышленником, расширяющим цепочку при попытке создать поддельные подтверждения для недоверенных ключей.
В примере Key Attestation используется парсер ASN.1 от Bouncy Castle для извлечения данных расширения сертификата аттестации. Вы можете использовать этот пример в качестве образца для создания собственного парсера.
Более подробную информацию см. в разделе, посвященном схеме данных расширения аттестации ключей .
Проверьте согласованность данных расширения, полученных на предыдущих шагах, и сравните их с набором значений, которые, как вы ожидаете, должен содержать аппаратный ключ.

Корневые сертификаты

Достоверность аттестации зависит от корневого сертификата цепочки. Устройства Android, прошедшие тестирование, необходимое для установки пакета приложений Google, включая Google Play, и выпущенные с Android 7.0 (уровень API 24) или выше, должны использовать ключи аттестации, подписанные корневым сертификатом Google Hardware Attestation Root. Обратите внимание, что аттестация не требовалась до Android 8.0 (уровень API 26). Набор действительных корневых сертификатов можно загрузить в виде массива в формате JSON .

Корневые сертификаты

При проверке цепочки сертификатов подтверждения ключа в качестве доверенных точек следует использовать следующие два корневых сертификата.

Ранее выданные корневые сертификаты

Если корневой сертификат в полученной вами цепочке аттестации содержит этот открытый ключ, и ни один из сертификатов в цепочке не был отозван , то вы знаете, что:

Ваш ключ находится в оборудовании, которое Google считает безопасным;
Оно обладает свойствами, описанными в свидетельстве о подтверждении.

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

Если корневой сертификат не содержит открытый ключ, указанный на этой странице, возможны две причины:

Вероятнее всего, устройство было выпущено с версией Android ниже 7.0 и не поддерживает аппаратную аттестацию. В этом случае Android имеет программную реализацию аттестации, которая создает аналогичный сертификат, но подписанный ключом , жестко закодированным в исходном коде Android . Поскольку этот ключ подписи не является секретом, аттестация могла быть создана злоумышленником, выдающим себя за создателя защищенного оборудования.
Другая вероятная причина заключается в том, что устройство не является устройством Google Play. В этом случае производитель устройства может свободно создать собственный корневой сертификат и определить значение данных аттестации. Обратитесь к документации производителя устройства. Следует отметить, что Google не располагает информацией о каких-либо производителях устройств, которые бы так поступили.

ротация корневого сертификата подтверждения оборудования

Google внедряет новый корневой сертификат для аттестации ключей Android . Это изменение повышает безопасность и надежность процесса аттестации для конфиденциальных приложений. Для аттестации ключей Android (KeyMint) был сгенерирован новый корневой ключ. Новый корневой ключ представляет собой ключ ECDSA P-384.

Что вам нужно сделать

Если ваше приложение использует аттестацию ключей Android, добавьте новый корневой сертификат в хранилище доверенных сертификатов до 31 марта 2026 года. Загрузите как новый, так и старый сертификаты по ссылке https://android.googleapis.com/attestation/root
Устройства, использующие технологию удаленного предоставления ключей (RKP), начнут получать сертификаты, основанные на этом новом сертификате, в феврале 2026 года. К 10 апреля 2026 года устройства с поддержкой RKP будут использовать исключительно новый корневой сертификат.
Обновите процессы аттестации, чтобы они доверяли как новому, так и существующему корневому сертификату. Более старые устройства с заводскими ключами не поддерживают смену ключей и продолжают использовать старый корневой сертификат.
Сама схема расширения сертификата останется неизменной; изменится только корневой сертификат.
Как удобочитаемая, так и машиночитаемая версии нового корневого кода будут доступны для публичного доступа.

Проверьте совместимость с новым корневым каталогом.

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

Предварительные требования

Убедитесь, что выполнены следующие требования:

Python 3
Отладочный мост Android (adb)
Устройство под управлением Android с заданной конфигурацией:
- Используется Android 15 или выше.
- Параметры разработчика включены .
- Устройство поддерживает RKP. Большинство устройств, выпущенных в 2025 году и позже, поддерживают RKP. Вы можете проверить поддержку RKP, используя adb shell cmd remote_provisioning dump . В результате должна отобразиться следующая информация:
```
default:
  hwVersion=[INTEGER]
  rpcAuthorName=[DEVICE MAKER]
    
```

Зарегистрируйте ваше устройство

Выполните следующие шаги, чтобы зарегистрировать ваше устройство.

Загрузите инструмент для регистрации тестового устройства: google_root_register.py
Запустите инструмент регистрации: python3 google_root_register.py
Выполните сброс настроек устройства до заводских . Этот шаг необходим для удаления всех ранее предоставленных сертификатов.

Убедитесь, что устройство получает сертификаты, подписанные новым корневым сертификатом, выполнив команду adb shell cmd remote_provisioning certify default . В результате будет получена цепочка сертификатов X.509 в формате PEM. Последний сертификат является корневым и должен соответствовать следующим параметрам:

Протестируйте приложение на устройстве.

Передовые методы

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

Постепенный отказ от заводских ключей: удаленная настройка ключей (RKP).

Для устройств, выпущенных с Android 16, система поддерживает только RKP. Эта политика постепенно отказывается от заводских ключей. Она улучшает процесс предоставления и управления ключами аттестации, расширяя возможности политики Android 15, где поддержка RKP была необязательной. RKP предотвращает утечку ключей, поскольку система не программирует ключи непосредственно на устройство. Вы не можете удалить эти ключи с устройства. Если вам необходимо отозвать ключ, вы можете сделать это для одного конкретного устройства.

Библиотеки аттестационной проверки

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

список статусов аннулирования сертификатов

Ключи аттестации могут быть отозваны по ряду причин, включая некорректное обращение или подозрение на их извлечение злоумышленником. Поэтому крайне важно проверять статус каждого сертификата в цепочке аттестации по официальному списку статусов отзыва сертификатов (CRL). Этот список поддерживается Google и публикуется по адресу: https://android.googleapis.com/attestation/status . Заголовок Cache-Control в HTTP-ответе определяет, как часто следует проверять наличие обновлений, поэтому сетевой запрос не требуется для каждого проверяемого сертификата. Этот URL-адрес возвращает JSON-файл, содержащий статус отзыва для всех сертификатов, которые не имеют обычного действительного статуса. Формат JSON-файла соответствует следующему определению JSON Schema ( проект 07 ):

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "entries": {
      "description" : "Each entry represents the status of an attestation key. The dictionary-key is the certificate serial number in lowercase hex.",
      "type": "object",
      "propertyNames": {
        "pattern": "^[a-f1-9][a-f0-9]*$"
      },
      "additionalProperties": {
        "type": "object",
        "properties": {
          "status": {
            "description": "[REQUIRED] Current status of the key.",
            "type": "string",
            "enum": ["REVOKED", "SUSPENDED"]
          },
          "expires": {
            "description": "[OPTIONAL] UTC date when certificate expires in ISO8601 format (YYYY-MM-DD). Can be used to clear expired certificates from the status list.",
            "type": "string",
            "format": "date"
          },
          "reason": {
            "description": "[OPTIONAL] Reason for the current status.",
            "type": "string",
            "enum": ["UNSPECIFIED", "KEY_COMPROMISE", "CA_COMPROMISE", "SUPERSEDED", "SOFTWARE_FLAW"]
          },
          "comment": {
            "description": "[OPTIONAL] Free form comment about the key status.",
            "type": "string",
            "maxLength": 140
          }
        },
        "required": ["status"],
        "additionalProperties": false
      }
    }
  },
  "required": ["entries"],
  "additionalProperties": false
}

Пример списка отозванных клиентов (CRL):

{
  "entries": {
    "2c8cdddfd5e03bfc": {
      "status": "REVOKED",
      "expires": "2020-11-13",
      "reason": "KEY_COMPROMISE",
      "comment": "Key stored on unsecure system"
    },
    "c8966fcb2fbb0d7a": {
      "status": "SUSPENDED",
      "reason": "SOFTWARE_FLAW",
      "comment": "Bug in keystore causes this key malfunction b/555555"
    }
  }
}

Политика аннулирования сертификатов

Аттестация является основой противодействия злоупотреблениям и обеспечения доверия в экосистеме Android. Она предоставляет криптографически проверяемое подтверждение внешнему пользователю о состоянии устройства после загрузки.

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

Что является основанием для отзыва лицензии?

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

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

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

Проверка пар аппаратных ключей с помощью аттестации ключей

Перед началом работы: убедитесь, что ваше устройство поддерживает аттестацию ключей на аппаратном уровне.

Получите и проверьте пару ключей, поддерживаемую аппаратным обеспечением.

Корневые сертификаты

ротация корневого сертификата подтверждения оборудования

Что вам нужно сделать

Проверьте совместимость с новым корневым каталогом.

Предварительные требования

Зарегистрируйте ваше устройство

Передовые методы

Постепенный отказ от заводских ключей: удаленная настройка ключей (RKP).

Библиотеки аттестационной проверки

список статусов аннулирования сертификатов

Политика аннулирования сертификатов

Что является основанием для отзыва лицензии?

Схема данных расширения аттестации ключа

Схема данных расширения информации о предоставлении ресурсов