Initialization command for the Nitrokey HSM can time out after it was heavily populated.
Possible Cause
The smart card is engaged in a cleanup operations (like garbage collection), and cannot reply immediately. The timeout extension commands are not sent to the host due to waiting for the smart card reply in a busy loop, which results in a timeout error shown by the OpenSC to the user.
Workaround
While the timeout error is shown to the user, this does not necessarily means the operation failed. The smart card continues execution of the initialization command and should finish after around 30 seconds of the processing (usually 10 seconds later after the timeout error is reported).
The workaround is to ignore the error and wait until the LED on the Nitrokey HSM will stop flashing, which will signalize the reception of the smart card's reply, or add a hard delay in case of the batch execution, and restart the pcscd (OpenSC smart card service) after doing so.
Possible solution
Send timeout extension packets on the bulk endpoint (during the busy wait loop in USART_ByteReceive()) while the smart card is busy and is not doing it by itself. Perhaps by reusing CCID_CheckUsbCommunication().
Fill HSM by generating RSA4096 keys until the device is full, e.g. with:
pkcs11-tool -l --pin 648219 --keypairgen --key-type rsa:4096 --id $i
Reset the device with: sc-hsm-tool --initialize --so-pin 3537363231383830 --pin 648219
Execution takes about 45-60 minutes.
Populating with binary data (like certificates) might be faster, but the occurrence frequency seems to drop. With generating ECC keys the issue was not reproduced.
Populating script
```bash
#!/bin/bash
set -xeo
for i in {1..1000}
do
env OPENSC_DEBUG=2 pkcs11-tool -l --pin 648219 --keypairgen --key-type rsa:4096 --id $i
done
```
Summary
Initialization command for the Nitrokey HSM can time out after it was heavily populated.
Possible Cause
The smart card is engaged in a cleanup operations (like garbage collection), and cannot reply immediately. The timeout extension commands are not sent to the host due to waiting for the smart card reply in a busy loop, which results in a timeout error shown by the OpenSC to the user.
Workaround
While the timeout error is shown to the user, this does not necessarily means the operation failed. The smart card continues execution of the initialization command and should finish after around 30 seconds of the processing (usually 10 seconds later after the timeout error is reported). The workaround is to ignore the error and wait until the LED on the Nitrokey HSM will stop flashing, which will signalize the reception of the smart card's reply, or add a hard delay in case of the batch execution, and restart the
pcscd
(OpenSC smart card service) after doing so.Possible solution
Send timeout extension packets on the bulk endpoint (during the busy wait loop in
USART_ByteReceive()
) while the smart card is busy and is not doing it by itself. Perhaps by reusingCCID_CheckUsbCommunication()
.https://github.com/Nitrokey/nitrokey-pro-firmware/blob/47dd7f1ad6789e5b317266b831d8624c7d126063/src/ccid/smartcard/smartcard.c#L1303-L1322
See below for CCID protocol details:
Used library:
Details
Nitrokey HSM firmware:
hsm-2
HSM smart card firmware: v3.4 Frequency: tester1: 1/6, tester2: 1/3Scenario
pkcs11-tool -l --pin 648219 --keypairgen --key-type rsa:4096 --id $i
sc-hsm-tool --initialize --so-pin 3537363231383830 --pin 648219
Execution takes about 45-60 minutes. Populating with binary data (like certificates) might be faster, but the occurrence frequency seems to drop. With generating ECC keys the issue was not reproduced.
Populating script
```bash #!/bin/bash set -xeo for i in {1..1000} do env OPENSC_DEBUG=2 pkcs11-tool -l --pin 648219 --keypairgen --key-type rsa:4096 --id $i done ```