I am planning for the scenario where I lose the librem key or it is damaged. In that case I need to create a new one (or have one on hand). If I need to contact tech support I will but this seems like the type of thing that the community would benefit from so I’m posting here.
I purchased a second librem key and followed the same procedure that I used to transfer all of the keys to the first one. I did not export the public key from the librem key and create a stub import of the public key in my gpg folder since the second librem key is using the same set of keys as the first one.
[EDIT: the issue is related to the second key being too new and not recognized by out of the box libraries. See workarounds below. I am also setting up multiple laptops to use the keys in the case that one is lost or damaged.]
Alas, the second librem key does not work. gpg --card-status does find both keys with minor differences. (I’ll post more later). The first key works but pkcs15-tool cannot find the second one.
@jeremiahmoree The reason for the differences is that first Librem Key you have Is a first generation Librem Key (LK), developed and manufactured together with NItrokey and the second one you got is a Librem Key USA, made by Purism in the US.
That explains the differences you see in the Device and Manufacturer ID numbers.
As for your specific Issue GPG operations and pkcs are handled by different deamon and drivers.
GPG is handled by scdaemon which recognizes both models of the Librem Key with no problems.
As for pkcs15, whatever application use for pkcs it is likely that it depends on the CCID driver, to be specific libccid.
libccid does not yet recognize the Librem Key USA out of the box (but there is a workaround).
We have submited an upstream patch for the Librem Key to be recognized by libccid, and that patch has been accepted so in next versions, we should have support out of the box.
In the meantime the workaround is here, it was for debian based systems, but it can be adapted for other distributions:
[EDIT 2: this comment was created before I realized that I was working on two different systems and the changes from the previous comment were not applied to both. Recommend ignoring this comment.]
Thank you, the card works better now but only as root. [EDIT - pkcs15-tool still doesn’t recognize the new key though as root or non root. I was wrong about root access working. Sorry. this whole post is a mess. I’m deleting bad information to clean it up]
On my primary system I am using the original key as my non-root user with pkcs15 but the second key is not working. I have fresh .gnupg folders with the public key imported for both root and the non-root user so the process and data should be the same for both and the key imported into both librem keys is the same.
I’m on Kubuntu 19.10 and have added the udev rules as mentioned here (watch out for weird quotes)
also tried setting GNUPGHOME to ~/.gnupg as mentioned somewhere in these posts
Ah. be careful if you copy/paste from these forums. Some of the double quotes are changed into other characters. I had to fix them to be “real” double quotes in the udev rules.
for anyone reading this my librem key was showing as /dev/hiddev0 until the udev rule was working. Now I can’t seem to find a device for it. maybe /dev/input/event0 since dmesg shows the key as …/input0
The group access on /dev/input/event0 doesn’t suggest that it should work for my non root user but I must be missing something.
The following doesn’t find your device but it may answer the question “Is device the right one?”
sudo udevadm info -a -n device | grep -E 'idProduct|idVendor'
where in this case device would be /dev/input/event0
but only look at the first idProduct and idVendor and maybe retry but the next time pipe to more and examine more closely if you think you found the right device. However on my computer event0 is apparently the “sleep button” and event1 is the “power button” etc. !
Also, you could try temporarily adding SYMLINK+="xyz" to your udev rule and then see where the symlink points.
Oh. that’s interesting. I have the two keys but there are 4 devices listed on my system after the experiments of the last few days. I found them to be /dev/hiddrawX. It looks like some are leftovers from previous attempts to get them working.
Thank you for bring that file up again. I have multiple systems and multiple OS installs. Those changes we not on all of them. The second key now works on my primary system. In summary here is everything I did to get the second key working:
modify /etc/libccid_Info.plist
create /etc/rules.d/60libremkey.rules
correct invalid double quotes generated by copy/paste from these forums
Unfortunately, I seem to have broken the librem key setup on the other systems. Neither the first nor the second key work. After I fix, I will post any interesting gotchas to this issue in case anyone else ends up in the same situation. I will also clean up the in between posts with notes about what I did wrong to help future readers find good information quickly.
This can be normal for USB devices. If a USB device offers or requires more than one type of functionality then it can be that that results in more than one device.
My USB keyboard gives two /dev/hidrawn devices. My USB audio gives two /dev/snd/pcmC1xyz devices.
When I plug my USB mobile broadband dongle in, I get no less than four /dev/ttyUSBn devices.
I suspect neither Librem key has ever worked on my PureOS 9 install. I had not deleted the private keys from my .gnupg setup and I think that is what was being used this whole time. Now that I have removed the private key neither the first nor second librem key works. i get the message about not finding any card readers. Since I have this working on kubuntu 19.10 with both keys it has to be a problem in the user setup in PureOS.
To troubleshoot I have made both systems match settings as much as possible.
copied /etc/libccid_Info.plist from the working installation to PureOS
copied the /etc/udev/rules.d/xxxlibremkey.rules also
Have restarted a few times for various reasons
To remove the private key I delete/move the .gnupg folder and then create a new one and use gpg --import as I did in kubuntu. For some reason pureos is not working the same way.
The only difference I can see so far is that in /etc/libccid_Info.plist the PureOS version seems to be behind the kubuntu version. the differences are that the new version has more entries which I wouldn’t think would be a problem but there is also a version line that is not the same …
1.4.31 vs 1.4.30
these instructions don’t explicitly cover the use case of moving to a new system with the key–in fact when I review I don’t see anything about deleting the private key from my local system which I thought I had read somewhere in the librem key docs…
I think we should work out this use case and add it to the docs.
I found another difference that seems to be a key component. The non working systems are not running pcscd.socket. This is because I found a post or two that stated pcscd and scdaemon were incompatible during my initial troubleshooting.
I had disabled pcscd but pcscd.socket seems to be a separate service. Leaving pcscd off I can enable/disable pcscd.socket and repeat the working/non working state of using the librem key. Turning on/off pcscd doens’t seem to do anything to the use of the key.
Some quick research suggests that the incompatibility is different than I understood it to be or just wrong information. I have turned pcscd and socket back on on all systems.
I have the second librem key working for LUKS and logins (using poldi) but it does not work for PureBoot/HEADS. When I try the second key at boot the background is red and it says :
TOTP: 968748 | HOTP: Invalid code
I have searched menus and even told it to resign the files in boot but it’s always red. I wonder if the HEADs setup is storing the serial # for the key?
On this issue, we have submitted a patch for libccid. A new version of libccid with support for the Librem Key USA, has just reached Debian Testing, and it will soon bee in pureOS Bizantium.
The version is libccid 1.4.32-1 , I have already tested it and opensc now works out of the box with the Librem Key USA