키 및 ID 증명

컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

키 저장소는 제어된 방식으로 암호화 키를 생성, 저장 및 사용할 수 있는 보다 안전한 장소를 제공합니다. 하드웨어 지원 키 저장소를 사용할 수 있고 사용하는 경우 키 자료는 기기에서 추출되지 않도록 더 안전하며 Keymaster는 파괴하기 어려운 제한을 적용합니다.

그러나 이는 키 저장소 키가 하드웨어 지원 스토리지에 있는 것으로 알려진 경우에만 해당됩니다. Keymaster 1에서는 앱이나 원격 서버에서 이것이 사실인지 확실하게 확인할 방법이 없었습니다. 키 저장소 데몬은 사용 가능한 키 마스터 HAL을 로드하고 키의 하드웨어 지원과 관련하여 HAL이 말한 모든 것을 믿었습니다.

이를 해결하기 위해 Keymaster는 Android 7.0(Keymaster 2)의키 증명 과 Android 8.0(Keymaster 3)의 ID 증명을 도입했습니다.

키 증명은 비대칭 키 쌍이 하드웨어 지원인지, 키 속성이 무엇인지, 사용에 적용되는 제약 조건이 무엇인지 강력하게 결정하는 방법을 제공하는 것을 목표로 합니다.

ID 증명을 통해 장치는 일련 번호 또는 IMEI와 같은 하드웨어 식별자의 증거를 제공할 수 있습니다.

주요 증명

키 증명을 지원하기 위해 Android 7.1에서는 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 에서 반환된 키 blob입니다.
  • attestParams 는 증명에 필요한 매개변수 목록입니다. 여기에는 Tag::ATTESTATION_CHALLENGE 및 가능한 경우 Tag::RESET_SINCE_ID_ROTATION 뿐만 아니라 Tag::APPLICATION_IDTag::APPLICATION_DATA 가 포함됩니다. 후자의 두 개는 키 생성 중에 지정된 경우 키 Blob을 해독하는 데 필요합니다.
  • certChain 은 인증서 배열을 반환하는 출력 매개변수입니다. 항목 0은 증명 인증서입니다. 즉, keyToAttest 의 키를 인증하고 증명 확장을 포함합니다.

attestKey 메서드는 언제든지 호출할 수 있고 인증 제약 조건을 충족할 필요가 없기 때문에 증명된 키에 대한 공개 키 작업으로 간주됩니다. 예를 들어 증명된 키를 사용하기 위해 사용자 인증이 필요한 경우 사용자 인증 없이 증명을 생성할 수 있습니다.

공증 인증서

증명 인증서는 표준 X.509 인증서이며 증명된 키에 대한 설명이 포함된 선택적 증명 확장이 있습니다. 인증서는 증명되는 키와 동일한 알고리즘을 사용하는 공장에서 프로비저닝된 증명 키로 서명됩니다(RSA의 경우 RSA, EC의 경우 EC).

증명 인증서는 아래 표의 필드를 포함하며 추가 필드를 포함할 수 없습니다. 일부 필드는 고정 필드 값을 지정합니다. CTS 테스트는 인증서 콘텐츠가 정의된 대로 정확히 맞는지 확인합니다.

인증서 시퀀스

필드 이름( RFC 5280 참조)
tbs인증서 TBS인증서 시퀀스
서명 알고리즘 키 서명에 사용되는 알고리즘의 AlgorithmIdentifier:
EC 키용 ECDSA, RSA 키용 RSA.
서명값 BIT STRING, ASN.1 DER로 인코딩된 tbsCertificate에서 계산된 서명.

TBS인증서 시퀀스

필드 이름( RFC 5280 참조)
version INTEGER 2(v3 인증서를 의미)
serialNumber INTEGER 1(고정 값: 모든 인증서에서 동일)
signature 키 서명에 사용되는 알고리즘의 AlgorithmIdentifier: EC 키의 경우 ECDSA, RSA 키의 경우 RSA.
issuer 배치 증명 키의 제목 필드와 동일합니다.
validity Tag::ACTIVE_DATETIMETag:: USAGE_EXPIRE_DATETIME 값을 포함하는 두 날짜의 SEQUENCE 이러한 값은 1970년 1월 1일 이후의 밀리초 단위입니다. 인증서의 정확한 날짜 표현은 RFC 5280 을 참조하십시오.
Tag::ACTIVE_DATETIME 이 없으면 Tag::CREATION_DATETIME 값을 사용합니다. Tag::USAGE_EXPIRE_DATETIME 이 없으면 배치 증명 키 인증서의 만료 날짜를 사용합니다.
subject CN = "Android Keystore Key"(고정 값: 모든 인증서에서 동일)
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 인증서 확장과 마찬가지로 콘텐츠는 증명 SEQUENCE의 DER 인코딩을 포함하는 OCTET_STRING으로 표시됩니다.

증명 확장

attestation 확장 프로그램에는 Android 및 keymaster HAL에서 사용되는 승인 목록에 직접 해당하는 구조로 키와 연결된 keymaster 승인에 대한 전체 설명이 포함되어 있습니다. 인증 목록의 각 태그는 ASN.1 SEQUENCE 항목으로 표시되며 keymaster 태그 번호로 명시적으로 태그가 지정되지만 유형 설명자(4개의 상위 비트)는 가려집니다.

예를 들어 Keymaster 3에서 Tag::PURPOSE 는 types.hal에서 ENUM_REP | 1 . 증명 확장의 경우 ENUM_REP 값이 제거되고 태그 1 이 남습니다. (Keymaster 2 이하의 경우 KM_TAG_PURPOSE 는 keymaster_defs.h에 정의되어 있습니다.)

값은 다음 표에 따라 ASN.1 유형으로 직접 변환됩니다.

키마스터 유형 ASN.1 유형
ENUM 정수
ENUM_REP 정수 세트
UINT 정수
UINT_REP 정수 세트
ULONG 정수
ULONG_REP 정수 세트
DATE INTEGER(1970년 1월 1일 00:00:00 GMT 이후 밀리초)
BOOL NULL(keymaster에서 태그 존재는 true를 의미하고 부재는 false를 의미합니다.
동일한 의미 체계가 ASN.1 인코딩에 적용됨)
BIGNUM 현재 사용되지 않으므로 정의된 매핑이 없습니다.
BYTES OCTET_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,
  applicationId               [601] EXPLICIT OCTET_STRING 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),
}

키 설명 필드

keymasterVersionattestationChallenge 필드는 태그가 아니라 위치적으로 식별되므로 인코딩된 양식의 태그는 필드 유형만 지정합니다. 나머지 필드는 스키마에 지정된 대로 암시적으로 태그가 지정됩니다.

분야 명 유형
attestationVersion 정수 증명 스키마 버전: 1, 2 또는 3.
attestationSecurity 보안 수준 이 증명의 보안 수준입니다. 하드웨어 지원 키의 소프트웨어 증명을 가져올 수 있습니다. Android 시스템이 손상된 경우 이러한 증명을 신뢰할 수 없습니다.
keymasterVersion 정수 Keymaster 기기의 버전: 0, 1, 2, 3 또는 4.
keymasterSecurity 보안 수준 keymaster 구현의 보안 수준입니다.
attestationChallenge OCTET_STRING 증명 요청에 지정된 Tag::ATTESTATION_CHALLENGE 값.
uniqueId OCTET_STRING 선택적 고유 ID, 키에 Tag::INCLUDE_UNIQUE_ID 가 있는 경우 존재
softwareEnforced 인증 목록 TEE에서 시행하지 않는 keymaster 인증(있는 경우)입니다.
teeEnforced 인증 목록 TEE에서 시행하는 Keymaster 승인(있는 경우)입니다.

AuthorizationList 필드

AuthorizationList 필드는 모두 선택 사항이며 유형 비트가 가려진 keymaster 태그 값으로 식별됩니다. 명시적 태깅이 사용되므로 더 쉽게 구문 분석할 수 있도록 필드에 ASN.1 유형을 나타내는 태그도 포함됩니다.

각 필드 값에 대한 자세한 내용은 types.hal 3의 경우 types.hal, Keymaster 2 이하의 경우 keymaster_defs.h 를 참조하세요. Keymaster 태그 이름은 KM_TAG 접두어를 생략하고 나머지를 카멜 표기법으로 변경하여 필드 이름으로 변환되었으므로 Tag::KEY_SIZEkeySize 가 되었습니다.

RootOfTrust 필드

RootOfTrust 필드는 위치에 따라 식별됩니다.

분야 명 유형
verifiedBootKey OCTET_STRING 시스템 이미지를 확인하는 데 사용되는 키의 보안 해시입니다. SHA-256 권장.
deviceLocked 부울 부트로더가 잠긴 경우 True입니다. 즉, 서명된 이미지만 플래싱할 수 있고 검증된 부팅 검사가 수행됩니다.
verifiedBootState VerifiedBootState 검증 부팅 상태.
verifiedBootHash OCTET_STRING 자체 검사 부팅으로 보호되는 모든 데이터의 다이제스트입니다. 자체 검사 부팅의 Android 자체 검사 부팅 구현을 사용하는 기기의 경우 이 값에는 VBMeta 구조체 의 다이제스트 또는 자체 검사 부팅 메타데이터 구조가 포함됩니다. 이 값을 계산하는 방법에 대한 자세한 내용은 The VBMeta Digest 를 참조하세요.

VerifiedBootState 값

verifiedBootState 의 값은 다음과 같은 의미를 갖습니다.

의미
Verified 부트로더, 부트 파티션 및 모든 확인된 파티션을 포함하여 부트로더에서 확인된 파티션으로 확장되는 전체 신뢰 체인을 나타냅니다.
이 상태에서 verifiedBootKey 값은 포함된 인증서의 해시이며, 이는 변경할 수 없는 인증서가 ROM에 기록되었음을 의미합니다.
이 상태는 검증된 부팅 흐름 문서에 설명된 녹색 부팅 상태에 해당합니다.
SelfSigned 포함된 인증서를 사용하여 부팅 파티션이 확인되었고 서명이 유효함을 나타냅니다. 부트로더는 부팅 프로세스를 계속하기 전에 공개 키의 지문과 경고를 표시합니다.
이 상태에서 verifiedBootKey 값은 자체 서명 인증서의 해시입니다.
이 상태는 검증된 부팅 흐름 설명서에 설명된 노란색 부팅 상태에 해당합니다.
Unverified 장치를 자유롭게 수정할 수 있음을 나타냅니다. 장치 무결성은 대역 외 확인을 위해 사용자에게 맡겨집니다. 부트로더는 부팅 프로세스를 계속하기 전에 사용자에게 경고를 표시합니다.
이 상태에서 verifiedBootKey 값은 비어 있습니다.
이 상태는 검증된 부팅 흐름 설명서에 설명된 주황색 부팅 상태에 해당합니다.
Failed 장치가 확인에 실패했음을 나타냅니다. 이 상태에서 부트로더가 중지되기 때문에 실제로 이 값을 포함하는 증명 인증서는 없습니다. 완전성을 위해 여기에 포함되었습니다.
이 상태는 검증된 부팅 흐름 문서에 설명된 빨간색 부팅 상태에 해당합니다.

SecurityLevel 값

securityLevel 의 값은 다음과 같은 의미를 갖습니다.

의미
Software 관련 요소(증명 또는 키)를 생성하거나 관리하는 코드는 Android 시스템에서 구현되며 해당 시스템이 손상될 경우 변경될 수 있습니다.
TrustedEnvironment 관련 요소(증명 또는 키)를 생성하거나 관리하는 코드는 TEE(Trusted Execution Environment)에서 구현됩니다. TEE가 손상되면 변경될 수 있지만 TEE는 원격 손상에 대한 내성이 강하고 직접적인 하드웨어 공격에 의한 손상에 어느 정도 저항합니다.
StrongBox 관련 요소(증명 또는 키)를 생성하거나 관리하는 코드는 전용 하드웨어 보안 모듈에서 구현됩니다. 하드웨어 보안 모듈이 손상되면 변경될 수 있지만 원격 손상에 매우 강하고 직접 하드웨어 공격에 대한 손상에 매우 강합니다.

고유 ID

고유 ID는 장치를 식별하는 128비트 값이지만 제한된 기간 동안만 가능합니다. 값은 다음과 같이 계산됩니다.

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

어디에:

  • TTag::CREATION_DATETIME 의 값을 2592000000으로 나누고 나머지는 삭제하여 계산한 "임시 카운터 값"입니다. T 는 30일마다 변경됩니다(2592000000 = 30 * 24 * 60 * 60 * 1000).
  • CTag::APPLICATION_ID 의 값입니다.
  • RTag::RESET_SINCE_ID_ROTATION 이 attest_key 호출에 대한 attest_params 매개변수에 있으면 1이고, 태그가 없으면 0입니다.
  • HBK 는 Trusted Execution Environment에 알려지고 절대 공개되지 않는 고유한 하드웨어 바인딩 비밀입니다. 암호에는 최소 128비트의 엔트로피가 포함되어 있으며 개별 장치에 고유합니다(128비트의 엔트로피가 주어지면 확률적 고유성이 허용됨). HBK는 HMAC 또는 AES_CMAC를 통해 융합된 키 자료에서 파생되어야 합니다.

HMAC_SHA256 출력을 128비트로 자릅니다.

증명 키 및 인증서

2개의 키(RSA 1개, ECDSA 1개)와 해당 인증서 체인이 장치에 안전하게 프로비저닝됩니다.

신분증 증명

Android 8.0에는 Keymaster 3가 있는 기기에 대한 ID 증명에 대한 선택적 지원이 포함됩니다. ID 증명을 통해 기기는 일련 번호 또는 IMEI와 같은 하드웨어 식별자의 증거를 제공할 수 있습니다. 선택적 기능이지만 모든 Keymaster 3 구현에서 이를 지원하는 것이 좋습니다. 기기의 ID를 증명할 수 있으면 진정한 제로 터치 원격 구성과 같은 사용 사례를 더 안전하게 할 수 있기 때문입니다(원격 측에서 이를 확신할 수 있기 때문). 신원을 속이는 장치가 아니라 올바른 장치와 통신하고 있음).

ID 증명은 장치가 공장에서 출고되기 전에 TEE(Trusted Execution Environment)만 액세스할 수 있는 장치의 하드웨어 식별자 사본을 생성하여 작동합니다. 사용자는 기기의 부트로더를 잠금 해제하고 시스템 소프트웨어와 Android 프레임워크에서 보고하는 식별자를 변경할 수 있습니다. TEE가 보유한 식별자의 사본은 이러한 방식으로 조작할 수 없으므로 장치 ID 증명이 장치의 원래 하드웨어 식별자만 증명하도록 하여 스푸핑 시도를 차단합니다.

ID 증명을 위한 기본 API 표면은 Keymaster 2에 도입된 기존 키 증명 메커니즘 위에 구축됩니다. keymaster가 보유한 키에 대한 증명 인증서를 요청할 때 호출자는 기기의 하드웨어 식별자가 증명 인증서의 메타데이터에 포함되도록 요청할 수 있습니다. 키가 TEE에 있는 경우 인증서는 알려진 신뢰 루트로 다시 연결됩니다. 이러한 인증서의 수신자는 하드웨어 식별자를 포함하여 인증서와 그 내용이 TEE에서 작성되었음을 확인할 수 있습니다. 증명 인증서에 하드웨어 식별자를 포함하라는 요청을 받으면 TEE는 공장 바닥에 채워진 대로 저장소에 보관된 식별자만 증명합니다.

스토리지 속성

장치의 식별자를 보관하는 저장소에는 다음 속성이 있어야 합니다.

  • 장치의 원래 식별자에서 파생된 값은 장치가 공장에서 출고되기 전에 저장소에 복사됩니다.
  • destroyAttestationIds() 메서드는 식별자 파생 데이터의 이 복사본을 영구적으로 삭제할 수 있습니다. 영구 파기는 데이터가 완전히 제거되어 공장 초기화나 장치에서 수행되는 다른 절차로 복원할 수 없음을 의미합니다. 이는 사용자가 부트로더를 잠금 해제하고 시스템 소프트웨어를 변경하고 Android 프레임워크에서 반환된 식별자를 수정한 기기에 특히 중요합니다.
  • RMA 시설은 하드웨어 식별자에서 파생된 데이터의 새로운 복사본을 생성할 수 있어야 합니다. 이렇게 하면 RMA를 통과한 기기에서 ID 증명을 다시 수행할 수 있습니다. RMA 시설에서 사용하는 메커니즘은 사용자가 스푸핑된 ID의 증명을 얻을 수 있도록 사용자가 직접 호출할 수 없도록 보호되어야 합니다.
  • TEE의 Keymaster 신뢰할 수 있는 앱 이외의 코드는 저장소에 보관된 식별자 파생 데이터를 읽을 수 없습니다.
  • 저장소의 변조 방지: 저장소의 콘텐츠가 수정된 경우 TEE는 콘텐츠의 복사본이 파기된 것처럼 이를 취급하고 모든 ID 증명 시도를 거부합니다. 이는 아래에 설명된 대로 스토리지에 서명하거나 MACing하여 구현됩니다.
  • 저장소에는 원래 식별자가 없습니다. ID 증명에는 챌린지가 포함되므로 호출자는 항상 증명할 식별자를 제공합니다. TEE는 이들이 원래 가지고 있던 값과 일치하는지 확인하기만 하면 됩니다. 값이 아닌 원래 값의 보안 해시를 저장하면 이 확인이 가능합니다.

건설

위에 나열된 속성이 있는 구현을 만들려면 다음 구조 S에 ID 파생 값을 저장합니다. 기기 소유자가 루팅을 통해 수정할 수 있는 시스템의 일반적인 위치를 제외하고 ID 값의 다른 복사본을 저장하지 마십시오.

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 은 원래 ID 값입니다. 특정 인덱스에 대한 특정 값의 연관은 구현에 따라 다릅니다. 다른 장치는 다른 수의 식별자를 갖기 때문입니다.
  • || 연결을 나타냅니다

HMAC 출력은 크기가 고정되어 있으므로 개별 ID 해시 또는 D의 HMAC를 찾기 위해 헤더나 기타 구조가 필요하지 않습니다. 증명을 수행하기 위해 제공된 값을 확인하는 것 외에도 구현 시 S에서 D를 추출하여 S를 검증해야 합니다. , HMAC(HBK, D)를 계산하고 이를 S의 값과 비교하여 개별 ID가 수정/손상되지 않았는지 확인합니다. 또한 구현 시 모든 개별 ID 요소와 S의 유효성 검사에 대해 상수 시간 비교를 사용해야 합니다. 비교 시간은 제공된 ID 수와 테스트의 모든 부분이 정확히 일치하는지에 관계없이 일정해야 합니다.

하드웨어 식별자

ID 증명은 다음 하드웨어 식별자를 지원합니다.

  1. Android의 Build.BRAND 에서 반환한 브랜드 이름
  2. Android의 Build.DEVICE 에서 반환한 기기 이름
  3. Android의 Build.PRODUCT 에서 반환한 제품 이름
  4. 제조업체 이름(Android의 Build.MANUFACTURER 에서 반환됨)
  5. Android의 Build.MODEL 에서 반환된 모델 이름
  6. 일련 번호
  7. 모든 라디오의 IMEI
  8. 모든 라디오의 MEID

장치 ID 증명을 지원하기 위해 장치는 이러한 식별자를 증명합니다. Android를 실행하는 모든 기기에는 처음 6개가 있으며 이 기능이 작동하는 데 필요합니다. 장치에 통합 셀룰러 무선이 있는 경우 장치는 무선의 IMEI 및/또는 MEID에 대한 증명도 지원해야 합니다.

ID 증명은 키 증명을 수행하고 증명할 장치 식별자를 요청에 포함하여 요청됩니다. 식별자는 다음과 같이 태그가 지정됩니다.

  • 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 인코딩 문자열로 표현됩니다.

기기가 ID 증명을 지원하지 않는 경우(또는 destroyAttestationIds() 가 이전에 호출되었고 기기가 더 이상 해당 ID를 증명할 수 없는 경우) 이러한 태그 중 하나 이상을 포함하는 키 증명 요청은 ErrorCode::CANNOT_ATTEST_IDS 와 함께 실패합니다.

장치가 ID 증명을 지원하고 위의 태그 중 하나 이상이 키 증명 요청에 포함된 경우 TEE는 각 태그와 함께 제공된 식별자가 하드웨어 식별자 사본과 일치하는지 확인합니다. 하나 이상의 식별자가 일치하지 않으면 전체 증명이 ErrorCode::CANNOT_ATTEST_IDS 와 함께 실패합니다. 동일한 태그가 여러 번 제공되는 것은 유효합니다. 이는 예를 들어 IMEI를 증명할 때 유용할 수 있습니다. 장치에는 여러 IMEI가 있는 여러 무선 장치가 있을 수 있습니다. 증명 요청은 각 ATTESTATION_ID_IMEI 와 함께 제공된 값이 장치의 라디오 중 하나와 일치하는 경우 유효합니다. 다른 모든 태그에도 동일하게 적용됩니다.

증명에 성공하면 위의 스키마를 사용하여 증명된 ID가 발급된 증명 인증서의 증명 확장 (OID 1.3.6.1.4.1.11129.2.1.17)에 추가됩니다. Keymaster 2 증명 스키마의 변경사항은 주석과 함께 굵게 표시 됩니다.

자바 API

이 섹션은 정보 제공용입니다. Keymaster 구현자는 Java API를 구현하거나 사용하지 않습니다. 이는 구현자가 애플리케이션에서 기능을 사용하는 방법을 이해하는 데 도움이 되도록 제공됩니다. 시스템 구성 요소는 이를 다르게 사용할 수 있으므로 이 섹션을 표준으로 취급하지 않는 것이 중요합니다.