Introduction
In August 2024, researchers from Aalto University, Finland published a “Security Analysis of the Consumer Remote SIM Provisioning Protocol”The research will be the subject of a briefing session at the Black Hat Europe 2024 event in London on 11th December 2024.
The GSMA welcomes this security analysis of the eSIM specifications (SGP.22 v2.3) and for the suggested improvements.
Impact Assessment
The GSMA has considered the research paper and undertaken a detailed assessment of the impact of the research, which involved modelling the remote SIM provisioning protocol and applying a cryptographic protocol verifier to it. The merits and practicality of the individual recommendations have also been considered.
The GSMA notes and welcomes the findings of the researchers that the remote SIM provisioning (RSP) protocol is adequately secured, between honest entities, against network adversaries and the security goals defined in the eSIM specifications are achieved. The potential attack scenarios, and the vulnerabilities that could arise from those, that are described in the research paper assume that one of the endpoints (the SM-DP+ and eUICC) is compromised. In a scenario where endpoints, and communications between them, are compromised, a range of vulnerabilities arise and these apply to any system in which TLS is deployed.
In the case of the GSMA’s remote SIM provisioning protocol, the use of TLS is mandated and if the integrity of its implementation is maintained the exposure to the vulnerabilities described in the research paper is minimised. Furthermore, an eSIM certification process has been put in place to mitigate the risk of compromised eSIM entities (SM-DP+ and eUICC). Combined, the presence of these security measures evidence that the GSMA eSIM specifications have been designed with security by design in mind to protect the security and resilience of the endpoints and the communication between them.
The GSMAs eUICC Security Assurance (eSA) Schemeis a rigorous certification programme that has been specifically developed for the eSIM ecosystem. GSMA Compliance Process and Certification is designed to ensure quality, security, and interoperability of the eSIM entities, such as SM-DP+ and eUICC. Therefore, on top of the architecture and requirements specification (SGP.21) and the technical specification (SGP.22), GSMA has developed a comprehensive set of specifications to complement the eSIM ecosystem and improve the integration of the eSIM into the market, while ensuring consumer trust. Those specifications are:
- GSMA Test specification (SGP.23) plays a vital role in ensuring interoperability within the eSIM ecosystem, significantly reducing functional errors during communication between the SM-DP+ and the eUICC.
- Security Accreditation Scheme (GSMA SAS) for the SM-DP+ implementation and operations (SAS-SM) and eUICC production sites (SAS-UP) demonstrates the security of these environments and processes, and therefore mitigates the risk of data breaches and attacks.
- GSMA eUICC Protection Profile (SGP.25), the stringent security requirements outlined in the eUICC Protection Profile ensure that the eUICC software components are able to protect and safeguard sensitive information and prevent unauthorised access. This Protection Profile targets EAL4+ which provides resistance against the high attack potential (AVA_VAN.5). The software certification against this Protection Profile enhances the overall security of eSIM ecosystems and reduces the risk of data breaches and attacks at the software level.
- eSIM Compliance Process (SGP.24) and GSMA Certification provides a comprehensive and common approach to demonstrating compliance of the security features and functionality of the eSIM products via certifications and other evidence. The eSIM Compliance scheme ensures that the GSMA eSIM products provide the security and functionality described in the eSIM specifications as authorised entities. All evidence and certifications need to be presented to GSMA for verification to acquire a PKI certificate that is used for signing and authentication purposes between entities in the ecosystem. This enhances the trust and reliability of these eSIM products in the marketplace.
The GSMA eSIM Compliance and Certification process were designed and introduced to serve and safeguard the eSIM ecosystem, of which they are an indispensable element. The GSMA strongly encourages the industry to recognise and invest in these security assurance initiatives to ensure the highest standards of quality, security, and interoperability. Combined with the use of TLS, the existence of these initiatives make it unlikely that the research could have practical application in the real world eSIM ecosystem.
eSIM specifications are continuously evolving to consider the feedback from the industry. The latest published version of SGP.21 and SGP.22 are:
- For version 2, SGP.22/21 v2.6 published in October 2024
- For version 3, SGP.22/21 v3.1 published in December 2023
The list of all these specifications and their versions can be found here
Assessment of the Recommendations
The GSMA has analysed the ten security risks and recommendations listed in section 6 of the research paper and has concluded on each one as outlined below.
Recommendation 1: Activation Code – SM-DP+ OID
In the activation-code approach, always provide the server OID to the LPA during the profile download initialisation.
Recommendation 2: Default SM-DP+ Address – SM-DP+ OID
Amend the RSP specification for the default-server approach so that, in addition to the default server domain name S, either the LPA or the eUICC stores the default server OID and compares it with the value in the server certificate CertSa during the server authentication.
For recommendations 1 and 2, it should be noted that the SM-DP+ OID is optional or absent because there are use cases where the SM-DP+ can be changed and/or dynamically assigned, e.g., for business reasons, migration/upgrade of SM-DP+ to another server, distribution of the transactions across multiple SM-DP+s for load balancing, etc. SM-DP+ OID embedded in an Activation Code or present in the eUICC is not easy to update, as the Activation Code and Default SM-DP+ address with SM-DP+ OID will be invalidated. However, using only SM-DP+ FQDN provides flexibility by simply updating DNS records.
It is up to individual MNOs to decide whether to add the SM-DP+ OID in an Activation Code in accordance with their own risk management assessment and needs.
Recommendation 3: Bind the EID during the Profile order
In the activation-code approach, always register the eUICC identifier U to the server during the profile ordering.
As noted in the research paper, according to SGP.22, the EID is already an optional field of the ES2+.DownloadOrder and ES2+.ConfirmOrder functions. The eSIM specification intentionally defines the EID as optional to allow certain MNO use cases, e.g., the subscriber can order a Profile before the device is shipped (like pre-paid SIM cards).
It is up to the MNO to request the EID registration by the subscriber during the Profile ordering.
Recommendation 4: User Verification for the Profile ordering process
When the user requests a profile for their eUICC, the MNO should verify the user identity carefully. In the default-server approach, it should do this before ordering the profile from the SM-DP+ server, and in the activation-code approach, before giving the activation code to the user.
The GSMA considers that this recommendation is part of the Know Your Customer process of the MNO. This process is not in the scope of the GSMA eSIM specifications. This depends on MNO processes and local and regional regulations.
In addition to the Activation Code, the MNO can provide the Confirmation Code to the subscriber that will be verified by the SM-DP+ during the Profile download.
Recommendation 5: User Experience during the Profile ordering process
Amend the RSP specification with design guidelines for a uniform user experience on how the user confirms the MNO before the profile download or installation.
The user experience is outside the scope of the GSMA eSIM specifications because the detailed user experience is device implementation specific. However, according to SGP.22, the LPA allows the user to confirm the Profile download by presenting Profile Metadata returned in ES9+.AuthenticateClient function response.
Recommendation 6: Multiple Profile Download – User consent
Amend the RSP specification for the default-server approach so that, if there are multiple profiles on the SM-DP+ server, the user is warned and asked to choose the one to download.
SGP.22 already covers multiple pending Profiles in the Default SM-DP+. When the device reaches out to the Default SM-DP+, the server returns one of the pending Profiles based on the order configured by the MNO. Then,
- Profile Metadata informs the subscriber about the Profile download (see also the response to Recommendation 5),
- The subscriber accepts or declines the download of the Profile,
- The above steps repeat until there is no pending Profile.
“In that case, the attacker can order its profile from a different MNO that uses the same server”.
In relation to the statement above, the GSMA would like to clarify that:
- If “same servers” means multiple tenant SM-DP+, the SM-DP+ address should be different. Therefore, the default SM-DP+ would no longer work.
- If “same servers” means that the IP address of the SM-DP+s is the same for the two MNOs, the Profile A would still have a different FQDN from the Profile B.
Recommendation 7: Inclusion of OID for message authentication
Amend the RSP specification so that the signed messages in the initial authentication (messages 4–5 and 6–7) include the server OID, which the message recipient compares with the expected value. This requires the adoption of recommendations R1 and R2.
Recommendation 8: Checking of S values
Amend the RSP specification so that the server compares S in the received message 7 with its domain name.
Recommendation 9: Inclusion and checking of eUICC identifier U
Amend the RSP specification so that the server includes the eUICC identifier U from the initial authentication (message 7) in the signed profile-binding (message 8–9), and that the eUICC checks the identifier upon receipt of the message.
Recommendation 10: Eliminate dependency on TLS
Redesign the RSP protocol so that it does not depend on the TLS channel for any critical security requirements. This can achieved by implementing recommendations R1, R2, R3, R7 and R9.
For recommendations 7, 8, 9 and 10, the research paper assumes that the adversary can replace/replay part of honest SM-DP+ (or eUICC) signed messages with false signatures. That should fail at the honest SM-DP+ (or eUICC) side due to the way smdpSignatureX and euiccSignatureX are being chained.
According to SGP.22, eUICC U would reject the message because smdpSignature2 would not match. Based on the described scenario, the euiccSignature1 from U would be replaced by the signature from U’. Therefore, smdpSignature2 would be created on the concatenated objects: smdpSigned2 | euiccSignature1 (U’).
However, eUICC U would expect smdpSignature2 created on the concatenated objects: smdpSigned2 | euiccSignature1 (U). Therefore, the signature-chaining mechanism prevents the adversary from replacing partial messages and/or signatures.
Conclusions
The GSMA would like to thank and congratulate the researchers on the quality and rigour of their work. Publication of the paper provided a good opportunity for GSMA to revisit RSP security and consider the need to potentially enhance future RSP protocol versions.
As the research is largely grounded on the assumption that the end points are compromised, and because of the controls GSMA has put in place to mitigate the known risks, the practicalities of the attacks described in the research paper, and the opportunity for them to be executed, are not significant.
The GSMA welcomes constructive security research that has the potential to enhance security and resilience levels across the mobile ecosystem. For that reason, GSMA operates a Coordinated Vulnerability Disclosure (CVD) programme that is designed to support security researchers and the wider ecosystem to resolve vulnerabilities that have the potential to impact network, service and customer security. Further details about the programme are available here.