When fwupd writes firmware to devices, it often writes it, then does a verify pass. This is to read back the firmware to check that it was written correctly. For some devices we can do one better, and read the firmware hash and compare it against a previously cached value, or match it against the version published by the LVFS. This means we can detect some unintentional corruption or malicious firmware running on devices, on the assumption that the bad firmware isn’t just faking the requested checksum. Still, better than nothing.
Any processor better than the most basic PIC or Arduino (e.g. even a tiny $5 ARM core) is capable of doing public/private key firmware signing. This would use standard crypto using X.509 keys or GPG to ensure the device only runs signed firmware. This protects against both accidental bitflips and also naughty behaviour, and is unofficial industry recommended practice for firmware updates. Older generations of the Logitech Unifying hardware were unsigned, and this made the MouseJack hack almost trivial to deploy on an unmodified dongle. Newer Unifying hardware requires a firmware image signed by Logitech, which makes deploying unofficial or modified firmware almost impossible.
There is a snag with UEFI capsule updates, which is how you probably applied your last “BIOS” firmware update. Although the firmware capsule is signed by the OEM or ODM, we can’t reliably read the SPI EEPROM from userspace. It’s fair to say flashrom does work on some older hardware but it also likes disabling keyboard controllers and making the machine reboot when probing hardware. We can get a hash of the firmware, or rather, a hash derived from the firmware image with other firmware-related things added for good measure. This is helpfully stored in the TPM chip, which most modern laptops have installed.
Although the SecureBoot process cares about the higher PCR values to check all manners of userspace, we only care about the index zero of this register, so called PCR0. If you change your firmware, for any reason, the PCR0 will change. There is one PCR0 checksum (or a number slightly higher than one, for reasons) on all hardware of a given SKU. If you somehow turn the requirement for the hardware signing key off on your machine (e.g. a newly found security issue), or your firmware is flashed using another method than UpdateCapsule (e.g. DediProg) then you can basically flash anything. This would be unlikely, but really bad.
If we include the PCR0 in the vendor-supplied firmware.metainfo.xml file, or set it in the admin console of the LVFS then we can verify that the firmware we’re running right now is the firmware the ODM or OEM uploaded. This means you can have firmware 100% verified, where you’re sure that the firmware version that was uploaded by the vendor is running on your machine right now. This is good.
As an incentive for vendors to support signing there are now “green ticks” and “red crosses” icons for each firmware on the LVFS. All green ticks mean the firmware was uploaded to the LVFS by the OEM or authorized ODM on behalf of the OEM, the firmware is signed using strong encryption, and we can do secure attestation for verification.
Obviously some protocols can’t do everything properly (e.g. ColorHug, even symmetric crypto isn’t good) but that’s okay. It’s still more secure than flashing a random binary from an FTP site, which is what most people were doing before. Not upstream yet, and not quite finished, so comments welcome.
Firmware signature enforcement is a BAD thing. It restricts what you as a user can do with your own device! It is the exact opposite of Free Software. As a Free Software developer, you should absolutely NOT encourage such a treacherous computing practice.
Signing isn’t always bad. Only having one signing key means you can’t flash your own code onto the device, and also means that malicious firmware can’t also be flashed. With my firmware security hat on, I think it’s perfectly fine to only accept signed images on hardware. With my free software and open hardware hats on, I’d of course want to be able to enroll my own signing key for development, or to “turn off signing” like you can on some Google Chrome devices by removing a screw from the motherboard.
So if you want to encourage firmware freedom how might you go about that in this application? Maybe an additional icon? It could be full color when the item has the ability for you to circumvent signing and greyed out + broken or slashed when you are not.
I do think this information is worthwhile. I’ll have a think and file a bug.
Nice improvements once again. However, I’m not convinced the shield system is necessarily easy to understand. The shield icon probably should at least be accompanied with a verbal description (e.g. “Security level: Medium”). Or you could drop the icons and just have the descriptions.
It’s another thing if you’re using things that are commonly understood to form an ordered set (red-yellow-green, bronze-silver-gold), but if you come up with an original scheme, prepare for users not getting it.
Thanks — you’re the second person to tell me the shields are not obvious… Have you got any other ideas? A star rating would look like a user review, and red/green is a problem for colorblind users. Thanks for the feedback, it is appreciated.
You’re right about the colourblindness issue. Also, red usually indicates that something is wrong, which wouldn’t really be the case for the lowest security level in this case, I think. (Red should more properly be reserved for the random binary from an FTP site.)
I suppose my best suggestion for icons would be stylised bronze, silver and gold shields. That might not be super obvious either, though, so I’d recommend displaying the levels as text, too (e.g. Security level: Basic/Medium/High)
I have to agree on this. I didn’t find any obvious what they meant.
Maybe simply showing Low/Medium/High or similar next to the icon does it.
Thanks!
Come to think about it, a thermometer-like icon could also be used for visualising the security level. Or a star rating, with shield or padlock icons instead of stars. These would work even without any colour information at all.
Also, it might be a good idea to not make too big of a deal of the security levels in the UI. For the average user, updating firmware through LVFS would almost always be preferable to not updating or downloading random binaries from the net. So the UI should not scare non-technical users into not updating their firmware. Technical users who are able to weigh the risks would of course be happy to see the security information.
BTW, you could also display the security information on the LVFS website for each supported device. That way people can choose to buy security-enabled hardware.
Just wanted to say I’ve had a few firmware updates come through fwupd and it’s been amazing, thanks for all the work you’ve done on this.