Article published in COMPRION Customer Magazine “Testability Times“, August 2015
This article gives an overview of the GSMA specifications concerning embedded UICC (short eUICC), especially the infrastructure needed to provision and personalize such an entity in the field. At the same time, it will clarify and diversify several similar concepts like eSIM, virtual SIM or soft SIM, as far as this is possible today since those various terms are yet being used very carelessly.
[An embedded UICC is] A UICC which is not easily accessible or replaceable, is not intended to be removed or replaced in the terminal, and enables the secure changing of subscriptions. (Source: The GSMA Embedded SIM Specification for remote provisioning)
The upcoming sections will look into the details of this definition.
"An embedded UICC is..."
First off, it becomes clear that the eUICC is based on the well-known concepts of a traditional UICC. This implies that there are exactly the same expectations and requirements concerning functionality and behavior from the terminal’s point of view. All relevant UICC specifications remain valid. This does not only include the core specifications but refers to the appropriate test specifications, also, even though some of them cannot be implemented the same way as before when it comes to an eUICC. The technical specification of the eight contacts will also stay the same. This means that protocols and electrical behavior will not change.
At the same time, the GSMA explicitly points out what an eUICC is not. There is a clear distinction between the eUICC and other concepts like soft SIM or virtual SIM. Such approaches, which aim at the replacement of the physical entity – either replaceable or soldered – by software or platform-dependent hybrid solutions combining hardware and software, will have to be kept separate from the eUICC concept. It is a common concern of the MNOs (mobile network operators) that an open number of non-standardized solutions might render the certification and approval of security-relevant requirements very complex and costly if not even impossible.
"...An embedded UICC is not easily accessible or replaceable, is not intended to be removed or replaced in a terminal"
In specifying the eUICC, the GSMA has focused on the M2M (machine-to-machine) market. Such products are frequently used in rough environments, where vibration, dust or temperature might have serious impact on the reliability of contacting in case of classical UICCs. In order to solve the contacting issue, there are specific eUICC form factors (MFF1 or MFF2) which allow soldering the chip to a shielded terminal module. This implies that there is no easy way to replace the eUICC after delivery of the module. And what is even more important: There is no way to access the contacts any more as it has been done by traditional test and measurement tools for tracing and simulating the UICC interface.
The eUICC concept originally designed for the M2M market, might very well apply to consumer devices, too. It’s on the horizon that there will be an increasing number of devices, which might rely on an eUICC rather than a replaceable SIM card in the future, including mobile equipment like smart phones.
By the way, those parts of the eUICC concept, which refer to the module’s infrastructure are applicable to replaceable UICCs as well and could be used for traditional form factors like mini-SIM or micro-SIM.
"An embedded UICC enables the secure changing of subscriptions"
One of the most important requirements to an eUICC is obviously at hand: If there is no way to replace the eUICC after delivery, there is a strong need for a secure way of changing the service operator’s subscription without exchanging the module itself. This implies a very substantial difference in the eUICC’s life cycle.
During production, the classical UICC has been personalized for one specific MNO and to one specific subscriber without a chance to change this personalization during the card’s lifetime (figure 1). In contrast, an eUICC will only receive a so-called provisioning profile by the eUICC manufacturer (EUM) during production (figure 2). The only reason for this profile is to provide network connectivity for the mobile equipment in order to download the actual consumer subscription. This includes the file system, network access applications (NAA) and credentials as well as supplementary security domains (SSD) for third-party service providers together with their application. Hence, the effective MNO is selected much later during the life cycle, in fact after delivery of the device, when it is put into operation for the first time. After this initial selection, there might be various re-selections during the life cycle without having to replace the chip card. On an eUICC, it is possible to create new profiles or to delete old ones on demand. There might even be more than one profile on one eUICC at a time, with only one single profile being active at any point in time. This active profile determines the behavior of the eUICC from the user equipment’s point of view. This is why the one active profile is often referred to as the “eSIM”.
Figure 1: Classical life cycle with exactly one personalization (UICC)1 (Source: The GSMA Embedded SIM Specification for remote provisioning)
Figure 2: Life cycle with changing personalization over time (eUICC)1 (Source: The GSMA Embedded SIM Specification for remote provisioning)
Figure 3: Security Domain Structure on an eUICC1 (Source: The GSMA Embedded SIM Specification for remote provisioning)
To meet the given requirements, there is an infrastructure defined basing on a GlobalPlatform architecture. This refers to both, the hierarchy of the security domains on the eUICC itself as well as the off-card roles and services. In addition to this, services and security domains are interconnected by a set of well-defined interfaces.
The eUICC structure consists of a hierarchy of different security domains being assigned with specific access rights and privileges. The root of all eUICC accesses is the ISD-R (issuer security domain – root). This is the only way to create new ISD-P (issuer security domain – profile) instances as a container for a given mobile operator’s profile. Access to the profile data within such a container is restricted to the profile owner that means the MNO.
Each of the aforementioned on-card security domains corresponds to one of the newly defined off-card roles on the server side. Access to the ISD-R is controlled by the SM-SR (subscription manager – secure routing). This is the only instance with access to the necessary keys that can create new containers, delete containers no longer needed and activate or deactivate any given profile. After the SM-SR has created a new profile container (ISD-P), it is handed over to the profile owner who subsequently loads the profile data into that container. This is done by the SM-DP (subscription manager – data preparation). As soon as a profile is loaded and activated, the MNO has access to the internals of the profile as it would be the case with a traditional UICC, too. Each of these roles can be assigned to different security realms with their own certificates and keys in place. This guarantees that each of the roles is only able to access the data necessary for its specific tasks.
Communication between the various security domains and their respective backend representations
is specified by a number of different interfaces, including detailed descriptions for both, functionality and protocol security.
Figure 4: Interfaces1 (Source: The GSMA Embedded SIM Specification for remote provisioning)
The interfaces can be separated into two groups:
The stability of the communication channel ensures that the service provider has persistent contact to the mobile equipment and the embedded UICCs that have been delivered into the field million-fold, so that profiles can be maintained and services updated. This implies some serious requirements concerning the coverage of system tests for these interfaces.
ES5: SM-SR – eUICC (ISD-R)
Communication between the SM-SR and the ISD-R can be protected either by SCP80 (SMS or CAT_TP) or SCP81. SMS is mandatorily required by the specification while at least one of the others has to be supported additionally. Because of the small packet size and high overhead, SMS is better suited for small data volume transfers. Since many of the use cases involve higher amounts of data to be transferred, there will always be a demand for a packet-oriented protocol like CAT_TP or SCP81.
This interface allows the creation or deletion of profile containers (ISD-P) as well as activation or deactivation of the given profiles. Apart from this, the propagation of initial keys to a new container is another topic covered by this interface.
Figure 5: Interface ES51 (Source: The GSMA Embedded SIM Specification for remote provisioning)
ES6: MNO – eUICC (profile)
The MNO can access the activated card profile by exactly the same protocols as before. The MNO-SD can be accessed by SCP80 or SCP81. If necessary, data designated for a third-party SSD can be secured by SCP03 and embedded into the transport packets. From a functional point of view, this interface allows for providing the operator’s policies concerning the deactivation or deletion of the profile as well as setting specific connection parameters. The eUICC specification does not contain any additional requirements. It is important to mention that the keys used by ES5 and ES6 are not identical, that means these two interfaces differ from each other even though they might look similar at first glance.
Figure 6: Interface ES61 (Source: The GSMA Embedded SIM Specification for remote provisioning)
ES8: SM-DP – eUICC (ISD-P)
A special interface between the SM-DP and the profile container on the eUICC has been defined in order to deliver new profiles to the card. This interface facilitates a confidential data transmission protocol which does not even allow the SM-SR to read the data. To achieve this, the profile data is encrypted using SCP03 and embedded into the SCP80 or SCP81 communication. The main functions provided by this interface concern the key propagation between SM-DP and ISD-P as well as the download of the profile data.
Figure 7: Interface ES81 (Source: The GSMA Embedded SIM Specification for remote provisioning)
The GSMA Embedded SIM Specification for the remote provisioning of an eUICC is based on well-known technologies. Roles, protocols and functions constitute a specific application of the various GlobalPlatform specifications. From a technological point of view, there are no additional requirements raised by the specification. From an administrative point of view, though, there is an important question to be answered:
Who is going to fulfill the various roles that might be placed in independent security realms? The possible answers to this question imply substantially different business models.
We as test tool manufacturer are facing some very important challenges:
COMPRION provides answers and products to solve these challenges and continues to provide the markets with the solutions necessary to perform comprehensive quality assurance in the future. Stay tuned.
Figure 8: Projected Consumer Electronics Connections worldwide with alternative scenarios (Source: Beecham Research, GSMA)
Author: Henning Möller, Product Manager for Smart Card & OTA
COMPRION and Rohde & Schwarz announce the COMPRION SIMfony CMX500 solution, an extension of the COMPRION SIMfony family for 5G NR USIM/USAT device...
You frequently equip the already provisioned profiles on your subscribers’ devices with new apps? Then this is right for you. Learn how to create eSIM...