Re: [DNSOP] DNSSEC threshold signatures idea

Michael StJohns <msj@nthpermutation.com> Thu, 06 September 2018 19:52 UTC

Return-Path: <msj@nthpermutation.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12DC9130F39 for <dnsop@ietfa.amsl.com>; Thu, 6 Sep 2018 12:52:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com
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 Zjd81CjnxAPJ for <dnsop@ietfa.amsl.com>; Thu, 6 Sep 2018 12:52:39 -0700 (PDT)
Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 A0C3C130E93 for <dnsop@ietf.org>; Thu, 6 Sep 2018 12:52:39 -0700 (PDT)
Received: by mail-pf1-x42a.google.com with SMTP id b11-v6so5805895pfo.3 for <dnsop@ietf.org>; Thu, 06 Sep 2018 12:52:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=p9rZhw2whJUovRIBSE81/2f1Nqa6xYYfgvrrC0hVeFA=; b=mhoQCHKtNN0GsuCCKkMe77hs8BHvYAmJRXEx0b1TCFM4zBQ2ks1CnFVl/5M5tOC1ml Q9qMTMKoJNBwQPcnrKEVCtMgn+1gwoKBo+GdNPBCik5S7dAS009Lji/JwcLe9YokJbOf 6evBcELohGICVw58Ykp8cehrbNshWJ/G8VM29YQb6rtgY7KRcb7SHKipwEsJwltFqdDw Fa0qXLc8jl2oVRfwlswQyjCdAgWBH/YL9keK83U/Xq+qXzpUeNgqiOc2HFzKHJTbL+LT hqo916sCdxa5hWGiba9rYGaRH5+b44cQiui0I0/doNa9JA44RGXakzCan4Zmg1UgNtDF fDJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=p9rZhw2whJUovRIBSE81/2f1Nqa6xYYfgvrrC0hVeFA=; b=MvgoFrp2u3Y0Ls6owR7WKGkuvFn9S/gGcSYtiYS88/tzNIXRiyrbIG4qSuBOcik1bE QVEOTDDj8JFTkG454KgdLrlcDuWT0xPuMSz4U24xxMR0hVPdfQ2WdwHXC9i93gynNHNn WVzqrS+Lk7CkViBnrU/ZbB38G306n2U5sXgwhxcDQbbUmK1YFxxsYb20Yhvh+8a9JYdC Zd/2hU/F64X5OFSDakZYQUs4gjfUki+yzEC06ZVI6cVazxH7j0m36A/GJpPLx73CCInb Rmob1H8hUGD7LSUu848TRKnIsSNIX6r2MKuj7FbJ8HUgM0CRxZlLsUip3inyPD8P+nra wKAw==
X-Gm-Message-State: APzg51BmLS/d6ql45nkE8TVLqRagkZKd+iRZYAdPJID/k7Ws0YLsmEc0 Pje+TfI1qtaHnDeB1U5DbSxJ/0LrsG0=
X-Google-Smtp-Source: ANB0VdbIf1diDcaO5XGXd+EP4MTOgojF7g4r+uWywi9rexjIIXaSJvMNFGQvCH6tVfyNbluJ9gwlmA==
X-Received: by 2002:a63:6243:: with SMTP id w64-v6mr4588582pgb.145.1536263558611; Thu, 06 Sep 2018 12:52:38 -0700 (PDT)
Received: from [10.230.65.30] (edge-gw-rwc.silverspringnet.com. [74.121.22.10]) by smtp.gmail.com with ESMTPSA id j27-v6sm11200963pfj.91.2018.09.06.12.52.37 for <dnsop@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Sep 2018 12:52:37 -0700 (PDT)
To: dnsop@ietf.org
References: <20180906161252.GA2840@jurassic> <20180906173412.og736bryaeqbwjds@nic.cl> <20180906174926.GA9614@jurassic> <20180906190257.ig6yqgi5fsfepklz@nic.cl> <CABf5zv+-qH+k6Ts6W-+1Z4QsGYYPrtNiqgTL9jgZORcURFQ1vg@mail.gmail.com>
From: Michael StJohns <msj@nthpermutation.com>
Message-ID: <6e88fee9-1345-8e98-a3d6-ac9f7eb6bb05@nthpermutation.com>
Date: Thu, 6 Sep 2018 15:52:36 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <CABf5zv+-qH+k6Ts6W-+1Z4QsGYYPrtNiqgTL9jgZORcURFQ1vg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------AE08A9E02075E9C231E31507"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/hyPmSMhpZvzlfJ7V6k6qPmvWh50>
Subject: Re: [DNSOP] DNSSEC threshold signatures idea
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Sep 2018 19:52:43 -0000

On 9/6/2018 3:08 PM, Steve Crocker wrote:
> How do you prevent compromise of the central service?

The "Dealer" is only doing confidential processing during the key 
generation phase.   Once that's done, you can do a wipe.   The 
subsequent signature operations are all distributed.  The combine 
operation is public.

Let's pause here for a moment though.   Shoup came up with a threshold 
system that worked this way - but only for RSA signatures.   I actually 
built (and still have) the tools to do a N of K distributed DNSSEC 
signing process using his scheme.

> /**
>  * A key Dealer for an RSA-based (k,l) Threshold Signature Scheme<p>
>  * Portions Copyright (c) 2004 Nominum, Inc.<p>
>  * Substantially modified from Steve Weis' original to enable
>  * real (e.g. compatible with the JCA/JCE) RSA signatures.
>  *
>  * @author Steve Weis <sweis@cs.berkeley.edu>;
>  * @author Mike StJohns
>  * @see "Practical Threshold Signatures,
>  * Victor Shoup (sho@zurich.ibm.com), IBM Research Paper RZ3121, 4/30/99"
>  */



  Specifically the scheme generates K shares of a private key and 
distributes them.  The share holders generate partial signatures across 
the same identical data and publish those partial signatures.   
Publicly, anyone who wants can take those N of those partial signatures 
and form a normal RSA signature. (which can be verified using normal RSA 
signature/verification primitives).

AFAICT, there isn't an ECDSA system that has the same characteristics.


Lately, I've been thinking about a non-math based threshold system.

1. Assume you can program a policy wrapper around key material on an HSM 
(e.g. javacard scheme for example) - then
    a) Have K people generate key pairs and send the public keys of the 
key pairs to the HSM owner.  These represent the K keys of key share 
holders set H.
    b) generate a key pair providing H as an input and with the 
following policy
            the private key will sign data IF and ONLY IF it first sees 
N different valid signatures over the same data by the members of set H.
2) Signing manager generates and publishes the "to be signed" data
3) After public concurrence, the members of set H sign the data and 
publish their signatures.
4) After verification of sufficient valid signatures by the H keys, the 
HSM manager presents those signatures (and their related public keys as 
in index) to the HSM and retrieves and publishes the final signatre.

This is trivial to implement on a javacard and there are a few HSM 
vendors that are now providing support for scripting key policies that 
are much richer than PKCS11 can express.


PS - the RSA scheme is pretty neat in that it's invertible.  E.g. I can 
encrypt something using the public key, and then require N share holders 
to decrypt it.

Mike

>
> Steve
>
>
> On Thu, Sep 6, 2018 at 3:02 PM, Hugo Salgado-Hernández 
> <hsalgado@nic.cl <mailto:hsalgado@nic.cl>> wrote:
>
>     On 23:19 06/09, Mukund Sivaraman wrote:
>     > On Thu, Sep 06, 2018 at 02:34:12PM -0300, Hugo Salgado-Hernández
>     wrote:
>     > > Hi Mukund.
>     > > I talked about this to Davey in Montreal. There's an
>     implementation
>     > > in github[1] and presentations in OARC[2] and ICANN[3].
>     >
>     > Aha so you're the original source :)
>     >
>     > > I'm not sure if its being used right now in a live zone, but
>     certainly
>     > > in labs and testing. There's been some interests with academic
>     > > institutions, but don't think they're ready yet.
>     > >
>     > > We've been trying to focus this technology as a "poor-man" HSM, as
>     > > having similar security features without buying an expensive HW.
>     > > But I think the root and similar high-value zones will benefit for
>     > > having an split of the private key AND the fact of not needing a
>     > > "root key ceremony" to sign, because you can sign remotely with
>     > > each piece of the private key, and transmit the "signature pieces"
>     > > to a central place.
>     > >
>     > > Hugo
>     > >
>     > > [1] https://github.com/niclabs/docker/tree/master/tchsm
>     <https://github.com/niclabs/docker/tree/master/tchsm>
>     > > [2]
>     <https://indico.dns-oarc.net/getFile.py/access?contribId=22&sessionId=3&resId=1&materialId=slides&confId=20
>     <https://indico.dns-oarc.net/getFile.py/access?contribId=22&sessionId=3&resId=1&materialId=slides&confId=20>>
>     > > [3]
>     <http://buenosaires48.icann.org/en/schedule/wed-dnssec/presentation-dnssec-cryptographic-20nov13-en
>     <http://buenosaires48.icann.org/en/schedule/wed-dnssec/presentation-dnssec-cryptographic-20nov13-en>>
>     >
>     > So this's implemented as a PKCS 11 provider.. interesting. In my
>     mind I
>     > was thinking along the lines of updates to dnssec-keygen +
>     > dnssec-signzone + intermediate RRSIG representation using new RR
>     type +
>     > zone transfers to share intermediate effects.
>
>     In our implementation you'll need a central "orchestrator" who
>     creates the first key and split the private pieces to each
>     signing node. This same orchestrator later send signature
>     requests to each node, collect the signature pieces and
>     defines the "consensus" of M/N. Finally, there's an PKCS11
>     interface between this orchestrator and the zone signing
>     policy machinery (OpenDNSSEC in our setup).
>
>     Hugo
>
>
>     _______________________________________________
>     DNSOP mailing list
>     DNSOP@ietf.org <mailto:DNSOP@ietf.org>
>     https://www.ietf.org/mailman/listinfo/dnsop
>     <https://www.ietf.org/mailman/listinfo/dnsop>
>
>
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop