Chapter 14

アテステーション — 「このデバイスは何者か」を署名付きで証明する

この章のゴール.

psa_initial_attest_get_token() を呼んでトークンを取得し、 その中身（CBOR の主張の列と COSE 署名）を読めるようになり、 サーバ側で何を検証すべきか、そして「なぜチャレンジ応答より優れているか」を説明できるようになること。

この章で使う既出の用語（定義は各リンク先）. PSA（01 章 1 節）、参照実装（01 章 1 節）、type（03 章 11 節）、ハッシュ（05 章 1 節）、乱数（05 章 1 節）、MAC（06 章 1 節）、チャレンジ（09 章 5 節）、認証（09 章 1 節）

1. アテステーションとは何か

アテステーション（attestation、証明）は、 装置が「私はこのハードウェアで、このファームウェアを、この状態で動かしている」と、 改ざんできない形でサーバに申告する仕組みである。

09 章のチャレンジ応答は「秘密鍵を持っている」ことしか証明しない。 乗っ取られた装置も、正規のファームウェアが消されて別のコードが動いている装置も、秘密鍵さえ残っていれば認証を通ってしまう。 アテステーションは、署名の対象に「ブート時に測定したファームウェアのハッシュ」や「ライフサイクル状態」を含めることでこれを防ぐ。

PSA Initial Attestation API は、この申告書（トークン）を作る 2 つの関数だけからなる。

psa_status_t psa_initial_attest_get_token(const uint8_t *auth_challenge, size_t challenge_size,
                                          uint8_t *token_buf, size_t token_buf_size,
                                          size_t *token_size);
psa_status_t psa_initial_attest_get_token_size(size_t challenge_size, size_t *token_size);

2. 呼び方

uint8_t challenge[32];         /* サーバから受け取った乱数（32 / 48 / 64 バイトのいずれか） */
uint8_t token[1024];
size_t  token_len;

/* 必要なサイズを先に聞くこともできる */
PSA_CHECK(psa_initial_attest_get_token_size(sizeof challenge, &token_len));
/* token_len ≤ sizeof token を確認 */

PSA_CHECK(psa_initial_attest_get_token(challenge, sizeof challenge,
                                       token, sizeof token, &token_len));
send_to_server(token, token_len);

• auth_challenge（チャレンジ）はサーバが作った乱数。長さは 32・48・64 バイトのどれか（他の長さは INVALID_ARGUMENT）。トークンの中にそのまま入る。再送攻撃を防ぐ
• トークンの大きさは、ファームウェアの構成要素の数によるが、通常 300〜700 バイト。1 KB のバッファで足りる
• 呼ぶだけで、アプリケーションは署名鍵にも測定値にも触れない。すべてセキュア側（TF-M のアテステーションパーティション）が持っている

このため、アテステーションはTF-M（または同等のセキュア側実装）がある環境でしか意味を持たない。 Mbed TLS 単体にはこの API はない。 セキュア側が「非セキュア側が何を動かしているか」を独立に測定しているからこそ、申告に価値がある。

3. トークンの中身

トークンは COSE_Sign1（CBOR Object Signing and Encryption の署名 1 つ版、RFC 9052）で包まれた CBOR（Concise Binary Object Representation、JSON をバイナリにしたような形式、RFC 8949）のマップである。 中身の主張（claim、クレーム）は EAT（Entity Attestation Token、RFC 9711）の PSA プロファイルに従う。

旧プロファイル（PSA_IOT_PROFILE_1）では、キーが −75000〜−75010 の負の整数だった（arm_psa_nonce = −75008 など）。 古い TF-M や検証ツールのログに負のキーが出たら、こちらである。

3.1 ソフトウェア構成要素

トークンの核心は Software components（キー 2399）である。 ブートローダ（MCUboot——Arm 系マイコンで広く使われるオープンソースのブートローダ）が起動時に各イメージのハッシュを測り、セキュア側に渡した値がここに入る。

サーバはこの配列を見て、「この装置は既知の正しいファームウェア（ハッシュが一致）を動かしているか」を判断できる。 脆弱性のある古いバージョンを動かしている装置には、更新を強制したりアクセスを拒否したりできる。

4. 署名鍵 — IAK

トークンの署名には、IAK（Initial Attestation Key、初期アテステーション鍵）という装置固有の ECDSA P-256 鍵を使う。

• 工場で装置内に生成またはプロビジョニングされ、決して外に出ない（TF-M では組み込み鍵 ID TFM_BUILTIN_KEY_ID_IAK として、read-only の永続鍵として扱われる）
• 公開鍵は製造時にサーバ（検証サービス）に登録される。UEID は公開鍵から計算されるので、サーバは UEID から公開鍵を引ける
• 対称鍵版（HMAC で COSE_Mac0 を作る）もあるが、検証側が同じ鍵を持つことになるので通常は非対称版を使う

TF-M の開発用ビルドには公開されたテスト用 IAKが入っている。 製品では必ず差し替える（attest_key.c またはプロビジョニングバンドル）。 差し替え忘れは「誰でも正当なトークンを作れる装置」を出荷することを意味する。

5. サーバ側の検証

検証サービスが行うことを列挙する。装置側は 1 関数だが、価値は検証側で生まれる。

1. COSE_Sign1 の構造を解析し、CBOR の主張を取り出す
2. UEID から登録済みの IAK 公開鍵を引く
3. 署名を検証する（ECDSA P-256 + SHA-256。署名対象は COSE の Sig_structure）
4. Nonce が自分の送ったチャレンジと一致することを確認する（再送防止）
5. Security lifecycle が SECURED であることを確認する（デバッグ状態の装置を拒否）
6. Software components の各ハッシュが許可リストにあることを確認する
7. 結果（合格/不合格、その理由）をアプリケーションサーバに返す

Arm は参照実装として Veraison プロジェクト（オープンソースの検証サービス）を提供している。 開発中は、TF-M の iat-verifier（Python ツール）でトークンをデコードして中身を眺めるのが手軽である。

pip install iat-verifier    # TF-M の tools/iat-verifier
check_iat -k iak_pub.pem -t PSA-2.0.0-token token.cbor -p   # デコードして表示・検証

6. 使いどころ

トークンに秘密は入っていない。装置 ID とハッシュと署名だけである。 だから TLS で暗号化していない経路で送っても、内容が漏れて困ることはない（誰が何を動かしているかは分かる）。

7. 手を動かす

トークンの構造を見る

8. 仕様書に逃がす

この章のポイント

• アテステーション = 「何のハードウェアで、何のファームウェアが、どの状態で動いているか」の署名付き申告
• 装置側は psa_initial_attest_get_token(チャレンジ, トークン) の 1 関数。鍵も測定値も触らない
• トークンは COSE_Sign1 で包んだ CBOR。中身は Nonce、UEID、ライフサイクル、ソフトウェア構成要素のハッシュ
• 署名鍵は IAK。テスト用 IAK は必ず差し替える
• 価値は検証側で生まれる: 署名、Nonce、ライフサイクル、ハッシュの許可リストを確認する