基礎から学ぶPQC　～量子コンピュータ時代に備える、耐量子暗号（PQC）への移行戦略

量子コンピュータという新たな脅威

現代のデジタル社会は、暗号技術という見えない基盤の上に成り立っている。TLS、VPN、PKIなどのサービスは、共通鍵暗号方式と公開鍵暗号方式を用いて情報の機密性と完全性を担保している。

しかし量子コンピュータの登場により、これらの暗号技術が根本から脅かされる可能性が現実味を帯びてきた。

量子コンピュータは、従来のコンピュータでは非現実的だった素因数分解や離散対数問題を短時間で解く能力を持ち、RSAやDSAなどの公開鍵暗号方式を破ると予測されている。

特に、「Harvest-Now、Decrypt-Later（HNDL）」攻撃（図表1）は、今から暗号化データを収集しておき、将来的に量子コンピュータの性能が向上した時点で解読を試みる攻撃である。

このHNDL攻撃により、量子コンピュータが実用化した時点で即座に機密データが解読される恐れがある。したがって、量子コンピュータへの備えは「未来の話」ではなく、「今日始める必要があるTo-Do」であると言える。

PQC（耐量子暗号）とは何か

PQC（Post-Quantum Cryptography）は、量子コンピュータでも効率的に解けない数学的問題に基づいた新しい暗号方式である。

従来の暗号が素因数分解や離散対数に依存していたのに対し、PQCは格子問題や符号理論など、異なる数学的基盤を採用している。共通鍵暗号方式は、鍵長を2倍にすることで量子コンピュータに対しても安全性を維持できる一方、公開鍵暗号方式はPQCへの移行が必要となる（図表2）。

NIST（米国国立標準技術研究所）は2016年からPQCの標準化を進めており、2024年には鍵交換用アルゴリズムのML-KEM、デジタル署名用アルゴリズムのML-DSAやSLH-DSAをFIPS（Federal Information Processing Standard）として標準化した。日本でもCRYPTRECがPQCに関するガイドラインを公開し、今後の標準化に向けた検討が進められている。

PQCへの移行戦略─4つのステップ

以下の4ステップ（図表3）を実行することで、組織として戦略的にPQCへの対応を進めることが可能になる。

STEP1の暗号資産棚卸し（クリプト・インベントリー）は移行の第1歩として非常に重要である。クリプト・インベントリーは暗号アルゴリズムの詳細を管理する仕組みであり、インベントリー（管理台帳）を構築し、組織内の暗号利用箇所、つまりクリプト・プロパティーを特定することで準備が完了する。

STEP1　暗号資産棚卸し（クリプト・インベントリー）
組織内で使用されている暗号技術の種類、鍵長、保存場所、利用目的などを網羅的に把握する。

STEP2　優先順位決定とロードマップ策定
HNDL攻撃の影響度や法令遵守の観点から、移行の優先度を定め、段階的な対応計画を立案する。

STEP3　移行計画・実装設計の策定
対象システムの選定、PQCアルゴリズムの選択、実装方針の決定を行う。

STEP4　PQC移行計画、実装設計の実行
実際のシステム改修と運用体制の整備を進め、継続的な情報収集と評価を行う。

PQC未対応の場合に想定されるリスク

PQCへの移行戦略の重要性について解説してきたが、ここで移行対象となる通信やシステム、データに具体的にどのようなリスクが想定されるのか挙げていきたい。

一般的なWebシステム構成において、PQCへの移行が未実施のまま量子コンピュータが実用化された場合に想定されるリスクポイントを示す（図表4）。

 

・HTTPSの盗聴による機密データの漏洩
・VPN通信の盗聴
・サーバー証明書、クライアント証明書の窃取によるなりすまし
・電子署名の偽造による中間者攻撃（MITM）
・SSH認証情報の漏洩による不正アクセス
・暗号化データの解読による情報漏洩

通信経路、認証、データの保管場所など、システムのさまざまな箇所に潜在的なリスクが存在していることが理解できたかと思う。これらのリスクは、企業の信頼性や事業継続性に直結するものであり、PQCへの移行を先送りすることは、将来的なセキュリティ・インシデントの温床となりかねない。

したがって、PQC対応は喫緊の課題であり、特に「HTTPSの盗聴による機密データの漏洩」はHNDL攻撃にさらされるリスクが大きいため、早急な対応が求められる。よって、ここからは「HTTPS（TLS）のPQC対応」にフォーカスして詳細に解説したい。

TLSのPQC対応とハイブリッド・アルゴリズム　

HTTPSはTLSの仕組みを利用してセキュリティを担保している。TLSは、インターネット上の通信を暗号化する主要なプロトコルであり、Webサービス、API通信、クラウド接続など、あらゆる場面で利用されている。

TLS v1.3では鍵交換・認証・電子署名に公開鍵暗号方式が使われており、PQC対応のためにはこれらをPQC対応アルゴリズムに置き換える必要がある（図表5）。

また、PQC対応はTLS v1.3が前提となり、v1.2では対応が不可なことに注意してほしい。

このうち、「鍵交換アルゴリズム（KEM）」のPQC対応が最優先事項であると言われる。なぜなら、鍵交換で使用されている従来の公開鍵暗号方式が解読されると通信データが解読されるため、HNDL攻撃により量子コンピュータが実現した時点ですぐに機密データが漏洩してしまう恐れがあるためである。

この鍵交換アルゴリズムでは、ハイブリッド・アルゴリズムの使用が推奨されている。

ハイブリッド・アルゴリズムとは、従来の暗号方式（レガシー・アルゴリズム）とPQCアルゴリズムを併用することで、どちらかが破られてももう一方で安全性を担保する“保険”の役割を果たすものである。

たとえば、X25519（レガシー・アルゴリズム）とML-KEM768（PQCアルゴリズム）を組み合わせた「X25519MLKEM768」というハイブリッド・アルゴリズムは、Google ChromeやCloudflareのテスト環境ですでに利用可能である。

PQCへの移行案

図表6にある企業ネットワーク構成のサンプル図で、TLSのPQCへの移行案を紹介する。

こちらは、外部ユーザーがHTTPSで企業ネットワーク内のWebサーバーに接続する構成となっている。図表6のようにPQC非対応のWebサーバーに対しては、ハイブリッド・アルゴリズムおよびPQCアルゴリズムにのみ対応する外部ユーザーは接続できない。

まず移行案1として考えられるのは、Webサーバーの前にPQC対応のリバース・プロキシーを置くパターンである（図表7）。

ここでTLS終端を行い、KEMの変換を行うことで、ハイブリッド・アルゴリズムもしくはPQCアルゴリズムのみに対応する外部ユーザーが、PQC非対応のWebサーバーに問題なく接続できるようになり、互換性の問題（ハイブリッド・アルゴリズム、PQCアルゴリズムで接続する外部ユーザーに対応できない）は解消される。

一方で、レガシー・アルゴリズムにのみ対応している外部ユーザーはそのまま接続できるため、レガシー・アルゴリズムがインターネット上に残ってしまい、HNDL攻撃の危険性は依然として残ることになる。移行案1を実現する製品としては、IBM Quantum Safe Remediatorや、F5 BIG-IP LTMなどがある。

そこで移行案2として考えられるのが、外部ユーザー側にフォワード・プロキシーを入れるパターンである（図表8）。

こうすることで、外部ユーザー側でレガシー・アルゴリズムをハイブリッドもしくはPQCアルゴリズムに変換してから接続することが可能となり、インターネット上にレガシー・アルゴリズムが残らず、よりセキュアな通信を実現できる。

移行案2を実現する製品としては、IBM Quantum Safe Remediatorなどがある。

HNDL攻撃の脅威や移行に要するリードタイムなどを考慮すると、PQCへの対応は「将来の課題」ではなく、今すぐ着手すべき喫緊のTo-Doであるといえる。

また、PQCの標準化動向や各製品ベンダーの対応状況は日々進化しており、継続的な情報収集と適応が欠かせない。本稿が、PQC対応に向けた第1歩を踏み出す一助となれば幸いである。