This general area of discussion -- software modification authentication -- is a bit fuzzy: if you can modify the software you can patch out the check of the signature (a correctly placed NOP is known to do it). However, and for example in the FIPS 140-1 crypto software validation program, you can do simple things to slightly frustrate the simple minded patching out of keys etc. FIPS 140-1 suggests actions such as signatures on modules, code to check the signatures being located in two different modules (so that modification of one module alone is not sufficient). (FIPS 140-1 is a US government / NIST program for validation of crypto modules). Interestingly, a recent press release suggests Microsoft is claiming it will have FIPS 140-1 on their crypto modules in the latest version of NT. David Howe <[EMAIL PROTECTED]> writes: > > It's very important to note the difference between key > <I>loss</I> > > and key <I>compromise</I>. Key loss means the loss of the > private > > key itself, and with it the ability for Microsoft to sign CSPs. > > Key compromise means the loss of the confidentiality associated > > with the key, as would happen if, for example, someone gained a > > copy of the key. > > I can't see the difference - unless the mere USE of the second key > disables the first, you will still need to run some sort of patch to > disable the original key - so why not just change the key with that > patcher? If Microsoft can change the operational key (Microsoft key) with a patcher, so can anyone else. A key compromise certificate whilst proving you have the private key does not authenticate the new key. Someone else (once you have released your patch containing the revocation cert) can use it to write a new patch which puts their own key in place. A plausible design involving an operational key and a disaster (or compromise) recovery key would be to allow updates of the operational key with a patch signed by the recovery key. However, whilst this is plausible -- this is not what Microsoft are doing: the NSA key is accepted as a key that can be used to sign CAPI modules directly. And as has been noted the NSA key can be patched in a completely simple minded way, allowing anyone to easily insert their own modules. (Though one supposes it is within the bounds of possibility that the NSA key has two functions: where it could also used to sign operational key replacement patches. However in that case you would have expected some attempt to prevent replacement of the NSA key, but we know that there is no authentication for replacing the NSA key -- you can just patch it out.) So in summary I conclude that Microsoft is just blowing smoke. The key is NSA's, and is either intended for Info War purposes, or for their own use, or both. Brian LaMacchia (head of CAPI development at Microsoft) knows what he is talking about. I think if Microsoft were in the clear, the best PR approach would be to just let BAL do the press release. However, from Lucky's comments on the cryptography list: : After watching the NSAKEY talk at the Crypto rump session [name : elided], by his own account at the time the person ultimately : responsible for CAPI at Microsoft, told a group that even he had not : know about the second key. In addition, he informed us that access : to the Windows source code is heavily compartmentalized, making it : easy to insert modifications without the knowledge of even the : respective product managers. it appears BAL was not aware of the second key. So the evidence to me indicates that it is NSA's key, and Microsoft does not want to admit it because it makes for bad PR. Or that Microsoft is doing a poor job of in it's press releases! Adam
