Implementing Shamir's Secret Sharing for tokens

[jmls]

I really like the idea of the unsealing of the vault by having to pass in x of y secrets. I was wondering if it would be possible to leverage a lot of the code you've already written in order to provide a seal/unseal cli call for a token

I really don't want to have to store the equivalent of a root token *anywhere*, or have one person know this token, but in order to start reading / writing tokens, you need a token, kind of a catch-22.

So it struck me that it should be "trivial" for you guys to provide a seal/unseal on a token : 

#1 "seal" a token by calling /token/seal?numkeys=9&required=7 - this takes the current token and seals it requiring 7 of 9 secrets to unseal

#2 unseal a token by calling /token/unseal?key=<key>:  call n times until threshold met. when the threshold has been met, return the token

At least this way no single token needs to be made available to either scripts, vars or users

thoughts ?

[Armon Dadgar]

Hey,

It would be possible, but there is a question of UX difficulty in using Vault.

There are also some challenges of around the stateful nature of using Shamir’s.

The system needs to track the state of every operation and the partial progress,

handling rollbacks, cancelation, etc.

Of course, most of the internal infrastructure needed to do this is already in Vault

for unseal. We are trying to focus on the common use cases, and ensure the

UX is simple enough that developers and operations don’t start avoiding Vault

due to the challenges in using it.

We have an open ticket to support generating a root token given the unseal key

holders, so one option is to simply delete the root token immediately, and then

use the upcoming root generation features to make a new token as necessary.

Hope that helps!

Best Regards,

Armon Dadgar

--
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/1205bdcc-aaf1-4e86-bd62-c3ddcd79a7ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jmls]

looking forward to the release where the token stuff is in !

Another question : when you are unsealing the vault, how do you know when the threshold has been reached ? Do you store the original threshold somewhere ? And how do you know if an invalid share has been passed into the api ?

Ok, so another 3 questions ;)

[Armon Dadgar]

Hey,

The Vault server is minimally stateful, so it does track the key shards its received so far.

The original threshold is persisted in the backend so we know how many parts are needed.

A share is only known to be invalid after the keys are recombined and we verify the master key.

If any of the shards are invalid, the wrong master key will be computed and decryption will fail.

Vault then reverts back into a sealed state.

Hope that helps!

Best Regards,

Armon Dadgar

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/04809d94-8470-407e-b6ef-f194a1f27061%40googlegroups.com.