No common default PINs

[muellermartin]

All Nitrokey Pro and Storage devices have the same PINs set by default (see "What is the default PIN/password?" in the official FAQ).

I have several issues with this:

1. The default passwords are no good choice (12345678 and subsets are the most common passwords, so if you start brute-forcing with the most common passwords you will likely succeed – even with 3 tries). See also PIN analysis.
2. The initial setup does not emphasize the importance to change the default PINs and even allows to skip this step (this probably is more an issue in Nitrokey/nitrokey-app but the firmware could refuse to work unless the default password is changed).
3. In some countries the practice of common default passwords is starting to get illegal (although for "connected" devices only): https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=201720180SB327 A company with a product dedicated to security should take a step forward and adopt best practices such as individual default passwords.

In my opinion it would be best to ship each device with individual passwords and provide the default keys via a separate channel (e.g. encrypted/signed email or probably more practicable: a secure web portal). The accompanying software should force the user to change these inital passwords to make sure that the manufacturer does not know the password anymore.

[szszszsz]

Hi!
These are valid points! I like the great PIN analysis article very much, which in my opinion went classic on the publication day. However the default PIN is connected with the OpenPGP smart card life-cycle, which allows at every moment to reset it to the defaults, without knowing the User/Admin PIN. See the specifications for versions v2.1 (chapter 4.2) and v3.3.

Regarding point 2, Nitrokey App v1.3.x asks for PIN/password change on every use of the default one. Perhaps in v1.4 we will block usage of the latter completely, though I am not sure it will not confuse users. Blocking this in the firmware sounds good to me as well.

Point 3 is right. With the recent movement we might reconsider our default password politics. Maybe not by sending the personalized PINs / firmware passwords, but forcing the change should suffice entirely.

Against the supply-chain attack and firmware replacement, we have firmware verification procedure, which should show any interference, even done during the production. It would be nice to have it automatized in the future, and done entirely with the Nitrokey App.

cc: @jans23

Edit: corrected the link for v3.3, and v2.1.

[muellermartin]

Hi, too :) And thank you very much for your extensive reply!

Wow, I did not know that these default passwords are even mentioned in the standard. This is somewhat concerning to have such recommendations in security related specs :(
Unfortunately I'm not very familiar with the standard, but to my understanding the mentioned chapter says the default PIN 123456[78] is only assumed "[i]f the card is delivered without personalisation and/or PW letter […]". Therefore it would be possible to provide a better default. Also, if this default is kept secret, the lifecycle managment shouldn't matter that much (it should be made very clear, that this default is also an important secret to keep).
BTW: The link to v3.3 is broken, this worked for me: https://gnupg.org/ftp/specs/OpenPGP-smart-card-application-3.3.1.pdf

Could you elaborate what prevents a supply-chain attacker to use the current default passwords to deploy a custom firmware which always returns a firmware dump which looks like the original one while being compromised? To my understanding this is possible (e.g. by overwriting FileIO_SaveAppImage_u8 with a "faked" version). Because if this cannot be prevented, it is even more important to provide a custom default password via a separate letter (or better a 2nd channel like the previously suggested web portal).

[szszszsz]

Corrected the links. I have not checked the second one, sorry!

I might not understand fully your concern regarding the PINs. Smart card firmware cannot be updated, and if someone would use it, or lock the PINs, it would be visible, and fully reversible. Smart card factory reset could be invoked any time, resetting the PINs and its storage to default state.
Perhaps the only thing dangerous on the supply-chain attack could be supplying the AES key to the smart card, which end-user could miss while starting the use of the device, and use it by accident.
However that could be easily circumvented by issuing device's factory reset on device's first use. We do not rely solely on it, while creating the Encrypted Volume, and most probably even it is regenerated at the EV first usage, while the EV secrets are not yet initiated.
We do supply initialized devices for users, since it could take hours for full overwrite for some sizes.

Regarding the firmware password, at the current state I think this point is valid. There is some space available in the flash, which theoretically could take additional routines. Ideally from security point it would be best to update the firmware, when possible, with latest one, or the same, once received the device. Alternatively, to check for changes, firmware could be downloaded directly using the bootloader and any DFU tool, like dfu-programmer, without the firmware relay.
On the other hand the firmware export cannot be faked, while the source of the image takes the whole flash. I plan to populate the empty flash with random bytes, so no space would be left for possible faking code.

In general, I believe end-user validation is better, than sending the personalized passwords, since we are an element of the supply-chain as well. You can never know, has any evil maid working in the production company looked at your firmware password by someone's shoulder, and sold your secret to someone. End-user validation on the other hand does not care who had the device, unless any unexpected hardware was glued there. But in that case the personalized password would not help either.

• Ask users to run factory reset on reception (if not done already).
• Fill left firmware file's space with random bytes, which will be used to calculate the control checksum.