1 |
On Sunday, 17. June 2012 20:00:51 Florian Philipp wrote: |
2 |
> Am 17.06.2012 19:34, schrieb Sascha Cunz: |
3 |
> > [...] |
4 |
> > |
5 |
> >> It doesn't. It's just a very long wooden fence; you just didn't find |
6 |
> >> the hole yet. |
7 |
> > |
8 |
> > Given the fact that the keys in the BIOS must somehow get there and it |
9 |
> > must |
10 |
> > also be able to update them (how to revoke or add keys else?). |
11 |
> > |
12 |
> > Unless this is completely done in hardware, there must be a software doing |
13 |
> > it. Software can - by design - be reverse engineered; in some countries |
14 |
> > even legally without any further agreement or license. |
15 |
> > |
16 |
> > So, you can sign, encrypt, obfuscate or use some other foobar-mechanism on |
17 |
> > this blob of software - at some point it must be readable from the |
18 |
> > processor, so you have to provide the mechanisms to verify signs, undo |
19 |
> > encryption etc somewhere (either in hardware or another software). |
20 |
> > |
21 |
> > Even if you somehow manage to embed all of this in the hardware stack, it |
22 |
> > would still require some kind of interface to get updated / revoked keys |
23 |
> > to |
24 |
> > operate on. |
25 |
> > |
26 |
> > It's not a matter of *if this can* be broken by someone who cares, it's a |
27 |
> > matter of *how long does it take* for someone who cares to break it. |
28 |
> > |
29 |
> > In the end, this is just another kind of "seems to be secure for a day or |
30 |
> > two". Admittedly a complex one - but there will always be a "kid in a |
31 |
> > garage" that is able to set everyone else out of business. |
32 |
> > |
33 |
> > SaCu |
34 |
> |
35 |
> Okay, a few points here: |
36 |
> |
37 |
> First: On an abstract level, the key innovation in Secure Boot and |
38 |
> driver signing is that it establishes a trust relationship between |
39 |
> platform owner and platform firmware (using a so called Platform Key) as |
40 |
> well as trust between operating system and platform firmware (using Key |
41 |
> Exchange Keys). |
42 |
|
43 |
You've said yourself, that "some removable media might not require signatures" |
44 |
in order to boot. Well, if that is the case, then isn't this defeating the |
45 |
whole point of Secure Boot at that stage? |
46 |
|
47 |
> Under the assumption that the implementation is correct, nothing on the |
48 |
> operating system level can inject drivers, boot loaders or whatever else |
49 |
> into the firmware unless it is properly signed. The platform will not |
50 |
> allow anything unless it is bit-by-bit verified to come from the |
51 |
> platform owner or a trusted third party. The recommended algorithms for |
52 |
> signing and verifying code are SHA-256 and RSA-2048. Good luck breaking |
53 |
> that in "a day or two"! |
54 |
> |
55 |
> Second point: Secure Boot is not designed to protect against an attacker |
56 |
> with physical access to the machine. So you can leave your soldering |
57 |
> iron and memory stick at home when you try to prove that Secure Boot can |
58 |
> be broken. |
59 |
|
60 |
I was under the impression that it should at least help in that scenario. |
61 |
OTOH, if it takes a compromised system or physical access to the machine in |
62 |
order to manipulate the boot sequence, then I no longer understand what the |
63 |
boot sequence in such a system must be protected against (Assuming that the |
64 |
primary reason for boot sequence manipulation is to later on compromise the |
65 |
system). |
66 |
|
67 |
> Third point: Of course Secure Boot will be broken! A mainboard maker |
68 |
> will screw up, there will be a bug in the specs or RSA will be broken. |
69 |
> And when one of these happens, it will be fixed. Plain and simple. We |
70 |
> didn't abandon SSL just because version 1 and 2 were broken. Why should |
71 |
> we abandon Secure Boot? |
72 |
|
73 |
"Plain and simple" here probably means, that all (at least many) sold system |
74 |
up to that date are downgraded to "unsecure". Not every user out there is |
75 |
reachable by any channel telling that it is just now a hard requirement to |
76 |
update the system - and even getting the message to the user won't cause 100% |
77 |
of the reached users to go that upgrade path. |
78 |
|
79 |
SaCu |