LFNW25：TLSからポスト量子暗号、その間のすべて

いくつかの発表はスライドから始まります。
別のものは、廊下での雑談や、スキャン結果、証明書エラー、あるいはチームの誰かの「ねえテッド、本当にTLS 1.3が必要なの？」という質問から始まります。LinuxFest Northwest 2025 のためにこの発表を準備し終えた頃──ちょうど LFNW と LPI の25周年でもあったのですが──私は、会場の枠を超えて「量子コンピューティング時代のセキュリティ」について発信する必要があると確信しました。

私の探求は単に標準規格の話ではありません。私たちが築くウェブ──特にFOSSにおいて──が次に来るものに一歩先んじるようにすることが目的です。たとえその「次に来るもの」が量子であっても。

LFNWに参加でき（詳細レポートはこちら）、私は「ポスト量子暗号でWebサーバーを守る」という発表を行えたことを誇りに思います。本記事はそのセッションを整理し直し、この媒体向けに書き換えたものです。検索や共有もしやすくなっているはずです。

では、始めましょう。

SSL、TLS、そしてあの混乱

いまだに「SSL証明書」と呼んでいますが、SSL自体はすでに約30年前に廃止されています。
今日では、少なくともTLS 1.2を（できればTLS 1.3を）使っていなければ、すでに危険な状態です。

TLS 1.3は単に「きれい」なだけではありません。RSA鍵交換（Diffie-Hellmanのような前方秘匿性を持たない）といった古い仕組みを廃止し、より良い暗号スイートを強制し、ポスト量子時代への基盤を築いています。TLS 1.3ではクライアントとサーバー間のハンドシェイクも効率的になっています（図1、Cloudflareサイトより）：

図1 TLS 1.2とTLS 1.3におけるハンドシェイクの違い

そして私たちはそちらに向かって急速に進んでいます。量子コンピューターによるRSAへの新たな攻撃報告を読むたびに、攻撃対象となる数はどんどん大きくなっています。しかも実際は報告より悪いかもしれません。なぜなら公表される研究には国家機関や成果を公開しない組織のものは含まれていないからです。

RSA 2048ビットがいつ破られるのかは私にも分かりません。しかし、NISTが「2030年までにRSAやECDSAを非推奨とし、2035年以降は使用禁止」と勧告しているのは妥当でしょう。というのも、OpenSSL 3.5 のように量子脅威に弱い暗号から移行できるOSSツールがすでに公開されているからです。

以下の表は脆弱な標準から移行するタイムラインを示しています：

• 既知の量子攻撃に脆弱なアルゴリズム

• 既知の量子攻撃に脆弱な鍵共有スキーム

NISTは10年近くにわたり、世界中の研究者と協力し、新しい耐量子暗号の最終草案をまとめてきました。初期の選択肢に脆弱性が見つかった場合に備えたバックアップも用意されています。

「ポスト量子」とは何を意味するのか

ポスト量子暗号（PQC）は流行語ではありません。差し迫った問題への実際的な対応です。すなわち、量子コンピューターが実用規模に達した時、私たちの暗号化通信はどうなるのか？

答えは簡単です。攻撃者は「今データを収集し、後で解読」します。

だからこそ私はセッションの後半を、NISTが審査したアルゴリズム──ML-KEM（格子ベース鍵カプセル化）、ML-DSA（格子ベース署名アルゴリズム）、HQC──に焦点を当てました。これらはすでにCloudflareやGoogleなどのクラウド事業者によってハイブリッド運用が始まっています。

もしあなたのサーバーがOpenSSL 3.5に対応しているなら、すでに有利な立場にいます。対応していないなら、今すぐ計画とテストを始めるべきです。

図2 OpenSSLのLTSバージョン（長い棒・水色）は5年間サポートされる

サーバーやAPIエンドポイントをTLSで守る業務に携わっていない人でも、ブラウザの最新版（FirefoxやChromeなど）はML-KEMによるPQCに対応済みです。

いくつかのブラウザはハイブリッド方式でPQCを利用しています。つまり証明書は従来の仕組みで検証しつつ、サーバーとクライアント双方が対応していればPQC暗号化を使うという形です。Cloudflareの推定では、現時点で同社ネットワークの2%がPQC耐性を持っています。Googleのような大規模事業者は2022年から社内ネットワークでPQCを導入済みです。

新しい耐量子アルゴリズムにはFIPS ID番号が付与され、監査やコンプライアンスで追跡できるようになっています。

証明書：DV、OV、EV──そして有効期限の計算

インターネット上の信頼とプライバシーは技術的手段だけでなく、社会的信頼にも基づいています。SSL証明書はドメイン検証（DV）、組織検証（OV）、拡張検証（EV）の3種類があります。

多くの人がLet’s Encryptを利用していますが、それで十分なケースも多いでしょう。ただしLet’s EncryptのDV証明書は基本的な用途向けであり、銀行や公共サービス、DNS以外の身元確認が必要な場合はOVやEVが推奨されます。

また、10年分の証明書を購入しても、実際には13か月ごとに再発行が必要です。これはエコシステム全体の信頼維持の仕組みです。

自分の証明書について分からない場合は、SSL Labs や SSLScan などのツールを強く推奨します。

コンプライアンス：PCI、HIPAA、FIPS──そして本当のコスト

医療、フィンテック、政府契約の分野ではコンプライアンスは必須です。

発表ではFIPS 140-2/140-3、FedRAMPなどの標準フレームワークがどのように暗号の有効性を定義しているか、また認証にどれほどのコストがかかるかを解説しました。

結論を言うと「数百万ドル規模」です。長期的に見ても負担は大きい。

そのため多くの企業はRed Hat、Rocky、SUSE、Alma、Ubuntuといったディストリビューションが提供する認証済みモジュールを利用します。エンタープライズサポートを受けつつ、認証や費用の負担はベンダーに任せられるからです。

後方互換性（おばあちゃんのブラウザ）

なぜTLS 1.3に移行して1.2を切り捨てないのか？

それは現実の利用者が常に最新環境を使っているわけではないからです。Android 5のスマホや、Windows 7のキオスク端末、あるいは古いiMacを使うおばあちゃんかもしれません。

TLS 1.2と1.3を併用し、賢い暗号スイート選択を行うことで、安全性と使いやすさを両立できます。

楕円曲線暗号（ECC）はRSAよりCPU負荷が軽く、モバイル端末では高速に動作します。インターネットの半分以上のトラフィックはモバイルからのものなので、暗号方式のCPU負荷は世界的なエネルギー消費やバッテリー寿命に直結します。

アップグレードの準備はできていますか？

ライブで共有したチェックリストをまとめます：

• サーバーを管理しているなら可能な限りOpenSSL 3.5へアップグレード

• TLS 1.3を使用し、必要な場合のみ1.2へフォールバック

• 証明書の種類（DV/OV/EV）を把握

• SSLScanなどのツールでサイトをスキャン

• ポート80（平文HTTP）は本当に必要な場合以外は閉じる

• NISTのPQC標準（ML-KEM、HQCなど）を注視

• 2025〜2030年はハイブリッド運用が主流になると予測

発表を超えて

私は90年代からセキュリティ、DevSecOps、ネットワークに関わってきましたが、ポスト量子暗号は久々に「ルールブックを書き換える」ものだと感じています。

FOSSの世界は幸運です。テストし、共有し、適応することで一歩先を行けるからです。ただし、そのためには参加と準備が不可欠です。単なる「パッチ」ではなく。

LinuxFest Northwest、セッションに参加してくださった皆さま、そして会場とサポートを提供してくださったLPIに感謝します。未来に通用するウェブを共に築きましょう。

資料・ツール: スライドPDF、発表動画（YouTube）

LPIはLFNW25を誇りを持って支援しました。Tedの完全レポートはこちら。LPIはすでにLFNWチームと協力し、LinuxとOSSをこの地域で支援する取り組みを2026年版へ向けて進めています。

参加したい方、経験を共有したい方、LFNWコミュニティを支援したい方は、ぜひコメントを残すか、私（tmatsumura@lpi.org）までご連絡ください。