Password misuse detection method and device supporting automatic rule derivation and cross-library analysis, medium and product

Abstract

The invention discloses a password misuse detection method and device supporting automatic rule derivation and cross-library analysis, a medium and a product, and relates to the field of information security, and the method comprises the steps: obtaining a use rule of a basic password library, and carrying out the formalized expression of the use rule, and obtaining a password rule constraint library; function constraints are mapped to a function name matching detection method; a detection method for mapping parameter constraints and member variable constraints to data flow analysis; obtaining a complete to-be-detected item source code and a go.mod file; the intermediate representation is converted into an intermediate representation in a static single assignment form; judging whether the position of the calling function is in a blacklist or not, and if yes, giving an alarm; aiming at the parameter constraint, obtaining a first slicing criterion and a corresponding runtime value; acquiring a second slicing criterion and a corresponding runtime value according to the member variable constraint; predicate judgment is carried out, and if judgment conditions are not met, an alarm is given; and obtaining a data flow analysis result and carrying out constraint derivation. According to the invention, high-precision cryptography misuse detection can be realized.

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] Cryptography misuse refers to the incorrect use of cryptography APIs. Cryptography is an integral part of the information security field and is the basis for protecting data confidentiality, integrity, availability, authenticity, and non-repudiation. However, ensuring the correct use of these cryptographic algorithms has always been a difficult problem. Incorrect configuration of various encryption algorithms during application implementation seriously reduces the actual security assurance of these cryptographic algorithms. There are many reasons for this. Some algorithm protocol API interfaces are too complex, but the relevant documentation is unclear. Many developers lack the necessary security training and are unaware of the security impact of potential misconfigurations. Some legacy algorithms have led to a large number of potential insecure configurations. Cryptography misuse has led to the inability to effectively ensure network and software security, and has caused many serious security issues. For example, hard-coding keys in programs is a common cryptographic misuse. Attackers can easily obtain keys through reverse engineering or source code audits, thereby destroying the confidentiality and integrity of communications.

[0003] Tools for detecting cryptographic misuse are currently mainly divided into static analysis tools and dynamic analysis tools. Static analysis tools do not require the actual running of the program, which makes them very suitable for fast and extensive detection tasks. However, such tools are also prone to a large number of false positives (FP). In contrast, dynamic analysis tools are able to verify potential misuse situations, thereby reducing the occurrence of false positives. However, due to the problem of code coverage, dynamic tools may cause missed detections. Regardless of whether static or dynamic methods are adopted, most existing tools (CogniCryptoSAST, CryptoGuard, and CryptoGo, etc.) rely on black / white lists, which require experts to manually create misuse rules, whether for basic library APIs provided in various programming languages ​​or APIs developed through encapsulation. This approach is not only time-consuming and labor-intensive, but also limited in scope: on the one hand, it can only detect predefined rules and cannot support dynamic updates of rules; on the other hand, it is difficult to adapt to unofficial cryptographic APIs and perform cross-library detection. Although some studies have explored the use of artificial intelligence for misuse detection, these methods 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 the following two main problems when analyzing complex misuses across function libraries: 1. Complex cross-library data flows. In large projects, code bases are often divided into multiple independently compiled libraries, which makes functions from other libraries opaque to the compiler, hindering the accurate identification of behaviors in other libraries (such as phantom methods in JAVA). Even with access to all code related to the project's dependent libraries, cross-library data flow analysis will still expand the data scope of the analysis, thereby increasing the complexity of the analysis. This complexity may lead to a decrease in analysis accuracy and place higher demands on the time and memory resources required for analysis. 2. Manually established, 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 the API. When the API is encapsulated, rules based on the API name will become invalid, resulting in missed detections. Although CrySL used in CogniCryptoSAST partially solves some hard-coding problems, all detection rules still need to be manually written by cryptography experts. Considering the large number of unofficial cryptographic libraries and complex grammar rules in actual applications, writing rules for large-scale unofficial APIs is still a practical challenge. In addition, 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 program usage 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 of the project to be tested and the 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 constraint 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 constraint 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 instructions for calling 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, a data flow analysis result is obtained by using a symbol x to represent a function parameter; the data flow analysis result is an expression including 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 a new constraint;

[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 parameter constraint in a new 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, the step of 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 a static single assignment IR.

[0029] Optionally, the 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 slice 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 slice criterion, and the first step is returned;

[0034] Based on the backward slicing result and the forward slicing result, all program statements that may affect the slicing criteria are obtained, and a data flow propagation path graph is constructed;

[0035] Data flow analysis is performed based on the data flow propagation path graph to obtain a runtime value of a 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 slice 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 slice criterion, and the first step is returned;

[0041] Based on the backward slicing result and the forward slicing result, all program statements that may affect the slicing criteria are obtained, and a data flow propagation path graph is constructed;

[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 class 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 any of the above-mentioned methods for detecting password misuse that supports automatic rule derivation and cross-library analysis.

[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 any of the above-described methods for detecting password misuse that support automatic derivation of rules and cross-library analysis.

[0046] In a fourth aspect, the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of any of the above-mentioned methods for detecting password misuse that support 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] The present application provides a cryptographic misuse detection method, device, medium and product that supports automatic rule derivation and cross-library analysis. A "cryptographic rule constraint library" is designed for cryptographic characteristics, and a formal method is used 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, and realizes the decoupling of the tools and detection rules, so that the detection tools have dynamic scalability, and the rules can be expanded and changed without secondary development of the tools; a new framework cryptographic misuse detection framework Goph is designed er, compared with the previous cryptographic misuse detection framework, it introduces a feedback mechanism that enables 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 static analysis solution for cryptographic misuse is designed. By performing forward and backward slicing before the data flow analysis process, the variable range in the data flow analysis process is reduced, 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 drawings required for use in the embodiments will be briefly introduced below. 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 paying 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 path diagram of data flow propagation 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 an 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 the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0059] In order to make the above-mentioned objects, 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 , which is used to achieve high-precision cryptographic misuse detection. Gopher consists of two core components: "Cryptographic Rule Constraint Library" and "Detector", which are logically independent of each other. "Cryptographic Rule Constraint Library" serves as a constraint library for cryptographic application program interfaces (APIs), while "Detector" performs misuse detection based on these constraints and provides necessary data flow information to "Cryptographic Rule Constraint Library" to further derive new constraints. Different from existing cryptographic misuse analysis methods, Gopher introduces a formal representation layer and feedback mechanism, which enables "Cryptographic Rule Constraint Library" to automatically generate new constraints for encapsulated APIs by analyzing the data flow collected by the detector during the misuse analysis process. This mechanism greatly reduces the burden of manually designing constraints in previous tools. This innovation enables Gopher to dynamically adapt to the update of detection constraints and improve detection coverage without the need for secondary development of tools, thereby effectively solving the scalability challenges faced by tools that rely on static blacklist and whitelist methods, and realizing self-improvement and optimization of tools and explicit representation of invisible usage specifications in cryptographic libraries during the detection process.

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

[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 the usage rules of the basic cryptographic library; the usage rules include: function rules, parameter rules and member variable rules.

[0065] In order 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] Among them, function rules are the rules for the correct use of cryptographic libraries at the function level. The confidentiality of ciphertext is directly related to the type of cryptographic algorithm adopted. Due to factors such as compatibility, there are often many functions in the cryptographic library that are not strong enough (such as MD5). Therefore, to use the cryptographic library correctly, you first need to collect various commonly used cryptographic algorithms and summarize them based on the current attack methods. Here, this application further divides the functions with security issues in the cryptographic library, including dangerous functions and warning functions.

[0068] Among them, the dangerous function category includes functions that are considered unsafe in cryptographic operations, which covers all dangerous algorithms (such as MD5, 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 cryptographic libraries.

[0070] Parameter rules

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

[0072] Member variable rules

[0073] At present, most programming languages ​​have a certain object-oriented design concept. In order to use the cryptography library correctly, it is also necessary to correctly configure the member variables of some key objects. For example, when configuring the TLS service, it is necessary to turn on the verification of the domain name and certificate, configure the correct minimum version of the TLS handshake, etc.

[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 basic cryptographic library based on the rules summarized in step 1, and automatically derives the constraints of the encapsulated API based on the constraints derived in stage 5. These constraints, as a formalized intermediate representation, bridge 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. The separation of constraints and detectors enables the framework to adapt to changes in the cryptographic library without modifying the developed detector itself.

[0077] The function of this step is to formally represent the usage rules of the natural language cryptographic 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 construction, the "Cryptographic Rule Constraint Library" constraint document is defined at the level of a library, that is, each "Cryptographic Rule Constraint Library" document details the usage rules of a cryptographic library, and the document first describes the function library to which the constraint applies. The "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 acted on, 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. It can be further divided into two subcategories based on the security vulnerabilities of the function:

[0083] (a.1) Dangerous Fun_Constraints

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

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

[0086] This category corresponds to warning functions, including functions that are not strictly prohibited but recommended to be replaced. This includes NIST-recommended replacement algorithms such as 3DES, as well as deprecated functions in standard cryptographic libraries. The structure of this part is exactly the same as that of dangerous function constraints. It directly lists all the names of banned algorithms and the reasons for banning them in the form of a list. Compared with 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 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 the detection method of data flow analysis.

[0092] The purpose 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 customizes specialized analysis methods for different types of constraints. This is a one-time design work during the tool development phase. After that, only the "password rule constraint library" constraints need to be updated to cope with changes in the API detection scope, without further modifications to the "detector".

[0093] Specifically, 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 with the function name and detects it by matching the function name. When a function call matches an entry in the pre-established blacklist in the function constraints in the "Password Rule Constraint Library", the "Detector" will immediately mark 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 specific type of variable, and v is the variable associated with it. In the process of 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 criterion 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, the call to the cryptographic library is considered safe.

[0098] Phase 4: Perform misuse detection

[0099] Steps 5-12 below are the "detector" performing misuse detection tasks and collecting data flow information required for subsequent constraint derivation. When performing cross-library detection, only the constraints of the called library need to be loaded. The design is fully decoupled, which means 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 the "detector" to perform misuse detection. The specific detection process is as follows:

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

[0102] That is, source code acquisition. This application applies the Gophe framework to the detection of the go language. When performing misuse detection, the implemented tool must first obtain the complete source code of the project to be detected. In addition, it is necessary to obtain the go.mod file of the project to be detected. The go.mod file is the core configuration file of the Go language module system. It records the basic information and dependencies of a Go module. Since Go 1.11 introduced module support, the go.mod file has become one of the standard ways to manage Go project dependencies. Through the go.mod file, all dependency information of the project can be accurately obtained.

[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 the program than the source code. The SSA package officially provided by golang can be used to convert the source code into IR in the form of SSA (static single assignment). During the IR generation process, the 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 calling functions involved in the program, and compares the calling 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] That is, calling function comparison, this step accepts the detection task converted from the function constraint. According to the method in stage three, the detector receives the function name blacklist provided by the "Function Constraint" in the "Password Rule Constraint Library", compares the locations of all calling functions involved in the program, and compares the calling function name with the function name in the blacklist in the "Password Rule Constraint Library" function constraint. If a function call in the blacklist is found, an alarm 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: Get the runtime value of the second slicing criterion.

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

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

[0113] For example, in the CryDict document of the cryptographic rule constraint library, for the RSA key generation function func GenerateKey(rand io.Reader, bits int), the predicate information GEQ(1,3072) is specified, indicating that the parameter bits (the computer starts counting from 0) at the second position of GenerateKey needs to 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 calling 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 turn.

[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}, and 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 "Crypto Rule Constraint Library", and the instructions for storing the corresponding member variables of the corresponding structure in the IR are found, and 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 tracks the definition and use of all variables that affect that point. Backward slicing first needs to determine the slicing point (slicing criterion), then needs to find all definitions of the variable, and trace back along the definition path. In 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. With the results of SSA, it is easy to perform backward slicing of programs within a procedure. In order to construct backward slicing between procedures, this application constructs a call graph through Class Hierarchy Analysis (CHA). With 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 procedure, which can achieve backward analysis between procedures.

[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 a program point to the same memory address. In the presence of aliases, that is, when multiple variables refer to 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. 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, 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. When performing forward slicing, all instructions from the above instructions to the slicing criteria will be searched in order from front to back, and 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 call instructions) will be tracked.

[0127] This check helps to quickly find aliases and potential assignments during the backward slicing process, efficiently locate the cause of cryptographic misuse, and analyze only necessary nodes during data flow analysis, reducing analysis time and memory overhead without reducing 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, which 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 possible runtime value set 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 code corresponding to Table 1 above is 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 variable value satisfies the corresponding predicate according to the predicate definition, that is, ∧ r∈Res P(r) = True. If not, the detector will give an alarm. For example, for the constraint GEQ(1,3072) for the RSA key generation function in the "Cryptographic Rule Constraint Library", the detector will detect whether the values ​​of all runtime values ​​corresponding to 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 will give 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, execute 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 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 a 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: Use the SMT solver to solve the equation group to obtain the predicate information in the new constraint.

[0146] Step 17: Use the data flow path of the new constraint generation process as the constraint reason, and combine 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] In order to derive new cryptographic library usage constraints from existing constraints and reduce the huge overhead of manually designing a "cryptographic rule constraint library" for all function libraries, this application designs a constraint derivation method. When performing constraint derivation, the data flow information provided in stage 4 is required. Through this step, the CryDict document corresponding to the user's newly encapsulated cryptographic library can be automatically obtained.

[0149] The purpose of the above steps 13 to 18 is to automatically generate the "cryptographic rule constraint library" formal constraints of the new cryptographic library after the developer conducts 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 function parameter Pa newly developed by a developer involving an existing constraint φ, first symbolize the parameter node as x, and track the symbolic execution along the data propagation path according to the data flow analysis results in stage 4. We record 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 functions of developers want 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] The constraint is formally a set of univariate equations. By applying the SMT solver, the constraints that need to be satisfied for the correct use of the encapsulated cryptographic function can be solved, that is, the conditions that x needs to satisfy. The SMT solver can be used to obtain the predicate information in the new constraint, and the data flow path of the constraint generation process can be used as the constraint reason. Combined with the function name and parameter information, a new parameter constraint in the cryptographic rule constraint library can be generated. The parameter constraints of the same cryptographic library can be organized together to form 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 running value of the first slice criterion analysis in stage 4, 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 derivation work needs to be performed on e. After parameterizing the parameter e as x, recursively trace the propagation path along the data flow propagation path graph, perform symbolic execution, update the values ​​corresponding to the nodes in the graph, and 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 satisfy is GEQ(0,3072). After being solved by the SMT solver, the parameter e of GenKey needs to satisfy 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 password rule constraint document, you can load the new document and detect the calls to the newly encapsulated cryptographic library in the application in the manner of 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 of 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 the three defects of manually established and hard-coded detection rules in the tool:

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

[0158] Secondly, it avoids the defect of the difficulty in expanding the API range in the previous hard-coding method. In the previous hard-coding tools, once the cryptographic algorithm is updated, the entire tool needs to be redesigned and compiled, otherwise the tool will not be able to detect the new API, resulting in missed detection. In this application, only the "cryptographic rule constraint library" used needs to be updated, and the tool can be adapted to the new API without secondary development of the tool.

[0159] The third aspect is the detection of cryptographic libraries across libraries. Due to the huge overhead of static analysis across libraries, previous tools are difficult to detect the use of cryptographic libraries across libraries. In this application, through the constraint derivation function, all constraints required for cross-function library detection can be generated. For example, when the developer is developing using the GenKey function in the newly encapsulated cryptographic 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, SSA and data flow analysis within the library, and does not need to load demopkg and all other related source codes to achieve the effect of cross-library detection. This avoids the huge overhead of previous cross-library analysis and achieves fast 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, referred to as I / O) and a communication interface. The processor, the memory and the 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 the 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 those shown in the figure, or combine certain components, or have a different arrangement of components.

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

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

[0164] In an exemplary embodiment, a computer program product is provided, including a computer program, and 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 of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed 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 the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memory. Non-volatile memory can 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 can 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 database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. The non-relational database may include a distributed database based on blockchain, etc., but is not limited thereto. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but is not limited thereto.

[0168] The technical features of the above embodiments may be arbitrarily combined. 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 article uses specific examples to illustrate the principles and implementation methods of this application. The description of the above embodiments is only used to help understand the method and core ideas of this application. At the same time, for those skilled in the art, according to the ideas of this application, there will 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 supporting automatic rule derivation and cross-database analysis, characterized in that: The password misuse detection method comprises: Obtaining usage rules of a basic cryptographic library; the usage rules include: function rules, parameter rules, and member variable rules; Formalizing the usage rules of the basic cryptographic library application program usage 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 of the project to be tested and the 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 constraint 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 constraint 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 instructions in the IR that call the function, 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, a data flow analysis result is obtained by using a symbol x to represent a function parameter; the data flow analysis result is an expression including 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 a new constraint; 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 parameter constraint in a new 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 step of converting 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 a static single assignment IR.

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 slice 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 slice criterion, and the first step is returned; Based on the backward slicing result and the forward slicing result, all program statements that may affect the slicing criteria are obtained, and a data flow propagation path graph is constructed; Data flow analysis is performed based on the data flow propagation path graph to obtain a runtime value of a 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 slice 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 slice criterion, and the first step is returned; Based on the backward slicing result and the forward slicing result, all program statements that may affect the slicing criteria are obtained, and a data flow propagation path graph is constructed; 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 1 is characterized in that: 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.

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-library analysis described in 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-library analysis described in any one of claims 1 to 6 are implemented.

Images