A method and system for asynchronous invocation of cryptographic cards

Abstract

This invention proposes an asynchronous invocation method and system for cryptographic cards. The method includes: device opening: the application opens the cryptographic card through the SDK main thread and creates a polling thread to query the returned data status; data sending: when the application calls the cryptographic service interface through the SDK main thread, the cryptographic service interface passes the calculation data, the sending process descriptor pid_send, the callback function parameters, and the callback function pointer to the driver and returns immediately without waiting for the cryptographic card's calculation result; data receiving: after the SDK polling thread queries the cryptographic service calculation result, it automatically executes the callback function to complete subsequent operations. This invention can effectively avoid the blocking of data interaction between the host application and the cryptographic card, improve the user experience, and fully utilize the performance of the cryptographic card.

Description

Technical Field

[0001] This invention relates to the field of cryptographic cards, and more particularly to a method and system for asynchronous invocation of 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 grows, 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 method and system for asynchronous invocation of password cards, which can effectively avoid the blocking of data exchange between the host application and the password card, improve the user experience, and give full play to the performance of the password card.

[0004] The first aspect of this invention proposes an asynchronous invocation method for a cryptographic card, the method comprising:

[0005] Device unlock: The application unlocks the password card via the SDK main thread and creates a polling thread to query the returned data status;

[0006] Data transmission: When the application calls the password service interface through the SDK main thread, the password service interface passes the calculation data, the sending process descriptor pid_send, the callback function parameters and the callback function pointer to the driver and returns immediately without waiting for the password card's calculation result;

[0007] Data reception: After the SDK polling thread retrieves the password service calculation result, it automatically executes the callback function to complete the subsequent operations.

[0008] Based on the above, in the device opening step, the SDK obtains the character device descriptor fd through the character device open function and then opens the password card.

[0009] Based on the above, the SDK obtains the file descriptor (fd) of the character device using the character device's `open` function to open the password card, specifically including:

[0010] The SDK main thread operates on the character device's open function, which then enters the kernel driver;

[0011] The kernel driver implements the association between the cryptographic card and the character device in the character device open function and returns the file descriptor fd of the character device.

[0012] Based on the above, the kernel driver implements the association between the cryptographic card and the character device in the character device open function, specifically including:

[0013] Obtain information for all m DMA channels of the character device, denoted as xdja_ring_handle[m].

[0014] Select n DMA channels from m DMA channels and save them to the private data of the character device, where n ≤ m;

[0015] Returns the file descriptor fd of the character device to the SDK main thread.

[0016] Based on the above, a polling thread is created, specifically including:

[0017] After the SDK main thread obtains the file descriptor fd of the character device file, it creates a polling thread;

[0018] The polling thread calls the character device's ioctl function, passing the character device's file descriptor fd and process descriptor pid_poll to the kernel driver. The kernel driver retrieves n DMA channel information from the private data of the character device's file descriptor fd and polls the receive queues of the n DMA channels one by one.

[0019] Based on the above, the specific steps for sending data include:

[0020] When the application calls the SDK password card service interface, the SDK main thread receives the data to be processed by the application and passes the data to be processed, the sending process descriptor pid_send, the callback function pointer and the callback function parameters to the kernel driver through the character device's ioctl function;

[0021] The kernel driver retrieves the DMA channels stored in the private data of the character device, selects one of the DMA channels, and denots it as xdja_ring_handle, for use in this data transmission.

[0022] The kernel driver allocates memory cb_data and stores the sending process descriptor pid_send, the callback function pointer, and the callback function parameters in cb_data;

[0023] The kernel driver assembles the request packet req and fills the starting address of cb_data into the pass-through data field of the request packet req;

[0024] The kernel driver iterates through the send queue corresponding to xdja_ring_handle, puts the request packet req into the free position of xdja_ring_handle and starts sending.

[0025] Based on the above, the data reception steps specifically include: the SDK polling thread passes the file descriptor fd of the character device and the sending process descriptor pid_poll to the kernel driver through the character device's ioctl function;

[0026] The kernel driver retrieves the n DMA channel information stored in the private data of the character device and queries the receive queue of each DMA for a response packet resp. If there is one, it executes step 1; otherwise, it continues to query the next one.

[0027] Step 1: Retrieve the response packet resp from the receive queue and parse it;

[0028] Step 2: Obtain the pass-through data address of cb_data from the response packet resp;

[0029] Step 3: Obtain the callback function parameters from cb_data, extract the address of the SDK layer calculation result user_dst from the callback function parameters, and copy the calculation result to that address;

[0030] Step 4: Compare whether the sending process descriptor pid_send obtained from cb_data and the polling thread's process descriptor pid_poll are consistent. If they are consistent, proceed to step 5; otherwise, proceed to step 6.

[0031] Step 5: Return the callback function pointer and callback function parameters to the SDK polling thread, and the SDK polling thread executes the callback function to process the calculation result;

[0032] Step 6: Save the polled callback function pointer, callback function parameters, and sending process descriptor pid_send packet as an element into the global linked list list;

[0033] Step 7: Traverse the global linked list list, compare the member pid_send of each element in the list with the polling thread pid_poll. If they match, return the corresponding callback function pointer and callback function parameters to the SDK polling thread, and delete the element corresponding to pid_send.

[0034] A second aspect of the present invention provides an asynchronous invocation system for a cryptographic card, 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 main thread, an SDK polling thread, and a kernel driver; the cryptographic card is used to provide cryptographic security services to the application program.

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

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

[0037] The beneficial effects of this invention are:

[0038] (1) After sending one packet of data, there is no need to wait for the result to continue sending the next packet of data, saving time and IO overhead, and making full use of the performance of the cryptographic card;

[0039] (2) Immediately return preliminary results to the caller to avoid blocking and improve user experience;

[0040] (3) Each time the SDK main thread opens the device system, it creates a new character device file descriptor and associates it with a certain amount of DMA channels. The polling thread only needs to poll the DMA channels associated with the character device file descriptor, without polling all the DMA channels of the password card, thereby improving polling efficiency.

[0041] (4) When the sending thread assembles the pass-through data field of the request packet req, it saves a memory address instead of a specific data. The memory address can save as much information as possible, which is convenient for software processing.

[0042] (5) Only the process descriptor pid needs to be matched to call the callback function, without the need to match the packet sequence number, thus improving response efficiency.

[0043] 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

[0044] 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:

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

[0046] Figure 2 A flowchart of the result data reception in Embodiment 1 of the present invention is shown. Detailed Implementation

[0047] 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.

[0048] 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.

[0049] Example 1

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

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

[0052] Device turned on

[0053] The application opens the password card through the SDK main thread and creates a polling thread to query the returned data status.

[0054] In the device opening step, the SDK obtains the character device descriptor fd through the character device open function and then opens the password card.

[0055] Specifically, the SDK obtains the file descriptor (fd) of the character device using the `open` function to open the password card, including:

[0056] The SDK main thread operates on the character device's open function, which then enters the kernel driver;

[0057] The kernel driver implements the association between the cryptographic card and the character device in the character device open function and returns the file descriptor fd of the character device.

[0058] Specifically, the kernel driver implements the association between the cryptographic card and the character device in the character device open function, including:

[0059] Obtain information for all m DMA channels of the character device, denoted as xdja_ring_handle[m].

[0060] Select n DMA channels from m DMA channels and save them to the private data of the character device, where n ≤ m;

[0061] Returns the file descriptor fd of the character device to the SDK main thread.

[0062] Creating a polling thread specifically includes:

[0063] After the SDK main thread obtains the file descriptor fd of the character device file, it creates a polling thread;

[0064] The polling thread calls the character device's ioctl function, passing the character device's file descriptor fd and process descriptor pid_poll to the kernel driver. The kernel driver retrieves n DMA channel information from the private data of the character device's file descriptor fd and polls the receive queues of the n DMA channels one by one.

[0065] Data transmission

[0066] When the application calls the password service interface through the SDK main thread, the password service interface passes the calculation data, the sending process descriptor pid_send, the callback function parameters, and the callback function pointer to the driver and returns immediately without waiting for the password card's calculation result.

[0067] The specific steps for sending data include:

[0068] When the application calls the SDK password card service interface, the SDK main thread receives the data to be processed by the application and passes the data to be processed, the sending process descriptor pid_send, the callback function pointer and the callback function parameters to the kernel driver through the character device's ioctl function;

[0069] The kernel driver retrieves the DMA channels stored in the private data of the character device, selects one of the DMA channels, and denots it as xdja_ring_handle, for use in this data transmission.

[0070] The kernel driver allocates memory cb_data and stores the sending process descriptor pid_send, the callback function pointer, and the callback function parameters in cb_data;

[0071] The kernel driver assembles the request packet req and fills the starting address of cb_data into the pass-through data field of the request packet req;

[0072] The kernel driver iterates through the send queue corresponding to xdja_ring_handle, puts the request packet req into the free position of xdja_ring_handle and starts sending.

[0073] Data reception

[0074] After the SDK polling thread retrieves the password service calculation result, it automatically executes the callback function to complete the subsequent operations.

[0075] like Figure 2 As shown, the data reception steps specifically include:

[0076] The SDK polling thread passes the character device's file descriptor (fd) and the sending process descriptor (pid_poll) to the kernel driver via the character device's ioctl function.

[0077] The kernel driver retrieves the n DMA channel information stored in the private data of the character device and queries the receive queue of each DMA for a response packet resp. If there is one, it executes step 1; otherwise, it continues to query the next one.

[0078] Step 1: Retrieve the response packet resp from the receive queue and parse it;

[0079] Step 2: Obtain the pass-through data address of cb_data from the response packet resp;

[0080] Step 3: Obtain the callback function parameters from cb_data, extract the address of the SDK layer calculation result user_dst from the callback function parameters, and copy the calculation result to that address;

[0081] Step 4: Compare whether the sending process descriptor pid_send obtained from cb_data and the polling thread's process descriptor pid_poll are consistent. If they are consistent, proceed to step 5; otherwise, proceed to step 6.

[0082] Step 5: Return the callback function pointer and callback function parameters to the SDK polling thread, and the SDK polling thread executes the callback function to process the calculation result;

[0083] Step 6: Save the polled callback function pointer, callback function parameters, and sending process descriptor pid_send packet as an element into the global linked list list;

[0084] Step 7: Traverse the global linked list list, compare the member pid_send of each element in the list with the polling thread pid_poll. If they match, return the corresponding callback function pointer and callback function parameters to the SDK polling thread, and delete the element corresponding to pid_send.

[0085] It is understandable that data reception is handled by a polling thread, which is started at the SDK layer. The polling thread is started when the SDK opens the device, and it continuously sends ioctl commands to query all DMA channels corresponding to the character device.

[0086] Example 2

[0087] This embodiment provides an asynchronous invocation system for a cryptographic card, including a host and a cryptographic card. The host and the cryptographic card are connected for data communication. The host has an application installed and is configured with an SDK main thread, an SDK polling thread, and a kernel driver. The cryptographic card is used to provide cryptographic security services to the application.

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

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

[0090] 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 method for asynchronously invoking a password card, characterized in that, The method includes: Device unlock: The application unlocks the password card via the SDK main thread and creates a polling thread to query the returned data status; Data transmission: When the application calls the password service interface through the SDK main thread, the password service interface passes the calculation data, the sending process descriptor pid_send, the callback function parameters and the callback function pointer to the driver and returns immediately without waiting for the password card's calculation result; The specific steps for sending data include: When the application calls the SDK password card service interface, the SDK main thread receives the data to be processed by the application and passes the data to be processed, the sending process descriptor pid_send, the callback function pointer and the callback function parameters to the kernel driver through the character device's ioctl function; The kernel driver retrieves the DMA channels stored in the private data of the character device, selects one of the DMA channels, and denots it as xdja_ring_handle, for use in this data transmission. The kernel driver allocates memory cb_data and stores the sending process descriptor pid_send, the callback function pointer, and the callback function parameters in cb_data; The kernel driver assembles the request packet req and fills the starting address of cb_data into the pass-through data field of the request packet req; The kernel driver iterates through the send queue corresponding to xdja_ring_handle, puts the request packet req into the free position of xdja_ring_handle and starts sending; Data reception: After the SDK polling thread retrieves the password service calculation result, it automatically executes the callback function to complete subsequent operations; The data reception steps specifically include: the SDK polling thread passes the file descriptor fd of the character device and the sending process descriptor pid_poll to the kernel driver through the character device's ioctl function; The kernel driver retrieves the n DMA channel information stored in the private data of the character device and queries the receive queue of each DMA for a response packet resp. If there is one, it executes step 1; otherwise, it continues to query the next one. Step 1: Retrieve the response packet resp from the receive queue and parse it; Step 2: Obtain the pass-through data address of cb_data from the response packet resp; Step 3: Obtain the callback function parameters from cb_data, extract the address of the SDK layer calculation result user_dst from the callback function parameters, and copy the calculation result to that address; Step 4: Compare whether the sending process descriptor pid_send obtained from cb_data and the polling thread's process descriptor pid_poll are consistent. If they are consistent, proceed to step 5; otherwise, proceed to step 6. Step 5: Return the callback function pointer and callback function parameters to the SDK polling thread, and the SDK polling thread executes the callback function to process the calculation result; Step 6: Save the polled callback function pointer, callback function parameters, and sending process descriptor pid_send packet as an element into the global linked list list; Step 7: Traverse the global linked list list, compare the member pid_send of each element in the list with the polling thread pid_poll. If they match, return the corresponding callback function pointer and callback function parameters to the SDK polling thread, and delete the element corresponding to pid_send.

2. The asynchronous invocation method for a password card according to claim 1, characterized in that: In the device opening step, the SDK obtains the character device descriptor fd through the character device open function and then opens the password card.

3. The asynchronous invocation method for a cryptographic card according to claim 2, characterized in that, The SDK uses the `open` function of the character device to obtain the file descriptor (fd) of the character device and then opens the password card, specifically including: The SDK main thread operates on the character device's open function, which then enters the kernel driver; The kernel driver implements the association between the cryptographic card and the character device in the character device open function and returns the file descriptor fd of the character device.

4. The asynchronous invocation method for a cryptographic card according to claim 3, characterized in that, The kernel driver implements the association between the cryptographic card and the character device in the character device open function, specifically including: Obtain information for all m DMA channels of the character device, denoted as xdja_ring_handle[m]. Select n DMA channels from m DMA channels and save them to the private data of the character device, where n ≤ m; Returns the file descriptor fd of the character device to the SDK main thread.

5. The asynchronous invocation method for a password card according to claim 4, characterized in that, Creating a polling thread specifically includes: After the SDK main thread obtains the file descriptor fd of the character device file, it creates a polling thread; The polling thread calls the character device's ioctl function, passing the character device's file descriptor fd and process descriptor pid_poll to the kernel driver. The kernel driver retrieves n DMA channel information from the private data of the character device's file descriptor fd and polls the receive queues of the n DMA channels one by one.

6. An asynchronous invocation system for a password card, characterized in that: It includes a host and a cryptographic card, with the host and cryptographic card communicating with each other. The host has an application installed and is configured with an SDK main thread, an SDK polling thread, and a kernel driver. The cryptographic card is used to provide cryptographic 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 to 5.

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

Images