要約

  • CMS AuthEnvelopedData は AES-GCM を正しく指定し、必須パラメーターを持ち、タグ検証に成功しても、同一鍵の nonce が歴史上初めてであるとは証明できない。
  • RFC 5084 は自動鍵管理を必須とし、コンテンツごとに新しい CEK を生成する構成を安全な道として示す。アルゴリズム対応と運用履歴は別の証拠である。

送信システムをバックアップから復元した。最初のメッセージは問題なく暗号化され、受信側でもタグが通った。ところが復元前の最後のメッセージと同じ nonce カウンターを使っていた。現在の封筒に壊れたフィールドはない。壊れていたのは、封筒をまたぐ履歴だった。

RFC 5084 は AES-CCM と AES-GCM を CMS の AuthEnvelopedData で用いる規約を定義する。AES の鍵長ごとに OID を割り当て、アルゴリズムパラメーターを必須とし、認証属性を AEAD の追加認証データとして扱う。

核心の制約は一つのオブジェクトではなく、一つの鍵の作用域に置かれる。同じコンテンツ認証暗号鍵の下では nonce を重複させてはならない。異なるメッセージに同じ key/nonce の組を使えば、安全性は失われる。現在のオブジェクトは nonce を記録しても、別ホストや古いスナップショットの利用履歴を内包しない。

したがって、十二オクテットという正しい長さは一意性の証明ではない。GCM では効率上も推奨されるが、復元されたカウンターは正しい長さの値を再び生成できる。乱数らしい見た目も、複製された PRNG 状態の否定にはならない。

RFC 5084 は静的な鍵で安全に運用する難しさを踏まえ、自動鍵管理を要求する。鍵配送、鍵合意、対称鍵暗号化鍵、パスワード等から導出した鍵暗号化鍵の四方式を挙げる。各コンテンツに新しいコンテンツ認証暗号鍵、CEK を生成すれば、いずれも要件を満たす。

コンテンツごとの新規 CEK は履歴の範囲を狭くする。別の CEK なら同じ nonce バイトが出ても禁止された組の再現ではない。長寿命 CEK を選ぶなら、組織はその鍵が使われる全期間・全拠点を覆う、原子的で後退しない nonce 割当てを所有しなければならない。

符号化されたパラメーターにも固有の役割がある。GCMParameters は nonce と十二から十六オクテットの ICV 長を持ち、十二が既定かつ推奨である。宣言値は mac の長さと一致しなければならない。CCM の nonce は七から十三オクテット、ICV 長は四から十六までの偶数で、十二が推奨される。nonce 長は表現可能なコンテンツ長との交換条件にもなる。

必須パラメーターの欠落、範囲外の値、MAC との不一致はその場で拒否できる。しかし合格は一つのオブジェクトの構文を証明するだけで、CEK の乱数源、組織のタグ長ポリシー、他送信者の状態までは証明しない。

RFC 5083 が定義する AuthEnvelopedData では、RFC 5084 の認証属性が AAD になる。暗号化はされないが改変から保護され、暗号文とともに MAC の対象となる。非認証属性は同じコンテナー内にあっても、承認済みの命令には変わらない。

タグ成功の意味も限定される。保護対象の入力と検証鍵が整合したことは示すが、人の身元、文書の正当性、受信者の業務権限、復号後の処理結果は別問題である。アプリが非認証属性を実行条件にするなら、その判断の責任はアプリ側にある。

RFC 5116 の AEAD インターフェースは鍵、nonce、平文、関連データを入力とする。暗号プリミティブは与えられた入力を処理するのであって、外部の履歴台帳を探索しない。NIST SP 800-38D も GCM の IV 一意性を重大な運用条件として扱う。

監査には鍵を漏らさない鍵識別が要る。非秘密の鍵エポック、割当て名前空間、nonce を発行した原子イベント、本件専用 CEK か長寿命 CEK か、認証属性の正確な符号、暗号文ハッシュ、タグ長、検証結果、実装版を結び付ける。

逆向きの誤判定も避けたい。新しい CEK を別々に使った二つのオブジェクトが同じ nonce を持つことはあり得る。実際の鍵エポックを見ずに nonce だけ比較すれば、安全な組まで衝突と判断する。nonce の意味は鍵との組で決まる。

復元可能な証拠列は、CMS 原文、OID とパラメーター、非秘密 CEK エポックまたは新規生成記録、nonce 割当て、認証属性と AAD 符号、暗号文とタグ、受信者と鍵管理方式、解析・鍵復号・タグ検証、鍵作用域での重複照合、平文解放、アプリ承認と結果を分離して残す。

これは RFC 5084 に新しい構文を足す主張ではなく、運用上の提案である。Heng Lu の現実層の考え方に従えば、アルゴリズム名、封筒、タグ、履歴的一意性、受信者判断、業務結果は互いに隣接していても同一ではない。

出典