WO2011095484A1 - Procédé fournissant une contre-mesure destinée à empêcher l'installation de virus par destruction sur un dispositif de mémoire de masse portatif sécurisé - Google Patents

Procédé fournissant une contre-mesure destinée à empêcher l'installation de virus par destruction sur un dispositif de mémoire de masse portatif sécurisé Download PDF

Info

Publication number
WO2011095484A1
WO2011095484A1 PCT/EP2011/051402 EP2011051402W WO2011095484A1 WO 2011095484 A1 WO2011095484 A1 WO 2011095484A1 EP 2011051402 W EP2011051402 W EP 2011051402W WO 2011095484 A1 WO2011095484 A1 WO 2011095484A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
files
malware
queue
computer
Prior art date
Application number
PCT/EP2011/051402
Other languages
English (en)
Inventor
Laurent Castillo
Bart Bombay
Asad Aly
Original Assignee
Gemalto Sa
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 Gemalto Sa filed Critical Gemalto Sa
Publication of WO2011095484A1 publication Critical patent/WO2011095484A1/fr

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55Detecting local intrusion or implementing counter-measures
    • G06F21/56Computer malware detection or handling, e.g. anti-virus arrangements

Definitions

  • the present invention relates generally to protecting a computer against introduction of malware, and more particularly to protecting a computer against introduction of malware through a removable device removed from a host computer prior to complete malware-scanning.
  • a device in digital security industry parlance, a device is said to be 'torn' when while the device is communicating to a host computer or peripheral, its power and/or communication with the host is unexpectedly interrupted, e.g., by physical removal.
  • USB universal serial bus
  • this portable device anti-malware capability is implemented as part of client software that resides in a read-only partition of the portable mass storage device.
  • the client software is typically executed directly from that read-only partition.
  • the user-accessible data storage is a read/write secure storage partition that only becomes available after the user starts the client software and has correctly entered a password.
  • the client software also constantly monitors the file activity on the secure storage partition and performs a malware scan on any files that are copied to, or are changed on the partition.
  • the intent is that any malware should be quickly detected and removed from the device before that malware may be transported using the device.
  • a secure portable mass storage device e.g., the Gemalto Smart Guardian (SG).
  • SG Gemalto Smart Guardian
  • any mention of Smart Guardian or SG should be construed also as a more generic secure portable mass storage device.
  • a weakness is known for this anti-malware operation model of the above- described secure portable mass storage device.
  • the malware scan of each file takes some significant time, and takes much longer than the actual writing of the file to the secure storage partition.
  • the anti-malware software remembers them in a queue, such that they may all be scanned when computational resources are available.
  • a secure portable mass storage device may be torn from its connection before all of the queued files have been scanned for malware. In such a case, it may be possible for malware to remain stored on the device.
  • That device is thereafter inserted into a different computer (e.g., at the business or government entity), then a user of that computer may be able to transfer the stored malware from the device onto that different computer, and this can bring potentially adverse security results for the entity. If that different computer does not have its own updated anti-malware software, then that computer may be especially vulnerable to such an attack.
  • a different computer e.g., at the business or government entity
  • Figure 1 is a block diagram illustrating a high-level view of a secure peripheral device connected to a host computer wherein the interaction between the host computer user and the peripheral device is marshaled by a token client.
  • Figure 2 is a block diagram providing a high-level view of the architecture of the host computer illustrated in Figure 1.
  • Figure 3 is a block diagram of one embodiment of a peripheral device illustrated in Figure 1 , namely, a secure flash drive having a smart card module for providing security functions to protect information stored in flash memory of the secure flash drive.
  • Figure 4 is a flow-chart illustrating the process executed when a file is added to the secure partition of the secure f ash drive.
  • Figure 5 is a flow-chart illustrating the process executed when a secure flash drive is dismounted.
  • Figure 6 is a timing sequence diagram illustrating the message flow and process executed when a secure f ash drive is inserted into the host computer.
  • Figure 7 is a flow-chart illustrating the determination if any corrective action is necessary based on the file scan queue of Figure 6.
  • a technology is introduced that protects against introduction of malware onto a host computer through a removable device having been torn away from the host computer or another host computer prior to the completion of scanning for malware files.
  • the secure portable mass storage device client software is modified with regard to its manner of storing the pending queue of files for scanning. Instead of storing it only in the RAM of the host computer (as is done today), that queue is also stored in a reliable manner on the secure partition of the secure portable mass storage device, preferably with hidden attribute.
  • this queue In order for this queue to be stored reliably, it is stored in two copies: a primary copy, and a backup copy.
  • a modification of the queue occurs, it is first modified in the primary copy and those changes are flushed to the secure partition. After that primary queue copy is successfully modified, the backup copy is likewise modified.
  • a secure portable mass storage device may be torn at any time, an interrupted update of a queue copy might result in a corrupted primary queue; if such a corruption is detected, then the backup queue is used. (If the primary queue is intact, the backup queue is ignored.)
  • Hash or Signature of queue copies might result in a corrupted primary queue; if such a corruption is detected, then the backup queue is used. (If the primary queue is intact, the backup queue is ignored.
  • the queue copies on the secure portable mass storage device can also include a hash or be signed by a security component that is embedded in the secure portable mass storage device.
  • This embedded security component that signs the queue files may be a smart card chip. This hash or signature is checked when the client software first opens the secure partition, to ensure that at least one of the queues is uncorrupted. (If both queues were to be corrupted, then the client software would consider the entire secure partition to be suspect, and would take action appropriately - see below.)
  • Files are queued when they are first created, even if they don't yet have any content. (This ensures that a file will always be scanned, even if the secure portable mass storage device is torn before file write completes.) Files are removed from the queue when they have been successfully scanned for malware. If multiple threads are used for scanning, then each item in the queue also contains an indicator to show whether a file is already being scanned by a scanning thread. Each queue item might also have an indicator to show whether the file has been created (and is still being written), or whether the file write is complete.
  • Scanning might begin when the file is first created or when the file write is complete. If the scan begins with the file creation, then a method is implemented that allows the scan to switch to another file if the file writing is paused for the file that is being scanned, e.g., a timeout may be implemented in the scanner. [0030] Handling of un-scanned files
  • the secure portable mass storage device client will not allow dismount (safe removal) of the device until all of the added/changed files have been scanned.
  • the queues should normally be empty. Only when a secure portable mass storage device is torn will it be possible that files remain in the scanning queue.
  • the client software may move those files from the secure portable mass storage device to a quarantined location on the host computer (optionally simultaneously putting the files through a transform which prevents any malware contents of the file from being executed). Those files would only be replaced onto the secure portable mass storage device under safe conditions, e.g., after the files have been scanned for malware.
  • the autorun file is easily identified by only its file name (e.g., autorun.inf) without the need to scan the file contents.
  • Other known file names might for other scenarios also be a security concern.
  • the secure portable mass storage device client may be designed to include a blacklist of file names.
  • the secure portable mass storage device client will be configured to check also the name of each added/modified file to determine whether or not it is among the blacklist (e.g., an autorun file). If the file name is on the black list, then the file is immediately deleted (and thus not added to the scan queue).
  • blacklist e.g., an autorun file
  • the SG client may maintain (also as a file on the secure private partition) a list of files that have already been scanned with the latest virus definition file (date and/or signature of that definition file also stored with the list). If this list would be used as an alternative to the scan queue, then any file not on the list would be scanned. If this list would be used as a supplement to the scan queue, then it may be used as a consistency check.
  • a similar vulnerability may exist for a storage medium within a desktop computer, whereby a set of files downloaded from the internet might still be undergoing a malware scan when the computer is suddenly turned off.
  • a similar method may be applied, whereby the scanning queue is stored persistently on the storage medium in question and checked at the time of a subsequent power-up, and then any still-queued files managed as suspicious items.
  • Gemalto Smart Guardian one example of a secure portable mass storage device - has on it an antivirus scan engine, in the case of the Gemalto Smart Guardian, an antivirus scan engine from McAfee, Inc. of Santa Clara, California, USA.
  • the antivirus scan engine is encapsulated in an antivirus client (AV client), e.g., the AV client used in the SecureFlash USB Flash Drive from Encryptx Corporation (a subsidiary of
  • the AV client is stored in the readonly partition of the Gemalto SG token.
  • the AV client may have two threads: one which detects and queues the new or modified files on the secure private partition, and the other which performs the virus scanning of those files.
  • the AV client continuously watches the opened secure private partition of the secure portable mass storage device. Whenever a file appears on the partition, or whenever a file changes, then the file is considered suspect and is added to the scan queue for the antivirus, unless it is an autorun file, in which case, in one embodiment, it is immediately deleted.
  • the AV client is implemented such that the scan queue is maintained as two files on the secure portable mass storage device private partition, e.g., a queue A and a queue B.
  • these two files can be memory mapped by the AV client.
  • This allows the AV client to access and update queue elements as if updating memory locations in RAM, but actually the underlying queue file is being updated in real-time.
  • Each queue update is done first to queue A, and after that update is successful, queue B is updated.
  • Normally queue A and queue B files are identical, and are both created with hidden attributes. If needed, both queue A and queue B can be signed after each update using the key from the smart card module in the secure portable mass storage device.
  • queue B When queue A signature is good, queue B is ignored. If queue A is ever found to be corrupted, queue B is used (provided that it has a good signature). If ever both queue A and queue B are corrupted or missing, then the entire contents of the secure portable mass storage secure partition are considered to be suspect.
  • FIG. 1 is a block diagram illustrating the connection of a secure peripheral device to a host computer.
  • the secure peripheral device 103 may be, for example, a secure flash drive such as the Gemalto S/A Smart GuardianTM from Gemalto S/A of Meudon, France.
  • the secure flash drive 103 may be used for storing information securely.
  • the accessing entity Prior to allowing access to such secure files, or even to store files thereon, the accessing entity must be authenticated, for example, by login on to the secure flash drive 103 using a PIN.
  • a tear of the secure flash drive 103 may allow the introduction of malware that has not been scanned properly.
  • the re-insertion of the secure flash drive into the host computer or another host computer may result in introduction of that malware into the host computer to which the flash drive 103 is inserted.
  • FIG. 2 is a block diagram of the architecture of the host computer 105 and further illustrating that the host computer 105 may be connected to a display device 201 for displaying graphic user interfaces 203 to a user.
  • the host computer 105 may include a central processing unit 205, a memory 207, and a secondary storage system 209.
  • the secondary storage system 209 (which may be external or internal hard disk drives, read-only memory, firmware, non- volatile memory, etc.) stores computer programs 211 for execution by the central processing unit 205.
  • Other components of the host computer 105 include an input/output module 213, a smart card connector 215 and a USB (universal serial bus) connector 217 for allowing the host computer 105 to connect to input/output devices such as display 201, smart cards, and USB peripheral devices such as the flash drive 103, respectively.
  • USB flash drive 103 When the USB flash drive 103 is inserted into the host computer 105 USB connector 217 a token client 107 is loaded from the flash memory of the USB flash drive 103 into the memory 207 (see Figure 3).
  • the token client 107 marshals the interaction between the host computer 105 and the flash drive 103.
  • the token client 107 includes the AV client described herein and may also include other software components such as components for authentication, safe device removal, etc. In one embodiment, such components are executed in separate threads to cooperatively achieve the functionality described herein.
  • FIG. 3 is a block diagram illustrating a high-level view of the architecture of a USB flash drive 103 incorporating a smart card module 313 for providing security functionality, e.g., authentication and cryptographic services, to enhance the security of data stored on the USB flash drive 103 (referred to hereinafter as a USB flash drive SC).
  • a USB flash drive SC 103 is constructed with a USB connector 317, and has a USB flash drive micro-controller 303 having a microprocessor 305, a non-volatile memory (NVM) 307, and a random access memory (RAM) 309, as well as a flash memory chip 311.
  • NVM non-volatile memory
  • RAM random access memory
  • the flash memory chip contains the token client 107 that is loaded into the memory 207 of the host computer 105 when the USB flash drive SC 103 is inserted into the USB connector 217 of the host computer 105. Additionally the USB flash drive SC 103 contains a smart card module 313 connected to the USB flash drive micro-controller 303.
  • the smart card module 313 is used by the USB flash drive SC 103 to authenticate a user and to provide certain cryptographic capabilities.
  • a logon screen may be presented to a user requesting the user to authenticate himself or herself using a PIN or password.
  • Authentication is then entirely a negotiation between the host computer 105 and the smart card module 313 via the micro-controller 303 with only the result being used by the firmware 315 executing on the USB flash drive micro-controller 303.
  • the communication between the host the computer 105 and the USB flash drive SC 103 is performed using the USB mass storage protocol and the USB CCID (Chip Card Interface Device) protocol.
  • the firmware control program 315 contains start-up instructions executed on initialization of the USB flash drive SC 103. Several of the start-up procedures are discussed in greater detail hereinbelow.
  • USB enumeration is one function performed during startup of the USB flash drive SC 103.
  • the USB flash drive SC 103 enumerates itself as one or more USB mass storage drives and as a smart card interface device (akin to a USB smart card reader) to allow for communication using the CCID protocol.
  • the firmware control program 315 contains the necessary instructions to act as a CCID device when the host computer 105 directs communication to the smart card module 313.
  • the communication between the host computer 105 and the USB flash drive SC 103 is performed using the USB mass storage protocol and the HID (Human Interface Device) protocol.
  • the firmware control program 315 contains start-up instructions executed on initialization of the USB flash drive SC 103.
  • USB enumeration is one function performed during startup of the USB flash drive SC 103.
  • the USB flash drive SC 103 enumerates itself as one or more USB mass storage drives and as an HID device (akin to a USB mouse or keyboard) to allow for communication using the HID protocol. This mechanism allows communication to take place over existing device drivers present in all modern operating systems.
  • the firmware control program 315 contains the necessary instructions to act as an HID device when the host computer 105 directs communication to the smart card module 313.
  • the flash memory chip 311 contains a secure partition 501 and a read-only partition 503.
  • the flash memory chip 311 contains a file-scan queue 505 in the secure partition 501.
  • a backup file-scan queue 507 of the file-scan queue 505 is also included in the secure partition 501.
  • FIG. 5 A token client 107 is included in the read-only partition 503.
  • the token client 107 is loaded onto memory 207 of the host computer 105 when the flash drive 103 is inserted in the host computer 105 or otherwise powered up.
  • Figure 4 is a flow-chart illustrating one embodiment of a file addition to the secure partition 501. A file is written to the secure partition 501 of the secure flash drive 103, step 611.
  • a thread of the token client receives a notification (e.g., from the host operating system) that a file has been added to the secure partition 501.
  • the notification includes a file identifier.
  • the file identifier is checked against a blacklist, step 601. If the file is on the blacklist, e.g., the blacklist includes "autorun" to guard against autorun files, the file is immediately deleted, step 603.
  • the flash drive immediately adds the file identifier to the file-scan queue 505, and, in an alternative embodiment, also to the back up file-scan queue 507, step 609.
  • step 613 the file is scanned for malware, step 613.
  • the scan result is evaluated, step 615. If the scan result shows that the file contains malware, the token client deletes the file (or performs some other remedial action), step 619, and removes the file identifier from the file-scan queue 505 and, alternatively, also from the backup file-scan queue 507, step 617.
  • the file identifier is removed from the file-scan queue 505 and, alternatively, also from the backup file-scan queue 507, step 617.
  • the file-scan queue 505 would still contain the file identifier. This time window would be very short. However, even so, if the file-scan queue 505 were corrupted (e.g., if torn while removing a file identifier), then the backup queue 507 would be valid.
  • a further counter measure is the consistency check described herein above, for example, in the section entitled "List of Scanned Files" as an inconsistency would be detected between the list of scanned files, the list of files in the file-scan queue and the files found in the secure flash drive 103.
  • FIG. 5 is a flow chart illustrating a dismount sequence for the secure flash drive 103.
  • the token client 107 of the host computer 105 receives a dismount instruction, step 701.
  • the token client 107 determines whether the file-scan queue is empty, step 703. If it is empty, the flash drive may be dismounted, step 705.
  • step 707 determines if safe, step 709, any unsafe files are removed (or some alternative remedial action is taken), step 711, and the corresponding file identifiers are removed from the file- scan queue 505, step 713, until the file-scan queue 505 is empty, step 703. If a backup file- scan queue 507 is used, the file identifiers are also removed from the backup file-scan queue 507.
  • Figure 6 is a timing sequence diagram illustrating the operation of a secure flash drive 103 and a host computer 105 that takes place upon an insertion of the secure flash drive 103 into the host computer 105.
  • the host computer 105 may be a different host computer 105 from the host computer 105 used to create the file scan queue 505 while adding files to the secure flash drive 103.
  • the process illustrated in Figure 6 (and elaborated upon in Figure 7) serves to protect the receiving host computer 105 from malware that may have been introduced onto the secure flash drive 103 by another host computer 105.
  • the secure flash drive 103 is inserted into a connection on the host computer 105, e.g., into a USB connection, step 801.
  • the token client 107 is transmitted to the host computer 105 or loaded by the host computer 105, step 803. [0082] The host 105, executing the token client 107, authorizes access to the secure partition, step 804, through some user authorization mechanism, for example, performed by a challenge-response test performed by the S/C module 313.
  • the host 105 executing the token client 107, uses the file scan queue to determine if scanning or other protective action is necessary (illustrated in Figure 7 and discussed in greater detail herein below), step 805.
  • Figure 7 is a flow-chart illustrating the determination if any corrective action is necessary based on the file scan queue 505; illustrating both an embodiment without a backup file scan queue 507 and also an embodiment wherein a backup file scan queue 507 is used.
  • the host 105 determines whether the primary file scan queue 505 is empty, step 903. If primary file scan queue is determined to be empty, no scanning is necessary, step 905. Otherwise, the files identified in the scan queue are scanned or immediately deleted, step 907.
  • step 901 If, on the other hand, the primary queue is corrupted, step 901, and no backup queue 507 is used, the entire secure partition is treated as being suspect to malware and protective actions are taken accordingly, such as scanning or immediate deletion, step 909.
  • step 901 the host 105, executing the token client 107, determines whether the backup queue 507 is also corrupted, step 911.
  • step 901 If the primary queue 505 is corrupted, step 901, and - in the embodiment using a backup queue 507 - the backup queue 507 is not corrupted, step 911, and is found to be empty, step 913, no scanning is necessary, step 905. If the backup queue is not corrupted and found to be not empty, step 913, the backup queue 507 is used as the file scan queue 505, step 915, and files identified therein are scanned and protective action is taken accordingly, such as scanning or immediate deletion, against any files identified as containing malware, step 907. [0090] If in addition to the primary queue 505 being corrupted, the backup queue 507 is also corrupted, the entire secure partition 501 is treated as being suspect to malware and protective actions are taken accordingly, such as scanning or immediate deletion, step 909.
  • Protective action against files in the file scan queue includes immediately deleting the files, scanning the files, or placing the files in quarantine. In the event files are scanned and identified as containing malware, the protective action may be to either delete the file, quarantine the file, or to remove any identified malware therefrom.
  • files may be moved to a quarantined location, and files are only made available to the host computer 105 after successful scanning establishes that the file contains no known malware.
  • the user of the secure flash drive 103 may be alerted that a security problem has been detected and allowing the user to select which course of action to take in regard thereto. For example, the user may be given the option of deleting the suspect files, quarantining and scanning the suspect files, or taking no action with respect to the suspect files.
  • the step of determining if the file scan queue is empty also includes verifying the integrity of the file-scan queue 505. If the file-scan queue 505 is determined to be corrupt, the token client 107 attempts using the backup file-scan queue 507 instead and ignores the file-scan queue 505. If the backup file-scan queue is also corrupt, the entire secure partition 501 is deemed suspect for malware and appropriate corrective action, e.g., deleting or scanning the entire partition, is taken.

Abstract

L'invention concerne un procédé permettant d'utiliser un jeton sécurisé en association avec un ordinateur hôte afin de garantir que cet ordinateur hôte ne sera pas infecté par un logiciel malveillant introduit à partir dudit jeton sécurisé par « destruction » de ce dernier avant la fin d'une analyse recherchant des logiciels malveillants. Ce procédé consiste à ajouter une file d'attente d'analyse de fichiers qui identifie les fichiers devant être analysés à la recherche d'un logiciel malveillant et qui est toujours stockée dans le jeton. Si la file d'attente d'analyse de fichiers n'est pas vide lors de l'activation du jeton sécurisé, cela indique que l'analyse du jeton est incomplète et qu'il est possible que les fichiers identifiés contiennent un logiciel malveillant. Une action correctrice peut alors être accomplie.
PCT/EP2011/051402 2010-02-02 2011-02-01 Procédé fournissant une contre-mesure destinée à empêcher l'installation de virus par destruction sur un dispositif de mémoire de masse portatif sécurisé WO2011095484A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US30082410P 2010-02-02 2010-02-02
US61/300,824 2010-02-02

Publications (1)

Publication Number Publication Date
WO2011095484A1 true WO2011095484A1 (fr) 2011-08-11

Family

ID=43799431

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2011/051402 WO2011095484A1 (fr) 2010-02-02 2011-02-01 Procédé fournissant une contre-mesure destinée à empêcher l'installation de virus par destruction sur un dispositif de mémoire de masse portatif sécurisé

Country Status (1)

Country Link
WO (1) WO2011095484A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2667314A1 (fr) * 2012-05-22 2013-11-27 Kaspersky Lab Zao Système et procédé de détection et de traitement de logiciels malveillants sur des dispositifs de stockage de données
WO2016105851A1 (fr) * 2014-12-23 2016-06-30 Mcafee, Inc. Stockage portable sécurisé
CN111428272A (zh) * 2020-04-21 2020-07-17 深圳融安网络科技有限公司 移动存储设备的安全访问方法、设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070083939A1 (en) * 2005-10-07 2007-04-12 Fruhauf Serge F Secure universal serial bus (USB) storage device and method
US20070240218A1 (en) * 2006-04-06 2007-10-11 George Tuvell Malware Detection System and Method for Mobile Platforms
WO2008003174A1 (fr) * 2006-07-06 2008-01-10 Memory Experts International Inc. Procédé et dispositif utilisés pour scanner des données à la recherche de signatures avant le stockage dans un dispositif de stockage
US20090249464A1 (en) * 2008-03-26 2009-10-01 Fego Precision Industrial Co., Ltd. Firewall for removable mass storage devices

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070083939A1 (en) * 2005-10-07 2007-04-12 Fruhauf Serge F Secure universal serial bus (USB) storage device and method
US20070240218A1 (en) * 2006-04-06 2007-10-11 George Tuvell Malware Detection System and Method for Mobile Platforms
WO2008003174A1 (fr) * 2006-07-06 2008-01-10 Memory Experts International Inc. Procédé et dispositif utilisés pour scanner des données à la recherche de signatures avant le stockage dans un dispositif de stockage
US20090249464A1 (en) * 2008-03-26 2009-10-01 Fego Precision Industrial Co., Ltd. Firewall for removable mass storage devices

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2667314A1 (fr) * 2012-05-22 2013-11-27 Kaspersky Lab Zao Système et procédé de détection et de traitement de logiciels malveillants sur des dispositifs de stockage de données
WO2016105851A1 (fr) * 2014-12-23 2016-06-30 Mcafee, Inc. Stockage portable sécurisé
CN111428272A (zh) * 2020-04-21 2020-07-17 深圳融安网络科技有限公司 移动存储设备的安全访问方法、设备及存储介质

Similar Documents

Publication Publication Date Title
US11947688B2 (en) Secure computing system
US10162975B2 (en) Secure computing system
US9390262B2 (en) Method for protecting computer programs and data from hostile code
US7853999B2 (en) Trusted operating environment for malware detection
US7657941B1 (en) Hardware-based anti-virus system
US8104088B2 (en) Trusted operating environment for malware detection
US9432397B2 (en) Preboot environment with system security check
US20060230454A1 (en) Fast protection of a computer's base system from malicious software using system-wide skins with OS-level sandboxing
US20080005797A1 (en) Identifying malware in a boot environment
US9251350B2 (en) Trusted operating environment for malware detection
WO2011095484A1 (fr) Procédé fournissant une contre-mesure destinée à empêcher l'installation de virus par destruction sur un dispositif de mémoire de masse portatif sécurisé
JP4627266B2 (ja) 未知のマルウェアによる情報漏洩防止システム
RU92217U1 (ru) Аппаратный антивирус

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

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

Country of ref document: EP

Kind code of ref document: A1