Live data from Hacker News

Microsoft proves backdoor keys are a bad idea

theregister.co.uk

101–106 of 106 posts

Re: Microsoft proves backdoor keys are a bad idea

#102
post #90

Earlier quoted context omitted.

But it's ok if Samsung, Google, Apple or whoever else lock you out of the device? Or at least they're not doing it to protect their monopoly. 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?

> But it's ok if Samsung, Google, Apple or whoever else lock you out of the device? Or at least they're not doing it to protect their monopoly. 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 u…

> Google sells phones with unlocked boot loaders

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.

Re: Microsoft proves backdoor keys are a bad idea

#103
post #97

Earlier quoted context omitted.

If Apple can take the phone and unlock it with the tools and knowledge at their disposal, then they have a backdoor for it. The distinction that you're drawing is meaningless.

A backdoor is typically reserved for solutions that bypass the existing security. As I understood it, the only thing Apple could do was provide a firmware without rate limiting. This would have allowed the FBI to perform an exhaustive search for the key. We already know that brute-forcing a key is always possible, that's not a new way to bypass security.

No, brute forcing a pin is not supposed to be possible. And yes, it was always possible, but only if you have Apple's secrets. A short PIN is only secure because of rate-limiting. Loading a firmware without rate-limiting is effectively hacking the phone. Apple possessed backdoor to phones that have a short PIN.

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.

Re: Microsoft proves backdoor keys are a bad idea

#104
post #48

Earlier quoted context omitted.

a deliberate effort by righteous free software-minded people who happen to work at Microsoft Or maybe a deliberate effort by developers who are paid by a three letter agency to sneak in a backdoor that looks like an accidental bug. In this case you might be right, but the last time a similar issue was widely circulated (Heartbleed in OpenSSL), it also looked like an accident (or rather gross negligence), but its effe…

> Or maybe a deliberate effort by developers who are paid by a three letter agency to sneak in a backdoor that looks like an accidental bug. Why would a three-letter agency bother to do that, when they could just as well get their malware EFI module signed by MS, and thus pass the secure-boot requirement? That way they wont risk exposing the existence of a backdoor on every single Windows-copy deployed worldwide. I h…

when they could just as well get their malware EFI module signed by MS

This is exactly what the FBI tried with Apple, causing an enormous public mud fight.

Besides, the outlined method would rather be deployed by NSA, or maybe a foreign service, without legal means to get a signed malware module.

Even if such legal means would exist, it would be in Microsofts best interest to fight them in court: once leaked, the malware would be clearly attributable to MS.

Re: Microsoft proves backdoor keys are a bad idea

#105
post #90

Earlier quoted context omitted.

> But it's ok if Samsung, Google, Apple or whoever else lock you out of the device? Or at least they're not doing it to protect their monopoly. 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 u…

> Google sells phones with unlocked boot loaders 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. T…

> Apple's laptops are absolutely locked down using EFI, you can't install any other OS unless Bootcamp allows it.

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.

Re: Microsoft proves backdoor keys are a bad idea

#106

Earlier quoted context omitted.

> Google sells phones with unlocked boot loaders 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. T…

> Apple's laptops are absolutely locked down using EFI, you can't install any other OS unless Bootcamp allows it. 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, rEFI…

You're right, this is 100% not true. I've installed VMWare ESXi on modern Apple hardware using tools like rEFIt. It's actually easier than on an equivalent PC since you never have to deal with the Secure Boot garbage.
Post reply on HN