The European Commission and ENISA solicits feedback on eUICC Specification report which can be used for implementing EUDIW. Through the specifications, ENISA aims to facilitate the certification of conformity of the eUICCs with the EU Cybersecurity Certification Scheme on Common Criteria (EUCC). Methics supports the ENISA’s efforts to streamline eUICC specifications. However there are some issues to which Methics has already provided feedback directly to ENISA and also through a joint statement as a Eurosmart member. The published draft specifications will need some modifications to reach their goals.
Link of report: Here.
Background:
The eUICC is a secure element housed inside user’s mobile phone in contrast to the traditional UICC which is a removable card. The eUICC is used by multiple mobile operators, and each of them has a Profile. One Profile can be active be active at a time. The Profile comprises the operator data (MNO specific) related to a subscription, including the operator’s credentials and different SIM based applications. The Profile remains the property of the operator as it contains items “owned” by the operator (IMSI, ICCID, security algorithms, etc.).
The content and structure for interoperable Profiles stored on eUICCs are similar to those installed on traditional SIMs. Operator Profiles are stored inside Issuer Security Domains and are
implemented using GlobalPlatform standards.
Since, GSMA introduced eSIM specifications in 2017, Methics has been providing Trust Services like Mobile ID through eUICC as well. We have been providing eSIM applets for Swiss Mobile ID since 2018. We have since expanded our offerings to other regions,including Mongolia, Oman, and Moldova, working with local Mobile Network Operators (MNOs) to launch mobile signature and authentication services powered by eSIMs.
Mobile ID applets can be run in either Supplementary Security Domain (SSD) or Issue Security Domain (ISD) according to ETSI Standards (ETSI TS 102 225 and 102 226). As GSMA standard is quoted in this report, which says “The content and structure for interoperable Profiles stored on eUICCs are similar to those installed on traditional SIMs.” For UICC (SIM) MNOs have a choice if the load the applet in SSD or ISD. But in eUICC case, there is only ISD, which contains MNO-SD and inside MNO-SD, Supplementary Security Domain (SSD) is present.
Annex I and Annex II of eIDAS 1(910/2014) defines requirements of SSCDs (both local and remote). When implementing the local signature in the UICC or in the eUICC, the ETSI standard TS 119 461 becomes the key standard. The other standards (EN 319 411 and EN 319 422) provide additional context and technical requirements for secure implementation and communication of Signatures with eUICC as SSCD.
This Feedback of report, is divided into 2 categories, i.e. Technical Feedback and General Feedback
General feedback:
1. This report solely focuses on future eSIM architectures, and not how current eUICC implementations can be used to provide trust services.
2. There is no current roadmap or timeline visibility when GP/GSMA SAM/RSP will become mandatory and MNOs have to comply with it. However, with eIDAS 2(2024/1183), member states must provide wallets by 2026.
3. There are no PP and standards defined for Applet at the moment for SAM/RSP and future eUICC use cases.
4. In terms of timeline, interim solutions needs to be defined by ENISA. As Article 51 of eIDAS 2 mentions that current Secure Signature Creation Devices (SSCDs) will remain valid until May 2027. So eUICC’s without SAM can be used for Wallets.
5. The report SHOULD include how eUICC without SAM architecture could be certified in EUCC. Which established the need in this ENISA report as well to include a new type, Type 0 of eUICC. This is type of eUICC independent of SAM and which can be used to power EUDIW.
6. Protection profile needed to comply to provide signature with eUICC is same as for UICC i.e. is PP_QSCD maintained by BSI/SOG-IS. These PP are used to implement CEN/EN419 211-2-Protection profiles for secure signature creation device-Part 2: Device with key generation and CEN/EN419 211-4-Protection profiles for secure signature creation device-Part 4: Extension for device with key generation and trusted channel to certificate generation application.
7. Mobile ID applets can be run in either Supplementary Security Domain (SSD) or Issue Security Domain (ISD) according to ETSI Standards (ETSI TS 102 225 and 102 226). For UICC (SIM) MNOs have a choice if the load the applet in SSD or ISD. But in eUICC case, there is only ISD, which contains MNO-SD and inside MNO-SD, Supplementary Security Domain (SSD) is present. So currently, Type 0 eUICC are running the Mobile ID applet in SSD present inside ISD-P. Figure below shows eUICC with Mobile ID applet running in SSD of ISD-P container.
8. eUICC of Type 0 can be evaluated where TOE (target of evaluation) is described in a way that it secures the signature creation data (SCD). Applet with eSIM, can be evaluated for EAL4 using existing protection profiles of SOG-IS Scheme. As Key Generation happens on on eUICC. eUICC TOE needs to be conformant with EN 419 221-2 and 419221-4 for key generation, and key transport.
Technical feedback:
Below list tackles technical aspects related to eUICC, applets and SAM.
1. SAM introduces a new SAM_SM business model for TSPs to provision SAM applets, which could operate independently of MNOs.
2. This model might rely on independent WiFi networks. Based on our thinking, a RAN operator needed in every case and this operator might have already ISD-P on eUICC. Therefore, we do not see it practical for a non-operator to start provisioning SAM applets without defining the provisioning methods
4. Applet should be provisioned at the same time as the ISD-P is provisioned, so applet is loaded along with eSIM profile in user device when eSIM is activated (and eSIM profile downloads to phone)
5. SAM applet addressing, using TAR and AID, does not take into account the entry of ASPs onto the same platform as MNOs. Moreover, handling of TAR and AID values are not defined in the report.
6. SAM applet requires an applications interface to communicate with the user and/or the app. There is no consideration for applet communication via the CAT interface, web interface or via some Open Mobile API communication.
Conclusion
We thank the Commission for the possibility of giving feedback on the draft specifications. We hope that future version will better support transition (intermediate) measures, so vendors are able to provide EUDIW to end-user by 2026 as eIDAS2 regulation dictates.
The success of the using eUICC for EUDIW depends on the sustainability of the business models of security domains, provisioning interface and certification route. We hope to see cross-border cooperation on wallet certification and look forward to a harmonized certification framework. The European identity wallets should support free movement within the European internal market and be usable in global use cases.
Methics is positioned to support stakeholders responsible for making the EDIW a reality. As a global leader of open standard Mobile IDentity services, our products are delivering tech for strong authentication. Methics can integrate existing services and high level of assurance identity mechanisms to a new identity framework. We support digital identity over a wide variety of authentication mechanisms and security assertions. Methics will offer a bridge between traditional PKI and W3C decentralized identity projects to provide identity and signing services. Feel free to get in touch with us if you want to discuss the presented model of MUSAP or have some other queries related to Digital Identity.
Publish Date: 4th September 2024 Written and Edited by: Ammar Bukhari & Jarmo Miettinen