UEFI Secure Boot: Microsoft is apparently putting signature allocation on hold until 2021

To prevent manipulated kernels and unwanted modules from starting on UEFI systems, Secure Boot controls cryptographic signatures and refuses to start if the signature is missing or blocked. The master key for signing boot loaders has always been with Microsoft. Developers who want to have an operating system bootable under Secure Boot must go through Microsoft’s certification process, which includes an examination by the so-called Shim Review Board. Ultimately, Microsoft then signs the shim bootloaders that the board has found to be sufficiently secure.

Since the “Boothole” security gap became known in July 2020, this certification process, which was often described as lengthy, has fallen behind again: months of waiting times for the release of signatures for the shim bootloader are causing displeasure among developers. So stayed about Inquiries to the Review Board that were submitted on GitHub as part of the public certification process in August 2020, partly unanswered.

For certification, it is important that the developers document that a kernel lockdown works in the started system so that no unsigned modules can be reloaded. As heise online reported about two weeks ago, the reviewers of the Shim Review Board are currently unable to assess the kernel lockdown mode for kernels other than Linux kernels.

In addition to the hurdles in assigning signatures due to a lack of time and a lack of specialist knowledge, further difficulties have now apparently been added: A conceptual weakness of the key database DBX could ensure that Microsoft no longer signs any shims at all by spring 2021.

Said conceptual weakness came to light after the Microsoft CA revoked many signatures of vulnerable shims to fix the boothole vulnerability. It affects the key database DBX in the UEFI Secure Boot. This database is located in the non-volatile memory of the firmware and, when Secure Boot is activated, checks whether the boot loader is in the list of allowed or blocked signatures.

The problem: After “Boothole” the blacklist has become too large and the revoke process no longer works if the DBX key database, which is limited to 30KB, is full. The (not even completed) cleanup work after Boothole has already used up half of the available space in the DBX with three revoked certificates and 150 invalid signature hashes.

Microsoft’s CA is currently looking for an alternative solution to save blocked signatures and has a first draft on GitHub posed. Instead of using a SHA-256 hash value for invalid signatures in the case of extensive vulnerabilities, this provides for using version numbers in order to be able to make a whole series of bootloaders unusable with a single entry. The suggestion goes further to generally reduce the number of different shims, which would also result in an accelerated review process.

It will be weeks before the proposal is clarified with all Microsoft partners. A software company that followed up with Microsoft by email (the correspondence is available online) was informed that Microsoft would no longer sign any new shims at least until spring 2021. An official statement from Microsoft on this planning is still pending; However, the email states that one is currently being worked on and that it will be published soon.

The temporary solution is to store your own Machine Owner Keys (MOKs) in the UEFI for Secure Boot. This suggestion by the Review Board is practical for the administration of your own certifiable IT, but hardly for software manufacturers who deliver systems that have to be bootable on UEFI Secure Boot without manipulating the key database.


To home page