1 |
On Fri, Jun 15, 2012 at 7:32 AM, Walter Dnes <waltdnes@××××××××.org> wrote: |
2 |
> Question... how would "blacklisting" work on linux machines? Let's |
3 |
> say Joe Blow gets a signing key and then passes it around. I can see |
4 |
> that if you want to build an executable (*.exe) to run under Windows, |
5 |
> you'll run into problems if the monthly MS Windows Update kills that |
6 |
> specific key. |
7 |
|
8 |
I took the time to read the MS Hardware Certification guide. I |
9 |
haven't read the full UEFI spec though it is referenced to it. It |
10 |
sounds like UEFI has a provision for revocation, and that includes an |
11 |
area of flash to store revoked keys. So, if you booted the device on |
12 |
Windows, then Windows could download a list of keys MS doesn't like, |
13 |
and then since Windows is trusted by the firmware it could add those |
14 |
keys to the flash. Then on a reboot the firmware would no longer boot |
15 |
those keys in secure mode. |
16 |
|
17 |
So, the revocation is non-volatile, and doesn't require a firmware |
18 |
update. Of course, if you never run Windows on the device then it |
19 |
probably won't get the update. It wasn't 100% clear, but it sounds |
20 |
like a full factory reset of the firmware might clear these revoked |
21 |
keys out (it definitely is supposed to clear out any custom keys you |
22 |
load). |
23 |
|
24 |
After reading up it seems to me that the best bet for somebody who |
25 |
wants free as in freedom is to just run in custom mode and load their |
26 |
own keys. |
27 |
|
28 |
The MS document leaves a lot of policy questions unanswered though. |
29 |
The vendor has to trust the MS key, and has to secure their root keys. |
30 |
However, they can trust any number of keys, and nothing is said about |
31 |
those keys having to be secure. It seems like that is a loophole that |
32 |
would be rapidly closed in practice if a vendor got "out of line." |
33 |
|
34 |
For ARM users are up the creek unless they can get the vendor to |
35 |
include their keys, or get a signature from somebody whose keys are |
36 |
included. ARM lacks the ability to use custom mode, which means you |
37 |
can't load your own keys, and it can't disable secure boot. |
38 |
|
39 |
Then again, all of this is only as good as the implementation. My |
40 |
current Android phone used just about all the tricks in the spec |
41 |
(flash is locked by bootloader, no downgrading, and so on). However, |
42 |
in the case of my phone messing with the power supply can reset the |
43 |
flash controller before it resets the CPU, unlocking it and allowing a |
44 |
rooted device to flash the bootloader. However, the UEFI specs |
45 |
themselves seem secure, and you can't count on every piece of hardware |
46 |
having an exploit. |
47 |
|
48 |
I think that anybody that really cares about security should be |
49 |
running in custom mode anyway, and should just re-sign anything they |
50 |
want to run. Custom mode lets you clear every single key in the |
51 |
system from the vendor on down, and gives you the ability to ensure |
52 |
the system only boots stuff you want it to. The MS spec does require |
53 |
a full factory reset to restore the original keys, though if you're |
54 |
using secure boot and TPM you could ensure that your hard drive |
55 |
becomes unreadable if this is done (unless the TPM has some backdoor |
56 |
and your vendor is complicit in accessing it). I don't have a problem |
57 |
with secure boot, and obviously to use it any pre-loaded OS has to |
58 |
have pre-loaded keys. What I don't like is the way certain companies |
59 |
are getting privileged in the process. If a full factory reset |
60 |
unlocked the machine, letting the first CD you boot from restore that |
61 |
OS vendor's keys or whatever, then then that would be more neutral. |
62 |
The whole bit about not allowing users to load their keys on ARM is |
63 |
obviously objectionable - I'm fine with ensuring security by making |
64 |
the user go into the pre-boot firmware, but the computer owner should |
65 |
have the final say. |
66 |
|
67 |
Rich |