COMMAND
CAPI (NSAKEY)
SYSTEMS AFFECTED
WinNT
PROBLEM
Andrew Fernandes found following. MS-CAPI trusts multiple keys
for code signing. However, in the regular distribution, all
modules are signed by only one key. It is possible to replace at
least one of the other 'trusted' signing keys (apparently provided
by the NSA) with any arbitrary key. An attacker could write a
compromised module (for example, a very weak random number
generator), and install it on a target machine by a virus or other
method. Replacing the _NSAKEY with his own would cause the
weakened module to be trusted.
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
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, there's
likely bugs in the OS designed to allow them to do this...
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).
So, whar's the problem? Oh, the second key. Russ Cooper was told
the NSA insisted there had to be a backup. No explanation as to
why yet. One theory that made a lot of sense 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.
Andrew's demonstration program effectively proves most of this:
http://www.cryptonym.com/hottopics/msft-nsa/ReplaceNsaKey.zip
SOLUTION
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.
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.
Papers to study too is:
http://www.counterpane.com/crypto-gram-9904.html#certificates
http://www.ncipher.com/products/files/papers/anguilla/keyhide2.pdf
http://www.counterpane.com/nsakey.html
One reader rightly pointed out that the "repair program" from
Cryptonym could be easily modified to become this malicious piece
of code. Interesting point.