Hashicorp Vault Data Encryption Key (Transit Backend) Vs. AWS KMS Data Encryption Key

[Yossi Cohen]

Hello,

Envelope-Encryption is a great pattern that allows encrypting data at-rest and at scale without too chatty interactions with KMS API. 

It has many more merits that I am currently not listing here.

AWS KMS API fully supports it and Hashicorp Vault (Transit backend) seems to provide most of the capabilities to support this pattern too. 

However, it appears there is one gap in Hashicorp Vault, which can be easily fixed to better support Envelope-Encryption.

AWS KMS API ensures that the Data Encryption Key is produced via a read-only API that does not store it. It is good for segregation and for storage scaling (especially in cases where there is one DEK per data object). 

Currently, Hashicorp Vault (Transit backend) use a stateful API to generate the data encryption key and store it inside Vault. Even though it may seems to provide some flexibility (future automatic key rotation support), it is mainly a limitation for systems that wish proper segregation & scaling. 

I would like to propose to fix the API that generate DEKs such that it also allows (e.g., via input parameter, a flag) generating DEKs in a complete stateless manner and without storing it anywhere.

Application can generate DEK by itself quite easily but then it requires another hope to the KMS in order to encrypt it.

What do you think?

Vault Team, would you consider adding it to your JIRA backlog?

Thanks,

Yossi C. (Amdocs)

[Chris Hoffman]

Hi Yossi,

The workflow you are suggesting is already supported by Vault!  Check out the data key endpoint in the transit backend https://www.vaultproject.io/api/secret/transit/index.html#generate-data-key.  The named encryption key (Master Key in KMS docs) is used to create and decrypt they data keys while only the "master" key is stored in Vault.  

Chris

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/vault/issues
IRC: #vault-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Vault" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/e99c0bcb-8f81-4681-a247-32ac08ac1a35%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Yossi Cohen]

Thank you Chris,I appreciate your swift response. I received another response from Hashicorp for which i created this post in the first place:

"To scale Vault horizontally you can create secondary clusters using the replication features and use these secondary clusters to distribute load. Updates to Vault configuration and secret backends will still be performed by the primary cluster, but this allows reads to scale horizontally. This includes encrypt, decrypt, rewrap, hash, and hmac operations in the transit backend." 

You can see that datakey API is excluded. When i asked about it, i have been told 'datakey' is a write API:

"Generating a datakey through POST /transit/datakey/:type/:name would be considered a write so it would have to be forwarded to the primary cluster..." 

And

"...The datakey is stored in Vault so that Vault can manage versions of it and rotate it in the future as needed. It also allows you to offload crypto operations to Vault using that key if you didn't want to export it..."

Can you please comment on Hashicorp responses above and advise how can we ensure stateless operation of datakey?

Thanks,

Yossi C.

[Jeff Mitchell]

Hi Yossi,

That response is incorrect. Datakey is supported in this scenario -- I
think whoever gave you that mixed up the actual keys in transit vs.
the datakey API (which is really a helper around generating random
bytes and encrypting them). Not only that, but scaling secondaries
will forward writes to the primary, so even if it required a write it
would still work if connectivity was established.

Best,
Jeff

> https://groups.google.com/d/msgid/vault-tool/a10fb5ff-a38c-42d8-97fa-704bd6c6f9c5%40googlegroups.com.

[Yossi Cohen]

Thanks a lot Jeff, that is very helpful.

Best Regards,

Yossi C. (Amdocs)