要約

  • RFC 10013 の計測コンポーネントには、必須の名前と生値またはダイジェスト値があり、任意でバージョン、コンポーネント署名者を示す authorities、プロファイル固有の flags を付けられる。JSON または CBOR で EAT の Measurement claim に格納する。
  • ダイジェスト一致は、選ばれた入力が参照値と等しいことを示すにすぎない。コンポーネントの authority は外側の EAT の署名者とは別であり、Verifier の肯定的な評価も、所有、登録、利用資格を証明しない。
  • 運用で必要なのは、計測範囲、採取時点、Attester、鮮度、プロファイル、Reference Value、評価ポリシー、Attestation Result、Relying Party の認可規則、実際の結果までを切らずに保存することだ。

交換部品を戻す前の判断

工場の制御装置で故障した基板を交換したとする。保守ネットワークへ戻す前に、装置は遠隔アテステーションを求められる。

返ってきた EAT は期待した Attester 鍵で正しく署名され、nonce も新しい。計測コンポーネントはブートローダーを示し、SHA-256 ダイジェストは承認済みの Reference Value と一致する。authorities には認められたファームウェア署名者が二つ並び、プロファイルも既知だ。Verifier は compliant という Attestation Result を返す。

ここで自動化が装置へ書き込み権限を戻したら、判断を一段飛ばしている。

計測範囲に、起動後のモジュールを選ぶ可変設定が含まれていないかもしれない。Reference Value は昨日まで安全だった版をまだ許可しているかもしれない。装置は本物で健全でも、交換基板の資産登録が完了していないかもしれない。監視データの送信は認められても、制御値の変更は認められない場合もある。

証拠が正しいことと、扉を開けることは同じではない。

2026 年 7 月に IETF Standards Track で公開された RFC 10013 は、対象環境にあるコンポーネントの計測状態を表現する情報モデルと JSON/CBOR データモデルを定めた。標準が担うのは交換可能な証拠であって、全用途に共通する信頼判定ではない。

コンポーネントの境界は規格より先に決まる

計測対象には、フラッシュ内のファームウェア、起動時にメモリへロードされるソフトウェア、ランタイム整合性検査、ファイルシステム上のオブジェクト、設定 blob、CPU レジスタなどがある。

RFC 9393 の CoSWID は、ソフトウェアの識別や導入・更新のライフサイクルを簡潔に表す。EAT の measurements でも evidence 型 CoSWID を利用できた。しかし、初期ブートやレジスタの値は必ずしもファイルやインストール済みパッケージではない。RFC 10013 は、その空白を埋める。

ただし、何を一つのコンポーネントとするかは決めない。

プラットフォーム設計者が境界を引き、コレクターがその中を読む。ハードウェアの信頼基点で採取処理を保護できても、境界外の状態が自動的に見えるわけではない。狭すぎる対象の正確なハッシュは、狭すぎる事実を正確に述べている。

監査記録には Target Environment、境界、採取機構、時刻または boot epoch、測らなかった依存関係が必要だ。「セキュアブート成功」という一語では、どの状態が証明されたかを再現できない。

Heng Lu の Running-Code Primacy は、規格と現実の順序を示す。規格は共通の assertion を定める。運用上の信頼は、読まれたバイト、実行されたコード、許可された動作を観測して成立する。

安定した名前は世界共通 ID ではない

コンポーネント名は必須で、人が読める文字列だ。形式や命名規則は対象の種類に依存する。更新を追跡しやすくするため、リリースが変わっても同じ項目には一貫した名前を使うことが重要とされる。

一貫性は一意性ではない。異なるベンダーが似た名前を選べるし、/boot/loader.bin というパスの中身や役割も変わり得る。誰が、どの規則で、どの実体へ名前を付けたかを残さなければ、Reference Value の選択を誤る。

バージョンは任意で、CoSWID の version scheme を再利用できる。情報モデルは Semantic Versioning を推奨するが、CPU レジスタや設定オブジェクトまで同じ方式に従わせるものではない。

安定名にはプライバシー上の反作用もある。ソフトウェアやパッチ水準が分かり、時間をまたいだ追跡にも使える。運用に便利な識別子は、攻撃者にとっても便利な識別子になり得る。

生値とダイジェストは違う負担を持つ

計測値は生の byte string またはダイジェストで表す。生値なら情報を圧縮しないが、CPU レジスタから大きな設定 blob までサイズが大きく変わる。デコーダーがこのフィールドへのメモリ割当てを制限できるのは、実装上の重要な境界だ。

ダイジェスト形式はアルゴリズムと値を組にする。アルゴリズム識別子は IANA Named Information Hash Algorithm レジストリに従い、RFC 10013 は強い暗号学的ハッシュを要求する。

強い関数でも、次の事柄は証明しない。

  • 対象範囲に重要な状態がすべて入っていたか。
  • 採取後に状態が変わっていないか。
  • Reference Value が現在も許容可能か。
  • Attester 実装が十分に保護されているか。
  • その装置が組織の所有物または登録済み資産か。
  • 要求中の操作をその結果から許可してよいか。

ダイジェスト一致を「信頼済み」に変換する UI は、証拠を増やさず、判断過程だけを消す。

authorities は EAT 署名者の一覧ではない

RFC 10013 における authority は、インストールされたコンポーネントへデジタル署名し、それを権威的に識別できる主体だ。X.509 証明書、生の公開鍵、鍵の thumbprint などで表せる。署名は RFC 9019 のようなファームウェア更新時、またはブートファームウェア、OS、ランチャーで検証され得る。

この署名は、外側の EAT evidence に対する Attester の署名とは明確に別である。

コンポーネント署名は、導入された artefact の出所や承認者を示す。EAT 署名は、どの Attester が claim set を生成し、改変から保護したかを示す。一方が正しくても、他方の信頼性は自動的には決まらない。

authorities には更新システム、フリート所有者、監査者など複数の主体を含められ、順序に意味を持たせることもある。基礎仕様はその意味を決めない。適用する EAT profile が、使用の有無、各 entry の役割、byte の解釈を定める。

flags も同様だ。長さは正確に 8 byte だが、64 bit の意味は profile が決める。authorities または flags があり、consumer が profile を知らない場合は EAT を拒否しなければならない。別 profile の経験で推測することは、相互運用ではなく誤読である。

JSON と CBOR の共通化は評価ポリシーを共通化しない

CBOR EAT は CBOR の measured component をそのまま持てるほか、JSON を tunnel できる。JSON EAT は JSON を直接持つか、base64url で CBOR を包める。IANA は application/measured-component+cbor と application/measured-component+jsonを登録し、CoRE Content-Formatsには 295 と 296 が割り当てられた。

レジストリは「どう読むか」を共通化する。「どう判定するか」までは共通化しない。

これは Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption の設計に合う。交換に必要な共通層は小さくし、profile、Reference Value、評価、認可の選択は結果を負う主体に残す。

公式の RFC 10013 errata 検索は、2026 年 8 月 30 日時点で該当なしだった。これは時点付きの事実であり、実装品質の保証ではない。

EAT の構文は Attester の強度をそろえない

RFC 9711 は、claim の意味を定義しても、その実装や Attester に特定のセキュリティ水準を要求するわけではないと明記する。受信側は、ベンダー実装と Verifier の検査内容を理解して trustworthiness を判断する。

保護されたハードウェアと一般アプリケーションが同じ EAT 形式を生成してもよい。形式が同じだからといって防御強度は同じにならない。

EAT の全利用には freshness が必要だ。nonce 等で古い token の replay を防ぐ。ただし、token の発行時刻と測定時刻は別である。ブート時の値が後の token に入るなら、採取時点、発行時点、boot epoch の関係を保存しなければならない。

EAT の measres claim は、Reference Value との比較結果を success、failure、not run、absent として示す。RFC 9711 は、それが Verifier 全体の結果ではないとする。measres=success を「装置を信頼」と表示すれば、比較結果へ存在しない権限を与える。

RFC 9783 の PSA Attestation Token は、RFC 10013 のモデルが参照した先行例だ。評価は exact な値、許容する release 群、既知 signer などに基づける。それぞれ違う保証であり、token 自身は選択しない。

Verifier の合格と Relying Party の許可

RFC 9334 の RATS Architecture は、責任を役割として分ける。

Attester は Evidence を作る。Reference Value Provider は期待値を提供する。Endorser は能力や信頼基盤について保証する。Verifier は Appraisal Policy for Evidence を適用して Attestation Result を作る。Relying Party はその結果と自らのポリシーから、データや操作へのアクセスを決める。

同じサービスが複数役を持ってもよいが、論理上の責任は残る。

Reference Value には提供者、版、発効時点、失効や撤回がある。脆弱性が判明すれば、装置の byte が変わらなくても同じダイジェストを拒否すべきになる。参照値や評価ポリシーの管理者は、装置に触れずにフリート全体の判定を変えられる。

Verifier はベンダー固有の Evidence を Relying Party が扱える結果へまとめる。その便利さは、Verifier への信頼集中でもある。結果には Verifier の identity、policy version、Evidence の強度と freshness を結び付ける必要がある。

健全性は資格ではない。RFC 9334 は、同一メーカーの健全な端末をすべて認識できても、企業が自社所有端末だけをネットワークへ入れたい場合を示す。正常な委託先端末は、正常であることを理由に自社端末にはならない。

Relying Party は、対象リソース、要求操作、資産登録、利用者、金額、障害状況を知る。Verifier の評価は重要な input だが、すべての下流認可を代行する mandate ではない。

事故対応で必要なのは途中の記録

再現すべき連鎖は次の通りだ。

計測境界 → コレクターと時点 → 値 → 命名規則 → authority の意味 → EAT 署名者と freshness → profile → Reference Value → Verifier policy と結果 → Relying Party policy → 許可操作 → 実際の効果。

一つの boolean に畳むと、あとから展開できない。

不正なコードが接続を得た場合、採取漏れ、古い参照、評価ミス、過大な認可を分けて調べる必要がある。途中がなければ、すべての担当者が同じ緑の画面を指し、誰の判断だったかが消える。

Heng Lu の Reality Layers と Symbolic Power はこの構造を説明する。名前、version、digest、signer ID、result は、選ばれた実行状態の表象だ。表象と現実の距離を見せることが、証拠の権威を守る。

計測情報を誰が持ち続けるか

名前とバージョンはソフトウェアや patch 水準を明かし、安定性は追跡を可能にする。生値はさらに多くの構成情報を漏らし得る。

最初の consumer が EAT を復号して claim subset を下流へ送る場合、元の envelope protection は失われる。RFC 9711 は同等の通信保護を求め、各 consumer への開示を最小化するよう促す。

Data Sovereignty の技術的現実と実務的現実を分けるなら、装置の所有者だけでなく、Verifier、log、trace、analytics、support がどのコピーを保持するかを追う必要がある。機器を所有していても、その構成地図を独占しているとは限らない。

アクセス判断に必要なのが scope 付きの Attestation Result なら、設定 blob 全体を渡さない。remediation に version が必要でも、永続的な device identity まで共有するとは限らない。目的別の選択的開示が原則となる。

規格が止まる位置は正しい

RFC 10013 は、共通オブジェクト、JSON/CBOR、profile の明示、強い digest、未知 profile の拒否、プライバシー上の注意を定めた。

装置が「良い」とは宣言しない。

コレクターは境界、Attester は Evidence、component signer は artefact provenance、Reference Value Provider は期待状態、Verifier は appraisal、Relying Party は authorization に責任を持つ。

ブートローダーを確認できたことは、判断の始点であって終点ではない。