Get CKA_ID of certificate

[SergeyByshlakov]

Hello,
I need to get the private key EVP_PKEY from the token. The token manufacturer provides the certificate label CKA_LABEL, with it I successfully loaded the certificate using the OSSL_STORE API and URI. Then I have to get the CKA_ID of the certificate (it matches the CKA_ID of the key according to the token manufacturer) and using it get the private key. Please tell me how can I get the CKA_ID of the certificate?

I tried to get the public key from the certificate and then use EVP_PKEY_print_public hoping that it will print the URI, but it did not work, the URI was not printed.

Thank you!

Provider version 1.0
OpenSSL version 3.0.7

[simo5]

Do you have to do this in code, or can you use other utilities?
CKA_ID is not exposed directly to openssl as openssl APIs have no use for it.
You can use pkcs11-tool to query individual objects stored on the token.

Example:

$ pkcs11-tool --module="${P11LIB}" --token-label="${TOKENLABEL}" -O --label caCert
Certificate Object; type = X.509 cert
  label:      caCert
  subject:    DN: CN=Issuer
  serial:     01
  ID:         0000
  Unique ID:  7b5afbc4-c224-4da2-98de-5a4ff6f34f09
  uri:        pkcs11:model=v1;manufacturer=Kryoptic%20Project;serial=;token=Kryoptic%20Token;id=%0000;object=caCert;type=cert

From this uri returned pkcs11:model=v1;manufacturer=Kryoptic%20Project;serial=;token=Kryoptic%20Token;id=%0000;object=caCert;type=cert you can then trim away unnecessary values and change it to something like:
pkcs11:id=%0000;type=public to get the public key with the same CKA_ID

[SergeyByshlakov]

This needs to be done in code.

The thing is that the manufacturer sometimes releases new versions of tokens and the CKA_IDs of the objects change, but the certificate labels remain the same. I know the CKA_IDs of the released versions, but I need a way to read the CKA_IDs for future versions so that I don't have to change the code every time.

[simo5]

You can open a feature request to be able to get CKA_ID gia an EVP_PKEY_get_params() call in the future, not easily available right now.

[t-j-h]

There is a lot of stuff still to go into the PKCS#11 provider, and there are a lot of PKCS#11 implementations that don't follow the standard and also hit major interoperability issues - which is why I'm pointing out that assumptions being made aren't supported in the standard. That doesn't mean there are not specific products that work that way - but it most likely means that non-conforming behaviours are less likely to be implemented in the provider.

In terms of getting at the underlying attributes (and setting them) there is a lot more to be done.

[dengert]

I agree. @SergeyByshlakov did not say what manufacture what the name of the pkcs11 module or what version of PKCS11 the module supports. Knowing these would help identify interoperability issues.

[SergeyByshlakov]

You can find the information you are interested in in the technical section on the page https://esante.gouv.fr/produits-services/socle-technique-cps

[dengert]

Thanks. Using Google translate, these are French health card (2 versions) and https://industriels.esante.gouv.fr/produits-et-services/socle-technique-cps#paragraph-id--564 says they have a Windows "minidriver", MacOS "Token driver" and on Linux "There is no driver yet, you can deploy Cryptolib." But also says "Access reserved for holders of a Personal Account" which I do not have.

Their Windows 10 and MacOS CPS do not use PKCS11, although if their Linux "Cryptlib" does have a PKCS11 module, there may be Windows and MacOS versions of the module.

I assume you are trying to run on Linux? What is the name of the pkcs11 module the provider is loading?

As suggested by @simo5 you can also use pkcs11-tool to see all the objects on the card.
pkcs11-tool pkcs11-tool --module="${P11LIB}" -O --login

Try on both an old and new versions of the card.

The ID: and the uri for each object shows the CKA_ID If things are working as expected the sets of private key, public key and certificates should have matching CKA_ID attributes.

You implied you knew the CKA_ID and CKA_LABEL for certificates on the old cards. The above may help with the new cards.

With the pkcs11-tool in @simo5 there is an OpenSC bug in the uri, as each non printable byte needs to be escaped so the
id=%0000; should be id=%00%00;

[SergeyByshlakov]

I assume you are trying to run on Linux? What is the name of the pkcs11 module the provider is loading?

Windows is used, cps_pkcs11_w32.dll from Cryptolib (via wrappers, but this is not so important, they are transparent).

It is not a problem to read all smart card objects and their attributes, including CKA_ID. I thought that this could be done using pkcs11_provider and OpenSSL API OSSL_STORE.

[simo5]

@dengert the point is, if OpenSC or something else generates CKA_ID out of thin air, this is bad, and should be changed. CKA_UNIQUE_ID can be generated out of thin air, because it is a unique id (per token) and the applicaiton ha sno say on how it is built.

CKA_ID has to be preserved and changeable, it is better to fail to change it so the application knows it cannot rely on it then to make one up arbitrarily.

As for the french spec the only reason they can get away with it is that CKA_ID is set on pre-generated key, and I think they may be within spec to prevent any modification of objects after creation.

I think returning CKA_ID prom pkcs11-provider is valuable, and I see no reason why we would not do it eventually, although I lean towards simply returning a pkcs11 URI rather than individual bits and pieces. It is just not a high priority for now, given users of such cards need to find out only once, generally.

Also note that for many operation pkcs#11 internally can find the "Associated" object, and it does that in part via CKA_ID matching.

[dengert]

if OpenSC or something else generates CKA_ID out of thin air, this is bad, and should be changed.

I agree. AFAIK OpenSC always bases the CK_ID on information from PKCS15 structures on card or on emulated cards, from data from the card via the card driver. (there are 42 card drivers in Opensc.)

It sounds like the official french CPS may come with a pkcs11 module for linux which may not be based on PKCS11 version 3. Or it may be using OpenSC. I don't know if OpenSC has support for either the old or new cards. More info from @SergeyByshlakov like ATR of the cards, or what pkcs11 module works for the old cards is actually being used.

@SergeyByshlakov Running pkcs11-tool -O (without the --module) would try using OpenSC's pkcs11 module.

The pkcs11-tool bug with URI format was committed: OpenSC/OpenSC#3326

I think returning CKA_ID prom pkcs11-provider is valuable, and I see no reason why we would not do it eventually, although I lean towards simply returning a pkcs11 URI rather than individual bits and pieces. It is just not a high priority for now, given users of such cards need to find out only once, generally.

Sounds like a good mod, but it is low priority for you. But @SergeyByshlakov is looking for something now, and it sounds like code for the old card has well known CKA_IDs, but he does not know how to get the CKA_IDs for new cards, which may be fixed for all new cards or vary by card. That was the reason to try pkcs11-tool -O with and without the --module on new card.

[SergeyByshlakov]

I got the CKA_ID of the certificate using FindObjects (C_FindObjectsInit -> C_FindObjects -> C_GetAttributeValue -> C_FindObjectsFinal) this works for both the old and the new card.