Re: [Cfrg] Proposal: Threshold cryptography for CFRG curves + UDF

[Phillip Hallam-Baker <[e-mail]>]

I have a different goal. Pedersen's distributed key generation term was
unhelpful. I think we should insist that Key generation is the process by
which one machine establishes one key pair in collaboration with other
machines. The paper is describing key generation for a key to be used as a
threshold key. That is a lot harder.

The use case for combining the key shares comes from the fact that

1) Many IoT devices are unable to generate secure key pairs.
2) Devices have been observed to have been compromised at every stage in
the supply chain: design, fabrication and distribution.

These attacks are real and thus it is entirely appropriate to require a
system that enables an administration device to generate a key for an IoT
device cooperatively.

The objective here is to obtain a situation in which the generated key will
be as secure as the combination of the two key contributions that are used
to create it and to prove to the admin device that the IoT device is using
a key that is not known to the device manufacturer.

The timing attack described in the paper is not relevant because there is
no such disclosure round.


In the circumstances described, that of an IoT device joining a collection,
there is no possibility of a perfect defense against an adversary that has
compromised the state of the IoT device joining that is able to observe the
interactions between the IoT device and the administration device as it
joins. A malicious manufacturer can always simulate the device. But only if
they have that visibility into the communication channel. And note that
since we haven't excluded side channel release schemes, we aren't
attempting to close every possible manufacturer compromise in any case.

If the device has sound random state, transmitting the admin system key
contribution is easy, we can get sufficient protection for the private key
using TLS with forward secrecy alone.

If not, we are going to have to rely on channel security rather than the TLS


What it sounds like is that I should probably write up the device to
collection protocol separate from the Mesh as well. But I think that should
probably remain a separate doc from the on showing the basic scheme.




On Mon, Jan 13, 2020 at 11:19 PM Denis Kolegov <[e-mail]>
wrote:

> Hello Phillip.
>
> I have the following questions:
> 1) Why do not use a distributed key generation approach like that
> https://link.springer.com/content/pdf/10.1007%2F3-540-48910-X_21.pdf?
> In that case, the "auditability" can be verified by zero-knowledge proof
> protocols and other MPC primitives.
>
> 2) The informal protocol of the Section 3.3.1 states "The administration
> device private key is transmitted to the Device by means of a secure channel".
> Do not you think that can be insecure for some threat models? For example,
> a rogue device can steal the private key. I mean within this approach it is
> necessary to guarantee that the device has not been compromised and can not
> be attacked using KCI.
>
> Thank you.
>
> вт, 14 янв. 2020 г. в 03:47, Phillip Hallam-Baker <[e-mail]>:
>
>> I just saw a practical use case that justifies application of threshold
>> cryptography in (n,t) fashion at the ECDH level rather than using release
>> of a static symmetric key to unlock a private key for use.
>>
>> Consider the case in which a service might be compromised and the private
>> key extracted. We split the private key across multiple servers (e.g. 3)
>> put them in different data centers and we perform each private key
>> operation on all three. The (2,3) quorum allows for fault tolerance when
>> one of the servers fails or is unable to communicate.
>>
>> So at this point it seems best to move the Shamir Secret Sharing scheme
>> into the threshold spec. But I will wait on comment on that before going
>> ahead.
>>
>> On Mon, Jan 6, 2020 at 12:42 AM Phillip Hallam-Baker <
>> [e-mail]> wrote:
>>
>>> All,
>>>
>>> I have just submitted two new drafts:
>>>
>>> https://www.ietf.org/id/draft-hallambaker-threshold-00.html
>>> https://www.ietf.org/id/draft-hallambaker-threshold-sigs-00.html
>>>
>>> I wish to (in due course) propose these as CFRG work items together with
>>> the existing draft:
>>>
>>> https://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html
>>>
>>> (should have a proper HTML version of above soon, stress test on the
>>> tools.)
>>>
>>> These are of course work that is motivated by my work on the
>>> Mathematical Mesh. And since the obvious question for the IESG to ask is
>>> whether CFRG has looked at the crypto, it probably makes sense to begin by
>>> discussing the crypto here.
>>>
>>> But more importantly, the Mesh is merely a vehicle to try to persuade
>>> the field to start using some post 1990s crypto. So it isn't a problem for
>>> me if the outcome is we end up putting threshold decryption into legacy CRM
>>> schemes rather than deploying my new one.
>>>
>>>
>>> The first draft describes the addition of three new capabilities to the
>>> X25519 / X448 / Ed25519 / Ed448 repertoire:
>>>
>>> 1) Threshold Decryption (n, n)
>>> 2) Threshold Key Generation
>>> 3) Side channel disclosure resistance
>>>
>>> The implementation of threshold signature is described in a separate
>>> draft. Two schemes are described for Ed25519/Ed448
>>>
>>> 1) Unanimous threshold i.e. (n, n)
>>> 2) Quorate threshold, i.e. (n, t)
>>>
>>> The third document describes the presentation of certain types of
>>> cryptographic material that it is necessary for people to interact with
>>> under certain circumstances. This began as a very tightly constrained piece
>>> of work to 'do digest fingerprints right'. It has since grown in response
>>> to requests and now has some capabilities that I think really need some
>>> CFRG input:
>>>
>>> 1) Deterministic functions for generating ECDH and RSA keys from a
>>> specified key via a KDF
>>> 2) Shamir secret sharing for escrow of encrypted keying material
>>> 3) Shamir secret sharing for escrow of seed used to generate key pairs
>>>
>>> As previously discussed on the list, the threshold signatures are not
>>> aggregate signatures. They are however compatible with the existing RFC7748
>>> and RFC8032 curves and algorithms and that is my overarching goal. I am
>>> aware of the BLS work but I don't see it as overlapping. There are numerous
>>> references and citations missing including to previous IETF/IRTF proposals.
>>> I am more than willing to share authorship. The key thing is to move the
>>> work ahead.
>>>
>>> Many thanks to all those who have helped on or off the list.. Will be
>>> following up to ask folk who helped me offlist if they want their names
>>> mentioned in the acknowledgements. Also need to chase down the references
>>> to source.
>>>
>>> Security considerations are intentionally left blank as I think it
>>> better to start this only after the scope is understood or things get
>>> missed.
>>>
>>>
>>> Questions:
>>>
>>> 1) Should CFRG look at any/all of this work?
>>>
>>> 2) Is (n,k) quorum Threshold decryption worth adding?
>>>
>>> 3) UDF provides two escrow models at present, do we need to add in
>>> direct escrow of the private keys?
>>>
>>> 4) If threshold signature is worth doing, should there be one threshold
>>> spec for the  RFC7748 and RFC8032 curves or keep these as two?
>>>
>>> 5) I was planning to kill OID UDFs, they were originally added as a way
>>> to allow QR code transmission of private keys and then Michael Richardson
>>> gave me a better idea.
>>>
>>> I understand that UDF might be a little on the 'lite' side and not so
>>> suited to CFRG. But I would like people to take a look at the deterministic
>>> key gen because it solves a very important problem a lot of sysadmins face
>>> today: how to keep SSH keys in sync across machines. Some of the
>>> instructions given on the net on how to do this are pitiful.
>>>
>>> This technique is not as simple or easy to use as the Mesh of course,
>>> but it does support 'offline' and 'paper' pretty well.
>>>
>>> _______________________________________________
>> Cfrg mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/cfrg
>>
>
>
> --
> Sincerely,
> Denis Kolegov
> @dnkolegov
>