RU2571382C1 - System and method for antivirus scanning depending on certificate trust level - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: method for antivirus scanning depending on the certificate trust level of a public key of the digital signature of a file, comprising obtaining an end certificate identifier; drawing up a chain of certificates from the end certificate, determined by the obtained certificate identifier, to the root certificate; determining, using a database of trusted certificates and depending on the chain of certificates, the trust level for the end certificate; performing antivirus scanning of the file depending on the trust level of the end certificate and scanning rules.

EFFECT: high efficiency of antivirus scanning through antivirus scanning whose process depends on a certificate trust level determined using a database of trusted certificates.

18 cl, 6 dwg, 1 tbl

Description

Technical field

The invention relates to the field of data integrity protection using checksums, certificates and digital signatures, in particular to anti-virus verification systems, depending on the level of trust of the certificate.

State of the art

Currently, to verify the integrity of files, software manufacturers (software) use a cryptosystem with a public key. The file is signed with an electronic digital signature (EDS) of the software manufacturer. Together with the file, the EDS and the public key certificate are saved, confirming that the public key belongs to the software manufacturer. Knowing the public key of a trusted CA, the authenticity of the digital signature of the file can be easily verified.

The certificate has a limited validity period, after which the certificate must be replaced. Verification of the validity of public key certificates for electronic digital signature of files is widely used by antivirus applications as one of the preliminary checks to identify files that have an invalid digital signature or revoked certificates.

According to the cryptographic standard X.509, the certificate includes in particular the following fields:

- the serial number used to identify the certificate;

- the entity representing the party to which the certificate was issued;

- electronic digital signature algorithm;

- electronic digital signature;

- publisher of the certificate;

- certificate validity period;

- public key of digital signature;

- hash of the public key;

- public key hashing algorithm.

However, if the secret key of the software manufacturer has been compromised, the CA will revoke the public key certificate. Often, files are not signed directly by a trusted CA, but through a chain of several certification authorities. When a key of one of the CA chains is compromised, the certificates signed by this key from the moment of its compromise are also subject to revocation. This circumstance is also taken into account during anti-virus scanning - files with revoked certificates may be executed with restrictions or may be completely blocked.

Nevertheless, such a system has several disadvantages when used by antivirus applications. For example, if a rootkit is installed on the computer (a malicious program designed to hide its presence in the system by intercepting system functions or spoofing system libraries), it may issue discredited certificates as trusted or vice versa. In addition, a malicious application can install a fake root certificate, as a result, digital signature authentication built into the operating system (OS) will not be able to determine the compromised certificate. Integrated digital signature authentication can often be quite slow due to the need to periodically download from the network a list of revoked certificates and a list of trusted certificates (in some cases, downloading can take several tens of seconds, which is not permissible for antivirus verification of a file).

To solve the problem of certificate verification in antiviruses, US 8,499,150 B1 describes a method for generating a database of trusted certificates and a method for verifying certificates against a generated database. If the certificate was compromised after signing the file, such a file will still be considered trusted. The main functionality for certificate verification is implemented on the server side, however, part of the functionality can be transferred to the client side.

US 7444509 B2 describes a system in which certificate verification in some cases is performed by forwarding a request to a remote server. Thus, initially the certificate is verified using local databases, then, if there is no record for this certificate, the request can be sent for verification to a remote server containing a large database. The patent also describes the possibility of storing the entire chain of certificates from the intermediate to the root certificate in the cache.

US Pat. No. 6,215,872 B1 describes the formation of a list of trusted certificates using an end-user community.

Analysis of the prior art allows us to conclude about the inefficiency and in some cases the impossibility of using previous technologies, the disadvantages of which are solved by the present invention, namely, a system and method of anti-virus scanning depending on the level of trust of the certificate.

Disclosure of invention

The present invention relates to systems and methods for protecting data integrity using checksums, certificates, and digital signatures.

The technical result of the present invention is to increase the performance of anti-virus scanning by anti-virus scanning, the execution process of which depends on the level of trust of the certificate, determined using the database of trusted certificates.

According to an embodiment, a method for changing the functionality of the application is used, in which: using the verification tool, an identifier of the final certificate is obtained; using the verification tool, they build a chain of certificates from the final certificate defined by the received certificate identifier to the root certificate; using the means of setting the level of trust, they determine, with the help of a database of trusted certificates, and depending on the chain of certificates, the level of trust for the final certificate; using the application, an anti-virus scan of the file is performed depending on the level of trust of the final certificate, as well as on the verification rules.

According to one particular embodiment, the certificate identifier is one of the parameters: serial number; public key hash amount from the public key of the certificate; name of the subject and publisher of the certificate.

According to another particular embodiment, the level of trust takes one of the following values: high, meaning that the file is safe, no additional anti-virus scan is performed; medium, which means that an anti-virus scan of the file will be performed; low, which means that the digital signature of the certificate holder is invalid, an additional anti-virus check of the file will be carried out.

According to yet another particular embodiment, the level of trust of the final certificate corresponds to the level of trust of said final certificate in the database of trusted certificates.

According to one particular embodiment, the intermediate certificates of the certificate chain are sequentially checked using the trusted certificate database when the final certificate is not in the trusted certificate database.

In another particular embodiment, a low level of trust is determined for an end certificate when at least one of the intermediate certificates is contained in a low level trust certificate database.

According to another private embodiment, a low level of trust is determined for the final certificate when all certificates in the certificate chain are not in the trust certificate database.

According to one particular embodiment, the final level of trust is determined for the final certificate when the following conditions are met: at least one certificate from the certificate chain is contained in the trust certificate database; The certificate chain does not contain certificates with a low level of trust.

According to another particular embodiment, the rules include at least the following: when the final certificate has a high level of trust, the file is considered legitimate and no further anti-virus scan is required; when the final certificate has an average level of trust, an additional antivirus scan of the file will be checked; when the final certificate has a low level of trust, one of the following actions will be performed: the most thorough additional anti-virus scan of the file has been performed; file launch will be blocked.

According to another particular embodiment, an additional anti-virus scan of the file is carried out using the application, depending on the contents of the certificate fields.

According to one particular embodiment, the application sends the final certificate to the verification tool to perform additional verification of the final certificate when the final certificate is not in the trust certificate database.

According to an embodiment, an anti-virus scan system is used, depending on the level of trust of the certificate, comprising: a scan tool designed to obtain the identifier of the final certificate; verification tool designed to build a chain of certificates from the final certificate defined by the received certificate identifier to the root certificate; trust level setting tool for determining the trust level for the final certificate using a database of trusted certificates and depending on the certificate chain; An application designed to conduct anti-virus scan of a file depending on the level of trust of the final certificate, as well as on the verification rules.

According to one particular embodiment, the certificate identifier is one of the parameters: serial number; public key hash amount from the public key of the certificate; name of the subject and publisher of the certificate.

According to another particular embodiment, the level of trust takes one of the following values: high, meaning that the file is safe, no additional anti-virus scan is performed; medium, which means that an anti-virus scan of the file will be performed; low, meaning that the digital signature of the certificate holder is invalid, one of the following actions will be performed: the most thorough additional anti-virus scan of the file is carried out taking into account that the file was not signed by the EDS of the certificate holder; file launch will be blocked.

According to yet another particular embodiment, the level of trust of the final certificate corresponds to the level of trust of said final certificate in the database of trusted certificates.

According to one particular embodiment, the verification tool is for sequentially verifying intermediate certificates of a certificate chain using a trusted certificate database when the final certificate is not in the trusted certificate database.

According to another particular embodiment, the trust level setting means is further adapted to determine a low level of trust for the final certificate when at least one of the intermediate certificates is contained in the low trust certificate database.

According to yet another particular embodiment, the trust level setting means is further intended to determine the average level of trust for the final certificate when all certificates in the certificate chain are not in the trust certificate database.

According to one particular embodiment, the trust level setting tool is further intended to determine the average level of trust for the final certificate when the following conditions are met: at least one certificate from the certificate chain is contained in the trust certificate database; The certificate chain does not contain certificates with a low level of trust.

According to another particular embodiment, the rules include at least the following: when the final certificate has a high level of trust, the file is considered legitimate and no further anti-virus scan is required; when the final certificate has an average level of trust, an additional antivirus scan of the file will be checked; when the final certificate has a low level of trust, one of the following actions will be performed: the most thorough additional anti-virus scan of the file is carried out taking into account that the file was not signed by the EDS of the certificate holder; file launch will be blocked.

According to another particular embodiment, the application is intended for additional anti-virus scanning of a file depending on the contents of the certificate fields.

According to one particular implementation, the application is further intended to be sent to the certificate of verification of the final certificate to perform additional verification of the final certificate when the final certificate is not in the database of trusted certificates.

Brief Description of the Drawings

Additional objectives, features and advantages of the present invention will be apparent from reading the following description of an embodiment of the invention with reference to the accompanying drawings, in which:

In FIG. 1 shows a general diagram of a digital signature verification system.

In FIG. 2 presents a method of forming and updating the database.

In FIG. Figure 3 shows an anti-virus scan method, depending on the level of certificate trust.

In FIG. Figure 4 shows how to bypass the certificate chain.

In FIG. Figure 5 shows a possible example of a certificate chain bypass.

FIG. 6 is an example of a general purpose computer system.

Description of Embodiments

The objects and features of the present invention, methods for achieving these objects and features will become apparent by reference to exemplary embodiments. However, the present invention is not limited to the exemplary embodiments disclosed below, it can be embodied in various forms. The essence described in the description is nothing more than the specific details provided to assist the specialist in the field of technology in a comprehensive understanding of the invention, and the present invention is defined in the scope of the attached claims.

In FIG. 1 shows a general diagram of a digital signature verification system. The system comprises a user’s computer device 110 (hereinafter referred to as a computer for illustration purposes) with the application 101 installed. The computer 110 can be, for example, a personal computer (PC), laptop, tablet, smartphone, etc. In a preferred embodiment, the application 101 is an antivirus. During the anti-virus scan of the file, the validity of the public key certificate of the digital signature of the file will also be checked. A certificate is considered valid if the following conditions are met:

- the digital signature of the certification center is correct;

- the validity period of the certificate is not expired;

- The certificate has not been revoked.

The system also includes a server 120 connected to a computer 110 via a computer network. The system includes a verification tool 103 associated with the application 101 and designed to obtain the final certificate from the application 101 when performing certificate verification. The final certificate is the public key certificate of the software manufacturer, whose digital signature was signed by the file. The tool for setting the level of trust 104 is associated with the means of verification 103 and is used to determine the level of trust for certificates using the database of trusted certificates 105 (for illustrative purposes, hereinafter referred to as database 105). The level of trust in the system under consideration acts as a parameter (for example, integer) that determines the validity of the certificate and is used during anti-virus scanning. Database 105 is associated with a tool for setting the level of trust 104 and contains certificates, as well as their corresponding levels of trust and identifiers, by which each certificate can be uniquely determined. A certificate identifier can be, for example, a serial number, a public key, a hash from the public key of a certificate, the name of the subject and publisher, etc. In a particular embodiment, the system also includes a local database 105a associated with the database 105. In a particular embodiment a complete or partial list of certificates with trust levels is periodically transferred from the database 105 to the local database 105a.

The tool for setting the level of trust 104 is also necessary to replenish the database 105 with certificates of received files and their corresponding levels of trust.

The verification tool 103 also serves to build a chain of certificates from the end certificate to the root certificate. The certificate chain consists of many certificates required for certification of the software manufacturer, identified by the final certificate. Typically, a certificate chain contains an end certificate, many intermediate certificates, and a root certificate — a certificate of the root certification authority that is trusted by all certification authorities in the certificate chain. Each intermediate CA in the chain contains a certificate issued by a certification authority located one level higher in the chain. At the same time, the root certificate was issued by its own certification authority, which is also called the root certificate (i.e., it is a self-signed certificate). In addition, the verification tool 103 is used to determine one of:

- the first certificate from the certificate chain contained in the database 105;

- The final certificate in the certificate chain.

In a private embodiment, the system includes a database of malicious files 106. The database of malicious files 106 for each malicious file may contain a hash, an EDS public key certificate and its identifier, the status of the malicious file (for example, virus, rootkit, worm, trojan), the original file, etc.

In a particular embodiment, application 101 and file 102 are located on computer 110, and tools 103-106 are located on server 120. In another example implementation, database 105 may be located on computer 110.

In FIG. 2, a method for generating and updating the database 105 is presented. When an unknown file 102 is launched on the computer 110, the application 101 determines the public key certificate of the digital signature of the file and sends the identifier of the certificate and file (for example, the hash sum from the file) to the server 120 to the verification tool 103. Appendix 101 can be installed on a variety of computer devices of various users — thus, certificate identifiers from a plurality of unknown files are received on server 120. Using database 105, a certificate can be uniquely identified by the identifier obtained. In a particular embodiment, if the certificate determined by the identifier was not found in the database 105, the verification tool 103 may request an unknown file from the application 101. In another embodiment, an unknown file may be obtained by the verification tool 103 from the software manufacturer.

In a particular embodiment, the verification server 103 periodically (for example, once a day) ranks the certificates by the number of users from whom the identifier of the corresponding certificate was received. At step 201, the verifier 103 selects from the ranked list a certain number of the most popular certificates (for example, the first ten certificates). In another embodiment, the verification tool 103 verifies all certificates whose identifiers were received from users.

At step 202, the validity of the certificates from the list selected in the previous step is verified. Based on the definition, the validity of the certificate is determined by checking the following conditions:

- the digital signature of the certification center is correct;

- the validity of the certificate at the current time is not expired;

- The certificate has not been revoked.

In addition, the certificate may be invalid for the following reasons:

- one of the certificates in the certificate chain has expired;

- the validity period of the certificate chain certificates may not overlap;

- the certificate chain is looped - one of the certificate chain certificates is issued by the CA certified by the CA of the certificate being verified.

It is worth noting that the verification of the validity of the certificate is not limited to the above conditions, but may include other conditions listed, for example, in the X.509 standard.

Validation of an electronic signature in a particular embodiment can be carried out by system tools (in Windows, for example, using the Sign Tool program). In another embodiment, the verification of the electronic signature can be carried out by decrypting it with the public key contained in the public key certificate of the given electronic signature and then comparing the obtained value of the hash function from the file with the calculated value of the hash function from the file.

At step 203, the trust level setting tool 104 sets the average trust level for certificates whose identifiers have been obtained from users and are valid. The remaining invalid certificates, the identifiers of which were obtained from users, are assigned a low level of trust. In a private implementation, the remaining certificates can be analyzed manually on the server side.

In a particular example of implementation, the level of trust can take the following values: low, medium, high. A low level of trust may mean that the digital signature of the owner is invalid and additional anti-virus scanning of the file is required (for example, using more complex and resource-intensive algorithms compared to conventional anti-virus scanning). A medium level of trust may mean that a routine anti-virus scan will be performed. A high level of trust, on the contrary, means that the file is safe and no additional anti-virus checks are required.

Next, the verification tool 103 obtains a list of malicious files and their certificates from the malware file database 106. At step 204, a low level of trust is set for the electronic public key signature certificates of the digital signature to which the malicious files were signed. At step 205, a high level of trust is set for certificates for which the certification authority is contained in the list of trusted certification authorities. In a particular embodiment, trusted certification authorities may be CAs of the largest manufacturers of software (software). In another particular embodiment, the list of trusted certification authorities may be pre-generated by server 120.

In a particular embodiment, in step 204, a low level of trust can be set for intermediate certificates that occur in the certificate chains of a certain number of malicious files. For example, if an intermediate certificate was present in ten certificate chains, and six files signed by the final certificates of these chains were malicious, then the intermediate certificate under consideration will be assigned a low level of trust. At the same time, if there are two malicious files, for example, an intermediate level of trust can be assigned to an intermediate certificate, because there is no sufficient reason to believe that the intermediate certificate has been discredited.

As a result, at step 206, the tool for setting the level of trust 104 adds (if the database has only been created and, accordingly, is empty) or replenishes the database with 105 certificates of received files and the corresponding levels of trust.

In FIG. Figure 3 shows a method of anti-virus scanning of a file using information about the certificate trust level. At the first step 301, the verification tool 103 obtains the identifier of the final certificate of the public key of the digital signature of the file verified by the application 101. Next, at step 302, the verification tool 103 builds a chain of certificates from the final certificate to the root certificate. Using database 105, a certificate can be uniquely identified by the identifier obtained. The construction of the chain of certificates occurs in a manner known from the prior art. The final CA determines the first CA that issued the certificate. For the certificate of the first CA, the second CA is determined, which issued the certificate of the first CA and so on, until the root CA is determined.

At step 303, the verification tool 103 sequentially bypasses the certificate chain, sequentially searching for each certificate from the chain in the database 105. The trust level of the final certificate will be updated depending on the result of the certificate chain bypass. A method of bypassing the certificate chain will be discussed below, with the description of FIG. four.

As a result, in step 304, the trust level for the final certificate is determined using the database 105. As a result, at step 305, application 101 on computer 110 performs an anti-virus scan of file 102, depending on the level of trust of the final certificate. This dependence is determined by the verification rules, which will be described below, in table 1. In a particular embodiment, the anti-virus scan method depends on the contents of the certificate fields, such as, for example: expiration date, country of issue of the certificate, etc.

In FIG. Figure 4 shows how to bypass the certificate chain. Certificate verification is performed sequentially, starting from the final certificate and ending with the root certificate. At step 410, a check is made to see if the final certificate is contained in the database 105. If the certificate is contained in the database 105, no further traversal of the certificate chain is required.

Otherwise, at step 420, the crawl continues from the next certificate in the chain until at step 430 it is determined that the intermediate certificate in question is contained in the database 105 with a low level of trust (step 431), or until the root is reached certificate (steps 440-441). However, if the intermediate certificate is contained in the database 105 with a high or medium level of trust, the chain will continue to bypass.

If the intermediate certificate is contained in the database 105 and has a low level of trust, the final certificate will also be assigned a low level of trust. This step allows you to identify a malicious file when one of the intermediate certificates of the certificate chain has a low level of trust, even if for some reason (for example, the intermediate certificate was revoked due to the compromise of the CA, while the parent CAs were not compromised) other certificates certificate chains have a medium or high level of trust.

If a root certificate has been reached and at least one of the intermediate certificates is contained in the database 105 with an average or high level of trust, the final certificate of the file will be assigned an average level of trust.

In addition, at step 441, it is checked whether intermediate certificates with a high level of trust were present in the certificate chain. If so, the final certificate will also be assigned a high level of trust.

The last possible result of bypassing the certificate chain: none of the certificates in the chain were contained in the database 105. In this case, the final certificate may be assigned a low level of trust. In addition, in a particular embodiment, the identifier of the final certificate may be sent to the verification tool 103, which will analyze the certificate in accordance with the method shown in FIG. 2. In another embodiment, a file identifier (eg, a hash sum) may also be sent to the verification tool 103.

Table 1 below shows an example of the verification rules, in accordance with which the anti-virus scan is performed after the end of the certificate chain bypass.

Table 1 No. End Certificate Trust Level The rule one Tall The file is considered trusted; no further anti-virus scan is required 2 Average An additional anti-virus scan is required. 3 Low A more thorough additional antivirus scan of the file is necessary.

For example, according to the first rule, if in FIG. In method 4, a certificate was found, which is the final certificate with a high level of trust, the file is considered legitimate and no further anti-virus scan is required. According to the second rule, an additional anti-virus scan will be carried out. Such a check can be, for example, heuristic algorithms, the use of cloud services, emulation, etc.

According to the third rule of Table 1, an additional anti-virus check will be carried out taking into account that the file was not digitally signed by the owner or the digital signature is not correct. In this case, the most thorough anti-virus scan or a set of checks will be carried out, which will most likely identify malicious files. For example, more resource-intensive heuristic algorithms, behavioral algorithms, etc. can be used. In a particular embodiment, if the certificate has a low level of trust, it can be blocked by application 101 at startup.

In FIG. 5 shows a possible example of a certificate chain bypass according to the method shown in FIG. 4. In this example, the file is signed with the final certificate 501. The certificate chain consists of certificates 501-506. Those. final certificate 501 was signed by CA 4, certificate 502 of which was signed by CA 3, etc.

The verification tool 103, in step 410, sequentially bypasses the certificates from the certificate chain, starting with the root certificate. The first certificate that is present in database 105 is certificate 502, which, according to database 105, has a high level of trust. Because it is not a root certificate, according to the method shown in FIG. 4, the certificate chain certificate bypass continues (step 440). Certificate 503 is not in database 105. The next certificate 504 is in a database with a low level of trust. Despite the fact that there are still two unverified certificates in the certificate chain, then there is no need to continue the bypass (step 431), because a discredited intermediate certificate 504 was found. According to rule 3 of table 1, the most thorough additional anti-virus scan of the file is necessary.

FIG. 6 is an example of a general purpose computer system, a personal computer or server 20 comprising a central processor 21, a system memory 22, and a system bus 23 that contains various system components, including memory associated with the central processor 21. The system bus 23 is implemented as any prior art bus structure comprising, in turn, a bus memory or a bus memory controller, a peripheral bus and a local bus that is capable of interacting with any other bus architecture. The system memory contains read-only memory (ROM) 24, random access memory (RAM) 25. The main input / output system (BIOS) 26, contains basic procedures that ensure the transfer of information between the elements of the personal computer 20, for example, at the time of loading the operating ROM systems 24.

The personal computer 20 in turn contains a hard disk 27 for reading and writing data, a magnetic disk drive 28 for reading and writing to removable magnetic disks 29, and an optical drive 30 for reading and writing to removable optical disks 31, such as a CD-ROM, DVD -ROM and other optical information carriers. The hard disk 27, the magnetic disk drive 28, the optical drive 30 are connected to the system bus 23 through the interface of the hard disk 32, the interface of the magnetic disks 33 and the interface of the optical drive 34, respectively. Drives and associated computer storage media are non-volatile means of storing computer instructions, data structures, software modules and other data of a personal computer 20.

The present description discloses an implementation of a system that uses a hard disk 27, a removable magnetic disk 29, and a removable optical disk 31, but it should be understood that other types of computer storage media 56 that can store data in a form readable by a computer (solid state drives, flash memory cards, digital disks, random access memory (RAM), etc.) that are connected to the system bus 23 through the controller 55.

Computer 20 has a file system 36 where the recorded operating system 35 is stored, as well as additional software applications 37, other program modules 38, and program data 39. The user is able to enter commands and information into personal computer 20 via input devices (keyboard 40, keypad “ the mouse "42). Other input devices (not displayed) can be used: microphone, joystick, game console, scanner, etc. Such input devices are, as usual, connected to the computer system 20 via a serial port 46, which in turn is connected to the system bus, but can be connected in another way, for example, using a parallel port, a game port, or a universal serial bus (USB). A monitor 47 or other type of display device is also connected to the system bus 23 via an interface such as a video adapter 48. In addition to the monitor 47, the personal computer may be equipped with other peripheral output devices (not displayed), such as speakers, a printer, and the like.

The personal computer 20 is capable of operating in a networked environment, using a network connection with another or more remote computers 49. The remote computer (or computers) 49 are the same personal computers or servers that have most or all of the elements mentioned earlier in the description of the creature the personal computer 20 of FIG. 6. Other devices, such as routers, network stations, peer-to-peer devices, or other network nodes may also be present on the computer network.

Network connections can form a local area network (LAN) 50 and a wide area network (WAN). Such networks are used in corporate computer networks, internal networks of companies and, as a rule, have access to the Internet. In LAN or WAN networks, the personal computer 20 is connected to the local area network 50 via a network adapter or network interface 51. When using the networks, the personal computer 20 may use a modem 54 or other means of providing communication with a global computer network such as the Internet. The modem 54, which is an internal or external device, is connected to the system bus 23 via the serial port 46. It should be clarified that the network connections are only exemplary and are not required to display the exact network configuration, i.e. in reality, there are other ways to establish a technical connection between one computer and another.

In accordance with the description, components, execution steps, data structure described above can be performed using various types of operating systems, computer platforms, programs.

In conclusion, it should be noted that the information provided in the description are examples that do not limit the scope of the present invention defined by the claims.

Claims (18)

1. Method of anti-virus scan, depending on the level of trust of the certificate of the public key of a digital signature of the file, in which:
a) using the verification tool receive the identifier of the final certificate;
b) using the verification tool, they build a chain of certificates from the final certificate defined by the received certificate identifier to the root certificate;
c) using the means of setting the level of trust, determine the level of trust for the final certificate using a database of trusted certificates and, depending on the chain of certificates, in this case:
- use the level of trust from the trust certificate database if it is present in said trust certificate database for said final certificate;
- sequentially check the intermediate certificates of the certificate chain using the trust certificate database when the final certificate is not in the trust certificate database;
d) using the application, an anti-virus scan of the file is carried out depending on the level of trust of the final certificate, as well as on the verification rules. 2. The method according to claim 1, wherein the certificate identifier is one of the parameters:
- serial number;
- public key;
- the hash amount from the public key of the certificate;
- name of the subject and publisher of the certificate. 3. The method according to p. 1, in which the level of trust takes one of the values:
- high, meaning that the file is safe, additional anti-virus scanning is not performed, while additional anti-virus scanning includes at least one of:
- heuristic algorithms;
- cloud services;
- emulations;
- medium, which means that an anti-virus scan of the file will be performed;
- low, which means that the digital signature of the certificate holder is invalid, an additional anti-virus check of the file will be carried out. 4. The method of claim 3, wherein the verification rules include at least the following:
- when the final certificate has a high level of trust, the file is considered legitimate and further anti-virus scanning is not required;
- when the final certificate has an average level of trust, an additional anti-virus scan of the file will be carried out;
- when the final certificate has a low level of trust, one of the following actions will be performed:
- conducted an additional anti-virus file scan;
- the launch of the file will be blocked. 5. The method according to claim 1, wherein a low level of trust is determined for the final certificate when at least one of the intermediate certificates is contained in the database of trusted certificates with a low level of trust. 6. The method according to claim 1, wherein a low level of trust is determined for the final certificate when all certificates in the certificate chain are not in the trust certificate database. 7. The method according to p. 1, in which for the final certificate determine the average level of trust when the following conditions are true:
- at least one certificate from the certificate chain is contained in the trust certificate database;
- There are no certificates with a low level of trust in the certificate chain. 8. The method according to p. 1, in which, at step d) using the application, an additional anti-virus scan of the file is performed depending on the contents of the certificate fields. 9. The method of claim 1, wherein the application sends the final certificate to the verification tool to perform additional verification of the final certificate when the final certificate is not in the trust certificate database. 10. The anti-virus scan system, depending on the level of trust of the certificate of the public key of the digital signature of the file, containing:
a) a means of verification intended for:
- obtaining the identifier of the final certificate;
- building a chain of certificates from the final certificate, determined by the received certificate identifier, to the root certificate;
- sequential verification of intermediate certificates of the certificate chain using the trust certificate database when the final certificate is not in the trust certificate database;
b) means for setting the level of trust, intended to determine the level of trust for the final certificate using the database of trusted certificates, and the level of trust from the database of trusted certificates is used if it is present in the said trust database for the said final certificate;
c) an application designed for anti-virus scanning of a file depending on the level of trust of the final certificate, as well as on the verification rules. 11. The system of claim 10, wherein the certificate identifier is one of the parameters:
- serial number;
- public key;
- the hash amount from the public key of the certificate;
- name of the subject and publisher of the certificate. 12. The system of claim. 10, in which the level of trust takes one of the values:
- high, meaning that the file is safe, additional anti-virus scanning is not performed, while additional anti-virus scanning includes at least one of:
- heuristic algorithms;
- cloud services;
- emulations;
- medium, which means that an anti-virus scan of the file will be performed;
- low, meaning that the digital signature of the certificate holder is invalid, one of the following actions will be performed:
- an additional anti-virus scan of the file was carried out taking into account that the file was not signed by the EDS of the certificate holder;
- the launch of the file will be blocked. 13. The system of claim 12, wherein the verification rules include at least the following:
- when the final certificate has a high level of trust, the file is considered legitimate and further anti-virus scanning is not required;
- when the final certificate has an average level of trust, an additional anti-virus scan of the file will be carried out;
- when the final certificate has a low level of trust, one of the following actions will be performed:
- an additional anti-virus scan of the file was carried out taking into account that the file was not signed by the EDS of the certificate holder;
- the launch of the file will be blocked. 14. The system of claim 10, wherein the confidence level setting means is further adapted to determine a low level of trust for the final certificate when at least one of the intermediate certificates is contained in the low level trust certificate database. 15. The system of claim 10, wherein the tool for setting the level of trust is additionally designed to determine the average level of trust for the final certificate when all certificates in the certificate chain are not in the trust certificate database. 16. The system according to p. 10, in which the tool sets the level of trust is additionally designed to determine the average level of trust for the final certificate when the following conditions are true:
- at least one certificate from the certificate chain is contained in the trust certificate database;
- There are no certificates with a low level of trust in the certificate chain. 17. The system of claim 10, wherein the application is designed to conduct additional anti-virus scan of a file depending on the contents of the certificate fields. 18. The system of claim 10, wherein the application is further intended to be sent to the certificate verifier of the final certificate to perform additional verification of the final certificate when the final certificate is not in the database of trusted certificates.

Images