Method for authenticating device comprising eUICC
By storing password keys in eUICC and real devices and performing password operations for device authentication, the problem of eUICC desoldering and welding from real devices is solved, and the reuse of eUICC is prevented and fraud is reduced.
Patent Information
- Application Number
- CN202311785296.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-12-22
- Publication Date
- 2025-06-24
AI Technical Summary
The prior art is difficult to detect whether eUICC is desoldered from a real device and welded in another device, resulting in fraud.
By storing the password key that allows eUICC to authenticate the device in eUICC and real devices, and performing a password operation when an event occurs to authenticate the device, if authentication fails, the device is considered not a real device.
Effectively prevent the reuse of eUICC, ensure that eUICC is only authenticated with the real devices it binds to, and reduce the occurrence of fraud.
Smart Images
Figure CN120201432A_ABST
Abstract
Description
Technical Field
[0001] The field of the present invention is telecommunications and more particularly relates to a method for preventing the reuse of an eUICC (Embedded UICC, where UICC is Universal Integrated Circuit Card) embedded (soldered) in a terminal, such as for example a smart meter, a smart watch, or any IoT device. Background Art
[0002] It has been found that fraudsters are able to unsolder the eUICC from the device in which it is soldered. For example, this may easily occur when a fraudster purchases a smart watch and unsolders the eUICC embedded in the watch at home. The fraudster can then solder the eUICC in another device, such as for example a smartphone, and make scam calls.
[0003] Some solutions have been proposed, but these solutions only relate to removable UICC (Sim cards) and are based on the identification of the IMEI which is easy to clone.
[0004] Therefore, there is no solution for detecting that the eUICC has been unsoldered from a genuine device and soldered in another device. Summary of the Invention
[0005] The proposed invention provides a solution to this problem.
[0006] More particularly, the present invention provides a method according to claims 1 to 6.
[0007] A method for authenticating a device including an eUICC, the method comprising:
[0008] - Binding the eUICC to the genuine device including the eUICC at the factory by storing at least one cryptographic key in the eUICC and the genuine device that allows the eUICC to authenticate the genuine device;
[0009] - At the occurrence of an event, authenticating the device by the eUICC by performing a cryptographic operation, and moreover:
[0010] о If the authentication fails, the device including the eUICC is considered not to be the genuine device,
[0011] о If the authentication succeeds, the device including the eUICC is considered to be the genuine device.
[0012] The method according to claim 1, wherein the at least one cryptographic key is a secret key shared between the eUICC and the genuine device.
[0013] The method according to claim 1, wherein the at least one cryptographic key is a pair of PSK keys shared between the eUICC and the genuine device.
[0014] The method according to any one of claims 1 to 3, wherein the event is the activation of the eUICC.
[0015] The method according to any one of claims 1 to 4, wherein if the authentication fails, the eUICC does not respond to the request of the device.
[0016] The method according to any one of claims 1 to 5, wherein if the authentication fails more than N times, the eUICC enters a reversible blocking state. Description of the Drawings
[0017] The present invention will be better understood by reading the following description of the preferred embodiments of the present invention with reference to the accompanying drawings, which show:
[0018] Figure 1 is a binding process between the eUICC and the genuine device based on PKI;
[0019] Figure 2 is a binding process between the eUICC and the genuine device based on a pre-shared secret key;
[0020] Figure 3 is a system including a genuine device and an eUICC, in which multiple pairs of keys are securely stored;
[0021] Figure 4 is an authentication process of the device by the eUICC according to the present invention. Detailed Description of the Invention
[0022] Figure 1 represents a binding process between the eUICC and the genuine device based on PKI.
[0023] In this figure, device 10 must be paired with eUICC 11 (denoted as eSIM). This binding or pairing is performed in the factory so that it can be detected later that eUICC 11 has not been desoldered from the genuine device 10 and soldered in another device.
[0024] Before performing this binding process, a pair of one-time PK / SK (private key / secret key) is stored in device 10, and another pair of one-time PK / SK is stored in eUICC 11.
[0025] The first step 20 of pairing (binding) consists in the genuine device 10 sending a unique device identifier, such as a device chip ID, IMEI, MAC address, device SN or SE ID, as well as its public key and a binding start command, to the eUICC 11. Then, in step 21, the eUICC 11 generates two keys:
[0026] - AUTH.AES.KENC key;
[0027] - AUTH.AES.KMAC key.
[0028] KENC stands for the encryption key, and KMAC stands for the message authentication code key.
[0029] These keys are calculated by using the received device PK, the eUICC secret key, and the received unique device identifier.
[0030] In step 22, the eUICC 11 returns the binding result (the binding has been performed) to the genuine device 10. This reply is '9000' for successful binding.
[0031] In step 23, the genuine device 10 generates the same keys KENC and KMAC from the secret key SK of the genuine device 10 sent in step 20, the eUICC public key PK, and the unique device identifier.
[0032] Figure 2 Represents the binding process between the eUICC 11 and the genuine device 10 based on a pre-shared secret key.
[0033] The secret key encryption algorithm secret key material is shared between the authorizing parties. The cryptographic algorithm uses the same secret key for an operation and its complement (e.g., encryption and decryption).
[0034] Before the steps represented in this figure, in the factory phase, the same secret key has been securely stored in the device 10 and the eUICC 11.
[0035] The first step 30 of pairing (binding) consists in the genuine device 10 sending a unique device identifier, such as a device chip ID, IMEI, MAC address, device SN or SE ID, as well as a binding start command, to the eUICC 11. Then, in step 31, the eUICC 11 generates two keys:
[0036] - KENC key;
[0037] - KMAC key.
[0038] KENC represents the encryption key as before, and KMAC represents the message authentication code key.
[0039] These secrets are calculated by using the received unique device identifier of device 10 and a pre-shared secret key.
[0040] In step 32, the eUICC 11 returns the binding result (binding is performed) to the genuine device 10. This response is a binding success (SW = '9000').
[0041] In step 33, the genuine device 10 generates the same keys KENC and KMAC from the pre-shared secret key SK and the unique device identifier sent in step 30. After steps 23 and 33, the eUICC 11 and the genuine device 10 are bound (paired).
[0042] Figure 3 Represents a system including the genuine device 10 and the eUICC 11, in which multiple pairs of keys are securely stored. This corresponds to the pairing performed as shown in Figure 1 and Figure 2 and
[0043] Device 10 includes a binding service 40 and an OS 41.
[0044] The binding service 40 includes a PK / SK (public key / secret key) 60 securely stored and generated by the ECKA (Elliptic Curve Cryptography Key Agreement) algorithm 42, or the pre-shared key 43 generated in step 23 of Figure 1 This binding service also includes a unique device ID 47.
[0045] The eUICC 11 includes a binding applet 44 and an OS 48 on its side.
[0046] The binding applet 44 includes an eSIM PK / SK 60 also securely stored and generated by ECKA (eSIM on behalf of eUICC), or the pre-shared key 43 and the unique device ID 47 received in steps 20 or 30 of Figure 1 and Figure 2 This binding applet also includes a unique device ID 47.
[0047] Device 10 and the eUICC 11 communicate through the applicable binding ADPU command 49 and are able to generate the keys AUTH.AES.KENC and AUTH.AES.KMAC 46.
[0048] Figure 4 Represents an authentication method of device 10 by the eUICC 11 according to the present invention.
[0049] This process starts after an event. The event is, for example, the start (power-on) of the eUICC 11. The event can also start later, but in any case, it must be early enough to avoid abuse of the eUICC 11 by non-genuine devices.
[0050] After this event, the eUICC 11 starts the authentication process of the device 10 at step 50. For this purpose, the eUICC 11 sends a randomly generated challenge and a MAC result calculated by the key KMAC (based on the challenge and the previously received device identifier as shown in Figure 1 and Figure 2 .
[0051] At step 51, the eUICC 11 sends a verification request command (e.g., GET INPUT command) to the device 10, which includes the MAC and the challenge generated at step 50.
[0052] At step 52, the device 10 verifies the received MAC result, and the device will calculate the MAC result using the received challenge and the device identifier stored in the device. If the results do not match, the device will throw an error. Otherwise, the device encrypts the received challenge with KENC and the device identifier and calculates a response. At step 53, this response including the challenge generated by the eUICC is transmitted to the eUICC 11 (e.g., in the TERMINAL RESPONSE command).
[0053] Then, the eUICC 11 verifies at step 54 that the eUICC challenge is the same as the challenge sent at step 51, and decrypts the received message with the KENC key.
[0054] If the eUICC has identified the genuine device 10, it considers everything normal and it can exchange further messages with the device 10.
[0055] Conversely, if this verification 54 fails, the eUICC 11 will consider that the device including the eUICC 11 is not the genuine device that has been paired according to Figure 1 or Figure 2 : The eUICC has likely been desoldered from the genuine device and soldered into another device.
[0056] The eUICC 11 can then have different behaviors:
[0057] - Do not answer requests from other devices;
[0058] - Block some normal telecommunication operations, such as network authentication;
[0059] - After a given number N of authentication failures, enter a reversible blocking state.
[0060] The reversible blocking state allows for post-mortem analysis (in the factory).
Claims
1. A method for authenticating a device (10) including an eUICC (11), the method comprising: - Binding the eUICC (11) to the genuine device (10) including the eUICC (11) at the factory by storing at least one cryptographic key in the eUICC (11) and the genuine device (10) that allows the eUICC (11) to authenticate the genuine device (10); - At the occurrence of an event, authenticating the device (10) by the eUICC (11) by performing a cryptographic operation, and: о If the authentication fails, the device (10) including the eUICC (11) is considered not to be the genuine device (10), о If the authentication succeeds, the device (10) including the eUICC (11) is considered to be the genuine device (10).
2. The method according to claim 1, wherein, The at least one cryptographic key is a secret key shared between the eUICC (11) and the genuine device (10).
3. The method according to claim 1, wherein, The at least one cryptographic key is a pair of PSK keys shared between the eUICC (11) and the genuine device (10).
4. The method according to any one of claims 1 to 3, wherein The event is the startup of the eUICC (11).
5. The method according to any one of claims 1 to 4, wherein If the authentication fails, the eUICC (11) does not answer the request of the device (10).
6. The method according to any one of claims 1 to 5, wherein If the authentication fails more than N times, the eUICC (11) enters a reversible blocking state.