CN118246040A

CN118246040A - Protection of electronic devices

Info

Publication number: CN118246040A
Application number: CN202311787283.4A
Authority: CN
Inventors: O·范尼乌文胡泽; A·查尔斯
Original assignee: Proton World International Co ltd; STMicroelectronics Rousset SAS
Current assignee: Proton World International Co ltd; STMicroelectronics Rousset SAS
Priority date: 2022-12-22
Filing date: 2023-12-22
Publication date: 2024-06-25

Abstract

The present disclosure relates to protection of electronic devices. The electronic device includes a secure element and an application programming interface. The secure element executes a first application in operation. The application programming interface verifies in operation the authenticity of the received command for the first application and transmits the command and the verified result to the first application.

Description

Protection of electronic devices

Technical Field

The present disclosure relates generally to electronic devices, and more particularly to electronic devices adapted to process secret data. More particularly, the present disclosure relates to electronic devices adapted to enable wireless communication such as Near Field Communication (NFC) or ultra wideband communication (UWB), and wherein at least a portion of the exchanged data is secret data and/or a portion of the exchanged data is critical or private data, which allows for example a method of identifying or authenticating a user, or enables for example locating a user.

Background

Over time, complex electronic devices such as cellular phones, electronic tablets, computers, etc. integrate more and more functions and enable digital services to be provided to best integrate into everyday life. As an example, some cellular phones and more particularly smartphones integrate digital services, such as bank payment services, or public transportation ticket usage services, performance tickets, or also digital key services, where authentication of the user may be achieved by a remote system (bank, public administration etc.). To achieve these functions, these devices may integrate electronic components specific to these functions, such as, for example, security components that enable the holding/storage of identification, reference and authentication information, commonly referred to as "credentials", and assets of digital service providers, motion sensors, wireless communication modules such as Near Field Communication (NFC) modules or ultra-wideband communication (UWB) modules, and the like.

A difficulty caused by adding new functionality is that secret data and/or critical or private data are exchanged between different modules and/or software layers of the same electronic device without protection.

Disclosure of Invention

In an embodiment, an electronic device includes a secure element and an application programming interface. The secure element executes a first application in operation. The application programming interface verifies in operation the authenticity of the received command for the first application and transmits the command and the verified result to the first application.

In an embodiment, a system includes a processor, a secure element that executes a first application in operation, and an application programming interface. The application programming interface verifies in operation the authenticity of the received command for the first application and transmits the command and the verified result to the first application.

In an embodiment, a method includes: executing a first application using a secure element of the device; verifying the authenticity of the received command for the first application using an application programming interface of the device; and transmitting the result of the command and verification to the first application using the application programming interface.

In an embodiment, the content of a non-transitory computer readable medium configures an electronic device to perform a method comprising: executing a first application using a secure element of the electronic device; verifying, using an application programming interface of the electronic device, the authenticity of the received command for the first application; and transmitting the result of the command and verification to the first application using the application programming interface.

Drawings

The above features and advantages and other features and advantages will be described in detail in the remaining part of the disclosure with reference to the specific embodiments, given by way of example and not limitation, with reference to the accompanying drawings, in which:

Fig. 1 very schematically shows in block diagram form an example of an electronic device to which the embodiments of fig. 2-5 may be applied;

FIG. 2 very schematically illustrates in block diagram form a software architecture of an electronic device;

FIG. 3 very schematically illustrates in block diagram form a first embodiment of an electronic device that processes critical or private data;

FIG. 4 shows a block diagram of one implementation of the embodiment of FIG. 3; and

Fig. 5 very schematically shows in block diagram form a second embodiment of an electronic device for processing critical or private data.

Detailed Description

Like features are indicated by like reference numerals in the various figures. In particular, structural and/or functional features common between the various embodiments may have the same reference numerals and may deploy the same structural, dimensional, and material characteristics.

For clarity, only the steps and elements useful for understanding the described embodiments are illustrated and described in detail. In particular, the operation of different types of wireless communications that can be implemented by embodiments is not described in detail.

Unless otherwise indicated, when two elements are referred to as being connected together, this means that there is no direct connection of any intermediate elements other than conductors, and when two elements are referred to as being coupled together, this means that the two elements can be connected or they can be coupled via one or more other elements.

In the following description, when referring to terms such as "front," "rear," "top," "bottom," "left," "right," etc., which define an absolute position, or relative positions, terms such as "above," "below," "upper," "lower," etc., or terms such as "horizontal," "vertical," etc., which define a direction, unless otherwise specified, refer to the orientation of the drawing figures.

Unless otherwise indicated, the expressions "about", "substantially" and "about" mean plus or minus 10%, plus or minus 5%.

Fig. 1 very schematically shows in block diagram form an example of an electronic device 100 to which the embodiments described in relation to fig. 2-5 may be applied.

The device 100 is an electronic device adapted to process data and is particularly adapted to process critical or proprietary data. In the remainder of this disclosure, there is so-called "critical" or private data, which includes secret or potentially secret information, or information that is considered private to a natural person (such as a user). In other words, critical or private data is data that is not accessible to all persons and that should not be shared with any arbitrary electronic device.

The device 100 comprises a processor 101 (CPU) enabling processing of data. According to an example, the device 100 may comprise a plurality of processors, each processor being adapted to process different types of data. According to a specific example, the device 100 may include a main processor and one or more auxiliary processors.

The device 100 also includes one or more secure elements 102 (SE) that enable critical or private data to be managed, such as the storage or use of such data, or enable, for example, secure applications to be implemented. The secure element 102 may include its own dedicated processor(s) and its own memory(s). In the remainder of this disclosure, the secure element 102 and its operating system are considered to be reliable and tamper-resistant. In the remainder of the present disclosure, the expression "secure element" in the following indifferently means an embedded secure element or an integrated secure element.

The device 100 includes one or more input/output circuits 103 (I/O) that enable the device 100 to transmit and/or receive data and/or power with one or more external electronic devices. In particular, the circuit enables management of communications with other devices, such as circuits or modules, enabling management of wired communications, such as communications using the USB protocol, and/or wireless communications, such as Wifi communications, bluetooth communications, and/or Near Field Communications (NFC). The device more precisely comprises at least one NFC module, i.e. a module adapted for Near Field Communication (NFC), and/or a UWB module, i.e. a module adapted for ultra wideband communication (UWB).

The device 100 includes one or more circuits 104 (ALIM) responsible for the power supply of the device 100. According to an example, the circuit 104 may include one or more batteries, power conversion circuitry, charging circuitry, and the like.

The device 100 includes one or more memories 105 (MEM) in which data, such as binary data, is stored. According to an example, the device 100 includes a variety of memory types, such as ROM, volatile and/or nonvolatile memory.

The device 100 includes one or more circuits 106 (FCTs) that implement one or more functions of the device 100. According to an example, the circuit 106 may include specific data processing circuitry, such as cryptographic circuitry, or circuitry that enables measurements to be performed, such as sensors.

The device 100 includes one or more communication buses 107 that enable the circuitry of the device 100 to communicate. In fig. 1, a single bus 107 is shown coupling processor 101, one or more memories 102, and circuits 103 through 106, but in practice device 100 may include multiple communication buses coupling these different elements. In particular, device 100 may include multiple communication buses shared by more than two circuits of the device, and/or one or more communication buses coupling only two circuits together. Further, the circuitry of device 100 may be coupled to multiple communication buses.

Fig. 2 schematically illustrates in block diagram form an embodiment of a software architecture 200 for an electronic device of the type described in relation to fig. 1.

Architecture 200 includes a virtual host platform 210 (VPP) or host platform 210 that enables different functions of an electronic device. The main platform 210 is made up of three levels:

Access to electronic components 211 (HW, hardware) of the electronic device;

one or more lower level operating systems 213 (LLOS); and

One or more software interfaces 215 (API, ABI, VRE, IPC).

Component 211 is the hardware of the electronic device. The component 211 of the secure element (see secure element 102 of fig. 1) is, for example, one or more processors, for example, processor 101 (fig. 1), one or more memories, for example, memory 105 (fig. 1), one or more communication devices, such as input/output circuits of the type of circuit 103 (fig. 1), such as Near Field Communication (NFC) devices, short range communication devices using, for example, the bluetooth standard, devices adapted for ultra wideband technology (UWB), or also sensors, such as biometric sensors.

The low-level operating system 213 is software adapted to implement the component 211 to execute commands received from applications implemented by the secure element. By way of example, the lower level operating system 213 includes all or part of the driver software for the component 211.

The lower operating system 213 is made up of executable code and execution data. The executable code contains instructions that allow the execution of program functions. By definition, an instruction is unchanged for a given program unless the program updates and then modifies the instruction. The executable code uses the execution data to place the execution in context and perform the desired functions.

The host platform 210 communicates with applications implemented by the secure element via a software interface 215 executed by the host platform. These interfaces 215 may include, among others:

an Application Programming Interface (API);

registers (VRE, virtual registers); and

A memory buffer, or a buffer memory, or also a shared memory, which allows data to be exchanged between processes via inter-process communication (IPC).

An application programming interface is software that enables multiple applications, described in detail below, to communicate together or with one or more lower-level operating systems. According to an example, the interface software enables converting commands sent by the application into commands executable by the lower-level operating system 213.

A register is a memory space linked to the hardware functions of the electronic device and used to temporarily store data, for example, when a command is sent to the host platform 210 of the electronic device or during an exchange between processes performed by the host platform.

The buffer memory (or shared memory) is used to store messages before the platform 210 or an application of the electronic device uses the messages. In practice, buffer memory is memory space allocated in memory of element 210 or 100 (e.g., volatile memory accessible to element 210, such as memory 105).

As an example, the software architecture 200 includes at least three applications 231, 232, 233 adapted to be implemented by the host platform 210. The applications 231, 232, 233 are software or computer programs that use the assets of the host platform. Of course, electronic devices implement a variety of applications within the limitations of their computing power and their data storage capabilities.

Similar to the lower operating system 213, each application 231, 232, 233 is made up of executable code and execution data. The executable code contains instructions that allow the execution of the functions of the application. By definition, an instruction is unchanged for a given application unless the program updates and then modifies the instruction. The executable code uses the execution data to place the execution in context and perform the desired functions.

The applications 231, 232, 233 may each be implemented by different processors. According to an example, some applications are implemented by a main processor (e.g., processor 101) of an electronic device, and other applications are implemented by a processor of a secure element (such as secure element 102).

The applications 231, 232, 233 may be adapted to implement various functions. They typically implement digital services of a service provider, such as EMV or a payment service of the traffic ticket type. These applications may be combined with another application present in the host processor 101 (fig. 1) or in another trusted execution environment. The processor and trusted execution environment are further capable of interacting with a user via a trusted user interface. The applications 231, 232, 233 are for example adapted to process commands originating from a communication interface, such as for example banking transactions using a near field communication device. These applications may be of different types, e.g. SIM (subscriber identity module) applications, payment applications, applications allowing verification of public transportation tickets, etc.

According to an example of an application type, the application 231 (App 1) is adapted to be directly implemented by the host platform 210 (VPP). The application 231 is, for example, an application that enables payment by communication with a Near Field Communication (NFC) device.

According to another example of an application type, the application 232 is a set of instructions 232A (App 2) adapted to be executed using a high level operating system 232H (HLOS 1). A high-level operating system is software adapted to implement different applications by providing a common set of software functions for the different applications. The operating system 232H is the only part of the application 232 that communicates with the host platform 210. As a variant, the high-level operating system and all applications attached thereto may also be considered a single application suitable for implementation by the host platform 210. In addition, the high-level operating system may be an operating system attached to a processor of the electronic device. According to an example, in the remainder of this disclosure, reference is made to the high-level operating system of the main processor 101 of the electronic device, which is then the high-level operating system implementing the applications executed by the main processor 101. Reference is also made to the high-level operating system of the secure element 102, which is then the high-level operating system that implements the applications executed by the secure element 102.

According to another example of an application type, another application 233 is a set of instructions 233A (App 3) using an execution environment 233E (ENV), which itself uses a high-level operating system 233H (HLOS 2). The execution environment is, for example, a Java or JavaCard type. Operating system 233H and execution environment 233E are the only parts of application 233 that communicate with host platform 210. As a variant, the high-level operating system and all applications attached thereto may also be considered applications suitable for implementation by the host platform 210.

An implementation example of the application 231, 232, or 233 is as follows. When an application 231, 232, or 233 desires to use the hardware assets of the secure element (i.e., one or more components 211 of the host platform 210), this means that the current operation performed on the fixed data is deemed complete. The application may then execute different commands, such as, for example, forced writing into non-volatile memory. To this end, the application sends commands and/or data to the host platform 210 via the interface 215. The command is responsible for one or more application programming interfaces, i.e., the command is divided into a plurality of operations, before being sent to the lower operating system 213. The data is stored in registers or transmitted via inter-process communication (IPC). The lower-level operating system 213 responds to the binary program interface request by applying the binary program interface requested operation to the data stored in the registers. The lower operating system 213 then drives the component 211 to execute the content requested by the application.

Fig. 3 very schematically shows in block diagram form a more specific first example of a software architecture for use in an electronic device of the type described in relation to fig. 1, constituting an embodiment.

As previously described, an embodiment of an electronic device includes a host processor or application processor and at least one secure element. The host processor and the secure element are each adapted to implement one or more applications.

In particular, the host processor implements the following software architecture 300 (CPU_Soft). The host processor implements a high-level operating system 301 (OS 1) so that it can implement one or more applications. In the case shown with respect to fig. 3, the main processor is adapted to implement two applications 302A (App 1) and 302B (App 2) via the higher-level operating system 301. The host processor is adapted to implement given software included in the host platform, namely at least one or more application programming interfaces 303 (APIs), at least one filter layer 304 (OMAPI), and at least one lower-level operating system 305 (LLOS). According to an example, the software architecture 300 corresponds to the software architecture of a smartphone specified by the trade name Android.

The application programming interface 303 is an interface adapted to receive commands and/or data from applications and convert them before they are transferred to other applications or other software layers of the architecture 301. In other words, an application programming interface is a software layer that enables to be responsible for external communication of one or more applications, etc.

Filter layer 304 is software that forms part of software interface 215 and is adapted to authorize, restrict, or prohibit applications (e.g., applications 302A and 302B) from using all or part of the various circuits or components of the electronic device. In other words, the filter layer 304 receives commands sent by the application programming interface 303 and decides whether to transmit them according to the application making the initial command. The filter layer 304 may grant or not grant applications access to the circuitry and components of the device based on different criteria. According to an example, the filter layer 304 may authorize access by a first application to a circuit or component of the electronic device or a portion thereof, and prohibit such access to a second application. According to an example, the filter layer 304 is an OMAPI layer defined by a standard currently specified by the name GlobalPlatform.

According to a first example, if the application is a system application (i.e., 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 of the circuits or elements, or only to access circuits and elements selected by the manufacturer. Additionally, rather, the system application may have permanent or non-permanent limited access to all or part of the various circuits or components of the electronic device. Thus, certain portions of a circuit or component or certain circuits or components of an electronic device may only be accessible to system applications, and applications that do not meet the criteria will systematically receive a rejection each time they attempt to send a command to those portions of a circuit or component or circuit or component.

According to a second example, the application may be a reliable application that has been successfully submitted to the manufacturer of the electronic device or the manufacturer or designer of the interface 303 for different reliability tests, thus permanently authorizing it to access all or part of the circuitry or components of the electronic device. This type of reliable application may be considered equivalent to a system application and thus have the same characteristics.

According to a third example, an application may have the possibility to periodically authenticate with a server external to the electronic device to obtain temporary authorization of access to all or part of the circuitry and components of the electronic device. In the remainder of this disclosure, it can be said that if the filter layer 304 authorizes an application to access such circuitry or such components of the electronic device, the application is authorized to access such circuitry or such components of the electronic device. According to an example, temporary authorization for access to circuitry and components of the electronic device may be maintained by the interface 303, the interface 303 being adapted to enable authentication of applications using an external server, for example.

According to a fourth example, circuitry or components of the electronic device (e.g., secure element 102) may be adapted to determine which applications are authorized to implement one or more of its functions. The circuitry or components of the electronic device may, for example, provide a list to the filter layer 304 indicating what applications are authorized to implement one or more of their functions. According to a variant, the circuit or component may communicate temporary authorization to all or part of the application, for example by authorizing multiple uses of one or more of its functions. The filter layer 304 applies these authorizations when the application sends an indication (order) to use one or more functions of one of the plurality of circuits or components of the electronic device. According to an embodiment, the secure element of the electronic device comprises a rule list, e.g. stored in a memory, indicating the authorization of different applications implemented by the electronic device.

According to a fifth example, the secure element of the electronic device passes the list of access rules for applications 302A and 302B to filter layer 304. These rules are loaded into filter layer 304 and applied each time an application 302A and 302B is requested. According to an example, the rule list may be updated directly in the secure element, e.g. remotely. After updating the rule list, the secure element passes the modified rule list to the filter layer 304. This operation may be performed during reboot of the electronic device or during operation of the electronic device.

The secure element implements the following software architecture 350 (se_soft). The secure element implements a high-level operating system 351 (se_os), which is considered reliable and secure, and enables one or more applications to be implemented. In the case shown with respect to fig. 3, the secure element is adapted to implement two applications 352A (AppSE 1) and 352B (AppSE) via the high-level operating system 351.

The secure element also stores rules 353 of the interface 303 of the host processor. According to an embodiment, the security element sends rules 353 to the interface 303, which may also perform, for example, an update of these rules 353.

In addition, the secure element may implement multiple low-level operating systems 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.

According to an embodiment, the low-level operating system 354 is an operating system having the following features. The lower-level operating system 354 enables communication using wireless communication systems, such as Near Field Communication (NFC) systems or Ultra Wideband (UWB) communication systems. More particularly, the operating system 354 is configured to enable transactions using the wireless communication system, i.e., communications in which exchange of critical or private data, such as identification data, banking data, etc., may occur. In addition, both applications 352A and 352B are configured to exchange commands with a lower operating system 354, e.g., via rules 353. According to an example, the lower operating system is a program known as Global Platform (GP) and/or a program known as Java Card Virtual Machine (JCVM).

According to an embodiment, the low-level operating system 355 is an operating system exhibiting the following features. The operating system 355 is adapted to verify the authenticity of the host processor's high-level operating system 301 and/or to verify the authenticity of the host processor's high-level operating system 301. More particularly, the operating system 355 is adapted to verify that the higher-level operating system 301 still complies with the version of the higher-level operating system 301 produced by the designer of the electronic device. In addition, the operating system 355 is adapted to store the results of the verification. The verification method and its use are described in further detail with respect to fig. 4. According to an example, the lower-level operating system is a program known as a trusted platform module (Trust Platform Module, TPM).

According to an embodiment, the lower-level operating systems 354 and 355 are adapted to exchange data and commands with each other, for example, by using dedicated communication channels. The dedicated communication channel may be a communication bus, a shared memory, or a common register, depending on the example.

In addition, according to an example, the secure element may be composed of two different 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 indicated in fig. 3 by dashed boxes. According to another example, two chips may be considered as two different secure elements.

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 may be implemented by a single electronic chip adapted to adapt its operation according to the implemented low-level operating system 354 or 355.

Fig. 4 is a block diagram illustrating an embodiment of a method of protecting a device having the software architecture described with respect to fig. 3.

The protection method of the electronic device comprises two stages. The first phase BOOT (BOOT) occurs during booting of the electronic device and the second phase Communication (COMM) occurs when an application query implemented by the host processor communicates with an application implemented by the secure element.

During a first phase BOOT (BOOT), at a first step 401 (BOOT START), the electronic device is started in hardware and in software.

At step 402 (LLOS verify OS) following step 401, the verification of the software architecture 300 is performed with respect to the lower-level operating system 355 described in relation to fig. 3, i.e. the verification of the higher-level operating system 301 and the verification of the software layers 303 to 305 of the main processor of the electronic device described with reference to fig. 3. With this verification, the lower-level operating system 355 determines whether the software architecture 300 is reliable or authentic, i.e., allows critical or private or secret data to be exchanged between the higher-level operating system 301 and the applications 302A and 302B that it implements. According to an example, through this verification, the lower-level operating system 355 determines whether the software architecture 300 is authentic, i.e., provided by the manufacturer of the architecture 300 or the device implementing it. To this end, the lower-level operating system 355 may, for example, verify all or part of the programming code of the software architecture 300. In addition, the lower-level operating system 355 may determine that one or more portions of the software architecture 300 are reliable and that one or more other portions of the software architecture 300 are unreliable. Once verification is performed, the lower operating system 355 stores the results thereof.

According to a variant, if the main processor of the electronic device implements a plurality of high-level operating systems of the type of software architecture 300, then at step 402, the low-level operating system 355 performs verification of all operating systems implemented by the main processor. According to another variation, the lower level operating system may perform verification of only certain higher level operating systems of the software architecture (such as, for example, the main higher level operating system) or verification of only certain software layers of the software architecture 300.

At step 403 (BOOT END) after step 402, the electronic device has ended its BOOT and is ready to be used.

During the second phase Communication (COMM), at a first step 451 (App- > AppSE), an application (e.g., application 302A) implemented by the high-level operating system 301 of the host processor queries to connect to an application (e.g., application 352A) implemented by the high-level operating system 351 of the secure element. More specifically, the application 302A sends a request to the application programming interface 303. The request is verified by the filter interface 304 and if the filter interface 304 verifies the request, the lower operating system 305 of the host processor communicates the request to the secure element. Because the request is for application 352A, lower operating system 354 receives the request.

At step 452 (verify OS 1), the lower-level operating system 354 receives the request initiated by application 302A and does not transmit the request to the addressee application 352A as long as the higher-level operating system 301 implementing application 302A has not been ensured to be reliable. To this end, the operating system 354 queries the lower operating system 355 for reliability with respect to the software architecture 300. The lower operating system 355 transmits the result of the verification performed during the first phase BOOT (BOOT) to the lower operating system 354. The lower-level operating system 354 may then transmit the request to the addressee application 352A and make the verified result accessible to the application 352A. According to a first example, the lower-level operating system 354 may send the verified results to the application 352A along with the request. According to a second example, lower-level operating system 354 may make information accessible to application 352A via an application programming interface of the same type as interface 303.

After application 352A has access to the verified results, it can consider the information. If the software architecture 300 is deemed reliable (output of step 452 is yes), then the next step is step 453 (execute request), otherwise (output of step 452 is no), the next step is step 454 (stop request).

At step 453, the software architecture 300 is deemed reliable, and the application 352A may process and (if relevant) answer the request of the application 302A, e.g., by using critical or private or secret data.

At step 454, the software architecture 300 is deemed at least partially unreliable, and therefore the application 352A considers this information. According to a first example, the application 352A may decide not to process the request from the application 302A and (if relevant) not to answer the request from the application 302A, for example by not returning data or by returning error data or random data. According to a second example, the application 352A may decide to process the request from the application 302A in part and (if relevant) only answer the request from the application 302A in part, e.g. by not disclosing critical or private or secret data. According to a third example, the application 352A may decide to process the request from the application 302A anyway and (if relevant) answer the request from the application 302A, for example if the received request does not relate to critical or private or secret data, or for example if the received request does not jeopardize the application 352A, such as for example a denial of service type attack.

Fig. 5 very schematically shows in block diagram form a second more specific example of a software architecture for use in an electronic device of the type described in relation to fig. 1, constituting an embodiment.

This second example may include elements common to the first example described with respect to fig. 3. These common elements are not described in detail again herein and only the differences between these two examples are emphasized.

In this second example, the host processor may use the same software architecture 300 as in the first example, or the same type of architecture. The secure element uses a software architecture 500 that includes elements in common with the architecture 350 described with respect to fig. 3.

Similar to software architecture 350, software architecture 500 includes a high-level operating system 351 (se_os) that is considered reliable and secure and enables implementation of one or more applications, in the case shown with respect to fig. 3, two applications 352A (AppSE 1) and 352B (AppSE). In addition, the software architecture 500 may include rules 353 for the interface 303 of the host processor. According to an example, the software architecture 500 may include a low-level operating system 354 that enables the implementation of applications 352A and 352B. According to an example and optionally, the software architecture 500 may also include a low-level operating system 355 described with respect to fig. 3.

According to an embodiment, the software architecture 500 further comprises an application programming interface 501 (t.host) configured to verify whether commands received by applications implemented by the secure element (i.e. applications 352A and 352B in the case of fig. 5) have been reliably sent. To this end, the application programming interface 501 may be configured to implement a plurality of different verification devices or different verification rules, some of which are described in detail below. Once verification is performed, the result of the verification is transmitted in parallel with the actual command to the application to which the command is addressed. The application analyzes the result and deduces therefrom whether it can process the command in part or in whole. In addition, the application programming interface 501 is also configured to verify the authenticity of the verification it performs.

An example of a verification device may be to verify that the sender of the command is authentic.

According to a first example, the sender of the command may be 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 includes a low-level operating system 355, the application programming interface 501 may communicate with the low-level operating system 355 to use the results of the verification of the high-level operating system 301 described with respect to FIGS. 3 and 4.

According to a second example, the sender of the command may be an electronic system external to the electronic device and enable communication with the electronic device. According to an example, the communication may be a wired communication or a wireless communication, such as Near Field Communication (NFC) or ultra-wideband communication (UWB). According to an example, the electronic system may be an electronic system with which the electronic device is adapted to PAIR, e.g. by using a pairing function 502 (PAIR). Pairing function 502 may be implemented by the same chip as lower operating system 355, by lower operating system 354, or may also be implemented by an application programming interface implemented by the same chip as lower operating system 354.

Another example of a verification device may be to verify a communication channel for transmitting commands.

Other verification means are within the ability of those skilled in the art.

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

Finally, based on the functional indications given above, the actual implementation of the described embodiments and variants is within the competence of a person skilled in the art.

According to a first aspect, an embodiment provides an electronic device, comprising:

a processor adapted to implement at least one first high-level operating system and at least one first application;

A secure element adapted to implement a first low-level operating system configured to enable verification of authenticity or authenticity of the first operating system and a second low-level operating system configured to enable at least one second application and to enable at least one wireless communication or to communicate with the at least one first application,

Wherein, at each boot of the electronic device, the first lower-level operating system performs verification of the authenticity or authenticity of the first higher-level operating system, and

When the at least one first application sends a request to the at least one second application, the second lower operating system queries the first lower operating system for the result and makes it accessible to the second application.

Another embodiment provides a method of protecting an electronic device, the electronic device comprising:

According to an embodiment, when the result indicates that the first higher-level operating system is reliable or authentic, then the at least one second application accepts the request from the at least one first application.

According to an embodiment, when the result indicates that the first operating system is unreliable or not truly, then the at least one second application is able to reject, partially accept or fully accept the request from the at least one first application.

According to an embodiment, the at least one second application considers the list of access authorization rules of the at least one first application when the at least one second application refuses, partially accepts or fully accepts the request from the at least one first application.

According to an embodiment, the first lower operating system stores the result when the first lower operating system performs a kernel on the reliability of the first operating system.

According to an embodiment, the second lower operating system sends the result to the at least one second application when the second lower operating system makes the result accessible to the second application.

According to an embodiment, when the second lower operating system makes the results accessible to the second application, the second lower operating system makes the results available to the at least one second application via the first application programming interface.

According to an embodiment, the first high-level operating system is a program known as a trusted platform module.

According to an embodiment, the second lower operating system is a program known as global platform and/or a program known as a Java card virtual machine.

According to an embodiment, the first lower operating system and the second lower operating system are adapted to communicate via a dedicated communication channel.

According to an 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.

According to an embodiment, the first chip is considered to be a first secure element and the second chip is considered to be a second secure element.

According to an 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 reliably sent.

According to an embodiment, wherein the second application programming interface is configured to use a plurality of verification devices.

According to an embodiment, the second application programming interface is configured to verify whether the sender of the command is authentic.

According to an embodiment, the application programming interface is configured to verify whether the higher-level operating system is authentic.

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 the at least one first application has been reliably sent.

Another embodiment provides a method of protecting an electronic device that includes a secure element adapted to implement at least one first application, and an application programming interface configured to verify whether commands received by the at least one first application have been reliably sent.

According to an embodiment, the application programming interface is configured to use a plurality of verification devices.

According to an embodiment, once the application programming interface performs verification, the application programming interface transmits the command to the at least one first application and sends the result of the verification to the first application.

According to an embodiment, the application programming interface is configured to verify whether the sender of the command is authentic.

According to an embodiment, the sender is a second application implemented by a high-level operating system of a processor comprised in the electronic device.

According to an embodiment, the application programming interface is configured to verify whether the higher-level operating system is reliable or authentic.

According to an embodiment, the secure element implements a first low-level operating system implementing the first application and a second low-level operating system configured to verify whether a high-level operating system of the processor is authentic or authentic, the application programming interface verifying that the high-level operating system is authentic by communicating with the first low-level operating system of the secure element.

According to an embodiment, the sender is an electronic system independent of the electronic device, said electronic system being adapted to be paired with said electronic device.

According to an embodiment, the electronic system is adapted to pair with the electronic device by using a pairing function.

According to an embodiment, the application programming interface is further configured to verify that the communication channel for transmitting the command is a reliable channel.

According to an embodiment, the application programming interface is further configured to verify the authenticity of the command received by the at least one first application.

According to an embodiment, the verification is performed by implementing verification means that can be parameterized by the application programming interface according to pairing functions.

The electronic device includes a secure element and an application programming interface. The secure element executes a first application in operation. The application programming interface verifies in operation the authenticity of the received command for the first application and transmits the command and the verified result to the first application.

In an embodiment, the application programming interface is operative to apply a plurality of verification tests.

In an embodiment, the verification by the application programming interface in operation includes verifying whether the sender of the command is authentic.

In an embodiment, the electronic device includes a processor coupled to the secure element, wherein the sender is a second application implemented by a high-level operating system of the processor.

In an embodiment, the application programming interface verifies in operation whether the higher-level operating system is reliable.

In an embodiment, the application programming interface verifies in operation whether the higher-level operating system is authentic.

In an embodiment, the security element is operative to: implementing a first low-level operating system, the first low-level operating system implementing a first application in operation; and implementing a second lower-level operating system that, in operation, verifies whether the higher-level operating system of the processor is authentic or authentic, and the application programming interface, in operation, verifies that the higher-level operating system is authentic by communicating with the first lower-level operating system of the secure element.

In an embodiment, the sender is an electronic system separate from the electronic device, and in operation, the electronic device is coupled to the electronic system.

In an embodiment, the electronic system is operatively coupled to the electronic device using a wireless pairing function.

In an embodiment, the application programming interface is operative to verify that the communication channel over which the command was received is a reliable channel.

In an embodiment, the application programming interface is operative to verify the authenticity of the verification of the command received by the first application.

In an embodiment, the application programming interface is operable to use the pairing function parameters to verify that the communication channel through which the command was received is a reliable channel; verifying the authenticity of the verification of the command received by the first application using the pairing function parameters; or use the pairing function parameters to verify that the communication channel through which the command was received is a reliable channel and use the pairing function parameters to verify the verification of the authenticity of the command received by the first application.

In an embodiment, a system includes a processor, a secure element that executes a first application in operation, and an application programming interface. The application programming interface verifies in operation the authenticity of the received command for the first application and sends the command and the verified result to the first application.

In an embodiment, in operation, the verification by the application programming interface includes verifying whether the sender of the command is authentic.

In an embodiment, the sender is a second application implemented by a high-level operating system of the processor.

In an embodiment, the processor is coupled to the secure element in operation using a wireless pairing function.

In an embodiment, a method includes: executing a first application using a secure element of the device; verifying the authenticity of the received command for the first application using an application programming interface of the device; and transmitting the results of the command and verification to the first application using the application programming interface.

In an embodiment, verifying includes verifying whether the sender of the command is authentic.

In an embodiment, the method includes verifying, using the application programming interface, whether the higher-level operating system is reliable.

In an embodiment, the method comprises: implementing a first low-level operating system using a secure element to execute a first application; implementing a second lower level operating system using a secure element to verify whether the higher level operating system of the processor is authentic or authentic; and verifying that the higher-level operating system is authentic by communicating with the first lower-level operating system of the secure element using the application programming interface.

In an embodiment, the sender is an electronic system independent of the device, and the method includes coupling the device to the electronic system using a wireless pairing function.

In an embodiment, the method comprises: verifying that the communication channel through which the command was received is a reliable channel using the pairing function parameters using the application programming interface; verifying, using the application programming interface, the verified authenticity of the command received by the first application using the pairing function parameters; or use the pairing function parameters to verify that the communication channel through which the command was received is a reliable channel and use the pairing function parameters to verify the authenticity of the verification of the command received by the first application.

In an embodiment, the content of the non-transitory computer readable medium configures an electronic device to perform a method comprising: executing a first application using a secure element of the electronic device; verifying, using an application programming interface of the electronic device, the authenticity of the received command for the first application; and transmitting the results of the command and verification to the first application using the application programming interface. In an embodiment, the content includes instructions executable by the electronic device.

Some embodiments may take the form of or include a computer program product. For example, according to an embodiment, a computer readable medium is provided, comprising a computer program adapted to perform one or more of the methods or functions described above. The medium may be a physical storage medium such as, for example, a Read Only Memory (ROM) chip, or a disk such as a digital versatile disk (DVD-ROM), compact disk (CD-ROM), hard disk, memory, a network, or a portable media article that is read by a suitable drive or via an appropriate connection, including one or more barcodes or other related codes encoded in one or more such computer-readable media and readable by a suitable reader device.

Additionally, in some embodiments, some or all of the methods and/or functions may be implemented or provided in other ways, such as at least partially in firmware and/or hardware, including but not limited to one or more Application Specific Integrated Circuits (ASICs), digital signal processors, discrete circuitry, logic gates, standard integrated circuits, controllers (e.g., by execution of appropriate instructions, and including microcontrollers and/or embedded controllers), field Programmable Gate Arrays (FPGAs), complex Programmable Logic Devices (CPLDs), and the like, as well as devices employing RFID technology, and various combinations thereof.

The various embodiments described above may be combined to provide further embodiments. Aspects of the embodiments can be modified if necessary to employ concepts of the various patents, applications and publications to provide yet further embodiments.

These and other changes can be made to the embodiments in light of the above-detailed description. In general, in the following claims, the terms used should not be construed to limit the claims to the specific embodiments disclosed in the specification and the claims, but should be construed to include all possible embodiments along with the full scope of equivalents to which such claims are entitled. Accordingly, the claims are not limited by the present disclosure.

Claims

1. An electronic device, comprising:

a secure element that executes a first application in operation; and

An application programming interface that, in operation:

Verifying the authenticity of the received command for the first application; and

The result of the command and verification is transmitted to the first application.

2. The electronic device of claim 1, wherein the application programming interface is operative to apply a plurality of verification tests.

3. The electronic device of claim 1, wherein the verification by the application programming interface in operation comprises verifying whether a sender of the command is authentic.

4. The electronic device of claim 3, comprising a processor coupled to the secure element, wherein the sender is a second application implemented by a high-level operating system of the processor.

5. The electronic device of claim 4, wherein the application programming interface is operative to verify whether the higher-level operating system is authentic.

6. The electronic device of claim 4, wherein the application programming interface is operative to verify whether the higher-level operating system is authentic.

7. The electronic device of claim 4, wherein,

The security element is operative to:

Implementing a first low-level operating system, said first low-level operating system implementing a first application in operation, an

A second lower-level operating system is implemented that in operation verifies whether the higher-level operating system of the processor is authentic or authentic, and the application programming interface in operation verifies that the higher-level operating system is authentic by communicating with the first lower-level operating system of the secure element.

8. The electronic device of claim 3, wherein the sender is an electronic system separate from the electronic device and the electronic device is operatively coupled to the electronic system.

9. The electronic device of claim 8, wherein the electronic system is coupled with the electronic device in operation using a wireless pairing function.

10. The electronic device of claim 1, wherein the application programming interface is operative to verify that a communication channel over which a command is received is a reliable channel.

11. The electronic device of claim 1, wherein the application programming interface is operative to verify the authenticity of the verification of the command received by the first application.

12. The electronic device of claim 1, wherein the application programming interface is operative to,

Verifying that the communication channel through which the command was received is a reliable channel using the pairing function parameters;

Verifying the authenticity of the verification of the command received by the first application using the pairing function parameters; or alternatively

The pairing function parameters are used to verify that the communication channel through which the command was received is a reliable channel and the pairing function parameters are used to verify the authenticity of the verification of the command received by the first application.

13. A system, comprising:

A processor;

a secure element that executes a first application in operation; and

An application programming interface that, in operation:

14. The system of claim 13, wherein the verification by the application programming interface in operation comprises verifying whether a sender of the command is authentic.

15. The system of claim 14, wherein the sender is a second application implemented by a high-level operating system of the processor.

16. The system of claim 15, wherein the application programming interface verifies in operation whether the higher-level operating system is reliable.

17. The system of claim 15, wherein the application programming interface is operative to verify whether the higher-level operating system is authentic.

18. The system of claim 15, wherein,

The security element is operative to:

19. The system of claim 14, wherein the processor is coupled to the secure element in operation using a wireless pairing function.

20. The system of claim 19, wherein the application programming interface is operative to,

21. A method, comprising:

executing a first application using a secure element of the device;

verifying the authenticity of the received command for the first application using an application programming interface of the device; and

The results of the command and verification are transmitted to a first application using the application programming interface.

22. The method of claim 21, wherein the verifying comprises verifying whether a sender of the command is authentic.

23. The method of claim 22, wherein the sender is a second application implemented by a high-level operating system of a processor.

24. The method of claim 23, comprising verifying, using the application programming interface, whether the higher-level operating system is reliable.

25. The method of claim 22, comprising:

implementing a first low-level operating system using the secure element to execute a first application;

Implementing a second lower-level operating system using the secure element to verify whether the higher-level operating system of the processor is authentic or authentic; and

Using the application programming interface, the high-level operating system is verified as being authentic by communicating with the first low-level operating system of the secure element.

26. The method of claim 22, wherein the sender is an electronic system independent of the device, and the method comprises coupling the device to the electronic system using a wireless pairing function.

27. The method of claim 21, comprising:

Using the application programming interface, verifying that the communication channel through which the command was received is a reliable channel using pairing function parameters;

using the application programming interface, verifying the verified authenticity of the command received by the first application using the pairing function parameters; or alternatively

Using the application programming interface, the pairing function parameters are used to verify that the communication channel through which the command is received is a reliable channel and the pairing function parameters are used by the application programming interface to verify the authenticity of the verification of the command received by the first application.

28. A non-transitory computer-readable medium having contents to configure an electronic device to perform a method comprising:

Executing a first application using a secure element of the electronic device;

Verifying, using an application programming interface of the electronic device, the authenticity of the received command for the first application; and

29. The non-transitory computer-readable medium of claim 28, wherein the content comprises instructions executable by the electronic device.