Coreboot and the NSA's expressed preference for subverting BIOSes
As proposed by Der Spiegel at http://www.spiegel.de/international/world/catalog-reveals-nsa-has-back-doors... the NSA seems to be interested in subverting BIOSes, lower-level disk roms and the like. May I request you loudly announce how one checksums one's coreboot, and in principle other BIOSes, so that one can see if anyone has changed firmware critical to one's security. --dave -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain (416) 223-8968
On Sun, Dec 29, 2013 at 5:06 PM, David Collier-Brown <davecb.42@gmail.com>wrote:
May I request you loudly announce how one checksums one's coreboot, and in principle other BIOSes, so that one can see if anyone has changed firmware critical to one's security.
Depends... In general this is not done by the firmware at all. Instead, one would either read the system firmware ROM using an independent microcontroller before taking the system out of reset, or after the system has booted by using a tool such as flashrom (http://www.flashrom.org) to read the firmware ROM and then perform the checksum on the output binary. Most systems don't have the microcontroller necessary for the former, and the latter can be tricked with sufficient effort. There are many practical considerations to each approach. For Chromebooks, full verification is built into coreboot and also utilizes hardware write-protection to ensure there is always a trusted read-only copy of the firmware that is run when the machine is turned on. Any field updateable portions of the firmware are verified before being run. A detailed overview is available here<http://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot-cry...>, and the code is open-sourced and can be adapted to other (non-Chromebook) platforms. I'm am not certain about other secure boot mechanisms out there, but AFAIK they are usually intended to verify the payload (bootloader, OS kernel, etc) rather than the firmware itself. They're pretty much all closed-source, so unless you have a license to the source code you really can't know if they do what you want or that the security model is not easily broken. Hope that helps to answer your question.
participants (2)
-
David Collier-Brown -
David Hendricks