Maybe to clarify: it highlights the mechanism (golden key) is flawed. That Microsoft uses it for boot loaders is unimportant.
Unfortunately, I don't think that's the message that's being interpreted by the vast majority of readers. I'm delving into opinion territory now, but when the word 'backdoor' is used, aren't most people going to assume that it's an FBI backdoor, instead of a test/development backdoor? This seems like the kind of article that fans the fuels of conspiracy theorists, and no one seems to be doing anything to correct the record.
If you let backdoors in the system, of course the secret services will demand to have it.
In fact, backdoors that were put in place because secret services' pressure, will be suited as developer backdoors as an excuse when found by the mainstream.
First they install backdoors in systems, in order for MS or the US gobertment to have complete access to any computer in the world, then they worry when the Chinese and Russians find them.
A backdoor that requires physical access isn't a backdoor. If an attacker has such access, you're already screwed.
A backdoor that requires administrative privileges isn't a backdoor. If an attacker has such access, you're already screwed.
The so-called dev/test 'backdoor' really isn't a backdoor. It's a 'unlock' tool that's required for anyone who's going to engineer the device. My main beef is that this article appears to be re-branding the engineering unlock as a backdoor, and confusion is obviously ensuing.
Again, In my original post, I asked "What's the exploit"? and I understand that the existence of an exploit might not be the article's subject, but If you really think that there's a security problem here, I'll ask it again: "What's the exploit?"
The security model of "secure boot" is designed to mitigate physical access, so a private way of circumventing that property is a backdoor.
While breaking this one aspect leaves other useful security properties intact, if those properties had been the only goal, they could have been implemented with a simpler and more user-friendly system.
so why did the original "load an unsigned debug build" functionality require cryptography rather than just, say, holding down the volume button during boot? Because it's not nearly as simple as "I have the hardware, I can do anything".
> A backdoor that requires administrative privileges isn't a backdoor. If an attacker has such access, you're already screwed.
Then why bother trying to lock it down in the first place?
I'm finding your line of argument across multiple comments increasingly disingenuous. You're hurting your argument far more than you're helping.
I ask this because I'm still rather unclear about the argument that the original article is trying to make. I'm even more confused about what conclusions slipstream would have us draw from his web-post. Some comments here say that it's not an exploit, that instead its a lesson about why you shouldn't, as a matter of policy, include backdoors. Others say that it is a backdoor/security hole, and are appropriately up in arms over it. The only thing I'm confessing is confusion.
I understand that you think I'm being disingenuous, and the nice thing is that we really don't need to continue this conversation. If it is as bad as some are suggesting, than wouldn't an exploit be out in the near future? I'd expect such an exploit, or even evidence of a backdoor, to make further news, and if I see it then I'll obviously have my answer.
I don't think they were trying to make any particular point rather than generate pageviews with a combination of "haha M$" and righteous anti-backdoor anger.
That said, I myself agree with other commenters that your stance "this isn't a backdoor because it requires physical access; if you've given up physical access you're already screwed" is beyond disingenuous. Disregarding a login screen bypass by the same logic would be rightly pilloried. Yes, physical security is the hardest to improve, but that's exactly the carrot Microsoft has used to try and convince the world Secure Boot isn't a pure anti-consumer move.
Ok, I'm open to the possibility that my views might be dated on this.
But, to be fair:
1) the 'physical access' rule was an absolute given in training that I've taken. (I'll let you draw your own conclusions since that the training was hosted by Microsoft). I guess I've had it drilled into my head for so long that I didn't even think the assertion would be controversial here.
2)Schneier commented on here (https://www.schneier.com/blog/archives/2009/10/evil_maid_att...) stating: "As soon as you give up physical control of your computer, all bets are off."
Granted, Schneier's comment was in 2009, and it's possible that expectations on security have changed since then, but
3) this stackexchange question (http://security.stackexchange.com/questions/19334/what-can-a...) is a bit more recent. Some quotes:
"Physical security is a critical (arguably the most critical) part of IT Security. At the end of the day, almost anything can be overridden with local access to the hardware."
"If a "hacker" with any real experience or skill has physical access to a PC, I would just throw away the hard drive and start fresh."
4) even some other comments in this thread (https://news.ycombinator.com/item?id=12264137) don't paint my notion as disingenuous as you might.
Again, I'm not a security expert, but do you think I could be forgiven for making such an assertion?
> Again, I'm not a security expert, but do you think I could be forgiven for making such an assertion?
Yeah, I forgive you.
Spaghetti to a wall as well.
You're not arguing coherently, effectively, logically, or using terms defined as they're commonly understood.
It's more like saying having a admin/root account and a post-it with a password hint is a backdoor (which is also wrong, of course).
(I'm not sure if that's what the Register was trying to say, because they're kind of screechy and incoherent at the best of times, but that's how I personally read it.)
> and no one seems to be doing anything to correct the record.
Maybe Microsoft feels guilty about it? It reminds me of when a journalist asked them about Bitlocker being backdoored, and they refused to comment.
https://www.schneier.com/blog/archives/2015/03/can_the_nsa_b...
Most companies don't go to the extent of having a cryptographically secure key validated by a TPM. At least MS is trying to secure the system.
Also, we're talking about Microsoft ARM based devices so what monopoly are they trying to protect? The monopoly on landfill space they used to dump all the Windows RT devices they failed to sell?
No, it is not ok. Kindly point me to the place where I said it is ok. (That said, Google sells phones with unlocked boot loaders, and have similar "Developer Mode" support for Chromebooks. Samsung and Apple to the best of my knowledge do not sell unlocked phones but do sell unlocked laptops).
> Also, we're talking about Microsoft ARM based devices so what monopoly are they trying to protect? The monopoly on landfill space they used to dump all the Windows RT devices they failed to sell?
Ah, but they wouldn't have produced millions of these devices if they didn't think they could sell them. The ARM based devices were a test of the waters.
Microsoft requires, on x86, that trust of the MS key be preinstalled and that it be possible to turn off UEFI - but they do not require (e.g.) that there be an ability for the user to remove the MS trust or add new trust. (All of these requirements support their monopoly).
I cannot know, but I suspect Microsoft is playing the long game here, and that at some point after Win7 extended support (4 years from now), they plan to require that UEFI cannot be turned off for a machine to be certified to run Win10 "dominion edition". They've started with restricting kernel drivers in the "anniversary edition". I suspect The ARM UEFI was a test for this.
If I am right, the failure of WindowsRT will not change the course of this long game; hopefully something else will (right now, the emergence of reasonable Chromebooks is the only thing that appears to have the potential to stop it)
They also sell carrier editions with locked boot loaders just like everyone else. Locking boot loaders is usually a carrier requirement imposed on manufacturers, not something OEMs arbitrarily decide to do, unless you're TP-Link.
> have similar "Developer Mode" support for Chromebooks.
CoreBoot on Chromebooks is just as locked down as UEFI Secure Boot if not more so. The RW Firmware isn't loaded unless the RO Firmware permits it and you can't modify or replace the RO Firmware by software. It requires hardware modification. Enabling Developer Mode on a Chromebook is analogous to disabling Secure Boot in UEFI.
> Samsung and Apple to the best of my knowledge do not sell unlocked phones but do sell unlocked laptops).
Samsung UEFI laptops have been known to brick if you try to boot Linux, not fail to boot but BRICK. Apple's laptops are absolutely locked down using EFI, you can't install any other OS unless Bootcamp allows it.
> Microsoft requires, on x86, that trust of the MS key be preinstalled and that it be possible to turn off UEFI
Secure boot is a security feature that validates code prior to execution via PKI in a signature database. The PK, is created and owned by the OEM and it can add KEKs from vendors (or distros) to allow them to sign their code. This database is owned, controlled and populated by the OEM, not Microsoft. Microsoft has no control over it beyond making their software refuse to function on not compliant systems. However the purpose of the feature is the inverse of that. That being said, there are several Linux Distros that support Secure Boot and offer PKIs for vendors.
Starting with Windows 8.1, Microsoft requires that new systems support Secure Boot have it enabled with Microsoft's PKI. That doesn't stop you from disabling it to use another OS. It doesn't inherently lock anyone out using whatever software they want, that decision is made by the vendor. The whole point of the system is to protect users from a compromised system, if someone tampers with Windows or it's drivers then the UEFI will refuse to boot it. It has absolutely nothing to do with locking people out.
Now on their RT/Mobile devices you can't disable UEFI Secure Boot. That's akin to locked ROMs and it's a requirement from Microsoft. There's no expressed reason for this but it's obviously because Microsoft gives OEMs subsidies to make Windows RT/Mobile devices so the hardware is often less expensive than comparable Android hardware. The last thing MS wants is for people to replace Windows on the devices with CyanogenMOD.
> They've started with restricting kernel drivers in the "anniversary edition".
Your implication is that this is a user hostile action when it's really a security measure to prevent naive users from installing hostile drivers. You can disable the feature by turning on developer mode. Now that's ok for Google's Chromebooks but not Windows?
You're attacking Microsoft for things you're giving everyone else a pass on.
Not exactly true, or even a little bit true; however, I'd say that these tools aren't exactly well known.
http://www.rodsbooks.com/refind/
> This page describes rEFInd, my fork of the rEFIt boot manager for computers based on the Extensible Firmware Interface (EFI) and Unified EFI (UEFI). Like rEFIt, rEFInd is a boot manager, meaning that it presents a menu of options to the user when the computer first starts up, as shown below. rEFInd is not a boot loader, which is a program that loads an OS kernel and hands off control to it. (Since version 3.3.0, the Linux kernel has included a built-in boot loader, though, so this distinction is rather artificial these days, at least for Linux.) Many popular boot managers, such as the Grand Unified Bootloader (GRUB), are also boot loaders, which can blur the distinction in many users' minds. All EFI-capable OSes include boot loaders, so this limitation isn't a problem. If you're using Linux, you should be aware that several EFI boot loaders are available, so choosing between them can be a challenge. In fact, the Linux kernel can function as an EFI boot loader for itself, which gives rEFInd characteristics similar to a boot loader for Linux.
One could speculate if this is a backdoor created with plausible deniability, maybe paid for by some three letter agency. But the evidence doesn't really point into the direction of an intentional backdoor.
Of course it isn't. Impossibility of bypassing is the only reason for secure boot technologies to exist. They are invented so that you are NOT automatically screwed if an attacker has physical access to your device. Secure boot technology is fine in principle, it's just stupid position the manufacturers hold. They ignore recent history. At their own peril, I'd say. https://en.wikipedia.org/wiki/Clipper_chip
And I'm not even sure physical access factor is strictly necessary for adversarial bypassing.
(I'm not a security expert, too.)
I think that this was once true, but Secure Boot was an attempt to improve the situation. My understanding is that Microsoft's Virtualization Based Security (which Device Guard/Credential Guard are built upon) rely on the assumption that the boot process is secure. If an attacker could have their root kit load before the OS/Hyper-V, then they render those mitigations useless.
Really?
Suppose that you are choosing a new device. You can choose one that let's a remote hacker install a rootkit via a malicious website, or you can choose one that let's a hacker install a rootkit only when they have physical access to your device.
Which one do you choose, and why is it the latter?
Remember that I-phone the FBI wanted apple to hack? With this golden key, anyone could've hacked into that I-phone.
I am not sure how e.g. bitlocker uses the TPM, but it might be that being able to load a modified OS allows for bypassing OS-implemented rate-limiting on TPM access.
Besides, doesn't secureboot block an unsigned live-CD? Otherwise, I don't see the point of secure boot past vendor lock-in.
The whole "only applies to RT devices" was a bit shifty looking from MS, though. Fortunately the broken Windows on ARM model died.
Edit: I'd also note that, e.g. console gamers love this stuff. It allows them to pretty much rely on others not being able to cheat very well.
The FBI had physical access to the San Bernardino iPhone. If this were true, what was the point of the public fight with Apple and eventual purchase of a zero day exploit to get into it?
The FBI asked Apple to create this firmware, and Apple refused.
What Apple had was the option of updating the phone with a compromised (or compromisable) security implementation.
Apple refused to do that.
The FBI did find an exploit (which AFAIR they've refused to disclose, in controvention of previous policy if not regulation and/or law), but that represents a flaw in implementation which Apple can then remedy.
http://mashable.com/2016/02/16/apple-hack-san-bernardino-pho...
Rather than asking Apple to obtain and provide the device’s passcode, Tuesday's ruling orders Apple to provide the FBI with special software that can act as a workaround for the iPhone's built-in security. Court documents suggest Apple should either provide software that bypasses the need for a passcode entirely or software that allows the FBI to unlock the phone by running an endless combination of passcodes until they are able to unlock the device. The latter method would also require software that disables the iPhone's auto-erase feature, which wipes a device after a certain number of unsuccessful attempts at unlocking.
The FBI was simply asking Apple to walk through a door that Apple created (perhaps unwittingly) for themselves. The case had nothing to do with forcing Apple to backdoor their products, which would mean mandated vulnerabilities that Apple is forced to ship phones with.
Apple can, and apparently is, designing future phones to not be vulnerable to this flaw. TPM chips, widely used in PCs, are not vulnerable to such an attack because the rate-limiting is done in the TPM hardware itself.
To be fair, the FBI did get into the phone, and could have much sooner had they not wasted their time fighting Apple.
This includes everyone from J. Random Hacker who wants to install on thier own hardware a linux (which might or might not be a good build), and an attacker who has borrowed your device from a hotel room to put some rootkit on it.
Besides, it is a worthy goal to protect a device from physical manipulation as well, i.e. to prevent border agents or secret agencies of a nondemocratic country from planting malware on your device.
The recent Apple vs. FBI debate has brought up a large number of arguments pro and contra protection from physical attacks.
I'm no security expert, but is this true?
Say I use full drive encryption, with whatever the popular Linux distros are offering at install time, and Say I use a strong password of 30 random characters.
Is it feasible to break this encryption in a reasonable time frame?
As far as is publicly known, you're not directly vulnerable to having the password broken as long as the device is powered off when it falls into the wrong hands, but there are a lot of caveats. If it's powered on they can possibly extract the password from RAM using a "cold boot attack". They can also freeze the RAM to get its contents to last longer and then moving it to another computer and dump it, recovering your full-disk encryption key.
If the attacker has temporary physical access, they have a number of ways that they can tamper with the device. For example, they can replace the BIOS, the bootloader, the firmware on your keyboard, etc. The new code can record your passwords or send your data to the attacker over the internet.
One other way that you're physically vulnerable is that the attacker can possibly infect your hardware before it even arrives at your home, by replacing hardware while it's shipping. This is probably only available to nation-states.
Tell that to the FBI. They seem to have been quite upset about not being able to unlock some iPhones.
Doesn't anyone wonder why you never seem to hear stories about FBI being unable to unlock encrypted user devices? Surely at the number of people who encrypt their Windows devices is in the tens of millions in the U.S. alone, and some of them must have been caught by law enforcement for various crimes.
It seems to me the mechanism was created exactly not allow even an owner to boot a non-approved OS image.
With a backdoor via any means, the attackers now basically have (N+1)% chance of getting that access, and arguably it's much more than a single increment since whereas other exploits "might" exist, these ones will guaranteed exist.
The suggestion and complaint isn't that "no secure boot is better than one that's easily bypassed", the complaint is requiring such a bypass and not giving the actual owners of the machine control over setting up that secure boot. With the RT devices, the user has absolutely no say in the secure boot process, and they're entirely dependent on Microsoft or whatever organization to provide best security practices.
Also, If the user sets up their own key and does it wrong, they have only themselves to blame. If a company or government does it, the user has no one to blame, since often legal contracts prevent any reparations as result of damage done by stuff like this. The US Government, for reasons of varying validity, needs to give you permission to sue it, meaning they can eschew any complaints should they lose the key.
All in all, a mandated backdoor just increases the chance that there will be a violation, takes control away from the user, and provides no compensation if the forced backdoor results in damages to the user.
> To reiterate, these Microsoft-signed resources – the debug-mode policy and the EFI installation tool – are only meant to be used by developers debugging drivers and other low-level operating system code. In the hands of Windows RT slab owners, whose devices are completely locked down, they become surprisingly powerful.
> It's akin to giving special secret keys to the police and the Feds that grant investigators full access to people's devices and computer systems. Such backdoor keys can and most probably will fall into the wrong hands: rather than be used exclusively for fighting crime, they will be found and exploited by criminals to compromise communications and swipe sensitive personal information.
I've read through the article, here, and in other places, and I'm seeing sentiment that this is a big fuck up on Microsoft's part. I might be completely misunderstanding, but I just don't see it.
In order to use the backdoor, you've got to flash firmware, so, you've got to have physical access to the device. If an attacker has physical access to your device, you're already screwed.
So, I don't doubt that the key exists (I had to use it myself when testing RT devices back in the win8 days), but what's the exploit here? Why is it, as the title suggests, a 'bad idea'? Isn't a secure boot policy that can be bypassed with physical access more secure than none?