Test method, device, system and electronic equipment of trusted cryptographic module chip

Abstract

The application discloses a test method, device and system of a trusted cryptographic module chip and electronic equipment, and belongs to the field of trusted computing. The method comprises the following steps: sending a test command to the trusted cryptographic module chip and receiving response data, extracting a status code therefrom, and determining whether the status code is an expected success status code in the case where the status code is valid; if the status code is not an expected success status code, extracting bit data of a predetermined bit width in the status code to determine an error code format corresponding to the status code; determining an error category based on the error code format and the values of different preset bit positions in the status code; selecting a corresponding error code dictionary according to the error code format and the error category to query error information corresponding to the status code therefrom; and outputting the error information to indicate the test failure reason of the test command. The application realizes automatic analysis of the status code based on the bit position rule, avoids manual bit-by-bit interpretation of the status code, and thus improves the accuracy of test failure reason positioning and the test efficiency.

Description

Technical Field

[0001] This application belongs to the field of trusted computing technology, and in particular relates to a testing method, apparatus, system and electronic device for a trusted cryptographic module chip. Background Technology

[0002] Trusted Cryptography Modules (TCMs), as crucial security chips supporting national cryptographic algorithms and trusted computing systems, are widely used in power, finance, government affairs, and industrial control scenarios. With the continuous evolution of TCM specifications (such as TCM 2.0), TCMs are becoming increasingly rich in command types, status code encoding rules, and communication methods, placing higher demands on the accuracy, versatility, and efficiency of the testing process.

[0003] During testing, trusted cryptographic modules typically return command execution results in the form of a four-byte status code. This status code is formed by combining multiple bits, with different bits representing the error code format, error source, and specific error cause. Most existing testing platforms only display the numerical form of the status code, requiring testers to parse it bit by bit according to the specifications. This parsing process is highly dependent on human experience, inefficient, and prone to errors. For complex error codes involving parameters, handles, or sessions, existing solutions struggle to provide comprehensive coverage and lack effective automated parsing and location capabilities. Summary of the Invention

[0004] This application aims to address at least one of the technical problems existing in the prior art. To this end, this application proposes a testing method, apparatus, system, and electronic device for a trusted cryptographic module chip, to achieve automated parsing of status codes based on bit-based rules.

[0005] Firstly, this application provides a testing method for a trusted cryptographic module chip, the method comprising: Send a test command to the trusted cryptographic module chip and receive the response data returned by the trusted cryptographic module chip; Extract the status code from the response data, and determine whether the status code is the expected success status code if the status code is valid. In the case that the status code is an unexpected success status code, extract the bit data of a predetermined width from the status code, and determine the error code format corresponding to the status code based on the bit data of the predetermined width. Based on the error code format and the values ​​of different preset bits in the status code, the error category corresponding to the status code is determined; Based on the error code format and the error category, select the corresponding error code dictionary and query the error information corresponding to the status code from the error code dictionary; Output the error message to indicate the reason for the test command's failure.

[0006] Secondly, this application provides a testing device for a trusted cryptographic module chip, the device being equipped with an error parsing module, including: The transceiver unit is used to send test commands to the trusted cryptographic module chip and receive response data returned by the trusted cryptographic module chip. The result determination unit is used to extract a status code from the response data and determine whether the status code is an expected success status code if the status code is valid. An error parsing unit is used to extract a predetermined bit width of bit data from the status code when the status code is an unexpected success status code, and to determine the error code format corresponding to the status code based on the predetermined bit width of bit data. The error parsing unit is also used to determine the error category corresponding to the status code based on the error code format and the values ​​of different preset bits in the status code; The error parsing unit is further configured to select the corresponding error code dictionary according to the error code format and the error category, and query the error information corresponding to the status code from the error code dictionary; The output unit is also used to output the error information to indicate the reason for the test failure of the test command.

[0007] Thirdly, this application provides a testing system for a trusted cryptographic module chip, the system comprising: Trusted cryptographic module chip; A communication interface device is used as a data interaction interface between the test terminal and the trusted cryptographic module chip during the test process, so as to realize the sending of test commands and the receiving of response data. A test terminal is used to test the trusted cryptographic module chip and is configured to execute the test parsing method for the trusted cryptographic module as described in the first aspect above.

[0008] Fourthly, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the testing method for the trusted cryptographic module chip as described in the first aspect above.

[0009] Fifthly, this application provides a non-transitory computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the test method for the trusted cryptographic module chip as described in the first aspect above.

[0010] Sixthly, this application provides a chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the testing method for the trusted cryptographic module chip as described in the first aspect.

[0011] In a seventh aspect, this application provides a computer program product, including a computer program that, when executed by a processor, implements the testing method for the trusted cryptographic module chip as described in the first aspect above.

[0012] The above-described one or more technical solutions in the embodiments of this application have at least one of the following technical effects: By sending test commands to the trusted cryptographic module chip and receiving its response data, the testing process is directly based on the chip's actual execution results, thus ensuring the authenticity and reliability of the test conclusions. By extracting status codes from the response data and determining whether a valid status code is an expected success code, the testing process can automatically separate success and failure scenarios, avoiding unnecessary subsequent parsing of successful execution results and improving overall testing efficiency. Specifically, in the case of an unexpected success status code, by extracting a predetermined width of bit data from the status code and determining the error code format based on this bit data, status code parsing is established on a standardized bit-level rule basis, avoiding judgment based solely on numerical comparison or human experience, thereby improving the consistency and accuracy of error parsing. Furthermore, based on the error code format and the values ​​of different preset bits in the status code, the error category is determined, enabling the testing system to distinguish errors of different sources and natures, narrowing the scope of problem localization and improving the targeting of fault analysis. Based on this, the corresponding error code dictionary is selected according to the determined error code format and error category, and the error information corresponding to the status code is queried from the error code dictionary. The complex status code parsing process is transformed into a structured and reusable query process, reducing the complexity of test implementation and improving parsing efficiency. Finally, the error information is output to indicate the reason for the test command failure, so that the test results can be presented in a clear and readable form, reducing the need for manual interpretation of status codes bit by bit, thereby improving the accuracy and automation level of error location in the trusted cryptographic module chip testing process as a whole.

[0013] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0014] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1 This is one of the schematic diagrams of the framework of the test system for the trusted cryptographic module chip provided in the embodiments of this application; Figure 2 This is a flowchart illustrating the testing method for the trusted cryptographic module chip provided in this application embodiment; Figure 3 This is a second schematic diagram of the framework of the test system for the trusted cryptographic module chip provided in the embodiments of this application; Figure 4 This is the third schematic diagram of the framework of the test system for the trusted cryptographic module chip provided in the embodiments of this application; Figure 5 This is a schematic diagram of the testing process for the trusted cryptographic module chip provided in the embodiments of this application; Figure 6 This is a schematic diagram of the structure of the test device for the trusted cryptographic module chip provided in the embodiments of this application; Figure 7 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0015] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0016] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0017] Existing testing schemes for trusted cryptographic modules still have several shortcomings. First, they suffer from the problems of low efficiency and high dependence on human experience, as mentioned above. In real-world scenarios, testers need to manually consult the ErrCode (Error Code) sections of the specification to parse error names and locate faults, resulting in low testing efficiency and a high reliance on the operator's expertise. While some platforms have attempted to solidify the mapping relationships of common error codes, this only applies to single error value scenarios. For complex error codes involving multiple bits such as parameter handles and sessions, existing schemes cannot provide comprehensive coverage and require a significant amount of manual coding work.

[0018] Secondly, as trusted cryptographic modules are deployed in various application scenarios, the types of communication protocols used by different chips or different COS (Chip Operating System) are constantly increasing. Existing test projects are typically developed for a single communication protocol (such as SPI (Serial Peripheral Interface) protocol), with test scripts highly coupled to the communication implementation, making it difficult to reuse them across different communication protocols. For example, a test platform based on the SPI protocol cannot be used to debug simulator communication. When the communication protocol changes, it is necessary to repeatedly modify or redevelop the communication library, resulting in high maintenance costs for test scripts, a high risk of omissions, and a limited applicability of the test platform.

[0019] Furthermore, random number generation is a crucial testing component of trusted cryptographic modules, and related tests typically require generating random number files of sufficient size to meet testing qualification requirements. Due to differences in chip internal buffers and COS configurations, different trusted cryptographic modules exhibit variations in the length of a single random number acquisition. Existing random number testing methods often employ fixed-length loop acquisition or manual script adaptation. When changing COS or chip models, repeated manual verification and script modification are necessary, resulting in low testing efficiency and insufficient automation in the testing process.

[0020] In view of this, this application proposes a testing method, apparatus, system, and electronic device for a trusted cryptographic module chip. By sending standard test commands to the trusted cryptographic module and processing the returned response data, the method automatically extracts and assigns return parameters when the command execution is successful. When the command execution fails, the method automatically parses the error information based on the bit rules of the status code and maps it into a readable error name, thereby improving the accuracy and efficiency of locating the cause of test failures and assisting in development and repair. Simultaneously, by introducing a communication protocol encapsulation mechanism, the method achieves flexible adaptation of the same test project to different communication protocols and different COS environments, reducing the maintenance cost of test scripts. Furthermore, by optimizing the random number acquisition process, the test script can automatically adapt to the random number acquisition capabilities under the current COS, obtaining random number data that meets the test requirements in the fastest way, thereby significantly improving the overall efficiency and intelligence level of trusted cryptographic module testing.

[0021] It should be noted that the testing of the trusted cryptography module is not a single or small-scale verification, but a high-frequency, batch-based, and strongly compliant engineering test. Its application scenarios have clear and specific requirements for testing efficiency, which are reflected in the following aspects: First, during the R&D, mass production, and delivery phases of trusted cryptographic modules, testing typically spans multiple stages, including chip debugging, functional verification, version regression testing, compatibility verification, and third-party testing. Each stage involves the repetitive execution of numerous test commands and the parsing of status codes. If the testing process relies on manual parsing of status codes or manual switching of test scripts, the testing cycle will increase linearly with chip version iterations and the number of test items, making it difficult to meet the demands for rapid iteration and delivery during the R&D and mass production phases.

[0022] Secondly, in critical infrastructure applications such as power and finance, trusted cryptographic modules typically need to pass rigorous type testing, network access testing, or qualification certification. These tests often require completing a large number of functional tests and random number generation tasks within a limited timeframe. Random number generation, in particular, requires generating a large sample of random numbers for statistical verification. Low efficiency in obtaining random numbers will directly extend the testing cycle, impacting product access and project deployment progress.

[0023] Furthermore, in real-world engineering environments, trusted cryptographic modules often need to support multiple communication protocols and different COS environments. The same test platform requires frequent switching between the tested objects and execution of the complete test process. Insufficient testing efficiency will significantly increase the operational burden and labor costs for testers, and is also prone to introducing errors during repeated manual configuration, affecting the stability and consistency of test results.

[0024] Therefore, in the aforementioned application scenarios with high frequency, batch processing, and strong timeliness requirements, testing efficiency not only affects the testing experience but also directly relates to the development progress, certification cycle, and engineering implementation efficiency of the trusted cryptographic module. This is also an important reason why this application emphasizes high efficiency and automation in its testing methods and system design.

[0025] Against this backdrop, there is an urgent need for a trusted cryptographic module testing solution that can adapt to the requirements of the above application scenarios, so as to improve the overall testing efficiency and automation level while ensuring the accuracy of testing.

[0026] Therefore, the testing method, apparatus, system and electronic equipment for trusted cryptographic module chips provided in this application embodiment can be applied to application scenarios such as R&D debugging, mass production testing, type testing, network access testing, qualification certification and on-site maintenance of trusted cryptographic module chips. They are especially suitable for application environments with high requirements for testing efficiency and automation of cryptographic devices, such as power, finance, government affairs and industrial control.

[0027] The following description, in conjunction with the accompanying drawings, details the testing methods, apparatus, system, and electronic equipment for the trusted cryptographic module chip provided in this application, through specific embodiments and application scenarios.

[0028] Figure 1 This is one of the schematic diagrams of the framework of the test system for the trusted cryptographic module chip provided in the embodiments of this application. The test method for the trusted cryptographic module chip provided in the embodiments of this application can be applied to, for example... Figure 1 The test system shown.

[0029] The testing system includes a test terminal 101, a communication interface device 102, and a trusted cryptographic module chip (TCM) 103. The test terminal 101 is used to execute test programs and control the test process. The communication interface device 102 is used to establish a communication link between the test terminal 101 and the trusted cryptographic module chip 103. The trusted cryptographic module chip 103 is used to receive test commands and return corresponding response data.

[0030] The test terminal 101 includes, but is not limited to, personal computers, industrial control computers, servers, portable test equipment, or other electronic devices with data processing and communication capabilities.

[0031] The communication interface device 102 can be implemented as a card reader, used to send test commands and receive response data between the test terminal 101 and the trusted cryptographic module chip 103. However, it should be understood that this application is not limited to this. In other embodiments, the communication interface device 102 can also be implemented as a direct connection port, a bus interface, an adapter module, or other communication methods, as long as it can realize data interaction between the test terminal 101 and the trusted cryptographic module chip 103, it falls within the protection scope of this application.

[0032] The trusted cryptographic module chip 103 includes, but is not limited to, security chips conforming to the TCM 2.0 specification, embedded trusted cryptographic modules, trusted cryptographic modules in the form of smart cards, or other cryptographic chips that integrate national cryptographic algorithms and have trusted computing functions.

[0033] Based on the framework of the test system, the test terminal 101 sends a test command to the trusted cryptographic module chip 103 through the communication interface device 102 and receives the response data returned by the trusted cryptographic module chip 103. Then, it processes and parses the status code and related information in the response data to complete the test of the trusted cryptographic module chip 103.

[0034] In some embodiments, the test terminal 101 is configured with a communication library. The communication library is used to encapsulate the test commands with a communication protocol without changing the content of the test commands, and to parse the received response data according to the protocol, so as to adapt to the communication protocol adopted by the communication interface device 102 and / or the trusted cryptographic module chip 103, thereby enabling the same test terminal to be applicable to test requirements under different communication protocol environments.

[0035] In some embodiments, the test terminal 101 is further configured to, when performing random number-related tests, send a random number acquisition request exceeding the expected length to the trusted cryptographic module chip 103 to determine the maximum length of a single random number acquisition supported by the trusted cryptographic module chip 103, and complete the random number test based on the maximum length, thereby improving the execution efficiency of the random number test process.

[0036] Based on the above-described test system structure and application scenarios, the test method for the trusted cryptographic module chip provided in this application embodiment will be further explained below in conjunction with specific procedures.

[0037] The following describes the testing method for the trusted cryptographic module chip provided in this application embodiment, using a test terminal as the execution subject.

[0038] Figure 2 This is a flowchart illustrating the testing method for the trusted cryptographic module chip provided in an embodiment of this application. Figure 2As shown, the testing method for the trusted cryptographic module chip includes steps 210 to 260.

[0039] Step 210: Send a test command to the trusted cryptographic module chip and receive the response data returned by the trusted cryptographic module chip.

[0040] The test command refers to a function call instruction conforming to the trusted cryptographic module specification, used to trigger the trusted cryptographic module chip to perform corresponding cryptographic operations, status queries, or functional tests. The response data refers to the data result returned by the trusted cryptographic module chip after executing the test command. The response data includes at least a status code indicating the command execution result and may further include return parameters corresponding to the test command.

[0041] In this step, the test terminal generates the corresponding test command according to the preset test process and sends the test command to the trusted cryptographic module chip through the communication interface device. After receiving the test command, the trusted cryptographic module chip performs the corresponding processing according to the test command and encapsulates the execution result into response data and returns it to the test terminal. The test terminal caches the received response data for subsequent status code judgment and parsing processing.

[0042] In some embodiments, the test terminal can build test programs based on the Python language at the software level and develop and debug them in the PyCharm integrated development environment. Leveraging the development efficiency of Python and the debugging, unit testing, and runtime monitoring capabilities provided by PyCharm, testers can quickly iterate and update test scripts, protocol encapsulation logic, and status code parsing logic, thereby conveniently completing the verification and maintenance of the test process under different versions of trusted cryptographic module chips or different test cases.

[0043] During the specific testing process, the test terminal sends test commands to the trusted cryptographic module and receives response data. When the status code in the response data indicates that the execution has failed, the test program automatically parses the status code and outputs the parsed error information in a readable name format. This allows testers to obtain a clear reason for failure without having to manually interpret the error code bit by bit according to the specification, thereby improving the efficiency of error location and shortening the testing and debugging cycle.

[0044] Step 220: Extract the status code from the response data, and if the status code is valid, determine whether the status code is the expected success status code.

[0045] In this step, after receiving the response data returned by the trusted cryptographic module chip, the test terminal parses the response data according to the preset data frame format and extracts the status code field from it.

[0046] Among them, the status code refers to the code value returned by the trusted cryptographic module chip in the response data after executing the test command, which is used to characterize the result of the command execution, indicating whether the test command was executed successfully and the corresponding error status when it failed.

[0047] When a complete status code field can be correctly parsed from the response data according to the preset response data structure rules, and the status code field meets the preset length and format requirements, it indicates that the status code is valid and can be used for subsequent judgment and parsing.

[0048] After confirming the validity of the status code, the test terminal compares the status code with the expected success status code pre-configured for the current test command. If they match, the test command is determined to have been executed successfully and the subsequent return parameter processing flow is entered. If they do not match, the test command is determined to have failed and the subsequent error code format determination and error message parsing flow is entered.

[0049] The expected success status code refers to the status code value predefined in the specification or test case corresponding to the current test command, which is used to characterize the successful execution of the command.

[0050] For example, if the status code parsed from the response data is "00000000", and the status code field length is 4 bytes and its position conforms to the definition of the response data structure in the Trusted Cryptography Module Specification, then this status code is a valid status code. Furthermore, if the expected success status code for a test command is predefined as "00000000", then when the parsed status code is "00000000", it can be determined that this status code is not only valid but also an expected success status code. If the parsed status code is "00000011", which also meets the length and format requirements, then this status code is still a valid status code, but not an expected success status code, and needs to proceed to the subsequent error code parsing process.

[0051] Step 230: If the status code is an unexpected success status code, extract the bit data of a predetermined width from the status code, and determine the error code format corresponding to the status code based on the bit data of the predetermined width.

[0052] Among them, the pre-defined bit width bit data refers to the bit field extracted from the status code according to the pre-agreed bit width range for error parsing. This bit field is used to reflect the encoding structure and format of the error code, and different error code formats correspond to different subsequent parsing rules.

[0053] The test terminal extracts a predetermined width of bit data from the status code and uses this bit data as the basis for error code format determination. Based on the value of at least one preset bit in the predetermined width of bit data, the test terminal performs format determination on the status code to determine the error code format corresponding to the status code, thereby providing a parsing path for subsequent error category determination and error information query based on different error code formats.

[0054] Step 240: Determine the error category corresponding to the status code based on the error code format and the values ​​of different preset bits in the status code.

[0055] Among them, the error category refers to the classification result used to characterize the error source and nature corresponding to the status code. Different error categories correspond to different error information query rules and output content.

[0056] Different preset bits refer to the bits that are pre-selected in the pre-width bit data of the status code and used to distinguish error categories according to the trusted cryptographic module specification.

[0057] In this step, the test terminal selects the corresponding error category determination rule based on the error code format and reads the values ​​of different preset bits in the status code corresponding to the determination rule. Then, the test terminal determines the error category of the status code based on the values ​​of the different preset bits. For example, when the status code belongs to the first error code format, the test terminal determines the error category as either a specification-compatible error or a non-specification-compatible error based on the value of the second preset bit; when the status code belongs to the second error code format, the test terminal determines the error category as either a parameter error, session error, or handle error based on the value of the third preset bit. This provides a classification basis for subsequently selecting the corresponding error code dictionary and querying error information.

[0058] Step 250: Select the corresponding error code dictionary according to the error code format and error category, and query the error information corresponding to the status code from the error code dictionary.

[0059] An error code dictionary is a pre-established error code mapping data structure used to record the correspondence between error code data and error information. Different error code dictionaries correspond to different error code formats or error categories, so that the same status code parsing process can call the matching mapping relationship for querying under different parsing paths.

[0060] Error messages are readable content that includes at least the error name. Furthermore, error messages may also include an error category identifier to indicate the type of error originating from.

[0061] Error information refers to readable error content corresponding to the status code, obtained from an error code dictionary, used to characterize the reason for test failure. Error information includes at least the error code name, and may further include one or more of the following: error code format, error category, error category identifier indicating the type of error source, and other auxiliary prompts.

[0062] For example, in this application embodiment, three sets of dictionaries can be pre-established according to the error warning content in the specification. The three sets of dictionaries are named ErrCode0, ErrCode1, and Warning according to the error code format and type, respectively, recording the error code value and error name for the three types. In the dictionary, the "key" is the binary value string of the err part of the error data; the return code of format 0 has 7 bits of data, and the return code of format 1 has 6 bits of data. The "value" is the error code name corresponding to the err content.

[0063] The test terminal selects an error code dictionary that matches the error code format and error category according to the pre-configured correspondence, extracts the bit data for querying from the pre-defined bit width of the status code, and converts the bit data into the key-value index required for dictionary lookup, so as to retrieve the error information corresponding to the status code in the selected error code dictionary.

[0064] For example, when the error code format is format 0, the test terminal selects ErrCode0 or Warning as the target dictionary; when the error code format is format 1, the test terminal selects ErrCode1 as the target dictionary. Subsequently, the test terminal extracts the err portion of the error data from the status code and converts it into a binary numerical string. The test terminal determines the length of the bit data used for querying based on the error code format: 7 bits for format 0 and 6 bits for format 1. The resulting binary numerical string is then used as a key to match and query the target dictionary to obtain the error code name corresponding to the status code, thus forming the error message for subsequent output.

[0065] By using an error code dictionary maintained by error code format and error category, the test terminal can quickly map the bit-level parsed results into readable error information, reducing the need for manual bit-by-bit parsing according to the specification.

[0066] Step 260: Output error messages to indicate the reason for the test command's failure.

[0067] The test terminal presents or records error information in a preset format, enabling testers or upper-level test programs to directly obtain the reasons for test command failures.

[0068] In one implementation, the test terminal displays error information in the test interface or console log so that testers can directly view the cause of the failure.

[0069] In another implementation, the test terminal writes the error information into a test report file or log file and stores it in association with the corresponding test command identifier, execution time, and status code value for subsequent traceability analysis and problem localization.

[0070] In another implementation, the test terminal can also output error information as a return value to the upper-level test script or automated test framework, enabling the automated test framework to perform processing such as alarm reporting, test case marking, or failure reason statistics based on the error information, thereby improving the automation level of the test process and the efficiency of fault location.

[0071] According to the testing method for the trusted cryptographic module chip provided in this application embodiment, by sending a test command to the trusted cryptographic module chip and receiving its returned response data, the testing process is directly based on the chip's actual execution results, thereby ensuring the authenticity and reliability of the test conclusions. By extracting status codes from the response data and determining whether a valid status code is an expected success status code, the testing process can automatically separate into success and failure scenarios, avoiding unnecessary subsequent parsing processing of successful execution results and improving overall testing efficiency. Specifically, in the case of an unexpected success status code, by extracting a predetermined bit width of bit data from the status code and determining the error code format based on this bit data, the status code parsing is established on the basis of standardized bit-level rules, avoiding judgment based solely on numerical comparison or human experience, thereby improving the consistency and accuracy of error parsing. Furthermore, based on the error code format and the values ​​of different preset bits in the status code, the error category is determined, enabling the testing system to distinguish errors of different sources and natures, narrowing the scope of problem localization, and improving the pertinence of fault analysis. Based on this, the corresponding error code dictionary is selected according to the determined error code format and error category, and the error information corresponding to the status code is queried from the error code dictionary. The complex status code parsing process is transformed into a structured and reusable query process, reducing the complexity of test implementation and improving parsing efficiency. Finally, the error information is output to indicate the reason for the test command failure, so that the test results can be presented in a clear and readable form, reducing the need for manual interpretation of status codes bit by bit, thereby improving the accuracy and automation level of error location in the trusted cryptographic module chip testing process as a whole.

[0072] In some embodiments, extracting a predetermined width of bit data from the status code includes: extracting the lower preset width bit data of the status code. The lower preset width bit data is the lower 12 bits of the status code. The test terminal converts the lower 12 bits of data into a binary string and records it. All subsequent error parsing and judgment are based on this binary string.

[0073] Accordingly, determining the error code format corresponding to the status code based on the bit data of a predetermined bit width includes: determining whether the status code belongs to the first error code format or the second error code format based on the value of the first preset bit in the low preset bit width bit data.

[0074] After extracting the lower 12 bits of data, the test terminal reads the first preset bit from the lower 12 bits, namely the 7th bit (bit 6) from the least significant bit, and determines the error code format corresponding to the status code based on the value of the first preset bit. For example, when the value of bit 6 is "0", the test terminal determines that the current status code belongs to the first error code format (F0 format) and records the current error code format information; when the value of bit 6 is "1", the test terminal determines that the current status code belongs to the second error code format (F1 format) and records the current error code format information.

[0075] By extracting the low-preset-width bit data of the status code as a unified parsing object and determining the error code format based on the first preset bit in the low-preset-width bit data, this embodiment of the application can quickly and accurately distinguish different error code formats at the beginning of the error parsing process, avoiding the problem of subsequent parsing path errors due to unclear format determination. At the same time, this method establishes error code format determination on a clear bit-level rule basis, making the status code parsing process consistent and standardized, reducing parsing differences between different test implementations, thereby improving the accuracy, stability, and maintainability of error parsing during the trusted cryptographic module testing process.

[0076] In existing trusted cryptographic module testing schemes, even if an error status code can be identified, the understanding is usually limited to the "error has occurred" level, making it difficult to further distinguish the specific source of the error. Since error codes in trusted cryptographic modules may correspond to multiple error sources under the same error code format, such as specification incompatibility errors, parameter errors, session errors, or handle errors, without further differentiation based on different preset bits in the status code, testers still need to manually analyze the error source bit by bit against the specification. This error localization process is complex and inefficient. Furthermore, inconsistent understandings of error source determination rules across different test implementations can easily lead to inconsistent parsing results, affecting the accuracy and repeatability of test conclusions.

[0077] Based on this, in some embodiments, the error category corresponding to the status code is determined based on the error code format and the values ​​of different preset bits in the status code, including: when the status code is determined to be a first error code format, the error category corresponding to the status code is determined to be a specification-compatible error or a non-specification-compatible error based on the values ​​of the second preset bits in the low preset bit width bit data; when the status code is determined to be a second error code format, the error category corresponding to the status code is determined to be a parameter error, a session error, or a handle error based on the values ​​of the third preset bits in the low preset bit width bit data.

[0078] When the status code is determined to be in the first error code format (e.g., F0 format), the test terminal makes a judgment based on the second preset bit in the low preset bit width data. Specifically, the test terminal reads the value of the 8th bit (bit7) from the least significant bit in the lower 12 bits of data. When bit7 is "0", the test terminal determines that the error category corresponding to the current status code is a specification-compatible error and outputs that the current error belongs to an error type compatible with the TCM1.2 specification. When bit7 is "1", the test terminal determines that the error category corresponding to the current status code is a non-specification-compatible error and outputs that the current error belongs to another error type under the TCM2.0 specification. Subsequently, the test terminal uses the data from bits 0 to 5 (bit0~bit5) as the basis for subsequent error information queries.

[0079] When the status code is determined to be in the second error code format (e.g., F1 format), the test terminal further determines the error category based on the third preset bit in the low preset bit width data. Specifically, the test terminal reads the value of the 6th bit (bit5) from the least significant bit in the lower 12 bits of data and determines the error source type based on this value: when bit5 indicates a parameter error, the test terminal determines the error category corresponding to the status code as a parameter error; when bit5 indicates a session error, the test terminal determines the error category corresponding to the status code as a session error; when bit5 indicates a handle error, the test terminal determines the error category corresponding to the status code as a handle error. Subsequently, the test terminal uses the data from bits 0 to 6 (bit0~bit6) as the basis for subsequent error information queries.

[0080] By classifying errors based on different preset bits under different error code formats, this application's embodiments can accurately distinguish between different error sources such as specification-compatible errors, non-specification-compatible errors, parameter errors, session errors, and handle errors. This refines the error parsing process from "whether an error occurred" to "where the error originated." This method reduces the need for manual specification review and bit-by-bit error source analysis, improving the accuracy and efficiency of error location. It also ensures consistency of error parsing results across different test implementations, thereby enhancing the standardization, repeatability, and engineering practicality of error analysis during trusted cryptographic module chip testing.

[0081] Based on this, in some embodiments, according to the error code format and error category, a corresponding error code dictionary is selected, and error information corresponding to the status code is queried from the error code dictionary, including: selecting a corresponding error code dictionary from multiple sets of independently maintained error code dictionaries according to the error code format and error category; extracting at least a portion of the bit data from the low preset bit width bit data, and using at least a portion of the bit data as a key index to query the corresponding error information in the selected error code dictionary.

[0082] The test terminal pre-maintains multiple independent error code dictionaries, with each dictionary corresponding to a different error code format and error category.

[0083] For example, for standard-compliant or non-standard-compliant errors under the first error code format, the test terminal selects the corresponding first-type error code dictionary (ErrCode0 dictionary); for parameter errors, session errors, or handle errors under the second error code format, the test terminal selects the corresponding second-type error code dictionary (ErrCode1 dictionary); and for warning status codes, the test terminal selects the corresponding warning error code dictionary (Warning dictionary). Each error code dictionary is maintained independently and is used to store the mapping relationship between error codes and error names under the corresponding category.

[0084] During the specific query process, the test terminal extracts at least a portion of bits from the low preset bit width bit data as the query basis, and uses the bit data as a key index to perform a matching query in the selected error code dictionary. The number of bits used for the query varies depending on the error code dictionary, in order to match the error code encoding rules under the corresponding error code format.

[0085] For example, when the status code belongs to the first error code format (F0), the test terminal extracts a preset number of low-order bits (e.g., bits 0 to 5) corresponding to this error code format from the low preset bit-width bit data as a key index. When the status code belongs to the second error code format (F1), the test terminal extracts another preset number of low-order bits (e.g., bits 0 to 6) corresponding to this error code format from the low preset bit-width bit data as a key index. The test terminal then searches the corresponding error code dictionary based on the extracted key index to obtain the error information that matches the status code.

[0086] By selecting a target dictionary from multiple independently maintained error code dictionaries based on error code format and error category, and using bit data of different widths as query indexes for different error code dictionaries, this embodiment of the application can transform the complex error code parsing process into a structured, reusable mapping query process, avoiding inconsistencies caused by manually consulting specifications or hard-coded parsing logic. Simultaneously, this method can accurately match encoding rules under different error code formats, improving the accuracy and stability of error information queries, reducing the implementation complexity and maintenance cost of the test system, thereby improving the efficiency and engineering usability of error parsing during the testing of trusted cryptographic module chips.

[0087] The above describes the process of determining the error code format, identifying the error category, and querying the error information when the status code indicates that the execution failed. In addition, it is necessary to handle the case where the status code indicates that the command was executed successfully to ensure that the test process can obtain complete and standardized test results output under both successful and failed execution paths.

[0088] In some embodiments, when the status code is an expected success status code, the returned parameters in the response data are parsed to output the corresponding test success result.

[0089] Specifically, after parsing the status code from the response data and confirming that it is the expected success status code, the test terminal parses the return parameters in the response data, excluding the status code, according to the preset response data structure rules. The return parameters may include the function execution result data corresponding to the current test command, such as password operation results, random number data, status information, or other specification-defined return fields.

[0090] After parsing, the test terminal associates the returned parameters with the current test command and outputs or records the parsed result as a test success result. For example, the test terminal can output the returned parameters to the test interface, write them to the test log or test report file, or provide them as a return value to the upper-level automated test script for use in subsequent test processes or result analysis.

[0091] By parsing the returned parameters in the response data and outputting a test success result when the status code is an expected success status code, this embodiment of the application enables the test process to cover both successful and failed execution paths simultaneously, avoiding a simple judgment based solely on "whether it was successful" as the test conclusion. This approach not only improves the completeness and verifiability of the test results but also facilitates the automated recording and analysis of the execution results of the trusted cryptographic module chip, thereby enhancing the standardization, automation, and engineering practical value of the test process.

[0092] In the random number testing process of existing trusted cryptographic modules, testers typically need to obtain a large number of random number samples and use specialized verification software to perform statistical tests on the obtained random numbers to verify randomness-related indicators. Due to limitations imposed by testing standards and certification requirements, random number verification requires a high sample length. It usually requires repeatedly executing the random number acquisition command and accumulating the returned random number data each time to form a random number file in order to complete the testing of various randomness indicators.

[0093] However, due to limitations in communication protocols and COS (Command Execution System), the length of random numbers returned by a single random number retrieval command typically has an upper limit. Furthermore, the maximum length of a single random number retrieval supported by the trusted cryptographic module is also limited by the parameter configuration of the command buffer in the COS. Therefore, the length of a single random number retrieval and the corresponding number of loop executions set in the random number test script are variable parameters in different trusted cryptographic module chips or different COS environments. Existing test solutions often rely on testing experience or historical engineering data to fix these parameters.

[0094] In this approach, if the set single random number retrieval length is too short, a large number of loop calls to the random number retrieval command are needed to meet the random number sample length requirement, significantly increasing the time consumed by random number testing. If the set single retrieval length exceeds the actual support range of the current COS, it may cause test failures or require repeated manual adjustment of script parameters, reducing testing efficiency and the degree of automation in the testing process. Therefore, existing random number testing solutions struggle to achieve efficient acquisition of random number data while ensuring compatibility with different COS environments.

[0095] Based on this, in some embodiments, when the test command is a random number-related test command, the method includes: sending a random number acquisition request to the trusted cryptographic module chip, and setting the length of the random number requested in the random number acquisition request to a target length exceeding the expected supported range; determining the maximum length of a single random number acquisition supported by the trusted cryptographic module chip based on the random number response data returned by the trusted cryptographic module chip; and determining the length of a single random number acquisition and the corresponding number of loop executions during the random number test based on the maximum length of a single random number acquisition, so as to obtain random number data of the target length.

[0096] When the test command executed by the test terminal is a random number related test command, the test terminal first sends a random number acquisition request to the trusted cryptographic module chip, and sets the length of the random number requested in the random number acquisition request to a target length that exceeds the expected supported range.

[0097] For example, the test terminal sets the requested random number length in the random number acquisition request to a target length significantly larger than the usual configuration value, to trigger the trusted cryptographic module chip to return its actual supported capability. In one specific implementation, the test terminal sets the length field in the random number acquisition request to 4 bytes "FFFFFFFF". This length usually exceeds the range of a single random number acquisition supported by a typical COS, but a trusted cryptographic module conforming to the TCM 2.0 protocol specification will not return an error status in this case.

[0098] When the trusted cryptographic module chip receives a random number retrieval request, if the request length exceeds the single random number retrieval limit supported by the chip or the current COS, the chip will not return an error status, but will instead return the maximum length of random number data it can actually support. The test terminal determines the maximum length of a single random number retrieval supported by the current trusted cryptographic module chip based on the actual length of the returned random number in the random number response data.

[0099] After obtaining the maximum length of a single random number acquisition, the test terminal calculates the length of a single random number acquired during the random number test and the corresponding number of loop executions, based on the preset target total length requirement for random numbers.

[0100] For example, the test terminal uses the maximum length of a single random number retrieval as the single retrieval length, and determines the required number of random number retrieval loops accordingly, in order to acquire random number data of the target length while minimizing the number of command calls. Subsequently, the test terminal executes the random number retrieval operation according to the determined parameters until it acquires random number data that meets the test requirements.

[0101] By first obtaining the maximum length of a single random number acquisition supported by the trusted cryptographic module chip during the random number test, and adaptively determining the single acquisition length and the number of loop executions based on this maximum length, the embodiments of this application do not require manual verification or modification of the random number test script after changing the COS. This significantly improves the efficiency of random number acquisition while ensuring compatibility, and effectively saves the debugging and execution time of the test project, thereby enhancing the practicality and stability of the trusted cryptographic module chip test method in engineering applications.

[0102] Based on the file organization method and communication module adaptation mechanism of the above test project, the following section explains the collaborative relationship of each functional module in the test project in conjunction with the specific system structure.

[0103] Figure 3 This is the second schematic diagram of the framework of the test system for the trusted cryptographic module chip provided in this application embodiment. Figure 3 As shown, the test system runs on a test PC (i.e., the test terminal), and the test PC contains a test project. The test project includes test scripts located in the script folder, as well as the implementation of functional modules located in the underlying folder.

[0104] The script folder stores test scripts, primarily consisting of script code describing the test flow, test case sequence, and test logic. The content of the script folder focuses on the organization of test strategies and test scenarios, without directly involving communication protocol implementation, error code parsing details, or low-level algorithm implementation. This allows testers to quickly write, adjust, or combine test cases without understanding the underlying implementation details, improving the readability and efficiency of test script writing.

[0105] The underlying folder stores functional modules related to the specific implementation, including communication modules, error parsing modules, and algorithm modules. The contents of the underlying folder encapsulate communication protocol adaptation, command encapsulation and parsing, error code parsing rules, and algorithm processing logic, making them transparent to upper-layer scripts and providing services to the command script module through a unified interface. By centrally managing the underlying implementation, communication protocols, parsing logic, or algorithm implementations can be replaced or upgraded without affecting test scripts, reducing system maintenance costs.

[0106] The test project adopts a file organization method that separates script folders from underlying folders to decouple functions. This separates the test process logic from the underlying implementation, making the test project structure clearer. It facilitates the rapid iteration and reuse of test scripts and the independent maintenance and expansion of underlying modules, thereby improving the engineering maintainability and versatility of the trusted cryptographic module chip test system.

[0107] The test project includes a command script module, which organizes and triggers the execution of various test commands according to a preset test procedure. The command script module is connected to the status code parsing function, command encapsulation function, and algorithm function to coordinate the calling order of different processing logics.

[0108] The status code parsing function is connected to the error parsing module via an error code parsing interface. The error parsing module parses the status codes returned by the trusted cryptographic module chip and returns the parsed error information to the command script module. Upon receiving the return data corresponding to the sent data, the status code parsing function processes the status codes within the returned data.

[0109] The command encapsulation function is connected to the communication module via a communication function interface library. The communication module includes a PCSC communication library, which is used to implement communication between the test PC and external devices. In this embodiment, the command encapsulation function encapsulates the test commands generated by the command script module and, through the communication function interface library, calls the PCSC communication library to send the encapsulated commands to the external device.

[0110] Algorithm functions are connected to algorithm modules through an algorithm library. The algorithm module is used to process the algorithm logic involved in the testing process, such as performing algorithmic calculations or verifications on the returned data, and returning the processing results to the command script module.

[0111] During data interaction, the test PC establishes a communication connection with an external card reader via a communication module. The card reader is further connected to a trusted cryptographic module chip. The test PC sends test commands as output data to the trusted cryptographic module chip through the card reader. After executing the test commands, the trusted cryptographic module chip returns the execution results as output data to the test PC via the card reader.

[0112] Through the above structure, the command script module can uniformly schedule the error parsing module, communication module, and algorithm module to send test commands for the trusted cryptographic module chip, receive returned data, and parse and process test results.

[0113] In existing trusted cryptographic module testing schemes, the generation of test commands and the implementation of communication protocols are usually tightly coupled, with different communication protocols often corresponding to different test programs or communication implementation logic. When the trusted cryptographic module chip under test adopts different communication protocols, or when switching communication methods during the R&D, debugging, or mass production stages, testers need to repeatedly modify or redevelop the communication part of the test program. This results in poor reusability of test scripts, high maintenance costs, and is prone to introducing configuration errors or omissions during protocol switching, which is not conducive to the long-term maintenance and expansion of the test project.

[0114] Furthermore, since the specification standard for TCM 2.0 has been officially established and stably released, chip commands and their corresponding command scripts that conform to this specification strictly adhere to unified interfaces and calling rules. Therefore, after the test scripts are debugged and finalized, the script modules in the test project do not need to be frequently adjusted with changes to the chip under test or COS, thus ensuring the consistency and reusability of the test process. In contrast, different COSs may use different protocol types at the communication layer. Accordingly, the communication library used in the test project to implement low-level data interaction needs to be adapted and adjusted according to the specific protocol.

[0115] Based on this, in some embodiments, the process of the test terminal sending test commands to the trusted cryptographic module chip and receiving response data is implemented through a communication library. The communication library is used to adapt to at least two different communication protocols without changing the content of the test commands, so as to complete the sending of test commands and the receiving of response data.

[0116] Specifically, after generating the test command, the test terminal transmits it to the communication library. The communication library, without altering the content of the test command, selects the appropriate communication processing method to encapsulate the test command according to the communication protocol type used by the trusted cryptographic module chip under test, and sends it to the trusted cryptographic module chip through the corresponding communication interface. When the trusted cryptographic module chip returns response data, the communication library performs protocol parsing on the response data and returns the parsed response data to the test terminal.

[0117] In some embodiments, the communication library may support at least two different communication protocols, such as serial communication protocols, bus communication protocols, or other communication protocols that conform to the trusted cryptographic module interface specification.

[0118] Therefore, by unifying the encapsulation and parsing of the communication library, the test command logic and communication protocol implementation can be decoupled. The test terminal does not need to modify the test command generation logic under different communication protocol environments. The same test program can be reused under different communication protocol environments, flexibly adapting to different communication protocol environments. This significantly reduces the maintenance cost and protocol switching cost of test scripts, reduces the configuration risk caused by manual modification of communication implementation, and improves the stability and consistency of the testing process. As a result, the versatility and engineering practicality of the trusted cryptographic module chip testing system in multiple protocols and environments are enhanced.

[0119] For example, such as Figure 3 As shown, the communication module in the underlying folder will be updated according to the communication protocol type used by the COS under test, without affecting the execution logic of the upper-level command script module. Therefore, when testing different communication protocols, only the communication module needs to be debugged or replaced to complete the switching of the test environment.

[0120] In some embodiments, the test project can also support storing multiple versions of communication protocol libraries simultaneously, and can select the corresponding communication library to participate in the test based on the type of COS being tested. To ensure the uniformity of the test project structure, the file names of communication libraries corresponding to different communication protocols are kept consistent; to avoid conflicts between multiple versions of communication libraries, communication protocol files that are not currently being tested can be compressed and stored, and the corresponding protocol type can be indicated in the compressed file name. When it is necessary to switch to another COS protocol for testing, simply compress the currently inapplicable communication library and store it in the specified location, and then decompress and enable the communication library corresponding to the target protocol to complete the switch.

[0121] Figure 4 This is the third schematic diagram of the framework of the test system for the trusted cryptographic module chip provided in this application embodiment. Figure 4 As shown, the command script module is connected to the error parsing module, the communication library module (e.g., the SPI communication library module), and the algorithm library module, respectively.

[0122] The error parsing module is used to parse the status codes of the data returned during the test and to feed back the parsed error information to the command script module.

[0123] The SPI communication library module includes a simulator communication library module and other protocol modules. The simulator communication library module is used in this embodiment to implement communication between the test PC and an external trusted cryptographic module chip simulator; the other protocol modules support extensions for communication protocols other than SPI communication. In this embodiment, the command script module uses the SPI communication library module to send test commands and receive returned data.

[0124] The algorithm library module is used to perform corresponding algorithm processing on the returned data and return the processing results to the command script module.

[0125] During data interaction, the test PC establishes a communication connection with an external card reader via the SPI communication library module. The card reader is further connected to a trusted cryptographic module chip simulator. The test PC sends test commands as output data to the trusted cryptographic module chip simulator. After executing the test commands, the trusted cryptographic module chip simulator returns the execution results as output data to the test PC via the card reader.

[0126] The command encapsulation functions in different communication library modules remain unchanged, while the communication function interface layer and communication library within the communication library module are edited as needed according to the specific protocol. This framework ensures that command script sending and receiving are unaffected by changes to the communication library.

[0127] With the above structure, the command script module can adapt to real trusted cryptographic module chips or trusted cryptographic module chip simulators through different communication library modules without changing the test logic, so as to realize the reuse and switching of the test process in different test environments.

[0128] The foregoing embodiments have described the parsing mechanism of the trusted cryptographic module chip's return status code from the perspectives of method steps and system architecture, including processing logic such as error code format determination, error category differentiation, and error information query. To facilitate a further understanding of the specific execution order and judgment path of the above error code parsing process in the test flow, the specific processing flow of error code parsing is explained below with reference to the flowchart.

[0129] Figure 5 This is a schematic diagram of the testing process for the trusted cryptographic module chip provided in an embodiment of this application. For example... Figure 5 As shown, this process is used to automatically parse the status codes returned by the Trusted Cryptographic Module (TCM) and generate corresponding error messages during the execution of the test script. This process begins execution after the script is triggered.

[0130] During the script execution process, the test terminal extracts the lower 12 bits of the error code from the response data returned by the trusted cryptography module and uses the lower 12 bits as the basis for subsequent error code parsing.

[0131] The test terminal determines whether bit 7 of the lower 12 bits of data is 1. If bit 7 is "yes", the process of parsing the error code using format 1 is initiated; if bit 7 is "no", the process of parsing the error code using format 0 is initiated.

[0132] When parsing the error code using format 1, the test terminal further checks if the value of bit 6 is 1. When the value of bit 6 is "yes", the test terminal determines that it is a parameter error, and by combining the values ​​of bits 11 to 8, it can determine the specific parameter error type. Subsequently, the test terminal obtains the error values ​​of bits 5 to 0, and generates the final error code information based on the error values ​​and the TPM2 error codes.

[0133] When bit6 is "No", the test terminal determines that the error is a Handle error or a Session error, and continues to check whether bits 11 to 8 are greater than 7.

[0134] When bits 11 to 8 are greater than 7, the test terminal determines it to be a Handle error, obtains the error values ​​of bits 5 to 0, and generates the final error code information by comparing it with the TPM2 error code. When bits 11 to 8 are not greater than 7, the test terminal determines it as a Session error, obtains the error values ​​of bits 5 to 0, and generates the final error code information by comparing it with the TPM2 error code.

[0135] In the event of the above-mentioned parameter errors, Handle errors, or Session errors, the test terminal will ultimately generate the corresponding final error code information by referring to the error code in Format 1.

[0136] When using format 0 to parse the error code, the test terminal further checks whether the value of bit 11 is 1.

[0137] When bit11 is "yes", the test terminal determines that the return code is a warning, then obtains the error values ​​of bits 6 to 0, and generates the final error code warning information by referring to the format 0 error code.

[0138] When bit11 is "no", the test terminal determines that the return code is an error, and similarly obtains the error values ​​of bits 6 to 0, and generates the final error code information by referring to the format 0 error code.

[0139] After generating the final error code or error code warning, the test terminal outputs the corresponding parsing result and executes a stop operation to end the current error code parsing process.

[0140] It should be noted that, Figure 5 The bit determination, format 0 / format 1 distinction, parameter error, Handle error, Session error, warning determination, and TPM2 error code comparison process involved in the process shown are all specific examples of the error code format determination, error category determination, and error code dictionary lookup steps in the foregoing claims and embodiments at the process level, and do not constitute a limitation on the scope of protection.

[0141] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0142] The testing method for a trusted cryptographic module chip provided in this application can be executed by a testing device for the trusted cryptographic module chip. This application uses an example of a testing device for the trusted cryptographic module chip executing the testing method to illustrate the testing device for the trusted cryptographic module chip provided in this application.

[0143] Figure 6 This is a schematic diagram of the structure of the test device for the trusted cryptographic module chip provided in the embodiments of this application. Figure 6 As shown, the test device 600 for the trusted cryptographic module chip is equipped with an error parsing module, which includes: a transceiver unit 601, a result determination unit 602, an error parsing unit 603, and an output unit 604. Wherein: The transceiver unit 601 is used to send test commands to the trusted cryptographic module chip and receive response data returned by the trusted cryptographic module chip.

[0144] The result determination unit 602 is used to extract the status code from the response data and determine whether the status code is the expected success status code if the status code is valid.

[0145] The error parsing unit 603 is used to extract a predetermined bit width of bit data from the status code when the status code is an unexpected success status code, and to determine the error code format corresponding to the status code based on the predetermined bit width of bit data.

[0146] The error parsing unit 603 is also used to determine the error category corresponding to the status code based on the error code format and the values ​​of different preset bits in the status code.

[0147] The error parsing unit 603 is also used to select the corresponding error code dictionary according to the error code format and error category, and to query the error information corresponding to the status code from the error code dictionary.

[0148] Output unit 604 is also used to output error information to indicate the reason for the test command failure.

[0149] According to the testing apparatus for the trusted cryptographic module chip provided in this application embodiment, by sending test commands to the trusted cryptographic module chip and receiving its returned response data, the testing process is directly based on the actual execution results of the chip, thereby ensuring the authenticity and reliability of the test conclusions. By extracting status codes from the response data and determining whether the status code is an expected success status code when it is valid, the testing process can automatically separate into success and failure scenarios, avoiding unnecessary subsequent parsing processing of successful execution results and improving overall testing efficiency. Specifically, when the status code is an unexpected success status code, by extracting a predetermined bit width of bit data from the status code and determining the error code format based on this bit data, the status code parsing is established on the basis of standardized bit-level rules, avoiding judgment based solely on numerical comparison or human experience, thereby improving the consistency and accuracy of error parsing. Furthermore, based on the error code format and the values ​​of different preset bits in the status code, the error category is determined, enabling the testing system to distinguish errors of different sources and natures, narrowing the scope of problem localization, and improving the pertinence of fault analysis. Based on this, the corresponding error code dictionary is selected according to the determined error code format and error category, and the error information corresponding to the status code is queried from the error code dictionary. The complex status code parsing process is transformed into a structured and reusable query process, reducing the complexity of test implementation and improving parsing efficiency. Finally, the error information is output to indicate the reason for the test command failure, so that the test results can be presented in a clear and readable form, reducing the need for manual interpretation of status codes bit by bit, thereby improving the accuracy and automation level of error location in the trusted cryptographic module chip testing process as a whole.

[0150] In some embodiments, the error parsing unit 603 is further configured to extract the low preset bit width bit data of the status code; and determine whether the status code belongs to the first error code format or the second error code format based on the value of the first preset bit in the low preset bit width bit data.

[0151] In some embodiments, the error parsing unit 603 is further configured to, when the status code is determined to be in the first error code format, determine the error category corresponding to the status code as a specification-compatible error or a non-specification-compatible error based on the value of the second preset bit in the low preset bit width bit data; and when the status code is determined to be in the second error code format, determine the error category corresponding to the status code as a parameter error, session error, or handle error based on the value of the third preset bit in the low preset bit width bit data.

[0152] In some embodiments, the error parsing unit 603 is further configured to select a corresponding error code dictionary from multiple independently maintained error code dictionaries according to the error code format and error category; extract at least a portion of the bit data from the low preset bit width bit data, and use at least a portion of the bit data as a key index to query the corresponding error information in the selected error code dictionary; wherein the number of bits used for querying is different for different error code dictionaries to match the error code encoding rules under the corresponding error code format.

[0153] In some embodiments, the above-described apparatus further includes a random number testing module, configured to send a random number acquisition request to the trusted cryptographic module chip when the test command is a random number-related test command, and set the length of the random number requested in the random number acquisition request to a target length exceeding the expected supported range; determine the maximum length of a single random number acquisition supported by the trusted cryptographic module chip based on the random number response data returned by the trusted cryptographic module chip; and determine the length of a single random number acquisition and the corresponding number of loop executions during the random number test based on the maximum length of a single random number acquisition, so as to obtain random number data of the target length.

[0154] In some embodiments, the above apparatus further includes a success parsing unit, configured to parse the return parameters in the response data when the status code is an expected success status code, so as to output the corresponding test success result.

[0155] In some embodiments, the above-described apparatus further includes a communication library module, which is configured to encapsulate and send the test command according to the communication protocol type adopted by the trusted cryptographic module chip under test, without changing the content of the test command, and to parse the returned data according to the protocol type, so as to realize the sending of the test command and the receiving of the response data.

[0156] In some embodiments, the above-described apparatus further includes an algorithm library module, which is configured to perform preset algorithm processing on the returned data received during the test and provide the processing results to the status code parsing process or the test result output process to support the analysis and verification of the test results.

[0157] The testing device for the trusted cryptographic module chip in this application embodiment can be an electronic device or a component within an electronic device, such as an integrated circuit or a chip. The electronic device can be a test terminal, etc.

[0158] The testing apparatus for the trusted cryptographic module chip provided in this application embodiment can implement all the processes implemented in the above-described testing method embodiment for the trusted cryptographic module chip. To avoid repetition, these processes will not be described again here.

[0159] Figure 7 This is a schematic diagram of the structure of the electronic device provided in an embodiment of this application. For example... Figure 7 As shown, this application embodiment also provides an electronic device 700, including a processor 701, a memory 702, and a computer program stored in the memory 702 and executable on the processor 701. When the program is executed by the processor 701, it implements the various processes of the above-described test method embodiment for the trusted cryptographic module chip and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0160] This application provides a non-transitory computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the various processes of the above-described test method embodiment for the trusted cryptographic module chip and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0161] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable media, such as computer read-only memory (ROM), random-access memory (RAM), magnetic disks, or optical disks.

[0162] The computer-readable storage medium may include: read-only memory (ROM), random-access memory (RAM), magnetic disk or optical disk, etc.

[0163] This application provides a computer program product, including a computer program that, when executed by a processor, implements the testing method for the aforementioned trusted cryptographic module chip.

[0164] This application provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described test method embodiment for the trusted cryptographic module chip, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0165] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0166] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0167] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the related technology, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0168] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

[0169] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0170] Although embodiments of this application have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of this application, the scope of which is defined by the claims and their equivalents.

Claims

1. A testing method for a trusted cryptographic module chip, characterized in that, The method includes: Send a test command to the trusted cryptographic module chip and receive the response data returned by the trusted cryptographic module chip; Extract the status code from the response data, and determine whether the status code is the expected success status code if the status code is valid. In the case that the status code is an unexpected success status code, extract the bit data of a predetermined width from the status code, and determine the error code format corresponding to the status code based on the bit data of the predetermined width. Based on the error code format and the values ​​of different preset bits in the status code, the error category corresponding to the status code is determined; Based on the error code format and the error category, select the corresponding error code dictionary and query the error information corresponding to the status code from the error code dictionary; Output the error message to indicate the reason for the test command's failure.

2. The testing method for the trusted cryptographic module chip according to claim 1, characterized in that, The step of extracting the predetermined bit width bit data from the status code includes: extracting the low predetermined bit width bit data of the status code; Determining the error code format corresponding to the status code based on the predetermined bit width of the bit data includes: Based on the value of the first preset bit in the low preset bit width bit data, it is determined whether the status code belongs to the first error code format or the second error code format.

3. The testing method for the trusted cryptographic module chip according to claim 2, characterized in that, The step of determining the error category corresponding to the status code based on the error code format and the values ​​of different preset bits in the status code includes: When the status code is determined to be in the first error code format, the error category corresponding to the status code is determined to be a standard compatible error or a non-standard compatible error based on the value of the second preset bit in the low preset bit width bit data. If the status code is determined to be in the second error code format, the error category corresponding to the status code is determined to be parameter error, session error, or handle error based on the value of the third preset bit in the low preset bit width bit data.

4. The testing method for a trusted cryptographic module chip according to any one of claims 1 to 3, characterized in that, The step of selecting the corresponding error code dictionary based on the error code format and the error category, and querying the error information corresponding to the status code from the error code dictionary, includes: Based on the error code format and the error category, select the corresponding error code dictionary from multiple sets of independently maintained error code dictionaries; Extract at least a portion of the bits from the low preset bit width bit data, and use the at least a portion of the bits as a key index to look up the corresponding error information in the selected error code dictionary; The number of bits used for querying varies depending on the error code dictionary, in order to match the error code encoding rules under the corresponding error code format.

5. The testing method for the trusted cryptographic module chip according to claim 1, characterized in that, The method further includes: if the status code is an expected success status code, parsing the return parameters in the response data to output the corresponding test success result.

6. The testing method for the trusted cryptographic module chip according to claim 1, characterized in that, The process of sending test commands to the trusted cryptographic module chip and receiving response data is implemented through a communication library. The communication library is used to encapsulate and send test commands according to the communication protocol type adopted by the trusted cryptographic module chip under test, without changing the content of the test commands, and to parse the returned data according to the protocol type, so as to realize the sending of test commands and the receiving of response data.

7. The testing method for the trusted cryptographic module chip according to claim 1, characterized in that, When the test command is a random number-related test command, the method includes: Send a random number acquisition request to the trusted cryptographic module chip, and set the length of the random number requested in the random number acquisition request to a target length that exceeds the expected supported range; Based on the random number response data returned by the trusted cryptographic module chip, the maximum length of a single random number acquisition supported by the trusted cryptographic module chip is determined. Based on the maximum length obtained from a single random number, determine the length of the random number obtained in a single random number test and the corresponding number of loop executions, so as to obtain random number data of the target length.

8. A testing device for a trusted cryptographic module chip, characterized in that, The device is equipped with an error parsing module, including: The transceiver unit is used to send test commands to the trusted cryptographic module chip and receive response data returned by the trusted cryptographic module chip. The result determination unit is used to extract a status code from the response data and determine whether the status code is an expected success status code if the status code is valid. An error parsing unit is used to extract a predetermined bit width of bit data from the status code when the status code is an unexpected success status code, and to determine the error code format corresponding to the status code based on the predetermined bit width of bit data. The error parsing unit is also used to determine the error category corresponding to the status code based on the error code format and the values ​​of different preset bits in the status code; The error parsing unit is further configured to select the corresponding error code dictionary according to the error code format and the error category, and query the error information corresponding to the status code from the error code dictionary; The output unit is also used to output the error information to indicate the reason for the test failure of the test command.

9. The testing apparatus for a trusted cryptographic module chip according to claim 8, characterized in that, The device also includes a communication library module, which is configured to encapsulate and send the test command according to the communication protocol type adopted by the trusted cryptographic module chip under test, without changing the content of the test command, and to parse the returned data according to the protocol type, so as to realize the sending of the test command and the receiving of the response data.

10. The testing apparatus for a trusted cryptographic module chip according to claim 8, characterized in that, The device also includes an algorithm library module, which is configured to perform preset algorithm processing on the returned data received during the test and provide the processing results to the status code parsing process or the test result output process to support the analysis and verification of the test results.

11. A testing system for a trusted cryptographic module chip, characterized in that, The system includes: Trusted cryptographic module chip; A communication interface device is used as a data interaction interface between the test terminal and the trusted cryptographic module chip during the test process, so as to realize the sending of test commands and the receiving of response data. A test terminal is used to test the trusted cryptographic module chip and is configured to execute the test parsing method of the trusted cryptographic module as described in any one of claims 1-7.

12. The testing system for the trusted cryptographic module chip according to claim 11, characterized in that, The test terminal is equipped with a communication library, which is used to encapsulate the test command protocol and parse the response data without changing the content of the test command, so as to adapt to the communication protocol adopted by the trusted cryptographic module chip.

13. The testing system for the trusted cryptographic module chip according to claim 11, characterized in that, The test terminal is configured to, when performing random number-related tests, send a random number acquisition request exceeding the expected length to the trusted cryptographic module chip to determine the maximum length of a single random number acquisition supported by the trusted cryptographic module chip, and complete the random number test based on the maximum length.

14. The testing system for a trusted cryptographic module chip according to any one of claims 11-13, characterized in that, The communication interface device includes a card reader.

15. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the test parsing method for the trusted cryptographic module as described in any one of claims 1-7.

Images