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

From coreboot
Jump to navigation Jump to search
 
(14 intermediate revisions by the same user not shown)
Line 9: Line 9:
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
of the OS installer. This however has several issues:
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:
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 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 TOCTOU attacks, making checksums useless.
* 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
Coreboot supports many payloads. Since this is payload-specific, there is the need
Line 46: Line 46:


Alternatively you can create the seabios_defconfig file with the following content:  
Alternatively you can create the seabios_defconfig file with the following content:  
  # CONFIG_USB is not set
CONFIG_COREBOOT=y
  # CONFIG_SERIAL is not set
# CONFIG_ATA is not set
  # CONFIG_LPT is not set
  # CONFIG_SDCARD is not set
  # CONFIG_DRIVES is not set
  # CONFIG_MEGASAS is not set
  # CONFIG_MOUSE is not set
  # CONFIG_FLOPPY is not set
  # CONFIG_USB_MSC is not set
  # CONFIG_USB_UAS is not set
This works at the time of writing and may need to be updated later.
This works at the time of writing and may need to be updated later.


Line 61: Line 63:
It will then look like that:
It will then look like that:
  (../../../seabios_defconfig) SeaBIOS config file
  (../../../seabios_defconfig) SeaBIOS config file
 
=== iPXE with checksum verification ===
=== iPXE with checksum verification ===
To build iPXE with checksum utilities run the following:
To build iPXE with checksum utilities run the following:
Line 72: Line 74:


=== Running it ===
=== Running it ===
==== Getting the sha1sum ====
Using iso files is problematic for our use case:
First, we need the sha1sum of the image.
* iso can be booted with the [ipxe.org/cmd/sanboot sanboot command], but checksums cannot be checked in a way that prevent TOCTOU attacks.
* iPXE supports images verification such as with [http://ipxe.org/cmd/imgverify imgverify], and that can be enforced, and so have the iso checked, but it requires the signature to be in DER format. GNU/Linux distributions tend not to produce signature in such format for the installers.


http://mirror.fsf.org/trisquel-images/sha1sum.txt has:
==== Getting the sha256sum ====
  d2205ac3d09343339831fa5da8d8e0fabd78a6e9 trisquel-netinst_7.0_i686.iso
The [http://lists.ipxe.org/pipermail/ipxe-devel/2016-September/005175.html patch] for adding the sha256sum command has been sent to [http://lists.ipxe.org/pipermail/ipxe-devel/2016-September/thread.html the iPXE mailing list].
That checksum can be independently verified on different computers,
 
and then written down.
We will use Debian in this example since it publishes kernel and initramfs images.
[http://http.us.debian.org/debian/dists/jessie/main/installer-i386/current/images/SHA256SUMS jessie/main/installer-i386/current/images/SHA256SUMS] has:
  aed809c620d36967d16f248bb1b8ebe4208aa539064a180be0c5f8cfd82ef2e0 ./netboot/gtk/debian-installer/i386/initrd.gz
97729b2938f969431e1b5c24a3f2364a4d075279fafd0d7724e66e857d467257  ./netboot/gtk/debian-installer/i386/linux
 
Write down the checksums, and verify that it's the same on different computers, internet connections, mirror, etc.
 
Ideally such checksums should somehow be verified with gpg.


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 ====
==== Actually verifying the image on the target ====
In iPXE, setup the network:
In iPXE, setup the network:
  dhcp
  dhcp
Then download the image:
Then download the files:
  imgfetch -n trisquel http://mirror.fsf.org/trisquel-images/trisquel-netinst_7.0_i686.iso
  imgfetch http://http.us.debian.org/debian/dists/jessie/main/installer-i386/current/images/netboot/debian-installer/i386/linux
After the (long) download time, we can finally check the checksum with:
imgfetch http://http.us.debian.org/debian/dists/jessie/main/installer-i386/current/images/netboot/debian-installer/i386/initrd.gz
  sha1sum trisquel
After waiting for the files to download, we can finally check the checksum with:
Then we need to boot that image. (TODO)
  sha256sum linux
sha256sum initrd.gz
Verify that the printed checksum corresponds to the checksum we wrote down earlier( aed809c620d36967d16f248bb1b8ebe4208aa539064a180be0c5f8cfd82ef2e0 and 97729b2938f969431e1b5c24a3f2364a4d075279fafd0d7724e66e857d467257 )


==== image download and verification ====
== Booting the image ==
With the following:
kernel linux
boot
the installer should boot.


== GRUB: ==
== GRUB: ==
Grub supports checking signatures, but to prevent TOCTOU attacks, it must be made
Grub supports checking signatures, but to prevent TOCTOU attacks, it must be made
mandatory.
mandatory.
We can use that to safely boot an installer:
* We would put the distribution public signing key inside the trusted boot flash.
* Then the user will enable enforcing signatures.
* To boot an installer a user would simply need to add the kenrel, initramfs and respective signatures on a boot media that grub can read, load them, and boot.


== Other possible payloads: ==
== Other possible payloads: ==
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 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.
  possible to make Tianocore load a signed installer or use
* Depthcharge could potentially be used for general purpose OS recovery or installation since it supports signature checking.
  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.

Latest revision as of 10:30, 9 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:

  • The 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_COREBOOT=y
# CONFIG_ATA is not set
# CONFIG_SDCARD is not set
# CONFIG_MEGASAS is not set
# CONFIG_FLOPPY is not set
# CONFIG_USB_MSC is not set
# CONFIG_USB_UAS 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 checksum utilities 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

Using iso files is problematic for our use case:

  • iso can be booted with the [ipxe.org/cmd/sanboot sanboot command], but checksums cannot be checked in a way that prevent TOCTOU attacks.
  • iPXE supports images verification such as with imgverify, and that can be enforced, and so have the iso checked, but it requires the signature to be in DER format. GNU/Linux distributions tend not to produce signature in such format for the installers.

Getting the sha256sum

The patch for adding the sha256sum command has been sent to the iPXE mailing list.

We will use Debian in this example since it publishes kernel and initramfs images. jessie/main/installer-i386/current/images/SHA256SUMS has:

aed809c620d36967d16f248bb1b8ebe4208aa539064a180be0c5f8cfd82ef2e0  ./netboot/gtk/debian-installer/i386/initrd.gz
97729b2938f969431e1b5c24a3f2364a4d075279fafd0d7724e66e857d467257  ./netboot/gtk/debian-installer/i386/linux

Write down the checksums, and verify that it's the same on different computers, internet connections, mirror, etc.

Ideally such checksums should somehow be verified with gpg.

Actually verifying the image on the target

In iPXE, setup the network:

dhcp

Then download the files:

imgfetch http://http.us.debian.org/debian/dists/jessie/main/installer-i386/current/images/netboot/debian-installer/i386/linux
imgfetch http://http.us.debian.org/debian/dists/jessie/main/installer-i386/current/images/netboot/debian-installer/i386/initrd.gz

After waiting for the files to download, we can finally check the checksum with:

sha256sum linux
sha256sum initrd.gz

Verify that the printed checksum corresponds to the checksum we wrote down earlier( aed809c620d36967d16f248bb1b8ebe4208aa539064a180be0c5f8cfd82ef2e0 and 97729b2938f969431e1b5c24a3f2364a4d075279fafd0d7724e66e857d467257 )

Booting the image

With the following:

kernel linux
boot

the installer should boot.

GRUB:

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

We can use that to safely boot an installer:

  • We would put the distribution public signing key inside the trusted boot flash.
  • Then the user will enable enforcing signatures.
  • To boot an installer a user would simply need to add the kenrel, initramfs and respective signatures on a boot media that grub can read, load them, and boot.

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.