Tampering with the Program Flow
Faults can also be injected to change the flow of an executed software code [28-31]. A fault in program counter is an obvious way to modify the program flow. For code implementing cryptographic algorithms, change in the program flow can be a security threat. Often an instruction skip lead to a wrong computation of critical portion of the algorithm, significantly weakening it. A notable example of this involves the exponentiation algorithm . Similarly, fault on loop counter or branch selection were demonstrated to leak secret point of pairing schemes  or to reduce the number of encryption round in symmetric key algorithms , thus enabling classical cryptanalysis. Often fault attack countermeasures are based on redundancy with sanity check. Some efficient attacks simply try to skip the sanity check to bypass a deployed countermeasure . This approach can be distinguished in two main categories: during compile time or during runtime. To inject faults at compile time, the program instruction must be modified before the program image is loaded and executed. Rather than injecting faults into the hardware of the target system, this method injects errors into the source code or assembly code of the target program to emulate the effect of hardware, software, and transient faults. During runtime, a mechanism is needed to trigger fault injection. Commonly used triggering mechanisms include, timeouts, exception/traps and code insertions. Although this approach is flexible, it has its shortcomings: first of all, it cannot inject faults into locations that are inaccessible to software. Second, the poor time-resolution of the approach may cause fidelity problems. For long latency faults, such as memory faults, the low time-resolution may not be a problem. For short latency faults, such as bus and CPU faults, the approach may fail to capture certain error behavior, like propagation.