A few years ago, a customer handed us a report from a Big 4 consulting firm describing how, after close to 100 person-hours of review, a team of ‘highly-qualified senior security engineers’ had failed to find any flaw in their encrypted communications product. Half a day later, I had worked out how to break the product’s encryption, and demonstrated a working exploit. The customer was confused—why hadn’t the well-dressed consultants caught the vulnerability?
One possible reason is that such firms will often present as ‘senior engineers’ or even ‘experts’, junior hires whose only expertise is a night browsing about the subject matter. For an hourly rate of $250. But that’s another story.
The reason it took me half a day to discover the flaw is principally to do with skillsets. Crypto requires specific skills. Like a good general surgeon won’t necessarily be a good heart surgeon, a good all-around security engineer won’t necessarily be the right person to review cryptography products.
Why Crypto Is Hard
To be honest, I don’t think that crypto is intrinsically harder than other domains of information security. I find crypto much simpler than, say, browser security. But crypto is viewed as hard because it requires totally different skills, especially mathematics, and because it involves security notions that aren’t used elsewhere. A security engineer can have years of experience in web security, application security, and network security, yet have little exposure to concepts such as forward secrecy or indistinguishability.
Of course, bugs in cryptographic software can be the same kind bugs as is any piece of software, bugs such as buffer overflows or use-after-frees (think Heartbleed). Finding logic bugs, however, often requires an understanding of the crypto protocols and their subtleties. Even harder is cryptanalysis, the task of studying properties of cryptographic designs and implementations. Doing cryptanalysis for a general security engineer is like asking a cryptographer to reverse engineer an obfuscated binary program. If you don’t have thousands of hours of experience, you won’t find the subtlest vulnerabilities (such as these), and it will take you days to do what an experienced person would do in hours.
An additional risk with crypto is that of side channels, or the leak of information about secret material from the program’s behavior. This class of bugs includes for example timing leaks, which occur when the execution time of a program reveals information on the cryptographic keys. A common side-channel attack in software applications is the padding oracle attack (alas, not yet eradicated).
The bottom line is that reviewing crypto is much more than checking what algorithms are used, as I’ve previously blogged about.
What To Do About It
To review the crypto in your crypto product, hire cryptography experts who are used to doing this kind of job. Purely academic researchers may help for the more theoretical analysis, but are rarely familiar with practical considerations.
You’ll find such crypto experts either in large security companies, or in smaller shops specialized in crypto reviews. It can be hard to identify the qualified teams though. A sign of ability is the publication of vulnerabilities or presentation of their research at conferences. Note that the absence of evidence is not evidence of absence; some companies choose not to publish anything.
Another approach, especially if part of your code is open-source, is to organize a bug bounty and offer a reward to discoverers of vulnerabilities including crypto vulnerabilities.
In any case, to prevent failures in your crypto product, follow the usual advice: refrain from creating your own protocol or algorithm and rely on time-tested software components.
And beware marketing. All that glitters is not gold, and with a view to getting a generous slice of an increasingly lucrative market, security companies are keen to package up their infosec-related skills as crypto-specific ones. Dig beneath slick marketing to find out if there is substance to the claims or, as Nomx experienced earlier this year, you could well end up with a Pi(e) on your face.
About the Author: Dennis Nuijens
