Browse Prior Art Database

Secure Method of updating Flash in a Insecure Environment

IP.com Disclosure Number: IPCOM000015133D
Original Publication Date: 2001-Aug-11
Included in the Prior Art Database: 2003-Jun-20
Document File: 2 page(s) / 67K

Publishing Venue

IBM

Abstract

Today, many customers want to Flash their systems either under an OS or with LAN based tools. With either of these methods, it is difficult for the Flash utility to determine whether a secure OS is running underneath it. This solution solves this problems. First and foremost, it is important for the BIOS to protect the root of trust for TCPA measurements. Since this is normally in the boot block, this can be easily done by permanently locking the boot block. But what about the rest of the flash? This disclosure will address that problem. The TCPA secure system needs several attributes to solve this problem. First, some secure storage needs to be available which holds key material and the hash of the first entry jumped to out of Boot block. Second, it needs a form of NVRAM which data can be passed from the post boot timeframe to the Preboot timeframe (the secure mailbox concept is disclosed by docket RPS9-2000-0030). Here is how the idea works. When the flash utility is invoked, it will write the expected hash of the first BIOS section to be executed after bootblock to the to the secure mailbox prior to starting the flash process. This hash is encrypted with a private key known only to the BIOS build process (i.e., the mailbox will contain a digital signature of the first non bootblock section of BIOS). When this is complete, the flash process will go on as usual. SECURE NVRAM H a s h o f fir s t e n tity w h ic h is jum ped to

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 54% of the total text.

Page 1 of 2

Secure Method of updating Flash in a Insecure Environment

Today, many customers want to Flash their systems either under an OS or with LAN based tools. With either of these methods, it is difficult for the Flash utility to determine whether a secure OS is running underneath it. This solution solves this problems.

First and foremost, it is important for the BIOS to protect the root of trust for TCPA measurements. Since this is normally in the boot block, this can be easily done by permanently locking the boot block. But what about the rest of the flash? This disclosure will address that problem. The TCPA secure system needs several attributes to solve this problem. First, some secure storage needs to be available which holds key material and the hash of the first entry jumped to out of Boot block. Second, it needs a form of NVRAM which data can be passed from the post boot timeframe to the Preboot timeframe (the secure mailbox concept is disclosed by docket RPS9-2000-0030). Here is how the idea works. When the flash utility is invoked, it will write the expected hash of the first BIOS section to be executed after bootblock to the to the secure mailbox prior to starting the flash process. This hash is encrypted with a private key known only to the BIOS build process (i.e., the mailbox will contain a digital signature of the first non bootblock section of BIOS). When this is complete, the flash process will go on as usual.

SECURE NVRAM

- H a s h o f fir s t e n tity...