Secure element

Abstract

Secure Element This description relates to a secure element and a communication method, adapted to implement at least one first application (231, 232, 233), and comprising a circuit adapted to: record routing information and a list and parameters of communication protocols compatible with said first application (231, 232, 233); verify the compatibility of a first communication protocol used by first messages destined for said first application (231, 232, 233) with the protocols in said list; convert said first messages into second messages using a second communication protocol if the first protocol is not compatible with at least one of the protocols in said list; and route said second messages to said first application using the routing information of said first application (231, 232, 233). Figure for the abstract: Fig. 4

Description

Description Title of the invention: Secure flutter element technical field 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 There is a growing number of electronic devices adapted to provide digital services. These digital services use cryptographic mechanisms where it is necessary to protect sensitive data of great importance. The integrity of the content is also crucial; indeed, unlike an encryption (or signature) key, an identification number must not be modifiable but is freely accessible. To this end, electronic devices are required to guarantee the confidentiality and integrity of data. 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. 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. Summary of the invention There is a need for secure components that can communicate effectively with other electronic devices. One embodiment overcomes all or part of the drawbacks of known secure elements. One embodiment provides a secure element suitable for implementation in at least one initial application, and comprising a circuit adapted to: - record routing information and a list and parameters of communication protocols compatible with said first application; - verify the compatibility of a first communication protocol used by first messages intended for said first application with the protocols of said list; - convert the first messages into second messages using a second communication protocol if the first protocol is not compatible with at least one of the protocols from said list; and - to route said second messages to said first application using the routing information of said first application. One embodiment provides a communication method between an electronic device and a secure element suitable for implementation in at least one initial application, the method comprising steps consisting of: - record routing information and a list of communication protocols compatible with said first application; - verify the compatibility of a first communication protocol used by first messages intended for said first application with the protocols of said list; - convert said first messages into second messages using a second communication protocol if the first protocol is not compatible with at least one of the protocols in said list; and - to route said second messages to said first application using the routing information of said first application. According to one embodiment, the first protocols in the list are chosen 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 time-delay memory. According to one embodiment, the secure element aggregates information from different applications to make a device with which it communicates believe that there is only one application combining the different registered or active applications. According to one embodiment, the secure element detects potential conflicts and implements a resolution mechanism when protocols, parameters, or routing information are recorded or modified by an application. According to one embodiment, the second protocol is the VPN protocol. According to one embodiment, the secure element or communication process is adapted to direct said first messages to said first application. According to one embodiment, the secure element further comprises electronic components and low-level operating systems. According to one embodiment, said first application is implemented using said electronic components and said low-level operating systems. According to one embodiment, the secure element is adapted to implement at least one second application. According to one embodiment, the first messages are routed to said first application even if said second application uses the same communication protocols as the first application. According to one embodiment, the list of routing information and communication protocols of said first application is erased or modified if said first application requests it. Brief description of the drawings 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: [Fig. 1] represents, schematically and in block form, an example of an electronic device of the type to which the described embodiments apply; [Fig. 2] represents, schematically and in block form, another example of an electronic device of the type to which the described embodiments apply; [Fig. 3] represents, schematically and in block form, yet another example of an electronic device of the type to which the described embodiments apply; Figure 4 schematically represents, 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 Figures 1 to 3; and [Fig. 5] represents, schematically and in block form, a method of communication between two electronic devices. Description of the implementation methods 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. For the sake of clarity, only the steps and elements useful for understanding the implementation methods described have been represented and are detailed. 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. 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 Orientation qualifiers, such as the terms "horizontal", "vertical", etc., refer, unless otherwise specified, to the orientation of the figures. Unless otherwise specified, the expressions 'approximately', 'roughly', 'significantly', and 'on the order of' mean within 10%, preferably within 5%. Figure [Fig. 1] represents, schematically and in block form, an example of an electronic device 100 (SOC) of the type to which the described embodiments apply. Device 100 is an electronic device formed 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. 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 111 processor (SE CPU) suitable for processing secret data; - a memory management function 112 (MMF) and / or a memory management unit (MMU) (not shown), adapted to manage the reading and writing of data in the memories; - one or more circuits 113 (HW FUNCTION) adapted to implement hardware functionalities (for example 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 manage 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. 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. The processor 111 is used to process commands and data from memories 114 and 115, or other memories included in device 100. The processor 111 uses the memory management circuit 112 as an intermediary for manage the storage in memory of data and commands, so the processor never has direct access to memories 114 and 115. As an example, 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. Circuits 113 can include a multitude of circuit types and components, functions enabling data copying to external memories, cryptographic coprocessors, etc. 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 121 processors (SoC CPU) adapted to process data; - one or more circuits 122 (FUNCTION) adapted to implement different functionalities of device 100; - one or more volatile memories 123 (SOC RAM); - one or more 124 non-volatile memories (NVM SoCs); and - a 125 communication bus (SOC BUS) allowing the exchange and transmission of commands and data to all the elements mentioned above. 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 particularly, 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. 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. Fig. 2 represents schematically and in block form another example of a 100" electronic device of the type to which the described embodiments apply. The 100" device includes various electronic circuits or chips, among which: - an embedded secure element (eSE) 150 constituent a secure environment (TRE —- Tampered Resistant Element); - a main CPU 161; - a modem-type communication circuit 163 (Modem); and - a near field communication circuit 165 (NFC controller). The embedded secure element 150 consists of a single chip and integrates, for example: - a secure CPU (Secure CPU); - a hardware cryptographic CPU (HW Crypto CPU) 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 (Bus) between the different components of element 150. 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; - a 157 (ISO7816) communication interface according to the ISO7816 standard with the modem 163; and - a 158 (SWP) type SWP interface for communication with the NFC 165 controller. The device 100" may include other circuits, integrated or not. For example, the embedded secure element 150 may use one or more external memories (not shown) with which it communicates directly or via the main processor. Unlike an integrated secure element such as element 110 in [fig.1], an embedded secure element 150 is not integrated with the other components of the device 100' and in particular the main application processor. The secure embedded element 150 can however be integrated with a near field communication (NFC) controller. Fig. 3 represents schematically and in block form yet another example of a 100" electronic device of the type to which the described implementation methods apply. 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: - an embedded secure element 150" (TRE) including the same elements as element 150 of [fig.2] except for interface 158, namely: - a secure CPU (Secure CPU); - a hardware cryptographic processor 152 (HW Crypto CPU); - one or more volatile memories 153 (RAM); - one or more non-volatile memories 154 (NVM); - one or more communication buses 155 (Bus) between the different components of element 150: - an I2C or SPI type interface 156 (12C / SPI HW) for communication with the external processor 161 (Main CPU); and - a communication interface 157 (ISO7816) according to the ISO7816 standard with the modem 163 (Modem); and - an NFC 170 controller (NFC Controller) including, for example: - a 171 processor (CPU); - a 172 radio frequency transmission / reception circuit (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 (12C / SPI HW) for communication with the main processor 161 of device 100". 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. 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). 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.). 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. Figure 4 represents schematically and in block form a method of realizing a software architecture 200 of a secure element of an electronic device of the type described in relation to Figures 1 to 3. 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. 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 [Fig. 5]. The components 211 are the hardware resources of the secure element SE (110, [fig.1]; 150, [fig.2]; 150', [fig.3]). The components 211 of the secure element 110 are, for example, one or more processors, for example the processor 111 ([fig.1]) or 151 (figures 2 and 3), one or more memories, for example memories 114 and 115 ([fig.1]) or 153 and 154 (figures 2 and 3), one or more communication devices, such as a communication device allowing direct communication with a Near Field Communication (NFC) device, a short-range communication device using, for example, the Bluetooth standard, biometric sensors, etc. 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. 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 invariable for a given program, except when the program is updated, which then modifies the instructions. 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 that. The temporary execution data contains the PIN code that is subject to verification. 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 - buffer memories, or buffer memories, or shared memories allowing the exchange of data between processes via inter-process communication (IPC - Inter Process Communication). A binary-program interface is a low-level interface between the applications of the secured element and its operating system, or between different parts of an application. 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. 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. 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. An integrated secure element 110 ([fig.1]) could execute only 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 its execution resumed), and the previous application must be unloaded before it can be used. Conversely, an embedded secure element 150 ([fig.2]) or 150' ([fig.3]) prioritizes the use of its internal memory to store and execute applications. This implies a more limited number of applications but faster execution because it is referred to as "in-place" execution, which does not require moving the application. It is still possible, however, to combine an embedded secure element with external memory, thus combining the benefits of both internal and external memory.The ap- . 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 ([Fig. 1]) or 161 (Figures 2 and 3) or in another Trusted Execution Environment. The processor and the Trusted Execution Environment are better able to interact with the user via a Trusted User Interface. Applications 231, 232, and 233 are, for example, adapted to process commands from communication interfaces, such as a banking transaction using a near-field communication device.These applications can be of different types, for example, a SIM (Subscriber Identity Module) application, a payment application, an application allowing the validation of a public transport ticket, etc. 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 to be made by communicating with a Near Field Communication (NFC) device. 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. 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 the applications attached to it, can also be considered an application suitable for implementation by the primary platform 210. 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. 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 state of wakefulness, 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. 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. When an application is disabled, all its data is stored in memory in the same way as for an application in standby mode. 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, force 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.The data, meanwhile, is stored in logs 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 binary-program interfaces to the data stored in the registers. The low-level operating systems (213) then control the components (211) to execute what the application requests. 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 information exchanged; - the SWP (Single Wire 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 standard (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 sSHDLC (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. Messages can also be transmitted via a memory acting 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. 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. 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. The CLT, sHDLC, and HCTI 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, HCTI, and ISO7816 protocols. 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. An embodiment of a communication process between the secure element 110 and the outside, explaining the operation of the process or software 215, is described in relation to [fig.5]. Figure 5 schematically represents, in block form, a method of re- Communication implementation between two electronic devices. In particular, [fig.5] illustrates, schematically and in block form, a communication process between a secure element SE 110 ([fig.1])), 150 ([fig.2]) or 150 ([fig.3]) and an electronic device 300 (DEVICE). 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) composed 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). The electronic device 300 uses any packet communication protocol (for example, one of those described in relation to [Fig. 4]) to communicate with the secure element. The device 300 can be an electronic device external to the device 100 ([Fig. 1]), 100' ([Fig. 2]), 100" ([Fig. 3]) in which the secure element is included, or it can be an internal element of the device 100 ([Fig. 1]), 100" ([Fig. 2]), 100" ([Fig. 3]), separate from the secure element 110. According to a particular embodiment, the device 300 is a near-field communication device 170 ([Fig. 3]) included in the device 100" and adapted to receive communications from electronic devices external to the device 100". In a first initialization step, symbolized by an arrow F1 in [Fig. 3], applications 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. Software 215 is adapted to make a message using a first communication protocol compatible with the communication protocol used by the secure element SE. In one embodiment, the secure element primarily uses the VPN communication protocol defined in relation to [Fig. 4]. In other words, the secure element SE includes, among its components 211 ([Fig. 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. The software 215, defined by the ISO7816 standard, modifies messages using the VPN protocol, for example, by modifying the headers of the packets constituting the message. Furthermore, software 215, knowing the routing information for applications, is also adapted to handle messages using the HCI or CLT protocols. As mentioned previously, the HCI and CLT protocols are compatible with the VPN protocol but are not designed to handle message routing. 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. Indeed, 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 layer 215 (in combination with 217) can make the 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 create the illusion that 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). 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 direct 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. According to one embodiment, process or software 215 is further adapted to Managing 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's registration (or modification) of these parameters would be refused. 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 deliver received messages to the correct application, particularly thanks to the routing information provided by the application. According to one embodiment, the software 215 is further adapted to erase information relating to an application, that is, 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. 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. 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

Demands

1. Method of communication between an electronic device and a secure element (110) suitable for implementing at least a first application (231, 232, 233), the process comprising steps consisting has: - record routing information and a list of protocols communications compatible with said first application (231, 232, 233); - verify the compatibility of a first communication protocol used by initial messages intended for said initial application (231, 232, 233) with the protocols of said list; - convert the aforementioned first messages into second messages using a second communication protocol if the first protocol is not compatible with at least one of the protocols of said list; and - to direct said second messages to said first application using the routing information from said first application (231, 232, 233).

2. A method according to claim !, wherein the first protocols of The list is chosen from the group including the defined VPN protocol by the standard, the HCI protocol, the SWP protocol, the CLT protocol, the packet-switching communication protocol defined by the ISO7816 standard, the sHDLC protocol and a communication protocol using a internal timer memory.

3. Method according to claim !, wherein the secured element (110; 150; 150") aggregates information from different applications for to make a device (300) with which it communicates believe that there is no that a single application combining the different applications enre- gistered or active.

4. Method according to claim 1, wherein the secured element (110; 150; 150") detects potential conflicts and implements a mechanism to resolution during recording or modification of protocols, parameters or routing information by an application (231, 232, 233).

5. A method according to any one of claims 1 to 4, wherein the The second protocol is the VPN protocol.

6. A method according to any one of claims 1 to 5, adapted to to direct said first messages to said first application (231, 232, 233).

7. A method according to any one of claims 1 to 6, wherein The secure element also includes electronic components (211) and low-level operating systems (213).

8. A method according to claim 7, wherein said first application (231, 232, 233) is implemented using said electronic components tronics (211) and said low-level operating systems (213).

9. A method according to any one of claims 1 to 7, wherein the secure element is suitable for implementing at least a second application (231, 232, 233).

10. A method according to claim 9, wherein the first messages are directed to said first application (231, 232, 233) even if said The second application (231, 232, 233) uses the same protocols of communication than the first application (231, 232, 233).

11. | Method according to any one of claims 1 to 10, wherein the list of routing information and communication protocols said first application (231, 232, 233) is deleted or modified if said first application (231, 232, 233) requires it.

12. Secure element (110; 150; 150") suitable for implementation at least a first application (231, 232, 233), and comprising a circuit adapted to implement the process according to any of the claims instructions 1 to 11.