Approved-By: Russ.Cooper@RC.ON.CA
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <61143C10CC8AD211A2F10000F878E6830D58B0@ns.rc.on.ca>
Date:         Fri, 3 Sep 1999 15:57:43 -0400
Reply-To: Russ <Russ.Cooper@RC.ON.CA>
Sender: Windows NT BugTraq Mailing List <NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM>
From: Russ <Russ.Cooper@RC.ON.CA>
Subject:      Alert: CryptoAPI and _NSAKey issue
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

-----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-----