[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
in regards to secure boot with multiple keys: the short answer is that it will not work. there are counters in use which will not match up between the two keys even though the private key is the same. the solution I am using is in the case of losing the primary key I reset the HOTP secret with the backup librem key in order to bring it into service.
Would this also mean I can’t use 1 LibremKey on 2 devices? I have a Librem 13 that I configured my LibremKey for and now that the Librem Mini arrived, I was going to use the same GPG keys and LibremKey to verify both devices.
I am using 1 librem key with multiple laptops. The only issue is that using both of them at the same time becomes tricky–not impossible though. Since NOT all subsystems in pureos/debian/etc will use the key I have to type passwords anyway.
I also have a backup librem key which will work the same but has to be ‘re-applied’ to the pureboot process in the event that I need it.
I could use both keys with both laptops but one is in a safe (for safe keeping).