要約

  • RFC 9529は、固定入力、EDHOCメッセージ、transcript hash、中間PRK、暗号文、exporter、OSCOREパラメータ、無効例を公開し、実装をバイト単位で比較できるようにする。
  • 全項目の一致が証明するのは、その計算経路の再現である。乱数の新鮮さ、秘密鍵の保管、検査の網羅性、資格情報の権限、実セッションの効果は含まれない。
  • 判断に使える保証には、参照再現、無効入力、entropyと鍵管理、身元と方針、実際の結果という五つの記録が要る。

CIは一件の差分も報告しなかった。message_1、TH_2、CIPHERTEXT_3、PRK_exporter、OSCORE Master Secretまで一致した。画面は多数の比較を一語に縮めた。「EDHOC検証済み」。

しかし端末は、再起動するたびに同じ一時秘密鍵を使っていた。

これは説明のための仮想例であり、実在製品の事故ではない。問うべきはテストの権限である。RFC 9529は、EDHOCの入力、出力、中間値を注釈付きで掲載し、二つの独立実装で確認した。最終結果だけでなく、最初に食い違った地点を探せる。

一方、固定されたままの性質を参照トレースが認証することはできない。

鍵交換の途中が見える

EDHOCは制約機器向けだが、methodとcipher suite、connection identifier、一時Diffie-Hellman、credential、transcript hash、MACまたは署名、認証暗号、exporter、OSCOREを結ぶ。

第一のトレースは署名認証、x5tで示すX.509、X25519、EdDSAを使う。第二はstatic DH、kidで示すCCS、P-256を使い、errorの後に二度目のmessage_1を送るsuite交渉も示す。

RFCはTH_2、TH_3、TH_4、中間PRK、平文、暗号文、associated data、PRK_out、PRK_exporter、OSCORE Master SecretとSalt、KeyUpdate後の値を並べる。差分をCBOR、credential、suite、KDF contextまで戻せる。

参照トレースが言えるのは明確だ。この入力なら、仕様の計算はこのバイト列を出す。

公開秘密鍵は試験のためにある

再現には固定入力が必要である。RFC 9529は必要な秘密鍵を掲載し、それらを秘密とみなしたり利用したりしてはならないと明記する。テストベクトルには既知の秘密が必要だが、運用には予測不能で、管理下で生成・保管・廃棄される秘密が要る。

したがって合格は、乱数生成器の健全性、再起動後の独立性、鍵の抽出耐性、メモリ消去、hardware isolation、同時セッションの分離を測らない。それぞれ別の試験対象である。

証跡には、トレース、build、機種、compilerとともに、entropy health、鍵生成元、保管、再起動、clone、並行実行の結果を残すべきだ。「RFC 9529 pass」だけでは運用状態が消える。

transcript一致は稼働中の身元ではない

TH_2はResponderの一時公開鍵とmessage_1のhashを結び、後続状態は認証平文とcredentialを加える。派生鍵と暗号文はその履歴に依存するため、診断には強い。

ただし参照例はcredentialと鍵を最初から与える。実運用ではx5tまたはkidを解決し、適切な規則で検証し、機器やprincipalに結び、その主体が何を許可されるか決める。暗号検証が正しくても、ローカルの身元対応や認可は誤り得る。

exporterも業務結果ではない。OSCORE材料の導出は、次のmessageが受理されたこと、replay制御が働いたこと、sensor値が新鮮なこと、actuatorが動いたことを証明しない。下流の事実には下流の記録が必要である。

無効例は攻撃面の一部である

第4節は、CBOR sequenceの代わりのarray、余分なwrapper、要素数や型の誤り、textとして符号化した一時鍵、非決定的encodingを示す。暗号関連では、長さ違反、field外の座標、曲線上にない点、low-order Curve25519 point、短いMAC、先頭zero欠落がある。

RFC自身が「小さな集合」と述べる。同種の不正は他のfieldやmessageにもある。公開例を全て拒否しても、任意の深さ、長さ、状態遷移、resource消費への安全性は証明しない。fuzzing、property test、differential test、resource limit、code reviewは別の範囲を担う。

「RFC 9529の無効トレースを拒否する」は監査できる。「不正EDHOC入力に堅牢」は、より広い証拠を要する。

決定的CBORは暗号状態である

RFCはraw byte stringとCBOR encodingを区別する。不必要に長いintegerやindefinite-length arrayは、decode後に同じに見えても、hash、署名、MAC、KDFの入力を変える。

そのため証跡はraw message、encoding判断、最初の中間差分、suite、credential形式を保持する。decode済みobjectだけのlogは原因を消しかねない。

相互運用性にも範囲がある

二つの独立実装が一致したことは重要である。一実装の癖をprotocol規則と誤認する危険を下げる。

それでも選択例への一致であり、全suite、method、credential、EAD、error pathではない。IANA EDHOC registryは値の意味を登録するが、製品のsupportや安全な有効化を保証しない。

標準とトレースは移植可能な最低線である。実装範囲、運用方針、lifecycle、failureの見え方はローカル責任として残る。

一つのbadgeを五つの証跡に戻す

第一は再現記録である。vector、version、platform、compiler、backend、最初の差分を持つ。第二はnegative inputで、拒否地点、cost、拒否後のstateを持つ。

第三はentropyと鍵管理で、health、重複、生成元、isolation、zeroisationを持つ。第四は身元と権限で、x5tまたはkidの解決、trust anchor、validation rule、principal、許可を持つ。第五は現実で、peer、replay判断、exporter用途、OSCORE context、保護message、観測効果を持つ。

Heng Luのreality layerの区別はここで実務になる。仕様は実装ではない。正しい計算は新鮮な鍵ではない。有効credentialは認可ではない。派生secretは結果ではない。各層を接続して初めて因果が残る。

情報源が証明しないこと

閉じた情報源は、一時鍵を反復したvendorを示さない。導入数、fleet failure、side-channelの一般結論もない。冒頭はcontrol gapの例である。

これはRFC 9529の価値を下げない。複雑な計算を実行可能な証拠にするからこそ、運用は残りの証跡を正確に足せる。

出典