Re: [Mathmesh] A different approach to key escrow

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 06 September 2019 02:26 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: mathmesh@ietfa.amsl.com
Delivered-To: mathmesh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2398C12011C for <mathmesh@ietfa.amsl.com>; Thu, 5 Sep 2019 19:26:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9RxDHD4Obos for <mathmesh@ietfa.amsl.com>; Thu, 5 Sep 2019 19:26:35 -0700 (PDT)
Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com [209.85.167.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07860120043 for <mathmesh@ietf.org>; Thu, 5 Sep 2019 19:26:35 -0700 (PDT)
Received: by mail-oi1-f182.google.com with SMTP id h4so3697069oih.8 for <mathmesh@ietf.org>; Thu, 05 Sep 2019 19:26:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OK0fXHI0UHMdmaZE4f1ZRpFc1BqpJBPFkO8mwvO7LTw=; b=VPqttkeYxPz804pqVfxacwNLgocay6wq7zZW1DUN2cch6X7TCkslAltgGP7WRacCBw TzmMtJUaN70AhNSALW9DBcTgvAxzfmcNjg2T7W+CM5yaOs9E/DOpCCLgi5jI5Xa+ZiZk 1MV/9kIR0md13qea3UTf0DnyRiQ7AupAorl3Wfhiy28u4YjyLapDJUBSRaFwJPyQDuFT IJwvHlZTnscNfIqFogS0YRaq8Fa9Ft+waR2NzV3oPVzU81bCtaXNjlJZYKfSEbWxzaJ6 DbX+K17RpxKanfrPoGqI0HzA4e+5d80GocklAnOngWEi8EOnY3vvw43Ljykh6jVIvlc0 yUBg==
X-Gm-Message-State: APjAAAWEispcgQhTtOGU/WycsEggk7uXJjCqXKWdiwenz9nw5kWSzXI6 0MWl2dZYDdljQbM31UT610xLU2YeHxfjd2YeZP+pdJT+
X-Google-Smtp-Source: APXvYqx7zryw23CRAPxLrk3701Km7IuZeXrk83gpy33v7tymA4B+2X5fRy+tpyR42nRp+R+7/49SpSVvF6gvCyVLaXE=
X-Received: by 2002:a05:6808:296:: with SMTP id z22mr638416oic.6.1567736794145; Thu, 05 Sep 2019 19:26:34 -0700 (PDT)
MIME-Version: 1.0
References: <CAMm+LwiZqA=M90YdmQOV+sAy+T-prhzphct2bsOyPmaQ4V2oOA@mail.gmail.com> <6241.1567487279@localhost> <CAMm+LwhKHHz8e6b2C61zjFDv+shsLsBgxaAv=88dFG3kdJ9Fiw@mail.gmail.com> <14973.1567579627@dooku.sandelman.ca>
In-Reply-To: <14973.1567579627@dooku.sandelman.ca>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Thu, 5 Sep 2019 22:26:22 -0400
Message-ID: <CAMm+LwhYv+m3swyipb5_7_N0-f0wM4MBSW4KFz4c=WT4jQzHfw@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: mathmesh@ietf.org, cfrg@irtf.org
Content-Type: multipart/alternative; boundary="000000000000b767e10591d92ac4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mathmesh/TWEpedkAZHNAA5vUlHQ3hCA4tlA>
Subject: Re: [Mathmesh] A different approach to key escrow
X-BeenThere: mathmesh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <mathmesh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mathmesh>, <mailto:mathmesh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mathmesh/>
List-Post: <mailto:mathmesh@ietf.org>
List-Help: <mailto:mathmesh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mathmesh>, <mailto:mathmesh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Sep 2019 02:26:37 -0000

On Wed, Sep 4, 2019 at 2:46 AM Michael Richardson <mcr+ietf@sandelman.ca>;
wrote:

>
> Phillip Hallam-Baker <phill@hallambaker.com>; wrote:
>     > OK so here is the difference.
>
> okay, thank you.
> I didn't realize the "done now" version encrypted the private keys like
> that.
> I assumed in my brain that it would always be the KDF version :-)
>
> > Escrow Key = HKDF ( [97 BE C3 8C EC 32 E3 A8 14 BE 38 AC 49 B3 58 D0],
> > "mmm/mesh-escrow/X448", 448)
> >
> >So now recovery of the escrow record ONLY requires the master secret
> >ECL3-5Q4M-5QZO-HKAU-XY4K-YSNT-LDIA. There is no encrypted escrow record.
>
> I'm confused here.  Isn't the private key is deterministically created
> from the
> master key, why do we need an escrow key?   Won't the key need to be
> numbered
> so that one knows which of potentially many pieces are generated? Or is
> there a master key for each key that Alice needs to generate?
>

Ah, the escrow key is the 'master escrow key' that may be used to create an
escrow record for the user's application keys should they choose.

So let us imagine that I am using OpenPGP and disk level encryption. I will
have an encryption key for both applications. I might not want to escrow
the encryption keys for the applications at all but it I did, I could
create key shares for those applications as for my mesh signature key or I
could just escrow them to my mesh escrow key.

Sorry for the confusion. There are two different levels of encryption going
on.





>     > Pros: More convenient.  Cons: The private keys have less ergodicity
> and
>     > are related by means of the HMAC function.
>
> I think that it's okay for the reasons you gave.
>
> Nico Williams <nico@cryptonector.com>; 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.
>

Allowing escrow of the secrets alone allows them to be protected using
steganographic techniques.

For example, let us say we want to hide the secret
SAYE-UHOY-TVZO-LPGT-ZAGE-7JUW-6MTJ-I

So lets render it in Base-32768-English which uses a dictionary of 32678
words to represent the code points. It (might) now become

Marmalade Snorkel Tuna Smoked Perambulate Throat Wombat Perfume Dredging
Tufted

That is something I can read to someone over a (secure) telephone line or
write down in a book




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

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.



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

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.