From f0f97a8926036db94b051346d1364dd590a53837 Mon Sep 17 00:00:00 2001 From: "ashkan@beigi.net" Date: Thu, 2 Jul 2026 03:15:24 +0000 Subject: [PATCH] Roadmap: correct the eSIM trust model (COTS UEs ARE in scope) Earlier framing wrongly treated the eUICC as immutable and put consumer phones out of scope. Corrected: we supply a controllable eUICC (removable sysmoEUICC with SGP.26/private root) that trusts our local osmo-smdpp, so any COTS phone/ modem works via its LPA (EasyEUICC/OpenEUICC or lpac) with no GSMA involvement. Update the trust-model section, architecture, Phase 3, and open questions. Co-Authored-By: Claude Opus 4.8 --- plan/roadmap.md | 79 +++++++++++++++++++++++++++++++------------------ 1 file changed, 51 insertions(+), 28 deletions(-) diff --git a/plan/roadmap.md b/plan/roadmap.md index 7dbebe2..f0735dd 100644 --- a/plan/roadmap.md +++ b/plan/roadmap.md @@ -19,26 +19,39 @@ link to the core exists, it can also register new subscribers dynamically. - Available for testing: **srsRAN gNB + Open5GS running**, a **test eUICC / phone**. - Deployment targets **Pi and Android**, equally. -## The hard constraint that shapes everything +## The trust model (and how we work with it — not against it) -Consumer eSIM (GSMA SGP.22 RSP) does **not** let you sideload a profile file into -an eUICC. The device's LPA downloads the profile from an **SM-DP+** identified by -an activation code, and **the eUICC will only trust an SM-DP+ whose certificate -chains to the GSMA CI root**. +Consumer eSIM (GSMA SGP.22 RSP) doesn't let you sideload a profile file into an +eUICC: the device's LPA downloads it from an **SM-DP+**, and the eUICC only +installs profiles from an SM-DP+ whose certificate chains to a **CI root the +eUICC trusts**. -A field-local SM-DP+ (e.g. Osmocom `osmo-smdpp`) uses **test CI keys**, which only -**test eUICCs** accept. Therefore: +The key realization: **we control which eUICC the device uses.** We do *not* need +to defeat a phone's soldered factory eUICC (that would need GSMA CI accreditation). +Instead we supply a **controllable eUICC** whose root-of-trust is ours/test — and +then any COTS UE works with our own local SM-DP+, with **no GSMA involvement**. +This is a productized, well-trodden path (sysmocom sells the cards and runs a +test SM-DP+ for them). + +Concretely, three ingredients: + +1. **A controllable eUICC**, e.g. **sysmoEUICC1** — a removable eUICC in 2FF/3FF/4FF + plastic (or MFF2 solder) form, loaded with **test (SGP.26) or private roots** + instead of GSMA keys. Plugs into virtually any COTS phone/modem with a SIM slot. +2. **A local SM-DP+** — Osmocom **`osmo-smdpp`** (proof-of-concept, ships with + pySim), serving *our* SAIP profiles, using SGP.26 test / private-root certs that + match the eUICC. +3. **An LPA on the device** — **EasyEUICC / OpenEUICC** (Android, via UICC Carrier + Privileges; needs the eUICC's ISD-R to grant an ARA-M rule) or **`lpac`** for + modems / CLI. The LPA consumes an activation-code **QR** and drives the install. + +Delivery tracks: - ✅ **Software UE** — loads a profile/credential file directly. Works today, no RSP. -- ✅ **Test eUICCs** (dev eUICC cards / test modems) — can install from a local - `osmo-smdpp`. This is the realistic "real eSIM" demo path. -- ❌ **Arbitrary consumer phones with factory eUICCs** — will reject a local - SM-DP+. Not achievable in an ad-hoc/offline deployment without a GSMA-accredited - SM-DP+ (out of scope for emergency/NTN). - -**Implication:** target the **software UE** and **test-eUICC modems**. Treat -generic consumer-phone eSIM as explicitly out of scope until/unless a real -SM-DP+ relationship exists. +- ✅ **COTS UE + controllable eUICC** — removable sysmoEUICC (test/private root) in a + COTS phone/modem + LPA + our local `osmo-smdpp`. The real eSIM path. +- ⚠️ **A phone's untouched factory eUICC** — would reject a local SM-DP+ (needs GSMA + CI accreditation). We sidestep this by supplying the eUICC, so it's not a blocker. ## Where we are (done) @@ -58,9 +71,11 @@ Drop device (Pi / Android) └─ Backhaul to core (optional) ← dynamic registration when present Two delivery tracks: - Track S — Software UE: profile file → soft-UE → attach (Phase 1) - Track E — Test eUICC: QR activation code → LPA → local SM-DP+ - → eUICC installs SAIP profile → attach (Phase 3) + Track S — Software UE: profile file → soft-UE → attach (Phase 1) + Track E — COTS UE + eUICC: COTS phone/modem with a controllable + (removable/private-root) eUICC + LPA: + QR activation code → LPA → local SM-DP+ + → eUICC installs SAIP profile → attach (Phase 3) ``` ## Phases @@ -89,15 +104,20 @@ a test eUICC) on srsRAN+Open5GS; confirm authentication succeeds. queue dynamic registrations for when the core link returns. - Deliverable: a drop that works fully offline from a pre-loaded batch. -### Phase 3 — Test-eUICC via local SM-DP+ (the real eSIM last mile) -- Stand up `osmo-smdpp` on the drop; wire our SAIP profiles into it; manage the - (test) CI cert chain. +### Phase 3 — COTS UE via local SM-DP+ (the real eSIM last mile) +- Obtain **controllable eUICCs** (removable sysmoEUICC1 with SGP.26/private root, or + equivalent) and confirm an **LPA** on the target UEs (EasyEUICC/OpenEUICC on + Android; `lpac` for modems). Verify the eUICC's ISD-R grants the ARA-M rule the + LPA needs. +- Stand up **`osmo-smdpp`** on the drop; wire our SAIP profiles into it; manage the + matching (SGP.26/private) CI cert chain. - Complete the SAIP profile to an installable one (PIN/PUK, ARR, security domain, - remaining mandatory PEs) — **validated against the test eUICC** (this is where + remaining mandatory PEs) — **validated against the real eUICC** (this is where the deferred SAIP PE work finally gets card-validated rather than guessed). -- Captive portal renders the LPA activation-code **QR**; test device installs and - attaches. -- Deliverable: test-eUICC device → scan QR → eSIM installed → on the network. + Cross-check against pySim's known-good test profiles. +- Captive portal renders the LPA activation-code **QR**; a COTS phone/modem (with + the controllable eUICC) installs and attaches. +- Deliverable: COTS UE + controllable eUICC → scan QR → eSIM installed → on the network. ### Phase 4 — Field hardening (Pi + Android, first-class) Offline/power/thermal, monitoring/observability, capacity, subscriber @@ -117,7 +137,10 @@ revoke/expire/resync, backhaul-aware dynamic registration, secure batch loading. - **Open5GS access** — reachable from the dev environment, or do you run sync? MongoDB URI, slice SST/SD, APN/DNN, PLMN to match the gNB. - **SM-DP+** — OK to vendor/run `osmo-smdpp` on the drop, or a different RSP? -- **Test eUICCs** — which test eUICC(s)/modems are the real targets (so Phase 3 - profile completion is validated against them)? +- **Controllable eUICCs** — which eUICC do we standardize on (sysmoEUICC1 with + SGP.26 vs private root)? Do the current "test eUICC/phone" you have match the + SGP.26 root osmo-smdpp ships, or do we need a private-root batch? +- **LPA** — EasyEUICC/OpenEUICC (Android) and/or `lpac` (modems) as the on-device + LPA? Any UEs whose SIM slot / carrier-privilege behavior needs checking? - **Batch model** — expected batch size per drop; how batches are provisioned and loaded (offline media vs one-time backhaul).