Secure Boot is a protocol from the UEFI Forum. It is defined to secure the boot process by preventing the loading of UEFI drivers or OS boot loaders that are not signed with an acceptable digital signature.
SecureBootDatabaseCollection is a standard collection of databases which are named based on the functionality of keys stored in the database.
UEFI/BIOS enrolls certificates and signatures to default secure boot databases and communicates these to the Management Controller. Apart from default, user can enroll certificates/signatures under each secure boot database.
Following databases are defined by UEFI:
Platform Key (PK): The platform key establishes a trust relationship between the platform owner and the platform firmware.
Key Exchange Key (KEK): Key exchange keys establish a trust relationship between the operating system and the platform firmware. Protects the signature database from unauthorized modifications. No changes can be made to the signature database without the private portion of this key.
Authorized Signature Database (db): Maintains a secure boot allowed signature database of signatures that are authorized to run on the platform.
Forbidden Signature Database (dbx): Maintains a secure boot blacklist signature database of signatures that are not authorized to run on the platform.
Timestamp Signature Database (dbt): Maintains signatures of codes in the timestamp signatures database.
Each of these databases have default secure boot databases associated which are read-only:
PKDefault: Default Platform KeyKEKDefault: Default Key Exchange Key DatabasedbDefault: Default Authorized Signature DatabasedbxDefault: Default Forbidden Signature DatabasedbtDefault: Default Authorized Timestamp Signature DatabasedbrDefault: Default Authorized Recovery Signature Database
Defaults contain OEM's or platform defined default keys (certificates/signatures). Defaults are not used at runtime but is provided in order to allow the OS to recover the OEM's default key setup. Defaults are read-only.
User can view certificates and signatures present in UEFI Secure Boot databases. And user is allowed to add or one or more certificate/signature to non-default UEFI Secure Boot databases.
The following table contains generic information from DMTF, and published in the DSP2059 1.1.0 document. Refer to the Managing HPE BIOS resources section for the HPE iLO implementation.
| Database Name | Description | Notes |
|---|---|---|
| PK | Platform Key | Must contain a max of 1 certificate, and no signatures. When no certificate is enrolled, SecureBoot cannot be enabled. |
| KEK | Key Exchange Key Database | Can contain any number of certificates (no signatures) |
| Db | Authorized Signature Database | Can contain any number of certificates and/or signatures |
| Dbx | Forbidden Signature Database | Can contain any number of certificates and/or signatures |
| Dbt | Authorized Timestamp Signature Database | Can contain any number of certificates and/or signatures |
| Dbr | Authorized Recovery Signature Database | Can contain any number of certificates and/or signatures |
| PKDefault | Default Platform Key | Read Only. Must contain a max of 1 certificate, and no signatures |
| KEKDefault | Default Key Exchange Key Database | Read Only. Can contain any number of certificates (no signatures) |
| dbDefault | Default Authorized Signature Database | Read Only. Can contain any number of certificates and/or signatures |
| dbxDefault | Default Forbidden Signature Database | Read Only. Can contain any number of certificates and/or signatures |
| dbtDefault | Default Authorized Timestamp Signature Database | Read Only. Can contain any number of certificates and/or signatures |
| dbrDefault | Default Authorized Recovery Signature Database | Read Only. Can contain any number of certificates and/or signatures |
The Secure Boot databases contains certificates. Several other Redfish subsystems use certificates to secure their use. Refer to the following documentation sections for their management:
To access Secure Boot database resource from Redfish, perform a GET of the SecureBootDatabaseCollection URI. This resource includes links to the members of the collection, default & non-default as shown in the following example.
GET /redfish/v1/Systems/{item}/SecureBoot/SecureBootDatabases/Individual databases can be accessed using GET of their respective URIs. A GET on /redfish/v1/Systems/1/SecureBoot/SecureBootDatabases/{@SecureBootDatabaseId} lists the certificates and signatures present under the respective database as shown in the next example:
GET /redfish/v1/Systems/1/SecureBoot/SecureBootDatabases/dbDefault/Individual certificates and signatures can be accessed by performing GET respectively of /redfish/v1/Systems/1/SecureBoot/SecureBootDatabases/{@SecureBootDatabaseId}/Certificates/{@CertificateId} and /redfish/v1/Systems/1/SecureBoot/SecureBootDatabases/{@SecureBootDatabaseId}/Signatures/{@SignatureId}.
To ENROLL a certificate in a non-default database, perform POST onto the certificate collection URI: /redfish/v1/Systems/1/SecureBoot/SecureBootDatabases/{@SecureBootDatabaseId}/Certificates/
The following example enrolls a certificate in the Authorized signature database (db) of an iLO 6 based server.
Refer to this TIP to convert a CRLF terminated file into a string.
POST /redfish/v1/Systems/1/SecureBoot/SecureBootDatabases/{@SecureBootDatabaseId}/Certificates/To REMOVE a certificate/signature in the non-default database, perform DELETE on the particular member from Certificate/Signature collection URI – /redfish/v1/Systems/1/SecureBoot/SecureBootDatabases/{@SecureBootDatabaseId}/Certificates/{@CertificateId} Or /redfish/v1/Systems/1/SecureBoot/SecureBootDatabases/{@SecureBootDatabaseId}/Signatures/{@SignatureId}