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?
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.
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.pyhere. 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.
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.
All the subkeys should be handled automatically. I am about to test that.
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.
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.
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.
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.)
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?
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).
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.
Run factory reset
Set up KDF
Change Admin PIN (optional; without keys only Admin PIN change is possible)
Import / generate keys
Change User and Admin PIN
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):
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):