Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Signing /boot without physical gpg key device #921

Closed
bencejuhaasz opened this issue Dec 8, 2020 · 6 comments
Closed

Signing /boot without physical gpg key device #921

bencejuhaasz opened this issue Dec 8, 2020 · 6 comments

Comments

@bencejuhaasz
Copy link

Can I sign /boot with a software gpg key from a usb stick, without specific hardware for storing keys ? I can import my public key but the UI won't sign anything or import my private key, only from a special smartcard device.

@tlaurion
Copy link
Collaborator

Not in current Heads codebase. A USB security dongle is required, for which signing operations depends on gpg --card-status and where private key is on external dongle.

Any implementation ideas on workflow? The private key could be injected in rom and only require the user to type associated passphrase... But that would lower security.

How to detect and propose to user to connect USB disk to load private key seemlessly?

@bencejuhaasz The private key would be in encrypted LUKS container on USB disk?

@fhvyhjriur
Copy link
Contributor

I know at least one person that would like to test out heads without the need of a security dongle. This person know that its insecure to have private and public key on a unencrypted usb drive just as files that everyone can read.
Recently there is no insecure "find out if you like heads before spending money for a dongle"-mode. Such a mode would be nice for testing heads.

@tlaurion
Copy link
Collaborator

tlaurion commented Jan 21, 2021

Iterative thought process happening.

Corrently, all heads codebase but the following takes into consideration the use of a smartcard, calling gpg without a homedir, where .gnupg is created locally (/.gnupg) at Heads runtime and solely in ram.

The following are the exception, specifying homedir to not interfere with the rest of codebase which implied locally created /.gnupg dir for smartcard operations to rely on user's keys. The following is called to support all iso related disto key validation, so that booting Qubes/Tails iso actually trusts distro keys implicitly. key-init is called really early in init, and then kexec-iso-init is called on demand when booting from USB from Heads menu:

user@x230-master:~/heads$ grep -Rn homedir initrd/
initrd/bin/key-init:11:gpg --homedir=/etc/distro/ --import /etc/distro/keys/* 2>/dev/null || true
initrd/bin/key-init:13:gpg --homedir=/etc/distro/ --list-keys --fingerprint --with-colons|sed -E -n -e 's/^fpr:::::::::([0-9A-F]+):$/\1:6:/p' |gpg --homedir=/etc/distro/ --import-ownertrust 2>/dev/null || true
initrd/bin/key-init:14:gpg --homedir=/etc/distro/ --update-trust 2>/dev/null || true
initrd/bin/key-init:17:gpg --export | gpg --homedir=/etc/distro/ --import 2>/dev/null || true
initrd/bin/kexec-iso-init:20:gpgv --homedir=/etc/distro/ "$ISOSIG" "$MOUNTED_ISO_PATH" \

We could "replace" a smartcard by a LUKS encrypted container's partition, having local, non homedir bounded gpg calls, taking into consideration that /.gnupg is created from:

  • existing over crytpsetup luksOpen call being embedded into mount-usb logic, so that if partition is tested positive to cryptsetup isLuks, is decrypted with user provided passphrase, mounted rw and then /media/.gnupg being softlinked into /.gnupg so that changes are also saved back into keyring if needed.
  • Possibliy protected by additiona; PIN on private key if user decides to protect it (should it be forced?)

Code changes that would be required under Heads:

  • mount-usb logic changed to support cryptsetup partition and mounts it (where booting ISO from that will just not work on kexec calls)
  • key-init changes applied if GPG_CARD_IS_LUKS in board config (and consequently under /etc/config) with above detailed logic
  • gpg-gui, oem-factory-reset and other scripts calling gpg --card-edit should do only if not GPG_CARD_IS_LUKS in board config (exported from /etc/config)

My thought experiment is that all other gpg calls are plainly depending on bindings between public key and private key identity being offloaded to card ID. So gpg here is simply requesting that smartcard presence linked to public key, to offload its operations after the mapping is done through gpg --card-status so that gpg knows if private key is local or on smartcard. So the rest of the logic should not change, the resulting changeset being minimal.

Thoughts, better idea?
@bencejuhaasz @fhvyhjriur @MrChromebox

@tlaurion
Copy link
Collaborator

The outcome of this should be used to document linuxboot/heads-wiki#62

@bencejuhaasz
Copy link
Author

I've found a soultion since. I just had to remove the line checking for a physical device, and import my encrypted key with gpg, saying "N" for changing things. But sadly now I can't use heads, as I've switched to arch linux, so I'm locked to secure boot.

@tlaurion
Copy link
Collaborator

Implemented under #1515

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants