Cryptome DVDs. Donate $25 for two DVDs of the Cryptome collection of 47,000 files from June 1996 to January 2009 (~6.9 GB). Click Paypal or mail check/MO made out to John Young, 251 West 89th Street, New York, NY 10024. The collection includes all files of cryptome.org, cryptome.info, jya.com, cartome.org, eyeball-series.org and iraq-kill-maim.org, and 23,100 (updated) pages of counter-intelligence dossiers declassified by the US Army Information and Security Command, dating from 1945 to 1985.The DVDs will be sent anywhere worldwide without extra cost.

26 May 2000: Add comment from Andrew D. Fernandes of Cryptonym Corporation (who discovered the NSA_KEY)

25 May 2000
Source: Duncan Campbell

This supercedes version of April 27, 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 [see parties involved]:


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
Microsoft Security Response Center

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?

The export regulatations for cryptography are provided in the BXA's Export Administration Regulations (EAR), 15 C.F.R. Parts 730-774. The specific regulations that are of interest regarding CryptoAPI are discussed in Part 740, section 17, paragraph f, "Open Cryptographic Interfaces".

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:

5. Microsoft has stated that it has sole possession of the NSA_KEY. Is this correct? Is it still true?

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.

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?

We have previously stated, and continue to state, that the purpose of the keys is *not* to enable third parties, including the US Government, to sign their own CSPs. This is in keeping with our historical stance in opposition to proposals such as Government key escrow.

7. Irrespective of the answers to the above, what is Microsoft's understanding of why it was require to include these keys?

First, let's discuss the signing keys and the signing process in in more detail. The first thing to note is what the signing means, and more importantly, what it does not mean. When Microsoft signs a CSP, it means only one thing -- that Microsoft has verified that the vendor's export paperwork is in order. It does *not* mean that we have verified the operation of the CSP. Some CSPs, such as the ones Microsoft provides by default, have been validated by third-party experts, but this is not a requirement for signing a CSP. Likewise, the signing is not intended as a security mechanism to prevent an adminstrator from modifying the CSPs. Some CSPs allow the administrator to supply his own code to perform certain cryptographic functions more efficiently -- this code might, for instance, interface to a hardware accelerator card. As long as these modifications don't affect the export-compliance of the CSP, the signature doesn't have to prevent it.

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?

In some respects, this is a historical question at this point, as the new US export controls published in January of this year allow us to ship 128-bit encryption in our products worldwide. Not only does this mean that we'll be able to distribute future products worldwide with 128-bit crypto, it also means that customers with existing products can upgrade them immediately to 128-bit crypto. So, customers using IE 4.0 and 5.0, the international versions of which were restricted to 40-bit crypto, and IE 5.01, the international version of which was restricted to 56-bit crypto, can apply the IE High Encryption Pack and upgrade to 128-bit crypto. (The High Encryption Pack is available at http://www.microsoft.com/windows/ie/download/128bit/intro.htm).

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.

The best references here are the specifications themselves:

Hope that helps! Please let me know if I can answer any other questions. Regards,

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.

Starting on date YYYY, we then developed. We had no communication of any type with or from NSA about how CAPI should be designed.

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?

If you're asking to review the design documents, I'm afraid I will have to decline. Like most companies, Microsoft must protect its intellectual property, and we simply don't release internal documents like these. However, we have provided complete design documentation to several governments as part of the various security evaluations we successfully completed. This included full design documentation for CryptoAPI. It seems reasonable to assume that if any of these security experts had any reservations about the adequacy or intent of the design, it would have been reflected in their findings.

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.

Actually, it is the correct answer. The point is that US export restrictions are public information, and Microsoft followed exactly the same process that any other vendor would have to follow in order to export approval for such a product.

The specific sequence of events was as follows:

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." Again, with respect, would you for the sake of the avoidance of doubt to please answer these questions directly. I repeat my questions.

We have sole possession of the so-called "NSA key", just as we have sole possession of all our keys. We do not share any of our private keys, including this one.

4. Has Microsoft to date signed any CSP or any other aplication with the second key? Has it ever been used, for anything?

Microsoft has never used the backup key to sign any production CSP or application. Please note that I've used the word "production" in the previous sentence. I'm sure that as part of system testing, we have signed test CSPs using this key.

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.

The longer answer is that CryptoAPI was designed under a fairly tight schedule in 1993. We could not create multiple copies of the same key, because the private portion of the key was generated on and lodged in a hardware device. In order to make a second copy of the key, we would have needed to completely replicate the hardware device -- but this is a difficult and time-consuming process and our ship schedule made this infeasible. On the other hand, it is quite easy to simply create a second key on a completely different hardware device. This is what we chose to do, and it is no better or worse security than replicating a single key to multiple locations.

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?

The variable name for the primary key is KEY

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?

The backup key has always been present in CryptoAPI. The variable name for the backup key was NSA_KEY, and it retained this name until Fall of 1999, at which point it was renamed KEY2.

8. If this [summary of Microsoft's postion] is not suitable, how would you out it instead?

In 1993, Microsoft developed CryptoAPI. As a cryptographic product, it was subject to the normal cryptographic export control mechanism. At the time, the Department of State exercised overall control of the licensing process, but NSA had the responsibility to perform all technical reviews. (Overall control later transitioned to Department of Commerce). We submitted a design that passed the technical review, and were granted an export approval.

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."

My view is different. I believe we are still a long way from any resolution of this issue. I have further questions. However, I would not seek to irritate you by putting questions if you now restate to me that you and Microsoft will refuse to reply further.

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.

Regards,

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
Director of Corporate Privacy
(US-COO-Division Management)
Microsoft
One Microsoft Way
Redmond WA 98052-63999
richarp@microsoft.com

Scott Culp
Microsoft Security Response Center
Microsoft
One Microsoft Way
Redmond WA 98052-63999
scottcu@microsoft.com

Duncan Campbell
Senior Research Fellow
Electronic Privacy Information Center
Suite 200
1718 Connecticut Avenue NW
Washington DC 20009
USA
campbell@epic.org

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: http://cryptome.org/nsakey-ms-dc.htm.

Microsoft's insistence that the second key is there for backup purposes is not a satisfying explanation for a number of reasons. The reason that the arguments are not satisfying is clear if you have experience using dedicated tamper-resistant crypto-boxes.

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.