Beyond cryptography, what hardware-level vulnerabilities are a concern in SoCs?

Silicon security has traditionally focused on cryptography, including hardening crypto-accelerators and protecting key storage. In System-on-Chip (SoC) design, this approach is insufficient. An SoC integrates multiple components, such as cores, memory, and third-party IP blocks, onto a single die. This integration introduces hardware-level vulnerabilities that do not target the cryptographic algorithms themselves.

Instead, these threats exploit the physical implementation and architectural structure of the chip. For system architects and engineers, it is necessary to understand these vulnerabilities. So, precisely where do these non-cryptographic risks lie? These concerns can be grouped into three main categories: side-channel attacks, fault injection attacks, and architectural isolation flaws.

Side-channel attacks

Side-channel attacks (SCAs) passively exploit unintended information leakage from hardware during operation. This leakage can include variations in power consumption, electromagnetic emanations, or timing (CWE-1300).

While many known SCAs target high-performance CPUs, resource-constrained microcontrollers (MCUs) are also vulnerable. MCUs can exhibit timing side channels that exploit memory bus arbitration and on-chip communication structures.

This scenario is illustrated in Figure 1. The attack is a three-phase process that uses SoC components to observe a victim task:

Figure 1. A three-phase timing side-channel attack on an MCU. (Image: arXiv)

Preparation phase: A malicious software task (attacker) on the CPU configures a peripheral, such as a DMA controller or a Timer, to act as an observation tool.
Recording phase: After a context switch, the trusted victim task executes. When the victim accesses memory (3), it creates contention on the shared interconnect. This bus contention is also experienced by the configured peripheral (2), causing a subtle delay in its operation (e.g., delaying the start of a timer).
Retrieval phase: The attacker task regains control, reads the peripheral’s state (4) (e.g., the timer value), and infers the victim’s memory access patterns from the measured delay.

Fault injection attacks

But, what if an attacker wants to do more than just passively listen? Fault injection attacks (FIAs) deliberately induce errors in hardware to manipulate computation, bypass security checks, or extract secrets.

While commonly observed FIA vulnerabilities involve physical methods, such as voltage glitching or electromagnetic fault injection (CWE-1332), a more recent variant is software-controlled fault injection.

The “V0LTpwn” attack, for example, exploits software-exposed power-management interfaces to undervolt physical cores. As shown in Figure 2, this attack proceeds in three phases:

Figure 2. Workflow for a software-controlled fault injection attack like V0LTpwn. (Image: USENIX)

Phase 1 (Offline Analysis): The attacker performs “Voltage Analysis” on a representative chip to identify an “exploitable voltage window” that induces errors without causing a system crash.
Phase 2 (Online Analysis): The attacker profiles the specific target chip to find the most fault-prone core.
Phase 3 (Attack): The attacker uses software to trigger a “Timed Undervolting” event while the victim program is running. This forces hardware faults and compromises the integrity of the computation.

Architectural and isolation flaws

Even if individual components are secure, what risks emerge from the way they are connected? This category of vulnerability arises from the integration of multiple IP cores, often from third-party vendors, on a shared bus. The security risk originates from the interconnects.

Figure 3. A typical IoT SoC subsystem integrates multiple IP cores on a shared interconnect. (Image: Springer Nature)

Figure 3, a block diagram for an ARM-based IoT subsystem, illustrates this challenge. It shows a Cortex-M3 processor, a multi-layer AHB (Advanced High-performance Bus) interconnect, and various IPs, including “Non ARM IP” such as a DMA and WiFi Radio. This architecture can lead to two primary flaws:

Bus snooping: A malicious or compromised IP (like a Hardware Trojan in the WiFi radio) connected to the shared AHB interconnect can passively monitor unencrypted data transferred between the CPU, SRAM, and other peripherals.
Improper SoC resource isolation (CWE-1189): This is a design flaw where the bus architecture fails to properly separate resources between trusted and untrusted components. If the interconnect does not enforce access control rules, the WiFi IP might directly access a secure memory region, bypassing any software-level permissions.

Summary

A comprehensive SoC security strategy must extend beyond cryptographic algorithms. It must also account for vulnerabilities in the chip’s physical implementation and architectural design. These include passive information leakage via side-channels, active manipulation through fault injection, and data breaches caused by improper isolation between integrated IP cores on a shared bus. Addressing these threats requires a holistic verification process that validates the entire hardware system.