TPM 2.0 v1.85でPQC対応へ — ML-KEM/ML-DSAと「実運用までの谷」を一次資料で読む

Posted at 2026-06-29

はじめに

こんちにちは！
GMOコネクト執行役員CTO / GMOインターネットグループ主席研究員菅野哲（かんのさとる）でございます。

「TPMがPQC対応したらしい」という話を一次資料で確認したところ、これはTPM 2.0 Library Specification version 185（v1.85）として実現していました。本稿では、どのアルゴリズムに対応したのか、いつチップが出るのか、そして運用上の本丸である暗号モジュール認証（CMVP／JCMVP）まで、TCG・NIST・IPA・各ベンダの一次資料に当たって通しで整理します。

結論を先に言えば、「対応仕様が出た」ことと「実際に調達・運用できる」ことの間には、まだ大きな谷があります。本稿ではその谷の正体まで踏み込みます。なお本稿で扱う日付・バージョン・各社日程は執筆時点（2026年6月）で確認できた範囲のもので、変動の大きい項目は参照時に各一次資料で再確認することをおすすめします。

参照先

要約

TPM 2.0 Library Specification v1.85 は、TCGとして初めてPQCに対応した仕様である。正式版（pub）は2026年3月12日付で公開された[1][2]。
採用アルゴリズムは ML-KEM（FIPS 203）とML-DSA（FIPS 204）の2つのみ で、ML-KEMをEndorsement Key、ML-DSAをAttestation Keyに割り当てる。SLH-DSA（FIPS 205）やFN-DSA（Falcon）は含まない[1]。
EKをML-KEM化することで、記録した暗号文を将来復号する HNDL（Harvest Now, Decrypt Later） への長期機密性を確保する設計である[1]。
現時点で実際に動かせるのは ファームウェアTPM（wolfSSL） のみで、PQCコマンドをホストへ公開するディスクリートのハードウェアTPMはまだ量産出荷されていない[5][6]。
運用上の本丸は CMVP（FIPS 140-3）認証 である。キューが12〜18か月あり、2026年9月の140-2失効・2027年1月のCNSA 2.0期限と衝突する[11][12][14]。
日本側は、CRYPTREC暗号リストが2026年3月改定で ML-KEMを表2（PQCリスト）へ収載済み（ML-DSAは評価中）。一方でJCMVPの暗号モジュール認証は2024年4月から新規受付を停止中であり、ここが日本側のクリティカルパスになる[15][16][17]。

図1：TPM 2.0 v1.85は「仕様対応」には到達したが、「調達・本番運用」までには実装供給とCMVP/JCMVP認証の谷が残る。本稿の主張を一枚で表すと、この図になる。

1. 基本情報

項目	内容
文書名	Trusted Platform Module 2.0 Library Specification
バージョン	Version 185（v1.85）
正式版公開	2026年3月12日（Part 0／Part 1 pub）[2][3]
主な前段	RC2：2025年7月1日／ RC4：2025年12月11日[2]
策定団体	Trusted Computing Group（TCG）
追加されたPQC	ML-KEM（FIPS 203）／ML-DSA（FIPS 204）[1]
併せて追加	Curve25519／Curve448（現行暗号、ISO 15118互換）[1]

TPM（Trusted Platform Module）は、鍵の安全な格納、measured boot、remote attestationなどを担うハードウェアのRoot of Trustである。その共通仕様を策定するTCGが、v1.85で初めてPQC能力を追加した。仕様開発には約100名が関与し、TPM 2.0アーキテクチャの貢献者としてDavid Wooten、参照コードの提供元としてMicrosoftが謝辞に挙げられている[2]。

2. 対応アルゴリズム：ML-KEM と ML-DSA

採用されたのは2つで、用途が明確に分かれている[1]。

図2：ML-KEMはEndorsement Key（EK）を含む鍵確立とHNDL対策に、ML-DSAはAttestation Key（AK）を含む署名とRemote Attestationに対応する。SLH-DSA／FN-DSAは対象外である。

1点目はML-KEM（FIPS 203、鍵カプセル化）で、Endorsement Key（EK）を含む鍵確立に使用する。パラメータセットはML-KEM-512／768／1024である。

2点目はML-DSA（FIPS 204、署名）で、Attestation Key（AK）を含む署名に使用する。パラメータセットはML-DSA-44／65／87である。

運用設計上いちばん重要なのは、EKにML-KEMを使う意味である。攻撃者が現在の暗号化トラフィックを記録し、将来の量子計算機で復号するHNDL（Harvest Now, Decrypt Later）シナリオに対し、EKをPQC化することで長期的な機密性を確保できる、という設計意図がTCGの公式リリースで明示されている[1]。長寿命の秘密ほどHNDL曝露が大きいため、ここを先に固めるのは理にかなっている。

スコープとして明確にしておくべき点として、SLH-DSA（FIPS 205）やFN-DSA（Falcon）はv1.85に含まれていない。格子ベースのML-KEM/ML-DSAのみで、ハッシュベース署名は今回の対象外である。また仕様コアにハイブリッド（PQ/T併用）モードを規定する記述は見当たらず、これらはスタンドアロンのPQCアルゴリズムとして導入されている[1]。

PQCとは別に、v1.85ではCurve25519とCurve448も追加され、ISO 15118などこれらの曲線を使うプロトコルとの互換性が改善された。こちらは現行暗号側の拡張だが、同一リリースに含まれる[1]。

3. アーキテクチャ上の変更点

PQCアルゴリズムを足しただけではなく、TPMの内部構造にも手が入っている。

1点目はLabeled KEMフレームワークである。Part 1（Architecture）の構成では、RSA Labeled KEM、ECC Labeled KEMに加えてML-KEM Labeled KEMが新たに定義されており、KEMを統一的な抽象化の枠組みに整理したうえでML-KEMを組み込んでいる[3]。

2点目はメッセージ全体への署名と新コマンドである。ML-DSAは、従来のdigestベースの署名ワークフロー（ハッシュ値に署名する方式）を置き換え、メッセージ全体に署名する方式を採る。任意サイズの大きなメッセージをTPM内のPQCエンジンで安全に処理するため、シーケンスベースの署名・検証コマンドが追加された。実装側（wolfSSL）のドキュメントによれば、v1.85で追加されるPQC関連コマンドは、TPM2_Encapsulate／Decapsulate（ML-KEM用）、SignDigest／SignSequenceStart／SignSequenceComplete（ML-DSA署名）、VerifyDigestSignature／VerifySequenceStart／VerifySequenceComplete（ML-DSA検証）の8つである[5]。なおコマンド名の厳密な確認はTCG仕様Part 3との突合が望ましい。

3点目は鍵の永続化である。ML-KEMとML-DSAは鍵・署名・暗号文のサイズが大きいため、永続化にあたっては鍵本体ではなくseedのみを保存することを前提とした設計になっている[4]。

4. プラットフォーム要件：PC Client Profile

ライブラリ仕様（汎用）とは別に、プラットフォームごとに必須要件を定めるプロファイルがある。PC Client向けでは次の要件が示されている（執筆時点で確認できたのはRC1段階のドラフトである）[4]。

1点目として、TPMはML-DSA-65またはML-DSA-87のいずれかをSHALL（必須）でサポートする。2点目として、ML-DSA-44／65／87をSHOULDでサポートする。3点目として、ML-KEM-512／768／1024をSHOULDでサポートする。

EK証明書の運用面では、PQC EK証明書をfield upgradeで後から提供できる場合に、EK CredentialへTCGPQCVersionという属性を付与し、どのファームウェアバージョンでEK証明書が利用可能になるかをverifierに伝える仕組みが規定されている[4]。ライブラリ仕様（正式公開済み）とこのプロファイル（RC/ドラフト）はステータスが異なる点に注意したい。

5. 実装とリリース動向

仕様が出たことと、製品として手に入ることは別である。実装の現状を層に分けて見る。

図3：実装は「ファームウェアTPM（入手可能）」「ディスクリートTPM（開発・サンプル段階）」「認証済みPQC TPM（実運用の本丸）」の3層に分かれる。PQC署名で保護されたファームウェア更新は、v1.85 PQC TPMとは別物である。

5.1 ファームウェアTPM（入手可能）

唯一すでに動かせるのがファームウェアTPMである。wolfSSLが2026年5月に、v1.85準拠でML-DSA-44/65/87・ML-KEM-512/768/1024をフルサポートしたファームウェアTPM（fwTPM）実装をリリースした。FIPS 203/204準拠を謳い、NIST ACVPテストベクタで検証しているとする。Cortex-M33ベアメタル、STM32セキュアエンクレーブ、Linuxなど、ディスクリートTPMシリコンが使えない領域がターゲットである[5][6]。物理的耐タンパ性が要らない用途であれば、ボード再設計なしにソフト更新でPQCに対応できる、という位置づけになる。

5.2 ディスクリートのハードウェアTPM（まだ量産出荷なし）

重要な現実として、v1.85のPQCコマンドをホストへ公開するディスクリートのハードウェアTPMは、執筆時点で量産出荷されていない[6]。ここで設計上区別しておきたいのは、次の2つが別物だという点である。前者はすでに存在するが、後者のディスクリート品はまだない。

1点目は、自身のファームウェア更新をPQC署名で保護するTPM。2点目は、ML-KEM/ML-DSAをTPMコマンドとしてホストに公開するv1.85 TPMである。

各社の状況は次のとおりである。

SEALSQはハードウェアで最も明確な日程を出している。本命のQVault TPM 185（TCG 1.85ベース）は、エンジニアリングサンプルが2026年7月、FIPS 140-3ラボ提出が2026年9月、TCG認証が2026年10月をターゲットとし、ML-KEM-1024・ML-DSA-87・SHA-3をサポートする[7]。製品ページ側ではサンプル供給・入手可能時期を2026年11月計画と記載しており、ES（7月）と一般サンプル（11月）で時期が分かれている読み方が自然である[8]。

Infineonは、方向性は出しているものの具体的なリリース日を公表していない。2026年6月3日のNVIDIA Jetson Thor連携発表で、ML-KEM・ML-DSAを組み込んだ次世代OPTIGA TPMでフルPQC対応を完成させるとしている。ただし現行のSLB 9672は、PQCで保護されたファームウェア更新メカニズムを備えたTPMという位置づけであり、ML-KEM/ML-DSAをホストへ公開するv1.85 TPMではない[9]。

STMicroelectronicsは、STSAFE-TPMがLMS署名で保護されたファーム更新を持つCommon Criteriaソリューションで、SHA-3アクセラレータ搭載のPQC-ready製品を提供している。最適化されたPQCアクセラレータと暗号ライブラリを備えた新製品が開発中とされるが、PQC TPM固有の日付は示されていない[10]。

6. 運用の本丸：CMVP / FIPS 140-3

「対応TPMが出れば運用できる」かというと、規制調達の世界ではそうはいかない。バインディングな制約はTCG認証ではなくCMVP（Cryptographic Module Validation Program）証明書の方で、しかも今回はそれが一番きついタイミングで効いてくる。

6.1 二段ゲート：アルゴリズム確認とモジュール認証

アルゴリズムレベル（CAVP）は目処が立っている。FIPS 140-3 Implementation Guidance（IG）10.3.A（自己テスト要件）が、FIPS 203（ML-KEM）・FIPS 204（ML-DSA）・FIPS 205（SLH-DSA）について更新済み（2026年4月9日版IG）で、ACVPベクタも揃っている[13]。

問題はモジュール認証（CMVP）の滞留である。CNSA 2.0は2027年1月開始の新規調達でML-KEM-1024・ML-DSA-87を要求し、署名生成を行うシステムにはNISTデータベース上の証明書によるフルCMVP認証を求める[12]。一方でCMVPは提出から有効な証明書まで12〜18か月かかり（2024年初頭の集計では、初回レビューだけで平均約1年、後続フェーズまで含めると約1.6年）、これは一時的なバックログではなく検証プロセスの構造的特性とされている[14]。そして「in-process」ステータスは、FedRAMP評価・監査・検査のいずれにおいても有効なコンプライアンス状態として受け入れられない。csrc.nist.govに検証済み証明書番号がなければ、検証不能な自己申告に過ぎない、という整理である[14]。

TPMはディスクリートの物理モジュールであり、物理セキュリティレベルを含むハードウェア試験を伴うため、最も時間がかかる経路に乗る。前述のSEALSQの「ラボ提出2026年9月」も、これは提出であって証明書発行ではない[7]。仕様公開が2026年3月、ESが年央、そこから十数か月のキューだと、v1.85 PQC TPMの有効証明書は現実的に2028年前後にずれ込む計算になる。

6.2 2026〜2027年の締切衝突

図4：v1.85公開（2026/03）とfwTPM実装（2026/05）は早い一方、FIPS 140-2失効（2026/09）・CNSA 2.0開始（2027/01）・CMVP認証待ち（2027〜2028）が短期間に重なる。結果として、有効なCMVP証明書が揃う現実ラインは2028年前後にずれ込む。

この遅延が規制側の締切と正面衝突する。1点目は、2026年9月21日にFIPS 140-2の検証がすべてHistorical Listへ移行する点で、140-2のみのモジュールは連邦調達で不利になる[11]。2点目は、2027年1月にCNSA 2.0のPQC要求が立ち上がる点である[12]。

「140-2失効 → 140-3必須化 → PQC必須化」が短い間隔で連続するのに、肝心のPQC TPMモジュールのCMVP証明書の供給が間に合わない。この需給ギャップが現実的なリスクである。緩和策は、早期ラボ提出でキュー待ち曝露を最小化することと、当座をハイブリッド構成でしのぐ設計、そしてアルゴリズムを差し替え可能にするcrypto-agilityを設計段階で確保しておくことである。

7. 日本の視点：CRYPTREC と JCMVP

日本での政府調達やGPKI連携を考えると、CRYPTREC暗号リストとJCMVP（暗号モジュール試験及び認証制度）の動向も外せない。ここは米国とは建付けが異なり、しかも2026年に入って大きく動いている。

まずCRYPTREC暗号リストである。2026年3月30日に改定版（CRYPTREC LS-0001-2022R2）が策定され、電子政府推奨暗号リストに「表2 耐量子計算機暗号（PQC）リスト」が新設された。ここに公開鍵暗号の鍵共有としてML-KEMが収載され、パラメータセットはML-KEM-768（Category 3）とML-KEM-1024（Category 5）である。一方で署名は「該当なし」のままで、ML-DSAはまだ推奨暗号リストには入っていない[15]。CRYPTRECはML-KEMの安全性・実装性能評価を先行実施しており、ML-DSA（FIPS 204）やSLH-DSA（FIPS 205）の評価は2026年度中に終了予定とされている[16]。

ここは本稿のテーマとも重なる対応関係になっている。TPM v1.85がML-KEM（鍵）とML-DSA（署名）の両方を載せたのに対し、日本の推奨暗号リスト側は鍵共有のML-KEMが先行し、署名のML-DSAは評価中という、KEM先行・署名追従の構図である。署名側がまだ揃っていないという非対称は、国際標準と国内リストの双方で共通して見られる。

次に、運用上もっとも効くのがJCMVP側の状況である。IPAは2024年4月1日付で暗号モジュール認証の新規申請受付を停止しており、当面は暗号アルゴリズム確認のみを継続している。背景には、基盤規格がISO/IEC 19790:2025（第3版、2025年2月発行）およびISO/IEC 24759:2025（第4版）へ更新されたことがあり、現行規格に基づく新規のモジュール認証申請は受付再開時に改めて告知するとされている[17][18]。つまり、CRYPTRECがML-KEMを推奨暗号リストへ収載しても、日本国内でPQC TPMの新規JCMVPモジュール認証を取得する窓口自体が現時点で開いていない、という状態にあるのではないか？

JCMVPの承認されたセキュリティ機能は電子政府推奨暗号リスト等を基礎としているため、CRYPTRECへのML-KEM収載は将来のPQCモジュール認証の裏付けにはなる。ただしモジュール認証の入口が止まっている以上、TPM調達の実務では「いつ受付が再開されるか」と「再開後のキュー」が日本側のクリティカルパスになると見ておくのが現実的である。加えて、CMVPとJCMVPの間に自動的な相互承認がない点も効く。米国で取得した証明書がそのままJCMVPを満たすわけではないため、日米両睨みの調達では同一TPMについて二制度分の認証コストと時間を見込む必要がある。

日米の制度状況を整理すると次のとおりである。

観点	米国	日本
標準・推奨リスト	FIPS 203/204/205、CNSA 2.0	CRYPTREC暗号リスト（LS-0001-2022R2）[15]
鍵確立（KEM）	ML-KEM	ML-KEM-768/1024 収載済み[15]
署名（DSA）	ML-DSA	ML-DSA 評価中（未収載）[15][16]
モジュール認証	CMVP（FIPS 140-3）	JCMVP
実務上の壁	認証キュー（12〜18か月級）[14]	新規受付停止（2024年4月〜）・再開時期未定[17]

8. 実務担当者向けチェックリスト

最後に、PQC TPMを検討する立場で押さえておきたい実務ポイントを整理する。

v1.85対応のPQC TPMと、PQC署名で保護されたファームウェア更新を混同しない。後者は既存製品にもあるが、ホストへPQCコマンドを公開するv1.85 TPMとは別物である。
ファームウェアTPMで検証できる範囲と、ディスクリートTPMでなければ満たせない要件（物理耐タンパ性など）を切り分ける。
調達要件にCMVP（または将来のJCMVP）の証明書番号が必要かを早めに確認する。JCMVPは2024年4月から新規モジュール認証の受付を停止している点も踏まえる。
ML-KEM/ML-DSAのパラメータを固定前提にせず、アルゴリズムとパラメータを差し替え可能にするcrypto-agilityを設計段階で確保する。
2026〜2028年は認証の供給が締切に追いつかない前提で、ハイブリッド構成や段階移行を計画に織り込む。

所感

仕様対応TPMの登場は号砲にすぎず、実運用で効くのは認証の供給と締切のタイミングである、というのが調べてみての率直な感触です。仕様（v1.85）は2026年3月に正式公開され、ソフト実装（wolfSSL）は2026年5月に出ました。一方でディスクリートシリコンはこれから認証フェーズに入る段階で、有効なCMVP証明書が揃うのは早くて2028年前後と見るのが現実的です。INTEROPやSCIS、IETFの場で語るなら、「仕様は出た・ソフトは動く・ディスクリートは認証待ち」という三層に分けて話すと誤解が少ないと思います。

技術的に興味深いのは、KEMが先行し署名が追従するという非対称が、国際標準・国内リスト・規制要件のいずれにも共通して現れている点です。TPM v1.85はML-KEMとML-DSAの両方を載せましたが、CRYPTREC暗号リストはML-KEMを先に収載しML-DSAは評価中、CMVPは署名生成にフルCMVP認証を要求します。HNDLの脅威モデルでは鍵交換側の機密性を先に固める優先順位は妥当であり、TLS WGやLAMPS WG、CFRGで進むPQC統合の議論とも整合します。EKをML-KEM化してHNDLに備えるという設計思想は、私自身がIETFで関わるPQC移行の文脈とまっすぐつながっており、ハードウェアのRoot of Trustまでこの優先順位が降りてきたことに、移行が実装層へ着実に進んでいる手応えを感じます。

調達の実務担当の立場で一点だけ申し添えると、ここで効くのはcrypto-agilityの確保です。アルゴリズムとパラメータを後から差し替えられる前提で設計しておけば、認証の供給が締切に間に合わないという今回の需給ギャップにも、ハイブリッド構成や段階移行で対応の幅を残せます。

参考文献

暗号の2030年問題として注目されているPQC暗号移行ですが、実施しなければならないけど自力では厳しいところが多いと思います。そのような状態になっている方は気軽にお声がけください。
本記事に関するお問い合わせは、GMOコネクトお問合せフォームよりお願いいたします。
https://gmo-connect.jp/contactus/

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up