Hello!
I decided to come back after a while of absence. Back in 2016 I bought a Nitrokey Storage and a Pro, and I’ve had them sitting in a drawer for all this time. Since I’m now setting up my PGP keys, I thought I’d also utilize the smartcards, but I have some questions before I move forward with the configuration. Basically, I have already asked some of this on the support email, but have yet to receive an answer so I though I’d ask here as well.
User, Admin and Firmware PIN
Okay, so the names might be a bit ambiguous because people normally understand the term “PIN” as a sequence of numbers. Back in the days, however, I was told that the PINs could also consist of non-numeric characters and basically become true passwords. Up until recently I was used to generating passwords from the lower ASCII (7 bits) table due to compatibility reasons with some applications. For example certain disk encryption utilities with pre-boot authentication will only accept these characters, and the non-us keyboard layout I am using only makes things worse as it narrows down the available pool.
So to increase password security I would normally use longer passwords (like 16 to 24 characters), but those are difficult to remember. Recently I thought to myself – why not increase the available character pool instead? This got me to try out and use the extended ASCII (128+) table, but I quickly learned it was very inconsistent. For example I found several different extended ASCII tables online, and my computer failed to fully match any one of them - there were always some differences. That’s when I did a little research and was surprised to find out so many appications alreay use UTF-8… which finally brings us to the point.
Can I use UTF-8 formatted passwords for the Firmware PIN, Admin PIN and User PIN on Nitrokey Pro/Storage?
What is the maximum length (in bytes) of the three "PIN"s?
Upgrading the SD card
I opened up the Nitrokey Storage and I noticed there was a 16GB SD card present. Since I have a 32GB card available I thought I’d upgrade it. What is the proper procedure to do so? Can I just remove and replace it with the new card? Do I have to format it in a specific way first? I noticed that the old card had a 2GB empty partition available, do I have to recreate it on the new card?
A good thing of Nitrokey is that you don’t have to remember a long and complicated password. Instead a short PIN (including characters) is sufficiently secure because the hardware prevents brute force attacks.
This channel might be sometimes faster, since it is covered as well by other Nitrokey users, which might have already the answer to the question.
That depends on the encoding compatibility between the applications you are aiming to use. Nitrokey App sends the PIN requests to the smartcard encoded in the UTF-8, with the maximum bytes length of 20, for all PINs and firmware password (which is not a PIN in our terms, since it does not have limited attempts).
The supported PIN size by the smart card is 32 bytes and more, depending on its model. GnuPG supports the whole length. Note having user/admin PIN set longer than handled by the Nitrokey App will make the device unusable for it though.
As @jan has mentioned, you do not need any longer PIN than minimum possible (6 bytes for user, and 8 for admin), since the attempts are limited in hardware (3 for each of the type). Only firmware password should be longer than that, but still the brute-forcing ability is limited (1 attempt per 300-500 ms AFAIR).
The SD card replacement is straightforward - you just need to replace it as with any other device. Then the space on it will be virtually (hardware side) divided to unencrypted and encrypted part, and presented to the OS as any usual block device. Last step is the SD card initialization, which is simply overwriting the storage with the random data.
You might want removing all partitions first from the new one to avoid OS reporting errors with invalid layout.
One case it might not work is when the firmware will find out it is from unsupported maker, and would block its use, due to past issues with such. In case your SD card would not belong to the supported list, you could remove the hardcoded check from the firmware, and flash it to see would it work.
Please note though issues coming from using custom firmware or hardware are not supported, and might result in losing warranty. We have no possibility to recover/reflash production devices, as the debugger access is removed.
For the custom firmwares I think it would be best to integrate changes with our firmware by placing a PR on the Github - this way we would test and maintain them in further firmware releases, if we would find given feature interesting.
