Method of protecting a microcontroller

Abstract

Method for protecting a microcontroller The present description relates to a method for protecting a microcontroller (100) comprising, in a customization phase: calculating a first checksum (Checksum 1) on the content of at least one configuration register (UCONF WR) of the microcontroller stored in a first memory, and storing, in the first memory, said first checksum (Checksum 1); and copying said first checksum and said register to a second memory (104,120); in a startup phase: copying the first checksum and the register, from the second memory (104,120) to the first memory; and comparing a second checksum (Checksum 2), calculated on the content of the copied register (UCONF RD), and the copied first checksum. Figure for abstract: Fig. 3

Description

Title of the invention: Method for protecting a microcontroller Technical field

[0001] The present description relates generally to methods for protecting microcontrollers as well as to microcontrollers implementing such methods. Prior art

[0002] Some microcontrollers use configuration registers that are preloaded at startup from non-volatile memory and can be updated. At startup, these registers are accessible by various components of the microcontroller and allow their configuration. Summary of the invention

[0003] There is a need to protect the components of the microcontroller against attacks targeting the registers and in particular the configuration registers.

[0004] One embodiment overcomes all or part of the drawbacks of the known methods.

[0005] One embodiment provides a method for protecting a microcontroller including, - in a customization phase: calculating a first checksum on the contents of at least one configuration register of the microcontroller stored in a first memory, and storing, in the first memory, said first checksum; and copying said first checksum and said register to a second memory; - in a start-up phase: copying the first checksum and the register, from the second memory to the first memory; and comparing a second checksum, calculated on the contents of the copied register, with the first copied checksum.

[0006] One embodiment provides a microcontroller comprising a first and a second memory, and configured to, - during a customization phase: calculating a first checksum on the content of at least one configuration register of the microcontroller stored in the first memory and storing, in the first memory, said first checksum; and copying said first checksum and said register to the second memory; - during a start-up phase: copy the first checksum and the register, from the second memory to the first memory; and perform a comparison between a second checksum, calculated from the copied register, and the first copied checksum.

[0007] In one embodiment, when the first and second checksums are different during the comparison, then the values ​​of the copied register are modified.

[0008] In one embodiment, when the first and second checksums are identical during the comparison, then the copied register is not modified.

[0009] In one embodiment, the configuration of the microcontroller, defined by the modified values ​​of the register, corresponds to a maximum access restriction level.

[0010] In one embodiment, the configuration of the microcontroller, defined by the modified values ​​of the register, corresponds to a maximum level of addressing mode restrictions.

[0011] In one embodiment, the configuration of the microcontroller, defined by the modified values ​​of the register, corresponds to a maximum boot program access prohibition level.

[0012] In one embodiment, the boot program access prohibition levels correspond, for example, to successively installed boot program protection levels, the protection levels being implemented using a monotonic counter.

[0013] In one embodiment, the configuration of the microcontroller, defined by the modified values ​​of the register, comprises a life cycle state of the microcontroller corresponding to a mode (provisioning) where the content of the programs of the microcontroller is inaccessible.

[0014] In one embodiment, the second checksum is calculated periodically.

[0015] In one embodiment, the storage of the first copied checksum is carried out in a register of the first memory.

[0016] In one embodiment, the first memory is a volatile memory.

[0017] In one embodiment, the second memory is a non-volatile memory.

[0018] In one embodiment, the first and second checksums are based on cyclic redundancy calculations.

[0019] In one embodiment, the calculation of the first and second checksums as well as their comparison are implemented by a memory interface of the first memory or the second memory. Brief description of the drawings

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

[0021] [Fig.l] represents, very schematically and in the form of blocks, an example of an integrated circuit of the type to which the described embodiments apply;

[0022] [Fig.2] schematically represents a method of operation of the microcontroller of [Fig.l] according to an example;

[0023] [Fig.3] schematically represents a method of operation of the microcontroller of [Fig.l] according to one embodiment;

[0024] [Fig.4] schematically represents a phase of an operating method of the microcontroller of [Fig.l] according to one embodiment; and

[0025] [Fig. 5] schematically represents another phase of a method of operation of the microcontroller of [Fig. 1] according to one embodiment. Description of the embodiments

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

[0027] For the sake of clarity, only the steps and elements useful for understanding the described embodiments have been shown and are detailed.

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

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

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

[0031] [Fig.l] represents, very schematically and in the form of blocks, an example of an integrated circuit 100 of the type to which the described embodiments apply. The circuit 100 is for example a microcontroller.

[0032] The circuit 100 comprises a non-volatile memory 104 (NVM), for example of the FLASH or phase change memory (PCM) type, capable of communicating, via a communication bus 114, with a non-volatile memory interface 106 (NVM INTERFACE) configured to write or read data into and from non-volatile memory 104 but also perform operations on the data.

[0033] The circuit 100 further comprises, for example, a processing unit 110 (CPU) comprising one or more processors under control of instructions stored in an instruction memory 112 (INSTR MEM). The instruction memory 112 is, for example, a volatile memory of the random access type (Random Access Memory, RAM). The processing unit 110 and the memory 112 communicate, for example, via a system bus 140 (data, address and control). The non-volatile memory 104 is connected to the system bus 140 via the non-volatile memory interface 106 and via the bus 114. The device 100 further comprises an input / output interface 108 (I / O interface) connected to the system bus 140 to communicate with the outside.

[0034] The circuit 100 may integrate other circuits implementing other functions, for example electronic blocks of intellectual property (IP, Intellectual Property core in English) such as for example, one or more volatile and / or non-volatile memories, or other processing units, symbolized by a block 116 (FCT) in [Fig.l]. Among other circuits, the circuit 100 comprises for example a read-only or static memory 118 (ROM).

[0035] [Fig.2] schematically represents a method of operation of the microcontroller 100 of [Fig.l] according to an example.

[0036] In the example shown, a personalization phase comprises successive steps 202, 204, 206 and 208.

[0037] In step 202 (UNCONF WR), the processing unit 110 writes values ​​into N registers called UCONF of a first memory. In the remainder of the text, when reference is made to a register, this term designates one or more configuration registers. These UCONF registers comprise, for example, configuration information related to security such as first and second levels of access restriction, such as those implemented with the TrustZone protocol of the ARM® CORTEX-M architecture. Other examples of security configuration information consist, for example, of the definition of an application with a first level of privileges (priviledged, Priv) which gives more rights than a second level of privileges (unpriviledged, unPriv). The first and second levels of privileges are, for example, those implemented with an ARM® architecture.Thus, an application configured with the first privilege mode (Priv), that is, in a first mode of addressing mode restriction, has for example its own space with physical addresses. An application implemented with the second privilege mode (unPriv), that is, in a second mode of addressing mode restriction, has for example its own space with virtual addresses and cannot . not have access to other memory-related processes that would directly use physical addresses. The UCONF registers include, for example, other security-related configuration information such as product state (life cycle) information, Timing isolation level areas information, addresses indicating where the processing unit 110 should start, or security keys.

[0038] In one example, these N UCONF configuration registers are coded on 32 bits.

[0039] In another example these registers are stored, when they are written by the unit of processing 110, in a first volatile memory.

[0040] In step 204, the values ​​of the registers are examined by a verification circuit 205 (security checker) which is for example implemented by the memory interface 106. The verification circuit 205 verifies for example whether the configurations stored in the UCONF registers are legal.

[0041] If no problem is detected, then step 206 is implemented and the verification circuit 205 generates one or more Wr_en signals which are for example coded on several bits to ensure information security.

[0042] When the Wr_en signal is generated, step 208 (UCONF storage) is implemented and the UCONF registers are written to a non-volatile memory, for example memory 104 or 120, for example via a bus such as bus 114.

[0043] This customization phase is implemented for example by a professional user such as a subcontractor or an integrator of the microcontroller 100.

[0044] In a start-up phase comprising successive steps 210 and 212, the microprocessor 110 is restarted.

[0045] In step 210, the registers stored in the non-volatile memory 104 are read and copied (UCONF RD) to a memory, for example volatile, for example the first memory.

[0046] In step 212, blocks 108, 116 or 118, blocks 222 (IPs) or unit 110 are configured using the values ​​of the copied configuration registers (UCONF RD). Blocks 222 are for example electronic intellectual property IP blocks.

[0047] When copying the values ​​of the registers from the second memory, attacks or hacks can be implemented to, for example, modify the values ​​of the configuration registers or even provide useful information for other types of subsequent hacking. These attacks can also open temporary entry points for malicious programs.

[0048] In order to reduce the impact or prevent these attacks, it is possible for example to copy, in step 208, two or more times the values ​​of the registers, or their inverse, to two different locations. This nevertheless requires mobilizing large chip sizes. It is also possible to use error correction codes. However, this solution only allows correction of two or three corrupted bits and requires an increase in the number of registers.

[0049] To overcome these drawbacks, the embodiments described propose a method for protecting the microcontroller 100 comprising, - in a customization phase: calculating a first checksum (checksum 1) on the content of at least one configuration register (UCONF WR) of the microcontroller stored in a first memory, and storing, in the first memory, said first checksum; and copying said first checksum and said register (UCONF WR) to a second memory 104,120; - in a start-up phase: copying the first checksum, checksum 1, and the register, from the second memory to the first memory; and the comparison between a second checksum (Checksum 2), calculated on the contents of the copied register (UCONF RD), and the first copied checksum.

[0050] An advantage of this method is that it allows manufacturing costs to be reduced, while allowing rapid processing and guaranteeing a high level of security for the configuration registers. On the other hand, this method is compatible with cyclic redundancy codes of 8, 16, 32 or more bits.

[0051] When the first and second checksums are different during the comparison, which may correspond to an attack, then the copied register is modified so that its values ​​correspond to a maximum security configuration. The functions 108, 116, 118, 222 are thus potentially reconfigured to be in maximum protection modes.

[0052] [Fig.3] schematically represents a method of operation of the microcontroller of [Fig.l] according to one embodiment.

[0053] In the example shown, the personalization phase comprises steps 202, 204 and 206 which are identical to those of the example of [Fig.2], as well as successive steps 302 and 304.

[0054] In step 302, after step 206, once the signal Wr_en has been generated, a first checksum 1 (checksum in English) is calculated by a calculation unit (Checksum generator) for example integrated into the control unit 205 of the memory interface 106.

[0055] In one example, a checksum Checksum 1 is for example calculated for each of the UCONF WR registers. There are therefore potentially as many first checksums as there are configuration registers.

[0056] Generically, a checksum is the result of running an algorithm, for example called a cryptographic hash function, on a piece of data, here the values ​​contained in a register. There are many hash functions such as MD5, SHA1, SHA256.

[0057] In another example, the checksums are implemented with a cyclic redundancy check (CRC).

[0058] This is followed by step 304, in which the first calculated checksum, for each register, as well as the associated registers (UCONF storage), are copied then stored in the second memory 104,120.

[0059] In a subsequent phase of starting the microcontroller and its processing unit, in other words the microprocessor 110, the values ​​of the UCONF storage registers and the associated checksums copied into the second memory are copied, during a step 310, to a respective UCONF_CRC_EXP register of a memory, for example volatile, which is for example the first memory.

[0060] In a step 316, subsequent to step 310 and similar to step 212, the copied values ​​of the registers (UCONF RD) can be used for example for the configuration of the blocks 108, 116, 118, 222 (IPs) and / or of the unit 110.

[0061] In a step 318, subsequent to step 316, a comparison unit 313 (Checksum checker), for example implemented by a memory interface such as the memory interface 106 or by the control unit 205, calculates a second checksum Checksum 2 for each copied register. In one example, the control unit 205 and the comparison unit 313 are the same circuit, for example formed in the memory interface 106. The comparison unit 313 compares these second checksums which have been calculated with the respective first checksums which have been copied and stored in the respective registers UCONF_CRC_EXP. Depending on the result of the comparison, the state of one or more signals called “status”, for example coded on several bits, indicates whether the comparison highlights a difference between the copied checksums and the recalculated checksums.In the case where the checksums are identical, then the values ​​of the UCONF RD registers remain unchanged. In the case where the first and second checksums are different during the comparison, then the values ​​of the copied UCONF RD registers are modified, for example by the control unit 205 or the comparison unit 313, to take on configuration values ​​that are stricter in terms of access and security. This modification remains valid until the next restart of the microprocessor 110 or the microcontroller 100. The blocks 108, 116, 118, 222 (IPs) and / or the processor 110 thus see their configuration modified towards a configuration that is stricter in terms of access and / or security.

[0062] In an example of a stricter configuration in terms of access and / or security, a configuration of the microcontroller or microprocessor 110, defined by the modified UCONF RD register(s), includes a maximum level of access restriction corresponding for example to the “secure” mode of the TrustZone protocol of the ARM® architecture.

[0063] In another example, the configuration of the microcontroller 100, or the microprocessor 110, defined by the modified UCONF RD register(s), includes a maximum level of addressing mode restrictions (priviledged in English).

[0064] In another example, the configuration of the microcontroller 100, or the microprocessor 110, defined by the modified UCONF RD register(s), includes a maximum boot program access prohibition level (HDPL0). In this example, the boot program access prohibition levels (HDPL) correspond, for example, to successively installed boot program protection levels, the protection levels being implemented using a monotonic counter.

[0065] In another example, the configuration of the microcontroller 100, or of the microprocessor 110, defined by the modified UCONF RD register(s), corresponds to a life cycle state of the microcontroller (product_state) corresponding to a mode (called provisioning in English) where the content of the programs of the microcontroller is inaccessible. In other words, in this state, even the manufacturer of the microcontroller cannot access the content of the programs of the microcontroller or of the microprocessor 110.

[0066] Step 318 can be implemented at each startup phase or after several restarts.

[0067] [Fig.4] schematically represents a phase of an operating method of the microcontroller of [Fig.l] according to one embodiment. More particularly, the example shown illustrates the customization phase.

[0068] The customization phase of [Fig.4] includes step 204 (Write UCONF WR) which is followed by step 206 (Security check ok?). If during step 206, the control unit detects a fault (path “N”) then for example step 204 is restarted or an error is returned to the processing unit 110. If during step 206 the control unit does not detect a fault (path “Y”) then step 302 (Compute Checksum 1) is implemented.

[0069] Once the first checksum has been calculated, then step 304 (Write UCONF WR + Checksum 1 in NVM) is implemented and the values ​​of the UCONF WR registers as well as their respective first checksums are written into the second memory 104,120.

[0070] [Fig. 5] schematically represents another phase of an operating method of the microcontroller of [Fig. 1] according to one embodiment. More particularly, the example of [Fig. 5] illustrates a start-up phase.

[0071] In the example shown, after starting the microcontroller 100 or the microprocessor 110, step 310 (Read UCONF and Checksum 1) is implemented. In this step, the values ​​of the registers and the associated checksums stored in the second memory 104, 120 are copied into the first memory for example.

[0072] Step 316 (Write UCONF RD to registers) is then implemented. In this step, registers of the different blocks 108, 116, 118, 222 (IPs) and / or the unit 110 are written with the respective values ​​of the copied UCONF RD configuration registers.

[0073] Step 318 (Computed Checksum 2 is equal to expected Checksum?) is then implemented. If the second calculated checksums are equal to the respective first checksums that were copied in step 310 (Y branch), then a step 516 (Keep UCONF value) is implemented. In this step 516, the values ​​of the UCONF RD configuration registers remain unchanged. If the second calculated checksums are different from the respective first checksums that were copied into the respective UCONF_CRC_EXP registers in step 310 (N branch), then a step 515 (Force UCONF RD to most secure) is implemented. In this step 515, the values ​​of the copied registers UCONF RD are modified, for example by the control unit 205 or the comparison unit 313, and replaced by the strictest configuration values ​​in terms of access and security.This modification remains valid until the next restart of the microprocessor 110 or the microcontroller 100. The blocks 108, 116, 118, 222 (IPs) and / or the processor 110 thus see their configuration modified towards a stricter configuration in terms of access and / or security, which makes it possible to limit the effects of an attack.

[0074] Various embodiments and variants have been described. Those skilled in the art will understand that certain features of these various embodiments and variants could be combined, and other variants will occur to those skilled in the art. In particular, in step 515, the values ​​of the copied registers UCONF RD may be modified and replaced with configuration values ​​that are more stringent in terms of access and security while not being the most stringent conditions in terms of access and security possible.

[0075] Finally, the practical implementation of the embodiments and variants described is within the reach of the person skilled in the art from the functional indications given above. In particular, as regards the calculation of the second checksums, it may be carried out at each start-up cycle or after several start-up cycles. boot. In addition, at each boot cycle, it will be possible, for example, to calculate the second checksum on the values ​​of only one or some of the configuration registers.

[0076] In another example, step 318 may take place before step 316.

Claims

Claims

1. Method for protecting a microcontroller (100) comprising, - in a customization phase: calculating a first checksum (Checksum 1) on the content of at least one configuration register (UCONF WR) of the microcontroller stored in a first memory, and storing, in the first memory, said first checksum (Checksum 1); and copying said first checksum and said register to a second memory (104,120); - in a startup phase: copying the first checksum and the register, from the second memory (104,120) to the first memory; and comparing a second checksum (Checksum 2), calculated on the content of the copied register (UCONF RD), and the copied first checksum.

2. The method of claim 1, wherein when the first and second checksums are different when compared, then the values ​​of the copied register (UCONF RD) are modified.

3. The method of claim 2, wherein when the first and second checksums are identical when compared, then the copied register (UCONF RD) is not modified.

4. Method according to claim 2 or 3, in which the configuration of the microcontroller, defined by the modified values ​​of the register, corresponds to a maximum access restriction level (secure).

5. Method according to any one of claims 2 to 4, in which the configuration of the microcontroller, defined by the modified values ​​of the register, corresponds to a maximum level of addressing mode restrictions (priviledged).

6. A method according to any one of claims 2 to 5, wherein the configuration of the microcontroller, defined by the modified values ​​of the register, corresponds to a maximum boot program access prohibition level (HDPL0).

7. The method of claim 6, wherein the boot program access prohibition levels (HDPL)

8.

9.

10.

11.

12.

13.

14.

15. correspond for example to protection levels of successively installed boot programs, the protection levels being implemented using a monotonic counter. Method according to any one of claims 2 to 7, in which the configuration of the microcontroller, defined by the modified values ​​of the register, comprises a life cycle state of the microcontroller (product_state) corresponding to a mode (provisioning) where the content of the programs of the microcontroller is inaccessible. A method according to any one of claims 1 to 8, wherein the second checksum is calculated periodically. Method according to any one of claims 1 to 9, wherein the storage of the first copied checksum is carried out in a register of the first memory (UCONF_CRC_EXP). Method according to any one of claims 1 to 10, wherein the first memory is a volatile memory. The method of any one of claims 1 to 11, wherein the second memory (104,120) is a non-volatile memory. The method of any one of claims 1 to 12, wherein the first and second checksums are based on cyclic redundancy calculations (CRC). Method according to any one of claims 2 to 13, wherein the calculation of the first and second checksums as well as their comparison are implemented by a memory interface of the first memory or the second memory. Microcontroller (100) comprising a first and a second memory (104,120), and configured to implement the method according to any one of the preceding claims.

Images