A unified national secret interface management system and method based on automatic recognition of hardware features

Abstract

The application discloses a unified national secret interface management system and method based on automatic identification of hardware features. The system acquires the vendor identification (VID) and product identification (PID) of a security device by scanning a USB bus, dynamically loads a corresponding vendor driver library according to a built-in static mapping table during deployment, and constructs an SKF standard interface function pointer table by using dynamic symbol resolution. A wrapped handle containing the real device handle and the function pointer table is generated when the device is opened, and subsequent interface calls are routed to the specific implementation of the vendor by unpacking the handle. At the same time, a globally unique device identification is generated in the format of "vendor name: device model" to avoid conflicts between device names of multiple vendors. The scheme does not require user configuration, supports plug-and-play and transparent calling of multi-brand UKEYs, and is conducive to improving the compatibility and management efficiency of national secret devices.

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:

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

[0014] Furthermore, the driver loading module is specifically implemented in the following ways:

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

[0016] Furthermore, the function binding module is implemented in the following ways:

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

[0018] Furthermore, the packaging handle generation module is specifically implemented in the following ways:

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

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

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

[0022] S1: Scan the hardware bus to obtain the VID and PID of each security device;

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

[0024] S3: Obtain the addresses of all standard SKF interface functions in the driver library through dynamic symbol resolution, and construct a function pointer table;

[0025] 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;

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

[0027] Further, step S1 specifically includes:

[0028] S11: Initialize the libusb runtime environment;

[0029] S12: Traverse all USB devices on the USB bus;

[0030] S13: Extract the Vendor Identifier (VID) and Product Identifier (PID) from the standard device descriptor of each USB device;

[0031] S14: Match the VID and PID with the preset static mapping table to determine the corresponding manufacturer driver library path.

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

[0033] Furthermore, step 5, which involves calling the corresponding vendor's SKF interface function, specifically includes:

[0034] S51: Convert the unified device handle passed from the application layer into an internal structure pointer;

[0035] S52: Extract the real device handle and function pointer table from it;

[0036] S53: Indirectly call the SKF interface functions implemented in the vendor driver through the function pointer table, and pass through the execution result.

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

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

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

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

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

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

[0043] {

[0044] "1234:5678": {

[0045] "vendor": "VendorA",

[0046] "model": "DeviceX",

[0047] "lib": " / opt / skf / drivers / driver_a.so"

[0048] },

[0049] "ABCD:9012": {

[0050] "vendor": "VendorB",

[0051] "model": "DeviceY",

[0052] "lib": " / opt / skf / drivers / driver_b.so"

[0053] }

[0054] }

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

[0056] like Figure 1As 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.

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

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

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

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

[0061] typedef struct {

[0062] DEVAPI LONG (*pOpenDev)(LPSTR, DEVHANDLE*);

[0063] DEVAPI LONG (*pRSASignData)(DEVHANDLE, BYTE*, ULONG, BYTE*,ULONG*);

[0064] / / ... Other SKF function pointers

[0065] } SKF_FUNC_TABLE;

[0066] 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).

[0067] 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".

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

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

[0070] 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).

[0071] The system creates internal structures in heap memory:

[0072] typedef struct {

[0073] void* real_handle; / / Real device handle

[0074] SKF_FUNC_TABLE* func_tbl; / / Pointer to the function pointer table

[0075] WrappedDevHandle;

[0076] Store real_handle and func_tbl, and cast the structure address to type DEVHANDLE, returning it as a unified device handle hDev.

[0077] 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, ...).

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

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

[0080] like Figure 2 As shown, this embodiment describes the specific method flow of the system execution in Embodiment 1 above.

[0081] Step S201: The application calls SKF_EnumDev(TRUE, szNameList, &ulSize).

[0082] 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).

[0083] 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”}.

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

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

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

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

[0088] Step S208: Fill these two names into szNameList and return it to the application.

[0089] Step S209: The application calls SKF_OpenDev(“VendorA:DeviceX”, &hDev).

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

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

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

[0093] Step S213: Return the structure address as hDev.

[0094] Step S214: The application calls SKF_RSASignData(hDev, data, 32, sig, &len).

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

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

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

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

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

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

[0101] 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 cryptographic interface management system based on automatic hardware feature identification, characterized in that, include: The device enumeration module is used to obtain the vendor identifier (VID) and product identifier (PID) of each security device by scanning the hardware bus. The 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. The preset static mapping table is built into the system during deployment and does not require user configuration. The function binding module is used to obtain the addresses of all standard SKF interface functions implemented in the driver library through a dynamic symbol resolution function, and to construct a function pointer table; The wrapper handle generation module is used to create a wrapper handle containing the real device handle and the function pointer table based on the driver context corresponding to the VID and PID when a device opening request called by the application layer is received, and return the wrapper handle to the application layer. The interface routing module is used to receive the packaged handle passed in 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.

2. The unified national cryptographic interface management system based on automatic hardware feature identification according to claim 1, characterized in that, 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.

3. The unified national cryptographic interface management system based on automatic hardware feature identification according to claim 1, characterized in that, The driver loading module is 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.

4. The unified national cryptographic interface management system based on automatic hardware feature identification according to claim 1, characterized in that, 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.

5. The unified national cryptographic interface management system based on automatic hardware feature identification according to claim 1, characterized in that, The packaging handle generation module is 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.

6. The unified national cryptographic interface management system based on automatic hardware feature identification according to claim 1, characterized in that: 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.

7. A unified national cryptographic interface management method based on automatic hardware feature identification, characterized in that, Includes 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 the dynamic symbol resolution function, 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.

8. The unified national cryptographic interface management method based on automatic hardware feature identification according to claim 7, characterized in that, Step S1 specifically involves: 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.

9. The unified national cryptographic interface management method based on automatic hardware feature identification according to claim 7, characterized in that: 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.

10. The unified national cryptographic interface management method based on automatic hardware feature identification according to claim 7, characterized in that, The step of calling the corresponding manufacturer's SKF interface function in step 5 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.

Images