Security system

Abstract

The present invention provides a security system configured on a chip to be protected, the system including fault injection detection subsystems configured on the chip, each fault injection detection subsystem having a plurality of real-time selectable sensitivity levels and including at least one hardware fault injection detector circuit disposed on the chip and / or sensitivity level control logic coupled with the hardware fault injection detector circuit, deployable on the chip and operable in real-time to transition the fault injection detection subsystem from a current sensitivity level of the plurality of selectable sensitivity levels to a next sensitivity level of the plurality of selectable sensitivity levels, for example by generating a sensitivity control signal (also referred to as a sensitivity level selection) and / or sending the sensitivity control signal to at least one hardware fault injection detector circuit in the fault injection detection subsystem. The fault injection countermeasure circuit is operated to protect the processor from fault injection attacks dynamically depending on the execution flow of the processor core.

Description

TECHNICAL FIELD

[0001] The present invention relates to security of devices, and in particular to detecting fault injection attacks. BACKGROUND

[0002] Commonly owned U.S. Patent 9,523,736 and its prior art describe prior art methods for identifying fault injection attempts.

[0003] Sensitivity level adjustable countermeasures can be known glitch detectors, which are known and described, for example, at the following http www link: inria.fr / detectors / voltage-glitch-detector.aspx. These are described as having a "configurable detection threshold"; and the following https link: hal.inria.fr / emse-01099006 / document and "An In-depth and Black-box Characterization of the Effects of Clock Glitches on 8-bit MCUs" by Josep Balasch, Benedikt Gierlichs and Ingrid Verbauwhede, a white paper describing fault injection research, available from IEEE.

[0004] "Characterizing a CPU Fault Attack Model via Run-Time Data Analysis" by Martin S. Kelly et al, a white paper describing fault injection research, available from IEEE.

[0005] "Experimental evaluation of two software countermeasures against fault attacks" by Nicolas Moro et al, a white paper for evaluating software countermeasures, available from IEEE.

[0006] "Electromagnetic fault injection: towards a fault model on a 32-bit microcontroller" by Nicolas Moro et al, a white paper describing fault injection research, available from IEEE.

[0007] The state of the art on glitching attacks is described in "Implementing Practical Electrical Glitching Attacks" by NCC Group, November 2015, accessible through the Internet at the following httpswww link: blackhat.com / docs / eu-15 / materials / eu-15-Giller-Implementing-Electrical-Glitching-Attacks.pdf. Countermeasures in software, such as repeated instructions, are described in "Compilation of a Countermeasure against Instruction-Skip Fault Attacks" by Thierno Barry, Damien Couroussé and Bruno Robisson, available through the Internet at the following https link: hal-cea.archives-ouvertes.fr / cea-01296572 / document and in "Low-Cost Software Countermeasures Against Fault Attacks: Implementation and Performances Trade Offs" extractable through the Internet at the following http: / / euler.ecs.umass.edu / research / bpbk-WESS-2010.pdf.

[0008] There exist authentication mechanisms running based on tracing the execution flow of a CPU, such as commonly owned U.S. Patent No. 9703945.

[0009] Prior art Figure 1 Taken from "Basic Operations of the DLX Machine" by Mike McDonald and Tony Jacobs, available at the following https www link: cs.umd.edu / class / fall2001 / cmsc411 / projects / DLX / proj.html.

[0010] This article https: / / www.nuvoton.com / support / technical-support / technical-articles / TSNuvotonTechBlog-000154 / describes "Running Process Sequence Random Delays and Random Variations" both of which produce unpredictable system execution times as a countermeasure against fault injection attacks.

[0011] General glitch detectors are described in US Patent 9729988B2 entitled "Glitch detection... ", https: / / www.chipestimate.com / log.php?from=%2FInvia%2FVoltage-Glitch-Detector%2Fdatasheet%2Fip%2F30894&logerr=1, https: / / www.design-reuse.com / sip / glitch-detector-tsmc-n5-ip-48440 / and https: / / hal.archives-ouvertes.fr / lirmm-01096047 / .

[0012] The disclosures of all publications and patent documents mentioned in the specification, and the disclosures of all publications and patent documents cited in the above-incorporated documents, are hereby incorporated by reference. The mention of any reference is not an admission that it is prior art to the present application. SUMMARY

[0013] Fault injection is a widely used and very effective (from a hacker's perspective) technique. Certain embodiments seek to provide improved protection against fault injection attacks or instruction-skip fault attacks.

[0014] The measure of a security system is the false positive rate (also known as false alarm rate) and the level of security they provide. Certain embodiments of the present invention seek to provide a system that takes advantage of the fact that there are periods of time that are generally less risky for security, such as but not limited to periods of time that have been empirically observed to be less vulnerable to hacking, and periods of time that are more risky for security, such as but not limited to periods of time that have been empirically observed to be more vulnerable to hacking. The system then limits the times when the system is more sensitive to security threats to the second class of time periods, thereby generally reducing the system's susceptibility to false alarms, making the system more secure while at the same time not impacting the availability and usability of setting the system to have the highest sensitivity to fault injection for 100% of the time.

[0015] Certain embodiments seek to provide a fault injection detector having a dynamic, e.g., real-time, level of sensitivity that is adjusted in real-time and having a response time that is shorter than a decode-through-execution cycle of a single instruction of a CPU that is protected by the fault injection detector. Typically, the detection is continuous, rather than intermittent.

[0016] Opening and closing countermeasures, e.g., depending on whether the chip is in an active state or in a sleep state, can or can not be known in the art. Certain embodiments shown and described herein seek to adjust the level of sensitivity in real-time in order to fine-tune the tradeoff of providing attack protection in the device and the inherent tradeoff of some false positives. Typically, the control of the countermeasures is provided at a resolution of a single opcode, e.g., because a first level of sensitivity, which can be a low level of sensitivity, can be provided upon detection of a first opcode, resulting in a first tradeoff of providing a lower level of detection and suffering a lower level of false positives, while a second level of sensitivity, which can be a higher level of sensitivity, can be provided upon detection of a second opcode that is forthcoming immediately after the first opcode, resulting in a second tradeoff of providing a higher level of detection and suffering a higher level of false positives.

[0017] Certain embodiments of the invention seek to provide a security system and / or method and / or computer program product that dynamically controls a fault injection countermeasure circuit to protect a CPU from a fault injection attack in accordance with an execution flow of the CPU. For example, a CPU or processor core can be provided that, in use, generates an output indication of at least one conditional branch that is to be executed in real-time. Typically, if at least one instruction other than the conditional branch is to be executed by the processor core, responsive to the output indication of the conditional branch that is to be executed, a sensitivity level configuration module is operable to select a next level of sensitivity that is higher than at least one level of sensitivity selected by the sensitivity level configuration module.

[0018] At least the following embodiments are also provided:

[0019] Embodiment 1. A security system that dynamically controls a fault injection countermeasure circuit to protect a processor core from a fault injection attack in accordance with an execution flow of the processor core, the system comprising:

[0020] i. the processor core, in use, executes instructions and concurrently generates output indications of at least some of the instructions that are to be executed in real-time;

[0021] ii. a fault injection detector having a plurality of selectable levels of sensitivity; and

[0022] iii. a sensitivity level control module that operates in real-time,

[0023] to receive an output indication,

[0024] a sensitivity level selection logic using at least the received output indication as input to select a next sensitivity level from a plurality of selectable sensitivity levels, and

[0025] setting the fault injection detector to the next sensitivity level,

[0026] thereby providing a differential sensitivity fault injection countermeasure circuit that, when protecting a processor core from a fault injection attack, depends on the output indication of at least some instructions to avoid at least one false positive that would have occurred if the processor core protection was provided at a sensitivity level that is independent of the output indication of the at least some instructions.

[0027] Embodiment 2. The system of any of the preceding embodiments, wherein when the sensitivity level control module receives an output indication of a single instruction associated with a risk level R, the sensitivity level control module responsively selects a next sensitivity level, wherein the next sensitivity level is higher than a sensitivity level selected for at least one instruction having a risk level lower than R.

[0028] Embodiment 3. The system of any of the preceding embodiments, wherein when the sensitivity level control module receives an output indication of an individual instruction of a processor core returning from an interrupt handler, the sensitivity level control module responsively selects a next sensitivity level, the next sensitivity level being higher than a sensitivity level selected for at least one instruction other than the individual instruction.

[0029] Generally, when the CPU finishes executing an if statement, the sensitivity returns to a lower level unless the upcoming opcode indicates that the upcoming instruction to be executed by the processor core is another conditional branch or other opcode for which the sensitivity level configuration module will select a high sensitivity level. Generally, the output indication is a signal that indicates what the processor core is currently going to execute and the sensitivity level that needs to be set accordingly by the sensitivity level configuration module. When the output indication of the next or upcoming opcode occurs, the sensitivity level will again be adjusted accordingly, so it can remain the same or change, depending on whether the next opcode is the same as (or logically corresponds to, in that it is the same sensitivity level as the sensitivity level corresponding to) the previous opcode.

[0030] Embodiment 4. The system of any of the preceding embodiments, wherein when the sensitivity level control module receives an output indication of an individual instruction that determines a routine return address, the next sensitivity level selected by the sensitivity level control module responsively is higher than a sensitivity level selected for at least one instruction other than the individual instruction.

[0031] Embodiment 5. The system of any of the preceding embodiments, wherein when the sensitivity level control module receives an output indication of an individual instruction that determines a stopping condition of a loop, the sensitivity level control module responsively selects a next sensitivity level that is higher than a sensitivity level selected for at least one instruction other than the individual instruction.

[0032] Embodiment 6. The system of any of the preceding embodiments, wherein when the sensitivity level control module receives an output indication of an individual instruction that determines a processor core execution mode change, the sensitivity level control module responsively selects a next sensitivity level that is higher than a sensitivity level selected for at least one instruction other than the individual instruction.

[0033] For example, the execution mode change can include a change between a privileged mode in which program code has access to certain restricted resources (e.g., certain memory regions, certain hardware functions, or other particular resources) and a non-privileged mode in which program code does not have access to the restricted resources.

[0034] Embodiment 7. The system of any of the preceding embodiments, wherein when the sensitivity level control module receives an output indication of an individual instruction that reads data from memory, the sensitivity level control module responsively selects a next sensitivity level that is lower than a sensitivity level selected for at least one instruction other than the individual instruction.

[0035] Embodiment 8. The system of any of the preceding embodiments, wherein the processor core includes memory, and when the sensitivity level control module receives an output indication of an individual instruction that reads data from the memory into a local storage device (e.g., a cache memory or a register), the sensitivity level control module responsively selects a next sensitivity level that is lower than a sensitivity level selected for at least one instruction other than the individual instruction.

[0036] Embodiment 9. The system of any of the preceding embodiments, wherein when the sensitivity level control module receives an output indication of an individual instruction that includes a conditional branch, the sensitivity level control module responsively selects a next sensitivity level that is higher than a sensitivity level selected for at least one instruction other than the individual instruction.

[0037] It will be appreciated that a conditional branch can be associated with a high risk level because the conditional branch can be an attractive target for hackers looking for valuable targets in a given program code to attack. For example, the conditional branch can be an attractive target for hackers because the branch can direct program code flow to a first option that grants an end user confidential information, or to a second option that does not provide the confidential information if the end user is not deemed authenticated.

[0038] Embodiment 10. The system of any of the preceding embodiments, wherein the at least one output indication related to the instruction I is generated when the processor core is about to execute the instruction I, thereby providing the output indication that the instruction I will be executed before the instruction I is executed.

[0039] Embodiment 11. The system of any of the preceding embodiments, wherein the processor core comprises adapted decode logic that decodes the individual instruction fetched from the program memory at least once, thereby deriving at least one CPU internal signal that subsequently operates at least one unit of the CPU to execute the individual instruction, wherein the decode logic is further adapted to provide the output indication of the individual instruction before the at least one unit operates in response to the at least one CPU internal signal derived from the individual instruction fetched from the program memory, thereby allowing the fault injection detector to be set to the next sensitivity level before the individual instruction is executed, rather than after.

[0040] Embodiment 12. The system of any of the preceding embodiments, wherein the processor core decodes the opcode to generate a signal comprising an instruction to an execution unit of the processor core and an output indication comprising a signal output from the processor core indicating the instruction decoded from the opcode, thereby providing the sensitivity level selection logic with a preview of an instruction that the processor core has not yet executed.

[0041] Embodiment 13. The system of any of the preceding embodiments, wherein the signal output from the processor core comprises the instruction decoded from the opcode.

[0042] Embodiment 14. The system of any of the preceding embodiments, wherein the fault injection detector comprises an analog circuit having a plurality of adjustment options corresponding to the plurality of sensitivity levels, respectively.

[0043] Embodiment 15. The system of any of the preceding embodiments, wherein the processor core comprises adapted decode logic that decodes the individual instruction fetched from the program memory at least once, thereby deriving at least one CPU internal signal that subsequently operates at least one unit of the CPU to execute the individual instruction, wherein for all instructions decoded by the decode logic, the decode logic is further adapted to provide the output indication of the individual instruction before the at least one unit operates in response to the at least one CPU internal signal derived from the individual instruction fetched from the program memory, thereby ensuring that the fault injection detector is always set to each particular sensitivity level before the sensitivity level logic uses the instruction to select the particular sensitivity level, rather than after.

[0044] Embodiment 16. A security method dynamically controlling a fault injection countermeasure circuit in response to a processor core execution flow to protect the processor core from a fault injection attack, the method comprising:

[0045] i. providing a processor core, in use, executing instructions and concurrently producing, in real-time, output indications of at least some of the instructions to be executed;

[0046] ii. providing a fault injection detector having a plurality of controllable sensitivity levels; and

[0047] iii. using, in real-time, a sensitivity level control module,

[0048] receiving the output indications,

[0049] using sensitivity level selection logic taking at least the received output indications as input to select a next sensitivity level from the plurality of controllable sensitivity levels, and

[0050] setting the fault injection detector to the next sensitivity level,

[0051] thereby providing a differential sensitive fault injection countermeasure circuit when protecting the processor core from the fault injection attack, depending on the output indications of the at least some instructions, to avoid at least one false positive if the sensitivity level at which the CPU is protected is independent of the output indications of the at least some instructions.

[0052] Embodiment 17. The system according to any of the preceding embodiments and further comprising a fault injection amelioration circuit to perform at least one fault injection amelioration operation in response to detection of a fault injection by the detector.

[0053] Embodiment 18. The method according to any of the preceding embodiments, wherein the processor core comprises adapted decoding logic to decode an individual instruction fetched from a program memory at least once to derive at least one CPU internal signal that subsequently operates at least one unit of the CPU to execute the individual instruction, wherein the decoding logic is further to provide an output indication of the individual instruction prior to the at least one unit of the CPU operating in response to the at least one CPU internal signal derived from the individual instruction fetched from the program memory, to allow setting the fault injection detector to the next sensitivity level prior to, rather than after, execution of the individual instruction.

[0054] Embodiment 19. The method of any of the preceding embodiments, wherein said processor core decodes the opcode using combinational logic to produce a signal comprising an instruction to an execution unit of the processor core and an output indication comprising a signal derived from the processor core to indicate the instruction decoded from the opcode, to provide the sensitivity level selection logic with a preview of an instruction that the processor core has not yet executed.

[0055] Embodiment 20. The system of any of the preceding embodiments, wherein the processor core comprises an execution pipeline comprising a plurality of consecutive instruction stages including at least one overlap stage, wherein the sensitivity level selection logic provides the fault injection detector with an indication for selecting a sensitivity level in dependence on at least one instruction I independently associated with a highest fault detection sensitivity level of the plurality of sensitivity levels.

[0056] The overlap stage can comprise a decode stage and / or an execution stage.

[0057] Embodiment 21. The system of any of the preceding embodiments, wherein said at least one instruction I, once decoded, is prioritized over all other decoded instructions and over all other instructions to be executed, since the highest detection sensitivity level is set to start immediately after the instruction I is decoded and to end only after the instruction I is fully executed, regardless of other instructions being decoded and other instructions to be executed.

[0058] Embodiment 22. The system of any of the preceding embodiments, wherein the processor core outputs an output indication comprising which opcode is to be executed.

[0059] Embodiment 23. The system of any of the preceding embodiments, wherein said fault injection detector is operable to protect the CPU from a fault injection attack, the decode-execute cycle of an individual instruction of the CPU is T time units long, and wherein the fault injection detector has a response time shorter than T.

[0060] Embodiment 24. The system of any of the preceding embodiments, wherein the fault injection detector comprises a plurality of fault injection detector units respectively deployed at a plurality of locations of the processor core, to detect a fault injection attack at all of the plurality of locations.

[0061] Embodiment 25. The system of any of the preceding embodiments, wherein the fault injection detector issues an alert if at least one of the detector units deployed at a location L detects a fault injection attack at the location L.

[0062] Embodiment 101. A security system configured to be deployed on a chip to be protected, the system comprising:

[0063] at least one fault injection detection subsystem is disposed on the chip, each fault injection detection subsystem having a plurality of real-time selectable sensitivity levels, including:

[0064] at least one hardware fault injection detector circuit disposed on the chip,

[0065] and sensitivity level control logic coupled with the hardware fault injection detector circuit, disposed on the chip and operating in real-time to transition the fault injection detection subsystem from a current sensitivity level of the plurality of selectable sensitivity levels to a next sensitivity level of the plurality of selectable sensitivity levels by generating a sensitivity control signal (also referred to as a sensitivity level selection) and sending the sensitivity control signal to the at least one hardware fault injection detector circuit in the fault injection detection subsystem.

[0066] The fault injection detection subsystem can include any logic configured for fault injection attack detection, typically including real-time identification of an attempt to tamper with the chip circuitry and real-time alerting of the attempt in response. The location of the detector typically represents a location of the chip circuitry most likely to be attacked, and the nature of the detector typically represents a type of attack, such as glitch, temperature, or otherwise.

[0067] Embodiment 102. The system of any of the preceding embodiments, and wherein the at least one fault injection detection subsystem further comprises at least one functional module configured to be disposed on the chip to generate an output signal in real-time and send the output signal to the sensitivity level control logic to provide an indication to the sensitivity level control logic as to the next sensitivity level to be selected from the plurality of selectable sensitivity levels.

[0068] Embodiment 103. The system of any of the preceding embodiments, wherein the at least one functional module is operable to generate and send at least one output signal to the sensitivity level control logic, the at least one output signal including a status indication to indicate whether the functional module is active, and wherein the sensitivity level control logic selects the next level at least in part based on the status indication.

[0069] Embodiment 104. The system of any of the preceding embodiments, wherein the logic sensitivity level control logic selects a higher next sensitivity level at least once in response to at least one of the plurality of functional modules becoming active.

[0070] Embodiment 105. The system according to any of the preceding embodiments, wherein said at least one output signal is indicative of a risk level associated with a current activity of said at least one functional module, wherein said sensitivity level control logic derives a sensitivity level from said risk level at least partially as a next sensitivity level.

[0071] Embodiment 106. The system according to any of the preceding embodiments, wherein if the functional module is active and has a first risk level, the sensitivity level control logic selects a first sensitivity level as a next sensitivity level, if the functional module is active and has a second risk level lower than the first level, the sensitivity level control logic selects a second sensitivity level as a next sensitivity level, and if the functional module is inactive, the sensitivity level control logic selects a third sensitivity level as a next sensitivity level.

[0072] Embodiment 107. The system according to any of the preceding embodiments, wherein said chip has a plurality of possible power states, the power states including at least one idle state and at least one wake state, and wherein said sensitivity level control logic selects a next sensitivity level in response to a new state of the chip, the new state of the chip including one of the plurality of possible states.

[0073] Embodiment 108. The system according to any of the preceding embodiments, wherein the functional module includes firmware to trigger a transition between the possible power states, thereby causing the sensitivity level control logic to be aware of the current state.

[0074] Embodiment 109. The system according to any of the preceding embodiments, wherein the next sensitivity level is selected prior to a transition of the power state of the chip to the new state.

[0075] Embodiment 110. The system according to any of the preceding embodiments, wherein the detector is set to the next sensitivity level prior to a transition of the power state of the chip to the new state.

[0076] Embodiment 111. The system according to any of the preceding embodiments, wherein the next sensitivity level is selected after the power state of the chip has transitioned to the new state.

[0077] Embodiment 112. The system according to any of the preceding embodiments, wherein the hardware fault injection detector circuit is set to the next sensitivity level after the power state of the chip has transitioned to the new state.

[0078] Embodiment 113. The system according to any of the preceding embodiments, wherein said system is deployed on a chip to be protected.

[0079] Embodiment 114. The system according to any of the preceding embodiments, wherein the at least one fault injection detection subsystem comprises a plurality of fault injection detection subsystems, each fault injection detection subsystem configured to be deployed on the chip and each fault injection detection subsystem comprising a hardware fault injection detector circuit and sensitivity level control logic coupled with the fault injection detection subsystem.

[0080] Embodiment 115. The system according to any of the preceding embodiments, wherein the system is deployed on a chip to be protected, wherein the at least one functional module comprises at least a first functional module and a second functional module, and wherein the plurality of fault injection detection subsystems comprises a first fault injection detection subsystem and a second fault injection detection subsystem to protect the first functional module and the second functional module, respectively, wherein the first module is closer to the first fault injection detection subsystem than the second module, and the second module is closer to the second fault injection detection subsystem than the first module.

[0081] Embodiment 116. The system according to any of the preceding embodiments, and wherein at least one fault injection detection subsystem S of the plurality of fault injection detection subsystems protects at least one functional module on the chip, wherein the respective hardware fault injection detector circuit of each of the plurality of fault injection detection subsystems has a sensitivity level selected in real-time by the at least one functional module protected by the hardware fault injection detector circuit.

[0082] Embodiment 117. The system according to any of the preceding embodiments, and wherein each hardware fault injection detector circuit has a plurality of real-time selectable sensitivity levels.

[0083] Embodiment 118. The system according to any of the preceding embodiments, and wherein the fault injection detection subsystem comprises a plurality of hardware fault injection detector circuits, and wherein the sensitivity level of the fault injection detection subsystem at a point in time t is implemented as a number of the plurality of hardware fault injection detector circuits being enabled at the point in time t, wherein the sensitivity level control logic determines how many of the plurality of hardware fault injection detector circuits to enable at the point in time t, thereby providing a countermeasure with a real-time configurable sensitivity level, whereby a lower sensitivity level is implemented by a lower number of enabled hardware fault injection detector circuits, and a higher sensitivity level is implemented by a higher number of enabled hardware fault injection detector circuits.

[0084] Embodiment 119. The system according to any of the preceding embodiments, wherein the at least one functional module comprises a plurality of functional modules, and wherein the sensitivity level control logic derives a sensitivity level to be selected as a next sensitivity level by combining output indications from each of the functional modules and composes a set of sensitivity control signals.

[0085] Embodiment 120. The system of any of the preceding embodiments, wherein the sensitivity level control logic releases the sensitivity level to a lower next sensitivity level at least once in response to at least one individual functional module becoming inactive.

[0086] Embodiment 121. The system of any of the preceding embodiments, wherein the functional modules include an encryption module associated with a high risk level.

[0087] It will be appreciated that certain embodiments can be implemented as a computer program driven CM sensitivity control product, if desired, that includes a computer program that is generally more real-time than execution of the processor core to be protected. Thus there is provided a computer program product comprising a non-transitory tangible computer readable medium having computer readable program code embodied therein, the computer readable program code adapted to be executed to implement a security method that dynamically depends on execution flow of a processor core to control a fault injection countermeasure circuit operation to protect a processor from a fault injection attack, the method comprising:

[0088] i. providing a processor core that, in use, executes instructions and concurrently in real-time generates output indications of at least some of the instructions to be executed;

[0089] ii. providing a fault injection detector having a plurality of controllable sensitivity levels; and

[0090] iii. using, in real-time, a sensitivity level control module,

[0091] receiving the output indications,

[0092] using sensitivity level selection logic that takes at least the output indications as input to select a next sensitivity level from the plurality of controllable sensitivity levels and setting the fault injection detector to the next sensitivity level,

[0093] thereby providing the fault injection countermeasure circuit to respond to the output indications of the at least some instructions to avoid at least one false positive that would have occurred if the sensitivity level providing the CPU protection was not dependent on the output indications of the at least some instructions when protecting the CPU from the fault injection attack. Moreover, if the sensitivity level is set to avoid false positives completely, the fault injection countermeasure circuit can detect at least one fault injection that would not have been detected if the sensitivity level providing the CPU protection was not dependent on the output indications of the at least some instructions.

[0094] The above mentioned embodiments and other embodiments will be described in detail in the next paragraphs.

[0095] Any trademarks appearing in this specification are the property of their respective owners and are used merely for illustrative purposes in showing an example of how an embodiment of the invention can be implemented.

[0096] Unless specifically stated otherwise, as apparent from the following discussions, it is appreciated that throughout the specification discussions utilizing terms such as "processing", "computing", "calculating", "determining", "estimating", "selecting", "ranking", "computing", "determining", "generating", "re-evaluating", "classifying", "producing", "generating", "stereo matching", "registering", "detecting", "associating", "overlaying", "obtaining", or the like, refer to the action and / or processes of one or more computers or computing systems, or processors or similar electronic computing

[0097] Elements listed separately herein are not necessarily distinct elements, or can be the same structure. Statements of the presence or absence of an element or feature are intended to include embodiments wherein the element or feature is present in the embodiment; embodiments wherein the element or feature is not present in the embodiment; embodiments wherein the element or feature is optionally present, e.g., a user can configure or select whether the element or feature is present.

[0098] The present security system dynamically depends on the execution flow of the processor core to control the fault injection countermeasure circuitry to operate to protect the processor from fault injection attacks. BRIEF DESCRIPTION OF DRAWINGS

[0099] Some embodiments of the invention are shown in the following drawings:

[0100] Figure 1 is a prior art showing a general CPU operation cycle, which specifically includes a fetch process, followed by a decode, followed by an execution.

[0101] Figure 2 is a simplified flowchart showing a method for constructing a system, according to some embodiments.

[0102] Figure 3is a simplified block diagram showing a security system in accordance with some embodiments, typically characterized by instructions executed by a processor core or CPU becoming triggers for a fault injection attack detector for adjusting protection of the core from some attacks (e.g. executing conditional branches or other portions of program code deemed to be at high risk of hacking), and the triggers possibly triggering adjustment of the detector in real time to make it more sensitive.

[0103] Figure 4 is a simplified flowchart showing a method of real-time operation for a dynamic sensitivity level adjustment system in accordance with some embodiments.

[0104] Figure 5 is a schematic diagram showing a dynamic sensitivity level adjustment system in accordance with some embodiments of the invention, showing 3 levels of sensitivity, including a lowest sensitivity level defined as a preset level and two additional levels each higher than the preset level.

[0105] Figure 6 is an embodiment of a fault detector showing Figure 5 .

[0106] Figure 7 is a 3-level waveform diagram showing instruction decode signals, combined risk level (e.g. low, medium or high) i.e. selected sensitivity level (e.g. conservative, medium or aggressive / highly sensitive); it will be appreciated that any number of levels other than 3 can be used instead.

[0107] Figure 8 is a simplified schematic diagram showing a plurality of detector units in accordance with some embodiments of the invention.

[0108] Figure 9 is a simplified diagram showing a single-single-single in accordance with some embodiments of the invention.

[0109] Figure 10 is a simplified diagram showing a multi-single-single in accordance with some embodiments of the invention.

[0110] Figure 11 is a simplified diagram showing a multi-single-multi embodiment in accordance with some embodiments of the invention.

[0111] Figure 12 is a simplified diagram showing an embodiment comprising a plurality of multi-single-single components, showing construction and operation in accordance with some embodiments of the invention.

[0112] Methods and systems encompassed within the scope of the invention can include some (e.g. any suitable subset) or all of the functional blocks shown in any suitable order (e.g. as shown in the figures).

[0113] The computing, functional or logical components described and illustrated herein can be implemented in various forms, for example, as hardware circuitry, such as, but not limited to custom VLSI circuitry or a gate array, or programmable hardware devices, such as, but not limited to FPGAs, or as software program code stored on at least one tangible or non-transitory computer readable medium and executable by at least one processor or any suitable combination thereof. A particular functional source can be formed by one particular sequence of software program code or by multiple such software program codes acting in concert or as described herein with reference to the functional source. For example, elements can be distributed over multiple program code sequences, such as, but not limited to objects, processes, functions, routines, and programs, and can be sourced from multiple computer files operating in concert.

[0114] Any logical function described herein can be implemented as a real-time application, as appropriate, and can employ any suitable architectural option, such as, but not limited to, ASIC or DSP or any suitable combination thereof. Any hardware element mentioned herein can actually comprise one or more hardware devices, such as chips, which can be co-located or remote from one another.

[0115] Reference Signs:

[0116] 301: processor core

[0117] 302: fault injection detector

[0118] 303: fault injection improvement circuit

[0119] 91, 91a, 91b, 91c: functional module

[0120] 92: sensitivity level control logic

[0121] 93, 93a, 93b: hardware error injection detector

[0122] 21-24, 310-350: step flow DETAILED DESCRIPTION

[0123] The following description is presented to enable any person skilled in the art to practice the application as claimed. Various modifications to the preferred embodiment will be readily apparent to those skilled in the art, and the generic principles defined herein can be applied to other embodiments without the use of the inventive faculty. The present disclosure is not intended to be limited to the embodiment shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein and defined by the following claims.

[0124] It will be understood that, although the terms "first", "second", "third", etc. can be used herein to describe various elements, components, regions, layers and / or sections, these elements, components, regions, layers and / or sections should not be limited by these terms. These terms are only used to distinguish one element, component, region, layer and / or section from another element, component, region, layer and / or section. Thus, a first element, component, region, layer and / or section discussed below could be termed a second element, component, region, layer and / or section without departing from the teachings of some embodiments of the disclosure.

[0125] It is to be noted that the following disclosure can provide numerous examples or implementations of different features to implement the application. Specific examples of elements and arrangements are described herein in simple terms to convey the spirit of the application and its principles, and not to limit the scope of the application. Furthermore, the same reference numerals or letters are used in different instances of similar elements throughout the specification. However, the repeated use of reference numerals or letters in various instances is not intended to be a limitation. In addition, the descriptions of one feature connected, coupled, and / or formed on another feature, etc. described in the following specification can actually include different embodiments, including the features directly contacting each other, or including other additional features formed between the features, etc. so that the features do not directly contact each other.

[0126] "Basic Operation of the DLX Machine" by Mike McDonald and Tony Jacobs, available online at the following Internet link with the html suffix: cs.umd.edu / class / fall2001 / cmsc411 / projects / DLX / proj. This document describes the five stages of execution in the DLX architecture: Instruction Fetch (IF), Instruction Decode (ID), Execution (EX), Memory (MEM), and Write-Back (WB). Each stage takes as much time as the slowest stage, even if it does not need that much time to complete. This period of time is one clock cycle. Thus, it takes a total of 5 clock cycles for each instruction to go from start to finish. Each stage of execution corresponds to hardware in the CPU. Each "part" of the hardware on the data path can run at the same time, and the pipeline takes advantage of these to get a huge performance advantage. Each stage does very specific things.

[0127] 1. Instruction Fetch (IF): Read instruction from memory and put it into instruction register (IR). Update new program counter (NPC) to point to next instruction (PC+4, or next word in memory).

[0128] 2. Execution (EX): Decode instruction (based on opcode). Outputs from registers in register file are placed into temporary registers. Sign extension can be part of the instruction for an immediate value and place that value into a temporary register.

[0129] 3. Execution (EX): What happens here depends on the type of instruction that is to be executed. The ALU runs in this cycle to perform the required operation.

[0130] Figure 1 is the prior art showing a general CPU operation cycle, which specifically includes a fetch process, followed by a decode, followed by an execution.

[0131] A system for fault injection countermeasure sensitivity adjustment will now be described in detail.

[0132] An "if" statement or conditional branch is an example of a CPU instruction that can be susceptible to a fault injection, i.e., a "fault injection attack", for example, can be targeted for a fault injection, for example, a point in the program flow that can be intentionally disrupted. For example, a conditional branch can be configured to jump to a portion of program code that provides some secret information to a user based on a previous operation. For example, on the condition that the user has successfully provided user authentication in a previous operation, or jump somewhere else, or not jump at all, both of which cases do not provide the requested information to the user if the user has not successfully provided the user authentication in the previous operation. In the latter case, a hacker can attempt to inject a "fault" at some time in an attempt to trick the conditional branch instruction to jump to the program code that provides the secret information even if the user has not provided the necessary user authentication in the previous operation.

[0133] According to some embodiments, a security system is provided in which a processor core indicates an upcoming opcode / instruction for execution in use (e.g., in real time). For example, a CPU, when fetching instructions from program memory, typically first decodes the instructions. The decoding of an instruction typically includes a logical function that takes as input the opcode, typically in binary form (the instruction opcode typically includes numbers that are typically stored in sequence as binary program code of the respective program, which can be interleaved with instruction operands), and applies a logical function (aka "decode logic") that produces CPU internal signals to operate various units of the CPU to perform respective functions, e.g., operating the ALU of the CPU to perform arithmetic operations, etc. According to some embodiments, the decode logic can be used to output the decode signals to a subsystem external to the CPU (e.g., a sensitivity level control module) to enable the subsystem to take action (e.g., select a sensitivity level) in response to advance knowledge of the operation that the CPU is about to perform at a given time, despite being external to the CPU.

[0134] It can be appreciated that, typically, the built-in CPU decode logic is designed to control the operational units of the CPU, e.g., the ALU, according to the instruction being processed, and the CPU does not "know" which instruction is going to be executed at any given time. Rather, according to some embodiments, the decode logic output typically indicates which instruction is going to be executed now. Furthermore, there can be overlapping control states within a CPU instruction. For example, two (or N) different instructions of a family can have some of the same internal controls, since the two different instructions operate on the same CPU block.

[0135] One particular advantage of adapting the decode logic to communicate with an external subsystem can be that, since the decoding precedes the actual execution of the instruction by the relevant CPU unit (e.g., the ALU), the external subsystem can preview the instruction that the CPU has not yet actually executed.

[0136] It can be appreciated that some integrated circuits implement a low power mode. For example, when it is detected that the core is executing certain predefined instructions, the integrated circuit can enter a low power mode, e.g., a WAIT instruction or some other type of HALT instruction, or Wait-For-Interrupt, all of which typically put the core of the CPU in a hold state in which the core typically remains, waiting for an event that triggers the core to exit the hold state. This would involve real-time indication of which opcode / instruction is going to be executed.

[0137] There exist authentication mechanisms that run based on tracking the CPU's execution flow, such as commonly owned U.S. Patent No. 9703945. When a specific set of instructions is executed, the execution flow can be paused to authenticate the program code. In particular, U.S. Patent 9703945 describes an authentication mechanism that runs based on tracking the CPU's execution flow. U.S. Patent 9703945 describes specific operations or instructions (e.g., accessing a specific space of memory-mapped I / O addresses). These operations or instructions are deemed to require a higher level of security in terms of program code authentication, according to the system designer's decision. Thus, upon detecting such an instruction, e.g., a write operation to that I / O address space, the execution flow is temporarily stopped until a certain program code authentication sequence is completed. Upon completion of this operation, assuming that the corresponding program code has passed authentication, the execution flow is resumed and the operation is executed. Thus, this method is triggered by certain instructions, which change the program flow to take some predefined operations, i.e., program code authentication.

[0138] Furthermore, U.S. Patent 9703945 describes a processing core coupled to receive program instructions from an input bridge and to execute the program instructions, wherein the program instructions include program instructions capable of outputting a signal through an output bridge and program instructions that do not send data to one or more system outputs, and wherein the processing core can execute the program instructions that do not send data to one or more system outputs both when the output bridge is in a first state and when the output bridge is in a second state.

[0139] The term "sensitivity level" is intended to include any cut-off point or threshold value, any specification or triggering characteristic applied by the fault injection detector to the fault injection, or any specification or triggering characteristic related to the fault injection, such that the fault injection detector can react to it, and used by the logic of the fault injection detector to distinguish between faults and non-faults. Typically, the fault injection detector will strive to detect a difference between the expected and actual situation, and each time a difference is detected, a "fault" alert is provided.

[0140] Since different types of fault injection detectors are implemented using different mechanisms, various sensitivity control mechanisms can be employed to implement the sensitivity level, such as, but not limited to, the following:

[0141] a. The fault injection detector can recognize a sudden change, i.e., a glitch in the supply voltage or ground level in the chip. In this case, the detector can be set to recognize an abnormal situation when the actual situation (the actual detected voltage) differs from the expected voltage by 50mV, 100mV, or 300mV.

[0142] b. Voltage level comparisons can be made between different locations on the same logical network to detect local differences, as all locations are expected to be in the same state.

[0143] c. The light detector can be operable to attempt to identify a fault injection using light energy, based on resulting fault injection detection from voltage levels corresponding to light intensity.

[0144] It can be appreciated that voltage levels of digital signals can be compared at any given time (assuming to be in the same logical state (whether 1 or 0)). In such a comparison, a trigger voltage difference can be defined as X, Y, or Z.

[0145] Furthermore, sensitivity need not be based on voltage levels at all. For example, a detector with non-voltage-based sensitivity levels can include:

[0146] First, a detector designed to directly detect light (e.g., laser, energy). If the detector converts light energy into voltage levels proportional to the light energy absorbed, then voltage levels A, B, or C can be detected corresponding to light energy levels X, Y, and Z, respectively.

[0147] Second, a detector designed to directly detect electromagnetic energy other than light. If the detector converts electromagnetic energy into voltage levels proportional to the electromagnetic energy absorbed, then voltage levels A, B, or C can be detected corresponding to electromagnetic energy levels X, Y, and Z, respectively.

[0148] An example of a detector with non-voltage-based sensitivity levels that does not operate in real-time is a frequency deviation detector, which can have multiple sensitivity levels in terms of the magnitude of a frequency deviation from an expected frequency. It should be appreciated that in this case, the target of the fault injection can include a chip’s clock that typically has an intended frequency (also referred to as an “expected frequency”). For example, if a given chip’s clock has an expected frequency of 250 MHz, and a transient deviation from that value is detected, such as two clock pulses detected closer together than expected, this can indicate that a fault injection has occurred.

[0149] Some glitch detectors can be designed to have multiple sensitivity levels, which are pre-defined and pre-configured (as opposed to being dynamically configured in embodiments of the present invention) by configuration selection and according to system architecture.

[0150] Figure 2 A method of building a system that can receive an opcode indicator from a processor core or CPU, make a corresponding sensitivity level decision in real-time, although other factors can also influence the decision, and then provide a sensitivity level control to a countermeasure circuit is described in accordance with some embodiments of the present invention.

[0151] As mentioned above, there can be situations or conditions where the security developer can consider that there is a higher risk of introducing hardware fault injection, for example but not limited to the execution of conditional branches.

[0152] Generally speaking, the injected faults will eventually translate into electrical events of the integrated circuit that will interfere with the consistency and coherent operation of the integrated circuit hardware. For example, in the case of an MCU / CPU executing program code, fault injection that attempts to interfere with the consistency and coherent operation of the integrated circuit hardware will typically attempt to interfere with the execution flow of the program code, attacking the hardware of the integrated circuit to interfere with the execution of the integrated circuit software and / or firmware.

[0153] In this case, the security developer can wish to dynamically use different trade-offs between security level and false positives.

[0154] The security developer can follow any suitable procedure when configuring the logic. For example, the designer can first simulate and / or operate the device under expected normal real-life scenarios and allowed operating conditions, to ensure that the mechanism never triggers false alarms (or only with an acceptable rarity) under the allowed operating conditions. Then, the designer can operate the device, given the fault injection that the device is intended to withstand, and determine a fault injection detection level that correctly triggers all or almost all of the fault injections, for example at an acceptable reliability level. The designer can then define this “appropriate level” as the preset detection level for detecting fault injections. The designer can then adjust the logic so that it enables a selected higher sensitivity level (corresponding to a slightly more aggressive detection) in real time in response to an output indication that the CPU is about to execute instructions that the designer considers to be associated with a higher risk of fault attack.

[0155] Generally, the developer will adjust the detection level so that it triggers (detects that an attack is occurring) when the operating conditions can indeed cause the hardware to operate incorrectly. Such a level can be noted by the developer on multiple device variants, to ensure that there is little or no detection of fault injections during normal operation.

[0156] Generally, it is desirable to provide a circuit that is capable of detecting at more than one level defined by the designer, for example at least two detection levels, one of which, but not the other, intercepts light fault injections at the risk of unnecessarily interfering with the normal operation of the device. These levels can include:

[0157] a first level that detects aggressive fault injections that result in abnormal situations (for example, situations that create a risk of failure of the device); and

[0158] Second level: Not only can attacks be detected, but non-attack (also called mild) fault injection can be detected, which causes unexpected situations, but the device can still maintain operation without failure.

[0159] Reference is made to Figure 2 , which generally provides a processor that generates a signal indicating which instruction / opcode or family / group of opcodes is to be executed at each intended time. For example, from the time a subject instruction / command is recognized by a decode unit of the processor to the time an execution unit indicates that execution of the instruction / command is complete, a signal can indicate that a given instruction is about to be executed. In this embodiment, the indication includes both the "decode" and "execute" stages of the instruction, however, this need not be the case. Alternatively, the signal can indicate that a given instruction is to be executed during the "execute" stage of the given instruction, rather than during the decode stage of the given instruction. Another possible embodiment is to have the indication active from (and including) the "decode" stage of a subject instruction until (but not including) the "decode" stage of the next instruction (the instruction executed after the subject instruction by the processor).

[0160] It is understood that certain control signals (also referred to as CPU internal signals) that control the above-described cycle are part of the internal design of the CPU, but are common to all or many CPUs, such as:

[0161] (a) a notification signal to notify the fetch unit to fetch an instruction from memory and store the instruction locally, and

[0162] (b) a signal generated by the decode unit to assign or inform other CPU units to operate and execute the instruction.

[0163] Furthermore, as still shown in Figure 2 , the system designer typically associates at least one opcode or a group of opcodes with a related security risk. Generally, a conditional branch opcode is associated with a high risk R (R can be a scalar) relative to some or all opcodes that are not associated with a risk lower than R. This is because a conditional branch instruction controls the flow of a program, and thus is a node at which fault injection can cause the program to deviate from the correct and ordered flow.

[0164] Alternatively or additionally, according to certain embodiments, a detailed risk analysis can be used to understand the relative risks associated with various different opcodes.

[0165] To perform a risk analysis, a designer can study the instruction set of the processor. An example description of an instruction set (ARM Cortex-M0) is available on the web at the following http link and with the html suffix: infocenter.arm.com / help / index.jsp?topic= / com.arm.doc.ddi0432c / CHDCICDF.

[0166] At least, since instruction sets tend to be similar across processors, at least across similar types of processors, e.g. across RISC processors or across CISC processors, to some extent this analysis can be generalized across processors. For example, many processors can have all or most of the following instruction types or groups of instructions:

[0167] 1. Memory and register manipulation: typically includes load instructions, store instructions, and move instructions.

[0168] 2. Arithmetic and logical operations: typically includes addition, subtraction, sometimes multiplication and division or arithmetic shifts, and logical operations such as or, and, exclusive or.

[0169] 3. Stack management: typically push / pop.

[0170] 4. Branching: conditional and unconditional.

[0171] 5. Control: e.g. but possibly not limited to state management, interrupt management.

[0172] Nonetheless, since each particular processor does tend to have at least somewhat different instruction sets from other processors, some individual risk analysis of processors can ultimately be performed.

[0173] A designer can also review the application and its implementation (including analysis of the application code), and can quantify the risk of particular instructions or instruction types accordingly. For example:

[0174] a. A stack management instruction can be considered high risk relative to at least one instruction other than a stack management instruction (and / or relative to a risk level associated with at least one instruction in at least one of the above instruction groups 3-5 and / or relative to an opcode considered low risk). For example because a stack can also play a role in program flow, particularly when subprogram calls are involved; a stack typically holds return addresses, so manipulating them through fault injection can also cause a program to deviate from an orderly flow of execution.

[0175] b.In the instruction set of arithmetic / logical operations (group 2 above), based on the analysis of the program code, the system designer can find that certain arithmetic instructions used in "critical" locations in the program code affect the program flow and / or the "decisions" of the program code. These certain instructions can be associated with a high risk, e.g., higher than the risk of an arithmetic instruction in the program code that is not in such a critical location or higher than the risk level associated with at least one instruction in at least one of the instruction groups 3-5 above and / or higher than an operation code deemed to be low risk.

[0176] Further, as shown in Figure 2 there is a fault injection detector with at least two levels of sensitivity (L>=2), one of which is more relaxed (with a lower level of sensitivity) and the other is more sensitive (with a higher level of sensitivity).

[0177] Further, as shown in Figure 2 the dynamic sensitivity level adjustment (e.g., the selection of one of the L levels in real time) can be implemented in any suitable manner. For example, decoding logic can be provided that receives these signals from the processor and, depending on the security risk level of the operation code, generates a corresponding signal at any time to indicate to the fault injection detector whether it should be triggered based on the more relaxed or more sensitive detection level. Figure 5 An embodiment is shown that shows a 3-level sensitivity, which includes a lowest level of sensitivity defined as a preset level and two additional levels that are both higher than the preset level.

[0178] According to certain embodiments, the indication to the detector disappears immediately or immediately after the decoding of the instruction, so that the detector gets the signal before the core starts executing the instruction. The detection circuitry itself typically does not "reject" or absorb or otherwise handle the fault injection. However, the circuitry does generate a flag to indicate that a fault injection has occurred, allowing other modules to respond in any suitable manner, such as but not limited to restoring the device (e.g., CPU or processor) to a known state and restoring the program to a known node in the flow. Such restoration can occur relatively slowly, e.g., only after the fault injection has occurred. However, since the damage caused by the fault injection does not occur immediately this is acceptable, unless the restoration occurs before reaching a location in the program code that should not have been reached and in fact would not have been reached but for the fault injection.

[0179] Figure 2 The method of

[0180] Step 21. What is susceptible to fault injection and what generates a signal to indicate which instruction / opcode or opcode family / group to execute at any given time is provided to the processor core / CPU.

[0181] Step 22. Risk analysis is performed: the system designer associates a security risk (e.g. risk of fault injection) with a list of opcodes or opcode groups and generates sensitivity level decision / selection logic accordingly. For example: conditional branch opcodes are high risk; all other opcodes are low risk.

[0182] Step 23. A fault injection detector with at least two sensitivity levels is provided.

[0183] Step 24. Sensitivity level adjustment of the CM circuit is implemented, for example a CM circuit is provided that can adjust the sensitivity level in real time, for example by dynamically selecting one of at least two levels. In general, the fault injection detector supports dynamic adjustment, for example real-time adjustment of the sensitivity level and its response time is shorter than the decode execution cycle of a single instruction of the processor or CPU that is protected by the fault injection detector.

[0184] As mentioned above, the response time is typically short since it is generally desirable to control the time period in which the signal propagates through the sensitivity control unit to the detector to leave sufficient time for the detector to react. For example: if the instruction cycle is 40ns long, then the time that elapses from the indication of the opcode to the detector being set at the required sensitivity level is, say, at most 10ns leaving a 30ns time window in which the detector can react.

[0185] Reference is now made to Figure 3 It can be appreciated that conditional execution and conditional branches, i.e. software decision points, are considered as weak points in the security program code, i.e. nodes that are susceptible to fault injection attacks. Figure 3 is a simplified block diagram showing a security system in accordance with certain embodiments, which can be provided as per the method of Figure 2 Figure 3 The system of

[0186] a processor core 301 or CPU with an indication of an opcode or other program code, indicating execution of a specific instruction or class of instructions, for example but not limited to conditional branches, specific comparisons, etc.; and

[0187] ​A countermeasure (CM) circuit, for example, includes a fault injection detector 302 designed with multiple controllable sensitivity levels. The CM circuit can include a fault injection amelioration circuit 303 in combination with a fault injection detector with adjustable sensitivity. If the fault injection detector detects a fault injection, the fault injection amelioration circuit is activated. For example, each time the fault injection detector detects a fault injection, the fault injection amelioration circuit is triggered.

[0188] For example, design issues regarding certain examples of such circuits are described in the following white papers, all available on the web:

[0189] Compilation of a Countermeasure Against Instruction-Skip Fault Attacks

[0190] Thierno Barry, Damien Courouss_e, Bruno Robisson

[0191] and:

[0192] Low-Cost Software Countermeasures Against Fault Attacks: Implementation and Performances Trade Offs

[0193] It should be understood that the term "countermeasure" is generally used to refer to detectors and / or modules used to ameliorate (e.g., prevent or correct) the adverse effects of fault injection attacks. In the context of Figure 3 the CM circuit detects such attacks and triggers any suitable modules to prevent or correct the adverse effects of such attacks.

[0194] According to one embodiment, a security system that has identified the execution of a conditional branch adjusts the detection level of the corresponding circuit to a more sensitive level.

[0195] It can be appreciated that various instructions or categories thereof can be considered to introduce a higher risk of fault injection as compared to instructions not so considered. By way of some non-limiting examples, any or all of the following opcodes can be considered to introduce a higher risk of fault injection that can cause system design decisions to associate any or all of the following opcodes with a high security risk (e.g., a high risk of fault injection), i.e., a risk level higher than the risk level associated with the opcodes (as opposed to the following and / or logic provided to increase the sensitivity level of a fault injection detector when such instructions are encountered), such as:

[0196] a. opcodes that indicate conditional branches, e.g., branch-if-equal, branch-if-not-equal of the branch instruction of a RISC CPU that decides whether to branch or continue in order based on a comparison between two operands that precede the conditional branch and produce a "result" branch that is used subsequently by the conditional branch.

[0197] b. opcodes that perform a comparison or other "test" that results in setting various flags that are then used by logic that "decides" whether to take a given conditional branch. For example, a compare instruction can be used to compare two operands and set a flag if the two are equal (or if the two are not equal). A subtraction operation can set a flag to compare operands, e.g., numbers, if the result is negative or non-zero.

[0198] c. opcodes that push a particular type of information onto the processor stack, e.g., a key or sensitive information or data or return address of a CPU subsystem banner that is used later for conditional operations.

[0199] d. opcodes that are characterized as being used as a stop condition for implementing a loop. For example, loops are described in the file provided at the following https www link with the htm suffix: tutorialspoint.com / assembly_programming / assembly_loops.

[0200] The loop instruction described is assumed to have a loop counter saved in a predetermined CPU register. When the CPU encounters the "loop" instruction, the CPU can decrement the loop counter, compare the loop counter to zero, and return to the beginning of the loop if the counter is greater than or equal to zero, thereby implementing the loop stop condition.

[0201] In some cases, it may be unknown in advance which instructions will be used, for example, because the instructions used may depend on the compiler choice of different CPUs. For instance, a CPU may have a built-in instruction for loops that processes a specified register or variable, automatically incrementing or decrementing it, and then, if the loop counter is specified, jumps back to the beginning of the loop, or allows the program to continue sequentially if the loop counter has expired.

[0202] It should be understood that, relative to various instructions or categories that are not so considered, there is a particularly low risk of fault injection compared to those that are considered. For the purpose of providing some non-limiting examples, any or all of the following may be considered to introduce a particularly low risk of fault injection (this may be due to system design decisions that associate any or all of the following opcodes with low security risk, i.e., a lower risk level than that associated with opcodes other than those listed below, and / or to providing logic to reduce the sensitivity level of the fault injection detector when encountering such instructions, thereby reducing false alarms with little or no adverse effect):

[0203] a. Load opcodes that read data only from memory or

[0204] b. Storing opcodes that only store data in memory

[0205] While fault injection may cause the aforementioned problems and lead to malfunctions, it is considered practically impossible for a hacker to define a valid attack by interfering with specific store / load instructions.

[0206] Figure 4 This illustrates the operating methods described according to certain embodiments; for example, according to Figure 2 Methods and / or Figure 3 The system's operating methods.

[0207] Figure 4 The approach typically combines core execution instruction operations, where instructions are provided, decoded, and used in real time to select the sensitivity level of the fault injection detector. Generally, a given sensitivity level is associated with each of several instructions or instruction families / groups. Typically, system designers associate higher sensitivity levels with instructions deemed to pose a higher risk based on their risk assessments—for example, from the perspective of a hacker searching for suitable target locations for a fault injection attack, these are considered attractive targets. Conversely, lower sensitivity levels are associated with instructions considered to have a lower risk level. Figure 4 Systems employing this method are typically configured to allow instructions to be decoded and responded to in real time. Instructions are set to a sensitivity level associated with or corresponding to the instruction that has just been decoded and is about to be executed. The sensitivity level is then set within the time window between the instruction's decoding and its execution by the core.

[0208] Figure 4 The method of FIG. 3 generally includes some or all of the following operations, in proper order, e.g., as shown:

[0209] At step 310, the CPU provides the operation code indicator I to the sensitivity level decision logic employed by the sensitivity level control module (also referred to as sensitivity level selection logic).

[0210] At step 320, the sensitivity level decision logic produces a decision that the sensitivity level of the CM circuit should be L_I.

[0211] At step 330, the sensitivity level control module signals (or commands) the sensitivity level control module to adjust the sensitivity level of the CM circuit to L_I.

[0212] At step 340, the sensitivity level control module signals the sensitivity level of the CM circuit.

[0213] At step 350, the CM circuit adjusts its sensitivity level to L_I. For example, a suitable selector unit can be used to adjust the level, the control of which includes (or is derived from) the sensitivity level control command indicating which operation code is to be executed.

[0214] Figure 5-6 is a 3-level embodiment of a dynamic sensitivity level adjustment system according to certain embodiments. The design of the device is pre-analyzed, including risk classification, then during operation, the probe responds in real-time according to the risk classification previously performed.

[0215] In particular, Figure 5 is a schematic diagram showing a 3-level sensitivity dynamic sensitivity level adjustment system, where the 3-level sensitivity includes a lowest sensitivity level defined as a preset level and two additional levels that are both higher than the preset level. Figure 6 is a block diagram of a fault detector for Figure 5

[0216] Figure 7 is a 3-level waveform diagram showing the decoding of signals, combining risk levels (e.g., low, medium, or high) and selected sensitivity levels (e.g., conservative, medium, or aggressive / highly sensitive) according to some embodiments; it should be understood that any number of levels other than 3 can be employed instead, and that the preset level as shown in the figure is not required.

[0217] ​In an embodiment of a CPU executing a pipeline, as illustrated, if the pipeline is processing a "low risk" instruction as well as a "high risk" instruction, the sensitivity level of the detector is set preferentially as soon as the high risk instruction is decoded. For example, at the point where "medium risk" fetch occurs, the sensitivity is increased (immediately) as soon as the instruction is decoded. Similarly, when "high risk" fetch occurs, the sensitivity is further increased immediately as soon as the instruction is decoded. More generally, when Figure 7 the system identifies an instruction with a higher risk than the currently set instruction, the newly decoded instruction with the (higher) risk priority until the CPU completes processing the high risk instruction, and then reverts to the previous instruction processing.

[0218] It is to be understood that "fetch" as illustrated in Figure 7 is inclusive of "decode", and for brevity, the "fetch" illustrated in the figures can be interpreted as "fetch and decode".

[0219] Reference is made to Figure 8 . According to certain embodiments, the fault injection detector includes a plurality of fault injection detector units deployed in a plurality of locations in the processor core, respectively, as illustrated in the embodiment of Figure 8 , thereby detecting fault injection attacks at all of the plurality of locations while taking into account certain location dependencies of the fault injection detector. If at least one detector unit deployed in a first location detects a fault injection attack at the first location, then the fault injection detector can issue an alert (and / or can trigger a fault injection amelioration operation applied to location L). Thus, an OR function (or any other suitable logic function) can be used to combine the fault injection detection determinations made by individual ones of the plurality of units. Any suitable number of units can be provided and with any suitable distance therebetween, typically determined in accordance with at least one of the following factors: die area occupied by each unit, physical characteristics of the integrated circuit being protected, and spatial characteristics of the anticipated fault injection attack.

[0220] Figure 8 is a simplified schematic illustration of a plurality of fault injection detector units deployed in various locations in the processor core and occupying a plurality of die areas of integrated circuits, respectively, in accordance with certain embodiments of the present application.

[0221] For certain embodiments of the present application, the use is as common as it is.

[0222] For example, commonly owned U.S. Patent 9,523,736 describes detecting state differences between different branches of a given electrical grid. An electrical logic network in an integrated circuit is generally expected to be in the same state, e.g., a logic state of 1 or 0, through all branches. Thus, when a voltage level difference is detected between two physical points on the same logic (electrical) network, it is likely to represent a fault injection attempt causing a local change. A designer can consider a difference between that location and elsewhere (e.g., 50mV between two points) to be normal, while a 300mV difference is sufficiently abnormal to be risky for integrated circuit functionality, and a 200mV difference is abnormal but not considered risky. According to certain embodiments, rather than just a detector designed to target 300mV, a detector can detect a 200mV difference or a 300mV difference depending on a level of sensitivity, which can be adjusted in real time by virtual control as described herein, e.g., a setting control signal can be sent to the detector in real time to set the detector to a 200mV level of sensitivity or a 300mV level of sensitivity. Thus, the system determines in real time whether to consider 50mV or 200mV or 300mV as a difference, where positive detection of the difference represents that a fault injection has been detected.

[0223] It can be appreciated that there can be other or more general uses than fault injection risk for which it would be reasonable to adjust sensitivity levels in real time. For example, it is believed that hackers will study and characterize the sensitivity of a given device to fault injection that they are targeting, which can precede the hackers' concentrated attempts to inject faults at very specific times and / or specific device locations. Changing sensitivity levels in real time, randomly, or according to real-time detected risk, e.g., by associating specific instructions with specific risk levels as described herein, can confuse or interfere with such studies.

[0224] Furthermore, if a device detects a large number (exceeding a threshold) of fault injection attempts in real time over a particular period of operation, e.g., more than X detections over Y time. For example, there can be periods of lower security risk, e.g., but not limited to, periods empirically observed to be less popular with hackers, and periods of higher security risk, e.g., but not limited to, periods empirically observed to be more popular with hackers, in 100% of system runtime.

[0225] Time-stamped events of detected fault injections can be recorded, after which suitable program code can track fault injections over time and identify peripheral time periods with particularly high or particularly low rates of fault injection occurrence.

[0226] It can be appreciated that the fault detectors herein can be integrated into larger systems, improving their operation.

[0227] For example, it should be appreciated that the embodiments shown and described herein need not act as the sole line of defense to make conditional branch operations more difficult to exploit. Rather, the fault detectors described herein can effectively be combined with traditional anti-hacker techniques to combat fault injection vulnerabilities at the program code level, for example:

[0228] a. by preventing or hindering or reducing the occurrence or occurrence rate of fault injection and / or

[0229] b. by circumventing or ameliorating the effects of fault injection once it has occurred,

[0230] Any of which can be triggered by the fault injection detection techniques shown and described herein.

[0231] Any of the methods shown and described herein for detecting fault injection can be employed and can augment or replace prior fault injection detection techniques used in prior systems that include a module operable to circumvent or ameliorate the effects of fault injection once detected. For example, the module can be activated when triggered by any of the two or more fault injection detectors.

[0232] Typically, category b requires detection of fault injection. Thus, any anti-hacker measures in category b can be improved by using the improved, dynamically controlled fault injection detection methods shown and described herein.

[0233] Once fault injection is detected, for example as shown and described herein, any suitable fault injection effect amelioration operation can thereby be triggered and can be executed in response to ameliorate, for example, correct at least one effect, for example, a deleterious effect of fault injection, for example, but not limited to, suitable for the following fault injection amelioration operations:

[0234] a. Placing the device in an irreversible state, preventing any further options.

[0235] b. Causing the processor to jump to a designated routine, such as performing an overall integrity check, which will typically then reset or reboot the CPU.

[0236] c. Placing the processor in an infinite loop until reset by a watchdog timer.

[0237] d. Stopping the device for a specific period of time.

[0238] e. Increasing the sensitivity level for a set time, after which the sensitivity will revert to a preset value if no further detections are made.

[0239] f. Disabling specific pre-designated “risky” functions for a period of time. The risky functions can be approval of authentication, exposure of sensitive data, or exposure of encryption keys.

[0240] g. pause the system until a power cycle is applied or until the system or device hardware is reset; watchdog timer reset or any other stop criteria or mechanism for releasing a stuck CPU.

[0241] It should be understood that the above fault injection amelioration operations are merely examples of functions that can be provided for modules designed to ameliorate the effects of a fault injection attack. The amelioration operations or functions can include preventing or blocking or reducing the occurrence or incidence of a fault injection and / or circumventing or ameliorating the effects of a fault injection once it occurs. It should be understood that the amelioration operations can be implemented in hardware and / or software and can utilize the program / data memory of the processor core.

[0242] It can be appreciated that more than one such fault injection amelioration operation can be performed. For example, operation e above can be combined with one of operations a-d or f-g.

[0243] Implement a sequence of conditional branches: for example, one of many techniques for making fault injection more difficult, and thus less likely, for example, per category a above, to repeat the conditional branch n > 1 times, for example, twice (n = 2). In this case, the first branch jumps to the second branch, which is the branch that jumps to the final destination, the two branches in n = 2, or more generally, all n branches are based on the same condition. This addresses the vulnerability because here a single fault is not enough for the branch to be hacked, instead a fault needs to be injected at each of the two or more, typically n, nodes, which increases the complexity of the subject execution flow for the hacker to perform. It should be understood that the embodiments shown and described herein can be combined with other anti-hacking measures, for example, any suitable measures to ameliorate, for example, correct at least one effect, for example, the effects of a fault injection, if desired by the system designer, to make the conditional branch operation more difficult to hack. The above technique regarding "Implementing A Sequence Of Conditional Branches" prevents fault injection by making it more difficult, and thus less likely, and can be combined with any suitable technique for ameliorating the effects or negative effects of a fault injection, for example, to ameliorate the effects or negative effects of a fault input. Suitable techniques can include, for example, using any of the embodiments shown and described herein to detect a fault injection, and then implementing any suitable fault injection effect amelioration measures when a fault injection is detected.

[0244] A known technique for better detecting fault injection (and thus better mitigating its effects, for example by stopping the system until applying a power cycle) is described in commonly owned U.S. Patent 9,523,736, which describes an apparatus for detecting fault injection including a high fan-out network of circuitry spanning a body of circuitry. During functional operation of the integrated circuit, the high fan-out network can remain inactive, and the circuitry can be configured to detect signal levels at multiple sampling points in the high fan-out network and identify a fault injection attempt by detecting a signal anomaly in the high fan-out network based on the sensed signal levels. The circuitry can be configured to detect signal levels at multiple sampling points in the high fan-out network to distinguish between a legitimate signal change and a signal anomaly in the high fan-out network during functional operation of the integrated circuit based on the sensed signal levels, and identify a fault injection attempt by detecting the signal anomaly. The circuitry can be configured to modify one or more signal levels in the high fan-out network in response to identifying the fault injection attempt. The control unit or sensor 48 can modify the signal levels on the network root 40 or another branch of the high fan-out network (e.g., force the signal to be active) as a result of the setting of the ALERT signal.

[0245] Another example is detecting hardware glitches, such as power / ground glitches in an integrated circuit caused by an external source (e.g., an electromagnetic energy source). Fault injection through power glitches is a known method for compromising integrated circuit devices. For many years, electromagnetic (EM) glitches have been considered an effective fault injection technique for achieving physical attacks on integrated circuits. Circuitry for detecting hardware glitches that indicate a fault injection vulnerability and "suffer" from a trade-off between a level of security and false alarms (also known as false positives) includes, for example, circuitry available over the Internet at the following http location: ieeexplore.ieee.org / document / 5376828;

[0246] Zussa, L et al., "Efficiency of a glitch detector against electromagnetic fault injection" ieeexplore.ieee.org / document / 6800417

[0247] and at the following https www location: blackhat.com / docs / eu-15 / materials / eu-15-Giller-Implementing-Electrical-Glitching-Attacks.pdf.

[0248] Recent knowledge about fault injection attack detectors is described in "Cheap & Cheerful: A Low Low-Cost Digital Sensor for Detecting Laser Fault Injection Attacks" dated December 16, 2016, available over the Internet at the following http location: www-users.math.umn.edu / ~math-sa-sara0050 / space16 / slides / space2016121602-37.pdf. The proposed solution is tunable ("The sensor has bi-directional detection capabilities, and the sensitivity of the back-end stage is tunable"). As noted elsewhere, the disclosure of this document, and indeed all documents cited herein, are hereby incorporated by reference.

[0249] It can be appreciated that the above-described detector can be enhanced by using the embodiments described herein to increase the dynamic sensitivity level adjustment of the opcode response. The CPU design in the disclosed document "Cheap & Cheerful" is tunable, and can be adapted to provide an output signal at all times indicating the instruction that is about to be executed. For example, multiple real-time selectable adjustments can be embedded in the design, or multiple circuits can be added, each with a different adjustment, where only one of the outputs of one of the multiple circuits is selected in real-time according to the sensitivity level indicated by the decision logic shown and described herein.

[0250] In general, any fault injection attack countermeasure known in the art can be used, such as the following:

[0251] "Compilation of a Countermeasure Against Instruction-Skip Fault Attacks" by Thierno Barry, Damien Courousse, Bruno Robisson, available over the Internet at the following https location: hal-cea.archives-ouvertes.fr / cea-01296572 / document; and

[0252] "Low-Cost Software Countermeasures Against Fault Attacks: Implementation and Performances Trade Offs" is available over the Internet at the following http location: euler.ecs.umass.edu / research / bpbk-WESS-2010.pdf

[0253] Can coexist with embodiments of the present invention as a complementary detection / protection layer. This all collectively enhances the overall level of protection of a CPU or similar device from attacks such as fault injection attacks.

[0254] It can be appreciated that analog circuits are often designed with an adjustment selection, such as multiple detection levels / thresholds providing multiple levels of sensitivity, and thus it can be difficult to predict in advance which levels / thresholds will be most effective in the actual electrical system environment. In general, once in silicon, testing is performed to determine which configuration is most effective, and then according to certain embodiments, rather than configuring the circuit to the setting of the single test selection, all or more than one of the multiple settings are retained, and control circuitry is added to select in real time which of the multiple settings to use, as shown and described herein. Testing can then simply be performed to reconfirm the performance of the circuit in real silicon.

[0255] One particular advantage of embodiments shown and described herein is that the tradeoff between the security level and the false positive level of fault injection detection is highly adjustable, even on a single opcode. By limiting the high tolerance for necessary but regrettable false positives (or low security level) to those opcodes that require such high tolerance, and desiring to reduce the tolerance for false positives (or low security level) to apply to all opcodes that do not require such high tolerance, the tradeoff is allowed to be overcome to a non-insignificant degree.

[0256] It should be appreciated that the specific embodiments herein are not intended to be limiting. The present invention is intended to include any embodiments operating in conjunction with a CPU or processor that has signals internally as a result of the decoding of instructions to be executed. According to these embodiments, these signals are sent out of the CPU, allowing at least one operating unit external to the CPU to take action based on the state of these signals, thus using signals available in one environment and designed for CPU internal purposes for another environment, typically for CPU external purposes in CPU external locations or environments. For example, in response to a real-time indication of which opcode / instruction is to be executed, a sensitivity level control module in a security system can simultaneously (e.g., in real-time) adjust the sensitivity level (also referred to as security level) of a fault injection detector function in a countermeasure circuit operable to counter a fault injection attack.

[0257] If used to implement certain embodiments herein, firmware can be saved in non-volatile memory, such as flash memory or ROM. Any suitable technique can be used to prevent the management of the flash memory from being interfered with by the restriction of the location of the firmware.

[0258] Alternatively, certain embodiments described herein can be implemented in hardware, partially or solely (i.e., without firmware), in which case some or all of the variables, parameters, sequential operations, and calculations described herein can be in hardware.

[0259] The term "countermeasure" (CM) as used herein is intended to include any aspect of the operation of the circuitry on the chip that is typically reactive in real-time to control signals, thus typically hardware implemented, that protects any other operating function in the CPU and / or chip or thwarts a fault injection attack, such as but not limited to power glitch attacks, clock glitch attacks, and signal glitch attacks.

[0260] Some countermeasures are "evasive" in that they obfuscate when and where the enemy or attacker is to inject a fault; it can be appreciated that if the attacker injects a fault at the "wrong" (from the attack's perspective) place or time, the attack is less likely to result in its intended effect.

[0261] For example, this article https: / / www.nuvoton.com / support / technical-support / technical-articles / TSNuvotonTechBlog-000154 / introduces "random delay and random change the order of processing flow", both of which will produce unpredictable system execution timing, as a countermeasure against fault injection attacks, explains that "letting attackers not easily understand the timing of the internal operation of the system will be an effective protection, the simplest method is to establish unpredictable system timing and processing flow, so that attackers are not easy to find the right attack time point, and not easy to attack the same key running point, and this can be achieved by random delay and random change the order of processing flow.

[0262] The term countermeasure (CM) used herein includes any mechanism, circuit, detector or other hardware or firmware or software that can be operated to detect and / or respond to an attack, such as by counterattacking or taking action against any danger or threat that has been or will be or can have or will have been caused by an attack. The countermeasure can include a mechanism, such as a temperature sensor or a fault detector triggered by an attack (also known as a "trap" or "trapdoor") that thus detects an attack; then the mechanism can also trigger appropriate actions, such as defense or resolution.

[0263] The CM can include any hardware, firmware, and even software, whether in whole or in part, triggered by an attack and / or triggering actions to protect the protected circuit, whether before the attack or during the attack, such as proactively or after the attack, such as retroactively.

[0264] The term "glitch" herein is intended to include the application of some external electrical, magnetic, laser, or other energy at a particular point in an integrated circuit or at an integrated circuit IO terminal / pin that interferes with the chip function in various possible ways, such as but not limited to causing a CPU to take a conditional branch that the CPU should not take, causing a logic state machine to make a state change that the logic state machine should not make, changing a state bit of a register or memory externally and intentionally, causing some chip logic to temporarily produce an incorrect (from the designer's perspective) logic result. The term "glitch" as used in the art is intended to include any transition that occurs on a signal. This typically occurs before the signal settles to its intended value, especially in digital circuits. Typically, a transition includes an electrical pulse of typically short duration, such as due to a race condition between multiple signals that can come from a common source but can have different delays. Certain electronic elements, such as flip-flops, require to be triggered by a pulse of at least a given length, otherwise the flip-flop (for example) does not work properly. In this case, a pulse shorter than the minimum length is also considered a glitch. Glitches can also include runt pulses, or pulses whose amplitude is less than the minimum level required for proper operation, and / or spikes, such as can be caused by ringing or crosstalk. Glitches can be harmless or well-tolerated in, for example, properly-timed synchronous circuits, but more often constitute an influence that leads to misbehavior and are therefore considered a fault or design error. The term glitch as used herein typically includes a transition that occurs on a signal and / or power / ground line and is introduced by an attacker with the intent of causing the integrated circuit to malfunction, and / or to cause the integrated circuit to perform or not perform certain operations, through their commission or omission respectively, resulting in an outcome that the attacker desires, such as revealing secret information, such as a social security number stored on the integrated circuit.

[0265] According to certain embodiments, a security system is configured to be deployed on a chip to be protected, the security system comprising at least one fault injection detection subsystem configured to be deployed on the chip, each fault injection detection subsystem having a plurality of real-time selectable sensitivity levels and comprising: at least one hardware fault injection detector circuit to be deployed on the chip, and coupled thereto, sensitivity level control logic to be deployed on the chip and operative in real-time to transition the fault injection detection subsystem from a present sensitivity level of the plurality of selectable sensitivity levels to a next sensitivity level of the plurality of selectable sensitivity levels by generating a sensitivity control signal (also referred to as a sensitivity level selection) and sending the sensitivity control signal to the at least one hardware fault injection detector in the subsystem.

[0266] It can be appreciated that any suitable mechanism can trigger the state change. The chip state transition can occur automatically by hardware, e.g., upon detecting inactivity, or can be triggered by firmware.

[0267] It can be appreciated that there can be one or more subsystems on the chip, and each of these subsystems can include one or more hardware fault injection detectors, one or more sensitivity level control logic circuits, each of which can be coupled to the one or more hardware fault injection detectors, and one or more functional modules, each of which can be associated with a different detector.

[0268] Any suitable implementation suitable for multiple sensitivity levels can be employed. Voltage fault detectors with multiple corresponding detection thresholds (e.g., as detailed or shown herein) can be used, or temperature sensors with multiple corresponding temperature detection thresholds.

[0269] The term "glitch detector" is intended to include any circuit that monitors the power line and is triggered each time the power level drops below X% (or Y mV) of the rated power level. Each time such a drop is detected, it can be due to a fault injected by an attacker trying to maliciously manipulate the chip's power.

[0270] The glitch detector can be triggered by a glitch on any power or signal that the glitch detector monitors. Similarly, a temperature sensor can be triggered when the temperature of a certain region of the chip on which the sensor is placed deviates from a (typically predefined) "normal" temperature range. Other events that can occur when the CM is triggered include, for example, stopping CPU execution and / or selectively resetting certain chip mechanisms and / or preventing access to certain memory regions and / or disabling the functionality of certain chip IO channels.

[0271] Another embodiment that provides countermeasures with multiple sensitivity levels is for a given subsystem to include multiple detectors, where a subset of the multiple detectors can be active, e.g., a subset of 25 out of 100 detectors can be active, or a second subset of 50 out of 100 detectors can be active, or a third subset of 75 out of 100 detectors can be active, thereby resulting in multiple (e.g., 3 in this case) sensitivity levels per subsystem at various different points in time.

[0272] More generally, the subsystem can comprise a plurality of detectors, and the sensitivity level of the subsystem at time t can be implemented as a number of the plurality of detectors that are enabled at time t, typically the sensitivity level control logic determines how many of the number of detectors are enabled at time t, thereby providing a countermeasure with a real-time configurable sensitivity level, such that a lower sensitivity level is implemented by a lower number of enabled detector circuits, and a higher sensitivity level is implemented by a higher number of enabled detector circuits.

[0273] A plurality of instances of hardware detector circuits that can detect fault injection attacks (e.g., glitch detectors, or temperature sensors or other countermeasures) can be distributed over at least a (typically predefined) portion of the chip to be protected, either uniformly, or using a predefined, intentional placement, depending inter alia on the location of functional modules of the chip and / or the security risk associated therewith.

[0274] Typically, the at least one fault injection subsystem further comprises at least one functional module deployed on the chip that generates an output signal in real-time and sends the output signal to the sensitivity level control logic, thereby providing the sensitivity level control logic with an indication as to the next sensitivity level to be selected from a plurality of selectable sensitivity levels.

[0275] For example, each functional module can comprise:

[0276] a cryptographic accelerator; and / or

[0277] a communication functional module (e.g., a Universal Asynchronous Receiver / Transmitter (UART), an I2C, a USB controller, or any (typically hardware) module) that uses a specific set of signals and follows a predefined protocol to communicate with another chip and / or another possibly deployed subsystem on the same system board; and / or

[0278] a peripheral function, such as a timer or a functional module that controls access to non-volatile memory, such as a one-time password, a watchdog timer, an interrupt controller, a DMA controller.

[0279] Each output signal generated by a given functional module typically indicates the current state of that functional module, or what state that functional module will be in (e.g., the state the functional module will transition to). For example, a functional module may include a processor core, where the processor core provides outputs indicating which instructions it will execute. A functional module may generate outputs indicating which state it will transition to (e.g., enabled or disabled). A functional module may generate outputs indicating that a specific activity (e.g., cryptographic activity) is about to begin being performed by the functional module or that the cryptographic activity may be about to end within the functional module.

[0280] Typically, when a module remains in the same state (each next state is unchanged relative to the current state), the output signal remains constant. In this case, the selected next sensitivity level can be the current sensitivity level, as long as it is influenced by the target module.

[0281] It is understood that a chip can include any suitable number of fault injection detection subsystems, each of which can include any suitable number of hardware fault injection detector circuits coupled to sensitivity level control logic, and can include any suitable number of functional modules. For example, Figure 9 It is a chip displaying a single subsystem on which a single functional module 91, sensitivity level control logic 92, and a single hardware error injection detector 93 are deployed. Figure 10 In the chip, a single fault injection detection subsystem is deployed, which includes three functional modules: 91a, 91b, and 91c. Figure 11 In the middle, a single fault injection detection subsystem is deployed on the chip, and... Figure 10 Similarly, the subsystem includes three functional modules: 91a, 91b, and 91c. Figure 11 The subsystem includes two hardware error injection detector circuits 93a and 93b. Figure 12 It shows a chip on which two subsystems are deployed, each of which includes three functional modules and a hardware error injection detector.

[0282] Therefore, if at least one / or more functional modules may include multiple functional modules, and the sensitivity level control logic can derive the next sensitivity level to be selected by combining the output indications from each of the multiple functional modules into a single set of sensitivity control signals.

[0283] Typically, each signal group includes a multi-bit sensitivity control signal.

[0284] Generally, a plurality of fault injection detection subsystems is provided, wherein each fault injection detection subsystem is configured to be deployed on the chip and comprises at least one hardware fault injection detector, and each fault injection detection subsystem is mutually coupled with sensitivity level control logic.

[0285] According to certain embodiments, the system is deployed on a protected chip, and the at least one functional module comprises at least a first functional module and a second functional module. Generally, the plurality of subsystems comprises a first subsystem and a second subsystem that respectively protect the first functional module and the second functional module, the first functional module being closer to the first subsystem than the second functional module, and the second functional module being closer to the second subsystem than the first functional module.

[0286] It will be appreciated that the fault injection is electrically and physically applied in the vicinity of the chip circuit targeted. It is therefore desirable that the functional module and the detector "in charge" of protecting this functional module are in mutual proximity to allow the detector (the fault injection detector circuit) to effectively intercept relevant activity that can be a fault injection attempt. If desired, the distance between a functional module and the detector of a given subsystem (e.g. to determine which functional modules are closer to which subsystems) can be defined as the distance between the location of the detector on the chip and the "weighted center" of the logic of the functional module, where the "weighted center" refers to a point in the logic of the functional module for which the square root of the sum of the square of the distance from this point to each cell contained in the functional module (e.g. to each logic gate contained in the given functional module, say 10k logic gates contained in the given functional module) is minimal relative to the similar square roots for all other points in the logic of the functional module.

[0287] Generally, at least one subsystem S of the plurality of fault injection detection subsystems protects at least one functional module on the chip. Generally, each individual detector of the respective hardware fault injection detectors from the plurality of subsystems has a sensitivity level that is selected in real time by the at least one functional module that the individual detector protects.

[0288] There can be an exclusive association between a particular functional module and a particular detector. However, in the general case, each functional module can influence (e.g. select a sensitivity level for) more than one detector, and each detector can be influenced by multiple functional modules, e.g. the sensitivity level of a given detector can be selected by combining the outputs produced by multiple functional modules that are generally protected by (e.g. within the detection range of) this detector.

[0289] Generally, each detector has a plurality of real-time selectable sensitivity levels.

[0290] According to certain embodiments, the sensitivity level control logic selects the controllable sensitivity level in real time as a function of at least in part whether the module on the certain chip is enabled.

[0291] For example, when the module on the certain chip is in an enabled state, the controllable sensitivity level can be selected by the sensitivity level control logic to be lower than the controllable sensitivity level selected by the mechanism when the module on the certain chip is not enabled.

[0292] And / or, for example, when the module on a given chip is in an enabled state, the controllable sensitivity level selected by the sensitivity level control logic can be higher than the controllable sensitivity level selected by the sensitivity level control logic when the module on the given chip is in a disabled state.

[0293] The module on the chip can include, for example:

[0294] a. a communication module that communicates, in operation, is deemed to be safety critical, for example a transmitter that can be used to transmit data deemed to be confidential outside the chip, or a receiver that can be used to receive data where the critical data affects the correct execution of the chip's mission.

[0295] b. a GPIO module deemed to be safety critical to control and monitor certain IO signals, for example to control the chip's output signals that enable certain functions outside the chip, where it is critical that these functions are not enabled unless a certain safety criterion is met, for example a successful password authentication.

[0296] c. a specific memory interface module deemed to be safety critical when handling a predefined memory region. For example, access to a given memory region used to store critical or secret information can be deemed to be safety critical. The region starts at address A and ends at address B; both can be editable. The decoder knows or determines that an address within the region is being accessed and can output a signal sent to the sensitivity level control logic in response, telling the sensitivity level control logic to increase its sensitivity level in order to produce a higher level of security when extracting data from that memory region.

[0297] d. a self-test module, for example a test of a certain memory array that is deemed to be safety critical when running. It can be understood that a memory error can lead to a safety issue, and therefore some conventional safety systems perform a self-test of certain units before starting to use the tested units. Interfering with such a self-test can lead to a false action of the safety system, whether non-serious or serious, depending on the importance of the tested unit.

[0298] A module is often considered critical or safety-critical if it has a significant impact on the security of the chip if it is interfered with or hacked, because it has a significant adverse impact on the operation of the chip, creating a risk.

[0299] It will be appreciated that the decision as to what is critical can be made at any suitable stage. For example, the architect of the chip can decide which elements or functional modules are critical, or can leave the freedom of decision to later stages, e.g. the designer of the system, who can then decide what to enable.

[0300] According to certain embodiments, the decision as to what is critical is edited and configured during the initialization of the integrated circuit, and then remains fixed by the operation of the design.

[0301] According to certain embodiments, e.g. for a system comprising a CM and a sensitivity control, the sensitivity can be set to a given value (e.g. the maximum value) until the firmware of the integrated circuit sets it otherwise. Since the configuration is a critical phase, this embodiment allows a highly protected configuration before releasing the CM to run at normal level, which is usually less secure than the security level set for the configuration phase.

[0302] According to certain embodiments, certain elements or functional modules are configured to have the ability to indicate to the sensitivity control whether they are currently enabled or not. For example, a given function such as a cryptographic accelerator can produce an output signal each time the accelerator actively performs a cryptographic activity. This output can be connected to the sensitivity level control logic, which can set the level of the countermeasures circuit sensitivity accordingly in response.

[0303] It will be appreciated that any suitable technique can be used to ensure that a given element or functional module knows whether it is enabled or not. For example, a cryptographic accelerator typically loads data to be processed, and then causes it to act by setting a "start" or "launch" bit. The accelerator can be considered as enabled once the data is loaded or once the start / launch is enabled, and not enabled until the data is loaded or until the start / launch is enabled. A communication module can know that it has started communicating when it reaches a state in its internal state machine (a.k.a. "transmission start" state), and that it is not enabled if the communication module is not in the "transmission start" state.

[0304] According to certain embodiments, at least one functional module is operable to produce and send at least one output signal to the sensitivity level control logic, the output signal comprising a status indication indicating whether the module is enabled or not. Typically, the logic selects the next sensitivity level as a function at least in part of the status indication.

[0305] According to certain embodiments, the next sensitivity level is selected as the given level if and only if the module is enabled. According to other embodiments, the next sensitivity level depends both on whether the module is in an enabled state or not, and on other factors, such as whether the module is a high-risk module or a low-risk module (which can for example require a somewhat lower sensitivity level even if enabled, relative to a high-risk module).

[0306] According to certain embodiments, the logic selects a higher next sensitivity level at least once in response to at least one individual module of the functional module becoming active.

[0307] According to certain embodiments, the logic releases to a lower level than the higher next sensitivity level at least once in response to at least one individual module becoming inactive.

[0308] It can be appreciated that a release to a lower sensitivity level can occur if no other module requires a higher sensitivity level, and can not occur if any other module does require a higher (e.g. current) sensitivity level. Conversely, a single module requiring an elevated sensitivity level can cause the sensitivity to be elevated to a higher level.

[0309] Thus, the system can take advantage of the fact that there are periods of time, typically of lower security risk, in 100% of the system's operating time, such as but not limited to periods of time that have been observed empirically to be less subject to hacking, and / or periods of time in which even if attacks do occur, they result in less negative consequences each time, and periods of time of higher security risk, such as but not limited to periods of time that have been observed empirically to be more subject to hacking, and / or periods of time in which attacks will result in more negative consequences each time. The system then limits the times in which the system is more sensitive to security threats to the second type of periods of time, thereby reducing the system's susceptibility to false positives overall, making the system more secure relative to the case in which the system has the highest sensitivity to fault injection at 100% of the time, while at the same time not impacting availability and usability.

[0310] According to certain embodiments, the at least one output signal is representative of a risk level associated with a current activity of the at least one functional module. Typically, the sensitivity level control logic derives the sensitivity level at least in part from the risk level, and selects that sensitivity level as the next sensitivity level.

[0311] Typically, the chip architect and chip designer will determine the appropriate risk level in advance (e.g., determine that cryptographic activity is the highest risk activity, etc.) and then design accordingly, providing state signals or output signals to the sensitivity level control logic for real-time monitoring, allowing the logic to adjust the sensitivity level control signal in real-time accordingly. For example, if it is desired to determine the sensitivity level based on whether a given module is in an active / inactive state, these modules can be designed to provide a single binary output signal that indicates (e.g., changes in real-time) whether the module is doing something, or whether it is idle at any given time. For multiple levels of risk rating, the designer can provide a decision for each of the multiple modules, such that the state of each module carries the relevant information.

[0312] According to certain embodiments, if the functional module is active and has a first level of risk, the logic selects a first sensitivity level as the next sensitivity level. If the functional module is active and has a second level of risk, the logic selects a second sensitivity level that is lower than the first level of risk as the next level of risk. If the functional module is not active, a third level of sensitivity is selected as the next sensitivity level.

[0313] It can be appreciated that any suitable number of risk levels can be provided, such as 2 or 3 or 4 or more risk levels, typically depending on the number of sensitivity levels provided by the chip design (or, the chip is designed to provide enough sensitivity levels to accommodate any risk rating solution that is desired).

[0314] It should be appreciated that an attacker can sometimes know when encryption activity is occurring, in which case it can be particularly important for the CM to be more sensitive in such cases, in order to provide better protection in such cases. Thus, according to certain embodiments, the sensitivity level control logic selects the controllable sensitivity level in real-time at least in part based on whether the chip is performing encryption acceleration.

[0315] According to certain embodiments, the functional module comprises a cryptographic module associated with a high risk level.

[0316] For example, when the CPU is performing encryption acceleration, the controllable sensitivity level can be forced by the sensitivity level control logic to be a higher sensitivity level than the controllable sensitivity level that is forced by the sensitivity level control logic when the CPU is not performing encryption acceleration.

[0317] The term "higher sensitivity" means that more events are judged to be fault injection than when the system is at a lower level of sensitivity. Typically, an attacker will try to study when a target device performs various operations (such as, but not limited to, cryptographic activity, sensitive communication activity such as transmitting a social security number or other sensitive data; accessing certain memory ranges - this is essentially another embodiment; performing certain security-related measurements / detections; the clock circuit is in a lock / adjust state) and then decide when to attack based on the goal the attacker wishes to accomplish. For example, if an attacker is trying to trick the system into thinking that a certain software (such as malicious software injected by the attacker) is authorized, although it is not, the attacker can choose to perform his attack at a time when he knows or believes that cryptographic activity is taking place. Typically, when cryptographic activity is performed, the system switches to a higher level of sensitivity, although this involves a higher level of false positives, and after the cryptographic activity is performed, the system switches back to a lower level of sensitivity.

[0318] According to certain embodiments, the sensitivity level control logic selects the controllable sensitivity level in real time depending at least in part on the power state of the chip.

[0319] When the CPU is in an idle power state, the sensitivity level control logic can select a controllable sensitivity level that is lower or higher than the controllable sensitivity level selected by the sensitivity level control logic when the CPU is in an active state. The system can force a first sensitivity level when idle and a higher second sensitivity level when active. For example, since there is less concern that the chip is under attack if it is in a sleep state. Or, the system can force a lower second sensitivity level when enabled, for example, since it is risky or undesirable to perform unnecessary fault detection remediation measures, which typically places a large burden on the normal operation of the chip.

[0320] According to certain embodiments, the CM is always active, but its sensitivity level varies over time, since the sensitivity level of the CM is sometimes automatically lowered by the hardware as shown and described herein.

[0321] It should be understood that the firmware is aware of some power state transitions, such as power state transitions triggered by the firmware, such as the firmware putting the chip in an idle state by writing something to a control register.

[0322] Accordingly, according to one embodiment, the functional module includes firmware that triggers transitions between possible power states, thereby causing the sensitivity level control logic to be aware of the current state.

[0323] It can be appreciated that the firmware can be aware of the power state transition even if the transition is not triggered by the firmware. For example, exiting a low power state is often triggered by hardware, such as a timer or an external event. In this case, the event can trigger an interrupt by which the firmware is notified to wake up.

[0324] In these cases, the firmware can be configured (e.g., by the firmware designer) to include a selection of a real-time sensitivity level that depends at least in part on the known current power state.

[0325] Alternatively, for example, if the firmware is not aware of certain changes in the power state, which are also referred to as transitions, a control signal can be generated, which can reduce the sensitivity level.

[0326] According to certain embodiments, the chip has a plurality of possible power states, including at least one idle state and at least one awake state. Typically, the logic selects the next sensitivity level in response to a new state of the chip, the new state including one of the plurality of possible states.

[0327] In this embodiment, the functional module can be referred to as a power management module or a power control module. This functional module typically does not generate or process anything or move anything from one place to another, but rather collects various indications present in the chip, thereby controlling the state of the chip and its modules. For example, upon detecting a specific, typically predefined, CPU instruction to "go to sleep", the power management or power control module (logic) can cause the chip to go to sleep and / or can disable certain other functions. Typically, the firmware will cause the chip to go to sleep. Upon executing such an instruction, the CPU can put itself to sleep and can also signal other parts or functional elements of the chip to sleep in response to the power management logic.

[0328] The next sensitivity level can be selected before the power state of the chip transitions to the new state. The detector can be set to the next sensitivity level before the power state of the chip transitions to the new state. The next sensitivity level can be selected after the power state of the chip transitions to the new state.

[0329] The detector can be set to the next sensitivity level after the power state of the chip transitions to the new state.

[0330] It should be understood that terms such as "force", "must", "need", and "require" refer to implementation choices made in the context of a particular implementation or application described herein for the sake of clarity, and are not intended to limit, as in another implementation the same elements can be defined as non-forced and non-required, and can even be eliminated altogether.

[0331] Features of the present application, including operations described in the context of separate embodiments, can also be provided in combination in a single embodiment. For example, system embodiments are intended to include corresponding process embodiments, and vice versa. Furthermore, each system embodiment is intended to encompass server-centric "views" or client-centric "views" or "views" from any other node of the system of the entire functionality of the system, computer-readable media, device, including only those functions performed on the server, client, or node. Features can also be combined with features known in the art, particularly those described in the Background section or in publications mentioned therein, without departing from the scope of the present application. Conversely, features of the present application, which include operations described in the context of single embodiments or in a certain order, can be provided alone or in any suitable combination with or in place of any of the features described herein, including features known in the art (particularly those described in the Background section or in publications mentioned therein) or in a different order. "Comprising" is used herein to represent an open-ended inclusion of the stated elements, and acts or operations "coupled" can represent that some or all of the functions of some of the elements are combined or shared in the combination. "For example" is used to indicate an embodiment that is not intended to be limiting. Each method can include some or all of the operations, in the order shown or described, as appropriate.

[0332] Although the present application has been described with reference to specific embodiments, it will be apparent to those skilled in the art that various modifications in form and details can be made without departing from the spirit and scope of the application. Accordingly, the disclosure is not intended to be limited to the specific embodiments set forth above. The scope of the disclosure includes processes, machines, manufacture, compositions of matter, means, methods, and steps for carrying out the same, substantially as recited in the claims, their combinations, and their equivalents. Accordingly, the disclosure is not intended to be limited to the specific embodiments set forth above. The scope of the disclosure includes processes, machines, manufacture, compositions of matter, means, methods, and steps for carrying out the same, substantially as recited in the claims, their combinations, and their equivalents.

Claims

1. A safety system, characterized by A security system for deployment on a chip to protect the chip, the security system comprising: at least one fault injection detection subsystem for deployment on the chip, wherein the fault injection detection subsystem has a plurality of sensitivity levels, wherein the fault injection detection subsystem comprises: at least one hardware fault injection detector circuit for deployment on the chip; and a sensitivity level control logic for deployment on the chip and operative in real time to transition the fault injection detection subsystem from a current sensitivity level of the plurality of sensitivity levels to a next sensitivity level of the plurality of sensitivity levels by generating a sensitivity control signal, and to send the plurality of sensitivity control signals to the at least one hardware fault injection detector circuit of the fault injection detection subsystem; the chip having a plurality of power states, the plurality of power states comprising at least one idle state and at least one wake state, wherein the sensitivity level control logic selects the next sensitivity level in response to a new state of the chip, the new state comprising one of the plurality of power states.

2. The safety system of claim 1, wherein, the at least one fault injection detection subsystem further comprising: at least one functional module for deployment on the chip, wherein the at least one functional module generates an output signal in real time and sends the output signal to the sensitivity level control logic, thereby instructing the sensitivity level control logic to select the next sensitivity level from the plurality of sensitivity levels.

3. The safety system of claim 2, wherein, the at least one functional module generates at least one output signal and sends the at least one output signal to the sensitivity level control logic, wherein the at least one output signal comprises a state indication to indicate whether the at least one functional module is active, wherein the sensitivity level control logic selects the next sensitivity level at least in part in dependence on the state indication.

4. The safety system of claim 3, wherein, the sensitivity level control logic selects a higher sensitivity level as the next sensitivity level at least once in response to at least one other functional module of the at least one functional module becoming active.

5. The safety system of claim 3, wherein, the at least one output signal represents a risk level associated with a current activity of the at least one functional module; wherein the sensitivity level control logic derives a sensitivity level as the next sensitivity level at least in part from the risk level.

6. The safety system of claim 5, wherein, the sensitivity level control logic selects a first sensitivity level as the next sensitivity level if the at least one functional module is active and has a first risk level, wherein the sensitivity level control logic selects a second sensitivity level as the next sensitivity level if the at least one functional module is active and has a second risk level, wherein the sensitivity level control logic selects a third sensitivity level lower than the first sensitivity level as the next sensitivity level if the at least one functional module is inactive.

7. The safety system of claim 2, wherein, the functional module comprises firmware to drive transitions between the plurality of power states, such that the sensitivity level control logic is aware of a current state of the chip operating in the plurality of power states.

8. The safety system of claim 1, wherein, The next sensitivity level is selected before the chip transitions to the new state.

9. The safety system of claim 8, wherein, The hardware fault injection detector circuit is set to the next sensitivity level before the chip transitions to the new state.

10. The safety system of claim 1, wherein, The next sensitivity level is selected after the chip transitions to the new state.

11. The safety system of claim 10, wherein, The hardware fault injection detector circuit is set to the next sensitivity level after the chip transitions to the new state.

12. The safety system of claim 1, wherein, The security system is deployed on the chip to be protected.

13. The safety system of claim 2, wherein, The at least one fault injection detection subsystem includes a plurality of fault injection detection subsystems, each of which is deployed on the chip, and each of which includes the hardware fault injection detector circuit and the sensitivity level control logic coupled to the hardware fault injection detector circuit.

14. The safety system of claim 13, wherein, The security system is deployed on the chip to be protected, wherein the at least one functional module includes a first functional module and a second functional module, and the plurality of fault injection detection subsystems includes a first fault injection detection subsystem and a second fault injection detection subsystem for protecting the first functional module and the second functional module, respectively, wherein the first functional module is closer to the first fault injection detection subsystem than the second functional module, and the second functional module is closer to the second fault injection detection subsystem than the first functional module.

15. The safety system of claim 13, wherein, At least one fault injection detection subsystem of the plurality of fault injection detection subsystems protects at least one functional module on the chip, wherein each hardware fault injection detector circuit of a corresponding plurality of hardware fault injection detector circuits of the plurality of fault injection detection subsystems has a sensitivity level selected in real time by at least one other functional module protected by each hardware fault injection detector circuit.

16. The safety system of claim 15, wherein, Each hardware fault injection detector circuit has a plurality of sensitivity levels that can be selected in real time.

17. The safety system of claim 1, wherein, The fault injection detection subsystem includes a plurality of hardware fault injection detector circuits, wherein the sensitivity level of the fault injection detection subsystem at a point in time is achieved by a number of hardware fault injection detector circuits of the plurality of hardware fault injection detector circuits enabled at the point in time, wherein the sensitivity level control logic determines how many of the plurality of hardware fault injection detector circuits to enable at the point in time; thereby providing a countermeasure with a sensitivity level that can be adjusted in real time, so that a lower sensitivity level is achieved with a smaller number of hardware fault injection detector circuits enabled, and a higher sensitivity level is achieved with a larger number of hardware fault injection detector circuits enabled.

18. The safety system of claim 2, wherein, The at least one functional module includes a plurality of functional modules, wherein the sensitivity level control logic derives a sensitivity level as the next sensitivity level by combining the output signals of each of the plurality of functional modules, and forms a set of sensitivity control signals.

19. The safety system of claim 4, wherein, The sensitivity level control logic selects a sensitivity level lower than the higher sensitivity level in response at least once to at least one other of the at least one functional module becoming active.

20. The safety system of claim 3, wherein, The functional module includes an encryption module, wherein the encryption module is associated with a high risk level.

Images