WO2019072158A1

WO2019072158A1 - Security control method and computer system

Info

Publication number: WO2019072158A1
Application number: PCT/CN2018/109416
Authority: WO
Inventors: 陈海波; 王楠; 陈善席; 谢淼
Original assignee: 华为技术有限公司
Priority date: 2017-10-13
Filing date: 2018-10-09
Publication date: 2019-04-18
Also published as: EP3674954B1; KR102347562B1; US20200250302A1; CN109670312A; EP3674954A4; KR20200052957A; EP3674954A1; US11687645B2

Abstract

Provided are a security control method and a computer system. A first domain and a second domain are deployed on the computer system, the security of the second domain is higher than that of the first domain, a program is deployed in the first domain, and a control flow management module and an auditing module are deployed in the second domain. The security of the second domain is higher than that of the first domain. The control flow management module acquires control flow information by means of a tracker during the execution of a program located in the first domain; the auditing module performs, according to auditing rules, auditing on information to be audited, determines that the auditing is passed when the information, to be audited, matches the auditing rules, and then allows the first domain to execute a subsequent operation, such as accessing a security program of the second domain. Data flows of the program may also be audited while the control flow information is audited. The method can prevent the execution of some key programs from being ignored, improving the security of the computer system.

Description

Safety control method and computer system

Technical field

The present application relates to a security control technology for a computer system, and more particularly to a method, device, and system for implementing system security by auditing control flow and the like.

Background technique

There is an increasing demand for terminal devices to handle important services. From the ability to pay, download and watch the latest Hollywood blockbusters for a specific time period, to the ability to remotely pay bills and manage bank accounts via mobile phones, these trends have made end devices a key target for viruses such as malware, trojans and rootkits. In order to ensure the security of the terminal device, a terminal device security framework represented by TrustZone has appeared.

In the existing TrustZone framework, system-level security is achieved by dividing the hardware and software resources of system on chips (SoC) into two worlds, namely the normal world and the secure world. (Also called security domain and non-security domain), the two worlds correspond to the rich execution environment (REE) and the trusted execution environment (TEE). TEE and REE run on the same device. TEE ensures the storage, processing and protection of sensitive data in a trusted environment and provides a secure execution environment for authorized trusted applications (TAs). The client application (CA) (also known as the normal application) runs on the REE. The CA accesses the TA by calling the TEE client application programming interface (API) located in the REE, thereby providing the TEE and the TA. Security features.

In the prior art, in order to ensure the security of the CA accessing the TA, an authentication procedure of the CA is set on the REE side, and the authentication program is used to extract the identity information of the CA, so as to subsequently verify the identity of the CA. Specifically, before the CA accesses the TA, the REE side extracts the identity information of the CA by executing the authentication procedure, and then submits it to the TEE side through a secure mode call (SMC), and allows the CA to access the TEE side after the verification is passed. The TA you want to access. However, on the REE side, the operating system (OS) running by the CA may be compromised, causing the authentication procedure to be bypassed, that is, not executed. For example, to

Various CAs are deployed on the OS on the REE side of the representative, and

There is a CA authentication program deployed in it.

There is a superuser privilege, root privilege. when

After being super-lifted (ie, rooted), the original rights management is no longer valid. That is, after being rooted

It is possible for a CA to bypass the authentication procedure under certain attack conditions. If the authentication procedure is bypassed, the CA's identity information extraction process is gone. In this way, the counterfeit CA can directly submit the forged identity information to the TEE side. After the TEE side verifies the authentication, the counterfeit CA can invoke the security functions provided by the TA, such as the fingerprint verification function, thereby causing a series of system security problems. .

Summary of the invention

The present application provides a computer system, a terminal device, and a security control method and the like applied thereto for improving the security of a terminal device or other type of computer system.

In order to facilitate the understanding of the technical solutions proposed in the present application, several elements which will be introduced in the description of the present application are first introduced herein.

Domain: A logical organizational unit of a computer system, specifically a logical organizational unit within a computer device. Each domain has its own security policy, and there are security boundaries between different domains. The domain of the computer system may be divided by software, for example

The user mode and kernel mode of the system, for example, a host layer and a guest layer formed by using virtualization technology; or may be divided by hardware, for example, a TrustZone-based security domain and a non-security domain.

Tracker: Also called tracer in this application, it is used to record transfer instructions (such as jump instructions) and data transfer instructions issued on the CPU (for example

In the load command and store instruction), these instructions can be used as control flow information to reconstruct the control flow and to obtain dynamic data. E.g

CoreSight under the architecture, IPT under the X86 architecture (

Processor Tracer), or other unit or module that can implement CPU instruction tracking. The tracker can exist as a single device, or it can be partially or fully embedded in the CPU or other hardware.

Control flow (also called execution flow): Indicates the execution process of the program. The control flow can be expressed directly or indirectly as an instruction address sequence or a sequence of events. For example, the code x=y, converted to assembly language is 0x1234:load r0,[y];0x1238:store r0,[x]. Here, the value of y stored in the memory flows to the register of the CPU, and then flows to the memory of x. The control flow of the code is executed first 0x1234, and then executes 0x1238, and the value of y belongs to the dynamic data during the execution of the code. .

Control flow information: used to indicate that information can be reconstructed from the control flow. In some descriptions, one of the plurality of pieces of control flow information forming a control flow of a program, in another description, all information forming a control flow of a program, and in other descriptions may also be used to refer to the control flow itself, specifically See the description context.

Data stream: indicates the data read and write process of the program, including the data in the process. A sequence of data read and write events that can be expressed directly or indirectly as a program. Some embodiments of the present application ensure the security of the system by auditing the data contained in the sequence of read and write events, which is typically dynamic data.

Data stream information: used to represent information that can be reconstructed, including dynamic data. In some descriptions, one of a plurality of dynamic data forming a data stream of a program, in another description, all dynamic data forming a data stream of a program, and in other descriptions may also be used to refer to the data stream itself, See the description context.

Automaton: A computer-implemented mathematical model. An automaton can transition from one state to another in response to an external input, such as an event. The automaton instance is a runtime automaton. In the embodiments provided by the present application, the rules or models are used to audit information such as control flows, and the automaton is an implementation form of "rules or models."

"Executing an action in the first domain or the second domain" may be understood to mean that the subject performing the action is deployed in the first domain or the second domain, or may be understood to be executing the subject in the first domain or The state represented by the second domain, the body performing the action may be a hardware module or a software module; or because the "domain" is a logical organization unit, in some cases, the execution subject of the action may be the first domain or Second domain.

“Multiple” or “multiple times” appearing in the present application means “two or more” or “two or more times” unless otherwise specified. The terms "first" and "second" appearing in this application do not have a meaning of order, only to distinguish two subjects in some description contexts for convenience of understanding, but the subject matter indicated is not in all embodiments. Both must be different subjects. "A/B", "A and/or B" appearing in the present application include A, B, and A and B. In this application

Means A is a trademark name, but does not bring

The words may also be trademark names.

Next, the technical solutions provided by the present application will be introduced in different aspects. It should be understood that the following aspects do not necessarily cover all implementations of the present application, and that implementations and benefits of the various aspects may be referred to each other.

In a first aspect, the application provides a computer system, which may be a terminal device, where the first device and the second domain are deployed on the terminal device, a program is deployed in the first domain, and a control is deployed in the second domain. Flow management module and audit module. A tracker is further disposed on the terminal device, and implements integrity auditing of the control flow of the program together with the control flow module and the audit module. Specifically, the control flow management module is configured to acquire information to be audited by a hardware tracker when the program located in the first domain is executed, where the information to be audited includes control flow information of the program; The auditing module is configured to perform an audit on the information to be audited according to an auditing rule, and determine that the auditing is passed when the information to be audited matches the auditing rule. The domain responsible for auditing is typically higher than (or equal to) the domain in which the audited program is running. The first domain and the second domain may be partitioned by software and/or hardware.

In some implementations, the first domain and the second domain are respectively a TrustZone-based non-secure world and a security world (also understood to be REE and TEE).

It can be seen that the tracking flow, such as CoreSight or IPT, is used to obtain control flow information of a key program (referred to as a program to be protected in the following specific embodiment), and the program is in another domain according to a preset audit rule. The control flow performs an integrity audit, and the next operation is allowed when the control flow matches the audit rule, for example, allowing the program or other programs related to the program to access the function of the domain of the audit module, thereby avoiding Some kind of attack means that the critical program is bypassed by system execution or illegal execution, which leads to system vulnerabilities and improves the security of the terminal device.

It should be noted that the control flow integrity audit may also be referred to as control flow integrity verification, and is referred to as control flow auditing in this application.

In some implementations, the program can be stored in a read-only memory area of the memory deployed in the first domain, avoiding being modified, further ensuring security.

In some implementations, the information to be audited further includes data flow information of the program. While performing control flow auditing, the data flow information of the program is also audited, and the security of the code execution process is ensured, and the security of the data in the code is also ensured, thereby further improving the security of the terminal device.

In some implementations, the terminal device further includes a Tracer audit module deployed in the second domain. The Tracer audit module is configured to perform an audit of the tracker before the audit module performs an audit. Specifically, whether the register of the audit trailer has been modified, if it is modified, the audit fails, and vice versa. After the audit is passed, the audit module is triggered to perform the audit. Review the tracker before the tracker performs a security audit to ensure that the tracker has not been tampered with to ensure the reliability of the audit process.

In some implementations, the terminal device further includes a process identity acquisition module deployed in the first domain. The process identifier obtaining module is configured to acquire a process identifier (eg, a PID or a process name) of a process executing the program before the tracker collects the control flow information, and store the process identifier in the tracker In the first register. The control flow management module is specifically configured to acquire the to-be-audited information by using the tracker, where the to-be-audited information further includes the process identifier, where the process identifier is the tracker from the first The process ID read in the register. The auditing module is specifically configured to search for an auditing rule that matches the process identifier according to the process identifier, and perform an audit on the control flow information according to the found auditing rule.

Before triggering the collection of each control flow information, the process identifier of the current process is obtained, and then the control flow information of the program executed by the current process is triggered, and then the control flow information is associated with the process identifier. Equivalent to each control flow information has a process identifier to identify its own source, so that the audit module can distinguish control flow information from different programs according to the process identification, and select the matching audit rules for auditing, thereby implementing multiple programs. Parallel auditing.

In some implementations, the terminal device further includes a first random number generator and a self-acquisition module deployed in the first domain, and the second domain includes a TEXT segment of the program. The TEXT segment here can be placed into the second domain by hard coding. The self-acquisition module is configured to call the first random number generator to generate a random number RX before the program is executed, and store the random number RX in a second register of the tracker; The random number RX and the TEXT segment of the process executing the program are calculated to obtain a hash value H1. The control flow management module is specifically configured to acquire the to-be-audited information by using the tracker, where the information to be audited further includes the random number RX, wherein the RX accesses the second by the tracker Register is obtained. The auditing module is specifically configured to acquire the hash value H1, calculate a hash value H2 according to the random number RX and the TEXT segment included in the second domain, and compare the H1 and H2. When H1 and H2 are the same and other information to be audited matches the audit rule, the audit is determined to pass.

In other implementations, the TEXT segment can be scrambled in other forms than random numbers.

In other implementations, the random number RX may also not be generated, the hash value H1 is not calculated, only the TEXT segment is transmitted, and then compared with the TEXT segment contained in the second domain.

The "TEXT segment" points to a section of storage area. The code and constants of the program are included in the TEXT section of a program. The "TEXT segment" in the right means the sum of all or part of the content contained in the TEXT segment, the content of the compressed TEXT segment, or the content contained in the TEXT segment.

It should be understood that the name "TEXT" is usually

or

Used in other systems, the storage area containing program code and constants may be called other names. It should be understood that in the present application, the "TEXT" segment means a storage area having the same meaning in all types of systems.

The TEXT section contains the code and constants of the program, the content of the TEXT section is first placed in the second domain, and then the TEXT section is acquired again during the running of the program, and transmitted to the second domain, and the TEXT segments obtained twice are compared. After passing, the audit is confirmed, which will further ensure the security of the program. Further, by random number scrambling in the process of TEXT segment transmission, the security of the TEXT segment transmission can be improved, thereby ensuring the reliability of the audit.

In some implementations, the terminal device further includes a first random number generator deployed in the first domain and a second random number generator deployed in the second domain. The first random number generator herein may be a random number generator in the foregoing implementation, or may be another random number generator. The information to be audited obtained by the control flow management module further includes a random number. The first random number generator is invoked when the program is executed to generate the random number, the random number is written into a third register of the tracker, and then the tracker is acquiring the control When the information is streamed, the third register is accessed to obtain a random number currently stored in the register, and is used together with the current control flow information as a piece of information to be audited. The auditing module is specifically configured to acquire a last random number RY generated by the first random number generator during execution of the program, and acquire a number n of random numbers generated in the second domain; The n triggering the second random number generator generates n random numbers, and compares the nth random number Rn with the RY, when the Rn is the same as the RY and other to-be-audited information matches the audit The rules are determined when the audit is passed.

In other words, the first random number generator (in the first domain) generates a plurality of random numbers when the program is executed, each random number is written to the register of the tracker after generation, and then the tracker collects the control stream When the information is read, the random number is read from the register and passed along with the control flow information to the second domain. The auditing module of the second domain may determine the random number RX generated by the first random number generator from the random number passed in a plurality of manners, and then acquire the random number generator occurrence number n corresponding to the random number RX. , this n is preset in the second domain according to the normal execution of the program. The audit module then calls the second random number generator to generate n random numbers and selects the nth random number. If the random numbers obtained by the two methods are the same, the execution of the program in the first domain is not interfered.

The "audit rules" appearing in this application can be understood differently in different implementation modes. For example, when only the control flow information is included in the information to be audited, the audit rule can be understood as a rule containing only the audit control flow, and when the audit is to be audited When other information appears in the information, such as data flow information, process identification, random number, TEXT segment, etc., the audit rule can be understood as a rule that also matches the process identification, and/or rules for reviewing random numbers, TEXT, and the like. In some other implementations, an "audit rule" can also be understood to include only control flow audit rules, and other information matching or auditing belongs to another model or rule. The "audit rules" can be implemented in a variety of ways, such as an automaton, an audit model, or a table, a list, a judgment statement, and so on. Complex audit rules can be implemented in a machine learning manner. For example, the program can be simulated running on the terminal device or the server side, and then learning to obtain an execution feature (or a model) of the program, and then determining the actual situation by matching information such as the actual execution flow of the program with the execution feature. Whether the execution process is legal.

In some implementations, all or part of the components of the tracker are placed in the second domain by way of hardware partitioning or software rights management, and the second domain is more secure than the first domain. In this way, the security of the tracker can be ensured. In the foregoing implementation manner, the review of the tracker is not necessary, and of course, the audit can still be performed, and the dual mechanism is used to ensure the security of the tracker.

In some implementations, a trigger instruction is inserted at multiple locations of the program for triggering the tracker to collect control flow information for a particular location; in other implementations, the tracker may not require triggering of the triggering command, but rather All control flow information of the program.

In a second aspect, the present application also provides an auditing method, which is applied to a computer system in which a first domain and a second domain are deployed. When the program located in the first domain is executed, the information to be audited is acquired by the tracker in the second domain, and the information to be audited includes control flow information of the program. The information to be audited is audited according to the auditing rule in the second domain, and the auditing is determined when the information to be audited matches the auditing rule. The tracker may be deployed in whole or in part in the second domain.

After the audit method is applied to the security control, when the audit pass allows the next operation to be performed, for example, the program or the next program associated with the program is allowed to perform access to a certain security program of the second domain.

In some implementations, the tracker is turned on when the program starts executing, and then the information to be audited collected by the tracker is acquired synchronously or asynchronously in the second domain; in other implementations, the program is executed. The tracker is turned on when there is a certain key code in the middle, or the tracker can be turned on after the system is started.

In some implementations, the information to be audited further includes data flow information of the program.

In some implementations, the tracker is audited in the second domain before the control flow information is audited, and the control flow information is audited after the audit is passed.

In some implementations, before obtaining the information to be audited by the tracker, acquiring a process identifier of the process executing the program, and storing the process identifier in a first register of the tracker; Acquiring the information to be audited collected by the tracker, where the information to be audited includes the control flow information and the process identifier in the first register when the control flow information is collected. In other words, the process identifies the current process identification read from the first register when the tracker acquires the control flow information. Then, the audit rule matching the process identifier is searched according to the process identifier, and the control flow information is audited according to the found audit rule.

In some implementations, the computer system further includes a first random number generator deployed in the first domain, the second domain including a TEXT segment of the program. Calling the first random number generator in the first domain to generate a random number RX, and storing the random number RX in a second register of the tracker, and according to the program being executed The random number RX and the TEXT segment of the process executing the program are calculated to obtain a hash value H1. Acquiring the information to be audited collected by the tracker, where the information to be audited includes the control flow information and the random number RX, wherein the RX is obtained by the tracker accessing the second register. Obtaining the hash value H1 in the second domain, calculating a hash value H2 according to the random number RX and the TEXT segment included in the second domain, and comparing the H1 and H2, When H1 and H2 are the same and other information to be audited matches the audit rule, the audit is determined to pass. In some implementations, the computer system further includes a first random number generator deployed in the first domain and a second random number generator deployed in the second domain. When the program is executed, the first random number generator is called in the first domain to generate a random number, and the random number is written to a third register of the tracker. The information to be audited is obtained by the tracker, where the information to be audited includes control flow information and a random number in the third register when the control flow information is collected. Obtaining, in the second domain, a last random number RY generated by the first random number generator during execution of the program, and acquiring a random number of occurrences n. preset in the second domain. And then triggering the second random number generator according to the n to generate n random numbers, and comparing the nth random number Rn with the RY, when the Rn is the same as the RY and other information to be audited matches The audit rule determines that the audit is passed.

It should be understood that, in the above implementation manner that requires a random number, it is not limited to include a random number in each piece of information to be audited.

In a third aspect, the present application further provides a computer readable storage medium comprising computer readable instructions for implementing any one of the foregoing methods when the computer readable instructions are executed by one or more processors .

In a fourth aspect, the present application further provides a computer program product comprising computer readable instructions for implementing any one of the foregoing methods when the computer readable instructions are executed by one or more processors .

In a fifth aspect, the present application further provides a computer system, the hardware layer of which includes a tracker, a processor, and a memory. The computer system can be logically divided into a first domain and a second domain. The processor is configured to read computer readable instructions in the memory and execute the computer readable instructions to effect initiation of the tracker and to execute a program located in the first domain. And the hardware tracker is configured to collect information to be audited related to the program when the program is executed. Further, the security of the second domain may be higher than (or equal to) the first domain.

The action of the tracker to collect the information to be audited is triggered in some implementations by the processor when the program is executed, for example, the trigger instruction is inserted in the program; in other implementations It is triggered by the processor in other situations, or it may be executed autonomously after the tracker is started.

DRAWINGS

In order to more clearly illustrate the technical solutions provided by the present application, the drawings will be briefly described below. Obviously, the drawings described below are only some embodiments of the present application.

FIG. 1 is a schematic structural diagram of a computer system according to an embodiment of the present disclosure;

FIG. 2 is a schematic structural diagram of a terminal device according to an embodiment of the present disclosure;

3 is a schematic flow chart of a security control method based on FIG. 2;

FIG. 4 is a schematic structural diagram of a terminal device according to an embodiment of the present disclosure;

5 is a schematic flow chart of a security control method based on FIG. 4;

FIG. 6 is a schematic structural diagram of a terminal device according to an embodiment of the present disclosure;

7 is a schematic flow chart of an audit method based on FIG. 6;

FIG. 8 is a schematic structural diagram of a terminal device according to an embodiment of the present disclosure;

9 is a schematic diagram of collecting information based on the tracker of FIG. 8;

10 is a schematic flow chart of an audit method based on FIG. 8 and FIG. 9;

FIG. 11 is a schematic structural diagram of a terminal device according to an embodiment of the present disclosure;

12 is a schematic diagram of collecting information based on the tracker of FIG. 11;

13 is a schematic flow chart of an audit method based on FIG. 11 and FIG. 12;

FIG. 14 is a schematic structural diagram of a terminal device according to an embodiment of the present disclosure;

FIG. 15 is a schematic structural diagram of a terminal device according to an embodiment of the present disclosure;

FIG. 16 is a schematic structural diagram of a terminal device according to an embodiment of the present disclosure;

17 is a schematic flow chart of an audit method based on FIG. 16;

FIG. 18 is a schematic diagram of a server and a network there according to the embodiment; FIG.

FIG. 19 is a schematic diagram of a server and a network there according to the embodiment; FIG.

FIG. 20 is a schematic diagram of a logical structure of a terminal device according to an embodiment of the present disclosure.

Detailed ways

Embodiment 1

Please refer to FIG. 1 , which is a schematic structural diagram of a computer system according to an embodiment of the present disclosure. The computer system includes a hardware layer including a processor 150, a memory 160, and a tracker 170. The computer system may specifically be a terminal device, and a fixed terminal or a mobile terminal may be used. The fixed terminal is, for example, a personal computer, a point of sale (POS), or an automatic teller machine; the mobile terminal is, for example, a smart phone, a laptop computer, a digital broadcast terminal, a personal digital assistant, a portable multimedia player, or a car. A navigation system or the like has a mobile computer. . It should be understood that the method provided by any embodiment of the present application may be applied to other types of computer systems, such as servers, in addition to the type of terminal device.

Processor 150 can be a single core or multi-core processor. Multiple types of processors can also be included in the computer system. The memory 160 may include one or more of the following types: flash memory, hard disk type memory, micro multimedia card type memory, card memory (such as SD or XD memory), random access memory (random access memory) , RAM), static random access memory (SRAM), read only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable Read-only memory (PROM), magnetic memory, magnetic disk or optical disk.

In other embodiments, the memory 160 may also include a network storage device on the Internet that may perform operations such as updating or reading on the memory 160 on the Internet.

From a software perspective, the computer system is divided into two domains: a first domain and a second domain, which are run by the same processor but run in different states of the processor. The two domains respectively have first and second operating systems, and the first and second operating systems respectively run a plurality of first applications and a plurality of second applications.

It should be noted that the types of the first operating system and the second operating system may be the same or different, or may be two different states of the same operating system, such as a user state and a kernel state, that is, the first domain and the first domain. The two domains are respectively the two states of the same operating system.

The program 110 to be protected is set in the first operating system, and the program to be protected collects control flow information and the like related to the running of the program through the tracker 170 during operation, and then the Tracer management module 130 can obtain the information. The program 110 to be protected may be part of the first application.

The "program to be protected" is any program that needs to be protected. The program must be executed according to the original execution flow and cannot be tampered with or bypassed. The program to be protected may be located anywhere in the system, may be located on the REE side of the embodiment described below, or may be located on the TEE side. For example, the program to be protected may be, for example,

The kernel module (the module with the suffix KO), the CA authentication module, and so on.

The acquisition of information such as feature information may be accomplished by inserting one or more triggering instructions for triggering the acquisition of information at one or more locations of the function code to generate the program 110 to be protected. When the program 110 to be protected runs to these trigger commands, the trigger tracker 170 collects relevant information of the program 110 to be protected. This information (hereinafter referred to as information to be audited) may include one or more of the following information: control flow information related to code execution for control flow auditing, dynamics in code execution process for data auditing Data, a random number for securing information transmission, and a process identification (PID) for identifying a program to be protected in a parallel audit.

Non-read-only data that is manipulated during code execution is dynamic data, and read-only data is static data. For example, in the example of the description of the control flow in the Summary of the Invention section, the value of y belongs to the dynamic data. As another example, the TEXT section contains code and data, which are usually static data. Dynamic data can be obtained by the tracker tracking load instruction and store instruction. For example, the code x=y corresponds to a load instruction and a store instruction. The load instruction reads the value of y from the memory of y into the register, and the store instruction registers the register. The value in the memory is written to the memory of x. The read and write of the memory data generally has to pass the load instruction and the store instruction, so tracking the two instructions can obtain dynamic data.

The generation of the program 110 to be protected may be on another computer system other than the computer system. The content of the trigger command and the specific insertion position can be determined by the developer, or can be automatically generated by the computer by inputting a specific rule into the computer. The trigger instruction can be manually inserted into the program to be protected by the developer during development, or it can be automatically inserted by the computer.

It should be noted that there are various implementations of the Tracer management module 130. In addition to acquiring (or managing) the information collected by the tracker 170, the tracker 170 itself can be managed, for example, opened and initialized during the startup phase of the computer system. Tracker 170, and in some cases, audits such operations as Tracer. In addition, program entry and startup operations may differ for different types of programs.

The audit triggering module 120 is configured to send trigger information to the auditing module 140 set in the second operating system to trigger the auditing module 140 to start performing the auditing operation of the program 110. Specifically, the audit trigger module 120 compares the audit rule 11 with the control flow acquired by the Tracer management module 130, and if the control flow complies with the audit rule 11, continues the subsequent functional operations. If the control flow does not comply with the audit rules, then there is a problem with the execution of the program 110, terminating the current operation and/or returning an error message to the first operating system. The audit trigger module 120 may also be part of the program 110 to be protected.

The audit rule 11 is stored in the memory 160. There may be many types of audit rules 11 . Automata is a specific implementation of audit rules.

It should be noted that when trigger information is sent from one domain to another, switching between two domains is generally involved. The method and the process of the two domain switching are related to the system applied in this application, which is not limited in this embodiment.

It can be seen that, by using the method provided in this embodiment, a control flow audit can be performed on the execution process of the code to be protected in another domain in one domain to ensure the normal execution of the code, and the code is effectively avoided after the domain is privileged to be promoted. To avoid the possible security vulnerabilities. Here, a domain is elevated by privilege means that the higher or highest privilege of the domain is obtained.

Further, if the tracker (or the Tracer management module 130) obtains other information to be audited except the control flow information, the auditing module 140 may process the information together to further enhance the applicability or security of the application. Sex.

Embodiment 2

The following combines the TrustZone technology framework with

The operating system is exemplarily introduced to the control flow auditing method provided by the present application and embodiments of various other methods.

Please refer to FIG. 2 , which is a schematic structural diagram of a device of a terminal device according to the embodiment. The terminal device includes a hardware layer including a processor 250, a memory 260, and a CoreSight 270. CoreSight 270 is a typical hardware tracker. The CoreSight 270 is in an open state during the entire period or part of the operation of the terminal device 200.

The memory 260 includes a read only memory area 260-1 and other memory areas 260-2 that are set to be read only. Of course, the memory 260 may also include other types of storage media. For reference, the foregoing embodiments are not described herein.

The terminal device 200 includes two domains: a rich execution environment (REE) and a trusted execution environment (TEE). These two domains are running separately

Operating system and a TEE side operating system (such as the open source OP-TEE operating system).

The operating system and TEE OS are further divided into user state and kernel state.

The client application (CA) is set in the user mode on the REE side. Before accessing the trusted application (TA) on the TEE side, the CA needs to invoke a kernel-based authentication program 210. This code is the program to be protected in the foregoing embodiment. 110. In other embodiments, the code can also be understood as part of the code of the CA, so the CA is also an object that can be protected and monitored by the present application.

The authentication procedure 210 is part of the REE and TEE pre-communication handshake procedure. This handshake procedure is divided into two parts: 1. REE proposes a handshake; 2. TEE handles the handshake request and decides whether the handshake is successful. The authentication procedure 210 implements the first part, ie, the REE proposes a handshake. The functions of the authentication program 210 mainly include: 1. collecting CA identity information; 2. constructing a handshake request; 3. verifying the identity information and the handshake request, generating a checksum; 4. placing the CA identity information, handshake request, and school Check and send to TEE. In the existing architecture, TEE rejects requests that have not been sent through the handshake process.

The handshake is made up of a series of function codes and the data they need to process. Security attack behavior can find vulnerabilities in the execution order of functions, corresponding data, or function execution order and data combination, thereby destroying the integrity of the execution of this code and causing subsequent security vulnerabilities. For example, a fake CA can bypass the process of collecting identity information, send fake identity information that is not its own, and impersonate the identity of a legitimate CA.

The authentication procedure 210 in this embodiment is no longer a prior art authentication procedure, and multiple locations of the authentication procedure 210 are inserted into multiple CoreSight triggering instructions. Trigger instructions are used to trigger information about the CoreSight270 acquisition code execution. Specifically, the CoreSight trigger instruction can be a program whose functions are: 1. Configure the data transfer register of the CoreSight 270; 2. Enable the CoreSight 270 to start collecting the information to be audited. The plurality of locations of the authentication procedure 210 can be understood as "collection points" that trigger the collection of information.

The SMC calling module 220 is also configured in the kernel state of the REE. The module is mainly used to send a trigger message for triggering the audit to the auditing module 240. In this embodiment, the SMC calling module 220 is implemented as part of the authentication program 210, that is, the authentication program 210 itself sends a trigger message triggering the audit. In other embodiments, the SMC calling module 220 and the program to be protected may also be independent.

Taking fingerprint verification as an example, FIG. 3 shows a process of controlling flow integrity auditing (hereinafter referred to as control flow auditing). The user inputs his or her fingerprint when booting or performing a certain payment operation, activates a certain CA, and the CA calls the authentication program 210, and then the authentication program 210 starts execution (S110). During the execution of the authentication program 210, since a plurality of CoreSight trigger instructions are set in the code, the CoreSigt 270 can perform the feature information collecting operation (S120) when executing each of the triggering instructions, and directly or through the information. The control flow information as the authentication program 270 after the conversion is stored. The SMC call module 220 sends a trigger message to the audit module 240 through the SMC command (S130). Specifically, the trigger message includes content such as CA identity information. The location of the SMC call module 220 can be understood as an "audit point" that triggers an audit.

When the SMC calling module 220 sends a trigger message to the auditing module 240, it involves switching from REE to TEE. The SMC (secure monitor call) command needs to be called, and the intermediate mode of the TrustZone is switched from the REE to the monitor mode (Monitor Mode), and then the monitoring mode is performed. Switch yourself to TEE. SMC is the basic technology of the TrustZone technology framework, and more implementations are not described here.

After the auditing module 240 receives the trigger information, the control flow information of the authentication program 210 is acquired from the memory 260, or the control flow management module 230 is invoked to acquire the control flow information (S140 and S150).

Specifically, the control flow management module 230 acquires control flow information from the CoreSight 270 (S140), and returns to the audit module 240 (S150). More specifically, the previous CoreSigt 270 stores the control flow information in a storage medium inside the CoreSigt 270, and the control flow management module 230 reads the control flow information from the storage medium, and stores the control flow information directly into the memory 260, or The control flow information is subjected to specific processing and then stored in the memory 260 or directly returned to the audit module 240. In some other embodiments, the control flow management module 230 and the audit module 240 can also be combined into one module.

The audit module 240 also obtains an automaton for auditing the control flow in accordance with the audit rules 21. Specifically, the auditing module 240 generates an automaton instance according to the auditing rule 21 (S160). The auditing module 240 implements auditing of the control flow by inputting control flow information or converted information into the automaton instance (S170). After the audit succeeds, the result is returned to the REE side. The REE continues to send the fingerprint information input by the user to the TEE, and then the TE of the TEE side performs the verification of the fingerprint information. For example, the TEE side invokes an authentication TA to verify whether the fingerprint information is preset. There is a match in the legal identity database. If there is a match, the fingerprint verification is successful to the REE side. If the audit is unsuccessful, the TEE terminates the current handshake, returns a handshake unsuccessful message to the REE, or returns information indicating the security issue.

An automaton can be understood as a function implemented by software code. The function's properties contain a two-dimensional array. Each element in the array represents a state of the automaton, such as the xth row and the value of the yth column. v, then the automaton code will be expressed as if the automaton is currently in state x and the current input is event y, then the state of the automaton is transitioned to v. Each state has its own attributes, "initial" and "terminate". There are only one state with an "initial" attribute, but there can be multiple states with a "terminate" attribute. An automaton instance is a specific runtime automaton instance created based on the aforementioned automaton (which can be understood as a template), and its initial state is the state of the attribute "initial". The method for the audit module 240 to perform the audit by using the automaton is specifically: converting the obtained control flow information into an event sequence, and driving the automaton instance to perform state transition by using the event sequence. After all events have been entered, check the status of the automaton. If the state is "terminated", the audit is successful; otherwise the audit fails.

The control flow management module 230 can manage the control flow information (S180), such as pre-processing, storage, and the like. In some other embodiments, the step of the control flow management module 230 acquiring and managing the control flow information from the CoreSight 270 (S140 and S180) may also be triggered without the call of the audit module 240, or before the triggering of the audit module 240. Control flow information is retrieved from CoreSight 270 and stored in memory 260.

It can be seen that the auditing module 240 on the TEE side audits the control flow of the authentication program 210 before the security application TA is invoked, and the call to the TA is actually implemented after the audit is successful (ie, the authentication program 210 is reliably executed), which is effective. The illegal CA is prevented from bypassing the authentication procedure 210. If the authentication process 210 is incomplete, the identity information of the illegitimate CA cannot be obtained normally, and the illegitimate CA can send the forged identity information that does not belong to itself but can pass the verification to the TEE side, and then the TEE side according to the forgery. The identity information is verified by the illegal CA, so that the illegal CA can communicate with the TEE side, thereby causing a security hole in the system.

Further, in this embodiment, the memory area may be divided in the startup phase of the terminal device, and a read-only memory area 260-1 is drawn, and the authentication program 210 is loaded into the read-only memory area 260-1, thereby avoiding authentication. The code of the program 210 is illegally modified to further ensure the security of the terminal device.

Embodiment 3

According to the introduction of the above embodiment, the CoreSight 270 is used to collect control flow information (and other information to be audited), so the security of the CoreSight 270 itself is the basis of the system. To further ensure security, the CoreSight 270 needs to be reviewed before any modules on the TEE side can read data from the CoreSight 270 storage media.

Referring to FIG. 4, a Tracer audit module 230b is added to the base of FIG. 3 for reviewing the CoreSight 270. Referring to the dashed box of FIG. 5, the SMC call module 220 sends a trigger message to the Tracer audit module 230b (S130). The Tracer auditing module 230b first audits the CoreSight 270 (S130a), and sends an audited message to the auditing module 240 (S130b) to trigger the auditing module 240 to perform the next operation.

The CoreSight 270 is reviewed to determine if the CoreSight 270 registers have been modified. Specifically, the current value of the register and the initial value of the register when the CoreSight 270 is initialized are obtained, and the two are compared. If they are consistent, the audit is passed, and if not, the audit fails. The "registers" reviewed here may include all of the registers in CoreSight 270 or any one or more of the registers that are considered critical.

The "initial value" is set at CoreSight design, written in the startup code, and the "initial value" recorded in the code is obtained during the review and then compared with the current value.

The other steps in FIG. 5 are similar to those in FIG. 3, and the foregoing description may be referred to, and details are not described herein.

In some other embodiments, the audit module 240 can still receive the trigger message as shown in FIG. 3 and then selectively invoke the Tracer audit module 230b. In other words, the audit module 240 can determine that the CoreSight 270 need not be audited.

It can be seen that reviewing CoreSight270 before auditing by the above method can improve the credibility of the entire audit process, thereby further improving the security of the system.

Embodiment 4

The present application also provides a method for parallel auditing, which can implement parallel auditing of control flows of multiple programs to be protected by using a tracker in a scenario in which multiple programs to be protected are simultaneously running. The method of parallel auditing can be implemented in any of the foregoing embodiments.

FIG. 6 is a schematic diagram of an apparatus for a parallel auditing method according to an embodiment of the present invention. The CoreSight 270 is configured with a register 271 that can be written to any value by software. There are programs 210a, 210b and 210c to be protected on the REE side. The 210a is the authentication program 210 in the foregoing embodiment, and the programs 210b and 210c to be protected are other codes, which are not limited in this embodiment. Audit module 240 contains three automaton instances a, b, and c. Other modules can be described with reference to the foregoing embodiments.

Different from FIG. 3, the programs 210a, 210b, and 210c are respectively executed by three processes of PID=a, PID=b, and PID=c, and executed to the CoreSight270 trigger instruction, and the CoreSight270 trigger instruction triggers the process of executing the current program. PID (process identification) and write the PID to register 271. When the CoreSight 270 triggers the command to trigger the CoreSight 270 to collect information, it not only collects the control flow information of the collection point, but also reads the value of the PID stored in the time register 271 generated by the control flow information from the register 271, and stores the value associated with the control flow information. Get up as information to be audited. When any one of the programs 210a, 210b, and 210c is executed to the audit point that triggers the audit (for example, S130 in FIG. 3), the audit module 240 on the TEE side is triggered to perform the audit. It is also possible to review the CoreSight 270 before auditing as in the embodiment shown in FIG. 5.

It should be noted that the code for acquiring and writing the process PID can be understood as one or more process identifier acquisition modules, which are not shown in the figure.

In the above manner, each piece of control flow information and the process of generating the control flow information are stored, so that different autonomic machine instances are separately used for auditing for different control flow information.

After the audit is triggered, the auditing module 240 obtains the information to be audited and searches for or creates a matching automaton instance according to the PID in the information to be audited, and inputs the control flow information in the information to be audited into the automaton instance, and each automaton instance Control flow auditing for each program to be protected is implemented separately.

In an implementation manner, as shown in FIG. 7, the auditing module 240 obtains the next piece of control flow information from all the information to be audited, and the piece of to-be-audited information includes the control flow information and the PID (S701). For the manner in which the audit module 240 obtains the information to be audited directly or indirectly from the CoreSight 270, reference may be made to the foregoing embodiment. After the information to be audited is obtained, the auditing module 240 determines whether the information to be audited is empty (S702). If the information to be audited is not empty, the matching automaton instance is searched according to the PID in the information to be audited (S703). Determining whether an automaton instance is found (S704), if an automaton instance is not found, creating an automaton instance identified as the PID (S705); if an automaton instance is found or an automaton instance is created, the control flow information is input into the The automaton instance (S706) is to push the automaton instance forward further. Then, the process returns to step S701.

If it is determined in step S702 that the acquired information to be audited is empty, that is, all the current to-be-audited information is processed according to the foregoing method, the PID of the process for sending the current audit trigger message is obtained (S707). Specifically, the CA on the REE side usually stores the PID of the process of the CA and the identifier and parameters of the TA to be called into the shared memory when the cross-domain call is made, so that the module on the TEE side can be shared from the shared memory. Get the value of the PID of the process. The automaton instance identified as the value of the PID is found (S708), and if such an automaton instance does not exist (S709), the audit fails for this. If such an automaton instance exists (S709), it is determined whether the automaton instance is currently in a state of "terminating" (abbreviated as a termination state), and if so, the audit is successful, and if not, the audit fails.

In another implementation manner, the auditing module 240 first obtains the PID of the process that sends the audit trigger message, obtains the to-be-audited information that contains the same PID from the information to be audited, and then performs the following on each acquired information to be audited. Operation: Find the matching automaton instance according to the obtained PID. If not found, create an automaton instance identified as the PID; if found, enter the to-be-audited information into the automaton instance. After all the information to be audited is processed, if the automaton instance is in the "terminated" state, the audit is successful, otherwise the audit fails.

It should be noted that, in this embodiment, the automata instance that matches the information to be audited is the automaton instance identified as the PID, and the PID is the value of the PID included in the to-be-audited information. For example, the information to be audited with PID=a, the matching automaton instance is an automaton instance identified as a. In some other embodiments, the process PID of the program to be protected and the identifier of the corresponding automaton instance do not have to be completely consistent, and the inconsistency but the correspondence between the two or the conversion relationship between the two may be implemented. .

Through the above parallel auditing method, the control flow audit provided by this embodiment can simultaneously audit multiple programs to be protected in a terminal device having only one tracker, so that the auditing efficiency is higher, and the applicable scenario of the method is wider.

Embodiment 5

In order to further reduce the possibility that the program to be protected is snooped, the embodiment provides a method for performing control flow auditing in combination with a random number.

FIG. 8 is a schematic structural diagram of a terminal device according to an embodiment of the present disclosure. The terminal device includes two hardware (pseudo) random number generators 280a and 280b, which are respectively divided into a REE side and a TEE side by a hardware partitioning mechanism of the TrustZone, that is, the random number generator 280a can Accessed by the REE side (either on the TEE side or inaccessible), the random number generator 280b can only be accessed by the TEE side. In addition, CoreSight 270 is also provided with a register 272, which can be written to any value by software. Each record generated by CoreSight 270 is accompanied by the value of the register at the time the record was generated.

The state of the automaton mentioned in the foregoing embodiment has two attributes of "initial" and "terminating". In the embodiment, when designing the automaton, "data transmission" and "random number generator access" are added for each state. "Number" of two attributes, or add one or more of these attributes to one or more of them based on demand.

According to the execution flow of the authentication program 210, a plurality of locations are selected in the authentication program 210. These multiple locations are called "random number generation points", and the code is inserted at the random number generation point, and the incoming code realizes that the random number is generated. The 280a generates a random number and writes the random number to the register 272 of the CoreSight 270. Thus, when the authentication program 210 executes, each time a random number is generated, the random number generator 280a is called once and the generated random number is written to the register 272.

In the foregoing embodiment, multiple locations of the authentication program 210 are inserted with a CoreSight trigger command for triggering the CoreSight 270 to collect control flow information (refer to FIG. 3). These multiple locations may be referred to as “acquisition points”. The "random number generation point" and "acquisition point" proposed in the example may be completely overlapped, or may be partially overlapped, or may not overlap at all. When a "point" produces a random number, but is not a "collection point", then the random number will be acquired by the CoreSight 270 along with the next adjacent "collection point" and then obtained by the TEE side. As shown in FIG. 9, the authentication program 210 includes at least four acquisition points (shown by a circle) CP1-CP4 and at least five random number generation points (square representation) GP1-GP5, wherein GP3 and CP3, GP5 and CP4 Overlapping separately. If they overlap, as shown in the figure, the generation instruction of the random number of the position is usually before the CoreSight trigger instruction. When the authentication program 210 executes the non-overlapping random number generating point GP1, the random number generator 280a is called to generate the random number R1, and the random number is written into the register 272, and then when the collection point CP2 is executed, the CoreSight 270 is triggered to acquire the The strip control stream information and the current random number R1 in the register 272 (refer to step S120 in Fig. 9) are used as one piece of information to be audited.

After setting the random number generation point, when encoding the automaton, manually or automatically calculate how many random number generation points have elapsed when the automaton runs to each state, and accordingly set the "random number generator access" of each state. Number of times attribute. For example, with continued reference to Figure 9, the program is executed through four acquisition points of CP1-CP4, corresponding to four events E1-E4, and the automaton may be coded according to the execution flow: (S0)–E1->(S1)– E2->(S2)–E3->(S3)–E4->S4. Then, the value of the access number attribute of the random number generator of S0, S1 is 0; since there is a random number between E1 and E2 to generate the point GP1, the value of the access number attribute of the random number generator of S2 is 1; The values of the random number generator access times attribute of S3 and S4 are 3 and 5, respectively.

According to the foregoing example, the last generation of the random number before the REE side termination state S4 is at GP5, the random number needs to be recorded, and the information to be audited is the information to be audited corresponding to the CP4, and the information to be audited includes the control flow information E4. (or as "event") and the random number (refer to Figure 9), so the value of the "data transfer" attribute of state S4 after E4 can be set to 1 in order to facilitate the subsequent automaton instance during operation. The attribute records the last random number generated on the REE side on the TEE side. The value of the "Data Transfer" attribute of other states can be set arbitrarily. Of course, the manner in which the setting is 1 or non-1, true or false is merely an example, and those skilled in the art can easily think of other setting manners according to the essence of the embodiment, and are also within the protection scope of the present application.

According to the foregoing embodiment, after the audit module 240 is triggered, an automaton instance is generated and the automaton instance is driven to perform state transition according to the acquired information to be audited to audit the control flow. In the present embodiment, the following changes are made to the automaton instance: the automaton instance has a variable V for recording random numbers. The status change rule has the following changes: after receiving the information to be audited and the status is pushed, if the value of the "data transmission" attribute of the advanced state is not 1, the random number carried in the information to be audited is ignored, if 1 , the random number is assigned to the variable V. When the audit is completed, if the automaton instance is not in the termination state, the audit is unsuccessful; if the automaton instance is in the termination state, n random numbers are acquired from the random number generator 280b at a time, and the n is the random state of the termination state. The value of the number of generator access times attribute, and then compare the nth random number with the value of the variable V. If they are consistent, the audit is passed. If they are inconsistent, the audit fails.

Specifically, as shown in FIG. 10, any one of the automata instances in the auditing module 240 performs the following steps: acquiring the next to-be-audited information (S1001), including the control flow information E[next] and the random number R[next] , if it is empty (S1002), if it is empty, it means that all the information to be audited is processed; if it is not empty, the automaton instance is advanced to the next state according to the E[next] and S[current] [current] (S1003). Obtaining the value of the "data transfer" attribute of the advanced state S[current] (S1004), determining whether the value is 1 (S1005), if not 1, returning to S1001; if 1, then the random number R[next ] Assigned to the variable V (S1006). After all the information to be audited is processed, it is judged whether S[current] is the termination state (S1007), and if not, the audit fails. If S[current] is the termination state, the attribute value n of the random number generator access number of S[current] is acquired (S1008), and n random numbers are generated according to n, and the nth random number is recorded and the nth random number is recorded. Number Rn (S1009). Then, it is judged whether the current values of Rn and V are the same (S1010). If they are the same, the audit is successful, otherwise the audit fails.

In other implementations, the "data transfer" attribute may also be left unset, that is, each random number may be recorded with a variable V, each time covering the previous value.

It should be noted that the purpose of this embodiment is to match the last generated random number V in the normal execution flow of the REE side to be protected code with the random number Rn generated on the TEE side, and Rn is the automaton termination state according to the execution flow. The pre-set random number generator access number n is generated. In order to achieve this goal, there are many possible changes in designing a specific solution. For example, if the data transfer attribute of the current state is first determined in the automaton instance state transition rule, and then the current state is advanced to the next state, then according to the foregoing example, the state The "data transfer" attribute of S3 should be set to 1 in order to record the last generated random number, etc. These variations are readily apparent to those skilled in the art and are not enumerated herein.

Just using an automaton can only guarantee that a process calls all the points of the call, and there is no guarantee that these points will only be called by it. If another process cuts in and calls some security processes, it is not audited by the automaton. Another process may just cut in to steal some data or inject some fake data, it may not trigger cross-domain calls, its abnormal behavior can not be audited by the automaton, but if it calls "random number generation point", random number The sequence will change, and the automaton will find that the random number does not match, and then the process is found to be disturbed. Therefore, in the above manner, it is possible to timely discover whether the REE side process is interfered on the TEE side, and further improve the security of the system.

Embodiment 6

In the foregoing embodiment, the auditing method of the control flow is introduced, which can largely detect the situation that the program to be protected is modified or bypassed, thereby discovering system problems in time and avoiding system loopholes. The following describes an embodiment that can audit the control flow and also perform identity auditing to further improve security.

When a (static) program is stored on a medium, its code and static data (also called constants) are placed in a storage area, called TEXT segments in some systems. The (dynamic) program is run by the process. Virtual memory technology allows each process to monopolize the entire memory space, starting at zero and reaching the upper memory limit. Each process divides this part of the space (from low address to high address) into multiple parts, one of which is a TEXT segment, which includes the code of the entire program and static data (ie constant).

The TEXT segment of the process contains all the instructions of the program executed by the process. Compared with the process PID or the process name, the TEXT segment is more difficult to forge. Therefore, in this embodiment, this content is understood as the "identity" of the process. The audit is called an "identity" audit.

FIG. 11 is a schematic structural diagram of a terminal device according to an embodiment of the present disclosure. The terminal device includes a hardware (pseudo) random number generator 290, which is divided into the REE side by the hardware partitioning mechanism of TrustZone. In addition, CoreSight 270 is also provided with a register 272, which can be written to any value by software. Each record generated by CoreSight 270 is accompanied by the value of the register at the time the record was generated.

In addition to the "initial" and "terminate" attributes, in the present embodiment, when designing an automaton, a "data transfer" attribute is added for each state, or this attribute is added to one or more of the states according to requirements.

As shown in FIG. 11, there is a self-acquisition module 210a in the authentication program 210, which is used to call the random number generator 290 to generate a random number, and write the random number into the register 272 of the CoreSight 270, and generate a segment. Scrambled data stream. The content of the scrambled data stream is: the generated random number is spliced together with the TEXT segment of the current process on the REE side, and the splicing method is a random number first, a TEXT segment is followed, and the spliced data is made. A hash value H1 obtained by a hash operation (such as the sha256 algorithm). The self-collection module 210a overwrites the random number with other data after calculating the stream header containing the random number. To use random numbers for calculations, random numbers must be read into registers and may even be written to memory, so the "overwrite" here is to remove the value of the random number from the register or memory to prevent hackers from using it. .

In some other embodiments, the random number can be after the TEXT segment. Random numbers have the advantage in the front: the actual processing does not have to be done before the calculation, it can be calculated stream. The random number can be used to complete the calculation related to the random number as soon as possible, so that the value of the random number is cleared from the memory or the register.

In some other embodiments, the spliced may not be the original content of the TEXT segment, and may be a digest of the content contained in the TEXT segment or a compressed TEXT segment. The algorithm for calculating the digest may be, for example, sha256 or md5.

As shown in FIG. 12, the code of the self-acquisition module 210a is set before the authentication program 210 first triggers the location of the CoreSight 270 in the previous embodiment. The piece of code 210a and the authentication program 210 can also be understood together as a program to be protected. Since it also belongs to the program to be protected, a collection point (not shown in FIG. 11) can also be set inside the self-acquisition module 210a.

In addition, copy a TEXT segment of the legal REE side process on the TEE side. Specifically, in the version release process, when the TEE side operating system is compiled, all the contents included in the TEXT segment on the REE side are hard coded into the TEE side operating system.

It should be noted that, in this embodiment, it is assumed that all legal CAs that can be operated on the REE side of this system are known in advance. A CA is a program that is a process at runtime. The TEXT segment here refers to the TEXT segment of all legitimate CAs. Therefore, the "TEXT segment on the REE side" is the TEXT segment of all legal CAs prepared in advance, including the code and constants of each CA.

In other embodiments, hard coding into the TEE side may also be a digest of the original content of the TEXT segment or a compressed TEXT segment.

As shown in FIG. 12, the self-acquisition module 210a executes first, and sets the entry of the code as an "acquisition point" (P1), triggering the CoreSight 270 to collect control flow information and a random number in the register 272, which is a self-acquisition module. 210a generates and writes the random number of register 272. Since the self-acquisition module 210a also generates a random number and writes to the register 272, the acquisition point is also a random number generation point (P1). When the automaton is encoded, the data transmission attribute of the state obtained by inputting the event corresponding to the acquisition point P1 into the automaton is set to 1. For example, suppose that the event corresponding to the feature information collected by the P1 trigger CoreSight 270 is E _P1 , the state of the automaton before the input of E _P1 is S0, and the state of the automaton after the input is changed to S1, that is, (S0)–E _P1 −>(S1), then The value of the data transfer attribute corresponding to S1 is set to 1.

It should be noted that, since this embodiment only needs to generate a random number once, the random number can also be transmitted to the TEE side along with other acquisition points except P1.

The REE transmits the hash value H1 obtained from the acquisition module 210a to the TEE through a conventional means provided by the TrustZone, and specifically, to the audit module 240. This can happen any time after the hash value is generated, but is recommended to be passed before the audit module 240 is triggered.

Referring to FIG. 13, after the audit module 240 is triggered, the execution process of the automaton instance is similar to that of FIG. 10, except that the random number is generated only once (refer to FIG. 12, the random number generation point P1), and because the corresponding state is set. The data transfer attribute, so the random number is recorded in the variable V after the automaton instance is finished, referring to steps S1301-S1306 of FIG.

It should be noted that, in other embodiments, the steps S1301-S1306 can also be simplified. Because there is only one random number, the step of acquiring and judging the data transmission attribute can be cancelled after the first time V is assigned. There are many similar variants that the coding personnel can easily think of, and the present application does not describe them one by one.

With continued reference to FIG. 13, if the final state S[current] is the termination state, the value of V and the hard-coded TEXT segment or TEXT segment are spliced together, and the splicing mode is the value of V first, TEXT segment or TEXT. After the summary of the segment is followed, the spliced data is hashed to obtain a hash value H2 (S1308), and H1 and H2 are compared (S1309). If the two are the same, the audit is passed, otherwise the audit fails. In other embodiments, if the hard-coded TEXT segment is hard-coded, decompression is needed here.

The random number generator mentioned in any of the foregoing embodiments is a hardware implementation. In other embodiments, the random number generator can also be implemented in software. For example, the two random number generators 280a and 280b in FIG. 8 are replaced by software-implemented two random number generators, and the two software random number generators are respectively placed in a storage area that can be accessed by the REE and can only be In the storage area accessed by the TEE.

Through the method provided in this embodiment, joint auditing of identity and control flows can be implemented, which further improves the security of the system. Further, in the process of transmitting identity information to the TEE, the random number is used for scrambling to ensure the security of the identity information transmission process.

Example 7

In the embodiment shown in Figure 4 above, to ensure the security of the CoreSight 270, the CoreSight 270 was reviewed to ensure that the CoreSight 270 was not tampered with. The embodiment further provides a security implementation method of the tracker. After the secure tracker is implemented by hardware or software, the review of the tracker is not necessary.

The first is hardware, which guarantees the security of the CoreSight270 through hardware isolation.

In the system startup phase, the CoreSight 270 is divided into the system security zone by hardware. For example, as shown in FIG. 14, in this embodiment, the modules of the CoreSight 270 can be divided into the security world by the TZPC (TrustZone protection controller), that is, the TEE side. To ensure that only the TEE can access the CoreSight270, thus avoiding CoreSight270 being attacked.

TZPC is

A standard module (IP) under the architecture that provides the ability to partition different hardware modules in a system into a secure world (such as TEE) or a non-secure world (such as REE). The function of TZPC is to control the access rights of other hardware. Some hardware can be divided into secure hardware or non-secure hardware through TZPC. Among them, the security hardware can only be accessed by the operating system of the security world, and the operating system access of the non-secure world is divided into hardware registers of the security hardware, which may cause errors.

Specifically, the hardware CoreSight 270 and the hardware TZPC are connected during hardware manufacturing, so that the TZPC has the ability to control the CoreSight 270. The TEE side is initialized first when the system starts up. During the initialization process, the CoreSight 270 is divided into secure state accessible by hardware TZPC, and non-secure state is inaccessible.

The second is the software mode, which guarantees the security of CoreSight270 through the setting of software access rights. The management of the CoreSight 270 is placed at a higher privilege level of the same security level. When accessing the CoreSight 270 at a lower privilege level, it will first fall into a high privilege level, restricting access to the CoreSight 270 through a page table prefabricated at a high privilege level.

Specifically, in the system startup phase, the page table of the REE side EL2 is configured to prevent access to the CoreSight 270 from EL0 and EL1, and a list of CoreSight 270 readable and writable registers and a table of possible values are prefabricated in EL2, respectively. In the authentication process 210 execution and information collection phase, the REE side

The kernel's access to the CoreSight 270 will fall into EL2, which only allows EL1 to operate on specific values of the preset registers. In this way, the attack on CoreSight270 from EL1 and EL0 is partly due to this. In this embodiment, although the CoreSight 270 is protected on the REE side, it is still necessary to perform a CoreSight 270 audit at the TEE to further ensure security.

It should be noted that EL is an abbreviation of exception level, which is

The concept inside. In one way, EL0 can be understood as a user mode, EL1 is understood to be a kernel mode, EL2 is a hypervisor, and EL3 is a secure mode. EL2 can control EL0 and EL1 access to physical memory. The above embodiment means that the EL2 collation table is limited in that EL0 and EL1 access the physical memory address of the CoreSight 270 register.

Figure 15 shows another system in which the REE side is divided into a hypervisor 22 and a normal operating system 21 (or guest operating system). In such a system, the normal operating system 21 is the first operating system in the foregoing embodiment (refer to FIG. 1), and it needs to undergo a two-stage mapping when accessing the memory of the hardware layer (for example, memory and registers): the first stage of normal operation System 21 maps the virtual address to a virtual linear address using the managed first page table; the second stage hypervisor maps the virtual linear address to the actual physical address using the second page table managed by the hypervisor. In such a system, if the second page table managed by the hypervisor does not map certain registers, the normal operating system 21 cannot access the hardware controlled by these registers, and the hypervisor itself can access them directly through the physical address. A virtual machine (VM) and a virtual machine monitor (VMM) are a specific implementation of the system, in which a common operating system 21 runs in a VM, and a VMM is a hypervisor.

Using the above mechanism, the security of the CoreSight 270 is enhanced by the hypervisor. The specific implementation steps are as follows: the system starts; the hypervisor 22 is started; the hypervisor 22 creates the second page table 221, and the second page does not include the address mapping of the hardware registers of the CoreSight 270, in other words, No virtual linear address can be mapped to the address of the CoreSight270 register. The hypervisor 22 then starts the normal operating system 21 and creates a first page table 211.

Similarly, CoreSight 270 is triggered to collect information after authentication program 210 is invoked. At the time of the trigger, instead of directly triggering, the normal operating system 21 calls hypercall and starts the CoreSight 270 through the hypervisor 22. When the normal operating system 21 runs outside the code to be protected, hypercall is called, and the CoreSight 270 is closed by the hypervisor 22.

Through the above method, the CoreSight270 call is moved down to the hypervisor22, thereby avoiding the normal operation of the CoreSight 270 by the normal operating system 21, and improving the security of the CoreSight 270.

Since a tracker has multiple components, such as a data collection module, a data transmission module, and a data storage module, only one or more of the critical components can be protected when the security of the tracker is implemented by software or hardware. For example, only the data storage module for storing data may be protected in the aforementioned hardware or software implementation. In this way, the REE side operating system or the normal operating system 22 can still control the data collection module and the data transmission module of the CoreSight 270, but cannot control the data storage module, thereby improving flexibility while avoiding the REE side operating system or the ordinary operating system 22 passing. Write fake data to the data storage module for spoofing.

The third is the combination of soft and hard. Considering that a tracker has multiple components, some components (such as ETM) can be protected by the above software in order to facilitate the design of the system software and reduce the software overhead, and the remaining components are protected by hardware. Among them, ETM (Embedded Trace Macrocell) is a component in CoreSight, which is used to obtain the tracking information of the processor core.

Through any of the above methods, the tracker itself can be prevented from being tampered to a certain extent, the security of the tracker itself is ensured, the audit trailer is avoided, and the audit process of the control flow is simplified without affecting the security of the system.

Example eight

In order to further prevent the malicious program from falsifying the control flow spoofing control flow auditing process with the wrong data, this embodiment adds the audited elements and provides a joint auditing method for the control flow and the data flow.

FIG. 16 is a schematic structural diagram of a terminal device according to the embodiment. The terminal device includes a CoreSight 270, and the ETM component of the hardware enables the ViewData function. The ETM is a component of the CoreSight 270 located inside the processor 250 for collecting control flow information. ViewData is an optional feature of ETM hardware. If this feature is configured, the ETM has the ability to monitor the value of the data that the load/store instruction reads from or writes to memory. After the ViewData function is enabled, if the monitored instruction is load/store, the collected information has the value of the data read or written by the load/store instruction in addition to the control flow information. This part of the information is called data in this embodiment. Stream or data stream information.

The authentication procedure 210 in this embodiment is no longer a prior art authentication procedure, and multiple locations of the authentication procedure 210 are inserted into multiple CoreSight triggering instructions. The load/store directive exists in the location where some or all of the CoreSight trigger instructions are inserted. The trigger instruction is used to trigger the CoreSight 270 to collect control flow information and data information. The CoreSight trigger instruction can be a program whose functions are: 1. Configure the data transfer register of CoreSight270; 2. Enable CoreSight270 to start data collection. Among them, function 1 includes the register of the ETM component of CoreSight270, which enables ViewData to monitor the data stream. After the auditing module 240 receives the trigger information, the control flow information and the data flow information of the authentication program 210 are obtained from the memory 260, or the control flow management module 230 is invoked to acquire the control flow information and the data flow information.

The state of the automaton mentioned in the foregoing embodiment has two attributes of “initial” and “terminating”. In the embodiment, when designing the automaton, the “data flow auditing” attribute is added for each state, or according to requirements. One or more of these states adds these two attributes. The state containing the data flow audit attribute also requires a data constraint. The data constraint may be a limit on the range of a data value, such as the data is not 0 or greater than 1000, or may be a relationship with other data, such as the data is obtained twice or less than the state y obtained by the state x Data, etc. If the data constraint is related to other data, the automaton needs to add a set of variables to store the data acquired during the operation of the automaton, called the "acquired data list".

In addition, in the present embodiment, when the automatic machine is designed, a state is added. The new state is not the initial and terminated states, and the destination state without any other state is the state. This state accepts all events, and the destination state is all the state itself. This state is hereinafter referred to as state F.

After the auditing module 240 is triggered, the automaton instance is generated and the automaton instance is driven to perform state transition according to the acquired control flow information and the data flow information to audit the control flow and the data flow. In this embodiment, the state change rule has the following changes: after receiving the information to be audited and the state is pushed, determining whether to obtain the value of the data related to the data flow in the information to be audited according to the data flow audit attribute of the current state (in the information to be audited) There may also be no data flow related data), and the value of the data is checked according to the data constraint corresponding to the state. If the check is passed, the data is saved in the “acquired data list” of the automaton, and the next information to be audited is continuously obtained; if the check is not passed, the current state is set to the state F.

Specifically, referring to FIG. 17, the attribute value of the data flow audit attribute of the current state S[current] is obtained (S1704). If the value is not 1, the process returns to step S1701. If the value is 1, the value of the data is compared. With the data constraint condition of S[current] (S1707), if the value of the data satisfies the data constraint condition, the value of the data is saved in the "acquired data list" (S1709), and returns to step S1701; otherwise S[current] is set to state F. After all the information to be audited is processed, if S[current] is not terminated, the audit fails. If S[current] was set to state F at the time of the previous processing, the state F will remain until the end according to the characteristics of the state F, which will cause the audit to fail. If S[current] is in the termination state, the audit is successful, or other judgments are made with reference to any of the foregoing embodiments.

In other embodiments, if it is known that each data constraint does not involve comparison with other data or historical data, the data in the data stream may not be recorded, ie, the variable "acquired data list" is not set.

It should be noted that the setting of the data flow audit attribute here is only an example, and other methods are not enumerated. Figure 17 is only an illustration of the important steps of this embodiment, some of which are similar to the previous embodiments, and may be referred to the foregoing description.

The method of the present embodiment and the method of other embodiments of the present application can also be used in combination. For example, if one of the data flow auditing attributes and the data transmission attribute and the random number generator access number attribute mentioned in the foregoing embodiment exist simultaneously, when the information to be audited is processed, the concurrent attributes are implemented according to the foregoing. The method described in the example is processed.

Example nine

The method provided by the present application can be applied not only to relatively complicated scenes but also to simple scenes. For a simple scenario, the present embodiment provides a simplified auditing method.

In this embodiment, there is only one CPU, and the external interrupt is turned off during the execution of the authentication program 210 (hereinafter referred to as an authentication flow). In the present embodiment, the instruction for starting the authentication process in the authentication program 210 and the address of the instruction for invoking the TEE function (referred to as address A and address B, respectively) are hard-coded into the operating system on the TEE side.

In the present embodiment, the CoreSight trigger instruction is not inserted in the authentication program 210. The CoreSight 270 is controlled by the operating system on the TEE side and is turned on before each switch to REE (including the first switch to REE at startup). Once turned on, CoreSight 270 begins collecting control flow information and stores it in its internal memory. At or after switching to the TEE, the operating system on the TEE side reads the control flow information stored in the memory inside the CoreSight 270, and finds the last occurrence according to the address A and the address B stored by the TEE side (obtained by hard coding described above). The acquisition point y of address B (or as a data point), and find the collection point x where address A last appeared before the last occurrence of address B. Between the collection point y and the last collection point recorded in the hardware, it is checked whether there are other collection points, and the address information is address A. If one or more of the following conditions are met, the audit fails: 1. The collection point cannot be located; y2. The collection point cannot be located; x3. There is an address between the collection point y and the last collection point recorded in the hardware. A.

It should be noted that, in other implementations, control flow information may still be collected by inserting a CoreSight trigger instruction at a code location corresponding to address A and address B. Additionally, the above steps can be simply extended to verify that the REE has executed 3 or more addresses in order.

Through the above simplified auditing method, it can be seen that the auditing rules do not have to be implemented by means of an automaton, and the control flow or other information is audited through an automaton instance, and different rules can be set for different scenarios, according to the rules. Different implementations of features and complexity may be performed by simple matching procedures based on simple rules.

Example ten

In some of the foregoing embodiments, the original program is inserted into the tracker triggering instruction to form a program to be protected. The program to be protected may be manually written, that is, the triggering instruction is manually inserted, or the computer may automatically be based on the auditing requirement. Generated. This embodiment provides a method for automatically generating a program to be protected.

Referring to FIG. 18, there are a version generation device 310 and a version distribution device 320 on the server 300 side. The two devices may exist on the same physical server or on different physical servers.

The version generating device 310 includes a processing unit 311 for automatically generating a program to be protected and an audit rule according to the program and the auditing requirement, and generating the program to be protected by the software issuing unit 321 located in the version issuing device. , or the program to be protected and the audit rules are sent to the terminal device, such as a smartphone, a tablet, and the like. The terminal device stores the program to be protected and the audit rule in a local storage, and can be stored in a read-only storage area to avoid malicious tampering.

Embodiment 11

When there are many paths in the flow to be audited and the description of the audit rules is complex, on the one hand, the efficiency of the audit may be low and the normal business may be affected. On the other hand, the complicated rules may result in the audit accuracy being reduced and the auditing failure. For a more complicated scenario, this embodiment proposes a machine learning method to improve the accuracy of the audit rule description and reduce the complexity of the rule as much as possible, thereby improving the efficiency of the audit.

In this embodiment, a positive sample is generated by performing acquisition, and a negative sample is generated by a simulated attack, and a control flow model is learned and generated from the two types of samples, and an audit rule is generated according to the control flow model. In this embodiment, the audit rule is a model obtained by machine learning, and the collected information may be directly or after being filtered and input into the model, and whether the audit is successful according to the calculated result (the automaton is not necessary).

In addition, it is no longer necessary to use the method of inserting the trigger instruction to trigger the tracker acquisition. As long as the tracker is configured to be in the on state, the tracker can collect all the control flow information of the running program, and collect the control flow information and machine learning. Extract audit rules. Further, if you want to apply the data flow auditing methods mentioned in some of the foregoing embodiments, you can also collect data stream information and other information to be audited.

As shown in FIG. 19, the server 400 includes a machine learning device 410 and a rule issuing device 420. The machine learning device 410 is configured to generate an audit rule by a method of machine learning, and the rule issuing unit 421 in the rule issuing device 420 is configured to send the audit rule to each terminal device. The device 420 of Figure 19 can be combined with the device 320 of Figure 18 into one device.

The method for generating audit rules is as follows:

1. Compiling the program into a runnable target program, the running module 411 runs the target program in the target terminal or the simulation environment; 2. During the running of the target program, the running module 411 simulates various input conditions, and the collecting module 413 collects the conditions. Control flow information and/or data flow information as a positive sample; 3. During the running of the target program, the attack module 412 simulates various possible attacks, and the acquisition module 413 collects control flow information and/or data during the attack process. Flow information, as a negative sample; 4, the positive and negative samples as the feature model of the program, input into the machine learning algorithm, through which the rules of the program execution feature are extracted; 5. The processing tool processes the aforementioned rules and the source to be audited; 7. The audit blueprint and the protection object of the processing output are placed on the version release server as the release target. The acquisition module 413 in this embodiment collects information through a tracker.

The detailed process of positive and negative samples and learning training is described below. It should be understood that the acquisition process of the positive and negative samples is similar to the information acquisition process of the audit method described in the foregoing embodiments. Similar or identical parts can be referred to the foregoing embodiments.

(1) Acquisition of positive samples

1) Arriving at the audit point and submitting the information to be audited, the information to be audited may include control flow information and data flow information;

2) The security domain (eg TEE) operating system reads the information to be audited in the circular buffer and records it in (non-volatile) memory, which is called a positive sample;

3) The security domain operating system returns the audit and passes the subsequent operations;

4) Run the above process in different scenarios to obtain a certain number of positive samples.

The circular buffer can be implemented as an array to record information from the beginning. If the array is full, continue recording from the beginning, overwriting the oldest record in the buffer.

(1) Acquisition of negative samples

1) Attack the system, try to bypass the program and call the audit point, taking the ROP attack as an example:

Analyze the system image, use the ROP Gadget or similar tool to find the available gadgets, and construct the attack chain. The functions implemented by the attack chain include: calling a function in the secure operating system (such as a TA).

b. Put the gadget call chain on the stack by intentionally setting or existing stack overflow vulnerability in the system;

c. When the system runs to the ret command, the ROP attack begins: the specific function in the program is executed by the ROP method, and the security domain operating system is invoked;

2) The security domain operating system is called to reach the audit point, read the information to be audited in the circular buffer, and record it in the memory, the record is called a negative sample.

ROP, called Return-oriented Programming, is a new type of code-based reuse attack that allows an attacker to extract instruction fragments from existing libraries or executables and build malicious code.

(3) Establishment of the model

A machine learning algorithm is used to build a classifier based on positive and negative samples. Take the C5.0 decision tree algorithm as an example:

1) Data Preprocessing 1: Parse all positive and negative samples and generate a set of events for each sample. The event refers to an event that occurs in the sample. For example, CPU3 executes an instruction at 0xfffffff12340000.

2) Data preprocessing 2: Eliminate unimportant information in the event collection, such as CPU number.

3) Analyze all data points appearing in the positive and negative samples to create a high dimensional space. Each of the data points that once appeared in a sample is a dimension. For example, if the following message appears in a sample: an instruction at 0xfffffff12340000 is executed, there is a dimension corresponding to it in the high-dimensional space.

4) Vectorization: Convert each sample into a vector in the high-dimensional space defined in the previous step. The principle of conversion is: if there is an event in the event collection of the sample, the vector has a value of 1 in the dimension corresponding to the event, otherwise the value is 0.

5) Label: Convert all vectorized samples into a binary group: <vector, positive and negative>. Among them, positive and negative values in the positive sample are true, and negative samples are opposite.

6) Generate a decision tree using the C5.0 algorithm for all labeled vectors generated in the previous step. The effect of a decision tree is: Given a vector, give true or false. The goal of training is to try to return the vector in the positive sample to true, and the vector in the negative sample to return false.

7) Encode the decision tree generated in the previous step to obtain the audit rules.

Take the following procedure for calculating A+B/C as an example. The program is converted to assembly language as:

1:X1=[B]

2:X2=[C]

3: X3 = X1/X2

4:X4=[A]

5: X5=X4+X3

Here, the instructions 1, 2, and 4 all generate data. During training, use the various legal A, B, and C as inputs, run the above program, and generate multiple positive samples. The flow of control for these positive samples is 1-2-3-4-5, and the data streams are different, but the value of C is never zero.

1) First attack this program. Various attack methods are used, such as cutting through ROP, executing only the subsequent part; sending interrupts to interrupt execution, etc.; using illegal data, such as making C 0. Finally, multiple negative samples are generated. 2) Then extract the features. This step needs to be obtained by some mathematical method or by artificial designation. This example extracts the control flow characteristics: instruction 1 is followed by instruction 2, instruction 2 is followed by instruction 3, instruction 3 is followed by instruction 4, instruction 4 is followed by instruction 5 (both are legal features), and instruction 2 is followed by instruction 1. Instruction 5 is followed by instruction 2... (these are illegal features), and the data stream characteristics: A is not 0, B is not 0, C is not 0.... 3) Next vectorization. Convert each data into a vector. Wherein each dimension of the vector corresponds to one of the above features. If the data satisfies this feature, the value in this dimension is 1, otherwise 0. For example, a positive sample may have the characteristics [1,1,1,1,0,0,...,0,0,1]; a negative sample, which may be characterized by [0,1,0,1,0 , 0,...,0,1,1].

By doing the above conversion for each sample, multiple vectors are generated and the vector is known to correspond to a positive or negative sample.

With the above information, you can use the C5.0 decision tree training algorithm for training. Finally, a decision tree is obtained, and the decision tree is the audit rule.

During the terminal device audit process, the collected information is vectorized as described above and then input to the decision tree, and the sample is output as a positive sample or the sample is a negative sample, and if the conclusion is a negative sample, the audit fails.

The above-mentioned machine learning method can automatically generate an audit rule and send it to the terminal device. The audit rule can be one or more models (can be understood as a formula), and then the terminal device collects the information to be audited in real time, inputs the model, and obtains Audit results. It can be seen that using this method can improve the generation speed and accuracy of the audit rules, thereby improving the reliability of the audit process.

If all the control flows are waiting for the audit information in the process of generating the audit rules, it is not necessary to insert the CoreSight trigger command in the process of performing the control flow auditing of the terminal device, and the specific location of the program to be protected is The trigger tracker collects the information to be audited, and can open the tracker and configure its function to collect the control flow waiting for the audit information before the program to be protected starts executing.

In other embodiments, the position of the trigger instruction may be determined by the machine learning algorithm. For example, after the decision tree is generated, the instructions with the weight are selected, and the trigger instruction is inserted at the code corresponding to the instruction. It can be seen that the machine learning algorithm can also be combined with the insertion method of the trigger instruction.

Example twelve

FIG. 20 is a schematic structural diagram of a computer system according to an embodiment of the present invention. The computer system can be a terminal device. As shown, the computer system includes a communication module 510, a sensor 520, a user input module 530, an output module 540, a processor 550, an audio and video input module 560, a tracker 570, a memory 580, and a power source 590.

Communication module 510 can include at least one module that enables communication between the computer system and a communication system or other computer system. For example, the communication module 510 can include one or more of a wired network interface, a broadcast receiving module, a mobile communication module, a wireless internet module, a local area communication module, and a location (or positioning) information module. There are many implementations of these various modules in the prior art, and the present application does not describe them one by one.

Sensor 520 can sense the current state of the system, such as an open/closed state, position, contact with the user, direction, and acceleration/deceleration, and sensor 520 can generate a sensing signal for controlling the operation of the system.

The user input module 530 is configured to receive input digital information, character information or contact touch/contactless gestures, and receive signal input related to user settings and function control of the system. User input module 530 includes a touch panel and/or other input device.

The output module 540 includes a display panel for displaying information input by the user, information provided to the user, or various menu interfaces of the system, and the like. Optionally, the display panel can be configured in the form of a liquid crystal display (LCD) or an organic light-emitting diode (OLED). In some other embodiments, the touch panel can cover the display panel to form a touch display. In addition, the output module 540 may further include an audio output module, an alarm, a haptic module, and the like.

The audio and video input module 560 is configured to input an audio signal or a video signal. The audio and video input module 560 can include a camera and a microphone.

The power supply 590 can receive external power and internal power under the control of the processor 550 and provide the power required for operation of the various components of the system.

Processor 550 can include one or more processors. For example, processor 150 can include one or more central processors, or can include a central processing unit and a graphics processor. When the processor 150 includes a plurality of processors, the plurality of processors may be integrated on the same chip, or may each be a separate chip. A processor can include one or more physical cores, with the physical core being the smallest processing module.

Tracker 570 is used to acquire instruction information of the processor for debugging or other purposes. Tracker 570 contains a number of components that are distributed throughout the hierarchy of the system, and some components may be embedded into the processor as shown.

The memory 580 stores a computer program including an operating system program 582, an application 581, and the like. Typical operating systems such as Microsoft's Windows, Apple's MacOS, etc. for desktop or notebook systems, as developed by Google Inc.

Android

A system such as a system for a mobile terminal.

The memory 580 may be one or more of the following types: flash memory, hard disk type memory, micro multimedia card type memory, card memory (such as SD or XD memory), random access memory (random access memory) , RAM), static random access memory (SRAM), read only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable Read-only memory (PROM), magnetic memory, magnetic disk or optical disk. In some other embodiments, the memory 580 can also be a network storage device on the Internet, and the system can perform operations such as updating or reading on the memory 580 on the Internet.

The processor 550 is configured to read a computer program in the memory 580 and then execute a computer program defined method, such as the processor 550 reading the operating system program 582 to run an operating system on the system and implementing various functions of the operating system, or reading One or more applications 581 are taken to run the application on the system.

The memory 580 also stores other data 583 in addition to the computer program, such as the information to be audited as set forth herein.

Other operations in the scheme provided by the present application other than the operations implemented by the tracker can be implemented by hardware or software. In the hardware implementation, an application specific integrated circuit (ASIC), a digital signal processor (DSP), a programmable logic device (PLD), a field programmable gate array ( At least one of an electronic unit such as a field programmable gate array (FPGA), a processor, a controller, a microcontroller, and/or a microprocessor implements an embodiment of the present application. In a software implementation, implementations such as procedures and functions may be implemented using software modules that perform at least one function and operation. The software modules can be implemented in a software program written in any suitable software language. The software program can be stored in memory 580 and read and executed by processor 550. The tracker utilized in the present application contains a plurality of hardware components distributed in multiple layers of the system, but the execution of the hardware often requires software drivers, so the "tracker" does not exclude that some components may be software implemented.

The connection relationship of each module in FIG. 20 is only an example, and the method provided in any embodiment of the present application may also be applied to other connection mode terminal devices, for example, all modules are connected through a bus.

It should be noted that the division of the modules or the units in the foregoing embodiments is only shown as an example, and the functions of the various modules described are only examples, and the application is not limited thereto. One of ordinary skill in the art can combine the functions of two or more of the modules as needed, or split the functions of one module to obtain more finer-grained modules, as well as other variations.

The same or similar parts between the various embodiments described above may be referred to each other.

The device embodiments described above are merely illustrative, wherein the modules described as separate components may or may not be physically separate, and the components displayed as modules may or may not be physical modules, ie may be located A place, or it can be distributed to multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the embodiment. In addition, in the drawings of the device embodiments provided by the present invention, the connection relationship between the modules indicates that there is a communication connection between them, and specifically, one or more communication buses or signal lines can be realized. Those of ordinary skill in the art can understand and implement without any creative effort.

The foregoing is only some specific embodiments of the present application, but the scope of protection of the present application is not limited thereto.

Claims

A computer system, wherein a first domain and a second domain are deployed on the computer system, a program is deployed in the first domain, and a control flow management module and an audit module are deployed in the second domain, where:

The control flow management module is configured to: when the program located in the first domain is executed, acquire information to be audited by a tracker, where the information to be audited includes control flow information of the program;

The auditing module is configured to perform an audit on the information to be audited according to an auditing rule, and determine that the auditing is passed when the information to be audited matches the auditing rule.
The computer system according to claim 1, wherein said information to be audited further comprises data stream information of said program.
A computer system according to claim 1 or 2, wherein said computer system further comprises a Tracer audit module deployed in said second domain,

The Tracer auditing module is configured to perform an audit on the tracker before the auditing module performs an audit, and then trigger the auditing module to perform the auditing after the auditing is passed.
The computer system according to any one of claims 1 to 3, wherein the computer system further comprises a process identifier acquisition module deployed in the first domain,

The process identifier acquisition module is configured to: obtain a process identifier of a process that executes the program before the tracker collects the control flow information, and store the process identifier in a first register of the tracker ;

The control flow management module is configured to: obtain the information to be audited by the tracker, where the information to be audited further includes the process identifier, where the process identifier is the tracker from the first The process ID read in a register;

The auditing module is specifically configured to: find an auditing rule that matches the process identifier according to the process identifier, and perform an audit on the control flow information according to the found auditing rule.
The computer system according to any one of claims 1 to 4, wherein the computer system further comprises a first random number generator and a self-acquisition module deployed in the first domain, the second domain Include the TEXT segment of the program;

The self-acquisition module is configured to: call the first random number generator to generate a random number RX before the program is executed, and store the random number RX in a second register of the tracker; The random number RX and the TEXT segment of the process executing the program are calculated to obtain a hash value H1;

The control flow management module is configured to: acquire the to-be-audited information by using the tracker, and the to-be-audited information further includes the random number RX, where the RX is accessed by the tracker Two registers are obtained;

The auditing module is specifically configured to: obtain the hash value H1; calculate a hash value H2 according to the random number RX and the TEXT segment included in the second domain, and compare the H1 and H2, The audit is determined to be passed when the H1 and H2 are the same and the other information to be audited matches the audit rule.
A computer system according to any one of claims 1 to 4, wherein the computer system further comprises a first random number generator deployed in the first domain and a second random number generator deployed in the second domain ;

The control flow management module is configured to: obtain the to-be-audited information by using the tracker, and the to-be-audited information further includes a random number, where the random number is when the program is executed a first random number generator is generated and generated and then written into a third register of the tracker, and then accessed by the tracker to access the third register;

The auditing module is specifically configured to: acquire a last random number RY generated by the first random number generator during execution of the program, and acquire a random number n of presets in the second domain; The n triggering the second random number generator to generate n random numbers, and comparing the nth random number Rn with the RY, when the Rn is the same as the RY and other to-be-audited information matches the The audit is determined when the audit is approved.
A computer system according to any one of claims 1 to 6, wherein all or part of the components of the tracker are deployed to the second domain by hardware partitioning, or all of the trackers The component or part of the component is deployed to the second domain by means of software rights management; wherein the security of the second domain is higher than the first domain.
A computer system according to any of claims 1-7, wherein the audit rules are obtained by a machine learning method.
A computer system according to any of claims 1-8, wherein the program is stored in a read only memory area.
A computer system having a first domain and a second domain deployed thereon, the computer system further comprising a processor, a tracker and a memory, wherein:

The memory is configured to: store computer readable instructions;

The processor is configured to: execute the computer readable instructions to: initiate the tracker, and execute a program in the first domain;

The tracker is configured to: when the processor executes the program, collect information to be audited, where the information to be audited includes control flow information of the program;

The processor is further configured to: execute the computer readable instructions to: obtain the to-be-audited information in the second domain, and perform an audit on the to-be-audited information according to an auditing rule, when the The audit is determined when the audit information matches the audit rules.
The computer system according to claim 10, wherein said information to be audited further comprises data stream information of said program.
A computer system according to claim 10 or 11, wherein

The processor is further configured to: review the tracker in the second domain prior to performing the auditing, and perform the auditing after the audit is passed.
A computer system according to any of claims 10-12, wherein

The processor is further configured to: before the tracker collects the to-be-audited information, acquire a process identifier of a current process in the first domain, and store the process identifier in the tracker a register

The tracker is configured to: when the control flow information is collected, read a process identifier currently stored in the first register, and use the control flow information as the to-be-audited information;

The processor is configured to: in the second domain, find an audit rule that matches the process identifier according to the process identifier, and perform an audit on the control flow information according to the found audit rule.
A computer system according to any of claims 10-13, wherein the computer system further comprises a first random number generator deployed in the first domain, the second domain comprising the program TEXT segment;

The processor is further configured to: call the first random number generator in the first domain to generate a random number RX and store the random number RX in the tracking before executing the program The second register of the device, and the hash value H1 calculated according to the random number RX and the TEXT segment of the process executing the program;

The tracker is further configured to: when collecting the control flow information, read a random number RX stored in the second register to be used as information to be audited together with the control flow information;

The processor is further configured to: acquire the hash value H1 in the second domain, and calculate a hash value H2 according to the random number RX and the TEXT segment included in the second domain, Comparing the H1 and H2, the audit is determined to be passed when the H1 and H2 are the same and the information to be audited matches the audit rule.
A computer system according to any of claims 10-13, wherein the computer system further comprises a first random number generator deployed in the first domain and a second deployed in the second domain Random number generator

The processor is further configured to: call the first random number generator to generate a random number when the program is executed in the first domain, and store the random number in a third register of the tracker ;

The tracker is further configured to: read a random number currently stored in the third register when acquiring the control flow information, to be used as the information to be audited together with the control flow information;

The processor is further configured to: acquire, in the second domain, a last random number RY generated by the first random number generator during execution of the program, and acquire a preset in the second domain Generating the number of random numbers n; triggering the second random number generator according to the n to generate n random numbers, and comparing the nth random number Rn with the RY, when the Rn is the same as the RY When the information to be audited matches the audit rule, the audit is determined to pass.
A computer system according to any one of claims 10-15, wherein all or part of the components of the tracker are deployed to the second domain by hardware partitioning, or all of the trackers The component or part of the component is deployed to the second domain by means of software rights management; wherein the security of the second domain is higher than the first domain.
A computer system according to any of claims 10-16, wherein the audit rules are obtained by a machine learning method.
A computer system according to any of claims 10-17, wherein said program is stored in a read-only memory area of said memory.
A security control method is characterized in that it is applied to a computer system in which a first domain and a second domain are deployed, including:

When the program located in the first domain is executed, the information to be audited is acquired by the tracker in the second domain, and the information to be audited includes control flow information of the program;

The information to be audited is audited according to an audit rule in the second domain, and when the information to be audited matches the audit rule, it is determined that the audit passes and allows access to the second domain.
The method of claim 19, wherein the information to be audited further comprises data stream information of the program.
The method according to claim 19 or 20, further comprising: before auditing the control flow information, further comprising:

The tracker is audited in the second domain, and the control flow information is audited after the audit is passed.
A method according to any of claims 19-21, wherein

The method further includes:

Obtaining, in the first domain, a process identifier of the process of executing the program, and storing the process identifier in a first register of the tracker, before acquiring the information to be audited by the tracker;

corresponding:

The obtaining the information to be audited by the tracker includes: acquiring the information to be audited collected by the tracker, where the information to be audited further includes the process identifier, where the process identifier is the tracker from the The process identifier read in the first register;

The auditing the information to be audited according to the auditing rule includes: searching for an auditing rule that matches the process identifier according to the process identifier, and performing an audit on the control flow information according to the found auditing rule.
The method of any of claims 19-22, wherein the computer system further comprises a first random number generator deployed in the first domain, the second domain comprising the program TEXT segment;

The method further includes:

Calling the first random number generator in the first domain to generate a random number RX, and storing the random number RX in a second register of the tracker, and according to the program being executed The random number RX and the TEXT segment of the process executing the program are calculated to obtain a hash value H1;

corresponding:

The obtaining the information to be audited by the tracker includes: acquiring the information to be audited collected by the tracker, where the information to be audited further includes the random number RX, wherein the RX is accessed by the tracker The second register is obtained;

The auditing the information to be audited according to the auditing rule includes: obtaining the hash value H1, and calculating a hash value H2 according to the random number RX and the TEXT segment included in the second domain, and comparing The H1 and H2 determine that the audit is passed when the H1 and H2 are the same and other information to be audited matches the audit rule.
The method of any of claims 19-22, wherein the computer system further comprises a first random number generator deployed in the first domain and a second random number generator deployed in the second domain;

The method further includes:

When the program is executed, calling the first random number generator in the first domain to generate a random number, and writing the random number to a third register of the tracker;

corresponding:

The obtaining the information to be audited by the tracker includes: acquiring the information to be audited collected by the tracker, where the information to be audited further includes a random number, wherein the random number is the tracker accessing the first Three registers are obtained;

The auditing the information to be audited according to the auditing rule includes: acquiring a last random number RY generated by the first random number generator during execution of the program, and acquiring a random preset in the second domain Counting the number of occurrences n; triggering the second random number generator according to the n to generate n random numbers, and comparing the nth random number Rn with the RY, when the Rn is the same as the RY and other The audit is determined when the audit information matches the audit rules.
A computer readable storage medium, comprising computer readable instructions for implementing the method of any one of claims 19-24 when the computer readable instructions are executed by one or more processors .
A computer program product, comprising computer readable instructions for implementing the method of any one of claims 19-24 when the computer readable instructions are executed by one or more processors.