要約

  • RFC 3537 は HMAC 鍵の前に 1 オクテットの長さを置き、3DES または AES の鍵ラップに必要なランダムパディングを加えた。
  • 正しくアンラップできれば元のバイト列は戻るが、その完全性確認だけでは HMAC のアルゴリズム、許可された用途、データの起源までは分からない。

CMS の AuthenticatedData パッケージをメールゲートウェイが開く場面を考える。受信者向けの鍵は保護され、受信側システムはアンラップして正確なバイト列を取り出す。鍵ラップの仕組みは役目を果たした。では、その成功は何を証明するのだろう。答えは限定的だ。その表現が当該ラップ方式の完全性チェックを通った、ということだ。それだけでは、どのハッシュ関数がそのバイト列を使うのか、このサービスに使用権限があるのか、誰がパッケージに入れたのか、いまも有効なのかは分からない。

そこに RFC 3537 の歴史的な境界がある。2003 年 5 月、S/MIME ワーキンググループによる IETF Standards Track の Proposed Standard として公開され、従来の 3DES および AES ラップ方式のサイズやパリティの前提に合わない HMAC 鍵を扱えるようにした。文書は CMS AuthenticatedData を利用例の一つに挙げる。これは鍵を運ぶ仕組みであり、認可や来歴をすべて記述する形式ではない。

長さの 1 バイト、その後に鍵

どちらの方式も LENGTH || KEY から始まる。LENGTH は 1 オクテットで、その数だけ鍵のオクテットが続く。全体を 8 オクテット単位にするため、必要最小限のランダムパディングを加える。したがって、序文の「任意長」は、鍵が従来方式の固定サイズに縛られないという意味であり、長さ欄が無限を表せるという意味ではない。RFC 3537 は、アプリケーションに対する最大鍵長の方針も定めていない。

パディングは封筒の外にあるメモではない。ラップされた表現の一部であり、完全性の構成に含まれる。アンラップ側はまずオブジェクトの完全性を検証し、長さ、鍵、残りを分け、パディングが 7 オクテットを超えていれば拒否する。これで鍵の終端を推測せずに復元できる。しかし、ランダムなパディングは意味のラベルを持たない。「この顧客の監査記録に HMAC-SHA-256 を使う鍵」や「次のローテーションまで有効」とは記していない。

継承された二つの保護経路

RFC 3537 は一つの共通変換を発明したわけではない。3DES 経路は RFC 3217 のラップ手順を基礎とし、HMAC 鍵には 3DES のパリティ制約がないことを考慮して 8 オクテットのチェックサムを加え、最終段の固定 IV を使う前にランダムな初期化ベクトルを用いる。AES 経路は、長さとパディングを付けたレコードを RFC 3394 の AES Key Wrap で包む。AES の完全性値と 3DES のチェックサムは置き換え可能な細部ではなく、それぞれ別の構成に属する。

このため RFC 3394 の 64 ビット A レジスタは別の主題として残る。これは AES 変換に混ぜ込まれ、候補平文を解放する前に検証される値だ。RFC 3537 の焦点は、その方式を包む HMAC 鍵の封筒、つまり可変長鍵をラップし復元するためのフレーミングである。RFC 3058 の記事も別の境界を扱い、IDEA の鍵ラップ、能力情報、チェックサムを中心に据える。RFC 3217 は 3DES 経路の背景であり、この記事の主張ではない。

アルゴリズム識別子も別の境界を示す。RFC 3537 は 3DES 用と AES 用の HMAC 鍵ラップに OID を割り当て、パラメーターを NULL とする。OID が示すのは、どのラップ処理で包んだかだ。復元後の鍵をどの HMAC ダイジェストが使うかまでは示さない。RFC 2104 の鍵指針は HMAC に関するもの、RFC 3537 の OID は包みに関するものだ。両者を同一視すれば、プロトコルの二層を一つに潰してしまう。

完全性があっても起源は分からない

セキュリティ考慮事項は KEK を保護するよう求め、KEK の漏えいがそれでラップしたすべての HMAC 鍵の開示につながり得ると警告する。さらに微妙な限界も述べている。ラップ関数は機密性とデータ完全性を与えるが、データ起源の認証を必ずしも与えない。KEK を持つ者なら誰でも、完全性チェックを通るメッセージを作れる。起源の認証も必要なら、KEK 配布の仕組みでその起源を認証するか、デジタル署名を使う必要がある。

これは、アルゴリズムが規定どおりのチェックに失敗するという話ではない。チェックが何を証明するかの話だ。「アンラップに成功した」を「期待された権限者がこの用途に鍵を承認した」と解釈すれば、そのレシートに書かれていない役割を押しつけることになる。オブジェクトが正しい形式で完全でも、送信元、目的、認可が証明されない場合はある。

記録の訂正であり、アルゴリズムの変更ではない

RFC Editor の検証済み編集エラッタ 254 は、3DES のセクション 3.4 のテストベクトルを訂正する。PAD の値は 38be62 ではなく be62fe である。修正値は直後の LKEYPADICV 行のバイト列と一致する。これは公開済みベクトルの編集上の修正であり、ラップ手順の変更でも、実運用の暗号障害を示す証拠でもない。

より広い教訓は、暗号アルゴリズムよりもシステム設計にある。復元可能な鍵を運ぶ仕組みだけでなく、ダイジェスト、意図された操作、主体、起源、有効期間を示す別個の認証済み証拠が要る。署名付きマニフェストやプロトコル固有の認証コンテキストがその判断を運べる。包みが符号化していないフィールドを、包みに読み込ませてはいけない。RFC 3537 は有用な輸送境界を設けた。システムがその境界を保ってこそ監査可能である。

出典