A password misuse detection method, device, medium and product supporting automatic rule derivation and cross-database analysis

Abstract

This application discloses a cryptographic misuse detection method, device, medium, and product that supports automatic rule derivation and cross-library analysis, relating to the field of information security. The method includes: obtaining the usage rules of a basic cryptographic library and formalizing them to obtain a cryptographic rule constraint library; a detection method that maps function constraints to function name matching; a detection method that maps parameter constraints and member variable constraints to data flow analysis; obtaining the complete source code and go.mod file of the project to be detected; and converting them into an intermediate representation in the form of a static single assignment; determining whether the calling function location is on a blacklist, and if so, generating an alarm; obtaining a first slicing criterion and its corresponding runtime value for parameter constraints; obtaining a second slicing criterion and its corresponding runtime value for member variable constraints; performing predicate judgment, and generating an alarm if the judgment condition is not met; and obtaining data flow analysis results and performing constraint derivation. This application can achieve high-precision cryptographic misuse detection.

Description

Technical Field

[0001] The present application relates to the field of information security, and in particular to a password misuse detection method, device, medium and product that supports automatic rule derivation and cross-database analysis. Background Art

[0002] Cryptographic misuse refers to the incorrect use of cryptographic APIs. Cryptography is an integral part of information security and fundamental to protecting data confidentiality, integrity, availability, authenticity, and non-repudiation. However, ensuring the correct use of these cryptographic algorithms has always been a challenge. Misconfiguration of various cryptographic algorithms during implementation can severely compromise their security. This can be due to a variety of factors. Some algorithm protocol APIs are overly complex, while documentation is unclear. Many developers lack necessary security training and are unaware of the security implications of potential misconfigurations. Legacy algorithms, however, lead to a large number of potentially insecure configurations. Cryptographic misuse can lead to ineffective network and software security, causing numerous serious security issues. For example, hard-coding keys in programs is a common cryptographic misuse. Attackers can easily obtain these keys through reverse engineering or source code auditing, compromising the confidentiality and integrity of communications.

[0003] Tools for detecting cryptographic misuse are currently categorized as static analysis tools and dynamic analysis tools. Static analysis tools do not require the actual execution of the program, making them well-suited for rapid and extensive detection. However, these tools are also prone to generating a large number of false positives (FP). In contrast, dynamic analysis tools can verify potential misuse scenarios, thus reducing the incidence of false positives. However, due to code coverage issues, dynamic tools can also produce missed negatives. Whether employing static or dynamic approaches, most existing tools (such as CogniCryptoSAST, CryptoGuard, and CryptoGo) rely on a blacklist / whitelist approach, which requires experts to manually create misuse rules for both basic library APIs available in various programming languages ​​and encapsulated APIs. This approach is not only time-consuming and labor-intensive, but also has limited scope: on the one hand, it can only detect predefined rules and cannot support dynamic rule updates; on the other hand, it struggles to adapt to unofficial cryptographic APIs and perform cross-library detection. While some research has explored the use of artificial intelligence for misuse detection, these approaches often face the challenge of autonomously generating reliable and effective rules. Although some studies have used artificial intelligence (machine learning / large language models) to automatically generate detection rules, the automatically generated detection rules still lack reliable guarantees.

[0004] Current cryptographic misuse analysis tools face two major challenges when analyzing complex, cross-library misuses: 1. Complex cross-library data flows. In large projects, code bases are often divided into multiple independently compiled libraries. This makes functions from other libraries opaque to the compiler, hindering accurate identification of behavior within other libraries (such as phantom methods in Java). Even with full access to the code base of a project's dependencies, cross-library data flow analysis still expands the scope of analysis, increasing analysis complexity. This complexity can lead to reduced analysis accuracy and increase the time and memory resources required for analysis. 2. Manually built, hard-coded detection rules. Most existing tools use hard-coded detection rules that are carefully designed by humans, making it difficult to expand the scope of APIs. When APIs are encapsulated, rules based on API names become ineffective, leading to missed detections. While CrySL, used in CogniCryptoSAST, partially addresses some of these hard-coding issues, all detection rules still need to be manually written by cryptography experts. Given the large number of unofficial cryptographic libraries and complex grammatical rules in real-world applications, writing rules for large-scale unofficial APIs remains a practical challenge. Furthermore, developers sometimes deliberately obfuscate function calls in an attempt to circumvent detection mechanisms. Summary of the Invention

[0005] The purpose of this application is to provide a cryptographic misuse detection method, device, medium and product that supports automatic rule derivation and cross-database analysis, which can achieve high-precision cryptographic misuse detection.

[0006] To achieve the above objectives, this application provides the following solutions:

[0007] In a first aspect, the present application provides a password misuse detection method that supports automatic rule derivation and cross-database analysis, including:

[0008] Obtaining usage rules of a basic cryptographic library; the usage rules include: function rules, parameter rules, and member variable rules;

[0009] Formalizing the usage rules of the basic cryptographic library application interface to obtain a cryptographic rule constraint library; the cryptographic rule constraint library includes: function constraints, parameter constraints, and member variable constraints;

[0010] Mapping the function constraints to a detection method that matches function names;

[0011] Mapping the parameter constraints and member variable constraints to a detection method for data flow analysis;

[0012] Get the complete source code and go.mod file of the project to be tested;

[0013] Convert the source code into an intermediate representation IR in a static single assignment form;

[0014] The detector receives a function name blacklist provided by the function constraints in the password rule constraint library, compares the positions of all calling functions involved in the program, compares the calling function name with the function name in the blacklist in the function constraints in the password rule constraint library, and issues an alarm if a function call in the blacklist is found;

[0015] For parameter constraints, extract function names and parameter information from the cryptographic rule constraint library, find the instruction that calls the function in the IR, and use the corresponding parameters in the instruction as the first slicing criterion;

[0016] Obtaining a runtime value of the first slicing criterion;

[0017] For member variable constraints, extract the structure and its member variable names from the cryptographic rule constraint library, find the instruction for storing the member variables corresponding to the corresponding structure in the IR, and use the variables stored in the storage instruction as the second slicing criterion;

[0018] Obtaining a runtime value of the second slicing criterion;

[0019] Performing a predicate judgment based on the runtime value of the first slicing criterion and the runtime value of the second slicing criterion, and issuing an alarm if the judgment condition is not met;

[0020] Determine whether the parameter node has an impact on the values ​​of the first slicing criterion and the second slicing criterion, and if so, execute the next step;

[0021] Based on the runtime value of the first slicing criterion and the runtime value of the second slicing criterion, using the symbol x to represent a function parameter, a data flow analysis result is obtained; the data flow analysis result is an expression containing a set of symbolic variables x;

[0022] Construct a system of equations based on predicate constraints and expressions involving a set of symbolic variables x;

[0023] Solving the system of equations using an SMT solver to obtain predicate information in the new constraints;

[0024] The data flow path of the new constraint generation process is used as the constraint reason, combined with the name and parameter information of the function, to generate a new parameter constraint in the password rule constraint library;

[0025] Integrate the parameter constraints of the same cryptographic library and convert them into a cryptographic rule constraint library document of a new cryptographic library.

[0026] Optionally, the function rules include: a danger function and a warning function; and the function constraints include: a danger function constraint and a warning function constraint.

[0027] Optionally, converting the source code into an intermediate representation IR in a static single assignment form specifically comprises the following steps:

[0028] Use the SSA package officially provided by golang to convert the source code into IR in static single assignment form.

[0029] Optionally, obtaining the runtime value of the first slicing criterion specifically includes the following steps:

[0030] Performing in-process backward slicing on the first slicing criterion to obtain a backward slicing result;

[0031] If an instruction of type a-f6 is encountered during the backward slicing process, the object of the instruction of type a-f6 is subjected to forward slicing within the process;

[0032] If the intermediate result of the forward slicing is not a function parameter, the slicing is terminated and the forward slicing result is obtained;

[0033] If the endpoint of the backward slicing is a function parameter, the function call point is found through the program call graph CHA, the corresponding position parameter of the function call point is used as the first slicing criterion, and the process returns to the first step;

[0034] Acquire all program statements that may affect the slicing criteria based on the backward slicing result and the forward slicing result, and construct a data flow propagation path graph;

[0035] Data flow analysis is performed based on the data flow propagation path graph to obtain a runtime value of the first slicing criterion.

[0036] Optionally, obtaining the runtime value of the second slicing criterion specifically includes the following steps:

[0037] Performing in-process backward slicing on the second slicing criterion to obtain a backward slicing result;

[0038] If an instruction of type a-f6 is encountered during the backward slicing process, the object of the instruction of type a-f6 is subjected to forward slicing within the process;

[0039] If the intermediate result of the forward slicing is not a function parameter, the slicing is terminated and the forward slicing result is obtained;

[0040] If the endpoint of the backward slicing is a function parameter, the function call point is found through the program call graph CHA, the corresponding position parameter of the function call point is used as the second slicing criterion, and the process returns to the first step;

[0041] Acquire all program statements that may affect the slicing criteria based on the backward slicing result and the forward slicing result, and construct a data flow propagation path graph;

[0042] Data flow analysis is performed based on the data flow propagation path graph to obtain a runtime value of the second slicing criterion.

[0043] Optionally, the a-f6 instructions include: store Store, unary operation Unop, change interface ChangeInterface, slice Slice, member variable address FieldAddr and array member address IndexAddr, and call Call.

[0044] In a second aspect, the present application provides a computer device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the password misuse detection method supporting automatic rule derivation and cross-library analysis as described above.

[0045] In a third aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the password misuse detection method for automatic derivation of support rules and cross-library analysis as described above.

[0046] In a fourth aspect, the present application provides a computer program product, comprising a computer program, which, when executed by a processor, implements the steps of any one of the above-mentioned methods for detecting password misuse by supporting automatic derivation of rules and cross-library analysis.

[0047] According to the specific embodiments provided in this application, this application discloses the following technical effects:

[0048] This application provides a cryptographic misuse detection method, device, medium and product that supports automatic rule derivation and cross-library analysis. It designs a "cryptographic rule constraint library" based on cryptographic characteristics, and uses a formal method to concisely represent the usage constraints of cryptographic APIs, overcoming the limitations of existing tools that are limited to specific detection rules and cryptographic libraries. It is constructed through three types of constraints. The "cryptographic rule constraint library" creates a clear intermediate formal representation method between natural language rules and specific code analysis tasks. This intermediate layer shields the specific detection tools designed from the dynamic changes of the underlying cryptographic rules, realizes the decoupling of the tool and the detection rules, and thus makes the detection tool dynamically scalable. The rules can be expanded and changed without secondary development of the tool; a new framework cryptographic misuse detection framework Goph is designed. er, compared with the previous cryptographic misuse detection framework, it introduces a feedback mechanism, allowing the tool to learn during the detection process. By using real-world code data, it can dynamically optimize and improve the "cryptographic rule constraint library" constraints, thereby deriving new cryptographic library usage constraints. This capability not only enables the tool to continuously improve itself during the scanning process and discover deeper misuse situations, but also supports the detection of unofficial encryption APIs and cross-library API calls, greatly reducing manual work; a high-precision and fast cryptographic misuse static analysis solution is designed. By performing forward and backward slicing before the data flow analysis process, the variable range in the data flow analysis process is narrowed, and the analysis speed is accelerated. By introducing forward slicing on the basis of backward slicing, the inaccurate impact of aliases on backward slicing when assigning values ​​through pointers is reduced, and the slicing accuracy is increased. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0050] Figure 1 This is a schematic diagram of the Gopher framework structure in one embodiment of the present application;

[0051] Figure 2 This is a schematic diagram of a password misuse detection method framework that supports automatic rule derivation and cross-database analysis in one embodiment of the present application;

[0052] Figure 3 This is a schematic diagram of nine types of predicates and their meanings in an embodiment of the present application;

[0053] Figure 4 A data flow propagation path diagram according to an embodiment of the present application;

[0054] Figure 5 This is a schematic diagram of the source code of the GenKey function encapsulated by the developer in demopkg in one embodiment of the present application;

[0055] Figure 6 This is the IR form of the GenKey function in one embodiment of the present application;

[0056] Figure 7 This is a schematic diagram of a CryDict document according to an embodiment of the present application;

[0057] Figure 8 A schematic diagram of the structure of a computer device provided in one embodiment of the present application. DETAILED DESCRIPTION

[0058] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0059] In order to make the above-mentioned purposes, features and advantages of the present application more obvious and easy to understand, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0060] This application designs a new framework - Gopher, see Figure 1 , used to achieve high-precision cryptographic misuse detection. Gopher consists of two core components: a "cryptographic rule constraint library" and a "detector," which are logically independent of each other. The "cryptographic rule constraint library" serves as a constraint library for the cryptographic application program interface (API), while the "detector" performs misuse detection based on these constraints and provides the "cryptographic rule constraint library" with necessary data flow information to further derive new constraints. Unlike existing cryptographic misuse analysis methods, Gopher introduces a formal representation layer and feedback mechanism, allowing the "cryptographic rule constraint library" to automatically generate new constraints for the encapsulated API by analyzing the data flow collected by the detector during misuse analysis. This mechanism significantly reduces the burden of manually designing constraints in previous tools. This innovation enables Gopher to dynamically adapt to updates to detection constraints and improve detection coverage without the need for secondary tool development. This effectively addresses the scalability challenges faced by tools that rely on static blacklist and whitelist approaches, enabling self-improvement and optimization of the tool during the detection process and explicit representation of implicit usage specifications in cryptographic libraries.

[0061] In the Gopher framework, constraints represent a formalized and standardized description of the usage rules of cryptographic APIs. As a core component of Gopher, the "Cryptographic Rules Constraint Library" can concisely and efficiently convert usage rules into formal constraints.

[0062] The Gopher framework consists of the following five stages: outlining the basic cryptographic library usage rules, building the "cryptographic rule constraint library" constraints, mapping the constraints to specific detection tasks, performing misuse detection and constraint derivation; combining Figure 2 The password misuse detection method supporting automatic rule derivation and cross-database analysis in this application specifically includes:

[0063] Phase 1: Overview of basic cryptographic library usage rules

[0064] Step 1: Obtain usage rules of the basic cryptographic library; the usage rules include: function rules, parameter rules, and member variable rules.

[0065] To ensure the correct use of the encryption API, the usage rules of the basic cryptographic library can be divided into three categories: function rules, parameter rules, and member variable rules.

[0066] Function rules

[0067] Function rules are the rules for correctly using cryptographic libraries at the function level. The confidentiality of ciphertext is directly related to the type of cryptographic algorithm used. Due to compatibility and other factors, cryptographic libraries often contain many functions that are not strong enough (such as MD5). Therefore, correctly using a cryptographic library requires first collecting various commonly used cryptographic algorithms and summarizing them based on currently available attack methods. This application further categorizes functions in the cryptographic library with security issues, including dangerous functions and warning functions.

[0068] Among them, the dangerous function category includes functions that are considered unsafe in cryptographic operations. It covers all dangerous algorithms (such as MD5 and DES). This type of constraint is classified based on the blacklist principle.

[0069] Warning functions: Functions in this category are not strictly prohibited, but more secure alternatives are recommended. This includes NIST-recommended replacement algorithms such as 3DES and deprecated functions in standard cryptography libraries.

[0070] Parameter rules

[0071] To ensure proper use of cryptographic libraries, in addition to using sufficiently strong functions, you also need to correctly configure function parameters. Function parameters directly affect the strength of various cryptographic algorithms. For example, while the RSA algorithm itself has no obvious security issues, configuring the RSA key parameter size to 512 bits will be extremely unsafe in 2024. According to NIST recommendations, the RSA key size should be set to at least 3072 bits in 2024.

[0072] Member variable rules

[0073] Most current programming languages ​​have a certain object-oriented design philosophy. To properly use cryptographic libraries, it's also necessary to correctly configure the member variables of key objects. For example, when configuring a TLS service, you need to enable domain name and certificate verification and configure the correct minimum TLS handshake version.

[0074] Phase 2: Building a "Password Rules Constraint Library"

[0075] Step 2: Formalize the usage rules of the basic cryptographic library application interface to obtain a cryptographic rule constraint library; the cryptographic rule constraint library includes: function constraints, parameter constraints and member variable constraints.

[0076] The "Cryptographic Rule Constraint Library" component initializes the constraints of the base cryptographic library based on the rules summarized in Step 1 and automatically derives the constraints of the encapsulated API using the constraint derivation in Step 5. These constraints serve as a formalized intermediate representation, bridging the gap between the natural language description of the cryptographic API and the specific detection tasks of the "detector," forming a dynamic constraint library of cryptographic API usage rules. This separation of constraints and detectors enables the framework to adapt to changes in the cryptographic library without requiring modifications to the developed detectors themselves.

[0077] The function of this step is to formally represent the usage rules of the natural language cryptography library summarized in step 1. For this purpose, this application designs a "cryptographic rule constraint library" to formally represent these rules.

[0078] (1) “Password Rule Constraint Library” document format design:

[0079] To provide a simple architecture, "Cryptographic Rule Constraint Library" constraint documents are defined at the library level. Each "Cryptographic Rule Constraint Library" document details the usage rules for a cryptographic library, beginning with a description of the library to which the constraint applies. A "Cryptographic Rule Constraint Library" can include three types of constraint specifications.

[0080] In the password rule constraint library, you first need to declare the name of the function library to be used, and then define the three constraints.

[0081] (a) Function Constraints

[0082] This category corresponds to the function rules in step 1 and is mainly used to impose constraints at the function level. Based on the security vulnerabilities of the function, it can be further divided into two subcategories:

[0083] (a.1) Dangerous Fun_Constraints

[0084] This category corresponds to dangerous functions, including functions that are considered unsafe for cryptographic operations. It covers all dangerous algorithms (such as MD5 and DES). The constraints of this category are simply a list of all dangerous cryptographic functions and the reasons why they are classified as dangerous.

[0085] (a.2) Warning Function Constraints (WarningFun_Constraints)

[0086] This category corresponds to warning functions and includes functions that aren't strictly prohibited but are recommended for replacement. This includes algorithms recommended by NIST, such as 3DES, as well as deprecated functions in standard cryptographic libraries. This section is structured identically to the dangerous function constraints, directly listing the names of all banned algorithms and the reasons for their disabling. Compared to the dangerous function constraints, the algorithms listed here are less dangerous.

[0087] (b) Parameter Constraints

[0088] Parameter constraints ensure the safe use of function (or method) parameters by defining the constraints on them. Parameter constraints need to declare the function name corresponding to the parameter, the parameter position, the constraint predicate that the parameter needs to satisfy, and the reason for this constraint. In order to construct the constraints on parameters and member variables in the "Password Rule Constraint Library", a total of 10 types of predicates are designed, such as Figure 3 shown.

[0089] Phase 3: Mapping constraints to specific detection tasks

[0090] Step 3: Map the function constraints to a detection method for function name matching.

[0091] Step 4: Map the parameter constraints and member variable constraints to a detection method of data flow analysis.

[0092] The goal of steps 3 and 4 is to establish a mapping strategy that connects the "Password Rule Constraint Library" constraints with specific target detection tasks (such as taint analysis or program slicing), and to tailor analysis methods for different types of constraints. This is a one-time design effort during the tool development phase. Subsequently, changes in the scope of API detection can be addressed by simply updating the "Password Rule Constraint Library" constraints, without requiring further modifications to the "detector."

[0093] Specifically, the three types of constraints are mapped to two types of detection methods.

[0094] First, map function constraints to function name matching detection method

[0095] For function constraints, the detector compares each function call in the program against the function name, using a function name matching method. When a function call matches an entry in the pre-established blacklist of function constraints in the "Password Rule Constraint Library," the detector immediately marks it as misused.

[0096] Second, the detection method of mapping parameter constraints and member variable constraints to data flow analysis

[0097] For parameter constraints (Parameter_Constraints) and member variable constraints (Field_Constraints), this application analyzes the potential runtime values ​​of the corresponding variables through program slicing and data flow analysis. The detector compares whether the runtime value meets the requirements of the corresponding predicate. If not, the "detector" will immediately mark it as misused. The detector accepts the slicing criteria as the variable to be analyzed for data flow. The slicing criteria is converted from the function name and parameter name (or structure name and member variable name) information in the "password rule constraint library" and accepts the predicate information in the "password rule constraint library" to judge the runtime value. The slicing criteria is formally expressed as < instr,v > , where instr represents a function call or storage instruction for a variable of a specific type, and v is the variable associated with it. During program slicing, for parameter constraints, the detector uses the actual parameters related to the function call as the slicing criteria. For member variable constraints, the right-hand side variable in the assignment statement is used as the slicing criteria for the corresponding object type. After performing data flow analysis, if a variable v may be corresponding to multiple potential runtime values ​​r∈R, if these runtime values ​​can all satisfy the constraints, that is, ∧ r∈R P ( r ) = True, then the call to the cryptographic library is considered safe.

[0098] Phase 4: Perform misuse detection

[0099] Steps 5-12 below are where the "detector" performs misuse detection and collects the data flow information required for subsequent constraint derivation. When performing cross-library detection, only the constraints of the called library need to be loaded. This design is fully decoupled, meaning that any static or dynamic detection tool that can recognize the constraints of the "password rule constraint library" can be adapted, ensuring the high compatibility and scalability of the Gopher framework.

[0100] This application uses a "detector" to perform misuse detection. The specific detection process is as follows:

[0101] Step 5: Get the complete source code and go.mod file of the project to be tested.

[0102] This application implements source code acquisition using the Gophe framework for Go language detection. To perform misuse detection, the implemented tool first retrieves the complete source code of the project being tested. Furthermore, it also requires the go.mod file for the project being tested. The go.mod file is the core configuration file of the Go language module system, recording the basic information and dependencies of a Go module. Since the introduction of module support in Go 1.11, the go.mod file has become a standard method for managing Go project dependencies. Using the go.mod file, you can accurately retrieve all of a project's dependency information.

[0103] Step 6: Convert the source code into an intermediate representation IR in a static single assignment form.

[0104] Intermediate Representation (IR) is an abstract representation commonly used in static analysis. IR is a high-level abstraction that is closer to the essential structure of a program than the source code. Using the SSA package officially provided by golang, the source code can be converted into IR in the form of SSA (static single assignment). During the IR generation process, a syntax tree is constructed, which eliminates many details related to the specific programming language, helping to simplify the subsequent analysis process. In a program, when a variable is assigned a value for the first time, we call it a "definition". Using IR in the form of SSA, each variable has a unique definition, which helps to track variables when slicing during data flow analysis.

[0105] Step 7: The detector receives the function name blacklist provided by the function constraints in the password rule constraint library, compares the locations of all called functions involved in the program, and compares the called function name with the function name in the blacklist in the function constraints in the password rule constraint library. If a function call in the blacklist is found, an alarm is issued.

[0106] This step, called function comparison, accepts detection tasks converted from function constraints. Following the same approach as in Phase 3, the detector receives the function name blacklist provided by the "Function Constraints" in the "Password Rule Constraint Library." It compares the locations of all function calls in the program and compares the names of the called functions with the blacklisted function names in the "Password Rule Constraint Library" function constraints. If a blacklisted function call is found, an alert is issued.

[0107] Step 8: For parameter constraints, extract the function name and parameter information from the cryptographic rule constraint library, find the instruction that calls the function in the IR, and use the corresponding parameters in the instruction as the first slicing criterion.

[0108] Step 9: Get the runtime value of the first slicing criterion.

[0109] Step 10: For member variable constraints, extract the structure and its member variable names from the cryptographic rule constraint library, find the instruction in the IR to store the corresponding member variables of the corresponding structure, and use the variables stored in the storage instruction as the second slicing criterion.

[0110] Step 11: Obtain the runtime value of the second slicing criterion.

[0111] The above steps 8 to 11 are slicing criterion positioning and data flow analysis, corresponding to a detection method of mapping parameter constraints and member variable constraints to data flow analysis.

[0112] Steps 8-11 above receive detection tasks converted from parameter constraints and member variable constraints. This detection task first maps these two types of constraints to specific slicing criteria. By analyzing the IR, the potential runtime values ​​of the slicing criteria are obtained. These potential runtime values ​​are used for "predicate judgment." For detection tasks converted from parameter constraints and member variable constraints, according to the method of stage three, the function name and parameter information are extracted from the "password rule constraint library" for the parameter constraint. The instruction calling the function in the IR is found, and the corresponding parameters in the instruction are used as the slicing criteria.

[0113] For example, the CryDict document of the cryptographic rule constraint library specifies the predicate information GEQ(1,3072) for the RSA key generation function func GenerateKey(rand io.Reader, bits int), indicating that the parameter bits at the second position of GenerateKey (the computer starts counting from 0) must be greater than or equal to 3072.

[0114] When matching the slicing criteria, find all instructions that call GenerateKey in the IR and use the variable at the position corresponding to the second parameter in these call instructions as the slicing criteria.

[0115] The data flow propagation path graph is constructed through program slicing, and then the possible runtime value of each node (including slicing criteria) is updated in sequence.

[0116] When performing predicate judgment, after analysis, the potential runtime value of the slicing criterion is obtained. For example, it is found that the variable at this position in the program may be {1536,5120}. Then these results are used to compare the predicate information in the document (greater than or equal to 3072) in turn. If it is found that the runtime value 1536 does not meet the requirement of being greater than or equal to 3072, an alarm is issued.

[0117] As for member variable constraints, the structure and its member variable names are extracted from the "Cryptographic Rule Constraint Library", and the instructions for storing the corresponding member variables of the corresponding structure in the IR are found. The variables stored in the storage instructions are used as slicing criteria. In order to determine the runtime value corresponding to the specified variable at the slicing criterion position, data flow analysis is required to construct the data flow information of the corresponding parameters. In order to reduce the workload of data flow analysis, this application first adopts a combination of backward slicing and forward slicing to reduce the range of variables involved in the data flow analysis process.

[0118] Backward Slicing starts from a point in the program and traces the definition and use of all variables that affect that point. Backward slicing first needs to determine the slicing point (slicing criterion), and then needs to find all definitions of the variable and trace back along the definition path. In the SSA form, since each variable has only one definition, it is easy to trace the path from definition to use in all functions based on IR. Through the results of SSA, it is easy to perform backward slicing of programs within a process. In order to construct backward slicing between processes, this application constructs a call graph through Class Hierarchy Analysis (CHA). Through the results of CHA, this application uses the parameters of the function call point as a new slicing criterion to perform recursive program analysis within the process, which can achieve backward analysis between processes.

[0119] However, only backward slicing is difficult to accurately analyze the program. Pointers are often used in programs, which leads to the emergence of aliases. Aliases refer to the situation where multiple variables or pointers in the program point to the same memory address. In the presence of aliases, that is, when multiple variables reference the same memory location, the result of backward slicing may miss some important definitions and usage relationships, making it difficult to fully capture the actual assignment source of the variable. In order to ensure accurate and efficient data flow analysis. This application performs local forward slicing on multiple instruction types, including:

[0120] (a) Store, indicating pointer assignment;

[0121] (b) Unop (unary operation), extract the pointer value;

[0122] (c) ChangeInterface (change interface), used for interface creation;

[0123] (d) Slice, generates a slice of an array structure;

[0124] (e) FieldAddr (member variable address) and IndexAddr (array member address), used to access structure fields and slice values;

[0125] (f) Call, allows exploration of orthogonal functions.

[0126] When the above instructions are encountered during the backward slicing process, the variables involved in these instructions will be sliced ​​forward. During the forward slicing process, all instructions between the above instructions and the slicing criteria will be searched in order from front to back, tracking down all instructions that use the variables involved in the above instructions and may affect the values ​​of the variables (for example, instructions that assign values ​​to variables through pointers, function calls).

[0127] This check helps to quickly discover aliases and potential assignments during backward slicing, enabling efficient localization of cryptographic misuses and ensuring that only necessary nodes are analyzed during data flow analysis, reducing analysis time and memory usage without sacrificing accuracy.

[0128] Through the results of backward and forward slicing, we can obtain all program statements that may affect the slicing criteria and construct a path diagram for data flow propagation. For details, see Figure 4 .

[0129] In the process of data flow analysis, this application marks nodes as n∈N. These nodes usually correspond to variables. In order to increase the accuracy of data flow analysis, a node N contains context and field information: N = ssaValue×Context×Field. For node n, Represents the input node set of node n, where Is the kth input node. Each node may correspond to multiple input nodes. For example, there are two input nodes for the node representing the addition operation. Res(n) represents the set of possible runtime values ​​corresponding to node n. In the process of data flow analysis, this application starts from the node with 0 input nodes (such as constant nodes) and analyzes all potential runtime values ​​corresponding to each node in turn until all potential runtime values ​​in the slicing criteria are obtained. The following table 1 is Figure 4 The data flow analysis results obtained from the data flow propagation path diagram are shown in the table. The left column is the node name, and the right column is all the potential runtime values ​​of the corresponding nodes.

[0130] Table 1 Data flow analysis results obtained from the data flow propagation path diagram

[0131] N Res(N) Constant 4096 {4096} Constant 512 {512} t0 {4096,512} e {4096,512} Constant 1024 {1024} t1 {5120,1536}

[0132] The codes corresponding to Table 1 above are as follows:

[0133]

[0134]

[0135] IR Code:

[0136]

[0137]

[0138] Step 12: Perform predicate judgment based on the runtime value of the first slicing criterion and the runtime value of the second slicing criterion. If the judgment condition is not met, an alarm is issued.

[0139] This step is used to judge the results of slicing criterion positioning and data flow analysis. After obtaining the potential runtime value of the slicing criterion variable, the detector will judge whether the runtime value satisfies the corresponding predicate according to the predicate definition, that is, ∧ r∈Res If P(r) = True, the detector issues an alarm. For example, for the constraint GEQ(1,3072) for the RSA key generation function in the "Cryptographic Rule Constraint Library," the detector checks whether the runtime values ​​of the second variable bits in all calls to the key generation function in the program are greater than or equal to 3072. If not, the detector issues an alarm.

[0140] Phase 5: Constraint Derivation

[0141] Step 13: Determine whether the parameter node has an impact on the values ​​of the first slicing criterion and the second slicing criterion. If so, proceed to the next step.

[0142] That is, in the previously constructed data flow propagation path graph, if it is found that the constructed data flow propagation path graph involves parameter nodes, it is proved that the parameter nodes have an impact on the numerical value of the slicing criterion, and the constraint derivation will be triggered at this time.

[0143] Step 14: Based on the runtime value of the first slicing criterion and the runtime value of the second slicing criterion, a data flow analysis result is obtained by using the symbol x to represent the function parameter; the data flow analysis result is an expression containing a set of symbolic variables x.

[0144] Step 15: Construct a system of equations based on the predicate constraints and expressions involving a set of symbolic variables x.

[0145] Step 16: Solve the equations using an SMT solver to obtain predicate information in the new constraints.

[0146] Step 17: Use the data flow path of the new constraint generation process as the constraint reason, and combine it with the function name and parameter information to generate a new parameter constraint in the password rule constraint library.

[0147] Step 18: Integrate the parameter constraints of the same cryptographic library and convert them into a cryptographic rule constraint library document of a new cryptographic library.

[0148] To derive new cryptographic library usage constraints from existing constraints, reducing the significant overhead of manually designing a "cryptographic rule constraint library" for all function libraries, this application has designed a constraint derivation method. This constraint derivation requires the data flow information provided in Stage 4. This step automatically generates the CryDict document corresponding to the user's newly packaged cryptographic library.

[0149] The purpose of steps 13 to 18 above is to automatically generate the "cryptographic rule constraint library" formal constraints of the new cryptographic library after the developer has performed secondary development on the existing cryptographic library. Assume that in the new cryptographic library, the developer has designed an encapsulation of the API of the original cryptographic library. Given a newly developed function parameter Pa involving an existing constraint φ, the parameter node is first symbolically represented as x. Based on the data flow analysis results in stage 4, the symbolic execution is traced along the data propagation path. We denote the symbolic execution result set of node n as O ( n ) Compared with the analysis results of the data flow in stage 4, since we do not obtain the runtime value of the parameter node here, but represent the parameter node as x, the result of the data flow analysis here is O ( n )It should be a set of expressions containing a set of unknown variables x. Therefore, if the newly developed function is to be used correctly, these expressions containing positional variables x should satisfy the predicate constraint φ for . Therefore, a function parameter can be expressed as follows:

[0150]

[0151] This constraint is formally a system of equations in one variable. By applying an SMT solver, we can obtain the constraints required for the encapsulated cryptographic function to function correctly, specifically the conditions that x must satisfy. The SMT solver can then extract the predicate information from the new constraint. Using the data flow path of the constraint generation process as the constraint reason, combined with the function name and parameter information, we can generate parameter constraints for a new cryptographic rule constraint library. By grouping parameter constraints from the same cryptographic library together, we can create a "Cryptographic Rule Constraint Library" document for the new cryptographic library.

[0152] For example, Figure 5 This is the source code of the GenKey function encapsulated by the developer in demopkg. Figure 6 It is the IR form of the GenKey function. When t1 is used as the first slice criterion analysis running value in stage four, the corresponding data flow propagation path graph will be constructed. The parameter node e of GenKey is involved in the constructed path graph, so it is judged that constraint deduction work needs to be performed on e. After parameterizing the parameter e as x, the propagation path is recursively traced along the data flow propagation path graph, symbolic execution is performed, and the values ​​corresponding to the nodes in the graph are updated to obtain the results in Table 2. Among them, the symbolic execution result of the first slice criterion is O(n_slice_criteria)={x+1024}. The constraint that the original slice criterion needs to meet is GEQ(0,3072). After being solved by the SMT solver, the parameter e of GenKey needs to meet GEQ(0,2048). The final CryDict document obtained is as follows Figure 7 shown.

[0153] Table 2 Symbolic execution results obtained from the data flow propagation path diagram

[0154] N Res(N) e {x} Constant 1024 {1024} t1 {x+1024}

[0155] Step 19: After obtaining the new cryptographic rule constraint document, you can load the new document and detect the calls to the newly encapsulated cryptographic library in the application according to steps 8 to 12. During the detection process, there is no need to load the source code of the encapsulated library again, nor is there any need to perform cross-library program analysis. You only need to perform in-library detection on the calls to the encapsulated cryptographic library according to the constraint information in the new document to achieve the effect of cross-library analysis.

[0156] Through the design of Phase 5 and the "Password Rule Constraint Library," this application can avoid three drawbacks of manually created, hard-coded detection rules in tools:

[0157] First, all detection rules need to be manually written by cryptography experts, but the secondary encapsulated cryptography library is massive, making it difficult for cryptography experts to write them traversally.

[0158] Secondly, this approach avoids the difficulty of expanding the API scope found in previous hard-coded methods. In previous hard-coded tools, any cryptographic algorithm update required a complete redesign and recompilation. Otherwise, the tool would be unable to detect the new API, leading to missed detections. This application only requires updating the "cryptographic rule constraint library," allowing the tool to adapt to new APIs without requiring further development.

[0159] The third aspect is the cross-library cryptography library detection. Due to the huge overhead of static analysis across libraries, previous tools have found it difficult to perform cross-library cryptography library usage detection. In this application, through the constraint derivation function, it is possible to generate the constraints required for all cross-function library detection. For example, when a developer is developing using the GenKey function in the newly encapsulated cryptography library demopkg, the tool directly loads the "Cryptographic Rule Constraint Library" document corresponding to the demopkg derived in step 17 (see the following code for details), performs program slicing within the library, and performs SSA and data flow analysis. The effect of cross-library detection can be achieved without loading demopkg and all other related source codes. This avoids the huge overhead of previous cross-library analysis and achieves rapid cross-library detection.

[0160] In an exemplary embodiment, a computer device is provided. The computer device may be a server or a terminal. The internal structure diagram thereof may be as follows: Figure 8 As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, abbreviated as I / O) and a communication interface. The processor, memory and input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The database of the computer device is used to store password misuse detection method data. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a password misuse detection method is implemented.

[0161] Those skilled in the art will understand that Figure 8 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0162] In an exemplary embodiment, a computer device is further provided, including a memory and a processor. The memory stores a computer program, and the processor implements the steps in the above method embodiments when executing the computer program.

[0163] In an exemplary embodiment, a computer-readable storage medium is provided, storing a computer program. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0164] In an exemplary embodiment, a computer program product is provided, including a computer program. When the computer program is executed by a processor, the steps in the above method embodiments are implemented.

[0165] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant regulations.

[0166] Those skilled in the art will understand that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, database or other media used in the embodiments provided in this application may include at least one of non-volatile and volatile memory. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory may include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM may be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM).

[0167] The databases involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, distributed databases based on blockchains. The processors involved in the various embodiments provided herein may include, but are not limited to, general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic units, data processing logic units based on quantum computing, and the like.

[0168] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0169] This document uses specific examples to illustrate the principles and implementation methods of this application. The description of the above examples is only intended to help understand the method and core concept of this application. At the same time, for those skilled in the art, based on the concept of this application, there may be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as limiting this application.

Claims

1. A password misuse detection method that supports automatic rule derivation and cross-database analysis, characterized in that: The password misuse detection method comprises: Obtaining usage rules for a basic cryptographic library application interface; the usage rules include: function rules, parameter rules, and member variable rules; Formalizing the usage rules of the basic cryptographic library application interface to obtain a cryptographic rule constraint library; the cryptographic rule constraint library includes: function constraints, parameter constraints, and member variable constraints; Mapping the function constraints to a detection method that matches function names; Mapping the parameter constraints and member variable constraints to a detection method for data flow analysis; Get the complete source code and go.mod file of the project to be tested; Convert the source code into an intermediate representation IR in a static single assignment form; The detector receives a function name blacklist provided by the function constraints in the password rule constraint library, compares the positions of all calling functions involved in the program, compares the calling function name with the function name in the blacklist in the function constraints in the password rule constraint library, and issues an alarm if a function call in the blacklist is found; For parameter constraints, extract function names and parameter information from the cryptographic rule constraint library, find the instruction that calls the function in the IR, and use the corresponding parameters in the instruction as the first slicing criterion; Obtaining a runtime value of the first slicing criterion; For member variable constraints, extract the structure and its member variable names from the cryptographic rule constraint library, find the instruction for storing the member variables corresponding to the corresponding structure in the IR, and use the variables stored in the storage instruction as the second slicing criterion; Obtaining a runtime value of the second slicing criterion; Performing a predicate judgment based on the runtime value of the first slicing criterion and the runtime value of the second slicing criterion, and issuing an alarm if the judgment condition is not met; Determine whether the parameter node has an impact on the values ​​of the first slicing criterion and the second slicing criterion, and if so, execute the next step; Based on the runtime value of the first slicing criterion and the runtime value of the second slicing criterion, using the symbol x to represent a function parameter, a data flow analysis result is obtained; the data flow analysis result is an expression containing a set of symbolic variables x; Construct a system of equations based on predicate constraints and expressions involving a set of symbolic variables x; Solving the system of equations using an SMT solver to obtain predicate information in the new constraints; The data flow path of the new constraint generation process is used as the constraint reason, combined with the name and parameter information of the function, to generate a new parameter constraint in the password rule constraint library; Integrate the parameter constraints of the same cryptographic library and convert them into a cryptographic rule constraint library document of a new cryptographic library.

2. The password misuse detection method supporting automatic rule derivation and cross-database analysis according to claim 1 is characterized in that: The function rules include: a danger function and a warning function; the function constraints include: a danger function constraint and a warning function constraint.

3. The password misuse detection method supporting automatic rule derivation and cross-database analysis according to claim 1 is characterized in that: The conversion of the source code into an intermediate representation IR in a static single assignment form specifically includes the following steps: Use the SSA package officially provided by golang to convert the source code into IR in static single assignment form.

4. The password misuse detection method supporting automatic rule derivation and cross-database analysis according to claim 1 is characterized in that: The step of obtaining the runtime value of the first slicing criterion specifically comprises the following steps: Performing in-process backward slicing on the first slicing criterion to obtain a backward slicing result; If an instruction of type a-f6 is encountered during the backward slicing process, the object of the instruction of type a-f6 is subjected to forward slicing within the process; If the intermediate result of the forward slicing is not a function parameter, the slicing is terminated and the forward slicing result is obtained; If the endpoint of the backward slicing is a function parameter, the function call point is found through the program call graph CHA, the corresponding position parameter of the function call point is used as the first slicing criterion, and the process returns to the first step; Acquire all program statements that may affect the slicing criteria based on the backward slicing result and the forward slicing result, and construct a data flow propagation path graph; Data flow analysis is performed based on the data flow propagation path graph to obtain a runtime value of the first slicing criterion.

5. The password misuse detection method supporting automatic rule derivation and cross-database analysis according to claim 1 is characterized in that: Obtaining the runtime value of the second slicing criterion specifically includes the following steps: Performing in-process backward slicing on the second slicing criterion to obtain a backward slicing result; If an instruction of type a-f6 is encountered during the backward slicing process, the object of the instruction of type a-f6 is subjected to forward slicing within the process; If the intermediate result of the forward slicing is not a function parameter, the slicing is terminated and the forward slicing result is obtained; If the endpoint of the backward slicing is a function parameter, the function call point is found through the program call graph CHA, the corresponding position parameter of the function call point is used as the second slicing criterion, and the process returns to the first step; Acquire all program statements that may affect the slicing criteria based on the backward slicing result and the forward slicing result, and construct a data flow propagation path graph; Data flow analysis is performed based on the data flow propagation path graph to obtain a runtime value of the second slicing criterion.

6. The password misuse detection method supporting automatic rule derivation and cross-database analysis according to claim 4 is characterized in that: The a-f6 instructions include: Store, Unop, ChangeInterface, Slice, FieldAddr, IndexAddr, and Call.

7. A computer device comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the password misuse detection method supporting automatic rule derivation and cross-library analysis as described in any one of claims 1-6.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the password misuse detection method supporting automatic rule derivation and cross-database analysis according to any one of claims 1 to 6 are implemented.

9. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the password misuse detection method supporting automatic rule derivation and cross-database analysis according to any one of claims 1 to 6 are implemented.

Images