Yesterday the five-member panel appointed by the President to review “Intelligence and Communications Technologies” issued its report. The report is serious and substantial, and makes 46 specific recommendations for change. I expect to have a lot to say about the report and its aftermath, but for today I want to focus on one small aspect: what the report says about the possibility that the NSA inserted backdoors into software products.
Here’s what the report says (p. 217):
Upon review, however, we are unaware of any vulnerability created by the US Government in generally available commercial software that puts users at risk of criminal hackers or foreign governments decrypting their data. Moreover, it appears that in the vast majority of generally used, commercially available encryption software, there is no vulnerability , or “backdoor,” that makes it possible for the US Government or anyone else to achieve unauthorized access.
[Footnote: Any cryptographic algorithm can become exploitable if implemented incorrectly or used improperly.]
Obviously, the panel had neither the time nor the expertise to look at primary evidence on this point, so it must have relied on what the NSA told it. What is not clear is whether this text was wordsmithed by the panelists themselves, or whether it is based more directly on text provided by the NSA (for example, in NSA written responses to questions from the panel). It matters whether this precise text is the panel’s or the NSA’s. From the panel, I would expect a good faith effort to speak clearly. From the NSA, well, we have seen the word games they sometimes try to play.
Turning to the text, the most interesting feature is the difference between the first and second sentences, which have parallel structure but use different language. Here’s a chart laying out the differences:
| First sentence | Second sentence |
| unaware of any vulnerability | in vast majority … no vulnerability |
| vulnerability created by USG | [any vulnerability] |
| generally available commercial software | generally used, commercially available … software |
| [any software] | encryption software |
| puts users at risk of [non-USG exploit] | [exploitable by USG] or anyone else |
| decrypting data | unauthorized access |
This structure leaves open the possibility that there are vulnerabilities known to and exploitable by the US Government (USG). These might fall into several categories:
- vulnerabilities created by the USG that are exploitable only with the knowledge of a cryptographic key known only to the USG. An example would be the widely suspected backdoor in the NIST pseudorandom number generator standard.
- vulnerabilities created by the USG that allow access to data by means other than decryption, for example by allowing remote access to data at rest, or by causing copies of data to be sent to NSA collection points.
- vulnerabilities in software that is not generally available, such as internally developed software used by large companies to manage their data centers.
- vulnerabilities that are in non-encryption software and were not created by the USG. These would be outside the scope of both sentences.
One also wonders about the limitations based on commercial status: “generally available commercial software” in the first sentence, and “generally used, commercially available … software” in the second sentence. One wonders how the people who chose those phrases would classify critical open source software such as Linux or OpenSSL. Are these “commercial software”? Even if not “commercial software”, are they “commercially available”? I can see two possibilities here. Perhaps this is imprecise drafting by the panel who might have intended to cover all of the relevant software but, being less familiar with the technical community, might have missed this nuance. Or perhaps this is one of the NSA’s word games, meant to leave a loophole.
Finally, I am intrigued by the first part of the footnote (“… if implemented incorrectly”), which seems to miss the distinction between a cryptographic algorithm and cryptographic software. The implication is that a “cryptographic algorithm … implemented incorrectly” is somehow an exception to a statement about “encryption software”. As above, either the panel is missing a technical nuance, or something is hidden here. And if something is hidden, it is probably in the gap between the main text’s “encryption” and the footnote’s “cryptographic”. (The two terms are often used synonymously, although “cryptographic” has a broader technical meaning. For example, a digital signature is “cryptographic” but arguably it is not technically “encryption”.)
The good news here is that the panel’s Recommendation 29 would broadly prevent the US Government from undermining crypto standards or the security of popular software—assuming that the recommendation is adopted by Congress or the President.
“Upon review, however, we are unaware of any vulnerability created by the US Government in generally available commercial software that puts users at risk of criminal hackers or foreign governments decrypting their data.”
I read this as a rather weak statement. The weakness is along the lines of your first bullet but broader.
There could be vulnerabilities created by the US Government that puts users at risk of their data being decrypted, but the NSA (or the panel) is unaware of anyone actually currently being able to use these vulnerabilitiies. Then we turn to
“It appears that in the vast majority of generally used, commercially available encryption software, there is no vulnerability , or ‘backdoor,’ that makes it possible for the US Government or anyone else to achieve unauthorized access.”
The “vast majority” phrasing of the second sentence seems to indicate that there are in fact *some* known problems with *some* software packages, possibly including backdoors placed there by the USG.
We are aware of all the vulnerability forced to be created by the software companies by the US Government in generally available commercial software that puts users private information into the pool of hidden government protected businesses and their employed hackers which includes our partners in foreign governments known to also be retaining and decrypting illegally captured personal, business and private data.
Google PREF anyone?
I’m struck by the phrase “any vulnerability created by the US Government.” This leaves open the possibility of government-directed, vendor-implemented vulnerabilities; and also vendor-initiated vulnerabilities shared with the government (whether created intentionally or not, whether intended for government use or not).
Three hundred eight pages will be a lot to go through with such a fine tooth comb, looking as much at what was not said, or how it was said, as what it says on the surface.
Really good point. There are also black markets for vulnerabilities; if NSA encouraged a vendor to include a third party product that had a vulnerability that NSA purchased on one of these markets, then it wasn’t a USG created vulnerability, or even one created by a vendor for the USG. How could this happen? By having NSA require support for a feature that needed a particular third party software product. For example, if they required support for CAC cards [yes, I know that’s redundant] using a particular software library that they knew had problems.
It’s pretty clear that given how finely NSA writes their statements, parsing of every letter and word is necessary. Scenarios such as this may well be the “out” they have in mind. It’s unfortunate that the committee didn’t include any strong technologists along with the excellent policy and legal folks.
I look forward to the discussion of the phone companies archiving citizen’s meta data to be subpoenaed, and the national system of guids they’ll want to implement.
The recent Tor bundle exploit didn’t count? Because it’s not commercial? or did the government just not fess up to the committee about it?
The vulnerability in the TOR bundle was (most likely) not introduced by the NSA It was already known and patched in the upstream version of Firefox at the time it was used by the FBI but the patch was not yet ported to the TOR bundle.