Security/From trustworthy flash to trustworthy OS: Difference between revisions

From coreboot
Jump to navigation Jump to search
(WIP security howto)
 
(fix spelling)
Line 1: Line 1:
{{stub}}
== Work in progress ==


This is a work in progress and is not finished yet.
This tutorial a work in progress and is not finished yet.


== From trustwrothy flash to trustworthy OS: ==
== From trustworthy flash to trustworthy OS: ==
Once you succesfully flashed a coreboot image that corresponds to its source code,
Once you successfully flashed a Coreboot image that corresponds to its source code,
there is again an issue of chicken and egg when wanting to install an opearting system.
there is again an issue of chicken and egg when wanting to install an operating system.


An easy way to deal with it is to make the boot firmware verify the checksums
An easy way to deal with it is to make the boot firmware verify the checksums
Line 11: Line 11:
- Verifying the checksum of an image that is installed on a storage device
- Verifying the checksum of an image that is installed on a storage device
   is not very reliable due to a variety of factors such as:
   is not very reliable due to a variety of factors such as:
   - live-usb creation software not copying the image as-is on the usb device.
   - live-usb creation software not copying the image as-is on the USB device.
   - The usb storage device having a different size than the image.
   - The USB storage device having a different size than the image.
   - USB storage device firmwares being untrustworthy, and can potentially do
   - USB storage device firmwares being untrustworthy, and can potentially do
     TOCTOU attacks, making checksums useless.
     TOCTOU attacks, making checksums useless.
Line 25: Line 25:


== Checksums verification with iPXE and SeaBIOS: ==
== Checksums verification with iPXE and SeaBIOS: ==
This is the most straingtforward way since iPXE supports computing sha1 checksums
This is the most straightforward way since iPXE supports computing sha1 checksums
with its "sha1sum" command.
with its "sha1sum" command.
The user will then download the installer image trough ipxe (the image will
The user will then download the installer image trough iPXE (the image will
then be stored inside the target computer's RAM) and run sha1sum on that image.
then be stored inside the target computer's RAM) and run sha1sum on that image.


The most straingtforward way to use it, is to add SeaBIOS as payload, and iPXE
The most straightforward way to use it, is to add SeaBIOS as payload, and iPXE
as an option rom.
as an option rom.


Line 38: Line 38:
   In laptops the option roms are usually in the boot firmware, and since we are rewriting
   In laptops the option roms are usually in the boot firmware, and since we are rewriting
   the boot, there should be no case where SeaBIOS loads an option rom from a device.
   the boot, there should be no case where SeaBIOS loads an option rom from a device.
* An ethernet card supported by iPXE. This tutorial doesn't deal yet with the wifi
* An Ethernet card supported by iPXE. This tutorial doesn't deal yet with the WiFi
   cards supported by ipxe (They require additional configuration).
   cards supported by iPXE (They require additional configuration).


=== SeaBIOS ===
=== SeaBIOS ===
Line 45: Line 45:
to only allow it to execute iPXE.
to only allow it to execute iPXE.


To produce a configuration that fits, download SeaBIOS, select the option to build it for coreboot,
To produce a configuration that fits, download SeaBIOS, select the option to build it for Xoreboot,
and then unselect the options loading code externally. then produce a minimal configuration with:
and then un-select the options loading code externally. then produce a minimal configuration with:
  $ make savedefconfig
  $ make savedefconfig
The configuration file will then be called defconfig.
The configuration file will then be called defconfig.
Line 105: Line 105:
The following payload may be able to fit but were not checked.
The following payload may be able to fit but were not checked.
- Tinaocore: Since UEFI has signature checking, it might be
- Tinaocore: Since UEFI has signature checking, it might be
   possible to make tianocore load a signed installer or use
   possible to make Tianocore load a signed installer or use
   a signed bootloader to check hashes.
   a signed bootloader to check hashes.
   Having a self-contained installer image can prevent many of
   Having a self-contained installer image can prevent many of
   the shortcommings of the checksums verifications mentioned
   the shortcomings of the checksum verification mentioned
   at the beginning.
   at the beginning.
- Depthcharge could potentially be used for general purpose
- Depthcharge could potentially be used for general purpose
   OS recovery or installation since it supports signature
   OS recovery or installation since it supports signature
   checking.
   checking.

Revision as of 23:30, 8 September 2016

Work in progress

This tutorial a work in progress and is not finished yet.

From trustworthy flash to trustworthy OS:

Once you successfully flashed a Coreboot image that corresponds to its source code, there is again an issue of chicken and egg when wanting to install an operating system.

An easy way to deal with it is to make the boot firmware verify the checksums of the OS installer. This however has several issues: - Verifying the checksum of an image that is installed on a storage device

 is not very reliable due to a variety of factors such as:
 - live-usb creation software not copying the image as-is on the USB device.
 - The USB storage device having a different size than the image.
 - USB storage device firmwares being untrustworthy, and can potentially do
   TOCTOU attacks, making checksums useless.

Coreboot supports many payloads. Since this is payload-specific, there is the need of having one section per payload.

Since we will diverge from the default configurations, a recovery mechanism is required. The best way is to have an external flash programmer. Using the fallback recovery mechanism could also be used as an alternative, but it is less safe than an external flash programmer.

Checksums verification with iPXE and SeaBIOS:

This is the most straightforward way since iPXE supports computing sha1 checksums with its "sha1sum" command. The user will then download the installer image trough iPXE (the image will then be stored inside the target computer's RAM) and run sha1sum on that image.

The most straightforward way to use it, is to add SeaBIOS as payload, and iPXE as an option rom.

Requirements

  • Ideally the target computer shouldn't have devices with untrustworthy option roms,
 since SeaBIOS would load and run them.
 In laptops the option roms are usually in the boot firmware, and since we are rewriting
 the boot, there should be no case where SeaBIOS loads an option rom from a device.
  • An Ethernet card supported by iPXE. This tutorial doesn't deal yet with the WiFi
 cards supported by iPXE (They require additional configuration).

SeaBIOS

Since SeaBIOS tend to execute code from a variety of sources, care must be taken to only allow it to execute iPXE.

To produce a configuration that fits, download SeaBIOS, select the option to build it for Xoreboot, and then un-select the options loading code externally. then produce a minimal configuration with:

$ make savedefconfig

The configuration file will then be called defconfig. Copy it to the coreboot source tree as seabios_defconfig

Alternatively you can create the seabios_defconfig file with the following content:

# CONFIG_USB is not set
# CONFIG_SERIAL is not set
# CONFIG_LPT is not set
# CONFIG_DRIVES is not set
# CONFIG_MOUSE is not set

This works at the time of writing and may need to be updated later.

Then pass the path of the seabios configuration file to coreboot with the "() SeaBIOS config file" option which appears in the payload section, when selecting SeaBIOS.

"SeaBIOS config file" looks by default in the mainboard directory, with "seabios_defconfig" it will look in:

"$(top)/src/mainboard/$(MAINBOARDDIR)/seabios_defconfig"

Since we have put the file inside coreboot's top directory we will prepend the path with "../../../". It will then look like that:

(../../../seabios_defconfig) SeaBIOS config file

= iPXE with checksum verification

To build ipxe with checksums run the following:

$ cd src
$ echo "#define DIGEST_CMD" > config/local/general.h
$ make bin/<pci-ids>.rom

Replace <pci-ids> by the PCI ids of your NIC. They can be found by using "lspci -nn" Here's an example for a specific intel card:

$ make bin/8086100e.rom

Running it

Getting the sha1sum

First, we need the sha1sum of the image.

http://mirror.fsf.org/trisquel-images/sha1sum.txt has:

d2205ac3d09343339831fa5da8d8e0fabd78a6e9  trisquel-netinst_7.0_i686.iso

That checksum can be independently verified on different computers, and then written down.

On a given computer it can for instance be checked with:

$ wget http://mirror.fsf.org/trisquel-images/sha1sum.txt.asc
$ wget http://mirror.fsf.org/trisquel-images/sha1sum.txt
$ gpg --verify sha1sum.txt.asc

Actually verifying the image on the target

In iPXE, setup the network:

dhcp

Then download the image:

imgfetch -n trisquel http://mirror.fsf.org/trisquel-images/trisquel-netinst_7.0_i686.iso

Then

image download and verification

GRUB:

Grub supports checking signatures, but to prevent TOCTOU attacks, it must be made mandatory.

Other possible payloads:

The following payload may be able to fit but were not checked. - Tinaocore: Since UEFI has signature checking, it might be

 possible to make Tianocore load a signed installer or use
 a signed bootloader to check hashes.
 Having a self-contained installer image can prevent many of
 the shortcomings of the checksum verification mentioned
 at the beginning.

- Depthcharge could potentially be used for general purpose

 OS recovery or installation since it supports signature
 checking.