MD 5 Hashing

An explanation of hashing and the recent exploit Michael Swartz Tilson Technology Management mswartz@tilsontech.com

Message Digest 5
Text that is represented by a string of digits created by applying a one-way hash function to the original text If using encryption, which requires a key to en- and decrypt, this is called a digital signature
There is confusing terminology on the internet. The paper published in December of 2008 also refers to hashing as a 'digital signature'

Both are means of authentication

Hashing vsEncryption
Hashing is one-way. There is no 'dehashing'
A 'secret' is hashed and stored for later comparison When an agent sends a secret to the system containing the hash algorithm, a hashed value is created from that secret.
The resulting hash value is compared to the stored hash value The original secret is not compared and, hopefully, not stored Ideally, the hashed value of a secret will be unique to that secret and algorithm (further discussion)

Encryption is two way, and requires a key

Applications
Applications Hashing stored secrets
Passwords

File Checksums
Create a Unique value for a particular file to verify

SSL Certificates
Compare hash value of a certificate against a trusted source. Verifies the validity of a web site

Vulnerabilities in MD 5
Vulnerabilities Collision is caused by creating the same hash value from two or more different inputs
Hash for password 'foo' can be the same as the hash for password 'bar'

Since systems check the hash value, a collision can lead to a compromise

Vulnerabilities (continued)
Certificates using MD5 are subject to collisions as well Sites using these certificates generally do so to provide the user with assurance that the site they are visiting is verified by the issuing Certificate Authority (CA) Such cases vulnerable to this collision exploit

Vulnerabilities (continued)
Enables a 'rogue' certificate to be created. This rogue certificate can impersonate a certificate issued by a legitimate, or 'root' CA such as VeriSign. Root CAs are, by default, trusted Web browsers that trust the root CA will accept a certificate issued by a rogue CA, thereby accepting the identity of any site spoofed as such

Vulnerabilities (The official explanation)

Vulnerabilities (The official explanation)

1a A legitimate website certificate is obtained from a commercial CA (the blue one in the diagram). 1b A rogue CA certificate is constructed (the black one in the diagram). It bears exactly the same signature as the website certificate. Thus it appears as being issued by the CA, whereas in fact the CA has never even seen it. 2 Then a website certificate (the red one in the diagram) bearing the genuine website's identity but another public key is created and signed by the rogue CA. A copy of the genuine website is built, put on another web server, and equipped with the rogue website certificate. 3 When a user wants to visit the secure website, the web browser will look on the Internet for the genuine web server

Addressing the Risk

Exploits are now widely published Most CAs are reissuing MD5 certificates using a different algorithm (SHA, for example)
SHA-1 is, in theory, vulnerable to the same exploit. No practical application has been provided, but it is likely a matter of time Where MD5 certificates may not be easily replaced, some CAs have taken to randomizing the serial numbers of certificates they issue. This is a stop-gap, and not a solution to the inherent weakness SHA-2 is becoming more widely accepted

Further Reading
http://www.win.tue.nl/hashclash/rogue-ca/ http://www.cryptography.com/cnews/hash.html http://ajaxian.com/archives/md5-hashcollision