Data-driven code security function verification system oriented to Internet of Things

Abstract

The invention provides a code security function verification system based on data driving, which is feasible in an actual scene and faces the Internet of Things, a two-stage software code formalization verification analysis system is constructed, and in the first stage, a data flow diagram DFD is constructed by taking user authentication information and user behavior information as starting points and taking data full life cycle flow as a main axis. And in the second stage, for the globally unique DFD which depends on a single user at a certain moment, a method for determining code flow control corresponding to each DFG node, a method for constructing local sub-CFA based on single code flow control, and a method for splitting the overall system overall CFA into local, refined and small operable CFA, so that code security function verification based on data driving is realized. The method not only ensures the coverage of the code security function formalized verification analysis system for the operation of the Internet of Things intelligent equipment on codes, but also provides a formalized verification analysis system which can be practically applied.

Description

Technical Field

[0001] The present disclosure relates to the technical field of formal verification and analysis, and more particularly to a data-driven code security function verification system for the Internet of Things. Background Art

[0002] Currently, formal verification and analysis technologies have been widely applied to hardware and software systems with extremely high security requirements, such as chips, aerospace, bank payments, medical devices, and Internet of Things wearable devices, covering multiple aspects including system design, functional and security analysis, and functional and security verification. Static formal verification and analysis refers to, after the system design and development are completed, formally expressing and verifying the system functions and security features based on design documents or source code. However, the formal code control flow models generated by static verification and analysis are often too large, making it difficult to construct a usable model in the actual formal verification and analysis process. Currently, formal verification and analysis face problems such as overly broad coverage and excessive complexity, resulting in state explosion of the formal model to be constructed and unable to obtain effective verification results within reasonable time and resource constraints.

[0003] To solve this problem, some dynamic formal verification and analysis methods during system operation have emerged. Dynamic verification and analysis is to formally express and verify the system functions and their security features based on the code execution flow and state of the actual system when the hardware and software systems are actually running, testing, and in use. For example, patent documents CN108536581A, CN115422033A, and academic papers (Research on Key Technologies of Software Runtime Verification Based on AOP, Zhang Xian, National University of Defense Technology, April 1, 2012), etc., have proposed security verification schemes with the code control flow CFG as the main axis. By analyzing the syntax tree and semantics of the program code in advance, the execution paths of the program (including control flow and data flow) are determined, and the entry points of the AOP aspect are set accordingly for runtime system security verification.

[0004] However, this runtime dynamic verification method depends on the prior syntax and semantics analysis of static code, and has the defect that it cannot fully cover the execution paths in actual operation. Especially in complex scenarios such as the Internet of Things that need to consider multiple factors such as user behavior, device interaction, and external input, its verification coverage may be incomplete. As a result, the control flow and data flow monitored during the runtime of the program code may be missing, unable to fully simulate the variable behaviors in actual execution, and difficult to comprehensively identify potential security vulnerabilities. Summary of the Invention

[0005] The present disclosure provides a data-driven code security function verification system for the Internet of Things, which can not only ensure the completeness of the code coverage of the data-driven code security function verification system for the Internet of Things, but also provide a formal verification analysis system that can be applied in actual scenarios.

[0006] The present disclosure provides a data-driven code security function verification system for the Internet of Things, characterized in that the system includes: A label definition module, configured to define a security label pattern and a globally unique instance and version label for variable names, data, and code flow control methods. A verification rule definition module, configured to define a code security rule verification model. A data annotation AOP module, configured to add a first security label to all variable names and data in the application to be verified and analyzed, as the entry point of the AOP data flow capture aspect for aspect-oriented programming. A data AOP aspect module, configured to generate AOP data flow capture aspect code, and the AOP data flow capture aspect code is configured to execute first logging enhancement logic according to the activation status and path of the first security label. A data flow capture module, configured to, at runtime, add globally unique instance and version labels of variable names and data to the variable names and data in each code block including a single code flow control method, and the AOP data flow capture aspect code executes first logging enhancement logic according to the activation status and path of the first security label, so as to determine a data flow diagram DFD and a data stream graph DFG. A sub-CFA determination module, configured to construct a local sub-control flow analysis CFA set based on each code flow control method corresponding to the nodes of the data stream graph DFG according to the data flow diagram DFD. A code annotation AOP module, configured to add a second security label to the code flow control methods of the sub-CFA set under each DFD in the application to be verified and analyzed, as the entry point of the AOP security verification aspect for aspect-oriented programming. A code verification AOP aspect module, configured to generate AOP security verification aspect code, and the AOP security verification aspect code is configured to execute the code security rule verification model and the enhancement logic of the second logging according to the activation status and path of the second security label and the instance and version label of the code flow control method. A runtime code verification module is used to add a globally unique instance of the code flow control method and a version tag to each sub-CFA in real time during runtime. The AOP security verification aspect code executes the enhanced logic of the code security rule verification model and the second logging according to the activation status and path of the second security tag, as well as the instance of the code flow control method and the version tag, to implement the code security rule verification and the second logging function.

[0007] Among them, the first logging includes the activation status and path record of the first security tag, as well as the instance and version tag record of the variable name and data.

[0008] Specifically, the security tag modes of the first security tag include: Sensitive data tag, sensitive variable name tag, variable name and data tags used by function interfaces within a package, variable name and data tags used for user-human interaction, variable name and data tags used for security authentication and protocols, variable name and data tags used for external databases and files of a package.

[0009] The security tag modes of the second security tag include: code flow control method tag.

[0010] Optionally, the method for constructing a local sub-control flow analysis CFA set based on the data flow diagram DFD for each data flow graph DFG node includes: obtaining the data flow diagram DFD determined by the data flow capture module, for each DFD, determining the code flow control method corresponding to each DFG node, and constructing a local sub-CFA based on the code flow control method corresponding to each DFG node to obtain a sub-CFA set under each DFD.

[0011] Among them, the second logging includes the activation status and path record of the second security tag, the instance and version tag record of the code flow control method, and the execution record of the code rule security verification.

[0012] Optionally, the system further includes a process control module for registering the application to be verified and analyzed, managing and coordinating the interaction and operation of each module within the code security function verification system, and generating a verification and analysis result report.

[0013] Further optionally, the system further includes: A system logging module for obtaining the first logging generated when the data flow capture module executes and the second logging generated when the runtime code verification module executes; The global code security policy execution module is used to comprehensively analyze the activation status and path records of the second security tags, code flow control method instances, and version tag records in the first and second log records of the system log module, determine the code flow of the entire link and full life cycle of the dependent data, and perform code security verification on the code flow of the entire link and full life cycle of the dependent data according to the code security rule verification model.

[0014] The beneficial effects of the present disclosure are as follows. Compared with the prior art, the present disclosure has the following advantages: 1) In the solution of the present disclosure, starting from user authentication information and user behavior information, with the full-life cycle transfer of data as the main axis, security tags are added to the data in the software code during system operation, the information read by the software code from the database or document file, the data in human-computer interaction, security authentication and protocol data, module call parameters and their data, function call parameters and their data and variable names, etc., to trace the data flow diagram DFD of the full life cycle of data oriented to users and their data behaviors. By combining the data flow diagram DFD and the local sub-CFA, the completeness of code coverage is ensured, especially covering the execution paths such as external input, user behavior, and database interaction that need to be considered in the Internet of Things. Its verification scope includes not only the front-end App, back-end applications and services, but also comprehensive platforms such as databases, file systems, big data platforms, and message queues, which can fully simulate the variable behaviors in the actual execution of system program code, ensuring the completeness of code coverage and avoiding the defect that the prior art cannot fully cover the runtime behaviors due to the prior syntax and semantic analysis of static code. The overall global CFA of the system is split into local, refined, and small operable CFAs, thus realizing the data-driven code security function verification.

[0015] This method not only ensures the completeness of code coverage of the formal verification analysis system for code security functions during the operation of Internet of Things intelligent devices, but also provides a practically applicable formal verification analysis system.

[0016] 2) Compared with all possible control flow and data flow paths in static analysis (static analysis DFD + static analysis CFA), the set of runtime control flow and data flow paths (activated DFD + activated CFA) in the data-driven code security function verification scheme provided by the present disclosure is reduced by nearly ten thousand times to one hundred thousand times, thus greatly compressing the formal verification space and improving the verification efficiency and accuracy.

[0017] 3) Since multiple programming languages support the programming language of the AOP security enhancement modification mechanism to implement its security verification analysis by uniformly applying the same security verification analysis strategy for security label and code modification, the data-driven code security function verification solution provided by this disclosure adapts to multiple programming languages and development standards (such as JNI, FFI) to achieve cross-language security verification analysis. Brief Description of the Drawings

[0018] The accompanying drawings herein are incorporated into the specification and form a part of this specification, showing embodiments consistent with this disclosure, and are used together with the specification to explain the principles of this disclosure.

[0019] Figure 1 Schematic diagram of a data-driven code security function verification system for the Internet of Things provided by an embodiment of this disclosure; Figure 2 Schematic diagram of an example of a runtime code security function verification process provided by an embodiment of this disclosure.

[0020] Through the above accompanying drawings, specific embodiments of this disclosure have been shown, and there will be more detailed descriptions hereinafter. These drawings and written descriptions are not intended to limit the scope of the concept of this disclosure in any way, but to illustrate the concept of this disclosure to those skilled in the art by referring to specific embodiments. Detailed Description of the Embodiments

[0021] The following further describes this disclosure with reference to the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solutions of this disclosure and cannot be used to limit the protection scope of this disclosure.

[0022] Term Explanation: 1. AOP (Aspect-Oriented Programming): Aspect-Oriented Programming (AOP) is a programming paradigm that modularizes cross-cutting concerns (such as logging, performance monitoring, security verification, etc.), enabling these functions to be separated from the core business logic code, thereby improving the maintainability and reusability of the code. In AOP, an "aspect" is a module that defines enhanced behaviors for certain points in the program (such as method calls, data access, etc.). AOP allows developers to flexibly embed additional behaviors into specified positions in the program without modifying the core code, and is widely used in scenarios such as logging, transaction management, and security verification, especially suitable for functions that span multiple modules.

[0023] 2. CFA (Control Flow Analysis): Control Flow Analysis (CFA) is a technique used to analyze the execution flow and control structure of various parts in a program, and is widely applied in software engineering. CFA mainly focuses on control flow characteristics such as the execution paths, conditional judgments, branches, and loops in the program. In the data / code security verification of Internet of Things intelligent devices, CFA can be used to trace and analyze the processing paths of data to verify the security of the system.

[0024] 3. CFG (Control Flow Graph): A Control Flow Graph (CFG) is a graphical representation of the control flow in a program, used to describe the execution order and control paths between different statements or basic blocks in the program. Each node represents a basic block in the program (i.e., a group of consecutive execution statements), and the edges in the graph represent the control flow paths from one basic block to another. Different from CFA, CFG is mainly composed of basic blocks and control flow paths, and focuses on showing the structured control flow of the program and the jump relationships between program blocks.

[0025] 4. DFD (Data Flow Diagram): A Data Flow Diagram (DFD) is a graphical tool used to represent the flow and processing of data in a system. It describes how data in the system flows from the input end to the processing unit, and then to the output end or storage system, mainly focusing on the paths and transformation processes of data flow. DFD is usually used in system analysis and design to clearly show the flow, storage, and processing methods of data in the system, especially suitable for revealing the data interaction between various modules in the system.

[0026] 5. DFG (Data Flow Graph): A Data Flow Graph (DFG) is a graphical model representing the data processing flow and dependency relationships in a program. Different from DFD, DFG mainly focuses on the operations and transformations of data during the calculation process, rather than just the data flow paths. DFG is usually used to represent how data is transmitted and transformed between different operations, functions, or modules during the program execution process, emphasizing the computational dependencies of data.

[0027] Figure 1 is a schematic diagram of a data-driven code security function verification system for the Internet of Things according to an embodiment of the present disclosure.

[0028] The present disclosure aims to propose a data-driven code security function verification system for the Internet of Things that is feasible in actual scenarios. Its technical concept is to construct a two-stage software code formal verification analysis system. In the first stage, starting from user authentication information and user behavior information, with the full life cycle flow of data as the main axis, a data flow diagram (DFD) is constructed. Specifically, by adding security tags, one-time-use instance and version tags to the data in the software code during runtime, the information read from the database or document files by the software code, the data in human-computer interaction, the security authentication and protocol data, the call parameters and their data between modules, the function call parameters and their data, and their variable names, a data flow diagram DFD oriented to the user and their data behavior is used.

[0029] On this basis, in the second stage, for the DFD that is globally unique for a single user at a certain moment, the method (function) of code flow control corresponding to each DFG node is determined, and a local sub-control flow analysis (CFA) is constructed based on the method (function) of a single code flow control. The overall global CFA of the system is split into local, refined, and small operable CFAs to achieve data-driven code security function verification. This method not only ensures the code coverage of the formal verification analysis system for the code security function during the runtime of Internet of Things intelligent devices, but also provides a formal verification analysis system that can be actually applied.

[0030] As Figure 1 shown, the data-driven code security function verification system 100 for the Internet of Things includes: a tag definition module 102, a verification rule definition module 103, a data annotation AOP module 104, a data AOP aspect module 105, a data flow capture module 106, a sub-CFA determination module 107, a code annotation AOP module 108, a code verification AOP aspect module 109, and a runtime code verification module 110.

[0031] The tag definition module 102 is used to define security tag patterns and globally unique instance and version tags for variable names, data, and code flow control methods.

[0032] Among them, the tag definition module includes a security tag definition module 1021 and an instance and version tag definition module 1022.

[0033] Specifically, the security tag definition module 1021 is used to define security tag patterns for variable names, data, and code flow control methods. The security tag patterns may include: 1) Sensitive data label: Labels the data that needs to be tracked in the application, helping the system determine the data flow diagram DFD based on the activation status and path (data flow direction) of the security label.

[0034] 2) Sensitive variable name label: Labels the variable names that need to be tracked in the application, helping the system determine the data flow diagram DFD based on the activation status and path (data flow direction) of the security label.

[0035] 3) Variable names and data labels used by the function interfaces within the package: Labels the data belonging to the internal function interfaces of the program.

[0036] 4) Variable names and data labels used for user-human interaction: Labels the data for interaction with the user.

[0037] 5) Variable names and data labels used for security authentication and protocols: Labels the data related to security authentication and protocols.

[0038] 6) Variable names and data labels used for external databases and files connected to the package: Labels the data related to external databases or files.

[0039] 7) Variable names and data labels used for externally called functions and services of the package: Labels the data related to external function calls and services.

[0040] 8) Shared data label: Marks two version numbers for the shared data, used to describe the parent-child relationship of the data lineage.

[0041] 9) Code flow control method label: Labels the methods (functions) used for code flow control in each CFA.

[0042] Among them, the methods (functions) of code flow control include conditional judgment functions (conditional statements), loop control functions (loop statements), function call / return control (jumping to control the program flow), and exception handling functions (exception control), etc.

[0043] The instance and version label definition module 1022 is used to define globally unique instance and version labels for variable names, data, and code flow control methods. Each instance and version label corresponds to a globally unique sub-CFA code flow to ensure the global uniqueness of the code security status identification even if the code is called many times during runtime code security verification. Among them, the instance and version labels include: variable name instance and version labels, data instance and version labels, and code flow control method instance and version labels.

[0044] Preferably, the instance and version tag is composed of the authentication session key + time, and is globally unique. That is, the variable name, data, and code flow control method are marked with a globally unique instance and version tag, that is, the variable name, data, and code flow control method are encrypted to obtain ciphertext. It can be understood that due to the addition of time, even if the same authentication session key appears in the key replacement, they are still unique due to the different timestamps, thereby enhancing the uniqueness of the instance and version tag.

[0045] Once each variable name, data or code flow control method marked with an instance and version label is referenced or processed by the code in the sub-CFA set under each DFD, its authentication session key will be replaced and the ciphertext encrypted by the original key will become unavailable, ensuring the global uniqueness of the sub-CFA (set) function code flow annotation attachment point, avoiding the ambiguity of the CFG security function verification status when building and tracking sub-CFAs that rely on DFD due to identical or overlapping data instances, and ensuring that each sub-CFA status is independent, non-conflicting, non-overlapping, traceable and accurately located.

[0046] The verification rule definition module 103 is used to define a code security rule verification model. Specifically, in the scenario of formal verification and analysis of the security function of the code, the code security rule verification model includes but is not limited to: 1. In the case of non-authentication, the code runs empty 2. The code does not jump to data and codes that are not in the CFA category; 3. All code calls are audited internal and external package interface functions; 4. Code calls are all audited AOP codes and CFA processes; 5. The parameters brought into the code are safe and have been verified to be in compliance with the format; 6. Data is not stored locally; 7. Data can only be uploaded through designated paths, and no backdoors can be left to steal data.

[0047] Optionally, the expression of the above code security rule verification model can be in various forms, including: model rule expression or formula, code semantic expression or formula, code general form expression or formula, etc.

[0048] Model rule expressions or formulas represent the formal description of code security behaviors based on predefined security policy models using mathematical formulas or logical expressions. For example, taking the code flow rule as an example, the code is defined to prevent data and code from jumping to non-CFA classes.

[0049] Code semantic expressions or formulas are used to define the mathematical meaning of programming language constructs (such as statements, expressions, functions, etc.), helping to verify whether the code meets the expected usage and permission scope.

[0050] Code general form expressions or formulas are used to describe the general rules of code structure, especially in generic programming or abstract structures. They provide a general and abstract description method, aiming to ensure that the code can run correctly and has been security-verified in different types or environments through a formal way.

[0051] It can be understood that not all of the above security label patterns and code security rule verification models need to be specified. When verifying different application systems, different security label patterns and code security rule verification models can be selected according to the different security specifications that the code in the application system needs to meet, so as to achieve the purpose of appropriate verification methods.

[0052] The data annotation AOP module 104 is used to add the first security label to all variable names and data in the application program to be verified and analyzed, serving as the entry point of the AOP data flow capture aspect.

[0053] Optionally, the application program to be verified and analyzed includes Internet of Things devices and their related application programs, as well as backend service systems that support the operation of Internet of Things devices, etc.

[0054] Specifically, according to the security label pattern of the application program to be verified and analyzed defined by the label definition module 102, the first AOP (Aspect-Oriented Programming) program adds the first security label to all variable names and data in the static code application package (Java application package) of the application program to be verified and analyzed, serving as the entry point of the AOP data flow capture aspect. The AOP data flow capture aspect code in the data AOP aspect module 105 executes the first logging enhancement logic according to the activation status and path (data flow direction) of these security labels.

[0055] Among them, the first AOP (Aspect-Oriented Programming) program is the AOP (Aspect-Oriented Programming) program developed by this module, which is used to add the first security label to all variable names and data in the static code application package (Java application package) of the application program to be verified and analyzed. Specifically, the first AOP (Aspect-Oriented Programming) program parses the static code of the application program to be verified and analyzed, determines all variable names and data, and then adds the corresponding security labels to them.

[0056] For example, for sensitive data labels and ciphertext labels, the code example for label implementation is as follows: public class UserData { @SensitiveData private String userName; / / The user name is sensitive data @SensitiveData String userPassword; / / The user password is sensitive data} The data AOP aspect module 105 is used to generate AOP data flow capture aspect code, and the AOP data flow capture aspect code is configured to execute the first logging enhancement logic according to the activation status and path (data flow direction) of the first security label. Among them, the first logging includes the first security label activation status and path record, as well as the variable name, data instance, and version label record.

[0057] Specifically, the AOP data flow capture aspect code is determined based on the pre-developed AOP (Aspect-Oriented Programming) data flow capture program and the security label pattern of the application program to be verified and analyzed defined by the label definition module. The AOP data flow capture aspect code is configured to execute the first logging enhancement logic according to the activation status and path (data flow direction) of the first security label. Among them, the first logging includes the first security label activation status and path (data flow direction), as well as the variable name, data instance, and version label record.

[0058] Among them, the pre-developed AOP (Aspect-Oriented Programming) data flow capture program of this module obtains the security label pattern of the application program to be verified and analyzed defined by the label definition module and generates the AOP data flow capture aspect code. The AOP data flow capture aspect code will be "woven" into the static code of the application program to be verified and analyzed, or dynamically "woven" at runtime. It can be understood that in AOP, "weaving" means embedding the AOP aspect code into the target running code.

[0059] When the application program to be verified and analyzed uses variables, data, and their related functions at runtime, the AOP aspect data flow capture code will execute the first logging enhancement logic according to the activation status and path (data flow direction) of the first security label.

[0060] As is well known in the art, in AOP aspect-oriented security authentication programming, it generally includes pointcuts, and AOP security authentication and / or logging aspect code (i.e., "advice" and "execution"). The AOP security authentication and / or logging aspect code is the security authentication and / or logging enhancement logic inserted at the specified pointcuts, and the specific location and timing of the enhancement are determined through the pointcuts. In this step, security labels are used as the pointcuts of the AOP aspect, and the AOP data flow capture aspect code executes the first logging enhancement logic in response to the activation and path of these security labels.

[0061] Thus, through the data AOP aspect module 105, the code security function verification system can track the data flow diagram DFD by determining the activation status of variable names and data security labels at runtime, while ensuring that the code does not run incorrectly due to additional label information during runtime.

[0062] The data flow capture module 106 is used to add globally unique instance and version labels of variable names and data to each code block of a method including a single code flow control in real time during runtime. The AOP data flow capture aspect code executes the first logging enhancement logic according to the activation status and path (data flow) of the first security label, thereby determining the data flow diagram DFD and the data flow graph DFG.

[0063] The data flow capture module 106 includes a first instance and version label control module 1061 and a first runtime module 1062.

[0064] The first instance and version label control module 1061 is used to add instance and version labels to variable names and data in real time during runtime, and generate globally unique instance and version labels for variable names and data in each code block of a method (function) including a single code flow control.

[0065] Specifically, according to the instance and version label definition module 1022, instance and version labels are added to variable names and data during runtime to obtain encrypted ciphertext. During the execution process at runtime, after each ciphertext is referenced or processed by a code block of a method (function) including a single code flow control, its key is replaced, and the original ciphertext encrypted by the key becomes unavailable, ensuring the global uniqueness of each code block of a method (function) including a single code flow control during runtime, and avoiding the ambiguity of subsequent construction of the sub-CFA security verification state due to the same or overlapping of ciphertext method (function) names, variable names, and data instances, ensuring that each sub-CFA state is independent, non-conflicting, non-overlapping, traceable, and precisely locatable.

[0066] It is understandable that since the key of each ciphertext is permuted after being referenced or processed by a code block that includes a method (function) with a single code flow control, the role of the first instance and version label control module 1061 is to add instance and version labels to variable names and data in real time at runtime. In contrast, the data annotation AOP module 104 is used to automatically add security labels to all variables and data in a static code package (such as a Java application package).

[0067] The first runtime module 1062 is used to activate the corresponding security labels when variables, data, and their related functions are passed through and used at runtime, that is, in an active state. The AOP data flow capture aspect code executes the first logging enhancement logic based on the activation state and path (data flow direction) of the first security label, thereby determining the data flow diagram DFD (data flow diagram) and data flow graph DFG of the entire link and full life cycle of the dependent data. Among them, the first logging includes the activation state and path (data flow direction) of the first security label, as well as the instance and version label records of variable names and data.

[0068] The sub-CFA determination module 107 is used to construct a local set of sub-CFAs based on the code flow control methods corresponding to each DFG node according to the data flow diagram DFD.

[0069] Among them, the sub-CFA determination module 107 obtains the data flow diagram DFD determined by the data flow capture module 106. For each DFD, it determines the code flow control method (function) corresponding to each DFG node, and constructs a local sub-CFA (control-flow Analysis) based on the code flow control method (function) corresponding to each DFG node, obtaining a set of sub-CFAs under each DFD.

[0070] By relying on the globally unique data flow DFG of a single user at a certain moment, the global CFA of the system is decomposed into multiple local and refined operable sub-CFAs, thereby providing a formal verification analysis system that is feasible in practical scenarios.

[0071] The code annotation AOP module 108 is used to add a second security label to the code flow control method of the set of sub-CFAs under each DFD in the application program to be verified and analyzed, as the entry point of the AOP security verification aspect.

[0072] Specifically, according to the security label pattern of the application program to be verified and analyzed defined by the label definition module, the first AOP (Aspect-Oriented Programming) program adds a second security label to the code flow control method of each sub-CFA set under each DFD in the static code application package (Java application package) of the application program to be verified and analyzed, as the entry point of the AOP security verification aspect. The AOP security verification aspect code in the code verification AOP aspect module 109 responds to the activation of these security labels and executes the enhanced logic of the code security rule verification model and the second logging.

[0073] Among them, the first AOP (Aspect-Oriented Programming) program is the AOP (Aspect-Oriented Programming) program developed by this module, which is used to add a second security label to the code flow control method of each sub-CFA set under each DFD in the static code application package (Java application package) of the application program to be verified and analyzed. Specifically, the first AOP (Aspect-Oriented Programming) program performs code parsing on the static code of the application program to be verified and analyzed, determines the code flow control methods of each sub-CFA set under each DFD, and then adds the corresponding security labels to them.

[0074] For example, use a custom @FlowControl annotation to identify the code flow control function.

[0075] public class DataProcessor { @FlowControl("security-check") / / Marked as a flow control function and set the security label type public void processData(String data) { if (data!= null &&!data.isEmpty()) { System.out.println("Processing data: " + data);} else { System.out.println("No data to process.");}} @FlowControl("logging") / / Another function marked as flow control public void logData(String data) { System.out.println("Logging data: " + data);}} The code verification AOP aspect module 109 is used to generate AOP security verification aspect code, which is configured to execute the code security rule verification model and the enhanced logic of the second logging according to the activation status and path (code flow direction) of the second security label, as well as the code flow control method instance and version label.

[0076] Specifically, the AOP (Aspect-Oriented Programming) code security verification program developed in advance, together with the security label pattern and verification rules of the application program to be verified and analyzed defined by the label definition module 102 and the verification rule definition module 103 respectively, are used to determine the AOP security verification aspect code. The AOP security verification aspect code is configured to execute the code security rule verification model and the enhanced logic of the second logging according to the activation status and path (code flow direction) of the second security label, as well as the code flow control method instance and version label. Among them, the second logging includes the activation status and path (code flow direction) record of the second security label, the code flow control method instance and version label record, and the code rule security verification execution record.

[0077] The AOP (Aspect-Oriented Programming) code security verification capture program developed in advance in this module obtains the security label pattern and the code security rule verification model of the application program to be verified and analyzed defined by the label definition module 102 and the verification rule definition module 103, and generates the AOP security verification aspect code. The AOP security verification aspect code will be dynamically "woven" into the application program code to be verified and analyzed during runtime. It can be understood that in AOP, "weaving" means embedding the AOP aspect code into the target running code.

[0078] When the application program to be verified and analyzed passes through and uses the code flow control method of each sub-CFA under each DFD during runtime, the AOP security verification aspect code executes the code security rule verification model and the enhanced logic of the second logging according to the activation status and path (code flow direction) of the second security label, as well as the code flow control method instance and version label.

[0079] Specifically, the code security verification rules include: 1) In the case of non-authentication, the code runs empty; 2) The code does not jump to the data and code that do not belong to the CFA class; 3) All code calls are to the internal and external interface functions of the packages that have been audited; 4) Data does not fall locally, etc.

[0080] Thus, by verifying the AOP aspect module 109 with code, the code security function verification system can complete the corresponding code security rule verification analysis and its logging function through the activation status and path (code flow direction) of the security label at runtime, the code flow control method instance, and the version label. At the same time, it ensures that the code will not go wrong during runtime due to additional label information.

[0081] The runtime code verification module 110 is used to add a globally unique code flow control method instance and version label to each sub-CFA in real time during runtime. The AOP security verification aspect code executes the enhanced logic of the code security rule verification model and the second logging according to the activation status and path (code flow direction) of the second security label, as well as the code flow control method instance and version label, to implement the code security rule verification and the second logging function.

[0082] The runtime code verification module 110 includes a second instance and version label control module 1101 and a second runtime module 1102.

[0083] The second instance and version label control module 1101 is used to add instance and version labels to the code flow control methods of the sub-CFA set under each DFD in real time during runtime, and generate globally unique instance and version labels for each sub-CFA passed through during runtime.

[0084] Specifically, according to the instance and version label definition module 1022, instance and version labels are defined to add instance and version labels to the code flow control methods of the sub-CFA set under each DFD during runtime, obtaining encrypted ciphertext. After each ciphertext is referenced or processed by the sub-CFA code, its key is replaced, and the original ciphertext encrypted by the key becomes unavailable, ensuring the global uniqueness of each sub-CFA label during runtime, avoiding ambiguity when tracking the security status of the CFA during runtime due to the same or overlapping ciphertext method (function) names, variable names, and data instances, and ensuring that the security status of each sub-CFA during runtime is independent, non-conflicting, non-overlapping, traceable, and precisely locatable.

[0085] It can be understood that since each ciphertext is referenced or processed by the sub-CFA code, its key will be replaced. The role of the second instance and version label control module 1101 is to add instance and version labels to the code flow control methods of the sub-CFA set under each DFD in real time during runtime. Different from this, the code annotation AOP module 108 is used to automatically add security labels to the code flow control methods of the sub-CFA set under each DFD in the static code package (such as a Java application package).

[0086] It should be noted that, in addition to identifying global uniqueness through the combination of an authentication session key and time, instance and version tags can also use methods such as time tags and sequential tags to achieve unique identification. The present disclosure does not make specific limitations on this.

[0087] The second runtime module 1102 is used to execute the code security rule verification model and the enhanced logic of the second logging when passing through and using the code flow control method of the sub-CFAs under each DFD at runtime. The AOP security verification aspect code performs code security rule verification and the second logging function according to the activation state and path (code flow direction) of the second security tag, as well as the instance and version tags of the code flow control method.

[0088] As Figure 2 shown, taking the verification rule model of "data not falling on the local disk" as an example, if the data does not fall on the local disk after the execution of CFA-2, the code security rule verification passes; if the data flows to the local disk for storage after the execution of CFA-2, the code security rule verification fails.

[0089] It can be seen that in the embodiments of the present disclosure, by relying on the globally unique DFD of a single user at a certain moment, the overall CFA of the system is decomposed into multiple local and refined operable sub-CFAs, thereby realizing the code security function verification based on data driving. This method of tracking the global data flow diagram DFD oriented by users and their data behaviors, and performing runtime code security function verification through the combination of the data flow diagram DFD and local sub-CFAs, can fully simulate the variable behaviors of program code during actual execution, not only ensuring the complete coverage of the code by the formal verification analysis system for the code security function during the operation of Internet of Things intelligent devices, but also realizing a practically applicable formal verification analysis system.

[0090] Optionally, the system further includes a process control module 101.

[0091] The process control module 101 is used to register the application to be verified and analyzed, manage and coordinate the interaction and operation of each module within the code security function verification system, and generate a verification and analysis result report.

[0092] Further optionally, the system may further include a system log module 111 and a global code security policy execution module 112.

[0093] The system log module 111 is used to obtain the first log record generated when the data stream capture module 106 executes and the second log record generated when the runtime code verification module 110 executes. At the same time, it can also record the operation and function execution of the code security function verification system, providing log information for the security audit of the system. Among them, the first log record includes the activation status and path record of the first security label, as well as the instance and version label record of the variable name and data. The second log record includes the activation status and path (code flow direction) record of the second security label, the instance and version label record of the code flow control method, and the execution record of the code rule security verification.

[0094] The global code security policy execution module 112 is used to perform an overall analysis on the activation status and path (code flow direction) record of the second security label, the instance and version label record of the code flow control method in the first log record and the second log record of the system log module 111, determine the code flow of the full link and full life cycle of the dependent data, and perform an overall analysis and verification of the code security of the code flow of the full link and full life cycle of the dependent data according to the code security rule verification model defined by the verification rule definition module 103, and return the verification analysis result to the process control module 101.

[0095] Through the global code security policy execution module 112, the verification and analysis functions that cannot be executed in real time by the runtime code verification module 110 can be completed, and the security verification of the code that needs to depend on the full link and full life cycle of the data can be realized.

[0096] Among them, the global security policy execution module can be a self-developed system or an existing security rule model verification system that can be purchased or open-sourced. The embodiments of the present disclosure do not make specific limitations on this.

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

[0098] It should be understood that the above embodiments are only used to illustrate the technical solutions of the present disclosure, rather than limiting them; although the present disclosure has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present disclosure.

Claims

1. A data-driven code security function verification system for the Internet of Things, characterized in that: The system comprises: A label definition module (102) is used to define a security label mode and globally unique instance and version labels for variable names, data and code flow control methods; A verification rule definition module (103), used to define a code security rule verification model; A data annotation AOP module (104) is used to add a first security label to all variable names and data in the application program to be verified and analyzed, as an entry point for the aspect-oriented programming AOP data flow capture aspect; A data AOP aspect module (105), used to generate an AOP data flow capture aspect code, wherein the AOP data flow capture aspect code is configured to execute a first logging enhancement logic according to an activation state and a path of a first security tag; A data flow capture module (106) is used to add globally unique variable names and data instance and version labels to variable names and data in each code block including a single code flow control method in real time during runtime, and the AOP data flow capture aspect code executes the first logging enhancement logic according to the activation state and path of the first security label, thereby determining the data flow diagram DFD and the data flow graph DFG; A sub-CFA determination module (107) is used to construct a local sub-control flow analysis CFA set based on the code flow control method corresponding to each data flow graph DFG node according to the data flow graph DFD; A code annotation AOP module (108) is used to add a second security label to the code flow control method of each sub-CFA set under the DFD in the application program to be verified and analyzed, as an entry point for the aspect-oriented programming AOP security verification aspect; A code verification AOP aspect module (109), used to generate AOP security verification aspect code, the AOP security verification aspect code is configured to execute the code security rule verification model and the enhanced logic of the second log record according to the activation state and path of the second security tag and the code flow control method instance and version tag; The runtime code verification module (110) is used to add a globally unique code flow control method instance and version label to each sub-CFA in real time at runtime. The AOP security verification aspect code executes the code security rule verification model and the enhanced logic of the second log record according to the activation state and path of the second security label and the code flow control method instance and version label, thereby realizing the code security rule verification and second log record functions.

2. The data-driven code security function verification system for the Internet of Things according to claim 1 is characterized in that: The first log record includes a first security tag activation state and path record as well as a variable name and data instance and version tag record.

3. The data-driven code security function verification system for the Internet of Things according to claim 1 is characterized in that: The security tag mode of the first security tag includes: Sensitive data labels, sensitive variable name labels, variable names and data labels used in function interfaces within the program package, variable names and data labels used in user-computer interaction, variable names and data labels used in security authentication and protocols, and variable names and data labels used in external databases and files of the program package.

4. The data-driven code security function verification system for the Internet of Things according to claim 3 is characterized in that: The security tag mode of the second security tag includes a code flow control method tag.

5. The data-driven code security function verification system for the Internet of Things according to claim 1 is characterized in that: The method for constructing a local sub-control flow analysis CFA set based on the code flow control method corresponding to each data flow graph DFG node according to the data flow graph DFD includes: obtaining the data flow graph DFD determined by the data flow capture module (106), for each of the DFDs, determining the code flow control method corresponding to each DFG node, constructing a local sub-CFA based on the code flow control method corresponding to each DFG node, and obtaining a sub-CFA set under each DFD.

6. The data-driven code security function verification system for the Internet of Things according to claim 1 is characterized in that: The second log record includes an activation status and path record of a second security label, a code flow control method instance and version label record, and a code rule security verification execution record.

7. The data-driven code security function verification system for the Internet of Things according to claim 1 is characterized in that: The instance and version tags consist of an authentication session key and a time.

8. The data-driven code security function verification system for the Internet of Things according to claim 1 is characterized in that: The code flow control method includes a condition judgment function, a loop control function, a function call or return control, and an exception handling function.

9. The data-driven code security function verification system for the Internet of Things according to claim 6 is characterized in that: The system also includes a process control module (101) for registering the application to be verified and analyzed, managing and coordinating the interaction and operation of various modules in the code security function verification system, and generating a verification and analysis result report.

10. The data-driven code security function verification system for the Internet of Things according to claim 9, characterized in that: The system further comprises: A system log module (111) for acquiring a first log record generated when the data flow capture module (106) is executed and a second log record generated when the runtime code verification module (110) is executed; A global code security policy execution module (112) is used to comprehensively analyze the activation status and path records of the second security label in the first log record and the second log record of the system log module (111), the code flow control method instance and the version label record, determine the code flow that depends on the entire link and the entire life cycle of the data, and perform code security verification on the code flow that depends on the entire link and the entire life cycle of the data according to the code security rule verification model.

Images