今回Help Net Securityは、AllotのVP CTOであるYaakov Stein博士にインタビューを行い、モバイルネットワークにおけるポスト量子時代への備えとはどのようなものかを聞きました。話題は、加入者IDのマッピング、課金記録、通話メタデータなど、何年にもわたって機密性を保つ必要があるオペレーターのトラフィックと、数時間で価値を失うトラフィックの見分け方にまで及びました。
インタビューでは、まず暗号インベントリの作成とTLSインターフェースにおけるハイブリッド鍵交換から着手し、続いてIPsecリンクへと進めるという作業の順序についても解説しています。さらに、疑ってかかるべきベンダーの回答例を具体的に挙げ、見落とされたインターフェースこそが障害の起点になりやすい理由についても説明しています。
通信事業者のセキュリティチームと話す際、長期にわたって機密性を保つ必要があるトラフィックと、そうでないトラフィックをどのように仕分けていますか。長期保存が必要な部類に入り、担当者を驚かせるものにはどのようなものがありますか
トラフィックの「保存期限」は、PQC対応の緊急性を測るMoscaの方程式を構成する要素の一つであり、見積もっておくことが重要です。オペレーターの制御トラフィックの大半は非常に短い時間で価値を失いますが、加入者IDのマッピング、課金記録、通話メタデータなど、何年も機密性を保ち続けるシグナリング系のメタデータも複数存在します。もちろん、個人パスワードやシステムパスワードが漏れる可能性のあるトラフィックも、優先度の高いリストに含まれます。
コアネットワークのトラフィックの中には、攻撃者に内部トポロジー情報を明かしてしまうものもあり、一部のインターフェースが露呈すればオペレーター同士の長期的な関係に影響を及ぼしかねません。一方で、加入者の音声通話、ウェブ閲覧、ストリーミングは数時間で無価値になります。クレジットカード情報のような加入者の金融取引データは、少なくとも数年間は機密性を保つ必要がありますが、その保護は加入者側のブラウザやアプリに委ねるのが最善です。
ポスト量子対応プログラムを一切持たないティア2のモバイル事業者から、月曜日に電話がかかってきたとします。1週目から12週目までの流れを教えてください。同じくらい重要な点として、あえてまだ手をつけるべきではないことは何でしょうか
各タスクをきっちり1週間ごとに区切れるとは考えていないので、ここでは項目ごとに挙げていきます。最初のタスクは、公開鍵暗号の利用状況を網羅的に洗い出したインベントリを作成することです。これには5G SBAインターフェース、IPsecで保護されたリンクに使われるIKE、DNSsec、暗号化されたAPIなどの特定が含まれます。ここで包括的なリストを作っておけば、後の工程で時間と労力を大幅に節約できます。2番目のステップは、TLSを利用しているすべての要素(SBAインターフェース、SEPP、ウェブポータル、OSS/BSS APIを含む)をハイブリッド鍵交換へ移行することです。これは現時点で最も入手しやすい技術です。
続いて、バックホール、DC間リンク、LTEローミングインターフェースを含むIPsecリンクについても同様の移行を行います。次(4週目)は、独自プロトコルも含め、公開鍵に依存するその他すべてのプロトコルに着手します。すべての鍵交換への対応が済んだ段階で、長期間持続する接続の認証について検討を始めることができます。こうした接続であれば、現行の標準化済みPQCデジタル署名で必要となる巨大な公開鍵のオーバーヘッドにも耐えられます。一方、短期間しか続かない接続のソフトウェア認証については、当面は後回しにしても問題ありません。ハードウェア認証やアテステーションの仕組みについては、ベンダー側の対応が整うのを待つ必要があります。また、オペレーターは一般加入者について特に心配する必要はありませんが、企業や政府機関の顧客には特別な配慮が求められる場合があります。
5Gの加入者認証は主に対称鍵に依存していますが、その周辺のPKIはそうではありません。オペレーターが今年PQCの導入を一つしか実施できないとしたら、コアネットワークのどこに導入すべきで、それはなぜですか
先ほども触れたとおり、手を付けやすいのはTLSの鍵交換です。TLSで保護されたすべてのSBAインターフェースおよび管理プレーンのインターフェースに、ハイブリッドML-KEM(X25519 ECCとML-KEMの組み合わせ、可能であればHQCへの暗号アジリティを備えたバックアップ付き)を導入することが、あらゆるオペレーターにとって最も手軽で、かつ最も効果の大きいPQC対策です。
PQCに関する質問に対して、警戒すべきベンダーの回答とはどのようなものでしょうか。疑わしいと感じる具体的な言い回しを教えてください
「PQCにはまだ対応していません」を別にすれば、ベンダーが返す最悪の回答は「標準が固まるのを待っています」というものです。確かにRFCがすべて確定しているわけではありませんが、PQCは通信業界の歴史上、他のどの大きなイノベーションよりも速いペースで標準化が進んでいます。そこで鍵となるのは、対応を先送りすることではなく、暗号アジリティを備えて将来に備えることです。次に悪い回答は、「暗号学的に問題となる量子コンピューターはまだ存在していない」や「当社の暗号化は対称暗号ベースなので量子耐性がある」といったもので、どちらも理解不足か、あるいは意図的なごまかしのいずれかを示しています。
オペレーターの移行が失敗する最も一般的な原因は何でしょうか。暗号が破られるといった話ではなく、地味な運用面での失敗について教えてください
これは、先ほどの回答で強調した論点、すなわち網羅的な暗号インベントリの整備に関わる話に戻ります。オペレーターは大半のセキュリティ機構をアップグレードできたとしても、SSHでアクセス可能なマシン、古いRADIUSインターフェース、ロードバランサーやNAT、何年も誰も触れていないオーケストレーションツールといった、一部のインターフェースを見落としてしまうことがあります。すると、そのオペレーターはPQC対応が完了したかのような誤った安心感を抱いてしまいますが、言うまでもなく、PQC対応の強度は最も弱いリンクによって決まります。
さらに、もう一つ別の問題もあります。新しい仕組みの一部は、既存機器が前提としていた条件を崩してしまう場合があるのです。これはKyberが初めて導入された際に実際に起きたことで、複数パケットにまたがるTLSクライアントハローが各種ミドルボックスの前提を崩してしまい、結局ロールバックを余儀なくされました。
翻訳元: https://www.helpnetsecurity.com/2026/09/01/yaakov-stein-allot-telecom-pqc-migration/
