Security element and method

Abstract

Embodiments of the present disclosure relate to security elements and methods. The present invention describes a security element and a communication method, including: a router that manages a first message using a first communication protocol between an application of the security element and the outside of the security element; and a software layer that performs processing at the router level. The software layer is configured to: verify the compatibility of a second communication protocol different from the first communication protocol, where a second message is received using the second communication protocol; in the case of a lack of compatibility, convert the second message into the first communication protocol; and transmit the converted second message to a router application.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims the benefit of French Patent Application No. 2010975, filed on October 27, 2020, which is hereby incorporated herein by reference. Technical Field

[0003] The present disclosure generally relates to electronic devices, and more particularly to electronic devices suitable for processing secret data. More specifically, the present disclosure relates to the communication between a secure element and other electronic devices. Background Art

[0004] There are an increasing number of electronic devices suitable for providing digital services. When it is necessary to protect secret data of high importance, these digital signals use cryptographic mechanisms. In fact, the integrity of the content is also very important. Contrary to cryptographic (or signature) keys, identification numbers should not be able to be modified but should be freely accessible. For this purpose, ensuring the confidentiality and integrity of the data is determined by the electronic device.

[0005] A secure element is an autonomous or non-autonomous electronic device suitable for processing secret data in a secure manner, that is, without accessing or deriving these secret data, for example, through side-channel attacks or penetration. The secure element can be configured to encrypt data, for example.

[0006] It is desirable to be able to at least partially improve certain aspects of the communication between a secure element and other electronic devices. Summary of the Invention

[0007] There is a need for a secure element suitable for efficient communication with other electronic devices.

[0008] Embodiments overcome all or some of the drawbacks of known secure elements.

[0009] Embodiments of a first aspect provide a secure element, including: at least one operating system including at least one application, the application having registers associated with the application; a buffer memory; and a router having a software layer, the software layer being suitable for: guiding a first message using a first protocol and intended for the application to the buffer memory; and guiding a second message using a second protocol different from the first protocol and intended for the application to the registers.

[0010] Embodiments of a first aspect provide a method for communicating between an electronic device and a security element, the security element including: at least one operating system including at least one application, the application having a register, a buffer memory, and a router associated with the application, the router implementing a software layer including: directing a first message using a first protocol and intended for the application to the buffer memory; and directing a second message using a second protocol different from the first protocol and intended for the application to the register.

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

[0012] According to an embodiment of the first aspect, the first protocol is the VNP protocol defined according to the GlobalPlatform Technology - Virtual Master Platform - Network Protocol 1.0.1 or subsequent standards.

[0013] According to an embodiment of the first aspect, the second protocol is selected from the group consisting of: the HCI protocol, the SWP protocol, the CLT protocol, the packet communication protocol defined by the ISO7816 standard, the sHDLC protocol, and the communication protocol using an internal timing memory.

[0014] According to an embodiment of the first aspect, the first message and the second message are formed by data packets of a packet communication method.

[0015] According to an embodiment of the first aspect, the software layer is adapted to modify the header of the data packet of the second message.

[0016] According to an embodiment of the first aspect, the second message originates from a near - field communication device.

[0017] According to an embodiment of the first aspect, the first message and the second message are intended for an application implemented by a high - level operating system of the security element.

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

[0019] According to an embodiment of the first aspect, the element or method is adapted to direct the second message to a selected application among at least two applications, the second message being intended for the selected application among the at least two applications.

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

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

[0022] According to an embodiment of the first aspect, the security element is integrated in an electronic system.

[0023] Embodiments of a second aspect provide a security element comprising: a router that manages first messages of a first communication protocol between an application using the security element and the exterior of the security element; and a software layer that performs processing at the router level and is adapted to verify the compatibility of a second communication protocol different from the first communication protocol, receive a second message using the second communication protocol; in the case of no compatibility, convert the second message into the first communication protocol; and transmit the second message to the router.

[0024] Embodiments of a second aspect provide a method of communicating between a security element and the exterior of the security element, the security element comprising: a router that manages first messages of a first communication protocol between an application using the security element and the exterior of the security element, the method comprising verifying, by a software layer at the router level, the compatibility of a second communication protocol different from the first communication protocol, receiving a second message using the second communication protocol; in the case of no compatibility, converting the second message into the first communication protocol; and transmitting the second message to the router.

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

[0026] According to an embodiment of the second aspect, the first protocol is implemented by a device exterior to the security element.

[0027] According to an embodiment of the second aspect, the first protocol is a VNP protocol defined according to GlobalPlatform Technology - Virtual Master Platform - Network Protocol 1.0.1 or a subsequent standard.

[0028] According to an embodiment of the second aspect, the second protocol is selected from the group consisting of: an HCI protocol, an SWP protocol, a CLT protocol, a packet communication protocol defined by the ISO7816 standard, an sHDLC protocol, and a communication protocol using an internal timing memory.

[0029] According to an embodiment of the second aspect, the first messages and the second message are formed by data packets of a packet communication method.

[0030] According to an embodiment of the second aspect, the software layer is adapted to modify the header of the data packet of the second message.

[0031] According to an embodiment of the second aspect, the second message originates from a near field communication device.

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

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

[0034] According to an embodiment of the second aspect, the software layer is also adapted to direct a second message to an application among at least two applications, the second message being intended for that application among the at least two applications.

[0035] According to an embodiment of the second aspect, the software layer has a routing table that enables the conversion of messages intended for a given application.

[0036] According to an embodiment of the second aspect, the software layer uses an injective function that enables the conversion of messages intended for a given application.

[0037] According to an embodiment of the second aspect, during the creation of a pipeline towards this same software layer, the software layer informs a device different from the security element of the existence of additional applications.

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

[0039] According to an embodiment of the second aspect, the security element is integrated in the electronic system. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] The foregoing features and advantages, as well as other features and advantages, will be described in detail in the following description of a given specific embodiment by way of illustration and not limitation with reference to the accompanying drawings, in which:

[0041] Figure 1 An example of an electronic device of the type to which the described embodiment applies is schematically shown in block form;

[0042] Figure 2 Another example of an electronic device of the type to which the described embodiment applies is schematically shown in block form;

[0043] Figure 3 Yet another example of an electronic device of the type to which the described embodiment applies is schematically shown in block form;

[0044] Figure 4 An embodiment of the software architecture of a security element of an electronic device of the type described in combination with Figures 1 to 3 is schematically shown in block form;

[0045] Figure 5 An embodiment of the communication between two electronic devices is very schematically shown in block form; and

[0046] Figure 6 Another embodiment of the communication between two electronic devices is very schematically shown in block form. DETAILED DESCRIPTION

[0047] In the various figures, like features have been designated by like reference numerals. Specifically, structural and / or functional features common to the various embodiments may have the same reference numeral, and the same structure, dimensions, and material properties may be provided.

[0048] For clarity, only the steps and elements that contribute to an understanding of the embodiments described herein are described and illustrated in detail.

[0049] Unless otherwise specified, when referring to two elements connected together, this means a direct connection without intervening elements other than a conductor, and when referring to two elements coupled together, this means that the two elements are capable of being connected or that they are capable of being coupled via one or more other elements.

[0050] In the following disclosure, unless otherwise specified, when referring 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 orientation qualifiers such as "horizontal", "vertical", etc., the orientation shown in the figures is referred to.

[0051] Unless otherwise specified, the expressions "about", "substantially", "essentially", and "approximately" mean within 10%, and preferably within 5%.

[0052] Figure 1 An example of an electronic device 100 (SOC) of the type to which the described embodiments are applicable is schematically shown in block form.

[0053] Device 100 is an electronic device formed on the same one chip (system-on-chip - SOC). Device 100 includes a security element 110, which in this example is integrated (iSE - integrated security element). Security element 110 is a security element integrated in device 100, i.e., it can operate autonomously in device 100. According to an alternative embodiment, security element 110 operates using certain hardware resources of device 100, such as memory, circuits implementing specific functionality, etc.

[0054] The integrated security element 110 is an electronic circuit that manipulates, for example, encrypted secret data. The security element 110 includes: at least one processor 111 (SE CPU), suitable for processing secret data; a memory management function 112 (MMF) and / or a memory management unit (MMU) (not shown), capable of managing reading data from and writing data to a memory; one or more circuits 113 (HW functions), suitable for implementing the hardware functionality of the security element 110 (such as a cryptographic accelerator, a communication unit, etc.); at least one volatile memory 114 (SE RAM); at least one non-volatile memory 115 (SE NVM); a communication circuit 116 (COMM), suitable for managing the communication of data and control signals between the security element 110 and the rest of the device 100; and a communication bus 117 (SE bus), coupling all elements of the security element 110.

[0055] As a variant, the integrated security element 110 is connected to one or more additional communication buses. For example, the integrated security element may have a bus connected to a modem of the system-on-chip 100 according to the ISO 7816 standard, and another SWP type (single-wire protocol) bus connected to a near-field communication device (NFC).

[0056] The processor 111 is used to process control signals and data originating 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 memory storage of data and the memory storage of control signals, and thus the processor never directly accesses the memories 114 and 115. As an example, the circuit 112 can be used, for example, to allocate the memory space of the volatile memory or the memory space of the non-volatile memory to certain applications implemented by the integrated security element.

[0057] The circuit 113 can include various types of circuits and components, functions enabling data to be copied to an external memory, a cryptographic coprocessor, etc.

[0058] The communication circuit 116 can be used as a data receiving and transmitting link for the security element 110. The circuit 116 can include a data receiving circuit, a data encryption and / or decryption circuit, one or more routers, and a data conversion circuit. The device 100 can include only the security element 110, but can also optionally include: one or more processors 121 (SOC CPU) suitable for processing data; one or more circuits 122 (functions) suitable for implementing 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) enabling the exchange of control signals and data and the transmission of control signals and data to all the previously mentioned elements.

[0059] For reasons of volume and compactness, the device 100 can also be suitable for storing data in one or more external memories. More specifically, the device 100 can be suitable for storing 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 an interface circuit suitable for communicating with the external memory. More specifically, in this case, the device 100 can include an interface circuit 126 (RAM interface) suitable for communicating with the external volatile memory 21, and / or an interface circuit 127 (NVM interface) capable of communicating with the non-volatile memory 22.

[0060] The security element 110 can access the hardware resources of the device 100 to be operated, such as, for example, accessing the circuit 122, accessing the memories 123, 124 or even accessing the memories 21 and 22.

[0061] Figure 2 Another example of an electronic circuit 100' of the type applicable to the described embodiment is schematically shown in block form.

[0062] The device 100' includes: various electronic circuits or chips, among which the embedded security element (eSE) 150 forms a tamper resistant element (TRE); a main processor 161 (main CPU); a modem-type communication circuit 163 (modem); and a near field communication circuit 165 (NFC controller).

[0063] The embedded security element 150 is formed by a single chip and integrates, for example, a security element 151 (security CPU); a hardware cryptographic processor 152 (HW encryption CPU) or a 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 communicating between different components of the element 150.

[0064] The component 150 also integrates interfaces for communicating with the outside according to various communication protocols, such as an I2C or SPI type interface 156 (I2C / SPI HW) for communicating with an external processor 161; an interface 157 (ISO7816) for communicating with a modem 163 according to the ISO7816 standard; and an SWP type interface 158 (SWP) for communicating with an NFC controller 165.

[0065] The device 100' may include other circuits that are integrated or not integrated. For example, the embedded security element 150 may use one or more external memories (not shown), and communicate with the one or more external memories directly or via the main processor.

[0066] Unlike an integrated security element such as Figure 1 the component 110, the embedded security element 150 is not integrated with other components of the device 100', especially the main processor of the application.

[0067] However, the embedded security element 150 may be integrated with a near field communication controller (NFC).

[0068] Figure 3 Another example of an electronic circuit 100" of the type applicable to the described embodiment is schematically shown in block form.

[0069] In this example, it is assumed that the embedded security element is integrated with a near field communication controller on the same chip 180. Accordingly, the integrated circuit or chip 180 includes: an embedded security element 150' (TRE), including elements that are the same as those of Figure 2 the component 150 except for the interface 158, that is, a security element 151 (secure CPU); a hardware cryptographic processor 152 (HW encryption CPU); one or more volatile memories 153 (RAM); one or more non-volatile memories 154 (NVM); one or more buses 155 (bus) for communication between different components of the component 150; an I2C or SPI type interface 156 (I2C / SPI HW) for communicating with an external processor 161 (main CPU); and an interface 157 (ISO7816) for communicating with a modem 163 (modem) according to the ISO7816 standard; and an NFC controller 170 (NFC controller), including, for example, a processor 171 (CPU); a radio frequency transmit / receive circuit 172 (RF analog HW) or an RF analog header; one or more volatile memories 173 (RAM); one or more non-volatile memories 174 (NVM); one or more buses 175 (bus) for communication between different components of the NFC controller; and an interface 176 (I2C / SPI HW) for communicating with the main processor 161 of the device 100".

[0070] The exchange directly between the security element 150' and the controller 170 is transmitted via buses 155 and 175, which are coupled together as appropriate and form a single bus, where the element 150' and the controller 170 can simulate the SWP protocol.

[0071] The security element 150' and the controller can also communicate via their RAMs 153 and 173 via the shared memory 159, thus enabling inter-process communication (IPC - Inter-Process Communication).

[0072] As a variant, the security element 150' and the controller can communicate via their internal SWP communication units (not shown). This enables the format of the SWP exchange (and the format of the protocol implemented thereon) to be maintained without constraints (such as noise, bus speed limitations, etc.).

[0073] Due to the significant development of these functions in electronic devices, the application of near-field communication between security elements (integrated or embedded) is a preferred application.

[0074] Figure 4 Schematically shown in block form is an embodiment of the software architecture 200 of the security element of an electronic device of the type described in conjunction with Figures 1 to 3 the description.

[0075] Unless otherwise specified, the expression "security element" herein refers in different ways to an embedded security element or an integrated security element. Thus, the software architecture 200 of the security element SE can be implemented in any one of the elements 110, 150 or 150' of the previous diagrams.

[0076] The architecture 200 includes a main platform 210 (VPP), commonly referred to as a virtual main platform (VPP), which includes access to the electronic components 211 (HW) of the security element SE and includes one or more low-level operating systems 213 (LLOS). According to an embodiment, the main platform 210 also includes circuitry capable of implementing communication management software or processes 215 (COMM MGT), regarding Figure 5 the description of whose operation.

[0077] The component 211 is the hardware resource of the security element SE (110, Figure 1 ; 150, Figure 2 ; 150', Figure 3 ). The component 211 of the security element 110 is, for example: one or more processors, such as processor 111 ( Figure 1 ) or 151 ( Figure 2 and Figure 3 ); one or more memories, such as memories 114 and 115 ( Figure 1) or 153 and 154( Figure 2 and Figure 3 ); one or more communication devices, such as a communication device enabling direct communication with a Near Field Communication device (NFC); a short-range communication device using, for example, the Bluetooth standard, a biometric sensor, etc.

[0078] The low-level operating system 213 is software suitable for implementing the component 211 to execute control signals received from most of the applications implemented by the security element. As an example, the low-level operating system 213 includes all or part of the driver software of the component 211.

[0079] The low-level operating system 213 is formed by execution code (or executable code) and execution data. The execution code contains instructions enabling the execution of the functions of a program. By definition, the instructions are invariant for a given program, except for updates to the program, which then modify the instructions. The execution data is used by the execution code to contextualize the execution and perform the required functions. The execution data can be divided into two categories. The so-called "temporary" execution data and the so-called "permanent" or "fixed" execution data. For example, if the function includes the verification of a PIN code, then this function is decomposed into three parts, the execution code contains the instructions for the verification of the PIN code, the permanent execution data contains the reference PIN code, and the remaining multiple tests and temporary execution data contain the PIN code submitted for verification.

[0080] The main platform 210 communicates with the applications executed by the security element 110, which has an interface or tool 220 (tool) executed by the main platform. These interfaces or tools 200 may include, among other features, an Application Binary Interface (ABI); registers (VRE, virtual registers); and a storage buffer memory or buffer memory, or may also include a shared memory implementing data exchange between processes via Inter-Process Communication (IPC).

[0081] The Application Binary Interface is a low-level interface between the applications of the security element and its operating system, or a low-level interface between different parts of an application.

[0082] A register is, for example, a memory space linked to the hardware functions of the security element and used for temporarily storing data when a control signal is sent to the main platform 210 of the security element or during the exchange between processes executed by the main platform.

[0083] The buffer memory (or shared memory) is used to store messages before they are used by the platform 210 or by the applications 231, 232, 233 of the security element. In fact, the buffer memory is a memory space allocated in the memory of the element 110 (for example, the volatile memory accessed by the element 110, such as the memory 114).

[0084] As an example, the software architecture 200 includes at least three applications 231, 232, 233 adapted to implement the main platform 210 using an interface or tool 220. The applications 231, 232, 233 are software that uses the resources of the main platform. Of course, the security element implements a large number of applications within its computing power limitations.

[0085] The integrated security element 110 ( Figure 1 ) can execute a single application in its internal memory and record other applications in the external memory at the same time, which will enable a large number of applications limited only by the external memory. The application must be pre-loaded into the internal memory before it can be executed (or resume execution), and the previous application must be unloaded before the application can use it. In contrast, the embedded security element 150 ( Figure 2 ) or 150' ( Figure 3 ) will preferentially use its internal memory to store and execute applications, which implies a more restricted but faster execution concept of the application, because the "in-situ" execution mentioned later does not require replacing the application. However, it is still possible to combine the benefits of the embedded security element with the external memory and thus combine the internal memory with the external memory. The applications 231, 232, 233 can be adapted to implement any type of functionality. They typically implement digital services of service providers, such as payment services of the EMV or transport ticket type. These applications can be combined with another application located in the main processor 121 ( Figure 1 ) or 161 ( Figure 2 and 3 ) or another secure environment (trusted execution environment). The processor and the secure environment are more capable of interacting with the user via a trusted user interface. The applications 231, 232, 233 are, for example, adapted to process control signals originating from a communication interface, such as a bank transaction using a near-field communication device. The applications can be of different types, such as SIM (Subscriber Identity Module) applications, payment applications, applications that enable the verification of public transport tickets, etc.

[0086] According to an example of the application type, the application 231 (App1) can be directly implemented by the main platform 210 (VPP) with the help of an interface or tool 220. The application 231 is, for example, an application that enables payment by communicating with a near-field communication (NFC) device.

[0087] According to another example of an application type, an application 232 is a set of instructions 232A (App2) adapted to be executed by using a high-level operating system 232H (HLOS1). The high-level operating system is software adapted to implement different applications by providing a set of common software functions. The operating system 232H is the only part of the application 232 that communicates with the main platform 210 by means of an interface or tool 220. As a variant, it can also be considered that the high-level operating system and all applications attached thereto are a single application adapted to be implemented by the main platform 210 by means of an interface or tool 220.

[0088] According to another example of an 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 Java or JavaCard type. The operating system 233H and the execution environment 233E are the only parts of the application 233 that communicate with the main platform 210 by means of an interface or tool 220. As a variant, it is also possible to consider that the high-level operating system and all the applications attached to it are applications that can be implemented by the main platform 210.

[0089] If no high-level operating system is present, the high-level operating system 232H and 233H or the applications 232 and 233 themselves use a virtual image of memory that can be used for management of execution code and management of execution data. Due to this technology, the high-level operating system (or application) does not have direct access to the management of volatile or non-volatile physical memory. In other words, in the described embodiment, the high-level operating system manages a virtual image of memory. The correspondence of the physical distribution in volatile and non-volatile memory is ensured by (one or more) low-level operating systems 213 in combination with certain HW modules 211. More generally, consider making the module 210 correspond to virtual and physical memory.

[0090] Furthermore, it is considered that an application can be in at least three different states: an active state or a state in which it is run by the host platform 110; a standby state, in which its execution is interrupted but it can be resumed at any time; and a deactivated or deactivated state, in which its execution cannot be restarted without one or more prior operations.

[0091] When the application makes the standby state execute again, it resumes its execution at the point where it was stopped. No specific routine needs to be used to continue its processing. From the perspective of the application, everything behaves as if the application has not been interrupted.

[0092] When an application is deactivated, all its data is stored in memory in the same way as for an inactive application.

[0093] The implementation of applications 231, 232, or 233 is as follows. When an application desires to use the hardware resources of the secure element (i.e., one or more components 211 of the main platform 210), this means that the current operation being performed on the fixed data is considered to end. The application can then execute different control signals, such as forcing a write into the non-volatile memory. For this purpose, the application sends the control signals and / or data to the main platform 210 via the interface or tool 220. The control signals are the responsibility of one or more application binary interfaces before being sent to the low-level operating system 213, i.e., the control signals are divided into multiple operations, each operation being represented by an application binary interface or a virtual register or a buffer memory / shared memory. The data is stored in a register or transmitted via inter-process communication (IPC). The low-level operating system 213 responds to the requests of the application binary interface by applying the operations requested by the application binary interface to the data stored in the register. The low-level operating system 213 then drives the component 211 to execute what is requested by the application.

[0094] Applications 231, 232, 233 are not able to communicate together within the secure element. Each application 23x (where x varies from 1 to the number of applications likely to be executed) is unaware of the existence of the other applications 23x. Specifically, each operating system of the applications "believes" that it is the only one communicating with the outside. Thus, if the applications have to communicate together, then this should be done as discussed towards the secure element executing the application 23x with respect to another element having the application 23x. However, two sub-applications or applications 233 of the same set (an application can include multiple sub-applications) use a grouped communication method to communicate together by using IPC (Inter-Process Communication) tools. Each application 231, 232, 233 can communicate with an external electronic device. Grouped communication is a data transmission method in which the message being sent is formed by one or more data packets. Each data packet includes a header which includes data related to the type of communication protocol used, related to the transmitter of the message, related to the receiver of the message, related to the size of the message, etc. Among different known grouped communication protocols, the secure element may use different protocols (be compatible with different protocols), which can be classified according to the nature of the protocol based on the data exchange protocol, application protocol, communication protocol, physical link. For example, these protocols include: the VNP protocol (Virtual Network Protocol), defined by the "GlobalPlatform Technology Virtual Master Platform - Network Protocol 1.0.1" standard (or any subsequent version), corresponding to the data exchange protocol; the SWP protocol (Single Wire Protocol), defined by the ETSI TS102613 UICC - Contactless Front End (CLF) Interface - Physical and Data Link Layer Characteristics standard, corresponding to the physical link; the communication protocol, defined by the ISO7816 standard, covering the nature of data exchange, application protocol, communication, and physical link (wireless); the HCI (Host Controller Interface) protocol, defined by the ETSI TS102 612v12.0 standard (or any subsequent version), corresponding to the application protocol; the CLT protocol, defined by the ETSI TS102 613 UICC - Contactless Front End (CLF) Interface - Physical and Data Link Layer Characteristics 11.0 standard (or any subsequent version), corresponding to the communication protocol; the sHDLC protocol (Simplified High-Level Data Link Control), defined by the ETSI TS102 613 (UICC - Contactless Front End (CLF) Interface - Physical and Data Link Layer Characteristics) standard; and the I2C or SPI protocol, corresponding to the physical link.

[0095] The message can also be transmitted via a memory acting as a communication bus. In other words, the communication bus can be replaced by a memory which has the data to be transmitted by the transmitting device written into it and read by the receiving device.

[0096] The VNP protocol is a communication protocol applicable to communication operations for a secure element. The protocol is capable of managing the routing of messages within the architecture 200 and also towards external devices. This is the preferred communication protocol in the secure element. According to an embodiment, the router included within the component 211 (combining the low-level operating system 213) is a router configured to process messages using the VNP protocol.

[0097] The HCI, sHDLC, and CLT protocols are protocols that conflict with the VNP protocol because these protocols are not compatible and the standard does 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. Therefore, the router included in the component 211 cannot use the sHDLC, CLT, and HCI protocols to support messages because there is no data for properly routing messages within the architecture 200.

[0098] The CLT, sHDLC, and HCI protocols, as well as the protocols defined by the ISO7816 standard, are protocols that are incompatible with the use of the VNP protocol. The router included in the component 211 (combination 213) cannot use the CLT, sHDLC, HCI, and ISO7816 protocols to support messages.

[0099] In the embodiments described below, it is desired to confirm possible conflicts between applications in a secure element (integrated or embedded) while isolating the applications from each other. In other words, each operating system of the applications (or each application without an operating system) believes that it is the only application accessing the secure element.

[0100] Figure 5 An embodiment of the communication between two electronic devices is schematically shown in block form.

[0101] Figure 5 For example, an embodiment is described that illustrates the communication between a secure element 300 (SE) of the type described in relation to the previous figures and an electronic device 401 (VNP) compatible with the VNP protocol, such as a main processor 121 ( Figure 1 ) or 161 ( Figure 2 and 3 ) and a device 402 (other) that is incompatible with the VNP protocol and uses a different packet communication protocol. For example, a modem 163 ( Figure 2 and 3 ), which conventionally exchanges data with the secure element (such as a subscriber identity module - SIM) via the ISO7816 protocol. The devices 401, 402 can be devices that include the secure element 300 (in the case of an integrated security module) or separate electronic devices (in the case of an embedded security module).

[0102] Device 401 is suitable for communicating with the security element 300 by sending messages using the VNP protocol.

[0103] Device 402 is suitable for communicating with the security element 300 by sending messages using other protocols than the VNP protocol, such other protocols being, for example, the HCI protocol, the SWP protocol, the CLT protocol, the ISO7816 protocol, the sHDLC protocol. Device 402 may also use, for example, an internal timing memory, such as a physical link carrying the relevant protocol. Device 402 is, for example, a near-field communication device, such as an NFC device. This type of device must implement specific standards to achieve interoperability (during its use with different devices). More specifically, the NFC device will use an NFC controller (Near Field Communication Controller - NFCC) or a Contactless Front End (CLF), which has an NCI protocol for interfacing with the NFCC and the main processor and an HCI / CLT / sHDLC protocol for interfacing between the NFCC or CLF and the security element.

[0104] In the example illustrated with respect to Figure 5 the security element 300 implements two applications 301 (App1) and 302 (App2). The link for receiving messages by the security element 300 is shown in Figure 3 which includes: a circuit 303 (VH) suitable for implementing virtual host software; a router 304 (ROUTER) suitable for processing the received messages; the virtual main platform 305 (VPP) of the security element; and two buffer memories 306 (MEM1) and 307 (MEM2) respectively associated with the applications 301, 302.

[0105] When device 401 sends a message to the security element 300 using the VNP protocol, this message is received by the router 304. Due to the header of the data packet of the message, the router 304 is able to determine, due to the data present in the VNP protocol, which application should receive the message. The message is then passed through the virtual private platform to be stored in the buffer memory associated with the application that is intended to receive, process, and respond to the message. The application will extract the message from the buffer memory to use the message.

[0106] When device 402 sends a message that does not use the VNP protocol to the security element 300, this message is first received by the circuit 303 suitable for implementing virtual host software or process. The software or process has several functions. First, it enables the modification of the communication protocol used by the message so that it can be used by the router 304, provided that this protocol is not compatible with the VNP protocol. The virtual host also enables the routing of the message to the desired application.

[0107] An example of an NFC controller that uses an HCI protocol in combination with the sHDLC and CLT protocols as defined in standards such as ETSI TS102 622 and TS102 613 is assumed. It is also assumed that applications App1 and App2 of the secure element 300 interface only with the VPP layer (and the router). The VPP layer and the associated router then use only the VNP protocol. First, the virtual host software will register on the VNP router and be witnessed by applications App1 and App2 as an NFC host implementing the HCI gate. When application App1 or App2 creates a VNP pipe towards this virtual host software, the virtual host software will accept the creation of the pipe and start communication between itself and the NFC controller by using the defined protocols included in the NFC controller. Then, when application App1 or App2 sends an HCI control signal to execute an instruction on the NFCC via a VNP packet, the virtual host software will intercept / receive the VNP packet containing the HCI control signal and remove the VNP encapsulation to encapsulate the message in one or more sHDLC frames. During the incoming message exchange from the NFC controller to application App1 or App2, the virtual host software will perform operations in the reverse direction, i.e., by suppressing the sHDLC data and by adding it to the VNP data (while maintaining the HCI content). This first type of implementation makes the use of this translation exclusive. In other words, two applications of two different low-level operating systems (LLSO) may not properly manage the NFCC controller. In fact, it will quickly become conflicting. Since each low-level operating system LLOS is unaware of the other low-level operating system, its corresponding application may additionally introduce incompatible parameters on the NFC controller, making the application in other applications unavailable. In addition, if a contactless message arrives via the antenna of the NFC controller, the application intended to process the control signal will not be identified. For example, if a link already exists between application App1 and the NFC controller, the virtual host software denies the creation of a link between application App2 and the NFC controller. Once the link with application App1 has been suppressed (e.g., the task is completed or the pipe between application 1 and the virtual host software is suppressed / closed), the virtual host software authorizes the creation of a link between application App2 and the NFC controller. In the following, if application App1 wishes to access the NFC controller, it should recreate the link to the NFC controller once the link between application App2 and the NFC controller ends.

[0108] As a variant, the virtual host software can inform the NFC controller of the existence of multiple low-level operating systems LLOS (and thus multiple applications App1, App2), which enables multiple links to be established 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 a pipeline between the application of this new operating system and the virtual host software. During the exchange between the NFC controller and the virtual host device, the two devices add data to identify the application of the low-level operating system targeted by the control signal. To form a bridge between the two protocols (mainly when there are multiple applications), the virtual host software has an internal routing table that allows data translation. As a variant, it uses an injective function between the identifier of the NFC controller and the identifier of the target application (two different identifiers cannot refer to the same application).

[0109] Optionally, the software can also enable the modification of the state of an application, for example, switching it from a deactivated or standby state to an active state, to enable the reception of reminder messages. Once the message has been processed by the virtual host software, it follows the same path as the message sent by device 401. In other words, the router 304 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 memory associated with the application that intends to receive the message. The application will extract the message from the buffer memory to use the message.

[0110] Optionally, the software can enable the management of access authorizations and a list of data exchanges between different applications, different environments, and / or different operating systems to authorize or not authorize communication.

[0111] The advantage of this embodiment is that it enables messages using communication protocols other than the VNP protocol to be used by the secure element.

[0112] Figure 6 Another embodiment of the communication between two electronic devices is very schematically shown in block form.

[0113] Figure 6 Another embodiment of a method for communicating between a secure element 500 (SE) of the type described in the previous figures and an electronic device 600 (DEVICE) is schematically illustrated in block form.

[0114] Device 600 uses any packet communication protocol described with respect to Figure 2 to communicate with the secure element. Device 600 can be a device that includes the secure element 500 or an external electronic device. Device 600 is, for example, a near-field communication device.

[0115] In relation to Figure 6In the illustrated example, the security element 500 implements the application 501 (App1). The link for receiving messages by the security element 500 is shown in Figure 6 This receiving link includes: a router 502 (ROUTER); a virtual main platform 503 (VPP) of the security element; a buffer memory 504 (MEM) associated with the application 501; and a register 505 (VRE).

[0116] The router 502 is adapted to process the received messages using the VNP protocol and direct the received messages to the application 501. When the device 600 sends a message using the VNP protocol, the router 502 directs the message to the application 501. For this purpose, the message passes through the main platform 503 and is then stored in the buffer memory 504. The application 501 then extracts the message from the buffer memory 504 to use the message.

[0117] According to an embodiment, the router 502 (as a variant, the platform 503) is also adapted to direct messages that do not use the VNP protocol to the register 505 instead of to the buffer memory 504. The register 505 is linked to the application 501. Before use, an operation of linking the register to the application is performed. In fact, the application App1 may be hosted on a virtual register VRE (or other component) having the main virtual main platform 503 to indicate to it that it can receive control signals / instructions / information according to defined protocols (sHDLC, CLT, etc.) and / or physical lines (SWP, I2C, SPI, ISO7816, etc.). In this embodiment, a single application can be hosted on a specific register. When data arrives on this pipeline (logical or physical), the router or VPP platform transfers the data to the hosted application (without changing the communication protocol used).

[0118] According to an alternative embodiment, the element 500 can be adapted to implement more than one application. In this case, each application is linked to a specific register by a linking operation.

[0119] In this case, the control signal is sent to the "default" application or to the currently active application. This implies that the application targeted by the control signal has been selected by other components (e.g., by a channel that has used the VNP protocol). In the case of selection by another channel, the application can request / impose its non - deselection for a given time (e.g., 500 ms, 1 sec, etc.) to be able to receive and process the next control signal. If the complete processing of an operation requires multiple control signals, then the application can extend the non - deselection time by asking the VPP layer.

[0120] According to another alternative embodiment where the element 500 is adapted to implement more than one application, the register can be linked to the application being executed by the security element 110.

[0121] In this variant, the application indicates its specific pattern. The advantage is that if multiple applications are registered on the same virtual register, then the router 304 or the platform 305 can select the application according to the recorded pattern. If the received control signal does not correspond to the pattern, then the default application can continue to execute its processing. Of course, the control signals following the selection of the application are still sent and processed by it.

[0122] The advantage of this embodiment is that it enables the messages using communication protocols other than the VNP protocol to be available.

[0123] According to yet another embodiment, for a host device outside the security element in the form of a host virtual (virtual host) or in hardware form (device host), a (first) communication protocol is implemented. If the security element is not compatible with this second protocol, then the message is converted to this communication protocol according to another (second) protocol.

[0124] Various embodiments and variants have been described. Those skilled in the art will understand that certain features of these various embodiments and variants can be combined, and those skilled in the art will think of other variants.

[0125] Ultimately, based on the functional indications given above, the actual implementation of the described embodiments and variations is within the capabilities of those skilled in the art.

Claims

1. A security element, comprising: a router that manages a first message using a first communication protocol between a first application and a second application of the security element and the outside of the security element; and a software layer that performs processing at the level of the router, the software layer being configured to: notify a second device outside the security element of the first presence of the first application of the security element in response to a first pipe to the software layer being created; notify the second device of the second presence of the second application of the security element in response to a second pipe to the software layer being created; verify the compatibility of a second communication protocol different from the first communication protocol, the second message being received using the second communication protocol; convert the second message into the first communication protocol in the absence of the compatibility; direct the converted second message to the first application or the second application according to a recipient expected by the second device; and transmit the converted second message to the router; wherein the software layer is a virtual destination host for the first application and the second application.

2. The security element according to claim 1, wherein the first communication protocol is implemented by a first device outside the security element.

3. The security element according to claim 1, wherein the first communication protocol is a virtual network protocol (VNP) protocol defined according to the GlobalPlatform Technology - Virtual Master Platform - Network Protocol 1.0.1 or subsequent standards.

4. The security element according to claim 1, wherein the second communication protocol is selected from the group consisting of: a host controller interface (HCI) protocol, a single wire protocol (SWP) protocol, a contactless tunnel (CLT) protocol, a packet communication protocol defined by the International Organization for Standardization 7816 (ISO7816) standard, a simplified high-level data link control (sHDLC) protocol, or a communication protocol using an internal timing memory.

5. The security element according to claim 1, wherein the first message and the second message contain data packets of a packet communication method.

6. The security element according to claim 5, wherein the software layer is configured to modify a header of the data packet of the second message.

7. The security element according to claim 1, wherein the second message originates from a near field communication device.

8. The security element according to claim 1, wherein the first message and the second message are intended for applications configured to be implemented by a high-level operating system of the security element.

9. The security element according to claim 1, wherein the software layer has a routing table that enables conversion of a given message intended for a given application.

10. The security element according to claim 1, wherein the software layer uses an injective function that enables conversion of a given message application intended for a given application.

11. The security element according to claim 1, wherein the security element is embedded in an electronic system.

12. The security element according to claim 1, wherein the security element is integrated in an electronic system.

13. A method for a security element to communicate with the exterior of the security element, the security element including a router that manages a first message using a first communication protocol between a first application and a second application of the security element and the exterior, the method including: Notifying, by a software layer of the security element, a second device exterior to the security element of the first presence of the first application of the security element in response to a first pipe to the software layer being created; Notifying, by the software layer of the security element, the second device of the second presence of the second application of the security element in response to a second pipe to the software layer being created; Verifying, by the software layer at the level of the router, the compatibility of a second communication protocol different from the first communication protocol, a second message being received using the second communication protocol; Converting, by the software layer, the second message into the first communication protocol in the absence of the compatibility; Directing, by the software layer of the security element, the converted second message to the first application or the second application according to a recipient expected by the second device; And Transmitting, by the software layer, the converted second message to the router.

14. The method according to claim 13, wherein the first communication protocol is implemented by a first device exterior to the security element.

15. The method according to claim 13, wherein: The first communication protocol is a virtual network protocol (VNP) defined according to Global Platform Technology - Virtual Master Platform - Network Protocol 1.0.1 or a subsequent standard; and The second communication protocol is selected from the group consisting of: a host controller interface (HCI) protocol, a single wire protocol (SWP) protocol, a contactless tunnel (CLT) protocol, a packet communication protocol defined by the International Organization for Standardization 7816 (ISO7816) standard, a simplified high-level data link control (sHDLC) protocol, or a communication protocol using internal timing memory.

16. The method according to claim 13, wherein the first message and the second message include data packets of a packet communication method.

17. The method according to claim 16, further including modifying a header of the data packet of the second message by the software layer.

18. The method according to claim 13, wherein the first message and the second message are intended for applications configured to be implemented by a high-level operating system of the security element.

Images