要約

  • suit-report-reason-invoke-pending は、呼び出しをこれから試みるが最終結果は不明だと示す。成功の予約でも失敗判定でもない。
  • SUIT_Record はマニフェストを辞書として圧縮された記録であり、digest が一致する正確なマニフェストなしに実行経路を復元してはならない。
  • 署名、freshness、報告環境の測定、制御移譲、初回実行、継続稼働、サービス結果を別々の受領記録として結ぶ必要がある。

戻り先がない呼び出しの直前

Manifest Processor は検証と条件分岐を終え、新しいコードを呼び出す地点に着く。SUIT_Command_Invoke が制御を移せば、呼び出されたコードはプロセッサへ戻らない場合がある。その後にレポートへ署名する設計は成立しない。

一方、remote attestation の Evidence は、信頼できる環境にいるうちに署名しなければならない。ここで先回りして success と書けば、署名は強くても内容は未来の推測になる。

draft-ietf-suit-report-22 はこの矛盾を隠さない。suit-report-reason-invoke-pending は「呼び出しを試みる直前で、最終結果はまだ分からない」と表す。草案は、後で呼び出しが失敗し得る以上、無条件の成功を先に署名するのは誤解を招くと説明する。

pending は失敗ではない。成功の弱い表現でもない。報告者が観測できた時点を保存するための時間境界である。

本物の記録でも単独では読めない

SUIT の記録は全文ログではない。依存マニフェストへの経路、コマンドシーケンス、バイトオフセット、コンポーネントインデックス、測定値を保持する。どの命令を意味するかは、対応するマニフェストを辞書として初めて分かる。

この圧縮は制約のある機器に向くが、解釈には厳格な条件が付く。受信者は suit-report-manifest-digest で一致を検証したマニフェストを入手しなければならない。参照URIがある場合、レポートのURIも完全に一致する必要がある。草案は、対応するマニフェストなしに SUIT_Record から処理を復元することを禁じている。

シーケンス番号だけでは不十分だ。複数の信頼された署名者がいれば番号は衝突し得る。番号はある履歴内の順番を表せても、解釈に必要な唯一のバイト列を指定しない。digest がその役割を持つ。

system-property-claims はコンポーネント識別子を直接含むため、先にマニフェストを得ずに処理できる。この限定された例外を、オフセットだけの waypoint に広げてはならない。

レポートだけ保存して辞書を捨てる運用は、真正な暗号文を残しながら監査可能性を失う。保存単位はレポートと正確なマニフェストの組である。

nonce が保証するのは「今」である

suit-report-nonce はfreshnessやreplay protectionに使える。外側の attestation container が challenge などでfreshnessを提供する場合は省略できる。

署名は作成者と改変有無を扱う。freshness は今回の交換に属するかを扱う。manifest digest は記録の辞書を特定する。result は署名時点でプロセッサが述べられる状態を扱う。

これらは交換可能ではない。新鮮な pending は成功にならない。過去の success は署名が正しくても現在の boot を説明しない。digest の一致は Report Generator 自体の健全性を証明しない。

「verified」という一語にまとめると、どの問いに答えたのかが消える。

証拠を作る環境も測る

SUIT Report を Attestation Evidence に使うには、生成環境も測定対象となる。第22版は Manifest Processor、Report Generator、さらにそれらを動かす bootloader や OS を挙げている。

正規の鍵で署名できることと、正しいコードが測定・編集したことは別である。改変された生成器は、一貫性のあるレポートを正規鍵で封じるかもしれない。出力の署名検証だけでは、その編集者を評価できない。

RFC 9334 の役割分担が有効になる。Attester が Evidence を作り、Verifier がポリシーに従って評価し、Attestation Results を出す。Relying Party はそれを使って信頼とアクセスを決める。信頼は決定であり、trustworthiness は対象の性質である。

さらにSUITのwaypointは、そのままRelying Party向けの主張ではない。Verifierが一致するマニフェストを用いて経路を復元し、評価可能なclaimsへ変換する。辞書または生成環境の測定が欠ければ、変換結果の見た目が整っていても根拠は不足する。

安全な配送は実行を代行しない

遠隔システムへ送る状態報告には、認証と機密性が必要である。EAT 内の保護された測定、COSE container、安全な通信プロトコルなどが候補になる。ローカルポリシーが認証を要求するなら、未認証の代替レポートを送ってはならず、partial report も同じintegrity要件を満たす。

これらは偽造、改変、漏えいを防ぐ。しかし、安全に運ばれた invoke-pending も、到着時点で success に変わるわけではない。

制御移譲後には別の観測が要る。entry point への到達、一定期間の生存、サービスの外部結果は、それぞれ範囲の違う証拠である。起動直後の一回の測定だけで、継続運用まで主張してはならない。

時間をまたぐ受領記録

まずレポートの原文、認証方式、署名者、検証結果とfreshnessの仕組みを保存する。root manifest digestに一致するマニフェストを取得し、経路、シーケンス、offset、componentを復元する。次にprocessor、generator、bootloader、OSの測定を評価する。

結果は上書きせず、success、明示的failure、暗黙のhandoff、invoke-pending のいずれかとして残す。その先に、実行開始、継続稼働、サービス効果の受領記録を接続する。

認証済みレポート → freshness → 正確なマニフェスト → 復元 → 生成環境の評価 → 制御移譲 → 実行 → サービス効果

調査時点の第22版は、Proposed Standardを目指す有効なInternet-Draftである。RFC Editor queueにあり、second-generation reference待ちでblockedだった。RFCでも導入実績でもない。

参照資料