A protection method, device and system of a group white-box cryptographic algorithm and a storage medium

Abstract

This application discloses a protection method, apparatus, system, and storage medium for block white-box cryptographic algorithms, relating to the field of information security technology. The method includes: inserting a first preset number of pseudo-operations into two arbitrarily related real cryptographic operations during the execution of a block white-box cryptographic algorithm according to a preset insertion order, obtaining an operation set; cyclically executing each sub-operation in the operation set to obtain multiple operation results; the sub-operations are either real cryptographic operations or pseudo-operations; determining the first and second operation results of the two real cryptographic operations from the multiple operation results according to the preset insertion order; verifying the first and second operation results to obtain a target verification result; if the target verification result indicates that the first and second operation results are inconsistent, determining that the execution flow corresponding to the two real cryptographic operations is abnormal, and performing protection operations.

Description

Technical Field

[0001] This application relates to the field of information security technology, and in particular to a protection method, device, system and storage medium for block white-box cryptographic algorithms. Background Technology

[0002] In numerous fields such as financial payments, digital content protection, and software encryption, there exists a core security requirement: how to perform cryptographic operations in a completely untrusted environment (e.g., a user's mobile smart terminal) while ensuring that the keys used cannot be extracted by malicious attackers. In such environments, attackers have complete control over the software execution process, enabling them to perform static code analysis, dynamic debugging, set breakpoints, and monitor memory and register states. This attack model is known as a "white-box attack environment." To address the threat of these white-box attacks, block white-box cryptographic algorithms have emerged. Their core idea is no longer simply storing and protecting key data, but rather breaking down, encoding, and hiding the key information throughout the entire implementation of the cryptographic algorithm. This implementation employs techniques based on lookup tables (LUTs) and affine transformation coding, transforming each round of computation in a cryptographic algorithm (such as AES or DES) into a series of large, randomized lookup table networks. The key is deeply embedded in these lookup tables, making it difficult for attackers to directly deduce the original key even if they reverse-engineer the contents of all the lookup tables. However, in the above-mentioned algorithm execution flow that relies on pre-obfuscated lookup tables, the execution path is fixed and unchanging. This makes it vulnerable to side-channel attacks, which can use statistical analysis of the execution path to obtain the operational patterns of the computational trajectory and attack and crack the key. It is also highly susceptible to fault injection attacks, greatly reducing the ability to protect information. Summary of the Invention

[0003] This invention provides a method, apparatus, system, and storage medium for protecting against block cipher algorithms (white-box cryptography), thereby at least addressing the problem in related technologies where the deterministic execution path and lack of redundant verification make it difficult to effectively resist related fault injection attacks simultaneously. The technical solution of this invention is as follows:

[0004] According to a first aspect of the present invention, a protection method for a block white-box cryptographic algorithm is provided. The method includes: inserting a first preset number of pseudo-operations into two arbitrarily associated real cryptographic operations during the execution of the block white-box cryptographic algorithm according to a preset insertion order to obtain an operation set; cyclically executing each sub-operation in the operation set to obtain multiple operation results; wherein the sub-operations are real cryptographic operations or pseudo-operations; determining a first operation result and a second operation result of the two real cryptographic operations from the multiple operation results according to the preset insertion order; verifying the first operation result and the second operation result to obtain a target verification result; if the target verification result indicates that the first operation result and the second operation result are inconsistent, determining that the execution flow corresponding to the two real cryptographic operations is abnormal, and performing protection operations.

[0005] In one implementation, verifying the first operation result and the second operation result includes: determining that the operation paths of the two real cryptographic operations are the same, and performing isomorphic verification on the first operation result and the second operation result; or, determining that the operation paths of the two real cryptographic operations are different, and performing heterogeneous verification on the first operation result and the second operation result.

[0006] In another implementation, isomorphic verification is performed on the first and second operation results, including: identifying a second preset number of first operation nodes in the first target sub-operation that produces the first operation result, and a second preset number of second operation nodes in the second target sub-operation that produces the second operation result; verifying the consistency of the algorithm execution flow of the second preset number of first operation nodes and the second preset number of second operation nodes to obtain a first verification result; determining a first comparison result between the first and second operation results; and determining a target verification result indicating whether the execution flow corresponding to the two real cryptographic operations is abnormal based on the first comparison result and the first verification result.

[0007] In another implementation, the two real cryptographic operations are an encryption operation and a decryption operation, respectively. Heterogeneous verification is performed on the first operation result and the second operation result, including: determining that the first operation result is an encryption operation result, comparing the first input of the first operation result with the second operation result to obtain a second comparison result, so as to determine the target verification result indicating whether the execution flow corresponding to the two real cryptographic operations is abnormal based on the second comparison result; or, determining that the second operation result is an encryption operation result, comparing the second input of the second operation result with the first operation result to obtain a third comparison result, so as to determine the target verification result indicating whether the execution flow corresponding to the two real cryptographic operations is abnormal based on the third comparison result.

[0008] In another implementation, the various sub-operations in the operation set are executed cyclically to obtain multiple operation results. This includes: using a main counter to control the cyclic iteration of each sub-operation in the operation set; the increment step of the main counter is generated using a non-linear increment function; using an auxiliary counter to record the number of times each sub-operation in the operation set is executed during the cyclic execution; the counting update rule of the auxiliary counter is different from that of the main counter, and the counting update rule of the auxiliary counter is constructed based on a complex arithmetic sequence and a first preset quantity or based on a hash accumulation value associated with the cyclic execution operation, and the auxiliary counter is decoupled from the main counter; at the end of the cyclic execution, it is verified whether the final count value of the auxiliary counter is the same as the expected count value.

[0009] In another implementation, the method further includes inserting a preset delay instruction between each sub-operation in the cyclic execution set to delay the execution time of each sub-operation.

[0010] In another implementation, the first correlation between the operation structure and energy consumption characteristics of the pseudo-operation is less than the second correlation between the operation structure and energy consumption characteristics of the real cryptographic operation; the first correlation characterizes the correlation between the intermediate value of the operation and the energy consumption of the pseudo-operation; the second correlation characterizes the correlation between the intermediate value of the operation and the energy consumption of the real operation.

[0011] According to a second aspect of the present invention, a protection device for a block white-box cryptographic algorithm is provided. The protection device comprises: an insertion unit, configured to insert a first preset number of pseudo-operations into two arbitrarily associated real cryptographic operations during the execution of the block white-box cryptographic algorithm according to a preset insertion order, to obtain an operation set; a loop execution unit, configured to loop execution of each sub-operation in the operation set to obtain multiple operation results; wherein the sub-operations are real cryptographic operations or pseudo-operations; a verification unit, configured to determine a first operation result and a second operation result of the two real cryptographic operations from the multiple operation results according to a preset insertion order; the verification unit is further configured to verify the first operation result and the second operation result to obtain a target verification result; and a protection unit, configured to determine that the execution flow corresponding to the two real cryptographic operations is abnormal if the target verification result indicates that the first operation result and the second operation result are inconsistent, and to perform a protection operation.

[0012] According to a third aspect of the present invention, a protection system for block white-box cryptographic algorithms is provided, the system being configured to perform a protection method for block white-box cryptographic algorithms as described in the first aspect and any possible implementation thereof.

[0013] According to a fourth aspect of the present invention, an electronic device is provided, comprising: a processor and a memory for storing processor-executable instructions; wherein the processor is configured to execute the executable instructions to implement a protection method for a block white-box cryptographic algorithm as described in the first aspect and any possible implementation thereof.

[0014] According to a fifth aspect of the present invention, a computer-readable storage medium is provided, on which instructions are stored, which, when executed by a processor of an electronic device, enable the electronic device to perform a protection method for a block white-box cryptographic algorithm as described in the first aspect and any possible implementation thereof.

[0015] According to a sixth aspect of the present invention, a computer program product is provided, the computer program product including computer instructions, which, when executed on an electronic device, cause the electronic device to execute the protection method of the block white-box cryptographic algorithm described in the first aspect and any possible implementation thereof.

[0016] The technical solution provided by this invention brings at least the following beneficial effects: On the one hand, by introducing pseudo-operations into two real cryptographic operations, the mixing of real and pseudo-operations disrupts the energy consumption trajectory alignment required for side-channel attacks, significantly reduces the signal-to-noise ratio of statistical execution path trajectory analysis, and renders the statistical correlation on which differential calculation analysis relies in the attack process ineffective, thereby improving the ability to protect information. On the other hand, by setting two associated real cryptographic operations in the execution process of the block white-box cryptography algorithm, and performing double verification based on the results of the two associated real cryptographic operations, inconsistencies caused by a single fault injection will be detected, ensuring that any single point of failure will be detected immediately, and protection can be implemented to block the output. This directly prevents the output of erroneous ciphertext material that may be used for fault injection attacks, greatly improving the ability to protect information.

[0017] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application, and do not constitute an undue limitation of this application.

[0019] Figure 1 This is a flowchart illustrating a method for protecting against block white-box cryptographic algorithms according to an exemplary embodiment;

[0020] Figure 2 This is a block diagram illustrating a protection device for a block white-box cryptographic algorithm according to an exemplary embodiment;

[0021] Figure 3 This is a schematic diagram of an electronic device according to an exemplary embodiment. Detailed Implementation

[0022] To enable those skilled in the art to better understand the technical solutions of this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0023] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0024] Before providing a detailed description of the protection method for block white-box cryptography algorithms provided in the embodiments of this application, a brief introduction will be given to the application scenarios and implementation environments involved in the embodiments of this application.

[0025] First, a brief introduction to the application scenarios involved in this application will be given.

[0026] Attackers can completely observe or execute the execution process of cryptographic software. In this environment, attackers can easily obtain key information. Simply protecting the key is no longer sufficient to achieve the desired protection effect; therefore, special measures are needed to hide the key information within the implementation of the cryptographic algorithm. The goal of white-box cryptography is to protect the key in a white-box attack environment by hiding the key information, preventing attackers from extracting the key during the execution of the cryptographic software. Therefore, white-box cryptography technology is becoming increasingly important and has received widespread attention.

[0027] The basic idea behind white-box cryptography security testing is to apply gray-box attack techniques to attacks implemented in white-box cryptography. By combining side-channel attacks and fault injection attacks, it attempts to recover key information. This testing method mainly includes two typical attack techniques: differential computation attacks and fault injection attacks (FIA).

[0028] First is the Differential Computation Analysis (DCA, also known as a side-channel attack). This attack uses binary analysis of white-box cryptography to track and analyze the execution process of the algorithm, extracts and records the leaked data in the operation as side-channel information, and extracts and records the data in the algorithm operation process as side-channel information to achieve side-channel attack and detection.

[0029] Secondly, there is the fault injection attack, which simulates the execution of a white-box cryptographic binary executable program and injects and modifies the values ​​of registers during execution, thereby achieving a fault injection attack on the software and recording the erroneous results.

[0030] By applying the aforementioned side-channel attacks and fault injection attacks, the security of white-box cryptographic implementations can be effectively evaluated, and their ability to resist real-world threat models can be verified. These attack methods constitute the core content of the white-box cryptographic security evaluation system, and have significant theoretical and practical implications for discovering security vulnerabilities at the implementation level and verifying the effectiveness of protection mechanisms.

[0031] To address the aforementioned issues, this application proposes a protection method for block cipher algorithms. By adding two verification operations and integrating pseudo-operation and pseudo-feature protection designs, the basic protection capability of the white-box cryptographic scheme against differential computation attacks and basic fault injection attacks is improved. Furthermore, this scheme is not limited to a specific algorithm but is applicable to all block cipher algorithms. Based on the above comprehensive protection scheme, the main loop logic part also incorporates multiple loop logic checks, effectively enhancing the white-box cryptographic scheme's protection against advanced multiple fault injection attacks.

[0032] For ease of understanding, the protection method of the block white-box cryptographic algorithm provided in this application will be described in detail below with reference to the accompanying drawings.

[0033] Figure 1 This is a flowchart illustrating a protection method for a block white-box cryptographic algorithm according to an exemplary embodiment. The protection method for the block white-box cryptographic algorithm is specifically implemented through the following steps.

[0034] S11. According to the preset insertion order, insert a first preset number of pseudo-operations into any two real cryptographic operations that are associated during the execution of the block white-box cryptography algorithm to obtain the operation set.

[0035] Two real cryptographic operations may have the same operation path or different operation paths but are complementary and correspond to each other.

[0036] The preset insertion order can be set between two real cryptographic operations, before two real cryptographic operations, and / or after two real cryptographic operations.

[0037] Parallel setup with two real cryptographic operation paths being identical.

[0038] Two serial settings with different actual cryptographic operation paths.

[0039] Based on this step, a first protection strategy is constructed through two verification checks, which enhances the system's fault tolerance and security. Given that a certain operation may be affected by a fault injection attack, due to the existence of a supplementary second operation, the system can refuse to output an erroneous result when the two results are inconsistent. This effectively prevents key information from being leaked through erroneous ciphertext, significantly reducing the risk of differential fault analysis.

[0040] S12 executes each sub-operation in the set of operations in a loop to obtain multiple operation results.

[0041] Suboperations can be either real cryptographic operations or pseudo-operations.

[0042] Based on this step, a second protection strategy was constructed using a hybrid protection mechanism of real and pseudo-operations. This mechanism introduces multiple computational loops, embedding only two real cryptographic operations (operations on the same path or operations on different paths) within an execution sequence containing N total operations, while the rest are pseudo-operations with similar structural and power consumption characteristics. All operations are uniformly distributed in time, and the positions of the real operations are randomly selected each time they are executed, following a uniform distribution.

[0043] Based on this second protection strategy, the uncertainty of the actual computation's position on the timeline makes it difficult for attackers to align the effective power consumption trajectory across multiple executions. This reduces the probability of observing the actual computation at any fixed time point to 2 / N (and to 1 / N for different path computations). This trajectory alignment misalignment significantly weakens the signal-to-noise ratio of statistical analysis, increasing the difficulty of side-channel attacks. Simultaneously, it can be seen that schemes using different path computations are superior to schemes using the same path computations in terms of protection against differential computation attacks.

[0044] Simultaneously, this mechanism enhances robustness against fault injection attacks (FIA). Attackers cannot predict the exact timing of the actual computation, making it difficult to precisely inject faults at critical computational stages to obtain valid error information. The randomly distributed timing of the actual computation forces attackers to attempt to inject faults at every stage of the computation, which not only significantly increases the number of attempts required for the attack but also raises the probability of being detected by the system's detection mechanisms.

[0045] This hybrid true / false operation mechanism effectively achieves dual protection against side-channel analysis and fault injection attacks by introducing spatiotemporal randomness and redundant computation, thereby enhancing the security of the cryptographic module.

[0046] S13, based on the preset insertion order, determine the first and second operation results of two real cryptographic operations from multiple operation results.

[0047] S14, verify the first and second operation results to obtain the target verification result.

[0048] As a verification method, to determine that the operation paths of two real cryptographic operations are the same, isomorphic verification is performed on the first and second operation results.

[0049] As another verification method, it is determined that the operation paths of the two real cryptographic operations are different, and heterogeneous verification is performed on the first operation result and the second operation result.

[0050] The isomorphic operation paths of the two real cryptographic operations are set in parallel.

[0051] The heterogeneous operation paths of the two real cryptographic operations are set sequentially.

[0052] The above two verification methods under the first protection strategy can be divided into the following two categories.

[0053] The first type of verification is based on two repeated operations along the same path. This mechanism can be further enhanced into a multi-step Intra-Operation Consistency Check, which compares each execution stage within the white-box cryptographic algorithm to achieve comprehensive detection of the integrity and logical correctness of the algorithm's execution flow, thus achieving full-process and multi-stage coverage.

[0054] In this verification method, internal consistency is verified through two operations.

[0055] The second type of verification is based on two independent computational operations—Final Output Validation. This mechanism employs heterogeneous computational paths; for example, the first computation might be an encryption operation, and the second might be a corresponding decryption operation. A verification module, isolated from the main computational path or using a different implementation, recalculates or verifies the correctness of the final result. This not only enhances the ability to detect faults but also increases the difficulty for attackers to simultaneously compromise both independent paths, thereby further improving overall security.

[0056] Furthermore, the above isomorphic verification is implemented through the following steps.

[0057] First, identify the first operation nodes of the second preset number in the first target sub-operation that produces the first operation result, and the second operation nodes of the second target sub-operation that produces the second operation result.

[0058] Secondly, the consistency of the algorithm execution flow of the second preset number of first computing nodes and the second preset number of second computing nodes is verified to obtain the first verification result.

[0059] Third, determine the first comparison result between the first operation result and the second operation result.

[0060] Fourth, based on the first comparison result and the first verification result, determine the target verification result that indicates whether the execution flow corresponding to the two real cryptographic operations is abnormal.

[0061] Furthermore, the two actual cryptographic operations are encryption and decryption, and the above heterogeneous verification is implemented in the following two ways.

[0062] In the first implementation, the first operation result is determined to be the encryption operation result. The first input of the first operation result is compared with the second operation result to obtain the second comparison result. Based on the second comparison result, the target verification result indicating whether the execution process corresponding to the two real cryptographic operations is abnormal is determined.

[0063] In the second implementation, the second operation result is determined to be the encryption operation result. The second input of the second operation result is compared with the first operation result to obtain a third comparison result. Based on the third comparison result, a target verification result is determined to indicate whether the execution process corresponding to the two real cryptographic operations is abnormal.

[0064] S15, if the target verification result indicates that the first operation result and the second operation result are inconsistent, determine that the execution process corresponding to the two real cryptographic operations is abnormal, and perform protection operations.

[0065] Through the above implementation methods, on the one hand, by introducing pseudo-operations into the two real cryptographic operations, the mixing of real and pseudo-operations disrupts the energy consumption trajectory alignment required for side-channel attacks, significantly reduces the signal-to-noise ratio of statistical execution path trajectory analysis, and renders the statistical correlation on which differential calculation analysis relies in the attack process ineffective, thereby improving the information protection capability. On the other hand, by setting two associated real cryptographic operations in the execution flow of the block white-box cryptography algorithm, and performing double verification based on the results of the two associated real cryptographic operations, inconsistencies caused by a single fault injection will be detected, ensuring that any single point of failure will be detected immediately and protection can be implemented to block the output. This directly prevents the output of erroneous ciphertext material that may be used for fault injection attacks, thus preventing the output of erroneous ciphertext and greatly improving the information protection capability.

[0066] As a refinement and extension of the specific implementation of the above embodiments, in order to fully illustrate the specific implementation process of this embodiment, this application provides another protection method for block white-box cryptography algorithms.

[0067] In some embodiments, the specific process of cyclically executing each sub-operation in step S12 above is as follows.

[0068] First, a master counter is used to control the iterative execution of each sub-operation in the set of operations.

[0069] The increment step size of the master counter is generated using a non-linear increment function.

[0070] Secondly, an auxiliary counter is used to record the number of times each sub-operation in the set of operations is executed during the loop execution process.

[0071] The counting update rules for the auxiliary counter are different from those for the main counter.

[0072] The counting update rule of the auxiliary counter is constructed based on a complex arithmetic sequence and a first preset quantity or based on the hash accumulation value associated with the loop execution operation. The auxiliary counter is decoupled from the main counter.

[0073] Third, at the end of the loop execution, check whether the final count value of the auxiliary counter is the same as the expected count value.

[0074] In this implementation, an integrity protection mechanism is achieved based on a loop of dual counters.

[0075] In the context of combating fault injection attacks, protecting loop structures in cryptographic algorithm implementations is crucial. Attackers may inject by modifying register values ​​to induce abnormal processor states, thereby achieving unintended manipulation of loop structures. This can manifest as: the loop body being completely skipped; the number of loop iterations being partially reduced or increased; or the loop remaining unaffected and executing normally.

[0076] Although the attack ultimately needs to use the tampered cryptographic operation results (such as AES encryption and decryption output) for differential fault analysis, its effectiveness is highly dependent on the deviation of a specific execution path, especially asymmetric fault injection attacks in encryption and decryption operations.

[0077] In the embodiments of this application, a loop operation involving encryption and decryption is considered, and the possible fault injection attacks it may suffer can be summarized into four categories.

[0078] In case (1), the encryption operation is skipped and the decryption is performed normally.

[0079] In scenario (2), encryption is performed normally, but decryption is skipped.

[0080] In scenario (3), both encryption and decryption are skipped.

[0081] In scenario (4), both encryption and decryption are executed normally.

[0082] From the perspective of the effectiveness of DFA attacks, only when the encryption process is executed and its result is injected with faults does the resulting erroneous ciphertext have analytical value. In the above scenarios (1) and (3), the output results are of no use to the attacker because the encryption process is missing. Scenario (4) is a normal operation and does not generate faulty data. Only scenario (2), where encryption is normal but decryption is skipped, can generate erroneous output that can be used for DFA under specific conditions. However, implementing such an attack requires meeting stringent conditions: the attacker must simultaneously carry out precise and coordinated multiple fault injection attacks on the AES core algorithm, the loop control logic (implementing partial skipping), and the final result comparison and judgment logic, which is technically difficult and costly.

[0083] In a specific cryptographic algorithm implementation architecture, if an attacker intends to use fault injection techniques to achieve effective differential fault analysis, the key to success lies in precisely manipulating the algorithm execution flow to produce erroneous outputs with analytical value. Specifically, when the system design relies on two independent ALG operations (denoted as ALG1 and ALG2) and their subsequent result verification logic, the attacker must ensure that the fault injection attack pattern can bypass the system's inherent consistency checks.

[0084] The above scheme is still susceptible to attack, and there are two feasible multiple fault injection attack strategies.

[0085] Synchronous Dual-Core Operation Fault Injection: The attacker applies fault pulses of equal strength and pattern to both the first cryptographic algorithm operation (ALG1) and the second cryptographic operation (ALG2). This synchronous injection aims to produce predictable and identical error states in both ALG operations, making it impossible for the final comparison logic (typically used to verify the consistency of the two operation results) to detect the difference. Consequently, the erroneous output containing valid fault information is misjudged as "correct" and released. This strategy requires extremely high injection timing precision and physical condition control.

[0086] Triple-Correlated Fault Injection Attack: This strategy is more complex, involving coordinated attacks on three different targets.

[0087] The first injection: targeting the core cryptographic operation unit, that is, injecting a fault into the successful first ALG operation (ALG1) to produce an incorrect intermediate or final result.

[0088] The second injection: targeting loop control logic, this involves precisely injecting to cause partial skipping of the loop iteration process. For example, it can cause the second ALG operation (ALG2) or its critical part in the loop body to be skipped, thereby preventing normal verification of the first incorrect result.

[0089] The third layer of injection targets the final result verification and decision module, injecting faults to interfere with or tamper with the execution flow or output of comparison operations (such as array equality checks). Its purpose is to ensure that even if inconsistencies exist, the system incorrectly determines the result as "valid" and allows its output.

[0090] While the aforementioned triple injection attack is theoretically feasible, its successful implementation places extremely stringent demands on the attacker: not only must the attacker accurately determine the timing, attack registers, and interference intensity of the three independent fault injections, but they must also ensure a high degree of coordination among the three to achieve the attack objective. Therefore, the practical operation of such attacks is difficult and resource-intensive.

[0091] Therefore, to improve the overall security of the system, it is still necessary to implement proactive protection for loop structures. This paper proposes a loop integrity verification scheme based on a dual-counter mechanism, which aims to ensure that the loop body (especially the encryption and decryption operations within it) is executed completely and correctly a specified number of times.

[0092] To enhance the master counter (Index), the loop variable (index++) with an increment step of 1, as used in related techniques, is abandoned. Instead, a discontinuous, non-linear, or larger step increment pattern (such as index += k, k>1) is adopted. This increases the difficulty for attackers to precisely control the loop termination condition.

[0093] For example, For(i=0;i<10;i++). Where i is 0, i->1, i->2 (injection), i->8, implement skipping.

[0094] For(i=k;i<10k;i=i+k). Among them, I is 0, i->k, i->2k (injection), i->2k-1.

[0095] Furthermore, an auxiliary integrity counter is introduced. An independent, logically decoupled auxiliary counter is added within the loop body. The update rule for this counter is designed as a non-trivial function (e.g., based on a complex arithmetic sequence, pseudo-random increments, or hash accumulation associated with loop body operations), ensuring that its final value strictly corresponds to the expected execution round. The initial value, update function, and expected final value of this counter should all be protected using white-boxing or obfuscation techniques.

[0096] Furthermore, post-loop verification is performed. After the loop terminates normally, the final value of the auxiliary counter is verified. If its value does not match the pre-calculated expected value, it is determined that the loop execution process has been interfered with by a fault injection attack. The system should immediately enter a fail-safe state, clear sensitive information, and refuse to output results. In addition, similar counters or redundant verification mechanisms can be applied to the logic used to compare array equality after the loop to prevent fault injection attacks on this judgment branch and ensure the reliability of result verification.

[0097] If the above i is affected, the loop will be affected.

[0098] For example, in the code `For(i=0;i<10;i++){counter = counter +5;}`, not only `i` is validated, but also `counter`. Therefore, for an attacker, it's not enough to just inject `i`; they also need to influence `counter`, increasing the difficulty.

[0099] Based on this implementation, the dual-counter scheme significantly increases the difficulty for attackers to precisely manipulate the loop execution path and bypass dual checks by introducing an auxiliary counter with complex update rules independent of the main loop variable. Even if an attacker successfully interferes with the main counter, causing abnormal loop counts, the abnormal final value of the auxiliary counter can still effectively trigger the protection mechanism. This effectively improves the protection capability against multiple fault injection attacks.

[0100] As one implementation method, a preset delay instruction is inserted between each sub-operation in the cyclic execution operation set to delay the execution time of each sub-operation.

[0101] As one implementation method, the first correlation between the operation structure and energy consumption characteristics of the pseudo-operation is less than the second correlation between the operation structure and energy consumption characteristics of the real cryptographic operation; the first correlation characterizes the correlation between the intermediate value of the operation and the energy consumption of the pseudo-operation; the second correlation characterizes the correlation between the intermediate value of the operation and the energy consumption of the real operation.

[0102] To achieve the above functions, the protection device for block white-box cryptography algorithms includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art will readily recognize that, based on the algorithmic steps of the examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0103] This disclosure also provides an embodiment such as Figure 2 The protection device for the block white-box cryptographic algorithm shown includes: an insertion unit 21, a loop execution unit 22, a verification unit 23, and a protection unit 24.

[0104] The insertion unit 21 is used to insert a first preset number of pseudo-operations into any two real cryptographic operations that are associated during the execution of the block white-box cryptographic algorithm according to a preset insertion order, so as to obtain an operation set.

[0105] The loop execution unit 22 is used to repeatedly execute each sub-operation in the operation set to obtain multiple operation results; the sub-operations are real cryptographic operations or pseudo-operations.

[0106] The verification unit 23 is used to determine the first and second operation results of two real cryptographic operations from multiple operation results according to the preset insertion order.

[0107] The verification unit 23 is also used to verify the first operation result and the second operation result to obtain the target verification result.

[0108] The protection unit 24 is used to determine that the execution process corresponding to the two real cryptographic operations is abnormal if the target verification result indicates that the first operation result and the second operation result are inconsistent, and to perform protection operations.

[0109] In one implementation, the verification unit 23 is specifically used to: determine that the operation paths of the two real cryptographic operations are the same, and perform isomorphic verification on the first operation result and the second operation result; or, determine that the operation paths of the two real cryptographic operations are different, and perform heterogeneous verification on the first operation result and the second operation result.

[0110] In another implementation, the verification unit 23 is specifically used to: identify a second preset number of first operation nodes in the first target sub-operation that produces the first operation result, and a second preset number of second operation nodes in the second target sub-operation that produces the second operation result; verify the consistency of the algorithm execution flow of the second preset number of first operation nodes and the second preset number of second operation nodes to obtain a first verification result; determine a first comparison result between the first operation result and the second operation result; and determine a target verification result indicating whether the execution flow corresponding to the two real cryptographic operations is abnormal based on the first comparison result and the first verification result.

[0111] In another implementation, the two real cryptographic operations are an encryption operation and a decryption operation, respectively; the verification unit 23 is specifically used to: determine that the first operation result is the encryption operation result, compare the first input of the first operation result with the second operation result to obtain a second comparison result, so as to determine, based on the second comparison result, a target verification result indicating whether the execution process corresponding to the two real cryptographic operations is abnormal; or, determine that the second operation result is the encryption operation result, compare the second input of the second operation result with the first operation result to obtain a third comparison result, so as to determine, based on the third comparison result, a target verification result indicating whether the execution process corresponding to the two real cryptographic operations is abnormal.

[0112] In another implementation, the loop execution unit 22 is specifically used to: use a main counter to control the loop iteration of each sub-operation in the loop execution operation set; the increment step of the main counter is generated by a non-linear increment function; use an auxiliary counter to record the number of times each sub-operation in the operation set is executed during the loop execution; the counting update rule of the auxiliary counter is different from that of the main counter, and the counting update rule of the auxiliary counter is constructed based on a complex arithmetic sequence and a first preset quantity or based on a hash accumulation value associated with the loop execution operation, and the auxiliary counter is decoupled from the main counter; at the end of the loop execution, verify whether the final count value of the auxiliary counter is the same as the expected count value.

[0113] In another implementation, the loop execution unit 22 is specifically used to insert a preset delay instruction between each sub-operation in the loop execution operation set to delay the execution time of each sub-operation.

[0114] In another implementation, the first correlation between the operational structure and energy consumption characteristics of the pseudo-operation is less than the second correlation between the operational structure and energy consumption characteristics of the real cryptographic operation; the first correlation characterizes the correlation between the intermediate value of the operation and the energy consumption of the pseudo-operation; the second correlation characterizes the correlation between the intermediate value of the operation and the energy consumption of the real operation.

[0115] Regarding the apparatus in the above embodiments, the specific manner in which each unit module performs its operations has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0116] Figure 3 This is a schematic diagram of an electronic device provided in this application. (For example...) Figure 3 The electronic device 30 may include at least one processor 301 and a memory 303 for storing processor-executable instructions. The processor 301 is configured to execute the instructions in the memory 303 to implement the block white-box cryptographic algorithm protection method described in the following embodiments.

[0117] In addition, the electronic device 30 may also include a communication bus 302, at least one communication interface 304, an input device 306, and an output device 305.

[0118] Processor 301 may be a processor (central processing unit, CPU), microprocessor unit, ASIC, or one or more integrated circuits for controlling the execution of programs according to the present application.

[0119] The communication bus 302 may include a path for transmitting information between the aforementioned components.

[0120] Communication interface 304 uses any transceiver-like device for communicating with other devices or communication networks, such as Ethernet, radio access network (RAN), wireless local area network (WLAN), etc.

[0121] Input device 306 is used to receive input signals and output device 305 is used to output signals.

[0122] Memory 303 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital versatile optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. Memory may exist independently and be connected to the processing unit via a bus. Memory may also be integrated with the processing unit.

[0123] The memory 303 stores instructions for executing the scheme of this application, and the processor 301 controls the execution. The processor 301 executes the instructions stored in the memory 303 to realize the functions of the method of this application.

[0124] In a specific implementation, as one example, processor 301 may include one or more CPUs, for example... Figure 3 CPU0 and CPU1 in the CPU.

[0125] In a specific implementation, as one example, the electronic device 30 may include multiple processors, such as... Figure 3 Processors 301 and 307 are described in the text. Each of these processors may be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. A processor here may refer to one or more devices, circuits, and / or processing cores used to process data (such as computer program instructions).

[0126] The electronic device is as follows Figure 3 The diagram includes a processor 301 and a memory 303 for storing executable instructions of the processor 301. The processor 301 is configured to execute the executable instructions to implement a protection method for a block white-box cryptographic algorithm as described in any of the possible embodiments above. Furthermore, it achieves the same technical effect, and to avoid repetition, will not be elaborated further here.

[0127] This application also provides a computer-readable storage medium. When the instructions in the computer-readable storage medium are executed by the processor of a block white-box cryptography protection device or electronic device, the block white-box cryptography protection device or electronic device is able to perform the block white-box cryptography protection method as described in any of the above possible embodiments. And it can achieve the same technical effect; to avoid repetition, it will not be described again here.

[0128] This application also provides a computer program product, including a computer program or instructions, which are executed by a processor to provide a protection method for block white-box cryptographic algorithms as described in any of the possible implementations above. This achieves the same technical effect, and to avoid repetition, it will not be repeated here.

[0129] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0130] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for protecting against block white-box cryptographic algorithms, characterized in that, The method includes: According to the preset insertion order, insert a first preset number of pseudo-operations into any two real cryptographic operations that are associated during the execution of the block white-box cryptographic algorithm to obtain the operation set; The sub-operations in the set of operations are executed cyclically to obtain multiple operation results; the sub-operations are either the actual cryptographic operations or the pseudo-operations. Based on the preset insertion order, determine the first and second operation results of the two real cryptographic operations from the multiple operation results; The first and second calculation results are verified to obtain the target verification result. If the target verification result indicates that the first operation result and the second operation result are inconsistent, it is determined that the execution process corresponding to the two real cryptographic operations is abnormal, and protection operations are performed. The verification of the first operation result and the second operation result includes: determining that the operation paths of the two real cryptographic operations are the same, and performing isomorphic verification on the first operation result and the second operation result; or determining that the operation paths of the two real cryptographic operations are different, and performing heterogeneous verification on the first operation result and the second operation result.

2. The method according to claim 1, characterized in that, The isomorphic verification of the first calculation result and the second calculation result includes: Identify a second preset number of first operation nodes in the first target sub-operation that produces the first operation result, and a second preset number of second operation nodes in the second target sub-operation that produces the second operation result; verify the consistency of the algorithm execution flow of the second preset number of first operation nodes and the second preset number of second operation nodes to obtain a first verification result; Determine the first comparison result between the first calculation result and the second calculation result; Based on the first comparison result and the first verification result, a target verification result is determined that indicates whether the execution flow corresponding to the two real cryptographic operations is abnormal.

3. The method according to claim 1, characterized in that, The two actual cryptographic operations are encryption and decryption operations, respectively; the heterogeneous verification of the first and second operation results includes: The first operation result is determined to be the encryption operation result. The first input of the first operation result is compared with the second operation result to obtain a second comparison result. Based on the second comparison result, the target verification result indicating whether the execution process corresponding to the two real cryptographic operations is abnormal is determined. Alternatively, determine that the second operation result is the encryption operation result, compare the second input of the second operation result with the first operation result to obtain a third comparison result, and determine the target verification result indicating whether the execution process corresponding to the two real cryptographic operations is abnormal based on the third comparison result.

4. The method according to any one of claims 1 to 3, characterized in that, The loop executes each sub-operation in the set of operations to obtain multiple operation results, including: A master counter is used to control the iterative execution of each sub-operation in the operation set; the increment step of the master counter is generated using a non-linear increment function. An auxiliary counter is used to record the number of times each sub-operation in the operation set is executed during the loop execution process. The counting update rule of the auxiliary counter is different from that of the main counter. The counting update rule of the auxiliary counter is constructed based on a complex arithmetic sequence and the first preset number or based on the hash accumulation value associated with the loop execution operation. The auxiliary counter is decoupled from the main counter. At the end of the loop execution, verify whether the final count value of the auxiliary counter is the same as the expected count value.

5. The method according to any one of claims 1 to 3, characterized in that, The method further includes: Between the execution of each sub-operation in the set of operations, a preset delay instruction is inserted to delay the execution time of each sub-operation.

6. The method according to any one of claims 1 to 3, characterized in that, The first correlation between the operational structure and energy consumption characteristics of the pseudo-operation is less than the second correlation between the operational structure and energy consumption characteristics of the real cryptographic operation; the first correlation represents the correlation between the intermediate value of the operation and the energy consumption of the pseudo-operation; the second correlation represents the correlation between the intermediate value of the operation and the energy consumption of the real operation.

7. A protection device for block white-box cryptographic algorithms, characterized in that, The device includes: An insertion unit is used to insert a first preset number of pseudo-operations into any two real cryptographic operations that are associated during the execution of the block white-box cryptographic algorithm according to a preset insertion order, so as to obtain an operation set. The loop execution unit is used to repeatedly execute each sub-operation in the operation set to obtain multiple operation results; the sub-operation is the real cryptographic operation or the pseudo-operation. The verification unit is used to determine the first and second operation results of the two real cryptographic operations from the multiple operation results according to the preset insertion order; The verification unit is also used to verify the first calculation result and the second calculation result to obtain the target verification result; The protection unit is used to determine that the execution process corresponding to the two real cryptographic operations is abnormal if the target verification result indicates that the first operation result and the second operation result are inconsistent, and to perform protection operations. The verification unit is specifically used to: determine that the two real cryptographic operations have the same operation path, and perform isomorphic verification on the first operation result and the second operation result; or, determine that the two real cryptographic operations have different operation paths, and perform heterogeneous verification on the first operation result and the second operation result.

8. A protection system for block cipher algorithms, characterized in that, The system is configured to perform a protection method for the block white-box cryptographic algorithm as described in any one of claims 1-6.

9. A computer-readable storage medium storing instructions thereon, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is able to perform the protection method of the block white-box cryptographic algorithm as described in any one of claims 1-6.

Images