Gentoo Archives: gentoo-dev

From: Florian Philipp <lists@×××××××××××.net>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
Date: Sun, 17 Jun 2012 18:04:21
Message-Id: 4FDE1B53.3010905@binarywings.net
In Reply to: Re: [gentoo-dev] Re: UEFI secure boot and Gentoo by Sascha Cunz
1 Am 17.06.2012 19:34, schrieb Sascha Cunz:
2 > [...]
3 >
4 >> It doesn't. It's just a very long wooden fence; you just didn't find
5 >> the hole yet.
6 >
7 > Given the fact that the keys in the BIOS must somehow get there and it must
8 > also be able to update them (how to revoke or add keys else?).
9 >
10 > Unless this is completely done in hardware, there must be a software doing it.
11 > Software can - by design - be reverse engineered; in some countries even
12 > legally without any further agreement or license.
13 >
14 > So, you can sign, encrypt, obfuscate or use some other foobar-mechanism on
15 > this blob of software - at some point it must be readable from the processor,
16 > so you have to provide the mechanisms to verify signs, undo encryption etc
17 > somewhere (either in hardware or another software).
18 >
19 > Even if you somehow manage to embed all of this in the hardware stack, it
20 > would still require some kind of interface to get updated / revoked keys to
21 > operate on.
22 >
23 > It's not a matter of *if this can* be broken by someone who cares, it's a
24 > matter of *how long does it take* for someone who cares to break it.
25 >
26 > In the end, this is just another kind of "seems to be secure for a day or
27 > two". Admittedly a complex one - but there will always be a "kid in a garage"
28 > that is able to set everyone else out of business.
29 >
30 > SaCu
31 >
32
33 Okay, a few points here:
34
35 First: On an abstract level, the key innovation in Secure Boot and
36 driver signing is that it establishes a trust relationship between
37 platform owner and platform firmware (using a so called Platform Key) as
38 well as trust between operating system and platform firmware (using Key
39 Exchange Keys).
40
41 Under the assumption that the implementation is correct, nothing on the
42 operating system level can inject drivers, boot loaders or whatever else
43 into the firmware unless it is properly signed. The platform will not
44 allow anything unless it is bit-by-bit verified to come from the
45 platform owner or a trusted third party. The recommended algorithms for
46 signing and verifying code are SHA-256 and RSA-2048. Good luck breaking
47 that in "a day or two"!
48
49 Second point: Secure Boot is not designed to protect against an attacker
50 with physical access to the machine. So you can leave your soldering
51 iron and memory stick at home when you try to prove that Secure Boot can
52 be broken.
53
54 Third point: Of course Secure Boot will be broken! A mainboard maker
55 will screw up, there will be a bug in the specs or RSA will be broken.
56 And when one of these happens, it will be fixed. Plain and simple. We
57 didn't abandon SSL just because version 1 and 2 were broken. Why should
58 we abandon Secure Boot?
59
60 Regards,
61 Florian Philipp

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo Sascha Cunz <sascha-ml@×××××××××.org>