Re: [Mathmesh] [Cfrg] A different approach to key escrow

[Nico Williams <[e-mail]>]

On Thu, Sep 05, 2019 at 10:26:22PM -0400, Phillip Hallam-Baker wrote:
> On Wed, Sep 4, 2019 at 2:46 AM Michael Richardson <[e-mail]>
> wrote:
> > Nico Williams <[e-mail]> wrote:
> >     > I don't see why in the first case you'd need a separate
> >     > service to store the private keys encrypted in the master
> >     > secret.  All the entities that hold secret shares can also
> >     > hold copies of the encrypted record along with the secret
> >     > shares.
> >
> > This allows the secrets to split and sent to appropriate entities
> > once at the beginning of the process, and they never need to be
> > updated again.  Alice can generate as many keys (and as frequently)
> > as she wishes, interacting only with the escrow service.  Assuming
> > that I understand correctly.

If you use a master secret to to generate all the others, indeed.

The first scheme, however, requires storing updated encrypted secrets
payloads.  That's the "service" that we'd asked about, but I assumed the
services that store secret shares would also store those payloads.

> >     > However, you might find it difficult to generate key pairs
> >     > from a master secret, especially if you ever need to generate
> >     > keys on a hardware token.  If you won't have that requirement,
> >     > and if you're willing to have that as an anti-requirement,
> >     > then the second scheme is simpler, indeed, and the entities
> >     > that store key shares will need to store smaller records.
> >
> > You are saying: If you use a hardware token, then you need the escrow
> > service.
> > Isn't it the case that some hardware tokens have no mechanism to get the
> > private key out?  I guess they are SOL regardless of scheme.

Yes, though I expect wrapped key export to be generally available,
still:

> I agree. If someone is using a hardware token, the hardware token needs to
> manage the escrow mechanism itself (e.g. like the way Luna cards do). But
> it will in any case need a way to import a private master key generated
> elsewhere.

not supporting such tokens is a reasonable thing to do.

> > Couldn't we generate per-key escrow keys from the master key using
> > the same KDF mechanism?  Doesn't that get us the best of both worlds,
> > with the confusion as to how the different

That enlarges the amount of secret share storage needed, which gets us
back to Phillip's desire to avoid that.  A nice feature of this scheme
is that there's a fixed number of fixed-sized keyshares generated early
on and this need never change unless you want to re-key everything.

Speaking of which, how does master secret change work?

> Hmm... that might be the way to do it. The only problem is that then you
> need access to the offline master to be able to generate application key
> sets and the idea of the offline master is that you should only need to
> ever use it when changing your administration device.


Nico
--