<nettime> Digest: "Microsoft, the NSA and You" (3 msgs)

["nettime's_digestive_system" <nettime-l@bbs.thing.net>]

---------- Forwarded message ----------
To: "nettime's_digestive_system" <nettime-l@bbs.thing.net>,
        thing.net@bbs.thing.net
Subject: Microsoft's statement.

> Synopsis: NSA has a backdoor into Windows NT by means of CryptoAPI,
> discovered by decompilation of software.  Bug only discovered because
> symbol information in CryptoAPI was not removed in Windows NT Service
> Pack 5.

 [Basing all those 'facts' on the name of only one identifier in code
  seems a little presumptious to me. We don't have to buy everything
  that Microsoft says, but do we have to believe everything that has a
  paranoid anti-Microsoft attitude? Besides, if the NSA needs access,
  why should they need a key of their own? I think they could do
  everything they wanted using the other key from Microsoft anyway.
  If they wanted, they'd probably find a way to force Microsoft to share
  it with them anyway. Anyway, here's the official reply from MS...]

From: http://microsoft.com/security/bulletins/backdoor.asp

Microsoft Security Bulletin

There is no "Back Door" in Windows 

Originally Posted: September 03, 1999 

Summary
A report alleges that Microsoft "may have installed a 'back door' for
the
National Security Agency... making it orders of magnitude easier for the
US government to access their computers". This allegation is false. 

What's the allegation?
The report alleges that a cryptographic key that ships as part of the
CryptoAPI architecture is labeled "NSA key" and constitutes a "back
door"
that could be used by government agencies to start or stop system
security services on user's computers. 

Is the allegation true?
No. Microsoft does not leave "back doors" in our products. This is in
keeping with our historical stance on this issue. For instance, we have
opposed the various key escrow proposals that have been suggested by the
government, because we because we don't believe they are in the best
interests of consumers or the industry. 

Are there two keys?
Yes. However, both are Microsoft keys. We do not share them with any
third party, including the National Security Agency or any other
government agency. 

What's CryptoAPI?
CryptoAPI is a Microsoft technology for providing cryptographic
services.
Vendors can develop stand-alone cryptographic modules called
Cryptographic Service Providers (CSPs), which can then be called by any
program via the CryptoAPI interface. For more information on CryptoAPI,
see http://www.microsoft.com/security/tech/cryptoapi/default.asp. 

What are the keys in question?
The keys are used to verify the digital signatures on CSPs. 

Why do CSPs have to be signed? And why by Microsoft?
CryptoAPI is subject US export laws regarding cryptography. One element
of this requires Microsoft to ensure that CryptoAPI will only load CSPs
that meet US cryptographic export laws. This is done by digitally
signing
all CSPs. Before it loads a CSP, CryptoAPI verifies that the CSP has
been
digitally signed. Part of Microsoft's responsibility as the vendor for
CryptoAPI is to sign the CSPs. 

When a vendor has a new CSP that they want to release, they submit it
for
signing and show that all export licensing has been received. Microsoft
then digitally signs the CSP, and it can thereafter be used by
CryptoAPI. 

Why are there two keys?
There is a primary and a backup key. 

Why is a backup key needed?
The backup key is needed for disaster recovery. To see why, suppose we
had only one signing key. If a natural disaster destroyed the building
in
which it were kept, all of the previously-signed CSPs would continue to
function normally, because the key used for verification exists in every
copy of Windows. However, Microsoft would need to sign future CSPs using
a new key. In order for these CSPs to be verified, matching key material
would need to be provided to all of the millions of customers using
Windows 95, 98 and Windows NT. Clearly, this would be a massive
undertaking. 

This is why there are two keys. If something befell the primary key,
Microsoft could thereafter sign CSPs using the backup key. Because the
backup is already in every copy of Windows, there would be no disruption
to customers. 

Why the backup key labeled "NSA key"?
This is simply an unfortunate name. The NSA performs the technical
review
for all US cryptographic export requests. The keys in question are the
ones that allow us to ensure compliance with the NSA's technical review.
Therefore, they came to known within Microsoft as "the NSA keys", and
this name was included in the symbol information for one of the keys.
However, Microsoft holds these keys and does not share them with anyone,
including the NSA. 

I heard that there is a third key in Windows 2000. Is this true?
There is a third key present in the beta versions of Windows 2000, but
it
does not provide a "back door". It is simply a test key that allows the
developers to sign test CSPs while Windows 2000 is under development. It
will not be present in the production version of Windows 2000. 

Does this have any effect on CryptoAPI's compliance with US export law?
No. The CryptoAPI architecture is fully compliant with US export law. 


---------- Forwarded message ----------
Date: Fri, 3 Sep 1999 20:49:07 -0500
From: Bruce Schneier <bruce@COUNTERPANE.COM>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
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

----- End of forwarded message from Paul Wouters -----

-- 
>}} sysx sysx.apana.org.au sysx.autonomous.org autonomous.org {{<
    "It's like a record needle cuts a groove into the brain."
>{{ http://autonomous.org/soundsite http://mp3.com/nerveagent }}<

#  distributed via <nettime>: no commercial use without permission
#  <nettime> is a moderated mailing list for net criticism,
#  collaborative text filtering and cultural politics of the nets
#  more info: majordomo@bbs.thing.net and "info nettime-l" in the msg body
#  archive: http://www.nettime.org contact: nettime@bbs.thing.net