Automated Recovery in a Secure Bootstrap Process

University of Pennsylvania
Technical Reports (CIS)
Department of Computer & Information Science
August 1997
Automated Recovery in a Secure Bootstrap Process
William A. Arbaugh
University of Pennsylvania
Angelos D. Keromytis
University of Pennsylvania
David J. Farber
University of Pennsylvania
Jonathan M. Smith
University of Pennsylvania,
Follow this and additional works at:
Recommended Citation
William A. Arbaugh, Angelos D. Keromytis, David J. Farber, and Jonathan M. Smith, "Automated Recovery in a Secure Bootstrap
Process", . August 1997.
University of Pennsylvania Department of Computer and Information Science Technical Report No. MS-CIS-97-13.
This paper is posted at ScholarlyCommons.
For more information, please contact
Automated Recovery in a Secure Bootstrap Process
Integrity is rarely a valid presupposition in much systems architecture, yet it is necessary to make any security
guarantees. To address this problem, we have designed a secure bootstrap process, AEGIS, which presumes a
minimal amount of integrity, and which we have prototyped on the Intel x86 architecture. The basic principle
is sequencing the bootstrap process as a chain of progressively higher levels of abstraction, and requiring each
layer to check a digital signature of the next layer before control is passed to it. A major design decision is the
consequence of a failed integrity check. A simplistic strategy is to simply halt the bootstrap process. However,
as we show in this paper, the AEGIS bootstrap process can be augmented with automated recovery
procedures which preserve the security properties of AEGIS under the additional assumption of the
availability of a trusted repository. We describe a variety of means by which such a repository can be
implemented, and focus our attention on a network accessible repository. The recovery process is easily
generalized to applications other than AEGIS, such as standardized desktop management and secure
automated recovery of network elements such as routers or "Active Network" elements.
University of Pennsylvania Department of Computer and Information Science Technical Report No. MSCIS-97-13.
This technical report is available at ScholarlyCommons:
Automated Recovery in a Secure Bootstrap Process
William A. Arbaugh
Angelos D. Keromytis
David J. Farber
Jonathan M. Smith
University of Pennsylvania
Distributed Systems Laboratory
Philadelphia, PA. 19104-6389
waa, angelos, farber, jms
August 1, 1997
is easily generalized to applications other than AEGIS,
such as standardized desktop management and secure automated recovery of network elements such as routers or
”Active Network” elements.
Integrity is rarely a valid presupposition in many systems architectures, yet it is necessary to make any security
guarantees. To address this problem, we have designed a
secure bootstrap process, AEGIS, which presumes a minimal amount of integrity, and which we have prototyped
on the Intel x86 architecture. The basic principle is sequencing the bootstrap process as a chain of progressively
higher levels of abstraction, and requiring each layer to
check a digital signature of the next layer before control is passed to it. A major design decision is the consequence of a failed integrity check. A simplistic strategy is to simply halt the bootstrap process. However, as
we show in this paper, the AEGIS bootstrap process can
be augmented with automated recovery procedures which
preserve the security properties of AEGIS under the additional assumption of the availability of a trusted repository. We describe a variety of means by which such a
repository can be implemented, and focus our attention
on a network-accessible repository. The recovery process
Systems are organized as layered levels of abstraction, in
effect defining a series of virtual machines. Each virtual
machine presumes the correctness (integrity) of whatever
virtual or real machines underlie its own operation. Without integrity, no system can be made secure, and conversely, any system is only as secure as the foundation
upon which it is built. Thus, without such a secure bootstrap the operating system kernel cannot be trusted since
it is invoked by an untrusted process. We believe that
designing trusted systems by explicitly trusting the boot
components provides a false sense of security to the users
of the operating system, and more important, is unnecessary.
We have previously reported[AFS97] the design and
preliminary implementation results for AEGIS, a secure
bootstrap process. AEGIS increases the security of the
boot process by ensuring the integrity of bootstrap code.
Smith and Farber’s work is supported by DARPA under Contracts
#DABT63-95-C-0073, #N66001-96-C-852, and #MDA972-95-1-0013
with additional support from the Hewlett-Packard and Intel Corporations.
It does this by constructing 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 compare a computed
cryptographic hash value with a stored digital signature
associated with each component.
The AEGIS model relies explicitly on three assumptions:
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 normally, but issue a warning.
Unfortunately, this may result in the execution or use of
either a corrupt or malicious component.
The second is to not use or execute the component. This
approach is typically called fail secure, and creates a potential denial of service attack.
1. The motherboard, processor, and a portion of the sysThe final approach is to recover and correct the incontem ROM (BIOS) are not compromised, i.e., the ad- sistency from a trusted source before the use or execution
versary is unable or unwilling to replace the mother- of the component.
board or BIOS.
The first two approaches are unacceptable when the
systems are important network elements such as switches,
2. Existence of a cryptographic certificate authority in- intrusion detection monitors, or associated with electronic
frastructure to bind an identity with a public key, al- commerce, since they either make the component unavailthough no limits are placed on the type of infrastruc- able for service, or its results untrustworthy.
1.2 Goals
3. A trusted source exists for recovery purposes. This
source may be a host on a network that is reachable There are six main goals of the AEGIS recovery protocol.
through a secure communications protocol, or it may
1. Allow the AEGIS client and the trusted repository to
be a trusted ROM card located on the protected host.
mutually authenticate their identities with limited or
prior contact (mobility between domains).
The AEGIS architecture, which we outline below in
Section 2, includes a recovery mechanism for repairing
integrity failures protecting against some classes of denial
of service attacks. An added benefit of the recovery mechanism is the potential for reducing the Total Cost Operation (TCO) of a computer system by reducing trouble
calls and down time associated with failures of the boot
From the start, AEGIS has been targeted for commercial operating systems on commodity hardware, making it
a practical “real-world” system. In AEGIS, the boot process is guaranteed to end up in a secure state, even in the
event of integrity 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 trusted or its integrity is verified prior to
its use. The second is that when an integrity failure is
detected a process can recover a suitable verified replacement module. This recovery process is the focus of the
current paper.
2. Prevent man in the middle attacks.
3. Prevent replay attacks.
4. Mitigate certain classes of denial of service attacks.
5. Allow the participating parties to agree upon a shared
secret in a secure manner in order to optimize future
message authentication.
6. Be as simple as possible: Complexity breeds design
and implementation vulnerabilities.
1.3 Outline of the Paper
In Section 2, we make the goals of the AEGIS design explicit. Sections 3, 4, and 5 form the core of the paper, giving an overview of AEGIS, and the IBM PC boot process.
Section 4 provides an introduction to the cryptographic
and system tools needed to build a secure recovery protocol, and describes such a protocol. Section 5 describes
the details of adding the recovery protocol to existing Dynamic Host Configuration Protocol (DHCP), and Trivial
File Transfer Protocol (TFTP) implementations and provides performance information. We discuss the system
status and our next steps in section 6, and conclude the
paper in section 7.
2 AEGIS Architecture
2.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 systems. We also use
the FreeBSD operating system, but the AEGIS architecture is not limited to any specific operating system. Porting to a new operating system only requires a few minor
changes to the boot block code so that the kernel can be
verified prior to passing control to it. Since the verification code is contained in the BIOS, the changes will not
substantially increase the size of the boot loader, nor the
boot block.
AEGIS modifies the boot process shown in figure 1 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 modifications and additions to the BIOS. The BIOS contains the
verification code, and public key certificate(s). In essence,
the trusted software serves as the root of an authentication
chain that extends to the operating system and potentially
beyond to application software [PG89] [GDM89] [Mic].
In the AEGIS boot process, either the operating system
kernel is started, or a recovery process is entered to repair
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.
In addition to ensuring that the system boots 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 expan-
sion card1 , 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.
2.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 1), which
correspond to phases of the bootstrap operation. The first
phase is the Power on Self Test or POST [Ltd91]. POST
is invoked in one of four ways:
1. Applying power to the computer automatically invokes POST causing the processor to jump to the entry point indicated by the processor reset vector.
2. Hardware reset also causes the processor to jump to
the entry point indicated by the processor reset vector.
3. Warm boot (ctrl-alt-del under DOS) invokes POST
without testing or initializing the upper 64K of system memory.
4. Software programs, if permitted by the operating
system, can jump to the processor reset vector.
In each of the cases above, a sequence of tests are conducted. All of these tests, except for the initial processor
self test, are under the control of the system BIOS.
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 immediately passed to it. When the ROM completes its execution, control is returned to the BIOS.
The final step of the POST process calls the BIOS operating 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
1 Ideally, the signature would be embedded in the firmware of the
secondary boot block depending on the operating system [Gri93] [Eli96] or boot loader [Alm96].
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 figure 1.
Operating System
Level 4
Boot Block
Level 3
Expansion ROMs
are responsible 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 process is accomplished with a jump or a call instruction
without 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. The pseudo code for the action taken at
each level, , before transition to level
Expansion ROMs
if (IntegrityValid(L+1))) {
} else {
Level 2
2.2.2 AEGIS BIOS Modifications
System BIOS
AEGIS modifies the boot process shown in figure 1 by
the BIOS into two logical sections. The first secLevel 1
tion contains the bare essentials needed for integrity verification and recovery. It comprises the “trusted software”.
Initiate POST
The second section contains the remainder of the BIOS
and the CMOS.
Figure 1: IBM PC boot process
The first section executes and performs the standard
checksum calculation over its address space to protect
against ROM failures. Following successful completion
2.2.1 A Layered Boot Process
of the checksum, the cryptographic hash of the second
We have divided the boot process into several levels to section is computed and verified against a stored signasimplify and organize the AEGIS BIOS modifications, as ture. If the signature is valid, control is passed to the secshown in figure 2. Each increasing level adds functional- ond section, i.e., Level 1.
ity to the system, providing correspondingly higher levThe second section proceeds normally with one
els of abstraction. The lowest level is Level 0. Level 0 change. Prior to executing an expansion ROM, a crypcontains the small section of trusted software, digital sig- tographic hash is computed and verified against a stored
natures, public key certificates, and recovery code. The digital signature for the expansion code. If the signature
integrity of this level is assumed to be valid. We do, how- is valid, then control is passed to the expansion ROM.
ever, perform an initial checksum test to identify PROM Once the verification of each expansion ROM is complete
failures. The first level contains the remainder of the usual (Level 2), the BIOS passes control to the operating sysBIOS code, and the CMOS. The second level contains tem bootstrap code. The bootstrap code was previously
all of the expansion cards and their associated ROMs, if verified as part of section 2 of the BIOS, and thus no furany. The third level contains the operating system boot ther verification is required. The bootstrap code finds the
block(s). These are resident on the bootable device and bootable device and verifies the boot block.
Assuming that the boot block is verified successfully,
control is passed to it (Level 3). If a secondary 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 through a trusted repository.
2.3 Integrity Policy
Formalizing the discussion in Section 1.1, the AEGIS integrity policy prevents the execution of a component if
its integrity can not be validated. There are three reasons
why the integrity of a component could become invalid.
The first is the integrity of the component could change
because of some hardware or software malfunction, or
it could change because of some malicious act. Finally,
the component’s certificate timestamp may no longer be
valid. In each case, the client MUST attempt to recover
from a trusted repository. Should a trusted repository be
unavailable after several attempts, then the client’s further action depends on the security policy of the user. For
instance, a user may choose to continue operation in a
limited manner, or they may choose to halt operations altogether.
The AEGIS Integrity Policy can be represented by the
following pseudo code:
Trusted Repository
The trusted repository can either be an expansion ROM
board that contains verified copies of the required software, or it can be a network host. If the repository is
a ROM board, then simple memory copies can repair or
shadow failures. If the repository is a network host, then
a protocol with strong authentication is required
In the case of a network host, the detection of an integrity failure causes the system to boot into a recovery
kernel contained on the network card ROM. The recovery
kernel contacts a “trusted” host through the secure protocol described in this paper to recover a signed copy of
the failed component. The failed component is then shadowed or repaired, and the system is restarted (warm boot).
The resultant AEGIS boot process is shown in figure 2. Note that when the boot process enters the recovery procedure it becomes isomorphic to a secure network
boot. We leverage this fact by adding authentication to the
well known network protocols supporting the boot process DHCP[Dro97], and TFTP[Fin84] and using them as
our recovery protocol.
User Programs
Network Host
Level 5
Operating System
Level 4
Boot Block
Level 3
if (ComponentCertificateValid) {
if (ComponentIntegrityValid) {
} elseif (Recover(Component)) {
} else {
} else if (Recover(Certificate)) {
goto StartOver;
} else {
Expansion ROMs
Level 2
BIOS Section 2
Level 1
BIOS Section 1
Level 0
Initiate POST
Control Transition
Recovery Transition
Figure 2: AEGIS boot control flow
3 AEGIS Network Recovery Protocol
((cert (issuer (hash-of-key (hash sha1
(subject (hash-of-key (hash sha1
The AEGIS network recovery protocol combines proto(tag (client))
cols and algorithms from networking and cryptography
(not-before 03/29/97-0000)
to ensure the security of the protocol. This section first
(not-after 03/29/98-0000))
provides an introduction to the material needed to fully
(signature (hash sha1 hashbytes)
understand the recovery protocol. We then describe the
(hash-of-key (hash sha1 cakey))
protocol and provide examples of its use.
3.1 Certificates
The usual purpose of a certificate with respect to public
key cryptography is to bind a public key with an identity.
While this binding is essential for strong authentication,
it severely limits the potential of certificates, e.g. anonymous transactions. The most widely used certificate standard, the X.509[Com89] and its variants, provide only this
binding. The X.509 standard, also, suffers from other serious problems in addition to its limited use. The most
significant is ambiguity in the parsing of compliant certificates because of its use of the Basic Encoding Rules
(BER)[Com88]. The encoding rules also require a great
deal of space to implement, and the encoded certificates
are usually large.
Because of the limits and problems with the X.509
certificate standard, we use a subset of the proposed
SDSI/SPKI 2.0 certificate structure[EFRT97][Ell97] instead. The SDSI/SPKI format does not suffer from the
same problems as X.509, and it offers additional functionality.
Figure 3: AEGIS Authorization Certificate
infrastructure and access control lists. In AEGIS, we use
two capabilities: SERVER, and CLIENT with the obvious
In AEGIS we only use three types of certificates. The
first is an authorization certificate. This certificate, signed
by a trusted third party or certificate authority, grants to
the keyholder (the machine that holds the private key)
the capability to generate the second type of certificatean authentication certificate. The authentication certificate demonstrates that the client or server actually hold
the private key corresponding to the public key identified
in the authentication certificate. The nonce field is used
along with a corresponding nonce in the server authentication certificate to ensure that the authentication protocol is “Fail Stop”[GS95] detecting and preventing active
attacks such as a man–in–the–middle. The msg-hash field
ensures that the entire message containing the certificates
has not been modified. Using the msg-hash in the authen3.1.1 SDSI/SPKI Lite
tication certificate eliminates a signature and verification
Since the SDSI/SPKI standard is still under development, operation since the entire message no longer needs to be
we have chosen to support the small subset of SDSI/SPKI signed. The additional server fields are used to pass opneeded for AEGIS. We call this subset SDSI/SPKI Lite.
tional Diffie-Helman parameters to the client so that these
SDSI/SPKI provides for functionality beyond the sim- parameters need not be global values. While clients are
ple binding of an identity with a public key. Identity based free to set the validity period of the authentication certificertificates require the existence of an Access Control List cate to whatever they desire, we expect that clients will
(ACL) which describe the access rights of an entity. Main- keep the period short. Examples of these certificates are
taining such lists in a distributed environment is a com- shown in figures 3 , 4, and 5. The third and final certifiplex and difficult task. In contrast, SDSI/SPKI provides cate format is the component signature certificate shown
for the notion of a capability [Lev84]. In a capability in figure 6. This certificate is either embedded in a combased model, the certificate itself carries the authoriza- ponent or stored in a table. It is used with the AEGIS boot
tions of the holder eliminating the need for an identity process described earlier in this paper.
((cert (issuer (hash-of-key (hash sha1
(subject (hash-of-key (hash sha1
(tag (client (cnonce cbytes)
(hash sha1 hbytes))))
(not-before 09/01/97-0000)
(not-after 09/01/97-0000))
(signature (hash sha1 hashbytes)
(public-key dsa-sha1 clientkey)
((cert (issuer (hash-of-key (hash sha1
(subject (hash sha1
(not-before 09/01/97-0000)
(not-after 09/05/97-0000))
(signature (hash sha1
(public-key dsa-sha1
Figure 6: AEGIS Component Certificate
3.1.2 Certificate Revocation Lists
Figure 4: AEGIS Client Authentication Certificate
((cert (issuer (hash-of-key (hash sha1
(subject (hash-of-key (hash sha1
(tag (server (dh-g gbytes)
(dh-p pbytes)
(dh-Y ybytes)
(hash sha1 hbytes))
(cnonce cbytes)
(snonce sbytes)))
(not-before 09/01/97-0900)
(not-after 09/01/97-0900))
(hash sha1 hashbytes)
(public-key dsa-sha1 serverkey)
Figure 5: AEGIS Server Authentication Certificate
Requiring each client to maintain a Certificate Revocation
List (CRL) places a significant burden on the non-volatile
storage of the client. Rather than use CRLs, we choose
instead to keep the validity period of certificates short as
in the SDSI/SPKI model and require the client to update
the certificates when they expire. This serves two purposes beyond the ability to handle key revocation. First,
we eliminate the storage requirements for CRLs. Second,
we can potentially reduce the amount of system maintenance required of the client. Since the client must connect
to the server on a regular basis to update the component
certificates, the server can, at the same time, update the
actual component as well if a new version is available.
Diffie Hellman Key Agreement
The Diffie Hellman Key Agreement (DH) [DH76] permits two parties to establish a shared secret between them.
Unfortunately, the algorithm as originally proposed is susceptible to a man-in-the-middle attack. The attack can be
defeated, however, by combining DH with a public key algorithm such as DSA as proposed in the Station to Station
The algorithm is based on the difficulty of calculating discrete logarithms in a finite field. Each participant
agrees to two primes, and , such that is primitive
. These values do not need to be protected in order to ensure the strength of the system, and therefore can
be public values. Each participant then generates a large
random integer. Bob generates as his large random integer and computes
. He then sends
to Alice. Alice generates as her large random integer
and computes
. She then sends to Bob.
Bob and Alice can now each compute a shared secret, ,
, reby computing
SHA1 Message Authentication Code
Message Authentication Codes (MAC) utilize a secret, ,
shared between the communicating parties and a message
digest. We use the Secure Hash Algorithm (SHA1), and
the HMAC described in RFC 2104[KBC97]. The MAC is
defined as:
36587 + )
3.3 Digital Signature Standard
QP -R 3J587 + S QP -R )9.T.
is the message or datagram,
is an array of
64 bytes each with the value 0x5c, and
is an array
The Digital Signature Standard (DSS) includes a digital
of sixty four bytes each with the value 0x36.
is zero
signature algorithm (DSA) [oS94] and a cryptographic
padded to sixty four bytes. The result of this MAC is the
hash algorithm (SHA1) [oS95]. DSA produces a 320 bit
160-bit SHA1 digest.
signature using the following parameters:
A prime, , between 512 and 1024 bits in length. The
size of the prime must also be a multiple of 64.
"!$#&% '
0 1 2+ +436587 + )9. :-*;."*.<(+ -,
= /.
* 1
> 1 =
? @+A36587 + )9.B > .C
?/D @+ *EB > .F
G *
The DHCP protocol[Dro97] provides clients the ability to
their networking and host specific parameters
A 160 bit prime factor, , of
dynamically during the boot process. The typical parameters are the IP addresses of the client, gateways, and DNS
, where
and is less than
DHCP, however, supports up to 255 configuration
such that is greater than 1.
parameters, or options. Currently approximately one hundred options are defined for DHCP [AD97]. One of these
, where is less than .
options is an authentication option which is described in
Section 4.1.
, where
The format of a DHCP message is shown in figure
7[Dro97]. The first field in the DHCP message is the
The parameters , , and are public. The private key is
opcode. The opcode can have one of two values, 1 for
, and the public key is .
A signature of a message, , is computed in the fol- a BOOTREQUEST message, and 2 for a BOOTREPLY
lowing manner. The signer generates a random number, message. The next field, htype, is the hardware address
type defined by the “Assigned Numbers” RFC[RP94], and
, that is less than . They then compute
indicates the length of the hardware address. hops is
, and
. The
zero by the client and used by BOOTP relay agents
values and , each 160 bits in length, comprise the sigto
if they should forward the message. xid is a
nature. The receiver verifies the signature by computing:
random number chosen by the client. Its use is to permit
the client and the server to associate messages between
each other. secs is set by the client to the number of seconds elapsed since the start address acquisition process.
Currently, only the leftmost bit of the flags field is used
to help solve an IP multicast problem. The remaining bits
must be zero. ciaddr is the client address if the client
knows it already, yiaddr is “your” address set by the server
if the client did not know (or had a bad one) its address.
The signature is verified by comparing and . If they are giaddr is the relay agent address. chaddr is the client’s
equal, then the signature is valid.
hardware address. sname is an optional null terminated
Client IP Address
Your (Client) IP Address
IP Address of Next Server in Bootstrap
Relay Agent IP Address
Client Hardware Address (16 bytes)
Optional Server Name (64 bytes)
Figure 8: Initial DHCP Message Exchange
cation of a bootstrap program to support diskless clients.
After the client receives the IP address of the boot server
and the name of the bootstrap program, the client uses
TFTP[Sol92] to contact the server and transfer the file.
Boot File Name (128 bytes)
TFTP was designed to be simple and small to fit in a ROM
on a diskless client. Because of this, TFTP uses UDP
rather than TCP with no authentication included in the
protocol. TFTP does, however, have an option capabilFigure 7: DHCP Message Format
ity [MH95] similar to DHCP.
TFTP has five unique messages that are identified by a
string containing the server’s name. file is the name of two byte opcode value at the beginning of the packet. The
the boot file. In AEGIS, this is the name of the compo- Read Request (RRQ) and the Write Request (WRQ) packnent to recover. Finally, options is a variable length field ets, opcodes 1 and 2 respectively, share the same format,
containing any options associated with the message.
see figure 12. The Data (DATA) packet contains three
The initial message exchange between the client and fields. The first field is the two byte opcode, 3 for DATA.
the server is shown in figure 8. The client begins the pro- Following the opcode is a two byte field containing the
cess by sending a DHCPDISCOVER message as a broad- block number of the data, beginning at 1 and increasing.
cast message on its local area network. The broadcast The third and final field of the packet contains the actual
message may or may not be forwarded beyond the LAN block of data transferred. Typically, the block size is 512
depending on the existence of relay agents at the gate- bytes. However, the size can be increased through the use
ways. Any or all DHCP servers respond with a DHCPOF- of the TFTP options. Should the block be smaller than
FER message. The client selects one of the DHCPOFFER the blocksize, this identifies the packet as the final DATA
messages and responds to that server with a DHCPRE- packet. Each DATA packet is acknowledged by a four
QUEST message, and the server acknowledges it with a byte ACK packet, opcode 4, containing the opcode and
the acknowledged block number. The final packet, opIn addition to providing networking and host specific code 5, is the ERROR packet with three fields. The first is
parameters, DHCP can provide the name and server lo- the two byte opcode. The second is a two byte error code,
Options (variable)
1 . The Server receives the message and verinonce
matches that sent in its
fies the signature and that
previous message. If both are valid, then the Server can
generate the shared secret, , using DH,
The Client similarly generates the shared secret,
. The shared secret, , can now be used to authenticate messages between the Server and the Client until
such time as both agree to change . Figure 9 depicts the
entire exchange between the Client and the Server with
the DHCP messages identified. The use of the authentication certificate assists in ensuring that the protocol is
3.7 Initial Mutual Authentication Protocol
“Fail Stop” through the use of nonces and a short validity
also permits
A Client (AEGIS) and a Server (Trusted Repository) wish period for the certificate. The use of
to communicate and establish a shared secret after au- the Server to reuse over a limited period. This reduces
thenticating the identity of each other. There has been the computational overhead on the server during high acno prior contact between the Client and the Server other tivity periods. The potential for a TCPSYN like denial
than to agree on a trusted third party, or a public key in- of service attack[HB96] is mitigated in the same manner
frastructure, to sign their authorization certificates, . by the authentication certificate. The authorization certifiThe Server and the Client also need to have a copy of the cate also prevents clients from masquerading as a server
trusted third party’s public key, . The Client sends because of the client/server capability tag. This is a benea message to the Server containing the Client’s autho- fit not possible with X.509 based certificates.
rization and authentication certificates, . The Server
receives the message and verifies the Client’s signature
3.8 Subsequent Message Authentication
on the authentication certificate and that the hash contained in the authentication certificate matches that of the Subsequent messages, e.g. TFTP messages, use the
. The signature of the CA on the autho- SHA1 HMAC defined in section 3.4 augmented with a
rization certificate is also verified. If all are valid and one up counter to prevent replays. The counter is initially
the timestamp on the authentication certificate is within set to zero when the shared secret, , is derived.
bounds, then the Server sends to the Client a message containing its authorization and authentication certificates.
The server’s authentication certificate may include the op- 4 Implementation
tional DH parameters, and , and , where
. If the DH parameters are not included in the cer- Moving from a high level design to an implementation retificate, then default values for and are used. Cur- quires a great deal of work. In this section we take the
rently, we are using the same default values as those protocol and certificates described in section 4 and de
, and scribe their implementation using DHCP and TFTP. We
used in SKIP[AMP]. The server’s nonce,
the client’s nonce,
, are also included in the mes- also provide the message formats and type information.
sage. The Client receives this message and verifies the We conclude the section by providing performance inforsignatures on the authentication and authorization certifi- mation, and discussing related work.
cates, that the hash in the servers authentication certificate
matches that
matches the message hash, and that 4.1 DHCP Authentication Option
sent in the first message. If all are valid and the timestamp
value of the authentication certificate is within bounds and DHCP is extensible through the use of the variable length
matches that sent in the first message, then the options field at the end of each DHCP message. The forClient sends a signed message to the Server containing its mat and use of this field is currently defined by an InDH parameter where
, and the server’s ternet RFC [AD97]. An option for authentication is also
and the final field is a zero terminated netascii string containing an error message. Figure 13 depicts the various
TFTP messages.
A TFTP session for reading/downloading a file begins
with the client sending a RRQ packet to the sever and receiving either the first DATA packet in response, or an
ERROR packet if the request was denied. The client responds with an ACK packet, and the process continues
until the file is transferred.
1 O (
1 )
? H(M)
hash =
VClient (CAN
? H(M)
hash =
? cnonce
cnonce =
Y=g y mod p
Server Server
VServer (CAN
X=gx mod p
X, snonce, S Client
k = Y mod p
snonce = snonce
VClient (SClient (M))
k = X mod p
Figure 9: Authentication Message Exchange
defined by an expired draft RFC [Dro96]. The format
of the message is shown in figure 10. The DHCP au0
Authentication Information
Authorization Certificate
Client Authentication Certificate
Server Authentication Certificate
Component Authentication Certificate
X value
Table 1: AEGIS Types
Figure 10: DHCP Authentication Option Format
thentication option was designed to support a wide variety of authentication schemes by using the single byte
protocol and length fields. Unfortunately, a single byte
value for the size in octets of authentication information
is too small for the AEGIS authentication information.
To solve this problem, our choices were to either violate
the current DHCP options standard and use a two byte
size field and potentially cause interoperability problems,
or place an additional restriction on the AEGIS authentication packet, requiring it to be the last option on any
DHCP packet. We have selected the latter. Using this and
a unique AEGIS option number permits interoperability
with current DHCP servers.
Since we are unable to use the authentication option
message format shown in figure 10, we must define a
new DHCP option format for AEGIS Authentication. The
AEGIS option uses the same basic format as the normal
DHCP format. The only difference is the use of a two byte
size field. Embedded in the data portion of the option are
the AEGIS certificates, and other data as required. These
fields are identified through the use of a one byte AEGIS
type followed by a two byte size field. The AEGIS Authentication format is shown in figure 11. The different
AEGIS Authentication Information
Figure 11: AEGIS Authentication Option Format
AEGIS types are shown in table 1.
Adding Authentication to TFTP
We define a new TFTP option, HMAC-SHA1, that uses
the HMAC defined in section 3.4 along with a 32 bit one
up counter for use with the TFTP Read (RRQ) and Write
(WRQ) requests. The format of a RRQ or WRQ packet
with the HMAC option is shown in figure 12. The counter
OPC FileName
0 Mode 0 "hmac-sha1"
TFTP Message
0 Count 0 Digest 0
TFTP Option Extension
Figure 12: TFTP RRQ/WRQ Authentication Packet Format
is two bytes in length, and its purpose is to prevent replay
attacks. Both the client and the server initialize the count
to zero immediately after is derived from the protocol
shown in figure 9.
The TFTP option extension, however, is not defined for
TFTP DATA or ERROR packets. Therefore, we must extend2 those packets in the same manner as we did with the
RRQ and WRQ packets shown in figure 12. The TFTP
packet formats are shown in figure 13.
Another TFTP implementation problem is how to handle the “lock-step” nature of the protocol and still prevent
replays. The solution we have adopted provides a narrow window for an adversary to obtain a copy of the file
from the server without proper authentication by replaying the message to the server before the clients next message. We believe the benefits of this approach, not having
to change the TFTP protocol other than a small message
2 We are currently investigating the interoperability issues with existing servers raised by this modification
DSA Verify (1024bit)
DSA Sign (1024bit)
Generate X,Y (1024bit)
Generate k (1024bit)
6.1 MB/sec
36 msec
23 msec
22 msec
71 msec
Table 2: CryptoLib 1.1 Benchmarks
Error Message
Figure 13: TFTP packets
format change, outweigh the potential problems associated with dramatically changing the protocol.
certificate is negligible and therefore not included in the
estimates below.
4.4.1 Initial Exchange
The initial authentication exchange includes the first three
4.3 Using DHCP/TFTP as the Recovery DHCPREQUEST. DHCPDISCOVER requires the client
to perfom one signature operation, and the server must
perform two verify operations. Thus, the total cost of this
Once authentication is added to DHCP and TFTP, AEGIS
message is 95 msec. The DHCPOFFER message requires
can use them without further modifications as its recovery
the server to generate and perform one signature operaprotocol. In AEGIS, the client follows the DHCP prototion. The client must perform two verify operations. This
col but adds to the DHCPDISCOVER message the name
results in a message cost of 117 msec. The final message,
of the required component needed followed by the SHA1
DHCPREQUEST, requires the client to generate
hash of the component in the boot file name field. Once
, and perform one signature operation. The server must
the DHCP protocol is completed and the shared secret esperform one verify operation, and generate resulting in
tablished, the AEGIS client contacts the trusted repository
a message cost of 107 msec. Summing the cost of these
using TFTP with authentication and downloads the new
three messages gives a total cost of 319 msec.
While the above time may seem too high a cost to pay
for security, the total time is small when compared to the
total time spent booting a computer system. It is unlikely
4.4 Performance Information
that users will see the increase in time required to perform
We are currently in the process of implementing this the authentication.
work using the Internet Software Consortium’s DHCP
server [Lem97], and AT&T’s Cryptolib [LMB95]. We
will provide specific performance information on our im- 4.4.2 Subsequent Exchanges
plementation in the final copy of this paper. We expect to
Subsequent messages use the MAC described earlier, and
have a completed prototype of the recovery process by the
will likely (in a LAN situation) be bounded by the speed
end of September. In the mean time, we are providing perof SHA1, 6.1 MB/sec.
formance estimates using the times shown in table 2. The
results were generated using a 200Mhz PentiumPro with
32MB of memory. For the purposes of these estimates, 4.5 Related Work
we assume that each DHCP message is three kilobytes in
length. The cost of hashing the first and second message To our knowledge, there is no previous work involving
for comparison to the hash contained in the authentication the secure recovery of bootstrap components. There have
been, however, several efforts at incorporating authentication into DHCP. Two are expired draft RFCs. The first effort [Dro] involves the use of a shared secret between the
DHCP client and server. While this approach is secure,
it severely limits the mobility of clients to those domains
where a shared secret was previously established. Furthermore, the maintenance and protection of the shared
secrets is a difficult process. Another effort at incorporating authentication into DHCP was by TIS. This proposal
combines DHCP with DNSSEC[EK97]. This approach
provides for the mobility of DHCP clients, but at a significant increase in cost in terms of complexity. The client
implementation, in order to support this approach, must
also include an implementation of DNSSEC. This will
significantly increase the size of client code- possibly beyond the ROM size available to the client. Recently, Intel
has proposed authentication support for DHCP [Pat97].
Their proposal uses a two phase approach. In the first
phase, the computer system boots normally using DHCP.
The second phase begins after the system completes the
DHCP process and uses ISAKMP [MSST96] to exchange
a security association. This security association is then
used to once again obtain the configuration information
from the DHCP server using a secure channel, if such a
channel can be established. This information is then compared to that obtained in the first phase. If they differ or a
secure channel cannot be established, then the boot fails.
The benefit of this approach is that it requires no changes
to DHCP. The drawbacks are the same as the DNSSEC
approach with the addition of two problems. The first is a
possible race condition vulnerability during the time before the two configurations are compared. The second is
that the approach does not protect against denial of service attacks.
5 Future Work
One of the major goals of the AEGIS research has been
the development of new ideas for the construction of secure systems, with the additional constraint that the ideas
must be realizable today or in the very near term with
commercial platforms. While confining, this constraint
ensures that AEGIS results will have impact beyond simply the academic community.
We intend to further investigate the centralized man-
agement of the bootstrap process. This has many practical uses, including desktop management in LAN-attached
PCs (where integrity failures might be stimulated by
viruses or user-inserted cards), as well as secure, recoverable bootstrap for network elements with processors, such
as bridges and IP routers.
The recovery protocol itself will be fully incorporated
into the DHCP model, and we intend to propose it as an
authentication RFC standard, perhaps as soon as the December 1997 Internet Engineering Task Force meeting.
We introduced the AEGIS secure bootstrap architecture,
explained its approach to integrity and the assumptions
it makes about the operating environment, and discussed
the general idea behind automated recovery in a secure
bootstrap process using trusted sources. We are currently
implementing this new automated recovery process in the
context of the PC architecture using a small portion of the
BIOS. We have shown how it can be extended to recovery over networks by use of cryptographic protocols, and
provided one such protocol, with expected data structures
and packet formats.
We believe that this work has a significant impact on
the administration and manage-ability of systems. While
we have previously demonstrated the need and provided
an architecture for a secure bootstrap for any trusted system, here we have shown how that architecture can be
utilized in a very realistic environment, with no loss of
security. Thus, we can build distributed computer systems of nodes which are in two logical states: (1) nonoperational (e.g., down or recovering), and (2) operational
and trusted. Such simple states and transitions ease, and
in some sense make possible, verification of applications
built on the distributed systems.
S. Alexander and R. Droms. DHCP Options and BOOTP Vendor Extensions. Internet RFC 2132, March 1997.
William A. Arbaugh, David J. Farber, and
Jonathan M. Smith. A Secure and Reliable
Bootstrap Architecture. In Proceedings 1997
IEEE Symposium on Security and Privacy,
pages 65–71, May 1997.
July 1996. 2.1.5 FreeBSD.
Werner Almesberger.
LILO Technical
Overview, version 19 edition, May 1996.
Carl M. Ellison. SDSI/SPKI BNF. Private
Email, July 1997.
Ross Finlayson. Bootstrap Loading using
Ashar Aziz,
Tom Markson,
and [Fin84]
TFTP. Internet RFC 906, June 1984.
Assigned Numbers for SKIP Protocols.
[GDM89] Y. Desmedt G. Davida and B. Matt. Defend
ing Systems Against Viruses through CrypConsultation Committee.
Recommendatographic Authentication. In 1989 IEEE
Symposium on Security and Privacy, pages
tion X.209: Specification of Basic Encod312–318. IEEE, 1989.
ing Rules for Abstract Syntax Notation One
(ASN.1), 1988.
Consultation Committee. X.509: The Di/sys/i386/boot/biosboot/README.MACH,
rectory Authentication Framework. InterOctober 1993. 2.1.5 FreeBSD.
national Telephone and Telegraph, International Telecommunications Union, Geneva,
Li Gong and Paul Syverson. Fail-Stop Pro1989.
tocols: An Approach to Designing Secure
Protocols. In Proceedings of IFIP DCCA-5,
W. Diffie and M.E. Hellman. New DirecSeptember 1995.
tions in Cryptography. IEEE Transactions on
Information Theory, IT–22(6):644–654, Nov
L.T. Heberlein and M. Bishop. Attack Class:
Address Spoofing. In Proceedings of the 19th
National Information Systems Security ConR. Droms. Authentication for DHCP mesference, pages 371–377, October 1996.
sages. Work in Progress.
H. Krawczyk, M. Bellare, and R. Canetti.
HMAC:Keyed–Hashing for Message Authentication. Internet RFC 2104, February
[DvOW92] W. Diffie, P.C. van Oorschot, and M.J.
Wiener. Authentication and Authenticated
Key Exchanges. Designs, Codes and Cryp- [Lev84]
tography, 2:107–125, 1992.
Ted Lemon. Dynamic Host Configuration
Server., 1997.
H.M. Levy. Capability Based Computer Systems. Digital Press, 1984.
[EFRT97] Carl M. Ellison, Bill Frantz, Ron Rivest, and
Brian M. Thomas. Simple Public Key Certificate. Work in Progress, April 1997.
Jack Lacy, Don Mitchell, and Matt
Blaze. Cryptolib 1.1. Email to, 1995.
R. Droms. Authentication for DHCP Messages. Work in Progress, November 1996.
R. Droms. Dynamic Host Configuration Protocol, RFC 2131, March 1997.
D. Eastlake and C. Kaufman. Dynamic Name [Ltd91]
Service and Security. Internet RFC 2065,
January 1997.
Phoenix Technologies Ltd. System BIOS for
IBM PCs, Compatibles, and EISA Computers. Addison Wesley, 2nd edition, 1991.
G. Malkin and A. Harkin. TFTP Option Extension. Internet RFC 1782, March 1995.
Microsoft. Authenticode Techonology. Microsoft’s Developer Network Library, October 1996.
[MSST96] Douglas Maughan, Mark Schertler, Mark
Schneider, and Jeff Turner. Internet Security Association and Key Management Protocol (isakmp). Internet–draft, IPSEC Working
Group, June 1996.
National Institute of Standards. Digital Signature Standard. Technical Report FIPS-186,
U.S. Department of Commerce, May 1994.
National Institute of Standards. Secure Hash
Standard. Technical Report FIPS-180-1, U.S.
Department of Commerce, April 1995. Also
known as: 59 Fed Reg 35317 (1994).
Baiju V. Patel. Securing dhcp.
Progress, July 1997.
Maria M. Pozzo and Terrence E. Gray. A
Model for the Containment of Computer
Viruses. In 1989 IEEE Symposium on Security and Privacy, pages 312–318. IEEE,
J. Reynolds and J. Postel. Assigned Numbers. Internet RFC 1700, October 1994.
K. R. Sollins. The TFTP Protocol (revision
2). Internet RFC 1350, July 1992.
Work in
Appendix A
<byte-string> :: <bytes> ;
<bytes> :: <decimal> ‘‘:’’ {binary byte string of that length} ;
<cert> :: ‘‘(‘‘ ‘‘cert’’ <issuer> <subject> <deleg>? <tag> <valid>?‘‘)’’ ;
<client> :: ‘‘(‘‘ ‘‘client’’ <cnonce>? <msg-hash>? ‘‘)’’ ;
<cnonce> :: ‘‘(‘‘ ‘‘cnonce’’ <byte-string> ‘‘)’’ ;
<date> :: <byte-string> ;
<ddigit> :: ‘‘0’’ | <nzdigit> ;
<decimal> :: <nzddigit> <ddigit> ;
<deleg> :: ‘‘(‘‘ ‘‘propagate’’ ‘‘)’’ ;
<hash> :: ‘‘(‘‘ ‘‘hash’’ ‘‘sha1’’ <byte-string> ‘‘)’’ ;
<issuer> :: ‘‘(‘‘ ‘‘issuer’’ <issuer-name> ‘‘)’’ ;
<issuer-name> :: <principal>;
<msg-hash> :: ‘‘(‘‘ ‘‘msg-hash’’ <hash> ‘‘)’’ ;
<not-after> :: ‘‘(‘‘ ‘‘not-after <date> ‘‘)’’ ;
<not-before> :: ‘‘(‘‘ ‘‘not-before’’ <date> ‘‘)’’ ;
<nzdigit> :: ‘‘1’’|‘‘2’’|‘‘3’’|‘‘4’’|‘‘5’’|‘‘6’’|‘‘7’’|‘‘8’’|‘‘9’’;
<obj-hash> :: ‘‘(‘‘ ‘‘object-hash’’ <hash> ‘‘)’’ ;
<principle> :: <pub-key> | <hash-of-key> ;
<pub-key> :: ‘‘(‘‘ ‘‘public-key’’ <pub-sig-alg-id> <s-expr>* <uri>?‘‘)’’ ;
<pub-sig-alg-id> :: ‘‘dsa-sha1’’ ;
<s-expr> :: ‘‘(‘‘ <byte-string> ‘‘)’’ ;
<server> :: ‘‘(‘‘ ‘‘server’’ <dh-g>? <dh-p>? <dh-Y>? <snonce>?
<msg-hash>? ‘‘)’’ ;
<signature> :: ‘‘(‘‘ ‘‘signature’’ <hash> <principle> <byte-string> ‘‘)’’ ;
<subject> :: <principal> | <obj-hash> ;
<tag> :: ‘‘(‘‘ ‘‘tag’’ ‘‘)’’ | ‘‘(‘‘ ‘‘tag’’ <tag-body> ‘‘)’’ ;
<tag-body> :: <client> | <server> ;
<valid> :: <not-before>? <not-after>? ;