Protection of an electronic device

Abstract

Protection of an electronic device The present description relates to an electronic device comprising a secure element adapted to implement at least one first application (352A, 352B), and an application programming interface (501) configured to check whether a command received by said at least one first application (352A, 352B) has been sent reliably. Figure for abstract: Fig. 5

Description

Title of the invention: Protection of an electronic device Technical field

[0001] The present description relates generally to electronic devices, and more particularly to electronic devices adapted to process secret data. More particularly, the present description relates to electronic devices adapted to implement wireless communication, such as near field communication (NFC) or ultra wideband communication (UWB), and in which at least part of the data exchanged is secret data and / or part of the data exchanged is sensitive data allowing, for example, a method of identifying or authenticating a user, or allowing, for example, the location of a user. Prior art

[0002] Complex electronic devices, such as mobile phones, electronic tablets, computers, etc., integrate, over time, more and more functionalities and allow the implementation of digital and / or digital services in order to integrate better into daily life. For example, certain mobile phones, and more particularly smart phones, integrate digital services such as a banking payment service, or a service for using public transport tickets, show tickets, or even a dematerialized key service, in which authentication of the user with a remote system (banking, public administration, etc.) is likely to be implemented.To implement these functionalities, these devices may integrate electronic components specific to these functionalities, such as for example secure components which make it possible to keep / store identification, reference and authentication information, generally referred to as "credentials", and resources (assets) of the digital service provider, motion sensors, a wireless communication module, such as a near field communication (NFC) module or an ultra wide band (UWB) communication module, etc.

[0003] A difficulty arising from the addition of new functionalities is that secret data and / or sensitive data are exchanged between different modules and / or software layers of the same electronic device without being protected. Summary of the invention

[0004] There is a need for electronic devices processing sensitive data of reliably.

[0005] There is a need for electronic devices that process sensitive data received during wireless communication more reliably.

[0006] There is a need for more reliable wireless communications.

[0007] One embodiment overcomes all or part of the drawbacks of known electronic devices processing sensitive data.

[0008] According to a first aspect, an embodiment provides an electronic device comprising: - a processor adapted to implement at least a first high-level operating system and at least a first application; - a secure element adapted to implement a first low-level operating system configured to implement the verification of the reliability or authenticity of the first operating system, and a second low-level operating system configured to implement at least one second application and to implement at least one wireless communication or to communicate with said at least one first application, wherein at each startup of the electronic device, the first low-level operating system performs a verification of the reliability or authenticity of the first high-level operating system, and when said at least one first application sends a request to said at least one second application, said second low-level operating system requests said result from the first low-level operating system and makes it accessible to the second application.

[0009] Another embodiment provides a method of protecting an electronic device comprising: - a processor adapted to implement at least a first high-level operating system and at least a first application; - a secure element adapted to implement a first low-level operating system configured to implement the verification of the reliability or authenticity of the first operating system, and a second low-level operating system configured to implement at least one second application and to implement at least one wireless communication or to communicate with said at least one first application, wherein at each startup of the electronic device, the first low-level operating system performs a verification of the reliability or authenticity of the first high-level operating system, and when said at least one first application sends a request to said at least one second application, said second low-level operating system requests said result from the first low-level operating system and makes it accessible to the second application.

[0010] According to one embodiment, when said result indicates that the first high-level operating system is reliable or authentic then said at least one second application accepts the request of said at least one first application.

[0011] According to one embodiment, when said result indicates that the first operating system is not reliable or authentic then said at least one second application can refuse, partially accept or fully accept the request of said at least one first application.

[0012] According to one embodiment, when said at least one second application refuses, partially accepts or fully accepts the request of said at least one first application, said at least one second application takes into account a list of access authorization rules of said at least one first application.

[0013] According to one embodiment, when the first low-level operating system performs the verification of the reliability of the first operating system, the first low-level operating system stores said result.

[0014] According to one embodiment, when the second low-level operating system makes said result accessible to the second application, the second low-level operating system sends said result to said at least one second application.

[0015] According to one embodiment, when the second low-level operating system makes said result accessible to the second application, the second low-level operating system makes said result available to said at least one second application via a first application programming interface.

[0016] According to one embodiment, the first high-level operating system is the program known as Trust Platform Module.

[0017] According to one embodiment, the second low-level operating system is the program known as Global Platform and / or the program known as Java Card Virtual Machine.

[0018] According to one embodiment, said first and second low-level operating systems are adapted to communicate via a dedicated communication channel.

[0019] According to one embodiment, the secure element comprises a first electronic chip implementing said first low-level operating system, and a second electronic chip, different from the first chip, implementing said second low-level operating system.

[0020] According to one embodiment, the first chip is considered as a first secure element, and the second chip is considered a second secure element.

[0021] According to one embodiment, the secure element is adapted to implement at least one second application programming interface configured to verify whether a command received by said at least one second application has been sent reliably.

[0022] According to one embodiment, wherein said second application programming interface is configured to use several verification means.

[0023] According to one embodiment, said second application programming interface is configured to check whether the sender of said command is reliable.

[0024] According to one embodiment, the application programming interface is configured to verify whether said high-level operating system is authentic.

[0025] According to a second aspect, an embodiment provides an electronic device comprising a secure element adapted to implement at least one first application, and an application programming interface configured to verify whether a command received by said at least one first application has been sent reliably.

[0026] Another embodiment provides a method for protecting an electronic device comprising a secure element adapted to implement at least one first application, and an application programming interface configured to verify whether a command received by said at least one first application has been sent reliably.

[0027] According to one embodiment, the application programming interface is configured to use several verification means.

[0028] According to one embodiment, once said application programming interface has performed the verification, said application programming interface transmits said command to said at least one first application, and sends the result of this verification to said first application.

[0029] According to one embodiment, the application programming interface is configured to check whether the sender of said command is reliable.

[0030] According to one embodiment, the sender is a second application implemented by a high-level operating system of a processor included in said electronic device.

[0031] According to one embodiment, the application programming interface is configured to verify whether said high-level operating system is trusted or authentic.

[0032] According to one embodiment, the secure element implements a first low-level operating system implementing said first application, and a second low-level operating system configured to verify whether the high-level operating system of said processor is trusted or authentic, the application programming interface verifies that said high-level operating system is trusted by communicating with said first low-level operating system of the secure element.

[0033] According to one embodiment, the sender is an electronic system independent of the electronic device, said electronic system being adapted to be coupled with said electronic device.

[0034] According to one embodiment, said electronic system being adapted to be coupled with said electronic device using a coupling function.

[0035] According to one embodiment, the application programming interface is further configured to verify that the communication channel used to transmit the command is a reliable channel.

[0036] According to one embodiment, the application programming interface is further configured to validate the authenticity of the verification of said command received by said at least one first application.

[0037] According to one embodiment, said verification is carried out by implementing verification means that can be configured by the application programming interface as a function of the coupling function. Brief description of the drawings

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

[0039] [Fig.l] represents, very schematically and in the form of blocks, an example of an electronic device to which the embodiments of figures 2 to 5 can be applied;

[0040] [Fig.2] represents, very schematically and in the form of blocks, a software architecture of an electronic device;

[0041] [Fig. 3] represents, very schematically and in the form of blocks, a first embodiment of an electronic device processing sensitive data;

[0042] [Fig.4] represents a block diagram illustrating an embodiment of the embodiment of [Fig.3]; and

[0043] [Fig. 5] represents, very schematically and in the form of blocks, a second embodiment of an electronic device processing sensitive data. Description of the embodiments

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

[0045] For the sake of clarity, only the steps and elements useful for understanding the described embodiments have been shown and are detailed. In particular, the operation of the different types of wireless communication that can be implemented by the embodiments is not detailed.

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

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

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

[0049] [Fig. 1] represents, very schematically and in the form of blocks, an example of an electrical device 100 to which the embodiments described in relation to FIGS. 2 to 5 can be applied.

[0050] The device 100 is an electronic device suitable for processing data, and which is particularly suitable for processing sensitive data. In the remainder of the description, the term "sensitive" refers to data comprising secret or potentially secret information, or information considered private for a natural person such as a user. In other words, sensitive data is data which is not accessible to everyone and which cannot be shared with any electronic device.

[0051] The device 100 comprises a processor 101 (CPU) for processing data. According to one example, the device 100 may comprise several processors each adapted to process different types of data. According to a particular example, the device 100 may comprise a main processor and one or more secondary processors.

[0052] The device 100 further comprises one or more secure elements 102 (SE) enabling the management of sensitive data, such as the storage or use of this data, or enabling, for example, the implementation of secure applications. A secure element 102 may comprise its own dedicated processor(s), as well as its own memory(s). A secure element 102, and its system operating system, is considered, in the remainder of the description, to be reliable and inviolable. Furthermore, in the remainder of the description, the expression "secure element" subsequently designates indifferently an embedded secure element or an integrated secure element.

[0053] The device 100 further comprises one or more input / output circuits 103 (1 / 0) enabling the device 100 to transmit and / or receive data and / or energy with one or more external electronic devices. In particular, the circuits enabling communication with other devices to be managed, such as circuits, or modules, enabling wired communications to be managed, such as communications using the USB protocol, and / or wireless communications, such as Wi-Fi communications, Bluetooth communications, and / or near-field communications (NFC). The device comprises, more specifically, at least one NFC module, i.e. a module suitable for near-field communication (NFC), and / or a UWB module, i.e. a module suitable for ultra-wideband communication (Ultra Wideband, UWB).

[0054] The device 100 further comprises one or more circuits 104 (ALIM) supporting the power supply of the device 100. According to one example, the circuits 104 may comprise one or more batteries, energy conversion circuits, charging circuits, etc.

[0055] The device 100 further comprises one or more memories 105 (MEM) in which data, for example binary data, is stored. According to one example, the device 100 comprises several types of memory, such as a read-only memory, a volatile memory, and / or a non-volatile memory.

[0056] The device 100 further comprises one or more circuits 106 (FCT) implementing one or more functionalities of the device 100. According to one example, the circuits 106 may comprise specific data processing circuits, such as encryption circuits, or circuits for carrying out measurements, such as sensors.

[0057] The device 100 further comprises one or more communication buses 107 allowing all the circuits of the device 100 to communicate. In [Fig.l], a single bus 105 connecting the processor 101, the memory(s) 102, and the circuits 103 to 106 is shown, but in practice, the device 100 may comprise several communication buses connecting these different elements. In particular, the device 100 may comprise several communication buses shared by more than two circuits of the device, and / or one or more communication buses connecting only two circuits together. Furthermore, a circuit of the device 100 may be connected to several communication buses.

[0058] [Fig. 2] represents, schematically and in the form of blocks, an embodiment of a software architecture 200 of an electronic device of the type of that described in relation to [Fig.l].

[0059] The architecture 200 comprises a virtual primary platform 210 (VPP), or primary platform 210, for implementing the various functionalities of the electronic device. The primary platform 210 is composed of three levels: - access to electronic components 211 (HW, Hardware) of the electronic device; - one or more low-level operating systems 213 (LLOS); and - one or more software interfaces 215 (API, ABI, VRE, IPC).

[0060] The components 211 are the hardware resources of the electronic device. The components 211 of the secure element 110 are, for example, the one or more processors, for example the processor 101 ([Fig.l]), one or more memories, for example the memories 105 ([Fig.l]), one or more communication devices, such as input / output circuits of the type of circuits 103 ([Fig.l]), such as a Near Field Communication (NFC) device, a short-distance communication device using, for example, the Bluetooth standard, a device adapted to ultra-wideband technology, also known as Ultra Wideband (UWB), or sensors, such as biometric sensors.

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

[0062] A low-level operating system 213 is composed of execution code (or executable code) and execution data. The execution code contains instructions allowing the execution of the program functions. By definition, the instructions are invariable for a given program, except for an update of the program which then modifies the instructions. The execution data is used by the execution code to contextualize the execution and carry out the desired function.

[0063] The primary platform 210 communicates with applications implemented by the secure element 110 via the software interfaces 215 executed by the primary platform. These interfaces 215 may include, among other things: - application programming interfaces (APIs); - registers (VRE, Virtual Register); and - storage buffers, or buffer memories, or shared memories allowing the exchange of data between processes via inter-process communications (IPC - Inter Process Communication).

[0064] Application programming interfaces are software programs that enable multiple applications, described in detail below, to communicate with each other, or with one or more low-level operating systems. In one example, the interface software programs enable a command sent by an application to be converted into a command that can be executed by the low-level operating systems 213.

[0065] The registers are memory spaces linked to a hardware function of the electronic device and used to temporarily store data, for example when a command is sent to the primary platform 210 of the electronic device or during exchanges between processes executed by the primary platform.

[0066] The buffer memories (or shared memories) are used to store messages before their use by the platform 210 or by applications of the electronic device. In practice, the buffer memories are memory spaces allocated in a memory of the element 110 or 100', for example a volatile memory to which the element 110 has access, such as the memory 114.

[0067] By way of example, the software architecture 200 comprises at least three applications 231, 232, 233 adapted to be implemented by the primary platform 210. The applications 231, 232, 233 are software or computer programs using the resources of the primary platform. Of course, the electronic device implements a number of applications within the limit of its computing capacities, and its data storage capacities.

[0068] Like the low-level operating systems 213, each application 231, 232, 233 is composed of an execution code (or executable code) and execution data. The execution code contains instructions allowing the execution of the application's functions. By definition, the instructions are invariable for a given application, except for an update of the program which then modifies the instructions. The execution data is used by the execution code to contextualize the execution and carry out the desired function.

[0069] The applications 231, 232, 233 may each be implemented by a different processor. According to one example, some applications are implemented by the main processor of the electronic device, such as the processor 101, and other applications are implemented by the processor of the secure element, such as the secure element 102.

[0070] The applications 231, 232, 233 can be adapted to implement all kinds of functionalities. They generally implement digital services of a service provider, for example, an EMV-type payment service or a transport ticket. These applications can be combined with another application located in the main processor 101 ([Fig.l]), or in another secure environment (Trusted Execution Environment). The processor and the secure environment are better able to interact with the user via a secure user interface (Trusted User Interface). The applications 231, 232, 233 are, for example, adapted to process commands coming from communication interfaces, such as, for example, a banking transaction using a near-field communication device. These applications can be of different types, for example, a SIM (Subscriber Identity Module) application, a payment application, an application allowing the validation of a public transport ticket, etc.

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

[0072] According to another example of an application type, the application 232 is a set of instructions 232A (App2) adapted to be executed using a high-level operating system 232H (HLOS1). A high-level operating system is software adapted to implement different applications by providing them with a set of common software functions. The operating system 232H is the only part of the application 232 to communicate with the primary platform 210. Alternatively, it may also be considered that the high-level operating system, as well as all the applications attached to it, are a single application adapted to be implemented by the primary platform 210. In addition, a high-level operating system may be an operating system attached to a processor of the electronic device.According to one example, in the remainder of the description, we speak of the high-level operating system of the main processor 101 of the electronic device, this being the high-level operating system implementing the applications executed by the main processor 101. We also speak of the high-level operating system of the secure element 102, this being the high-level operating system implementing the applications executed by the secure element 102.

[0073] According to another example of application type, another application 233 is a set of instructions 233A (App3) using an execution environment 233E (ENV) which itself uses a high-level operating system 233H (HLOS2). The execution environment is, for example, of type Java or JavaCard. The system 233H operating system and the runtime environment 233E are the only parts of the application 233 to communicate with the primary platform 210. Alternatively, the high-level operating system, along with all applications attached to it, may also be considered an application suitable for implementation by the primary platform 210.

[0074] An example of implementation of the application 231, 232, or 233 is as follows. When an application 231, 232, or 233 wishes to use a hardware resource of the secure element, i.e., one or more components 211 of the primary platform 210, this means that the current operations executed on the fixed data are considered to be completed. The application can then execute different commands such as, for example, forcing a write to a non-volatile memory. For this, the application sends a command and / or data to the primary platform 210 via the interfaces 215. The command is handled by one or more application programming interfaces before being sent to the low-level operating systems 213, i.e., the command is divided into several operations. The data is, in turn, stored in registers or transmitted via inter-process communications (IPC).Low-level operating systems 213 respond to requests from binary-to-program interfaces by applying the operations requested by the binary-to-program interfaces to the data stored in registers. Low-level operating systems 213 then drive components 211 to perform what the application requests.

[0075] [Fig. 3] represents, very schematically and in the form of blocks, a first more precise example of software architecture used in an electronic device, of the type described in relation to [Fig. 1], constituting an embodiment.

[0076] As described above, the embodiment of the electronic device comprises a main processor, or application processor, and at least one secure element. The main processor and the secure element are both adapted to implement one or more applications.

[0077] In particular, the main processor implements the following software architecture 300 (CPU_Soft). The main processor implements a high-level operating system 301 (OS1) enabling it to implement one or more applications. In the case illustrated in relation to [Fig. 3], the main processor is adapted to implement, via the high-level operating system 301, two applications 302A (Appl) and 302B (App2). The main processor is, furthermore, adapted to implement certain software included in the primary platform, namely at least one or more application programming interfaces 303 (API) (Application Programming Interface), at least one filtering layer 304 (OMAPI), and at least one low-level operating system 305 (LLOS). According to one example, the software architecture 300 corresponds to the software architecture of a smart mobile phone designated by the commercial name Android.

[0078] The application programming interfaces 303 are interfaces adapted to receive commands and / or data from the application and to convert them before their transmission to other applications or other software layers of the architecture 301. In other words, an application programming interface is a software layer making it possible, among other things, to support the external communications of one or more applications.

[0079] The filtering layer 304 is software forming part of the software interfaces 215 and is adapted to authorize, limit or prohibit an application, for example the applications 302A and 302B, from using all or part of one or more circuits or components of the electronic device. In other words, the filtering layer 304 receives the commands sent by the application programming interfaces 303 and decides whether or not to transmit them depending on the application that formulated the initial command. The filtering layer 304 may be based on different criteria to authorize or not access to the circuits and components of the device 304 to an application. According to an example, the filtering layer 304 may authorize access to one or part of a circuit or component of the electronic device to a first application, and refuse this access to a second application.In one example, the filtering layer 304 is an OMAPI layer defined by the standard commonly referred to as GlobalPlatform.

[0080] According to a first example, if the application is a system application, that is to say an application produced by the manufacturer of the electronic device, or by the manufacturer or designer of the software 303, the application may have permanent authorization to access all circuits or components, or only circuits and components chosen by the manufacturer. Furthermore, conversely, a system application may have limited access, permanent or not, to all or part of one or more circuits or components of the electronic device. Thus, certain parts of circuits or components, or certain circuits or components of the electronic device may only be accessible to system applications, and an application not meeting this criterion will systematically receive a refusal each time it tries to send a command to these parts of circuits or components, or circuits or components.

[0081] According to a second example, the application may be a reliable application having passed various reliability tests with the manufacturer of the electronic device, or with the manufacturer or designer of the interfaces 303, who has therefore permanently authorized it to have access to all or part of the circuits or components of the electronic device. A reliable application of this type may be likened to a system application, and therefore in present the same characteristics.

[0082] According to a third example, the application may have the possibility of authenticating itself, periodically, with a server external to the electronic device to obtain temporary authorization to access all or part of the circuits and components of the electronic device. In the remainder of the description, it will be said that an application is authorized to have access to such a circuit or such a component of the electronic device if the filtering layer 304 authorizes it to access it. According to one example, the temporary authorization to access the circuits and components of the electronic device may be retained by the interfaces 303, the interfaces 303 being, for example, adapted to implement the authentication of the application with the external server.

[0083] According to a fourth example, a circuit or component of the electronic device, for example the secure element 2012, can be adapted to determine which applications have the authorization to implement one or more of its functions. A circuit or component of the electronic device can, for example, provide, to the filtering layer 304, a list indicating which application is authorized to implement one or more of its functions. According to a variant, this circuit or component can provide temporary authorizations to all or part of an application, for example, by authorizing a certain number of uses of one or more of its functions. It is the filtering layer 304 which applies these authorizations at the time when an application sends orders to use one or more functions of one or more circuits or components of the electronic device.According to a preferred embodiment, it is the secure element of the electronic device which comprises a list of rules, for example stored in a memory, indicating the authorizations of the different applications implemented by the electronic device.

[0084] According to a fifth example, the secure element of the electronic device provides a list of access rules to the applications 302A and 302B to the filtering layer 304. The rules are loaded into the filtering layer 304 and applied to each request of the applications 302A and 302B. According to one example, the rule list can be updated directly in the secure element, for example, remotely. After an update of the rule list, the secure element provides the list of modified rules to the filtering layer 304. This operation can be carried out during the restart of the electronic device, or during the operation of the electronic device.

[0085] Furthermore, the secure element implements the following software architecture 350 (SE_Soft). The secure element implements a high-level operating system 351 (SE_OS), considered reliable and secure, and allowing the implementation of one or more applications. In the case illustrated in relation to [Fig. 3], the secure element is adapted to implement, via the high-level operating system 351, two applications 352A (AppSE1) and 352B (AppSE2).

[0086] In addition, the secure element also stores the rules 353 of the interfaces 303 of the main processor. According to one embodiment, it is the secure element which sends the rules 353 to the interfaces 303, it can also, for example, carry out updates of these rules 353.

[0087] In addition, the secure element can implement several low-level operating systems that are independent of each other. In [Fig. 3], the secure element implements two low-level operating systems 354 and 355 that are completely independent of each other.

[0088] According to one embodiment, the low-level operating system 354 is an operating system having the following characteristics. The low-level operating system 354 allows the implementation of a communication using a wireless communication system such as a Near Field Communication (NFC) system, or an Ultra Wide Band (UWB) communication system. The operating system 354 is configured to implement, more particularly, a transaction using this wireless communication system, i.e. a communication in which an exchange of sensitive data, such as identification data, banking data, or the like, can take place. In addition, the applications 352A and 352B are both configured to exchange commands with the low-level operating system 354, for example via the rules 353.In one example, the low-level operating system is the program known as Global Platform (GP) and / or the program known as Java Card Virtual Machine (JCVM).

[0089] According to one embodiment, the low-level operating system 355 is an operating system having the following characteristics. The operating system 355 is adapted to verify the reliability of the high-level operating system 301 of the main processor, and / or to verify the authenticity of the high-level operating system 301 of the main processor. More particularly, the operating system 355 is adapted to verify whether the high-level operating system 301 is still compliant with the version of the high-level operating system 301 produced by the designer of the electronic device. In addition, the operating system 355 is adapted to store the result of this verification. The verification method and its use is described in more detail in relation to [Fig.4]. According to one example, the low-level operating system is the program known as Trust Platform Module (TPM).

[0090] According to one embodiment, the low-level operating systems 354 and 355 are adapted to exchange data and commands between them, for example by using a dedicated communication channel. According to one example, this dedicated communication channel can be a communication bus, a shared memory, or a common register.

[0091] Furthermore, according to one example, the secure element may consist of two separate electronic chips, a first chip implementing the high-level operating system 351, the applications 352A and 352B, the rules 353 and the low-level operating system 354, and a second chip implementing the low-level operating system 355. These two different chips are signified by dotted blocks in [Fig. 3]. According to another example, the two chips may be considered as two separate secure elements.

[0092] According to another example, the high-level operating system 351, the applications 352A and 352B, the rules 353 and the low-level operating system 354, and the low-level operating system 355 can be implemented by a single electronic chip, this chip being adapted to adapt its operation according to the low-level operating system 354 or 355 implemented.

[0093] [Fig.4] is a block diagram representing an embodiment of a method for protecting the device whose software architecture is described in relation to [Fig.3],

[0094] The method for protecting the electronic device comprises two phases. A first BOOT phase takes place during the startup of the electronic device, and a second COMM phase takes place when an application implemented by the main processor requests to communicate with an application implemented by the secure element.

[0095] During the first BOOT phase, at a first step 401 (BOOT START), the electronic device starts in hardware and software.

[0096] At a step 402 (LLOS2 Verif OS), following step 401, the low-level operating system 355, described in relation to [Fig. 3], performs a verification of the software architecture 300, i.e. the high-level operating system 301 and the software layers 303 to 305, described in relation to [Fig. 3], of the main processor of the electronic device. By this verification, the low-level operating system 355 determines whether the software architecture 300 is reliable, or authentic, i.e. allowing exchanges of sensitive or secret data between the high-level operating system 301 and the applications 302A and 302B that it implements. According to one example, by this verification, the low-level operating system 355 determines whether the software architecture 300 is authentic, i.e. provided by the manufacturer of the architecture 300 or of the device implementing it.To do this, the low-level operating system 355 may, for example, verify all or part of the programming code of the software architecture 300. In addition, the low-level operating system 355 may determine that one or more parts of the software architecture 300 are reliable, and that one or more other parts of . software architecture 300 are unreliable. Once the verification is performed, the low-level operating system 355 stores the result.

[0097] According to a variant, if the main processor of the electronic device implements several high-level operating systems of the type of the software architecture 300, then, at step 402, the low-level operating system 355 carries out the verification of all the operating systems implemented by the main processor. According to another variant, the low-level operating system could only carry out the verification of certain high-level operating systems of the software architecture, such as for example, the main high-level operating systems, or the verification of only certain software layers of the software architecture 300.

[0098] At a step 403 (BOOT END), following step 402, the electronic device has completed its startup, and is ready for use.

[0099] During the second COMM phase, at a first step 451 (App -> AppSE), an application implemented by the high-level operating system 301 of the main processor, for example the application 302A, requests to contact an application implemented by the high-level operating system 351 of the secure element, for example the application 352A. More particularly, the application 302A sends a request to an application programming interface 303. This request is verified by the filtering interface 304, and if the filtering interface 304 validates the request, then the low-level operating system 305 of the main processor transfers the request to the secure element. Since the request is intended for the application 352A, it is the low-level operating system 354 which receives the request.

[0100] At a step 452 (Verif OS1), the low-level operating system 354 receives the request initiated by the application 302A, and does not transmit the request to the recipient application 352A until it has ensured that the high-level operating system 301 implementing the application 302A is reliable. For this, the operating system 354 queries the low-level operating system 355 on the reliability of the software architecture 300. The low-level operating system 355 transmits the result of the verification carried out during the first BOOT phase to the low-level operating system 354. The low-level operating system 354 can then transmit the request to the recipient application 352A, and make the result of the verification accessible to the application 352A. According to a first example, the low-level operating system 354 can send the result of the verification with the request to the application 352A.According to a second example, the low-level operating system 354 may make the information accessible via an application programming interface of the same type as the interfaces 303, to the application 352A.

[0101] The application 352A having access to the result of the verification, it can take into account takes into account the information. If the software architecture 300 is considered reliable (output Y of step 452), the next step is a step 453 (Executed Req), otherwise (output N of step 452), the next step is a step 454 (Stop Req).

[0102] In step 453, the software architecture 300 is considered reliable, the application 352A can process and, if necessary, respond to the request from the application 302A, for example by using sensitive or secret data.

[0103] In step 454, the software architecture 300 is considered unreliable, at least in part, the application 352A therefore takes this information into account. According to a first example, the application 352A may decide not to process and, if applicable, not to respond to the request from the application 302A, for example by not returning any data or by returning error data or random data. According to a second example, the application 352A may decide to process in part and, if applicable, to respond only in part to the request from the application 302A, for example by not disclosing any sensitive or secret data.According to a third example, the application 352A may still decide to process and, if necessary, respond to the request from the application 302A, for example if the request received does not concern any sensitive or secret data, or for example if the request received does not endanger the application 352A, such as a denial of service attack.

[0104] [Fig.5] represents, very schematically and in the form of blocks, a second more precise example of software architecture used in an electronic device, of the type described in relation to [Fig.l], constituting an embodiment.

[0105] This second example may include elements in common with the first example described in relation to [Fig.3]. These common elements are not described again in detail here, and only the differences between these two examples are highlighted.

[0106] In this second example, the main processor may use the same software architecture 300 as in the first example, or an architecture of the same type. The secure element uses a software architecture 500 comprising elements in common with the architecture 350 described in relation to [Fig.3].

[0107] Like the software architecture 350, the software architecture 500 comprises the high-level operating system 351 (SE_OS), considered reliable and secure, and allowing the implementation of one or more applications, in the case illustrated in relation to [Fig. 3], two applications 352A (AppSE1) and 352B (AppSE2). In addition, the software architecture 500 may comprise the rules 353 of the interfaces 303 of the main processor. According to one example, the software architecture 500 may comprise the low-level operating system 354 allowing the implementation of the applications 352A and 352B. According to one example, and optionally, the architecture software 500 may also include the low-level operating system 355 described in connection with [Fig.3].

[0108] According to one embodiment, the software architecture 500 further comprises an application programming interface 501 (T. HOST) configured to verify whether the commands received by the applications implemented by the secure element, i.e. the applications 352A and 352B in the case of [Fig. 5], have been sent reliably. For this, the application programming interface 501 can be configured to implement several different verification means, or different verification rules, some of which are detailed below. Once the verification has been carried out, the result of this verification is transmitted to the application receiving the command, in parallel with the command itself. The application analyzes this result and deduces whether or not it can process, in part or in full, said command.Additionally, the application programming interface 501 is further configured to validate the authenticity of the verification(s) it performs.

[0109] An example of a means of verification may be to verify that the sender of the order is reliable.

[0110] The sender of the command may be, according to a first example, one of the applications implemented by the main processor of the electronic device. In this case, the application programming interface 501 may verify the reliability of the application in question. If the architecture comprises the low-level operating system 355, the application programming interface 501 may communicate with the low-level operating system 355 to use the result of the verification of the high-level operating system 301 described in relation to FIGS. 3 and 4.

[0111] The sender of the command may be, according to a second example, an electronic system external to the electronic device, and implementing communication with said electronic device. According to one example, the communication may be a wired communication or a wireless communication such as a near field communication (NFC) or an ultra-wideband communication (UWB). According to one example, the electronic system may be an electronic system with which the electronic device is adapted to be coupled, for example using a pairing function 502 (PAIR). The pairing function 502 may be implemented by the same chip as the low-level operating system 355, by the low-level operating system 354, or even be implemented by an application programming interface implemented by the same chip as the low-level operating system 354.

[0112] Another example of a means of verification may be to verify that the communication channel used to transmit the commands.

[0113] Other means of verification are within the reach of those skilled in the art.

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

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

Claims

Claims

1. Electronic device (100) comprising a secure element (102) adapted to implement at least one first application (352A, 352B), and an application programming interface (501) configured to verify whether a command received by said at least one first application (352A, 352B) has been sent reliably, wherein once said application programming interface (501) has carried out the verification, said application programming interface (501) transmits said command to said at least one first application (352A, 352B), and sends the result of this verification to said first application (352A, 352B).

2. The device of claim 1, wherein the application programming interface (501) is configured to use multiple verification means.

3. Device according to claim 1 or 2, wherein the application programming interface (501) is configured to check whether the sender of said command is reliable.

4. Device according to claim 3, wherein the sender is a second application (302A, 302B) implemented by a high-level operating system (301) of a processor (101) included in said electronic device.

5. The device of claim 4, wherein the application programming interface (501) is configured to check whether said high-level operating system (301) is trusted.

6. The device of claim 4, wherein the application programming interface (501) is configured to verify whether said high-level operating system (301) is authentic.

7. Device according to claim 5 or 6, wherein the secure element (102) implements a first low-level operating system (354) implementing said first application (352A, 352B), and a second low-level operating system (355) configured to verify whether the high-level operating system (301) of said processor is reliable or authentic, the application programming interface (501) verifies that said high-level operating system (301) is reliable by communicating with said first low-level operating system (354) of the secure element (102).

8. Device according to any one of claims 1 to 7, wherein the sender is an electronic system independent of the electronic device (101), said electronic system being adapted to be coupled with said electronic device.

9. A device according to claim 8, wherein said electronic system is adapted to be coupled with said electronic device using a coupling function (502).

10. The device of any one of claims 1 to 9, wherein the application programming interface (501) is further configured to verify that the communication channel used to transmit the command is a reliable channel.

11. Device according to any one of claims 1 to 10, wherein the application programming interface (501) is further configured to validate the authenticity of the verification of said command received by said at least one first application (352A, 352B).

12. Device according to claim 10 or 11, wherein said verification is carried out by implementing verification means configurable by the application programming interface (501) as a function of the coupling function (502).

13. A method for protecting an electronic device comprising a secure element (102) adapted to implement at least one first application (352A, 352B), and an application programming interface (501) configured to verify whether a command received by said at least one first application (352A, 352B) has been sent reliably, wherein once said application programming interface (501) has performed the verification, said application programming interface (501) transmits said command to said at least one first application (352A, 352B), and sends the result of this verification to said first application (352A, 352B).

Images