Secure element

Abstract

Secure Element This description relates to a secure element (500) and a communication method comprising: at least one operating system having at least one application associated with a register; a buffer; and a router having a software layer adapted to: direct first messages using a first protocol and intended for said application to said buffer, and direct second messages using a second protocol different from the first protocol and intended for said application to said register. Figure for the abbreviation: Fig. 6

Description

Title of the invention: Secure element Technical field

[0001] The present description relates generally to electronic devices, and more particularly to electronic devices adapted to process secret data. More particularly, the present description relates to the communication of a secure element with other electronic devices. Prior art

[0002] There are more and more electronic devices adapted to provide digital services. These digital services use cryptographic mechanisms where it is necessary to protect secret data that is of great importance. The integrity of the content is also very important, in fact, unlike an encryption (or signature) key, an identification number must not be able to be modified but it must be freely accessible. To this end, electronic devices are called upon to guarantee the confidentiality and integrity of the data.

[0003] A secure element is an electronic device, autonomous or not, adapted to process secret data securely, that is to say without this secret data being accessible or deduced, for example by side channel attacks 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. Summary of the invention

[0005] There is a need for secure elements adapted to communicate effectively with other electronic devices.

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

[0007] An embodiment of a first aspect provides a secure element comprising: - at least one operating system comprising at least one application with which a register is associated; - a buffer memory; and - a router whose software layer is adapted to: - directing first messages using a first protocol and intended for said application to said buffer; and - directing second messages using a second protocol different from the first protocol and intended for said application to said register.

[0008] An embodiment of the first aspect provides a method of communication between an electronic device and a secure element comprising at least one operating system comprising at least one application with which a register, a buffer memory and a router are associated, the router implementing a software layer comprising the following steps: - directing first messages using a first protocol and intended for said application to said buffer; and - directing second messages using a second protocol different from the first protocol and intended for said application to said register.

[0009] According to an embodiment of the first aspect, the first protocol is implemented by a device external to the secure element.

[0010] According to an embodiment of the first aspect, the first protocol is the VNP protocol defined according to the Global Platform Technology - Virtual Primary Platform - Network Protocol 1.0.1 standard or later.

[0011] According to an embodiment of the first aspect, 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.

[0012] According to an embodiment of the first aspect, said first and second messages are composed of data packets of a packet communication method.

[0013] According to an embodiment of the first aspect, said software layer is adapted to modify headers of the data packets of said second messages.

[0014] According to an embodiment of the first aspect, said second messages originate from a near field communication device.

[0015] According to an embodiment of the first aspect, said first and second messages are intended for applications adapted to be implemented by a high-level operating system of the secure element.

[0016] According to an embodiment of the first aspect, the element is adapted to implement at least two applications.

[0017] According to an embodiment of the first aspect, the element or method is adapted to direct said second messages to the application among said at least two applications for which said second messages are intended.

[0018] According to an embodiment of the first aspect, said software layer manages a list of patterns provided by the applications allowing the routing of said protocol.

[0019] According to an embodiment of the first aspect, the secure element is embedded in an electronic system.

[0020] According to an embodiment of the first aspect, the secure element is integrated into an electronic system.

[0021] An embodiment of a second aspect provides a secure element comprising: - a router managing first messages using a first communication protocol between applications of the secure element and the exterior of the secure element; and - a software layer performing processing at the router level and adapted to: - check the compatibility of a second communication protocol, different from the first, with which second messages are received; - in the absence of compatibility, convert the second messages into the first communication protocol; and - transmit the second messages to said router.

[0022] An embodiment of the second aspect provides a method of communication between a secure element and the exterior of the secure element, the secure element comprising a router managing first messages using a first communication protocol between applications of the secure element and the exterior, the method comprising steps, executed by a software layer at the router, of: - verification of the compatibility of a second communication protocol, different from the first, with which second messages are received; - in the absence of compatibility, conversion of the second messages into the first communication protocol; and - transmission of the second messages to said router.

[0023] According to an embodiment of the second aspect, the software layer is a destination virtual host for the applications.

[0024] According to an embodiment of the second aspect, the first protocol is implemented by a device external to the secure element.

[0025] According to an embodiment of the second aspect, the first protocol is the VNP protocol defined according to the Global Platform Technology - Virtual Primary Platform - Network Protocol 1.0.1 standard or later.

[0026] According to an embodiment of the second aspect, 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.

[0027] According to an embodiment of the second aspect, said first and second messages are composed of data packets of a packet communication method.

[0028] According to an embodiment of the second aspect, said software layer is adapted to modify headers of the data packets of said second messages.

[0029] According to an embodiment of the second aspect, said second messages originate from a near field communication device.

[0030] According to an embodiment of the second aspect, said first and second messages are intended for applications adapted to be implemented by a high-level operating system of the secure element.

[0031] According to an embodiment of the second aspect, the element is adapted to implement at least two applications.

[0032] According to an embodiment of the second aspect, said software layer is, in addition, adapted to direct said second messages to the application among said at least two applications for which said second messages are intended.

[0033] According to an embodiment of the second aspect, said software layer has a routing table allowing the conversion of a message intended for a given application.

[0034] According to an embodiment of the second aspect, said software layer uses an injective function allowing the conversion of a message intended for a given application.

[0035] According to an embodiment of the second aspect, said software layer informs a device separate from the secure element of the presence of an additional application when creating a channel to this same software layer.

[0036] According to an embodiment of the second aspect, the secure element is embedded in an electronic system.

[0037] According to an embodiment of the second aspect, the secure element is integrated into an electronic system. Brief description of the drawings

[0038] These characteristics and advantages, as well as others, will be explained in detail in the following description of particular embodiments given without limitation in relation to the attached figures among which:

[0039] [Fig.l] represents, schematically and in the form of blocks, an example of an electronic device of the type to which the described embodiments apply;

[0040] [Fig. 2] represents, schematically and in the form of blocks, another example of an electronic device of the type to which the described embodiments apply;

[0041] [Fig. 3] represents, schematically and in block form, yet another example of an electronic device of the type to which the described embodiments apply;

[0042] [Fig.4] represents, schematically and in the form of blocks, a mode of rea development of a software architecture of a secure element of an electronic device of the type described in relation to figures 1 to 3; and

[0043] [Fig.5] represents, schematically and in the form of blocks, an embodiment of a communication between two electronic devices;

[0044] [Fig.6] represents, schematically and in the form of blocks, another embodiment of communication between two electronic devices. Description of the embodiments

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

[0046] For the sake of clarity, only the steps and elements useful for understanding the described embodiments have been shown and are detailed.

[0047] Unless otherwise specified, when referring to two elements connected to each other, this means directly connected without intermediate elements other than conductors, and when referring to two elements connected (in English "coupled") to each other, this means that these two elements can be connected or be connected by means of one or more other elements.

[0048] In the following description, when reference is made to absolute position qualifiers, such as the terms "front", "back", "top", "bottom", "left", "right", etc., or relative position qualifiers, such as the terms "above", "below", "upper", "lower", etc., or to orientation qualifiers, such as the terms "horizontal", "vertical", etc., reference is made unless otherwise specified to the orientation of the figures.

[0049] Unless otherwise specified, the expressions "about", "approximately", "substantially", and "of the order of" mean to within 10%, preferably to within 5%.

[0050] [Fig.l] represents, schematically and in block form, an example of an electronic device 100 (SOC) of the type to which the described embodiments apply.

[0051] The device 100 is an electronic device formed on a single chip (System On Chip - SOC). The device 100 comprises a secure element 110 which, in this example, is integrated (iSE - integrated Secure Element). The secure element 110 is a secure element integrated into the device 100, i.e. which can have autonomous operation in the device 100. According to an alternative embodiment, the secure element 110 uses certain hardware resources of the device 100 to operate, such as memories, circuits implementing specific functionalities, etc.

[0052] The integrated secure element 110 is an electronic circuit manipulating data secret data which are, for example, encrypted. The secure element 110 comprises: - at least one processor 111 (SE CPU) adapted to process 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 (NVM SE); - a communication circuit 116 (COMM) adapted to manage the transmissions of data and commands between the secure element 110 and the rest of the device 100; and - a communication bus 117 (SE BUS) connecting all the elements of the secure element 110.

[0053] 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 modem of the system on chip 100, another bus of the SWP (Single Wire Protocol) type connected to a near field communication (NFC) device.

[0054] The processor 111 is used to process commands and data from the 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 in memory of the data and commands, thus the processor never has direct access to the memories 114 and 115. As an example, the circuit 112 can, for example, be used to allocate memory spaces of a volatile memory or a non-volatile memory to certain applications implemented by the integrated secure element.

[0055] The circuits 113 may include a multitude of types of circuits and components, functions allowing the copying of data to external memories, cryptographic coprocessors, etc.

[0056] The communication circuit 116 may serve as a data reception and transmission chain for the secure element 110. The circuit 116 may comprise data reception circuits, data encryption and / or decryption circuits, one or more routers, data conversion circuits. The device 100 may comprise only the secure element 110, but may also optionally comprise: - one or more processors 121 (SOC CPU) adapted to process data; - one or more circuits 122 (FUNCTION) adapted to implement different features 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 commands and data to be exchanged and transmitted to all the elements mentioned above.

[0057] For reasons of size and compactness, the device 100 may, in addition, be adapted to store data in one or more external memories. More particularly, the device 100 may 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 further comprises interface circuits adapted to communicate with the external memories. More particularly, the device 100 may comprise, 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.

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

[0059] [Fig.2] represents, schematically and in the form of blocks, another example of electronic device 100' of the type to which the described embodiments apply.

[0060] The device 100' comprises various circuits or electronic chips including: - an embedded secure element (eSE) 150 constituting a secure environment (TRE - Tampered Resistant Element); - a main processor 161 (Main CPU); - a modem type communication circuit 163 (Modem); and - a near field communication circuit 165 (NFC controller).

[0061] The embedded secure element 150 consists of a single chip and integrates, for example: - a secure processor 151 (Secure CPU); - a hardware cryptographic processor 152 (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 buses 155 (Buses) for communication between the different constituents of the element 150.

[0062] The element 150 further integrates communication interfaces with the outside according to various communication protocols, for example: - a 156 (I2C / SPI HW) interface of I2C or SPI type for communication with the external processor 161; - a 157 (ISO7816) communication interface according to the ISO7816 standard with the 163 modem; and - an interface 158 (S WP) of type S WP for communication with the NFC controller 165.

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

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

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

[0066] [Fig. 3] shows, schematically and in block form, yet another example of an electronic device 100" of the type to which the described embodiments apply.

[0067] In this example, it is assumed that the embedded secure element is integrated with a near-field communication controller on the same chip 180. Thus, the integrated circuit or chip 180 comprises: - an embedded secure element 150' (TRE) including the same elements as element 150 of [Fig.2] with the exception of interface 158, namely: - a secure processor 151 (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 buses 155 (Buses) for communication between the different constituents of the element 150; - an interface 156 (I2C / SPI HW) of I2C or SPI type for communication with the external processor 161 (Main CPU); and - a 157 (ISO7816) communication interface 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 radio frequency transmission / reception 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 the device 100".

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

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

[0070] Alternatively, the secure element 150' and the controller can communicate via their internal SWP communication cells (not shown). This makes it possible to keep the format of the SWP exchanges (and the protocols implemented thereon) without having the constraints (such as noise, bus speed limitation, etc.).

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

[0072] [Fig.4] represents, schematically and in the form of blocks, a mode of rea lization of a software architecture 200 of a secure element of an electronic device of the type described in relation to figures 1 to 3.

[0073] Unless otherwise specified, the expression "secure element" hereinafter designates indifferently an embedded secure element or an integrated secure element. Thus, the software architecture 200 of the secure element SE can be implemented in any one of the elements 110, 150 or 150' of the preceding figures.

[0074] The architecture 200 comprises a primary platform 210 (VPP), generally referred to as a 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, Low Level Operating System). According to one embodiment, the primary platform 210 further comprises a circuit adapted to implement communication management software or process 215 (COMM MGT) whose operation is described in relation to [Fig. 5].

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

[0076] The low-level operating systems 213 are software adapted to implement the components 211 to execute commands received from the applications implemented by the secure element. For example, the low-level operating systems 213 comprise all or part of the driver software of the components 211.

[0077] A low-level operating system 213 is composed of execution code (or executable code) and execution data. The execution code contains instructions allowing the execution of the program functions. By definition, the instructions are invariable for a given program, except for an update of the program which then modifies the instructions. The execution data is used by the execution code to contextualize the execution and carry out the desired function. The 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 decomposed into three parts, the execution code contains instructions for verifying the PIN code while the permanent execution data contains the reference PIN code and the number of remaining attempts and the temporary execution data contains the PIN code subject to verification.

[0078] The primary platform 210 communicates with applications implemented by the secure element 110 via 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 - storage buffers, or buffer memories, or shared memories allowing the exchange of data between processes via inter-process communications (IPC - Inter Process Communication).

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

[0080] The 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.

[0081] Buffer memories (or shared memories) are used to store messages before their use by the platform 210 or by applications 231, 232, 233 of the secure element. In practice, the buffer memories are memory spaces allocated in a memory of the element 110, for example a volatile memory to which the element 110 has access, such as the memory 114.

[0082] By way of example, the software architecture 200 comprises at least three applications 231, 232, 233 adapted to use the interfaces or tools 220 to implement the primary platform 210. The applications 231, 232, 233 are software using the resources of the primary platform. Of course, the secure element implements a number of applications within the limit of its computing capacities.

[0083] An integrated secure element 110 ([Fig. 1]) could execute only one application at a time in its internal memories and save the other applications in external memories, which would allow having a number of applications limited only by the external memories. It is then necessary to first load the application into the internal memories before executing it (or resuming execution) and unload the previous application before being able to use it. Conversely, an embedded secure element 150 ([Fig. 2]) or 150' ([Fig. 3]) will favor the use of its internal memories to store and execute the applications, which implies a more limited notion of applications but a faster execution because we will speak of an "in place" execution which does not require moving the application.It remains possible, however, to combine an embedded secure element with external memories and therefore to combine the benefit of internal and external memories. The applications 231, 232, 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 transport ticket. These applications can be combined with another application located in the main processor 121 ([Fig.l]) or 161 (figures 2 and 3) or 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).The applications 231, 232, 233 are, for example, adapted to process commands originating from communication interfaces, such as, for example, a banking transaction using a near-field communication device. These applications may 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.

[0084] According to an example of application type, the application 231 (Appl) is adapted to be implemented directly by the primary platform 210 (VPP) with the help of the interfaces or tools 220. The application 231 is, for example, an application allowing to make payments by communicating with a Near Field Communication (NFC) device.

[0085] According to another example of an application type, the 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 the application 232 to communicate with the primary platform 210 with the help of the interfaces or tools 220. Alternatively, it can also be considered that the high-level operating system, as well as all the applications attached to it, are a single application adapted to be implemented by the primary platform 210 with the help of the interfaces or tools 220.

[0086] According to another example of application type, another application 233 is a set of instructions 233A (App3) using an execution environment 233E (ENV) which itself uses a high-level operating system 233H (HLOS2). The execution environment is for example of the Java or JavaCard type. The operating system 233H and the execution environment 233E are the only parts of the application 233 to communicate with the primary platform 210 with the help of the interfaces or tools 220. Alternatively, it can also be considered that the high-level operating system, as well as all the applications attached to it, are an application adapted to be implemented by the primary platform 210.

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

[0088] 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 sleep state, that is to say that its execution is interrupted but that it can resume at any time; and - an inactive or deactivated state, that is to say that its execution cannot be restarted without one or more prior operations.

[0089] When an application wakes up to be executed again, it resumes execution where it left off. It does not need to use any special routine to continue its processing. From the application's point of view, everything appears as if the application has not been interrupted.

[0090] When an application is deactivated, all of its data is stored in memory in the same way as for a sleeping application.

[0091] The implementation of the application 231, 232, or 233 is as follows. When an application wishes to use a hardware resource of the secure element, i.e., one or more components 211 of the primary platform 210, this means that the current operations executed on the fixed data are considered to be completed. The application can then execute different commands, for example, force a write to a non-volatile memory. For this, the application sends a command and / or data to the primary platform 210 via the 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, i.e., the command is divided into several operations each represented by a binary-program interface or virtual registers or a buffer memory / shared memory.Data is stored in registers or transmitted via inter-process communications (IPC). Low-level operating systems 213 respond to requests from binary-to-program interfaces by applying the operations requested by the binary-to-program interfaces to the data stored in the registers. Low-level operating systems 213 then control components 211 to execute what the application requests.

[0092] The applications 231, 232, 233 cannot communicate with each other inside the secure element. Each application 23x (x varying from 1 to the number of applications likely to be executed) does not know of the existence of the other applications 23x. In particular, each operating system of an application "believes" that it is the only one communicating with the outside. Thus, if the applications had to communicate with each other, they would have to do so as if they were discussing from a secure element executing an application 23x to another element with another application 23x. However, two sub-applications of the same set or application 233 (an application may contain several sub-applications) use packet communication methods to communicate with each other using the IPC tools for inter-process communication. Each application 231, 232, 233 can, for its part, communicate with external electronic devices.Packet communication is a . data transmission method in which sent messages are composed of one or more data packets. Each data packet includes a header containing information relating to 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 which can be classified, depending on the nature of the protocol, in terms of exchanged information protocol, application protocol, communication protocol, 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 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 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 vl2.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 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.

[0093] 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 are written by the transmitting device, and read by the receiving device.

[0094] The VNP protocol is a communication protocol adapted to operate for communications of a secure element. It is a protocol adapted to manage the routing of messages within the architecture 200 and also to external devices. It is the preferred communication protocol in a secure element. According to one embodiment, the router included in the components 211 (in combination with the low-level operating systems 213) is a router configured to process messages using the VNP protocol.

[0095] The HCI, sHDLC and CLT protocols are protocols that conflict with the VNP protocol, these protocols not being compatible, the standards do not define the interaction between the two. The result of this conflict shows that the HCI, sHDLC and CLT protocols are not suitable for managing the routing of messages within the architecture 200. Thus, the router included in the components 211 cannot support a message using the sHDLC, CLT and HCI protocols because there is no information to correctly route the messages within the architecture 200.

[0096] The CLT, sHDLC and HCI protocols, and the protocol defined by the ISO7816 standard are protocols that are not compatible with the use of the VNP protocol. The router included in the components 211 (in combination with 213) is not capable of supporting a message using the CLT, sHDLC, HCI and ISO7816 protocols.

[0097] In the embodiments described below, it is sought to ensure that the secure element (integrated or embedded) manages possible conflicts between the applications while isolating the applications from each other. In other words, each operating system of an application (or each application without an operating system) believes that it is the only one to access the secure element.

[0098] [Fig.5] represents, schematically and in the form of blocks, an embodiment of communication between two electronic devices.

[0099] [Fig. 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 ([Fig. 1]) or 161 (figures 2 and 3) and a device 402 (OTHER) which is not compatible with the VNP protocol, and which uses different packet communication protocols. This is, for example, the modem 163 (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. The device 401, 402 may 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).

[0100] The device 401 is adapted to communicate with the secure element 300 by sending messages using the VNP protocol.

[0101] The device 402 is adapted to communicate with the secure element 300 by sending messages using protocols other than the VNP protocol, such as for example the HCI protocol, the SWP protocol, the CLT protocol, the ISO7816 protocol, the sHDLC protocol. The device 402 can, for example, also use an internal timing memory as a physical link carrying the protocol concerned. The device 402 is, for example, a near field communication device, for example For example, an NFC (Near Field Communication) device. This type of device must implement specific standards to enable interoperability (when used with different devices). More specifically, an NFC device will use an NFC (Near Field Communication Controller - NFCC) or a Contactless Front-End (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 CLF and the secure element.

[0102] In the example illustrated in relation to [Fig. 3], the secure element 300 implements two applications 301 (Appl) and 302 (App2). The chain of reception of a message by the secure element 300 is represented in [Fig. 3]. This reception chain comprises: - a circuit 303 (VH) adapted to implement virtual host software; - a router 304 (ROUTER) adapted to process the messages received; - 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.

[0103] When the device 401 sends a message using the VNP protocol to the secure element 300, this message is received by the router 304. Thanks to the header of the data packets of the message, the router 304 is able to determine which application must receive the message thanks to the information present in the VNP protocol. The message then passes through the virtual private platform to be stored in the buffer memory associated with the application which must receive the message, process it and respond to it. The application will look for the message in the buffer memory to use it.

[0104] When the device 402 sends a message not using the VNP protocol to the secure element 300, this message is first received by the circuit 303 adapted to implement the virtual host software or process. This software or process has several functionalities. It allows, in a first step, to modify the communication protocol used by the message to make it usable by the router 304 if this protocol is not compatible with the VNP protocol. The virtual host also allows the message to be directed to the appropriate application.

[0105] We assume an example in which an NFC controller uses the HCI protocol, combined with sHDLC and CLT protocols, as defined in the ETSI TS 102 622 and TS 102 613 standards. We also assume that the applications Appl and App2 of the secure element 300 only interface the VPP layer (and the router). The VPP layer and the associated router then only use the VNP protocol. Initially, the virtual host software will register on the VNP router in order to be seen by the applications Appl and App2 as an NFC host implementing a port (gate) HCI. When the Appl or App2 application creates a VNP pipe to this virtual host software, the virtual host software accepts the creation of the channel and initiates communication between itself and the NFC controller using the protocols defined and understood by the NFC controller. Then, when the Appl or App2 application sends HCI commands to execute instructions on the NFCC via VNP packets, the virtual host software intercepts / receives the VNP packets containing the HCI command and removes the VNP encapsulation to encapsulate the message in one or more sHDLC frames. When messages come back from the NFC controller to the Appl or App2 application, the virtual host software performs the operation in reverse, i.e. by removing the sHDLC information and adding the VNP information (while keeping 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 handle the NFCC controller. Indeed, they would quickly come into conflict. Since each LLOS low-level operating system does not have knowledge of the other LLOS, their respective applications could otherwise introduce incompatible parameters on the NFC controller, rendering the applications of the other application unusable. Furthermore, if a contactless message arrived through the antenna of the NFC controller, it would have no way of identifying the application that should perform the command processing. For example, if a link already exists between the application App1 and the NFC controller, the virtual host software then refuses to create a link between the application App2 and the NFC controller.Once the link with the Appl application is removed (e.g., the task is completed or the pipe between App1 and the virtual host software is deleted / closed), the virtual host software allows the link between the App2 application and the NFC controller to be created. Subsequently, if the Appl application wants 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 terminated.

[0106] Alternatively, the virtual host software can inform the NFC controller of the presence of several low-level operating systems LLOS (therefore several applications Appl, App2), which makes it possible to have several links between the NFC controller and the applications. According to this variant, the virtual host software informs the NFC controller that a new low-level operating system is available when creating the channel between the application of this new operating system and the virtual host software. During exchanges between the NFC controller and the virtual host software, the two devices add information to identify the application of the low-level operating system targeted by the command. In order to act as a gateway between the two protocols (mainly when there are several applications), the host software virtual has an internal routing table, allowing data translation. Alternatively, it uses an injective function between the identifier of the NFC controller and the targeted application (two distinct identifiers cannot concern the same application).

[0107] Optionally, the software may also allow the state of an application to be modified, for example to move it from an inactive or standby state to an active state so that it is alerted to receive a message. Once the message has been processed by the virtual host software, it follows the same path as a message sent by the device 401. In other words, the router 304 receives the message and directs it to the correct application. The message then passes through the virtual private platform to be stored in the buffer memory associated with the application that is to receive the message. The application will retrieve the message from the buffer memory to use it.

[0108] Optionally, the software can make it possible to manage a list of access and data exchange authorizations between the different applications, the different environments, and / or the different operating systems to authorize, or not, communications.

[0109] An advantage of this embodiment is that it allows a message using a communication protocol other than the VNP protocol to be made usable by the secure element.

[0110] [Fig.6] represents, schematically and in the form of blocks, another mode of carrying out communication between two electronic devices.

[0111] [Fig.6] illustrates, schematically and in block form, another mode of rea implementation of a communication method between a secure element 500 (SE) of the type described in relation to the preceding figures, and an electronic device 600 (DEVICE).

[0112] The device 600 uses any packet communication protocol described in relation to [Fig. 2] to communicate with the secure element. The device 600 may be the device in which the secure element 500 is included or an external electronic device. The device 600 is for example a near field communication device.

[0113] In the example illustrated in relation to [Fig.4], the secure element 500 implements an application 501 (Appl). The chain of reception of a message by the secure element 300 is represented in [Fig.5]. This reception chain comprises: - a 502 router (ROUTER); - the virtual primary platform 503 (VPP) of the secure element; - a buffer memory 504 (MEM) associated with the application 501; and - a register 505 (VRE).

[0114] The router 502 is adapted to use the VPN protocol to process and route the messages received to the application 501. When the device 600 sends a message using the VPN protocol, the router 502 directs the message to the application 501. For this, the message passes through the primary platform 503 and is then stored in the buffer memory 504. The application 501 then searches for the message in the buffer memory 504 to use it.

[0115] According to one embodiment, the router 502 (alternatively, the platform 503) is also adapted to direct messages that do not use the VNP protocol into the register 505 rather than to the buffer 504. The register 505 is linked to the application 501. Before being used, a linking operation of the register to the application is carried out. Indeed, the application Appl could register itself on a virtual register VRE (or other means) with the primary virtual primary platform 503 in order to indicate to it that it can receive commands / instructions / information according to a defined protocol (sHDLC, CLT, etc.) and / or from a physical line (SWP, I2C, SPI, ISO7816, etc.). In this implementation, only one application can register itself on the particular register.When information arrives on this channel (logical or physical), the router or VPP platform transmits the information to the application that has registered (without altering the communication protocol used).

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

[0117] In this case, the command is sent to the "default" application or to the currently active application. This implies that the application targeted by the command has been selected by another means (for example, by a channel that used the VNP protocol). In the case of selection by another channel, the application can request / impose its non-de-selection for a certain time (for example 500 ms, 1 sec, etc.) in order to be able to receive and process the next command. If the complete processing of the operation requires several commands, the application could extend the non-de-selection time by requesting it from the VPP layer.

[0118] According to another variant embodiment where the element 500 is adapted to implement more than one application, a register can be linked to the application which is being executed by the secure element 110.

[0119] In this variant, the applications indicate a pattern of their own. The advantage is that if several applications register on the same virtual register, the router 304 or the platform 305 can select the application according to the registered pattern. A default application can continue to execute its processing if the received command does not correspond to any pattern. Of course, the commands following the selection of the application continue to be sent and processed by it.

[0120] An advantage of this embodiment is that it makes it possible to make a message using a communication protocol other than the VNP protocol usable.

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

[0122] Various embodiments and variations have been described. Those skilled in the art will understand that certain features of these various embodiments and variations could be combined, and other variations will occur to those skilled in the art.

[0123] Finally, the practical implementation of the embodiments and variants described is within the reach of those skilled in the art from the functional indications given above.

Claims

Claims

1. A method of communication between an electronic device (600) and a secure element (110; 150; 150'; 500) comprising at least one operating system comprising at least one application with which a register, a buffer memory and a router are associated, the router implementing a software layer comprising the following steps: - directing first messages using a first protocol and intended for said application to said buffer memory; and - directing second messages using a second protocol different from the first protocol and intended for said application to said register, wherein said first and second messages are composed of data packets of a packet communication method and said software layer is adapted to modify headers of the data packets of said second messages.

2. The method of claim 1, wherein the first protocol is implemented by a device external to the secure element.

3. The method of claim 1 or 2, wherein the first protocol is the VNP protocol defined according to the Global Platform Technology - Virtual Primary Platform - Network Protocol 1.0.1 standard or later.

4. Method according to any one of claims 1 to 3, 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.

5. A method according to any one of claims 1 to 4, wherein said second messages originate from a near field communication device.

6. Method according to any one of claims 1 to 5, wherein said first and second messages are intended for applications adapted to be implemented by a high-level operating system of the secure element.

7. Method according to claim 6, in which the element (110; 150; 150'; 500) is adapted to implement at least two applications.

8. The method of claim 7, wherein said software layer is further adapted to direct said second messages to the application among said at least two applications for which said second messages are intended.

9. Method according to claim 8, wherein said software layer manages a list of patterns provided by the applications allowing the routing of said protocol.

10. Secure element (110; 150; 150'; 500) comprising: - at least one operating system comprising at least one application with which a register is associated; - a buffer memory; and - a router whose software layer is adapted to implement the method according to any one of claims 1 to 9.

11. Element according to claim 10, embedded in an electronic system.

12. Element according to claim 10, integrated into an electronic system.

Images