# Hardware Countermeasures Benchmarking against Fault Attacks
## 6 Discussion  
The following discusses the considerations that must be taken into account when selecting the most adequate type of countermeasure solution and the targeted fault coverage.  
Taking into account Table 3, DFA analyses focus on attacking three different points, the state matrix, the S-box() or the KeySchedule(). This is very important since many countermeasures do not protect these three points at the same time, possibly leading to DFA vulnerabilities. For example, in the analysis presented in Section 6, the solutions in [35; 49] are able to offer 100% fault coverage, but they are not able to protect the S-box() in the case of [35] and the KeySchedule() in the case of [49]. It should be noted that, depending on the selected protection solution, the cipher remains equally vulnerable to attack. Therefore, if complete protection is desired, only the options [38; 45] are useful. In case there is no need for a KeySchedule() protection because it is generated and stored before performing all the rounds of the cipher, refs. [39; 40; 41; 42; 43; 44; 48; 49; 53] would also be useful.  
Figure 8 can be used to guide the selection of the approach to use. For example, if the restrictions are very high and the fault coverage must be moderate, the proposals [43; 50] may be enough. On the other hand, if the application does not have a high level of time or area restrictions, but, on the contrary, needs a maximum level of protection, valid options may be [35; 44; 54]. Furthermore, depending on the type of implementation that is performed, it may be possible to assume a lower level of protection. For example, if the application uses rolled implementations instead of unrolled ones, it becomes difficult to insert faults between operations of the rounds, since everything is done in the same clock cycle.  
Regarding the trade-off between each type of countermeasure, on the one hand, hardware redundancy countermeasures are those that can offer the highest level of security at a higher cost of resources. As a consequence, these solutions must be oriented to environments where designs require a high level of security, but where resource limitations are not a strong constraint. On the other hand, temporal redundancy countermeasures allow for an improvement in the cost of resources compared to hardware redundancy, but on the contrary, they will have a high cost in operation frequency. In the case of information redundancy countermeasures, they have the great advantage of not presenting a high cost of resources and operating frequency, but on the other hand, the difficulty in determining parity in non-linear functions brings with it an increase in resources and execution time. Furthermore, depending on the solution, they will not be able to detect even-type faults. On the other hand, the use of information redundancy allows to determine faults inside the operations, such as S-boxes(), but if the fault is injected in the transition values (between the different functions), the countermeasures will not be able to detect them. Therefore, one of the most interesting alternatives is the use of combined countermeasures that allow us to find a trade-off between the advantages of each one of the types of countermeasures and to minimize the disadvantages that each one of them presents by itself.  
From the designer point of view, access to the codes or designs that allow the implementation of the schemes is another problem to take into account. Most of the solutions reported in the literature are described theoretically. For example, information redundancy countermeasures can be very complex from the mathematical point of view that they require, making it very difficult to implement in order to prove their viability in different environments or applications.