|
|
| Microsoft Stonewalls NSA_Key Questions |
| by Duncan Campbell, Senior Research Fellow, Electronic Privacy Information Center(27/04/2000) |
|
|
| Microsoft offer
to resolve "questions about NSA_key", then put up a brick wall.
Background : Duncan Campbell gave a presentation on Global surveillance and the Echelon network at the Computers, Freedom and Privacy 2000 (CFP2000) conference held in Toronto, Canada from 4-7 April 2000. During the presentation, he instanced the NSA_KEY controversy as one of a number of oustanding issues related to security and surveillance. Richard Purcell, Microsoft’s Director of Corporate Privacy, also attended the CFP2000 conference. After the presentation, Purcell approached Campbell. He said that he wished to resolved the doubts about NSA_KEY. He would see that this was done. Campbell then put a number of key questions, politely but persistently. After three weeks, Microsoft backed off. They refused to answer outstanding questions. They declined even to explain why they were unwilling to continue contact. They stopped answering e-mail. The following correspondence took place : 7 April 2000 Hi Duncan - I'm a colleague of Richard Purcell at Microsoft -- I work in the Microsoft Security Response Center, so Richard's path and mine cross quite a bit. Richard mentioned to me that he recently met you, and you had some questions regarding the so-called "NSA key". I was involved in investigating the claims that were made about the key, and I think I should be able to answer your questions. Can you tell me what questions you have? Look forward to talking further with you, Scott Culp Toronto 8 April 2000 Dear Scott Culp By way of reference, I wrote the European Parliament report on communications surveillance, and am currently preparing a further report for the Electronic Privacy Information Center in Washington DC (EPIC). In both of these connections I will be grateful for your response. Those that I have seen to date have been insufficient. Thank you for offering to remedy this. 1. In relation to the NSA_KEY, Mr Purcell stated that it was included because of NSA requirements. Is this correct? 2. What is the requirement? If so :- 3. When was it communicated to Microsoft? 4. May I please see a copy? If not, why not? 5. Microsoft has stated that it has sole possession of the NSA_KEY. Is this correct? Is it still true? 6. I understand that Microsoft has denied that the purpose of the key is to enable the US government to sign its own CAPI modules without disclosing them or their code to Microsoft. Is this correct? Is it still correct? 7. Irrespective of the answers to the above, what is Microsoft's understanding of why it was require to include these keys. I may have further questions, but these will probably only arise if you are unable to give candid and complete answers to the above. However, in a separate area, I have another question. 8. In IE4 and 5, the export versions are restricted to 40 bit security. My understanding is that in fact the software generates a 128 bit key and encrypts with this; but 88 bits of the session key are broadcast with the message. Is this correct? If not, what is the accurate position? 9. Please describe with precision the form in which the message containing the 88 disclosed bits is sent from the browser when operating an SSL connection. (I am aware that the export position has recently changed.) Duncan Campbell Toronto 8 April 2000 Dear Richard Thanks for taking the time to talk to me at the conference. I have responded to Scott Culp, and hope that I will be getting forthright answers. Yours sincerely, Duncan Campbell Tue, 11 Apr 2000 Hi Duncan Thanks for your note. The two questions regarding the specific way that we handle 40-bit crypto are a bit out of my usual area -- I'm researching them and will get answers to you shortly. Meantime, I do want to answer the "NSA key" questions right away. Here goes: 1. In relation to the NSA_KEY, Mr Purcell stated that it was included because of NSA requirements. Is this correct? Richard's answer was correct, but I think I may be able to give you a bit more precise answer. To do so, I need to provide a little background. CryptoAPI is an architecture that provides applications with a standard way to request cryptographic functions such as encryption/decryption, digital signing, and so forth. Before CryptoAPI was available, if a software developer was writing an application that needed to use cryptography, he had two choices, both bad. He could write his own cryptographic functions and incorporate them into his code. However, cryptography is a rather specialized science, and it's easy to make a mistake that compromises the security of the cryptography. Alternatively, he could use a third party's pre-written cryptographic software, and call it from his own application. The problem here is portability. Every third-party's cryptographic implementation would likely have a different calling interface, so an application that used such an implementation would be "locked in" to the particular third-party software. CryptoAPI makes developers' lives easier, because it standardizes how cryptographic services are requested. This standardization benefits developers who write general-purpose software, as well as specialists who write cryptographic software. General-purpose developers no longer have to write their own cryptographic code, and they don't have to change their software when they want to change the third-party implementation they use. Cryptographic developers only have to code a single calling interface, rather than potentially having to customize their calling interfaces for different users. More important, CryptoAPI creates new market opportunities for crypto developers by making it easier for general-purpose developers to use cryptography. CryptoAPI ships as part of every Microsoft platform. Several cryptographic modules -- known as Cryptographic Service Providers (CSPs) -- ship by default, and customers can install additional CSPs at will. The fact that third-party cryptographic software can run under our CryptoAPI architecture raises an issue that ultimately touches on the raison d'etre for the so-called "NSA key". As a US company, Microsoft is bound by US export laws. Not only are we required to ensure that all of our products comply with US export laws, we're also required to make reasonable efforts to ensure that technologies like CryptoAPI also support US export law. Specifically, Microsoft has an obligation to make reasonable efforts to ensure that only CSPs that comply with US export law can be used in CryptoAPI. The signing keys in question are a mechanism for doing that. The US Department of Commerce, Bureau of Export Administration (BXA) has oversight authority regarding US export laws. However, they rely on the National Security Agency to perform technical evaluations regarding cryptographic export. NSA doesn't specify how an architecture like CryptoAPI must operate; it only provides a technical opinion regarding whether the architecture meets the export requirements. In short, NSA did not tell Microsoft to build CryptoAPI a certain way, it only evaluated our design and advised the BXA as to whether the design met export law. So the back-up signing key is present because the design that we submitted to the NSA for technical review included a back-up signing key, the NSA opined that this design satisfied US export requirements, and BXA issued the necessary license approvals. 2. What is the requirement? 3. When was it communicated to Microsoft? The BXA regulations are a matter of public record. 4. May I please see a copy? All of the EAR documentation is available online. Here are some specific references:
An overview of the BXA encryption regulations is available
at http://www.bxa.doc.gov/Encryption/regs.htm 6. I understand that Microsoft has denied that the
purpose of the key is to enable the US government to sign its own CAPI
modules without disclosing them or their code to Microsoft. Is this correct?
Is it still correct? 7. Irrespective of the answers to the above, what is
Microsoft's understanding of why it was require to include these keys?
When a third party wants to market a new CSP, they bring it to Microsoft and assert that either of two cases is true: (a) they intend to deploy the CSP only within North America, or (b) they intend to deploy the CSP outside of North America. In the former case, it is the vendor's responsibility to ensure that the CSP isn't exported, and we can immediately sign it. In the latter case, we confirm that the vendor has gotten export approval, then we sign the CSP. The keys in question are the ones used to sign the CSPs. One is a primary and one is a backup. We have been asked frequently why we have two keys. The answer is that it is strictly a disaster-recovery precaution. Suppose we had only one signing key. There's a private and a public half to the key -- the private half is held by Microsoft, and the public half is in every copy of Windows 95, 98, Windows NT and Windows 2000. Now suppose that the building that houses the private key were destroyed by an earthquake (Seattle is in a high-risk area for earthquakes, so this isn't as far-fetched as it might sound). All of the previously-signed CSPs would continue to work, because our customers could still verify the signatures. However, if we wanted to sign additional ones, we would need to create a new signing key and somehow distribute the public half of that key to all of our customers. That would be a mammoth job. That's why we have a primary and a backup key. The private half of the primary key is in one location, and the private half of the second key is in another. Both are under Microsoft's sole control, and we do not share them with anyone. The public half of both keys is included in every copy of Windows95, 98, Windows NT and Windows 2000. If the primary key were to be destroyed, we would simply begin signing new CSPs with the backup key, with no disruption to our customers. However, we have never needed to sign a CSP with the backup key. I'm sure you'll have some additional questions after reading the above. Just let me know what they are, and I'll do my best to answer them. Regards, Scott Tue, 11 Apr 2000 Hi Duncan - I was able to get answers for the last two questions on the list. Here they are: 8. In IE4 and 5, the export versions are restricted
to 40 bit security. My understanding is that in fact the software generates
a 128 bit key and encrypts with this; but 88 bits of the session key are
broadcast with the message. Is this correct? If not, what is the accurate
position? However, when 40- or 56-bit crypto is used in IE, the handling of the keys is done per the standard industry specifications: SSL and its successor, TLS. We must follow these specifications, or our implementation wouldn't be interoperable with other vendors'. SSL/TLS define a negotiation phase, during which the client and the server determine which cryptoalgorithm and key lengths will be used. Once the algorithm and key length have been negotiated, a table indicates exactly how the "effective" key material is expanded into the actual key that's used. For instance, if the client and server agree on 40-bit key, the table tells how to package the 40 key bits within the 128 bit key. The exact packaging varies by cryptoalgorithm and key length, but the main point is that we do it exactly the same way that every other vendor does, according to industry standard specifications. 9. Please describe with precision the form in which
the message containing the 88 disclosed bits is sent from the browser
when operating an SSL connection.
TLSv1: The TLS Working Group, Charter and related protocol specifications are described at http://www.ietf.org/html.charters/tls-charter.html See especially the TLS Protocol Version 1, IETF RFC
2246 at http://www.ietf.org/rfc/rfc2246.txt?number=2246 Scott Washington DC 24 April 2000 Dear Scott MS / NSA_KEY Thank you very much for your detailed reply on 11 April. I have further and supplementary questions. I look forward to your responses. Many thanks Duncan Campbell 1. In relation to the NSA_KEY, Mr Purcell stated that it was included because of NSA requirements. Is this correct? You replied […] The US Department of Commerce […] rely on the National Security Agency to perform technical evaluations regarding cryptographic export. NSA doesn't specify how an architecture like CryptoAPI must operate; it only provides a technical opinion regarding whether the architecture meets the export requirements. In short, NSA did not tell Microsoft to build CryptoAPI a certain way, it only evaluated our design and advised the BXA as to whether the design met export law. So the back-up signing key is present because the design that we submitted to the NSA for technical review included a back-up signing key, the NSA opined that this design satisfied US export requirements, and BXA issued the necessary license approvals. Q May I please have a copy of the "design that we submitted to the NSA for technical review [which] which included "a back-up signing key", and information as to when it was submitted. 2. When was [the requirement] communicated to Microsoft? You replied. The BXA regulations are a matter of public record. That is with respect, not the answer to the question I asked. I repeat my question. 3. Microsoft has stated that it has sole possession of the NSA_KEY. Is this correct? Is it still true? You replied. Microsoft does not share any of its private keys with any third party. That includes the CSP signing keys, and the so-called "NSA key" in particular. Q Again, with respect, would you for the sake of the avoidance of doubt to please answer these questions directly. I repeat my questions. 4. Irrespective of the answers to the above, what is Microsoft's understanding of why it was require to include these keys? You replied. […] When a third party wants to market a new CSP, they bring it to Microsoft and assert that either of two cases is true: (a) they intend to deploy the CSP only within North America, or (b) they intend to deploy the CSP outside of North America. In the former case, it is the vendor's responsibility to ensure that the CSP isn't exported, and we can immediately sign it. In the latter case, we confirm that the vendor has gotten export approval, then we sign the CSP. The keys in question are the ones used to sign the CSPs. One is a primary and one is a backup. […] it is strictly a disaster-recovery precaution. 5. Has Microsoft to date signed any CSP or any other aplication with the second key? Has it ever been used, for anything? You further replied. […] "Suppose we had only one signing key. There's a private and a public half to the key -- the private half is held by Microsoft, and the public half is in every copy of Windows 95, 98, Windows NT and Windows 2000. Now suppose that the building that houses the private key were destroyed by an earthquake (Seattle is in a high-risk area for earthquakes, so this isn't as far-fetched as it might sound). All of the previously-signed CSPs would continue to work, because our customers could still verify the signatures. However, if we wanted to sign additional ones, we would need to create a new signing key and somehow distribute the public half of that key to all of our customers. That would be a mammoth job That's why we have a primary and a backup key. The private half of the primary key is in one location, and the private half of the second key is in another." 5. Please explain with precision why this is a better security policy than lodging two or more copies of the private key at geographically dispersed, secure locations. More questions. 6. What is the label of the first [primary] key ? Has it always had that name? 7. Has the second key always been present? Was it always labelled NSA_KEY ? If not, when was it first introduced and what was it called? 8. Would it be fair and accurate and complete to summarise Microsoft’s position as follows. "On date XXXX we were advised by BXA of the export
regulations that would apply to our export of new products containing
cryptographic software. We then considered, purely internally, the precautions we should take for disaster recovery. We opted to have two keys, stored at separate locations. This was nothing whatsover to do with NSA. We knew that their technical review of the software would arise only when it was completed and submitted. They did not levy any requirements on us in relation to CAPI at this or any other time. Our programmers decided to call the first key ??? and the second key NSA_KEY. This did not relate to anything that NSA had required, because there were no requirements other than to show them the software and obtain their approval. Nor did it relate to any discussions with NSA about the design of CAPI, since there were no such discussions. There was in fact, no reason whatsoever to label the key NSA-KEY, rather than (for example) BAK_KEY or BXA_KEY or KEY_2. Its just a complete mystery to us why the programmer concerned chose that name. On a later date, namely ZZZZZ, we submitted our CAPI design to NSA. There was no discussion and no requirement for changes. They approved it. We then distributed it, starting on day QQQQQQ." If this is not suitable, how would you put it instead? Wed, 26 Apr 2000 Hi Duncan - Thanks for your note. I believe I've answered all your questions below, but I'm going to need to draw the line at this round of questions, as it seems to me that we've reached the end of productive exchange with the most recent set of questions. Regards, Scott 1. May I please have a copy of the "design that
we submitted to the NSA for technical review [which] which included "a
back-up signing key", and information as to when it was submitted?
2. When was [the requirement] communicated to Microsoft?
You replied, "The BXA regulations are a matter of public record."
That is with respect, not the answer to the question I asked. I repeat
my question. The specific sequence of events was as follows:
In 1992-93, Windows NT program management identified a need for a cryptographic API set that would allow third-party cryptographic modules to be installed. Because of the obvious parallels to the "crypto with a hole" case, we went to State Department, who confirmed that they would not grant export approval for our design unless it controlled which third-party cryptographic modules could be installed. We proposed using a signature mechanism to limit access to only export-approved CSPs (or CSPs that aren't subject to export controls) State Department, after technical review from NSA,
approved our design for export. 4. Has Microsoft to date signed any CSP or any other
aplication with the second key? Has it ever been used, for anything? 5. Please explain with precision why this is a better
security policy than lodging two or more copies of the private key at
geographically dispersed, secure locations. The short answer is that creating
multiple copies of the same key would be no better or worse security than
the method we chose. The two methods basically amount to the same thing.
It's important to note that this design critique isn't relevant to the question at hand. If we had designed CryptoAPI to use a single signing key, and had made multiple copies of it, we could just as easily have been falsely accused of giving one of the copies to the NSA. This is true of any signing mechanism -- the ultimate security of the system depends on how the key material is controlled. As we've previously noted, Microsoft has sole control of the keys used to sign CSPs. 6. What is the label of the first [primary] key ? Has
it always had that name? 7. Has the second key always been present? Was it always
labelled NSA_KEY ? If not, when was it first introduced and what was it
called? 8. If this [summary of Microsoft's postion] is not
suitable, how would you out it instead? Because CryptoAPI is a cryptographic enabling technology, our design was required to ensure that only CSPs that had themselves been granted export licenses or were not subject to US export restrictions could run under it. The design we developed checks for a digital signature on the CSP at execution time, and only allows a CSP to run if it has been signed using either of two signing keys. Microsoft has the responsibility to verify that every new CSP either has an export license or does not need one, after which point it signs the CSP. We chose to implement a design using two keys, a primary and a backup, for disaster recovery purposes. The rationale behind this design was that if the primary key were destroyed, we could sign new CSPs using the backup. There were alternative designs that could also have worked, but this is the design that we submitted and the Department of State approved. We have never needed to use the backup key, which gained noteriety in 1999 when it was learned that the variable name for it was "NSA_KEY". (The name reflects the fact that the key is present in the design to satisfy the NSA technical review per US cryptographic export regulations). As a corporate policy, Microsoft does not share any of its private key material with any third party, and this holds for the specific case of the so-called "NSA key" as well. Microsoft has historically opposed the various government key escrow schemes that have been proposed, and our handling of cryptographic material is consistent with this stance. Washington DC 26 April Dear Scott, You have kindly taken the time on two recent occasions to answer at some length the questions that I have put to you about the NSA_KEY affair. Thank you. However, I am saddened and dismayed by the terms in which you began your second reply, namely : "I'm going to need to draw the line at this round
of questions, as it seems to me that we've reached the end of productive
exchange with the most recent set of questions." But I will say this. I was drawn into this correspondence at the specific invitation of a senior Microsoft official attending the Computers, Freedom and Privacy conference in Toronto three weeks ago. My enquiries are not idle; I wrote a report for the European Parliament, which may shortly call for new reports including on this very issue. I am presently preparing a further report on electronic surveillance issues for EPIC, the Electronic Privacy Information Center in Washington DC. The issues are important as they go to the question of what level of trust consumers, especially outside the US, can put in the Windows operating system. We have aired important issues, and I would like to continue doing so. If Microsoft now insists on withdrawing from the dialogue it initiated, I will seek the comments and assistance of the wider cryptographic community to facilitate my understanding and reporting on these issues. To this end, an initial step I propose to take is to publish our exchanges on the web, in the first instance on relevant listservs and at the well-known US site covering these issues, www.crytome.org. This is a debate which belongs on the public record. Others will draw their conclusions from Microsoft's bringing down the curtain (if you do). I will draw my own conclusions when I have heard what they have to say. In closing, I do think that you and your colleagues ought to carry on talking to those concerned about privacy and security, and I urge you to so. I look forward to hearing from you shortly. Yours, Duncan Campbell 28 Apr 2000 Dear Duncan, I'm sorry, but we have definitely reached the end of this discussion. I have given you all the information there is on the issue and, in my estimation, the discussion is rapidly spiraling into the realm of conspiracy theory. Rather than obligate myself to rebut an endless series of hypotheses, I would rather simply put the data in your hands and let it speak for itself. You certainly can "seek the assistance of the wider cryptographic community", but that community has already spoken. For instance, I would refer you to articles like http://www.counterpane.com/crypto-gram-9909.html#NSAKeyinMicrosoftCryptoAPI, and note that even cryptographers who rarely agree with Microsoft on anything have concluded that this claim falls apart under the weight of its own illogic. The facts are clear, and I would submit that Occam's Razor applies.
We built a design that complied with those laws. People can argue over the merits of the design, but it is the one that we submitted and which was approved for export. Nothing in the design provides a "back door"
for the NSA or any other third party as long as the signing keys have
not been shared, and we have never shared them. Scott 28 Apr 2000 Dear Scott NSA_KEY in Microsoft Windows Thank you for your note of 28 April. I was surprised to read it. You suggest that our discussion is "rapidly spiraling into the realm of conspiracy theory" concerning an "endless series of hypotheses". That is not so. Kindly review the correspondence you have had from me this month. It consists entirely of questions. I have offered you no hypotheses, because I hold to none. Nothing that I have said speaks to a conspiracy, because I do not say that one is present. You say "I would rather simply put the data in your hands and let it speak for itself". That’s great, because that’s exactly what I want. In your last letter, however, you said that you would now cease to answer questions in this dialogue that your senior collegue invited. What I do seek to do is to test alternative hypotheses. One of these is that no-one should have any misgivings at all about the chance discovery in 1999 that a second key called NSA_KEY was embedded in CAPI. We both know that other hypotheses are out there. Only evidence, which you and not I are in a position to provide, can help an informed audience determine which hypotheses are better sustained. With great respect, issuing or repeating statements ex cathedra, performs none of this. Nor does asserting that "debate" is closed. I read Bruce Schneier’s Cryptogram article when he published it. He too offers hypotheses, and comments on some of them, but can only reach speculative conclusions because data is lacking. That’s what I would like to remedy by continuing our discussion, Yours, Duncan 12 May 2000 Dear Richard, You will recall talking to me at the Computers Freedom and Privacy 2000 conference. You said then that you wished to resolve the questions that had been raised about the "NSA_key" in CAPI, and invited Mr Scott Culp to correspond with me and answer my questions. As will have seen, Mr Culp has now refused to continue the correspondence, after he was asked by me to provide specific, direct answers to questions I asked. He then offered as his reasons for so doing so a number of observations which simply did not stand up to scrutiny. When I pointed this out to him, he ceased to correspond entirely. This type of behaviour is not merely impolite, it is intellectually dishonest and evasive. It is bound to raise suspicion that Microsoft does have something serious to hide about its conduct. It further puts in question the integrity of MS systems offered for sale overseas. So far as I am concerned, if Microsoft now adopts a position of belligerent silence, I am more concerned about the security of its systems than I was when I spoke to you a month ago. Then, I was entirely open to the idea that Microsoft might be able to prove that its conduct could be innocently explained. I now observe that this, apparently, is not the case. If you confirm that that is the position, so be it. The issue will not die, even if you now wish to hide from it. Next month, it is expected that European Parliament will set up a temporary committee to look further issue into the information security and surveillance matters which have aroused much concern over the past 2 years. The subject of the security of US software including this issue, will be on its agenda. Yours sincerely, Duncan Campbell The parties : Richard Purcell Scott Culp Duncan Campbell Additional comment from Andrew D. Fernandes of Cryptonym Corporation (who discovered the NSA_KEY) on the Microsoft/Duncan Campbell exchanges on the NSA_KEY
A dedicated crypto-box internally generates a key pair, exports the public key, and then digitally signs designated input whenever properly prompted. These boxes are specifically designed to NEVER export the private key as plaintext. Furthermore, these boxes are designed to destroy their private key if the box detects any attempted physical tampering. The danger with a crypto-box is not only the potential compromise of the private key. An almost as great danger is the loss of the private key! Consider that a disgruntled employee could destroy the private key by merely hitting the crypto-box, sticking a paperclip into an input port, or dropping an ice cube on the box... (no, I'm not making up the ice cube part - these boxes are usually temperature sensitive). What you would have is a very ready denial-of-service attack. Therefore, almost universally, crypto-boxes allow the export of the private key in encrypted format. A good crypto-box will even use advanced cryptographic techniques called "secret splitting" to split the encrypted key into several different parts - one part for each senior manager. That way, if the crypto-box is lost or destroyed, a new crypto-box can be quickly initialized and utilized. It is possible that Microsoft's CSP team has a crypto-box that will not export the private key even if it is in encrypted or secret-split format. If that is true, it would be natural to assume a second backup key would be necessary. However, look at this scenario in terms of "failure analysis", where the security of the CSP scheme fails if a signing key is lost. There are two signing keys that can load a CSP. If the first key is lost, Microsoft could rely on using the second key. If the second key is lost, then Microsoft is out of luck, and must patch or upgrade every copy of Windows in the world, as well as every CSP it has ever signed, all because they did not buy a crypto-box capable of data recovery. Call me draconian, but given the extraordinarily high level of cryptographic expertise that Microsoft employs, I would fire the design team that presented a CSP signing system based on a single backup, rather than data recovery. So it is rather strange that the CSP signing key (labeled "_KEY") has backup key at all... even more strange that it would be labeled "_NSAKEY". In fact, there is no specific requirement in the BXA's EAR that backup keys exist. That document draws heavily on the Wassenaar Arrangement on the export of dual-use goods (http://www.wassenaar.org/) for its wording and substance. |
|
|