# Hardware Countermeasures Benchmarking against Fault Attacks
## 4 Countermeasures against DFA
In [37], the use of pipeline architectures that use both edges of the clock signal is proposed in order to reduce the throughput degradation when duplicating the cipher function. A solution called recomputing with permuted operands (REPO) is presented in [38]. This approach consists of the duplicate computation of two inputs and the permutation between them to perform a new computation and check if the result is the same or if any faults have been introduced. In [39], a solution is presented where the result of each round is stored in a register and is used to repeat the round. In addition, using the multiplexed keys of KeySchedule() allows to perform the rounds alternately and compare the results in search for faults. Figure 3: Representation of hardware redundancy, (**a**) Full redundancy, (**b**) partial redundancy. 3. The information redundancy [40; 41; 52] countermeasures consists of adding information to the state of the ciphers before the intermediate operations. This information allows to detect if the state was tampered during the process. It is possible, for example, to detect whether faults have been injected during state transformation processes using a parity predictor and a parity checker. A representation of an example of information redundancy can be seen in Figure 5. In this case, it has been chosen to add a parity bit to the state matrix and compare this parity after performing the encryption operation. The main advantage of this type of approach is the low resource overhead. Depending on the type of added information, the cost can be very small. However, the main advantage of this type of countermeasure is the difficulty of relating the parity before and after the encryption operations, since these are non linear. However, different types of faults will not be detected, depending on the number of bits used for fault detection. For example, the use of a single parity bit can detect odd state changes, but if the injected fault changes an even number of bits, it will not detect it. When this type of solution is applied to the AES cipher, it is necessary to take into account whether the nonlinear S-box() function is implemented through the use of Lookup Tables (LUTs) or not. For example, if the solution needs to access the intermediate result of the reverse multiplication of the S-box(), the scheme cannot be applied if the S-box() is implemented in a memory since there is no access to that intermediate result. On the contrary, if the scheme involves adding a parity bit in memory, as a signature of the input data, this scheme cannot be applied if the S-box() implementations are not implemented with memories. Taking this into account, there are numerous options available by applying this type of scheme to the AES cipher. An option is to calculate the parity of input data of the S-box() and add it to the memory in order to compare the parity at the input and output of the S-box() [41; 42]. The same approach is also applicable if the differential result between the input and output data of the (S-box()) is added as a memory output instead of computing the parity [44]. It is possible to detect fault injection by validating the operation \(Sbox_{input}\oplus Sbox_{output}=Diff\). In [45] a Hamming code signature generator targeting an AES cipher based on T-boxes() is presented. It generates a signature of the data before and after the operations of the T-boxes(). This allows to determine if any fault has been introduced in the S-box() and MixColumn() operations. This approach is applicable to both encryption and decryption and is capable of protecting the state matrix and S-box(), and also is applicable to KeySchedule(). In addition to the parity prediction added to the S-box(), it is also possible to add backup and multiplexing elements composed of an additional S-box() that allows reconfiguration of a possible injected fault. This allows to drive the data by the correct line in online mode [47].