| 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 |
Archives