Work conducted by Ibrahima Keita.

Introduction to Sidechannel Attacks & Fault Injection

Continuing our 7-part series on attacking the Renesas RH850.

Background

In the previous blog post, we gave a brief overview of our target, the Renesas RH850, and the various security features. In this blog post, we will go over two techniques we can use to potentially bypass them: fault injection, and side-channel analysis.

Motivation

When securing embedded systems, a common first step is to focus on the software aspect. It is much easier to implement protections in software than with hardware; bugs in software often stem from improper implementation, but usually fixing a bug in software is just a matter of recompiling the software with proper logic fixes.

With software, while we make plenty of sensible assumptions, there is one which often gets ignored – the underlying hardware executes the code as intended, and has no faults. This is a fairly reasonable assumption, as most devices operate within the expected operating conditions. But what if the hardware suffers a fault during code execution? Will the code continue to execute correctly? If it doesn’t, will it be able to recover from the fault? What if the bug we are experiencing is because of this?

Fault Injection

The process of deliberately faulting an integrated system is called fault injection. The process of performing fault injection with the intention to characterize these faults is called fault analysis.

Hardware design engineers often perform fault analysis in order to verify system performance and designate operating conditions for a given component. This is because, depending on the operating conditions, faults are more or less likely to happen, which can affect device performance.

Faulting a system has various results; the system could crash, skip instructions, or read invalid memory, among other undefined behaviors. A notorious example of an accidental fault affecting the results of code is the Super Mario 64 “Cosmic Ray Incident”, in which a Super Mario 64 speedrunner performed a jump that was magnified randomly. While the exact cause is unknown, the leading theory is that a cosmic ray caused a bit in Mario’s jump height to flip to 0, causing Mario to jump significantly higher than normal. Efforts to reproduce this incident point to misbehaving hardware.

However, faults are not always accidental, and can be weaponized to force undefined behavior. An intentional fault scenario would be the Rowhammer DRAM exploit, which exploits DRAM accesses to corrupt memory contents of nearby rows. This works by repeatedly accessing a specific cell in a row of memory, increasing the chance of electrical noise from that operation causing a bit to flip in adjacent cells, which can cause values retrieved by a program to be different.

In terms of deliberate fault injection techniques, there are quite a few, including (but not limited to):

• Voltage glitching, where we utilize a crowbar circuit attached to the embedded system to momentarily power off a system.
• Clock glitching, where we arbitrarily overclock/underclock a system.
• Electromagnetic fault injection, where we utilize an electromagnetic coil to generate a high voltage pulse.

That being said, if we are performing a deliberate fault injection attempt, how do we determine when to perform the attack? This is where side-channels come in.

Sidechannel Attacks

A side-channel is an unintended source of information that can be analyzed to draw conclusions about internal operations.

An example of this would be the serial numbers of German tanks in World War II. Assuming that the serial numbers of each tank were consecutively assigned from 0 onwards (which they were), the serial numbers of a few tanks would be enough to allow one to estimate the number of tanks the Germans had, a tactic the British used to prepare troops for any incoming attacks.

Similar to the German tank problem, when performing side-channel attacks on hardware or software, we first identify a component that may expose information to us when viewed with the right set of tools. Some examples of this are monitoring the power draw of a device during a given operation, or viewing traffic coming into/out of a device (such as a memory read command being issued over SPI). Understanding the information being presented in the sidechannel gives us insight into what operations are being done, where they are being done, and what devices are used to perform it. This allows us to more precisely target a given system, and provides the information we need to perform fault injection or other attacks.

Voltage Fault Injection

Many embedded devices are designed to operate at a certain voltage level, but may not react well to being in different levels. Take air conditioners on a hot summer day for example.

• When one air conditioner is running in the entire city during the summer, the air conditioner would probably be fine and work as expected.
• If 30% start using their own air conditioner, the power going to your air conditioner may be slightly reduced by the electric company, in order to reduce stress on the grid. Your air conditioner might still run, but maybe not correctly (for example, the fan might run slower).
• If everyone in the city runs their air conditioners, the power will very likely be reduced a lot by the electric company, causing the air conditioner to stop working/shut it off.

With voltage fault injection, we coerce components in the device into acting similar to the second bullet point (your air conditioner fan running slower because 30% of the city is also using theirs), but only for a short period of time.

Imagine the fan was the logic unit (a component responsible for defining what operations return LOW (0) and HIGH (1) on the system), and we forced it to operate incorrectly like the fan did. By causing this behavior for just enough time, we can force a logical statement that should logically never be true (for example, 1 == 2) to be true, which could potentially cause the system to take a different code path (or, experience undefined behavior). Doing this behavior for too long can cause the entire system to crash, while doing it for too little time may cause no noticeable effect at all.

To cause this behavior, we want to induce voltage oscillations, or ringing, in the circuit. This will take a somewhat stable voltage, and cause it to fluctuate for a moment, which should hopefully cause our device to operate out of specification.

To cause these oscillations, we quickly drop the voltage of the system using a crowbar circuit. A crowbar circuit acts as a controllable short circuit on the voltage rails, preventing any device on the corresponding voltage rails (such as our system) from being powered. It got the name “crowbar” because it has the same effect as literally throwing a crowbar across exposed voltage rails.

For voltage glitching to be as effective as we want, we need to carefully choose the following:

• The condition that our sidechannel needs to be in for us to perform the glitch (known as the trigger). This strongly depends on what you are trying to target.
• How many trigger device cycles from the detected sidechannel condition we should wait to pull the voltage down (known as the external offset, or ext. offset).
• The shape of our glitch (a combination of the glitch pulse width, and how many trigger device cycles the glitch pulse should be repeated for).

Because execution time is stochastic, and because the sidechannel may produce the condition earlier or later as a result, it is extremely wise to define a range of ext. offsets, widths, and repeats to iterate over as this will greatly increase the chances of causing the behavior you want.

That being said, this looks like a lot of information for a human to keep track of. Thankfully, Colin O’Flynn had the exact same thought, and designed the ChipWhisperer series of glitch controllers.

ChipWhisperer

The ChipWhisperer is a series of instrumentable FPGA-based glitch controllers that include a built-in crowbar circuit. They support all of the constructs which we have defined above: they can trigger on a signal (of which we’d determine using a sidechannel), pull the line down for a certain amount of device cycles, and allow us to define a proper glitch shape.

Depending on the specific ChipWhisperer hardware being used, there are differing feature sets. The ChipWhisperer Husky, which we have, allows us to perform triggering on serial communication for example. It can also perform basic power measurements, which makes it helpful for power analysis. It can also be easily controlled via Python with the chipwhisperer API.

We own a ChipWhisperer Husky, so we will use it in order to help us perform fault injection, as it makes our job much easier.

That all being said, to demonstrate the efficacy of these techniques, we will perform fault injection and side-channel attacks against the Renesas RH850 to bypass the security features that were mentioned in the previous post. In theory, if the protections could be bypassed with these techniques, we could gain access to any locked RH850. In the next blog post, we will explore if the RH850 is susceptible to fault injection.