Posts
BlackBerry Ltd, the NSA, and The Encryption Algorithm that NIST Warned You Not To Use
- In 2003, Certicom announced that it licensed its Elliptic Curve Cryptography technology to the NSA for US$25 million.
- In 2004, the NSA convinced RSA to make it the default CPRNG (Crypto Pseudo Random Number Generator) for its BSAFE software for an alleged US$10 million.
- In December, 2005 NIST issued its draft standard for Dual_EC_DRBG.
- In February, 2006, RSA announced that BSAFE had conformed with Suite B cryptography requirements issued by the NSA.
- In March, 2006, RSA announced that the NSA had chosen BSAFE "for use in a classified communications project".
- Starting in March, 2006 and continuing into 2007, security researchers Kristian Gjøsteen, Berry Schoenmakers and Andrey Sidorenko, Dan Shumow and Niels Ferguson, and Bruce Schneier all published articles warning about weaknesses in Dual EC DRBG. The final NIST standard SP 800-90A published in June 2006 included mention of those weaknesses as unresolved.
BlackBerry Ltd
According to NIST's DRBG Validation List, the following BlackBerry products include Dual EC DRBG:- BlackBerry Cryptographic Algorithm Library, Version 6.1 which apparently provides advanced cryptographic functionality to systems running BlackBerry 10 OS and components of BlackBerry Enterprise Service 10.
- BlackBerry Algorithm Library for Secure Work Space Version 1.0. ""The BlackBerry Algorithm Library for Secure Work Space provides a suite of cryptographic services utilized by the BlackBerry Cryptographic Library for the BlackBerry Secure Work Space (BBSWS). BBSWS provides the secure operation and management of iOS and Android devices when used in conjunction with BlackBerry® mobile device management solutions."
- BlackBerry Tablet Cryptographic Library Version 5.6. "The BlackBerry Tablet Cryptographic Library is the software module that provides advanced cryptographic functionality to BlackBerry Tablets."
"The Dual EC DRBG algorithm is only available to third party developers via the Cryptographic APIs on the platform. In the case of the Cryptographic API, it is available if a 3rd party developer wished to use the functionality and explicitly designed and developed a system that requested the use of the API."I then asked if BlackBerry has forwarded the NIST warning about not using Dual EC DRBG to its customers or developers and received this response:
"To your other question, the reason we didn’t issue an advisory is because it wasn’t a vulnerability. We only do them for fixes that are needed. You can read more about that process here: http://bizblog.blackberry.com/2013/07/security-privacy-malware-notices-advisories/. "Therefore, since this warning from NIST:
"Recommending against the use of SP 800-90A Dual Elliptic Curve Deterministic Random Bit Generation: NIST strongly recommends that, pending the resolution of the security concerns and the re-issuance of SP 800-90A, the Dual_EC_DRBG, as specified in the January 2012 version of SP 800-90A, no longer be used."
does not meet BlackBerry's definition of a vulnerability, the company hasn't issued an advisory. If you are a BlackBerry customer or developer, be advised that it's apparently up to you to keep informed about possible backdoors among the encryption algorithms included with BlackBerry products.
It just makes no sense - it is absurd not to consider a NSA backdoor a vulnerability.
ReplyDeleteThe question seems to become whether BlackBerry is stupid or evil.
Jeff: Thanks for making a complex issue more understandable.
ReplyDeletePerhaps this is why Snowden claimed that he could access communications of anyone, including POTUS...
A polite but firm takedown, well done.
ReplyDeleteThanks, Lewis. I'm learning to appreciate the complexities of nuance, depth, and patient research. :-)
DeleteCarr: A request. Could you please end columns like this with a short summary of your (obvious) opinion, like "I personally believe that BlackBerry Ltd lack of warning its customers or developers is incomprehensible, irresponsibly, and against best practices"?
ReplyDeleteIn the blog post, you are laying out the facts, and giving people the ability make reach own conclusions, which is good. But some people don't have the background to reach their own conclusions with certainty, but might still want some guidance.
I have personally been writing on Wikipedia's articles around Dual_EC_DRBG, and it is a pest when authors like you lays out all the facts, but then choose not to make an explicit conclusion. Probably because you think the facts speak for themselves (which they do to you and me, but not to everybody). I can see what the obvious conclusion it, but I can't write it in Wikipedia, because then it would be my opinion, and not the experts :(.
Bruce Schneier is a good example of someone doing it right, for example in http://www.wired.com/politics/security/commentary/securitymatters/2007/11/securitymatters_1115 .
If you read my other posts on this topic, my opinion is pretty clear. For this particular post, I've decided to let the facts speak for themselves.
DeleteThanks Jeffery, this is really good.
ReplyDeleteOne question that bugs me - if Blackberry is using Dual_EC_DRBG, then how come most in the US government still regard its products to be "more secure" than iOS or Android? Is it because the algorithm is weak only if Dual_EC_DRBP is used with a specific pair of initialization numbers (P and Q)? So the USG could ensure that its Blackberries were using safe P&Q while everyone else's Blackberry's are using the specially chosen ones? Where in the process does those numbers get chosen and who has control over them? Are they chosen by Blackberry and standard in every ROM?
I'm just trying to square the fact of the USG using a known vulnerable product for itself. That doesn't seem to be logical at all to me.
Well, you'd have to specifically have a developer use that algorithm. There are options which work better. I believe (although I could be mistaken) that the FIPS 140-2 standard prohibits making any changes for P and Q.
Delete> I believe (although I could be mistaken) that the FIPS 140-2 standard prohibits making any changes for P and Q.
DeleteYup, the NIST standard does prohibit the alternative P and Q, specifically stating you "shall" use the official curve and points if you want to be FIPS-certified (but can generate your own P and Q if you don't need to be FIPS-certified).
But according to the patent, using a smaller outlen will also disable the backdoor, and using a smaller outlen is only going against a "should", and therefore allowed for FIPS validation, as I read it.
That's why it was a shock that RSA made the algorithm the default - my understanding is that it's about 1000 times slower than the others in the standard.
ReplyDeleteDo we know if it's the default for Blackberry systems or just part of the suite?
Definitely NOT a default for BlackBerry.
Delete