nettime's_digestive_system on Tue, 7 Sep 1999 01:07:07 +0200 (CEST) |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
<nettime> Digest: "Microsoft, the NSA and You" (3 msgs) |
---------- 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