Robin Duke-Woolley, the chief executive of Beecham Research, interviews Laurent Leloup, the product line manager, and Stephane Quetglas, the marketing director, of Thales DIS (Digital Identity & Security) to understand how integrated SIM (iSIM) technology has been developing and what it enables in IoT.
Robin Duke-Woolley: It has taken several years to establish the embedded SIM (eSIM) in the IoT market. Now attention is moving towards the iSIM. Why is there a need for a standard for iSIM?
Laurent Leloup: Like eSIM, we need to have an iSIM that is fully endorsed by GSMA in compliance with the remote SIM provisioning (RSP) standard. This ensures that not only the hardware is secured, but also compliance with the remote provisioning servers and compliance with a secure production process. All of this is needed to provide an iSIM solution that can scale to meet the rapidly-growing demands of the IoT market.
RD-W: What do you mean by secure production process?
LL: A secure production process is needed because to make an iSIM you need to load the initial profile of the mobile network operator (MNO) in a secure way. For an iSIM, the integrated chip will not go through the embedded universal integrated circuit card (eUICC) manufacturer production site, which is a secure place. Instead, it has to be done by the device original equipment manufacturer (OEM) and it must be done in a secure way.
This is a specific process that was standardised by GSMA which implies a security process and certification only for the system on chip (SoC) maker, a vendor such as Qualcomm, and the eUICC manufacturer. This specifically avoids the need to secure the device OEM production site.
RD-W: Does that mean the device OEM needs to put further investment into their production process?
LL: No, they only have to rely on an SoC maker and eSIM manufacturer that are compliant to the GSMA process. The specific process was created by GSMA to avoid this. Without this process, the OEM would need to be certified by GSMA through a certification process called SAS-UP – the Security Accreditation Scheme for UICC Production – which is quite onerous. This can be avoided completely by relying on the SoC maker and the eUICC manufacturer. By doing so, a Root of Trust is loaded into the SoC directly by the SoC maker, with the eUICC manufacturer then following up later with the MNO profile data.
This is a two-step process. The SoC maker is responsible for loading securely a key inside each SoC. The eUICC manufacturer is then responsible for preparing the profile data for each specific chip, binding each data to a unique SoC key.
RD-W: Why is this a two step process? Does that not make it more complicated?
LL: There are three alternative ways to ensure security is maintained. The profile data could be prepared by the eUICC manufacturer and loaded by the SoC maker in a secure environment, but that would then cause a lot of new stock-keeping unit (SKU) numbers and logistical issues for the SoC maker to deal with. Another alternative would be for the OEM to load the profile data in a secure environment. However, setting up that process is expensive and complex for the OEM.
The third alternative is the two-step process created by GSMA, which provides for the loading of sensitive data at the latest stage of device production without any security constraint being needed at the OEM production site. To achieve this, the SoC maker loads securely a unique specific key inside each SoC. The eUICC manufacturer then prepares the data set bound to a specific SoC. Each data set is secured for a specific chip and can only be loaded inside the chip for which it was prepared. They cannot be changed, cloned or tampered with. The process is designed to avoid any security threat on the OEM side and is the simplest for all the stakeholders.
RD-W: Is this process certified? If so, what does that mean?
LL: It is fully certified by GSMA, meaning that both SoC maker and eUICC manufacturer will be audited by GSMA-accredited auditors to ensure that both entities are fully compliant with two-step personalisation process requirements. This allows the OEM to receive and load the data in a non-secure environment.
GSMA certification also includes hardware and software certification, meaning that external labs accredited by GSMA have implemented all types of attacks – hardware and logical software attacks – and it passed all these tests. There is then a stamp provided by GSMA to prove that everything was thoroughly checked: production process, hardware and software, and compliance to the RSP standards.
If you don’t go through this standard recognised scheme to prove the solution is secure, MNOs will not usually trust that security without themselves looking at the details of what has been done to check the security of the hardware and the software, and of the production process. When a proprietary implementation is used, they have to look in-depth at the details for each implementation to ensure that their sensitive assets are not jeopardised. That is complex and time-consuming to do.
RD-W: Has this been introduced before, or is this the first time that a two-step process like this has been considered?
LL: It is being introduced for integrated SIM, so it is indeed the first time this process has been launched. We are working with Qualcomm right now as the first certified SoC maker for step 1. Thales is the first certified eUICC manufacturer for step 2.
RD-W: What are the main benefits for IoT device manufacturers of introducing this process?
Stephane Quetglas: This process enables secure RSP. An iSIM that does not go through this process can only be supported by MNOs if they each create their own security certification process. This is complex and time-consuming to achieve because each potential security issue needs to be studied and tested. At best, this will only be done for a few very large deployments. In practice, it means that the subscription cannot be changed remotely.
In contrast, this standardised process opens up the iSIM opportunity with secure remote SIM provisioning for the whole market and is therefore the only truly scalable approach.
RD-W: Is this compatible with IoT SAFE?
SQ: Yes, it is. IoT SAFE can certainly work on iSIM because you just need to have a SIM or eSIM functionality. Another interesting point is that you can use this SIM secure enclave to implement more features. A secure enclave within the SoC is also referred to as an integrated tamper-resistant element (TRE) by the Trusted Connectivity Alliance. SoC makers also use the term secure processor unit (SPU).
With IoT SAFE, you can authenticate the device, the cloud, sign transactions, and more but what you can do with an integrated SIM is provide the IoT SAFE functionality plus you can have a secure element approach, which is totally separate from the integrated SIM functionality. That can be used for example for secure boot for the device, so that when the device starts up all the software modules are verified against the initial values that were signed by the device maker. You can check these modules have not been modified or tampered with in any way. You can also imagine working on other value-added services like activating features in the software for the device, which means you can deliver different products with a single piece of software for your customers with features you can monetise. All these kinds of things become possible. On the other hand, when you have an embedded SIM that sits outside the SoC, it is very difficult or even impossible to implement them.
Once you are in the device, then you can add more services. We can talk about IoT SAFE being naturally compatible with integrated SIM but we should say that being inside the device itself means you can provide more security and also a range of new value added services and features that can be monetised, so it opens up a new range of opportunities.
RD-W: Why does it enable more services to be introduced by being in the secure enclave, rather than as a separate eSIM?
SQ: Because typically the eSIM is external to the SoC, so when you start the device all the software within the device will come alive and then, once everything is OK, the device will start connecting to the cellular network and will then switch the eSIM on. On the other hand, if the eSIM is already inside the SoC, everything associated with the eSIM can start up earlier. Externally there are interfaces, so the interface between the external eSIM and the cellular module of the device is standardised. There is not much extra you can do with that. But when you are inside the SoC already, you can start to think about application programme interfaces (APIs), you can work with middleware providers, you can provide a package that is broader and more powerful.
RD-W: Do you expect the iSIM to replace the eSIM?
SQ: In the very long run – up to 15 years – possibly. Not in the short to medium term though. It takes a long time to add the secure enclave into a chipset and there are different chipsets for different connectivity requirements. Depending on the use case, you may need voice, you may need very high speed or low power consumption. Some options are likely to be introduced much faster than others.
RD-W: Is the iSIM with integrated IoT SAFE particularly suitable for very small form factor devices? Is it likely to be introduced in these first?
SQ: That makes sense. For the industrial use cases, that would include the sensors that you may need to deploy. In the smart city, you may need a lot of sensors as well. Certainly for wearables. Where you have small objects that deliver value in the industrial space as well as those in the consumer space.
Comment on this article below or via Twitter: @IoTNow_OR @jcIoTnow
