SoK: A Security Architect's View of Printed Circuit Board Attacks

TL;DR

Over fifty PCBA attacks are reviewed to show how most can be prevented by proper architecture and careful implementation, and which tampering threats can be mitigated by PCBA security architecture.

Abstract

Many recent papers have proposed novel electrical measurements or physical inspection technologies for defending printed circuit boards (PCBs) and printed circuit board assemblies (PCBAs) against tampering. As motivation, these papers frequently cite Bloomberg News' "The Big Hack", video game modchips, and "interdiction attacks" on IT equipment. We find this trend concerning for two reasons. First, implementation errors and security architecture are rarely discussed in recent PCBA security research, even though they were the root causes of these commonly-cited attacks and most other attacks that have occurred or been proposed by researchers. This suggests that the attacks may be poorly understood. Second, if we assume that novel countermeasures and validation methodologies are tailored to these oft-cited attacks, then significant recent work has focused on attacks that can already be mitigated instead of on open problems. We write this SoK to address these concerns. We explain which tampering threats can be mitigated by PCBA security architecture. Then, we enumerate assumptions that security architecture depends on. We compare and contrast assurances achieved by security architecture vs. by recently-proposed electrical or inspection-based tamper detection. Finally, we review over fifty PCBA attacks to show how most can be prevented by proper architecture and careful implementation.

Figures (4)

• Figure 1: Only interactions where both parties can use cryptographic protocols can be protected by security architecture.
• Figure 2: Depending on what attacks must be stopped and when attacks are anticipated, different defenses are needed.
• Figure 3: The Xbox 360 architecture. Visualizes key components and establishes terminology used in our discussion.
• Figure 4: Summary of the Xbox 360 boot process. The 1bl, located in the CPU die, decrypts the 2bl into CPU-internal SRAM and verifies its RSA signature free60_boot_nodate before loading it. The 2bl checks the device's fuse set and may abort boot if the fuses indicate that the running 2bl is outdated. The 2bl also initializes RAM and the CPU's transparent encryption engine before decrypting the 4BL into RAM. Note that the the 2bl was eventually divided into two parts, 2BL-A and 2BL-B, but this is immaterial for our discussion. The 4BL verifies and decrypts the base kernel into RAM. Note that the manner of verification and keys involved in 4BL decryption changed across versions and these changes were significant for attackers noauthor_jtag_nodate. The 4BL also performs a second fuse check and compares the fuse set with the ldv from the header of BL Section 0. If the fuses and BL Section 0 header do not match, the 4BL launches the 6BL and 7BL from additional BL sections until one of their ldv matches the device's fuse set. An update's 6BL and 7BL work together to patch the base kernel that was loaded into RAM by the 4BL. Finally, after all updates have been applied, the Xbox runs the patched kernel from RAM.