The IMSI Problem in 4G

In LTE and earlier generations, the IMSI (International Mobile Subscriber Identity) is transmitted in cleartext during the initial attach procedure. When a UE powers on and sends an Attach Request, the MME may request the IMSI via an Identity Request (identity type = IMSI). The UE responds with its permanent identity in plaintext over the air interface.

This vulnerability enables IMSI catchers (also called Stingrays or cell-site simulators) -- devices that impersonate a legitimate base station, force the UE to attach, and then request the IMSI. Law enforcement, intelligence agencies, and malicious actors have exploited this since the GSM era.

The scale of the problem is significant. The Electronic Frontier Foundation documented over 75 law enforcement agencies in the US operating IMSI catchers by 2023. Academic researchers at the University of Minnesota demonstrated in 2019 that a $1,500 software-defined radio setup could capture IMSIs within a 500 m radius. In crowded areas, a single device captured 1,200+ unique IMSIs per hour.

3GPP addressed this in Release 15 by introducing SUPI and SUCI, defined in TS 33.501 Section 6.12.

SUPI vs SUCI vs IMSI Comparison

SUPI Structure

SUPI can be either IMSI-based or NAI-based. For IMSI-type SUPI:

• SUPI = IMSI = MCC (3 digits) + MNC (2-3 digits) + MSIN (9-10 digits)
• Example: 310260123456789 where MCC=310 (US), MNC=260 (T-Mobile), MSIN=123456789

The critical difference from legacy: the SUPI is never transmitted over the radio interface. It exists in the USIM and in the home network's UDM. All over-the-air identity exchanges use either SUCI (initial registration) or 5G-GUTI (subsequent procedures).

SUCI Structure Breakdown

SUCI is constructed by encrypting only the MSIN portion of the SUPI, while leaving routing information in cleartext so the serving network can route the registration to the correct home network.

The serving network reads the cleartext fields (SUPI type, MCC, MNC, Routing Indicator) to route the NAS Registration Request to the correct AMF and then to the home network's UDM. The encrypted Scheme Output can only be decrypted by the home network's SIDF function.

ECIES Encryption: Step-by-Step

5G uses Elliptic Curve Integrated Encryption Scheme (ECIES) as defined in TS 33.501 Annex C. Two profiles are specified:

• Profile A: X25519 (Curve25519) for key agreement + AES-128-CTR + HMAC-SHA-256
• Profile B: ECDH on NIST P-256 + AES-128-CTR + HMAC-SHA-256

Six-Step ECIES Process (Profile A)

Step 1 -- Key provisioning (one-time, during USIM programming):

The home network generates a static key pair:

• Private key: SK_hn (stored securely in UDM/SIDF)
• Public key: PK_hn (provisioned into the USIM during manufacture)

Step 2 -- Ephemeral key generation (USIM, per registration):

The USIM generates a fresh ephemeral key pair for each SUCI computation:

• ek = random 32 bytes (ephemeral private key)
• EPK = X25519(ek, G) (ephemeral public key, 32 bytes)

This ensures each SUCI is cryptographically unique -- even for the same subscriber.

Step 3 -- Shared secret computation (USIM):

The USIM computes: shared_secret = X25519(ek, PK_hn)

This is a 32-byte Diffie-Hellman shared secret. Only the USIM (which knows ek) and the SIDF (which knows SK_hn) can compute this value.

Step 4 -- Key derivation (USIM):

Using ANSI-X9.63-KDF with SHA-256:

• Input: shared_secret || EPK
• Output: enc_key (16 bytes) || icb (16 bytes) || mac_key (32 bytes)

Where enc_key is the AES-128 encryption key, icb is the initial counter block, and mac_key is the HMAC key.

Step 5 -- Encrypt MSIN (USIM):

• Plaintext: MSIN bytes (e.g., 123456789 encoded as BCD)
• Ciphertext: AES-128-CTR(enc_key, icb, MSIN_bytes)
• MAC tag: HMAC-SHA-256(mac_key, ciphertext) truncated to 8 bytes

Step 6 -- Construct SUCI (USIM): SUCI = SUPI_type || MCC || MNC || Routing_Indicator || Scheme_ID || Key_ID || EPK || Ciphertext || MAC

This SUCI is placed in the NAS Registration Request (5GS Mobile Identity IE) and sent to the gNB, which forwards it to the AMF.

Worked Decryption at the SIDF

When the AMF receives the SUCI, it forwards it to the UDM's SIDF (Subscription Identifier De-concealing Function) via the Nudm_UEAuthentication service.

1. SIDF extracts the cleartext fields and the Scheme Output.
2. SIDF retrieves SK_hn corresponding to the Key ID.
3. SIDF computes: shared_secret = X25519(SK_hn, EPK)
4. SIDF derives enc_key, icb, mac_key using the same KDF.
5. SIDF verifies the MAC tag -- if it fails, the SUCI is rejected (tamper detection).
6. SIDF decrypts: MSIN = AES-128-CTR(enc_key, icb, ciphertext)
7. SIDF reconstructs: SUPI = MCC || MNC || MSIN

The SUPI is then used internally within the core network for authentication (via AUSF) and session management. It is never sent back to the serving network in cleartext -- the serving network only receives a 5G-GUTI to identify the subscriber in subsequent transactions.

SIDF Function in UDM

The SIDF is a critical security function defined in TS 29.509 Section 5.2.2. It is deployed as part of the UDM and has the following properties:

• Isolation: SIDF must be deployed in a trusted environment with access controls. The private key SK_hn should be stored in an HSM (Hardware Security Module).
• Stateless: Each SUCI decryption is independent -- no session state is maintained.
• Performance: Must handle peak registration rates. For a network with 100 million subscribers, peak attach rates can reach 50,000 SUCI decryptions per second during morning rush hours.
• Key rotation: The home network can provision multiple public keys (identified by Key ID). Key rotation involves provisioning a new public key to newly manufactured USIMs while maintaining the old key for existing subscribers.

The Nudm_UEAuthentication_Get request carries the SUCI. The response returns the SUPI along with authentication vectors. The SUPI is encrypted in transit between NFs using TLS 1.3 as mandated by TS 33.501 Section 13.1.

How 5G Mitigates IMSI Catchers

Attack Scenario Comparison

Remaining Considerations

SUCI is not a complete solution against all surveillance:

1. NSA (Non-Standalone) mode: In EN-DC, the LTE anchor still uses GUTI/IMSI procedures. SUCI protection only applies in 5G SA mode. As of 2025, many operators still run NSA.
2. Null scheme (Scheme ID = 0): 3GPP allows a null protection scheme for testing. If an operator deploys null scheme in production, SUCI provides no privacy. This is prohibited by GSMA guidelines but not enforced by 3GPP.
3. Metadata leakage: While the MSIN is encrypted, the MCC, MNC, and Routing Indicator are cleartext. An attacker can determine the subscriber's home network but not their individual identity.
4. Pre-5G USIMs: USIMs manufactured before 5G that lack the home network public key cannot generate SUCI. The UE falls back to sending SUPI in cleartext if no SUCI capability exists.

Deutsche Telekom reported in 2024 that 92% of their 5G SA subscribers use Profile A ECIES, with the remaining 8% on legacy USIMs requiring USIM replacement. SK Telecom achieved 99% SUCI adoption by mandating USIM refresh for all 5G SA activations.

Key Takeaway: SUCI with ECIES encryption eliminates the decades-old IMSI catcher vulnerability by ensuring the subscriber's permanent identity (SUPI) never traverses the air interface. Each SUCI is cryptographically unique and unlinkable, using ephemeral Diffie-Hellman keys. Full protection requires 5G SA deployment and ECIES-capable USIMs -- operators still running NSA or null-scheme configurations remain vulnerable.