Algorithm security detection method and system for cryptographic card, and storage medium

Abstract

The present application discloses an algorithm security detection method and system for a cryptographic card, and a storage medium. The method comprises: receiving a first ciphertext and a second ciphertext outputted by a cryptographic card, wherein the first ciphertext is obtained by encrypting a known plaintext message, and the second ciphertext is obtained by encrypting an attacked target; in the case of the presence of key reuse in a random private key value, determining whether the second ciphertext can be decrypted to the attacked target on the basis of the known plaintext message and the first ciphertext; if yes, determining that a cryptographic card algorithm security detection result indicates a security risk; and if not, determining that the cryptographic card algorithm security detection result is normal. The present application can implement algorithm security detection of cryptographic cards.

Description

Algorithm security testing methods, systems, and storage media for cryptographic encryption cards

[0001] This application claims priority to Chinese Patent Application No. 202410985641.0, filed on July 23, 2024, entitled "Method, System and Storage Medium for Algorithm Security Detection of Cryptographic Encryption Card", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of information security technology, specifically to a method, system, and storage medium for detecting the algorithm security of a cryptographic encryption card. Background Technology

[0003] A commercial cryptographic encryption card is a hardware device that provides commercial cryptographic services. It typically generates, stores, and manages digital keys, performs encryption and decryption operations, and provides digital signatures and authentication. Encryption cards are fundamental infrastructure for building security systems and can be integrated into information security devices through built-in or plug-in methods.

[0004] Security testing of encrypted cards is a method to ensure that the card can continuously and effectively protect channels and data. The testing includes: cryptographic function testing, physical security testing, protocol implementation testing, authentication and authorization, etc.

[0005] When selecting or manufacturing complete equipment, the testing of encryption cards typically focuses on functional indicators such as algorithm correctness, interface performance, and stress test performance. However, the security testing of the algorithm implemented on the encryption card itself, which is the cornerstone of the entire cryptographic security system, is often overlooked, mainly for the following reasons:

[0006] (1) Limited to the testing interfaces of encryption card vendors, which typically only contain content related to algorithm correctness and performance.

[0007] (2) Testers lack testing experience and tools to detect algorithm security.

[0008] (3) The authentication process of cryptographic modules mainly focuses on compliance testing.

[0009] (4) It is difficult to find problems from the callback results. Whether the hardware has safely implemented the algorithm needs to be verified by formula.

[0010] In related technologies, patent application CN114244503A proposes a method for testing the performance of cryptographic devices. This method only verifies the "correctness" of the encryption card's algorithm interface and does not verify the security of the algorithm implemented on the encryption card itself. Patent application CN115525564A proposes a testing method for the kernel-mode driver interface of a PCIe cryptographic card. This method is for functional testing of the server cryptographic machine, not the encryption card, and does not verify the security of the hardware algorithm. The thesis "Research on Key Technologies of High-Performance PCI-E Cryptographic Cards, Master's Thesis, Li Ming" proposes detecting the quality of random numbers, specifically whether the probabilities of 0 and 1 are balanced. However, simply checking whether the probabilities of 0 and 1 meet the requirements does not fully prove the randomness of the sequence.

[0011] Summary of the Invention

[0012] The technical problem this application aims to solve is how to implement security testing of the algorithm implemented on the encryption card itself.

[0013] This application solves the above-mentioned technical problems through the following technical means:

[0014] Firstly, this application proposes a method for detecting the algorithmic security of a cryptographic encryption card, the method comprising:

[0015] Receive the first ciphertext and the second ciphertext output by the encryption card. The first ciphertext is obtained by encrypting a known plaintext message, and the second ciphertext is obtained by encrypting the target being attacked.

[0016] Assuming a random private key value allows for key reuse, determine whether the second ciphertext can be restored to plaintext based on the plaintext message and the first ciphertext.

[0017] If so, then the security test result of the encryption card algorithm indicates that there is a security risk.

[0018] If not, then the encryption card algorithm security test result is normal.

[0019] Furthermore, the setting of a random private key value involves key reuse. Determining whether the second ciphertext can be restored to the attacked target based on the plaintext message and the first ciphertext includes:

[0020] Based on the random private key value and the encryption public key, a ciphertext segment containing plaintext information in the first ciphertext and a ciphertext segment containing plaintext information in the second ciphertext are determined;

[0021] Based on the plaintext message, the ciphertext segment containing plaintext information in the first ciphertext, and the ciphertext segment containing plaintext information in the second ciphertext, a plaintext restoration function is used to attempt to restore the plaintext corresponding to the second ciphertext. The plaintext restoration function is:

[0022] M′ b =C a2 xor M a xor C b2

[0023] In the formula, M′ b Indicates cracking plaintext, M a This indicates the plaintext message, C a2 This indicates that the first ciphertext contains a ciphertext fragment containing plaintext information, C b2 This indicates that the second ciphertext contains a ciphertext fragment containing plaintext information.

[0024] Furthermore, the method also includes:

[0025] Receive the first signature value and the second signature value output by the encryption card, wherein the first signature value and the second signature value are obtained by signing two known sets of plaintext messages, respectively.

[0026] If the random private key value is set to be reused, determine whether the signature private key can be successfully restored based on the first signature value and the second signature value;

[0027] If so, then the algorithm security test result of the encryption card is determined to have a security risk;

[0028] If not, then the algorithm security test result of the encryption card is normal.

[0029] Furthermore, the setting of the random private key value involves key reuse. Determining whether the signing private key can be successfully restored based on the first signature value and the second signature value includes:

[0030] Based on the first signature value and the second signature value, an attempt is made to restore the signing private key using a private key restoration function, wherein the private key restoration function is:

[0031] d′=(S a -S b ) / (r a -r b )-1

[0032] In the formula, d′ represents the restored signature private key, (r a ,S a ) represents the first signature value, (r b ,S b ) represents the second signature value;

[0033] The derivation result P′ of the signature public key is calculated based on the restored signature private key. If the derivation result P′ of the signature public key is equal to the real signature public key P, then the signature private key is determined to have been successfully restored.

[0034] Furthermore, the method also includes:

[0035] Iterate through the key management and algorithm interfaces in the encryption card API function interface, and add the interface name of the key management and algorithm interface with hook function record output and the corresponding hook function to the detection list file;

[0036] When the test list file is empty, the test results are output directly; otherwise, the API's random number generation interface is called to collect data of a set size and pass it to the random number sieve function to obtain the test results of each item of the random number sieve function.

[0037] Generate a random plaintext message M;

[0038] The message M is encrypted N times in a loop, and the content of the ciphertext C1 segment is recorded to the detection list file each time.

[0039] Perform deduplication on the ciphertext C1 segment in the detection list file and modify the return value of the hook function;

[0040] The security of the API function interface is tested based on the number of times the hook function records, the detection results of each item of the random number sieve function, and whether there are duplicates in the deduplication operation.

[0041] Furthermore, the security check of the API function interface based on the number of records in the hook function, the detection results of each item in the random number sieve function, and whether there are duplicates in the deduplication operation includes:

[0042] When the number of records in the hook function is zero, the API function interface is considered to be in normal status.

[0043] When the number of records in the hook function is non-zero, and each item in the random number sieve function has no failed items and the deduplication operation has no duplicates, the API function interface is determined to be of low risk.

[0044] When the number of records in the hook function is non-zero and each item in the random number sieve function has a failed item and the deduplication operation has no duplicates, the API function interface status is determined to be medium risk.

[0045] When the hook function records a non-zero number of times, and each item in the random number sieve function has a failed item and the deduplication operation has duplicates, the API function interface is determined to be of high risk.

[0046] Furthermore, the method also includes:

[0047] The compliance of the interfaces was tested in accordance with the requirements of the "Application Interface Specification for Cryptographic Devices GM / T 0018-2012". The types of interfaces tested for compliance included device management interfaces, key management interfaces, asymmetric algorithm interfaces, symmetric algorithm interfaces, hash algorithm interfaces, and file operation interfaces.

[0048] If at least one type of interface call fails or does not exist in the compliance check interface types, the password card interface is deemed non-compliant.

[0049] Furthermore, the method also includes:

[0050] Call the random number generation interface of the encryption card to collect a random sequence file of a set size;

[0051] A test thread is created to test the random sequence file. The test items include poker algorithm test items, frequency test items, block frequency test items, overlapping template matching test items, total number of runs test items, run distribution test items, maximum run within a block test items, binary derivation test items, autocorrelation test items, cumulative sum test items, approximate entropy test items, discrete Fourier transform test items, matrix rank test items, linear complexity test items, and compression test items.

[0052] The compliance of random numbers is checked based on the test results of each test item.

[0053] Secondly, this application also proposes an algorithm security detection system for a cryptographic encryption card. The system includes a container manager, a test container, and an encryption card driver module. The container manager is used to provide a runtime environment for the test container image and to run a daemon process into the test container via the unshare command.

[0054] The test container includes a random private key detection container, which in turn includes an encryption test module, wherein:

[0055] The encryption test module is used to determine that the encryption card has a security risk when there is key reuse in the set random private key value and the second ciphertext can be restored to plaintext based on the plaintext message output by the encryption card and the first ciphertext. The first ciphertext is obtained by encrypting a known plaintext message and the second ciphertext is obtained by encrypting the target being attacked.

[0056] Furthermore, the random private key detection container also includes a signature testing module. The signature testing module is used to determine that there is a security risk in the encryption card when the random private key value is reused and the signature private key can be successfully restored according to the first signature value and the second signature value output by the encryption card. The first signature value and the second signature value are obtained by signing two sets of known plaintext messages respectively.

[0057] Furthermore, the encryption test module is used to restore the plaintext of the second ciphertext using a plaintext restoration function;

[0058] The plaintext restoration function is:

[0059] M′ b =C a2 xor M a xor C b2

[0060] In the formula, M′ b Indicates cracking plaintext, M a This indicates the plaintext message, C a2 This indicates that the first ciphertext contains a ciphertext fragment containing plaintext information, C b2 This indicates that the second ciphertext contains a ciphertext fragment containing plaintext information.

[0061] Furthermore, the signature testing module is used to restore the signature private key using a private key restoration function;

[0062] The private key restoration function is:

[0063] d′=(S a -S b ) / (r a -r b )-1

[0064] In the formula, d′ represents the restored signature private key, (r a ,S a ) represents the first signature value, (r b ,S b ) represents the second signature value.

[0065] Furthermore, the test container also includes an API security detection container, which includes an API security detection program, a security detection library, and a hook function library. The API security detection program is used to call the asymmetric algorithm interface of the encryption card, and uses the security detection library to record the API's trace call interface during loading.

[0066] The hook function library is used to perform hook operations on basic functions and modify the return values ​​of hook functions so that the return values ​​have characteristic patterns.

[0067] Furthermore, the test container also includes a compliance test container, which comprises an interface testing module and a random number abstraction test module, wherein:

[0068] The interface testing module is used to test the compliance of interfaces in accordance with the requirements of the "Application Interface Specification for Cryptographic Devices GM / T 0018-2012". The interface types for compliance testing include device management interfaces, key management interfaces, asymmetric algorithm interfaces, symmetric algorithm interfaces, hash algorithm interfaces, and file operation interfaces. If at least one type of interface fails to be called or does not exist among the interface types for compliance testing, the cryptographic card interface is determined to be non-compliant.

[0069] The random number abstraction test module is used to call the random number generation interface of the encryption card, extract a random number sequence of a set size, and perform quality testing on the random number sequence in accordance with the requirements of "Random Number Testing Requirements for Cryptographic Products GM / T 0062-2018".

[0070] Furthermore, the test container includes a random private key detection container, an API security detection container, and a compliance test container, all of which are equipped with an encryption card API interface library, which is used to provide cryptographic service interfaces.

[0071] Thirdly, this application proposes a computing processing device, comprising: a memory storing computer-readable code; and one or more processors, wherein when the computer-readable code is executed by the one or more processors, the computing processing device executes the algorithm security detection method for the cryptographic encryption card proposed in the first aspect above.

[0072] Fourthly, this application proposes a computer program including computer-readable code, which, when executed on a computing processing device, causes the computing processing device to execute the algorithm security detection method for the cryptographic encryption card as proposed in the first aspect above.

[0073] Fifthly, this application also proposes a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, it implements the algorithm security detection method for the cryptographic encryption card as described above.

[0074] The advantages of this application are:

[0075] (1) When receiving several sets of ciphertext from the encryption card, assuming that the random private key value is reused, the ciphertext can be directly restored to plaintext without the encryption private key, i.e., the receiver's private key. If the restoration is successful, it indicates that the random private key of the encryption card is a non-random entropy value, and the encryption card has a security risk. When receiving several sets of signature values ​​from the encryption card, assuming that the random private key value is reused, the signature private key can be directly calculated with only the signature value and the signature public key. If the signature private key is successfully restored, it indicates that the random private key of the encryption card is a non-random entropy value, and the encryption card has a serious security vulnerability. Based on this, this application realizes the security detection of asymmetric algorithm encryption and the security detection of asymmetric algorithm signature, and detects whether there is a security risk in the asymmetric algorithm implemented by the encryption card itself.

[0076] (2) Vulnerability testing of the API dynamic library associated with the encryption card is achieved by using a hook function-based detection method.

[0077] (3) The service interface of the encryption card has been verified to be compliant and correct in accordance with the interface definition of device management, key management, algorithm (asymmetric / symmetric / hash algorithm) and file operation as described in the "Cryptographic Device Application Interface Specification GM / T 0018-2012".

[0078] (4) The quality of random numbers for Class E products described in “Random Number Testing Requirements for Cryptographic Products GM / T 0062-2018” is tested. The quality of random numbers is judged comprehensively from multiple test results such as distribution, autocorrelation, run length, and compression. The quality judgment of random number sequences generated in cryptographic cards is more stringent and the judgment results are more accurate.

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

[0080] Figure 1 is a flowchart illustrating an algorithm security detection method for a cryptographic encryption card proposed in an embodiment of this application;

[0081] Figure 2 is a schematic diagram of the structure of an algorithm security detection system for a cryptographic encryption card proposed in an embodiment of this application;

[0082] Figure 3 is a schematic diagram of the computing processing device for a cryptographic encryption card algorithm security detection method according to another embodiment of this application;

[0083] Figure 4 is a schematic diagram of the computer program structure of a password encryption card algorithm security detection method proposed in another embodiment of this application. Specific Implementation

[0084] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the embodiments of this application. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0085] As shown in Figure 1, this application embodiment proposes a method for detecting the algorithm security of a cryptographic encryption card, the method comprising the following steps:

[0086] S10. Receive the first ciphertext and the second ciphertext output by the encryption card. The first ciphertext is obtained by encrypting a known plaintext message, and the second ciphertext is obtained by encrypting the target being attacked.

[0087] S20. Set the random private key value to have key reuse. Determine whether the second ciphertext can be restored to the attacked target based on the plaintext message and the first ciphertext. If yes, execute step S30; otherwise, execute step S40.

[0088] S30. The security test result of the encryption card algorithm indicates that there is a security risk.

[0089] S40. The security test result of the encryption card algorithm is confirmed to be normal.

[0090] It should be noted that in this embodiment, the encryption card is the sender and the detection system is the receiver. Data encryption means that the sender uses the receiver's encryption public key PUB_B to encrypt the data and then sends the ciphertext to the receiver. The receiver uses its own encryption private key PRI_B to decrypt the ciphertext. Data signing means that the sender uses its own signing private key PRI_A to sign the data and then sends the signed value to the receiver. The receiver can only decrypt the signed value using the sender's signing public key PUB_A.

[0091] When receiving several sets of ciphertext from the encryption card, assuming key reuse exists (i.e., the random private key value is set to a fixed value), the ciphertext can be directly restored to plaintext without the encryption private key PRI_B (the receiver's private key). If this is successfully restored, it indicates that the encryption card's random private key is a non-random entropy value, and the encryption card has a security risk. Similarly, when receiving several sets of signature values ​​from the encryption card, assuming key reuse exists, the signature private key PRI_A can be directly calculated with only the signature value and the signature public key PUB_A. If the signature private key PRI_A is successfully restored, it indicates that the encryption card's random private key is a non-random entropy value, and the encryption card has a serious security vulnerability. Based on this, this application implements security detection for asymmetric algorithm encryption and signature detection for asymmetric algorithm signatures, detecting whether the asymmetric algorithm implemented by the encryption card itself has security risks.

[0092] As a further preferred technical solution, step S20: assuming the random private key value is reused, determining whether the second ciphertext can be restored to the attacked target based on the plaintext message and the first ciphertext, includes the following steps:

[0093] Based on the random private key value and the encryption public key, a ciphertext segment containing plaintext information in the first ciphertext and a ciphertext segment containing plaintext information in the second ciphertext are determined;

[0094] Based on the plaintext message, the ciphertext segment containing plaintext information in the first ciphertext, and the ciphertext segment containing plaintext information in the second ciphertext, a plaintext restoration function is used to attempt to restore the plaintext corresponding to the second ciphertext. The plaintext restoration function is:

[0095] M′ b =C 22 xor M2 xor C b2

[0096] In the formula, M′ b Indicates cracking plaintext, M a C represents the known plaintext message. a2 This indicates that the first ciphertext contains a ciphertext fragment containing plaintext information, C b2 This indicates that the second ciphertext contains a ciphertext fragment containing plaintext information.

[0097] Furthermore, there are two sets of plaintext messages (M) a M b ), where the plaintext message M a Given plaintext message M b For the target of the attack, two sets of plaintext messages (M) a M bThe plaintext message is passed to an encryption card for encryption using the SM2 algorithm. The callback retrieves the first ciphertext (C) corresponding to the plaintext message. a1 C a2 C a3 ) and plaintext message M b The corresponding second ciphertext (C) b1 C b2 C b3 ):

[0098] (M a )-->(C a1 C a2 C a3 )

[0099] (M b )-->(C b1 C b2 C b3 )

[0100] Compare the ciphertext segments in the first and second ciphertext sequences respectively. Assume the random private key value k is a fixed value (i.e., the random private key value is reused), P b If the encryption public key is the recipient's public key, then the ciphertext segment S in the first ciphertext sequence is equal to the ciphertext segment S in the second ciphertext sequence, where S represents the random private key k and the recipient's public key P. b The dot product of the two keys, S, is used to encrypt the plaintext message using the key KDF(S) derived from S, resulting in segment C2. Since both ciphertext segments use the receiver's public key P... b In encryption, when the k-value is reused, the S-value used in the two encryption processes is the same, for example, C. a2 With C b2 The S in the middle is equal:

[0101] S b =kP b =S a

[0102] In the formula, S a Indicates the plaintext M a The S value during encryption, S b Indicates the plaintext M b The S value during encryption.

[0103] Next, according to the formula for evaluating C2, "C2 = KDF(S) xor M", we can obtain:

[0104] C a2 =KDF(S a )xor M a

[0105] C b2 =KDF(Sb )xor M b

[0106] Then we can deduce M b The restoration function is:

[0107] M′ b =C a2 xor M a xor C b2

[0108] It should be noted that when restoring the ciphertext corresponding to the attacked target in this embodiment, it is only necessary to crack the ciphertext segment containing plaintext information. For example, when the SM2 algorithm is used to encrypt the plaintext message, the obtained ciphertext includes three ciphertext segments C1, C2, and C3, among which segment C2 contains plaintext information.

[0109] As a further preferred technical solution, the method further includes the following steps:

[0110] S1. Receive the first signature value and the second signature value output by the encryption card, wherein the first signature value and the second signature value are obtained by signing two known sets of plaintext messages respectively;

[0111] S2. Set the random private key value to have key reuse. Determine whether the signature private key can be successfully restored based on the first signature value and the second signature value. If yes, proceed to step S3; otherwise, proceed to step S4.

[0112] S3. The algorithm security test result of the encryption card indicates that there is a security risk.

[0113] S4. Confirm that the algorithm security test result of the encryption card is normal.

[0114] As a further preferred technical solution, in step S2, assuming that the random private key value is reused, determining whether the signature private key can be successfully restored based on the first signature value and the second signature value includes the following steps:

[0115] Based on the first signature value and the second signature value, the signature private key was successfully restored using a private key restoration function, wherein the private key restoration function is:

[0116] d′=(S a -S b ) / (r a -r b )-1

[0117] In the formula, d′ represents the restored signature private key, (r a ,S a ) represents the first signature value, (r b,S b ) represents the second signature value, S a and S b This represents a portion of the signature, calculated by combining information from the private key d and the random private key k value, r. a and r b This represents a portion of the signature, calculated using the message's hash value and the x-coordinate of the elliptic curve point.

[0118] S32. Calculate the derivation result P′ of the signature public key based on the restored signature private key. If the derivation result P′ of the signature public key is equal to the real signature public key P, it is determined that the encryption card has a security risk.

[0119] Furthermore, there are two sets of plaintext messages (M) a M b Two sets of signature values ​​(r) were obtained. a ,S a ) and (r b ,S b Assuming the signature private key d in the encrypted card is the target of the attack, and the random private key value is k, in the signature algorithm formula, the value of S is:

[0120] S=[(1+d)-1×(kr×d)]mod n

[0121] In the formula, n represents the order of the elliptic curve. For example, in the SM2 algorithm, the value of n is a 256-bit constant (prime number).

[0122] It should be noted that in plaintext message M a During the signature value calculation process, according to r a S was calculated a In plaintext message M b During the signature value calculation process, according to r b S was calculated b .

[0123] Assuming that the random private key value k is reused (i.e., k is a fixed value), the signing private key can be directly calculated given only the signature value and the signing public key. If the signing private key d is successfully restored within a given test period, it indicates that the encryption card's random private key is a non-random entropy value, and the encryption card has a serious security vulnerability.

[0124] Assuming the random private key value k is a fixed value, the formula for evaluating S is first transformed as follows:

[0125] S×(1+d)+r×d=k mod n

[0126] When the value of k is reused, the following equation is obtained:

[0127] S a×(1+d)+r a ×d=S b ×(1+d)+r b ×d

[0128] After the equation transformation, the private key restoration function can be obtained as follows:

[0129] d′=(S a -S b ) / (r a -r b )-1

[0130] As a further preferred technical solution, the method also includes a security detection step for the API function interface:

[0131] Iterate through the key management and algorithm interfaces in the encryption card API function interface, and add the interface name of the key management and algorithm interface with hook function record output and the corresponding hook function to the detection list file;

[0132] When the test list file is empty, the test results are output directly; otherwise, the API's random number generation interface is called to collect data of a set size and pass it to the random number sieve function to obtain the test results of each item of the random number sieve function.

[0133] Generate a random plaintext message M;

[0134] The message M is encrypted N times in a loop, and the content of the ciphertext C1 segment is recorded to the detection list file each time.

[0135] Perform deduplication on the ciphertext C1 segment in the detection list file and modify the return value of the hook function;

[0136] The security of the API function interface is tested based on the number of times the hook function records, the detection results of each item of the random number sieve function, and whether there are duplicates in the deduplication operation.

[0137] It should be noted that this embodiment uses commonly used related functions in the hook library to track the implementation of the encryption card's API interface, observe whether the password and random number related operations in the API are strictly implemented through the hardware encryption card, and modify the return value of the hook function to make it exhibit regularity or characteristic values, and observe whether it will have a security impact on the output of the API interface, thereby realizing the security detection of the API function interface.

[0138] In this embodiment, the security check of the API function interface means that the cryptographic implementation of the encryption card is more secure than the cryptographic service interfaces of the operating system or open-source software. The purpose of the check is to ensure that the manufacturer's API only calls the underlying implementation of the encryption card during the operation, and does not use the cryptographic-related interfaces of the operating system.

[0139] By hooking into the operating system and open-source software implementations running in the container, if the API calls these software implementation interfaces, a log will be triggered during the call. The log can be used to determine whether the API strictly executes the cryptographic service of the encryption card, rather than third-party software.

[0140] As a further preferred technical solution, the security detection of the API function interface based on the number of records of the hook function, the detection results of each item of the random number sieve function, and whether there are duplicates in the deduplication operation includes the following steps:

[0141] When the number of records in the hook function is zero, the API function interface is considered to be in normal status.

[0142] When the number of records in the hook function is non-zero, and each item in the random number sieve function has no failed items and the deduplication operation has no duplicates, the API function interface is determined to be of low risk.

[0143] When the number of records in the hook function is non-zero and each item in the random number sieve function has a failed item and the deduplication operation has no duplicates, the API function interface status is determined to be medium risk.

[0144] When the hook function records a non-zero number of times, and each item in the random number sieve function has a failed item and the deduplication operation has duplicates, the API function interface is determined to be of high risk.

[0145] As a further preferred technical solution, the method also includes a step of verifying the compliance of the encryption card interface:

[0146] The compliance of the interfaces was tested in accordance with the requirements of the "Application Interface Specification for Cryptographic Devices GM / T 0018-2012". The types of interfaces tested for compliance included device management interfaces, key management interfaces, asymmetric algorithm interfaces, symmetric algorithm interfaces, hash algorithm interfaces, and file operation interfaces.

[0147] If at least one type of interface call fails or does not exist in the compliance check interface types, the password card interface is deemed non-compliant.

[0148] It should be noted that, since the encryption card is the foundation of security services, all security devices using national cryptographic functions will design their upper-layer cryptographic interface calls in accordance with "0018-2012". Therefore, it is necessary to verify that the API provided by the manufacturer fully complies with this standard and can execute normally. This embodiment implements the verification of the service interface compliance and correctness of the encryption card according to the interface definitions of device management, key management, algorithm (asymmetric / symmetric / hash algorithm), and file operation as described in "Cryptographic Device Application Interface Specification GM / T 0018-2012".

[0149] As a further preferred technical solution, the method also includes a random number compliance detection step:

[0150] Call the random number generation interface of the encryption card to collect a random sequence file of a set size;

[0151] A test thread is created to test the random sequence file. The test items include poker algorithm test items, frequency test items, block frequency test items, overlapping template matching test items, total number of runs test items, run distribution test items, maximum run within a block test items, binary derivation test items, autocorrelation test items, cumulative sum test items, approximate entropy test items, discrete Fourier transform test items, matrix rank test items, linear complexity test items, and compression test items.

[0152] The compliance of random numbers is checked based on the test results of each test item.

[0153] This embodiment implements the quality testing of random numbers for Class E products as described in "Requirements for Random Number Testing of Cryptographic Products GM / T 0062-2018". It accurately converts the mathematical formulas related to the test cases into code flow, and comprehensively judges the quality of random numbers from multiple test results such as distribution, autocorrelation, run length, and compression. The quality judgment of random number sequences generated in the cryptographic card is more rigorous and the judgment result is more accurate.

[0154] Furthermore, as shown in Figure 2, this application embodiment proposes an algorithm security detection system for a cryptographic encryption card. The system includes a container manager, a test container, and an encryption card driver module. The container manager is used to provide a runtime environment for the test container image and to run a daemon process into the test container via the unshare command.

[0155] The test container includes a random private key detection container, which in turn includes an encryption test module, wherein:

[0156] The encryption test module is used to determine that the encryption card has a security risk when there is key reuse in the set random private key value and the second ciphertext can be restored to plaintext based on the plaintext message output by the encryption card and the first ciphertext. The first ciphertext is obtained by encrypting a known plaintext message, and the second ciphertext is obtained by encrypting the target being attacked.

[0157] As a further preferred technical solution, the random private key detection container also includes a signature testing module. The signature testing module is used to determine that there is a security risk in the encryption card when the set random private key value is reused and the signature private key can be successfully restored according to the first signature value and the second signature value output by the encryption card. The first signature value and the second signature value are obtained by signing two sets of known plaintext messages respectively.

[0158] Furthermore, the encryption card driver module includes a VFIO driver architecture and an encryption card driver group, used to drive the encryption card to perform encryption processing. The container manager can be used to manage daemons, enabling operations such as creating, starting, and stopping encryption card test containers. It can also be used to manage clients, communicating with the daemons via a REST API to allow users to control the test containers. Finally, it manages the `unshare` command, running the daemon in an independent test container to isolate the main system from test resources.

[0159] As a further preferred technical solution, the encryption test module is used to restore the plaintext of the second ciphertext using a plaintext restoration function;

[0160] The plaintext restoration function is:

[0161] M′ b =C a2 xor M a xor C b2

[0162] In the formula, M′ b Indicates cracking plaintext, M a This indicates the plaintext message, C a2 This indicates that the first ciphertext contains a ciphertext fragment containing plaintext information, C b2 This indicates that the second ciphertext contains a ciphertext fragment containing plaintext information.

[0163] It should be noted that the encryption test module is used to attempt to crack the plaintext of the ciphertext output by several sets of encryption cards without the recipient's private key, thereby realizing the security test of asymmetric algorithm encryption.

[0164] As a further preferred technical solution, the signature testing module is used to restore the signature private key using a private key restoration function;

[0165] The private key restoration function is:

[0166] d′=(S a -S b ) / (r a -r b )-1

[0167] In the formula, d′ represents the restored signature private key, (r a ,S a ) represents the first signature value, (r b ,S b ) represents the second signature value.

[0168] It should be noted that the signature testing module is used to generate an asymmetric key and to collect the encryption and signature results output by several sets of encryption cards to observe whether there is a regularity in the encryption results. If there is a regularity, the signature private key is derived using the signature value, and the G-point is used to verify whether the derived value is the signature private key, thereby realizing the security detection of asymmetric algorithm signatures.

[0169] It should be noted that the derivation process of the plaintext restoration function and the private key restoration function is detailed in the above method embodiments and will not be repeated here.

[0170] As a further preferred technical solution, the test container also includes an API security detection container, which includes an API security detection program, a security detection library, and a hook function library. The API security detection program is used to call the asymmetric algorithm interface of the encryption card, and uses the security detection library to record the API's trace call interface during loading.

[0171] The hook function library is used to hook basic functions and modify the return value of hook functions so that the return value is a constant or a regular range value.

[0172] As a further preferred technical solution, the test container also includes a compliance test container, which comprises an interface test module and a random number abstraction test module, wherein:

[0173] The interface testing module is used to test the compliance of interfaces in accordance with the requirements of the "Application Interface Specification for Cryptographic Devices GM / T 0018-2012". The interface types for compliance testing include device management interfaces, key management interfaces, asymmetric algorithm interfaces, symmetric algorithm interfaces, hash algorithm interfaces, and file operation interfaces. If at least one type of interface fails to be called or does not exist among the interface types for compliance testing, the cryptographic card interface is determined to be non-compliant.

[0174] The random number abstraction test module is used to call the random number generation interface of the encryption card, extract a random number sequence of a set size, and perform quality testing on the random number sequence in accordance with the requirements of "Random Number Testing Requirements for Cryptographic Products GM / T 0062-2018".

[0175] As a further preferred technical solution, the test container includes a random private key detection container, an API security detection container, and a compliance test container, all of which are equipped with an encryption card API interface library. The encryption card API interface library is used to provide cryptographic service interfaces.

[0176] As a further preferred technical solution, the test container includes a basic library in the random private key detection container, API security detection container and compliance test container.

[0177] It should be noted that both operating systems and open-source software provide software implementations of basic cryptographic algorithms. These implementations are integrated into the operating system through basic software libraries. These libraries provide cryptographic service interfaces for various upper-layer applications, and their computation is performed on the local CPU and memory.

[0178] Specifically, the process of inserting the encryption card into the detection system and then using the detection system to test the security of the encryption card includes:

[0179] (1) Security detection of asymmetric algorithm encryption

[0180] a1: Call the management interface of the detection system to check if the encryption card hardware is in place. If the hardware is in place, proceed to step a2; otherwise, terminate the detection process.

[0181] a2: Create plaintext message M, call the encryption interface of encryption card SM2 to encrypt plaintext message M, and obtain ciphertext A.

[0182] a3: Start the loop execution of the asymmetric algorithm detection subprocess (default 100,000 times):

[0183] a3-1: Randomly generate a 128-byte string and record it as the plaintext message N;

[0184] a3-2: Call the SM2 encryption interface of the encryption card to encrypt the plaintext message N and obtain the ciphertext B;

[0185] a3-3: Compare the contents of segment C1 in ciphertext sequences A and B. If the values ​​are the same, jump to process a3-4; otherwise, jump to a3-1.

[0186] a3-4: Pass message M, ciphertext A and segment C2 of ciphertext B into the plaintext decryption formula function, and return the cracked plaintext N'.

[0187] a3-5: Record the loop value, timestamp, plaintext message N, and cracked plaintext N' to the test log.

[0188] a4: Loop ends, print the encryption security test results.

[0189] The encryption security of asymmetric algorithms is determined based on the encryption security test results, as shown in Table 1.

[0190] Table 1. Security Detection Results of Asymmetric Algorithm Encryption

[0191] (2) Security detection of asymmetric algorithm signatures

[0192] b1: Call the device management interface to check if the encryption card is in place. If the hardware is in place, proceed to step b2; otherwise, terminate the detection process.

[0193] b2: Create a 32-byte digest message M.

[0194] b3: Start the asymmetric algorithm detection subprocess in a loop (default 100,000 times).

[0195] b3-1: Call the SM2 signature interface of the encryption card to obtain the signature S of message M.

[0196] b3-2: Iterate through the signatures in the detection list, pass S and S' (not S) to the private key restoration function, and return the deduced private key d'.

[0197] b3-3: Use d' to calculate the public key P', and compare whether P' is equal to the public key P.

[0198] b3-4: If they are not equal, save the signature S to the list, jump to b3-1, if they are equal, output d' and exit the loop.

[0199] b4: Record the timestamp, loop value, signature S, signature S', and d' to the log file.

[0200] The signature security of asymmetric algorithms is determined based on the signature security test results, as shown in Table 2.

[0201] Table 2. Security Detection Results of Asymmetric Algorithm Signatures

[0202] (3) API security testing

[0203] c1: Load the hook function library into the test process space.

[0204] c2: Iterate through the API's key management and algorithm (asymmetric / symmetric / hash algorithm) class interfaces.

[0205] c2-1: Execute a function call interface.

[0206] c2-2: Check if there are any records of hook function output.

[0207] c2-3: If there is output, add the interface name and the corresponding hook to the detection list file; otherwise, jump to c2-1.

[0208] c4: If the detection list file is empty, jump to c11; otherwise, jump to c5.

[0209] c5: Call the API's random number generation interface to collect 20MB of data.

[0210] c6: Pass data to the random number sieve function.

[0211] c7: Print each test result of the random number sieve.

[0212] c8: Generate a random plaintext message M

[0213] c9: Perform SM2 encryption on message M 100,000 times in a loop, and record the contents of the ciphertext C1 segment in each iteration to a list.

[0214] c10: Performs a deduplication operation on the list and prints the return value.

[0215] c11: Print test results and exit the process.

[0216] The API security assessment results are shown in Table 3.

[0217] Table 3 API security test results

[0218] The function categories in the hook function library are shown in Table 4:

[0219] Table 4 Hook Function Library

[0220] (4) Interface compliance testing

[0221] The test checks whether the interface conforms to the requirements of the "Cryptographic Device Application Interface Specification GM / T 0018-2012". The test includes six types of interfaces. Judgment criteria: If more than one interface call fails or does not exist, the interface is judged as non-compliant.

[0222] The six types of interfaces are as follows:

[0223] Device management class, used to manage encrypted card devices, operation permissions and sessions.

[0224] The key management class is used for key pair generation, key import and export, and digital envelope functionality.

[0225] Asymmetric algorithm class used for RSA / ECC computation, signature, and verification.

[0226] Symmetric algorithm class, used for symmetric encryption, symmetric decryption and MAC calculation.

[0227] Hash algorithm class, a three-part interface for hash operations.

[0228] File operation class, used for creating, reading, writing and deleting files within the encrypted card.

[0229] (5) Random number compliance test

[0230] my country's random number testing standards for cryptographic devices are very strict. The NIST and other general tests used in this embodiment cannot meet the requirements. Random number quality testing should be carried out for Class E products in the "Random Number Testing Requirements for Cryptographic Products GM / T 0062-2018".

[0231] d1: Automatically call the encryption card's "random number generation interface" to collect a 128MB random sequence.

[0232] d2: Input a random sequence file and create a unit test thread for each test item.

[0233] d3: Executes test threads in parallel and records test data for each unit.

[0234] d4: Automatically counts unit tests and outputs the test results.

[0235] Judgment criteria: If none of the test items are qualified, the test item is deemed unqualified; when more than three items are unqualified, the randomness test is deemed unqualified.

[0236] The random number unit detection item is shown in Table 5:

[0237] Table 5 Random Number Unit Detection Items

[0238] The test output is as follows:

[0239]

[0012] Discrete Fourier Transform (Algorithm time: 1835812US)

[0240] : 0 non-compliant (including 0 re-inspections); pass rate 100.00%; value distribution 0.468120. Result: YES

[0241]

[0013] Matrix rank (algorithm time: 374029us)

[0242] m,q=32: 2 non-compliant (including 0 re-inspections); pass rate 97.01%; 9-value distribution 0,680539. Result: YES

[0243]

[0014] Maurer statistics (algorithm time: 8601s)

[0244] l=7, q=1280: 1 non-compliant (including 0 re-inspections); pass rate 98.51%; q-value distribution 0.468120. Result: YES

[0245]

[0015] Linear complexity (algorithm time: 740045uS)

[0246] m=500: 0 non-compliant (including 0 re-inspections); pass rate 100.00%; q-value distribution 0.131642. Result: YES

[0247] m=1000: 1 non-compliant (including 0 re-inspections); pass rate 98.51%; q-value distribution 0.998785. Result: YES

[0248]

[0249] Significance level: p-value 0.01, q-value distribution 0.0001

[0250] Maximum number of non-conforming items: 3 (limit 3)

[0251] Block bit length: 1,000,000

[0252] Valid count: 67

[0253] Number of re-examinations: 0

[0254] Algorithm time: 4419155 US

[0255] Test result: Passed

[0256]

[0257] It should be noted that other embodiments or implementation methods of the algorithm security detection system for the cryptographic encryption card described in this application can refer to the above-mentioned method embodiments, and will not be repeated here.

[0258] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0259] The various component embodiments of this application can be implemented in hardware, or as software modules running on one or more processors, or a combination thereof. Those skilled in the art will understand that microprocessors or digital signal processors (DSPs) can be used in practice to implement some or all of the functions of some or all of the components in the computing processing device according to the embodiments of this application. This application can also be implemented as a device or apparatus program (e.g., a computer program and computer program product) for performing part or all of the methods described herein. Such an implementation of this application can be stored on a computer-readable medium, or can be in the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.

[0260] For example, Figure 3 illustrates a computing processing device that can implement the method according to this application. This computing processing device conventionally includes a processor 1010 and a computer program product or computer-readable medium in the form of a memory 1020. The memory 1020 can be an electronic memory such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM. The memory 1020 has a storage space 1030 for program code 1031 for performing any of the method steps described above. For example, the storage space 1030 for the program code may include various program codes 1031 for implementing the various steps in the methods described above. These program codes can be read from or written to one or more computer program products. These computer program products include program code carriers such as hard disks, compact discs (CDs), memory cards, or floppy disks. Such computer program products are typically portable or fixed storage units as described with reference to Figure 4. This storage unit may have storage segments, storage spaces, etc., arranged similarly to the memory 1020 in the computing processing device of Figure 3. The program code may be compressed, for example, in a suitable form. Typically, the storage unit includes computer-readable code 1031', which is code that can be read by a processor such as 1010, which, when run by a computing processing device, causes the computing processing device to perform the various steps in the method described above.

[0261] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0262] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "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.

[0263] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0264] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method for detecting the algorithm security of a cryptographic card, wherein, The method comprises: receiving first and second ciphertexts output by the encryption card, the first ciphertext being obtained by encrypting a known plaintext message, and the second ciphertext being obtained by encrypting an attack target; setting a random private key value to exist key reuse, and determining whether the second ciphertext can be restored to the attack target according to the plaintext message and the first ciphertext; if yes, determining that the encryption card algorithm security detection result is a security risk; if no, determining that the encryption card algorithm security detection result is normal.

2. The method of claim 1, wherein the algorithm security of the password encryption card is detected by using a predetermined algorithm. The setting of the random private key value to exist key reuse and the determination of whether the second ciphertext can be restored to the attack target according to the plaintext message and the first ciphertext comprise: determining, based on the random private key value and an encryption public key, a ciphertext segment containing plaintext information in the first ciphertext and a ciphertext segment containing plaintext information in the second ciphertext; attempting to restore the plaintext corresponding to the second ciphertext according to the plaintext message, the ciphertext segment containing plaintext information in the first ciphertext, and the ciphertext segment containing plaintext information in the second ciphertext, using a plaintext restoration function, wherein the plaintext restoration function is: M' b = C a2 xor M a xor C b2 where M' = M b represents the plaintext message, C a represents the plaintext message, C a2 represents the ciphertext segment of the first ciphertext that contains plaintext information, C b2 represents the ciphertext segment of the second ciphertext that contains plaintext information.

3. The algorithm security detection method for the cryptographic encryption card as described in claim 1, wherein, The method further comprises: receiving first and second signature values output by the encryption card, the first and second signature values being obtained by signing two groups of known plaintext messages, respectively; setting a random private key value to exist key reuse, and determining whether the signature private key can be successfully restored according to the first and second signature values; if yes, determining that the encryption card algorithm security detection result is a security risk; if no, determining that the encryption card algorithm security detection result is normal.

4. The algorithm security detection method for the cryptographic encryption card as described in claim 3, wherein, The setting of the random private key value to exist key reuse and the determination of whether the signature private key can be successfully restored according to the first and second signature values comprise: attempting to restore the signature private key according to the first and second signature values, using a private key restoration function, wherein the private key restoration function is: calculating a derivation result P' of a signature public key according to the restored signature private key, and determining that the signature private key is successfully restored when the derivation result P' of the signature public key is equal to the real signature public key P. d' = (S a - S b ) / (r a - r b )-1 wherein d' represents the reduced signature private key, (r a , S a ) represents the first signature value, (r b , S b ) represents the second signature value; The method further comprises:

5. The algorithm security detection method for the cryptographic encryption card as described in claim 1, wherein, traversing key management and algorithm interfaces in an encryption card API function interface, adding the interface names of the key management and algorithm interfaces and the corresponding hook functions to a detection list file; when the detection list file is empty, directly outputting a test result, otherwise calling a random number interface of the API to collect data of a set size and inputting the data into a random number sieve function to obtain each detection result of the random number sieve function; generating a random plaintext message M; encrypting the message M N times in a loop, and recording the content of each ciphertext C1 segment to the detection list file; performing a deduplication operation on the content of the ciphertext C1 segment in the detection list file, and modifying the return value of the hook function; detecting the security of the API function interface according to the number of hook function records, each detection result of the random number sieve function, and whether there is repetition in the deduplication operation. ​ 6. The method for detecting the algorithm security of a password encryption card according to claim 5, wherein, The security of the API function interface is detected according to the number of hook functions, each detection result of the random number sieve function, and whether there is repetition in the deduplication operation, including: When the number of hook functions is zero, it is determined that the API function interface state is normal; When the number of hook functions is nonzero and each detection result of the random number sieve function has no failed item and the deduplication operation has no repetition, it is determined that the API function interface state is low risk; When the number of hook functions is nonzero and each detection result of the random number sieve function has a failed item and the deduplication operation has no repetition, it is determined that the API function interface state is medium risk; When the number of hook functions is nonzero and each detection result of the random number sieve function has a failed item and the deduplication operation has a repetition, it is determined that the API function interface state is high risk.

7. The algorithm security detection method for the cryptographic encryption card as described in claim 1, wherein, The method further includes: According to the requirements of the "Cryptographic Device Application Interface Specification GM / T 0018-2012", the interface compliance is detected, wherein the interface types of compliance detection include device management interface, key management interface, asymmetric algorithm interface, symmetric algorithm interface, hash algorithm interface and file operation interface; When at least one type of interface fails to call or does not exist in the interface types of compliance detection, it is determined that the cryptographic card interface is not compliant.

8. The method of claim 1, wherein the algorithm security of the password encryption card is detected by using a predetermined algorithm. The method further includes: Calling the random number generation interface of the encryption card to collect a random sequence file of a set size; Creating a test thread to test the random sequence file, wherein the test items include poker algorithm test item, frequency test item, block frequency test item, overlapping template matching test item, run total test item, run distribution test item, fast inner maximum run test item, binary derivation test item, autocorrelation test item, cumulative sum test item, approximate entropy test item, discrete Fourier transform test item, matrix rank test item, linear complexity test item and compression test item; According to the test results of each test item, the random number compliance is detected.

9. A system for detecting algorithmic security of a cryptographic card, wherein, The system includes a container manager, a test container and an encryption card driver module, the container manager is used to provide a running environment for a test container image, and a daemon process is run to the test container through an unshare command; The test container includes a random private key detection container, and the random private key detection container includes an encryption test module, wherein: The encryption test module is configured to determine that the encryption card has a security risk when a set random private key value exists key reuse and the second ciphertext can be restored to plaintext according to the plaintext message output by the encryption card and the first ciphertext, wherein the first ciphertext is obtained by encrypting the known plaintext message, and the second ciphertext is obtained by encrypting the target under attack.

10. The algorithm security detection system of the cryptographic card of claim 9, wherein, The random private key detection container further includes a signature test module, and the signature test module is configured to determine that the encryption card has a security risk when a set random private key value exists key reuse and the signature private key can be successfully restored according to the first signature value and the second signature value output by the encryption card, wherein the first signature value and the second signature value are obtained by signing two groups of known plaintext messages, respectively.

11. The algorithm security detection system of the cryptographic card of claim 9, wherein, The encryption test module is configured to restore the plaintext of the second ciphertext by using a plaintext restoration function. ​ The plaintext restoration function is: M' b = C a2 xor M a xor C b2 where M' = M - C b represents the plaintext message, C a represents the known plaintext message, C a2 represents the ciphertext segment of the first ciphertext that contains plaintext information, C b2 represents the ciphertext segment of the second ciphertext that contains plaintext information.

12. The algorithm security detection system of the cryptographic card of claim 10, wherein, The signature test module is configured to restore the signature private key by using a private key restoration function. The private key restoration function is: d' = (S a - S b ) / (r a - r b )-1 where d' represents the reduced private key, (r a , S a ) represents the first signature value, and (r b , S b ) represents the second signature value.

13. The algorithm security detection system of the cryptographic card of claim 9, wherein, The test container further comprises an API security detection container, which comprises an API security detection program, a security detection library, and a hook function library. The hook function library is configured to perform hooking operation on a basic function and modify the return value of the hook function, so that the return value has a characteristic rule.

14. The algorithm security detection system of the cryptographic card of claim 9, wherein, The test container further comprises a compliance test container, which comprises an interface test module and a random number abstraction test module. The interface test module is configured to detect the interface compliance according to the requirements of the “Cryptographic Device Application Interface Specification GM / T 0018-2012”, wherein the interface types for compliance detection include device management interfaces, key management interfaces, asymmetric algorithm interfaces, symmetric algorithm interfaces, hash algorithm interfaces, and file operation interfaces. The random number abstraction test module is configured to call the random number generation interface of the cryptographic card, extract a random number sequence of a set size, and perform quality detection on the random number sequence according to the requirements of the “Cryptographic Product Random Number Detection Requirements GM / T 0062-2018”.

15. The algorithm security detection system of the cryptographic card of claim 9, wherein, The test container comprises a random private key detection container, an API security detection container, and a compliance test container, each of which is provided with a cryptographic card API interface library. ​ 16. A computing processing device, wherein, comprises: a memory in which computer readable code is stored; one or more processors, when the computer readable code is executed by the one or more processors, the computing processing device performs the algorithm security detection method of the cryptographic encryption card according to any one of claims 1-8.

17. A computer program comprising computer readable code which, when run on a computing processing device, causes the computing processing device to perform the algorithm security detection method of the cryptographic encryption card according to any one of claims 1-8.

18. A computer readable storage medium having stored thereon a computer program, wherein, The computer program is executed by the processor to implement the algorithm security detection method of the cryptographic encryption card according to any one of claims 1-8.

Images