From 9b405930deedf404733efc2f11f55d0e4614ec18 Mon Sep 17 00:00:00 2001 From: Trammell Hudson Date: Sun, 7 Aug 2016 13:50:06 -0400 Subject: [PATCH] read-only / thoughts --- README.md | 29 +++++++++++++++++++++++++++-- 1 file changed, 27 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 5490cac0..a98fd56b 100644 --- a/README.md +++ b/README.md @@ -24,7 +24,14 @@ significant frustration. 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 @@ -43,9 +50,27 @@ 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 any of the other x86 boot processes, -since we now have +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.