-
-
Notifications
You must be signed in to change notification settings - Fork 187
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
Add GPG smartcard keygen feature #546
Conversation
This change updates the very basic GPG smartcard feature in the GPG GUI so that it can properly support generating a key from within Heads. It offers the user the option to copy the generated GPG public key to a USB thumb drive so it's not lost as well as the option to reflash the current Heads BIOS with this new public key added to the keyring. I've moved the common functions required to flash a new ROM with GPG changes into a shared function at the top of the script.
Did: Then followed steps. Generation was successful. |
@tlaurion I suspect you didn't get the prompt because your GPG session didn't exit with an error code of 0, maybe because you typed 'exit' instead of "quit"? I'm not sure. I opted to go with key generation instead of a full factory reset, so as not to wipe out any HOTP secrets or other information that might be on the key, but I think adding a "factory reset" option to the main menu in gpg-gui.sh that calls your script would be useful for people who want that full reset. Also, I hadn't reviewed your script yet so I wasn't aware I was reinventing the wheel! I'm still not sure about how I feel about using a /boot/oem file to track state. |
@kylerankin, that OEM file hijacks the rest of the normal flow and continues across multiple boots (gpg factory reset injects key and reflashes, reboot. Which requires HOTP/TOTP reseal. Then cascades into Disk Unlock Key to be redone if it was previously set (kexec_key_devices.txt presence).TPM sealing of LUKS header, reboot. Then the reencryption of LUKS container happens, followed by the Disk Recovery Password change and finally TPM reownership. Reboot. Done.) It can't be done through a wizard which takes the user by the hand without keeping an external state between reboots. That file is even unseen by signature validation until it is deleted. Any real concerns on keeping state in an external file for that? Sent from my Galaxy S3 using FastHub-Libre |
@tlaurion fair enough, that's fine with me. I don't have any concerns (as long as it can be bypassed in case the deletion didn't work or the file shows up again accidentally). |
@kylerankin : ping me here when you merged your latest changes |
This mimics tlauion's OEM work in the sense that a user (or OEM) could choose this option and it will reset an OpenPGP smart card and automatically generate a random key on it. The idea is to allow an OEM to set up a Librem Key and Heads on a machine before shipping with a random key, so the user can test for tampering when they receive the machine, and then the user can choose to reset all of the keys with their chosen keys after that fact.
@tlaurion The "Add a "Factory reset" GPG option" change is pushed. |
@kylerankin: are we ok with both being present (#511)? Would be ready to merge. Sent from my Galaxy S3 using FastHub-Libre |
@tlaurion Yes I'm OK with both of my options and your option being present in the menu. |
This change updates the very basic GPG smartcard feature in the GPG GUI
so that it can properly support generating a key from within Heads. It
offers the user the option to copy the generated GPG public key to a USB
thumb drive so it's not lost as well as the option to reflash the
current Heads BIOS with this new public key added to the keyring.
I've moved the common functions required to flash a new ROM with GPG
changes into a shared function at the top of the script.