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

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