Microsoft's CAPI

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 uses a special version of the OS).

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 (with they sign Netscape's CSP, for example).
They say they won't even look or keep a copy of your CSP (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.

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 examine the source to their crypto
(most CSPs will, presumably, not include source).

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.

-matt

According to Matt Blaze:

[[ Prelude about MS Cryptography API deleted ]]

>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.

	Did MS mention how the crypto DLL's would be "protected" from 
surreptitious tampering?  What I'm wondering is if it will be possible
to "drop in" a new (signed) crypto.dll (that just happens to
forward cleartext to the DLL author, or perhaps uses intentionally 
deficient (or just fixed) keys) when installing, for example, the latest
game craze distributed on the Internet?
	It would seem to be fairly sketchy (and dangerous) to allow drop-in
crypto engines if those can be replaced with *ANY* other crypto engine at
any time (note for the paranoid: Imagine "NSA the Game" for Windows(TM) with
the new "Send the Feds a copy" encryption DLL--that last part in fine print
of coures :)
	I am hoping that they do have some for of protection against this
that hasn't been mentioned yet, but this kind of jumps out at me when I
think of drop-in DLLs (anyone ever see how well the WINSOCK.DLL scheme
works? God Forbid that an encryption scheme be subject to the same problems!)

	--Sean

#include <std_disclaimer.h>

-----BEGIN PGP SIGNED MESSAGE-----

In article <199601171502.KAA16060@nsa.tempo.att.com>,
Matt Blaze <mab@research.att.com> wrote:

> 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 uses a special version of the OS).

The next obvious question is:  Will Microsoft sign strong-crypto CSPs
developed by foreign developers for out-of-USA use?



- -- 
   Alan Bostick             | He played the king as if afraid someone else 
Seeking opportunity to      | would play the ace.
develop multimedia content. |      John Mason Brown, drama critic
Finger abostick@netcom.com for more info and PGP public key

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQB1AwUBMP09JuVevBgtmhnpAQHbyQMAw3yh1qhIrBD0RF2ppiiiJnwJkF45qMKm
vsjXXZY92dJPbdLcOebxBRPCBxpyRSVqVKsy6QPA0KsYdLIgFt+ziFYWRrv3PFjz
f3Jf2dg+rhJ6G4dhDhTqp4/pdUT0huzy
=78Il
-----END PGP SIGNATURE-----

The shadowy figure took form and announced "I am Alan Bostick and I say ...
> The next obvious question is:  Will Microsoft sign strong-crypto CSPs
> developed by foreign developers for out-of-USA use?

To obvious really, if they signed strong foreign crypto MS would
neither be exporting strong crypto or exporting an application that
had general purpose crypto hooks, since technically only that specific
foreign implementation could be used.

However I would guess that the arrangement with the guvmint would
label the signing to be the equivalent of MS exporting an application
with strong crypto and subject to the same disciplinary measures, just
transfered to the time of signing.  Perhaps there will be some
modification to the itar - thou shalt not _enable_ foreign markets to
have strong crypto.

I assume MS would be free to sign weak foreign crypto, but as "weak"
crypto is hard/expensive to determine I think they would take the easy
way out.  Id also expect a kernel patch to be part of the install
procedure of foreign crypto.

--Matt