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.

 Tamper controller attack detection 

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.

 

This website uses cookies to ensure you get the best experience on our website. Learn more
OK