Re: [blink-dev] Re: MD5 -- Re: (Pre-)Intent to Deprecate: <keygen> element and application/x-x509-*-cert MIME handling

I would concentrate the debate on what I think is the core, namely that client-certificate
authentication in browsers may be gone in a not so distant future.  By Google MAYBE killing
keygen (Microsoft HAVE already killed their version of it), the bar will be substantially
raised for using client-certificates.

I totally agree on the MD5 issue.  The only attack you can succeed with is getting
a certificate for a public key which you may not have a private key to which isn't
a security problem but a nuisance.

Anders


On 2015-09-07 11:20, henry.story@gmail.com wrote:
>
>
> On Sunday, 6 September 2015 09:57:44 UTC+2, henry...@gmail.com wrote:
>
>
>
>     On Friday, 4 September 2015 20:33:47 UTC+2, Ryan Sleevi wrote:
>
>
>
>         On Fri, Sep 4, 2015 at 11:28 AM, Melvin Carvalho <melvinc...@gmail.com> wrote:
>
>             Please could you state what you believe the attack vector relating to MD5's use in SPKAC and/or KEYGEN is.  You brought this up, so it is reasonable to ask what you think it is.  Subsequent discussion has shown no attack vector that compromises either identity or key material.  If there is, please elaborate, or if not, let's agree that KEYGEN is not insecure.
>
>
>         Are you arguing that MD5 is secure because you don't understand how it's not secure?
>
>
>     MD5 is a message digest algorithm. Wether it is secure depends on what it is used for. For example if I create an MD5 of a file on my file system as a way to explain the command line tool md5, this presents no security threat
>
>     $ md5 ~/rfc-6592.txt
>
>     MD5 (/Users/hjs/rfc-6592.txt) = 1e001b0a4d2913233714772624d91f29
>
>
>     I can create md5s of any string I want. For some reason the <keygen> authors added an md5 to the key request format sent to the server. But that server does nothing with that MD5 string. All that interests the server is the public key that comes in the spkac packet.
>
>
>     So there was a security problem when Certificate Authorities used MD5 to sign certificates.
>
>     But since in the actual usage of <keygen> the MD5 is not at all used, well there is and can be no security hole.
>
>
>     It's a bit of a joke, a bit like the Null Packet RFC 6592 .
>
>
> Ok, the above is way too terse and misleading. So let me try again.
>
> The spkac clearly signs the generated public key + challenge with the private key using the MD5 signature [1]. The server is then meant to verify the signature and that it matches the challenge, as a way of verifying that the agent that sent the public key is actually the agent connected in the session. I suppose this is to avoid the server signing certificates for clients presenting random public keys. Of course the client would not be able to do anything with the generated certificate, given we assume that it does not have the private key. So this signature and challenge can be seen as an extra security feature.
>
> (So I admit that I have not been using this verification in my code - which has not been required for anything at this high level of security, but it will be nice to be able to add it.)
>
> This assumes that between the creation of the form and the challenge ( which should of course contain a very random string as possible, include a date and be tied to the user session - perhaps even the TLS session) , and the receipt of the form and the public key someone would be able to find a public key for which they did not have the private key, find an MD5 hash collision for that given challenge, and send that to the certificate service. Let's stop here for a second.
>
> Let us note the complexity of the attack:
>
> 1) for the MD5 break example 7 years ago demonstrated by Jacob Appelbaum, they had to spend 3 days to create the challenge (ok computers are faster now of course )
> 2) there is a lot more information in a X509 cert than in an spkac so that MD5 clashes are presumably much more difficult to generate in spkac
> 3) plus they were dealing with a certificate authority that would create server certificates with identity numbers that were sequential, so completely predictable ( hence the answer that by  randomising the string this would be difficult to duplicate )
>
> All the above is very very hard.
>
> Let us now think of the result of this attack:
>
> The attackers would end up receiving an X509 certificate signed with SHA2, which is recommended now I am told.
> But they would not have a private key for the given public key ( for if they did have the private key, none of the above attack
> would of course be necessary ).
>
> This is the opposite of the attack demonstrated by Applebaum, where the whole game was to start off with a public key for which they had the private key, in order then to get the CA to generate a certificate signed with MD5, and then be able to generate another certificate with the same signature that put them in control of a root certificate!
>
> Here the attacker ends up with a secure certificate which he cannot break as it uses SHA2 and for which he does not have
> the private key!
>
> And apart from that it is really quite unbelievable that it is hard to improve the keygen tag to add an option to make it SHA2 enabled without allowing for backward compatibility!
>
> Henry
>
> [1] As one can see from the bouncy castle API http://www.bouncycastle.org/docs/docs1.5on/org/bouncycastle/jce/netscape/NetscapeCertRequest.html

Received on Monday, 7 September 2015 09:32:25 UTC