Browse Prior Art Database

Secure Bootbblock recovery Disclosure Number: IPCOM000015134D
Original Publication Date: 2001-Aug-11
Included in the Prior Art Database: 2003-Jun-20

Publishing Venue



Many PC systems today include a recovery mode that can be used to boot a flash utility and update the BIOS even when the main portion of BIOS is corrupt. This function, called the bootblock, resides at the system's reset vector and is the first code to execute following a system reset or power on. This function will examine some predetermined system status (GPIO, CRC check failure, etc.) and make a determination if the system should be booted normally, or if recovery mode should be entered. When recovery mode is entered, BIOS functions are usually limited to the bare minimum necessary to boot the system and load a standalone flash utility to update the corrputed portion of BIOS. Unfortunately, the boot block recovery function does not include support for user I/O (keyboard, mouse, video, etc.). This renders the usual methods for administrator authentication unusable (since they normally rely on user input). One method of solving this problem is to include the user authentication (usually a password) in a file on the media used for the flash utility and including the necessary BIOS security functions to verify the administrator authentication in the boot block. However, this method permits the compromise of the user's authentication by allowing the administrator's secret to be simply read from a file. What is needed is a method of protecting the administrator's authentication. This disclosure describes a method of protecting the administrator's secret while providing a way of verifying the update is being requested by an authorized authority. The idea described here places a file containing an encrypted adminstrator's secret (password) on the boot media. This scenario would only be used on systems where the administrator's has selected to use a security mode known as enhanced security mode (other security modes permit the secret to be cleared when system configuration is cleared via a jumper, rendering the use of a secret in a recovery scenario ineffective). Upon detecting the system is in a recovery scenario, the flash utility would read the contents of the password file and pass the contents to BIOS along with a request to unlock the flash part to permit update. BIOS would unencrypt the passed data and verify the secret against the secret previously stored in the system NVRAM. If the secrets match, the flash part would be unlocked, permitting the recovery operation to proceed. If the comparison fails, flash updates would not be permitted. A symmetric encryption process would be used to encrypt or decrypt the secret. When the system is placed in the enhanced security mode, the utility used would generate the encryption key, place the key in the systems lockable NVRAM, and use the key to encrypt the current password and save it to a file. Since the administrator's secret is encrypted, the file can be placed on an ordinary flash update diskette (or any other media) without fear of compromising the secret. Multiple files could be placed on the same media if a naming convention is adopted that permits the identification of a file with a particular system (for example: the file name could be a derived from some system unique identifier such as machine/model type or system serial number). 1