前略、母さん、PQC移行が心配です / 開発者向けブログ・イベント

この記事は GMOインターネットグループ Advent Calendar 2025 25日目の記事です。

はじめに

こんにちは！GMOグローバルサインの漆嶌(うるしま)です。

近年、量子コンピューターという爆発的な計算力を持つコンピューターが開発されており、計算に時間がかかることで守られたてきたこれまでの暗号が解読されてしまう可能性があります。量子コンピューターが実現したとしても解読されにくい暗号として耐量子計算機暗号(PQC、Post-quantum cryptography)が開発されました。

いろんな国や業界から暗号をPQCに移行するためのガイドラインが出ており、エライ人から「君、我が社のPQC移行の計画を立てて推進してくれたまえよ。」なんて言われて困っている人がいたり、心配になってどうしようか悩んでいる人もいるかなと思います。

安易に「2030年までにPQCに移行しろ」という人が多い中、「そう簡単じゃないんだよ。まだまだ課題がいっぱいあるんだよ。」ってことを紹介したいと思います。(あまりクリスマスにふさわしくありません。)

RSA 2048ビットの公開鍵暗号はいつ破られそうか？

現在多くの利用者証明書ではRSA 2048bitの公開鍵暗号が使われており、これがいつ破られそうかがみんなの関心事になっています。

Craig Gidneyが2019年に「誤り率0.1%以下の2000万量子ビットを持つ量子コンピューターがあれば、RSA 2048bitを8時間程度で解読できる」と予測する論文を発表しました。そして2025年5月、Gidneyは新しい論文を発表し「RSA 2048bitはで誤り率が同程度の100万量子ビット未満の量子コンピューターで(多少時間を犠牲にして)1週間で解読可能」と予測しました。NTTとOptQCが共同で「2030年までに100万量子ビットの実現を目指す」としていると2030年ごろ破られてしまう可能性も出てきたということでしょうか？

その他にも予測は様々で[「2039年よりも前にRSA 2048が解読される可能性は5%未満」とする研究発表や、「(2024年時点で)2039年までにRSA 2048が解読される可能性は39〜62%」という白書もあります。

とある2025年10月のカンファレンスでは量子コンピューターの開発者の方が「(予測はいろいろですが)2045年にはRSA 2048が解けそうかなぁなんて思ってます。」と仰ってたりもしました。

実際にいつ破られるかは別にして公開鍵暗号のPQC移行は2030〜2035年ごろには済ませておかないといけなそうです。

アプリケーション毎のPQC移行準備状況

PQC移行が必要そうなアプリケーションはTLS、SSH、X.509証明書などありますが、標準の策定状況、実装状況、市場普及状況などをPost Quantum Cryptography Coalitionがヒートマップの形で毎月公開してくれており、12月分を引用して貼っておきます。

やはり、鍵共有が署名よりも遅れているのがよくわかります。標準化までのステップがとても細かいですが、そこからが長いですよね。7の「Integrated in Libraries(ライブラリに標準が組み込まれた)」って言ってもそこからが普及まで遠いわけで、、、、

PQC対応暗号ライブラリ、ソフトウェアの状況

OpenSSL(3.5以降): Open Quantum Safeが3.5より標準サポートされた暗号ライブラリ。Apache HTTP Serverなどでも利用される。
Bouncy Castle: Java用暗号とPKIのライブラリ
Open Quantum Safe(liboqs): OpenSSL 3系向けのプロバイダとして提供されているPQCライブラリ
wolfSSL: 組み込み機器でよく使用されている暗号ライブラリ

最もメジャーな暗号ライブラリであるOpenSSLが3.5になってPQC対応されて良かったなぁと思います。ちょっと残念なのは2点

PQC Hybrid暗号に対応していない(pure PQCのみ)
(smime, cmsは対応済な一方で)タイムスタンプ(ts)がPQCに対応していない

OpenSSLのタイムスタンプはとても古いCMSベースじゃないPKCS#7ベースのコードでメンテされていんですよね。issueとしてはインプットしてみたんですが、なかなか対応されなそう。

もう一点、PQC移行が心配なのが多くのブラウザに標準搭載されているW3C Web Cryptographyです。OpenID系の方々とか結構使ってらっしゃるのかなと思い、そのPQC対応が見えないのでちょっと心配しています。

世の中にあふれるPQC移行ガイドライン

2030〜2035年ぐらいには既存の公開鍵暗号からPQCに移行しとかないと、いよいよヤバそうだなということで、様々な国、業界、組織からPQC移行に関するガイドラインが公開されています。

内容は似たり寄ったりな面も多くて全部に目を通す必要はないと思います。ざっくり以下のような移行ステップが書かれていることが多いです。

準備
– 資産棚卸し
– 経営層、IT部門、セキュリティ部門を巻き込み責任者を任命
現状把握
– 各資産が使う暗号の棚卸し
– 影響評価、リスク評価、優先順位決め
移行
– 暗号の選定、開発、実装
– パフォーマンステスト
モニタリング
– 問題ないか？

私が是非おすすめしたいガイドラインは2つ

脆弱性情報提供で有名なMITREの組織。割と簡潔。
– Post Quantum Cryptography Coalition: Post-Quantum Cryptograpy (PQC) Migration Roadmap (2025.05)
大ボリュームだけどとてもおすすめ。ケース分け、移行フローも秀逸。背景情報も充実。
– オランダ政府: The PQC Migration Handbook(2024.11)

特にPKI、署名関連のPQC移行計画の策定を阻む多くの壁

PQC鍵共有は良いがPQC署名への移行がヤバい

PQC暗号移行には2つの種類。

ML-KEMなどの鍵共有アルゴリズム: 暗号通信の開始・更新のための鍵共有
ML-DSA、SLH-DSAなどの署名アルゴリズム: 署名や認証のために用いられる

鍵共有については通信する双方の実装だけが対応していればよく、標準化も普及も順調でウェブブラウザやクラウドサービスでも既にPQC対応済です。VPN製品などのネットワーク機器なども順次対応製品が出てくるでしょうし、それを使えばいいだけなので話が簡単です。

その一方で、PQC署名アルゴリズムやこれを使用するシステムの移行は関係が複雑で移行には相当時間がかかりそうです。多くのPQC移行ガイドラインで2030年とか2035年とかまでにはPQC移行すると言っていますが、相互に依存関係があり「ニワトリと卵」のような状態で一筋縄では行かなそうです。移行を妨げる多くの壁について紹介したいと思います。

認定を受けたHSM製品、スマートカード、USBトークンの不在

デジタル証明書を発行する認証局やデジタルタイムスタンプを発行するタイムスタンプ局などではハードウェアセキュリティモジュール(HSM)と言われるハードウェア製品で暗号鍵を管理しています。今年あたり、PQC署名アルゴリズムに対応したHSM製品が出始めましたが、TLSサーバー証明書などパブリックな証明書を発行する認証局は、FIPS 140 Level3やCommon Criteria(CC) EAL4+といったセキュリティ評価制度の認定を受けた製品を使用する必要があり、これらの認定品が出てくるのが来年ごろと言われているようです。結果的にPQC対応TLSサーバー証明書、コードサイン証明書などが出てくるのもそのずっと後ということになりそうです。

スマートカード、USBトークン、TPMチップについても同様で、FIPSやCC認定品は出ていないので、認定品を使用することが要件となっている制度、ガイドラインは注意が必要です。

パブリックな認証局、証明書のガイドラインの対応

パブリックな認証局はCAブラウザフォーラム(CABF)のガイドラインに準拠していますが、PQC対応の認証局への対応にはまだまだ時間がかかりそうです。

CABFでは証明書の用途種類毎に基本要求(baseline requirements)をまとめたガイドラインが発行されています。

TLSサーバー証明書の基本要求(2025年12月 2.2.1版): 対応予定未定
コードサイン証明書の基本要求(2025年11月 3.10.0版): 対応検討中
S/MIMEメール証明書の基本要求(2025年10月 1.0.12版): PQC(ML-DSA,ML-KEM)対応済

現時点ではS/MIME証明書が対応済、コードサイン証明書が対応検討に向けた議論中、最も利用されており影響の広いTLSサーバー証明書については議論の開始が遅れているようです。前述に加えてここでもTLSサーバー証明書の認証局のPQC移行は遅くなりそうです。

PQC証明書に対応するウェブブラウザの不在

Chrome、Edge、Safari、Firefoxなど主要なウェブブラウザは全てPQC証明書に対応しておらず、対応計画も明らかになっていないと認識しています。前述のパブリック認証局の対応が遅くなっていたとしても、OpenSSLが既にPQC対応していることによりHTTPサーバーもPQC対応しているので、プライベート証明書を使ってPQC証明書対応HTTPS通信が使えるようになっててもいいのではないかと思います。パブリック認証局の対応を待たずに早くウェブブラウザでもPQC証明書対応されると良いなと思います。

ルートプログラムのPQC対応

OSやブラウザにはルート(認証局)プログラムというものがあり、OSやブラウザでデフォルトで信頼されるルート認証局のリスト搭載、認定をする際の基準が定められています。プログラムによっては現時点ではPQCアルゴリズムのルート証明書に対応していないものもあり、これらのPQC移行も早めに進めていただく必要があるようです。改訂は文言だけの話なので、早めに認められるようになると良いと思うんですけどね。

Chrome Root Program: アルゴリズムには依存せず
Microsoft Root Program: RSA、ECDSAに制限
Apple Root Program: S/MIMEのみRSA、ECDSAに制限
Mozilla Root Program: RSA、ECDSA、EdDSAに制限

CRYPTREC電子政府推奨暗号に影響するシステム

CRYPTRECでは、[日本の電子政府が調達のため参照すべき暗号リスト(CRYPTREC暗号リスト)](https://www.cryptrec.go.jp/list.html)を定めていて、民間でもこのリストがガイドライン等で参照され要件になっていることがあります。現時点では、ML-DSAやML-KEMといったPQC対応の暗号は掲載されていないので、リストに厳密に準拠するシステムはPQCが使えないということになってしまいます。

CRYPTREC暗号リストは3つの種類のリストで構成されています。

電子政府推奨暗号リスト: 安全で市場利用実績があり利用を推奨する暗号
推奨候補暗号リスト: 安全で将来電子政府推奨暗号リストに記載される可能性がある暗号
運用監視暗号リスト: リスクが高まり推奨はできないが、互換性維持のために利用を容認する暗号

例えば、総務大臣の認定タイムスタンプでは実施要項に「電子政府推奨暗号リストに記載された公開鍵暗号技術を使うこと」となっています。CRYPTREC暗号リストでは、その暗号が日本で使って大丈夫かどうか安全性を評価し、最初に「推奨候補暗号リスト」に記載され問題がなければ次の改訂の際に「電子政府推奨暗号リスト」に記載されるという流れになっているそうです。評価に必要な時間、記載初版と改訂を考えるとPQCが記載されるまでに4〜5年かそれ以上かかりそうで一部のPQC移行期限の2030年を超えてしまいそうです。CRYPTREC暗号リストの影響を受ける制度は、それから数年を経て利用可能になるかもしれません。CRYPTREC暗号リストのPQC対応を待たずに、開発などできるところから先行して準備を進めておくなどの工夫が必要そうです。

PQCの記載については、緊急措置、特別措置としてこれまでと違う記載に向けたプロセスが必要なのではないかと心配しています。

コード署名におけるLMS、XMSSの利用

ソフトウェアの改ざんから保護し製造者を証明するためにコード署名という方法が使われています。

米国の政府システム調達に関する新しい基準CNSA 2.0では、
様々な暗号利用用途の中でもソフトウェア、ファームウェアの移行は特に緊急性が高いとして以下と定めています。

2022年時点でも他よりも先に至急移行に着手しなければならない
他よりも早く2030年までには移行が完了しなければならない
使用するアルゴリズムはML-DSA署名アルゴリズムではなくハッシュベースのPQC署名アルゴリズムであるLMS、XMSSを使わなければならない

誤解していたらごめんなさいですが、このLMS、XMSSは少し厄介で、署名の度に秘密鍵がアップデートされます。認証局の秘密鍵はHSMを使うことになっていますが、何か問題が起きて秘密鍵をバックアップ、リストアする際に、巻き戻った秘密鍵を使用した場合、その間行った署名の扱いはどうなるか？という問題がありそうです。

HSMベンダーはこのあたりを想定して、特許を取得した方式や様々な方法で対処するそうですが、これまでは秘密鍵は固定だったという常識から外れることになり、想定外の問題が起きないかと心配しています。

結局、2025年12月時点、どう対処するのがいいのか？(私見)

2025年12月の現時点から1年くらいは、PQCに対応するソフトウェアもハードウェアもOSも十分には揃っておらず、PQC移行計画の技術的な詳細真面目に検討してもしかたないと思います。
経営層、IT部門、開発部門、セキュリティ部門を早めに巻き込んで、移行責任者を決め、ざっくりした計画と棚卸しを始めましょう。
システムの棚卸しは早めにしておいた方がいいと思います。棚卸しもCBOMのように真面目にする必要はなく、おおまかな棚卸しをするだけで十分だと思います。
情報収集は重要です。使用しているHSMベンダー、スマートカードベンダー、VPNなどのネットワーク機器ベンダー、OSベンダー、PKIベンダーから提供される情報はこれからも継続的に入手してください。2026年あたり、対応するハードウェア、OSの情報がアップデートされ真面目に検討できるようになりそうです。注視しといてください。詳しそうな人を誰か抱えて聞けるようにしておくのでも良いと思います。
PQC対応のライブラリも出はじめてきたので、システムの試作、署名のパフォーマンステストなんかはしておくと良いです。

資産や暗号の棚卸し

システム資産、暗号資産の棚卸しは、現時点ではざっくりで埋められるとこだけ埋めるで良いように思います。棚卸しで管理したほうがよさそうな項目は以下でどうでしょうか？

名称: 資産、システムの名称
– 担当者、主幹部門
– 優先順位と対応
PQC移行の緊急度
– 移行アクション: システム修正か再構築か機器リプレースか廃棄かなど
システムと共通鍵暗号
– 機密性: 求められるデータの機密性
– 耐用年数: システムやデータを保護すべき年数
– 署名か鍵共有かそれ以外か
– 公開鍵アルゴリズム: システムが使用する公開鍵アルゴリズムと鍵長
依存関係
– 外部依存: 自社開発か外部ベンダー製品か
– 暗号モジュール: 使用している暗号モジュール、ライブラリ、ソフトウェア
– 依存する制度: 依存している制度、ガイドライン、標準(金融庁ガイド,大臣認定,CRYPTREC,CNSA2,CABF等)

最近、ソフトウェア部品表(SBOM: Software Bill of Material)を整備してライブラリなどの脆弱性の依存関係を調べやすくするといった活動の一環で、暗号部品表(CBOM: Cryptography Bill of Material)を整備しましょうという話も聞きます。しかしながら、依存しているライブラリや製品のベンダーが作ってくれないと作るのも管理するのも大変ですよね。現時点ではCBOMを使ってPQC移行の調査をしよう、進めようとするのは「労多くして益少なし」な気がしてやめておいた方がいいように思います。

テスト用PQC証明書

宣伝っぽくてすみません。他社も始めているようですが、弊社GMOグローバルサインからもテスト用PQC証明書をご提供させていただいております。

TLSサーバー証明書
クライアント証明書
ドキュメント署名用証明書
S/MIME用証明書

など、様々な用途のテスト用証明書を発行することができ、失効情報も定期更新しており、証明書拡張の値などの記載内容も比較的柔軟にお受けできると思いますので、よかったら社内検証、開発の用途でご利用ください。

PQC移行で勇気づけられた講演の話

最後に一つ紹介させてください。

2025年10月にマレーシアのクアラルンプールでPKI Consortiumという団体によるPQC Conference 2025というカンファレンスが現地とオンラインで開催されました。その中で、オランダ政府システムのPQC移行の責任者であるPieter Schneider氏の講演がとても勇気づけられました。講演の感動ポイントをいくつか紹介します。

PQC移行は短距離走じゃない、マラソンだ。
PQC移行は単なるITプロジェクトではなく技術的と非技術的な多くの要素が複数のレイヤーで構成されていて、とてもじゃないが単一の組織では対処することができない。
君は一人ではない。一人であるべきじゃない。みんなでやっていこう。

どこか1社でもPQC移行マラソンを完走してインタビューを放送してくれたりすると、救われた後続がどんどん出てきてみんな幸せになれるんじゃないかと思いました。

おわりに

以上、現時点では多くのシステムがPQC移行の具体的な計画を立てるには課題が多くて早すぎるということ、最低限、リーダーシップを決めて、システムの棚卸しをし、動向のウォッチをしておけば十分んなんじゃないか？システムの実装はこれからになりそうということをご紹介しました。

なんか、PQC移行を心配する個人的な想いがあふれて、長文になってしまいごめんなさい。

PQC移行に関係しそうな、あるいはしてしまった多くの方々が来年も幸せでありますように。メリークリスマス。