Method for diversifying a general application stored in a security processor of a terminal safely

Abstract

The present invention proposes a method for diversifying a general application (11) stored in a secure processor (10) of a terminal in a secure manner, the method comprising: - generating a server challenge (SERVER.CHALLENGE) at a remote server (13) at the request of a manager application (12) to be hosted in an application processor of the terminal; - sending the server challenge to the application (11); - generating a first message (MSG1) at the application (11), the first message (MSG1) being based on the server challenge, an application challenge, and a unique identifier (APP.ID) of the application (11); - sending the first message (MSG1) to a trusted root service (112) hosted in the secure processor (10) of the terminal, the trusted root service (112) generating a proof of the first message, the proof guaranteeing that the first message (MSG1) has not been modified and originates from the secure processor (10); - transmitting the proof of the first message (MSG1) to the remote server (13) in an enabling request message; - at the remote server (13): verifying that the proof of the first message (MSG1) is provided by the trusted root service (112); verifying that the first message (MSG1) contains the server challenge; returning an enabling payload to the application (11), the enabling payload comprising a second message (MSG2) and a public key certificate having a public key that will be used to verify the signature of the second message, the second message comprising the application challenge; - at the application (11), upon receiving the enabling payload: verifying the public key certificate; verifying the signature of the second message; verifying that the second message (MSG2) contains the application challenge.

Description

[0001] The present invention relates to telecommunications and, in particular, to the remote and secure enabling of a general (undiversified) application (e.g., an integrated UICC, also known as an iUICC, or an eUICC for an embedded UICC) loaded in and running on a security processor (SP) part of a system-on-chip (SoC) of a networked device (i.e., a device capable of accessing a network). The device (or terminal) is, for example, a smartphone, a PDA, an IoT device that can connect to a cellular network (2G, 3G, 4G, or 5G). Thus, the application can be an application that allows the secure element to connect to an MNO (Mobile Network Operator) network with all the required credentials.

[0002] Consider a SoC that includes a main application processor (AP) and a security processor (SP). The AP and the SP are isolated from each other and communicate with each other only using specific hardware and security protocols. This isolation provides a higher level of security for sensitive applications loaded in and running on the SP. Applications loaded in the SP are known as SP applications.

[0003] In this configuration, the SP application (hereinafter SP.APP) needs to be deployed on multiple devices / SPs, i.e., the SP.APP is initially loaded in a general, undiversified form. That is, initially the same software and data (not containing any diversified identifiers or credentials) are loaded on all devices / SPs.

[0004] The problem to be solved is to securely diversify the identifiers and credentials of such a general (undiversified) form of SP.APP loaded on a specific device / SP so that subsequent communication with each diversified SP.APP instance can be carried out in a secure manner.

[0005] A typical example is to securely diversify the iUICC in the SP on a mobile phone / device.

[0006] The environment required by the present invention is further refined as follows:

[0007] - The AP can run advanced applications and provide access to advanced services such as network access for them. In particular, the SoC includes a modem that allows the AP to access the network. On the other hand, the SP application running on the SP cannot directly access the network.

[0008] - The SP provides a trusted root (ROT) service to the SP application, i.e., a signature service that can generate an encrypted proof for any message (provided by the SP.APP), and such a proof guarantees that the message has not been modified and originated from a specific SP / device.

[0009] - The SP also provides an ID service for SP applications. The ID service can be used to retrieve the SP.ID, which is the unique identifier bound to the SP (i.e., the unique identifier of the SP itself or some data that can only be provided by this SP and not by any other SP), or to allow the generation of such identifiers (bound to the SP) or some data for a universally unique identifier (i.e., independent of the SP). Even if not universally unique, the SP.ID can be or can allow the generation of an identifier that is unique within the scope of SPs produced by a given SP manufacturer. The ID service is described separately for clarity, but it can actually be embodied through the ROT service (e.g., the SP.ID can be retrieved from the proof generated by the ROT service).

[0010] - The SP application has been loaded onto the SP in a secure manner, that is, the loading operation has been authorized, and the integrity and origin of the SP application are guaranteed, and the SP application (SP.APP) is genuine and authorized software.

[0011] The present invention proposes a method for securely diversifying a general application stored in a secure processor of a terminal. The method includes:

[0012] - Generating a server challenge at the level of a distant server in response to a request from a manager application hosted in an application processor of the terminal;

[0013] - Sending the server challenge to the application;

[0014] - Generating a first message at the application based on the server challenge, an application challenge, and the unique identifier of the application;

[0015] - Sending the first message to a trusted root service hosted in the secure processor of the terminal, and the trusted root service generates a proof of the first message, which guarantees that the first message has not been modified and originates from the secure processor;

[0016] - Transmitting the proof of the first message to the remote server in an enable request message;

[0017] - At the remote server:

[0018] o Verifying that the proof of the first message is provided by the trusted root service;

[0019] o Verifying that the first message contains the server challenge;

[0020] o Returning an enable payload to the application, which contains a second message and a public key certificate having a public key that will be used to verify the signature of the second message, and the second message includes the application challenge;

[0021] - At the application, upon receiving an enabling payload:

[0022] o Verify the public key certificate;

[0023] o Verify the signature of the second message;

[0024] o Verify that the second message contains an application challenge.

[0025] Preferably, the enabling payload further comprises additional and suitably diversified data from a remote server.

[0026] Advantageously, the application is an application of an iUICC.

[0027] In a preferred embodiment, the first message further comprises the public key of the application, and the second message further comprises the certificate of the application.

[0028] The present invention includes the following elements as shown in Figure 1 , 2A and 2B, Figure 1 , 2A and 2B illustrate different steps of a method according to the present invention:

[0029] - A security processor SP 10 provided by a chip manufacturer;

[0030] - A general (undiversified) application SP.APP 11 stored in the SP 10;

[0031] - A manager application (MGR 12) running on an application processor AP, capable of:

[0032] - Communicating with the SP.APP 11,

[0033] - Relaying messages between the SP.APP 11 and a remote enabling service / network server (RES 13);

[0034] - A server RES 13, which is a remote server.

[0035] The SP 10, SP.APP 11, and MGR 12 are part of a terminal / device. It is assumed that the RES 13 is owned and managed by the vendor of the SP.APP 11.

[0036] The method according to the present invention includes different steps, which will be explained hereinafter, and which use PKI (Public Key Infrastructure) to securely transmit messages and provide integrity.

[0037] As a preparatory step, as shown in Figure 1As shown, SP.APP must generate a unique identifier APP.ID. To do this, SP.APP 11 first needs to obtain the unique identifier of the SP (step 100), which is done by sending a request to the ID service 101 managed by the SP 10. The ID service returns SP.ID, which is used by SP.APP 11 in step 102 to generate its own unique identifier APP.ID.

[0038] Step 102 can be implemented in various ways to ensure the uniqueness of APP.ID. For example, if SP.ID is already a unique identifier, then APP.ID can simply be equal to SP.ID. However, this is usually not the case for the following reasons:

[0039] - For application reasons, APP.ID may need to use a specific format / encoding.

[0040] - If SP.ID is only unique within the context of a specific SP manufacturer, then APP.ID can also include the identifier of the SP manufacturer (hereinafter referred to as SP.MK.ID) to make it unique, regardless of the SP manufacturer. If not retrieved from the SP 10 in some way, this SP.MK.ID can be provided by SP.APP 11 itself. However, note that the present invention does not exclude use cases where such an SP.MK.ID is not required, for example, if the SP.ID provided by the ID service 101 will already be universally unique, or if the application solution will generally be bound and restricted to a specific SP manufacturer.

[0041] Then SP.APP waits for the server challenge that will later be generated by RES 13 (step 103).

[0042] Steps 100 to 103 can be executed when SP.APP 11 is started for the first time.

[0043] After or simultaneously with steps 100 to 103, MGR 12 can request the server challenge from RES 13, which corresponds to Figure 2A step 104 shown. In step 105, RES 13 generates a random challenge SERVER.CHALLENGE and returns it to MGR 12. In step 106, MGR 13 simply forwards SERVER.CHALLENGE to SP.APP 11. In step 107, the previously waiting SP.APP 11 receives SERVER.CHALLENGE and can now proceed to step 108, where SP.APP 11 generates a random challenge APP.CHALLENGE. In step 110, SP.APP 11 then generates message MSG1, which includes the following information:

[0044] - SERVER.CHALLENGE;

[0045] - APP.CHALLENGE;

[0046] - APP.ID;

[0047] - Optionally, MSG1.DATA: application-related data that RES 13 can use to generate the enabling payload;

[0048] - Optionally, supplementary information (e.g., SP.MK.ID), which RES 13 can use to enforce the enabling acceptance policy.

[0049] In step 111, SP.APP 11 then obtains a proof for MSG1 by sending a request to the Trusted Root (ROT) service 112 managed by SP 10, as Figure 2B shown.

[0050] The ROT service 112 generates and returns a proof that includes MSG1 and guarantees that MSG1 has not been modified and originates from SP 10.

[0051] In step 113, SP.APP 11 simply forwards the proof to MGR 12. In step 114, MGR 12 packages the proof into an enabling request and sends it to RES 13. The enabling request may include SP.MK.ID if RES 13 requires it to detect the format of the proof (specific to SP 10).

[0052] After receiving the enabling request, RES 13 then:

[0053] - At step 115, verifies that the proof was generated by the ROT service 112 and extracts MSG1 from the proof.

[0054] o Assume that RES 13 knows the public key required to verify the proof (e.g., pre-transmitted by the SP 10 manufacturer);

[0055] o Optionally, RES 13 enforces the enabling acceptance policy based on supplementary information present in MSG1;

[0056] - At step 116, verifies that MSG1 (extracted from the proof) contains the SERVER.CHALLENGE previously generated in step 105;

[0057] - At step 117, prepares the message MSG2 to be returned to SP.APP 11, which includes the following information:

[0058] o APP.CHALLENGE (extracted from MSG1);

[0059] o Optionally, MSG2.DATA: application-related data, possibly related to MSG1.DATA

[0060] - At step 118, generate an enabling payload including MSG2, ensuring that MSG2 is unmodified and originated from RES13. The enabling payload includes the following information:

[0061] o The public key certificate (CERT.RES) having the public key (PK.RES), where the public key (PK.RES) will be used to verify MSG2.SIG (see below);

[0062] o MSG2;

[0063] o MSG2.SIG: the signature of MSG2 generated using SK.RES (the paired private key of PK.RES).

[0064] RES 13 returns the enabling payload, which is forwarded by MGR 12 to SP.APP 11 at step 119.

[0065] After receiving the enabling payload, SP.APP 11 then:

[0066] - At step 120, verify that the enabling payload was generated by RES 13. To do so, SP.APP 11:

[0067] o Verify the certificate CERT.RES present in the enabling payload. Assume that SP.APP 11 knows the public key required to verify CERT.RES (which is included in the general, non-diversified form of SP.APP 11);

[0068] o Extract the public key PK.RES from CERT.RES;

[0069] o Use the public key PK.RES to verify the signature MSG2.SIG;

[0070] - At step 121, verify that MSG2 contains the APP.CHALLENGE previously generated at step 108.

[0071] Finally, at step 122, it is considered that the enabling payload has been successfully verified, and SP.APP 11 can further use or store MSG2.DATA required to complete its initialization.

[0072] After step 122, SP.APP 11 has a unique identity APP.ID, has notified RES 13 of its existence and identity (APP.ID), and may have received additional data (MSG2.DATA) from RES 13, which is appropriately diversified or may be used by SP.APP 11 to ultimately complete the diversification of its internal data.

[0073] In a first variant of the invention, the content and purpose of MSG1.DATA and MSG2.DATA are further described as follows:

[0074] - SP.APP 11 generates a public key pair, including a public key (PK.APP) and a private key (SK.APP). It is assumed here that SP.APP11 is capable of performing public key encryption operations. SP.APP 11 then includes the following information in MSG1.DATA:

[0075] o PK.APP

[0076] - If RES 13 accepts the enablement request message 117, it includes the following information in MSG2.DATA:

[0077] o CERT.APP (which owns PK.APP previously extracted from MSG1.DATA) signed by RES using SK.APP.PROVIDER (the paired private key of PK.APP.PROVIDER). This certificate is bound to APP.ID (i.e., APP.ID appears in this certificate).

[0078] o CERT.APP.PROVIDER, which owns the public key (PK.APP.PROVIDER) that will be used to verify CERT.APP. It is assumed that this certificate was previously signed by an independent agency (ROOT.APP) related to this application solution.

[0079] o Optionally: Supplementary application-related information related to SP.APP 11.

[0080] CERT.APP.PROVIDER and CERT.RES are independent. CERT.RES is used to secure the enablement program, while CERT.APP.PROVIDER belongs to the certificate chain of SP.APP 11 for authenticating itself to other parties in the application solution.

[0081] After successfully verifying the enablement payload, SP.APP 11 can store CERT.APP.PROVIDER, CERT.APP, and any provided supplementary information extracted from MSG2.DATA as needed.

[0082] At the end of the enabling procedure (according to this first variant), SP.APP 11 also has a public key pair (PK.APP, SK.APP) certified by ROOT.APP (i.e., the relevant authority for the application solution), and can perform the following operations:

[0083] - Transmit its identity to other parties in the application solution.

[0084] - Use SK.APP, CERT.APP (bound to APP.ID) and CERT.APP.PROVIDER to provide its identity to other parties in the application solution and / or sign messages sent to them. That is, SP.APP 11 can sign messages with SK.APP, and other parties can use the certificate chain (CERT.APP.PROVIDER ← CERT.APP) to verify such signatures.

[0085] Therefore, in this first variant, SP.APP 11 also generates a (public / private) key pair. The public key and APP.ID are both included in MSG1, and then RES 13 generates a certificate for the public key and sends it back to SP.APP 11 in MSG2.

[0086] In a second variant of the present invention, which is based on the first variant, there are and may be several ROOT.APPs involved in the application solution. In this case, SP.APP 11 can generate several public key pairs (PK.APP, SK.APP), and each public key pair can be certified by a different ROOT.APP. In this case, MSG1.DATA will include several PK.APPs, and for each PK.APP, it will include the identifier (ROOT.ID) of the ROOT.APP that will certify it. In this case, MSG2.DATA will include several certificate chains (CERT.APP.PROVIDER ← CERT.APP), one certificate chain for each PK.APP, assuming that RES 13 also has the CERT.APP.PROVIDER for each ROOT.APP indicated in MSG1.DATA.

[0087] At the end of the enabling procedure (according to this second variant), SP.APP 11 will then be able to communicate securely with other parties in the application solution using any of its public key pairs (PK.APP, SK.APP) and the relevant certificate chains.

[0088] Therefore, in this second variant, SP.APP generates multiple key pairs instead of just one.

[0089] In a third variant of the invention based on the first or second variant, the certificate chain from CERT.APP to ROOT.APP may include more than two certificates (i.e., not just CERT.APP.PROVIDER ← CERT.APP), and in this case, each certificate chain present in MSG2.DATA will include a variable number of certificates (i.e., CERT.ROOT.APP ← … ← CERT.APP.PROVIDER ← CERT.APP).

[0090] Thus, in this third variant, RES 13 returns a certificate chain of variable length (greater than or equal to 2, not just 2 certificates: CERT.APP.PROVIDER and CERT.APP) for each public key (i.e., the case of a multi-level hierarchy).

[0091] In a fourth variant of the invention, MSG2.DATA includes appropriate information for suggesting or forcing a different APP.ID for SP.APP. This means that RES 13 returns an alternative APP.ID that SP.APP 11 should store and use instead of the one generated in step 102.

[0092] The present invention provides a solution for the diversification of integrated UICC (iUICC) in SP on mobile phones.

[0093] Traditional diversification procedures (such as those for UICC or eUICC) typically involve a database and a key management system (KMS) that store secrets and scripts to be loaded onto the produced cards.

[0094] The iUICC cannot be personalized in the same way at the production site because it has to be loaded into SP, which is itself in the SoC, which is itself in a terminal assembled in an OEM factory. Therefore, the present invention proposes a solution for remotely personalizing / diversifying the iUICC.

[0095] The advantage of the present invention is that (in the case where the iUICC application is SP.APP 11), the iUICC generates its own secrets and credentials, so RES 13 does not have to store any secrets regarding multiple iUICC instances. Only a request is made to RES 13 to prove the (one or more) public keys of the iUICC.

[0096] The iUICC (SP.APP) generates its own identity (APP.ID) based on SP.ID. Even if at the very beginning (before enabling) the iUICC (SP.APP 11) cannot prove its identity, this still provides an opportunity for early identification.

[0097] The present invention not only provides a solution for the diversification of the iUICC in the SP 10 on a mobile phone, but also this solution can be extended to any kind of SP.APP and any kind of IoT device including the SP 10. To some extent, it can also be applied to the diversification of the eUICC or the chip.

Claims

1. A method for securely diversifying a general application (11) stored in a secure processor (10) of a terminal, the method comprising: - generating a server challenge at a remote server (13) in response to a request from a manager application (12) hosted in an application processor of the terminal; - sending the server challenge to the application (11); - generating, at the application (11), a first message that includes the server challenge, an application challenge, and a unique identifier of the application (11); - sending the first message to a trusted root service (112) hosted in the secure processor (10) of the terminal, the trusted root service (112) generating a proof of the first message that guarantees that the first message has not been modified and originated from the secure processor (10); - transmitting the proof of the first message in an enable request message to the remote server (13); - at the remote server (13): o verifying that the proof of the first message is provided by the trusted root service (112); o verifying that the first message contains the server challenge; o returning an enable payload to the application (11), the enable payload including a second message and a public key certificate having a public key that will be used to verify a signature of the second message, the second message including the application challenge; - at the application (11), upon receiving the enable payload: o verifying the public key certificate; o verifying the signature of the second message; o verifying that the second message contains the application challenge.

2. The method according to claim 1, wherein The enable payload further includes additional and properly diversified data from the remote server (13).

3. The method according to claim 1 or 2, wherein The application (11) is an iUICC application.

4. The method according to claim 1 or 2, wherein the first message further includes a public key of the application, and wherein the second message further includes a certificate of the application.

5. The method according to claim 3, wherein the first message further includes a public key of the application, and wherein the second message further includes a certificate of the application.

Images