After introducing the eSIM (eUICC) Remote Service Provisioning (RSP) concepts in the previous 3 posts of this series it’s now time to have a look at the security implementation. Security is obviously of paramount importance in the process as the virtual SIM that is downloaded contains the identity (IMSI) of the user and the secret key used for authentication and generation of encryption material. If these two pieces were ever stolen in the RSP service chain it would be the greatest possible disaster for mobile network operators.
The only way to make a data transfer secure and private is mutual authentication in combination with end to end encryption. The eUICC soldered into the phone must be absolutely certain that the profile (virtual SIM) it receives comes from a valid SM-DP+ (provisioning) server on the Internet from which the user wants to receive a virtual SIM (a profile). On the other end of the connection, the SM-DP+ server on the Internet must be absolutely certain that there really is an eUICC at the other end of the connection and that there is no way to extract the secret key and other confidential information during the transmission or afterward.
Ciphering
Let’s have a look at how data is encrypted before looking at how mutual authentication is performed. To encrypt data, each side uses a public and a private key. During connection establishment, each side sends its public key, for everyone to see, to the other side. The oder side then uses this public key to encrypt all data it sends. The only way to decrypt that data again is by using the corresponding private key, which is never shared with anyone. As only the private key can be used to decrypt the data it doesn’t matter that the public key was sent in the clear for everyone to see, it can’t be used to decrypt the data
Authentication
The next problem that presents itself is how each end of the connection knows to whom the private key they have received belongs to. This is crucial to know as otherwise an attacker between the embedded SIM card and the provisioning server could intercept the public key and forward its own public key instead. This way the attacker would be able to decrypt all data and encrypt it again before forwarding it to the other side. The way to solve this is by having an authentication procedure during the key exchange.
This is done by having a trusted third party, the certificate authority (CA), that signs the public keys of all embedded SIMs and all provisioning servers. Signing the keys is done by the CA by encrypting the public key of an embedded SIM or of a provisioning server with the CA’s private key. The combination of the public key of the eSIM / provisioning server and the encrypted version (the signature) produced by the CA is referred to as a signed public key certificate.
When the provisioning server receives such a signed certificate from an eSIM it uses the public key of the CA and decrypts the signature part of the certificate. If the result matches the public key that was part of the certificate, the other end is authenticated. Equally, when the eSIM receives a public key + a CA signature for it from a provisioning server it also uses the public key of the CA to decrypt the signature. If it matches the public key that was sent alongside, it knows that the CA trusts the public key of the provisioning server. The important part to realize is that the eSIMs and the provisioning servers have to trust the CA that it has only signed public keys from devices (eSIMs and provisioning servers) it trusts. Note that the word ‘trust’ was used twice in the previous sentence: The CA signs a public key that it trusts to belong to a valid entity and later on the eSIM or provisioning server trusts the CA. This chain of trust is also referred to as Public Key Infrastructure (PKI).
Using such a chain of trust makes a man-in-the-middle attack impossible because a device in the middle can’t replace such a certificate by his own because it was not signed by the CA. As a consequence a device in the middle can’t decrypt and re-encrypt any traffic even though it has seen both public keys. This is because data can only be decrypted with the private keys that are never shared. To prevent another man-in-the-middle attack approach, the eSIMs and the provisioning servers have to have a permanent copy of the public keys of the Certificate Authorities they trust so they can’t be tampered with.
The concept and implementation of the authentication procedure and use of a private/public key pairs that I have just described is the same as is used today when a web server supplies its signed public key during HTTPS connection establishment. The major difference is that in the web server example, only the web server authenticates itself to the web browser while the web browser sends an unsigned public key. In eSIM remote service provisioning, however, each party sends its public key that was signed by a certificate authority.
Authentication and Ciphering in Practice
In practice this is done as follows: As the eSIM is not directly connected to the Internet, it needs the LPA app on the smartphone as described in a previous part to establish a connection to the SM-DP+ provisioning server on the Internet, e.g. via Wifi. Once that connection is established, the LPA helps the eSIM to perform mutual authentication and to set-up an end-to-end encrypted tunnel from inside the eSIM to the SM-DP+. Once this is done the LPA only sees encrypted traffic, i.e. it has no means to look inside the traffic it receives and forwards from and to the eSIM and the SM-DP+.
Getting Certificates Signed
On the Internet there are hundreds of certificate signing authorities that are trusted by web browsers. For eSIM remote service provisioning this would not be secure enough. As a consequence the eSIMs and provisioning servers only trust very few CA public keys. In practice, the GSMA is in control of the certificate signing process for SM-DP+ servers and eSIMs. Here is a practical example: If an eSIM manufacturer wants to produce a million eSIMs it has to generate one million public/private key pairs and get the public keys signed by the GSMA certificate signature chain. On the network side there will probably only be a handful of SM-DP+ servers, so there will be only a few certificates that have to be signed for the server infrastructure.
No Trust for the LPA app
It is important to realize that the authenticated and encrypted tunnel is from the eSIM to the provisioning server. The LPA app merely helps to set up this connection and forwards the data. However, it only forwards the packets and is not part of the tunnel. As a consequence the LPA app does not have to have a signed pair of public/private keys, it simply uses an unsigned public/private key pair to encrypt its communication with the SM-DP+. This means that the GSMA has no control over the LPA app.
Summary
To end this post here’s the elevator pitch for eSIM Remote Service Provisioning security: Public/Private keys are used to establish an end-to-end encrypted tunnel between the embedded SIM and a provisioning server on the Internet. To prevent man-in-the-middle attacks, each side authenticates the other during tunnel establishment by trusting the enclosed signature of a Certificate Authority that has been generated for the public key of each side. In practice the same method is also used between web servers and web browsers to establish HTTPS connections. The main difference is that only the web server authenticates itself while in the eSIM world each side authenticates to the other.