next up previous
Next: Discussion and alternative Up: A Secure and Previous: Performance impact on

Related work

The first presentation of a secure boot process was done by Yee [21]. 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 expands his discussion of a secure boot in his thesis [23], 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 implementations questions 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 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 a 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.

Lampson [12] describes a secure boot model as an example for his authentication calculus. In Lampson's model, the entire boot ROM is trusted, and he does not address the verification of expansion cards/ROMs. The Birlix [11] Security Architecture proposes a model designed by Michael Gross that is similar to Lampson'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.





next up previous
Next: Discussion and alternative Up: A Secure and Previous: Performance impact on



William A Arbaugh
Mon Feb 24 15:36:58 EST 1997