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.

[tlaurion]

@alex-nitrokey

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.

Asking the user to buy two Nitrokey Storage i nthe idea of loosing the key is something I would think psychologically difficult for the user, after the fact. And if a user thinks of buying 2 keys because he might be disorganized, then the possibility of loosing 2 keys (instead of buying a lineyard and have a USB drive securely stored somewhere...) is problematic idea per se. Now he looses the second key and he still doesn't have a way to restore it, the private key not having been exported when it was actually accessible.

This path would once again use Heads to generate the keys and store it with copytocard, while not having a physical 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.

I'm sorry I don't understand the point here since there is no difference for me or langage used is not on point.
If you are talking about smartcard based keypair generation vs Heads based keypair generation, you might have a point, where the normal risks here are again on prime number generation and entropy generation. As long as we do not rely on the vulnerable hardware extensions to do the work (blink blink Intel, not under the x230, not used by currently built GPG AFAIK) then there would be a difference in the kind of trust the user is required to have into the random number generator, let it be inside of the USB Security dongle/ Heads.

EDIT: @jans23 @kylerankin @techge @MrChromebox : experts in the smartcard area are now having serious doubts about smartcard generated keypairs: "[...]it's tricky to generating RSA keys properly with hardware. The opposite is true with ECC. [...] I wouldn't trust key generation on smartcards" (anonymous, trustworthy source).
Why would we trust smartcards here anyway, by default? (not open source: blind faith, not measured and auditable trust, right?)
I think my first step here will be to unify USB storage in external storage (which will also support MMC with kernel additions into -maximized boards) and have the possibility to use sdcard (can be locked read only by user after creation, even better...).

There is no added risk in having the key also stored onto a secured storage from an amnesiac environment (Heads).

The main points, for me, to move the keypair generation inside of Heads instead of having it inside of the smartcard are two folded:

• Lower keypair generation time of RSA 4096 bits (5 minutes each in card: 15 minutes)
• Have a backup of the private key inside a secured storage.

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.

Well, personally, I would have deduplicated once more the Disk Recovery Key passphrase here (in reownership, which would take advantage of this codepath as well). So we would have:

• TPM passphrase (named PIN.... disagree) = GPG Admin passphrase (without augmenting risk since GPG Admin PIN is rate limited and kicks out user after 3 attempts)
• Disk Recovery Key passphrase = Disk Recovery Key passphrase for USB secured drive partition (User should never type that passphrase but in secured space, and boots his machine with Disk Unlock Key passphrase as of right now, or with GPG User PIN in Librem setups if I got this well)

No added risk here. The reownership wizard requires provisioning secrets to be inside of a LUKS container already. A user not coming from the reownership wizard would be asked to insert a blank USB thumb drive to have it prepared for that use case. He refuses? then warning: no backup of your private key will be possible. Please provide a USB drive to store your public key. User refuses, he can be warned with the possibility of exporting it in a later time, which is the consequence of current code base.

[tlaurion]

If we have agreement, I will start coding this, starting with #777

[alex-nitrokey]

If we have agreement, I will start coding this, starting with #777

No added risk here. The reownership wizard requires provisioning secrets to be inside of a LUKS container already. A user not coming from the reownership wizard would be asked to insert a blank USB thumb drive to have it prepared for that use case. He refuses? then warning: no backup of your private key will be possible. Please provide a USB drive to store your public key. User refuses, he can be warned with the possibility of exporting it in a later time, which is the consequence of current code base.

I have no objections in having this workflow in heads. I might disagree with some design decisions, but I neither think they are dangerous or wrong nor do I feel like they would make the situation worse, on the contrary, I think it is generally a good idea that tackles an important issue. It probably all depends on the use case/threat model/user in mind. I prefer a simpler setup for innocent users, in which there is no backup and no additional usb drive as well.

So I am totally fine and glad with having this feature in heads.

PS:

I'm sorry I don't understand the point here since there is no difference for me or langage used is not on point.
If you are talking about smartcard based keypair generation vs Heads based keypair generation, you might have a point, where the normal risks here are again on prime number generation and entropy generation. As long as we do not rely on the vulnerable hardware extensions to do the work (blink blink Intel, not under the x230, not used by currently built GPG AFAIK) then there would be a difference in the kind of trust the user is required to have into the random number generator, let it be inside of the USB Security dongle/ Heads.

Yes, I indeed referred to the fact that having no backup key outside of a smartcard is considered generally the safest as you can not do something wrong here - you just can not export it in any way. So having keys generated on card is less error prone imho. Having said that, you can of course handle private keys with care outside of a smartcard, I am doing this myself, of course. Would I recommend Jane Doe? Not really. Again, this is my personal feeling about it, I totally see the use for your workflow.

[tlaurion]

@jans23 @kylerankin @techge @alex-nitrokey @MrChromebox
Ok, with #919 being in the air, here is my next steps where I need your disagreements/comments/threats :)

• Add mmc kernel modules, pushing newer kernel depending on current old release to the last LTS release (since the x230 has two possible controllers: Ricoh and Realtek controllers) EDIT: PoC under 923
• change mount-usb to integrate/adapt mount-sdcard code and go more general into mounting external storage drives move away to mount-external-storage (able to deal with mmc controllers if present and configured in board and loop on new devices popping up including those new ones). EDIT: PoC under xx30-*-maximized linux 4.19.162 mmc support: add external storage support #924
• change mount-external-storage to be able to deal with encrypted storage EDIT: (currently added under PoC xx30-*-maximized linux 4.19.162 mmc support: add external storage support #924)
• Implement NKSTORECLI mount-external-storage logic
• Implement oem factory reset keygen under Heads with external storage of private key over encrypted storage
• Implement RESET PIN into oem factory reset/gpg factory reset
• Implement Restore of private keys to USB Security dongle (keytocard from encrypted storage)

[saper]

I have a funny idea how to solve this nicely and securely (no private key export in plain). Can we use something else than gpg?

[jans23]

The only other software I know and which is capable of replacing GnuPG is Sequoia. AFAIK HEADS doesn't has Rust in the tool chain yet.

[saper]

What I mean I'd like to use raw APDU interface to the smartcard (and PKCS#11) but not scdaemon interface.

[tlaurion]

@jans23 last time i checked, sequoia was not supporting smartcard?

[tlaurion]

@saper : I'm not sure I understand why this would help the present ticket?

[tlaurion]

I will start attacking this issue in the next weeks, providing testing scripts first then iterate from them with integration.

Reminder: goal is to generate keypair in memory, then copy those keypairs into luks encrypted container and on smartcard after reset of smartcard.

Then to offer possibility to use only Luks container to use keypair in case no USB dongle is avail.

And to restore keypairs to USB security dongle, at OEM factory reset/Re-ownership

[saper]

I understand that this is one of the possible solutions for the customer concern.

I have two slightly different/broader ideas to solve the "I flushed the token down the toilet" problem:

1. Provide a mechanism to securely install the key onto multiple tokens.

Less ambitious:

2. Primary keypair is printed to the screen and/or provided in an easy to memorize form, then it is used to generate actual keys stored on the hardware token(s). If the token is lost, another keypair can be generated. Next level could be revocation mechanism of the lost keypair.

We can surely discuss it outside of this bug (if you prefer to focus on the "generate the key outside of the smartcard" solution.

[tlaurion]

@saper

If:

• master key, signing, auth and encryption subkeys are generated in ram and stored on encrypted container (which decryption key passphrase permits usage)

Then

• subkeys can be used in case of flushed down the toiley/lost in the sea
• subkeys can be used to provision one/multiple keys

The idea here is to propose to the user in factory reset/reownership automatic creation of

• master key
• subkeys
• user/admin pin (passphrase)
• use admin passphrase as luks key passphrase
• partitioning and saving keys to encrypted thumb drive
• copy subkeys to smartcard

Then

• having gpg submenus under heads to use backup to provision X number of keys

But most importantly, implement authentication (detach signature + validation against public key injected in ROM)

• accessing recovery shell when a backup is known to exist
• boot from USB
• flashing new firmware
• unsafe boot

This way, heads with authentication could:

• lock the platform prior of kexec (limiting internal firmware upgrades to Heads with authentication of user only)
• mitigate DoS attacks (wiping disk from recovery shell, flashing invalid firmware, booting whatever from USB)

---

Accessing smartcard content without scdaemon seems nice but would deserve a separate issue, explaining goals, actual limitations of Heads (and gpg for that goal) and a short description of what is proposed/desired to attain that goal.

[jans23]

@jans23 last time i checked, sequoia was not supporting smartcard?

These days Sequoia does support OpenPGP Card.

[hko-s]

@jans23 last time i checked, sequoia was not supporting smartcard?

I've written a set of OpenPGP card client libraries in Rust (https://gitlab.com/openpgp-card/openpgp-card), which will over time be more integrated into the Sequoia ecosystem.

In particular, the openpgp-card libraries will be used in the https://gitlab.com/sequoia-pgp/sequoia-keystore project (Sequoia's future private key store) as the backend for OpenPGP card devices. However, the Sequoia keystore project is still in a pre-alpha stage.
(pks-openpgp-card is an experimental project by @wiktor-k, which is not intended for wider use).

Depending on what you want to do, the https://crates.io/crates/openpgp-card-tools CLI tool might be of interest. It can be used to set up OpenPGP cards, and also to perform cryptographic operations on them. The tool has an optional JSON mode (for scripted setup - or checking the state of - OpenPGP cards).

[tlaurion]

@saper

From gnupg 2.3 news

• New tool gpg-card as a flexible frontend for all types of supported smartcards.

That would permit to get rid of a lot of screenscaping if not all, yet again this needs to be tested.

On slack/matrix, you said that you adding keys from newer version of gnupg on OS made weird behaviors happen under Heads (which is using really old 2.2.21), this was meant to happen. If I look at the same news from gnupg website linked above, and the bugs you reported trying to deal with curves algo and some reported fixes and your experience with dealing with Tails newer gnupg toolchain, it is my hope (we do not want to change things too much here for current use case of Heads which is basically to detach sign /boot content and have those verified at each boot) while supporting as well what users use.

As said in Q&A of your talk at DUG#1, best case here would be to confirm/infirm that newer gpg toolstack fits the need and doesn't bug. Once code is made to securely create usb thumb drive encrypted container and apply current not so hard RSA 4096 subkeys current use case from factory reset, I will see if PoC code permits to deal correctly with keygen for other key material. I was going to use bookworm for this testbed... but this is still 2.2.40 :/

[tlaurion]

Integrated in #1515