【原】Windows下密码服务开发指引----CryptoAPI/CSP体系

写完上一篇，密码学这棵大树的主干，基本就勾勒完了。我们要开始为它添加枝叶和果实，就是一个个重要的知识点。今天介绍的是Windows下密码体系的实现和调用机制。

密码学是科学，PKI是技术体系，而不同操作系统平台有不同的PKI实现方式。Windows采用的是CryptoAPI/CSP体系。CryptoAPI是标准密码功能接口，包括了对称加解密、非对称加解密、数字签名与验证、数字摘要以及证书管理这些主要功能以及众多辅助功能。通过包含WinCrypt.h头文件，可以浏览并引入所需要的功能接口。如下图，调用CertOpenStore打开计算机上的证书存储集。

CryptoAPI足够强大全面，但它本质上只是调用接口，真正实现密码功能的是加密服务提供程序，英文全称Cryptographic Service Provider，简称CSP。Windows定义了一套标准的密码服务接口，CSP实现了这些接口，而CryptoAPI则通过这套接口调用CSP的相关功能。那么，CSP从哪来的呢？是由各个安全厂商提供的。比如，研发加密机、加密卡、USB Key的安全企业。根据密码学“私钥永远不出Key”的圭帛，涉及到密钥的运算都需要由硬件完成，而不同硬件的原生接口千差万别，应用系统如果直接调用硬件的接口，会带来很多的重复开发，程序的可移植性和兼容性也会差很多。因此，CSP机制的意义在于屏蔽了硬件实现的不同，各个厂商提供自己的CSP，使CryptoAPI可以用同样的接口调用不同的安全硬件功能。整个CryptoAPI/CSP体系的结构如下图。

从上往下看，应用层就是要实现密码
服务的应用，系统层是CryptoAPI，而服务提供层里就是各个产品的CSP了。这样的结构层次界限清晰，上层应用无需知道下层CSP细节，更重要的是，通过使用不同的CSP，就可以实现不同级别的安全运算，而应用系统本身可以做到无需改造。以电子印章系统为例，我们在开发时可以使用软实现（通过计算机软件功能实现）的CSP，以便于调试；在一般用户使用时，可以设置成使用某款USB Key的CSP；而在安全性要求更高，签章量很大的应用场景下，就可以配置成使用加密卡甚至加密机的CSP。而电子印章系统却不用因密码服务的不同而做代码的二次开发。打开Windows注册表的HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Defaults\Provider位置，可以看到目前所安装的CSP。而Microsoft Base Cryptographic Provider v1.0、Microsoft Enhanced Cryptographic Provider v1.0、Microsoft Strong Cryptographic Provider都是Windows提供的缺省CSP，以保证在没有安装任何第三方安全产品时，系统的密码功能还能正常运行。

2000年左右CSP由微软推出后，迅速成为市场上主流的密码服务调用机制，应用系统实现密码服务的门槛被大幅度降低。据我了解，Java、Android、IOS还没有类似的机制。而微软的这一机制倒是启发了国内很多CA厂商，它们也通过定义一套标准接口，实现接入多种安全硬件设备。

CryptoAPI/CSP机制虽然强大，但它毕竟比较复杂，而且不适合所有的应用场景，尤其是JavaScript这样的客户端页面脚本。你当然可以自己把CryptoAPI封装成COM控件，供脚本语言调用。但这里推荐CAPICOM，全名是 Cryptographic API Component Object Model，它是微软为了方便使用，将CryptoAPI封装成的COM安全组件。最新版本的CAPICOM是2.1.0.2。因为它是由微软原厂商提供，又和CryptoAPI同源，所以使用起来还是很方便的，尤其它对数字证书的管理使用做的很不错。比如用下面的语句就可以在JS中调用CAPICOM的证书组件。

var smcerts = new ActiveXObject ("CAPICOM.Certificate");

关于Windows下密码体系的实现和调用机制就介绍到这里，如果大家有任何问题和建议，欢迎评论交流。