mirror of
https://github.com/linuxboot/heads.git
synced 2024-12-18 20:47:55 +00:00
removed old info, added link to presentatoin
This commit is contained in:
Trammell Hudson
parent
24dd8489b4
commit
73a3b6d08f
167
README.md
167
README.md
@ -12,7 +12,7 @@ to commodity hardware. Among its goals are:
|
|||||||
* Measure and attest to the state of the firmware
|
* Measure and attest to the state of the firmware
|
||||||
* Measure and verify all filesystems
|
* Measure and verify all filesystems
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
NOTE: It is a work in progress and not yet ready for users.
|
NOTE: It is a work in progress and not yet ready for users.
|
||||||
If you're interested in contributing, please get in touch.
|
If you're interested in contributing, please get in touch.
|
||||||
@ -20,6 +20,8 @@ Installation requires disassembly of your laptop or server,
|
|||||||
external SPI flash programmers, possible risk of destruction and
|
external SPI flash programmers, possible risk of destruction and
|
||||||
significant frustration.
|
significant frustration.
|
||||||
|
|
||||||
|
More information is available in [the 33C3 presentation of building "Slightly more secure systems"](https://trmm.net/Heads_33c3).
|
||||||
|
|
||||||
|
|
||||||
Building heads
|
Building heads
|
||||||
===
|
===
|
||||||
@ -49,169 +51,6 @@ of the Xen command line. Booting or installing Qubes is a bit hacky and needs t
|
|||||||
* Coreboot 4.4 does not handle initrd separately from the kernel correctly, so it must be bundled into the coreboot image. Building from git does the right thing.
|
* Coreboot 4.4 does not handle initrd separately from the kernel correctly, so it must be bundled into the coreboot image. Building from git does the right thing.
|
||||||
|
|
||||||
|
|
||||||
Threat model
|
|
||||||
===
|
|
||||||
Heads considers two broad classes of threats:
|
|
||||||
|
|
||||||
* Attackers with physical access to the system
|
|
||||||
** Customs officials, LEO, etc with brief access
|
|
||||||
** "Evil maid" attacks with longer, but still limited access (sans password)
|
|
||||||
** Stolen machines, with unlimited physical access without password
|
|
||||||
** Insider attacks with unlimited time, with password
|
|
||||||
** Insider attacks with unlimited time, with password and without regard for the machine
|
|
||||||
|
|
||||||
* Attackers with ring0 code execution on the runtime system
|
|
||||||
|
|
||||||
The first is hardest to deal with since it allows an attacker to
|
|
||||||
make physical changes to the machine. Without a hardware root of
|
|
||||||
trust and secrets stored inside that CPU, it is very difficult to
|
|
||||||
project against a physical attackers who can replace components and
|
|
||||||
fake measurements. Hardware measurements of the boot ROM (such as
|
|
||||||
Intel's Boot Guard) can help, although a dedicated attacker could
|
|
||||||
replace the CPU with one that is not fused to do the initial measurement.
|
|
||||||
The best that we can do is to lock the bootblock on the SPI flash,
|
|
||||||
perform the first measurement from it and hope that there are not any
|
|
||||||
exploits against the chip itself.
|
|
||||||
|
|
||||||
The second class is also a difficult challenge, but since it is only
|
|
||||||
a software attack, we have better hopes of handling with some harware
|
|
||||||
modifications. The SPI flash chip's boot block protection modes can
|
|
||||||
be locked on and the WP# pin grounded, which will prevent any software
|
|
||||||
attacks from overwriting that portion of the boot ROM. This gives us
|
|
||||||
a better root of trust than the EFI configurations, most of which do
|
|
||||||
not lock the boot ROM.
|
|
||||||
|
|
||||||
Even if they are not able to write to the ROM, the attackers might
|
|
||||||
be able to use their software code execution to modify the system
|
|
||||||
software or boot partition on the drive. The recommended OS
|
|
||||||
configuration is a read-only `/boot` and `/` filesystem, with
|
|
||||||
only the user data directories writable. Additional protection
|
|
||||||
comes from using dm-verity on the file systems, which will
|
|
||||||
detect any writes to the filesystem through a hash tree
|
|
||||||
that is signed by the user's (offline) key.
|
|
||||||
|
|
||||||
Updates to `/` or `/boot` will require a special boot mode,
|
|
||||||
which can be selected by the boot firmware. After the file
|
|
||||||
systems are updated, the user can sign the new hashes with their
|
|
||||||
key on a different machine and store the signed root hash on the
|
|
||||||
drive. TPM keys might need to be migrated as well for the recovery
|
|
||||||
boot mode. On next boot the firmware will mount the drives read-only
|
|
||||||
and verify that the correct key was used to sign the changes,
|
|
||||||
and the TPM should be able to unseal the secrets for TPMTOTP
|
|
||||||
as well as the drive decryption.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
|
|
||||||
dm-verity setup
|
|
||||||
===
|
|
||||||
*You must install `libdevmapper-dev`, `libpopt-dev` and `libgcrypt-dev` to build cryptsetup*
|
|
||||||
|
|
||||||
This set of tools isn't the easiest to use. It is possible to store
|
|
||||||
hashes on the device that is being hashed if some work is done ahead
|
|
||||||
of time to reserve the last few blocks or if the file system can be
|
|
||||||
resized.
|
|
||||||
|
|
||||||
The size of the hash table grows logarithmic with the size of the
|
|
||||||
filesystem. Every 4K block is hashed, and then 4K of those blocks
|
|
||||||
are hashed, and so on until there is only one hash left.
|
|
||||||
Each hash is 32 bytes, so the hash tree size is 32 * log_4096(fs)
|
|
||||||
|
|
||||||
The hashes can be stored on a separate device or on the free space
|
|
||||||
at the end of an existing partition. This will require resizing
|
|
||||||
if you didn't allocate the space initially.
|
|
||||||
|
|
||||||
The sizes of physical partitions can be read (in 512-byte blocks) from
|
|
||||||
`/sys/class/block/sda1/size`. The `resize2fs` tool (assuming you're using
|
|
||||||
a normal ext4 filesystem) will not resize smaller than the free
|
|
||||||
space. Figure out the desired size
|
|
||||||
|
|
||||||
fs_size = $[30 * 1024 * 1024]
|
|
||||||
e2fsck hdd.img
|
|
||||||
resize2fs hdd.img $fs_size
|
|
||||||
|
|
||||||
Once the file system has been resized to make space at the end,
|
|
||||||
the dm-verity tools can generate the hashes. The file system
|
|
||||||
must be unmounted before this is done, otherwise the hashes
|
|
||||||
will not be correct.
|
|
||||||
|
|
||||||
veritysetup \
|
|
||||||
--data-blocks $[$fs_size / 4096] \
|
|
||||||
--hash-offset $fs_size \
|
|
||||||
format hdd.img hdd.img \
|
|
||||||
| tee verity.log
|
|
||||||
|
|
||||||
This will output a text file that contains several important
|
|
||||||
constants for mounting the filesystem later:
|
|
||||||
|
|
||||||
VERITY header information for hdd.img
|
|
||||||
UUID: 73532888-a3e9-4f16-a50a-1d03a265b94f
|
|
||||||
Hash type: 1
|
|
||||||
Data blocks: 7680
|
|
||||||
Data block size: 4096
|
|
||||||
Hash block size: 4096
|
|
||||||
Hash algorithm: sha256
|
|
||||||
Salt: 3d0cd593d29715005794c4e1cd5164c14ba6456c3dbd2c6d8a26007c01ca9937
|
|
||||||
Root hash: 91beda90d7fa1ab92463344966eb56ec9706f4f26063933a86d701a02a961a10
|
|
||||||
|
|
||||||
Unfortunately this is in the wrong form for the `dmsetup` command
|
|
||||||
and must be reformmated like this:
|
|
||||||
|
|
||||||
dmsetup create vroot --readonly --table \
|
|
||||||
"0 61440 verity 1 /dev/sda /dev/sda 4096 4096 7680 7681 sha256 "\
|
|
||||||
"c51e171a1403eda7636c89f10d90066d6a593223399fdd4c36ab214da3c6fc11 "\
|
|
||||||
"f6c6c6b6cbdf2682d6213e65b0e577cb57c8af3015f88f9a40fb512eaf48aca9"
|
|
||||||
|
|
||||||
The 61440 is the number of 512-byte blocks that the filesystem uses.
|
|
||||||
The two 4096 are the data block size and hash block size.
|
|
||||||
The 7680 is the number of data blocks and the 7861 is the first
|
|
||||||
datablock containing hashes (note that block 7680 contains the `VERITY`
|
|
||||||
header and the salt, but not the root hash). The hash and salt are
|
|
||||||
reversed in the order from the `veritysetup` printout.
|
|
||||||
|
|
||||||
We sign this command and stash it in the block after the `VERITY`
|
|
||||||
header so that the firmware can validate the image before mounting it.
|
|
||||||
This does require that the firmware be able to find the header;
|
|
||||||
for now we have it hard coded.
|
|
||||||
|
|
||||||
|
|
||||||
mbedtls vs OpenSSL
|
|
||||||
---
|
|
||||||
mbedtls is a significantly smaller and more modular library than
|
|
||||||
OpenSSL's libcrypto (380KB vs 2.3MB). It is not API compatible,
|
|
||||||
so applications must be written to use it.
|
|
||||||
|
|
||||||
One the build host side we can make use of openssl's tools, but in
|
|
||||||
the firmware we are limited to the smaller library. They are mostly
|
|
||||||
compatible, although the tools are quite different.
|
|
||||||
|
|
||||||
Generate the private/public key pair (and copy the public key to
|
|
||||||
the initrd):
|
|
||||||
|
|
||||||
openssl genrsa -aes256 -out signing.key
|
|
||||||
openssl rsa -pubout -in signing.key -out signing.pub
|
|
||||||
|
|
||||||
Sign something (requires password and private key):
|
|
||||||
|
|
||||||
openssl pkeyutl \
|
|
||||||
-sign \
|
|
||||||
-inkey signing.key \
|
|
||||||
-in roothash \
|
|
||||||
-out roothash.sig
|
|
||||||
|
|
||||||
Verify it (requires public key, no password):
|
|
||||||
|
|
||||||
openssl pkeyutl \
|
|
||||||
-verify \
|
|
||||||
-pubin
|
|
||||||
-inkey signing.pub \
|
|
||||||
-sigfile roothash.sig \
|
|
||||||
-in roothash
|
|
||||||
|
|
||||||
but this doesn't work with pk_verify from mbedtls. more work is necessary.
|
|
||||||
|
|
||||||
|
|
||||||
Signing with GPG
|
Signing with GPG
|
||||||
---
|
---
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user