HTTPSは量子コンピューター時代にどう変わる？

イト

HTTPSが量子対応になったら、URLのhttpsも別の文字へ変わるの？

ユイ

鍵共有と証明書とデータ暗号化は、全部同じ方式なのかな

マコト

通信相手の対応状況もあるから、一夜で一斉交換とはいかなそうだね

ピコ

量子通信港の受付で、TLSの役割を三つに分けよう

HTTPSは量子コンピューター時代にどう変わるのでしょうか。結論は、WebのURLやHTTPという配送の役割を捨てるのではなく、TLSで使う公開鍵暗号、特に鍵共有と電子署名を、ポスト量子暗号（PQC）やハイブリッド方式へ段階的に更新するというものです。

HTTPS全体が一種類の暗号で動いているわけではありません。接続時に共有鍵を作る仕組み、サーバーの身元を確かめる証明書と署名、その後のデータを守る共通鍵暗号が協力します。どの部品が量子脅威を受け、どの部品が残るかを整理すると、移行の流れが見えます。ピコルート・ラボのTLS工房では、三つの窓口へ違う色の札を置いて観察します。

移行を先延ばしにした時の時間差は、物語第104話「未来に開けられる保管庫」で確かめられます。

なお、本文で参照するIETF文書には2026年8月11日時点でInternet-Draftのものがあり、確定RFCではありません。方式名や移行判断に使うときは、固定した版だけでなくDatatrackerの最新状態を確認してください。

HTTPSが変わる流れを先に確認

量子対応は、次のような部品交換として進みます。

1. ブラウザとサーバーが対応方式を提示する
2. 接続ごとの秘密を作る鍵共有へPQCを加える
3. 移行中は古典方式とPQCを組み合わせる場合がある
4. 証明書の電子署名もPQC対応を進める
5. 作った共通鍵で通信データを暗号化する
6. 古い機器、プロキシ、監視装置との互換性を試す
7. 性能、通信量、エラーを監視する
8. 標準と実装が安定した範囲から古い方式を減らす

港のたとえでは、道路は使いながら、受付で合鍵を作る方法と身分証の印を順に交換します。実際には世界中のブラウザ、サーバー、証明書発行者、ネットワーク機器が関わるため、段階的な相互運用が必要です。

TLSでは何を守っている？

HTTPSとは？で扱うTLSには、主に三つの役割があります。

1. 鍵共有: ブラウザとサーバーが通信ごとの秘密を安全に作る
2. 認証: 証明書と電子署名で、接続先が正当なサーバーか確認する
3. 暗号化・完全性保護: 作った共通鍵でデータを読まれにくくし、改変を検出する

現在のTLSでは、鍵共有や署名に楕円曲線暗号やRSAなどの公開鍵暗号を使う構成があります。十分な耐故障量子計算が可能になると、これらの安全性の土台が影響を受けます。

一方、接続後の大量データにはAESなどの共通鍵暗号を使います。共通鍵暗号への量子攻撃は公開鍵暗号と同じショアのアルゴリズムではなく、必要に応じて鍵長やパラメータを見直す形になります。三役を一括して「RSAからPQCへ」と表現しないことが大切です。

鍵共有が先に使われる役割

WebでPQC導入が先行している領域の一つが、TLS接続時の鍵共有です。ML-KEMなどの鍵カプセル化方式を使い、ブラウザとサーバーが共通の秘密を作ります。

鍵共有を早く守る理由には、「現在の暗号通信を保存して、将来解読する」脅威があります。接続の記録が残っていると、将来秘密鍵や量子計算能力を得た攻撃者が過去データを読む可能性を考えます。長期秘密データでは、証明書の更新日より前から対策が必要です。

ただし新しい鍵共有は暗号文やメッセージを大きくし、通信の分割、遅延、メモリ、古い機器との相性に影響する場合があります。実験環境だけでなく、実際のネットワーク条件で測定します。

ハイブリッド方式を使う仕組み

移行期には、従来の楕円曲線鍵共有とPQC鍵共有の両方から秘密を作るハイブリッド方式が検討・導入されます。どちらか一方の安全性が後で問題になっても、もう一方が安全なら接続の秘密を守れるよう組み合わせます。

ハイブリッド方式には利点と注意があります。

• 新しいPQC方式だけへ一度に依存しない
• 既存の暗号保証を残しながら実装経験を積める
• メッセージサイズと計算量が増える
• 組合せ方法が標準に沿っている必要がある
• 途中のネットワーク機器が大きなハンドシェイクを処理できない場合がある
• 失敗時に古い方式へ無言で戻る設計は危険になる

二種類を置けば安全性が単純に足し算されるわけではありません。鍵を組み合わせる方法、エラー処理、方式選択、ダウングレード防止を含めて検証します。

証明書と署名が変わる部分

鍵共有がPQCになっても、サーバー証明書の署名が従来方式のままなら、将来の量子攻撃に対する認証の課題が残ります。証明書では、認証局がサイトの公開鍵と名前を結び付け、電子署名で保証します。

署名移行には次の関係者と制約があります。

1. ブラウザやOSの検証実装
2. WebサーバーとTLSライブラリ
3. 認証局と証明書発行の仕組み
4. 中間証明書を含む信頼チェーン
5. 証明書や署名のサイズ
6. ハードウェアセキュリティモジュール
7. コード署名や更新署名との整合
8. 失効、更新、監査の運用

鍵共有よりも多くの基盤と長期互換性が関わるため、同じ時期・同じ方式で切り替わるとは限りません。鍵共有が量子対応ならHTTPS全体の移行完了、とは判断しないようにします。

変わらない部分と残る注意

PQCへ移行しても、Webの基本的な役割は残ります。

• DNSで接続先の名前を解決する
• HTTPでリクエストとレスポンスを交換する
• TLSで通信を保護する
• 証明書で接続相手を認証する
• 共通鍵暗号で本文を効率よく守る
• ブラウザが証明書エラーを利用者へ知らせる

またPQCは、フィッシング、端末のマルウェア、サーバー侵入、弱いパスワード、設定ミスを解決しません。暗号が強くても、偽サイトへ自分で情報を入力すれば守れない場合があります。HTTPとHTTPSの違いで扱う通信路の保護と、サイト内容の信頼性を分ける考え方は量子時代も同じです。

移行時に確認する手順

サイト運営やシステム管理では、方式名を有効にする前後に次を確認します。

1. TLS終端がどこにあるか棚卸しする
2. CDN、ロードバランサー、プロキシ、サーバーの対応を調べる
3. クライアントと取引先の対応範囲を確認する
4. 鍵共有と署名のどちらを移すか分ける
5. ハンドシェイクサイズ、遅延、エラー率を測る
6. 古いネットワーク機器で接続障害がないか試す
7. ダウングレードと切戻しの条件を決める
8. ログに方式と失敗理由を残す
9. 標準・ライブラリ更新を追跡する責任者を決める

暗号アジリティは、方式を選べる設定だけではありません。依存箇所を把握し、互換性を試し、問題時に安全に切り戻し、古い方式を計画的に廃止する能力です。

RSAとPQCを読む次のルート

なぜ従来の公開鍵暗号が量子脅威を受けるのかは量子コンピューターでRSA暗号は破られるの？へ進みます。理論、必要資源、現在の実機、データ寿命を分けます。

方式そのものの定義、ML-KEMと署名方式の違い、QKDとの境界はポスト量子暗号とは？で確認できます。この記事はHTTPS/TLSの移行工程を所有し、対応率や標準化の変化は移行観測所で更新します。

TLS受付の確認クイズとワーク

ワーク: TLSの「鍵共有」「証明書署名」「共通鍵暗号」を三列に分け、それぞれの現在方式、PQC候補、通信相手、更新担当、確認方法を書きます。分からない項目を移行台帳の調査対象にしてください。

Q1. 量子対応HTTPSではURLが変わる？

基本的なhttpsという仕組みを保ちながら、TLS内部の暗号方式を更新します。

Q2. 鍵共有がPQCなら証明書もPQC？

別の役割です。鍵共有と証明書署名は、対応方式や移行時期を分けて確認します。

Q3. ハイブリッド方式なら互換性問題はない？

メッセージの大型化や古い中継機器の処理などを試験する必要があります。方式選択と失敗時の挙動も確認します。