Mobile Subscriber-Identity Security

⊕ On the typography. This document keeps its central Tufte CSS conventions — a narrow measure, numbered sidenotes, and a wide right margin for glosses and asides — reflowed onto the RAGBAZ token sheet: warm-solarized-dark surfaces, Spectral for text, Intel One Mono for labels, orange ember for accents. Acronyms carry a brief margin gloss and link to the fuller glossary. This reference distils a working conversation about the attack surface of mobile subscriber identity: the physical SIM, the embedded eUICC and its remote provisioning, the (non-)verifiability of SMS/MMS origin, and the covert network paths that bypass an on-device VPN. It closes with an incident-response playbook for a suspected repeat compromise.

The secret key is engineered never to leave the secure element — so real-world key theft reduces to exploiting a weak legacy algorithm or physically attacking the chip. Every layer in this document is a variation on that one boundary.

1 · The layered trust model

⊕ RSP — Remote SIM Provisioning; the GSMA framework for delivering operator profiles to an eUICC. more Everything reduces to one root of trust. The GSMA CI (Certificate Issuer) signs both the eUICC’s per-chip certificate and each SM-DP+’s certificate; profile delivery is a mutual authentication plus an ECKA key agreement. Break either half — steal an eUICC private key, or an SM-DP+ certificate — and the “end-to-end encrypted profile” guarantee collapses.

PlantUML source

@startuml
title RSP / eSIM Trust Model (SGP.22 consumer + SGP.32 IoT)
skinparam componentStyle rectangle
skinparam shadowing false
skinparam defaultFontName Helvetica
skinparam backgroundColor transparent
package "Device" {
  [LPA\n(Local Profile Assistant)] as LPA
  [eUICC\n(embedded secure element)] as EUICC
  [Baseband] as BB
}
cloud "GSMA PKI" {
  [GSMA CI\n(Certificate Issuer)] as CI
}
node "Operator / Provisioning" {
  [SM-DP+] as DP
  [SM-DS\n(Discovery)] as DS
}
node "IoT management" {
  [eIM] as EIM
}
CI ..> EUICC : signs eUICC cert
CI ..> DP : signs SM-DP+ cert
LPA --> DP : ES9+ (download)
LPA --> EUICC : ES10 (APDU)
LPA --> DS : ES11 (discovery)
EIM --> EUICC : SGP.32 remote mgmt\n(no user consent)
EUICC <--> DP : mutual auth (ECKA)\nend-to-end encrypted profile
BB --> EUICC : ISO 7816 APDU bus
note bottom of CI
  Root of trust.
  Steal an eUICC private key OR an SM-DP+ cert
  => impersonate one half of the mutual auth.
end note
@enduml

2 · The physical SIM (UICC)

⊕ Ki — the per-subscriber authentication master key. Stored in the card; never transmitted. more Authentication runs on-card: the baseband sends a challenge, the card computes the response and session keys internally, and returns only the result. On the APDU bus you therefore see IMSI, the challenge/response pair, and the derived CK/IK session keys — never Ki.

PlantUML source

@startuml
title APDU authentication — Ki never crosses the bus
skinparam shadowing false
skinparam backgroundColor transparent
participant "Baseband\n(terminal / master)" as BB
participant "UICC / USIM\n(secure element)" as SIM
BB -> SIM : AUTHENTICATE(RAND, AUTN)
note right of SIM
  Milenage / COMP128 runs on-card
  using Ki (never exported)
end note
SIM --> BB : RES, CK, IK  (derived session keys)
note over BB, SIM
  ON the wire: RAND, RES, CK/IK, IMSI, STK, OTA-SMS.
  NOT on the wire: Ki, OTA keys.
  A shim/SIMtrace sees the former, never the latter.
end note
@enduml

What a lost card actually leaks depends almost entirely on whether a SIM PIN is set. With it enabled the card is inert on power-up; without it, stored identifiers and — more dangerously — the ability to receive the subscriber’s calls and SMS one-time codes pass to whoever holds it.

3 · eSIM and Remote SIM Provisioning

⊕ LPA — Local Profile Assistant; the on-device agent that drives profile download. A conduit, not a keyholder. more The eUICC is a soldered secure element provisioned over the air. The LPA parses an activation code and relays an encrypted BPP that only the target eUICC can decrypt — which is why you cannot extract your own profile through the LPA, and why the interesting attacks target the chip or the provisioning server instead.

PlantUML source

@startuml
title SGP.22 profile download (simplified)
skinparam shadowing false
skinparam backgroundColor transparent
actor User
participant LPA
participant eUICC
participant "SM-DP+" as DP
User -> LPA : scan QR  LPA:1$dp.example$MATCHING-ID
LPA -> eUICC : get eUICC cert + challenge (ES10)
LPA -> DP : InitiateAuthentication (ES9+)
DP --> LPA : SM-DP+ cert + signed challenge
LPA -> eUICC : verify SM-DP+ cert against GSMA CI
eUICC --> LPA : eUICC signed response
LPA -> DP : mutual auth OK -> request profile
DP --> LPA : BoundProfilePackage (encrypted to THIS eUICC)
LPA -> eUICC : install BPP
note right of eUICC : IMSI + Ki + OTA keys land inside the SE
note over LPA : LPA only relays ciphertext — it is not a keyholder
@enduml

⊕ eUICC — embedded UICC; the eSIM secure element. Identified by its EID. more The 2025 Kigen eUICC disclosure showed the systemic risk: a publicly-keyed GSMA TS.48 test profile let researchers load an applet, an incomplete on-card Java Card bytecode verifier let it escape the firewall, and the eUICC’s private key plus GSMA certificate were extracted — enough to download real profiles in cleartext and clone eSIMs.

• 2019 — Simjacker / WIBattack (S@T & WIB applet abuse) and prior Java Card research surface.
• Mar 2025 — Security Explorations extracts an eUICC private ECC key; proof delivered to Kigen.
• Jul 2025 — Public disclosure; GSMA TS.48 v7.0 restricts test-profile capability; vendor OS patch hardens the verifier.
• 2025→ — Residual exposure concentrated in un-updated IoT/M2M eUICCs and SGP.32 management (an eIM with no user-consent gate).

4 · STK / OTA — the Simjacker family

⊕ STK / OTA — SIM Application Toolkit driven by Over-The-Air binary SMS (ENVELOPE SMS-PP). The card can proactively command the handset. more Because the card cannot speak first on the master-driven bus, it raises a status word and the handset FETCHes a proactive command. A silent binary OTA SMS delivered via ENVELOPE reaches a vulnerable applet, which can request location and send an SMS — the Simjacker mechanism. It is largely mitigated by removing S@T/WIB applets and filtering binary OTA SMS at the network.

PlantUML source

@startuml
title Simjacker / WIBattack (legacy S@T / WIB applet)
skinparam shadowing false
skinparam backgroundColor transparent
actor Attacker
participant "SMSC /\nOTA sender" as SMSC
participant "Baseband" as BB
participant "SIM applet\n(S@T / WIB)" as APP
Attacker -> SMSC : binary OTA SMS (Type-0, silent, no UI)
SMSC -> BB : deliver
BB -> APP : ENVELOPE (SMS-PP data download)
APP -> BB : proactive: PROVIDE LOCAL INFORMATION
BB --> APP : location area / IMEI
APP -> BB : proactive: SEND SHORT MESSAGE
BB -> SMSC : exfil SMS -> attacker
note bottom
  Mitigated by removing S@T / WIB applets +
  network filtering of binary OTA SMS (GSMA guidance).
end note
@enduml

5 · SMS / MMS origin: nothing the handset can verify

⊕ MM4 — the inter-MMSC interface, which is SMTP/MIME over the operator GRX/IPX. The originator is a header. more An inbound SMS hands the app a spoofable sender string (TP-OA), an unreliable SMSC address, and a timestamp — no origin-network attestation, no signature. MMS is no better: across carriers it travels as email (MM4), the From: is a header written by the sender side, and no DKIM/SPF/DMARC is enforced across the inter-operator mesh.

PlantUML source

@startuml
title Inter-carrier MMS over MM4 (SMTP / MIME)
skinparam shadowing false
skinparam backgroundColor transparent
participant "Originating\nMMSC (A)" as A
participant "Terminating\nMMSC (B)" as B
participant "Recipient\nhandset" as R
A -> B : SMTP  MAIL FROM:<+15550000/TYPE=PLMN@mmsc.a>
A -> B : RCPT TO:<+15554321/TYPE=PLMN@mmsc.b>
A -> B : DATA\nX-Mms-Message-Type: MM4_forward.REQ\nFrom: +15550000/TYPE=PLMN@mmsc.a\n(multipart/related; type=application/smil)
B --> A : MM4_forward.RES
B -> R : MM1 M-Retrieve.conf (From = asserted originator)
note over A,B
  From is a header written by the sender side.
  No DKIM/SPF/DMARC enforced across GRX/IPX.
  => email-grade spoofable.
end note
@enduml

6 · Covert bearers that bypass an on-device VPN

⊕ PDN / APN — a Packet Data Network context on an Access Point Name. The MMS APN is a second bearer distinct from the default route. more Android’s VPN is an L3 capture of the default network. A socket explicitly bound to a specific network — e.g. the MMS PDN via NET_CAPABILITY_MMS and bindProcessToNetwork — pins to that interface and escapes the tunnel, even under “always-on + block without VPN”. The forensic backstop is that the carrier still logs the PDN activation and bytes in its CDRs, regardless of on-device state.

PlantUML source

@startuml
title Secondary-bearer egress bypassing an on-device VPN
skinparam shadowing false
skinparam componentStyle rectangle
skinparam backgroundColor transparent
package "Android device" {
  [App socket\n(default, unbound)] as S1
  [App socket bound to\nNET_CAPABILITY_MMS] as S2
  [tun0  (VpnService)] as TUN
  [rmnet  (MMS APN / PDN)] as RMNET
}
cloud "VPN tunnel" as VPN
cloud "Carrier core\n(+ CDR / PDN logging)" as CORE
S1 --> TUN : default route (captured)
TUN --> VPN
S2 --> RMNET : bindSocket / bindProcessToNetwork
RMNET --> CORE : ESCAPES the VPN
note right of RMNET
  Bound sockets pin to the interface, not tun0,
  so even "always-on + block without VPN" misses them.
  Carrier CDR still records the PDN + bytes -> forensic backstop.
end note
@enduml

7 · Obtaining carrier records: routes and provenance

⊕ DSAR — Data Subject Access Request. Under GDPR Art. 15 (and CCPA/analogues) the subscriber can compel the carrier to disclose the personal data it holds — which includes itemised usage. more Every preceding section leans on the same backstop: the carrier holds records the handset cannot reach or forge. But “the CDR proves it” is only useful if you can lawfully obtain the CDR. There are three access routes, and which records you can get depends entirely on who you are and what authority you hold — not on what the network technically logs.

PlantUML source

@startuml
title Where carrier records originate, and the lawful routes to obtain them
skinparam shadowing false
skinparam componentStyle rectangle
skinparam backgroundColor transparent
package "Mobile core (record producers)" {
  [MSC / IMS\n(voice, SMS)] as VOICE
  [SGSN / GGSN  --  4G MME / S-GW / P-GW\n5G SMF / UPF] as PS
  [HLR / HSS / UDM\n(subscriber, IMSI/IMEI binding)] as HLR
  [OCS / OFCS  (charging)] as CHG
  [SM-DP+ / eIM\n(eSIM provisioning log)] as RSP
}
[Mediation / billing\nTS 32.298 ASN.1 CDRs] as MED
[Lawful-intercept gateway\nETSI LI / CALEA] as LI
[Subscriber DSAR / itemised bill] as SUB
[Legal process] as LAW
VOICE --> MED : voice-CDR, SMS-CDR
PS --> MED : G-CDR / PGW-CDR, IPDR
CHG --> MED : Rf / Ro (Diameter)
HLR --> MED : provisioning + location events
RSP --> MED : EID <-> profile bind
MED --> SUB : itemised usage (self, GDPR DSAR)
MED --> LAW : subpoena / court order / warrant
LI --> LAW : live intercept (warrant only)
note bottom of LAW
  Preservation letter freezes records first;
  MLAT / MLA bridges cross-border carriers.
end note
@enduml

7.1 · The three lawful routes

As the subscriber you already own most of the low-resolution data: an itemised bill lists calls, SMS counts and per-session data volume, and a DSAR compels the fuller personal-data set the operator retains — usage records, provisioning history, and often coarse cell/location associated with billing. This is self-service and needs no court. As an enterprise or plan owner (a business account, an MDM/EMM fleet, a family plan admin) you can request the records for numbers on the account through the carrier’s business portal or account team. As law enforcement the resolution rises with the legal instrument: a preservation letter first freezes the data before it ages out; a subpoena reaches subscriber and toll (CDR) records; a court order reaches transactional/PDN and historical cell-site; a warrant is required for content and for real-time lawful intercept. Cross-border, an MLAT / mutual-legal-assistance request bridges to the foreign operator.

7.2 · What each record actually is, and where it is born

⊕ Charging arch. 3GPP TS 32.240 defines the charging framework; TS 32.298 the ASN.1 CDR encoding. Each node emits its own record type. more A “CDR” is not one thing. Each network function emits its own charging record, which a mediation system normalises, correlates and hands to billing, retention or a warrant return:

• Voice / SMS CDR — from the MSC/IMS: A- and B-number, IMSI, IMEI(SV), start/duration, and the serving cell (Cell-ID / ECGI) at setup.
• Packet / PDN records — the PDN backstop from §6. In 3G these are S-CDR (SGSN) and G-CDR (GGSN); in 4G/EPC the PGW-CDR (with SGW-CDR); in 5G the SMF/UPF charging records. They log APN, PDN activation/deactivation times, byte counts up/down, and the allocated (often CGNATed) IP — this is what betrays a covert bearer.
• IPDR — IP Detail Records: finer-grained flow/session logs (5-tuples, timestamps) some operators keep beyond the volume totals in the PGW-CDR.
• Charging events — the OCS (online, prepaid) and OFCS (offline, postpaid) systems carry Diameter Ro/Rf event streams that predate and cross-check the billed CDR.
• Subscriber & identity — the HLR/HSS/UDM holds the IMSI↔MSISDN↔IMEI bindings, current VLR/serving-node, and provisioning history; an SM-DP+/eIM holds the EID↔profile download log for eSIMs.
• Location — from coarse to fine: the serving cell stamped on every CDR; a historical cell-site list; a tower dump (all IMSIs on a cell in a window); per-measurement timing-advance / RTT or operator RF-fingerprint (e.g. NELOS) for sub-cell fixes.

7.3 · Retention, format, and the practical ask

Records do not live forever. Retention is set by national law and operator policy — commonly months to a couple of years for CDRs, often much shorter for fine IPDR/flow data — which is why the preservation request goes first, before the subpoena that eventually compels production. What you receive is typically a mediation export (CSV/PDF for a bill or DSAR; native TS 32.298 ASN.1 BER, or a vendor CSV, for a warrant return). For an investigation the high-value, concrete ask is: the PGW/SMF PDN-session records and voice/SMS CDRs for this IMSI/MSISDN over this window, with serving-cell and byte counts, plus the IMEI binding history and any eSIM provisioning events — then correlate those against on-device netstats exactly as in the playbook below.

8 · DFIR playbook for a suspected repeat compromise

⊕ DFIR — Digital Forensics & Incident Response. Preserve before you remediate; correlate device egress against carrier records. more When prior defences have already failed, assume a persistent, adaptive adversary at a layer those defences never covered. Preserve evidence and operate over a clean out-of-band channel before touching anything; audit device egress and carrier records in parallel; cross-correlate on-device netstats against carrier CDRs to reveal covert bearers; and stage hardening so you do not tip the adversary.

PlantUML source

@startuml
title DFIR playbook for a suspected repeat mobile compromise
skinparam shadowing false
skinparam backgroundColor transparent
start
:Phase 0 - OpSec + evidence integrity;
note right: clean out-of-band channel, chain of custody, written authorization
:Phase 1 - Scope & threat model;
:Phase 2 - Preserve & acquire\n(MVT, dumpsys, backups, eUICC/EID);
:Phase 3 - Audit incoming + outgoing traffic;
fork
  :Off-device gateway\n(Zeek / Suricata / pcap / DNS);
fork again
  :Carrier CDR / PDN records;
end fork
:Cross-correlate netstats vs CDR;
if (covert bearer or C2 found?) then (yes)
  :Phase 5 - attribution + evidence package;
else (no)
  :continue monitoring;
endif
:Hardening (staged, no tip-off);
stop
@enduml

The single highest-signal cross-check is on-device per-UID/per-interface byte counts versus carrier-reported usage: any excess the operator recorded that the device does not account for points at a covert bearer or tampering. Because carrier records are outside the device, complete on-device concealment is not achievable — which is exactly what makes an evidence-grade investigation possible.

Glossary