Unified cryptographic interface management system and method based on hardware feature automatic identification

Abstract

The invention discloses a unified cryptographic interface management system and method based on hardware feature automatic identification. The system obtains a manufacturer identifier VID and a product identifier PID of the safety equipment by scanning a USB bus, dynamically loads a corresponding manufacturer driver library according to a built-in static mapping table during deployment, and analyzes and constructs an SKF standard interface function pointer table by using a dynamic symbol; when the equipment is opened, a packaging handle containing a real equipment handle and a function pointer table is generated, and subsequent interface calling is specifically realized by unpacking the handle and routing to a manufacturer; and meanwhile, a global unique equipment identifier is generated by adopting a manufacturer name: equipment model combination format, so that the conflict of equipment names of multiple manufacturers is avoided. According to the scheme, user configuration is not needed, plug-and-play and transparent calling of multi-brand UKEYs are supported, and the compatibility and management efficiency of national secret equipment are improved.

Description

Technical Field

[0001] This invention relates to the field of information security and cryptographic device management technology, and in particular to a unified national cryptographic interface management system and method based on automatic identification of hardware features. Background Technology

[0002] In domestically developed cryptographic applications, smart cryptographic keys (commonly known as UKEYs) are the core hardware carriers for identity authentication, digital signatures, and data encryption / decryption. To standardize the access methods of upper-layer applications to devices from different manufacturers, the State Cryptography Administration issued the "GM / T 0016-2012 Smart Cryptographic Key Cryptographic Application Interface Specification," which defines a set of standard SKF (Security Key Function) interfaces, including functions such as SKF_EnumDev, SKF_OpenDev, and SKF_RSASignData.

[0003] Currently, each USB key manufacturer implements its own SKF driver library (usually a dynamic link library, such as an xx.so file) based on this specification and provides it for application integration. However, because the specification does not specify the driver loading mechanism and device naming rules, there are differences in the implementations of different manufacturers.

[0004] Firstly, regarding driver deployment, applications typically need to pre-install driver libraries from specific vendors and specify the loading location at runtime via hard-coded paths or environment variables. When multiple vendors' devices exist in the system, multiple driver libraries need to be deployed simultaneously, and there is a lack of a unified loading management mechanism.

[0005] Secondly, during the device enumeration phase, the device names returned by drivers from different manufacturers often lack uniqueness. For example, multiple USB keys from different brands may all return "USB Token" or an empty string as the device name. This makes it impossible for applications to accurately distinguish the target device by its name in scenarios where multiple devices coexist.

[0006] Furthermore, SKF interface calls depend on the specific driver implementation provided by the vendor. If an application needs to support devices from multiple vendors, it typically needs to maintain multiple sets of driver loading and calling logic in the code, or rely on external configuration files to specify the currently used driver, increasing development and maintenance complexity.

[0007] Furthermore, existing solutions generally employ a static binding method, meaning that the application links to a specific vendor's SDK during the compilation or linking phase. This method makes it difficult to automatically adapt to newly inserted devices at runtime, and it also does not support operating multiple U-keys from different vendors simultaneously within the same process.

[0008] In summary, existing technologies lack a management system that can automatically identify manufacturers, dynamically load corresponding drivers, generate globally unique device identifiers, and uniformly route standard SKF interface calls based on device hardware characteristics without user intervention. Summary of the Invention

[0009] To overcome the aforementioned problems in the existing technology, this invention provides a unified national cryptographic interface management system and method based on automatic hardware feature identification, aiming to achieve zero-configuration identification, automatic driver loading, and transparent calling of standard interfaces for national cryptographic UKEY devices from multiple manufacturers.

[0010] On the one hand, the present invention provides a unified national cryptographic interface management system based on automatic identification of hardware features. The system includes a device enumeration module, a driver loading module, a function binding module, a wrapper handle generation module, and an interface routing module.

[0011] The system comprises the following modules: a device enumeration module for obtaining the vendor identifier (VID) and product identifier (PID) of each security device by scanning the hardware bus; a driver loading module for dynamically loading the corresponding vendor driver library based on a pre-set static mapping table and the VID and PID information, wherein the pre-set static mapping table is built into the system during deployment and requires no user configuration; a function binding module for obtaining the addresses of all standard SKF interface functions implemented in the driver library through a dynamic symbol resolution function and constructing a function pointer table; a wrapper handle generation module for creating a wrapper handle containing the real device handle and the function pointer table based on the driver context matched by the VID and PID when a device open request is received from the application layer, and returning the wrapper handle to the application layer; and an interface routing module for receiving the wrapper handle from the application layer, parsing out the real device handle and the corresponding function pointer table, and calling the corresponding vendor's SKF interface function to perform the operation and return the result.

[0012] Furthermore, the device enumeration module is implemented in the following ways: First, initialize the libusb runtime environment; then, traverse all USB devices on the USB bus; next, extract the vendor identifier (VID) and product identifier (PID) from the standard device descriptor of each USB device; finally, match the VID and PID with the preset static mapping table to determine the corresponding vendor driver library path.

[0013] Furthermore, the driver loading module is specifically implemented in the following ways: Call the dlopen function to load the manufacturer's driver library file that matches the VID and PID; if loading is successful, record the handle of the driver library for subsequent symbol resolution.

[0014] Furthermore, the function binding module is implemented in the following ways: For each function name in the standard SKF interface, the dlsym function is called to obtain its function address from the loaded driver library; all obtained function addresses are filled into the function pointer table to form a driver context bound to the device.

[0015] Furthermore, the packaging handle generation module is specifically implemented in the following ways: First, the device opening function in the function pointer table is called, passing in the device identifier parameter, to obtain the real device handle returned by the manufacturer driver; then, an internal structure is created, which contains the real device handle and a pointer to the function pointer table; finally, the address of the structure is returned to the application layer as a unified device handle.

[0016] Furthermore, during the device enumeration process, the system generates a unique device identifier for each device. The unique device identifier adopts a combined naming format of "manufacturer name: device model". The manufacturer name is obtained from the preset static mapping table based on the VID, and the device model is determined based on the PID or a string read from the device firmware to ensure the uniqueness of the device name in the global namespace when multiple manufacturers' devices coexist.

[0017] On the other hand, the present invention also provides a unified national cryptographic interface management method based on automatic identification of hardware features, including the following steps. S1: Scan the hardware bus to obtain the VID and PID of each security device; S2: Dynamically load the corresponding vendor driver library according to the preset static mapping table and the VID and PID information. The preset static mapping table is built into the system during deployment and does not require user configuration. S3: Obtain the addresses of all standard SKF interface functions in the driver library through dynamic symbol resolution, and construct a function pointer table; S4: Upon receiving a device open request from the application layer, based on the driver context corresponding to the VID and PID matching, create a wrapper handle containing the real device handle and the function pointer table, and return the wrapper handle to the application layer; S5: Receive the package handle passed from the application layer, parse out the real device handle and the corresponding function pointer table, and call the corresponding vendor's SKF interface function according to the function pointer table to perform the operation and return the result.

[0018] Further, step S1 specifically includes: S11: Initialize the libusb runtime environment; S12: Traverse all USB devices on the USB bus; S13: Extract the Vendor Identifier (VID) and Product Identifier (PID) from the standard device descriptor of each USB device; S14: Match the VID and PID with the preset static mapping table to determine the corresponding manufacturer driver library path.

[0019] Furthermore, during the device enumeration process, the system generates a unique device identifier for each device. The unique device identifier adopts a combined naming format of "manufacturer name: device model". The manufacturer name is obtained from the preset static mapping table based on the VID, and the device model is determined based on the PID or a string read from the device firmware to ensure the uniqueness of the device name in the global namespace when multiple manufacturers' devices coexist.

[0020] Furthermore, step 5, which involves calling the corresponding vendor's SKF interface function, specifically includes: S51: Convert the unified device handle passed from the application layer into an internal structure pointer; S52: Extract the real device handle and function pointer table from it; S53: Indirectly call the SKF interface functions implemented in the vendor driver through the function pointer table, and pass through the execution result.

[0021] Through the above system and method, the present invention can automatically identify the manufacturer of the inserted UKEY device, dynamically load the corresponding driver, generate a globally unique logical device name, and realize transparent routing from the standard SKF interface to the specific implementation of the manufacturer through the wrapper handle mechanism, thereby supporting plug-and-play and unified management of devices from multiple manufacturers. Attached Figure Description

[0022] Figure 1 This invention drives automatic loading and device enumeration flowchart.

[0023] Figure 2 This invention presents a flowchart of SKF interface call routing based on wrapped handles. Detailed Implementation

[0024] The present invention will now be described in detail with reference to the accompanying drawings and embodiments. Example 1

[0025] This embodiment provides a unified national cryptographic interface management system based on automatic hardware feature identification, deployed on the Linux operating system, to enable plug-and-play and transparent calling of standard SKF interfaces for multi-vendor national cryptographic UKEY devices.

[0026] During system installation, a static mapping table file is integrated into the program resource directory. This mapping table is built into the system during deployment and requires no user configuration. An example of its content is shown below: { "1234:5678": { "vendor": "VendorA", "model": "DeviceX", "lib": " / opt / skf / drivers / driver_a.so" }, "ABCD:9012": { "vendor": "VendorB", "model": "DeviceY", "lib": " / opt / skf / drivers / driver_b.so" } } In this embodiment, the key of the mapping table is a string composed of the device's manufacturer identifier (VID) and product identifier (PID) concatenated in hexadecimal numbers, in the format '{VID}:{PID}' (e.g., '1234:5678'), and the value includes the manufacturer name, device model, and driver library path.

[0027] like Figure 1 As shown, when the application first calls SKF_EnumDev(TRUE, szNameList, &ulSize), the system starts the device enumeration module. This module first calls libusb_init() to initialize the USB access context, and then obtains a list of all connected USB devices.

[0028] For each USB device, the system reads its standard USB device descriptor and extracts the Vendor Identifier (VID) and Product Identifier (PID). For example, a device is detected with VID=0x1234 and PID=0x5678.

[0029] The system uses "1234:5678" as the key to query the mapping table above. If a match is found (such as the entry in the first row), the corresponding driver library path / opt / skf / drivers / driver_a.so is recorded.

[0030] The driver loading module calls dlopen(" / opt / skf / drivers / driver_a.so", RTLD_LAZY) to load the shared library. If a non-null handle is returned, the loading was successful.

[0031] The function binding module then calls dlsym to obtain the entry address in the driver for each SKF function name (such as "SKF_OpenDev", "SKF_RSASignData", etc.) defined in the GM / T 0016-2012 specification, and fills it into an SKF_FUNC_TABLE structure: typedef struct { DEVAPI LONG (*pOpenDev)(LPSTR, DEVHANDLE*); DEVAPI LONG (*pRSASignData)(DEVHANDLE, BYTE*, ULONG, BYTE*,ULONG*); / / ... Other SKF function pointers } SKF_FUNC_TABLE; The system encapsulates this function pointer table, driver library handle, VID / PID and other information into a driver context and stores it in a global hash table (with "VID:PID" as the key).

[0032] At the same time, the system generates a unique logical name for the device: it retrieves vendor="VendorA" and model="DeviceX" from the mapping table and concatenates them into "VendorA:DeviceX".

[0033] If another device (VID=0xABCD, PID=0x9012) is inserted at this time, the system will complete the same process and generate "VendorB:DeviceY".

[0034] Finally, the system iterates through the global driver context hash table, collects all unique device names, populates them into szNameList, and returns them to the application.

[0035] When the application calls SKF_OpenDev(“VendorA:DeviceX”, &hDev), the wrapper handle generation module looks up the corresponding driver context by the device name and calls its pOpenDev function to obtain the real device handle (e.g., real_h = (void*)0x12345678).

[0036] The system creates internal structures in heap memory: typedef struct { void* real_handle; / / Real device handle SKF_FUNC_TABLE* func_tbl; / / Pointer to the function pointer table WrappedDevHandle; Store real_handle and func_tbl, and cast the structure address to type DEVHANDLE, returning it as a unified device handle hDev.

[0037] Subsequently, when the application calls SKF_RSASignData(hDev,pbData,32,pSig, &ulSigLen), the interface routing module interprets hDev as a WrappedDevHandle* pointer, extracts the real handle and function pointer table from it, and calls func_tbl->pRSASignData(real_handle, ...).

[0038] The call jumps directly to the implementation in the corresponding vendor driver, which performs the signature calculation and returns the result to the application.

[0039] This embodiment uses a pre-set static mapping table combined with VID / PID to automatically load the manufacturer's driver library, and uses a wrapper handle to encapsulate the real device handle and function pointer table. This system achieves zero-configuration identification of multi-vendor UKEY devices and transparent calling of the standard SKF interface. At the same time, it generates a globally unique device identifier by using a combination naming method of "vendor name: device model", which effectively avoids name conflict problems when multiple devices coexist. Example 2

[0040] like Figure 2 As shown, this embodiment describes the specific method flow of the system executed in the above embodiment one. Step S201: The application calls SKF_EnumDev(TRUE, szNameList, &ulSize).

[0041] Step S202: The system initializes libusb and scans the USB bus. In this embodiment, two devices are found: Device 1 (VID=0x1234, PID=0x5678) and Device 2 (VID=0xABCD, PID=0x9012).

[0042] Step S203: Query the preset mapping table. Device 1 matches the entry {“vendor”:“VendorA”, “model”:“DeviceX”, “lib”:“driver_a.so”}, and Device 2 matches {“vendor”:“VendorB”, “model”:“DeviceY”, “lib”:“driver_b.so”}.

[0043] Step S204: dlopen was called to load driver_a.so and driver_b.so respectively, and both were successful.

[0044] Step S205: For each driver, call dlsym to bind all SKF interface function addresses and construct two independent function pointer tables.

[0045] Step S206: Store the two driver contexts in the global driver management table.

[0046] Step S207: Generate a unique name "VendorA:DeviceX" for device 1 and "VendorB:DeviceY" for device 2.

[0047] Step S208: Fill these two names into szNameList and return it to the application. Step S209: The application calls SKF_OpenDev(“VendorA:DeviceX”, &hDev).

[0048] Step S210: The system looks up the VendorA driver context in the table by name.

[0049] Step S211: Call its pOpenDev function to obtain the real device handle real_h1.

[0050] Step S212: Create a wrapper structure and store the function pointer table of real_h1 and VendorA.

[0051] Step S213: Return the structure address as hDev. Step S214: The application calls SKF_RSASignData(hDev, data, 32, sig, &len).

[0052] Step S215: The system converts hDev into a pointer to an internal wrapper structure.

[0053] Step S216: Extract the function pointer tables of real_h1 and VendorA.

[0054] Step S217: Call pRSASignData(real_h1, data, 32, sig, &len).

[0055] Step S218: VendorA driver performs the signature and returns the result.

[0056] Step S219: The system passes the result to the application, and the call is complete.

[0057] This method dynamically loads the driver and binds the SKF interface function based on the hardware VID / PID during the device enumeration phase. When the device is opened, it constructs a wrapper structure containing the real handle and function pointer table, and unpacks and routes to the corresponding manufacturer's implementation in subsequent calls. Thus, it supports plug-and-play, unique naming and unified interface access for multi-vendor national cryptographic UKEY devices without user intervention.

[0058] Finally, it should be noted that the above embodiments are only used to illustrate the present invention and are not intended to limit the technical solutions described in the present invention. Therefore, although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the present invention. All technical solutions and improvements that do not depart from the spirit and scope of the present invention should be covered within the scope of the claims of the present invention.

Claims

1. A unified national secret interface management system based on automatic identification of hardware features, characterized in that, The application comprises the following steps: A device enumeration module is used to obtain the VID and PID of each secure device by scanning the hardware bus; A driver loading module is used to dynamically load the corresponding vendor driver library according to the preset static mapping table and the VID and PID information, wherein the preset static mapping table is built in the system at the time of deployment and does not need to be configured by the user; A function binding module is used to obtain the addresses of all standard SKF interface functions implemented in the driver library through dynamic symbol resolution functions, and a function pointer table is constructed; A wrapper handle generation module is used to match the corresponding driver context based on the VID and PID when receiving the device opening request called by the application layer, create a wrapper handle containing the real device handle and the function pointer table, and return the wrapper handle to the application layer; An interface routing module is used to receive the wrapper handle transmitted by the application layer, analyze the real device handle and the corresponding function pointer table, and call the SKF interface functions of the corresponding vendor according to the function pointer table to perform operations and return the results. 2.The system of claim 1, wherein, The device enumeration module is specifically implemented in the following manner: First, the libusb running environment is initialized; then, all USB devices on the USB bus are traversed; then, the VID and PID of each USB device are extracted from the standard device descriptor of the USB device; finally, the VID and PID are matched with the preset static mapping table to determine the path of the corresponding vendor driver library. 3.The system of claim 1, wherein, The driver loading module is specifically implemented in the following manner: The dlopen function is called to load the vendor driver library file matched with the VID and PID; if the loading is successful, the handle of the driver library is recorded for subsequent symbol resolution. 4.The system of claim 1, wherein, The function binding module is specifically implemented in the following manner: For each function name in the standard SKF interface, the dlsym function is called to obtain the function address from the loaded driver library; all obtained function addresses are filled into the function pointer table to form the driver context bound to the device. 5.The system of claim 1, wherein, The wrapper handle generation module is specifically implemented in the following manner: First, the device opening function in the function pointer table is called to pass in the device identification parameter to obtain the real device handle returned by the vendor driver; then, an internal structure body is created, which contains the real device handle and a pointer to the function pointer table; finally, the address of the structure body is returned to the application layer as the unified device handle. 6.The system of claim 1, wherein: In the device enumeration process, the system generates a unique device identification for each device, which adopts the naming format of "vendor name: device model", wherein the vendor name is obtained from the preset static mapping table based on the VID, and the device model is determined based on the PID or the string read from the device firmware, so as to ensure the uniqueness of the device name in the global naming space when multiple vendor devices coexist.

7. A unified national secret interface management method based on automatic identification of hardware features, characterized in that, The application comprises the following steps: S1: Scan the hardware bus to obtain the VID and PID of each secure device; S2: According to the pre-set static mapping table and the VID and PID information, a corresponding manufacturer driver library is dynamically loaded, and the pre-set static mapping table is built-in by the system during deployment and does not need to be configured by the user; S3: The addresses of all standard SKF interface functions in the driver library are obtained through dynamic symbol analysis, and a function pointer table is constructed; S4: When receiving a device opening request from the application layer, a wrapping handle containing the real device handle and the function pointer table is created based on the corresponding driver context matched by the VID and PID, and the wrapping handle is returned to the application layer; S5: The wrapping handle transmitted by the application layer is received, the real device handle and the corresponding function pointer table are parsed, and the SKF interface functions of the corresponding manufacturer are called according to the function pointer table to execute operations and return results.

8. The method of claim 7, wherein, The step S1 is specifically: S11: Initialize the libusb running environment; S12: Traverse all USB devices on the USB bus; S13: Extract the vendor identification VID and product identification PID from the standard device descriptor of each USB device; S14: Match the VID and PID with the pre-set static mapping table to determine the corresponding manufacturer driver library path. 9.The method of claim 7, wherein: During the device enumeration process, the system generates a unique device identification for each device, which adopts the combination naming format of "manufacturer name: device model", wherein the manufacturer name is obtained from the pre-set static mapping table based on the VID, and the device model is determined based on the PID or a string read from the device firmware, to ensure the uniqueness of the device name in the global namespace when multiple manufacturer devices coexist.

10. The method of claim 7, wherein the method further comprises: The step of calling the SKF interface functions of the corresponding manufacturer in step 5 specifically includes: S51: Convert the uniform device handle transmitted by the application layer into an internal structure pointer; S52: Extract the real device handle and the function pointer table therefrom; S53: Indirectly call the SKF interface functions implemented in the manufacturer driver through the function pointer table, and transparently transmit the execution results.

Images