SECURED ELEMENT AND METHOD FOR COMMUNICATION BETWEEN AN ELECTRONIC DEVICE AND A SECURED ELEMENT

Description

technical field

[0001] This description applies generally to electronic devices, and more specifically to electronic devices adapted for handling confidential data. More specifically, this description concerns the communication of a secure element with other electronic devices. Previous technique

[0002] There is a growing number of electronic devices designed to provide digital services. These digital services use cryptographic mechanisms, making it essential to protect sensitive data. The integrity of the content is also crucial; unlike an encryption (or signature) key, an identification number must be unalterable but freely accessible. Therefore, electronic devices are required to guarantee the confidentiality and integrity of data.

[0003] A secure element is an electronic device, whether standalone or not, designed to handle confidential data securely, meaning without that confidential data being accessible or deduced, for example, through side-channel or penetration attacks. A secure element can be configured to encrypt data, for example.

[0004] It would be desirable to be able to improve, at least in part, certain aspects of communication between a secure element and other electronic devices.

[0005] US Patent 2018 / 376333 describes a process in which, when the protocol of an application running on a device is incompatible with that of a remote system, the transaction is converted to enable communication. This document concerns the management of a transaction between a card and a reader and only addresses application protocols, i.e., high-level protocols. It does not address changes in the physical link or routing.

[0006] Document FR 3 090 947 describes a device with multiple communication interfaces and corresponding process.

[0007] US document 2016 / 210179 describes a communication protocol bridge for processing card devices.

[0008] US document 2010 / 272254 describes a secure NCF device and a method for supporting different security modules.

[0009] US document 2016 / 173652 describes a device for supporting communications between several types of secure carriers and its communication method.

[0010] US document 2019 / 318341 describes an integrated mobile trust service manager.

[0011] US document 2016 / 112874 describes a method and operating system for a secure element.

[0012] US document 2019 / 005284 describes an interface between a near field communication (NFC) controller and a secure element. Summary of the invention

[0013] There is a need for secure components that can communicate effectively with other electronic devices.

[0014] One embodiment overcomes all or part of the drawbacks of known secure elements.

[0015] The invention is defined by the attached claims. Brief description of the drawings

[0016] These features and advantages, as well as others, will be described in detail in the following description of particular embodiments, given by way of non-limiting example, in relation to the attached figures, among which: there figure 1 represents, schematically and in block form, an example of an electronic device of the type to which the described embodiments apply; the figure 2 represents, schematically and in block form, another example of an electronic device of the type to which the described embodiments apply; the figure 3 represents, schematically and in block form, yet another example of an electronic device of the type to which the described embodiments apply; the figure 4represents, schematically and in block form, a method of implementing a software architecture for a secure element of an electronic device of the type described in relation to the figures 1 to 3 ; and the figure 5 represents, schematically and in block form, a method of implementing communication between two electronic devices. Description of the implementation methods

[0017] The same elements have been designated by the same reference numerals in the different figures. In particular, structural and / or functional elements common to the different embodiments may have the same reference numerals and may have identical structural, dimensional and material properties.

[0018] For the sake of clarity, only the steps and elements useful for understanding the implementation methods described have been represented and are detailed.

[0019] Unless otherwise specified, when referring to two connected elements, this means directly connected without any intermediate elements other than conductors, and when referring to two coupled elements, this means that these two elements can be connected or linked through one or more other elements.

[0020] In the description that follows, when referring to absolute positional qualifiers, such as the terms "front", "back", "top", "bottom", "left", "right", etc., or relative positional qualifiers, such as the terms "above", "below", "superior", "inferior", etc., or to orientational qualifiers, such as the terms "horizontal", "vertical", etc., unless otherwise specified, it refers to the orientation of the figures.

[0021] Unless otherwise specified, the expressions "approximately", "roughly", and "on the order of" mean within 10%, preferably within 5%.

[0022] Various examples of implementation and realization are subsequently described. Regardless of the name given to these examples (embodyments, examples, variants, etc.) and the qualifiers used (for example, preferably, etc.), only the parts of the description that are included in the scope of the claims are part of the present invention, the other examples being given only for illustrative purposes and being useful only to highlight aspects specific to the invention as opposed to what is not part of it.

[0023] There figure 1 represents, schematically and in block form, an example of an electronic device 100 (SOC) of the type to which the described embodiments apply.

[0024] Device 100 is an electronic device built on a single chip (System on Chip - SoC). Device 100 includes a secure element 110 which, in this example, is integrated (iSE - integrated Secure Element). The secure element 110 is integrated into Device 100, meaning it can operate autonomously within Device 100. In one embodiment, the secure element 110 uses certain hardware resources of Device 100 to function, such as memory, circuits implementing specific functionalities, etc.

[0025] The integrated secure element 110 is an electronic circuit that handles secret data, which is, for example, encrypted. The secure element 110 includes: at least one processor 111 (SE CPU) adapted to handle secret data; a memory management function 112 (MMF) and / or a memory management unit (MMU) (not shown), adapted to handle reading and writing data in the memories; one or more circuits 113 (HW FUNCTION) adapted to implement hardware functionalities (e.g., a cryptographic accelerator, a communication cell, etc.) of the secure element 110; at least one volatile memory 114 (SE RAM); at least one non-volatile memory 115 (SE NVM); a communication circuit 116 (COMM) adapted to handle data and command transmissions between the secure element 110 and the rest of the device 100; and a communication bus 117 (SE BUS) linking all the elements of the secure element 110.

[0026] Alternatively, 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 ISO7816 standard, connected with a system-on-chip modem 100, and another SWP (Single Wire Protocol) type bus connected to a Near Field Communication (NFC) device.

[0027] The processor 111 is used to process commands and data from memories 114 and 115, or other memories included in the device 100. The processor 111 uses the memory management circuit 112 as an intermediary to manage the storage of data and commands in memory, so the processor never has direct access to memories 114 and 115. As an example, the circuit 112 can, for example, be used to allocate memory spaces of volatile or non-volatile memory to certain applications implemented by the integrated secure element.

[0028] Circuits 113 can include a multitude of circuit types and components, functions enabling data copying to external memories, cryptographic coprocessors, etc.

[0029] Communication circuit 116 can serve as a data reception and transmission chain for secure element 110. Circuit 116 may include data reception circuits, data encryption and / or decryption circuits, one or more routers, and data conversion circuits. Device 100 may consist only of secure element 110, but may also optionally include: one or more processors 121 (SOC CPU) adapted to process data; one or more circuits 122 (FUNCTION) adapted to implement different functionalities of the 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) allowing the exchange and transmission of commands and data to all the elements mentioned above.

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

[0031] The secure element 110 can have access to the hardware resources of the device 100 to function, such as circuits 122, memories 123, 124 or even memories 21 and 22.

[0032] There figure 2 represents, schematically and in block form, another example of an electronic device 100' of the type to which the described embodiments apply.

[0033] The 100' device includes various electronic circuits or chips, among which are: an embedded secure element (eSE) 150 constituting a secure environment (TRE - Tamper Resistant Element); a main CPU 161; a modem-type communication circuit 163 (Modem); and a near field communication circuit 165 (NFC controller).

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

[0035] Element 150 also integrates communication interfaces with the outside world using various communication protocols, for example: an interface 156 (I2C / SPI HW) of type I2C or SPI for communication with the external processor 161; an interface 157 (ISO7816) for communication according to the ISO7816 standard with the modem 163; and an interface 158 (SWP) of type SWP for communication with the NFC controller 165.

[0036] Device 100' may include other circuits, integrated or not. For example, the embedded security element 150 may use one or more external memories (not shown) with which it communicates directly or via the main processor.

[0037] Unlike an integrated security element such as element 110 of the figure 1 , an embedded secure element 150 is not integrated with the other components of the device 100' and in particular the main processor of the application.

[0038] The secure embedded element 150 can however be integrated with a near field communication (NFC) controller.

[0039] There figure 3 represents, schematically and in block form, yet another example of a 100" electronic device of the type to which the described embodiments apply.

[0040] In this example, it is assumed that the embedded security element is integrated with a near-field communication controller on the same 180 chip. Thus, the integrated circuit or 180 chip comprises: a secure onboard element 150' (TRE) including the same elements as element 150 of the figure 2with the exception of interface 158, namely: a secure CPU 151; a hardware cryptographic CPU 152; one or more volatile memories 153 (RAM); one or more non-volatile memories 154 (NVM); one or more communication buses 155 between the different components of element 150; an I2C or SPI interface 156 (I2C / SPI HW) for communication with the external processor 161 (Main CPU); and an ISO7816 interface 157 for communication with the modem 163 (Modem) according to the ISO7816 standard; and an NFC controller 170 including, for example: a CPU 171; a radio frequency transmit / receive circuit 172 (RF Analog HW) or RF analog head; one or more volatile memories 173 (RAM); one or more non-volatile memories 174 (NVM); one or more communication buses 175 (Bus) between the different components of the NFC controller;and an interface 176 (I2C / SPI HW) for communication with the main processor 161 of device 100".;

[0041] The exchanges between the secure element 150' and the controller 170 pass directly through the buses 155 and 175 which, depending on the case, are linked together or constitute a single bus, the element 150' and the controller 170 being able to simulate an SWP protocol if necessary.

[0042] The secure element 150' and the controller can also communicate via their RAM memories 153 and 173 through a shared memory 159 enabling inter-process communication (IPC - Inter Process Communication).

[0043] Alternatively, the 150' secure element and the controller can communicate via their internal communication cells (e.g., SWP) (not shown). This allows the SWP exchange format (and the protocols implemented on it) to be maintained without the constraints (such as noise, bus speed limitations, etc.).

[0044] The application to near field communications between a secure element (integrated or embedded) is a preferred application due to the strong development of these functionalities in electronic devices.

[0045] There figure 4 represents, schematically and in block form, a method of implementing a software architecture 200 of a secure element of an electronic device of the type described in relation to the figures 1 to 3 .

[0046] Unless otherwise specified, the term "secure element" hereafter refers interchangeably to an embedded secure element or an integrated secure element. Thus, the software architecture 200 of the secure element SE can be implemented in any of the elements 110, 150, or 150' shown in the preceding figures.

[0047] The architecture 200 includes a primary platform 210 (VPP), generally referred to as the Virtual Primary Platform (VPP), comprising access to the electronic components 211 (HW) of the secure element SE, and comprising one or more low-level operating systems 213 (LLOS). In one embodiment, the primary platform 210 further includes a circuit adapted to implement communication management software or a communication management process 215 (COMM MGT), the operation of which is described in relation to the figure 5 .

[0048] Components 211 are the hardware resources of the secure element SE (110, figure 1 ; 150, figure 2 ; 150', figure 3 ). The components 211 of the secure element 110 are, for example, one or more processors, for example processor 111 ( figure 1 ) or 151 ( figures 2 And 3 ), one or more memories, for example memories 114 and 115 ( figure 1 ) or 153 and 154 ( figures 2 And 3 ), one or more communication devices, such as a communication device enabling direct communication with a Near Field Communication (NFC) device, a short-range communication device using, for example, the Bluetooth standard, biometric sensors, etc.

[0049] Low-level operating systems (213) are software adapted to implement components (211) to execute commands received from applications implemented by the secure element. For example, low-level operating systems (213) include all or part of the driver software for components (211).

[0050] A low-level 213 operating system consists of execution code (or executable code) and execution data. The execution code contains instructions that allow the program's functions to be executed. By definition, instructions are invariant for a given program, except when a program update modifies them. The execution data is used by the execution code to contextualize the execution and perform the desired function. Execution data can be divided into two categories: so-called "temporary" execution data and so-called "permanent" or "fixed" execution data.For example, if the function consists of verifying a PIN code, this function is broken down into three parts: the execution code contains instructions to verify the PIN code, while the permanent execution data contains the reference PIN code and the number of attempts remaining, and the temporary execution data contains the PIN code being verified.

[0051] The primary platform 210 communicates with applications implemented by the secure element 110 through interfaces or tools 220 (TOOLS) executed by the primary platform. These interfaces or tools 220 may include, among other things: Binary-program interfaces (ABI, Application Binary Interface); registers (VRE, Virtual Register); and memory buffers, or shared memories allowing data exchange between processes via inter-process communication (IPC - Inter Process Communication).

[0052] A binary-program interface is a low-level interface between applications of the secured element and its operating system, or between different parts of an application.

[0053] Registers are memory spaces linked to a hardware function of the secure element and used to temporarily store data, for example when a command is sent to the primary platform 210 of the secure element or during exchanges between processes executed by the primary platform.

[0054] Buffers (or shared memory) are used to store messages before they are used by platform 210 or by applications 231, 232, 233 of the secure element. In practice, buffers are memory spaces allocated in a memory location of element 110, for example, volatile memory to which element 110 has access, such as memory location 114.

[0055] For example, the software architecture 200 includes at least three applications 231, 232, 233 adapted to use the interfaces or tools 220 to implement the primary platform 210. Applications 231, 232, 233 are software applications that utilize the resources of the primary platform. Naturally, the secure element implements a number of applications limited by its computing capacity.

[0056] A secure integrated element 110 ( figure 1) could only run one application at a time in its internal memory and store other applications in external memory, thus limiting the number of applications solely to the external memory. The application must then be loaded into internal memory before it can be executed (or execution can be resumed), and the previous application must be unloaded before it can be used. Conversely, a secure embedded element 150 ( figure 2 ) or 150' ( figure 3) will prioritize the use of its internal memory to store and execute applications, which implies a more limited concept of applications but faster execution because it will be referred to as "in-place" execution, which does not require moving the application. However, it remains possible to combine an embedded security element with external memory and thus combine the benefits of both internal and external memory. Applications 231, 232, and 233 can be adapted to implement all kinds of functionalities. They generally implement digital services from a service provider, for example, an EMV-type payment service or a transit ticketing service. These applications can be combined with another application located in the main processor 121 ( figure 1 ) or 161 ( figures 2 And 3or in another secure environment (Trusted Execution Environment). The processor and the secure environment are better able to interact with the user via a secure user interface (Trusted User Interface). Applications 231, 232, and 233, for example, are suitable for processing commands from communication interfaces, such as a banking transaction using a near-field communication device. These applications can be of various types, for example, a SIM (Subscriber Identity Module) application, a payment application, an application for validating a public transport ticket, etc.

[0057] According to an example of an application type, application 231 (App1) is suitable for being implemented directly by the primary platform 210 (VPP) with the help of interfaces or tools 220. Application 231 is, for example, an application enabling payments by communicating with a Near Field Communication (NFC) device.

[0058] According to another example of an application type, application 232 is a set of instructions 232A (App2) adapted to be executed using a high-level operating system 232H (HLOS1). A high-level operating system is software adapted to implement different applications by providing them with a set of common software functions. The operating system 232H is the only part of application 232 that communicates with the primary platform 210 using interfaces or tools 220. Alternatively, the high-level operating system, along with all the applications attached to it, can also be considered a single application adapted to be implemented by the primary platform 210 using interfaces or tools 220.

[0059] According to another example of an application type, another application 233 is a set of instructions 233A (App3) using a runtime environment 233E (ENV) which itself uses a high-level operating system 233H (HLOS2). The runtime environment is, for example, Java or JavaCard. The operating system 233H and the runtime environment 233E are the only parts of the application 233 that communicate with the primary platform 210 using interfaces or tools 220. Alternatively, the high-level operating system, along with all its associated applications, can also be considered an application suitable for implementation by the primary platform 210.

[0060] The high-level operating systems 232H and 233H, or the applications 232 and 233 themselves if no high-level operating system is present, use virtual images of the available memory for managing execution code and execution data. Thanks to this technique, the high-level operating systems (or applications) do not have direct access to the management of physical memory, whether volatile or non-volatile. In other words, in the described embodiments, the high-level operating systems manage a virtual image of the memory. The mapping of the physical memory allocation between volatile and non-volatile memory is ensured by the low-level operating system(s) 213 in combination with certain HW modules 211. More generally, module 210 is considered to perform the mapping between virtual and physical memory.

[0061] Furthermore, it is considered that an application can be in at least three different states: an active or running state by the primary platform 110; a standby state, meaning that its execution is interrupted but can resume at any time; and an inactive or disabled state, meaning that its execution cannot be restarted without one or more prior operations.

[0062] When an application wakes from sleep mode, it resumes execution from where it left off. It doesn't need to use any special routines to continue processing. From the application's perspective, everything appears as if the application had never been interrupted.

[0063] When an application is disabled, all its data is stored in memory in the same way as for an application in standby mode.

[0064] The implementation of application 231, 232, or 233 is as follows. When an application wants to use a hardware resource of the secure element, that is, one or more components 211 of the primary platform 210, this means that the current operations performed on the fixed data are considered complete. The application can then execute various commands, for example, forcing a write to non-volatile memory. To do this, the application sends a command and / or data to the primary platform 210 via interfaces or tools 220. The command is handled by one or more binary-program interfaces before being sent to the low-level operating systems 213; that is, the command is divided into several operations, each represented by a binary-program interface, virtual registers, or a buffer / shared memory.Data is stored in registers or transmitted via inter-process communication (IPC). Low-level operating systems (213) respond to requests from binary-program interfaces by applying the operations requested by the interfaces to the data stored in the registers. These low-level operating systems then control the components (211) to execute the application's commands.

[0065] Applications 231, 232, and 233 cannot communicate with each other within the secure element. Each application 23x (where x ranges from 1 to the number of applications that can be executed) is unaware of the existence of other applications 23x. In particular, each application's operating system "believes" it is the only one communicating with the outside world. Thus, if applications were to communicate with each other, they would have to do so as if they were communicating from a secure element running one application 23x to another element with another application 23x. However, two sub-applications within the same set or application 233 (an application can contain multiple sub-applications) use packet-switching to communicate with each other using the inter-process communication (IPC) tools. Each application 231, 232, and 233 can, however, communicate with external electronic devices.Packet communication is a method of data transmission in which sent messages are composed of one or more data packets. Each data packet includes a header containing information about the type of communication protocol used, the message sender, the message receiver, the message size, etc. Among the various known packet communication protocols, the secure element is likely to use (be compatible with) different protocols that can be classified, according to the nature of the protocol, in terms of information exchange protocol, application protocol, communication protocol, and physical link. For example, these protocols include: the VNP (Virtual Network Protocol) protocol defined by the "GlobalPlatform Technology Virtual Primary Platform - Network Protocol 1.0.1" standard (or any later version) which corresponds to a protocol for the exchanged information; the SWP (Single Wire Protocol) protocol, defined by the ETSI TS 102 613 UICC standard - Contactless Front-end (CLF) Interface - Physical and data link layer characteristics, which corresponds to a physical link; the communication protocol defined by the ISO7816 standard which covers both the exchange of information, the application protocol, communications and the nature of the physical link (wireless); the HCI (Host Controller Interface) protocol, defined by the ETSI TS 102 612 v12.0 standard (or any later version) which corresponds to an application protocol; the CLT protocol, defined by the ETSI TS 102 613 (UICC - Contactless Front-end (CLF) Interface - Physical and data link layer characteristics 11.0 (or any later version) which corresponds to a communication protocol; the sHDLC (Simplified High-Level Data Link Control) protocol, defined by the ETSI TS 102 613 standard (- UICC - Contactless Front-end (CLF) Interface - Physical and data link layer characteristics); and the I2C and SPI protocols which correspond to physical links.

[0066] Messages can also be transmitted via a memory that acts as a communication bus. In other words, a communication bus can be replaced by a memory in which the data to be transmitted by the sending device is written, and read by the receiving device.

[0067] The VPN protocol is a communication protocol suitable for use within a secure element. It is well-suited for managing message routing within the architecture and also to external devices. It is the preferred communication protocol within a secure element. In one embodiment, the router included in the components (in combination with the low-level operating systems) is configured to handle messages using the VPN protocol.

[0068] The HCI, sHDLC, and CLT protocols conflict with the VPN protocol because they are incompatible, and standards do not define their interaction. This conflict demonstrates that HCI, sHDLC, and CLT are not suitable for managing message routing within the 200 architecture. Therefore, the router included in component 211 cannot handle messages using sHDLC, CLT, and HCI protocols because it lacks the necessary information to properly route messages within the 200 architecture.

[0069] The CLT, sHDLC, and HCI protocols, as well as the protocol defined by ISO7816, are incompatible with VPN. The router included in component 211 (in combination with component 213) is not capable of handling messages using the CLT, sHDLC, HCI, and ISO7816 protocols.

[0070] In the embodiments described below, the aim is to ensure that the secure element (integrated or embedded) manages potential conflicts between applications while isolating the applications from each other. In other words, each application's operating system (or each application without an operating system) believes it is the only one accessing the secure element.

[0071] An embodiment of a communication method between the secure element 110 and the outside world, explaining the operation of the process or software 215, is described in relation to the figure 5 .

[0072] There figure 5 represents, schematically and in block form, a method of implementing communication between two electronic devices.

[0073] More specifically, the figure 5 illustrates, schematically and in block form, a communication process between a secure SE 110 element ( figure 1 ), 150 ( figure 2 ) or 150' ( figure 3 ) and an electronic device 300 (DEVICE).

[0074] The secure element SE is represented by a simplified form of its software architecture 200. The simplified form of the software architecture 200 includes: the primary platform 210 (VPP) consisting of a block 217 (LLOS + HW) representing access to components 211 and low-level operating systems 213, and block 215 (COMM MGT) representing the communication management process or software 215; and three applications 231 (App1), 232 (App2) and 233 (App3).

[0075] The electronic device 300 uses any packet communication protocol (for example, one of those described in relation to the figure 4 ) to communicate with the secured element. Device 300 can be an electronic device external to device 100 ( figure 1 ), 100' ( figure 2 ), 100" ( figure 3) which includes the secure element, or may be an internal element of device 100 ( figure 1 ), 100' ( figure 2 ), 100" ( figure 3 ), distinct from the secure element 110. According to a particular embodiment, the device 300 is a near-field communication device 170 ( figure 3 ) included in the 100" device and adapted to receive communications from electronic devices external to the 100" device.

[0076] A first initialization step, symbolized by an arrow F1 in figure 3Applications 231, 232, and 233 register with software 215. During application registration with software 215, the application sends software 215 a list of the communication protocols it can use (with which it is compatible), the parameters necessary to use the protocols, and also provides software 215 with its routing information. In other words, routing information, a list of compatible communication protocols, and the parameters associated with the protocols are registered with the first application.

[0077] Software 215 is adapted to make a message using a first communication protocol compatible with the communication protocol used by the secure element SE. According to one embodiment, the secure element primarily uses the VNP communication protocol defined in relation to the figure 4In other words, the secure element SE includes, among its components, 211 ( figure 4), at least one router configured to use the VPN communication protocol and adapted to process messages using this protocol by routing them to their destination, such as application 231, 232, or 233. Thus, software 215 is adapted to convert messages using the SWP protocol, the sHDLC protocol, or the communication protocol defined by the ISO7816 standard into messages using the VPN protocol by modifying the headers of the packets constituting the message. Furthermore, software 215, knowing the routing information for the applications, is also adapted to process messages using the HCI or CLT protocols. As mentioned previously, the HCI and CLT protocols are compatible with the VPN protocol but are not adapted to handle message routing.In other words, software 215 specifies the intended (targeted) application of initial messages in a given protocol in the headers of subsequent message packets in a different protocol. When a message using the HCI or CLT protocol is received by the secure element SE, software 215 is adapted to route the message to the application using that communication protocol. Software 215 (in combination with block 217) provides an advantage for device 300. This is because device 300 is not capable of using the VPN protocol and uses its own protocol (SWP, sHDLC, ISO7816, etc.). One advantage of this solution is that software 215 (in combination with 217) can make device 300 believe that there is only one application (231, 232, 233).Indeed, thanks to the information provided during application registration, device 300 is able to combine the information to aggregate it and make it appear as if there is only one application, but one that combines all the "functionalities" of the active / registered applications (231, 232, 233). When a message arrives from device 300, thanks to the routing information, software layer 215 (in combination with 217) is able to route the message to the intended application (while converting the protocol if necessary, as previously mentioned).

[0078] An example of communication between device 300 and the secure element is as follows. Device 300 sends a message intended for an application on the secure element, for example, application 231. This message is initially received by the low-level components and operating systems 217 of the primary platform 210. More specifically, the message is received by the router included in the components of the secure element SE. If the message uses a communication protocol other than VPN, it is sent to software 215 for processing. In one embodiment, all messages can be sent to software 215 for processing. If the message uses a communication protocol compatible with VPN, such as HCI or CLT, the software uses the routing information of applications 231, 232, and 233 to route the message to application 231.If the message uses a communication protocol that is not compatible with the VPN protocol, software 215 converts the message to use the VPN protocol. To do this, it modifies the headers of the packets constituting the message and uses the routing information of applications 231, 232, and 233 to direct the message to application 231.

[0079] In one embodiment, process or software 215 is further adapted to manage conflicts between multiple applications. More specifically, it may happen that several applications use the same communication protocol or parameters that could conflict with the same protocol. During registration, each application would provide a list of the protocols, parameters, and routing information it needs. If this information is incompatible with existing parameters, the application would refuse to register (or modify) those parameters. Software 215 (in combination with 217) could also provide a mechanism for managing conflicts, for example, by identifying which application is causing the conflict so that it can be resolved (for example, by disabling the conflicting application and allowing the registration / modification of the new application).Software 215 (in combination with 217) is adapted to provide received messages to the correct application, particularly thanks to routing information provided by the application.

[0080] In one embodiment, the software 215 is further adapted to erase information relating to an application, namely the list of communication protocols it uses and its routing information, at the application's request. For example, an application may request to deregister itself each time it enters an inactive state.

[0081] Various embodiments and variations have been described. A person skilled in the art will understand that some features of these various embodiments and variations could be combined, and other variations will become apparent to a person skilled in the art.

[0082] Finally, the practical implementation of the described methods and variants is within the reach of the person in the trade, based on the functional indications given above.

Claims

1. Secure element (110; 150; 150') adapted to implementing at least one first application (231, 232, 233), and comprising a circuit (210) adapted to: - recording routing data and a list and parameters of communication protocols compatible with said first application (231, 232, 233); - verifying the compatibility of a first communication protocol used by first messages intended for said first application (231, 232, 233) with the protocols of said list; - converting said first messages into second messages using a second communication protocol, included in said list, if the first protocol is not compatible with at least one of the protocols of said list, said conversion including the modification of headers of the second messages to specify routing information of said first application targeted by the first message; and - directing, based on said modified headers, said second messages to said first application by using the routing information of said first application (231, 232, 233).

2. Method of communication between an electronic device and a secure element (110) adapted to implementing at least a first application (231, 232, 233), the method comprising steps, implemented in the secure element, of: - recording routing information and a list of communication protocols compatible with said first application (231, 232, 233); - verifying the compatibility of a first communication protocol used by first messages intended for said first application (231, 232, 233) with the protocols of said list; - converting said first messages into second messages using a second communication protocol, included in the list, if the first protocol is not compatible with at least one of the protocols of said list said conversion including the modification of headers of the second messages to specify routing information of said first application targeted by the first message; and - directing, based on said modified headers, said second messages to said first application by using the routing data of said first application (231, 232, 233).

3. Element according to claim 1 or method according to claim 2, wherein the first protocols in the list are selected from the group comprising the VNP protocol defined by the standard, the HCI protocol, the SWP protocol, the CLT protocol, the packet communication protocol defined by the ISO7816 standard, the sHDLC protocol, and a communication protocol using an internal timing memory.

4. Element according to claim 1 or 3, or method according to claim 2 or 3, wherein the second protocol is the VNP protocol.

5. Element according to any of claims 1, 3, 4, or method according to any of claims 2 to 4, wherein the secure element further comprises electronic components (211) and low-level operating systems (213).

6. Element or method according to claim 5, wherein said first application (231, 232, 233) is implemented by using said electronic components (211) and said low-level operating systems (213).

7. Element according to any of claims 1, 3 to 6, or method according to any of claims 2 to 6, wherein the secure element is adapted to implementing at least one second application (231, 232, 233).

8. Element or method according to claim 7, wherein the first messages are directed to said first application (231, 232, 233) even if said second application (231, 232, 233) uses the same communication protocols as the first application (231, 232, 233).

9. Element according to any of claims 1, 3 to 8, or method according to any of claims 2 to 8, wherein the list of the routing data and of the communication protocols of said first application (231, 232, 233) is erased or modified if said first application (231, 232, 233) requests it.