Electronic assembly comprising a disabling module

Abstract

An electronic assembly for an electronic device may include a detection module to detect a security anomaly of a Rich-OS operating system and a disabling module to disable at least one secure function of the electronic device in response to the detection. The disablement nevertheless allows use of the electronic device in fail-soft mode. The electronic assembly may be implemented such that these two modules are dependent on a trusted operating system, and the trusted operating system and the Rich-OS operating system may be stored in a memory of the electronic assembly and executed on the electronic assembly.

Claims

1. An electronic assembly for an electronic device, the electronic assembly comprising: a processor; a memory; a detection module to detect a security anomaly of a Rich-OS operating system, wherein the detection module performs a calculation of a fingerprint of a specific series of octets in at least one level of the Rich-OS operating system and compares the fingerprint with a reference fingerprint; a disabling module which in response to said detection disables at least one secure function of said electronic device used by applications of the Rich-OS operating system, by performing operations comprising: sending a disabling instruction to the at least one secure function, and waiting for an acknowledgement of disablement of the at least one secure function; and a trusted operating system comprising the detection module and the disabling module, the trusted operating system and the Rich-OS operating system being stored in the memory of the electronic assembly, and being executed on the electronic assembly.

2. The electronic assembly according to claim 1, wherein the security anomaly is corruption of the Rich-OS operating system.

3. The electronic assembly according to claim 1, wherein the detection module is capable of receiving a message containing a securing command.

4. The electronic assembly according to claim 1, wherein the at least one secure function comprises of at least one chosen from a group consisting of: an application of a secure element, executed by the electronic device; and a function providing access to at least one sensitive data item of a secure element, the at least one sensitive data item being accessible to the electronic device.

5. The electronic assembly according to claim 1, wherein the trusted operating system takes steps to ensure the security of said electronic device when the acknowledgement is negative.

6. The electronic assembly according to claim 1, wherein the detection module is activated in response to verification of the security of the electronic device, triggered by at least one chosen from a group consisting of: on the initiative of the trusted operating system, on start-up of the electronic device, at regular intervals, and on the initiative of a user of said electronic device.

7. A terminal comprising: an electronic assembly comprising: a processor; a memory; a detection module to detect a security anomaly of a Rich-OS operating system, wherein the detection module performs a calculation of a fingerprint of a specific series of octets in at least one level of the Rich-OS operating system and compares the fingerprint with a reference fingerprint; a disabling module which in response to said detection disables at least one secure function of said electronic device used by applications of the Rich-OS operating system, by performing operations comprising: sending a disabling instruction to the at least one secure function, and waiting for an acknowledgement of disablement of the at least one secure function; and a trusted operating system comprising the detection module and the disabling module, the trusted operating system and the Rich-OS operating system being stored in the memory of the electronic assembly, and being executed on the electronic assembly.

8. The terminal according to claim 7, wherein the terminal is a mobile telephony terminal.

9. A method for securing an electronic device comprising a processor, the method comprising: detecting, by the processor of the electronic device, a security anomaly of a Rich-OS operating system, wherein the detecting comprises calculating a fingerprint of a specific series of octets in at least one level of the Rich-OS operating system and comparing the fingerprint with a reference fingerprint; and disabling, by the processor of the electronic device and in response to the detecting, at least one secure function of said electronic device, by performing operations comprising: sending a disabling instruction to the at least one secure function, and waiting for an acknowledgement of disablement of the at least one secure function; wherein the method is implemented using a trusted operating system comprising a module that performs said detecting and a module that performs said disabling, and the trusted operating system and the Rich-OS operating system are executed on the electronic device.

10. A non-transitory computer-readable medium comprising instructions that, when executed by a processor of an electronic assembly, perform a method comprising: detecting, by the processor of the electronic assembly, a security anomaly of a Rich-OS operating system, wherein the detecting comprises calculating a fingerprint of a specific series of octets in at least one level of the Rich-OS operating system and comparing the fingerprint with a reference fingerprint; and disabling, by the processor of the electronic assembly and in response to the detecting, at least one secure function of an electronic device, by performing operations comprising: sending a disabling instruction to the at least one secure function, and waiting for an acknowledgement of disablement of the at least one secure function; wherein the detecting and the disabling are implemented using a trusted operating system comprising a module that performs said detecting and a module that performs said disabling, and the trusted operating system and the Rich-OS operating system are executed on the electronic assembly.

11. The non-transitory computer-readable medium according to claim 10, wherein the method is included in the trusted operating system.

12. The non-transitory computer-readable medium according to claim 10, wherein the method is included in a patch on said trusted operating system.

13. The non-transitory computer-readable medium according to claim 10, wherein the method is included in an application implementation-dependent on said trusted operating system.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) Other characteristics and advantages of the present invention will become apparent from the description given below with reference to the appended drawings illustrating an example of embodiment thereof that is in no way limiting. In the Figures:

(2) FIG. 1 schematically illustrates an electronic device according to one embodiment of the invention;

(3) FIG. 2 schematically illustrates a method according to one particular embodiment of the invention;

(4) FIG. 3 schematically illustrates a scenario of use of the method according to the embodiment of the invention shown in FIG. 2;

(5) FIG. 4 is a flow chart illustrating a method according to another embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

(6) FIG. 1 illustrates an electronic device 1 according to one embodiment of the invention. In this example, the electronic device is a terminal e.g. a touchpad, laptop computer or a mobile telephone.

(7) As a variant, it could have been a device of machine-to-machine type, such as a computer on-board a vehicle, or a smartcard such as a bank card or an electronic identity document.

(8) In the example in FIG. 1, the terminal comprises an electronic assembly 10 conforming to the invention and a secure element 20.

(9) In this example, the electronic assembly itself 10 comprises a processor 300 and a memory 500 in which in particular the code of two operating systems is stored, namely that of a Rich-OS operating system referenced 100 and that of a trusted operating system referenced 200.

(10) These two operating systems are jointly started up, on start-up of the terminal 1. As is known to persons skilled in the art, the secure execution environment of the trusted operating system 200 has a secure start-up mechanism (Secure Boot) whereby the trusted operating system 200 is authenticated and then initialised i.e. launched, followed by start-up of the Rich-OS operating system 100.

(11) More specifically, the Secure Boot is a chain of steps leading to complete start-up of the terminal, each step validating the following. For example, step i+1 is only triggered if step i validates the transition.

(12) However active operation, in opposition to stand-by, of each of the operating systems is exclusive. That is to say that when one of the operating systems is active, the other is in inactive mode.

(13) In this example, the trusted operating system 200 comprises a detection module to detect a security anomaly referenced 210, and a disabling module 220. When the trusted operating system detects a security anomaly by means of module 210, the disabling module 220 is in turn set in operation.

(14) Also, the secure element may be a smartcard connected to the terminal by a reader e.g. a SIM card, or an integrated circuit whose connection pads are connected to the terminal such as an eSE for example.

(15) In general, a secure element meets the security criteria: Common Criteria as per standard ISO/CEI 15408, ISO 7816 and/or standard FIPS 140, and stores data and sensitive applications such as applications dedicated to contactless payment via NFC (Near Field Communication). In this example, the secure element 20 is a SIM card allowing the terminal to communicate in particular via a mobile network. The trusted operating system 200 is able directly i.e. without mobilising the Rich-OS operating system, to access applications stored in the SIM card 20. This SIM card 20 comprises a component CM in charge of managing applications (Card Manager) stored in the SIM card 20. This Card Manager CM may be an application of the SIM card 20. In particular it ensures the routing of frames of APDU type conforming to standard ISO 7816.

(16) Therefore, when a security anomaly is detected, and the trusted operating system by means of the disabling module 220 sends a disabling instruction to disable all the applications of a specific type for example, e.g. applications dedicated to payment, the Card Manager CM routes the disabling instruction towards the different applications concerned, namely in this precise example the applications dedicated to payment.

(17) In this example, only the disabling of secure functions of the SIM card 20 has been described. However, the invention also concerns the securing of a terminal comprising several secure elements, each containing secure functions to be disabled. In this configuration, a list of these secure elements and of their applications is memorised in a non-volatile memory controlled by the trusted operating system 200.

(18) FIG. 2 illustrates the main steps of a method according to one particular embodiment of the invention, whose implementation is dependent on a trusted operating system 200 in a terminal 1 such as previously described with reference to FIG. 1.

(19) At a step E5, a particular application of the trusted operating system verifies the integrity of the Rich-OS operating system.

(20) In this example, the method is implemented on the initiative of the trusted operating system 200, on secure start-up of the terminal 1 such as described above.

(21) As a variant, the method could have been implemented on the initiative of the trusted operating system 200 on a regular basis by means of a clock or else on the initiative of the user of the terminal 1, or even on receipt of a polling command.

(22) In manner known to persons skilled in the art, the verification of the integrity of an operating system entails on-the-fly calculation of the fingerprint of a specific series of octets in each level of this system (e.g. the core, the native libraries, execution environment, applications), then of comparing this fingerprint with a reference fingerprint for example by applying the SHA-1 algorithm well-known to skilled persons.

(23) At step E10, the particular application in charge of verifying the integrity of the Rich-OS operating system ascertains that this system is corrupt.

(24) In practice when said corruption is ascertained, information on the security anomaly is memorised in a non-volatile memory controlled by the trusted operating system 200, so that a particular application of this operating system 200, capable of reading this information, sets in operation the disabling step E11 to disable at least one secure function of the terminal.

(25) In the particular case in which the terminal comprises several secure elements whose list is memorised in a non-volatile memory controlled by the trusted operating system 200, a particular application of this operating system 200 reads the list and initiates the disabling step E11 for each application to be disabled of each secure element in the list.

(26) Returning to FIG. 2, the disabling step E11 comprises a step E20 to send a disabling instruction directly in this example to a sensitive application of the SIM card 20, and a wait step E30 to wait for acknowledgement ACK given by the application under consideration.

(27) Communications (sending and receipt of the instruction, and acknowledgement) take place using the APDU protocol for example conforming to standard ISO 7816.

(28) FIG. 3 schematically illustrates a scenario of use integrating the method according to the embodiment previously described with reference to FIG. 2.

(29) In this scenario, the user switches on the terminal 1. At step E5, a particular application of the trusted operating system verifies the integrity of the Rich-OS operating system.

(30) The trusted operating system ascertains that the Rich-OS operating system is corrupt (step E10) and starts to disable (step E11) payment applications of the SIM card and access to cryptographic keys present on the SIM card 20. The applications of the Rich-OS operating system using payment applications on the SIM card 20, e.g. electronic commerce or purchase applications, then remain accessible to the user of the terminal 1 but the payment actions using the applications of the SIM card or the cryptographic keys are no longer possible.

(31) In this example, these applications of the Rich-OS operating system have direct access to the SIM card 20. The user later uses the terminal 1 to make a call via the mobile network. This call is able to take place since solely the secure payment applications stored on the SIM card 20 are blocked. On the other hand, the user can no longer fully use the purchase and electronic commerce applications. This partial use of the terminal is termed fail-soft mode

(32) FIG. 4 illustrates the main steps of a method according to another embodiment of the invention, which can also be implemented by a trusted operating system 200 in a terminal 1 such as previously described with reference to FIG. 1.

(33) In addition, in this example, the SIM card comprises three applications APP.sub.0, APP.sub.1 and APP.sub.2, the last two being payment applications.

(34) At step E10, the trusted operating system 200 receives a message containing a command to disable payment applications stored on the SIM card 20.

(35) At step E200, it sends an instruction to disable payment applications to the Card Manager CM which:

(36) does not select the APP.sub.0 application since it is not a payment application;

(37) selects the APP.sub.1 application and APP.sub.2 application, these both being dedicated to payment.

(38) In practice, the disabling instruction is in the form of an APDU frame and the Card Manager CM selects the applications as per their unique AID identifier (Application IDendifier) in accordance with standard ISO 7816.

(39) The Card Manager therefore transmits the APDU frame containing the disabling instruction to the selected applications, namely APP.sub.1 and APP.sub.2.

(40) The APP.sub.1 application successively carries out disablement and sends a positive acknowledgement ACK+ whilst the disabling of application APP.sub.2 fails, hence the sending of a negative acknowledgement ACK−.

(41) In this example, the Card Manager CM summarises the acknowledgements and sends a global acknowledgement ACK (+,−) also in the form of an APDU frame to the trusted operating system, thereby terminating the acknowledgement waiting step E300.

(42) In this example, as mentioned previously, the applications of the Rich-OS operating system have access to the SIM card 20 without necessarily mobilising the trusted operating system.

(43) As a variant, the trusted operating system could be a systematic intermediary between the Rich-OS operating system and the secure element i.e. the SIM card 20.

(44) The disabling steps of the secure functions on the SIM card 20 could then entail integrating a communication controlling component (Secure Element Access Controller) in the trusted operating system. This controller acts as filter and applies a predefined security policy. When a security anomaly is detected, this security policy may for example block requests originating from the Rich-OS operating system requesting access to secure functions via the trusted operating system.