You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The very first key used in the system is Intel's public key that signs the
34
-
Management Engine firmware partition table in the SPI flash. This key is
35
-
stored in the on-die ROM of the ME and the ME will not start up if this
36
-
signature does not match. An attacker who controls this key (which is highly
37
-
unlikely) can subvert the Bootguard checks as well as the measured boot
38
-
process.
39
-
40
-
The [Bootguard fuses](https://trmm.net/Bootguard) fuses provide protection
41
-
against most "evil maid" attacks against the firmware. The hash of the ACM
42
-
signing key is set in write-once fuses in the CPU chipset and during the CPU
43
-
bringup phase the ME and the CPU microcode cooperate in some undocumented way
44
-
to validate the "Startup ACM" in the SPI flash. Since this key is fused into
45
-
hardware, an evil maid attack would need to replace the CPU to install
46
-
malicious firmware into the SPI flash. The x230 Thinkpads do not support
47
-
bootguard and only the Librem laptops ship with unfused keys.
31
+
The first key used is Intel's public key that signs the Management Engine
32
+
firmware partition table in the SPI flash. This key is stored in the on-die ROM
33
+
of the ME and the ME will not start up if this signature does not match. An
34
+
attacker who controls this key (highly unlikely) can subvert the Bootguard
35
+
checks and the measured boot process.
36
+
37
+
The [Bootguard fuses](https://trmm.net/Bootguard) provide protection against
38
+
most "evil maid" attacks against the firmware. The hash of the ACM signing key
39
+
is set in write-once fuses in the CPU chipset. During CPU bringup, the ME and
40
+
the CPU microcode validate the "Startup ACM" in the SPI flash. An evil maid
41
+
attack would need to replace the CPU to install malicious firmware into the SPI
42
+
flash. The x230 Thinkpads do not support Bootguard and only the Librem laptops
43
+
ship with unfused keys.
48
44
49
45
An attacker who controls this key can flash new firmware via hardware means
50
-
(and possibly remotely via software, unless other steps are taken).
46
+
(and possibly remotely via software, unless other steps are taken).
51
47
52
-
TPM Owner password
53
-
---
48
+
## TPM Owner password
54
49
55
-
As part of setting up Heads the TPM is "owned" by the user and the owner
56
-
password is set. This clears all existing NVRAM and spaces (but does not reset
57
-
counters?).
50
+
As part of setting up Heads, the TPM is "owned" by the user and the owner
51
+
password is set. This clears all existing NVRAM and spaces (but does not reset
52
+
counters?).
58
53
59
54
Are there any consequences of an attacker controlling this key?
60
55
61
-
TPMTOTP shared secret
62
-
---
56
+
## TPMTOTP shared secret
63
57
64
58
65
59
66
-
Since humans have trouble doing RSA public key cryptography in their brains,
67
-
Heads uses [TPM TOTP](https://trmm.net/Tpmtotp) to let the system attest to the
68
-
user that the firmware is unmodified. During system setup a random 20-byte
69
-
value is generated and shared (via QR code) to the user's phone as well as
70
-
sealed with the correct TPM PCR values into the TPM NVRAM. On subsequent boots
71
-
the TPM will unseal the secret if and only if the PCRs match, and the computer
72
-
then generates a one-time password based on the current clock time, which the
73
-
user can compare to the value displayed on their phone. A new secret must be
74
-
generated each time the firmware is updated since this will change the PCRs.
60
+
Heads uses [TPM TOTP](https://trmm.net/Tpmtotp) to let the system attest to the
61
+
user that the firmware is unmodified. During setup, a random 20-byte value is
62
+
generated and shared (via QR code) to the user's phone and sealed with the
63
+
correct TPM PCR values into the TPM NVRAM. On subsequent boots, the TPM will
64
+
unseal the secret if the PCRs match, and the computer generates a one-time
65
+
password based on the current clock time, which the user can compare to the
66
+
value displayed on their phone. A new secret must be generated each time the
67
+
firmware is updated since this will change the PCRs.
75
68
76
69
If an attacker can control this shared secret (such as by directly sending PCR
77
-
values into the TPM) they can install malicious firmware in the SPI flash and
78
-
generate valid TOTP codes.
70
+
values into the TPM), they can install malicious firmware in the SPI flash and
71
+
generate valid TOTP codes.
79
72
80
-
TPM counter key
81
-
---
73
+
## TPM counter key
82
74
83
75
The TPM's increment-only counters can be used to prevent roll-back attacks on
84
-
the signed kernel and initramfs configurations. An attacker who controls this
85
-
key can increment the counter, causing a denial of service attack against the
86
-
system, but it does not provide any access to encrypted data nor any way to
87
-
roll back to an old version.
88
-
89
-
TPM disk encryption key
90
-
---
91
-
92
-
The TPM NVRAM also stores one of the disk encryption keys, which is encrypted
93
-
with the user's disk unlock password and sealed with the TPM PCR values for
94
-
the firmware and the LUKS headers on the disk. On every boot the user types in
95
-
their password and the TPM will unseal and decrypt the disk encryption key if
96
-
and only if the firmware is unmodified and the password matches. Since the
97
-
TPMTOTP one-time code matched, the user can have confidence that the firmware
98
-
is unmodified before they enter their password. If the system is booted in
99
-
recovery mode, the PCRs will not match and this key is not accessible to the
100
-
user.
76
+
the signed kernel and initramfs configurations. An attacker who controls this
77
+
key can increment the counter, causing a denial of service attack against the
78
+
system, but it does not provide access to encrypted data nor any way to roll
79
+
back to an old version.
80
+
81
+
## TPM Disk Unlock key
82
+
83
+
The TPM NVRAM stores one of the disk encryption keys, which is encrypted with
84
+
the user's Disk Unlock Key passphrase and sealed with the TPM PCR values for
85
+
the firmware and the LUKS headers of the disk. On every boot, the user types in
86
+
their TPM Disk Unlock Key passphrase and the TPM will unseal and decrypt the disk encryption key if
87
+
the firmware is unmodified and the passphrase matches. Since the TPMTOTP
88
+
one-time code matched, the user can have confidence that the firmware is
89
+
unmodified before they enter their TPM Disk Unlock Key passphrase. If the system is booted in
90
+
recovery mode, the PCRs will not match and this key is not accessible to the
91
+
user.
101
92
102
93
The Heads firmware inserts this key into the Qubes `initramfs.cpio` as
103
-
`/secret.key`, which is listed in the `/etc/crypttab` file as the decryption
104
-
key for the various partitions. The dracut/systemd startup scripts will read
105
-
the `/etc/crypttab` file and use it to decrypt the drives without further user
106
-
intervention.
94
+
`/secret.key`, which is listed in the `/etc/crypttab` file as the decryption
95
+
key for the various partitions. The dracut/systemd startup scripts will read
96
+
the `/etc/crypttab` file and use it to decrypt the drives without further user
97
+
intervention.
107
98
108
99
The sealed blob is not secret since it is both encrypted and sealed, but if an
109
-
attacker can extract this unsealed and decrypted key they can decrypt the data
110
-
on the disk. If they extract the TPM they can set the PCRs to the correct
111
-
values and attempt to brute force the unlock code, although the TPM should
112
-
provide some rate limiting. TODO: Can the TPM also flush the keys if too many
113
-
attempts are made?
100
+
attacker can extract this unsealed and decrypted key, they can decrypt the data
101
+
on the disk. If they extract the TPM, they can set the PCRs to the correct
102
+
values and attempt to brute force the unlock code, although the TPM should
103
+
provide some rate limiting. TODO: Can the TPM also flush the keys if too many
104
+
attempts are made?
114
105
115
-
Disk recovery key
116
-
---
106
+
## Disk Recovery Key
117
107
118
-
During initial system setup the disk is encrypted with a user chosen passphrase.
119
-
This key is only entered if the TPM PCRs have been changed, such as following a
120
-
firmware update, or if the disk has been moved to a new machine and the user
121
-
needs to back up the code. If the system is booted into recovery mode, the TPM
122
-
PCRs will not match the TPM sealed encryption key, so the user will need to
123
-
enter the recovery key to decrypt the drives.
108
+
During initial system setup, the disk is encrypted with a user-chosen
109
+
passphrase. When a TPM Disk Unlock Key is set up, this key is only entered if
110
+
the TPM PCRs have changed, such as following a firmware update, or if the disk
111
+
has been moved to a new machine and the user needs to back up the code. If the
112
+
system is booted into recovery mode, the TPM PCRs will not match the TPM sealed
113
+
Disk Unlock Key, so the user will need to enter the recovery key to decrypt the
114
+
drives.
124
115
125
-
If an attacker gains control of this recovery key they can decrypt the disk to
126
-
get access to the data, but not necessarily the system configuration if
127
-
dm-verity is configured. They can also add additional disk decryption keys,
128
-
although this will be detected by the TPM measurement of the LUKS headers.
116
+
If an attacker gains control of this recovery key, they can decrypt the disk to
117
+
access the data, but not necessarily the system configuration if dm-verity is
118
+
configured. They can also add additional disk decryption keys, although this
119
+
will be detected by the TPM measurement of the LUKS headers.
129
120
130
-
LUKS disk encryption key
131
-
---
121
+
## LUKS Keys and Passphrases
132
122
133
-
The TPM disk encryption and user's disk recovery keys are not the actual
134
-
encryption keys for the disk; they are passed through[PBKDF2](https://en.wikipedia.org/wiki/PBKDF2)
135
-
and the result is used to encrypt the actual disk encryption key, which is
136
-
stored in the LUKS header on the disk. Under normal circumstances this key is
137
-
not visible to the user and is only an implementation detail.
123
+
The TPM Disk Unlock and user's Disk Recovery passphrases are not the actual
124
+
encryption keys for the disk. These passphrases are processed through
125
+
[PBKDF2](https://en.wikipedia.org/wiki/PBKDF2) (LUKS1) or [Argon2]
126
+
(https://en.wikipedia.org/wiki/Argon2) (LUKS2) to derive a key. This derived
127
+
key then decrypts the actual disk encryption key stored in the LUKS header.
138
128
139
-
Access to this key has the same risks as the disk recovery key.
129
+
The disk encryption key itself remains hidden from users, serving only as an
130
+
implementation detail for the encryption process.
140
131
141
-
Owner's GPG key
142
-
---
132
+
## Owner's GPG key
143
133
144
134
145
135
146
-
The owner of the machine generates a GPG key pair as part of installing Heads.
147
-
Ideally the private key does not live on the machine, but instead is in a
148
-
Yubikey or other USB Security dongle.
136
+
The owner of the machine generates a GPG key pair as part of installing Heads.
137
+
Ideally, the private key does not live on the machine, but instead is in a
138
+
Yubikey or other USB Security dongle.
149
139
150
-
The security dongle may be used in the disk decryption process. Some of the [Linux distros](https://docs.puri.sm/Librem_Key/Getting_Started/User_Manual.html#decrypt-luks-encrypted-drives-with-librem-key) have incorporated this using /etc/crypttab with a keyscript option.
140
+
The security dongle may be used in the disk decryption process. Some of the
Copy file name to clipboardExpand all lines: Installing-and-Configuring/install-os.md
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -82,7 +82,7 @@ Default Boot and Disk Unlock
82
82
83
83
If you want to set a default option so that you don't have to choose at every
84
84
boot, you can do so from the menu by selecting 'd' on the confirmation screen.
85
-
You will also be able to seal your Disk Unlock Key into the TPM, which would be unsealed only when provided with the good TPM disk encryption key passphrase and when firmware measurement and LUKS header are the same as when the Disk Unlock Key was sealed when booting from detached signed default boot option selection.
85
+
You will also be able to seal your Disk Unlock Key into the TPM, which would be unsealed only when provided with the good TPM Disk Unlock Key passphrase and when firmware measurement and LUKS header are the same as when the Disk Unlock Key was sealed when booting from detached signed default boot option selection.
86
86
87
87
This should work for Qubes OS, Fedora, Debian (and derivatives).
0 commit comments