View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Syracuse University Research Facility and Collaborative Environment Syracuse University SURFACE Electrical Engineering and Computer Science - Technical Reports College of Engineering and Computer Science 8-2018 Formal Verification of a Modern Boot Loader Scott D. Constable Syracuse University, [email protected] Rob Sutton RJMetrics Arash Sahebolamri Syracuse University, [email protected] Steve Chapin Syracuse University, [email protected] Follow this and additional works at: https://surface.syr.edu/eecs_techreports Part of the Information Security Commons, and the Software Engineering Commons Recommended Citation Constable, Scott D.; Sutton, Rob; Sahebolamri, Arash; and Chapin, Steve, "Formal Verification of a Modern Boot Loader" (2018). Electrical Engineering and Computer Science - Technical Reports. 183. https://surface.syr.edu/eecs_techreports/183 This Report is brought to you for free and open access by the College of Engineering and Computer Science at SURFACE. It has been accepted for inclusion in Electrical Engineering and Computer Science - Technical Reports by an authorized administrator of SURFACE. For more information, please contact [email protected]. Syracuse University SURFACE Electrical Engineering and Computer Science College of Engineering and Computer Science Technical Reports 8-2018 Formal Verification of a Modern Boot Loader Scott .D Constable Rob Sutton Arash Sahebolamri Steve Chapin Follow this and additional works at: https://surface.syr.edu/eecs_techreports Part of the Information Security Commons, and the Software Engineering Commons Formal Verification of a Modern Boot loader ∗ Scott Constable Rob Sutton Arash Sahebolamri Steve Chapin Department of Electrical Engineering and Computer Science Syracuse University Syracuse, New York, 13244-1200 Abstract loader code, operating system, and web server soft- ware. Such TCBs could easily comprise millions of We introduce the Syracuse Assured Boot Loader Ex- lines of code. ecutive (SABLE), a trustworthy secure loader. A The surface area of the problem may be reduced trusted boot loader performs a cryptographic mea- in two ways. The first and most obvious solution is surement (hash) of program code and executes it un- to shrink the TCB, either by reducing the amount of conditionally, allowing later-stage software to verify code required to perform the desired tasks, or reduc- the integrity of the system through local or remote ing the amount of code which needs to be trusted. attestation. A secure loader differs from a trusted The latter can be accomplished by utilizing hard- loader in that it executes subsequent code only if ware protections such as AMD SVM [5] and Intel measurements of that code match known-good val- TXT [20], which effectively remove pre-operating sys- ues. We have applied a rigorous formal verifica- tem software and firmware from the TCB. ARM tion technique recently demonstrated in practice by TrustZone [3] partitions system code into \normal NICTA in their verification of the seL4 microkernel. world" and \secure world" code, ideally to exclude We summarize our design philosophy from a high the normal world code from the TCB. More recently, level and present our formal verification strategy. Intel SGX technology [2] introduced a hardware- protected execution environment to shield arbitrary 1 Introduction code (e.g. system or application code) from the rest of the system. The United States Department of Defense Orange The second solution is to increase the trustworthi- Book defines the Trusted Computing Base (TCB) ness of code which must be a member of the TCB. of a computer system as the part of the computer For instance, a program written in a memory-safe system \which contains all of the elements of the language may be more trustworthy than a similar system responsible for supporting the security pol- program written in C. Stronger guarantees about the icy and supporting the isolation of objects (code and trustworthiness of a program or system can be made data) on which the protection is based" [15]. Hence, using formal methods. Substantial progress on pro- on a typical x86 server the TCB or \trust bound- ducing partially or fully verified operating systems, ary" would encompass the hardware, firmware, boot microkernels, and hypervisors has been made in the past decade [17, 23, 27]. ∗This research was supported in part by a subcontract from Critical Technologies Inc., under United States Air SABLE is a trustworthy secure loader which ap- Force Research Laboratory (USAFRL) Information Direc- plies both of these solutions to shrink the platform torate prime contract #FA8750 13 C 0152, based upon US TCB and improve the trustworthiness of platform Department of Defense (DoD) Small Business Innovation Re- search (SBIR) topic #AF121-051, \Remote Attestation and software. A trusted boot loader performs a crypto- Distributed Trust in Networks (RADTiN)" graphic measurement of program code and then ex- 1 ecutes it unconditionally. Later-stage software may be done to fully formally verify SABLE, respectively. opt to verify the integrity of the system through lo- Section 7 discusses our reflection on the design and cal or remote attestation. A secure loader differs from verification process. a trusted loader in that it executes subsequent code only if measurements of that code match known-good values. 2 Background Hence a secure loader must, by definition, prevent the execution of untrusted code [30]. SABLE is able 2.1 Trusted Computing to make this guarantee by utilizing the Trusted Plat- According to the Trusted Computing Group (TCG), form Module (TPM) [36] chip together with AMD SVM on AMD platforms and Intel TXT on Intel Trust is the expectation that a device will platforms. Via cryptographic hashing, the TPM can behave in a particular manner for a specific \measure" code prior to its execution. Addition- purpose. A trusted platform should provide ally the TPM may \seal" data to a particular sys- at least three basic features: protected capa- tem state, characterized by hash chain digests aggre- bilities, integrity measurement and integrity gated in secure storage [30]. By joining these two reporting. [37] paradigms, SABLE satisfies the definition of a secure loader. SABLE serves as the software foundation for integrity Moreover we employ formal verification techniques measurement and utilizes the protected capabilities demonstrated in practice during the seL4 verifica- of the trusted platform. The following subsections tion effort [24]. In particular, we have implemented introduce these concepts. Integrity reporting may SABLE in a manner which allows it to be trans- be performed by the operating system or application lated into a monadic language that can be parsed software which is outside the scope of this paper. De- by a proof assistant. In this proof assistant, we con- tails about integrity reporting with the TPM can be struct an abstract specification of SABLE's imple- found elsewhere [11, 31, 37, 44]. mentation, and prove that the implementation ex- hibits a subset of the behavior allowed by the ab- 2.1.1 Integrity Measurement stract specification. This rigorous verification effort The TCG uses the term measurement to describe thus increases the trustworthiness of SABLE when a cryptographic hash operation [37]. Measurements compared against other trusted software which has can, among other purposes, be used to verify the in- only been penetration tested. tegrity of code/data or to attest to the integrity of a We have implemented SABLE to run on both the particular system configuration. TPM chips contain AMD SVM and Intel TXT architectures. From the several Platform Configuration Registers (PCRs) user's perspective, the behavior of SABLE on either which store measurements in a digest. Measure- architecture is identical. Though the implementation ments, however, are not written directly into a PCR. details do differ somewhat, for brevity we focus our Rather, they are extended into a PCR in the following discussion in this paper on SABLE's implementation manner: for AMD SVM. The rest of this paper is organized as follows. Sec- PCRi;n+1 H(PCRi;n jj H(data)) tion 2 introduces the relevant background in trusted computing and formal verification. Section 3 out- where H is a cryptographic hash function, jj is the lines the design of SABLE and its bilateral attesta- concatenation operator, and PCRi;n is the value tion protocol. Section 4 describes the implementa- of the ith PCR after n extend operations on that tion of SABLE. Section 5 details the formal methods PCR [37]. Thus in each extend operation the cur- used to verify SABLE's implementation. Sections 6 rent value in the PCR is replaced by the hash of the and 8 discuss related work and the work remaining to old value of the PCR concatenated with the hash of 2 is sufficiently trustworthy (i.e. known non-malicious). Then the client would use the SML to compute the hash digest(s) in the same manner and sequence as the server software and the TPM, and compare the result(s) against the server's quoted PCR value(s). Assuming that the PCR values can be transmitted to the client with verifiable integrity1, these PCR val- ues accurately characterize of the state of the server. Thus the remote client is able to determine whether or not the SML is an honest log of the server's run- ning software and firmware. A Linux platform which uses this logging and reporting scheme was described in [33]. Figure 1: Trusted boot execution [37] In the TCG terminology, the boot protocol given in Figure 1 uses a static RTM (SRTM) [37]. A SRTM begins performing measurements as early in the boot the new data. Because the PCRs are shielded by the process as possible. For instance, on PC clients the TPM and a narrow command interface, they form a BIOS and firmware serve as the SRTM. The BIOS root of trust for measurement (RTM) for the system.