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