Probleme mit Nitrokey Start nach Firmwareupdate auf RTM.9 – Veränderte Kartenummer

Nitrokeys Misc
#1

Hallo,
ich habe mein Nitrokey Start heute erfolgreich auf die neuste Firmware RTM.9 geupdated. Das hat soweit gut geklappt. Das Update war erfolgreich.

Daraufhin habe ich auf einem air-gapped Laptop erst meine Subkeys mittels keytocard erneut auf den Nitrokey Start geschoben, den Admin-PIN gesetzt und anschließend den User-PIN gesetzt. Beide PINs müssen laut Releasenotes jetzt offenbar mindestens 14 Zeichen haben, was den praktischen Nutzen des Nitrokeys sehr einschränkt, für meinen Anwendungsfall sogar prinzipiell unbrauchbar macht. Vielleicht sollte man das mal auf der Shopseite hervorheben? Das ist ja schließlich eine nicht ganz selbstverständliche Beschränkung? Aber nun gut, anderes Thema…

Nun habe ich das Problem, dass mein Nitrokey trotzdem nich funtioniert wie zuvor. Es erscheint der Hinweis: „Bitte legen Sie die Karte mit der folgenden Seriennummer ein“ und dort dann die Kartennummer.
Vor dem Update habe ich, wie hier beschrieben, den Output von gpg --card-status in eine Datei mit dem Name before.status gesichert. Ein diff -y before.status after.status zeigt aber, dass die „Application ID“ und die „Serial number” sich geändert haben. Ich vermute, deshalb funktioniert das ganze nicht mehr? Was kann ich nun tun?

#2

Hi @maaattes!

Indeed that long PIN is not handy to use, and hopefully this would be eased in the next firmware releases by increasing the on-device computation time. In the meantime you might like to generate a passphrase, which would be suitable for such use, e.g. using diceware tool.

Regarding the problem, the RTM.9 firmware changed its serial number indeed due to the new feature. To update it on your operating system I believe you need to delete the public key from the keychain, and then import it back again with simply calling gpg --card-status.
I will test that solution on my PC first and let you know if that works.
For a quick workaround you can downgrade firmware to RTM.8 version, which does not support multiple identities feature.

#3

Hi @szszszsz,
thank you very much for your quick response and the suggested solutions. I’ve read about setting the serial number via ../tool/gnuk_put_binary_libusb.py here. But I haven’t tried it yet because it says “You can setup the serial number of Gnuk Token only once” so I’m a little bit afraid (although I have cold backups of everything in multiple places. SD-Card, DVD-Ram, paper…).
Could this also be a solution? And if so, when should this step be done? Would it also be possible to do this after the initial configuration (importing keys, setting up PIN)?

If I only reimport the public key from the card, would this also update the card number of the subkeys? Because when I do gpg --card-status every subkey has a card number.

#4
  1. Using own serial number was fully supported until RTM.8. With latest RTM.9 release the first character of the serial number is overwritten with a 0, when being in the first identity, and 1 and 2 for two next identities. The custom serial handling for this case was not taken into consideration unfortunately during the feature implementation. We will discuss correcting that, perhaps simply not changing the serial number (custom set or hardware derived) first digit for the first identity.
  2. All the subkeys should be handled automatically. I am about to test that.
  3. Regarding the PIN’s length, the KDF-DO could be set up, which allows to use the shorter PIN by calculating PIN hash value on the PC and then sending it to the device, however it will work only with GnuPG 2.x. Any other smart-card applications will probably not know, how to send the right PIN hash value with this set.
#5

Hi @maaattes!

  1. We have decided to fix the serial number issue with the next firmware release - RTM.10 (should be within 2 days) to avoid hassle with the serial number metadata update on the used hosts. Details: NitrokeyStart#41.
  2. It seems that I was wrong and setting own serial number with gnuk_put_binary_libusb could work, but there will be no need for that in the next firmware release, so let’s leave it.
#6

Just FYI, my serial number has changed in two places. Before it was 431xxxxx and after the update 001xxxxx (I guess it’s safe to post the full serial number publicly? Obfuscating it just in case).

How can I set this up? Or does it have to be implemented in the firmware? I think GnuPG 2.x is fairly common these days, isn’t it?

Okay, then I’ll just wait for the next release. Thanks again for the quick help!

#7

Hey, just wanted to let you know that I’ve just updated successfully to RTM.10 and everything works fine again :slight_smile:

Just one more thing: I’ve got some syntax warnings because my system uses Python 3.8. Looking at the “Reference log using update tool” over at Github releases I saw you were using Python 3.7.7.

From the Python 3.8 Releasenotes:

The compiler now produces a SyntaxWarning when identity checks ( is and is not ) are used with certain types of literals (e.g. strings, numbers). These can often work by accident in CPython, but are not guaranteed by the language spec. The warning advises users to use equality tests ( == and != ) instead. (Contributed by Serhiy Storchaka in bpo-34850.)

1 Like
#8

Hi!

Great it works again for you!
Thank you for the heads-up - will correct this. Registered as nitrokey-start-firmware#43.

Regarding KDF-DO, its setup is as easy as:

  1. Run gpg2 --card-edit
  2. $ admin
  3. $ kdf-setup
  4. Enter Admin PIN
  5. Verify current state state by looking at the card details (gpg2 --card-status), where KDF setting ......: on should be visible, e.g.:
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 0
KDF setting ......: on
Signature key ....: [none]
#9

Unfortunately, setting up KDF-DO is not working. After executing kdf-setup and entering my Admin-PIN it fails.
gpg: Fehler beim Einstellen der KDF: Kartenfehler

I use gpg 2.2.20.

#10

Hi! Any news on that? It’s really inconvenient to use a PIN with 14 characters… Furthermore, this restriction is still not mentioned anywhere on the product page (https://shop.nitrokey.com/de_DE/shop/product/nk-sta-nitrokey-start-6).

#11

Hi @maaattes !
Sorry, no decision yet, but we are leaning towards using KDF-DO with shorter PIN.
Regarding your issue with KDF-DO, I could not reproduce it. Do you have any special settings on smart card, or environment?

#12

None that I’m aware of. I’m using gpg version 2.2.20, libgcrypt 1.8.5 on Fedora 32, Kernel 5.7.8-200.

Output of gpg --card-status

Reader ...........: 20A0:4211:FSIJ-1.2.15-XXXXXXXX:0
Application ID ...: XXXXXXX
Application type .: OpenPGP
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: XXXXXXXX
Name of cardholder: XXXX
Language prefs ...: de
Salutation .......: Hr.
URL of public key : [nicht gesetzt]
Login data .......: [nicht gesetzt]
Signature PIN ....: zwingend
Key attributes ...: ed25519 cv25519 ed25519
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 0
KDF setting ......: off
1 Like
#13

Still no news on that issue? It’s been more than 3 months and it is still nowhere mentioned that with a Nitrokey Start you have to use a pin with 14! characters. Of course one could use the old firmware but then the device is open for attacks (see: https://github.com/Nitrokey/nitrokey-start-firmware/issues/29).

#14

Hello??

#15

Sorry, when I jump in: so will you keep the serial number in the future with the next FW Update ? The same issue ( new serial number ) is also when you update the HSM …

#16

Regarding the Nitrokey Start, yes. This was an issue introduced with Multiple Identities, which was corrected. As for the Nitrokey HSM, I believe this is by design.

#17

@maaattes
I am sorry for the delay. Will take a look at this issue today again.

#18

@maaattes Problem described in your comment (Probleme mit Nitrokey Start nach Firmwareupdate auf RTM.9 – Veränderte Kartenummer) has reproduced for me.

Initial investigation shows that with the current implementation of both GnuPG and Nitrokey Start, the latter has to have default PINs set to enable the KDF-DO, and it has to be empty (just after factory reset). There is already a patch in queue for the GnuPG to handle switching it with the non-default settings - see ticket:

Solution is merged to the main branch, however there is no information currently when it will be available in the actual release (to be requested). I was expecting it will be in the next GnuPG release, when you were asking last time.

Current procedure:

  1. Run factory reset
  2. Set up KDF
  3. Change Admin PIN (optional; without keys only Admin PIN change is possible)
  4. Import / generate keys
  5. Change User and Admin PIN

Tested with:

  • gpg (GnuPG) 2.2.20 / 2.2.25
  • Nitrokey Start RTM.10
  • Curve 25519 keys

Regarding the card failure error (caused by the forbidden request of changing the KDF state when the Nitrokey is already populated), here are the GnuPG’s 2.2.25 scdaemon logs (for completeness):

2021-01-26 12:35:01 scdaemon[22] 3 Admin PIN attempts remaining before card is permanently locked 
2021-01-26 12:35:01 scdaemon[22] DBG: check_pcsc_pinpad: command=20, r=27265 
2021-01-26 12:35:01 scdaemon[22] DBG: asking for PIN '|A|Please enter the Admin PIN%0A%0ANumber: FFFE 87042524%0AHolder: ' 
2021-01-26 12:35:01 scdaemon[22] DBG: chan_7 -> [ 49 4e 51 55 49 52 45 20 4e 45 45 44 50 49 4e 20 ...(70 byte(s) skipped) ] 
2021-01-26 12:35:05 scdaemon[22] DBG: chan_7 <- [ 44 20 31 32 33 34 35 36 37 38 00 00 00 00 00 00 ...(76 byte(s) skipped) ] 
2021-01-26 12:35:05 scdaemon[22] DBG: chan_7 <- END 
2021-01-26 12:35:05 scdaemon[22] DBG: send apdu: c=00 i=CA p1=00 p2=F9 lc=-1 le=256 em=0 
2021-01-26 12:35:05 scdaemon[22] DBG:   PCSC_data: 00 CA 00 F9 00 
2021-01-26 12:35:05 scdaemon[22] DBG:  response: sw=9000  datalen=0 
2021-01-26 12:35:05 scdaemon[22] DBG:       dump:   
2021-01-26 12:35:05 scdaemon[22] DBG: send apdu: c=00 i=20 p1=00 p2=83 lc=8 le=-1 em=0 
2021-01-26 12:35:05 scdaemon[22] DBG:   PCSC_data: 00 20 00 83 08 31 32 33 34 35 36 37 38 
2021-01-26 12:35:05 scdaemon[22] DBG:  response: sw=9000  datalen=0 
2021-01-26 12:35:05 scdaemon[22] DBG:     dump:   
2021-01-26 12:35:05 scdaemon[22] DBG: send apdu: c=00 i=DA p1=00 p2=F9 lc=110 le=-1 em=0 
2021-01-26 12:35:05 scdaemon[22] DBG:   PCSC_data: 00 DA 00 F9 6E 81 01 03 82 01 08 83 04 02 80 00 00 84 08 C2 35 03 19 6A A7 DC EB 85 08 71 5D 2D D6 06 C1 A7 8A 86 08 9D EB 8D 7C 4F 8F 0A BF 87 20 23 E2 3D E0 55 DF 8F 8B 18 FF 25 BE 96 38 1F 08 FF 52 5F F3 73 72 CA F4 64 B4 DF 7B BF 07 92 0C 88 20 66 26 33 D4 D4 87 9B E4 5D 36 92 2F 61 B2 6D BD 62 BF 19 F1 DC 26 22 CA CD B4 22 8A A6 A4 A8 70 
2021-01-26 12:35:05 scdaemon[22] DBG:  response: sw=6F00  datalen=0 
2021-01-26 12:35:05 scdaemon[22] failed to set 'KDF': Card error 
2021-01-26 12:35:05 scdaemon[22] DBG: chan_7 -> ERR 100663404 Card error

Edit: the mentioned GnuPG patch is unfortunately for other devices than Nitrokey Start.

#19

Confirmed today, that setting KDF-DO after initializing Nitrokey Start with key material is not possible by design, and as of this moment not scheduled to be implemented due to potential security issues.

Current description should be available in the documentation (to be extended):

#20

Thank you for your research @szszszsz. Well, I guess I have no choice then. I’m planning to do a factory reset and try to activate KDF-DO in the coming days. Will report if I was successful.