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 <sw...@cs.berkeley.edu>
* @author Mike StJohns
* @see "Practical Threshold Signatures,
* Victor Shoup (s...@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
<hsalg...@nic.cl <mailto:hsalg...@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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
