Keytocard does not delete my keys from computer

Nitrokeys Misc
1

Hello there,

I followed the guide from your support page to create my GPG keys and move them to the Nitrokey Pro 2. After completing the tutorial, I noticed with gpg2 -K that my private keys are still on my laptop. They are also on the Nitrokey so the keytocard worked, but I didn’t get any error message so I don’t understand why the keys are still there.
I use GnuPG 2.1.11

Also, it’s not possible to use Enigmal since there is no stub keys in my keyring.

I tried this both with my current keys and new created ones.

Cheers

2

Are you sure they are still there? If the (secret) keys are marked with a > then that means they are referenced (i.e. on the device), for my nitrokey start using gpg -K:

ssb>  ed25519/0x8XXXXXXXXXXX3FB14 2020-03-13 [S] [expires: 2021-03-13]
ssb>  cv25519/0x2BXXXXXXXXX78E9 2020-03-13 [E] [expires: 2021-03-13]
ssb>  ed25519/0x8XXXXXXAXXXX8AB 2020-03-13 [A] [expires: 2021-03-13]

You can encrypt some tekst to yourself with gpg -e , unplug the device and see if you can get the original tekst back, if you can with the device not connected, then your secret keys are there.

3

Yes, there is nothing after both sec and ssb. And I tested this the first time with Enigmail. Even with the key unplugged it worked, so the secret keys were there.

I also tried to generate directly a new key set on the Nitrokey because I was sick of it not working. And I got a gpg: key generation failed: card error. I don’t know if this could be a hint on why I couldn’t move properly my secret keys.

So far, I cannot use at all the Nitrokey with GPG. It’s quite frustrating. Any workaround?

Thanks

4

Hi, what kind of OS are you using ? ( asking because I am more familiar with macOS/FreeBSD )
( I am assuming that gpg is gpg v2 or a link to it )

  • have you tried gpg --card-status and you receive a valid answer ?
  • have you tried gpg --card-edit then gpg/card> admin ?
  • what kind of keys are you generating ? RSA… ( Some key types don’t work )
  • are the key-attr valid against the keys you are generating ?
  • can you generate gpg/card> generate the keys
  • Have you enabled the agent ? (use-agent in ~/.gnupg/gpg.conf )
    Now let’s see how far you get …
5

Thanks @Peacekeeper for this thorough debugging check-up.

OS: Trisquel 8.0 (Ubuntu 16.04 derivative)
GnuPG: 2.1.11

Answering in a ordered way:

  • Yes, I got a normal and valid answer
  • Yes, I was also able to edit the personal information fields with this command (name, language pref…)
  • First, I had RSA 2048bits that I tried to move with keytocard. Then, I tried to generate directly on the Nitrokey both RSA 2048bits and 4096bits which yielded the same gpg card error
  • Initially the key attributes were rsa2048 and I tried the 4096bits generation. I got a message like the key attribute were modified to match the key generation request. And it did, even after the card error, I checked with gpg2 --card-status and the attributes were now rsa4096. The same when I tried 2048, they changed accordingly but the error was still there. Now the attribute is rsa2048 and I just tried again to generate a 2048bit key but I still got the same error.
  • When I do gpg/card> admin and gpg/card> generate, I can specify the key size, the expiration date and the identity. Then, the Nitrokey starts the generation and eventually stops yielding the error message
    gpg: key generation failed: Erreur de carte Échec de génération de la clef : Erreur de carte
    Translated as: gpg: key generation failed: card error. Generation of key failed: card error.
  • I just did. So, I started over with my existing keys. I followed the procedure with keytocard again but I got the same problem. The keys are move onto the Nitrokey but there is no stubs on my hard drive (checked with gpg2 -K). I also try the generation again on the key but I got the same error message.

Is there something in my gpg.conf that could prevent the Nitrokey to work properly?

default-key 0xyyyyyyyyyy (my subkey for signing because my primary has just certification usage and I keep it on a separate media).

#default-recipient some-user-id
#default-recipient-self

#group mynames = paige 0x12345678 joe patti

#auto-key-locate local,pka,dane

keyserver-options no-honor-keyserver-url

#no-escape-from-lines

#no-greeting

use-agent

no-emit-version
no-comments
export-options export-minimal

keyid-format 0xlong
with-fingerprint

list-options show-uid-validity
verify-options show-uid-validity

personal-cipher-preferences AES256
personal-digest-preferences SHA512
default-preference-list SHA512 SHA384 SHA256 RIPEMD160 AES256 TWOFISH BLOWFISH ZLIB BZIP2 ZIP Uncompressed

cipher-algo AES256
digest-algo SHA512
cert-digest-algo SHA512
compress-algo ZLIB

disable-cipher-algo 3DES
weak-digest SHA1

s2k-cipher-algo AES256
s2k-digest-algo SHA512
s2k-mode 3
s2k-count 65011712

6

Hi!
I am concerned about your GnuPG version - latest is 2.2.18. Could you update?
Alternatively, if you are familiar with Docker, you can run quick tests with:

./docker-build.sh --build-arg GPG_VERSION=2.2.18
./docker-run.sh

Default setting is to take log from the smart card communication, including user PINs. If you could reproduce this on the latest GnuPG, please send the logs (and change the PINs to default ones).

Logs could be taken with your version as well, though there is rather no point in debugging old software.

About private keys being present, these are left on PC in case user is not saving the changes at the end of the procedure and only then, otherwise it is a GnuPG bug.

Edit: Nitrokey Pro2 might be not supported by GnuPG with this version (2.1.11 was released in 2016.01), since it uses OpenPGP v3.3 released in 2017.08.

7

Hi,

I’m not familiar with Docker. But I can give it a shot. Two questions though:

  • My distro has already a docker.io package 18.09.7, can I use this one instead of the one from the script?
  • Installing Docker and running the latest version of GPG inside it will not impact my current GPG installation and settings, right? I don’t really want to mess with the default installation of GPG, being a quite critical component of the OS.

Edit: Nitrokey Pro2 might be not supported by GnuPG with this version (2.1.11 1 was released in 2016.01), since it uses OpenPGP v3.3 released in 2017.08 1.

So it’s highly possible that the GPG version is the issue.

EDIT: After struggling with my own .gnupg folder (I think I messed up too much with it) and seeing this Docker step, I prefer to quit because I already spent too much time on this. I contacted Nitrokey support to return the key. Maybe I’ll buy a Nitrokey start later on, which is compatible with my GnuPG version. Thank you for the support. Perhaps, you could indicate on the support page for the Nitrokey Pro 2 that it requires a more recent GnuPG version to avoid all this headache for future customer.

8

I understand. I think this is a good suggestion to provide the versions on the device’s first use page. We do so in another place (FAQ) already.

@nitroalex Could you make this change please?

As for the Nitrokey Start, the chance for being compatible is higher, though some latest features might not work as well. Still I want to underline we support only latest LTS releases of major Linux distributions, and always recommend using latest applications versions. Development of the latter is active, and besides features being added, crucial security fixes are provided.

Regarding other questions, I will reply them in case other readers would find this page:

  1. If you have the Docker installed already, you probably do not need the latest version for this use case.
  2. Docker here is used to separate the working environment from the test environment. For this use case it would be similar to a virtual machine. Alternatively, you could install any OS in a VM and experiment there, e.g.: installing latest packages or building GnuPG yourself from source. Another option is to simply download and boot Tails, which has the quite recent GnuPG version installed. It could be run in a VM too.
9

Oh, al right. Based on the installation page, I thought the Start just required scdaemon and gpg > 2.1 to function properly.

Well, it’s good to know to be more careful with older systems. :slightly_smiling_face:

10

Sorry to be back here late.
so you have a lot of customizations in your conf, while I only have three
use-agent
no-emit-version
default-key FDB… ( no 0x in front for hex needed )

So as szszszsz mentioned, it could be the version of your GnuPG ( I am using 2.217 which works fine)
I would also recommend to reduce the customization and start tests with the lowest level and then add the special options step-by-step

1 Like
11

Going some steps back here…
Did you actually save the results? The keytocard command does not already remove the keys from the system. It only happens if you ordinarily quit and saves the gnupg session. This is what most likely wasn’t done if the keys are on the Nitrokey and still on the system…
At least, I never heard of this behaviour otherwise.

12

Yes, I did. I used both save and quit + save during my tests.