要約

  • RFC 10021 は、セキュリティ・コンテキストの状態を失った Group OSCORE エンドポイントに、nonce の再利用とリプレイ誤認を避ける手順を定める。停止し、必要なコンテキストを得てから、新鮮性を確認する。
  • 回復済みコンテキストや新鮮性チャレンジの成功が示すのは限定されたプロトコル条件であり、過去の指示、現在の承認、安全条件、完了した効果を再構成するものではない。

現場機器の再起動後、「復旧した」という表示ほど判断を急がせる言葉はない。それは通電を意味するかもしれず、ネットワーク接続、鍵ストアへのアクセス、あるいは監視へのハートビート復帰を意味するかもしれない。いずれも別の事実である。どれも、途中で止まった作業を続けてよいという指示に静かに変換してはならない。

RFC 10021 は 2026 年 7 月に IETF Standards Track として発行され、グループのメンバー間で保護された CoAP 通信を行う Group OSCORE を定める。グループ・モードでは、送信者が CoAP メッセージを保護し、私有鍵でカウンタ署名する。受信者は送信者の公開鍵と Security Context でそれを検証する。ここから得られるのは、保護されたメッセージとその送信元認証処理に関する厳密な証拠である。業務工程を再開するスケジューラではない。

この抑制が重要になるのは、揮発性の状態が失われたときだ。Group OSCORE は Security Context の長期部分と、予期しない再起動で失われうる可変部分を分ける。エンドポイントがその喪失を検知したなら、同一鍵で nonce を再使用しないようにし、リプレイされたメッセージを扱わなければならない。更新済みパラメータを取得できないなら、影響を受けたコンテキストでメッセージを保護し続けてはならない。リプレイを検出する能力を回復できない非サイレントなエンドポイントは、グループからの受信も受け入れてはならない。これは再起動フラグで回避する不便ではなく、安全な停止である。

受信者の履歴を限られたメモリのために削除した場合も同じだ。再導出された Recipient Context の Replay Window は無効から始まる。装置は過去のトラフィックを十分に知らず、新しい要求と古い要求を区別できないためである。RFC 10021 が示す道は限定される。メッセージを破棄する、新しい Security Context パラメータを得る、または CoAP Echo を使う。見た目の正しい次のパケットが過去を取り戻す、とは書いていない。

Echo は過大に読まれやすい。RFC 9175 は、サーバがチャレンジを出し、クライアントがそれを返すことで、アプリケーションが定める要件に従って要求の新鮮性を確認できるようにする。Group OSCORE では、正しく返された Echo が関係する Replay Window を有効にし、新鮮な要求をアプリケーションに届かせられる。これはリプレイ防止の確信を狭く回復する処理である。Echo は要求を特定の過去の応答に結び付けず、取引履歴を再建せず、不在の運用者がなおその操作を望むことを証明せず、アクチュエータを再始動できるかを決めない。

Group Manager の役割も重要だが限定される。RFC 10021 は、参加するエンドポイントがグループ参加を許可されていることを直接、または信頼された主体の証拠により確認するよう求める。その許可の詳細は RFC の範囲外である。セキュリティ・グループへの参加は、その後グループを通るすべての操作への恒久的な委任ではない。コンテキスト配布、メンバーシップ、現在の業務権限は、異なる記録と時計に属する。

鍵の更新は、緑の状態表示が一つでは足りない理由を示す。クライアントが旧コンテキストで要求を保護した直後にサーバが新しいパラメータを導入し、応答は新コンテキストで保護されることがある。RFC 10021 は移行時の nonce 再利用を避ける。元の要求がなお適時であること、目標状態がなお望まれていること、遅い応答が工程完了を示すことまでは述べない。

ここでの編集上の結論は、喪失検知、旧新コンテキストの識別子、再プロビジョニング又は新鮮性チャレンジ、署名とリプレイの結果、アプリケーション状態の照合、ローカル承認、独立した効果観測を分けて残すことだ。こうすればメッセージ保護の基盤を安全に回復でき、回復そのものを決定権にすり替えずに済む。

出典