4Gの「丸裸」な時代は終わった：5Gで実現するSUPI/SUCIによるプライバシー革命
エンジニアの皆さん、こんにちは。現場でパケットを追いかけていると、ふと「この通信、本当に安全なのか？」と背筋が寒くなる瞬間はありませんか？
特にモバイル通信の世界では、長らく4G（LTE）以前の仕様が抱えていた「プライバシーの脆弱性」がエンジニア界隈の頭痛の種でした。今日は、5Gで導入された「SUPI/SUCI」という仕組みが、いかにして私たちのデジタルな身分証を守っているのか、その泥臭い仕組みを深掘りしていきましょう。
—
なぜ4GのIMSIは「危険」だったのか？
4G以前、端末がネットワークに接続する際、加入者を特定するためのIDとして IMSI（International Mobile Subscriber Identity）が使われていました。問題は、この IMSI がネットワーク側からの要求に対して「平文（プレインテキスト）」で返されることがあった点です。
悪意のある攻撃者が「IMSIキャッチャー」と呼ばれる偽の基地局を設置すれば、通信エリア内の端末から IMSI を吸い上げ、位置追跡やプロファイリングが容易にできてしまいました。これは、Web APIで言えば「認証トークンなしで個人情報を全開示するエンドポイントを公開している」ようなものです。
—
5Gが導入した「SUCI」という防波堤
5G（3GPP TS 33.501）では、この問題を解決するために加入者識別子を二つに分けました。
1. SUPI (Subscription Permanent Identifier): いわゆる「真のID」。ネットワーク内部でのみ扱われ、決して空中に平文で流れることはありません。
2. SUCI (Subscription Concealed Identifier): 空中に流れる「暗号化されたID」。ホームネットワーク側が持つ公開鍵で暗号化されています。
通信フローの簡略図
端末（UE）がネットワークに接続する際の流れは以下のようになります。
1. UE がホームネットワークの公開鍵を使って SUPI を暗号化し、SUCI を生成する。
2. UE は基地局を経由して、この SUCI を認証サーバー（AUSF/UDM）へ送る。
3. UDM が持つ秘密鍵で SUCI を復号し、元の SUPI を取り出す。
これによって、途中の基地局やパケットを傍受する攻撃者には「ランダムなバイト列」しか見えないため、誰が接続しようとしているのか特定できなくなりました。
—
実務視点：SUCI生成のロジックを読み解く
もし皆さんがプライベート5G環境や、シミュレーター環境でこの仕組みを扱う場合、SUCI の生成には「ECIES（Elliptic Curve Integrated Encryption Scheme）」という方式が使われていることを理解しておく必要があります。
Pythonで概念的なシミュレーションを行うなら、以下のようなイメージです。
# 概念的なSUCI生成プロセスのイメージ
# 実際には3GPPが規定する特定の楕円曲線とパディング規則に従います
from cryptography.hazmat.primitives.asymmetric import ec
def generate_suci(supi, public_key):
# 1. 乱数を生成（毎回異なるSUCIを作るためのソルト）
ephemeral_key = ec.generate_private_key(ec.SECP256R1())
# 2. 秘密鍵と公開鍵で共有シークレットを生成
# 3. 共有シークレットを用いてSUPIをAES等で暗号化
suci = encrypt_data(supi, ephemeral_key)
# 4. 最終的にBase64エンコードして送信
return suci
# ポイント: 毎回ephemeral_keyが変わるため、
# 同じ端末でも接続ごとにSUCIの値が変わる（追跡不能性の担保）—
デバッグと運用における注意点
インフラエンジニアとして現場に立つ際、SUCI がうまく認証されないケースに遭遇することがあります。その多くは、以下のいずれかが原因です。
- 公開鍵の不一致: 端末（USIM/USIMアプリ）に書き込まれている公開鍵IDと、ネットワーク側（UDM）のプロビジョニングデータが食い違っている。
- パケットキャプチャの落とし穴: Wireshark等で
NAS(Non-Access Stratum) メッセージを解析する際、暗号化されているため中身が見えません。UDM側のログで復号エラーが出ていないか確認するのが鉄則です。
また、Web APIの開発と同様、鍵管理（Key Management） が全てです。curl でモックサーバーへリクエストを送るような単純な世界ではありませんが、設定ファイルを扱う際は以下の点に注意してください。
# 5Gコアネットワーク設定例（イメージ）
security_policy:
suci_protection: true
# 端末が送信するSUCIの暗号化方式を強制
encryption_algorithm: "ECIES-X25519"
# 公開鍵の有効期限設定（定期的なローテーションが必須）
key_rotation_interval_days: 90—
まとめ：ネットワークは「見えない」のがデフォルト
5Gの SUCI 導入は、モバイル通信における「プライバシー・バイ・デザイン」の究極形です。これまで「空中に流れる情報は盗聴されるのが前提」だった世界が、「暗号化して初めて通信が成立する」世界へとシフトしました。
もし皆さんが今後、5Gコアネットワークに関わるプロダクトや、セキュアなIoTエッジデバイスの設計に携わるなら、この「SUCIの生成フロー」を技術仕様書の片隅に置くことを強くお勧めします。
パケットは嘘をつきません。正しく設計された暗号化は、どんな熟練したハッカーの追跡も拒絶します。皆さんのネットワークが、今日も安全にパケットを運んでいることを願っています。
それでは、また次回の深い技術談義でお会いしましょう。
コメント