<nettime> 4 fwds: NSA key in Microsoft crypto API

[t byfield <tbyfield@panix.com>]

     [i'm sure that the 'the NSA IS SPYING ON YOUR WINDOWS BOX'
      meme is very satisfying, but it's not very illuminating.
      here are four good posts discussing the recent news item
      about it. ah: 'API' means 'application programming inter-
      face'--the resources and rules that an operating system
      makes available to programs that run under that system.
      the last post (4, originally from the BUGTRAQ mailing
      list) *is* illuminating, because it talks about ways in
      which the NSA's alleged subversion of microsoft's (heh)
      security implementation can itself be subverted. but the
      bottom line, i think, is that it's impossible to know 'for
      sure' whether the extra key(s) is/are accessible to any-
      one but microsoft (assuming that microsoft is 'one').
      it may be accessible only to microsoft--until it's not.
      cheers, t]

--- Forwarded (1)

From: "Lucky Green" <shamrock@cypherpunks.to>
To: "cypherpunks@Algebra. COM" <cypherpunks@Algebra.COM>
Cc: "Cryptography@C2. Net" <cryptography@c2.net>, <bugtraq@securityfocus.com>
Old-Subject: NSA key in MSFT Crypto API
Date: Fri, 3 Sep 1999 00:21:01 -0700
Subject:  NSA key in MSFT Crypto API
Reply-To: "Lucky Green" <shamrock@cypherpunks.to>

Andrew Fernandes tonight published the results of his reverse engineering of
Microsoft's Crypto API (CAPI). [This builds on work done by Nicko van
Someren from nCipher].

Background: MSFT CAPI comes pre-installed with two keys used to check the
validity of a Cryptographic Service Provider (CSP). The holder of either key
can install operating system security services without user authorization.
The first key is used by MSFT to sign their own security services modules.
The identity of the second key holder until now been unknown. That is to say
until MSFT forgot to strip the binary of NT4 SP5 off debugging symbols.

Perhaps not surprisingly, the debugging symbol for the second key is...
_NSAKEY,

For more information and a program to remove the NSA's key from your copy of
Windows 95, 98, NT, 2000, see
http://www.cryptonym.com/hottopics/msft-nsa.html

Note that Windows 2000 includes not just two keys, but three keys that can
sign modules that will control security services on your copy of Windows.

Word has it that the third key belongs to the FBI. So far, there has been no
independent confirmation of this rumor.

--Lucky Green <shamrock@cypherpunks.to>

--- Backwarded (1)


--- Forwarded (2)

From: "Tim Dierks" <tim@dierks.org>
To: "Cryptography@C2. Net" <cryptography@c2.net>, <bugtraq@securityfocus.com>
Subject: RE: NSA key in MSFT Crypto API
Date: Fri, 3 Sep 1999 17:15:08 -0700
Sender: owner-cryptography@c2.net

It's not clear to me why being able to sign CSP modules is a risky thing
anyway; all it means is that Windows will load and execute your crypto. The
mechanism is designed to keep overseas end users from being able to build
and install strong crypto libraries. If the NSA has a key, all they can do
is vouch for their libraries as export-qualified and thus enable their use.

It's not a secret backdoor or anything, and modules need to be on the
machine before their signatures are checked. If I can get you to execute
code on our Windows machine, I can penetrate your security, period. These
authorizing signatures have nothing to do with it.

Even if the key belongs to the NSA, I suspect that the NSA just wanted to be
able to load classified Crypto Service Providers into Windows and didn't
want to have to send said classified software to Microsoft for approval, so
they got the key installed so they could approve software in house.

  - Tim

Tim Dierks
VP of Engineering, Certicom
tdierks@certicom.com
510.780.5409 [Hayward] -- 905.501.3791 [Mississauga]

--- Backwarded (2)



--- Forwarded (3)

From: "Lucky Green" <shamrock@cypherpunks.to>
To: "Robert Hettinga" <rah@shipwright.com>, "Matt Blaze" <mab@crypto.com>,
         <cypherpunks@cyberpass.net>
Cc: "Cryptography@C2. Net" <cryptography@c2.net>
Subject: RE: NSA key in MSFT Crypto API
Date: Fri, 3 Sep 1999 17:58:51 -0700

The NSA would be remiss in their task as US spy agency if it failed to
ensure that there are multiple backdoors to the world's most widely used
operating system. One would assume, there are backdoors even the vendor does
not know about.

After watching the NSAKEY talk at the Crypto rump session [name elided], by
his own account at the time the person ultimately responsible for CAPI at
Microsoft, told a group that even he had not know about the second key. In
addition, he informed us that access to the Windows source code is heavily
compartmentalized, making it easy to insert modifications without the
knowledge of even the respective product managers.

On thing I learned from my work on the GSM ciphers is that intelligence
agencies will insert compromises at every step: key size, key generation,
cryptographic algorithms, every single cryptographic component in GSM has
been deliberately compromised.

It therefore stands to reason that additional, so far undetected, backdoors
exist in Microsoft's operating systems.

--Lucky Green <shamrock@cypherpunks.to>

 -----Original Message-----
 From: Robert Hettinga [mailto:rah@shipwright.com]
 Sent: Friday, September 03, 1999 16:52
 To: Matt Blaze; Lucky Green; cypherpunks@cyberpass.net
 Cc: Cryptography@C2. Net; bugtraq@securityfocus.com
 Subject: Re: NSA key in MSFT Crypto API


 At 3:48 PM -0400 on 9/3/99, Matt Blaze wrote:


 > Since anyone
 > with a debugger and a copy of an MS OS can find this symbol, if this is
 > intended as some kind of covert mechanism, it's not very well hidden.

 Though, truth be told, the symbols were supposedly *accidently* left
 in on this one build.


 Which brings me to my crazy "policy page" theory of all this.

 When, finally, people looked inside the Netscape *executable*, and
 saw that just-as-you-please plaintext crypto "policy" page, something
 anybody with a clue and good text editor could go in and change,
 turning their crippleware to actual crypto (I mean, even *I* went and
 did it for chrissakes, and it worked), the folks at Netscape said,
 and I think this is a direct quote, "It took you long enough." The
 thing must have been in there for years, I bet.

 Anyway, I don't know why I *don't* believe the same thing about
 Microsoft (okay, maybe I do, only that's a theological reason :-)),
 but, right now, I just can't believe that they really did this thing
 so that people could fix their own crippleware, just like Netscape
 did with their policy page.

 Unfortunately, I think that all this *was* a mistake on their part,
 and, of course, there are just that many more neurons firing outside
 the Microsoft firewall than in it. A classic argument for open source
 and peer review, of course, but, paradoxically, one which, in the
 end, *helps* Microsoft to be more devious about their trapdoors in
 the future.

 I'd love to be proven wrong on this, and if someone on the other side
 of that Redmond firewall wants to actually speak up on this, cool,
 but I bet this is more about failed skullduggery than any
 crypto-beneficence on BillG's part.

 Cheers,
 RAH

--- Backwarded (3)



--- Forwarded (4)

Date:         Fri, 3 Sep 1999 16:32:38 -0400
Reply-To: Law & Policy of Computer Communications
<CYBERIA-L@LISTSERV.AOL.COM>
Sender: Law & Policy of Computer Communications
<CYBERIA-L@LISTSERV.AOL.COM>
From: David Lesher <wb8foz@NRK.COM>
Subject:      Re: [dc-sage] Microsoft, the NSA, and you... (fwd)
To: CYBERIA-L@LISTSERV.AOL.COM

This is long and nerdy, but think it's worthwhile.

Bugtraq, in general, is a place real security types hang out,
although I can't speak re: Ross (As I don't claim to know more
than a few crypto types; draw no conclusion from that.) I'll
assume NTBugtraq is similar.

Here's the NTBUGTRAQ post........
======================================================================

>From Russ.Cooper@RC.ON.CA Fri Sep  3 16:01:34 1999
Date: Fri, 3 Sep 1999 15:57:43 -0400
From: Russ <Russ.Cooper@RC.ON.CA>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: Alert: CryptoAPI and _NSAKey issue


-----BEGIN PGP SIGNED MESSAGE-----

This is also available at http://ntbugtraq.ntadvice.com/_nsakey.asp

Whoa horsie...

I had a long chat with Andrew Fernandes this morning, as well as
another chat with others, and of course I've had a ton of messages
sent my way with various links to various stories about the issue.

I wanted to get a few things straight before I sent this message, but
given how quickly things are spreading it makes sent to send something
interim.

Ok, so here's what I can tell you.

1. Andrew's speculation about the _NSAKEY being a backdoor for the NSA
is based on;

a) The variable is called "NSA".

b) Its a second key, not known to exist in Windows previously.

c) What possible purpose would a second key serve?

d) Its presence, arguably, weakens CryptoAPI (Andrew explains this on
his website at <http://www.cryptonym.com/hottopics/msft-nsa.html>,
I'll elaborate more later.

2. Sources close to Microsoft say that the key is a "Backup" key. It
is owned by Microsoft, and only Microsoft have the private key to it.
The key was named "_NSAKEY" because the NSA insisted that Microsoft
include a backup key in their CryptoAPI before the Commerce Department
would approve its inclusion in NT 4.0.

Editorial
- ---------

There's a bunch of somewhat understandable furor going on over the
idea that the NSA might have a backdoor to Windows. Unfortunately,
however, all of this is based on a variable name. Anyone who programs
knows that variables might get named anything for a variety of
reasons. One would expect that they would be named descriptively, but
alas, not everyone follows such stringent conventions (can you spell
"Easter Egg"?).

The Conspiracy Theorist's theory goes;
- -------------------------------------

- - The NSA has a signing key on your box.

- - The NSA can implant a Trojan to replace the module which performs
encryption on your box with one that doesn't perform encryption, and
because the failure of signature verification against Microsoft's key
is silent, they can get their trojan'd app up and running without you
being any the wiser.

- - The NSA can then sniff your traffic, now being conducted in
plain-text.

There's obviously a ton of variations possible on this theory, they
take your private key, they replace your key with another, etc...

They only have to get a Trojan to you and get you to run it, and as
those same Conspiracy Theorists always say, <speculation>there's
likely bugs in the OS designed to allow them to do
this...</speculation>

Yeah, could be true.

My take from Microsoft's Perspective;
- ------------------------------------

- - We want to have one build of our products that simultaneously
supports weak or strong encryption functionality.

- - We want to be able to ship this one product world-wide, changing as
few bits as possible for those that are being shipped outside the U.S.
and Canada.

- - We'll build an API (good, bad, or otherwise) that allows the
controlled bits to be inserted into an infrastructure, then get the
infrastructure approved, and all will be good.

- - Commerce (with advice from lots of people including the NSA),
agrees, and tells Microsoft they have to sign everything that can use
the infrastructure. That way, Microsoft can ship its product anywhere,
and Commerce will know that only those products that have been signed
by Microsoft will be able to run on the OS.

- - You want to build a Cryptographic Service Provider (CSP), the module
that performs the encryption, you gotta get Microsoft to sign it for
it to run. Microsoft doesn't sign anything that doesn't have the
appropriate Commerce Department Export approvals first.

Wonderful, life's good, Microsoft doesn't have to manage multiple
versions based on Crypto-strength, folks can implement whatever crypto
they want (assuming its Commerce approved).

Oh, the second key, I almost forgot;
- -----------------------------------

I'm told the NSA insisted there had to be a backup. No explanation as
to why yet, that's what I've been told. One theory that made a lot of
sense to me was the simple idea of;

What happens if Microsoft's key is ever compromised? Well, they'd
simply revoke it, right? Yeah, but the problem is that you'd have no
way of telling a Microsoft system that there's a new key. You'd have
to rely on the old one to tell it about the new one. But if there's a
backup key, and they're kept separate, you could use the Backup to
verify the new key to replace the primary.

That's only meaningful to Microsoft since there's no revocation lookup
being done on the primary anyway. Microsoft would have a way to
salvage its name by using a new key. In practice, this would be near
impossible to deploy, but hey, at least there's a way to do it
securely.

BUT!!!
- ------

Andrew's discovery goes beyond this NSA stuff. There's a real issue
here. Andrew has found that by replacing the _NSAKEY with one of your
own, you are able to add a CSP to the system signed only by you. This
by-passes Microsoft's signing controls (the ones Commerce needed to be
in place to allow Microsoft to ship its products world-wide).

As Andrew says, "Export controll is effectively dead for Windows."

More importantly, it means you can add a CSP that does whatever you
want it to do, and then modify existing Windows .dlls that call
CryptoAPI such that they are signed by you instead of Microsoft. This
will cause them to fail the Microsoft signature verification, but
they'll pass verification against your own signature. Windows will
silently let them run and do whatever it is you want them to with the
CryptoAPI environment.

In theory, you create your own CSP to replace Microsoft's supplied CSP
(implementing whatever you wanted in it, say boosting 40-bit to
128-bit), modify the second key to one of your own, install your CSP
over Microsoft's, and fire up any application that uses CryptoAPI. The
signature will fail Microsoft's verification, pass yours, and
everything should work as if you had a U.S./Canadian version.

Fortify <http://www.fortify.net/> for Windows NT (I'd sure love to see
that implemented, anyone up for the challenge?)

It also means the encryption you use on your system could be
compromised in the same fashion, assuming it relies on CryptoAPI
(hasn't this been called for by the U.S. President's commission?)

Andrew's demonstration program effectively proves most of this;

http://www.cryptonym.com/hottopics/msft-nsa/ReplaceNsaKey.zip

On the other hand;
- -----------------

If there were only one key present in the system, Andrew acknowledges,
then this wouldn't be possible. However, it would still be possible to
subvert the export controls by trojanning all of the necessary .dlls
used with CryptoAPI with ones signed by your key, and then replacing
the Microsoft key with your own. Its a lot more work, but it would
still achieve the same results.

Nobody is suggesting that any of this is a Remote Exploit, or
something you have to worry about receiving in Email. Sure, Andrew's
program demonstrates that a running application can subvert the second
key and implement its own CSP...in memory...which is possible but
unreliable.

Bottom-line:
- ------------

I think the NSA thing is being over-hyped. Sure, its possible, and we
need Microsoft to make their official statement about it to have it on
the record. Once they do, if anyone can prove its not their key I will
happily help them. I doubt anyone will...although I also doubt that
people will readily accept that it is a second Microsoft key (who
killed JFK?)...maybe Microsoft can sign something with the second key
so we could verify it somehow??

Meanwhile, the risk of your system's cryptographic methods being
exploited is limited while folks figure out how it could be done
effectively. I'm looking at how you could audit access or
manipulation, but what's really needed is a TripWire-like
functionality (http://www.tripwiresecurity.com/). Alternatively,
Microsoft should build-in some additional mechanism to verify that
something that should be Microsoft signed, really is Microsoft signed,
and not a blind failover to the second key.

As to the issues of a third key in W2K, I have no information
regarding this beyond what Andrew has said.

More as information becomes available.

Cheers,
Russ - NTBugtraq Editor

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2

iQCVAwUBN9AoOBBh2Kw/l7p5AQEArgQApuinKKbm2VgQ3etb6mm4MPu2IPiO4Orr
lhhzz3yYNqCJW0kgubSiPcZoOyHvD3VU2IXLk4CKRqeIhQEz1UXJhJWF11qYF888
pJQpo08ejP3aozx7AB4+37O7gWkLGcH+wAC8siMpOMMUjgHJUhkzOZ0Fa+tbXxt3
ntSOJU8kXus=
=Ihd3
-----END PGP SIGNATURE-----

--
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433

--- Backwarded (4)





#  distributed via <nettime>: no commercial use without permission
#  <nettime> is a moderated mailing list for net criticism,
#  collaborative text filtering and cultural politics of the nets
#  more info: majordomo@bbs.thing.net and "info nettime-l" in the msg body
#  archive: http://www.nettime.org contact: nettime@bbs.thing.net