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