A Secure and Reliable Bootstrap Architecture
Total Page：16
File Type：pdf, Size：1020Kb
A Secure and Reliable Bootstrap Architecture William A. Arbaugh” David J. Farbert Jonathan M. Smith Universiw of Pennsylvania Distributed Systems Laboratory Philadelphia, PA. 19104-6389 {waa, fat-her, jms}@dsl.cis.upenn.edu Abstract these suppositions are true, the system is said to possess integrity. Wkhout integrity, no system can be made secure. In a computer system, the integrity of lo~lerlayers is typ- Thus, any system is only as secure as the foundation ically treated as axiomatic by higher layers. Under the pre- upon which it is built. For example, a number of attempts’ sumption that the hardware comprising the machine (the were made in the 1960s and 1970s to produce secure com- lowest layer) is valid, integrih of a layer can be guaran- puting systems, using a secure operating system environ- teed if and only ~: (1) the integrity crf the lower layers is ment as a basis [24]. An essential presumption of the se- checked, and (2) transitions to highm layers occur only uf- curity arguments for these designs was that system lay- ler integrity checks on them are complete. The resulting ers underpinning the operating system, whether h,ardware, ii~tegrity “chain” inductively guarantees system integrity. firtnw,are,or both, are trusied. We find it surprising, given When these conditions are not met, a~ they typically are the great attention paid to operating system security [161[9] not in the bootstrapping (initialization) of a computer sys- that so little attention has been paid to the underpinnings tem, no integri~ guarantees can be nude. Yet, these guar- required for secure operation, e.g., a secure bootstrapping antees are increasingly important to di~’erseapplications phase for these operating systems. such as Internet commerce, security systems, and “active Without such a secure bootstrap the operating system networks.” In this papec we describe [he AEGIS architec- kernel cannot be trusted since it is invoked by an untrusted turefor initializing a computer svstern. It Iwlidates integrity process. Designers of trusted systems often avoid this prob- at each layer transition in the bootstrap process. AEGIS lem by including he boot components in the trusted com- also includes a recoveryproces,~,forintegrity check.failures, puting base (TCB) [7]. That is, the bootstrap steps are ex- and we show how this results in robust systems. plicitly trusted. We believe that this provides a false sense of security to the users of the operating system, and more important, is unnecessary. 11 Introduction 1.1 AEGIS Systems are organized as layers to limit complexity. A We have designed AEGIS, a secure bootstrap process. common layering principle is the use of levels of abstraction AEGIS increases the security of the boot process by en- to mark layer boundmies. A compuier system is organized suring the integrity of bootstrap code. It does this by con- in a series of levels of abstraction, each of which defines a structing a chain of integrity checks, beginning at power-on “’virtualmachine” upon which higher levels of abstraction and continuing until the final transfer of control from the are constructed. Each of the virtual machines presupposes bootstrap components to the operating system itself. The that it is operating in an environment where the abstractions integrity checks comp,we a computed cryptographic hash of underlying layers can be treated as axiomatic. When value with a stored digitiaJsignature associated with each component. *Arbatrgh is also with the U.S. I@wtment of Defense. The AEGIS ,at-chitecture includes a recovery mechanism fsnuttr and Far&r’s work is snpp(rted by DARPA under Con- tracts #DABT63-95-C-O073, #N66C01-%-C-852. and #MDA972-95-l - for repairing integrity failures which protects against some CIO13 with additional SUppOrtfrom Hewlett-Packtud and ln~cl ~orlwrations classes of denial of service attacks. From the smrt, AEGIS 65 1081-6012/97 $10.00 @ 1997 IEEE has been targeted for commercial operating systems on which contains copies of the essential components of the commodity hardware, making it a practical “real-world” boot process for recovery purposes, and optionally a small system. operating system for recovering components from a trusted In AEGIS, the boot process is gwamnteed to end up in a network host. We are investigating a more pragmatic ap- secure state, even in the event of integrity failures outside of proach using the PROM available on most network c,ardsin a minimal section of trusted code. We define a guaranteed lieu of the AEGIS PROM card. secure boot process in two parts. The first is that no code is The second assumption is the existence of a crypto- executed unless it is either explicitly frusted or its integrity graphic certificate authority infrastructure to bind an iden- is verified prior to its use. The second is that when ,anin- tity with a public key. We are currently planning on us- tegrity failure is detected a process can recover a suitable ing the infrastructure being established by Microsoft and veritied replacement module. Verisign [27] for use with Authenticode [20], The final assumption is that some trusted source exists 1.2 Responses to integrity failure for recovery purposes. This source may be a host on a network that is reachable through a secure communications When a system detects an integrity failure, one of three protocol, or it may be the trusted ROM card located on the possible courses of action can be taken. protected host. The first is to continue normal]y, but issue a warning. Unfortunately, this may result in the execution or use of ei- 3 AEGIS Architecture ther a corruptor malicious component. The second is to not use or execute the component. This 3.1 Overview approach is typically called~tdl secnre, and creates a poten- tial denial of service attack. To have a practical impact, AEGIS must be able to work The final approach is to recover and correct the inconsis- with commodity hardware with minimal changes (ideally tency from a trusted source before the use or execution of none) to the existing architecture. The IBM PC architecture the component. was selected as our prototype platform because of its large The first two approaches are unacceptable when the sys- user community and the availability of the source code for tems are important network elements such as switches, in- several operating systetns. We also use the FreeBSD op- trusion detection monitors, or associated with electronic erating system, but the AEGIS architecture is not limited commerce, since they either make the component unavail- to any specific operating system. Porting to a new operat- able for service, or its results untrustworthy. ing system only requires a few minor changes to the boot block code so that the kernel can be verified prior to pass- 1.3 Outline of the paper ing con~ol to it. Since We verification code is con~ined in the BIOS, the changes will not substantially increase the In Section 2, we make the assumptions of the AEGIS size of the boot loader, or boot block. design explicit. Section 3 is the core of the paper, giv- AEGIS modifies the boot process shown in figure 2 so ing an overview of the AEGIS design, and then plunging that all executable code, except for a very small section into details of the IBM PC boot process and its modifica- of trusted code, is verified prior to execution by using a tions to support AEGIS. A model and logical dependencies digital signature. This is accomplished through the ad- for integrity chaining are given in Section 4, and a calcu- dition of an inexpensive PROM board, and modifications lation of the complete bootstrap perfornumce is given; the to the BIOS. The BIOS and the PROM board contain the estimated performance is surprisingly good. Section 5 dis- verification code, and public key certificates. The PROM cusses related work and critically examines some alterna- board also contains code that allows the secure recovery of tive approaches to those taken in AEGIS. We dkcuss the any integrity failures found during the initial bootstrap. In system status and our next steps in Section 6, and conclude essence, the trusted softw,are serves as the root of an au- the paper with Section 7. thentication chain that extends to the operating system and potentially beyond to application software [22] [10] [18]. 2 Assumptions A high level depiction of the bootstrap process is shown in figure 1. In the AEGIS boot process, either the operating The first assumption upon which the AEGIS model is system kernel is started, or a recovery process is entered based is that the motherbo.wd, processor, and a portion of to re@r any integrity failure detected. Once the repair is the system ROM (BIOS) are not compromised, i.e., the ad- completed, the system is restarted to ensure that the system versary is unable or unwilling to replace the motherboard or boots. This entire process occurs without user intervention. BIOS. We also depend on the integrity of an expansion card 66 first finds a bootable disk by searching the disk search order defined in the CMOS. Once it finds a bootable disk, it loads the primary boot block into memory and passes control to OS kernel it. The code contained in the boot block proceeds to load the operating system, or a secondary boot block depending on the operating system [11] [8] or boot loader [1]. Once the BIOS has performed all of its power on tests, it begins searching for expansion card ROMs which are identified in memory by a specific signature. Once a valid ROM signature is found by the BIOS, control is immedi- ately passed to it.