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.

Go directly to our eUICC test solutions

• eUICC Profile Manager
• eUICC Profile Creator
• COMPRION Network Bridge

 

Definition

[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”.

 

Architectural Overview

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.

 

Card Structure

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.

 

Off-Card Infrastructure

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.

 

Interfaces

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.

The interfaces can be separated into two groups:

 

1. eUICC interfaces – ES5, ES6 and ES8:
   These interfaces control the access of the backend servers to the eUICC. Each of the different combinations between off-card role (SM-SR, SM-DP and MNO) and on-card security domain (ISD-R, ISD-P and profile) has its own interface.
    
2. Off-card interfaces – ES1, ES2, ES3, ES4 and ES7:
   These interfaces are used for information exchange between the various off-card entities, e.g. for sharing the “eUICC information set” (EIS), transmitting profile data, or approving eligibility requests. The eUICC interfaces are of special interest for the global system because they require a secure and reliable over-the-air (OTA) communication chain to be in place. Security is granted by GlobalPlatformspecified secure channel protocols (SCP). There are two groups of SCPs:
    
   • SCP80 (via SMS or CAT_TP) or SCP81 secure the transport layer over the radio access network

   • SCP03 protects the data within the transport packets to grant a confidential data transmission between the service provider and its appropriate security domain on the eUICC

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.

 

eUICC 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.

 

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.

 

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.

 

Summary

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:

• How will the comprehensive number of conformance tests based on the contact 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. interface between UICC and mobile equipment be implemented in an eUICC environment?
• How can system tests cover the whole communication chain with its specific use cases in a reproducible and manageable lab environment?

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.

 

What Automotive, M2M and IoT Gain from eUICC

• Robustness: Less susceptible against environmental conditions
  (low and high temperatures, vibrations, humidity, dust)
• Higher cost efficiency: Production in very large quantities, fast shipment everywhere in the world and individual provisioning after delivery
• Less risk of theft as they are permanently installed

---

• eUICC
• GSMA
• eSIM
• Remote Provisioning