> your attached comments may have been stripped by the mailing list. I did > receive them via direct email, but you may want to upload them somewhere > so others on this list can comment.
I'll just share the Docs link so anyone interested can request access: https://docs.google.com/document/d/1qcufI1zbXBGVh9S8qHwPFRXasHXUHbfp9jpRz4L27PI > > I'll be on a plane Monday/Tuesday, but I can try to do that later next > > week — I hope that will still be in time? > > I think so, yes. We should try to get this done in a call next week and > then submit the comments during or immediately after the call. Please > mail me directly with your availability so we can try to schedule a call. Great, yeah, let's do that. I'll be available Wed/Thu/Fri afternoon and evening (German time) next week, let me know what works for you. > To jumpstart the dicusssion, let me try to reply to a few larger topics > you seemed to focus on. (Admittedly my reply is not structured in a way > which would be fit for submission. I tried to do this in a few hours and > cover multiple topics.) I should probably start by explaining some differences between the way UEFI Secure boot generally works and the way the verification systems on Chromebooks and many smartphones tend to work, because I think that's at the core of many of these issues — that the standard seems to be written with the assumption that firmware verification is always done the same way and many details in the requirements don't really make sense for different styles of verification and update systems (which may have equivalent or at least different but not necessarily worse security guarantees, that focus more on the kinds of attacks that are important for that particular device type). On a UEFI PC, as I understand it (admittedly not that familiar with those systems), you tend to have a SPI flash that's not particularly protected by hardware, hooked up to an x86 CPU. The first firmware component that boots from that flash (which may or may not be covered by BootGuard) will then use a root key (also stored on that flash, but not covered by BootGuard?) to verify all other components as they are loaded. Those components may come from a wide variety of different vendors that each have their own signing and release process (and might even be updatable independently?), so they're each signed by a different certificate authority and there needs to be a certificate hierarchy from these authorities to the root key. At some point, the firmware will lock write access to the flash until the next reboot by writing to flash protection registers in the PCH, to prevent an attacker in the OS from modifying the firmware. If there's an update, the update needs to be placed in a special (always writable) space on the flash by the OS, which the firmware will then pick up during the next boot, verify with its certificates, and then copy to the right location where it will actually start being used. On a Chromebook or a smartphone, things tend to work very differently. The firmware may be stored on SPI flash or another medium (e.g. eMMC/UFS disk). The SoC usually does not have SPI flash protection registers that can block out access. Instead, the first firmware stage is often write-protected on the medium itself (via hardware pin for SPI flash, or permanently on eMMC/UFS). This write protection can never be removed during normal operation (it might require opening the case, or it may not be possible at all). It may or may not additionally be verified by a ROM mechanism with fused keys comparable to BootGuard. This first stage contains a root key in the write-protected part and uses that to verify the later firmware stages that are stored in an unprotected part of the flash (where there are often two slots for A/B updating). The write-protected part also often contains some kind of "recovery firmware" that is automatically entered if verification of the unprotected firmware components (or later the OS) fails, and can then be used to reinstall those components from an external medium. Updates do not involve the firmware itself at all, instead the operating system can directly write the update to the unprotected firmware slot, and it will be verified as part of the next boot. These firmwares also tend to be built, signed and bundled for update by a single entity (the device manufacturer) in one go, so there's no real need for certificate hierarchies because there's only one certificate authority. (They also often don't use x509 certificates at all and instead use other, custom data formats for their root key and signatures.) Both of these schemes have their advantages and disadvantages. The UEFI scheme allows replacing the first firmware stage (at least if it doesn't use BootGuard) and the root key with an automatic update — the other scheme doesn't allow this at all, or only with physical intervention (opening the case and removing write-protection). However, the UEFI scheme is also very vulnerable to persistent exploits (and AFAIK there are plenty of examples where this has happened in practice), because if you just get a code execution vulnerability once while the SPI flash is still unprotected, you can compromise the device forever. The whole "capsule update in firmware" mechanism also tends to be pretty complicated and adds a lot of code to the most trusted computing base, whereas hardware write-protection solutions can get away with a very simple first stage that basically only needs to do the crypto itself to verify the updateable part and jump to it (which reduces risk and improves security). Both options also depend on different hardware features that aren't available on all platforms. > - The whole signing/verification scheme seemed to irk you a lot. AFAICS > the requirements for replacable certificate hierarchies are designed to > address one problem: A machine may ship with UEFI and trust the > mainboard vendor's CA as well as a Microsoft CA to authenticate any code > that gets run by the firmware or boot loader. The user (or admin) may > want to not trust Microsoft and instead replace the Microsoft CA with > another more trusted CA, possibly a CA controlled by the user. When > refurbishing/recycling this machine, there needs to be an option to undo > this CA change and/or replace the first user's preferred CA with the > second user's preferred CA, subject to some robust controls so an > attacker cannot do it without consent from the owner. There is a very fundamental problem here that doesn't have a real solution to my knowledge about balancing the protection against physical attacks with the ability to replace top-level key material. The kind of UEFI system that I described above which can replace the root key via a capsule update cannot be made secure against opening the case and overwriting the flash with an external programmer (dediprog). If you try to use a mechanism like BootGuard to fix that, then either BootGuard verifies the root key on flash and so you cannot update it, or it doesn't and then it doesn't actually add any security. If BootGuard also uses PKI to verify the first firmware stage and root key (so that you could sign the new root key so that BootGuard would accept it), then you're really just moving the meaning of where your real "root key" is one layer up but you're still having the same problem (needing to trust the authority that owns the BootGuard key). There may also be solutions with external secure elements to try to address this but in practice you are then trusting the authority that owns the secure element instead. This is a trade-off decision that may be made differently for different device classes, but I don't think it makes sense for the EU to mandate a single answer for everything from servers to smartphones to thermostats here. For the laptop/mobile device segment, we tend to care a lot more about physical evil maid attacks and therefore value the protection against those, while key exchange just tends to not be a commonly needed feature in practice. For a server that has a much longer lifetime and always stands in a secure datacenter anyway, I can understand that priorities can be very different. But that's why I think it's important to not too broadly mandate edge-case features like this for vast swathes of device classes. > - CA hierarchies: There have been so many compromised intermediate CAs > (usually from hardware vendors signing their drivers) used for signing > malware that it makes sense to retire an entire compromised intermediate > CA and start fresh without having to roll out a new root CA everywhere. Right, but this only happens to those UEFI-style systems I mentioned above that *have* other CAs to compromise. If my entire firmware update (and OS) always gets built and signed in total by the single entity that controls the root key anyway, then there's no need for intermediate CAs and no need for mechanisms to rotate and revoke them. So I think in many places the standard needs more Applicability restrictions to say "this requirement only applies to you when you actually have <multiple certificate authorities or other specific quality>". > - Clearing memory: If the firmware asks for a boot password and then > keeps the password (or traces of keystrokes) in memory accessible to the > operating system, an admin of the operating system can later learn > secrets which should have been restricted to the person knowing the boot > password. I absolutely understand the need for clearing secret data from memory and I'm not objecting to that. It's just that in some places the standard is written in a way that says you have to clear all "temporary buffers" or something like that, which could mean the firmware needs to always clear every single variable it uses for anything (which I think is clearly excessive and impractical, at least for MEDIUM risk devices). I think this is just a wording problem where a few places need to be adjusted to clarify that you need to clear any memory containing secrets, which should of course include cases where those secrets go through intermediate buffers like keyboard input handling, but shouldn't apply to something completely separate that has nothing to do with secret handling (e.g. the disk driver). > - The whole memory-safety thing: Exploitable parsers with firmware > privileges are bad. Use a mechanism of your choice to prevent > exploitation (memory safe language, encapsulating or de-privileging the > parser, compiler features, whatever). I'm not quite sure which point you're referring to here to be honest... is this for [RQ-VULN-006]? For that one I just didn't understand what it meant at all (e.g. if you're saying that it is supposed to be related to parsers, it doesn't actually say that). If there is supposed to be a requirement to specially protect parsers, then it needs to clearly define what counts as a parser in that context, and it should also be restricted to parsers used on untrusted data (e.g. when I have a feature to display JPEG images but I ensure that I am only using it to display images that come from the same cryptographically verified source as all the code I'm executing, there's no reason to implement extra strong safety measures for that JPEG parser). > - Authentication: Should physical presence be sufficient authentication > for certain operations? IMHO that depends. Evil maid attacks use > physical presence and you may want to protect against them. It is > non-trivial to differentiate between a legitimate wish to replace the > firmware and an evil maid trying to replace the firmware. It doesn't get > easier if someone installed their own coreboot on a chromebook and wants > protection against evil maid attacks, including evil maid attacks > reverting the firmware to the factory-delivered version. This is > probably one of the harder problems requiring significant effort to get > it right and document the implications of the solution/solutions. Right, exactly, it depends, but that means that this standard cannot just declare a blanket solution for everyone. I don't think it's reasonable to demand password protection for debug features for every single smartphone, thermostat, etc. because they all have entirely different use cases, user interfaces, etc. We actually do spend a lot of time thinking through these kinds of problems for our devices and how to best strike the trade-offs between keeping our users secure and making things practical for them, a lot more than any regulation body could possibly spend when drafting a standard for all kinds of devices at once. So I think for some of these things you just have to give the manufacturers a bit more rope to decide what works best for their case. > - Some requirements being too strict: The idea is to have a risk-based > approach and apply stricter requirements to higher-risk uses. If you see > a requirement which arguably is unnecessary for the general use case, > you can try to get it moved as a requirement only for higher-risk uses. Yeah, I think the key exchange requirement, all the secure logging stuff and the multiple algorithm stuff would probably be good candidates for moving up the HIGH tier. On the other hand, I'm quite surprised that rollback protection is only a requirement for HIGH tier right now. That seems like a very important and very basic requirement that has been an industry standard for many years, so I'd expect it to be required in at least MEDIUM tier. > - Having to verify code before flashing if code is verified before > execution anyway: If you don't verify before flashing and only before > execution, you may have created a DoS attack. For the kinds of Chromebook/smartphone systems I've described above, this is not really a practical problem. Anyone who can overwrite or erase the unprotected parts of the firmware flash can also overwrite or erase the operating system from the disk and create a denial of service that way. Those systems tend to have some sort of recovery feature implemented exclusively in the permanently write-protected part of the flash to allow the user to recover from such an attack. > - Vague wording: A few things in the standard would benefit from > explanations along the lines of "why is this a problem" or "why do we > want this solution" to help people understand the rationale and/or > improve the requirements and/or suggest something should be scrapped. Right, but I think there are a lot of issues with not clearly defined or too narrow terminology, too. For example, we're using the terms "certificate", "certificate authority", etc. when discussing things here, but those terms don't actually apply to our kinds of systems. We do not use x509 certificates to store our key materials, we have custom data formats and we just use the terms "root key", "intermediate key", "signer" and so on. It's easy enough for me to translate the UEFI lingo to the equivalent in our system most of the time, but for a legally binding document, I think the language needs to be a lot more clear (e.g. in the glossary in section 3.1, "certificate" could be defined to "any data structure containing a public key, usually with an attached signature signed by a higher-order private key" or something like that). The document is also talking about signatures a lot but not all verification systems actually use PKI signatures — it's possible (with the right hardware support) to build a verification system that uses only hashes, and a pre-shared secret key that is known to the update server and stored in the device in a way that can only be used (enforced by hardware) to verify HMACs, but not read out in cleartext. The standard actually acknowledges this style of verification system in section 4.3.1.2 but then a lot of the requirements seem to be written with the assumption that everything uses PKI (or at least using that sort of terminology). _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
