New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a generate-share endpoint for getting new master key shares #2523

Closed
wants to merge 26 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@jam-pot
Copy link

jam-pot commented Mar 22, 2017

Shamir's allows for generation of new master key shares so that we don't have to generate a new master key and re-issue new shares to existing shareholders.

I've added a generate-share endpoint which can be used to get a new master key share using this property of Shamir's.

It works in a similar way to the generate-root endpoint. First, initialise the endpoint with a PGP key. Then, provide a threshold number of shares in order to retrieve a new share which is encrypted with the provided PGP key.

@jefferai

This comment has been minimized.

Copy link
Member

jefferai commented Mar 22, 2017

Hi James,

We'll have to talk about this internally and see if we want to merge it. One main issue I see is that being able to add new shares at any given time removes some oversight from the process. Even though only a threshold is required to perform the rekey, in the end, all unseal key holders are made aware that the change has taken place; here, the number of unseal key holders could increase indefinitely without any such notification to previous unseal key holders. This kind of oversight is something that our auditors like to see, and I'm generally inclined to agree with that position.

This also may potentially clash with some things that are scheduled with 0.7.1, among them the fact that we're probably going to be deprecating PGP support in favor of a new mechanism, but that's not yet set in stone.

@jam-pot

This comment has been minimized.

Copy link
Author

jam-pot commented Mar 22, 2017

I look forward to hearing about the new mechanism!

James Hall and others added some commits Mar 25, 2017

@jefferai

This comment has been minimized.

Copy link
Member

jefferai commented Apr 14, 2017

Hi @jam-pot ,

Separately from any new mechanism, we have decided not to implement this. We're not comfortable with the idea that eventually this can allow new key share holders without oversight from the original designated set.

Thanks for submitting this though!

@jefferai jefferai closed this Apr 14, 2017

@jam-pot

This comment has been minimized.

Copy link
Author

jam-pot commented Apr 14, 2017

Hi @jefferai, thanks for the comments. It would be helpful to know about particular scenarios you are wanting to avoid. I don't quite understand why the "original designated" set of shareholders is more important than any others that are added - if a threshold number have agreed to bring in another shareholder, then they must be trusted to hold that share. Perhaps I'm not thinking widely enough but a threshold number of shareholders are capable of generating a root token which is a greater risk than generating a new share and this functionality exists in the API already.

@jefferai

This comment has been minimized.

Copy link
Member

jefferai commented Apr 14, 2017

Given key holders A, B, C where the threshold is two, let's say you want to add another two key holders for redundancy -- so now you have A, B, C, and D with a threshold of two. Maybe C is not actually trustworthy, and is able to convince their buddy D to generate another share with them to give to more operators ("I'm just super worried about not enough people being on call"), so now you have an untrustworthy C and E with a threshold of two. C and E can now generate as many shares as they want and as many root tokens as they want, and A or B are never a check on C's behavior, whereas in the original scenario A or B would be able to put a stop to what C is trying to do.

Granted in a rekey process if C manages to convince the others to add both D and E that could still happen, except with two differences: one, if there were five key holders at rekey time you may well move to a threshold of three, still requiring A, B, or (after rekey) D to be involved; two, the actual generation of a key share for E required A or B to be involved, rather than happening between just C and D in the above scenario.

Even if C and E are actually honest, maybe over time people keep adding more shares to allow others to unseal or generate root tokens. Maybe some of those people are not actually honest (but if A and B feel that way they're unnecessary at that point). Now you've gone from a conspiracy of 2/3 to a conspiracy of 2/13 -- much more likely.

Finally, it's arguable that generating a root token is a greater risk than generating a new share. New share generation can be used to then achieve root token generation success by bad actors; additionally, while generating a new root token is bad in the wrong hands, allowing those wrong hands to combine their unseal keys and get the master key is even worse since that divulges everything; even the sys/raw endpoint filters out anything under core/.

@jam-pot

This comment has been minimized.

Copy link
Author

jam-pot commented Apr 14, 2017

I think the low threshold scheme argument is a fair one. Being able to generate the master key from a threshold number is true whenever n >> t, regardless of whether its possible to generate new shares or not, however.

I wonder if it would be better to combine share generation with an alerting mechanism. Perhaps emailing every shareholder using the email address held in their PGP key when a new share is created?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment