Newsgroups: comp.dcom.telecom
From: brettf@netcom.com (Brett Frankenberger)
Subject: Re: Debate Flares Over MS 'Spy Key'
Date: 6 Sep 1999 03:26:27 GMT

In article <telecom19.377.12@telecom-digest.org>, Monty Solomon
<monty@roscom.com> wrote:

> Questions lingered Friday over whether or not security experts
> overreacted to a scientist's charge that Microsoft built a backdoor in
> Windows for a US spy agency to enter.

> [TELECOM Digest Editor's Note: I got the original article here, but
> chose not to run it. After some discussion with a couple of people
> my personal feeling was that something seemed fishy about the whole
> thing. The person who made the accusation never did respond to
  ...
> was located, or *how* it was to be used. One correspondent here
> said he thought it best to toss the whole thing in the trash.  PAT] 

Pat's essentially got it on the money.  NTBUGTRAQ has a lot of good
information on it, which I will attempt to summarize here.

First, what this is not: Even if it turns out that the "NSAKEY" is a
key owned by the NSA (and Microsoft denies this), it isn't something
that the NSA could use to directly hack into your computer.  (Of
course, if the NSA wants to do such a thing, they can use any number
of known Windows security holes ... none of them require knowledge of
any key, and all of them work just as well for the NSA as they do for
any other attacker.)

What this is:

First, we need to understand a bit about the Windows Cryptography
Services architecture.  Windows provides cryptography services to
applications through their "CryptoAPI".  This looks something like:

   [ApplicationThatWantsToUseCrypto]--[CryptoAPI]--[CSP]

Where:

  ApplicationThatWantsToUseCryptography is some application that wants
to encrypt and decrypt stuff (or sign things, or verify signatures, or
do other cryptopgraphy relayed things), and wants to use
Windows-provided services to do it.

  CrpytoAPI is the Microsoft standard interface between applications
and CSPs.  CryptoAPI doesn't itself do any crpytography for
applications -- it just fcilitates the process.

  CSPs are Cryptography Service Providers, which actually encrypt and
decrypt sutff.

Microsoft ships with Windows a CSP that the government deems acceptable
for export (i.e. 56 bits or less).  They don't need government approval
to do this, because it's 56 bits or less.  

Microsoft also ships the CryptoAPI with Windows.  This API can be used
to interface any form of encryption, as long as there is a CSP for that
form.  That is, I can use a 128 bit CSP, or a 200 bit CSP, or whatever
 ... CryptoAPI doesn't care -- it just passes stuff between the
application and the CSP.  But since the CryptoAPI will facilitate
encryption with keys longer than 56 bits, it's the position of the US
Government that it is export-controlled software.  That may or may not
be legally correct -- I'm not well-versed enough in the relevant law to
know -- but regardles, Microsoft seems to be going along.  So:

It turns out that the Government will allow Microsoft to export the
CryptoAPI as long as (1) Microsoft makes it so that it won't load just
any CSP -- it will only load CSPs signed by Microsoft, and (2)
Microsoft agrees not to sign CSPs that the government doesn't approve
of.

So, Microsoft generates a public/private key pair, sticks the public
key in the CryptoAPI and puts code in there to prevent a CSP from
loading if it isn't signed by the private key, and Microsoft keeps the
Private Key secret.

Now, this doesn't mean that you can't write code that uses strong
encryption without getting your encrpytion code signed by Microsoft. 
All it means is that you can't write a CSP and have other applications
use it, unless your CSP is signed by Microsoft.

Now, we find out that there isn't just one key pair that can sign CSPs. 
There's two.  And: In Microsoft's source code, the second one is named:
NSAKEY.  (This is just a variable name.  For example, both programs
below do the same thing, even though I used different variables:

  Prog#1: main(){char aaa="Hello World.\n"; printf(aaa);}
  Prog#2: main(){char nsa="Hello World.\n"; printf(nsa);}

There's nothing spy-like about the second program, even though I named
a variable "nsa".  But, in the case of the Microsoft CryptoAPI, some
people got curious/concerned about why Microsoft might name the key
NSAKEY.

Microsoft claims that they named it "NSAKEY" because it was the NSA
that insisted that they have a backup key.  (This is a tad suspicious,
because why would the NSA want there to be a second key.)  Previously,
they apparently had claims that the key was there to signify that the
NSA has approved the code.  (Huh?  Lots of groups and managers at
Microsoft also approved the code before it got released, but we don't
have a key in there to signify those approvals ...)  But, in any event,
Microsoft specifically says they have the private key that goes with
the "NSAKEY" public key.

But let's assume that the scare-mongers are right, and that the NSA has
the private key that goes with the NSAKEY public key.  All that means
is that the NSA could write CSPs that could be used in Windows, without
getting Microsoft's approval.  This really isn't so bad.  For many
reasons:

(1) You have never needed a key to write a CSP.  Having a key makes it
easy.  If you don't have a key, you just have to replace Microsoft's key
with your own key in memory (this is doable), and then replace all of
Microsoft's CSPs with your own CSPs that are signed by your key (this is
doable).  Yes, it's much harder if you don't have the key.  But the NSA
has the resources to do hard things.  The kid down the street might
need to know a private key to get a CSP in.  The NSA doesn't.  

(2) Implementing trojan CSPs isn't necessary something the NSA would
need to do anyway.  Let's say they write one and want it on my
computer.  Coming up to my front door and telling me that they are the
NSA and they would like me to install this new CSP they wrote in my
computer isn't likely to work.  It's even less likely to work on an
international terrorist.  So they have to find a way to hack into the
computer and install software.  And possessing the "NSAKEY" private key
is no help here.  Furthermore, once they get into the machine, why
would they want to go around implementing CSPs.  Once you're in, you
can do so much more.  

(3) Even if they want to implement a CSP, and they don't have the
NSAKEY private key, and they don't want to replace all Microsoft's
CSPs, all they have to do is disassemble the cryptography DLLs, add
another public/private keypair to them, reassemble them, and replace
them on the target machine.  The "replace them on the target machine"
is about the same difficulty as installing a CSP (in either case, you
need write access to the filesystem).  Disassembling (and reverse
engineering) the crypto code would be hard, but, again, not beyond the
NSA's resources.

So, in short: It doesn't matter whether or not you believe Microsoft
here.  Even if the NSA does have the private key that corresponds to
the "NSAKEY" public key, it doesn't enable them to do anything they
weren't able to do before.

Furthermore, as pointed out in the original announcement, this
backfired on the NSA anyway: Since the NSAKEY isn't currently used for
signing anything that comes with Windows, you can replace NSAKEY with
your own key without breaking anything.  And once you've done that, you
can write CSPs, sign them with your own key, and run them.  As Andrew
Fernandes said: Export Control for Windows CSPs is now effectively
dead.  Woops.  


     -- Brett

Newsgroups: comp.dcom.telecom
From: tls@panix.com (Thor Lancelot Simon)
Subject: Re: Debate Flares Over MS 'Spy Key'
Date: 6 Sep 1999 00:12:16 -0400
Reply-To: tls@rek.tjls.com

In article <telecom19.377.12@telecom-digest.org>, Monty Solomon
<monty@roscom.com> wrote:

> by James Glave

> Questions lingered Friday over whether or not security experts
> overreacted to a scientist's charge that Microsoft built a backdoor in
> Windows for a US spy agency to enter.

> http://www.wired.com/news/news/technology/story/21589.html

> MS Denies Windows 'Spy Key'
> by Steve Kettmann and James Glave
> 10:20 a.m.  3.Sep.99.PDT

> Microsoft is vehemently denying allegations by a leading cryptographer
> that its Windows platform contains a backdoor designed to give a US
> intelligence agency access to personal computers.

> http://www.wired.com/news/news/technology/story/21577.html

> [TELECOM Digest Editor's Note: I got the original article here, but
> chose not to run it. After some discussion with a couple of people
> my personal feeling was that something seemed fishy about the whole
> thing. The person who made the accusation never did respond to
> various inquiries about exactly *where* in the code this back door
> was located, or *how* it was to be used. One correspondent here
> said he thought it best to toss the whole thing in the trash.  PAT] 

Well.  The details are hardly secret.

Microsoft's CAPI ("Cryptography API" where API is "Application
Programming Interface" as usual) is designed to allow loadable
cryptography modules to provide enhanced security to various pieces of
the Windows operating system.  Because the U.S. typically does not
allow the export of such "cryptography with a hole" interfaces, where
an overseas entity could just obtain or produce strong crypto and drop
it into the "hole" in the existing framework, Microsoft requires that
such modules be signed with a secret key known only to Microsoft
before Windows will accept them.

It transpires that there are, in fact, not just one, but three such
keys.  This was determined by disassembly of the CAPI module loading
object code in Windows.  An analysis of a Microsoft patch which
accidentally went out the door without its debugging symbols (which
show the names of variables as they were in the source code) stripped
off yielded the information that one of those three keys was called
"__NSAKEY".

Given what the module does, this isn't terribly surprising to me,
and I doubt that it's evidence of any nefarious intent.  The NSA
probably wants the ability to provide CAPI modules for use within
the U.S. Government which it does *not* wish to provide copies of
to Microsoft in order to have them signed.  __NSAKEY presumably
exists in order to let them sign the modules themselves, so that
their (intra-governmental) consumers can load them without
Microsoft's say-so.

An interesting question is just what the third key might be for.  The
paranoid might (even semi-reasonably) suggest that this key, if it
were in the posession of, say, the FBI, could be tailor-made for
exercising the authority the FBI coincidentally just asked Congress
for: entering the home of the subject of an investigation, unloading
his usual CAPI module which provided strong crypto of some sort, and
loading a module supplying cryptography with a flaw known to those
tapping his communications.  Using various techniques (such as
generation of weak or known keys) this could be done *without*
impacting interoperability with whoever the subject might be
communicating with.  Again, we have a situation where the government
agency in question might not care to provide copies of its new crypto
modules to Microsoft for signing, yet would still need an unaltered
copy of Windows to load them without complaint ...

The patch, unfortunately, did *not* contain the debugging symbol
with the name of the mysterious third key.  So we lose any hint
that might have provided.  And of course it's entirely possible
that it was intended for some non-nefarious use -- probably more
likely than that it was intended for some underhanded use by
government snoops.  I personally consider it far more likely
that __NSAKEY, which all the fuss has been raised about, is intended
to keep NSA-developed government ciphers secret from Microsoft than
to help snoop on the public at large.  There are plenty of other ways
to do that.

What's really a shame is the blatantly unconstitutional program of
export controls which make all this secret skulduggery necessary
instead of just allowing simple, reasonable APIs for drop-in crypto of
the user's choice.  Soon the courts may knock them down, and it'll be
about time.  But that's probably a subject for another forum ...


Thor Lancelot Simon	                              tls@rek.tjls.com
	"And where do all these highways go, now that we are free?"