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. >>> 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. > 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). 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. 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. >>>> 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. > 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. -- :wq
