DOCSLIB.ORG

Bootkeeper: Validating Software Integrity Properties on Boot Firmware Images

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Bootkeeper: Validating Software Integrity Properties on Boot Firmware Images Session 8: System Security and Authentication CODASPY ’19, March 25–27, 2019, Richardson, TX, USA BootKeeper: Validating Software Integrity Properties on Boot Firmware Images Ronny Chevalier Stefano Cristalli Christophe Hauser CentraleSupélec, Inria, Univ Rennes, Università degli Studi di Milano University of Southern California CNRS, IRISA [email protected] [email protected] [email protected] Yan Shoshitaishvili Ruoyu Wang Christopher Kruegel Arizona State University Arizona State University University of California, Santa [email protected] [email protected] Barbara [email protected] Giovanni Vigna Danilo Bruschi Andrea Lanzi University of California, Santa Università degli Studi di Milano Università degli Studi di Milano Barbara [email protected] [email protected] [email protected] ABSTRACT Boot Firmware Images. In Ninth ACM Conference on Data and Application Boot firmware, like UEFI-compliant firmware, has been the target Security and Privacy (CODASPY ’19), March 25–27, 2019, Richardson, TX, USA. of numerous attacks, giving the attacker control over the entire ACM, New York, NY, USA, 11 pages. https://doi.org/10.1145/3292006.3300026 system while being undetected. The measured boot mechanism of a computer platform ensures its integrity by using cryptographic 1 INTRODUCTION measurements to detect such attacks. This is typically performed by relying on a Trusted Platform Module (TPM). Recent work, however, One of the most critical components of every computer is the shows that vendors do not respect the specifications that have been boot firmware (e.g., BIOS or UEFI-compliant firmware), which isin devised to ensure the integrity of the firmware’s loading process. charge of initializing and testing the various hardware components, As a result, attackers may bypass such measurement mechanisms and then transfer execution to the Operating System (OS). As a and successfully load a modified firmware image while remaining result of its early execution, the boot firmware is a highly privileged unnoticed. In this paper we introduce BootKeeper, a static anal- program. Any malicious alteration of its behavior can have critical ysis approach verifying a set of key security properties on boot consequences on the entire system. An attacker that can control the firmware images before deployment, to ensure the integrity ofthe firmware can control any parts of the software and undermine the measured boot process. We evaluate BootKeeper against several at- security of the entire OS. Without any protection of the integrity tacks on common boot firmware implementations and demonstrate of the boot firmware, we cannot assure any security properties of its applicability. the software executing on the system. To guarantee the software integrity of the machine, the Trusted CCS CONCEPTS Computing Group (TCG), an industry coalition formed to imple- ment trusted computing concepts across personal computers, de- • Security and privacy → Systems security. signed a new set of hardware components, the aim of which is to solve various hardware-level trust issues. In their specification, KEYWORDS they define the TPM, which is composed of a co-processor that firmware, TPM, SCRTM, binary analysis offers cryptographic functions (e.g., SHA-1, RSA, random number ACM Reference Format: generator, or HMAC) and a tamper-resistant non-volatile mem- Ronny Chevalier, Stefano Cristalli, Christophe Hauser, Yan Shoshitaishvili, ory used for storing cryptographic keys [33]. The TPM along with Ruoyu Wang, Christopher Kruegel, Giovanni Vigna, Danilo Bruschi, and An- other software components together form a root of trust, which drea Lanzi. 2019. BootKeeper: Validating Software Integrity Properties on is leveraged as part of several security mechanisms, including the measured boot process. With measured boot, platforms with a TPM Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed can be configured to measure every component of the boot process, for profit or commercial advantage and that copies bear this notice and the full citation including the firmware, boot loader, and kernel. Such measurement on the first page. Copyrights for components of this work owned by others than ACM process is also called the Static Root of Trust for Measurement must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a (SRTM). fee. Request permissions from [email protected]. The core of trust of the entire process is established based on CODASPY ’19, March 25–27, 2019, Richardson, TX, USA the integrity of the first piece of code inside the boot firmware © 2019 Association for Computing Machinery. ACM ISBN 978-1-4503-6099-9/19/03...$15.00 which is doing the first measurements, also called the Static Core https://doi.org/10.1145/3292006.3300026 Root of Trust for Measurement (SCRTM) [41]. In the event where a 315 Session 8: System Security and Authentication CODASPY ’19, March 25–27, 2019, Richardson, TX, USA malicious modification of the SCRTM successfully hides from the efficacy of our approach. Our paper makes the following contribu- self-measurement technique, the whole chain of trust and, conse- tions: quently, the integrity of the entire system may be broken. In this • We devise a set of software properties that can be used for direction, Butterworth et al. [4] described different examples of validating the measurement process and mitigate firmware attacks against the SCRTM component. In particular, the authors attacks aimed to subvert the entire system. show how a novel “tick” malware, a 51-byte patch to the SCRTM, • We design and implement BootKeeper, a binary analysis can replay a forged measurement to the TPM, falsely indicating approach to detect and prevent measurement boot firmware that the BIOS is genuine. These attacks take advantage of the fact attacks in different attack scenarios. that some vendors do not measure the SCRTM code, thus allowing • We perform experimental evaluation against different at- an attacker to modify it and to forge measurements without being tacks and several boot firmware implementations to demon- detected. strate the effectiveness of our approach. Recent platforms incorporate an immutable, hardware protected SCRTM [11, 23]. Intel Boot Guard and HP Sure Start are immutable 2 BACKGROUND SCRTMs which measure and verify, at boot time, the integrity of the In this section, we introduce the background technology needed BIOS image before executing it. Such technologies are not directly to understand our approach. We first describe the principles of the vulnerable to the aforementioned attacks, since their code cannot TPM, then we describe the UEFI specifications and some of the be modified by an attacker.1 Both technologies, however, are only software/hardware components involved in the boot measurement available in recent Intel and HP platforms, leaving previous hard- process. ware implementations, or devices of other vendors, vulnerable against forged measurements. In such implementations, since the SCRTM is 2.1 Trusted Platform Module (TPM) not hardware protected, it is usually attached to the firmware image itself during the firmware update process. Even when the firmware The TPM specification defines a co-processor offering cryptographic image is signed, attacks may compromise this process [14], and features (e.g., SHA-1, RSA, random number generator, or HMAC), consequently allow an attacker to modify both the firmware code and tamper-resistant storage for cryptographic keys [33]. and the SCRTM. The TPM provides a minimum of 16 Platform Configuration In order to solve these challenges in validating the SCRTM code, Register (PCR) which are 160-bit wide registers used to store the we design a self-contained approach based on static analysis at the measurements done by the SCRTM (usually SHA-1 hashes). The de- binary level, which is able, starting from a boot firmware image, sign of these registers allows an unlimited amount of measurements to validate the correctness of the measurement process. Our sys- and prevents an attacker from overwriting them with arbitrary val- tem verifies software properties on the SCRTM code embedded ues. In order to do this, the only possible operation is extend: in firmware images, including: (1) the completeness of firmware PCRi = H¹PCRi jj mº code measurements in terms of fingerprinted memory regions, (2) the correctness of cryptographic functions implemented2 inside Where PCRi is the ith PCR register, H is the hash function and the SCRTM (e.g., SHA-1), and (3) the correctness of the SCRTM’s m the new measurement. The TPM concatenates each new measure- control flow. More in detail, the first property ensures that thecode ment sent with the previous value of the register, then it hashes of the entire firmware is measured correctly by the SCRTM, i.e., that the result, which becomes the new value of the register. This mech- none of the instructions to be executed at runtime will be missed anism is crucial to establishing a chain of trust, since the only way by the measurement process. The second property ensures that the to obtain a given measurement value from a PCR is to reproduce implementation of cryptographic functions inside the SCRTM is the same series of measurements in the same order. The measured correct. The third property validates the correctness of the measure- boot process relies on this mechanism to guarantee that a given ment operations performed by the SCRTM in terms of execution software platform is valid and has not been tampered with. order. It also guarantees the atomicity of operations occurring be- The TPM also relies on these measurements to provide specific tween memory fingerprinting and write operations performed on features (e.g., secure storage or remote attestation). For instance, the TPM component (i.e., ensuring that what is measured is what is with the sealing operation, the TPM offers the ability to encrypt data, written to the TPM).
Load more

Recommended publications
  • CIS 4360 Secure Computer Systems Attacks Against Boot And
    CIS 4360 Secure Computer Systems Attacks against Boot and RAM Professor Qiang Zeng Spring 2017 Previous Class • BIOS-MBR: Generation I system boot – What BIOS and MBR are? – How does it boot the system? // Jumping to MBR – How does multi-boot work? // Chain-loading • The limitations of BIOS and MBR – Disk, memory, file system, multi-booting, security, … • UEFI-GPT: Generation II system boot – What UEFI and GPT are? – How does it boot the system? // UEFI boot manager – How does multi-boot work? // separate dirs in ESP CIS 4360 – Secure Computer Systems 2 Limitations of BIOS-MBR • MBR is very limited – Support ~2TB disk only – 4 primary partitions at most (so four OSes at most) – A MBR can store only one boot loader • BIOS is very restrictive – 16-bit processor mode; 1MB memory space (little spare space to accommodate a file system driver) – Blindly executes whatever code on MBR CIS 4360 – Secure Computer Systems 3 UEFI vs. BIOS • Disk partitioning schemes – GPT (GUID Partition Table): part of UEFI spec.; to replace MBR – MBR supports disk size 232 x 512B = 2TB, while UEFI supports much larger disks (264 x 512B ＝ 8,000,000,000 TB) – MBR supports 4 partitions, while GPT supports 128 • Memory space – BIOS: 20-bit addressing; UEFI: 32-bit or 64-bit • Pre-OS environment – BIOS only provides raw disk access, while UEFI supports the FAT file system (so you can use file names to read files) • Booting – BIOS supports boot through boot sectors (MBR and VBR) – UEFI provides a boot partition of hundreds of megabytes (and boot manager and secure boot) CIS 4360 – Secure Computer Systems 4 Previous Class How does dual-boo-ng of Linux and Windows work in UEFI-GPT? Each vendor has a separate directory storing its own boot loader code and configuraon files in the ESP (EFI System Par--on).
    [Show full text]
  • Data Security Features for Ssds
    A MICRON WHITE PAPER Data Security Features for SSDs Micron® self-encrypting SSDs are easy-to-use, cost- effective solutions that protect important stored data from intrusion or loss. Introduction Realizing that data security was fast becoming one of the most pressing issues facing the information technology industry, Micron was among the first manufacturers to bring full drive encryption capability to solid state drives with our self-encrypting drives (SEDs). Micron has now shipped several generations of SSDs that feature hardware encryption. This paper covers the basics of encryption — a key tool in data storage security — including discussions about: • Different data storage encryption schemes, such as file/folder encryption and full-drive en- cryption (FDE). • SEDs as data protection tools, covering methods to manage encryption and SEDs, including management of these security features in concert with software on the host computer. • Industry and government protocols that ensure consistency and conformity of data security systems. These include protocols from the Trusted Computing Group (TCG) and requirements of the Federal Information Protection Standard (FIPS). Encryption Explained Put simply, encryption is an arithmetic tool used to keep data private between the sender and intended recipient. It uses mathematical algorithms and randomly derived keys to convert data from its original “clear text” to unreadable “cipher text.” Cipher text can only be read using the same key and reverse-deciphering algorithm. Methods of encrypting data range from the simple (for example, ROT13), to the complex (ENIGMA), to the extremely complex and robust (AES). 1 A MICRON WHITE PAPER A MICRON WHITE PAPER Data Security Features for SSDs Simple Encryption Example: ROT13 One of the simplest (and oldest) encryption mechanisms is rotation.
    [Show full text]
  • Analysing Android's Full Disk Encryption Feature
    Analysing Android’s Full Disk Encryption Feature Johannes Gotzfried¨ ∗ and Tilo Muller¨ Friedrich-Alexander-Universitat¨ Erlangen-Nurnberg,¨ Germany fjohannes.goetzfried, [email protected] Abstract Since Android 4.0, which was released in October 2011, users of Android smartphones are pro- vided with a built-in encryption feature to protect their home partitions. In the work at hand, we give a structured analysis of this software-based encryption solution. For example, software-based encryption always requires at least a small part of the disk to remain unencrypted; in Android this is the entire system partition. Unencrypted parts of a disk can be read out and are open to system manipulations. We present a tool named EvilDroid to show that with physical access to an encrypted smartphone only (i.e., without user level privileges), the Android system partition can be subverted with keylogging. Additionally, as it was exemplary shown by attacks against Galaxy Nexus devices in 2012, Android-driven ARM devices are vulnerable to cold boot attacks. Data recovery tools like FROST exploit the remanence effect of RAM to recover data from encrypted smartphones, at worst the disk encryption key. With a Linux kernel module named Armored, we demonstrate that Android’s software encryption can be improved to withstand cold boot attacks by performing AES entirely on the CPU without RAM. As a consequence, cold boot attacks on encryption keys can be defeated. We present both a detailed security and a performance analysis of Armored. Keywords: cold boot, evil maid, Android, cpu-bound encryption 1 Introduction Smartphones are long since part of the privacy sphere of their owners, and consequently, a missing smartphone that falls into the wrong hands has severe consequences for its owner.
    [Show full text]
  • Digital Forensics
    Advanced Security for Systems Engineering – VO 08: Digital Forensics Clemens Hlauschek, Christian Brem INSO – Industrial Software Institute of Information Systems Engineering | Faculty of Informatics | TU Wien Contents Forensics – Anti-Forensics Political/Historical Context: End-to-end Encryption Forensic Science Acquire-Analyze-Present Cryptographic Attacks and Limitations Common Attacks against Crypto Analysis of Encypted Traffic Disk encryption Advanced Security for Systems Engineering WS20 | Forensics 2 / 37 Forensics – Anti-Forensics Advanced Security for Systems Engineering WS20 | Forensics 3 / 37 End-to-end Encryption Debate ■ Australia passes Assistance & Access Act (December 2018): allows to secretly compel companies and individuals to re-engineer IT Systems for spying ■ EU Council agrees on e-Evidence proposal (December 2018): access data ■ FBI vs Apple encryption dispute (2016) ■ NSA/Snowden (2013): Dual EC DRBG backdoor, etc ■ Crypto War: Crypto export restrictions (until 1996), Clipper Chip, weak SSL keys, PGP, A5/1 Advanced Security for Systems Engineering WS20 | Forensics 4 / 37 CLEAR Proposal and Technial Discussion Secure access to encrypted storage for 3rd parties without risiking mass surveillance abuse? ■ Ray Ozzie (2018): CLEAR Proposal: Key escrow, per-device key pair for encrypting passcode, acess to device and vendor request necessary, secure hardware to ‘brick’ phone: forensic r/o lock mode. ■ Savage: Lawful Device Access without Mass Surveillance Risk (CCS’18): self-escrow of access credentials in secure time-vaulting
    [Show full text]
  • Trusted Systems in Untrusted Environments: Protecting Against Strong Attackers
    Trusted Systems in Untrusted Environments: Protecting against Strong Attackers Vertrauenswürdige Systeme in nicht vertrauenswürdigen Umgebungen: Schutz vor starken Angreifern Der Technischen Fakultät der Friedrich-Alexander-Universität Erlangen-Nürnberg zur Erlangung des Doktorgrades Dr.-Ing. vorgelegt von Johannes Götzfried aus Amberg Als Dissertation genehmigt von der Technischen Fakultät der Friedrich-Alexander-Universität Erlangen-Nürnberg Tag der mündlichen Prüfung: 7. Dezember 2017 Vorsitzender des Promotionsorgans: Prof. Dr.-Ing. Reinhard Lerch Gutachter: Prof. Dr.-Ing. Felix Freiling Prof. Dr. Ir. Ingrid Verbauwhede Abstract In this thesis, we investigate possibilities of operating trusted systems within untrusted environments in the presence of strong attackers. We consider attackers with physical access to a system as well as root-level attackers which are able to execute code on the target system at the highest privilege level possible. Our proposed defense mechanisms range from hardware-based trusted computing architectures over hardware-assisted software solutions to pure software-based encryption schemes. First, we design two hardware-based trusted computing architectures for embedded devices, called Soteria and Atlas, which both protect against root-level attackers and focus on code and data confidentiality. At its heart, Soteria is a lightweight program-counter based memory access control extension which provides integrity, authenticity, and confidentiality guarantees for software modules. To guarantee the confidentiality of code at any given point in time against all software attacks, we design a scheme consisting of initially encrypted software modules and loader modules. Mutual integrity checks between software modules and the loader ensure that a software module is only decrypted if the system behaves with integrity. Atlas protects software modules with the help of an encryption unit placed between the cache and main memory.
    [Show full text]
  • How to Not Be Hacked
    The Motherboard Guide to Not Getting Hacked VERSION_1.0 UPDATED_11.14.17 The Motherboard Guide to Not Getting Hacked One of the questions we are asked most often at Motherboard is This guide isn’t comprehensive and it’s not personalized; there is “how can I prevent myself from getting hacked?” no such thing as “perfect security” and there are no one-size-fits all solutions. Instead, we hope this will be a jumping-off point for Because living in modern society necessitates putting an uncom- people looking to batten down the hatches on their digital lives. fortably large amount of trust in third parties, the answer is often “not a whole lot.” Take, for example, the massive Equifax hack That’s why we’ve tried to keep this guide as accessible as that affected roughly half of the American population: Few peo- possible, but if you run into any lingo you don’t know, there’s a ple voluntarily signed up for the service, and yet their information glossary at the end of this guide to help out. was stolen anyway. This guide is the work of many people on Motherboard staff both Hackers steal hundreds of millions of passwords in one swoop past and present, and has been vetted by several of our sources, and occasionally cause large-scale blackouts. The future is who we owe a great debt to. Large sections of it were written by probably not going to get better, with real-life disasters caused by Lorenzo Franceschi-Bicchierai, Joseph Cox, Sarah Jeong, and internet-connected knick-knacks, smart home robots that could Jason Koebler, but the tips within it have grown out of years of kill you, flying hacker laptops, and the dangers of hackers getting writing and research on digital security by dozens of reporters your genetic data.
    [Show full text]
  • Uefisecure Boot in Modern Computer Security Solutions
    UEFI SECURE BOOT IN MODERN COMPUTER SECURITY SOLUTIONS September 2013 Revised: August 2019 Authors: Richard Wilkins, Ph.D. Phoenix Technologies, Ltd. [email protected] Brian Richardson Intel Corporation [email protected] OVERVIEW What is the UEFI Forum? The Unified Extensible Firmware Interface (UEFI) Forum is a world-class non-profit industry standards body that works in partnership to enable the evolution of platform technologies. The UEFI Forum champions firmware innovation through industry collaboration and the advocacy of a standardized interface that simplifies and secures platform initialization and firmware bootstrap operations. Both developed and supported by representatives from more than 350 industry-leading technology companies, UEFI specifications promote business and technological efficiency, improve performance and security, facilitate interoperability between devices, platforms and systems, and comply with next-generation technologies. What is UEFI Secure Boot, and how did it originate? UEFI Secure Boot was created to enhance security in the pre-boot environment. UEFI Forum members developed the UEFI specification, an interface framework that affords firmware, operating system and hardware providers a defense against potential malware attacks. Without UEFI Secure Boot, malware developers can more easily take advantage of several pre-boot attack points, including the system-embedded firmware itself, as well as the interval between the firmware initiation and the loading of the operating system. Malware inserted at this point can provide an environment in which an operating system—no matter how secure—cannot run safely. Secure Boot helps firmware, operating system and hardware providers cooperate to thwart the efforts of malware developers. Additional background on the intent of UEFI Secure Boot can be found in "UEFI Networking and Pre-OS Security," published in the Intel Technology Journal [1].
    [Show full text]
  • Tamperproof Authentication to Resist Keylogging 1 Introduction
    Stark Tamperproof Authentication to Resist Keylogging Tilo M¨uller,Hans Spath, Richard M¨ackl, and Felix C. Freiling Department of Computer Science Friedrich-Alexander-University, Erlangen, Germany Abstract. The weakest link in software-based full disk encryption is the authentication procedure. Since the master boot record must be present unencrypted in order to launch the decryption of remaining system parts, it can easily be manipulated and infiltrated by bootkits that perform keystroke logging; consequently password-based authentication schemes become attackable. The current technological response, as enforced by BitLocker, verifies the integrity of the boot process by use of the trusted platform module. But, as we show, this countermeasure is insufficient in practice. We present Stark, the first tamperproof authentication scheme that mutually authenticates the computer and the user in order to resist keylogging during boot. To achieve this, Stark combines two ideas in a novel way: (1) Stark implements trust bootstrapping from a secure token (a USB flash drive) to the whole PC. (2) In Stark, users can securely verify the authenticity of the PC before entering their password by using one-time boot prompts, that are updated upon successful boot. Keywords: Disk Encryption, Evil Maid Attacks, Authentication, TPM 1 Introduction Full disk encryption (FDE) protects sensitive data against unauthorized access in the event that a device is physically lost or stolen. The risk of data exposure is reduced by rendering disks unreadable to unauthorized users through encryption technologies like AES [11]. Unlike file encryption, FDE encrypts whole disks automatically on operating system level, without the need to take action for single files.
    [Show full text]
  • Security of Hard Disk Encryption
    Security of Hard Disk Encryption USMAN YOUSUF Degree project in Information and Communiation Systems Security Stockholm, Sweden 2013 TRITA-ICT-EX-2013:92 SECURITY OF HARD DISK ENCRYPTION Abstract| Abstract In order to provide confidentiality to digital information and safety to computer hard disk, encryption is considered to be best solutions. Now a day, several hard disks encryption software’s with a range of different features are commercially available. Majority of the software uses that encryption algorithm, whose cryptanalyses are already known. Now the vital question is that how much these encryption software’s provide security to the data. Any implementation and design flaw leave loop hole or backdoors in these softwares. Either by take the advantage of user unawareness or by using any external hardware, software’s security can be defeated by using smart and easy methods. This thesis will provide possible weaknesses and vulnerabilities of commercially available hard disk encryption software, who offering complete security to the hard disk data. This thesis will also access the real world performance of hard disk encryption softwares. i SECURITY OF HARD DISK ENCRYPTION Acknowledgement| Acknowledgement First of all, I wish to thank ALMIGHTLY GOD for providing me strength and courage to continuously hunt which is so called knowledge. I am most grateful to Prof. Sead Muftic supervising and guiding this thesis. Last, but not the least thanks to all my friends and families for their support, encouragement and love throughout my work.
    [Show full text]