Подтверждение ключа и удостоверения личности

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

Однако это верно только в том случае, если известно, что ключи хранилища ключей находятся в аппаратном хранилище. В Keymaster 1 у приложений или удаленных серверов не было возможности надежно проверить, так ли это. Демон хранилища ключей загрузил доступный ключевой мастер HAL и поверил всему, что HAL сказал в отношении аппаратной поддержки ключей.

Чтобы исправить это, компания Keymaster представила аттестацию ключей в Android 7.0 (Keymaster 2) и аттестацию идентификатора в Android 8.0 (Keymaster 3).

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

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

Ключевая аттестация

Для поддержки аттестации ключей в Android 7.0 в HAL представлен набор тегов, типов и методов.

Теги

  • Tag::ATTESTATION_CHALLENGE
  • Tag::INCLUDE_UNIQUE_ID
  • Tag::RESET_SINCE_ID_ROTATION

Тип

Keymaster 2 и ниже

typedef struct {
    keymaster_blob_t* entries;
    size_t entry_count;
} keymaster_cert_chain_t;

Метод AttestKey

Ключник 3

    attestKey(vec<uint8_t> keyToAttest, vec<KeyParameter> attestParams)
        generates(ErrorCode error, vec<vec<uint8_t>> certChain);

Keymaster 2 и ниже

keymaster_error_t (*attest_key)(const struct keymaster2_device* dev,
        const keymaster_key_blob_t* key_to_attest,
        const keymaster_key_param_set_t* attest_params,
        keymaster_cert_chain_t* cert_chain);
  • dev — структура устройства keymaster.
  • keyToAttest — это ключевой объект, возвращаемый generateKey , для которого создается аттестация.
  • attestParams — список любых параметров, необходимых для аттестации. Сюда входят Tag::ATTESTATION_CHALLENGE и, возможно, Tag::RESET_SINCE_ID_ROTATION , а также Tag::APPLICATION_ID и Tag::APPLICATION_DATA . Последние два необходимы для расшифровки ключа, если они были указаны при генерации ключа.
  • certChain — выходной параметр, который возвращает массив сертификатов. Запись 0 — это сертификат аттестации, то есть она сертифицирует ключ из keyToAttest и содержит расширение аттестации.

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

Сертификат аттестации

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

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

Сертификат ПОСЛЕДОВАТЕЛЬНОСТЬ

Имя поля (см. RFC 5280 ) Ценить
tbsCertificate TBSCertificate ПОСЛЕДОВАТЕЛЬНОСТЬ
подписьАлгоритм AlgorithmIdentifier алгоритма, используемого для подписи ключа:
ECDSA для ключей EC, RSA для ключей RSA.
подписьзначение BIT STRING, подпись, вычисленная на tbsCertificate, закодированном в ASN.1 DER.

TBSCertificate ПОСЛЕДОВАТЕЛЬНОСТЬ

Имя поля (см. RFC 5280 ) Ценить
version ЦЕЛОЕ ЧИСЛО 2 (означает сертификат v3)
serialNumber ЦЕЛОЕ ЧИСЛО 1 (фиксированное значение: одинаковое для всех сертификатов)
signature AlgorithmIdentifier алгоритма, используемого для подписи ключа: ECDSA для ключей EC, RSA для ключей RSA.
issuer То же, что поле темы ключа пакетного подтверждения.
validity ПОСЛЕДОВАТЕЛЬНОСТЬ двух дат, содержащих значения Tag::ACTIVE_DATETIME и Tag::USAGE_EXPIRE_DATETIME . Эти значения указаны в миллисекундах с 1 января 1970 года. Правильное представление даты в сертификатах см. в RFC 5280 .
Если Tag::ACTIVE_DATETIME отсутствует, используйте значение Tag::CREATION_DATETIME . Если Tag::USAGE_EXPIRE_DATETIME отсутствует, используйте дату истечения срока действия сертификата ключа пакетной аттестации.
subject CN = «Ключ хранилища ключей Android» (фиксированное значение: одинаковое для всех сертификатов)
subjectPublicKeyInfo subjectPublicKeyInfo, содержащий подтвержденный открытый ключ.
extensions/Key Usage digitalSignature: устанавливается, если ключ имеет назначение KeyPurpose::SIGN или KeyPurpose::VERIFY . Все остальные биты не установлены.
extensions/CRL Distribution Points Значение подлежит уточнению
extensions/"attestation" OID — 1.3.6.1.4.1.11129.2.1.17; содержимое определяется в разделе «Расширение аттестации» ниже. Как и во всех расширениях сертификата X.509, содержимое представлено в виде OCTET_STRING, содержащего кодировку DER аттестационной ПОСЛЕДОВАТЕЛЬНОСТИ.

Расширение аттестации

Расширение attestation содержит полное описание авторизаций мастера ключей, связанных с ключом, в структуре, которая напрямую соответствует спискам авторизации, используемым в Android и HAL мастера ключей. Каждый тег в списке авторизации представлен записью ASN.1 SEQUENCE , явно помеченной номером тега мастера ключей, но с замаскированным дескриптором типа (четыре старших бита).

Например, в Keymaster 3 Tag::PURPOSE определен в файле Types.hal как ENUM_REP | 1 . Для расширения аттестации значение ENUM_REP удаляется, оставляя тег 1 . (Для Keymaster 2 и ниже KM_TAG_PURPOSE определяется в keymaster_defs.h.)

Значения напрямую преобразуются в типы ASN.1 в соответствии с этой таблицей:

Тип мастера ключей Тип АСН.1
ENUM ЦЕЛОЕ ЧИСЛО
ENUM_REP НАБОР ЦЕЛЫХ ЧИСЛЕН
UINT ЦЕЛОЕ ЧИСЛО
UINT_REP НАБОР ЦЕЛЫХ ЧИСЛЕН
ULONG ЦЕЛОЕ ЧИСЛО
ULONG_REP НАБОР ЦЕЛЫХ ЧИСЛЕН
DATE ЦЕЛОЕ ЧИСЛО (миллисекунды с 1 января 1970 г., 00:00:00 по Гринвичу)
BOOL NULL (в Keymaster наличие тега означает истину, отсутствие означает ложь.
Та же семантика применима и к кодировке ASN.1)
BIGNUM В настоящее время не используется, поэтому сопоставление не определено.
BYTES ОКТЕТ_STRING

Схема

Содержимое расширения аттестации описывается следующей схемой ASN.1.

KeyDescription ::= SEQUENCE {
  attestationVersion         INTEGER, # KM2 value is 1. KM3 value is 2. KM4 value is 3.
  attestationSecurityLevel   SecurityLevel,
  keymasterVersion           INTEGER,
  keymasterSecurityLevel     SecurityLevel,
  attestationChallenge       OCTET_STRING,
  uniqueId                   OCTET_STRING,
  softwareEnforced           AuthorizationList,
  teeEnforced                AuthorizationList,
}

SecurityLevel ::= ENUMERATED {
  Software                   (0),
  TrustedEnvironment         (1),
  StrongBox                  (2),
}

AuthorizationList ::= SEQUENCE {
  purpose                     [1] EXPLICIT SET OF INTEGER OPTIONAL,
  algorithm                   [2] EXPLICIT INTEGER OPTIONAL,
  keySize                     [3] EXPLICIT INTEGER OPTIONAL.
  digest                      [5] EXPLICIT SET OF INTEGER OPTIONAL,
  padding                     [6] EXPLICIT SET OF INTEGER OPTIONAL,
  ecCurve                     [10] EXPLICIT INTEGER OPTIONAL,
  rsaPublicExponent           [200] EXPLICIT INTEGER OPTIONAL,
  rollbackResistance          [303] EXPLICIT NULL OPTIONAL, # KM4
  activeDateTime              [400] EXPLICIT INTEGER OPTIONAL
  originationExpireDateTime   [401] EXPLICIT INTEGER OPTIONAL
  usageExpireDateTime         [402] EXPLICIT INTEGER OPTIONAL
  noAuthRequired              [503] EXPLICIT NULL OPTIONAL,
  userAuthType                [504] EXPLICIT INTEGER OPTIONAL,
  authTimeout                 [505] EXPLICIT INTEGER OPTIONAL,
  allowWhileOnBody            [506] EXPLICIT NULL OPTIONAL,
  trustedUserPresenceRequired [507] EXPLICIT NULL OPTIONAL, # KM4
  trustedConfirmationRequired [508] EXPLICIT NULL OPTIONAL, # KM4
  unlockedDeviceRequired      [509] EXPLICIT NULL OPTIONAL, # KM4
  allApplications             [600] EXPLICIT NULL OPTIONAL,
  creationDateTime            [701] EXPLICIT INTEGER OPTIONAL,
  origin                      [702] EXPLICIT INTEGER OPTIONAL,
  rollbackResistant           [703] EXPLICIT NULL OPTIONAL, # KM2 and KM3 only.
  rootOfTrust                 [704] EXPLICIT RootOfTrust OPTIONAL,
  osVersion                   [705] EXPLICIT INTEGER OPTIONAL,
  osPatchLevel                [706] EXPLICIT INTEGER OPTIONAL,
  attestationApplicationId    [709] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdBrand          [710] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdDevice         [711] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdProduct        [712] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdSerial         [713] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdImei           [714] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdMeid           [715] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdManufacturer   [716] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdModel          [717] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  vendorPatchLevel            [718] EXPLICIT INTEGER OPTIONAL, # KM4
  bootPatchLevel              [719] EXPLICIT INTEGER OPTIONAL, # KM4
}

RootOfTrust ::= SEQUENCE {
  verifiedBootKey            OCTET_STRING,
  deviceLocked               BOOLEAN,
  verifiedBootState          VerifiedBootState,
  verifiedBootHash           OCTET_STRING, # KM4
}

VerifiedBootState ::= ENUMERATED {
  Verified                   (0),
  SelfSigned                 (1),
  Unverified                 (2),
  Failed                     (3),
}

Поля KeyDescription

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

Имя поля Тип Ценить
attestationVersion ЦЕЛОЕ ЧИСЛО Версия схемы аттестации: 1, 2 или 3.
attestationSecurity Уровень безопасности Уровень безопасности этой аттестации. Можно получить программные подтверждения аппаратных ключей. Таким аттестациям нельзя доверять, если система Android скомпрометирована.
keymasterVersion ЦЕЛОЕ ЧИСЛО Версия устройства-мастера: 0, 1, 2, 3 или 4.
keymasterSecurity Уровень безопасности Уровень безопасности реализации мастера ключей.
attestationChallenge ОКТЕТ_STRING Значение Tag::ATTESTATION_CHALLENGE , указанное в запросе на аттестацию.
uniqueId ОКТЕТ_STRING Необязательный уникальный идентификатор, присутствует, если ключ имеет Tag::INCLUDE_UNIQUE_ID
softwareEnforced Список авторизации Необязательные авторизации мастера ключей, которые не применяются TEE, если таковые имеются.
teeEnforced Список авторизации Необязательно, авторизация Keymaster, обеспечиваемая TEE, если таковая имеется.

Поля списка авторизации

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

Подробную информацию о значениях каждого поля см. в файлах types.hal для Keymaster 3 и keymaster_defs.h для Keymaster 2 и ниже. Имена тегов Keymaster были преобразованы в имена полей путем исключения префикса KM_TAG и изменения остатка на верблюжий регистр, поэтому Tag::KEY_SIZE стал keySize .

Поля RootOfTrust

Поля RootOfTrust идентифицируются позиционно.

Имя поля Тип Ценить
verifiedBootKey ОКТЕТ_STRING Безопасный хэш ключа, используемый для проверки образа системы. Рекомендуется SHA-256.
deviceLocked БУЛЕВОЕ значение True, если загрузчик заблокирован, что означает, что можно прошивать только подписанные образы и выполняется проверенная проверка загрузки.
verifiedBootState ПровереноBootState Состояние проверенной загрузки.
verifiedBootHash ОКТЕТ_STRING Дайджест всех данных, защищенных проверенной загрузкой. Для устройств, использующих реализацию Verified Boot Android Verified Boot, это значение содержит дайджест структуры VBMeta или структуру метаданных Verified Boot. Чтобы узнать больше о том, как вычислить это значение, см.Дайджест VBMeta.

Значения проверенногобутстате

Значения verifiedBootState имеют следующие значения:

Ценить Значение
Verified Указывает полную цепочку доверия, простирающуюся от загрузчика до проверенных разделов, включая загрузчик, загрузочный раздел и все проверенные разделы.
В этом состоянии значение verifiedBootKey представляет собой хеш встроенного сертификата, то есть неизменяемый сертификат, записанный в ПЗУ.
Это состояние соответствует зеленому состоянию загрузки, как описано в проверенной документации по потоку загрузки .
SelfSigned Указывает, что загрузочный раздел проверен с помощью встроенного сертификата и подпись действительна. Загрузчик отображает предупреждение и отпечаток открытого ключа, прежде чем продолжить процесс загрузки.
В этом состоянии значение verifiedBootKey представляет собой хэш самозаверяющего сертификата.
Это состояние соответствует желтому состоянию загрузки, как описано в проверенной документации по потоку загрузки .
Unverified Указывает, что устройство можно свободно модифицировать. Целостность устройства предоставляется пользователю для проверки внеполосного доступа. Загрузчик отображает предупреждение пользователю, прежде чем разрешить продолжить процесс загрузки.
В этом состоянии значение verifiedBootKey пусто.
Это состояние соответствует оранжевому состоянию загрузки, как описано в проверенной документации по потоку загрузки .
Failed Указывает, что устройство не прошло проверку. Ни один сертификат аттестации на самом деле не содержит этого значения, поскольку в этом состоянии загрузчик останавливается. Он включен сюда для полноты картины.
Это состояние соответствует красному состоянию загрузки, как описано в проверенной документации по потоку загрузки .

Значения уровня безопасности

Значения securityLevel имеют следующие значения:

Ценить Значение
Software Код, который создает соответствующий элемент (аттестацию или ключ) или управляет им, реализован в системе Android и может быть изменен в случае взлома этой системы.
TrustedEnvironment Код, который создает соответствующий элемент (аттестацию или ключ) или управляет им, реализуется в доверенной среде выполнения (TEE). Его можно изменить, если TEE скомпрометирован, но TEE очень устойчив к удаленному взлому и умеренно устойчив к компрометации путем прямой аппаратной атаки.
StrongBox Код, который создает соответствующий элемент (аттестацию или ключ) или управляет им, реализован в специальном аппаратном модуле безопасности. Его можно изменить, если аппаратный модуль безопасности скомпрометирован, но он очень устойчив к удаленному взлому и очень устойчив к взлому путем прямой аппаратной атаки.

Уникальный идентификатор

Уникальный идентификатор — это 128-битное значение, которое идентифицирует устройство, но только в течение ограниченного периода времени. Значение рассчитывается с помощью:

HMAC_SHA256(T || C || R, HBK)

Где:

  • T — это «значение временного счетчика», вычисляемое путем деления значения Tag::CREATION_DATETIME на 2592000000 с отбрасыванием остатка. T меняется каждые 30 дней (2592000000 = 30*24*60*60*1000).
  • C — значение Tag::APPLICATION_ID
  • R равен 1, если Tag::RESET_SINCE_ID_ROTATION присутствует в параметре attest_params для вызова attest_key, или 0, если тег отсутствует.
  • HBK — это уникальный аппаратный секрет, известный Доверенной среде выполнения и никогда ею не раскрываемый. Секрет содержит не менее 128 бит энтропии и уникален для отдельного устройства (вероятностная уникальность приемлема, учитывая 128 бит энтропии). HBK должен быть получен из материала объединенного ключа через HMAC или AES_CMAC.

Усеките выходные данные HMAC_SHA256 до 128 бит.

Ключи и сертификаты аттестации

Два ключа, один RSA и один ECDSA, а также соответствующие цепочки сертификатов надежно хранятся в устройстве.

В Android 12 реализована функция удаленного предоставления ключей, а в Android 13 требуется, чтобы устройства реализовали ее. Remote Key Provisioning предоставляет устройствам в полевых условиях сертификаты аттестации ECDSA P256 для каждого приложения. Эти сертификаты имеют более короткий срок действия, чем сертификаты, предоставленные заводом-изготовителем.

Несколько IMEI

В Android 14 добавлена ​​поддержка нескольких IMEI в записи аттестации ключа Android. OEM-производители могут реализовать эту функцию, добавив тег KeyMint для второго IMEI. Все чаще устройства имеют несколько сотовых радиомодулей, и OEM-производители теперь могут поддерживать устройства с двумя IMEI.

OEM-производители должны иметь вторичный IMEI, если он присутствует на их устройствах, который должен быть предоставлен реализации KeyMint, чтобы эти реализации могли подтвердить его так же, как они подтверждают первый IMEI.

удостоверение личности

Android 8.0 включает дополнительную поддержку аттестации идентификатора для устройств с Keymaster 3. Аттестация идентификатора позволяет устройству предоставить подтверждение идентификаторов своего оборудования, таких как серийный номер или IMEI. Несмотря на то, что это необязательная функция, настоятельно рекомендуется, чтобы все реализации Keymaster 3 обеспечивали ее поддержку, поскольку возможность подтверждения личности устройства позволяет использовать такие варианты использования, как настоящая удаленная настройка без касания, более безопасными (поскольку удаленная сторона может быть уверена, что она обращается к правильному устройству, а не к устройству, подделывающему его личность).

Аттестация идентификатора работает путем создания копий идентификаторов оборудования устройства, к которым может получить доступ только доверенная среда выполнения (TEE) до того, как устройство покинет завод. Пользователь может разблокировать загрузчик устройства и изменить системное программное обеспечение и идентификаторы, сообщаемые платформами Android. Копиями идентификаторов, хранящихся в TEE, нельзя манипулировать таким образом, гарантируя, что аттестация идентификатора устройства подтверждает только исходные идентификаторы оборудования устройства, тем самым предотвращая попытки подделки.

Основная поверхность API для аттестации идентификаторов построена на основе существующего механизма аттестации ключей, представленного в Keymaster 2. При запросе сертификата аттестации для ключа, хранящегося в keymaster, вызывающая сторона может запросить включение идентификаторов оборудования устройства в метаданные сертификата аттестации. Если ключ хранится в TEE, сертификат связывается с известным корнем доверия. Получатель такого сертификата может убедиться, что сертификат и его содержимое, включая идентификаторы оборудования, были написаны TEE. Когда его просят включить идентификаторы оборудования в сертификат аттестации, TEE подтверждает только те идентификаторы, которые хранятся в его хранилище и заполняются на заводе.

Свойства хранения

Хранилище, в котором хранятся идентификаторы устройства, должно иметь следующие свойства:

  • Значения, полученные из исходных идентификаторов устройства, копируются в хранилище до того, как устройство покинет завод.
  • Метод destroyAttestationIds() может безвозвратно уничтожить эту копию данных, полученных из идентификатора. Безвозвратное уничтожение означает, что данные полностью удалены, поэтому ни сброс к заводским настройкам, ни любая другая процедура, выполняемая на устройстве, не может их восстановить. Это особенно важно для устройств, на которых пользователь разблокировал загрузчик, изменил системное программное обеспечение и изменил идентификаторы, возвращаемые платформами Android.
  • Средства RMA должны иметь возможность генерировать свежие копии данных, полученных из идентификатора оборудования. Таким образом, устройство, прошедшее через RMA, может снова выполнить аттестацию идентификатора. Механизм, используемый средствами RMA, должен быть защищен таким образом, чтобы пользователи не могли вызвать его самостоятельно, поскольку это позволило бы им получить подтверждения поддельных идентификаторов.
  • Никакой код, кроме доверенного приложения Keymaster в TEE, не может читать данные, полученные из идентификатора, хранящиеся в хранилище.
  • Хранилище защищено от несанкционированного доступа: если содержимое хранилища было изменено, TEE рассматривает его так же, как если бы копии содержимого были уничтожены, и отклоняет все попытки подтверждения идентификатора. Это реализуется путем подписания или MAC-адреса хранилища , как описано ниже .
  • В хранилище не хранятся исходные идентификаторы. Поскольку аттестация идентификатора требует проверки, вызывающая сторона всегда предоставляет идентификаторы, подлежащие аттестации. TEE необходимо только убедиться, что они соответствуют исходным значениям. Хранение безопасных хэшей исходных значений, а не самих значений, обеспечивает такую ​​проверку.

Строительство

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

S = D || HMAC(HBK, D)

где:

  • D = HMAC(HBK, ID 1 ) || HMAC(HBK, ID 2 ) || ... || HMAC(HBK, ID n )
  • HMAC — это конструкция HMAC с соответствующим безопасным хешем (рекомендуется SHA-256).
  • HBK — это аппаратно-привязанный ключ, не используемый для каких-либо других целей.
  • ID 1 ...ID n — исходные значения идентификатора; привязка определенного значения к определенному индексу зависит от реализации, поскольку разные устройства имеют разное количество идентификаторов
  • || представляет собой конкатенацию

Поскольку выходные данные HMAC имеют фиксированный размер, для поиска отдельных хэшей идентификаторов или HMAC D не требуются заголовки или другая структура. Помимо проверки предоставленных значений для выполнения аттестации, реализациям необходимо проверять S путем извлечения D из S. , вычисляя HMAC(HBK, D) и сравнивая его со значением в S, чтобы убедиться, что никакие отдельные идентификаторы не были изменены/повреждены. Кроме того, реализации должны использовать сравнения с постоянным временем для всех отдельных элементов идентификатора и проверку S. Время сравнения должно быть постоянным независимо от количества предоставленных идентификаторов и правильного соответствия любой части теста.

Идентификаторы оборудования

Аттестация идентификатора поддерживает следующие идентификаторы оборудования:

  1. Название бренда, возвращаемое Build.BRAND в Android.
  2. Имя устройства, возвращаемое Build.DEVICE в Android.
  3. Название продукта, возвращаемое Build.PRODUCT в Android.
  4. Имя производителя, возвращаемое Build.MANUFACTURER в Android.
  5. Имя модели, возвращаемое Build.MODEL в Android.
  6. Серийный номер
  7. IMEI всех радиостанций
  8. MEID всех радиостанций

Для поддержки подтверждения идентификатора устройства устройство подтверждает эти идентификаторы. Все устройства под управлением Android имеют первые шесть, и они необходимы для работы этой функции. Если устройство оснащено встроенными сотовыми радиомодулями, оно также должно поддерживать аттестацию номеров IMEI и/или MEID радиомодулей.

Подтверждение идентификатора запрашивается путем выполнения ключевого подтверждения и включения идентификаторов устройств для подтверждения в запрос. Идентификаторы помечены как:

  • ATTESTATION_ID_BRAND
  • ATTESTATION_ID_DEVICE
  • ATTESTATION_ID_PRODUCT
  • ATTESTATION_ID_MANUFACTURER
  • ATTESTATION_ID_MODEL
  • ATTESTATION_ID_SERIAL
  • ATTESTATION_ID_IMEI
  • ATTESTATION_ID_MEID

Подтверждаемый идентификатор представляет собой строку байтов в кодировке UTF-8. Этот формат также применим к числовым идентификаторам. Каждый идентификатор, подлежащий подтверждению, выражается в виде строки в кодировке UTF-8.

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

Если устройство поддерживает аттестацию идентификатора и один или несколько из вышеуказанных тегов были включены в запрос на аттестацию ключа, TEE проверяет, что идентификатор, предоставленный с каждым из тегов, соответствует его копии идентификаторов оборудования. Если один или несколько идентификаторов не совпадают, вся аттестация завершается с ErrorCode::CANNOT_ATTEST_IDS . Один и тот же тег может быть указан несколько раз. Это может быть полезно, например, при проверке IMEI: устройство может иметь несколько радиомодулей с несколькими IMEI. Запрос на подтверждение действителен, если значение, указанное в каждом ATTESTATION_ID_IMEI соответствует одному из радиомодулей устройства. То же самое относится и ко всем остальным тегам.

Если аттестация прошла успешно, аттестованные идентификаторы добавляются к расширению аттестации (OID 1.3.6.1.4.1.11129.2.1.17) выданного сертификата аттестации, используя приведенную выше схему . Изменения в схеме аттестации Keymaster 2 выделены жирным шрифтом и сопровождаются комментариями.

Java API

Этот раздел носит исключительно информационный характер. Разработчики Keymaster не реализуют и не используют Java API. Это сделано для того, чтобы помочь разработчикам понять, как эта функция используется приложениями. Компоненты системы могут использовать его по-разному, поэтому крайне важно, чтобы этот раздел не рассматривался как нормативный.