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
`
`In a computer system, the integrity of lo~ler layers is typ-
`ically treated as axiomatic by higher layers. Under the pre-
`sumption that
`the hardware
`comprising
`the machine
`(the
`lowest
`layer)
`is valid,
`integrih
`of a layer can be guaran-
`teed if and only ~:
`(1) the integrity crf the lower layers is
`checked, and (2) transitions
`to highm layers occur only uf-
`ler integrity checks on them are complete.
`The resulting
`ii~tegrity “chain” inductively guarantees system integrity.
`When these conditions are not met, a~ they typically are
`not in the bootstrapping (initialization) of a computer sys-
`tem, no integri~ guarantees can be nude. Yet, these guar-
`antees are increasingly important to di~’erseapplications
`such as Internet commerce, security systems, and “active
`networks.” In this papec we describe [he AEGIS architec-
`turefor initializing a computer svstern. It Iwlidates integrity
`at each layer transition in the bootstrap process. AEGIS
`also includes a recoveryproces,~,forintegrity check.failures,
`and we show how this results in robust systems.
`
`these suppositions are true, the system is said to possess
`integrity, no system can be made secure.
`integrity. Wkhout
`Thus, any system is only as secure as the foundation
`upon which it is built. For example, a number of attempts’
`were made in the 1960s and 1970s to produce secure com-
`puting systems, using a secure operating system environ-
`ment as a basis [24]. An essential presumption of the se-
`curity arguments for these designs was that system lay-
`ers underpinning the operating system, whether h,ardware,
`firtnw,are, or both, are trusied. We find it surprising, given
`the great attention paid to operating system security [161[9]
`that so little attention has been paid to the underpinnings
`required for secure operation, e.g., a secure bootstrapping
`phase for these operating systems.
`Without such a secure bootstrap the operating system
`kernel cannot be trusted since it is invoked by an untrusted
`process. Designers of trusted systems often avoid this prob-
`lem by including he boot components in the trusted com-
`puting base (TCB) [7]. That is, the bootstrap steps are ex-
`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
`common layering principle is the use of levels of abstraction
`to mark layer boundmies. A compuier system is organized
`in a series of levels of abstraction, each of which defines a
`“’virtualmachine” upon which higher levels of abstraction
`are constructed. Each of the virtual machines presupposes
`that it is operating in an environment where the abstractions
`of underlying layers can be treated as axiomatic. When
`
`*Arbatrgh is also with the U.S. I@wtment
`of Defense.
`by DARPA under Con-
`snpp(rted
`fsnuttr
`and Far&r’s work is
`tracts #DABT63-95-C-O073,
`#N66C01-%-C-852.
`and #MDA972-95-l
`-
`SUppOrtfrom Hewlett-Packtud
`and ln~cl ~orlwrations
`CIO13 with
`additional
`
`We have designed AEGIS, a secure bootstrap process.
`AEGIS increases the security of the boot process by en-
`suring the integrity of bootstrap code. It does this by con-
`structing a chain of integrity checks, beginning at power-on
`and continuing until the final transfer of control from the
`bootstrap components to the operating system itself. The
`integrity checks comp,we a computed cryptographic hash
`value with a stored digitiaJsignature associated with each
`component.
`The AEGIS ,at-chitecture includes a recovery mechanism
`for repairing integrity failures which protects against some
`classes of denial of service attacks. From the smrt, AEGIS
`
`1081-6012/97
`
`$10.00 @ 1997 IEEE
`
`65
`
`Apple Inc. Exhibit 1015 Page 1
`
`

`
`has been targeted for commercial operating systems on
`commodity hardware, making it a practical “real-world”
`system.
`In AEGIS, the boot process is gwamnteed to end up in a
`secure state, even in the event of integrit y failures outside of
`a minimal section of trusted code. We define a guaranteed
`secure boot process in two parts. The first is that no code is
`executed unless it is either explicitly frusted or its integrity
`is verified prior to its use. The second is that when ,anin-
`tegrity failure is detected a process can recover a suitable
`veritied replacement module.
`
`1.2 Responses
`
`to integrity failure
`
`When a system detects an integrity failure, one of three
`possible courses of action can be taken.
`The first is to continue normal] y, but issue a warning.
`Unfortunately, this may result in the execution or use of ei-
`ther a corruptor malicious component.
`The second is to not use or execute the component. This
`approach is typically called~tdl secnre, and creates a poten-
`tial denial of service attack.
`The final approach is to recover and correct the inconsis-
`tency from a trusted source before the use or execution of
`the component.
`The first two approaches are unacceptable when the sys-
`tems are important network elements such as switches, in-
`trusion detection monitors, or associated with electronic
`commerce, since they either make the component unavail-
`able for service, or its results untrustworthy.
`
`1.3 Outline of the paper
`
`In Section 2, we make the assumptions of the AEGIS
`design explicit. Section 3 is the core of the paper, giv-
`ing an overview of the AEGIS design, and then plunging
`into details of the IBM PC boot process and its modifica-
`tions to support AEGIS. A model and logical dependencies
`for integrity chaining are given in Section 4, and a calcu-
`lation of the complete bootstrap perfornumce is given; the
`estimated performance is surprisingly good. Section 5 dis-
`cusses related work and critically examines some alterna-
`tive approaches to those taken in AEGIS. We dkcuss the
`system status and our next steps in Section 6, and conclude
`the paper with Section 7.
`
`2 Assumptions
`
`The first assumption upon which the AEGIS model is
`based is that the motherbo.wd, processor, and a portion of
`the system ROM (BIOS) are not compromised, i.e., the ad-
`versary is unable or unwilling to replace the motherboard or
`BIOS. We also depend on the integrity of an expansion card
`
`which contains copies of the essential components of the
`boot process for recovery purposes, and optionally a small
`operating system for recovering components from a trusted
`network host. We are investigating a more pragmatic ap-
`proach using the PROM available on most network c,ardsin
`lieu of the AEGIS PROM card.
`The second assumption is the existence of a crypto-
`graphic certificate authority infrastructure to bind an iden-
`tity with a public key. We are currently planning on us-
`ing the infrastructure being established by Microsoft and
`Verisign [27] for use with Authenticode [20],
`The final assumption is that some trusted source exists
`for recovery purposes. This source may be a host on a
`network that is reachable through a secure communications
`protocol, or it may be the trusted ROM card located on the
`protected host.
`
`3 AEGIS Architecture
`
`3.1 Overview
`
`To have a practical impact, AEGIS must be able to work
`with commodity hardware with minimal changes (ideally
`none) to the existing architecture. The IBM PC architecture
`was selected as our prototype platform because of its large
`user community and the availability of the source code for
`several operating systetns. We also use the FreeBSD op-
`erating system, but the AEGIS architecture is not limited
`to any specific operating system. Porting to a new operat-
`ing system only requires a few minor changes to the boot
`block code so that the kernel can be verified prior to pass-
`ing con~ol to it. Since We verification code is con~ined
`in the BIOS, the changes will not substantially increase the
`size of the boot loader, or boot block.
`AEGIS modifies the boot process shown in figure 2 so
`that all executable code, except for a very small section
`of trusted code, is verified prior to execution by using a
`digital signature. This is accomplished through the ad-
`dition of an inexpensive PROM board, and modifications
`to the BIOS. The BIOS and the PROM board contain the
`verification code, and public key certificates. The PROM
`board also contains code that allows the secure recovery of
`any integrity failures found during the initial bootstrap. In
`essence, the trusted softw,are serves as the root of an au-
`thentication chain that extends to the operating system and
`potentially beyond to application software [22] [10] [18].
`A high level depiction of the bootstrap process is shown in
`figure 1. In the AEGIS boot process, either the operating
`system kernel is started, or a recovery process is entered
`to re@r any integrity failure detected. Once the repair is
`completed, the system is restarted to ensure that the system
`boots. This entire process occurs without user intervention.
`
`66
`
`Apple Inc. Exhibit 1015 Page 2
`
`

`
`OS kernel
`
`I Trusted Software
`
`Figure 1. AEGIS boot overview
`
`In addition to ensuring that the system boot.. in a secure
`manner, AEGIS can also be used to maintain the hardware
`and software configuration of a machine. Since AEGIS
`maintains a copy of the signature for each expansion card,
`any additional expansion cards will fail the integrity test.
`Similarly, a new operating system cannot be started since
`the boot block would change, and the new boot block would
`fail the integrity test.
`
`3.2 AEGIS Boot Process
`
`Every computer with the IBM PC architecture follows
`approximately the same boot process. We have divided this
`process into four levels of abstraction (see figure 2), which
`correspond to phases of the bootstrap operation. The first
`phase is the Power on Self Test or POST [21]. POST is
`invoked in one of four ways:
`
`1.
`
`2.
`
`3.
`
`4.
`
`Applying power to the computer automatically invokes
`POST causing the processor to jump to the entry point
`indicated by the processor reset vector.
`
`Hardware reset also causes the processor to jump to
`the entry point indkated by the processor reset vector.
`
`Warm boot (ctrl-alt-del under DOS) invokes POST
`without testing or initializing the upper 64K of system
`memory.
`
`Software programs, if permitted by the operating sys-
`tem, can jump to the processor reset vector.
`
`In each of the cases above, a sequence of tests are con-
`ducted. All of these tests, except for the initial processor
`self test, are under the control of the system BIOS.
`The finat step of the POST process calls the BIOS operat-
`ing system bootstrap interrupt (Int 19h). The bootstrap code
`
`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
`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. When the ROM completes its execution,
`control is returned to the BIOS.
`Ideally, the boot process would proceed in a series of
`levels with each level passing control to the next until the
`operating system kernel is running. Unfortunately, the IBM
`architecture uses a “star like” model which is shown in fig-
`ure 2.
`
`2Operating System
`T Level 3
`
`,,,
`
`,,,
`
`,,,
`
`,,,
`
`Level 4
`,,
`
`,,
`
`,,,
`
`,,7, ,,,
`
`,!, ,,,
`
`,$
`
`,,,
`
`,,,
`
`,,,
`
`,,,
`
`,, !,.,!!,!,
`
`=-
`
`-,,1,9!1,,,::””2
`
`I SystemBIOS
`
`IT Level 1
`
`,4,
`
`,! !,,,,
`
`,,
`
`!,,,,,,,
`
`,,,
`
`.,,,,,,
`
`,,,
`
`Inki& POST
`
`Figure 2. IBM PC boot process
`
`3.2.1
`
`A Multilevel Boot Process
`
`We have divided the boot process into several levels to
`simplify and organize the AEGIS BIOS modifications, as
`shown in figure 3. Each increasing level adds functional-
`ity to the system, providing correspondingly higher levels
`of abstraction. The lowest level is Level 0. Level O con-
`tains the small section of trusted software, digital signa-
`tures, public key certificates, and recovery code. The in-
`tegrity of this level is assumed to be valid. We do, how-
`ever, perform an initial checksum test to identify PROM
`the remainder of the usual
`failures. The first level contains
`BIOS code, and the CMOS. The second level contains all
`of the expansion c,ards and their associated ROMs, if any.
`
`67
`
`Apple Inc. Exhibit 1015 Page 3
`
`

`
`The third level contains the operating system boot block(s).
`These are resident on the bootable device and ,are respon-
`sible for loading the operating system kernel. The fourth
`level contains the operating system, and the fifth and final
`level contains user level programs and any network hosts.
`The transition between levels in a traditional boot pro-
`cess is accomplished with a jump or a call instruction with-
`out any attempt at verifying the integrity of the next level.
`AEGIS, on the other hand, uses public key cryptography
`and cryptographic hashes to protect the transition from each
`lower level to the next higher one, and its recovery process
`ensures the integrity of the next level in the event of failures.
`
`3.2.2 AEGIS BIOS Modifications
`
`AEGIS modifies the boot process shown in figure 2 by di-
`viding the BIOS into two logical sections. The first section
`contains the bare essentials needed for integrity verification
`and recovery. Coupled with the AEGIS ROM, it comprises
`the “trusted software”. The second section contains the re-
`mainder of the BIOS and the CMOS.
`The first section executes and performs the standard
`checksum calculation over its address space to protect
`against ROM failures. Following successful completion of
`the checksum, the cryptographic hash of the second section
`is computed and verified ag,ainst a stored signature.
`If the
`signature is valid, control is passed to the second section,
`i.e., Level 1.
`The second section proceeds normally with one change,
`Prior to executing an expansion ROM, a cryptographic hash
`is computed and verified against a stored digital signature
`for the expansion code. If the signature is valid, then con-
`trol is passed to the expansion ROM. Once the verification
`of each expansion ROM is complete (Level 2), the BIOS
`passes control to the operating system bootstrap code. The
`bootstrap code was previously verified as part of the BIOS,
`and thus no further verification is required. The bootstrap
`code finds the bootable device and verifies the boot block.
`Assuming that the boot block is verified successfully,
`control is passed to it (Level 3). If a second,wy boot block
`is required, then it is verified by the primary block before
`passing control to it. Finally, the kernel is verified by the last
`boot block in the chain before passing control to it (Level 4).
`Any integrity failures identified in the above process are
`recovered either through storage on the expansion ROM
`card, or through a network host. If the component that fails
`its integrity check is a portion of the BIOS, then it must be
`recovered from the ROM card. The recovery process is a
`simple memory copy from the address space of the ROM
`card to the memory address of the failed componenq in ef-
`fect shadowing the failed component.
`A failure beyond the BIOS causes the system to boot
`into a recovery kernel contained on the ROM card. The
`
`recovery keruel contacts a “trusted” host through a secure
`protocol, e.g., IPv6 [2], to recover a verified copy of the
`failed component. The failed component is then shadowed
`or repaired, if possible, and the system is restarted.
`
`The resultant AEGIS boot process is shown in figure 3.
`Note that when the boot process enters the recovery proce-
`dure it becomes isomorphic to a secure network boot.
`
`U*. Pro*raln8
`
`.=
`
`II
`
`~;
`, !,,;,.,,,...,,,,.,
`
`,,,
`
`...
`
`...,,
`
`...
`
`,,,
`
`Level 5
`,,
`
`OF-lXW Sw.-
`
`,,
`
`G
`.,...,,
`
`,,,
`
`,,,
`
`,,
`
`,,,
`
`k“d
`
`4
`
`;“T
`:
`\
`
`‘.
`
`-----
`
`-do
`- -7’0” -
`
`Figure 3. AEGIS boot control
`
`flow
`
`3.3 Key and Configuration Management
`
`The initial prototype
`the signed cryptographic
`stores
`hashes in a raw format
`,and the public keys in PKCS #1 [13]
`format. Eventually, we expect
`to move to X.509V3 certifi-
`cates [6] and PKCS #7 [14] to bind the public key with an
`identity as well as use the Verisign certificate authority in-
`frastructure.
`Ideally, we hope in the future that expansion
`board vendors will
`include signatures
`in their ROM in a
`manner similar
`to Authenticode
`[18],
`
`two kilobytes of the 128kb AEGIS BIOS flash
`The tast
`ROM contain the component signatures and public key(s).
`We are in the process of developing an installation and con-
`figuration program to allow system administrators to in-
`statl and remove components and their associated signatures
`stored in the flash ROM. This will provide a level of flex-
`ibility to the system and still maintain the security of the
`system.
`
`68
`
`Apple Inc. Exhibit 1015 Page 4
`
`

`
`4
`
`Integrity Chaining
`mance
`
`and System Perfor-
`
`through the
`is preserved
`system integrity
`In AEGIS,
`chain of integrity checks in the bootstrap process. The ideal
`authentication
`chain produced by each level verifying the
`next can be represented by the recurrence
`
`10 = True,
`
`Ii+l = {Ii Av(L,+l)
`
`for O < i <4.
`
`(1)
`
`the integrity of level
`is a boolean value representing
`Ii
`1; is the verification
`i, and A is the boolean and operation.
`function associated with the it h lCVCI.l’; takes as its only ar-
`gument
`the level to verify, and it returns a boolean value as
`a result. The verification function performs a cryptographic
`hash of the level, and comp,ares the result
`to the value ob-
`tained from a stored signature for the level. As smted ear-
`lier, the IBM PC does not lend itself to such a boot process.
`[nstead. we alter the recurrence
`to:
`
`10 = True,
`
`Ii A Vi(Li+l)
`
`for i = 0,3,4,
`
`~i+l =
`
`vi(~~+.l)
`L A E?=l
`IiAU_l(L,+l))
`
`for i = I,
`for i = 2.
`
`{
`
`Algori~m
`MD5
`RSA Verify(512b
`it)
`RSA Verify (1024
`bit)
`RSA Verify ‘--‘“
`~Lmmhit)
`E
`
`Time
`13,156,000 bytes/see
`0.0027 sec
`0.0086 sec
`0.031 sec
`
`3===1
`
`Table 1. BSAFE 3.0 Benchmarks
`
`For analysis
`such as video cards, as large ,as 64 kilobytes.
`purposes, we will resume that one@ kilobyte c,ard and two
`16 kilobyte cards ,are present. The size of the boot blocks
`for FreeBSD 2.2 (August 1996 Snapshot) are 512 bytes for
`the primary boot block, 6912 bytes for the secondary boot
`block, and 1,352 kilobytes
`for the size of the GENERIC
`kernel. Using the perfonmmce
`of MD5 from table 1, the
`time required to verify each layer using a 1024 bit modulus
`is:
`
`t(Vo(L1)) = 0.0185 seconds
`
`t(Vl (L2)) = 0.0160 seconds
`t(V1 (L3)) = 0.018 secorzd
`
`t(V3(L4)) = 0.l14secomk.
`
`(2)
`
`Summing these times gives TA = 0.1665 seconds which
`is insignificant
`comp,ared to the length of time currently
`needed to bootstrap an IBM PC.
`
`the number of expansion boards in the
`Here, n represents
`system, and our level of assurance is preserved.
`
`5 Related work
`
`4.1
`
`Performance impact on bootstrap completion
`time
`
`relation shown in equation 2, we
`Using the recurrence
`can COIIIpttti3
`the estimated itICIWSt3
`ill boot tiIne (~A), With-
`out integrity failures, between AEGIS and a standard IBM
`PC using the following equation:
`
`n
`
`TA
`
`=
`
`~(Vo(L))
`
`+
`
`~(~vl(~~))
`
`+
`
`~(~1(J53))
`
`1=1
`
`+t(v3(L4)),
`
`(3)
`
`In estimat-
`the execution time of op.
`returns
`where t(op)
`ing the time of the verification
`function, W, we use the
`BSAFE benchmarks
`[23] for an Intel 90Mhz Pentium com-
`puter, shown in table 1. The cost of verification includes
`time required for computing
`a MD5 message digest, and
`the time required to verify the digest against a stored signa-
`ture. Any signatures embedded in the public key certificate
`are ignored at the moment.
`( 128 Kilobytes), and
`The BIOS is typically one megabit
`the expansion ROMs are usually 16 kilobytes with some,
`
`The first presentation of a secure boot process wassdone
`by Yee [26].
`In Yee’s model, a cryptographic
`coprocessor
`is the first to gain control of the system. Unfortunately,
`this
`is not possible without a complete architectural
`revision of
`most computer
`systems— even if the coprocessor
`is tightly
`coupled. Yee exp,ands his discussion of a secure boot in his
`thesis [28], but he continues
`to state that the secure copro-
`cessor should control
`the boot process verifying each com-
`ponent prior
`to its use. Yee states that boot ROM modifi-
`cations may be required, but since a prototype
`secure boot
`process w= never implemented more implemcutation
`ques-
`tions are raised than ,answered by his discussion.
`Clark [5] presents a secure boot process
`for DOS that
`stores all of the operating system bootstrap code on a PCM-
`CIA card. He does not uddress
`the verification
`of any
`firmware (system BIOS or expansion cards). Clark’s model,
`however, does permit mutual cryptographic
`authentication
`between the user and the host which is an important capa-
`bility. However,
`the use of a PCMCIA card containing all
`of the system boot
`tiles creates severat configuration man-
`agement problems,
`e.g., a system upgrade requires
`tie re-
`programming
`of atl the cards in circulation,
`and since today
`m,any users have multiple operating systems on their per-
`
`69
`
`Apple Inc. Exhibit 1015 Page 5
`
`

`
`a user needs a scp,amtc PCMCIA card for
`sotml computers
`each operating system they wish to use.
`Lampson
`[15] describes
`a secure boot model as ,an ex-
`ample for his authentication
`catcul us. In Lmnpsou’s model,
`the entire boot ROM is trusted, and he does not address the
`verification of expansion cards/ROMs. The Birlix [12] Se-
`curity Architecture
`proposes a model designed by Michael
`Gross that is similar
`to Lampsou”s. The Birlix model also
`suffers
`from the same problems.
`In both cases,
`the boot
`ROM is responsible
`for generating a public and private key
`pair for use in host based authentication
`once the operating
`system is running.
`In AEGIS we leave (any security related
`functions, beyond the boot process,
`to the operating system
`without
`loss of security.
`To do otherwise
`limits security
`choices for the operating system.
`None of the approaches address a recovery process in the
`event of an integrity failure.
`
`[17] to allow user choice of a secure protocol.
`(ISAKMP)
`the method with which the recovery kernel
`Additionally,
`contacts
`a host
`is currently via a fixed address. We hope
`to develop or use a protocol
`in which the recovery host’s
`address c,an be dctertnined dynamically when needed.
`The process by which components
`are vetted,
`signed,
`and the resultant
`signature
`and public key certificate
`in-
`stalled needs
`to be addressed
`carefully
`since
`signing a
`“buggy” or malicious
`component
`can result
`in a security
`breech. We plan to address
`this once a full prototype
`is
`completed,
`and will report on the results. As a minimum,
`we expect
`to use flaw detection techniques
`such as those
`from Bishop [3], Kannan [4], and others to assist
`in a tech-
`nical vetting before the actual signing of the cotnponent.
`In addition, we ,are investigating
`the use of this tech-
`nology as part of a secure bootstrap for an active network
`node[25].
`
`5.1 Discussion and alternative approaches
`
`7 Conclusions
`
`Current operating systems cannot provide security assur-
`ances since they are started via an untrusted process. With
`the explosive growth in Intemet commerce,
`the need fOr se-
`curity assumnces
`from computer
`systems has grown con-
`siderably. AEGIS is a guaranteed secure boot process that
`ensures that the computer
`system is started via a trusted pro-
`cess, and ensures that the system starts in spite of integrity
`failures.
`
`References
`
`A possible criticism of this work is that booting from a
`floppy disk provides
`the same level of protection. There are
`several reasons why this is not so. The first is that providing
`physical
`security for the floppy disk is extremely difficult.
`Users can take the disks wherever
`they like, and do what-
`ever they like to them. One can envision a user building
`their own boot
`floppy that gives them systcm level privi-
`leges. The user
`is now free to read and write anywhere
`on the local disk circumventing
`any security systems put
`in place by the “real” boot
`floppy or \he on disk operat-
`ing system. This problem is described by Microsoft
`[19]
`as a method of circumventing
`the Windows NT file system
`(NITS).
`The major shortcoming,
`however,
`in using a boot
`disk is that none of the firmw,are is verified prior
`to use.
`Thus, a user can add or replace expansion boards into the
`system without any security controls, potentially introduc-
`ing unauthorized
`expansion cards.
`
`6
`
`Status and Future Work
`
`and we are
`The AEGIS prototype is nearing completion,
`confident
`that a description of its current performance
`and
`implementation will be provided at the conference.
`Initial
`difficulty in obtaining BIOS source code has delayed mod-
`ifying it to support AEGIS as described in the body of the
`paper. However, we are currently adding the required cryp-
`tographic routines and optimizing them for space to store as
`much key and recovery material
`in the flash ROM as possi-
`ble.
`IPv6 as
`uses
`prototype
`kernel
`recovery
`The current
`replacement
`files. We intend to
`a means of recovering
`switch to the Internet Engineering Task Force’s (IETF)
`In-
`ternet Security Association and Key Management
`Protocol
`
`[1]
`
`[2]
`
`[3]
`
`[4]
`
`[5]
`
`[6]
`
`[7]
`
`[8]
`
`70
`
`W. Ahnesberger. LILO Technical Overview, version 19 edi-
`tion, May 1996.
`R. J. Atkinson, D. L. McDonald, B. G. Phan, C. W. Metz,
`Implementation of ipv6 in 4.4 bsd. In Pro-
`and K. C. Chin.
`ceedings of the 1996 USENIX Technical Conference, pages
`113–125. USENIX, January 1996.
`M. Bishop and M. Dilger. Checking for race conditions
`in file accesses, Computing Systems, 9(2):13 1–152, Spring
`1996.
`M. Blum and S. Kannan. Designing programs
`their work. JACM. 42(1):269-291,
`January 1995.
`P. C. Clark. BITS: A SmcwtcardProtected Operoting System.
`PhD thesis, George Washington University, 1994.
`C. Committee. X.S09: The Directosy Authentication Frclme-
`work. International Telephone and Telegraph,
`International
`Telecommunications Union, Geneva, 1989.
`DOD. Trusted computer system evaluation criteria. Tech-
`mcal Report DOD 52CK).28-STD,Department of Defense,
`December 1985.
`J.
`Elischer.
`/sys/i386/boot/biosboot/README.386,
`FreeBSD.
`
`386
`July 1996.
`
`boot.
`2.1.5
`
`that check
`
`Apple Inc. Exhibit 1015 Page 6
`
`

`
`loacler.
`1993.
`
`bootstrap
`October
`
`[9] D. R. Engler, M. F. Kaashoek, and 1. W. OToole. The op-
`erating system kernel as a secure programmable machine.
`In Proceedings of the Sixth SIG(2PS European Workshop,
`pages 62-67. September 1994.
`[10] Y. D. G. Davida and B. Matt. Defending systems against
`In 1989 IEEE
`viruses through cryptographic authentication.
`Symposium on Security ond Privoc~, pages 312-318.
`IEEE,
`1989.
`[11] R. Grimes.
`At386 protected mode
`/sys/i386/bootibiosboot/README.MACH,
`2.1.5 FreeBSD.
`The Birlix
`and W. Kuhnhauser.
`[12] H. Hartig, O. Kowalski
`Journal of ComplcrerSecurigj. 2(1 ):5–
`security architecture.
`21, 1993.
`[13] R. Laboratories. PKCS #1: RSA Encryption Stmrdord, ver-
`sion 1.5 edition, 1993. November.
`[14] R. Laboratories. PKCS #7: Cryptographic Message Syntax
`Standard, version 1.5 edkion, November 1993.
`[15] B. Larnpson, M. Abadi, and M. Burrows. Authentication
`in distributeds ystems: Theory and practice. ACM Transac-
`tions on Computer Systems, v 10:265–310, November 1992.
`[16] F. M. M. Branstad, H. Tajalli and D. Dalva. Access medi-
`In IEEE Conference on
`ation in a message-passing kernel.
`Security and Privacy, pages 66-71, 1989.
`and J. Turner.
`[17] D. Maughan, M. Schertler, M. Schneider,
`Internet security association and key management protocol
`(isakmp).
`Internet+lraft,
`IPSEC Working Group, June 1996.
`[18] Microsoft. Authenticode technology. Microsoft’s Devel-
`oper Network Library, October 1996.
`file sys-
`smd ntfs
`[19] Microsoft.
`Overview of
`fat, hpfs,
`tems. Knowledge Base Article Q1OO1O8, Microsoft, Oc-
`tober 1996.
`[20] Microsoft. Proposal for authenticating code via the internet.
`http://www.tiaosoft.
`cotiw[,rkshop/prog/secwity/misR-
`f.htm, April 1996.
`IBM PCs, Com-
`121] L. Phoenix Technologies. System BI07for
`patibles,
`and EISA Computers. Addison Wesley, 2nd edi-
`tion, 1991.
`122] M. M. Pozzo and T. E. Gray. A model for the containment
`In 1989 IEEE Symposium on Security
`of computer viruses.
`and Privacy, pages 3 12–318. IEEE, 1989.
`benchmarks.
`Bsafe
`3.0
`123] I. RSA Data
`Security.
`RSA
`Data
`Security
`Engineering
`Report,
`1996.
`http//www.rsa.corrs/rsa/developers/bench
`.htm.
`for multics.
`[24] M. Schroeder.
`Engineering a security kernel
`In F~th Symposium on Operating Systems Principles, pages
`125–132, November 1975.
`[25] D. Tennenhouse,
`J. Smith, W. Sincoskie, D. Wetherall, and
`IEEE
`G. Minden. A survey of achve network research.
`Communications Magazine, pages 80-86,
`January 1997.
`:[26] J. Tygar and B. Yee. Dyad: A system for using physically
`secure coprocessor.
`Techmcal ReportCMU-CS-91-140R,
`Carnegie Mellon University, May 1991.
`‘[27] I. Verisign. Verisign certification practice statement. Techni-
`cal Report Version 1.1, Verisign, Inc., Mountain View, CA.,
`August 1996.
`[28] B. Yee. Using Secure Coprocessor. PhD thesis, Carnegie
`Mellon University, 1994.
`
`71
`
`Apple Inc. Exhibit 1015 Page 7