1 |
> From: Michael Mol <mikemol@×××××.com> |
2 |
|
3 |
>On Mon, Jun 4, 2012 at 9:33 AM, BRM <bm_witness@×××××.com> wrote: |
4 |
>>> From: Michael Mol <mikemol@×××××.com> |
5 |
>> |
6 |
>>>On Sat, Jun 2, 2012 at 10:04 PM, BRM <bm_witness@×××××.com> wrote: |
7 |
>>>>> From: Michael Mol <mikemol@×××××.com> |
8 |
>>>[snip] |
9 |
>>>> In theory that's how key signing systems are suppose to work. |
10 |
>>>> In practice, they rarely implement the blacklists as they are (i) hard to maintain, |
11 |
>>>> and (ii) hard to distribute in an effective manner. |
12 |
>>> |
13 |
>>>Indeed. While Firefox, Chromium, et al check certificate revocation |
14 |
>>>lists, Microsoft doesn't; they distribute them as part of Windows |
15 |
>>>Update. |
16 |
>> |
17 |
>> Which can then be intercepted by IT in any IT department that stages Windows Update using their own servers. |
18 |
> |
19 |
>Only if the workstation is so configured. (i.e. it's joined to the |
20 |
>domain, or has otherwise had configuration placed on it.) It's not |
21 |
>just a matter of setting up a caching proxy server and modifying the |
22 |
>files before they're delivered. |
23 |
> |
24 |
>And if you think that's a risk, then consider that your local domain |
25 |
>administrator has the ability to push out the organization CA into |
26 |
>your system cert store as a trusted CA, and can then go on to create |
27 |
>global certs your browser won't complain about. |
28 |
> |
29 |
>If you don't own the network, don't expect to be able to do things on |
30 |
>it that the network administrator doesn't want you to do. At the same |
31 |
>time, he can't force (much...see DHCP) configuration onto your machine |
32 |
>without your being aware, at least if you're at least somewhat |
33 |
>responsible in knowing how configuring your machine works. |
34 |
|
35 |
|
36 |
True. |
37 |
|
38 |
My point was that since Microsoft is using Windows Update to update the CRLs, that the corporate IT departments could decide not to allow the update to go through. |
39 |
Of course, it's their risk if they don't allow it through. Further, they can push out CRLs even if Microsoft doesn't send them. |
40 |
|
41 |
But that's not the concern unless you want your device free of the IT department, and that's a wholly different issue. |
42 |
And of course, they can't change the CA on a WinRT device for SecureBoot. |
43 |
|
44 |
>>>> Honestly, I don't expect SecureBoot to last very long. |
45 |
>>>> Either MS and the OEMs will be forced to always allow users to disable it, |
46 |
>>>> or they'll be simply drop it - kind of like they did with TPM requirements that were |
47 |
>>>> talked about 10 years back and never came to fruition. |
48 |
>>> |
49 |
>>>TPM is still around for organizations which can use them. And, |
50 |
>>>honestly, I've been annoyed that they haven't been widespread, nor |
51 |
>>>easy to pick up in the aftermarket. (They come with a random number |
52 |
>>>generator...just about any HRNG is going to be better than none.) |
53 |
>> |
54 |
>> |
55 |
>> Yes TPM (originally named Palladium) is still around. However its use is almost non-existent. |
56 |
> |
57 |
>No, TPM wasn't originally named Palladium. TPM was the keystore |
58 |
>hardware component of a broader system named Palladium. The TPM is |
59 |
>just a keystore and a crypto accelerator, both of which are two things |
60 |
>valuable to _everybody_. The massive backlash against Palladium is at |
61 |
>least part of why even a generally useful hardware component like the |
62 |
>TPM never got distributed. Imagine if the floating-point coprocessor |
63 |
>was ditched in x86 because people thought it was a conspiracy to |
64 |
>induce difficult-to-resolve math precision errors from careless use of |
65 |
>floating point arithmetic. |
66 |
> |
67 |
>The part you're worried about is the curtained memory and hardware |
68 |
>lockout, which it sounds like Intel is distributing with vPro. |
69 |
|
70 |
|
71 |
TPM, SecureBoot, and Palladium are both beasts which need to be removed. |
72 |
|
73 |
|
74 |
>> When it was proposed, it was to include "SecureBoot" and enable secure Internet transactions, etc. |
75 |
>> None of that came to fruition. Now, after over a decade of ignoring it, they are trying it one step at a time, first with SecureBoot. |
76 |
>>>I see something like SecureBoot as being useful in corporate and |
77 |
>>>military security contexts. I don't see it lasting in SOHO |
78 |
>>>environments. |
79 |
>> Certain environments as you say may find it useful; but then those environments already have very stringent controls |
80 |
>> over the computers in those environments, often to the inability of people to do their job. |
81 |
> |
82 |
>The nature of those controls stems at least in part from the ability |
83 |
>to use other means to maintain an overall security policy. With more |
84 |
>tools comes the ability to be more flexible, allowing people to do |
85 |
>more convenient convenient things (such as insert a flash drive or CD |
86 |
>into a computer) at lower risk (it'll be more difficult to |
87 |
>accidentally boot from that flash drive or CD). |
88 |
|
89 |
|
90 |
How often do people accidentally boot from the wrong device? |
91 |
It's probably more of an issue for USB devices than floppy/CDs any more, but still. |
92 |
|
93 |
And why destroy people's ability to boot from USB/CD/Floppy? |
94 |
Let's not forget this makes it harder for Gentoo (and numerous other distros and OSes) to go on devices. |
95 |
|
96 |
The user should own and control the device, not a corporate entity (except where said corporate entity purchased the device in the first place). |
97 |
|
98 |
|
99 |
>It's for similar reasons the Linux kernel has support for fine-grained |
100 |
>access controls; you can grant additional privileges where needed, and |
101 |
>reduce the base set of privileges required. |
102 |
|
103 |
|
104 |
Linux has fine grain control because that's what's required for Common Criteria, and what the NSA implemented for SELinux. |
105 |
|
106 |
>And here's a use case that might seem worthwhile...Say you've got |
107 |
>hardware with SecureBoot. Now, you don't run Windows, so you don't |
108 |
>care about the UEFI BIOS having Microsoft's key. Instead, you're a |
109 |
>Linux guy, and you're very privacy conscious; perhaps you're a |
110 |
>security consultant or contractor. Or perhaps you're worried about |
111 |
>corporate espionage. Or perhaps you're simply afraid of governments. |
112 |
> |
113 |
>You can flush Microsoft's key from BIOS and insert your own. Sign your |
114 |
>bootloader, kernel and initramfs. Set up your / filesystem to be fully |
115 |
>encrypted. And configure things such that if BIOS isn't operating in |
116 |
>SecureBoot mode with your key, it won't even mount and decrypt your / |
117 |
>filesystem. |
118 |
> |
119 |
>You've just denied access to any existing forensic tool which would |
120 |
>either examine your hard disk or operate as a rootkit. The only thing |
121 |
>that's going to get your data is a live inspection of your RAM |
122 |
>(tricky! but doable.) or a rubber hose. |
123 |
|
124 |
|
125 |
Or you just pull the hard drive and do the decryption elsewhere. |
126 |
All it does is lock you out of your own system, and hand the keys to someone else. |
127 |
|
128 |
And, on WinRT approved devices you will not be allowed to change the Keys for SecureBoot period (not even corporate IT). |
129 |
On x86-based Windows devices you'll be allowed to, but it's only a matter of time before Microsoft will try to pull the plug there too. |
130 |
|
131 |
|
132 |
>>>>> What kind of signature is the bootloader checking, anyway? |
133 |
>>>> Regardless of the check, it'll never be sufficient. |
134 |
>>>Sure; ultimately, all DRM solutions get cracked. |
135 |
>> |
136 |
>> TPM and SecureBoot will by design fail. |
137 |
> |
138 |
>Please be aware of the distinction between TPM from Palladium. In |
139 |
>fact, you should probably be aware of the distinction between tools |
140 |
>and policies, too. |
141 |
|
142 |
|
143 |
That won't resolve the issue. |
144 |
|
145 |
|
146 |
>> We'll see if SecureBoot actually even makes it to market; if it does, expect some Class Action lawsuits to occur. |
147 |
> |
148 |
>We'll see. Don't forget _you can turn the thing off_. I expect the |
149 |
>lawsuits will come around when the ability to turn the thing off or |
150 |
>reconfigure it is removed. |
151 |
|
152 |
|
153 |
As noted, WinRT devices will not allow you to change the keys; they also won't allow you to turn off Secure Boot. |
154 |
If MS can get SecureBoot out there and keep it enabled, then it's just a matter of time before they try to do the same thing to the rest of the platforms. |
155 |
So expect the lawsuits to happen if it even gets out to start with. |
156 |
|
157 |
|
158 |
Ben |