Key generation with Nitrokey Start on Debian buster fails / RSA4096

Nitrokeys
11

I thought mostly about the implementation details here - that some OpenSC tools might not work correctly.
Another point is being not tamper-resistant indeed - with physical access, and if the PIN is short enough, the user data could be copied to PC with debug adapter hardware (despite hardware read protection being enabled) and by using brute-forcing the PIN combination private key data could be extracted from the image. This hardware attack was shown just recently. I believe this is not a real risk for regular users, but definitely is for a CA.
To avoid this attack the PIN needs to be set to more than 11 printable characters (small and big letters, digits, special characters) or at least 14 small ASCII letters (the more the better - device allows for PIN length up to 128 bytes, but lower count should be sufficient). If possible, using local diacritics with UTF-8 increases the required work to break the protection further.
Nitrokey Pro, HSM and Storage do not suffer from this issue, as the keys are stored off the MCU, on a tamper-resistant smart card, hence the PIN length could be smaller.

Calculations for the required safe PIN length for Nitrokey Start against the mentioned below hardware:

Constants:

  • 26 ASCII small letters to create the PIN;
  • 14 - PIN length, letters chosen randomly;
  • 192 - minimal count of SHA256 rounds run on the device to create the storage encryption key for the data;
  • 7747e7 - average SHA256 hashes count computed per second on 10x NVIDIA GTX 2080 GPU with hashcat (taken from this benchmark);
  • /2 - average result.

Edit: Benchmark sources update:

Edit: Announcement about the attack:

Edit: Instead of unmanageable random 14-letters PIN it is advised to use KDF-DO where possible. In other cases the PIN can be multiple (5-6) word based, exceeding the minimal PIN ASCII length, ideally containing national characters (aka accents / diacritics).

1 Like