硬件加密引擎的实现方法

专利名称：硬件加密引擎的实现方法
技术领域：
本发明属于信息安全技术领域，尤其涉及一种硬件加密引擎的实现方法。
背景技术：
SSL是Secure Socket Layer的英文缩写，意思是安全套接层协议，指使用公钥和 私钥技术组合的安全网络通讯协议。SSL协议是网景公司(Netscape)推出的基于TOB应 用的安全协议，SSL协议指定了一种在应用程序协议(如Http、Telenet, NMTP和FTP等) 和TCP/IP协议之间提供数据安全性分层的机制，它为TCP/IP连接提供数据加密、服务器认 证、消息完整性以及可选的客户机认证，主要用于提高应用程序之间数据的安全性，对传送 的数据进行加密和隐藏，确保数据在传送中不被改变，即确保数据的完整性。SSL以对称密码技术和公开密码技术相结合，可以实现如下三个连接目标
(1)秘密性SSL客户机和服务器之间传送的数据都经过了加密处理，网络中的非 法窃听者所获取的信息都将是无意义的密文信息。(2)完整性SSL利用密码算法和散列(HASH)函数，通过对传输信息特征值的提取 来保证信息的完整性，确保要传输的信息全部到达目的地，可以避免服务器和客户机之间 的信息受到破坏。(3)认证性利用证书技术和可信的第三方认证，可以让客户机和服务器相互识 别对方的身份。为了验证证书持有者是其合法用户(而不是冒名用户)，SSL要求证书持有 者在握手时相互交换数字证书，通过验证来保证对方身份的合法性。The Public-Key Cryptography Standards (PKCS)是由美国 RSA 数据安全公司 及其合作伙伴制定的一组公钥密码学标准，其中包括证书申请、证书更新、证书作废表发 布、扩展证书内容以及数字签名、数字信封的格式等方面的一系列相关协议。PKCS#11称为 Cyptoki，定义了一套独立于技术的程序设计接口，用于智能卡和PCMCIA卡之类的加密设 备。OpenSSL项目是一个开源代码的安全项目，目标是用强大的加密算法来实现安全 的 Socket 层(Secure Sockets Layer, SSLv2/v3)和传输层的安全性(Transport Layer Security, TLS vl)。它包含了完整的加密算法，数字签名算法及证书签名算法等。可以很 好的保证数据的完整性、保密性和正确性。引擎(Engine)机制的目的是为了使OpenSSL能够透明地使用第三方提供的软件 加密库或者硬件加密设备进行加密。OpenSSL的Engine机制成功地达到了这个目的，这使 得OpenSSL已经不仅仅是一个加密库，而且还是一个通用的加密接口，能够与绝大部分加 密库或加密设备协调工作。

发明内容
本发明的目的在于，提供一种硬件加密引擎的实现方法，为用户提供一个用以添 加硬件加解密算法的接口。
一种硬件加密引擎的实现方法，上层应用程序通过调用所述硬件加密引擎的引擎绑定接口、密钥初始化接口、数据加解密接口、引擎释放接口来实现，所述方法包括引擎绑定接口被上层应用程序调用时，硬件加密引擎与硬件加密设备建立连接， 获取所述硬件加密设备的算法列表，并填充第一数据结构；密钥初始化接口被上层应用程序调用时，所述硬件加密引擎根据传入的所述第一 数据结构设置所述硬件加密设备当前所要使用的加解密算法，并检索相应的算法密钥，如 果检索不到，则控制所述硬件加密设备创建所述算法密钥；数据加解密接口被上层应用程序调用时，所述硬件加密引擎根据当前设置的加解 密算法和算法密钥，控制所述硬件加密设备对传入的数据进行加/解密操作，并输出操作
结果；引擎释放接口被上层应用程序调用时，所述硬件加密引擎结束与所述硬件加密设 备的连接。所述硬件加密设备包括智能密钥设备或加密机。所述引擎绑定接口、密钥初始化接口、数据加解密接口、引擎释放接口具体为 bind—engine 接口、init 接口、do_cipher 接口、clean—up 接 口。所述硬件加密引擎与所述硬件加密设备通过硬件加密接口建立连接；其中，所述硬件加密接口包括密码令牌接口或加密服务提供程序接口。所述第一数据结构具体为EVP_CIPHER数据结构，所述EVP_CIPHER数据结构是上 层应用程序中已定义的。所述填充第一数据结构具体为所述硬件加密引擎根据所述获取的算法列表和init接口、decipher接口和 clean_up接口的指针来填充传入的EVP_CIPHER数据结构。根据所述获取的算法列表和init接口、decipher接口和cleanup接口的指针 来填充传入的EVP_CIPHER数据结构具体为根据上层应用程序中已有的定义，在EVP_CIPHER数据结构中为所述算法列表中 的任一加解密算法设置对应的算法ID号；根据所述算法列表中的数值，在EVP_CIPHER数据结构中为密钥长度、密钥分组长 度、初始向量长度设置对应的数值，并为init接口、do_cipher接口、clean_up接口指针设 置对应的函数指针。所述硬件加密引擎根据传入的所述第一数据结构设置所述硬件加密设备当前所 要使用的加解密算法，并检索相应的算法密钥，如果检索不到，则控制所述硬件加密设备创 建所述算法密钥具体为密钥初始化接口被上层应用程序调用时，所述填充后的EVP_CIPHER数据结构传 入所述硬件加密引擎；所述硬件加密引擎根据所述传入的EVP_CIPHER数据结构中的算法指针获取第一 加解密算法ID，所述第一加解密算法ID对应的加解密算法为上层应用程序中的算法；所述硬件加密设备根据预设的映射关系，获取与所述第一加解密算法ID对应的 第二加解密算法ID，所述第二加解密算法ID对应的加解密算法为所述硬件加密设备中的 算法；
所述硬件加密引擎在所述硬件加密设备中的密钥信息集合中，查找所述第二加解密算法ID，如果能查找到，则将所述第二加解密算法ID对应的密钥句柄存储到EVP_CIPHER 数据结构的上下文中，如果查找不到，则控制所述硬件加密设备创建所述第二加解密算法 密钥，并将所述第二加解密算法密钥的密钥信息添加到密钥信息集合中；所述第二加解密算法为所述硬件加密设备当前所要使用的加解密算法。所述算法指针是由上层应用程序在EVP_CIPHER数据结构的算法列表中选定的。所述预设的映射关系是由上层应用程序创建的，是将算法参数一致的所述硬件加 密设备中的加解密算法和上层应用程序中的加解密算法建立一一对应的映射关系；其中，算法参数具体是指密钥长度、密钥分组长度、初始向量长度。所述密钥信息包括密钥句柄、密钥值、密钥标签。所述硬件加密引擎根据当前设置的加解密算法和算法密钥，控制所述硬件加密设 备对传入的数据进行加/解密操作，并输出操作结果具体为数据加解密接口被上层应用程序调用时，从传入的所述上下文中查找得到所述硬 件加密设备当前所要使用的加解密算法的密钥句柄；所述硬件加密引擎控制所述硬件加密设备根据所述查找得到的密钥句柄对传入 的数据进行加/密操作，并输出操作结果。所述加解密操作包括分组链接加解密模式和电子密码本加解密模式。本发明的效果在于通过硬件加密引擎，将一些硬件加解密算法，尤其是一些未公 开的，只能用硬件实现的加解密算法添加扩展到软件算法库中。


图1是硬件加密设备的加解密算法与OpenSSL库中的加解密算法的映射关系示意 图；图2是硬件加密设备的加解密算法传入引擎得到引擎的加解密算法示意图；图3是OpenSSL接口中的加解密算法列表值赋值给引擎的加解密算法的指针示意 图；图4是返回与硬件加密设备的加解密算法相对应的OpenSSL库中的加解密算法示 意图；图5是引擎绑定流程图；图6是获取PKCS#11接口动态库中的加解密算法流程图；图7是分包加解密流程图；图8是另一种引擎绑定流程图；图9是获取CSP接口动态库中的加解密算法流程图；图10是一种分包加解密流程图。
具体实施例方式下面结合附图，对优选实施例作详细说明。应该强调的是，下述说明仅仅是示例性 的，而不是为了限制本发明的范围及其应用。实施例1
在引擎被调用之前，先在引擎中建立硬件加密设备的加解密算法与OpenSSL接口中的加解密算法的映射关系。图1是硬件加密设备的加解密算法与OpenSSL接口中的加解 密算法的映射关系示意图。图1中，硬件加密设备的加解密算法与OpenSSL接口中的加解密 算法的映射关系具体是将硬件加密设备中的加解密算法和OpenSSL接口中的加解密算法 中算法参数一致的加解密算法作为具有映射关系的加解密算法。算法参数包括密钥长度、 分组长度、初始向量长度。图2是硬件加密设备的加解密算法传入引擎得到引擎的加解密算法示意图。图2 中，引擎中会创建加密对象，用于存储与加解密算法相关的信息。在引擎被调用加载后，硬 件加密设备中的加解密算法，会传入引擎中的对称加密对象中，从而实现硬件加密设备的 加解密算法传入引擎，得到引擎的加解密算法。之后，获取引擎的加解密算法的指针、OpenSSL接口中的加解密算法列表值和各加 解密算法ID。判断引擎的加解密算法的指针是否为空，如果引擎的加解密算法的指针为空， 则说明引擎中传入的硬件加密设备的加解密算法的指针为空，此时将OpenSSL接口中的加 解密算法列表值赋值给引擎的加解密算法的指针，并返回OpenSSL接口中的加解密算法列 表值。图3是OpenSSL接口中的加解密算法列表值赋值给引擎的加解密算法的指针示意 图。图3中，当引擎的加解密算法的指针为空时，因为引擎的加解密算法存储的是硬件加密 设备的加解密算法，所以引擎的加解密算法的指针为空说明，硬件加密设备中没有加解密 算法。此时，将OpenSSL接口中的加解密算法列表值赋值给引擎的加解密算法的指针，在引 擎的加解密算法被调用时，引擎会根据被赋值的指针，调用OpenSSL接口中的加解密算法。如果引擎的加解密算法的指针不为空，则根据硬件加密设备的加解密算法与 OpenSSL接口中的加解密算法的映射关系和算法ID，返回与硬件加密设备的加解密算法相 对应的OpenSSL接口中的加解密算法。图4是返回与硬件加密设备的加解密算法相对应的 OpenSSL接口中的加解密算法示意图。图4中，引擎的加解密算法的指针不为空时，说明硬 件加密设备中包含加解密算法，此时根据硬件加密设备的加解密算法与OpenSSL接口中的 加解密算法的映射关系和算法ID，找到与硬件加密设备的加解密算法对应的OpenSSL接口 中的加解密算法，返回该OpenSSL接口中的加解密算法，即将OpenSSL接口中的加解密算法 存储在引擎的对称加密对象中。这样，引擎的对称加密对象中，存储的就是与硬件加密设备 中的加解密算法有映射关系的OpenSSL接口中的加解密算法了。实施例2引擎是OpenSSL预留的用于加载第三方加密库的，主要包括了动态库加载的代码 和加密函数指针管理的一系列接口。要使用引擎，OpenSSL首先会加载该引擎，并选择要使 用的算法或者使用支持的所有加解密算法，这样应用程序在调用加解密函数时，就会指向 所加载的第三方加密库中的加解密算法，而不是原先的OpenSSL的libeay32. dll库里的加 解密算法，引擎的主要原理是使用第三方加密库中的函数指针或硬件加密设备的接口指针 来替换OpenSSL中默认的加解密函数，从而实现动态加载第三方加密库。在本实施例中，所述硬件加密引擎通过硬件加密接口 PKCS#11(密码令牌)接口动 态库(当然，也可以是硬件加密接口 CSP接口动态库)与硬件加密设备进行连接，以完成数 据加解密操作，所述PKCS#11接口动态库由硬件加密设备的开发者提供，所述硬件加密设 备包括客户端的智能密钥设备(如USB KEY)，服务端的加密机等；PKCS#11接口动态库的内部细节不在本发明描述的范围。 本发明提供的硬件加密引擎通过注册在OpenSSL接口中的bincLengine ()、 init()、do_cipher()和clean_up()等四个函数实现。其中，引擎绑定接口 bind_engine () 用于绑定引擎；密钥初始化接口 initO用于获取硬件加密接口动态库中的加解密算法并 初始化密钥及密钥信息；数据加解密接口 decipher ()用于进行数据的分包加密或解密操 作；引擎释放接口 ClearuupO用于释放引擎。 下面以标准C语言编程为例，并结合PKCS#11接口动态库与OpenSSL接口来说明 本发明中硬件加密引擎(以下简称引擎)的实现过程。如图5所示，当bincLengine ()接口被上层应用程序OpenSSL接口调用时，硬件加 密引擎执行如下操作步骤101、引擎加载PKCS# 11接口动态库。优选地，本步骤通过调用计算机的系统函数IoadlibraryO来完成，该PKCS#11接 口动态库的文件名是预先约定的。步骤102、引擎获取PKCS#11接口动态库的函数列表。优选地，本步骤通过调用PKCS#11接口中的C_GetFunctionList()函数完成；进一步地，本步骤还可以先通过调用计算机系统函数GetProcAddress ()尝试 获取PKCS#11接口中的C_GetFunctionList()函数在PKCS#11接口的入口点，调用C_ GetFunctionListO函数成功后，就可获得其他PKCS#11接口的入口点，并且能够调用这些 接口获得PKCS#11接口动态库的函数列表；如果尝试失败，则报错返回。具体地，PKCS#11接口动态库的函数列表可以是CK_FUNCTION_LIST_PTR。需要说明的是，PKCS#11接口动态库的函数列表包含PKCS#11接口动态库中函数 指针的指针。步骤103、引擎通过调用PKCS#11接口动态库中定义的函数CJnitializeO来初 始化PKCS#11接口动态库。具体地，调用PKCS#11接口动态库中定义的函数CJnitializeO是通过步骤102 中获取的PKCS#11接口动态库的函数列表中函数CJnitializeO指针的指针来实现的。需要说明的是，根据PKCS#11接口的规范标准，在进行其他操作之前必须要首先 调用该 C_Initialize()接口。步骤104、引擎创建并启动一个监控线程，用于监控硬件加密设备的插拔事件，并 将硬件加密设备的插拔状态存储在自定义的数据结构中。优选地，监控硬件加密设备的插拔事件(硬件加密设备的插入或拔除)是通过调 用PKCS#11接口动态库中定义的函数C_WaitF0rSl0tEvent ()来实现的，并根据监控到的插 拔状态来及时更新自定义数据结构。其中，调用PKCS#11接口动态库中定义的函数C^WaitForSlotEventO具体是通过步骤102中获取的PKCS#11接口动态库的函数列表中函数C_WaitForSlotEvent()指针的 指针来实现调用的。具体地，自定义数据结构是指槽列表信息的集合，其中，槽列表信息包含硬件加密设备的插拔状态信息。具体地，PKCS#11接口动态库中定义的槽列表信息数据结构中包含槽描述、制造商ID、性能标识符、硬件序列号、固件序列号等信息。步骤105、引擎获取槽列表信息，得到硬件加密设备的插拔状态。优选地，引擎获取槽列表信息通过调用PKCS#11接口动态库中定义的函数C_GetSlotListO来实现，得到硬件加密设备的插拔状态，并获取当前连接到主机的硬件加密 设备句柄，如果当前存在多个硬件加密设备连接到主机，则选择所述列表中的第一个硬件 加密设备。具体地，调用PKCS#11动态库中定义的函数C_GetSlotList()是通过步骤102中 获取的PKCS#11接口动态库的函数列表中函数C GetSlotListO指针的指针来实现调用 的。步骤106、引擎与硬件加密设备建立连接，以便对硬件加密设备进行操作。优选地，引擎与硬件加密设备建立接连是通过调用PKCS#11接口动态库中定义的 函数C_0penSession()来实现的。具体地，调用PKCS#11接口动态库中定义的函数C_0penSeSSiOn()是通过步骤102 中获取的PKCS#11接口动态库的函数列表中函数c_0pensession()指针的指针来实现调用 的。需要说明的是步骤105中，获取槽列表信息中硬件加密设备的插拔状态是为了 能及时告知引擎该硬件加密设备的当前状态，如果，硬件加密设备被拔除，则引擎及时关闭 与硬件加密设备的会话，如果，硬件加密设备被插入，则及时引擎开启与硬件加密设备的会 话，以便提高工作效率，同时，避免了引擎在使用硬件加密设备时临时开启会话，而硬件加 密设备是拔除状态，从而造成错误情况的出现。步骤107、引擎通过ENGINE_new()函数来创建一个空的引擎对象engine。其中， ENGINE_new ()函数是OpenSSL接口中已定义的。步骤108、引擎为引擎对象engine设置id及名称，例如ENGINE_set_ id (engine, ，，rtl8651b，，)，ENGINE_set_name (engine, " BSDrtl8651b engine，，)。步骤109、引擎获取硬件加密设备的算法列表；具体地，通过调用PKCS#11接口中的C_GetMechanismList来获取算法列表；例如，取得的算法列表是{CKM_SHA_1,{0，0，CKF_DIGEST}}，{CKM_DES_ECB,{8,8,CKF_ENCRYPT|CKF_DECRYPT|CKF_WRAP|CKF_UNWRAP}}，{CKM_DES_CBC，{8,8,CKF_ENCRYPT|CKF_DECRYPT|CKF_WRAP|CKF_UNWRAP}}，{CKM_DES3_ECB， {24，24，CKF_ENCRYPT|CKF_DECRYPT|CKF_WRAP|CKF_UNWRAP}}，{CKM_DES3_CBC， {24,24，CKF_ENCRYPT|CKF_DECRYPT|CKF_WRAP|CKF_UNWRAP}}，步骤110、引擎设置加解密对象的EVP_CIPHER数据结构，以便供上层OpenSSL应用
程序调用。其中，EVP_CIPHER数据结构的定义是OpenSSL中已有的，具体如下
struct evp_cipher_st{int nid ；int block_size ；int key_len ；/氺 Default value for variable length ciphers氺/int iv_len ；
unsigned long flags ；/氺 Various flags*/intOinit) (EVP_CIPHER_CTX氺ctx，const unsigned char氺key，const unsigned charint enc) ；/*init key*/int(*do_cipher)(EVP_CIPHER_CTX *ctx, unsigned char *out，const unsigned char 氺in, unsigned int inl) ；/^encrypt/decryptdata */int(*clean_up)(EVP_CIPHER_CTX*) ；/*clean_up ctx */int ctx_size ;/氺how big ctx->cipher_data needs to be 氺/int(*set_asnl_parameters)(EVP_CIPHER_CTX*，ASN1_TYPE*) ；/*Populate a ASN1_TYPE with parameters */int (*get_asnl_parameters)(EVP_CIPHER_CTX*，ASN1_TYPE*) ；/*Getparameters from a ASN1_TYPE */int (氺ctrl)(EVP_CIPHER_CTX氺，int type, int arg, void 氺ptr) ；/氺Miscellaneous operations 氺/void *app_data ;/*Application data 氺/} /*EVP_CIPHER */ ；typedef struct evp_cipher_st EVP_CIPHER ；nid 算法的 ID 号，在 include/openssl/object. h 中定义；block_size 加解密的分组长度key_len:密钥长度iv_len 初始向量长度flags 标志(*init)初始化函数，提供密钥，IV向量，算法上下文CTX，加密还是解密(*do_cipher)加解密函数，提供算法上下文CTX，输出数据，输入数据和输入 数据长度(*clean_up)资源释放ctx_size 各算法相关数据大小，实际就是各算法的密钥数据(氺set_asnl_parameters)设置 asnl 参数(氺get_asnl_parameters)获取 asnl 参数(*ctrl)其他控制操作app_data 算法相关数据其中，引擎设置EVP_CIPHER数据结构具体是通过ENGINE_set_ciphers()函数来 实现的，并根据OpenSSL的定义，设置对应的nid。
其中，ENGINE_set_ciphers函数的定义如下int ENGINE_set_ciphers(ENGINE *e，ENGINE_CIPHERS_PTR f)。e:引擎对象指针f 引擎中对称算法选取的回调函数f回调函数的定义如下typedef int(*ENGINE_CIPHERS_PTR)(ENGINE *e， const EVP_CIPHER**cipher， constint 氺氺nids， int nid)。e:引擎对象指针cipher :EVP_CIPHER 指针的指针nids是对称算法列表值(即int数组)nid是算法ID号，在获取引擎对象时传入的。具体地，引擎根据获取的算法列表来填充EVP-CIPHER数据结构；例如，算法列表中的{CKM_DES3_CBC，{24，24，CKF_ENCRYPT | CKF_ DECRYPT I CKF_WRAP | CKF_UNWRAP} }，表示智能密钥设备支持CBC (分组链接加密)模式的 3DES加解密操作，分组长度和密钥长度都是24字节。则，对应的EVP_CIPHER数据结构如 下{20，24，24，24，0&Encrypt_DES3_CBC_Init,&Encrypt_Update,&Encrypt_Final,sizeof (EVP_CIPHER_CTX),NULL,NULL,NULL,}其中，Encrypt_DES3_CBC_Init、Encrypt_Updata和 Encrypt_FiInal 是引擎内部 的接口，分别通过PKCS#11接口来完成加密操作。步骤111、引擎判断从bincLengineO接口传入的加解密算法指针cipher是否为 空，如果为空，则执行步骤112，否则，执行步骤113。具体地，根据bincLengine ()接口传入硬件加密设备的加解密算法，EVP_CIPHER 获得硬件加密设备的加解密算法，成为引擎的加解密算法；步骤112、引擎将OpenSSL接口中的加解密算法列表值赋值给引擎的加解密算法 指针cipher，并返回OpenSSL接口中的加解密算法列表长度。其中，所述加解密算法列表长度指的是加解密算法的数量。
当引擎的加解密算法的指针为空时，因为引擎的加解密算法存储的是硬件加密设 备的加解密算法，所以引擎的加解密算法的指针为空说明，硬件加密设备中没有加解密算 法。此时，将OpenSSL接口中的加解密算法列表值赋值给引擎的加解密算法的指针，在引擎 的加解密算法被调用时，引擎会根据被赋值的指针，调用OpenSSL接口中的加解密算法。步骤113、根据硬件加密设备的加解密算法与OpenSSL接口中的加解密算法的映 射关系和算法ID，找到与硬件加密设备的加解密算法对应的OpenSSL接口中的加解密算 法，返回该OpenSSL接口中的加解密算法。当引擎的加解密算法的指针不为空时，说明硬件加密设备中包含加解密算法，此 时根据硬件加密设备的加解密算法与OpenSSL接口中的加解密算法的映射关系和算法ID， 找到与硬件加密设备的加解密算法对应的OpenSSL接口中的加解密算法，返回该OpenSSL 接口中的加解密算法，即将OpenSSL接口中的加解密算法存储在引擎的对称加密对象中。 这样，引擎的对称加密对象中，存储的就是与硬件加密设备中的加解密算法有映射关系的 OpenSSL接口中的加解密算法了。在bincLengineO函数调用结束，init()函数被调用之前，OpenSSL接口还要执 行以下的操作=OpenSSL接口通过调用ENGINEjnit ()函数来初始化该引擎；OpenSSL接 口通过调用ENGINE_set_defaUlt_Ciphers()函数将引擎提供的加解密算法设置成为引擎 默认的加解密算法；OpenSSL接口从引擎中获取EVP_CIPHER对象和算法ID，并调用EVP_ Encryptlnit/EVP_Decryptlnit ()函数，转入引擎的 init ()函数。首先，需要知道的是，当init ()接口被上层OpenSSL应用程序调用时，传入init () 接口的参数有int (*init) (EVP_CIPHER_CTX*ctx，// 上下文const unsigned char 氺key,//对禾尔密 月值const unsined char 氺iv，//率刀女台向量int enc)；其中，initO函数中的上下文结构EVP_CIPHER_CTX如下struct evp_cipher_ctx_st{const EVP_CIPHER *cipher ；ENGINE 氺engine ；/氺 functional reference if，cipher，isENGINE-provided */int encrypt ；/氺 encrypt or decrypt 氺/int buf_len ；/氺 number we have left 氺/unsigned char oiv[EVP_MAX_IV_LENGTH] ；/氺 original iv */unsigned char iv[EVP_MAX_IV_LENGTH] ；working iv */unsigned char buf[EVP_MAX_BL0CK_LENGTH] ；/氺 saved partial block “int num ；used by cfb/ofb mode */void *app_data ；application stuff */int key_len ；May change for variable length cipher 氺/
unsigned long flags ；/氺 Various flags 氺/void 氺cipher—data ;/氺 per EVP data 氺/int f inal_used ；int block_mask ；unsigned char final[EVP_MAX_BLOCK_LENGTH] ；/* possible final block*/}/* EVP_CIPHER_CTX */;typedef struct evp_cipher_ctx_st EVP_CIPHER_CTX ；参数为cipher:算法指针engine:加解密引擎encrypt 加密或解密buf_len 剩余空间oiv:原始的初始向量iv:当前的初始向量buf 保存的部分块数据num :cfb/ofb方式时的数据数量app_data 应用相关数据key_len 密钥长度flags 标志cipher_data 各算法相关部分，主要是各算法的key等f inal_used block_mask 块的掩码final 最后的分组块如图6所示，则当init()接口被上层OpenSSL应用程序调用时，硬件加密引擎(以 下简称引擎)执行如下操作步骤201、从init()函数的上下文结构EVP_CIPHER_CTX中，获取与所述硬件加密 设备中加解密算法相对应的OpenSSL接口中的加解密算法ID，并记为第一算法ID。具体地，通过上下文结构EVP_CIPHER_CTX中的ctx->cipher_>nid变量来获取该
第一算法ID。其中，上下文结构中的CtX->Cipher->nid变量是由引擎获取的cipher对象提供 的。步骤202、根据硬件加密设备中加解密算法与OpenSSL接口中加解密算法的映射关系，从PKCS#11接口动态库中，获取与第一算法ID相对应的硬件加密设备的加解密算法 ID，并记为第二算法ID，将第二算法ID存储在引擎中，这样引擎便将硬件加密设备当前所 要使用的加解密算法设置为了第二算法ID所对应的加解密算法了。具体的，将所述第二算法ID存储到init()函数中的上下文结构中的cipher_ data (ctx->cipher_data) pIll0其中，在引擎中，将硬件加密设备与OpenSSL中算法参数一致的加解密算法建立一一对应的映射关系；算法参数一致具体是指密钥长度、分组长度、初始向量长度等参数要一致。为了便于理解，在此举例详述根据硬件加密设备中加解密算法与OpenSSL接口中 加解密算法的映射关系，获得第二算法ID的过程。若OpenSSL接口中的算法为AES，PKCS#11 接口动态库中的算法是SSF33，在引擎对象中已经定义好了该两个算法的映射关系，AES算 法与SSF33算法的算法参数是一致的，通过AES算法的上下文结构的ctx->cipher->nid变 量中获取AES算法ID，如果得到了 AES算法ID，根据映射关系查找SSF33算法，便得到了 SSF33的算法ID，即为第二算法ID。步骤203、在密钥信息集合中，查找第二算法ID，并判断是否能够查找到该第二算 法ID，如果能查到，则执行步骤204 ；否则，执行步骤205。判断是否能在密钥信息集合中查找到第二算法ID的密钥信息具体为通过调 用 OpenSSL 接 口中的 EVP_Encryptlnit/EVP_Decryptlnit ()函数，并根据调用的 EVP_ Encryptlnit/EVP_Decryptlnit ()函数时传入的密钥值，在密钥信息集合中查找第二算法 ID。其中，根据传入的密钥值来找到密钥信息具体为通过调用PKCS#11接口动态库的C_ FindObjectslnit ()、C_Find0bjects ()、C_Find0bjectFilal ()函数在密钥信息集合中进行 查找，而查找结果是密钥句柄。在采用CBC (分组链接)加密模式时，所述 EVP_Encryptlnit/EVP_Decryptlnit() 函数被调用时传入的参数还包含初始向量值。另外，需要说明的是，EVP_CIPHER数据结构中定义了密钥长度、密钥分组长度、初 始向量长度、密钥值、密钥句柄等信息，上述信息被称之为密钥信息，不同算法密钥的密钥 信息构成密钥信息集合。步骤204、将第二算法ID的密钥句柄存储到init()函数的上下文结构中。具体地，将第二算法ID的密钥句柄存储到引擎中加解密对象的上下文结构中。步骤205、创建第二算法ID的密钥，并将所述密钥的密钥信息添加到密钥信息集
α由
口 T O创建密钥具体是通过调用PKCS#11接口动态库的CLCreateObject ()函数来创建 密钥模板。其中，创建密钥模板包括密钥类型、密钥标识、密钥值以及密钥句柄等密钥信息。 密钥标识标识密钥是加密密钥还是解密密钥；密钥句柄是供加解密函数使用的。具体地，例如，当EnCrypt_SSF33_CBC_Init ()接口被调用时，执行下列操作步骤2051 通过PKCS#11接口 C_CreateOb ject创建密钥对象，将上层应用的密钥 导入硬件加密设备。进一步地，也可以通过PKCS#11接口 C_GenerateKey控制硬件加密设备创建密钥。步骤2052 通过PKCS#11接口 C_EnCryptInit ()进行加密初始化操作，将算法设 为 CKM_SSF33_CBC。其中，CKM_SSF33_CBC表示CBC模式的SSF33加解密操作。Encrypt_Update 和 Encrypt_Final 分别通过 PKCS#11 接 口 C_EncryptUpdate 和 PKCS#11接口 C_EncryptFinal完成后续的加密操作。其中，解密操作的处理与加密类似，不再赘述。其中，具体算法与算法索弓I的对应关系保存在引擎内部。
在init()调用结束，do_cipher()函数调用之前，OpenSSL调用EVP_ EncryptUpdata/EVP_DecryptUpdata()函数，而通过上述接口函数的被调用，引擎向上层应 用提交硬件加密设备的算法列表，也确定了当前硬件加密设备所要使用的加解密算法，上 层应用程序便可以使用硬件加密设备中的算法了，而这一步具体是通过调用d0_cipher() 接口来完成的。首先，需要说明的是，当d0_cipher()函数被调用时，传入的参数有int (*do_cipher) (EVP_CIPHER_CTX*ctx，// 上下文unsigned char *out，//加 / 解密输出数据const unsigned char 氺in，// 力口 / 解密输入数据unsigned int inl) ；//加/解密输入数据的长度其中EVP_CIPHER_CTX数据结构的定义为_ struct evp_cipher_ctx_st{const EVP_CIPHER ^cipher ；// 算法ENGINE *engine ;//引擎int encrypt ;//加密或解密int buf_len ；//当前要处理的数据长度unsigned char oiv [EVP_MAX_IV_LENGTH] ；//初始起始变量unsigned char iv [EVP_MAX_IV_LENGTH] ；//当前初始变量unsigned char buf [EVP_MAX_BLOCK_LENGTH] ；//保存的部分数据块int num ；// 仅供 CFB/0FB 模式使用void *app_data ；// 其他附加数据int key_len ；// 密钥长度unsigned long flags ；// 标志位void *cipher_data ；//各算法相关部分，主要是各算法的key等int f inal_used ；int block_mask ；// 块的掩码unsigned char final [EVP_MAX_BL0CK_LENGTH] ；//最后的分组块} /* EVP_CIPHER_CTX */ ；typedef struct evp_cipher_ctx_st EVP_CIPHER_CTX ；其中的cipher由上层应用在引擎通过bincLengine ()接口报告的算法列表中选 定，engine由上层应用创建，并在调用bincLengine ()时与算法列表建立关联，其他密钥数 据由具体运算过程决定。如图7所示，当decipher ()接口被上层OpenSSL应用程序调用时，硬件加密引擎 执行如下操作步骤301、根据decipher的上下文结构EVP_CIPHER_CTX，在密钥信息集合中，查 找出与第二算法ID的密钥相对应的密钥信息，并从中取出密钥句柄。步骤302、在PKCS#11接口动态库中，查找出与第二算法ID相同的加解密算法ID。步骤303、控制硬件加密设备根据查找得到的加解密算法对传入的数据进行分包加密或解密操作，并输出结果。do_cipher()函数调用结束后，OpenSSL结束对引擎的使用，并释放该引擎，通过 clean_up ()接口来完成。当Clean_up()接口被上层OpenSSL应用程序调用时，clean_up ()接口主要进行清除第二算法ID对应的密钥及密钥信息的工作，清除方法是根据传入到引擎中的上下文 结构，从密钥信息集合中查找出对应的密钥信息，将所述密钥及密钥信息进行清除。具体地，当clean_up()接 口 被调用时，通过 PKCS#11 接口的 C_DestroyObject 函数来销毁硬件加密设备中的密钥及密钥信息；另外，硬件加密引擎在此之后还可以通过 PKCS#11接口中的函数c_ciosesession关闭硬件加密引擎与硬件加密设备的连接；需要说明的是，在该过程中还可以通过PKCS#11接口 C_FinaliZe结束硬件加密引 擎对整个PKCS#11接口的调用。实施例3在本实施例中，硬件加密引擎提供bind_engine()、init()、do_cipher()禾口 clean_up()等四个接口。其中，引擎绑定接口 bincLengine ()用于绑定引擎；密钥初始化 接口 initO用于获取硬件加密接口动态库中的加解密算法并初始化密钥及密钥信息；数 据加解密接口 d0_Cipher()用于进行分包加密或解密操作；引擎释放接口 Clean_up()用于 释放引擎。在本实施例中，所述硬件加密引擎通过硬件加密接口 CSP (Cryptographic Service Provider密码服务提供程序)接口动态库与硬件加密设备进行连接，以完成加解 密操作。通过CSP接口的CryptAcquireContext与硬件加密设备建立连接；通过CSP接口的CryptGetProvParam取得硬件加密设备的算法列表；通过CSP 接口的 CryptImportKey 导入密钥；
通过 CSP 接口的 CryptGenerateKey 生成密钥；通过CSP接口的CryptEncrypt进行加密；通过CSP接口的CryptDecrypt进行解密；通过 CSP 接口的 CryptDestroyKey 禾口 CryptReleaseContext 清理环境；通过CSP 接口的 CryptAcquireContext (DELETE_KEYSET)销毁硬件加密设备中的 密钥及密钥信息；具体流程如下图8是引擎绑定流程图。图8显示了 CSP接口动态库与OpenSSL接口的绑定过程， 当bincLengineO接口被上层OpenSSL接口调用时，所述硬件加密引擎(以下简称引擎) 执行以下操作步骤401、引擎设置CSP名称，并为硬件加密设备选择相应的CSP接口。其中，硬件加密设备可以是客户端的智能密钥设备(例如USB Key)和服务端的加 密机等。步骤4011、在引擎中定义一个命令CSP_SET，该命令用来实现CSP名称的指定。其中，实现CSP名称指定的CMD命令函数为ENGINE_CTRL_FUNC_PTR，其定义如下typedef int (*ENGINE_CTRL_FUNC_PTR)(ENGINE*，int, long, void*，void(*f)(void))；引擎在实现上述CMD命令函数时将CSP名称传入到引擎，同时将CSP名称保存在全局变量中；这样引擎在需要使用到CSP名称时(如调用CryptAcquireContext函数)，使
用该全局变量即可。步骤4012、引擎通过调用ENGINE_set_ctrl_function()函数将上述实现的命令 注册到引擎中。其实，引擎设置CSP名称的原理和ENGINE_set_i d和ENGINE_set_name相同。这样， 外部使用引擎时可以通过调用 ENGINE_ctrl_cmd_string(e，“ CSP_SET〃，“ XXXXXX“， 0)函数来设定CSP名称了。需要说明的是，在使用CSP接口实现硬件加密引擎时，不同的硬件加密设备会有 不同的CSP接口，引擎根据CSP名称加以区别，即CSP名称是和CSP接口相对应的。步骤402、引擎获取硬件加密设备的插拔事件，为硬件加密设备的CSP接口获取一 个句柄，与硬件加密设备建立了连接。引擎通过调用系统函数WindowProc获得WM_DEVICECHANGE类型事件来 获得硬件加密设备的插拔事件。其中，DBT_DEVICEARRIVAL消息为插入事件，DBT_ DEVICEREM0VEC0MPLETE消息为拔除事件。需要说明的是，由于WM_DEVICECHANGE类型是获取所有USB设备的事件(USB设 备是泛指带有USB接口的设备，而硬件加密设备可以是使用USB接口的硬件加密设备，当 然也可以是不使用USB接口的硬件加密设备，而系统函数WM_DEVICECHANGE反映的是所有 USB接口的设备)，因此调用它也可能会收到非硬件加密设备的事件。因此还需要通过调用 CryptAcquireContext (CSP接口的句柄)来确定接收到的插拔事件是否是硬件加密设备的 插拔事件，通过判断调用CryptAcquireContext是否成功来区分，如果硬件加密设备是拔 除状态的，则是获取不到该CSP接口的句柄。另外，还需要说明的是，如果有新的硬件加密设备的插入，调用 CryptAquireContext的同时还可以获取该硬件加密设备的上下文结构(即可以获取到硬 件加密设备的CSP接口句柄)。其中，CryptAcquireContext函数是CSP接口库中已有定义的函数。另外，还需要 说明的是，计算机系统会根据引擎设置的CSP名称为引擎自动分配一个句柄；这样，引擎通 过获取CSP接口句柄，以便对硬件加密设备进行操作。步骤403、引擎通过OpenSSL接口中的ENGINE_new()函数来创建一个空的引擎对 象 engine。步骤404、引擎为空的引擎对象engine设置id及名称，例如ENGINE_set_ id (engine, ，，rtl8651b，，)，ENGINE_set_name (engine, " BSDrtl8651b engine，，)。步骤405、引擎获取硬件加密设备的算法列表。具体地，引擎通过CSP接口的CryptGetProvParam取得硬件加密设备的算法列 表；步骤406、引擎设置EVP_CIPHER数据结构，以供上层OpenSSL应用程序调用。具体地说明在步骤110中已有叙述，在此就不再赘述。步骤407、判断bincLengineO接口传入的加解密算法的指针cipher是否为空，如果为空，则执行步骤408，否则，执行步骤409。具体地，根据bincLengine ()接口传入硬件加密设备的加解密算法，EVP_CIPHER 获得硬件加密设备的加解密算法，成为引擎的加解密算法；步骤408、引擎将OpenSSL接口中的加解密算法列表值赋值给引擎的加解密算法 的指针cipher，并返回OpenSSL接口中的加解密算法列表长度。其中，所述加解密算法列表长度指的是加解密算法的数量。当引擎的加解密算法的指针为空时，因为引擎的加解密算法存储的是硬件加密设 备的加解密算法，所以引擎的加解密算法的指针为空说明，硬件加密设备中没有加解密算 法。此时，将OpenSSL接口中的加解密算法列表值赋值给引擎的加解密算法的指针，在引擎 的加解密算法被调用时，引擎会根据被赋值的指针，调用OpenSSL接口中的加解密算法。步骤409、根据硬件加密设备的加解密算法与OpenSSL接口中的加解密算法的映 射关系和算法ID，找到与硬件加密设备的加解密算法对应的OpenSSL接口中的加解密算 法，返回该OpenSSL接口中的加解密算法。当引擎的加解密算法的指针不为空时，说明硬件加密设备中包含加解密算法，此 时根据硬件加密设备的加解密算法与OpenSSL接口中的加解密算法的映射关系和算法ID， 找到与硬件加密设备的加解密算法对应的OpenSSL接口中的加解密算法，返回该OpenSSL 接口中的加解密算法，即将OpenSSL接口中的加解密算法存储在引擎的对称加密对象中。 这样，引擎的对称加密对象中，存储的就是与硬件加密设备中的加解密算法有映射关系的 OpenSSL接口中的加解密算法。图9是获取CSP接口动态库中的加解密算法流程图。图9中，当init()接口被上 层OpenSSL应用程序调用时，硬件加密引擎执行如下操作步骤501、从init()接口上下文结构中，获取与所述硬件加密设备中加解密算法 相对应的OpenSSL接口中加解密算法的算法ID，记为第一算法ID。具体地，通过上下文结构的ctX->cipher->nid变量来获取第一算法ID。其中，上下文结构中的ctx->cipher->nid变量是由引擎中获取的cipher对象提 供的。步骤502、根据硬件加密设备中加解密算法与OpenSSL接口中的加解密算法的映 射关系，从CSP接口动态库中，获取与第一算法ID对应的硬件加密设备中的加解密算法ID， 记为第二算法ID，并将第二算法ID存储在引擎中，这样引擎就将硬件加密设备当前所要使 用的加解密算法设置为了第二算法ID所对应的加解密算法了。具体的，将所述第二算法ID存储到init()函数中的上下文结构中的cipher_ data (ctx->cipher_data) pIll0其中，在引擎中，将硬件加密设备与OpenSSL中算法参数一致的加解密算法建立 一一对应的映射关系。算法参数一致具体是指密钥长度、分组长度、初始向量长度等参数要一致。为了便于理解，在此举例详述根据硬件加密设备的加解密算法与OpenSSL接 口中的加解密算法的映射关系，获得第二算法ID的过程。若OpenSSL接口中的算法为 IDEAdnternational Data Encryption Algorithm)，CSP接口动态库中的算法是SSF33，在 引擎对象中已经定义好了这两个算法的映射关系，IDEA算法与三重数据加密标准SSF33算法的算法参数是一致的，通过高级加密标准AES算法的上下文结构的ctx->cipher->nid变量中获取IDEA算法ID，如果得到了 AES算法ID，根据映射关系查找SSF33算法，得到SSF33 算法的算法ID，即为第二算法ID。步骤503、在密钥信息集合中，查找第二算法ID，并判断是否能够查到，如果能查 至|J，则执行步骤504 ；否则，执行步骤505。判断是否能在密钥信息集合中查找到第二算法ID的密钥信息具体为通过调 用 OpenSSL 接 口中的 EVP_Encryptlnit/EVP_Decryptlnit ()函数，并根据调用的 EVP_ Encryptlnit/EVP_Decryptlnit ()函数时传入的密钥值在密钥信息集合中查找密钥信息。 其中，根据传入的密钥值来找到密钥信息具体为在密钥信息集合中进行查找，而查找结果 是密钥句柄。在采用CBC (分组链接)加密模式时，所述 EVP_Encryptlnit/EVP_Decryptlnit() 函数的参数列表中包含初始向量值。另外，需要说明的是，加解密算法对像EVP_CIPHER结构中定义了密钥长度、密钥 分组长度、初始向量长度、密钥值、密钥句柄等信息，这些信息称之为密钥信息，不同密钥的 密钥信息构成密钥信息集合。步骤504、将第二算法ID的密钥句柄存储到init()函数的上下文结构中。具体地，将密钥句柄存储到引擎的加密对象的上下文结构中。步骤505、创建第二算法ID的密钥，并将所述密钥的密钥信息添加到密钥信息集
A由
口 T O创建密钥具体是通过调用CSP接口的CryptImportKeyO函数来创建密钥。其中， 创建密钥模板包括密钥值以及密钥句柄等密钥信息。如图10所示，当decipher ()接口被上层OpenSSL应用程序调用时，硬件加密引 擎执行如下操作步骤601、在密钥信息集合中根据d0_cipher()接口的上下文结构，查找出与第二 算法ID对应的密钥信息，并从中取出密钥句柄。步骤602、在CSP接口动态库中，查找出与第二算法ID相同的加解密算法ID。步骤603、控制硬件加密设备根据查找得到的加解密算法对传入的数据进行分包 加密或解密操作。其中，分包加解密操作包括电子密码本加解密模式EBC和分组链接加解密模CBC式。加解密操作完成后，cleap_up接口将被调用，以清理环境。当Clean_up()接口被上层OpenSSL应用程序调用时，主要进行清除第二算法ID 的密钥及密钥信息的工作，清除方法是根据传入到引擎中的上下文结构，从密钥信息集合 中查找出对应的密钥信息，将所述密钥及密钥信息清除。具体地，当clean_up()函数被调用时，通过PKCS#11接口的C_DestroyObject 函数来销毁硬件加密设备中的密钥及密钥信息；另外，硬件加密引擎在此之后还可以通过 PKCS#11接口中的函数c_ciosesession关闭硬件加密引擎与硬件加密设备的连接；需要说明的是，在该过程中还可以通过PKCS#11接口 C_FinaliZe结束硬件加密引 擎对整个PKCS#11接口的调用。
本发明提供的硬件加密引擎，将一些硬件加解密算法添加扩展到软件算法库中。 同时，该硬件加密引擎在实现上还可以支持多线程和SSL通讯。为使引擎能够支持多线程， 使用一个互斥锁和自定义的数据结构来实现并发控制。如果加解密算法还要支持SSL通讯 协议(SSL协议定义用于加密和解密用的密钥是分开的)，在创建密钥时，还要对密钥用途 做标识。另外，需要说明的是，以上实施例中所指的加解密算法均指对称加解密算法。 以上所述，仅为本发明较佳的具体实施方式
，但本发明的保护范围并不局限于此， 任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换， 都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围 为准。
权利要求
一种硬件加密引擎的实现方法，上层应用程序通过调用所述硬件加密引擎的引擎绑定接口、密钥初始化接口、数据加解密接口、引擎释放接口来实现，其特征是，所述方法包括引擎绑定接口被上层应用程序调用时，硬件加密引擎与硬件加密设备建立连接，获取所述硬件加密设备的算法列表，并填充第一数据结构；密钥初始化接口被上层应用程序调用时，所述硬件加密引擎根据传入的所述第一数据结构设置所述硬件加密设备当前所要使用的加解密算法，并检索相应的算法密钥，如果检索不到，则控制所述硬件加密设备创建所述算法密钥；数据加解密接口被上层应用程序调用时，所述硬件加密引擎根据当前设置的加解密算法和算法密钥，控制所述硬件加密设备对传入的数据进行加/解密操作，并输出操作结果；引擎释放接口被上层应用程序调用时，所述硬件加密引擎结束与所述硬件加密设备的连接。
2.根据权利要求1所述的一种硬件加密引擎的实现方法，其特征是，所述硬件加密设 备包括智能密钥设备或加密机。
3.根据权利要求1所述的一种硬件加密引擎的实现方法，其特征是，所述引擎绑定接 口、密钥初始化接口、数据加解密接口、引擎释放接口具体为bincLengine接口、init接口、 do_cipher 接口、clean_up 接 口。
4.根据权利要求1所述的一种硬件加密引擎的实现方法，其特征是，所述硬件加密引 擎与所述硬件加密设备通过硬件加密接口建立连接；其中，所述硬件加密接口包括密码令牌接口或加密服务提供程序接口。
5.根据权利要求1所述的一种硬件加密引擎的实现方法，其特征是，所述第一数据结 构具体为EVP_CIPHER数据结构，所述EVP_CIPHER数据结构是上层应用程序中已定义的。
6.根据权利要求3或5所述的一种硬件加密引擎的实现方法，其特征是，所述填充第一 数据结构具体为所述硬件加密引擎根据所述获取的算法列表和init接口、decipher接口和cleanup 接口的指针来填充传入的EVP_CIPHER数据结构。
7.根据权利要求6所述的一种硬件加密引擎的实现方法，其特征是，根据所述获取的 算法列表和init接口、do_cipher接口和clean_up接口的指针来填充传入的EVP_CIPHER 数据结构具体为根据上层应用程序中已有的定义，在EVP_CIPHER数据结构中为所述算法列表中的任 一加解密算法设置对应的算法ID号；根据所述算法列表中的数值，在EVP_CIPHER数据结构中为密钥长度、密钥分组长度、 初始向量长度设置对应的数值，并为init接口、decipher接口、cleanup接口指针设置对 应的函数指针。
8.根据权利要求5所述的一种硬件加密引擎的实现方法，其特征是，所述硬件加密引 擎根据传入的所述第一数据结构设置所述硬件加密设备当前所要使用的加解密算法，并检 索相应的算法密钥，如果检索不到，则控制所述硬件加密设备创建所述算法密钥具体为密钥初始化接口被上层应用程序调用时，所述填充后的EVP_CIPHER数据结构传入所 述硬件加密引擎；所述硬件加密引擎根据所述传入的EVP_CIPHER数据结构中的算法指针获取第一加解密算法ID，所述第一加解密算法ID对应的加解密算法为上层应用程序中的算法；所述硬件加密设备根据预设的映射关系，获取与所述第一加解密算法ID对应的第二 加解密算法ID，所述第二加解密算法ID对应的加解密算法为所述硬件加密设备中的算法；所述硬件加密引擎在所述硬件加密设备中的密钥信息集合中，查找所述第二加解密算 法ID，如果能查找到，则将所述第二加解密算法ID对应的密钥句柄存储到EVP_CIPHER数据 结构的上下文中，如果查找不到，则控制所述硬件加密设备创建所述第二加解密算法密钥， 并将所述第二加解密算法密钥的密钥信息添加到密钥信息集合中；所述第二加解密算法为所述硬件加密设备当前所要使用的加解密算法。
9.根据权利要求8所述的一种硬件加密引擎的实现方法，其特征是，所述算法指针是 由上层应用程序在EVP_CIPHER数据结构的算法列表中选定的。
10.根据权利要求8所述的一种硬件加密引擎的实现方法，其特征是，所述预设的映射 关系是由上层应用程序创建的，将算法参数一致的所述硬件加密设备中的加解密算法和上 层应用程序中的加解密算法建立一一对应的映射关系；其中，算法参数具体是指密钥长度、密钥分组长度、初始向量长度。
11.根据权利要求8所述的一种硬件加密引擎的实现方法，其特征是，所述密钥信息包 括密钥句柄、密钥值、密钥标签。
12.根据权利要求11所述的一种硬件加密引擎的实现方法，其特征是，所述硬件加密 引擎根据当前设置的加解密算法和算法密钥，控制所述硬件加密设备对传入的数据进行加 /解密操作，并输出操作结果具体为数据加解密接口被上层应用程序调用时，从传入的所述上下文中查找得到所述硬件加 密设备当前所要使用的加解密算法的密钥句柄；所述硬件加密引擎控制所述硬件加密设备根据所述查找得到的密钥句柄对传入的数 据进行加/密操作，并输出操作结果。
13.根据权利要求1所述的一种硬件加密引擎的实现方法，其特征是，所述加解密操作 包括分组链接加解密模式和电子密码本加解密模式。
全文摘要
本发明公开了一种硬件加密引擎的实现方法。技术方案是，引擎绑定接口被调用时，硬件加密引擎与硬件加密设备建立连接，获取所述硬件加密设备的算法列表，并填充第一数据结构；密钥初始化接口被调用时，所述硬件加密引擎根据传入的所述第一数据结构设置所述硬件加密设备当前所要使用的加解密算法，并检索相应的算法密钥，如果检索不到，则控制所述硬件加密设备创建所述算法密钥；数据加解密接口被调用时，所述硬件加密引擎根据当前设置的加解密算法和算法密钥，控制所述硬件加密设备对传入的数据进行加/解密操作，并输出操作结果；引擎释放接口被调用时，所述硬件加密引擎结束与所述硬件加密引擎的连接。
文档编号H04L9/08GK101820342SQ20101013868
公开日2010年9月1日 申请日期2010年3月31日 优先权日2010年3月31日
发明者于华章, 陆舟 申请人:北京飞天诚信科技有限公司