rework OS pages #76
rework OS pages #76
Conversation
- based on work in PR 66 which now has conflicts linuxboot#66 - re-org OS pages to use subfolder - add pureOS page with current info not on Purism site - change link to OS page in parent index
|
https://jtmoree-github-com.github.io/heads-wiki/ is the online version of this content for easy preview |
| TPM vs Security Dongle | ||
| ---- | ||
|
|
||
| Which one you choose depends on hardware you have and threat models you are working with. Your system may not have a TPM or you may not have a smartcard. The core functionality is similar in that they both store private keys and allow for cryptographic operations. |
There was a problem hiding this comment.
This is tricky to explain.
Heads doesn't "require" a TPM while strongly suggested. But it requires a USB Security dongle enforcing GPG operations for /boot digest detach signing. As you know, key generations (generating keypairs and exporting public key to USB drive, importing public key inside of the ROM) or importing USB Security dongle private key's matching public key is required to sign /boot content.
So the statement here saying "you might not have a smartcard" is a bit contradicting reality of Heads stated prerequisites.
What is true is that a USB Security dongle doesn't require to support HOTP for remote attestation, while a USB Security dongle enforcing GPG is required https://osresearch.net/Prerequisites#usb-security-dongles-aka-security-token-aka-smartcard
There was a problem hiding this comment.
reworded this section to align with your notes.
| * they are two different proprietary hardware chips | ||
| * TPM has access to RAM and processor so it can 'measure' system states | ||
| * Security Dongles often have other features such as password management | ||
| * the TPM is a non-removable chip inside the system but the USB Security dongle is removable |
There was a problem hiding this comment.
"TPM is a non-removable chip" that is not true for KGPE-D16 and other workstations/servers platforms. You can say that it is a chip, soldered in most cases, to the motherboard. A picture of a removable TPM is showed https://osresearch.net/Keys/#tpm-pcrs
"TPM has access to RAM and processor". Hmm.
The TPM, is initialized as early as possible by coreboot, normally in bootblock or romstage, and is fed content to be measured through a tool/library outside of Heads interaction. This was enforced by a patch under Heads for coreboot 4.8.1, and was since then upstreamed and now available without any patch under coreboot 4.13 as measured boot (without need of activating verified boot) through TPM_MEASURED_BOOT.
Heads then use userland tool (tpm userland tool and libraries coming from tpmtotp to ask for measurements that are already stored in PCRs where it can also extend those measurements. Loading kernel modules under Heads calls a wrapper around insmod which extends PCR#5. Going into recovery extends PCR#4. And having inconsistent measurements won't permit to unseal TPM NV's own memory, required to release TPM LUKS Disk Unlock Key.
So to reflect reality here, while it is true that the TPM is not completely independent of the system (it shares LPC bus in most cases) it has limited access to external resources; you can communicate with the TPM. The TPM can read what is on that LPC (or other bus it is connected to) which is why there are still frisky users reluctant to trust a TPM. But stating that:
"TPM has access to RAM and processor so it can 'measure' system states" leaves the user thinking that the TPM is having the capacity to read states directly, which is misleading. The TPM measures content that is passed to it. Stores values, extends values. Can generate keys, secrets, can be used as a random numbr generator etc but all of this is out of scope here. Once again, explaining so that we are on the same page technically.
So :
TPM is fed content to measure and normally store the result of those measurements in what is called PCRs.
If you want to go into more detail, or refer externally to relevant sources:
In the case of Intel TXT (not covered by Heads right now but in Threat model), Intel's ACM binary blob is fed to the processor to be executed first, which is used as a Hardware Root of Trust (RoT). Since the ACM blob is verified against fused Intel signature, the ACM is trusted into reporting the first measurement into PCR0 per coreboot's IBB/CRTM measured boot implementation. Heads uses coreboot measured boot in SRTM mode where the schematic can be observed here.
As always, I would keep things simple and refer externally to have better explanations instead of bloating things here. But what I want you to understand here is that Heads aligned measurements scheme with Coreboot, and that all coreboot related measurements are happening in PCR#2 per this commit on boot (coreboot 4.8.1 and forward) while Heads feeds the TPM to measure other Heads stuff for example here and here to measure user related configs and public key, LUKS header, kernel modules etc.
There was a problem hiding this comment.
removed line about TPM and ram. reworded removable chip.
updated per feedback from PR
|
@tlaurion I reworded sections based on your notes and removed some of the inaccuracies. Please take a look. |
|
|
||
| If not using one of the included Operating Systems--where the vendor public key is [stored in the heads ROM](https://github.com/osresearch/heads/tree/master/initrd/etc/distro/keys)--you must verify the media immediately after download and sign it with your own key to establish a chain of trust. | ||
|
|
||
| To verify an ISO with your key, create a partition with a Heads compatible filesystem on a USB storage device and copy the ISO image to it. The most common filesystems are: FAT and ext. The layout might look like this: |
There was a problem hiding this comment.
FAT won't permit putting files larger then 4GB, not really recommended (Qubes bigger then that. Tails fits though)
ext-> ext3, ext4
There was a problem hiding this comment.
removed FAT reference
| Securely Booting Installation Media | ||
| ---- | ||
|
|
||
| Heads also supports booting directly from verified ISOs on a standard disk partition. In this scenario heads will check the ISO against a detached PGP signature file. The ISO must be signed by a valid key for the boot process to succeed--either the distribution signing key or your own key. |
There was a problem hiding this comment.
directly from verified ISOs -> directly from detached signed ISOs (iso should be accompanied with its iso.asc or iso.sig counterpart on the root of your formatted partition)
|
@jtmoree-github-com You do not want this to be merged? |
Docs refresh of OS install #66