Key and Certificate ID Mismatch in MacOS Provider

[microshine]

Description

When adding keys and a certificate to the MacOS provider via Fortify, their IDs differ, causing the application to be unable to associate the key with the certificate. Consequently, they are not displayed in the list. If the application is restarted, the certificate and keys will have the same identifiers, and the certificate will be displayed.

Steps to Reproduce

1. Launch Fortify.
2. Open https://tools.fortifyapp.com/
3. Generate a self-signed certificate on the MacOS provider.
4. The certificate appears in the list.
5. Refresh the browser window.
6. The certificate disappears from the list.

Expected Behavior

The certificate should remain in the list even after a browser refresh and should be properly associated with its corresponding key.

Actual Behavior

The certificate is not displayed in the list after a browser refresh due to differing IDs for the key and certificate.

Additional Information

This could be an issue with either node-webcrypto-p11 or pvpkcs11. When the same procedure is executed on SoftHSM, everything works as expected. It seems that the pvpkcs11 module may not be assigning the CKA_ID to the key object. The application sets this property using the hash of the public key after key generation. Upon restarting the application, pvpkcs11 appears to recalculate CKA_ID.

Interestingly, the certificate ID remains unchanged after an application restart. This suggests that the issue might not be with the key's CKA_ID, but rather with the certificate's. Further investigation is needed to pinpoint the issue.

[microshine]

While debugging webcrypto-local for certificate import, I discovered an inconsistency in the behavior of the pvpkcs11 module on MacOS. Specifically, the CKA_ID attribute gets modified when creating a PKCS#11 object from the template.

Here's the relevant code snippet:

const id = await this.computeID();
// ... (other code)
this.p11Object = this.crypto.session.create(template).toType();
console.log(template.id.toString("hex")); // Outputs '73e4ac6199ba1ff0c29b44a72d643f43'
console.log(this.p11Object.id.toString("hex")); // Outputs '2d0cf479b87f65381e211287443ade9f1413b666'

The CKA_ID is supposed to be '73e4ac6199ba1ff0c29b44a72d643f43' as per the template.id, but it gets altered to '2d0cf479b87f65381e211287443ade9f1413b666' when the PKCS#11 object is created.

This appears to be a bug within the MacOS pvpkcs11 provider. It may require an internal modification to preserve the CKA_ID as-is during PKCS#11 object creation.

[microshine]

I have opened an issue in the pvpkcs11 repository to address this. You can find more details and follow the progress here: PeculiarVentures/pvpkcs11#56

[microshine]

I've fixed the C_CreateObject issue in pvpkcs11. You can grab the updated library from the artifacts here: GitHub Actions Run.

I've tested it on my macOS and Windows setups. It'd be great if someone else could also give it a try.

[WorldThirteen]

This fix works for me on MacOS

[WorldThirteen]

Fix works for me on Win 10 too.

[microshine]

Thank you, @WorldThirteen, for the test