要約

  • RFC 3185 は最初の CMS オブジェクトの内容暗号鍵を、後続オブジェクトの鍵暗号鍵の導出元として再利用し、非対称処理を減らした。
  • MSG1 の受信者集合 S1 が CEK を保持すれば、MSG2 がその一部だけを記載しても S1 全員が復号できた。後の一覧は、以前に渡した能力を取り消さなかった。

2001 年 10 月の Reuse of CMS Content Encryption Keys は Standards Track で公開され、RFC Editor は Proposed Standard としている。複数フィールドを別々に暗号化する取引や、サーバー間の頻繁な通信で、非対称鍵確立の費用を省くことが目的だった。

仕様は完全なプロトコルではない。参照鍵を失った場合の動作は外側の文脈が定める必要があり、一般的なグループ鍵管理にも向かなかった。API は鍵材料の変換を許し、CEK と KEK のアルゴリズムは形式と強度が適合しなければならない。

MSG1 は未保護属性に CEKReference を入れる。MSG2 は同じ値を KEKIdentifier として使う。受信者は参照から保存済み CEK を見つけ、MSG2 の新しい CEK を包む KEK を導出する。参照値自体は秘密ではなく、知るだけで鍵を得ることはない。

互換形式では旧 CEK のバイトを逆順にした。既知の平文と暗号文を次の暗号化鍵として直接使う特定の構成を避けるためだった。形式が異なる場合は PBKDF2 を使う選択肢があった。後続の CMS、PBKDF2、AES 鍵ラップ RFC は歴史的背景であり、RFC 3185 の現在利用を証明しない。

重要なのは S1 の例である。MSG1 を受けた全員は CEK を得る。MSG2 の名目上の受信者を S1 の部分集合にしても、KEK は旧 CEK から計算されるため、S1 全員が MSG2 を開ける。最新の表示と実際の鍵保持者は一致しない。

CEKMaxDecrypts は将来の再利用回数を示す。送信者には拘束的だが、受信者にはヒントである。属性がなければ一回とみなす。受信者は期待回数またはローカル期限まで状態を保存できるが、巨大な値や届かない後続メッセージはメモリ保持を長引かせる。

この値は遠隔消去ではない。全受信者が同じメッセージを受け、同じ回数を数え、全コピーを消したことは証明しない。保存と削除は各主体の行為であり、送信者の整数表現とは別である。

暗号化は送信者認証でもない。既知の参照を含む EnvelopedData は誰でも作れる。正しい参照は挿入や再送も防がない。復号、認証、権限、順序、新鮮性は別々の証拠を必要とする。

成功した復号も、ある鍵状態とパラメータが明文を生んだという観測に限られる。以前の受信者が読めないこと、明文が安全に扱われたこと、アプリケーション結果が成功したことまでは示さない。

CEK は順次更新できた。MSG[n] の新しいランダム CEK が次の導出元になる一方、自分の KEK から循環的に CEK を作れば予期せぬ固定鍵になり得ると RFC は警告した。各導出の出所と新鍵の独立性を保存する必要がある。

失敗理由も分けるべきだった。参照なし、期限切れ、非対応導出、アルゴリズム不一致、変更パラメータ、誤鍵は異なる。「復号失敗」だけでは運用判断を再現できない。

この歴史が示すのは、暗号権限が最新オブジェクトではなく鍵の受け渡し履歴に従うことだ。MSG2 を誰が読めたかは、MSG1 から始まる保管の連鎖を見なければ答えられない。