A software protection system, method, storage medium, device and program product

Abstract

This specification provides a software protection system, method, storage medium, device, and program product. The system includes: a security intermediary component, used to perform local authentication of corresponding software components according to a preset security policy, and determine the trustworthiness of the software components based on the local authentication results; the security intermediary component and the software components are configured in a target device; and a remote security management center, used to obtain the operating information of the security intermediary component, and perform remote authentication of the security intermediary component based on the operating information; determine whether the security intermediary component is trustworthy based on the remote authentication results, and update the trustworthiness of the security intermediary component based on the determination results.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a software protection system, method, storage medium, device, and program product. Background Technology

[0002] The potential information security risks of software data in computer devices cannot be ignored. Due to the complexity of the network environment and the existence of unknown vulnerabilities, design flaws, or improper configurations, software components used to maintain this data can easily become key entry points for hackers, thus losing their security and trustworthiness. Therefore, establishing effective security and trust mechanisms for software components is a major challenge that the industry urgently needs to address. Summary of the Invention

[0003] In view of this, this specification provides a software protection system, method, storage medium, device, and program product to address the shortcomings of the related art.

[0004] Specifically, this specification is implemented through the following technical solution:

[0005] According to a first aspect of the embodiments of this specification, a software protection system is provided, comprising:

[0006] A security intermediary component is used to perform local authentication of the corresponding software component according to a preset security policy, and to determine the trustworthiness of the software component based on the local authentication result. The security intermediary component and the software component are configured in the target device.

[0007] The remote security management center is used to obtain the operation information of the security intermediary component, and to remotely authenticate the security intermediary component based on the operation information; to determine whether the security intermediary component is trustworthy based on the remote authentication result, and to update the trustworthiness of the security intermediary component based on the determination result.

[0008] According to a second aspect of the embodiments of this specification, a software protection method is provided, applied to a security intermediary component configured in a target device, comprising:

[0009] Local authentication is performed on the corresponding software components according to a preset security policy, and the software components are configured in the target device.

[0010] The trustworthiness of the software component is determined based on the local authentication results;

[0011] The operational information of the security intermediary component is obtained by the remote security management center for remote authentication of the security intermediary component. The result of the remote authentication is used to determine whether the security intermediary component is trustworthy, and the trustworthiness of the security intermediary component is updated based on the determination result.

[0012] According to a third aspect of the embodiments of this specification, a software protection method is provided, applied to a remote security management center, comprising:

[0013] The system obtains the operation information of a security intermediary component, which is used to perform local authentication on the corresponding software component according to a preset security policy, and to determine the trustworthiness of the software component based on the local authentication result. The security intermediary component and the software component are configured in the target device.

[0014] The security intermediary component is remotely authenticated based on the operational information, and its trustworthiness is determined based on the remote authentication result. The trustworthiness of the security intermediary component is then updated based on the determination result.

[0015] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in the second or third aspect.

[0016] According to a fifth aspect of the embodiments of this specification, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the steps of the method described in the second or third aspect.

[0017] According to a fifth aspect of the embodiments of this specification, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the steps of the method described in the second or third aspect.

[0018] The technical solution provided in this specification introduces a security intermediary component. This security intermediary component is configured together with the software component in the target device. Even during the operation of the target device, the security intermediary component can perform local authentication of the corresponding software component according to a preset security policy, and determine the trustworthiness of the software component based on the local authentication result. This ensures the trustworthiness of the software component in real time, and the authentication process does not involve costly operations such as verification hashing, thus having a low performance threshold for the target device. Simultaneously, a remote security management center can obtain the operational information of the security intermediary component and use it to perform remote authentication of the security intermediary component. Based on the remote authentication result, the center can determine whether the security intermediary component is trustworthy and update its trustworthiness accordingly. Since a one-way trustworthiness determination relationship is formed between the remote security management center and the security intermediary component, and between the security intermediary component and the software component, the remote security management center can ensure the security of the security intermediary component by updating its trustworthiness, thereby ensuring that the software component determined by the security intermediary component is also secure and trustworthy.

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

[0020] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings.

[0021] Figure 1 This is a schematic diagram of the architecture of a software protection system shown in an exemplary embodiment of this specification;

[0022] Figure 2 This is a schematic diagram illustrating, in an exemplary embodiment of this specification, the construction of a trusted chain by a target device during startup;

[0023] Figure 3 This is a schematic diagram illustrating a process of protecting software in a target device during operation, as shown in an exemplary embodiment of this specification.

[0024] Figure 4 This is a schematic diagram illustrating an exemplary embodiment of a verification application as described in this specification;

[0025] Figure 5 This is a flowchart illustrating an exemplary embodiment of a software protection method shown in this specification;

[0026] Figure 6 This is a flowchart illustrating another software protection method as shown in an exemplary embodiment of this specification;

[0027] Figure 7 This is a schematic diagram of the structure of an electronic device shown in an exemplary embodiment of this specification;

[0028] Figure 8 This is a schematic diagram of the structure of a software protection device shown in an exemplary embodiment of this specification;

[0029] Figure 9 This is a schematic diagram illustrating the structure of another software protection device as shown in an exemplary embodiment of this specification. Detailed Implementation

[0030] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this specification.

[0031] It should be noted that in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification. In some other embodiments, the methods may include more or fewer steps than those described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments. It should be understood that although the terms first, second, third, etc., may be used in this specification to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of this specification, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0032] 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, data stored, data displayed, etc.) involved in this manual are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0033] In related technologies, computer systems can be structurally divided into three basic layers: hardware, system software, and application software. Hardware is the physical component of a computer system, including the processor (CPU), memory, hard drive, graphics card, motherboard, power supply, and other peripherals such as keyboard, mouse, and monitor. System software manages and controls the computer hardware, providing a runtime environment for application software. It includes operating systems (such as Windows, Linux, or macOS), device drivers, system utilities, and other software that provides services to the hardware. Application software is designed to meet specific user needs and runs on top of system software. This includes office software (such as word processing and spreadsheets), internet browsers, media players, games, and other professional software such as graphic design and programming development tools. System software and application software are among the most vulnerable to malicious attacks in real-world applications. To ensure data security, Trusted Computing (TC) technology can be introduced. One of the core objectives of this technology is to ensure the integrity of the operating system within the system software and the applications within the application software, thereby ensuring that the operating system or applications are running in the trusted state expected by the design goals. It's important to note that trust is not the same as security, but it is the foundation of security. Data security solutions and strategies can only further ensure security if they operate in an untampered, trusted environment. In other words, by ensuring the integrity of the operating system and applications, it's possible to ensure that the computer system uses the correct software stack and that any changes made to the software stack due to attacks can be detected promptly. In short, incorporating trusted verification can effectively reduce the likelihood of attacks due to the use of unknown or tampered operating systems or applications.

[0034] The aforementioned trusted computing technology can be implemented through measurement and verification techniques. Measurement involves collecting the status of the application or operating system being tested, while verification compares the measurement results with preset reference values ​​to check for consistency. If they match, the trusted verification passes; otherwise, it fails. In actual implementation, these techniques rely on a Root of Trust, which is a reliable foundation or starting point in a computer system, used to ensure the security and trustworthiness of the entire system. In computer devices, trusted hardware chips are typically used as the Root of Trust. Based on the differences between the chip and the trusted software stack running on it, the trusted hardware can be categorized into several standards: Trusted Platform Module (TPM), Trusted Cryptography Module (TCM), and Trusted Platform Control Module (TPCM). Considering that TPM technology is more mature and commercially available, this specification will uniformly base the implementation of the aforementioned trusted computing technology on TPM in the following discussion.

[0035] TPM is an independent hardware security module located outside the CPU, capable of resisting software attacks and controlling access. It can be used to store tamper-proof data and provides cryptographic operations such as encryption, decryption, and signing. In trusted computing technology, TPM can typically be used to record metrics of relevant components during computer system startup, such as the hash value of the corresponding component image. Specifically, before loading the next component, each component can calculate a fixed-length hash value for the component to be loaded and store it in the TPM. The TPM can compare the stored hash value with a preset hash value; if they match, the corresponding component is considered tamper-proof, maintaining its original integrity. This process repeats until the last component is loaded. Alternatively, a corresponding metric report can be generated after loading and submitted to a remote verifier maintaining preset hash values ​​to prove whether the device is in a trusted state, thus fully constructing the corresponding static chain of trust. In short, the essence of a static chain of trust is a continuous verification chain used to ensure that the security and integrity of each step in the entire startup process can be traced and verified.

[0036] However, the above static trust chain still has the following problems:

[0037] 1. Lack of runtime protection: While a static trust chain establishes a trusted state at system startup, it does not involve continuous monitoring and protection during operating system runtime. Therefore, once the operating system is loaded, the static trust chain's function ends. During system runtime, new security threats may emerge, such as malware injection, system call tampering, or privilege abuse, which the static trust chain struggles to address specifically.

[0038] 2. Limited to the operating system level, in real-world scenarios, computer systems often run a wide variety and numerous applications that are frequently updated and changed. This makes establishing and maintaining a trust chain for each application extremely difficult, potentially consuming significant computing and storage resources. This is impractical for TPMs, which generally have weaker performance, and is particularly pronounced in resource-constrained environments such as mobile devices or embedded systems. The operating system level itself provides a degree of abstraction and control, making the establishment of a trust chain at this level relatively easy to manage and implement.

[0039] Of course, in order to solve the first problem, even if we ignore the objective factors of TPM itself and try to perform dynamic measurement and verification directly at runtime to achieve runtime protection, it is impossible. The reason is that applying the verification hash method to the runtime will generate huge resource overhead, which will seriously hinder the normal operation of the computer system.

[0040] Regarding the second issue, to protect at the application level, the following security mechanisms can be adopted: mechanisms deployed around the application, such as application firewalls, and mechanisms integrated within the application, such as Runtime Application Self-Protection (RASP). These mechanisms are designed to protect against different attack characteristics and targets; however, both are designed based on known publicly disclosed vulnerabilities and lack effective protection against zero-day vulnerabilities and bypass attacks. Furthermore, without the support of the aforementioned trusted hardware and trusted chains, the integrity of these mechanisms themselves can be completely compromised by attackers, resulting in limited reliability.

[0041] Based on this, the present specification proposes the following technical solutions to solve the above problems.

[0042] This specification provides a software protection system. Figure 1 This is a schematic diagram illustrating the architecture of a software protection system according to an exemplary embodiment of this specification. Figure 1 As shown, the system includes a target device 11, a network 12, and a remote security management center 13.

[0043] The target device 11 incorporates a security intermediary component on top of its existing software components. This component can interact with a remote security management center 13 via network 12, allowing the remote security management center 13 to determine the trustworthiness of the security intermediary component 11. If the security intermediary component is trustworthy, it can perform local authentication of the corresponding software components according to a preset security policy, thereby determining the trustworthiness of the software components. The interaction between the security intermediary component, the remote security management center 13, and the software components can occur during system runtime. The security intermediary component can act as a trusted intermediate component to verify the trustworthiness of the software components, and the verification process does not involve traditional checksum hashing. The target device 11 can be a physical server containing an independent host or a virtual server hosted in a host cluster. Alternatively, users can use electronic devices such as mobile phones, tablets, laptops, PDAs (Personal Digital Assistants), and wearable devices (such as smart glasses and smartwatches). One or more embodiments in this specification do not limit this.

[0044] The aforementioned remote security management center 13 refers to a management platform that does not run on the target device 11 but is connected via the Internet. The system administrators on this platform can be either the user of the target device 11 or a third-party cloud service provider. This platform can determine the trust status of the security intermediary components of the target device through remote authentication and can monitor and adjust the operation of the target device within the aforementioned software protection system by obtaining operational information and issuing security policies. With the direct participation of the aforementioned administrators, the security management center 13 can be assumed to be an always-trusted device in this specification.

[0045] Figure 2 This is a schematic diagram illustrating the construction of a trusted chain by a target device during startup, as shown in an exemplary embodiment of this specification. Figure 2 As shown, the target device of the software protection system in this specification includes conventional system components such as a Basic Input / Output System (BIOS) or similar firmware boot code, a BIOS boot block, a bootloader, an operating system, and applications. The operating system and applications can be collectively referred to as software components. Furthermore, Figure 2 It also includes operating system-level security intermediary components corresponding to the operating system, and application-level security intermediary components corresponding to the application. The operating system-level security intermediary components and application-level security intermediary components can be collectively referred to as the security intermediary components corresponding to their respective software components.

[0046] Furthermore, the specific correspondence between the security intermediary component and the software component can change depending on the different requirements for the trusted chain. Assuming the aforementioned software component can include an operating system and / or an application, then if the software component only contains an operating system, the security intermediary component includes the system security intermediary component for that operating system. If the software component only contains an application, the security intermediary component includes the program security intermediary component for that application. If the software component includes both an operating system and an application, the security intermediary component is a shared security intermediary component for both the operating system and the application; alternatively, the security intermediary component includes both the system security intermediary component for the operating system and the program security intermediary component for the application.

[0047] During the boot process of the target device, following the component loading order of BIOS, BIOS boot block, boot loader, operating system, and applications, each component can sequentially measure the subsequent components to be loaded (corresponding to...). Figure 2 (The order of the solid arrows) means that a hash calculation is performed on the image of the corresponding component, and the corresponding hash value can be stored as a metric in the Platform Configuration Register (PCR) in the TPM for verification. In the target device, the hash values ​​of each component are stored in a preset memory, namely the aforementioned register (corresponding to...). Figure 2 If all components (as indicated by the dashed arrow) are verified, an initial trusted chain can be constructed. The security intermediary component is implemented based on the process running in the environment of the corresponding software component. Therefore, it can be regarded as being in the same environment as the corresponding software component and being loaded together with the software component. Thus, compared with the traditional static trusted chain, the above-mentioned initial trusted chain still extends the components involved to the application level.

[0048] The process of verifying the hash value can be performed by a remote security management center. Specifically, the remote security management center can actively or passively obtain the hash value from the aforementioned storage via the network and determine whether the obtained hash value matches the preset expected hash value within the remote security management center. If the determination result is yes, the trustworthiness of the corresponding component in the aforementioned trusted chain can be initialized. If the determination result is no, the administrators of the remote security management center can be notified that there is an anomaly in the target device's startup process, such as tampering with the corresponding component, so as to promptly locate the target device and handle the corresponding anomaly.

[0049] This specification allows defining an initial trust level for each verified component. This trust level is an abstract variable that measures the component's trustworthiness during operation. Since the probability of a component being compromised by an attacker gradually increases during operation, the trust level can gradually decrease over time. Conversely, by judging the trust level, the trustworthiness of a component can be quickly and effectively determined. For example, the trust level can be a continuous value between 0 and 1, where 1 represents trustworthiness, 0 represents untrustworthiness, and 0.5 is the trust threshold. If a component's trust level is below the threshold, it can be determined that the component is untrustworthy; if its trust level is above the threshold, it can be determined that the component is trustworthy. Furthermore, considering that different components have different code sizes and logical complexities, their trust level decreases at different rates, meaning that components more easily attacked will experience a faster decrease in trustworthiness. Additionally, each component can have a different trust threshold set, and this threshold can be used to classify trustworthy and untrustworthy states, thereby increasing the flexibility in setting the trust level.

[0050] Furthermore, each component participating in the trusted chain can be considered as a node. As mentioned earlier, during operation, trustworthiness decreases over time. Therefore, the rate at which trustworthiness decreases over time is called the trustworthiness decline rate. (Node N) α The rate of decline in credibility is represented by λ. α Represents (λ) α ≥0). Furthermore, since the trustworthiness degradation rate is related to factors such as program complexity, the modules and components used, and the operating environment, it reflects the probability of a component being attacked and damaged. The initial trustworthiness established by a trusted chain node after startup is denoted as C. α The corresponding establishment time is t. α Therefore, we can obtain the real-time reliability of the component corresponding to any node:

[0051]

[0052] For the distinction between trustworthy and untrustworthy concepts, there exists a trustworthiness threshold, denoted as θ. If Cred α If (t)≥θ, then node N is called α The corresponding component is trustworthy; otherwise, node N is not. α The corresponding component is untrusted.

[0053] Those skilled in the art will understand that the BIOS boot block, BIOS, and boot loader are low-level components that only work during the boot phase and do not run during the system operation phase. Even if attacked, they can be detected during the next boot process. Therefore, the trust degradation rate of the above-mentioned low-level components can be set to 0 during system operation, that is, the components are always trustworthy, or the above-mentioned low-level components can be directly removed from the above-mentioned initial trust chain to shorten the trust chain and improve the resource utilization of TPM.

[0054] Furthermore, the above process can be executed during the operation of the target device, not just during the startup process. Therefore, the above initial trust chain can also be called a dynamic trust chain applicable to runtime.

[0055] The following is combined with Figure 3 This section describes the verification process for the trusted state between the remote security management center and the security intermediary component, as well as between the security intermediary component and the corresponding software components. For example... Figure 3 As shown, the target device uses the remote security management center as a trusted source and as a trusted status monitoring platform. The verification process is as follows:

[0056] In step S302, the security intermediary component stores the hash value of its own operation information in the TPM.

[0057] In one embodiment, the security intermediary component can maintain corresponding runtime information, which may include: the security intermediary component's own state information and configuration information, such as its own call stack, control flow, global variables, configuration files, and security policies for the corresponding software components; interaction verification information with the corresponding software components; file data and process information within its environment, etc.

[0058] Among these, the aforementioned important files can correspond to different contents based on the differences between system security intermediary components and application security intermediary components: For system security intermediary components, which reside in the same environment as the operating system, the file data within that environment refers to the binary executable files or library files required by the file system within that environment, as well as configuration files including system configuration; for application security intermediary components, which reside in the same environment as the application, the file data within that environment refers to the application's own configuration files. As for process information representing the scanning status of other processes, abnormal or malicious processes in the corresponding environment can be identified through comparison and filtering.

[0059] Whenever new runtime information is generated, its generated content can be appended to the end of the log file containing the original runtime information. Simultaneously, the hash value of the new runtime information or the entire log file is stored in the TPM register. When the security intermediary component includes both a system security intermediary component and a program security intermediary component, each component can independently maintain its log file and TPM register value (i.e., the hash value stored in that register). When the security intermediary component is a shared security intermediary component corresponding to the aforementioned operating system and application, this component can jointly maintain the log file and TPM register value for both the corresponding operating system and application. This specification does not impose any limitations on this.

[0060] Step S304: The remote security management center obtains the operation information of the security intermediary component.

[0061] In one embodiment, the remote security management center can obtain the operational information of the security intermediary component so that it can subsequently perform remote authentication on it. The remote security management center can request the security intermediary component to send operational information by sending a request, or the security intermediary component can proactively send operational information to the remote security management center under preset conditions; this specification does not impose any limitations on this.

[0062] Furthermore, there is no absolute order of execution between steps S302 and S304; the specific order can be determined and adjusted according to actual needs.

[0063] Step S306: The remote security management center obtains the TPM's registration information.

[0064] In one embodiment, after the TPM obtains the hash value of the operational information of the security intermediary component, it can generate a target signature of the hash value based on a preset private key, and send the target signature along with the corresponding hash value as registered information to the remote security management center. Specifically, the aforementioned registered information can adopt a data structure called Quote generated through a preset API. This data structure contains the selected register value and the signature of the data by the TPM using the contained private key. This signature can prevent attackers from forging the TPM register value. Similar to the method of sending operational information, the generation and sending of registered information can also be triggered by a remote authentication request sent by the remote security management center to the TPM, or by the TPM's preset rules. This specification does not impose any limitations on this.

[0065] Once the remote security management center obtains the registered information, it can verify the target signature using the public key publicly provided by the trusted platform module on the network, and match the hash value with the runtime information. If the target signature verification passes and the hash value matches the runtime information, the trustworthiness of the security intermediary component can be determined based on the runtime information. Specifically, the target signature verification is used to verify the authenticity of the TPM register value, and the hash matching is used to verify the authenticity of the runtime information, preventing forgery or tampering. If verification fails, it indicates that the registered information was not generated by a genuine TPM; if matching fails, it indicates that the runtime information provided by the security intermediary component may be forged or tampered with.

[0066] For genuine, unaltered operational information, the remote security management center can identify abnormal operational states through manual review or analysis tools. This allows them to determine if the security intermediary component itself has been attacked, resulting in compromised integrity. Examples include abnormal information in the security intermediary component's configuration file or the detection of pre-marked abnormal processes in other processes. If no abnormalities are found, the trustworthiness of the security intermediary component can be reset to its maximum value, i.e., the time t in Formula 1 above can be reset. α .

[0067] Those skilled in the art will understand that, as mentioned above, although the aforementioned operational information may also include information about the software component corresponding to the security intermediary component, the remote security management center still cannot adjust the credibility of the software component based on the operational information. This is because there must be a time gap between the time when the security intermediary component obtains the information about the software component and the time when the remote security management center obtains the operational information of the security intermediary component. This gap will lead to information lag, thereby affecting the remote security management center's judgment on the credibility of the software component. Therefore, the operational information can at most serve as one of the bases for the remote security management center to infer the credibility of the software component, but it cannot serve as key evidence.

[0068] Steps S302 to S306 above constitute the remote authentication process between the remote security management center and the security intermediary component. The purpose is to ensure that the security intermediary component remains in a trusted state after running for a period of time.

[0069] Step S308: The remote security management center issues security policies to the security intermediary component.

[0070] In one embodiment, if the remote security management center determines that the security intermediary component is trustworthy through remote authentication, it can issue a security policy to the security intermediary component, enabling the component to perform local authentication of the corresponding software component. Conversely, if the remote security management center determines that the security intermediary component is untrustworthy, there is no need to issue the aforementioned security policy, since even if the security intermediary component performs local authentication based on a valid security policy, the authentication result will still be unreliable if it is untrustworthy. The so-called security policy may include judgment policies for abnormal behavior of the operating system and / or applications, such as abnormal interface call parameter characteristics, abnormal file access behavior characteristics, etc., and may also include corresponding processing and reporting policies, such as simply logging, sending warnings to the remote security management center, terminating abnormal programs, etc.

[0071] It should be noted that all the aforementioned local authentication should only be performed after successful remote authentication. However, this manual includes a special case: the target device's first secure boot and the establishment of an initial trusted chain. In this case, any node in the initial trusted chain, including the security intermediary component, can be considered trustworthy. Therefore, remote authentication can be skipped, and local verification can proceed directly. Of course, if the initial trusted chain construction time exceeds the preset trusted duration, remote authentication must be performed again to ensure the trustworthiness of the security intermediary component.

[0072] In step S310, the security intermediary component receives a local verification request from the corresponding software component during operation.

[0073] In one embodiment, the system security intermediary component can receive a local verification request from the operating system, and the application security intermediary component can receive a local verification request from the application.

[0074] In step S312, the security intermediary component obtains the software operation information of the corresponding software component and performs local authentication.

[0075] In one embodiment, the security intermediary component can obtain the software operation information of the corresponding software component, and determine whether the operation status of the corresponding software component is abnormal based on the software operation information and the aforementioned security policy. If the operation status is normal, the trustworthiness of the software component is updated to the trustworthiness of the security intermediary component; if the operation status is abnormal, the abnormality can be reported to the remote security management center. The aforementioned software operation information is equivalent to the interaction verification information with the corresponding software component contained in the operation information. The software operation information may further include the context information of the running software, function call parameters, and memory space data, etc. The aforementioned security policy may specify a verification method for the aforementioned software operation information.

[0076] In particular, for applications within software components, different programming languages ​​can be specifically validated. The following example... Figure 4 Taking Java applications as an example, this section introduces the local authentication process for Java applications.

[0077] In one embodiment, when the software component includes the application, the security intermediary component can insert verification logic into the calling method of the method interface corresponding to the application according to the security policy; wherein, the verification logic can be used to terminate the execution process if it is determined that there is an anomaly during the execution of the calling method.

[0078] Specifically, Figure 4 The application is written in Java, so its actual execution file is a binary file with a specific format and the .class extension. By leveraging Java's Instrumentation mechanism, verification trigger logic is inserted into critical locations within the methods during class loading. This verification trigger logic retrieves important contextual information from the application's runtime, such as the call stack, important global variables, and call parameters, and sends it to a security intermediary component at the same layer for verification. Through this logic injection method, verification logic in the security policy can be triggered based on code inserted at scheduled tasks or specific execution locations, thereby ensuring the application's trustworthiness in a deep and comprehensive way.

[0079] like Figure 4 As shown, the program security intermediary component can maintain the environment image of the environment it is in, as well as the log report for the log file containing the running information. When the program security intermediary component receives the security policy issued by the remote security management center, it provides three methods: class loading check, logic injection, and boundary check.

[0080] Method 1: Class loading detection. This method involves verifying the class definition during the linking process of the binary file to ensure it is valid and does not violate the Java Virtual Machine (JVM) specification. For example, it checks if the class has the correct class file format, the correct magic number, the correct version number, and the correct constant pool. If the class passes verification, it can be safely loaded and executed by the JVM.

[0081] Method 2: Boundary checking typically refers to the process by which the JVM execution engine, after obtaining data from the JVM's Runtime Data Area and executing array operations, string operations, or other operations requiring index or parameter range checks via native method calls, ensures that the index or parameter value does not exceed a predefined boundary or range. This is a practice to prevent Index Out Of Bounds Exceptions and other types of errors, aiming to ensure the robustness and stability of the program.

[0082] Method 3: Logic injection, typically referring to a security vulnerability, allows attackers to manipulate application input data to alter the program's logical flow, thereby performing unintended actions. This type of attack is usually malicious, designed to bypass security controls or perform unauthorized behavior. However, in this specification, the concept of logic injection can also be used for legitimate and secure purposes, namely, injecting secure logic. In this case, secure logic injection refers to intentionally adding additional logic to the application to enhance the system's security and robustness. Figure 4 The security policy can inject security logic into the JVM's class loader, so that the operation behavior indicated by the security logic can be executed during the application's class loading process.

[0083] The above embodiments are based on Java applications, but their design can be applied to other languages ​​as well. The difference lies in the implementation details, which vary depending on the specific characteristics of each language. For interpreted languages ​​with built-in virtual machines, such as Python, the approach used in Java programs can be similar, identifying application boundaries and adding security check logic to the application interpreter or runtime library. However, for languages ​​like C / C++ that compile to raw machine code, application boundaries are more difficult to determine, and the use of common instructions is also vulnerable to attack. In such scenarios, hardware-supported isolation mechanisms, such as Software Guard Extensions (SGX), can address this issue. SGX establishes isolated enclaves to prevent direct interaction between the application and the external environment. Its communication interface serves as the application boundary for protection and is combined with the trusted chain security verification mechanism described in this specification to achieve trusted verification of the application.

[0084] Returning to the software runtime information mentioned above, regardless of the detection method used, if an anomaly is detected during the execution of the corresponding called method, the application's execution can be terminated, thereby minimizing potential damage to the application. If the verification passes, the application component's trustworthiness can be updated to the current trustworthiness of the corresponding security intermediary component. It is understandable that the above method of collecting application context information and verifying application trustworthiness based on insertion verification logic can save significant resource overhead compared to the check hash method. Furthermore, the insertion verification logic can more flexibly determine the application's detection points and behaviors, enabling the solution in this specification to possess a certain ability to identify zero-day vulnerabilities and bypass attacks.

[0085] Of course, the method described above for updating the current trustworthiness of the corresponding security intermediary component is generally only applicable to nodes with only one security intermediary component performing local authentication of the software component. This is in contrast to nodes with multiple security intermediary components, such as the same software component corresponding to different security intermediary components (N1, N2, ..., N...). k When this happens, the updated trust level of the node corresponding to the aforementioned software component in the trusted chain should be set to the minimum trust level among the nodes corresponding to multiple security intermediary components, i.e.

[0086] C α =max(min 1≤i≤k (Cred i (t)), Cred α (t)), t α =t (Formula 2)

[0087] Steps S308 to S312 above constitute the local authentication process between the security intermediary component and the software component. The purpose is to enable trusted detection to cover software components, including applications, and to support this process during system operation.

[0088] It is worth mentioning that this manual, by introducing a secure intermediary component and its trustworthiness, links the complete remote authentication and local verification processes together, while ensuring that they do not interfere with each other during operation. They can be configured to run in parallel or alternately, or different running frequencies can be configured for each.

[0089] As can be seen from the above embodiments, this specification extends the trust chain from the traditional operating system to the application based on the security intermediary component, thereby establishing a trust relationship between the lowest-level hardware root of trust and the top-level application, and realizing runtime protection. In addition, based on the application insertion verification logic, the context information of the application is collected and verified, thereby realizing an efficient application runtime measurement mechanism, which can ensure low overhead and real-time measurement during application operation. Furthermore, by improving the anomaly detection points and detection behaviors, the anomaly detection mechanism corresponding to the application has high effectiveness and universality, and has a certain ability to defend against zero-day vulnerabilities and bypass attacks.

[0090] Figure 5 This is a flowchart illustrating an exemplary embodiment of a software protection method, as shown in this specification. Figure 5 As shown, this method is applied to a security mediation component configured in the target device, including:

[0091] Step S502: Perform local authentication on the corresponding software components according to the preset security policy, wherein the software components are configured in the target device;

[0092] Step S504: Determine the trustworthiness of the software component based on the local authentication result;

[0093] The operational information of the security intermediary component is obtained by the remote security management center for remote authentication of the security intermediary component. The result of the remote authentication is used to determine whether the security intermediary component is trustworthy, and the trustworthiness of the security intermediary component is updated based on the determination result.

[0094] As mentioned above, the target device is also equipped with a trusted platform module; the remote security management center is also used for:

[0095] Obtain the registered information maintained in the trusted platform module, the registered information recording the hash value of the running information, and the target signature generated by the trusted platform module based on the hash value using a preset private key;

[0096] The target signature is verified using the public key provided by the trusted platform module, and the hash value is matched with the runtime information.

[0097] If the target signature verification is successful and the hash value matches the runtime information, the reliability of the security intermediary component is determined based on the runtime information.

[0098] As previously stated, the trusted platform module is used for:

[0099] Based on a preset root of trust, the security intermediary component and the software component are measured step by step to store the hash values ​​of each component in the target device into a preset memory and construct the corresponding trusted chain.

[0100] The remote security management center is also used for:

[0101] Obtain the hash value in the memory and determine whether the obtained hash value is consistent with the preset expected hash value;

[0102] If the judgment result is yes, the trustworthiness of the corresponding component in the trusted chain is initialized.

[0103] As previously stated, the software components include an operating system and / or applications;

[0104] In the case where the software component includes the operating system and the application...

[0105] The security intermediary component is a shared security intermediary component corresponding to the operating system and the application; or,

[0106] The security intermediary component includes a system security intermediary component corresponding to the operating system and a program security intermediary component corresponding to the application.

[0107] As mentioned above, the method further includes:

[0108] When the software component includes the application, verification logic is inserted into the method call method corresponding to the application according to the security policy; wherein, the verification logic is used to: terminate the execution process if it is determined that an exception exists during the execution of the method call.

[0109] As mentioned above, the remote security management center is also used for:

[0110] If the determination result is yes, the security policy is issued to the security intermediary component so that the security intermediary component can perform the local authentication.

[0111] As mentioned above, the operational information of the security intermediary component includes at least one of the following:

[0112] The component's own state and configuration information, interaction verification information with the corresponding software components, and file data and process information within its environment.

[0113] As mentioned above, the local authentication of the corresponding software components according to the preset security policy includes:

[0114] Obtain the software operation information of the corresponding software component, and determine whether the operation status of the software component is abnormal based on the software operation information and the security policy. If the operation status is normal, update the trustworthiness of the software component to the trustworthiness of the security intermediary component.

[0115] Figure 6 This is a flowchart illustrating another software protection method as shown in an exemplary embodiment of this specification, such as... Figure 6 As shown, this method is applied to a remote security management center configured in the target device, including:

[0116] Step S602: Obtain the operation information of the security intermediary component. The security intermediary component is used to perform local authentication on the corresponding software component according to the preset security policy, and determine the trustworthiness of the software component based on the local authentication result. The security intermediary component and the software component are configured in the target device.

[0117] Step S604: Perform remote authentication on the security intermediary component based on the operation information, determine whether the security intermediary component is trustworthy based on the remote authentication result, and update the trustworthiness of the security intermediary component based on the determination result.

[0118] As mentioned above, the target device is also equipped with a trusted platform module; the method further includes:

[0119] Obtain the registered information maintained in the trusted platform module, the registered information recording the hash value of the running information, and the target signature generated by the trusted platform module based on the hash value using a preset private key;

[0120] The target signature is verified using the public key provided by the trusted platform module, and the hash value is matched with the runtime information.

[0121] If the target signature verification is successful and the hash value matches the runtime information, the reliability of the security intermediary component is determined based on the runtime information.

[0122] As previously stated, the trusted platform module is used for:

[0123] Based on a preset root of trust, the security intermediary component and the software component are measured step by step to store the hash values ​​of each component in the target device into a preset memory and construct the corresponding trusted chain.

[0124] The method further includes:

[0125] Obtain the hash value in the memory and determine whether the obtained hash value is consistent with the preset expected hash value;

[0126] If the judgment result is yes, the trustworthiness of the corresponding component in the trusted chain is initialized.

[0127] As previously stated, the software components include an operating system and / or applications;

[0128] In the case where the software component includes the operating system and the application...

[0129] The security intermediary component is a shared security intermediary component corresponding to the operating system and the application; or,

[0130] The security intermediary component includes a system security intermediary component corresponding to the operating system and a program security intermediary component corresponding to the application.

[0131] As mentioned above, the security intermediary component is also used for:

[0132] When the software component includes the application, verification logic is inserted into the method call method corresponding to the application according to the security policy; wherein, the verification logic is used to: terminate the execution process if it is determined that an exception exists during the execution of the method call.

[0133] As mentioned above, the method further includes:

[0134] If the determination result is yes, the security policy is issued to the security intermediary component so that the security intermediary component can perform the local authentication.

[0135] As mentioned above, the operational information of the security intermediary component includes at least one of the following:

[0136] The component's own state and configuration information, interaction verification information with the corresponding software components, and file data and process information within its environment.

[0137] As mentioned above, the process of local authentication performed by the security intermediary component includes:

[0138] Obtain the software operation information of the corresponding software component, and determine whether the operation status of the software component is abnormal based on the software operation information and the security policy. If the operation status is normal, update the trustworthiness of the software component to the trustworthiness of the security intermediary component.

[0139] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an exemplary embodiment. Please refer to... Figure 7At the hardware level, the device includes a processor 702, an internal bus 704, a network interface 706, memory 708, and non-volatile memory 710, and may also include other hardware required for its functions. One or more embodiments of this specification can be implemented in software, for example, the processor 702 reads the corresponding computer program from the non-volatile memory 710 into memory 708 and then runs it. Of course, besides software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution entity of the following processing flow is not limited to individual logic units, but can also be hardware or logic devices. Corresponding to the embodiments of the aforementioned software protection method, this specification also provides embodiments of a software protection device.

[0140] Corresponding to the aforementioned embodiment of a software protection method, this specification also provides an embodiment of a software protection device.

[0141] Please refer to Figure 8 , Figure 8 This is a schematic diagram illustrating the structure of a software protection device in an exemplary embodiment. For example... Figure 8 As shown, in the software implementation, the device is applied to a security mediation component configured in the target device and may include:

[0142] Local authentication unit 81 is used to perform local authentication on the corresponding software components according to a preset security policy, wherein the software components are configured in the target device;

[0143] The software component trustworthiness determination unit 82 is used to determine the trustworthiness of the software component based on the local authentication result;

[0144] The operational information of the security intermediary component is obtained by the remote security management center for remote authentication of the security intermediary component. The result of the remote authentication is used to determine whether the security intermediary component is trustworthy, and the trustworthiness of the security intermediary component is updated based on the determination result.

[0145] Optionally, the target device is further configured with a trusted platform module; the remote security management center is also used for:

[0146] Obtain the registered information maintained in the trusted platform module, the registered information recording the hash value of the running information, and the target signature generated by the trusted platform module based on the hash value using a preset private key;

[0147] The target signature is verified using the public key provided by the trusted platform module, and the hash value is matched with the runtime information.

[0148] If the target signature verification is successful and the hash value matches the runtime information, the reliability of the security intermediary component is determined based on the runtime information.

[0149] Optionally, the trusted platform module is used for:

[0150] Based on a preset root of trust, the security intermediary component and the software component are measured step by step to store the hash values ​​of each component in the target device into a preset memory and construct the corresponding trusted chain.

[0151] The remote security management center is also used for:

[0152] Obtain the hash value in the memory and determine whether the obtained hash value is consistent with the preset expected hash value;

[0153] If the judgment result is yes, the trustworthiness of the corresponding component in the trusted chain is initialized.

[0154] Optionally, the software component includes an operating system and / or applications;

[0155] In the case where the software component includes the operating system and the application...

[0156] The security intermediary component is a shared security intermediary component corresponding to the operating system and the application; or,

[0157] The security intermediary component includes a system security intermediary component corresponding to the operating system and a program security intermediary component corresponding to the application.

[0158] Optionally, the device further includes:

[0159] The verification logic insertion unit 83 is used to insert verification logic into the calling method of the method interface corresponding to the application according to the security policy when the software component includes the application; wherein the verification logic is used to terminate the execution process if it is determined that there is an exception in the execution process of the calling method.

[0160] Optionally, the remote security management center is also used for:

[0161] If the determination result is yes, the security policy is issued to the security intermediary component so that the security intermediary component can perform the local authentication.

[0162] Optionally, the operational information of the security intermediary component includes at least one of the following:

[0163] The component's own state and configuration information, interaction verification information with the corresponding software components, and file data and process information within its environment.

[0164] Optionally, the local authentication unit 81 is specifically used for:

[0165] Obtain the software operation information of the corresponding software component, and determine whether the operation status of the software component is abnormal based on the software operation information and the security policy. If the operation status is normal, update the trustworthiness of the software component to the trustworthiness of the security intermediary component.

[0166] Corresponding to the aforementioned embodiment of another software protection method, this specification also provides an embodiment of another software protection device.

[0167] Please refer to Figure 9 , Figure 9 This is a schematic diagram illustrating the structure of a software protection device in an exemplary embodiment. For example... Figure 9 As shown, in the software implementation, the device is applied to a remote security management center and may include:

[0168] The operation information acquisition unit 91 is used to acquire the operation information of the security intermediary component. The security intermediary component is used to perform local authentication on the corresponding software component according to the preset security policy, and to determine the trustworthiness of the software component based on the local authentication result. The security intermediary component and the software component are configured in the target device.

[0169] The security intermediary component trustworthiness update unit 92 is used to remotely authenticate the security intermediary component based on the operation information, determine whether the security intermediary component is trustworthy based on the remote authentication result, and update the trustworthiness of the security intermediary component based on the determination result.

[0170] Optionally, the target device is further configured with a trusted platform module; the apparatus further includes:

[0171] The trust judgment unit 93 is used to obtain the registered information maintained in the trusted platform module. The registered information records the hash value of the running information and the target signature generated by the trusted platform module based on the hash value using a preset private key.

[0172] The target signature is verified using the public key provided by the trusted platform module, and the hash value is matched with the runtime information.

[0173] If the target signature verification is successful and the hash value matches the runtime information, the reliability of the security intermediary component is determined based on the runtime information.

[0174] Optionally, the trusted platform module is used for:

[0175] Based on a preset root of trust, the security intermediary component and the software component are measured step by step to store the hash values ​​of each component in the target device into a preset memory and construct the corresponding trusted chain.

[0176] The device further includes:

[0177] The credibility initialization unit 94 is used to obtain the hash value in the memory and determine whether the obtained hash value is consistent with the preset expected hash value;

[0178] If the judgment result is yes, the trustworthiness of the corresponding component in the trusted chain is initialized.

[0179] Optionally, the software component includes an operating system and / or applications;

[0180] In the case where the software component includes the operating system and the application...

[0181] The security intermediary component is a shared security intermediary component corresponding to the operating system and the application; or,

[0182] The security intermediary component includes a system security intermediary component corresponding to the operating system and a program security intermediary component corresponding to the application.

[0183] Optionally, the security mediation component is further used for:

[0184] When the software component includes the application, verification logic is inserted into the method call method corresponding to the application according to the security policy; wherein, the verification logic is used to: terminate the execution process if it is determined that an exception exists during the execution of the method call.

[0185] Optionally, the device further includes:

[0186] The security policy delivery unit 95 is used to deliver the security policy to the security intermediary component when the judgment result is yes, so that the security intermediary component can perform the local authentication.

[0187] Optionally, the operational information of the security intermediary component includes at least one of the following:

[0188] The component's own state and configuration information, interaction verification information with the corresponding software components, and file data and process information within its environment.

[0189] Optionally, the local authentication process performed by the security intermediary component includes:

[0190] Obtain the software operation information of the corresponding software component, and determine whether the operation status of the software component is abnormal based on the software operation information and the security policy. If the operation status is normal, update the trustworthiness of the software component to the trustworthiness of the security intermediary component.

[0191] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0192] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the solution in this specification according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0193] In addition, this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the corresponding steps in the method described above.

[0194] This specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the corresponding steps in the method described above.

[0195] The embodiments of the subject matter and functional operation described in this specification can be implemented in the following ways: digital electronic circuits, tangibly embodied computer software or firmware, computer hardware including the structures disclosed in this specification and their structural equivalents, or combinations thereof. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible, non-transitory program carrier for execution by a data processing apparatus or for controlling the operation of a data processing apparatus. Alternatively or additionally, the program instructions may be encoded on artificially generated propagation signals, such as machine-generated electrical, optical, or electromagnetic signals, which are generated to encode information and transmit it to a suitable receiving device for execution by the data processing apparatus. The computer storage medium may be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or combinations thereof.

[0196] The processing and logic flow described in this specification can be executed by one or more programmable computers that execute one or more computer programs to perform corresponding functions by operating on input data and generating output. The processing and logic flow can also be executed by dedicated logic circuitry—such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits), and the device can also be implemented as dedicated logic circuitry.

[0197] Computers suitable for executing computer programs include, for example, general-purpose and / or special-purpose microprocessors, or any other type of processing unit. Typically, the processing unit receives instructions and data from read-only memory and / or random access memory. The basic components of a computer include a processing unit for implementing or executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices for storing data, such as disks, magneto-optical disks, or optical disks, or the computer will be operatively coupled to such mass storage devices to receive data from or transfer data to them, or both. However, a computer is not required to have such devices. Furthermore, a computer can be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device such as a universal serial bus (USB) flash drive, to name a few.

[0198] Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, such as semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., internal hard disks or removable disks), magneto-optical disks, and CD-ROM and DVD-ROM disks. Processors and memory may be supplemented by or incorporated into dedicated logic circuitry.

[0199] While this specification contains numerous specific implementation details, these should not be construed as limiting the scope of any invention or the scope of the claims, but rather are primarily intended to describe features of specific embodiments of a particular invention. Certain features described in the various embodiments herein may also be implemented in combination in a single embodiment. Conversely, various features described in a single embodiment may also be implemented separately in various embodiments or in any suitable sub-combination. Furthermore, while features may function in certain combinations as described above and even initially claimed in this way, one or more features from a claimed combination may be removed from that combination in some cases, and a claimed combination may refer to a sub-combination or a variation thereof.

[0200] Similarly, although the operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring these operations to be performed in the specific order shown or sequentially, or requiring all illustrated operations to be performed to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system modules and components in the above embodiments should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0201] Therefore, specific embodiments of the subject matter have been described. Furthermore, the processes depicted in the figures are not necessarily shown in a specific order or sequence to achieve the desired result. In some implementations, multitasking and parallel processing may be advantageous.

[0202] The above description is merely a preferred embodiment of this specification and is not intended to limit this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of protection of this specification.

Claims

1. A software protection system, comprising: A security intermediary component is used to perform local authentication of the corresponding software component according to a preset security policy, and to determine the trustworthiness of the software component based on the local authentication result. The security intermediary component and the software component are configured in the target device. A remote security management center is used to obtain the operation information of the security intermediary component and to remotely authenticate the security intermediary component based on the operation information. The trustworthiness of the security intermediary component is determined based on the remote authentication result, and the trustworthiness of the security intermediary component is updated based on the determination result. And, if the determination result is yes, the security policy is issued to the security intermediary component so that the security intermediary component performs the local authentication; The operational information of the security intermediary component includes at least one of the following: the component's own status information and configuration information, the interaction verification information with the corresponding software component, and the file data and process information in the environment.

2. The system according to claim 1, wherein the target device is further configured with a trusted platform module that is different from the security intermediary component.

3. The system according to claim 2, wherein the remote security management center is further configured to: Obtain the registered information maintained in the trusted platform module, the registered information recording the hash value of the running information, and the target signature generated by the trusted platform module based on the hash value using a preset private key; The target signature is verified using the public key provided by the trusted platform module, and the hash value is matched with the runtime information. If the target signature verification is successful and the hash value matches the runtime information, the reliability of the security intermediary component is determined based on the runtime information.

4. The system according to claim 3, wherein the trusted platform module is used for: Based on a preset root of trust, the security intermediary component and the software component are measured step by step to store the hash values ​​of each component in the target device into a preset memory and construct the corresponding trusted chain. The remote security management center is also used for: Obtain the hash value in the memory and determine whether the obtained hash value is consistent with the preset expected hash value; If the judgment result is yes, the trustworthiness of the corresponding component in the trusted chain is initialized.

5. The system according to claim 1, wherein the software component comprises an operating system and / or an application program; In the case where the software component includes the operating system and the application... The security intermediary component is a shared security intermediary component corresponding to the operating system and the application; or, The security intermediary component includes a system security intermediary component corresponding to the operating system and a program security intermediary component corresponding to the application.

6. The system according to claim 5, wherein the security intermediary component is further configured to: When the software component includes the application, verification logic is inserted into the method call method corresponding to the method interface of the application according to the security policy; wherein, The verification logic is used to terminate the execution process if an exception is detected during the execution of the called method.

7. The system according to claim 1, wherein the process of the security intermediary component performing local authentication includes: Obtain the software operation information of the corresponding software component, and determine whether the operation status of the software component is abnormal based on the software operation information and the security policy. If the operation status is normal, update the trustworthiness of the software component to the trustworthiness of the security intermediary component.

8. A software protection method, applied to a security intermediary component configured in a target device, comprising: Local authentication is performed on the corresponding software components according to a preset security policy, and the software components are configured in the target device. The trustworthiness of the software component is determined based on the local authentication results; The operational information of the security intermediary component is obtained by a remote security management center for remote authentication of the security intermediary component. The result of the remote authentication is used to determine whether the security intermediary component is trustworthy, and the trustworthiness of the security intermediary component is updated based on the determination result. If the determination result is positive, the security policy is issued to the security intermediary component to enable the security intermediary component to perform the local authentication. The operational information of the security intermediary component includes at least one of the following: component's own status information and configuration information, interaction verification information with the corresponding software component, and file data and process information in its environment.

9. A software protection method, applied to a remote security management center, comprising: The system obtains the operation information of a security intermediary component, which is used to perform local authentication on the corresponding software component according to a preset security policy, and to determine the trustworthiness of the software component based on the local authentication result. The security intermediary component and the software component are configured in the target device. The security intermediary component is remotely authenticated based on the operational information, and its trustworthiness is determined based on the remote authentication result. The trustworthiness of the security intermediary component is then updated based on the determination result. The operational information of the security intermediary component includes at least one of the following: component's own status information and configuration information, interaction verification information with the corresponding software component, and file data and process information within its environment. The method further includes: If the determination result is yes, the security policy is issued to the security intermediary component so that the security intermediary component can perform the local authentication.

10. A computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the method as claimed in any one of claims 8 to 9.

11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the steps of the method as claimed in any one of claims 8 to 9.

12. A computer program product comprising a computer program or instructions which, when executed by a processor, implement the steps of the method as described in any one of claims 8 to 9.

Images