> From: Michael Mol <mike...@gmail.com> >On Mon, Jun 4, 2012 at 9:33 AM, BRM <bm_witn...@yahoo.com> wrote: >>> From: Michael Mol <mike...@gmail.com> >> >>>On Sat, Jun 2, 2012 at 10:04 PM, BRM <bm_witn...@yahoo.com> wrote: >>>>> From: Michael Mol <mike...@gmail.com> >>>[snip] >>>> In theory that's how key signing systems are suppose to work. >>>> In practice, they rarely implement the blacklists as they are (i) hard to >>>> maintain, >>>> and (ii) hard to distribute in an effective manner. >>> >>>Indeed. While Firefox, Chromium, et al check certificate revocation >>>lists, Microsoft doesn't; they distribute them as part of Windows >>>Update. >> >> Which can then be intercepted by IT in any IT department that stages Windows >> Update using their own servers. > >Only if the workstation is so configured. (i.e. it's joined to the >domain, or has otherwise had configuration placed on it.) It's not >just a matter of setting up a caching proxy server and modifying the >files before they're delivered. > >And if you think that's a risk, then consider that your local domain >administrator has the ability to push out the organization CA into >your system cert store as a trusted CA, and can then go on to create >global certs your browser won't complain about. > >If you don't own the network, don't expect to be able to do things on >it that the network administrator doesn't want you to do. At the same >time, he can't force (much...see DHCP) configuration onto your machine >without your being aware, at least if you're at least somewhat >responsible in knowing how configuring your machine works.
True. 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. 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. But that's not the concern unless you want your device free of the IT department, and that's a wholly different issue. And of course, they can't change the CA on a WinRT device for SecureBoot. >>>> Honestly, I don't expect SecureBoot to last very long. >>>> Either MS and the OEMs will be forced to always allow users to disable it, >>>> or they'll be simply drop it - kind of like they did with TPM requirements >>>> that were >>>> talked about 10 years back and never came to fruition. >>> >>>TPM is still around for organizations which can use them. And, >>>honestly, I've been annoyed that they haven't been widespread, nor >>>easy to pick up in the aftermarket. (They come with a random number >>>generator...just about any HRNG is going to be better than none.) >> >> >> Yes TPM (originally named Palladium) is still around. However its use is >> almost non-existent. > >No, TPM wasn't originally named Palladium. TPM was the keystore >hardware component of a broader system named Palladium. The TPM is >just a keystore and a crypto accelerator, both of which are two things >valuable to _everybody_. The massive backlash against Palladium is at >least part of why even a generally useful hardware component like the >TPM never got distributed. Imagine if the floating-point coprocessor >was ditched in x86 because people thought it was a conspiracy to >induce difficult-to-resolve math precision errors from careless use of >floating point arithmetic. > >The part you're worried about is the curtained memory and hardware >lockout, which it sounds like Intel is distributing with vPro. TPM, SecureBoot, and Palladium are both beasts which need to be removed. >> When it was proposed, it was to include "SecureBoot" and enable secure >> Internet transactions, etc. >> 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. >>>I see something like SecureBoot as being useful in corporate and >>>military security contexts. I don't see it lasting in SOHO >>>environments. >> Certain environments as you say may find it useful; but then those >> environments already have very stringent controls >> over the computers in those environments, often to the inability of people >> to do their job. > >The nature of those controls stems at least in part from the ability >to use other means to maintain an overall security policy. With more >tools comes the ability to be more flexible, allowing people to do >more convenient convenient things (such as insert a flash drive or CD >into a computer) at lower risk (it'll be more difficult to >accidentally boot from that flash drive or CD). How often do people accidentally boot from the wrong device? It's probably more of an issue for USB devices than floppy/CDs any more, but still. And why destroy people's ability to boot from USB/CD/Floppy? Let's not forget this makes it harder for Gentoo (and numerous other distros and OSes) to go on devices. The user should own and control the device, not a corporate entity (except where said corporate entity purchased the device in the first place). >It's for similar reasons the Linux kernel has support for fine-grained >access controls; you can grant additional privileges where needed, and >reduce the base set of privileges required. Linux has fine grain control because that's what's required for Common Criteria, and what the NSA implemented for SELinux. >And here's a use case that might seem worthwhile...Say you've got >hardware with SecureBoot. Now, you don't run Windows, so you don't >care about the UEFI BIOS having Microsoft's key. Instead, you're a >Linux guy, and you're very privacy conscious; perhaps you're a >security consultant or contractor. Or perhaps you're worried about >corporate espionage. Or perhaps you're simply afraid of governments. > >You can flush Microsoft's key from BIOS and insert your own. Sign your >bootloader, kernel and initramfs. Set up your / filesystem to be fully >encrypted. And configure things such that if BIOS isn't operating in >SecureBoot mode with your key, it won't even mount and decrypt your / >filesystem. > >You've just denied access to any existing forensic tool which would >either examine your hard disk or operate as a rootkit. The only thing >that's going to get your data is a live inspection of your RAM >(tricky! but doable.) or a rubber hose. Or you just pull the hard drive and do the decryption elsewhere. All it does is lock you out of your own system, and hand the keys to someone else. And, on WinRT approved devices you will not be allowed to change the Keys for SecureBoot period (not even corporate IT). 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. >>>>> What kind of signature is the bootloader checking, anyway? >>>> Regardless of the check, it'll never be sufficient. >>>Sure; ultimately, all DRM solutions get cracked. >> >> TPM and SecureBoot will by design fail. > >Please be aware of the distinction between TPM from Palladium. In >fact, you should probably be aware of the distinction between tools >and policies, too. That won't resolve the issue. >> We'll see if SecureBoot actually even makes it to market; if it does, expect >> some Class Action lawsuits to occur. > >We'll see. Don't forget _you can turn the thing off_. I expect the >lawsuits will come around when the ability to turn the thing off or >reconfigure it is removed. As noted, WinRT devices will not allow you to change the keys; they also won't allow you to turn off Secure Boot. 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. So expect the lawsuits to happen if it even gets out to start with. Ben
