Software Countermeasures for Fault Injection Attacks
Abstract
Not long after the major global mobile computing IP company Arm launched its new isolation technology TrustZone™, the hacker world also released an attack targeted to that architecture and claims that it can bypass the TrustZone™ protection. Regardless of whether hackers can finally use this crack to obtain any actual information or benefits, we know that the method used by the hackers is generally known as fault injection attacks in information security. Since the advantages of this type of attack include easy, low cost, and equipment for it can be easily acquired, it is often used by hackers; there are even dedicated kits for it sold on the market.
Since there are such attacks, there are corresponding protections, and the protection against it can be divided into software and hardware protection. For the software protection against fault injections, possible vulnerabilities may need to be analyzed first, and then corresponding software development and protection must be conducted for these vulnerabilities. To software engineers, this requires in-depth professional knowledge and skills in order to achieve.
When equipment with hardware protection capabilities is used, the protection against fault injection attacks is relatively easier in terms of software development. When the MCU is designed, protection against fault injection attacks was already considered into the hardware design. This means that the professional information security technologies required for product applications are already embedded into the hardware; all the software engineers need to do is to enable them and they could provide great protection against fault injection attacks. Relatively speaking, this is much easier and it can avoid causing security vulnerabilities from software errors to the greatest extent.
Hardware protection against fault injection attacks
When the execution condition of a product exceeded its default specifications, there would be errors with the operation of the product. If this kind of execution condition can be restricted so that it only appears at specific times, and only for an extremely short period of time, it can make the product malfunction when executing specific commands, while other commands can still execute normally so-called fault injection attack. A common means of attack is to cause the voltage and frequency of semiconductor components to exceed their operation specifications temporarily. Therefore, in terms of protection, once abnormal voltages and frequencies can be detected effectively, responses can be performed immediately, blocking the attack in real-time.
To ensure that the hardware can respond to attacks effectively at all times, the detection hardware must be separated from the usual operating circuit and have its own power supply and frequency system to prevent external attacks from paralyzing the detection circuit. In addition, the detection circuit must also be able to control key hardware directly so that the necessary protective actions can be performed automatically. For example, clearing the keys in the memory prevents software errors generated by fault injection, causing key processes to be unable to be executed during attacks.
Figure 1: The tamper controller detects attacks from voltages and frequencies, notifies the CPU and triggers the Key Store protection mechanism directly.
Voltages and frequency attacks and handling
Various voltages and frequency attack methods are included on the M2354 fault injection protection hardware, and responses were designed accordingly as listed in the table below:
Detection method |
Normal condition |
Status under attack |
Protection method |
Detects VDD using EADC |
1.62V ~ 3.6V |
Voltages other than 1.62V ~ 3.6V |
Software intervention |
High voltage detection |
VDD < 4.0V |
VDD >= 4.0V |
Hardware interruption and the preset action is triggered |
Low voltage breakthrough detection |
Users set the fault tolerance range |
Exceeded the fault tolerance range set |
Hardware interruption and the preset action is triggered |
VBAT voltage detection |
Normal operation of RTC |
VBAT low voltage |
Hardware interruption and the preset action is triggered |
Power failure detection |
LDO_CAP being within the preset high and low voltage limits |
LDO_CAP exceeded the preset high and low voltage limits |
Hardware interruption and the preset action is triggered |
High speed external clock failure detection |
Stable and continuous clock source |
Clock source disappeared |
Hardware switches to internal clock source automatically |
Low speed external clock failure detection |
Stable and continuous clock source |
Clock source disappeared |
Hardware switches to internal clock source automatically |
High speed external clock monitoring |
Frequency falls within the preset range |
Frequency exceeded the preset range |
Interruption is used to notify software intervention |
Low speed external clock monitoring |
Frequency falls within the preset range |
Frequency exceeded the preset range |
Hardware interruption and the preset action is triggered |
The “preset action” in the table above can be software intervention only, or to force the system to reset, or force the clearing of all keys stored in the Key Store.
Conclusion
For microcontroller products, fault injection attacks are indeed easy, effective and low-cost attacks. This is why hackers often use this type of attack. In order to protect the important information in the products, protection against this type of attack is imperative. However, protection using software not only requires engineers with expertise in information security, but it also requires a set of rigorous inspection mechanisms to prevent man-made negligence. On the other hand, protection methods built on hardware detection only require engineers to enable all hardware protection and set the corresponding actions to fully prevent attacks from the power source and clock. Hardware protection is clearly much easier.
Therefore, the use of the fault injection protection design of M2354 can allow users to focus more on the development of product functions, and not many additional tasks need to be added for the protection of information security, reducing the additional time and cost required to develop protection mechanisms.