SECURED ELEMENT AND METHOD FOR COMMUNICATION BETWEEN A SECURED ELEMENT AND AN ENVIRONMENT EXTERNAL TO THE 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 low-level transaction routing method based on an execution unit identifier contained in a command, with conversion from an external protocol to an internal protocol and vice versa.

[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; the figure 6 represents, schematically and in block form, another way 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", "about", 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 - Tampered 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 for inter-process communication (IPC).

[0043] Alternatively, the 150' secure element and the controller can communicate via their internal SWP communication cells (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, 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.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. The low-level operating systems (213) then control the components (211) to execute the application's requests.

[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 standard "Global Platform Technology Virtual Primary Platform - Network Protocol 1.0.1" (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 or SPI protocol which correspond to physical links.

[0066] 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.

[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] There figure 5 represents, schematically and in block form, a method of implementing communication between two electronic devices.

[0072] There figure 5 illustrates, for example, an embodiment of communication between a secure element 300 (SE) of the type described in relation to the preceding figures and electronic devices 401 (VNP) compatible with the VNP protocol, for example the main processor 121 ( figure 1 ) or 161 ( figures 2 And 3) and a 402 (OTHER) device that is not compatible with the VPN protocol and uses different packet communication protocols. For example, the 163 modem ( figures 2 And 3 ) which traditionally exchanges with the secure element (for example a subscriber identification module - SIM, Subscriber Identification Module) via an ISO7816 protocol. Device 401, 402 can be the device in which the secure element 300 is included (case of the integrated security module) or a separate electronic device (case of the embedded security module).

[0073] Device 401 is adapted to communicate with secure element 300 by sending messages using the VNP protocol.

[0074] The 402 device is suitable for communicating with the 300 secure element by sending messages using protocols other than VPN, such as HCI, SWP, CLT, ISO7816, and sHDLC. The 402 device can also use internal time-delay memory as a physical link to carry the relevant protocol. The 402 device is, for example, a near-field communication (NFC) device. This type of device must implement specific standards to ensure interoperability (when used with different devices).More specifically, an NFC device will use an NFC (Near Field Communication Controller - NFCC) or a contactless communication head (CLF - Contactless Front-End) with the NCI protocol for interfacing between the NFCC and the main processor and the HCI / CLT / sHDLC protocol for interfacing between the NFCC or the CLF and the secure element.

[0075] In the example illustrated in relation to the figure 3 The secure element 300 implements two applications, 301 (App1) and 302 (App2). The message reception chain for the secure element 300 is represented in figure 3 This receiving chain includes: a circuit 303 (VH) adapted to implement virtual host software; a router 304 (ROUTER) adapted to process received messages; the virtual primary platform 305 (VPP) of the secure element; and two buffer memories 306 (MEM1) and 307 (MEM2) each associated with an application 301, 302.

[0076] When device 401 sends a message using the VPN protocol to secure element 300, this message is received by router 304. Using the message's data packet headers, router 304 can determine which application should receive the message based on the information contained in the VPN protocol. The message then passes through the virtual private platform to be stored in the buffer associated with the application that is to receive, process, and respond to the message. The application then retrieves the message from the buffer for use.

[0077] When device 402 sends a message not using the VPN protocol to secure element 300, this message is first received by circuit 303, which is adapted to implement the Virtual Host software or process. This software or process has several functions. First, it modifies the communication protocol used by the message to make it usable by router 304 if that protocol is not compatible with VPN. The Virtual Host also directs the message to the appropriate application.

[0078] Consider an example where an NFC controller uses the HCI protocol, combined with sHDLC and CLT protocols, as defined in ETSI standards TS 102 622 and TS 102 613. It is further assumed that the App1 and App2 applications of the 300 secure element interface only with the VPP layer (and the router). The VPP layer and the associated router then use only the VPN protocol. Initially, the virtual host software will register itself with the VPN router so that it is seen by the App1 and App2 applications as an NFC host implementing an HCI port (gate). When the App1 or App2 application creates a VPN channel (pipe) to this virtual host software, the virtual host software will accept the channel creation and initiate communication between itself and the NFC controller using the protocols defined and understood by the NFC controller.Next, when application App1 or App2 sends HCI commands to execute instructions on the NFC controller via VPN packets, the virtual host software intercepts / receives the VPN packets containing the HCI command and removes the VPN encapsulation to encapsulate the message in one or more sHDLC frames. For messages returning from the NFC controller to application App1 or App2, the virtual host software performs the reverse operation, removing the sHDLC information and adding the VPN information (while retaining the HCI content). This first type of implementation makes the use of this translation exclusive. In other words, two applications from two different low-level operating systems (LLOS) could not properly manage the NFC controller. Indeed, they would quickly encounter conflicts.Since each low-level operating system (LLOS) is unaware of the other LLOS, their respective applications could otherwise introduce incompatible parameters on the NFC controller, rendering the other application unusable. Furthermore, if a contactless message were to arrive via the NFC controller's antenna, it would have no way to identify the application responsible for processing the command. For example, if a link already exists between application App1 and the NFC controller, the virtual host software will refuse to establish a link between application App2 and the NFC controller. Once the link with application App1 is removed (for example, the task is completed or the pipe between application App1 and the virtual host software is removed / closed), the virtual host software will allow the creation of the link between application App2 and the NFC controller.Subsequently, if the App1 application wishes to access the NFC controller, it must recreate the link to the NFC controller once the link between the App2 application and the NFC controller is completed.

[0079] Alternatively, the virtual host software can inform the NFC controller of the presence of multiple low-level operating systems (LLOS) (and therefore multiple applications, App1, App2), enabling multiple connections between the NFC controller and the applications. In this variant, the virtual host software informs the NFC controller that a new low-level operating system is available when the channel is established between the application of this new operating system and the virtual host software. During communication between the NFC controller and the virtual host software, both devices add information to identify the application of the low-level operating system targeted by the command. To act as a gateway between the two protocols (primarily when there are multiple applications), the virtual host software has an internal routing table that facilitates data translation.Alternatively, it uses an injective function between the NFC controller identifier and the target application (two distinct identifiers cannot relate to the same application).

[0080] Optionally, the software can also allow the state of an application to be modified, for example, switching it from an inactive or sleep state to an active state so that it is alerted to receive a message. Once the message is processed by the virtual host software, it follows the same path as a message sent by the 401 device. In other words, the 304 router receives the message and routes it to the correct application. The message then passes through the virtual private platform to be stored in the buffer associated with the application that is to receive the message. The application retrieves the message from the buffer to use it.

[0081] Optionally, the software can manage a list of access and data exchange permissions between different applications, environments, and / or operating systems to allow, or not, communication.

[0082] One advantage of this embodiment is that it allows the secure element to use a message using a communication protocol other than the VNP protocol.

[0083] There figure 6 represents, schematically and in block form, another way of implementing communication between two electronic devices.

[0084] There figure 6 illustrates, schematically and in block form, another embodiment of a communication process between a secure element 500 (SE) of the type described in relation to the previous figures, and an electronic device 600 (DEVICE).

[0085] The 600 device uses any packet communication protocol described in relation to the figure 2 to communicate with the secure element. Device 600 can be the device containing secure element 500 or an external electronic device. Device 600 is, for example, a near-field communication device.

[0086] In the example illustrated in relation to the figure 4 The secure element 500 implements a 501 application (App1). The message reception chain for the secure element 300 is represented in figure 5 This receiving chain includes: a 502 router (ROUTER); the 503 virtual primary platform (VPP) of the secure element; a 504 buffer (MEM) associated with the 501 application; and a 505 register (VRE).

[0087] Router 502 is designed to use the VPN protocol to process and route incoming messages to application 501. When device 600 sends a message using VPN, router 502 routes the message to application 501. To do this, the message passes through the primary platform 503 and is then stored in buffer 504. Application 501 then retrieves the message from buffer 504 for use.

[0088] In one embodiment, router 502 (or alternatively, platform 503) is also adapted to direct messages that do not use the VPN protocol to register 505 rather than to buffer 504. Register 505 is bound to application 501. Before it can be used, a binding operation is performed between the register and the application. Specifically, application App1 could register itself on a virtual register (VRE) (or other means) with the virtual primary platform 503 to indicate that it can receive commands / instructions / information according to a defined protocol (sHDLC, CLT, etc.) and / or a physical line (SWP, I2C, SPI, ISO7816, etc.). In this implementation, only one application can register on the particular register. When information arrives on this channel (logical or physical), the router or VPP platform transmits the information to the registered application (without altering the communication protocol used).

[0089] According to one embodiment, element 500 could be adapted to implement more than one application. In this case, each application is linked to a particular register by a binding operation.

[0090] In this case, the command is sent to the "default" application or the currently active application. This implies that the application targeted by the command was selected by another means (for example, via a channel using the VPN protocol). In the case of selection via another channel, the application can request / enforce its non-deselection for a certain period (for example, 500 ms, 1 sec, etc.) in order to receive and process the next command. If the complete processing of the operation requires multiple commands, the application could extend the non-deselection time by requesting it from the VPP layer.

[0091] According to another embodiment where element 500 is adapted to implement more than one application, a registry can be linked to the application that is running by secure element 110.

[0092] In this variant, applications specify a unique pattern. The advantage is that if multiple applications register on the same virtual registry, the 304 router or 305 platform can select the application based on the registered pattern. A default application can continue processing even if the received command does not match any pattern. Of course, subsequent commands sent after the application's selection are still processed by that application.

[0093] One advantage of this implementation is that it allows a message using a communication protocol other than the VNP protocol to be usable.

[0094] According to yet another embodiment, the external host device to the secure element, whether this host is virtual (virtual host) or hardware (device host), implements a (first) communication protocol into which messages according to another (second) protocol are converted if the secure element is not compatible with this second protocol.

[0095] 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.

[0096] 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'; 300) comprising: - a router (304) managing first messages using a first communication protocol between applications of the secure element and the outside of the secure element; and - a software layer (303) performing a processing involving a change in physical link between the secure element and the outside of the secure element as well as the adaptation of the packet routing protocol at the router and adapted to: - verifying the compatibility, with the first protocol, of a second communication protocol, different from the first one, with which second messages are received, this verification being performed based on information relative to the type of communication protocol used comprised in headers of the messages; - in the absence of compatibility, converting the second messages into the first communication protocol by removing the VNP encapsulation to encapsulate the message in one or more sHDLC frames; and - transmitting the second messages to said router (304).

2. Method of communication between a secure element (110; 150; 150'; 300) and the outside of the secure element, the secure element comprising a router (304) managing first messages using a first communication protocol between applications of the secure element (110; 150; 150'; 300) and the outside, the method comprising steps, executed by a software layer and involving a change in physical link between the secure element and the outside of the secure element as well as the adaptation of the packet routing protocol at the router, of: - verification of the compatibility, with the first protocol, of a second communication protocol, different from the first one, with which second messages are received this verification being performed based on information relative to the type of communication protocol used comprised in headers of the messages; - in the absence of compatibility, conversion of the second messages into the first communication protocol by removing the VNP encapsulation to encapsulate the message in one or more sHDLC frames; and - transmission of the second messages to said router (304).

3. Element according to claim 1, or method according to claim 2, wherein the software layer is a virtual destination host for the applications (301, 302).

4. Element according to claim 1 or 3, or method according to claim 2 or 3, wherein the first protocol is implemented by a device external to the secure element.

5. Element according to claim 1, 3, or 4, or method according to claim 2 or 4, wherein the first protocol is the VNP protocol defined according to the Global Platform Technology - Virtual Primary Platform - Network Protocol 1.0.1 or subsequent standard.

6. Element according to claim 1, 3 to 5, or method according to any of claims 2 to 5, wherein the second protocol is selected from the group comprising 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.

7. Element according to any of claims 1, 3 to 6, or method according to any of claims 2 to 6, wherein said first and second messages are formed of data packets of a packet communication method.

8. Element or method according to claim 7, wherein said software layer is adapted to changing headers of the data packets of said second messages.

9. Element according to any of claims 1, 3 to 8 or method according to any of claims 2 to 8, wherein said second messages originate from a near-field communication device.

10. Element according to any of claims 1, 3 to 9 or method according to any of claims 2 to 9, wherein said first and second messages are intended for applications adapted to being implemented by a high-level operating system of the secure element.

11. Element or method according to claim 10, wherein the element (110; 150; 150'; 300) is adapted to implementing at least two applications.

12. Element or method according to claim 11, wherein said software layer is further adapted to directing said second messages to the application among said at least two applications for which said second messages are intended.

13. Element or method according to claim 12, wherein said software layer has a routing table allowing conversion of a message intended for a given application.

14. Element or method according to claim 12, wherein said software layer informs a device (402) distinct from the secure element of the presence of an additional application on creation of a channel to this same software layer.

15. Element or method according to claim 1, 3 to 14, or method according to any of claims 2 to 14, wherein the secure element is embedded in an electronic system.

16. Element according to any of claims 1, 3 to 14, or method according to any of claims 2 to 14, wherein the secure element is incorporated in an electronic system.