Can I use a Yubi Key in place of Librem Key on Librem 13v2

Hardware
1

I have two different Yubi Keys.

YubiKey Security Key NFC

YubiKey 5 NFC

Can I use this in place the Librem Key I wrecked.

1 Like
2

If you’re talking about using them with PureBoot for tamper-evident detection for the boot files, I don’t believe it will work, particularly because there is no LED to indicate if the checks pass or fail.

I personally use the Nitrokey 3C and it works with PureBoot because it has the tamper-evident detection feature built into it.

If you’re using the Yubikey as a general security key for things like PGP, WebAuthn, MFA, passwords, etc., then it will work.

2 Likes
3

Interesting. Didn’t know about this.
Did you have to modify the payload’s script for it to recognise the Nitrokey as a valid device? Because to my knowledge Pureboot (Purism’s fork of Heads) specifically looks for a Librem Key brand as indicated in the kexec_hotp_key file inside the /boot partition. How did you do it?

1 Like
4

I didn’t modify anything with the Nitrokey firmware (v1.8.1) or PureBoot (v30) – everything is stock. I believe you need to reset the TPM and reset the HOTP/TOTP codes in that order to use the Nitrokey security key if you change your OS or switch from the Librem Key.

The Nitrokey 3 has integrity checking and tamper detection as a feature, probably as a result of their partnership to develop the Librem Key and Purism upstreaming the work they put into PureBoot to the Heads project.
You may need to perform a factory reset on your Nitrokey by running nitropy nk3 factory-reset with the nitropy tool. Make sure that you have backed up your PGP keys and can re-import them to your Nitrokey.

2 Likes
5

Thank you. Your reply puzzled me a bit, so I made some experiments with different Nitrokey models (3c/NFC and Pro 2)
You are right: the newer Nitrokey 3c works out of the box, no modification required. It is as if it was recognized as a Librem Key. Same thing with the former generation Nitrokey Pro 2 (from which the LK was derived for Purism)

  • NK Pro 2: I only had to regenerate TOTP/HOTP secret (firmware tampering detection) and re-sign /boot files (because different GPG keys and subkeys) after having exported the pubkey and injected it into the ROM’s keyring

  • NK3: regenerating TOTP/HOTP secret was ok, but I was unable to re-sign /boot with some checksum error message. I don’t know exactly why - it could be either:

  1. the newer algorithm I had chosen may be unsupported by PureBoot 30
    or
  2. I may have to do a complete factory-reset for this to work, but didn’t want to because I would have lost all secrets presently on the device.

What is interesting about using the newer NK3, is that the touch feature - to confirm physical presence - works fine with PureBoot requesting it for some operations.

Another thing to be aware of: if you had used the smartcard-key-luks script to have your rootfs opened via a keyfile and a pin code, it won’t anymore. That’s because the file was encrypted with your previous GPG keys and cannot be decrypted correctly if that key changes with the new device. But you are not locked out: choose a boot option ‘recovery’ so you can open the container with your original passphrase and then delete the cryptkey.gpg file inside /etc/cryptsetup-initramfs/. Then run the smartcard-key-luks script again, so it will recreate a LUKS key slot and keyfile with the new gpg keys.

One thing still bothers me though: what is this file kexec_hotp_key in the /boot partition used for?
Since mine contained “Librem Key”, I thought it was for the payload to know it had to use an LK specifically. Apparently, this is not the case: if I change it for “Nitrokey”, everything works the same. If I leave it blank or even radically remove that file, everythink works fine. This file is not even needed! So why is it there and what’s its purpose if any Librem or Nitrokey models can be used equally?

1 Like
6

I quote myself from my previous post, because I am now able to answer that question.
I combed some of the scripts in the payload’s initrd and I found where it is being used.
It’s in the /bin/gui-init script that a variable HOTPKEY_BRANDING is being set with the content read from this file kexec_hotp_key in /boot (whatever that content is)

# Use stored HOTP key branding
if [ -r /boot/kexec_hotp_key ]; then
	HOTPKEY_BRANDING="$(cat /boot/kexec_hotp_key)"
else
	HOTPKEY_BRANDING="HOTP USB Security Dongle"
fi

then this variable is used to display various whiptail messages such as:

"WARNING: Please Insert Your $HOTPKEY_BRANDING"
"Your $HOTPKEY_BRANDING was not detected.\n\nPlease insert your $HOTPKEY_BRANDING"
"Error checking code, Insert $HOTPKEY_BRANDING and retry"

So basically it is only used for the GUI to request you to insert your Security Dongle, whatever the name of the device contained in that file is. If it doesn’t find the file, it will default to a generic “HOTP USB Security Dongle”

The kexec_hotp_key file is not included in the hashed files for the signed digest, this is why you can modify it or even delete it without the secure boot mechanism to complain about a change.

2 Likes