Microsoft & the "NSAKEY"
Frequently Asked Questions

This FAQ was last updated on 11 September 1999.
Make sure you've read the original press release before continuing!

If you have any questions or comments, please send them to Andrew
Fernandes.

   * [S01] What is the danger?
        o [Q01] Am I at risk with the "_NSAKEY"?
        o [Q02] What does the "_NSAKEY" affect? PGP? SSL?
        o [Q03] So who, if anyone, should be worried?
        o [Q04] What is the real danger of the "_NSAKEY"?

   * [S02] What about the "removal program'?
        o [Q05] Does the program remove the "_NSAKEY" permanently?
        o [Q06] When will a Win95/98 version be available?
        o [Q07] When and where can I buy the final program?
        o [Q08] I get errors when running the program; why?
        o [Q09] Why is the source available only under NDA?

   * [S03] Is Microsoft telling the truth?
        o [Q10] What does Microsoft say?
        o [Q11] What do other data security specialists say?
        o [Q12] Why would it be an NSA key?
        o [Q13] Why would it not be an NSA key?

   * [S04] What should Microsoft to do about this?
        o [Q14] How can Microsoft acquit themselves?
        o [Q15] Is any other operating system at risk?
        o [Q16] Does Open-Source software, like Linux, help?

   * [S05] Miscellaneous Questions...
        o [Q17] What about that third key in Win2k?
        o [Q18] Where can the debugging symbol be found?
        o [Q19] Wasn't this whole thing a little overly sensationalized?
        o [Q20] Do programmers use a silly names like "_NSAKEY" on purpose?

[Image]

Answers

Again, if you have any questions or comments, please send them to Andrew
Fernandes.

[Image][Image]What is the danger?

Am I at risk with the "_NSAKEY"?

Almost certainly, the answer is no. The potential for a backdoor like this
one should only worry organizations intending to rely on Windows for large
scale, very security sensitive operations. Windows has enough known bugs
that almost hacker can access and tamper with your system. For the average
person, I would be more worried about known Windows bugs and viruses
letting in hackers than I would be about the NSA spying on me.

What does the "_NSAKEY" affect? PGP? SSL?

The key affects only products that use Microsoft's CryptoAPI architecture.
So far, that is a very small number of programs indeed. Most programs, such
as Network Associate's PGP or Netscape's SSL do not (and probably never
will) use CryptoAPI. In fact, Microsoft themselves rarely use the CryptoAPI
(or so we are told). You can look here for more info on Microsoft's
CryptoAPI.

So who, if anyone, should be worried?

The only people who should possibly worry are those responsible for the
operation of highly secure computers. Large organizations, companies, and
banks may fit this description. Individuals almost certainly don't.

What is the real danger of the "_NSAKEY"?

The real danger represented by the "_NSAKEY" is that it shows how US
companies must work with the NSA to gain export approval licenses. In the
US, a company needs an export license from the US Federal Department of
Commerce. Before granting this license, the Commerce Department requires
the company pass technical review by the NSA. You can see Bruce Schneier's
Crypto-Gram for how this can imply all sorts of nasty things. Also see [Q12
- Why would it be an NSA key?].

[Image][Image]What about the "removal program"?

Does the program remove the "_NSAKEY" permanently?

No. The program is a demonstration-only utility that loads a
Microsoft-signed and a Cryptonym-signed Cryptographic Service Provider
(CSP) into the CryptoAPI simultaneously. The CryptoAPI itself is not
modified at all from its original form.

When will a Win95/98 version be available?

Whenever a programmer with lots of experience in kernel-mode virtual memory
management under these operating systems donates his/her time to produce
it. We've had a very few number of offers, but no serious discussions have
occurred so far.

When and where can I buy the final program?

Never. First of all, by eliminating the second permanently, key we would be
modifying the functionality of Microsoft provided code. This violates all
sorts of copyright laws and is quite illegal. Second, we do not have (nor
do we want) a valid RSA license needed to produce the digital signatures
needed to run the demo. Therefore we only offer the program to be used in a
research and development setting.

I get errors when running the program; why?

You need to be in very specific directories when running the various
programs. Please read the "readme.txt" files in the distribution very
carefully.

Why is the source available only under NDA?

We offer the source code (for free) under nondisclosure agreement to
enforce our assertion that the program is to be used for research and
development only.

[Image][Image]Is Microsoft telling the truth?

What does Microsoft say?

The official Microsoft press release is here, as of 07 September 1999. Note
that there are a few technical problems with what they have said.
Specifically, Microsoft asserts:

   * the "_NSAKEY" key cannot be used to start or stop security services on
     a computer.
     However, we have never discussed starting or stopping security
     services, merely loading CryptoAPI Cryptographic Service Providers
     that may be already used by already running security services.
   * the "_NSAKEY" cannot be used by someone to weaken Windows' security.
     However, we are not talking about a generic someone here; whoever owns
     or effectively controls the "_NSAKEY" can tamper with already running
     security services, and compromise Windows' security.
   * the "_NSAKEY" is a merely a backup key for the first key (which is
     named "_KEY").
     However, that explanation doesn't make a lot of sense. For example:
        o Root keys are always (more accurately, should always) be
          symmetrically encrypted and cryptographically "split" just in
          case they are lost. Most tamper-resistant hardware works this
          way.
        o Having a second key operating in series with the first key allow
          the second key to be replaced (as per the demonstration program).
          In Microsoft's defense, they have written poor software suffering
          from the same problem like this before, such as the Authenticode
          framework.
        o Although conceivable, why are the keys not labeled "_KEY1" and
          "_KEY2", or "_KEY" and "_BACKUP_KEY"? That so-called unfortunate
          name "_NSAKEY" seems to be rather strong evidence that the NSA
          had input into the CryptoAPI system, at least on some level.

Furthermore, in the Washington Post, Microsoft indicated that the "_NSAKEY"
was there "only a notation that the key conforms to technical standards set
by the NSA". However, we need to point out that the NSA has no technical
standards for publicly available cryptography. In the US, the National
Institute of Standards and Technology (NIST) is responsible for
cryptography standards. If it can be said that the NSA in some way does
have crypto standards, then those are for bad cryptography. In other words,
the NSA standards are for weak, escrowed, or back-door holes in
cryptography.

Lastly, Microsoft asserts in their press release that losing the original
"_KEY" would be devastating because the rely on it daily. However, by their
own admission there are less than 50 Cryptographic Service Providers they
have signed so far, in the past 2+ years that the CryptoAPI has been
available. Software developers do not need to have their software signed by
Microsoft until they are ready for a final release, thanks to Microsoft's
own CryptoAPI Software Development Kit. Therefore it would seem that they
need the key once every couple of weeks, on the average, at most.

What do other data security specialists say?

Ian Goldberg of Zero Knowledge Systems, agrees that the key can be used as
some sort of back door, allowing "alternate" Cryptographic Service
Providers to be loaded into Windows.

Bruce Schneier, of Counterpane Systems does not buy the arguument. He
argues that there are already so many ways of compromising a Windows
machine that installing yet-another-hole is just a silly idea, and that
Microsoft would not be so stupid as to leave an incriminating debugging
symbol around.

On the other hand, his company (along with Peter Gutmann, and others) has
done quite a bit of work finding "stupid" cryptography and programming
errors in Windows. Furthermore, his comments seem to have been made in the
context of a personal computer user, where viruses and trojan-horses are a
real concern. In a data center operation, the integrity of the computer
components is what gives you security, not vulnerability to viruses; and
the CryptoAPI is an integral component of Windows.

Lastly, Bruce concludes that either the key is just a backup key as
Microsoft contends, or it was placed in to allow the NSA to produce
Cryptographic Service Providers for their own internal use. We've already
talked about the key being a backup key (see [Q10 - What does Microsoft
say?]). Regarding the possibility of NSA internal use, just remember that
this key is in every copy of almost every operating system Microsoft sells.
If it can be used for NSA internal use, why not external use?

Point in fact, Microsoft does not need the actual crypto DLL to sign it.
Instead, all they need is a 16-byte "digest" of the program, called an "MD5
hash". Therefore, Microsoft could easily sign crypto modules without having
access to the content of those modules themselves. So why have a separate
key for the NSA?

Matt Blaze of AT&T Research said in the New York Times that the key is
probably a backup key and nothing more. Again, see [Q10 - What does
Microsoft say?] for a response.

Why would it be an NSA key?

For an interesting read discussing An interesting link that discusses some
of the previous adventures of the NSA can be found by clicking here. Other
information on how the NSA works can be found by looking up "Project
Echelon" as mentioned in the 14 August 1999 issue of The Economist.

Historically, Microsoft's behavior has been a little strange. Initially,
developers were aware of one signature verification key embedded in the
CryptoAPI. In August of 1998, Nicko van Someren of Ncipher (along with Adi
Shamir; the 'S' in RSA) found that there was a second key along with the
first. Then, this August, we found the debugging symbols attached to the
second key. With each development, Microsoft has said the same thing: don't
worry, everything is fine, you have nothing to worry about. Yet every time,
we find that they have not told us the whole story of how their security
components really work, and what exactly were the terms on which they
passed their NSA technical review.

Why would it not be an NSA key?

There are actually several good reasons why the second key may not be
"owned" in some way by the NSA. We think it's inconceivable that the NSA
did not have some sort of influence on the second key; but whether or not
they "control" it is an open argument.

For instance, there are several good arguments that indicate the NSA would
not need anything more than a one-time signature from Microsoft to be able
to insert unauthorized Cryptographic Service Providers into a target
system. Specifically, if the NSA wrote a "shim" module that inserted itself
between Windows and the crypto module, and intercepted secure traffic. So,
they may have no need to write multiple service providers. Then again, we
don't know what they may have planned...

[Image][Image]What should Microsoft do about this?

How can Microsoft acquit themselves?

Microsoft can come clean in this matter by telling its clients (and the
world) the exact details of its deal with the NSA. If all they had to do
was pass a technical review, let us see the requirements of that technical
review. Let us talk to the developers and managers involved in working with
the NSA. To get their export license, we already know that some sort of
agreement with the NSA exists. We deserve to know the details.

Is any other operating system at risk?

Are you at risk if you use MacOS, Solaris, HP/UX, Tru64 Unix, AIX, VMS,
OS/2,  ... ?

Have you ever seen the source code to these operating systems? Who knows
what's going on in them?

A lesson may come from a story partially retold here. IBM was shipping
strong-crypto versions of Lotus Notes to Europe, but warned their customers
that in order to get an export license, the US government had been given an
escrow key to their "strong" crypto. Possibly because they didn't publicize
the fact enough, the Swedish government decided to make heavy use of Notes'
security... to their peril. So, in the end, IBM was really technically
being honest, but possibly not quite honest enough.

Does Open-Source software, like Linux, help?

Yes and no. Having the source code to your operating system certainly helps
reduce the risk of not knowing what's going on, but consider this:

   * the latest Linux kernel alone is well over 1.5-million lines of source
     code,
   * it would take a long time for some very experienced people to scan all
     of that code,
   * you would have to rely on the judgment of all those programmers to
     spot and "irregularities", and
   * nothing stops your hardware from being compromised if the software is
     secure.

These things being said, open source software definitely helps because it
does give you more ways to manage the risk of relying on others. For
instance, even though you would have to rely on the developers you had
scanning the source code:

   * lots of developers all over the world scan the code regularly, and
     there is a good chance an irregularity would be noticed, and
   * at least you get to pick who you are going to rely on to form security
     judgments.

Remember, we cannot eliminate the risks that we run in life, but we can
manage them.

[Image][Image]Miscellaneous Questions...

What about that third key in Win2k?

Microsoft has stated that this is a testing key, used for internal
development, and it should be removed in the final Win2k release.

This explanation is plausible and reasonable. However, since Win2k won't be
shipping for at least six more months, by the time we find out, this whole
issue may be dead. Furthermore, even if the key is still there, an excuse
could be as simple as "oh, we forgot to remove it that time... you know,
trying to make a late shipping deadline..."

Where can the debugging symbol be found?

Originally we reported that the symbol was only in NT4, sp5. However, many
people have written in to report that the symbol can be found in every
version of NT4 and every service pack. Unfortunately, we somehow missed
them when we looked.

Wasn't this whole thing a little overly sensationalized?

Perhaps. There is a real danger in trying to explain a highly technical
subject to the public that the ramifications will be either ignored or
overly sensationalized.

For instance, due to the relatively soft stance taken by the team that
broke the cellular telephone encryption schemes, most people today still
believe that conversations on a digital cellular phone are secure from
eavesdropping and cloning. In fact, the opposite is true; most modern
digital cell phones are secure only against casual eavesdropping. Odds are
that even this marginal security will disappear soon.

We decided to err on the side of getting the message out. Roughly, our
message would be "don't trust a software or hardware vendor just because
they have a good public relations department." A company that treats your
security in a cavalier manner should reap what they have sown.

Do programmers use a silly names like "_NSAKEY" on purpose?

As a strictly anecdotal story, one reader wrote in to tell us that the
X.509 Distinguished Name (DN) of the Lotus Notes' escrow key is "Big
Brother". So yes, sometimes programmers do use silly names in their
development. However silly the name "Big Brother" is, notice that it is
still apt, and contains a kernel of truth about what Notes was doing.

  ------------------------------------------------------------------------
 :: Home :: Products :: Services :: Research :: Hot Topics :: Company Info
                              :: Contact Us ::
        Copyright © 1999 Cryptonym Corporation. All rights reserved.
                         :: Frames :: No-Frames ::