要約

  • RFC 9709は、内部のAlgorithmIdentifierをパラメータ込みでDER符号化し、元のコンテンツ暗号鍵とともにHKDFへ入力する。
  • 認証付き暗号をCBCとして見せる改変や、パラメータだけの改変でも導出鍵が変わるため、有用な平文オラクルにならない。
  • 守られるのはこの変換攻撃に対する機密性であり、送信者の真正性、内容の安全性、後続処理の権限ではない。

暗号文より先に「解釈」が狙われた

LAMPSが検討した攻撃では、攻撃者は鍵を盗まない。AES-GCMまたはAES-CCMで保護されたCMSデータを捕捉し、選んだ暗号文ブロックをAES-CBCの内容として再構成する。鍵を持つ受信側が改変物を処理し、結果や挙動を外へ出せば、低エントロピーで構造化された平文候補を確かめる逆向きのオラクルになり得る。

実環境で必ず成功するわけではない。IETF 118の資料は、S/MIMEでは意味のない出力になりやすく、ヘッダー検査で止まる可能性があり、実際に脆弱な製品群も不明だったと説明した。しかし、それはアプリケーションごとの偶然の防壁である。プレビュー、変換、通知、解析済みフィールド、処理時間の差など、別のCMS用途が推測を確定する信号を返すことはあり得る。

RFC 9709はアルゴリズムの説明を鍵の構成要素に変える。対応する受信者はS/MIME Capabilitiesでid-alg-cek-hkdf-sha256を通知し、そのパラメータは付けない。送信者が保護を選ぶ場合、外側のcontentEncryptionAlgorithmにこのOIDを置き、必須パラメータとして実際の内部AlgorithmIdentifier、すなわちコンテンツ暗号方式とそのパラメータを格納する。

双方はHKDF-SHA-256で作業鍵CEK-primeを導出する。元のCEKが入力鍵材料、固定ASCII文字列“The Cryptographic Message Syntax”がsalt、内部識別子の完全なDER符号化がinfoとなる。DERのSEQUENCEタグ、長さ、OID、符号化済みパラメータまで含む。出力長は元の鍵と同じで、HKDF-SHA-256の上限8,160バイト以内である。

一バイト単位の同一性が防御になる。GCMをCBCへ置き換える、初期化ベクトルを変える、パラメータを別表現にする――いずれもinfoを変え、別の鍵を生む。元の鍵向け暗号文は、攻撃者が指定した解釈では役立つ試験にならない。外側OIDを除去した場合、受信側はCEK-primeではなく元のCEKを使い、メッセージを読めなくなる。それでも保護された平文は出ない。結果はアクセス拒否であり、機密性の破綻ではない。

一つの成功表示に畳まない

運用証拠は少なくとも、受信者の能力通知、外側OIDの選択、内部方式とパラメータ、HKDFに渡したDERバイト列、認証復号と関連データ検証の結果、信頼境界を越えた平文・解析結果・挙動、後続処理を許可した方針を分けて残すべきだ。

「復号成功」だけでは、互換性障害と改変を区別できない。反対に、正しく解析できても送信元は証明されない。RFC 9709は鍵を分離する仕組みであり、署名、送信者評価、マルウェア検査、業務上の承認を代替しない。

RFCは認証属性にも注意を促す。暗号化されていないメッセージダイジェスト属性は平文候補の確認に使われ得る。また、暗号化された未承諾メッセージは、迷惑メールやフィッシングを内容で検査する仕組みを迂回し得る。承認済み送信者だけを受け入れる方針は補完策だが、アルゴリズム結合とは別の判断である。

小さな共通仕様と端末での検証

この構成はSHA-256に固定され、KDFを交渉しない。別のハッシュを採用する将来仕様は新しいOIDを必要とする。共通部分を「外側を認識し、内部符号化を保持し、導出し、内部方式を実行する」という決定的な手順に抑えた設計である。

CEKの安全な乱数生成と保護は依然必要だ。RFC 5652のCMS構造、RFC 5083のAuthenticated-Enveloped-Data、RFC 5084のAEAD、RFC 5869のHKDF、RFC 8551のS/MIME能力、RFC 4086の乱数指針は独立した前提である。弱い鍵や侵害端末、偽装された送信者はRFC 9709だけでは直らない。

今回の確認時点で、RFC Editorの検索にはRFC 9709の報告済み正誤表がなく、IANAのSMI登録簿には割当識別子が記録されていた。これは標準化の状態を示すが、実装普及の証拠ではない。

出典