On Mon, 6 Sep 1999, r.i.p wrote:
> Just received a mail with this link:
>
> http://www.cryptonym.com/hottopics/msft-nsa.html
>
> As I understand it, this means that the US National Security Agency has the
> potential to access any machine using Windows 95/98/NT !
>
Unlikely or at least there are better ways. The email below is from an
mailing list for NT security.
-------------------------------------------------------------------------
> From [EMAIL PROTECTED] Mon Sep 6 19:39:32 1999
> Date: Fri, 3 Sep 1999 20:49:07 -0500
> From: Bruce Schneier <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Comments on the "NSA" key in Microsoft CryptoAPI
This is a response
to: http://ntbugtraq.ntadvice.com/default.asp?sid=1&pid=47&aid=52
A few months ago in my newsletter Crypto-Gram, I talked about Microsoft's
system for digitally signing cryptography suits that go into its operating
system. The point is that only approved crypto suites can be used, which
makes thing like export control easier. Annoying as it is, this is the
current marketplace.
Microsoft has two keys, a primary and a spare. The Crypto-Gram article
talked about attacks based on the fact that a crypto suite is considered
signed if it is signed by EITHER key, and that there is no mechanism for
transitioning from the primary key to the backup. It's stupid
cryptography, but the sort of thing you'd expect out of Microsoft.
Suddenly there's a flurry of press activity because someone notices that
the second key is called "NSAKEY" in the code. Ah ha! The NSA can sign
crypto suites. They can use this ability to drop a Trojaned crypto suite
into your computers. Or so the conspiracy theory goes.
I don't buy it.
First, if the NSA wanted to compromise Microsoft's Crypto API, it would be
much easier to either 1) convince MS to tell them the secret key for MS's
signature key, 2) get MS to sign an NSA-compromised module, 3) install a
module other than Crypto API to break the encryption (no other modules need
signatures). It's always easier to break good encryption.
Second, NSA doesn't need a key to compromise security in Windows. Programs
like Back Orifice can do it without any keys. Attacking the Crypto API
still requires that the victim run an executable (even a Word macro) on his
computer. If you can convince a victim to run an untrusted macro, there
are a zillion smarter ways to compromise security.
Third, why in the world would anyone call a secret NSA key "NSAKEY." Lots
of people have access to source code within Microsoft; a conspiracy like
this would only be known by a few people. Anyone with a debugger could
have found this "NSAKEY." If this is a covert mechanism, it's not very covert.
I see two possibilities. One, that the backup key is just as Microsoft
says, a backup key. It's called "NSAKEY" for some dumb reason, and that's
that.
Two, that it is actually an NSA key. If the NSA is going to use Microsoft
products for classified traffic, they're going to install their own
cryptography. They're not going to want to show it to anyone, not even
Microsoft. They are going to want to sign their own modules. So the
backup key could also be an NSA internal key, so that they could install
strong cryptography on Microsoft products for their own internal use.
But it's not an NSA key so they can secretly install weak cryptography on
the unsuspecting masses. There are just too many smarter things they can
do to the unsuspecting masses.
Bruce
-----------
The following is from the April Crypto-Gram,
at: http://www.counterpane.com/crypto-gram-9904.html#certificates
Attacking Certificates with Computer Viruses
How do you know an e-mail is authentic? You verify the digital signature,
of course. This means that you verify that the message was correctly
signed, using the sender's public key. How do you know that the sender's
(call her Alice) public key is valid? You check the signature on *that*
public key.
What you're checking is called a certificate. Someone else, call him Bob,
signs Alice's public key and confirms that it is valid. So you verify Bob's
signature on Alice's certificate, so you can verify Alice's signature on
her e-mail.
Okay, how do you know that Bob's signature is valid? Maybe Carol signs her
key (creating another certificate). That doesn't actually solve the
problem; it just moves it up another layer. Or maybe you signed Bob's key,
so you know to trust him. Or maybe someone else whose key you signed has
signed Carol's key. In the end, you have to trust someone.
This notion of a certificate chain is one of the biggest problems with
public-key cryptography, and one that isn't talked about very much. PGP
uses the notion of "trusted introducers"; Bob signs Alice's key because Bob
knows Alice and is her friend. You signed Bob's key for the same reason. So
when Alice sends you an e-mail you can note that her public key is signed
by Bob, and you trust Bob to introduce you to people. (Much like Bob
bringing Alice along to your party.)
Other Internet protocols -- S/MIME, SSL, etc. -- take a more hierarchical
approach. You probably got your public key signed by a company like
Verisign. A Web site's SSL public key might have been signed by Netscape.
Microsoft signs public keys used to sign pieces of ActiveX code you might
download from the net.
These so-called "root-level certificates" come hard-wired into your
browser. So when you try to establish an SSL connection with some Web site,
that Web site sends you its public-key certificate. You check to see if
that certificate is signed (using the public key in your browser); if it
is, you're happy. The you-have-to-trust-someone public keys are the ones
that come with your software. You trust them implicitly, with no outside
verification.
So if you're a paranoid computer-security professional, the obvious
question to ask is: can a rogue piece of software replace the root-level
certificates in my browser and trick me into trusting someone? Of course it
can.
It's even weirder than that. Researchers Adi Shamir and Nico van Someren
looked at writing programs that automatically search for public-key
certificates and replace them with phony ones. It turns out that the
randomness characteristics of a public key make them stick out like sore
thumbs, so they're easy to find.
This attack isn't without problems. If a virus replaces the root Netscape
certificate with a phony one, it can trick you into believing a fake
certificate is valid. But that replacement certificate can't verify any
real certificates, so you'll also believe that every real certificate is
invalid. (Hopefully, you'll notice this.) But it works well with
Microsoft's Authenticode. Microsoft had the foresight to include two
root-level Authenticode certificates, presumably for if one ever gets
compromised. But the software is designed to authenticate code if even one
checks out. So a virus can replace the Authenticode spare certificate. Now
rogue software signed with this rogue certificate verifies as valid, and
real software signed by valid Microsoft-approved companies still checks out
as valid.
This virus doesn't exist yet, but it could be written.
An okay story on the topic:
http://www.techweb.com/wire/story/TWB19990315S0001
The actual research paper:
http://www.ncipher.com/products/files/papers/anguilla/keyhide2.pdf
--- from list [EMAIL PROTECTED] ---
