GB2495648A

GB2495648A - Maintaining a database of trusted public keys in a plurality of computer devices

Info

Publication number: GB2495648A
Application number: GB1222212.1A
Authority: GB
Inventors: Jarno Niemela
Original assignee: F Secure Oyj
Current assignee: WithSecure Oyj
Priority date: 2008-09-11
Filing date: 2008-09-11
Publication date: 2013-04-17
Also published as: GB201222212D0

Abstract

The application discloses a method of maintaining a database of trusted public keys in a plurality of computer devices. Preferably, the keys are stored in a memory 102 of said device 101. The keys must be suitable for the purpose of eliminating the need to scan trusted files for malware at the computer devices (e.g. see S8, fig. 2). In the method, public keys are identified at a network based service, preferably a certificate authority or CA. The keys belong to a public key infrastructure or PKI architecture and are used in the digital signing of electronic files. The keys, which the method verifies as belonging to a trusted source, are sent securely to the devices.

Description

I

MAL WARE DETECTION

Technical Field

The present invention relates to maiware detection.

Background

Malwarc is short for malicious software and is used as a term to refer to any software designed to infiltrate or damage a computer system without the owner's informed consent. Malwarc can include viruses, worms, trojan horses, rootkits, adwarc, spywarc and any other malicious and unwanted software. Any computer device, such as a desktop personal computer (PC), laptop, personal data assistant (PDA) or mobile phone, can be at risk from malware.

When a device is infected by malware the user will often notice unwanted behaviour and degradation of system performance as the infection can create unwanted processor activity, memory usage, and network traffic. This can also cause stability issues leading to application or system-wide crashes. The user of an infected device may incorrectly assume that poor performance is a result of software flaws or hardware problems, taking inappropriate remedial action, when the actual cause is a malwarc infection of which they arc unaware.

Detecting malwarc is challenging as the malwarc authors design their software to be difficult to detect, often employing teclmology that deliberately hides the presence of maiware on a system, i.e. the malware application may not show up on the operating system tables that list currently running processes.

Computer devices make use of anti-virus software to detect and possibly remove malware. This anti-virus software can make use of various methods to detect malware including scanning, integrity checking and heuristic analysis. Of these methods, malware scanning involves the anti-virus software examining files for a virus fingerprint or "signature" that is characteristic of an individual malware program. Typically, this requires that the anti-virus software has a database containing the signatures. When the provider of the anti-virus software identifies a new malware threat, the threat is analysed and its signature is extracted. The maiware is then "known" and its signature can be supplied as updates to the anti-virus software database. However, scanning files for malware can consume significant processing resources potentially resulting in a reduction in the performance of a computing device.

In order to reduce this processing burden, some anti-virus solutions provide for lists of trusted files that are highly unlikely to be a source of malware. These trusted files are those files published or authored by trusted sources. For example, those files that make up a piece of software distributed by a reputable software provider could be considered to be trustworthy such that, provided such files have not been modified since their publication/release, these files need not be scanned for malware.

The provider of the anti-virus software identifies files that can be considered trustworthy and applies a one-way hash function to the file to convert it to a fixed-lcngth string known as a hash value (also known as a digcst). For a description of one-way hash functions see Chapter 2 of Applied Cryptography by Bruce Schneier, 1997. The hash value provides a fingerprint of the file that is highly unlikcly to bc duplicated by another input. Given the extremely small probability of such a collision' and the one-way nature of a hash function, it is extremely difficult or almost impossible to calcuLate the input that has produced a given hash value, even though the hash function used to generate the hash value is publicly available. The list of the hash values of these trusted files is secured against unauthorised modification (i.e. by digitally signing the trusted file list) and provided to a user's device.

Prior to scanning a given file to determine if the file could possibly be or contain malware (for example when prompted by the user, when due to perform a scheduled scan, or when initiated in response to a request to run the file or in response to the receipt of the file), the anti-virus software will determine if the file is on the trusted file list. The anti-virus software applies the same one-way hash frmnction to the file to be checked and then compares the resulting hash value with the trusted file list provided by the supplier of the anti-virus software. If a match is found in the list, there is an extremely high probability that this file can be trusted, i.e. it is from a trusted source and has not been modified since its first publication, and therefore it need not be scanned for matware.

As with a database of virus signaturcs, in order for a trusted file list to be widely effective for use, it must include the hash value of as many trusted files as possible.

The anti-virus supplier does not necessarily know what files are in use, or are likely to be used, in each user device. Given that there are thousands of files that are published by a variety of trusted sources, these trusted file lists are large and can consume a significant amount of memory. This is a particular problem for devices such as mobile phones and PDA's that are likely to be provided with less memory than a traditional PC. Moreover, the list must also be continually updated by the provider of the anti-virus software, requiring that it must expend significant effort to both maintain and expand the list.

Summary

There is provided a malware detection method implemented within a computer. The method comprises, for a given electronic file, determining if the file is associated with a valid digital signature. If the file is associated with a valid digital signature, then verifying that the signature belongs to a trusted source. If the signature does belong to a trusted source then not performing a maiware scan of said file, and if the signature cannot be verified as belonging to a trusted source then performing said sean.

The method provides that trusted files can be identified dynamically within an individual device, removing the burden placed on the anti-virus provider to maintain and update a trusted file list. Furthermore, dynamically identifying trusted files within a device would, in most cases, ensure that a larger proportion of the trustworthy files present on a device are identified. This further reduces the processing burden by minimising the number of files that require a full malware scan.

Preferably, if the file is associated with a valid digital signature and the signature belongs to a trusted source, generating a hash value of the file path and adding the file path hash value to a database of trusted files. Then on subsequent occasions and prior to determining if the file is associated with a valid digital signature, the method may further comprise, generating a hash value of the file path and determining if the hash value of thc file path is contained in thc database of trusted files. If the hash value of the file path is contained in the database of trusted files then not performing a malware sean of said file, and if the hash value of the file path is not contained in database of trusted files, then proceeding to determine if the file is associated with a valid digital signature and verify that the signature belongs to a trusted source.

The step of determining if the file is associated with a valid digital signature may comprise determining if the file has a valid embedded or attached signature. Then, if the file does not have a valid embedded or attached signature, generating a hash value of the file and determining if the hash value is listed in a catalog having a valid embedded or attached digital signature. The digital signature may rely upon a public key infrastructure.

The step of verifying that the signature belongs to a trusted source may comprise maintaining a database of trusted public keys, identif'ing a public key used to verif' the digital signature, and determining if the public key is contained in the database of trusted public keys. Preferably, the step of maintaining the database of trusted public keys comprises periodically receiving new trusted public keys and adding these to the database.

The step of determining if the file is associated with a valid digital signature comprises using an Application Programming Interface of an operating system of the computer. Preferably, the operating system is a WindowsiM based operating system and said Application Programming Interface is the WinVerifyTrustEx Application Programming Interface.

There is also provided a recording medium storing computer interpretable instructions for causing a programmable computer to perform a malware scanning method, the method being according to the method described above.

In addition, there is provided a computer. The computer comprises a memory storing a database of trusted public keys, and a processor for dctcrmining if a given electronic file is associated with a valid digital signature and, if it is, then vcriing that the signature belongs to a trusted source, and if the signature is verified then not performing a malware scan of said file, and if the signature cannot be verified as belonging to a trusted source then performing said scan.

According to the present invention there is provided a method of maintaining a database of trusted public keys in a plurality of computer devices for the purpose of eliminating the need to scan trusted files for maiware at the computer devices. The method comprises identi'ing at a network-based service, public keys belonging to a public key infrastructure architecture and which are used to digitally sign electronic files, vcri'ing that these public keys belong to a trusted source, and securely sending the trusted public keys to the devices.

Bricf Description of the Drawings

Figure 1 illustrates schematically a computer suitable for detecting malware; and Figure 2 is a flow diagram illustrating the process of determining which files can be excluded from a malware scan.

Detailed Description

As has already been described, being able to identify files that have been supplied, published or authored by a source that can be considered trustworthy reduces the processing burden when anti-virus software performs malwarc scanning. However, this places a further burden on the provider of the anti-virus applications, as these lists must be kept up-to-date and must identi' as many trusted files as possible in order to be effective. Furthermore, given that there are a very large number of files that could be considered trustworthy, these lists are large such that they can consume a significant amount of memory within a device and, in providing regular updates to the list via a network or Internet connection, can cause an increase in data traffic (which may result in additional costs to an end user, e.g. where the network connection is via a mobile telephone network).

It has been recognised here that a large proportion of those files that can be considered trustworthy are associated with a digital signature of a trusted software provider. This is the case, for example, with certain Microsoft® originating files. The Windows® operating system makes use of an embedded Trust Verification API to confirm the source and integrity of files using the associated digital signature. To be associated with a digital signature, a file can either have its own embedded/attached digital signature or the file can be listed in a catalog file that has itself been signed. Catalog files contain a "fingerprint" for each of a set of files. If the fingerprint for a file can be found in a catalog file, and the catalog file has been signed by a trusted source, then that file could itself be considered trustworthy.

Digital signatures arc used to identiñ' and verify the sender, author or publisher of a file. There are two steps involved in creating a digital signature for the associated file (source file or catalog file). The first step involves creating a hash value from the file.

This hash value is then signed, using the signer's private key. To verify a signature, a hash value must be created from the file in the same way the signature was created, using the same hash function. This hash value is then verified against the signature using the public key of the signer. For a description of digital signatures and public key cryptography see Chapter 2 of Applied Cryptography by Bruce Schneier, 1997.

Of course, the steps described in the preceding paragraph merely confirm that the file is "owned" by the party that possesses the private key corresponding to the used public key. In order to confirm the identity of the owner, and therefore the sender, publisher or author of a signed file, the recipient of a file can make use of a digital certificate. The digital certificate comprises a public key, details of the functionlalgorithm used to generate the hash value, and any important information regarding the identity of the owner of the public key, and a signature generated by a certification authority. The certification authority is a trusted organisation that issues a digital certificate when it has verified the identity of the owner of a public key.

Examples of such certificate authorities are Verisign®, DigiCertTM and Thawte®.

The certificate is often embedded within a signed document or, alternatively, the certificate may be contained in a manifest file supplied with the application or with new software updates.

There will now be described a method of dynamically identifying trusted files that need not be otherwise scamied for malware. The method involves making use of the presence of the digital signatures of a software supplier to confirm, within a device, that a file is from a trustworthy source and that the file has not been tampered with.

Figure 1 illustrates schematically a user device 101 which comprises a memory 102, an operating system 103 and a malware detection unit 104. The memory 102 stores a database of public keys. The public keys in the database are those that have been identified as belonging to a trusted source. As such, if a public key is not found within the database then it is assumed not to belong to a trusted source. The database of public keys will usually be supplied and updated by the provider of the malware detection unit 104. The memory 102 also stores a database of trusted files. This database contains an identifier for those files that have previously been identified as being from a trusted source. The memory 102 also stores any catalog files. The operating system 103, such as Mierosoft®Windows®, provides a trust verification function unit 105.

Prior to scanning a file for malware, the malware detection unit 104 determines whether or not the file is associated with a valid digital signature using the trust verification functions of the operating system 103. If the file is associated with a valid digital signature then the malware detection unit 104 checks the database of trusted keys, stored in the memory 102, to determine whether or not the database

S

contains the public key used to decrypt the digital signature. If the database does contain the public key, then the file is considered to bc from a trusted source and the maiware dctection unit 103 excludes the file from the malware scan. Furthermore, an identifier for the now trusted file is added to a database of trusted file identifiers stored in the memory 102. On subsequent occasions this database can be checked to determine if a file has previously been identificd as from a trusted source. This can bc aehieyed by applying a one-way hash function to thc information relating to thc location of the file (i.e. thc filc path) and adding the resulting hash value to the database of trusted files. On subsequent occasions, the same hash function will be applied to the file path and the resulting hash value compared with the database of trusted files. If the hash value matches a value in the database then the file does not need to be scanned.

Figure 2 is a flow diagram further illustrating the process of dynamically identifying trusted files within a user device 101. The steps performed are as follows: Si. The malware detection unit 104 prepares to scan a file on the device 101. For example, the scan can be a scheduled scan, a scan prompted by the user, or a scan initiated in response to a request to run the file or in response to the receipt of the file S2. The malware detcction unit 104 calculates a cryptographic hash of the file path.

S3. The malware detection unit 104 then checks the database of trusted files stored in the memory 102 to see if the hash value for the file path is present. If the hash value is stored in the database then the process proceeds to step Sb.

S4. If the hash value for the file path is not found in the database then the malware detection unit 104 makes a call to the trust verification function unit 105 of the operating system 103, using the WinVeri'TrustEx function to veri that the file has a valid embedded/attached digital signature. If the file is found to have a valid embedded/attached digital signature then the process proceeds to step S8.

S5. If the file is found not to have an embedded/attached digital signature then the malware detection unit 104 makes another call to the trust verification function unit 105 of the operating system 103, using the CryptCATAclminCalcHashFromFileHandle function to calculate a cryptographic hash of the file.

56. The maiware detection unit 104 then makes a further call to the trust verification function unit 105 of the operating system 103, using the CryptCATAdm in EnumCatalog-FromFlash function, to check the catalog files stored in thc memory 102 to see if they contain the hash value of the file. If the hash value of the file is not found within one of the catalog files then the process proceeds to step Si 1.

57. If the hash value for the file is found within one of the catalogs then the malware detection unit 1 04 makes use of the CryptCATCataloglnfo-FromContext function of the trust verification function unit 105 to retrieve the catalog information and uses the WinVerif'TrustEx function to verify that the digital signature of the catalog is valid. If the catalog does not have a valid signature then the process proceeds to step SI 1.

S8. If a file has been identified as being associated with a valid digital signature, either by way of an embedded/attached digital signature or by having the files hash value listed in a catalog file that itself has a valid digital signature, then the malware detection unit 104 retrieves the public key from the associated digital certificate. As previously described, the digital certificate is often embedded within a signed file such that the certificate, and therefore the public key, can be extracted from the file itself Alternatively, the digital certificate may be found in an associated manifest file. The malware detection unit 104 checks the public key against the database of public keys stored in the memory 102. If the public key is not found within the database then it does not belong to a trusted source and the process proceeds to step 511.

59. If the public key used to decrypt the signature matches one of the public keys in the database, then the hash value of the file path (calculated in step S2) is added to the database of trusted files stored in the memory 102. On subsequent occasions the hash value of this file path will then be found during step S3, when the database of trusted files is checked. The process proceeds to step 510 Si 0. If any of the previous steps have determined that the file is from a trusted source then the file is excluded from the malware scan.

811. If the file, or a catalog listing the file, does not have a valid digital signature, or the public key used for the signature is not that of a trusted source, then the file will be scanned for malware using for example conventional scanning techniques based on maiware signatures and heuristics.

The method dcscribed above makes use of; i.e. "piggybacks" on, a trust verification function unit within the operating system, such as the Trust Verification API provided by the Microsoft® Windows®. However, this is a non-limiting example and the Irust verification function unit, or equivalent thnctionality, may equally be provided in an alternative operating systems or its installation packages, or in the malware detection unit.

The use of a trusted file database (see steps S2, S3 and S9) is optional. However, use of such a database may improve the performance of the process by eliminating the need for checking the file or an associated catalog file for a valid and trusted digital signature.

The database of trusted public keys could be provided and/or updated by uploads fixm a web server accessed over the Internet and operated by the provider of the maiware detection software, or directly from the certification authorities. Updates may be received by any transmission method but may also be provided in the form of a memory card or other storage device that can be accessed by a reader that is part of, or is connected to the device. The database of trusted public keys would itself need to be secured against modification, such that its source and integrity could be verified. For example, the database of public keys and any updates to this database could be signed by the provider of the anti-virus software. This signature could then be verified by means of a digital certificate. Alternatively, the user of a device or the administrator of a network could choose to Irust a particular sender, publisher or author and add their public key to the database when prompted or when a valid digital certificate, signed by a trusted certificate authority, is received or loaded into the device.

The method described provides that trusted files can be identified dynamically within an individual device, removing the burden placed on the anti-virus provider to maintain and update a trusted file list. The anti-virus provider will then only be required to supply and maintain a database of public keys belonging to trusted sources. This database of public keys consumes significantly less memory than a list of trusted files and requires significantly less effort to build and maintain. The method also provides that the device does not nccd to store a list containing a large number of hash values for trusted files that are not actually on thc device, reducing the memory consumed by such a list and reducing the data traffic that would otherwise be required if the anti-virus software provider were to provide regular updates to the list via a network or internct connection. Furthcrmore, dynamically identifying trustcd filcs within a device would, in most cases, ensure that a largcr proportion of the trustworthy files present on a device are identified. This further reduces the processing burden by minimising the number of files that require a full maiware scan.

It will be appreciated by the person of skill in the art that various modifications may be made to the above described embodiments without departing from the scope of the prcscnt invention.

Claims

<claim-text>Claims 1. A method of maintaining a database of trusted public keys in a plurality of computer devices for the purpose of eliminating the need to scan trusted files for maiware at the computcr devices, the method comprising: idcntifying at a network bascd service, public keys bclonging to a public key infrastructure architecture and which are used to digitally sign electronic files; verifying that these public keys belong to a trusted source; and securely sending the trusted public keys to the devices.AMENDMENTS TO THE CLAIMS HAVE BEEN FILED AS FOLLOWS: Claims 1. A method of maintaining a database of trusted public keys in a plurality of computer devices in communication with a network based server, the method comprising, at one of the plurality of computer devices: receiving, over a secure connection from the network based server, one or more public keys which have been verified to belong to a trusted source, storing each of the one or more public keys in a database of trusted keys in a memoiy of the computer device; at the computer device generating a hash value of a received file which is verified as having a valid embedded or attached digital signature; storing the hash value for the received file in a database of hash va'ues for files stored in a memory of the computer device.</claim-text> <claim-text>O
2. The method of maintaining a database of trusted pubfic keys in a plurality of Q) computer devices according to claim 1 wherein the computer device verifies the received file by, for a given electronic file, determining if the file has a valid embedded or attached digital signature; and if it is, then verifying that the signature belongs to a trusted source by comparing the key to the public keys stored in the database of trusted keys in the memory.</claim-text> <claim-text>3. A network-based infrastructure comprising: a plurality of computer devices and a network-based server in communication with each of the plurality of computer devices wherein: each computer device comprises: an input to receive, over a secure connection from the network based server, one or more public keys which have been verified to belong to a trusted source, a memory configured to store each of the one or more public keys in a 31 775922-2-cborton database of trusted keys; a processor configured to generate a hash value of a received file which is verified as having a valid embedded or attached digital signature and cause the hash value for the received file to be stored in a database of hash values for files stored in the memory.and the network-based server comprising: a memory including a database of public keys belonging to trusted sources; and m output to transmit, over a secure connection, one or more public keys which have been verified to belong to a trusted source.</claim-text> <claim-text>4. The network-based infrastructure according to claim 3 wherein the processor r of the computer device is configured to verify the received file by, for a given electronic file, determining if the file has a valid embedded or attached digital C signature; and if it is, then verifying that the signature belongs to a trusted source by 0) comparing the key to the public keys stored in the database of trusted keys in the memory.31 775922-2-cborton</claim-text>