The Achilles Heel Of Secure Boot: Certificate Revocation

Some years ago, there was a report about a compromised boot image from
Kaspersky labs; Microsoft initially issued a revocation of its Secure
Boot Certificate, but then had to withdraw that because it caused so
many problems for Windows users who couldn’t (or just wouldn’t)
upgrade/replace the affected versions of Kaspersky products
<https://arstechnica.com/information-technology/2020/07/new-flaw-neuters-secure-boot-but-theres-no-reason-to-panic-heres-why/>.

Now it turns out Microsoft has been negligent in revoking other
certificates for ancient, compromised, obsolete bootloader “shims”
<https://arstechnica.com/security/2026/07/microsoft-secure-boot-has-been-broken-for-most-of-its-existence/>
-- even when the repercussions of doing so would be minor, there still
didn’t seem to be the will to promptly enforce the rules that the
company itself created.

Certificate revocation in the event of a security compromise is also a
measure used in another context: with TLS/SSL certificates for
securely accessing websites. In this situation, it has long been known
to be a troublesome and unreliable mechanism. And so something called
“OCSP” was invented as a kind of workaround, only to fall victim to
its own problems.

Which is why, in the TLS/SSL world, the general consensus is that the
only reliable solution nowadays is to drastically shorten the validity
interval of the certificates -- some are suggesting they should be
valid for no longer than a week -- so the problem is (mostly) solved
simply by reducing the opportunity for malicious parties to make use
of compromised certificates.

This solution doesn’t seem practical for Secure Boot keys, which have
to be stored in UEFI flash RAM on every PC ... or could something like
it be made to work?

But then again, is this just another item to add to the pile of
evidence that Secure Boot might be more trouble than it’s worth? From
the recent article:

    The prospect that attackers have had the means to bypass Secure
    Boot for more than a decade through what amounts to
    hack-by-numbers scripts isn’t much of an endorsement of the
    mechanism proposed by Microsoft in partnership with hardware
    makers. As mentioned earlier, a key contributor to this debacle is
    its complexity.

    “This is a solid rebuke of the entire secure boot model,” HD
    Moore, a firmware security expert, CEO and founder of runZero, and
    a long-time critic of Secure Boot, said in an interview. His
    complaints include Microsoft being the de facto root of trust for
    the entire UEFI platform, the inability of the protection to scale
    sufficiently, and the ability for components to boot even after
    top-level certificates expire.