top of page
検索

PQC暗号アルゴリズムを理解する：ML-KEM 入門

  • 5月3日
  • 読了時間: 6分

Hi, there.

本日取り上げるテーマは、PQCの暗号アルゴリズムの一つであるML-KEMについてです。


量子時代の鍵共有をどう置き換えるか


ポスト量子暗号は、もう遠い未来の話ではありません。政府、金融、重要インフラの世界では、すでに2030年から2035年にかけて移行を前提にした時間軸が具体化し始めています。


NIST は量子脆弱な公開鍵アルゴリズムについて、112-bit 相当は2030年以降に deprecated、2035年以降に disallowed、128-bit 以上相当でも2035年以降に disallowedという移行方針を示しています。英国 NCSC も 2028年、2031年、2035年の3段階で移行を進めるロードマップを公開し、EU でも加盟国に2026年末までの移行開始、重要インフラについては2030年末までの移行を促しています。さらに金融分野では、G7 Cyber Expert Group が金融セクター向けの PQC 移行ロードマップを公表しています。


もはや PQC は、政府・金融・重要インフラに関わるなら今すぐ理解しておかなければならない技術になっています。


まずは、その入口としてNIST によりPQC の主要標準の一つとして位置づけられたML-KEMを本日の題材とします。


ML-KEM は何をするアルゴリズムか


ML-KEM は、公開鍵を使って共有秘密を包み、秘密鍵を持つ相手だけがそれを取り出せるようにする方式です。平たく言えば、相手と共通鍵を安全に作るための部品です。

この位置づけは、従来の暗号でいえば ECDH や RSA ベースの鍵配送に近いものです。特に現代的な通信では、RSA で直接データを守るよりも、まず鍵共有や鍵配送を行い、その後は AES-GCM や ChaCha20-Poly1305 のような高速な共通鍵暗号で本体データを保護する構成が一般的です。ML-KEM は、この公開鍵暗号で安全に共有秘密を確立する役割を、量子計算機時代に耐える形で担う候補です。


ここで重要なのは、ML-KEM 自体がアプリケーションデータをそのまま暗号化するものではないという点です。ML-KEM で得るのはあくまで共有秘密であり、その後に HKDF などで鍵導出を行い、通信鍵やデータ暗号鍵へ分離して使うのが自然な使い方です。つまり、ML-KEM は「暗号化アルゴリズムそのもの」というより、安全な鍵交換のための中核部品として理解するのが適切です。


なぜ ML-KEM が安全だと考えられているのか


ML-KEM が注目されている理由は、従来の RSA や楕円曲線暗号のように素因数分解問題や離散対数問題に依存していないことです。これらは大規模な量子計算機が実用化した場合、Shor のアルゴリズムによって効率よく破られるおそれがあります。一方、ML-KEM はそうした前提ではなく、格子問題に基づく困難性を土台にしています。


もう少し具体的に言えば、ML-KEM は格子暗号の一種であり、特にモジュール格子に関する計算困難性を利用しています。攻撃者は公開情報から秘密を導こうとしますが、その問題は現在知られている古典計算機・量子計算機のいずれに対しても、現実的な計算量では解くのが難しいと考えられています。少なくとも、RSA や楕円曲線暗号のように「量子計算機が十分育つと理論的に明確な破り方がある」という状況とは異なります。


もちろん、これは「絶対安全」を意味するものではありません。暗号方式の安全性は、数学的評価、実装品質、パラメータ選定、周辺プロトコル設計に支えられています。そのため ML-KEM も、単体で魔法のように安全を与えるわけではなく、適切なパラメータ、正しい鍵

導出、認証との組み合わせ、実装上の副作用対策まで含めて初めて意味を持ちます。


何にとって代わるのか


ML-KEM を理解するときは、「何を置き換えるのか」をはっきりさせると整理しやすくなります。基本的には、既存の公開鍵ベースの鍵共有・鍵配送を置き換える候補です。


代表的には次のような対象があります。

  • ECDH / ECDHE

    TLS などで広く使われてきた鍵共有方式です。現在の通信では、もっとも直接的な置き換え対象として意識されます。

  • RSA 鍵配送や RSA ベースの古い仕組み

    いまでは主流ではないものの、古い設計や一部の製品にはまだ残っています。

  • 機器間の独自鍵配送プロトコル

    組み込み機器や専用プロトコルで、公開鍵を使ってセッション鍵やラップ鍵を渡している仕組みも置き換え対象になります。


特に TLS の文脈では、ML-KEM は「証明書の署名」を直接置き換えるものではありません。そこは ML-DSA など別の署名方式の役割です。ML-KEM が担うのは、あくまでハンドシェイクの中で安全に共有秘密を作る部分です。この役割分担を混同しないことが重要です。


どこで使うべきか


ML-KEM は、次のような用途で考えると理解しやすいです。

  • TLS などの通信路でセッション鍵を確立したい

  • デバイス間通信で、鍵配送の仕組みを量子耐性化したい

  • 今すぐ全面移行はできないが、ハイブリッド移行を見据えたい

  • データ暗号用の一時鍵やラップ鍵を安全に受け渡したい


とくに実務では、いきなり ML-KEM 単独へ全面移行するというより、既存の ECDHE と ML-KEM を組み合わせたハイブリッド構成から入るのが現実的です。これは、従来方式の相互運用性と、PQC の将来耐性の両方を見ながら移行するためです。組織や製品によっては、まずは内部通信や限定的な閉域環境から適用し、その後に外部接続や広域配布へ展開する流れのほうが現実に即しています。


また、組み込みや IoT の文脈では、ML-KEM は単なる「インターネット向け暗号」ではありません。たとえば、製造時に書き込んだ公開鍵基盤を使って、装置起動後にサーバとセッション鍵を確立する、あるいは機器間で一時鍵を安全に配送するといった用途にも自然に適用できます。つまり ML-KEM は、量子時代の鍵共有を担う汎用部品として見ておくとよいアルゴリズムです。


Python サンプルコード例


概念としてはここまでとし、少しでも動きを知っておいた方が分かりやすいだろうということで、liboqs-python を使った最小限の動作例を掲載しておきます。


OQS の Python ラッパーは KeyEncapsulation、Signature、StatefulSignature を提供しており、examples/kem.py が ML-KEM の参考実装として公開されています。 (GitHub)

import oqs
from cryptography.hazmat.primitives.kdf.hkdf import HKDF
from cryptography.hazmat.primitives import hashes

KEM_ALG = "ML-KEM-768"

with oqs.KeyEncapsulation(KEM_ALG) as receiver:
    # 受信側: 鍵ペア生成
    public_key = receiver.generate_keypair()

    with oqs.KeyEncapsulation(KEM_ALG) as sender:
        # 送信側: 受信側公開鍵に対して encapsulate
        ciphertext, shared_secret_sender = sender.encap_secret(public_key)

    # 受信側: decapsulate
    shared_secret_receiver = receiver.decap_secret(ciphertext)

    assert shared_secret_sender == shared_secret_receiver

    # そのまま使わず、HKDFで用途別に導出する
    hkdf = HKDF(
        algorithm=hashes.SHA256(),
        length=32,
        salt=None,
        info=b"app=session-key:v1",
    )
    session_key = hkdf.derive(shared_secret_receiver)

    print("shared secret matched")
    print(f"derived session key length = {len(session_key)}")


実験環境では、まず liboqs-python を使えるようにします。公式 README では、liboqs を共有ライブラリとしてビルドし、その後 liboqs-python を pip install . で導入する手順が案内されていますのでそれに従います。 (GitHub)

git clone --depth=1 https://github.com/open-quantum-safe/liboqs
cmake -S liboqs -B liboqs/build -DBUILD_SHARED_LIBS=ON
cmake --build liboqs/build --parallel 8
sudo cmake --build liboqs/build --target install

git clone --depth=1 https://github.com/open-quantum-safe/liboqs-python
cd liboqs-python
pip install .

まとめ


ML-KEM は、PQC を学ぶ入口として非常に扱いやすいアルゴリズムです。その理由は、「ML-KEM は署名方式ではなく、共有秘密を安全に確立するための鍵共有アルゴリズム」という役割が明確だからです。


また、ML-KEMは将来的にECDH をはじめとする従来の公開鍵ベースの鍵共有を置き換えていく有力候補として位置付けられています。その重要性は、標準化の動きにも表れています。NIST は ML-KEM を FIPS 203 として標準化しており、量子計算機に対して脆弱な公開鍵暗号を、2035年までを視野に段階的に移行していく方向性を示しています。


だからこそ今の段階で押さえておきたいのは、ML-KEM を「新しい暗号化方式」と大づかみに理解するのではなく、「安全な共有秘密を作るための中核部品」として正確に捉えることです。


PQC 移行は、遠い将来の話ではありません。まずは ML-KEM の役割を正しく理解することが、その第一歩になります。


参考



bottom of page