Re: GeeK: Alert: CryptoAPI and _NSAKey issue

["Mike" <mike_cantelon@tcp.ca>]

[: hacktivism :]

I seems a fair assumption to me that if it looks like a duck and quacks like
a duck, it's probably a duck. The N S A has been trying to ram through key
escrow (having a duplicate of every encryption key given to them) for quite
some time. This seems to be a related issue. If this key has not already
been given to the N S A, it is probably there waiting for the N S A to get
key escrow ratified. At any rate, unless the cryptographers that are being
quoted are ignorant of the law, it should not be there.

People formerly involved in Echelon have said that it is used to monitor
civilan's email (even though that is technically illegal). Wouldn't the N S
A try to sneak in a backdoor to Windows?

Mike

>
> I'm new to this list so I hope forwards of this length are ok. I found
> it an interesting counterpoint to the rapidly spinning conspiracy
> hyperbole out there.
>
> -mark
>
> -----FW: <61143C10CC8AD211A2F10000F878E6830D58B0@ns.rc.on.ca>-----
>
> Date: Fri, 3 Sep 1999 15:57:43 -0400
> Sender: markjr@mail.easydns.com
> From: Russ <Russ.Cooper@RC.ON.CA>
> To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
> Subject: GeeK: 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-----
>
>
>
> --------------End of forwarded message-------------------------
>
> ---
> |||| mark jeftovic    (MJ177)   ====  http://SlingShot.to/StuntPope/     ||||
> |||| easyDNS Technologies Inc.  ====  http://www.easyDNS.com/            ||||
> ------------------------------------------------------------------------------
>  dns hosting / domain registrations / web forwarding / mail forwarding / etc
> ------------------------------------------------------------------------------
>
>
> [: hacktivism :]
> [: for unsubscribe instructions or list info consult the list FAQ :]
> [: http://hacktivism.tao.ca/ :]

[: hacktivism :]
[: for unsubscribe instructions or list info consult the list FAQ :]
[: http://hacktivism.tao.ca/ :]