标签：建立   底层实现   体系   导出   接收   oca   开发者   多个   版本   

CryptoAPI概述

Windows CryptoAPI是Microsoft 公司提出的安全加密应用服务框架，也是PKI推荐使用的加密 API。它提供了在Win32 环境下使用认证、编码、加密和签名等安全服务时的标准加密接口，用于增强应用程序的安全性与可控性。应用开发者可以在不了解复杂的加密机制和加密算法的情况下，简便、快速地开发出标准、通用和易于扩展的安全加密应用程序。CryptoAPI 提供的功能主要有：密钥管理、数据加密和解密、数字签名和验证、证书管理、可信根证书管理、数据编码和解码、数字证书编码和解码、PKCS#7 标准格式编码和解码等。现在CryptoAPI的最新版本为2.0版本。

微软加密服务体系

微软加密服务体系包含3层结构和两个接口，分别为应用程序层、操作系统层（OS）、加密服务提供者层（Cryptographic Service Provider，CSP）、CryptoAPI接口和加密服务提供者接口（CSPI），其结构图如下图所示。应用程序层通过CryptoAPI接口与操作系统通信，操作系统通过加密服务提供者接口（CSPI）与CSP通信。其编程模型同Windows系统的图形设备接口 GDI比较类似，其中加密服务提供者CSP等同于图形设备驱动程序 ，加密硬件（可选）等同于图形硬件，其上层的应用程序也类似，都不需要同设备驱动程序和硬件直接打交道。CryptoAPI接口面向应用系统，而CryptoSPI 面向加密模块开发商，CryptoAPI 统一由Windows 提供，而底层的CSP由各开发商提供。这样的分层体系结构，使应用系统不必关心底层的加密实现细节和实现方式(软件或硬件)，降低了集成难度，并且在一个系统中可以同时加载多个CSP。同时微软公司为开发商制定了CSP 的标准接口，开发商按照标准开发CSP，就可以把自己开发的软件或硬件加密模块紧密集成进CryptoAPI 的体系中。

微软加密服务体系

在微软加密服务体系中，加密服务相关的所有操作都在CSP实现，它是真正实行加密相关服务的独立模块，既可以由软件实现也可以由硬件实现，但是必须符合CryptoAPI接口的规范。每个CSP必须包含有一个动态链接库和一个签名文件，签名文件用于保证底层的CSP 的安全性，CryptoAPI 接口在加载每个CSP 时，需要验证CSP 的签名，如果签名无效，则拒绝加载，CSP 的签名由微软公司签发。同时，每个CSP都有一个名字和一个类型，名字必须唯一的，这样便于CryptoAPI找到对应的CSP。加密服务标准被分为不同的家族，每种家族包含自己的一系列数据格式和协议，不同的家族有不同的数据格式或协议等。在CryptoAPI中，每种CSP类型代表不同的家族。目前已经有9种CSP类型，并且还在增长，不同类型支持的密钥交换算法、签名算法、对称加密算法和Hash算法等如下表所示。

CryptoAPI体系架构

CryptoAPI体系架构共由五大主要部分组成：基本CSP函数（Base Cryptographic Functions）、证书编解码函数（Certificate Encode/Decode Functions）、证书库管理函数（Certificate Store Functions），简单消息函数（Simplified Message Functions）、底层消息函数（Low-level Message Functions）。其结构图如下图所示。

CryptoAPI体系架构

基本加密函数：用于选择CSP、建立CSP连接、产生密钥、交换及传输密钥等操作。这些函数为开发加密应用程序提供了足够灵活的空间。所有CSP 的通讯都是通过这些函数，一个CSP 是实现所有加密操作的独立模块，于是在每一个加密应用程序中至少需要提供一个CSP来完成所需的加密操作。

证书编/解码函数：用于数据加密、解密、哈希等操作。这类函数支持数据的加密/解密操作；在应用程序中完成计算哈希、创建和校验数字签名操作；用来对证书、证书撤销列表、证书请求和证书扩展进行编码和解码操作。

证书库管理函数：用于数字证书及证书库管理等操作。这组函数用于管理证书、证书撤销列表和证书信任列表的使用、储存、获取等。

简单消息函数：用于消息处理，比如消息编码/解码、消息加/解密、数字签名及签名验证等操作。它是把多个低层函数包装在一起以完成某个特定任务，以方便用户的使用。

底层消息函数：低级消息函数对传输的PKCS#7 数据进行编码，对接收到的PKCS#7 数据进行解码，并且对接收到的消息进行解密和验证。它可以实现简单消息函数可以实现的所有功能，它提供更大的灵活性，但一般会需要更多的函数调用。对于绝大多数应用，我们不推荐使用低级消息函数，使用简化消息函数更为方便。

CryptoAPI基本功能

利用CryptoAPI，开发者可以给基于Windows的应用程序添加安全服务，包括: ASN.1编码及解码、数据加密/解密、身份论证、数字证书管理，同时支持PKI、对称密码技术等。应用程序开发者直接使用这些安全功能而无须了解其底层实现。

1. 加密密钥

密钥是密码体系操作的中心，它们必须安全保存，任何人获得某个密钥则对此密钥有关的任何数据都拥有了访问的权限。例如，某人得到了加密某文件的密钥，则他就可以解密此文件了。再比如，获取了对某消息签名的密钥，则可以伪造数字签名。

在CryptoAPI中，支持两种类型密钥：会话密钥、公/私密钥对。

会话密钥也称为对称密钥，用于对称加密算法，例如RC2、RC4、DES等。在CryptoAPI中，一般使用CryptGenKey 或 CryptDeriveKey函数产生会话密钥。为了保证密钥的安全性，这些密钥都保存在CSP内部。当然，用户也可以通过CryptExportKey函数把密钥以加密密钥块形式导出到具体应用空间内，以备以后使用或传输给其他用户。

公/私密钥对（包括公钥、私钥）用于非对称加密算法，例如RSA等。非对称加密算法主要用于加解密会话密钥和数字签名。在CryptoAPI中，一般来说，大多数 CSP产生的密钥容器包含两对密钥对，一对用于加密会话密钥，称为交换密钥对，一对用于产生数字签名，称为签名密钥对；但也有些CSP没有存储密钥对，或者存储不止两对密钥对。

在CryptoAPI中，所有的密钥都存储在CSP，CSP负责产生、销毁密钥，并使用它们完成各种密码操作。也可以利用CryptoAPI函数从CSP中导出密钥。

2. 数据编码/解码

通过通信媒介（例如电话线路）传输数据，必须先把数据序列化，即把数据转化为0、1串。在序列化操作中，接到数据的计算机必须能够把数据转化为其原始格式。序列化完成的操作规则称为通信协议，它由软件和数据传输硬件共同完成，其协议一般包含多层，图3-3为一个简化了的通信协议层。

下图表示：计算机1应用程序层先传输原文数据到编码/解码层，编码/解码层编码原文数据为计算机字节流，然后发送到硬件层，硬件层把字节流数据转化为0、1串流传输到计算机2。计算机2接到数据后，反向操作，转化0、1串流为计算机字节流，发送到编码/解码层，编码/解码层解码计算机字节流为原文数据。

一种可接受的软件设计原理是使用抽象化，即根据问题或对象的一般参数来描述，而不是要描述解决问题的所有细节或对象的所有细节。利用抽象化，设计者说明软件对象的特定性质而不必关心其具体实现，它简化了说明文档。抽象化是大多数现代软件规范的特点，并且多数通信协议都包含一些列的抽象化。

简化通信协议层

描述抽象对象的一个普遍方式为：ASN.1（抽象语法标记1），ASN.1在CCITT推荐文件X.208中定义，描述对象转换为0、1串的ASN.1规则称为DER（精确编码规则），在CCITT推荐文档X.509 8.7节定义。CryptoAPI采用的就是这种编码方式，表示数据发送方发送时先把数据抽象为ASN.1对象，然后使用DER编码规则把ASN.1对象转化为可传输的0、1串；接收方接到数据后，利用DER解码规则把0、1串转化为ASN.1对象，然后再把ASN.1对象转化为具体应用支持的数据对象。

3. 数据加/解密

把明文转化为密文的过程称为加密，反之把密文转化为明文的过程称为解密。加密较大的数据，CryptoAPI中约定用对称加密算法，这种算法中，在加密和解密过程中都使用同一个对称密钥或会话密钥。CryptoAPI中，通过其封装好的加解密函数来实现数据加解密操作，不同CSP提供不同的加解密算法，但常用的算法，一般CSP都提供。

4. 哈希与数字签名

哈希与数字签名一般用于确定数据的完整性和身份鉴别。CryptoAPI中，通过其封装好的哈希与数字签名函数来实现相关操作。微软提供的CSP产生的数字签名遵循RSA标准（PKCS#6），其他CSP可能遵循其他标准。

5. 数字证书

数字证书主要用于安全通信中的身份鉴别。CryptoAPI中，对数字证书的使用管理分为证书与证书库函数、证书验证函数。

6. 数字消息

任何被编码的数据都可称为消息，它是发送给其他人或实体（或从其他人或实体接收到）的编码数据，包括数字证书。在CryptoAPI环境中，消息一般会被签名或加密，或者同时被签名和加密。在CryptoAPI2.0版本中，消息处理函数一般分为两类：底层消息函数，简单消息函数。低级消息函数直接和PKCS#7 消息工作，简化消息函数是比较高级的函数，是对几个低级消息函数和证书函数的封装，用来执行指定任务。

下篇文章介绍如何使用CryptoAPI进行文件加解密，把我那烂代码拿出来给大家看。

[加密解密]CryptoAPI简介

标签：建立   底层实现   体系   导出   接收   oca   开发者   多个   版本   

原文地址：http://www.cnblogs.com/testlife007/p/7058740.html