idea: password protection

[jans23]

A customer or ours wishes a simple password protection in Heads. This should prevent against simple DoS attacks where somebody executes a factory reset or other misconfiguration. Do you think this makes sense?

[tlaurion]

@jans23 #361 ?

[tlaurion]

@jans23 : Once again, that would depend of #771 if we want to implement this correctly, so that users don't lock themselves out if USB Security dongle is lost, while not having a secret hardcoded somewhere that could be extracted (externalize that validation).

Authentication could then be implemented prior of going into recovery shell, which could mainly mitigate #836 (comment), since access to recovery shell is mandatory to be able to modify boot scripts and get away of the protection given by Heads GUI in absence of a TPM to invalidate measurements and delete secrets prior of entering recovery shell

[szszszsz]

@tlaurion The initial idea was to use a simple passphrase as a low-security mean against non-hackers, and without the need for the USB Security dongle. Saying that, the #361 sounds like a right way to do it from a brief look.
Perhaps both should be possible - that is unlocking Heads configuration with passphrase or USB Security dongle.

cc: @alex-nitrokey

[tlaurion]

@szszszsz @alex-nitrokey #361 was finally tested, and works well.

@persmule
The only problem I see with it is that if the public key is expired (just tested) Heads will panic and won't let the machine owner go into recovery.

@MrChromebox There could be some fallbacks or other options.

• One i'm thinking is reusing the Disk Unlock Key passphrase (TPM sealed and protected decryption key) to test unlocking LUKS container. If that passphrase succeeds, then we know that the the sealed measurements in reserved TPM NV memory contained the LUKS header which is part of what is measured to release the Disk Unlock Key. So we know no drive swap occured and can safely land into recovery shell.
• Another one, less secure, would be to permit recovery access by prompting for the Disk Recovery Key (LUKS slot 0 passphrase). That one would permit an attacker to swap current disk with one he prepared and for which he knows the passphrase to be able to access the recovery.
• Another option could be to mitigate the problem of an expired public key by permitting in the GUI to extend the expiracy date of that key, export on external media if desired and reflash. On reboot, user would need to reseal HOTP.
• But the most tragic use case is if the user lost his USB Security dongle.

Thoughts?

[kylerankin]

At least in my experience quite a few people who use Heads sometimes find managing the various keys and PINs challenging so I'm sensitive to adding anything that risks locking someone out of their own system without a way to recover, since people do forget/mix up passwords. However if they were still allowed to reset in the GUI with an OEM Factory Reset, then they could reset things and because it's a destructive operation, it would be noticeable if someone other than the owner did it. Beyond that I think it would be acceptable to allow someone to extend their key expiry date and reflash and that would be less destructive than a full reset. However that risks allowing other arbitrary public keys into the keyring, but the fact that the HOTP secret changes would also make that detectable.

…

On Fri, Sep 10, 2021 at 10:50:51AM -0700, tlaurion wrote: @szszszsz @alex-nitrokey #361 was finally tested, and works well. @persmule The only problem I see with it is that if the public key is expired (just tested) Heads will panic and won't let the machine owner go into recovery. There could be some fallbacks or other options. - One i'm thinking is reusing the Disk Unlock Key passphrase (TPM sealed and protected decryption key) to test unlocking LUKS container. If that succeed, then we know that the firmware recognized the LUKS header which is part of what is measured to release the Disk Unlock Key. - Another one, less secure, would be to permit recovery access by prompting for the Disk Recovery Key (LUKS slot 0 passphrase). That one would permit an attacker to swap current disk with one he prepared and for which he knows the passphrase to be able to access the recovery. - Another option could be to mitigate the problem of an expired public key by permitting in the GUI to extend the expiracy date, and reflash. On reboot, user would need to reseal HOTP. - But the most tragic use case is if the user lost his USB Security dongle. Thoughts? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #881 (comment)

[daringer]

I would also totally second @kylerankin 's thoughts here, from user perspective the only thing that counts is: "I need to factory-reset my device at any time" -> So I would also 1st vote for a factory reset mechanism, which should always be possible, leaving the device in a state in which the user (if an attacker has done it) will clearly see that someone has tampered the device.

[tlaurion]

@daringer @kylerankin :

So I would also 1st vote for a factory reset mechanism, which should always be possible, leaving the device in a state in which the user

That mechanism is already in place and is triggered automatically under gui-init here when no gpg user's public key were imported in ramfs from key-init that were extracted from cbfs-init early at boot.

Of course, the user is guided into gpg options only if no gpg public key were found in the ROM, but it is already there, and basically launches gpg-gui.sh. Otherwise the user has to go there manually.

What would we want to add here to meet your needs here?

• A test to check if public keys found in ROM are not expired? If expired, tell the user it is and invite him to extend expiracy date or reset his dongle (Y/n).
• Give additional option under gpg-gui.sh to the user to change expiracy date, where user has been offered in previous advice.

The rest is already covered, yes?
Question uncovered here is: dongle is lost. Do we want a backup mechanism, less secure:

• To use Disk Unlock Key passphrase, which unlocks sealed TPM NV space only if LUKS header is valid + firmware measurements + not having went to recovery and if successful, let user go to recovery?
• Open up for less secure option of asking user to type Disk Recovery Key passphrase for disk encrypted partition (cryptsetup luksOoen call on referred encrypted partition in file /boot/kexec_key_devices.txt ?)
• Or, just expect the user to boot insecurely his system until he buys and receive a new USB Security dongle that he will have to factory reset through gpg-gui.sh from GPG Options menu?

[kylerankin]

I always considered TOTP to be the backup for a lost dongle, for people who want to protect against that and face a threat such that they will be rebooting and testing firmware against tampering in the span of time they wait for their replacement dongle to arrive.

…

On Mon, Sep 13, 2021 at 10:04:18AM -0700, tlaurion wrote: @daringer @kylerankin : > So I would also 1st vote for a factory reset mechanism, which should always be possible, leaving the device in a state in which the user That mechanism is already in place and is triggered automatically when no public key are exportable from the ROM under gui-init [here](https://github.com/osresearch/heads/blob/055165d61a3c312e7e03998ea832447452a86d71/initrd/bin/gui-init#L174-L185). Of course, the user is guided into doing that only if not public key are found in the ROM, but it is already there, and basically [launches](https://github.com/osresearch/heads/blob/055165d61a3c312e7e03998ea832447452a86d71/initrd/bin/gui-init#L423-L426) gpg-gui.sh. What would we want to add here to meet your needs here? - [ ] A test to check if public keys found in ROM are not expired? If expired, tell the user it is and invite him to extend expiracy date or reset his dongle (Y/n). - [ ] Give additional option under gpg-gui.sh to the user to change expiracy date manually, where user has been offered in previous advice. The rest is already covered, yes? Question uncovered here is: dongle is lost. Do we want a backup mechanism, less secure: - [ ] To use Disk Unlock Key passphrase, which unlocks sealed TPM NV space only if LUKS header is valid + firmware measurements + not having went to recovery and if successful, let user go to recovery? - [ ] Open up for less secure option of asking user to type Disk Recovery Key passphrase for disk encrypted partition (cryptsetup isLuks call on referred encrypted partition in file /boot/kexec_key_devices.txt ?) - [ ] Or, just expect the user to boot insecurely his system until he buys and receive a new USB Security dongle that he will have to factory reset through gpg-gui.sh from GPG Options menu? -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #881 (comment)

[daringer]

What would we want to add here to meet your needs here?

• A test to check if public keys found in ROM are not expired? If expired, tell the user it is and invite him to extend expiracy date or reset his dongle (Y/n).
• Give additional option under gpg-gui.sh to the user to change expiracy date, where user has been offered in previous advice.

I would go for option 1 only to keep things straight, resetting the dongle is perfectly fine and enough. The 2nd option is a "nice-to-have" but I don't feel like this is really necessary.

The rest is already covered, yes?
Question uncovered here is: dongle is lost. Do we want a backup mechanism, less secure:

• Or, just expect the user to boot insecurely his system until he buys and receive a new USB Security dongle that he will have to factory reset through gpg-gui.sh from GPG Options menu?

Giving the user options for less secure setups, will lead to this option getting permanent. So I would (also for the sake of reduced complexity) force the insecure boot, which will then (hopefully) force the user to get a new dongle.

[tlaurion]

Integrated in #1515