Renesas RH850 Attacks (Part 7 of 7) – RH850 Power Analysis: An Attempt

June 13th, 2025 by Brian

Background

In the previous blog posts, we detailed a fault injection attack on the Renesas RH850, both with crowbar fault injection and electromagnetic fault injection. In this blog post, we will perform some power analysis in order to gain more information about the ID authentication on the processor.

Introduction

As stated previously, a side-channel is an unintended source of information that can be analyzed to draw conclusions about internal operations. Power analysis is a form of side-channel analysis where the power usage of the chip is profiled at various times and correlated with the work done internally by an embedded device. This is often done via a black-box testing model, where our target is sent data, and the power is profiled at that moment.

Like the German tank scenario, this can reveal information about internal processes, such as when a specific operation is executing. For hardened devices (such as those with ID protections), this information can be helpful for bruteforcing secure parameters, as it reduces the search space if any data is exposed through it.

Theorizing an Attack Model for the RH850

Why Power Analysis?

Power analysis can be very powerful (no pun intended) in understanding the internal work an embedded device is doing. Depending on the operation being performed, the current drawn by a device will either increase or decrease, as certain operations are more power-intensive than others. Per Watt’s law $( P = I \cdot V )$ , this linearly correlates to an increase in power, measured in watts.

Operations involving cryptography tend to be fairly power consuming due in part to the computational complexity of the algorithms involved. For example, AES implementations have many computations required for decryption purposes, which can easily drive up the power for a sustained amount of time. Therefore, it oftentimes becomes fairly obvious when an AES operation is executing, often by looking at power traces. This blogpost by Colin O’Flynn is an example of a sidechannel AES attack, using the Hamming-Distance model.

We can attempt to use this concept to attack the password system on the RH850. While the details of the attack will certainly not be the same, the tools and methodology to determine the details will get us close enough to an attack surface.

RH850 ID Authentication

According to the Renesas Boot Mode Specification, and my documentation, ID authentication on the RH850 via UART is as follows:

What this essentially tells us is:

To skip the erasure check, the two most significant bits of ID_S, ID_S[127 : 126], must be equal to 10_b (2).
If we send the ID ALeRASE, we either erase the entire user and config area, or we run into a protection error if the FSPR bit is set to 0.
If ID_S[127] is 1_b, serial programming is disabled, and we error out.
If our ID matches the one stored, and none of the errors above stops us, command acceptance phase is enabled.

Now, when it comes to bruteforcing the ID, we need to keep in mind that the ID is 16 bytes at maximum. This means we need to try every combination of bytes ranging in value from [0,255], in 16 different locations. This means we have $256^{16} = 3.402 \times 10^{38}$ possible passwords. If we were to attempt to try every single password, given that it takes approximately 0.8 seconds to try every password in the worst case scenario, it would take us:

$3.402 \times 10^{38} \text{ passwords} \times \frac{0.8 \text{ seconds}}{1 \text{ password}} \times \frac{1 \text{ minute}}{60 \text{ seconds}} \times \frac{1 \text{ hour}}{60 \text{ minutes}} \times \frac{1 \text{ day}}{24 \text{ hours}} \times \frac{1 \text{ year}}{365 \text{ days}} = 8.63 \times 10^{30} \text{ years}$

See you in year $2025 + 8.63 \times 10^{30}$ , then! This is how long it takes for a single chip in the worst case. I wouldn’t even be alive to see what the password is at that point.

So, that is obviously out of the question, unless you get super lucky. However, there is a way we can reduce the maximum number of permutations. Remember how I mentioned that power analysis can be used to determine when a specific computation is occurring? Why not utilize it to determine when the password check is going on, and analyze its behavior?

To perform said analysis, we will need a rough methodology to follow, as well as a suite of tools to use in each step.

Designing a Methodology

Per Kirchhoff’s Current Law, the sum of all current (rate of electron transfer) going into a point equals the sum of all current exiting a point, or $\Sigma I<em>_{in} = \Sigma I_</em>{out}$ . Simply put, this means if a particular component in a circuit draws current, the net current draw in the circuit is proportionally affected. This also means that if we measure the current through a component in series with the positive voltage rail $V_{cc}$ and our device under test, the current through that component is the same as the total current through the device under test.

Additionally, given a component’s resistance, $R$ , and the current through the component, $I$ , the voltage drop across the component, $V$ , is directly proportional to the product of the current through the component and the resistance of the component, or $V=IR$ . If we fix the resistance value to a constant value, as the current trends up or down, the voltage drop is proportionally affected.

What we can do to measure the current, as many ammeters do, is insert an item of a known resistance between $V_{cc}$ and $V_{dut}$ , measure the voltage drop across it, then divide the voltage drop by the resistance of the item. This particular item is called a high-side shunt resistor (because it is a shunt resistor connected to the voltage line), and is used to force current in a particular direction in a circuit. A differential measurement should make short work of this.

For it to be non-intrusive, this component’s power should be minimized. The power consumed by a device, $P$ , is directly proportional to the product of the current $I$ (squared) and the resistance $R$ , or $P = I^2R$ . It helps to think of this as a quadratic equation, where $R$ is a vertical scaling factor; the higher the resistance $R$ is, the more the current $I$ affects the power consumption of the component, $P$ . We want to select a resistor which minimizes $P$ while also being able to withstand the current through it (as too low of a value can cause the shunt to heat up and burn out).

Furthermore, we are only interested in capturing power at a certain point in execution. As such, our differential measurement needs to happen when we trigger it, and only when we trigger it. Similar to how we did fault injection, we can trigger on a known sequence of data, forcing a capture in that time interval, and use that to perform power analysis.

We also need to have a tool to capture and perform differential measurements, which is yet another thing the ChipWhisperer Husky is capable of doing. However, for this, we originally used the Power Profiler Kit 2. It has a built in shunt resistor, but samples at only 100 kilosamples per second (and for a chip that runs at 16 MHz, this is definitely not enough to capture all the behavior).

So, our final methodology is as follows:

Create a program that instruments our RH850, and gets us to the ID authentication phase.
Have the ChipWhisperer Husky trigger when the ID authentication phase happens, and perform a differential measurement with our shunt resistor (either with an instrumented Power Profiler Kit 2 by Nordic Semiconductor, or the ChipWhisperer Husky).
Stop capturing right after the command is sent.
Plot a current vs sample number graph, which represents the current over a given time interval.

Now that we have a methodology, we can now get started.

Performing Power Analysis

Test Scenario 1 (ID-Protected RH850, known password)

Note: the captures here were done with the Nordic Semiconductor Power Profiler Kit 2, as we did not have a shunt resistor setup at this time. The Power Profiler Kit 2 has a shunt, however.

In this first scenario, the device under test is an RH850 with a known password. As such, we are able to freely unlock the device with ease by sending the correct command.

What I ended up doing here was trying to identify deviations in the traces. The best idea I had for this scenario was to do a run with no correct password bytes, capture the power trace, then do a run with one correct password byte, capture the power trace, and repeat this until I have done this for all 16 bytes (leaving me with 17 traces).

First, I captured a run using just none of the correct characters (all 00).

Then, I captured a run with all of the correct characters (all 7F).

I also did a few other combinations.

This is all 0F.

This is all F0.

This is all FF.

Potential Discovery

If you look closely, you can see that in the 7F case, as we send more 7F bytes, the current has more frequent drops. And this makes complete sense; the UART TX line is set to high by default, and is pulled down to low (0V) when a bit is to be sent. This is also the case for any byte where bits are set to one, as we can see with the various test cases.

This allows us to determine that the region before the dips in current are likely the first parts of the UART transmission (command header and length), and the region after the dips in current are likely the second parts of the UART transmission (the checksum, and the end). Therefore, it must be the case that the region directly succeeding the UART transmission has to be the work being done to verify the password.

Limitations

It was here that we ran into a limitation with our Power Profiler Kit 2. Remember how I said it only sampled at 100 kilosamples per second? That’s still significantly slower than the clock rate of the processor, so seeing exactly what the “work” region is doing is a little bit difficult.

That being said, the region after the UART transmission is very likely the region where the password is checked, as right after that, the system attempts to send some acknowledgement back (this being an invalid password acknowledgement). So, we could attempt to perform fault injection on this region to see if the password check could be skipped. However, it was at this point that I ran out of time, so our results have stopped there.

Conclusion

After getting a deeper understanding of the Renesas RH850, not only were we able to demonstrate that it is susceptible to fault injection, but we also demonstrated that we were able to bypass one of the critical security features by utilizing it.

Although I have successfully performed the serial programmer prohibition bypass, I have theorized a few other fault injection attacks which should be doable with more time.

Since we are able to communicate with the RH850 after faulting it, we should theoretically be able to send any command we want to it. This would mean that, given the RH850 in question is not locked with an ID, you can disable the serial programming handicap by writing a new set of flash options. This requires usage of the AREA_REQUEST command (0x3B) as I have documented previously.
It might be possible to dump the bootrom from the RH850 by glitching the read command work area to let us read from a restricted area, and dump the bootrom.
The ID authentication check may be glitchable. After performing power analysis, my current conclusion is that the ID authentication check either happens in constant time (and doesn’t increase power consumption with each correct character), or happens relatively quickly. I am very likely to be wrong with this, though.

Special Thanks

I’d like to thank Matt Alt and Charlie Waters, for being great mentors, teaching me more about hardware hacking, and allowing me to explore the field of fault injection. I’d also like to thank the rest of Caesar Creek Software, especially the Woburn office, for giving me the opportunity to work on a cool project.

NOTE

Thanks to Renesas for reaching out about the posts. They note that newer generations of this product “use defensive secure coding practices on the mask ROM as well as implement things like fault detection for glitches”. It is always good to see product vendors reaching out and working with security researchers to help improve product security.

Posted in Blog
No Comments