WO2011120421A1 - 加密引擎的实现方法 - Google Patents

加密引擎的实现方法 Download PDF

Info

Publication number
WO2011120421A1
WO2011120421A1 PCT/CN2011/072250 CN2011072250W WO2011120421A1 WO 2011120421 A1 WO2011120421 A1 WO 2011120421A1 CN 2011072250 W CN2011072250 W CN 2011072250W WO 2011120421 A1 WO2011120421 A1 WO 2011120421A1
Authority
WO
WIPO (PCT)
Prior art keywords
interface
engine
encryption
algorithm
decryption
Prior art date
Application number
PCT/CN2011/072250
Other languages
English (en)
French (fr)
Inventor
陆舟
于华章
Original Assignee
北京飞天诚信科技有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from CN2010101386858A external-priority patent/CN101820342B/zh
Priority claimed from CN 201010214432 external-priority patent/CN102055759B/zh
Priority claimed from CN2010102484576A external-priority patent/CN101908963B/zh
Application filed by 北京飞天诚信科技有限公司 filed Critical 北京飞天诚信科技有限公司
Priority to US13/635,918 priority Critical patent/US8995663B2/en
Publication of WO2011120421A1 publication Critical patent/WO2011120421A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0877—Generation of secret information including derivation or calculation of cryptographic keys or passwords using additional device, e.g. trusted platform module [TPM], smartcard, USB or hardware security module [HSM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0485—Networking architectures for enhanced packet encryption processing, e.g. offloading of IPsec packet processing or efficient security association look-up
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3249—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using RSA or related signature schemes, e.g. Rabin scheme
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/12—Details relating to cryptographic hardware or logic circuitry
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/168—Implementing security features at a particular protocol layer above the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H04L63/205—Network architectures or network communication protocols for network security for managing network security; network security policies in general involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved

Definitions

  • the present invention relates to the field of information security technologies, and in particular, to an implementation method of an encryption engine, which can be extended to an existing software algorithm library by using an information algorithm that can only be implemented by hardware, so as to improve the security of information operations.
  • Background technique
  • SSL is the abbreviation of Secure Socket Layer, which means Secure Sockets Layer protocol, which refers to a secure network communication protocol that uses a combination of public and private key technologies.
  • the SSL protocol is a WEB-based security protocol introduced by Netscape.
  • the SSL protocol specifies a data security between application protocols (such as Http, Telenet, NMTP, FTP, etc.) and TCP/IP.
  • application protocols such as Http, Telenet, NMTP, FTP, etc.
  • TCP/IP TCP/IP.
  • a layered mechanism that provides data encryption, server authentication, message integrity, and optional client authentication for TCP/IP connections. It is primarily used to improve data security between applications, encrypting and hiding transmitted data. , to ensure that the data is not changed in the transmission, that is, to ensure the integrity of the data.
  • SSL combines symmetric cryptography with public cryptography to achieve the following three connectivity goals:
  • SSL uses the cryptographic algorithm and the hash (HASH) function to ensure the integrity of the information by extracting the feature values of the transmitted information, ensuring that all the information to be transmitted arrives at the destination, and avoids the server and the client. The information between them was destroyed.
  • HASH hash
  • PKCS Public-Key Cryptography Standards
  • Cyptoki defines a set of technology-independent programming interfaces for encryption devices such as smart cards and PCMCIA cards.
  • the OpenSSL project is a security project for open source code.
  • the goal is to implement a secure Sockets Layer (SSLv2/v3) and Transport Layer Security (TLS vl) with powerful encryption algorithms. It contains complete encryption algorithms, digital signature algorithms and certificate signature algorithms. Data integrity, confidentiality and correctness can be guaranteed.
  • the purpose of the Engine mechanism is to enable OpenSSL to transparently use a third-party software encryption library or hardware encryption device for encryption.
  • OpenSSL's Engine mechanism has successfully achieved this goal, which makes OpenSSL more than just a cryptographic library, but also a universal cryptographic interface that works with most cryptographic libraries or cryptographic devices.
  • An object of the present invention is to provide an implementation method of an encryption engine, which can extend an information algorithm that can only be implemented by hardware into an existing software algorithm library, thereby improving the security of information operations.
  • An implementation method of a hardware engine is implemented by calling an engine binding interface, an initialization interface, a first interface, and an engine release interface of the engine, where the first interface includes a data encryption and decryption interface;
  • the first interface includes
  • the first interface includes
  • the initialization interface is a key initialization interface
  • the method includes:
  • the engine When the engine is called by the upper layer application, the engine establishes a connection with the smart key device, obtains a list of algorithms of the smart key device, and fills the first data structure;
  • the engine sets an encryption and decryption algorithm to be used by the smart key device according to the first data structure that is input, and retrieves a corresponding algorithm key, if the retrieval is not And controlling the smart key device to create the algorithm key;
  • the engine controls the according to the currently set encryption and decryption algorithm and the algorithm key.
  • the smart key device performs an encryption/decryption operation on the incoming data, and outputs an operation result;
  • the initialization interface is an engine initialization interface, and the method includes:
  • the engine initialization interface When the engine initialization interface is called by the upper application, the engine establishes a connection with the smart key device;
  • the engine binding interface When the engine binding interface is invoked by the upper application, binding the engine, loading the algorithm key and the certificate, and setting the second data structure, where the algorithm key includes a public key and a private key;
  • the engine controls the smart key device to perform an encryption/decryption operation on the incoming data according to the loaded algorithm key, and outputs the operation result.
  • the engine controls the smart key device to perform the signature operation on the incoming digest value according to the loaded algorithm key, and returns the signature result;
  • the engine controls the smart key device to decrypt the incoming signature value according to the loaded algorithm key, and verifies the decryption. If the obtained digest value is correct or correct, the verification is successful; otherwise, the verification fails;
  • the engine controls the smart key device to perform SSL client authentication according to the loaded certificate, and returns an authentication result;
  • the method includes:
  • the engine When the interface is invoked by the upper layer application, the engine establishes a connection with the smart key device, acquires a list of algorithms of the smart key device, and populates the third data structure, and registers the third data structure to In the upper layer application;
  • the engine sets an information digest algorithm currently used by the smart key device according to the incoming third data structure, allocates a storage space for the incoming context, and initializes the Context
  • the engine controls the smart key device to perform a digest operation on the incoming information summary data according to the currently set information digest algorithm
  • the engine controls the smart key device to end the digest operation, and outputs the operation result; when the bow engine release interface is called by the upper application, the engine ends with the smart password The connection of the key device.
  • FIG. 1 is a schematic diagram showing a mapping relationship between an encryption and decryption algorithm of a hardware encryption device and an encryption and decryption algorithm in an OpenSSL library;
  • FIG. 2 is a schematic diagram of an encryption and decryption algorithm of an encryption and decryption algorithm of a hardware encryption device, which is transmitted to an engine;
  • FIG. 3 is a schematic diagram of a pointer to an encryption and decryption algorithm assigned to an engine by an encryption/decryption algorithm list value in an OpenSSL interface;
  • FIG. 4 is a schematic diagram of an encryption and decryption algorithm in an OpenSSL library corresponding to an encryption and decryption algorithm of a hardware encryption device;
  • FIG. 5 is a flowchart of engine binding
  • FIG. 6 is a flow chart of obtaining an encryption and decryption algorithm in a PKCS#11 interface dynamic library
  • Figure 7 is a flow chart of packet encryption and decryption
  • Figure 8 is another flow chart of engine binding
  • FIG. 9 is a flowchart of obtaining an encryption and decryption algorithm in a CSP interface dynamic library
  • Figure 10 is a flow chart of packet encryption and decryption.
  • FIG. 11 is a flowchart of an engine binding interface bincLengine being invoked according to an embodiment of the present invention.
  • FIG. 12 is a flowchart of the crtl_f() interface being invoked according to an embodiment of the present invention.
  • FIG. 13 is a flowchart of an engine initialization interface init being invoked according to an embodiment of the present invention.
  • FIG 14 is a flowchart of a public key encryption when provided in the interface rSa _pub_ enc invoked embodiment of the invention.
  • FIG 16 the signature interface according to an embodiment of the present invention rSa _ S ign flowchart is invoked
  • FIG 17 is a flowchart when call sign test interface provided rSa _ V erif y embodiment of the present invention.
  • FIG. 18 is a flowchart of a method for loading a client certificate interface ENGINE_set_load_ssl_client_cert_function according to an embodiment of the present invention.
  • FIG. 19 is a flowchart of an engine binding interface that is invoked by an upper application according to an embodiment of the present disclosure
  • FIG. 20 is a flowchart of an initialization interface provided by an upper layer application according to an embodiment of the present invention.
  • FIG. 1 is a schematic diagram of the mapping relationship between the encryption and decryption algorithm of the hardware encryption device and the encryption and decryption algorithm in the OpenSSL interface.
  • the mapping relationship between the encryption and decryption algorithm of the hardware encryption device and the encryption and decryption algorithm in the OpenSSL interface is specifically: an encryption and decryption algorithm that matches the algorithm parameters in the encryption and decryption algorithm in the hardware encryption device and the encryption and decryption algorithm in the OpenSSL interface.
  • Algorithm parameters include key length, packet length, and initial vector length.
  • FIG. 2 is a schematic diagram of an encryption and decryption algorithm of an encryption and decryption algorithm of a hardware encryption device transmitted to an engine to obtain an engine.
  • an encrypted object is created in the engine to store information related to the encryption and decryption algorithm.
  • the encryption and decryption algorithm in the hardware encryption device is transmitted into the symmetric encryption object in the engine, so that the encryption and decryption algorithm of the hardware encryption device is transmitted to the engine, and the engine encryption and decryption algorithm is obtained.
  • the pointer of the engine encryption and decryption algorithm, the encryption and decryption algorithm list value in the OpenSSL interface, and each encryption and decryption algorithm ID are obtained. Determine whether the pointer of the engine encryption/decryption algorithm is empty. If the pointer of the engine encryption/decryption algorithm is empty, it indicates that the pointer of the encryption and decryption algorithm of the incoming hardware encryption device in the engine is empty, and the encryption in the OpenSSL interface is added.
  • the decryption algorithm list value is assigned to the pointer of the engine's encryption and decryption algorithm, and returns the encryption and decryption algorithm list value in the OpenSSL interface.
  • FIG. 3 is a schematic diagram of the pointer of the encryption/decryption algorithm list value assigned to the engine in the OpenSSL interface.
  • the pointer of the engine encryption/decryption algorithm when the pointer of the engine encryption/decryption algorithm is empty, since the encryption and decryption algorithm of the engine stores the encryption and decryption algorithm of the hardware encryption device, the pointer of the encryption and decryption algorithm of the engine is empty, and there is no hardware encryption device. Encryption and decryption algorithm.
  • the encryption and decryption algorithm list value in the OpenSSL interface is assigned to the pointer of the engine's encryption and decryption algorithm.
  • the engine encryption and decryption algorithm When the engine encryption and decryption algorithm is called, the engine will call the encryption and decryption algorithm in the OpenSSL interface according to the assigned pointer.
  • the OpenSSL interface corresponding to the encryption and decryption algorithm of the hardware encryption device is returned according to the mapping relationship between the encryption and decryption algorithm of the hardware encryption device and the encryption and decryption algorithm in the OpenSSL interface and the algorithm ID.
  • the encryption and decryption algorithm. 4 is a schematic diagram of an encryption and decryption algorithm in an OpenSSL interface corresponding to an encryption and decryption algorithm of a hardware encryption device. In Figure 4, when the pointer of the engine encryption/decryption algorithm is not empty, it indicates that the hardware encryption device includes an encryption and decryption algorithm.
  • the algorithm relationship and the algorithm ID are The encryption and decryption algorithm in the OpenSSL interface corresponding to the encryption and decryption algorithm of the hardware encryption device is found, and the encryption and decryption algorithm in the OpenSSL interface is returned, and the encryption and decryption algorithm in the OpenSSL interface is stored in the symmetric encryption object of the engine.
  • the encryption and decryption algorithm in the OpenSSL interface that is mapped to the encryption and decryption algorithm in the hardware encryption device is stored.
  • the engine is reserved by OpenSSL for loading third-party encryption libraries. It mainly includes a series of interfaces for dynamic library loading code and encryption function pointer management. To use the engine, OpenSSL first loads the engine and selects the algorithm to use or uses all the encryption and decryption algorithms supported, so that when the application calls the encryption and decryption function, it points to the encryption and decryption in the loaded third-party encryption library. Algorithm, instead of the encryption and decryption algorithm in the original OpenSSL libeay32.dll library, the main principle of the engine is to replace the default encryption and decryption function in OpenSSL by using the function pointer in the third-party encryption library or the interface pointer of the hardware encryption device. Implement dynamic loading of third-party encryption libraries.
  • the hardware encryption engine is connected to the hardware encryption device through the hardware encryption interface PKCS#11 (password token) interface dynamic library (of course, the hardware encryption interface CSP interface dynamic library) to complete the data.
  • PKCS#11 password token
  • the encryption and decryption operation, the PKCS#11 interface dynamic library is provided by a developer of the hardware encryption device, and the hardware encryption device includes a smart key device (such as a USB KEY) of the client, an encryption machine of the server, etc.; PKCS#11 interface dynamic
  • the internal details of the library are outside the scope of the present invention.
  • the hardware encryption provided by the present invention is implemented by four functions such as bind_engine(), init(), do_cipher(), and clean_up() registered in the OpenSSL interface.
  • the engine binding interface bincLengineO is used for the binding engine;
  • the key initialization interface init() is used to obtain the encryption and decryption algorithm in the hard encryption interface dynamic library and initialize the key and key information;
  • the data encryption and decryption interface d 0 _ciph er () is used for data packet encryption or decryption operations;
  • the bow engine release interface C l ean _up () is used to release the engine.
  • the standard C language programming is taken as an example, and the PKCS#11 interface dynamic library and OpenSSL interface are combined to illustrate the implementation process of the hardware encryption engine (hereinafter referred to as the engine) in the present invention.
  • Step 101 The engine loads the PKCS#11 interface dynamic library.
  • this step is completed by calling a system function loadlibraryO of the computer, and the file name of the PKCS#11 interface dynamic library is Pre-agreed.
  • Step 102 The engine obtains a function list of the PKCS#11 interface dynamic library.
  • this step is completed by calling the C_GetFunctionList() function in the PKCS#11 interface;
  • this step may firstly obtain the C_GetFunctionList() function in the PKCS#11 interface at the entry point of the PKCS#11 interface by calling the computer system function GetProcAddressO. After the C_GetFunctionList() function is successfully executed, other functions may be obtained.
  • the entry point of the PKCS#11 interface and can call these interfaces to obtain a list of functions of the PKCS#11 interface dynamic library; if the attempt fails, an error is returned.
  • the function list of the PKCS#11 interface dynamic library may be CK_FUNCTION_LIST_PTR.
  • the function list of the PKCS#11 interface dynamic library includes a pointer of a function pointer in the PKCS#11 interface dynamic library.
  • Step 103 The engine initializes the PKCS#11 interface dynamic library by calling the function C_Initialize() defined in the PKCS#11 interface dynamic library.
  • calling the function C_Initialize() defined in the PKCS#11 interface dynamic library is implemented by the pointer of the function C_Initiali Z e() pointer in the function list of the PKCS#11 interface dynamic library obtained in step 102.
  • the C_Initiali Ze () interface must be called first before performing other operations.
  • Step 104 The engine creates and starts a monitoring thread for monitoring the insertion and removal events of the hardware encryption device, and storing the plugged and unplugged state of the hardware encryption device in a customized data structure.
  • the plugging and unplugging event of the hardware encryption device is implemented by calling the function C-WaitForSlotEventO defined in the dynamic library of the PKCS#11 interface, and timely according to the monitored plugging and unplugging status. Update the custom data structure.
  • the function C_WaitForSlotEvent() defined in the PKCS#11 interface dynamic library is specifically called by the pointer of the function C_WaitForSlotEvent() pointer in the function list of the PKCS#11 interface dynamic library obtained in step 102.
  • the custom data structure refers to a set of slot list information, where the slot list information includes plug and play status information of the hardware encryption device.
  • the slot list information data structure defined in the PKCS#11 interface dynamic library includes slot description, manufacturer ID, performance identifier, hardware serial number, firmware serial number, and the like.
  • Step 105 The engine obtains the slot list information, and obtains the plugged and unplugged state of the hardware encryption device.
  • the engine obtaining the slot list information is implemented by calling a function C_GetSlotList() defined in the PKCS#11 interface dynamic library, obtaining the plugged and unplugged state of the hardware encryption device, and acquiring the hardware encryption device handle currently connected to the host, if currently exists When multiple hardware encryption devices are connected to the host, the first hardware encryption device in the list is selected.
  • calling the function C_GetSlotList() defined in the PKCS#11 dynamic library is implemented by the pointer of the function C_GetSlotLi S tO pointer in the function list of the PKCS#11 interface dynamic library obtained in step 102.
  • Step 106 The engine establishes a connection with the hardware encryption device to operate the hardware encryption device.
  • connection between the engine and the hardware encryption device is implemented by calling a function C_OpenSe SS i 0n () defined in the PKCS#11 interface dynamic library.
  • the function C_OpenSession() defined in the PKCS#11 interface dynamic library is called by the function C-OpenSessionO pointer in the function list of the PKCS#11 interface dynamic library obtained in step 102.
  • step 105 the plug-in status of the hardware encryption device in the slot list information is obtained in order to notify the engine of the current state of the hardware encryption device in time. If the hardware encryption device is removed, the engine is shut down and the hardware is encrypted in time. The session of the device, if the hardware encryption device is inserted, the timely engine opens a session with the hardware encryption device to improve work efficiency, and at the same time, avoids the engine temporarily opening the session when using the hardware encryption device, and the hardware encryption device is unplugged. , resulting in the occurrence of an error condition.
  • Step 107 The engine creates an empty engine object engine through the ENGINE_new() function.
  • the ENGINE_new() function is defined in the OpenSSL interface.
  • Step 108 The engine sets an id and a name for the engine object engine, for example, ENGINE_set_id(engine, "rtl8651b"),
  • Step 109 The engine obtains a list of algorithms of the hardware encryption device.
  • the algorithm list is obtained by calling C_GetMechanismList in the PKCS#11 interface;
  • Step 110 The engine sets the encryption and decryption object EVP.CIPHER data structure for the upper layer OpenSSL application to call.
  • EVP_CIPHER data structure is already in OpenSSL, as follows:
  • Nid ID number of the algorithm, defined in include/openssl/object.h;
  • Block.size packet length of encryption and decryption
  • Ctx.size The data size of each algorithm is actually the key data of each algorithm.
  • EVP_CIPHER particular data structure et_dph by ENGINE_ S erS () function to achieve, and OpenSSL definition is provided corresponding to the nid.
  • ENGINE_set_ciphers function is defined as follows:
  • Typedef int (*ENGINE_CIPHERS_PTR)(ENGINE *e, const EVP—CIPHER **cipher, const int **nids, int nid).
  • Cipher pointer to the EVP_CIPHER pointer
  • Nids is a symmetric ⁇ method list value (ie int array)
  • Nid is the algorithm ID number that was passed in when the engine object was obtained.
  • the engine populates the EVP-CIPHER data structure according to the obtained algorithm list
  • Encrypt_DES3_CBC_Init, Encrypt_Updata and B Encrypt_Filnal are the internal interfaces of the engine, respectively
  • the PKCS#11 interface is used to complete the encryption operation.
  • Step 111 Determine whether the encryption/decryption algorithm pointer cipher sent from the bincLengineO interface is empty. If it is empty, execute step 112. Otherwise, go to step 113.
  • the EVP_CIPHER obtains the encryption and decryption algorithm of the hardware encryption device, and becomes an encryption and decryption algorithm of the engine;
  • Step 112 The engine assigns the encryption/decryption algorithm list value in the OpenSSL interface to the engine encryption/decryption algorithm pointer cipher, and returns the encryption/decryption algorithm list length in the OpenSSL interface.
  • the length of the encryption/decryption algorithm list refers to the number of encryption and decryption algorithms.
  • the pointer of the engine encryption and decryption algorithm When the pointer of the engine encryption and decryption algorithm is empty, since the encryption and decryption algorithm of the engine stores the encryption and decryption algorithm of the hardware encryption device, the pointer of the encryption and decryption algorithm of the engine is empty, and there is no encryption and decryption algorithm in the hardware encryption device. At this time, the value of the encryption and decryption algorithm in the OpenSSL interface is assigned to the pointer of the engine's encryption and decryption algorithm. When the engine's encryption and decryption algorithm is called, the engine will call the encryption and decryption algorithm in the OpenSSL interface according to the assigned pointer.
  • Step 113 According to the mapping relationship between the encryption and decryption algorithm of the hardware encryption device and the encryption and decryption algorithm in the OpenSSL interface, and the algorithm ID, find an encryption and decryption algorithm in the OpenSSL interface corresponding to the encryption and decryption algorithm of the hardware encryption device, and return to the OpenSSL interface. Encryption and decryption algorithm.
  • the hardware encryption device When the pointer of the engine encryption/decryption algorithm is not empty, the hardware encryption device includes an encryption and decryption algorithm. At this time, according to the mapping relationship between the encryption and decryption algorithm of the hardware encryption device and the encryption and decryption algorithm in the OpenSSL interface, and the algorithm ID, The encryption and decryption algorithm in the OpenSSL interface corresponding to the encryption and decryption algorithm of the hardware encryption device returns the encryption and decryption algorithm in the OpenSSL interface, that is, the encryption and decryption algorithm in the OpenSSL interface is stored in the symmetric encryption object of the engine. Thus, in the symmetric encryption object of the engine, the encryption and decryption algorithm in the OpenSSL interface that is mapped to the encryption and decryption algorithm in the hardware encryption device is stored.
  • the OpenSSL interface performs the following operations before the init() function is called:
  • the OpenSSL interface initializes the engine by calling the ENGINE_init() function;
  • the OpenSSL interface provides the engine by calling the ENGINE_set_default_ciphers() function.
  • the encryption and decryption algorithm is set to become the engine's default encryption and decryption algorithm;
  • the OpenSSL interface obtains the 3 ⁇ 4X EVP.CIPHER object and algorithm ID from the engine, and calls the EVP_Encryptlnit/EVP_Decryptlnit() function to transfer to the engine's init() function.
  • the parameters are:
  • Cipher algorithm pointer
  • App.data application related data
  • Cipher.data the relevant parts of each algorithm, mainly the key of each algorithm, etc.
  • Block_mask block mask
  • the hardware encryption engine (hereafter referred to as the engine) performs the following operations:
  • Step 201 Obtain an encryption and decryption algorithm ID in an OpenSSL interface corresponding to the encryption and decryption algorithm in the hardware encryption device from the context structure EVP_CIPHER_CTX of the init() function, and record it as the first algorithm ID.
  • the first algorithm ID is obtained by a ctx->cipher->nid variable in the context structure EVP_CIPHER_CTX.
  • the ctx-> C iph er ->nid1 ⁇ 2 quantity in the context structure is provided by the cipher object obtained by the engine.
  • Step 202 Obtain an encryption and decryption algorithm ID of the hardware encryption device corresponding to the first algorithm ID from the PKCS#11 interface dynamic library according to the mapping relationship between the encryption and decryption algorithm in the hardware encryption device and the encryption and decryption algorithm in the OpenSSL interface, and Recorded as the second algorithm ID, the second algorithm ID is stored in the engine, so that the engine sets the encryption and decryption algorithm currently used by the hardware encryption device to the encryption and decryption algorithm corresponding to the second algorithm ID.
  • the second algorithm ID is stored in a C iph er _d a t a ( C t X -> C iph er _dat a ) field in a context structure in the init() function.
  • the encryption and decryption algorithms that match the hardware encryption device with the algorithm parameters in OpenSSL establish a one-to-one mapping relationship; the algorithm parameters are consistent, that is, the parameters such as the key length, the packet length, and the initial vector length are consistent.
  • the process of obtaining the second algorithm ID according to the mapping relationship between the encryption and decryption algorithm in the hardware encryption device and the encryption and decryption algorithm in the OpenSSL interface is exemplified in this example.
  • the algorithm in the OpenSSL interface is AES
  • the algorithm in the PKCS#11 interface dynamic library is SSF33.
  • the mapping relationship between the two algorithms is defined in the engine object.
  • the algorithm parameters of the AES algorithm and the SSF33 algorithm are consistent.
  • the AES algorithm ID is obtained from the ct X -> C iph er -> nid variable of the context structure of the AES algorithm. If the AES algorithm ID is obtained, the SSF33 algorithm is searched according to the mapping relationship, and the algorithm ID of the SSF 33 is obtained, which is the second algorithm. ID.
  • step 203 the second algorithm ID is searched for in the key information set, and it is determined whether the second algorithm ID can be found. If yes, step 204 is performed; otherwise, step 205 is performed.
  • the key information for judging whether the second algorithm ID can be found in the key information set is specifically: by calling the EVP_Encryptlnit/EVP_Decryptlnit() function in the OpenSSL interface, and according to the EVP_Encryptlnit/EVP_Decryptlnit() function called.
  • the key information is found according to the key value of the ⁇ transmission: specifically: by calling the C_FindObjectslnit(), C_FindObjects(), C_FindObjectFilal() functions of the PKCS#11 interface dynamic library, searching in the key information set, and searching for the result Is the key handle.
  • the parameters passed in when the EVP_Encryptlnit/EVP_Decryptlnit() function is called also contain an initial vector value.
  • the EVP_CIPHER data structure defines information such as key length, key packet length, initial vector length, key value, key handle, etc. The above information is called key information, different algorithm keys.
  • the key information constitutes a set of key information.
  • Step 204 Store the key handle of the second algorithm ID into the context structure of the init() function.
  • the key handle of the second algorithm ID is stored in the context structure of the encryption and decryption object in the engine.
  • Step 205 Create a key of the second algorithm ID, and add the key information of the key to the key information set.
  • the key is created by calling the C-CreateObjectO function of the PKCS#11 interface dynamic library.
  • the key template is created including key information such as a key type, a key identifier, a key value, and a key handle.
  • the key identifier identifies whether the key is an encryption key or a decryption key; the key handle is used by the encryption and decryption function.
  • Step 2051 Create a key object through the PKCS#11 interface C_CreateObject, and import the key of the upper application into the hardware encryption device. Further, it is also possible to control the hardware encryption device to create a key through the PKCS#11 port C_GenerateKey.
  • Step 2052 Perform a cryptographic initialization operation through the PKCS#11 interface C_EncryptInit(), and set the algorithm to CKM_SSF33_CBC.
  • CKM_SSF33_CBC indicates the SSF33 encryption and decryption operation in CBC mode.
  • the processing of the decryption operation is similar to the encryption, and will not be described again.
  • OpenSSL calls the EVP_EncryptUpdata/EVP_DecryptUpdata() function, and by the above interface function is called, the engine submits the algorithm list of the hardware encryption device to the upper layer application, and also determines the current hardware encryption.
  • the encryption and decryption algorithm to be used by the device, the upper layer application can use the algorithm in the hardware encryption device, and this step is specifically completed by calling the do_cipher ( ) interface.
  • the EVP_CIPHER_CTX data structure is defined as
  • the cipher is selected by the i layer in the list of algorithms reported by the engine through the bind_ en gi ne () interface.
  • the engine is created by the upper application and is associated with the algorithm list when calling bincLengineO.
  • the other key data is determined by the specific operation process. Decide.
  • Step 301 Searching in the key information set according to the context structure EVP_CIPHER_CTX of the do-cipher The key information corresponding to the key of the second algorithm ID is extracted, and the key handle is taken out therefrom.
  • Step 302 In the PKCS#11 interface dynamic library, find the same encryption and decryption algorithm ID as the second algorithm ID.
  • Step 303 The control hardware encryption device performs a packet encryption or decryption operation on the incoming data according to the encryption and decryption algorithm obtained by the search, and Output the result.
  • the key and key signal in the hardware encryption device are destroyed by the C_DestroyObject function of the PKCS#11 interface; in addition, the hardware encryption engine can also pass the PKCS#11 interface after this.
  • the function C-CloseSession in the function closes the connection between the hardware encryption and the hardware encryption device;
  • the PKCS#11 interface C_Finalize can also be used to end the call of the hardware encryption engine to the entire PKCS#11 interface.
  • the hardware encryption engine provides four interfaces, such as bind_engine(), init(), do_cipher(), and clean_up().
  • the engine binding interface bincLengineO is used for the binding engine;
  • the key initialization interface init() is used to obtain the encryption and decryption algorithm in the hardware encryption interface dynamic library and initialize the key and key information;
  • the data encryption and decryption interface d 0 _ciph er () is used for packet encryption or decryption operations;
  • the engine release interface cl ean _ U p() is used to release the engine.
  • the hardware encryption engine is connected to the hardware encryption device through a hardware encryption interface CSP (Cryptographic Service Provider) interface dynamic library to complete the encryption and decryption operation.
  • CSP Cosmetic Service Provider
  • Figure 8 is a flowchart of engine binding.
  • Figure 8 shows the binding process with the CSP interface to OpenSSL DLL interface, when bind_ en gin e () is the interface when the interface call OpenSSL upper layer, the hardware encryption engine (hereinafter referred to as engine) perform the following operations:
  • Step 401 The engine sets the CSP name, and selects a corresponding CSP interface for the hardware encryption device.
  • the hardware encryption device may be a client's smart key device (such as a USB Key) and a server-side encryption machine.
  • Step 4011 Define a command CSP_SET in the engine, which is used to specify the CSP name.
  • the CMD command function that implements the CSP name specification is ENGINE_CTRL_FUNC_PTR, which is defined as follows: typedef int (*ENGINE_CTRL_FUNC_PTR)(ENGINE *, int, long, void *, void (*f)(void)) ;
  • the engine implements the above CMD command function
  • the CSP name is passed to the engine, and the CSP name is saved in the global variable; thus the engine can use the global variable when it needs to use the CSP name (such as calling the CryptAcquireContext function).
  • Step 4012 The engine registers the above implemented command into the engine by calling the ENGINE_set_ctrl_function() function.
  • the engine sets the CSP name to be the same as ENGINE_set_id and ENGINE_set_name.
  • the CSP interface implements the hardware encryption engine
  • different hardware encryption devices have different CSP interfaces, and the engine is distinguished according to the CSP name, that is, the CSP name corresponds to the CSP interface.
  • Step 402 The engine acquires a plug-in event of the hardware encryption device, acquires a handle for the CSP interface of the hardware encryption device, and establishes a connection with the hardware encryption device.
  • the engine obtains the WM_DEVICECHANGE type event by calling the system function WindowProc to obtain the plug-in event of the hardware encryption device.
  • the DBT_DEVICEARRIVAL message is an insert event
  • the DBT_DEVICEREMOVECOMPLETE message is an unplug event.
  • the WM_DEVICECHANGE type is an event for acquiring all USB devices (the USB device refers to a device with a USB interface, and the hardware encryption device may be a hardware encryption device using a USB interface, of course, the USB interface may not be used.
  • the hardware encryption device, and the system function WM_DEVICECHANGE reflects all USB interface devices), so calling it may also receive events from non-hardware encryption devices.
  • CryptAquireContext can also be obtained. Take the context structure of the hardware encryption device (that is, the CSP interface handle of the hardware encryption device can be obtained).
  • the CryptAcquireContext function is a function that has been defined in the CSP interface library.
  • the computer system automatically assigns a handle to the engine according to the CSP name set by the engine; thus, the engine obtains the CSP interface handle to operate the hardware encryption device.
  • Step 403 The engine creates an empty engine object engine through the ENGINE_new() function in the OpenSSL interface.
  • Step 404 Set the id and name of the engine object engine whose engine is empty, for example, ENGINE_set_id(engine, "rtl8651b"), ENGINE_set_name(engine, "BSD rtl8651b engine”).
  • Step 405 The engine obtains a list of algorithms of the hardware encryption device.
  • the engine obtains a list of algorithms of the hardware encryption device by using CryptGetProvParam of the CSP interface;
  • Step 406 The engine sets the EVP_CIPHER data structure for the upper layer OpenSSL application to call.
  • step 110 it has been described in step 110, and will not be described again here.
  • Step 407 Determine whether the pointer cipher of the encryption and decryption algorithm passed in the bincLengineO interface is empty. If yes, go to step 408. Otherwise, go to step 409.
  • the EVP_CIPHER obtains the encryption and decryption algorithm of the hardware encryption device, and becomes an encryption and decryption algorithm of the engine;
  • Step 408 The engine assigns the encryption/decryption algorithm list value in the OpenSSL interface to the cipher of the engine encryption and decryption algorithm, and returns the length of the encryption/decryption algorithm list in the OpenSSL interface.
  • the length of the encryption/decryption algorithm list refers to the number of encryption and decryption algorithms.
  • the pointer of the engine encryption and decryption algorithm When the pointer of the engine encryption and decryption algorithm is empty, since the encryption and decryption algorithm of the engine stores the encryption and decryption algorithm of the hardware encryption device, the pointer of the encryption and decryption algorithm of the engine is empty, and there is no encryption and decryption algorithm in the hardware encryption device. At this time, the value of the encryption and decryption algorithm in the OpenSSL interface is assigned to the pointer of the engine's encryption and decryption algorithm. When the engine's encryption and decryption algorithm is called, the engine will call the encryption and decryption algorithm in the OpenSSL interface according to the assigned pointer.
  • Step 409 According to the mapping relationship between the encryption and decryption algorithm of the hardware encryption device and the encryption and decryption algorithm in the OpenSSL interface, and the algorithm ID, find an encryption and decryption algorithm in the OpenSSL interface corresponding to the encryption and decryption algorithm of the hardware encryption device, and return to the OpenSSL interface. Encryption and decryption algorithm.
  • the hardware encryption device When the pointer of the engine encryption/decryption algorithm is not empty, the hardware encryption device includes an encryption and decryption algorithm. At this time, according to the mapping relationship between the encryption and decryption algorithm of the hardware encryption device and the encryption and decryption algorithm in the OpenSSL interface, and the algorithm ID, The encryption and decryption algorithm in the OpenSSL interface corresponding to the encryption and decryption algorithm of the hardware encryption device returns the encryption and decryption algorithm in the OpenSSL interface, that is, the encryption and decryption algorithm in the OpenSSL interface is stored in the symmetric encryption object of the engine. Thus, in the symmetric encryption object of the engine, the encryption and decryption algorithm in the OpenSSL interface that is mapped to the encryption and decryption algorithm in the hardware encryption device is stored.
  • FIG 9 is a flow chart of the encryption and decryption algorithm in the CSP interface dynamic library.
  • the hardware crypto engine does the following:
  • Step 501 Obtain an algorithm ID of the encryption and decryption algorithm in the OpenSSL interface corresponding to the encryption and decryption algorithm in the hardware encryption device from the init() interface context structure, and record it as the first algorithm ID.
  • the first algorithm ID is obtained by the ct X -> dph er -> n id variable of the context structure.
  • the ctx-> C iph er -> nid variable in the context structure is provided by the cipher object obtained by the engine.
  • Step 502 According to the mapping relationship between the encryption and decryption algorithm in the hardware encryption device and the encryption and decryption algorithm in the OpenSSL interface, obtain the encryption and decryption algorithm ID in the hardware encryption device corresponding to the first algorithm ID from the CSP interface dynamic library, and record it as The second algorithm ID stores the second algorithm ID in the engine, so that the engine sets the encryption and decryption algorithm currently used by the hardware encryption device to the encryption and decryption algorithm corresponding to the second algorithm ID.
  • the second algorithm ID is stored in a C iph er _d a t a ( C t X -> C iph er _dat a ) field in a context structure in the init() function.
  • the encryption and decryption algorithms that match the hardware encryption device with the algorithm parameters in OpenSSL establish a one-to-one mapping relationship.
  • the consistency of the algorithm parameters refers to the parameters such as the key length, the packet length, and the initial vector length.
  • the process of obtaining the second algorithm ID according to the mapping relationship between the encryption and decryption algorithm of the hardware encryption device and the encryption and decryption algorithm in the OpenSSL interface is exemplified herein.
  • the algorithm in the OpenSSL interface is IDEA (International Data Encryption Algorithm)
  • the algorithm in the dynamic library of the CSP interface is SSF33.
  • the mapping relationship between the two algorithms has been defined in the engine object.
  • the IDEA algorithm and the triple data encryption standard SSF33 algorithm The algorithm parameters are consistent.
  • the IDA algorithm ID is obtained by the ct X -> C iph er -> nid variable of the context structure of the advanced encryption standard AES algorithm. If the AES algorithm ID is obtained, the SSF33 algorithm is searched according to the mapping relationship, and the SSF33 is obtained.
  • the algorithm ID of the algorithm is the second algorithm ID.
  • Step 503 In the key information set, find the second algorithm ID, and determine whether it can be found. If it can be found, go to step 504; otherwise, go to step 505.
  • the key information for judging whether the second algorithm ID can be found in the key information set is specifically: by calling the EVP_Encryptlnit/EVP_Decryptlnit() function in the OpenSSL interface, and according to the EVP_Encryptlnit/EVP_Decryptlnit() function called.
  • the key value looks up the key information in the key information set. Wherein, the key information is found according to the value of the incoming key, which is specifically: searching in the key information set, and the search result is a key handle.
  • the parameter list of the EVP_Encryptlnit/EVP_Decryptlnit() function contains the initial vector value.
  • the encryption and decryption algorithm defines the key length, the key packet length, the initial vector length, the key value, the key handle, and the like in the EVP_CIPHER structure, and the information is called key information.
  • the key information of the key constitutes a set of key information.
  • Step 504 Store the key handle of the second algorithm ID into the context structure of the init() function.
  • the key handle is stored in the context structure of the engine's encrypted object.
  • Step 505 Create a key of the second algorithm ID, and add the key information of the key to the key information set.
  • the key is created by calling the CryptlmportKeyO function of the CSP interface to create the key.
  • the key template is created including key information such as a key value and a key handle.
  • Step 601 iph er do_ C in accordance with the key information set () interface context structure to find The key information corresponding to the second algorithm ID is extracted, and the key handle is taken out therefrom.
  • Step 602 In the CSP interface dynamic library, find an encryption and decryption algorithm ID that is the same as the second algorithm ID.
  • Step 603 The control hardware encryption device performs a packet encryption or decryption operation on the incoming data according to the encryption and decryption algorithm obtained by the searching.
  • the packet encryption and decryption operation includes an electronic codebook encryption and decryption mode EBC and a packet link encryption/decryption module CBC.
  • the C leap_ U p interface will be called to clean up the environment.
  • the key of clearing the key and key information of the second algorithm ID is mainly performed.
  • the clearing method is based on the context structure that is passed into the engine, and the key information. The corresponding key information is found in the set, and the key and key information are cleared.
  • the key and key signal in the hardware encryption device are destroyed by the C_DestroyObject function of the PKCS#11 interface; in addition, the hardware encryption engine can also pass the PKCS#11 interface after this.
  • the function C-CloseSession in the function closes the connection between the hardware encryption and the hardware encryption device;
  • the PKCS#11 interface C_Finalize can also be used to end the call of the hardware encryption engine to the entire PKCS#11 interface.
  • the hardware encryption engine provided by the invention extends some hardware encryption and decryption algorithms into the software algorithm library.
  • the hardware encryption engine can also support multi-threading and SSL communication.
  • multi-threading a mutex and a custom data structure are used to implement concurrency control. If the encryption/decryption algorithm also supports the SSL communication protocol (the key defined by the SSL protocol for encryption and decryption is separated), the key usage is also identified when the key is created.
  • encryption and decryption algorithms referred to in the above embodiments all refer to a symmetric encryption and decryption algorithm.
  • the hardware engine is an extension of existing software algorithm libraries (such as the OpenSSL dynamic library), providing users with an interface to add hardware algorithms.
  • the data structure provided by the hardware engine includes not only data, but also various methods (the method referred to herein refers to a set of algorithm callback functions), and the method is replaceable.
  • the hardware engine provides a default method. And by replacing the default method to achieve the purpose of increasing the algorithm.
  • the hardware engine provided by the present invention implements the id, name field, RSA_METHOD method, init(), finish(), destroy(), ctri-f(), load_privkey(), load_pubkey in the above data structure. () to implement the addition of symmetric algorithms in the smart key device to the existing software algorithm library;
  • the method of adding the algorithm in the smart key device to the OpenSSL dynamic library may also be implemented by replacing the methods DSA_METH, DH_METHOD, ECDH_METHOD, ECDSA_METHOD, RAND_METHOD, STORE_METHOD in the above data structure.
  • DSA_METH DH_METHOD
  • ECDH_METHOD ECDSA_METHOD
  • RAND_METHOD RAND_METHOD
  • STORE_METHOD in the above data structure.
  • the hardware engine id and name are set to determine the hardware engine to be loaded, and init() is used to initialize the PKCS#11 interface dynamic library to bind a specific function pointer.
  • the function pointer points to the function according to the engine data structure.
  • the function pointer is specifically implemented, for example: algorithm function in the smart key device; finishO is used to clear the resources occupied by the hardware engine; destroyO is used to clear the application resource; ctrl_f() is used to implement the custom command function; load_privkey() Used to load the private key; load_pubkey() is used to load the public key; load_ssl_client_cert is used to implement the loading of the certificate; the flags field is used to identify whether the algorithm used by the hardware engine is the default algorithm provided by the hardware engine or a custom algorithm.
  • the RSA_METHOD data structure defines the initialization/end interface init/ finish, the RSA public key encryption/decryption interface rsa_pub_enc/rsa_pub_dec, the RSA private key interface/decryption interface rsa_priv_enc/rsa_priv_dec, and the RSA signature/inspection interface rsa_mod_exp / bn_mod_exp, the implementation of RSA_METHOD is essentially the implementation of the above eight function interfaces;
  • the upper eight function interfaces can be selectively implemented, that is, selectively implemented according to the functions of the hardware engine; For example, if the hardware engine is used for asymmetric encryption/decryption operations, the RSA public key encryption/decryption interface and the RSA private key encryption/decryption interface need to be implemented, and the flags identifier in the RSA_METHOD structure is set to RSA_FLAG_EXT_PKEY, indicating that it is used for data exchange.
  • the RSA signature/checking interface is implemented, and the flags identifier in the RSA_METHOD structure is set to RSA_FLAG_SIGN_VER, indicating that it is used for signature operations, and so on.
  • the padding is the padding/de-filling mode, which is set by the user;
  • the flags field is used to identify which operation the RSA_METHOD data structure is used for, for example, if the flags is set to RSA_FLAG_SIGN_VER, the data structure is used for signature/ Check, then, rsa_sign / rsa_verify in the data structure will be used, and RSA_public_decrypt / RSA_private_encrypt will not be used, where the number of flags can be RSA_FLAG_EXT_PKEY (for
  • the initialization/end interface init/ finish is set to a null value, which is not used, and is not included in the scope of the present invention.
  • the remaining six function interfaces are described.
  • the hardware engine implements the engine binding interface bincLengineO and the engine initialization interface init() registered in the hardware engine data structure, the engine completion interface finish(), the engine destruction interface de S roy (), the custom function interface.
  • the hardware engine communicates with the smart key device connected to the host through the PKCS#11 (password token) interface dynamic library, and replaces the existing software algorithm library with the RSA algorithm in the smart key device.
  • the RSA algorithm performs data encryption and decryption, identity authentication, and the like by using a public-private key pair in the key device.
  • the PKCS#11 interface dynamic library is provided by the developer of the smart key device, and the internal details of the PKCS#11 interface dynamic library are not within the scope of the present invention.
  • Step 1101 Create an engine object e;
  • the ENGINE_new() function is defined in the OpenSSL dynamic library, and the engine object e created by the function is empty. Step 1102: Set an id and name for the created engine object e;
  • ENGINE_set_id (e, engine_rsaref_id); ENGINE_set_name(e, engine_rsaref_name) , when the upper application calls this function, it loads the engine of the phase / ⁇ according to the set engine id and the name.
  • Step 1103 Set crtl_f() to control the function of calling the custom command.
  • ctrl_f() is set by the ENGINE_set_ctrl_f_function() function
  • an example of a custom command is as follows:
  • the custom command implemented by the ctri_f() control in the embodiment of the present invention includes all the commands mentioned in the above example;
  • the custom command described in the above example is implemented by setting the command number field in ctri_f().
  • Step 1104 Set load_privkey()
  • load_privkey() is set by the ENGINE_set_load_privkey_ftmction() function.
  • Step 1105 Set load SS l_f() to implement loading of the certificate and the public-private key pair; Specifically, the callback function is set by the ENGINE_set_load_ssl_client_cert_function() function, in which the certificate and the public-private key pair are loaded; the upper-layer application is 3 ⁇ 4 overshoot l 0a d_ SS l_ C li en t_ C ert() Implement the loading of certificates and public-private key pairs; where loadssl_f() is described as follows:
  • the client certificate and the public-private key pair are loaded by setting the callback function ENGINE_set_load_ssl_client_cert_function();
  • Step 1106 Set load_pubkey()
  • load_pubkey() is set by the ENGINE_set_load_pubkey_function() function.
  • Step 1107 Setting an RSA_METHOD data structure
  • the RSA_METHOD data structure can be set by the ENGINE_set_RSA() function
  • setting the RSA_METHOD data structure means setting the RSA public key encryption/decryption interface rsa_pub_enc()/rsa_pub_dec(), RSA private key encryption/decryption interface rsa_priv_enc()/rsa_priv_dec(), RSA signature/test in the RSA_METHOD data structure.
  • the interface rsa_mod_exp()/bn_mod_exp() is a pointer to the SSL client authentication interface.
  • the program transfers to the RSA public key encryption/decryption interface rsa_pub_enc()/rsa_pub_dec(), RSA private key plus / decryption interface rsa_priv_enc () / rsa_priv_dec (), RSA signature / check interface rsa_mod_exp () / bn_mod_exp (), SSL client authentication interface processing flow.
  • setting the crtl_f() in the 3 ⁇ 43 ⁇ 4 poly 103 means setting the function pointer of crtl_f().
  • the program transfers to the processing flow of crtl_f(), as follows:
  • the enumCert command is set, when the command is invoked, the certificate list in the smart key device is returned, the certificate and the key are selected in the returned certificate list by selecting the certificate setCert command, and the selected certificate and key are saved.
  • the memory Into the memory;
  • the eC mCert command is implemented by calling C_FindObjectInit(), C_FindObjects() and C_FindObjectsFinal() in the PKCS#11 interface dynamic library.
  • C_Login() implements a login operation
  • C_GetSe SS i 0n Inf 0 () implements update of the login state of the smart key device
  • C_Logout() implements the logout operation
  • C_GetSe SS i 0n Inf 0 () implements the update of the smart key device logout state
  • crtl_f() when crtl_f() is called, the following operations can also be implemented: setting the name of the PKCS#11 interface dynamic library, selecting a slot slot; selecting a device number through the smart key device; setting the PIN of the selected slot Code; Get the total number of hardware encryption devices; etc.; and set the name of the PKCS#11 interface dynamic library, the selected slot slot, the selected device number, the PIN code of the set slot slot, and the total hardware encryption obtained.
  • the number of devices is stored in the cache and can be taken directly from the cache for subsequent use.
  • Step 1301 Load a PKCS#11 interface dynamic library
  • this step is accomplished by calling the system function loadlibraryO of the computer.
  • Step 1302 Obtain a function list of the PKCS#11 interface dynamic library
  • this step is completed by calling the C_GetFunctionList() function in the PKCS#11 interface;
  • this step may firstly obtain the C_GetFunctionList() function in the PKCS#11 interface at the entry point of the PKCS#11 interface by calling the computer system function GetProcAddressO. After the C_GetFunctionList() function is successfully executed, the The PKCS#11 function list obtained by the C-GetFunctionListO function obtains the entry point of other PKCS#11 interfaces; if the attempt fails, an error is returned.
  • the function list of the PKCS#11 interface dynamic library may be CK_FUNCTION_LIST_PTR.
  • the function list of the PKCS#11 interface dynamic library includes a pointer of a function pointer in the PKCS#11 interface dynamic library.
  • Step 1303 calling the function C_Initialize() defined in the PKCS#11 interface dynamic library to initialize the PKCS#11 interface dynamic library; here, it should be noted that, according to the specification standard of the PKCS#11 interface, it is necessary to perform other operations before the 3 ⁇ 4 line. Call C_Initiali Ze (). Further, during this process, the following operations can also be performed:
  • Step 1303' create and start a monitoring thread, and use the function C_WaitForSlotEvent() defined in the dynamic library of the PKCS#11 interface to monitor the insertion and removal events of the smart key device, so that the engine can be set according to the smart key in the subsequent processing.
  • the plug-in status responds in a timely manner.
  • Step 1304 Obtain a smart key device handle currently connected to the host
  • the device list of the smart key device currently connected to the host is obtained by calling the function C_GetSlotList() defined in the PKCS#11 interface dynamic library.
  • the smart key device corresponding to the smart key device serial number implemented in the control of crtl_f() is selected in the device list; correspondingly, the device list is selected The first smart key device in .
  • the smart key device connected to the slot slot controlled by crtl_f() in the device list may also be selected.
  • Step 1305 Establish a connection with the smart key device.
  • a connection is established with the smart key device by calling the function C_OpenSessionO defined in the PKCS#11 interface dynamic library.
  • the information interaction between the hardware engine and the smart key device is implemented through the PKCS#11 interface.
  • FIG 1402, 1403 are encryption
  • the RSA padding mode includes a padding mode or a padding mode, such as RSA PKCS1 and RSAX93 RSA SSLV23; Step 1401: Convert the incoming RSA key pair into a char array form;
  • the import of the RSA key pair is completed by calling (_0 ⁇ 1601 ⁇ ( ⁇ ) in the PKCS#11 interface.
  • Step 1402 Fill in the data before the incoming encryption
  • the root infilling method fills the encryption and decryption data
  • RSA_padding_add_none, RSA_padding_PKCSl_type_l, RSA_padding_PKCSl_type_2, RSA_padding_SSLv23 and other padding functions can be used to fill in the number before encryption and decryption;
  • RS A_padding_PKCS l_type_l is mainly used for padding of private key encryption, and RSA_padding_PKCS l_type_2 is mainly used for padding of public key encryption. .
  • Step 1403 Control the smart key device to perform encryption operation on the padded data, and output the encryption result.
  • the padded data is encrypted by calling the functions C_EncryptInit, C_Encrypt in the PKCS#11 interface dynamic library, and the encryption result is output through the to field of the public key encryption interface r Sa _pub_de C ().
  • the RSA padding mode includes a padding mode or a padding mode, such as RSA PKCS1 and RSA X93 RSA SSLV23; Step 1501: Converting the RSA private key into a char array form;
  • Step 1502 Fill in the data before the encryption and decryption
  • the root infilling method fills the encryption and decryption data
  • RSA_padding_add_none, RSA_padding_PKCSl_type_l, RSA_padding_PKCSl_type_2, RSA_padding_SSLv23 and other padding functions can be used to fill in the number before encryption and decryption;
  • RS A_padding_PKCS l_type_l is mainly used for padding of private key encryption, and RSA_padding_PKCS l_type_2 is mainly used for padding of public key encryption. .
  • Step 1503 Perform a login check. If the login has been performed, go to step 1505. Otherwise, go to step 1504.
  • Step 1504 Log in, verify the PIN code, and perform step 1505 after the verification is passed;
  • the login operation is completed by calling the function C_Login in the PKCS#11 interface dynamic library;
  • the login operation may also be performed when the smart key device establishes a connection with the host;
  • the maximum number of times of inputting the PIN code may be limited. If the number of times the accumulated input PIN code is incorrect exceeds the maximum number of input times, the operation ends.
  • Step 1505 Control the smart key device to perform encryption operation on the padded data, and output the encryption result.
  • the encryption and decryption specifically encrypts the padded data by calling C_SignRecoverInit, C.SignRecover in the PKCS#11 interface dynamic library. And the encrypted ⁇ data is output through the to field of the public key encryption interface r S a_pub_ enC ().
  • Step 1501 Create a summary structure X509_SIG according to the incoming summary mode ;
  • the summary structure X509_SIG is used to store the digest or signature value, defined in crypto/x509/x509.h, as follows:
  • algor is a digest algorithm, and digest is used to store digest or signature values.
  • digest is used to store digest or signature values.
  • the result of the calculation must be encoded by the X509_SIG structure for DER (Distinguished Encoding Rules), and then the private key can be used for calculation.
  • the digest is the abstract. value.
  • Step 1502 Control the smart key device to sign the incoming digest value
  • the smart key device performs signature calculation on the incoming digest value according to the loaded algorithm key
  • the loading of the algorithm key is implemented by the function load_ssl_client_cert(). It should be noted that if the algorithm key inside the smart key device is specified, the key of the specified ID is used for the signature operation. Specifically, the signature is completed by calling C_SignRecoverInit() and C_SignRecover() of the PKCS#11 interface.
  • the incoming smart key device ⁇ ] digest value includes the filled digest value, and the hardware engine fills the DER encoded digest value in the X509_SIG structure.
  • the 1024-bit RSA key must be filled. Fills up to 128 bytes, and the specific fill mode is specified by the user.
  • Step 1701 Perform public key decryption on the incoming signature value to obtain a digest value
  • Step 1702 Check whether the digest mode of the obtained digest value is consistent with the incoming "digest mode”. If they are consistent, perform the step.
  • Step 1703 Comparing the encrypted digest value with the incoming "digest value”, if the agreement is successful, the verification is successful, otherwise, the verification fails.
  • the load client certificate function interface ENGINE_set_load_ssl_client_cert_function() is called, the hardware engine performs the following operations:
  • the loading of the SSL client certificate and the operation of the public-private key pair are performed by the loadssLfO function;
  • the code is as follows:
  • the operation of the client certificate and the public-private key pair is performed by setting a callback function ENGINE_set_load_ssl_client_cert_function();
  • Step 1801 Find a certificate object from the smart key device.
  • Step 1802 Check whether the used certificate is used by the SSL client. If yes, go to step 1803. Otherwise, the operation ends.
  • the data structure X509_PURPOSE needs to be explained. The structure is used to check the certificate usage and is defined in x509v3.h. In, as follows: typedef struct x509_purpose_st
  • Purpose is the certificate use ID
  • check_purpose is the check certificate usage function
  • X509_PURPOSE when checking the purpose of the certificate, find the corresponding X509_PURPOSE, call its check_purpose function to determine whether the certificate is valid, and check the certificate usage by the function X509_check_purpose (X509 *x, int id, int ca), where x is to be checked.
  • the certificate uses NID, ca to indicate whether X is a ca certificate.
  • Step 1803 according to the obtained certificate for the SSL client, find the matching public-private key pair object in the smart key device, and if the matching certificate is not found, report an error;
  • Step 1804 Perform SSL client authentication.
  • the hardware engine performs the SSL client authentication operation when the other party requests to verify the client certificate.
  • the interface finishO will be called by the upper application, and the use of the smart key device is ended.
  • the interface de S t roy _f() is called by the upper application to release the occupied resources;
  • connection between the hardware engine and the smart key device can be closed through the function C-CloseSession in the PKCS#11 interface;
  • the hardware engine can communicate with the smart key device through the CSP interface.
  • the CSP interface Such as:
  • the hardware engine loads the key through the CSP interface HCRYPTKEY hKey;
  • the hardware engine establishes a connection with the smart key device through the CSP interface. There is a slight difference between the implementation of the custom command and the PKCS#11 interface.
  • the commands are as follows:
  • enumcontainer enumeration container (enumerate signature / check container or key exchange class container);
  • usecontainer selects the container
  • setpin sets the PIN code of the selected container
  • the above commands are custom commands and are for reference only.
  • Each command function needs to be implemented by a function, and the control callback function is responsible for invoking control. It should be noted that the "setflags" setting flag command.
  • the flag set by this command is the flag in the CryptAcquireContextO function, which can be the following values:
  • CRYPT_VERIFYCONTEXT set this flag, the application can not access the private key or public and private key pairs, for example, the application is only used for hashing or symmetric encryption and decryption operations.
  • CRYPT_NEWKEYSET sets the flag to create a new container.
  • the CSP is in a container unit. Therefore, it is necessary to provide a command for enumerating the container, so that the user selects the container, and the hardware engine loads the key and the certificate through the container.
  • the controller first selects the container selected by the custom command, and extracts the key handle from the container, and performs data encryption and decryption according to the key handle;
  • the EVP_MD structure is used to store the information of the information digest algorithm, and the digest engine completes the corresponding digest operation by implementing the EVP_MD structure.
  • the EVP_MD structure is described as follows: : typedef struct env_md_st
  • Type the NID identifier of the message digest algorithm (the ID number of the algorithm), used to indicate the information digest algorithm used;
  • Md.size the length of the digest value (in bytes) generated by the message digest algorithm. If the EVP_MD structure encapsulates the SHA1 algorithm, the field is SHA1_DIGEST_LENGTH, and the value is 20;
  • Init points to the initialization function of the message digest algorithm. If the EVP_MD structure encapsulates the SM3 algorithm, it points to
  • Update A function that points to the digest value. If the EVP_MD structure encapsulates the MD5 algorithm, it points to MD5_update . final—points to the function to be called after the digest value is calculated. This function completes the processing of the last block.
  • the EVP_MD structure encapsulates the SHA256 algorithm and points to SHA256_final;
  • Block.size Specifies the packet length (in bytes) of the data block when the digest operation is performed. If the EVP_MD structure encapsulates the SHA1 algorithm, the field is SHA1_CBL0CK with a value of 64.
  • Ctx.size Specifies the size of the CTX (context) space required to implement the message digest algorithm. If the EVP_MD structure encapsulates the SHA algorithm, the field refers to sizeof(EVP_MD*)+sizeof(SHA_CTX)
  • the digest engine provided by the present invention implements the engine binding interface bincLengineO and the initialization interface init(), the first digest interface updata(), the second digest interface final(), and the engine release interface cleanupO registered in the EVP_MD structure.
  • the digest engine implements an extension of the information digest algorithm in the existing software algorithm library; wherein, bincLengineO is used for the binding engine, init() is used to initialize the digest algorithm, and updata() is used for digesting the incoming information digest data, finalO is used for End the digest operation and output the digest value. cleanupO is used to clear the EVP_MD structure of the message digest algorithm.
  • the summary engine communicates with the smart key device connected to the host through the PKCS#11 (public key cryptography standards) interface dynamic library, so as to add the information digest algorithm in the smart key device to the present
  • the information digest algorithm in the smart key device is called to perform the digest operation of the data.
  • the PKCS#11 interface dynamic library is provided by the developer of the smart key device, and the internal details of the PKCS#11 interface dynamic library are not within the scope of the present invention.
  • Step 1901 The engine loads the PKCS#11 interface dynamic library
  • this step is accomplished by calling the system function loadlibraryO of the computer.
  • the file name of the PKCS#11 interface dynamic library is pre-agreed.
  • Step 1902 The engine obtains a function list in the PKCS#11 interface dynamic library.
  • this step is accomplished by calling the C_GetFunctionList() function in the PKCS#11 interface.
  • this step may firstly obtain the C_GetFunctionList() function in the PKCS#11 interface at the entry point of the PKCS#11 interface by calling the computer system function GetProcAddressO. After the C_GetFunctionList() function is successfully executed, other PKCS#11 may be obtained. The entry point of the interface, and can call these interfaces to obtain a list of functions of the PKCS#11 interface dynamic library; if the attempt fails, an error is returned.
  • the function list of the PKCS#11 interface dynamic library may be CK_FUNCTION_LIST_PTR
  • the obtained function list contains the pointer of the function pointer in the PKCS#11 interface dynamic library, so that in the future operation, the engine can implement the PKCS#11 interface dynamic library by calling the pointer of the obtained function pointer.
  • the function is called.
  • the engine calls C_Initiali Z e() in the PKCS#11 interface dynamic library, which can be implemented by calling the pointer of the obtained C_Initiali Z e() pointer.
  • Step 1903 the engine calls C_Initialize(), Initialize the PKCS#11 interface dynamic library;
  • the C_Initiali Ze () interface must be called first before performing other operations.
  • the engine creates and starts a monitoring thread for monitoring the plug-in event of the smart key device for timely response in subsequent processing; preferably, monitoring the plug-in event of the smart key device (insertion or removal of the smart key device) ) is implemented by calling the function C_WaitForSlotEvent() defined in the PKCS#11 interface dynamic library.
  • monitoring the plug-in status of the smart key device is to promptly inform the current state of the smart key device. If the smart key device is removed, the engine closes the session with the smart key device in time. If the smart key device is inserted, the engine promptly opens a session with the smart key device to improve work efficiency, and at the same time, avoids the engine temporarily opening the session when using the smart key device, and the smart key device is unplugged. The state, which causes an error condition to occur.
  • Step 1904 The engine acquires a smart key device handle currently connected to the host;
  • the engine obtains the smart key key device column by calling the function C_GetSlotList() defined in the PKCS#11 interface dynamic library.
  • Step 1905 The engine establishes communication with the smart key device.
  • connection between the engine and the smart key device is implemented by calling a function C_OpenSe SS i 0n () defined in the PKCS#11 interface dynamic library.
  • Step 1906 the engine creates an engine object, such as engine
  • the engine is implemented by calling ENGINE_new();
  • Step 1907 The engine sets an id and a name for the created engine object.
  • the engine id and the name are set by registering the function ENGINE_set_id(e, engine_cipher_id), ENGINE_set_name(e, engine_cipher_name), for example, ENGINE_set_id(engine, "rtl 865 lb"), ENGINE_set_name(engine, "BSD rtl8651b engine”; ).
  • ENGINE_set_id e, engine_cipher_id
  • ENGINE_set_name e, engine_cipher_name
  • Step 108 Obtain a list of algorithms of the smart key device
  • the algorithm list is obtained by calling C_GetMechanismList defined in the PKCS#11 interface dynamic library.
  • the algorithm list includes information summary algorithm attributes, such as group degree, summary value length, and the like.
  • ⁇ CKM SHA—1, ⁇ 0, 0, CKF_DIGEST ⁇ ⁇ .
  • Step 1909 Fill the EVP_MD structure according to the obtained algorithm list, so as to be called by the upper layer application;
  • the specific filling method is: setting any corresponding algorithm ID number according to the definition of the upper layer application for any digest algorithm in the obtained algorithm list; setting the digest value length mcLsize, the packet length block-size according to the value in the algorithm list, It also indicates the size of the space that needs to be allocated when implementing the digest algorithm, and sets the init(), updata(), final(), and cleanupO interface pointers.
  • Step 1910 Obtain an EVP_MD structure of the digest algorithm.
  • call ENGINE_ Se t_dig eS ts provided digest algorithm current engine supported by, and get EVP_MD structure digest algorithm to obtain user interface and digest algorithms attribute EVP_MD configuration package, comprising: init user interface, UPDATA operation The interface, the final operation interface, the cleanup operation interface, the packet length of the message digest algorithm, the length of the digest value, and the space size of the context.
  • Step 1911 Implement binding of the information digest algorithm and the engine
  • ENGINE_register_digests adds the information digest algorithm supported by the current engine to the algorithm table in the upper application, and associates with the engine, so that when the layer application uses the information digest algorithm, it can be obtained.
  • the EVP_MD structure and related attributes of the message digest algorithm.
  • the parameters passed in include: context and information of the information digest algorithm stored in the EVP_MD structure, including the grouping of the information digest algorithm. Length, summary value length, message digest algorithm ID, etc.
  • init() the parameters of init() are described as follows:
  • EVP_MD_CTX a brief description of EVP_MD_CTX is as follows:
  • EVP_MD_CTX the parameters in the EVP_MD_CTX structure are as follows:
  • the engine is created by the upper application, and is associated with the algorithm list when calling bind_ en gin e (), and the information summary data is determined by the specific operation process.
  • Step 2001 setting a currently used information digest algorithm
  • the corresponding information digest algorithm is searched according to the incoming information digest algorithm ID, and if not found, the currently used information digest algorithm is set as the default information digest algorithm, and if found, the currently used information digest is The algorithm is set to an information digest algorithm corresponding to the type of the incoming message digest algorithm;
  • the message digest algorithm ID is passed in along with EVP_MD_CTX.
  • the digest in the EVP_MD_CTX structure is executed, it points to the EVP_MD structure, and the information digest algorithm ID in the structure is passed to the init() interface.
  • Step 2002 Allocate memory space for EVP_MD_CTX (context);
  • the memory is allocated.
  • Step 2003 initializing the context
  • assigning an initial value to a context is determined by a specific operation process.
  • the parameters passed in include:
  • the summary engine caches the incoming message summary data, and controls the smart key device to perform a digest operation on the incoming message summary data according to the currently set information digest algorithm, and cache the operation result;
  • the digest operation is performed more than once in the interface, and the number of operations is determined by a specific operation process.
  • the digest operation can be completed by calling the C_Dig es tUpdate function of the PKCS#11 interface.
  • the parameters passed in include:
  • the summary engine controls the smart key device to end the digest operation, and outputs the operation result, specifically, outputs the result through the md field;
  • the digest operation can be completed by calling the C_Di geS tFi na l function of the PKCS#11 interface.
  • the cleaupO interface will be called to clean up the environment
  • the abstract engine can communicate with the smart key device through the Cryptographic Service Provider (CSP) interface.
  • CSP Cryptographic Service Provider
  • the specific process is similar to the process when communicating through the PKCS#11 interface, and will not be described here.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)

Description

加密引擎的实现方法
技术领域 本发明属于信息安全技术领域， 尤其涉及一种加密引擎的实现方法， 将只能用硬件实现的信息算 法添加扩展到现有的软件算法库中， 以提高信息运算的安全性。 背景技术
SSL是 Secure Socket Layer的英文缩写,意思是安全套接层协议，指使用公钥和私钥技术组合的安全 网络通讯协议。 SSL协议是网景公司 (Netscape)推出的基于 WEB应用的安全协议， 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已经不仅仅是一个 加密库， 而且还是一个通用的加密接口， 能够与绝大部分加密库或加密设备协调工作。 发明内容 本发明的目的在于提供一种加密引擎的实现方法， 其可以将只能用硬件实现的信息算法添加扩展到现 有的软件算法库中， 从而提高了信息运算的安全性。
一种硬件引擎的实现方法，上层应用程序通过调用所述引擎的引擎绑定接口、初始化接口、第一接口、 弓 I擎释放接口来实现， 其中， 所述第一接口包括数据加解密接口；
或者， 所述第一接口包括
第二数据结构中的加解密接口、 签名接口、 验签接口和 SSL客户端认证接口；
或者， 所述第一接口包括
第一摘要接口和第二摘要接口；
其中， 当所述第一接口包括数据加解密接口时， 所述初始化接口为密钥初始化接口， 并且所述方法包 括：
弓 I擎绑定接口被上层应用程序调用时， 所述引擎与智能密钥设备建立连接， 获取所述智能密钥设备的 算法列表， 并填充第一数据结构；
密钥初始化接口被上层应用程序调用时， 所述引擎根据传入的所述第一数据结构设置所述智能密钥设 备当前所要使用的加解密算法， 并检索相应的算法密钥， 如果检索不到， 则控制所述智能密钥设备创建所 述算法密钥；
数据加解密接口被上层应用程序调用时， 所述引擎根据当前设置的加解密算法和算法密钥， 控制所述 智能密钥设备对传入的数据进行加 /解密操作， 并输出操作结果；
弓 I擎释放接口被上层应用程序调用时， 所述引擎结束与所述智能密钥设备的连接；
当所述第一接口包括第二数据结构中的加解密接口、 签名接口、 验签接口和 SSL客户端认证接口时， 所述初始化接口为引擎初始化接口， 并且所述方法包括：
弓 I擎初始化接口被上层应用程序调用时， 所述引擎与智能密钥设备建立连接；
引擎绑定接口被上层应用程序调用时， 绑定所述引擎， 并加载算法密钥和证书， 及设置所述第二数据 结构， 所述算法密钥包括公钥和私钥；
第二数据结构中的加解密接口被上层应用程序调用时， 所述引擎根据所述加载的算法密钥， 控制所述 智能密钥设备对传入的数据进行加 /解密操作， 并输出操作结果；
第二数据结构中的签名接口被上层应用程序调用时， 所述引擎根据所述加载的算法密钥， 控制所述智 能密钥设备对传入的摘要值进行签名操作， 并返回签名结果；
第二数据结构中的验签接口被上层应用程序调用时， 所述引擎根据所述加载的算法密钥， 控制所述智 能密钥设备对传入的签名值进行解密操作， 并验证所述解密得到的摘要值是否正确， 正确， 则验签成功， 否则， 验签失败；
第二数据结构中的 SSL客户端认证接口被上层应用程序调用时， 所述引擎根据所述加载的证书， 控制 所述智能密钥设备进行 SSL客户端认证， 并返回认证结果；
当弓 I擎释放接口被上层应用程序调用时， 所述引擎结束与所述智能密钥设备的连接；
当所述第一接口包括第一摘要接口和第二摘要接口时， 所述方法包括：
弓 I擎绑定接口被上层应用调用时， 所述引擎与智能密钥设备建立连接， 获取所述智能密钥设备的算法 列表， 并填充第三数据结构， 将所述第三数据结构登记到所述上层应用中；
初始化接口被上层应用调用时， 所述引擎根据传入的所述第三数据结构设置所述智能密钥设备当前所 使用的信息摘要算法， 并为传入的上下文分配存储空间， 及初始化所述上下文；
第一摘要接口被上层应用调用时， 所述引擎根据当前设置的信息摘要算法， 控制所述智能密钥设备对 传入的信息摘要数据进行摘要运算；
第二摘要接口被上层应用调用时， 所述引擎控制所述智能密钥设备结束摘要运算， 并输出运算结果； 弓 I擎释放接口被上层应用程序调用时， 所述引擎结束与所述智能密钥设备的连接。
本发明的效果在于： 通过加密引擎， 将一些硬件加解密算法， 尤其是一些未公开的， 只能用硬件实现 的加解密算法添加扩展到软件算法库中； 通过加密引擎， 将一些硬件摘要算法， 尤其是一些未公开的， 只 能用硬件实现的信息摘要算法添加扩展到现有的软件算法库中， 提高了信息摘要运算的安全性。 附图说明 图 1是硬件加密设备的加解密算法与 OpenSSL库中的加解密算法的映射关系示意图；
图 2是硬件加密设备的加解密算法传入引擎得到引擎的加解密算法示意图；
图 3是 OpenSSL接口中的加解密算法列表值赋值给引擎的加解密算法的指针示意图；
图 4是返回与硬件加密设备的加解密算法相对应的 OpenSSL库中的加解密算法示意图；
图 5是引擎绑定流程图；
图 6是获取 PKCS#11接口动态库中的加解密算法流程图；
图 7是分包加解密流程图；
图 8是另一种引擎绑定流程图；
图 9是获取 CSP接口动态库中的加解密算法流程图；
图 10是一种分包加解密流程图。
图 11为本发明实施例提供的引擎绑定接口 bincLengine被调用时的流程图；
图 12为本发明实施例提供的 crtl_f()接口被调用时的流程图；
图 13为本发明实施例提供的引擎初始化接口 init被调用时的流程图；
图 14为本发明实施例提供的公钥加密接口 rSa_pub_enc被调用时的流程图；
图 15为本发明实施例提供的私钥加密接口 rSa_piv_enC被调用时的流程图；
图 16为本发明实施例提供的签名接口 rSa_Sign被调用时的流程图；
图 17为本发明实施例提供的验签接口 rSa_Verify被调用时的流程图；
图 18为本发明实施例提供的加载客户端证书接口 ENGINE_set_load_ssl_client_cert_function被调用时 的流程图。
图 19为本发明实施例提供的引擎绑定接口被上层应用程序调用时的流程图； 图 20为本发明实施例提供的初始化接口被上层应用程序调用时的流程图。 具体实施方式 下面结合附图， 对优选实施例作详细说明。 应该强调的是， 下述说明仅仅是示例性的， 而不是为了限 制本发明的范围及其应用。
实施例 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接口动态库的内部细节不在本发明描述的范围。
本发明提供的硬件加密弓 I擎通过注册在 OpenSSL接口中的 bind_engine()、 init()、 do_cipher()和 clean_up() 等四个函数实现。 其中， 引擎绑定接口 bincLengineO用于绑定引擎； 密钥初始化接口 init()用于获取硬 加 密接口动态库中的加解密算法并初始化密钥及密钥信息； 数据加解密接口 d0_cipher()用于进行数据的分包 加密或解密操作； 弓 I擎释放接口 Clean_up()用于释放引擎。
下面以标准 C语言编程为例， 并结合 PKCS#11接口动态库与 OpenSSL接口来说明本发明中硬件加密 引擎 （以下简称引擎） 的实现过程。
如图 5所示，当 bincLengineO接口被上层应用程序 OpenSSL接口调用时，硬件加密引擎执行如下操作： 步骤 101、 引擎加载 PKCS#11接口动态库。
优选地， 本步骤通过调用计算机的系统函数 loadlibraryO来完成， 该 PKCS#11接口动态库的文件名是 预先约定的。
步骤 102、 引擎获取 PKCS#11接口动态库的函数列表。
优选地， 本步骤通过调用 PKCS#11接口中的 C_GetFunctionList()函数完成；
进一步地， 本步骤还可以先通过调用计算机系统函数 GetProcAddressO尝试获取 PKCS#11 接口中的 C_GetFunctionList()函数在 PKCS#11接口的入口点， 调用 C_GetFunctionList()函数成功后， 就可获得其他
PKCS#11接口的入口点， 并且能够调用这些接口获得 PKCS#11接口动态库的函数列表； 如果尝试失败， 则报错返回。
具体地， PKCS#11接口动态库的函数列表可以是 CK_FUNCTION_LIST_PTR。
需要说明的是， PKCS#11接口动态库的函数列表包含 PKCS#11接口动态库中函数指针的指针。
步骤 103、引擎通过调用 PKCS#11接口动态库中定义的函数 C_Initialize()来初始化 PKCS#11接口动态 库。
具体地 ， 调用 PKCS#11接口动态库中定义的函数 C_Initialize()是通过步骤 102中获取的 PKCS#11接 口动态库的函数列表中函数 C_InitialiZe()指针的指针来实现的。
需要说明的是， 根据 PKCS#11接口的规范标准， 在进行其他操作之前必须要首先调用该 C_InitialiZe() 接口。
步骤 104、 引擎创建并启动一个监控线程， 用于监控硬件加密设备的插拔事件， 并将硬件加密设备的 插拔状态存储在自定义的数据结构中。
优选地， 监控硬件加密设备的插拔事件 （硬件加密设备的插入或拔除） 是通过调用 PKCS#11 接口动 态库中定义的函数 C—WaitForSlotEventO来实现的， 并根据监控到的插拔状态来及时更新自定义数据结构。
其中， 调用 PKCS#11 接口动态库中定义的函数 C_WaitForSlotEvent()具体是通过步骤 102 中获取的 PKCS#11接口动态库的函数列表中函数 C_WaitForSlotEvent()指针的指针来实现调用的。
具体地， 自定义数据结构是指槽列表信息的集合， 其中， 槽列表信息包含硬件加密设备的插拔状态信 息。
" 具体地， PKCS#11接口动态库中定义的槽列表信息数据结构中包含槽描述、 制造商 ID、 性能标识符、 硬件序列号、 固件序列号等信息。
步骤 105、 引擎获取槽列表信息， 得到硬件加密设备的插拔状态。
优选地， 引擎获取槽列表信息通过调用 PKCS#11接口动态库中定义的函数 C_GetSlotList()来实现， 得 到硬件加密设备的插拔状态， 并获取当前连接到主机的硬件加密设备句柄， 如果当前存在多个硬件加密设 备连接到主机， 则选择所述列表中的第一个硬件加密设备。
具体地， 调用 PKCS#11动态库中定义的函数 C_GetSlotList()是通过步骤 102中获取的 PKCS#11接口 动态库的函数列表中函数 C_GetSlotLiStO指针的指针—来实现调用的。
步骤 106、 引擎与硬件加密设备建立连接， 以便对硬件加密设备进行操作。
优选地，引擎与硬件加密设备建立接连是通过调用 PKCS#11接口动态库中定义的函数 C_OpenSeSSi0n() 来实现的。
具体地， 调用 PKCS#11接口动态库中定义的函数 C_OpenSession()是通过步骤 102中获取的 PKCS#11 接口动态库的函数列表中函数 C—OpenSessionO指针的指 Ϊ十来实现调用的。
需要说明的是： 步骤 105中， 获取槽列表信息中硬件加密设备的插拔状态是为了能及时告知引擎该硬 件加密设备的当前状态， 如果， 硬件加密设备被拔除， 则引擎及时关闭与硬件加密设备的会话， 如果， 硬 件加密设备被插入， 则及时引擎开启与硬件加密设备的会话， 以便提高工作效率， 同时， 避免了引擎在使 用硬件加密设备时临时开启会话， 而硬件加密设备是拔除状态， 从而造成错误情况的出现。
步骤 107、 引擎通过 ENGINE_new()函数来创建一个空的引擎对象 engine。 其中， ENGINE_new()函 数是 OpenSSL接口中已定义的。
步骤 108、 引擎为引擎对象 engine设置 id及名称， 例如 ENGINE_set_id(engine,"rtl8651b")，
ENGINE_set_name(engine,"BSD rtl8651b engine")。
步骤 109、 引擎获取硬件加密设备的算法列表；
具体地， 通过调用 PKCS#11接口中的 C_GetMechanismList来获取算法列表；
例如， 取得的算法列表是
{CKM—SHA—1, { 0, O' CKF—DIGEST} },
{CKM—DES—ECB, { 8, 8,
CKF_ENCRYPTICKF_DECRYPTICKF_WRAPICKF_UNWRAP } } ,
{CKM—DES—CBC, { 8, 8,
CKF_ENCRYPTICKF_DECRYPTICKF_WRAPICKF_UNWRAP } } ,
{CKM_DES3_ECB, { 24, 24, CKF_ENCRYPTICKF_DECRYPTICKF_WRAPICKF_UNWRAP } }，
{CKM_DES3_CBC, { 24, 24，
CKF_ENCRYPTICKF_DECRYPTICKF_WRAPICKF_UNWRAP } }，
步骤 110、 引擎设置加解密对象 EVP.CIPHER数据结构， 以便供上层 OpenSSL应用程序调用。 其中， EVP_CIPHER数据结构的定义是 OpenSSL中已有的， 具体如下：
struct evp_cipher_st
{
int nid;
int block—size;
int key_len; I* Default value for variable length ciphers */
int iv_len;
unsigned long flags; /* Various flags */
int (*init)(EVP_CIPHER_CTX *ctx, const unsigned char *key，
const unsigned char *iv, int enc); /* init key */
int (*do_cipher)(EVP_CIPHER_CTX *ctx, unsigned char *out,
const unsigned char *in, unsigned int inl);/* encrypt/decrypt data */
int (*clean_up)(EVP_CIPHER_CTX *); I* 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 *); /* Get parameters 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: 加解密的分组长度
keyjen: 密钥长度
ivjen: 初始向量长度
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_dpherS()函数来实现的， 并根据 OpenSSL的定义， 设置对应的 nid。
其中， ENGINE_set_ciphers函数的定义如下：
int ENGINE_set_ciphers(ENGINE *e, ENGINE—CIPHERS— PTR f)。
e: 引擎对 ^旨 t
f: 引擎中对称算法选取的回调函数
f回调函数的定义如下：
typedef int (*ENGINE_CIPHERS_PTR)(ENGINE *e, const EVP— CIPHER **cipher, const int **nids, int nid)。
e: 引擎对象指针
cipher: EVP_CIPHER指针的指针
nids是对称 ^法列表值 （即 int数组）
nid是算法 ID号， 在获取引擎对象时传入的。
具体地， 引擎根据获取的算法列表来填充 EVP-CIPHER数据结构；
例如， 算法列表中的 {CKM_DES3_CBC， { 24, 24，
CKF_ENCRYPTICKF_DECRYPTICKF_WRAPICKF_UNWRAP} } , 表示智能密钥设备支持 CBC (分组链接 加密）模式的 3DES加解密操作， 分组长度和密钥长度都是 24字节。 贝 I」， 对应的 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 禾 B Encrypt_Filnal 是引擎内部的接口， 分别通过
PKCS#11接口来完成加密操作。
步骤 111、 弓 I擎判断从 bincLengineO接口传入的加解密算法指针 cipher是否为空， 如果为空， 则执行 步骤 112， 否则， 执行步骤 113。
具体地， 根据 bincLengineO接口传入硬件加密设备的加解密算法， EVP_CIPHER获得硬件加密设备的 加解密算法， 成为引擎的加解密算法；
步骤 112、 引擎将 OpenSSL接口中的加解密算法列表值赋值给引擎的加解密算法指针 cipher, 并返回 OpenSSL接口中的加解密算法列表长度。
其中， 所述加解密算法列表长度指的是加解密算法的数量。
当引擎的加解密算法的指针为空时， 因为引擎的加解密算法存储的是硬件加密设备的加解密算法， 所 以引擎的加解密算法的指针为空说明， 硬件加密设备中没有加解密算法。此时， 将 OpenSSL接口中的加解 密算法列表值赋值给引擎的加解密算法的指针，在引擎的加解密算法被调用时，引擎会根据被赋值的指针， 调用 OpenSSL接口中的加解密算法。
步骤 113、 根据硬件加密设备的加解密算法与 OpenSSL接口中的加解密算法的映射关系和算法 ID, 找到与硬件加密设备的加解密算法对应的 OpenSSL接口中的加解密算法， 返回该 OpenSSL接口中的加解 密算法。
当引擎的加解密算法的指针不为空时， 说明硬件加密设备中包含加解密算法， 此时根据硬件加密设备 的加解密算法与 OpenSSL接口中的加解密算法的映射关系和算法 ID， 找到与硬件加密设备的加解密算法 对应的 OpenSSL接口中的加解密算法， 返回该 OpenSSL接口中的加解密算法， 即将 OpenSSL接口中的加 解密算法存储在引擎的对称加密对象中。 这样， 引擎的对称加密对象中， 存储的就是与硬件加密设备中的 加解密算法有映射关系的 OpenSSL接口中的加解密算法了。
在 bind_engine()函数调用结束， init()函数被调用之前， OpenSSL接口还要执行以下的操作： OpenSSL 接口通过调用 ENGINE_init()函数来初始化该引擎； OpenSSL接口通过调用 ENGINE_set_default_ciphers() 函数将引擎提供的加解密算法设置成为引擎默认的加解密算法; OpenSSL接口从引擎 获 ¾X EVP.CIPHER 对象和算法 ID， 并调用 EVP_Encryptlnit/EVP_Decryptlnit()函数， 转入引擎的 init()函数。
首先， 需要知道的是， initO接口被上 jl openSSL应用程序调用时， 传入 init()接口的参数有： int (*init)(EVP_CIPHER_CTX *ctx,〃上下文
const unsigned char *key,〃对禾尔密钢值
const unsined char *iv, II初始向量
int enc);
其中， init()函数中的上下文结构 EVP_CIPHER_CTX如下：
struct evp_cipher_ctx_st
{
const EVP—CIPHER *cipher;
ENGINE *engine; I* functional reference if 'cipher' is ENGINE-provided */
int encrypt; I* encrypt or decrypt */
int buf_len; I* 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_BLOCK_LENGTH] ;/* saved partial block */
int num; /* used by cfb/ofb mode */
void *app_data; /* application stuff */
int key_len; I* May change for variable length cipher */
unsigned long flags; I* Various flags */
void *cipher_data; /* per EVP data */
int final—used;
int block—mask;
unsigned char final [EVP—MAX—B LOCK—LENGTH];/* possible final block */
} I* EVP_CIPHER_CTX */;
typedef struct evp_cipher_ctx_st EVP_CIPHER_CTX;
参数为：
cipher: 算法指针
engine: 加解密引擎
encrypt: 加密或解密
bufjen: 剩余空间
oiv: 原始的初始向量
iv: 当前的初始向量
buf: 保存的部分块数据
num: cfb/ofb方式时的数据数量
app.data: 应用相关数据
keyjen: 密钥长度
flags: 标志
cipher.data: 各算法相关部分， 主要是各算法的 key等
final—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)字段中。 其中，在引擎中，将硬件加密设备与 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_FindObjects()、 C_FindObjectFilal()函数在密钥信息集合中 进行査找， 而査找结果是密钥句柄。
在采用 CBC (分组链接）加密模式时， 所述 EVP_Encryptlnit/EVP_Decryptlnit()函数被调用时传入的参 数还包含初始向量值。 另外， 需要说明的是， EVP_CIPHER数据结构中定义了密钥长度、 密钥分组长度、 初始向量长度、 密钥值、 密钥句柄等信息， 上述信息被称之为密钥信息， 不同算法密钥的密钥信息构成密钥信息集合。
步骤 204、 将第二算法 ID的密钥句柄存储到 init()函数的上下文结构中。
具体地， 将第二算法 ID的密钥句柄存储到引擎中加解密对象的上下文结构中。
步骤 205、 创建第二算法 ID的密钥， 并将所述密钥的密钥信息添加到密钥信息集合中。
创建密钥具体是通过调用 PKCS#11 接口动态库的 C—CreateObjectO函数来创建密钥模板。 其中， 创建 密钥模板包括密钥类型、 密钥标识、 密钥值以及密钥句柄等密钥信息。 密钥标识标识密钥是加密密钥还是 解密密钥； 密钥句柄是供加解密函数使用的。
具体地， 例如， 当 Encrypt_SSF33_CBC_Init()接口被调用时， 执行下列操作：
步骤 2051 : 通过 PKCS#11接口 C_CreateObject创建密钥对象， 将上层应用的密钥导入硬件加密设备。 进一步地， 也可以通过 PKCS#11 Ϊ妾口 C_GenerateKey控制硬件加密设备创建密钥。
步骤 2052:通过 PKCS#11接口 C_EncryptInit()进行加密初始化操作，将算法设为 CKM_ SSF33_CBC。 其中， CKM_ SSF33_CBC表示 CBC模式的 SSF33加解密操作。
Encrypt—Update 禾 B Encrypt. Final 分别通过 PKCS#11 接口 C_EncryptUpdate 禾 B PKCS#11 接口 C.EncryptFinal完成后续的加密操作。
其中， 解密操作的处理与加密类似， 不再赘述。
其中， 具体算法与算法索引的对应关系保存在引擎内部。
在 init()调用结束， do_cipher()函数调用之前， OpenSSL调用 EVP_EncryptUpdata/EVP_DecryptUpdata() 函数， 而通过上述接口函 的被调用， 引擎向上层应用提交硬件加密设备的算法列表， 也确定了当前硬件 加密设备所要使用的加解密算法， 上层应用程序便可以使用硬件加密设备中的算法了， 而这一步具体是通 过调用 do_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 bufjen; //当前要处理的数据长度
unsigned char oiv[EVP_MAX_IV_LENGTH]；〃初始起始变量
unsigned char iv[EVP_MAX_IV_LENGTH]；〃当前初始变量
unsigned char buf[EVP_MAX_BLOCK_LENGTH];〃保存的部分数据块
int num; //仅供 CFB/OFB模式使用
void *app_data; //其他附加数据
int keyjen; //密钥长度
unsigned long flags;〃标志位
void *cipher_data; //各算法相关部分， 主要是各算法的 key等
int final—used;
int block—mask；〃块的掩码
unsigned char final [EVP_MAX_BLOCK_LENGTH] ;11最后的分组块
} /* EVP—CIPHER—CTX */;
typedef struct evp_cipher_ctx_st EVP—CIPHER—CTX;
其中的 cipher由 i层应 在引擎通 bind_engine()接口报告的算法列表中选定， engine由上层应用创 建， 并在调用 bincLengineO时与算法列表建立关联， 其他密钥数据由具体运算过程决定。
如图 7所示， 当 d0_cipher()接口被上层 OpenSSL应用程序调用时， 硬件加密引擎执行如下操作： 步骤 301、 根据 do—cipher的上下文结构 EVP_CIPHER_CTX， 在密钥信息集合中， 査找出与第二算法 ID的密钥相对应的密钥信息， 并从中取出密钥句柄。
步骤 302、 在 PKCS#11接口动态库中， 査找出与第二算法 ID相同的加解密算法 ID。
步骤 303、 控制硬件加密设备根据査找得到的加解密算法对传入的数据进行分包加密或解密操作， 并 输出结果。
do_Cipher()函数调用结束后， OpenSSL结束对引擎的使用，并释放该引擎，通过 clean_up()接口来完成。 当 clean_up()接口被上层 OpenSSL应用程序调用时， clean_up()接口主要进行清除第二算法 对应的 密钥及密钥信息的工作， 清除方法是根据传入到引擎中的上下文结构， 从密钥信息集合中査找出对应的密 钥信息， 将所述密钥及密钥信息进行清除。
具体地， 当 clean_up()接口被调用时， 通过 PKCS#11接口的 C_DestroyObject函数来销毁硬件加密设 备中的密钥及密钥信ϊ; 另外， 硬件加密引擎在此之后还可以通过 PKCS#11接口中的函数 C—CloseSession 关闭硬件加密弓 I擎与硬件加密设备的连接；
需要说明的是， 在该过程中还可以通过 PKCS#11接口 C_Finalize结束硬件加密引擎对整个 PKCS#11 接口的调用。
实施例 3
在本实施例中，硬件加密引擎提供 bind_engine()、 init()、 do_cipher()和 clean_up()等四个接口。其中， 引擎绑定接口 bincLengineO用于绑定引擎；密钥初始化接口 init()用于获取硬件加密接口动态库中的加解 密算法并初始化密钥及密钥信息； 数据加解密接口 d0_cipher()用于进行分包加密或解密操作； 引擎释放 接口 clean_Up()用于释放引擎。
在本实施例中， 所述硬件加密引擎通过硬件加密接口 CSP (Cryptographic Service Provider密码服务 提供程序） 接口动态库与硬件加密设备进行连接， 以完成加解密操作。
通过 CSP接口的 CryptAcquireContext与硬件加密设备建立连接；
通过 CSP接口的 CryptGetProvParam取得硬件加密设备的算法列表；
通过 CSP接口的 CryptlmportKey导入密钥；
通过 CSP接口的 CryptGenerateKey生成密钥；
通过 CSP接口的 CryptEncrypt进行加密；
通过 CSP接口的 CryptDecrypt进行解密；
通过 CSP接口的 CryptDestroyKey和 CryptReleaseContext清理环境；
通过 CSP接口的 CryptAcquireContext ( DELETE_KEYSET ) 销毁硬件加密设备中的密钥及密钥信息； 具体流程如下：
图 8是引擎绑定流程图。 图 8显示了 CSP接口动态库与 OpenSSL接口的绑定过程， 当 bind_engine() 接口被上层 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_id和 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_DEVICEREMOVECOMPLETE消息为拔 除事件。
需要说明的是， 由于 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,"BSD rtl8651b engine")。
步骤 405、 引擎获取硬件加密设备的算法列表。
具体地， 引擎通过 CSP接口的 CryptGetProvParam取得硬件加密设备的算法列表；
步骤 406、 引擎设置 EVP_CIPHER数据结构， 以供上层 OpenSSL应用程序调用。
具体地说明在步骤 110中已有叙述， 在此就不再赘述。
步骤 407、 判断 bincLengineO接口传入的加解密算法的指针 cipher是否为空， 如果为空， 则执行步骤 408， 否则， 执行步骤 409。
具体地， 根据 bincLengineO接口传入硬件加密设备的加解密算法， 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->dpher->nid变量来获取第一算法 ID。
其中， 上下文结构中的 ctx->Cipher->nid变量是由引擎中获取的 cipher对象提供的。
步骤 502、 根据硬件加密设备中加解密算法与 OpenSSL接口中的加解密算法的映射关系， 从 CSP接 口动态库中， 获取与第一算法 ID对应的硬件加密设备中的加解密算法 ID， 记为第二算法 ID， 并将第二算 法 ID存储在引擎中，这样引擎就将硬件加密设备当前所要使用的加解密算法设置为了第二算法 ID所对应 的加解密算法了。
具体的，将所述第二算法 ID存储到 init()函数中的上下文结构中的 Cipher_data(CtX->Cipher_data)字段中。 其中，在引擎中，将硬件加密设备与 OpenSSL中算法参数一致的加解密算法建立一一对应的映射关系。 算法参数一致具体是指密钥长度、 分组长度、 初始向量长度等参数要一致。
为了便于理解，在此举例详述根据硬件加密设备的加解密算法与 OpenSSL接口中的加解密算法的映射 关系，获得第二算法 ID的过程。若 OpenSSL接口中的算法为 IDEA( International Data Encryption Algorithm), CSP接口动态库中的算法是 SSF33, 在引擎对象中已经定义好了这两个算法的映射关系， IDEA算法与三 重数据加密标准 SSF33 算法的算法参数是一致的， 通过高级加密标准 AES 算法的上下文结构的 ctX->Cipher->nid变量中获取 IDEA算法 ID, 如果得到了 AES算法 ID, 根据映射关系査找 SSF33算法， 得 到 SSF33算法的算法 ID, 即为第二算法 ID。
步骤 503、在密钥信息集合中，査找第二算法 ID，并判断是否能够査到，如果能査到，则执行步骤 504; 否则， 执行步骤 505。
判断是否能在密钥信息集合中査找到第二算法 ID 的密钥信息具体为： 通过调用 OpenSSL接口中的 EVP_Encryptlnit/EVP_Decryptlnit()函数， 并根据调用的 EVP_Encryptlnit/EVP_Decryptlnit()函数时传入的密 钥值在密钥信息集合中査找密钥信息。 其中， 根据传入的密钥值来找到密钥信息具体为： 在密钥信息集合 中进行 找， 而査找结果是密钥句柄。
在采用 CBC (分组链接）加密模式时， 所述 EVP_Encryptlnit/EVP_Decryptlnit()函数的参数列表中包含 初始向量值。
另外， 需要说明的是， 加解密算法对像 EVP_CIPHER结构中定义了密钥长度、 密钥分组长度、 初始 向量长度、密钥值、密钥句柄等信息， 这些信息称之为密钥信息， 不同密钥的密钥信息构成密钥信息集合。
步骤 504、 将第二算法 ID的密钥句柄存储到 init()函数的上下文结构中。
具体地， 将密钥句柄存储到引擎的加密对象的上下文结构中。
步骤 505、 创建第二算法 ID的密钥， 并将所述密钥的密钥信息添加到密钥信息集合中。
创建密钥具体是通过调用 CSP接口的 CryptlmportKeyO函数来创建密钥。 其中， 创建密钥模板包括密 钥值以及密钥句柄等密钥信息。
如图 10所示， 当 do_cipher()接口被上层 OpenSSL应用程序调用时， 硬件加密引擎执行如下操作： 步骤 601、在密钥信息集合中根据 do_Cipher()接口的上下文结构， 査找出与第二算法 ID对应的密钥信 息， 并从中取出密钥句柄。
步骤 602、 在 CSP接口动态库中， 査找出与第二算法 ID相同的加解密算法 ID。
步骤 603、 控制硬件加密设备根据査找得到的加解密算法对传入的数据进行分包加密或解密操作。 其中， 分包加解密操作包括电子密码本加解密模式 EBC和分组链接加解密模 CBC式。
加解密操作完成后， Cleap_Up接口将被调用， 以清理环境。
当 Clean_up()接口被上层 OpenSSL应用程序调用时， 主要进行清除第二算法 ID的密钥及密钥信息的 工作， 清除方法是根据传入到引擎中的上下文结构， 从密钥信息集合中査找出对应的密钥信息， 将所述密 钥及密钥信息清除。
具体地， 当 clean_up()函数被调用时， 通过 PKCS#11接口的 C_DestroyObject函数来销毁硬件加密设 备中的密钥及密钥信ϊ; 另外， 硬件加密引擎在此之后还可以通过 PKCS#11接口中的函数 C—CloseSession 关闭硬件加密弓 I擎与硬件加密设备的连接；
需要说明的是， 在该过程中还可以通过 PKCS#11接口 C_Finalize结束硬件加密引擎对整个 PKCS#11 接口的调用。
本发明提供的硬件加密引擎， 将一些硬件加解密算法添加扩展到软件算法库中。 同时， 该硬件加密引 擎在实现上还可以支持多线程和 SSL通讯。为使引擎能够支持多线程， 使用一个互斥锁和自定义的数据结 构来实现并发控制。 如果加解密算法还要支持 SSL通讯协议（SSL协议定义用于加密和解密用的密钥是分 开的）， 在创建密钥时， 还要对密钥用途做标识。
另外， 需要说明的是， 以上实施例中所指的加解密算法均指对称加解密算法。
实施例 4
硬件引擎作为现有软件算法库 （如 OpenSSL动态库） 的扩展， 为用户提供了一个用于增加硬件算 法的接口。 硬件引擎所提供的数据结构中不仅包括数据， 还包括各种方法（这里所说的方法是指算法回 调函数集合）， 所述方法是可替换的， 通常情况下， 硬件引擎提供一个默认方法， 并通过替换该默认方 法来达到增加算法的目的。
在本实施例进行说明之前， 需要对硬件引擎的数据结构有所了解， 该数据结构的描述如下： typedef struct engine_st
{
const char *id;
const char ^name;
const RSA_METHOD *rsa_meth;
const DSA_METHOD *dsa_meth;
const DH_METHOD *dh_meth;
const ECDH_METHOD *ecdh_meth;
const ECDSA_METHOD *ecdsa_meth;
const RAND_METHOD *rand_meth;
const STORE—METHOD *store_meth;
int (*init)(void);
int (*finish)(void);
int (*destroy)(void);
EVP_PKEY *(*load_privkey)(const char *key_id， const char *passphrase);
EVP_PKEY *(*load_pubkeyXconst char *key_id， const char ^passphrase);
int ctrl_f(ENGINE *e， int cmd， long i， void *p， void (*f)(void)); const ENGINE_CMD_DEFN *cmd_defns;
ENGINE_SSL_CLIENT_CERT_PTR load_ssl_client_cert;
int flags;
I* reference count on the structure itself */
int struct_ref;
I* reference count on usability of the engine type. NB: This
* controls the loading and initialisation of any functionlity
* required by this engine, whereas the previous count is
* simply to cope with (de)allocation of this structure. Hence,
* running_ref <= struct_ref at all times. */
int funct—ref;
I* A place to store per-ENGINE data */
CRYPTO_EX_DATA ex_data;
I* Used to maintain the linked-list of engines. */
struct engine_st *prev;
struct engine_st *next;
} ENGINE;
具体地， 本发明所提供的硬件引擎正是通过实现上述数据结构中的 id、 name字段， RSA_METHOD 方法， init()、 finish()、 destroy(),ctri-f()、 load_privkey()、 load_pubkey()来实现将智能密钥设备中的对称算法 添加到现有的软件算法库中；
需要说明的是， 在具体实现时， 也可以通过替换上述数据结构中的方法 DSA_METH、 DH_METHOD、 ECDH_METHOD、 ECDSA_METHOD、 RAND_METHOD、 STORE_METHOD来实现将智能密钥设备中的 算法添加到 OpenSSL动态库中的目的， 但不在本发明的说明范围， 在此就不再详述了。
其中， 通过设置硬件引擎 id和 name来确定所要加载的硬件引擎， init()用于初始化 PKCS#11接口动 态库，来绑定特定的函数指针，该函数指针指向的函数是根据引擎数据结构中的函数指针具体实现的,例如： 智能密钥设备中的算法函数； finishO用于清除硬件引擎所占用的资源； destroyO用于清除应用资源； ctrl_f() 用于实现自定义命令功能； load_privkey()用于加载私钥； load_pubkey()用于加载公钥； load_ssl_client_cert 用于实现证书的加载； flags字段用于标识硬件引擎使用的算法是硬件引擎所提供的默认算法， 还是自定义 算法。
其中， 方法 RSA_METHOD的描述如下：
typedef struct rsa_meth_st
{
const char ^name;
int (*rsa_pub_enc)(int flen，unsigned char *from，unsigned char *to， RSA *rsa，int padding);
int ( *r s a_pub_dec) (int flen，unsigned char *from，unsigned char *to， RSA *rsa，int padding);
int (*rsa_priv_enc)(int flen，unsigned char *from，unsigned char *to， RSA *rsa，int padding);
int (*rsa_priv_dec)(int flen，unsigned char *from，unsigned char *to， RSA *rsa，int padding);
int (*rsa_mod_exp)(BIGNUM *rO，BIGNUM *I，RSA *rsa); /* Can be null */
int (*bn_mod_exp)(BIGNUM *r， BIGNUM *a， const BIGNUM *p， const BIGNUM *m， BN—CTX *ctx; BN_MONT_CTX *m_ctx); /* Can be null */
int (*init)(RSA *rsa); /* called at new */
int (*finish)(RSA *rsa); /* called at free */
int flags; /* RSA_METHOD_FLAG_* things
char *app_data; /* may be needed! */
/* New sign and verify functions: some libraries don't allow arbitrary data to be signed/verified: this allows them to be used. Note: for this to work the RS A_public_decrypt() and RSA_private_encrypt() should *NOT* be used RSA_sign()， RSA_verify() should be used instead. Note: for backwards compatibility this functionality is only enabled if the RSA_FLAG_SIGN_VER option is set in 'flags'. */
int (*rsa_sign)(int type, unsigned char *m， unsigned int m_len， unsigned char *sigret， unsigned int *siglen， RSA *rsa);
int (*rsa_verify)(int dtype, unsigned char *m， unsigned int m_len， unsigned char *sigbuf， unsigned int siglen, RSA *rsa);
} RS A—METHOD;
由上 3^描述可知， RSA_METHOD数据结构定义了初始化 /结束接口 init/ finish、 RSA公钥加 /解密接口 rsa_pub_enc/rsa_pub_dec、 RSA私钥力口 /解密接口 rsa_priv_enc/ rsa_priv_dec、 RSA签名 /验签接口 rsa_mod_exp/ bn_mod_exp， 实现 RSA_METHOD实质上就是实现上述八个函数接口；
需要说明的是， 上 ^八个函数接口是可以有选择地实现的， 即根据硬件引擎的功能有选择地实现； 例 如， 硬件引擎用做非对称加 /解密操作的， 则需要实现 RSA公钥加 /解密接口和 RSA私钥加 /解密接口， 并 且 RSA_METHOD结构中的 flags标识置为 RSA_FLAG_EXT_PKEY， 表明是用于数据交换； 再例如， 引 擎用做签名 /验签操作， 则要实现 RSA签名 /验签接口， 并且 RSA_METHOD 结构中的 flags 标识置为 RSA_FLAG_SIGN_VER， 表明是用于签名操作的， 等等。
其中， padding为填充方式 /去填充方式， 是由用户设置的； flags字段用于标识该 RSA_METHOD数据 结构用于哪一种操作，例如，如果 flags设置为 RSA_FLAG_SIGN_VER，则表明该数据结构用于签名 /验签， 那么， 该数据结构中的 rsa_sign/ rsa_verify将被使用， 而 RSA_public_decrypt/ RSA_private_encrypt则不会 被使用， 其中， flags的数 ¾可以是 RSA_FLAG_EXT_PKEY (用于 |ί据交换） 。
还需要说明的是， 本发明实施例中初始化 /结束接口 init/ finish设置为空值， 没有使用， 不做为本发明 说明的范围， 对其余的六个函数接口都进行了说明。
实施例 5
基于上述说明， 硬件引擎通过实现引擎绑定接口 bincLengineO及注册在硬件引擎数据结构中的引擎初 始化接口 init()、 引擎完成接口 finish()、 引擎销毁接口 deStroy()、 自定义功能接口 ctrl_f()、 私钥加载接口 load_privkey()、 公钥加载接口 load_pubkey()、 证书加载接口 load_ssl_client_cert()、 第一数据结构 RSA_METHOD 中的 RS A 公钥加 /解密接口 rsa_pub_enc()/rsa_pub_dec()、 RSA 私钥加 /解密接口 rsa_priv_enc()/rsa_priv_dec() , RSA签名 /验签接口 rsa_mod_exp() n_mod_expO来达到用智能密钥设备中的 算 ^替 ^ OpenSSL动态库中的 RSA算法的目的， 接 来， 将对各个接口进行详细的描述。
在本实施例中， 硬件引擎通过 PKCS#11 (密码令牌）接口动态库与连接到主机的智能密钥设备进行 通信， 实现用智能密钥设备中的 RSA算法来替换现有软件算法库中的 RSA算法， 完成利用密钥设备中 的公私密钥对进行数据加解密、 身份认证等操作。 所述 PKCS#11接口动态库由智能密钥设备的开发者 提供， PKCS#11接口动态库的内部细节不在本发明描述范围之内。
参见图 11， 当引擎绑定接口 bincLengineO被上层应用程序调用时， 硬件引擎执行如下操作： 步骤 1101 : 创建引擎对象 e;
具体地， 通过 ENGINE_new()函数来实现；
其中， ENGINE_new()函数是 OpenSSL动态库中已定义的， 且通过该函数所创建的引擎对象 e为空。 步骤 1102: 为 创建的引擎对象 e设置 id及 name;
具体地， 通过函数 ENGINE_set_id()、 ENGINE_set_name()来实现；
例如： ENGINE_set_id(e, engine_rsaref_id)； ENGINE_set_name(e, engine_rsaref_name) , 则上层应用程 序调用该函数时， 根据设置的引擎 id及引 名称加载相 /^的½件引擎。
步骤 1103 : 设置 crtl_f()， 控制调用自定义命令功能；
具体地， 通过 ENGINE_set_ctrl_f_function()函数来设置 ctrl_f();
其中， ctri_f()描述如下：
int(*ctrl_f)(ENGINE *e, /*引擎 */
int cmd, /*命令号 */
long i, /*输入参数的长度 */
void *p, /*输入参数的内容 */
void (*f)());
具体地， 自定义命令示例如下所述：
(1) . pkcslllib 设置 PKCS#11库名称；
(2) . setxcert 设置需要的证书；
(3) . usetokeni 选择一个槽 Slot;
(4) . usetokenn 通过智能密钥设备序列号选择一个设备；
(5) . setpin 设置选择的 Slot的 PIN码；
(6) . login 登录；
(7) . logout 登出；
(8) . getslots 获取总的硬件加密设备数量。
本发明实施例中 ctri_f()控制实现的自定义命令包括上述示例所说的所有命令；
具体地， 通过设置 ctri_f()中的命令号字段来控制实现上述示例所述的自定义命令。
步骤 1104: 设置 load_privkey();
具体地， 通过 ENGINE_set_load_privkey_ftmction()函数设置 load_privkey()。
需要说明是， 设置的 loacLprivkeyO是空 。
步骤 1105: 设置 loadSSl_f()， 实现证书和公私密钥对的加载； 具体地， 通过 ENGINE_set_load_ssl_client_cert_function()函数来设置回调函数， 在此函数中实现证书 和公私密钥对的加载；上层应用程序贝 Ϊ是 ¾过调 l0ad_SSl_Client_Cert()来实现证书和公私密钥对的加载的； 其中， loadssl_f()的描述如下：
int (*loadssl_f)(ENGINE *e; I* 引擎 */
SSL *ssl, I* SSL */
STACK_OF(X509_NAME) /* CA颁发者名称 */
X509 **pcert, I* 用户证书 */
EVP—PKEY **pkey, I* 公私密钥对 */
STACK_OF(X509) **pother,
UI_METHOD *ui_method,
void *callback_data);
具体地， 通过设置回调函数 ENGINE_set_load_ssl_client_cert_function()来进行客户端证书和公私密钥 对的加载操作；
需要说明的是， 如果智能密钥设备中存储着多张证书， 相应的， 也就出现多对密钥对， 可以在加载私 钥函数中， 对智能密钥设备中所有的证书和密钥对进行遍历， 按统一的 CKA_ID (P11接口中对象的一个 属性） 进行分组， 使得证书与密钥对能够对应。 然后， 通过 crtl_f()中的设置证书命令实现证书的选择； 并 将选择的证书及与证书相对应的密钥保存到 **pcert字段。
步骤 1106: 设置 load_pubkey();
具体地， 通过 ENGINE_set_load_pubkey_function()函数设置 load_pubkey()。
需要说明是， 设置的 load_pubkeyO是空 。
步骤 1107: 设置 RSA_METHOD数据结构；
具体地， 可以由 ENGINE_set_RSA()函数来设置 RSA_METHOD数据结构；
具体地， 设置 RSA_METHOD数据结构是指， 设置 RSA_METHOD数据结构中的 RSA公钥加 /解密接 口 rsa_pub_enc()/rsa_pub_dec()、 RSA私钥加 /解密接口 rsa_priv_enc()/rsa_priv_dec()、 RSA签名 /验签接口 rsa_mod_exp()/bn_mod_exp() , SSL客户端认证接口的指针， 当 层应用程序调用到上述指针时， 程序转入 RSA公钥加 /解密接口 rsa_pub_enc()/rsa_pub_dec()、RSA私钥加 /解密接口 rsa_priv_enc()/rsa_priv_dec()、RSA 签名 /验签接口 rsa_mod_exp()/bn_mod_exp()、 SSL客户端认证接口的处理流程。
需要说明的是， 在¾¾聚 103 设置 crtl_f()是指设置 crtl_f()的函数指针， 当上层应用程序调用到该设置 的函数指针时， 程序转入 crtl_f()的处理流程， 具体如下：
参见图 12， 当 crtl_f()被上层应用程序调用时， 硬件引擎执行如下操作：
1103-1、 设置证书；
具体地， 设置 enumCert命令， 当该命令被调用时， 返回智能密钥匙设备中的证书列表， 通过选择证 书 setCert命令在返回的证书列表中选择证书和密钥， 并将选择的证书和密钥保存到内存中；
具体地， e皿 mCert命令是通过调用 PKCS#11接口动态库中的 C_FindObjectInit()， C_FindObjects()和 C_FindObjectsFinal()实现的。
1103-2、 进行登录操作；
具体地， 通过调用 PKCS#11接口动态库中的 C_Login(),C_GetSessionInfo()来实现；
其中， C_Login()实现登录操作， C_GetSeSSi0nInf0()实现智能密钥设备登录状态的更新；
1103-3、 进行登出操作；
具体地， 通过调用 PKCS#11接口动态库中的 C_Logout,C_GetSessionInfo来实现；
其中， C_Logout()实现登出操作， C_GetSeSSi0nInf0()实现智能密钥设备登出状态的更新；
需要说明的是， 在 crtl_f()被调用时， 还可以实现如下操作： 设置 PKCS#11接口动态库的名称、 选择 一个槽 slot; 通过智能密钥设备选择一个设备号； 设置选择的 slot的 PIN码； 获取总的硬件加密设备数量； 等等； 并将设置的 PKCS#11接口动态库的名称、 选择的槽 slot、 选择的设备号、 设置的槽 slot的 PIN码、 获取的总的硬件加密设备的数量存储在缓存中， 在后续使用时， 就可以直接从缓存中取出了。
参见图 13， 当引擎初始化接口 init()被上层应用程序调用时， 硬件引擎执行如下操作：
步骤 1301、 加载 PKCS#11接口动态库；
优选地， 本步骤通过调用计算机的系统函数 loadlibraryO来完成。
进一步地， 加载与 crtl_f()中控制实现的 PKCS#11接口动态库的名称相对应的 PKCS#11接口动态库。 步骤 1302、 获取 PKCS#11接口动态库的函数列表；
优选地， 本步骤通过调用 PKCS#11接口中的 C_GetFunctionList()函数来完成；
进一步地， 本步骤还可以先通过调用计算机系统函数 GetProcAddressO尝试获取 PKCS#11 接口中的 C_GetFunctionList()函数在 PKCS#11 接口的入口点， 调用 C_GetFunctionList()函数成功后， 就可通过由 C—GetFunctionListO函数获得的 PKCS#11函数列表获取其他 PKCS#11接口的入口点；如果尝试失败，则报 错返回。
具体地， PKCS#11接口动态库的函数列表可以是 CK_FUNCTION_LIST_PTR。
需要说明的是， PKCS#11接口动态库的函数列表包含 PKCS#11接口动态库中函数指针的指针。 步骤 1303、 调用 PKCS#11接口动态库中定义的函数 C_Initialize()来初始化 PKCS#11接口动态库； 这里需要说明的是，根据 PKCS#11接口的规范标准，在¾行其他操作之前必须要先调用 C_InitialiZe()。 进一步地， 在此过程中， 还可执行以下操作：
步骤 1303'、创建并启动监控线程，利用 PKCS#11接口动态库中定义的函数 C_WaitForSlotEvent()来监 控智能密钥设备的插拔事件， 以便在后续的处理过程中引擎可以根据智能密钥设 ^的插拔状态及时地做出 相应的反应。
步骤 1304: 获取当前连接到主机的智能密钥设备句柄；
具体地，通过调用 PKCS#11接口动态库中定义的函数 C_GetSlotList()来获取当前连接到主机的智能密 钥设备的设备列表。
具体地， 如果存在多个智能密钥设备连接到主机， 优选的， 选择设备列表中与 crtl_f()中控制实现的智 能密钥设备序列号相对应的智能密钥设备； 相应的， 选择设备列表中的第一个智能密钥设备。
需要说明的是， 当有多个智能密钥设备连接到主机时， 还可以选择设备列表中与 crtl_f()中控制实现的 槽 slot相连接的智能密钥设备。
步骤 1305: 与智能密钥设备建立连接；
具体地， 通过调用 PKCS#11接口动态库中定义的函数 C—OpenSessionO来与智能密钥设备建立连接。 接下来， 硬件引擎与智能密钥设备之间的信息交互都是通过 PKCS#11接口实现的。
参见图 14， 当公钥加密接口 rSa_pub_enc()被上层应用程序调用时， 硬件引擎执行如下操作： 图中 1402、 1403都是加解密
其中， 公钥加密接口 rSa_pub_enc()的参数描述如下：
int(*rsa_pub_enc)(
int filen, /*加密前数据的长度 */
const unsigned char *from, /*力口密前的数据 */
unsigned char *to, /*加密后的数据 */
RSA *rsa, /*RSA密钥对 */
int padding) ； /*RSA填充模式 */
具体地， RSA填充模式包括RSA PKCS1、 RSAX93 RSA SSLV23等填充模式或无填充模式； 步骤 1401： 将传入的 RSA密钥对转换为 char数组形式；
具体地， 当公钥加密接口 rSa_pub_enc()被上层应用程序调用时， 伴随该接口的被调用， RSA密钥对将 会通过 rsa字段传入；
具体地， 通过调用 PKCS#11接口中的( _0^1601^(^来完成 RSA密钥对的导入。
步骤 1402: 对传入的加密前的数据进行填充；
具体地， 当公钥加密接口 rSa_pub_enc()被上层应用程序调用时， 伴随该接口的被调用， 加密前数据将 会通过 from字段传入； 而 RS A填充模式由 padding字段传入；
具体地， 根 传入的填充方式对加解密数据进行填充；
具体地，可采用 RSA_padding_add_none、 RSA_padding_PKCSl_type_l、 RSA_padding_PKCSl_type_2、 RSA_padding_SSLv23 等填充方 函 数对 入 的加解密前 的数 进行填充 ； 其 中 RS A_padding_PKCS l_type_l主要用于私钥加密的填充， RSA_padding_PKCS l_type_2主要用于公钥加密的 填充。
步骤 1403: 控制智能密钥设备对填充后的数据进行加密操作， 并输出加密结果；
具体地， 通过调用 PKCS#11接口动态库中的函数 C_EncryptInit, C_Encrypt来加密填充后的数据， 并 通过公钥加密接口 rSa_pub_deC()的 to字段输出加密结果。
这里需要说明是， 当公钥解密接口 rSa_pub_deC()被上层应用程序调用时， 通过调用 PKCS#11接口动 态库中的 C—Decryptlnit, C.Decrypt来完成对数据的解密操作， 其他操作与上述执行的操作类似， 此处就不 再赘述。
参见图 15， 当私钥加密接口 rSa_piv_enC()被上层应用程序调用时， 硬件引擎执行如下操作： 其中， 私钥加密接口 rSa_piv_enC()的参数描述如下：
int(*rsa_piv_enc)(
int filen, /*加密前数据的长度 */
const unsigned char *from, /*加密前数据 */ unsigned char *to, /*加密后的数据 */
RSA *rsa, /*RSA密钥对 */
int padding) ； /*RSA填充模式 */
具体地， RSA填充模式包括RSA PKCS1、 RSA X93 RSA SSLV23等填充模式或无填充模式； 步骤 1501： 将 RSA私钥转换为 char数组形式；
具体地， 当私钥加密接口 rSa_piv_enC()被上层应用程序调用时， 伴随该接口的被调用， RSA密钥对将 会通过 rsa字段传入；
步骤 1502: 对传入的加解密前的数据进行填充；
具体地， 当公钥加密接口 rsa_pUb_enc()被上层应用程序调用时， 伴随该接口的被调用， 加密前数据将 会通过 from字段传入； 而 RSA填充模式由 padding字段传入；
具体地， 根 传入的填充方式对加解密数据进行填充；
具体地，可采用 RSA_padding_add_none、 RSA_padding_PKCSl_type_l、 RSA_padding_PKCSl_type_2、 RSA_padding_SSLv23 等填充方 函 数对 入 的加解密前 的数 进行填充 ； 其 中 RS A_padding_PKCS l_type_l主要用于私钥加密的填充， RSA_padding_PKCS l_type_2主要用于公钥加密的 填充。
步骤 1503 : 进行登录检査， 如果已进行登录， 则执行步骤 1505， 否则， 执行步骤 1504;
步骤 1504: 登录， 对 PIN码进行验证， 验证通过后执行步骤 1505 ;
具体地， 通过调用 PKCS#11接口动态库中的函数 C_Login来完成登录操作；
需要说明的是， 登录的操作还可以在智能密钥设备与主机建立连接之时进行；
具体地， 本步骤中还可以对 PIN码最大输入次数进行限制， 如果累计输入 PIN码错误的次数超过约定 的最大输入次数， 则操作结束；
步骤 1505 : 控制智能密钥设备对填充后的数据进行加密操作， 并输出加密结果； 图中是加解密 具体地， 通过调用 PKCS#11接口动态库中的 C_SignRecoverInit， C.SignRecover来加密填充后数据， 并通过公钥加密接口 rSa_pub_enC()的 to字段将加密 ^数据输出。
这里需要说明是， 当私钥解密接口 rSa_piV_deC()被上层应用程序调用时， 通过调用 PKCS#11接口动态 库中的 C_VerifyReCOVerInit， VerifyRecover来解密填充后的数据， 其他操作与上述执行的操作类似， 此处就 不再赘述。
参见图 16， 当签名接口 rSa_Sign()被上层应用程序调用时， 硬件引擎执行如下操作：
其中， 接口 rsa_sign()的描述如下：
int (*rsa_sign) (
int type, /* 摘要模式 */
const unsigned char *m, I* 摘要值 */
unsigned int mjength, /* 摘要值的长度 */
unsigned char *sig, /*此参数返回签名结果 */
unsigned int *siglen, I* 签名值的长度 */
const RSA *rsa); /* RSA密钥对 */
步骤 1501 : 根据传入的摘要模式， 创建摘要结构 X509_SIG;
需要说明的是， 在接口 rSa_Sign()被上层应用程序调用时， 伴随该接口的被调用， 摘要模式通过该接口 的 type字段被传入；
其中， 摘要结构 X509_SIG是用来存放摘要或者签名值的， 定义在 crypto/x509/x509.h中， 如下：
Typedef struct X509_sig_st
{
X509—ALGOR *algor;
ASNl—OCTET—STRING *digest;
}X509_SIG;
具体地—， algor为摘要算法， digest用于存放摘要或者签名值。 对数据进行签名时， 要先对数据进行摘 要计算，计算结果要通过 X509_SIG结构进行 DER (Distinguished Encoding Rules,可辨别编码规则）编码， 然后才能用私钥进行计算， 此日 digest中存放的就是摘要值。
步骤 1502: 控制智能密钥设备对传入的摘要值进行签名；
需要说明的是， 在接口 rSa_Sign0被上层应用程序调用时， 伴随该接口的被调用， 摘要值通过该接口的 m字段被传入；
具体地， 智能密钥设备根据加载的算法密钥对传入的摘要值进行签名计算；
具体地， 通过函数 load_ssl_client_cert()实现算法密钥的加载。 需要说明的是， 如果指定的有智能密钥设备内部的算法密钥， 则使用指定 ID的密钥做签名运算。 具体地， 通过调用 PKCS#11接口的 C_SignRecoverInit()和 C_SignRecover()完成签名。
需要说明的是， 该传入智能密钥设备^]摘要值包括进行过填 后的摘要值， 硬件引擎对 X509_SIG结 构中经过 DER编码后的摘要值进行填充， 例如， 1024位的 RSA密钥必须填满 128字节， 而具体的填充方 式是由用户指定的。
参见图 17， 验签接口 rSa_Verify()被上层应用程序调用时， 硬件引擎执行如下操作：
其中， 接口 rsa_verify()的描述如下：
int (*rsa_ verify) (
int type, /* 摘要模式 */
const unsigned char *m, I* 摘要值 */
unsigned int mjength, /* 摘要值的长度 */
unsigned char *sig, /*此参数为签名值 */
unsigned int *siglen, I* 签名值的长度 */
const RSA *rsa); /* RSA密钥对 */
在对具体的操作进行说明之前， 需要知道的是： 接口 rSa_Verify()被上层应用程序调用时， 伴随该接口 的被调用而传入的参数包括： 摘要模式、摘要值、摘要值的长度、签名值、签名值的长度、 RSA密钥对等。
步骤 1701 : 对传入的签名值进行公钥解密， 得到摘要值；
具体地， 通过调用 PKCS#11接口动态库中的( _060^«1^,( _060^1解密传入的签名值；
步骤 1702 : 检査所获得的摘要值的摘要模式与传入的 "摘要模式"是否一致， 如果一致， 则执行步骤
1703， 如果不一致， 操作结束；
步骤 1703 : 将加密得到的摘要值与传入的"摘要值 "进行对比， 一致， 则验签成功， 否则， 验签失败。 参见图 18， 当加载客户端证书函数接口 ENGINE_set_load_ssl_client_cert_function()被调用时， 硬件引 擎执行如下操作：
具体地，一通过 loadssLfO函数来进行 SSL客户端证书的加载和公私密钥对的操作；
代码表示如下：
int (*loadssl_f)(ENGINE *e, /* 引擎 *l
SSL *ssl, I* SSL */
STACK_OF(X509_NAME) *ca_dn, /* CA颁发者名称 */
X509 **pcert, /* 用户证书 */
EVP_PKEY **pkey, /* 公私密钥对 */
STACK_OF(X509) **pother,
UI_METH0D *ui_method,
void *callback_data);
具体地， 通过设置回调函数 ENGINE_set_load_ssl_client_cert_function()来进行客户端证书和公私密钥 对的操作；
步骤 1801： 从智能密钥设备中査找出证书对象；
步骤 1802 : 检査査找出的证书的用途是否是 SSL客户端， 如果是， 执行步骤 1803， 否则， 操作结束； 这里需要说明数据结构 X509_PURPOSE， 该结构用于检査证书用途， 定义在 x509v3.h中， 如下： typedef struct x509_purpose_st
{
int purpose;
int trust;
int flags;
int(*check_purpose)(conststruct x509_purpose_st*，const X509*，int);
char ^name;
char ^sname;
void *usr_data;
}X509_PURPOSE;
Purpose为证书用途 ID，check_purpose为检查证书用途函数；
具体地， 检查证书用途时， 找到对应的 X509_PURPOSE，调用其 check_purpose函数来判断证书用途是 否合法， 并通过函数 X509_check_purpose (X509 *x，int id，int ca) 来检查证书用途， 其中， x为待检查证书 用途 NID， ca表明 X是否是 ca证书。
步骤 1803根据查找得到的用于 SSL客户端的证书， 在智能密钥设备中查找到与之匹配的公私密钥对 对象， 如果不能找到与之匹配的证书， 就报错； 步骤 1804: 进行 SSL客户端认证；
需要说明的是， 在对方要求验证客户端证书时， 硬件引擎才会进行 SSL客户端认证的操作。
上述操作完成后， 接口 finishO将被上层应用程序调用， 结束对智能密钥设备的使用， 接口 deStroy_f() 被上层应用程序调用， 释放占用的资源；
另外， 在此之后还可以通过 PKCS#11接口中的函数 C—CloseSession关闭硬件引擎与智能密钥设备的 连接；
类似地， 硬件引擎也可以通过 CSP接口与智能密钥设备进行通信。 如：
通过 CSP接口 CryptAcquireContext与智能密钥设备建立连接；
通过 CSP接口 CryptGetProvParam取得智能密钥设备的算法列表；
通过 CSP接口 CryptCreateHash (HCRYPTHASH hHash)获取签名数据的 hash值；
通过 CSP接口 CryptSignHash进行签名；
通过 CSP接口 CryptVerifySignature进行验签；
通过 CSP接口 CryptEncrypt进行数据加密；
通过 CSP接口 CryptDecrypt进行数据解密；
此外， 硬件引擎通过 CSP接口 HCRYPTKEY hKey来加载密钥；
硬件引擎通过 CSP接口与智能密钥设备建立连接， 在自定义命令的实现上与 PKCS#11接口有少许的 区别， 命令如下：
(1) . cspname 设置 CSP名称；
(2) . setxcert 设置需要的证书；
(3) . setflags 设置标志；
(4) . enumcontainer 枚举容器 （枚举签名 /验签用容器或密钥交换类容器）；
(5) . usecontainer 选择容器；
(6) . setpin 设置选择的容器的 PIN码；
(7) . login
(8) . logout 登出；
(9) . getslots 获取总的容器数量。
以上命令为自定义命令，仅供示例参考。各命令功能需要用函数实现， 由控制回调函数负责调用控制。 需要说明的是 "setflags"设置标志命令。 此命令设置的标志是 CryptAcquireContextO函数中的标志， 该 标志可以是以下几个值：
1 )、 值 说明
2)、 CRYPT_VERIFYCONTEXT设置该标志， 应用不能访问私钥或公私密钥对， 例如， 应用只用于做 哈希或对称加解密运算。
3 )、 CRYPT_NEWKEYSET设置该标志， 创建一个新容器。
4)、 CRYPT_DELETEKEYSET 设置该标志， 删除指定的密钥容器。
5 )、 CRYPT_SILENT 设置该标志， CSP不显示任何用户的窗口。
需要说明的是， CSP是以容器为单位的， 因此， 需要提供一个枚举容器的命令， 以便用户选择容器， 其中， 硬件引擎通过该容器来加载密钥和证书。
还需要说明的是， 硬件引擎在通过 CSP接口加载私钥和证书时， 首先通过自定义命令所选择的容器， 从该容器中取出密钥句柄， 根据所述密钥句柄进行数据的加解密；
这样， 通过硬件加密引擎， 实现上述操作后， 就可以将一些硬件加解密算法， 尤其是一些未公开的， 只能用硬件实现的加解密算法添加扩展到软件算法库中了。
实施例 6
在进行具体说明之前， 需要对数据结构 EVP_MD有所了解， 该 EVP_MD结构用于存放信息摘要算法 的信息， 摘要引擎则正是通过实现该 EVP_MD结构来完成相应的摘要运算的， EVP_MD结构的描述如下： typedef struct env_md_st
{
int type;
int md_size;
int (*init)(EVP_MD_CTX *ctx);
int (*update)(EVP_MD_CTX *ctx，const void *data，unsigned long count);
int (*final)(EVP_MD_CTX *ctx，unsigned char *md);
int (*cleanup)(EVP_MD_CTX *ctx);
int block—size; int ctx_size;
} EVP—MD;
具体 i£ 对该数据结构中的参数进行解释， 如下：
type—信息摘要算法的 NID标识 (算法的 ID号)， 用于指明所采用的信息摘要算法；
md.size—信息摘要算法所生成的摘要值长度 （单位为字节）， 若该 EVP_MD 结构封装的是 SHA1 算法， 则该字段是 SHA1_DIGEST_LENGTH， 值为 20;
init—指向信息摘要算法的初始化函数， 若该 EVP_MD 结构封装的是 SM3 算法， 则指向的是
SM3_init;
update—指向计算摘要值的函数，若该 EVP_MD结构封装的是 MD5算法，则指向的是 MD5_update; final—指向在摘要值计算之后所要调用的函数， 该函数完成最后一个数据块的处理工作， 若该 EVP_MD结构封装的是 SHA256算法， 则指向的是 SHA256_final;
block.size—指明进行摘要运算时的数据块的分组长度（单位是字节），若该 EVP_MD结构封装的是 SHA1算法， 则该字段是 SHA1_CBL0CK， 值为 64;
ctx.size—指明实现信息摘要算法所需要分配的 CTX (上下文） 的空间大小， 若该 EVP_MD结构封 装的是 SHA算法， 则该字段指的是 sizeof(EVP_MD*)+sizeof(SHA_CTX)
cleanup——用于做一些清理工作， 清除 EVP_MD结构。
具体地，本发明提供的摘要引擎通过实现引擎绑定接口 bincLengineO及注册在 EVP_MD结构中的初始 化接口 init()、 第一摘要接口 updata()、 第二摘要接口 final()、 引擎释放接口 cleanupO来实现现有软件算法 库中信息摘要算法的扩展； 其中， bincLengineO用于绑定引擎， init()用于初始化摘要算法， updata()用于对 传入的信息摘要数据进行摘要运算， finalO用于结束摘要运算， 并输出摘要值， cleanupO用于清除信息摘要 算法的 EVP_MD结构。
本实施例中， 摘要引擎通过 PKCS#11 (public key cryptography standards密码令牌）接口动态库与连接 到主机上的智能密钥设备进行通信， 实现将智能密钥设备中的信息摘要算法添加到现有软件算法库中， 调 用智能密钥设备中的信息摘要算法来进行数据的摘要运算。 PKCS#11接口动态库由智能密钥设备的开发者 提供， 所述 PKCS#11接口动态库的内部细节不在本发明所描述的范围之内。
参见图 19， 当引擎绑定接口 bincLengineO被上层应用程序调用时， 摘要引擎执行如下操作： 步骤 1901、 引擎加载 PKCS#11接口动态库；
优选地， 本步骤通过调用计算机的系统函数 loadlibraryO来完成。
其中， PKCS#11接口动态库的文件名是预先约定的。
步骤 1902、 引擎获取 PKCS#11接口动态库中的函数列表；
优选地， 本步骤通过调用 PKCS#11接口中的 C_GetFunctionList()函数来完成。
进一步地， 本步骤还可以先通过调用计算机系统函数 GetProcAddressO尝试获取 PKCS#11 接口中的 C_GetFunctionList()函数在 PKCS#11接口的入口点， 调用 C_GetFunctionList()函数成功后， 就可获得其他 PKCS#11接口的入口点， 并且能够调用这些接口获得 PKCS#11接口动态库的函数列表； 如果尝试失败， 则报错返回。
具体地， PKCS#11接口动态库的函数列表可以是 CK_FUNCTION_LIST_PTR
需要说明的是， 获取的函数列表包含 PKCS#11 接口动态库中函 ^指针 指针， 这样， 引擎在以后的 操作中， 就可以通过调用获取的函数指针的指针来实现 PKCS#11 接口动态库中的函数的调用了， 例如， 引擎调用 PKCS#11接口动态库中的 C_InitialiZe()，就可以通过调用获取的 C_InitialiZe()指针的指针来实现， 步骤 1903、 引擎调用 C_Initialize()， 初始化 PKCS#11接口动态库；
需要说明的是， 根据 PKCS#11接口的规范标准， 在进行其他操作之前必须要首先调用该 C_InitialiZe() 接口。
进一步地， 在此过程中， 还可以包括如下操作：
引擎创建并启动一个监控线程，用于监控智能密钥设备的插拔事件，以便在后续处理中及时作出反应; 优选地， 监控智能密钥设备的插拔事件 （智能密钥设备的插入或拔除） 是通过调用 PKCS#11 接口动 态库中定义的函数 C_WaitForSlotEvent()来实现的。
需要说明的是： 监控智能密钥设备的插拔状态是为了能及时告知弓 I擎该智能密钥设备的当前状态， 如 果智能密钥设备被拔除， 则引擎及时关闭与智能密钥设备的会话， 如果， 智能密钥设备被插入， 则引擎及 时开启与智能密钥设备的会话， 以便提高工作效率， 同时， 避免了引擎在使用智能密钥设备时临时开启会 话， 而智能密钥设备是拔除状态， 从而造成错误情况的出现。
步骤 1904、 引擎获取当前连接到主机的智能密钥设备句柄；
具体地，引擎通过调用 PKCS#11接口动态库中定义的函数 C_GetSlotList()来获取智能密钥密钥设备列 表；
本实施例中，如果当前存在多个智能密钥设备连接到主机，则选择所述列表中的第一个智能密钥设备。 步骤 1905、 引擎与智能密钥设备建立通信；
优选地，引擎与智能密钥设备建立接连是通过调用 PKCS#11接口动态库中定义的函数 C_OpenSeSSi0n() 来实现的。
步骤 1906、 引擎创建一个引擎对象， 如 engine;
具体地， 引擎通过调用 ENGINE_new()来实现；
需要说明的是， 通过 ENGINE_neW()所创建的弓 I擎对象是空的。
步骤 1907、 引擎为所创建的引擎对象设置 id及名称；
具体地， 通过注册函数 ENGINE_set_id(e,engine_cipher_id), ENGINE_set_name(e,engine_cipher_name) 来实现引擎 id及名称的设置， 例如 ENGINE_set_id(engine,"rtl 865 lb"), ENGINE_set_name(engine,"BSD rtl8651b engine"；)。 当上层应用调用到 ENGINE_set_id (e,engine_cipher_id), ENGINE_set_name (e, engine_cipher_name) 时， 选定相应的引擎。
步―骤 108、 获取智能密钥设备的算法列表；
具体地， 通过调用 PKCS#11接口动态库中定义的 C_GetMechanismList来获取算法列表。
其中， 算法列表中包含信息摘要算法属性， 如分组 ^度、 摘要值长度等。
例如， 获取的算法列表是：
{CKM—SHA—1, { 0, 0, CKF_DIGEST} }。
步骤 1909、 Ϊ艮据所获取的算法列表填充 EVP_MD结构， 以便供上层应用调用；
具体的填充方法是，对所获取的算法列表中的任一摘要算法，根据上层应用的定义设置对应的算法 ID 号； 根据算法列表中的数值， 设置摘要值长度 mcLsize, 分组长度 block—size, 并指明实现摘要算法时所需 要分配的上下文的空间的大小， 及设置 init()、 updata(), final()、 cleanupO接口指针。
步骤 1910、 获取摘要算法的 EVP_MD结构；
具体地， 通过调用 ENGINE_set_digests来实现；
需要说明的是， 调用 ENGINE_Set_digeSts 设置当前引擎所支持的摘要算法， 并得到摘要算法的 EVP_MD结构， 从而得到 EVP_MD结构中封装的操作接口及摘要算法属性， 包括： init操作接口、 updata 操作接口、 final操作接口、 cleanup操作接口， 信息摘要算法的分组长度、 摘要值长度、 上下文的空间大 小等属性。
需要说明的是， 引擎默认支持的摘要算法包括 MD5和 shal
步骤 1911、 实现信息摘要算法与引擎的绑定；
具体地， 通过调用 ENGINE_register_digests来实现， ENGINE_register_digests将当期引擎所支持的信 息摘要算法添加到到上层应用中 算法歹 Ϊ表中， 与引擎建立关联，这样， 当 层应用使用信息摘要算法时， 就可以得到该信息摘要算法的 EVP_MD结构及相关的属性了。
需要说明的是， 当 init()接口、 updataO接口、 final()接口被上层应用调用时， 传入的参数一般包括： 上 下文及 EVP_MD结构中存放的信息摘要算法的信息， 包括信息摘要算法的分组长度， 摘要值长度、 信息 摘要算法 ID等。
参见图 20、 当 init()接口被上层应用程序调用时， 摘要引擎执行如下操作：
其中， init()的参数描述如下：
int (*init)(EVP_MD_CTX *ctx 〃上下文）；
具体地， 对 EVP_MD_CTX进行简单的说明， 如下：
typedef struct env_md_ctx_st
{
const EVP—MD *digest;
ENGINE *engine;
unsigned long flags;
void *md_data;
}EVP_MD_CTX；
具体地， EVP_MD_CTX结构中参数的介绍如下：
digest——指向 EVP_MD结构的指针；
engine—如果算法由弓 |擎提供， 该指针指向引擎；
md.data—信息摘要数据；
具体地， engine由上层应用创建， 并在调用 bind_engine()时与算法列表建立关联， 信息摘要数据由具 体运算过程决定。 步骤 2001、 设置当前使用的信息摘要算法；
具体地， 根据传入的信息摘要算法 ID査找相应的信息摘要算法， 如果査找不到， 则将当前使用的信 息摘要算法设置为默认的信息摘要算法， 如果能够找到， 则将当前使用的信息摘要算法设置为与传入的信 息摘要算法类型相对应的信息摘要算法；
具体地， 信息摘要算法 ID是伴随 EVP_MD_CTX而传入的， 当 EVP_MD_CTX结构中的 digest被执 行时， 就指向了 EVP_MD结构， 该结构中的信息摘要算法 ID就被传入 init()接口了。
步骤 2002、 为 EVP_MD_CTX (上下文） 分配内存空间；
具体地， 根据 bincLengineO接口被调用时， 设置的上下文空间大小进行内存的分配。
例如， 建立一个双向链表， 该双向链表用来存储信息摘要数据。
步骤 2003、 初始化上下文；
具体地， 为上下文赋初始值， 由具体的运算过程决定。
当 updataO接口被上层应用程序调用时， 传入的参数包括：
int (*update)(EVP_MD_CTX *ctx, //上下文
const void *data, //信息摘要数据
unsigned long count 〃迭代运算次数)
当 updataO接口被上层应用程序调用时， 摘要引擎缓存传入的信息摘要数据， 并控制智能密钥设备根 据当前设置的信息摘要算法对传入的信息摘要数据进行摘要运算， 并缓存运算结果；
需要说明的是， updataO接口被调用时， 在该接口中进行不止一次的摘要运算， 运算次数由具体的运算 过程所决定。
具体地， 可以通过调用 PKCS#11接口的 C_DigestUpdate函数来完成摘要运算。
当 finalO接口被上层应用程序调用时， 传入的参数包括：
int (*final)(EVP_MD_CTX *ctx,//上下文
unsigned char *md //摘要输出数据）
当 finalO接口被上层应用程序调用时， 摘要引擎控制智能密钥设备结束摘要运算， 并将运算结果输出， 具体地， 通过 md字段将结果输出；
具体地， 可以通过调用 PKCS#11接口的 C_DigeStFinal函数来完成摘要运算。
当 finalO接口调用结束后， cleaupO接口将被调用， 用于清理环境；
当 cleaupO接口被上层应用程序调用时， 通过 PKCS#11接口 C—CloseSession关闭与智能密钥设备的通 信；
清除摘要引擎所占用的应用资源， 结束对摘要弓 I擎的使用。
类似地， 摘要引擎中也可以通过加密服务程序 CSP (Cryptographic Service Provider) 接口与智能密钥 设备进行通信。 例如，
通过 CSP接口的 CryptAcquireContext与智能密钥设备建立连接；
通过 CSP接口的 CryptGetProvParam取得智能密钥设备的算法列表；
通过 CSP接口的 cryptGreateHash设置智能密钥设备当前所使用的算法；
通过 CSP接口的 CrypthashData对传入的数据进行摘要运算；
通过 CSP接口的 CryptGetHashParam输出摘要运算的结果；
通过 CSP接口的 CryptReleaseContext清理环境；
具体流程与通过 PKCS#11接口进行通信时的流程相似， 此处就不再赘述。
这样， 通过摘要引擎实现上述操作后， 就可以将一些硬件摘要算法， 尤其是一些未公开的， 只能用硬 件实现的摘要算法添加扩展到软件算法库中了。
以上所述， 仅为本发明较佳的具体实施方式， 但本发明的保护范围并不局限于此， 任何熟悉本技术 领域的技术人员在本发明揭露的技术范围内， 可轻易想到的变化或替换， 都应涵盖在本发明的保护范围 之内。 因此， 本发明的保护范围应该以权利要求的保护范围为准。

Claims

权利要求书
1、 一种加密引擎的实现方法， 上层应用程序通过调用所述引擎的引擎绑定接口、 初始化接口、 第一 接口、 引擎释放接口来实现， 其中， 所述第一接口包括数据加解密接口；
或者， 所述第一接口包括
第二数据结构中的加解密接口、 签名接口、 验签接口和 SSL客户端认证接口；
或者， 所述第一接口包括
第一摘要接口和第二摘要接口；
其特征是， 当所述第一接口包括数据加解密接口时， 所述初始化接口为密钥初始化接口， 并且所述方 法包括：
弓 I擎绑定接口被上层应用程序调用时， 所述引擎与智能密钥设备建立连接， 获取所述智能密钥设备的 算法列表， 并填充第一数据结构；
密钥初始化接口被上层应用程序调用时， 所述引擎根据传入的所述第一数据结构设置所述智能密钥设 备当前所要使用的加解密算法， 并检索相应的算法密钥， 如果检索不到， 则控制所述智能密钥设备创建所 述算法密钢；
数据加 Ϊ¥密接口被上层应用程序调用时， 所述引擎根据当前设置的加解密算法和算法密钥， 控制所述 智能密钥设备对传入的数据进行加 /解密操作， 并输出操作结果；
弓 I擎释放接口被上层应用程序调用时， 所述引擎结束与所述智能密钥设备的连接；
当所述第一接口包括第二数据结构中的加解密接口、 签名接口、 验签接口和 SSL客户端认证接口时， 所述初始化接口为引擎初始化接口， 并且所述方法包括：
弓 I擎初始化接口被上层应用程序调用时， 所述引擎与智能密钥设备建立连接；
引擎绑定接口被上层应用程序调用时， 绑定所述引擎， 并加载算法密钥和证书， 及设置所述第二数据 结构， 所述算法密钥包括公钥和私钥；
第二数据结构中的加解密接口被上层应用程序调用时， 所述引擎根据所述加载的算法密钥， 控制所述 智能密钥设备对传入的数据进行加 /解密操作， 并输出操作结果；
第二数据结构中的签名接口被上层应用程序调用时， 所述引擎根据所述加载的算法密钥， 控制所述智 能密钥设备对传入的摘要值进行签名操作， 并返回签名结果；
第二数据结构中的验签接口被上层应用程序调用时， 所述引擎根据所述加载的算法密钥， 控制所述智 能密钥设备对传入的签名值进行解密操作， 并验证所述解密得到的摘要值是否正确， 正确， 则验签成功， 否则， 验签失败；
第二数据结构中的 SSL客户端认证接口被上层应用程序调用时， 所述引擎根据所述加载的证书， 控制 所述智能密钥设备进行 SSL客户端认证， 并返回认证结果；
当弓 I擎释放接口被上层应用程序调用时， 所述引擎结束与所述智能密钥设备的连接；
当所述第一接口包括第一摘要接口和第二摘要接口时， 所述方法包括：
弓 I擎绑定接口被上层应用调用时， 所述引擎与智能密钥设备建立连接， 获取所述智能密钥设备的算法 列表， 并填充第三数据结构， 将所述第三数据结构登记到所述上层应用中；
初始化接口被上层应用调用时， 所述引擎根据传入的所述第三数据结构设置所述智能密钥设备当前所 使用的信息摘要算法， 并为传入的上下文分配存储空间， 及初始化所述上下文；
第一摘要接口被上层应用调用时， 所述引擎根据当前设置的信息摘要算法， 控制所述智能密钥设备对 传入的信息摘要数据进行摘要运算；
第二摘要接口被上层应用调用时， 所述引擎控制所述智能密钥设备结束摘要运算， 并输出运算结果； 弓 I擎释放接口被上层应用程序调用时， 所述引擎结束与所述智能密钥设备的连接。
2、 根据权利要求 1所述的方法， 其特征是，
当所述第一接口包括数据加解密接口时， 所述引擎绑定接口、 密钥初始化接口、 数据加解密接口、 引 擎释放接口具体为 bind_engine接口、 init接口、 do_cipher接口、 clean_up接口；
当所述第一接口包 ½第二数据结构中的加解密 Ϊ妾口、 签名接口、 ^签接口和 SSL客户端认证接口时， 所述引擎绑定接口、 引擎初始化接口、 弓 I擎释放接口具体为 bincLengine接口、 init接口、 destroy接口； 当所述第一接口包括第一摘要接口和第二摘要接口时， 所述引擎绑定接口、 初始化接口、 第一摘要接 口、 第二摘要接口、 引擎释放接口具体为： bind_engine接口、 init接口、 updata接口、 final接口、 cleanup 接口。
3、 根据权利要求 1 所述的方法， 其特征是， 所述硬件加密引擎与所述智能密钥设备通过硬件加密接 口建立连接和通信。
4、 根据权利要求 3所述的方法， 其特征是，
当所述第一接口包括数据加解密接口时， 所述填充第一数据结构具体为：
所述硬件加密引擎根据所述获取的算法列表和 init接口、 decipher接口和 clean—up接口的指针来填充 传入的第一数据结构；
当所述第一接口包括第一摘要接口和第二摘要接口时， 所述填充第三数据结构具体为： 根据初始化接 口、 数据摘要接口、 摘要输出接口、 引擎释放接口的指针及所述获取的算法列表来填充第三数据结构。
5、 根据权利要求 4所述的方法， 其特征是， 当所述第一接口包括数据加解密接口时， 所述根据所述 获取的算法列表和 init接口、 do—cipher接口和 clean—up接口的指针来填充传入的第一数据结构具体为： 根据上层应用程序中已有的定义， 在所述第一数据结构中为所述算法列表中的任一加解密算法设置对 应的算法 ID号；
根据所述算法列表中的数值， 在所述第一数据结构中为密钥长度、 密钥分组长度、 初始向量长度设置 对应的数值， 并为 init接口、 do_cipher接口、 clean_up接口指针设置对应的函数指针；
当所述第一接口包括第一摘要接口和第二摘要接口时， 所述根据初始化接口、 数据摘要接口、 摘要输 出接口、 引擎释放接口的指针及所述获取的算法列表来填充第三数据结构具体为：
根据上层应用中已有的定义， 在所述第三数据结构中为所述算法列表中的信息摘要算法设置对应的算 法 ID号；
根据所述算法列表中的数值， 在所述第三数据结构中为信息摘要算法的分组长度、 摘要值长度设置对 应的数值， 并为信息摘要算法所需要的上下文空间大小设置对应的数值， 为所述初始化接口、 第一摘要接 口、 第二摘要接口、 引擎释放接口设置对应的接口指针。
6、 根据权利要求 1 所述的方法， 其特征是， 当所述第一接口包括数据加解密接口时， 所述引擎根据 传入的所述第一数据结构设置所述智能密钥设备当前所要使用的加解密算法， 并检索相应的算法密钥， 如 果检索不到， 则控制所述智能密钥设备创建所述算法密钥具体为：
初始化接口被上层应用程序调用时， 所述填充后的第一数据结构传入所述硬件加密弓 I擎； 所述引擎根据所述传入的第一数据结构中的算法指针获取第一加解密算法 ID，所述第一加解密算法 ID 对应的加解密算法为上层应用程序中的算法；
所述智能密钥设备根据预设的映射关系， 获取与所述第一加解密算法 ID对应的第二加解密算法 ID， 所述第二加解密算法 ID对应的加解密算法为所述智能密钥设备中的算法；
所述引擎在所述智能密钥设备中的密钥信息集合中， 査找所述第二加解密算法 ID, 如果能査找到， 则 将所述第二加解密算法 ID对应的密钥句柄存储到所述第一数据结构的上下文中， 如果査找不到， 则控制 所述智能密钥设备创建所述第二加解密算法密钥， 并将所述第二加解密算法密钥的密钥信息添加到密钥信 息集合中 ·
" 所述 ½二加解密算法为所述智能密钥设备当前所要使用的加解密算法。
7、 根据权利要求 6所述的方法， 其特征是， 所述算法指针是由上层应用程序在所述第一数据结构的 算法列表中选定的。
8、 根据权利要求 1所述的方法， 其特征在于， 当所述第一接口包括第一摘要接口和第二摘要接口时， 所述引擎根据传入的所述第三数据结构设置所述智能密钥设备当前所使用的信息摘要算法具体为：
所述初始化接口被上层应用调用时， 将所述填充后的第三数据结构传入所述引擎；
所述引擎根据所述传入的第三数据结构中的信息摘要算法 ID査找对应的信息摘要算法， 如果査找不 到， 就将当前的信息摘要算法设置为默认的信息摘要算法， 如果能够査找到， 则将当前的信息摘要算法设 置为与所述传入的信息摘要算法 ID相对应的信息摘要算法。
9、 根据权利要求 6所述的方法， 其特征是， 所述预设的映射关系是由上层应用程序创建的， 将算法 参数一致的所述智能密钥设备中的加解密算法和上层应用程序中的加解密算法建立一一对应的映射关系； 其中， 算法参数具体是指密钥长度、 密钥分组长度、 初始向量长度。
10、 根据权利要求 1所述的方法， 其特征是， 所述引擎根据当前设置的加解密算法和算法密钥， 控制 所述智能密钥设备对传入的数据进行加 /解密操作， 并输出操作结果具体为：
数据加解密接口被上层应用程序调用时， 从传入的所述上下文中査找得到所述智能密钥设备当前所要 使用的加解密算法的密钥句柄；
所述引擎控制所述智能密钥设备根据所述査找得到的密钥句柄对传入的数据进行加 /密操作，并输出操 作结果。
11、 根据权利要求 1所述的方法， 其特征在于， 当所述第一接口包括第二数据结构中的加解密接口、 签名接口、 验签接口和 SSL客户端认证接口时， 所述绑定硬件引擎具体为：
创建引擎对象；
为所述创建的弓 I擎对象设置引擎 id及引擎名称； 当上层应用程序调用所述设置的引擎 id及引擎名称时， 则绑定与所述引擎 id及引擎名称相对应的引 擎。
12. 根据权利要求 1所述的方法， 其特征在于， 当所述第一接口包括第二数据结构中的加解密接口、 签名接口、验签接口和 SSL客户端认证接口时， 所述加载证书和算法密钥具体是通过 load_SSl_Client_Cert() 来完成的。
13. 根据权利要求 12所述的方法， 其特征在于， 当所述智能密钥设备中存在多张证书时， 所述方法还 包括： 通过 loadssl_f()接口及 crtl_f()接口来加载证书和私钥， 具体为：
当 loadssLfO接口被上层应用程序调用时， 对智能密钥设备中所有的证书和密钥对进行遍历， 并对所 述智能密钥设备中的证书和密钥进行分组， 使得证书与密钥对能够对应； 在 crtl_f()接口中实现设置证书命 令， 所述设置证书命令对所述智能密钥设备中的证书进行选择， 并将选择的证书及与选择的证书相对应的 密钥保存到所述硬件引擎的上下文中； 通过所述 load_SSl_Client_Cert()加载所述选择的证书及对应的算法密 钥。
14. 根据权利要求 3所述的方法， 其特征在于， 所述硬件加密接口包括密码令牌接口或加密服务提供 程序接口，
当所述硬件加密接口为密码令牌接口时， 所述 crtl_f()接口实现的操作还包括： 选择槽 slot、 通过智能 密钥设备序列号选择智能密钥设备、 获取总的智能密钥设备数量；
当所述引擎为加密服务提供程序接口时， 所述自定义命令还包括： 枚举容器、 选择容器、 获取总的容 器数量。
15. 根据权利要求 14所述的方法， 其特征在于， 所述引擎通过所述容器加载算法密钥及证书。
16.根据权利要求 1所述的方法， 其特征在于， 当所述第一接口包括第二数据结构中的加解密接口、 签 名接口、 验签接口和 SSL客户端认证接口时， 所述引擎根据所述加载的算法密钥， 控制所述智能密钥设备 对传入的数据进行加 /解密操作具体包括：
对传入的数据按照设定的填充方式进行填充， 所述填充方式包括： RSA PKCS1、 RSA X931、 RSA SSLV23或无填充方式；
进行登录检査， 如果没有进行登录， 则进行 PIN码验证， 进行登录操作， 如果已登录， 则控制所述智 能密钥设备对所述填充后的数据进行加解密操作。
17. 根据权利要求 1所述的方法， 其特征在于， 当所述第一接口包括第二数据结构中的加解密接口、 签名接口、 验签接口和 SSL客户端认证接口时， 第二数据结构中的签名接口被上层应用程序调用时， 所述 方法还包括： 创建 X509_SIG摘要结构。
18. 根据权利要求 1所述的方法， 其特征在于， 当所述第一接口包括第二数据结构中的加解密接口、 签名接口、 验签接口和 SSL客户端认证接口时， 所述 X509_SIG摘要结构用来存放摘要值和签名值。
19. 根据权利要求 1所述的方法， 其特征在于， 当所述第一接口包括第二数据结构中的加解密接口、 签名接口、验签接口和 SSL客户端认证接口时， 对传入的签名值进行解密操作， 并验证所述解密得到的摘 要值是否正确具体为： 对传入的签名值进行公钥解密， 并检査解密得到的摘要值的摘要模式是否与传入的 摘要模式相一致， 如果一致， 则将所述解密得到的摘要值与传入的摘要值进行对比， 如果一致， 则验签成 功。
PCT/CN2011/072250 2010-03-31 2011-03-29 加密引擎的实现方法 WO2011120421A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US13/635,918 US8995663B2 (en) 2010-03-31 2011-03-29 Method for implementing an encryption engine by smart key device

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
CN2010101386858A CN101820342B (zh) 2010-03-31 2010-03-31 硬件加密引擎的实现方法
CN201010138685.8 2010-03-31
CN201010214432.4 2010-06-30
CN 201010214432 CN102055759B (zh) 2010-06-30 2010-06-30 一种硬件引擎的实现方法
CN201010248457.6 2010-08-09
CN2010102484576A CN101908963B (zh) 2010-08-09 2010-08-09 一种摘要引擎的实现方法

Publications (1)

Publication Number Publication Date
WO2011120421A1 true WO2011120421A1 (zh) 2011-10-06

Family

ID=44711365

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/072250 WO2011120421A1 (zh) 2010-03-31 2011-03-29 加密引擎的实现方法

Country Status (2)

Country Link
US (1) US8995663B2 (zh)
WO (1) WO2011120421A1 (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109255246A (zh) * 2018-08-14 2019-01-22 平安普惠企业管理有限公司 接口参数加密方法、装置、计算机设备及存储介质
CN111756532A (zh) * 2020-06-08 2020-10-09 西安万像电子科技有限公司 数据传输方法及装置
CN115208615A (zh) * 2022-05-20 2022-10-18 北京科技大学 一种数控系统数据加密传输方法
CN111756532B (zh) * 2020-06-08 2024-06-07 西安万像电子科技有限公司 数据传输方法及装置

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8918641B2 (en) * 2011-05-26 2014-12-23 Intel Corporation Dynamic platform reconfiguration by multi-tenant service providers
US9773111B2 (en) * 2012-08-14 2017-09-26 Empire Technology Development Llc Software-based side-channel attack prevention
CN103093136B (zh) * 2012-12-27 2015-05-27 飞天诚信科技股份有限公司 一种java应用访问智能密钥装置的方法
US8924741B2 (en) 2012-12-29 2014-12-30 Intel Corporation Instruction and logic to provide SIMD secure hashing round slice functionality
US10038550B2 (en) 2013-08-08 2018-07-31 Intel Corporation Instruction and logic to provide a secure cipher hash round functionality
CN103544037B (zh) 2013-10-29 2016-08-17 飞天诚信科技股份有限公司 一种支持OpenSC的软硬件驱动的实现方法
US10503510B2 (en) 2013-12-27 2019-12-10 Intel Corporation SM3 hash function message expansion processors, methods, systems, and instructions
US9912481B2 (en) 2014-03-27 2018-03-06 Intel Corporation Method and apparatus for efficiently executing hash operations
US9317719B2 (en) 2014-09-04 2016-04-19 Intel Corporation SM3 hash algorithm acceleration processors, methods, systems, and instructions
US9658854B2 (en) 2014-09-26 2017-05-23 Intel Corporation Instructions and logic to provide SIMD SM3 cryptographic hashing functionality
CN105119894B (zh) * 2015-07-16 2018-05-25 上海慧银信息科技有限公司 基于硬件安全模块的通信系统及通信方法
US10826875B1 (en) * 2016-07-22 2020-11-03 Servicenow, Inc. System and method for securely communicating requests
HUE16774544T1 (hu) * 2016-07-29 2020-02-28 Permanent Privacy Ltd Biztonságos titkosításhoz kapcsolódó alkalmazások
CN107977565A (zh) * 2016-10-25 2018-05-01 航天信息股份有限公司 Usbkey接口系统及与usbkey连接的方法
US10243731B2 (en) 2017-01-27 2019-03-26 Accenture Global Solutions Limited Hardware blockchain acceleration
WO2020220034A1 (en) * 2019-04-26 2020-10-29 Csub Auxiliary For Sponsored Programs Administration Reconfigurable security hardware and methods for internet of things (iot) systems
CN112580061B (zh) * 2019-09-27 2023-04-07 科大国盾量子技术股份有限公司 一种量子加解密应用接口的调用方法及相关设备

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1457859A2 (en) * 2003-03-14 2004-09-15 Broadcom Corporation Data encryption/decryption device
CN1790359A (zh) * 2004-12-16 2006-06-21 国际商业机器公司 使用便携式计算设备作为智能密钥设备的方法和系统
US20090055556A1 (en) * 2007-08-20 2009-02-26 Ntt Docomo, Inc. External storage medium adapter
CN101552836A (zh) * 2009-05-18 2009-10-07 浙江大学 应用于手机中移动Widget引擎的实现方法
CN101820342A (zh) * 2010-03-31 2010-09-01 北京飞天诚信科技有限公司 硬件加密引擎的实现方法
CN101908963A (zh) * 2010-08-09 2010-12-08 北京飞天诚信科技有限公司 一种摘要引擎的实现方法

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5195136A (en) 1991-09-30 1993-03-16 Motorola, Inc. Method and apparatus for data encryption or decryption
US20030035547A1 (en) * 2001-03-27 2003-02-20 John Newton Server with multiple encryption libraries
US20030009687A1 (en) * 2001-07-05 2003-01-09 Ferchau Joerg U. Method and apparatus for validating integrity of software
US8024563B1 (en) * 2006-12-15 2011-09-20 Oracle America, Inc. Programming interface for a kernel level SSL proxy
GB2471282B (en) * 2009-06-22 2015-02-18 Barclays Bank Plc Method and system for provision of cryptographic services

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1457859A2 (en) * 2003-03-14 2004-09-15 Broadcom Corporation Data encryption/decryption device
CN1790359A (zh) * 2004-12-16 2006-06-21 国际商业机器公司 使用便携式计算设备作为智能密钥设备的方法和系统
US20090055556A1 (en) * 2007-08-20 2009-02-26 Ntt Docomo, Inc. External storage medium adapter
CN101552836A (zh) * 2009-05-18 2009-10-07 浙江大学 应用于手机中移动Widget引擎的实现方法
CN101820342A (zh) * 2010-03-31 2010-09-01 北京飞天诚信科技有限公司 硬件加密引擎的实现方法
CN101908963A (zh) * 2010-08-09 2010-12-08 北京飞天诚信科技有限公司 一种摘要引擎的实现方法

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109255246A (zh) * 2018-08-14 2019-01-22 平安普惠企业管理有限公司 接口参数加密方法、装置、计算机设备及存储介质
CN111756532A (zh) * 2020-06-08 2020-10-09 西安万像电子科技有限公司 数据传输方法及装置
CN111756532B (zh) * 2020-06-08 2024-06-07 西安万像电子科技有限公司 数据传输方法及装置
CN115208615A (zh) * 2022-05-20 2022-10-18 北京科技大学 一种数控系统数据加密传输方法
CN115208615B (zh) * 2022-05-20 2023-12-19 北京科技大学 一种数控系统数据加密传输方法

Also Published As

Publication number Publication date
US20130010955A1 (en) 2013-01-10
US8995663B2 (en) 2015-03-31

Similar Documents

Publication Publication Date Title
WO2011120421A1 (zh) 加密引擎的实现方法
CN102055759B (zh) 一种硬件引擎的实现方法
Dierks et al. The transport layer security (TLS) protocol version 1.2
US7600122B2 (en) Methods and apparatus for accelerating secure session processing
Dierks et al. RFC 5246: The transport layer security (TLS) protocol version 1.2
US8009829B2 (en) Method and system for deploying advanced cryptographic algorithms
US8032742B2 (en) Dynamic updating of trusted certificates and certificate revocation lists in a computing system
US6892301B1 (en) Method and system for securely handling information between two information processing devices
CN101459506B (zh) 密钥协商方法、用于密钥协商的系统、客户端及服务器
CN101820342B (zh) 硬件加密引擎的实现方法
US11582045B2 (en) Combined digital signature algorithms for security against quantum computers
CN112422507B (zh) 一种基于标识算法的国密ssl加密方法
US8042156B2 (en) Mapping proprietary SSL APIs onto openssl APIs
Dierks et al. RFC 4346: The transport layer security (TLS) protocol version 1.1
CN112398826A (zh) 基于国密的数据处理方法、装置、存储介质及电子设备
CN113452522B (zh) 基于国密的硬件安全模块软件实现方法、存储介质及装置
Cooper et al. Fido device onboard specification 1.1
Jiang et al. Design and implementtationg of an IPsec VPN gateway base on OpenWRT
RU2707398C1 (ru) Способ и система защищенного хранения информации в файловых хранилищах данных
Åkesson Hermod: A File Transfer Protocol Using Noise Protocol Framework
Leon Hejdenberg Establishment of Secure Channel Binding with Remote Party Attestation
BSAFE SSL-C
CN117544951A (zh) 一种5g物联网安全网关
Mavrogiannopoulos et al. The GnuTLS manual
CN116566612A (zh) Quic连接建立方法及系统、装置、电子设备和存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11761995

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 13635918

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11761995

Country of ref document: EP

Kind code of ref document: A1