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

gpg: no default secret key: No public key (Yubikey 4 nano) #641

Closed
kamilr opened this issue Dec 21, 2019 · 9 comments
Closed

gpg: no default secret key: No public key (Yubikey 4 nano) #641

kamilr opened this issue Dec 21, 2019 · 9 comments

Comments

@kamilr
Copy link

kamilr commented Dec 21, 2019

I am newbie with this Heads. I really try to follow all installation instructions, but I stuck on running Qubes 4.0.1 on X230T. I have a problem like:

gpg: no default secret key: No public key
signing failed: No public key

What I did was:

  1. Build Heads without problems.
  2. Flash top chip.
  3. Install coreboot.rom via Heads console.
  4. TPM reset ownership, set up TOTP,
  5. Use Yubikey and generate GPG manually via HEADS settings.
  6. Reflash BIOS with new key, after reboot keyring list is not empty. Additionally in recovery shell

gpg --list-keys

shows keys, but

gpg --list-secret-keys

prints nothing.
7) TOTP after clock synchronization works as expected, but using Yubikey from start prints N/A state after some logs of loading kbx and gpg from CBFS and setting new values.
8) Use menu to boot from usb -> install Qubes 4.0.1, with success.
9) After reboot configuration of default boot menu failed. Also typing "m","u" during booting Heads does not work.
10) I can get into Qubes only via unsafe mode.
11) When I try to sign /boot partition with Yubikey inserted the cited problem from begging of this post occurs 3 times.

What Can I do, to have normal system default boot menu with signed /boot partition? What I missed? After all I can help to upgrade installation instructions, but now I am lost. Many thanks for any help.

Regards

@tlaurion
Copy link
Collaborator

tlaurion commented Dec 22, 2019

Yubikey from start prints N/A state

@kamilr Can you give your board configuration?
Do you see HOTP N/A state?

If using a Yubikey, your board config should not state CONFIG_LIBREMKEY=y
building without that should fix your problem, if I understood it well.

USB security dongles supporting visual attestations are currently: Nitrokey Pro, Nitrokey Storage and Librem Key. Yubikey permits GPG signing of boot configurations, while firmware integrity attestation fully relies on TPM and OTP.

If you do not get any HOTP warnings or prompts asking you to enter your Librem Key, then none of the above concerns you.

From the above I see that you resolved that part of the problem:

gpg: no default secret key: No public key
signing failed: No public key

Now: gpg doesn't show any directly known private key, since your public key is bound to your USB security dongle private key, secured inside of your USB security dongle.

Let me know if that helps.

@kamilr
Copy link
Author

kamilr commented Dec 24, 2019

Thank You @tlaurion for Your response.
Unfortunatelly, I used already prepared configuration for x230 board x230.config. Where, there is no

CONFIG_LIBREMKEY=y

value. Maybe I need to include this with "n" value or delete:
bin_modules-$(CONFIG_LIBREMKEY) += libremkey-hotp-verification from heads/Makefile ?

Do I really need to make a custom board configuration?

I have Yubikey 4 nano. Am I able to use HOTP functionality in HEADS with it?
What is the best scenario to make it work? I am stuck on OS booting with exported and reflashed public key into Heads. Is it not possible to generate keys inside Yubikey and use only Public during boot + Private from pluged in Yubikey?

@tlaurion
Copy link
Collaborator

tlaurion commented Dec 24, 2019

With a Yubikey, you won't have HOTP functionality (visual attestation only for supporting technology models, see above post).
Yet the board configuration is then consequently right, no need to explicitly say it is not needed. So the problem is not that.

@kamilr : So you say gpg --list-keys shows your public key, while gpg can't pick it as your key by default.
1- Is there multiple keys shown?

2-Try something simple from the recovery console (Exit to recovery option).
We will make /boot writable, create a dumb test file, make the USB security dongle known by gpg, and make it sign test file from your USB security dongle, which is roughly what Heads does when signing sha256 digest (sha256 or all /boot files) used against your public in rom to perform verified /boot integrity phase at each boot.
But for that, the USB security dongle needs to be detected and usable. I do not own a Yubikey 4 nano key, so I can't test. Let's see:

mount -o remount,rw /boot
echo "test" > /boot/test
gpg --card-status
gpg --sign --detach test

That should pick your default key and detach sign /boot/test with your private key inside of your Yubikey 4 nano.
Please report:
2.1: Is gpg --card-status reporting your card?
2.2: Is gpg --sign --detach able to sign a file from recovery?

Then cleanup:

rm /boot/test
mount -o remount,ro /boot
reboot

@tlaurion tlaurion changed the title gpg: no default secret key: No public key gpg: no default secret key: No public key (Yubikey 4 nano) Dec 24, 2019
@kamilr
Copy link
Author

kamilr commented Dec 25, 2019

I bought Yubikey, because it was only pointed in installation guide. On the other hand found that 4th gen has OATH HOTP verification with led light as a "visual attestation". Sad to hear that will not work, I need to change my hardware key. Is it possible to work with HEADS without HOTP and not using "unsafe" mode of loading the kernel/boot partition?

gpg --list-keys prints out public content of ./gnupg/pubring.kbx file. As follow:

pub rsa4096 (date) [SC] (expiration date)
(id of the key, probably in hex)
uid [Ultimate] (my string credentials from key)
sub rsa4096 (date) [A] (expiration date)
sub rsa4096 (date) [E] (expiration date)

Ad. 1) Only one public key and assosiated A and E, as above.
Ad. 2) Mounted with success as rw, but when releasing gpg --sign --detach test or /boot/test. The same message occures as in first post:
gpg: no default secret key: No public key
signing failed: No public key

Ad. 2.1) Prints correct information about USB security dongle with Signature, Encryption and Authetication key.

@tlaurion
Copy link
Collaborator

@kamilr

5\. Use Yubikey and generate GPG manually via HEADS settings.

What Heads settings you used? (Sorry I don't use Heads upstreamed code.)
I will try to find what is wrong with the code which should work right.
Can you give me the commit ID you have under Heads doing
cat /etc/config and tag me in this issue please?

@tlaurion
Copy link
Collaborator

tlaurion commented Dec 28, 2019

@kamilr
Was it adding key with r menu option?
I would suggest doing removing keys e menu option and report back (this will factory reset your key, of course).
The code seems right and you public key, inserted in rom, should match the private key in your USB security dongle, unless an error happened in key generation and the private key in your USB security dongle was resetted, but the public key is still your old. Else I do not currently have an explanation.

Please note fingerprint generated and validate that it is there with the l menu option.

@kamilr
Copy link
Author

kamilr commented Jan 2, 2020

@kamilr

5\. Use Yubikey and generate GPG manually via HEADS settings.

What Heads settings you used? (Sorry I don't use Heads upstreamed code.)
I will try to find what is wrong with the code which should work right.
Can you give me the commit ID you have under Heads doing
cat /etc/config and tag me in this issue please?

So the scenario was: Options --> GPG Options --> Generate GPG keys manually on a USB security token.

However, my Heads is based on the last commit from current master branch with ID 8af849c.

@tlaurion
Copy link
Collaborator

tlaurion commented Feb 5, 2020

@kamilr : please get a clean checkout and build again and post screen captures of the observed problem with the exact commands proposed above and their output.

If the issue is resolved, please close accordingly.

@tlaurion
Copy link
Collaborator

tlaurion commented Mar 9, 2020

@kamilr Please reopen if not fixed upstream

@tlaurion tlaurion closed this as completed Mar 9, 2020
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

2 participants