Security elements and methods

By designing the software layer of multi-protocol message routing in the secure element, the problem of insufficient communication efficiency between existing secure elements and other electronic devices is solved, and efficient and flexible multi-protocol communication is achieved.

CN114499918BActive Publication Date: 2025-06-06STMICROELECTRONICS (ROUSSET) SAS +1
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202111245485.7
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2021-09-28
Filing Date
2021-10-26
Publication Date
2025-06-06
Estimated Expiration
2041-10-26

AI Technical Summary

Technical Problem

There are certain shortcomings in the communication between existing security elements and other electronic devices, making it difficult to achieve efficient communication.

Method used

A security element is designed, including an operating system, application, register, buffer memory and router. The router has a software layer for directing messages using different protocols to corresponding registers or buffer memory to realize multi-protocol message routing.

Benefits of technology

With this design, the security element can efficiently communicate with other electronic devices, improving communication efficiency and flexibility in the prior art.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114499918B_ABST
    Figure CN114499918B_ABST
Patent Text Reader

Abstract

Embodiments of the present disclosure relate to security elements and methods. The present disclosure describes a security element and a communication method, wherein the security element includes: at least one operating system, including at least one application, having a register associated therewith; a buffer memory; and a router having a software layer. The software layer is configured to direct a first message using a first protocol and intended for the application to the buffer memory, and to direct a second message using a second protocol different from the first protocol and intended for the application to the register.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

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

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

[0004] There are more and more 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, and in contrast to the cryptographic (or signature) keys, the identification numbers should not be able to be modified but freely accessible. For this purpose, it is up to the electronic devices to ensure the confidentiality and integrity of the data.

[0005] A secure element is an autonomous or non-autonomous electronic device adapted to process secret data in a secure manner, ie without access or derivation of such secret data, for example by side channel attacks or penetration. A secure element may be configured to encrypt data, for example.

[0006] It would be desirable to be able to at least partially improve certain aspects of communication between secure elements and other electronic devices. Summary of the invention

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

[0008] Embodiments overcome all or part of the disadvantages of known security elements.

[0009] An embodiment of the first aspect provides a security element, comprising: at least one operating system, including at least one application, the application having a register associated with the application; a buffer memory; and a router, having a software layer, the software layer being adapted to: direct a first message using a first protocol and intended for the application to the buffer memory; and direct a second message using a second protocol different from the first protocol and intended for the application to the register.

[0010] An embodiment of the first aspect provides a method for communication between an electronic device and a security element, the security element comprising: at least one operating system, including at least one application, the application having a register associated with the application, a buffer memory, and a router, 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 a VPN protocol defined in accordance with Global Platform Technology-Virtual Host 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: an HCI protocol, a 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.

[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 a header of a data packet of the second message.

[0016] According to an embodiment of the first aspect, the second message originates from the 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 adapted to be implemented by a high-level operating system of the secure element.

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

[0019] According to an embodiment of the first aspect, the element or the 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, a software layer manages a list of patterns provided by an application enabled routing protocol.

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

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

[0023] An embodiment of the second aspect provides a security element, which includes: a router, which manages a first message of a first communication protocol between an application using the security element and an outside of the security element; and a software layer, which performs processing at the router level and is suitable for verifying the compatibility of a second communication protocol different from the first communication protocol, receiving a second message using the second communication protocol; in the event of no compatibility, converting the second message to the first communication protocol; and transmitting the second message to the router.

[0024] An embodiment of the second aspect provides a method for communication between a security element and an external part of the security element, the security element comprising: a router, managing a first message of a first communication protocol between an application using the security element and an external part of the security element, the method comprising performing, by a software layer at a router level, verification of the compatibility of a second communication protocol different from the first communication protocol, receiving a second message using the second communication protocol; in the absence of compatibility, converting the second message to 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 the application.

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

[0027] According to an embodiment of the second aspect, the first protocol is a VPN protocol defined in accordance with Global Platform Technology-Virtual Host Platform-Network Protocol 1.0.1 or subsequent standards.

[0028] According to an embodiment of the second aspect, the second protocol is selected from the group consisting of: an HCI protocol, a 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 message 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 a header of a 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 message and the second message are intended for an application implemented by a high-level operating system of the second element.

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

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

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

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

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

[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 into 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 given specific embodiments 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 embodiments are applicable is schematically shown in block form;

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

[0043] Figure 3 Still another example of an electronic device of the type to which the described embodiments are applicable is schematically shown in block form;

[0044] Figure 4 The combination is schematically shown in box form Figures 1 to 3 Embodiments of a software architecture for a secure element of an electronic device of the type described;

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

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

[0047] In the various drawings, similar features have been referred to by similar reference numerals. In particular, common structural and / or functional features in the various embodiments may have the same reference numerals, and may be arranged with the same structure, dimensions, and material properties.

[0048] For clarity, only the steps and elements that are helpful for understanding the embodiments described herein are explained and described in detail.

[0049] Unless otherwise stated, when referring to two elements connected together, this means directly connected without intermediate elements other than conductors, and when referring to two elements coupled together, this means the two elements can be connected or they can be coupled via one or more other elements.

[0050] In the following disclosure, unless otherwise specified, when reference is made to absolute position qualifiers such as terms "front", "back", "top", "bottom", "left", "right", or to relative position qualifiers such as terms "above", "below", "upper", "lower", or to directional qualifiers such as "horizontal", "vertical", etc., reference is made to the orientation shown in the drawings.

[0051] Unless otherwise specified, the expressions "about," "substantially," "substantially," 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 shown schematically in block form.

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

[0054] The integrated security element 110 is an electronic circuit that manipulates secret data, such as encrypted 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 the memory and writing data to the memory; one or more circuits 113 (HW functions), suitable for implementing the hardware functionality of the security element 110 (e.g., cryptographic accelerator, 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 secure element 110 is connected to one or more additional communication buses. For example, the integrated secure element may have a bus connected to a modem of the system on chip 100 according to the ISO 7816 standard, 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 therefore the processor never directly accesses the memories 114 and 115. As an example, the circuit 112 can, for example, be used to allocate memory space of a volatile memory or memory space of a non-volatile memory to certain applications implemented by an integrated secure element.

[0057] Circuitry 113 may include various types of circuits and components, functionality to enable copying of data to external memory, a cryptographic coprocessor, and the like.

[0058] The communication circuit 116 can be used as a data reception and transmission link for the security element 110. The circuit 116 may include a data reception circuit, a data encryption and / or decryption circuit, one or more routers, and a data conversion circuit. The device 100 may include only the security element 110, but may 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) to enable the exchange of control signals and data and to transmit control signals and data to all previously mentioned elements.

[0059] For reasons of size and compactness, the device 100 may also be adapted to store data in one or more external memories. More specifically, 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 also includes interface circuits adapted to communicate with the external memories. More specifically, in this case, the device 100 may include an interface circuit 126 (RAM interface) adapted to communicate 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 secure element 110 may access hardware resources of the device 100 to be operated, such as, for example, access to the circuit 122 , access to the memories 123 , 124 or even access to the memories 21 and 22 .

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

[0062] Device 100' includes: various electronic circuits or chips, among which embedded secure element (eSE) 150 forms a tamping resistance element (TRE); main processor 161 (main CPU); modem type communication circuit 163 (modem); and 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 cryptographic 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 communication between different components of the element 150.

[0064] Element 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, integrated or non-integrated.For example, the embedded secure element 150 may use one or more external memories (not shown) with which it communicates, either directly or via a host processor.

[0066] With such as Figure 1 In contrast to an integrated secure element such as embedded secure element 110 , embedded secure element 150 is not integrated with other components of device 100 ′, in particular the main processor of the application.

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

[0068] Figure 3 Yet another example of an electronic circuit 100" of the type to which the described embodiments are applicable is shown schematically in block form.

[0069] In this example, it is assumed that the embedded secure element is integrated with the near field communication controller on the same chip 180. Thus, the integrated circuit or chip 180 includes: an embedded secure element 150 ′ (TRE), including, except for the interface 158, Figure 2 The components of the present invention are the same as the components 150 of the present invention, namely, the security element 151 (security CPU); the hardware cryptographic processor 152 (HW cryptographic 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 components of the component 150; an interface 156 of the I2C or SPI type for communication with an external processor 161 (main CPU) (I2C / SPI 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 transmission / reception 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 (buses) for communicating 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] Exchanges between the secure element 150 ′ and the controller 170 are directly transmitted via buses 155 and 175 , which are coupled together and form one and the same bus as appropriate, wherein the element 150 ′ and the controller 170 can emulate the SWP protocol.

[0071] The secure element 150 ′ and the controller may also communicate via their RAMs 153 and 173 via a shared memory 159 , thereby implementing communication between processes (IPC—Inter-Process Communication).

[0072] As a variant, the secure element 150 ′ and the controller may communicate via their internal SWP communication unit (not shown). This enables the format of the SWP exchanges (and of the protocol implemented thereon) to be preserved without constraints (such as noise, bus speed limits, etc.).

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

[0074] Figure 4 The combination is schematically shown in box form Figures 1 to 3 An embodiment of a software architecture 200 for a secure element of an electronic device of the type described.

[0075] Unless otherwise specified, the expression "secure element" herein refers to an embedded secure element or an integrated secure element in various ways. Thus, the software architecture 200 of the secure element SE may be implemented in any of the elements 110, 150 or 150' of the previous figures.

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

[0077] Component 211 is a security element SE (110, Figure 1 ; 150, Figure 2 ; 150', Figure 3 ) hardware resources. The component 211 of the security element 110 is, for example: one or more processors, such as the 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 that enables 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 secure 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 of execution code (or executable code) and execution data. The execution code contains instructions that enable the functions of the program to be executed. By definition, the instructions are unchanged 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. So-called "temporary" execution data and 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 instructions for the verification of the PIN code, and the permanent execution data contains a reference to the PIN code, and the remaining multiple tests and temporary execution data contain the PIN code submitted for verification.

[0080] The host platform 210 communicates with applications executed by the secure element 110, which has interfaces or tools 220 (tools) executed by the host platform. These interfaces or tools 200 may include, among other features, an application binary interface (ABI); registers (VRE, virtual registers); and storage buffers or buffer memories, or also shared memories that implement data exchange between processes via inter-process communication (IPC).

[0081] An application binary interface is a low-level interface between an application of a secure element and its operating system, or between different parts of an application.

[0082] The register is a memory space that is linked to a hardware function of the secure element and is used to temporarily store data, for example, when a control signal is sent to the host platform 210 of the secure element or during an exchange between processes performed by the host platform.

[0083] The buffer memory (or shared memory) is used to store messages before they are used by the platform 210 or by the secure element's applications 231, 232, 233. In practice, the buffer memory is a memory space allocated in the memory of the element 110 (e.g., a volatile memory such as the memory 114 that the element 110 has access to).

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

[0085] Integrated security element 110 ( Figure 1 ) can simultaneously execute a single application in its internal memory and record other applications in external memory, which will enable a large number of applications limited only by the external memory. Applications must be pre-loaded into the internal memory before being executed (or resumed), and applications must unload previous applications before they can be used. In contrast, the embedded secure element 150 ( Figure 2 ) or 150'( Figure 3 ) will preferentially use its internal memory to store and execute applications, which implies the concept of a more restricted but faster execution of applications, since the "in situ" execution mentioned does not require replacement of applications. However, the benefits of combining an embedded secure element with external memory and therefore combining internal memory with external memory are still possible. Applications 231, 232, 233 can be suitable for implementing any type of functionality. They typically implement digital services of a service provider, such as payment services of the EMV or transport ticketing type. These applications can be combined with the main processor 121 ( Figure 1 ) or 161( Figure 2 and 3 ) or another application in another secure environment (trusted execution environment). The processor and the secure environment are further able to interact 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 for example a banking transaction using a near field communication device. The applications may be of different types, such as a SIM (Subscriber Identity Module) application, a payment application, an application enabling verification of public transport tickets, etc.

[0086] According to an example of an application type, the application 231 (App1) can be implemented directly by the main platform 210 (VPP) by means of the interface or tool 220. The application 231 is, for example, an application enabling payments by means of 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 application 231, 232 or 233 is as follows. When the application expects to use the hardware resources of the security element (i.e. one or more components 211 of the main platform 210), this means that the current operation performed on the fixed data is considered to be over. The application can then execute different control signals, such as forcing to write in a non-volatile memory. For this purpose, the application sends control signals and / or data to the main platform 210 via an interface or tool 220. The control signal is responsible for by one or more application binary interfaces before being sent to the low-level operating system 213, that is, the control signal is divided into multiple operations, each operation is represented by an application binary interface or a virtual register or a buffer memory / shared memory. Data is stored in registers or transmitted via inter-process communication (IPC). The low-level operating system 213 reacts to the request of the application binary interface by applying the operation 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 cannot communicate together within the security element. Each application 23x (x varies from 1 to the number of applications that are likely to be executed) is unaware of the existence of other applications 23x. Specifically, each operating system of the application "believes" that it is the only one communicating with the outside. Therefore, if the application must communicate together, it should be completed as discussed towards the security element of the execution application 23x of another element with application 23x. However, two sub-applications or applications 233 (applications can contain multiple sub-applications) of the same set use a packet communication method to communicate together by using an IPC inter-process communication tool. Each application 231, 232, 233 can communicate with an external electronic device. Packet communication is a data transmission method in which the message 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 message receiver, related to the message size, etc. Among different known packet communication protocols, the secure element may use different protocols (be compatible with different protocols), which may be classified according to the nature of the protocol in terms of exchanged data protocol, application protocol, communication protocol, physical link. For example, these protocols include: VNP protocol (Virtual Network Protocol), defined by the "Global Platform Technology Virtual Host Platform - Network Protocol 1.0.1" standard (or any subsequent version), corresponding to the protocol for exchanging data; 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; Communication protocol, defined by the ISO7816 standard, covering data exchange, application protocol, communication and the nature of the physical link (wireless); HCI (Host Controller Interface) protocol, defined by the ETSI TS 102 612v12.0 standard (or any subsequent version), corresponding to the application protocol; CLT protocol, defined by the ETSI TS 102 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; sHDLC protocol (Simplified High-Level Data Link Control), defined by the ETSI TS 102 613 (UICC-Contactless Front End (CLF) Interface-Physical and Data Link Layer Characteristics) standard definition; and I2C or SPI protocol, corresponding to the physical link.

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

[0096] The VNP protocol is a communication protocol suitable for communication operations for a security element. The protocol can manage the routing of messages within the architecture 200 and also toward external devices. This is a preferred communication protocol in a security element. According to an embodiment, the router included in the component 211 (combined low-level operating system 213) is a router configured to use the VNP protocol to process messages.

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

[0098] CLT, sHDLC and HCI protocols and the protocol 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) is not able to support messages using the CLT, sHDLC, HCI and ISO7816 protocols.

[0099] In the embodiments described below, it is desirable to verify possible conflicts between secure element (integrated or embedded) management 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 application accessing the secure element.

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

[0101] Figure 5 For example, an embodiment of communication between a secure element 300 (SE) of the type described with respect 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 devices 402 (others) that are not compatible with the same VNP protocol and use different packet communication protocols. For example, modem 163 ( Figure 2 and 3 ), the modem 163 conventionally exchanges data with a secure element (eg, a subscriber identity module - SIM) via the ISO7816 protocol. Devices 401, 402 may be devices including a secure element 300 (in the case of an integrated secure module) or separate electronic devices (in the case of an embedded secure module).

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

[0103] Device 402 is suitable for communicating with security element 300 by sending messages using other protocols other than VNP protocol, such as HCI protocol, SWP protocol, CLT protocol, ISO7816 protocol, sHDLC protocol. Device 402 can also use internal timing memory, such as a physical link for conveying related protocols, for example. Device 402 is, for example, a near field communication device, such as an NFC device. This type of device must implement specific standards to implement interoperability (during its use with different devices). More specifically, NFC devices will use an NFC controller (near field communication controller-NFCC) or a contactless front end (CLF), which has an NCI protocol for interfacing with NFCC and a host processor and an HCI / CLT / sHDLC protocol for interfacing between NFCC or CLF and a security element.

[0104] In About Figure 3 In the illustrated example, the secure element 300 implements two applications 301 (App1) and 302 (App2). The link for receiving messages by the secure element 300 is Figure 3 This receiving link comprises: a circuit 303 (VH) adapted to implement virtual host software; a router 304 (ROUTER) adapted to process received messages; a virtual host platform 305 (VPP) of a secure element; and two buffer memories 306 (MEM1) and 307 (MEM2) associated with applications 301 and 302, respectively.

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

[0106] When device 402 sends a message not using the VPN protocol to secure element 300, the message is first received by circuit 303 adapted to implement virtual host software or process. The software or process has several functionalities. First, it enables modification of the communication protocol used by the message so that it can be used by router 304, provided that the protocol is incompatible with the VPN protocol. The virtual host also enables the message to be directed to a desired application.

[0107] Assume an NFC controller example using the HCI protocol combined with the sHDLC and CLT protocols as defined in the ETSI TS 102 622 and TS 102 613 standards. It is also assumed that the applications App1 and App2 of the secure element 300 only interface with the VPP layer (and router). The VPP layer and the associated router then use only the VNP protocol. First, the virtual host software will be registered on the VNP router, witnessed by the applications App1 and App2 as the NFC host implementing the HCI gate. When the application App1 or App2 will create a VNP pipe towards this virtual host software, the virtual host software will accept the creation of the pipe and start the communication between itself and the NFC controller by using the defined protocol included by the NFC controller. Then, when the application App1 or App2 will send 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 will remove the VNP encapsulation to encapsulate the message in one or more sHDLC frames. During the incoming message from the NFC controller to the application App1 or App2 as an exchange, 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 the other application unavailable. In addition, if the 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 the application App1 and the NFC controller, the virtual host software denies the creation of a link between the application App2 and the NFC controller. Once the link with the application App1 has been suppressed (e.g., completing a task or suppressing / closing a pipe between the application 1 and the virtual host software), the virtual host software authorizes the creation of a link between the application App2 and the NFC controller. In the following, if application App1 wants to access the NFC controller, it should re-create the link to the NFC controller once the link between application App2 and the NFC controller ends.

[0108] As a variation, the virtual host software can inform the NFC controller of the presence of multiple low-level operating systems LLOS (and therefore multiple applications App1, App2), which enables multiple links between the NFC controller and the application. According to this variation, the virtual host software informs the NFC controller that the new low-level operating system is available when creating a pipe 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. In order 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 the data to be translated. As a variation, 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 state of the application to be modified, such as switching it from a deactivated or standby state to an activated state, so as to enable a reminder to receive a message. Once the message has been processed by the virtual host software, it follows the same path as the 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 a buffer memory associated with the application that intends to receive the message. The application will extract the message from the buffer memory to use it.

[0110] Optionally, the software may enable management of lists of access authorizations and data exchanges between different applications, different environments and / or different operating systems to authorize or not authorize communications.

[0111] An 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 communication between two electronic devices is shown very schematically in block form.

[0113] Figure 5 A further embodiment of a method of communication between a secure element 500 (SE) and an electronic device 600 (DEVICE) of the type described with respect to the previous figures is schematically illustrated in block form.

[0114] Device 600 uses about Figure 2 The device 600 may be a device including the secure element 500 or an external electronic device. The device 600 is, for example, a near field communication device.

[0115] In About Figure 4In the illustrated example, secure element 500 implements application 501 (App1). The link for receiving messages by secure element 300 is Figure 5 This receiving link includes: a router 502 (ROUTER); a virtual host platform 503 (VPP) of a secure 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 message using the VPN protocol and direct the received message 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 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 suitable for directing 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, the operation of linking the register to the application is performed. In fact, the application App1 may be registered on the virtual register VRE (or other component) with the main virtual host platform 503 to indicate to it that it can receive control signals / instructions / information according to the defined protocol (sHDLC, CLT, etc.) and / or physical line (SWP, I2C, SPI, ISO7816, etc.). In this embodiment, a single application can be registered on a specific register. When data arrives on this pipeline (logical or physical), the router or VPP platform transfers the data to the registered application (without changing the communication protocol used).

[0118] According to an alternative embodiment, the element 500 may be adapted to implement more than one application. In this case, each application is linked to a specific register by a link 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-cancellation selection for a given time (e.g., 500ms, 1sec, etc.) to be able to receive and process the next control signal. If the full processing of the operation requires multiple control signals, the application can extend the non-cancellation selection 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 registers may be linked to the applications being executed by the secure element 110 .

[0121] In this variation, the application indicates its specific pattern. The advantage is that if multiple applications are registered on the same virtual register, the router 304 or platform 305 can select an application based on the recorded pattern. If the received control signal does not correspond to the pattern, the default application can keep executing its processing. Of course, the control signal that follows the application's selection keeps being sent and processed by it.

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

[0123] According to yet another embodiment, a (first) communication protocol is implemented for a host device external to the secure element that is a host virtual (virtual host) or in hardware form (device host), and if the secure element is not compatible with this second protocol, the messages are converted into the communication protocol according to another (second) protocol.

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

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

Claims

1. A security element, include: at least one operating system in the secure element, including an application, the application having a register in the secure element associated with the application; a buffer memory in the secure element, wherein the buffer memory is separate from the register; as well as The router in the secure element has a software layer configured to: directing a first message using a first protocol and intended for the application to the buffer memory; determining compatibility of a second protocol with the first protocol before directing a second message to the register, the second message being received using the second protocol; as well as A second message using the second protocol different from the first protocol and intended for the application is directed to the register without changing the second protocol used by the second message. 2 . The secure element of claim 1 , wherein the first protocol is implemented by a device external to the secure element. 3 . The secure element of claim 1 , wherein the first protocol is a Virtual Network Protocol (VNP) protocol defined in accordance with Global Platform Technology-Virtual Host Platform-Network Protocol 1.0.1 or a subsequent standard.

4. The security element of claim 1 , wherein the second 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 secure element of claim 1 , wherein the first message and the second message contain data packets of a packet communication method. 6 . The secure element of claim 5 , wherein the software layer is configured to modify a header of the data packet of the second message. The secure element of claim 1 , wherein the second message originates from a near field communication device. 8 . The secure element of claim 1 , wherein the first message and the second message are intended for an application configured to be implemented by a high-level operating system of the secure element. 9 . The secure element of claim 8 , wherein the secure element is configured to implement at least two applications. 10 . The secure element of claim 9 , wherein the software layer is further configured to direct the second message to a selected application among the at least two applications, the second message being intended for the selected application. 11 . The secure element of claim 10 , wherein the software layer is configured to manage a pattern list provided by an application for routing the protocol.

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

14. A method for communicating with an electronic device via a secure element, the secure element include: at least one operating system in the secure element, including an application having a register in the secure element; a buffer memory in the secure element and separate from the register; and a router in the secure element associated with the secure element, the router implementing a software layer, the method comprising: directing, by the software layer, a first message using a first protocol and intended for the application to the buffer memory; determining, by the software layer in the secure element, compatibility of a second protocol with the first protocol before directing a second message to the register, the second message being received using the second protocol; and The second message using the second protocol different from the first protocol and intended for the application is directed by the software layer to the register without changing the second protocol used by the second message.

15. The method of claim 14, wherein the first protocol is implemented by the electronic device, and the electronic device is external to the secure element.

16. The method of claim 14, wherein the first protocol is a Virtual Network Protocol (VNP) protocol defined in accordance with Global Platform Technology - Virtual Host Platform - Network Protocol 1.0.1 or subsequent standards.

17. The method of claim 14, wherein the second protocol is selected from the group consisting of a host controller interface (HCI) protocol, a single wire protocol (SWP) protocol, a contactless tunneling (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.

18. The method of claim 14, wherein the first message and the second message comprise data packets of a packet communication method.

19. The method according to claim 18, further comprising: include: A header of the data packet of the second message is modified by the software layer.

20. The method of claim 14, wherein the second message originates from a near field communication device.

21. The method of claim 14, wherein the first message and the second message are intended for an application configured to be implemented by a high-level operating system of the secure element.

22. The method of claim 21, wherein the secure element implements at least two applications.

23. The method according to claim 22, further comprising: include: The second message is directed by the software layer to a selected application among the at least two applications, the second message being intended for the selected application.

24. The method according to claim 23, further comprising: include: The pattern lists provided by the application for routing the protocol are managed by the software layer.

25. A system on chip SOC, include: Communication bus; at least one processor connected to the communication bus; as well as A security element is connected to the communication bus, the security element comprising: at least one operating system in the secure element, including an application, the application having a register associated with the application; a buffer memory in the secure element, wherein the buffer memory is separate from the register; and The router in the secure element has a software layer configured to: directing a first message using a first protocol and intended for the application to the buffer memory; determining compatibility of a second protocol with the first protocol before directing a second message to the register, the second message being received using the second protocol; and The second message using the second protocol different from the first protocol and intended for the application is directed to the register without changing the second protocol used by the second message.

26. The SOC according to claim 25, in: The first protocol is a Virtual Network Protocol (VNP) protocol defined in accordance with Global Platform Technology - Virtual Host Platform - Network Protocol 1.0.1 or subsequent standards; and The second 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.

Citation Information

Patent Citations

  • Process for exhaust gas turbocharging in branch for internal combustion engines

    FR2010974A1

  • Adapter for providing unified transaction interface

    US20180376333A1