This disclosure relates generally to data processing, and more particularly, to a countermeasure for protecting against a fault injection attack in a data processing system.
Some fault injection attacks are non-invasive attempts to inject a “glitch” into a device in order to change program execution in the device. A glitch may be a power supply or other voltage glitch, a clock glitch, electromagnetic fault injection (EMFI), or the like. The attacker may attempt to inject the glitch at a particular point in program execution to cause the program execution to take a wrong branch, to skip a step of the program, or some other wrong decision. The glitch attack may allow an attacker to skip a mathematically complex cryptographical operation such as a signature verification during a secure booting process, and thus execute unauthorized code or gain access to a secure data processing system.
The present invention is illustrated by way of example and is not limited by the accompanying figures, in which like references indicate similar elements. Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale.
Generally, there is provided, a method for protecting execution of a program against a fault injection attack. The method includes executing multiple instances of a conditional branch operation multiple times in a sequence. For example, the conditional branch operation may be an if-then-else statement. As an example, an if-then-else conditional operation may ask the question: does A=B? If the answer is yes, in one implementation, program execution proceeds to the next state, else program execution returns to a previous state. In one example, the if-then-else conditional branch is implemented twice in sequence, where the condition is identical in both conditional operations. If an attacker causes a glitch to happen at the first instance of the conditional branch and successfully causes the conditional branch to be skipped, the program execution proceeds to the second instance of the if-then-else conditional branch and the attacker must inject a glitch at the correct time that also causes the program execution to skip the second instance and proceed to the next state. The likelihood that an attacker will be successful twice in succession is very low because two separate glitches may not affect the two decisions the same way. Alternatively, the conditional statement may be logically the same, but the implementation of the conditional statement may be different. The different implementation may behave differently if the same glitch is injected twice. In addition, for additional resistance to a fault injection attack, another embodiment determines if a current state was reached from a valid previous state. The valid previous state may be stored in an assigned register bit field. In a further embodiment, the same conditional operation in a subsequent program execution may be executed a final time where a correct decision allows program execution to remain in a final state, and a wrong decision requires the program execution to return to a previous state. In one embodiment, the previous state is the initial state. This may prevent an attacker from doing too much damage in the event the attacker is successful bypassing the previous conditional operation. Depending on the sensitivity of the data to be protected, and on the sophistication of the attacker to be protected against, more intermediate conditional operations and states can be added to the program.
In accordance with an embodiment, there is provided, a method for protecting execution of a program against a fault injection attack in a data processing system, the method including: executing a first conditional operation while the program execution is in a first state, wherein when an evaluation of a condition of the first conditional operation is true, the program execution proceeds forward from the first state to a second state, and wherein when an evaluation of the first conditional operation is false, program execution remains at the first state; and executing a second conditional operation while the program execution is in the second state, wherein a condition of the second conditional operation is substantially the same as the condition of the first conditional operation, wherein when an evaluation of the condition of the second conditional operation is true, the program execution proceeds forward from the second state to a third state, and wherein when an evaluation of the condition of the second conditional operation is false, program execution returns to the first state. The method may further include checking that the program execution arrived in each of the first, second, and third states from an allowed previous state, wherein if the program execution is determined to have arrived at the third state from an allowed previous state, the program execution can remain in the third state, and if the program execution is determined to have arrived at the third state from an unallowed state, the program execution returns to the first state. The allowed previous state may be stored in a register bit field and wherein checking that program execution arrival in the third state is from the allowed previous state further comprises checking the register bit field for the allowed previous state. The register bit field may store a program counter value for the allowed previous state. The method may further include executing a third conditional operation from the third state, wherein a condition of the third conditional operation is identical to the condition of both the first and second conditional operations, wherein when an evaluation of a condition of the third conditional operation is true, the program execution stays in the third state, and wherein when an evaluation of the condition of the third conditional operation is false, program execution goes back from the third state to the first state. The method may be implemented as instructions stored on a non-transitory machine-readable storage medium. The first and second conditional operations may be logically identical if-then-else operations having different implementations. The method may further include: performing the steps of executing using a first state machine in the data processing system; performing the steps of executing using a second state machine in the data processing system; and determining that the first and second state machines both reach the third state via the second state. The first state machine may be a software state machine and the second state machine may be a secure hardware state machine. The method may further include executing a third conditional operation from the third state in both the first and second state machines, wherein when a condition of the third conditional operation is true, the program execution stays in the third state, and wherein when the condition of the third conditional operation is false, program execution goes returns to the first state.
In another embodiment, there is provided, a method for protecting execution of a program against a fault injection attack in a data processing system, the method including: executing a first conditional operation while the program execution is in a first state, wherein when a condition of the first conditional operation is true, the program execution proceeds forward from the first state to a second state, and when the condition of the first conditional operation is false, program execution remains at the first state; executing a second conditional operation while the program execution is in the second state, wherein a condition of the second conditional operation is substantially the same as the condition of the first conditional operation, wherein when the condition of the second conditional operation is true, the program execution proceeds forward from the second state to a third state, and when the condition of the second conditional operation is false, program execution returns to the first state; and executing a third conditional operation while the program execution is in the third state, wherein a condition of the third conditional operation is substantially the same as the condition of the first and second conditional operations, wherein when the condition of the third conditional operation is true, the program execution stays in the third state, and when the condition of the third conditional operation is false, the program execution returns to the first state. The method may further include checking that the program execution arrived in each of the first, second, and third states from an allowed previous state, wherein if the program execution is determined to have arrived at the third state from an allowed previous state, the program execution remains in the third state, and if the program execution is determined to have arrived at the third state from an unallowed state, the program execution returns to the first state. The allowed previous state may be stored in a register bit field of the data processing system and wherein checking that program execution arrival in the third state is from the allowed previous state may further include checking the register bit field for the allowed previous state. The register bit field may store a program counter value for the allowed previous state. The first, second, and third conditional operations may be executed in a sequence. The first, second, and third conditional operations may be logically identical if-then-else operations and at least one of the first, second, and third conditional operations is implemented differently from the other two. The method may further include: performing the steps of executing by a first state machine in the data processing system; performing the steps of executing by a second state machine in the data processing system; and determining that the first and second state machines both reach the third state via second state. Performing the steps of executing by the first state machine may further include performing the steps with a software state machine, and wherein performing the steps of executing of the second state machine may further include performing the steps with a secure hardware state machine. The steps of performing and determining may be executed in parallel by the first and second state machines. The method may be implemented as instructions stored on a non-transitory machine-readable storage medium.
Conditional state transition 10 is a transition from a first state (STATE 1) 12 to a second state (STATE 2) 14 conditioned on the outcome of a conditional operation 16 (shown as a decision block). As an example, conditional operation 16 requires a decision between two paths conditioned with the comparison of two values A and B. If A equals B, program execution proceeds as indicated by the YES path from STATE 1 to STATE 2. However, if A does not equal B, program execution does not proceed and remains at STATE 1 as indicated by the NO path. Hardware logic or software code can be used to implement the functionality of conditional operation 16. Conditional operations like conditional operation 16 are frequently targeted in a glitch attack as indicated by glitch 18. A goal of the attack may be to cause program execution to proceed from STATE 1 to STATE 2 even when, for example, A does not equal B, thus potentially skipping the need to correctly perform a complex security protocol, such as a signature verification, to execute unauthorized code or gain access to a device. This may be accomplished by the attacker using a single well-timed momentary glitch 18.
Program execution according to the embodiment of
Also, as the program progresses through states 42, 46, and 50, the program may check at each state if arrival at the current state is from an allowed previous state. To do this, the previous state location, such as a program counter value, is stored in a register bit-field. If a check of the register bit-field during program execution indicates that a transition was not valid, then an exception may be raised, and program execution returns to the initial state (STATE 1).
Memory 106 may include multiple and different types of memory. Memory 106 may include a data memory and instruction memory. Memory 106 may be any kind of memory, such as for example, L1, L2, or L3 cache or system memory. Memory 106 may include volatile memory such as static random-access memory (SRAM) or dynamic RAM (DRAM), or may include non-volatile memory such as flash memory, read only memory (ROM), or other volatile or non-volatile memory. Also, at least a portion of memory 106 may be implemented in a secure hardware element. Alternately, memory 106 may be a hard drive implemented externally to data processing system 100. In one embodiment, memory 106 is used to store the program portions illustrated in
Peripheral(s) 108 may include one or more of any type of peripheral. A peripheral is an internal or external module or device that adds functionality to data processing system 100. The number and type of peripherals depends on the intended application of data processing system 100. Example peripherals include but are not limited to: direct memory access (DMA) module, analog-to-digital converter (ADC), digital-to-analog converter (DAC), controller area network (CAN) module, universal asynchronous receiver-transmitter (UART)), serial peripheral interface (SPI), etc.
Secure decision maker 110 may be implemented in a trusted execution environment or other secure element and may be used to implement the hardware state machine program portion illustrated in
Various embodiments, or portions of the embodiments, may be implemented in hardware or as instructions on a non-transitory machine-readable storage medium including any mechanism for storing information in a form readable by a machine, such as a personal computer, laptop computer, file server, smart phone, or other computing device. The non-transitory machine-readable storage medium may include volatile and non-volatile memories such as read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage medium, flash memory, and the like. The non-transitory machine-readable storage medium excludes transitory signals.
Although the invention is described herein with reference to specific embodiments, various modifications and changes can be made without departing from the scope of the present invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present invention. Any benefits, advantages, or solutions to problems that are described herein with regard to specific embodiments are not intended to be construed as a critical, required, or essential feature or element of any or all the claims.
Furthermore, the terms “a” or “an,” as used herein, are defined as one or more than one. Also, the use of introductory phrases such as “at least one” and “one or more” in the claims should not be construed to imply that the introduction of another claim element by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim element to inventions containing only one such element, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an.” The same holds true for the use of definite articles.
Unless stated otherwise, terms such as “first” and “second” are used to arbitrarily distinguish between the elements such terms describe. Thus, these terms are not necessarily intended to indicate temporal or other prioritization of such elements.