CN118427891A - System security management method and device and electronic equipment - Google Patents

Abstract

The application provides a system security management method, a system security management device and electronic equipment. The method comprises the following steps: the electronic device may obtain the encrypted first summary file from the extended attribute during running or loading the system file in the REE. The electronic device may switch the execution environment to the TEE after sending the encrypted first summary file to the TEE under the execution environment of the REE. The electronic device may verify the encrypted first digest file at the TEE and generate a first verification result. When the first verification result is used for indicating that the encrypted first summary file is not tampered, the electronic device can continue to run or load the system file. Otherwise, when the first verification result is used for indicating that the encrypted first verification result is tampered, the electronic device may stop loading or running the system file. The method of the application realizes the effect of improving the integrity verification of the system by using the security verification file on the basis of not increasing the hardware cost.

Description

System security management method and device and electronic equipment

Technical Field

The present application relates to information security technologies, and in particular, to a system security management method, apparatus, and electronic device.

Background

With the continuous development of internet technology, network security threats have also presented an increasing trend. The Linux system is an open source operating system widely applied, and it is particularly important to ensure the system safety.

In the prior art, a method of adding a trusted platform module (Trusted Platform Module, TPM) in electronic equipment is generally sampled, so that functions of encryption of system files, authentication and authorization of users and the like are realized in the use process of the system, and the safety of the electronic equipment is improved.

The carrier of the TPM is a secure chip. To use the TPM related functionality in an electronic device, a secure chip needs to be implanted first. This approach greatly increases the hardware cost of the electronic device. Therefore, how to improve the system security without increasing the hardware cost of the electronic device is a problem to be solved.

Disclosure of Invention

The application provides a system security management method, a system security management device and electronic equipment, which are used for improving the system security on the basis of not increasing the hardware cost of the electronic equipment.

In a first aspect, the present application provides a system security management method, applying a rich execution environment of an electronic device, where the rich execution environment and a trusted execution environment are deployed in the electronic device, the method including:

Acquiring an encrypted first abstract file from an extended attribute, and transmitting the first abstract file to a trusted execution environment, so that the electronic equipment performs verification on the encrypted first abstract file in the trusted execution environment after switching the execution environment to the trusted execution environment, and obtains a first verification result, and switches back to the rich execution environment after transmitting the first verification result to the rich execution environment;

When the first verification result indicates that the encrypted first abstract file is not tampered, continuing to run or loading a system file;

the first abstract file is obtained by abstracting a system file.

In a second aspect, the present application provides a system security management apparatus, comprising:

The verification module is used for acquiring an encrypted first abstract file from the extended attribute, sending the first abstract file to a trusted execution environment, enabling the electronic equipment to verify the encrypted first abstract file in the trusted execution environment after switching the execution environment to the trusted execution environment, obtaining a first verification result, and switching back to the rich execution environment after sending the first verification result to the rich execution environment;

the processing module is used for continuing to run or load the system file when the first verification result indicates that the encrypted first abstract file is not tampered;

the first abstract file is obtained by abstracting a system file.

In a third aspect, the present application provides an electronic device comprising: a processor, and a memory communicatively coupled to the processor;

the memory stores a computer program; the processor executes the computer program stored by the memory to implement the method of the first aspect and any one of the possible designs of the first aspect.

In a fourth aspect, the present application provides a computer readable storage medium having stored therein a computer program for carrying out the method of the first aspect and any one of the possible designs of the first aspect when executed by a processor.

In a fifth aspect, the application provides a computer program product which, when executed by a processor, implements the method of the first aspect and any one of the possible designs of the first aspect.

According to the system security management method, the system security management device and the electronic equipment, in the process of running in REE or loading a system file, the encrypted first abstract file is obtained from the expansion attribute; after the encrypted first summary file is sent to the TEE under the execution environment of REE, the execution environment is switched to the TEE; verifying the encrypted first abstract file at the TEE, and generating a first verification result; when the first verification result is used for indicating that the encrypted first abstract file is not tampered, continuing to run or loading the system file; otherwise, when the first verification result is used for indicating that the encrypted first verification result is tampered, the loading or running of the system file is stopped, and the effect of improving the integrity verification of the system by using the security verification file is achieved on the basis of not increasing the hardware cost.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the application and together with the description, serve to explain the principles of the application.

FIG. 1 is a flow chart of a system security management method according to an embodiment of the present application;

FIG. 2 is a flowchart of generating a security verification document according to an embodiment of the present application;

FIG. 3 is a flowchart of a system security management method according to an embodiment of the present application;

FIG. 4 is a flowchart of a security verification document according to an embodiment of the present application;

FIG. 5 is a schematic diagram of a system security management device according to an embodiment of the present application;

fig. 6 is a schematic hardware structure of an electronic device according to an embodiment of the present application.

Specific embodiments of the present application have been shown by way of the above drawings and will be described in more detail below. The drawings and the written description are not intended to limit the scope of the inventive concepts in any way, but rather to illustrate the inventive concepts to those skilled in the art by reference to the specific embodiments.

Detailed Description

Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary examples do not represent all implementations consistent with the application. Rather, they are merely examples of apparatus and methods consistent with aspects of the application as detailed in the accompanying claims.

With the continuous development of internet technology, network security threats have also presented an increasing trend. System security is the basis for ensuring that users can use electronic devices normally. The Linux system is widely used as an open source operating system. Particularly in vehicles, on-board systems typically use the Linux system. The product attributes of a vehicle determine its extremely high demands on the safety of the system. Alternatively, the vehicle security herein may specifically include both functional security and information security. The information security may further include aspects of system integrity, confidentiality, availability, and the like. The purpose of the system integrity protection is, among other things, to prevent data in the system files from being tampered with.

The premise of integrity protection is to preserve the original metric values derived from the original data. The system may derive the current metric value prior to accessing the data. If the current metric value does not match the original metric value, it is indicated that there has been a change in the data in the system file. For this verification mode, two deep questions can be generated. One is where this metric is stored. And secondly how to ensure that the measurement itself is not tampered with. Metrics that achieve this integrity protection may include both static and dynamic processes. Where static metrics are integrity checks before run-time, while dynamic metrics refer to integrity checks at run-time.

In the prior art, starting from Linux 2.6.30, the Linux kernel integrates a mechanism for file integrity protection: IMA/EVM. The IMA is INTEGRITY MEASUREMENT ARCHITECTURE, namely an integrity metric architecture. The EVM is Embedded Virtual Machine, i.e., an embedded virtual machine. The main function of IMA is to collect a metric file and store the metric values. Platform configuration registers (Platform Configuration Register, PCR) such as kernel trust chain or trusted platform module (Trusted Platform Module, TPM). The IMA can also sign the metric value and judge whether the file is tampered with or not based on the metric value. The main functions of the EVM are to protect the extended attribute related to file security, such as selinux related "security.selinux", IMA related "security.ima", and capability related "security.capability", etc. Wherein ima and evm belong to the extended attributes of the file. The use of the IMA/EVM can solve the problem of where the metric is stored. IMA/EVM is a dynamic metric method. Furthermore, IMA typically solves the second problem above in combination with a TPM or kernel key ring subsystem. Wherein the TPM or kernel key ring subsystem provides the associated key. The IMA hashes and signs the metric value with the key.

However, the TPM is a secure chip. To use the TPM related functionality in an electronic device, a secure chip needs to be implanted first. This approach greatly increases the hardware cost of the electronic device. The kernel key ring has the problem of low security.

In order to solve the technical problems, the embodiment of the application provides a system security management method. The security management method is an IMA integrity measurement method based on a trusted execution environment (Trusted Execution Environment, TEE). The method can solve the problem of how to realize the system integrity measurement under the condition of TPM chip missing. The TEE has a higher security level than the rich execution environment (Rich Execution Environment, re) such as Linux, android. The TEE may provide secure services such as key storage for the REEs. TEE is more secure than kernel key ring and less costly than TPM. Therefore, based on the communication between the TEE and the REEs, the effect of improving the system safety can be achieved on the basis of not increasing the hardware cost of the electronic equipment.

In the present application, the system security management method of the following embodiment is executed with the electronic device as an execution subject. In particular, the execution body may be a hardware device of the electronic apparatus, or a software application implementing the embodiments described below in the electronic apparatus, or a computer-readable storage medium on which the software application implementing the embodiments described below is installed, or code of the software application implementing the embodiments described below.

The technical scheme of the application is described in detail below by specific examples. The following embodiments may be combined with each other, and some embodiments may not be repeated for the same or similar concepts or processes.

Fig. 1 is a flowchart of a system security management method according to an embodiment of the present application. As shown in fig. 1, the electronic device is taken as an execution subject, and a rich execution environment REE and a trusted execution environment TEE can be deployed in the electronic device. The REE can implement the switching of the execution environment in the electronic device by calling the interface of the TEE. Specifically, the electronic device may enable REEs after power-on. When the REE invokes the TEE through the interface, the execution environment of the electronic device may switch to the TEE. When the TEE completes execution, the execution environment of the electronic device may switch back to REE. Specifically, based on TEE and REE, the system security management method of the present embodiment may include the following steps:

S101, acquiring an encrypted first abstract file from the extended attribute, and sending the first abstract file to a trusted execution environment, so that the electronic equipment verifies the encrypted first abstract file in the trusted execution environment after switching the execution environment to the trusted execution environment, and obtains a first verification result, and switches back to the rich execution environment after sending the first verification result to the rich execution environment. The first abstract file is obtained by abstracting the system file.

In this embodiment, the electronic device may run the system file in the REEs. The electronic device may perform the system file integrity verification operation of the present embodiment when the system file is running. Specifically, when the system file starts to move, the electronic device may obtain the encrypted first summary file from the extended attribute of the system file. Alternatively, the first summary file may be security. Ima. Alternatively, the first summary file may include a summary of the content of the system file. The electronic device may send the encrypted first summary file to the TEE by invoking an interface of the TEE. Meanwhile, through the invocation of the TEE interface, the electronic device can switch the execution environment to the TEE.

A built-in private key may be stored within the TEE. The electronic device may verify the encrypted first digest file obtained by the TEE after switching the execution environment to the TEE. Alternatively, the verification process may be a process of decrypting and signing the encrypted first digest file using a built-in private key for the TEE. The electronic device may obtain the first verification result after the verification of the encrypted first summary file is completed. When the first verification result is verification passing, the first verification result is used for indicating that the encrypted first abstract file is not tampered. Otherwise, when the first verification result is verification failure, the first verification result is used for indicating that the encrypted first abstract file is tampered. The electronic device may return the first verification result to the tape REE by returning information using the TEE interface. When the TEE performs the return of the first verification result, the TEE is indicated to end, and at this time, the execution environment of the electronic device may be switched back to the re.

Alternatively, the encrypted first summary file may be generated and stored in the extended attribute when the system file is pre-deployed. Optionally, the specific generation process of the encrypted first summary file may include:

And step 1, abstracting file contents of the system file to generate a first abstract file.

In this step, the electronic device may complete the pre-deployment of the system file in the rich execution environment REE. In the deployment process of the system file, the electronic equipment can acquire the content of the system file and abstract the content of the system file to obtain a first abstract file. Alternatively, the first summary file may be saved as security. Ima. Alternatively, the electronic device may be completed in the REE by evmctl tools.

And step 2, the first abstract file is sent to a trusted execution environment, so that the electronic equipment encrypts and/or signs the first abstract file in the trusted execution environment after switching the execution environment to the trusted execution environment, and the electronic equipment switches back to the rich execution environment after sending the encrypted first abstract file to the rich execution environment.

In this step, when the electronic device obtains the first summary file, the electronic device may call an interface of the TEE to implement a process of sending the first summary file to the TEE. The electronic equipment can realize the function of switching the execution environment to the TEE when the interface of the TEE is called.

Optionally, the TEE has a first private key stored therein. The electronic device may use the first private key in the TEE to encrypt and/or sign the first digest file, to obtain an encrypted first digest file. The electronic device may send the encrypted first summary file to the REE as return information through the interface of the TEE. After the electronic equipment completes the transmission of the encrypted first summary file in the TEE, the electronic equipment completes the execution of the TEE and switches the execution environment back to the re.

And step 3, storing the encrypted first abstract file into the extension attribute.

In this step, the electronic device may store the encrypted first summary file in the extension attribute when the first summary file is obtained. Optionally, the extended attribute is a file extended security attribute of the system file in the electronic device.

S102, when the first verification result indicates that the encrypted first abstract file is not tampered, continuing to run or loading the system file.

In this embodiment, the electronic device may obtain the first verification result in the REE. When the first verification result is that verification is passed and the first summary file is indicated to be not tampered, the electronic device can continue to move or load the system file. When the system file is loaded, the application program corresponding to the system file is operated.

Optionally, the first verification result may further include the decrypted first digest file. The electronic device may generate a new first summary file from the current system file in the REE. The electronic device may compare the new first digest file to the decrypted first digest file. If the new first digest file and the decrypted first digest file match, it is indicated that the system file has not been tampered with. Otherwise, the system file is tampered.

Optionally, when the first verification result is verification failure, the first verification result is used for indicating that the first summary file is tampered. At this time, in order to secure the system, the electronic device needs to stop the operation or loading of the system file. The electronic device may also refuse to re-run or load the system file.

According to the system security management method provided by the application, the electronic equipment can acquire the encrypted first abstract file from the extended attribute in the process of running in REE or loading the system file. The electronic device may switch the execution environment to the TEE after sending the encrypted first summary file to the TEE under the execution environment of the REE. The electronic device may verify the encrypted first digest file at the TEE and generate a first verification result. When the first verification result is used for indicating that the encrypted first summary file is not tampered, the electronic device can continue to run or load the system file. Otherwise, when the first verification result is used for indicating that the encrypted first verification result is tampered, the electronic device may stop loading or running the system file. According to the application, by verifying the encrypted first abstract file, the accuracy of system integrity verification is improved on the basis of not increasing hardware cost, so that the effect of improving system safety is achieved.

Fig. 2 is a flowchart of a system security management method according to an embodiment of the present application. Based on the embodiment shown in fig. 1, as shown in fig. 2, an electronic device is taken as an execution subject, and in the electronic device, the integrity verification of a system file of the electronic device can be realized in the loading or running process of the system file of the electronic device through switching between a rich execution environment REE and a trusted execution environment TEE. Specifically, the system security management method of the present embodiment may include the following steps:

S201, acquiring an encrypted second abstract file from the extended attribute, and sending the second abstract file to the trusted execution environment, so that the electronic equipment verifies the encrypted second abstract file in the trusted execution environment after switching the execution environment to the trusted execution environment, and obtains a second verification result, and switches back to the rich execution environment after sending the second verification result to the rich execution environment. The second summary file is obtained by abstracting the encrypted first summary file and the security attribute.

In this embodiment, the electronic device may run the system file in the REEs. The electronic device may perform the system file integrity verification operation of the present embodiment when the system file is running. Specifically, when the system file starts to move, the electronic device may obtain the encrypted second summary file from the extended attribute of the system file. Alternatively, the second summary file may be security. Optionally, the second digest file may include a digest of the encrypted first digest file and the security attribute. The electronic device may send the encrypted second summary file to the TEE by invoking an interface of the TEE. Meanwhile, through the invocation of the TEE interface, the electronic device can switch the execution environment to the TEE.

A built-in private key may be stored within the TEE. The electronic device may verify the encrypted second digest file obtained by the TEE after switching the execution environment to the TEE. Alternatively, the verification process may be a process of decrypting and signing the encrypted second digest file using a built-in private key for the TEE. The electronic device may obtain a second verification result after the verification of the encrypted second digest file is completed. And when the second verification result is verification passing, the second verification result is used for indicating that the encrypted second abstract file is not tampered. Otherwise, when the second verification result is verification failure, the second verification result is used for indicating that the encrypted second summary file is tampered. The electronic device may return the second verification result to the tape REE by returning information using the TEE interface. When the TEE performs the return of the second verification result, the TEE is indicated to end, and at this time, the execution environment of the electronic device may be switched back to the re.

Alternatively, the encrypted second summary file may be generated and stored in the extended attribute when the system file is pre-deployed. Optionally, the specific generation process of the encrypted second summary file may include:

And step 1, abstracting the encrypted first abstract file and the security attribute to generate a second abstract file.

In this step, the electronic device may complete the pre-deployment of the system file in the rich execution environment REE. In the deployment process of the system file, the electronic device can abstract the encrypted first abstract file and the security attribute after acquiring the encrypted first abstract file to obtain a second abstract file. Alternatively, the second summary file may be saved as security. Alternatively, the security attribute may include a security.selinux or other file. Alternatively, the electronic device may be completed in the REE by evmctl tools.

Optionally, when dual verification of the encrypted security. Evm and the encrypted security. Ima in the embodiment needs to be performed, before the integrity verification of the system file is implemented, the electronic device needs to complete the generation of the first digest file, the storage of the encrypted first digest file, the generation of the second digest file, and the storage of the encrypted second digest file in a pre-deployment stage of the system file.

And step 2, sending the second abstract file to the trusted execution environment, so that the electronic equipment encrypts and/or signs the second abstract file in the trusted execution environment after switching the execution environment to the trusted execution environment, and switches back to the rich execution environment after sending the encrypted second abstract file to the rich execution environment.

In this step, the electronic device may call the interface of the TEE when obtaining the second summary file, so as to implement a process of sending the second summary file to the TEE. The electronic equipment can realize the function of switching the execution environment to the TEE when the interface of the TEE is called.

In one implementation, the TEE may have a first private key stored therein. The electronic device may use the first private key in the TEE to encrypt and/or sign the second digest file, to obtain an encrypted second digest file.

In another implementation, the TEE may have a second private key stored therein. The electronic device may use the second private key in the TEE to encrypt or sign the second digest file, to obtain an encrypted second digest file.

The electronic device may send the encrypted second summary file to the REE as return information through the interface of the TEE. After the electronic equipment completes the sending of the encrypted second summary file in the TEE, the electronic equipment completes the execution of the TEE and switches the execution environment back to the re.

Optionally, the private key used by the TEE of the electronic device to encrypt and/or sign the first and second digest files is the same.

And step 3, storing the encrypted second abstract file into the extension attribute.

In this step, the electronic device may store the encrypted second summary file in the extension attribute when the second summary file is obtained. Optionally, the extended attribute is a file extended security attribute of the system file in the electronic device.

S202, when the second verification result indicates that the encrypted second summary file is tampered, continuing operation or loading of the system file is forbidden.

In this embodiment, the electronic device may obtain the second verification result in the REE. And when the second verification result is verification failure, the second verification result is used for indicating that the second abstract file is tampered. At this time, in order to secure the system, the electronic device needs to stop the operation or loading of the system file. The electronic device may also refuse to re-run or load the system file.

Optionally, the second verification result may further include a decrypted second digest file. The electronic device may generate a new second digest file in the REE based on the security attributes of the current system file and the encrypted first digest file. The electronic device may compare the new second digest file to the decrypted second digest file. If the new second digest file and the decrypted second digest file match, it is indicated that the system file has not been tampered with. Otherwise, the system file is tampered.

Alternatively, the electronic device may continue to perform the following steps when the second verification result indicates that the encrypted second digest file has not been tampered with.

S203, acquiring the encrypted first abstract file from the extended attribute, and sending the first abstract file to the trusted execution environment, so that the electronic equipment verifies the encrypted first abstract file in the trusted execution environment after switching the execution environment to the trusted execution environment, and obtains a first verification result, and switches back to the rich execution environment after sending the first verification result to the rich execution environment. The first abstract file is obtained by abstracting the system file.

And S204, when the first verification result indicates that the encrypted first abstract file is not tampered, continuing to run or loading the system file.

Steps S203 and S204 are similar to the implementation of steps S101 and S102 in the embodiment of fig. 1, and are not described here again.

According to the system security management method provided by the application, the electronic equipment can firstly acquire the encrypted second abstract file from the extended attribute in the process of running in REE or loading the system file. The electronic device may switch the execution environment to the TEE, and verify the second summary file in the TEE, to generate a second verification result. When the second verification result indicates that the second summary file is not tampered, the electronic device may acquire the encrypted first summary file from the extension attribute. The electronic device may switch the execution environment to the TEE, and verify the first summary file in the TEE, to generate a first verification result. When the first verification result indicates that the first summary file is not tampered, the electronic device may continue to load or run the system file. Otherwise, when the first verification result or the second verification result is verification failure, the electronic device may stop loading or running the system file. In the application, through double verification of the encrypted first abstract file and the encrypted second abstract file, double verification of the security attribute and the file content of the system file is realized, and the accuracy of system integrity verification is improved on the basis of not increasing hardware cost, thereby improving the effect of system security.

On the basis of the above embodiment, as shown in fig. 3, the interaction process between the REEs and the TEEs is performed in the encryption process of the first digest file and the second digest file. Wherein a private key (PRIVATE KEY) required for IMA/EVM signing is stored within the TEE. The TEE may also include an encryption and decryption engine (ENCRYPT ENGINE). The REE can send the first digest file security. Ima and the second digest file security. Evm to the TEE, and an encryption and decryption engine in the TEE can sign the first digest file security. Ima and the second digest file security. Evm. After the encryption and decryption engine signs the first digest file security.ima and the second digest file security.evm by using a private key, the encrypted first digest file security.ima and the encrypted second digest file security.evm can be obtained. The encrypted first digest file security. Ima and the encrypted second digest file security. Evm may be returned to the REE. The encrypted first summary file security. Ima and the encrypted second summary file security. Evm are used for carrying out integrity measurement on the system file in the loading or running process of the system file. The process of collecting/storing is implemented for the TEE as follows, namely, the generation process of the encrypted first digest file security.

And step 1, the REE performs summary operation on the content of the system File (File) in a pre-deployment stage through a evmctl tool, and stores the summary operation as a first summary File security. Alternatively, the digest operation may be obtained by a hash algorithm preset in evmctl.

And 2, the REE sends the security. Ima to the TEE. And encrypting or signing (signature) the TEE by using a built-in private key and an encryption and decryption engine to obtain the encrypted security. The TEE may send the encrypted security. Ima to the REE.

And step 3, the REE saves the encrypted security. Ima as a measurement standard in the extension attribute of the system file. Optionally, the extended attribute is a file extended security attribute of the system file, that is, a security attribute of the system file.

And 4, the REE summarizes security attributes such as security. Ima, security. Selinux and the like, and stores the security attributes as a second summary file security. Evm. Alternatively, the digest operation may be obtained by a hash algorithm preset in evmctl.

And 5, the REE sends the security. Evm to the TEE. And encrypting or signing (signature) the TEE by using a built-in private key and an encryption and decryption engine to obtain the encrypted security. The TEE may send the encrypted security. Evm to the REE.

And 6, the REE saves the encrypted security.evm as a measurement standard in the extension attribute of the system file.

On the basis of the above embodiment, as shown in fig. 4, the integrity check of the system File (File) is performed during the running or loading process of the system File. The process may include the steps of:

And step 1, the REE firstly sends the encrypted second summary file security.evm to the TEE. And decrypting or checking the TEE by the built-in private key and the encryption and decryption engine. The TEE may send the second validation result to the REE.

And 2, the REE can judge whether the security.evm is tampered or not through the second verification result, so that whether the system file is safe or not is determined. If the encrypted security. Evm is tampered with, it indicates that there is an exception to the system file (illegal), and the system file is prohibited from running or being loaded. Otherwise, if the encrypted security. Evm is not tampered, the REE may proceed with the determination.

And step 3, the REE sends the encrypted first summary file security. Ima to the TEE. And decrypting or checking the TEE by the built-in private key and the encryption and decryption engine. The TEE may send the first validation result to the REE.

And 4, REE can judge whether the security. Ima is tampered or not by changing the first verification result, so as to determine whether the system file is safe or not. If the encrypted security. Ima is tampered with, this indicates that there is an exception to the system file (illegal), and the system file is prohibited from running or being loaded. Otherwise, if the encrypted security. Ima is not tampered with, the REE runs or loads (excute) the system file.

Fig. 5 is a schematic structural diagram of a system security management device according to an embodiment of the present application, as shown in fig. 5, a system security management device 10 according to the present embodiment is used to implement operations corresponding to electronic devices in any of the above method embodiments, where the system security management device 10 according to the present embodiment includes:

The verification module 11 is configured to obtain the encrypted first summary file from the extended attribute, and send the first summary file to the trusted execution environment, so that the electronic device performs verification on the encrypted first summary file in the trusted execution environment after switching the execution environment to the trusted execution environment, and obtains a first verification result, and switches back to the rich execution environment after sending the first verification result to the rich execution environment;

The processing module 12 is configured to continue running or load the system file when the first verification result indicates that the encrypted first summary file is not tampered;

the first abstract file is obtained by abstracting the system file.

Optionally, the processing module 12 is further configured to:

and when the first verification result indicates that the encrypted first summary file is tampered, prohibiting continuous operation or loading the system file.

Optionally, the verification module 11 is further configured to:

acquiring an encrypted second abstract file from the extended attribute, and transmitting the second abstract file to a trusted execution environment, so that the electronic equipment verifies the encrypted second abstract file in the trusted execution environment after switching the execution environment to the trusted execution environment, and obtains a second verification result, and switches back to the rich execution environment after transmitting the second verification result to the rich execution environment;

And when the second verification result indicates that the encrypted second summary file is tampered, prohibiting continuous operation or loading the system file.

The second summary file is obtained by abstracting the encrypted first summary file and the security attribute.

Optionally, the encrypted first digest file or the encrypted second digest file is generated and stored in the extended attribute when the system file is pre-deployed.

Optionally, the system security management apparatus 10 further includes:

the preprocessing module 13 is used for abstracting file contents of the system file to generate a first abstract file; the method comprises the steps that a first abstract file is sent to a trusted execution environment, so that the electronic equipment encrypts and/or signs the first abstract file in the trusted execution environment after switching the execution environment to the trusted execution environment, and the electronic equipment switches back to the rich execution environment after sending the encrypted first abstract file to the rich execution environment; and storing the encrypted first abstract file into the extension attribute.

Optionally, the preprocessing module 13 is further configured to:

abstracting the encrypted first abstract file and the security attribute to generate a second abstract file;

The second abstract file is sent to a trusted execution environment, so that the electronic equipment encrypts and/or signs the second abstract file in the trusted execution environment after switching the execution environment to the trusted execution environment, and the electronic equipment switches back to the rich execution environment after sending the encrypted second abstract file to the rich execution environment;

And storing the encrypted second abstract file into the extension attribute.

Optionally, at least one private key is stored in a trusted execution environment of the electronic device.

The system security management apparatus 10 provided in the embodiment of the present application may execute the above-mentioned method embodiment, and the specific implementation principle and technical effects thereof may be referred to the above-mentioned method embodiment, which is not described herein again.

Fig. 6 shows a schematic hardware structure of an electronic device according to an embodiment of the present application. As shown in fig. 6, the electronic device 20, configured to implement operations corresponding to the electronic device in any of the above method embodiments, the electronic device 20 of this embodiment may include: a memory 21 and a processor 22.

A memory 21 for storing a computer program. The Memory 21 may include a high-speed random access Memory (Random Access Memory, RAM), and may further include a Non-Volatile Memory (NVM), such as at least one magnetic disk Memory, and may also be a U-disk, a removable hard disk, a read-only Memory, a magnetic disk, or an optical disk.

A processor 22 for executing a computer program stored in the memory to implement the system security management method in the above embodiment. Reference may be made in particular to the relevant description of the embodiments of the method described above. The Processor 22 may be a central processing unit (Central Processing Unit, CPU), or may be other general purpose Processor, digital signal Processor (DIGITAL SIGNAL Processor, DSP), application SPECIFIC INTEGRATED Circuit (ASIC), or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in connection with the present invention may be embodied directly in a hardware processor for execution, or in a combination of hardware and software modules in a processor for execution.

Alternatively, the memory 21 may be separate or integrated with the processor 22.

When memory 21 is a separate device from processor 22, electronic device 20 may also include bus 23. The bus 23 is used to connect the memory 21 and the processor 22. The bus 23 may be an industry standard architecture (Industry Standard Architecture, ISA) bus, an external device interconnect (PERIPHERAL COMPONENT INTERCONNECT, PCI) bus, or an extended industry standard architecture (Extended Industry Standard Architecture, EISA) bus, among others. The buses may be divided into address buses, data buses, control buses, etc. For ease of illustration, the buses in the drawings of the present application are not limited to only one bus or to one type of bus.

The electronic device provided in this embodiment may be used to execute the system security management method described above, and its implementation manner and technical effects are similar, which is not described herein.

The present application also provides a computer-readable storage medium having a computer program stored therein, which when executed by a processor is adapted to carry out the methods provided by the various embodiments described above.

The computer readable storage medium may be a computer storage medium or a communication medium. Communication media includes any medium that facilitates transfer of a computer program from one place to another. Computer storage media can be any available media that can be accessed by a general purpose or special purpose computer. For example, a computer-readable storage medium is coupled to the processor such that the processor can read information from, and write information to, the computer-readable storage medium. In the alternative, the computer-readable storage medium may be integral to the processor. The processor and the computer readable storage medium may reside in an Application SPECIFIC INTEGRATED Circuits (ASIC). In addition, the ASIC may reside in a user device. The processor and the computer-readable storage medium may also reside as discrete components in a communication device.

In particular, the computer readable storage medium may be implemented by any type or combination of volatile or non-volatile Memory devices, such as Static Random-Access Memory (SRAM), electrically erasable programmable Read-Only Memory (EEPROM), erasable programmable Read-Only Memory (Erasable Programmable Read Only Memory, EPROM), programmable Read-Only Memory (Programmable Read-Only Memory, PROM), read-Only Memory (ROM), magnetic Memory, flash Memory, magnetic or optical disk. A storage media may be any available media that can be accessed by a general purpose or special purpose computer.

The present application also provides a computer program product comprising a computer program stored in a computer readable storage medium. The computer program may be read from a computer-readable storage medium by at least one processor of the apparatus, and executed by the at least one processor, causes the apparatus to implement the methods provided by the various embodiments described above.

In the several embodiments provided by the present application, it should be understood that the disclosed apparatus and method may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of modules is merely a logical function division, and there may be additional divisions of actual implementation, e.g., multiple modules may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or modules, which may be in electrical, mechanical, or other forms.

Wherein the individual modules may be physically separated, e.g. mounted in different locations of one device, or mounted on different devices, or distributed over a plurality of network elements, or distributed over a plurality of processors. The modules may also be integrated together, e.g. mounted in the same device, or integrated in a set of codes. The modules may exist in hardware, or may also exist in software, or may also be implemented in software plus hardware. The application can select part or all of the modules according to actual needs to realize the purpose of the scheme of the embodiment.

When the individual modules are implemented as software functional modules, the integrated modules may be stored in a computer readable storage medium. The software functional modules described above are stored in a storage medium and include instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) or processor to perform some of the steps of the methods of the various embodiments of the application.

It should be understood that, although the steps in the flowcharts in the above embodiments are sequentially shown as indicated by arrows, these steps are not necessarily sequentially performed in the order indicated by the arrows. The steps are not strictly limited in order and may be performed in other orders, unless explicitly stated herein. Moreover, at least some of the steps in the figures may include multiple sub-steps or stages that are not necessarily performed at the same time, but may be performed at different times, the order of their execution not necessarily occurring in sequence, but may be performed alternately or alternately with other steps or at least a portion of the other steps or stages.

Other embodiments of the application will be apparent to those skilled in the art from consideration of the specification and practice of the application disclosed herein. This application is intended to cover any variations, uses, or adaptations of the application following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the application pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the application being indicated by the following claims.

It is to be understood that the application is not limited to the precise arrangements and instrumentalities shown in the drawings, which have been described above, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the application is limited only by the appended claims.

Claims (10)

1. A system security management method, applied to a rich execution environment of an electronic device, where the rich execution environment and a trusted execution environment are deployed, the method comprising:

Acquiring an encrypted first abstract file from an extended attribute, and transmitting the first abstract file to a trusted execution environment, so that the electronic equipment performs verification on the encrypted first abstract file in the trusted execution environment after switching the execution environment to the trusted execution environment, and obtains a first verification result, and switches back to the rich execution environment after transmitting the first verification result to the rich execution environment;

When the first verification result indicates that the encrypted first abstract file is not tampered, continuing to run or loading a system file;

the first abstract file is obtained by abstracting a system file.

2. The method according to claim 1, characterized in that the method further comprises:

And when the first verification result indicates that the encrypted first digest file is tampered, prohibiting continuous operation or loading the system file.

3. The method of claim 2, wherein prior to obtaining the encrypted first summary file from the extended attribute, the method further comprises:

Acquiring an encrypted second abstract file from the extended attribute, and transmitting the second abstract file to a trusted execution environment, so that the electronic equipment performs verification on the encrypted second abstract file in the trusted execution environment after switching the execution environment to the trusted execution environment, and obtains a second verification result, and switches back to the rich execution environment after transmitting the second verification result to the rich execution environment;

when the second verification result indicates that the encrypted second summary file is tampered, prohibiting continuous operation or loading the system file;

The second summary file is obtained by abstracting the encrypted first summary file and the security attribute.

4. A method according to any of claims 1-3, wherein the encrypted first digest file or the encrypted second digest file is generated and stored into the extension attribute at a pre-deployment of the system file.

5. A method according to any of claims 1-3, wherein before obtaining the encrypted first summary file from the extended attributes, the method further comprises:

Abstracting file contents of the system file to generate a first abstract file;

The first summary file is sent to the trusted execution environment, so that the electronic equipment encrypts and/or signs the first summary file in the trusted execution environment after switching the execution environment to the trusted execution environment, and the electronic equipment switches back to the rich execution environment after sending the encrypted first summary file to the rich execution environment;

And storing the encrypted first abstract file into the extension attribute.

6. A method according to any of claims 1-3, wherein before obtaining the encrypted second summary file from the extended attributes, the method further comprises:

Summarizing the encrypted first summary file and the security attribute to generate a second summary file;

sending the second summary file to the trusted execution environment, so that the electronic device encrypts and/or signs the second summary file in the trusted execution environment after switching the execution environment to the trusted execution environment, and switches back to the rich execution environment after sending the encrypted second summary file to the rich execution environment;

and storing the encrypted second abstract file into the extension attribute.

7. A method according to any of claims 1-3, characterized in that at least one private key is stored in the trusted execution environment of the electronic device.

8. An electronic device, comprising: a processor, and a memory communicatively coupled to the processor;

The memory stores a computer program;

The processor executes the computer program stored in the memory to implement the method of any one of claims 1-7.

9. A computer readable storage medium, characterized in that the computer readable storage medium has stored therein a computer program for implementing the method according to any of claims 1-7 when being executed by a processor.

10. A computer program product comprising a computer program which, when executed by a processor, implements the method of any of claims 1-7.