Nitrokey Start forgets keys

Nitrokeys
1

Hello all,

In the recent days my Nitrokey Start “forgot” my keys 3 times. I usually use the key to sign commits on GitHub. Today I was able to sign my very first one, then I removed the key from the PC, had some other work and when I tried to sign the next git reported the below:
error: gpg failed to sign the data
fatal: failed to write commit object

The ‘gpg --card-status’ showed the following:
Signature PIN ....: forced
Key attributes ...: rsa2048 rsa2048 rsa2048
Max. PIN lengths .: 0 0 0
PIN retry counter : 0 0 0
Signature counter : 0
KDF setting ......: off
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]
General key info..: [none]

The key I wanted to use was generated last night after I faced the exact same problem. I thought I entered the wrong PIN a lot of times (however the signing happened before that, so it wasn’t too logical). So now I tried to unblock using the ‘unblock’ command and I got the below:
gpg/card> unblock
gpg: OpenPGP card no. D2***************00 detected
gpg: Reset Code not or not anymore available

If I try to reset the PIN in admin/passwd, I get the below message:
Error changing the PIN: Operation not supported by device

Because I moved the keys from the PC I can’t export them again.

2

Hi!

I would like to try to reproduce that. Could you provide versions of:

  • Start firmware (should be provided in the device’s USB name - see dmesg -w);
  • GnuPG (gpg2 --version)?

Additionally, have you used user mode? This is the device mode, where Admin PIN is unused at all.

3

Hello!

Thank you for getting back to me this quickly.
The firmware on the device is RTM.7, updated in the middle of December
The GnuPG version is 2.2.17, libgcrypt 1.8.5.

No, I didn’t use the user mode, I have separate PIN for user and admin.
Oddly the device keeps my name, gender, language, but the keys are vanished.

4

Thank you for the details! Will check this today. In summary, the scenario is as follows:

  1. Generate keys on the PC
  2. Move keys to the device
  3. Remove device, restart system
  4. Insert device, sign commit
  5. Remove device
  6. Insert device after a longer delay
  7. Sign commit - failure

Additionally:

  • user mode was not used;
  • unblock command is not working;
  • reset operation is not possible.

Please correct me, if I have missed anything.

I am concerned about the returned PIN lengths, and that the reset is not working. This loosely reminds me about the user mode, but I do not remember the details right now. Will check and get back to you.

5

To be exact, I did the followings:
1.) I did a factory reset to get into a clear state
2.) Generate keys on PC, move them to device
3.) Change PINs (Admin and then User)
4.) Remove device, reinsert, sign commit
5.) Remove device, let it rest for a longer time
6.) Reinsert, try to sign commit and that failed

For your concern: I’m 100% certain I had user and admin PIN as well every time when the reset happened, and every time when I lost the keys the PIN lengths were 0 0 0.

6

I did some tests yesterday and today with directly flashed RTM.7 (FSIJ-1.2.14), including leaving it overnight, and on GnuPG 2.2.18 everything seems normal.

I will try once again with an updated sample (RTM.x->RTM.7), and (now outdated) GnuPG 2.2.17.

  1. Just a sanity check, are you setting the right expiration date for the key? (it should not self-delete itself though in the event of expiry AFAIK).
  2. Have issue occurred again lately?
  3. If possible please set up scdaemon logging with copying this scdaemon.conf file to your ~/.gnupg/ directory, and changed path to /home/<your login>/.gnupg/scdaemon.log. When the issue occurs please attach the log. Do not use secret PINs since setting this, as all communication with smart card will be included there.
  4. Could you use the device on another machine only? If issue would occur as well then we could safely reason this could be hardware related.
  5. For a full firmware test you can run the GNUK’s tests - let me know, if you are interested - I will make a guide then. It will delete all user data on the device though.
  6. (edit) Last thing - you can try to run isolated GnuPG installation with gnupg-docker and confirm this is not an issue of your OS.
  7. (edit) Additionally, is OpenSC tooling returning the lack of keys on the device as well? Or 0-length PIN for that matter (pkcs11-tool -L).
7

I have asked about this on GNUK’s mailing list, and confirmed this might be a USB communication issue, which might lie in the hardware. However I suspect this is software related - parallel access to the device could result in such a behavior - could you stop other applications/services using smart card, and see if the situation improves?

  1. In case you have set up the scdaemon logging already, it can be disabled for the time being by renaming the scdaemon.conf file to any other name and executing gpgconf --kill scdaemon.
  2. The following will disable OpenSC access, and leave GnuPG working - these often compete for the device access:
sudo systemctl disable pcscd pcscd.socket
  1. On the next issue occurrence please post full output of the following commands:
  • gpg2 --card-status (and second time with enabled scdaemon logging if possible)
  • To enable the below pkcs* commands (no need for posting output of these; please reinsert device after running that):
sudo systemctl enable pcscd pcscd.socket 
sudo systemctl start pcscd pcscd.socket
  • pkcs11-tool -L
  • pkcs15-tool --list-keys

Reposting full answer from the gnuk-users at gnupg.org mailing list for the future reference. From NIIBE Yutaka:

Apparently (0 0 0 and 0 0 0 and 0 and triple [none]), gpg was unable
to get information from scdaemon. It looks like USB failure.
Unfortunately, important information is missing. Full output of gpg
–card-status should be available, which includes information about
method of accessing the token (PC/SC or internal CCID driver).

Edit:
Note: this is alternative approach, not tested extensively and with possible compatibility issues or security regression; please check earlier solution first.
For the future reference, this scdaemon patch for shared access pushed to FreeBSD ports may solve the parallel access issue as well:

Longer discussion in this topic:

1 Like
8

I didn’t use the device in the recent days to avoid unnecessary key-regeneration. The keys were valid till 2024.01.14.
What I did yesterday is a factory reset, plugged the device out and in again, flashed the RTM.7 firmware again, then moved the new keys to the USB device.
Today I used those keys on another machine, plugged in and out the device a few times and I still have everything as I set yesterday.
I’ll check if I run into the same issue again, if so, I’m ready to run the GNUK’s tests.

Thanks for all the information and idea you shared, I think there is plenty of things I can check or do to get the root cause of this misbehaviour.

1 Like
9

I’m suspecting a software error, but can’t narrow down to the firmware or the gpg on one of the machines I use. Things I observed in the recent few days (on machine A):
One day no issue happened, I plugged out and in the NKS a few times and was able to sign the commits. The other day I couldn’t sign once, then I restarted the gpg-agent and the issue is solved.
Today I try to use the key again and I receive the

    error: gpg failed to sign the data
    fatal: failed to write commit object

I am able to list the keys on the device with gpg --card-status
So, I restarted the gpg-agent, hoping that it will solve the problem again, but it didn’t, I still get the same message. Thought it might be an already discovered bug, so I updated gpg. Now I have

    gpg (GnuPG) 2.2.19
    libgcrypt 1.8.5

Unfortunately it didn’t solve my mysterious phenomenon, I still get the same output.
Now I tried to use the command you gave me and run into the following:

    peter : ~/Downloads/gitprojects/$ pkcs11-tool -L
    Available slots:
    Slot 0 (0x0): (GetSlotInfo failed, CKR_DEVICE_ERROR)
    peter : ~/Downloads/gitprojects/$ pkcs15-tool --list-keys
    Using reader with a card: Nitrokey Nitrokey Start
    Failed to connect to card: Reader in use by another application

It tells us what’s the problem, so I ran gpgconf --kill scdaemon, after that the pkcs15-tool --list-keys works, but a moment later I still can’t sign the commit. Tried to restart the agent, again, with gpg-connect-agent reloadagent /bye, but had no luck.
It seems to be a software problem, rather than a hardware defect.

The `pkcs11-tool -L` gives the below output (after killing scdaemon)
    Available slots:
    Slot 0 (0x0): Nitrokey Nitrokey Start
      token label        : User PIN (OpenPGP card)
      token manufacturer : OpenPGP project
      token model        : PKCS#15 emulated
      token flags        : login required, rng, token initialized, PIN initialized
      hardware version   : 2.0
      firmware version   : 2.0
      serial num         : f----------3
      pin min/max        : 6/127
    Slot 1 (0x1): Nitrokey Nitrokey Start
      token label        : User PIN (sig) (OpenPGP card)
      token manufacturer : OpenPGP project
      token model        : PKCS#15 emulated
      token flags        : login required, rng, token initialized, PIN initialized
      hardware version   : 2.0
      firmware version   : 2.0
      serial num         : f----------3
      pin min/max        : 6/127

I’ll remove OpenSC to see if that solves this all.

10

It should be enough to disable the OpenSC service with:

sudo systemctl disable pcscd pcscd.socket
11

Unfortunately neither of them helped, I still couldn’t sign the commits. In the meantime I checked on another machine and there everything works. So it must be something with the software/s.
I’ll run a few other tests to find out the difference.

12

After 2 weeks of testing it seems the GPG Tools (https://gpgtools.org/) caused the issue on the machine where it doesn’t work, and as it wasn’t installed on my PC, it didn’t do there. I forgot I installed this tool a while ago.
It seems to be a user mistake, sorry for it.

1 Like
13

Thank you for retesting! This is really a valuable knowledge, and will make use of it in the future troubleshooting.
So to summarize, you probably had two GnuPG installations (as GPGTools contains its code) competing between themselves in accessing the smart card - would that be right?

14

Exactly. I had GnuPG installed, and later I also installed the GPG Tools, they had a race condition and blocked access in my case.

1 Like