1 |
[...] |
2 |
|
3 |
> It doesn't. It's just a very long wooden fence; you just didn't find |
4 |
> the hole yet. |
5 |
|
6 |
Given the fact that the keys in the BIOS must somehow get there and it must |
7 |
also be able to update them (how to revoke or add keys else?). |
8 |
|
9 |
Unless this is completely done in hardware, there must be a software doing it. |
10 |
Software can - by design - be reverse engineered; in some countries even |
11 |
legally without any further agreement or license. |
12 |
|
13 |
So, you can sign, encrypt, obfuscate or use some other foobar-mechanism on |
14 |
this blob of software - at some point it must be readable from the processor, |
15 |
so you have to provide the mechanisms to verify signs, undo encryption etc |
16 |
somewhere (either in hardware or another software). |
17 |
|
18 |
Even if you somehow manage to embed all of this in the hardware stack, it |
19 |
would still require some kind of interface to get updated / revoked keys to |
20 |
operate on. |
21 |
|
22 |
It's not a matter of *if this can* be broken by someone who cares, it's a |
23 |
matter of *how long does it take* for someone who cares to break it. |
24 |
|
25 |
In the end, this is just another kind of "seems to be secure for a day or |
26 |
two". Admittedly a complex one - but there will always be a "kid in a garage" |
27 |
that is able to set everyone else out of business. |
28 |
|
29 |
SaCu |