On Wed, Aug 12, 2015 at 4:04 PM, Andrew Ayer <[email protected]> wrote: > On Tue, 11 Aug 2015 22:52:05 -0700 > Richard Barnes <[email protected]> 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.
Nice find! (Thanks, Trevor!) I would note, though that in practice, e=65537 pretty much always, and the attack would almost never produce that value. So this could still be prevented by checks on account public keys. Still doesn't change the conclusion, though :) --Richard > >> 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 _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
