|
|
02-04-2009
Registered User
26,240,
27
The crypto hamster wheel
A recent public demonstration by a team of researchers from the Netherlands, Switzerland and California in which they successfully created fake digital certificates provides an interesting case study in lifecyle management for cryptography. The team exploited technical and procedural vulnerabilities in some public Certificate Authorities (CAs) to obtain fake SSL certificates that would be trusted by most web browsers. There are serious implications for the financial services industry, users of VPNs and others.
Others have published more frivolous but equally worrying demonstrations of deliberately crafted MD5 hash collisions.
Key to the SSL certificate exploit was a technical weakness in the MD5 cryptographic hashing algorithm used by some CAs to sign their digital certificate products. Due to the flaw, it is possible to generate hash collisions on demand. This has been known for at least five years and hence MD5 has been deprecated - that is, it is no longer recommended and users have been encouraged to migrate to a different algorithm, especially in situations where integrity is highly important (such as, ah, oh, digital certificates!). It is evident, however, that MD5 remains in use. As well as being used by some CAs, MD5 "checksums" are still frequently used to authenticate and spot unauthorized changes to program files, for instance.
This is not an uncommon situation in cryptography. As the mathematical science behind cryptography and cryptanalysis advance inexorably, so weaknesses are discovered in the crypto algorithms. Typically, the first signs of trouble arise when some bright sparks publish scientific papers explaining purely theoretical mechanisms that would make it slightly quicker/easier to find encryption keys by brute force attacks, craft plaintext to expose an exploitable flaw in the cryptographic algorithm (a chosen plaintext attack) or to exploit procedural weaknesses in the cryptographic protocols and/or associated processes such as key exchange. Next, others in the field often develop and extend the flaws, sometimes finding related flaws and cryptanalytical techniques, gradually spinning-off working "demonstrations" to prove that the weaknesses can indeed be exploited. When black hat hackers take up the challenge, working exploit code often circulates in the wild and is eventually added to Metasploit. By that stage, woe betide anyone still depending on the broken technology for anything (wake up those of you still using WEP and WPA!).
Such inherent weaknesses in the cryptography are conceptually different from commonplace implementation flaws, such as using inadequate randomness for seed values, excessive re-use of keys or plaintext, or restricting the key space through crude human-memorable-password-to-crypto-key functions. The latter only affect specific implementations/uses of the cryptography, whereas the former affect all implementations of the broken algorithms. While implementation flaws may be important for widespread crypto subsystems such as encryption functions embedded in mainstream operating systems and application software, the vendors tend (eventually!) to fix the flaws through patches or by replacing the crypto subsystems with entirely new generations (leaving remaining first generation users with a legacy problem). Judging by the exploits in the wild, implementation flaws appear to be somewhat easier to exploit than inherent flaws in the cryptographic functions themselves, presumably because the algorithms are developed and tested more thoroughly and scientifically for security than the implementations.
Anyway, back to the plot. MD5 users have been recommended to migrate to algorithms such as NIST's SHA-1 and the SHA-2 family (although weaknesses in SHA-1 are also known). MD5 users should therefore already have migration strategies and processes in place to make the move to stronger hashing algorithms, and more generally all cryptography users should have strategies and processes to keep up with the flow of theoretical and practically demonstrated flaws in the algorithms and protocols on which they depend.
I'm deliberately using the term "users" quite loosely here: vendors selling and suporting crypto-based products should quite obviously be running hard around the hamster wheel of crypto upgrades. So too should their customers who depend heavily on crypto functions. In the specific case of fake SSL certificates, customers of the CAs that still issue MD5-based certificates should be pushing hard for the CAs to upgrade to more trustworthy alternative algorithms and, meanwhile, to at least alter their procedures for numbering certificates to inject some randomness into the digital signatures since it doesn't take much grey matter to figure out the next in a sequence of sequential numbers! In fact they might be advised to seek new suppliers who have the strategies and processes in place to monitor and keep up with advances in cryptography routinely. Finally, while it is not practicable for all of us to become crypto-experts, end-users like me should be wary of trusting security technologies, no matter how optimistically they are described by the suppliers' marketing people. [I always cringe when I see advertisements stating or strongly implying perfect security. Such claims are surprisingly common, particularly in relation to One Time Pads (OTP) where vendors naively emphasise the theoretical strength of OTP but gloss over the practical constraints that inevitably weaken real-world OTP implementations.]
More...
Others have published more frivolous but equally worrying demonstrations of deliberately crafted MD5 hash collisions.
Key to the SSL certificate exploit was a technical weakness in the MD5 cryptographic hashing algorithm used by some CAs to sign their digital certificate products. Due to the flaw, it is possible to generate hash collisions on demand. This has been known for at least five years and hence MD5 has been deprecated - that is, it is no longer recommended and users have been encouraged to migrate to a different algorithm, especially in situations where integrity is highly important (such as, ah, oh, digital certificates!). It is evident, however, that MD5 remains in use. As well as being used by some CAs, MD5 "checksums" are still frequently used to authenticate and spot unauthorized changes to program files, for instance.
This is not an uncommon situation in cryptography. As the mathematical science behind cryptography and cryptanalysis advance inexorably, so weaknesses are discovered in the crypto algorithms. Typically, the first signs of trouble arise when some bright sparks publish scientific papers explaining purely theoretical mechanisms that would make it slightly quicker/easier to find encryption keys by brute force attacks, craft plaintext to expose an exploitable flaw in the cryptographic algorithm (a chosen plaintext attack) or to exploit procedural weaknesses in the cryptographic protocols and/or associated processes such as key exchange. Next, others in the field often develop and extend the flaws, sometimes finding related flaws and cryptanalytical techniques, gradually spinning-off working "demonstrations" to prove that the weaknesses can indeed be exploited. When black hat hackers take up the challenge, working exploit code often circulates in the wild and is eventually added to Metasploit. By that stage, woe betide anyone still depending on the broken technology for anything (wake up those of you still using WEP and WPA!).
Such inherent weaknesses in the cryptography are conceptually different from commonplace implementation flaws, such as using inadequate randomness for seed values, excessive re-use of keys or plaintext, or restricting the key space through crude human-memorable-password-to-crypto-key functions. The latter only affect specific implementations/uses of the cryptography, whereas the former affect all implementations of the broken algorithms. While implementation flaws may be important for widespread crypto subsystems such as encryption functions embedded in mainstream operating systems and application software, the vendors tend (eventually!) to fix the flaws through patches or by replacing the crypto subsystems with entirely new generations (leaving remaining first generation users with a legacy problem). Judging by the exploits in the wild, implementation flaws appear to be somewhat easier to exploit than inherent flaws in the cryptographic functions themselves, presumably because the algorithms are developed and tested more thoroughly and scientifically for security than the implementations.
Anyway, back to the plot. MD5 users have been recommended to migrate to algorithms such as NIST's SHA-1 and the SHA-2 family (although weaknesses in SHA-1 are also known). MD5 users should therefore already have migration strategies and processes in place to make the move to stronger hashing algorithms, and more generally all cryptography users should have strategies and processes to keep up with the flow of theoretical and practically demonstrated flaws in the algorithms and protocols on which they depend.
I'm deliberately using the term "users" quite loosely here: vendors selling and suporting crypto-based products should quite obviously be running hard around the hamster wheel of crypto upgrades. So too should their customers who depend heavily on crypto functions. In the specific case of fake SSL certificates, customers of the CAs that still issue MD5-based certificates should be pushing hard for the CAs to upgrade to more trustworthy alternative algorithms and, meanwhile, to at least alter their procedures for numbering certificates to inject some randomness into the digital signatures since it doesn't take much grey matter to figure out the next in a sequence of sequential numbers! In fact they might be advised to seek new suppliers who have the strategies and processes in place to monitor and keep up with advances in cryptography routinely. Finally, while it is not practicable for all of us to become crypto-experts, end-users like me should be wary of trusting security technologies, no matter how optimistically they are described by the suppliers' marketing people. [I always cringe when I see advertisements stating or strongly implying perfect security. Such claims are surprisingly common, particularly in relation to One Time Pads (OTP) where vendors naively emphasise the theoretical strength of OTP but gloss over the practical constraints that inevitably weaken real-world OTP implementations.]
More...