The majority of current cryptographic algorithms are based on problems that are easy to compute but hard to reverse. Like multiplying numbers or exponentiation – figuring out what primes went into a product or which log gives you an integer solution back. Now that’s hard math. This is especially true when done with significantly large numbers. After all, factoring the primes in 36 is not that challenging.
When implementing a cryptographic algorithm to protect sensitive information, we expect the numbers used to be big enough and therefore too complex and too difficult for an adversary to crack. Following this logic, accepting numbers that are ‘0’ (zero) should be outright taboo. Yet, that’s what Java 15, and versions up, just gave us. The flaw found lets a pass in a certificate with all zeroes, and the Elliptic Curve Digital Signature (ECDS) algorithm in Java 15+ just accepts…. ouch. This means authentication is entirely broken. Any entity can authenticate as anyone they’d like to impersonate. A very serious “oops” but indicative of the daily snafus and oversights that happen in cryptography and cryptographic implementations on a daily basis.
This is not the first major bug we’ve seen this year. We also learned that up to 100M+ smartphones made by Samsung are at risk of compromise of their “TrustZone” — the most secure part of the phone — because a developer failed to pass in a random number in the entropy that is required for the crypto algorithm, instead passing a zero. Point is programmers make mistakes all the time in cryptography. And these bugs are hard to catch, because there’s no fault in the intended behavior. The code works as intended. We just cannot trivially see in which ways it is broken.
We often speak of algorithmic weaknesses, and the potential of powerful new computing technologies to break current cryptography, but in reality these methods — although serious — are not the common case. Programmer error is the #1 reason crypto can be broken, and often trivial mistakes are to blame.Traditionally the computing world has accepted that there’s bugs in code, and that security defenses are not perfect. So a defense-in-depth approach is generally advised, where filtering and access control are applied at every level. Add to this approach a doctrine of “least privileged access” we should be good.
Except if every level of the defense-in-depth approach relies on the same cryptographic and authentication approaches then we have a monoculture. Monocultures are susceptible to singular attack vectors. Think about how the entire human population is susceptible to the common cold. Defense-in-depth is necessary, but not sufficient. Proper security defenses must be diversified at every layer.
An approach of diversification, in crypto and otherwise, only works if the approach is additive, layering multiple security strategies on top of each other. In the crypto world this is using both symmetric and asymmetric cryptographic algorithms, while also bringing key exchange out-of- band and preferably using a two-factor authentication system. Seasoned security architects should always have a keen eye for spotting single failure points throughout all their chosen defenses. Only then can we confidently accept the reality that no computer system by itself is perfectly secure.
