How to ensure Third Party SIM Applications on the eUICC are always available?
July 21, 2017 - Might there already be solutions available for third party applications installed on an Embedded UICC (eUICC) profile to be always available when the profile is switched?
In my previous discussion on this topic (see: here) I mentioned how the need for third party applications in both M2M and Consumer RSP domains had highlighted an issue where these applications ‘disappeared’ when the profile was switched. After further investigation into this issue new options have emerged that may help resolve this problem, or at least push it closer to delivering a viable solution.
On M2M or Consumer RSP devices, Service Providers (SPs) or End Users can load applications associated to the MNO Security Domain (MNO SD) hierarchy in the enabled profile on the eUICC, which belongs to the MNO, rather than being installed in the eUICC independently of any particular profile. After switching profile any applications installed under the MNO SD will currently not be available to the End User in Consumer RSP or the SPs in M2M, and that indeed is not explicitly addressed by the GSMA specifications for either of these domains.
How to create an ‘always on’ app?
Previously I asserted that GSMA needed to resolve this issue to realise the full potential of the value add of the eUICC acting as a secure element. Highlighting that the best solution may be to use a Central Services Security Domain (CSSD) associated to the Issuer Security Domain-Root (ISD-R), where the third party application executable load files (ELFs) can be used to create new third party application instances into their own third party Supplementary Security Domain (SSD) associated to the CSSD under the ISD-R. This may require that the M2M and Consumer RSP specifications would need to be updated, plus potentially the core GlobalPlatform specifications to accommodate this solution and any other related potential issues.
But maybe this issue isn’t actually a GSMA problem to solve, and they could just let the eUICC manufacturers (EUMs) develop their own proprietary solutions? As it happens this has already occurred and indeed some EUMs do have their own proprietary solutions where they effectively view the whole eUICC as a Secure Element which benefits from the flexibility provided by GlobalPlatform card specifications with the remote SIM provisioning layer for either the M2M or Consumer domains.
But might there be future interoperability issues awaiting ‘just around the corner’ if the industry pursues this approach? Profiles and these third party applications would be separate entities with no relationship other than the fact that they both are installed on the same eUICC, so it’s not expected that there would be any interoperability issues in this regard. But instead the ability to provide this type of functionality may be seen as a USP for the EUMs where the SPs and End Users require this type of functionality. So it might be possible for ‘always on’ third party applications to ‘live’ in M2M and Consumer RSP eUICCs without the need to standardise this functionality.
However, this potential approach to solving this issue still doesn’t fully address the problem of the ‘always on’ third party application. It allows the EUM to install and manage the third party application on the eUICC to avoid the issue caused by switching profiles, but what happens if the End-User wants to install an application in the CSSD hierarchy that has the same Application Identifier (AID) as another application in the MNO SD, or if they want to install new third party application with NFC privileges in the CSSD hierarchy? This uncovers new problems that needs to be solved mainly for the Consumer domain, as in the M2M domain the SP will hopefully be fully aware of their third party applications and associated AIDs and it is unlikely that they will use NFC based applications. Any potential solution would require updates to the GSMA specifications for Consumer RSP such as allowing the ISD-R to have a Global Registry view of the CSSD hierarchy and also for the Contactless Registry Services (CRS) to have the same access beyond the MNO SD hierarchy. Plus even though it might not be considered appropriate or necessary to add it to the M2M specifications, it might be wise to safeguard against it ever becoming an issue in the M2M domain in the future.
Another possible solution is that devices that have both an eUICC and also an embedded Secure Element (eSE) could allow the third party applications to be installed in the eSE in complete isolation from the profiles in the eUICC. In this case the eSE can deliver the same level of assurance regarding the associated security i.e. ELA 4+. The disadvantage of this solution is that not all devices will offer the eSE, especially in the M2M domain where the cost of both the eUICC and the eSE functionality is prohibitive to the use case of low end M2M devices. Therefore this solution is more likely to be applied to the Consumer RSP domain.
The GSMA may not need to resolve the issue surrounding third party applications due to the fact that the EUMs and OEMs might already have the answer. Whether it be EUM proprietary solutions to store the third party applications on the eUICC or in the eSE by the OEM, this non-standardized approach to ‘always on’ third party applications might just be the solution for SPs the M2M domain where it is expected that third party applications for identification and authentication may be mainly used, required to address security concerns regarding the data itself. However, it remains to be seen if this non-standardized solution will cause any future interoperability issues for the M2M and Consumer domains, and it only partly solves the problem for the Consumer domain, introducing the new dilemma of how to manage duplicate AIDs, NFC based applications across the complete eUICC security domain hierarchy and any other issues that might occur. So the strong and compelling value-add of the eUICC - namely, its role as a hardware secure element is potentially part of the solution to its own problem, where the OEMs might also be able help out in the Consumer RSP domain. Unfortunately it would probably still require updates to the GSMA Consumer RSP (and potentially the M2M specifications) to fully resolve all these issues to deliver a standardized and fully functional solution that guarantees interoperability.