Encrypting keysets w/ Google KMS

[Maya Midzik]

Hi All,

Thanks so much for this library and all you do here! I'm looking at using Tink (the golang library) with Google KMS for encryption. My use-case needs to support large-scale application traffic, so using KMS encrypt/decrypt for each secret is cost prohibitive. When evaluating Tink, I'm planning to use another primitive and encrypt the keyset with the cloud KMS, per recommendation #2 on this page, and wanted to get feedback on approach.

Before evaluating Tink, I was planning to simply create keys, store them in Google Secret Manager, and use a different cryptography library for local envelope encryption. In this scenario, the KEK would be retrieved from GSM and used client-side to encrypt/decrypt the data. The main downside I've found here is the lack of backup protection or automatic rotation in GSM.

With client-side encryption and Tink, my understanding is I would need to do the following:

1. Create a primitive keyset
2. Encrypt that keyset w/ KMS
3. Store that keyset somewhere - this could be GSM, a protected cloud bucket, or my app storage (is there a recommendation here?)
4. Implement rotation of the primitive keyset (KMS will have automatic rotation, but this doesn't solve rotating the underlying keys)

Does the above sound correct? If so, I'd still need to implement manual backups + rotation, so I'm not sure it's much of an improvement over my initial GSM solution.

I found this old thread on GSM, which suggested direct GSM support might be getting integrated into Tink. Is that still in progress, or is there a recommended way to use Tink primitives w/ GSM?

Any thoughts/feedback appreciated!

Thanks,

Maya

[Maya Midzik]

Thinking this over, I realize that the Berlgas library does almost exactly what I'm describing - takes a value, encrypts it with KMS, and stores it in GSM or GCS. I'd still like to use Tink to generate my keysets and encrypt / decrypt, but wondering if I should perhaps consider the following:

1. Use Tink's insecurecleartextkeyset for my keyset
2. Encrypt w/ KMS and store using Berglas

I'm wary of using insecurecleartextkeyset given the various documentation warnings, but this seems most correct / performant given my constraints?

Thanks again,

Maya

[Charles Lee II]

Once you encrypt a keyset using a KMS, the encrypted keyset can essentially be stored anywhere. For example, with envelope encryption, a fresh data encryption key is generated for each plaintext, which is KMS encrypted and stored directly alongside the ciphertext. So all of the options you listed (GSM, cloud bucket, app storage) are valid.

The larger concern is rotation of the data encryption key, which you would need to manage directly. I'd base the storage location choice on whatever makes your rotation process less complicated. Making any specific recommendation on this front depends on your application architecture.

There's no reason to use the insecurecleartextkeyset package. Instead, you can use the GetAEAD() method from the KMSClient interface to create an AEAD primitive backed by a KMS key. Then you use that AEAD as the masterKey argument to the Read()/ReadWithAssociatedData() and Write()/WriteWithAssociatedData() Keyset functions. Doing so allows you to directly read/write an encrypted keyset. (Note, I'm linking to godoc here since you referenced a Go utility. All of this is demonstrated in multiple languages at https://developers.google.com/tink/generate-encrypted-keyset.)

There are no GSM integrations currently being worked on, and, as far I know, no active plans for GSM to implement native support Tink in the manner described by Thai in that previous thread.

--
You received this message because you are subscribed to the Google Groups "tink-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tink-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tink-users/485ba180-291e-46ea-ae17-83081d1d3bban%40googlegroups.com.