If there's one security life lesson to learn that too many companies make, it is: "don't mess with the crypto".
BlackBerry announced its new phone, the DTEK50, calling it the "world's most secure Android smartphone". It's the company's second attempt at a "secure" smartphone, following its debut Android-based Priv phone from last year that promised "ultimate privacy".
But alarm bells went off when the company hinted it modified the cryptography on the device. In a press release, the company said it had hardened Android, heralding how it "improved [the] random number... generation" to make it "more difficult for attackers to target a device".
It's enough to make any seasoned cryptographer twitch.
Modifying the operating system, software, and components that encryption relies on opens the possibility of attackers exploiting flaws in the implementation. In the case of the random number generator, you'll want to know there's no way to be able to predict a sequence of numbers. If you can predict a sequence, that's a backdoor an attacker can use to decrypt data.
But the company didn't detail how it "improved" the random number generation. One wrong move, and you have a so-called "secure smartphone" with flawed encryption that could let an attacker in.
We asked a number of security experts and cryptographers what the deal was, and here's what we found out.
When asked, a BlackBerry spokesperson said the company uses "the standard Linux RNG with hardware improvements from Qualcomm to add entropy".
That's good news on one part, as the standard Linux RNG is tried and tested over many years, and it's trusted by the security community. Some of the best encryption has been around for decades, and it's stood the test of time. But what BlackBerry has done to "improve random number generation" is use the Qualcomm processor that powers BlackBerry's DTEK50 to increase the amount of available entropy (essentially unpredictable events like fan speeds or network traffic). That entropy gets fed into the Linux RNG, with the intention of helping to scramble the data further. Exactly how Qualcomm does that, however, hasn't been fully disclosed. A spokesperson cited "non-disclosure agreements", effectively meaning only its customers and partners know.
All that sounds good and well. In reality -- it doesn't actually matter, says Thomas Ptacek, a respected cryptographer, who spoke to me by email.
"Nothing that BlackBerry or even Qualcomm can do with random number generation will meaningfully improve the cryptographic security of their new phone," he said. "That's because cryptographic randomness has been a solved problem on Linux for years." He explained that the Linux RNG is designed to safely mix in randomness from different sources, including some that are predictable. "Even if you fed it more weak random signals, the design won't lose security -- it just won't gain any," he said.
He describe a "culture of rubber-chicken-waving mysticism about how best to generate randomness" for the past decade, but "none of it much matters", so long as the platform has one secure random number generator -- and Android has that.
In other words, "this feature doesn't meaningfully change the security of the phone", he said.
The other cryptographers expressed cynicism with how BlackBerry portrayed the improvements.
"I think what we have here is bizarre: solving a solved problem, but losing trust by adding components that aren't open or documented," said Justin Troutman, an independent cryptographer, citing Qualcomm's secrecy around the process.
The secrecy surrounding that added complexity means cryptographers can't verify its implementation. The process may be secure, but nobody can be entirely sure.
"The reality is likely that, while security probably isn't jeopardized, the trade-off is also likely: zero practical benefit in exchange for shakier trust," he said.
Any kind of phone or device that uses homebrew encryption, or proprietary code that can't be inspected, will send alarm bells ringing to any security professional. It's difficult to trust a critical security component when the code isn't open-source, documented, or peer-reviewed.
In other words, "don't mess with the crypto."