search

GoogleCloudPlatform / kms-integrations

https://cloud.google.com/kms
Apache License 2.0
39 stars 13 forks source link

Using Google KMS pkcs11 with ThalesIgnite - crypto11 library #1

Closed PunitNaran closed 3 years ago

PunitNaran commented 3 years ago

I have a production application currently using AWS and Thales HSMs. We're looking at moving to use a Google HSM, so I'm trying to use this Google PKCS11 library from Go using the Thales Crypto11 library: https://github.com/ThalesIgnite/crypto11, but several API's don't work.

C_GenerateKeyPair - works only when setting the CKA_LABEL attribute and a Google-specific CKA_KMS_ALGORITHM attribute, whereas our application also sets the CKA_ID attribute along with other attributes set by the Crypto11 library - C_GenerateKeyPair to return an error. See here for the attributes that Crypto11 is setting: https://github.com/ThalesIgnite/crypto11/blob/master/ecdsa.go#L252-L264

C_FindObjects - also does not work when the CKA_ID is specified, but also when just CKA_LABEL is used it is not clear what exactly C_FindObjects is returning and the Crypto11 code is not able to parse it into keys.

C_DestroyObject - this call returns an error "failed to destroy public key" however after the error looking in the Google KMS console the keys do appear to be removed from anyway.

Can you provide any guidance on what we can do about these?

We could provide testcases for each of these if that would help?

bdhess commented 3 years ago

Thanks for reaching out.

I'd suggest https://github.com/sethvargo/go-gcpkms as the best way to make a crypto.Signer that's backed by a GCP HSM key. This is a native Go solution that avoids depending on a PKCS #11 library (and thereby avoids CGo).

To answer your specific questions:

C_GenerateKeyPair - works only when setting the CKA_LABEL attribute and a Google-specific CKA_KMS_ALGORITHM attribute, whereas our application also sets the CKA_ID attribute along with other attributes set by the Crypto11 library - C_GenerateKeyPair to return an error.

CKA_ID isn't user-settable in our library. The value is assigned by the remote Cloud KMS service, and is the full name of the KMS CryptoKeyVersion.

C_FindObjects - also does not work when the CKA_ID is specified, but also when just CKA_LABEL is used it is not clear what exactly C_FindObjects is returning and the Crypto11 code is not able to parse it into keys.

I'm curious about the errors you're seeing here when trying to retrieve keys by label.

C_DestroyObject - this call returns an error "failed to destroy public key" however after the error looking in the Google KMS console the keys do appear to be removed from anyway.

in Cloud KMS, public and private keys have a shared lifecycle. We model that in our PKCS #11 library by making only the private key destroyable: CKA_DESTROYABLE is true for private keys, and false for public keys.

PunitNaran commented 3 years ago

Hi @bdhess thanks for reaching out.

I'll start working on using the go-gcpkms wrapper. I was hoping to use the Thales that accompanies some major HSM/KMS providers.

The error I get when I'm trying to retrieve keys: "unexpected data found when parsing elliptic curve point" I guess that can be the private attributes that are being set may not be correct?

bdhess commented 3 years ago

Thanks. There's a bug here with how CKA_EC_POINT is encoded. We need to fix that, and add a better test case.