[kmsp11] When using multiple key rings via PKCS#11, "slots" have identical serial numbers

[lspiehler]

When multiple key rings are supplied using the config defined via KMS_PKCS11_CONFIG, the pkcs11-tool --module /usr/local/lib/kms/libkmsp11.so --list-slots command returns multiple slots with the same serial number "0000000000000000"

Available slots:
Slot 0 (0x0): A virtual slot mapped to a key ring in Google Cloud KMS
  token label        : 
  token manufacturer : Google
  token model        : Cloud KMS Token
  token flags        : rng, SO PIN locked, token initialized, PIN initialized
  hardware version   : 0.0
  firmware version   : 0.0
  serial num         : 0000000000000000
  pin min/max        : 0/0
  uri                : pkcs11:model=Cloud%20KMS%20Token;manufacturer=Google;serial=0000000000000000;token=
Slot 1 (0x1): A virtual slot mapped to a key ring in Google Cloud KMS
  token label        : 
  token manufacturer : Google
  token model        : Cloud KMS Token
  token flags        : rng, SO PIN locked, token initialized, PIN initialized
  hardware version   : 0.0
  firmware version   : 0.0
  serial num         : 0000000000000000
  pin min/max        : 0/0
  uri                : pkcs11:model=Cloud%20KMS%20Token;manufacturer=Google;serial=0000000000000000;token=

The serial is often used in the PKCS#11 URI to reference a key. Without a unique serial for each, how can we distinguish between the slots? See example OpenSSL command below. Thank you!

openssl ca -in csr.req -config openssl.cnf -create_serial -policy signing_policy -batch -notext -utf8 -keyfile pkcs11:serial=0000000000000000;objectid=iothsmkey1;type=private -subj /CN=test.com/C=US -startdate 20251126202916Z -enddate 20251226203416Z -passin stdin -in csr.req

[tdbhacks]

Apologies for the late reply: so you are correct that we intentionally leave the serial number empty, and while I wasn't part of that discussion I imagine the original author of this library deemed it to be N/A because slots correspond to Cloud KMS keyrings, which don't really have a serial number unlike a traditional HSM card.

While we could populate it with something (e.g. hash the KeyRing resource name), we haven't run into the strong need of doing so yet. To your question, openssl can iterate through the slots to correctly find your specified object value (note: I think it's object, not sure if objectid is also a thing), so your command above should still work if you drop the serial=0000000000000000; part. Now, you might also be implicitly asking about what happens if there are two keys with the same resource name, in two different KMS keyrings, and both are specified in the PKCS#11 config. While I haven't tested myself, I assume openssl would pick one based on some order (likely slot ID?). Note though, that you can also specify an individual key version using the pkcs11:id openssl field, see this example. There is no collision risk there, since the full resource name of each CryptoKeyVersion is unique, but keep in mind the long-standing issue of the 100-char limit in openssl (#35)

I hope this helps!

[lspiehler]

During my testing, I've already run into the issue of two key rings containing keys with the same name, but the conflict caused other issues with my application before I was able to actually test with OpenSSL. I'm also aware of the 100-char limit. Previously my application used the ID in the pkcs11 URI, but I had to start using the objectid when using Google keys.

My application is designed to manage multiple PKCS11 devices (virtual and physical). It uniquely identifies tokens using the serial and the conflicting serial is also causing problems with management of the tokens in my UI. It would be great if the library was updated to return unique serials. I'm willing to test if that would be helpful. Otherwise, I'll probably limit the application to only support a single key ring because the alternative would likely mean significant changes to my code. Thanks!

[tdbhacks]

Ack, thanks for the explanation and insights! Following up on this, I recommend limiting your application to support one keyring for now, which sounds like a restriction that you might always be able to remove later, right?

I am a little hesitant to just start populating the serial number with something arbitrary, but also honestly don't foresee this causing issues in the future.. I will consult internally. It sounds like the kind of change I'd like to reserve for an upcoming v2.0 major release though, where we'll eventually have to upgrade to a more recent PKCS#11 spec to start supporting PQC algorithms. No ETA for that yet, but I hope the added context helps.