要約

  • revision 01では、InitiatorがResponderを認証するのはmessage_4_KEMの検証後であり、ResponderがInitiatorを認証するのはmessage_5_KEMの検証後である。
  • message 3には機密性と完全性があっても、Initiatorの認証にはならない。相互認証、transcriptの完全性、credentialの真正性、鍵保有証明がそろうまで、最終application keyを確定してはならない。

3通目の成功表示が危ない

message 3を処理した時点で、運用画面には成功らしい材料が並ぶ。ephemeral KEMから共有秘密ができ、InitiatorはResponderのcredentialを確認し、そのstatic public keyにencapsulateした。自身のcredential情報も保護されたciphertextで送り、Responderはdecapsulateと復号に成功した。

しかし、その時点の緑表示は早すぎる。

2026年9月28日に提出されたKEM-based Authentication for EDHOC revision 01は、message 3を保護する鍵ではInitiatorを認証できないと明記する。Responderは自分を証明するMACをまだ送っておらず、Initiator側のMACもまだない。static KEM private keyの保有者は、peerが対応するpublic keyに作ったencapsulationを先に受け取らなければ保有を示せないため、後続の2メッセージが必要になる。

Datatracker上では、LAKE WGのactive Internet-Draftで、IESG状態はI-D Existsにすぎない。本文はStandards Trackを意図するが、RFCでも承認済み標準でもなく、実装や導入を証明しない。更新または前進がなければ2027年4月1日に失効する。

認証完了は一度ではなく二度来る

message 1がephemeral KEM public keyを運び、Responderはそこへencapsulateしてmessage 2を返す。そこにはResponderのcredential識別子も入る。Initiatorは自分のcredentialを開示する前に、相手のcredentialを取得し、検証し、local policyで受け入れなければならない。暗号学的に正しいcredentialでも、信頼していない相手や意図しない相手のものかもしれないからだ。

InitiatorはResponderのstatic KEM keyにencapsulateし、message 3でそのciphertextと自身の保護されたcredential情報を送る。Responderがdecapsulateできても、identity bindingは閉じていない。Responderの明示的なMACを含むmessage_4_KEMを検証して初めて、InitiatorはResponderを認証し、PRK_outやapplication keyを保存できる。

反対方向はまだ未完了である。Responderはmessage_5_KEMのMACを検証して初めてInitiatorを認証する。草案は、misbindingがこの第4・第5メッセージの確認まで発見されない可能性を認めている。それまではEADを未保護として扱い、keying materialを永続化してはならない。

したがって、一つのauthenticatedフラグでは状態を表せない。片側だけがpeerを検証済みの時間帯がある。decapsulation成功が示すのも特定の秘密材料の保有であり、どのidentity、trust policy、transcript、application権限に結びつくかは別途確認が要る。

耐量子方式でもsession freshnessは省略できない

このkey scheduleは、freshなephemeral contributionと、2本のstatic KEM keyに由来する秘密を混ぜる。static keyへのencapsulationはsessionごとに新しく作らなければならず、ss_I、ss_Rと対応するciphertextの再利用は禁止される。さらにKEMにはIND-CCA2だけでなく、derived secretをrecipient public keyへ暗号学的にbindする性質が必要だ。IND-CCA2単独ではre-encapsulationやunknown key-shareを排除できない。

RFC 9935とFIPS 203はML-KEMを定めるが、鍵に組織の権限を与えない。SP 800-227はKEM利用の指針を示し、RFC 9528はEDHOCの基準を与える。新草案が提案するのはLAKEでのtranscript、credential、確認順序であり、deployment、相互接続、性能の結果ではない。

また、この方式が与えるのはimplicit proof of participationであり、non-repudiationではない。認証されたLAKE peerにも、経路変更、software導入、送金、物理装置の操作を行う権限が自動で付くわけではない。運用ledgerではmethodとsuite、credentialのlocal validation、message 2〜5、MAC_2とMAC_3、秘密を含まないfreshness識別子、key保存を許す遷移、application authorization、保護要求・応答、最終効果を分けて残す必要がある。

BTWのRFC 9668に関する既報は、EDHOC message 3と最初のOSCORE requestを同梱してもapplication実行を証明しないという境界を扱った。今回はその手前である。このKEM方式ではmessage 3の時点で認証そのものが未完了だ。

Running-Code Primacyに従うなら、message 4/5を中断し、encapsulationをreplayし、credentialを差し替え、残る状態を観察する。Minimum Initial Specificationが支持する共通部分は、明示的な完了状態とsessionごとのfreshnessという薄い不変条件でよい。具体的なtrust policyはlocal decisionである。Reality Layersは、鍵保有、信頼identity、authorization、effectが互いの証明を代用することを防ぐ。

出典