实验一-密码引擎-加密API研究

0 、查找各种标准的原始文档，研究学习（至少包含Crypto API,PKCS#11,GMT 0016-2012,GMT 0018-2012）

（1）Crypto API：

作为一部分 Microsoft Windows 提供的应用程序编程接口 (API)，CryptoAPI 提供了一组函数。这些函数允许应用程序在对用户的敏感私钥数据提供保护时，以灵活的方式对数据进行加密或数字签名。实际的加密操作是由称为加密服务提供程序 (CSP) 的独立模块执行。

CryptoAPI是一组函数，为了完成数学计算，必须具有密码服务提供者模块（CSP）。Microsoft通过捆绑RSA Base Provider在操作系统级提供一个CSP，使用RSA公司的公钥加密算法，更多的CSP可以根据需要增加到应用中。事实上，CSP有可能与特殊硬件设备（如智能卡）一起来进行数据加密。CryptoAPI接口允许简单的函数调用来加密数据，交换公钥，散列一个消息来建立摘要以及生成数字签名。它还提供高级的管理操作，如从一组可能的CSP中使用一个CSP。此外，CryptoAPI还为许多高级安全性服务提供了基础，包括用于电子商务的SET，用于加密客户机/服务器消息的PCT，用于在各个平台之间来回传递机密数据和密钥的PFX，代码签名等等。

（2）PKCS#11：

在密码系统中，PKCS#11是公钥加密标准（PKCS, Public-Key Cryptography Standards）中的一份子 ，由RSA实验室(RSA Laboratories)发布[1]，它为加密令牌定义了一组平台无关的API ，如硬件安全模块和智能卡。

PKCS#11标准定义了与密码令牌（如硬件安全模块（HSM）和智能卡）的独立于平台的API，并将API本身命名为“Cryptoki”（来自“加密令牌接口”，发音为“crypto-key” - 但是“PKCS#11”通常用于指代API以及定义它的标准）。 API定义了最常用的加密对像类型（RSA密钥，X.509证书，DES / 三重DES密钥等）以及使用，创建/生成，修改和删除这些对象所需的所有功能。

（3）GMT 0016-2012：

本标准规定了基于PKI密码体制的智能密码钥匙密码应用接口，描述了密码应用接口的函数、数据类型、参数的定义和设备的安全要求。
本标准适用于智能密码钥匙产品的研制、使用和检测。

（4）GMT 0018-2012：

本标准规定了公钥密码基础设施应用技术体系下服务类密码设备的应用接口标准，
本标准适用于服务类密码设备的研制使用，以及基于该类密码设备的应用开发，也可用于指导该类密码设备的检测

1、总结这些API在编程中的使用方式

（1）Crypto API

使用CryptoAPI编写一个文件保护程序，具有如下功能：

（1）给定明文文件，生成加密文件，同时产生文件的数字签名文件；

（2）给定密文文件，解密出明文文件，并验证签名的正确性。

在不安全的网络上进行安全的数据传输涉及三个方面的要求：信息隐藏，身份鉴别和完整性检验。CryptoAPI除了提供上述三个功能外还提供标准的ASN.1编码、解码，信息解密，数字证书和证书存储区的管理，证书信任列表、吊销列表和证书有效性检查等功能。

信息隐藏

信息隐藏的意义是保障信息内容只能被特定的人获取。信息隐藏通常是使用某种形式的密码学方式。数据加密算法能保障信息的安区隐藏和传输。数据加密算法是将明文数据经过一定的变换使其看上去是一组毫无意义的数据。在没有加密密钥的情况下，对于好的加密算法想从密文获取明文信息是不可能的。被加密的数据可以是任意的ASCII编码文本文件，数据库文件，和任意需要进行安全传输的数据。这里，“信息”是指任意的一段数据，“明文”是指任意一段没有被加密的数据，“密文”是指任意一段加密的数据。被加密的数据可以在不安全的通道上进行传输而不伤害其安全性。之后，密文可以被还原成明文.

数据加密和解密的概念是：对数据加密的时候需要一个加密密钥，相当于门上的一把钥匙。解密的时候，需要使用一个解密密钥来解开数据。加密密钥、解密密钥可以相同也可以不相同。

加密密钥必须小心保存，给其它用户的时候也必须通过安全的通道传递。对解密密钥的访问权限必须小心控制，因为拥有解密密钥意味着可以解开所有相应加密密钥加密的信息。

身份鉴别

安全通讯的前提是通讯的双方知道对方的身份。身份鉴别的任务就是鉴别一个用户或者实体的真实身份。标识用户身份的文档通常被称为信任状或者凭证。

身份鉴别有时候也用来判定接受的数据就是被发送的数据。如果A向B发送了一段数据，B需要鉴别这段数据就是A发出去的，而不是其它冒充A发出去的。为了满足这类验证的需求，CryptoAPI提供数字签名和校验函数，用来对信息进行鉴别。

因为在计算机网网络上传输的数据与用户之间并没有物理连接，因此对数据进行鉴别的凭证也必须能够在网络上进行传输。这种凭证必须由受信任的凭证发行机构发行。

数字证书就是平常说的证书就是这种凭证，是计算机在网络上进行身份验证的有效凭证。

数字证书是由一个被称为证书机构的信任组织或实体颁发的凭证。它包含与证书对应的用户公钥以及其它一些记录证书主题和用户信息的数据。证书机构只有在验证了证书主题和证书对应的用户公钥的有效性之后才会签发证书。

证书申请者和证书机构之间交换签发证书信息可以使用物理介质，比如软盘，进行传输。通常，这种信息都是在计算机网络上进行完成的。证书机构使用被信任的服务程序处理用户的请求和证书的签发工作。

完整性检测

任何通过不安全介质传输的信息都可以被意外或蓄意的修改。在现实世界中，盖章、签名就是用来提供和证明信息完整性的工具。

信息的接收者不但需要确定信息是由谁发送的，还要确定自己收到的信息是发送者发送的信息，而没有任何的变化。要建立数据的完整性检测机制，不仅要发送信息本身，还要发送用来校验数据的信息，这一信息通常被称作哈希值。数据和验证信息都可以与数字签名一起发送来证明其完整性。

PKCS#11

架构

会话状态

对象

机制

根据机制标记，可以分为几类：
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：密钥派生

操作

Cryptoki 为一个或多个密码设备提供一个接口，这些设备通过大量的槽在系统中运行。每个对应于一个物理阅读器或另一个设备接口的槽可包含一个令牌。当一台密码设备存在于阅读器中，一个令牌就存在于该槽中。当然，由于Cryptoki提供槽和令牌的逻辑视图，所以可能有其它的物理译码。多个槽可能共享一个阅读器。问题在于一个系统有相当多的槽，应用程序能连接到这些槽的其中任何一个或全部槽的令牌上。

密码设备可以按照某一命令集执行某些密码操作，这些命令通常要经过标准设备驱动程序，例如PCMCIA卡服务程序或槽服务程序。Cryptoki 使每个密码设备看起来逻辑上很象其它设备，而不管什么技术实现的。因此，应用程序不必直接与设备驱动器接口（或甚至不必知道包括那些设备）；Cryptoki 隐藏了这些细节。的确，基础设备完全能用软件来实现，（例如，在一个服务器上运行的处理程序），不须专用硬件。

Cryptoki 或许可以作为支持接口功能的库来实现，而应用程序则与该库连接。应用程序可以直接与Cryptoki 连接，或者，Cryptoki 是一个所谓的“共享”库（或动态连接库），在这种情况下，应用程序动态地连接库。用Microsoft Windows和OS/2操作系统可以比较容易地生成数据库，并且在UNIX和DOS中也可相对容易地生成“共享”库。

由于新库可以使用，所以动态方法有许多优点；但从安全的角度来说，也有一些缺点。要特别指出的是，如果库能较容易地被替换，攻击者有可能用恶意制造的假库取而代之，以截取用户的PIN。即使编码签名技术能防止许多动态连接的安全危险，从安全角度来说，一般采用直接连接。总之，应用程序和Cryptoki 库之间的程序设计接口是相同的。

设备的种类和所支持的能力的种类将取决于专用Cryptoki 库。本标准只定义库的接口，不定义库的特征。要特别指出的是，并不是所有的库支持这个接口（因为不是所有的令牌支持所有的机制）中定义的机制（算法）。并且库也许只支持可使用的所有密码设备的一个子集。（当然，可以预料更多更好的设备种类将被开发，以支持多种令牌，而不是单个供应商提供的令牌。）只要开发出应用程序，就会形成Cryptoki 的接口、标准数据库和令牌“轮廓”。

令牌的逻辑视图

Cryptoki的令牌逻辑视图是一个能存储对象和能执行密码函数的设备。Cryptoki定义如下三个对象：数据、证书和密钥。数据对象由应用程序定义。一个证书对象存储一个证书。一个密钥对象存储一个密码密钥。密钥可以是一个公共密钥、一个私钥或是一个保密密钥，每个种类的密钥在专用机制中使用其的辅助型。令牌的这种逻辑视图如下图所示：

Ⅲ.GMT 0016-2012#

结构模型#

智能密码钥匙应用接口位于智能密码钥匙应用程序与设备之间

一个设备中存在设备认证密钥和多个应用，应用之间相互独立。

应用由管理员PIN、用户PIN、文件和容器组成，可以存在多个文件和多个容器。

每个应用维护各自的与管理员PIN和用户PIN相关的权限状态。

一个应用的逻辑结构如图所示

密码服务#

错误代码#

Ⅳ.GMT 0018-2012#

三、列出这些API包含的函数，进行分类，并总结它们的异同

Crypto API感觉更加易读，但是分类较为复杂；PKCS#11为拥有密码信息（如加密密钥和证书）和执行密码学函数的单用户设备定义了一个应用程序接口（API）。智能卡就是实现Cryptoki的典型设备。但Cryptoki定义了密码函数接口，但并未指明设备具体如何实现这些函数。而且Cryptoki只说明了密码接口，并未定义对设备来说可能有用的其他接口，如访问设备的文件系统接口，其API很全面，很模式化，读起来有点头晕。国密标准感觉挺复杂的，既具体地讲解了设备又分析了如何调用其接口进行加密解密，其API更侧重于设备，基本上都是基于设备进行开发。

四、调用不同接口的代码

Ⅰ.Crypto API

HCRYPTPROV hCryptProv;
HCRYPTHASH hCryptHash;
HCRYPTKEY hCryptKey;


CPAcquireContext(
    hCryptProv, NULL,
    MS_DEF_PROV,
    PROV_RSA_FULL,
    CRYPT_VERIFYCONTEXT
)//为应用程序创建一个上下文
    
CPCreateHash(
    hCryptProv,
    CALG_MD5,
    0,
    0,
    &hCryptHash
) //为应用程序创建一个上下文
    
static char szHash[]=”PISAHASHDATA”; //原始字符串
DWORD dwLen=strlen(szHash);
CPHashData(hCryptHash, (BYTE*)szHash, dwLen, 0);//散列输入的数据
CPDeriveKey(hCryptProv, CALG_RC2, hCryptHash, 0, &hCryptKey);//从一个数据散列中生成一个会话密钥，它保证生成的密钥互不相同

static char szEntry[]= “PISA2002”;
DWORD dwLenIn = strlen(szEntry);
DWORD dwLenOut=dwLenIn;
CPEncrypt(hCryptKey, 0, TRUE, 0, (BYTE*)szEntry, &dwLenOut, dwLenIn);//用来加密明文
CPDecrypt(hCryptKey, 0, TRUE, 0,(BYTE*)szEntry,&dwLenOut);//用来解密先前被加密的数据
CPDestroyKey(hCryptKey);//释放一个密钥句柄，释放后，句柄将无效，密钥将无法再被访问
CPDestroyHash(hCryptHash);//删除一个散列对象句柄
CPReleaseContext(hCryptProv, NULL);//释放CPAcquireContext.创建的上下文

Ⅱ.PKCS#11

CK_SESSION_HANDLE hSession;
CK_MECHANISM digestMechanism;
CK_ULONG ulStateLen;
CK_BYTE data1[] = {0x01, 0x03, 0x05, 0x07};
CK_BYTE data2[] = {0x02, 0x04, 0x08};
CK_BYTE data3[] = {0x10, 0x0F, 0x0E, 0x0D, 0x0C};
CK_BYTE pDigest[20];
CK_ULONG ulDigestLen;
CK_RV rv;

/* Initialize hash operation */
rv = C_DigestInit(hSession, &digestMechanism);//初始化消息杂凑计算操作，指定计算消息杂凑的算法
assert(rv == CKR_OK);

/* Start hashing */
rv = C_DigestUpdate(hSession, data1, sizeof(data1));//对多个分组的消息进行杂凑计算
assert(rv == CKR_OK);//返回成功或者失败

/* Find out how big the state might be */
rv = C_GetOperationState(hSession, NULL_PTR, &ulStateLen);//获取设备是否存在的状态
assert(rv == CKR_OK);//返回成功或者失败

/* Allocate some memory and then get the state */
pState = (CK_BYTE_PTR) malloc(ulStateLen);
rv = C_GetOperationState(hSession, pState, &ulStateLen);//获取设备是否存在的状态

/* Continue hashing */
rv = C_DigestUpdate(hSession, data2, sizeof(data2));//对多个分组的消息进行杂凑计算
assert(rv == CKR_OK);//返回成功或者失败

/* Restore state.  No key handles needed */
rv = C_SetOperationState(hSession, pState, ulStateLen, 0, 0);
assert(rv == CKR_OK);//返回成功或者失败

/* Continue hashing from where we saved state */
rv = C_DigestUpdate(hSession, data3, sizeof(data3));//对多个分组的消息进行杂凑计算
assert(rv == CKR_OK);//返回成功或者失败

/* Conclude hashing operation */
ulDigestLen = sizeof(pDigest);
rv = C_DigestFinal(hSession, pDigest, &ulDigestLen);
if (rv == CKR_OK) {
  /* pDigest[] now contains the hash of 0x01030507100F0E0D0C */
}//返回成功或者失败

Ⅲ.SKF接口

CK_FLAGS flags = 0;
CK_Dev_ID DevID;
CK_Dev_INFO DevInfo;

/* Block and wait for a slot event */
rv = SKF_WaitForSlotEvent(flags, &slotID, NULL_PTR);//等待设备的插拔事件
assert(rv == CKR_OK);//返回成功或者失败

/* See what’s up with that slot */
rv = SKF_GetDevInfo(slotID, &slotInfo);//获取设备的一些特征信息
assert(rv == CKR_OK);//返回成功或者失败