SUPI / SUCI / 5G-GUTI — 5GCはUEをどう識別するのか¶

学習目標¶

この章を読み終えると、次のことができるようになります。

• SUPI / SUCI / 5G-GUTI を「恒久ID・秘匿ID・一時ID」という目的の違いで説明できる
• SUCI の内部構造（SUPI Type / Home Network Identifier / Routing Indicator / Protection Scheme Identifier / Home Network Public Key Identifier / Scheme Output）と、どの部分が平文で残るかを説明できる
• SUCI→SUPI の復号（de-concealment）を AMFではなくUDM側のSIDF が行う理由を説明できる
• 5G-GUTI / 5G-S-TMSI / 5G-TMSI の包含関係とビット長を図示できる
• Wireshark で 5GS mobile identity の種別（SUCI / 5G-GUTI 等）を確認し、「5G-GUTIを送ったのに Identity Request が来た」等の事象を切り分けられる

前提知識¶

• Registration（初回登録） — 識別子が実際に流れる手続き
• Authentication — SUCIがAUSF/UDMへ渡る流れ
• Security — NAS Security と SUCI秘匿の基礎
• 補助: Identifier辞典（用語の早引き） / AMF / UDM

Why — なぜUEの「名前」が3種類も必要なのか¶

5GCのTraceを開くと、UEを指す名前が大量に出てきます。

SUPI / SUCI / 5G-GUTI / 5G-S-TMSI / 5G-TMSI / PEI / RAN UE NGAP ID / AMF UE NGAP ID

もし「加入者の恒久ID（SUPI）」を無線区間で毎回そのまま送ると、第三者が無線を傍受するだけで 「同じ加入者がまたここにいる」と追跡 できてしまいます。これが Subscriber Privacy（加入者プライバシー） の問題で、4G以前ではIMSIキャッチャ（偽基地局）が悪用してきました。

一方で、ネットワークは加入者を確実に特定しないと、認証も課金も着信もできません。この「隠したい」と「特定したい」を両立するために、5GCは目的の異なる3種類の識別子を使い分けます。

例え話: 病院で考えると、SUPIは「保険証の本名」、SUCIは「病院の本部しか開けられない封筒に入れた保険証」、5G-GUTIは「受付でもらう番号札（担当窓口の番号＋あなたの番号）」です。待合室で呼ばれるのは番号札であり、本名は大声で呼ばれません。

What — 3つの識別子の正体¶

関係の全体像¶

flowchart LR
    SUPI["SUPI
恒久ID（本名）"]
    SUCI["SUCI
秘匿ID（封緘）"]
    GUTI["5G-GUTI
一時ID（番号札）"]
    SUPI -- "UE(USIM/ME)がHN公開鍵で秘匿" --> SUCI
    SUCI -- "UDM内のSIDFだけが復号" --> SUPI
    SUPI -. "登録成功後AMFが割当て（SUPIとは数学的に無関係）" .-> GUTI

ここで重要なのは、5G-GUTIはSUPIから計算されるものではない点です。SUCIはSUPIを暗号化したもの（SUPIに復元可能）ですが、5G-GUTIはAMFが割り当てる番号であり、SUPIとの対応はAMFのUE Context（同一AMF SetでUDSF等によりContextを共有する構成ではその共有Context）の中にしか存在しません。

SUPI（Subscription Permanent Identifier）¶

SUPI は、5GSにおける加入契約の恒久識別子です（TS 23.501 §5.9.2、TS 23.003 §2.2A）。「端末」ではなく Subscription（加入契約） を指す点に注意してください。端末（装置）の識別子は別に PEI（Permanent Equipment Identifier、IMEI等）があります（TS 23.501 §5.9.3）。

SUPIの形式は主に次の2種類です（TS 23.003 §2.2A）。

SUCI（Subscription Concealed Identifier）¶

SUCI は、SUPIを秘匿（conceal）した識別子です（TS 23.501 §5.9.2a、TS 23.003 §2.2B、TS 33.501 §6.12）。ただし SUCI全体が暗号文ではありません。Home Networkが受け取って処理するために、ルーティングに必要な部分は平文のまま残ります。

flowchart LR
    subgraph Clear["平文で残る部分（ルーティング・復号の手がかり）"]
        T["SUPI Type"]
        H["Home Network Identifier
(IMSIならMCC+MNC)"]
        R["Routing Indicator"]
        P["Protection Scheme Identifier"]
        K["Home Network Public Key Identifier"]
    end
    subgraph Enc["秘匿される部分"]
        S["Scheme Output
(IMSIならMSIN部分を秘匿)"]
    end
    T --- H --- R --- P --- K --- S
    classDef clr fill:#e8f0fe,stroke:#3b5bdb;
    classDef enc fill:#fde2e1,stroke:#c92a2a;
    class T,H,R,P,K clr;
    class S enc;

Protection Scheme は TS 33.501 Annex C で規定されます。

ECIESではUEが毎回一時的な鍵ペアを生成するため、同じSUPIでもSUCIは毎回異なる値になります。これが「傍受者が同一加入者だと紐付けられない（unlinkability）」の根拠です。null-schemeにはこの性質がありません。

誰がSUCIをSUPIに戻すのか — SIDF¶

SUCIの復号は AMFでは行いません。Home Network側の SIDF（Subscription Identifier De-concealing Function） が行い、SIDFは UDM が提供するサービスとして位置づけられます（TS 33.501 §6.12.2）。

sequenceDiagram
    participant UE
    participant AMF as AMF (SEAF)
    participant AUSF
    participant UDM as UDM (SIDF / ARPF)
    UE->>AMF: Registration Request (5GS mobile identity = SUCI)
    AMF->>AUSF: Nausf_UEAuthentication_Authenticate (SUCI, SN name)
    AUSF->>UDM: Nudm_UEAuthentication_Get (SUCI, SN name)
    UDM->>UDM: SIDF: 秘密鍵でSUCI → SUPI を復元
    UDM-->>AUSF: 認証ベクタ + SUPI
    Note over AUSF,AMF: SUPIがAMFへ渡るのは
認証が成功した後
    AUSF-->>AMF: 認証結果 + SUPI（5G-AKAでは認証確認後）

• なぜAMFで復号しないのか — HN秘密鍵を訪問先網（ローミング時はVPLMN）のAMFに配ると、鍵の保護範囲が広がりすぎるためです。秘密鍵をHPLMNのUDM/SIDFに閉じ込めることで、SUCIで登録した場合、ローミング先にもSUPIを認証成功まで渡さない設計になっています。
• SUPIがAMFへ渡るタイミング — SUCIで登録した場合、AUSFは認証成功後にSUPIをSEAF（AMF）へ提供します（5G AKA: TS 33.501 §6.1.3.2 / EAP-AKA': §6.1.3.1）。5G-GUTIで登録し旧AMFからContextを取得できた場合は、旧AMF経由で受け取ります（TS 23.502 §4.2.2.2.2）。

5G-GUTI（5G Globally Unique Temporary Identifier）¶

5G-GUTI は、AMFがUEに割り当てる一時識別子です（TS 23.501 §5.9.4、TS 23.003 §2.10.1）。構造は次のとおりです。

<5G-GUTI>    = <GUAMI><5G-TMSI>
<GUAMI>      = <MCC><MNC><AMF Identifier>
<AMF Identifier> = <AMF Region ID><AMF Set ID><AMF Pointer>
<5G-S-TMSI>  = <AMF Set ID><AMF Pointer><5G-TMSI>

ビット長は TS 23.003 §2.10.1 に規定されています。前半の GUAMI = 「どのAMFか」、後半の 5G-TMSI = 「そのAMFのどのUEか」 です。GUAMIの詳細は次章で扱います。

5G-S-TMSI — 無線区間用の「短縮版」¶

5G-S-TMSI（48 bit）は、5G-GUTIからPLMNとAMF Region IDを省いた短縮形です（TS 23.501 §5.9.4、TS 23.003 §2.10.1。要確認）。PagingやService Requestなど、無線区間で効率よくUEを指したい場面で使われます。RRCでは RRCSetupRequest に収まるよう ng-5G-S-TMSI-Part1（39 bit） と Part2（9 bit） に分割して運ばれます（TS 38.331 §6.2.2）。

flowchart TD
    GUTI["5G-GUTI"] --> GUAMI["GUAMI
MCC+MNC+Region(8)+Set(10)+Pointer(6)"]
    GUTI --> TMSI["5G-TMSI (32)"]
    STMSI["5G-S-TMSI (48)
= Set(10)+Pointer(6)+5G-TMSI(32)"]
    GUAMI -. "Set ID / Pointer を抜き出し" .-> STMSI
    TMSI -. "そのまま" .-> STMSI

5G-GUTIはいつ変わるのか¶

5G-GUTIは一時IDなので、同じ値を長く使い続けると追跡の手がかりになります。そのためTS 33.501は、NAS Security確立後の登録受諾や、Pagingに応答したService Requestなどを契機に 新しい5G-GUTIを割り当てる ことを求めています（TS 33.501 §6.12.3、節番号は要確認）。割当ては Registration Accept のほか、Generic UE Configuration Update 手続き（TS 24.501 §5.4.4）でも行えます。

How — Registration中に識別子はどう変わるか¶

Call Flow（初回登録：5G-GUTI無し → SUCI）¶

sequenceDiagram
    participant UE
    participant gNB
    participant AMF
    participant AUSF
    participant UDM as UDM (SIDF)
    Note over UE: 有効な5G-GUTIなし
    UE->>gNB: RRCSetupRequest (ue-Identity = random value)
    UE->>gNB: RRCSetupComplete (NAS: Registration Request)
    gNB->>AMF: Initial UE Message (NAS-PDU)
    Note over AMF: 5GS mobile identity = SUCI
    AMF->>AUSF: Nausf_UEAuthentication_Authenticate (SUCI)
    AUSF->>UDM: Nudm_UEAuthentication_Get (SUCI)
    UDM->>UDM: SIDF: SUCI → SUPI
    UDM-->>AUSF: AV + SUPI
    AUSF-->>AMF: 認証チャレンジ
    AMF->>UE: Authentication Request / Response
    AMF->>AUSF: 認証確認
    AUSF-->>AMF: 認証成功 + SUPI
    AMF->>UE: Security Mode Command / Complete
    Note over AMF: SUPIでUDM登録・加入者データ取得
    AMF->>UE: Registration Accept (5G-GUTI) — T3550開始
    UE-->>AMF: Registration Complete — T3550停止
    Note over UE,AMF: 以後はUEが5G-GUTI / 5G-S-TMSIを使用

Call Flow（再登録：既存5G-GUTI → 旧AMFからContext取得）¶

UEが別AMFの管理エリアへ移動した場合、新AMFは5G-GUTI内のGUAMIから旧AMFを特定し、UE Contextを取りに行きます（TS 23.502 §4.2.2.2.2）。

sequenceDiagram
    participant UE
    participant NewAMF as New AMF
    participant OldAMF as Old AMF
    UE->>NewAMF: Registration Request (5GS mobile identity = 5G-GUTI)
    NewAMF->>NewAMF: 5G-GUTIのGUAMIから旧AMFを特定
    NewAMF->>OldAMF: Namf_Communication_UEContextTransfer (N14)
    alt Context取得成功
        OldAMF-->>NewAMF: UE Context (SUPI, Security Context 等)
        Note over NewAMF: Context取得後もUE認証を再実行し得る
(TS 23.502 §4.2.2.2.2、オペレータポリシー依存)
    else 旧AMFが特定できない / Contextが無い / 完全性検証失敗
        NewAMF->>UE: Identity Request (SUCI)
        UE-->>NewAMF: Identity Response (SUCI)
        Note over NewAMF: 以降は初回登録と同様に認証へ
    end

Signal Flow（識別子に関わる主要メッセージ）¶

5GS mobile identity IE の種別¶

TS 24.501 §9.11.3.4 の Type of identity で、IEの中身が何かが決まります。

符号値は同節の表を参照してください（本ページでは値の断定を避けます）。

Packet Analysis (Wireshark)¶

Display Filter¶

Decode例（概念表現）¶

以下は表示構造の概念表現です。実際のラベル名はWiresharkのバージョンにより異なります（要キャプチャ）。

NGAP InitialUEMessage
 └─ NAS-PDU
     └─ Registration Request
         └─ 5GS mobile identity
             ├─ Type of identity: SUCI
             ├─ SUPI format: IMSI
             ├─ MCC / MNC               ← Home Network Identifier（平文）
             ├─ Routing indicator       ← 平文
             ├─ Protection scheme Id    ← null-scheme / Profile A / Profile B
             ├─ Home network public key identifier
             └─ Scheme output           ← Profile A/Bなら暗号化された値

Registration Request
 └─ 5GS mobile identity
     ├─ Type of identity: 5G-GUTI
     ├─ MCC / MNC
     ├─ AMF Region ID
     ├─ AMF Set ID
     ├─ AMF Pointer
     └─ 5G-TMSI

見るべきポイント¶

1. Type of identity — SUCIか5G-GUTIか。「初回相当」か「既存Contextの再利用を試みている」かの手がかりになる（5G-GUTIがmappedかどうかも併せて確認）
2. Protection scheme Id — null-schemeならMSINが見えている。本番網でnull-schemeが出ていたらUSIM/UDMの鍵設定を疑う
3. Home network public key identifier — UDM側に同じIDの秘密鍵があるか（鍵ローテーション直後の不一致に注意）
4. Routing indicator — AUSF/UDM選択に使われる。選択は NRF discovery（NF Profile の routingIndicators、TS 29.510、節番号は要確認）またはローカル設定で行われ、どちらを使うかは実装・運用依存（TS 23.501 §6.3.4 / §6.3.8、要確認）。想定外の値なら、NRF登録またはAMF/AUSFのローカル設定と照合
5. Registration Accept 内の 5G-GUTI と、続く Registration Complete の有無

Trouble Shooting¶

SUPIだけでTraceを追わない¶

商用AMFでは、1つの識別子だけを追うと途中で見失います。識別子は 2系統 に分けて考えます。

flowchart LR
    subgraph Sub["加入者識別（NAS / SBI）"]
        A["SUCI"] --> B["SUPI"]
        B --> C["5G-GUTI / 5G-S-TMSI"]
    end
    subgraph N2["N2シグナリング識別（NGAP）"]
        D["RAN UE NGAP ID"]
        E["AMF UE NGAP ID"]
    end
    C -. "同じNGAPメッセージ内で紐付け" .-> D
    C -. "同じNGAPメッセージ内で紐付け" .-> E

RAN UE NGAP ID / AMF UE NGAP ID は Subscription Identity ではありません。N2上のUE-associated signalingを識別するためのIDで（AMF UE NGAP ID: TS 38.413 §9.3.3.1 / RAN UE NGAP ID: §9.3.3.2、要確認）、接続ごとに変わります。NAS内の識別子とNGAPのIDが同一メッセージに載る瞬間（Initial UE Message 等）を起点に紐付けるのが定石です。

障害と切り分け¶

3GPP仕様とVendor実装の境界¶

商用AMFを解析するときは、3GPP Identity ⇔ Vendor内部のUE Context ⇔ NGAPのUE ID の対応を取れることが重要です。

EPC（4G）との比較¶

3GPP Specification¶

Summary¶

• SUPI = 加入契約の恒久ID、SUCI = SUPIの無線区間秘匿形、5G-GUTI = 登録後の一時ID。目的がそれぞれ違う
• SUCIは全体が暗号文ではなく、Home Network Identifier / Routing Indicator / Scheme ID / PKI は平文、秘匿されるのは Scheme Output
• SUCI→SUPIの復号は UDM内のSIDF のみ。SUCIで登録した場合、サービングAMFがSUPIを受け取るのは AUSFが認証成功を確認した後（TS 33.501 §6.1.3.2 / §6.1.3.1）。5G-GUTIで登録し旧AMFからContextを取得できた場合は旧AMF経由（TS 23.502 §4.2.2.2.2）
• 5G-GUTI = GUAMI + 5G-TMSI。5G-GUTIはSUPIから計算されず、対応はAMF（またはAMF Set内で共有されるUE Context）の中にだけある
• Registration Request の 5GS mobile identity がSUCIか5G-GUTIかで、UEの状態と以後の流れ（Context転送 / Identity Request）を読める

理解度チェック¶

Next Step¶

• 5G-GUTIの前半 GUAMI を分解し、AMF Region / AMF Set / AMF Pointer とAMF選択を学ぶ → GUAMI / AMF Region / Set / Pointer
• 識別子が流れる手続き全体に戻る → Registration
• 旧AMF⇔新AMFのContext転送 → N14 / Mobility Registration Update
• 用語の早引き → Identifier辞典