Comprehensive technical knowledge base covering 12 GSMA eSIM specifications. 84+ articles on Remote SIM Provisioning — SGP.02, SGP.22, SGP.32, SGP.41, SGP.29, SGP.23, SGP.25, SGP.26 and more.
🏠 eUICC.tech > SGP.25 eUICC Security > Physical Security: Side-Channel and Fault Injection Defenses
💡 Why this matters: An eUICC doesn’t just face network-based attacks: it sits inside a device that an adversary can physically hold, probe, and manipulate. Side-channel analysis can extract cryptographic keys from power consumption patterns. Fault injection can flip bits during critical operations. Physical tampering can expose internal buses and memory. SGP.25 explicitly addresses these threats, requiring the TOE and its underlying platform to resist attackers with oscilloscopes, glitching tools, and lab benches.
Key takeaways:
- T.PHYSICAL-ATTACK is a “second-level” threat covering environmental stress, electrical probing, side channels, fault injection, and physical tampering
- FPT_EMS.1/Base requires the TOE to resist emissions-based attacks: SPA, DPA, timing analysis, and electromagnetic radiation analysis
- The secure IC (operational environment) must be certified against [PP0084] or [PP0117], providing hardware-level physical defenses
- OE.IC.SUPPORT requires atomic memory operations, segmentation fault detection, and secure low-level cryptographic processing
- O.DATA-CONFIDENTIALITY and O.DATA-INTEGRITY objectives apply to both the TOE and Runtime Environment, including explicit side-channel resistance
- Secure manufacturing processes (life-cycle phases a–e) create a chain of trust from IC fabrication through personalisation to operational deployment
Physical attacks represent a qualitatively different threat than logical attacks. They don’t exploit bugs in software: they exploit the physical reality that every computation consumes power, takes time, emits radiation, and can be disrupted. SGP.25’s treatment of physical security spans the TOE’s own SFRs, the objectives placed on the operational environment (IC, Runtime Environment), and the life-cycle controls on manufacturing.
SGP.25 defines physical attacks as a distinct “second-level” threat that bypasses all first-level protections:
“The off-card actor discloses or modifies the design of the TOE, its sensitive data or application code by physical (as opposed to logical) tampering means.”
The formal threat definition encompasses:
| Attack Category | Examples | Assets Threatened |
|---|---|---|
| Environmental stress | Temperature extremes, voltage manipulation, clock glitching | All assets |
| IC failure analysis | Decapsulation, micro-probing, reverse engineering | D.TSF_CODE, keys |
| Electrical probing | Monitoring bus lines, memory bus sniffing | D.SECRETS, D.SK.EUICC.ECDSA |
| Side channels | SPA, DPA, electromagnetic analysis, timing attacks | Secret keys, session keys |
| Fault injection | Voltage glitching, laser fault injection, EM pulses | Execution integrity |
| Unexpected tearing | Power removal during sensitive operations | Atomicity of state transitions |
| Instruction manipulation | Altering execution order through physical means | TSF code integrity |
All assets of the TOE are directly threatened: from private keys and session secrets to TSF code and Profile data. A successful physical attack could clone the eUICC, extract operator credentials, or bypass profile policy enforcement entirely.
The primary SFR directly addressing physical attacks is FPT_EMS.1/Base:
FPT_EMS.1.1/Base
The TSF shall ensure that the TOE does not emit emissions over its attack
surface in such amount that these emissions enable access to TSF data
and user data as specified.
The assets explicitly protected from emanation-based disclosure:
The Application Note provides a detailed catalogue of the attack classes that must be resisted:
“The TOE shall prevent attacks against the secret data of the TOE where the attack is based on external observable physical phenomena of the TOE. Such attacks may be observable at the interfaces of the TOE or may originate from internal operation of the TOE or may originate from an attacker that varies the physical environment under which the TOE operates.”
| Attack | Description | Observable Phenomenon |
|---|---|---|
| Simple Power Analysis (SPA) | Direct interpretation of power consumption traces during cryptographic operations | Power consumption over time |
| Differential Power Analysis (DPA) | Statistical correlation between power consumption and processed data across many operations | Aggregated power traces |
| Timing attacks | Measuring execution time variations that depend on secret data | Transition timing of internal states |
| Electromagnetic radiation analysis | Capturing and analysing EM emissions from the chip during computation | Electromagnetic radiation |
| Radio emission analysis | Detecting radio-frequency emissions from internal operation | Radio emissions |
The evaluator is expected to assess resistance against state-of-the-art attacks applicable to the technologies employed by the TOE : a forward-looking requirement that keeps pace with advancing attack techniques.
SGP.25 explicitly delegates first-line physical defense to the underlying secure IC. The IC is not part of the TOE but is a required component of the operational environment:
The secure IC must be certified according to:
This is a mandatory requirement: the IC’s hardware security features are independently evaluated before the eUICC software evaluation begins.
OE.IC.SUPPORT specifies four essential capabilities:
(1) Non-bypassability and non-alterability of TSF:
The IC must not allow TSF functions to be bypassed or altered, and
must not allow access to low-level functions beyond those exposed
through the API.
→ Includes protection of private data and code against disclosure
or modification at the hardware level.
(2) Secure low-level cryptographic processing:
The IC must provide secure cryptographic primitives to the Profile
Rules Enforcer, Profile Package Interpreter, and Telecom Framework.
(3) Structured memory with access controls:
Memory model must be structured and allow low-level control
accesses (segmentation fault detection).
→ Transient objects must not be stored in non-volatile memory.
→ Prevents memory-based attacks (buffer overflows, stack smashing).
(4) Atomic memory operations:
The IC must provide a means to perform memory operations atomically.
→ Critical for resisting fault injection during state transitions.
OE.IC.RECOVERY addresses unexpected tearing (power removal during operations):
“If there is a loss of power while an operation is in progress, the underlying IC must allow the TOE to eventually complete the interrupted operation successfully, or recover to a consistent and secure state.”
This prevents attackers from manipulating eUICC state by precisely timing power removal during profile installation, key generation, or state transitions.
OE.IC.PROOF_OF_IDENTITY requires the underlying IC to be uniquely identified: a hardware root of trust that anchors the eUICC’s identity and prevents chip-swapping attacks.
Physical security is not just an IC problem. SGP.25 distributes side-channel resistance requirements across three layers:
Hardware countermeasures: power consumption smoothing, clock randomisation, shielded buses, metal layers, sensors
“The Runtime Environment shall provide a means to protect at all times the confidentiality of the TOE sensitive data it processes.”
The Application Note explicitly requires:
“refining the ADV_ARC ‘non-bypassability’ requirements to explicit the coverage of side channel attacks by the security architecture of the ST TOE.”
For Java Card implementations, this means the Java Card System’s own security architecture must incorporate side-channel resistance: not just pass through to the hardware.
The TOE itself must ensure that:
Physical security begins long before the eUICC is deployed. SGP.25’s life-cycle model (Section 1.2.3) defines a chain of trusted phases:
| Phase | Activity | Security Relevance |
|---|---|---|
| Phase a | eUICC Platform Development | IC and embedded software development: must occur in ALC_DVS.2-protected environment |
| Phase b | IC Manufacturing and Packaging | IC fabrication, pre-personalisation, test: SAS-accredited site |
| Phase c | eUICC Platform Storage, Pre-Personalisation, Test | Software embedding onto the IC: may be combined with Phase d if at same secure site |
| Phase d | eUICC Personalisation | ECASD/ISD-R key injection, optional provisioning Profile loading : GSMA SAS-accredited |
| Phase e | Operational Usage | Integration onto Device, SM-DS registration, post-issuance provisioning |
The TOE may be delivered (i.e., leave the trusted environment) at three possible stages:
The ST writer must describe which delivery activities are required in their specific life-cycle model and at which phase the self-protected TOE is delivered.
The ADV_ARC.1 architectural design requirement explicitly addresses tampering:
ADV_ARC.1.2D: The developer shall design and implement the TSF so that
it is able to protect itself from tampering by untrusted active entities.
ADV_ARC.1.4C: The security architecture description shall demonstrate
that the TSF protects itself from tampering.
This means the eUICC software architecture must include self-protection mechanisms that detect and respond to tampering attempts: not just rely on the hardware. The security domain model (ISD-R, ECASD, ISD-P isolation) is the primary architectural mechanism: even if one component is compromised, others remain protected.
Based on GSMA SGP.25 v2.1 (3 February 2025) : eUICC for Consumer and IoT Devices Protection Profile, Sections 1.2.3 (TOE life-cycle), 3.3.6 (Second-level threats: T.PHYSICAL-ATTACK), 4.1 (Security objectives for the TOE: O.DATA-CONFIDENTIALITY), 4.2.2 (Platform objectives: OE.IC.SUPPORT, OE.IC.RECOVERY), and 6.1 (SFRs: FPT_EMS.1/Base)
| ← Previous: eUICC Assurance Requirements: EAL4+ and Penetration Testing | Section Index | Next: SGP.25 Certification: SAS-UP and the Evaluation Process → |