Safe startup of a processing device

Abstract

Secure startup of a processing device. This description relates to a method comprising the execution, by a processor (104) of a processing device (100), of startup code to perform a startup sequence of the processing device, the execution comprising: - at least one step to verify the correct execution of the startup sequence; and - if at least one verification step identifies an error in the execution of the startup sequence, the storage of a status value in a register (114) of the processing device and the reset of the processing device, the register (114) being accessible for reading via a debugging interface (112) of the device. Figure for the abstract: Fig. 1

Description

Title of the invention: Secure start-up of a processing device Technical field

[0001] The present disclosure relates generally to electronic devices, and in particular to processing devices and methods of starting a processing device. Prior art

[0002] Generally, when starting a processing device, such as a device comprising one or more processors, a startup code is executed in order to verify, for example, the authenticity and / or integrity of certain application codes.

[0003] For security and privacy reasons, startup code generally executes without displaying information about the execution progress, and such information is then not available to a user of the device. Thus, if an error occurs, it is not possible to understand the cause, or even when the error occurred. Similarly, when the startup code includes the installation of application code, the installation may fail without the user of the device being notified. In the event that an error occurs during this startup, the absence of information makes it difficult to debug the startup code. However, there is a technical problem in enabling debugging of the startup code without compromising the security of the execution of this code. Summary of the invention

[0004] One embodiment provides a method comprising the execution, by a processor of a processing device, of a startup code in order to carry out a startup sequence of the processing device, the execution comprising: - at least one step of verifying the correct execution of the startup sequence; and - if the at least one verification step identifies an error in the execution of the startup sequence, storing a status value in a register of the processing device and resetting the processing device, the register being accessible for reading via a debugging interface of the device.

[0005] According to one embodiment, the status value is encoded on a plurality of bits, each bit indicating the status of an associated verification step.

[0006] According to one embodiment, the startup code is configured to, following each verification step, control the programming of a bit associated with a verification step, towards a first value when an error has occurred during the verification step.

[0007] According to one embodiment, the register is part of non-volatile memory, the register being readable via the debug interface during execution of the startup code without other locations in the non-volatile memory being accessible via the debug interface.

[0008] According to one embodiment, the above method further comprises: - retrieving the status value, via the debugging interface; and - debugging, by an external device, of the startup sequence, based on the status value.

[0009] According to one embodiment, the recovery of the status value takes place during the execution of the startup sequence.

[0010] According to one embodiment, the processor is in a closed state during the boot sequence.

[0011] According to one embodiment, at least one verification step, among the plurality of startup code verification steps, comprises verifying the authenticity and / or the integrity and / or the format of one or more application codes loaded into a first memory location.

[0012] According to one embodiment, at least one verification step, among the plurality of startup code verification steps, comprises verifying the authenticity and / or integrity and / or format of one or more installation or update codes loaded into a second memory location.

[0013] According to one embodiment, the status value is a hexadecimal value.

[0014] One embodiment provides a processing device comprising: - a processor configured to, upon execution of a startup code to perform a startup sequence of the processing device, perform: - at least one step to verify the correct execution of the startup sequence; and - if the at least one verification step identifies an error in the execution of the startup sequence, storing a status value in a non-volatile register of the processing device and resetting the processing device, the register being accessible for reading via a debugging interface of the device.

[0015] According to one embodiment, the register is part of a non-volatile memory, the register being accessible for reading via the debugging interface during executing the startup code without other locations in non-volatile memory being accessible through the debugging interface.

[0016] According to one embodiment, the register is accessible during the startup sequence via the debugging interface.

[0017] According to one embodiment, the processor is in a closed state during the boot sequence. Brief description of the drawings

[0018] 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:

[0019] [Fig.l] is a block diagram of a processing device according to an embodiment of the present description;

[0020] [Fig.2] is a flowchart illustrating steps of a method of executing a startup code according to an embodiment of the present disclosure; and

[0021] [Fig.3] illustrates an example of an embodiment of an interface of the processing device. Description of the embodiments

[0022] 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.

[0023] 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 different steps executed during a start-up of a processing device are not described in detail.

[0024] 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.

[0025] 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.

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

[0027] [Fig.l] is a block diagram of a processing device 100 comprising an integrated circuit 102 according to an embodiment of the present description.

[0028] The processing device 100 is for example a mobile, such as a mobile telephone, or an electronic card such as a microcircuit card.

[0029] The circuit 102 comprises for example a processor 104 (CPU) connected to a non-volatile memory 106 (NV MEM) and to a volatile memory 108 (RAM) via a bus 110. By way of example, the memory 106 is a Flash type memory, and the memory 108 is a volatile memory, for example of the RAM type (from the English "Random Access Memory").

[0030] The processing device further comprises, for example, a debugging interface 112 (INTERFACE). The interface 112 is, for example, a JTAG (from the English "far Test Action Group") type interface or a SWD (from the English "Serial Wire Debug") type interface. The interface 112 is, for example, an interface configured to allow access to the device 100 when performing debugging operations of the circuit 102.

[0031] When the processing device 100 is started, a startup code, for example stored in the non-volatile memory 106, is executed. The startup code makes it possible, for example, to verify the correct operation of the circuit 102 and in particular the integrity and / or authenticity of certain application codes executing following the startup of the processing device 100. The startup code also makes it possible, for example, to update application codes, for example stored in the non-volatile memory 106. The startup code also makes it possible, for example, and during certain startups of the device 100, to install other application codes. For example, during an update and / or installation of an application code, the startup code is further configured to verify the authenticity and integrity of the update and / or the installed application code.

[0032] The processor 104 is for example locked, or placed in a closed state, during the execution of the startup code, for security reasons. Indeed, the execution of the startup code involves, for example, sensitive and / or confidential data, such as, for example, encryption keys. In particular, in the closed state, the processor 104 is not accessible via the interface 112. Thus, this provides protection against attacks aimed at obtaining information on this sensitive and / or confidential data.

[0033] For example, the non-volatile memory 106 includes a register 114 (REGISTER) connected to the interface 112. For example, the register 114 is accessible by the interface 112 when the startup code executes, without other locations in the non-volatile memory 106 being accessible by the interface 112. According to one embodiment, the register 114 is for example configured to receive, for example via the bus 110, indications on the progress of the startup code. For example, the startup code is carried out in a plurality of steps. The startup code is for example configured to, following at least one step, control the storage, in the register 114, of a status indication value of the execution of the startup code in the register 114 indicating whether the step was successful or not.

[0034] According to one embodiment, the indication takes the form of a bit field. Each bit is for example associated with the state of a step among steps of the execution of the startup code.

[0035] For example, programming a bit of the status indication value to 1 indicates that an error occurred during the associated step, and programming it to 0 indicates that the associated step completed without error. In another example, programming it to 0 indicates that an error occurred during the step and programming it to 1 indicates that the step completed without error.

[0036] For example, the status indication value provided by the register 114 to the interface 112 takes the form of a hexadecimal value. The hexadecimal value encodes, for example, the information on which steps have presented errors and which have not presented errors. In another example, the indication value is a binary number whose number of bits corresponds, for example, to the number of steps in which the startup code is configured to indicate the presence of an execution error or not.

[0037] The startup code is for example an immutable code and is executed for example like a “black box”. In other words, apart from what is recorded in the register 114, the execution of the startup code leaves no history of the steps of its execution. For example, when an error occurs during the execution of the startup code, an initialization of the device 100 is executed, which can cause the processing device to enter an infinite loop. The error comes, for example, from an incorrect configuration of the startup code and / or from an incorrect encryption of the application code to be installed or updated and / or from a lack of integrity and / or from the integrity of the application code and / or from an incorrect format in the coding of the application code, etc.

[0038] [Fig.2] is a flowchart illustrating steps of a method of executing a boot code. This method is implemented, for example, by the processor 104, under the control of instructions stored in a memory of the device 100, such as the memory 106 or 108.

[0039] In a first phase 200 (SECURE BOOT), the processing device 100 is for example started or reset. The startup code is then executed. The first phase 200 comprises for example steps 201 to 212 and 212'.

[0040] In step 201 (INIT), the processing device 100 is for example initialized. For example, the processor 104 is placed in the closed state and the startup code, as well as for example sensitive data such as encryption keys, are for example not accessible via the interface 112.

[0041] It is then checked, in step 202 (OK?), whether the initialization, carried out in step 201, was successful or not. For example, if an error is detected during the performance of step 202 (branch N), the method continues in a step 203 (STATUS SAVED). For example, an error occurs in step 201 when an encryption key is corrupted. In another example, an error during step 201 occurs when the processing device 100 is incorrectly configured and the startup code does not execute.

[0042] During step 203, the status indication value, for example stored in register 114, is updated. For example, the bits of the status indication value are by default all programmed to the value 0. Following an error in step 201, the bit of the status indication value associated with the initialization step 201 is for example programmed to the value 1, indicating that an error occurred during the performance of this step. In another example, the bit is for example left at the value 0, if it is this value which indicates an error.

[0043] Following step 203, the method resumes at initialization step 201.

[0044] In the case where step 201 has been completed successfully (branch Y at the exit of step 202), in other words, if no error has occurred, the process continues in step 204 (CONFIG).

[0045] Step 204 is for example a step in which the configuration of the startup code is verified. Following step 204, it is verified in a new step 205 (OK?) whether the verification step 204 was carried out without error, in other words whether the configuration of the startup code was not completed successfully.

[0046] In the case where at least one error has occurred during step 204 of configuration verification (branch N at the output of step 205), the method continues in an embodiment of step 203. The bit of the indication value associated with the configuration verification step is then programmed to the value indicating an error.

[0047] In the case where no error has occurred during the execution of the configuration verification step 204 (branch Y at the output of step 205), the method continues in a step 206 (SEC. ACTIVATION). Step 206 consists for example of the activation of security measures on the circuit 102, and more particularly on the processor 104. For example, during step 206, a memory protection unit (in English "Memory Protection Unit") is activated in order to limit the execution of the startup code to a particular memory, for example to a User Flash type memory included in the memory 106. For example, during of step 206, a secure access unit (in English "Secure Access Unit") is activated in order to define and protect secure areas of the memory 106. For example, during step 206, physical alteration detection mechanisms (in English "tamper detection mechanisms") are activated in order to detect physical attacks on the device 100. For example, step 206 further comprises the verification of optional bits (from the English "Option Bytes"), for example included in the memory 108. For example, the optional bits define a secure area and / or an unsecured area of ​​the memory 106. Following step 206, it is determined, in a step 207 (OK?), whether step 206 has been correctly executed. In other words, step 207 consists of checking whether at least one error occurred during the execution of step 206.

[0048] In the event that at least one error in the execution of step 206 is detected in step 207 (branch N), the method continues in an embodiment of step 203. The bit of the status indication value associated with the configuration step of step 206 is programmed to the value indicating an error.

[0049] If, during step 207, it is determined that step 206 was completed without error, the method continues in a step 208 (SECONDARY CTRL). During step 208, one or more secondary memory locations, for example included in the non-volatile memory 106, are consulted. For example, the one or more secondary memory locations are configured to store one or more update codes for one or more application codes of the processing device 100. Alternatively or additionally, the one or more secondary memory locations are configured to store one or more installation programs for one or more new application codes. In another example, the one or more secondary locations are empty, for example in the case where no application code is to be updated or installed.For example, step 208 includes verifications of authenticity and / or integrity and / or format of the code(s) included in one or more secondary memory locations.

[0050] Following step 208, it is determined, in step 209 (OK?), whether at least one of the verifications among those of the integrity, authenticity and format of the application code(s) has failed. In other words, it is determined whether at least one update or installation is not integral and / or is not authentic and / or has a format problem.

[0051] If at least one of the checks failed during the performance of step 208 (branch N at the output of step 209), the method continues with a performance of step 203. The bit of the status indication value associated with step 208 is programmed to the value indicating an error during step 208.

[0052] In the case where the checks of step 208 have all succeeded, (branch Y at the output of step 209), the method continues for example in step 210 (PRIMARY CTRL). In the case where steps 208 and 209 are not carried out, step 210 follows the detection of no error during the execution of step 206.

[0053] When performing step 210, one or more primary memory locations are for example consulted by the processor 104. By way of example, one or more primary memory locations comprise one or more application codes configured to be executed following the start-up of the processing device 100. By way of example, step 210 comprises verifications of authenticity and / or integrity and / or format of the code(s) included in one or more primary memory locations.

[0054] Following step 210, the status of the checks carried out during the performance of step 210 is determined in step 211 (OK?).

[0055] In the case where the checks of step 210 have all succeeded, (branch Y at the output of step 211), the method continues in step 212 (STATUS SAVED). Otherwise, (branch N at the output of step 211), the method continues in step 212' (STATUS SAVED).

[0056] Step 212' consists for example of programming the bit of the status indication value associated with step 210 to the value indicating an error.

[0057] Step 212 consists, for example, of programming the bits associated with steps 201, 204, 206, 208 and 210 to the value indicating that no error occurred during the performance of these steps. In another example, when one of steps 201, 204, 206 and 208 is completed successfully, the bit of the status indication value is directly programmed to the value indicating that no error occurred. Thus, step 212 is similar to step 212' except that the bit is programmed to the value indicating that no error occurred. In the example where the default value of the status indication value corresponds to the value indicating that no error occurred during the execution of the startup code, or at least, during the verified steps, step 212 is for example omitted.

[0058] For example, the status indication value programmed during step 203, step 212 or step 212' is equal, depending on the progress of the startup sequence, to the following values ​​programmed with the corresponding instructions:

[0059] INIT_DONE (step 201 successful) (0x00000001UL)

[0060] CONFIG_DONE (step 204 successful) (0x00000002UL) [0061 ] SECURITY_DONE (step 206 successful) (0x00000004UL)

[0062] SLOT_PRIMARY_1_VALID (first valid primary memory location) (OxOOOOOOlOUL)

[0063] SLOT_PRIMARY_2_VALID (Second valid primary memory location) (0x00000020UL)

[0064] SLOT_SECONDARY_1_VALID (first valid secondary memory location) (0x00000040UL)

[0065] SLOT_SECONDARY_2_VALID (Second valid secondary memory location) (0x00000080UL)

[0066] PARSING_DONE (code parsing successful, performed in step 208) (OxOOOOOlOOUL)

[0067] INSTALLATION_DONE (code installation successful, performed in step 208) (0x00000200UL)

[0068] VALIDATION_DONE (code validation successful, performed in step 210) (0x00000400UL)

[0069] JUMP_BL (jump to boot loader instruction - "Boot Loader" in English - successful) (0x00001000UL)

[0070] JUMP_APPLI (jump instruction to application execution successful) (0x00002000UL) where the values ​​are in hexadecimal and the letters "UL" indicate unsigned long format.

[0071] According to the coding defined above, each step is associated with a corresponding bit of the status indication value, and in some embodiments, it is possible for multiple bits to be programmed at once to indicate that multiple steps have succeeded.

[0072] Following the completion of step 212 or 212', the method continues in a phase 213 (BOOT END). For example, phase 213 comprises a step 214 (APP. EXECUTION) following for example step 212. Step 214 consists for example of the execution of the application code(s) for example included in the other memory location. During phase 213, the user has for example the possibility of obtaining information on the application codes being executed, which was not the case during phase 200 during the execution of the startup code.

[0073] Phase 213 further comprises a step 215 (STD LOADER EXECUTION) following, for example, step 212'. For example, step 215 is performed when an error has occurred during step 210. For example, step 215 comprises the execution of a loader type software code allowing access to one or more secondary locations in order to load one or more new application codes. For example, the software code is stored in the non-volatile memory 106. For example, the software code is stored in an area defined as non-secure in the non-volatile memory 106, this area being for example an area reserved for the system code.

[0074] For example, the status indication value is accessible, via the interface 112 at any time during the execution of the startup code. Thus, it is possible for a user of the processing device 100, for example by connecting a test device (not shown) to the interface 112, to retrieve the status indication value and to deduce therefrom at which stage of the startup an error occurred. In this way, it is for example possible to know whether the error is linked to the configuration of the startup code. The test device is for example connected to the interface 112 via connectors, and / or a wireless link.

[0075] For example, when an error occurs in the execution of phase 200 of the startup code, the interface 112 is configured to implement a protocol for extracting and retrieving the status indication value.

[0076] [Fig.3] illustrates, in more detail, the interface 112, and more particularly, the interactions between the interface 112 and the processor 104.

[0077] The interface 112 comprises, for example, a register 300 (APSEL) configured to store a value, for example the value of a bit. The interface 112 further comprises, for example, a debug port 302 (SWJPD) allowing the connection of an external test device (not shown), such as a computer. By way of example, the port 302 is accessible via the external test device and allows the value included in the register 300 to be programmed. The interface 112 further comprises, for example, a register 303 (DBGMCU) connected to the register 300.

[0078] The processor 104 implements, for example, a debugging protocol 304 (PROTOCOL) for application codes of the device 100. For example, the protocol 304 can be executed when performing step 214, but is not accessible during the startup phase 200. In particular, the processor 104 is, for example, configured to be placed in an open state from phase 213 of [Fig. 2], when the startup phase 200 is completed. For example, when a bit stored in the register 300 is programmed to the value 1 by the external test device, the processor 104 is accessible in debugging via the protocol 304. The example of programming a bit to the value 1 is not limiting and other programmings of one or more bits of data included in the register 300 are of course conceivable.

[0079] For example, the processor 104 is configured to be in a closed state during execution of the startup code, and more particularly during phase 200 of the startup code. When the processor 104 is in the closed state, access to the processor 104 via the protocol 304 and the interface 112 is locked.

[0080] During phase 200, it is possible for the external test device, connected to the interface 112 and in particular to the port 302, to command the extraction of the status indication value. For example, the status extraction command does not is not carried out on the basis of a certificate and / or permission. For example, the value programmed in register 300 during phase 200 allows the external test device to access register 303 and program a keyword there. Programming this keyword in register 303 causes, for example, a reset of the processing device 100. During the reset, the processor 104 is then configured to execute, on the basis of the keyword present in register 303, a protocol allowing the external test device to control the extraction of the status indication value and transmit it to the test device.

[0081] Although the status indication value is stored in a non-volatile memory, not necessarily secure, the method of debugging the startup code is for example subject to one or more access restrictions. For example, a user of the device 100 is able to read, during the startup phase 200, the status indication value but not to debug the startup code.

[0082] An advantage of the described embodiments is that they make it possible to provide the user of the device 100 with an indication of the status of the startup procedure of the device 100. Indeed, when the startup code is not executed correctly, the status indication value gives the user information on the step in which the error occurred.

[0083] 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 occur to those skilled in the art. In particular, the form of the shape and the coding of the status indication value may vary. Similarly, only some of the verification steps 204, 206, 208, 210 of [Fig. 2] may be implemented, and / or other verification steps inherent in the execution of the startup code, in addition to or instead of the steps described in connection with [Fig. 2], may be performed. Those skilled in the art will know how to choose the steps in the execution of the startup code for which they wish to obtain an indication of the progress.

[0084] Finally, the practical implementation of the embodiments and variants described is within the reach of those skilled in the art from the functional indications given above. In particular, with regard to the storage of the status indication value, other memories than those described in relation to [Fig.l] can be used to store this value.

Claims

Claims

1. Method comprising the execution, by a processor (104) of a processing device (100), of a startup code in order to carry out a startup sequence of the processing device, the execution comprising: - at least one step of verifying the correct execution of the startup sequence;and - if the at least one verification step identifies an error in the execution of the startup sequence, storing a status value, indicating that an error in the execution of the startup sequence occurred during the at least one verification step, in a register (114) of the processing device and resetting the processing device, the register (114) being part of a non-volatile memory (106) and being accessible for reading via a debugging interface (112) of the device during execution of the startup code without other locations in the non-volatile memory (106) being accessible via the debugging interface.;

2. The method of claim 1, wherein the status value is encoded on a plurality of bits, each bit indicating the status of an associated verification step.

3. The method of claim 2, wherein the startup code is configured to, following each verification step, control the programming of a bit associated with a verification step, to a first value when an error has occurred during the verification step.

4. A method according to any one of claims 1 to 3, further comprising: - retrieving the status value, by the debugging interface (112); and - debugging, by an external device, the startup sequence, based on the status value.

5. The method of claim 4, wherein the retrieval of the status value occurs during execution of the startup sequence.

6. A method according to any one of claims 1 to 5, wherein the processor (104) is in a closed state during the boot sequence.

7. A method according to any one of claims 1 to 6, wherein at least one verification step, among the plurality of startup code verification steps, comprises verifying the authenticity and / or integrity and / or format of one or more application codes loaded into a first memory location.

8. A method according to any one of claims 1 to 7, wherein at least one verification step, among the plurality of startup code verification steps, comprises verifying the authenticity and / or integrity and / or format of one or more installation or update codes loaded into a second memory location.

9. The method of any one of claims 1 to 8, wherein the status value is a hexadecimal value.

10. A processing device (100) comprising: - a processor (104) configured to, upon execution of a startup code to perform a startup sequence of the processing device, perform: - at least one step of verifying the proper execution of the startup sequence; and - if the at least one verification step identifies an error in the execution of the startup sequence, storing a status value, indicating that an error occurred during the at least one verification step, in a non-volatile register (106) of the processing device and resetting the processing device, the register being part of a non-volatile memory (106) and being readable via a debugging interface (112) of the device during execution of the startup code without other locations in the non-volatile memory (106) being accessible via the debugging interface.

11. The processing device (100) of claim 10, wherein the register (114) is accessible during the startup sequence via the debug interface (112).

12. A processing device (100) according to claim 10 or 11, wherein the processor (104) is in a closed state during the startup sequence.

Images