Security: Difference between revisions
Line 8: | Line 8: | ||
* Signature verification - option to boot from payload only signed images | * Signature verification - option to boot from payload only signed images | ||
[[Bayou]] / [[coreinfo]] / [[GRUB2]] have "BIOS password"-like feature, using SHA-1 hashes stored in NVRAM or the (flash) ROM chip. | [[Bayou]] / [[coreinfo]] / [[GRUB2]] have "BIOS password"-like feature, using SHA-1 hashes stored in NVRAM or the (flash) ROM chip. | ||
GRUB2 can also do signature verification of on-disk operating systems. | GRUB2 can also do signature verification of on-disk operating systems. [[TianoCore]] could probably be adapted to support either, too. | ||
Both features are in the payload domain since coreboot doesn't provide a user interface. | |||
* RAM wiping after each boot | * RAM wiping after each boot | ||
This is not very useful: The most interesting time would be right before power-off, which could be implemented in [[SMM]]. Unfortunately a cautious attacker just pulls the plug. | |||
To prevent reading data after a reboot, a payload could be adapted to clean out memory. Using applications that manage sensible data sensibly (ie. wipe after use) is still a better solution. | |||
* Support booting from encrypted block devices/volumes | * Support booting from encrypted block devices/volumes |
Revision as of 15:26, 4 May 2014
This page explains how coreboot can help with various security aspects of your system, compared to closed-source, legacy BIOS/EFI/firmware implementations.
Common security features
- Boot password (like BIOS password)
- Signature verification - option to boot from payload only signed images
Bayou / coreinfo / GRUB2 have "BIOS password"-like feature, using SHA-1 hashes stored in NVRAM or the (flash) ROM chip. GRUB2 can also do signature verification of on-disk operating systems. TianoCore could probably be adapted to support either, too.
Both features are in the payload domain since coreboot doesn't provide a user interface.
- RAM wiping after each boot
This is not very useful: The most interesting time would be right before power-off, which could be implemented in SMM. Unfortunately a cautious attacker just pulls the plug.
To prevent reading data after a reboot, a payload could be adapted to clean out memory. Using applications that manage sensible data sensibly (ie. wipe after use) is still a better solution.
- Support booting from encrypted block devices/volumes
GRUB2 can do that.
Current BIOS issues
RAM wiping
- http://citp.princeton.edu/memory/
- Coreinfo as demo payload for coreboot, showing your RAM contents after a cold boot.
SMI issues
- http://www.ssi.gouv.fr/fr/sciences/fichiers/lti/cansecwest2006-duflot.pdf
- http://tracker.coreboot.org/trac/coreboot/ticket/42
ATA issues
- http://coreboot.org/pipermail/coreboot/2005-May/011686.html
- http://www.heise.de/ct/english/05/08/172/
Firewire issues
- http://md.hudora.de/presentations/firewire/
- http://www.hermann-uwe.de/blog/physical-memory-attacks-via-firewire-dma-part-1-overview-and-mitigation