Eric Murray <[EMAIL PROTECTED]> writes:
>>On Sat, Sep 04, 1999 at 01:59:01AM +0200, Lucky Green wrote:
>>>On Fri, 3 Sep 1999, Tim Dierks wrote:
>>>Even if the key belongs to the NSA, I suspect that the NSA just wanted to
>>>be able to load classified Crypto Service Providers into Windows and didn't
>>>want to have to send said classified software to Microsoft for approval,
>>>so they got the key installed so they could approve software in house.
>>
>>Classified crypto is done in secure hardware. Any hypothetical CSP's the NSA
>>needs to install on their own machines would not contain classified
>>algorithms. Hence the NSA could submit them to Microsoft for signing.
>
>I'm not a CAPI expert, but my understanding is that there is a CSP required
>even for hardware crypto. A hardware CSP would send data and keys etc as
>appropriate to the crypto hardware. This is how PKCS#11 and CDSA work.
The Fortezza CI driver (the only published NSA crypto interface) is just a
basic PCMCIA driver which marshalls the parameters passed to it and sends them
to a PCMCIA device (if you look at the published specs, you'll see that every
function in the Fortezza CI library maps directly to a Fortezza crypto hardware
function). Revealing the fact that CryptEncrypt() maps to a function in the
crypto hardware called ENCRYPT probably isn't a major threat to national
security. Existing PKCS #11 drivers also reveal details of classified crypto
algorithms like Juniper and Baton without this being a major problem. I don't
think this is a valid claim.
In any case there's a very easy workaround if you don't want anything about
your implementaton to leak: Get MS to sign a shim CSP which just passes the
call on to the real implementation:
CryptEncrypt( ... )
{
return( NSACryptEncrypt( ... ) );
}
This way you can get a signed CSP without having to reveal anything about the
implementation. This is also a good way to bootstrap a barn-door CSP (as
opposed to a back-door CSP), what you do is use the ability to specify
application-specific data in function calls as a covert channel to load the
real CSP:
SomeFunction( int keyType, void *keyParameters, ... )
{
..
if( keyType == MAGIC_VALUE )
LoadNewCSP( keyParameters );
...
}
"Tim Dierks" <[EMAIL PROTECTED]> writes:
>It's not clear to me why being able to sign CSP modules is a risky thing
>anyway; all it means is that Windows will load and execute your crypto. The
>mechanism is designed to keep overseas end users from being able to build
>and install strong crypto libraries. If the NSA has a key, all they can do
>is vouch for their libraries as export-qualified and thus enable their use.
The NSA have a history of covert backdoors in crypto shipped to other
countries, for example there's coverage of this sort of thing in the
Baltimore Sun (http://jya.com/nsa-sun.htm) and Der Spiegel (English
translation at http://jya.com/cryptoa2.htm). The reason it's a potential
security problem is that it allows the owner of the signing key to quietly
replace your strong (well, as close as MS will ever get to strong) crypto with
crypto which leaks keys in encrypted data or who knows what else.
>If I can get you to execute code on our Windows machine, I can penetrate
>your security, period.
ActiveX means every Windows machine is vulnerable (see Richard Smith's talk
at Usenix, reported in Wired, for details). What you do is use one of the
zillions of ActiveX holes to install the trapdoored crypto, and the NSA
signing key to make sure it loads. If you're not the NSA (or whoever it is
who really have the corresponding private key), you use ActiveX to install
the trapdoored crypto *and* replace the NSA key with your own, and that'll
also make sure it loads. This is at least as big a threat for US users as
for non-US ones (imagine a site like www.hotbabes.iq or www.freewidgets.sy
which quietly sidegrades the crypto of everyone connecting from a .mil
address to get an idea of the implications).
Peter.
