Bypassing Secure Boot Using Fault Injection

Presented at Black Hat Europe 2016, Nov. 4, 2016, noon (60 minutes)

More and more embedded systems implement Secure Boot to assure the integrity and confidentiality of all software executed after power-on reset. These implementations are bypassed using logical flaws, for example as shown in the following iPhone boot ROM exploits: SHAtter [1] and limera1n [2]. However, the early stages of Secure Boot (i.e. ROM or 1st stage bootloader) are often of insignificant size and therefore logically exploitable vulnerabilities are not guaranteed to be present. In such situations, other attacks may be used to exploit the embedded system. An example of such an attack is Fault Injection, which works by injecting faults into the target to change its intended behavior. The early stages of Secure Boot are executed in a privileged context and therefore interesting to gain control of before mounting other attacks compromising the target's assets (e.g. encryption keys, code, data, privileged access).<br /> <br /> The community has produced various papers and presentations about Fault Injection and Secure Boot. Some notable examples are: Exide's talk at Recon 2014 [3] and Brett Miller's talk at Blackhat Europe 2015 [4] cover the principles of Fault Injection. Also, Colin O'Flynn's continuous efforts show casing his open source Fault Injection test bench: Chip Whisperer [5][6]. Job de Haas' presentation at HITB 2013 [7] details the complete, but high level, attack surface of Secure Boot.<br /> <br /> This talk starts with a brief introduction to both Secure Boot and Fault injection which form the foundation of the rest of the talk. For example, we will introduce the different Fault Injection techniques and briefly describe the characteristics. But we refrain from describing Fault Injection attacks in detail as these are already covered by the community. As this talk builds upon the efforts produced by the community, we go into greater detail about different strategies to bypass Secure Boot.<br /> <br /> The Fault Injection attack surface of Secure Boot implementations is determined by the specifics of their design and implementation. Using a generic Secure Boot design we detail multiple vulnerabilities (~10) using examples in source code, disassembly and hardware. We will determine what the impact is of the target's design on its Fault Injection attack surface: from high-level architecture to low-level implementation details. We will consider: dedicated peripherals (e.g. DMA), enforced decryption of the software, specific code constructs, fault injection countermeasures, compiler optimizations and the instruction set. Based on those considerations we describe novel attack strategies, including a combination of fault injection and software exploitation.<br /> <br /> Additionally, we provide insights on how to overcome challenges (timing, target modification, glitch shape, etc.) faced when performing Fault Injection attacks on high speed feature rich System on Chips (SOC) such as those found in smart phones.<br /> <br /> The practicality of voltage Fault Injection attacks on a fast (~1 GHz) and feature rich system on chip (SOC) is demonstrated using two live demos: <br /> 1. Fault injection demo 1: target characterization<br /> 2. Fault injection demo 2: bypassing Secure Boot<br /> <br /> We conclude this talk with an overview of good and bad practices when implementing software and hardware countermeasures against fault injection. These can be used by the developers of Secure Boot implementations to minimize the risk of Fault Injection attacks.<br /> <br /> Sources:<br /> [1]:<br /> [2]:<br /> [3]:<br /> [4]:<br /> [5]:<br /> [6]:<br /> [7]:


  • Niek Timmers - Senior Security Analyst, Riscure
    Niek Timmers is a Senior Security Analyst at Riscure where he analyzes and tests, among other things, the security of SOCs and embedded systems. His primary interest is hardware and low-level software. At the moment his primary research topic are Fault Injection attacks. However, never a week goes by without disassembling, analyzing or emulating some random binary.
  • Albert Spruyt - Senior Security Analyst, Riscure
    Albert Spruyt is a Senior Security Analyst at Riscure, where he tries to best systems. He is fascinated by the area where crypto rubber meets the hardware road. Where he builds stuff to take things apart.


Similar Presentations: