Secure element and method for launching an application

Abstract

The present description relates to a secure element and a method for launching an application. A method of launching a first application, the first application being configured to be implemented by at least one low-level operating system of a secure element, the method comprising verifying at least a first piece of information updated after each reset operation of the secure element, the first piece of information being associated with the at least one low-level operating system.

Description

[0001] Cross-references to related applications

[0002] This application claims the benefit of French patent application No. 2100996, filed on February 2, 2021, which is incorporated herein by reference. Technical Field

[0003] This disclosure generally relates to electronic devices, and more specifically to electronic devices suitable for processing confidential data. More specifically, this disclosure relates to electronic devices implementing various applications, and in particular to methods for launching applications using such electronic devices. Background Technology

[0004] A secure element is an electronic device, whether autonomous or not, designed to handle confidential data securely, without requiring access to or inference of this confidential data through means such as side-channel attacks or infiltration. For example, a secure element can be configured to encrypt data.

[0005] A security element can be adapted to implement one or more applications in a secure manner.

[0006] It is hoped that certain aspects of safety elements can be improved, at least in part, and more specifically, certain aspects of one or more applications can be implemented through safety elements. Summary of the Invention

[0007] It needs to be configured as a security element to implement multiple applications.

[0008] It needs to be configured to implement a secure element for multiple applications, ensuring that the execution of these applications remains secure even after the secure element is restarted or reset.

[0009] One embodiment overcomes all or some of the disadvantages of known safety elements.

[0010] One embodiment provides a security element configured to securely implement multiple applications even after the security element has been restarted or reset.

[0011] One embodiment provides a method for launching a first application configured to be implemented by at least one low-level operating system of a secure element, including verifying at least one first piece of information updated after each reset operation of the secure element, the first piece of information being associated with at least one low-level operating system.

[0012] Another embodiment provides a security element configured to implement at least one low-level operating system, the at least one low-level operating system implementing at least one first application, wherein, at each startup of the first application, a first piece of information updated after each reset operation of the security element is verified, the first piece of information being associated with at least one low-level operating system.

[0013] According to one embodiment, the verification of the first piece of information is performed by comparing it with a second piece of information associated with a first application.

[0014] According to one embodiment, the comparison between the first message and the second message is performed by at least one low-level operating system.

[0015] According to one embodiment, the comparison between the first piece of information and the second piece of information is performed by a first application.

[0016] According to one embodiment, if the verification fails, at least one second piece of information is updated.

[0017] According to one embodiment, at least one piece of second information is updated by making at least one piece of second information equal to the first piece of information.

[0018] According to one embodiment, after updating at least one second piece of information, at least one low-level operating system notifies the first application that a reset operation has occurred.

[0019] According to one embodiment, after being notified, and taking into account the fact that a reset operation has already occurred, the first application implements the protocol.

[0020] According to one embodiment, each time the first application is launched, at least one third piece of information associated with at least one low-level operating system and updated after each reset operation of the security element is verified.

[0021] According to one embodiment, at least one first piece of information is associated with a first type of reset operation, and a third piece of information is associated with a second type of reset operation.

[0022] According to one embodiment, the first type of reset operation is a cold reset operation when the power supply to the safety element is interrupted.

[0023] According to one embodiment, the second type of reset operation is a warm reset operation when the power supply to the safety element is not interrupted.

[0024] According to one embodiment, the safety element is embedded in the electronic device.

[0025] According to one embodiment, the safety element is integrated into the electronic device.

[0026] According to one embodiment, the security element is configured to implement at least one second application.

[0027] Another embodiment provides an application configured to be implemented by at least one low-level operating system of the previously described security element. Attached Figure Description

[0028] The above-described features and advantages, as well as others, will be described in detail in the following description of specific embodiments given by way of illustration rather than limitation with reference to the accompanying drawings, in which:

[0029] Figure 1 Examples of electronic devices of the type to which the described embodiments are applicable are schematically shown in block form;

[0030] Figure 2 Another example of an electronic device of the type to which the described embodiments are applicable is schematically shown in block form;

[0031] Figure 3 The diagram is schematically shown in block form regarding Figure 1 and Figure 2 Examples of software architectures for the security elements of those types of electronic devices described;

[0032] Figure 4 The illustration is shown schematically in block form, based on the information provided. Figure 1 and Figure 2 Flowcharts describing the different states of applications implemented by the security elements of those types of electronic devices;

[0033] Figure 5 The illustration is shown schematically in block form, demonstrating how the explanation can be derived from... Figure 1 and Figure 2 Flowcharts describing the different types of reboots or resets implemented by those types of electronic devices;

[0034] Figure 6 The illustration is shown schematically in block form, using information about... Figure 1 and Figure 2 Flowcharts describing the implementation patterns of methods for launching applications on those types of electronic devices; and

[0035] Figure 7 The illustration is shown schematically in block form, using information about... Figure 1 and Figure 2 A flowchart illustrating the implementation patterns of methods for launching applications on those types of electronic devices. Detailed Implementation

[0036] In different figures, the same features are designated by the same reference numerals. Specifically, common structural and / or functional features in various embodiments may have the same reference numerals and may have the same structure, dimensions, and material properties.

[0037] For clarity, only the steps and elements useful for understanding the embodiments described herein are described in detail.

[0038] Unless otherwise stated, when two elements are referenced together, it means there is no direct connection of any intermediate element other than a conductor, while when two elements are referenced together, it means that the two elements can be connected, or they can be coupled through one or more other elements.

[0039] In the following disclosure, unless otherwise stated, when referring to absolute position qualifiers such as the terms “front,” “back,” “up,” “down,” “left,” “right,” etc., or relative position qualifiers such as the terms “above,” “below,” “upper,” “lower,” etc., or orientation qualifiers such as “horizontal,” “vertical,” etc., refer to the orientation shown in the figure.

[0040] Unless otherwise stated, the terms “approximately,” “estimated,” “basically,” and “in order” indicate less than 10%, preferably less than 5%.

[0041] Figure 1 An example of an electronic device 100 (SOC) of the type to which the described embodiments are applied is illustrated schematically in block form.

[0042] Device 100 is an electronic device formed on a single chip (System-on-a-Chip - SOC). Device 100 includes a security element 110 (SE), which in this example is integrated (iSE integrated security element). Security element 110 is a security element integrated within device 100, meaning it can operate autonomously within device 100. According to an alternative embodiment, security element 110 can be embedded, meaning it can operate using certain hardware resources of device 100, such as memory, circuitry implementing specific functions, etc. Figure 2 A more detailed example of the embedded security element 110 is described below.

[0043] The secure element 110 is an electronic circuit that manipulates, for example, encrypted secret data. The secure element 110 includes: at least one processor 111 (SE CPU) adapted to process the secret data; memory management circuitry 112 (MMF); and / or a memory management unit (MMU). Figure 1(Not shown in the diagram) capable of managing reading data from and writing data to memory; one or more circuits 113 (HW functions) adapted to implement the hardware functions of the secure element 110 (e.g., cryptographic accelerator, communication unit, etc.); at least one volatile memory 114 (SE RAM); at least one non-volatile memory 115 (SE NVM); communication circuit 116 (COMM) adapted to manage the transmission of data and control signals between the secure element 110 and the rest of the device 100; and communication bus 117 (SE bus) coupled to all elements of the secure element 110.

[0044] As a variant, the integrated secure element 110 is connected to one or more additional communication buses. For example, the integrated secure element may have a bus according to the ISO 7816 standard, connected to a modem of the system-on-chip, and another SWP-type (Single Wire Protocol) bus connected to a near field communication (NFC) device. This will be discussed below. Figure 2 This situation will be described in more detail.

[0045] Processor 111 is used to process control signals and data from memories 114 and 115, or from other memories included within device 100. Processor 111 uses memory management circuitry 112 as an intermediary to manage the memory storage of data and control signals; therefore, the processor never directly accesses memories 114 and 115. As an example, memory management circuitry 112 may be used, for instance, to allocate memory space of volatile or non-volatile memory to certain applications implemented by integrated security elements.

[0046] Circuit 113 may include various types of circuits and components, functions that can copy data to external memory, cryptographic coprocessors, etc.

[0047] The communication circuit 116 can be used as a data receiving and transmitting chain for the security element 110. The circuit 116 may include a data receiving circuit, a data encryption and / or decryption circuit, one or more routers, and a data conversion circuit.

[0048] Device 100 may include only the safety element 110, but may also optionally include one or more processors 121 (SOC CPU) adapted to process data; one or more circuits 122 (functions) adapted to implement different functions of device 100; one or more volatile memories 123 (SOC RAM); one or more non-volatile memories 124 (SOC NVM); and a communication bus 125 (SOC bus) capable of exchanging control signals and data and sending them to all the aforementioned elements.

[0049] For reasons of size and compactness, device 100 may be further adapted to store data in one or more external memories. More specifically, device 100 may be adapted to store data in external volatile memory 21 (EXT RAM) and / or external non-volatile memory 22 (EXT NVM). In this case, device 100 also includes interface circuitry adapted to communicate with these external memories 21 and 22. More specifically, in this case, device 100 may include interface circuitry 126 (RAM interface) adapted to communicate with external volatile memory 21, and / or interface circuitry 127 (NVM interface) adapted to communicate with non-volatile memory 22.

[0050] The secure element 110 can access the hardware resources of the device 100 to operate, such as the circuitry 122, the memories 123 and 124, or even the memories 21 and 22. As previously described, the secure element 110 can be integrated into or embedded in the device 100. When the secure element 110 is integrated, its non-volatile memory 115 has a very low storage capacity, for example, on the order of 1 to 2 kilobytes, its volatile memory 114 has a larger storage capacity, for example, greater than 8 megabytes, and the circuitry 113 is limited to the minimum necessary extent, or may not even be present in the secure element 110. For operation, when the secure element is integrated, it uses the non-volatile memory 124 of the device 100 or the external non-volatile memory 22, as well as the circuitry 122 of the device 100, to store data. Furthermore, when the security element 110 is embedded, its non-volatile memory 115 has a larger storage capacity, enabling it to store more data, for example, on the order of 4.5 megabytes, and circuitry 113 is present within the security element 110. Therefore, when installed, the security element 110 is autonomous in its operation. Figure 2 and Figure 3 Other differences between integrated security elements and embedded security elements are described.

[0051] Figure 2 Another example of an electronic circuit 100' of the type to which the described embodiment is applicable is schematically shown in block form.

[0052] Device 100' includes various electronic circuits or chips, including an embedded secure element (eSE) 150 forming a tamper-proof element (TRE); a main processor 161 (main CPU); a modem-type communication circuit 163 (modem); and a near field communication circuit 165 (NFC controller).

[0053] The embedded secure element 150 is formed from a single chip and integrates, for example, a secure element processor 151 (secure CPU); a hardware cryptographic processor 152 (HW cryptographic CPU) or cryptographic accelerator; one or more volatile memories 153 (RAM); one or more non-volatile memories 154 (NVM); and one or more buses 155 (buses) for communication between different components of the element 150.

[0054] Component 150 also integrates external communication interfaces according to various communication protocols, such as an I2C or SPI type interface 156 (I2C / SPI HW) for communicating with an external processor 161; an interface 157 (ISO7816) for communicating with a modem 163 according to the ISO7816 standard; and an SWP type interface 158 (SWP) for communicating with an NFC controller 165.

[0055] Device 100' may include other circuitry, whether integrated or not. For example, embedded security element 150 may use one or more external memories (…). Figure 2 (not shown in the image), it communicates with it directly or via the main processor.

[0056] With such as Figure 1 Unlike the integrated security element of component 110, the embedded security element 150 is not integrated with other components of device 100', and in particular not with the main processor of the application.

[0057] However, the embedded secure element 150 can be combined with the near field communication controller 165 (NFC).

[0058] Depending on the variant, the embedded security element 150 may include memory management elements, such as those related to... Figure 1 The memory management circuit 112 or memory management unit described herein is capable of preventing its security element processor 151 from directly accessing the memories 153 and 154.

[0059] Figure 3 The diagram is schematically shown in block form regarding Figure 1 and Figure 2 Examples of the architecture 200 of the safety element SE of those types of electronic devices described.

[0060] Unless otherwise stated, the term "safety element" in the following text refers inconsequentially to an embedded safety element or an integrated safety element. Therefore, the software architecture 200 of the safety element SE can be implemented in either element 110 or 150 of the preceding figures.

[0061] Architecture 200 includes a Virtual Main Platform 210 (VPP) or a main platform, enabling the implementation of different functions of the Security Element (SE). The main platform 210 consists of three layers: access to the electronic components 211 (HW, hardware) of the Security Element (SE); one or more low-level operating systems 213 (LLOS); and one or more software interfaces 215 (ABI, VRE, IPC).

[0062] Component 211 is a safety element SE (110, Figure 1 150, Figure 2 The hardware resources of the security element 110. Component 211 of the security element 110 is, for example, one or more processors, such as processor 111 ( Figure 1 ) or 151 ( Figure 2 ); one or more memories, such as memories 114 and 115 ( Figure 1 ) or 153 and 154 ( Figure 2 ( ); one or more communication devices, such as communication devices capable of direct communication with near field communication (NFC) devices; short-range communication devices using, for example, Bluetooth standards; biometric sensors; devices suitable for ultra-wideband (UWB) technology, etc.

[0063] The low-level operating system 213 is software suitable for implementing component 211 to execute control signals received from most applications implemented by the security element. As an example, the low-level operating system 213 includes all or part of the driver software for component 211.

[0064] A low-level operating system 213 consists of executable code and execution data. The executable code contains instructions that enable the program to perform its functions. By definition, for a given program, the instructions are invariant, except for updates to the program, which then modify the instructions. The executable code uses execution data to contextualize the execution and perform the required functions. Execution data can be distributed in two categories: "temporary" execution data and "permanent" or "fixed" execution data, as detailed below.

[0065] The main platform 210 communicates with the application implemented by the secure element 110 via a software interface 215 executed by the main platform. These interfaces 215 may include an application binary interface (ABI); registers (VRE, virtual registers); and a storage buffer or shared memory that allows data exchange between processes via inter-process communication (IPC); and so on.

[0066] The binary program interface is a low-level interface between an application program (implemented by a secure element, described below) and the low-level operating system 213, or between different parts of an application program. The binary program interface can link applications and components 211.

[0067] Registers are storage spaces linked to the hardware functions of the security element and are used to temporarily store data, such as when control signals are sent to the main platform 210 of the security element or during exchanges between processes executed by the main platform.

[0068] Buffer memory (or shared memory) is used to store messages before they are used by applications on platform 210 or the secure element. In practice, buffer memory is memory space allocated in the memory of element 110 or 100', such as volatile memory accessible to element 110, such as memory 114.

[0069] As an example, software architecture 200 includes at least three applications 231, 232, and 233 suitable for implementation by the main platform 210. Applications 231, 232, and 233 are software or computer programs that utilize the resources of the main platform. Of course, the security element implements many applications within the limitations of its computing and data storage capabilities.

[0070] Similar to the low-level operating system 213, each application 231, 232, 233 consists of executable code (or executable code) and execution data. The executable code contains instructions that enable the application to perform its functions. By definition, for a given program, the instructions are immutable, except for updates to the program, which then modify the instructions. The executable code uses execution data to contextualize execution and perform the required functions. As previously mentioned, execution data can be divided into two categories: execution data called "temporary" and execution data called "permanent" or "fixed." For example, if the function includes verifying a PIN code, the function is broken down into three parts: the executable code contains instructions for verifying the PIN code, the permanent execution data contains the reference PIN code and the number of remaining tests, and the temporary execution data contains the PIN code to be submitted for verification.

[0071] Integrated Safety Element 110 ( Figure 1 The embedded secure element 150 can execute a single application at a time in its internal memory, while storing other applications in external memory. This limits the number of applications to only the capacity of the external memory. Applications must be pre-loaded into internal memory before execution (or resumption of execution), and previous applications must be released before they can be used. In contrast, the embedded secure element 150... Figure 2 The embedded secure element will tend to use its internal memory to store and execute applications, meaning a more limited number of applications but faster execution speeds, as it will be referred to as "in-place" execution without requiring application replacement. However, it is still possible to combine embedded secure elements with external memory, thus combining the advantages of both internal and external memory.

[0072] Applications 231, 232, and 233 are suitable for implementing various functions. They typically implement digital services provided by service providers, such as payment services for EMV or transportation tickets. These applications can be integrated with the main processor 121 ( Figure 1 ) or 161 ( Figure 2 This refers to a combination of applications located within or in another secure environment (a trusted execution environment). The processor and secure environment are better able to interact with the user through a trusted user interface. Applications 231, 232, and 233 are, for example, suitable for processing control signals from a communication interface, such as banking transactions using a near-field communication device. Applications can be of different types, such as SIM (Subscriber Identity Module) applications, payment applications, applications capable of verifying public transportation tickets, etc.

[0073] Based on the example of the application type, application 231 (App1) is suitable to be implemented directly by the main platform 210 (VPP). Application 231 is, for example, an application capable of making payments by communicating with a near field communication (NFC) device.

[0074] According to another example of application type, application 232 is an instruction set 232A (App2) suitable for execution using an advanced operating system 232H (HLOS1). An advanced operating system is software suitable for implementing different applications by providing a set of common software functions. Operating system 232H is the sole component of application 232 that communicates with the main platform 210. Alternatively, the advanced operating system and all applications attached to it can be considered as a single application suitable for implementation by the main platform 210.

[0075] According to another example of application type, another application 233 is an instruction set 233A (App3) using an execution environment 233E (ENV), and the application 233 itself uses an advanced operating system 233H (HLOS2). For example, the execution environment is of the Java or JavaCard type. The operating system 233H and the execution environment 233E are the only parts of the application 233 that communicate with the main platform 210. As a variant, the advanced operating system and all applications attached to it can also be considered as applications suitable for implementation by the main platform 210.

[0076] The advanced operating systems 232H and 233H, or, if no advanced operating system is available, the applications 232 and 233 themselves, use a virtual image of memory that can be used to manage the execution code and execution data. Because of this technique, the advanced operating system (or application) cannot directly access the management of physical memory, whether it is volatile or non-volatile. In other words, in the described embodiments, the advanced operating system manages the virtual image of memory. The low-level operating system 213, in conjunction with certain components 211, such as... Figure 1 The described memory management circuit 112 ensures a match between the physical distribution of volatile and non-volatile memories. More generally, the host platform 210 is considered to implement a match between virtual and physical memory.

[0077] The implementation of applications 231, 232, or 233 is as follows. When an application wishes to use the hardware resources of the secure element, namely one or more components 211 of the host platform 210, this means that the current operation performed on fixed data is considered to have ended. The application can then execute different commands, such as forcing a write to non-volatile memory. For this purpose, the application sends control signals and / or data to the host platform 210 via interface 215. The control signals are handled by one or more binary program interfaces before being sent to the low-level operating system 213; that is, the command is broken down into multiple operations, each represented by a binary program interface, a virtual register, or a buffer / shared memory. Data is stored in registers or transferred via inter-process communication (IPC). The low-level operating system 213 responds to the application binary interface's request by applying the operation requested by the application binary interface to the data stored in the registers. The low-level operating system 213 then drives component 211 to execute what the application requested.

[0078] Applications 231, 232, and 233 may not communicate with each other within the secure element. Each application 23x (where x varies from 1 to the number of applications that may be executed) is unaware of the existence of other applications 23x. Specifically, each application's operating system "believes" it is the only one communicating with the outside world. Therefore, if applications must communicate together, they should communicate as if discussing something from the secure element executing application 23x to another element containing application 23x. However, two sub-applications of the same group of applications or two sub-applications of application 233 (an application may contain multiple sub-applications) communicate together using packet communication methods, employing inter-process communication (IPC) tools. Each application 231, 232, and 233 may communicate with external electronic devices. Packet communication is a data transmission method in which messages are formed by one or more data packets. Each data packet includes a header containing information about the type of communication protocol used, the message transmitter, the message receiver, the message size, etc. The secure element may use (and be compatible with) different known packet communication protocols, which can be categorized based on the nature of the protocol, the information exchange protocol, the application protocol, the communication protocol, and the physical link. For example, these protocols include:

[0079] - The VNP protocol (Virtual Network Protocol) is defined by the "Global Platform Technology Virtual Primary Platform-Network Protocol 1.0.1" standard (or any subsequent version), which corresponds to the protocol for exchanging information;

[0080] - The SWP protocol (Single-Wire Protocol) is defined by the ETSI TS 102 613 UICC - Contactless Front-End (CLF) Interface - Physical and Data Link Layer Characteristics Standard, corresponding to the physical link;

[0081] - Communication protocols defined by the ISO 7816 standard, including information exchange, application protocols, communication, and the nature of the physical link (wireless);

[0082] - The HCI (Host Controller Interface) protocol, defined by the ETSI TS 102 612 V12.0 standard (or any subsequent version), corresponds to the application protocol;

[0083] - The CLT protocol, defined by the ETSI TS 102 613 UICC - Contactless Front-End (CLF) Interface - Physical and Data Link Layer Features 11.0 standard (or any subsequent version), corresponds to the communication protocol;

[0084] The -sHDLC protocol (Simplified High-Level Data Link Control) is defined by the ETSI TS 102 613 (UICC - Contactless Front-End (CLF) Interface - Physical and Data Link Layer Characteristics) standard; and

[0085] - The ISO 7816 protocol, defined by the ISO / IEC 7816 standard; and

[0086] - I2C and SPI protocols corresponding to the physical link.

[0087] These messages can also be transmitted via a memory that acts as a communication bus. In other words, the communication bus can be replaced by a memory containing data written to it, which will be sent by the sending device and read by the receiving device.

[0088] The VNP protocol is a communication protocol suitable for use in secure elements. It is a protocol capable of managing message routing within architecture 200 and also capable of managing message routing to external devices. This is a preferred communication protocol in secure elements. According to an embodiment, the router included in component 211 (in combination with the low-level operating system 213) is configured to process messages using the VNP protocol.

[0089] HCI, sHDLC, and CLT protocols conflict with the VNP protocol because they are incompatible, and the standard does not define the interaction between them. This conflict results in HCI, sHDLC, and CLT protocols being unsuitable for managing message routing within architecture 200. Therefore, routers included in component 211 cannot support messages using sHDLC, CLT, and HCI protocols because the information needed for correctly routing messages within architecture 200 is unavailable.

[0090] CLT, sHDLC, and HCI protocols, as well as protocols defined by the ISO 7816 standard, are incompatible with the use of the VNP protocol. Routers included in component 211 (in combination with 213) cannot support messages using CLT, sHDLC, HCI, and ISO 7816 protocols.

[0091] Figure 4 The illustration is shown schematically in block form, based on the information provided. Figure 1 or Figure 2 The type of safety element SE described herein performs, regarding Figure 3 The flowchart describes the different states of application 301 (VPP App) of types 231, 232 and 233.

[0092] Application 301 includes two main states: deactivated state 302 (deactivated) and activated state 303 (activated).

[0093] When application 301 is in deactivated state 302 or is deactivated, it is not implemented by the secure element SE. According to an embodiment, application 301 is in a deactivated state when it has just been installed on the secure element SE and has never been implemented. According to another example, application 301 can be in a deactivated state when it decides to be set to a deactivated state, for example, when application 301 has just finished a task. More specifically, the executable code and fixed execution data of application 301 are stored in non-volatile memory. Then two cases arise. If the secure element is integrated into the electronic device, all or part of the executable code and execution data of application 301 are stored in non-volatile memory outside the secure element SE. According to an example, the executable code and execution data of application 301 are entirely stored in non-volatile memory outside the secure element SE, similar to the case regarding... Figure 1 The memory 124 is described. However, if the security element SE is embedded in the electronic device, the application's execution code and fixed execution data are stored in non-volatile memory included in the security element SE, similar to the combination of... Figure 1 The described non-volatile memory 115 or combination Figure 2 The non-volatile memory 154 is described.

[0094] When application 301 is in active state 303 or activated, it is being implemented by the security element SE. Then, application 301 includes two secondary states that it may be in, namely running state 304 (running) and hold on state 305 (suspended).

[0095] When application 301 is in running state 304 or is running, application 301 is implemented in the foreground by the security element SE. Figure 1 In the example, specifically in the example of a security element integrated into an electronic device, all or part of the executable code and fixed execution data of application 301 have been loaded into volatile memory for use, for example, regarding... Figure 1 The volatile memory 114 is described. In Figure 2 In the example, specifically in the example of a security element embedded in an electronic device, all or part of the execution code and fixed execution data of application 301 are obtained from information about... Figure 2The non-volatile memory 154 is described for execution. Then, the in-situ execution of the application is discussed. The verb "load" here refers to copying the execution code and fixed execution data from the non-volatile memory, and this copy is stored in volatile memory. Application 301 generates and uses temporary execution data at runtime, and this temporary execution data is also stored in volatile memory.

[0096] When application 301 is in a suspended state 305 or is in a suspended state, the execution of application 301 is temporarily suspended, for example, to allow the execution of another application of the secure element. All or part of the executable code of application 301, along with fixed execution data and temporary execution data, is loaded into an area assimilated with the volatile memory space managed by the main platform VPP. When the secure element SE is integrated into an electronic device, the area assimilated into the volatile memory space is the volatile memory of the secure element, for example, combined with... Figure 1 The described volatile memory 114. When a security element SE is embedded in an electronic device, the area assimilated into the volatile memory space is a combination of the volatile memory of the security element SE and a portion of the non-volatile memory of the security element SE. An example of the management of the area assimilated into the volatile memory space in the case of an embedded security element is further described in detail in French patent application reference FR1903168, published in reference FR3094526.

[0097] When application 301 is in a suspended state, it is not "aware" that it is in a suspended state. Application 301 is unaware that its implementation has been stopped by another event, such as the implementation of another application.

[0098] Figure 5 The explanation is illustrated schematically in block form. Figure 1 and Figure 2 The timing diagram of the different reset operations 401 (reset) of the type of safety element SE described in the document.

[0099] There are at least two reset operations for the safety element SE: cold reset operation 402 (cold reset); and hot reset operation 403 (hot reset).

[0100] During a cold reset operation or cold reset, the power supply to the Safety Element SE, or specifically the power supply to the electronic equipment comprising the Safety Element SE, is at least temporarily stopped. In the absence of power, the volatile memory of the Safety Element SE and the volatile memory of the electronic equipment comprising it are reset, and all data stored therein is erased. Therefore, the fixed execution data and temporary execution data of active applications—that is, the fixed execution data and temporary execution data of running or suspended applications—are erased. The non-volatile memory of the Safety Element and the non-volatile memory of the electronic equipment comprising it are not reset because non-volatile memory has the characteristic of retaining the data it stores even after the power supply to the non-volatile memory is stopped. Furthermore, applications that are active but suspended may not receive a cold reset command.

[0101] A warm reboot or warm reset is a reset performed in software or hardware, but does not involve cutting off the power supply. For example, the reset can be requested by a component, an application, or by an instruction from an external electronic device. A warm reset can cause a reset of the volatile memory of a safety element, as well as the volatile memory of the electronic device that includes it. However, a warm reset performed by software means that an active but suspended application may not receive a warm reset instruction.

[0102] Figure 6 It is shown that by about Figure 1 and Figure 2 The safety elements SE described are of type 110 and 150, and are activated regarding... Figure 3 The flowchart describes the implementation mode of the method steps for implementing application VPP Apps of types 231, 232, and 233. The security element SE includes components suitable for implementing application VPP Apps. Figure 3 The main platform described is a VPP of type 210.

[0103] The startup method or method for launching the execution of the VPP App described herein is adapted to take into account possible reset operations performed by the Security Element SE. In practice, according to one embodiment, considering possible reset operations, both the main platform VPP and the application implemented by the Security Element SE have at least one piece of information that is updated on each reset. According to one example, this information can be updated on each reset, whether it is a hot reset or a cold reset. According to a variation, this information can be updated on each specific type of reset, for example, only for hot resets and separately for cold resets.

[0104] According to one embodiment, the master platform (VPP) and the application implemented by the security element (SE) each have at least one piece of information for each cold reset update and at least one piece of information for each hot reset update. More specifically, the information is updated each time the master platform (the application implemented by the security element) becomes aware that a hot reset or cold reset operation has occurred. In practice, the master platform is always aware that a hot reset or cold reset operation has occurred. These information bars are, for example, binary data modified at each cold reset or hot reset operation. According to one embodiment, each information bar represents the date and time of the last cold reset or hot reset. According to another embodiment, the information bar is a random number generated at each cold reset or hot reset. According to another embodiment, the information bar is an incrementing number at each new cold reset or hot reset. In the following description, the following symbols are used:

[0105] -CR Num VPP, information about the primary platform VPP implemented during each cold reset;

[0106] -WR Num VPP, information about the primary platform VPP implemented during each hot reset;

[0107] -CR Num, information about the VPP App implemented during each cold reset; and

[0108] -WR Num, information about the application VPP App implemented during each hot reset.

[0109] Therefore, the method to launch the VPP App application is as follows.

[0110] In step 401 (Loading VPP App), the application VPP App requests to start. If the application VPP App was inactive before step 401, it begins loading all or part of its executable code and fixed execution data into the non-volatile memory of the Secure Element SE. If the application VPP App was suspended before step 401, it begins loading all or part of its executable code and fixed execution data into the non-volatile memory of the Secure Element SE.

[0111] Following step 401, in step 402 (checking CR Num and WR Num), the master platform VPP verifies that its information CR NumVPP and WR NumVPP are consistent with the information CR Num and WR Num of the application VPP App. This verification checks whether a cold reset or hot reset operation was performed without considering the application VPP App. In fact, when a cold or hot reset operation is in progress or implemented by the security element SE, the master platform VPP is always aware of it and updates its information CR NumVPP and WR NumVPP respectively. The application VPP App may not be aware that a cold or hot reset operation has occurred. If the information CR NumVPP and CR Num are consistent with WR NumVPP and WR Num respectively... Figure 6 If the output is the same as in step 403 (execute VPP App), then the next step is step 403. Otherwise ( Figure 6 (The outputs in the previous steps are different), the next step is step 404 (adjust CR Num, WR Num).

[0112] According to an alternative embodiment, an application in a pending state can verify its information CR Num and WR Num by comparing it with the main platform's information CR Num VPP and WR Num VPP at each reset.

[0113] In step 403, the data CR Num VPP and CR Num are consistent with WR Num VPP and WR Num, respectively, and the application VPP App has not "missed" the cold and hot reset operations. The application VPP App can then be executed.

[0114] In step 404, the information CR Num of the application VPP App (and information WR Num) is made equal to the information CR Num VPP of the main platform VPP (and information WR Num VPP). The main platform VPP updates the information CR Num and / or WR Num of the application VPP app.

[0115] Following step 404, in step 405 (notifying the VPP App), the main platform VPP notifies the application VPP App that a reset operation has occurred. Furthermore, the main platform VPP notifies the application VPP App whether this operation was a cold reset or a hot reset.

[0116] The application VPP (Virtual Platform Provider) may be unaware of multiple consecutive cold and / or hot reset operations. If at least one cold reset operation exists among the multiple reset operations, the master platform VPP indicates to the application VPP that a cold reset operation has occurred. Otherwise, the master platform VPP indicates to the application VPP that a hot reset operation has occurred. According to an alternative embodiment, during the implementation of multiple consecutive hot reset operations, the master platform VPP may indicate the number of hot reset operations performed on it before the application VPP executes.

[0117] Following step 405, in step 406 (VPP App Protocol), the application VPP App considers the information received from the main platform in step 405 and then executes a protocol specific to the type of reset operation that has occurred. Figure 7 An example of the protocol is described.

[0118] The advantage of this embodiment is that it ensures that the application does not "miss" any reset operations, and thus makes it possible to erase all or part of its temporary execution data.

[0119] Figure 7 The illustration is shown schematically in block form, illustrating the combination. Figure 6 The steps described are performed during step 406. Figure 6 A timing diagram of an example of the protocol of the VPP App application.

[0120] As a reminder, Figure 6 In step 406, the main platform VPP of the security element SE notifies the application VPP App that a reset operation has occurred on the element SE and / or the electronic equipment including it. Its information CR Num and WR Num have been updated to correspond to the information CR Num VPP and WR Num VPP of the main platform VPP.

[0121] Figure 7 An example of the protocol implemented by the VPP App is shown. Those skilled in the art will understand that various protocols can be envisioned. In particular, this protocol is chosen by the application's designer.

[0122] In step 501 (Reset Type?), the application VPP App processes the information it receives from the main platform VPP. Specifically, the application VPP App determines whether the reset operation that occurred was a cold reset or a hot reset. If the reset operation was a cold reset ( Figure 7 If the output is cold reset in the process, then the next step is step 502 (VPP App reset). If the reset operation is a hot reset operation ( Figure 7 If the output is hot-reset in the process, then the next step is step 503 (VPP App status?).

[0123] In step 502, the application VPP App becomes aware that a cold reset operation has occurred. As previously described, during a cold reset operation, the volatile memory of the Secure Element SE is erased. Furthermore, while the application VPP App is active, a portion of this execution data may be stored in non-volatile memory.

[0124] According to the example, after recognizing that a cold reset operation has occurred, the application VPP App verifies that all its temporary execution data has been effectively erased from the different memory locations of the Secure Element SE. According to a variant, the application VPP App recovers the data that was not erased.

[0125] In step 503, the application VPP App becomes aware that a hot reset operation has occurred. As mentioned earlier, during a hot reset operation, information requesting a software reset has been circulated. However, if the application VPP App is suspended, it may have missed this information. Therefore, when the application is running (in...) during a hot reset operation... Figure 7 If the application is suspended during a hot reset, the next step is step 504 (partial or full reset). If the application is suspended during a hot reset, the next step is step 505 (ignore (or do not) reset). It should be noted that if the application VPP App is inactive during a hot or cold reset, the operation may have no effect on its operation because its execution code or execution data has not been loaded into the volatile memory of the Secure Element SE.

[0126] In step 504, the application VPP App runs during the hot reset operation. The application VPP App may perform a full or partial reset. According to one embodiment, the application may erase all of its temporary execution data. According to another example, the application may retain general temporary execution data and erase only the temporary execution data linked to one or more of its functions.

[0127] In step 505, the VPP App is suspended during the hot reset operation. According to one example, the operation can perform a full or partial reset as if it were already running. According to another example, the VPP App can decide to ignore the hot reset operation.

[0128] Various embodiments and variations have been described. Those skilled in the art will understand that certain features of these various embodiments and variations can be combined, and others will be seen by those skilled in the art.

[0129] Finally, based on the functional indications given above, the actual implementation of the described embodiments and variations is within the capabilities of those skilled in the art.

Claims

1. A method for launching a first application, the first application being configured to be implemented by at least one low-level operating system of a secure element, the method comprising: At least a first binary data is updated during each reset operation of the security element, and the updated first binary data is associated with the at least one low-level operating system; Compare the updated first binary data with the second binary data associated with the first application; as well as When the updated first binary data is not equal to the second binary data, the second binary data is updated, wherein the second binary data is updated by making the second binary data equivalent to the first binary data; Wherein, after updating the second binary data, the at least one low-level operating system notifies the first application that a reset operation has occurred; and Upon being notified, and considering that the reset operation has already occurred, the first application implements a protocol for the type of reset operation that has already occurred.

2. The method of claim 1, wherein the comparison of the first binary data with the second binary data is performed by the at least one low-level operating system.

3. The method of claim 1, wherein the comparison of the first binary data with the second binary data is performed by the first application.

4. The method according to claim 1, further comprising: At least one third binary data is verified each time the first application is launched, and the at least one third binary data is associated with the at least one low-level operating system, and the at least one third binary data is updated after each reset operation of the security element.

5. The method of claim 4, wherein the first binary data is associated with a first type of reset operation, and the third binary data is associated with a second type of reset operation.

6. The method of claim 5, wherein the first type of reset operation is a cold reset operation, the cold reset operation comprising stopping the power supply to the safety element.

7. The method of claim 5, wherein the second type of reset operation is a thermal reset operation, the thermal reset operation comprising not stopping the power supply to the safety element.

8. The method of claim 1, wherein the security element is configured to implement at least one second application.

9. A security element configured to implement at least one low-level operating system, the at least one low-level operating system implementing at least one first application, the security element comprising: Non-transient computer-readable storage; as well as A security processor is coupled to the memory, and the security processor is configured to: At least a first binary data is updated during each reset operation of the security element, wherein the first binary data is associated with the at least one low-level operating system; The updated first binary data is compared with the second binary data associated with the at least one first application; as well as When the updated first binary data is not equal to the second binary data, the second binary data is updated, wherein the second binary data is updated by making the second binary data equivalent to the first binary data; The at least one low-level operating system is configured to: notify the first application that a reset operation has occurred after the second binary data has been updated; and The first application is configured to, upon being notified, implement a protocol of the type of reset operation that has already occurred, taking into account that the reset operation has already taken place.

10. The security element of claim 9, wherein the at least one low-level operating system is configured to compare the first binary data with the second binary data.

11. The security element of claim 9, wherein the first application is configured to compare the first binary data with the second binary data.

12. The security element of claim 9, wherein the security processor is configured to: verify at least one third binary data each time the first application is launched, wherein the at least one third binary data is associated with the at least one low-level operating system, and wherein the at least one third binary data is updated after each reset operation of the security element.

13. The security element of claim 12, wherein the first binary data is associated with a first type of reset operation, and the third binary data is associated with a second type of reset operation.

14. The safety element of claim 13, wherein the first type of reset operation is a cold reset operation, wherein the power supply to the safety element is stopped.

15. The safety element of claim 13, wherein the second type of reset operation is a thermal reset operation, wherein the power supply to the safety element is not interrupted.

16. The security element of claim 9, wherein the security element is embedded in an electronic device.

17. The safety element of claim 9, wherein the safety element is integrated into an electronic device.

18. The security element of claim 9, wherein the security element is configured to implement at least one second application.

Images