"Blinking" of HSM LED possible?

Nitrokeys
1

I have 4 HSM on one FreeBSD server. They are all labeled as “Nitrokey HSM” from Nitrokey. 2 of them are the HSM v2, but which ?
lsusb will provide:
Bus /dev/usb Device /dev/ugen0.5: ID 20a0:4230 Clay Logic
Bus /dev/usb Device /dev/ugen0.4: ID 20a0:4230 Clay Logic
Bus /dev/usb Device /dev/ugen0.2: ID 20a0:4230 Clay Logic
Bus /dev/usb Device /dev/ugen0.3: ID 20a0:4230 Clay Logic
Neither dmesg, sc-hsm-tool nor pkcs11-tool will wave a connection between the USB Slot and the reader-slot. With pkcs11-tool you could at least see the different versions of HSM on the different token-slots.
On RAID arrays you could enable the drive LED to blink to identify the right drive. As HSM also has a LED, I wonder if there is a function to do the same to identfy a NK HSM ?

2

That’s a good point. On request we do physically label Nitrokeys with their serial number to distinguish and identify them. I guess this would solve your problem.

Still your suggestion is good and I created an issue ticket. However I don’t think it will be high priority to be implemented.

3

Yes, label it upfront is of course a possibility. Especially my server e.g. is under the ceiling - so anyway difficult to see the LED that is glowing up ( and not to the front :smiley: )

BTW: I am not sure your udev rules are implemented : In FreeBSD I use the following rules:

nomatch 32 {
match “bus” “uhub[0-9]+”;
match “mode” “host”;
match “vendor” “0x20a0”;
match “product” “0x4230”;
action “logger NK HSM is attached and recognized”;
};

notify 100 {
match “system” “USB”;
match “subsystem” “DEVICE”;
match “type” “ATTACH”;
match “vendor” “0x20a0”;
match “product” “0x4230”;
action “/usr/local/etc/rc.d/pcscd onestart”;
};

notify 100 {
match “system” “USB”;
match “subsystem” “DEVICE”;
match “type” “DETACH”;
match “vendor” “0x20a0”;
match “product” “0x4230”;
action “/usr/local/etc/rc.d/pcscd onestop”;
};

attach 100 {
match “system” “USB”;
match “subsystem” “DEVICE”;
match “type” “ATTACH”;
match “vendor” “0x20a0”;
match “product” “0x4230”;
action “/usr/local/etc/rc.d/pcscd onestart”;
};

detach 100 {
match “system” “USB”;
match “subsystem” “DEVICE”;
match “type” “DETACH”;
match “vendor” “0x20a0”;
match “product” “0x4230”;
action “/usr/local/etc/rc.d/pcscd onestop”;
};

And there is another problem hidden: When I pull out one NK HSM, the pcscd is stopped. I need to change the rc-script to check the numbers of keys - but that might be not an GNU/Linux problem.

1 Like
4

There is one difference between models, which could help you. All Nitrokey HSM’s have serial number 010000000000000000000000, while Nitrokey HSM2 gets its iSerial from the smart card.

5

This bash line works for me:

[ $(lsusb -d 20a0:4230  | wc -l ) -gt 0 ] || echo stop

Edit: I meant to replace the action “/usr/local/etc/rc.d/pcscd onestop”; line with the bash script containing the mentioned source.

6

Thanks ! hat’s a good one to include in the start and the stop scripts for the daemon. Will try it ! Thanks

7

With pkcs11-tool --list-token you will get both : serial num and also the serial number concatenated in the token label string:

pkcs11-tool --list-slots G ‘DENK|Slot’
Slot 0 (0x0): Nitrokey Nitrokey HSM (DENKxxxxxxx0000 ) 00 00
serial num : DENKxxxxxxx
Slot 1 (0x4): Nitrokey Nitrokey HSM (DENKyyyyyyy0000 ) 01 00
serial num : DENKyyyyyyy
Slot 2 (0x8): Nitrokey Nitrokey HSM (010000000000000000000000) 02 00
serial num : DENKzzzzzzz
Slot 3 (0xc): Nitrokey Nitrokey HSM (010000000000000000000000) 03 00
serial num : DENKwwwwwww

Update: Oh, I see: you mean iSerial from lsusb --verbose. And yes, there the serial number is not composed into the line of the reader

But still you will need to understand the slot no aligned with USB.
BTW: I wonder when I see the following things:

Slot 0 (0x0): Nitrokey Nitrokey HSM (DENKxxxxxxx0000 ) 00 00
manufacturer: Nitrokey
hardware ver: 0.0
firmware ver: 0.0
flags: token present, removable device, hardware slot
token label : UserPIN (SmartCard-HSM)
token manufacturer : www.CardContact.de
token model : PKCS#15 emulated
token flags : login required, rng, token initialized, PIN initialized
hardware version : 24.13
firmware version : 3.1
serial num : DENKxxxxxxx
pin min/max : 6/15

HW and FW Version is not used, manufacturer should be Nitrokey and not the Smartcard Card producer, nor ? And the token label always has the prefix of “UserPIN ( )” ???
Strange !

8

Sorry for delay.
This is the expected output. The smart card is identified with the ATR, and commands are suited for this one particular. I guess hardware and firmware version getters implementation could be added. Smart card firmware and hardware are present though.
I suspect UserPIN seems to be a prefix for tokens, which require user PIN to execute operation over it (from my OpenPGP past experience), but I have not confirmed that.