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 |