Why entering invalid SO-PIN in HSM 2 bricks the device?

I wonder why entering SO-PIN more than 15 times (default value) bricks the device? Is it forced by hardware (i.e. internal smart card works this way) or was that implemented separately? I believe that initializing such device again would wipe data from it, so there should be no problems with it?

1 Like

Hi!

This is a hardware security latch, which makes smart card unusable. We do not have any method for reinitializing a device with used up attempt counter for SO PIN.

So this is as I suspected. Thank you for an answer.

Can default amount of max tries (times of attempts to enter a pin) be increased in settings?

How many can be set as a maximum retries before it bricks?

It is not possible to change the default attempt count for the SO PIN as far as I see in the manual. For the User PIN I have found Retry Counter Initial Value field in the INITIALIZE DEVICE APDU. Looking at sc-hsm-tool help screen I see its value can be defined during initialization (no range declared):

$ sc-hsm-tool --help
sc-hsm-tool: unrecognized option '--help'
Usage: sc-hsm-tool [OPTIONS]
Options:
  -X, --initialize              Initialize token
  -C, --create-dkek-share <arg>
                                Create DKEK key share and save to <filename>
  -I, --import-dkek-share <arg>
                                Import DKEK key share <filename>
  -W, --wrap-key <arg>          Wrap key and save to <filename>
  -U, --unwrap-key <arg>        Unwrap key read from <filename>
  -s, --dkek-shares <arg>       Number of DKEK shares [No DKEK]
      --so-pin <arg>            Define security officer PIN (SO-PIN)
      --pin <arg>               Define user PIN
      --pin-retry <arg>         Define user PIN retry counter
(...)

$ man sc-hsm-tool
(...)
       --pin-retry value
           Define number of PIN retries for user PIN during initialization. Default is 3.

Is it really ‘bricked’ (aka not more usable) or is only a new initialization/PIN-change permanently impossible ?

If I got it right, I need the SO-PIN only for initialization- and PIN-change processes, therefore a ‘try’ will be only accounted there.

Both, initialization code (aka SO-PIN) and User-PIN have a retry counter that will eventually expire after wrong PIN presentation.

The SO-PIN has a retry counter of 15, the User-PIN can have up to 10 retries, depending on the selected PIN length (6=3, 7=5, >7=10). For the User-PIN the retry counter can be defined during initialization.

A blocked User-PIN can also be unblocked and reset, if that has been allowed during initialization.

For a block SO-PIN there is no recovery possible. You could only try a firmware update to reinstall from scratch.

For a block SO-PIN there is no recovery possible. You could only try a firmware update to reinstall from scratch.

Will such upgrade work out for sure to resurrect locked out HSM hardware or it is uncertain? Shall a version of firmware being loaded into the HSM be newer than one which is already installed? Are any other specific conditions or terms influencing the results of recovery procedure?

Also please let me know if you plan to produce HSM3 with an authorization button the same way as for Nitrokey Pro 3?