Session-based cryptographic card asynchronous invocation method and system

Abstract

This invention proposes a session-based asynchronous cipher card invocation method and system. The method includes: an SDK that opens the device, registers a callback function, and returns the application device handle; the SDK creates a SessionHandle object, requests an idle ring channel, saves its ring_id number to the SessionHandle, starts a polling thread, and returns the SessionHandle; the polling thread receives data from the ring channel; the SDK encapsulates the information to be sent into a data packet, sends it through the ring channel with the ring_id number saved in the SessionHandle, and returns immediately; the SDK polling thread polls the results through the SessionHandle, and automatically executes the callback function to process the results after they are found; after the application completes the cipher card invocation, it closes the device.

Description

Technical Field

[0001] This invention relates to the field of cryptographic cards, and more particularly to a session-based asynchronous invocation method and system for cryptographic cards. Background Technology

[0002] Cryptographic cards are used to provide hardware cryptographic security services, such as PCI-E cryptographic cards. Typically, the cryptographic card is connected to the host computer via an external device. When the host application needs to perform encryption and decryption processing, it needs to call the cryptographic card for hardware cryptographic service support. However, traditional calling methods can easily lead to call congestion as the number of applications increases and the call demand rises, which is detrimental to fully utilizing the cryptographic card's performance and also reduces the user experience. Summary of the Invention

[0003] Based on the above, it is necessary to provide a session-based asynchronous invocation method and system for cryptographic cards, which can effectively avoid blocking of data exchange between the host application and the cryptographic card, improve user experience, and fully utilize the performance of the cryptographic card.

[0004] The first aspect of this invention proposes a session-based asynchronous invocation method for cryptographic cards, the method comprising:

[0005] Initialization: The application calls the SDK to initialize; the SDK opens the password card device, registers a callback function, and returns the password card device handle;

[0006] Opening a session: The application calls the SDK to open a session; the SDK creates a session object SessionHandle, requests an idle ring channel through the driver, records its number as ring_id and saves it in SessionHandle, starts a polling thread, and returns SessionHandle;

[0007] Data transmission: The application calls the SDK and sends the information to be processed through SessionHandle; the SDK encapsulates the information to be processed into a data packet, sends it through the ring channel with the number ring_id stored in SessionHandle, and returns immediately;

[0008] Data reception: The SDK polling thread polls the results through SessionHandle, and automatically executes the callback function to process the results after they are retrieved;

[0009] Closing the session: The application calls the SDK to close the session; the SDK closes the polling thread and releases the SessionHandle;

[0010] Shutting down the device: The application calls the SDK to shut down the password card device and release related resources.

[0011] Based on the above, the initialization steps specifically include:

[0012] The application initializes itself by calling the SDK initialization function through initialization parameters, which include password card device information and function calls.

[0013] The SDK initialization function opens the cryptographic card device by operating on the Open function, obtains the cryptographic card device handle fd, and returns the cryptographic card device handle fd to the application.

[0014] The SDK initialization function registers a callback function for use by polling threads.

[0015] Based on the above, the steps to open a session specifically include:

[0016] The application calls the SDK's open session function to open a session, and the transmission parameter is the password card device handle fd;

[0017] The SDK requests a SessionHandle object and assigns the password card device handle fd to the SessionHandle.

[0018] The SDK requests an idle ring channel through the driver. If the request for the ring channel fails, it returns a failure message to the application. If it succeeds, it continues to execute subsequent steps.

[0019] The SDK assigns the ring channel number, ring_id, to the SessionHandle.

[0020] The SDK starts a polling thread, which is used to receive the calculation result data of the ring_id channel.

[0021] The SDK returns a SessionHandle to the application.

[0022] Based on the above, the data transmission step specifically includes:

[0023] The application calls the SDK to send the information to be processed, which includes the data to be processed (DATA), the algorithm type (alg_id), the algorithm mode (alg_mode), the encryption key (key), the vector (iv), the data address (src_adrr), and the data length (data_len).

[0024] The SDK requests a session context entity session_st, assigns the information to be computed to session_st, and assigns the ring_id from SessionHandle to session_st;

[0025] The SDK allocates memory to store the computation results and assigns that memory address to the computation result address dst_addr of session_st;

[0026] The SDK calls the device's write function to write session_st to the driver.

[0027] The driver receives session_st, finds the address of the channel numbered session_st->ring_id, and queries the spatial location req in the session_st->ring_id channel;

[0028] The driver fills the corresponding fields of req with the algorithm type alg_id, algorithm mode alg_mode, encryption key key, vector iv, data address src_addr, operation result address dst_addr and data length data_len from session_st;

[0029] The driver requests a transparent transfer entity transfer_descriptor_st, and fills the corresponding fields of transfer_descriptor_st with the algorithm type alg_id, algorithm mode alg_mode, operation result address dst_addr, and data length data_len from session_st.

[0030] The driver fills the transfer_descriptor_st address into the pass-through data field of req;

[0031] The driver updates the transmit register of the cryptographic card, which is used by the cryptographic card to transfer the req information to the cryptographic card via DMA for processing and then return immediately.

[0032] Based on the above, the data receiving steps specifically include:

[0033] The SDK polling thread obtains the ring_id from the SessionHandle;

[0034] The SDK polling thread periodically sends ioctl instruction information to the driver, and the ioctl instruction information includes the ring_id, which is used to receive the data address space;

[0035] The SDK polling thread queries the received data address space. If data is found, the data in the received data address is assigned to the callback function, and the callback function is executed.

[0036] The data in the receiving address includes the algorithm type alg_id, the algorithm mode alg_mode, the operation result address dst_addr, and the data length data_len;

[0037] The callback function releases the address of the computation result, dst_addr.

[0038] Based on the above, the driver obtains the ring_id from the ioctl instruction information, queries the ring channel with the ring_id, and if data is found, returns it to the polling thread for processing, specifically including:

[0039] The driver obtains the ring_id from the ioctl instruction information;

[0040] The driver checks if there is a response packet (resp) in the receive queue of the ring channel with the number ring_id. If there is a resp, it executes the following:

[0041] The driver retrieves the address of transfer_descriptor_st from the pass-through data field of resp and assigns the transfer_descriptor_st member to the receiving data address space.

[0042] A second aspect of the present invention provides a session-based asynchronous invocation system for cryptographic cards, comprising a host and a cryptographic card, wherein the host and the cryptographic card are connected for data communication; the host is equipped with an application program and configured with an SDK and a driver program; the cryptographic card is used to provide cryptographic security services to the application program.

[0043] When the host calls the password card, it uses the asynchronous password card calling method.

[0044] Based on the above, the cryptographic card supports Chinese national cryptographic encryption and decryption algorithms and signature algorithms.

[0045] The beneficial effects of this invention are:

[0046] (1) The callback function is injected into the polling thread by injection, which reduces the IO calls between the application and the driver and improves the execution efficiency;

[0047] (2) Data processing is implemented based on the session method. The polling thread polls the DMA channel data corresponding to the session, reducing the IO interaction between the SDK and the kernel and improving system efficiency;

[0048] (3) A polling thread is established for each session. Different sessions can be established for different operations. A multi-threaded mechanism can be adopted to improve retrieval efficiency.

[0049] (4) The polling thread only polls the open DMA channels and does not poll the DMA channels that are not open, thus saving resources;

[0050] (5) The data sending thread and the polling thread are in the same process. The polling thread can directly execute the callback function, reducing the operation of the matching process.

[0051] Additional aspects and advantages of the invention will become apparent in the following description or may be learned by practice of the invention. Attached Figure Description

[0052] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which:

[0053] Figure 1 A flowchart of the asynchronous invocation method for a cryptographic card according to Embodiment 1 of the present invention is shown. Detailed Implementation

[0054] To better understand the above-mentioned objectives, features, and advantages of the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be combined with each other.

[0055] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and therefore the scope of protection of the invention is not limited to the specific embodiments disclosed below.

[0056] Example 1

[0057] like Figure 1 As shown, the cryptographic card software architecture mainly involves the data interaction of five objects: application (App), SDK, SDK polling thread, driver, and cryptographic card device.

[0058] This embodiment provides an asynchronous call method for a password card, including:

[0059] initialization

[0060] The application calls the SDK for initialization; the SDK opens the device, registers callback functions, and returns the application's device handle.

[0061] The application calls the SDK for initialization, which includes:

[0062] The application initializes itself by calling the SDK initialization function through initialization parameters, which include password card device information and callback functions.

[0063] The application initializes itself by calling the SDK initialization function through initialization parameters, which include password card device information and function calls.

[0064] The SDK initialization function opens the cryptographic card device by operating on the Open function, obtains the cryptographic card device handle fd, and returns the cryptographic card device handle fd to the application.

[0065] The SDK initialization function registers a callback function for use by polling threads.

[0066] Open a session

[0067] The application calls the SDK to open a session; the SDK creates a session object SessionHandle, requests an idle ring channel through the driver, records its number as ring_id and saves it in the SessionHandle, starts a polling thread, and returns the SessionHandle; the polling thread is used to receive data from the ring_id channel.

[0068] Opening a session specifically includes:

[0069] The application calls the SDK's open session function to open a session, and the transmission parameter is the password card device handle fd;

[0070] The SDK requests a SessionHandle object and assigns the password card device handle fd to the SessionHandle.

[0071] The SDK requests an idle ring channel through the driver. If the request for the ring channel fails, it returns a failure message to the application. If it succeeds, it continues to execute the following steps.

[0072] The SDK then assigns the ring channel number, ring_id, to the SessionHandle.

[0073] The SDK starts a polling thread, which is used to receive the calculation result data of the ring_id channel;

[0074] The SDK returns the SessionHandle to the application.

[0075] Data transmission

[0076] The application calls the SDK and sends the information to be processed through the SessionHandle; the SDK encapsulates the information to be processed into a data packet, sends it through the ring channel with the number ring_id stored in the SessionHandle, and returns immediately.

[0077] Data transmission specifically includes:

[0078] The application calls the SDK to send the information to be processed, which includes the data to be processed (DATA), the algorithm type (alg_id), the algorithm mode (alg_mode), the encryption key (key), the vector (iv), the data address (src_adrr), the data length (data_len), and other related information.

[0079] The SDK requests a session context entity session_st, assigns the information to be computed to session_st, and assigns the ring_id in the SessionHandle to session_st;

[0080] The SDK allocates memory to store the computation results and assigns that memory address to the computation result address dst_addr of session_st;

[0081] The SDK calls the device's write function to write the session_st to the driver.

[0082] The driver receives the session_st, finds the address of the channel numbered session_st->ring_id, and queries the spatial location req in the session_st->ring_id channel.

[0083] The driver fills the fields corresponding to the req with information from the session_st, such as the algorithm type alg_id, algorithm mode alg_mode, encryption key key, vector iv, data address src_addr, operation result address dst_addr, and data length data_len.

[0084] The driver requests a transparent transfer entity transfer_descriptor_st, and fills the corresponding fields of transfer_descriptor_st with information such as algorithm type alg_id, algorithm mode alg_mode, operation result address dst_addr, and data length data_len from session_st.

[0085] The driver fills the transfer_descriptor_st address into the pass-through data field of req;

[0086] The driver updates the password sending register, which is used by the encryption card to transfer the req information to the encryption card via DMA for processing and then return immediately.

[0087] Data reception

[0088] The SDK polling thread polls the results through the SessionHandle, and automatically executes the callback function to process the results after they are retrieved.

[0089] Data reception specifically includes:

[0090] The SDK polling thread obtains the ring_id from the SessionHandle;

[0091] The SDK polling thread periodically sends ioctl instruction information to the driver. The ioctl instruction information includes the ring_id and the address space used to receive data.

[0092] The SDK polling thread queries the received data address space. If data is found, the data in the received data address is assigned to the callback function, and the callback function is executed.

[0093] The data in the receiving address includes: algorithm type alg_id, algorithm mode alg_mode, operation result address dst_addr, data length data_len, and other information;

[0094] The callback function releases the address of the computation result, dst_addr.

[0095] The driver obtains the ring_id from the ioctl instruction information, queries the ring channel with the ring_id, and if data is found, returns it to the polling thread for processing, specifically including:

[0096] The driver obtains the ring_id from the ioctl instruction information;

[0097] The driver determines whether there is a response packet (resp) in the receive queue of the ring channel with the ring_id number. If there is a resp, the following is executed:

[0098] The driver retrieves the address of transfer_descriptor_st from the pass-through data field of resp and assigns the transfer_descriptor_st member to the received data address space.

[0099] Close session

[0100] The application calls the SDK to close the session; the SDK closes the polling thread and releases the SessionHandle.

[0101] Turn off the device

[0102] The application calls the SDK to shut down the device and release related resources.

[0103] Example 2

[0104] This embodiment provides an asynchronous invocation system for a password card, including a host and a password card. The host and the password card are connected for data communication. The host has an application program (APP) installed and is configured with an SDK, a polling thread, and a driver. The password card is used to provide password security services to the application program.

[0105] When the host terminal calls the password card, it uses the asynchronous password card calling method described in Embodiment 1.

[0106] Furthermore, the cryptographic card supports Chinese national cryptographic encryption and decryption algorithms as well as signature algorithms.

[0107] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A session-based asynchronous invocation method for cryptographic cards, characterized in that, The method includes: Initialization: The application calls the SDK to initialize; the SDK opens the password card device, registers a callback function, and returns a handle to the password card device; Opening a session: The application calls the SDK to open a session; the SDK creates a session object SessionHandle, requests an idle ring channel through the driver, records its number as ring_id and saves it in SessionHandle, starts a polling thread, and returns SessionHandle; Data transmission: The application calls the SDK and sends the information to be processed through SessionHandle; the SDK encapsulates the information to be processed into a data packet, sends it through the ring channel with the number ring_id stored in SessionHandle, and returns immediately; The data transmission steps specifically include: The application calls the SDK to send the information to be processed, which includes the data to be processed (DATA), the algorithm type (alg_id), the algorithm mode (alg_mode), the encryption key (key), the vector (iv), the data address (src_adrr), and the data length (data_len). The SDK requests a session context entity session_st, assigns the information to be computed to session_st, and assigns the ring_id from SessionHandle to session_st; The SDK allocates memory to store the computation results and assigns that memory address to the computation result address dst_addr of session_st; The SDK calls the device's write function to write session_st to the driver. The driver receives session_st, finds the address of the channel numbered session_st->ring_id, and queries the spatial location req in the session_st->ring_id channel; The driver fills the corresponding fields of req with the algorithm type alg_id, algorithm mode alg_mode, encryption key key, vector iv, data address src_addr, operation result address dst_addr and data length data_len from session_st; The driver requests a transparent transfer entity transfer_descriptor_st, and fills the corresponding fields of transfer_descriptor_st with the algorithm type alg_id, algorithm mode alg_mode, operation result address dst_addr, and data length data_len from session_st. The driver fills the transfer_descriptor_st address into the pass-through data field of req; The driver updates the transmit register of the cryptographic card, which is used by the cryptographic card to transfer the req information to the cryptographic card via DMA for processing and then return immediately; Data reception: The SDK polling thread polls the results through SessionHandle, and automatically executes the callback function to process the results after they are retrieved; The data receiving steps specifically include: The SDK polling thread obtains the ring_id from the SessionHandle; The SDK polling thread periodically sends ioctl instruction information to the driver, and the ioctl instruction information includes the ring_id, which is used to receive the data address space; The SDK polling thread queries the received data address space. If data is found, the data in the received data address is assigned to the callback function, and the callback function is executed. The data in the receiving address includes the algorithm type alg_id, the algorithm mode alg_mode, the operation result address dst_addr, and the data length data_len; The callback function releases the address of the computation result, dst_addr. Closing the session: The application calls the SDK to close the session; the SDK closes the polling thread and releases the SessionHandle; Shutting down the device: The application calls the SDK to shut down the password card device and release related resources.

2. The session-based asynchronous invocation method for cryptographic cards according to claim 1, characterized in that, The initialization steps specifically include: The application initializes itself by calling the SDK initialization function through initialization parameters, which include password card device information and function calls. The SDK initialization function opens the cryptographic card device by operating on the Open function, obtains the cryptographic card device handle fd, and returns the cryptographic card device handle fd to the application. The SDK initialization function registers a callback function for use by polling threads.

3. The session-based asynchronous invocation method for cryptographic cards according to claim 1, characterized in that, The specific steps to open a session include: The application calls the SDK's open session function to open a session, and the transmission parameter is the password card device handle fd; The SDK requests a SessionHandle object and assigns the password card device handle fd to the SessionHandle. The SDK requests an idle ring channel through the driver. If the request for the ring channel fails, it returns a failure message to the application. If it succeeds, it continues to execute subsequent steps. The SDK assigns the ring channel number, ring_id, to the SessionHandle. The SDK starts a polling thread, which is used to receive the calculation result data of the ring_id channel. The SDK returns a SessionHandle to the application.

4. The session-based asynchronous invocation method for cryptographic cards according to claim 1, characterized in that, The driver obtains the ring_id from the ioctl instruction information, queries the ring channel with the ring_id, and if data is found, returns it to the polling thread for processing, specifically including: The driver obtains the ring_id from the ioctl instruction information; The driver checks if there is a response packet (resp) in the receive queue of the ring channel with the number ring_id. If there is a resp, it executes the following: The driver retrieves the address of transfer_descriptor_st from the pass-through data field of resp and assigns the transfer_descriptor_st member to the receiving data address space.

5. A session-based asynchronous cryptographic card invocation system, characterized in that: It includes a host and a password card, wherein the host and the password card are connected for data communication; the host has an application installed and is configured with an SDK and a driver; the password card is used to provide password security services to the application. When the host terminal calls the password card, it uses the asynchronous password card calling method according to any one of claims 1-4.

6. The asynchronous invocation system for a cryptographic card according to claim 5, characterized in that, The cryptographic card supports Chinese national cryptographic encryption and decryption algorithms as well as signature algorithms.

Images