Protecting Access to Secure Applets

Abstract

The present invention relates to a device having at least an application processor (AppP) and a communication module (ComM) having a secure element (SE) with a secure application applet (SA), wherein the application processor (AppP) accesses the secure application applet (SA) in the secure element (SE) via the communication module (ComM) using a mono interface configuration, and the device further comprises a hardware link (HWL) between the application processor (AppP) and the secure element (SE) for transmitting a hardware signal (HWS) triggered by the application processor (AppP) only when the application processor (AppP) transmits a command (C(SA)), and the secure element (SE) rejects any received command (C(SA)) intended for the secure application applet (SA) if the hardware signal (HWS) is not activated.

Description

[Technical field]

[0001] The present invention relates to a device having at least an application processor and a communication module having a secure element with a secure application applet, said application processor accessing the secure element via the communication module using a mono interface arrangement.

[0002] The invention also relates to a method for protecting access by an application processor to a secure application applet in a security element of a communication module of a device. [Background technology]

[0003] With the introduction of mobile communication means in various objects / devices, such as automobiles, it is now common to use Secure Elements to protect their interactions with other objects and networks.

[0004] Secure elements are widely available in the embedded universal integrated circuit card (eUICC) form factor, however the present invention covers any security element, embedded or not.

[0005] Such secure elements are generally not fully utilized, both in terms of memory and computational power capacity, by the interfacing communications module and therefore may be used as general purpose secure elements by the device's application processor.

[0006] A typical configuration is shown in Figure 1. An application processor AppP interfaces with a communication module ComM which itself has a secure element SE equipped with at least an application application that should be secured within the secure element, hereafter called a security applet SA.

[0007] The application processor AppP interfaces with the communication module ComM classically using APDUs via AT commands. The secure element SE and the communication module ComM also use APDUs for communication.

[0008] With this simple implementation of figure 1, the secure element SE, typically an eUICC, receives commands from two external entities: the application processor AppP via the communication module ComM and from the communication module ComM itself, in fact it cannot distinguish those coming from the application processor AppP.

[0009] This configuration is typically found in the automotive sector and is already being implemented by some car manufacturers. The three components can be integrated with each other in various ways, but the communication method shown in Figure 1 remains the same.

[0010] In this architecture, the communication module ComM is the most advanced communication component of the device, typically a car. It is therefore also the most vulnerable to hacking. As shown in Figure 2, it is most likely to be the first element to be infected by the malware MW. In such a case, the malware MW will directly compromise the security applet SA and may use its keys.

[0011] Therefore, such a single hardware interface is not secure at all. Moreover, while it is known to use dual hardware interfaces which are more secure, these are often too complex and expensive to implement in the target devices.

[0012] Such a dual hardware interface is classical protection, using an eUICC to provide the second hardware interface.

[0013] For example, as shown in FIG. 3, the communication module ComM may communicate using APDUs via a mono interface (typically ISO7816), while the application processor AppP communicates with the secure element SE via an SPI interface.

[0014] If the Security Applet SA is implemented in a Secure Element SE, it can know from which hardware interface the command came, and therefore in this example it can reject commands coming from the ISO7816 interface.

[0015] However, this configuration is costly to develop because two communication stacks must be developed and tested: one for the SPI interface and one for the ISO7816 interface, and both interfaces may be used simultaneously, further increasing software complexity and making debugging and testing more difficult.

[0016] Thus, further alternative and advantageous solutions are desirable in the art. Summary of the Invention

[0017] The present invention aims to avoid the above mentioned malicious attacks, or at least make them more difficult.

[0018] In its broadest sense, the invention is defined as a device having at least an application processor and a communication module having a secure element with a secure application applet, said application processor accessing the secure application applet in the secure element via the communication module using a mono interface configuration, said device further comprising a hardware link between the application processor and the secure element for transmitting a hardware signal that is triggered by the application processor only when the application processor sends a command, and the secure element rejecting any received command intended for the secure application applet if the hardware signal is not activated.

[0019] Therefore, the present invention proposes to unlock access to the secure application applet using a hardware link: by wiring one secure element input signal to only one of the two entities, the secure element can identify which one is sending a command to it.

[0020] The hardware signal will be activated by the application processor only when it sends a command, so if the GPIO signal is not activated but the security applet receives a command, the command will be rejected.

[0021] In fact, while receiving a command, the security applet has no way of knowing whether the command is coming from the application processor or not. If the GPIO signal is activated, it properly indicates that the command is coming from the application processor.

[0022] The inventive setup still provides an opportunity for an attacker, but the opportunity is greatly reduced. The tradeoff between security and cost applies to many applications.

[0023] According to one feature, the hardware signal is a general purpose input / output GPIO signal.

[0024] Advantageously, the secure element is embedded in the communication module.

[0025] Such an implementation is recognized as a secure and efficient solution for targeted Internet of Things applications.

[0026] Also advantageously, the mono interface configuration complies with the ISO 7816 standard.

[0027] Such a standardized configuration combined with the hardware signals of the present invention is a simple and efficient implementation.

[0028] According to a preferred embodiment, the secure element has an MFF2 standard form factor and the hardware signals are implemented on the remaining pins.

[0029] Secure elements with this standardized form factor have at least one unconnected pin that can be used to add an additional GPIO signal, and thus be used to route simple hardware signals to the application processor.

[0030] In one embodiment, the secure element is not standardized and the hardware signals are implemented with proprietary general purpose input / output GPIO signals.

[0031] In general, non-standardized secure elements have room to implement the use of the hardware signals of the invention: if the eUICC is provided as a non-standard form factor, the GPIO signals are indeed already available.

[0032] In a centralized embodiment, the secure element contains a list of secure application applets, and the secure element checks the activation of hardware signals only for commands targeted to application applets listed in the list of secure application applets.

[0033] This embodiment is a kind of filtering module for secure elements that uses a table that associates each applet with the presence or absence of a secure application, where commands are forwarded to the listed secure application applets only if a hardware signal is activated.

[0034] In a distributed embodiment of the invention, the secure application applet itself triggers the step of checking for activation of the hardware signals and itself rejects the command.

[0035] Now, each applet knows if it is a secure application or not and checks the activation of the signal. If the hardware signal of the present invention is not activated, the secure application applet will cause an error.

[0036] The invention also relates to a method for protecting access by an application processor to a secure application applet in a secure element through a communication module of a device using a mono interface configuration, said device further comprising a hardware link for transmitting hardware signals between the application processor and the secure element, said method comprising the steps of: - an application processor sending a command intended for a secure application applet via a communication module to a secure element; - the application processor triggering a hardware signal on a hardware link in parallel with sending the command; - receiving, by the secure element, a command sent by the application processor and intended for a secure application applet; - the secure element verifying that a hardware signal is activated on the hardware link; - the secure element rejecting commands targeted to the secure application applet if the hardware signal is not activated.

[0037] Such a method implemented in the device of the present invention allows the secure application applet to ensure that incoming commands are truly sent from the application processor.

[0038] The method according to the invention therefore makes it possible to reduce the risk of a malicious attack, or at least to make it more complicated for a malicious attacker to carry out the attack.

[0039] To the accomplishment of the foregoing and related ends, the one or more embodiments comprise the features hereinafter fully described and particularly pointed out in the claims. [Brief description of the drawings]

[0040] The following description and the annexed drawings set forth in detail certain illustrative aspects and are indicative of but a few of the various ways in which the principles of the embodiments may be employed.

[0041] Other advantages and novel features will become apparent from the following detailed description when considered in conjunction with the drawings, and the disclosed embodiments are intended to include all such aspects and their equivalents.

[0042] [Figure 1] FIG. 1 shows a schematic diagram of a first type of device according to the prior art. [Diagram 2] FIG. 1 is a diagram illustrating a schematic diagram of an attack on a first type of device in the prior art. [Diagram 3] FIG. 2 shows a schematic diagram of a second type of device according to the prior art. [Figure 4] FIG. 1 is a schematic diagram showing a device of the present invention. [Diagram 5]1 is a flow chart of the method of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0043] In order to provide a more complete understanding of the present invention, the present invention will now be described in detail with reference to the accompanying drawings. In the detailed description, what are considered to be preferred embodiments of the present invention are illustrated and described. It will, of course, be understood that various modifications and changes in form or detail can be readily made without departing from the scope of the present invention. It is therefore intended that the present invention not be limited to the exact forms and details shown and described herein, nor to the entirety of the invention disclosed herein and claimed below. In different drawings, the same elements are designated by the same reference numerals. For clarity, only those elements and steps that are helpful in understanding the present invention are shown and described in the drawings.

[0044] Figure 4 shows diagrammatically a first type of prior art device in which the invention is implemented, in which a hardware link HWL is added between the application processor AppP and the secure element SE, said hardware link HWL being dedicated to transmitting hardware signals activated by the application processor when sending commands in parallel to the secure application applet SA in the secure element SE.

[0045] The hardware link HWL can use spare and therefore available GPIOs of the secure element. It can also use free pins of the secure element if they are available. This is the case for secure elements with the MFF2 standard form factor.

[0046] FIG. 5 shows a flow chart of the method of the present invention.

[0047] In a first step E1, the application processor AppP sends a command C(SA) intended for the secure application applet SA to the secure element SE via the communication module ComM, as also shown in Figure 1. In parallel, a step E2 takes place in which the application processor sends a hardware signal HWS on a hardware link HWL, illustrated by the dotted box in Figure 5 between the application processor AppP and the secure element SE.

[0048] The secure element SE receives the command C(SA) in a step E3.The secure element SE then checks in a step E4 whether the hardware signal HWS is activated on the hardware link HWL.

[0049] If the hardware signal HWS is not activated (case N), the secure element SE rejects the command C(SA) and preferably informs it back to the communications module ComM.

[0050] If the hardware signal HWS is activated (case Y), the secure element SE provides a command C(SA) to the secure application applet.

[0051] Prior to the implementation of the present invention, it was not possible for a security element to know where a command came from.

[0052] This is not important for Carrier applets whose commands target the functionality of the Secure Element SE (SIM, USIM, ISIM, etc.). In this case the inventive mechanism is not needed. The Secure Element SE can now act differently depending on the applet it targets.

[0053] For any secure application applet, the security element SE can use the mechanism of the invention.

[0054] In the foregoing detailed description, reference has been made to the accompanying drawings which show, by way of illustration, specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. Accordingly, the foregoing detailed description is not to be taken in a limiting sense, and the scope of the invention is defined only by the appended claims, appropriately interpreted.

Claims

1. A device having at least an application processor (AppP) and a communication module (ComM) having a secure element (SE) equipped with a secure application applet (SA), wherein the application processor (AppP) accesses the secure application applet (SA) in the secure element (SE) via the communication module (ComM) using a mono interface configuration, and the device further comprises a hardware link (HWL) between the application processor (AppP) and the secure element (SE) for transmitting a hardware signal (HWS) triggered by the application processor (AppP) only when the application processor (AppP) transmits a command (C(SA)), and the secure element (SE) rejects any received command (C(SA)) intended for the secure application applet (SA) if the hardware signal (HWS) is not activated.

2. The device of claim 1 , wherein the hardware signals (HWS) are general purpose input / output (GPIO) signals.

3. The device according to claim 1 or 2, wherein the secure element (SE) is embedded in the communication module (ComM).

4. 3. The device of claim 1 or 2, wherein the mono interface configuration complies with the ISO 7816 standard.

5. 3. The device of claim 1 or 2, wherein the secure element (SE) has an MFF2 standard form factor and the hardware signals (HWS) are implemented on remaining pins.

6. 3. The device of claim 1 or 2, wherein the Secure Element (SE) is not standardized and the Hardware Signals (HWS) are implemented on any available General Purpose Input / Output (GPIO) pins on a proprietary package.

7. 3. The device of claim 1, wherein the secure element (SE) includes a list of secure application applets (SA), and the secure element (SE) checks activation of the hardware signal (HWS) only for commands (C(SA)) targeted to application applets listed in the list of secure application applets (SA).

8. 3. The device according to claim 1 or 2, wherein the secure application applet (SA) itself triggers the step of checking the activation of the hardware signal (HWS) and itself rejects the command (C(SA)).

9. A method for protecting access to a secure application applet (SA) in a secure element (SE) by an application processor (AppP) via a communication module (ComM) of a device using a mono interface configuration, the device further comprising a hardware link (HWL) for transmitting a hardware signal (HWS) between the application processor (AppP) and the secure element (SE), the method comprising: said application processor (AppP) sending a command (C(SA)) intended for said secure application applet (SA) to said secure element (SE) via said communication module (ComM); - said application processor (AppP) triggering a hardware signal (HWS) on said hardware link (HWL) in parallel with the sending of said command (C(SA)); - receiving, by said Secure Element (SE), said command (C(SA)) sent by said Application Processor (AppP) and intended for said Secure Application Applet (SA); - said secure element (SE) checking that said hardware signal (HWS) is activated on said hardware link (HWL); - the secure element (SE) rejects the command (C(SA)) intended for the secure application applet (SA) if the hardware signal (HWS) is not activated.

Images