WO2021211091A1 - Moteur de traitement sécurisé pour sécuriser un système informatique - Google Patents

Moteur de traitement sécurisé pour sécuriser un système informatique Download PDF

Info

Publication number
WO2021211091A1
WO2021211091A1 PCT/US2020/028010 US2020028010W WO2021211091A1 WO 2021211091 A1 WO2021211091 A1 WO 2021211091A1 US 2020028010 W US2020028010 W US 2020028010W WO 2021211091 A1 WO2021211091 A1 WO 2021211091A1
Authority
WO
WIPO (PCT)
Prior art keywords
processor
processing engine
security
computing system
main processor
Prior art date
Application number
PCT/US2020/028010
Other languages
English (en)
Inventor
Yigal Edery
Jorge Myszne
Efi SASSON
Ido Naishtein
Original Assignee
KameleonSec Ltd.
Kameleonsec Inc.
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 KameleonSec Ltd., Kameleonsec Inc. filed Critical KameleonSec Ltd.
Priority to PCT/US2020/028010 priority Critical patent/WO2021211091A1/fr
Publication of WO2021211091A1 publication Critical patent/WO2021211091A1/fr

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/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
    • G06F21/575—Secure boot
    • 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
    • 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/82—Protecting input, output or interconnection devices
    • G06F21/85—Protecting input, output or interconnection devices interconnection devices, e.g. bus-connected or in-line devices

Definitions

  • the present disclosure relates generally to system security, and more particularly to a secure processing engine for use within a computing system.
  • FIG.1 A first generation of security applications, such as those executed in the Windows® 3.1 operating system 110, were configured to run any security application, such as an anti-virus program, within a user space 112 alongside other general applications, such as a word processor or email client.
  • security application such as an anti-virus program
  • FIG. 1 A first generation of security applications, such as those executed in the Windows® 3.1 operating system 110, were configured to run any security application, such as an anti-virus program, within a user space 112 alongside other general applications, such as a word processor or email client.
  • the second generation of security applications such as those run on the Windows® NT or 9X operating system 120, were configured to be run within the kernel 122 of the system itself. That is, the portion of the operating system code that is run in a protected memory region only accessible to “ring 0” applications and not run within the memory space of regular applications. Such an approach creates a distance between the security functions of the operating system and the regular user space. While this is an improvement over the first generation, the kernel itself is not wholly immune to attacks and remains vulnerable.
  • the third generation of security applications such as those run on the Windows® 10 operating system 130, further distances the security applications by running them on a separate secure kernel 132, separated from the normal kernel 133 caused by general programs of the operating system.
  • This configuration is possible due to the implementation of a hypervisor 134, which allows multiple kernels to run on a single hardware system.
  • a hypervisor 134 allows multiple kernels to run on a single hardware system.
  • the hardware charged with security tasks is the same hardware that runs the system it is designed to protect. Further, hypervisor and firmware vulnerabilities could be exploited to bypass this configuration.
  • Such a configuration remains open to various attacks that are based on detecting internal processes and information about how the system itself functions.
  • two recent vulnerabilities exploited by attackers the Meltdown and Spectre attacks, are side-channel attacks configured to decipher valuable information based on tangential data related to a system’s memory usage and kernel files, respectively. These attacks rely on access to the system’s main hardware in order to function properly, even without kernel access.
  • a viable solution that prevents access to such information and ensures an elevated level of protection is needed.
  • the separation approaches discussed with reference to Fig. 1 are performed in software.
  • There exist some attempts to provide separation in hardware such as separation approach performed in hardware as provided by Intel® and AMD, and known as an Intel® Management Engine (ME) and AMD Platform Security Processor (PSP).
  • ME Intel® Management Engine
  • PSP AMD Platform Security Processor
  • Such solutions are autonomous subsystems that have been incorporated in the processor chipset. Therefore, for example, the Management Engine is not decoupled from the main processor.
  • Such solutions are limited in the security features that they can execute. For example, such solutions are limited to validating boot processes, and initializing various security related mechanisms. Therefore, the solutions are limited to monitoring only the boot sequence or some limited set of signals.
  • a major disadvantage of such solutions is the inability to proactively protect the entire system, and to fully monitor the memory the operating system at run time.
  • Certain embodiments disclosed herein include a secure processing engine configured to protect a computing system.
  • the system includes a first processor configured to provide real-time protection to at least processes executed over the main processor of the protected computing system; and a direct memory access (DMA) configured to provide an access to a main memory of the main processor, wherein the first processor is coupled to the DMA and further configured to monitor the at least processes by accessing the main memory via the DMA; wherein the first processor operates in an execution environment in complete isolation from an execution environment of the main processor.
  • DMA direct memory access
  • Certain embodiments disclosed herein also include a method for securing a computing system.
  • the method comprises providing, by a first processor of the security processing engine (SPE), real-time protection to at least processes executed over the main processor of the protected computing system; wherein the real-time protection is executed in an execution environment in complete isolation from an execution environment of the main processor.
  • SPE security processing engine
  • FIG. 1 is a block diagram illustrating the evolution of conventional security separation processes.
  • FIG. 2A is a block diagram of a secure processing engine (SPE) designed according to an embodiment.
  • SPE secure processing engine
  • FIG. 2B is a block diagram of a secure processing engine (SPE) serving as a proxy according to another embodiment.
  • SPE secure processing engine
  • Figure 3 is a functional diagram illustrating the operation of the SPE in tandem with a protected system according to an embodiment.
  • Figure 4 is a diagram illustrating the operation of the SPE in preventing a cyber-attack on a protected system.
  • Figure 5 shows an example flowchart illustrating a method for providing an isolated execution environment according to an embodiment.
  • the various disclosed embodiments provide a secure processing engine (SPE) which operates separately from the main processor of a computing system.
  • the SPE is configured to secure the operation of the main processor and operating system(s) executed therein.
  • the main processor and operating system(s) secured by the SPE will be referred to hereinafter after as the protected system.
  • the SPE is configured to execute security applications separately from the protected entity, thereby preventing malicious code from being executed by the protected entity.
  • the security applications may be partially executed on the SPE and partially on the protected system, with the SPE ensuring the proper operations of applications being executed on the protected system.
  • Fig. 2A is an example block diagram of the SPE 200 designed according to an embodiment.
  • the SPE 200 includes a first memory 215 coupled to an integrity check processor 210, and a second memory 225 coupled a run-time check processor 220.
  • the run-time check processor 220 is also referred to as a “first processor” and the integrity check processor 210 is also referred to a “second processor.”
  • the SPE 200 further includes a direct memory access (DMA) 230, over a high-speed interface (such as a PCIe bus) 240.
  • the SPE 200 includes a peripheral interface 250 to peripheral devices, such as a network interface card (NIC).
  • NIC network interface card
  • the PCIe bus 240 provides the connection to a main processor 270 via the PCIe bus 240.
  • the DMA 230 provides direct access to a memory 280 of the main processor 270.
  • the memory 280 may be, for example, a DRAM.
  • the main processor 270 may be a single-core or multiple-core processor, such as is provided by Intel®, ARM®, and AMD®.
  • the SPE 200 is further connected to a non-volatile memory (e.g., Flash memory) 290 via Serial Peripheral Interface. That is, the SPE 200 interposes the connection to Flash memory 290.
  • the non-volatile memory 290 includes at least the BIOS of the protected system.
  • the main processor 270 may include graphics processing units (GPUs), tensor processing units (TPUs), general-purpose microprocessors, microcontrollers, and digital signal processors (DSPs).
  • the operating systems executed by the main processor 270 may include, but are not limited to, Windows®, Linux®, iOS®, and the like.
  • the integrity check processor 210 is configured to provide security functions of boot integrity control.
  • the SPE 200 is configured to interpose the non-volatile memory 290.
  • the SPE 200 is further configured to provide sequenced boot flow, to validate firmware images before the main processor 270 to executes the firmware, to validate BIOS images before allowing the main processor 270 to execute the images, and to validate attestation of all supported peripheral devices.
  • the processor 210 can also provide boot integrity control on the run-time check processor 220.
  • the processor 210 is interposed between the Flash memory and the main processor, and is physically part of the SPE 200.
  • the run-time check processor 220 provides run-time protection to the operating system or any other code running on the main processor 270.
  • the run time check processor 220 may access the main memory 280 via the DMA 230 to monitor and secure processes executed by the operation system. This is performed in complete synchronization with the operating system of the protected system. Such processes include execution of system drivers, instantiation of VMs, execution of VMs, execution of applications by the operating system, and more.
  • access to the main memory 280 is granted only through the SPE 200.
  • the SPE 200 serves as a proxy between the main processor 270 and the memory 280. This would allow for protecting systems with encrypted memory as well. It should be noted that in such embodiments, access to the memory is not through the DMA 230, and the DMA 230 is not included in the SPE 200.
  • An example diagram showing the SPE 200 operable as a proxy is provided in Fig. 2B.
  • the run-time check processor 220 is configured to perform a plurality of security functions, such as anti-virus, malware detection, intrusion detection, integrity checks, code polymorphism, control flow integrity enforcement, alerting into security information and event management (SIEM) systems, and the like.
  • security functions such as anti-virus, malware detection, intrusion detection, integrity checks, code polymorphism, control flow integrity enforcement, alerting into security information and event management (SIEM) systems, and the like.
  • one of the security functions includes polymorphism of the code being executed. An example method for performing code polymorphism is described in US Patent Application 16/601 ,938, filed October 15, 2019 assigned to the common assignee, and it is hereby incorporated by reference for all which is contained.
  • the computing power of the integrity check processor 210 can be different than that of the run-time check processor 220.
  • the integrity check processor 210 may be, for example, a single-core processor, while the second processor 220 may be a multi-core processor. It should be noted that any of the integrity check processor 210 and the run-time check processor 220 may be realized as one or more hardware logic components and circuits.
  • illustrative types of hardware logic components include field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip systems (SOCs), graphics processing units (GPUs), tensor processing units (TPUs), central processing units (CPUs), general-purpose microprocessors, microcontrollers, and the like, or any other hardware logic components that can perform calculations or other manipulations of information.
  • the processor 220 can also be realized in polymorphic hardware, as discussed in U.S. Patent Application 16/670,110, filed October 31 , 2019 assigned to the common assignee, and it is hereby incorporated by reference for all which is contained.
  • the first and second memory 215 and 225 may be program memory containing instructions to be executed by the first and second processors.
  • the first and second memory 215 and 225 may include volatile (e.g., RAM, etc.), non-volatile (e.g., ROM, flash memory, etc.), or a combination thereof.
  • computer readable instructions to implement one or more embodiments disclosed herein may be stored in the first and second memory 215 and 225.
  • the first and second memory 215 and 225 are configured to store software and configuration data.
  • Software shall be construed broadly to mean any type of instructions, whether referred to as software, firmware, middleware, microcode, hardware description language, or the like. Instructions may include code (e.g., in source code format, binary code format, executable code format, or any other suitable format of code). The instructions, when executed by the first and second processors, cause the respective processor (210 or 220) to perform the various processes described herein.
  • the main processor is configured to execute the standard applications without the main operating system sacrificing resources, thus increasing efficiency and reducing cost.
  • the SPE 200 may be further configured with a unique identity and unclonable per chip. Thereby, the SPE 200 can be used as a trustworthy and unclonable identity to establish evidence of ownership of a system.
  • each SPE 200 has a unique identify embedded therein, for example, which can be generated in the factory or provisioned after the fact. This unique ID can be used to authenticate the protected system or grant a user or application access.
  • Fig. 3 is an example functional diagram illustrating the operation of the SPE 200 in tandem with a protected system 320 according to an embodiment.
  • the SPE 200 is directed to two security features, a boot integrity control 316 and a run time protection 310.
  • the boot integrity control 316 is primarily directed at securing the protected system 320 during boot of the system and the boot of the run time protection 320.
  • the security functions provided under the control 316 includes at least firmware integrity of the firmware 328 and attestation of the peripherals in the hardware platform 329, as well as firmware that is part of run time protection 320.
  • the boot integrity control 316 can optionally be further configured to operate as a trusted platform module (TPM), thereby enabling the securing of hardware through integrated cryptographic keys.
  • TPM trusted platform module
  • the boot integrity control 316 is performed by the integrity check processor 210 (see Fig. 2A) of the SPE.
  • the run time protection 310 provides execution of security functions over processes and flows executed in the protected system 320.
  • the run time protection 310 is performed by the second processor 220 (see Fig. 2A) of the SPE. As illustrated in Fig. 3, the run time protection 310 secures any processes by middleware 327 executed over the protected system 320.
  • the middleware 327 collectively refers to the operating system, kernel, hypervisor, and drivers executed over the hardware platform 329.
  • the run time protection 310 further protects applications 324 (e.g., a word processor, an email application, etc.), and one or more virtual machines (VMs) 326.
  • applications 324 e.g., a word processor, an email application, etc.
  • VMs virtual machines
  • the security functions provided by the run time protection 310 include, for example, functions such as anti-virus, malware detection, intrusion detection, code polymorphism, integrity checks, alerting, and the like.
  • the run time protection 310 can be further configured to offload certain key operating system components, such as sensitive kernel code, into the secure environment.
  • the run time protection 310 monitors the memory of the protected system 320 and executes security functions as needed.
  • the run time protection 310 may be pre-configured such that each process executed in the middleware 327 may be secured. This configuration may be a default for all processes or only sensitive processes. The same is true of applications 324 and VMs 326.
  • a run time protection 310 may be configured to secure a VM 326 accessing sensitive resources.
  • the SPE 300 provides a complete isolated trusted execution environment.
  • the isolated nature of the SPE 300 enables trusted execution of the security application, which secures the processes, applications 324, and VMs 326 on the protected system 320. Further, the isolated execution environment guarantees the integrity of the code the environment runs, as the SPE 300 can be configured to only accept properly signed code for execution.
  • the SPE 300 is separate from the main processor in the hardware platform 329 of the protected system 320, it is not subject to side channel attacks that rely on information provided by malicious code in separate processes 324 running on the main processor in the hardware platform 329. Further, the SPE 300 can be configured to control the security applications performed by the run time protection 310 without allowing input or modifications from a user, thus ensuring that a user cannot disable the security applications, either intentionally or otherwise.
  • a single SPE 300 is configured to allow for easier and more practical enforcement of a chain of trust from the initial boot to the applicative security. That is, the boot integrity control 316 ensures the SPE 300 is only configured to load verified security code without any unsigned/unverified code that could break the chain of trust.
  • the SPE 300 is configured to monitor the protected system 320 without need for instructions from the general processor included in the hardware platform 329.
  • a communication channel may be established between the SPE 300 and the protected system 320 to enable receiving instructions over such a channel.
  • the communication channel is firewalled and authenticated to prevent undesirable communication from passing through.
  • FIGs. 4A and 4B are example diagrams illustrating the operation of the SPE in preventing a cyber-attack on a protected system.
  • Fig. 4A shows a protected system 410 with no SPE.
  • Fig. 4B shows a protected system 420 with an SPE 425.
  • Fig 4A for the protected system 410, with no separate SPE 425, security applications 419 run within the same kernel space as kernel code 418 of the operating system 412, and if a rogue application (e.g., malware) 414 is successfully implemented, the rogue application 414 will be executed in the user space. While this setup may be sufficient to protect from direct attacks against a victim application 416, the security application 419 itself is susceptible to any vulnerabilities that may exist in shared kernel code 418. This can provide the rogue application 414 access to the kernel code 418 to disable or modify the security application 419.
  • a rogue application e.g., malware
  • Fig 4B for the protected system 420 with the separate SPE 425, the security application 426 is fully isolated from the operating system 421. Thus, even if a rogue application 422 successfully takes control of the kernel code 424, the security application 426 remains protected.
  • FIG. 5 shows an example flowchart illustrating a method 500 for providing an isolated execution environment according to an embodiment. The method is performed by the SPE discussed herein.
  • a boot integrity control process is performed by the integrity-check processor of the SPE.
  • S510 the loading of the BIOS of the protected system from the system’s Flash and the BIOS is checked and validated.
  • the BIOS is checked for proper signatures, by a verified signer, which the integrity-check processor is configured to accept.
  • S510 further includes validating the firmware of the protected system, for example, by checking that the firmware is signed by a verified signer.
  • S510 further includes validating attestation of all supported peripheral devices connected to the protected system.
  • S550 real-time protection of the protected system is performed.
  • S550 includes accessing the memory of the protected system to monitor any process, application, and/or VM executed in the protected system, each of which can be checked in isolation by one or more security functions of the SPE.
  • the real-time protection is performed by a run-time check processor 220 of the SPE 200. Examples for security functions utilized at S550 are provided above.
  • S560 it is checked if any process, application, and/or VM breaches a security function utilized at S550. If so, at S570, an indication is provided to the main processor informing the main processor of the potentially malicious process, application, and/or VM. Otherwise, execution returns to S550.
  • the various embodiments disclosed herein can be implemented as hardware, firmware, software, or any combination thereof.
  • the software is preferably implemented as an application program tangibly embodied on a program storage unit or computer readable medium consisting of parts, or of certain devices and/or a combination of devices.
  • the application program may be uploaded to, and executed by, a machine comprising any suitable architecture.
  • the machine is implemented on a computer platform having hardware such as one or more central processing units (“CPUs”), a memory, and input/output interfaces.
  • CPUs central processing units
  • the computer platform may also include an operating system and microinstruction code.
  • a non-transitory computer readable medium is any computer readable medium except for a transitory propagating signal.
  • the phrase “at least one of” followed by a listing of items means that any of the listed items can be utilized individually, or any combination of two or more of the listed items can be utilized. For example, if a system is described as including “at least one of A, B, and C,” the system can include A alone; B alone; C alone; A and B in combination; B and C in combination; A and C in combination; or A, B, and C in combination.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un moteur de traitement sécurisé et un procédé configuré pour protéger un système informatique. Le système comprend un premier processeur configuré pour fournir une protection en temps réel à au moins des processus exécutés sur le processeur principal du système informatique protégé ; et un accès direct à la mémoire (DMA) configuré pour fournir un accès à une mémoire principale du processeur principal, le premier processeur étant couplé au DMA et configuré en outre pour surveiller les processus susmentionnés en accédant à la mémoire principale par l'intermédiaire du DMA ; le premier processeur fonctionnant dans un environnement d'exécution dans une isolation complète à partir d'un environnement d'exécution du processeur principal.
PCT/US2020/028010 2020-04-13 2020-04-13 Moteur de traitement sécurisé pour sécuriser un système informatique WO2021211091A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2020/028010 WO2021211091A1 (fr) 2020-04-13 2020-04-13 Moteur de traitement sécurisé pour sécuriser un système informatique

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2020/028010 WO2021211091A1 (fr) 2020-04-13 2020-04-13 Moteur de traitement sécurisé pour sécuriser un système informatique

Publications (1)

Publication Number Publication Date
WO2021211091A1 true WO2021211091A1 (fr) 2021-10-21

Family

ID=78083682

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2020/028010 WO2021211091A1 (fr) 2020-04-13 2020-04-13 Moteur de traitement sécurisé pour sécuriser un système informatique

Country Status (1)

Country Link
WO (1) WO2021211091A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6523119B2 (en) * 1996-12-04 2003-02-18 Rainbow Technologies, Inc. Software protection device and method
US20080181227A1 (en) * 2007-01-31 2008-07-31 Hewlett-Packard Development Company, L.P. Zero-day security system
CA2685058A1 (fr) * 2007-05-11 2008-11-20 Echostar Technologies L.L.C. Appareil pour controler l'execution d'un processeur dans un environnement securise
US7484247B2 (en) * 2004-08-07 2009-01-27 Allen F Rozman System and method for protecting a computer system from malicious software

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6523119B2 (en) * 1996-12-04 2003-02-18 Rainbow Technologies, Inc. Software protection device and method
US7484247B2 (en) * 2004-08-07 2009-01-27 Allen F Rozman System and method for protecting a computer system from malicious software
US20080181227A1 (en) * 2007-01-31 2008-07-31 Hewlett-Packard Development Company, L.P. Zero-day security system
CA2685058A1 (fr) * 2007-05-11 2008-11-20 Echostar Technologies L.L.C. Appareil pour controler l'execution d'un processeur dans un environnement securise

Similar Documents

Publication Publication Date Title
US11403403B2 (en) Secure processing engine for securing a computing system
US8910238B2 (en) Hypervisor-based enterprise endpoint protection
Zhang et al. Hypercheck: A hardware-assistedintegrity monitor
US8677482B2 (en) Hardware security for software processes
US9934380B2 (en) Execution profiling detection of malicious objects
US8966624B2 (en) System and method for securing an input/output path of an application against malware with a below-operating system security agent
EP2973171B1 (fr) Commutation basée sur le contexte à un environnement de système d'exploitation sécurisé
US8214900B1 (en) Method and apparatus for monitoring a computer to detect operating system process manipulation
US20170011220A1 (en) System and method of controlling opening of files by vulnerable applications
US20150288659A1 (en) Systems and Methods for Mutual Integrity Attestation Between A Network Endpoint And A Network Appliance
US8887302B2 (en) System, method and computer program product for utilizing code stored in a protected area of memory for securing an associated system
WO2014143029A1 (fr) Prévention d'escalade de privilège générique
Schmidt et al. Malware detection and kernel rootkit prevention in cloud computing environments
RU2724790C1 (ru) Система и способ формирования журнала при исполнении файла с уязвимостями в виртуальной машине
US20180004946A1 (en) Regulating control transfers for execute-only code execution
CN107980133B (zh) 暂时进程特权解除
Schiffman et al. The smm rootkit revisited: Fun with usb
Rutkowska Intel x86 considered harmful
Zaidenberg Hardware rooted security in industry 4.0 systems
WO2021211091A1 (fr) Moteur de traitement sécurisé pour sécuriser un système informatique
EP1902384B1 (fr) Securisation de services de reseau a l'aide de listes de controle d'actions de reseau
Schlüter et al. Heckler: Breaking Confidential VMs with Malicious Interrupts
CN116257889A (zh) 数据完整性保护方法及相关装置
EP4052154A1 (fr) Protection d'intégrité basée sur la signature d'un dispositif de bloc pour applications conteneurisées
Pereira et al. Virtualization and Security Aspects: An Overview

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: 20931205

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20931205

Country of ref document: EP

Kind code of ref document: A1

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 13/02/2024)