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 > eUICC Security Functional Requirements
💡 Why this matters: The heart of any Protection Profile is its Security Functional Requirements (SFRs). These are the precise, testable statements that define what the eUICC must do to be considered secure: from authenticating remote actors and isolating Profiles to protecting cryptographic keys and enforcing policy rules. Understanding the SFRs reveals exactly what security properties a certified eUICC guarantees.
Key takeaways:
- SGP.25 defines four Security Function Policies (SFPs): Secure Channel Protocol, Platform Services, ISD-R Content Access Control, and ECASD Access Control
- Identification & Authentication SFRs (FIA_*) ensure every remote and local actor is identified and authenticated before accessing TOE services
- Communication SFRs (FTP_ITC.1, FDP_UCT.1, FDP_UIT.1) protect all data transmitted through ES6, ES8+, and other interfaces
- Security Domain SFRs (FDP_ACC.1, FDP_ACF.1) enforce strict isolation between ISD-R, ISD-P, and ECASD based on AID and ISD-P state attributes
- Security management SFRs (FMT_*) control who may modify security attributes like Profile Policy Rules, keys, and the Rules Authorisation Table
- The TOE scope explicitly excludes MNO-SD, Profiles, and the Runtime Environment from the PP’s SFR coverage
The Security Functional Requirements in SGP.25 are drawn from Common Criteria Part 2, with refinements (adding detail), selections (choosing from CC options), assignments (specifying parameter values), and iterations (repeating components for different contexts). This article unpacks the SFR structure and explains what each group of requirements means in practice.
SGP.25 defines four SFPs that collectively govern all access to and protection of eUICC assets:
This policy governs communication between remote actors (SM-DP+, MNO OTA Platform) and their on-card counterparts (ISD-R, ISD-P, MNO-SD). The TOE must support three secure channel protocols:
| Protocol | Used By | Interface |
|---|---|---|
| SCP-SGP22 | SM-DP+ ↔ ISD-R / ISD-P | ES8+ |
| SCP80 | MNO OTA Platform ↔ MNO-SD | ES6 |
| SCP81 | MNO OTA Platform ↔ MNO-SD (HTTP-based) | ES6 |
These secure channels are built upon security attributes: keysets (D.MNO_KEYS, D.SECRETS) : that bind user identities to the appropriate subjects on the eUICC.
Controls access by the Application Layer (ISD-R, ISD-P, ECASD) to Platform services (Profile Package Interpreter, Profile Rules Enforcer, Telecom Framework). This ensures that:
Governs which operations may be performed on the ISD-R and its data. The ISD-R is the single most privileged component on the eUICC: it creates ISD-Ps, manages their life-cycle, and accesses ECASD functions. This SFP ensures only authenticated remote actors (via secure channels) can trigger ISD-R operations.
The ECASD holds the eUICC’s most sensitive assets: private keys, certificates, eSIM CA public keys, and secrets. This SFP restricts local access to ECASD functions to:
Additional subjects may be granted local access in the Security Target for optional key renewal functionality.
Every actor interacting with the TOE must be identified and authenticated before any other SFR-enforcing actions occur.
Remote users (U.SM-DP+, U.MNO-OTA, U.EIM) are authenticated via the FIA hierarchy:
| SFR | Purpose |
|---|---|
| FIA_UID.1/EXT | Timing of identification: remote users must be identified before any other TSF-mediated action except those listed in the allowance clause |
| FIA_UAU.1/EXT | Timing of authentication: authentication must succeed before any TSF-mediated action beyond identification |
| FIA_USB.1/EXT | User-subject binding: associates remote user security attributes (CERT.DPauth.ECDSA, CERT.DPpb.ECDSA, SM-DP+ OID, MNO OID) with corresponding subjects (S.ISD-R, S.ISD-P, SO.ISD-P) |
| FIA_UAU.4/EXT | Single-use authentication mechanisms: prevents reuse of authentication data related to one-time keys (otSK/otPK) and shared secrets |
| FIA_API.1 | Authentication Proof of Identity: the TOE provides a cryptographic authentication mechanism to prove the eUICC’s identity to remote actors |
The only local user is the MNO-SD (an on-card application within a Profile, not part of the TOE):
| SFR | Purpose |
|---|---|
| FIA_UID.1/MNO-SD | MNO-SD must be identified before any TSF-mediated action |
| FIA_USB.1/MNO-SD | Associates MNO-SD security attributes (MNO OID, keysets) with SO.ISD-P |
FIA_ATD.1/Base defines the full list of security attributes maintained by the TSF for each user, including: AID, ISD-P state, PPR, Reference Enterprise Rule, Enterprise Rule, RAT, keysets/session keys, certificates (CERT.DPauth.ECDSA, CERT.DPpb.ECDSA), and OIDs.
The Secure Channel Protocol SFP is enforced through interconnected SFRs that protect data in transit:
FTP_ITC.1/SCP ──► Trusted channel establishment (ES8+, ES6)
FDP_IFC.1/SCP ──► Information flow control policy definition
FDP_IFF.1/SCP ──► Simple security attribute-based flow rules
FDP_UCT.1/SCP ──► Confidentiality of transmitted user data
FDP_UIT.1/SCP ──► Integrity of transmitted user data
FDP_ITC.2/SCP ──► Import of user data with security attributes
FPT_TDC.1/SCP ──► Consistent interpretation of TSF data between TOE and external entities
Key management for these channels is handled by:
The access control SFRs enforce the strict separation between Security Domains:
FDP_ACC.1/ISDR ──► Defines which subjects/objects are covered
FDP_ACF.1/ISDR ──► Defines the access control rules
Operations governed by ISD-R state include: profile download and installation, ISD-P creation/deletion, ISD-P state transitions (INSTALLED → SELECTABLE → ENABLED → DISABLED), PPR enforcement, and Enterprise Rule evaluation.
FDP_ACC.1/ECASD ──► Defines ECASD subjects and objects
FDP_ACF.1/ECASD ──► Defines access rules based on AID
ECASD operations include: key generation, shared secret computation, signature creation, certificate verification, and EID retrieval.
The ISD-P structure ensures that:
Security management SFRs control who may modify which security attributes:
| SFR | Coverage |
|---|---|
| FMT_SMF.1/Base | Specification of management functions: defines the complete list of management operations (create, delete, enable, disable ISD-P; install, enable, disable, delete Profile; configure ISD-P; update ISD-P metadata) |
| FMT_SMR.1/Base | Security management roles: defines roles authorised to perform management functions (S.ISD-R, U.SM-DP+, U.MNO-OTA, LPAd/IPAd, End User via LUId) |
| FMT_MSA.1/PLATFORM_DATA | Management of Platform data security attributes: restricts state transitions for ISD-P state (ENABLED/DISABLED/INSTALLED/SELECTABLE) |
| FMT_MSA.1/RULES | Management of PPRs and Reference Enterprise Rules: restricts modification and deletion to authorised actors |
| FMT_MSA.1/RAT | Management of Rules Authorisation Table: restricts RAT modification to manufacturing or initial Device setup |
| FMT_MSA.1/CERT_KEYS | Management of certificate and key attributes: restricts modification of eSIM CA keys and CRLs |
| FMT_MSA.3 | Static attribute initialisation: defines restrictive default values for all security attributes |
FPT_FLS.1/Base : Failure with preservation of secure state
FPT_FLS.1/Platform_services: Platform services failure handling
These ensure that failures (including memory reset and test memory reset) do not compromise security. The Memory Reset function may override PPRs (disabling/deleting profiles even when PPRs prohibit it), which is an explicit documented exception.
FPT_EMS.1/Base : TOE Emanation of TSF and User data
Ensures that secret data stored or transmitted within the TOE (shared secrets between ECASD and ISD-R/ISD-P, private keys, session keys) shall not be disclosed through side-channel emissions. This includes resistance to SPA, DPA, timing attacks, and electromagnetic radiation analysis.
FDP_SDI.1/Base : Stored data integrity monitoring
FDP_RIP.1/Base : Residual information protection
FDP_SDI.1 ensures integrity monitoring of all integrity-sensitive data (keys, Profile data, management data, identity data). FDP_RIP.1 ensures that deallocated resources do not leak residual confidential data.
FCS_RNG.1/Base : Random number generation
The ST author must select RNG classes (NTRG, DRG.2, DRG.3, DRG.4, PTG.2, PTG.3) as defined in AIS 20/31. This underpins all key generation, challenge-response protocols, and session key derivation.
What SGP.25 SFRs explicitly do NOT cover:
Based on GSMA SGP.25 v2.1 (3 February 2025) : eUICC for Consumer and IoT Devices Protection Profile, Sections 3 (Security Problem Definition), 4 (Security Objectives), and 6 (Security Requirements including SFR definitions)
| ← Previous: SGP.25 Overview: The eUICC Common Criteria Protection Profile | Section Index | Next: eUICC Assurance Requirements: EAL4+ and Penetration Testing → |