| |||||||||||||
Fedora reexamines "trusted boot"Fedora reexamines "trusted boot"Posted Jun 30, 2011 14:14 UTC (Thu) by brendan_wright (subscriber, #7376)Parent article: Fedora reexamines "trusted boot"
I'm always suprised at the negative reactions Trusted Computing gets. It's an optional feature! If you don't like it, don't turn it on! But for those of us who have dealt with compromised systems in the past and would prefer not have to again, it's a godsend.
Linux distros rejecting it is another step down the path of Linux turning into "the *least* secure OS" when it was once considered to be one of the most secure...
(Log in to post comments)
Fedora reexamines "trusted boot" Posted Jun 30, 2011 14:33 UTC (Thu) by gmaxwell (subscriber, #30048) [Link]
I thought I was clear enough that my concern was mostly related to the default install.
If it's something someone has to go through an effort to activate it won't be imposed casually by third parties.
Though you seem to be suggesting that it's a useful system security feature. It is not. If your system is compromiseable without trusted boot it will be just as vulnerable with it.
Iff linux and much of the userspace were redesigned you _might_ be able to use it to detect rootkits, but even then its unlikely to help... Attackers already aren't rebooting your systems into new kernels for rootkit purposes: They usually use intentionally exposed features (or bugs) to add code to the kernel without rebooting. ... so TPM would attest to you that it booted your trusted kernel but it wouldn't matter.
Fedora reexamines "trusted boot" Posted Jun 30, 2011 16:46 UTC (Thu) by alonz (subscriber, #815) [Link] You're touching on the most important point here:trusted boot is not really about security anymore. Trusted boot has been proven totally ineffective as a security measure, time and time again. It only remaining business case is to enforce lock-in. But many people still believe the old hype about trusted boot as “the security technology that will rid us of those pesky rootkits”, and serve as unknowing shills for the commercial interests behind the technology. Even the name of the technology hints at its shortcomings: trusted—by whom? boot—not a trusted system, but only the boot process is trusted. (Full disclosure: I design security products, and my company even sells “trusted boot” solutions.)
Fedora reexamines "trusted boot" Posted Jul 1, 2011 14:32 UTC (Fri) by geofft (subscriber, #59789) [Link]
I'd like to know more about why you say it's ineffective as a security measure?
I'm thinking (only thinking, no real plans) about deploying it in a large academic environment, where we're able to take kernel updates all the time and in fact have auto-updates, and the local machines are also stateless so we can reinstall them at any time. Trusted boot would let us know whether or not the system was booted normally or e.g. from a CD or in single-user mode, and whether the disk had been tampered with since last time it was trusted-booted. We're fine assuming that we take updates often enough to avoid rootkits (and in fact we have no network login on these machines), and that in case we suspect something we just want to trigger a remote reinstall.
Will trusted boot and remote attestation not work here?
Note that we have no desire to prevent people from rebooting terminals into a live CD. We just want them not to mess with the hard disk when doing so, and we want to know if they _left_ it booted into a live CD.
Fedora reexamines "trusted boot" Posted Jul 1, 2011 15:01 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
There have been various flaws in Intel chipsets that allow attacks, the most entertaining being an exploit in the BIOS flasher code that would allow you to flash unsigned BIOS images and replace the sinit. I don't believe there are any <em>known</em> flaws in current systems, but http://theinvisiblethings.blogspot.com/search/label/trust... discusses some of the ones that have been found.
So I don't think there's any direct evidence that it's ineffective, merely that history suggests that anything that's never been seriously attacked and which has a track record of holes tends to have more holes that haven't been found yet...
Fedora reexamines "trusted boot" Posted Jul 3, 2011 12:04 UTC (Sun) by alonz (subscriber, #815) [Link] OK, I'll qualify my statements above a bit:Trusted Boot has been shown to be ineffective as a general security measure for open environments. If your system is managed centrally, and does not permit execution of locally-introduced code, you're likely OK. Also, if the only purpose of your trusted boot solution is access control to centrally-managed systems, your risk is at least controllable. The issue with trusted boot is that it's often presented as a “magic bullet”—e.g., claiming that trusted boot (from a local disk!) is an effective countermeasure against rootkits.
Fedora reexamines "trusted boot" Posted Jul 3, 2011 10:57 UTC (Sun) by brendan_wright (subscriber, #7376) [Link]
> Trusted boot has been proven totally ineffective as a security measure, time and time again.
So are you saying that most systems that have fully deployed trusted boot have been and/or can be made to incorrectly attest themselves as secure when they were actually booting compromised code? If so I'm interested to know how, when and why.
If not, in what way has it failed? I get the impression it's seldom fully implemented outside of DoD & Chrome OS and maybe a few others...
Fedora reexamines "trusted boot" Posted Jul 3, 2011 10:45 UTC (Sun) by brendan_wright (subscriber, #7376) [Link]
> Though you seem to be suggesting that it's a useful system security feature. It is not. If your system is compromiseable without trusted boot it will be just as vulnerable with it.
It may not prevent compromise but the idea is it can reveal it through remote attestation - see: http://lwn.net/Articles/137306/
A successful compromise might still be a denial-of-service attack, but by immediately taking the compromised system offline you can have confidence that your computers aren't really "owned" by a bunch of hackers.
> Iff linux and much of the userspace were redesigned you _might_ be able to use it to detect rootkits, but even then its unlikely to help... Attackers already aren't rebooting your systems into new kernels for rootkit purposes: They usually use intentionally exposed features (or bugs) to add code to the kernel without rebooting. ... so TPM would attest to you that it booted your trusted kernel but it wouldn't matter.
The idea is that the signing process continues after boot and no code is run without first being checked. If you can extend that to all code in the system (which I agree is a lot of work) then you can detect code changes after boot. Presumably NX bits help here too.
Fedora reexamines "trusted boot" Posted Jul 3, 2011 12:13 UTC (Sun) by alonz (subscriber, #815) [Link] I'm afraid I have to disagree with you, at least partially…
For example, you write
Likewise, The concepts of “trusted boot” looked OK on paper, in the context of early security research (which dealt with monolithic managed systems, when software distributions were small and organizations were large). But they don't fit most modern use cases.
Fedora reexamines "trusted boot" Posted Jul 4, 2011 2:31 UTC (Mon) by brendan_wright (subscriber, #7376) [Link]
> Here you are assuming that the main purpose of the system is access to some (single!) remote service, which can perform the attestation often enough to matter. But this isn't the case for most modern uses, especially when even connected devices often use cellular (= intermittent) connections.
If a firewall is setup to check the security of severs or desktops siting behind it, it can take them offline as soon as they fail a trust check. A mobile device like an Android integrates with online systems such as the update system that could in theory perform such checks for you (alerting your by email perhaps). A lot is possible if the software can be sorted properly...
> > The idea is that the signing process continues after boot and no code is run without first being checked
> This assumes a completely closed software ecosystemwhich, again, is far from the normal case in almost all modern use-cases.
Really? Don't many distros and Anrdoid already only download correctly signed code updates by default? Linux is already much more "closed" or at least "centralized" in one sense than Windows in that most software is installed via apt-get or whatever.
It's not hard to imagine extending this framework to include the TPM, so that your system can attest it is running the code as provided by the update servers, not some code compromised in transit or after it was installed on your machine.
Fedora reexamines "trusted boot" Posted Jul 4, 2011 8:57 UTC (Mon) by etienne (subscriber, #25256) [Link]
> The idea is that the signing process continues after boot and no code is run without first being checked.
How do you check system-wide libraries? They can be loaded at different time and so different addresses on two successive boots (depending on timing issues or randomized loaded), and they are lasy loaded (http://en.wikipedia.org/wiki/Lazy_loading) so they are constantly being modified - if those memory pages are loaded in memory at all.
Fedora reexamines "trusted boot" Posted Jul 4, 2011 23:12 UTC (Mon) by brendan_wright (subscriber, #7376) [Link]
> How do you check system-wide libraries?
You check the library loading code, and then the library code that is about to be loaded & relocated - if they haven't changed then the output can't have changed (except for addresses), so if they are "secure" then so should the output be.
Fedora reexamines "trusted boot" Posted Jun 30, 2011 16:33 UTC (Thu) by cesarb (subscriber, #6266) [Link]
> I'm always suprised at the negative reactions Trusted Computing gets. It's an optional feature! If you don't like it, don't turn it on!
If "Trusted Computing" gets traction, how long before it is no longer optional?
How long before you need it enabled to watch movies on your computer?
How long before you need it enabled to visit some websites?
How long before you need it enabled to read documents people send to you?
How long before you need it enabled to connect to the Internet at all?
Finally, how long before you no longer have a choice, and only "trusted" operating systems are allowed to run?
That is why "Trusted Computing" causes strong negative reactions. The potential for its abuse is tremendous.
Fedora reexamines "trusted boot" Posted Jun 30, 2011 23:32 UTC (Thu) by smoogen (subscriber, #97) [Link]
I would say about 10 years from now.
Fedora reexamines "trusted boot" Posted Jul 3, 2011 11:14 UTC (Sun) by brendan_wright (subscriber, #7376) [Link]
> If "Trusted Computing" gets traction, how long before it is no longer optional? How long before you need it enabled to watch movies on your computer?
It can attest to changes in the code run on the device, potentially preventing "secret" modification to that code.
But devices with practically unmodifiable boot code (at least for the average Joe) have been sold for decades (and I still had a lot of fun with our C64). And it didn't mean that customizable & modifiable systems became a thing of the past. There will no doubt always be a market for them, so someone will always make them.
But what about the potential for trusted computing to reduce the amount of loss of private data that goes on? Where's the knee-jerk reaction from the masses demanding that organisations that store our private data can remotely attest to their system's security?
How many innocent Grandmas are really happy about the fact that their PC is actually controlled by a Russian crime syndicate and that all their "personal" data actually isn't?
Like most technology it can be used for both "good" and (for those that expect to be able to modify their systems without telling others) "evil" (in that it can prevent that).
Generally with such technology, although their may be some hiccups along the way, common sense generally prevails in the end. I like Google's use of "optional" trusted computing on Chrome OS - to me the it's the best of both worlds.
Fedora reexamines "trusted boot" Posted Jul 3, 2011 18:37 UTC (Sun) by nix (subscriber, #2304) [Link]
The C64 was still fun despite its ROMs because you could tell them to get entirely out of the way, and they did. Modern OSes don't do that sort of thing.
Fedora reexamines "trusted boot" Posted Jun 30, 2011 23:15 UTC (Thu) by paravoid (subscriber, #32869) [Link]
Have a look at Google's Chrome OS laptop that employs trusted boot.
Fedora reexamines "trusted boot" Posted Jul 1, 2011 9:09 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
Well, knee-jerk reactions to TPM are just embarrassing.
First, it's already very much possible to lock down the boot sequence. Just look at all these Motorolla phones with locked bootloaders. It's even possible to do it on x86-based CPUs.
Second, TPM does provide security benefits. For example, I can use it to store keys for full-disk encryption and keys will be released only if boot loader is secure. Argument that viruses are going to use exploitable bugs anyway can just as well be used against EVERYTHING, including Unix access rights and SELinux/AppArmor.
Third, bootloader attacks are very much real. There are worms out there that actively use bootkits.
Fourth, there are good uses even for remote attestation.
Fedora reexamines "trusted boot" Posted Jul 1, 2011 9:40 UTC (Fri) by nix (subscriber, #2304) [Link] For example, I can use it to store keys for full-disk encryption and keys will be released only if boot loader is secure.Yeah, that's great. Now attackers can't pull the disks and put them in something else. Of course, this is really very unlikely. Much more likely is that the machine will eventually fail (as they always do) and then you can't put the disks in something else, and you'll be cursing that you ever went near the TPM in the first place.
Fedora reexamines "trusted boot" Posted Jul 1, 2011 9:44 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
Again, a knee-jerk reaction.
Since it's _me_ who control the disk encryption keys, I can just print them out (put on a thumb drive, etc) and store in my safe deposit box for this occasion.
No-one says that TPM should hold the only copy of encryption keys.
Fedora reexamines "trusted boot" Posted Jul 1, 2011 13:38 UTC (Fri) by nix (subscriber, #2304) [Link]
I thought the whole point of the TPM was that it held the only copy?
I suppose you could take the keys before feeding them into the TPM and preserve those, but it's amazing how none of the use cases anyone mentions for the TPM ever describe that.
Fedora reexamines "trusted boot" Posted Jul 1, 2011 13:50 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
You're confusing two issues.
It's certainly possible to use TPM to secure user-provided keys (which is what Windows uses for its BitLocker software, btw). In this mode TPM stores your symmetric encryption keys and only releases them if your boot chain is secure.
It's also possible to use TPM to generate an RSA keypair. In this mode TPM securely stores private key of the generated keypair. It's not possible to extract generated private key, so this mode can be used for remote attestation or for secure signatures.
Fedora reexamines "trusted boot" Posted Jul 1, 2011 14:16 UTC (Fri) by nix (subscriber, #2304) [Link]
Right. So the former mode is fine -- but as far as I can see doesn't really need more hardware support than a bit of NVRAM. The latter mode, which actually requires crypto and so on, is as far as I can see evil, because it locks keys up in opaque and failure-prone hardware, thus effectively doing a delayed deletion on any data secured by it and a delayed DoS on any access granted by it (because hardware always fails in the end).
Fedora reexamines "trusted boot" Posted Jul 1, 2011 15:18 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
Uhm. Private key mode is not (generally) used to encrypt data, so no worries about data loss.
It's used to make your machine 'uncloneable' and prove it to a remote party. It can be used for DRM (so you can view content only from uncloneable authorized devices) or to make sure that if your server is stolen you can make it unusable for the thief. We actually used TPM for this exact purpose - to make servers with medical data secure against physical theft.
Fedora reexamines "trusted boot" Posted Jul 2, 2011 10:52 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
BTW, 'a bit of NVRAM' won't work to store encryption keys. Because an attacker can just boot a LiveCD/LiveUSB and read all your keys from NVRAM.
That's where the measurement part of TPM comes handy - TPM won't release keys unless your system is secure.
Fedora reexamines "trusted boot" Posted Jul 7, 2011 17:34 UTC (Thu) by farnz (guest, #17727) [Link] I've used the unknown private key mode - the point is to provide me with a way to confirm, beyond all doubt, that the accesses I'm seeing are coming from my trusted hardware, running my trusted OS. Change the OS, or change the hardware, and you need reauthorising with a new key to get on the network; similarly, you can use the hidden private key for encryption of your disk's AES key, which is also stored offline somewhere physically secure. You can thus get the key out again when the TPM fails (and recover your data), it's just hassle typing it in from your laminated printouts. In the meantime, the TPM lets you forget that there is such a key - the hardware knows what it is and ensures you always run a known-good OS. The evil in TPM is nothing to do with the technical capabilities of the chip - they're fairly innocuous, if tricky to use well; the danger is when the TPM chip is used to store a private key that the user did not ask it to generate; in this situation, the holder of the public key has a path all the way to the machine that bypasses the user's wishes. If the user generates the key and hands the "public" section to the third party, all is well - nothing stops the user lying to the third party and giving them a public key not generated by a TPM.
Fedora reexamines "trusted boot" Posted Jul 8, 2011 12:44 UTC (Fri) by nix (subscriber, #2304) [Link]
Ah, right. That makes things much clearer.
|
|||||||||||||