Re: [Lurk] Notes on preventing signing oracles

Hi,

It seems the presented mechanism can be used to mitigate the signing oracle
issue. Unless someone opposes this I am encline to consider that the
signing oracle issue is closed.

BR,
Daniel

On Wed, Oct 12, 2016 at 11:00 AM, Daniel Migault <
daniel.migault@ericsson.com> wrote:

> Hi,
>
>
>
> If I understand correctly, to prevent a generic signing oracle, some
> mechanisms or operations should be defined so the signed public key can be
> believed to be part of legitimate ECDHE exchange instead of some random
> data. This includes checking the public key belongs to the curve or proving
> that the Edge Server owns the corresponding private key associate to that
> curve.
>
>
>
> In order, for the Edge Server, to prove the ownership of the corresponding
> private key, I propose the following mechanism. Please let me know if you
> agree with that mechanism as well as if you believe the generic signing
> oracle has been sufficiently addressed.
>
>
>
> Upon the request the server computes:
>
> a)       r a randomly generated number the Edge Server can chose
>
> b)      c a randomly generated number the Edge Server cannot chose. **
>
> Let
>
> t = cb + r
>
> and
>
> bG the public key to be signed.
>
>
>
> The Edge Server sends to the Key Server:
>
> rG, tG, c,  bG
>
>
>
> The Key Server checks: c(bG) + rG = tG
>
>
>
> ** Ideally, the number could be provided by the Key Server for each
> request. However, we can probably find some reasonable alternatives where
> the number is generated by the Edge Server while being reasonably out of
> control from the Edge Server. For example we could use the resulting hash
> of a combination of a shared secret between the Edge Server and the Key
> Server,  associated to a sequence number address. There are probably other
> maybe better ways to do and feel free to propose alternatives.
>
>
>
>
>
> BR,
>
> Daniel
>
> *From:* Lurk [mailto:lurk-bounces@ietf.org] *On Behalf Of *Kyle Rose
> *Sent:* Monday, July 18, 2016 11:23 AM
> *To:* Eric Rescorla <ekr@rtfm.com>
> *Cc:* LURK BoF <lurk@ietf.org>
> *Subject:* Re: [Lurk] Notes on preventing signing oracles
>
>
>
> It's possible we can't do much to prevent creating a generic signing
> oracle for TLS 1.2, but for 1.3 we can send precursors to the key owner and
> require it to reproduce the final input to the signature algorithm,
> constraining the adversary to signatures of messages of the form
> (0x20){32}("TLS 1.3, (server|client) CertificateVerify")(0x00)(.){64} for
> SHA-256.
>
> We could potentially backtrack even further, sending inputs to each of the
> hashes and requiring the key owner to do additional verification, at the
> risk of exposing some data to the key owner that we might not want to.
>
> Is this worth the added complexity and duplicated effort (by both the
> server and the key owner)? Regardless of best-practice, since it's at least
> somewhat likely that a particular signing key will be used in more than
> context, this might prevent some future class of cross-protocol attacks.
>
> Kyle
>
>
>
> On Mon, Jul 18, 2016 at 9:22 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> The current charter proposal says:
>
>
>
>   A Standards Track document that defines the interface between an edge
>
>   server and a content owner. Security is a key concern, specifically
>
>   avoiding a "signing oracle" where possible.
>
>
>
> This text is a bit unclear, but I presume that the intent is to avoid
>
> allowing the Server to use the KeyOwner as a signing oracle. This
>
> message attempts to explore how hard this is.
>
>
>
>
>
> As I think is well known, TLS 1.2 servers inherently allow clients to
>
> obtain a signature with the server key on a message with a 32-byte
>
> prefix chosen by the client [0]. In a LURK context, if one adopts the
>
> naive design where the Server supplies the ServerKeyExchange to the
>
> KeyOwner, the Server can obtain a signature by the KeyOwner on a
>
> string which consists of:
>
>
>
> - 32 bytes of ClientRandom (which can be chosen by the Server)
>
> - 32 bytes of ServerRandom (which in the worst-case for the attacker
>
>   is selected by the KeyOwner)
>
> - The serialization of the ServerKeyExchange message which ostensibly
>
>   consists of [1]:
>
>   - The server's ECDHE share
>
>   - The server's FFDHE group + share
>
>
>
> It should be clear that if we just allow the Server to supply an
>
> unverified key/share that that's a very powerful signing oracle, but
>
> there are also limits to how much the KeyOwner can validate the share:
>
>
>
> - If it's ECDHE (NIST curves) then it can validate that the ostensible
>
>   point is on the curve. This allows the Server to generate a pretty
>
>   random x-coord value but then y-coord has to match (assuming we
>
>   require uncompressed points).
>
>
>
> - If it's ECDHE (CFRG curves), then the Server can basically generate
>
>   an arbitrary 32 or 48-byte string
>
>
>
> - If it's FFDHE, then the Server gets to control a huge amount of data
>
>   if you allow custom groups, but one could require that Servers use
>
>   the defined FFDHE groups, in which case, the Server just gets to
>
>   specify Y as a random value.
>
>
>
> Maybe one could do a bit better than this with some more thought, but
>
> I suspect that ultimately really preventing a signing oracle requires
>
> preventing the Server from arbitrarily choosing the "public" part of
>
> the DH share, e.g., by requiring the Server prove it knows the private
>
> part) Absent this, I'm not sure how much security value this actually
>
> provides over no validation (the CFRG curve case seems especially
>
> bad).
>
>
>
> -Ekr
>
>
>
>
>
> [0] https://tlswg.github.io/tls13-spec/#rfc.section.4.3.2
>
> [1] I'm ignoring the length bytes for the purposes of this discussion.
>
>
>
>
> _______________________________________________
> Lurk mailing list
> Lurk@ietf.org
> https://www.ietf.org/mailman/listinfo/lurk
>
>
>
> _______________________________________________
> Lurk mailing list
> Lurk@ietf.org
> https://www.ietf.org/mailman/listinfo/lurk
>
>