Method for implementing execution of application in secure element, and related system and secure element

Abstract

The disclosure relates to a method for implementing execution of an application in a secure element, and a related system and secure element. There is described a method for implementing execution of an application in a secure element (SE), comprising a host sending an APDU command to the SE containing the application, processing the APDU command at the SE for execution, implementing a plurality of operations of determination of the application commanded by the APDU command, and executing the execution of the application. The application determines, among a plurality of application operations commanded by the APDU command, a first set of operations to be performed by the application after receiving the APDU command and at least a second set of operations. The SE implements a first set of operations to be executed by the application after receiving the APDU command, and deferred execution of the second set of operations is performed upon communicating completion of execution of the first set of operations from the SE to the host.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority from Italian application No. 102023000014067, filed on July 6, 2023, which is hereby incorporated by reference in its entirety. Technical Field

[0003] Embodiments of the present disclosure relate to techniques for executing applications such as Java Card Applets in a secure element. Background Art

[0004] Secure elements are known, for example, tamper-resistant platforms, typically single-chip secure microcontrollers, capable of securely hosting applications and their confidential and encrypted data (e.g., cryptographic keys) in accordance with rules and security requirements set by well-known trusted authorities. Such secure hosting can be achieved, for example, using a Java Card platform. The secure element may correspond to or be embodied by a UICC, an "eUICC, Subscriber Identity Module", a "chip card", an iUICC, an integrated eUICC, an integrated secure element, an embedded secure element, a "secure element" or a SIM.

[0005] exist Figure 1 Schematically shown in FIG is a system 10 comprising a first host 11 (e.g. a mobile phone) comprising a host application APP1 operating in a first corresponding Java Card runtime environment J1 within a first secure element SE1. The operation of the host 11 is supervised by a microcontroller unit or microprocessor HP1. The host application APP1 in this example has access to an NFC controller N1 in the first secure element SE1. Thus, the host application APP1 can communicate with an NFC reader 12 on an NFC channel NC, e.g. based on the signaling type NFC-A of ISO / IEC 14443A, via an NFC antenna NA in the first host 11. The NFC reader 12 comprises a corresponding NFC antenna RNA coupled to an NFC reader / writer NRW, which decodes the signals exchanged with the first host 11 on the NFC channel NC and communicates with a reader processor RP, e.g. via an SPI (serial to parallel interface) RSP, which is coupled to a microprocessor in a second host 13 (e.g. an ECU host) for communication, e.g. via a CAN bus VB.

[0006] The second host 13 includes a second host SE2, including a second secure element SE2 and a corresponding Java Card runtime environment J2, and J2 includes a second applet APP2.

[0007] exist Figure 1In the embodiment, the second host 13 also comprises a corresponding NFC reader / writer NRW2, which exchanges signals with the second host microcontroller unit HP2 to read and write signals exchanged on the NFC channel NC. In particular, the architecture of the host is very simplified, and only the modules involved in the protocol are shown according to the solution described here.

[0008] In this regard, the dashed line indicates the path of the command from the first host 11 , in particular from the first applet APP1 to the second applet APP2 in the second host 13 .

[0009] Figure 1 An alternative wireless communication channel UCB is also indicated by way of example, which may be a BLE (Bluetooth Low Energy) / UWB (Ultra Wideband Wireless Channel), which is the path of commands from the first applet APP1 to the second host 13 (in particular the second processor HP2, indicated by the dashed (shorter dashed) line). The host 11 may include a BLE transceiver BT and a UWB transceiver UT at one end of the channel UCB, and may be coupled to a BLE reader BR and a UWB anchor UA (i.e., a device that detects UWB pulses in the second host 13) at the other end. The UWB anchor UA is controlled by a UWB controller UC.

[0010] The architecture shown may correspond, for example, to a mobile phone that uses a first applet APP1 to send a command to open a door of a vehicle equipped with a reader 12 and a second host 13 (e.g., a car ECU). In this architecture, a second applet APP2 performs the task of opening the door through an ECU (e.g., a second host 13). In particular, the applet (APP2 in collaboration with APP1) may operate according to the CCC (Car Networking Alliance) digital key ecosystem.

[0011] Figure 2A protocol diagram is shown, which represents the protocol by its transmission between nodes (such as hosts, entities, applications), or the interaction between the first host 11 (specifically, its host application APP1) and the second security element SE2. According to the ISO / IEC 7816 standard, the host-SE transmission is based on the APDU command / response protocol. Therefore, the host application APP1 in the host 11 must receive the response status word SW (SW indicates that the command processing has been completed) from the second security element SE2 before processing the corresponding response and continuing to the next protocol step. The response status word SW is a byte, for example, SW1 (for example, command processing status) and SW2 (for example, command qualifier), which define the processing status in the card according to the specification ISO-7814-4. The status word SW can signal normal processing ('9000' ISO-7814-4) or several other states including warnings or errors. Thus, for example, according to ISO-7814-4, the status word SW contains a normal processing indication (SW1SW2 = '9000') to indicate the completion of the first APDU command AC1, as explained below. As mentioned before, a Java Card based secure element comprises a Java Card Runtime Environment (JCRE), which receives APDU (Application Protocol Data Unit) commands and forwards them to applications (applets) in the secure element.

[0012] Therefore, in Figure 2 In the figure, it is first shown that the first application APP1 in the first host 11 (not shown) implements its application function in the first transmission T1. For example, the application function determines to send a command (for example, a first APDU command AC1) to the second security element SE2 through the reader 12 in transmission T2. ​​The reader 12 forwards the first APDU command AC1 to the second security element SE2 in transmission T3. The second security element SE2 receives the first APDU command AC1 at its low-level operating system O2 (that is, the operating system responsible for the input / output communication between the security element and other entities (including the first host 11)). The low-level operating system 22 indicates the received command and APDU command AC1 to the second Java Card runtime environment J2 via transmission T4. The JavaCard runtime environment J2 processes the APDU command AC1 in transmission T5, for example, by applying the Applet.process(APDU) method (for example, see the JCRE specification, Java Card Runtime Environment J2). TM Platform Runtime Environment Specification, Classic Edition 3.1, available at https: / / docs.oracle.com / Javacard / 3.1 / related-docs / JCCRE / JCCRE.pdf).

[0013] The APDU command causes an instance of the APDU class containing the command to be passed to the Process(APDU) method of the currently selected applet (i.e., APP2), which therefore starts the applet execution procedure P1, such start being indicated by P1S, wherein the Java Card virtual machine or JVCM executes the second applet APP2 process, processes the first APDU command AC1 in transmission T6, and then implements the first task TSK1 corresponding to T7 (i.e., the task required by the APDU command AC1).

[0014] Then, transmission T8 is implemented by sending a command response (i.e., response APDU RC1) to the low-level operating system O2. If the first APDU command AC1 requires the implementation of more than one task (e.g., a second task TSK2 is to be implemented after the first task TSK1), a more time-consuming second transmission T7' occurs, and only when one or more tasks (especially in the example task TSK2) are completed, the applet executor P1 considers that the Java Card virtual machine execution of the APP2 process is completed (process P1 completes PC) and sends a completion signal T9 to the Java Card runtime environment O2 to the low-level OS O2, which in turn determines to send a status word SW to the low-level operating system O2 in transmission T10, SW indicating the command processing status, for example, indicating completion by signaling normal processing (e.g., according to ISO-7814-4, the normal processing indication (SW1SW2='9000') indicates that the first APDU command AC1 has been completed, as mentioned above).

[0015] Also, in general, the structure of an ISO 7816 APDU command / response is as follows:

[0016] -APDU command (e.g. AC1):

[0017] ○Header (4 bytes) defining the class, instruction, and additional command parameters 1 and 2 (P1 P2)

[0018] ○ Command input data length (optional)

[0019] ○Command input data (optional)

[0020] ○Expected output data length (optional)

[0021] -APDU Response:

[0022] ○ Output data (optional)

[0023] ○Status word (2 bytes)

[0024] The allowed values ​​for the classes, instructions, P1, P2, the required input data for each command, and the expected response data and status word SW are defined by the application level specification and protocol.

[0025] The second secure element SE2 then sends (transmission T11) the response RC1 plus the status word SW (e.g. as defined in the Java Card Runtime Environment specification mentioned above) to the reader 12 via the low-level OS O2, which in turn sends (transmission T12) this response RC2 plus the status word SW to the first host application APP1 on the host 11. After transmission T10, the second secure element SE2 also enters an idle time or standby state, indicated by transmission T10' looped at the OS O2 level.

[0026] Then, the first host application APP1 processes the response RC1 and the status word SW of the second secure element SE2, i.e., implements one or more small program operations determined by such response RC1 and status word SW (transmission T13), and when it is completed, issues (transmission T14) a new command to the second secure element SE through the reader 12, which issues a second APDU command AC2 in transmission T15. Figure 2 As shown in , the time periods at the first secure element SE1 (particularly associated with the first application APP1) and the second secure element SE2 (O2) can be defined as:

[0027] a host waiting time HWT, between transmissions T2 and T12 at the host application APP1 , i.e. the time the host 11 (in particular the application APP1 ) waits for a response from the second secure element SE2 , and

[0028] - a secure element command processing time SEHT, between transmissions T3 and T11 , which is the time required by the second secure element SE2 to process the first APDU command AC1 , i.e. the time required to implement the operation required by the second secure element SE2 by means of such command AC1 ;

[0029] - secure element waiting time SEWT, the time between the idle state or standby state entered by the OS 22 after transmission T10 (T10′) and the reception of the second APDU command AC2 in transmission T15, i.e. the time the second secure element SE2 remains idle to wait for the next command;

[0030] - The host processing time HPT between transmissions T12 and T14, which is the time required for the applet APP1 / host 11 to process the response RC1 and issue the next command AC2.

[0031] Due to the host processing time HPT and the time required for the second security element SE2 to receive the next command AC2, the second security element SE2 waits for a time SEWT corresponding to the dead time, that is, a time of little or no activity. During the waiting time SEWT, the security element SE2 usually enters a standby state: in this state, the second security element SE2 can switch to a low power consumption mode to reduce power consumption until the second APDU command AC2 or the next APDU command is received.

[0032] According to the Java Card virtual machine specification, Java Card applet execution (e.g., program P1) is single-threaded: applet cannot parallelize tasks. Time-consuming operations on the second secure element SE2 increase the secure element command processing time SEHT and the host waiting time HWT. Time-consuming operations on the first host side (e.g., mobile phone) increase the host processing time HPT and the secure element waiting time SEWT.

[0033] Since host / SE communications are typically half-duplex and the SE can only process one command at a time, a typical approach to improving performance is to do the following on either the host or SE:

[0034] Host and secure element: Optimize operating system, application code

[0035] Host and security element: Increase CPU (central processing unit) operating frequency, I / O (input / output) protocol speed

[0036] Secure Element Only: Remove any unnecessary NVM operations

[0037] Secure Element Only: Fine-tune security countermeasures or reduce them if application use case allows (Secure Element side)

[0038] Secure element only: Provides a dedicated API (Application Programming Interface) tailored for the specific use case of the application (secure element side).

[0039] Each measure has disadvantages.

[0040] The host in the given example has complex architecture and operational constraints: the HW / SW layers interact according to well-defined protocols, timing, and power consumption limits. Limited improvements can be made.

[0041] The safety element should also strictly follow the safety guidelines: the countermeasure level cannot be reduced below the threshold defined in the guidelines.

[0042] The standard APIs available on all Java Card-based secure elements are "generic" and should securely serve any applicable use case; therefore, the security level cannot be customized for a specific application.

[0043] Specialized APIs can provide the necessary trade-offs between performance and security, but they cannot be reused in all possible use cases. Summary of the invention

[0044] In view of the above, various embodiments of the present disclosure are intended to provide solutions that can overcome one or more limitations of the prior art.

[0045] According to one or more embodiments, executing an application in a secure element includes: sending at least one APDU command by at least one host to a secure element including the application; processing at least one APDU command at the secure element for execution by the application; implementing multiple operations determined by the application commanded by the at least one APDU command, wherein the application determines at least a first group of operations and at least a second group of operations to be performed by the application after receiving the APDU command among the multiple application operations commanded by the at least one APDU command, and the method includes: implementing at the secure element the first group of operations to be performed by the application after receiving the APDU command, and after the completion of execution of at least the first group of operations is communicated from the secure element to the host, implementing deferred execution of at least the second group of operations.

[0046] In an embodiment, processing at least one APDU command for application execution includes processing in a runtime environment of a secure element, the method comprising: providing a software module defining a deferred program execution privileged entity in the secure element, applying, among a plurality of application operations commanded by at least one APDU command, determining at least a first set of operations to be performed by the application and at least a second set of operations to be performed by the deferred program after receiving the APDU command, the method comprising: implementing deferred execution of at least the second set of operations by commanding the deferred program execution privileged entity through the runtime environment to deferred execution in a deferred program object created by the deferred program execution privileged entity; and waiting at the secure element for supplying another APDU command to the runtime environment until such a second set of operations to be performed by the deferred program object is completed.

[0047] In an embodiment, the deferred program execution privileged entity creates a deferred program object during the installation phase (installation of the application).

[0048] In an embodiment, when an APDU command (particularly a first APDU command) is processed at the secure element, the deferred program execution privileged entity creates a deferred program object.

[0049] In an embodiment, a software module defining a deferred program execution privileged entity exposes an API that is added to a system, particularly a Java Card system in a secure element, that includes a runtime environment.

[0050] In an embodiment, the secure element is hosted in a host.

[0051] In an embodiment, the secure element is hosted in a different host.

[0052] In an embodiment, the method comprises, when another APDU command is received at the secure element, performing at the deferred program execution privileged entity a check of an execution result of a deferred program object associated with the at least one APDU command.

[0053] In an embodiment, the method includes: implementing a first set of operations corresponding to a first task; requesting, by an application, to execute a deferred program object from a deferred program execution privileged entity; the deferred program execution privileged entity is configured to schedule a deferred program in a runtime environment after receiving the request, indicating that the deferred program object is assigned to the application, and starting to execute the deferred program object during idle or standby time after sending a response (particularly an APDU response and a status word determined by the completion of the first set of operations) from a secure element to a host; the runtime environment is configured to indicate (particularly by setting a flag) that the deferred program is to be executed after receiving the schedule; the secure element is configured to wait for execution of another APDU command until the indication that the deferred program is to be executed is removed; after sending the response, the runtime environment commands the deferred program execution privileged entity to start executing the deferred program object to perform a second set of operations; then, after issuing a signal that the second set of operations is completed or an exception is issued during execution, the deferred program execution privileged entity sends a signal that the deferred program is completed to the runtime environment, and the runtime environment accordingly implements the removal of the indication that the deferred program is to be executed.

[0054] In a variant embodiment, the secure element includes a portion of the operating system dedicated to input / output communication operations to exchange signals between the runtime environment and the host.

[0055] In a variant embodiment, the application is configured to determine at least a first set of operations and at least a second set of operations to be performed by the application after receiving the APDU command, among multiple application operations commanded by at least one APDU command, based on criteria based on operation execution time or operation execution priority.

[0056] In a variant embodiment, the application is a Java Card applet and the runtime environment is a Java Card runtime environment.

[0057] According to one or more embodiments, one or more of the previous purposes are also achieved by a system comprising a host and a security element for communication exchange, the security element comprising an application, in particular a Java Card applet. The host is configured to send at least one APDU command to the application, and the system is configured to operate the method according to an embodiment.

[0058] In a variant embodiment, the system comprises: a first host hosting a corresponding secure element; and a second host comprising an application in the secure element, in particular a Java Card applet.

[0059] In a variant embodiment, the first host is a user terminal and the second host is a vehicle ECU, in particular configured to command the actuation of a door or the start of a car engine.

[0060] In a variant embodiment, the host and the secure element communicate via a wired or wireless channel, in particular an NFC, UWB or BLE channel.

[0061] According to one or more embodiments, one or more of the foregoing purposes are also achieved by a security element configured to communicate with at least one host, the security element including an application, in particular a Java Card applet, the security element being configured to: process at least one APDU command for execution by the application, implement a determined plurality of operations of the application commanded by the at least one APDU command, the application determining at least a first set of operations and at least a second set of operations to be performed by the application after receiving the APDU command among the plurality of application operations commanded by the at least one APDU command; implement the first set of operations to be performed by the application after receiving the APDU command; and implement deferred execution of at least the second set of operations after the completion of execution of at least the first set of operations is communicated from the security element to the host.

[0062] In an embodiment, a host sends at least one APDU command to a secure element including a Java Card applet. The secure element includes a Java Card runtime environment configured to process at least one APDU command for execution by the Java Card applet. The Java Card applet is configured to implement a plurality of determined applet operations commanded by the at least one APDU command. In particular, the solution described herein can be applied in application protocols, such as digital key vehicle access and engine start transactions of the CardConnect Alliance. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] Embodiments of the present disclosure will now be described with reference to the accompanying drawings, which are provided by way of non-limiting examples only, in which:

[0064] Figure 1 A system including a host and a secure element with an applet is schematically shown;

[0065] Figure 2 An explanatory diagram showing a protocol for implementing a method for executing a Java Card applet in a secure element according to the prior art;

[0066] Figure 3Schematically illustrates another system comprising a host and a secure element with an applet, which is configured to implement a method according to an embodiment;

[0067] Figure 4 An explanatory diagram showing a protocol for implementing a method for executing a Java Card applet in a secure element according to an embodiment;

[0068] Figure 5 A diagram showing the installation or creation of a program according to the method of an embodiment; and

[0069] Figure 6 A diagram showing subsequent stages of result checking of a method according to an embodiment. DETAILED DESCRIPTION

[0070] Various specific details are described in the following description to provide a deeper understanding of the embodiments. Embodiments may not be provided with one or more specific details, or other methods, components, materials, etc. may not be provided. In other cases, known structures, materials, or operations are not described or described in detail so as not to obscure various aspects of the embodiments.

[0071] References to "an embodiment" or "an embodiment" in the framework of the present disclosure are intended to indicate a specific configuration, structure, or characteristic about an embodiment (including at least one embodiment). Therefore, phrases that may appear throughout this description (such as "in an embodiment" or "in an embodiment") do not necessarily refer to the same embodiment. In addition, specific configurations, structures, or characteristics may be combined in one or more embodiments in any appropriate manner.

[0072] The references used herein are provided for convenience only and thus do not define the scope or range of the embodiments.

[0073] In short, the solution described herein provides a method for implementing the execution of a Java Card applet in a secure element, wherein the host sends APDU commands to the secure element containing such a Java Card applet, which commands may be implemented in a proprietary API, defining proprietary Java Card classes that allow the applet to group time-consuming operations into tasks to be performed at a later protocol stage ("deferred tasks"), schedule such tasks and obtain results when the appropriate protocol stage is reached.

[0074] Figure 3 A system 20 is schematically shown in which the solution described herein can be implemented. Figure 1 The same reference numerals indicate the same elements having the same functions.

[0075] Thus, the system comprises a first host 11, the first host 11 comprising a host application APP1 running in a first corresponding Java Card runtime environment J1 within a first secure element SE1. The use example here is also the same, the host application APP1 accesses the NFC controller N1 in the first secure element SE1 to communicate with the NFC reader 12 via the NFC antenna NA in the first host 11, the reader 12 is coupled to a second host 13 (e.g., an ECU host) for communication, for example, via a CAN bus VB, the second host 13 comprising a corresponding second secure element SE2, the second secure element SE2 comprising a corresponding Java Card runtime environment J2, J2 comprising a second Java Card applet APP2. As mentioned above, the presence of the reader 12 fully illustrates the communication channel between the hosts. However, in general, as long as the hosts have communication circuits (e.g., wireless or wired communication channels) to communicate between each other and between the corresponding secure elements, the solution does not require the reader 12.

[0076] In an embodiment, the method is also applicable to a host interacting with its secure element (i.e., a secure element hosted by the host), wherein the communication is provided, for example, by a bus or other signal lines. In addition, the dashed line here indicates the path of the command from the first host 11, in particular from the first applet APP1 to the second applet APP2 in the second host 13.

[0077] The only difference is that in each Java Card runtime environment, J1 and J2 indicate the presence of a deferral executor module DE. The deferral executor module DE is a software module, in particular an API (application programming interface). The solution described here provides a software extension of the Java Card platform (i.e., the Java Card runtime environment J1 or J2) and a specific API package for calculating complex and time-consuming operations in idle time by deferring the executor DE. For example, an applet APP2 resident on the second secure element S2 can call this API (i.e., deferral executor DE) to defer the operation in idle time (i.e., when one of the two parties, i.e., the host, is waiting for the next command / response exchange).

[0078] Figure 4 An example protocol diagram of the solution described herein is shown. In the diagram, the second applet APP2 represents a Java Card applet that calls the deferred procedure. Thus, the solution is shown to be applied in the second secure element SE2, however it may also be present in the first secure element SE1 at the same time. Figure 2 or Figure 1 system, Figure 4The protocol refers to a system in which no reader exists, i.e., the host 11 communicates directly with the host 13, i.e., the second low-level operating system O2 directly receives the first APDU command AC1 from the host 11 (e.g., through an NFC channel or other wireless or wired communication channel types).

[0079] In this case, the host 11 (rather than the reader 12) sends the first APDU command AC1 to the second secure element SE2 in transmission T3, which in turn receives the first APDU command AC1 at its low-level operating system O2. Similarly, the low-level operating system O2 implements the same transmission T4 (AC1), supplying the APDU AC1 to the Java Card runtime environment J2.

[0080] The Java Card runtime environment J2 processes the APDU command AC1 in transmission T5, for example, applies the Applet.process(APDU) method and starts the applet execution program P1, wherein the Java Card virtual machine executes the second applet APP2 process, i.e., processes the first APDU command AC1 in transmission T6, and then implements the first task TSK1 corresponding to T7, i.e., the task with the first set of operations required by the APDU command AC1 to be implemented by the applet APP2.

[0081] However, in Figure 4 In the protocol shown in , a deferred program execution privilege entity, a deferred executor DE, and a deferred program object DP are represented.

[0082] The Deferred Executor DE is a privileged entity obtained by adding a specific API to create a "deferred program" DP object. It is a Java API that is configured to implement the operations of the Deferred Executor DE described below through its set of software elements (including pre-written packages, classes and interfaces and their corresponding methods, fields and constructors One or more). As indicated, in addition to elements such as JCVM, JCRE and standard Java Card APIs, the Deferred Executor DE also exposes (i.e., enables access to) API packages added to the Java Card system. The Java Card applet APP2 requires the Deferred Executor DE to create a Deferred Program object DP and assign this Deferred Program object DP to the applet APP2. The applet APP2 attaches time-consuming tasks to the Deferred Program object DP, so they can be executed at a later stage, that is, the applet APP2 is configured to group the operations determined by APDUAC1 into a first group of operations (assigned to the first task TSK1), and is configured to group the operations determined by APDU AC1 into a second group of operations (assigned to the second task TSK2, preferably including time-consuming operations).

[0083] Therefore, after transmission T7, the applet APP2 is configured to implement a request T31 to the deferred executor DE, requesting execution by the deferred program DP. The deferred executor DE is configured to schedule such deferred program DP in the Java Card runtime environment J2 after receiving such request T31 (T32), that is, to indicate to the Java Card runtime environment J2 that the deferred program DP has been assigned to the applet APP2 and to indicate that the deferred program DP is started at idle time T10'. After receiving the scheduling of the deferred program DP (T32), the Java Card runtime environment J2 sets the flag "deferred execution pending" to TRUE in the operating system O2 (T33), that is, the deferred program object DP is pending execution.

[0084] Then, a transmission T8 is implemented to send a command response APDU RC1 to the low-level operating system O2.

[0085] In this case, with Figure 2 Differently, after executing the operation of the first task TSK1, the applet APP2 sends a completion signal T9 to the JavaCard runtime environment J2, indicating that the command AC1 has been processed, and J2 determines to send (transmit T10) the status word SW to the low-level operating system O2. In fact, the command AC1 is processed in such a way that, in the postponed program DP, the first task TSK1 has been executed while the second task TSK2 is being executed (after reaching the idle state T10').

[0086] The second secure element SE2 then sends (transmission T11) the response RC1 plus the status word SW (e.g., as defined in the JCRE specification mentioned above) to the host 11 (in an embodiment, to the first application APP1 (if present), however it can also be sent directly to the host 11) through the low-level OS O2. The host 11 processes the response RC1 and the status word SW of the second secure element SE2 through or without the first host application APP1, i.e., implements the operation determined by such response RC1 and the status word SW (transmission T13), and after the operation is completed, issues a new command to the second secure element SE, thereby issuing a second APDU command AC2 to the OS O2 in transmission T15 (without skipping the reader transmission T14). In this case, according to the solution described here, when the flag "postpone execution pending" is set to TRUE, the OS O2 waits for the command AC2 to be forwarded to the JavaCard runtime environment J2 (transmission T39).

[0087] Furthermore, according to the solution described here, the Figure 2In the prior art protocol, after transmission T10, the second secure element SE2 also enters an idle time or standby state (indicated by transmission T10' cycled at OS O2 level), Figure 4 In the protocol of , the Java Card runtime environment J2 (scheduled by the deferred executor DE in transmission T32) instructs the deferred executor DE in transmission T34 to start the deferred execution. Therefore, the deferred executor DE issues (T35) an execution command to the deferred program object DP, which executes (T36) the second task TSK2 (i.e., the time-consuming second set of operations).

[0088] After the deferred program object DP sends a signal to the deferred executor in transmission T37 to notify that the second set of operations in the second task TSK2 is completed (or an exception is issued during execution), the deferred executor sends a signal T38 to the Java Card runtime environment J2 to notify that the deferred program has been completed, and J2 sets the flag "deferred execution pending" to FALSE (T40) in the low-level operating system OS2, thereby exiting the waiting state T40 and forwarding the second APDU AC2 to the Java Card runtime environment J2 for execution at the applet APP2.

[0089] Therefore, as just described, a "deferred execution model" is proposed that allows the Java Card runtime environment to execute deferred tasks when the secure element is in an "idle / standby" state.

[0090] When the Java Card applet receives an APDU command that requires a time-consuming task, it requests the scheduling of the "deferred procedure" created in the previous step. The Java Card runtime environment executes this procedure after sending the APDU status word to the host. If the secure element's input / output operating system receives the next APDU before the deferred procedure is completed, it delays the processing of the new APDU.

[0091] During the HPT execution deferral procedure, the secure element remains active.

[0092] Therefore, based on the above, Figure 3 and Figure 4 A method for executing an application APP2 (particularly a Java Card applet) in a secure element (e.g., SE2) is described.

[0093] The method comprises: at least one host (for example, the first host 11) sends (for example, transmits T1-T4) at least one APDU command (for example, AC1) to a security element (for example, the second security element SE2) including an application (for example, the second Java applet APP2),

[0094] At least one APDU command AC1 is processed (e.g., transmitted T6) at the security element SE2 for execution by the application APP2, and multiple operations determined by the application APP2 commanded by the at least one APDU command AC1 are implemented, wherein the application APP2 determines at least a first group (e.g., TSK1) of operations and at least a second group (e.g., TSK2) of operations to be performed by the application APP2 after receiving the APDU command AC1 among the multiple application operations commanded by the at least one APDU command AC1. The method includes: at the security element SE2, implementing the first group of TSK1 operations to be performed by the application APP2 after receiving the APDU command AC1; after the completion of the execution of at least the first group of TSK1 operations is communicated from the security element SE2 to the host (e.g., the first host 11), implementing deferred execution of at least the second group of TSK2 operations (e.g., transactions T34-T39).

[0095] As indicated, the secure element (e.g., SE2) waits to supply another APDU command (e.g., AC2) to the runtime environment (e.g., Java Card runtime environment J2) until deferred execution of this second set (e.g., TSK2) of operations to be performed is completed.

[0096] In more detail, Figure 3 and Figure 4 A method for implementing execution of an application (particularly a Java Card applet, such as APP2) in a secure element (such as SE2) is described.

[0097] The method comprises: at least one host (e.g., 11) sends (e.g., T) at least one APDU command (e.g., AC1) to a security element (e.g., SE2) including an application (in particular, a Java Card applet, such as APP2),

[0098] The security element (e.g., SE2) includes a runtime environment (in particular, a Java Card runtime environment, such as J2), which is configured to process at least one APDU command (e.g., AC1) for execution by an application (in particular, a Java Card applet, such as APP2), and the application (in particular, a Java Card applet, such as APP2) is configured to implement a plurality of determined applet operations commanded by the at least one APDU command (e.g., AC1), and the method comprises: in the security element (e.g., SE2), providing a software module defining a deferred program execution privileged entity (e.g., DE); the application (in particular, a Java Card applet, such as APP2) is configured to, among the operations commanded by the at least one APDU command (e.g., AC1), select at least a first group (e.g., TSK1) of operations to be implemented after receiving the at least one APDU command (e.g., AC1) and at least a second group (e.g., TSK2) of operations to be performed by the deferred program; the Java Card applet The Java Card runtime environment (e.g., J2) is configured to, after the completion of execution of at least a first set (e.g., TSK1) of operations is communicated from the secure element (e.g., SE2) to the host (e.g., 11), command a deferred program execution privileged entity (e.g., DE) to execute at least a second set (e.g., TSK2) of operations in a deferred program object (e.g., DP) created by the deferred program execution privileged entity (e.g., DE); the secure element (e.g., SE2) is configured to wait for supplying another APDU command to the runtime environment (in particular, the Java Card runtime environment, e.g., J2) until the second set (e.g., TSK2) of operations executed by the deferred program object (e.g., DP) is completed.

[0099] The software module defining the deferred program execution privileged entity DE (ie the deferred executor) may be an API, more particularly an API of a Java Card runtime environment (eg J2) added to a secure element (eg SE2).

[0100] With reference to a specific transmission, substantially this method provides for implementing (e.g., T7) a first set of operations corresponding to a first task (e.g., TSK1) requested (e.g., T31) by a Java Card applet (e.g., APP2) to have a deferred program execution privileged entity (e.g., DE) execute a deferred program object (e.g., DP); the deferred program execution privileged entity (e.g., DE) being configured to, upon receiving the request (e.g., T31), schedule a deferred program (e.g., T32) in a Java Card runtime environment (e.g., J2) indicating that the deferred program object (e.g., DP) has been assigned to the Java Card applet; Card applet (e.g., APP2), and is configured to start execution of a deferred program object (e.g., DP) during idle or standby time (e.g., egT10') after sending (e.g., T11) a response (in particular, an APDU response, such as RC1) and a status word (e.g., SW) from a secure element (e.g., SE2) to a host (e.g., 11), wherein the completion of a first set (e.g., TSK1) of operations determines the response and the status word; the JavaCard runtime environment (e.g., J2) is configured to indicate (e.g., T33) that a deferred program (e.g., DP) is to be executed, in particular by setting a flag, after receiving a schedule (e.g., T32); the secure element is configured to wait (e.g., T40) to execute another APDU command (e.g., AC2) until the indication that the deferred program (e.g., DP) is to be executed is removed (e.g., T39); after sending (e.g., T11) the response, the Java The Java Card runtime environment (e.g., J2) instructs (e.g., T34) the deferred program execution privileged entity (e.g., DE) to start (e.g., T35) the execution of a deferred program object (e.g., DP) and execute (e.g., T36) a second set (e.g., TSK2) of operations; then, after issuing a completion signal of the second set (e.g., TSK2) of operations or issuing an exception signal (e.g., T37, T38) during its execution, the deferred program execution privileged entity (e.g., DE) sends a deferred program completion signal to the Java Card runtime environment (e.g., J2), and the runtime environment accordingly implements the removal (e.g., T39) of the indication that the deferred program (e.g., DP) is to be executed.

[0101] In an embodiment, if the completion signal is not received within the timeout interval, the host 11 can resend the command (e.g., the first APDU, AC1). This means that the processing of such a command is restarted starting from the first task TSK1.

[0102] Figure 5 A protocol diagram according to the solution proposed here is shown, which illustrates the transmission involved in the setup or installation phase of the deferral program, namely the deferral executor DE and the deferral program object at the second secure element SE2 .

[0103] exist Figure 5 In the figure, a transmission T5 from the Java Card runtime environment J2 is shown, which indicates processing the first APDU command AC1, for example, applying the Applet.process(APDU) method and starting the applet execution program P1.

[0104] Alternatively, in the setup transport, T5 may correspond to an install operation (ie, the Java Card runtime environment's applet.install() method), whose main task within the applet is to create an instance of the applet subclass using its constructor and register the instance.

[0105] Then, the second applet APP2 creates a deferred program object DP by sending a create command to the deferred executor DE (transmission T26). As mentioned before, the deferred executor DE is a privileged entity (such as the Java Card runtime environment J2) that can interact and create deferred program objects DP. The applet APP2 asks the deferred executor DE to create a deferred program object DP and assign it to the applet APP2.

[0106] The defer executor DE creates (T27) a new deferr object DP and then returns (T28) the deferr object DP to the applet APP2. The second applet APP2, after receiving, implements the operation of attaching the second task TSK2 to the deferr DFP (transmission T29) and returns control (T30) to the Java Card runtime environment J2. The Java Card applet APP2 attaches the time-consuming tasks to the deferr object DP so that they can be executed later.

[0107] In transmission T29, an additional operation is performed to insert a task (e.g., a second task TSK2) into a deferred program object DP created by the deferred executor DE, which is initially empty. Since the Java Card applet is configured to group the operations commanded by a certain APDU command (e.g., AC1) into at least a first set of applet operations associated with task TSK1 and a second set of applet operations associated with at least a second task TSK2, this second set of applet operations preferably contains more time-consuming operations.

[0108] As shown in the figure, in order to avoid wasting time during the application protocol execution, the applet APP2 can create a deferred program object DP in advance (for example, during the installation of the applet). Figure 4 The protocol transmission can be Figure 3Because this corresponds to postponing the setting of the program object DP, for example, when installing the applet APP2 (installing transmission T5). However, the applet APP2 can also implement this operation after receiving the first APDU (e.g., AC1) (processing transmission T5).

[0109] Therefore, in essence, the method includes the deferred program execution privileged entity DE creating a deferred program object DP during the installation phase (e.g., method (install())) of a Java Card applet (e.g., APP2), or creating a deferred program object DP when processing an APDU command (in particular, the first APDU command AC1) at a secure element (e.g., SE2).

[0110] The solution requires that, at a given protocol stage, the Java Card applet (APP2 in the example) knows that one or more time-consuming tasks should be implemented. In addition, all (multiple) task inputs are available, for example, input data shared and passed by the host in a previous exchange or data permanently stored in the secure element memory. The results of one or more tasks can only be used at a later stage of the protocol (for example, after another APDU exchange). Therefore, the postponement of the execution of a time-consuming task may imply that all inputs are available for the first command, while its output is only used or considered in subsequent commands.

[0111] in this regard, Figure 6 The protocol check procedure is also described. After receiving the second APDU command AC2 (T15), OS O2 postpones its execution, remains in the waiting state T40 until the flag is set to FALSE (T39) during the execution of the postponed transmission (i.e. T37, T38), and then sends the second APDU AC2 to the Java Card runtime environment J2 (T41 (AC2)) in the transmission corresponding to T4, and then the applet implements the execution of the second ADPU AC2 (T42, corresponding to T5), processes the command AC2, and sends a request T45 to the postponed executor DE to check the result of the previous postponed procedure. The postponed executor DE sends (T45) the result or exception to the applet APP2. Then, the applet APP2 sends (T46, corresponding to T8) a command response to OS O2, and then the command processing is completed (T47, corresponding to T9), and then sends the status word SW to OS O2 (T48, corresponding to T10). Finally, the APDU response and the status word SW are sent to the host 11 (T49, corresponding to T11).

[0112] therefore, Figure 6The protocol shows how the result of a task (e.g., TSK2) is only used in a later stage of the protocol after another APDU exchange (in this case, after executing the second APDU AC2). Postponing the execution of a procedure may also mean postponing any error management that should have been implemented during the execution of the first APDU command. Thus, the applet APP2 is allowed to query the execution status of the postponed procedure and handle any errors when processing the second APDU command.

[0113] In particular, the method described herein includes, when another APDU command (e.g., a second command AC2) is received at the security element SE2, implementing a check of the execution result of a deferred program object DP associated with at least one APDU command (i.e., a previous command AC1) through operations T45 and T46 at the deferred program execution privileged entity DE.

[0114] The solution described here can be applied to any scenario where high performance of time-consuming operations is required and where there is sufficient lead time between command processing (even multiple commands). Of course, this depends on the capabilities (e.g., computing speed) and power of the systems involved.

[0115] A similar result can be obtained by modifying the behavior of the Java Card Runtime Environment (the OS layer responsible for input / output communication): the APDU response and status word can be sent earlier while the Applet.process() method is still running, assuming that the applet does not modify the response buffer or the SW. Nevertheless, this affects several SW layers in the SE implementation.

[0116] For example, by programming by a programmer or developer, the application (e.g., APP2) has been configured to determine, among a plurality of application operations commanded by at least one APDU command AC1, at least a first set of TSK1 operations and at least a second set of TSK2 operations to be performed by the application APP2 after receiving the APDU command AC1, according to criteria based on operation execution time or operation execution priority. Other criteria are also possible depending on the application characteristics.

[0117] It should be emphasized that determining or selecting a task set (e.g., the first task TSK1 and the second task TSK2, and the division in other subsequent tasks of the operation of applet APP2) is a part of the design / programming of an application (e.g., APP2), which may be based on time / priority criteria. For example, an application specification can define or determine its own APDU command / response (e.g., according to the APDU formatted in ISO 7816-4). For each APDU command, the specification defines that the host must provide the exact input provided by the safety element storing the application (e.g., APP2), the expected calculation or operation that the safety element should implement, and the expected output data and status word (e.g., SW) that the safety element should provide when the command is successfully processed (e.g., normally processed) or is wrong. Therefore, all codes required for command processing, the exact code of the task, and the creation of the postponed program are predefined or determined during application or applet development.

[0118] Based on what is defined in the application specification, the applet developer can know in advance which commands are critical in terms of computation or execution and time, and which commands the host (e.g., 11) is expected to use a lot of processing time in. Therefore, the application code can be designed in such a way that each command processing is handled using a series of tasks to be executed as a whole (i.e., before returning a status word) or even defining a task that anticipates partial processing of the next command instead of just waiting.

[0119] Based on the above, therefore, the advantages of the described solution are clear.

[0120] The solution described here allows small programs with time-consuming operations to be executed in a better way compared to methods using increased frequency, I / O and CPU speed, or reduction countermeasures.

[0121] Furthermore, the solution does not require rewriting the applet code from Java to native code.

[0122] The solution described is a generic mechanism that can operate with different use cases or applications involving time-consuming operations.

[0123] Applications are grouped into "deferred programs"; all of these operations can be deferred to a later APDU exchange, without having to deal with ad-hoc optimizations strictly related to a given operation. The extension is a "pluggable" Java Card extension: it does not change the behavior described in the official Java Card API (no impact on the official test suite). Deferred programs are object instantiations of classes written as Java Card code, allowing applets to attach applet tasks (Java Card objects and associated code). Deferred executors are separate software modules, extensions to the Java Card runtime environment. There is minimal impact on the low-level OS and JCRE layers: essentially, these are the flags needed to tell the Java Card runtime environment that a new program should be executed (just like it does with the Applet.process() method), and any flags for the OS to defer processing of any incoming APDUs until the deferred program has completed.

[0124] Of course, without prejudice to the principle of the invention, the details of construction and of the embodiments may vary widely from what is described and illustrated herein purely by way of example, without departing from the scope of the invention as defined in the following claims.

[0125] The solution described here may be applied between a first and a second host comprising respective secure elements, as in the exemplary embodiment.

[0126] However, the solution described here is applicable to all systems including at least one host sending APDU commands to a secure element including a Java Card applet. Thus, it can be applicable to a host sending commands to its own secure element but not to secure elements of other hosts, or to any other APDU exchange and response between any host and any secure element.

Claims

1. A method for implementing execution of an application in a secure element, the method comprising: The secure element receives an application protocol data unit (APDU) command from a host, wherein the APDU command includes an application to be executed; Processing, by the secure element, the APDU command for execution by the application to implement a plurality of operations of the application according to the APDU command, the plurality of operations comprising a first group of operations and a second group of operations to be processed, the application to perform the first group of operations after receiving the APDU command; implementing, by the secure element, the first set of operations to be performed by the application after receiving the APDU command; as well as After completion of the execution of the first set of operations is communicated from the secure element to the host, deferred execution of the second set of operations is performed.

2. The method of claim 1 , wherein processing the APDU command for execution by the application comprises processing in a runtime environment of the secure element, the method further comprising: providing a deferred program execution privileged entity in the secure element, wherein the first set of operations is to be performed by the application after receiving the APDU command, and wherein the second set of operations is to be performed by the deferred program execution privileged entity; commanding, by the runtime environment, to the deferred program execution privileged entity, the deferred execution in a deferred program object to perform the deferred execution of the second set of operations, the deferred program object being created by the deferred program execution privileged entity; as well as Waiting at the secure element to supply a second APDU command to the runtime environment until the second set of operations to be performed by the deferred program object are completed. 3 . The method of claim 2 , wherein the deferred program execution privileged entity creates the deferred program object during an installation phase of the application.

4. The method of claim 2, wherein the deferred program execution privileged entity creates the deferred program object in response to the APDU command, the APDU command being processed at the secure element.

5. The method of claim 2, wherein the deferred program execution privileged entity exposes an API added to a system including the runtime environment.

6. The method according to claim 2, further comprising: In response to receiving the second APDU command at the secure element, a check is performed at the deferred program execution privileged entity on an execution result of the deferred program object associated with the APDU command.

7. The method according to claim 2, further comprising: performing the first set of operations, the first set of operations corresponding to the first task; Requesting, by the application, the execution of the deferred program object from the deferred program execution privileged entity; In response to the deferred program execution privileged entity receiving the request, scheduling the deferred program in the runtime environment to indicate that the deferred program object is assigned to the application; starting said execution of said deferred program object at idle or standby time after sending an APDU response from said secure element to said host, in particular an APDU response and a status word determined by the completion of said first set of operations; In response to receiving the schedule, setting, by the runtime environment, a flag indicating that the deferred procedure is to be executed; awaiting execution of a second APDU by the secure element until the indication that the postponed procedure is to be executed is removed; Instructing the deferred program execution privileged entity by the runtime environment to start the execution of the deferred program object; performing the second set of operations; as well as The deferred program execution privileged entity signals completion of the deferred program to the runtime environment, wherein the runtime environment removes the indication that the deferred program is to be executed in response to signaling completion of the second set of operations or raising an exception during the execution of the second set of operations.

8. The method of claim 2, wherein the secure element includes an operating system portion dedicated to input / output communication operations to exchange signals between the runtime environment and the host.

9. The method of claim 2, wherein the application is a Java Card applet, and wherein the runtime environment is a Java Card runtime environment.

10. The method of claim 1, wherein the secure element is hosted in the host.

11. The method of claim 1, wherein the host is a first host, and wherein the secure element is hosted in a second host.

12. The method according to claim 1, further comprising: The plurality of operations are determined by the application according to a criterion, the criterion being based on an execution time of the operations or an execution priority of the operations.

13. A system comprising: A host is configured to transmit an application protocol data unit (APDU) command, wherein the APDU command includes an application to be executed; as well as A security element, in communication with the host, wherein the security element is configured to: Receiving the APDU, processing the APDU command for execution by the application to implement a plurality of operations of the application according to the APDU command, the plurality of operations comprising a first set of operations and a second set of operations to be processed, the application to perform the first set of operations after receiving the APDU command, implementing a first set of operations to be performed by the application after receiving the APDU command, and After completion of the execution of the first set of operations is communicated from the secure element to the host, deferred execution of the second set of operations is performed. 14 . The system of claim 13 , wherein the secure element is a first secure element, wherein the host is a first host configured to host a second secure element, wherein the system further comprises a second host configured to host the first secure element. 15 . The system of claim 14 , wherein the first host is a user terminal, wherein the second host is an electronic control unit (ECU) of a vehicle, and wherein the ECU is configured to command door actuation or start an engine of the vehicle.

16. The system of claim 13, wherein the host and the secure element communicate via a wired or wireless channel.

17. The system of claim 16, wherein the wireless channel is one or more of a near field communication (NFC) channel, an ultra-wideband (UWB) channel, or a Bluetooth low energy (BLE) channel.

18. A security element in communication with a host, the security element being configured to: receiving an application protocol data unit (APDU) command from the host, wherein the APDU command includes an application to be executed; Processing the APDU command for execution by the application to implement multiple operations of the application according to the APDU command, the multiple operations including a first group of operations and a second group of operations to be processed, the application to perform the first group of operations after receiving the APDU command; Implementing the first set of operations to be performed by the application after receiving the APDU command; as well as After completion of the execution of the first set of operations is communicated from the secure element to the host, deferred execution of the second set of operations is performed. 19 . The secure element of claim 18 , wherein the secure element is a first secure element, wherein the host is a first host configured to host a second secure element, wherein the second host is configured to host the first secure element. 20 . The secure element of claim 19 , wherein the first host is a user terminal, wherein the second host is an electronic control unit (ECU) of a vehicle, and wherein the ECU is configured to command door actuation or start an engine of the vehicle.

Images