GPG keypair generation from Heads, then copied to USB Security dongle

[tlaurion]

Current customer concerns:

• What do I do if I loose the USB Security dongle. Worst : drown USB security dongle in pool, toilet.
• What do I do if I lock myself out of the USB Security dongle Admin PIN?

Solutions:

• Have the keypair generated inside of Heads (/tmp) then offered to be copied to USB Security dongle with a big fat warning if destination backuppartition mountpoint is not encrypted? (I would deny such export)
• Have the factory reset code also generate a Reset Code (that permits to unlock Admin PIN)

EDIT: implementation plan here: #771 (comment)

[tlaurion]

@alex-nitrokey @kylerankin @MrChromebox : Thoughts?

[alex-nitrokey]

As far as I can see, the function of the dongle is to detect unauthorized alternation of the firmware/everything in /boot. So, losing/breaking the dongle does solely mean that the user needs a new device to be able to detect such change on the system again. The problem arises if the dongle gets lost during a situation in which the pc was unattended and exposed as well.

One could implement a feature to prepare two dongles at once during oem factory reset to have a backup device.

Imho it is not useful to let the key be exported if you like to make Heads secure and easy to use for the innocent. If you really like a full backup of your GnuPG keys you already can prepare your dongle first and then provide the public key to Heads - though this is for the more experienced users.

I do not see how rising the PIN size should help here?

[MrChromebox]

a second dongle isn't going to be a drop-in replacement since the counters will be out of sync, and you'd still have to generate a new secret with the backup dongle.

[techge]

a second dongle isn't going to be a drop-in replacement since the counters will be out of sync

A right, forgot that.

and you'd still have to generate a new secret with the backup dongle.

This would have been solvable by copying the secret to both dongles, I guess.

[tlaurion]

The goal here is really to be loss-proof from encrypted mails perspective. I think it is ok to accept the user to have to validate with Disk Unlock Key code and or TOTP and not update dom0 before having secrets sealed through HOTP on new device with options provided below.

Menu options:

• Heads keypair generation + copy keys to smartcard + PINs generation + Reseal HOTP secret
• Copy keys to smartcard + USB Security dongle PIN generation + Reseal HOTP secret

Thoughts?

[alex-nitrokey]

I would adapt this to

• keypair generation in GnuPG + keytocard command in GnuPG + (maybe export +) shred keys + PINs generation + Reseal HOTP secret
• Generate keys on smartcard + PIN generation + Reseal HOTP secret

That's maybe nitpicking, but I want to make sure the process is described as I see it.

Please note that keypair generation and copying to (multiple) devices would be a process that includes a lot of screenscraping in GnuPG which might be error prone. Honestly, I really think "power users" shall just do this themselves and copy a public key to the BIOS like they can today (and I did it). John and Jane Doe may just use the key on the one and only USB Security dongle and thus do not need to think how to store a exported GnuPG key securely.

[tlaurion]

@alex-nitrokey @MrChromebox @jans23 will attack that issue soon, with following plan.

• Generate GPG keypair under Heads + keytocard command in GnuPG + export to secure storage + shred keys (not needed if gpg --home=/media/luks_encrypted_mountpoint) + PINs generation + Reseal HOTP secret (Fast + Lost proof keypair backup)
• Generate GPG keypair on smartcard + Export to secure storage + shred keys (not needed if gpg --home=/media/luks_encrypted_mountpoint) + PIN generation + Reseal HOTP secret (Slow generation of 4096 keys (15 minutes) + Lost proof keypair backup)
• Generate GPG keypair on smartcard + PIN generation + Reseal HOTP secret (Risky: No private key backup, HOTP only use case)

Please note that keypair generation and copying to (multiple) devices would be a process that includes a lot of screenscraping in GnuPG which might be error prone.

Screenscraping should not be a problem unless we change versions of GPG, which should come with regression testing if we learned from our past errors this time. If the gpg UX change, so should be the screenscraping. Not a hard problem.

Honestly, I really think "power users" shall just do this themselves and copy a public key to the BIOS like they can today (and I did it).

The problem, and a lot of request coming out of it (1 per week at least from enough technical people to understand the risk and ask the question prior of the fact...) is the user don't understand the risks of loosing their USB Security dongle once they started using it for what it is intended for outside of Heads. They actually believe wrongly that Nitrokey [Pro/Storage]/Librem Key permit private key backup after the fact (same thing for public key that is thought to be exportable from the USB Security dongle, btw...), and do not understand that once their USB Security dongle is lost, they lose decryption of all their past encrypted mails and other encrypted stuff and other identities linked to their private keys store on it.... Until they loose their dongle.

The issue here is that those "slightly more secure" (heads) laptops that we sell are supposed to ease such onboarding and resolve the chicken egg problem. If the goal here is to propose a solution where the user can trust their root of trust (RoT) because remotely attested (TOTP) and tamper evident in transit (HOTP), Heads should be useable to facilitate this while not being misleading.

Imagine a user buys a x230 himself outside of our distribution channels. No partition defined on hard drive/comes with Windows preinstalled. That user wants (he does't know what he wants most of the time, but if technical enough...):

• To provision Heads on first boot (TPM, USB Security dongle after validating dongle/bios has not tampered with)
• Boots from USB by default when no /boot is found, opening possibility to boot a QubesOS ISO from USB drive to install it (QubesOS + detached signature)/Other ISO he manually validated integrity+detach sign that ISO (he can't here at this point,unless... dongle is already owned and can detach sign, right?)
• Second phase of QubesOS (on reboot) requires creating of digest of /boot content and detach signature of it to boot in new default boot OR to unsafe boot to finish installation. At that point, we have a chicken egg problem. Should we require users to be able to be techy enough to/and have another trustworthy computer on which he should be able to generate a keypair on and copy public key over while leaving the private key on disk unsecured? Or should we facilitate this process in the safest environment he can possibly have (Heads). I believe in the later.

So if the user boots under Heads without a public key in ROM, as of right now:

• The first prompt that user will receive is that no public key is inside of the ROM, opening the possibility for that user to actually generate a keypair useable for so many other things then just HOTP.

• The user should be proposed to insert a USB drive that will be used store that GPG keypair securely if he desires, WIPING OUT ORIGINAL CONTENT ON THAT DRIVE. (simple. mount-usb hack, checking if isLuks prior of mounting partition if multiple partitions are found. If partition is not luks: prompt to continue. Else mount isLuks detected partition and skip next step.

• That USB drive should be partitioned with two partitions. One as LUKS container (25% of total drive space), and a public, standard partition (75% of total disk space).

• The wizard would then propose the user to choose a Disk Recovery Key passphrase (kept in memory and used to luksFormat then luksOpen), and then create a standard ext4 partition inside of it and mount it under precedently created /mnt/encrypted mountpoint, mounting the public partition under /media

• The wizard should then proceed into generating the 4096 RSA keys from Heads with gpg --homedir=/mnt/encrypted, and export public key under /media/public/public.asc (and find a trick to change ownership, since files under heads are created with root user and requires user knowledge to change ownership of files prior of copyingthat public key somewhere usable...)

• After generation, keytocard the private keys into smartcard

• Continue with actual codepaths.

@alex-nitrokey thoughts?

• The user could then use that USB drive to go on that not so trusted prior computer and download ISO + detached signature (QubesOS, Tails)/verify ISO(Others ditros) prior of copying it over public partition+detach sign it and then come back to Heads to boot/install from it.

• On next reboot, he would be able to sign /boot content(in case of install), the public key being fused inside of Heads already, Heads being ready to sign /boot digest with private key, while that "Emergency USB drive" would content original reinstallation media + secured GPG private key to store securely. Or, in current codepath, if no /boot exists, show default option to boot from USB media (the user might want to use Heads without a harddrive, in which case booting from USB would ease installation/booting of Tails.)

Otherwise, the process requires the user to be really technical, trust another computer to generate keys, not have a backup or have the private key on their less trustable computer(Nooooooooo.....), not be able to properly erase it... which implies other risks most of users are not aware of and if they were, wouldn't go that path.

John and Jane Doe may just use the key on the one and only USB Security dongle and thus do not need to think how to store a exported GnuPG key securely.

I do not understand your point considering real risks of loosing the physical dongle here but if you consider a USB Security dongle to be useable only for HOTP, which most users would use for other means if they knew prior of the fact. Please clarify.

[jans23]

I agree that such process should not require a 2nd computer.

For clarification: IMO "export to secure storage" in the first two paragraphs refer to two different things. In the first paragraph it means exporting private key and in second paragraph it means exporting public key. Right?

If the purpose of the LUKS-encrypted drive is only to store the private PGP key, I suggest to use GPG encryption instead. It should be easier to implement and easier to use for the user (she can copy the encrypted file to whatever other backup media she prefers).

[alex-nitrokey]

I totally see your point in providing a all-in-one-failsafe solution for the innocent user. I guess my problem is just that I am not sure if things are really getting better. In the end it is a matter of taste. That is to say, I do not want to argue against you proposal in any way (it should be doable), it is just not the path I would use.

I personally think that the whole process is getting just more complicated for users without technical knowledge. I opt to losing data/keys instead of letting users do bad stuff. They already need to remember/know the difference of User PIN, Admin PIN, (TPM password, theoretically), passphrase for the LUKS disk on the machine - and now the passphrase for the key backup. They all should be different. I see more potential data loss in losing these or in willingly typing these in inappropriate situations than in losing/breaking the smartcard.

I do not understand your point considering real risks of loosing the physical dongle here but if you consider a USB Security dongle to be useable only for HOTP, which most users would use for other means if they knew prior of the fact. Please clarify.

I guess I just meant the fact that they do not need to think about how to create a secure usb drive on which the backup key is stored. As far as I can see the process you described above would somehow solve this issue already.

Generally, I think the process you describe is legitimate. If I would go for a solution to create a backup I would go either in a similar way you did or I would propose configuring two smart cards at once - thus having a smart card-protected backup. In any case a user should be informed in detail what the security implications of a key-on-encrypted-disk vs. key-on-smartcard are.

[jans23]

If I would go for a solution to create a backup I would go either in a similar way you did or I would propose configuring two smart cards at once - thus having a smart card-protected backup.

I support that. This has been requested by some of our users already.

[tlaurion]

I agree that such process should not require a 2nd computer.

Awesome

For clarification: IMO "export to secure storage" in the first two paragraphs refer to two different things. In the first paragraph it means exporting private key and in second paragraph it means exporting public key. Right?

Yes. Sorry for the confusion. Saving the private key requires secured storage (non linked to secure storage linked to private that is to be restored by copytocard later on), while public key can be saved, and should be saved, on public partition.

If the purpose of the LUKS-encrypted drive is only to store the private PGP key, I suggest to use GPG encryption instead. It should be easier to implement and easier to use for the user (she can copy the encrypted file to whatever other backup media she prefers).

This solution, while seeming more logic, doesn't fit the use case of being able to restore the private key to be restored to do a copytocard. LUKS is supported everywhere, even on windows, and onve again, the goal here is for the user to be guided in a programmatic way to have its private key restored on a new USB Security dongle in case the prior one is lost (from Heads, again)

The Heads GUI, responsible to restore the private key, would expect a LUKS partition to find the private key under it once unlocked and mounted, from where it would be able to restore it on a new USB Security dongle ordered and received.
@jans23: Having an encrypted gpg file would not resolve the issue (current need) when private key is lost to be able to provision a new USB Security dongle. (Falling back into the chicken egg problem, not solving it at all)

The risks we really try to mitigate here are:

• Do not store the private key on untrusted media.
• USB Security dongle being lost resulting in encrypted disks and emails staing in encrypted form forever
• Loss of signing identity
• Being able to activate and use a Reset PIN to reactivate Admin PIN to unlock User PIN, so that a user locking himself out, but not loosing its USB Security dongle, can unlock it without factory resetting it or restore keytocard.
• Hassle of creating key transition statement...

Between the moment of the USB Security dongle being lost and the moment the new ordered one is received, the user can:

• Not update dom0 and rely on Disk Unlock Key passphrase to attest firmware integrity/boot integrity
• Update dom0 but boot insecurely his laptop (Options, Boot options, other boot option, boot without validating /boot integrity)
• Accept not being able to decrypt new received encrypted mail, use QubesOS split-gpg meanwhile...

Until he goes into the new heads menu and select the Restore private key under new USB Security dongle from External encrypted partition + change PINs + reseal + resign option or something similar.