Re: [DNSOP] DNSSEC threshold signatures idea

[Michael StJohns <[e-mail]>]

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 <[e-mail]>
>  * @author Mike StJohns
>  * @see "Practical Threshold Signatures,
>  * Victor Shoup ([e-mail]), 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 
> <[e-mail] <mailto:[e-mail]>> 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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/dnsop
>     <https://www.ietf.org/mailman/listinfo/dnsop>
>
>
>
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop