[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why don't and RMS sign mail? - FDE Crypto

From: Florian Weimer
Subject: Re: Why don't and RMS sign mail? - FDE Crypto
Date: Mon, 04 Nov 2019 22:11:49 +0100

* Jean Louis:

> * <> [2019-11-04 14:05]:
>> Windows is required to disable the trusted computing locks in Most new
>> laptops. Other than windows there are only a few signed operating systems
>> that can be installed without disabling said locks, and they are signed by
>> microsoft.

> Dr. Stallman was warning about it:

The FSF has given out an award in support of Secure Boot-related work,
so its approach to the matter is rather ambiguous.

Secure Boot with the second Microsoft key is dead from a security
perspective.  I think all GNU/Linux vendors nowadays have deliberate
backdoors into ring 0.  This means that you can boot any operating
system, pretending that Secure Boot is enabled, while in fact it is
not.  Furthermore, downgrade protection was never implemented for
Linux, so you can boot a vulnerable kernel with a known root-to-ring-0
vulnerability, and use that to boot anything else.

There was never a real effort to get a secured boot into userspace, so
any security benefit to GNU/Linux would have been extremely slim
anyway.  Clear security goals for the Secure Boot under the Microsoft
trust root have never been specified.

There is the first Microsoft key, reserved to their own operating
systems, which does not have these problems.  As far as I know, no
GNU/Linux distributions are signed by it.  I have only encountered it
in isolation as an option in Hyper-V.  Physical x86 hardware I've seen
always came with both sets of keys installed.

In the end, what remains is the hassle that Secure Boot creates for
many users, with very little to no benefit to anyone whatsoever.

I knew this would happen and wrote extensively against Secure Boot.
That became a futile exercise when the FSF started supporting it, too.
Sadly, it is impossible nowadays to get rid of useless cruft if it has
“Secure” in its name.

To be clear here, the problem is not the Microsoft trust root.  I'm
pretty sure Microsoft would happily hand over the trust root to any
credible organization that would be willing to manage it and absorb
the risk.  A lot of organizations and governments criticize central
control over such keys, but very few are actually willing to manage a
trust root.  The same thing happened with DNSSEC.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]