A compliance detection method and system for an intelligent password key identity authentication process

Abstract

The application relates to a compliance detection method and system of an intelligent password key identity authentication process, and belongs to the technical field of information security, which solves the problems of static evidence corroboration and intrusive detection in the prior art. The method comprises the following steps: capturing the communication flow of a target Ukey on a USB bus in a bypass mode, analyzing the communication flow according to an APDU format, recombining the obtained APDU data into structured APDU data according to time, comparing each piece of structured APDU data with a standard APDU instruction to perform compliance verification, and determining that the Ukey is truly called to communicate if the verification is passed; after the structured APDU data that pass the verification are mapped into functions, a Ukey function call chain is formed, the Ukey function call chain is compared with an identity authentication process in a target scheme to perform compliance determination of the identity authentication process, and a compliance output result is determined. The application realizes non-intrusive, full-automatic and multi-standard flexible configuration supporting detection.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and in particular to a compliance testing method and system for a smart password key identity authentication process. Background Technology

[0002] A smart cryptographic key (hereinafter referred to as a Ukey) is a hardware-based high-security identity authentication device widely used in e-government, online banking, and enterprise internal authentication scenarios. Ukeys are used to store digital certificates, perform identity authentication, and implement digital signatures; the security of their use directly affects the overall security level of the information system. In commercial cryptography application security assessments (cryptographic evaluations) and various compliance tests, verifying whether the application system genuinely and compliantly uses Ukeys for identity authentication is a crucial step in assessing information security levels.

[0003] Currently, compliance testing for the Ukey identity authentication process mainly employs the following methods: Static evidence corroboration: Testing personnel require the tested party to provide static materials such as source code screenshots, log files, and API call records, and manually verify whether there is evidence of calling the Ukey. This method has the following drawbacks: there is a risk of forged evidence; it is impossible to confirm whether the screenshots or logs are consistent with the actual operating environment; it relies on manual review, which is inefficient and highly subjective; and it cannot verify whether the hardware is actually involved in the communication.

[0004] Intrusive detection: This method records Ukey call behavior by modifying the application, instrumenting drivers, or adding logs at the driver layer. This approach has the following drawbacks: it is highly invasive, potentially affecting business continuity and system stability; it is complex to implement, requiring vendor cooperation to modify code or drivers; and it is difficult to deploy in a real production environment. Summary of the Invention

[0005] Based on the above analysis, the embodiments of the present invention aim to provide a compliance detection method and system for the smart password key identity authentication process, so as to solve the problems in the prior art.

[0006] On one hand, embodiments of the present invention provide a compliance detection method for a smart password key authentication process, including: Real-time capture of communication traffic of the target Ukey on the USB bus in bypass mode; The communication traffic of the target Ukey is parsed according to the APDU format to obtain APDU data. The APDU data is then reassembled into structured APDU data according to time to form a structured APDU data list. Each structured APDU data in the structured APDU data list is compared with the standard APDU instructions in the standard APDU instruction library to verify the compliance of the actual call. If the verification passes, it is determined that the Ukey is being used for communication. After the structured APDU data that has passed compliance verification is functionally mapped, a Ukey function call chain is formed. The Ukey function call chain is compared with the identity authentication process in the target solution to determine the compliance of the identity authentication process. If the identity authentication process is determined to be compliant, the process compliance verification result is output.

[0007] Furthermore, the communication traffic of the target Ukey on the USB bus is captured in real time in a bypass mode, including: Capture all data packets on the USB bus in real time using bypass mode; Based on the USB bus number to which the target Ukey is connected and the device number of the target Ukey, filter out the communication traffic of the target Ukey from the full data packet; USB data is obtained from the communication traffic of the target Ukey. The USB data includes timestamps, transfer types, endpoint addresses, data payloads, and USB device descriptor metadata. The USB data is then encapsulated.

[0008] Furthermore, the communication traffic of the target Ukey is parsed according to the APDU format to obtain APDU data. The APDU data is then reassembled into structured APDU data according to time, forming a structured APDU data list, including: The USB data is filtered according to the transmission type to obtain USB data with the transmission type of bulk transmission; The transmission direction of the batch-transmitted USB data is determined based on the endpoint address; The parsing route is determined based on the USB device descriptor metadata. The data payload in each batch of USB data is parsed based on the transmission direction and the parsing path. Based on the parsing result, it is determined whether the data payload belongs to a command request APDU or a response request APDU. The corresponding command request APDU and response request APDU are paired into a transaction, and APDU data is obtained. When it belongs to a command request APDU, the corresponding timestamp is determined as the sending timestamp, and the instruction category CLA, instruction code INS, instruction parameter P1, instruction parameter P2, and request data field are extracted from the corresponding APDU data according to the APDU format. When it belongs to a response request APDU, the corresponding timestamp is determined as the receiving timestamp, and the response data field, status word SW1, and status word SW2 are extracted from the corresponding APDU data according to the APDU format. Each transaction constitutes a structured APDU data record, which records the sending timestamp, receiving timestamp, instruction type CLA, instruction code INS, instruction parameter P1, instruction parameter P2, request data field, response data field, status word SW1, and status word SW2. Arrange multiple structured APDU data in ascending order according to their sending timestamps to obtain a list of structured APDU data containing multiple structured APDU data.

[0009] Further, determining the resolution route based on the USB device descriptor metadata includes: When the USB device descriptor metadata is 0x08, it is determined to be a USM resolution path; when the USB device descriptor metadata is other data, the USB data in the batch transmission is discarded.

[0010] Further, based on the transmission direction and the parsing path, the data payload in each batch of transmitted USB data is parsed. Based on the parsing result, it is determined whether the data payload belongs to a command request APDU or a response request APDU, and the corresponding command request APDU and response request APDU are paired into a transaction, including: When the USM resolution path is used, the data payload is determined to be either a command request APDU or a response request APDU based on the signature identifier of the first 4 bytes of the data payload and the transmission direction. Based on the label field of CBW in the data payload corresponding to the command request APDU and the label field of CSW in the data payload corresponding to the response request APDU, the corresponding command request APDU and response request APDU are paired into a transaction.

[0011] Furthermore, the standard APDU instructions in the standard APDU instruction library include the expected instruction category CLA, the expected instruction code INS, the expected instruction parameter P1, the expected instruction parameter P2, the expected request length, and the expected response length; Each structured APDU in the structured APDU data list is compared with the standard APDU instructions in the standard APDU instruction library to verify compliance with actual calls. If the verification passes, it is determined that the communication is actually using the Ukey, including: Each structured APDU data is checked against the standard APDU instructions in the standard APDU instruction library for instruction format, parameter range, and data field structure. If all checks pass, it is determined that the Ukey is actually being used for communication.

[0012] Furthermore, the instruction format verification includes: Determine whether the instruction class (CLA) and instruction code (INS) in each structured APDU data can match the expected instruction class (CLA) and expected instruction code (INS) included in the standard APDU instruction; The parameter range verification includes: Determine whether the values ​​of instruction parameter P1 and instruction parameter P2 in each structured APDU data are within the preset range of expected instruction parameter P1 and expected instruction parameter P2; The data field structure verification includes: Determine whether the value of the data length field in the request data field and response data field of each structured APDU data is equal to the expected request length and expected response length.

[0013] Furthermore, the standard APDU instructions in the standard APDU instruction library also include function names that correspond one-to-one with the expected instruction category CLA, expected instruction code INS, expected instruction parameter P1, and expected instruction parameter P2; After the structured APDU data that has passed compliance verification is functionally mapped, a Ukey function call chain is formed, including: The instruction category CLA, instruction code INS, instruction parameter P1, and instruction parameter P2 of each structured APDU data that has passed compliance verification are matched with the expected instruction category CLA, expected instruction code INS, expected instruction parameter P1, and expected instruction parameter P2 of the standard APDU instruction in the standard APDU instruction library. After all matches are completed, the corresponding function name is mapped to the function name of the structured APDU data that has passed compliance verification. A structured APDU data that has passed compliance verification corresponds to a calling node. The calling nodes are chained together in ascending order of sending timestamp to form a Ukey function calling chain. Each Ukey function calling chain includes multiple calling nodes. Each calling node includes a function name, sending timestamp, receiving timestamp, instruction category CLA, instruction code INS, instruction parameter P1, instruction parameter P2, status word SW1, and status word SW2.

[0014] Furthermore, the compliance of the identity authentication process is determined by comparing the Ukey function call chain with the identity authentication process in the target solution, including: Each Ukey function call chain is compared with the identity authentication process in the target solution to verify the integrity of the core steps, the correctness of the execution order, and the operation. The operation check includes checking for abnormal or redundant operations. The core step integrity verification includes: for each core step in the identity authentication process in the target scheme, searching in the Ukey function call chain for a node that matches the function name, instruction category CLA, instruction code INS, instruction parameter P1, and instruction parameter P2, and the status word SW1 and status word SW2 of that node are combined to form 9000. The execution order correctness verification includes: setting the pointer to initially point to step 1 of the identity authentication process in the target scheme; matching each node in the Ukey function call chain with each step in the identity authentication process in the target scheme whose sequence number is incremented; traversing the nodes in the Ukey function call chain; and determining whether the sequence number corresponding to the step of the node is less than the current position of the pointer. The abnormal operation check includes: determining whether the function name of each node in the Ukey function call chain is in the identity authentication process of the target scheme; The redundancy check includes: counting the number of identical function nodes in the Ukey function call chain, determining whether the identical function is a non-reusable function set in the identity authentication process of the target solution and the number exceeds a preset number, or counting whether the number of nodes in the Ukey function call chain exceeds the number of steps in the target solution.

[0015] On the other hand, embodiments of the present invention provide a compliance detection system for a smart password key identity authentication process, comprising: The data acquisition module is used to capture the communication traffic of the target Ukey on the USB bus in real time in a bypass mode; The data parsing module is used to parse the communication traffic of the target Ukey according to the APDU format, obtain APDU data, and reassemble the APDU data into structured APDU data according to time to form a structured APDU data list. The protocol conformance verification module is used to compare each structured APDU data in the structured APDU data list with the standard APDU instructions in the standard APDU instruction library to verify the compliance of the actual call. If the verification passes, it is determined that the communication is actually called using the Ukey. The identity authentication process verification module is used to map the structured APDU data that has passed compliance verification into a Ukey function call chain, compare the Ukey function call chain with the identity authentication process in the target solution to determine the compliance of the identity authentication process, and output the process compliance verification result if the identity authentication process is determined to be compliant.

[0016] Compared with the prior art, the present invention can achieve at least the following beneficial effects: This invention verifies whether an application has actually communicated physically with the Ukey through USB bus bypass acquisition and APDU protocol consistency verification, effectively identifying hardware call bypass risks. Simultaneously, by constructing a function call chain and comparing it with a dynamically configurable identity authentication process library, it automatically determines the completeness and correctness of the identity authentication process steps, accurately locating missing or erroneous steps. The entire detection process is based on bypass acquisition using the operating system's underlying USB bus monitoring interface, requiring no application modification, driver instrumentation, or hardware vendor cooperation, achieving non-intrusive detection with no impact on business systems. Furthermore, the identity authentication process library supports flexible switching between national standards, industry specifications, and custom processes, meeting diverse compliance testing needs. Finally, the fully automated processing from data acquisition, data parsing, protocol comparison to process determination significantly shortens the detection cycle, reduces manual intervention, and significantly improves the objectivity and authority of the test results.

[0017] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description

[0018] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts. Figure 1 A schematic diagram of a compliance detection method for a smart password key identity authentication process provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of a data acquisition process provided in an embodiment of the present invention; Figure 3 A schematic diagram of a data parsing process provided in an embodiment of the present invention; Figure 4 A schematic diagram of a protocol consistency verification process provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of an identity authentication process verification procedure provided in an embodiment of the present invention. Detailed Implementation

[0019] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.

[0020] Based on the problems existing in the prior art, this invention collects hardware communication data in a non-intrusive manner, extracts APDU (Application Protocol Data Unit) instruction sequences, first verifies protocol consistency to confirm the actual hardware call, and then automatically determines the integrity and compliance of the identity authentication process by comparing the sequence with a dynamically configurable identity authentication process library. Finally, it realizes fully automated detection from data collection to compliance determination, effectively solving the problems of lack of verification of actual call, difficulty in automatically verifying process compliance, and single detection standards in the prior art.

[0021] A specific embodiment of the present invention discloses a compliance detection method for a smart password key identity authentication process, such as... Figure 1 As shown, the method includes: S110: Captures the communication traffic of the target Ukey on the USB bus in real time in bypass mode.

[0022] In specific implementation, such as Figure 2 As shown, S110 specifically includes: S210: Captures all data packets on the USB bus in real time in bypass mode.

[0023] Specifically, the bypass (non-intrusive listening technology) listens to the USB bus and captures all data packets on the USB bus in real time. Each full data packet contains a USB pseudo header (including bus number, device number, endpoint address, transfer type, timestamp, USB device (i.e., Ukey) descriptor metadata (including interface class byte bInterfaceClass)) and a data payload.

[0024] This can be achieved using a hardware bypass device. A typical alternative is to use a dedicated USB protocol analyzer or a customized USB traffic mirroring hub. This device is physically connected in series between the host and the Ukey, directly mirroring and capturing communication data at the hardware link layer. This approach is completely independent of the host operating system and software environment, providing another, more versatile, and non-intrusive data acquisition implementation path that does not rely on specific APIs.

[0025] The USB device descriptor metadata is reported to the host by the USB device during the enumeration phase, and it includes the bInterfaceClass field.

[0026] The endpoint address is reported to the host by the USB device during the enumeration phase. The endpoint address is an 8-bit (1-byte) field used to uniquely identify a specific endpoint on the USB device. On a computer, the Ukey is typically recognized as a USB Mass Storage Class (UMS) device. Communication between the host and the Ukey strictly follows the SCSI (Small Computer System Interface) standard, usually using only bulk transfers. Therefore, it occupies two endpoints: an OUT endpoint (the host sends CBW (Command Block Wrapper) and APDU (Application Protocol Data Unit) data to the USB device) and an IN endpoint (the USB device sends back CSW (Command Status Wrapper) and response data to the host). Assuming endpoint number 1 is assigned as the OUT endpoint, its endpoint address is 0x01. Assuming endpoint number 2 is assigned as the IN endpoint, its endpoint address is 0x82.

[0027] The transfer type defines the mechanism, timing, and reliability requirements for data transfer between the host and the device. In the UMS protocol, bulk transfer is primarily used. Therefore, this invention specifies the transfer type as bulk transfer.

[0028] The data payload consists of the remaining payload bytes after removing the USB header from the USB packet during the USB bulk transfer phase. The data payload includes UMS protocol data packets. For UMS mode Ukeys, the UMS protocol data packets for the host → device direction (OUT endpoint) include CBW (31 bytes, encapsulating SCSI commands), and the UMS protocol data packets for the device → host direction (IN endpoint) include CSW (13 bytes, encapsulating SCSI status responses). The APDU body is transmitted as an independent bulk data packet in the data phase corresponding to CBW (the payload is TPDU frame header + APDU, where TPDU stands for Transport Protocol Data Unit).

[0029] CBW: The first 4 bytes are the signature 0x55534243 ("USBC"), followed by the tag field (4 bytes, used for pairing with CSW), data transfer length, transfer direction flag, LUN and SCSI command block length, and the last 16 bytes are the SCSI command block (CBWCB) – this command block is the SCSI instruction. The SCSI command block encapsulates APDU data. According to the UMS extended specification, the 0th byte of the SCSI command block (CBWCB) is the custom command code 0xFE, the 1st byte is the sub-command code (0x01 indicates that the device sends an APDU command in the OUT data phase, 0x02 indicates that the device returns an APDU response in the IN data phase), and bytes 2-10 are the magic number "GMCAPIDFS".

[0030] CSW: The first 4 bytes are the signature 0x55534253 ("USBS"), the next 9 bytes are the tag paired with CBW (4 bytes, used for pairing with CBW) and the 5-byte status word - i.e., the SCSI response.

[0031] S220: Based on the USB bus number to which the target Ukey is connected and the device number of the target Ukey, filter out the communication traffic of the target Ukey from the full data packet.

[0032] Specifically, precise filtering is performed based on the bus number and device number of the Ukey, retaining only the communication traffic of the target Ukey.

[0033] S230: Obtain USB data from the communication traffic of the target Ukey. The USB data includes timestamp, transmission type, endpoint address, data payload, and USB device descriptor metadata. Encapsulate the USB data.

[0034] Specifically, the bus number and device number of the Ukey are removed, and only the timestamp, transfer type, endpoint address, and data payload are recorded, along with the USB device descriptor metadata (including bInterfaceClass). The records are structured USB data with fields {timestamp, endpoint address, transfer type, data payload, bInterfaceClass}.

[0035] Multiple timestamps correspond to multiple data payloads. The data payloads are arranged in ascending order of timestamps to obtain a time series. The APDU list is then reorganized according to this time order.

[0036] This solution achieves non-intrusive real-time collection of Ukey communication data without modifying application code, instrumenting drivers, or interrupting business operations.

[0037] S120: Parse the communication traffic of the target Ukey according to the APDU format to obtain APDU data, and reassemble the APDU data into structured APDU data according to time to form a structured APDU data list.

[0038] This step performs multi-layer protocol stripping. First, UMS protocol packets are identified, and SCSI commands and responses are located by parsing the CBW and CSW structures. Then, encapsulated APDU data is extracted from the SCSI command payload. Finally, the extracted APDU data is reassembled into a structured data list according to time series.

[0039] In specific implementation, such as Figure 3 As shown, S120 specifically includes: S310: Filter the USB data according to the transmission type to obtain USB data with the transmission type of bulk transmission.

[0040] Specifically, because the Ukey's data packet type is bulk transfer, the transfer type is used as the filtering basis. USB data is filtered according to the transfer type, filtering out non-bulk transfer packets and retaining bulk transfer packets.

[0041] S320: Determine the transmission direction of the bulk USB data based on the endpoint address.

[0042] Specifically, the endpoint address serves as an auxiliary verification, and its direction bits (OUT / IN) help identify the data flow direction and verify the consistency of the pairing between CBW and CSW.

[0043] S330: Determine the parsing route based on the USB device descriptor metadata, parse the data payload in each batch of USB data based on the transmission direction and the parsing path, determine whether the data payload belongs to a command request APDU or a response request APDU based on the parsing result, pair the corresponding command request APDU and response request APDU into a transaction, and obtain APDU data at the same time.

[0044] Specifically, the bInterfaceClass field of the USB device descriptor metadata is read for transport mode routing: when bInterfaceClass=0x08 (mass storage class), the UMS resolution path is followed; if it is another value (neither UMS nor CCID), the data is discarded and no APDU resolution is performed.

[0045] UMS parsing path: First, read the first 4 bytes of the data payload to determine its signature: USBC signature identifier CBW (Command Block Encapsulation), USBS signature identifier CSW (Status Encapsulation). CBW and CSW are paired according to their respective tag fields in bytes 4-7 to represent the same transaction (the UMS protocol stipulates that the tag of the CSW must be equal to the tag of the corresponding CBW). The CBWCB (SCSI Command Block) of the CBW is fixed at 16 bytes: the data stage is located by 0xFE + magic number "GMCAPIDFS" + subcommand code, and the APDU request and response are extracted after stripping the 3-byte TPDU frame header from the data stage payload.

[0046] Then, when it is a command request APDU, the corresponding timestamp is determined as the sending timestamp, and the APDU command header and request data field are extracted from the corresponding APDU data according to the APDU format. The APDU command header includes the instruction class (CLA), instruction code (INS), instruction parameter P1, and instruction parameter P2. The extraction of the request data field depends on the Lc (command data length) field. According to the length indicated by Lc, the corresponding bytes are truncated from the command header and Lc field to obtain the request data field. When it is a response request APDU, the corresponding timestamp is determined as the receiving timestamp, and the response data field, status word SW1, and status word SW2 are extracted from the corresponding APDU data according to the APDU format.

[0047] Each transaction constitutes a structured APDU data record, recording the send timestamp, receive timestamp, command type (CLA), command code (INS), command parameter P1, command parameter P2, request data field, response data field, status word SW1, and status word SW2 (SW1 and SW2 together form SW). For example, a VerifyPIN transaction record might be: {send time T1, receive time T2, {CLA, INS, P1, P2} = 80 18 00 00, request data = [8-byte PIN], SW = 90 00}, indicating that the VerifyPIN command was sent at time T1 and a successful response of 90 00 was received at time T2.

[0048] S340: Arrange multiple structured APDU data in ascending order according to the sending timestamp to obtain a list of structured APDU data including multiple structured APDU data.

[0049] S130: Compare each structured APDU data in the structured APDU data list with the standard APDU instructions in the standard APDU instruction library to verify the compliance of the actual call. If the verification passes, it is determined that the Ukey is being used for communication.

[0050] In practical implementation, a standard APDU instruction library is pre-built based on the GM / T 0017 standard, and stored in the form of a mapping table of command header quadruple {CLA,INS,P1,P2} → function name. An example is shown below: {0x80,0x18,0x00,0x00} → SKF_VerifyPIN (Verify PIN); {0x80,0x26,0x00,0x00} → SKF_OpenApplication opens the application; {0x80,0x10,0x00,0x00} → SKF_DevAuth device authentication; {0x80,0x74,0x02,0x00} → SKF_ECCSignData ECC signature; {0x80,0x50,0x00,0x00} → SKF_GenRandom generates random numbers; {0x80,0x04,0x00,0x00} → SKF_GetDevInfo retrieves device information.

[0051] The instruction library also includes the expected request length and expected response length for each instruction—the expected request length is the length of the message data field in the request APDU (the APDU request message data for some functions is fixed and must be explicitly specified), and the expected response length is the length of the message data field in the response APDU (the APDU response message data for some functions is fixed and must be explicitly specified). Both are used to verify whether the actual data field length is consistent with the expectation when verifying protocol consistency.

[0052] In some embodiments, such as Figure 4 As shown, S130 specifically includes: Each structured APDU data is verified against the standard APDU instructions in the standard APDU instruction library in terms of instruction format, parameter range, and data field structure (three dimensions). If all verifications pass, it is determined that the Ukey is actually being used for communication. The instruction format verification includes: Determine whether the instruction class (CLA) and instruction code (INS) in each structured APDU data can match the expected instruction class (CLA) and expected instruction code (INS) included in the standard APDU instruction; The parameter range verification includes: Determine whether the values ​​of instruction parameter P1 and instruction parameter P2 in each structured APDU data are within the preset range of expected instruction parameter P1 and expected instruction parameter P2; The data field structure verification includes: Determine whether the value of the data length field in the request data field and response data field of each structured APDU data is equal to the expected request length and expected response length.

[0053] Specifically, the value of the Lc field is checked to be equal to the actual data length in the format of "length (Lc)-value (data)" (Note: APDU data fields use Lc-value format, not label-length-value format).

[0054] Let's take the PIN verification command (VerifyPIN) as an example: 1. Command Category (look at the first two bytes of the command header: CLA and INS): CLA tells the device the category of the command, and INS tells the device which specific command it is. The category must be valid, and the command must be defined by the standard. In this structured APDU data, {CLA, INS, P1, P2} is 80 18 00 00. CLA=0x80 is valid, and INS=0x18 is a defined PIN verification command, so it passes. In this structured APDU data, {CLA, INS, P1, P2} is 88 10 02 00. CLA=0x88 has its reserved bit set to 1, indicating an abnormal command. In this structured APDU data, {CLA, INS, P1, P2} is 00 2A 00 00. INS=0x2A is not defined by the standard, indicating an unrecognized command.

[0055] II. Parameter Range (see the last two bytes P1 and P2 of the command header): The parameter values ​​for each instruction are fixed. When verifying a PIN, P1 is always 0, and P2 is either 0x00 (administrator) or 0x01 (user). If {CLA, INS, P1, P2} is 80 18 00 00, then P2=0x00 in this structured APDU data indicates administrator verification, which is within the range and passes. If {CLA, INS, P1, P2} is 8018 00 05, then P2=0x05 in this structured APDU data is outside the range of {0x00, 0x01}, indicating a parameter out-of-bounds error.

[0056] III. Data Field Structure (Refer to the data carried afterward, in the format "Length (Lc) - Value (data), No Tag"): The length must match the actual number of bytes in the password. The PIN code length is verified to be 0x12. In this structured APDU data, the request data field is 00 00 12 [18-byte PIN] – the length 0x12 matches the following 18 bytes, so it passes. In this structured APDU data, the request data field is 00 00 12 [8-byte PIN] – the length 0x12 does not match the actual 8 bytes, indicating a data field structure mismatch. This verifies whether the value of the length field is equal to the data length.

[0057] If all three dimensions pass, the structured APDU data is deemed compliant; if any fails, it is deemed non-compliant, and the reason for failure is recorded. Only when all structured APDU data passes verification is it confirmed that the application has actually called the Ukey hardware, and verification is output as successful. If any non-compliance rule exists, it is determined as "hardware call bypass risk," verification is output as failed, and the process does not proceed to the subsequent identity verification process.

[0058] S140: After mapping the structured APDU data that has passed compliance verification to form a Ukey function call chain, compare the Ukey function call chain with the identity authentication process in the target solution to determine the compliance of the identity authentication process. If the identity authentication process is determined to be compliant, output the process compliance verification result.

[0059] In some embodiments, such as Figure 5 As shown, the structured APDU data that has passed compliance verification is mapped to functions to form a Ukey function call chain, including: For each structured APDU data that has passed compliance verification, the instruction category (CLA), instruction code (INS), instruction parameter (P1), and instruction parameter (P2) are matched with the expected instruction category (CLA), expected instruction code (INS), expected instruction parameter (P1), and expected instruction parameter (P2) of the standard APDU instruction in the standard APDU instruction library. After all matches are found, the corresponding function name is mapped to the function name of the structured APDU data that has passed compliance verification. If there is no match (i.e., the command header {CLA, INS, P1, P2} is not in the mapping table), it is directly discarded and does not enter the call chain.

[0060] A structured APDU data that has passed compliance verification corresponds to a calling node. The calling nodes are chained together in ascending order of sending timestamp to form a Ukey function calling chain. Each Ukey function calling chain includes multiple calling nodes. Each calling node includes a function name, sending timestamp, receiving timestamp, instruction category CLA, instruction code INS, instruction parameter P1, instruction parameter P2, status word SW1, and status word SW2 (SW1 and SW2 constitute SW).

[0061] In practical implementation, the identity authentication process library pre-configures multiple solutions corresponding to different authentication standards or on-site customized needs. These solutions are determined based on standards such as GBT 15843 or specific on-site requirements. Each solution in the identity authentication process library has a solution number and an applicable authentication standard / scenario label, which can be manually selected by the user. The sequence of steps in the solution is used as the comparison benchmark. Dynamic switching of authentication solutions is supported to meet diverse compliance testing needs.

[0062] In some embodiments, such as Figure 5As shown, the compliance of the identity authentication process is determined by comparing the Ukey function call chain with the identity authentication process in the target solution, including: Each Ukey function call chain is compared with the identity authentication process in the target solution to verify the integrity of the core steps, the correctness of the execution order, and the operation. The operation check includes checking for abnormal or redundant operations. The core step integrity verification includes: for each core step in the identity authentication process of the target solution, searching the Ukey function call chain for a node that matches the function name, instruction category (CLA), instruction code (INS), instruction parameter (P1), and instruction parameter (P2), and whose status word (SW1) and status word (SW2) combination equals 9000. Specifically, using the function name and command header of the core step in the target solution, a matching node is searched in the call chain. After finding a matching node, it is checked whether the node's SW = 9000. If there is no matching item for the function name and command header of any core step, or if SW ≠ 9000, the step is judged as missing / failed → the process is incomplete. Example: The solution requires device authentication and PIN verification as core steps; if the actual chain has no PIN verification node → PIN verification is missing → incomplete.

[0063] The execution order correctness verification includes: setting the pointer to initially point to step 1 of the identity authentication process in the target scheme; matching each node in the Ukey function call chain with each step in the identity authentication process of the target scheme whose sequence number is incremented; traversing the nodes in the Ukey function call chain; and determining whether the sequence number of the step corresponding to the node is less than the current position of the pointer. Specifically, verifying whether the order of the Ukey function call chain conforms to the sequence number of the scheme steps. Maintaining the pointer to traverse the Ukey function call chain, each node must match the current or subsequent allowed steps of the pointer; if a match is found, it moves forward; if the sequence number of the matched step is less than the position already traversed by the pointer (in reverse order) or occurs in an unallowed stage, the order is judged to be incorrect. Repeated reusable steps are not considered to violate the order. Example: Ukey function call chain = [Open application (80 26) → Open container (80 42) → Sign (80 74) → Close container (80 44)], the sequence number of the target scheme is 1 Open application → 2 Open container → 3 Sign → 4 Close container. The pointer p is initially set to point to step 1 of the scheme. The Ukey function call chain is traversed: the first node (open application) matches step 1, p moves forward to step 2; the second node (open container) matches step 2, p moves forward to step 3; the third node (signature) matches step 3, p moves forward to step 4; the fourth node (close container) matches step 4, p moves forward to step 5. The node numbers increment throughout, and the order is correct. If the Ukey function call chain is [open application → open container → sign → close container], and the second node (open container) matches step 4, but p has only reached step 2, the sequence number of step 4 is greater than p's current position, indicating an out-of-order occurrence, and the order is considered incorrect.

[0064] The abnormal operation check includes determining whether the function name of each node in the Ukey function call chain is present in the identity authentication process of the target solution. Specifically, an anomaly occurs when the command header of a node in the Ukey function call chain does not match any step sequence in the target solution. For example, a container deletion may occur in the Ukey function call chain, but it is not present in the target solution.

[0065] The redundancy check includes: counting the number of identical function nodes in the Ukey function call chain, determining whether the identical function is a non-reusable function set in the identity authentication process of the target solution and the number exceeds a preset number, or counting whether the number of nodes in the Ukey function call chain exceeds the number of steps in the target solution. Specifically, redundancy means that the actual number of steps in the Ukey function call chain exceeds the expected number of steps in the target solution, or the number of times the non-reusable core steps in the Ukey function call chain are executed exceeds the number allowed by the target solution. For example: PIN verification is performed 3 times consecutively in the Ukey function call chain, but the target solution only allows 1 time → redundancy.

[0066] Passing all three checks indicates that the identity authentication process is compliant; failing any one check indicates that the identity authentication process is non-compliant, thereby achieving automated auditing of compliance from the underlying hardware communication behavior to the upper-layer business logic.

[0067] The following example uses a complete digital signature scheme, with the target process as follows: Step 1: Initialize SKF_DigestInit with hash, {CLA,INS,P1,P2} is 80 B4 00 01. This is the core step. Step 2: Hash operation SKF_Digest, {CLA,INS,P1,P2} is 80 B6 00 00. Core step; Step 3: Open the application SKF_OpenApplication, {CLA,INS,P1,P2} is 80 26 00 00 Non-core step / reusable step; Step 4: Open the container SKF_OpenContainer, {CLA,INS,P1,P2} is 80 42 00 00. Core step; Step 5: Generate random numbers SKF_GenRandom, {CLA,INS,P1,P2} are 80 50 00 00. This is a non-core / reusable step. Step 6: Sign SKF_ECCSignData, {CLA,INS,P1,P2} is 80 74 02 00. Core step; Step 7: Close the container SKF_CloseContainer, {CLA,INS,P1,P2} is 80 44 00 00. Core step; Step 8: Close the application SKF_CloseApplication, {CLA,INS,P1,P2} is 80 28 00 00 Non-core step / reusable step; Expected number of steps = 8.

[0068] The following operations are performed using the method of the present invention: First, data acquisition is performed: USB packets related to this authentication are captured on the USB bus and structured USB data records (timestamp, endpoint address, transfer type, data payload, bInterfaceClass=0x08) are output.

[0069] Then, data parsing is performed: bInterfaceClass=0x08→UMS; CBW and CSW are paired into 8 transactions according to the tag field; the data stage is located from the SCSI command block according to 0xFE + "GMCAPIDFS" + subcommand code; the 3-byte TPDU frame header is stripped to extract the APDU. 8 transaction records are output: Transaction 1: Send T1=10:00:00.001, Receive T2=10:00:00.003, Command Header 80 B4 00 01, Request Data Field=[Algorithm Parameters], Response Data Field=None, SW=90 00; Transaction 2: Send T1=10:00:00.010, Receive T2=10:00:00.012, Command Header 80 B6 00 00, Request Data Field=[Message Data], Response Data Field=[Hash Value], SW=90 00; Transaction 3: Send T1=10:00:00.020, Receive T2=10:00:00.022, Command Header 80 26 00 00, Request Data Field=[Application Name], Response Data Field=[Application ID + Application Attribute], SW=90 00; Transaction 4: Send T1=10:00:00.030, Receive T2=10:00:00.032, Command Header 80 42 00 00, Request Data Field=[Container ID + Container Name], Response Data Field=[Container ID], SW=90 00; Transaction 5: Send T1=10:00:00.040, Receive T2=10:00:00.042, Command Header 80 50 00 00, Request Data Field=None, Response Data Field=[Random Number], SW=90 00; Transaction 6: Send T1=10:00:00.050, Receive T2=10:00:00.052, Command Header 80 74 02 00, Request Data Field=[Application ID + Container ID + 32B SM3 Digest], Response Data Field=[64B SM2 Signature R‖S], SW=90 00; Transaction 7: Send T1=10:00:00.060, Receive T2=10:00:00.062, Command Header 80 44 00 00, Request Data Field=[Application ID+Container ID], Response Data Field=None, SW=90 00; Transaction 8: Send T1=10:00:00.070, Receive T2=10:00:00.072, Command Header 80 28 00 00, Request Data Field=[Application ID], Response Data Field=None, SW=90 00; Then, protocol consistency verification is performed (taking transaction 2 hash operation as an example): Command category – CLA=0x80 valid, INS=0Xb6 defined → Pass; Parameter range—P1=0x00, P2=0x00 are within the fixed values ​​of this instruction → pass; Data field structure – length (Lc)-value (data) format, Lc is consistent with the actual message data length → passed; Summary: Transaction 2 is compliant. If all 8 conditions are compliant, the application is confirmed to be genuinely calling the Ukey hardware, and the process proceeds to the identity authentication verification step. If any condition is non-compliant, the process is judged as "hardware call bypass risk," and the identity authentication verification step is not initiated.

[0070] Then proceed with the identity verification process: Identification—80 B4 00 01 → Hash initialization (Transaction 1), 80 B6 00 00 → Hash operation (Transaction 2), 80 26 00 00 → Open application (Transaction 3), 80 42 00 00 → Open container (Transaction 4), 80 50 00 00 → Generate random number (Transaction 5), 80 74 02 00 → ECC signature (Transaction 6), 80 44 00 00 → Close container (Transaction 7), 80 28 0000 → Close application (Transaction 8); Chaining (in ascending order of sending timestamp) — [Hash Initialization (T1=…001,SW=9000)] → [Hash Calculation (T1=…010,SW=9000)] → [Open Application (T1=…020,SW=9000)] → [Open Container (T1=…030,SW=9000)] → [Generate Random Number (T1=…040,SW=9000)] → [ECC Signature (T1=…050,SW=9000)] → [Close Container (T1=…060,SW=9000)] → [Close Application (T1=…070,SW=9000)]; Three checks – Completeness: All five core steps of the target process (hash initialization / hash operation / open container / signature / close container) appear in the chain and SW=9000 → Pass; Order correctness: The chain order is consistent with the target process sequence number 1→2→3→4→5→6→7→8 → Pass; Abnormality / redundancy: The actual number of steps in the chain is 8 ≤ the expected number of steps is 8, the chain does not contain any functions not included in the target process, and there is no excessive duplication → Pass; Output: All three verifications pass → Chain-based identity authentication process is compliant -> Passes inspection.

[0071] Counterexample (non-compliant): Change the response of the hash operation of Transaction 2 to SW=67 00 (length error). Transaction 2 is still considered compliant in the protocol consistency verification and enters the integrity verification. Although the core step "hash operation" in the chain appears, SW≠9000 → it is judged as "hash operation execution failed". Finally, the comprehensive judgment is: integrity fails → hash operation process is non-compliant, deviation location = "hash operation execution failed (SW=6700, length error)".

[0072] Compared with existing technologies, the compliance detection method for the smart password key authentication process provided in this embodiment can achieve the following beneficial effects: 1) Enhanced Authenticity Verification Capability: Addressing the shortcomings of "static evidence"—such as the risk of forgery and the inability to verify actual hardware communication—this invention collects real communication data via USB bus bypass and verifies it based on APDU protocol consistency. This method of obtaining evidence from the underlying physical communication layer can definitively verify whether the application has actually interacted with the Ukey hardware, effectively identifying fraudulent behaviors such as "hardware call bypass," and ensuring the objectivity and authenticity of the detection results.

[0073] 2) Non-intrusive and Unaffected Detection Process: Addressing the drawbacks of invasive detection methods, such as significant impact on business system stability and complex implementation, this invention utilizes a bypass acquisition method based on the operating system's underlying USB bus monitoring interface. This approach requires no modification to application code, no instrumentation of drivers, and no cooperation from hardware vendors, achieving completely non-intrusive detection. This ensures the continuity and stability of the tested business system while significantly reducing deployment and implementation costs.

[0074] 3) Significantly Enhanced Automation and Flexibility: Addressing the issues of low efficiency, high subjectivity, and limited testing standards associated with existing technologies that rely on manual review, this invention automates the entire process from data collection to compliance determination by constructing a function call chain and performing automatic sequence comparison with a dynamically configurable identity authentication process library. Simultaneously, the process library supports flexible switching between national standards, industry specifications, and custom solutions, meeting diverse compliance testing needs, significantly shortening the testing cycle, and enhancing the authority of the test results.

[0075] One specific embodiment of the present invention discloses a compliance detection system for a smart password key identity authentication process, comprising: The data acquisition module is used to capture the communication traffic of the target Ukey on the USB bus in real time in a bypass mode; The data parsing module is used to parse the communication traffic of the target Ukey according to the APDU format, obtain APDU data, and reassemble the APDU data into structured APDU data according to time to form a structured APDU data list. The protocol conformance verification module is used to compare each structured APDU data in the structured APDU data list with the standard APDU instructions in the standard APDU instruction library to verify the compliance of the actual call. If the verification passes, it is determined that the communication is actually called using the Ukey. The identity authentication process verification module is used to map the structured APDU data that has passed compliance verification into a Ukey function call chain, compare the Ukey function call chain with the identity authentication process in the target solution to determine the compliance of the identity authentication process, and output the process compliance verification result if the identity authentication process is determined to be compliant.

[0076] The above-described method and system embodiments are based on the same principles, and their related aspects can be referenced from each other to achieve the same technical effects. For specific implementation processes, please refer to the foregoing embodiments, which will not be repeated here.

[0077] Electronic device example: One specific implementation of this application discloses an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps of the compliance detection method for the smart password key authentication process in the method embodiment.

[0078] Examples of readable storage media: One specific implementation of this application discloses a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the compliance detection method for the smart password key identity authentication process in the method embodiment.

[0079] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0080] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A compliance testing method for a smart password key identity authentication process, characterized in that, include: Real-time capture of communication traffic of the target Ukey on the USB bus in bypass mode; The communication traffic of the target Ukey is parsed according to the APDU format to obtain APDU data. The APDU data is then reassembled into structured APDU data according to time to form a structured APDU data list. Each structured APDU data in the structured APDU data list is compared with the standard APDU instructions in the standard APDU instruction library to verify the compliance of the actual call. If the verification passes, it is determined that the Ukey is being used for communication. After the structured APDU data that has passed compliance verification is functionally mapped, a Ukey function call chain is formed. The Ukey function call chain is compared with the identity authentication process in the target solution to determine the compliance of the identity authentication process. If the identity authentication process is determined to be compliant, the process compliance verification result is output.

2. The compliance detection method for the smart password key identity authentication process according to claim 1, characterized in that, Real-time capture of communication traffic of the target Ukey on the USB bus in bypass mode, including: Capture all data packets on the USB bus in real time using bypass mode; Based on the USB bus number to which the target Ukey is connected and the device number of the target Ukey, filter out the communication traffic of the target Ukey from the full data packet; USB data is obtained from the communication traffic of the target Ukey. The USB data includes timestamps, transfer types, endpoint addresses, data payloads, and USB device descriptor metadata. The USB data is then encapsulated.

3. The compliance detection method for the smart password key identity authentication process according to claim 2, characterized in that, The communication traffic of the target Ukey is parsed according to the APDU format to obtain APDU data. The APDU data is then reassembled into structured APDU data according to time, forming a structured APDU data list, including: The USB data is filtered according to the transmission type to obtain USB data with the transmission type of bulk transmission; The transmission direction of the batch-transmitted USB data is determined based on the endpoint address; The parsing route is determined based on the USB device descriptor metadata. The data payload in each batch of USB data is parsed based on the transmission direction and the parsing path. Based on the parsing result, it is determined whether the data payload belongs to a command request APDU or a response request APDU. The corresponding command request APDU and response request APDU are paired into a transaction, and APDU data is obtained. When it belongs to a command request APDU, the corresponding timestamp is determined as the sending timestamp, and the instruction category CLA, instruction code INS, instruction parameter P1, instruction parameter P2, and request data field are extracted from the corresponding APDU data according to the APDU format. When it belongs to a response request APDU, the corresponding timestamp is determined as the receiving timestamp, and the response data field, status word SW1, and status word SW2 are extracted from the corresponding APDU data according to the APDU format. Each transaction constitutes a structured APDU data record, which records the sending timestamp, receiving timestamp, instruction type CLA, instruction code INS, instruction parameter P1, instruction parameter P2, request data field, response data field, status word SW1, and status word SW2. Arrange multiple structured APDU data in ascending order according to their sending timestamps to obtain a list of structured APDU data containing multiple structured APDU data.

4. The compliance detection method for the smart password key identity authentication process according to claim 3, characterized in that, Determining the resolution route based on the USB device descriptor metadata includes: When the USB device descriptor metadata is 0x08, it is determined to be a USM resolution path; when the USB device descriptor metadata is other data, the USB data in the batch transmission is discarded.

5. The compliance detection method for the smart password key identity authentication process according to claim 4, characterized in that, Based on the transmission direction and the parsing path, the data payload in each batch of transmitted USB data is parsed. Based on the parsing result, it is determined whether the data payload belongs to a command request APDU or a response request APDU. The corresponding command request APDU and response request APDU are paired into a transaction, including: When the USM resolution path is used, the data payload is determined to be either a command request APDU or a response request APDU based on the signature identifier of the first 4 bytes of the data payload and the transmission direction. Based on the label field of CBW in the data payload corresponding to the command request APDU and the label field of CSW in the data payload corresponding to the response request APDU, the corresponding command request APDU and response request APDU are paired into a transaction.

6. The compliance detection method for the smart password key identity authentication process according to claim 3, characterized in that, The standard APDU instruction library includes the expected instruction category CLA, expected instruction code INS, expected instruction parameter P1, expected instruction parameter P2, expected request length, and expected response length. Each structured APDU in the structured APDU data list is compared with the standard APDU instructions in the standard APDU instruction library to verify compliance with actual calls. If the verification passes, it is determined that the communication is actually using the Ukey, including: Each structured APDU data is checked against the standard APDU instructions in the standard APDU instruction library for instruction format, parameter range, and data field structure. If all checks pass, it is determined that the Ukey is actually being used for communication.

7. The compliance detection method for the smart password key identity authentication process according to claim 6, characterized in that, The instruction format verification includes: Determine whether the instruction class (CLA) and instruction code (INS) in each structured APDU data can match the expected instruction class (CLA) and expected instruction code (INS) included in the standard APDU instruction; The parameter range verification includes: Determine whether the values ​​of instruction parameter P1 and instruction parameter P2 in each structured APDU data are within the preset range of expected instruction parameter P1 and expected instruction parameter P2; The data field structure verification includes: Determine whether the value of the data length field in the request data field and response data field of each structured APDU data is equal to the expected request length and expected response length.

8. The compliance detection method for the smart password key identity authentication process according to claim 7, characterized in that, The standard APDU instruction library also includes function names that correspond one-to-one with the expected instruction category CLA, expected instruction code INS, expected instruction parameter P1, and expected instruction parameter P2. After the structured APDU data that has passed compliance verification is functionally mapped, a Ukey function call chain is formed, including: The instruction category CLA, instruction code INS, instruction parameter P1, and instruction parameter P2 of each structured APDU data that has passed compliance verification are matched with the expected instruction category CLA, expected instruction code INS, expected instruction parameter P1, and expected instruction parameter P2 of the standard APDU instruction in the standard APDU instruction library. After all matches are completed, the corresponding function name is mapped to the function name of the structured APDU data that has passed compliance verification. A structured APDU data that has passed compliance verification corresponds to a calling node. The calling nodes are chained together in ascending order of sending timestamp to form a Ukey function calling chain. Each Ukey function calling chain includes multiple calling nodes. Each calling node includes a function name, sending timestamp, receiving timestamp, instruction category CLA, instruction code INS, instruction parameter P1, instruction parameter P2, status word SW1, and status word SW2.

9. The compliance detection method for the smart password key identity authentication process according to claim 8, characterized in that, The compliance of the identity authentication process is determined by comparing the Ukey function call chain with the identity authentication process in the target solution, including: Each Ukey function call chain is compared with the identity authentication process in the target solution to verify the integrity of the core steps, the correctness of the execution order, and the operation. The operation check includes checking for abnormal or redundant operations. The core step integrity verification includes: for each core step in the identity authentication process in the target scheme, searching in the Ukey function call chain for a node that matches the function name, instruction category CLA, instruction code INS, instruction parameter P1, and instruction parameter P2, and the status word SW1 and status word SW2 of that node are combined to form 9000. The execution order correctness verification includes: setting the pointer to initially point to step 1 of the identity authentication process in the target scheme; matching each node in the Ukey function call chain with each step in the identity authentication process in the target scheme whose sequence number is incremented; traversing the nodes in the Ukey function call chain; and determining whether the sequence number corresponding to the step of the node is less than the current position of the pointer. The abnormal operation check includes: determining whether the function name of each node in the Ukey function call chain is in the identity authentication process of the target scheme; The redundancy check includes: counting the number of identical function nodes in the Ukey function call chain, determining whether the identical function is a non-reusable function set in the identity authentication process of the target solution and the number exceeds a preset number, or counting whether the number of nodes in the Ukey function call chain exceeds the number of steps in the target solution.

10. A compliance detection system for an intelligent password key identity authentication process, characterized in that, include: The data acquisition module is used to capture the communication traffic of the target Ukey on the USB bus in real time in a bypass mode; The data parsing module is used to parse the communication traffic of the target Ukey according to the APDU format, obtain APDU data, and reassemble the APDU data into structured APDU data according to time to form a structured APDU data list. The protocol conformance verification module is used to compare each structured APDU data in the structured APDU data list with the standard APDU instructions in the standard APDU instruction library to verify the compliance of the actual call. If the verification passes, it is determined that the communication is actually called using the Ukey. The identity authentication process verification module is used to map the structured APDU data that has passed compliance verification into a Ukey function call chain, compare the Ukey function call chain with the identity authentication process in the target solution to determine the compliance of the identity authentication process, and output the process compliance verification result if the identity authentication process is determined to be compliant.

Images