The implications of UEFI "Secure Boot" for Linux users(blog.canonical.com)
blog.canonical.com
The implications of UEFI "Secure Boot" for Linux users
http://blog.canonical.com/2011/10/28/white-paper-secure-boot-impact-on-linux/
7 comments
The TPM-based measured boot isn't part of the UEFI secure boot specification. It's a separate TCG spec. Secure boot doesn't use the TPM and doesn't support remote (or even local) attestation.
Interesting. It still worries me to see it in the "Windows 8 Platform Integrity Architecture". Are you not worried about it, or just pointing out that it's not relevant to the topic at hand?
Lots of (especially cheaper) machines ship without a TPM, so it's difficult for anything to explicitly require it yet. It's something to be concerned about in future, but not an immediate issue.
Isn't it always possible to just fake that Remote Attestation request? Or I wonder, how would it be possible to implement that in a way that it is non-breakable security wise / cryptographically?
If the private key is stored on the TPM chip, if the crypto takes place on the TPM chip, and if the remote service knows your public key (or, more likely, a master key which signed your key), then you won't be able to break the scheme by intercepting the request.
Of course, even though the general scheme might be sound, there might still be a lot of possible attacks. I'm not saying it's unbreakable.
Of course, even though the general scheme might be sound, there might still be a lot of possible attacks. I'm not saying it's unbreakable.
Ah ok. But probably it also wont take long until the private key from the TPM chips gets hacked.
It's reassuring the Canonical is involved with the UEFI Forum and making sensible recommendations, it's doubtful that BIOS manufacturers would bother making a chip that won't support Linux.
It's also amusing the Microsoft is so concerned with malware operating underneath the OS when most nuisance malware on Windows simply uses the features that are readily available within Windows itself.
It's also amusing the Microsoft is so concerned with malware operating underneath the OS when most nuisance malware on Windows simply uses the features that are readily available within Windows itself.
It's also to combat piracy. For example, Windows Loader uses a pre-boot technique to fool WGA:
http://forums.mydigitallife.info/threads/24901-Windows-Loade...
http://forums.mydigitallife.info/threads/24901-Windows-Loade...
Personally I think this is the real reason behind the push for secure boot.
If users can easily disable Secure Boot, it won't prevent much piracy at all.
Users can disable SB, but then they wouldn't be able to boot Windows 8.
Isn't it a completely optional feature? Otherwise, Windows 8 would not work on any pre-Secure Boot PCs.
Without piracy, nobody (approximately) in the Third World will use Windows or, by extension, any Microsoft software. Microsoft knows this. I doubt Microsoft wants to stop piracy that badly.
I suspect that only name brand PCs will use secure boot; people in developing regions mostly buy whitebox PCs and thus can easily avoid it.
Canonical isn't concerned that windows 8 compatible motherboards won't support linux because secure boot can be disabled. They're worried that a naively implemented secure boot will add one more barrier to installing linux. Requiring a user to 'turn off security' through an unfriendly bios screen would make the first steps into linux more hostile.
Exactly. Canonical has gone out of their way to make sure that you never have to muck around in a terminal or BIOS to install Ubuntu, with their Windows installers and all that.
If you run their installer and the first step is "reboot, press F12 (or F2, or DEL, or who knows what else) to enter the BIOS and turn off this security setting - that you have to find on your own - then reboot and run the installer again" instead of "click the Install button" that's a big step backwards. Not to mention the fear some users will have about turning of security, wondering if they're being had.
If you run their installer and the first step is "reboot, press F12 (or F2, or DEL, or who knows what else) to enter the BIOS and turn off this security setting - that you have to find on your own - then reboot and run the installer again" instead of "click the Install button" that's a big step backwards. Not to mention the fear some users will have about turning of security, wondering if they're being had.
The BIOS vendors will surely support linux as a checklist item. But they don't sell to consumers. They sell to PC manufacturers. Sony and Dell and HP's laptop divisions don't give a hoot about linux. If they get a directive from MS to turn on UEFI secure boot with MS's key, that's exactly what they'll do. What they're not going to do is write a user-supplied key UI in the BIOS allowing the user to install their own keys. Even if the BIOS vendor provides one, they won't test it. Or might even disable it to "reduce support costs".
Maybe microsoft is focusing on tomorrow's threat instead of todays? All too often people give MS too little credit. There are some very smart people at Microsoft even though they do not exclusively use hw/sw from apple...
Microsoft's concern is recent rootkit malware that loads before Windows even boots. Thus it can make itself completely indetectable from Windows and any anti-virus software that is loaded later on in the booting process. The malware can even run a hypervisor of sorts if it wanted to and no one will be any wiser that there's malware running.
While that's an understandable concern, I think parent was wondering whether Microsoft should be more concerned with why their system allowed the rootkit to install itself in the first place.
Rootkit doesn't "install itself" - user installs it by running something shady and entering their own password or clicking Yes in UAC prompt.
If the software is executed by the boot loader (UEFI), before Microsoft's windows boots, that is not by any fault of windows.
"If the software is executed by the boot loader (UEFI), before Microsoft's windows boots, that is not by any fault of windows."
That's what it does after it gets installed. It got installed by attacking Windows itself.
That's what it does after it gets installed. It got installed by attacking Windows itself.
> It got installed by attacking Windows itself.
The same attack is technically possible in OS X and Linux but not in iOS or WP7. Go figure.
The same attack is technically possible in OS X and Linux but not in iOS or WP7. Go figure.
No reason they can't do both, it increases security.
Security is all about layers. You fight malware where you can. You should never depend on any one defense, however strong it is.
>I think parent was wondering whether Microsoft should be more concerned with why their system allowed the rootkit to install itself in the first place
Short of iOS style lockdown, how do they do that? Even OS X and Linux can be rootkitted.
>I think parent was wondering whether Microsoft should be more concerned with why their system allowed the rootkit to install itself in the first place
Short of iOS style lockdown, how do they do that? Even OS X and Linux can be rootkitted.
>Microsoft's concern is recent rootkit malware that loads before Windows even boots.
Nothing recent about it; boot sector viruses have been around way longer than Windows. I remember getting one on my 386DX from a floppy I'd used to grab a shareware version of Commander Keen from our local public library. Pain in the ass to clean up.
Nothing recent about it; boot sector viruses have been around way longer than Windows. I remember getting one on my 386DX from a floppy I'd used to grab a shareware version of Commander Keen from our local public library. Pain in the ass to clean up.
I remember writing one on my Atari ST.
Boot viruses were to major form of viruses back then, there was a fun one that reversed your mouse's y-axis after a while. There weren't many destructive ones though.
Boot viruses were to major form of viruses back then, there was a fun one that reversed your mouse's y-axis after a while. There weren't many destructive ones though.
Doesn't this happen also with virtualized hardware?
The real question is who "approves" what software runs on _your_ hardware? No software producer should have a say on that. It should be the decision of the hardware owner.
If you read the recent thread about RMS you will see a large market exists of consumers who don't want the power to make decisions. They don't even want that option to be available. Quotes like:
- Why would I care? I don't know anything about what's under the hood and I don't want to.
- Apple puts DRM on for the user's safety.
- The days when every software users was if not programmer then at least IT guy in some sense are long gone. That model no longer fits the world.
http://news.ycombinator.com/item?id=3163920
- Why would I care? I don't know anything about what's under the hood and I don't want to.
- Apple puts DRM on for the user's safety.
- The days when every software users was if not programmer then at least IT guy in some sense are long gone. That model no longer fits the world.
http://news.ycombinator.com/item?id=3163920
If there had been that large market back in the early 80's I suspect we would have never seen that massively successful open IBM PC-compatible platform and ecosystem.
There is also another side of the story: you buy a piece of hardware and run your software on it and then the hw producer pushes firmware updates and turns your dear hw into an expensive brick.
Take the Sony Playstation or their rootkits for example...
Take the Sony Playstation or their rootkits for example...
While I agree on that systems should have a mechanism for users to enter "Setup Mode", I don't understand why the recommendations ask systems to ship in that mode. It would only affect the first boot of the system, and I seriously doubt that for anyone that plans installing Linux on first boot visiting UEFI configuration would be a significant barrier.
It would be interesting to know how much influence Microsoft seeks to impose on these new BIOS implementations with their hardware partners and/or how willing the OEMs will be to bargain it away for more favorable licensing terms and hence, profits.
We can already see how willing handset makers are to pay them for Android related cross-licensing. That's extending into the realm of ChromeOS now too.
I hope the days of installing an alternate OS on garden variety hardware are not numbered, because I suspect the economic leverage Microsoft has vs. the economic incentive for OEMs to ship open hardware isn't enough. Hopefully, I'm totally wrong.
We can already see how willing handset makers are to pay them for Android related cross-licensing. That's extending into the realm of ChromeOS now too.
I hope the days of installing an alternate OS on garden variety hardware are not numbered, because I suspect the economic leverage Microsoft has vs. the economic incentive for OEMs to ship open hardware isn't enough. Hopefully, I'm totally wrong.
Started a petition on AskForIt.com:
http://www.askforit.com/3993/all-computer-manufacturers-that...
http://www.askforit.com/3993/all-computer-manufacturers-that...
In related news, I'd kill for an open design workstation with a powerful GPU (~iPad 2) + iPad 2-class but 64-bit ARM chip that I could run Linux and Chrome on.
Or even an open spec x64 motherboard with EFI that I can slam an x64 chip into.
There have been a lot of attempts in the past, but has anyone gotten anywhere?
Or even an open spec x64 motherboard with EFI that I can slam an x64 chip into.
There have been a lot of attempts in the past, but has anyone gotten anywhere?
It's pretty hard to make that kind of hw yourself but it's not impossible.
Based on some news here, it looks there are 10-20 years lag between the state of the art and what you can build on your own.
And there are a lot of Asian companies that don't give a shit on what Microsoft wants.
Building something vaguely iPad-class is not all that hard, as long as you are OK with it being open source at the board level rather than all the way down to the silicon level. Check out, for example, the TI BeagleBoard. That's more like a 1-2 year lag, not 10-20.
Open source people don't care much for EFI but Coreboot can run on some recent AMD motherboards.
[citation needed]
I'm an open source person and I care for EFI :)
It looks like some Free Software people (along with the coreboot) guy don't care for EFI, due to IP issues.
However, Free Software hardware (and peripheries like coreboot) efforts rarely seem to gain the kind of sizable acceptance required for these kinds of endeavors.
It looks like the coreboot guy, Stefan, works for Google. So that may be a possible "in" (for example, future Chromebooks).
I'm an open source person and I care for EFI :)
It looks like some Free Software people (along with the coreboot) guy don't care for EFI, due to IP issues.
However, Free Software hardware (and peripheries like coreboot) efforts rarely seem to gain the kind of sizable acceptance required for these kinds of endeavors.
It looks like the coreboot guy, Stefan, works for Google. So that may be a possible "in" (for example, future Chromebooks).
http://blogs.msdn.com/b/b8/archive/2011/09/22/protecting-the...
If you look at the diagram, it appears that Remote Attestation is being brought back. For those of you who weren't around, or weren't paying attention, during the first Trusted Computing War, that means something like the following:
- You try to log on to your bank's website - Your bank queries your TPM - Your TPM sends back a signed hash attesting that you're running an unmodified version of Windows 8 - The bank lets you on
Versus:
- You try to log on to your bank's website - Your bank queries your TPM - Your TPM sends back a signed hash attesting that you're running an unmodified version of RedHat Linux - The bank denies your login for violating the security policy - There is NOTHING you can do about it, short of taking an electron microscope to your TPM to extract the keys.
Of course, none of this is possible as long as there are a nontrivial number of people whose machines aren't capable of Remote Attestation. But it's likely that every machine you've bought in the last 5 years has a TPM with this capability, which means that as soon as Windows 8 and UEFI Secure Boot have critical mass, Remote Attestation will have critical mass too. And then it will start showing up in security requirements for banks and other secure applications. And then the Linux users will start to feel the heat...