Introduction: The Hardening of Tensor SoCs

Google Tensor SoCs, at the heart of Pixel phones, represent a significant leap in mobile computing, integrating AI capabilities directly into the silicon. Alongside performance, these chips feature a robust security architecture, including a hardware-rooted Secure Boot process and a Trusted Execution Environment (TEE). These mechanisms are designed to protect the integrity of the device’s software stack and sensitive user data from a wide range of attacks. However, no system is impenetrable, and hardware-level fault injection, often referred to as ‘glitching,’ remains a powerful technique for security researchers to probe and potentially bypass these protections.

This article delves into the principles of fault injection, specifically how voltage and clock glitching can be applied to Tensor SoCs to disrupt their intended operation, with the ultimate goal of compromising Secure Boot and the TEE. Understanding these attack vectors is crucial for both attackers and defenders in the ongoing cat-and-mouse game of hardware security.

Understanding Fault Injection: Perturbing Silicon Logic

Fault injection is a side-channel attack where an attacker intentionally introduces transient errors into a target system’s operation. By briefly perturbing power supply, clock signals, or electromagnetic fields, it’s possible to cause a CPU or peripheral to misexecute an instruction, skip a check, or reveal internal state. The goal is typically to:

• Bypass integrity checks (e.g., signature verification during boot).
• Alter execution flow (e.g., skip a security-critical branch).
• Induce data corruption (e.g., in sensitive memory regions).
• Extract cryptographic keys or other secrets.

On complex SoCs like Tensor, fault injection requires precise timing and careful targeting, often achieved through iterative experimentation and detailed knowledge of the target’s internal architecture, typically obtained via reverse engineering firmware or, in some cases, hardware.

Voltage Glitching

Voltage glitching involves temporarily dropping or raising the power supply voltage to the SoC or a specific component. This can cause various effects, such as:

• Incorrect instruction decoding.
• Skipping instructions.
• Corrupting data in registers or memory.
• Altering the outcome of conditional branches.

The efficacy depends on the target’s voltage tolerance and the precise timing of the glitch relative to instruction execution. Common targets for voltage glitching are the main SoC power rails, which can be identified via schematics or by physically probing power delivery networks (PDNs) on the PCB.

# Conceptual steps for voltage glitching setup:1. Identify target power rail (e.g., VDD_CORE) for the SoC.2. Connect a fast-switching MOSFET or dedicated fault injector to the rail.3. Use an oscilloscope to characterize the rail's normal operation.4. Initialize the SoC into a known state (e.g., early boot).5. Program the fault injector:   - Set glitch duration (e.g., 5-50 nanoseconds).   - Set glitch amplitude (e.g., drop by 0.5V - 1.0V).   - Set trigger point (e.g., external GPIO, instruction address breakpoint).6. Execute the target code and trigger the glitch synchronously.7. Observe system behavior (e.g., boot log output, debugger).

Clock Glitching

Clock glitching introduces a momentary disruption in the clock signal fed to the SoC. This can manifest as:

• Skipping clock cycles.
• Introducing extra clock cycles.
• Changing the clock frequency momentarily.

Similar to voltage glitching, this can lead to incorrect instruction execution, mis-sequencing of operations, or corrupting state machines. Clock glitching is particularly effective against sequential logic and can be challenging due to the high frequencies involved in modern SoCs.

# Conceptual steps for clock glitching setup:1. Identify target clock line (e.g., CPU clock, peripheral clock).2. Connect a high-speed signal injector capable of manipulating clock edges.3. Use a high-bandwidth oscilloscope to capture the clock signal.4. Load a target firmware component that performs a critical check.5. Program the fault injector:   - Set glitch type (e.g., single cycle omission, frequency shift).   - Set duration (e.g., 1-5 clock cycles).   - Set precise trigger relative to the target instruction.6. Initiate execution and trigger the glitch.7. Monitor for unexpected behavior or bypass of security checks.

Targeting Secure Boot: A Race Against Cryptography

Secure Boot on Tensor SoCs ensures that only cryptographically signed and trusted software can execute. This process typically starts from an immutable Boot ROM, which loads and verifies the first stage bootloader, which in turn verifies subsequent stages. Fault injection aims to disrupt this verification chain.

Bypassing Signature Checks

The most lucrative target during Secure Boot is the signature verification process. If a fault can be injected precisely when the SoC’s hardware security module (HSM) is comparing a hash or verifying a signature, it might be possible to:

• Force a `TRUE` result for a `strcmp` or `memcmp` operation, even if the signatures don’t match.
• Skip the entire verification function.
• Corrupt the cryptographic hash value being computed, making a malicious hash appear valid.

Successful execution of such a glitch would allow an attacker to load and execute an unsigned, custom bootloader, gaining full control over the device before the OS even starts. This is often the holy grail for hardware attackers.

# Example: Conceptual target for a secure boot bypass if (verify_signature(bootloader_image, public_key)) {    jump_to_bootloader(bootloader_image); } else {    panic("Signature verification failed"); } # Attacker aims to glitch the 'if' condition to always be true, or skip the 'else' branch.

Compromising the Trusted Execution Environment (TEE)

The TEE (often based on ARM TrustZone) provides a hardware-isolated environment for sensitive operations like key storage, biometric authentication, and DRM. It runs a ‘Trusted OS’ alongside the untrusted ‘Rich OS’ (Android). Attacking the TEE is incredibly challenging due to its isolation, but fault injection offers a unique avenue.

Exploiting Trusted Applications (TAs) and OS Services

Within the TEE, Trusted Applications (TAs) perform specific security-critical tasks. A fault injection attack might target:

• **TA Loading/Verification**: Disrupting the verification of a TA’s integrity upon loading, potentially allowing a malicious TA to run.
• **Memory Accesses**: Causing a TA to incorrectly access or expose data from its secure memory, or from another TA’s memory space.
• **Crypto Operations**: Inducing errors in cryptographic routines within the TEE, potentially leaking partial key material or causing predictable output.

The TEE’s secure memory regions are usually protected by Memory Protection Units (MPUs) and Memory Management Units (MMUs). Glitching can potentially corrupt these control registers or the memory controller itself, leading to temporary bypass of memory access restrictions.

# Hypothetical scenario: Glitching a TEE service call# Target: A service within a TA that decrypts user data.# Goal: Corrupt the decryption key pointer or the data itself during processing.def decrypt_sensitive_data(encrypted_blob, key_id):    # ... TEE internal logic to retrieve key ...    key_ptr = get_key_from_store(key_id)    # Fault injection here might corrupt key_ptr or the data buffer    decrypted_data = AES_decrypt(encrypted_blob, key_ptr)    return decrypted_data# An attacker would try to trigger a glitch during the 'get_key_from_store' or 'AES_decrypt' phases.

Methodology and Tooling

Successful fault injection is an iterative process requiring specialized hardware and deep firmware understanding.

• Hardware Setup

  • **Fault Injector**: Devices like ChipWhisperer or custom FPGA-based solutions provide precise control over voltage/clock glitches.
  • **Oscilloscope**: High-bandwidth scopes are essential for monitoring target signals and precisely timing glitches.
  • **Probes**: Differential probes, active probes, and micro-probes for connecting to fine-pitch SoC pins or PCB traces.
  • **Target Board**: The Tensor SoC device (e.g., a Pixel phone motherboard) prepared for probing, often requiring decapsulation (delidding) of the SoC package to access internal die features or power bumps.

• Software Analysis

  • **Firmware Reverse Engineering**: Using tools like Ghidra or IDA Pro to analyze bootloaders, secure ROM code (if dumped), and TEE binaries to identify target functions, vulnerable instructions, and precise trigger points.
  • **Debugging**: JTAG/SWD debuggers (if available or enabled) are crucial for setting breakpoints and observing the effects of glitches.
  • **Scripting**: Python is commonly used to automate glitching campaigns, adjusting parameters, and analyzing results.

• Iterative Process

  1. **Identify Target**: Locate specific code paths or hardware operations to attack.
  2. **Prepare Hardware**: Connect fault injection equipment to the target.
  3. **Characterize**: Determine normal operational parameters (voltage, clock).
  4. **Develop Trigger**: Find a reliable way to trigger the glitch at the precise moment (e.g., instruction address, GPIO toggle).
  5. **Iterate Parameters**: Systematically vary glitch duration, amplitude, and delay.
  6. **Analyze Results**: Monitor device behavior, crash logs, or debugger output for signs of successful fault injection.

Conclusion

Fault injection remains a potent weapon in the arsenal of hardware security researchers. While Tensor SoCs are designed with multiple layers of defense, their reliance on precise electrical and timing operations creates potential vulnerabilities to techniques like voltage and clock glitching. The ability to disrupt Secure Boot and compromise the TEE would grant an attacker unprecedented control over the device, bypassing critical security features. As SoCs become more integrated and complex, the precision required for these attacks increases, but the fundamental principles of perturbing silicon logic remain a persistent challenge for hardware security.