WO2019095911A1 - 一种抵御拒绝服务攻击的方法及设备 - Google Patents

一种抵御拒绝服务攻击的方法及设备 Download PDF

Info

Publication number
WO2019095911A1
WO2019095911A1 PCT/CN2018/110296 CN2018110296W WO2019095911A1 WO 2019095911 A1 WO2019095911 A1 WO 2019095911A1 CN 2018110296 W CN2018110296 W CN 2018110296W WO 2019095911 A1 WO2019095911 A1 WO 2019095911A1
Authority
WO
WIPO (PCT)
Prior art keywords
access
service
interface
access request
terminal device
Prior art date
Application number
PCT/CN2018/110296
Other languages
English (en)
French (fr)
Inventor
谢淼
姚英亮
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP18877968.0A priority Critical patent/EP3694170B1/en
Publication of WO2019095911A1 publication Critical patent/WO2019095911A1/zh
Priority to US16/870,203 priority patent/US20200274898A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1458—Denial of Service
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/554—Detecting local intrusion or implementing counter-measures involving event detection and direct action
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1425—Traffic logging, e.g. anomaly detection

Definitions

  • the present application relates to the field of security, and more specifically to a method and apparatus for defending against a Denial of Service (DoS) attack.
  • DoS Denial of Service
  • REE Rich Execution Environment
  • REE is also called a general operating environment, and mainly includes Rich Operating System (Rich OS) running on a general purpose processor, such as The operating system, and the client application (CA) running on the Rich OS.
  • Rich OS Rich Operating System
  • CA client application
  • TEE is a stand-alone operating environment that runs outside of REE and is isolated from REE.
  • Each Trusted Application (TA) running in the TEE is independent, and the TA cannot access unauthorized resources of another TA.
  • the CA in the REE cannot directly access the hardware and software security resources of the TEE, so it can resist software attacks on the REE side.
  • the CA in the REE can call a specific application programming interface (API) to call TEE resources or services, such as cryptographic operations and storage, or access data of the TA running in the TEE. .
  • API application programming interface
  • TEE attempts to prevent attacks on the REE side through hardware isolation, thus ensuring the security of sensitive data
  • TEE is essentially a public security "platform".
  • TA and CA are TEE applications, and the entire TEE Need to provide them with essential services.
  • TEE has gradually become an important cornerstone for protecting REE side applications and data security, which determines the security level of terminal equipment to a certain extent.
  • the malicious application can easily use the existing interface to frequently invoke the service on the TEE side.
  • a Denial of Service (DoS) attack may occur, resulting in unavailable services on the REE side and the TEE side, or even a device restart. It can be seen that the current terminal device (the REE side and the TEE side) is more likely to have a DoS attack, which seriously threatens the security of the terminal device.
  • DoS Denial of Service
  • the present application provides a method for defending against a Denial of Service (DoS) attack, and a device for implementing the method, so as to reduce the probability of occurrence of DoS inside the device and ensure the safe operation of the device.
  • DoS Denial of Service
  • the embodiment of the present application provides a method for defending against a DoS attack, which can be applied to a terminal device or other similar device including a trusted execution environment TEE and a rich execution environment REE, wherein a client application CA runs in the REE.
  • the method includes: obtaining an access request initiated by a CA to a service/interface, the service/interface being a service or interface provided by the REE or the TEE, the CA initiating the access request by using the service/interface Requesting a service or a resource; transmitting the access request to a defense module deployed in the TEE through a message delivery mechanism in the terminal device; the defense module determines whether to authorize the access request according to a management policy; wherein the control policy Is determined according to the access behavior model; the access behavior model is obtained by training the access behavior data set by a statistical method or a machine learning algorithm, and is used for characterizing behavior characteristics of the at least one CA accessing the service/interface, wherein The access behavior data set includes the at least one CA collected in the TEE accessing the service/connection The access behavior logs.
  • the method provided by the embodiment of the present application utilizes an access behavior feature model to determine a management policy, and the module is further controlled and controlled based on the management policy, so that the access request with potential DoS attack threat can be accurately identified and blocked, and the device is improved.
  • Security Since the access behavior data set used by the training access behavior feature model is collected in the TEE, the behavior data can be prevented from being tampered, the authenticity of the data sample and the accuracy of the access behavior model are ensured, and the defense module is also deployed in the TEE. Internally, it guarantees its own security.
  • the CA that initiates the access request is first authenticated inside the TEE, and the CA fails to pass the identity authentication. In case, the access request is blocked; in case the CA passes the identity authentication, the access request is further passed to the defense module for further control. In this way, the access request can be initially authenticated in advance to reduce the load on the module and prevent the module from becoming a performance bottleneck.
  • the access behavior data set may be collected by an access behavior data collector deployed in the TEE to ensure the reliability of the access behavior data and prevent tampering by the REE side malicious program.
  • the access behavior data collector records a plurality of access behavior logs corresponding to the multiple access requests initiated by the at least one CA to the service/interface; according to the multiple access behavior logs Constructing the access behavior data set.
  • the access request may also be delivered to the access behavior data collector, where the access behavior data collector records the access corresponding to the access request.
  • the behavior log and incrementally update the access behavior data set; the access behavior model trained based on the updated access behavior data set will become more and more precise, thereby implementing iterative optimization of the management strategy.
  • the management policy includes a threshold of at least one management parameter; the at least one management parameter is determined according to the access behavior model; and the threshold of the at least one management parameter is based on a DoS attack defense
  • the capability analysis formula is obtained by solving the minimum resource required for completing the DoS attack beyond the rigid index; wherein, the DoS attack resilience analysis formula represents the minimum resource amount and the control parameter required to complete the DoS attack.
  • the constraint relationship is related to the hardware resource limitation of the terminal device, or the limitation of the operating system, or the limitation of the service scenario. The minimum amount of resources required to complete a DoS attack exceeds the rigid metric, which means that the probability of a DoS attack is 0.
  • the threshold of the control parameters solved by the DoS attack resilience analysis formula can minimize the probability of a DoS attack.
  • the control parameters are more precise, and the probability of DoS attacks initiated against the to-be-protected service/interface in the terminal device is the lowest.
  • the defense module determines, according to the access request, and the management policy, whether to authorize the access request, if the access request triggers the at least one management parameter to exceed the threshold, The access request is blocked, otherwise the access request is authorized.
  • This threshold-based management method has a small computational overhead and therefore has less impact on system performance.
  • the defense module notifies or reminds the user to decide whether to authorize the access request; if the user authorizes the access request, according to the access request
  • the behavior log is accessed, and the access behavior model is updated by an enhanced learning algorithm to obtain an updated access behavior model.
  • the access behavior model can be corrected in time to improve the accuracy of the access behavior model.
  • the management policy can be updated according to the updated access behavior model, thereby implementing dynamic adjustment of the management policy to improve the accuracy of the access request management and control.
  • the access behavior log collected by the access behavior data collector includes: information of an originating entity of each of the plurality of access requests, and each of the plurality of access requests a timestamp, a quantity of resources involved in each of the plurality of access requests; the at least one control parameter includes at least one of the following: a time interval in which the same CA accesses the service/interface twice, and the same CA holds The number of resources associated with the service/interface and the time at which the same CA holds the resources associated with the service/interface.
  • the access behavior data collector collects and collects these key information that can be used to discriminate DoS attack behavior, and the amount of data collected is small, and the resource consumption on the TEE side is small.
  • a trusted application TA is run in the TEE, and the access request is used to open a session with the CA in the TA;
  • the at least one control parameter includes at least the following One: the time interval between the same CA accessing the service/interface twice, the number of sessions held by the same CA with the TA, and the time of the session held by the same CA with the TA.
  • the threshold of the at least one control parameter includes: a time interval threshold for the same CA to access the service/interface twice; and determining, by the defense module, whether to authorize the access request according to the management policy includes: Calculating a time interval at which the CA initiates the access request and a last access request initiated by the CA to the service/interface; when the calculated time interval is less than the time interval threshold, the defense module blocks the An access request; the defense module authorizes the access request when the calculated time interval is greater than the time interval threshold.
  • the threshold of the at least one control parameter includes: an upper limit value of a number of sessions held by the same CA and the TA; the defense module determines whether to authorize the according to a management policy
  • the access request includes: determining, according to the current request status of the CA, the number of sessions that the CA has held with the TA; and when the determined number of sessions is greater than or equal to the upper limit, the defense The module blocks the access request; when the determined number of sessions is less than the upper limit, the defense module authorizes the access request.
  • the embodiment of the present application provides a method for generating a management policy, where the management policy is used to control an application to initiate an access request to a service/interface in a terminal device, where the terminal device includes a trusted execution environment TEE and a rich execution Environment REE, the method comprises: obtaining an access behavior model by using a machine learning algorithm according to the access behavior data set; wherein the access behavior data set is collected by an access behavior data collector deployed in the TEE, including one or more CA accesses An access behavior log of the service/interface, the access behavior model is used to describe an access behavior feature of the one or more CAs; determining a control parameter according to the access behavior model, and solving a control parameter according to a DoS attack resilience analysis formula The constraint condition is generated according to the constraint condition of the control parameter; wherein the DoS attack resilience analysis formula is used to indicate the constraint relationship between the minimum resource quantity required for completing the DoS attack and the control parameter.
  • the constraints of the control parameters solved by the DoS attack resilience analysis formula can minimize the probability of occurrence of DoS attacks. Compared with the scheme of determining the constraints of the control parameters directly through the access behavior model, the control parameters are more accurate and can guarantee The probability of a DoS attack initiated by the terminal device for the to-be-protected service/interface is the lowest.
  • the minimum amount of resources required to complete a DoS attack may be the number of applications that need to run simultaneously on the terminal device, or the size of the shared memory needs to be occupied, or needs to run simultaneously on the terminal device. The number of processes or threads, etc.
  • the constraint condition for solving the control parameter according to the DoS attack resilience analysis formula includes: based on the DoS attack resilience analysis formula, the minimum resource required to complete the DoS attack exceeds the rigid index (ie, a DoS attack occurs) Under the premise that the probability is 0), the value of the control parameter is solved.
  • the solved value can be used as a constraint for the control parameters.
  • the rigidity indicator is related to the limitation of the hardware resources of the terminal device, or the limitation of the software (such as an operating system), or the limitation of the service scenario.
  • the stiffness indicator can be the number of applications, processes, or threads that can run simultaneously on the terminal device.
  • control parameters include: a predefined normal CA holds a maximum hold time b of a resource related to the service/interface to be protected, and a predefined normal CA accesses the service/interface to be protected twice.
  • Minimum time interval a the upper limit of the number of resources related to the service/interface to be protected by the same CA during the access process.
  • ⁇ is a soft/hardware resource threshold directly related to the limitation of the hardware resources of the terminal device, or the limitation of software (such as an operating system), or the limitation of the service scenario.
  • the constraint condition of the control parameter is the value of the control parameter, or a range of values.
  • the management strategy is obtained by converting the constraints of the control parameters.
  • the method for generating a management policy provided by the second aspect of the present application may be implemented separately, or may be implemented in combination with the foregoing method for defending against DoS attacks, that is, the generated management and control policy may be applied to the first aspect to defend against DoS attacks. In the method, the precise control of the access request is realized.
  • the embodiment of the present application provides a terminal device, including one or more functional units for performing the method described in any one of the foregoing first to second aspects, which may be implemented by a software module. Or implemented by hardware, such as a processor, or by software combined with the necessary hardware.
  • an embodiment of the present application provides a terminal device, including a memory, a processor, and a computer program stored on the memory, where the first aspect to the second aspect are implemented when the processor executes the computer program The steps of the method described in any of the aspects.
  • an embodiment of the present application provides a computer readable storage medium, where a computer program (instruction) is stored, and the program (instruction) is executed by a processor to implement any one of the foregoing first aspect to the second aspect. The steps of the method described.
  • the embodiment of the present application provides a method for defending against a denial of service DoS attack in a server, where the server includes a security domain and a non-security domain, and the non-security domain runs a client application CA.
  • the method includes: obtaining an access request initiated by the CA to a service/interface, where the service/interface is an interface provided by the security domain or the non-secure domain, and the CA accesses the service by using the service /interface to request a resource or service; pass the access request to an access behavior data collector deployed in the security domain; the access behavior data collector passes the access request to a defense module deployed in the security domain; Determining, by the defense module, whether to authorize the access request according to the access of the access request, and a management policy; wherein the management policy is determined according to an access behavior model; the access behavior model is a statistical method or machine learning
  • the algorithm is obtained by training the access behavior data set to characterize the behavior characteristics of the CA-initiated access request.
  • the access behavior data set
  • the present application can reduce the probability of occurrence of a DoS attack inside the device and ensure the safe operation of the device.
  • FIG. 1 is a schematic diagram of a terminal device according to an embodiment of the present application.
  • FIG. 2 is a schematic diagram of a terminal device according to an embodiment of the present application.
  • FIG. 3 is a schematic diagram of a process of a method for resisting a denial of service (DoS) attack according to an embodiment of the present application.
  • DoS denial of service
  • FIG. 4 is a flowchart of a method for defending against a DoS attack according to an embodiment of the present application.
  • FIG. 5 is a schematic diagram of interaction between a client application and a trusted application in the embodiment of the present application.
  • FIG. 6 is a schematic diagram of a process of a method for defending against a DoS attack according to an embodiment of the present application.
  • FIG. 7 is a schematic diagram of data collection of access behavior according to an embodiment of the present application.
  • FIG. 8 is a schematic diagram of a training process of an access behavior model according to an embodiment of the present application.
  • FIG. 9 is a schematic diagram of a process of generating a management and control policy according to an embodiment of the present application.
  • FIG. 10 is a schematic diagram of a terminal device according to an embodiment of the present application.
  • FIG. 11 is a schematic diagram of a terminal device according to an embodiment of the present application.
  • FIG. 12 is a schematic diagram of a server in an embodiment of the present application.
  • the embodiment of the present invention provides a method for defending against a Denial of Service (DoS) attack to identify and prevent a malicious program from initiating a DoS attack initiated by a specific interface or service in a device to improve device security.
  • DoS Denial of Service
  • the method provided by the present application can be typically applied to a terminal device or can also be applied to a computer system such as a server.
  • the terminal device according to the embodiment and the claims of the present application points to a device for providing voice and/or data connectivity, including a wireless terminal or a wired terminal.
  • the wireless terminal can communicate with one or more core networks via a radio access network (RAN), which can be a mobile terminal, such as a mobile phone (or "cellular" phone) and a computer with a mobile terminal For example, it can be a portable, pocket, handheld, computer built-in or in-vehicle mobile device.
  • RAN radio access network
  • An interface also known as an Application Programming Interface (API)
  • API Application Programming Interface
  • a service is an application component that can be executed in the background without providing a user interface, and the service can be launched by other applications or application components.
  • FIG. 1 is a schematic structural diagram of a terminal device 100 according to an embodiment of the present application.
  • the terminal device 100 includes a hardware platform 110, and two operating environments that are isolated from each other on the hardware platform 100, that is, a rich execution environment ( Rich Execution Environment, REE) 120 and Trusted Execution Environment (TEE) 140.
  • the two operating environments have separate hardware resources and operating systems.
  • Through hardware isolation techniques, such as The TrustZone mechanism can isolate the hardware resources of REE 120 and TEE 140, and realize the isolation between the operating systems of REE 120 and TEE 140 and the applications through virtualization technology.
  • the REE 120 is an operating environment outside of the TEE 140.
  • the REE 120 is less secure than the TEE 140 and is an easy to attack environment, while applications running on the REE 120 are considered untrustworthy.
  • the application 155 running in the TEE 140 is a Trusted Application (TA), and the TA 155 can provide security-related for client applications (CAs) outside the TEE 140 or other TAs within the TEE 140. Feature or service.
  • TA Trusted Application
  • the CA running in the REE 120 can utilize the TEE external interface 125 to request the security services provided by the TA 155 in the TEE 140.
  • a Trusted Operating System (Trusted Operating System) 143 running in the TEE 140 provides a TEE internal interface 145 to the TA 155.
  • the TA 155 obtains access rights to security resources and services through the TEE internal interface 145. These security resources and services These include but are not limited to: key injection and management, encryption, secure storage, secure clocking, trusted user interface (UI), and trusted keyboard.
  • Rich Operating System (Rich OS) 123 in REE 120 offers a wider range of features than Trusted OS 143 in TEE 140. Rich OS 123 is very open and accepts all types of applications, but its security Also lower than Trusted OS 143. Rich OS 123 can be Such as the terminal operating system.
  • the hardware platform 110 of the terminal device 100 includes a common peripheral device 121 and a trusted peripheral device 141, and the Rich OS 123 and the trusted operating system 143 respectively include a common peripheral driver 127 and trusted Peripheral drive.
  • the trusted peripheral 141 includes a Secure Element (SE) that can only be controlled and accessed by the TEE 140, such as a secure memory, a secure clock, a trusted keyboard, and the like.
  • SE Secure Element
  • the public peripheral 121 is a device that can be controlled and accessed by the Rich OS 123 in the REE 120.
  • the TEE external interface 125 in FIG. 1 may specifically include a TEE functional interface (TEE functional API) 127 and a TEE client interface (TEE client API) 126.
  • the TEE function interface 127 provides a set of Application Programming Interfaces (APIs) to the CA 113 in the REE 120.
  • the CA 113 can invoke partial TEE services, such as encryption and decryption operations or secure storage, through the TEE function interface 127.
  • the TEE client interface 126 is a low level communication interface designed to enable the CA 113 running in the Rich OS 123 to access and exchange data for the trusted application 115 running in the TEE 140.
  • a REE communication agent 129 and a TEE communication agent 145 are deployed in the REE 120 and the TEE 140, respectively, to support message interaction between the CA 113 and the TA 115.
  • the REE communication agent 129 and the TEE communication agent 145 work in tandem and provide security for message interaction between the CA 113 and the TA 115 using the underlying message routing mechanism.
  • the embodiment of the present application provides a method for defending against a DoS attack in the terminal device 100.
  • the DoS attacks occurring inside the terminal device 100 generally have the following characteristics:
  • the DoS attack initiator is an application running directly on the terminal device, such as a CA, or other application on the REE side;
  • “Resist the DoS attack in the terminal device” includes: (1) a service or interface to be protected for the REE 120 and/or the TEE 140 side, such as a TA Open Session interface, so that all predefined ones are A normal CA (for example, a certain CA set) can be accessed smoothly without a denial of service problem; (2) a blocking/interrupting call of a malicious CA to protect the service or interface, where the "to-be-protected service or interface” is the embodiment of the present application.
  • the target object to which the method is targeted may be a TEE internal interface 143 or a TEE external interface 125, such as a TEE functional interface 127 and/or a TEE client interface 126; the to-be-protected service may be a TEE side and/or a REE side service.
  • the method for defending against DoS attacks provided by the embodiments of the present application can also be applied to other types of computer systems, such as a server with a dual domain system (security domain and non-security domain), and a data center. Wait.
  • FIG. 3 shows the functional entities and main steps involved in the method for defending against denial of service attacks provided by the embodiments of the present application.
  • the method for defending against a denial of service attack provided by the embodiment of the present application includes three phases: (1) a data acquisition phase of an access behavior of a client application (CA) (hereinafter referred to as a “data collection phase”); 2) CA behavior model training phase (hereinafter referred to as “model training phase”); (3) CA access behavior management and control phase (hereinafter referred to as "management phase”).
  • the data collection phase and the model training phase are usually performed offline, that is, sample data collection and model training are performed during system software development and deployment before the terminal device operating system is released. It should be understood that in the specific implementation of the solution, these three phases are not completely serially executed.
  • the access behavior data sample of the CA to be protected service/interface 10 needs to be collected as an input of the model training phase, and the collected access behavior data samples are trusted to be reflected in the real business scenario.
  • Access behavior characteristics when the CA accesses the service/interface 10 to be protected Therefore, the embodiment of the present application configures the access behavior data collector 134 in the TEE 140 to ensure the security of the access behavior data collection and prevent the access behavior data from being tampered with by the malicious program on the REE 120 side.
  • the access behavior data collector 134 constructs an access behavior data set 138 by collecting an access behavior log when one or more normal CAs access the service/interface 10 to be protected.
  • the "normal CA" here is relative to a malicious CA that is likely to launch a DoS attack.
  • a normal CA usually refers to a reliable CA that is predefined by the user or application developer or detected by security.
  • the service/interface 10 to be protected may be a service or interface of the REE, or may be a service or interface of the TEE. If the to-be-protected service/interface 10 is deployed in the REE 120, the to-be-protected service/interface 10 forwards the access request initiated by the CA to the key resource access agent 130 in the REE, and the key resource access agent 130 is an agent. It is responsible for forwarding access requests from the service/interface to be protected to the critical resource request interface 132 deployed in the TEE 140.
  • the key resource application interface 132 is responsible for authenticating the identity of the initiating entity of the received access request.
  • the critical resource application interface 132 forwards the access request to the access behavior data collector 134 deployed in the TEE 140.
  • the data collector 134 records the access behavior log corresponding to the access request. If the to-be-protected service/interface 10 is deployed in the TEE 140, the access request of the CA can be directly sent by the to-be-protected service/interface 10 directly to the key resource application interface 132 on the TEE side without going through the critical resource access agent 130.
  • the behavior modeler 150 uses the access behavior data set 138 as a data source to train the access behavior required by the DoS attack analyzer 160 through statistical methods and/or machine learning methods, such as maximum likelihood estimation methods.
  • a model that can characterize the access behavior of the normal CA to the protected service/interface 10, such as the time interval between two accesses to be protected service/interface 10, and the key associated with holding the service/interface 10 to be protected during the access process The number of resources, etc.
  • Model training includes model establishment and tuning of model parameters.
  • the trained access behavior model or model parameters are stored for use in the control phase.
  • the process of training the access behavior model based on the access behavior data set 138 can be implemented using a variety of prior art techniques and will not be described in detail herein.
  • the DoS attack analyzer 160 utilizes its built-in DoS attack resilience analysis formula, takes the access behavior model outputted by the behavior modeler 150 as an input, and solves the control parameters required by the defense module 170 to obtain a control strategy.
  • the control policy is used to indicate constraints that the control parameters need to meet, and may include a threshold or a range of values of at least one control parameter.
  • the governance policy can be translated into decision logic and executed by the defense module 170.
  • the resource request interface 132 sends the access request to the access behavior data collector 134, which forwards the access request to the defense module 170, and the defense module 170 authorizes or blocks the access request according to the governance policy.
  • the key resource request interface 132 and the defense module 170 block the access request can be implemented in various manners. For example, a command, message or parameter may be returned to the service/interface 10 to be protected to indicate that the service/interface 10 to be protected rejects the access request; or a system function or interface may be invoked to reject the access request.
  • the critical resource application interface 132 may also directly send the access request to the defense module 170 instead of being forwarded by the access behavior data collector 134.
  • the defense module 170 is deployed in the TEE 140, and utilizes the security mechanism of the TEE 140 itself to protect itself and the security and confidentiality of the management policy from being damaged.
  • the defense module 170 relies on a small number of management parameters to control the access request for the interface to be protected, so as to reduce the probability of a denial of service attack in the terminal device and ensure the safe operation of the terminal system.
  • the behavior data collector 134 does not need to collect the full amount of access behavior data of the normal CA, and can collect part of the behavior data according to the requirements of the management and control to reduce the system resource overhead.
  • the behavior data collector 134 may determine the type of the access behavior log that needs to be collected according to the root cause of the DoS attack occurring inside the terminal device 100, and access multiple to-be-protected services/interfaces 10 in the data collection phase. Part of the access behavior log is recorded in the system, ultimately outputting the access behavior data set 138 required by the offline process.
  • the types of access behavior logs that need to be collected include logs that record the key behavior characteristics when the CA accesses the service/interface to be protected.
  • the key behavior characteristics here are the behavior characteristics of the CA that can distinguish between the normal CA and the potential DoS attack.
  • the access behavior log collected by behavior data collector 134 includes characteristics of the time dimension and resource dimension of the CA in accessing the service/interface 10 to be protected.
  • the characteristics of the time dimension include, but are not limited to, one or more of the following: a timestamp of the CA accessing the service/interface, a time interval between the same CA accessing the service or the interface, and the CA holding the resource related to the service or the interface.
  • Time (the time difference between the CA requesting the critical resource and the CA to release the resource); the characteristics of the time dimension include but are not limited to one or more of the following: the number of resources related to the service/interface held by the CA during the access process.
  • the service/interface related resources include the system resources occupied by the functions implementing the service/interface, or the system resources available to the application by accessing or calling the service/interface, such as sessions, CPU, memory, and the like.
  • the behavior data collector 134 records the access behavior log of each CA during the process of accessing or invoking the to-be-protected service/interface 10 by a plurality of normal CAs, and finally outputs the access behavior data set 138.
  • the raw data collected by the behavioral data collector 134 may be stored in a memory, or the raw data may be cleaned/processed and then stored in the memory.
  • Data cleaning refers to the process of re-examining and verifying data by a computer to remove duplicate information, correct existing errors, and provide data consistency.
  • Data processing refers to the processing of data type, format, etc., or mathematical transformation of data.
  • the access behavior data set 138 contains an access behavior log for each normal CA.
  • the behavior modeler 150 performs feature extraction on the access behavior data set 138, converts the extracted features into feature vectors that can be processed by the machine learning algorithm, and then trains the access behavior model using a machine learning algorithm, such as a softmax algorithm.
  • the access behavior model characterizes behavioral characteristics or laws of access requests initiated by normal CAs.
  • the DoS attack analyzer 160 determines the control parameters based on the access behavior model, and calculates the constraint conditions of the control parameters based on the DoS attack resilience analysis formula to form a management control strategy.
  • the collected access behavior data set 138 may be divided into multiple categories from one dimension or multiple dimensions before the behavior modeler 150 performs model training.
  • the categories train their respective access behavior models.
  • the data set may be divided according to the dimension of the CA, that is, the access behavior log of each CA is used as a classification; or the data set may be divided according to the dimension of the business scenario, that is, the access behavior log of all normal CAs in the same business scenario is taken as one classification.
  • the behavior log of the same CA to call the same service/interface may be different in different service scenarios.
  • the collection of behavior data and modeling in different service scenarios can more accurately reflect the call behavior characteristics of CA in different scenarios.
  • the behavior data collector 134 can perform necessary remarks on the access behavior log of the CA during the data collection phase, for example, recording the identity and/or service scenario of the CA corresponding to the access behavior log. . In this way, machine learning is performed on each of the classified classifications, and a plurality of access behavior models (or model parameters) corresponding to the plurality of classifications can be obtained.
  • the DoS attack analyzer 160 trains the output access behavior model (or model parameters) according to the behavior modeler 150 to determine the control parameters required to defend against the DoS attack, and the initial constraints of the control parameters, wherein the constraints may be a specific one. Value, or a range of values.
  • the control parameters may indicate partial access behavior characteristics, such as time or resource dimension characteristics, when the CA accesses the service/interface to be protected.
  • the control parameters may include a time interval for accessing the service/interface to be protected, a number of resources occupied or held when accessing the service/interface to be protected, a time when the resource is held or occupied, and the like.
  • the CA is considered to be a normal CA, that is, the probability of initiating a DoS attack is low, otherwise the CA is considered to be a potential meeting.
  • a malicious CA that initiates a DoS attack.
  • the initial constraints based on the governing parameters are used directly to determine the likelihood of a DoS attack, and accuracy may not be guaranteed. That is to say, even if the control parameters corresponding to the CA satisfy the initial constraints of the control parameters, the probability of occurrence of a DoS attack cannot be guaranteed to be minimal.
  • the DoS attack analyzer 160 can optimize the constraints of the control parameters based on the DoS attack resilience analysis formula to minimize the probability of a DoS attack.
  • the DoS attack resilience analysis formula is used to indicate the constraint relationship between the minimum resource required to complete the DoS attack and the control parameters.
  • the minimum amount of resources required to complete a DoS attack can be the number of malicious programs that need to be run simultaneously on the terminal device, or the size of the shared memory. Because the hardware and software resources of the terminal device are limited, if the minimum resource required to complete the DoS attack exceeds a certain rigid indicator related to the hardware resource limitation of the terminal device or the limitation of the software (such as the operating system), it represents a DoS attack.
  • the probability of occurrence is 0.
  • the DoS attack resilience analysis formula can evaluate the probability of occurrence of a DoS attack.
  • the different values of the control parameters correspond to the probability of occurrence of different DoS attacks.
  • the solution is performed.
  • the value of the control parameters is optimal.
  • the DoS attack analyzer 160 can be based on the DoS attack resilience analysis formula, and solve the value of the control parameter under the premise that the minimum resource required to complete the DoS attack exceeds the rigid index (ie, the probability of occurrence of the DoS attack is 0).
  • the solved value can be used as a constraint for optimizing the control parameters.
  • the DoS attack analyzer 160 may generate a corresponding management policy according to the optimized constraints of the control parameters.
  • the defense module 170 manages access requests for the service/interface to be protected based on the governance policy.
  • control behavior model is trained according to the behavior modeler 150 to determine the control parameters as:
  • the DoS attack resilience analysis formula of the terminal device may be a calculation formula for calculating the lower limit value of the resource Y required to complete the DoS attack, for example, may be:
  • ⁇ is a rigid indicator.
  • the control parameters are solved and calculated, and the constraints of the control parameters (after optimization), such as the range of control parameters, thresholds, etc., can be obtained.
  • the constraint of the control parameter can be converted into a control policy or the decision logic is solidified in the defense module 170, and the defense module 170 performs security control on the access request for the to-be-protected service/interface based on the management policy.
  • the REE side CA initiates an access request to the REE or TEE side to be protected service/interface 10
  • the method for controlling the access request in the defense module 170 includes the following steps:
  • Step 401 The CA 113 on the REE side initiates an access request to the protection service/interface 10.
  • Step 403 After the to-be-protected service/interface 10 encapsulates the access request, the information along with the originating entity of the request (ie, the CA 113 in step 401) is passed to the key resource accessing agent 130 on the REE side.
  • Step 405 The key resource accessing agent 130 transmits the information of the access request and the request initiating entity (ie, CA 113) to the key resource application interface 132 on the TEE side through the program interface deployed on the REE side of the TEE side.
  • the request initiating entity ie, CA 113
  • Step 407 The key resource application interface 132 performs identity authentication on the request originating entity, and correspondingly sends the access request to the access behavior data collector 134 under the condition of identity authentication, and the access behavior data collector 134 stores the access request correspondingly. Access behavior log.
  • Step 409 The access behavior data collector 134 passes the access request along with the current request status of the entity from the request to the defense module 170 on the TEE side.
  • the access behavior data collector 134 also records an access behavior log corresponding to the access request to update the access behavior data set 138.
  • Step 411 The defense module 170 decides whether to authorize the current access request according to the management policy, and after the defense module 170 makes a decision to authorize or block the access request according to the management policy, the feedback result is fed back to the to-be-protected service/interface through the critical resource application interface 132. 10.
  • the service/interface 10 to be protected responds to the current access request based on the decision result, or rejects the access request.
  • the to-be-protected service/interface 10 can directly send the access request directly to the access behavior data collector 134. There is no need to access the proxy and critical resource request interfaces through critical resources.
  • the governance policy includes the time when the same CA accesses the service/interface twice.
  • the defense module 170 then calculates a time interval at which the CA 113 initiates the access request and the last access request initiated to the service/interface; when the calculated time interval is less than the time interval threshold, the defense module 170 blocks the An access request; the defense module 170 authorizes the access request when the calculated time interval is greater than the time interval threshold.
  • the defense module 170 blocks the access request, otherwise the defense module 170 authorizes the access request.
  • the method may further include:
  • Step 413 After the defense module makes a decision to block the current access, the user feedback mechanism may be used to request the user to decide whether the access subject is trusted. If it is trusted, the current request is authorized, and the behavior model corrector 151 is adopted. The request information is recorded, and the access behavior model and the control strategy are refreshed by methods such as enhanced learning. Since the access behavior model is trained in the offline process, it is based on the access behavior data set 138, which is a sample of the access behavior data of the normal CA accessing the service/interface to be protected, and thus may be deviated from the actual access behavior. The function of the behavior model corrector 151 is to judge whether the access behavior model deviates from the actual access behavior through the behavior log data captured in real time.
  • the access behavior model will be updated through the online learning method, and the DoS attack analysis is performed.
  • the controller 160 updates the management policy according to the updated access behavior model.
  • the defense module 170 will control subsequent access requests based on the updated management policy.
  • the embodiment of the present application deploys a behavior data collector on the TEE side, collects access behavior logs of multiple predefined normal CAs to access the service/interface 10 to be protected, and outputs an access behavior data set to ensure data collection of the access behavior log. Credibility. Further, based on the machine learning method, the probability distribution of the limited access behavior parameters of the normal CA or its upper and lower limits is learned, the effective access behavior model is trained, and the precise control strategy is determined according to the access behavior model, and then treated based on the management strategy The access request on the protection service/interface is controlled, so as to timely defend against the DoS attack initiated by the service/interface to be protected, and the security of the terminal device is improved.
  • FIG. 5 shows a flow chart of interaction between a CA in a REE and a TA in a TEE in this embodiment, involving an InitializeContext, an OpenSession, an InvokeCommand, and a CloseSession. There are 5 main processes such as ending the context (FinalizeContext).
  • the CA invokes the OpenSession interface to cause the specified TA to open a session with the CA, that is, the Session, and the operation of the CA to subsequently invoke a certain service of the TA is performed in the context specified by the Session. Therefore, in the TEE, due to the limitation of computing resources, the CA cannot be allowed to open the session of a certain TA without restriction, otherwise the DoS attack may be caused. If the upper limit of the number of Sessions that a CA can open at the same time is pre-defined, the occurrence of a DoS attack cannot be avoided, and the predefined normal CA cannot be successfully accessed.
  • the specified upper limit is too small, it is more susceptible to DoS attacks and cannot meet the requirements of normal CA; if the specified upper limit is too large, the resource consumption may be large, the TEE system resources are difficult to bear, and it is easy to collapse, which in turn leads to The system refused service. Therefore, a unified threshold is difficult to set, even if it is set, there is no evidence to follow, it is difficult to resist DoS attacks.
  • CAs that access the OpenSession interface are mostly developed by third parties.
  • FIG. 6 we take three CAs as examples to form a predefined normal CA: fingerprint CA, digital certificate CA, and security keyboard CA.
  • Figure 6 shows the deployment of key components that implement the DoS functionality in the application embodiment.
  • the OpenSession interface to be protected is in the TEE Client API library of the REE side user state. Any CA can invoke the OpenSession interface.
  • the TEE side relies on the authentication model to authenticate the identity of the CA. However, because the REE side is a non-secure side, malicious.
  • the CA can bypass the TEE side identity authentication mechanism by spoofing identity information.
  • the key resource access agent 130 is responsible for packaging the predefined normal CA initiated OpenSession request into a Secure Monitor Call (SMC) command to the TEE side Global Task module 142.
  • SMC Secure Monitor Call
  • the key resource access agent 130 is a kernel-state process or thread, and its function can be undertaken by the Tzdriver component in the kernel.
  • the Global Task module is a core module of the TEE side access processing, and implements the functions of the key resource application interface 132 and the access behavior data collector 134 in the foregoing embodiment of the present application.
  • the Global Task module 142 includes the CA authentication model. After the CA passes the identity authentication, the access behavior data of the CA is recorded to form an access behavior log, which is stored in the persistent storage medium.
  • these access behavior logs are exported to obtain an access behavior data set 138 for the OpenSession interface.
  • the behavior modeler 150 uses the access behavior data set as a data sample, the behavior modeler 150 derives an access behavior model that can be trained to characterize a predefined normal CA access behavior, and finally the DoS attack analyzer 160 determines the management strategy based on the access behavior model.
  • the firmware is cured in the defense module 170, and the defense module 170 performs security management on the access request for the OpenSession interface based on the management policy.
  • the key resource accessing agent 130 will send a corresponding SMC request to the Global Task module 142. If the CA passes the identity authentication of the Global Task module 142, the current access of the CA is obtained. The status is sent to the defense module 170, and if the defense module 170 authorizes the access according to the governance policy, then the corresponding TA is invoked to perform the open session operation and the session handle is returned to the CA. If the defense module 170 rejects the access, the user may be notified in the form of a dialog box to decide whether to authorize the current access.
  • the defense module 170 prevents the normal CA from running, so the misjudgment, then Global
  • the task module 142 records the current access behavior data and passes it to the behavior model corrector 151.
  • the corrective process will be initiated to Re-learn the access behavior model and generate new management strategies to reduce system error rates.
  • one or more service scenarios in which a predefined normal CA invokes an OpenSession interface may be determined.
  • each normal CA call or access to the OpenSession interface is tested.
  • Global Task The module 142 records each access behavior data of each normal CA into the memory.
  • the Global Task module 142 can record and maintain the timestamp of each CA access OpenSession, the timestamp of the CloseSession, and each time the CA requests the session. The number of Sessions held, and so on.
  • the recorded access behavior data can be exported in batches, and then calculated separately: (1) the access interval J of the same CA twice calling the OpenSession interface; (2) the length of time that the CA holds the session L, that is, The length of time that the key resources involved in the OpenSession interface are involved. (3) The same CA holds the number of sessions m during the access process.
  • These parameters can describe the behavior characteristics of each normal CA accessing the OpenSession interface in a specific service scenario. Therefore, based on the calculated parameters, a minimum behavior log set of each normal CA in each service scenario can be constructed. The result is a set of access behavior data sets.
  • the behavior modeler 150 can traverse the set of access behavior logs recorded by the Global Task module 142 when each Open Normal CA (such as the fingerprint CA, the digital certificate CA, the security keyboard CA) is called when the OpenSession interface is invoked.
  • each Open Normal CA such as the fingerprint CA, the digital certificate CA, the security keyboard CA
  • the access behavior model of each normal CA is trained by the machine learning method.
  • each data sample is independent and step by step. The statistical distribution of the time length L of the CA holding the Session and the interval J of the same CA calling the OpenSession interface twice satisfies the Gaussian distribution.
  • the learning of the access behavior model can be modeled as (taking the length L of the Session as an example) to solve the parameters u and ⁇ of the Gaussian distribution such that the probability of occurrence of the sampled value of L in the access behavior data set occurs. maximize.
  • the model f1 of the parameters u and ⁇ yields the probability of accessing the sampled value of L in the behavioral data set, which can be expressed as:
  • the maximum likelihood method is used to learn the distribution parameters of L and J, and the likelihood function is zeroed to obtain an approximate estimation expression of the parameter:
  • the access behavior model in each service scenario can be obtained, and the payment service scenario is taken as an example.
  • the obtained L, J model is:
  • u(L) 100ms
  • ⁇ (L) 30ms
  • u(J) 10s
  • ⁇ (J) 2s
  • the maximum value of m is 2.
  • the access behavior model parameters of each normal CA in each scenario can be obtained.
  • the DoS attack analyzer 160 determines one or more control parameters according to the access behavior model, and then uses its built-in DoS attack resilience analysis formula to solve the problem that the probability of occurrence of a DoS attack is the smallest. , the threshold or range of values of the control parameters.
  • the digital certificate CA as the payment service as an example
  • the thresholds for the control parameters are as follows:
  • the threshold of the control parameters is converted to a control strategy that is cured in the defense module 170.
  • the following control strategy can be transformed:
  • the above-mentioned management policy can be implemented in code and loaded into the defense module 170, and the defense module 170 can implement the control of the access request by executing the code.
  • FIG. 10 shows an example of another terminal device 200 provided by an embodiment of the present application.
  • the terminal device 200 includes a communication subsystem 210, a power source 220, an input device 230, a display device 240, a processing unit 250, and a memory 260.
  • the memory 260 stores computer programs or instructions including an operating system 294, an application 292, and the like.
  • Processing unit 250 is configured to execute a computer program in memory 260 to implement the computer program defined method, such as processing unit 250 running operating system 294 to implement various functions of the operating system on terminal device 200.
  • Processing unit 250 may include one or more processors, for example, processing unit 250 may include an application processor, a graphics processor, a digital signal processor, or the like. When the processing unit 250 includes a plurality of processors, the plurality of processors may be integrated on the same chip, or may each be a separate chip.
  • the memory 260 also stores other data 296 in addition to the computer program.
  • the other data 296 may include data generated during operation of the operating system 294 or application 292, such as system data (e.g., configuration parameters of the operating system 294) and user data.
  • Memory 260 generally includes memory and external memory.
  • Memory includes, but is not limited to, random access memory (RAM), read-only memory (ROM), or cache (cache).
  • the external memory includes, but is not limited to, a flash memory, a hard disk, a universal serial bus (USB) disk, etc., the computer program is usually stored on the external memory, and the processing unit 250 will execute the program from the computer program before executing the computer program. The external memory is loaded into memory.
  • the operating system 294 includes a computer program for implementing the method for defending against the DoS attack provided by the embodiment of the present application, so that the processor 250 runs the operating system 294 to implement the defense provided by the embodiment of the present application.
  • the steps of the DoS attack method may be in a computer program (instructions) The way, the processor 250 loads and runs these computer programs (instructions) to implement the respective functions of these modules.
  • the input device 230 is configured to receive user input information, such as digital/character information, touch operations or gestures, and generate corresponding input signals.
  • the input device 230 includes a touch panel.
  • a touch panel also known as a touch screen, collects touch operations on the user and generates touch signals to drive the relevant components in response to the user's actions.
  • the input device 230 may also include other input devices including, but not limited to, one or more of a physical keyboard, function keys (such as volume control buttons, switch buttons, etc.), trackballs, mice, joysticks, and the like. .
  • the display device 240 can be a display panel such as a liquid crystal display (LCD) or an organic light-emitting diode (OLED).
  • the touch panel can be overlaid on the display device 240 to form a touch display.
  • the communication subsystem 210 is a basic communication unit of the terminal 200 for data transmission and reception by the terminal 200.
  • the power source 220 is used to supply power to the above components, and specifically may be a power management chip.
  • the communication subsystem 210 includes a wireless modem, which mainly implements functions such as baseband processing, modulation and demodulation, signal amplification and filtering, and equalization.
  • communication subsystem 210 includes a baseband processor, a radio frequency circuit, and an antenna.
  • the RF circuit and the antenna are mainly responsible for signal transmission and reception;
  • the baseband processor is responsible for signal processing, such as signal A/D, D/A conversion, signal encoding and decoding, and the like.
  • the baseband processor supports one or more of the wireless communication standards, including but not limited to a global system for mobile communications (GSM), code division multiple access (code division multiple access,) CDMA), wideband code division multiple access (WCDMA), high speed packet access (HSPA), long-term evolution (LTE), and the like.
  • GSM global system for mobile communications
  • code division multiple access code division multiple access
  • WCDMA wideband code division multiple access
  • HSPA high speed packet access
  • LTE long-term evolution
  • the baseband processor can be a single chip or can be integrated into the same chip as the processor included in processing unit 250.
  • the terminal device 200 further includes one or more sensors 280, such as an acceleration sensor, a light sensor, and the like.
  • sensors 280 such as an acceleration sensor, a light sensor, and the like.
  • the method for defending against DoS attacks provided by the embodiments of the present application may be performed by a suitable combination of software, hardware, and/or firmware of the terminal device 200.
  • it can be implemented by the operating system 294 shown in FIG. 10 in combination with necessary hardware.
  • the terminal 200 may include fewer or more components than those shown in FIG. 10, and the terminal device 200 illustrated in FIG. 10 only shows a plurality of components disclosed in the embodiments of the present application. A more relevant component of the implementation.
  • the embodiment of the present application further provides a terminal device 400.
  • the terminal device 400 includes: a processing circuit 402, and a communication interface 404 and a storage medium connected thereto. 406.
  • Processing circuitry 402 is used to process data, control data access and storage, issue commands, and control other components to perform operations.
  • Processing circuit 402 can be implemented as one or more processors, one or more controllers, and/or other structures that can be used to execute a program.
  • the processing circuit 402 may specifically include a general purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or At least one of the other programmable logic components.
  • a general purpose processor may include a microprocessor, as well as any conventional processor, controller, microcontroller, or state machine.
  • Processing circuit 402 can also be implemented as a computing component, such as a combination of a DSP and a microprocessor.
  • the storage medium 406 may include a non-transitory computer-readable storage medium such as a magnetic storage device (eg, a hard disk, a floppy disk, a magnetic strip), and an optical storage medium (eg, a digital versatile disc (digital) Versatile disc, DVD)), smart card, flash device, RAM, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), Registers, and any combination of them.
  • Storage medium 406 can be coupled to processing circuitry 402 such that processing circuitry 402 can read information and write information to storage medium 406.
  • storage medium 406 can be integrated into processing circuit 402, or storage medium 406 and processing circuit 402 can be separate.
  • Communication interface 404 can include circuitry and/or programs to enable two-way communication between terminal device 400 and one or more network devices (eg, routers, switches, access points, etc.).
  • Communication interface 404 includes at least one receive circuit 416 and/or at least one transmit circuit 418.
  • communication interface 404 may be implemented in whole or in part by a wireless modem.
  • a program (instruction) 420 is stored in the storage medium 406, and the processing circuit 402 is adapted to execute a program (instruction) sequence 420 stored in the storage medium 406 to implement any of the method embodiments of the present application. Part or all of the steps.
  • the embodiment of the present application further provides a computer readable storage medium storing code, instructions or a program for implementing the method steps in the method embodiment of any of the present application.
  • the method for defending against a DoS attack can also be applied to a server 300 having a dual domain system, where the server 300 includes a non-secure domain 310 and a security domain 320 that are isolated from each other, wherein the security domain 320 The security level is higher than the non-secure domain 310.
  • the CA running in the non-secure domain 310 can also request the services of the TA running in the security domain 320 through a specific interface.
  • a malicious application may implement a DoS attack by frequently calling a non-secure domain 310 or a service/interface 11 in the secure domain 320.
  • the service/interface 11 can be protected using the method of defending against DoS attacks provided by the foregoing embodiments of the present application.
  • the behavior data collector is deployed in the security domain 320, and the access behavior logs of the plurality of predefined normal CA access services/interfaces 11 running in the non-security domain 310 are collected, and the access behavior data set is constructed.
  • one or more access behavior models are trained based on the machine learning method, and an accurate management policy is determined according to the access behavior model, and then the defense module deployed in the security domain 320 is based on the management policy on the service/interface 11
  • the access request is controlled, so as to timely resist the DoS attack initiated by the service/interface 11, thereby improving the security of the device.
  • the disclosed apparatus and method may be implemented in other manners.
  • the device embodiments described above are merely illustrative.
  • the division of the unit is only a logical function division.
  • there may be another division manner for example, multiple units or components may be combined or Can be integrated into another system, or some features can be ignored or not executed.
  • the mutual coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interface, device or unit, and may be in an electrical, mechanical or other form.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
  • the functions may be stored in a computer readable storage medium if implemented in the form of a software functional unit and sold or used as a standalone product. Based on such understanding, a portion of the technical solution of the present application that contributes in essence or to the prior art or a portion of the technical solution may be embodied in the form of a computer software product stored in a storage medium. A number of instructions are included to cause a computer device (which may be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in various embodiments of the present application.
  • the foregoing storage medium includes various media that can store program codes, such as a USB flash drive, a removable hard disk, a ROM, a RAM, or an optical disk.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

一种抵御DoS攻击的方法，可应用于包含互相隔离的可信执行环境TEE以及富执行环境REE的终端设备，该方法首先获取REE中运行的客户端应用程序对服务或接口发起的访问请求，该访问请求用于请求服务或资源；将所述访问请求传递给所述TEE中部署的抵御模块；所述抵御模块基于根据访问行为模型确定出的管控策略决定是否授权所述访问请求，所述访问行为模型是通过统计学方法或者机器学习算法对多个正常CA访问所述服务/接口的访问行为数据集进行训练后得到的。

Description

一种抵御拒绝服务攻击的方法及设备 技术领域
本申请涉及安全领域，更为具体地，涉及一种抵御拒绝服务(Denial of Service，DoS)攻击的方法、及设备。
背景技术
近年来，随着移动互联网的发展，智能终端设备的数量急剧增加。为了提供智能移动终端的丰富功能和可扩展属性，终端设备通常都是构建在提供开放式操作环境的富执行环境(Rich Execution Environment，REE)之上，REE也被称为一般运行环境，主要包括运行于通用处理器上的富操作系统(Rich Operating System，Rich OS)，如
Figure PCTCN2018110296-appb-000001
操作系统，及运行在Rich OS上的客户端应用程序(client application，CA)。REE的一个主要优点是用户可以随时添加应用程序，然而，这种开放式的环境也为信息泄露和恶意软件传播提供了通道，使终端设备暴露在不断增长的多种形式的攻击之下，因此很容易被恶意软件破解，导致终端设备的各种安全问题也日益凸显。
REE本身是不可信的已成为业内共识，针对这一问题，开放移动终端组织(Open Mobile Terminal Platform，OMTP)首先提出了可信执行环境(Trusted Execution Environment，TEE)概念。2010年7月，全球平台组织(Global
Figure PCTCN2018110296-appb-000002
GP)提出了TEE标准。TEE是运行于REE之外的独立运行环境，并且与REE隔离。运行在TEE内中的每一个可信应用程序(Trusted Application，TA)都是独立的，TA不能未经授权访问另一个TA的安全资源。REE中的CA无法直接访问TEE的硬件和软件安全资源，因此它能够抵御在REE侧发生的软件攻击。REE中的CA在通过TEE身份认证的情况下，可以调用特定的应用编程接口(Application Programming Interface，API)调用TEE的资源或服务，如密码运算和存储，或者访问运行于TEE中的TA的数据。
尽管TEE试图通过硬件隔离的方式阻止REE侧的攻击，进而保证敏感数据的安全，但是TEE本质还是一个公共安全“平台”，在GP标准里，明确指出TA和CA为TEE的应用软件，整个TEE需要为他们提供必不可少的服务。为了利用TEE增强安全性，许多软件开发厂商会利用TEE，以及TEE的特定接口开发和部署自己的CA与TA，以支撑其应用程序的安全性。因此，TEE也逐渐成为保护REE侧应用程序与数据安全的重要基石，其在一定程度上决定了终端设备的安全程度。但是由于TEE的软硬件资源是非常有限的，当CA存在漏洞或者REE侧被Root后，恶意应用可以很容易地利用现有接口来频繁调用TEE侧的服务。这种情况下，一旦将TEE的资源全部占用，且长时间不释放，即可造成拒绝服务(Denial of Service，DoS)攻击，导致REE侧和TEE侧的服务不可用，甚至设备重启等状况。由此可见，目前终端设备(REE侧和TEE侧)发生DoS攻击的可能性较大，严重威胁终端设备的安全。
发明内容
本申请提供一种抵御拒绝服务(Denial of Service，DoS)攻击的方法，以及用于实施 该方法的设备，以降低设备内部的DoS发生的概率，保证设备的安全运行。
第一方面，本申请实施例提供一种抵御DoS攻击的方法，可应用于包含可信执行环境TEE以及富执行环境REE的终端设备或其它类似设备，其中，REE中运行有客户端应用程序CA，该方法包括：获取CA对服务/接口发起的访问请求，所述服务/接口为所述REE或者所述TEE提供的服务或接口，所述CA通过向所述服务/接口发起该访问请求以请求服务或资源；将所述访问请求通过终端设备内的消息传递机制传递给所述TEE中部署的抵御模块；所述抵御模块根据管控策略决定是否授权所述访问请求；其中，所述管控策略是根据访问行为模型确定的；所述访问行为模型是通过统计学方法或者机器学习算法对访问行为数据集进行训练后得到的，用于表征至少一个CA访问所述服务/接口的行为特征，其中，所述访问行为数据集包括在所述TEE中采集到的所述至少一个CA访问所述服务/接口的访问行为日志。本申请实施例提供的方法，利用访问行为特征模型来确定管控策略，抵御模块进而基于管控策略对访问请求进行针对性管控，从而可以精准识别并阻止具有潜在DoS攻击威胁的访问请求，提升了设备的安全性。由于训练访问行为特征模型所使用的访问行为数据集合是在TEE中采集的，可以防止行为数据被篡改，保证了数据样本的真实性以及访问行为模型的准确性，同时，抵御模块也部署于TEE内部，保证了其自身的安全性。
在一种可能的实现方式中，在将所述访问请求传递给所述抵御模块之前，先在TEE内部对发起所述访问请求的所述CA进行身份认证，在所述CA未通过身份认证的情况下，阻止该访问请求；在所述CA通过身份认证的情况下，再将所述访问请求传递给所述抵御模块以进行进一步管控。通过这种方式，可以提前对访问请求进行初步鉴别，减轻抵御模块的负载，避免抵御模块成为性能瓶颈。
在一种可能的实现方式中，所述访问行为数据集合可以由TEE中部署的访问行为数据采集器来采集，以保证访问行为数据的可靠性，防止被REE侧恶意程序篡改。
在一种可能的实现方式中，所述访问行为数据采集器记录所述至少一个CA对所述服务/接口发起的多个访问请求对应的多个访问行为日志；根据所述多个访问行为日志构建所述访问行为数据集。
在一种可能的实现方式中，当所述CA通过身份认证后，还可以将所述访问请求传递给所述访问行为数据采集器，所述访问行为数据采集器记录所述访问请求对应的访问行为日志，并增量更新所述访问行为数据集合；基于更新后的访问行为数据集合训练出的访问行为模型会愈来愈精确，从而可以实现管控策略的迭代优化。
在一种可能的实现方式中，所述管控策略包括至少一个管控参数的阈值；所述至少一个管控参数是根据所述访问行为模型确定的；所述至少一个管控参数的阈值是基于DoS攻击抵御能力分析公式，在完成DoS攻击所需的最小资源量超出刚性指标的前提下，求解得到的；其中，其中，所述DoS攻击抵御能力分析公式表征完成DoS攻击所需的最小资源量与管控参数之间的约束关系，所述刚性指标与所述终端设备的硬件资源限制、或者操作系统的限制，或者业务场景的限制相关。完成DoS攻击所需的最小资源量超出刚性指标意味着发生DoS攻击的概率为0，因此，通过DoS攻击抵御能力分析公式求解出的管控参数的阈值可以使得发生DoS攻击的概率降到最低，与仅通过访问行为模型来管控访问请求的方案相比，管控参数更加精准，并且能保证终端设备内针对该待保护服务/接口发起的DoS攻 击的概率最低。
在一种可能的实现方式中，所述抵御模块根据所述访问请求，以及管控策略决定是否授权所述访问请求包括：若所述访问请求会触发所述至少一个管控参数超出所述阈值，则阻止所述访问请求，否则授权所述访问请求。这种基于阈值的管控方式，计算开销较小，因此对系统性能的影响较小。
在一种可能的实现方式中，在阻止所述访问请求后，所述抵御模块通知或提醒用户决策是否授权所述访问请求；若所述用户授权所述访问请求，则根据所述访问请求的访问行为日志，通过增强学习算法更新所述访问行为模型，以得到更新后的访问行为模型。通过该技术方案，当抵御模块发生误判后，可以及时对访问行为模型进行纠偏，提升访问行为模型的精度。进一步地，可以根据更新后的访问行为模型更新管控策略，从而实现管控策略的动态调整，以提升对访问请求管控的精准性。
在一种可能的实现方式中，访问行为数据采集器采集的访问行为日志包括：所述多个访问请求中每一个访问请求的发起实体的信息，所述多个访问请求中每一个访问请求的时间戳，所述多个访问请求中每一个访问请求涉及的资源的数量；所述至少一个管控参数包括如下至少一种：同一CA两次访问所述服务/接口的时间间隔，同一CA持有所述服务/接口相关的资源的数量，以及同一CA持有所述服务/接口相关的资源的时间。访问行为数据采集器采集针对性地采集这些可用于判别DoS攻击行为的关键信息，采集的数据量少，对TEE侧的资源消耗较少。
在一种可能的实现方式中，所述TEE中运行有可信应用程序TA，所述访问请求用于在所述TA中打开一个与所述CA的会话；所述至少一个管控参数包括如下至少一种：同一CA两次访问所述服务/接口的时间间隔，同一CA持有的与所述TA之间的会话数量，以及同一CA持有的与所述TA之间的会话的时间。
在一种可能的实现方式中，所述至少一个管控参数的阈值包括：同一CA两次访问所述服务/接口的时间间隔阈值；所述抵御模块根据管控策略决定是否授权所述访问请求包括：计算所述CA发起所述访问请求以及所述CA向所述服务/接口发起的上一次访问请求的时间间隔；当计算出的时间间隔小于所述时间间隔阈值时，所述抵御模块阻止所述访问请求；当所述计算出的时间间隔大于所述时间间隔阈值时，所述抵御模块授权所述访问请求。
在一种可能的实现方式中，所述至少一个管控参数的阈值包括：同一CA持有的与所述TA之间的会话数量的上限值；所述抵御模块根据管控策略决定是否授权所述访问请求包括：根据所述CA当前的请求状态，确定所述CA已持有的与所述TA之间的会话数量；当确定出的会话数量大于或等于所述上限值，则所述抵御模块阻止所述访问请求；当所述确定出的会话数量小于所述上限值，则所述抵御模块授权所述访问请求。
第二方面，本申请实施例提供一种生成管控策略的方法，该管控策略用于管控应用程序对终端设备中的服务/接口发起的访问请求，该终端设备包含可信执行环境TEE以及富执行环境REE，该方法包括：根据访问行为数据集，通过机器学习算法训练得到访问行为模型；其中，访问行为数据集是部署在TEE中的访问行为数据采集器采集的，包括一个或多个CA访问所述服务/接口的访问行为日志，所述访问行为模型用于刻画所述一个或多个CA 的访问行为特征；根据所述访问行为模型确定管控参数，根据DoS攻击抵御能力分析公式求解管控参数的约束条件；根据所述管控参数的约束条件生成管控策略；其中，DoS攻击抵御能力分析公式用于表示完成DoS攻击所需的最小资源量与管控参数之间的约束关系。通过DoS攻击抵御能力分析公式求解出的管控参数的约束条件可以使得发生DoS攻击的概率最小化，与直接通过访问行为模型确定管控参数的约束条件的方案相比，管控参数更加精准，并且能保证终端设备内针对该待保护服务/接口发起的DoS攻击的概率最低。
在一种可能的实现方式中，完成DoS攻击所需的最小资源量可以为需要在终端设备上同时运行的应用程序的个数，或者需要占用共享内存的大小，或者需要在终端设备上同时运行的进程或线程的个数等。
在一种可能的实现方式中，根据DoS攻击抵御能力分析公式求解管控参数的约束条件包括：基于DoS攻击抵御能力分析公式，在完成DoS攻击所需的最小资源量超出刚性指标(即发生DoS攻击概率为0)的前提下，求解管控参数的值。求解出的值可以作为管控参数的约束条件。
在一种可能的实现方式中，刚性指标与终端设备硬件资源的限制、或者软件(比如操作系统)的限制，或者业务场景的限制有关。例如，刚性指标可以为终端设备上最多可同时运行的应用程序、进程或线程的个数。
在一种可能的实现方式中，管控参数包括：预定义的正常CA持有待保护服务/接口相关的资源的最长持有时间b、预定义的正常CA两次访问该待保护服务/接口的时间最小间隔a、同一个CA在访问过程中持有该待保护服务/接口相关的资源的数量上限m。
在一种可能的实现方式中，DoS攻击抵御能力分析公式为计算要完成DoS攻击，所需的资源Y的下限值的计算公式，即：Y＝(a/b)*m，其中，Y为完成DoS攻击所需的资源量。
在一种可能的实现方式中，在Y>＝γ的前提条件下，求解a,b,m的值，使得恶意CA能够造成DoS攻击的概率最小化，以得到管控参数a,b,m的约束条件；其中，γ是与终端设备硬件资源的限制、或者软件(比如操作系统)的限制，或者业务场景的限制直接相关的一个软/硬件资源阈值。
在一种可能的实现方式中，管控参数的约束条件为管控参数的取值，或者取值范围。
在一种可能的实现方式中，管控策略由管控参数的约束条件转换得到。
本申请实施例第二方面提供的生成管控策略的方法可以单独实施，也可以结合前面第一方面的抵御DoS攻击的方法来实施，即生成的管控策略可以应用于第一方面的抵御DoS攻击的方法中，从而实现对访问请求的精准管控。
第三方面，本申请实施例提供一种终端设备，包括用于执行上述第一方面至第二方面中任一方面所描述的方法的一个或多个功能单元，这些功能单元可以由软件模块实现，或者由硬件，比如处理器实现，或者由软件结合必要的硬件实现。
第四方面，本申请实施例提供一种终端设备，包括存储器、处理器以及存储在所述存储器上的计算机程序，当所述处理器执行所述计算机程序时实现上述第一方面至第二方面中任一方面所描述的方法的步骤。
第五方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序(指令)，该程序(指令)被处理器执行时实现上述第一方面至第二方面中任一方面所描述的 方法的步骤。
第六方面，本申请实施例提供一种抵御服务器中的拒绝服务DoS攻击的方法，所述服务器包括互相隔离的安全域以及非安全域，所述非安全域中运行有客户端应用程序CA，其特征在于，所述方法包括：获取所述CA对服务/接口发起的访问请求，所述服务/接口为所述安全域或所述非安全域提供的接口，所述CA通过访问所述服务/接口来请求资源或服务；将所述访问请求传递给所述安全域中部署的访问行为数据采集器；所述访问行为数据采集器将访问请求传递给所述安全域中部署的抵御模块；所述抵御模块根据所述访问请求的访问，以及管控策略决定是否授权所述访问请求；其中，所述管控策略是根据访问行为模型确定的；所述访问行为模型是通过统计学方法或者机器学习算法对访问行为数据集进行训练后得到的，用于表征CA发起的访问请求的行为特征，其中，所述访问行为数据集包括一个或多个CA访问所述服务/接口的访问行为日志。
本申请通过以上技术方案，可以减少设备内部发生DoS攻击的概率，保证设备的安全运行。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍。
图1是本申请实施例的终端设备的示意图。
图2是本申请实施例的终端设备的示意图。
图3是本申请实施例的抵御拒绝服务(DoS)攻击的方法的过程示意图。
图4是本申请实施例的抵御DoS攻击的方法流程图。
图5是本申请实施例的客户端应用程序与可信应用程序之间的交互示意图。
图6是本申请实施例的抵御DoS攻击的方法的过程示意图。
图7是本申请实施例的访问行为数据采集示意图。
图8是本申请实施例的访问行为模型训练过程示意图。
图9是本申请实施例的生成管控策略的过程示意图。
图10是本申请实施例的终端设备的示意图。
图11是本申请实施例的终端设备的示意图。
图12是本申请实施例的服务器的示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行详细描述，显然，所描述的实施例是本申请的一部分实施例，而不是全部实施例。
本申请实施例提供一种抵御拒绝服务(Denial of Service，DoS)攻击的方法，以识别和阻止恶意程序通过调用设备内的特定接口或服务发起的DoS攻击，提高设备的安全性。本申请提供的方法可典型地应用于终端设备，或者也可以应用于服务器等计算机系统。本申请实施例及权利要求所述的终端设备指向用户提供语音和/或数据连通性的设备，包括无线终端或有线终端。无线终端可以经无线接入网(radio access network，RAN)与一个或多 个核心网进行通信，无线终端可以是移动终端，如移动电话(或称为“蜂窝”电话)和具有移动终端的计算机，例如，可以是便携式、袖珍式、手持式、计算机内置的或者车载的移动装置。接口，也称为应用编程接口(Application Programming Interface，API)，是由计算机程序代码实现的特定功能的封装和抽象表达，应用程序通过调用接口可以实现特定功能。服务是可以在后台执行而不提供用户界面的应用组件，服务可由其他应用程序或应用组件启动。
下面将参照附图更详细地描述本申请涉及的终端设备。需要说明的是，后置用语“单元”和“模块”仅仅是为了描述的方便，并且这些后置用语不具有相互区分的含义或功能。
图1示出了本申请实施例提供的终端设备100的架构图，根据图1，终端设备100包括硬件平台110，以及运行在硬件平台100上的互相隔离两个运行环境，即富执行环境(Rich Execution Environment，REE)120和可信执行环境(Trusted Execution Environment，TEE)140，两个运行环境分别有独立的硬件资源和操作系统。通过硬件隔离技术，比如
Figure PCTCN2018110296-appb-000003
TrustZone机制，可以实现REE 120和TEE 140的硬件资源的隔离，同时通过虚拟化技术实现REE 120和TEE 140的操作系统之间，以及应用之间的隔离。这样，TEE140所能访问的软硬件资源是与REE是分离的，并且，TEE 140对应用程序可访问的数据和功能做了非常严格的限制，使其安全级别满足特定的安全需求，因此TEE 140通常被认为是安全的执行环境。REE 120是TEE140之外的运行环境，相比于TEE140，REE 120的安全性更低，是一个易于被攻击的环境，而运行于REE 120中的应用程序也被认为是不可信的。运行在TEE 140中的应用程序155为可信应用程序(Trusted Application，TA)，TA 155可以为TEE 140外的客户端应用程序(client application，CA)或者TEE 140内的其它TA提供安全相关的功能或服务。运行在REE 120中的CA可以利用TEE外部接口125来请求TEE 140中的TA 155所提供的安全服务。在TEE 140中运行的可信的操作系统(Trusted Operating System，Trusted OS)143向TA155提供TEE内部接口145，TA 155通过TEE内部接口145来获取安全资源和服务的访问权限，这些安全资源和服务包括但不限于：密钥注入和管理、加密、安全存储、安全时钟、可信用户界面(UI)和可信键盘等。REE 120中的富操作系统(Rich Operating System，Rich OS)123提供了比TEE 140中的Trusted OS 143更广泛的特性，Rich OS 123非常开放，能接受各种类型的应用程序，但其安全性也低于Trusted OS 143。Rich OS 123可以为
Figure PCTCN2018110296-appb-000004
等终端操作系统。
关于本申请所有实施例涉及的REE、TEE、CA、TA、Rich OS、Trusted OS等术语的定义，可以参见全球平台组织(Global
Figure PCTCN2018110296-appb-000005
GP)提出的TEE相关标准。
在一个实施例中，如图2所示，终端设备100的硬件平台110包括公共外设121和可信外设141，Rich OS 123和可信操作系统143分别包含公共外设驱动127以及可信外设驱动。可信外设141包括只能被TEE140控制和访问的安全元件(Secure Element，SE)，比如安全存储器、安全时钟、可信键盘等。公共外设121是可被REE 120中的Rich OS 123控制和访问的设备。图1中的TEE外部接口125具体可以包括TEE功能接口(TEE functional API)127和TEE客户端接口(TEE client API)126。TEE功能接口127向REE 120中的CA 113提供一套应用编程接口(Application Programming Interface，API)，CA 113通过TEE功能接口127可以调用部分TEE服务，如加解密运算或安全存储等。TEE客户端接 口126是一个低级的通信接口，它被设计用于使运行于Rich OS 123中的CA 113访问和交换运行于TEE140中的可信应用程序115的数据。REE 120和TEE 140中分别部署有REE通信代理129和TEE通信代理145，用以支持CA 113和TA 115之间的消息交互。REE通信代理129和TEE通信代理145协同工作，并利用底层的消息路由机制为CA 113和TA 115之间的消息交互提供安全保障。
基于图1或图2所描述的终端设备100，本申请实施例提供一种抵御终端设备100中的DoS攻击的方法。终端设备100内部发生的DoS攻击通常都具有如下特征：
(1)DoS攻击发起方为在终端设备上直接运行的应用程序，例如CA，或者REE侧的其它应用程序；
(2)DoS攻击发起方会频繁调用接口或服务以达到占用资源的目的；
(3)DoS攻击发起方会长时间占用所获得的有限的系统资源。
由于终端设备100的运行资源有限，其上所能部署及运行的应用个数有限，该特征正是区别于传统网络DoS攻击的最为本质的差别。鉴于此，本申请实施例中“抵御终端设备中的DoS攻击”包括：(1)针对REE120和/或TEE140侧的待保护服务或接口，例如TA打开会话(OpenSession)接口，使得所有预定义的正常CA(例如某个CA集合)能够顺利访问，不发生拒绝服务问题；(2)阻止/中断恶意CA对待保护服务或接口的调用，这里的“待保护服务或接口”即为本申请实施例的方法所针对的目标对象。其中，待保护接口可以为TEE内部接口143，也可以为TEE外部接口125，比如TEE功能接口127和/或TEE客户端接口126；待保护服务可以是TEE侧和/或REE侧的服务。当应理解的是，除了终端设备以外，本申请实施例提供的抵御Dos攻击的方法也可以应用于其他类型的计算机系统，比如具有双域系统(安全域和非安全域)的服务器、数据中心等。
图3示出了本申请实施例提供的抵御拒绝服务攻击的方法涉及的功能实体和主要步骤。如图3所示，本申请实施例提供的抵御拒绝服务攻击的方法包括3个阶段：(1)客户端应用程序(CA)的访问行为数据采集阶段(下文简称“数据采集阶段”)；(2)CA行为模型训练阶段(下文简称“模型训练阶段”)；(3)CA访问行为管控阶段(下文简称“管控阶段”)。其中，数据采集阶段和模型训练阶段通常是离线进行，即在终端设备操作系统发布前，系统软件开发与部署时进行样本数据采集和模型训练。应理解的是，在方案的具体实现中，这三个阶段并非全然是串行执行的。
在数据采集阶段，需要采集CA访问待保护服务/接口10的访问行为数据样本，以作为模型训练阶段的输入，并且要保证采集的访问行为数据样本可信，能反映在真实的业务场景下，CA访问待保护服务/接口10时的访问行为特征。因此，本申请实施例将访问行为数据采集器134在部署TEE 140中，以保证访问行为数据采集的安全性，防止访问行为数据被REE 120侧的恶意程序篡改。访问行为数据采集器134通过采集一个或多个正常CA访问待保护服务/接口10时的访问行为日志，以构建访问行为数据集138。这里的“正常CA”是相对于潜在可能发动DoS攻击的恶意CA而言的，正常CA通常是指用户或者应用开发者预定义的，或者通过安全性检测的可靠CA。待保护服务/接口10可以是REE的服务或接口，也可以是TEE的服务或接口。若待保护服务/接口10部署在REE 120中，则待保护服务/接口10会将CA对其发起的访问请求转发给REE中的关键资源访问代理130， 关键资源访问代理130为一个代理程序，负责将来自待保护服务/接口的访问请求转发到TEE 140中部署的关键资源申请接口132。关键资源申请接口132负责对接收到的访问请求的发起实体进行身份认证，当通过身份认证后，关键资源申请接口132将访问请求转发给部署在TEE 140中的访问行为数据采集器134，访问行为数据采集器134会记录该访问请求对应的访问行为日志。若待保护服务/接口10部署在TEE 140中，则可以由待保护服务/接口10直接将CA的访问请求直接发送TEE侧的关键资源申请接口132，而不需要经过关键资源访问代理130。
在模型训练阶段，行为建模器150以访问行为数据集138为数据源，通过统计学方法和/或机器学习方法，例如最大似然估计方法，训练得到DoS攻击分析器160所需要的访问行为模型，该访问行为模型可以表征正常CA对待保护服务/接口10的访问行为的特征，比如两次访问待保护服务/接口10的时间间隔，访问过程中持有待保护服务/接口10相关的关键资源的数量等。模型的训练包括模型建立以及模型参数的调优过程，训练出来的访问行为模型或者模型参数会被存储起来，用于管控阶段使用。基于访问行为数据集138训练访问行为模型的过程可以使用多种现有技术来实现，在此不进行详细说明。
在管控阶段，DoS攻击分析器160利用其内置的DoS攻击抵御能力分析公式，以行为建模器150输出的访问行为模型为输入，对抵御模块170所需的管控参数求解计算，以得到管控策略。管控策略用于表示管控参数需要满足的约束条件，可以包括至少一个管控参数的阈值或取值范围。管控策略可以转化为判断逻辑并由抵御模块170执行。当关键资源申请接口132接收到针对待保护服务/接口的访问请求，先对访问请求的发起实体进行身份认证，若身份认证不通过，则可以直接阻止该访问请求；若身份认证通过，则关键资源申请接口132将访问请求发送给访问行为数据采集器134，访问行为数据采集器134将该访问请求转发给抵御模块170，抵御模块170根据该管控策略授权或者阻止该访问请求。其中，关键资源申请接口132和抵御模块170阻止该访问请求可以通过多种方式实现。比如可以返回一个命令、消息或参数给待保护服务/接口10，以指示待保护服务/接口10拒绝该访问请求；或者也可以调用某个系统函数或接口来拒绝该访问请求。作为一种可选的实施方式，在身份认证通过后，关键资源申请接口132也可以直接将该访问请求发送给抵御模块170，而不是经过访问行为数据采集器134转发。抵御模块170部署于TEE 140中，利用TEE 140本身的安全机制保护自身以及管控策略的安全性与机密性不受到破坏。抵御模块170依赖少量的管控参数来管控针对待保护接口的访问请求，以降低终端设备内拒绝服务攻击发生的概率，保证终端系统的安全运行。
下面示例性地分别介绍以上三个阶段的详细实现方式。
在数据采集阶段，行为数据采集器134不需要采集正常CA的全量访问行为数据，可以根据管控的需求，针对性采集部分访问行为数据，以减少系统资源开销。例如，行为数据采集器134可以根据终端设备100内部发生的DoS攻击的根因，确定需要采集的访问行为日志的类型，并在数据采集阶段，将多个正常CA访问待保护服务/接口10的部分访问行为日志记录在系统中，最终输出离线过程所需要的访问行为数据集138。需要采集的访问行为日志的类型包括记录有CA访问待保护服务/接口时的关键行为特征的日志，这里的关键行为特征是指能够区分正常CA与潜在可能发动DoS攻击的CA的行为特征。在一个实 施例中，行为数据采集器134采集的访问行为日志包含CA在访问待保护服务/接口10过程中的时间维度和资源维度的特征。具体地，时间维度的特征包括但不限于如下一项或多项：CA访问服务/接口的时间戳、同一CA两次访问该服务或接口的时间间隔，CA持有该服务或接口相关的资源的时间(CA请求关键资源与CA释放资源的时间差)；时间维度的特征包括但不限于如下一项或多项：CA在访问过程中持有该服务/接口相关的资源的数量。服务/接口相关的资源包括实现该服务/接口的功能所占用的系统资源，或者应用程序通过访问或调用该服务/接口可获得的系统资源，比如会话、CPU、内存等资源。相应地，行为数据采集器134在多个正常CA访问或调用待保护服务/接口10的过程中，记录每个CA的访问行为日志，并最终输出访问行为数据集138。
在一个实施例中，行为数据采集器134可以采集到的原始数据存储到存储器中，或者也可以将原始数据经过清洗/加工后再存储到存储器中。数据清洗(Data cleaning)指的是计算机对数据进行重新审查和校验的过程，目的在于删除重复信息、纠正存在的错误，并提供数据一致性。数据加工指的是对数据进行类型、格式等变化，或对数据进行数学变换等处理。
访问行为数据集138包含了每个正常CA的访问行为日志。在模型训练阶段，行为建模器150对访问行为数据集138进行特征提取，将提取的特征转换为机器学习算法可处理的特征向量，然后使用机器学习算法，比如softmax算法等训练出访问行为模型，该访问行为模型表征正常CA发起的访问请求的行为特征或者规律。DoS攻击分析器160基于访问行为模型确定出管控参数，并基于DoS攻击抵御能力分析公式计算出管控参数的约束条件，以形成管控策略。在一个实施例中，为了使访问行为模型更加精确，在行为建模器150进行模型训练之前，可以将采集的访问行为数据集138从一个维度或多个维度分为多类，针对这多个类别分别训练各自的访问行为模型。例如，可以按照CA的维度来划分数据集，即将每个CA的访问行为日志作为一个分类；也可以按照业务场景的维度来划分数据集，即将同一业务场景下所有正常CA的访问行为日志作为一个分类。由于在不同的业务场景下，同一个CA调用同一个服务/接口的行为日志也可能是有区别的，而分业务场景去收集行为数据及建模更能准确体现不同场景下CA的调用行为特征，因此可以同时参考CA和业务场景两个维度的信息来对访问行为数据集进行更精细的划分。可以理解的是，为了便于数据集的划分，行为数据采集器134在数据采集阶段可以对CA的访问行为日志进行必要的备注，例如将访问行为日志对应的CA的标识和/或业务场景进行记录。这样，对划分之后的各个分类进行机器学习，可以得到多个分类分别对应的多个访问行为模型(或模型参数)。
DoS攻击分析器160根据行为建模器150训练输出的访问行为模型(或模型参数)，确定抵御DoS攻击所需的管控参数，以及管控参数的初始约束条件，其中，约束条件可是个一个特定的值，或者一个取值范围。管控参数可以指示CA访问待待保护服务/接口时的部分访问行为特征，比如时间或资源维度的特征。在一个实施例中，管控参数可以包括访问待保护服务/接口的时间间隔，访问访问待保护服务/接口时占用或持有资源的数量，持有或占用资源的时间等。通常，如果对待保护服务/接口发起访问的CA对应的管控参数满足管控参数的初始约束条件，则认为该CA是正常CA，即发起DoS攻击的可能性较低，否 则就认为该CA是潜在会发起DoS攻击的恶意CA。然而，直接使用根据管控参数的初始约束条件来判定发生DoS攻击的可能，准确性可能无法保证。也就是说，即便CA对应的管控参数满足管控参数的初始约束条件，仍然不能保证发生DoS攻击的概率最小。因此，DoS攻击分析器160可以基于DoS攻击抵御能力分析公式对管控参数的约束条件进行优化，以使得发生DoS攻击的概率最小化。其中，DoS攻击抵御能力分析公式用于表示完成DoS攻击所需的最小资源量与管控参数之间的约束关系。完成DoS攻击所需的最小资源量可以为需要在终端设备上同时运行的恶意程序的个数，或者需要占用共享内存的大小等。由于终端设备的软硬件资源有限，所以，如果完成DoS攻击所需的最小资源量如果超过了与终端设备的硬件资源限制或者软件(比如操作系统)限制相关的某个刚性指标，则代表DoS攻击发生的概率为0。也就是说，通过DoS攻击抵御能力分析公式可以评估DoS攻击发生的概率，管控参数的不同取值对应于不同的DoS攻击发生概率，当DoS攻击发生的概率最小时(最优为0)，求解出的管控参数的取值为最优。鉴于此，DoS攻击分析器160可以基于DoS攻击抵御能力分析公式，在完成DoS攻击所需的最小资源量超出刚性指标(即发生DoS攻击概率为0)的前提下，求解管控参数的值。求解出的值可以作为管控参数优化后的约束条件。进一步地，DoS攻击分析器160可以根据管控参数优化后的约束条件生成对应的管控策略。抵御模块170基于该管控策略管控针对待保护服务/接口的访问请求。
具体地，在一个实施例中，假设根据行为建模器150训练输出的访问行为模型，确定管控参数为：
(1).预定义的正常CA持有待保护服务/接口相关的资源的最长持有时间，用符号b代表；
(2).预定义的正常CA两次访问该待保护服务/接口的时间最小间隔，用符号a代表；
(3)同一个CA在访问过程中持有该待保护服务/接口相关的资源的数量上限，用符号m代表。
那么终端设备的DoS攻击抵御能力分析公式可以为计算要完成DoS攻击所需的资源Y的下限值的计算公式例如，可以为：
Y＝(a/b)*m，
其中，所需的资源Y可以为需要同时运行的恶意程序的个数，或占用共享内存的大小等。当Y>＝γ，即可抵御DoS攻击的发生，γ为一个刚性指标，γ与终端设备硬件资源的限制、或者软件(比如操作系统)的限制，或者业务场景的限制有关。例如，γ可以为终端设备上最多可同时运行的应用程序或者进程的个数，，因此，当Y表示完成DoS攻击需要同时运行的恶意程序的个数时，只要令Y>＝γ，即可抵御DoS攻击的发生。
因此，管控参数的求解目标，即在Y>＝γ的前提条件下，求解a,b,m的值，使得恶意CA能够造成DoS攻击的概率最小化。基于上述前提条件对管控参数进行求解计算，可以得到管控参数的约束条件(优化后)，比如管控参数的取值范围，阈值等等。管控参数的约束条件可以转化为管控策略或者判断逻辑固化在抵御模块170中，抵御模块170基于该管控策略来对针对该待保护服务/接口的访问请求进行安全管控。具体地，如图4所示，以 REE侧CA发起对REE或TEE侧的待保护服务/接口10的访问请求为例，使用抵御模块170中对访问请求的管控方法包括如下步骤：
步骤401：REE侧的CA 113发起对待保护服务/接口10的访问请求。
步骤403：待保护服务/接口10将访问请求封装后，连同该请求的发起实体(即步骤401中的CA 113)的信息传递给REE侧的关键资源访问代理130。
步骤405：关键资源访问代理130通过TEE侧部署在REE侧的程序接口，将访问请求及请求发起实体(即CA 113)的信息传入TEE侧的关键资源申请接口132。
步骤407：关键资源申请接口132对请求发起实体进行身份认证，在其通过身份认证的条件下，将访问请求对应发送给访问行为数据采集器134，访问行为数据采集器134将存储该访问请求对应的访问行为日志。
步骤409：访问行为数据采集器134将访问请求连同该发请求起实体当前的请求状态一并传递给TEE侧的抵御模块170。可选地，在该步骤中，访问行为数据采集器134也记录该访问请求对应的访问行为日志，以更新访问行为数据集138。
步骤411：抵御模块170根据管控策略决策是否授权本次访问请求，抵御模块170根据管控策略做出授权或阻止访问请求的决策之后，通过关键资源申请接口132将决策结果反馈给待保护服务/接口10，待保护服务/接口10基于决策结果响应本次访问请求，或者拒绝本次访问请求。
可以理解的是，当TEE侧的TA发起对REE或TEE侧的待保护服务/接口10的访问请求时，待保护服务/接口10可直接将访问请求直接发送给访问行为数据采集器134，而不需要通过关键资源访问代理和关键资源申请接口。
在一个实施例中，假设CA 113发起对待保护服务/接口10的访问请求为在TA 115中打开一个与CA 113的会话的请求，管控策略包括：同一CA两次访问所述服务/接口的时间间隔阈值，和/或同一CA持有的与所述TA之间的会话数量的上限值。则抵御模块170计算述CA 113发起所述访问请求以及向所述服务/接口发起的上一次访问请求的时间间隔；当计算出的时间间隔小于所述时间间隔阈值时，抵御模块170阻止所述访问请求；当所述计算出的时间间隔大于所述时间间隔阈值时，抵御模块170授权所述访问请求。或者，若CA 113已持有的与TA 115之间的会话数量大于或等于上述上限值时，抵御模块170阻止所述访问请求，否则，抵御模块170授权所述访问请求。
可选地，在对安全性要求较低，但对易用性要求较高的情况下，该方法还可以包括：
步骤413：当抵御模块做出阻止本次访问的决策后，可以通过用户反馈的机制，请求用户决策该访问主体是否可信，如果可信，那么授权本次请求，并通过行为模型纠偏器151对该次请求信息进行记录，并通过增强学习等方法对访问行为模型和管控策略进行刷新。由于在离线过程训练访问行为模型时，是基于访问行为数据集138的，该数据集为正常CA访问待保护服务/接口的访问行为数据的抽样，因此可能与实际的访问行为存在一定偏差。行为模型纠偏器151的功能是通过实时捕获的行为日志数据，来判断访问行为模型是否与实际访问行为存在偏差，如果存在偏差，那么将通过在线学习方法，对访问行为模型进行更新，DoS攻击分析器160进而根据更新后的访问行为模型更新管控策略。相应地，抵御模块170会基于更新后的管控策略对后续的访问请求进行管控。
本申请实施例通过上述方案，在TEE侧部署行为数据采集器，采集多个预定义正常CA访问待保护服务/接口10的访问行为日志，并输出访问行为数据集，保证了访问行为日志数据采集的可信性。进一步地，基于机器学习方法对正常CA的有限个访问行为参数的概率分布或其上下限进行学习，训练有效的访问行为模型，并根据访问行为模型来确定精确的管控策略，然后基于管控策略对待保护服务/接口上的访问请求进行管控，从而及时抵御利用待保护服务/接口发起的DoS攻击，提升了终端设备的安全性。
下面结合图5和图6来描述抵御终端设备100中的DoS攻击的方法的一个更具体的实施例。假设终端设备100的REE为
Figure PCTCN2018110296-appb-000006
操作系统，TEE为基于信任区域(Trustzone)硬件技术实现的Trusted OS。REE与TEE的交互及其接口完全满足Global Platform对的TEE标准。图5展示了在该实施例中，REE中的CA与TEE中的TA进行交互的流程图，涉及初始化上下文(InitializeContext)，打开会话(OpenSession)，调用命令(InvokeCommand)，关闭会话(CloseSession)，结束上下文(FinalizeContext)等5个主要过程。
CA调用OpenSession接口以使指定TA打开一个与该CA的会话，即Session，该CA后续调用TA的某个服务的操作即在该Session所指定的上下文中进行。因此在TEE中，由于计算资源的限制，不能允许CA无限制地打开某个TA的Session，否则就可能造成DoS攻击。如果预先规定一个CA可以同时打开的Session个数的上限，那么不能避免DoS攻击的发生，而且不能确保预定义的正常CA能够访问成功。若规定的上限值太小，则比较容易遭受DoS攻击，也不能满足正常CA需要；若规定的上限值太大，可能使得资源消耗大，TEE系统资源难于承受，容易崩溃，进而也导致系统拒绝服务的情况。因此一个统一的阈值很难设定，即使设定了也无据可循，很难抵御DoS攻击。
访问OpenSession接口的CA大多由第三方开发。在一个实施例中，如图6所示，我们以其中的三个CA为例，组成预定义的正常CA：指纹CA、数字证书CA和安全键盘CA。图6给出了在申请实施例中，实现抵御DoS功能的关键组件的部署方式。待保护的OpenSession接口处于REE侧用户态的TEE Client API库中，任何CA都可以调用该OpenSession接口，在TEE侧依赖鉴权模型对CA的身份进行认证，但是由于REE侧为非安全侧，恶意CA可以通过仿冒身份信息来绕过TEE侧身份认证机制。关键资源访问代理130负责将预定义的正常CA发起的OpenSession请求打包成安全监控调用(Secure Monitor Call，SMC)命令传递给TEE侧全局任务(Global Task)模块142。为了提升数据采集的安全性，关键资源访问代理130为内核态的进程或线程，其功能可由内核中的Tzdriver组件来承担。Global Task模块为TEE侧访问处理的核心模块，实现了本申请前述实施例中的关键资源申请接口132和访问行为数据采集器134的功能，Global Task模块142中包含了CA的鉴权模型，当CA通过身份认证后，将该CA的访问行为数据进行记录，形成访问行为日志，存储于持久化存储介质中。在离线处理过程，即系统开发阶段，将这些访问行为日志导出，得到针对OpenSession接口的访问行为数据集138。以该访问行为数据集作为数据样本，通过行为建模器150得出可以训练出刻画预定义的正常CA访问行为的访问行为模型，最终由DoS攻击分析器160根据该访问行为模型确定出管控策略固化在抵御模块170中，抵御模块170基于该管控策略来对针对OpenSession接口的访问请求进行安全管控。
在系统开发完成后，在某个CA调用OpenSession接口时，关键资源访问代理130将 发送对应的SMC请求到Global Task模块142，如果该CA通过Global Task模块142的身份认证，那么将CA当前的访问状态发送给抵御模块170，如果抵御模块170根据管控策略授权该次访问，那么将调用对应TA执行打开会话操作，并将会话句柄返回该CA。如果抵御模块170拒绝该次访问，那么可以以对话框的形式，通知用户决策是否授权本次访问，如果用户确认授权，那么说明抵御模块170阻止了正常CA的运行，因此为误判，那么Global Task模块142会将本次访问行为数据进行记录，并传递给行为模型纠偏器151，当行为模型纠偏器151中的数据量达到设定阈值，假设为100条，那么将会启动纠偏过程，以对访问行为模型进行重新学习，并产生新的管控策略，降低系统错误率。
接下来进一步阐述采集访问行为数据集、训练访问行为模型，以及计算管控策略的实现细节。
如图7所示，可以先确定预定义正常CA调用OpenSession接口的一种或多种业务场景，针对每种场景，对各个正常CA调用或访问OpenSession接口进行测试，在测试的过程中，Global Task模块142将每个正常CA每一次的访问行为数据记录到存储器中，例如，Global Task模块142可以记录并维护每个CA访问OpenSession的时间戳、CloseSession的时间戳、以及CA每次请求Session时已持有的Session的数量等等。在特定时机，可以将记录的访问行为数据批量导出，然后分别计算出：(1)同一个CA两次调用OpenSession接口的访问间隔时间J；(2)CA持有Session的时间长度L，即持有OpenSession接口所涉及的关键资源的时间长度(3)同一个CA在访问过程中同时持有Session的数量m。这些参数能够刻画各个正常CA在具体的业务场景下访问OpenSession接口的行为特征，因此，基于计算出的这些参数，可以构建各个正常CA在每种业务场景下的最小行为日志集合，这些最小日志集合最终构成了访问行为数据集。
进一步地，如图8所示，行为建模器150可以遍历各个预定义正常CA(比如指纹CA、数字证书CA、安全键盘CA)在调用OpenSession接口时Global Task模块142记录的访问行为日志集合，通过数据分析过滤掉极端情况下产生的异常行为数据，然后通过机器学习方法训练出每个正常CA的访问行为模型。首先假设访问行为数据集中，每个数据采样都是独立同分步的。CA持有Session的时间长度L和同一个CA两次调用OpenSession接口的间隔时间J的数据的统计分布满足高斯分布。在一个实施例中，对访问行为模型的学习可以建模为(以持有Session的时间长度L为例)求解高斯分布的参数u和σ,使得访问行为数据集合中L的采样值发生的概率最大化。
参数u和σ的模型f1产生访问行为数据集中L的采样值的概率，可以表达为：
Figure PCTCN2018110296-appb-000007
即求解参数u和σ使得上述表达式最大化，其中f即为似然函数。
在本实施例中，采用最大似然方法对L和J的分布参数进行学习，对似然函数求导等零，即可得出参数的近似估计表达式：
Figure PCTCN2018110296-appb-000008
Figure PCTCN2018110296-appb-000009
例如，针对数字证书CA的访问行为数据集进行统计学习后，可得到每个业务场景下的访问行为模型，以支付业务场景为例，得到的L，J的模型为：
u(L)＝100ms,σ(L)＝30ms，u(J)＝10s,σ(J)＝2s，m的最大值为2。
类似地，采用上述算法可以得出各个正常CA在每种场景下的访问行为模型参数。
进一步地，如图9所示，DoS攻击分析器160根据访问行为模型确定出一个或多个管控参数，然后利用其内置的DoS攻击抵御能力分析公式，求解在发生DoS攻击的概率最小的前提下，管控参数的阈值或取值范围。以数字证书CA应用于支付业务为例，根据业务场景可知，终端设备内能够运行的CA个数有限，通常不超过100个，因此设置刚性指标γ＝100。由于假设L，J满足高斯分布，根据高斯分布特点，数据处于在x＝u的3σ的范围内的概率可以高达99.730020％，因此根据模型u(L)＝0.1s,σ(L)＝0.03s，u(J)＝10s,σ(J)＝2s,管控参数a可以以99.730020％的置信度，按照如下方式计算:a＝u(J)-3σ(J)，即计算可得a＝4。同理可得，b＝u(L)+3σ(L)＝0.19。那么当完成DoS攻击所需要的最小资源量Y超出刚性指标γ时，发生DoS攻击的概率最小，为0；其中，Y可以为需要同时运行的恶意程序的个数。因此，根据Y＝(a/b)*m≧γ,可得21.06*m≧100,m≧4.76≈5。
综上，可得管控参数的阈值如下：
a＝4,即访问OpenSession接口的最小时间间隔为4s
b＝0.19,即持有Session的最大时间为0.19s。
m＝5,即一个CA同时持有Session的最大数量的上限为5。
最后，将管控参数的阈值转化为管控策略固化在抵御模块170中。例如，根据上述管控参数的阈值，可以转化得到如下管控策略：
计算CA本次访问OpenSession接口与上一次访问OpenSession接口之间的时间间隔t；
如果(t<4)，那么拒绝本次访问请求；
否则，计算本次访问的CA主体已持有的Session数量s，如果(s>5),那么拒绝本次访问，否则授权本次访问请求。
计算持有该TA的Session的所有CA，如果某个CA持有Session的时间多于0.19s，那么强制释放该CA的Session。
可以将上述管控策略以代码的方式实现，并加载到抵御模块170中，抵御模块170通过执行该代码即可实现访问请求的管控。
图10示出了本申请实施例提供的另一种终端设备200的示例。根据图10，终端设备200包括通信子系统210、电源220、输入设备230、显示设备240、处理单元250、以及存储器260。存储器260存储有计算机程序或指令，该计算机程序包括操作系统294和应用程序292等。处理单元250被配置用于执行存储器260中的计算机程序，从而实现该计算机程序定义的方法，例如处理单元250运行操作系统294从而在终端设备200上实现操作系统的各种功能。
处理单元250可以包括一个或多个处理器，例如，处理单元250可以包括应用处理器、图形处理器、数字信号处理器等。当处理单元250包括多个处理器时，这多个处理器可以 集成在同一块芯片上，也可以各自为独立的芯片。
存储器260还存储有除计算机程序之外的其他数据296，其他数据296可包括操作系统294或应用程序292运行过程中产生的数据，比如系统数据(例如操作系统294的配置参数)和用户数据。
存储器260一般包括内存和外存。内存包括但不限于随机存取存储器(random access memory，RAM)，只读存储器(read-only memory,ROM)，或高速缓存(cache)等。外存包括但不限于闪存(flash memory)、硬盘、通用串行总线(universal serial bus,USB)盘等，计算机程序通常被存储在外存上，处理单元250在执行计算机程序前会将该程序从外存加载到内存。
在一个实施例中，操作系统294中包含了用于实现本申请实施例所提供的抵御DoS攻击的方法的计算机程序，从而使得处理器250运行操作系统294后，实现本申请实施例提供的抵御DoS攻击的方法的步骤。示例性地，前述实施例所描述的关键资源访问代理130、关键资源申请接口132、访问行为数据采集器134、行为建模器150、DoS攻击分析器160以及抵御模块170可以以计算机程序(指令)的方式实现，处理器250加载并运行这些计算机程序(指令)后，实现这些模块各自的功能。
输入设备230，用于接收用户输入信息，比如数字/字符信息、触摸操作或手势，以及产生对应的输入信号。具体地，在一个实施例中，该输入设备230包括触控面板。触控面板，也称为触摸屏，可收集用户在其上的触摸操作，并生成触控信号以驱动相关的组件响应用户的操作。除了触控面板，输入设备230还可以包括其他输入设备，包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。
显示设备240可以为液晶显示器(liquid crystal display，LCD)、有机发光二极管(organic light-emitting diode,OLED)等显示面板。在一些实施例中，触控面板可覆盖显示设备240上，以形成触摸显示屏。
通信子系统210为终端200的基本通信单元，用于终端200的数据发送和接收。电源220用于给上述各个部件供电，具体可以为电源管理芯片。
当终端设备200为无线终端时，通信子系统210包括无线调制解调器(wireless modem)，主要实现基带处理、调制解调、信号放大和滤波、均衡等功能。在一个实施例中，通信子系统210包括：基带处理器、射频电路和天线。其中，射频电路和天线主要负责信号发送和接收；基带处理器负责信号的处理，比如信号的A/D、D/A转换、信号的编解码等等。基带处理器支持无线通信标准中的一种或多种，这里的无线通信标准包括但不限于全球移动通信系统(global system for mobile communications,GSM)、码分多址接入(code division multiple access,CDMA)、宽带码分多址(wideband code division multiple access,WCDMA)、高速分组接入(high speed packet access,HSPA)、长期演进(long-term evolution,LTE)等。基带处理器可以为一个单独的芯片，也可以和处理单元250所包含的处理器可以集成在同一芯片中。
可选地，终端设备200还包括一个或多个传感器280，例如加速度传感器、光传感器等。
本申请实施例提供的抵御DoS攻击的方法可由终端设备200的软件、硬件和/或固件的适当组合执行。例如，可以由图10所示的操作系统294结合必要的硬件来实施。
此外，所属领域的技术人员可以理解终端200可包括比图10中所示部件更少或更多的部件，图10所示的终端设备200仅示出了与本申请实施例所公开的多个实现方式更加相关的部件。
基于以上实施例描述的抵御DoS攻击的方法，本申请实施例还提供一种终端设备400，如图11所示，该终端设备400包括：处理电路402，以及与其连接的通信接口404和存储介质406。
处理电路402用于处理数据，控制数据访问和存储，发出命令以及控制其它组件执行操作。处理电路402可以被实现为一个或多个处理器，一个或多个控制器和/或可用于执行程序的其它结构。处理电路402具体可以包括通用处理器，数字信号处理器(digital signal processor,DSP)，专用集成电路(application-specific integrated circuit,ASIC)，现场可编程门阵列(field-programmable gate array,FPGA)或其它可编程逻辑组件中的至少一种。通用处理器可以包括微处理器，以及任何常规的处理器，控制器，微控制器，或状态机。处理电路402也可以实现为计算组件，例如DSP和微处理器的组合。
存储介质406可以包括非瞬时计算机可读存储介质(non-transitory computer-readable storage medium)，如磁存储设备(例如，硬盘，软盘，磁条)，光存储介质(例如，数字多功能光盘(digital versatile disc,DVD))，智能卡，闪存设备，RAM，ROM，可编程只读存储器(programmable read-only memory,PROM)，可编程可擦除只读存储器(erasable programmable read-only memory,EPROM)，寄存器，以及它们的任意组合。存储介质406可以耦合到处理电路402以使得处理电路402可读取信息和将信息写入到存储介质406。具体地，存储介质406可以集成到处理电路402，或者存储介质406和处理电路402可以是分开的。
通信接口404可包括电路和/或程序以实现终端设备400与一个或多个网络设备(例如，路由器、交换机、接入点等等)之间的双向通信。通信接口404包括至少一个接收电路416和/或至少一个发射电路418。在一个实施例中，通信接口404可以是全部或部分由无线调制解调器来实现。
在一个实施例中，存储介质406中存储有程序(指令)420，处理电路402被适配为执行存储在存储介质406中的程(指令)序420，以实现本申请任一方法实施例中的部分或全部步骤。
本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质存储有实现本申请任一方法实施例中的方法步骤的代码、指令或程序。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
如图12所示，本申请实施例提供的抵御DoS攻击的方法也可以应用于具有双域系统的服务器300，其中服务器300包括互相隔离的非安全域310和安全域320，其中，安全域320的安全等级高于非安全域310。与前述实施例所描述的TEE和REE类似，非安全域310中运行的CA也可以通过特定接口请求安全域320中运行的TA的服务。恶意应用程序可 能会通过频繁调用非安全域310或安全域320中的某个服务/接口11来实现DoS攻击。因此，可以使用本申请前述实施例提供的抵御DoS攻击的方法来保护该服务/接口11。具体的，在安全域320中部署行为数据采集器，采集非安全域310中运行的多个预定义正常CA访问服务/接口11的访问行为日志，并构建访问行为数据集。进一步地，基于机器学习方法训练出一个或多个访问行为模型，并根据访问行为模型来确定精确的管控策略，然后，部署在在安全域320中的抵御模块基于管控策略对服务/接口11上的访问请求进行管控，从而及时抵御利用服务/接口11发起的DoS攻击，提升了设备的安全性。其中，数据采集、模型训练以及访问管控的具体实现细节可以参照前述方法实施例，不在此赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以计算机软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：USB闪存盘、移动硬盘、ROM、RAM、或者光盘等各种可以存储程序代码的介质。

Claims (26)

  1. 一种抵御终端设备中的拒绝服务DoS攻击的方法，所述终端设备包括可信执行环境TEE以及富执行环境REE，所述REE中运行有客户端应用程序CA，其特征在于，所述方法包括：
    接收所述CA对服务/接口发起的访问请求，所述服务/接口为所述REE提供的服务或接口，或者为所述TEE提供的服务或接口；所述CA通过访问所述服务/接口来请求服务或资源；
    将所述访问请求传递给所述TEE中部署的抵御模块；
    所述抵御模块根据管控策略决定是否授权所述访问请求；其中，所述管控策略是根据访问行为模型确定的；所述访问行为模型是通过统计学方法或者机器学习算法对访问行为数据集进行训练后得到的，用于表征至少一个CA访问所述服务/接口的行为特征，其中，所述访问行为数据集包括在所述TEE中采集到的所述至少一个CA访问所述服务/接口的访问行为日志。
  2. 根据权利要求1所述的方法，其特征在于，还包括：
    在所述CA通过身份认证的情况下，将所述访问请求传递给所述TEE中部署的访问行为数据采集器；
    所述访问行为数据采集器记录所述访问请求对应的访问行为日志。
  3. 根据权利要求2所述的方法，其特征在于，还包括：
    所述访问行为数据采集器记录所述至少一个CA对所述服务/接口发起的多个访问请求对应的多个访问行为日志；
    所述访问行为数据采集器根据所述多个访问行为日志构建所述访问行为数据集；所述访问行为数据集合被用于训练所述访问行为模型。
  4. 根据权利要求1至3任一项所述的方法，其特征在于，所述管控策略包括至少一个管控参数的阈值；所述至少一个管控参数是根据所述访问行为模型确定的；所述至少一个管控参数的阈值是基于DoS攻击抵御能力分析公式，在完成DoS攻击所需的最小资源量超出刚性指标的约束条件下求解得到的；其中，其中，所述DoS攻击抵御能力分析公式表征完成DoS攻击所需的最小资源量与管控参数之间的约束关系，所述刚性指标与所述终端设备的硬件资源限制、或者操作系统的限制，或者业务场景的限制相关。
  5. 根据权利要求4所述的方法，其特征在于，所述完成DoS攻击所需的最小资源量为需要在终端设备上同时运行的应用程序的个数；所述刚性指标为终端设备可支持同时运行的应用程序的数量的最大值。
  6. 根据权利要求4或5所述的方法，其特征在于，所述抵御模块根据所述管控策略决定是否授权所述访问请求包括：
    若所述访问请求会触发所述至少一个管控参数超出所述阈值，则阻止所述访问请求，否则，授权所述访问请求。
  7. 根据权利要求6所述的方法，其特征在于，还包括：
    在阻止所述访问请求后，通知用户决策是否授权所述访问请求；
    若所述用户授权所述访问请求，则根据所述访问请求的访问行为日志，更新所述访问 行为模型，以得到更新后的访问行为模型。
  8. 根据权利要求7所述的方法，其特征在于，还包括：
    根据所述更新后的访问行为模型，更新所述管控策略。
  9. 根据权利要求4至8任一项所述的方法，其特征在于，所述多个访问请求对应的多个访问行为日志包括：所述多个访问请求中每一个访问请求的发起实体的信息，所述多个访问请求中每一个访问请求的时间戳，所述多个访问请求中每一个访问请求涉及的资源的数量；所述至少一个管控参数包括如下至少一种：同一CA两次访问所述服务/接口的时间间隔，同一CA持有所述服务/接口相关的资源的数量，以及同一CA持有所述服务/接口相关的资源的时间。
  10. 根据权利要求4至9任一项所述的方法，其特征在于，所述TEE中运行有可信应用程序TA，所述访问请求用于在所述TA中打开一个与所述CA的会话；所述至少一个管控参数包括如下至少一种：同一CA两次访问所述服务/接口的时间间隔，同一CA持有的与所述TA之间的会话数量，以及同一CA持有的与所述TA之间的会话的时间。
  11. 根据权利要求10所述的方法，其特征在于，所述至少一个管控参数的阈值包括：同一CA两次访问所述服务/接口的时间间隔阈值；所述抵御模块根据管控策略决定是否授权所述访问请求包括：
    计算所述CA发起所述访问请求以及所述CA向所述服务/接口发起的上一次访问请求的时间间隔；
    当计算出的时间间隔小于所述时间间隔阈值时，所述抵御模块阻止所述访问请求；
    当所述计算出的时间间隔大于所述时间间隔阈值时，所述抵御模块授权所述访问请求。
  12. 根据权利要求10所述的方法，其特征在于，所述至少一个管控参数的阈值包括：同一CA持有的与所述TA之间的会话数量的上限值；所述抵御模块根据管控策略决定是否授权所述访问请求包括：
    根据所述CA当前的请求状态，确定所述CA已持有的与所述TA之间的会话数量；
    当确定出的会话数量大于或等于所述上限值，则所述抵御模块阻止所述访问请求；
    当所述确定出的会话数量小于所述上限值，则所述抵御模块授权所述访问请求。
  13. 一种终端设备，包括互相隔离的可信执行环境TEE以及富执行环境REE，所述REE中运行有客户端应用程序CA，其特征在于，所述终端设备还包括：
    服务/接口，用于接收所述CA发起的访问请求，并将所述访问请求传递给部署于所述TEE中的抵御模块；其中，所述服务/接口为所述REE提供的服务或接口，或者为所述TEE提供的服务或接口；所述CA通过访问所述服务/接口来请求服务或资源；
    所述抵御模块，用于根据管控策略决定是否授权所述访问请求；其中，所述管控策略是根据访问行为模型确定的；所述访问行为模型是通过统计学方法或者机器学习算法对访问行为数据集进行训练后得到的，用于表征至少一个CA访问所述服务/接口的行为特征，其中，所述访问行为数据集包括在所述TEE中采集到的所述至少一个CA访问所述服务/接口的访问行为日志。
  14. 如权利要求13所述的终端设备，其特征在于，所述服务/接口为所述REE提供的服务或接口；所述服务/接口具体用于，将所述访问请求传递给所述REE中部署的关键资源 访问代理；
    所述关键资源访问代理，用于通过所述TEE部署在所述REE侧的接口，将所述访问请求转发到所述TEE的关键资源申请接口；
    所述关键资源申请接口，用于在所述CA通过身份认证的情况下，将所述访问请求传递给所述抵御模块。
  15. 如权利要求12或13所述的终端设备，其特征在于，还包括：访问行为数据采集器，所述访问行为数据采集器部署于所述TEE中，用于采集所述至少一个CA对所述服务/接口发起的多个访问请求对应的多个访问行为日志，根据所述多个访问行为日志构建所述访问行为数据集；所述访问行为数据集被用于训练所述访问行为模型。
  16. 如权利要求13至15任一项所述的终端设备，其特征在于，还包括：DoS攻击分析器，用于根据所述访问行为模型确定至少一个管控参数；基于DoS攻击抵御能力分析公式，求解在完成DoS攻击所需的最小资源量超出刚性指标的约束条件下，所述至少一个管控参数的阈值；所述管控策略包括所述至少一个管控参数的阈值；其中，其中，所述DoS攻击抵御能力分析公式表征完成DoS攻击所需的最小资源量与管控参数之间的约束关系，所述刚性指标与所述终端设备的硬件资源限制、或者操作系统的限制，或者业务场景的限制相关。
  17. 根据权利要求16所述的终端设备，其特征在于，所述完成DoS攻击所需的最小资源量为需要在终端设备上同时运行的应用程序的个数；所述刚性指标为终端设备可支持同时运行的应用程序的数量的最大值。
  18. 根据权利要求16或17所述的终端设备，其特征在于，所述抵御模块具体用于，若所述访问请求会触发所述至少一个管控参数超出所述阈值，则阻止所述访问请求，否则，授权所述访问请求。
  19. 如权利要求18所述的终端设备，其特征在于，还包括：行为模型纠偏器；所述抵御模块还用于，在阻止所述访问请求后，通知用户决策是否授权所述访问请求；若所述用户授权所述访问请求，则触发所述行为模型纠偏器根据所述访问请求的访问行为日志，更新所述访问行为模型，以得到更新后的访问行为模型。
  20. 如权利要求19所述的终端设备，其特征在于，所述DoS攻击分析器还用于，根据所述更新后的访问行为模型，更新所述管控策略。
  21. 根据权利要求15至20任一项所述的终端设备，其特征在于，所述多个访问请求对应的多个访问行为日志包括：所述多个访问请求中每一个访问请求的发起实体的信息，所述多个访问请求中每一个访问请求的时间戳，所述多个访问请求中每一个访问请求涉及的资源的数量；所述至少一个管控参数包括如下至少一种：同一CA两次访问所述服务/接口的时间间隔，同一CA持有所述服务/接口相关的资源的数量，以及同一CA持有所述服务/接口相关的资源的时间。
  22. 根据权利要求13至21任一项所述的终端设备，其特征在于，所述TEE中运行有可信应用程序TA，所述访问请求用于在所述TA中打开一个与所述CA的会话；所述至少一个管控参数包括如下至少一种：同一CA两次访问所述服务/接口的时间间隔，同一CA持有的与所述TA之间的会话数量，以及同一CA持有的与所述TA之间的会话的时间。
  23. 如权利要求22所述的终端设备，其特征在于，所述至少一个管控参数的阈值包括：同一CA两次访问所述服务/接口的时间间隔阈值；
    所述抵御模块具体用于，计算所述CA发起所述访问请求以及所述CA向所述服务/接口发起的上一次访问请求的时间间隔；当计算出的时间间隔小于所述时间间隔阈值时，阻止所述访问请求；当所述计算出的时间间隔大于所述时间间隔阈值时，授权所述访问请求。
  24. 如权利要求22所述的终端设备，其特征在于，所述至少一个管控参数的阈值包括：同一CA持有的与所述TA之间的会话数量的上限值；
    所述抵御模块具体用于，根据所述CA当前的请求状态，确定所述CA已持有的与所述TA之间的会话数量；当确定出的会话数量大于或等于所述上限值，则阻止所述访问请求；当所述确定出的会话数量小于所述上限值，则授权所述访问请求。
  25. 一种终端设备，包括处理器、存储器及存储在所述存储器上并可被所述处理器执行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至12中任一项所述方法的步骤。
  26. 一种计算机可读存储介质，其上存储有计算机程序(指令)，其特征在于，所述程序(指令)被处理器执行时实现权利要求1至12中任一项所述方法的步骤。
PCT/CN2018/110296 2017-11-14 2018-10-15 一种抵御拒绝服务攻击的方法及设备 WO2019095911A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP18877968.0A EP3694170B1 (en) 2017-11-14 2018-10-15 Method and device for withstanding denial-of-service attack
US16/870,203 US20200274898A1 (en) 2017-11-14 2020-05-08 Method And Device For Defending Against Denial Of Service Attacks

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201711124979.3 2017-11-14
CN201711124979.3A CN109787943B (zh) 2017-11-14 2017-11-14 一种抵御拒绝服务攻击的方法及设备

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/870,203 Continuation US20200274898A1 (en) 2017-11-14 2020-05-08 Method And Device For Defending Against Denial Of Service Attacks

Publications (1)

Publication Number Publication Date
WO2019095911A1 true WO2019095911A1 (zh) 2019-05-23

Family

ID=66493533

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/110296 WO2019095911A1 (zh) 2017-11-14 2018-10-15 一种抵御拒绝服务攻击的方法及设备

Country Status (4)

Country Link
US (1) US20200274898A1 (zh)
EP (1) EP3694170B1 (zh)
CN (1) CN109787943B (zh)
WO (1) WO2019095911A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110545541A (zh) * 2019-09-20 2019-12-06 百度在线网络技术（北京）有限公司 防御攻击行为的方法、装置、设备、终端和介质
CN115630373A (zh) * 2022-12-21 2023-01-20 四川知行志成科技有限公司 一种云服务安全分析方法、监控设备及分析系统

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11556730B2 (en) * 2018-03-30 2023-01-17 Intel Corporation Methods and apparatus for distributed use of a machine learning model
CN110430158B (zh) * 2019-06-13 2020-07-03 中国科学院信息工程研究所 采集代理部署方法及装置
GB2586640B (en) * 2019-08-30 2021-12-08 Trustonic Ltd Trusted execution environment scheduling method
CN112765106B (zh) * 2019-10-21 2024-05-14 伊姆西Ip控股有限责任公司 文件访问方法、电子设备和计算机程序产品
US11416585B2 (en) * 2019-12-18 2022-08-16 Disney Enterprises, Inc. Define return value at runtime
CN111148070B (zh) * 2019-12-31 2021-06-15 华为技术有限公司 V2x通信方法、装置及车辆
US11436343B2 (en) * 2019-12-31 2022-09-06 Arm Limited Device, system, and method of policy enforcement for rich execution environment
CN113138878B (zh) * 2020-01-19 2022-11-18 华为技术有限公司 可信执行环境操作系统崩溃处理方法及电子设备
CN111949986B (zh) * 2020-02-19 2023-10-03 华控清交信息科技(北京)有限公司 业务处理方法、系统及存储介质
US11537913B2 (en) * 2020-03-12 2022-12-27 Aetna Inc. Artificial intelligence automation for enrollment
GB2594789A (en) * 2020-03-17 2021-11-10 Capital One Services Llc Adaptive artificial intelligence systems and methods for token verification
US10979422B1 (en) 2020-03-17 2021-04-13 Capital One Services, Llc Adaptive artificial intelligence systems and methods for token verification
CN113742740A (zh) * 2020-05-29 2021-12-03 华为技术有限公司 设备行为监督方法、装置及存储介质
CN113946528A (zh) * 2020-07-16 2022-01-18 华为技术有限公司 切换系统架构的方法与装置
CN112100625B (zh) * 2020-09-14 2021-10-19 浙江大学 一种基于模型检测的操作系统访问控制脆弱性发现方法
CN114462589B (zh) * 2021-09-28 2022-11-04 北京卫达信息技术有限公司 正常行为神经网络模型训练方法、系统、装置及存储介质
CN114124463B (zh) * 2021-10-27 2023-05-16 中国电子科技集团公司第三十研究所 基于网络行为特征的暗网加密应用服务识别方法及系统
CN113792276A (zh) * 2021-11-11 2021-12-14 麒麟软件有限公司 基于双体系结构的操作系统用户身份认证方法及系统
CN114070638B (zh) * 2021-11-22 2023-07-18 安天科技集团股份有限公司 一种计算机系统安全防御方法、装置、电子设备及介质
CN115017497B (zh) * 2021-11-24 2023-04-18 荣耀终端有限公司 信息处理方法、装置及存储介质
CN115016886B (zh) * 2021-12-31 2023-04-11 荣耀终端有限公司 业务处理方法和装置
CN114398653B (zh) * 2022-01-13 2022-11-08 百度在线网络技术（北京）有限公司 数据处理方法、装置、电子设备及介质
CN115037482A (zh) * 2022-06-10 2022-09-09 维沃移动通信有限公司 欺诈行为检测方法、装置、电子设备及可读存储介质
CN115086036B (zh) * 2022-06-15 2024-04-26 浙江浩瀚能源科技有限公司 云平台的安全防护方法、装置、设备及存储介质
CN116070280B (zh) * 2023-04-06 2023-06-27 中诚华隆计算机技术有限公司 一种安全访问统计装置、方法和芯片
CN116483733A (zh) * 2023-06-12 2023-07-25 数据堂（北京）科技股份有限公司 多维度人工智能产品评测方法及装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105809036A (zh) * 2016-04-01 2016-07-27 中国银联股份有限公司 一种tee访问控制方法以及实现该方法的移动终端
CN105978917A (zh) * 2016-07-19 2016-09-28 恒宝股份有限公司 一种用于可信应用安全认证的系统和方法
CN106796639A (zh) * 2014-09-26 2017-05-31 迈克菲股份有限公司 用于可信执行环境的数据挖掘算法
US20170277869A1 (en) * 2016-03-25 2017-09-28 Mstar Semiconductor, Inc. Computing device and data processing method
US20170317990A1 (en) * 2016-05-02 2017-11-02 Samsung Electronics Co., Ltd. Apparatus and method for managing virtual subscriber indentity module

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI543014B (zh) * 2015-01-20 2016-07-21 動信科技股份有限公司 快速佈署可信任執行環境應用的系統與方法
CN104683336B (zh) * 2015-02-12 2018-11-13 中国科学院信息工程研究所 一种基于安全域的安卓隐私数据保护方法及系统
US20160241576A1 (en) * 2015-02-13 2016-08-18 Canon Kabushiki Kaisha Detection of anomalous network activity
CN104765612B (zh) * 2015-04-10 2018-05-08 武汉天喻信息产业股份有限公司 一种访问可信执行环境、可信应用的系统及方法
CN105138904B (zh) * 2015-08-25 2018-06-15 华为技术有限公司 一种访问控制方法和装置
CN105468980B (zh) * 2015-11-16 2018-07-03 华为技术有限公司 一种安全管控的方法、装置及系统
EP3179690A1 (en) * 2015-12-11 2017-06-14 Gemalto Sa Mobile device having trusted execution environment

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106796639A (zh) * 2014-09-26 2017-05-31 迈克菲股份有限公司 用于可信执行环境的数据挖掘算法
US20170277869A1 (en) * 2016-03-25 2017-09-28 Mstar Semiconductor, Inc. Computing device and data processing method
CN105809036A (zh) * 2016-04-01 2016-07-27 中国银联股份有限公司 一种tee访问控制方法以及实现该方法的移动终端
US20170317990A1 (en) * 2016-05-02 2017-11-02 Samsung Electronics Co., Ltd. Apparatus and method for managing virtual subscriber indentity module
CN105978917A (zh) * 2016-07-19 2016-09-28 恒宝股份有限公司 一种用于可信应用安全认证的系统和方法

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110545541A (zh) * 2019-09-20 2019-12-06 百度在线网络技术（北京）有限公司 防御攻击行为的方法、装置、设备、终端和介质
CN110545541B (zh) * 2019-09-20 2023-06-23 百度在线网络技术（北京）有限公司 防御攻击行为的方法、装置、设备、终端和介质
CN115630373A (zh) * 2022-12-21 2023-01-20 四川知行志成科技有限公司 一种云服务安全分析方法、监控设备及分析系统

Also Published As

Publication number Publication date
CN109787943A (zh) 2019-05-21
US20200274898A1 (en) 2020-08-27
EP3694170B1 (en) 2023-08-30
CN109787943B (zh) 2022-02-22
EP3694170A4 (en) 2020-10-14
EP3694170A1 (en) 2020-08-12

Similar Documents

Publication Publication Date Title
WO2019095911A1 (zh) 一种抵御拒绝服务攻击的方法及设备
US9607140B2 (en) Authenticating a user of a system via an authentication image mechanism
CN107005543B (zh) 用于防止未经授权的网络入侵的系统和方法
EP3029593B1 (en) System and method of limiting the operation of trusted applications in the presence of suspicious programs
US20220124097A1 (en) Fictitious account generation on detection of account takeover conditions
US8776196B1 (en) Systems and methods for automatically detecting and preventing phishing attacks
US20160350534A1 (en) System, apparatus and method for controlling multiple trusted execution environments in a system
US10867048B2 (en) Dynamic security module server device and method of operating same
US20230370488A1 (en) Third-party application risk assessment in an authorization service
US10169567B1 (en) Behavioral authentication of universal serial bus (USB) devices
US10142308B1 (en) User authentication
CN105531709A (zh) 可执行对象在本地设备上的受信任的执行
US9888035B2 (en) Systems and methods for detecting man-in-the-middle attacks
US10885162B2 (en) Automated determination of device identifiers for risk-based access control in a computer network
TW202105211A (zh) 業務系統的存取方法及裝置
US10019577B2 (en) Hardware hardened advanced threat protection
CN112511618A (zh) 边缘物联代理防护方法及电力物联网动态安全可信系统
US11176276B1 (en) Systems and methods for managing endpoint security states using passive data integrity attestations
CN111917696A (zh) 使用不可旁路的网关的基于tpm的安全多方计算系统
De Oliveira Nunes et al. On the root of trust identification problem
EP3044721B1 (en) Automatic pairing of io devices with hardware secure elements
CN113821841B (zh) 资源管理方法、计算装置、计算设备和可读存储介质
US11799857B2 (en) Software posture for zero trust access
Zou et al. A survey of android mobile platform security
CN117134999B (zh) 一种边缘计算网关的安全防护方法、存储介质及网关

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18877968

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2018877968

Country of ref document: EP

Effective date: 20200507

NENP Non-entry into the national phase

Ref country code: DE