Nordic Semiconductor ASA.

Page1

AES-128 ECB/CBC/CTR Plaintext Recovery

and Error Byte Diffusion via Voltage Fault

Injection on Arm® TrustZone® CryptoCell

310 in Nordic Semiconductor nRF52840 SoC

1. Introduction

Hardware security vulnerabilities in cryptographic accelerators pose a significant risk, particularly

when they enable attackers to bypass encryption mechanisms using physical fault injection

techniques. This research investigates a critical weakness in the Arm® TrustZone® CryptoCell

310 AES-128 hardware engine implemented in the Nordic Semiconductor nRF52840 SoC. The

identified vulnerability allows plaintext recovery and error byte diffusion across ECB, CBC, and

CTR encryption modes when subjected to voltage fault injection.

Unlike traditional Differential Fault Analysis (DFA) attacks that require multiple faulty ciphertexts

to infer encryption keys, this vulnerability enables direct plaintext extraction without advanced

cryptanalysis. The attack effectively bypasses encryption safeguards, rendering key management

strategies such as key rotation and CBC initialization vectors ineffective. Additionally, the

observed error byte diffusion patterns suggest a potential for DFA in ECB mode under specific

fault conditions.

This research provides a comprehensive analysis of the attack methodology, including the

experimental setup, fault injection conditions, and observed fault effects on AES encryption. A

custom-built voltage glitching tool was utilized to introduce controlled voltage faults without

requiring capacitor removal, demonstrating a practical and repeatable attack scenario.

Experimental results are documented with detailed technical breakdowns, highlighting how

voltage fault injection influences encryption output.

To ensure responsible disclosure, these findings were communicated to the vendor, and

recommendations for mitigation strategies are proposed. This research underscores the necessity

for robust fault detection and countermeasures in hardware cryptographic implementations,

emphasizing the broader security implications for embedded systems relying on hardware-

accelerated AES encryption.

The goal of this research is to contribute to the ongoing improvement of cryptographic hardware

security, provide valuable insights for embedded system developers, security researchers, and

vendors while promoting stronger security practices in hardware-accelerated AES encryption. It is

important to note that hardware encryption is not always more secure and should be carefully

assessed, as well as subjected to threat modeling, especially in microcontrollers and SoCs that are

not hardened against fault injection attacks.

Nordic Semiconductor ASA.

Page2

2. Report Overview

• Report Title: AES-128 ECB/CBC/CTR Plaintext Recovery and Error Byte Diffusion via

Voltage Fault Injection on Arm® TrustZone® CryptoCell 310 in Nordic Semiconductor

nRF52840 SoC

• Date Submitted to Vendor: November 13, 2024

• Submitted By: Bedri Zija, Embedded Hardware/Software Engineer | Independent

Embedded Systems and Hardware Security Researcher

• Email: bedri.zija@proton.me

• Target Device: nRF52840 Revision QIAA-D0, Multiprotocol Bluetooth 5.4 SoC

supporting Bluetooth Low Energy, Bluetooth mesh, NFC, Thread and Zigbee,

• Runtime cryptography library nrf_cc310 version: libnrf_cc310_0.9.13 for using

hardware-accelerated ARM CryptoCell CC310. Latest cortex-m4\hard-float\no-interrupts

version in latest maintained nRF5 SDK v17.1.0

3. Executive Summary

• Vulnerability Type: Cryptographic Fault Injection (Voltage Fault Injection on AES-128

cryptographic hardware engine using hardware-accelerated ARM CryptoCell CC310 on

nRF52840 SoC).

• Impact Summary: Voltage fault injection on the AES hardware engine in ARM

CryptoCell CC310 allows plaintext extraction and produces error byte diffusion in ECB,

CBC, and CTR encryption modes. Bypassing encryption to extract plaintext instead of

ciphertext poses a significant risk, as it renders security practices like key rotation and

initialization vectors for CBC ineffective, leaving sensitive data exposed. The error byte

diffusion is potentially exploitable for Differential Fault Analysis (DFA) in ECB mode due

to its suitability for such analysis.

• Severity: Medium, CVSS 4.0 Base Score: 5.6

• Vector: CVSS:4.0/AV:P/AC:H/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N

• Exploitability: Moderate to High (requires physical access and fault injection equipment).

• Affected Components: AES128 (ECB, CBC, and CTR modes) in Arm® TrustZone®

CryptoCell 310 security subsystem providing root of trust (RoT) and cryptographic

services for a device.

4. Vulnerability Details

4.1 Description

A vulnerability in the Arm® TrustZone® CryptoCell 310 security subsystem AES-128 hardware

engine on the nRF52840 Multiprotocol Bluetooth 5.4 SoC allows attackers to extract plaintext

instead of ciphertext when voltage faults are applied during encryption. This issue could pose

significant security implications for applications relying on AES hardware engine in ARM

Nordic Semiconductor ASA.

Page3

CryptoCell CC310. This vulnerability affects ECB, CBC, and CTR modes and undermines data

confidentiality. Although Differential Fault Analysis (DFA) does not yield key extraction in ECB

mode, plaintext recovery is achieved consistently with voltage fault injection in ECB, CBC, and

CTR modes. Additionally, various error byte diffusion patterns, such as all-zeroes output and

partial error byte diffusion, were observed under specific fault conditions.

4.2 Technical Analysis

• Root Cause: The AES hardware engine lacks adequate protection against fault injection,

leading to corrupted encryption outputs that permit plaintext leakage.

• Hardware-Based Fault Injection Technique: A custom voltage glitching tool with a

MOSFET crowbar circuit introduces voltage faults during the encryption process. The

setup does not require the removal of capacitors.

• Fault Patterns Observed: Voltage fault injection produces multiple fault patterns,

including:

o Plaintext output: Plaintext appears directly in place of ciphertext.

o All-zeroes output

o Full error byte diffusion: Results in randomized byte values, likely indicating a

fault occurring in round 8 or earlier.

o Partial error byte diffusion: Observed error byte diffusion patterns include 15-

byte, 4-byte, 2-byte, and single-byte diffusion, with 4-byte partial error byte

diffusion suggesting a likely hit in round 9.

• DFA Analysis: While DFA can be tested for ECB mode, no key extraction was achieved.

Although we have achieved the required types of errors, specifically full-byte error

diffusion in round 8 or earlier and 4-byte error partial diffusion in round 9, we have not yet

obtained the necessary exact byte patterns that would be useful for analysis. The glitching

tool's precision may not be sufficient to consistently generate the precise fault patterns

needed for optimal differential fault analysis (DFA). Refining the fault injection process,

potentially using EMFI or body biasing techniques, could improve the accuracy and help

achieve the exact byte patterns needed for more effective analysis.

4.3 Impact Assessment

• Data Exposed: This vulnerability allows direct access to sensitive plaintext data that

should remain protected by encryption, creating a serious risk of exposing confidential

information. When fault injection causes plaintext output instead of ciphertext, encryption

is bypassed entirely, exposing critical data such as passwords, cryptographic keys, or other

sensitive content to an attacker without requiring advanced cryptographic analysis like

DFA. This exposure compromises data confidentiality instantly across multiple encryption

modes (ECB, CBC, and CTR), affecting any application that relies on them for secure

communication. Attackers may retrieve critical data directly in plaintext, bypassing the

intended encryption protections, which could lead to unauthorized access and potential

misuse of sensitive assets. Additionally, it undermines secure communication protocols

between the SoC and other MCUs or connected devices, weakening the security of

confidential communication channels.

Nordic Semiconductor ASA.

Page4

• Privilege Escalation: The fault injection affects only data confidentiality and does not

grant elevated privileges. However, unauthorized access to sensitive data can facilitate

other forms of attacks, such as replay attacks, session hijacking, or information disclosure

that may indirectly compromise system security or enable privilege abuse in connected

environments.

• Network or System Access: N/A, as the attack relies on physical access to the device.

5. Exploitation Details

5.1 Attack Procedure

The fault injection attack on the AES-128 encryption process on the nRF52840 Multiprotocol

Bluetooth 5.4 SoC leverages both the system-on-chip (SoC) setup and an external glitcher

controlled via Python. Here is a step-by-step breakdown of the procedure:

SoC Setup

1. AES Initialization: Configure the AES-128 encryption with a predefined key. For CBC

mode, set an Initialization Vector (IV).

2. Plaintext Input: Load the plaintext data intended for encryption.

3. Buffer Clearing: Clear the ciphertext buffer before each encryption cycle to ensure that

residual data does not impact results.

4. Trigger Signal for Lab Testing: Implement a trigger signal using an external pin, set high

at the start of encryption and low upon completion. This pin-based trigger aids in

pinpointing the encryption timing in a controlled environment.

5. Encryption Activation: Monitor the serial port for incoming data. When receiving the

command "E", initiate the encryption process.

6. Fault Injection Timing: Upon encryption start, the high signal on the trigger pin activates

the fault injection tool, which introduces a voltage glitch of a predefined width after a

specified delay.

7. Data Collection: After a 100ms wait (to ensure and demonstrate no interference beyond

AES operations), output the contents of the ciphertext buffer for analysis.

Real-World Triggering Technique For a production device without direct access to a precise

trigger pin, localization of the AES encryption process requires an alternative, indirect approach:

• Identifying Encryption Timing: In practical applications, encrypted data is typically

output through communication interfaces such as USB, UART, SPI, I2C, CAN bus or other

communications channels. Monitoring this output allows identification of when data is

ready, indicating that encryption has concluded.

• Side-Channel Power Analysis: To determine the exact timing of encryption, side-channel

power analysis is employed to capture characteristic power traces. By analyzing these

traces, specific power signatures or waveforms corresponding to the AES encryption

process can be identified.

Nordic Semiconductor ASA.

Page5

• Triggering via SAD or Zone-Based Trigger:

o Tools like the ChipWhisperer Husky support triggering based on the Sum of

Absolute Differences (SAD) for these specific signal shapes, allowing the glitcher

to trigger accurately on observed waveforms associated with encryption activity.

o Oscilloscopes with advanced zone-triggering functionality can also define specific

waveform zones to trigger when power signals match pre-defined shapes.

Glitcher Control Setup

1. Power Control and Initialization: A Python script manages the glitcher’s control over

the SoC power and reset lines. The script also controls the crowbar MOSFET used for

voltage glitching.

2. Glitcher Preparation:

o Reset the SoC and allow time for it to boot.

o Arm the glitcher, setting it to detect the identified trigger condition.

o Send the "E" command via the serial interface to initiate encryption.

3. Fault Injection and Result Capture: Upon receiving the trigger condition, the glitcher

applies a voltage glitch at a preset delay, which can be adjusted in 5ns steps (or smaller if

using tools like ChipWhisperer). The Python script records results and categorizes them as

plaintext faults or diffusion patterns, automatically storing the findings for later analysis.

Glitch Width and Profiling

• Glitch Width: The ideal glitch width is determined through initial profiling with a double

loop counter, applying glitches systematically across the loop count cycle. This

configuration allows precise timing for fault injection, introducing disturbances in the

count results without triggering a reset on the target device.

• Ideal Glitch Width: Based on profiling, the ideal glitch width is set to 160 ns, the most

reliable value determined using a double loop-counting function as a baseline. This

parameter is highly dependent on the electrical parameters of the circuit, including parasitic

elements and used “crowbar” MOSFET.

• Delay Adjustments: The delay window for successful plaintext fault injection is 3.645 to

3.750 microseconds from the start of encryption. To improve reproducibility, the delay

window can be widened to 2,000 - 5,000 nanoseconds.

• Delay Adjustments and Glitcher Latency Observations:

o Notable delay range for effective plaintext leakage:

▪ 3.645–3.750 µs (set) measured as 3.91–4.02µs. The additional delay

(~+270 ns) is introduced by the custom fault injection tool and results from

the tool's MCU’s internal timing overhead, which includes interrupt latency,

function execution time, and maximum timing jitter.

• Recommended Range: To account for the fault injection tool's latency (as described

previously), a broader range of 2,000–5,000 ns is suggested for repeatability. To improve

reproducibility with different fault injection tools, the broader delay window and well

profiled glitch width need to be taken into account.

Nordic Semiconductor ASA.

Page6

5.2 Proof of Concept (PoC)

Tools Used

• Custom low-cost voltage fault injection tool based on Teensy 4.1 Development Board and

“crowbar” MOSFET IRF7303, oscilloscope, logic analyzer, J-Link debug probe,

nRF52840 Multiprotocol Bluetooth 5.4 SoC board (PCA10059-nRF52840 USB Dongle)

working on 64 MHz with enabled Arm® TrustZone® CryptoCell 310.

Steps to Reproduce

1. Modify Power Supply:

o Modify the board to allow an external 3.3 V power supply through the VDDOUT

pin instead of USB by cutting jumper S2 and soldering jumper S1.

Figure 1. Modification of the dongle for external power with jumper changes.

2. Connect the Hardware:

o Attach the MOSFET crowbar circuit to the DEC1 pin CPU (0.8V-0.9V) power line

of the PCA10059-nRF52840 USB Dongle without removing C5, 100nF decoupling

capacitor.

Figure 2. PCA10059-nRF52840 USB Dongle with pinouts for power, debug, and glitch

connections.

Nordic Semiconductor ASA.

Page7

Figure 3. PCA10059-nRF52840 USB Dongle schematic

Figure 4. Target preparation

Nordic Semiconductor ASA.

Page8

Figure 5. Complete glitching and test setup

3. Initialize AES Encryption:

o Initiate AES-128 ECB, CBC, or CTR encryption with predefined key, IV (if using

CBC), and plaintext.

Figure 6. Source code showing AES-128 setup with key, IV, plaintext, and ciphertext buffer.

Nordic Semiconductor ASA.

Page9

Figure 7. Source code showing AES-128 ECB function

Nordic Semiconductor ASA.

Page10

Figure 8. Source code showing AES-128 CBC function

Nordic Semiconductor ASA.

Page11

Figure 9. Source code showing AES-128 CTR function

Nordic Semiconductor ASA.

Page12

4. Apply Voltage Glitch:

o Use the glitch tool to introduce a brief voltage drop by pulsing the crowbar circuit

at targeted intervals during encryption.

o The optimal glitch width (160ns) and timing intervals (set and measured) for

successful fault injection are:

▪ Set Timing: 3.645µs - 3.750µs / Measured: 3.91µs to 4.02µs

5. Trigger Glitch in Synchronization with Encryption:

o The following Python script is used to control glitch process:

Figure 10. Python glitch control script with trigger function and timing parameters.

Nordic Semiconductor ASA.

Page13

6. Record and analyze the AES Output:

o Record the ciphertext buffer output. In successful fault injection cases, the AES

hardware reveals plaintext or partial diffusion patterns instead of full ciphertext

encryption.

Figure 11: Screenshot showing plaintext output in the terminal instead of the expected ciphertext

“bb16b9b2321dce8999c16c9e5ea4d2a3” after successful glitching in AES-128 ECB mode.

Nordic Semiconductor ASA.

Page14

Figure 12: Screenshot showing plaintext output in the terminal instead of the expected ciphertext

“1eeecb7e880782460eb7542b6fd91a67” after successful glitching in AES-128 CBC mode.

Nordic Semiconductor ASA.

Page15

Figure 13: Screenshot showing plaintext output in the terminal instead of the expected ciphertext

“3cf155de2d4d5722c62289f585f28e13” after successful glitching in AES-128 CTR mode.

Nordic Semiconductor ASA.

Page16

Figure 14. Screenshot showing error byte diffusion in the ciphertext after successful glitching,

instead of the expected ciphertext output “bb16b9b2321dce8999c16c9e5ea4d2a3” in AES-128

ECB mode.

Page17

7. Voltage Fault Injection Analysis:

o Analyze the glitch parameters for reproducibility and verify that the glitch timing consistently causes plaintext recovery

or error byte diffusion without affecting other SoC operations.

Figure 15. Oscilloscope capture showing the actual glitch shape and timing aligned with encryption cycle, with glitch delay measured

as 3.92 µs.

Page18

Figure 16. Oscilloscope capture showing glitch width measurement and additional ringing, approximately 640 ns.

Note: The ringing, caused by the circuit's capacitance and inductance, can extend the glitch window but many times can enhance the

fault injection effect.

Page19

Figure 17. Logic analyzer capture showing standard AES encryption time without fault injection, measured as 12.62 µs.

Page20

Figure 18. Logic analyzer capture displaying system reset and the 'E' command received to initiate encryption.

Page21

Figure 19. Logic analyzer capture showing the reduced encryption time due to glitching, measured as 12.02 µs (0.6 µs less than

normal).

Page22

Figure 20. Logic analyzer capture showing the plaintext output transmitted from the MCU to the PC, as observed on the RX line (PC-

side reception)

Nordic Semiconductor ASA.

Page23

6. Remediation Recommendations

Here's a set of practical fault injection countermeasures suitable for microcontrollers and SoCs

where a full redesign isn't feasible. These strategies focus on increasing difficulty for attackers

using software-based and lightweight hardware mitigations, although they do introduce additional

overhead to the process.

1. Execution Redundancy & Verification Techniques

o Double Encryption and Decryption Check: Encrypt the data, then immediately

decrypt it and verify that the result matches the original plaintext. This double-

check helps ensure that the encryption was processed accurately.

o Encrypt-Then-Compare Approach: Perform AES encryption twice on the same

plaintext and check if both outputs match. This redundancy makes it harder for

single faults to go unnoticed.

o Inversion Check: After encryption, verify that the ciphertext does not match the

plaintext. If they match, it could indicate a processing fault or attack attempt. This

basic integrity check ensures that encryption is active.

2. Randomized Timing for Encryption Operations

o Randomized Start Delay: Introduce a small, random delay before beginning the

encryption process. Randomizing the start time of each encryption session disrupts

an attacker’s ability to time fault injections precisely.

3. Lower Clock Frequency During Sensitive Operations

o Frequency Throttling During AES: If possible, temporarily reduce the

microcontroller’s clock speed while performing AES encryption. Many fault

injection techniques rely on precise timing and pre-profiled fault injection

parameters, which becomes more challenging at lower clock frequencies.

4. Control Flow Monitoring for Firmware Application Code

o Control Flow Counters: Implement a counter in the firmware to track the correct

execution path, ensuring that the AES encryption routine is accessed as intended.

o Checksums on Critical Branches: Use checksums for critical checks and branches

in the application code to confirm consistent execution flow and reduce

susceptibility to tampering.

o Constants with Large Hamming Distance: In the application firmware, use

constants with a large Hamming distance for critical values, making it harder for

single-bit faults to alter control flow.

o Nested Checks for High Security: Incorporate layered or nested control flow

checks in the firmware to increase fault tolerance. These nested validations add

redundancy that complicates fault attacks, making each step harder to bypass

undetected.

o Check Complement: Implement checks to ensure that the complement of values

or calculations matches expected results, preventing incorrect execution due to

single-bit faults.

Nordic Semiconductor ASA.

Page24

o Verify Each Branch: After executing each conditional branch, verify that the

outcome matches the expected result, ensuring no unauthorized manipulation

occurred.

o Verify Loop Completion: Confirm that each loop completes its intended number

of iterations, ensuring the integrity of repetitive operations and preventing faults

from prematurely terminating loops.

These techniques target the firmware level rather than the AES hardware engine, making

them feasible additions to sensitive applications requiring enhanced fault resistance

without altering the fixed hardware AES engine.

Each of these methods introduces additional challenges for fault injection attacks by making the

timing and validation of encryption processes less predictable, adding verification steps, and

incorporating basic integrity checks. However, they also introduce some performance and

processing overhead that may need to be managed depending on the microcontroller’s application

and constraints.

7. Additional Information

• References:

o https://www.nordicsemi.com/Products/nRF52840

o https://www.nordicsemi.com/Products/Development-hardware/nRF52840-Dongle

o https://docs.nordicsemi.com/bundle/ps_nrf52840/page/cryptocell.html

o https://docs.nordicsemi.com/bundle/sdk_nrf5_v17.1.0/page/lib_cryptocell.html

o https://blog.quarkslab.com/differential-fault-analysis-on-white-box-aes-

implementations.html

o https://github.com/SideChannelMarvels/JeanGrey

o https://www.infineon.com/cms/en/product/power/mosfet/n-channel/irf7303/

• Disclosure Timeline:

o October 21, 2024: Vulnerability discovered and validated

o November 13, 2024: Reported to Nordic Semiconductor ASA

o November 2024 – April 2025: Ongoing communication and coordination with the

vendor

o April 11, 2025: Public disclosure in coordination with Nordic Semiconductor ASA