PQC暗号アルゴリズムを理解する：ML-DSA 入門
- 5月17日
- 読了時間: 6分
量子時代に、署名の信頼をどう守るか
PQC が必要になる理由は、通信の暗号化だけではありません。政府、金融、重要インフラのシステムでは、「誰が作ったか」「改ざんされていないか」を確認する署名基盤も同じように量子脆弱性の影響を受けます。NIST は 2035年までに量子脆弱な公開鍵アルゴリズムを段階的に外していく方針を示しており、英国 NCSC は 2035年までの移行完了を目標にした3段階のロードマップを公表しています。EU も加盟国全体での移行開始と、重要インフラの早期移行を促しています。
そこで中核になるのが ML-DSA です。NIST は 2024年8月に FIPS 204 を承認し、ML-DSA を PQC の主要なデジタル署名標準として定めました。ML-DSA は旧称 CRYSTALS-Dilithium で、用途は 署名生成と署名検証 です。
ML-DSA は何をするアルゴリズムか
ML-DSA は、秘密鍵で署名を作り、公開鍵でその署名を検証する方式です。役割自体は RSA や ECDSA、EdDSA と同じで、データの完全性と署名者の真正性を検証するための公開鍵署名方式です。ML-DSA により、署名対象データが改ざんされていないこと、そして対応する秘密鍵を持つ主体によって署名されたことを、公開鍵によって検証できます。NIST は同標準の中で、デジタル署名は改ざん検知、署名者認証、さらには第三者に対する証拠性、すなわち non-repudiation に用いられると説明しています。
この位置づけは、従来暗号でいえば RSA 署名や ECDSA / EdDSA の置き換え先として理解するのが自然です。つまり、ML-KEM が ECDH や RSA ベース鍵共有の代替候補であるのに対し、ML-DSA は 公開鍵署名の量子耐性版です。ファームウェア更新、ソフトウェア配布、セキュアブート、証明書、文書署名といった、「誰が作ったか」「途中で変わっていないか」が重要な領域で使うアルゴリズムです。
なぜ ML-DSA が安全だと考えられているのか
ML-DSA が注目されている理由は、RSA や楕円曲線署名のように 素因数分解問題や離散対数問題に依存していないことです。これらの問題は、大規模な量子計算機が実用化された場合、Shor のアルゴリズムによって現実的に破られる可能性があります。一方、ML-DSA はそうした前提ではなく、格子問題に基づく困難性を土台にしています。NIST も FIPS 204 の概要で、ML-DSA は lattice-based digital signature algorithm であり、大規模量子計算機を持つ攻撃者に対しても安全と考えられていると説明しています。
もう少し技術的に言えば、ML-DSA は module lattice に基づく署名方式であり、既存の RSA や ECDSA とは異なる数学的前提の上に成り立っています。ここが重要です。つまり、量子計算機時代に従来署名方式の安全性前提が崩れるとしても、ML-DSA は 別の計算困難性に依拠することで署名機能を維持しようとする方式です。ただし、これも「方式を選べば自動的に安全」という意味ではありません。署名対象の正規化、鍵管理、検証失敗時の停止、乱数や実装品質といった周辺要素が壊れていれば、方式自体が強くても実運用では事故になります。これは PQC でも変わりません。
何にとって代わるのか
基本的には、既存署名方式の役割を量子計算機時代でも維持するための、公開鍵署名方式の置き換え候補です。
代表的には、次のような対象があります。
RSA 署名
証明書、文書署名、古い更新基盤などに広く使われています。
ECDSA / EdDSA
より現代的なシステム、TLS 証明書、ソフトウェア署名、トークン署名などで広く使われています。
ここで重要なのは、ML-DSA は 鍵共有を置き換えるものではないという点です。ML-KEM のように共有秘密を確立する役割ではなく、あくまで 署名生成と署名検証 の役割を担います。つまり、TLS で言えば ML-KEM はハンドシェイクの鍵共有側、ML-DSA は証明書や認証の側です。この役割分担を混同しないことが、PQC を整理して理解するうえでとても重要です。
なぜ ML-DSA が重要なのか
鍵共有は見えにくい内部部品ですが、署名はもっと表面に出ます。ソフトウェア更新、証明書運用、ブート検証、リリース管理。どれも運用に直結しています。NIST が ML-DSA を FIPS 204 として標準化したのは、PQC 移行を現実のシステムへ落とし込むうえで、署名の置き換えが避けられないからです。NIST の PQC プロジェクトは、承認済み標準が “most deployments” の基盤になると説明しており、ML-DSA はその中核の一つです。
通信路の機密性はその場限りで済むことがありますが、署名は数年後、あるいは十数年後にも検証されることがあります。ファームウェア更新の真正性、配布物の由来、長期保存文書、監査証跡、こうしたものは「いま通ればよい」では済みません。だからこそ、政府、金融、重要インフラのように長期運用と証拠性が重い分野では、署名方式の量子耐性化が特に重要になります。
ML-DSA の実装と運用
ML-DSA の実装には、いくつかの重要な要素があります。まず、適切な鍵管理が必要です。秘密鍵は安全に保管し、アクセス制御を厳格に行うことが求められます。また、署名対象のデータを正確に特定し、改ざんを防ぐための手段を講じることも重要です。
次に、署名の検証プロセスを確立することが必要です。署名が失敗した場合、どのように対処するかを明確に定めておくことが、信頼性を高めるポイントとなります。これにより、運用中のトラブルを未然に防ぐことができます。
Python サンプルコード例
liboqs-python は Signature クラスを提供しており、examples/sig.py が公式の参考例として案内されています。README でも、利用可能な署名方式は get_enabled_sig_mechanisms() で列挙できるとされています。 (GitHub)
この例は説明用にシンプルですが、実務では「何に署名したか」をもっと厳密にすべきです。たとえば、バージョン、対象機種、ハッシュ値、発行日時、失効条件まで含めた manifest を署名対象にするほうが事故が減ります。
まとめ
ML-DSA は、PQC の中でも特に実務との距離が近いアルゴリズムです。NIST はこれを FIPS 204 として標準化しており、2030年代前半に向けて、各国で耐量子計算機暗号への移行圧力も着実に高まりつつあります。そうした流れの中で重要なのは、ML-DSA を単なる「新しい署名方式」として捉えるだけで終わらせないことです。
本当に押さえるべきなのは、何に署名するのか、どの場面で検証失敗を確実に失敗として扱うのか、そして署名鍵をどのように保護するのかという、実装と運用まで含めた視点です。署名アルゴリズムそのものを知っているだけでは、実務では十分ではありません。鍵管理、検証処理、失敗時の扱いまで含めて整理できて初めて、ML-DSA は現場で活用できる技術になります。
そのため、PQC への移行に向けては、単に仕様書を読むだけではなく、ML-DSA の基本的な仕組みを実装とあわせて理解しておくことが重要です。そうした理解の積み重ねが、将来の適切な移行を進めるうえで確かな助けになるはずです。
参照
NIST FIPS 204: Module-Lattice-Based Digital Signature Standard
NIST FIPS 204 PDF
NIST Post-Quantum Cryptography FIPS Approved
NIST Post-Quantum Cryptography Project
Open Quantum Safe liboqs-python
