SUCI, SUPI and SIDF: how 5G finally stopped broadcasting who you are
In 4G your phone shouted its permanent identity across the air, and anyone with cheap radio kit could write it down. SUCI is the fix - what it conceals, what it deliberately does not, and how to check yours is actually switched on.
Your phone has a permanent identity. In 4G, it shouted that identity across the air the first time it met a network — and anyone with a few hundred dollars of radio kit could write it down.
5G fixed that. The fix is called SUCI, and it is one of the few genuinely new pieces of security in the 5G core rather than a renamed 4G idea.
Here is what it is, how it is built, and how to recognise it in a trace.
The problem SUCI solves
Every subscription has a permanent identifier. In 4G it was the IMSI. In 5G it is the SUPI — the Subscription Permanent Identifier. Same idea, new name.
The SUPI never changes for the life of the SIM. That is exactly what makes it useful, and exactly what makes it dangerous.
When a phone first attaches to a network, the network has no idea who it is. There is no temporary identity yet, no security context, nothing. So in 4G, the phone answered the only way it could: it sent the IMSI in the clear.
That one message is the whole basis of the IMSI catcher. Stand up something that looks like a base station, be the strongest signal in the room, and every phone that reselects to you politely hands over its permanent identity. You now know precisely which subscriptions are in the room, and if you do it in two places you know who moved between them.
This was never a subtle flaw. It was known for twenty years. It survived because there was no clean way to fix it without breaking the one thing that has to work: the network still needs to know where to send the authentication request.
What SUCI actually is
SUCI is the Subscription Concealed Identifier — the SUPI with the sensitive part encrypted, so the phone can identify itself without broadcasting who it is.
The key insight is that it is only partly encrypted, and the part left readable is left readable on purpose.
Think of it like posting a letter. The address on the envelope has to be readable or the postal service cannot deliver it. The letter inside can be sealed. SUCI works the same way: the routing information stays in plain text, and the bit that identifies you specifically is sealed.
The format, field by field
A SUCI is a structure, not a blob. Here is what a real one contains:
SUPI Type | Home Network ID | Routing Indicator | Protection Scheme ID | HN Public Key ID | Scheme Output
SUPI Type — what kind of identity is inside. 0 for an IMSI-based SUPI, which is what a normal SIM uses. Other values exist for network-specific identifiers used in private networks.
Home Network Identifier — for an IMSI-based SUPI this is the MCC and MNC. Country code and operator code. This is in the clear. It has to be: this is how a visited network in Germany knows to send the authentication request to an operator in India.
Routing Indicator — 1 to 4 digits, in the clear, assigned by the home operator. It tells the network which AUSF and UDM instance inside that operator holds this subscriber. A large operator has many; without this, every request would have to be broadcast or guessed at.
Protection Scheme Identifier — which encryption profile was used:
0— null scheme. No encryption at all. More on this below, because it matters.1— Profile A, ECIES over Curve25519 (X25519).2— Profile B, ECIES over NIST P-256 (secp256r1).
Home Network Public Key Identifier — which of the operator's public keys the phone used. This is quietly one of the most practical fields in the whole structure: it is what lets an operator rotate their keys without reissuing every SIM in the field. Old SIMs keep using key 1, new ones use key 2, and the UDM keeps both private keys until the old SIMs are gone.
Scheme Output — the actual concealed part. With the null scheme this is just the MSIN in the clear. With Profile A or B it is the ephemeral public key, the ciphertext, and a MAC tag.
What is encrypted, and what is not
This trips people up constantly, so it is worth stating plainly.
Encrypted: the MSIN — the subscriber-specific digits at the end of the IMSI. The part that says which customer.
Not encrypted: MCC, MNC, Routing Indicator, Protection Scheme ID, Key ID.
So an observer on the air interface learns "this is an Airtel India subscriber, served by UDM group 3". They do not learn which Airtel subscriber. They can count how many subscribers of each operator are in the area. They cannot follow a specific person.
That is the trade, and it is the right one. Total concealment would mean nobody could route the request anywhere.
How the phone builds a SUCI
This is ECIES — Elliptic Curve Integrated Encryption Scheme. It sounds heavier than it is. Five steps:
1. The SIM already holds the operator's public key. Provisioned at manufacture, along with the Key ID and which profile to use. The matching private key never leaves the operator's core.
2. The phone generates a brand-new, throwaway key pair. A fresh one, for this single concealment, used once and discarded.
3. ECDH. The phone combines its throwaway private key with the operator's public key and derives a shared secret. This is the clever part of Diffie-Hellman: the operator will later derive the same secret from the other side — its own private key plus the phone's throwaway public key — without either secret ever crossing the air.
4. Derive keys and encrypt. A key derivation function turns the shared secret into an encryption key and a MAC key. The MSIN is encrypted with AES in counter mode, and a MAC tag is computed over the result so tampering is detectable.
5. Assemble. The Scheme Output becomes: the throwaway public key, the ciphertext, and the MAC tag. All of that goes into the SUCI and out over the air.
Why step 2 is the whole point
If the phone used a fixed key, the same SUPI would produce the same SUCI every single time. And a constant identifier that follows you around is exactly as trackable as the IMSI it replaced — you would just be tracking a different number.
The fresh key pair per concealment means the same SIM produces a completely different SUCI every time it registers. Two SUCIs from the same phone, ten minutes apart, look unrelated to anyone watching.
If you take one thing from this article, take that: the encryption is not what defeats the IMSI catcher. The freshness is.
SIDF: who unwraps it
The SIDF — Subscription Identifier De-concealing Function — is the only thing on earth that can turn a SUCI back into a SUPI. It lives inside the UDM, in the subscriber's home network.
Not in the AMF. Not in the visited network. Not in the base station. The UDM, and only the UDM.
The reason is simply key custody. The SIDF is defined where it is because that is where the home network private key lives, and the design deliberately gives that key to exactly one place. A visited operator you are roaming on never learns your permanent identity — it authenticates you entirely through your home network.
De-concealment reverses the maths:
- Take the throwaway public key out of the Scheme Output.
- Combine it with the home network private key — ECDH again — producing the same shared secret the phone derived.
- Derive the same keys.
- Verify the MAC. If it fails, something has been tampered with; stop.
- Decrypt the MSIN, and rebuild the full SUPI from it plus the MCC, MNC that were readable all along.
The null scheme, and why it should worry you
Protection Scheme 0 is a legitimate, standardised value that means no concealment at all — the MSIN travels in the clear, exactly as in 4G.
It exists for real reasons: emergency calls from a device with no valid credentials, and networks where the operator has not provisioned public keys onto the SIMs.
That second reason is the problem. A network that has not deployed keys is a network where every registration is still leaking permanent identities, on 5G, in 2026 — with all the security marketing and none of the security.
If you take one practical action after reading this: go and look at a registration trace on your own network and check the Protection Scheme ID. If it is 0 outside of emergency scenarios, SUCI is doing nothing for you. You have the feature and not the benefit.
What SUCI does not protect
Being honest about the limits matters more than the marketing.
Only the first contact. After registration, the network assigns a 5G-GUTI, a temporary identity used for everything afterwards. SUCI protects the moment of introduction. Whether you stay unlinkable depends on how often that temporary identity is refreshed — an operator who reallocates the GUTI rarely reintroduces trackability through the back door.
Not the radio layer. Signal strength, timing and behaviour are still observable. SUCI conceals identity, not presence.
Not a solved problem in the literature. Researchers have demonstrated linkability attacks against parts of the 5G authentication exchange — mostly by observing how a network responds to replayed or malformed messages rather than by breaking the encryption. Treat SUCI as a very large improvement over sending the IMSI in the clear, not as a finished answer.
Where to see it in a trace
Registration Request, on the air and then carried on N2 in the Initial UE Message.
Look for the 5GS Mobile Identity information element. Its type field tells you what you are looking at — SUCI, 5G-GUTI, IMEI. When it is a SUCI, decode it and read the fields in order: SUPI Type, then MCC and MNC in the clear, then the Routing Indicator, then the Protection Scheme.
Two checks are worth making a habit:
Is the Protection Scheme non-zero? If not, see above.
Does the same device produce a different Scheme Output on each fresh registration? It should. If you ever see it repeat, something is badly wrong with the ephemeral key generation — and that is a finding worth escalating, because the concealment has quietly stopped working while continuing to look correct.
We teach this procedure end to end — including reading real SUCI structures out of live traces and following them through to the UDM — in our 5G Core (SA) course.