WO2017033180A1 - System and method for monitoring and protecting an untrusted operating system by means of a trusted operating system - Google Patents
System and method for monitoring and protecting an untrusted operating system by means of a trusted operating system Download PDFInfo
- Publication number
- WO2017033180A1 WO2017033180A1 PCT/IL2016/050899 IL2016050899W WO2017033180A1 WO 2017033180 A1 WO2017033180 A1 WO 2017033180A1 IL 2016050899 W IL2016050899 W IL 2016050899W WO 2017033180 A1 WO2017033180 A1 WO 2017033180A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- main
- domain
- trusted
- trusted domain
- services
- Prior art date
Links
Classifications
-
- 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
-
- 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0227—Filtering policies
- H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
-
- 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
-
- 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
-
- 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/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
- G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
- G06F21/74—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information operating in dual or compartmented mode, i.e. at least one secure mode
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45587—Isolation or security of virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45595—Network integration; Enabling network access in virtual machine instances
Definitions
- the invention relates in general to the field of cyber-security. More specifically, the invention relates to an improved structure for protecting an untrusted operating system by using an extensible operating system which operates within a trusted zone, thereby to provide better security and novel maintenance options compared to the prior art.
- Trusted Execution Environments are commonly used as a "safe container” for executing processes or services in a trusted manner. Examples of TEE implementations are the ARM TrustZone, and Intel TEE.
- the common TEE architecture combines the main operating system (OS) running on the main processor(s) and having its own “main domain” (also referred herein as the "normal domain"), and a single process or a set of processes that run within another, more privileged and trusted section of the processor, which is commonly referred to as a "trusted domain” or “secured domain”.
- a "Trusted Domain OS” which is separate, and most often also different in structure, language and layer from the main OS, operates within said privileged secured domain.
- the access to the Trusted Domain OS can be performed (in a privileged manner) only via the main OS, both for the purpose of its configuration, and for the purpose of receiving service from it in run time.
- the trusted zone is typically used to store encryption and decryption keys.
- the main OS submits data to the trusted- domain OS, which in turn uses a respective process running within the trusted domain to encrypt or decrypt said data, respectively, and return the results to the main OS.
- the TEE structure is not so commonly used in embedded systems, and moreover, when used, it is commonly applied for performing limited and specific functionalities.
- a user or a process may receive service from the trusted domain only via the main OS.
- the main OS is typically accessible to a wide range of users, devices, and processes, particularly when the system includes a network.
- the ability to access and receive services from the trusted domain is limited and privileged, still the main OS itself is susceptible to malicious code manipulations, in view of its availability to such a wide range of users and processes. Therefore, even though the trusted domain is relatively secured in itself, the fact that the interaction with the trusted domain is implemented via the relatively susceptible environment of the main OS, significantly degrades the security of operation with the trusted domain and its resources.
- a hypervisor is commonly used in computer systems as a privileged, low level layer below the operating system.
- the hypervisor also called a "virtual machine manager", or a “virtual machine monitor” is a piece of low level software, firmware or hardware.
- the hypervisor is commonly used to create and run virtual machines, allowing multiple operating systems to share a single hardware host. Each operating system appears to have the host's processor, memory, and other resources all to itself. In such a manner and structure, a plurality of "virtual machines" is implemented on a single hardware machine.
- TEE and the hypervisor are sometimes implemented on a same machine, their typical functions are totally isolated, namely, one allows receiving services from a trusted-privileged zone, and the other virtually provides the possibility for a plurality of virtual machines to operate on a single machine.
- the invention relates to a TEE (Trusted Environment Execution) structure which comprises : (a) a main domain defining a domain of operation for a main OS; (b) a privileged trusted domain defining a domain of operation for a trusted domain OS; and (c) a low level hypervisor which is separated from both of said main OS and said trusted domain OS, said hypervisor is used for: (c. l) receiving packets from a network; (c.2) examining an address included in each of said received packets; and (c.3) based on the determined address in each of said packets, targeting respectively the packet to either said main OS or to said trusted domain OS, while in the latter case any interaction between the received packet and said main OS is eliminated.
- TEE Truste Execution
- said received packets that are targeted to the trusted domain OS convey information to one or more services running by said trusted domain OS at said trusted domain, and wherein results obtained by said running services are conveyed in a packet form back to the hypervisor, which respectively routes the packet to a target entity at the network, without any interaction with said main OS.
- said examination by the hypervisor of the packet address is performed on a MAC address within said packet.
- said one or more services of the trusted domain OS analyze data relating to the main OS in a non-invasive manner, while said services of the trusted domain OS are operated by an external entity at the network by means of said packets, respectively, while entirely avoiding any interaction between the packets that carry operation instructions or service results respectively, and the main OS.
- the trusted domain OS comprises a check-alive service for periodically or upon receipt of an external trigger, checks that the main OS is alive, namely that it is not in a halt state.
- the trusted domain OS comprises an introspection process list service which extracts a list of currently running services from the main OS, for further inspection and analysis within the domain of the trusted OS.
- the trusted domain OS comprises an introspection process memory dump service which halts the main OS, and extracts from the run-time memory that stores the main OS, a section of its memory for further inspection and analysis within the domain of the trusted OS.
- said inspection and analysis comprises scanning the memory for patterns or signatures relating to malicious code.
- said trusted domain OS comprises a main domain reboot service that causes reboot of the main OS from within the trusted domain, with no intervention whatsoever of the main OS.
- said trusted domain OS comprises a main-domain software update service for performing an update procedure of the main OS, wherein said update procedure is performed by said service periodically halting the processor which runs the main OS, replacing sections of contents of the memory which contains the main OS, and rerunning the main OS.
- the hypervisor comprises a timer for independently triggering processes within one or more of the services of the trusted domain OS.
- Fig. 1 shows in a general block diagram form a structure of a prior art TEE system having a main domain and a trusted domain;
- Fig. 2 shows in a general block diagram form still another structure of a conventional prior art TEE system having a main domain and a trusted domain;
- Fig. 3 shows in a general block diagram form a novel structure for performing secured operations within the trusted domain 130 of the processor, according to the present invention.
- Fig. 4 shows in a general block diagram form still another example of a structure of a TEE system according to an embodiment of the present invention.
- Fig. 1 illustrates in a block diagram form the general structure of a typical TEE, according to the prior art.
- TEE structure such as ARM TrustZone, or Intel TEE
- two separate domains of operation are defined ⁇ (l) a normal (main) domain 20 of the Main OS 21; and (2) a trusted domain 30 of the Trusted-Domain OS 31.
- the Trusted Domain OS 31, which comprises one or more services Si, S2, ...S n is typically different from the Main OS in structure and language, and is more targets oriented.
- the interaction between said two operating systems, 20 and 30, respectively, is typically performed via an interface 40 which is susceptible to malicious code, as it resides within the memory domain of the less privileged main OS.
- a user While in offline, a user can define the trusted domain OS 31 only via the main OS 21. Likewise, during runtime, either a user program or a network packet may interact with the trusted domain OS 31 only via the Main OS 21 (and interface 40).
- Fig. 2 shows in a general block diagram form still another structure of a conventional prior art TEE system having a main domain 20 and a trusted domain 30.
- the main OS resides in the main domain 20
- the trusted domain OS resides in the trusted domain 30.
- each of said operating systems is divided into a user space section (25 and 35 respectively) residing in a less privileged level PL0, and a kernel space section (26 and 36 respectively) residing in a more privileged level PL1.
- the trusted domain 30 provides highly secured services to the main domain 20, for example, encryption/decryption services, keys storing, integrity checks, etc.
- the main domain typically communicates with the secured (trusted) domain via a dedicated API (not shown).
- the main domain 20 conveys to the trusted domain 30 requests for services.
- the requests 28 and 29 are issued either from the user space 25, or from the kernel space 26 of the main domain 20.
- the processor transfers the control to the trusted domain 30, which in turn processes the request and returns the results and control to the main domain 20.
- a request for a trusted domain service may result, for example, from a network packet 50, or a user space program (not shown) which causes issuance of a system call to the kernel space 26.
- the prior art architecture of Figs. 1 and 2, which requires submission of requests to the secured domain via the main domain has several drawbacks in term of security.
- the operating system 20 at the main domain can be compromised, for example, by the injection of malicious code.
- the main operating system 21 (Fig. l) which resides in the main domain 20 is compromised, an adversary may exploite this compromise to manipulate all the requests that pass through the main OS.
- a valid request is conveyed to the main domain 20 (for example, from a network packet) to initiate a call to the secured domain 30, a malicious code at the main OS may intercept the request, abort the call to the trusted domain 30, and return its own faked response.
- a malicious code at the main domain 20 may perform a denial of service (DoS) attack on the trusted domain to entirely prevent receipt of request calls at the trusted domain.
- DoS denial of service
- the present invention provides a structure that eliminates a possible exploitation of the trusted domain 30 by maliciously affecting the main OS at the main domain 20.
- Fig. 3 shows in a general block diagram form a novel structure for performing secured operations within the trusted domain 130 of the processor, according to the present invention.
- the system further comprises a highly privileged low level "hypervisor" 180 (at a privileged level PL3), which is used to route packets that arrive from the network 150 either to the main OS 121 or to the trusted domain OS 131. More specifically, those packets arriving hypervisor 180 that are targeted to the trusted domain OS 131 are conveyed directly to the trusted domain OS 131, while avoiding any passage through or interaction with both the main OS 121 and the high level API (not shown) at the main domain.
- hypervisor 180 at a privileged level PL3
- said highly secured direct channel to the trusted domain OS is defined as the only possible channel to the trusted domain 130 (while eliminating entirely the channels 141 and 142 from the main OS to the trusted domain OS). Moreover, processing results from the trusted operating system which operates at the trusted domain 131 are conveyed back to the issuing entity in the network 150 via the hypervisor 180, while entirely avoiding any interaction with the main operating system.
- said highly secured channel is provided in addition to the conventional channels, 141 and 142 respectively, from the user space 125 and from the kernel space 126 of the main OS 121 to the kernel space 139 of the trusted domain OS 131. More specifically, in said latter embodiment the user may still use said two conventional channels 141 and 142 to the trusted domain, while being aware that said conventional channels may be compromised.
- packets from network 150 that are targeted to the trusted domain OS 131 are differentiated from packets that are targeted to the main OS 121 by their MAC address.
- the hypervisor 180 inspects the header of each arriving packet, and accordingly directs the packet either to the main OS 121, or directly to the trusted domain OS 131 based on the MAC address.
- This manner of differentiation between the packets is very simple and efficient, therefore the routing of the packets respectively can be performed by hypervisor 150 in a very fast manner.
- the trusted operating system 131 may comprise a variety of services, such as: maintenance services, introspection services, debugging and memory-acquisition services, integrity check services, and security and cyber-defense services.
- all said services of the trusted domain OS 131 operate in a way which is entirely independent from the main OS 121, as the interaction between an external entity and the trusted domain OS 131 is performed directly, by means of packets passing via the hypervisor, and avoiding any interaction whatsoever with the main OS 121 (i.e., without changing or modifying the main OS memory or execution-flow). Therefore, this structure and manner of operation is much safer compared to the prior art.
- the trusted OS runs alongside the main OS in the TEE, and performs operations on the main OS in a non-invasive way.
- the trusted operating system services may perform the following non ⁇ invasive operations on the main OS:
- the services of the trusted domain OS may be triggered if one the following events occurs :
- Timer triggered periodic (for example, every 1000ms);
- the trusted domain OS 131 may perform an integrity analysis of the main OS 121, by periodically halting the main OS 121, performing memory acquisition, and scanning and inspecting the extracted memory section for a possible existence of malicious code. As said, this is done while avoiding any interaction or dependence on the main OS 121.
- the services of the trusted domain OS 131 may perform "heartbeat" checks on the main OS 121, for example, checking the processor and its core activities to determine whether the main OS 121 is fully functioning;
- the services of the trusted domain OS 131 a system -load monitoring of the main OS, and sampling of the processor loads and processor counters; 5.
- the services of the trusted domain OS 131 may check the memory usage of the main OS 121, for example, by checking the free and allocated memory tables;
- the services of the trusted domain OS 131 may check for exceptions and interrupts that may occur in the main OS 121, for example, monitoring of hardware interrupts and exceptions.
- the services of the trusted domain OS 131 may halt the main OS, for example, by halting the processors or the cores by an appropriate request;
- the services of the trusted domain OS 131 may initiate a shutdown process of the main OS 121, for example, by triggering a shutdown interrupt of the main OS 121.
- the services of the trusted domain OS 131 may extract a process/thread list of the main OS 121, namely, it may perform introspective analysis of the main memory and extract the process and thread list;
- the services of the trusted domain OS 131 may check for network activity reports, namely, it may report the current open TCP/IP ports as reflected in the main OS handles;
- the services of the trusted domain OS 131 may reconstruct and parse various kernel objects of the main OS 121;
- the services of the trusted domain OS 131 may open file handle lists to reconstructing and parse various handle list tables;
- the services of the trusted domain OS 131 may extract memory and object allocation tables or other kernel elements for reconstruction of them.
- Debugging and memory acquisition services 14.
- the services of the trusted domain OS 131 may extract system and kernel memory by range!
- the services of the trusted domain OS 131 may perform system debugging and trace at various levels;
- the services of the trusted domain OS 131 may perform kernel panic monitoring
- the services of the trusted domain OS 131 may extract system logs
- the services of the trusted domain OS 131 may issue critical alerts
- the services of the trusted domain OS 131 may extract memory content in a case of failure for offline analysis
- the services of the trusted domain OS 131 may analyze and detect memory corruptions
- the services of the trusted domain OS 131 may validate in- memory kernel integrity of the main OS 121, namely, a validation of the kernel integrity on load and other invariant parts after the load;
- the services of the trusted domain OS 131 may validate perform in-memory driver integrity check of the main OS 121, namely validation of drivers integrity, and on-load and after-load signatures;
- the services of the trusted domain OS 131 may validate in- memory application/process integrity
- the services of the trusted domain OS 131 may file system integrity check in a persistent storage.
- the services of the trusted domain OS 131 may perform implement a trusted firewall outside of the main OS 121;
- the services of the trusted domain OS 131 may also perform trusted packet and I/O encryption and decryption for entities external of the main OS;
- the services of the trusted domain OS 131 may also perform a trusted signing mechanism, namely, it may sign packets outside of the main OS 121;
- the services of the trusted domain OS 131 may also perform a trusted memory scanning, namely, it may scan the memory for malicious signature, vulnerabilities and corruptions.
- Fig. 4 shows still another example of a structure of a TEE system according to an embodiment of the present invention.
- Monitor 181 within hypervisor 180 may receive an FIQ interrupt from either an entity in the network 150 (in a form of a packet - as described above) or from an internal timer 187. If the interrupt comes from the network, the packet is conveyed to a routing unit 182. The routing unit inspects the MAC address of the packet. If the MAC address relates to the main OS 121, the packet is forwarded to the main OS. Otherwise, when the MAC address relates to the TEE, the packet is forwarded to the TEE service dispatcher 132 within the secured domain 131. The TEE service dispatcher may then activate one or more of the exemplary services 133, 134, 135, 136, or 137, respectively.
- the Check Alive service 133 checks various elements of the main OS to ensure that it is not halted (i.e., that the OS is indeed running).
- the Introspection Process List service 134 extracts the list of currently running services from the main OS 121, for further inspection and analysis within the trusted OS 121 domain.
- the Introspection Process Memory Dump service 135 halts the main OS 121, and extracts from the main OS 121 a section of its memory, for further inspection and analysis within the trusted OS 121 domain.
- the Main Domain Reboot service 136 performs reboot of the main OS 121 upon a specific event or trigger.
- Main Domain Software Update service 137 performs an updating procedure of the main OS 121. This procedure is performed by periodical halting the processor which runs the main OS, replacing sections of the memory, and rerunning the main OS.
- the interrupt is conveyed from the monitor to the TEE service dispatcher, which in turn activates one of the services, 132-137, respectively.
- the secured services 133-137 may be triggered by one the following events :
- Periodic timer 187 trigger - A secured service begins execution every given period of time. The wakeup is managed via timer 187 interrupts. Example for a service which is activated is the check alive service 133 which checks every 10 seconds that the operating system is alive (i.e., that it is not halted); 2. Timer triggered, setup timer - A secured service begins execution of some procedure a predetermined time after the occurrence of a predefined event;
- Hardware event trigger - The secured service begins execution upon a hardware event as determined by the secured OS 131. This may occur, for example, when an I/O operation begins or is completed, or upon arrival or sending of a network packet;
- Network command triggered - The secured service begins execution when a command from the network 150 is received within a packet from the routing unit 182.
- the above types of events are managed in the internal queues of the trusted OS 131, and are mapped to the appropriate services.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Mathematical Physics (AREA)
- Computing Systems (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Debugging And Monitoring (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention relates to a TEE (Trusted Environment Execution) structure which comprises : (a) a main domain defining a domain of operation for a main OS; (b) a privileged trusted domain defining a domain of operation for a trusted domain OS; and (c) a low level hypervisor which is separated from both of said main OS and said trusted domain OS, said hypervisor is used for: (c. 1) receiving packets from a network; (c.2) examining an address included in each of said received packets; and (c.3) based on the determined address in each of said packets, targeting respectively the packet to either said main OS or to said trusted domain OS, while in the latter case any interaction between the received packet and said main OS is eliminated.
Description
SYSTEM AND METHOD FOR MONITORING AND PROTECTING AN UNTRUSTED OPERATING SYATEM BY MEANS OF A TRUSTED
OPERATING SYTEM
Field of Invention
The invention relates in general to the field of cyber-security. More specifically, the invention relates to an improved structure for protecting an untrusted operating system by using an extensible operating system which operates within a trusted zone, thereby to provide better security and novel maintenance options compared to the prior art.
Background of the Invention
Trusted Execution Environments (TEEs) are commonly used as a "safe container" for executing processes or services in a trusted manner. Examples of TEE implementations are the ARM TrustZone, and Intel TEE. The common TEE architecture combines the main operating system (OS) running on the main processor(s) and having its own "main domain" (also referred herein as the "normal domain"), and a single process or a set of processes that run within another, more privileged and trusted section of the processor, which is commonly referred to as a "trusted domain" or "secured domain". Typically, a "Trusted Domain OS", which is separate, and most often also different in structure, language and layer from the main OS, operates within said privileged secured domain. The access to the Trusted Domain OS can be performed (in a privileged manner) only via the main OS, both for the purpose of its configuration, and for the purpose of receiving service from it in run time.
In one example, the trusted zone is typically used to store encryption and decryption keys. The main OS, in turn, submits data to the trusted- domain OS, which in turn uses a respective process running within the
trusted domain to encrypt or decrypt said data, respectively, and return the results to the main OS.
The TEE structure is not so commonly used in embedded systems, and moreover, when used, it is commonly applied for performing limited and specific functionalities.
As described, a user or a process may receive service from the trusted domain only via the main OS. However, the main OS is typically accessible to a wide range of users, devices, and processes, particularly when the system includes a network. Although the ability to access and receive services from the trusted domain is limited and privileged, still the main OS itself is susceptible to malicious code manipulations, in view of its availability to such a wide range of users and processes. Therefore, even though the trusted domain is relatively secured in itself, the fact that the interaction with the trusted domain is implemented via the relatively susceptible environment of the main OS, significantly degrades the security of operation with the trusted domain and its resources.
In another aspect, a hypervisor is commonly used in computer systems as a privileged, low level layer below the operating system. The hypervisor, also called a "virtual machine manager", or a "virtual machine monitor", is a piece of low level software, firmware or hardware. In one example, the hypervisor is commonly used to create and run virtual machines, allowing multiple operating systems to share a single hardware host. Each operating system appears to have the host's processor, memory, and other resources all to itself. In such a manner and structure, a plurality of "virtual machines" is implemented on a single hardware machine.
Even though the TEE and the hypervisor are sometimes implemented on a same machine, their typical functions are totally isolated, namely, one
allows receiving services from a trusted-privileged zone, and the other virtually provides the possibility for a plurality of virtual machines to operate on a single machine.
In still another aspect, many systems are required to be turned off relatively frequently to allow performance of maintenance or software updates. However, the turning off becomes almost impossible in essential systems like embedded systems that handle very sensitive processes. The fact that such systems can only rarely be turned off (for example, for maintenance and software upgrade purposes), leads to a situation where the security and performance of the system are compromised.
Moreover, the inspection and analysis with respect to the integrity of the main OS during runtime, even when they are performed by services of the trusted domain OS, are also compromised, as the interaction with said services of the trusted domain OS must be performed via the relatively unsecured environment (i.e., domain) of the main OS.
It is an object of the present invention to provide a structure which significantly improves the security of interaction with the trusted domain of a TEE structure, and with the resources running therewith.
It is still another object of the present invention to provide a structure that enables performance of a secured maintenance and software updates during runtime, particularly in embedded systems.
Other objects and advantages of the invention will become apparent as the description proceeds.
Summary of the Invention
The invention relates to a TEE (Trusted Environment Execution) structure which comprises : (a) a main domain defining a domain of operation for a main OS; (b) a privileged trusted domain defining a domain of operation for a trusted domain OS; and (c) a low level hypervisor which is separated from both of said main OS and said trusted domain OS, said hypervisor is used for: (c. l) receiving packets from a network; (c.2) examining an address included in each of said received packets; and (c.3) based on the determined address in each of said packets, targeting respectively the packet to either said main OS or to said trusted domain OS, while in the latter case any interaction between the received packet and said main OS is eliminated.
In an embodiment of the invention, said received packets that are targeted to the trusted domain OS convey information to one or more services running by said trusted domain OS at said trusted domain, and wherein results obtained by said running services are conveyed in a packet form back to the hypervisor, which respectively routes the packet to a target entity at the network, without any interaction with said main OS.
In an embodiment of the invention, said examination by the hypervisor of the packet address is performed on a MAC address within said packet.
In an embodiment of the invention, said one or more services of the trusted domain OS analyze data relating to the main OS in a non-invasive manner, while said services of the trusted domain OS are operated by an external entity at the network by means of said packets, respectively, while entirely avoiding any interaction between the packets that carry operation instructions or service results respectively, and the main OS.
In an embodiment of the invention, the trusted domain OS comprises a check-alive service for periodically or upon receipt of an external trigger, checks that the main OS is alive, namely that it is not in a halt state.
In an embodiment of the invention, the trusted domain OS comprises an introspection process list service which extracts a list of currently running services from the main OS, for further inspection and analysis within the domain of the trusted OS.
In an embodiment of the invention, the trusted domain OS comprises an introspection process memory dump service which halts the main OS, and extracts from the run-time memory that stores the main OS, a section of its memory for further inspection and analysis within the domain of the trusted OS.
In an embodiment of the invention, said inspection and analysis comprises scanning the memory for patterns or signatures relating to malicious code.
In an embodiment of the invention, said trusted domain OS comprises a main domain reboot service that causes reboot of the main OS from within the trusted domain, with no intervention whatsoever of the main OS.
In an embodiment of the invention, said trusted domain OS comprises a main-domain software update service for performing an update procedure of the main OS, wherein said update procedure is performed by said service periodically halting the processor which runs the main OS, replacing sections of contents of the memory which contains the main OS, and rerunning the main OS.
In an embodiment of the invention, the hypervisor comprises a timer for independently triggering processes within one or more of the services of the trusted domain OS.
Brief Description of the Drawings
In the drawings :
Fig. 1 shows in a general block diagram form a structure of a prior art TEE system having a main domain and a trusted domain;
Fig. 2 shows in a general block diagram form still another structure of a conventional prior art TEE system having a main domain and a trusted domain; and
Fig. 3 shows in a general block diagram form a novel structure for performing secured operations within the trusted domain 130 of the processor, according to the present invention; and
Fig. 4 shows in a general block diagram form still another example of a structure of a TEE system according to an embodiment of the present invention.
Detailed Description of Preferred Embodiments
Fig. 1 illustrates in a block diagram form the general structure of a typical TEE, according to the prior art. As noted, in the TEE structure (such as ARM TrustZone, or Intel TEE) two separate domains of operation are defined^ (l) a normal (main) domain 20 of the Main OS 21; and (2) a trusted domain 30 of the Trusted-Domain OS 31. The Trusted Domain OS 31, which comprises one or more services Si, S2, ...Sn, is typically different from the Main OS in structure and language, and is more targets oriented. The interaction between said two operating systems, 20 and 30, respectively, is typically performed via an interface 40 which is susceptible to malicious code, as it resides within the memory domain of the less privileged main OS.
While in offline, a user can define the trusted domain OS 31 only via the main OS 21. Likewise, during runtime, either a user program or a
network packet may interact with the trusted domain OS 31 only via the Main OS 21 (and interface 40).
Fig. 2 shows in a general block diagram form still another structure of a conventional prior art TEE system having a main domain 20 and a trusted domain 30. As noted, the main OS resides in the main domain 20, while the trusted domain OS resides in the trusted domain 30. As is conventional, each of said operating systems is divided into a user space section (25 and 35 respectively) residing in a less privileged level PL0, and a kernel space section (26 and 36 respectively) residing in a more privileged level PL1. The trusted domain 30 provides highly secured services to the main domain 20, for example, encryption/decryption services, keys storing, integrity checks, etc. The main domain typically communicates with the secured (trusted) domain via a dedicated API (not shown). The main domain 20 conveys to the trusted domain 30 requests for services. The requests 28 and 29 are issued either from the user space 25, or from the kernel space 26 of the main domain 20. The processor transfers the control to the trusted domain 30, which in turn processes the request and returns the results and control to the main domain 20.
A request for a trusted domain service may result, for example, from a network packet 50, or a user space program (not shown) which causes issuance of a system call to the kernel space 26.
The prior art architecture of Figs. 1 and 2, which requires submission of requests to the secured domain via the main domain has several drawbacks in term of security. First, the operating system 20 at the main domain can be compromised, for example, by the injection of malicious code. When the main operating system 21 (Fig. l) which resides in the main domain 20 is compromised, an adversary may exploite this compromise to manipulate all the requests that pass through the main
OS. For example, when a valid request is conveyed to the main domain 20 (for example, from a network packet) to initiate a call to the secured domain 30, a malicious code at the main OS may intercept the request, abort the call to the trusted domain 30, and return its own faked response. In another example, a malicious code at the main domain 20 may perform a denial of service (DoS) attack on the trusted domain to entirely prevent receipt of request calls at the trusted domain.
The present invention provides a structure that eliminates a possible exploitation of the trusted domain 30 by maliciously affecting the main OS at the main domain 20.
Fig. 3 shows in a general block diagram form a novel structure for performing secured operations within the trusted domain 130 of the processor, according to the present invention. Components having indices similar to those of Fig. 2 perform substantially a same function. According to the present invention, the system further comprises a highly privileged low level "hypervisor" 180 (at a privileged level PL3), which is used to route packets that arrive from the network 150 either to the main OS 121 or to the trusted domain OS 131. More specifically, those packets arriving hypervisor 180 that are targeted to the trusted domain OS 131 are conveyed directly to the trusted domain OS 131, while avoiding any passage through or interaction with both the main OS 121 and the high level API (not shown) at the main domain. In one embodiment of the invention, said highly secured direct channel to the trusted domain OS is defined as the only possible channel to the trusted domain 130 (while eliminating entirely the channels 141 and 142 from the main OS to the trusted domain OS). Moreover, processing results from the trusted operating system which operates at the trusted domain 131 are conveyed back to the issuing entity in the network 150 via the hypervisor 180, while entirely avoiding any interaction with the main operating system.
In another embodiment of the invention, although less preferable, said highly secured channel is provided in addition to the conventional channels, 141 and 142 respectively, from the user space 125 and from the kernel space 126 of the main OS 121 to the kernel space 139 of the trusted domain OS 131. More specifically, in said latter embodiment the user may still use said two conventional channels 141 and 142 to the trusted domain, while being aware that said conventional channels may be compromised.
In an embodiment of the invention, packets from network 150 that are targeted to the trusted domain OS 131 are differentiated from packets that are targeted to the main OS 121 by their MAC address. The hypervisor 180, in turn, inspects the header of each arriving packet, and accordingly directs the packet either to the main OS 121, or directly to the trusted domain OS 131 based on the MAC address. This manner of differentiation between the packets is very simple and efficient, therefore the routing of the packets respectively can be performed by hypervisor 150 in a very fast manner.
In an embodiment of the invention, the trusted operating system 131 may comprise a variety of services, such as: maintenance services, introspection services, debugging and memory-acquisition services, integrity check services, and security and cyber-defense services. As described above, all said services of the trusted domain OS 131 operate in a way which is entirely independent from the main OS 121, as the interaction between an external entity and the trusted domain OS 131 is performed directly, by means of packets passing via the hypervisor, and avoiding any interaction whatsoever with the main OS 121 (i.e., without changing or modifying the main OS memory or execution-flow). Therefore,
this structure and manner of operation is much safer compared to the prior art.
Examples :
As noted, the trusted OS runs alongside the main OS in the TEE, and performs operations on the main OS in a non-invasive way. For example, the trusted operating system services may perform the following non¬ invasive operations on the main OS:
General services:
1. The services of the trusted domain OS may be triggered if one the following events occurs :
o Timer triggered, periodic (for example, every 1000ms);
o Timer triggered - setup timer;
o Hardware event triggered (for example, interrupts); o Network command triggered;
2. In another example, the trusted domain OS 131 may perform an integrity analysis of the main OS 121, by periodically halting the main OS 121, performing memory acquisition, and scanning and inspecting the extracted memory section for a possible existence of malicious code. As said, this is done while avoiding any interaction or dependence on the main OS 121.
Maintenance Services:
3. The services of the trusted domain OS 131 may perform "heartbeat" checks on the main OS 121, for example, checking the processor and its core activities to determine whether the main OS 121 is fully functioning;
4. The services of the trusted domain OS 131 a system -load monitoring of the main OS, and sampling of the processor loads and processor counters;
5. The services of the trusted domain OS 131 may check the memory usage of the main OS 121, for example, by checking the free and allocated memory tables;
6. The services of the trusted domain OS 131 may check for exceptions and interrupts that may occur in the main OS 121, for example, monitoring of hardware interrupts and exceptions.
7. The services of the trusted domain OS 131 may halt the main OS, for example, by halting the processors or the cores by an appropriate request;
8. The services of the trusted domain OS 131 may initiate a shutdown process of the main OS 121, for example, by triggering a shutdown interrupt of the main OS 121.
Introspection Services:
9. The services of the trusted domain OS 131 may extract a process/thread list of the main OS 121, namely, it may perform introspective analysis of the main memory and extract the process and thread list;
10. The services of the trusted domain OS 131 may check for network activity reports, namely, it may report the current open TCP/IP ports as reflected in the main OS handles;
11. The services of the trusted domain OS 131 may reconstruct and parse various kernel objects of the main OS 121;
12. The services of the trusted domain OS 131 may open file handle lists to reconstructing and parse various handle list tables;
13. The services of the trusted domain OS 131 may extract memory and object allocation tables or other kernel elements for reconstruction of them.
Debugging and memory acquisition services :
14. The services of the trusted domain OS 131 may extract system and kernel memory by range!
15. The services of the trusted domain OS 131 may perform system debugging and trace at various levels;
16. The services of the trusted domain OS 131 may perform kernel panic monitoring;
17. The services of the trusted domain OS 131 may extract system logs;
18. The services of the trusted domain OS 131 may issue critical alerts;
19. The services of the trusted domain OS 131 may extract memory content in a case of failure for offline analysis;
20. The services of the trusted domain OS 131 may analyze and detect memory corruptions;
;ritycheck services :
21. The services of the trusted domain OS 131 may validate in- memory kernel integrity of the main OS 121, namely, a validation of the kernel integrity on load and other invariant parts after the load;
22. The services of the trusted domain OS 131 may validate perform in-memory driver integrity check of the main OS 121, namely validation of drivers integrity, and on-load and after-load signatures;
23. The services of the trusted domain OS 131 may validate in- memory application/process integrity;
24. The services of the trusted domain OS 131 may file system integrity check in a persistent storage.
Security and cyber- defense integrity;
25. The services of the trusted domain OS 131 may perform implement a trusted firewall outside of the main OS 121;
26. The services of the trusted domain OS 131 may also perform trusted packet and I/O encryption and decryption for entities external of the main OS;
27. The services of the trusted domain OS 131 may also perform a trusted signing mechanism, namely, it may sign packets outside of the main OS 121;
28. The services of the trusted domain OS 131 may also perform a trusted memory scanning, namely, it may scan the memory for malicious signature, vulnerabilities and corruptions.
Fig. 4 shows still another example of a structure of a TEE system according to an embodiment of the present invention. Monitor 181 within hypervisor 180 may receive an FIQ interrupt from either an entity in the network 150 (in a form of a packet - as described above) or from an internal timer 187. If the interrupt comes from the network, the packet is conveyed to a routing unit 182. The routing unit inspects the MAC address of the packet. If the MAC address relates to the main OS 121, the packet is forwarded to the main OS. Otherwise, when the MAC address relates to the TEE, the packet is forwarded to the TEE service dispatcher 132 within the secured domain 131. The TEE service dispatcher may then activate one or more of the exemplary services 133, 134, 135, 136, or 137, respectively.
The Check Alive service 133 checks various elements of the main OS to ensure that it is not halted (i.e., that the OS is indeed running).
The Introspection Process List service 134 extracts the list of currently running services from the main OS 121, for further inspection and analysis within the trusted OS 121 domain.
The Introspection Process Memory Dump service 135 halts the main OS 121, and extracts from the main OS 121 a section of its memory, for further inspection and analysis within the trusted OS 121 domain.
The Main Domain Reboot service 136 performs reboot of the main OS 121 upon a specific event or trigger.
Finally, the Main Domain Software Update service 137 performs an updating procedure of the main OS 121. This procedure is performed by periodical halting the processor which runs the main OS, replacing sections of the memory, and rerunning the main OS.
It should be noted that all said services are unique, as they may be activated from an external entity (via the hypervisor), they are operated from within trusted domain OS, and the results may be conveyed back directly to the activating entity via the hypervisor, without any intervention whatsoever of the main OS.
Alternatively, if the FIQ relates to a timer 187 issued interrupt, the interrupt is conveyed from the monitor to the TEE service dispatcher, which in turn activates one of the services, 132-137, respectively.
As a result of this structure, the secured services 133-137 may be triggered by one the following events :
1. Periodic timer 187 trigger - A secured service begins execution every given period of time. The wakeup is managed via timer 187 interrupts. Example for a service which is activated is the check alive service 133 which checks every 10 seconds that the operating system is alive (i.e., that it is not halted);
2. Timer triggered, setup timer - A secured service begins execution of some procedure a predetermined time after the occurrence of a predefined event;
3. Hardware event trigger - The secured service begins execution upon a hardware event as determined by the secured OS 131. This may occur, for example, when an I/O operation begins or is completed, or upon arrival or sending of a network packet;
4. Network command triggered - The secured service begins execution when a command from the network 150 is received within a packet from the routing unit 182.
The above types of events are managed in the internal queues of the trusted OS 131, and are mapped to the appropriate services.
While some embodiments of the invention have been described by way of illustration, it will be apparent that the invention can be carried into practice with many modifications, variations and adaptations, and with the use of numerous equivalents or alternative solutions that are within the scope of persons skilled in the art, without departing from the spirit of the invention or exceeding the scope of the claims.
Claims
A TEE (Trusted Environment Execution) structure which comprises : a. a main domain defining a domain of operation for a main OS;
b. a privileged trusted domain defining a domain of operation for a trusted domain OS; and
c. a low level hypervisor which is separate from both of said main OS and said trusted domain OS, said hypervisor is used for:
(i) receiving packets from a network;
(ii) examining an address included in each of said received packets; and
(hi) based on the determined address in each of said packets, targeting respectively the packet to either said main OS or to said trusted domain OS, while in the latter case any interaction between the received packet and said main OS is eliminated.
A TEE structure according to claim 1, wherein said received packets that are targeted to the trusted domain OS convey information to one or more services running by said trusted domain OS at said trusted domain, and wherein results obtained by said running services are conveyed in a packet form back to the hypervisor, which respectively routes the packet to a target entity at the network, without any interaction with said main OS.
A TEE structure according to claim 1, wherein said examination by the hypervisor of the packet address is performed on a MAC address as defined in a header within said packet.
4. A TEE structure according to claim 2, wherein said one or more services of the trusted domain OS analyze data relating to the main OS in a non-invasive manner, while said services of the trusted domain OS
are operated by an external entity at the network by means of said packets, respectively, while entirely avoiding any interaction between the packets that carry operation instructions or service results respectively, and the main OS.
5. A TEE structure according to claim 2, wherein the trusted domain OS comprises a check-alive service for periodically or upon receipt of an external trigger, checks that the main OS is alive, namely that it is not in a halt state.
6. A TEE structure according to claim 2, wherein the trusted domain OS comprises an introspection process list service which extracts a list of currently running services from the main OS, for further inspection and analysis within the domain of the trusted OS.
7. A TEE structure according to claim 2, wherein the trusted domain OS comprises an introspection process memory dump service which halts the main OS, and extracts from the run-time memory that stores the main OS, a section of its memory for further inspection and analysis within the domain of the trusted OS.
8. A TEE structure according to claim 7, wherein said inspection and analysis comprises scanning the memory for patterns or signatures relating to malicious code.
9. A TEE structure according to claim 2, wherein said trusted domain OS comprises a main domain reboot service that causes reboot of the main OS from within the trusted domain, with no intervention whatsoever of the main OS.
10. A TEE structure according to claim 2, wherein said trusted domain OS comprises a main-domain software update service for performing an update procedure of the main OS, wherein said update procedure is
performed by said service periodically halting the processor which runs the main OS, replacing sections of contents of the memory which contains the main OS, and rerunning the main OS.
11. A TEE structure according to claim 1, wherein the hypervisor comprises a timer for independently triggering processes within one or more of the services of the trusted domain OS.
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/755,073 US10742603B2 (en) | 2015-08-26 | 2016-08-17 | System and method for monitoring and protecting an untrusted operating system by means of a trusted operating system |
EP16838671.2A EP3341879B1 (en) | 2015-08-26 | 2016-08-17 | System and method for monitoring and protecting an untrusted operating system by means of a trusted operating system |
IL257620A IL257620A (en) | 2015-08-26 | 2018-02-19 | System and method for monitoring and protecting an untrusted operating system by means of a trusted operating system |
Applications Claiming Priority (8)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201562209910P | 2015-08-26 | 2015-08-26 | |
US201562209920P | 2015-08-26 | 2015-08-26 | |
US62/209,920 | 2015-08-26 | ||
US62/209,910 | 2015-08-26 | ||
US201562241799P | 2015-10-15 | 2015-10-15 | |
US62/241,799 | 2015-10-15 | ||
US201662300840P | 2016-02-28 | 2016-02-28 | |
US62/300,840 | 2016-02-28 |
Publications (2)
Publication Number | Publication Date |
---|---|
WO2017033180A1 true WO2017033180A1 (en) | 2017-03-02 |
WO2017033180A8 WO2017033180A8 (en) | 2017-12-28 |
Family
ID=58100002
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/IL2016/050899 WO2017033180A1 (en) | 2015-08-26 | 2016-08-17 | System and method for monitoring and protecting an untrusted operating system by means of a trusted operating system |
Country Status (4)
Country | Link |
---|---|
US (1) | US10742603B2 (en) |
EP (1) | EP3341879B1 (en) |
IL (1) | IL257620A (en) |
WO (1) | WO2017033180A1 (en) |
Families Citing this family (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11792307B2 (en) | 2018-03-28 | 2023-10-17 | Apple Inc. | Methods and apparatus for single entity buffer pool management |
US11347869B2 (en) | 2019-03-08 | 2022-05-31 | International Business Machines Corporation | Secure interface control high-level page management |
US11206128B2 (en) | 2019-03-08 | 2021-12-21 | International Business Machines Corporation | Secure paging with page change detection |
US11403409B2 (en) | 2019-03-08 | 2022-08-02 | International Business Machines Corporation | Program interruptions for page importing/exporting |
US11558348B2 (en) * | 2019-09-26 | 2023-01-17 | Apple Inc. | Methods and apparatus for emerging use case support in user space networking |
US11829303B2 (en) | 2019-09-26 | 2023-11-28 | Apple Inc. | Methods and apparatus for device driver operation in non-kernel space |
US11775359B2 (en) | 2020-09-11 | 2023-10-03 | Apple Inc. | Methods and apparatuses for cross-layer processing |
US11954540B2 (en) | 2020-09-14 | 2024-04-09 | Apple Inc. | Methods and apparatus for thread-level execution in non-kernel space |
US11799986B2 (en) | 2020-09-22 | 2023-10-24 | Apple Inc. | Methods and apparatus for thread level execution in non-kernel space |
KR102479465B1 (en) * | 2021-01-14 | 2022-12-22 | 충남대학교 산학협력단 | Device for enhancing the security of mobile trust execution environment |
US11876719B2 (en) | 2021-07-26 | 2024-01-16 | Apple Inc. | Systems and methods for managing transmission control protocol (TCP) acknowledgements |
US11882051B2 (en) | 2021-07-26 | 2024-01-23 | Apple Inc. | Systems and methods for managing transmission control protocol (TCP) acknowledgements |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060107329A1 (en) | 2004-11-15 | 2006-05-18 | Microsoft Corporation | Special PC mode entered upon detection of undesired state |
US20070208873A1 (en) | 2006-03-02 | 2007-09-06 | Lu Jarrett J | Mechanism for enabling a network address to be shared by multiple labeled containers |
US20100031325A1 (en) * | 2006-12-22 | 2010-02-04 | Virtuallogix Sa | System for enabling multiple execution environments to share a device |
EP2680180A1 (en) * | 2012-06-29 | 2014-01-01 | Orange | System and method for securely allocating a virtualised space |
US20140059680A1 (en) | 2005-04-01 | 2014-02-27 | Microsoft Corporation | Local secure service partitions for operating system security |
US20160335433A1 (en) | 2013-10-28 | 2016-11-17 | Oberthur Technologies | Intrusion detection system in a device comprising a first operating system and a second operating system |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7460556B2 (en) * | 2005-02-17 | 2008-12-02 | International Business Machines Corporation | Autonomic adjustment of connection keep-alives |
US8774213B2 (en) * | 2011-03-30 | 2014-07-08 | Amazon Technologies, Inc. | Frameworks and interfaces for offload device-based packet processing |
US8656482B1 (en) * | 2012-08-20 | 2014-02-18 | Bitdefender IPR Management Ltd. | Secure communication using a trusted virtual machine |
-
2016
- 2016-08-17 EP EP16838671.2A patent/EP3341879B1/en active Active
- 2016-08-17 WO PCT/IL2016/050899 patent/WO2017033180A1/en active Application Filing
- 2016-08-17 US US15/755,073 patent/US10742603B2/en active Active
-
2018
- 2018-02-19 IL IL257620A patent/IL257620A/en unknown
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060107329A1 (en) | 2004-11-15 | 2006-05-18 | Microsoft Corporation | Special PC mode entered upon detection of undesired state |
US20140059680A1 (en) | 2005-04-01 | 2014-02-27 | Microsoft Corporation | Local secure service partitions for operating system security |
US20070208873A1 (en) | 2006-03-02 | 2007-09-06 | Lu Jarrett J | Mechanism for enabling a network address to be shared by multiple labeled containers |
US20100031325A1 (en) * | 2006-12-22 | 2010-02-04 | Virtuallogix Sa | System for enabling multiple execution environments to share a device |
EP2680180A1 (en) * | 2012-06-29 | 2014-01-01 | Orange | System and method for securely allocating a virtualised space |
US20160335433A1 (en) | 2013-10-28 | 2016-11-17 | Oberthur Technologies | Intrusion detection system in a device comprising a first operating system and a second operating system |
Non-Patent Citations (1)
Title |
---|
See also references of EP3341879A4 |
Also Published As
Publication number | Publication date |
---|---|
US10742603B2 (en) | 2020-08-11 |
US20180248847A1 (en) | 2018-08-30 |
IL257620A (en) | 2018-04-30 |
EP3341879A1 (en) | 2018-07-04 |
EP3341879B1 (en) | 2022-10-26 |
WO2017033180A8 (en) | 2017-12-28 |
EP3341879A4 (en) | 2019-03-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10742603B2 (en) | System and method for monitoring and protecting an untrusted operating system by means of a trusted operating system | |
US10740456B1 (en) | Threat-aware architecture | |
US10528726B1 (en) | Microvisor-based malware detection appliance architecture | |
US9912681B1 (en) | Injection of content processing delay in an endpoint | |
US10630643B2 (en) | Dual memory introspection for securing multiple network endpoints | |
US9680862B2 (en) | Trusted threat-aware microvisor | |
US10474813B1 (en) | Code injection technique for remediation at an endpoint of a network | |
US8250519B2 (en) | Forcing registered code into an execution context of guest software | |
Duflot et al. | What if you can’t trust your network card? | |
WO2016004080A1 (en) | Verification of trusted threat-aware microvisor | |
JP2019066995A (en) | System capable of selectively switching between secure mode and non-secure mode | |
Tian et al. | An Online Approach for Kernel-level Keylogger Detection and Defense. | |
Tsifountidis | Virtualization security: Virtual machine monitoring and introspection | |
Schlüter et al. | Heckler: Breaking Confidential VMs with Malicious Interrupts | |
Ghosh et al. | On the feasibility of deploying software attestation in cloud environments | |
Hollingworth et al. | Enhancing operating system resistance to information warfare | |
Bushouse et al. | Goalkeeper: Comprehensive process enforcement from the hypervisor | |
Kuhn et al. | A survey of forensic analysis in virtualized environments | |
Takemura et al. | TEE-PA: TEE Is a Cornerstone for Remote Provenance Auditing on Edge Devices With Semi-TCB | |
Wan | Hardware-Assisted Security Mechanisms on Arm-Based Multi-Core Processors | |
Chang et al. | LWRM: A lightweight response mechanism for TCG TOCTOU attack | |
ZHAO | Secure enforcement of isolation policy on multicore platforms with virtualization techniques | |
de Souza et al. | SMM Revolutions | |
Sprabery | An architecture for trustworthy services built on event based probing of untrusted guests | |
Cheng | Virtualization-based System Hardening against Untrusted Kernels |
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: 16838671 Country of ref document: EP Kind code of ref document: A1 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 257620 Country of ref document: IL |
|
WWE | Wipo information: entry into national phase |
Ref document number: 15755073 Country of ref document: US |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2016838671 Country of ref document: EP |