WO2011095484A1

WO2011095484A1 - Method of countermeasure against the installation-by-tearing of viruses onto a secure portable mass storage device

Info

Publication number: WO2011095484A1
Application number: PCT/EP2011/051402
Authority: WO
Inventors: Laurent Castillo; Bart Bombay; Asad Aly
Original assignee: Gemalto Sa
Priority date: 2010-02-02
Filing date: 2011-02-01
Publication date: 2011-08-11

Abstract

A method of operating a secure token in conjunction with a host computer to ensure that the host computer is not infected with malware introduced from the secure token by "tearing" the secure token prior to completion of a malware scan. The method includes introducing a file-scan queue identifying files needed to be scanned for malware, with that file-scan queue persistently stored on the token. If the file-scan queue is not empty upon power-up of the secure token, that condition is taken to indicate incomplete scanning of the token and that the identified files may potentially include malware. Corrective action may then be taken.

Description

METHOD OF COUNTERMEASURE AGAINST THE INSTALLATION-BY- TEARING OF VIRUSES ONTO A SECURE PORTABLE MASS STORAGE

DEVICE

BACKGROUND OF THE INVENTION

[0001] 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. [0002] Definition: 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.

[0003] Today we commonly use portable mass storage devices, e.g., USB (universal serial bus) mass storage tokens, for easily transporting large amounts of digital data from one computer to another. With this ease of transport comes also the danger of transporting (either intentionally or unintentionally) malicious software (malware), e.g., a virus which might spy sensitive data stored on a computer. This can be particularly worrisome for businesses and government entities that work with highly sensitive data on their computer systems. Nevertheless, these entities wish to allow the transport of other data which is beneficial to worker productivity.

[0004] In order to allow the digital data transport while minimizing risk of exposure to malware, some entities restrict the use of portable mass storage devices to those devices which include within them an explicit anti-malware capability. In industry, 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. However, to improve performance it may also be copied to a temporary location on the host computer's hard disk and executed from there. 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. Such a device is sometimes called a secure portable mass storage device, e.g., the Gemalto Smart Guardian (SG). Within this document, any mention of Smart Guardian or SG should be construed also as a more generic secure portable mass storage device.

[0005] 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. When many files (or few large files) are quickly written to the partition, the anti-malware software remembers them in a queue, such that they may all be scanned when computational resources are available. However, it is also possible that 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. If 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.

[0006] The same weakness to a lesser degree may also affect the anti-malware functions on a desktop computer. If the power to such a computer were forcibly switched off very precisely after the computer had loaded several large and small files from the Internet, some of those files might escape scanning. To address this, some host computer based anti- virus engines adopt a different approach. Instead of scanning the files after they are written to hard disk, the anti- virus software taps into the file I/O interface of the host operating system and scans the data for viruses before it is written to the hard disk. While this method does not suffer from tearing attacks, it does require an installation of the antivirus software so that it can attach itself to the I/O level operating system driver. The solution is limited to only those computers on which this installation has been done. This approach cannot be adopted for secure USB tokens to connect to any host computer without requiring an installation.

[0007] At present in the industry, there are no known solutions to the aforementioned problem associated with tearing of a portable device prior to complete malware scanning, despite an active desire in industry to eliminate this weakness.

[0008] From the foregoing it is apparent that there is still a need for an improved method to provide a secure mechanism for securing 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 completion of scanning for malware files. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] 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.

[0010] Figure 2 is a block diagram providing a high-level view of the architecture of the host computer illustrated in Figure 1.

[0011] 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.

[0012] 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.

[0013] Figure 5 is a flow-chart illustrating the process executed when a secure flash drive is dismounted.

[0014] 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.

[0015] Figure 7 is a flow-chart illustrating the determination if any corrective action is necessary based on the file scan queue of Figure 6.

DETAILED DESCRIPTION OF THE INVENTION

[0016] In the following detailed description, reference is made to the accompanying drawings that show, by way of illustration, specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. It is to be understood that the various embodiments of the invention, although different, are not necessarily mutually exclusive. For example, a particular feature, structure, or characteristic described herein in connection with one embodiment may be implemented within other embodiments without departing from the spirit and scope of the invention. In addition, it is to be understood that the location or arrangement of individual elements within each disclosed embodiment may be modified without departing from the spirit and scope of the invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims, appropriately interpreted, along with the full range of equivalents to which the claims are entitled. In the drawings, like numerals refer to the same or similar functionality throughout the several views.

[0017] The discussion herein describes various software components. These software components provide instructions for the computers or computerized equipment that executes the software components. For the sake of brevity, the discussion may say that a software component performs a particular action. That, of course, means that it is the computer or computerized equipment that executes the software component that in fact performs that described action. Conversely, while the software components and methods are said to cause particular operations to occur on particular computers or computerized equipment, such descriptions are typically merely one embodiment of which computer or computerized equipment executes a particular method or software component. Execution by other computers to perform the same task should be considered equivalent embodiments to the implementation described.

[0018] In an embodiment of the invention, 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.

[0019] An illustrative operating environment, an illustrative example architecture, and an embodiment for implementing a solution to the aforementioned vulnerability is described hereinbelow in conjunction with Figures 1 through 6. A mechanism for solving the aforementioned vulnerability to malware introduction via a removable device that is torn away prior to completion of malware scanning is first described herein in general terms.

[0020] Queue stored on the Secure Portable Mass Storage Device

[0021] First, 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.

[0022] Two copies of queue

[0023] In order for this queue to be stored reliably, it is stored in two copies: a primary copy, and a backup copy. When 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. Because 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.) [0024] Hash or Signature of queue copies

[0025] For added security, 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.) [0026] Queue management

[0027] 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.

[0028] Scanning [0029] 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

[0031] Under normal operation, 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. Thus when a secure portable mass storage device is inserted into a computer, 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.

[0032] Deletion of suspects

[0033] If upon insertion and unlocking of a secure partition it is found that files remain in the queue to be scanned, those files are considered to be suspect, and actions are taken by the client to manage the risk of malware. In the simplest and most direct action, the client software immediately deletes those suspect files, and after the deletion it could notify the user of the action taken and which files were deleted (and explain that it was due to a tear of the device, for security reasons).

[0034] This most simple action is also the most secure and most easily implemented, such that the modification can be done with minimal impact on pre-existing software designs.

[0035] Temporary removal of suspects

[0036] In an alternative action, 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. [0037] User choice for lower security scenarios

[0038] In a lower security implementation, the above actions may be taken only after approval by the user. Thus a pop-up message may inform the user of the risk and allow the user to decide regarding the deletion or additional scanning. [0039] Autorun protection and file name blacklist

[0040] In addition to the above-described scenarios, we also consider the risk of a malware or malicious user to place an autorun file on the secure partition. For example, the malicious user could copy a large file to the partition, followed by a virus file and an autorun file, and the user could then quickly tear the device. That autorun file could then execute the virus file at next opening of the partition. Thus the autorun might cause the virus to infect the target machine before the SG client is able to delete the virus file (e.g., if autorun did execute before the above-described countermeasure).

[0041] 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. Thus the secure portable mass storage device client may be designed to include a blacklist of file names.

[0042] In order to protect against this attack, 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).

Since this is an immediate action that does not wait for the scan queue, we can be confident that the autorun file will not remain on the device when it is removed, and thus the device is well protected against this attack. [0043] List of scanned files

[0044] As an alternative or supplement to the scan queue, 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.

[0045] Similar vulnerability for desktop computer

[0046] Depending upon the type of anti-virus software used, 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. To combat this vulnerability, 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.

[0047] Description of a practical example.

[0048] Gemalto Smart Guardian (SG) - 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

BeCompliant Corportion, Louisville, Colorado, USA). 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.

[0049] 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.

[0050] With the technology described herein, 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. For fast read/write operations and ease of software implementation 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. 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.

[0051] If during the middle of operating, i.e., not at unlocking of private partition after insertion, then the detection of both queues being corrupted or missing leads to all files of the secure portable mass storage device private partition to be considered suspect. They may be all deleted, or they may be added to a newly written queue. Also a notice to the user may be popped up to inform about the disruption (possible attack) of the queue files.

[0052] If at insertion and unlocking of the private partition it is found that the queue is non-empty, then all files in the queue are considered to be suspect. They may be deleted, or the AV client may merely pop-up a notice to the user describing the files as being suspect.

[0053] The AV client is also implemented to disallow the user from logging out from the secure peripheral device 103, or closing of the private partition while any files remain in the scanning queue, i.e., while file scanning is in progress. [0054] Figure 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 Guardian™ from Gemalto S/A of Meudon, France. In one mode of operation, the secure flash drive 103 may be used for storing information securely. 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.

[0055] As noted herein above, 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.

[0056] Figure 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. Typically 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. 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). As is described herein below, 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.

[0057] Figure 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). [0058] 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. 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.

[0059] In one embodiment, the smart card module 313 is used by the USB flash drive SC 103 to authenticate a user and to provide certain cryptographic capabilities. Thus, for example, when the USB flash drive SC 103 is inserted into a computer 105, 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. [0060] In one embodiment, 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.

[0061] Operations of the USB flash drive micro-controller 303 are according to instructions stored in a firmware control program 315 stored in the NVM memory 307. 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.

[0062] 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. [0063] In an alternative embodiment, 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.

[0064] Operations of the USB flash drive micro-controller 303 are according to instructions stored in a firmware control program 315 stored in the NVM memory 307. 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. [0065] 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. In one embodiment a backup file-scan queue 507 of the file-scan queue 505 is also included in the secure partition 501.

[0066] 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. [0067] 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.

[0068] 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.

[0069] In one embodiment, illustrated by the inclusion of decision box 601 and step 603 into the flow chart of Figure 4, 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.

[0070] Otherwise, i.e., without the blacklist check or if the blacklist check is negative, 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.

[0071] Next the file is scanned for malware, step 613. [0072] 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.

[0073] If the scan result shows that there is no malware in the file, the file identifier is removed from the file-scan queue 505 and, alternatively, also from the backup file-scan queue 507, step 617.

[0074] Thus, if at any time between the addition of the file identifier to the file-scan queue and the completion of the malware scan the secure flash drive 103 is torn from the host computer 105, 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.

[0075] Figure 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.

[0076] 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.

[0077] If not, all the files identified in the file-scan queue 505 are scanned, step 707, determined 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.

[0078] Thus, if any file is left in the file-scan queue 505 as unscanned, the normal dismount procedure would not complete until after the scan is completed and any remedial action (such as removing the file) has been performed on all files in the secure partition 501. If the secure flash drive 103 is prematurely removed, the file-scan queue 505 (and alternatively the backup file-scan queue 507) still contains identifiers for any files that have not been scanned.

[0079] 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. It should be noted that 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.

[0080] The secure flash drive 103 is inserted into a connection on the host computer 105, e.g., into a USB connection, step 801.

[0081] 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.

[0083] 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.

[0084] 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.

[0085] First, it is determined if the primary file scan queue 505 is corrupted, step 901.

[0086] If the primary file scan queue 505 is not corrupted, the host 105, executing the token client 107, 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.

[0087] 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.

[0088] In the alternative embodiment in which a backup queue 507 is used, if it is determined that the primary file scan queue 505 is corrupted, step 901, the host 105, executing the token client 107, determines whether the backup queue 507 is also corrupted, step 911.

[0089] 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.

[0091] When all scanning and corrective action has been taken, access to the secure partition may continue, step 917.

[0092] Protective action against files in the file scan queue (or the backup file scan queue if used) 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.

[0093] In the case of placing the files in the file scan queue in quarantine, 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.

[0094] Alternatively, 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.

[0095] In the alternative embodiment in which a backup file-scan queue 507 is utilized, 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.

[0096] From the foregoing it will be apparent that an improved method is introduced herein the method being for securing 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 completed scanning for malware files being performed.

[0097] Although specific embodiments of the invention have been described and illustrated, the invention is not to be limited to the specific forms or arrangements of parts so described and illustrated. The invention is limited only by the claims. [0098] We Claim:

Claims

1. A method for protecting a removable memory token having a secure partition against being a carrier of malware from one computer to another computer, comprising: upon receiving a file for storage in the secure partition from a host device to which the token is connected, entering a file identifier in a file-scan queue stored on the token; scanning any files identified in the file-scan queue for malware and upon

completing scanning of any such file identified in the file-scan queue, removing the any such file identified in the file-scan queue file from the file- scan queue; upon authorizing access to the secure partition, determining if the file-scan queue is empty; and upon start-up of the removable memory token, detecting that the file-scan queue is not empty, taking a protective action against any file identified in the file- scan queue.

2. The method of securing a removable token having a secure partition against being a carrier of malware from one computer to another computer of Claim 1 wherein the file-scan queue comprises a primary file-scan queue and a backup file-scan queue, and wherein the step of storing a file identifier in a file-scan queue comprises storing the file identifier in both the primary file- scan queue and the backup file- scan queue; and wherein the step of upon start-up of the removable memory token, determining if the file-scan queue is empty comprises: determining if the primary file-scan queue is corrupted; upon detecting that the primary file- scan queue is corrupted, determining if the backup file-scan queue is also corrupted; upon detecting that the primary file- scan queue is not corrupted, using the primary file-scan queue to determine if the file-scan queue is empty; upon detecting that the primary file- scan queue is corrupted and that the backup file- scan queue is not corrupted, using the backup file- scan queue to determine if the file-scan queue is empty; and upon detecting that both the primary file-scan queue and the backup file- scan queue are corrupted, treating the secure partition as suspect of carrying malware.

3. The method of securing a removable token having a secure partition against being a carrier of malware from one computer to another computer of Claim 2 wherein the primary file-scan queue and the backup file-scan queue are stored in the secure partition.

4. The method of securing a removable token having a secure partition against being a carrier of malware from one computer to another computer of Claim 1 comprising entering the file identifier into the file-scan queue upon creation of a file in the secure partition; and removing the file identifier from the file-scan queue upon successfully scanning the file and determining that the file does not contain known malware.

5. The method of securing a removable token having a secure partition against being a carrier of malware from one computer to another computer of Claim 1 wherein taking a protective action comprises: deleting any files for which file-identifiers remain in the file-scan queue.

6. The method of securing a removable token having a secure partition against being a carrier of malware from one computer to another computer of Claim 1 wherein taking a protective action comprises: moving any files for which file-identifiers remain in the file-scan queue to a quarantined location.

7. The method of securing a removable token having a secure partition against being a carrier of malware from one computer to another computer of Claim 1 wherein taking a protective action comprises: making files from the quarantined location available in the secure partition only after successful scanning establishes that the file contains no known malware.

8. The method of securing a removable token having a secure partition against being a carrier of malware from one computer to another computer of Claim 1 wherein taking a protective action comprises: alerting a user of the removable token that a security problem has been detected and allowing the user to determine which course of action to take with respect to files identified in the file-scan queue.

9. The method of securing a removable token having a secure partition against being a carrier of malware from one computer to another computer of Claim 1 comprising; if the scanning of the file shows malware detected, taking remedial action for the malware file; and removing the file identifier from the file-scan queue after the scan is complete and any remedial action has been taken.

10. The method of securing a removable token having a secure partition against being a carrier of malware from one computer to another computer of Claim 1 comprising: detecting the presence of any blacklisted files in the secure partition; and removing any detected blacklisted files from the secure partition.

11. The method of securing a removable token having a secure partition against being a carrier of malware from one computer to another computer of Claim 10 wherein the detecting of the presence of blacklisted files is performed immediately upon reception of the file identifier, and any remedial action taken immediately without the need to wait for a malware scan of the file.

12. A method of operating a first computer and a second computer to track which files on a storage medium are suspect and to take corrective actions upon those suspect files such that the second computer using the same storage medium is better protected against malware, comprising :□ determining additions of new files or changes to existing files in the storage

medium and treating new or changed files as suspect, and maintaining a queue of suspect files of the storage medium persistently on the same storage medium in the presence of unexpected interruptions of operation to the first computer, andD sequentially scanning suspect files for malware while the first computer is still operating and removing files not found to be infected with malware from the queue, and upon opening of the storage medium by a second computer after an interruption of operation to the first computer, taking protective action against any remaining suspect files identified in the queue, thereby protecting the second computer from possible malware contained in those suspect files.

13. A method of claim 12 wherein taking protective action against remaining suspect files upon the opening of the storage medium consists of immediately deleting at least one of the remaining suspect files.

14. The method of Claim 12 or 13 wherein taking protective action against remaining suspect files upon the opening of the storage medium consists of repairing at least one of the remaining suspect files.

15. A method of claim 12 wherein taking protective action againstremaining suspect files upon the opening of the storage medium comprises □ moving remaining suspect files into a quarantine,□ scanning quarantined files for malware, deleting quarantined files detected as containing malware, and□ replacing files that have not been detected as containing malware back onto the storage medium.

16. A method of claim 12 through 15 wherein handling of remaining suspect files upon the opening of the storage medium comprises presenting a user interface whereby the user may choose an action among:□ deleting the suspect files, quarantining and scanning the suspect files, orD taking no action.

17. A method of any of claims 12 through 16 wherein before adding a suspect file to the queue, checking the filename of the file against a blacklist, and upon detecting a match of the filename of the file with a name in the blacklist, deleting the file immediately.

18. A method of claim 1 through 17 wherein the storage medium is a portable secure USB mass storage device.

19. A secure removable token having a secure partition and comprising: a memory area for storing instructions executable on a host computer to which the secure removable token may be connected, the instruction including an autorun module executable upon power-up of the secure removable token and comprising instructions directing the host computer to perform the method of any of Claims 1 through 18.