Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

Method for capturing libraries of custom secure boot capabilities

IP.com Disclosure Number: IPCOM000235943D
Publication Date: 2014-Mar-31
Document File: 5 page(s) / 51K

Publishing Venue

The IP.com Prior Art Database


Disclosed are a method and system that enable personalities of secure boot modes to be loaded and used without removal. This library of modes improves the user’s ability to add new modes as well as the ability to return to a defined secure boot mode without a deletion and a reinstall.

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

Page 01 of 5

Method for capturing libraries of custom secure boot capabilities

Secure boot prevents unauthorized operating systems and software from loading during the startup process.

When Secure Boot is activated using Unified Extensible Firmware Interface (UEFI) setup menus, it checks each piece of software, including the UEFI drivers (Option Read Only Memories (ROMs)) and the operating system, against databases of known good signatures. If each piece of software is valid, then the firmware runs the software and the operating system. Original Equipment Manufacturers (OEMs) provide the drivers to the system developing company to include in UEFI firmware. This includes the signature database (db), revoked signatures database (dbx), and the Key Enrollment Key database (KEK). These databases are stored on the Flash* at manufacturing time.

The signature database (db) and the revoked signatures database (dbx) list the signers or image hashes of UEFI applications, operating system loaders and UEFI drivers that can be loaded on the server, and the revoked images for items that are no longer trusted and may not be loaded.

The Key Enrollment Key database (KEK) is a separate database of signing keys that can be used to update the signature database and revoked signatures database. Microsoft requires a specified key to be included in the KEK database so that in the future the software manufacturer can add new operating systems to the signature database or add known bad images to the revoked signatures database.

After these databases have been added, and after final firmware validation and testing, the system developer locks the firmware from editing, except for updates that are signed with the correct key or updates by a physically present user who is using firmware menus, and then generates a platform key (PK). The PK can be used to sign updates to the KEK or to turn off Secure Boot.

In general, there is a precedence order (most to least significant) of PK, KEK, db, and dbx. Thus, in order to update a KEK, a signature with the correct PK is needed. Additionally, in order to update a db or a dbx, a signature with the correct PK or KEK is needed.

A system development company can have a signing server that is used to sign Option ROMs and drivers from suppliers in the manner described above. Said system development company can have a UEFI that allows three modes of Secure Boot (i.e. Disable, Enabled Standard, and Enabled Custom).

For Enabled Standard, the defaults from the company's signing servers are used to boot any operating system (OS) or use any Option ROMs. If a signature does not match, then the OS or driver is not loaded. Some products also allow for a Custom Mode, which does not use the default signatures from the company. When Custom Mode is applied at UEFI setup, the user has the ability to delete the system development company's default PK, KEK, db and dbx and enroll a specifically


Page 02 of 5

associated PK, KEK, db, and dbx. By design, t...