目录
1 CryptoAPI
1.1 五个主要功能区域
1.2 函数
1.2.1 基本加密函数
1.2.2 证书和证书库函数
1.2.3 证书验证函数
1.2.4 创建密钥容器
2 PKCS#11
2.1 函数
2.2 操作
3 GM/T 0018-2012
3.1 简介
3.2 范围
3.3 结构模型
3.4 函数
3.5 安全要求
3.5.1 密钥管理要求
3.5.2 密码服务要求
3.5.3 设备状态要求
3.5.4 其他要求
4 调用不同接口的代码
PKCS#11
SKF
密码引擎API的主要标准和规范包括：
1 微软的Crypto API
2 RAS公司的PKCS#11标准
3 中国商用密码标准：GMT 0016-2012 智能密码钥匙密码应用接口规范，GMT 0018-2012密码设备应用接口规范等
研究以上API接口，总结他们的异同，并以龙脉GM3000Key为例，写出调用不同接口的代码，提交博客链接和代码链接。
内容：
0 查找各种标准的原始文档，研究学习（至少包含Crypto API,PKCS#11,GMT 0016-2012,GMT 0018-2012）（5分）
1 总结这些API在编程中的使用方式（5分）
2 列出这些API包含的函数，进行分类，并总结它们的异同（10分）
3 以龙脉GM3000Key为例，写出调用不同接口的代码（Crypto API,PKCS#11，SKF接口），把运行截图加入博客，并提供代码链接（10分）
1 CryptoAPI
1.1 五个主要功能区域
基本密码功能
证书编码/解码功能
证书存储功能
简化的消息功能
低级消息功能
1.2 函数
基本加密函数、证书编码与解码函数、证书存储函数、简化信息处理函数、底层信息处理函数。
1.2.1 基本加密函数
服务提供者函数
** 密钥的产生和交换函数**
编码/解码函数
数据加密/解密函数
哈希和数字签名函数
1.2.2 证书和证书库函数
这组函数是管理、使用和取得证书、证书撤销列表和证书信任列表。
证书库函数：一个用户站点可以收集许多证书。这些证书是为这个站点的用户所使用的，证书描述了这个用户的具体身份。对于每个人，可能有一个以上的证书。证书库和其相关的函数提供了对库获得、枚举、验证和使用证书库里的信息。
维护函数
证书函数
证书撤销列表函数
1.2.3 证书验证函数
证书验证是通过CTL 和证书列表进行的.
使用CTL的函数
证书链验证函数
1.2.4 创建密钥容器
创建密钥容器得到CSP句柄:每一个CSP都有一个名字和一个类型，并且名字保证唯一。所以可以通过名字和类型得到一个CSP。然而，要想加密肯定需要密钥，密钥放在密钥容器。密钥容器并不是一开始就存在的，需要用户去创建。下面是创建容器的代码：
if(CryptAcquireContext(
&hCryptProv, // 返回CSP句柄
UserName, // 密码容器名
NULL, // NULL时使用默认CSP名（微软RSA Base Provider）
PROV_RSA_FULL, // CSP类型
0)) // Flag values
{
//以UserName为名的密钥容器存在，那么我们已经得到了CSP的句柄
printf("A crypto context with the %s key container \n", UserName);
printf("has been acquired.\n\n");
}
else //如果密钥容器不存在，我们需要创建这个密钥容器
{
if(CryptAcquireContext(
&hCryptProv,
UserName,
NULL,
PROV_RSA_FULL,
CRYPT_NEWKEYSET)) //创建以UserName为名的密钥容器
{
//创建密钥容器成功，并得到CSP句柄
printf("A new key container has been created.\n");
}
else
{
HandleError("Could not create a new key container.\n");
}
} // End of else
2 PKCS#11
2.1 函数
根据机制标记，可以分为几类：
CKF_ENCRYPT：加密类
CKF_DECRYPT：解密类
CKF_DIGEST：摘要类
CKF_SIGN：签名类
CKF_SIGN_RECOVER：可恢复签名类
CKF_VERIFY：验证类
CKF_VERIFY_RECOVER：可恢复验证类
CKF_GENERATE：密钥产生
CKF_GENERATE_KEY_PAIR：密钥对产生
CKF_WRAP：密钥封装
CKF_UNWRAP：密钥解封
CKF_DERIVE：密钥派生
2.2 操作
Cryptoki 为一个或多个密码设备提供一个接口，这些设备通过大量的槽在系统中运行。每个对应于一个物理阅读器或另一个设备接口的槽可包含一个令牌。当一台密码设备存在于阅读器中，一个令牌就存在于该槽中。当然，由于Cryptoki提供槽和令牌的逻辑视图，所以可能有其它的物理译码。多个槽可能共享一个阅读器。问题在于一个系统有相当多的槽，应用程序能连接到这些槽的其中任何一个或全部槽的令牌上。
密码设备可以按照某一命令集执行某些密码操作，这些命令通常要经过标准设备驱动程序，例如PCMCIA卡服务程序或槽服务程序。Cryptoki 使每个密码设备看起来逻辑上很象其它设备，而不管什么技术实现的。因此，应用程序不必直接与设备驱动器接口（或甚至不必知道包括那些设备）；Cryptoki 隐藏了这些细节。的确，基础设备完全能用软件来实现，（例如，在一个服务器上运行的处理程序），不须专用硬件。
Cryptoki 或许可以作为支持接口功能的库来实现，而应用程序则与该库连接。应用程序可以直接与Cryptoki 连接，或者，Cryptoki 是一个所谓的“共享”库（或动态连接库），在这种情况下，应用程序动态地连接库。用Microsoft Windows和OS/2操作系统可以比较容易地生成数据库，并且在UNIX和DOS中也可相对容易地生成“共享”库。
由于新库可以使用，所以动态方法有许多优点；但从安全的角度来说，也有一些缺点。要特别指出的是，如果库能较容易地被替换，攻击者有可能用恶意制造的假库取而代之，以截取用户的PIN。即使编码签名技术能防止许多动态连接的安全危险，从安全角度来说，一般采用直接连接。总之，应用程序和Cryptoki 库之间的程序设计接口是相同的。
设备的种类和所支持的能力的种类将取决于专用Cryptoki 库。本标准只定义库的接口，不定义库的特征。要特别指出的是，并不是所有的库支持这个接口（因为不是所有的令牌支持所有的机制）中定义的机制（算法）。并且库也许只支持可使用的所有密码设备的一个子集。（当然，可以预料更多更好的设备种类将被开发，以支持多种令牌，而不是单个供应商提供的令牌。）只要开发出应用程序，就会形成Cryptoki 的接口、标准数据库和令牌“轮廓”。
3 GM/T 0018-2012
3.1 简介
这个标准规定了基于PKI密码体制的智能密码钥匙密码应用接口，描述了密码应用接口的函数、数据类型、参数的定义和设备的安全要求。本标准的目标是为公钥密码基础设施应用体系框架下的服务类密码设备制定统一的应用接口标准，通过该接口调用密码设备，向上层提供基础密码服务。为该类密码设备的开发、使用及检测提供标准依据和指导，有利于提高该类密码设备的产品化、标准化和系列化水平。
3.2 范围
本标准规定了公钥密码基础设施应用技术体系下服务类密码设备的应用接口标准，适用于服务类密码设备的研制、使用，以及基于该类密码设备的应用开发，也可用于指导该类密码设备的检测。
3.3 结构模型
层次关系：智能密码钥匙密码应用接口位于智能密码钥匙应用程序与设备之间
设备的应用结构：一个设备中存在设备认证密钥和多个应用，应用之间相互独立。设备的逻辑结构如下图：
3.4 函数
访问控制系列函数
应用管理函数
容器管理系列函数
密码服务系列函数
3.5 安全要求
3.5.1 密钥管理要求
设备密钥的使用不对应用系统开放；
密钥必须用安全的方法产生并存储；
在任何时间、任何情况下，除公钥外的密钥均不能以明文形式出现在密码设备外；
密码设备内部存储的密钥应具备有效的密钥保护机制，防止解剖、探测和非法读取；
密码设备内部存储的密钥应具备权限控制机制，防止非法使用和导出。
3.5.2 密码服务要求
使用的密码算法应得到国家密码主管部门的批准；
使用国家密码主管部门认可的密码算法芯片；
本标准所列的所有接口函数均应能被应用系统任意调用。
3.5.3 设备状态要求
密码设备应具有初始和就绪两个状态；
未安装设备密钥的密码设备应处于初始状态，已安装设备密钥的密码设备应处于就绪状态；
在初始状态下，除可读取设备信息、设备密钥的生成或恢复操作外，不能执行任何操作，生成或恢复设备密钥后，密码设备处于就绪状态;
在就绪状态下，除设备密钥的生成或恢复操作外，应能执行任何操作；
在就绪状态下进行的密钥操作，设备操作员应经过密码设备的认证。
3.5.4 其他要求
密码设备应有安全机制和措施，保证密钥在生成、安装、导入、存储、备份.恢复及销毁整个生存期间的安全,此安全机制可由设备厂商自行设计实现
4 调用不同接口的代码
PKCS#11
SKF
