03 February 2009

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.

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.]

Comments

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.

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.]

About the (ISC)² Blog

As the certifying body for more than 125,000 cyber, information, software and infrastructure security professionals worldwide, (ISC)² believes in the importance of open dialogue and collaboration. (ISC)² established this blog to provide a voice to certified members, who have significant knowledge and valuable insights that can benefit other security professionals and the public at large.

The (ISC)² blog gives members a forum to exchange ideas and inspires a safe and secure cyber world by supporting the advancement of the information security workforce via a public exchange with a broad range of information security topics.

Whether an (ISC)² member chooses to participate in the (ISC)² blog is his or her own decision. The postings on this site are the author's own and don't necessarily represent (ISC)²'s positions, strategies or opinions. (ISC)² monitors the blog in accordance with the (ISC)² Blog Guidelines, but the bloggers are responsible for their own content – common sense and intelligence should prevail.

Other than links to the (ISC)² website, (ISC)² does not control or endorse any links to products or services provided in this blog and makes no warranty regarding the content on any other linked website.

Those who post comments to (ISC)² blogs should ensure their comments are focused on relevant topics that relate to the specific blog being discussed. (ISC)² reserves the right to remove any post or comment from this site. Should you find objectionable content in this blog, please notify us as soon as possible at blog@isc2.org