Recognise a PKCS11 hardware token with its serial number instead of slot number

[hug-dev]

To interface with a specific PKCS11 implementation token, Parsec currently uses the slot number (CK_SLOT_ID) of the token.

As stated here and here this is a bit fragile:

• the slot number can change if the device is unplugged and re-plugged
• the slot number can map to a different device if a different device is plugged-in instead
• the slot number can change if the OS is rebooted

Ideally, the admin would know the serial number of the device they want to use with Parsec and enter that + its PIN in the configuration file. That way, the slot number might change the same device will always be used with Parsec.

Parsec configuration is stable. That means that we can not remove support for the slot_number field. Instead we can do:

• if no slot_number or serial_number is entered and there is only one slot available, use that one (Make the slot_number field optional #375)
• if only slot_number is entered, check that the slot number is valid via GetSlotList and use that one. Print a warning message that slot number might change and that serial number is preferred.
• if only serial_number is entered, call GetSlotList then GetTokenInfo for each one of them and use the slot ID mapping with the serial number
• if both are entered, use the serial_number logic

About security: as per our threat model, the admin and what they write in the configuration file is trusted. The machine is not supposed to be accessed physically by untrusted agents. For those reasons I don't recognise this as a security issue.

[mohamedasaker-arm]

Is it helpful to add a warning when there is a mismatch between the slot_number provided and the actual slot_number of the given token?
for example:
Token T with sn: 0 is at slot 1
in config:
serial_number = 0
slot_number = 2
@hug-dev @ionut-arm

[hug-dev]

Hey!
Thanks for tackling this issue 😃

If both serial_number and slot_number are written in the config, I would say that it would be nice to print a warning saying that the slot_number is ignored and can be removed from it. But I don't think that it's necessary to check that the slot_number does not match

[ionut-arm]

Hmm, not sure. I agree on the warning message, but I'd lean towards stopping the service because something ain't right. My reason being that perhaps they wrote down the wrong serial number and it's the slot number that's correct. I guess it would fail at the first login, since the PIN would be incorrect, but it still seems weird to continue if you have the configuration clearly wrong somewhere.

[mohamedasaker-arm]

If they put the wrong serial number that can have 2 possibilities:

• It doesn't match any token in the system
  Action: Error that no token with this serial number
• It does match but on a different slot
  Actions suggested:
  1- Warning: slot number will be ignored (that won't be enough to let them know that they put the wrong serial number)
  2- Warning: on the mismatch ( that will give an indication that there is something wrong)
  3- Error: slot mismatch
  I would go with 2 and 3, what do you think?

[ionut-arm]

I'm happy either way - it's more friendly towards admins if we just log a warning and proceed with the mismatching serial/slot numbers, but it might bite them later on. Feel free to either error out or not! Don't think we have a strict stance on this.

[mohamedasaker-arm]

Done in #608