Re: [Acme] Signature misuse vulnerability in draft-barnes-acme-04

[Andrew Ayer <[e-mail]>]

On Tue, 11 Aug 2015 22:52:05 -0700
Richard Barnes <[e-mail]> wrote:

> I'm not 100% sure I agree that there are non-trivial cases where RSA
> allows one to find a key that will verify a given (message, signature)
> pair.  (I would note, however, that you don't even need to find the
> modular inverse d of e -- you just need n and e such that s^e == m mod
> n.)  It's even less clear for ECDSA.  I'm not sure we even need to get
> a clear answer to that question, though.  There are protocol ways to
> hack around it, as you suggest.

Thanks to Trevor Perrin, I now know that this attack is called
"duplicate-signature key selection," and found a paper which presents
a general way to construct a non-trivial RSA key (pages 4-5):

http://eprint.iacr.org/2011/343

It also presents an attack with ECDSA, though it depends on the
attacker picking their own base point, and I believe that the
commonly-used curves (P-256, P-384, and so on) specify a fixed base
point.

> I think you're on the right track that we really should just not use
> signatures here.  I had added those in response to concerns about a
> CDNs in front of the ACME server, but in retrospect, they're solving
> the wrong problem.  The risk posed by a CDN is that it swaps the keys
> out, much like this situation.  So it's enough for the statement by
> the domain owner (i.e., the validation object) to include an
> indication of which account key he intends to authorize.
> 
> This actually adds some symmetry to the challenges.  I had thought
> that proofOfPossession seemed like the odd one out, since the account
> key was being signed instead of doing the signing.  Your observation
> that the domain holder needs to assert the key basically says that the
> other challenges should follow the proofOfPossession model and have
> the domian owner make a statement about the account key.  It's just
> that in the other cases, the authenticity of the statement won't be
> shown with a signature, but with its being provisioned in a particular
> place.

Exactly.

> We will probably want to bind some more stuff into the validation
> object besides the public key, though, in order to bound replay
> opportunities.  At the very least, there needs to be a token that the
> CA can use to associate the validation object with things like which
> identifier is being authorized, and what type of challenge it goes
> with (to prevent replay for different domains, or in different
> channels).

I may be overlooking something, but I'm skeptical of the value of
including extra information.  If an attacker can replay a validation
object for another domain or in the context of a different challenge,
that means the attacker effectively controls that domain/validation
channel, and can just contact the ACME server, start a new challenge,
and complete it "normally" without any need for replays.

> In light of the above, ISTM that the right tactical move is probably
> to define a standard validation object that many challenges can use.
> Then the proofOfPossession challenge can sign the validation object,
> and the "put it here" challenges can provision a digest of the
> validation object.

That seems like a great way to simplify the protocol.  On the other
hand, Jacob's /.well-known/certificate/acme-account-keys.json idea is
also quite nice.

Regards,
Andrew