AUTHORISATION OF LOADING AN APPLICATION INTO A SECURITY ELEMENT

Description

1. Scope of the invention

[0001] The invention relates to a security element. It applies in particular to a security element capable of downloading applications onto a communications network. 2. Prior Art

[0002] Data transfer between a remote machine and a security element, such as a smart card, is most often secured by cryptographic mechanisms. These mechanisms, whether symmetric or asymmetric, guarantee the confidentiality and integrity of the exchanged data, thus creating a secure communication channel between the remote machine and the security element.

[0003] The establishment of a secure communication channel, which also allows the sender of the data to be identified, is considered sufficient proof of trust between the two parties; therefore, the recipient does not control the nature of the data before accepting its receipt.

[0004] As a result, the sender is able to use the secure communication channel to send data, including applications, which may be improper.

[0005] In a domain other than the technical domain of the application, document CN107944261A1 (GUANGDONG et al.) discloses an application control method and user equipment. The application control method comprises the following steps: the user equipment detects a user-initiated download instruction for a target application and determines a tag for the target application based on the download instruction; this tag is then used to determine the category to which the target application belongs. The user equipment acquires a control level for the target application based on the application's category, judges whether the control level of the target application is equal to or greater than a target control level, and, if so, prevents the download of the target application. Applications intended for download can thus be effectively controlled. 3. Description of the invention

[0006] The invention improves upon the existing state of the art.

[0007] To this end, it proposes a method for authorizing the loading of an application into a security element according to claim 1.

[0008] Advantageously, according to the invention, an application is loaded into the security element only if verification information has validated it. Since the verification information depends on the type of application to be loaded, even a reliable provider cannot load an unwanted application into the security element.

[0009] The term "application" here refers to a set of data (active, such as computer code, or passive, such as data of any kind, including cryptographic keys) intended for subsequent use on the security element. The application is associated with a "type," which corresponds, for example, to a category of applications (telecommunications, identity, digital rights, connected objects, payment, etc.). The application can take the form of a computer program and associated data; the computer program may include operating system components.

[0010] The term "security element" refers to any hardware and / or software element that ensures data security in accordance with the rules and security requirements set by a trusted authority, for example, a smart card, a SIM card (for Subscriber Identity Module) or any of their evolutions: eSIM (embedded SIM), UICC (for Universal Integrated Circuit Card), eUICC (for embedded UICC) or an SSP-type architecture (for Smart Secure Platform) currently being defined at ETSI. For example, one can refer to the document "SIM evolution" by Mr. Klaus Vedder (20TH SIGOS CONFERENCE FOR TELCO & DIGITAL EXPERIENCE - 9-11 July 2018 | Nuremberg) for a presentation of this architecture. As another example, the security element architecture can be of the TEE type (for Trusted Execution Environnement), that is to say a secure area (memory) isolated from other execution environments, located in a device (such as a mobile phone), ensuring that sensitive data is stored, processed and protected in a trusted environment.

[0011] An "application provider" is an entity that makes one or more applications available for the security element, such as a mobile network operator (MNO), a government representative providing identity applications, a bank providing payment applications, etc. The application provider is uniquely identified by an identifier such as a URI (for Universal Resource Identifier), a string of characters, a sequence of numbers, etc.

[0012] According to the invention, a method as described above is further characterized in that the security element is accessible to at least one user identified by a user ID, the type of application authorized is relative to said user, and the method includes a step of obtaining said user ID.

[0013] This implementation of the invention allows for the control of application loading for a given user when the security element is associated with one or more users who have rights over that element, specifically the right to use the resources of that security element for a given application or service. These users are assigned a user identifier, such as a name, number, string, URI, etc. Since the type of authorized application is specific to a particular user, this ensures that each user can securely load their own applications.

[0014] According to a particular embodiment of the invention, a method as described above is further characterized in that it includes a step of obtaining an identifier of the supplier of the application to be loaded and in that the verification information is calculated based on said supplier identifier.

[0015] This implementation of the invention notably strengthens load validation by introducing a provider identifier into the validation data calculation, thereby excluding unauthorized providers. Advantageously, if the validation information is generated by combining the provider identifier and the type of authorized application, it will be possible to refuse to load an application whose type is not authorized for a given provider, and potentially for a given user.

[0016] According to a particular embodiment of the invention, a process such as the one described above is characterized in that it further comprises: a step of comparing the identifier of the application provider to be loaded and the identifier of the user; depending on the results of the comparison, a step of refusing to load the application.

[0017] This implementation method of the invention strengthens verification security by comparing the provider's identifier with that of the security element's user. For example, if both entities are of type "bank," the application will be accepted, but if one of the entities is not a bank, the application will be refused.

[0018] According to another particular embodiment of the invention, the authorization process is further characterized in that an identifier of said user and at least one type of application authorized for said user are recorded in the form of a certificate in a memory of the security element.

[0019] Advantageously, in this method, an electronic certificate can be used to transmit data to the security element. Such a certificate, used to identify and authenticate a person, but also to encrypt communications, can conform to a standard well-known to those skilled in the art (such as the X.509 standard).

[0020] The invention also relates to a device for authorizing the loading of an application into a security element according to claim 5.

[0021] The term "module" can refer to a software component, a hardware component, or a set of hardware and software components. A software component itself corresponds to one or more computer programs or subprograms, or more generally, to any element of a program capable of implementing a function or set of functions as described for the modules in question. Similarly, a hardware component corresponds to any element of a hardware assembly capable of implementing a function or set of functions for the module in question (integrated circuit, smart card, memory card, etc.).

[0022] The invention also relates to an electronic card comprising such an authorization device.

[0023] The invention also relates to a secure memory area comprising such an authorization device.

[0024] The invention also relates to a computer program comprising instructions for implementing the above method according to any of the particular embodiments described above, when said program is executed by a processor. The method can be implemented in various ways, including in hardwired or software form. This program can use any programming language and be in the form of source code, object code, or code intermediate between source and object code, such as in a partially compiled form, or in any other desirable form.

[0025] The computer program can be stored on a computer-readable storage medium or information carrier containing instructions for a computer program as described above. The aforementioned storage media can be any entity or device capable of storing the program. For example, the medium may include a storage means, such as a ROM (e.g., a CD-ROM or a microelectronic circuit ROM), or a magnetic recording means, such as a hard drive. Alternatively, the storage media may be a transmissible medium such as an electrical or optical signal, which can be transmitted via an electrical or optical cable, by radio, or by other means. Programs according to the invention can, in particular, be downloaded from a network such as the Internet.

[0026] Alternatively, the recording media may correspond to an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the process in question.

[0027] This authorization device and computer program have features and advantages similar to those described previously in relation to the authorization process. The optional features mentioned for the process can be applied to the device and the program. 4. List of figures

[0028] Other features and advantages of the invention will become clearer upon reading the following description of particular embodiments, given by way of simple illustrative and non-limiting examples, and the accompanying drawings, among which: [ Fig 1 ] There figure 1 illustrates an example of an implementation environment for the invention according to a particular embodiment of the invention, [ Fig 2 ] There figure 2 illustrates the steps in the process of authorizing the loading of an application according to a particular embodiment of the invention, [ Fig 3 ] There figure 3 illustrates a device configured to implement the loading authorization process according to a particular embodiment of the invention. Fig 4 ] There figure 4 illustrates a device configured to implement the loading authorization process according to another particular embodiment of the invention. 5. Description of an embodiment of the invention 5.1 General principle of the invention

[0029] The process described here proposes a method for verifying the nature of the data constituting an application within a security element (SE) before accepting its receipt. Each user of the security element must first be registered with an identifier, along with a list of the application types for which that user authorizes downloads, in the SE's memory. Before the download, the application type is verified by the security element. Advantageously, a sender / provider is therefore no longer able to use the communication channel, even a secure one, to send improper data. 5.2 Specific embodiments of the invention.

[0030] There figure 1 illustrates an example of an implementation environment of the invention according to a particular embodiment, in the context of downloading an application (APP) from a remote machine, or application server for security element (SAES), to a security element (ES).

[0031] According to this embodiment, the security element (ES) has at least one user with an identifier denoted ES_uid. This user defines the type(s) of application(s) that it authorizes to be downloaded onto the ES. There can be multiple users of the same ES, as shown in the figure 1 where the ES has two users A and B (ES_uid_A and ES_uid_B). The security element can be integrated, for example, into a device such as a smartphone. It can be hardware, software, or a combination of both.

[0032] The application server communicates with the Security Element (SE) to download an application (APP) through the C communication channel.

[0033] According to a particular embodiment of the invention, the communication channel C is secured, for example by the use of cryptographic keys.

[0034] The application to be downloaded (APP) is associated with a provider and has a type; APP_id denotes the identifier of the application provider and APP_t the type of the application. APP_t can be used by one or more providers.

[0035] APP_tid denotes the identifier representing the type of application APP_t offered by the provider APP_id; for example, if APP is the loyalty application of merchant xyz, APP_id (id=xyz) is the identifier of this merchant, APP_t corresponds to the "loyalty applications" type, and APP_tid_A is the "loyalty applications" type of merchant xyz for customer A

[0036] According to a particular embodiment of the invention, the APP_tid value is composed by combining the value of APP_id and APP_t.

[0037] According to a particular embodiment of the invention: the application APP is an electronic identity application; an application type APP_t is a type of identity application (passport, driver's license, etc.); a provider is a state or a representative of a state (ANSSI in France or the BSI in Germany) represented in the ES by an ES_uid; several states can agree to use the same APP_t values, independent of the provider's APP_id (a Franco-German citizen can hold a passport from each country). Implementing the invention in this context ensures that only the French state can download French identity applications and cannot download identity applications from any other state.

[0038] There figure 2 illustrates the steps in the process of loading an application according to a particular embodiment of the invention

[0039] Step E0 corresponds to an initialization step. It can be performed at any time (card initialization, subsequent user customization, etc.). For each ES user, the following information is stored in the ES memory: A unique identifier ES_uid of the user. In one particular embodiment, the value of ES_uid is equal to the value of APP_id; The list of APP_tids, that is, the list of application types for which the user is authorized to download.

[0040] According to a particular embodiment, this information is stored in an electronic certificate (Cert), containing, for example, the following information: The certificate issuer identifier (for example: urn:xyz.com). This identifier then acts as the ES_uid. The list of APP_tids, that is, the list of application types for which the ES user is authorized to download for a given provider.

[0041] During a stage E1, the server and the security element, SAES and ES establishing a communication channel C.

[0042] According to a particular embodiment of the invention, this communication channel is secured by the use of public-key electronic certificates, as previously described.

[0043] During a stage E10, The SAES server sends on communication channel C the provider identifier (APP_id) and the application type (APP_t) of an APP application to be downloaded, received during a step E2.

[0044] During a stage E3Optionally, the ES security element verifies that the application provider is authorized. In one embodiment, it compares the received APP_id value to the recorded ES_uid values: If the APP_id value does not match any registered ES_uid value, ES responds to SAES that APP_id is not associated with any registered user for that ES; ES does not allow the APP download. This prevents an application provider from misusing the security element. For example, if the ES_uid is lambda (e.g., telco for a telecommunications operator) but the App_id is associated with a bank, this step fails because the lambda user (the telco) is unable to load a banking application. If the APP_id value matches a registered ES_uid value, the process continues.

[0045] According to a particular embodiment of the invention presented earlier, in which the communication channel is secured by the use of public key electronic certificates, the issuer identifier of the certificate (ES_uid) is extracted from the certificate.

[0046] Then during a stage E4, The ES security element obtains validation information, denoted APP'_tid, from the application type APP_t, or according to a preferred embodiment, by combining the information sent by the SAES server, APP_id and APP_t.

[0047] According to a particular embodiment of the invention, APP_tid is calculated according to the method described in the IETF RFC 4122 specification: "A Universally Unique IDentifier (UUID) URN Namespace"; such an identifier is also known as "UUID version 5", where NID (Namespace Identifier) ​​is equal to APP_id and NSS (Namespace Specific String) is equal to APP_t.

[0048] According to another particular embodiment of the invention, this processing can be entrusted to an external entity by the security element.

[0049] During a stage E5, The ES security element compares the APP'_tid value calculated or obtained in the previous step to the APP_tid values ​​recorded for the user ES_uid; if the APP'_tid value does not match any APP_tid value recorded for the user ES_uid, ES responds to the SAES server that the application type is not authorized by the user; ES does not accept the download of the APP application.

[0050] During a stage E6 If the value of APP'_tid matches a registered APP_tid value for the user ES_uid, ES tells SAES that the APP download is allowed.

[0051] According to a particular embodiment of the invention presented earlier, in which the communication channel is secured by the use of public key electronic certificates, this step consists of comparing the value of APP'_tid calculated in step E4 with the values ​​of APP_tid extracted from the certificate used for the establishment of the communication channel, i.e. the list of types of applications for which the download is authorized by the user of the ES.

[0052] During a stage E11, The SAES server downloads the APP application onto the ES security element, which receives it during an E7 step.

[0053] There figure 3 illustrates a DISP device configured to implement the loading process according to a particular embodiment of the invention.

[0054] The DISP device has the classic architecture of a security element, and includes, in particular, a memory module (MEM), a processing unit (TU), equipped, for example, with a processor (PROC), and controlled by the computer program (PG) stored in the MEM. The computer program (PG) includes instructions to implement the steps of the loading process as described above, when the program is executed by the processor (PROC).

[0055] At initialization, the code instructions of the computer program PG are, for example, loaded into memory before being executed by the PROC processor. The PROC processor of the processing unit UT implements, in particular, the steps of the loading authorization process according to any one of the specific embodiments described in relation to the figure 2 , according to the instructions of the PG computer program.

[0056] The DISP device includes a COM communication module configured to establish communication with a network, for example IP, for downloading the APP application. The APP application is loaded into a portion of the M memory.

[0057] According to a particular embodiment, such a device is a SIM card.

[0058] According to a particular embodiment, such a device is a TEE (for Trusted Execution Environment) as mentioned above.

[0059] According to another particular embodiment, represented in the figure 4 , Such a device is a secure platform of the iSSP type. (pour integrated Smart Secure Platform) as defined in particular in the ETSI standard currently under development, reference TS 103 666-2, entitled: "Smart Secure Platform (SSP); Integrated SSP (iSSP) characteristics" ».This evolution of secure elements responds to new functional and security requirements of the security element (SE) enabling, among other things, multi-application management, optimization of software and hardware architectures, reduction of integration costs and increased secure storage capacities, etc.

[0060] The hardware and software architecture of an iSSP, as represented in the figure 4 is divided into three parts: a primary platform (Primary Platform - PP) consisting of the hardware itself (processors, memory, etc.) as well as a low-level operating system (LLOS) and basic services (SB), for example communication; secondary platforms (Secondary Platform Bundles - SPB) consisting of a high-level operating system (HLOS) and a family of applications designated A1, A2, etc. (for example: related to the USIM, user identity, etc.); and a loading module (Secondary Platform Bundle Loader -SPBL), a particular SPB allowing the management of other SPBs (loading, activation, etc.). In this context, the invention applies to the mechanism for downloading applications of the "Secondary Platform Bundle" (SPB) type: the process of authorizing the loading of an application, as described above, is implemented by the hardware and software elements of the iSSP in such a way that a family or set of applications (SPB) can be loaded into the memory of the iSSP by the loader (SPBL) after verification of its type, and possibly its provider, for a given user.

[0061] In one embodiment, the iSSP contains a certificate from a certification authority (for example, the GSMA, an international association of mobile network operators) that includes the types of application families (SPBs) authorized to be downloaded; for example, Telecom SPBs, Payment SPBs, Identity SPBs, etc. It should be noted that several authorities (GSMA, bank, nation-state, etc.), several users, and several application families can coexist within the iSSP.

[0062] It goes without saying that the embodiment described above has been given purely as an indication and is in no way limiting, and that many modifications can easily be made by a person skilled in the art without going out of the scope of the invention.

Claims

1. Method implemented by a security element able to communicate with an application loading server (SAES), said security element being accessible to a user identified via a user identifier (ES-uid), said user identifier being recorded in a memory of said security element and said method comprising: - said user registering the types of applications that are authorized to be loaded in relation to said user identifier, in association with the security element; - authorizing loading (E6) of an application onto said security element, for said user of said security element, only if at least one of the authorized types of application (APP_tid) registered by and for said user of said security element matches a type of said application to be loaded (APP_t).

2. Method according to Claim 1, wherein said method comprises obtaining (E2) an identifier of a provider (APP_id) of the application to be loaded, and said authorization takes into account said identifier of the provider (APP_id).

3. Method according to Claim 2, wherein said method furthermore comprises: - declining (E3) to load the application on the basis of said identifier of the provider (APP_id) of the application to be loaded and of said user identifier (ES_uid).

4. Method according to either of Claims 2 and 3, wherein said user identifier (ES_uid) and at least one type of application authorized for said user identifier (APP_tid) are recorded in the form of a certificate (Cert) in said memory of the security element.

5. Device for authorizing loading of an application (APP, SPB) into a security element (ES, iSSP) able to communicate with a loading server (SAES) of an application provider, said security element being accessible to a user identified via a user identifier (ES-uid), said user identifier being recorded in a memory of said security element, the device comprising at least one processor designed to allow: - said user to register the types of applications that are authorized to be downloaded in relation to said user identifier, in association with the security element; - loading (E6) of an application onto said security element to be authorized, for said user of said security element, only if at least one of the authorized types of application (APP_tid)) registered by and for said user of said security element matches a type of said application to be loaded (APP_t).

6. Device according to Claim 5, wherein said processor is designed to obtain (E2) an identifier of a provider (APP_id) of the application to be loaded and wherein said authorization takes into account said identifier of the provider (APP_id).

7. Device according to Claim 6, said processor being designed to decline (E3) to load the application on the basis of said identifier of the provider (APP_id) of the application to be loaded and of said user identifier (ES_uid).

8. Device according to Claim 7, wherein said user identifier (ES_uid) and at least one type of application authorized for said user identifier (APP_tid) are recorded in the form of a certificate (Cert) in said memory of the security element.

9. Electronic card (SIM, iSSP) comprising an authorization device according to any of Claims 5 to 8.

10. Secure memory area (TEE) comprising an authorization device according to any of Claims 5 to 8.

11. Computer program comprising instructions for implementing the method according to any one of Claims 1 to 4 when the program is executed by a processor.