Electrical computers and digital processing systems: support – Digital data processing system initialization or configuration – Loading initialization program
Reexamination Certificate
1998-10-02
2001-02-06
Butler, Dennis M. (Department: 2787)
Electrical computers and digital processing systems: support
Digital data processing system initialization or configuration
Loading initialization program
C713S152000
Reexamination Certificate
active
06185678
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to an architecture for initializing a computer system and more particularly to a secure bootstrap process and automated recovery procedure.
2. Related Art
Systems are organized as layers to limit complexity. A common layering principle is the use of layers of abstraction to mark layer boundaries. A computer system is organized in a series of levels of abstraction, each of which defines a “virtual machine” upon which higher levels of abstraction are constructed. Each virtual machine presumes the correctness (integrity) of whatever virtual or real machines underlie its own operation. Under the presumption that the hardware comprising the machine (the lowest layer) is valid, integrity of a layer can be guaranteed if and only if: (1) the integrity of the lower layers is checked, and (2) transitions to higher layers occur only after integrity checks on them are complete. The resulting integrity “chain” inductively guarantees system integrity. When these suppositions are true, the system is said to possess integrity. When these conditions are not met, as they typically are not in the bootstrapping (initialization) of a computer system, no integrity guarantees can be made. Yet, these guarantees are increasingly important to diverse applications such as Internet commerce, security systems, and “active networks.” However, it is surprising, given the great attention paid to operating system security today, 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 problem by including the boot components (including but not limited to the ROM BIOS (Basic Input Output System), any expansion card ROMs, CMOS memory and NVRAM, the boot sector and the operating system kernel) in the trusted computing base (TCB). That is, the bootstrap steps are explicitly trusted. However, the present invention discloses that this provides a false sense of security to the users of the operating system, and more importantly, is unnecessary.
A number of attempts were made in the 1960s and 1970s to produce secure computing systems, using a secure operating system environment as a basis. However, an essential and unnecessary presumption of the security arguments for these designs was that system layers underpinning the operating system, whether hardware, firmware, or both, are trusted. The first presentation of a secure boot process was done by Yee in
Dyad: A system for using physically secure coprocessors,
by J. Tygar and B. Yee, Technical Report CMU-CS-91-140R, Carnegie Mellon University, May 1991. 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 expanded his discussion of a secure boot in his thesis, see B. Yee,
Using Secure Coprocessors,
Ph.D. thesis, Carnegie Mellon University, 1994, but he continues to state that the secure coprocessor should control the boot process verifying each component prior to its use. Yee states that boot ROM modifications may be required, but since a prototype secure boot process was never implemented, more implementation questions are raised than answered by his discussion.
P.C. Clark presents, in
BITS: A Smartcard Protected Operating System,
Ph.D. thesis, George Washington University, 1994, a secure boot process for DOS that stores all of the operating system bootstrap code on a PCMCIA card. He does not address 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 capability. However, the use of the PCMCIA card containing all of the system boot files creates several configuration management problems, e.g., a system upgrade requires the reprogramming of all the cards in circulation, and since today many users have multiple operating systems on their personal computers a user needs a separate PCMCIA card for each operating system they wish to use.
B. Lampson, M Abadi, and M. Burrows also describe a secure boot model, in
Authentication in distributed systems: Theory and Practice,
ACM Transactions on Computer Systems, v10:265-310, November 1992, as an example for their authentication calculus. In the Lampson et al. model, the entire boot ROM is trusted, and they do not address the verification of expansion cards/ROMs. The Birlix Security Architecture, disclosed in
The Birlix security architecture,
by H. Härtig, O. Kowalski and W Kühnhauser, Journal of Computer Security, 2(1):5-21, 1993, proposes a model designed by Michael Gross that is similar to the Lampson et al. model. As a result, 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. The present invention, on the other hand, leaves 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.
Two patents, U.S. Pat. No. 5,379,342 to Arnold (“the Arnold patent”) and U.S. Pat. No. 5,421,006 to Jablon (“the Jablon patent”) also present secure boot models. Both of these patents are similar in that the BIOS verifies the boot block before control is transferred and the boot block verifies the OS kernel before control is transferred. The Jablon patent continues to provide static integrity checks while the operating system is running, i.e validating the integrity of a program before execution. Another difference between the two patents is that the Arnold patent uses a Modification Detection Code, e.g. MD5, and Jablon uses public key cryptography. Both approaches, however, fail to verify the BIOS beyond the normal eight bit additive CRC, and both approaches also fail to verify expansion ROMs. The ROMs on add in boards are programs, and they are run during the boot process' of these two patents without verification. Therefore, Jablon's and Arnold's approaches fail to provide a secure bootstrap process since neither approach verifies the BIOS and the ROMs.
Several anti-virus products also claim to create a secure boot process. A number of companies and BIOS vendors have anti-virus capabilities in their products. All concern themselves with the boot block only. Those products that run as an application over the operating system typically store a MDC for the boot block and check it when run. This detects changes to the boot block, but is susceptible to spoofing. The BIOS anti-virus protection simply alerts the user when a process is attempting to write to the boot block. The protection is ineffective when a protected mode operating system is running and a real mode application writes directly to the storage device. Finally, several vendors are now offering ROM based anti-virus protection. These products work by using an expansion ROM board that is executed during the boot process. The code on the ROM board checks the boot block against a previously stored MDC in order to detect changes. The vendors claim this prevents the possibility of spoofing the check as is possible when the check is done by an application. This is not entirely true, since the BIOS passes control to the ROM and if the BIOS has been reprogrammed to skip the ROM, control will never be passed to the ROM.
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 of either a corrupt or malicious component. The second is to not use or execute the component. This approach is ty
Arbaugh William A.
Farber David J.
Keromytis Angelos D.
Smith Jonathan M.
Butler Dennis M.
Sterne Kessler Goldstein & Fox PLLC
Trustees of the University of Pennsylvania
LandOfFree
Secure and reliable bootstrap architecture does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Secure and reliable bootstrap architecture, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Secure and reliable bootstrap architecture will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2588070