Draft:Boot Integrity Services

Boot Integrity Services (BIS) is a software interface specification whose primary goal is to verify data, particularly operating system images, loaded over network. It was developed by Intel as part of the now-obsolete Wired for Management initiative.

While modern UEFI still provides the Boot Integrity Services Protocol, the functionality has mostly been superseded by Secure Boot.

Overview

Boot Integrity Services are generally used in conjunction with Preboot Execution Environment (PXE). In that case, it comes into play once an image (called "Network Bootstrap Program") has been discovered using DHCP and downloaded into local memory.

Assuming Boot Integrity Services are available and the authenticity test is enabled, the client requests the location of a supported credential file from the DHCP server and downloads it via Trivial File Transfer Protocol from the boot server. This credential file is a signed manifest, containing (among others) integrity data for the image as well as the signer's certificate ("Boot Object Authorization Certificate").

The image's integrity is then verified.

Use

According to WfM base sec. 5.7, implementation of Boot Integrity Services is Recommended, not Required (pf06).

BIS can be considered obsolete, as evidenced by the lack of available specifications outside of archives.

A reference server and client implementation was provided by Intel, which was based on the Common Data Security Architecture (CDSA) framework initially created by Intel and published by The Open Group. The latest release dates to 2001, and the accompanying CDSA repository contains a disclaimer that "the project will no longer be maintained by Intel."

Widely-used open source PXE client and server software, such as IPXE, OVMF and ISC DHCP, provide superficial interfaces at most (like the aforementioned UEFI protocol), but no support for actually providing verification.

Security

Boot Integrity Services provides for authenticity by means of a cryptographic signature. In theory, any algorithms supported by the platform (as reported by the GetSignatureInfo function) can be used, but only two sets of signature and hash algorithms are required by the specification:

• DSA signatures (with implied SHA-1 hash algorithm) and 1024-bit key length
• RSA signatures with MD5 hashes and 512-bit key length

These supposedly refer to CSSM_ALGID_DSA and CSSM_ALGID_MD5WithRSA from the Common Security Services Manager (CSSM) Algorithms, a part of CDSA.

SHA-1 and MD5 have both been found vulnerable to certain attacks, and the respective key sizes are below recommended secure minimums.

512-bit RSA signatures have been forged in the wild by factoring the modulus. The factoring can be done with as little as 8$ worth of cloud computing.

The CDSA repository mentioned above states that "due to the age of the code, the cryptography should not be used in any new products."

Programming Interface

Boot Integrity Services can be discovered by retrieving the corresponding structure from the System Management BIOS table. Starting with version 2.3 of the SMBIOS specification, Type 31 is reserved for a BIS Entry Point structure. If present, it contains both a Segment:offset address and a 32-bit address, referring to entry point functions for 16-bit Real mode and flat 32-bit Protected mode, respectively.

uint8_t bisEntry(uint32_t opCode, void* pParamBundle, uint32_t checkFlag);

Each entry point function takes an operation code and a pointer to a parameter structure for passing data in and out. If an integrity check is requested using the checkFlag parameter, the return value indicates its success or failure.

List of defined Operation Codes

Name	Code	Functionality
Initialize	1	Initializes the BIS service, ensures the requested version is compatible, and returns an application handle.
Free	2	Frees memory allocated by another function.
Shutdown	3	Shuts down the BIS service and invalidates the application handle.
GetBootObjectAuthorizationCertificate	4	Returns the configured certificate for boot object signatures.
VerifyBootObject	5	Verifies the integrity and authorization (if required) of a block of data given credentials.
GetBootObjectAuthorizationCheckFlag	6	Indicates if a Boot Authorization Check is required.
GetBootObjectAuthorizationUpdateToken	7	Provides a token used for changing Boot Object Authorization set parameters.
UpdateBootObjectAuthorization	8	Changes a parameter of the Boot Object Authorization set, provided a valid token is given.
VerifyObjectWithCredential	9	Verifies the integrity and authorization of a block of data given credentials and a certificate.
GetSignatureInfo	10	Provides a list of supported signature and hash algorithms along with key sizes (see below).

Initially, a boot server providing multiple signature files for an image could only differentiate these according to the algorithm identifier requested. After the release of the specification, a Review Request was drafted and approved, which replaced the 4-byte algorithm identifier used in the PXE protocol with a certificate identifier, consisting of a hash of the desired certificate. This also changed the data layout provided by the GetSignatureInfo function.