I have been using the Nitrokey 3A NFC for several things, FIDO2 as well as smart card for GPG and SSH. While FIDO2 still works, the smart card device has not been recognized since the beginning of this week. It could be related to my trials to get firmware updates for Nitrokey HSM allthough those are still recognized by SmartCardShell. NitrokeyApp 2 still recognizes Nitrokey 3A NFC, but udating the firmware fails with the following error:
If I unplug it and reconnect it, FIDO2 still works and I can repeat the process with the same result. Any suggestions on what I could do?
I think this might actually be related to using the Nitrokey HSM, because SCSH also shows
GPError: Card (CARD_CONNECT_FAILED/0) - “No card in reader or mute card.” in /home/…/CardContact/scsh/scsh-3.18.60/keymanager/keymanager.js#3346at /home/…/CardContact/scsh/scsh-3.18.60/keymanager/keymanager.js#3346
when Nitrokey 3 is working but SCSH doesn’t have a problem connecting Nitrokey HSM, when I can’t access the Nitrokey 3 smart card.
the issue is likely using gnupg (note: the standard is called pgp - pretty good privacy - the common used implementation is calld gpg - gnupg - gnu/privacyguard)
unfortunately gnupg has a very bad habbit of lazily grabbing a lock onto a smartcard (no matter if via built-in scdaemon or when using disable-ccid in scdaemon.conf via pcscd) and keeps onto it until either
the token is replugged
gpgconf –kill all is called
systemctl stop pcscd is called
using gpg-card and issue the command reset followed by immediate quit
I analyzed this digging thru the gnupg code while having a similar issue with my yubikey trying to use it with all its features (pgp, piv, fido) and learned that gnupg doesn’t properly release the lock.
I reported this to gnupg - but its maintainers have the rather strange attitude of “we become the de-factor standard of pgp - if you want to use pgp - use gnupg - and gnupg only! we refuse to change our code - and also refuse to accept this report as a bug of our code as it works fine as long as you stay within gnupg” - sorry to call them out but they’re quite some ignorant assholes
this can be repeated very easy: use a fido+pgp capable token - register it in your browser with any fido website - use some gpg command accessing the token - switch back to your browser and see how the token is no longer available until replug
tl;dr: just stay away from GnuPG - if you want to use PGP on your token: use other implementations that handle token locking and lock release properly
as for firmware update: I noticed it seem to work best when doing it right after replugging the nitrokey before using it for anything else
also: make sure you have the udev rules installed or execute firmware update as root
None of these suggestions has any effect on my situation, I tested them and they did not resolve the issue. While I understand the frustration I would still prefer to not read insults against people clearly benefitting society a lot.
I will look for other PGP implementations and test, whether that will resolve the issue. It is likely I cannot use them because some of the software I need to use might not have integration for something else.
And yes I set up udev rules. On another device, firmware update works even without root. So it is definitely a software issue on my Ubuntu.
it’s not PGP as a standard - it has lot of good ideas although barely properly practiced in the real world
the issue is its implementation GnuPG - and it’s not just me to criticize it - if you read “they have to get called out for thier crap” as “insult towards who society(?) benefit from” … well, which society? those handful of crypto-nerds here trying to get thier head around PGP?
if GnuPG wouldn’t be so broken but play by the standard its de-facto implementaiton it became my call out wouldn’t be necessary
also - to quote them: “we wish sequoia to fail” - that’s not just anti-competitive - that’s actively denying a standard by denying other implementaions of said standard - and for this they have to get called out for
I can confirm, that this is really an issue introduced by the GnuPG developers.
They just grab whatever looks like an OpenPGP smart card and break everything else. And they resist to change that. They even refuse to integrate other card implementation, because they want to promote their own OpenPGP card standard. We tried to integrate the SmartCard-HSM, got refused and had do develop our own solution. We even offered to pay them to allow the integration.
Unfortunately the Sequoia guys are not really better.
Thank you, I had disable-ccid in it, but not pcsc-shared. It seems to resolve the issue for now, but I will wait a bit, as last time it also seemed to be a temporary solution.
Unfortunately it is not resolving the issue. What I have to add to this discussion: I was using it with GnuPG for a little less than a year without any issues. But when I started experiments with the Nitrokey HSM it suddenly stopped working. So even though it seems to be a GnuPG issue, it seems to be a corner case that was triggered by something I did during the HSM tests.
the Broadcom device you noticed will be an integrated smartcard/NFC reader in the laptop. If you don’t need it for the time being, it can be blacklisted.
I don’t think it’s necessary to uninstall packages. pcscd is triggered again by pcscd.socket; stopping both, then killing active processes should suffice.
