Need help with travel-laptop?
Click the “chat” button below for chat support from the developer who created it, or find similar developers for support.

About the developer

CrowdStrike
209 Stars 22 Forks 3 Commits 1 Opened issues

Description

Auxiliary documentation and scripts around "A Reasonably Safe Travel Burner Laptop"

Services available

!
?

Need anything else?

Contributors list

A Reasonably Secure Travel Laptop Setup

This repository contains auxiliary scripts and configurations around building a reasonably secure travel laptop using coreboot with a GRUB2 payload. The scripts and configurations have been tested with an ArchLinux setup but should be adaptable to other distributions easily.

A reasonably secure travel laptop following the approach laid out here will boot only a signed kernel and initrd and assure user-space integrity with a dm-verity protected root filesystem. If you require confidentiality, it is additionally recommended encrypted the entire filesystem or use a separate, encrypted

/home
partition.

Building coreboot and GRUB2 for your target laptop and flashing the appropriate image is out of the scope of this repository's contents and documentation. You can find more information on the coreboot Wiki. You can find a preliminary coreboot review branch that measures platform state into TPM PCRs in gerrit changeset #14038 (click the Download drop-down to get a URL usable in

git checkout
).

Involved Components

The resources contained in this repository are used in the boot chain as follows: - A GRUB2 configuration file is embedded into a GRUB2

memdisk
on the SPI Flash itself. It serves as the root of the chain of trust and loads the signing key from the GRUB2
memdisk
, transitions the GRUB2
root
to the boot device / partition and hands over to a signed GRUB2 configuration there. - The GRUB2 configuration on the boot device/partition loads the Linux kernel and initrd or whatever other payload you want to load. It will provide the dm-verity root hash to the initrd, which in turn assigns it to the
dm-verity
device. Because this configuration is signed, the
dm-verity
root hash is signed and transitively the root filesystem is authenticated. - Because a
dm-verity
root filesystem must be read-only and is not supported by most distributions' generic initrd generation scripts, a special set of scripts to support a
tmpfs
backed overlayfs mounted from the initrd and intializing the
dm-verity
device with the right root hash is required. This set of scripts will hook into the
mkinitcpio
script on ArchLinux, it must be adapted for other distributions to generate an initrd compatible with this setup. - When built with a measuring coreboot, you can deploy TPM remote attestation as a OpenSSH enforced public key command to deny logging in from an untrusted device. Two simple programs that implement remote attestation and verification againts a trusted set of PCR values can be found in
tpm-attest/
.

GRUB2 Configuration in SPI Flash

The initial GRUB2 configuration to be loaded from the SPI flash is used to kick off a more accessible but signed configuration from the boot device/partition. An examplary script that loads a signing key from the GRUB2

memdisk
is provided in this repository under
grub-cfg/memdisk-grub.cfg
.

Generally, it is recommended to create a directory representing the additional memory disk contents of GRUB2 and invoking

grub-mkstandalone
from there: - Create an empty directory representing your
memdisk
somewhere and change to that directory. - Copy
grub-cfg/memdisk-grub.cfg
to
boot/grub/grub.cfg
relative to the
memdisk
base directory, adjust it to your needs. - Export your signing public key to
boot/${keyid}.gpg
and fix the path in the
grub.cfg
- Invoke
grub-mkstandalone
from the
memdisk
base directory as follows to create a coreboot payload image with the appropriate
memdisk
contents:
grub-mkstandalone -O i386-coreboot -o ../grub_coreboot_payload.elf --compress=none --themes='' --locales='' boot/grub/grub.cfg boot/${keyid}.gpg

You can now reference

../grub_coreboot_payload.elf
as ELF payload in the coreboot
Kconfig
to be directly built in or alternatively add it manually with
cbfstool
.

GRUB2 Configuration on boot device/partition

When using a GRUB2 configuration in SPI flash derived from

grub-cfg/memdisk-grub.cfg
, signature verification of the kernel and initrd will be mandatory already. Your configuration merely has to load the kernel with the correct command line and reference the right initrd.

The initrd scripts in this repository understand the following command line options: -

overlay_verity_dev
: device name for the device containing the dm-verity hash tree, created with
veritysetup
. If you just want to test a read-only root filesystem with a
tmpfs
backed
overlayfs
, set this to anything and do not specify the
overlay_verity_root
option on the command line. -
overlay_verity_root
: the root hash of the dm-verity hash tree on the device provided in
overlay_verity_dev
. This will activate actual root filesystem block integrity checking. -
root
: as usual, this is the root filesystem backing device, which will then be read-only and integrity protected.

An exemplary configuration file can be found in

grub-cfg/bootdrive-grub.cfg
.

mkinitcpio Hook

To generate an initrd/initramfs/initcpio that initializes dm-verity and creates a

tmpfs
backed
overlayfs
around it, a hook for
mkinitcpio
is required. This hook is provided within
etc-initcpio/
, simply copy the directory contents to your
/etc/initcpio
directory and add the
overlay_verity
hook to your
/etc/mkinitcpio.conf
in the
HOOKS
array after the
filesystems
hook. If you have a
fsck
hook, be sure to remove it as it will tamper with the root filesystem's on-disk header and cause verification failures.

TPM Remote Attestation

When booting with a coreboot build in which measuring of platform components has been enabled, the different stages of the boot process up to and including the RSA key used for signing the GRUB2-loaded components (see above) are hashed. These hashes are then stored in a hash-chain in the TPM chip of the target device and cannot simply be tampered with after booting.

You can then deploy the code from

tpm-attest/
to a trusted OpenSSH server to securely verify the platform state after booting. The server will issue a request including a random nonce (see for example
tpm-attest/doc/examples/request.json
). The client will sign the nonce and it's current PCR state on the TPM chip and provide back an attestation blob for the server (see for example
tpm-attest/doc/examples/quote.json
. Only if the PCR contents contain the expected values will the shell wrapper spawn a valid shell for the client.

This way, you can travel with zero critical information and only a travel SSH authenticationon key on your travel laptop into your destination country. You can then download any additional information over an encrypted and authendicated connection, however the server will only let you access this data if the device you are connecting from can prove that it is in a known-good boot chain state.

Step-by-step Setup

  1. First, install ArchLinux (or one of its derivatives, such as BlackArch) on your target devices internal drive, ensure to have a separate
    /boot
    partition. Make sure that you have all your tools and your root filesystem is ready to be frozen. At this point, you should also have set up any encrypted
    /home
    partitions and similar.
  2. Make sure you have installed the mkinitcpio hook from this repository and your initrd/initramfs/initcpio has been updated with
    mkinitcpio
    . Double check with
    lsinitcpio
    that a module for your root filesystem (for example
    ext4.ko
    ) is present.
  3. Now it is time to flash the coreboot and GRUB2 image onto your device's SPI flash. Make sure you can disable signature verification for the setup step by using the GRUB2 command line and entering
    set check_signature=''
    ; this will require posessing the PBKDF2 superuser password, see
    grub-cfg/memdisk-grub.cfg
    .
  4. Load your operating system with a read-only root and a fake
    overlayfs
    by providing a command line containg
    overlay_verity_dev=y
    but no
    overlay_verity_root
    option.
  5. You can now populate the dm-verity hash tree on the appropriate device using
    veritysetup format
    . Be sure to copy the root hash!
  6. Update your boot device
    grub.cfg
    by providing the real
    overlay_verity_dev
    you just populated and setting the root hash with
    overlay_verity_root
    .
  7. Sign your boot device
    grub.cfg
    , the kernel and the initrd/initramfs/initcpio using
    gpg --detach-sign
    (optionally specify the right signing key with
    --local-user
    ).
  8. Optionally deploy
    tpm-attest/
    to an trusted OpenSSH server.

We use cookies. If you continue to browse the site, you agree to the use of cookies. For more information on our use of cookies please see our Privacy Policy.