security consideration info

[mat-c]

At the same time, DKEK is encrypted with doubled salted and hashed PIN. Also, the PIN is hashed in memory during the session. Hence, PIN is never stored in plain text neither in flash nor in memory. Note that PIN is conveyed from the host to the HSM in plain text if no secure channel is provided.

If the Pico is stolen the contents of private and secret keys cannot be read without the PIN, even if the flash memory is dumped.

Could you detail resistance to brute force attack ?
Dumping to flash and try to brute force pin to recover DKEK.

What are the recommended pin len/complexity to prevent brute force attack ?

[polhenarejos]

MKEK is a random AES-256 secret key that is salted by your hashed PIN. Despite it has billions of possibilities, the input to that system is your PIN. So, the larger is the better protection offers.

If your flash gets dumped offline it can be cracked by brute-force by introducing PIN values. Doing a quick calculus, using 4 RTX 3090 Ti, they could perform 512 x 10^6 hashes per second. For a 8-bytes PIN length in plain text (ASCII number 0-9) in few seconds would be cracked. If you use 8-bytes PIN length in HEX it will require thousands of years. However, HEX mode depends on client implementation (opensc I think uses ASCII mode).

For this reason, we provide alternative methods:

• PKA: Public Key Authentication uses the certificate of a secondary HSM to identify. It adds an additional layer but at the end the ultimate HSM device will depend on a PIN, otherwise you will create a circular identification.
• Secure lock: it relies on a private key that resides in the keychain of your OS. In that case, the inputs to unlock the MKEY is the PIN and that private key. It adds a significant robustness but then your HSM gets tied to your computer. You must unlock the HSM at every boot and introduce your PIN as usual. Secure lock can be enabled/disabled/unlocked via pico-hsm-tool.py.

These are not the optimal solutions, but this is due to Raspberry Pico, which is not designed as an homologated secure hardware device. We can add as many layers of security as we can, but at the end the flash memory can be always dumped, which is not a good deal for high security standards.

[mat-c]

Thanks

I think you should put a warning on pin security limitation.

I look at the code
double_hash_pin of pin are saved in a file
double_hash_pin of sopin are saved in a file
hash_multi of pin encrypt the mkek
hash_multi of sopin encrypt the mkek

hash_multi is based on sha256 with serial injection and 256 input len (pin is repeated several time)
double_hash_pin is hash_multi * 2 and pin xor

What is the purpose of 256 iter in hash_multi ?
What is the purpose of pin xor in double_hash_pin ?

Both pin and sopin need to be good to keep mkek secret

What are the specification of pin and sopin in sc-hsm protocol ?

https://github.com/OpenSC/OpenSC/wiki/SmartCardHSM#initialize-the-device
For sopin, opensc want a 16 hexadecimal and convert it to 8 bytes binary
for pin, it want a max len of 16 and driver send it as raw. But it don't know if there is other limitation. Numeric only on opensc side, need to checked.

[polhenarejos]

These are legacy functions defined by OpenPGP. The purpose of xor'ng pin in double_hash_pin is to change the input of second hash_multi.

sc-hsm is not a protocol, but a vendor solution from CardContact. PKCS11 interface defines PIN authorization but is up to implementation how is encoded. As you noted, so-pin expects 16 HEX string, but there is no limitation on PIN length (like 8 or 10 bytes). It is sent as ASCII, so if you pass --pin 0123 it will be sent as 30313233. I never tried but it should work with symbol characters too (!@#$).

[leommxj]

MKEK is a random AES-256 secret key that is salted by your hashed PIN. Despite it has billions of possibilities, the input to that system is your PIN. So, the larger is the better protection offers.

If your flash gets dumped offline it can be cracked by brute-force by introducing PIN values. Doing a quick calculus, using 4 RTX 3090 Ti, they could perform 512 x 10^6 hashes per second. For a 8-bytes PIN length in plain text (ASCII number 0-9) in few seconds would be cracked. If you use 8-bytes PIN length in HEX it will require thousands of years. However, HEX mode depends on client implementation (opensc I think uses ASCII mode).

For this reason, we provide alternative methods:

• PKA: Public Key Authentication uses the certificate of a secondary HSM to identify. It adds an additional layer but at the end the ultimate HSM device will depend on a PIN, otherwise you will create a circular identification.
• Secure lock: it relies on a private key that resides in the keychain of your OS. In that case, the inputs to unlock the MKEY is the PIN and that private key. It adds a significant robustness but then your HSM gets tied to your computer. You must unlock the HSM at every boot and introduce your PIN as usual. Secure lock can be enabled/disabled/unlocked via pico-hsm-tool.py.

These are not the optimal solutions, but this is due to Raspberry Pico, which is not designed as an homologated secure hardware device. We can add as many layers of security as we can, but at the end the flash memory can be always dumped, which is not a good deal for high security standards.

@polhenarejos Is it better to state this situation in readme? The current description in readme is slightly misleading.

If the Pico is stolen the contents of private and secret keys cannot be read without the PIN, even if the flash memory is dumped.

People who are not familiar with the project may easily mistaken that even if the pico hsm is lost, their keys are still very secure.