Secure firmware download

Abstract

Secure Firmware Download This description relates to a method comprising: - executing, by an electronic device (100), a first firmware stored in volatile memory (113) of the electronic device, the execution of the first firmware resulting in an updated firmware key (130) being stored in non-volatile memory (124) of the electronic device; - downloading a second encrypted firmware module into the electronic device; - decrypting the second encrypted firmware module by a cryptographic processor (108) of the electronic device based on the updated firmware key; and - installing the second decrypted firmware module into the volatile memory of the electronic device, at least partially overwriting the first firmware. Figure for the abstract: Fig. 1

Description

Title of the invention: Secure download of microlo^ciel technical field

[0001] This description relates generally to the field of electronic devices, and in particular to so-called "ROM-less" electronic devices (without read-only memory). Previous technique

[0002] Devices with limited non-volatile data storage capacity, such as so-called “ROM-less” devices (i.e., devices without read-only memory or ROM), are highly advantageous to industry due to their low technological complexity and low cost. For such devices, firmware is generally stored in external non-volatile memory and downloaded into the device's random access memory. Since random access memory is volatile, its contents are lost when the device's power is turned off. In some environments, devices are powered for relatively long periods, and therefore the use of volatile memory is possible. If the power is removed, the firmware is reloaded at the next startup.

[0003] However, there is a technical problem in ensuring the authenticity of the firmware and it is desirable to prevent a hacker from loading non-genuine firmware and injecting data into the device. Summary of the invention

[0004] There is a need to ensure the authenticity of firmware installed in a device without ROM without implementing dedicated hardware.

[0005] One embodiment overcomes all or part of the disadvantages of devices lacking known ROM.

[0006] According to one aspect, a process is envisaged comprising:

[0007] - execute, by an electronic device, a first firmware stored in volatile memory of the electronic device, the execution of the first firmware resulting in an updated firmware key being stored in non-volatile memory of the electronic device;

[0008] - download a second encrypted firmware module into the electronic device tronics;

[0009] - decrypt the second firmware module encrypted by a crypto processor graph of the electronic device based on the updated firmware key; and

[0010] - install the second decrypted firmware module into the volatile memory of the electronic device by at least partially overwriting the first firmware.

[0011] According to one embodiment, the method further comprises, before the execution of the first firmware:

[0012] - download the first encrypted firmware module into the electronic device electronics; and

[0013] - decrypt the first firmware module encrypted by the crypto processor graphic of the electronic device based on an initial firmware key.

[0014] According to one embodiment, the second encrypted firmware module is downloaded via an interface of the electronic device, and the volatile memory is not directly accessible through the interface, but only through the cryptographic processor.

[0015] According to one embodiment, the initial firmware key is stored in non-volatile memory.

[0016] According to one embodiment, the initial firmware key is stored by a hardware configuration of the electronic device.

[0017] According to one embodiment, the method further includes, after decrypting the second firmware module, a verification that the second firmware module has an expected format and / or content.

[0018] According to one embodiment, the first and / or second firmware module includes a cyclic redundancy check field storing a CRC value, the method further comprising a check of the CRC value by a CRC module of the electronic circuit.

[0019] According to one embodiment, the verification is based on a comparison between at least a part of the code of the first and / or second firmware module and a reference value.

[0020] According to one embodiment, the electronic device includes a processing module, and the method includes stopping the power supply to the processing module during the downloading, decryption and / or verification of the second firmware module.

[0021] According to one embodiment, the method further comprises, after the execution of the first firmware, the deactivation of the initial firmware key.

[0022] According to one embodiment, the method further comprises, after the execution of the first firmware, the encryption of the first firmware by the cryptographic processor on the basis of the updated firmware key.

[0023] According to one embodiment, after the installation of the second firmware, the downloading of a new firmware module triggers an increment of an account value stored in non-volatile memory.

[0024] According to one embodiment, the method further includes authorizing the installation of the new firmware based on a comparison between a value contained in the new firmware module and the account value.

[0025] According to one embodiment, the cryptographic processor is arranged to perform elliptic curve cryptography to decrypt the first and / or second encrypted firmware module.

[0026] According to another aspect, an electronic device is provided comprising:

[0027] - a volatile memory comprising a first firmware;

[0028] - a non-volatile memory arranged to store a firmware key set to day when the first firmware was run;

[0029] - an interface arranged for downloading a second firmware module encrypted; and

[0030] - a cryptographic processor arranged to decrypt the second module of mi encrypted firmware, based on the updated firmware key;

[0031] the electronic device being further arranged to install the second decrypted firmware module in volatile memory, partially overwriting the first firmware. Brief description of the drawings

[0032] These features and advantages, as well as others, will be described in detail in the following description of particular embodiments, given by way of non-limiting example, in relation to the accompanying figures, among which:

[0033] [Fig.1] schematically represents an example of an electronic device according to an embodiment of the present description;

[0034] [Fig.2] is a flowchart illustrating steps of a process for securely downloading firmware into the electronic device of [Fig.1] according to an embodiment of the present description;

[0035] [Fig. 3] is a flowchart illustrating a firmware verification operation according to an embodiment of the present description; and

[0036] [Fig.4] represents an example of the implementation of a pseudo-monotonic counter according to an embodiment of the present description. Description of the implementation methods

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

[0038] For the sake of clarity, only the steps and elements useful for understanding the described embodiments have been shown and are detailed. In particular, the operations The cryptographic methods used in the process are not described in detail.

[0039] Unless otherwise specified, when referring to two elements connected together, this means directly connected without intermediate elements other than conductors, and when referring to two elements coupled together, this means that these two elements can be connected or linked through one or more other elements.

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

[0041] Unless otherwise specified, the expressions "approximately", "roughly", "about" and "on the order of" mean within 10%, preferably within 5%.

[0042] Figure 1 schematically represents an example of an electronic device 100 (SoC) according to an embodiment of the present description. In some embodiments, the electronic device 100 is a system-on-a-chip (SoC).

[0043] The electronic device 100 includes a user interface, which is, for example, a standard interface such as a serial device interface, coupled to an external device 103. The interface 102 is coupled, for example via a bus 106, to an input of a cryptographic processor 108 (CRYPTO). The cryptographic processor 108 applies, for example, a symmetric encryption or decryption method, such as the AES (Advanced Encryption Scheme) or 3DES (Triple Data Encryption Standard). An output of the cryptographic processor 108 is coupled, for example via a bus 110 and via a direct memory access module 112 (DMA), to volatile memory 113 (RAM).Volatile memory 113 is, for example, a random access memory (RAM), such as static RAM (SRAM). In some embodiments, a multiplexer 114 (MUX) is also coupled to bus 110, with one output of the multiplexer 114 coupled, for example via bus 110, to volatile memory 113 and another output of the multiplexer 114 coupled, for example via bus 115, to a data verification module 120 (CRC). The data verification module 120 is, for example, a cyclic redundancy check module arranged to verify data based on one or more CRC bits. The interface 102, the cryptographic processor 108 and the direct memory access module 112 are, for example, controlled by a control circuit 121 (CTRL) via command lines 122.

[0044] The electronic device 100 further comprises a processor 123 (CPU) and a one-time programmable (OTP) memory 124. The processor 123 is, for example, a central processing unit (CPU) and is, for example, coupled to the volatile memory 113 via a bus 125. Writing to the OTP memory 124 is, for example, controlled by an OTP control circuit 126 (OTP CTRL). An output 128 of the one-time programmable memory 124 is, for example, coupled to the cryptographic processor 108. The OTP memory 124 stores, for example, one or more updated firmware keys 130 (UPDATED FW KEYS).

[0045] The device 100 further includes an initial firmware key 131 (INITIAL FW KEY) stored in the OTP memory 124 or alternatively hard-coded in a logic circuit 132, for example during a coding design phase.

[0046] Interface 102 is not, for example, coupled to bus 125, and there is, for example, no direct connection between interface 102 and volatile memory 113. Thus, volatile memory 113 is, for example, inaccessible via interface 102, except through the cryptographic processor 108. The cryptographic processor 108 accesses volatile memory 113, for example, through the direct memory access module 112.

[0047] The volatile memory 113 stores, for example, firmware that is executed by the processor 123. The firmware is, for example, loaded into the electronic device 100 from the external device 103. For example, in some cases, the external device 103 is permanently connected to the electronic device 100, such as if the external device 103 and the electronic device 100 are mounted on the same printed circuit board (PCB) or motherboard. In other cases, the external device 103 may be connected to the electronic device 100 only when firmware needs to be loaded into the device 100, such as after the device 100 is powered on, or when the firmware needs to be updated.

[0048] We will now describe the operation of the electronic device 100 and the external device 103 of [Fig.1] in more detail by referring to [Fig.2].

[0049] Figure 2 is a flowchart illustrating steps in a method for securely uploading new firmware to the electronic device 100 of Figure 1 according to an embodiment of this description. The method in Figure 2 is, for example, implemented when the electronic device 100 is powered on for the first time in order to perform an initial firmware installation on the device. In addition to or instead of this, the method in Figure 2 is, for example, carried out when the device 100 is powered on following a period during which the device 100 was switched off and therefore the volatile memory 113 lost its data. In addition to or instead of this, the method in Figure 2 is, for example, implemented when a firmware update needs to be performed.

[0050] In step 201 (KEY INJECTION FW UPLOAD), encrypted firmware, enabling a key exchange protocol, is uploaded to the electronic device 100. This firmware will be called the key injection firmware. The key injection firmware is, for example, uploaded to the device 100 from the external device 103. In some cases, the communication channel between the external device 103 and the device 100 is an insecure channel.

[0051] In a step 202 (DECRYPTING USING FW KEY), the encrypted key injection firmware is decrypted by the cryptographic processor 108. For example, the encrypted key injection firmware is received by the interface 102 of the electronic device and transmitted via the bus 106 to the cryptographic processor 108. In the case of a first firmware installation, i.e., if no firmware has yet been installed in the electronic device 100, the decryption is, for example, performed using the initial firmware key 131. As described in relation to [Fig. 1], the initial firmware key 131 is, for example, stored in the OTP memory 124 and is supplied, from the output 128 of the OTP memory 124, to the cryptographic processor 108.Alternatively, the initial firmware key 131 is stored by the logic circuit 132 and provided at an output of this logic circuit 132 to the cryptographic processor 108. In yet another variant, if firmware has already been previously installed on the device, such as in the case of a firmware update, decryption is performed, for example, using one of the updated firmware keys 130, which is provided, for example, at output 128 of the OTP memory 124. In some embodiments, the cryptographic processor 108 decrypts the firmware using cryptographic operations based on symmetric cryptography.

[0052] In a step 203 (STORE KEY INJECTION FW TO VOLATILE MEMORY), the decrypted key injection firmware is stored in volatile memory 113. In some embodiments, during the downloading and decryption of the key injection firmware, the control circuit 121 is arranged to cut off the power supply to the processor 123 or to disable it. Once the key injection firmware has been stored in volatile memory 113, the control circuit 121 is, for example, arranged to turn on the processor 123.

[0053] In a step 204 (KEYS EXCHANGE), the decrypted key injection firmware is executed by the processor 123. This causes, for example, the processor 123 to command the OTP control circuit 126 to store an updated firmware key in the OTP memory 124. The execution by the processor 123 of the decrypted key injection firmware allows the electronic device 100 and the External device 103 for exchanging a secret key, using for example a public-key cryptographic method, implemented by the key injection firmware. As an example, an elliptic curve method, such as the Diffie-Hellman method or similar, can be used.

[0054] In some embodiments, step 204 is executed multiple times to install more than one secure secret key in different regions of OTP memory 124.

[0055] In a step 205 (NEW FW UPLOAD), new encrypted firmware, corresponding to an encrypted version of new firmware to be installed in the device 100, is uploaded to the electronic device 100. The new firmware is, for example, uploaded to the device 100 from the external device 103. In some cases, the communication channel between the external device 103 and the device 100 is an insecure channel. The new firmware is, for example, an updated version of firmware already stored in volatile memory 113. Alternatively, the new firmware corresponds, for example, to programs for the end user of the device and is installed on the device for the first time, for example, by a partner other than the manufacturer.

[0056] In a step 206 (DECRYPTING USING UPDATED FW KEY), the new encrypted firmware is decrypted by the cryptographic processor 108. For example, the new encrypted firmware is received by the interface 102 of the electronic device and transmitted via the bus 106 to the cryptographic processor 108. Decryption is performed, for example, using one of the updated firmware keys 130. As described in relation to [Fig. 1], the updated firmware key 130 is, for example, stored in the OTP memory 124 and is supplied, from the output 128 of the OTP memory 124, to the cryptographic processor 108. In some embodiments, the cryptographic processor 108 decrypts the firmware using cryptographic operations based on symmetric cryptography.

[0057] In step 207 (STORE NEW FW IN VOLATILE MEMORY), the new decrypted firmware is stored in volatile memory 113. If the key injection firmware is also stored in volatile memory 113, storing the new firmware at least partially overwrites the key injection firmware. In some embodiments, during the downloading and decryption of the new firmware, the control circuit 121 is configured to power off or disable the processor 123. Once the new firmware has been stored in volatile memory 113, the control circuit 121 is, for example, configured to power on the processor 123.

[0058] According to one embodiment, once the key injection firmware is Stored in volatile memory 113, the initial firmware key 131 is disabled. For example, if the initial firmware key 131 is stored in OTP memory 124, all bits of the key are programmed to overwrite the key's contents. Alternatively, the key injection firmware is re-encrypted, for example, using one of the updated firmware keys 130. This allows the key injection firmware to be reused, for example, before updating to new firmware or following data loss in volatile memory 113.

[0059] Figure 3 is a flowchart illustrating a firmware verification operation according to an embodiment of this description. In particular, Figure 3 illustrates an example of a verification operation that can optionally be performed by the electronic device 100 between steps 202 and 203 and / or between steps 206 and 207 of the process in Figure 2. For example, the firmware is verified after decryption and before its execution by the processor 123.

[0060] According to some embodiments, at the start of the firmware verification operation, the processor 123 is still in a powered-off state and is only powered on if the firmware is successfully verified. The powered-off state of the processor 123 reduces energy consumption and reduces the risk of an attacker introducing code and / or data into the electronic device 100.

[0061] In a step 301 (FORMAT AND / OR CONTENT VERIFICATION), which follows, for example, step 202 and / or step 206, a verification of the correct decryption and authenticity of the decrypted firmware is performed. In some embodiments, another verification operation is performed on the fly while the download and / or decryption process is running. This makes it possible to detect any data corruption, for example, corruption due to noise. If corrupted data is detected, the user interface 102 is used, for example, to interrupt step 202 and / or step 206. For example, the verification of the correct decryption and authenticity of the decrypted firmware involves verifying that the firmware has the expected format and / or content. The verification can be based on certain dedicated fields found within the decrypted firmware.Indeed, it is highly unlikely that a fraudster would be able to generate malicious software which, once processed by the cryptographic processor 108, yields an expected value for such bits. In some embodiments, verification is based on a comparison between a header of the decrypted firmware and a reference bit string stored by the electronic device, for example in OTP memory 124 or by logic circuit 132. In addition to or instead of this, verification is based on the calculation of a signature, such as a MAC (message authentication code), from the mi. decrypted firmware, and on the comparison between the calculated signature and a signature provided with the encrypted firmware.

[0062] Format and / or content verification is performed, for example, by firmware verification hardware (not shown in the drawings), which is capable of accessing locations in volatile memory 113 in order to verify expected values. For example, the firmware verification hardware checks a MAC (message authentication code) value of the firmware and / or another header or termination of the firmware. This operation makes it possible, for example, to verify the authenticity and integrity of the firmware.

[0063] In a step 302 (VALID?), the result of the comparison is for example transmitted to the control circuit 121. If the decryption and the authenticity of the firmware are validated (branch Y) the process continues with a step 303 (ANTI-REPLAY).

[0064] In step 303, which is optional, an anti-reexecution mechanism is implemented, for example, to prevent an obsolete version of encrypted firmware from being reinstalled on the electronic device 100. For example, the anti-reexecution mechanism involves incrementing a pseudo-monotonic counter, which, for example, stores a count value in non-volatile memory, such as OTP memory 124. The count value is then, for example, compared to a count value contained in the firmware. If the count values ​​match, or in the absence of an anti-reexecution mechanism, the process continues with step 304 (FW EXECUTION).

[0065] In step 304, the firmware is executed. According to one embodiment, the processor 123 is powered on to execute the firmware. The process then terminates in step 305 (END), and the device is ready to be used for its final purpose.

[0066] If in step 302 it is determined that the firmware was not validated in step 301 (branch N of step 302), or if the account values ​​do not match during the anti-reexecution step 303, a countermeasure is implemented, for example, in step 306 (COUNTER-MEASURE). The countermeasure includes, for example, deleting the firmware from volatile memory 113. In addition to or instead of this, the countermeasure involves locking the processor 123 in a powered-off state. This prevents falsified firmware from being executed by the processor 123 and causing a potential security problem. The process then terminates in step 305.

[0067] [Fig.4] illustrates an example of implementation of memorizing the value of account 400 of a pseudo-monotonic counter which can be used as part of an anti-re-execution mechanism in step 303 of [Fig.3].

[0068] In the example in [Fig. 4], the pseudo-monotonic counter (not shown in [Fig. 4]) is arranged to store the account value 400 in a location in the OTP memory 124. Such a solution avoids the cost and complexity of a hardware implementation of a true monotonic counter. The OTP memory 124 stores, for example, the account value 400 in addition to one or more updated firmware keys 130 (UPDATED FW KEYS) as described in relation to Figures 1 and 2, and other features 401 (OTHER FEATURES) such as, for example, the initial firmware key 131 or the initial disabled firmware key 131.

[0069] Initially, the value 400 is, for example, entirely composed of unprogrammed bits, for example, bits with the value 0. Each increment of the count value involves a write operation on one of the bits with the value 0, setting it to 1. For example, the bit to be written is the least significant bit with the value 0 in the value 400. Thus, once the counter has been incremented n times, the n least significant bits of the count value will be set to 1. Assuming that the count value 400 has a length of N bits, the maximum count value that can be stored is N. In the example in [Fig. 4], the pseudo-monotonic counter has already been incremented seven times. That is, seven new firmware versions have been stored in volatile memory 113.

[0070] Various embodiments and variations have been described. Those skilled in the art will understand that certain features of these various embodiments and variations could be combined, and other variations will be apparent to those skilled in the art. In particular, the initial firmware key can remain active after decryption and execution of the key injection firmware. The pseudomonotonic counter can also be implemented differently from that described in relation to [Fig. 4], for example by using a different type of memory, and it would also be possible to use a true monotonic counter implemented by hardware.

[0071] Finally, the practical implementation of the embodiments and variants described is within the reach of a person skilled in the art, based on the functional indications given above.

Claims

Demands

1. A method comprising: - executing, by an electronic device (100), a first firmware stored in volatile memory (113) of the electronic device, the execution of the first firmware resulting in an updated firmware key (130) being stored in non-volatile memory (124) of the electronic device; - downloading a second encrypted firmware module into the electronic device via an interface (102) of the electronic device (100); - decrypting the second encrypted firmware module by a cryptographic processor (108) of the electronic device on the basis of the updated firmware key;and - install the second decrypted firmware module into the volatile memory of the electronic device by at least partially overwriting the first firmware, the volatile memory not being directly accessible through the interface, but only through the cryptographic processor.;

2. A method according to claim 1, further comprising, prior to the execution of the first firmware: - downloading the first encrypted firmware module into the electronic device (100); and - decrypting the first encrypted firmware module by the cryptographic processor (108) of the electronic device on the basis of an initial firmware key (131).

3. Method according to claim 2, wherein the initial firmware key (131) is stored in a non-volatile memory (124).

4. Method according to claim 2, wherein the initial firmware key (131) is stored by a hardware configuration (132) of the electronic device (100).

5. A method according to any one of claims 1 to 4, further comprising, after decryption of the second firmware module, a verification that the second firmware module has an expected format and / or content.

6. A method according to claim 5, wherein the verification of the second firmware module is based on a comparison between at least a portion of the code of the first and / or second module of firmware and a reference value.

7. A method according to claim 5 or 6, wherein the electronic device (100) comprises a processing module (123), the method comprising stopping the power supply to the processing module during the downloading, decryption and / or verification of the second firmware module.

8. A method according to any one of claims 1 to 7, wherein the first and / or second firmware module includes a cyclic redundancy check (CRC) field storing a CRC value, the method further comprising a check of the CRC value by a CRC module of the electronic circuit (100).

9. A method according to any one of claims 1 to 8, further comprising, after execution of the first firmware, deactivation of the initial firmware key (131).

10. A method according to any one of claims 1 to 9, further comprising, after execution of the first firmware and before installation of the second firmware module, encryption of the first firmware by the cryptographic processor (108) on the basis of the updated firmware key (130).

11. A method according to any one of claims 1 to 10, wherein, after the installation of the second firmware, the downloading of a new firmware module triggers an increment of an account value (400) stored in non-volatile memory (124).

12. A method according to claim 11, further comprising authorization to install the new firmware based on a comparison between a value contained in the new firmware module and the account value (400).

13. A method according to any one of claims 1 to 12, wherein the cryptographic processor (108) is arranged to perform elliptic curve cryptography to decrypt the first and / or second encrypted firmware module.

14. An electronic device (100) comprising: - volatile memory (113) comprising a first firmware; - non-volatile memory (124) arranged to store a firmware key that is updated (130) during the execution of the first firmware; - an interface (102) arranged to download a second encrypted firmware module; and - a cryptographic processor (108) arranged to decrypt the second encrypted firmware module, based on the updated firmware key (130); Since volatile memory is not directly accessible through the interface, but only through the cryptographic processor, the electronic device is further arranged to install the second decrypted firmware module into volatile memory, partially overwriting the first firmware.

Images