[personal profile] mjg59
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.

Date: 2012-06-06 04:10 pm (UTC)
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?

Coreboot = dead soon?

Date: 2012-06-06 06:01 pm (UTC)
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: [personal profile] markjenkins
My question is the same -- Matthew, are you saying that if I disable Secure Boot, boot my operating system of choice, and then try to use flashrom (http://flashrom.org) that I'll be out of luck, I won't be allowed to re-flash firmware on Windows 8 certified hardware?

How is this done? Does the boot firmware send some kind of signal to the flash chip to lock itself until the next reboot?

It would be better if operating systems (such as Windows and Fedora) were responsible for deciding that it is lockout time on the flash chip. This would allow a user supplied operating system booted to decide what should be done.

I'm hoping you'll reply and say I've got it wrong -- that we'll be in a world where you can't flash an arbitrary firmware when running a Secure Boot version of Windows or Fedora, that those systems will be the ones checking signatures before allowing flashing. Thus the freedom to switch to coreboot will still there for those who boot a different operating system.

Underlying assumption here: that the signature checking on new firmware is being done by either the boot firmware itself (with lockout to follow) or by operating systems (in which case we can run an operating system that doesn't do so) -- there's no weird crypto hardware like TPM being tied up in the Windows 8 certification requirements.
From: [personal profile] markjenkins
Did some of my own research on this.

It looks like firmware is locked out from write at a certain point by the boot firmware. Firmware updates that are initiated from the operating system are actually just queued up for installation by the current firmware on the next boot, and as such the current firmware does the final cryptographic checks before overwrite.

The UEFI specs provide some considerable APIs/protocols for changing stored keys and hashes but execution of these has to be done in "setup mode". It's not clear if UEFI firmwares have to provide any guis for actually using those APIs -- so its all going to be vendor by vendor.

Anyone know what the Microsoft Windows 8 certification requires? Are they just asking for users to be able to turn off secure boot for other operating systems but without requiring that the GUIs allow the firmware to be reflashed and or the keys/hashes changed?

For reference, this is one of the simple things I was looking at other than the UEFI spec itself
http://www.uefi.org/learning_center/UEFI_Plugfest_2012Q1_v3_AMI.pdf

and it notably referrenced this:
http://csrc.nist.gov/publications/nistpubs/800-147/NIST-SP800-147-April2011.pdf

"""
Security guidelines are specified for four system BIOS features:
• The authenticated BIOS update mechanism, where digital signatures prevent the installation of
BIOS update images that are not authentic.
• An optional secure local update mechanism, where physical presence authorizes installation of
BIOS update images.
• Integrity protection features, to prevent unintended or malicious modification of the BIOS outside
the authenticated BIOS update process.
• Non-bypassability features, to ensure that there are no mechanisms that allow the system processor or any other system component to bypass the authenticated update mechanism.
"""

Re: Coreboot = dead soon?

Date: 2012-06-12 10:01 pm (UTC)
From: [personal profile] markjenkins
Ahh, Microsoft requirements say this:
"""
17. MANDATORY. On non-ARM systems, the platform MUST implement the ability for a
physically present user to select between two Secure Boot modes in firmware setup:
"Custom" and "Standard". Custom Mode allows for more flexibility as specified in the
following:
a) It shall be possible for a physically present user to use the Custom Mode firmware setup option to
modify the contents of the Secure Boot signature databases and the PK. This may be implemented by
simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx) which will put the
system into setup mode.
b) If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the
system will be operating in Setup Mode with SecureBoot turned off.
"""

On systems where the firmware allows you to set a new PK (platform key) then you're able to reflash with a firmware signed by a new self-created PK.

On systems where the firmware just provides an option to wipe the PK and be in "setup mode" I presume you can subsequently boot your own operating system and set a PK from there -- can anyone confirm that UEFI specs describe setup mode this way? It would suck if such machines locked you out from changing the PK once you booted your own code.

One a new PK is installed (by a helpful firmware or a new PK intaller) then you could install your preferred firmware as a "capsule" to be installed by the old firmware on the next boot.

So, perhaps not the death of Coreboot on Windows 8 certified non-ARM hardware (without requiring special flashing hardware)? But, flashrom (http://flashrom.org) won't be useful for the first flash step, a new tool will have to be developed to do the above steps.

I'd be interested in developing a tool for installing new PKs while in setup mode and also porting coreboot to a motherboard that only ships with PK clearing -- I'm not thrilled that only Microsoft signed systems get the benifit of Secure Boot on such boards -- I'd like to "liberate" them to make for equal treatment.

This of course implies adding a Secure Boot option to a coreboot payload -- it would be interesting to decide which payload is best to enhance along those lines. Tiano may be the way to go, but perhaps grub2 as a coreboot payload using some of the enhacements that Fedora is making to it for Secure Boot purposes.

Date: 2012-06-06 06:07 pm (UTC)
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)
One thing I forgot to point out is that the password option puts users in control over their own machines, while still offering security against malware.

With key signing, you have to trust the keysigner, the intentions of those who compile the signed operating system, and the meticulousness of those compiling the operating system, hoping they disable every vulnerability. And in the end, there's less freedom for the user, when you depend on other people's keys.
From: (Anonymous)
Or probably better just a flip switch/jumper on the board (flashable/unflashable mode) - this is something manufacturers would go for.
I really do not see a problem with this. If at the end of the day you can flash the bios directly, then there is no point to thinking of it in a physical security sense. If someone has access to the system it is insecure. Therefore, you could also just write the firmware password on the motherboard or on a sticker on the PC, and then have the user change it at their will.

I believe that we should be completely discounting Linux on SecureBoot, this is 2012, we should not be thinking of it as a "hack your system and install linux" or a follow the rules set out by verisign (who are as bad as Microsoft btw) and Microsoft. This is like buying an iPhone with the intention to run Android.... You intend to use Linux from the offset, so getting manufacturers to realize we won't buy anything we don't own if the best policy.

If you are thinking in the mentality of a user being able to download Linux take it to their local library and boot into Linux instead of Windows - this is never going to happen. Or if you are thinking there are users who are incapable of disabling SecureBoot who will be capable to know how to boot it on their system, they do not exist. These users will most likely be using iPads or in the future windows on arm. Companies using Linux will be able to create their own sets of keys/disable secure boot.

You need to forget about this and start concentrating on people buying free software/open computers with Linux pre-installed.

I for one will be moving away from using Fedora if it starts to support this structure of hierarchical forced trust. This would include even a Fedora or free software signing key.

EFI is horrible, just see how much so.

Date: 2012-06-06 10:07 pm (UTC)
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

Re: EFI is horrible, just see how much so.

Date: 2012-06-07 05:03 pm (UTC)
From: (Anonymous)
I don’t watch talks – they’re usually a huge waste of time considering my reading speed, *if* I understand them at all, considering the crass difference between my reading/writing and talking/listening English language skills (English is neither my first nor my second human language, after all).

So, please get us standalone slides, a paper, a blogposting, whatever instead. A medium allowing us to peruse the content at our own speed and by plain text.

(Not even *trying* OpenID this time…)

Google will disagree with you for now

Date: 2012-06-06 10:19 pm (UTC)
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.

Re: Google will disagree with you for now

Date: 2012-06-07 12:43 am (UTC)
From: (Anonymous)
I don't speak for Google either, but developing a custom-software product where you can port your own firmware to a _known_ set of hardware is _very_ different to doing an open-source firmware that is expected to run on all sorts of random systems.

Doing a firmware port can be quite messy, and it requires intimate knowledge of the chipset AND board, including schematics, etc. Sure, it can be reverse engineered from whatever is already there, but in general it would be a 100% reactive project, always having to scramble and fixup things when the vendor does a small hardware modification, etc. Not exactly something that end users can rely on.

Keep in mind that the BIOS is where _all_ the PC manufacturers hide the abstractions to all the crazy stuff they do on hardware, including all the bug workarounds. They can change hardware in the middle of a production run because they can coordinate a firmware that goes on those specific machines, etc. So it'll be a constant churn trying to deal with all of that.

Re: Google will disagree with you for now

Date: 2012-06-07 10:45 am (UTC)
From: (Anonymous)
Open source under which license? This sounds eerily like what the anti-tivoization clause in GPLv3 should prevent...

For me, this probably means I'll only buy coreboot-supported motherboards from now on, and will return them to the store if flashing the firmware fails.

Re: Google will disagree with you for now

Date: 2014-02-18 07:34 pm (UTC)
From: (Anonymous)
BSD

Small correction

Date: 2012-06-06 11:13 pm (UTC)
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.

Why hasn't Red Hat gone to the DOJ?

Date: 2012-06-06 11:29 pm (UTC)
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?

Re: Why hasn't Red Hat gone to the DOJ?

Date: 2012-06-07 08:36 am (UTC)
From: (Anonymous)
> Why isn't anyone screaming bloody murder right now?

Oh man they *DID* scream bloody murder by everyone involved trusted what Microsoft said about not preventing anyone to have more than one key or disabling secure boot.

Of course the latter does not solve the problem, the former does mean "not preventing" is going to be "going out of one's way to make sure nobody is widely including another key".

Re: Why hasn't Red Hat gone to the DOJ?

Date: 2012-06-07 08:53 am (UTC)
doldonius: (Default)
From: [personal profile] doldonius
Believed MS? Just how old exactly were they back then, 4?

Re: Why hasn't Red Hat gone to the DOJ?

Date: 2012-06-07 03:45 pm (UTC)
From: (Anonymous)
I have seen a lot of people getting upset about it, but I haven't really seen any official comments from corporations. I believe (and I could be wrong) that this issue will be a of huge importance in the future. However, once the damage is done, it will be a bit late to complain.

Seriously?

Date: 2012-06-07 01:45 pm (UTC)
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..."

Flame

Date: 2012-06-07 03:32 pm (UTC)
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

People are stupid as usual

Date: 2012-06-08 05:03 pm (UTC)
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.

Re: People are stupid as usual

Date: 2012-06-08 11:14 pm (UTC)
From: (Anonymous)
Yes, you can delete that one, I was replying to you and I reposted it below.

Re: People are stupid as usual

Date: 2012-06-08 11:19 pm (UTC)
From: (Anonymous)
An you mean the wrong thread... indeed. A day at work can do that to a man. Never mind, the only important part is that you've read it.

delete the duplicate please

Date: 2012-06-08 05:08 pm (UTC)
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.

UEFI key management application

Date: 2012-06-09 10:10 am (UTC)
From: [identity profile] 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.

Re: UEFI key management application

Date: 2012-06-11 06:11 pm (UTC)
From: (Anonymous)
Instead of the Linux Foundation, perhaps the organization could be CAcert? I would think it would be a matter of persuading the OEMs to include the CAcert root keys in the default list. CAcert is a non-profit certificate authority that uses a worldwide web-of-trust model to verify identities. You can sign up as a community member for free, have your identity verified by their assurers at no cost, and then sign all the distros you want.

Why not just use coreboot?

Date: 2012-06-15 09:14 pm (UTC)
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..

Re: Why not just use coreboot?

Date: 2012-06-16 04:11 am (UTC)
From: (Anonymous)
If that's the case then the chip must have restricted write access, which doesn't surprise me. Couldn't you then at least extract the ROM and flash it to a different chip? A chip that doesn't have Secure Boot enabled? Perhaps even try to reverse engineer the firmware directly and strip out the secure boot code? DRM such as SecuROM (much often used in video games) uses SSL and many other forms of cryptography, the same types you have mentioned before. People modify the .exe files at assembly level to remove the DRM from the executable. Perhaps the same thing could potentially be done for Secure Boot? Reverse-engineering such code is not an easy task at all however some (Coreboot) developers can make sense out of some of the compiled assembly instructions from the BIOS.

Obviously not everybody would be soldering their boards left and right to replace the chips but perhaps some progress? At least the deep inter-workings of Secure Boot would be figured out (if this could be done.)

Profile

Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Nebula. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Expand Cut Tags

No cut tags