Browse Prior Art Database

Making Legacy DOS Boot devices Secure Disclosure Number: IPCOM000015135D
Original Publication Date: 2001-Aug-11
Included in the Prior Art Database: 2003-Jun-20

Publishing Venue



Most PC vendors have developed tools that work in DOS mode. Although these tools are inexpensive and easy to use, they create a problem if used in a secure TCPA environment. For instance, a Flash Diskette today utilizes DOS to load the appropriate utilities. A company could go to all the trouble of digging up all of the various components that load when you load a DOS Flash diskette and make the TCPA hash and extend changes but this may not be feasible if the source code is not available. This invention allows existing DOS utilities that boot off of a DISKETTE CD ROM to work with very little change. A method needs to be developed which will allow existing utilities to run. This solution addresses this problem for data read off of a media which supports the INT 13h handler. Refer to figure 1. This is an existing flow. When the system gets to the end of the boot process, the Master Boot Record (MBR) is read. The MBR gives the BIOS enough data to determine that a bootable media is available and then the BIOS jumps to the MBR. The MBR loads the OS loader which then takes control of the system. At the completion of the OS loader, the appropriate utility is loaded which then starts the Flash process. In this process, there are many area’s in which untrusted code could be loaded (MBR,Loader,….). These are attack points in which an attacker could modify the BIOS. Figure 1 Our solution attempts to solve this problem. Refer to Figure 2. At the completion of POST, the BIOS will go out to a media and determine if the media is bootable. The MBR has four boot partitions. One partition will point to the OS loader and be marked as bootable. A second partition could be pointed to which would contains a file of a specific length. The BIOS would go read the data in the second partition and look for a particular signature. If found, the BIOS knows that the user is attempting to boot to a media that contains a flashable BIOS. Within the record(s) that the special partition resides, an encrypted block of data can be analyzed by the SMI handler. The SMI handler will take this data, use a BIOS public key to decrypt, and analyze whether the data is valid. If valid, the SMI loads the data into SMI memory and turns on a special mode in the BIOS. This mode is used to hash and extend all calls to the INT 13h. The BIOS would then go back and read the MBR (so it gets hashed), and start the loading process. The SMI handler will be called each time the INT 13h handler is called so that all data loaded into memory will be recorded in the SMI handler (which is secure storage). When the actual MFG approved utility loads, it can communicate with the SMI handler that it has loaded and to verify the current hash against the expected hash(which was in the encrypted data kept in the second partition. If it's hash comparison passes, the SMI handler can allow the Flash to be updated. If it fails, an unapproved utility or loader is being run and the system will not allow