A method and system for efficient constant-time security verification of binary programs

Abstract

The application belongs to the technical field of software development and security guarantee, and particularly relates to a binary program efficient constant-time security verification method and system. The method comprises the following steps: S1, marking the security level of input information of a binary executable file; S2, processing the security level marked information after verification to generate a DBA intermediate representation; S3, analyzing the intermediate representation DBA to generate key components required for subsequent analysis; S4, converting the key components into initial symbolic states, path conditions, security assertion templates and SMT constraint templates to be verified required for relational symbolic execution; S5, dynamically generating, optimizing and verifying the SMT constraint by using the relational symbolic execution and combined verification technology; and S6, judging whether the analyzed executable program has a vulnerability violating the constant-time security property. The application provides an efficient and reliable formal security verification method for binary program verification.

Description

Technical Field

[0001] This invention belongs to the field of software development and security technology, specifically relating to an efficient constant-time security verification method and system for binary programs. Background Technology

[0002] Timing side-channel attacks can remotely recover secret information by exploiting execution time differences associated with secret input information, posing a serious threat to software security. Historical examples, such as private key recovery attacks against the RSA algorithm in OpenSSL and Lucky 13 attacks, have demonstrated the destructive power of this type of risk. While mitigation measures such as security-aware systems and architectural optimizations exist, the fundamental solution to reducing these risks lies in eliminating time differences associated with secret inputs at the software implementation level.

[0003] Currently, one of the mainstream methods to avoid timing side-channel attacks is to follow the Constant-time Security programming specification, which has been adopted by mainstream cryptographic libraries such as NaCl, BearSSL, MbedTLS, s2n-tls, and OpenSSL. The main idea behind constant-time security is that operations that affect program execution time or attacker-observable behavior, such as conditional branches, loop exit conditions, dynamic jumps, and memory access addresses, should not rely on secret input.

[0004] Relational symbolic execution, as an advanced formal verification technique, overcomes the limitation of traditional symbolic execution, which can only analyze single paths, and achieves rigorous determination of "2-safety properties." By capturing subtle differences between different execution flows through techniques such as self-composition, relational symbolic execution has irreplaceable application value in detecting timing side-channel vulnerabilities, verifying complex information flows, and ensuring constant-time safety properties.

[0005] There are many existing methods for timing side-channel detection. For example, Ronen et al. used concrete execution techniques to analyze timing side-channel; Sung et al. converted buffering behavior into corresponding constraints and used dynamic symbolic execution for side-channel detection; Cai et al. proposed a constant-time property analysis framework that combines lightweight taint analysis and formal security verification.

[0006] While existing analysis methods can identify time-series side-channel problems and verify the constant-time security properties of programs to some extent, they still suffer from three key shortcomings: First, in terms of input modeling, most current constant-time analysis tools do not support flexible manual annotation of program inputs by users, or, when annotation is supported, lack mechanisms for automatic error correction and completion of annotation information, limiting the accuracy and applicability of the analysis results. Second, regarding analysis efficiency, existing methods based on relational symbolic execution generally suffer from the state space explosion problem, leading to a significant decrease in verification efficiency, especially in programs containing frequent function calls, where this problem is more pronounced, severely impacting the scalability of the tools. Finally, in terms of constraint solving, existing methods lack the ability to optimize formal constraints and intermediate representations, easily leading to excessively high complexity in the constraint solving process, which in turn causes solver timeouts and reduces the overall practicality of the analysis.

[0007] In summary, there is an urgent need for a method and system that can efficiently verify and guarantee the constant-time safety properties of binary executable files. Summary of the Invention

[0008] To address the shortcomings of existing technologies, this invention provides an efficient constant-time security verification method and system for binary programs.

[0009] Technical solution An efficient constant-time security verification method for binary programs includes the following steps: Step S1: The user marks the security level of the input information of the executable file according to their own needs; Step S2: Standardize, perform integrity and consistency checks on the security level labeling information provided by the user, and automatically complete missing labels within the inferable range. Provide prompts or corrections for labels that conflict or are inconsistent. Generate an intermediate representation of Dynamic Bit-Vector Automata (DBA) based on the binary executable file and the verified labeling information. Step S3: Parse the DBA intermediate representation generated in step S2 and convert the key processes therein into components that meet the requirements of combinatorial verification. The components include a function call graph, an inter-process control flow graph, and a function summary. Step S4: Convert the components into the initial symbolic state, path conditions, security assertion template, and SMT (Satisfiability Modulo Theories) constraint template required for relational symbolic execution. Step S5: The SMT constraint template obtained in Step S4 is formally verified using the Bitwuzla solver and relational symbolic execution to obtain the verification results. Simultaneously with the relational symbolic execution, fault packing, taint removal, loop invariant generation based on a large language model, and memory read / write optimization methods are employed to optimize the SMT constraints. Step S6: Based on the verification results of step S5, determine whether the executable file has vulnerabilities that violate the constant-time safety property. If vulnerabilities exist, use the location and number of vulnerabilities, along with the constraint counterexamples obtained by the solver, as the final output report.

[0010] Furthermore, S1 includes the following sub-steps: Step S1-1: For the input information of the executable file, the user marks the input information of the binary executable file from two dimensions: register information and memory information. For these two different types of information, the user selects the registers or information that need to be paid attention to and marks them as public or secret. In steps S1-2, after completing the annotation, the user provides supplementary constraint information, including: the data range of the register storage value, the storage address range of different information in memory, and whether different memory regions overlap.

[0011] Step S2 includes the following sub-steps: Step S2-1: Standardize the security level labeling information provided by the user.

[0012] Specifically, the system receives input annotation information provided by users through configuration files, comments, command-line parameters, or an interactive interface, and converts it into an internal annotation table. This internal annotation table includes at least the input object identifier, input object type, security level, address range, data length, and supplementary constraint information. The input object type includes registers, memory regions, function parameters, and global data regions; the security level includes public information and secret information; and the supplementary constraint information includes address range, data length, value range, and whether memory regions overlap. The system can also extract input usage features from binary executable files and read preset annotation rules. These input usage features include the input object's register role, parameter location, data source, memory access context, and calling convention information. The preset annotation rules are used to constrain the input object's default security level, conflict judgment conditions, and completion priority. Step S2-2: Perform an integrity check on the standardized security level labeling information.

[0013] Specifically, the system determines whether the registers, memory regions, or function parameters involved in the analysis all have corresponding security level labels based on the calling convention of the binary executable file, function entry parameters, register usage, memory access behavior, and the set of input objects required for subsequent constant-time analysis. If an input object is found to lack a security level label, it is recorded as an object to be completed and enters the subsequent automatic completion process. Step S2-3: Perform consistency and conflict detection on the security level labeling information.

[0014] Specifically, the system determines whether there are conflicts or inconsistencies between different annotations based on the supplementary constraint information provided by the user in steps S1-2, the input usage characteristics extracted from the binary executable file, and the preset annotation rules. Such conflicts or inconsistencies include at least: the same input object being repeatedly labeled with different security levels; the memory range annotated by the user being inconsistent with the address range in the supplementary constraints; two memory regions declared as non-overlapping overlapping in their address ranges; input objects declared as public directly carrying secret data regions specified by the user; and situations where the annotation information is inconsistent with the preset calling convention or parameter roles. Step S2-4: Based on the results of integrity detection, consistency detection, and conflict detection, automatically complete, prompt, or correct the security level labeling information.

[0015] Specifically, for input objects with missing annotations, the system infers their default security level based on the input object's type, variable name or register role, calling convention, parameter location, data source, memory access context, and preset rules, and generates completion annotations. For annotations with clear conflicts, corrections are made based on user-provided supplementary constraints and preset priority rules; among these, user-declared secret inputs have higher priority than automatically inferred results, and user-provided address range constraints have higher priority than default memory layout inferred results. For input objects whose security level cannot be uniquely determined based on existing information, the system does not perform forced correction but marks them as objects awaiting confirmation and prompts the user in the output results. Step S2-5: Based on the binary executable file and the verified security level labeling information obtained in step S2-4, generate the intermediate representation of the dynamic bit vector automaton DBA.

[0016] Specifically, register operations, memory read / write operations, arithmetic and logical operations, conditional branches, static jumps, and dynamic jumps in the binary executable file are converted into corresponding DBA statements. Security level annotation information is then associated with register variables, memory region variables, and symbolic input objects in the DBA statements. This allows subsequent DBA parsing to directly obtain DBA variables and statements with security level attributes, thus providing a unified intermediate representation for relational symbolic execution and SMT constraint generation.

[0017] Steps S2-1 to S2-4 constitute the automated annotation, verification, and completion mechanism for input information security levels in this invention. This mechanism does not simply rely on manual annotation by users, nor does it directly set all unannotated objects to a fixed security level. Instead, it combines explicit user annotation, supplementary constraints, input usage features extracted from binary programs, and preset inference rules to standardize, perform integrity checks, consistency checks, automatic completion, and conflict handling on the security level annotation information.

[0018] Step S3 includes the following sub-steps: Step S3-1: Parse the DBA program generated in step S2 and convert it into DBA variables and DBA statements required for subsequent analysis; Step S3-2: Based on user annotations, the intermediate language is further converted into security variables with security levels, and vulnerability patterns are organized according to the corresponding DBA statement types. These vulnerability patterns include control flow vulnerabilities related to branch statements and memory vulnerabilities related to memory access. Step S3-3: Based on the DBA information generated in step S3-2, generate information on different components required for subsequent analysis, including: Call Graph, Inter-procedure Control Flow Graph, and Function Summary.

[0019] In the process of generating function summaries during program analysis, relational symbol execution typically requires traversing all feasible paths to ensure verification accuracy. However, for complex, large-scale programs, full path exploration often leads to a severe path explosion problem. Especially in cryptographic implementations, the same library functions are frequently called to achieve specific functionalities; performing repeated deep analysis on each call would incur enormous computational overhead.

[0020] To address this issue, this invention creatively employs a combinatorial verification approach: during the pre-analysis phase, a function summary is generated for each function to encapsulate its input-output relationships and security constraints. In the main analysis phase following the pre-analysis, when the function call is encountered, the system only needs to substitute the actual parameters into the function summary for instantiation and verify the constraints in the summary, thereby avoiding repeated scanning of the function's internal logic. This strategy significantly reduces the number of paths to be analyzed and effectively improves overall analysis efficiency.

[0021] Although binary executables lack explicit function boundary declarations, the function call graph of the program can still be effectively reconstructed through control flow analysis of instructions such as `call` and `ret`. In DBA program analysis, the low-level processes are abstracted into function operators similar to those in high-level languages.

[0022] Specifically, for any function Summary of its relational functions Defined as a triple .in, and These represent the initial symbolic state and the initial relational symbolic memory of the function, respectively. It is a collection A list of quadruplets, each quadruplet It precisely depicts a symbolic execution path of the function, where: Path constraints The necessary and sufficient condition for this path to be triggered is manifested in the initial symbolic state of the function. With initial relation symbol memory Boolean formula; State transition ( , This describes how registers, flags, and symbolic memory evolve based on the initial input at the end of the path, i.e., the symbolic representation of function side effects. This represents the update of the symbolic state of a function, while Represents the update of relational symbol memory; Set of security assertions ( ): This encapsulates all the security constraints generated during the execution of this path, including non-interference checks on all memory accesses and requirements for the constant-time safety of branch conditions.

[0023] In the pre-analysis phase, since the analysis is within the process and the specific actual parameters are unknown, the summary is used for placeholder modeling through formal parameters. In the main analysis phase, whenever the symbolic execution flow reaches a call point, the system triggers the summary instantiation process. This involves using the constraint replacement mechanism of the SMT solver to map and replace the formal parameters in the summary with the current symbolic actual parameters. By reusing the function summary, cross-process combinatorial verification is achieved without requiring the solver to repeatedly re-enter the function's internal logic.

[0024] The specific analysis process is as follows: (1) Reachability verification: First, verify the conditions of each output path in conjunction with the current path constraints. The satisfiability of the path is assessed; if the path is reachable, further analysis is performed; otherwise, pruning is carried out.

[0025] (2) Security verification: For paths that are determined to be reachable, the system will instantiate their associated security assertions. The results are then submitted to the SMT solver for compliance verification.

[0026] (3) State Update: The path verified will be used as the equivalent output of the function, and its state transformation will be performed. and This will propagate to subsequent analysis at the calling point.

[0027] This summary-based analysis paradigm transforms the original deep path exploration into combinatorial computation based on logical mapping. Especially when dealing with large-scale binary executables containing frequent library function calls or complex inter-process logic, this method can effectively avoid redundant traversal of the same function body logic, greatly alleviate the path explosion problem, and significantly improve the analysis efficiency and scalability of relational symbolic execution.

[0028] Furthermore, in step S4, the initial symbol state is generated according to the security level of the input: for public input, the system uses the same symbol value to model in both left and right executions to represent that the public input takes the same value in the two executions; for secret input, the system uses independent symbol values ​​to model in both left and right executions to represent that the secret input can take different values ​​in the two executions. The security assertion template is generated based on the leakage pattern to be detected: for conditional branches, memory accesses, and dynamic jumps, left and right projection consistency assertions for branch conditions, access addresses, and jump targets are generated respectively, and the current path conditions are combined with the negative form of the security assertion to form vulnerability query constraints.

[0029] Furthermore, step S5 includes the following sub-steps: Step S5-1: The Bitwuzla solver is used, combined with relational symbolic execution analysis technology, to verify and analyze the SMT constraints; during the analysis, the methods in steps S5-2 to S5-5 are used for optimization operations. Step S5-2: The SMT constraint is optimized using the fault packaging optimization technique. Specifically, the constraint with the vulnerability mode of memory vulnerability in the basic block of the control flow graph of the same process will be packaged into an SMT constraint for verification in the subsequent verification. Step S5-3: The SMT constraints are optimized using taint removal optimization techniques. Specifically, if the solver verifies that the left and right projections of a certain relational expression are always equal under certain path conditions, the system reduces the expression to a simple relational expression in the subsequent analysis of the current path and reuses the equivalent result. This process does not change the security level of the original input object. Step S5-4: The component is optimized by using a loop invariant generation method based on a large language model. Specifically, for components with loop structures, the present invention will use a large model to generate the corresponding loop invariant. Step S5-5: Optimize SMT constraints using memory read / write optimization methods. Specifically, if a variable is stored in memory and then immediately read from memory, it can be optimized to directly read the variable.

[0030] Furthermore, in step S5-1, during the execution of relational symbols, the program data is represented using relational formulas and modeled with left and right execution paths.

[0031] make Given the standard set of first-order logic formulas for quantifier-free arrays and bit-vectors (QF_ABV), the relational formulas are... Defined as: The simple relational expression is: This indicates that the variable has the same value in both the left and right execution paths (i.e., the value depends only on the public input). The pairing relation expression is... This indicates that the variable may have different symbolic values ​​in the left and right execution paths (i.e., the value is affected by secret input). , These are the symbol values ​​for the left and right execution paths, respectively.

[0032] To extract the components of the left and right paths, a projection operation is defined: For Its left projection Right projection .like ,but At the binary analysis level, the execution state of a program is formalized as a symbolic configuration; specifically, a symbolic configuration is a quadruple. ,in This indicates the location of the currently executing instruction. Due to the constant-time safety property, both execution paths must follow the same control flow path; therefore, only a single instruction location needs to be maintained. Symbolic state This represents the mapping from symbolic variables to corresponding relational formulas, where... A set of symbolic variables. Represents symbolic memory, where and These represent a 64-bit bit vector set and an 8-bit bit vector set, respectively. In relational symbolic execution, memory is modeled as a pair of symbolic arrays. ,in and These represent the memory locations for the left and right execution paths, respectively. Each array conforms to the QF_ABV theorem and maps memory addresses to 8-bit relational expressions. Path constraints. Record from the initial state to the current instruction position The input constraints that need to be satisfied.

[0033] Relational symbolic execution detects the leakage of secret inputs by monitoring execution behavior. Specifically, it defines a security decision function. Used to evaluate symbolic expressions Safety at leakage points (observation points include memory access, branch conditions, and dynamic jumps). Function The definition is as follows: Define a model that can assign specific numerical values ​​to symbolic variables. Path constraints In the model Satisfaction on is denoted as Without needing a specific model In this case, it is hidden and only processed through Symbols to represent constraints It is satisfiable. During implementation, the SMT solver is used to determine the satisfiability of the formula. When When, it indicates the current symbolic expression. It is only affected by publicly available inputs, therefore it must satisfy the constant-time safety property. And when... When affected by secret input, if it does not satisfy the constraints If this path is reachable, then the attacker's observations are the same for both paths, thus satisfying the constant-time safety property. Otherwise, there must exist a set of input counterexamples that cause the attacker's observations to differ, thus violating the constant-time safety property. It is important to note that when... In this case, it is not necessary to call the solver to solve the problem, because symbolic expressions are always affected by public inputs. Therefore, the number of solver calls can be reduced, thereby improving analysis efficiency, which is especially effective in large-scale program analysis.

[0034] Configure the two symbols and The transition between them is represented as Decision formula Indicates the current symbol state Relational symbolic memory Below, expression The evaluated relational expression .

[0035] In addition to path explosion caused by redundant function calls, binary-level relational symbolic execution also faces the following three major performance and accuracy bottlenecks: (1) State space expansion caused by low-level semantic missing: In order to verify relational attributes, the system needs to establish complex association expressions for sensitive variables on two execution paths, which greatly increases the dimension of symbolic states. (2) Performance overhead of large-scale constraint solving: When the path constraints are large in scale and complex in logic, frequent calls to the SMT solver for feasibility testing and property verification will generate huge computational overhead, becoming the performance bottleneck of the overall analysis. (3) The problem of accurate modeling of loop structures: At the binary level, the number of loop iterations is often unpredictable. How to achieve accurate modeling and analysis of loop logic without causing path explosion is the core challenge to ensure the completeness and accuracy of verification.

[0036] To address the aforementioned challenges, this invention proposes four key optimization techniques aimed at significantly improving the efficiency and accuracy of the analysis.

[0037] Fault Packaging (Step S5-2): Instead of submitting each vulnerability query condition separately to the solver, the system merges multiple vulnerability query conditions under the same path constraint using disjunction to form a packaged vulnerability query condition. The system submits the packaged vulnerability query condition to the solver to determine whether there is at least one memory access point with different left and right address projections under the path constraint π. If the packaged query is not satisfied, it means that there is no address leakage in the current group of memory accesses under the current path constraint; if the packaged query is satisfied, it means that there is at least one potential memory access leakage point in the current basic block or under the same path constraint. The system records the statements of the current group of memory accesses as a candidate vulnerability set in the report and performs fine-grained splitting and verification of the set as needed.

[0038] In instruction-by-instruction analysis of cryptographic algorithms, the number of queries generated by insecure memory accesses is enormous. Each memory load or store instruction requires a separate SMT query, which significantly increases verification overhead. To address this, a sequence of symbolic expressions representing a set of potential memory leaks under the same path constraint π is used. Optimize using disjunction relation as This reduces the number of queries from It dropped to 1.

[0039] In practice, for the same basic block or the same path constraint Multiple memory access expressions under , , ..., The system extracts the projections of each address expression in the left and right execution paths, denoted as follows: , , , , ..., , Subsequently, the system constructs vulnerability query conditions for each memory access point, that is, it determines whether the left and right projections of the corresponding address expression might be different. For the i-th memory access point, its vulnerability query condition can be expressed as follows: .

[0040] By using the above methods, the number of queries sent to the solver can be reduced, thereby reducing solver call overhead and improving verification efficiency.

[0041] Taint Removal (Step S5-3): During constant-time verification, the system needs to frequently initiate security queries to detect whether the expression is affected by secret inputs (i.e., whether it is tainted). Based on the aforementioned security determination function... (A detailed definition of this formula will be given later.) If the expression is a simple relational expression... This indicates that it relies solely on public input, naturally satisfies the constant-time safety property, and does not require verification by calling the solver. For pairwise relation expressions... If the solver determines that it meets the safety constraints, it means that there is a solution under any execution path. This holds true. Based on this equivalence relation, in subsequent analysis... The variables involved are replaced with The corresponding variable in the middle.

[0042] In practice, when a certain pairing relation expression is obtained during the execution of the relation symbol, When prompted, the system first determines whether the expression appears in subsequent branch conditions, memory access addresses, or dynamic jump targets. If the expression may affect the attacker's observable behavior, the system then constrains the current path. The following constructs an equivalence query to determine... Is it possible that the projections in the left and right execution paths are different? If so... and If the condition that the left and right projections are unequal is not satisfied, it means that although the expression is formally affected by secret input propagation under the current path conditions, the execution results of its left and right paths are always equal, thus preventing constant-time security leaks at subsequent observation points. When the above query cannot be satisfied, the expression is reduced from a pairwise relational expression to a simple relational expression in the successor state of the current path and recorded in the equivalence cache of the current path. If the same expression or its derived expressions are encountered again subsequently, the system prioritizes reusing the equivalence cache result to avoid repeatedly generating security queries. This taint removal only takes effect within the scope of subsequent analysis governed by the current path conditions; it does not change the security level of the original input object, nor does it affect the independent judgment of the expression under other paths.

[0043] By using the above methods, the system can streamline the size of expressions in subsequent symbolic execution and reduce the number of security queries.

[0044] Loop Invariant Generation Based on Large Language Model (Step S5-4): Introducing loop invariants is a key means to improve the accuracy of program verification. This invention proposes a relational loop invariant generation method based on a large language model, aiming to support relational symbolic execution.

[0045] From a formal perspective, the relational property to be verified can be represented as a Hall triple. This triple shows that, from satisfying the preconditions... Starting from the state, execute the loop instruction. Afterwards, the system will inevitably enter a state where the postconditions are met. The state. Without loss of generality, the loop instruction is defined as... ,in This represents the loop condition expression. This represents the loop body instructions. Although loops in DBA programs often consist of complex jump and conditional branch instructions, this does not affect the applicability of the analysis framework in this step. (Regarding attributes...) Candidate loop invariants The following three core principles must be met: Initialization: That is, the initial state of the cycle contains an invariant; Inductivity: That is, the effectiveness of the loop body in maintaining invariant properties; Sufficiency: That is, the invariant is sufficient to prove the target property when the loop terminates. The target is to automatically synthesize loop invariants that possess both inductive and sufficiency properties.

[0046] In practice, structured cue words are used to guide the Large Language Model (LLM) in generating candidate cyclic invariants. To address the randomness of the LLM output and improve the success rate, a multi-sampling strategy is employed: a higher sampling temperature is set to enhance the diversity of candidate solutions, and the LLM is requested to generate a set containing n independent candidate relation invariants. Furthermore, the prompt explicitly requires that candidate loop invariants must contain relational predicates to characterize the synchronicity between the left and right execution paths.

[0047] If a solution that passes SMT verification exists among the n candidate loop invariants, the loop is considered verified, and this invariant will serve as a function summary for subsequent combinatorial verification. If verification fails, LLM analysis is initiated to determine the cause of the failure (e.g., counterexample information), followed by feedback-driven refinement and regeneration. If a valid invariant cannot be synthesized within a preset time threshold, the process reverts to bounded loop expansion mode. While this mechanism loses the ability to provide complete proofs for infinite paths due to the introduction of bounds, it ensures the termination of the analysis process and basic security verification. When a candidate invariant fails initialization, inductive, and sufficiency verifications, it is not used as a proof basis; the system only includes candidate invariants that pass SMT constraint verification in the function summary. If the process reverts to bounded expansion, the report marks this conclusion as a "bounded verification result," and it is not considered an unbounded constant-time security proof.

[0048] Memory read / write optimization (steps S5-5): Under the QF_ABV logical framework, memory load and store operations are transformed into select and store primitives in SMT. Because this method uses bit-level precise modeling (i.e., modeling memory as a symbolic array mapping from a 64-bit address space to 8-bit data), processing a 256-bit data block requires triggering 32 consecutive store operations, resulting in severe nesting and stacking in the generated SMT expression, significantly increasing the solution overhead.

[0049] Based on the axioms of array theory and The following two optimization strategies were designed and implemented, among which Represents memory, and They represent memory addresses, This indicates the memory value that needs to be loaded or stored: (1) Expression algebra reduction: using array theory to axiomatize semantics, simplifying redundant nested select / store structures; (2) Memory-mapped caching mechanism: Cache mapping is introduced to record the initial memory layout and the write state during runtime. When executing the load instruction, the system first searches the cache; if the cache is hit, the result is returned directly, thus avoiding the construction of complex symbolic expressions; if the cache is not hit, it falls back to the standard select instruction for symbolic reading.

[0050] Step S6 includes the following sub-steps: Step S6-1: Analyze the results of formal verification using the Bitwuzla solver to determine whether the executable file has vulnerabilities that violate the constant-time safety property.

[0051] Specifically, for each security assertion, the current path condition and its negation are submitted to the Bitwuzla solver for satisfiability assessment. When the solver returns "unsatisfiable," it indicates that there are no input assignments under the current path condition that would cause an observable difference between the left and right execution paths, and the security assertion is marked as verified. When the solver returns "satisfiable," it indicates that there exists a set of left and right input assignments that could cause a difference in branch direction, memory access address, or dynamic jump target, and the program location corresponding to the security assertion is marked as a candidate vulnerability point that violates the constant-time safety property.

[0052] When a vulnerability is detected, the system extracts counterexample information from the model returned by the solver, including the path conditions that trigger the vulnerability, the input assignments in the left and right execution paths, the vulnerability trigger location, the vulnerability type, the corresponding observation expression, and the difference results of the left and right projections. Subsequently, the system categorizes this information according to function, basic block, instruction address, and vulnerability type, generating a structured vulnerability report. For candidate vulnerability sets generated by fault packaging, the system records the corresponding basic block or path range in the report and can further perform unpacking verification to locate the specific instruction according to user needs. If no counterexamples meeting the vulnerability query conditions are detected, the system outputs a verification pass result; if incomplete strategies such as bounded loop unpacking are used during the analysis, the corresponding verification boundaries are marked in the report.

[0053] Step S6-2: If the executable file contains a vulnerability that violates the constant-time security property, then output the corresponding vulnerability to the console to display the vulnerability content in an intuitive way.

[0054] Step S6-3: If the executable file contains vulnerabilities that violate the constant-time safety property, then the analyzed vulnerabilities and the constraint counterexamples obtained by the solver are summarized into a corresponding vulnerability report and fed back to the user.

[0055] A binary program efficient constant-time security verification system for implementing the above method includes: a security level labeling module, a DBA generation module, a DBA parsing module, a component generation module, a constraint generation module, and a relational symbolic execution and optimization module.

[0056] The security level labeling module is used to receive manual labels from users on binary executable file input information, and to perform standardization processing, integrity detection, consistency detection, automatic completion, and conflict prompting or correction on the labeled information. The DBA generation module is used to convert binary executable files into DBA programs as intermediate representations. The DBA parsing module is used to convert the intermediate representation of the DBA program into DBA variables with security levels, support DBA statements for subsequent analysis, and vulnerability patterns that need to be detected. The component generation module is used to convert the DBA information parsed by the DBA parsing module into intermediate components such as function call graphs, inter-process control flow graphs, and function summaries. The constraint generation module is used to convert the components generated by the component generation module into SMT constraints that need to be verified. The relation symbolic execution and optimization module is used to perform symbolic execution and optimization on SMT constraints, and summarize the results to obtain the final vulnerability report and counterexample report.

[0057] Beneficial effects The efficient constant-time security verification method and system for binary programs provided by this invention have the following beneficial effects: First, this invention standardizes, performs integrity checks, consistency checks, automatic completion, and conflict alerts or corrections on user-provided input annotation information through security level annotation. This reduces the impact of missing, conflicting, and inconsistent manual annotations on subsequent analysis results, improves the accuracy, consistency, and reliability of input security level annotations, and allows users to explicitly annotate only some key input objects, thereby enhancing the flexibility and ease of use of the verification process.

[0058] Secondly, this invention is based on the intermediate representation of the Dynamic Bit Vector Automaton (DBA) and adopts the idea of ​​combinatorial verification to decompose the binary program to be analyzed. The large binary program representation is converted into function call graphs, inter-process control flow graphs, function summaries or other smaller-scale components suitable for verification, thereby reducing the program size required for a single formal verification, reducing the problems of path explosion and excessive constraint size, and improving the efficiency of constant-time safety verification of binary programs.

[0059] Furthermore, this invention adapts and extends traditional relational symbolic execution technology, enabling it to analyze DBA variables and DBA statements with security level attributes. It can also generate corresponding security assertions and vulnerability query constraints for program behaviors that may lead to constant-time security leaks, such as conditional branches, memory accesses, and dynamic jumps, thereby achieving formal verification of the constant-time security properties of binary programs.

[0060] Furthermore, this invention employs constraint optimization methods such as fault packaging, taint removal, generation of loop invariants based on large language models, and memory read / write optimization to simplify and compress the SMT constraints generated during relational symbolic execution. This reduces redundant constraints, lowers solver overhead, and improves verification efficiency and scalability during the analysis of complex binary programs.

[0061] Finally, this invention can determine whether a binary program has vulnerabilities that violate the constant-time security property based on the SMT solution results, and generate a vulnerability report based on the vulnerability type, vulnerability content, vulnerability location, and counterexample information returned by the solver, thereby facilitating users to locate and fix related security issues. Therefore, this invention not only overcomes the shortcomings of existing technologies in efficiently verifying binary-level constant-time security properties, but also provides a more efficient and reliable formal security verification method for cryptographic implementations, low-level security programs, and other binary programs with high side-channel security requirements. Attached Figure Description

[0062] Figure 1 This is a schematic diagram of the method flow of the present invention; Figure 2 This invention employs the symbolic execution semantics of the DBA intermediate representation program used in relational symbolic execution based on combinatorial verification. Figure 3 This is a structural block diagram of the binary program efficient constant-time security verification system according to an embodiment of the present invention. Detailed Implementation

[0063] To make the technical means, creative features, objectives and effects of this invention easy to understand, the following embodiments, in conjunction with the accompanying drawings, specifically illustrate the efficient formal verification method and system for the constant-time security properties of binary executable files.

[0064] Example 1 An efficient constant-time security verification method for binary programs, the processing procedure is as follows: Figure 1 .

[0065] In this embodiment, the following assembly function, Fr_leaky_reduce_lookup, will be used as an example for illustration: 1.; rdi = out, the address of the output buffer, public 2.; rsi = in, secretly input the address of a large integer, secret 3.; rdx = mod, public modulo address, public 4.; rcx = table, looks up the table address, public 5. r8 = len, the array length, public, for example, len = 4 6. 7. Fr_leaky_reduce_lookup: 8.xor r9, r9; i = 0, public loop counter 9.xor r10, r10 ; acc = 0, secret-tainted aggregate value 10. 11. loop_start: 12. cmp r9, r8 13. `jae loop_end;` The branch condition only depends on the public `i` and `len`. 14. 15. `mov rax, [rsi + r9*8] ;` This command reads the secret limb. 16. `mov rbx, [rdx + r9*8] ;` reads the public mod limb. 17. 18. sub rax, rbx ; rax = in[i] - mod[i] 19. `xor r10, rax ; acc` is affected by the `secret` input. 20. 21. `mov [rdi + r9*8], rax ;` writes a temporary result. 22. `mov r11, [rdi + r9*8] ;` This is followed by reading the value that was just written. twenty three. 24. inc r9 25. jmp loop_start 26. 27. loop_end: 28. test r10, 1 29. jnz secret_branch; Vulnerability 1: Branch condition depends on secret-tainted account 30. 31. public_branch: 32. and r10, 7 33. mov r12, [rcx + r10*8] ; Vulnerability 2: Memory access address depends on secret-taintedacc 34. mov [rdi], r12 35. ret 36. 37. secret_branch: 38. and r10, 7 39. mov r12, [rcx + r10*8] ; Vulnerability 3: Memory access address depends on secret-taintedacc 40. mov [rdi + 8], r12 41. ret This function performs word-for-word reduction on a large integer input and then performs a lookup operation based on the calculation result. It iteratively processes the input data element by element, accumulating intermediate results, and finally selects different execution paths and lookup indices based on these accumulated results to output the final result. Because the intermediate accumulated values ​​depend on the secret input, this function introduces secret-related dependencies in both control flow branches and memory access addresses, thus violating the constant-time safety property. Specifically, in the function, input data is first read from the memory address pointed to by register rsi in line 15. This input is marked as secret information, so the value loaded into register rax has a secret dependency. Subsequently, in lines 18 and 19, this secret-related value is propagated and accumulated in register r10 through subtraction and XOR operations, making register r10 an intermediate variable dependent on the secret input. Based on this, the function uses register r10 as a condition for branch judgment in lines 28 and 29, causing the program's execution path to depend on the secret information, forming a secret-related control flow vulnerability. Furthermore, in lines 32 and 33, the function uses register r10 as an offset in memory address calculation and reads data from a lookup table, making the memory access address also dependent on the secret input, thus creating a secret-related memory access vulnerability. Therefore, this function introduces a dependency on secret data at both the control flow and memory access levels, thereby violating the constant-time security property and potentially leading to timing side-channel leakage.

[0066] The above case will be analyzed in detail, including the following steps: Step S1-1: Users can use comments or configuration to mark the security level of input information in the binary executable file. In this embodiment, registers rsi, rdx, rcx, and rdi serve as the starting address pointers for input data, modulo data, lookup table, and output buffer, respectively. The memory area pointed to by register rsi stores the large integer input data to be processed, which typically contains sensitive information; therefore, the user marks it as secret. The modulo data pointed to by register rdx, the lookup table data pointed to by register rcx, and the output buffer pointed to by register rdi are all considered public information. Furthermore, the loop counter and length parameters (such as register r8) are only used to control the program execution flow and are also marked as public.

[0067] Step S1-2: After completing the security level labeling, users can further provide supplementary constraints related to the input information to improve analysis accuracy. In this embodiment, users can specify the range of the memory regions pointed to by each register, for example, specifying that the memory regions pointed to by registers rsi, rdx, and rcx correspond to different data structures, and that these memory regions do not overlap in the address space, thereby avoiding inaccurate analysis caused by address aliases.

[0068] Step S2-1: First, the annotation information provided by the user is standardized. In this embodiment, the user labels the large integer input region pointed to by rsi as "secret," and labels the modulus region pointed to by rdx, the lookup table region pointed to by rcx, the output buffer pointed to by rdi, and the array length represented by r8 as "public." The system converts the above annotations into an internal annotation table and records supplementary constraints such as the type, starting address, data length, and whether overlap with other memory regions is allowed for each input object.

[0069] Step S2-2: Perform a completeness check on the normalized annotation information. Specifically, the system determines whether rsi, rdx, rcx, rdi, r8 and their corresponding memory regions all have security level annotations based on the registers used at the function entry point, the memory access expressions appearing in the loop, and the set of input objects required for subsequent constant-time analysis. If an input object is found to be missing an annotation, for example, if the user only annotated rsi but not rcx or r8, the system records that object as an object to be completed.

[0070] Step S2-3: Further perform consistency and conflict detection on the annotation information. In this embodiment, the system checks whether the memory range constraints provided by the user are consistent with the annotation information. For example, if the user declares that rsi points to the secret input region, and rdx and rcx point to the public modulus region and the public lookup table region respectively, the system checks whether these memory regions are declared as non-overlapping; if the supplementary constraints show that the address ranges of rsi and rcx overlap, the system identifies this as an address range conflict. As another example, if the user declares that rsi points to the secret input region on the one hand, and on the other hand, labels this memory region as public, the system identifies this as an inconsistency in security level labeling.

[0071] Step S2-4: Complete, prompt, or correct the annotation information based on the integrity and consistency detection results. In this embodiment, for objects that are not explicitly labeled but can be inferred from their register roles, such as the loop counter r9 or the length parameter r8, the system can complete them as public; for data areas explicitly declared by the user as secret input, such as the large integer input area pointed to by rsi, the system retains its secret label; for objects with address range conflicts or security level conflicts, the system corrects them or prompts the user according to preset priority rules. When the security level of an input object cannot be uniquely determined, the system can adopt a conservative strategy to temporarily mark it as secret or mark it as an object to be confirmed.

[0072] Step S2-5: Generate a DBA intermediate representation based on the binary executable file and the security level annotation information processed in step S2-4. In this embodiment, register operations, arithmetic logic operations, memory loading and storing operations, loop jumps, and conditional branches in the program are all converted into corresponding DBA statements. Simultaneously, the input data pointed to by rsi is associated as a secret symbolic input in the DBA, while objects such as rdx, rcx, rdi, and r8 are associated as public symbolic input. Therefore, the subsequent DBA parsing module 13 can continue to extract variables, statements, and vulnerability patterns based on the DBA intermediate representation with security level attributes.

[0073] Step S3-1: Parse the DBA intermediate representation generated in Step S2 to extract key semantic information for subsequent analysis, including DBA variables, DBA statements, and potential vulnerability patterns. In this embodiment, register variables and memory variables in the program are first abstractly modeled. Registers (such as rsi, rdi, rcx, r10) and their corresponding symbolic expressions are parsed into DBA variables, and corresponding security attributes (public or secret) are attached to these variables according to the security level labeling information in Step S2. Specifically, the input data pointed to by register rsi will affect intermediate variables (such as register r10) during propagation, thus forming symbolic expressions with secret dependencies.

[0074] Step S3-2: Based on this, the DBA statements are further classified, and the key operation types related to constant-time safety properties are identified. Specifically, this embodiment mainly identifies the following two types of vulnerability patterns: Branching vulnerability pattern: corresponding to conditional jump statements, if the branch condition depends on secret-related variables (such as intermediate variables obtained from the propagation of input data), the execution path may change with the secret input, thus forming a timing side-channel risk; Memory access vulnerability pattern: corresponding to memory read and write statements, if the access address expression contains secret-related variables (such as a lookup index calculated based on register r10), it may cause memory access behavior to depend on secret input, thereby resulting in side-channel leakage.

[0075] Through the above parsing process, variable dependencies and vulnerability candidate patterns closely related to security analysis can be automatically extracted from the intermediate representation, providing a foundation for subsequent component generation and formal verification.

[0076] Step S3-3: Generate analysis components suitable for subsequent combinatorial verification based on the DBA information extracted in Step S3-1, including a function call graph, an inter-process control flow graph, and a function summary. The inter-process control flow graph is mainly constructed based on the program's control flow structure. Specifically, the function contains loop structures and condition-based branching structures: on the one hand, the loop control structure is driven by public variables (such as loop counters and length parameters), and its control flow remains consistent across different execution paths; on the other hand, after the loop ends, there is a conditional branch based on an intermediate variable (such as register r10), which depends on a secret input, resulting in secret dependency in branch path selection.

[0077] Therefore, the generated control flow graph contains multiple key branch nodes, which correspond to conditional jump statements in the program and are marked as potential vulnerability locations requiring focused analysis. Simultaneously, combined with the vulnerability pattern information identified in step S3-1, these branch nodes and their associated paths will be used for subsequent SMT constraint generation and relational symbolic execution verification.

[0078] The function summary mainly records information such as the function's input parameters, the SMT constraints to be analyzed, the correspondence between different variables and constraints, and the reachability of paths to be determined. In this embodiment, the input includes register information such as rsi, and the corresponding SMT constraints include the branch constraints and memory access constraints to be analyzed.

[0079] Furthermore, when generating the inter-process control flow graph, DBA basic blocks are used as graph nodes, and sequential execution relationships, conditional jump relationships, static jump relationships, dynamic jump relationships, function call relationships, and function return relationships in DBA statements are used as graph edges. For each function entry point, the entry address, exit address set, call point set, return point set, and the mapping relationship from the entry register and memory region to the function's formal parameters are recorded. For function call instructions, call edges are established based on the call target address, and return edges are established based on the return address; for dynamic calls or dynamic jumps where the target address cannot be statically determined, they are marked as dynamic control flow nodes that need to be further solved in the relational symbolic execution stage. When generating the function summary, in-process relational symbolic execution is performed on the internal paths of the function starting from the function entry point, collecting the path constraints, register state transitions, memory state transitions, and security assertion sets corresponding to each reachable path, and forming the corresponding path summary at the function exit. For cases where the same function is called multiple times, the subsequent analysis stage no longer traverses the internal statements of the function repeatedly, but instead substitutes the actual symbolic parameters at the call point into the corresponding function summary for instantiation, thereby achieving combinatorial verification based on the function summary.

[0080] Step S4: Convert the component information generated in Step S3 into the initial symbolic state, path conditions, security assertion template, and SMT constraint template to be verified required for relational symbolic execution. Specifically, first, initialize the relational symbolic state based on the security level annotation information obtained in Step S2. For public inputs, use the same symbol values ​​for modeling in both left and right execution paths; for secret inputs, use independent symbol values ​​for modeling in both left and right execution paths. Thus, public inputs satisfy equal left and right projections in the initial state, while secret inputs are allowed to have different left and right projections in the initial state.

[0081] When generating security assertion templates, corresponding constant-time security constraints are generated based on the DBA statement type: For conditional branch statements, extract the branch condition expression and generate a left and right projection consistency assertion for the branch condition, which is used to require that the left and right executions choose the same branch direction under the current path condition.

[0082] For memory load and memory store statements, extract the memory access address expression and generate an address left and right projection consistency assertion, which is used to require that the left and right paths access the same memory address under the current path conditions.

[0083] For dynamic jump statements, extract the jump target expression and generate a jump target left and right projection consistency assertion to require the left and right execution paths to jump to the same target address.

[0084] For each potential leak point, the current path condition is combined with the negation of the corresponding security assertion to form a vulnerability query constraint. If the vulnerability query constraint is satisfied, it means that there exists a set of left and right inputs that cause observable differences in the branch direction, memory access address, or dynamic jump target between the two execution paths; if the vulnerability query constraint is not satisfied, it means that the leak point satisfies the constant-time security requirement under the current path condition.

[0085] Step S5-1: Perform formal verification on the SMT constraints obtained in step S4 using relational symbolic execution.

[0086] Figure 2 The symbolic execution semantics rules for DBA programs are detailed below: (1) Basic instruction rules: The rule states that the skip statement in a DBA only triggers an update to the program counter, without changing the symbol state. or memory ; The rule then guides the execution flow to a terminated state. For assignment statements that do not access memory, The rules will include variables exist The mapping in the expression is updated. Corresponding relational value .

[0087] (2) Memory operation rules: When processing the memory load instruction, The rule first takes the address expression Resolved to relational address Then, using the SMT select primitive from Extract the corresponding symbolic memory value and And update Given that memory access may violate the constant-time safety property, this rule requires that constant-time safety constraints must be met. Similarly, The rules describe memory storage operations: it The obtained relation address Place the memory Updated to Corresponding relational value Similarly, this operation must satisfy constraints. To prevent information leakage at the memory address level.

[0088] (3) Control flow rules: For the branch instruction ite (if-then-else), in order to prevent the control flow from depending on secret inputs, the rule requires that the branch conditions must be public, that is, satisfying the condition. Furthermore, to maintain the synchronization of execution paths, the system requires that the left and right execution paths must select the same branch: in the true branch (rule) The following conditions must be met: In the false branch (rule) The following conditions must be met: .

[0089] (4) Jump instruction rules: Static jump rules Only the analysis location is updated. In contrast, dynamic redirection rules... The semantics are similar to branch instructions: except that it requires passing through In addition to function security checks, it is also necessary to ensure that both execution paths jump to the exact same target address. This satisfies the security requirements of control flow.

[0090] Step S5-2: Optimize SMT constraints using fault packaging optimization techniques. In this embodiment, the program contains multiple memory access statements in the loop body and branch paths, all of which correspond to potential memory access side-channel detection points. For example: input reading and intermediate result reading / writing in the loop body (e.g., based on rsi+). *8、rdi + *8 access), table lookup access in branch paths (such as access based on rcx + r10*8). Without optimization, each of the above memory access statements requires generating a separate SMT safety constraint, for example, verifying whether each address expression depends on a secret variable, thus generating a large number of independent solution requests. In this embodiment, multiple memory access safety conditions under the same basic block or the same path constraint are fault-packed, and multiple independent constraints are merged into a single SMT constraint through disjunction (OR), for example: .in, This represents the address expression corresponding to different memory access statements. This method combines multiple queries that would otherwise require multiple solver calls into a single query, significantly reducing the number of SMT solvers and improving overall analysis efficiency.

[0091] Step S5-3: Optimize SMT constraints using taint removal optimization techniques. In this embodiment, some variables in the program (such as the loop counter, array length, and address offset) only depend on public input and should not be misjudged as secret-related variables. Specifically, variables such as the loop counter... (Corresponding register r9) and length parameter (Register r8) only participates in loop control and address offset calculation throughout the entire execution process; its value does not depend on the secret input. Therefore, for the following expression: .in If it is a public variable, then * 8 is still a public expression. This represents the memory address expression. A security decision function identifies expressions that do not depend on secret inputs, thus marking them as public expressions and avoiding the generation of security verification constraints on them in subsequent analysis. This optimization removes variables that might otherwise participate in taint propagation from the secret dependency chain, retaining only variables truly propagated from the secret input (such as intermediate variable register r10), thereby reducing symbolic expression complexity and significantly decreasing the number of calls to the SMT solver.

[0092] Step S5-4: Optimize SMT constraints using a loop invariant generation method based on a large language model. In this embodiment, the program contains an explicit loop structure, the number of iterations of which is controlled by public variables (such as array length). However, the loop body involves operations on secret inputs. Directly expanding the loop would lead to path explosion. Therefore, this invention generates relational loop invariants using a large language model to characterize the relationships between variables during loop execution. Specifically, the loop invariants generated by the large language model include at least the following constraints: Loop variable range constraints: Consistency constraints for left and right execution paths: Memory access consistency constraints: Constraints on the propagation of taint: in This represents the length parameter (corresponding to register r8). This represents the loop counter (corresponding to register r9). and These represent the memory address expression and the memory starting address expression, respectively. This represents the XOR operation. This represents the intermediate calculation process within the loop body; in this embodiment, it refers to the calculation of the input element. and modulus elements After subtraction, the resulting invariant must satisfy the initialization, inductive, and sufficiency conditions, and its correctness must be verified by the SMT solver. Upon successful verification, this invariant will replace the loop unrolling process, thus avoiding the generation of an exponential number of paths. If the generated invariant fails verification within a preset time, the system will automatically revert to a bounded loop unrolling strategy to ensure the termination of the analysis process.

[0093] Step S5-5: Optimize the SMT constraints using memory read / write optimization methods. In this embodiment, the program exhibits a typical write-after-read pattern, meaning that after writing the calculation result to memory, the value is immediately read from the same address. For example, the following access pattern exists within the loop body: and In the unoptimized form, this operation would be modeled as a nested expression in SMT: This expression introduces additional nested array structures, thus increasing the solution complexity. Based on the fundamental axioms of array theory, the above expression can be directly reduced to: This eliminates redundant select-store nested structures. Furthermore, this invention introduces a memory access caching mechanism, recording the address and corresponding value of the most recently written operation during symbolic execution. When a subsequent access hits the cache, the result is returned directly, avoiding the repeated construction of complex expressions. Specifically, the memory access cache uses the normalized address expression as the key and the symbolic value written in the most recent store operation as the value. When a store operation is executed, the system records the written address expression and the written value in the memory access cache of the current path. If an old cache entry with a possible alias for the written address exists in the cache, it determines whether the two might point to the same address based on the current path conditions, and updates or invalidates cache entries that may have alias conflicts. When a load operation is executed, the system first queries the memory access cache of the current path based on the address expression to be read. If a cache address can be proven to be equal to the address to be read under the current path conditions, the corresponding cache symbolic value is returned directly. If a cache hit cannot be proven, it falls back to the standard select expression for symbolic reading. Through these optimizations, the SMT constraint size can be significantly reduced, and the solution efficiency improved.

[0094] Step S6-1: Solve the generated SMT constraints using the Bitwuzla solver and analyze the formal verification results. In this embodiment, the verification objects mainly include the constraints corresponding to various components optimized in step S5, including memory access constraints after fault packaging and branch control flow constraints. Specifically, the verification results of the following two types of key constraints are analyzed: Branching constraints: used to detect whether conditional jumps in a program depend on secret input; Memory access constraints: used to detect whether a memory access address expression contains secret-related variables.

[0095] By determining the satisfiability of the above constraints using the solver, it can be determined whether the corresponding program behavior satisfies the constant-time safety property.

[0096] Step S6-2: Based on the solution results in step S6-1, determine whether the analyzed executable file contains vulnerabilities that violate the constant-time safety property, and output the detection results to the user. In this embodiment, the analysis results show that the program contains both branching vulnerabilities and memory access vulnerabilities. Specifically: In the conditional statement after the loop ends, the branch condition depends on the intermediate variable (such as register r10) obtained by the propagation of input data, which causes the program execution path to depend on secret input, thus constituting a secret-related control flow vulnerability. During the table lookup process, the memory access address is calculated using the aforementioned secret-related variables (e.g., offset based on r10), which causes the memory access behavior to depend on secret input, thus constituting a secret-related memory access vulnerability.

[0097] Both types of vulnerabilities violate the constant-time security property. Therefore, the relational symbolic execution and optimization module 16 outputs relevant vulnerability information to the console or log system to provide intuitive feedback to the user.

[0098] Step S6-3: When a vulnerability violating the constant-time safety property is detected, the vulnerability information and corresponding constraint counterexamples will be further organized, and a structured vulnerability report will be generated and fed back to the user. In this embodiment, the generated vulnerability report includes at least the following: Vulnerability location: Corresponds to the instruction location in the program that triggers the vulnerability (such as secret-related branch statements and table lookup access statements); Vulnerability details: Describe the specific operation type that leads to the vulnerability, such as branch conditions depending on secret input or memory access addresses depending on secret variables; Vulnerability Category: Classified into control flow vulnerabilities or memory access vulnerabilities; Counterexamples: A set of specific input examples generated by the SMT solver that can trigger differences in control flow or memory access in the left and right execution paths, thus proving that the program does not satisfy the constant-time safety property.

[0099] Through the above report, users can not only locate the vulnerability, but also analyze the specific reasons for the vulnerability based on counterexample information, thereby providing a basis for subsequent program repair and optimization.

[0100] Example 2 A binary program efficient constant-time secure verification system, such as Figure 3 As shown, it includes: a security level labeling module 11, a DBA generation module 12, a DBA parsing module 13, a component generation module 14, a constraint generation module 15, and a relation symbol execution and optimization module 16.

[0101] The security level annotation module 11 is used to receive manual annotations from users on binary executable file input information, and to perform standardization processing, integrity detection, consistency detection, automatic completion, and conflict prompts or corrections on the annotation information, laying the foundation for subsequent DBA parsing and relational symbolic execution.

[0102] DBA generation module 12 is used to convert binary executable files into intermediate programs (DBAs) with a simpler structure, which facilitates subsequent analysis.

[0103] DBA parsing module 13 is used to convert intermediate DBA representations into DBA variables with security levels, supporting subsequent optimization and analysis of DBA statements, as well as vulnerability patterns that need to be detected.

[0104] The component generation module 14 is used to convert the DBA information output by module 13 into more detailed analysis components, including function call graphs, inter-process control flow graphs, and function summaries, thereby facilitating subsequent analysis.

[0105] The constraint generation module 15 converts the components generated by module 14 into SMT constraints for subsequent analysis.

[0106] The relational symbolic execution and optimization module 16 is primarily based on the Bitwuzla solver. It performs relational symbolic analysis on the SMT constraints generated by module 15 and further optimizes the SMT constraints using four methods: fault packaging, taint removal, loop invariant generation based on a large language model, and memory read / write optimization, thus facilitating subsequent analysis. In addition, it can analyze whether the SMT constraints satisfy constant-time safety properties or contain vulnerabilities. For cases with vulnerabilities, it can summarize the type, content, and location of the vulnerabilities and output them, along with constraint counterexamples generated by the solver, to the user. This assists the user in optimizing programs with vulnerabilities to avoid them.

[0107] Even in the absence of existing dedicated analysis tools, the method of this invention can still perform systematic side-channel security analysis on programs from two key dimensions: branch control flow and memory access, effectively ensuring the constant-time security properties of binary executable files.

[0108] The following table compares the performance of the method of this invention with that of Binsec / Rel, the most advanced tool in the field, on 43 common assembly function libraries. The assembly function libraries mentioned above are mainly derived from basic operations in cryptographic computation, including finite field addition Fr_add, finite field multiplication Fr_mul, binary OR operation Fr_bor, left shift operation Fr_shl, etc.

[0109] As can be seen, this invention outperforms the tool Binsec / Rel in both average analysis time and the number of vulnerabilities detected.

[0110] The above description is merely a description of preferred embodiments of this application and is not intended to limit the scope of this application in any way. Any changes or modifications made by those skilled in the art based on the above-disclosed technical content should be considered as equivalent and valid embodiments and fall within the scope of protection of the technical solution of this application.

Claims

1. A method for efficient constant-time security verification of binary programs, characterized in that, Includes the following steps: Step S1: The user marks the security level of the input information of the executable file according to their own needs; Step S2: Standardize, perform integrity and consistency checks on the security level labeling information provided by the user, and automatically complete missing labels within the inferable range, and provide prompts or corrections for conflicting or inconsistent labels. Generate a dynamic bit vector automaton (DBA) intermediate representation based on the binary executable file and the verified annotation information; Step S3: Parse the DBA intermediate representation generated in step S2 and convert the key processes therein into components that meet the requirements of combinatorial verification. The components include a function call graph, an inter-process control flow graph, and a function summary. Step S4: Convert the component into the initial symbolic state, path conditions, security assertion template, and SMT constraint template to be verified required for relational symbolic execution; Step S5: The SMT constraint template obtained in step S4 is formally verified using the Bitwuzla solver and relational symbolic execution to obtain the verification results. While performing relational symbolic execution, the SMT constraints are optimized using methods such as fault packing, taint removal, generation of loop invariants based on a large language model, and memory read / write optimization. Step S6: Based on the verification results of step S5, determine whether the executable file has vulnerabilities that violate the constant-time safety property. If vulnerabilities exist, use the location and number of vulnerabilities, as well as the constraint counterexamples obtained by the solver, as the final output report. Step S5 includes the following sub-steps: Step S5-1: The Bitwuzla solver is used, combined with relational symbolic execution analysis technology, to verify and analyze the SMT constraints; during the analysis, the methods in steps S5-2 to S5-5 are used for optimization operations. Step S5-2: Optimize SMT constraints using fault packaging optimization techniques; Step S5-3: Optimize SMT constraints using taint removal optimization techniques; Step S5-4: Optimize the component using a loop invariant generation method based on a large language model; Step S5-5: Optimize SMT constraints using memory read / write optimization methods; Step S5-1 specifically involves, In relational symbolic execution, program data is represented using relational formulas and modeled using left and right execution paths. make Given a standard set of quantifier arrays and bit vector logic QF_ABV first-order logic formulas, then the relational formulas... Defined as: The simple relational expression is: This indicates that the variable has the same value in both the left and right execution paths; while the pairing relation expression is... This indicates that the variable may have different sign values ​​in the left and right execution paths. , These are the symbol values ​​for the left and right execution paths, respectively. To extract the components of the left and right paths, a projection operation is defined: For Its left projection Right projection ;like ,but ; At the binary analysis level, the execution state of a program is formalized as a symbolic configuration, specifically a quadruple. ,in Indicates the position of the currently executing instruction; Maintain a single instruction location ; Symbolic state This represents the mapping from symbolic variables to corresponding relational formulas, where... A set representing symbolic variables; Represents symbolic memory, where and These represent 64-bit bit vector sets and 8-bit bit vector sets, respectively; in relational symbolic execution, memory is modeled as a pair of symbolic arrays. Each array conforms to the QF_ABV theorem and maps memory addresses to 8-bit relational expressions; path constraints. Record from the initial state to the current instruction position The input constraints that need to be satisfied; Relational symbolic execution detects the leakage of secret inputs by monitoring execution behavior: defining a security decision function. Used to evaluate symbolic expressions The safety of the leak point is as follows: Define a model that can assign specific numerical values ​​to symbolic variables. Path constraints In the model Satisfaction on is denoted as ; Without needing a specific model In this case, it is hidden and only processed through Symbols to represent constraints It is satisfyable; when When, it indicates the current symbolic expression. It is only affected by publicly available inputs and satisfies the constant-time safety property; while when When affected by secret input, if it does not satisfy the constraints This means that if this path is reachable, the observation results for both attackers will be the same, thus satisfying the constant-time safety property. Otherwise, there exists a set of input counterexamples that would cause the attacker's observations to differ, thus violating the constant-time security property; Configure the two symbols and The transition between them is represented as ; Judgment formula Indicates the current symbol state Relational symbolic memory Below, expression The evaluated relational expression ; The generation of loop invariants based on large language models is specifically as follows: From a formal perspective, the relational property to be verified can be represented as a Hall triple. This triple indicates that, from satisfying the preconditions... Starting from the state, execute the loop instruction. Afterwards, the system will inevitably enter a state where the postconditions are met. The state; without loss of generality, the loop instruction is defined as ,in This represents the loop condition expression. Indicates the loop body instruction; for attributes Candidate loop invariants The following three core principles must be met: Initialization: That is, the initial state of the cycle contains an invariant; Inductivity: That is, the effectiveness of the loop body in maintaining invariant properties; Sufficiency: That is, the invariant at the end of the loop is sufficient to prove the target property; The goal is to automate the synthesis of cyclic invariants that possess both inductive and sufficiency properties; Specifically, structured prompt words are used to guide the large language model in generating candidate loop invariants. To address the randomness of LLM output and improve the success rate, a multi-sampling strategy is adopted: a higher sampling temperature is set to enhance the diversity of candidate solutions, and the LLM is requested to generate a set containing n independent candidate relation invariants. ; In addition, the prompt words require that candidate loop invariants must contain relational predicates to characterize the synchronicity between the left and right execution paths; If there is a solution among the n candidate loop invariants that passes SMT verification, then the loop is considered to have passed verification, and the invariant will serve as a function summary for subsequent combinatorial verification; if the verification fails, LLM is guided to analyze the reasons for the verification failure, perform feedback-driven refinement, and regenerate. If a valid invariant cannot be synthesized within the preset time threshold, the process reverts to the bounded loop expansion mode.

2. The method according to claim 1, characterized in that, Step S1 includes the following sub-steps Step S1-1: For the input information of the executable file, the user annotates the input information of the binary executable file from two dimensions: register information and memory information. For these two different types of information, the user selects the registers or information that need to be paid attention to and annotates them as public or secret. In steps S1-2, after completing the annotation, the user provides supplementary constraint information, including: the data range of the register storage value, the storage address range of different information in memory, and whether different memory regions overlap. Step S2 includes the following sub-steps: Step S2-1: Standardize the security level labeling information provided by the user; Step S2-2: Perform an integrity check on the standardized security level labeling information; Step S2-3: Perform consistency and conflict detection on the security level labeling information; Steps S2-4 involve automatically completing, prompting, or correcting security level labeling information based on the results of integrity checks, consistency checks, and conflict checks. Specifically, for input objects with missing labels, the system infers their default security level based on the input object's type, variable name or register role, calling convention, parameter location, data source, memory access context, and preset rules, and generates complete labels. For labels with clear conflicts, the system corrects them based on user-provided supplementary constraints and preset priority rules. For input objects whose security level cannot be uniquely determined based on existing information, they are marked as objects to be confirmed, and the system prompts the user in the output results. Step S2-5: Based on the binary executable file and the verified security level labeling information obtained in step S2-4, generate the intermediate representation of the dynamic bit vector automaton (DBA). Step S3 includes the following sub-steps: Step S3-1: Parse the DBA program generated in step S2 and convert it into DBA variables and DBA statements required for subsequent analysis; Step S3-2: Based on the user's annotations, the intermediate language is converted into security variables with security levels, and the vulnerability patterns are organized according to the corresponding DBA statement types; the vulnerability patterns include control flow vulnerabilities related to branch statements and memory vulnerabilities related to memory access. Step S3-3: Based on the DBA information generated in step S3-2, generate information on different components required for subsequent analysis, including: function call graph, inter-process control flow graph, and function summary; The approach employs a combination verification strategy: during the pre-analysis phase, a function summary is generated for each function to encapsulate its input-output relationships and security constraints; during the main analysis phase following the pre-analysis phase, when the function is called, the system only needs to substitute the actual parameters into the function summary for instantiation and verify the constraints in the summary, thereby avoiding repeated scanning of the function's internal logic. In step S4, the initial symbol state is generated according to the security level of the input: for public input, the system uses the same symbol value to model in both left and right executions to represent that the public input takes the same value in the two executions; for secret input, the system uses independent symbol values ​​to model in both left and right executions to represent that the secret input can take different values ​​in the two executions. The security assertion template is generated based on the leakage pattern to be detected: for conditional branches, memory accesses, and dynamic jumps, left and right projection consistency assertions for branch conditions, access addresses, and jump targets are generated respectively, and the current path conditions are combined with the negative form of the security assertion to form vulnerability query constraints.

3. The method according to claim 1, characterized in that, The fault packaging specifically refers to... Instead of submitting each vulnerability query condition to the solver separately, multiple vulnerability query conditions under the same path constraint are merged through disjunction to form a packaged vulnerability query condition. Submit the packaged vulnerability query conditions to the solver to determine whether there is at least one memory access point with different left and right address projections under the path constraint π. If the packaged query cannot be satisfied, it means that there is no address leakage in the memory access of the current group under the current path constraint; if the packaged query can be satisfied, it means that there is at least one potential memory access leakage point under the current basic block or the same path constraint. The system records the statements of memory access in the current group as a set of candidate vulnerabilities in the report, and performs fine-grained splitting and verification of the set as needed.

4. The method according to claim 1, characterized in that, The stain removal specifically involves: During constant-time verification, security queries need to be frequently initiated to detect whether the expression is affected by secret inputs, i.e., whether it has been contaminated; based on the security determination function... If the expression is a simple relational expression This indicates that it relies solely on public input, naturally satisfies the constant-time safety property, and does not require verification by calling the solver; for pairwise relation expressions If the solver determines that it meets the safety constraints, it means that there is a solution under any execution path. It holds true; based on this equivalence relation, in the analysis... The variables involved are replaced with The corresponding variable in; Specifically, when a relational notation is executed, a pairing relational expression is obtained. When encountering this, first determine if the expression appears in subsequent branch conditions, memory access addresses, or dynamic jump targets; if the expression may affect the attacker's observable behavior, then constrain the current path. The following constructs an equivalence query to determine... Is it possible that the projections in the left and right execution paths are different? If so... and If the condition that the left and right projections are not equal cannot be satisfied, it means that under the current path conditions, although the expression is formally affected by the propagation of secret input, the execution results of its left and right paths are always equal, so it will not cause constant-time security leakage at subsequent observation points. If the above query cannot be satisfied, the expression is reduced from a pairing relation expression to a simple relation expression in the successor state of the current path, and recorded in the equivalence cache of the current path; If the same expression or an expression derived from it is encountered again in the future, the system will prioritize reusing the equivalent cached result to avoid generating security queries repeatedly. This taint removal only takes effect within the scope of subsequent analysis governed by the current path conditions, does not change the security level of the original input object, and does not affect the independent judgment of the expression under other paths.

5. The method according to claim 1, characterized in that, The memory read / write optimization (step S5-5) is as follows: Under the QF_ABV logical framework, the memory loading and storage operations are transformed into select and store primitives in SMT; Based on the axioms of array theory and The following two optimization strategies were designed and implemented, among which Represents memory, and They represent memory addresses, This indicates the memory value that needs to be loaded or stored: (1) Expression algebra reduction: using array theory to axiomatize semantics, simplifying redundant nested select / store structures; (2) Memory mapping cache mechanism: Cache mapping is introduced to record the initial memory layout and the write state during runtime; when the load instruction is executed, the system first searches the cache; if the cache is hit, the result is returned directly, thus avoiding the construction of complex symbolic expressions; if the cache is not hit, it falls back to the standard select instruction for symbolic reading.

6. The method according to claim 1, characterized in that, Step S6 includes the following sub-steps: Step S6-1: Analyze the results of formal verification using the Bitwuzla solver to determine whether the executable file has vulnerabilities that violate the constant-time safety property: For each security assertion, submit the current path condition and the negation form of the security assertion together to the Bitwuzla solver for satisfiability determination; when the solver returns unsatisfiable, the security assertion is marked as verified. When the solver returns a satisfied condition, the program location corresponding to the security assertion is marked as a candidate vulnerability point that violates the constant-time security property; When a vulnerability is detected, the system extracts counterexample information from the model returned by the solver, including the path conditions that trigger the vulnerability, the input assignments in the left and right execution paths, the vulnerability trigger location, the vulnerability type, the corresponding observation expression, and the difference results of the left and right projections. Subsequently, the system categorizes the above information according to functions, basic blocks, instruction addresses, and vulnerability types, and generates a structured vulnerability report. For the set of candidate vulnerabilities generated by fault packaging, the system records the corresponding basic block or path range in the report, and performs further unpacking verification according to user needs to locate the specific instruction; if no counterexamples that meet the vulnerability query conditions are detected, the system outputs the verification result; if the bounded loop expansion incomplete strategy is used in the analysis process, the corresponding verification boundary is marked in the report. Step S6-2: If the executable file contains a vulnerability that violates the constant-time security property, output the corresponding vulnerability to the console and display the vulnerability content. Step S6-3: If the executable file contains vulnerabilities that violate the constant-time safety property, the analyzed vulnerabilities and the constraint counterexamples obtained by the solver are summarized into a corresponding vulnerability report and fed back to the user.

7. A binary program efficient constant-time secure verification system, used to implement the method of any one of claims 1 to 6, characterized in that, include: The module includes a security level labeling module, a DBA generation module, a DBA parsing module, a component generation module, a constraint generation module, and a relation symbol execution and optimization module. The security level labeling module is used to receive manual labels from users on binary executable file input information, and to perform standardization processing, integrity detection, consistency detection, automatic completion, and conflict prompting or correction on the labeled information. The DBA generation module is used to convert binary executable files into DBA programs as intermediate representations. The DBA parsing module is used to convert intermediate representations of DBA programs into DBA variables with security levels, supporting subsequent analysis of DBA statements and vulnerability patterns that need to be detected. The component generation module is used to convert the DBA information parsed by the DBA parsing module into a function call graph, an inter-process control flow graph, and a function summary intermediate component. The constraint generation module is used to convert the components generated by the component generation module into SMT constraints that need to be verified. The relation symbolic execution and optimization module is used to perform symbolic execution and optimization on SMT constraints, and summarize the results to obtain the final vulnerability report and counterexample report.

Images