Clone this wiki locally
- How to enable Security with EDK II
- PDF on How to Sign UEFI Drivers & Applications V1.31.pdf
- Secure Boot Ecosystem Challenges PDF-From ToorCamp 2012, Presentation by Vincent Zimmer
- White Paper : A Tour Beyond BIOS into UEFI Secure Boot PDF
Table of Contents
The Trusted Platform Module (TPM) is a passive hardware device on the system board. UEFI TCG Measured Boot takes use of TPM device to construct the basic trusted computing environment based on S-CRTM (Static Core Root of Trust for Measurement). The implementation includes a set of TCG-compliant modules that provide the necessary functionality as described by the TCG specifications for the TPM component. These modules deeply rely on the TCG-defined specifications. Basically, they provide the capabilities to initialize and operate a TPM device and implement the TCG-defined services (performing measurement and logging data/events, physical presence, memory overwrite request, etc) for S-CRTM based attestation of the UEFI platform.
The UID framework implements EFI_USER_MANAGER_PROTOCOL, EFI_USER_CREDENTIAL_PROTOCOL and EFI_DEFERRED_IMAGE_LOAD_PROTOCOL, and supports user identity management, user access privilege management, user identification policy management, static multi-factor authentication, and publishes the current user profile in the EFI System Configuration Table after user authentication.
This secure boot mechanism allows the firmware to authenticate a UEFI image, such as an operating system loader or an option ROM. This provides the capability to ensure that the firmware drivers are loaded only in an owner-authorized fashion and provides a common means to ensure platforms security and integrity over systems running UEFI-based firmware.
Authenticated variable service is an enhancement on Variable Service in UEFI, which provides a means to restrict operation on certain sensitive storage data. If the EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS is set, both the identity of operator and integrity of data will be authenticated before write the variable into storage.
This section lists signing tools and resources for UEFI Secure Boot on Linux. It is far from an exhaustive list but hopefully will be a helpful starting point. This version was created Jan. 31, 2013 and will be updated periodically. Please send recommended changes to the firstname.lastname@example.org To join the email list goto: edk2-devel (NOTE: Do NOT send any personal information to the edk2-devel list.)
- UEFI Secure Boot support in several Linux distros,
- creating keys and certificates,
- signing images for development and production,
- And more …
|ubuntu||OVMF tips, creating keys & certificates, configuring secure boot , signing test images with sbsign, updating key databases|
|jk.ozlabs.org||creating keys & certificates, tools for signing variables and maintaining key databases|
|suse.com||shim loader description|
|en.opensuse.org||Secure Boot in OVMF & lockdown.efi|
|Testing||Images for testing|
|uefi-secure-boot||using MS UEFI CA to sign images|
- EFI_STUB Kernel - has been signed with the Microsoft* SignTool and successfully secure booted. Fixes are available in tip:x86/efi branch at:
- efilinux Loader - has been signed with the Microsoft* SignTool and successfully secure booted. These fixes have been merged into the 'next' branch prior to being merged into the 'master' branch and a planned 1.1 release:
- The .reloc section fix on x86-64 was merged into the efi-linux library’s sourceforge repository and a new version was released (3.0q).
- UDK GCC44 & GCC46 UDK Tool Chain
- UEFI applications (such as HelloWorld.efi) built with the GCC44 and GCC46 UDK tool chains have been signed with the Microsoft* SignTool and successfully secure booted.
- UDK UNIXGCC UDK Tool Chain
- UEFI applications built with the UNIXGCC tool chain are not currently secure bootable. This problem is under investigation.
This section describes support for Authenticode-signed UEFI images with multiple signatures, references sample certificates and images and describes patches to enable this support .
The Authenticode signature is in a location called the "Attribute Certificate Table" in a UEFI image. According to the UEFI and PE/COFF specifications, the Attribute Certificate Table is composed of a set of contiguous certificate entries (a list of certificates), and each certificate entry contains an independent Authenticode signature.
However, revision 2.3.1B of the UEFI Specification has no explicit description about the verification policy for the multiple certificate entries in a UEFI image, but the Authenticode specification does not preclude this case of multiple entries.
Currently, both the SignTool from MSFT and the DxeImageVerificationLib from the SecurityPkg on http://www.tianocore.org treat the Attribute Certificate Table as a single certificate. So if one re-signs a UEFI image with a new certificate, the MSFT SignTool will overwrite the old certificate entry with the new one. And the verification library assumes that there is only one certificate entry in the attribute certificate table.
Other Sign Tools are now emerging that can create UEFI images with multiple signatures.
Some sample UEFI images and their certificates can be found at: http://pjones.fedorapeople.org/multisign/
- pjones.cer - public key with a DN that basically says "pjones"
- PeterJones.cer - different public key with a DN that says "PeterJones" instead
- hello-0.efi - "Normal, unsigned HelloWorld.efi
- hello-1.efi - same binary, signed with "pjones"
- hello-2.efi - same binary, signed with "pjones" and then with "PeterJones".
Note: the 28-Jun-2012 12:41 version of both .cer files [which] were corrupt.
Verification of UEFI images with multiple signatures can be enabled with a small patch to the IsPkcsSignedDataVerifiedBySignatureList routine in SecurityPkg\Library\DxeImageVerificationLib\DxeImageVerificationLib.c.
Patches are based based on SVN r13505
Rev2 handles N certificates in an image and validates each WIN_CERTIFICATE header found in the image
Rev1 only supported 2 certificates in an image.
- Enroll pjones.cer in PK, KEK & DB,
- both hello-1.efi and hello-2.efi run.
- Enroll PeterJones.cer in PK, KEK & DB,
- now only hello-2.efi runs.