A method for authentication a device by an euicc

Abstract

The invention concerns a method for authentication a device (102) comprising an eUICC (104). The method comprises binding in a factory the eUICC (104) with an authorized device (102) comprising the eUICC (104). The binding is performed through storing in the eUICC (104) and the authorized device (102) at least a cryptographic key permitting to authenticate the authorized device (102) by the eUICC (104). The method comprises authenticating, upon an occurrence of an event, the device (102) by the eUICC (104) by performing a cryptographic operation and, if the authentication fails, determining that the device (102) comprising the eUICC (104) is not the authorized device (102), and, if the authentication is successful, determining that the device (102) comprising the eUICC (104) is the authorized device (102).

Description

[0001] A method for authentication a device by an elllCC

[0002] FIELD OF THE INVENTION

[0003] The domain of the invention is telecommunications and more precisely concerns a method for preventing the reuse of a eUlCC (embedded UICC, UICC being a Universal Integrated Circuit Card) embedded (e.g., soldered) in a terminal, for example a smart meter, a smart watch, or any loT device.

[0004] BACKGROUND

[0005] It has been discovered that fraudsters are able to unsolder eUlCCs from devices in which such eUlCCs were soldered. This can easily happen when a fraudster buys a smartwatch for example and, at home, unsolders the eUlCC embedded in this watch. The fraudster can then solder the eUlCC in another device, like for example a smartphone, and perform scam calls.

[0006] Some solutions have been proposed but these solutions only concern removable UICCs (Sim cards) and are based on the identification of the IMEI that is easy to clone.

[0007] There is therefore no solution for detecting that an eUlCC has been desoldered from an authorized device and soldered in another device.

[0008] SUMMARY

[0009] The proposed invention proposes a solution to this problem.

[0010] More precisely, the invention proposes a method for authenticating a device comprising an eUlCC. The method comprises binding in a factory the eUlCC with an authorized device (genuine device) comprising the eUlCC. The binding is performed by storing, in the eUlCC and the authorized device, at least a cryptographic key permitting to authenticate the authorized device by the eUlCC. The method further comprises authenticating, upon an occurrence of an event, the device by the eUlCC by performing a cryptographic operation and, if the authentication fails, determining that the device comprising the elllCC is not the authorized device and, if the authentication is successful, determining that the device comprising the elllCC is the authorized device.

[0011] According to some example embodiments, the at least cryptographic key is a secret key shared between the eUlCC and the authorized device.

[0012] According to some example embodiments, the at least cryptographic key is a plurality of PSK keys shared between the eUlCC and the authorized device.

[0013] According to some example embodiments, the event is a boot of the eUlCC.

[0014] According to some example embodiments, if the authentication fails, the elllCC does not answer to the device’s requests.

[0015] BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The invention will be better understood by reading the following description of a preferred embodiment of the invention in regard of the figures that represent:

[0017] Figure 1 a binding procedure between an eUlCC, and an authorized device based on PK;

[0018] Figure 2 a binding procedure between an eUlCC, and an authorized device based on a pre-shared secret key;

[0019] Figure 3 a system comprising an authorized device and an eUlCC in which plurality of keys are stored securely;

[0020] Figure 4 an authentication procedure of a device by an eUlCC according to the invention;

[0021] Figure 5 a method for authentication a device comprising an elllCC.

[0022] DETAILED DESCRIPTION

[0023] Figure 1 represents a binding procedure between an elllCC 102 and an authorized (genuine) device 104 based on PK. An elllCC is a type of SIM (Subscriber Identity Module) designed to provide flexibility and enhanced functionality for mobile devices, loT devices, and other connected hardware.

[0024] In this figure, a device 102 has to be paired with an elllCC 104 (interchangeably referred to as “eSIM”). An eSIM is a digital SIM technology integrated directly into devices like smartphones, tablets, wearables, loT devices ... Unlike traditional SIM cards that require physical insertion and replacement, an eSIM is embedded in the device’s hardware and can be programmed or updated remotely, enabling flexibility, convenience, and efficiency.

[0025] This binding or pairing is performed in a factory in order to be later on able to detect that the eUlCC 104 has not been desoldered from the authorized device 102 and soldered in another device.

[0026] Before performing this binding procedure, a plurality of one-time PK / SK (Private Key / Secret Key) is stored in the device 102 and another plurality of one-time PK / SK is stored in the eUlCC 104.

[0027] At step 106, pairing (binding) is performed by sending by the authorized device 102 to the eUlCC 104 a unique device identifier, for example but not limited to, Device Chip ID, IM El, MAC Address, Device SN or SE ID, along with its public key and a binding start command. The eUlCC 104 then generates at step 108 two keys:

[0028] - An AUTH.AES.KENC key;

[0029] - An AUTH.AES.KMAC key.

[0030] KENC stands for Encryption key and KMAC for Message Authentication Code key. In other words, the AUTH.AES.KENC key is used for encrypting data, while the AUTH.AES.KMAC key is used for generating and verifying message authentication codes.

[0031] These keys are computed using the received device PK, the eUlCC secret key, and the received unique device identifier.

[0032] At step 110, the eUlCC 104 returns to the authorized device 102 the binding result (binding performed). This reply can include binding successful ‘SW9000’. SW9000 indicates a status word (SW) returned by a smart card or a similar device to signify successful execution of a command. Specifically, the value 9000 represents a standard success code defined in the ISO / IEC 7816 standard for integrated circuit cards such as eUlCCs.

[0033] At step 112, the authorized device 102 generates the same keys KENC and KMAC from the authorized device’s 102 secret key SK, the elllCC public key PK and the unique device identifier sent at step 106.

[0034] Figure 2 represents a binding procedure between an elllCC 104 and an authorized device 102 based on a pre-shared secret key.

[0035] A secret key encryption algorithm relies on secret keying material shared between authorized parties to ensure secure communication. This type of cryptographic algorithm uses the same secret key for both an operation and its complement, such as encryption and decryption. The security of the system depends on the confidentiality of the shared key, which must be exchanged and maintained securely between the parties. Examples of secret key encryption algorithms include the Data Encryption Standard (DES), the Advanced Encryption Standard (AES), widely recognized for their robustness and efficiency in securing data in applications like secure communications and file storage.

[0036] Prior to the steps represented in this figure, a same secret key has been stored securely in the device 102 and in the elllCC 104, at factory stage.

[0037] At the first step 202, pairing (biding) initiates through sending by the authorized device 102 to the eUlCC 104 a unique device identifier, for example but not limited to, Device Chip ID, IM El , MAC Address, Device SN or SE ID, and a binding start command. The eUlCC 104 then generates at step 204 two keys:

[0038] - A KENC key;

[0039] - A KMAC key.

[0040] KENC stands as before for Encryption key and KMAC for Message Authentication Code key.

[0041] These secrets are computed by using the received unique device identifier of the device 102 and the pre-shared secret key. At step 206, the elllCC 104 returns to the authorized device 102 the biding result (binding performed). This reply is binding successful (SW- 9000’).

[0042] At step 208, the authorized device 102 generates the same keys KENC and KMAC from the preshared secret key SK and the unique device identifier sent at step 202. After executing steps 112 and 208, the elllCC 104 and the authorized device 102 are bounded (paired).

[0043] Figure 3 represents a system comprising an authorized device 102 and an elllCC 104 in which plurality of keys are stored securely. This corresponds to the pairing performed as shown in figures 1 and 2.

[0044] The device 102 comprises a binding service 302 and a Device_OS 316. The Device_OS 316 manages the entire device, including hardware resources, user interface, and application execution. Further, the Device_OS 316 ensures security through features like app sandboxing and encryption. Also, the Device_OS 316 facilitates network communication (Wi-Fi, cellular, etc.) in conjunction with lower-level firmware and protocols.

[0045] The binding service 302 comprises securely stored a PK / SK (Public key I Secret key) 304 generated by an ECKA (Elliptic Curve cryptography Key Agreement) algorithm or a pre-shared key 308 as generated at step 112 of figure 1. It also comprises a unique device ID 306.

[0046] Elliptic Curve Cryptography Key Agreement (ECKA) is a cryptographic method enabling secure key exchange between parties. It allows two parties to establish a shared secret key over an insecure channel without directly transmitting the key. ECKA is highly efficient, offering strong security with smaller key sizes compared to traditional methods like Diffie-Hellman, thereby reducing computational overhead and resource consumption. Alternatively, alternate key agreement functions such as RSA-based key exchange, Diffie-Hellman Key Exchange, and PostQuantum Cryptographic Algorithms allowing them to resist emerging quantum computing threats can be used. Each method varies in efficiency, computational requirements, and resistance to specific attack vectors.

[0047] On other side, the eUlCC 104 comprises a binding applet 314 and an eSIM_OS 320. Further, the eSIM_OS 320 is dedicated to manage the secure storage and operation of subscriber information and network profiles on the eSIM hardware. Also, the eSIM_OS 320 stores multiple carrier profiles securely, ensures secure authentication with mobile networks (based on cryptographic keys and algorithms) and enables switching between carrier profiles without physically replacing the SIM.

[0048] The binding applet 314 comprises securely stored an eSIM PK / SK 304 also generated by a ECKA (eSIM standing for eUICC) or stores a pre-shared key 308 and the unique device ID 306 received at steps 106 or 202 of figures 1 and 2.

[0049] The device 102 and the elllCC 104 communicate through applicative binding (Application Protocol Data Unit (ADPU) commands 312 and are able to generate keys AUTH.AES.KENC and AUTH.AES.KMAC 310. The binding APDU 312 process is the backbone of secure and structured communication between mobile devices and embedded smart card technology, enabling critical functions like eSIM profile management, authentication, and secure data handling.

[0050] Figure 4 represents an authentication method of a device 102 by an eUlCC 104 according to the invention.

[0051] The process starts after the occurrence of an event. This event is for example a boot of the eUlCC 104 (power on). The event can also start later but in any case, it has to be early enough to avoid an abusive use of the eUlCC 104 by a non-authorized device.

[0052] After this event, the eUlCC 104 starts at step 402 the authentication procedure of the device 102. To this end, the eUlCC 104 sends a randomly generated challenge and MAC result computed by the key KMAC (based on challenge and the device identifier previously received as shown in figures 1 and 2).

[0053] At step 404, the eUlCC 104 sends to the device 102 a verification request command (for example a GET INPUT command). The verification request command can include the challenge generated at step 402 and the MAC.

[0054] At step 406, the device 102 verifies the received MAC result and the device calculates MAC result with the received challenge and device identifier. If it does not match, the device will generate an error. Else, the device encrypts the received challenge with KENC and device identifier, and computes a response. This response comprising the eUlCC generated challenge is transmitted at step 408 to the eUlCC 104 (for example in a TERMINAL RESPONSE command). The elllCC 104 then verifies at step 410 that the elllCC challenge is the same as the one sent at step 404 and deciphers the received message with the KENC key.

[0055] If the elllCC has recognized the authorized device 102, it considers that everything is ok and it can exchange further messages with the device 102.

[0056] On the contrary, if this check at step 410 fails, the eUlCC 104 will consider that the device comprising the eLJICC 104 is not the authorized one with which it has been paired according to figures 1 or 2 and the eUlCC 104 has probably been unsoldered from the authorized device 102 and soldered in another device.

[0057] The eUlCC 104 can then have different behaviours:

[0058] - not answering to further device’s requests;

[0059] - block some normal telecom operations like network authentication;

[0060] - after a given number N of authentication failures, entering in a reversible blocked state.

[0061] The reversible blocked state allows to make post-mortem analyses (in factory).

[0062] FIG. 5 illustrates a flow diagram of a method 500 for authentication a device 102 comprising an eUlCC 104, in accordance with an example embodiment. It will be understood that each block of the flow diagram of the method 500 may be implemented by various means, such as hardware, firmware, processor, circuitry, and / or other communication devices associated with execution of software including one or more computer program instructions.

[0063] Further, blocks of the flow diagram support combinations of means for performing the specified functions and combinations of operations for performing the specified functions for performing the specified functions. It will also be understood that one or more blocks of the flow diagram, and combinations of blocks in the flow diagram, may be implemented by special purpose hardwarebased computer systems which perform the specified functions, or combinations of special purpose hardware and computer instructions.

[0064] At step 502, the method comprises binding in a factory is the performed between the eUlCC 104 and the authorized device 102 comprising the elllCC 104. The binding is performed by storing, in the eUlCC 104 and the authorized device 102, at least a cryptographic key permitting to authenticate the authorized device 102 by the eUlCC 104. In accordance with an embodiment, the cryptographic key is a secret key shared between the eUlCC 104 and the authorized device 102. In accordance with another example the cryptographic key is a plurality of PSK keys shared between the eUlCC 104 and the authorized device 102.

[0065] At step 504, upon an occurrence of an event, the device 102 is authenticated by the eUlCC 104 by performing a cryptographic operation and determining whether the device 102 comprising the eUlCC 104 is the authorized device. In accordance with an example, the event is a boot of the eUlCC 104. Further, if the authentication fails 504a, it is determined that the device 102 comprising the eUlCC 104 is not the authorized device 102. If the authentication is successful 504b, it is determined that the device 102 comprising the eUlCC 104 is the authorized device 102. In accordance with an example, if the authentication fails, the eUlCC 104 does not answer to requests of the device 102. In accordance with another example, if the authentication fails more than a predefined number of N times, the eUlCC 104 enters in a reversible blocked state.

Claims

CLAIMS1. A method (500) for authentication a device (102) comprising an eUlCC (104), said method (500) comprising: binding (502) in a factory said eUlCC (104) with an authorized device (102) comprising said eUlCC (104), wherein binding is performed by storing, in said eUlCC (104) and said authorized device (102), at least a cryptographic key permitting to authenticate said authorized device (102) by said eUlCC (104); authenticating (504), upon an occurrence of an event, said device (102) by said ell ICC (104) by performing a cryptographic operation and: o if said authentication fails, determining that the device (102) comprising said eUlCC (104) is not said authorized device (102); o if said authentication is successful, determining that the device (102) comprising said eUlCC (104) is said authorized device (102).

2. The method (500) according to claim 1 , wherein said at least cryptographic key is a secret key shared between said eUlCC (104) and said authorized device (102).

3. The method (500) according to claim 1 , wherein said at least cryptographic key is a plurality of PSK keys shared between said eUlCC (104) and said authorized device (102).

4. The method (500) according to any of the claims 1 to 3, wherein said event is a boot of said eUlCC (104).

5. The method (500) according to any of the claims 1 to 4, wherein if said authentication fails, said eUlCC (104) does not answer to said device (102)’s requests.

6. The method (500) according to any of the claims 1 to 5, wherein if said authentication fails more than a predefined number of times, said eUlCC (104) enters in a reversible blocked state.

Images