Generating RSA keys with vault

[Bruno Mattarollo]

Hi there,

From the archives of this group, I saw that this question was asked however the use case wasn't described, so if I may, just ask again with a bit of a description of our use case. And, maybe, since time has passed, there might be a solution for this.

We currently generate an RSA keypair with CloudHSMs and use the public key on our web app to encrypt sensitive data as soon as it is entered by the fundraisers (our app supports charities, not for profits and member organisations around the world). Once the data is received by our app, we then send the ciphertext to the HSM which uses the private keypair (which we create with parameters that prevent that key from being extracted, etc) to decrypt the ciphertext and we then use a symmetric key to encrypt it (also using the HSM) and store that in our DB.

The CloudHSMs are great for compliance however for a bootstrapped startup, well, they really hurt every month ... when you realise that a very large chunk of the infrastructure cost just comes from those devices.

There are other considerations, not just financial ones ... but we'll leave those aside for now. 

We're subjected to PCI DSS level 1, been compliant and renewed our compliance once, so we really want to keep that :) 

So, now comes the question ... I am considering putting in place Vault to, not only manage our infrastructure secrets (passwords, API keys, etc) that we currently store encrypted on disk (and use ansible-vault for storing in our config management), but also to use the transit backend to encrypt the data that we store for our customers. The symmetric key part is not a problem, given the transit backend and all the measures that can be put in place to mitigate possible vectors of attack, the ability to have many data keys, etc. The RSA keypair, on the other hand, is another issue all together. For PCI's purposes, the HSM is great as the keys are generated on the certified hardware and we don't need to handle the plaintext keys, which helps enormously. I could generate the RSA keypair on an isolated instance and store the private key in the HSM, etc however ideally, I would prefer the ability to ask Vault to generate a keypair, never show me the private key, and use an API call with a token, etc to send it ciphertext and get it decrypted by Vault. A bit like a transit backend but with a public/private key pair.

Is this use case a common enough one that would warrant such a feature in Vault? Is there such feature planned for the future of Vault? How do others manage in these scenarios?

Recently I saw the `safe` tool from Stark and Wayne, which has the ability to generate an RSA key ... however it does so outside of Vault using Go libraries, calls, on the client ... Ideally, this would be something that fits into Vault's operations (within the security teams realm, etc).

Sorry for the long email, I just wanted to give some context to my question ...

Thanks in advance for any responses or ideas on how this can be achieved with vault.

/B

--

Bruno Mattarollo | CTO & co-founder | @bmatt | Skype: brunomattarollo

[Jeff Mitchell]

Hi Bruno,

Meeting those kinds of needs in transit is definitely on our roadmap. I can't go into specifics now, but more features will be starting to appear in transit. In 0.6.1 we have convergent encryption...I am hoping more will be in 0.6.2 but it's too early to tell. What I can say for sure is that it is a use case we at HC are very interested in.

One question for you specifically though: is there a reason that you must use RSA keys for this workflow, especially since you are ending up with the information symmetrically encrypted in the end? Vault's ACLs allow you to give out tokens that can encrypt with a given key but not decrypt with it...ingressing customer data on servers that cannot actually be used to exfiltrate said data (since they have no decryption access) is a common Vault use case here. Would that work for you at least in the interim?

Best,
Jeff

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/CACGxCHONXr073Fhrh1DmmMS8sZN6c3DjmeVJAFveDeTdapGw4g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Bruno Mattarollo]

Hi Jeff,

Thank you for the prompt response.

Glad to hear it's an interesting use case for HC :-) #hopeful

As for your specific question, the main reason is that fundraisers are often is areas that have limited connectivity and so, our app has to be able to work offline for extended periods of time, encrypting the data with a public RSA key, doing the best we can to ensure that the data cannot be decrypted on the device once it's been encrypted, etc. I'd also be hesitant to have our Vault server accessible outside of our VPC (we're using AWS as you'll have figured out by now).

Hope this answers your question,

Cheers

/B

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/CAORe8GEAtiQtRdRx6S2u0oHB%2B3TT4H_kQOfM8igoiXm5Ctt7%2Bw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[G. Santos]

Hi Bruno,

I'm not sure if this is still relevant to you at all, but one thing you could do is have an RSA Key Pair generated somehow, importing the private key into Vault, and distributing the public key to the fundraisers' devices. Then, have the application that handles the re-encryption of data with a symmetric key also handle the asymmetric decryption first (by requesting the private key from Vault).

I'd also be interested to find out if you decided to change anything, or if you kept on footing the bill for CloudHSM.

Guilherme

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/CACGxCHONXr073Fhrh1DmmMS8sZN6c3DjmeVJAFveDeTdapGw4g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
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/CAORe8GEAtiQtRdRx6S2u0oHB%2B3TT4H_kQOfM8igoiXm5Ctt7%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Bruno Mattarollo]

Hi Guilherme,

For the time being we are still using the HSM ... I want to avoid seeing the RSA private key, thus why the prospect of Vault handling that for me would be great. In the same way as the HSM creates and holds the private key without the operator handling it (which greatly facilitates our compliance burden), I would (ideally) still want Vault to do that, like when creating a transit key etc I don't have to handle them, Vault takes care of that so I can offload the process of creating the key material, etc to the vault itself.

So, I am still eagerly looking at the CHANGELOG on the vault github project every week :)

Cheers

/B

To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/63a53c1e-a8ad-4cbc-b145-ea86517e0c25%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Jeff Mitchell]

Hi Bruno,

We started looking at this last week (no promises on a timeframe, just scoping out the work). An interesting thing we found is that we can probably support convergent encryption with RSA keys, even though we can't generally support key derivation. So this would be really cool although it also means needing to do some internal logic changing to handle that case.

Best,

Jeff

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/CACGxCHOCvjY7dr7KqbHbW2vvrkXBdfiGXSe9kAnc74K6E185Eg%40mail.gmail.com.

[DG]

Jeff,

I wonder if there is any progress of supporting encryption/decryption in transit service for asymmetric keys?

Thanks in advance for your response.

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/63a53c1e-a8ad-4cbc-b145-ea86517e0c25%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Bruno Mattarollo | CTO & co-founder | @bmatt | Skype: brunomattarollo

--
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.

[Vishal Nayak]

Hi,

Since 0.9.0, the Transit backend supports encryption/decryption, and
signing/verification using 2048 and 4096 bit RSA keys.

Regards,
Vishal

> https://groups.google.com/d/msgid/vault-tool/d8abc8d0-9414-4b63-92ef-3f724e583ec1%40googlegroups.com.

>
> For more options, visit https://groups.google.com/d/optout.



--

vn

[DG]

Great news. Probably the documentation needs to be updated, it still states that only symmetric keys are supported: https://www.vaultproject.io/api/secret/transit/index.html

This endpoint encrypts the provided plaintext using the named key. Currently, this only supports symmetric keys. This path supports the create and update policy capabilities as follows: if the user has the create capability for this endpoint in their policies, and the key does not exist, it will be upserted with default values (whether the key requires derivation depends on whether the context parameter is empty or not). If the user only has update capability and the key does not exist, an error will be returned.

On Tuesday, November 21, 2017 at 12:12:46 AM UTC+8, Vishal Nayak wrote:

Hi,

Since 0.9.0, the Transit backend supports encryption/decryption, and
signing/verification using 2048 and 4096 bit RSA keys.

Regards,
Vishal

[Vishal Nayak]

Hi,

The documentation is now updated. Thanks for reporting.

Regards,
Vishal

> https://groups.google.com/d/msgid/vault-tool/5c9e0715-a4c0-44dd-8637-5c67558cc2ac%40googlegroups.com.

[Bruno Mattarollo]

Hey all,

As I am starting to write some tests and replacement code for our app that currently uses PKCS11 and HSMs to use Vault, I have a question that is probably simple and I might need to sleep on it, but I thought I'd ask rather than keep bashing my head against the wall.

Our application distributes the RSA public key to devices and those devices encrypt data to that key without having access to our vault. So I will only use the vault to generate the keypair and then to decrypt the payload once received and verified.

So in order to simulate that in my local dev environment, I am doing something like:

$ echo "some secret to encrypt" | base64 | openssl rsautl -oaep -encrypt -pubin -inkey file-with-public-key.pub | base64 > ciphertext.out

Now, I need to add the prefix (say vault:v1:) and then when I try to decrypt using vault I get failed to RSA decrypt the ciphertext: crypto/rsa: decryption error. The same happens when I use, say, https://github.com/travist/jsencrypt to encrypt a base64 encoded string.

I am a bit at a loss as to how I can encrypt a plaintext in a way that vault will be able to decrypt using the private key ... 

Cheers

/B

[Jeff Mitchell]

Hi Bruno,

I will take a look at this. I suspect it has something to do with specifying the right options on the openssl command line; FWIW, here is a full-round-trip operation using Vault alone, just as a verification that Vault can encrypt and decrypt the values using the held keys. Will get back to you when I have some more info:

$ echo -n "encrypt this" | base64 -w 0 | vault write -format=json transit/encrypt/rsa plaintext=- | jq -r '.data.ciphertext' | vault write -format=json transit/decrypt/rsa ciphertext=- | jq -r '.data.plaintext' | base64 -d 

Best,

Jeff

--

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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/cecd69f6-04be-4a2b-bbac-d8edc1ddb440%40googlegroups.com.

[Jeff Mitchell]

Hi Bruno,

Got it. You have to use pkeyutl, not rsautl, and there are some options that are required that aren't even documented on openssl's wiki (https://wiki.openssl.org/index.php/Manual:Pkeyutl(1)) :-/

According to some stuff I read around, the order of operations may very well matter for pkeyutl, e.g. -encrypt before -inkey, and the rsa_padding_mode option before the rsa_oaep_md option:

$ vault mount transit; vault write transit/keys/rsa type=rsa-2048

Successfully mounted 'transit' at 'transit'!

Success! Data written to: transit/keys/rsa

$ vault read -format json transit/keys/rsa | jq -r '.data.keys["1"].public_key' > public.pem

$ cat public.pem 

-----BEGIN PUBLIC KEY-----

MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy1VkM/jNU1VisaFIIv2D

u3bJd2oJo5I6uUkWNNCQT+ORGgBKfRbftdZyFM531X+Vb3yEwyiESpvw/wAoSThV

blUR0DnEUGwOvuTmsPyZtki2qc1PVaLlRrekaFThCtpAb0dylg9rD9y3UC6Gs4hE

expS4DbD80h6L50YSqrMx1/IuZWqAXrIVniF1sss43zvDqZerspjjeJSSvUh+iEz

9+x3AAQc5ftTPFrPSCkHBzVFZ2JJuqTjvU/sfgUN6sHpER6r2rzMm1w2o1eDFNCC

sdlFwR5f16Slw8WaJRP2TsUZWIFmheNd1SmhFUon2mW5J1VCHRJW+YZ7rWcPoAAa

OQIDAQAB

-----END PUBLIC KEY-----

$ echo -n "vault:v1:" > enc; echo -n "encrypted value" | openssl pkeyutl -encrypt -inkey public.pem -pubin -pkeyopt rsa_padding_mode:oaep -pkeyopt rsa_oaep_md:sha256 | base64 -w 0 | cat >> enc

$ cat enc 

vault:v1:Wi0v6KJrtKLP99+7SWv0n/E8MBFSp/o/ASi+a9WOQv3k/kG9oCSWL4rOhCuhwARs9prh21b1/ixBhfll28M+1azuo9DsxSAAbjdfvm8MtLRff+qQP/RQ4YartKbNm+vOiaQD801kOfT6WuvBBiu/eaB2nxP6kSHyz22vBBTxh/TJVi1/jq+S3guGcpQChT9j1PQ51UJ0rntPy9odPs6FVhLLlVz3mqAtwfQ0jOpmT9Lpagtlrik6MCpZT1RQ2aQKkAOlY8XrO3M4wSpp4xFDY36F1+mEMJrpLUFNoFSIoSZG4EqWXiTrHJUgXrL6LPRbdcpID7IqO+jWJywPSVKsVQ==

$ vault write -format=json transit/decrypt/rsa ciphertext=@enc | jq -r '.data.plaintext' | base64 -d

encrypted value

Best,

Jeff

[Bruno Mattarollo]

Hi Jeff

Ah! OpenSSL is even more cryptic than PGP ;) thank you so much for all this, it’s super helpful and detailed. 

Cheers

B

Mobile, so being brief

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/CAORe8GHZE7T2sHQKJ3Kb9is7ymns_fzVzXSq97KwVY27ZJLNWA%40mail.gmail.com.

[Jeff Mitchell]

Hi Jiri,

RSA-OAEP can't be used for arbtirarily-sized messages. A good explanation of that can be found at https://crypto.stackexchange.com/a/42100

Often it's used not to directly encrypt data but rather to encrypt a symmetric key that is then used for the actual data encryption. So your final message can be a concatenation of the encrypted key (encrypted with the public key) and the accompanying, say, AES-GCM data.

Best,

Jeff

On Tue, Feb 13, 2018 at 9:00 AM, 'Jiri' via Vault <vault...@googlegroups.com> wrote:

 Thank you Jeff, this is very helpful. Small issue is that the encryption caps on 117 characters with error

RSA_padding_add_PKCS1_OAEP_mgf1:data too large for key size

did anybody figured if there is a way to flip the keys to GPG format or/and bypass this 117 characters limit?

thank you
 

RSA_padding_add_PKCS1_OAEP_mgf1:data too large for key siz

--
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+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/b4833027-7fa1-4168-a684-770b7fae363d%40googlegroups.com.