Rooting the Cadillac Part 3: Infineon EMI Power Side Channels

In part 2 I said we could “Think Really Fast” to get SecOC frames.

Well, TLDR if it wasn’t obvious. I was referring to EMI based power side channels.

It didn’t work. I didn’t get the key :(

But still, a negative result is still a significant result.

The idea

Transistors, clocks, and other traces emit EMI which we can pick up in the open air. So, the theory is that we can ‘pull’ AES keys out of the air simply by looking at the EMI emissions of a target.

My target is the Infineon Tricore TC3xx series of MCUs. These are used on a variety of boards, not just in GM but across OEMs. These are complex MCUs, and have many internal components within their module and of course printed on silicon. Each of these generates its own EMI signature.

Hand-drawn block diagram titled Infineon TriCore TC3xx EMI view: crystal oscillator, PLLs and clock tree on top; two CPU cores up to 300 MHz and the SRI bus, flash and LMU; a dashed HSM security domain holding an ARM Cortex-M3 on its own clock and an AES accelerator; I/O pads and comms; and the EVRC switching core supply, EVR33 linear regulator and decoupling along the bottom

‘Where’ a given chip actually emits its EMI is also a complex subject. I.e. the HSM’s EMI may not be from the transistors themselves, but simply from their effect on the clock cycle and power draw… So the location of the noisiest signal can be in a different spot from what produced it… Especially if you are trying to just stick a giant probe over it like I am.

The Infineon Tricore TC3xx series in particular is special. It has an HSM, but its HSM shares a different architecture and notably operates on a different clock cycle. Its HSM is actually an ARM Cortex M series, printed on the silicon. The ARM Cortex M itself has been modified to support a dedicated AES Accelerator.

That AES Accelerator implements AES-CMAC, which is what is used to both sign and validate SecOC CAN frames, and others.

In other words, our target is not the Tricore ‘Cores’ and not the ARM Cortex HSM, but rather the AES Accelerator of unknown origin… But presumably it is of Infineon design.

Why?

A floor-to-ceiling rack holding hundreds of comma devices, each with its screen lit, labeled with colored tape and wired into rows — A wall of comma 4s. Every one of these runs openpilot.

That’s a wall of comma devices running openpilot, open source driver assistance that already works on a lot of cars. If you can get the key to leak from EMI, then you can get openpilot to work on modern cars. Not just GM, but Toyota, Honda, Ford, and anyone else who implements a SecOC derivation in the future.

That’s it. That’s the whole motivation :).

The Target Boards

I have a few candidate boards. Each uses an Infineon Tricore CPU.

Front view camera module board with an Infineon TriCore TC397 in the middle, a lens mount covered in black sealant on the left and a connector on the right — Front view camera module. Infineon TC397XX, and an EyeQ processor.

SuperCruise IPM board: a row of colored connectors down the left edge, a large square processor under a metal lid in the center, and pink thermal pad residue on the chips — Image Processing Module (ACP3, SuperCruise). Infineon AURIX TC397 safety MCU alongside a Qualcomm SA8530P.

The bench

The setup for this is a NewAE 15mm probe, a Rigol Oscilloscope, and a NewAE LNA (low noise amplifier).

Hand holding the NewAE 15 mm H-field probe, its SMA end wrapped in kapton tape, in front of a Rigol oscilloscope with three channels connected and a CAN frame on screen — The NewAE 15 mm H-field probe in front of the Rigol. Sorry, it's vertical.

15mm is massive for a chip this size, so I divided it into regions based on a numpad system. I.e. position 5 (over the silicon) is the direct center.

Top view of a square TC3xx package with nine overlapping probe circles numbered like a keypad, 7 8 9 on top and 1 2 3 on the bottom; the center circle 5 is shaded and covers most of the package, and the eight outer circles hang over its edges

That’s absolutely brutal placement, but 15mm is what I have to work with. p5 and p9 were the best positions, and that judgement was made entirely by feel. p7 is the most noisy.

One Trace

Three stacked panels for one capture: the CAN-H bit pattern ending at EOF, the raw H-probe signal which looks like uniform noise, and a spectrogram of the probe signal with horizontal clock lines and one faint vertical streak labeled anchor at EOF plus 62.1 microseconds — One capture at probe position P9. (a) CAN-H, (b) the H-probe channel, (c) its spectrogram, 100 ns by 10 MHz. Time is relative to the end of the CAN frame.

Most power side channel analyses use unrealistic scenarios such as programming a target chip to loop infinitely and calculate some AES value (which could be thousands of operations a second).

My approach is to instead send a single SecOC frame (or more accurately… wait on a SecOC frame) and observe the result naturally. While this means traces are much slower, it requires 0 exploitation. You just trigger the AES-CMAC operation however you can, and on a vehicle component that is always going to be a CAN Frame.

So, the scope triggers on the CAN SOF. The trace is then downloaded to a computer where it is stored for later processing.

Finding AES-CMAC

Heatmap of Welch t statistic over time and frequency comparing SecOC frames with plain frames; nearly flat everywhere except a strong red vertical band at about 63 microseconds after EOF spanning most frequencies, with a weaker cluster from 25 to 50 microseconds — SecOC frames (n = 49,572) against plain frames (n = 6,199), aligned to the CAN EOF, probe position P5. Welch t per time-frequency cell.

Histogram of anchor time after CAN EOF for two probe positions, both sharply peaked at 63.3 microseconds with a small secondary bump near 60 microseconds for P5 — Anchor latency after the CAN EOF for SecOC frames at P5 (n = 49,572) and P9 (n = 14,923). Both medians are 63.3 µs.

The wide trace is simply too much data, so we narrow it down by finding an ‘anchor’ (basically a surge in power). This usually occurs after a CAN frame has arrived in a mailbox, and a future task schedule picks it up.

Because it uses a task scheduler and mailbox, we have the unfortunate situation where the EOF to Anchor is not actually consistent (which is why we align on the anchor). Still, it follows a nice range.

What about clock synchronization?

Normally power side channel analysis will sync to a clock cycle (this is what the iconic chipwhisperer does). Instead of doing this, I just oversampled at 2GS/s (and fix it in post).

Where is AES CMAC?

Heatmap of power difference, SecOC minus plain, aligned to the anchor; a dark red vertical stripe at time zero, a purple bar marking a host-state region before it, an orange bar marking a CMAC transaction region after it, and a horizontal 300 MHz line that flips between blue and red across the window — Mean log power, SecOC minus plain, anchor-aligned, per-frequency median removed. P5, n = 49,572. Bars mark the host-state region (−24 to −6 µs) and the CMAC transaction region (+2 to +26 µs).

Line chart of power difference versus time from the anchor for three bands; the 300 MHz line dips negative before the anchor and rises slightly positive during the CMAC transaction region, while the 600 MHz and broadband lines stay near zero apart from the clipped anchor spike — Band power difference, SecOC minus plain, anchor-aligned, 1 µs boxcar. P5, n = 49,572. The anchor burst is clipped at +4 dB.

The 300MHz band line is the only real indicator of HSM work I got in my data. Prior to the identified anchor we see some activity (likely some task scheduling in an RTOS), a spike in processing, and then back to idle.

Is the 300MHz activity the HSM? Probably. It’s really the best I’m going for here…. Removing the die and taking pictures could possibly help identify it but look man I’m working blind here.

Where is my key?

Diving deep into what is ‘probably’ the AES accelerator… It’s just noise.

Left: heatmap of Welch t for frames with a valid MAC versus frames with an invalid MAC, uniform noise with no structure. Right: histogram of all t values overlaid on a standard normal curve, matching closely with sigma 0.95 — Valid MAC (n = 5,970) against invalid MAC (n = 7,461) at P9, anchor-aligned. (a) Welch t per cell, (b) the distribution of all 101,000 t values against N(0, 1).

To be very clear, I threw everything under the sun at the data. Nothing came out. I even varied the key, and nada.

Plaintext Leakage

What DOES LEAK is the plaintext handling by the tricore cores. In fact this is quite loud, and doesn’t take much effort at all to extract.

Top: correlation energy versus time from the anchor on a log scale, flat at chance everywhere except a narrow spike reaching about 11 at time zero, with the shuffled-label band shown in grey. Bottom: heatmap of max correlation per payload byte over a 6 microsecond span, darkest for byte 0 at plus 0.35 microseconds — Hamming-weight correlation of the wire bytes with power, P5, n = 44,615. (a) Mean n·r² over 7 bytes and 101 frequency bins, with the 0.1–99.9 % band from 20 label shuffles. (b) Max |r| over frequency per byte. The only excursion above the shuffle band is −0.35 to +0.45 µs around the anchor.

Two heatmaps of Pearson correlation between power and byte Hamming weight over time and frequency, for byte 0 and byte 2; both show a vertical column of correlated cells at about plus 0.35 microseconds, with labeled peaks at 200 and 240 MHz for byte 0 and 240 and 530 MHz for byte 2 — Signed r between power and byte Hamming weight around the anchor burst, P5. (a) byte 0, (b) byte 2.

This isn’t a surprising result, but it’s nice to see it confirms the setup.

Where this leaves things

I believe the problem is the AES accelerator is simply too fast and surrounded by too much noise to lead to a leak at my scale. I don’t think the accelerator is in any particular way hardened or truly constant time (but without engineering notes, I could be wrong).

A smaller probe ‘could’ filter it down further and decrease noise, but this is not proven. Unfortunately, 15mm is all I had on hand and I can’t budget creation of a smaller probe right now.

I also have yet to do this same technique on the RH850x series, which is something I intend to do next if there is time. The RH850x is another common automotive microcontroller.

Try your luck!

While I did not succeed, I built a large dataset of traces which you can analyze yourself, at home. The dataset tells you a payload, and the corresponding AES-CMAC key. Good luck!

https://huggingface.co/datasets/SnipesySpecial/tricore-secoc-emi-traces

110,717 captures across probe positions 5, 6, 8 and 9, two keys, 207 GB. P6 and P8 were a second campaign under a second key, same setup. Every trace comes with the frame on the wire, the freshness, and the key that verified it.

Prior work

Katsumi Ebina, Rei Ueno, Naofumi Homma. Side-Channel Analysis Against SecOC-Compliant AES-CMAC. IEEE TCAS-II, 2023.
Takaya Kubota et al. A Side-Channel Attack Method against Truncated MAC. CHES 2018 poster.
Deep learning side-channel attack against hardware implementations of AES. Microprocessors and Microsystems, 2020.
Yoo-Seung Won, Shivam Bhasin. On Use of Deep Learning for Side Channel Evaluation of Black Box Hardware AES Engine. 2021.
Ruize Wang, Huanyu Wang, Elena Dubrova. Far Field EM Side-Channel Attack on AES Using Deep Learning. ASHES 2020.
Virtual Triggering: a Technique to Segment Cryptographic Processes in Side Channel Traces. 2022.
Revisiting a Realistic EM Side-Channel Attack on a Complex Modern SoC. IACR ePrint 2024/1322.
SCATTER: A New Dimension in Side-Channel. IACR ePrint 2017/706.
Infineon. AURIX Security Solutions.
AUTOSAR. Specification of Secure Onboard Communication Protocol, FO R20-11.

Disclaimer

Posts in this category are my personal commentary and independent research. They are not official Surreal Development guidance, and they do not represent the views of any current corporation. Nothing here is a support recommendation for Gretio or any other product. If you act on it, you’re doing so at your own risk.