search

linuxboot / heads

A minimal Linux that runs as a coreboot or LinuxBoot ROM payload to provide a secure, flexible boot environment for laptops, workstations and servers.
https://osresearch.net/
GNU General Public License v2.0
1.42k stars 187 forks source link

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

Closed tlaurion closed 11 months ago

tlaurion commented 4 years ago

Current customer concerns:

Solutions:

EDIT: implementation plan here: https://github.com/osresearch/heads/issues/771#issuecomment-740850208

tlaurion commented 4 years ago

@alex-nitrokey @kylerankin @MrChromebox : Thoughts?

alex-nitrokey commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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:

Thoughts?

alex-nitrokey commented 4 years ago

I would adapt this to

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 commented 4 years ago

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

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...):

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

@alex-nitrokey thoughts?

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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:

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

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 commented 4 years ago

@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:

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:

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 commented 4 years ago

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

alex-nitrokey commented 4 years ago

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 commented 3 years ago

@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 :)

saper commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

tlaurion commented 1 year ago

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

tlaurion commented 1 year ago

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

tlaurion commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@saper

If:

Then

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

Then

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

This way, heads with authentication could:

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 commented 1 year ago

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

These days Sequoia does support OpenPGP Card.

hko-s commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

Integrated in #1515