Security element and method

Abstract

Embodiments of the present disclosure relate to secure elements and methods. The present description discloses a secure element and a communication method configured to implement at least one first application and comprising a circuit configured to record routing data and a list of parameters of communication protocols compatible with the first application; verify compatibility of a first communication protocol used by a first message with the protocols of the list, the first message intended for the first application; in response to the first protocol not being compatible with at least one protocol in the list, convert the first message into a second message using a second communication protocol; and direct the second message to the first application by using the routing data of the first application.

Description

[0001] Cross-references to related applications

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

[0003] This disclosure generally relates to electronic devices, and more specifically to electronic devices suitable for processing confidential data. More specifically, this disclosure relates to communication between secure elements and other electronic devices. Background Technology

[0004] There is a growing number of electronic devices available for providing digital services. These digital signals utilize cryptographic mechanisms when it is necessary to protect highly sensitive and confidential data. In fact, the integrity of the content is also paramount; unlike cryptographic (or signature) keys, identifiers should not be modifiable but freely accessible. For this purpose, ensuring the confidentiality and integrity of the data is determined by the electronic device itself.

[0005] A secure element is an autonomous or non-autonomous electronic device designed to handle confidential data securely, i.e., without allowing access to or derivation of this confidential data, for example, through side-channel attacks or penetration. A secure element can be configured, for example, to encrypt the data.

[0006] The goal is to at least partially improve certain aspects of communication between security components and other electronic devices. Summary of the Invention

[0007] A secure element is needed that can communicate efficiently with other electronic devices.

[0008] The embodiments overcome all or some of the shortcomings of known safety elements.

[0009] A first aspect embodiment provides a security element configured to implement at least one first application, and the security element includes circuitry configured to record routing data and a list and parameters of communication protocols compatible with the first application, verify the compatibility of a first communication protocol used by a first message, the first message intending to use the listed protocols for the first application, and if the first protocol is incompatible with at least one protocol in the list, convert the first message to a second message using a second communication protocol, and guide the second message to the first application using routing data of the first application.

[0010] An embodiment provides a method for communication between an electronic device configured to implement at least one first application and a security element, the method comprising: recording routing data and a list of communication protocols compatible with the first application; verifying the compatibility of a first communication protocol used by a first message intended for use in the first application with the protocols in the list; if the first protocol is incompatible with at least one protocol in the list, converting the first message into a second message using a second communication protocol; and directing the second message to the first application using the routing data of the first application.

[0011] According to an embodiment, the first protocol in the list is selected from the group including: VNP protocol, HCI protocol, SWP protocol, CLT protocol, packet communication protocol defined by the standard, sHDLC protocol, and communication protocol using internal timing memory.

[0012] According to an embodiment, the security element aggregates data from different applications, such that devices communicating with the security element believe that a single application exists that combines different recording or activation applications.

[0013] According to an embodiment, the security element detects potential conflicts and implements a solution mechanism during the recording or modification of protocols or during the routing of application data.

[0014] According to an embodiment, the second security protocol is the VNP protocol.

[0015] According to an embodiment, a security element or communication method is configured to direct a first message to a first application.

[0016] According to an embodiment, the security element also includes electronic components and a low-level operating system.

[0017] According to an embodiment, the first application is implemented using electronic components and a low-level operating system.

[0018] According to an embodiment, the safety element is configured to implement at least one second application.

[0019] According to an embodiment, even if the second application uses the same communication protocol as the first application, the first message is still directed to the first application.

[0020] According to an embodiment, in the event of a first application request, the routing data and the list of communication protocols of the first application are erased or modified. Attached Figure Description

[0021] 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 rather than limitation, with reference to the accompanying drawings, wherein:

[0022] Figure 1Examples of electronic devices of the type to which the described embodiments are applicable are illustrated schematically in box form;

[0023] Figure 2 Another example of an electronic device of the type to which the described embodiments are applicable is illustrated schematically in box form;

[0024] Figure 3 Another example of an electronic device of the type to which the described embodiments are applicable is illustrated schematically in box form;

[0025] Figure 4 The combination is schematically shown in the form of a box. Figures 1 to 3 Examples of software architectures for the safety elements of electronic devices of the described type; and

[0026] Figure 5 An example of communication between two electronic devices is illustrated schematically in box form. Detailed Implementation

[0027] In the various figures, similar features are indicated by similar reference numerals. Specifically, structural and / or functional features common in various embodiments may have the same reference numerals and may be arranged with the same structure, dimensions, and material properties.

[0028] For clarity, only the steps and elements that help to understand the embodiments described herein will be described in detail.

[0029] Unless otherwise stated, when referring to two elements connected together, this means a direct connection without any intermediate elements other than conductors, and when referring to two elements coupled together, this means that the two elements can be connected or can be coupled via one or more other elements.

[0030] In the following disclosure, unless otherwise specified, when referring to absolute positional qualifiers such as “front,” “back,” “top,” “bottom,” “left,” “right,” or relative positional qualifiers such as “above,” “below,” “upper,” “lower,” or directional qualifiers such as “horizontal,” “vertical,” etc., refer to the orientation shown in the diagram.

[0031] Unless otherwise specified, the expressions “about,” “roughly,” “substantially,” and “approximately” indicate within 10%, and preferably within 5%.

[0032] Figure 1 An example of an electronic device 100 (SOC) of the type to which the described embodiments are applied is illustrated schematically in box form.

[0033] Device 100 is an electronic device formed on a single chip (System-on-a-Chip - SOC). Device 100 includes a security element 110, which is integrated in this example (iSE - Integrated Security Element). Security element 110 is a security element integrated into device 100, meaning it can operate autonomously within device 100. According to an alternative embodiment, security element 110 operates using certain hardware resources of device 100, such as memory, circuitry implementing specific functions, etc.

[0034] The integrated secure element 110 is an electronic circuit that manipulates, for example, encrypted secret data. The secure element 110 includes: at least one processor 111 (SE CPU) for processing secret data; a memory management function 112 (MMF) and / or a memory management unit (MMU) (not shown) for managing reading data from and writing data to memory; one or more circuits 113 (HW functions) for implementing the hardware functionality of the secure element 110 (e.g., 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) for managing communication of data and control signals between the secure element 110 and the rest of the device 100; and a communication bus 117 (SE bus) coupled to all components of the secure element 110.

[0035] 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 the 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 (NFC) device.

[0036] Processor 111 is used to process control signals and data originating from memories 114 and 115 or other memories included within device 100. Processor 111 uses memory management circuitry 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 memories 114 and 115. As an example, circuitry 112 may be used, for instance, to allocate memory space of volatile memory or memory space of non-volatile memory to certain applications implemented by integrated security elements.

[0037] Circuit 113 may include various types of circuits and components, functions that enable data to be copied to external memory, cryptographic coprocessors, etc.

[0038] Communication circuit 116 can be used as a data receiving and transmission link for secure element 110. Circuit 116 may include data receiving circuitry, data encryption and / or decryption circuitry, one or more routers, and data conversion circuitry. Device 100 may include only secure element 110, but may also optionally include: one or more processors 121 (SOC CPU) for processing data; one or more circuits 122 (functions) for implementing different functionalities of 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.

[0039] For reasons of size and compactness, device 100 may also be adapted to store data in one or more external memories. More specifically, device 100 may be adapted to store data in external volatile memory 21 (EXT RAM) and / or external non-volatile memory 22 (EXT NVM). In this case, device 100 also includes interface circuitry for communicating with the external memories. More specifically, in this case, device 100 may include interface circuitry 126 (RAM interface) for communicating with external volatile memory 21, and / or interface circuitry 127 (NVM interface) for communicating with non-volatile memory 22.

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

[0041] Figure 2 Another example of an electronic circuit 100' of the type to which the described embodiment applies is shown schematically in box form.

[0042] The device 100' includes: various electronic circuits or chips, in which an embedded security element (eSE) 150 is formed as a ground-mount resistor element (TRE); a main processor 161 (main CPU); a modem-type communication circuit 163 (modem); and a near-field communication circuit 165 (NFC controller).

[0043] The embedded secure element 150 is formed from a single chip and integrates, for example, a secure element 151 (secure CPU); a hardware cryptographic processor 152 (HW cryptographic CPU) or cryptographic accelerator; one or more volatile memories 153 (RAM); one or more non-volatile memories 154 (NVM); and one or more buses 155 (buses) for communication between different components of the element 150.

[0044] Component 150 also integrates interfaces for communicating with external devices 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.

[0045] Device 100' may include other circuitry, either integrated or non-integrated. For example, embedded security element 150 may use one or more external memories (not shown), which communicate directly with or via the host processor.

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

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

[0048] Figure 3 Another example of an electronic circuit 100 of the type to which the described embodiment applies is shown schematically in box form.

[0049] In this example, it is assumed that the embedded security element is integrated with the near-field communication controller on the same chip 180. Therefore, the integrated circuit or chip 180 includes: an embedded security element 150' (TRE), comprising, in addition to interface 158, a near-field communication controller... Figure 2 The same components as component 150 include: security component 151 (security CPU); 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 (buses) for communication between different components of component 150; and an I2C or SPI type interface 156 for communication with an external processor 161 (main CPU). The interface 157 (ISO7816) for communicating with modem 163 (modem) according to ISO7816 standard; and NFC controller 170 (NFC controller), including, for example, processor 171 (CPU); radio frequency transmit / receive circuitry 172 (RF analog HW) or 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 communication between different components of the NFC controller; and interface 176 (I2C / SPI HW) for communicating with the main processor 161 of device 100".

[0050] The exchange between safety element 150' and controller 170 is directly transmitted via buses 155 and 175, which are coupled together as needed to form a single bus, wherein element 150' and controller 170 can emulate the SWP protocol.

[0051] The safety element 150' and the controller can also communicate via shared memory 159 through their RAMs 153 and 173, thereby enabling inter-process communication (IPC).

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

[0053] Due to the significant advancements in these functionalities within electronic devices, near-field communication between secure components (integrated or embedded) is a preferred application.

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

[0055] Unless otherwise specified, the term "safety element" is used herein to refer to an embedded safety element or an integrated safety element in different ways. Therefore, the software architecture 200 of the safety element SE can be implemented in any of the elements 110, 150, or 150' in the previous diagram.

[0056] Architecture 200 includes a primary platform 210 (VPP), commonly referred to as a Virtual Primary Platform (VPP), which includes access to the electronic components 211 (HW) of the Secure Element SE and includes one or more low-level operating systems 213 (LLOS). According to an embodiment, the primary platform 210 also includes circuitry capable of implementing communication management software or processes 215 (COMM MGT), regarding... Figure 5 Describe its operation.

[0057] Component 211 is safety element SE(110, Figure 1 150, Figure 2 ;150', Figure 3 The hardware resources of the security element 110. 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 communication devices that enable direct communication with near field communication (NFC) devices; short-range communication devices that use, for example, Bluetooth standards, biometric sensors, etc.

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

[0059] A low-level operating system 213 is formed from executable code and execution data. The executable code contains instructions that enable the program to perform its functions. By definition, the instructions are invariant for a given program, except for updates to the program, which then modify the instructions. Execution data is used by the executable code to contextualize execution and perform the required functions. 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 PIN verification, then this function is broken down into three parts: the executable code contains instructions for PIN verification, the permanent execution data contains the reference PIN, and the remaining multiple test and temporary execution data contain the PIN submitted for verification.

[0060] Primary platform 210 communicates with applications executed by secure element 110, which has interfaces or tools 220 (tools) executed by the primary platform. These interfaces or tools 200 may include, among other features, an application binary interface (ABI); registers (VRE, virtual registers); and storage buffers or caches, or may also include shared memory for implementing data exchange between processes via inter-process communication (IPC).

[0061] Application binary interfaces are low-level interfaces between applications of a secure element and its operating system, or between different parts of an application.

[0062] A register is a hardware function linked to the safety element, for example, when a control signal is sent to the primary platform 210 of the safety element, or during an exchange between processes performed by the primary platform, and is used for temporary data storage.

[0063] Buffer memory (or shared memory) is used to store messages before they are used by platform 210 or by applications 231, 232, 233 of the security element. In practice, buffer memory is memory space allocated in the memory of element 110 (e.g., volatile memory already accessed by element 110, such as memory 114).

[0064] As an example, software architecture 200 includes at least three applications 231, 232, and 233 suitable for implementing primary platform 210 using interface or tool 220. Applications 231, 232, and 233 are software that uses the resources of the primary platform. Of course, security elements implement a large number of applications within their computational capacity limitations.

[0065] Integrated Safety Element 110 ( Figure 1 The embedded secure element 150 can execute a single application simultaneously in its internal memory and record other applications in external memory, which allows for a large number of applications to be used only by external memory. Applications must be pre-loaded into internal memory before being executed (or resumed), and previous applications must be unloaded before an application can be used. In contrast, the embedded secure element 150... Figure 2 ) or 150' ( Figure 3 The application will preferentially use its internal memory to store and execute applications, implying a more constrained but faster execution concept, due to the aforementioned "in-situ" execution not requiring application replacement. However, the benefits of combining embedded secure elements with external memory, and thus combining internal and external memory, remain possible. Applications 231, 232, and 233 can be adapted to implement any type of functionality. They typically implement digital services provided by service providers, such as payment services for EMV or transportation ticketing. These applications can be combined with the main processor 121 ( Figure 1 ) or 161 ( Figure 2 and 3 This can be another application within a trusted execution environment (or another secure environment). The processor and secure environment can interact with the user via a trusted user interface. Applications 231, 232, and 233 are, for example, suitable for processing control signals originating from a communication interface, such as banking transactions using near-field communication devices. Applications can be of different types, such as SIM (Subscriber Identity Frame) applications, payment applications, applications enabling the verification of public transportation tickets, etc.

[0066] Based on the example of the application type, application 231 (App1) can be implemented directly by the primary platform 210 (VPP) using interface or tool 220. Application 231 is, for example, an application that enables payments via near field communication (NFC) devices.

[0067] According to another example of application type, application 232 is a set of instructions 232A (App2) suitable for execution using an advanced operating system 232H (HLOS1). An advanced operating system is software suitable for implementing different applications by providing a set of common software functions. Operating system 232H is only a part of application 232 that communicates with primary platform 210 via interface or tool 220. As a variation, it is also possible to consider an advanced operating system and all applications attached to it as a single application suitable for implementation by primary platform 210 via interface or tool 220.

[0068] According to another example of application type, another application 233 is a set of instructions 233A (App3) using an execution environment 233E (ENV), which itself uses an advanced operating system 233H (HLOS2). The execution environment is, for example, of the Java or JavaCard type. The operating system 233H and the execution environment 233E are only part of the application 233 that communicates with the primary platform 210 via an interface or tool 220. As a variant, it is also possible to consider an advanced operating system and all applications attached to it that can be implemented by the primary platform 210.

[0069] If no high-level operating system exists, then the high-level operating systems 232H and 233H, or applications 232 and 233 themselves, use a virtual image of memory that can be used for the management of executable code and execution data. Due to this technique, 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 between the physical distribution in volatile and non-volatile memory is ensured by the combination of certain HW modules 211 by one or more low-level operating systems 213. More generally, consider making module 210 correspond to both virtual and physical memory.

[0070] In addition, consider that the application can be in at least three different states: an active state or a state run by the primary platform 110; a standby state, in which its execution is interrupted but it can be resumed at any time; and a deactivated or de-activated state, in which its execution cannot be restarted without one or more pre-operations.

[0071] When an application resumes execution from a standby state, it resumes execution from where it was stopped. No specific routine is needed to continue its processing. From the application's perspective, everything appears as if the application had not been interrupted.

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

[0073] 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 primary platform 210), this means that the current operation performed on fixed data is considered complete. The application can then execute different control signals, such as forcing a write to non-volatile memory. For this purpose, the application sends control signals and / or data to the primary platform 210 via an interface or tool 220. The control signals are handled by one or more application binary interfaces before being sent to the low-level operating system 213; that is, the control signals are divided into multiple operations, each represented by the application binary interface, a virtual register, or a buffer / shared memory. Data is stored in registers or transferred via inter-process communication (IPC). The low-level operating system 213 responds 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 component 211 to perform what the application requested.

[0074] Applications 231, 232, and 233 cannot communicate together within a secure element. Each application 23x (x varies from 1 to the number of applications likely to be executed) is unaware of the existence of other applications 23x. Specifically, each application's operating system "believes" it is the only one communicating with the outside world. Therefore, if applications must communicate together, they should do so, as discussed, towards the secure element executing application 23x on another element containing application 23x. However, two sub-applications or applications 233 (an application can contain multiple sub-applications) of the same set can communicate together using packet communication methods via IPC inter-process communication tools. Each application 231, 232, and 233 can communicate with external electronic devices. Packet communication is a data transmission method in which the sent message is formed by one or more data packets. Each data packet includes a header containing data related to the type of communication protocol used, the message transmitter, the message receiver, the message size, etc. Among different known packet communication protocols, the secure element may use different protocols (compatible with different protocols), which can be classified according to the nature of the protocol based on the exchanged data protocol, application protocol, communication protocol, and physical link. For example, these protocols include: VNP (Virtual Network Protocol), defined by the "Global Platform Technology Virtual Primary Platform – Network Protocol 1.0.1" standard (or any subsequent version), corresponding to the data exchange protocol; SWP (Single-Wire Protocol), defined by the ETSI TS 102613 UICC - Contactless Front-End (CLF) Interface - Physical and Data Link Layer Characteristics standard, corresponding to the physical link; a communication protocol, defined by the ISO 7816 standard, covering data exchange, application protocols, communication, and the nature of the physical link (wireless); HCI (Host Controller Interface) protocol, defined by the ETSI TS 102 612 v12.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; and sHDLC (Simplified High-Level Data Link Control) protocol, defined by the ETSI TS 102 The 613 (UICC - Contactless Front-End (CLF) Interface - Physical and Data Link Layer Features) standard defines the physical link; and the I2C or SPI protocol corresponds to the physical link.

[0075] Messages 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 in which data to be transmitted by the transmitting device is written and read by the receiving device.

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

[0077] HCI, sHDLC, and CLT protocols conflict with the VNP protocol because they are incompatible and the standard does not define their interaction. This conflict results in HCI, sHDLC, and CLT protocols being unsuitable for message routing within management architecture 200. Therefore, the routers included in component 211 cannot use sHDLC, CLT, and HCI protocols to support messages because there is no data available for properly routing messages within architecture 200.

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

[0079] In the embodiments described below, it is desirable to verify potential conflicts between applications (integrated or embedded) while isolating the applications from each other. In other words, each application (or each application without an operating system) believes itself to be the only application accessing the secure element.

[0080] Combination Figure 5 An embodiment of a method for communication between the safety element 110 and the outside of the operation of the clarification process or software 215 is described.

[0081] Figure 5 An example of communication between two electronic devices is illustrated schematically in box form.

[0082] More specifically, Figure 5 Two safety elements SE 110 are schematically shown in boxes. Figure 1 ), 150 Figure 2 ) or 150' ( Figure 3 Methods of communication between ( ).

[0083] The security element SE is represented by a simplified form of its software architecture 200. The simplified form of its software architecture 200 includes a main platform 210 (VPP), which consists of block 217 (LLOS+HW) representing access to component 211 and low-level operating system 213 and block 215 (COMM-MGT) representing communication management process or software 215; and three applications 231 (App1), 232 (App2) and 233 (App3).

[0084] Electronic device 300 uses any packet communication protocol (e.g., about Figure 4 The device 300 communicates with the safety element using a communication protocol described. The device 300 may be part of the device 100 that includes the safety element. Figure 1 ), 100' ( Figure 2 ), 100" Figure 3 External electronic devices, or devices 100 that may be different from safety element 110. Figure 1 ), 100' ( Figure 2 ), 100" Figure 3 Internal components of ). According to a particular embodiment, device 300 is a near-field communication device 170 included in device 100”. Figure 3 It is adapted to receive communication from electronic devices outside of device 100.

[0085] In the first initial step, by Figure 3 Arrow F1 indicates that applications 231, 232, and 233 register with software 215. During the registration process with software 215, each application sends a list of communication protocols it can use (and is compatible with), the parameters required to use those protocols, and routing data about itself. In other words, the first application records routing data, a list of compatible communication protocols, and the parameters associated with those protocols.

[0086] Software 215 is adapted to make messages using the first communication protocol compatible with the communication protocol used by the security element SE. According to one embodiment, the security element will combine... Figure 4 The defined VNP communication protocol is used as a priority. In other words, the security element SE is defined in its component 211 ( Figure 4The software 215 includes at least one router configured to use the VNP communication protocol and adapted to process messages using the protocol by directing messages to their destinations (e.g., applications 231, 232, or 233). Therefore, software 215 is adapted to convert messages using the SWP protocol, sHDLC protocol, or a communication protocol defined by the ISO 7816 standard into messages using the VNP protocol, for example, by modifying the headers of the packets forming the messages. Knowing further routing data about the applications, software 215 is further adapted to process messages using the HCI protocol or the CLT protocol. As previously mentioned, the HCI and CLT protocols are compatible with the VNP protocol but are not suitable for managing message routing. When the security element SE receives a message using the HCI or CLT protocol, software 215 is adapted to direct the message to an application using that communication protocol. Software 215 (in conjunction with block 217) provides an advantage to device 300. In practice, device 300 cannot use the VNP protocol but instead uses its own protocols (SWP, sHDLC, ISO 7816, etc.). The advantage of this solution is that software 215 (in conjunction with 217) can perceive the existence of a single application from the perspective of device 300 (231, 232, 233). In reality, due to the data provided during application registration, device 300 is able to combine data to aggregate them and believes in the existence of a single application, but it combines all the "functionality" of the active / registered application (231, 232, 233). When a message originates from device 300, software layer 215 (in conjunction with 217) is able to route the message to the target application (while simultaneously converting protocols as needed, as previously shown).

[0087] An example of communication between device 300 and the secure element is as follows. Device 300 sends a message for an application (e.g., application 231) on the secure element. This message is first received by components of the main platform 210 and the low-level operating system 217. More specifically, the message is received by a router contained in a component of the secure element SE. If the message uses a communication protocol different from the VNP protocol, the message is sent to software 215 for processing. According to an alternative embodiment, all messages can be sent to software 215 for processing. If the message uses a communication protocol compatible with the VNP protocol, i.e., the HCI protocol or the CLT protocol, the software uses routing data from applications 231, 232, and 233 to direct the message to application 231. If the message uses a communication protocol incompatible with the VNP protocol, software 214 translates the message to use the VNP protocol. To do this, it modifies the header of the packets forming the message and directs the message to application 231 using routing data from applications 231, 232, and 233.

[0088] According to an embodiment, the processing or software 215 is further adapted to manage conflicts between multiple applications. More specifically, multiple applications may use the same communication protocol or have parameters that may conflict on the same protocol. During its registration, each application will provide a list of the protocols, parameters, and routing data it requires. If this data is incompatible with existing parameters, the application's recording (or modification) of these parameters will be rejected. Software 215 (in conjunction with 217) may also provide a mechanism for managing conflicts, for example, resolving conflicts by referring to the application causing the conflict (e.g., by using, the conflicting application will be deactivated and the registration / modification of this new application will be allowed). Software 215 (in conjunction with 217) is adapted to deliver received messages to the correct application, particularly due to the routing data provided by the application.

[0089] According to an embodiment, software 215 is also adapted to erase application-associated data, namely, a list of communication protocols used by the application and their routing data, upon request by the application. As an example, the application may request deregistration each time it switches to a deactivated state.

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

[0091] 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 safety element configured to perform at least one first application, the safety element comprising: The circuit is configured as follows: Record the routing data compatible with the first application, as well as a list and parameters of communication protocols; Verify the compatibility of the first communication protocol used by the first message with the communication protocols in the list, the first message being intended for the first application; In response to the first communication protocol being incompatible with any of the communication protocols in the list, the first message is converted into a second message using the second communication protocol; as well as By using the routing data of the first application, the second message is directed to the first application; The security element is configured to aggregate data from different applications such that devices communicating with the security element treat the different applications as a single application.

2. The security element of claim 1, wherein each communication protocol in the list is selected from the group consisting of: Virtual Network Protocol (VNP) as defined by Global Platform Technology - Virtual Host Platform - Network Protocol 1.0.1 or a subsequent standard, Host Controller Interface (HCI) protocol, Single Wire Protocol (SWP) protocol, Contactless Tunneling (CLT) protocol, packet communication protocol as defined by the International Organization for Standardization 7816 (ISO 7816) standard, Simplified High-Level Data Link Control (sHDLC) protocol, or a communication protocol using an internal timing memory.

3. The security element of claim 1, wherein each of the different applications is recorded or activated.

4. The security element of claim 1, wherein the security element is configured to: detect potential conflicts and implement a resolution mechanism during the recording or modification of the applied communication protocol, the parameters, or the routing data.

5. The security element of claim 4, wherein the second communication protocol is the VNP protocol defined according to Global Platform Technology - Virtual Host Platform - Network Protocol 1.0.1 or a subsequent standard.

6. The security element of claim 1, wherein the security element is configured to direct the first message to the first application.

7. The security element according to claim 1, wherein the security element further comprises electronic components and a low-level operating system.

8. The security element of claim 7, wherein the first application is implemented using the electronic components and the low-level operating system.

9. The safety element of claim 1, wherein the safety element is configured to perform at least one second application.

10. The security element of claim 9, wherein the first message is directed to the first application, regardless of whether the second application uses the same communication protocol as the first application.

11. The security element of claim 10, wherein in response to a request from the first application, the routing data of the first application and the list of communication protocols are erased or modified.

12. A method for communicating with an electronic device via a secure element, the secure element being configured to perform at least a first application, the method comprising: Record the routing data compatible with the first application, as well as a list and parameters of communication protocols; Verify the compatibility of the first communication protocol used by the first message with the communication protocols in the list, the first message being intended for the first application; In response to the first communication protocol being incompatible with any of the communication protocols in the list, the first message is converted into a second message using the second communication protocol; By using the routing data of the first application, the second message is directed to the first application; as well as The security element aggregates data from different applications so that devices communicating with the security element treat the different applications as a single application.

13. The method of claim 12, wherein each communication protocol in the list is selected from the group consisting of: Virtual Network Protocol (VNP) as defined by Global Platform Technology - Virtual Host Platform - Network Protocol 1.0.1 or a subsequent standard, Host Controller Interface (HCI) protocol, Single Wire Protocol (SWP) protocol, Contactless Tunneling (CLT) protocol, packet communication protocol as defined by the International Organization for Standardization 7816 (ISO 7816) standard, Simplified High-Level Data Link Control (sHDLC) protocol, or communication protocol using internal timing memory.

14. The method of claim 12, wherein each of the different applications is recorded or activated.

15. The method of claim 12, further comprising: Potential conflicts are detected through the aforementioned safety element; as well as The security element enables a solution mechanism to be implemented during the recording or modification of the applied communication protocol, parameters, or routing data.

16. The method of claim 15, wherein the second communication protocol is a Virtual Network Protocol (VNP) as defined in Global Platform Technology - Virtual Host Platform - Network Protocol 1.0.1 or a subsequent standard.

17. The method of claim 12, further comprising: The security element directs the first message to the first application.

18. The method of claim 12, wherein the method further comprises using the electronic components of the security element and a low-level operating system to implement the first application.

19. The method of claim 12, further comprising: At least one second application is implemented through the security element.

20. The method of claim 19, further comprising: The first message is directed to the first application, regardless of whether the second application uses the same communication protocol as the first application.

21. The method of claim 12, further comprising: In response to a request from the first application, the routing data and the list of communication protocols of the first application are erased or modified.

Images