Patent Application
20220317184
This application claims the benefit of French Patent Application No. 2103315, filed on Mar. 31, 2021, which application is hereby incorporated herein by reference.
The present disclosure relates to methods and devices for securing electronic circuits, and in particular to a device and method for performing secure debugging of such a circuit.
Debugging procedures for a processing device are likely to be problematic in applications where memories of the device contain confidential, sensitive data. This may include encryption keys, passwords, codes, or keys used in the life of the circuit, boot codes, or proprietary protocols stored in a device memory by the manufacturer of the device or by an intermediate entity between the manufacturer and an end user. It is desirable that the security of sensitive data should not be compromised during a debugging procedure.
Embodiments provide improvements to the security of access to sensitive data.
Various embodiments address all or some of the drawbacks of known processing devices.
Other embodiment provide a method for debugging a processing device, the method comprising generating, by a monotonic counter, a first count value, transmitting, by the monotonic counter, the first count value to a debug access control circuit, comparing, by the debug access control circuit, the first count with one or more reference values, and authorizing or preventing access for debugging by the debug access control circuit based on the comparison.
According to one embodiment, the first count value is generated in a first step of a boot sequence of the processing device, this first step comprising incrementing the monotonic counter to a second count value after transmission of the first count value.
According to one embodiment, the authorization or prevention comprises preventing access for debugging based on the first count value, the method further comprises transmitting, by the monotonic counter, the second count value to the debug access control circuit, comparing, by the debug access control circuit, the second count value with the said one or more reference values and authorizing debug access based on the second count value.
According to one embodiment, the first count value corresponds to an initialization value of the monotonic counter during a first boot of the processing device and the second count value corresponds to an initialization value of the monotonic counter at a second boot of the processing device.
According to one embodiment, during the first boot, the processing device is initially placed in a first state in which the debug access by the debug access circuit is authorized based on the first count value, and, during the second boot, the processing device is locked in a second state in which the debug access by the debug access circuitry is prevented based on the first count value.
According to one embodiment, the method further comprises transmitting the first count value, by the monotonic counter, to an access control circuit of a memory of the processing device, reading, based on the first count value, of the first data stored in the memory, transmitting the second count value, by the monotonic counter, to the access control circuit of the memory of the processing device and reading, based on the second count value, of the second data stored in the memory, the memory access control circuit being configured such that reading of the first data is not authorized based on the second count value.
According to one embodiment, the first and second states of the processing device are defined by one or more values stored in the memory.
According to one embodiment, the debug access control circuit authorizes debug access based on a count value greater than or equal to the said one or more reference values and prevents debug access based on a count value strictly less than the said one or more reference values.
According to one embodiment, the method further comprises, prior to authorizing or preventing debugging access, receiving by the debug access circuit a debug access request from an external device and verifying by the debug access circuit of authentication of the external device, wherein authorization or prevention of debug access by the debug access control circuit is also performed based on the authentication verification.
One embodiment provides a data processing device comprising a monotonic counter configured to generate a first count value and a debug access control circuit configured to compare the first count value with one or more reference values and authorize or prevent debug access based on the comparison.
The foregoing features and advantages, as well as others, will be described in detail in the following description of specific embodiments given by way of illustration and not limitation with reference to the accompanying drawings, in which:
Like features have been designated by like references in the various figures. In particular, the structural and/or functional features that are common among the various embodiments may have the same references and may dispose identical structural, dimensional, and material properties.
For the sake of clarity, only the operations and elements that are useful for an understanding of the embodiments described herein have been illustrated and described in detail. In particular, the design of processing devices is well known to the person skilled in the art and certain elements have not been detailed in the following description.
Unless indicated otherwise, when reference is made to two elements connected together, this signifies a direct connection without any intermediate elements other than conductors, and when reference is made to two elements coupled together, this signifies that these two elements can be connected or they can be coupled via one or more other elements.
In the following disclosure, unless indicated otherwise, when reference is made to absolute positional qualifiers, such as the terms “front”, “back”, “top”, “bottom”, “left”, “right”, etc., or to relative positional qualifiers, such as the terms “above”, “below”, “higher”, “lower”, etc., or to qualifiers of orientation, such as “horizontal”, “vertical”, etc., reference is made to the orientation shown in the figures, or to a . . . as orientated during normal use.
Unless specified otherwise, the expressions “around”, “approximately”, “substantially” and “in the order of” signify within 10%, and preferably within 5%.
The electronic device 100 is, for example, an electronic board such as a microcircuit board, hardware for computer use, a microprocessor circuit, etc.
The processing device 102 comprises, for example, a non-volatile memory 104 (NV MEM), such as a flash memory and a monotonic counter 106 (MONOTONIC COUNTER).
Monotonic counters are known in the art. An example of such a counter is described in the publication “Virtual Monotonic Counters and Count-Limited Objects using a TPM without a Trusted OS” by L. F. G. Sarmenta, M. Van Dijk, C. W. O'Donnell, J. Rhodes and S. Devadas, and in particular in part 3 of this paper. This paper is incorporated herein by references in its entirety and describes embodiments of counters implemented in hardware and/or software form. The monotonic counter 106 is for example implemented in hardware form by a digital circuit, such as an Application Specific Integrated Circuit (ASIC). The monotonic counter is configured to maintain a count value, accessible at an output of the counter. Following an increment instruction, the monotonic counter increases its count value by one or more units but, following each increment, the operation is not reversible. Indeed, the monotonic counter is configured so that its count value never decreases. Moreover, between two increments, the count value is protected against any modification, so that it cannot be erased nor changed. Only the increment instruction allows the current value to be replaced by a new value that is higher than the current value.
The monotonic counter 106 is configured so that no instruction, other than a reset to zero of the processing device, will allow the return to the previous value once the increment instruction is executed. In the case where the count value is stored in a volatile manner, each time the processing device is turned off, the count value is lost and each time the device is booted, the monotonic counter generates an initial count value again. In the case where the count value is stored in a non-volatile storage element, upon each reboot, an initial count value is, for example, written back to the non-volatile storage element of the monotonic counter.
The processing device 102 further comprises a generic processor no (CPU). For example, the generic processor no is coupled via a bus 120 to the monotonic counter 106 as well as to a RAM (random access memory) 112 and to the non-volatile memory 104. The memory 112 and/or the memory 104 store, for example, instructions for controlling the processor no. The generic processor no is further coupled via the bus 120 to a cryptographic processor 114 (CRYPTO) as well as a random number generator 118 (RN GENERATOR). The cryptographic processor 114 receives, via the bus 120, encrypted data and returns the decrypted data and/or receives, via the bus 120, unencrypted data and returns the encrypted data. In one example, the random number generator 118 is a pseudo random-number generator, such as a linear congruential generator, using recursive arithmetic sequences having a disordered behavior and having a period long enough to appear random. The quality of such a generator depends entirely on the arithmetic parameters used. In another example, the generator 118 is a true random number generator using a physical random source based, for example, on the intrinsic properties of a material on which it is implanted.
The processing device 102 further comprises a debug access circuit 116 (DEBUG INTERFACE) connected to the bus 120. For example, the circuit 116 is part of, or connected to, a Joint Test Action Group (JTAG) debug port or Serial Wire Debug Port (SW-DP) or other type of debug access circuit for the device 102. The circuit 116 allows a user to connect a compatible interface (not represented) to the device 102 in order to request execution of a system debugging procedure, for example in the event of malfunctions. According to the embodiments described herein, the circuit 116 is further configured to limit access to the debugging procedure based on the count value generated by the monotonic counter 106. For example, the monotonic counter 106 is controlled to increment its count value during operation of the device 102, for example during the boot phase of the device 102. Thus, it is possible to limit time periods during which the debugging operations are accessible.
The non-volatile memory 104 comprises, for example, an access control circuit 108 (ACCESS CONTROL) connected to the output of the monotonic counter 106. The memory 104 stores, for example, a plurality of data sets, for example boot codes and/or encryption keys, which are associated with a plurality of isolation levels, TIL (temporal isolation level). In the example of
The TIL level of isolation depends on the count value generated by the monotonic counter 106. In the example of
The access control mechanism implemented by the circuit 108 can be implemented in several ways. In a first example, when the circuit 108 receives a read request, either by the device 102 itself or through the debug access circuit 116, associated with one or more addresses in the memory 104, it is configured to compare that/those address(es) to the address ranges associated with the areas 122, 124, and 126 of the memory 104. If it is an address in an area associated with a TIL value lower than the current value, the access control circuit 108 is for example configured to block the read operation. In a second example, the circuit 108 is configured to disable a read circuit of any area 122, 124, and 126 of the memory 104 associated with a TIL value lower than the current value. For example, one or more logic gates, such as OR gates or AND gates, are coupled into the output path of each area 122, 124, and 126 of the memory 104 and also receive a generated activation signal based on the TIL value to selectively disable each output path.
The fact that the TIL value cannot be decremented during the period of operation of the device 100 allows for the protection of the data sets, with the access control circuit 108 preventing them from being read based on a TIL value greater than the value associated with them.
In some embodiments, one or more of the data sets and associated isolation levels are reserved for separate entities in the chain from manufacturer to end user. For example, an intermediate entity between the manufacturer of the processing device and the end user of the electronic device 100 may be required to store data, such as boot codes, that are specific to the use of the device 100. In this case, one or more of the “lowest” data sets, such as those associated with the isolation level 0, are reserved for the manufacturer of the processing device 102, for example, and other sets are reserved for the intermediate entity.
However, when the device 102 presents one or more malfunctions, the manufacturer, the intermediate entity, or another entity, external to the manufacturer as well as the intermediate entity, may perform a debugging procedure. It is then desirable that the data sets associated with the TIL values reserved for the manufacturer and/or the intermediate entity are not accessible during this procedure.
In a step 201 (CLOSED STATE), the processing device has just been booted, and automatically goes into a so-called closed (or secure) state. In the closed state, access to debugging procedures is not permitted. The contents of the memories of the device 102, and in particular the contents of the areas 122, 124, and 126 of the non-volatile memory 104, are therefore rendered inaccessible from the outside by the debug access circuit 116. In other words, the execution of tests of the processing device 102 as well as a debugging protocol is not possible when the processing device 102 is in the closed state and this is true regardless of the current TIL value.
In a step 203 (DEBUG REQUEST), subsequent to step 201, an external debugging device is connected to the debug access circuit 116 to activate a debug mode of the device 102. For example, the external device sends a debug mode access request to the debug access circuit 116. Step 203 also comprises, for example, an authentication procedure initiated by the processing device 102. For example, this authentication procedure is based on the debug access circuit 116 verifying a digital signature generated by the external device, and provided with, or separately from, the debug mode access request.
In a step 205 (SUCCESS?), subsequent to step 203, the authentication procedure ends. Either the authentication procedure succeeds (Y branch) or it fails (N branch). In the case where the procedure fails, the method ends with a step 207 (ERROR SIGNAL) in which the processing device alerts the initiator of the authentication procedure that it has failed. For example this alert is an error message, or a beep.
In the event that the authentication procedure is successful, the method continues, in some cases, to a step 209 (DEFINE OR RETRIEVE TIL REF FOR DEBUG) in which one or more reference TIL values are, for example, defined or retrieved. The reference values indicate TIL values that are compatible with the debug mode access. For example, one or more reference values may define one or more TIL values for which the debug mode access is prevented, or one or more TIL values for which the debug mode access is permitted. In some cases, the reference TIL value is a threshold at or above which the debug mode access is permitted. In the following, the case in which a single reference TIL value indicating the threshold of the TIL value above which access to the debug mode is permitted is considered.
In some cases, the one or more reference TIL values are invariant and are stored in a memory of the device 102. In another example, the one or more reference TIL values may be set by a request from the external device.
In a step 211 (CURRENT TIL≥TIL REF?), subsequent to step 209, the current TIL value, corresponding to, for example, the count value of the monotonic counter, is compared to one or more reference TIL values, which were, for example, defined or retrieved in step 209. If the current TIL value is not greater than or equal to the reference TIL value (N branch), in other words, if the current TIL value is strictly less than the reference TIL value, the method is on hold for a step 213 (WAIT UNTIL CURRENT TIL=TIL REF) waiting for the monotonic counter 106 to be incremented and for the current TIL value to equal the reference TIL value. For example, in a boot of the processing device 102 in which the areas 122, 124, and 126 contain boot codes and in which the monotonic counter is incremented after the codes in each area are executed, the step 213 includes waiting, for example, for at least some steps in the boot method to complete.
Following the step 213, or if in the step 211 the current TIL value is at least equal to the reference TIL value (Y branch), the method terminates in a step 215 (OPEN STATE AND DEBUG) in which the circuit transitions from the closed state to an open state, allowing for the execution of tests and debugging protocols of the processing device 102 and the debugging procedure executes.
As an example in relation to
The life of the processing device 102 begins in a fabrication step 301 (FABRICATION). During step 301, manufacturer-specific data, such as boot codes and encryption keys, are stored in the non-volatile memory 104 of the device 102. This data is confidential and the manufacturer of the device 102 does not want this data to be accessible by a third party. In the example of
The level value TIL 0 corresponds, for example, to the initial count value generated by the monotonic counter 106 when the device 102 is first booted.
Following storage of the confidential data and in a step 303 (CLOSE DEBUG), the debug access is closed. This implies that the debugging access is preceded by an authentication procedure for debugging.
For example, the device 102 is customized in a step 305 (PERSONALIZATION). For example, at this stage in the life of the device 102, the device 102 is in the hands of an intermediate entity. The intermediate entity is, for example, a reseller that will customize the device 102 to fit the operation of the electronic device 100. The intermediate entity will, for example, store other data, for example, other boot codes and other encryption keys, in another portion of the memory 104. In an example relative to
In one example, following the step 305, the intermediate entity initiates a debugging procedure in a step 307 (DEBUG AUTHENTIFICATION). This procedure is initiated, for example, to verify proper operation of the device 102 following the customization.
For example, since the level value TIL 0 was closed in step 305, the reference value for this procedure is equal to 1. The flow of the debugging procedure when the reference value is equal to 1 is represented by the continuous thin arrow sequence. Once authentication for debugging is successful and the device 102 is opened for debugging, the device 102 is debugged in a step 309 (DEBUG ON TIL 1). In this step, the data associated with the level value TIL 0 is inaccessible in contrast to the data stored by, for example, the intermediate entity and associated with the level values TIL 1 and TIL 2. Once debugged, customization of the device 102 in step 305 may continue.
Following customization of the device 102 and in a step 311 (CONSTRAIN DEBUG), the reference TIL value is programmed to allow access to the debug mode only for TIL values greater than a reference value, for example the value 2 or 3. The memory areas associated with TIL values below the reference value are therefore locked, particularly with respect to debugging procedures. In particular, following the step 311, debugging of the “root of trust” type, associated for example with the level TIL 0 and/or 1, are no longer allowed.
Following the step 311, the device 102 is for example acquired and used in a step 313 (USE) by its end user.
During use, by the end user, the device 102 may be required to undergo a debugging procedure again, initiated by, for example, the manufacturer or another entity. In this case, the debugging procedure in step 307 (DEBUG AUTHENTIFICATION) is initiated. The flow of this debugging procedure is represented by the dotted arrow sequence.
Once authentication for debugging is successful and the device 102 is opened for debugging, the device 102 is debugged in a step 315 (DEBUG ON TIL 3). For example, because debugging is performed after step 311, in which debug access for a TIL value of 1 or less was locked, the reference TIL value identified by the device is greater than 1. In the example of
In the debugging authentication step 307, a computing device 300 (COMPUTER) is, for example, connected to the device 102 via the debugging access circuit 116. The debugging authentication procedure is, for example, implemented by a digital signature protocol based on asymmetric cryptography. For example, the initiator of the debugging procedure has a card 302 (MODULE) containing a private key and connected to the computing device 300. For example, the random number generator 118 of the device 102 in
This authentication protocol is a non-limiting example. Other authentication protocols may be implemented.
The
In the example of
During a first boot step 410, the processing device illustrated at the top of
For example, once the first code CODE0 is executed, the generic processor 110 controls a first increment of the current count value by the monotonic counter 106. For example, the first code comprises an instruction requesting the increment of the counter. This instruction is, for example, transmitted to a control register (not illustrated) of the monotonic counter 106.
After this first increment, the current count value of the monotonic counter 106 is, for example, equal to 1, corresponding to a second boot step 411. The access control circuit 108 receives the new current count value, and is configured to prevent, based on this count value greater than 0, any access to the first code as well as to the first data that is associated with isolation level 0. In other words, the memory areas 122 and 400 are locked based on any count value strictly greater than 0.
The isolation level 1 is associated with a second code (CODE1) contained in the area 124 as well as with the second data (KEY1) contained in the area 402. According to one embodiment, a third code (CODE2), for example associated with the isolation level 2 and contained in the area 126, is accessible for reading based on the current count value being equal to 1.
For example, once the second code CODE1 is executed, the generic processor no controls a second increment of the current count value by the monotonic counter 106. For example, after this second increment, the current count value of the monotonic counter 106 is equal to 2, corresponding to a third boot step 412. The isolation level 2 is associated with the third code CODE2 as well as the third data (KEY2). The access control circuit 108 receives the new count value, and is configured to prevent, based on this count value greater than 1, any access to the first and second codes as well as the first and second data that are associated with the isolation levels less than or equal to 1.
According to one embodiment, when the last boot code is executed, for example the third boot code, the generic processor no controls a third increment of the current count value by the monotonic counter. The access control circuit 108 then locks out all access to the first, second, and third boot codes and the first, second, and third data.
According to another embodiment, when the last boot code is executed, for example the third boot code, the current count value is not incremented by the monotonic counter 106 and access to the third boot code as well as the third data remains allowed by the access control circuit 108.
In a step 501 (LAUNCH BOOT SEQUENCE) the processing device 102 is booted. In one example, this is the first boot of the device 102 after its manufacture. In another example, it is a boot performed by an intermediate entity between the manufacturer of the device 102 and its end user. In yet another example, it is a so-called operational boot of the electronic device 100 performed by the end user.
In a step 503 (INITIALIZE COUNTER), subsequent to step 501, the monotonic counter is initialized to an initial value, being a natural number. In the example in which the count value is stored in a volatile manner, each boot of the processing device causes the count value to be initialized, for example to 0 or 1. In another example in which the count value is stored in a non-volatile storage element, each boot of the processing device causes the current count value to be replaced with the initial count value, for example equal to 0 or 1.
In some embodiments, the initial count value generated following a boot, may vary depending on the state, or context, of the processing device 102. For example, one or more count values corresponding to one or more isolation levels reserved for an initial set-up phase of the device 102, comprising, for example, the installation of firmware. The data and/or codes associated with these isolation levels are, for example, used for this initial set-up.
For example, following manufacture, the processing device 102 has the context “blank” and the initial count value is equal to a value reserved for setting-up, such as 0. Once the set-up is complete, the context of the device becomes, for example, “set-up complete.” With this new context, booting the device 102, for example by an intermediate entity between the manufacturer and the end user and/or by the end user, will then trigger a count value greater than the reserved count value, and for example equal to 1. The boot code(s), as well as the sensitive data, associated with the isolation level corresponding to the reserved count value will, therefore, be inaccessible.
For example, the context of the device is detected by the presence of a voltage on a start-up pin of the device, this voltage being applied, for example, by adding a jumper between the start-up pin and another pin at a supply voltage. Additionally or alternatively, the context of the device is detected by the value of one or more bits stored in a non-volatile, protected manner in the memory 104, or in another memory.
In one example, the generic processor no is arranged to detect the context of the device 102 upon booting the device 102, and to configure the initial count value of the monotonic counter 106 accordingly. In another example, the monotonic counter 106 is arranged to detect the context of the device 102 itself and to configure its initial count value itself, upon booting the device 102.
In a step 505 (READ AND EXECUTE CODE ON LEVEL i), subsequent to step 503, the data and boot codes associated with the isolation level i are read by the generic processor 110 and the boot codes associated with the isolation level i are executed. Once the codes of level i are executed, the generic processor no compares, in a step 507 (i=N?) the count value i to the value N, where N is the count value associated with the last step in the boot sequence, in other words, the boot codes of isolation level N are the last to be executed according to an embodiment. For example, in the example of
In the event that, as a result of the comparison step 507, the count value is equal to N (Y branch), the method concludes with a step 511 (END OF BOOT) in which the boot of the processing device ends. According to one embodiment, the current count value remains equal to N following the step 511. According to another embodiment, the count value is incremented in the step 511, and the current count value becomes equal to N+1. In this second embodiment, the access control circuit 108 is configured to prevent access to all boot codes based on this count value.
Steps 601 and 603 are similar to steps 501 and 503 of
In a step 605 (ACCESS CODE ON LEVELS i AND i+1 EXECUTE CODE ON LEVEL i), subsequent to step 603, the data and boot codes associated with the isolation levels i+1 are accessed by the generic processor no and the boot code(s) associated with the isolation level i are executed.
In one example, the data or codes associated with the isolation level i contain one or more encryption keys, encrypted or unencrypted, which will be used when executing one or more codes associated with isolation level i+1. Thus, a write access is for example authorized on the memory area(s) associated with the isolation level i+1 in order to provision the keys to the codes associated with the isolation level i+1.
In another example, the codes associated with isolation level i contain instructions to verify the integrity of the data and/or codes associated with isolation level i+1. Thus, read access to the memory area(s) associated with isolation level i+1 is permitted in order to perform this verification.
In a step 607 (i=i+1), subsequent to step 605, the count value is incremented. For example, the count value increases from i to i+1. In other examples, the increment increases i by several units.
In a step 609 (i=N?) the generic processor no compares the count value i to the value N, where N is defined as described, relative to step 507 of
In the event that in the comparison step 609 the count value is equal to N (Y branch), the method continues to a step 613 (EXECUTE CODE ON LEVEL N) in which the boot code(s) associated with the isolation level N are executed.
The boot of the processing device ends with a step 615 (END OF BOOT), which is similar to the step 511 of
The method whose implementation is shown in
One advantage of the described embodiments is that sensitive data in terms of confidentiality, are protected in a significant way by the use of a monotonic counter and in particular to the lock access during a debugging procedure.
Another advantage of the described embodiments is that they are easily adaptable to several boot architectures.
Various embodiments and variants have been described. Those skilled in the art will understand that certain features of these embodiments can be combined and other variants will readily occur to those skilled in the art. In particular, different types of processors may be used. In addition, the number of isolation levels may vary.
Finally, the practical implementation of the embodiments and variants described herein is within the capabilities of those skilled in the art based on the functional description provided hereinabove. In particular, authentication protocols for debugging other than an asymmetric cryptography protocol can be implemented.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2103315 | Mar 2021 | FR | national |
