Weekly Edition
Return to the Security page
| |||||||||||||
Garrett: UEFI secure booting (part 2)
Here's a second installment
from Matthew Garrett on the UEFI secure boot feature. "Microsoft
have responded to suggestions that Windows 8 may make it difficult to boot
alternative operating systems. What's interesting is that at no point do
they contradict anything I've said. As things stand, Windows 8 certified
systems will make it either more difficult or impossible to install
alternative operating systems. But let's have some more background."
(Log in to post comments)
Conceptually simple solution? Posted Sep 23, 2011 15:09 UTC (Fri) by cruff (subscriber, #7201) [Link]
Start a distributed effort to find Microsoft's private singing key, then release it to the world, rendering the key useless. However, since I'm not sure about the key size and encryption scheme being used by UEFI, I can't say how long such an effort might take.
Conceptually simple solution? Posted Sep 23, 2011 15:17 UTC (Fri) by lolando (subscriber, #7139) [Link]
Countermeasure: Microsoft can use a different signing key for each OEM, or even for each batch of boards coming from that OEM, thus diluting the efforts in search of "the" key.
Conceptually simple solution? Posted Sep 23, 2011 15:32 UTC (Fri) by cjb (guest, #40354) [Link]
We can presume they're still going to put Win8 DVDs in boxes and sell them at Best Buy at some point, though, right? And the key that verifies the signature of the boot binaries in those boxes will have to be present in every OEM's BIOS, and can't be revoked later without destroying the value of those boxes.
Conceptually simple solution? Posted Sep 23, 2011 15:46 UTC (Fri) by lolando (subscriber, #7139) [Link]
I'll concede the point.
(Unless and until Windows is only available via some kind of appstore, which would be consistent with the current trend.)
Conceptually simple solution? Posted Sep 23, 2011 16:00 UTC (Fri) by clump (subscriber, #27801) [Link]
Or just revoke the compromised key. The best solution is to ensure that hardware isn't limited to running only one operating system. There are a number of more ethical ways to achieve this goal.
Conceptually simple solution? Posted Oct 4, 2011 12:10 UTC (Tue) by robbe (guest, #16131) [Link]
I take exception to broadly labeling the breaking of the boot key as unethical. Against the law ... maybe (even that is doubtful, and highly specific to a jurisdiction) -- unethical ... no.
Conceptually simple solution? Posted Nov 4, 2011 21:32 UTC (Fri) by clump (subscriber, #27801) [Link]
Hrm, re-reading, I didn't mean to say breaking the boot key was unethical, but that's certainly how it reads. Apologies. How about instead of breaking the key, do what Garrett's doing which is to draw attention to the issue and try to fix it before it's a problem?
Conceptually simple solution? Posted Sep 23, 2011 15:51 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
Keys are RSA, probably 2048 bit. The alternative to breaking the key is to find a hash collision between a Microsoft-signed bootloader and a binary that executes arbitrary other binaries, which is "simply" a matter of breaking SHA-256.
Conceptually simple solution? Posted Sep 23, 2011 20:49 UTC (Fri) by rahvin (subscriber, #16953) [Link]
Why break the encryption. This is just like the major problem with Digital Rights Management and that is to have the ability execute the software you have to have both keys (public, private). So either the OS is signed with the private key or it's encased in the BIOS. The avenue of attack then becomes to simply extract the private key because you already have it. Like DRM I expect this will ultimately happen and break the entire purpose of the process. Blu-Ray was the most well thought out DRM ever invented and it was broken because if you give someone the keys to decrypt the content and then try to hide the keys through obfuscation you are doomed to failure.
Secure boot seems to suffer the same problem or media DRM, unless the private signing key is embedded in a TPM chip that would offer some actual protection to the private key. I seriously doubt they are going to put a TPM chip on every board and flash a private key from MS into that TPM (they might consider this if there is a TPM chip that can be updated, mass produced and can hold multiple keys). But even then, if the TPM can be updated it can be compromised.
I don't know why companies think encryption is an effective security measure if you give everyone both keys but try to hide one of them.
Conceptually simple solution? Posted Sep 23, 2011 20:54 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
It works like this. A hash is taken of (most) of the binary. That binary is encrypted with the private key. The encrypted hash is embedded into the binary. When you try to run the binary, the firmware takes a hash of (most) of the binary. The encrypted hash is then decrypted with the public key (which is included in the firmware) and compared. If the hashes match, the file is run.
The private signing key is not distributed with the binary. It's not distributed with the firmware. It's on a computer belonging to the company that did the signing. There's no requirement at all to have the private key in order to execute the code.
Conceptually simple solution? Posted Sep 24, 2011 0:46 UTC (Sat) by flewellyn (subscriber, #5047) [Link]
Could the firmware itself be bypassed, by reflashing for instance?
Conceptually simple solution? Posted Sep 24, 2011 2:11 UTC (Sat) by mjg59 (subscriber, #23239) [Link]
Under this scheme firmware updates need to be signed, so the only way to flash an unauthorised one would be by taking the machine apart and attaching to the flash directly.
Conceptually simple solution? Posted Sep 24, 2011 0:50 UTC (Sat) by Trelane (subscriber, #56877) [Link]
Those "(most)"s are quite interesting. Do you have more details?
Conceptually simple solution? Posted Sep 24, 2011 2:09 UTC (Sat) by pjones (subscriber, #31722) [Link]
The list of signatures is skipped during signing and verification, for obvious reasons.
Conceptually simple solution? Posted Sep 24, 2011 2:12 UTC (Sat) by mjg59 (subscriber, #23239) [Link]
Like Peter says, it's impossible to hash the section containing the signature because that's going to change when you insert the signature. Ditto for the file checksum.
Conceptually simple solution? Posted Sep 24, 2011 2:37 UTC (Sat) by flewellyn (subscriber, #5047) [Link]
So you could, in theory, read the region of the file that contains the signature, duplicate that, and put it in another file?
Conceptually simple solution? Posted Sep 24, 2011 2:39 UTC (Sat) by mjg59 (subscriber, #23239) [Link]
Absolutely. You'd then have a signed hash that wouldn't match the binary it was in, so it wouldn't be a great deal of use, but it's something that you could do
Conceptually simple solution? Posted Sep 24, 2011 2:51 UTC (Sat) by flewellyn (subscriber, #5047) [Link]
Oh, right. I forgot about the comparison part.
Hmm...well, I hope those enterprising folks that cracked the XBox 360 can help with this one...
It'll not help Posted Sep 24, 2011 14:13 UTC (Sat) by khim (subscriber, #9252) [Link] All known XBox360 cracks are hardware cracks so I'm not sure if it'll be big help or not.
Conceptually simple solution? Posted Sep 24, 2011 5:17 UTC (Sat) by rahvin (subscriber, #16953) [Link]
So would it be possible if there were enough hashes generated to back calculate the private key? After all you have the input and output from the private key hash and the public key. It would seem to be open to reverse computing the private key with the hashes once you obtain enough of them. Sort of a variation of the HDCP crack where they used all the HDCP keys that were generated from the base private key to reverse the private key.
Conceptually simple solution? Posted Sep 24, 2011 14:05 UTC (Sat) by mjg59 (subscriber, #23239) [Link]
Possible, sure, but that would be equivalent to cracking RSA and nobody's done that yet.
Conceptually simple solution? Posted Sep 25, 2011 19:53 UTC (Sun) by Wol (guest, #4433) [Link]
Because you CAN'T *crack* RSA. It's been proven to be impossible.
RSA is vulnerable, however, to being SOLVED.
I don't fully understand the maths, but RSA relies on a large number P1P2 (the product of two primes) being known to *both* parties. You can have many key-pairs for one P1P2. If you know one half K2 of a key pair you can encode/decode anything for the person who knows the other half K1.
IF however, you can find out what P1 is (and by implication P2 :-), given one half of the key-pair it is easy to calculate the other half. So, in order to verify the signature, I need to know P1P2, and K2.
That means if we launch a mass "find a prime and test it against MS's P1P2" campaign, we might well break it. Heaven knows we've got masses of compute power to throw at it! And if we find it, K1 will fall. It's probably 10 seconds work after P1 or P2 has been found.
Cheers,
Conceptually simple solution? Posted Sep 25, 2011 22:39 UTC (Sun) by rich0 (guest, #55509) [Link]
So, this is just a simple matter of factoring a 2048 bit number, then?
Phew, I was worried there for a second. Now I just need to build a two kilobit quantum computer or convert the mass of a few galaxies into conventional processor cores...
Conceptually simple solution? Posted Sep 24, 2011 2:19 UTC (Sat) by pjones (subscriber, #31722) [Link]
It isn't really like DRM - mostly because they used a well known good cryptosystem instead of making up their own, and they used it correctly.
Conceptually simple solution? Posted Sep 24, 2011 6:12 UTC (Sat) by job (guest, #670) [Link]
It's not like DRM at all. With a DRM scheme you get a media file or disc that you aren't allowed to play unless you use a certified player. Here it's the other way around, it's your computer which won't run unsigned software.
This can be accomplished using standard public key crypto, which we already trust pretty much everywhere to be unbreakable within the foreseeable future. It's what Microsoft used to call Palladium, which never took off, and later got joined in with the bigger Trusted Computing spec.
Linux is probably too big now to fall for this completely but it could still be a threat in the lower end consumer sector, where manufacturers are paid to load their systems with crapware. They want to make sure their crap is what boots after all.
But even if Linux is not harmed directly there could still be thousands of ways to harm it indirectly. An app store model which only runs on "trusted" hardware and does not allow you to export the software would pretty much kill Wine for example, while being an easy sell to OEMs. It is how game consoles already work.
Conceptually simple solution? Posted Sep 27, 2011 11:16 UTC (Tue) by ekj (guest, #1524) [Link]
No, the situation is not at ALL like the one for DRM.
DRM is, in essence, giving you some data, and the ability to playback that data, but *not* the ability to do other things with the same data, such as copy it.
This is fundamentally impossible. The data can be encrypted, but if so, you must posess the decryption-key in order to play the data back. And if your machine is capable of decrypting data for the purpose of sending it to the soundcard, then it's also capable of decrypting data and sending it to some other destination.
Signed bootloaders are not about the same thing at all. They're not worried that you'll copy the bootloader, or read it in unencrypted form. Instead they're worried that you'll not use their bootloader at all, but instead one of your own.
The straightforward way of doing this, is requiring that the bootloader be signed with some private key. The validity of this signature can be verified using the corresponding *public* key.
Essentially, the hardware does a variant of "If valid_signature(bootloader) then bootloader() else complain_and_stop()"
There's no need for the private key for this.
And the situation has precisely nothing at all to do with DRM, except for concepts from cryptography being used for both purposes.
The fundamental thing that makes DRM impossible is this:
I give you data. I also give you all the keys nessecary to decrypt the data. Yet I don't want you to be able to decrypt the data at will.
Conceptually simple solution? Posted Sep 27, 2011 12:06 UTC (Tue) by fuhchee (subscriber, #40059) [Link]
"Signed bootloaders are not about the same thing at all."
Right. But they are an enabler of robust DRM, because if the entire verification chain is deployed, then the DRM-enforcement code in the OS cannot (in theory) be bypassed. With unsigned code running in kernel space, the DRM enforcement game would be over before it started.
Conceptually simple solution? Posted Sep 27, 2011 12:21 UTC (Tue) by ekj (guest, #1524) [Link]
Right. But the game is -already- over before it's started, by way of the analogue-hole if nothing else. Atleast for content that's text/audio/video. (interactive content such as games can't really be copied by way of the analogue hole)
Get me right, signed bootloaders *are* potentially part of the same problem-space as DRM, namely the idea that someone else than you should have final say over which instructions execute, and which don't, on hardware that you own.
As such, they *are* a potential threat. My comment was meant much more narrowly: the fundamental impossibility of DRM, does not imply that signed bootloaders are fundamentally impossible.
Because the private key, or decryption-key is required to decrypt encrypted content, whereas it's sufficient with the public key to verify the signature on a program.
Garrett: UEFI secure booting (part 2) Posted Sep 23, 2011 15:43 UTC (Fri) by hannada (subscriber, #4633) [Link]
A more likely scenario, I think, is just that the fact that you have to "disable a critical security feature" in order to load a commodity PC with Linux. This will be a great FUDing opportunity to discourage casual users from even trying Linux.
This does beg the question, though, concerning the ultimate effectiveness of UEFI as a security feature. If UEFI turned out to be the Silver Bullet that would finally put an end to all malware, we'd have to concede that MS has accomplished something good.
However, I don't believe that most active trojans and viruses find it necessary to tamper with Windows booting in order to do Bad Things. I expect that the malware writers and script kiddies will not be greatly inconvenienced by this new feature.
The surest move I ever made to free myself from malware worries was to change over to running Linux as my primary desktop OS. We should still be able to make that case.
FUD and PITA Posted Sep 23, 2011 16:23 UTC (Fri) by dbruce (subscriber, #57948) [Link]
Given the need for businesses to run older versions of Windows (as well as Linux, et al), I'd be surprised if desktop/laptop PCs disallow non-UEFI booting anytime soon. It might be a part of Windows 8 tablets from the start, however.
So this may be a way to stigmatize Linux - making people believe it requires the computer to be "jailbroken" or "rooted" to run Linux (not that most folks ever think of Linux on desktops, or at all).
Also, it may thwart the very nice recent ability to keep an entire Linux distro on a keychain USB drive that can be booted by most PCs without changing any settings.
FUD and PITA Posted Sep 23, 2011 17:40 UTC (Fri) by mchazaux (guest, #64024) [Link]
What about virtualisation?
FUD and PITA Posted Sep 25, 2011 22:42 UTC (Sun) by rich0 (guest, #55509) [Link]
Ah, so you get the software compatibility of linux with the stability, performance, memory use, security, cost, and compatibility with old hardware of windows?
Virtualisation Posted Oct 4, 2011 12:35 UTC (Tue) by robbe (guest, #16131) [Link]
On server-class HW you normally boot directly to the hypervisor (Xen, VMware ESX, etc.). If this secure boot scheme is extended to these machines, HW manufacturers would have to allow this as well, either via a bypass or carry the keys of VMware, Citrix et al. The latter would effectively tivoize Xen (which is GPL v2). Carrying and caring for more than one key is hard, a bypass switch is easier, and will support customers wanting to run Linux on bare metal (a larger percentage than in the desktop market).
Maybe this will spill over to the desktop area, but maybe not. There is not much overlap in motherboards for servers and desktops, currently.
Virtualisation Posted Oct 4, 2011 13:46 UTC (Tue) by vonbrand (subscriber, #4458) [Link] Want to apply a hotfix for some kernel (or whatever else) package in your shiny new <insert favorite server OS here>? Sorry, must wait until the vendor goes around to push it out... that won't fly very far. And won't work with enterprisey desktops either, with custom packages or select non-bleeding-edge software versions. To me it looks like the same wet dream of "large software vendor" that TPM was, which went exactly nowhere.
"jailbroken" Posted Oct 4, 2011 12:06 UTC (Tue) by robbe (guest, #16131) [Link]
That you have to jailbreak your device does not have serious negative connotations for the average user. The word itself is positive! And a lot of users have freed their smartphone. The only hassle for the average user is actually doing it without fear of bricking their precious hardware. But the greediness of the telcos nicely fostered a culture of mom-and-pop mobile shops that will do phone unlocking (and jailbreaking, which is often necessary) for a small fee.
The Gnome developers just called, they want their average user back. So I can only talk about the people I know. Those that own smartphone, often jailbreak it.
Garrett: UEFI secure booting (part 2) Posted Sep 23, 2011 16:29 UTC (Fri) by k3ninho (subscriber, #50375) [Link]
>If UEFI turned out to be the Silver Bullet that would finally put an end to all malware, we'd have to concede that MS has accomplished something good.
Like identity cards with lots of details stopped people from denying political regimes like that in Hitler's Germany? (I know that this is a potentially sticky example, but it's a real time and place where showing your papers was expected and used to enforce rules.) The counterfeiters will co-opt the process and steal Windows' signing keys so that they can pass themselves off as the authentic article, and they'll probably do it without too much trouble.
I'm going to call this a piece of 'security theatre' -- it's show. While it might make some malware attacks more difficult, there are a few things we need to remember:
Take care.
Garrett: UEFI secure booting (part 2) Posted Sep 23, 2011 16:39 UTC (Fri) by cesarb (subscriber, #6266) [Link]
> finally, we will want to weigh up this prospect of buying a Windows-8-badged device with limited liberty to use its general-purpose components against the adage about trading-eternal-liberty-for-temporary-security.
This made me think of something. What if someone starts using it as FUD? "Do not buy computers with a Windows 8 logo, <insert bad thing here>." Even if the bad thing mentioned is not true, it does not matter; nontechnical users would not be able to tell the difference, and having heard that "Windows 8 has something that prevents you from booting other operating systems" (I know this sentence is a very badly mangled version of the issue, but it is how nontechnical people would perceive it) makes them more inclined to believe on the bad thing mentioned.
This could backfire for Microsoft if someone plays this angle.
Garrett: UEFI secure booting (part 2) Posted Sep 23, 2011 17:40 UTC (Fri) by cjwatson (subscriber, #7322) [Link]
Noting that Microsoft's response says something like (sorry, from memory as I'm typing this on my phone) "no compromise on security", I think the best way to respond to this in the public arena is to note that it's *securing the wrong thing* - it's securing the computer against its legitimate owner and user!
Garrett: UEFI secure booting (part 2) Posted Sep 23, 2011 17:34 UTC (Fri) by mgross (subscriber, #38112) [Link]
um, like kernel.org and linux.com?
Garrett: UEFI secure booting (part 2) Posted Sep 23, 2011 16:54 UTC (Fri) by paravoid (subscriber, #32869) [Link]
I am wondering how antitrust authorities will feel about this
Organizations should complain Posted Sep 24, 2011 3:57 UTC (Sat) by eru (subscriber, #2753) [Link] I am wondering how antitrust authorities will feel about thisThey won't feel a thing unless they receive enough complaints. It would probably be be useful if both vendors and user groups of other operating systems (not just Linux; the BSD folks are in the same boat) started filing complaints now, both in the US and EU.
Something to keep an eye on but I'm not seeing a big issue yet. Posted Sep 23, 2011 17:25 UTC (Fri) by mgross (subscriber, #38112) [Link]
I don't see a big difference between this and what's running on the chrome books. From the end of the referenced MS response http://blogs.msdn.com/b/b8/archive/2011/09/22/protecting-... shows a simple bios option to turn off secure boot.
I suspect anti trust challenges would quickly happen if the option to disable the secure boot was not available.
I am more interested in making sure we can make our own signed secure boot images and understand how to install deployment keys for our own locked down deployments (enterprise servers/clients or POS cash registers and what not.) What do the signing and key generation tools need to look like? Can we make such tools? What would os updates look like on such deployments?
I think our biggest problem is to get Linux distros installers and boot loaders to "just work" on such uefi systems. I had a hell of a time getting ubuntu 11.04 to install on a Cr48 and in the end I had to just flash a EFI bios that included the compatibility layer.
Something to keep an eye on but I'm not seeing a big issue yet. Posted Sep 23, 2011 17:45 UTC (Fri) by cjwatson (subscriber, #7322) [Link]
I expect it would be straightforward enough to add an option to grub-setup to sign generated GRUB core images for UEFI, although I doubt any GRUB developer (including myself) would be remotely interested in locking down the system more than necessary. The actual signature protocol is pretty simple.
I haven't brought it up on grub-devel yet because the whole thing is intensely political and honestly I'd rather only do it once it's clear that we have no choice if we want to keep booting; I don't want "GRUB works with UEFI secure boot" to be a check on somebody's checklist.
Something to keep an eye on but I'm not seeing a big issue yet. Posted Sep 23, 2011 23:53 UTC (Fri) by iabervon (subscriber, #722) [Link]
I think it would be good if computers came with a USB frob, and the only way to create a boot image that the BIOS wouldn't warn you about would be to plug in the frob and get it to sign the image. The thing is "the key to your computer", and it is needed as part of any OS installation (although it is also possible to use "the key" on a different computer to set up a linux image on a USB drive that your computer will trust). If that system were available, the next step is FUD saying, "If you got a Windows 8 computer, and it didn't come with 'its key', then Microsoft can hack into your system no matter what OS you use! They'll be able to force you to use broken versions like Vista, even if you don't want to, because your computer automatically trusts them. If you have 'the key', you control when you upgrade and what you run."
Of course, UEFI doesn't really provide any meaningful security in the first place, but if you postulate that it has some benefit, allowing Microsoft to circumvent it would be obviously very bad.
The key to your computer Posted Oct 4, 2011 11:41 UTC (Tue) by robbe (guest, #16131) [Link]
Cool idea. The two problems I see with this:
* Users will misplace their key, especially if it is needed very rarely. Will you offer a backdoor, or is that tough luck?
* I have a hard time imagining manufacturers, that shave off single jumpers for the cost savings, throwing in an USB key.
USB Posted Oct 4, 2011 16:39 UTC (Tue) by mathstuf (subscriber, #69389) [Link]
> an USB
Is this a typo or do you pronounce "USB" as "us-buh" rather than "yoo ess bee"? Just wondering if there are people that don't just spell "USB" when saying it.
Something to keep an eye on but I'm not seeing a big issue yet. Posted Sep 24, 2011 14:47 UTC (Sat) by mgross (subscriber, #38112) [Link]
One question WRT all this posturing: Would have a secure boot implementation prevented the rootkit that took down kernel.org from happening?
Something to keep an eye on but I'm not seeing a big issue yet. Posted Sep 24, 2011 14:50 UTC (Sat) by mjg59 (subscriber, #23239) [Link]
Possible, but unlikely.
Garrett: UEFI secure booting (part 2) Posted Sep 23, 2011 17:34 UTC (Fri) by b7j0c (subscriber, #27559) [Link]
UEFI, GPT the rest of it....its been nothing but a hassle in my life.
fortunately when installing freebsd9 on a macbook pro, there is an escape hatch to go into a shell and just obliterate the gpt before installation
GPT Posted Oct 4, 2011 11:36 UTC (Tue) by robbe (guest, #16131) [Link]
At least GPT solves the real problem of large (>2 TB) partitions. What problem does UEFI (or secure boot) solve?
GPT Posted Oct 12, 2011 18:48 UTC (Wed) by ccurtis (guest, #49713) [Link]
>> What problem does UEFI (or secure boot) solve?
The problem of having a 1970s era BIOS. See:
GPT ->> What problem does UEFI (or secure boot) solve? Posted Oct 13, 2011 13:23 UTC (Thu) by etienne (subscriber, #25256) [Link]
Seen that long video, was not convinced.
Considering points: - Time delay at POST Solved by UEFI by disabling boot from CDROM/DVD (the drive usually needs 4-6 seconds to detect if a disk is present) and network boot (needs some network traffic, and initialisation of the network card by the network card real-mode code contained in the FLASH of the PCI card).
- Boot Kit threats
- Loads of <Fn> key options at boot
- Confusing O.S. boot menus
- No connection between OS and BIOS boot menu
- BIOS menus circa 1980
- BOOT disk size limited to 2.2TB
Moreover I would like to see those PC where the BIOS (real mode) is implemented on the top of UEFI (64 bit virtual memory) as he said, IHMO it is not possible - I will be proven wrong when I see one such a beast...
In short, not everything made in the 1970s area has to be rejected just because of its age.
Garrett: UEFI secure booting (part 2) Posted Sep 23, 2011 17:40 UTC (Fri) by alvieboy (subscriber, #51617) [Link]
What exactly is being signed and checked ? Only the bootloader, or other parts of the operating system ? I guess that for "other parts of operating system" validation they would have to get NTFS support in the firmware.
Now, if only the bootloader is signed, I wonder if we can use it as-is to bootstrap a second bootloader (e.g., grub), and continue from there (can we?). That would probably imply a small NTFS/FAT partition.
I assume this secure boot thing is backed up by a TPM chip. Most vendors should give users support to reset the TPM using physical presence (e.g., some jumper on the motherboard), or in the "BIOS" configuration screens.
And, as someone already said, this is the kind of things antitrust guys like. Lets see how it goes.
End note: having a HW reset mechanism for this (I assume a TPM will be used) will let you do whatever you want, and surely (since it's a physical presence thing) no worm/virus/trojan/whatever can do it for you - since this seems to be (is it?) the main objective, I don't see why they would disallow it [I'm not sure TPM are enforced to have some sort of reset mechanism, spec is quite vague]. There's of course Social Engineering which might force a user to perform the HW manipulation, but it's not a key point here.
Alvie
Is there any difference? Posted Sep 23, 2011 19:28 UTC (Fri) by khim (subscriber, #9252) [Link] What exactly is being signed and checked ? Only the bootloader, or other parts of the operating system ? AFAICS only bootloader is signed. The bootloader is supposed to verify the rest Now, if only the bootloader is signed, I wonder if we can use it as-is to bootstrap a second bootloader (e.g., grub), and continue from there (can we?). Depends on the bootloader, I guess. Wii used similar scheme and the way to fool the bootloader worked just fine till Nintendo produced newer versions of hardware which patched the vulnerability. Now you can not replace the bootloader - you must hack the OS itself. Thankfully it's easy enough to do. It does not look like the UEFI secure booting contains the reviocation list, so I guess we'll need to rely on old, cracked (but still signed) versions of Windows 8 to do the trick. As lock down scheme this does not look like very difficult scheme at all - nothing like XBox360 and/or PS3 (and these were successfully cracked), but the idea that you need to jailbreak the system to install Linux just does not feel like PC.
Is there any difference? Posted Sep 24, 2011 6:36 UTC (Sat) by gmaxwell (subscriber, #30048) [Link]
It _does_ contain a revocation list. I couldn't fathom what it was for until I saw your post. Thanks.
(and I think it sort of darkly supports the doomsday vision of this: I can see how a revocation list keeps you from using buggy windows bootloaders to boot linux, I can see how it can help create improved obsolescence, but I can't see how a revocation list will help protect a user from malware at all even in the fairly limited sense that UEFI secure boot can help at all)
Is there any difference? Posted Sep 24, 2011 12:54 UTC (Sat) by Trelane (subscriber, #56877) [Link]
> keeps you from using buggy windows bootloaders to boot linux
That's the place it can help vs malware. Arbitrary code is arbitrary code. What Linux needs is a way to a way to run *user-selected* code, not arbitrary code.
Garrett: UEFI secure booting (part 2) Posted Sep 25, 2011 20:07 UTC (Sun) by Wol (guest, #4433) [Link]
The problem here is the Windows Tax. You need Windows 8 in order to run linux, whether you want it or not.
At which point, MS says "but everyone uses Windows", and uses that to clamp down even tighter.
Cheers,
Will Keys expire? Posted Sep 23, 2011 22:34 UTC (Fri) by sjlyall (subscriber, #4151) [Link]
What would happen if the key (Microsoft's, Vendor's, OS's) expires? Will the machine now refuse to boot?
Could Vendors use this to limit the lifetime of machines, so you'd buy a computer and find that the cert on it expires in 4 years time after which it won't boot.
Will Keys expire? Posted Sep 24, 2011 20:29 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
It doesn't have an expiration date. Key revocation list is used instead to kill of bad certificates.
Will Keys expire? Posted Sep 26, 2011 10:27 UTC (Mon) by tialaramex (subscriber, #21167) [Link]
Note that getting this working is not, so far as I can see, on the short path to getting a Windows logo (and thus OEM pricing) so there is every reason to expect revocation won't work correctly in some proportion of systems "secured" with the technology.
The absolute laziest "implementation" will be to accept Microsoft's generic OEM key as issued and nothing else, ever. That suits Microsoft just fine today, although it's a nightmare down the road there's no sign anybody at Microsoft is thinking further ahead than the next financial year anyway these days.
Garrett: UEFI secure booting (part 2) Posted Sep 26, 2011 1:24 UTC (Mon) by PaulWay (✭ supporter ✭, #45600) [Link]
What I find amusing is the quantity of raving Microsoft fanboi comments along the lines of "Wow, this is great, keep up the good work Microsoft, we trust you completely!" It's like these people really need to believe that Microsoft is doing the right thing, this time, for sure, honest. Including the "I'm sure we'll get some Linux people whinging that they can't boot their own operating system, sucks to be them eh?" comments too. These people are really committed - and I mean that in a Stockholm Syndrome, insane asylum sense.
In contrast, the actual people asking about alternate operating systems are almost universally polite. Funny, that.
Human psychology is weird.
Have fun,
Paul
|
|||||||||||||