CN115146265A - Security system - Google Patents

Abstract

The present invention provides a security system configured on a chip to be protected, the system includes a fault injection detection subsystem configured on the chip, each fault injection detection subsystem has multiple real-time selectable sensitivity levels and includes At least one hardware fault injection detector circuit, and/or sensitivity level control logic coupled with the hardware fault injection detector circuit, may be deployed on-chip and operable in real-time to switch the fault injection detection subsystem from a plurality of selectable The current sensitivity level of the sensitivity levels is transferred to the next sensitivity level of a plurality of selectable sensitivity levels, such as by generating a sensitivity control signal (also known as sensitivity level selection) and/or sending a sensitivity control signal to the fault injection detection subsystem At least one of the hardware faults is injected into the detector circuit. Dynamically depending on the execution flow of the processor core, the fault injection countermeasure circuit operation is controlled to protect the processor from fault injection attacks.

Description

security system

technical field

The present invention is related to device security, and in particular to detecting fault injection attacks.

Background technique

Commonly owned US Patent 9,523,736 and its prior art describe prior art methods for identifying fault injection attempts.

Countermeasures with adjustable sensitivity levels may be known glitch detectors, which are known and described for example in the following http www link: invia.fr/detectors/voltage-glitch-detector.aspx. These are described as having "configurable detection thresholds"; and the following https links: hal.inria.f r/emse-01099006/document and "An In-depth and Black-box Characterization of the Effects of Clock Glitches on 8-bit MCUs" is a white paper describing fault injection research, available from IEEE.

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

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

"Electromagnetic fault injection: towards afault mod el on a 32-bit microcontroller" by Nicolas Moro et al. is a white paper describing fault injection research, available from IEEE.

The latest knowledge on surge attacks is described in "Implementing Practical Electrical Glitching Attacks" by the NCC Group, November 2015, available on the Internet at the following https www link: blackhat.com/docs/eu-15/materials /eu-15-Giller-Implementing-Electrical-Glitching-Attacks.pdf. Countermeasures in software, such as repeated instructions, are described by Thierno Barry, Damien Couroussé and Bruno Robisson, available via the Internet at the following https link: hal-cea.archives-ouvertes.fr/cea-01296572/document Written "Compilation of aCounterm easure against Instruction-Skip Fault Attacks" and "Low- CostSoftware Counterme asures Against Fault Attacks: Implementation and Performances Trade Offs".

Authentication mechanisms exist that operate based on tracking the execution flow of the CPU, such as commonly owned U.S. Patent No. 9,703,945.

Figure 1 of the prior art is taken from "Basic Operation of a 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.

This article https://www.nuvoton.com/support/technical-support/technical-articles/TS NuvotonTechBlog-000154/ describes "random delays and random changes in the order of running processes", both of which produce unpredictable systems Execution time as a countermeasure against fault injection attacks.

A generic glitch detector is described in US Patent 9,729,988B2 entitled "Glitch detection...", https://www.chipestimate.com/log.php?id=2 from=%2FInvia%2FVoltage-Glitch-Detector%2Fdatashe et%2Fip%2F30894&logerr=1, https://www.design-reuse.com/sip/glitch-detector-tsmc-n5-ip-48440/ and https://www.design-reuse.com/sip/glitch-detector-tsmc-n5-ip-48440/ It is described in /hal.archives-ouvertes.fr/lirmm-01096047/.

The disclosures of all publications and patent documents mentioned in the specification, as well as the disclosures of publications and patent documents directly or indirectly cited therein, are hereby incorporated by reference. The importance of such publications and patent documents to patentability is not hereby acknowledged.

SUMMARY OF THE INVENTION

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

Security systems are measured by false positive rates (aka false alarm rates) 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 typically 100% of the system's operating time is during periods of lower security risk, such as, but not limited to, those that have been empirically observed to be less vulnerable to hacking periods, and periods of higher security risk, such as, but not limited to, periods when greater vulnerability to hacking has been observed empirically. The system then limits the times when the system is more sensitive to security threats to the second type of time period, thereby reducing the system's overall susceptibility to false positives, making the system more secure and at the same time not affecting the time relative to setting the system at 100% Availability and usability with the highest sensitivity to fault injection.

Certain embodiments seek to provide a real-time adjustment of sensitivity levels with dynamic, eg, real-time operation, and with a response that is shorter than the decode-through-execution cycle of a single instruction of a CPU protected by a fault injection detector. Time error injection detector. Typically, detections are continuous, not intermittent.

Turning countermeasures on and off depending on the chip state, eg depending on whether the chip is active or sleeping, may or may not be known in the art. Certain embodiments shown and described herein seek to adjust sensitivity levels in real-time in order to provide protection against attacks in fine-tuned devices as well as the inherent trade-off at the cost of some false positives. Often, control of countermeasures is provided at the resolution of a single opcode, for example because a first sensitivity level, which may be a low sensitivity level, can be provided when the first opcode is detected, resulting in a detection that provides a lower level and suffers from a higher level of sensitivity. The first trade-off for a low level of false positives, while possibly providing a second sensitivity level that may be a higher sensitivity level upon detection of a second opcode imminent after the first opcode, yields Provides a higher level of detection and a second trade-off at the expense of a higher level of false positives.

Certain embodiments of the present invention seek to provide a security system and/or method and/or computer program product that dynamically controls a fault injection countermeasure circuit according to the execution flow of the CPU to protect the CPU from fault injection attacks. For example, a CPU or processor core may be provided which, when in use, generates in real-time an output indication of at least one conditional branch to be executed. Generally, the sensitivity level configuration module is operable to select the next sensitivity level higher than the sensitivity level configuration in response to the output indication of the conditional branch to be executed if at least one instruction other than a conditional branch is to be executed by the processor core At least one sensitivity level selected by the module.

At least the following embodiments are also provided:

Embodiment 1. A security system that dynamically controls a fault injection countermeasure circuit according to an execution flow of a processor core to protect the processor core from fault injection attacks, the system comprising:

i. The processor core executes instructions when in use and simultaneously generates in real-time output indications of at least some of the instructions to be executed;

ii. Fault injection detectors with multiple selectable sensitivity levels; and

iii. The sensitivity level control module operates in real time,

to receive output indications,

selects the next sensitivity level from a plurality of selectable sensitivity levels using sensitivity level selection logic that receives at least an output indication as input, and

Set the fault injection detector to the next sensitivity level,

Thereby a differential sensitive fault injection countermeasure circuit is provided that, when protecting processor cores from fault injection attacks, depends on the output indications of at least some instructions, avoiding if processor core protection is provided as sensitive independent of the output indications of at least some instructions at least one false positive caused by the level.

Embodiment 2. The system of any one of the preceding embodiments, wherein the sensitivity level control module responsively selects the next A sensitivity level, where the next sensitivity level above is higher than the sensitivity level of at least one instruction associated with having a risk level lower than R.

Embodiment 3. The system of any one of the preceding embodiments, wherein the sensitivity level control module responds when the sensitivity level control module receives an output indication that determines an individual instruction of the processor core returned from the interrupt handler to select the next sensitivity level, which is higher than the sensitivity level selected by at least one command other than the individual command.

Typically, when the CPU finishes executing the if statement, unless the upcoming opcode indicates that the upcoming instruction to be executed by the processor core is another conditional branch or the sensitivity level configuration module selects another opcode with a high sensitivity level, sensitivity resumes to a lower level. Typically, a signal is output indicating what the processor core is currently about to execute and the sensitivity level to be set accordingly by the sensitivity level configuration module. When the output indication of the next or upcoming opcode appears, the sensitivity level will again be adjusted accordingly, so it can remain the same or change, depending on whether the following opcode is the same as the previous one (or in logically corresponds, in terms of sensitivity level, which is exactly the same as the sensitivity level corresponding to the previous opcode).

Embodiment 4. The system of any preceding embodiment, wherein the sensitivity level control module responsively selects the next sensitivity The level is higher than the sensitivity level selected for at least one command other than the individual command.

Embodiment 5. The system of any one of the preceding embodiments, wherein the sensitivity level control module responsively selects the next The sensitivity level is higher than the sensitivity level selected for at least one command other than the individual command.

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

For example, execution mode changes may include in privileged mode (in which program code has access to certain restricted resources (eg, certain memory regions, certain hardware functions, or other specific resources)) and unprivileged mode (in which program code does not have access to certain resources) limit resources).

Embodiment 7. The system of any preceding embodiment, wherein when the sensitivity level control module receives an output indication of an individual instruction to read data from memory, the sensitivity level control module responsively selects the next sensitivity level to be Below the sensitivity level selected for at least one command other than the individual command.

Embodiment 8. The system of any of the preceding embodiments, wherein the processor core includes a memory, and when the sensitivity level control module receives data from the memory to read the data into a local storage device (eg, a cache or scratchpad) ), the sensitivity level control module responsively selects the next sensitivity level to be lower than the sensitivity level selected for at least one command other than the individual command when the output of the individual command is indicated.

Embodiment 9. The system of any preceding embodiment, 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 that the next sensitivity level is high On the sensitivity level selected for at least one command other than the individual command.

It should be appreciated that because conditional branches may be attractive targets for hackers looking for valuable targets to attack in a given program code, conditional branches may be associated with a high level of risk. For example, since the branch might lead the program code flow to the first option that grants the end-user secret, or to the second option that assumes the end-user is not authenticated without providing the secret, the conditional branch is very important for Could be an attractive target for hackers.

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

Embodiment 11. The system of any of the preceding embodiments, wherein the processor core includes adapted decoding logic that decodes individual instructions fetched from 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 adapted to provide the individual instruction prior to operation of the at least one unit in response to the at least one CPU internal signal derived from the individual instruction fetched from the program memory The output of the instruction indicates, allowing the fault injection detector to be set to the next sensitivity level before, rather than after, the execution of the individual instruction.

Embodiment 12. The system of any of the preceding embodiments, wherein the processor core decodes the opcodes to generate signals including instructions to execution units of the processor core and signals including signals output from the processor core. The output indication, the signal output from the processor core, is indicative of the instruction decoded from the opcode, thereby providing the sensitivity level selection logic with a preview of the instruction not yet executed by the processor core.

Embodiment 13. The system of any preceding embodiment, wherein the signal output from the processor core comprises an instruction decoded from an opcode.

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

Embodiment 15. The system of any of the preceding embodiments, wherein the processor core includes adapted decode logic that decodes individual instructions fetched from program memory at least once to derive at least one CPU internal signal , this signal then operates at least one unit CPU to execute the individual instructions, wherein for all instructions decoded by the decode logic, the decode logic is also used in the at least one unit in response to the individual instructions fetched from the program memory. Internal signals are preceded to provide output indications to operate individual instructions, ensuring that the fault injection detector is always set to each specific sensitivity level before, rather than after, the instruction that executes the sensitivity level logic to select the specific sensitivity level.

Embodiment 16. A security method for dynamically controlling a fault injection countermeasure circuit according to a processor core execution flow to protect the processor core from fault injection attacks, the method comprising:

i. Provide a processor core that, when in use, executes instructions and simultaneously generates in real-time output indications of at least some of the instructions to be executed;

ii. Provide fault injection detectors with multiple controllable sensitivity levels; and

iii. use the sensitivity level control module in real time,

receive output indication,

selects a next sensitivity level from a plurality of controllable sensitivity levels using sensitivity level selection logic that receives at least an output indication as input, and

Set the fault injection detector to the next sensitivity level,

Thus, when protecting the processor core from fault injection attacks, depending on the output indications of at least some instructions, a differential sensitive fault injection countermeasure circuit is provided to avoid problems if the CPU is protected at a sensitivity level that is independent of the output indications of at least some instructions. of at least one false positive.

Embodiment 17. The system of 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 the fault injection by the detector.

Embodiment 18. The method of any of the preceding embodiments, wherein the processor core includes adapted decoding logic that decodes individual instructions fetched from program memory at least once to derive at least one CPU internal Signals that subsequently operate at least one unit of the CPU to execute individual instructions, wherein the decoding logic is also used to perform signal operations before at least one unit performs signal operations in response to at least one CPU internal signal derived from the individual instructions fetched from program memory An output indication of the individual instruction is provided, allowing the fault injection detector to be set to the next sensitivity level before, rather than after, execution of the individual instruction.

Embodiment 19. The method of any one of the preceding embodiments, wherein the processor core decodes the opcodes using combinatorial logic to generate signals comprising instructions to execution units of the processor core and signals from the processor core. The core derives an output indication of a signal indicative of an instruction decoded from the opcode, thereby providing the sensitivity level selection logic with a preview of the instruction not yet executed by the processor core.

Embodiment 20. The system of any one of the preceding embodiments, wherein the processor core includes an execution pipeline including a plurality of sequential instructions having at least one overlapping stage, wherein the sensitivity level selection logic is based on an independent At least one instruction I, associated with the highest fault detection sensitivity level of the sensitivity levels, provides an indication to the fault injection detector for selecting the sensitivity level.

Overlapping stages may include decoding stages and/or execution stages.

Embodiment 21. The system of any one of the preceding embodiments, wherein since the highest detection sensitivity level is set to begin immediately after instruction 1 is decoded, it ends only after instruction 1 is fully executed, regardless of other instructions being decoded and Other instructions to be executed, so the at least one instruction I above, once decoded, takes precedence over all other instructions that are decoded and takes precedence over all other instructions to be executed.

Embodiment 22. The system of any of the preceding embodiments, wherein the processor core output indication comprises an output indication of which opcode is to be executed.

Embodiment 23. The system of any one of the preceding embodiments, wherein the fault injection detector described above is operable to protect the CPU from fault injection attacks, the decode-execution cycle of individual instructions of the CPU being T time units long , and where the fault injection detector has a response time shorter than T.

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

Embodiment 25. The system of any preceding embodiment, wherein the fault injection detector sounds an alarm if at least one of the detector units deployed at location L detects a fault injection attack at location L.

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

At least one fault injection detection subsystem is deployed on the chip, each fault injection detection subsystem has multiple real-time selectable sensitivity levels, including:

at least one hardware fault injection detector circuit, deployed on the chip,

Also, sensitivity level control logic coupled to the hardware fault injection detector circuit is deployed on the chip and operates in real time by generating sensitivity control signals (aka sensitivity level selection) and sending the sensitivity control signals to the fault injection detection subsystem at least one hardware fault injection detector circuit in the fault injection detection subsystem 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.

The fault injection detection subsystem may include any logic configured for fault injection attack detection, typically including identifying, in real-time, an attempt to tamper with a chip circuit, and warning of the attempt in real-time in response. The location of the detector generally indicates the location of the chip circuitry most likely to be attacked, and the nature of the detector generally indicates the type of attack, such as glitch, temperature, or others.

Embodiment 102. The system of any one of the preceding embodiments, and wherein the at least one fault injection detection subsystem further comprises at least one functional module configured to be deployed on a chip to generate output in real time signal, and sends an output signal to the sensitivity level control logic, thereby providing the sensitivity level control logic with an indication of the next sensitivity level to select from among a plurality of selectable sensitivity levels.

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

Embodiment 104. The system of any one of the preceding embodiments, wherein the logic sensitivity level control logic selects a next higher next function at least once in response to at least one individual function module of the plurality of function modules becoming active. Sensitivity level.

Embodiment 105. The system of any preceding embodiment, wherein the at least one output signal represents a risk level associated with the current activity of the at least one functional module, wherein the sensitivity level control logic is derived at least in part from the The risk level derives the sensitivity level as the next sensitivity level.

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

Embodiment 107. The system of any preceding embodiment, wherein the chip has a plurality of possible power states, the power states including at least one idle state and at least one awake state, and wherein the sensitivity level control logic is responsive to The next sensitivity level is selected based on the new state of the chip, which includes one of a number of possible states.

Embodiment 108. The system of any of the preceding embodiments, wherein the functional module includes firmware to trigger transitions between possible power states so that the sensitivity level control logic is aware of the current state.

Embodiment 109. The system of any preceding embodiment, wherein the next sensitivity level is selected before the power state of the chip transitions to the new state.

Embodiment 110. The system of any preceding embodiment, wherein the detector is set to the next sensitivity level before the power state of the chip transitions to the new state.

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

Embodiment 112. The system of any preceding embodiment, 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.

Embodiment 113. The system of any preceding embodiment, wherein the system is deployed on a chip to be protected.

Embodiment 114. The system of any preceding embodiment, 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 a chip and Each fault injection detection subsystem includes a hardware fault injection detector circuit and sensitivity level control logic coupled with the fault injection detection subsystem.

Embodiment 115. The system of any one of the preceding embodiments, wherein the system is deployed on a chip to be protected, wherein the at least one functional module includes at least a first functional module and a second functional module, and wherein the multiple Each fault injection detection subsystem 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 module is closer to the first fault than the second module An injection detection subsystem, the second module is closer to the second fault injection detection subsystem than the first module.

Embodiment 116. The system of any preceding embodiment, 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 a chip, wherein the plurality of fault injection detection subsystems The respective hardware fault injection detector circuit of each of the detection subsystems has a sensitivity level selected in real time by at least one functional module protected by the hardware fault injection detector circuit.

Embodiment 117. The system of any of the preceding Embodiments, and wherein each hardware fault injection detector circuit has a plurality of sensitivity levels selectable in real time.

Embodiment 118. The system of any preceding embodiment, and wherein the fault injection detection subsystem includes a plurality of hardware fault injection detector circuits, and wherein the fault injection detection subsystem is implemented at a sensitivity level at time point t enabling a number of hardware fault injection detector circuits for a plurality of hardware fault injection detector circuits at time point t, wherein the sensitivity level control logic determines to enable the plurality of hardware fault injection detector circuits at time point t how many in the circuit, thus providing countermeasures with real-time configurable sensitivity levels, thus lower sensitivity levels are achieved by a smaller number of enabled hardware fault injection detector circuits, and higher sensitivity levels are achieved by more The hardware fault injection detector circuit can be implemented.

Embodiment 119. The system of any preceding embodiment, wherein the at least one functional module includes a plurality of functional modules, and wherein the sensitivity level control logic derives by combining output indications from each functional module to be The sensitivity level selected as the next sensitivity level and forms a set of sensitivity control signals.

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

Embodiment 121. The system of any one of the preceding embodiments, wherein the functional module includes an encryption module associated with a high risk level.

It will be appreciated that, if desired, certain embodiments may be implemented as a computer program driven CM sensitivity control product comprising a computer program that is typically more real-time than the execution of the processor core to be protected. There is thus 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 being adapted to be executed to implement a security method dynamically dependent on the processing The execution flow of the processor core is controlled to control the operation of the fault injection countermeasure circuit to protect the processor from fault injection attacks, and the method includes:

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

ii. Provide fault injection detectors with multiple controllable sensitivity levels; and

iii. use the sensitivity level control module in real time,

receive output indication,

selects the next sensitivity level from a number of controllable sensitivity levels using sensitivity level selection logic that receives at least an output indication as input, and sets the fault injection detector to the next sensitivity level,

Thus, when protecting the CPU from fault injection attacks, fault injection countermeasure circuitry is provided to respond to the output indications of at least some of the instructions to avoid at least some of the instructions if the sensitivity level at which the CPU protection is provided is independent of the output indications of at least some of the instructions. A false positive. Furthermore, if the sensitivity level is set to avoid false positives entirely, the fault injection countermeasure circuit can detect at least one fault injection that would not have been detected if the sensitivity level providing CPU protection was independent of the output indications of at least some instructions.

The above-mentioned embodiments and other embodiments will be described in detail in the next paragraphs.

Any trademarks appearing in the text or drawings are the property of their owners and are shown here only to explain or illustrate one example of how an embodiment of the invention may be practiced.

Unless specifically stated otherwise, as will be apparent from the following discussion, throughout the discussion of the specification, it should be understood that the use of terms such as "processing," "calculating," "estimating," "selecting," "ranking," "ranking," "calculating," "determine", "generate", "re-evaluate", "classify", "generate", "generate", "stereomatch", "register", "detect", "associate", "superpose", "obtain" etc., means the operation and/or the action and/or process of converting data represented as physical by at least one or more computers or computing systems, or processors or similar electronic computing devices, such as registers and/or processes of computing systems or electronic quantities within a memory, converted to other data similarly represented as physical quantities within a memory, register or other such information storage, transmission or display device of a computing system. The term "computer" should be construed broadly to encompass any type of electronic device having data processing capabilities, including but not limited to personal computers, servers, embedded cores, computing systems, communication devices, processors (such as digital signal processors (DSPs) ), microcontrollers, Field Programmable Gate Arrays (FPGAs), Application Specific Integrated Circuits (ASICs, etc.) and other electronic computing devices.

Elements listed individually herein are not necessarily different elements, or may be of the same structure. A statement that an element or feature may be present is intended to include (a) embodiments in which the element or feature is present; (b) embodiments in which the element or feature is absent; (c) embodiments in which the element or feature is alternatively present, e.g. The user can configure or select the presence or absence of components or features.

The present security system dynamically depends on the execution flow of the processor core, and controls the operation of the fault injection countermeasure circuit to protect the processor from fault injection attacks.

Description of drawings

Some embodiments of the present invention are shown in the following figures:

Figure 1 is a prior art showing a typical CPU operating cycle, which in particular includes a process of extraction, followed by decoding, followed by execution.

2 is a simplified flowchart showing a method for building a system, according to some embodiments.

FIG. 3 is a simplified block diagram showing a security system, typically characterized in that instructions executed by a processor core or CPU are used to adjust the protection of the core from some attacks (such as executing high-level security systems believed to be hacked), according to some embodiments. Risky conditional branches or other parts of program code) are injected into a trigger that attacks the detector, and that trigger may trigger adjustments to the detector in real time, making it more sensitive.

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

5 is a schematic diagram showing a dynamic sensitivity level adjustment system according to some embodiments of the present invention, showing 3 levels of sensitivity, including a lowest sensitivity level defined as a preset level and two additional sensitivity levels above the preset level level.

FIG. 6 shows an embodiment of the fault detector of FIG. 5 .

FIG. 7 is a 3-level waveform diagram showing the instruction decode signal, combined risk level (eg, low, medium, or high), ie, a selected sensitivity level (eg, conservative, medium, or aggressive/highly sensitive); it will be appreciated that alternatively, Any number of levels except 3.

Figure 8 is a simplified schematic diagram showing a plurality of detector cells according to some embodiments of the present invention.

Figure 9 is a simplified diagram showing a single-single-single according to some embodiments of the present invention.

Figure 10 is a simplified diagram showing multiple-single-single according to some embodiments of the present invention.

Figure 11 is a simplified diagram showing a multiple single multiple embodiment according to some embodiments of the present invention.

Figure 12 is a simplified diagram of an embodiment comprising multiple single-unit assemblies showing construction and operation in accordance with further embodiments of the present invention.

Methods and systems encompassed within the scope of the invention may include some (eg, any suitable subset) of the functional blocks shown in any suitable order (eg, as shown in the figures) or in a specifically described implementation.

The computations, functions or logic components described and illustrated herein can be implemented in various forms, for example, as hardware circuits, such as, but not limited to, customized VLSI circuits or gate arrays, or programmable hardware devices, such as, but not limited to, FPGAs, Or as software program code stored on at least one tangible or intangible computer readable medium and executable by at least one processor or any suitable combination thereof. A specified source of functionality may be formed from a particular sequence of software program code or from a plurality of such software program codes that act together or behave or function as described herein with reference to the source of functionality discussed. For example, elements may be distributed over multiple sequences of program code, such as, but not limited to, objects, procedures, functions, routines, and programs, and may be derived from multiple computer files that generally operate in conjunction.

Any of the logic functions described herein may be implemented as a real-time application, where appropriate, and may employ any suitable architectural option, such as, but not limited to, an ASIC or a DSP, or any suitable combination thereof. Any hardware elements mentioned herein may actually include one or more hardware devices, such as chips, which may be co-located or remote from each other.

Reference number:

301: processor core

302: Fault Injection Detector

303: Fault Injection Improvement Circuit

91, 91a, 91b, 91c: Functional modules

92: Sensitivity level control logic

93, 93a, 93b: Hardware Error Injection Detector

21～24, 310～350: Step flow

Detailed ways

The following descriptions are examples of the present invention. Its purpose is to illustrate the general principles of the present invention, and should not be regarded as a limitation of the present invention, and the scope of the present invention should be governed by the claims.

It will be understood that although the terms "first," "second," "third," etc. may 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, and these terms are only used to distinguish between different elements, components, regions, layers, and/or sections. 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 present disclosure. and/or parts.

Notably, the following disclosure may provide multiple embodiments or examples for practicing various features of the present invention. The specific component examples and arrangements described below are only used to briefly and briefly illustrate the spirit of the present invention, and are not intended to limit the scope of the present invention. In addition, the following description may reuse the same symbols or words in multiple instances. However, the purpose of re-use is merely to provide a simplified and clear illustration, and not to limit the relationship between the various embodiments and/or configurations discussed below. Furthermore, descriptions in the following description of a feature being connected to, coupled to and/or formed on another feature, etc., may actually encompass a number of different embodiments, including direct contact of the feature, or including other additional The features are formed between the features, etc., such that the features are not in direct contact.

"Basic Operation of a DLX Machine" by Mike McDonald and Tony Jacobs, available online at the following httpswww internet link with html suffix: cs.umd.edu/class/fall2001/cmsc411/projects/DLX/proj. The above document describes five execution stages in the DLX architecture: Instruction Fetch (IF), Instruction Decode (ID), Execution (EX), Memory (MEM), and Write-Back (Write-Back) , WB). Each stage takes as much time as the slowest stage, even if it doesn't take that much time to complete. This time period is one clock cycle. Therefore, each instruction takes a total of 5 clock cycles to execute from start to finish. Each execution stage corresponds to the hardware in the CPU. Every "part" of the hardware on the data path can run concurrently, and pipelines take advantage of these to gain huge performance benefits. Each stage does very specific actions.

1. Instruction Fetch (IF): An instruction is read from memory and placed into an instruction register (IR). The new program counter (NPC) is updated to point to the next instruction (PC+4, or the next word in memory).

2. Execution (EX): Decode the instruction (based on the opcode). The scratchpad output from the scratchpad file is placed into the scratchpad. Sign-extending may be the instruction part of an immediate value and placing the value in a scratchpad.

3. Execution (EX): What happens here depends on the type of instruction that will be executed. The ALU runs during this cycle to perform the required operations.

Figure 1 is a prior art showing a typical CPU operating cycle, which in particular includes a process of extraction, followed by decoding, followed by execution.

A system for sensitivity adjustment of fault injection countermeasures will now be described in detail.

"If" statements or conditional branches are examples of CPU instructions that may be vulnerable to fault injection or "fault injection attacks", such as can be the target of fault injection, such as the point where program flow may be intentionally broken . For example, a conditional branch can be configured to jump to a portion of program code that provides some secret information to the user, based on a previous operation. For example, conditional on the user's previous operation successfully providing user authentication, or jumping elsewhere, or not jumping at all, in both cases the requested information is not provided to the user (if the user did not succeed in the previous operation). provide user authentication). In the latter case, a hacker may at some point attempt to inject a "bug" in an attempt to trick the conditional branch instruction to jump to program code that provides secret information, even though the user did not provide the necessary information in the previous operation user authentication.

According to some embodiments, a security system is provided wherein a processor core indicates an opcode/instruction to be executed when in use (eg, in real time). For example, when a CPU fetches an instruction from program memory, it typically decodes the instruction first. Decoding of an instruction typically involves logic functions that take an opcode as input, usually in binary form (an instruction opcode typically consists of numbers stored in sequence, usually as the binary program code of the corresponding program, which may be interleaved with the instruction operands) and an application logic function ( Also known as "decoding logic") generates the CPU internal signals used to operate the various units of the CPU to perform their respective functions, such as operating the ALU of the CPU to perform arithmetic operations, and so on. According to some embodiments, decoding logic may be used to output decoded signals to a sub-system (eg, a sensitivity level control module) external to the CPU, so that the sub-system, although external to the CPU, responds to a Actions to be taken with advance knowledge (eg selecting a sensitivity level).

It will be appreciated that in general, the built-in CPU decode logic is specifically designed to control a CPU's operational unit, such as the ALU, and the CPU does not "know" which instruction is going to be executed at any given time, based on the instruction being processed. Conversely, according to some embodiments, the decode logic output generally indicates which instruction will now be executed. Additionally, there may be overlapping control states within CPU instructions. For example, two (or N) different instructions of a family may have some of the same internal control because the two different instructions operate on the same CPU block.

A particular advantage of adapting decoding logic to communicate with external subsystems may be that since decoding precedes actual execution of the decoded instructions by the relevant CPU unit (e.g. ALU), external subsystems can preview instructions that have not yet been actually executed by the CPU.

It will be appreciated that some integrated circuits implement a low power mode. For example, the integrated circuit may enter a low power mode when it is detected that the core is executing some specific predefined instruction, for example, in some CPUs, a WAIT instruction or some other type of HALT instruction, or a Wait-For -Interrupt, all of which usually leave the CPU's cores in a holdover state, where the cores are usually held on hold, waiting for an event that triggers the core to exit that holdover state. This would involve a real-time indication of which opcode/instruction will be executed.

There are authentication mechanisms that operate based on tracking the execution flow of the CPU, such as commonly owned US Pat. No. 9,703,945. When a specific set of instructions is executed, execution flow may be paused to verify program code. Specifically, U.S. Patent 9,703,945 describes an authentication mechanism based on tracking the execution of a CPU's execution flow. U.S. Patent 9,703,945 describes specific operations or instructions (eg, accessing a specific space of memory-mapped I/O addresses). At the discretion of the system designer, these operations or instructions are considered to require a higher level of security in terms of program code verification. Therefore, when such an instruction is detected, such as a write to this I/O address space, the flow of execution is temporarily halted until a program code verification sequence completes. Once this is done, assuming the corresponding program code is authenticated, the execution flow will resume and the action will be executed. Therefore, the method is triggered by some instructions, changing the program flow to take some predefined action, i.e. program code verification.

Additionally, US Patent 9,703,945 describes a processing core coupled to receive program instructions from an input bridge and execute those program instructions, wherein the program instructions include program instructions capable of outputting a signal through an output bridge and not sent to one or more system outputs program instructions for data, and wherein the processing core may execute program instructions that do not send data to one or more system outputs both when the output bridge is in the first state and when the output bridge is in the second state.

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

Since different types of fault injection detectors are implemented using different mechanisms, various sensitivity control mechanisms can be employed to achieve sensitivity levels, such as but not limited to the following:

a. The fault injection detector can identify sudden changes, ie glitches in the supply voltage or ground level in the chip. In this case, the detector can be set to identify anomalies when the actual condition (actually detected voltage) differs from the expected voltage by 50mV, 100mV or 300mV.

b. Voltage level comparisons can be made between different locations on the same logic network to detect local differences, since all locations are expected to be in the same state.

c. The light detector is operable to attempt to identify fault injection using light energy, based on the resulting fault injection detection of a voltage level corresponding to the light intensity.

It is understood that the voltage levels of digital signals (assuming the same logic state (whether 1 or 0)) can be compared at any given time. In such a comparison, the trigger voltage difference can be defined as X, Y or Z.

Also, the sensitivity need not be based on voltage level at all. For example, detectors with non-voltage-based sensitivity levels might include:

The first is a detector designed to directly detect light (eg, laser, energy). If the detector converts the light energy to a voltage level proportional to the absorbed light energy, voltage levels A, B or C corresponding to light energy levels X, Y and Z, respectively, can be detected.

The second is a detector designed to directly detect electromagnetic energy other than light. Voltage levels A, B or C corresponding to electromagnetic energy levels X, Y and Z, respectively, can be detected if the detector converts the electromagnetic energy into a voltage level proportional to the absorbed electromagnetic energy.

An example of a detector with a non-voltage-based sensitivity level that does not operate in real time is a frequency deviation detector, which may have multiple sensitivity levels in the magnitude of the frequency deviation from the expected frequency. It should be understood that, in this case, the target of fault injection may include a chip clock that typically has a predetermined frequency (also referred to as "expected frequency"). For example, if a given chip's clock has an expected frequency of 250MHz, and an instantaneous deviation from this value, such as two clock pulses detected closer than expected, could indicate fault injection.

Some glitch detectors may be designed with multiple sensitivity levels selected by configuration and pre-defined and pre-configured according to system architectural decisions (as opposed to dynamic configuration in embodiments of the present invention).

Figure 2 illustrates a method of building a system that can receive opcode metrics from a processor core or CPU and make a corresponding sensitivity level decision in real-time, although other factors may also affect this decision, according to some embodiments of the present invention , and then the sensitivity level control is provided to the countermeasure circuit.

As mentioned above, there may be situations or conditions that security developers may deem to introduce a higher risk of hardware fault injection, such as, but not limited to, the execution of conditional branches.

In general, injected faults eventually translate into electrical events in the integrated circuit that interfere with the consistent and coherent operation of the integrated circuit hardware. For example, in the case of MCU/CPU executing program code, fault injection that attempts to interfere with the consistency and coherent operation of the integrated circuit hardware usually attempts 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.

In this case, security developers may want to dynamically use a different trade-off between security level and false positives.

Security developers can follow any suitable procedure when configuring logic. For example, the designer could first simulate and/or operate the device under expected normal real-life scenarios and permissible operating conditions to ensure that under permissive operating conditions the mechanism will never (or only with acceptable rarity) Trigger false alarms. The designer can then operate the device, given the fault injection the device is designed to withstand, and determine the level of fault injection detection that correctly triggers all or nearly all of the fault injection, e.g., at an acceptable reliability level. The designer can then define this "appropriate level" as a preset detection level for detecting fault injection. The designer can then adjust the logic to enable the selected higher sensitivity level (corresponding to slightly more aggressive detection in real time) in response to an output indication that the CPU is about to execute an instruction that the designer believes is associated with a higher risk of fault attack ).

Often, developers adjust the detection level to trigger (detection of an attack occurring) when operating conditions are indeed likely to cause the hardware to operate incorrectly. Such levels can be marked by developers on multiple device variants to ensure that little or no fault injection is detected during normal operation.

In general, it would be desirable to provide a circuit capable of detection at more than one designer-defined level, such as at least two detection levels, one of the two levels, but not the other, to risk unnecessarily interfering with the normal operation of the device. The next intercepts mild fault injection. These levels may include:

Level 1: Detect aggressive fault injection leading to abnormal conditions (eg, conditions that create a risk of device failure); and

Level 2: Detects not only aggressive fault injections, but also non-aggressive (also known as mild) fault injections, which cause unexpected conditions but the device can remain operational without a fault.

Referring to Figure 2, a processor is typically provided that generates a signal that indicates which instruction/opcode or family/group of opcodes is to be executed at each given moment in time. For example, from the time the processor's decoding unit identifies a subject instruction/command to the execution unit indicating that execution of the instruction/command is complete, a signal would indicate that the processor is about to execute a given instruction. In this embodiment, the indication includes the "decode" and "execute" phases of a given instruction, although this need not be the case. Alternatively, the signal may indicate that the given instruction is to be executed during the "execute" phase of the given instruction, rather than during the decode phase of the given instruction. Another possible embodiment is for the instruction to start from (and include) the "decode" stage of a host instruction until (but not including) the next instruction (an instruction executed after the processor executes the instruction preceding it). The "decode" stage remains active.

It will be appreciated that certain control signals (also known as CPU internal signals) that control the above cycle are part of the CPU's internal design, but are common to all or many CPUs, such as:

(a) a notification signal to notify the fetch unit to fetch the instruction from memory and store the instruction locally somewhere, and

(b) Signals generated by the decoding unit that assign or inform other CPU units to operate and execute instructions.

Furthermore, still as shown in Figure 2, system designers typically associate at least one opcode or set of opcodes with an associated security risk. In general, a conditional branch opcode is associated with a high risk R (R may be a scalar), relative to some or all opcodes that are not associated with a lower risk than R. This is because conditional branch instructions control the flow of the program and are therefore nodes where fault injection can divert the program from a correct and orderly flow.

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

For risk analysis, designers may study the processor's instruction set. An example description of the instruction set (ARM Cortex-M0) is available on the web at the following http link with html suffix: infocenter.arm.com/help/index.jsp?id=2 topic=/com.arm.doc.ddi0432c/CHDCICDF.

At least, since instruction sets tend to be similar between processors, at least between similar types of processors, such as between RISC processors or between CISC processors, to some extent this analysis can be Spread between processors. For example, many processors may have all or most of the following instruction types or groups:

1. Memory and scratchpad processing: usually include load instructions, store instructions, and move instructions.

2. Arithmetic and logical operations: usually include addition, subtraction, sometimes multiplication and division or arithmetic shifts, and logical operations such as OR, AND, XOR.

3. Stack management: usually push/pop.

4. Branch: Conditional and unconditional.

5. Control: such as but possibly not limited to state management, interrupt management.

Nonetheless, since each particular processor does tend to have at least a somewhat different instruction set from the others, some individual risk analysis of processors is eventually possible.

Designers can also review the application and how it is implemented (including analysis of the application code) and can quantify the risk of a specific instruction or instruction type accordingly. E.g:

a. a stack management instruction relative to at least one instruction other than the stack management instruction (and/or relative to the risk level associated with at least one instruction in at least one instruction group of at least one of the above instruction groups 3-5 and/or relative to opcodes considered low risk), can be considered high risk. For example, because stacks may also play a role in program flow, especially when subroutine calls are involved; stacks typically hold return addresses, so operating them through fault injection may also deviate a program from an orderly flow of execution.

b. In the instruction group for arithmetic/logical operations (Group 2 above), based on analysis of the program code, the system designer may find that the use of specific arithmetic instructions in "critical" locations in the program code affects program flow and/or The "decision" of the program code. These particular instructions may be associated with a high risk, eg higher than 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 above instruction groups 3-5 and / or higher than opcodes considered low risk.

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

Furthermore, still as shown in Figure 2, dynamic sensitivity level adjustment may be implemented in any suitable manner (e.g. selecting one of the L levels in real-time). For example, decoding logic may be provided that receives these signals from the processor and, depending on the security risk level of the opcode, generates a corresponding signal at any time to indicate to the fault injection detector whether it should be trigger. Figure 5 shows an embodiment showing a 3-level sensitivity comprising a minimum sensitivity level defined as a preset level and two additional levels both above the preset level.

According to some embodiments, the indication to the detector disappears immediately or immediately after decoding the instruction, so that the detector gets the signal before the core starts executing the instruction. The detection circuit itself generally does not "reject" or absorb or otherwise handle fault injection. However, the circuit does generate a flag to indicate that fault injection has occurred, allowing other modules to respond in any suitable manner, such as, but not limited to, restoring the device (such as a CPU or processor) to a known state and resuming the program to a known node in the process. This recovery can occur relatively slowly, for example only after fault injection occurs. However, since the damage from fault injection does not happen immediately, this is acceptable, unless recovery occurs only when it reaches a place in the program code that should not have been reached, and would not have actually reached if it were not for fault injection. before reaching this position in the program code.

The method of Figure 2 typically includes some or all of the following operations, appropriately ordered as follows:

Step 21. Provide to the processor core/CPU which is susceptible to fault injection and which generates a signal indicating which instruction/opcode or family/group of opcodes to execute at any given time.

Step 22. Perform risk analysis: The system designer associates security risks (eg, risk of error 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.

Step 23. Provide a fault injection detector with at least two sensitivity levels.

Step 24. Implement sensitivity level adjustment of the CM circuit, eg, provide a CM circuit that can adjust the sensitivity level in real time, eg, by dynamically selecting one of at least two levels. In general, fault injection detectors support dynamic adjustments, such as adjusting the sensitivity level in real-time and with a response time shorter than the decode execution cycle of a single instruction of the processor or CPU protected by the fault injection detector.

As mentioned above, the response time is generally short since the time period during which the control signal propagates through the sensitivity control unit to the detector is generally desired to allow sufficient time for the detector to react. For example: if the instruction cycle is 40ns long, then the time elapsed from the indication of the opcode until the detector is set at the desired sensitivity level is, say at most 10ns leaving a 30ns time window where the detector can be response within the time window.

Referring now to Figure 3, it can be understood that conditional execution and conditional branching, ie, software decision points, are considered weaknesses in secure program code, ie, nodes prone to fault injection attacks. FIG. 3 is a simplified block diagram showing a security system according to some embodiments, which may be provided according to the method of FIG. 2 . The system of Figure 3 typically includes:

a processor core 301 or CPU with an indication of an opcode or other program code that directs the execution of a particular instruction or class of instructions, such as, but not limited to, conditional branches, particular comparisons, etc.; and

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

For example, design issues on some examples of such circuits are described in the following white papers, all available on the web:

Compilation of a Countermeasure Against Instruction-Skip FaultAttacks

Thierno Barry, Damien Courouss_e, Bruno Robisson

as well as:

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

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

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

It will be appreciated that various instructions or classes thereof may be considered to introduce a higher risk of fault injection than instructions that are not so considered. To give some non-limiting examples, any or all of the following opcodes may be considered to introduce a higher risk of fault injection, which may lead to system design decisions that associate any or all of the following opcodes with a high security risk (e.g., a fault high risk of injection), i.e., the risk level is higher than that associated with the opcode (rather than the following and/or logic provided by increasing the sensitivity level of the fault injection detector when such an instruction is encountered), such as the following Opcode:

a. An opcode that indicates a conditional branch, e.g., a branch instruction of a RISC CPU that decides whether to branch or continue in order based on a comparison between the two operands preceding the conditional branch and producing a "result" branch that the conditional branch then uses branch-if-equal, branch-if-not-equal.

b. Opcodes that perform comparisons or other "tests" that cause various flags to be set, which are then used by logic that "decides" whether to take a given conditional branch. For example, compare instructions can be used to compare two operands and set a flag if they are equal (or if they are not). A subtraction operation can set a flag to compare operands, such as numbers, in the case that the result is negative or non-zero.

c. Opcodes push specific types of information onto the processor stack, such as critical or sensitive information or data or return addresses for CPU subsystem flags that are later used for conditional operations.

d. The opcode is characterized as a stop condition for implementing a loop. For example, loops are described in the archive provided by the following https www link, which has the htm suffix: tutorialspoint.com/assem bly_programming/assembly_loops.

The described loop instruction assumes that the loop counter is stored in a predetermined CPU register. When the CPU encounters a "loop" instruction, the CPU may decrement the loop counter, compare the loop counter to zero, and return to the start of the loop if the counter is greater than or equal to zero, thereby implementing a loop stop condition.

In some cases, it may not be known in advance which instructions are used, for example because the instructions used may depend on the choice of compiler for different CPUs. For example, a CPU might have a built-in instruction for a loop that handles a specified register or variable, automatically incrementing and decrementing that register or variable, and then jumping back to the beginning of the loop if the loop counter so dictates, or If the loop counter has elapsed let the program continue in sequence.

It should be appreciated that with respect to various instructions or categories thereof that are not so considered, there is a particularly low risk of fault injection compared to those that are so considered. To give some non-limiting examples, any or all of the following may be considered to introduce a particularly low risk of fault injection (which may result from system design decisions that associate any or all of the following opcodes with a low security risk, That is, the risk level is lower than the risk level associated with opcodes other than the following, and/or provide logic that reduces the sensitivity level of the fault injection detector when such instructions are encountered, thereby reducing false positives with little or no No adverse effects):

a. Load opcodes that only read data from memory or

b. Store opcodes that only store data in memory

While fault injection can cause the above problems to cause misbehavior, it is considered practically impossible for a hacker to define an effective attack based on interfering with specific store/load instructions.

FIG. 4 is a diagram illustrating a method of operation according to certain embodiments; eg, according to the method of FIG. 2 and/or the system of FIG. 3 .

The method of FIG. 4 typically operates in conjunction with core execution instructions, where the instructions are provided, decoded, and used in real-time to select the sensitivity level of the fault injection detector. Typically, a given sensitivity level is associated with each of multiple instructions or instruction families/groups. Often, the designer of a system associates a higher sensitivity level with instructions that are believed to be subject to a higher level of risk, based on the designer's risk assessment, such as from the point of view of a hacker finding a suitable target location for a fault injection attack. Targets that are considered attractive, conversely, lower sensitivity levels are associated with directives that are considered to have lower risk levels. Systems using the method of Figure 4 are typically constructed such that instructions are decoded and responded to in real-time. Instructions are set to the sensitivity level associated with or corresponding to the instruction that has just been decoded and is about to be executed. Next, in the time window between the decoding of the instruction and its execution by the core, setting the sensitivity level takes place.

The method of Figure 4 typically includes some or all of the following operations, ordered appropriately, for example: as shown:

At step 310, the CPU provides the opcode index I to the sensitivity level decision logic (also known as the sensitivity level selection logic) employed by the sensitivity level control module.

At step 320, the sensitivity level decision logic makes a decision that the sensitivity level of the CM circuit should be L_I.

In step 330, the sensitivity level control module sends a signal (or command) to the sensitivity level control module to adjust the sensitivity level of the CM circuit to L_I.

At step 340, the sensitivity level control module sends a sensitivity level control signal to the CM circuit.

At step 350, the CM circuit adjusts its sensitivity to L_I. For example, this level may be adjusted using a suitable selector unit whose control includes (or derives from) a sensitivity level control command indicating which opcode is to be executed.

5-6 are a 3-stage embodiment of a dynamic sensitivity level adjustment system according to certain embodiments. The design of the device is pre-analyzed, including the risk classification, and then during operation, the detector responds in real-time based on the previously made risk classification.

Specifically, FIG. 5 is a schematic diagram showing a dynamic sensitivity level adjustment system with 3 levels of sensitivity including the lowest sensitivity level defined as a preset level and two additional levels both above the preset level. FIG. 6 is a block diagram of the fault detector of FIG. 5 .

7 is a 3-level waveform diagram showing instruction decode signals, combined risk levels (eg, low, medium, or high) and selected sensitivity levels (eg, conservative, medium, or aggressive/highly sensitive), according to some embodiments; it should be understood However, any number of levels other than 3 can be used instead, and the preset levels as shown are not required.

In an embodiment execution pipeline of a CPU, as shown, if the pipeline is processing a "low risk" instruction as well as a "high risk" instruction, once the high risk instruction is decoded, the detector's Sensitivity level. For example, at the point where a "medium risk" fetch occurs, once the instruction is decoded, the (immediately) sensitivity increases. Similarly, when a "high risk" fetch occurs, the sensitivity increases further once the instruction is decoded. More generally, when the system of Figure 7 identifies a higher risk instruction than the one currently set, the newly decoded one has a (higher) risk priority until the CPU finishes processing the high risk instruction, then reverts to the previous command processing.

It should be known that "fetch" as shown in Fig. 7 includes "decoding", and for the sake of brevity, "fetch" shown in the figure can be interpreted as "fetching and decoding".

Refer to Figure 8. According to some embodiments, the fault injection detector includes multiple fault injection detector units respectively deployed in multiple locations in the processor core, as shown in the embodiment of FIG. 8, so that certain general faults are considered The location-dependent injection detector detects fault injection attacks at all multiple locations simultaneously. If at least one detector unit deployed at the first location detects a fault injection attack at the first location, the fault injection detector may issue an alarm (and/or may trigger fault injection amelioration actions applied to location L). Thus, an OR function (or any other suitable logical function) can be used to combine fault injection detection determinations made by individual cells of a plurality of cells. Any suitable number of cells may be provided with any suitable distance therebetween, generally determined by at least one of the following factors: the integrated circuit die area occupied by each cell, the physical characteristics of the integrated circuit being protected, and the expected failure Spatial features of injection attacks.

8 is a simplified schematic diagram of multiple fault injection detector cells deployed at various locations in a processor core and occupying multiple integrated circuit chip areas, respectively, according to some embodiments of the present invention.

For certain embodiments of the present invention, the usage patterns abound.

For example, commonly owned US Patent 9,523,736 describes detecting state differences between different branches of a given electrical grid. Electrical logic networks in integrated circuits are generally expected to be in the same state, such as a logic state of 1 or 0, through all branches. Therefore, when a difference in voltage level is detected between two physical points on the same logical (electrical) network, it is likely to represent a fault injection attempt resulting in a local change. A designer might think that a difference between that location and elsewhere (eg, 50mV between two points) is normal, a 300mV difference is abnormal enough to risk the IC's function, and a 200mV difference Although abnormal, it is not considered a risk. According to some embodiments, instead of just designing the detector to target 300mV, the detector depends on the level of change in sensitivity, a difference of 200mV or a difference of 300mV can be detected by virtual control as described herein, for example, a difference of 200mV can be detected in real time The detector sends a set control signal to set the detector to a sensitivity level of 200mV or a sensitivity level of 300mV. Thus, the system determines in real time whether to consider 50 mV or 200 mV or 300 mV as a difference, where a positive detection of the difference means that fault injection has been detected.

It is understandable that there may be other or more general usages of fault injection risk in addition to fault injection risk, which would justify adjusting the sensitivity level in real time. For example, it is believed that hackers will study and characterize the sensitivity of a given device they target to fault injection, possibly prior to a concentrated attempt by hackers to inject faults at very specific times and/or specific device locations. Changing sensitivity levels in real time, randomly or based on real-time detected risks, such as by associating specific directives with specific risk levels as described herein, may confuse or interfere with such research.

Furthermore, if the device detects a large number (over a threshold value) of fault injection attempts in real time during a specific operating cycle, eg, more than X detections are performed in Y time. For example, in 100% of the system uptime, there may be periods of lower security risk, such as but not limited to periods where hackers are empirically observed to be less prevalent, and periods of higher security risk, such as but not limited to Periods that are more popular with hackers are observed empirically.

Time-stamped events of detected fault injections can be recorded, after which appropriate program code can track fault injections over time and identify peripheral time periods with particularly high or low incidences of fault injections.

It will be appreciated that the fault detectors herein can be integrated into larger systems to improve their operation.

For example, it should be understood that the embodiments shown and described herein need not act as the only line of defense to make conditional branch operations more difficult to crack. Conversely, the fault detector described in this paper can be effectively combined with traditional anti-hacking techniques to combat fault injection vulnerabilities at the program code level, such as:

a. By preventing or preventing or reducing the occurrence or incidence of fault injection and/or

b. By circumventing or ameliorating the impact of fault injection, once it occurs,

Any of these can be triggered by the fault injection detection techniques shown and described here.

Any of the methods shown and described herein for detecting fault injection may be employed, and may add to or replace previous fault injection detection techniques used in previous systems including those operable to avoid or, once detected, Mods that improve the impact of fault injection. For example, the module can be activated when triggered by either of two or more fault injection detectors.

Generally, category b needs to detect fault injection. Thus, any anti-hacking measures in category b can be improved by using the improved, dynamically controlled fault injection detection methods shown and described herein.

Once fault injection is detected, eg, as shown and described herein, any suitable fault injection impact amelioration actions may thereby be triggered and may be performed responsively to ameliorate, eg correct, at least one impact, eg, the adverse effects of fault injection , for example but not limited to the following fault injection improvement actions:

a. Put the device in an irreversible state, preventing any further options.

b. Causes the processor to jump to a specified routine, such as performing an overall integrity check, and then usually resets or restarts the CPU.

c. Put the processor in an infinite loop until reset by the watchdog timer.

d. Stop the device until a specified period of time has passed.

e. After raising the sensitivity level for a certain period of time, if there is no further detection, the sensitivity will return to the preset value.

f. Disable certain pre-designated "risk" features for a period of time. Risky functions may be the approval of authentication, the disclosure of sensitive data, or the disclosure of encryption keys.

g. Suspend the system until an application power cycle is set or until a system or device hardware reset; watchdog timer reset or any other stop criterion or mechanism for releasing a stuck CPU.

It should be understood that the above-described fault injection amelioration operations are merely examples of functions that may be provided for modules designed to ameliorate the ill effects of fault injection attacks. Improving operation or functionality may include preventing or preventing or reducing the occurrence or rate of fault injection and/or avoiding or ameliorating the impact of fault injection once it occurs. It should be understood that the improved operations may be implemented in hardware and/or software and may utilize the program/data memory of the processor core.

It will be appreciated that more than one such fault injection improvement action may be performed. For example, operation e above might be combined with one of operations a–d or f–g.

Implement a series of conditional branches: e.g. one of many techniques used to make fault injection more difficult and therefore less likely, e.g. as per category a above, repeat a conditional branch n > 1 times, e.g. twice (n=2 ). In this case, the first branch jumps to the second branch, which is the branch that jumps to the final destination, two branches in n=2, or more generally, all n Branches are all based on the same condition. This solves the vulnerability, because here for the branch to be hacked, a single fault is not enough, instead a fault needs to be injected at each of two or more nodes, usually n nodes, which adds to the complexity of the hacking topic degree of execution process. It should be understood that the embodiments shown and described herein may be combined with other anti-hacking measures (eg, any suitable measures to improve, eg correct, at least one effect, eg, the undesirable effects of fault injection), if desired by the system designer. , which together make conditional branch operations harder to hack. The techniques above regarding "Implementing A Sequence Of Conditional Branches" prevent fault injection by making fault injection more difficult, and are therefore unlikely to be able to improve, for example, in combination with any suitable technique for ameliorating the effects or ill effects of fault injection. Effects or negative effects of faulty inputs. Suitable techniques may, for example, include detecting fault injection using any of the embodiments shown and described herein, and then implementing any suitable fault injection impact amelioration when fault injection is detected.

A known technique for better detecting fault injection (and thus better ameliorating its effects, such as by stopping the system until a power cycle is applied) is described in co-owned US Patent 9,523,736, which describes a Means for detecting fault injection include circuits across the body and high fan-out networks of circuits. During functional operation of the integrated circuit, the high fan-out network may remain inactive, and the circuit may be configured to detect signal levels at a plurality of sampling points in the high fan-out network and to detect signal levels based on the sensed signal levels. Detect signal anomalies in high fanout networks to identify fault injection attempts. The circuit may be configured to detect signal levels at multiple sampling points in the high fan-out network to distinguish between legitimate signal changes in the high fan-out network and Signal anomalies and identify fault injection attempts by detecting signal anomalies. The circuitry may be configured to modify one or more signal levels in the high fan-out network in response to identifying the fault injection attempt. Due to the setting of the ALERT signal, the control unit or sensor 48 may modify the signal level (e.g., force the signal to be active) on the net root 40 or another branch of the high fan-out net.

Another example is the detection of hardware glitches, such as power/ground glitches in integrated circuits caused by external sources (e.g., electromagnetic energy sources). Fault injection through power surges is a known method for hacking integrated circuit devices. Electromagnetic (EM) surges have been considered for many years as an effective fault injection technique to achieve physical attacks on integrated circuits. Circuits for detecting hardware surges that indicate fault injection vulnerabilities and "suffer" between security levels and false alarms (also known as false positives), including, for example, available over the Internet at Circuit obtained at the following http location: ieeexpl ore.ieee.org/document/5376828;

Zussa, L et al., "Efficiency of a glitch detector against electromagnetic fa ult injection" ieeexplore.ieee.org/document/6800417/

and at the following https www location: blackhat.com/docs/eu-15/materials/eu-15-Giller-Imple menting-Electrical-Glitching-Attacks.pdf.

The latest knowledge on 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 Obtained: www-users.math.umn.e du/~math-sa-sara0050/space16/slides/space2016121602-37.pdf. The proposed solution is tunable ("the sensor has bidirectional detection capability and the sensitivity of the back-end stage is tunable"). Also as noted elsewhere, the disclosure of this document, and indeed all documents cited herein, are hereby incorporated by reference.

It will be appreciated that the above-described detector may be enhanced by adding opcode response to dynamic sensitivity level adjustment using the embodiments described herein. The CPU design in the aforementioned "Cheap & Cheerful" publication is adaptable and can be adapted to provide an output signal indicating the instruction to be executed at any time. 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, depending on the level of sensitivity indicated by the decision logic shown and described here, only Select one of the outputs of one of multiple circuits in real time.

In general, any fault injection attack countermeasure known in the art is as follows:

"Compilation ofa Countermeasure Against Instruction-Skip Fault Attacks" by Thierno Barry, Damien Courousse, Bruno Robisson, available via the Internet at the following https location: hal-cea.archives-ouvertes.fr/cea-01296572/document ;as well as

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

Can coexist with embodiments of the present invention as complementary detection/protection layers. Together, this increases the overall degree of protection of a CPU or similar device from attacks, such as fault injection attacks.

It will be appreciated that analog circuits are often designed with tuning options, such as multiple detection levels/thresholds providing multiple sensitivity levels, so it may be difficult to predict in advance which levels/thresholds will be most effective in the actual electrical system environment. Generally speaking, once in a silicon circuit, testing is performed to determine which configuration works best, and then according to some embodiments, the circuit may be configured for a particular "best" or most feasible setup, rather than being configured as Settings for individual test selections. Instead, all or more than one of the multiple settings are retained, and as shown and described herein, control circuitry is added to select in real-time which of the multiple settings to use. A simple test can then be performed to reconfirm the circuit's performance in real silicon.

A particular advantage of the embodiments shown and described here is that the trade-off between the level of safety of fault injection detection and the degree of false positives is highly adjustable, even on a single opcode. By limiting the necessary but unfortunate high tolerance (or low security level) for false positives to those opcodes that require such a high tolerance, and hopefully reducing the false positive tolerance (or low security level) for all non- Opcodes with such high tolerance are required, allowing the trade-off to be overcome to a considerable extent.

It should be understood that the specific examples herein are not intended to be limiting. The present invention is intended to include any embodiment that operates, for example, in conjunction with a CPU or processor that has internally a signal that is the result of decoding an instruction to be executed. According to these embodiments, these signals are sent out of the CPU, thereby allowing at least one operating unit external to the CPU to take action based on the state of these signals to utilize signals available in one environment and designed for CPU-internal purposes for another Environment, usually used outside of the CPU Purpose is for a location or environment outside of the CPU. 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 may simultaneously (eg, in real-time) adjust the sensitivity of a fault injection detector function in a countermeasure circuit operable to counter fault injection attacks level (also known as security level).

If used to implement certain embodiments herein, the firmware may be stored in non-volatile memory, such as flash memory or ROM. Any suitable technique may be used to prevent firmware location constraints from interfering with the management of flash memory.

Alternatively, some of the embodiments described herein may be implemented in hardware, in part or alone (ie, without firmware), in which case some or all of the variables, parameters, sequential operations, and calculations described herein may be implemented in in hardware.

The term "Countermeasure (CM)" as used herein is intended to encompass any aspect of the operation of an on-chip circuit, which typically reacts to control signals in real-time, and is therefore typically implemented in hardware, which protects the CPU and/or the chip Any other operational function in the system or prevent fault injection attacks such as, but not limited to, power surge attacks, clock surge attacks, and signal surge attacks.

Some countermeasures are "evasive" because they confuse the enemy or attacker when and where to inject the fault; understandably, if the attacker is in the "wrong" (from an attack's point of view) place or time injection failure, the attack is less likely to have its intended effect.

For example, this article https://www.nuvoton.com/support/technical-support/technical-articles/TSNuvotonTechBlog-000154/ describes "random delays and random changes in the order of the processing flow", both of which can result in unreliable Predicted system execution timing, as a countermeasure against fault injection attacks, explains that "it will be an effective protection to prevent attackers from easily understanding the timing of the internal operation of the system. The easiest way is to establish unpredictable system timing and processing. The process makes it difficult for attackers to find a suitable attack time point, and it is not easy to continuously attack the same critical operation point, which can be achieved by random delay and random change of the order of processing processes.

The term countermeasure (CM) as used herein includes any mechanism, circuit, detector or other hardware or firmware or software operable to detect and/or respond to an attack, such as by countering or taking action to counter what was or will be or any danger or threat that may have been or will be caused by an attack. Countermeasures can include a mechanism such as a temperature sensor or a failure detector (aka a "trap" or "trapdoor") that is triggered by the attack so that the attack is detected; the mechanism can then also trigger an appropriate actions, such as defenses or resolutions.

A CM may include any hardware, firmware or even software, whether in whole or in part, that is triggered by an attack and/or triggers an action to protect a protected circuit, whether before or during an attack, e.g. proactively or after an attack, e.g. retrospectively.

The term "glitch" as used herein is intended to include the application of some external electrical, magnetic, laser or other energy at a specific point in an integrated circuit or at an IO terminal/pin of an integrated circuit, which may occur in various ways Interfering with the function of the chip in a way, such as but not limited to causing the CPU to take a conditional branch that the CPU should not take, causing the logic state machine (state-machine) to make state changes that the logic state machine should not make, and deliberately changing the temporary state bits of a register or memory that cause some chip logic to temporarily produce incorrect (from the designer's point of view) logic results. The term "glitch" as used in the art is intended to include any transition that occurs in a signal. This usually happens before the signal settles to its expected value, especially in digital circuits. Typically, transitions include electrical pulses of generally short duration, e.g. due to race conditions between multiple signals that may originate from a common source but may have different delays. Certain electronic components, such as flip-flops, need to be triggered by a pulse of at least a given length, otherwise the flip-flop (for example) will not function properly. In this case, pulses shorter than the minimum length are also considered to be glitches. Spurs may also include runt pulses, or pulses whose amplitude is less than the minimum level required for proper operation, and/or spikes such as may be caused by oscillations or crosstalk. For example, in a synchronous circuit with proper timing adjustment, glitch may be harmless or well tolerated, but in more cases it will constitute an effect that causes malfunction and thus be regarded as a fault or a design error. The term glitch as used herein generally includes transitions that occur on signal and/or power/ground lines and are introduced to an attacker with the purpose of causing the integrated circuit to fail and/or cause the integrated circuit to perform some operation , or inability to perform certain operations, through their commission or omission, respectively, to produce the attacker's desired result, such as revealing secret information to the attacker, such as a social security number stored on an integrated circuit.

According to certain embodiments, a security system is configured to be deployed on a chip to be protected, the security system including at least one fault injection detection subsystem configured to be deployed on the chip, each fault injection detection subsystem having a real-time A plurality of sensitivity levels are selected and include: at least one hardware fault injection detector circuit for deployment on the chip, and sensitivity level control logic coupled therewith, the sensitivity level control logic for deployment on the chip and operating in real time to pass generating a sensitivity control signal (also referred to as sensitivity level selection) to transition the fault injection detection subsystem from the current sensitivity level of the plurality of selectable sensitivity levels to the next sensitivity level of the plurality of selectable sensitivity levels, and converting the sensitivity control signal Sent to at least one hardware fault injection detector in the subsystem.

It will be appreciated that any suitable mechanism can trigger a state change. Chip state transitions can occur automatically by hardware, such as when inactivity is detected, or can be triggered by firmware.

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

Any suitable implementation suitable for multiple sensitivity levels may be employed. A voltage fault detector with a plurality of corresponding detection levels (e.g., as described or shown in detail herein), or a temperature sensor with a plurality of corresponding temperature detection thresholds, may be used.

The term "glitch detector" is intended to include any circuit that monitors the power line and triggers each time the power level falls below X% (or Y mV) of the rated power level. Every time this dip is detected, it may be due to a fault injected by an attacker trying to maliciously manipulate the chip's power supply.

The glitch detector can be triggered by (detecting) a glitch on any power supply or signal monitored by the glitch detector. Similarly, a temperature sensor can be triggered when the temperature of a certain area of the chip in which the sensor is placed deviates from a (usually predefined) "normal" temperature range. Other events that may occur when a CM is triggered include, for example, halting 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 .

Another example of providing a countermeasure with multiple sensitivity levels is that a given subsystem may include multiple detectors, where a subset of the multiple detectors may be active, for example only a subset of 25 out of 100 detectors. Can be active, or only a second subset of 50 detectors can be active, or only a third subset of 75 detectors can be active, resulting in multiple (eg 3 in this case) sensitivity levels.

More generally, a subsystem may include multiple detectors, and the sensitivity level of the subsystem at time t may be implemented as multiple detectors of multiple detectors enabled at time t, typically the sensitivity level controls The logic determines how many of the many detectors are enabled at time t, providing a countermeasure with real-time configurable sensitivity levels such that lower sensitivity levels are achieved with a smaller number of detector circuits enabled, and A larger number of enabled detector circuits achieves higher sensitivity levels.

Multiple instances of hardware detector circuits that can detect fault injection attacks (eg, glitch detectors, or temperature sensors, or other countermeasures) can be distributed over at least one (usually predefined) portion of the chip to be protected on top, either evenly distributed, or using predefined, intentional placements, depending in particular on the location of the functional modules of the chip and/or the security risks associated therewith.

Typically, the at least one fault injection subsystem also includes 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 information about the sensitivity level to be selected from a plurality of selectable sensitivity levels. The next sensitivity level indicates the sensitivity level control logic.

For example, each functional module may include:

cryptographic accelerators; and/or

A communication function module (for example, Universal Asynchronous Receiver/Transmitter (UART), I2C, USB controller, or any (usually hardware) module) uses a specific set of signals and follows a predefined protocol, with another chip and/or another possibly deployed subsystem to communicate on the same system board; and/or

Peripheral functions such as timers or function blocks control access to non-volatile memory such as one-time passwords, watchdog timers, interrupt controllers, DMA controllers.

Each output signal produced by a given functional module generally indicates the current state of the functional module, or what the state of the functional module will be (eg, the state the functional module will transition to). For example, a functional module may include a processor core, where the processor core is used to indicate the output of which instructions the processor core is to execute. The functional module may generate an output indicating which state the functional module is to transition to (eg, enabled and disabled). The functional module may generate an output indicating that a particular activity (e.g., a cryptographic activity) is about to begin to be performed by the functional module or that the cryptographic activity may be about to end in the functional module.

Typically, each time the module remains in the same state (every time the next state is unchanged relative to the current state), the output signal remains unchanged. In this case, as long as the next sensitivity level selected is affected by the target module, it can be the current sensitivity level.

It will be appreciated that a chip may include any suitable number of fault injection detection subsystems, each fault injection detection subsystem may include any suitable number of hardware fault injection detector circuits coupled to sensitivity level control logic, and may include Any suitable number of functional modules. For example, Figure 9 is a chip showing a single subsystem including a single functional module 91, sensitivity level control logic 92, and a single hardware error injection detector 93 deployed thereon. In FIG. 10, a single fault injection detection subsystem is deployed on the chip, and this subsystem includes three functional modules 91a, 91b, and 91c. In Figure 11, a single fault injection detection subsystem is deployed on the chip. Like Figure 10, the subsystem includes 3 functional modules 91a, 91b, 91c, while in Figure 11, the subsystem includes 2 hardware fault injection detectors Circuits 93a, 93b. Figure 12 shows a chip on which two subsystems are deployed and each subsystem includes 3 functional modules and a hardware error injection detector.

Thus, as at least one/or more functional modules may comprise multiple functional modules and the sensitivity level control logic may derive the to be selected by combining output indications from each of the multiple functional modules into a single set of sensitivity control signals the next sensitivity level.

Typically, each set of signals includes a multi-bit sensitivity control signal.

Typically, a plurality of fault injection detection subsystems are provided, wherein each fault injection detection subsystem is configured to be deployed on a chip and includes at least one hardware fault injection detector, and each fault injection detection subsystem interacts with sensitivity level control logic coupled.

According to some embodiments, the system is deployed on a protected chip, and the at least one functional module includes at least a first functional module and a second functional module. Generally speaking, the multiple subsystems include a first subsystem and a second subsystem that protect the first functional module and the second functional module respectively, the first functional module is closer to the first subsystem than the second functional module, and the second functional module is closer to the first subsystem than the second functional module. Closer to the second subsystem than the first functional module.

It should be understood that fault injection is applied electrically and physically in the vicinity of the targeted chip circuit. Therefore, it is desirable that the functional modules and the detectors "responsible for" protecting the functional modules are in close proximity to each other to allow the detectors (fault injection detector circuits) to effectively intercept related activities that may be fault injection attempts. If desired, the distance between functional blocks and detectors for a given subsystem (eg, to determine which functional blocks are closer to which subsystems) can be defined as the location of the detectors on the chip and the logical "weighted center of the functional block" ”, where “weighted center” refers to a point in the logic of a functional module, for which point, from that point to each unit contained in the functional module (e.g. to each logic gate in it (such as Say the square root of the sum of the squared distances of the 10k logic gates)) contained in a given functional module is minimal relative to the similar square root of all other points in the logic of the functional module.

Typically, at least one subsystem S of the plurality of fault injection detection subsystems protects at least one functional module on the chip. Typically, each individual detector of respective hardware fault injection detectors from multiple subsystems has a sensitivity level selected in real time by at least one functional module protected by the individual detector.

There may be an exclusive association between certain functional modules and certain detectors. In general, however, each functional module may affect (eg select a sensitivity level for) more than one detector, and each detector may be affected by multiple functional modules, for example, may be produced by combining multiple functional modules output to select the sensitivity level of a given detector by which these functional blocks are normally protected (eg, within its detection range).

Typically, each detector has multiple sensitivity levels that can be selected in real time.

According to some embodiments, the sensitivity level control logic selects the controllable sensitivity level in real time based on whether at least in part certain on-chip modules are enabled.

For example, when certain on-chip modules are enabled, the controllable sensitivity level may be selected by the sensitivity level control logic to be lower than the controllable sensitivity level selected by the mechanism when certain on-chip modules are disabled.

And/or, for example, when a given on-chip module is enabled, the controllable sensitivity level selectable by the sensitivity level control logic is higher than when the given on-chip module is disabled. The controllable sensitivity level selected by the control logic.

Modules on a chip can include, for example:

a. A communication module that communicates and is considered safety-critical when in operation, such as a transmitter, which can be used to transmit data that is considered confidential outside the chip, or a receiver, which can be used to receive data that is critical to the mission of the chip Do it correctly.

b. GPIO modules considered as safety-critical, used to control and monitor certain IO signals, such as the output signals of the control chip, these signals enable certain functions outside the chip, the key is that unless a specific safety standard, For example, password authentication is successful, otherwise these functions cannot be enabled.

c. A specific memory interface module that is considered safety-critical when dealing with predefined memory regions. For example, access to a given storage area for storing critical or secret information may be considered security critical. The area starts at address A and ends at address B; both can be editable. The decoder knows or determines the address within that 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 generate more information when fetching data from that memory region. High security.

d. A self-test module, such as one that tests a certain memory array that is deemed safety-critical when run. Understandably, memory errors can cause safety issues, so some conventional safety systems perform self-tests of certain units before starting to use the unit under test. Interfering with this self-test can lead to malfunction of the safety system, whether minor or severe, depending on the criticality of the unit under test.

If the module, when disturbed or hacked, would have a serious impact on the security of the chip, the module is generally considered critical or safety-critical because it would have a serious adverse effect on the operation of the chip, thereby creating a risk.

Understandably, decisions about what is critical can be made at any suitable stage. For example, the architect of the chip can decide which elements or functional blocks are critical, or can decide which elements or functional blocks (all or any subset of the elements or functional blocks of the chip) can be considered critical, the freedom to decide Degrees are left to later stages, such as the system designer, who can then decide what to enable.

According to some embodiments, decisions about what is critical are edited and configured during initialization of the integrated circuit, and then held fixed through the operation of the design.

According to some embodiments, such as for a system including a CM and sensitivity control, the sensitivity may be set to a given value (e.g., a maximum value) until the firmware of the integrated circuit is set otherwise. Since configuration is a critical stage, this embodiment allows for a highly secured configuration to be advanced before the CM is released to operate at the normal level, which is generally less secure than the security level set for the configuration stage.

According to some embodiments, certain elements or functional modules are configured with the ability to indicate to the sensitivity control whether they are currently enabled or disabled. For example, a given function, such as a cryptographic accelerator, may generate an output signal each time the accelerator is actively performing cryptographic activity. This output can be connected to the sensitivity level control logic, which can set the countermeasure circuit sensitivity level accordingly in response.

It should be understood that any suitable technique may be used to ensure that a given element or functional module knows whether it is enabled. For example, a cryptographic accelerator typically loads the data to be processed and then causes it to take action by setting a "start" or "start" bit. The accelerator may be considered enabled once data is loaded or once start/start is enabled, and not enabled until data is loaded or until start/start is enabled. When reaching a state in its internal state machine (aka "transfer started" state), the communication module can know that it has started communication, and if it is not in the "transfer started" state, that it is not enabled.

According to some embodiments, at least one functional module is operable to generate and send at least one output signal to the sensitivity level control logic, the output signal including a status indication indicating whether the module is enabled. Typically, logic selects the next sensitivity level based on at least part of the status indication.

According to some embodiments, the next sensitivity level is selected as a 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, but also on other factors, such as whether the module is a high-risk module or a low-risk module (which may, for example, require a slightly lower sensitivity level relative to a high-risk module , even if enabled).

According to some embodiments, the logic selects the next higher sensitivity level at least once in response to at least one individual module of the functional modules becoming active.

According to some embodiments, logic is released to a lower level than the next higher sensitivity level at least once in response to an individual module becoming inactive.

It is understandable that a release to a lower sensitivity level may occur if no other module requires a higher sensitivity level, and may not occur if any other module does require a higher (eg, current) sensitivity level to a lower sensitivity level. Conversely, a single module requiring an increased sensitivity level may result in a higher sensitivity level.

Thus, the system can take advantage of the fact that 100% of the system's operating time typically has periods of lower security risk, such as, but not limited to, periods when less hacking has been observed empirically, and/or even if Periods where attacks did occur but each attack resulted in fewer negative outcomes, and periods when there was a higher security risk, such as, but not limited to, periods of greater hacking that have been observed empirically and/or each attack would result in Periods of more negative outcomes. The system then limits the times when the system is more sensitive to security threats to the second type of time period, thereby reducing the system's overall susceptibility to false positives relative to the situation where the system has the highest sensitivity to fault injection 100% of the time , making the system more secure without compromising usability and usability.

According to some embodiments, the at least one output signal represents a risk level associated with the 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.

Usually, chip architects and chip designers will determine the appropriate risk level in advance (for example: determine that cryptographic activities are the highest risk activities, etc.), and then design accordingly to provide status signals or output signals for sensitivity level control logic for real-time monitoring, Allows the logic to adjust the sensitivity level control signal accordingly in real time. For example, if it is desired to determine the sensitivity level based on whether a given module is active/inactive, these modules can be designed to provide a single binary output signal indicating (eg changing in real time) whether the module is doing something, or whether it is in any Idle for a given time. For multiple levels of risk ratings, the designer can provide decisions for each of the multiple modules so that the status of each module carries relevant information.

According to some embodiments, if the functional module is active and has a first level of risk, the logic selects the 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 lower than the first level of risk as the next level of risk. If the function block is inactive, the third sensitivity level is selected as the next sensitivity level.

It will be appreciated that any suitable number of risk levels may 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 sufficient sensitivity levels) to accommodate any risk grading solution required).

It should be understood that attackers may sometimes know when cryptographic activity is taking place, in which case it may be especially important for the CM to be more sensitive in this situation in order to provide better protection in this situation. Thus, according to some embodiments, the sensitivity level control logic selects the controllable sensitivity level in real-time based at least in part on whether the chip is performing cryptographic acceleration.

According to some embodiments, the functional module includes a cryptographic module associated with a high risk level.

For example, when the CPU is performing cryptographic acceleration, the controllable sensitivity level may be enforced by the sensitivity level control logic to a sensitivity level higher than the controllable sensitivity level enforced by the sensitivity level control logic when the CPU is not performing cryptographic acceleration.

The term "higher sensitivity" means that more events are diagnosed as fault injection than when the system's sensitivity level is lower. Typically, attackers will try to study when the target device is performing various actions (such as but not limited to encryption activities, sensitive communication activities such as transferring social security numbers or other sensitive data; accessing certain memory ranges - this is basically for another One embodiment; perform some security-related measurements/detections; clock circuits are locked/adjusted), and then decide when to attack based on what the attacker wants to accomplish. For example, if an attacker tries to trick the system into thinking that a piece of software (such as malware injected by the attacker) is authorized, even though it is not, the attacker may choose to conduct his attack at a time he knows or believes to be cryptographic activity . Typically, when performing cryptographic activities, the system switches to a higher sensitivity level, although this involves a higher level of false positives, and after performing cryptographic activities, the system switches back to a lower sensitivity level.

According to some 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.

When the CPU is in an idle power state, the sensitivity level control logic may select a lower or higher controllable sensitivity level than the controllable sensitivity level selected by the sensitivity level control logic when the CPU is active. The system can enforce a first sensitivity level when idle and a second, higher sensitivity level when active. For example, since if the chip is dormant, there is less concern about it being attacked. Alternatively, the system may force a lower second sensitivity level when enabled, e.g. because it is risky or undesirable to perform unnecessary fault detection remedies, which often detract from the normal operation of the chip burden.

According to some embodiments, the CM is always active, but its sensitivity level changes over time, as the CM's sensitivity level is sometimes automatically reduced by the hardware shown and described herein.

It should be understood that some power state transitions are known to the firmware, eg power state transitions triggered by the firmware, eg the firmware puts the chip in some idle state by writing something to the control register.

Thus, according to one embodiment, the functional module includes firmware that triggers transitions between possible power states so that the sensitivity level control logic is aware of the current state.

Understandably, firmware can be aware of power state transitions even if the transitions are not triggered by 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 may trigger an interrupt that informs the firmware to wake up.

In these cases, the firmware may be configured (eg, by the firmware designer) to include a selection of real-time sensitivity levels that depend at least in part on the known current power state.

Or, for example, if the firmware is unaware of certain changes in power state, these changes aka transitions may generate control signals, which may reduce the sensitivity level.

According to some embodiments, the chip has multiple 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, which includes one of several possible states.

In this embodiment, the functional modules may be referred to as power management modules or power control modules. This functional module typically does not produce or process anything or move anything from one place to another, but instead collects various indications present in the chip, thereby controlling the state of the chip and its modules. For example, a power management or power control module (logic) may put the chip to sleep and/or may disable some other function upon detection of a specific, often predefined, "go to sleep" CPU instruction. Usually, firmware puts the chip to sleep. In executing such instructions, the CPU may place itself in a sleep state, and may also signal in response to the power management logic that other parts or functional elements of the chip may be placed in a sleep state.

The next sensitivity level can be selected before the chip's power state transitions to a new state. The detector can be set to the next sensitivity level before the chip's power state transitions to a new state. After the chip's power state transitions to a new state, the next sensitivity level can be selected.

After the chip's power state transitions to a new state, the detector can be set to the next sensitivity level.

It should be understood that terms such as "mandatory," "required," "required," and "must" refer to implementation choices made for clarity in the context of a particular implementation or application described herein, and are not used To limit, because in another implementation, the same elements may be defined as optional and optional, and may even be eliminated altogether.

Features of the invention, including operations that are described in the context of separate embodiments, may 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 include a server-centric "view" or a client-centric "view" of the entire functionality of the system, computer-readable medium, device, or "view" from any other node of the system ", including only those functions performed on that server, client, or node. Features may also be combined with features known in the art, in particular but not limited to those described in the Background section or in the publications mentioned therein. Rather, features of the invention, including operations that are described for brevity in the context of a single embodiment or in a specific order, may be provided separately or in any suitable subcombination, including features known in the art (in particular but not limited to those described in the Background section or the publications mentioned therein) or in a different order. "For example" is used to denote an embodiment that is not intended to be limiting. Each method may include some or all of the operations shown or described, in a suitable order, e.g., as shown or described herein.

Although the embodiments of the present disclosure and their advantages have been disclosed above, it should be understood that any person skilled in the art can make changes, substitutions and modifications without departing from the spirit and scope of the present disclosure. In addition, the protection scope of the present disclosure is not limited to the process, machine, manufacture, material composition, device, method and steps in the specific embodiments described in the specification, and any person skilled in the art can learn from the disclosure content of some embodiments of the present disclosure. It is understood that processes, machines, manufacturing, material compositions, devices, methods and steps developed in the present or in the future can be implemented according to the present disclosure as long as they can implement substantially the same functions or obtain substantially the same results in the embodiments described herein. Example use. Therefore, the protection scope of the present disclosure includes the above-mentioned processes, machines, manufactures, compositions of matter, devices, methods and steps. In addition, each claimed scope constitutes a separate embodiment, and the protection scope of the present disclosure also includes the combination of each claimed scope and the embodiments.

Claims (21)

1. 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 disposed on the chip; and

a sensitivity level control logic disposed on the chip and operative in real-time to convert 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 sending the sensitivity control signals to the at least one hardware fault injection detector circuit in the fault injection detection subsystem.

2. The safety system of claim 1, wherein the at least one fault injection detection subsystem further comprises:

at least one functional module disposed 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 security system of claim 2, wherein the at least one function module generates at least one output signal to the sensitivity level control logic, wherein the at least one output signal includes a status indication indicating whether the at least one function module is active, wherein the sensitivity level control logic selects the next sensitivity level based at least in part on the status indication.

4. The security 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 respective one of the at least one functional module becoming active.

5. The security 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 function 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 function module is active and has a second risk level, and 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 function module is inactive.

7. The security system of claim 2, wherein the chip has a plurality of power states including 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 including one of the plurality of power states.

8. The security system of claim 7, wherein the functional module includes firmware that drives transitions between the plurality of power states such that the sensitivity level control logic knows that the chip is operating in a current one of the plurality of power states.

9. The security system of claim 7, wherein said next sensitivity level is selected before said chip transitions to said new one of said plurality of power states.

10. The security system of claim 9 wherein said hardware fault injection detector circuit is set to said next sensitivity level before said chip transitions to said new state.

11. The security system of claim 7, wherein said next sensitivity level is selected after said chip transitions to said new state.

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

13. The security system of claim 1, wherein said security system is disposed on said chip to be protected.

14. The safety system of claim 2, wherein the at least one fault injection detection subsystem comprises a plurality of fault injection detection subsystems, wherein each of the plurality of fault injection detection subsystems is configured to be disposed on the chip, and wherein each of the plurality of fault injection detection subsystems comprises the hardware fault injection detector circuit and the sensitivity level control logic coupled to the hardware fault injection detector circuit.

15. The security system of claim 14, wherein the security system is disposed on the chip to be protected, wherein the at least one functional module comprises a first functional module and a second functional module, wherein the plurality of fault injection detection subsystems comprises 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.

16. The safety system according to claim 14, 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 the 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 respective functional module protected by said each hardware fault injection detector circuit.

17. The safety system of claim 16, wherein each of said hardware fault injection detector circuits has said plurality of sensitivity levels selectable in real time.

18. The safety system of claim 1, wherein the fault injection detection subsystem comprises a plurality of hardware fault injection detector circuits, wherein the sensitivity level of the fault injection detection subsystem at a point in time is implemented by a number of the plurality of hardware fault injection detector circuits that are enabled at the point in time, wherein the sensitivity level control logic determines how many of the plurality of hardware fault injection detector circuits are enabled at the point in time; thus, a countermeasure is provided having a sensitivity level that is adjustable in real time such that a lower sensitivity level is achieved with a smaller number of hardware fault injection detector circuits, and a higher sensitivity level is achieved with a larger number of hardware fault injection detector circuits.

19. The security system of claim 2, wherein said at least one functional module comprises a plurality of functional modules, and wherein said sensitivity level control logic derives a sensitivity level as said next sensitivity level by combining said output signal of each of said plurality of functional modules and composes a set of sensitivity control signals.

20. The security system of claim 4, wherein the sensitivity level control logic selects a sensitivity level that is lower than the higher sensitivity level at least once in response to at least one individual functional module of the at least one functional module becoming active.

21. A security system according to claim 3, wherein said functional module comprises a cryptographic module, wherein said cryptographic module is associated with a high risk level.

Images