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. Hartig, O. Kowalski and W Kuhnhauser, 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 typically called fail secure, and creates a potential denial of service attack. The final approach is to recover and correct the inconsistency from a trusted repository before the use or execution of the component. The first two approaches are unacceptable when the systems are important network elements such as switches, intrusion detection monitors, or associated with electronic commerce, since they either make the component unavailable for service, or its results untrustworthy.
None of the approaches mentioned above address a recovery process in the event of integrity failure or the secure recovery of bootstrap components. Previous efforts to provide recovery of bootstrap components have required human interaction, typically to insert a floppy disk containing the new component or to boot from a floppy disk. There are several reasons why this recovery method is inferior to the present invention. The first is that providing physical security for the floppy disk is extremely difficult. Users can take the disks wherever they like, and do whatever they like to them. The major shortcoming, however, in only using a boot disk is that none of the firmware is verified prior to use. Thus, a user can add or replace expansion boards into the system without any security controls, potentially introducing unauthorized expansion cards. Additionally, these efforts have only focused on repairing a single component of the entire process, i.e. only repairing the boot block, or the BIOS but not both. This is in contrast to the present invention which provides automatic recovery of all of the bootstrap components including ROM chips.
Finally, there have been several efforts at incorporating authentication into DHCP as is done in the AEGIS embodiment of the recovery process of the present invention. The first effort, disclosed in the expired RFC draft Authentication for DHCP messages, by R. Droms, November 1996, 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, see D. Eastlake and C. Kaufman, Dynamic Name Service and Security, Internet RFC 2065, January 1997. 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, see Baiju V. Patel, Securing DHCP, Work in Progress, July 1997. 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 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, discussed above, 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.
USPTO Backgrounds
USPTO Backgrounds