The Importance of the SafeKey’s Personal Identification Number

This small write-up explains the importance of the Personal Identification Number (PIN) length and covers -in a nutshell- the efforts we invested in some aspects of our SafeKey related security features.

The PIN is similar to password in a way, but differs in complexity and use case. PIN is a short string of characters, easy to remember for the user. On the contrary to the password, PIN cannot be ‘brute-forced’ (that is, all combinations of characters cannot be checked) due to limited attempts the user would be asked for it. For FIDO2, the device will ask for the PIN 8 times, after which it will go to a ‘blocked’ state, disallowing further use of the device until it will be reinitialized (all user data, including attempts counter and the current PIN, will be cleared). For FIDO2 PIN, minimal length defined in the FIDO2 standard, is 4 bytes, and maximum is 63. This means it can hold 63 ASCII characters, or 15 (63/4) 4-byte wide Unicode characters (e.g. UTF-32). FIDO2 standard defines the PIN to be UTF-8 encoded, however device accepts any form, and is encoding agnostic (it compares binary data). FIDO2 PIN is required for FIDO2 registration and authentication actions, as well as using the Resident Keys feature. Since FIDO2 PIN is used for the Custom Storage (CS) access (it is possible to decouple it), it will be required as well for each login action to the CS, to use its features. Despite using FIDO2 PIN, all transport is still conducted through FIDO U2F layer, where the custom commands are sent. Simply, FIDO2 PIN is sent through FIDO U2F using the custom command. At no time is FIDO2 used to call CS commands. The same PIN is used for usability — to not add another PIN for user to remember, to use the device full capabilities.

Attackers who manage to break the MCU’s read-out protection, could brute force the PIN and retrieve half of user’s PIN which reduces the effectiveness of PBKDF2 protection by 50-times. The PIN is salted and hashed with SHA256. Only half of the PIN is stored for the FIDO2 use case.

SafeKey PIN Length Importance by Numbers

For a successful attack, the attacker would need to execute the following steps:

1. Get hold of a physical SafeKey.

2. Break MCU’s read-out protection to extract the flash. As to our knowledge, no attack on our MCU is published. However, successful attacks on older MCU’s were published a few months ago.

3. The PIN needs to be brute forced. The duration of a brute force attack very much depends on the PIN length. For example:

PIN length of 6 characters (consisting of 26 letters and 10 digits taken randomly), brute force takes a second, assuming 10x NVIDIA GPUs. Approximate calculations: https://www.wolframalpha.com/input/?i=36%5E6%2F%287747e7%2F2%29+%2F2+seconds

PIN length of 12 characters, brute force takes about two years, assuming 10x NVIDIA GPUs. Approximate calculations: https://www.wolframalpha.com/input/?i=36%5E12%2F%287747e7%2F2%29+%2F2+seconds

4. Now the attacker has reduced the space to brute force PBKDF2 by 50-times. The duration of a brute force attack very much depends on the PIN length. For example:

PIN length of 6 characters, brute force takes 1.5 second, assuming 10x NVIDIA GPUs. Approximate calculations:
https://www.wolframalpha.com/input/?i=36%5E6%2F%287747e7%2F%28100%2B1%29%29+%2F2+seconds

PIN length of 12 characters, brute force takes about 98 years, assuming 10x NVIDIA GPUs. Approximate calculations: https://www.wolframalpha.com/input/?i=36%5E12%2F%287747e7%2F%28100%2B1%29%29+%2F2+seconds

Note: Because of salting the PIN hash, a rainbow table attack is not possible.

In summary, the security very much depends on the PIN length.

SafeKey Features Implemented to Cope with This Problem

· PIN attempts counter

With PIN any attempts counter is associated, which will decrease with each invalid PIN provided (that is other, than currently set), and resets otherwise. Only 3 attempts are possible in the given power cycle, and 8 attempts total

Note: This protects from a malware trying to block the device (DOS protection).

· Device blocked state

If all the 8 attempts are used up for entering the valid PIN, the device will enter the blocked state, where all FIDO2 and CS functionality will be blocked. It will remain in this state until FIDO2 reset command will be issued. With the execution of it, all user data: FIDO U2F, FIDO2 and CS; will be cleared, including the PIN. PIN setting command is required to be called to use device’s features again, including the CS commands.

PIN Calculations and Storage

FIDO2 PIN is stored in SHA-256 hashed version in the device’s general configuration. The hash is salted against a 256-bit random number, generated during the very first initialization of the device, and only the first 128-bits of it are stored and used for the validation. This forbids the adversary to learn the true PIN’s clear text the user had initially set up.

To show calculations in the pseudo-code for the CS PIN validation:

interm_hash = SHA256(incoming_PIN)

incoming_PIN_hash = SHA256({interm_hash[:16], PIN_SALT})

PIN_correct = (incoming_PIN_hash == stored_PIN_hash)

Where…

· incoming_PIN is the PIN device is testing to be valid;

· PIN_SALT is 256-bit salt number for the SHA256 hash;

· stored_PIN_hash is the currently set on the device user PIN SHA256 hash, with size of 16 bytes;

· interm_hash is an intermediate 256-bit SHA256 hash;

· interm_hash[:16] is the first 16 bytes of interm_hash;

· incoming_PIN_hash is the final 256-bit hash of incoming PIN, which is tested against stored value;

· PIN_correct is the boolean final result of the byte-to-byte comparison of both hashes.

The reason that hash is calculated two times is because of the FIDO2 PIN handling — the user provided PIN is never transported to the device in plaintext, but instead only first 16 bytes of its SHA256 hash. Thus, to make use of the same PIN as FIDO2, client-side hashing has to be simulated on the device for CS PIN validation.

Usage

The PIN has to be confirmed every time before access to the user’s secret data: for FIDO2 and Custom Storage. It is shared among these for usability reasons — to minimalize the required PINs count to use the device’s full capability.

Some more details about our PIN authentication and more , please go read our documentation : https://docs.safetech.io/6%20Design%20docs/#pin-authentication