To use our site, you agree to the use of cookies and data processing according to our privacy statement.
Close
Search

Fault Injection is now part of Common Weaknesses Enumeration database

At Riscure we believe that hardware security is the next frontier of protection from cyberattacks. While the majority of attacks exploit flaws in software, in some areas, especially in embedded systems, better code practices reduce the vulnerability surface significantly. If there are now practical software vulnerabilities to exploit, a direct attack on hardware is the next logical step. The consequences of a successful fault injection often have the largest impact on product security: a complete bypass of security mechanisms, access to firmware, compromise of a payment system.

You can learn more about our view on Fault Injection here, but in this blog post we would like to reference an independent view on the severity of the threat. In February 2020 Fault Injection was added to a list of Common Weaknesses maintained by the MITRE Corporation. Unlike the CVE database that contains data on actual flaws in real software or hardware, CWE is attempt to formalize potential security vulnerabilities. Of course, the majority of the list is devoted to software mistakes:

Let’s have a look at CWE-1247: an entry that describes “Missing Protection Against Voltage and Clock Glitches” which is basically a formal description of Fault Injection. We could argue that ‘Voltage’ and ‘Clock’ glitches are not the only ones known types of a hardware attack. These, together with the electromagnetic pulse glitch are relatively ‘easy’ to carry out. An example of a ‘complex’ fault is affecting a (decapped) integrated circuit with a laser pulse, with high level of precision.

In any case, the most interesting aspect of Fault Injection is that the protection against such hardware attack needs to be implemented in software. There are certain types of hardware mitigations, but without code hardening they are not very efficient. An example of a pseudo-code above from the CWE-1247 entry is a typical example of bypassing a security check: only once we verify the validity of input (a firmware signature or a PIN entry). Should we find a way to ‘glitch’ a device during this particular moment, we can bypass the security check altogether and continue with code execution with wrong input. The result? Depending on the application, an execution of arbitrary code, access to unencrypted firmware or accessing data without PIN or password on a crypto-wallet.

We are happy to see that Fault Injection is recognized independently by a reputable party, and that Riscure research is mentioned in the overview. As part of the WeLove.fi initiative we will share more in-depth information about Fault Injection, reveal different attack types and talk about mitigations. In May we are hosting a special online event, the ‘Riscure Fault Injection Crash Course’ where we will accumulate the essential information on hardware security and share it with the audience, for free. If you are interested in attending this event, sign up on this page.