On Mon, Jun 4, 2012 at 5:13 PM, BRM <bm_witn...@yahoo.com> wrote: >> 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] >>>>> 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. I'm still confused by your malice toward the TPM. What part of 'crypto coprocessor' or 'crypto accelerator' doesn't get you thinking about faster SSH and SSL connection setup and data transfers? [snip] >>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? You know how many Linux install flash drives are floating around? What about OS install CDs? A curious artifact of both is that they're left in systems so _frequently_, they're often designed to proceed back to a disk-based boot after a timeout. > It's probably more of an issue for USB devices than floppy/CDs any more, but > still. The Gentoo 12.1 LiveDVD also has the timeout-and-boot. And it's quite common for people to leave flash drives plugged into systems over boot cycles; it's like a portable 'My Documents' folder. > > And why destroy people's ability to boot from USB/CD/Floppy? You're not; you can turn off SecureBoot in BIOS, and then boot from USB or CD as normal. Though why you'd boot from a floppy on a system that has SecureBoot, I have no idea. (It's questionable whether systems shipping SecureBoot will even have floppy controllers...) Being able to disable SecureBoot is going to be _critical_ for application of diagnostics, forensics and system repair. And if it comes down to it, you'll likely be able to get those tools signed, too. > Let's not forget this makes it harder for Gentoo (and numerous other distros > and OSes) to go on devices. Nobody's forgotten that. Now let's not forget how easy it will be to turn SecureBoot off. You're likely to have a harder time getting latest-grade RAM functioning in a brand-new new system, what with timings and gang modes to contend with. > The user should own and control the device, not a corporate entity (except > where said corporate entity purchased the device in the first place). Fully concur...and I'm moderately impressed; most people I've seen argue things like this can't make that distinction. >>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. SELinux required it because it was necessary. Linux included SELinux because it's legitimately useful. Anything legitimately useful for someone else to keep you out of their stuff is legitimately useful for you to keep them out of yours. >>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. Decryption is not trivial. > 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 I properly understand what's discussed elsewhere in the thread, the capability to turn off SecureBoot will be required for Windows 8 certification on x86 hardware. So, again, you _will_ be able to turn it off. Sure, that may mean you can't access the WinRT subsystem on Windows with SecureBoot turned off. But you can still boot Linux. Want to boot Windows and get WinRT? Turn SecureBoot back on and boot Windows. Yes, dual-booting is going to be a bigger pain than it already is. And, honestly, I've never really understood dual-booting; if you spend a long time in one OS, and a short time in another OS, much (most?) of the time spend in that secondary OS is going to be spent in updates. Which makes that secondary OS either very insecure for you, or a very poor, nigh pointless experience. > 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. I did some googling after your repeated mentions of WinRT. From the look of things, it's going to be hitting ARM as well as x86. ARM is going to have a rougher time of it, though. Microsoft is being more aggressive in that market...and no surprise; ARM platforms are eating Microsoft's lunch--they're where you want to be in the mobile and low-power markets. I think it unlikely Microsoft's going to succeed, though; they're late to the game, and old giants (Nokia, RIM) are collapsing. -- :wq
