Use shred instead of rm on secret related files.

[tlaurion]

Replacing rm with shred for secrets that should not be present in ram when booting OS.
Address the following concerns

[tlaurion]

@marmarek: would that address your concerns?

A critic that was done over slack was that the key is injected into initrd that is passed to kexec, so an attack like this could still be done from dom0, which means game over anyway.

[marmarek]

I don't have access to that slack channel, but (verified!) dom0 will have access to LUKS key anyway. But for that to happen, one need to run 1) unmodified firmware 2) provide luks passphrase (actually passphrase to unlock luks key). The key is not loaded into RAM unless both happen, which (hopefully) mean it's legitimate owner accessing the machine.

My concern is HOTP/TOTP key, which is loaded into RAM before the user provide any secret. And it is also the thing authenticating machine to the user, so if it got stolen, attacker could convince the user to provide the password (into now backdoored firmware). So we should ensure that this secret doesn't leak anywhere. Yes, coldboot style attacks are probably still possible, but are much harder to perform (especially if you control the firmware), than just booting random Linux using built-in menu and dumping RAM from there.

As for the actual PR, yes it should be good. I'm not sure if -n 10 makes sense on RAM (this makes sense mostly on magnetic discs), but also shouldn't hurt.

[tlaurion]

My concern is HOTP/TOTP key, which is loaded into RAM before the user provide any secret. And it is also the thing authenticating machine to the user, so if it got stolen, attacker could convince the user to provide the password (into now backdoored firmware). So we should ensure that this secret doesn't leak anywhere. Yes, coldboot style attacks are probably still possible, but are much harder to perform (especially if you control the firmware), than just booting random Linux using built-in menu and dumping RAM from there.

Let's go high level first on TOTP/HTOP interaction. Exerpt from here with some comments inline:

Instead of doing away with the TOTP code we are actually using the same exact TPM secret, just in addition to converting it into a TOTP code, we are also combining it with the incrementing counter to generate an HOTP code too. So when you tell Heads that you want to seal a new TOTP secret, if your version of Heads has Librem Key support enabled, in addition to showing you a QR code, it will also prompt you to insert your Librem Key and set up the secret there as well using the libremkey_hotp_initialize program.

This happens everytime the firmware gets modified. If the user didn't update it by himself, he should be alarmed by being prompted to generate new TOTP/HTOP secrets. The vulnerable part would be when the QrCode is generated and when the HOTP secret is sealed into the Nitrokey Pro v2/LibremKey. Those functions are called only when PCRs mismatch and require the user to type TPM/GPG card Admin PIN, a reboot is required after this step.

The next time you boot, in addition to displaying the TOTP code in the menu as always, it also attempts to communicate with your Librem Key using the libremkey_hotp_verification tool. If the Librem Key isn’t inserted, it gets a specific error and warns the user that the key isn’t plugged in, but it doesn’t stop the user from booting. If the user then plugs in the key and tells Heads to regenerate the code, it can do a second test from the GUI. If you lose your Librem Key or leave it behind somewhere, you can always just fall back to the standard TOTP code + phone approach until you have a new Librem Key to enroll.

The TOTP code generation happens here while the HOTP happens here. They both depends on the TPM, and the secret could be grabbed only if the firmware was modified, which the user would be aware of and asked to regenerate TOTP/HOTP secret.

After Heads sends the Librem Key an HOTP code, if the code matches what the Librem Key itself generates, it will flash a green LED and return a success code to Heads to display on the laptop screen. If the HOTP codes don’t match, the Librem Key will flash a red LED indefinitely and also send a specific error back to Heads which will cause it to show a red background and error dialog. Note that you shouldn’t trust the Heads UI to display this error, it’s only for convenience. A modified UI could lie to you so you should only trust the Librem Key LED at this phase of the boot process.

Heads sends HOTP code here. The TPMTOTP is used to unseal disk unlock key here only if PCRs matches, the passphrase typed would fail if the firmware or LUKS header gets modified. So even if the user looses it's GPG card, doesn't check the TOTP numeric code on his phone, the system won't permit to unlock the disk with disk unlock key and will propose the user to unlock the disk with disk recovery key passphrase.

That is where we are now.
Any concerns, @marmarek ?

[marmarek]

Sounds fine!

A little comment: this shred should be done also in case of success. In fact, especially in case of success.

[tlaurion]

Sounds fine!

A little comment: this shred should be done also in case of success. In fact, especially in case of success.

@marmarek: applied. But again, HOTP/TOTP generation happens when firmware tampering is detected (measurements don't match) and is followed by a forced reboot before being able to use the system.

[kylerankin]

This seems straightforward to me. Approved.