I am away in Australia for a while and typing this from LAX. Many alert politech readers have forwarded me info on this (thanks, all of you). Here are the URLs: http://www.slashdot.org/articles/99/09/03/0940241.shtml http://www.cnn.com/TECH/computing/9909/03/windows.nsa/ http://www.cryptonym.com/hottopics/msft-nsa.html http://www.wired.com/news/news/technology/story/21577.html And a heavily-fowarded note below. -Declan > > >From [EMAIL PROTECTED] Fri Sep 3 16:01:34 1999 > > Date: Fri, 3 Sep 1999 15:57:43 -0400 > > From: Russ <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > 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----- -------------------------------------------------------------------------- POLITECH -- the moderated mailing list of politics and technology To subscribe: send a message to [EMAIL PROTECTED] with this text: subscribe politech More information is at http://www.well.com/~declan/politech/ --------------------------------------------------------------------------
