[14 February 1996]
I attended a meeting at Microsoft the other day at which they
described their Crypto API project. As CAPIs go, it's reasonable
enough; nothing particularly exciting about it or especially wrong
with it (though they don't yet support nonblocking calls to crypto
modules).
They've defined 23 cryptographic services (establish key, encrypt, etc.) that an application is expected to use for its cryptographic needs. The idea is to hide the crypto details (and keys) from applications, and to make it easy to switch from, say, wimpy export-approved crypto to good crypto just by switching to another DLL at load-time. The cryptography used depends on the crypto modules in use at runtime. The API will be part of the WIN32 interface. The next version of NT (and windows 95, I think), to be released in a few months will support loading ``Cryptographic Service Providers'' (CSPs) that contain the crypto functions that sit below the API. They have (or will have soon) an application development kit to allow you to write code that uses the API, and a CSP development kit to let you write the crypto functions.
The interesting part is that they say they've made a deal with the government to allow applications that use the API to be exportable as long as they don't also try to implement crypto on their own. Ordinarily, the government claims that ``crypto with a hole'' (applications that call a crypto API) are just as export-controlled as crypto functions themselves, so this is something of a surprise and would represent considerable forward progress. But, of course, there's a catch.
The OS will not load just any old CSP. CSPs have to be signed by Microsoft. The kernel contains a (hardcoded?) 1024 RSA public key that it uses to check the signature when the user tries to load a CSP. If the signature check fails, the CSP won't load. Microsoft says it will sign any CSP from anyone AS LONG AS THEY CERTIFY THAT THEY WILL FOLLOW THE EXPORT RULES. So you can get your CSP signed if you use exportable cryptography or if you agree not to send it outside the US and Canada, etc. But an end user can't just compile crypto code and use it as a CSP, even for his or her own use, without getting it signed by Microsoft first (actually, the CSP development kit does allow this, but it includes a special version of the OS kernel).
I'm not sure whether this whole thing is good or bad. One important issue is whether MS will really sign anyone's CSP or whether they will start charging high fees or making business-based decisions on who's CSPs they will allow (will they sign Netscape's CSP, for example). They say they won't even look at or keep a copy of your CSP when they sign it (at my suggestion, they are probably going to change the process so that you send them a hash of your CSP instead of your CSP code when you get the signature). For now they promise to sign CSPs for anyone who returns the export certificate, at no charge. In any case, the scheme attempts to put Microsoft, for better or for worse, in control of the cryptography that gets used on their platforms.
We (Jack Lacy and I) will probably implement, get signed, and give away a CryptoLib-based CSP (not for export) for which we will also make source available so people can at least examine the source to the crypto they use (most CSPs will, presumably, not include source. MS plans to include an exportable RC4-40/RSA512-based "default" CSP with the OS).
Despite all this, I think it will be easy to get around the CSP signature requirements and use homebrew, unsigned crypto even with pre-compiled .exe files from other sources. I suspect it will be easy to write a program, for example, that takes an executable program and converts CryptoAPI calls to calls that look like just another DLL. And I'm sure someone will write a program to patch the NT/Windows kernel to ignore the signature check. Needless to say, it would be nice if someone outside the US were to write and distribute programs to do this. It would also be nice if someone would write a Unix/Linux version of the API/CSP mechanism. It might make it possible to export applications for those platforms as well.
I haven't tried any of this out yet, but they say they will have beta versions of the API and CSP developers kits out in a few weeks. They say that the API kit will not be export-controlled but the CSP kit will be. They plan to announce all this at the RSA conference this week.
[The 29 January issue of INFOWORLD, p. 25, reported that the Microsoft Crypto API would ship with the beta version of Windows NT 4.0 Workstation, to be shipped in the first week of February. The 22 January issue of Government Computer News reported that the NSA had awarded a contract under the MISSI program to Global Internet of Palo Alto, CA, to conduct a feasability study on how Windows NT version 3.51 might be altered to meet TCSEC B1 level requirements. The study also includes developing a prototype encryption card access control system based on Fortezza. Completion of the study is scheduled for late 1996. -- CEL]