eSIM for IoT

standard
evolution

In December 2013, the GSMA released version 1.1 of the “Remote Provisioning Architecture for eUICC” and the associated Technical Specification describing the implementation, creating a de facto standard for Subscription Management systems for machine-to-machine (M2M) and IoT devices.

A strategic weakness of this specification was the absence of an interoperable profile download mechanism. This gap was closed with the release of the Interoperable Profile Description specification by SIMalliance in May 2015 and the GSMA SGP.02 v3.0 specification in June 2015.

Figure 1: GSMA SGP.02 M2M

By loosening the dependencies between the eSIM and the managing platform, independence of the Subscription Management service from the eSIM manufacturing process became possible, creating opportunities for new players in the market.

use case
example

The M2M subscription management functionality is illustrated below for one of the major IoT uses cases. Also known as “insurance”, this scenario prevents a connectivity lock-in for the IoT service provider. It allows switching connectivity from one operator to another either for an entire fleet of devices, or a subset thereof.

Figure 2: M2M subscription management

(1) The device fleet of the service provider is provisioned with connectivity from MNO A and the eSIMs of the devices are registered with a Subscription Manager (SM-SR) of the IoT Service Provider’s choice.

(2) At some point the IoT service provider decides to move the connectivity of the devices from MNO A to MNO B and puts the related contracts in place. In an automated process, the SM-SR requests profiles from the “profile data preparation” system of MNO B (SM-DP) and downloads the profiles to the selected devices. Whether the profile of MNO A remains on the eSIM or is deleted is part of the policy agreement between the parties.

Note: M2M remote provisioning requires cellular connectivity; hence, the eSIM must have an active profile at all times. The initial profile that is stored on eSIM during production is also known as the “provisioning” or “bootstrap” profile with the dedicated function to download an “operational” profile.

system
architecture

The GSMA M2M architecture is a server-driven push model that enables the centralised management of eSIMs and profiles by the owner of a fleet of devices. This management of profile and eSIM lifecycle requires the involvement of two system components.

The SM‑DP (Subscription Manager Data Preparation) represents the profile owner and manages the mobile network operator’s profiles. It securely encrypts the network access credentials (i.e. the profile), ready for remote secure provisioning to a deployed eSIM.

Figure 3: M2M Remote Provisioning System for IoT

The SM‑SR (Subscription Manager Secure Routing) is in charge of eSIM management and represents the eSIM owner. It is also the entity that securely delivers the encrypted operator profile to the eSIM.

Once the profile is downloaded and installed, the SM‑SR manages the eSIM remotely during its lifetime using a specific set of operations, such as profile activation, deactivation or deletion. For the remote OTA communication with the eSIM the SM‑SR can use different transport channels of the mobile network, such as SMS or HTTPS.

Figure 4: Transport Channels

The following network connectivity parameters are stored on eSIM to enable SMS and HTTPS transport for subscription management procedures:

(1) SMS-C address - through which SMS are routed

(2) SM-SR destination address (DA) - to which eSIM originating SMS are sent (conversely, in case the SM-SR is sending notifications by SMS this becomes the originating address of the message)

(3) SM-SR IP address - to which the eSIM device is opening the TCP connection for HTTPS session

(4) APN (Access Point Name) - the data gateway between the mobile network and another network through which the data is routed

The SM‑SR is free to select the most relevant transport protocol according to the capabilities of the targeted eSIM and device as well as the operation to execute.

security
domains

A trusted security level for the communication between Subscription Management system and eSIM requires the authentication of system entities as well as the protection of integrity and confidentiality of the communication. An established concept, the so called Security Domain, provides just that and is central to the security architecture of eSIM (as well as smart cards in general).

Figure 1: Global Platform Security Domain

As defined by Global Platform (an organization established by companies from the payments and communications industries) a Security Domain acts as an on-card representative of an off-card authority and provides secure communication support.

They are special applications containing key material and algorithms for cryptographic operations and have specific privileges managing the card’s applications.

The eSIM Security Domains ISD-R, ISD-P and MNO-SD facilitate the separation of functions and data of the two defining roles in the IoT subscription management system: the owner of the eSIM and the owner of the profile.

Figure 2: eSIM Security Domains

They ensure that each role has only access to the data in its domain. Nonetheless it is possible for a single party to assume both roles, for example an MNO that is not only profile owner but eSIM owner as well.

interface
security

GSMA incorporated GlobalPlatform standards to secure the “on-card” eSIM interfaces ES5, ES6 and ES8 with Secure Channel Protocol (SCP) to offer a security level at least equivalent to the security reached by the traditional SIM and its application management systems.

Security for ES5 functions between SM-SR and ISD-R depend on the selected transport channel. Protocol SCP80 is used for SMS (and the optional legacy protocol CATTP), while SCP81 is applied for TLS over HTTP (HTTPS).

 

Figure 3: ES5 Interface Security

Both protocols require algorithms and keys to be pre-shared in the system. The keys are loaded into the ISD-R of the eSIM during manufacturing. They are also imported into the SM-SR using EIS files (eUICC Information Set) containing not only the ISD-R keys but any other relevant information about the eSIM platform such as installed profiles, memory capacity, version information and other details.

For protection of ES8 functions between SM-DP and ISD-P the Secure Channel Protocol SCP03 is used as well as the GSMA variant SCP03t. However, as only the SM-SR can establish a remote transport channel with the eSIM, SCP03(t) is always tunnelled, first through a secure connection between SM-DP and SM-SR, then through a SCP80/81 secured tunnel between SM-SR and ISD-R.

Figure 4: ES8 Interface Security

Contrary to the ISD-R, which is personalised during eSIM manufacturing with pre-shared keys, an ISD-P is typically created post-issuance and no initial keys are available to secure the communication. Therefore ES8 contains a procedure by which the first SCP03(t) key set is loaded into the ISD-P by its SM-DP. This is based on an elliptic curve key agreement scheme, also defined by GlobalPlatform, the so called “Key Establishment with Scenario#3-Mutual Authentication”.

The ES6 Interface for the remote update of profile components such as the profile connectivity parameters, uses the same secure channel protocols as ES5, with SCP80 for SMS (and CATTP), and SCP81 for HTTPS. Besides the MNO-SD shown in the diagram, any other Supplementary Security Domain (SSD) of the profile can be used.

Figure 5: ES6 Interface Security

The OTA system is not covered by the GSMA specification. It may be a legacy system used for SIM as well as eSIM profiles. As with ES5, the keys for SCP80/81 must be pre-shared and are either loaded during the profile download procedure by SM-DP or by the EUM during eSIM manufacturing in the initial profile.

While the security of “on-card” eSIM interfaces is specified in detail by the Global Platform standards for Secure Channel Protocols, the “off-card” interface security is more flexibility as to how the required security level is implemented. As part of its security certification scheme for subscription manager roles (SAS-SM) the GSMA has released a number of documents providing guidelines and requirements for security certification, which we address in a separate paper.

system
PKI

To create trust between the different parties throughout the eSIM ecosystem GSMA has defined a Public Key Infrastructure (PKI) supporting the use of Certificates for authentication.

A Certificate Authority (CA) is acting as a trusted third party for the purpose of mutual authentication of all system entities, using a self-signed Root Certificate to verify certificates issued and signed by the CA.

Figure 6: eSIM ecosystem certificate chains

The CA signs the certificate of the eSIM manufacturer (EUM) that becomes a sub-CI signing the operational eSIM certificates it issues. The CA also signs the operational SM-DP and SM-SR server certificates.

This trust model is deployed in the global, open eSIM ecosystem using a GSMA assigned CA but also effectively secures closed systems with a private CA.