【解説記事】ML-KEM Security Considerations が気になったので読んでみた

Posted at 2025-11-18

こんにちは〜、GMOコネクトでCTOの菅野哲（かんのさとる）です。
11月17日の日刊IETFで紹介された「ML-KEM Security Considerations」について読んでみました。
気になった方や知らなかったという人は、日刊IETFを読んでみてね！

はじめに

PQCへの移行が現実のものとなりつつある中、2024年8月にNISTがML-KEMをFIPS 203として標準化したことで、量子計算機に耐性を持つ鍵交換メカニズムの実装が本格的に始まっています。しかし、アルゴリズム仕様が標準化されても、「実際のプロトコルでどう使えば安全か」 という運用ガイドラインが不足していました。

本記事では、IRTF CFRGに関連するI-Dとして2024年10月に初版が公開され、2025年11月に最新版（rev.04）がリリースされた draft-sfluhrer-cfrg-ml-kem-security-considerations を詳細に読み解きます。このDraftは、Cisco、NIST、Ericsson、Quantinuum、Arqitといった主要ベンダとNISTのメンバーが協力して作成した ML-KEMの「公式運用ガイド」 を目指す文書です。

この記事の対象読者

プロトコル設計者: TLS、HPKE、MLS、EDHOC等でML-KEMを組み込む方
セキュリティエンジニア: PQC移行プロジェクトを推進する方
実装者: ML-KEMライブラリを実装・統合する開発者
技術リーダー: PQC移行の技術的判断を行う方
IETF参加者: 標準化プロセスに関心がある研究者

Executive Summary

Draft の概要

ML-KEM Security Considerations (draft-sfluhrer-cfrg-ml-kem-security-considerations) は、ML-KEMを安全に使うための横断的なガイドラインです。NIST FIPS 203（アルゴリズム仕様）では規定されていない、プロトコルレベルでの運用上の注意点を体系的にまとめています。

ターゲット: CFRG (Crypto Forum Research Group)
最新版: rev.04（2025-11-17）
ステータス: Informational（標準化予定）
目的: 他のWG（TLS、LAMPS、MLS等）が参照できる共通なSecurity Considerationsを提供

主要な推奨事項

乱数生成器（RNG）の品質管理
- ML-KEM-512なら128ビット、ML-KEM-768なら192ビット、ML-KEM-1024なら256ビットのセキュリティ強度を持つDRBGを使用
- keygen と encaps で乱数を再利用しない
- 各呼び出しで新しいエントロピを取得
認証の必須実装
- KEM単体では相手認証を提供しない
- 公開鍵とciphertextの真正性を、証明書・署名・プロトコル認証のいずれかで保証
- 差し替え攻撃への対策を設計段階で組み込む
鍵ライフサイクルの明確化
- Static key運用でもIND-CCA2により安全だが、PFS運用を推奨
- PFS運用では、セッションごとにfresh keypairを生成し、Decaps後に秘密鍵をゼロ化
- ML-KEMのkeygen性能は高いため、頻繁な鍵更新も実用的
上位プロトコルの活用
- Public Key Encryption用途ではHPKE（RFC 9180）の利用を推奨
- 独自プロトコルを作る前に、既存の標準化プロトコルで要件を満たせないか検討

実務上の重要な知見

無視してよい問題:

Decapsulation failure: 発生確率は"宇宙全体で見ても起こらないレベル"で、実装で特別なエラー処理は不要
非定数時間実装: 多くのユースケースでrejection sampling由来のタイミング差は問題にならない（PAKEなど特殊ケースを除く）

注意が必要な問題:

Misbinding攻撃: 正しいKeyGen実装を使えば通常は問題ないが、認証用途で秘密鍵が攻撃者のコントロール下に置かれるシナリオでは追加の認証を検討
Shared secretの性質: Bobが任意の値を選べるわけではなく、両者のランダムネスから内部的に決定される

他のプロトコルとの関係

このDraftは Security Considerationsの「母艦」とすることを期待しており、以下のDraftから参照される予定です：

draft-ietf-lamps-kyber-certificates（X.509証明書）
draft-connolly-cfrg-hpke-mlkem（HPKE統合）
draft-ietf-tls-hybrid-design（TLS 1.3 Hybrid鍵交換）
draft-ietf-mls-protocol（Messaging Layer Security）

各WGのSecurity Considerationsで、詳細な考察をこのDraftに委譲できるようになります。

このDraftを読むべき理由

実装の落とし穴を事前に回避: RNG要件、認証設計、鍵管理の具体的な指針
標準化された運用知識: ベンダ横断で合意された安全な使い方
プロトコル設計の効率化: 各WGで重複して検討する必要がなくなる
セキュリティレビューの基準: ML-KEM実装の安全性評価の共通基盤

1. このInternet Draftの立ち位置

1.1 誰が、なぜ書いたのか

著者陣:

Scott Fluhrer (Cisco)
Quynh Dang (NIST)
John Preuß Mattsson (Ericsson)
Kevin Milner (Quantinuum)
Daniel Shiu (Arqit)

つまり、主要ベンダ + NIST + PQCベンダが揃って書いている「ML-KEMの公式チュートリアル兼Security Considerations」 という位置づけと考えられます。

1.2 なぜ必要だったのか

2024年8月、NISTはML-KEMを FIPS 203 として標準化しましたが、FIPS 203はアルゴリズム仕様書であり、TLS、HPKE、MLSやEDHOCなどで 「どう組み込めば安全か」までは規定していません。

CFRGメーリングリストでFluhrer氏は次のように説明しています：

「このドラフトのゴールは、他のWGに "ML-KEMをどう安全に使うか" のガイダンスを提供すること。いくつかのWGは、このようなガイドなしにML-KEMを使うことに慎重だったので、それに応える。」

実際、LAMPSの kyber-certificates DraftやHPKEの draft-connolly-cfrg-hpke-mlkem などが、このDraftを参照先として活用する流れができています。

1.3 CFRG的には「退屈なエンジニアリング文書」

IETF 124 CFRGセッションでは、このDraftについて：

ML-KEMのセキュリティゴールを明示
安全な使い方を整理
想定読者: プロトコル設計者・実装者
「CFRG的にはかなり退屈な文書になるはず」

つまり、新しい暗号理論ではなく、「実務で事故らないためのHow-To」 を意識した文書です。

2. ドラフトの構成

1. Introduction
2. Using ML-KEM
   2.1 ML-KEM Key Generation
   2.2 ML-KEM Encapsulation
   2.3 ML-KEM Decapsulation
   2.4 ML-KEM Parameter Sets
3. KEM Security Considerations（KEM全般）
4. ML-KEM Security Considerations（ML-KEM固有）
   4.1 Issues that are likely not a concern
       4.1.1 Decapsulation failure
       4.1.2 ML-KEM operations not being constant time
5. IANA Considerations
6. References

3. 重要ポイントの詳解

3.1 Introduction： KEMの基本とML-KEMの特性

KEMとDHの違い

Draft本体では、Diffie-Hellman (DH) との違いについて説明されています。

DH（Diffie-Hellman）の特徴:

非対話・非同期で2つの公開鍵を交換
双方が独立に共有鍵を導出可能

KEM（Key Encapsulation Mechanism）の特徴:

Draftの記述に基づくと、KEMでは以下のような流れになります：

Aliceが鍵ペア（公開鍵・秘密鍵）を生成
BobがAliceの公開鍵に対してciphertextとshared secretを生成
Aliceがciphertextからshared secretを復元
DHと異なり、ciphertextが片側の公開鍵に強く結びつく

また、Draft本体では 「Bobが任意の値をshared secretとして選べるわけではない」 という重要な特性が明記されています。ML-KEMでは、両者のランダムネスから内部的にshared secretが決定されます。

Public Key Encryption としての利用

Draft本体では、ML-KEMをPublic Key Encryptionの部品として使う場合は、HPKE（RFC 9180）上で使うことを推奨しています。HPKE経由で使えば、認証付き暗号化やKDF統合などが標準化された形で利用できます。

3.2 Using ML-KEM：基本操作フロー

2.1 Key Generation

ML-KEM.KeyGen() → (公開鍵, 秘密鍵)

Draft本体（FIPS 203の7.1節に準拠）では：

RNGから取得したシードを使用
シードも秘密鍵と同等の機密として扱うべきと明記

2.2 Encapsulation（Bob側）

Draft本体の手順：

1. Encapsulation Key Check（公開鍵の妥当性検証、FIPS 203の7.2節）
2. ML-KEM.Encaps(公開鍵) → (ciphertext, shared secret)

shared secretは32バイト
中間データは安全に削除すること（公開情報から導ける行列データを除く）

2.3 Decapsulation（Alice側）

Draft本体の手順：

1. Decapsulation Key Check（秘密鍵の妥当性検証）
2. ML-KEM.Decaps(秘密鍵, ciphertext) → shared secret

2.4 Parameter Sets と性能

Draft本体では、3つのパラメータセットの鍵長・ciphertext長・性能を、典型的なECDHと比較する表が掲載されています。

パラメータセット	セキュリティレベル	公開鍵サイズ	Ciphertextサイズ
ML-KEM-512	Category 1	800 bytes	768 bytes
ML-KEM-768	Category 3	1,184 bytes	1,088 bytes
ML-KEM-1024	Category 5	1,568 bytes	1,568 bytes

Draft本体の性能評価（Ryzen 7 7700 単コア）:

鍵サイズ・ciphertextサイズはECDHより大きい
keygen / encaps / decaps の単体スループットは非常に高い
頻繁な鍵生成（PFS）も実用的

3.3 KEM Security Considerations（KEM全般）

DraftのSection 3では、KEM全般に共通する注意点がまとめられています。

3.3.1 高品質な乱数が必須

Draftでは以下が明記されています：

keypair生成・ciphertext生成の両方でRNGが破られると致命的
shared secretや秘密鍵が攻撃者に露出

3.3.2 KEM単体では認証を提供しない

Draftの重要な指摘: 公開鍵やciphertextが攻撃者に差し替えられると、攻撃者とshared keyが張られてしまう。

Draftが推奨する対策: プロトコル側で公開鍵とciphertextの真正性を担保する必要がある。具体例として：

TLS: 証明書による公開鍵認証
MLS: 署名ベースの認証層
その他のプロトコル固有の認証機構

3.3.3 鍵のライフサイクル管理

Draftでは以下が整理されています：

PFSが必要なら、適切な頻度で鍵を更新
不要になった秘密鍵はゼロ化（メモリから完全消去）

3.4 ML-KEM Security Considerations（ML-KEM固有）

DraftのSection 4では、ML-KEM固有のSecurity Considerationsが展開されています。

3.4.1 セキュリティゴール

Draftでは、ML-KEMのセキュリティ特性について以下が明記されています：

IND-CCA2 安全性:

盗聴者が公開鍵とciphertextを見ても、CRQC（大規模量子計算機）を持っていても共有鍵は復元できない
「固定した公開鍵に対して任意ciphertextを投げてshared keyを観測する」攻撃モデルでも安全
無効なciphertextをDecapsに投げても、秘密鍵情報は漏れない

3.4.2 乱数と鍵の扱い

DraftのRNG要件:

各パラメータセット（512/768/1024）のセキュリティ強度以上のRNGを使用
keygen / encaps のそれぞれで新しいエントロピを使うべき

DraftのShared secret利用ガイド:

32バイトのshared secretは、そのまま以下の用途に使えると記載されています：

AESキー
MACキー
KDFへの入力

3.4.3 Perfect Forward Secrecy (PFS)

Draftの説明:

Static key運用:

IND-CCA2により、同じ公開鍵を繰り返し使っても安全

PFS運用（Draftが推奨）:

セッションごとにfresh keypairを生成
Decaps後にprivate keyを即座にゼロ化
Draftのベンチマークによれば、ML-KEMのkeygen性能は十分高いため、実用上の支障は小さい

3.4.4 Misbinding 問題（理論上のリスク）

Draftの説明:

攻撃者が**"あり得ない秘密鍵"を意図的に生成**できる状況では、特定の公開鍵やciphertextの組み合わせで、同じshared secretが再利用されるような「misbinding」が作れることが文献で示されている（MAL-BIND-K-CT / MAL-BIND-K-PK）。

Draftの実務評価:

正しいKeyGen実装を使っている通常利用では起こらないと明言
ただし、ML-KEMを認証用途で使い、かつ「秘密鍵が攻撃者のコントロール下」に置かれるシナリオがある場合は、公開鍵とciphertext自体にも認証をかけることを検討すべきとしています

3.4.5 実務上ほぼ無視してよい問題

DraftのSection 4.1 "Issues that are likely not a concern" では、よく話題になるが実用上はほぼ無視して良いものが2つ挙げられています。

4.1.1 Decapsulation failure

Draftの評価：

理論上、正しい手順でもAliceとBobのshared keyが食い違う確率がわずかに残る
3つのパラメータセット全てで、確率は "宇宙全体で見ても起こらないレベル"
実務上は無視してよいと明言

4.1.2 非定数時間実装（rejection sampling起因）

Draftの説明：

keygenやencapsで行列成分を生成する際、rejection samplingが入るため、XOF呼び出し回数が入力に依存して変動し得る。

Draftの影響評価:

多くのユースケースでは問題にならない
PAKEなど、公開鍵をパスワードで暗号化するような特殊ケースでは注意が必要

4. プロトコル設計者・実装者向けチェックリスト

Draftの内容に基づいて、実装時のチェックリストを整理します。各項目には、見落としがちなポイントや具体的な確認方法を含めています。

4.1 RNG（乱数生成器）

FIPS 203パラメータセットの強度と整合したDRBG/RNGを使用
- ML-KEM-512なら128ビット、ML-KEM-768なら192ビット、ML-KEM-1024なら256ビットのセキュリティ強度が必要
- SP 800-90A準拠のDRBGを使用しているか確認
keygen・encapsで乱数を再利用していない
- 各関数呼び出しで新しいエントロピを取得しているか
- 内部状態の再シードが適切なタイミングで行われているか
- テストコードで乱数ソースをモックしている場合、本番環境で正しく切り替わるか
RNGの故障やエントロピ不足を検知する仕組みがある
- DRBG の health test が実装されているか
- エントロピ不足時のエラーハンドリングが適切か（決して処理を続行しない）

4.2 鍵ライフサイクル

Static key運用 or PFS運用の方針を明確に決定
- 脅威モデルに基づいて、どちらの運用が適切か判断済みか
- Static keyを使う場合でも、IND-CCA2により安全性は保たれることを理解しているか
PFS運用の場合：keygen頻度を明示的に設計
- セッションごと/時間ベース/トランザクション数ベースなど、明確な鍵更新ポリシーがあるか
- ML-KEMのkeygen性能は高いため、頻繁な更新も実用的（Draftのベンチマーク参照）
PFS運用の場合：private keyのゼロ化タイミングを実装
- Decaps完了後、即座に秘密鍵をゼロ化しているか
- メモリ上の鍵データが適切に消去されることを確認（デバッガやメモリダンプで検証）
- ガベージコレクション対象言語では、explicit_bzero()のような確実な消去関数を使用
鍵の保管期間と廃棄手順を文書化
- 鍵のバックアップが必要な場合、暗号化保管の手順が明確か
- 鍵の廃棄時に、全てのコピー（バックアップ含む）が確実に削除されるか

4.3 認証設計

KEM単体に「相手認証」を期待していない
- Draftで強調されているように、KEMは認証機能を提供しない
- 公開鍵やciphertextの差し替え攻撃を防ぐ仕組みが別途必要
公開鍵の真正性保証の方法を決定
- 証明書ベース（X.509、draft-ietf-lamps-kyber-certificates参照）
- 署名ベース（MLSのような認証層）
- プロトコル固有の認証機構（EDHOC等）
- どの方法を採用するか明確に設計されているか
Ciphertextの改ざん検知機構を設計
- ciphertextが通信路で改ざんされないことをどう保証するか
- TLSのようにレコード層でMAC/AEADを使うか、アプリケーション層で署名を使うか
認証と鍵交換の順序を明確化
- 認証前に鍵交換を行うのか、認証後に行うのか
- タイミング攻撃やDoS攻撃への耐性を考慮しているか

4.4 ML-KEM固有の挙動

Shared secretが「Bobの好きな値ではない」前提でプロトコルを設計
- Draftで明記されているように、ML-KEMでは両者のランダムネスから内部的に決定
- 「Bobが特定の値を強制できる」ことを前提としたプロトコル設計になっていないか
Misbindingを避けたい認証系ユースケースでは、鍵生成手順とキー認証の組み合わせを検討
- 正しいKeyGen実装を使っていれば通常は問題ないが、認証用途では慎重に
- 秘密鍵が攻撃者のコントロール下に置かれる可能性があるシナリオでは、公開鍵とciphertext自体にも認証をかける
HPKEなど、標準化された上位プロトコルの利用を優先
- Draftが推奨するように、Public Key Encryption用途ではHPKE（RFC 9180）を使用
- 独自プロトコルを作る前に、既存の標準化プロトコルで要件を満たせないか検討
32バイトのshared secretの用途を明確化
- そのままAESキーとして使うのか、KDFに入力するのか、MACキーとして使うのか
- Draftでは全ての用途が可能とされているが、プロトコル仕様で明確に定義

4.5 実装の現実解

Decapsulation failureを「システム障害」として扱う必要はないことを理解
- Draftの評価：発生確率は"宇宙全体で見ても起こらないレベル"
- 実装で特別なエラー処理を用意する必要はない（コードを簡潔に保てる）
定数時間化のコストと攻撃者モデルを評価
- Rejection samplingによるタイミング差は、多くのユースケースで問題にならない
- PAKEなど公開鍵をパスワードで暗号化する特殊ケースでは、定数時間実装を検討
- 定数時間化のパフォーマンスコストと、実際の脅威を天秤にかけて判断
中間データの安全な削除を実装
- Draftでは、公開情報から導ける行列データなどを除き、中間データを安全に削除することを推奨
- Encaps/Decaps処理中に生成される一時変数が、処理完了後にメモリに残らないことを確認
テストベクトルとの整合性確認
- NIST FIPS 203の公式テストベクトルで実装を検証済みか
- 異なる実装間での相互運用性テストを実施したか
サイドチャネル攻撃への対策レベルを決定
- タイミング攻撃、キャッシュ攻撃、電力解析などへの耐性が必要か
- 脅威モデルに応じて、適切な対策レベルを選択（組み込み機器では特に重要）

5. 他のプロトコルDraftとの関係

5.1 参照している/される予定のDraft

Draftやメーリングリストの議論から、以下の参照関係が確認されています：

Draft	用途	参照関係
`draft-ietf-lamps-kyber-certificates`	X.509証明書へのML-KEM組み込み	Security Considerationsで本Draftを参照
`draft-connolly-cfrg-hpke-mlkem`	HPKEでのML-KEM利用	本Draftを参照して詳細省略
`draft-ietf-tls-hybrid-design`	TLS 1.3 Hybrid鍵交換	ML-KEM固有の考察で参照予定
`draft-ietf-mls-protocol`	Messaging Layer Security	同上