Today we saw two big topics being addressed. The first topic was a collection of issues related to electronic payment systems (talks by Kim Wagner and Gaven Watson) and - more general - Authenticated Encryption (talk by Phil Rogaway) and the second topic was about coping with things going wrong (talks by Marc Stevens, Adam Langley and Eric Rescorla). In the following I'm going to focus on the issue of coping with things going wrong.
Both Adam Langley and Eric Rescorla were talking about known security issues within TLS/SSL protocols where fixes are available but with a mixed-to-poor deployment history of those fixes. Eric Rescorla, based on his experience with TLS/SSL pointed out that fixes have a far better chance to achieve high deployment rates fast if they are either
Adam Langley took a slightly different tack by pointing out the differences in quality of existing code for cryptographic primitives and urged every cryptographer who presents a new primitive to present it together with a carefully coded (i.e. secure) implementation as this will raise awareness of implementation issues (esp. constant time behaviour) for the designers themselves while significantly reducing the probability that less knowledgeable (with respect to security) implementers create a swamp of vulnerable implementations. Also he presented his "Crypto room 101" of primitives that he didn't want to see in future protocols due to their vulnerability prone implementation: CBC mode, primitives that suffer a "sudden death" in case of entropy failures, DSA,pseudo mersenne primes generalized mersenne primes and AES-GCM.
Adam also stressed the importance of work-arounds¹ for security issues; one fairly novel and impressive workaround was presented by Marc Stevens: Counter-cryptanalysis of the collision attack used by the Flame malware that was discovered in 2012. Using the example of an MD5 based certificate where we know that MD5 is vulnerable the idea of counter-cryptanalysis is to check whether this certificate could have been created by crypt-analytic methods instead of the legitimate signing process.
This is exactly what was done for the Flame malware; Flame did not contain any significant new part except that it is the first known malware to rely on a cryptanalytic attack. A collision attack on MD5 - which is still present as legacy hash function within the PKI infrastructure used by Microsoft (and almost everyone else) - was used to forge a certificate that enabled Flame to insert itself into the Windows security update mechanism. While early examination of Flame already suggested that the certificate might be a forgery, this was only proven using counter-cryptanalysis. In addition, it was possible to show that the creators of flame must have used an unpublished method to construct the MD5 collision, suggesting significant cryptographic skills being involved in the creation of Flame. While this forensic use of counter-cryptanalysis happens offline, Marc also sketched ongoing work to use counter-cryptanalysis to detect attacks online, i.e. while they are happening, so that they can be blocked before systems get compromised.
¹) Eric's stance on work-arounds was more ambiguous as he noted that work-arounds reduce the pressure to fix security issues properly without achieving the same confidence as a proper fix would.
Both Adam Langley and Eric Rescorla were talking about known security issues within TLS/SSL protocols where fixes are available but with a mixed-to-poor deployment history of those fixes. Eric Rescorla, based on his experience with TLS/SSL pointed out that fixes have a far better chance to achieve high deployment rates fast if they are either
- anticipated, provide strong incentives to those who need to deploy them and enjoy strong support from major governments as it was the case with the switch from DES to AES
- or if they need to be supported on one side (of a browser - server communication) only, i.e. if they can be applied unilaterally without "breaking the internet".
Adam Langley took a slightly different tack by pointing out the differences in quality of existing code for cryptographic primitives and urged every cryptographer who presents a new primitive to present it together with a carefully coded (i.e. secure) implementation as this will raise awareness of implementation issues (esp. constant time behaviour) for the designers themselves while significantly reducing the probability that less knowledgeable (with respect to security) implementers create a swamp of vulnerable implementations. Also he presented his "Crypto room 101" of primitives that he didn't want to see in future protocols due to their vulnerability prone implementation: CBC mode, primitives that suffer a "sudden death" in case of entropy failures, DSA,
Adam also stressed the importance of work-arounds¹ for security issues; one fairly novel and impressive workaround was presented by Marc Stevens: Counter-cryptanalysis of the collision attack used by the Flame malware that was discovered in 2012. Using the example of an MD5 based certificate where we know that MD5 is vulnerable the idea of counter-cryptanalysis is to check whether this certificate could have been created by crypt-analytic methods instead of the legitimate signing process.
This is exactly what was done for the Flame malware; Flame did not contain any significant new part except that it is the first known malware to rely on a cryptanalytic attack. A collision attack on MD5 - which is still present as legacy hash function within the PKI infrastructure used by Microsoft (and almost everyone else) - was used to forge a certificate that enabled Flame to insert itself into the Windows security update mechanism. While early examination of Flame already suggested that the certificate might be a forgery, this was only proven using counter-cryptanalysis. In addition, it was possible to show that the creators of flame must have used an unpublished method to construct the MD5 collision, suggesting significant cryptographic skills being involved in the creation of Flame. While this forensic use of counter-cryptanalysis happens offline, Marc also sketched ongoing work to use counter-cryptanalysis to detect attacks online, i.e. while they are happening, so that they can be blocked before systems get compromised.
¹) Eric's stance on work-arounds was more ambiguous as he noted that work-arounds reduce the pressure to fix security issues properly without achieving the same confidence as a proper fix would.
No comments:
Post a Comment