System on a chip comprising a processor having a debugging function and a self-protection circuit, and corresponding self-protection method.

Abstract

The system-on-a-chip (SoC) includes a processor (CPU) with program debugging capabilities, configured to have debugging parameters determined by debug control signals (dbgen, niden, spiden, spniden). A tamper protection circuit (TAMP) is configured to detect states indicative of debug access authorization on these debug control signals. Figure 1 for abbreviations

Description

Title of the invention: System on chip comprising a processor having a debugging function and a self-protection circuit, and corresponding self-protection method.

[0001] Embodiments and implementation methods relate to systems on chip, i.e. integrated circuits incorporating a complete system such as microcontrollers, and more particularly to methods and means of self-protection against reverse engineering attacks.

[0002] In reverse engineering processes, attacks are defined as implementations aimed, for example, at accessing sensitive or secret information, such as encryption data or program code.

[0003] In this regard there are techniques directing attacks on a debugging function of a central computing unit (“processor”).

[0004] Indeed, if access to the debugging functionality is allowed, then it is possible to read at an address by a debug command, typically via a dedicated access port "DAP" (for "Debug Access Port" usually in English).

[0005] The "DAP" access port interface is classically capable of filtering debug requests, by completely closing access to the processor.

[0006] For example, the owner of the system-on-chip, usually called the "original equipment manufacturer" or "OEM" (for "Original Equipment Manufacturer"), benefits from an initial "completely open" state of the system, where access to the debugging functionality is fully permitted.

[0007] As software development progresses, access to the debugging functionality will be progressively restricted, until it reaches a completely closed state.

[0008] In particular, the succession of states may include the "fully open" state where the application is not yet developed; then a "provisioning" state allowing secrets (keys, secret, ...) to be written into the system; then a "provisioned" state, when the provisioning phase has just been completed; then for example a "closed trust zone" state when the development of the "secure" application is finished; then the "fully closed" state where the development of the final application is finished.

[0009] Typically, between, for example, the "closed trust zone" state and the "completely closed" state, another client may be in charge of coding the insecure application, for example the "rich" operating system (usually "Rich"). Operating System (in English), and need to benefit from the processor's debugging features.

[0010] And, in this context, there is a vulnerability, for example by a hardware attack of the type laser pulse fault injection, on debug isolation control signals.

[0011] The debug isolation control signals allow, for example to allow or prevent access to information with secure access rights during debugging. In addition, debug isolation control signals can also determine, for example, whether invasive debugging (allowing reading variables, introducing breakpoints, etc.) or non-invasive debugging (communicating only an execution trace) is permitted.

[0012] Indeed, in the "closed trust zone" state, for example, access to secure zones should be impossible, however, by forcing a hardware attack on, for example, the debug isolation control signal allowing invasive access to the secure level, secret information can be obtained via the debugging functionality.

[0013] There is therefore a need to guard against this vulnerability.

[0014] In this regard, according to one aspect, a system-on-chip is proposed comprising a processor having a program debugging functionality, configured to have debugging parameters determined by debugging control signals, in which a self-protection circuit is configured to detect states representative of debugging access authorization, on said debugging control signals.

[0015] Therefore, if at least one of the debug control signals is altered, for example forced by a hardware attack, into a state that grants access (potentially any access authorization), then this is detected by the self-protection circuit, even though the system theoretically allows this state of the debug control signal. The self-protection circuit thus allows the system to "know" that access authorization is being granted by said signal, thereby enabling a decision to be made regarding the legitimacy of this command. In case of illegitimacy, system protection measures can then be taken.

[0016] According to one embodiment in this regard, a countermeasure means is configured to activate system protection measures, in the event of detection made by the self-protection circuit and depending on a system access right state.

[0017] For example, the countermeasure is implemented in software within a secure environment that has information on the system's access rights status, for example, within a means designed to manage system-on-chip access rights. For example, the protection measures may include a system-on-a-chip shutdown, an erasure of sensitive data, or even a self-destruction of the system.

[0018] According to one embodiment, the self-protection circuit is configured to detect a state representative of an authorization of access to debugging at a secure level and / or of an authorization of access to debugging at an insecure level, on at least one debugging control signal setting the respective access rights.

[0019] According to one embodiment, the self-protection circuit is configured to detect a state representative of an invasive access authorization for debugging and / or a non-invasive access authorization for debugging, on at least one debugging control signal setting the respective invasive degree.

[0020] According to one embodiment, the processor being configured to provide evolving system state information, the self-protection circuit is configured to perform said detection on the debugging control signals in all system states except in an initial "fully open" state.

[0021] According to another aspect, a self-protection method is proposed for a system-on-chip comprising a processor having a program debugging function, debugging control signals determining debugging parameters of the processor, the self-protection method comprising a detection of states representative of an authorization of access to debugging, on said debugging control signals.

[0022] According to one embodiment, the method includes detecting a state representative of an authorization to debug access at a secure level and / or an authorization to debug access at an insecure level, on at least one debug control signal setting the respective access rights.

[0023] According to one embodiment, the method includes detecting a state representative of an invasive access authorization for debugging and / or a non-invasive access authorization for debugging, on at least one debugging control signal setting the respective invasive degree.

[0024] According to one embodiment, said detection on the debugging control signals is done in all system states except in an initial "completely open" state, the evolving system state information being provided by the processor.

[0025] According to one implementation method, system protection measures are activated in the event of detection of at least one state representative of an access authorization for debugging, and depending on a system access right state.

[0026] Other advantages and features of the invention will become apparent upon examination of the detailed description of embodiment and implementation, which is in no way limiting, and the accompanying drawings, in which the figures:

[0027] [Fig.l] ;

[0028] [Fig.2] illustrate embodiments and implementations of the invention.

[0029] Figure 1 illustrates an example of a system-on-a-chip (SoC), comprising a unit CPU, commonly called a processor, is a central computing unit capable of executing software code, and in particular according to a debugging function.

[0030] In this regard, the system includes a dedicated DAP debugging access port; as well as a MEM memory, which can for example contain the program code executed by the processor, and a TAMP self-protection circuit.

[0031] A third-party DBGGR system, called a "debugger," can access the CPU to control the debugging implementation via the DAP debug access port. The third-party DBGGR debugger system could, for example, be a desktop computer on which software code is developed by a programmer and used to test the code implemented by the system-on-a-chip (SoC).

[0032] The DAP debug access port includes an input interface, or a DP debug port, following for example the JTAG or SWD protocol.

[0033] The abbreviation JTAG, from the English name "Joint Test Action Group", refers to the IEEE 1149.1 standard entitled "Standard Test Access Port and Boundary-Scan Architecture" (i.e., in French, literally, "Joint Action Group on Testing" of the standard "Test Access Port and Boundary-Scan Architecture").

[0034] The JTAG interface is used in particular for intra-circuit debugging, allowing in particular direct access to the inside of the processor, such as by breakpoints, reading and writing of internal registers or internal and external memories.

[0035] The abbreviation SWD, from the English terms "Serial Wire Debug" (or in French "débugging in serial connection"), designates a debugging technique equivalent to JTAG and uses the same connector interface.

[0036] The DAP debug access port includes an output interface, or an AP integrated circuit bus access port, accessing the CPU processor via an integrated circuit bus, for example following an AHB protocol of the "Advanced High-performance Bus" type.

[0037] For example, a first AP_EN isolation signal is provided in the DAP access port to determine whether or not to allow the transmission of debug requests from the DP input interface to the DA output interface, and thus in particular by completely closing access to the CPU processor.

[0038] Indeed, as software development progresses, access to the debugging functionality will be progressively restricted, until a completely closed state where it is no longer possible to exploit the debugging functionality of the CPU processor.

[0039] Thus, on the one hand, in order to guard against a hardware attack capable of forcing the state of this first isolation signal in order to reopen access to the debugging functionality, it is possible to plan to monitor the state of the first isolation signal, by means of the TAMP self-protection circuit.

[0040] A hardware attack capable of forcing the state of such a signal can, for example, be carried out using a laser pulse fault injection technique. Other techniques capable of forcing the state of a signal may exist.

[0041] Thus, when the monitored signal is illegitimately placed in a state allowing access to the debugging functionality, the self-protection circuit detects it, and the system can be configured to trigger defensive countermeasures in a conditional manner on this detection.

[0042] In addition, on the other hand, there are debug isolation control signals, intended to allow or not allow the CPU processor to access information having a secure, or insecure, access right during debugging.

[0043] In other words, there is at least one debugging control signal setting access rights, the state of which is representative of an authorization to debug access at a secure level and / or an authorization to debug access at an insecure level.

[0044] Also, there are debug isolation control signals, intended to allow or not allow the CPU processor to give so-called "invasive" access to debugging, or so-called "non-invasive" access to debugging.

[0045] In other words, there is at least one debugging control signal setting the invasive degree, the state of which is representative of an invasive access authorization for debugging and / or a non-invasive access authorization for debugging.

[0046] Invasive debugging allows reading and writing of variables in system registers and memories, introduction of breakpoints in the program, etc.; whereas non-invasive debugging only allows communication of a trace of program execution.

[0047] In practice, the following four debugging control signals can be used to configure access rights and the degree of invasiveness of the debugging: - the dbgen command signal, the first state of which, for example the state "true" or "1", commands an invasive debugging authorization of content with an insecure access right; - the niden command signal, the first state of which, for example the state "true" or "1", commands a non-invasive debugging authorization of content having an insecure access right; - the spiden command signal, the first state of which, for example the state "true" or "1", commands an authorization for invasive debugging of content having a secure access right; - the spniden command signal, the first state of which, for example the state "true" or "1", commands a non-invasive debugging authorization of content having an insecure access right.

[0048] The self-protection circuit is thus configured to detect states representative of an access authorization for debugging, on said debugging control signals determining the debugging parameters implemented by the processor.

[0049] Therefore, if at least one of the debugging control signals dbgen, niden, spiden, spniden is altered, i.e. for example forced by a hardware attack, and placed in a state commanding authorization of an access, then this is detected by the TAMP self-protection circuit.

[0050] It may be advantageous to provide that all access authorizations, regardless of the type of access (secure right or invasive degree) are detected by the TAMP self-protection circuit.

[0051] It may also be advantageous to provide for said detection in all states of the system, except in an initial "completely open" state; the processor being configured to provide an evolving data representative of the state of the system.

[0052] In the advantageous example illustrated by [Fig. 1], the debugging control signals setting the "secure" access rights spiden, spniden, and the debugging control signals setting the "unsecure" access rights dbgen, niden have been grouped together to form two or three detection sources:

[0053] Detection of an unsafe debug opening based on dbgen and niden signals: When unsafe debugging is open (dbgen=l OR niden=l), an event is detected.

[0054] Detection of an opening of the secure debug based on the spiden and spniden signals: When the secure debug is open (spiden=l OR spniden=l), an event is detected.

[0055] Optionally, detection of an opening of the AP_EN debug access port. When the access port is open, an event is detected.

[0056] In addition, the detections of opening the unsecured and secure debugging are cumulatively conditioned "AND" by the condition that the system is not in the fully open PrdSt^OPN state.

[0057] Logic gates offering the condition "OR" are designated by the reference OR, and the logic gate offering the condition "AND" is designated by the reference AND.

[0058] When an event is detected, an interrupt can be triggered and all sensitive data of the SOC system (present in the MEM memory or in other circuits of the SOC system) are erased.

[0059] Thus, the TAMP self-protection circuit allows the system to "know" that an access authorization is triggered by said signal, enabling it to decide on the legitimacy of this command. Indeed, the system allows for normal use in which the debugging control signals are used to authorize the respective accesses.

[0060] A trusted entity may be configured to make said decision regarding the legitimacy or illegitimacy of the detected debug command signal state.

[0061] For example, the trusted entity can be implemented in software in a secure CPU processor environment, and for example in an environment having information on the system's access rights status, for example integrated into a means of managing system-on-chip access rights.

[0062] For example, the trusted entity is able to activate system protection measures, such as shutting down the system-on-chip, erasing sensitive data, or even self-destructing the system; as a result of detection by the self-protection circuit and with knowledge of a system access right state.

[0063] We now refer to [Fig.2].

[0064] Fig. 2 functionally illustrates a self-protection method 200, for example implemented in the system-on-chip SOC described previously in relation to Fig. 1.

[0065] In a step 202, debug control signals (dbgen; niden; spiden; spniden) have logic states, for example "0" or "1", to determine debug parameters.

[0066] The logic states of the debugging control signals (dbgen; niden; spiden; spniden) can be generated in the normal operation of the system or by corruption of the system by means of a physical attack.

[0067] For example, the state "1" commands an authorization of access (also called "opening") while the state "0" commands a restriction or prohibition of access (also called "closing").

[0068] Optionally, a state of the PrdSt system is communicated in step 202.

[0069] In an optional step 203, a logical test "NOT(PrdSt=OPN)" allows verification that the system is not in the fully open state.

[0070] In a step 204, a detection of states representative of an authorization of debug access is made on said debug control signals (dbgen; niden; spiden; spniden), for example by a logical test "dbgen OR niden OR spiden OR spniden = 1" verifying that at least one of said signals is in the state "1".

[0071] Alternatively (see [Fig.1]), the method 200 includes in step 204 a detection of a state representative of an authorization of access to debugging at a secure level and / or of an authorization of access to debugging at an insecure level, on at least one debugging control signal setting the respective access rights.

[0072] For this purpose, two parallel logical tests can be provided, "dbgen OR niden = 1", verifying on the one hand that at least one of said signals commands an opening of unsecured debugging; and "spiden OR spniden = 1", verifying on the one hand that at least one of said signals commands an opening of secure debugging.

[0073] In another alternative (not shown), process 200 comprises at step 204 detection of a state representative of an invasive access authorization for debugging and / or a non-invasive access authorization for debugging, on at least one debugging control signal setting the respective invasive degree.

[0074] For this purpose, two parallel logic tests can be provided, "dbgen OR spiden = 1", verifying on the one hand that at least one of said signals commands an opening of intrusive debugging; and "niden OR spniden = 1" verifying on the one hand that at least one of said signals commands an opening of non-intrusive debugging.

[0075] In a step 206, a FLAG is recorded, for example in a register, to communicate that a detection of states representative of an authorization of access to debugging is made on said debugging control signals (dbgen; niden; spiden; spniden).

[0076] In an optional step 207, CNTRMES protection measures of the system are activated in the event of detection of at least one state representative of an access authorization of the debugging, and according to a state of access right of the system.

[0077] The system access rights state is typically known by an access rights management means, for example implemented in software by a trusted entity implemented in a secure CPU processor environment.

[0078] For example, system protection measures may include system-on-chip shutdown, erasure of sensitive data, system self-destruction.

Claims

Demands

1. System on chip (SOC) comprising a processor (CPU) having a program debugging capability, configured to have debugging parameters determined by debug control signals (dbgen, niden, spiden, spniden), wherein a self-protection circuit (TAMP) is configured to detect states representative of debug access authorization, on said debug control signals.

2. System on chip according to claim 1, wherein the self-protection circuit (TAMP) is configured to detect a state representative of debug access authorization at a secure level and / or debug access authorization at an insecure level, on at least one debug control signal setting the respective access rights (spiden, spniden; dbgen, niden).

3. System on chip according to any one of claims 1 or 2, wherein the self-protection circuit (TAMP) is configured to detect a state representative of an invasive debug access authorization and / or a non-invasive debug access authorization, on at least one debug control signal setting the respective invasive degree (dbgen, spiden; niden, spniden).

4. System-on-chip according to any one of claims 1 to 3, the CPU processor being configured to provide evolving system state information (PrdSt), wherein the self-protection circuit is configured to perform said detection on the debug control signals in all system states except in an initial "fully open" state (PrdSt^OPN).

5. System on chip according to any one of claims 1 to 4, wherein a trusted entity (CPU) is configured to activate system protection measures, in case of detection made by the self-protection circuit (TAMP) and depending on a system access right state.

6. A method for self-protecting a system-on-a-chip (SoC) comprising a processor (CPU) having a program debugging function, debugging control signals (dbgen, niden, spiden, spniden) determining processor debugging parameters (202), the self-protection method (200) comprising a detection (204) of states representative of an authorization of access to debugging, on said debugging control signals.

7. Method according to claim 6, comprising a detection (204) of a state representative of an authorization of access to debugging at a secure level and / or of an authorization of access to debugging at an insecure level, on at least one debugging control signal setting the respective access rights (spiden, spniden; dbgen, niden).

8. A method according to any one of claims 6 or 7, comprising a detection (204) of a state representative of an invasive debug access authorization and / or a non-invasive debug access authorization, on at least one debug control signal setting the respective invasive degree (dbgen, spiden; niden, spniden).

9. A method according to any one of claims 6 to 8, wherein said detection on the debugging control signals is done in all system states except in an initial "completely open" state (PrdSt^OPN), the evolving system state information being provided by the processor (CPU).

10. A method according to any one of claims 6 to 9, wherein system protection measures are activated (207) upon detection of at least one state representative of debug access authorization (206), and depending on a system access right state.

Images