鍵構成証明と ID 構成証明

キーストアは、暗号鍵の作成、保存、使用を適切に制御できる安全な場所を提供します。ハードウェア格納型の鍵ストレージが利用可能で実際に使用されている場合、鍵マテリアルがデバイスから抽出される危険はより少なくなり、Keymaster が適用する制限を打ち破るのはより難しくなります。

ただし、それはキーストア鍵がハードウェア格納型ストレージ内にあることが認識される場合に限られます。Keymaster 1 では、そのような状態をアプリまたはリモート サーバーが確実に確認する方法はありませんでした。キーストア デーモンは、利用可能な Keymaster 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 メソッド

Keymaster 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::APPLICATION_ID と Tag::APPLICATION_DATA に加えて Tag::ATTESTATION_CHALLENGE があり、Tag::RESET_SINCE_ID_ROTATION が含まれることもあります。最初の 2 つのパラメータは、鍵の生成時に指定された鍵 blob を復号するために必要です。
• certChain は、証明書の配列を返す出力パラメータです。エントリ 0 は構成証明書です。構成証明書とは、構成証明拡張を含む、keyToAttest の鍵の証明書です。

attestKey メソッドは、いつでも呼び出すことができ、承認の制約を満たす必要がないため、証明済みの鍵に対する公開鍵オペレーションと見なされます。たとえば、証明済みの鍵の使用にユーザー認証が必要な場合、ユーザー認証なしで構成証明を生成できます。

構成証明書

構成証明書は標準の X.509 証明書であり、証明済みの鍵の説明を含む構成証明拡張がオプションとしてあります。証明書は、認定済みの構成証明鍵で署名されます。この鍵は、証明対象の鍵とは異なるアルゴリズムを使用する場合があります。

構成証明書には、下記の表のフィールドが含まれます。フィールドを追加することはできません。一部のフィールドには、固定フィールド値が指定されています。CTS テストでは、証明書の内容が正確に定義どおりであるかどうかが検証されます。

Certificate SEQUENCE

TBSCertificate SEQUENCE

構成証明拡張

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 スキーマによって記述されます。

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),
}

KeyDescription フィールド

keymasterVersion および attestationChallenge フィールドはタグではなく位置によって識別されるため、エンコードされたフォームのタグはフィールド型のみを規定します。残りのフィールドは、スキーマの規定に従って暗黙的にタグ付けされます。

AuthorizationList フィールド

AuthorizationList フィールドはすべてオプションです。Keymaster タグ値で識別され、型ビットはマスクされます。明示的なタグ付けが使用されるため、フィールドには ASN.1 型を示すタグも含まれます。これにより解析が容易になります。

各フィールドの値の詳細については、Keymaster 3 の場合は types.hal、Keymaster 2 以下の場合は keymaster_defs.h をご覧ください。Keymaster タグ名のフィールド名への変換は、KM_TAG プレフィックスを削除し、残りの部分をキャメルケースに変更することによって行われます。つまり、Tag::KEY_SIZE は keySize に変換されます。

RootOfTrust フィールド

RootOfTrust フィールドは位置によって識別されます。

VerifiedBootState の値

verifiedBootState の値が持つ意味を次に示します。

SecurityLevel の値

securityLevel の値が持つ意味を次に示します。

一意の ID

一意の ID はデバイスを識別する 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 は、attest_key 呼び出しに対する attest_params パラメータに Tag::RESET_SINCE_ID_ROTATION が存在する場合は 1、このタグが存在しない場合は 0 です。
• HBK は、信頼できる実行環境が認識していて絶対に明かすことがない、ハードウェアにバインドされた一意のシークレットです。このシークレットは、少なくとも 128 ビットのエントロピーを含み、個々のデバイスに対して一意です（128 ビットのエントロピーがあれば確率的な一意性が満たされます）。HBK は、HMAC または AES_CMAC を使用して、融合された鍵マテリアルから生成する必要があります。

HMAC_SHA256 出力を切り捨てて 128 ビットにします。

構成証明の鍵と証明書

2 つの鍵（RSA と ECDSA）および対応する証明書チェーンは、セキュアな方法でデバイスにプロビジョニングされます。

Android 12 ではリモートキー プロビジョニングが導入され、Android 13 ではデバイスへの実装が必須になりました。リモートキー プロビジョニングにより、フィールドのデバイスに対し、アプリケーションごとに ECDSA P256 構成証明書が提供されます。これらの証明書は、工場出荷時にプロビジョニングされた証明書よりも有効期間が短くなります。

ID 構成証明

Android 8.0 では、Keymaster 3 を備えたデバイスの ID 構成証明をオプションでサポートしています。ID 構成証明を使用すると、デバイスはシリアル番号や IMEI などのハードウェア識別子の証明を提供できます。この機能はオプションであるとはいえ、すべての Keymaster 3 実装でサポートすることを強くおすすめします。これは、デバイスの身元証明ができるということは、真のゼロタッチ リモート構成などのユースケースのセキュリティを強化できることを意味するためです（リモート側は、なりすましデバイスではなく正当なデバイスと通信していることを確信できます）。

ID 構成証明は、デバイスの工場出荷前に、信頼できる実行環境（TEE）のみがアクセスできる、デバイスのハードウェア識別子のコピーを作成することによって、利用可能になります。ユーザーは、デバイスのブートローダーをロック解除して、Android フレームワークによって報告されるシステム ソフトウェアと識別子を変更できます。TEE が保持する識別子のコピーは、この方法では操作できません。つまり、デバイス ID 構成証明は、デバイスの元のハードウェア識別子のみを証明することで、なりすましの試みを阻止します。

ID 構成証明のメイン API サーフェスは、Keymaster 2 で導入された既存の鍵構成証明メカニズムを土台にして構築されています。Keymaster が保持する鍵の構成証明書をリクエストするとき、呼び出し元は、デバイスのハードウェア識別子が構成証明書のメタデータに含まれていることを要求できます。鍵が TEE によって保持されている場合、証明書チェーンは既知のルート オブ トラストまで遡ります。この証明書を受け取った側は、証明書とその内容（ハードウェア識別子を含む）が TEE によって作成されたことを確認できます。TEE は、構成証明書にハードウェア識別子を含めることを要求された場合、ストレージに保持されている、工場出荷前に設定された識別子のみを証明します。

ストレージの特性

デバイスの識別子を保持するストレージには、次のような特性が必要です。

• デバイスが工場から出荷される前に、デバイスの元の識別子から生成された値がストレージにコピーされること。
• destroyAttestationIds() メソッドを使用して、識別子から派生したデータのコピーを完全に破棄できること。「完全に破棄」とは、データを完全に削除し、デバイスを工場出荷時の状態にリセットしても、あるいはデバイス上で他のいかなる手順を実行してもそのデータを復元できないようにするという意味です。ユーザーがブートローダーをロック解除し、システム ソフトウェアを変更し、Android フレームワークが報告する識別子を変更したデバイスの場合、これは特に重要です。
• RMA 機能を使用して、ハードウェア識別子から派生したデータの新しいコピーを生成できること。それにより、RMA を通過するデバイスは ID 構成証明を再度実行できます。RMA 機能が使用するメカニズムは、ユーザー自身が呼び出せないように保護する必要があります。そうしないと、ユーザーがなりすまし ID の構成証明を取得する可能性があるためです。
• TEE 内の Keymaster TA（TA: 信頼できるアプリ）以外のコードが、ストレージに保存されている識別子派生データを読み取れないこと。
• ストレージが改ざん検出可能であること。ストレージのコンテンツが変更された場合、TEE はそのコンテンツのコピーが破棄された場合と同様に扱い、すべての ID 構成証明の試みを拒否すること。この仕組みは、ストレージに署名または MAC 化を行うことで実装します。下記の説明をご覧ください。
• ストレージが元の識別子を保持しないこと。ID 構成証明にはチャレンジが含まれるため、証明対象の識別子は常に呼び出し元が指定します。TEE は、指定された識別子が元の値と一致していることのみを検証する必要があります。値ではなく元の値のセキュア ハッシュを格納することで、この検証が可能になります。

コンストラクション

上記の特性を持つ実装を作成するには、ID から派生した値を次のコンストラクション S に格納します。ID 値の他のコピーをシステムの正規の場所以外に格納しないでください。デバイスのオーナーは、ルート権限の取得によってこの場所を変更できます。

S = D || HMAC(HBK, D)

ここで:

• D = HMAC(HBK, ID1) || HMAC(HBK, ID2) || ... || HMAC(HBK, IDn)
• HMAC は、適切なセキュア ハッシュ（SHA-256 が推奨されます）を使用した HMAC コンストラクションです。
• HBK は、他の目的で使用されていない、ハードウェアにバインドされた鍵です。
• ID1...IDn は元の 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 を証明できなくなった場合）、これらのタグを 1 つ以上含む鍵構成証明リクエストは ErrorCode::CANNOT_ATTEST_IDS で失敗します。

デバイスが ID 構成証明をサポートしており、上記のタグが 1 つ以上鍵構成証明リクエストに含まれている場合、TEE は、各タグで指定された識別子がハードウェア識別子のコピーと一致するかどうかを検証します。1 つ以上の識別子が一致しない場合、構成証明全体が ErrorCode::CANNOT_ATTEST_IDS で失敗します。同じタグを複数回指定するのは有効です。これは、デバイスの無線通信に複数の IMEI がある場合に IMEI を証明するときなどに役立ちます。個々の ATTESTATION_ID_IMEI で指定された値がデバイスの無線通信の 1 つと一致すれば、構成証明リクエストは有効です。他のすべてのタグについても同様です。

構成証明が成功すると、証明された ID は、上記のスキーマを使用して、発行される構成証書の構成証明拡張（OID 1.3.6.1.4.1.11129.2.1.17）に追加されます。Keymaster 2 の構成証明スキーマの変更点は、コメント付きで太字で表示されています。

Java API

このセクションは、情報提供のみを目的としています。Keymaster の実装者は、Java API を実装することも使用することもありません。下記の説明は、アプリがどのように機能を使用するかを実装者が理解するのための参考情報です。システム コンポーネントはこの機能を別の方法で使用することがあるので、このセクションの説明を規範と見なさないようにご注意ください。

// Create KeyPairGenerator and set generation parameters for an ECDSA key pair
// using the NIST P-256 curve.  "Key1" is the key alias.
KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance(
    KeyProperties.KEY_ALGORITHM_EC, "AndroidKeyStore");
keyPairGenerator.initialize(
    new KeyGenParameterSpec.Builder("Key1", KeyProperties.PURPOSE_SIGN)
         .setAlgorithmParameterSpec(new ECGenParameterSpec("secp256r1"))
         .setDigests(KeyProperties.DIGEST_SHA256,
                     KeyProperties.DIGEST_SHA384,
                     KeyProperties.DIGEST_SHA512)
         // Only permit the private key to be used if the user
         // authenticated within the last five minutes.
         .setUserAuthenticationRequired(true)
         .setUserAuthenticationValidityDurationSeconds(5 * 60)
         // Request an attestation with challenge "hello world".
         .setAttestationChallenge("hello world".getBytes("UTF-8"))
         .build());
// Generate the key pair. This will result in calls to both generate_key() and
// attest_key() at the keymaster2 HAL.
KeyPair keyPair = keyPairGenerator.generateKeyPair();
// Get the certificate chain
KeyStore keyStore = KeyStore.getInstance("AndroidKeyStore");
keyStore.load(null);
Certificate[] certs = keyStore.getCertificateChain("Key1");
// certs[0] is the attestation certificate. certs[1] signs certs[0], etc.,
// up to certs[certs.length - 1].