PQC（耐量子計算機暗号）対応は何から始める？ 企業が取り組むべき5つのステップ

初回となる前回は、量子コンピュータによって現在の公開鍵暗号が解読可能になる日（Q-Day）をめぐる脅威や、PQC（耐量子計算機暗号）の標準化に向けた日本と米国の動き、PQCに対応しない場合のリスクについて解説しました。

今回は、PQCに関連する暗号技術を紹介するとともに、企業がPQC対応を進めるための5つのステップを解説します。

PQC対応を進める5つのステップ

企業でPQC対応を進めるプロセスは、下記の5ステップです。後ほど、ステップごとに詳細を解説します。

• ステップ1：情報資産と対象システムを棚卸しする
• ステップ2：利用している暗号技術を把握する
• ステップ3：「鍵共有」を優先して移行対象を評価する
• ステップ4：標準化と製品の対応状況を踏まえて移行計画を立てる
• ステップ5：検証を経てPQC対応を実行する

PQC対応は時間がかかるため、早めに着手し、この5つのステップによってPQC対応を始めましょう。「鍵共有」と「署名」は分けて考え、「鍵共有」を優先してPQCに対応し、「署名」は製品やアプリケーションの対応状況を確認してPQC対応を進める必要があります。

ステップ1：情報資産と対象システムを棚卸しする

前回解説した通り、PQC対応の第一歩は「クリプト・インベントリ（暗号利用状況の棚卸し）」です。まずは、自社がどのシステムやサービスで、どのような暗号アルゴリズムや鍵長を使用しているかを正確に把握することが必要です。

そこで、ステップ1では、まず、暗号を利用している“情報資産や対象システム”を棚卸しします。同時に、その情報資産の重要度や通信先も洗い出す必要があります。

下図で、暗号を利用している主な箇所を記載しています。自社での棚卸の参考にしてください。

• 

  暗号を利用している主な箇所

ステップ2：利用している暗号技術を把握する

ステップ2も「クリプト・インベントリ」の継続で、使用している“暗号技術”を棚卸しします。

ステップ1で棚卸しした資産・システムで使用している、暗号アルゴリズムや鍵長を洗い出します。

洗い出す際に注目すべき点として、量子コンピュータが実用化されると、「鍵共有（鍵交換）」に使う「DH/ECDH」や、署名に使う「ECDSA/RSA」などの公開鍵暗号が解読可能になります。つまり、PQC対応では、「鍵共有」と「署名」を新しい暗号アルゴリズムに変更することになります。

なお、共通鍵暗号に使う「AES」やハッシュ関数に使う「SHA2/SHA3」は、その暗号アルゴリズム自体は維持したままで、それぞれ鍵サイズやビット数を増やすことで、量子コンピュータに対しても十分な強度を保つことが可能です。

• 

  従来のアルゴリズムとPQC対応のアルゴリズム

それと同時に、設定変更やバージョンアップでPQCに対応できる予定があるかを確認します。開発終了した製品やアプリケーションで構築されたシステムなど、PQC対応が見込めない場合は、PQCに対応できるシステムへのリプレースを検討する必要があります。

ステップ3：「鍵共有」を優先して移行対象を評価する

棚卸した結果をもとに、対応すべきシステムの優先度を評価します。ステップ2で記載したように、PQC対応では、「鍵共有」と「署名」の暗号アルゴリズムを変更する必要があります。ただし、その変更タイミングは、「鍵共有」と「署名」で分けて考える必要があります。

鍵共有では、現在取得された暗号通信が将来復号されるHNDL攻撃への備えが必要となる一方、署名では、将来の署名偽造やなりすましへの対策が重要になります。そのため、長期間の機密性が求められる通信については、まず「鍵共有」のPQC対応を優先する必要があります。

脅威が生じる時期が異なる理由を解説します。

「鍵共有」は、SSL/TLSやIPsecなどで暗号通信を開始する前に、公開鍵暗号で安全に通信先と共有秘密（Shared Secret）の値を共有する処理です。暗号通信は、その共有秘密の値を使ってデータを暗号化するため、共有秘密の値が分かると、暗号通信の中身を復号して見ることができてしまいます。

つまり、前回解説した、「HNDL（Harvest Now, Decrypt Later：今採取して後から解読する）」の考え方で、現時点で攻撃者が暗号通信を盗み取って保存しておけば、Q-Dayを迎えた後に共有秘密の値を解読し、暗号通信の中身を復号して見られてしまう可能性があります。長期間の機密性が求められるデータに対する脅威は、「既に」始まっているのです。

一方で、「署名」は、サーバ証明書やOSイメージの署名などで、データの完全性や署名者が正しいことを確認できる処理です。よって、鍵共有と異なり、現時点データを盗み取って保存しても意味がありません。「Q-Dayを迎えた後」から、署名の偽造やなりすましの脅威が始まります。

• 

  量子コンピュータが実用化された際の脅威と時系列

ただし、「署名」も先送りせずにPQC対応する必要があります。その理由は、Q-Dayを事前に把握できるとは限らないからです。量子コンピュータの開発が何かのきっかけで大きく加速する可能性や、安全保障の観点から量子コンピュータを実用化しても公開しない可能性も考えられます。その結果、既にQ-Dayを迎えていて、リスクにさらされていたことを事後に気づくリスクがあります。

また、長期間の機密性が求められるデータや外部と通信するシステムは暗号通信を盗み取られるリスクが高いため優先度を上げます。その一方で、同じデータセンタ内の有線LANで通信しているシステムは、暗号通信を盗み取られるリスクが低いため、優先度を下げることができます。

ステップ4：標準化と製品の対応状況を踏まえて移行計画を立てる

製品やアプリケーションがPQC対応する予定、日本政府の基準、業界動向を考慮して計画を立てます。リプレースする場合は、納期も考慮する必要があります。

2024年に米国NIST（米国立標準技術研究所）がPQC対応として、FIPS 203（ML-KEM：鍵共有）、FIPS 204（ML-DSA：署名）、FIPS 205（SLH-DSA：署名）のアルゴリズムを標準化しました。

しかし、NISTがアルゴリズムを標準化しただけではPQC対応は進みません。IETF（インターネット技術タスクフォース）などの標準化団体がPQC対応した各プロトコルを標準化し、さらに各製品やアプリケーションがその標準化に対応することで、ようやく対応可能な状態になります。

また、日本政府は政府機関等のPQC移行を原則2035年までに完了させる方針で、2026年度中に、PQC対応の工程表（ロードマップ）を策定する予定になっています。

先行して対応が必要な「鍵共有」のPQC対応状況は、各プロトコルで標準化団体による標準化と製品やアプリケーションの対応が進んでおり、バージョンアップや機器のリプレースでPQC対応できる状況です。

その一方で、「署名」では、標準化団体で議論中であったり、製品やアプリケーションの対応待ちであったりと、まだPQC対応ができない場合が多い状況です。

• 

  「鍵共有」と「署名」の標準化の状況

なお、注意が必要な点として、暗号鍵や署名を保持できるメモリや処理性能が限られたICカードやIoTデバイスなどは、リプレースが必要になる場合があります。その理由は、PQC対応のアルゴリズムは、従来のアルゴリズムと比べて鍵や署名のサイズが大きくなるためです。「ハイブリッド方式」を採用している場合は、さらに影響が大きくなります。

この「ハイブリッド方式」とは、従来のアルゴリズムとPQC対応のアルゴリズムを組み合わせた方式のことです。プロトコルによっては、より安全にするために、従来のアルゴリズムからPQC対応のアルゴリズムへの単純な置き換えではなく、双方を組み合わせる形式を採用することがあります。片方のアルゴリズムが破られても、もう片方のアルゴリズムが破られなければ安全性を保つことができるからです。

ステップ5：検証を経てPQC対応を実行する

ステップ1～4を経て策定した移行計画に基づき、製品やアプリケーションのバージョンアップ、設定変更、必要に応じた機器のリプレースを実施します。

実行にあたっては、PQC対応による処理性能への影響や、既存システムとの相互接続性を事前に検証することが重要です。また、移行後も正常に通信や認証が行えることを確認し、問題が発生した場合に備えて切り戻しの手順を用意しておく必要があります。

次回からは、具体的にネットワーク機器、セキュリティ機器、アプリケーションにおけるPQC対応について解説します。