mjg59 | "Why not just use Coreboot?"

Why not just avoid the entire Secure Boot problem by using Coreboot? Because the reason we have the Secure Boot problem is because Microsoft's Windows 8 certification requirements mean vendors have to ship a UEFI implementation with Secure Boot. You could satisfy that by using Coreboot with a Tiano payload, but it'll still have Secure Boot enabled so you still have the same set of problems. But maybe you could just reflash your system with Coreboot? No, because another part of the requirements states that all firmware updates have to be cryptographically signed now. The only way to reflash will be to attach a flash programmer directly to your motherboard.

So why not just use Coreboot? Because it doesn't help solve this problem in any way.

Threaded | Flat

From: (Anonymous)

So why not just crack it?
UEFI is so complex that it is almost impossible to implement bug free.

From: (Anonymous)

Does the fiormware need to be signed by a manufacturer's key or can it be signed by a key setup manually as secure boot keys can be?

From: (Anonymous)

So does that mean that we won't be able to reverse-engineer future motherboards and flash coreboot on them? This probably means the end of Coreboot as a project then, right…?

Such a shame. I much preferred Coreboot's minimalism. But even openfirmware would have been preferable over UEFI. I still don't understand the raison d'etre of (U)EFI, and it seems to have been overloaded with boatloads of "stuff" of dubious necessity.

From what I understand, even an open source "UEFI-light" is not in the cards, right? Man, this really is turning into a nightmare.

From: (Anonymous)

Does any part of the Windows 8 requirements prohibit having a coreboot base with an EFI Secure Boot payload *and* another payload? In other words, could you boot Windows via EFI Secure Boot, and boot Linux via a GRUB2 payload?

From: (Anonymous)

Hello Matt. I was wondering: why not lock down ROM flashing ability, by requiring a password stored in firmware? This check would have to be implemented on the hardware or firmware level.

I wouldn't be surprised if this is not possible on today's systems, but wouldn't this be an appealing alternative to placing the burden of security on some other key-signing authority? The computer would come with a pre-set random password, and/or ask for one on first boot. Ideally, users could be given the option of using the password, or using Microsoft keys.

I'm curious if you can spot any problems with this idea. One that I see is that the password check may need to be at the cpu, chipset, or firmware level before giving write access to firmware. That might be tricky to implement and/or depend on AMD/Intel wanting to implement it.

Another catch is: if flashing is done within a booted OS, then you face the problem of keyloggers. But this can be avoided by booting from a usb stick to flash the firmware.

I think having this choice is preferable to a "Trust Microsoft's key signing authority and the ability for every signed GNU/Linux distro to lock down their bootloaders, kernels and modules appropriately" approach as the only option besides having no protection at all.

What do you think about this idea?

From: (Anonymous)

I would encourage everyone of a technical bent to watch this talk which explains why UEFI is just horrid on so many levels, not least of which it being technically incompetent of doing the job it was supposed to do.

http://www.youtube.com/watch?v=V2aq5M3Q76U

From: (Anonymous)

http://www.amazon.com/Samsung-XE300M22-A01US-Series-3-Chromebox/dp/B007Y8DJEA

Realistically, though, if we ever get to the point that we can't do something like coreboot on hardware, the next target is Linux -- as it has been all along, since this secure boot nonsense first started to appear. And we can't hide behind the ARM: MS is pushing UEFI on that one too.

The Chromebook/Chromebox have a verified boot that's open source right down to the BIOS. That's how it ought to be.

Not that I speak for Google.

From: (Anonymous)

On many platforms there are root keys in the chipset itself, even with a jtag you won't be able to stick your own firmware on it. That's been true for a long time.

From: (Anonymous)

Matthew:

Why haven't Red Hat and the other Linux friendly tech companies gone to the DOJ about this? This is clearly setting Microsoft up to be the gatekeeper whether or not they are being benevolent about it at the moment. It is simply unacceptable that a company with a monopoly hold on the OS market should be the sole driving force behind this technology. Especially considering past threats against Linux. Why isn't anyone screaming bloody murder right now?

From: (Anonymous)

Did you seriously start a sentence with "Because the reason we have the Secure Boot problem is because..."?
Why not just drop ALL of those wasted words and start with "Microsoft's Windows 8 certification requirements means..."

From: (Anonymous)

Wonder what effect if any the fallout from Flame will have on this plan.

From: (Anonymous)

Coincidence but I just posted a change.org Petition two days ago about the UEFI:

https://www.change.org/petitions/federal-trade-commission-stop-microsoft-pc-makers-monopoly-plan-for-uefi-boot-loader-restriction

From: (Anonymous)

>>cleverly designed binary may be able to validate even though it contains unsigned code Someone can just write and sign the bytecoode interpreter. Then what? Even though the interpreter itself is not malicious it could be used for malicious purposes. Where do you draw a line? Will you ban thin hypervisors because some flaw could allow unsigned VM code to change something on the host? >>People desperately want to believe that the Secure Boot implementation is fundamentally >>broken, and that's just not true. But it is true. Certificate Authority system is broken. Adding a 3rd party to a chain of trust reduces security by increasing the number of entities you implicitly trust. The whole CA thing is just a money raking scheme, a big boys club membership pass. >>For starters, you'll need to provide some form of plausible ID for Verisign to >>authenticate you and hand over access. Yes, as if someone from Russia or China couldn't do that. Good luck trying to arrest them. Anyway, Verisign wouldn't be the first security company that got compromised. Verisign has been tricked into issuing certificates in Microsoft's name: http://news.cnet.com/2100-1001-254628.html Diginotar has been breached: http://isc.sans.edu/diary.html?storyid=11500 RSA has been breached: http://www.nytimes.com/2011/06/08/business/08security.html?pagewanted=all Microsoft's own certificates were compromised few days ago and had to be revoked, not to mention that they have allowed Flame malware to exist and do its bidding. It's almost as if that was a deliberate backdoor waiting to be exploited: http://blogs.technet.com/b/msrc/archive/2012/06/03/microsoft-releases-security-advisory-2718704.aspx And what if someone with enough determination actually physically breached into Verisign and got the UEFI root CA thus compromising everything? How is that going to be revoked? Will it require user consent, or will it be silent, mandatory key update? What will happen with user added keys? Will you trust the state of potentially compromised system or you will zap the key store and just load the new key? Will you have to pay again to sign with a new key? The whole point of secure boot is not to secure our computers from malicious software (did anyone seriously believed that for one second?), but to secure software and media content that we "the pirates" might try to "steal". Next thing you won't be able to pass the BIOS boot screen unless the computer is online and can check for updated or revoked certificates. From that point onwards it is just a matter of months before they will silently start scanning your data and sending it to them through the out-of-band network channel.

From: (Anonymous)

>>cleverly designed binary may be able to validate even though it contains unsigned code

Someone can just write and sign the bytecoode interpreter. Then what? Even though the
interpreter itself is not malicious it could be used for malicious purposes. Where do
you draw a line? Will you ban thin hypervisors because some flaw could allow unsigned
VM code to change something on the host?

>>People desperately want to believe that the Secure Boot implementation is fundamentally
>>broken, and that's just not true.

But it is true.

Certificate Authority system is broken. Adding a 3rd party to a chain of trust reduces
security by increasing the number of entities you implicitly trust. The whole CA thing
is just a money raking scheme, a big boys club membership pass.

>>For starters, you'll need to provide some form of plausible ID for Verisign to
>>authenticate you and hand over access.

Yes, as if someone from Russia or China couldn't do that. Good luck trying to arrest them.

Anyway, Verisign wouldn't be the first security company that got compromised.

Verisign has been tricked into issuing certificates in Microsoft's name:
http://news.cnet.com/2100-1001-254628.html

Diginotar has been breached:
http://isc.sans.edu/diary.html?storyid=11500

RSA has been breached:
http://www.nytimes.com/2011/06/08/business/08security.html?pagewanted=all

Microsoft's own certificates were compromised few days ago and had to be revoked, not
to mention that they have allowed Flame malware to exist and do its bidding. It's almost
as if that was a deliberate backdoor waiting to be exploited:
http://blogs.technet.com/b/msrc/archive/2012/06/03/microsoft-releases-security-advisory-2718704.aspx

And what if someone with enough determination actually physically breached into Verisign
and got the UEFI root CA thus compromising everything? How is that going to be revoked?
Will it require user consent, or will it be silent, mandatory key update? What will happen
with user added keys? Will you trust the state of potentially compromised system or you
will zap the key store and just load the new key? Will you have to pay again to sign with
a new key?

The whole point of secure boot is not to secure our computers from malicious software
(did anyone seriously believed that for one second?), but to secure software and media
content that we "the pirates" might try to "steal".

Next thing you won't be able to pass the BIOS boot screen unless the computer is online
and can check for updated or revoked certificates. From that point onwards it is just a
matter of months before they will silently start scanning your data and sending it to
them through the out-of-band network channel.

From:

ayers [launchpad.net]

Clearly having a key signed by any unrelated software vendor is an unfortunate workaround to this issue. Putting all the bashing aside, what would the ideal solution look like? How can the situation be fixed... now or in the future?

Let's assume, that users want to insure that their boot sequence has been verified and signed by the trusted vendor of their choice, yet still keep themselves in control to override the upstream signatures. How should that be set up?

There could be some centrally maintained list of 'root' keys that each hardware vendor imports as the default list. The signing format must be updated to allow multiple signatures on binaries. That way, the user can choose which vendor keys to trust and distributions can decide to have there code signed by multiple vendors who choose to take responsibility for the security of the code. The UEFI implementation must provide a simple application to manage those keys. This simple applications must provide a consistent user experience over all UEFI implementations. It would probably be best to provide this simple application in the reference implementation. The management must allow the user to trust and distrust keys, to remove keys and to add keys from external media and to prioritize keys in a list to resolve potential conflicts of binaries whose signatures have been revoked by some vendors but not by others. There should probably also be an easy way to restore the default list. Yet there must be another application for the operating systems for every day users to generate there own key and install it on external media to add it to the UEFI key management, so that they can position their own key on top and override the vendor keys. It should also be trivial for the user to sign boot loaders, kernels, drivers they trust.

The major distributions could use a single organization like the Linux Foundation to manage a root key in the default list. Yet it would allow other distributions to distribute their own root key independently via their websites. The user would store them on external media to install them via the UEFI key management. This should allow the user to control the system while using secure boot to keep whatever integrity secure boot offers.

From: (Anonymous)

Secure Boot resides within UEFI, like you said. UEFI resides within Flash memory. Agreed? If you attach that "flash programmer directly to your motherboard" and replace the data with Coreboot with Tiano, wouldn't you then erase the Secure Boot software and replace it? If not, what are you programming? The only way you'll be able to still have the Secure Boot data on the device after flashing, is if it's an incomplete flash, or you flashed the wrong chip..