要約

  • SEAT ユースケース文書の01版は、接続への結合、証拠の鮮度、複合認証、実行時アテステーション、長時間・再開接続の状態ドリフトを別々の目標として扱う。
  • TLS/DTLS が暗号学的に正常でも、証明対象の環境は後から変わり得る。ハンドシェイクは時間を区切った観測であり、恒久的な認可ではない。

午前9時、サーバは TLS ハンドシェイクを完了し、その接続に結び付いた新鮮な証拠を示す。Verifier は firmware、OS、workload、セキュリティ設定を受理し、Relying Party は秘密を渡す。午後2時も暗号通信は正常だが、workload は別のモジュールを読み込み、AI agent は新しい tool を得たかもしれない。

通信路は壊れていない。それでもアクセスを認めた根拠は、もう成立していない可能性がある。

この時間境界を扱うのが draft-ietf-seat-use-cases-01 である。2026年9月15日に更新され、2027年3月19日に失効する。SEAT Working Group の Internet-Draft で、状態は I-D Exists。表紙は Informational とするが Datatracker の Intended RFC status は空欄で、shepherd、担当 area director、telechat はない。IANA action もない。将来の protocol solution に「なぜ」と「何を」を与える文書であり、具体的な方式、appraisal policy、実装、導入、測定結果ではない。

接続の相手と実行環境は別の問い

TLS と DTLS は通常、鍵とネットワーク上の identity で peer を認証する。リモートアテステーションは Target Environment の hardware、firmware、software、security configuration に関する Evidence を加える。これにより、接続を保持する主体と、その接続を実行する環境の受容可能性を分けられる。

証明書が正しくても、秘密鍵が今も export 不可能か、secure boot が有効かは分からない。適合した別の機械が作った正しい Evidence だけでも、現在の接続をその機械が所有するとは分からない。

01版は Evidence または Attestation Result を特定の secure connection に暗号学的に結び付ける目標を置く。別の context から正しい Evidence を relay する攻撃を防ぐためだ。同時に compound authentication、machine identifier、通常の peer authentication、attestation credential freshness を分ける。一つの成功表示では代用できない。

ハンドシェイク時の鮮度は永久ではない

鮮度は古い適合状態の replay を防ぐ。接続結合は Evidence の移植を防ぐ。両方があれば、一定の freshness rule の下で十分に新しい assertion が、その接続 context に属することを示せる。その後の状態を固定するわけではない。

文書は long-lived connection と resumed connection の state drift を明記し、runtime attestation と periodic/on-demand の違いを扱う。本物の Evidence でも時間とともに古くなる。TLS record の認証が通り続けても、数時間前の構成が残っているとは限らない。

AI agent は典型例である。binary が同じでも、model、prompt template、利用可能な tool、外部 permission は頻繁に変わる。confidential workload の migration、reference value の失効、鍵保護設定の低下も record layer を壊す必要はない。

主張は限定しなければならない。ある Target Environment が、ある時刻、ある freshness rule と policy generation の下で評価され、その結果が接続に結び付いた。「接続が安全であり続ける」と「端末が認可条件を満たし続ける」は同じではない。

Resumption は再測定ではない

TLS resumption は以前の関係から導いた state で新しい接続を作る。暗号学的な連続性はあっても、Evidence の年齢、Target Environment の同一性、Verifier と policy の変更、権限上昇時の再証明を自動では判断しない。

草案は将来設計にこの問題を扱うよう求めるが、共通の有効期間は選ばない。telemetry の read と secret provisioning では許容できる年齢が違う。local policy に任せることは、記録しなくてよいという意味ではない。

KeyUpdate も traffic key を更新するが、firmware や agent tool set を測り直さない。transport key、Evidence、authorization の freshness は別々の時計である。

Passport と Background Check の交換条件

RATS の Passport model では Attester が Attestation Result を得て提示する。Background Check では Relying Party が Verifier と連携する。01版は最大の鮮度を求める用途に Background Check、scale、performance、Verifier 不達時の用途に Passport が向くとする。

Passport には期限と replay rule が要る。Background Check には Verifier availability、latency、timeout policy が要る。短い期限は stale window を狭める一方、負荷と DoS 面を広げる。長い期限は continuity を助ける一方、古い approval を長く継承する。

頻繁な証明は privacy にも影響する。Evidence は platform composition、configuration、workload identity を明かし得る。鮮度向上と linkability・保存・漏えいの増加を同時に評価する必要がある。

Authentication key と attestation key の障害は違う

TLS authentication key が盗まれると、別の機械へ re-host される可能性がある。attestation が役立つには、現在の key、environment、connection の結合が substitution を示せる必要がある。attestation key 自体が侵害されれば、適合して見える Evidence が偽造され得る。強い channel binding でも不正な Attester を正直にはできない。

certificate enrollment 時の key attestation にも同じ時間境界がある。その時点で key を生成・保存した module は示せるが、後の接続開始時や接続中の状態は保証しない。

結果はローカル認可への入力である

Evidence と Attestation Result は普遍的な allow 命令ではない。Relying Party が現在の operation と risk に local policy を適用する。01版は appraisal policy を明示的に scope 外とする。

新しい measurement は暗号学的に正しくても新しい policy に失敗し得る。同じ状態でも read には十分で secret release には不足し得る。Verifier の timeout 時に degrade するか close するかも service risk の判断である。

Heng Lu の minimum initial specification は binding、freshness、result semantics の小さな共通契約を支持し、platform technology と local appraisal は開く。running-code primacy は、trigger 時に再証明を要求し、古い approval を無効化し、権限を撤回した実際の receipt を求める。

運用では transcript binding、Evidence/Result ID、freshness basis、Verifier、policy generation、Target Environment、resumption lineage、last accepted time を記録する。migration、resumption、privilege increase、tool change、key rotation、alert、revocation、maximum age を trigger とする。これは本稿の提案であり、01版の必須要件ではない。

channel binding は substitution gap を閉じる。re-attestation と authorization withdrawal は time gap を閉じる。最初の handshake receipt だけでは、変化する機械を継続的に信頼できない。

出典