To prevent manipulated kernels and unwanted modules from starting on UEFI systems, Secure Boot controls cryptographic signatures and refuses to start in the event of missing or blocked signatures. The master key for signing boot loaders has always been with Microsoft. Anyone who as a developer would like 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 bootloader that the board has found to be sufficiently secure.

Since the “Boothole” vulnerability became known in July

, this certification process, which has already been described as lengthy, has fallen behind again: months of waiting times for the release of signatures for the shim bootloader cause (t) developers to resent. For example, inquiries to the Review Board that were placed on GitHub as part of the public certification process in August 2020 went 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.

Regarding lack of time and lack of it Hurdles based on specialist knowledge in the assignment of signatures have now evidently been joined by further difficulties: A conceptual weakness in the key database DBX could ensure that Microsoft no longer signs any shims by spring 2021.

Signature database DBX: The boot is full Said conceptual weakness came to light after many signatures of vulnerable shims to fix the Boothole vulnerability have been “revoked” by the Microsoft CA. 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 bootloader is in the list of permitted or blocked signatures.

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

Proposed workaround: Own keys Microsoft’s CA is currently looking for an alternative Solution to save blocked signatures in a space-saving way and has put a first draft on GitHub. Instead of an SHA 256 hash value for invalid signatures in the case of extensive vulnerabilities, this provides version numbers to make a whole series of bootloaders unusable with a single entry to be able to. 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 via email (the correspondence is available online) was informed that Microsoft would not sign any new shims until at least spring 2021. An official statement from Microsoft on this planning is still pending; In the e-mail, however, it says that one is currently working on one and that it will be published soon.

As a temporary solution, it remains 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 must be bootable on UEFI Secure Boot without manipulating the key database.

(ovw)