Protecting anti-malware processes

<img file="ES2736673T3_D0001.tif" />

SPANISH OFFICE OF

PATENTS AND TRADEMARKS

SPAIN

<img file="ES2736673T3_D0002.tif" />

© Int. Cl .:

G06F 21/51

G06F 21/57

G06F 21/56

G06F 21/52

H04L 06/29 (2013.01) (2013.01) (2013.01) (2013.01) (2006.01)

TRANSLATION OF EUROPEAN PATENT

T3 © Date of submission and number of the international application: 20.09.2013 PCT / US2013 / 061054 © Date and number of international publication: 04.12.2014 WO14193451 © Date of submission and number of the European application: 20.09.2013 E 13771331 (9 ) © Date and publication number of the European concession: 03.04.2019 EP 3005216 © Title: Protection of anti-malware processes © Priority:

05/31/2013 US 201313907331 © Date of publication and mention in BOPI of the patent translation:

03.01.2020 © Owner / s:

MICROSOFT TECHNOLOGY LICENSING, LLC (100.0%)

One Microsoft Way

Redmond, WA 98052, US © Inventor / es:

PULAPAKA, HARI;

JUDGE, NICHOLAS S .; KISHAN, ARUN U .; SCHWARTZ, JAMES A .; KINSHUMANN, KINSHUMANN; LINSLEY, DAVID J .; MAJMUDAR, NIRAJV. and ANDERSON, SCOTT D.

@ Agent / Representative:

CARPINTERO LÓPEZ, Mario

ES 2 736 673 T3

Notice: Within nine months from the date of publication in the European Patent Bulletin, of the mention of granting the European patent, any person may object to the European Patent Office to the granted patent. The opposition must be in writing and be motivated; It will only be considered as formulated once payment of the opposition fee has been made (art. 99.1 of the Convention on the Grant of European Patents).

ES 2 736 673 T3

DESCRIPTION

Anti-malware process protection

Background

Computer devices have increasingly become repositories of confidential data of corporations and users. This has resulted in an emergence of malicious users trying to gain access to these computing devices. In addition, malicious users often attempt to install programs that track user interactions or use the computing resources of computing devices for malicious purposes.

Consequently, antimalware software has been developed to prevent these malicious users from accessing computer devices. However, malicious users continually try to avoid the protection provided by anti-malware software. These malicious users may try to operate as antimalware software, also known as counterfeit software, interrupt antimalware software, etc. One way that malicious programs gain access to antimalware software is by posing as an administrative user. Since administrative users have broad permissions to interrupt or otherwise alter processes, malicious users posing as administrative users can open a computer device to attack by disabling the protection provided by anti-malware software.

The document Use Windows 8 ELAM to secure the boot process, detect rootkits, Michael Cobb, March 15, 2013, obtained from the Internet URL http://searchsecurity.techtarget.com/answer/Utilize-Windows8-ELAM-to- securethe-boot-process-detect-rootkits? vgnextfmt = print, describes the Early Launch AntiMalware (ELAM), which is the first software driver that is loaded into the Windows 8 operating system (OS). ELAM drivers must pass a set of certification tests to verify performance and other behaviors, after which Microsoft signs them so that the Windows kernel can start them.

Document US2007094496 discloses systems and procedures for managing malicious software on a protected computer. An embodiment is configured to redirect a call to create a process to a core level process monitor, identify a file associated with the process and analyze the file to determine if the file is a malicious software file. If the file is a malicious software file, the process is prevented from being created. In variations, the core level process monitor is a core mode controller adapted to communicate with a malicious software application that resides at a user level of memory.

Summary

Techniques to protect anti-malware processes are described. In one or more implementations, an antimalware process associated with an antimalware driver is verified, at least in part, based on the certificates contained in an antimalware driver. Certificates are registered with an operating system for future use.

In one or more implementations, a computing device comprises one or more processors and one or more modules implemented at least partially in hardware. The module or modules are configured to start an antimalware process. The module or modules also assign the antimalware process to a protection level defined by a signer and a type of protection based, at least in part, on certificates contained in an antimalware controller. The module or modules can also execute the antimalware process on the computing device.

In one or more implementations, one or more computer-readable storage media comprise instructions stored therein which, in response to execution by the computing device, cause the computing device to execute an anti-malware process protection module. The anti-malware process protection module is configured to perform operations that include the verification, during a startup process, of an anti-malware driver associated with an anti-malware program based, at least in part, on the certificates contained in the anti-malware driver, containing the certificates an identity signed with a trusted certificate from a verified source, registering the certificates with the core of an operating system, verifying an antimalware process associated with the antimalware program based, at least in part, on the registered certificates and without taking into account a level of permission associated with the user associated with the antimalware process, assigning a level of protection to the antimalware process based at least partly in the registered certificates, and preventing the user from altering the antimalware process, including altering the termination of the antimalware process, code injection or loading of binary files related to the antimalware process.

In one or more implementations, an antimalware driver is signed and then provided to a computing device.

ES 2 736 673 T3

This Summary is provided to introduce a selection of concepts in a simplified form that are described in more detail below in the detailed description. This Summary is not intended to identify key characteristics or essential characteristics of the claimed object, nor is it intended to be used as an aid in determining the scope of the claimed object.

The invention is defined by the scope of the appended claims.

Brief description of the drawings

The detailed description is described with reference to the attached figures. In the figures, the leftmost digit (s) of a reference number identifies the figure in which the reference number appears for the first time. The use of the same reference numbers in different cases in the description and in the figures may indicate similar or identical elements.

FIG. 1 is an illustration of an example of a computing device that is operable to implement the anti-malware process protection techniques described herein.

FIG. 2 illustrates a hierarchy of protection levels related to anti-malware process protection techniques.

FIG. 3 shows a system in an example implementation to sign an antimalware driver.

FIGS. 4A and 4B represent a procedure in an example implementation to protect anti-malware processes.

FIG. 5 shows a procedure in an example implementation to sign an antimalware driver.

FIG. 6 shows a procedure in an example implementation to provide an anti-malware driver to the computing device.

FIG. 7 illustrates an example system that includes the computing device as described with reference to FIG. one.

FIG. 8 illustrates various components of an example device that can be implemented as any type of computing device as described with reference to FIGS. 1-7 to implement embodiments of the techniques described in this document.

Detailed description

Overview

When malicious users emerged, a relationship developed between operating system manufacturers and anti-malware software manufacturers to protect user data. However, these techniques have to be continuously developed and advanced to address the continued development of malicious techniques that are used to compromise this data. Conventional techniques to protect a computer environment against malicious users and anti-malware programs, for example, may not protect the computer environment from attacks by users who use administrative permissions. Consequently, these malicious users can perform unwanted activities within the computing environment, such as suspending a process.

Accordingly, techniques for verifying an antimalware process and assigning a protection level based on a signature associated with an antimalware controller to the process are described. In this way, the actual code that is being executed is checked, instead of the user permissions associated with a user who initiated the process. For example, it may be more difficult to falsify who signed a part of the code than to falsify a user.

To allow the antimalware process to take advantage of these code checking operations, the operating system manufacturer and the antimalware software manufacturer can reach an agreement with each other regarding what is considered a verified signature for the antimalware driver. The manufacturer of anti-malware software and the manufacturer of the operating system, for example, can participate in a tightly controlled process to generate the verified signature, and therefore, the verified signature cannot be falsified or easily manipulated. In addition, since the manufacturer of the operating system can use verified signatures to protect the processes verified by the operating system through the hierarchy of hierarchical levels of protection, the use of a verified signature to protect the anti-malware software processes gives the processes of anti-malware software a level of protection consistent with the protection given to the operating system itself.

Therefore, the code checking process can protect the anti-malware software process, since the anti-malware software process protects the computer environment of malicious users. In an example usage scenario, an antimalware software process can be initiated by an operating system that has a level of protection reserved for antimalware software processes. The level of protection can be included

EN 2 736 673 T3 within a hierarchy of protection levels associated with other processes, or it may be a reserved protection level that operates outside the hierarchy of protection levels for other processes. By assigning the antimalware software process to a protection level, the antimalware software process can work without having to monitor whether other processes attempt to alter or manipulate the antimalware software process. Therefore, computer resources that would otherwise be used by the anti-malware software process to protect against attacks can be released and used by the computing device for other operations.

In addition, protections to the anti-malware process can be extended to prevent malicious administrative users from terminating or otherwise altering the anti-malware process. The alteration of the antimalware process may include opening an invasive abstract reference in the antimalware process, injecting code into the antimalware process, reading or writing to the memory used by the antimalware process or otherwise accessing the antimalware process.

In addition, malicious administrative users may be of concern, since administrative users are normally allowed to perform operations that are vital to the function of the computing device, such as enabling backups, restoring privileges, appropriating processes, terminating processes and Start processes from the core of the operating system. The techniques described in this document can be used to prevent malicious administrative users from performing these operations against an antimalware process.

When a level of protection is granted to the antimalware process, the computing device can verify that the antimalware process is associated with an antimalware program. For example, an operating system of the computing device can verify the antimalware process by loading a driver associated with the antimalware program. This antimalware driver may contain a signature. The operating system may also have received a verified signature from a reliable source. If the signature contained in the antimalware driver and the verified signature of the trusted source match, the antimalware process is verified as legitimate and granted the level of protection reserved for antimalware processes.

In the following discussion, we first describe an example environment that can employ the anti-malware process protection techniques described in this document. The following describes sample procedures that can be performed in the sample environment, as well as in other environments. Consequently, the performance of the sample procedures is not limited to the sample environment and the sample environment is not limited to the performance of the example procedures.

Sample environment

FIG. 1 is an illustration of an environment 100 in an example implementation that is operable to maintain the anti-malware process protection techniques described herein. The illustrated environment 100 includes a computer device 102 having a computer-readable storage medium that is illustrated as a memory 104 and a processing system 106, although other confirmations are also contemplated as described below.

The computer device 102 can be configured in several ways. For example, the computer device 102 may be configured as a computer that is capable of communicating through a network, such as a desktop computer, an entertainment device, a decoder communicatively coupled to a display device, a game console, etc. The computer device 102 can also be configured as a mobile communications device, such as a laptop as illustrated, a tablet, a mobile phone, a portable game device, a portable music device, an electronic notebook, etc. Therefore, the computing device 102 may range from complete resource devices with substantial memory and processor resources (eg, personal computers, game consoles) to a low resource device with limited memory and / or processing resources (for example, traditional decoders, handheld game consoles) as described in more detail in relation to FIG. 7. In addition, although a single computing device 102 is shown, the computing device 102 may be representative of a plurality of different devices, such as multiple servers used by a company to perform operations such as a web service, a combination of remote control and decoder, an image capture device and a game console configured to capture gestures, etc.

The computer device 102 also includes an operating system. The operating system is configured to abstract the underlying functionality of the computing device 102 to the processes that are executable in the computing device 102. For example, the operating system may abstract the memory 104, the processing system 106, the network and / or the functionality of the display device of the computing device 102, so that applications can be written without knowing how this underlying functionality is implemented. A process, for example, can provide data to the operating system to be represented and displayed by the display device without understanding how this representation can be performed. The operating system can also represent a variety of other functionalities, such as managing a file system and a user interface that is navigable by a user of the computing device.

Memory 104 is illustrated including a process start module 108, a verification module 110 and running processes 112. The process start module 108 is representative of the functionality to start processes

ES 2 736 673 T3 for execution in computer device 102, for example, an antimalware process 114. The antimalware process 114 may have a protection attribute 116, which is the level of protection requested by the antimalware process 114, whose further discussion can be found in relation to FIG. two.

The antimalware process 114 is then passed to the verification module 110, where the protection attribute 116 is used to obtain a level of protection for the antimalware process 114. For example, the verification module 110 may contain an antimalware controller 118 that includes a signature 120 with a fingerprint 122 and, optionally, one or more EKU 124. Verification module 110 may use signature 120, fingerprint 122 and / or EKU 124 to verify that the anti-malware process 114 is eligible to receive the level of protection associated with protection attribute 116. If the antimalware process 114 passes the verification through the verification module 110, the antimalware process 114 can be granted a level of protection associated with the protection attribute 116. Antimalware process 114 can be added to running processes 112.

Alternatively, if the antimalware process 114 does not pass the verification through the verification module 110, the antimalware process may be allowed to run as an unverified antimalware process 128, the antimalware process 114 may be interrupted, etc. An unverified antimalware process 128 does not have an associated level of protection, and therefore is not granted the level of protection associated with protection attribute 116. Therefore, the unverified antimalware process 128 has limited access to the computing device and can be modified by one or more of the running processes 112. Consequently, an unverified antimalware process 128 can be treated as an unprotected application, the further discussion of which can also be found in connection with FIG. two.

Therefore, the environment 100 can take advantage of a tightly controlled agreement process between the operating system manufacturer and the anti-malware software manufacturer to secure the environment 100. This process, specifically the generation of the anti-malware driver, is described in more detail from in relation to FIG. 3.

FIG. 2 illustrates a hierarchy 200 of protection levels 202 associated with anti-malware process protection techniques. These levels 202 of protection are used to indicate which processes can obtain an invasive abstract reference on which other processes. In general, what will be described in more detail below, processes with a level 202 of protection to the left and the top of the illustration can obtain an invasive abstract reference to processes with a level 202 of protection toward the bottom and right of the illustration. Therefore, both the x-axis and the y-axis of permission levels 202 are important. Consequently, the broken lines in FIG. two indicate the different levels 202 of protection, from top to bottom, as described below.

Hierarchy 200 defines the types of protection from the highest to the lowest from left to right, namely protected 204, mild protected 206, and unprotected 208. Within one type of protection, several signers are identified, and the signers that they have a higher level of protection they are located towards the top of the levels 202 of protection. The dashed lines in FIG. two indicate the different levels 202 of protection assigned to the signatories within the same type of protection.

In the protected protection type 204 of FIG. 2, three signers are identified, namely the critical components 210 of the operating system, the components 212 of the operating system and the content 214 DRM hosted. The critical components 210 of the operating system are assigned the highest level of protection in the computing device 102, and generally consist of the core of the operating system plus a set of critical system processes.

Within the type of protection of mild protection 206, four signers are identified, namely the critical components 216 of the operating system, the components 218 of the operating system, the 220 anti-malware services and the signed applications 222 of the virtual store. Within the unprotected protection type 208, a signer is identified, namely unprotected applications 224.

Thus, each combination of type of protection and signer is granted a unique signature level. A variable can be created to store the signature levels, which can have a maximum size of 4 bits in one or more implementations. For example, the protection attribute 116 can be assigned a value associated with the variable, and the anti-malware process 114 can be verified by the verification module 110 and a protection level 202 can be assigned based on the information contained in the anti-malware driver 118, specifically the signature 120, the fingerprint 122 and the EKU 124.

Processes can be verified based on levels of protection 202, rather than the user privileges associated with a user trying to start a process. Therefore, the antimalware process 114, even if initiated by an administrative user, can still be verified by the verification module 110 based on the protection attribute 116 and the information contained in the antimalware controller 118. Similarly, the anti-malware process 114, even if initiated by a user who has backup or restore privileges, can also be verified by the verification module 110.

Several processes can be given a level of protection associated with a type of protection and a signer. For example, the anti-malware process 114 can be granted a level of protection associated with the type of protection

ES 2 736 673 T3 protected mild 206 and with the signer's 220 anti-malware services, if protection attribute 116 is associated with 220 anti-malware services. For a first process to access a second process, the protection level 202 of the first process must be higher than the protection level 202 of the second process. A protection level 202 of a first process is higher than a protection level 202 of a second process when both the type of protection and the signer of the first process are greater than or equal to a type of protection and a signer of the second process.

For example, a process signed by the critical components 210 of the operating system with a level 202 of protection of protection 204 may alter or otherwise access any process in the computer system 102. In addition, a process signed by anti-malware services 220 with level 202 of mild protected protection 206 may alter or otherwise access processes signed by anti-malware services 220, processes signed by applications 222 signed from the virtual store or processes signed by unprotected applications 224. Similarly, a process signed by the hosted 214 DRM content may be limited to modifications or access to processes signed by hosted 214 DRM content or unprotected applications 224, even if the hosted 214 DRM content has a higher type of protection (e.g., protected 204) than a process signed by 220 antimalware services.

Alternatively, a process with a lower level of protection can be granted limited access rights to a process with a higher level of protection. For example, the process of the lowest level of protection can be granted the right to interrupt a process with a higher level of protection. However, the process with the lowest level of protection cannot be granted these limited access rights when the process of the highest level of protection is signed with a particular level of protection. For example, critical components 210 of the operating system, critical components 216 of the operating system and antimalware services 220 may not allow a process with a lower level of protection to have limited access rights, such as termination rights. Therefore, the termination of the verified antimalware process 126 is limited to the processes signed by the critical components 210 of the operating system, by the critical components 216 of the operating system and by the antimalware services 220. This can be used to provide an additional level of protection to the verified 126 anti-malware process.

Depending on the levels of protection 202 described above, there may be situations in which two processes cannot alter each other. For example, a process signed by the hosted 214 DRM content cannot alter a process signed by the antimalware services 220, and a process signed by the antimalware services 220 cannot alter a process signed by the hosted 214 dRm content. Therefore, the processes signed by the antimalware services 220 or by the hosted 214 DRM content are isolated from each other at protection levels 202, which provides greater security.

Alternatively, a protection level 202 may be defined that is not within the hierarchy of protection levels 202, which may be referred to as a reserved protection level. Processes signed with the level of protection reserved can restrict access to processes signed with a higher level of protection. For example, if the signed store 222 applications are assigned a protection level of 8 and the anti-malware services 220 are assigned a protection level 7, the processes typically signed by the anti-malware services 220 could not restrict access from the processes signed by the 222 signed applications of the virtual store. However, if the antimalware services 220 were assigned a reserved level of protection, the processes signed by the antimalware services 220, such as the verified antimalware process 126, could restrict access from the processes signed by the signed applications 222 of the On-line shop.

In addition, the types of protection can be determined based on what type of signature procedure is required for certificates extracted from a controller. For example, protection levels 202 of the protected protection type 204 may require a page fingerprint signature procedure . In addition, levels 202 of the mild protected protection type 206 may require a file fingerprint signature procedure. Therefore, a more secure signature procedure may be required for a process to receive a higher type of protection.

In addition, processes can create child processes. A process that has received a level 202 of protection can create an unprotected child process. The process that has received a level 202 of protection can only pass abstract references to the explicitly unprotected child process through a list of transmitted abstract references. The process that has received a level 202 of protection may not pass all inheritable abstract references to an unprotected child process. Therefore, a process that has received a protection level 202 may not create an unprotected child process that has an abstract reference to a process with a protection level 202.

For example, if the verified antimalware process 126 created a child process that was assigned a protection level of unprotected applications 224, the verified antimalware process 126 is prevented from allowing the child process to have an abstract reference to the antimalware process 126, or on any other process of the processes 112 in execution that has an assigned level of protection 202.

Alternatively, if the verified antimalware process 126 created a child process to which a protection level of unprotected applications 224 was assigned, the verified antimalware process 126 may explicitly pass

EN 2 736 673 T3 individual abstract references to the child process. In the latter situation, the child process receives an abstract reference on a process of the processes in execution that had an assigned level of protection 202.

FIG. 3 shows a system 300 in an example implementation for signing an antimalware driver. An anti-malware software manufacturer 302 and an operating system manufacturer 304 communicate and reach an agreement to produce a verified anti-malware signature 306, such as signature 120. The verified anti-malware signature 306 is sent to an anti-malware service 308. The antimalware service 308 sends an antimalware controller 118 to a computer device 102. The anti-malware driver 118 may be platform independent, so that the anti-malware driver 118 can be used in a variety of different types of computing devices 102.

Sample Procedures

The following discussion describes anti-malware process protection techniques that can be implemented using the systems and devices described above. The aspects of each of the procedures can be implemented in hardware, firmware or software, or in a combination thereof. The procedures are shown as a set of blocks that specify the operations performed by one or more devices and are not necessarily limited to the orders shown to perform the operations by the respective blocks. In parts of the following discussion, reference may be made to environments 100 and 300 of FIGS. 1 and 3, and at protection levels 200 of FIG. 2, respectively.

FIGS. 4A and 4B represent a procedure 400 to verify that an antimalware process can run at a specific level of protection. For example, the anti-malware process 114 that seeks a level 202 of protection associated with the protection attribute 116 may be verified by the verification module 110, which uses the anti-malware driver 118.

A computing device receives a certificate of trust from a verified source (block 402). The trust certificate may include an identity associated with the certificate, which indicates the verified source. The verified source may be, for example, a manufacturer 302 of anti-malware software. Alternatively, the verified source may be, for example, the antimalware driver 118. The antimalware driver may be a verified source since the antimalware driver 118 contains the verified antimalware signature 306. The verified 306 antimalware signature is trusted because it comes from the 302 manufacturer of antimalware software.

The computing device receives the anti-malware driver 118 (block 404). The anti-malware driver 118 may be sent from a creator of an anti-malware program, such as a manufacturer or provider of an anti-malware program 302. The installation of the antimalware driver 118 does not require a restart of the computing device 102.

The computing device 102 loads the anti-malware driver 118 during a boot process (block 406). The anti-malware driver 118 can be re-registered during each boot process. An operating system manufacturer 304 may define a standard structure for the antimalware controller 118, and this structure may be passed between the process start module 108 and the verification module 110. Alternatively, the computer device 102 may load the antimalware driver 118 during the installation of an antimalware program.

The computing device extracts an identity from the antimalware driver (block 408). The identity may be associated with the manufacturer 302 of antimalware software. The identity can comprise a fingerprint to further improve security. The fingerprint may have a minimum fingerprint requirement that may be SHA256 by default.

The computing device 102 determines that the identity extracted from the antimalware controller 118 is signed with the certificate of trust received from the verified source (block 410). This handshake ensures that the 118 antimalware driver is legitimate.

The computing device extracts certificates from the anti-malware driver 118 (block 412). These certificates can be used to verify that an antimalware process is legitimate, so that the antimalware process is not the result of an attack by a malware or a malicious user. Certificates may designate an identity of a 302 antimalware manufacturer.

The computing device records the extracted certificates with a core of an operating system (block 414). This provides additional protection for certificates, since access to the kernel is limited. These certificates can be accessed from the kernel through the application program interfaces (APIs). These APIs are not exported from the kernel.

The computing device 102 starts the anti-malware process 114 (block 416). Antimalware process 114 may have an associated protection attribute 116, which designates a sought level of protection.

The computing device verifies that the antimalware process 114 is legitimate, based on the certificates previously registered with the core of the operating system.

ES 2 736 673 T3

Verification may not use a route. Not using a path prevents malicious code from changing a file below the call to verify the file and then extract the certificates from the file. If the antimalware process 114 is successfully verified, the verified antimalware process 126 is assigned a level 202 of protection (block 418). Verification may not be successful if protection attribute 116 seeks a level of protection that is not included in protection levels 202. The verification process is asynchronous, so that other controllers cannot delay the completion of a load through the verification process.

A user is prevented from altering the verified antimalware process 126 (block 420). This includes preventing an administrative user from altering the verified 126 anti-malware process. Specifically, to alter the verified antimalware process 126, the process trying to access the verified antimalware process 126 must have a level 202 of protection that is greater than or equal to the level of protection associated with the verified antimalware process 126.

As discussed above and shown in FIG. 2, to have a level of protection that is greater than a process signed by an antimalware service 220, a process must be signed by one of: a critical component 210 of the operating system with a protected protection level 204, a critical component 216 of the operating system with a slight protected protection level 206, a component 212 of the operating system with a protected protection level 204, or a component 218 operating system with a mild protected protection level 206. Thus, even processes signed by an operating system manufacturer 304 may not have access to processes signed by antimalware services 220. Processes signed by an antimalware service 220 may have access to processes signed by a different antimalware service.

FIG. 5 shows a procedure 500 in an example implementation for the signature of the anti-malware driver 118 by a manufacturer 302 of anti-malware software. The 302 antimalware software manufacturer signs the antimalware driver 118 with the verified 306 antimalware signature (block 502). This signature can be done using a public CA or a private CA.

The antimalware driver 118 is signed using a public CA (block 504). For example, the manufacturer 302 of anti-malware software can use a CA product such as VeriSign. As a result of this signature, the manufacturer 302 of anti-malware software could provide a fingerprint of its software publisher certificate to assist in the protection of the anti-malware process. When a public CA is used, the manufacturer 302 of anti-malware software is required to update the anti-malware driver 118 and the anti-malware program each time a new agreement is reached with the manufacturer 304 of the operating system. The new agreement may result in the issuance of new certificates for the 302 manufacturer of anti-malware software.

The anti-malware driver 118 is signed using a private CA (block 506). When a private CA is used, the manufacturer 302 of antimalware software is not required to update the antimalware driver 118 and the antimalware program each time a new agreement is reached with the manufacturer 302 of the operating system.

As a result of signing in 506, the manufacturer 302 of anti-malware software could supply the CA certificate fingerprint and one or more EKUs to the 118 anti-malware driver (block 508). The anti-malware service 308 provides the signed anti-malware driver 118 to the computing device 102 (block 510).

FIG. 6 a procedure 600 in an example implementation to provide an anti-malware driver to the computing device. An antimalware 410 controller is generated for the 308 antimalware service (block 602). A signature is generated, at least in part, in an agreement between the manufacturer 302 of anti-malware software and the manufacturer 304 of the operating system (block 604). The anti-malware driver 118 is signed with the fingerprint that identifies the manufacturer 302 of the anti-malware software (block 606). Antimalware controller 118 is provided to computer device 102 (block 608).

System and example device

FIG. 7 illustrates an example system 700 that includes the computing device 102 as described with reference to FIG. 1. The sample system 700 allows for ubiquitous environments for a smooth user experience when running applications on a personal computer (PC), on a television device and / or on a mobile device. Services and applications run substantially similarly in all three environments for a common user experience when transitioning from one device to the next while using an application, playing a video game, watching a video, etc. .

In the example system 700, multiple devices are interconnected through a central computing device. The central computing device can be local to multiple devices or it can be located remotely from multiple devices. In one embodiment, the central computing device may be a cloud of one or more servers that are connected to the multiple devices through a network, Internet or other data communication link. In one embodiment, this interconnection architecture allows the functionality to be delivered across multiple devices to provide a common and smooth experience to a user of the multiple devices. Each of the multiple devices may have different physical requirements and capabilities, and the central computing device uses a platform to allow the delivery of an experience to the device that is both adapted to the device and is common to all devices. In one embodiment, a class of target devices is created and the experiences are adapted to the

ES 2 736 673 T3 generic class of devices. A class of devices can be defined by physical characteristics, types of use or other common characteristics of the devices.

In various implementations, the computing device 102 can assume a variety of different configurations, such as for the uses of computer 702, mobile 704 and television 706. Each of these configurations includes devices that may have generally different constructions and capacities, and therefore both the computer device 102 can be configured according to one or more of the different classes of devices. For example, the computer device 102 may be implemented as the computer class 702 of a device that includes a personal computer, a desktop computer, a multi-screen computer, a laptop, a netbook, etc.

The computing device 102 can also be implemented as the mobile device class 704 that includes mobile devices, such as a mobile phone, a portable music player, a portable gaming device, a tablet, a multi-screen computer, etc. The computer device 102 can also be implemented as the kind of television device 706 that includes devices that have or are connected to generally larger screens in informal viewing environments. These devices include televisions, decoders, game consoles, etc. The techniques described herein may be supported by these various configurations of the computing device 102 and are not limited to the specific examples of the techniques described herein.

Cloud 708 includes and / or is representative of a 710 platform for content services 712. Platform 710 extracts the underlying functionality of the hardware (for example, servers) and software resources from the 708 cloud. Content services 712 may include applications and / or data that can be used while computer processing is running on servers which are far from the computer device 102. Content services 712 may be provided as a service through the Internet and / or through a subscriber network, such as a mobile telephone network or a Wi-Fi network.

The platform 710 can extract resources and functions to connect the computing device 102 with other computing devices. Platform 710 can also serve to extract the scale of resources to provide a level of scale corresponding to the demand found for content services 712 that are implemented through platform 710. Accordingly, in an interconnected device embodiment, the implementation of the functionality of the functionality described herein can be distributed throughout the system 700. For example, the functionality can be implemented in part in the computing device 102, as well as through of the 710 platform that extracts the functionality of the 708 cloud.

FIG. 8 illustrates various components of an example device 800 that can be implemented as any type of computing device as described with reference to FIGS. 1-8 to implement embodiments of the techniques described in this document. Device 800 includes communication devices 802 that allow wired and / or wireless communication of data 804 of the device (e.g., received data, data being received, data programmed for retransmission, data data packets, etc.). The data 804 of the device or other device content may include configuration settings of the device, multimedia content stored in the device and / or information associated with a user of the device. The multimedia content stored in the device 800 may include any type of audio, video and / or image data. The device 800 includes one or more data entries 806 through which any type of data, multimedia content and / or inputs can be received, such as inputs that can be selected by the user, messages, music, media content television, recorded video content and any other type of audio, video and / or image data received from any data source and / or content.

The device 800 also includes communication interfaces 808 that can be implemented as any one or more of: a serial and / or parallel interface, a wireless interface, any type of network interface, a modem and any other type of communication interface . Communication interfaces 808 provide a connection and / or communication links between device 800 and a communication network through which other electronic, computer and communication devices communicate data with device 800.

The device 800 includes one or more processors 810 (for example, any of the microprocessors, controllers and the like) that process various instructions executable by the computer to control the operation of the device 800 and to implement embodiments of the techniques described herein. Alternatively or additionally, the device 800 may be implemented with any one or with a combination of hardware, firmware or fixed logic circuits that is implemented in connection with the control and processing circuits that are generally identified in 812. Although not shown, The device 800 may include a bus system or data transfer system that couples the various components within the device. A system bus can include any one or a combination of different bus structures, such as a memory bus or a memory controller, a peripheral bus, a universal serial bus and / or a processor or local bus using any one from a variety of bus architectures.

The device 800 also includes computer-readable media 814, such as one or more memory components, examples of which include random access memory (RAM), non-volatile memory (for example, one or more memories among: only read (ROM), instant memory, EPROM, EEPROM, etc.) and a disk storage device. A disk storage device can be implemented like any type

ES 2 736 673 T3 of magnetic or optical storage device, such as a hard disk drive, a recordable and / or rewritable compact disc (CD), any type of versatile digital disc (DVD) and the like. Device 800 may also include a mass storage device 816.

The computer-readable media 814 provides data storage mechanisms for storing the data 804 of the device, as well as various applications 818 of the device and any other information and / or data related to the operational aspects of the device 800. For example, a Operating system 820 can be maintained as a computer application with computer readable media 814 and run on 810 processors. Device applications 818 may include a device administrator (for example, a control application, a software application, a signal processing and control module, a code that is native to a particular device, an extraction layer of hardware for a particular device, etc.). Device applications 818 also include any system component or modules to implement the embodiments of the techniques described herein. In this example, device applications 818 include a process start module 822 and a verification module 824 that are shown as software modules and / or computer applications. There may be additional software modules that are used to provide an interface with a device configured to capture inputs, such as a touch screen, a control panel, a camera, a microphone, etc. Alternatively or additionally, the process start module 822 and the verification module 824 can be implemented as hardware, software, firmware or any combination thereof. In addition, additional software modules can be configured to support multiple input devices, such as separate devices to capture visual and audio inputs, respectively.

The device 800 also includes an audio and / or video input and output system 826 that provides audio data to an audio system 828 and / or provides video data to a display system 830. The audio system 828 and / or the display system 830 may include any device that processes, displays and / or otherwise represents audio, video and image data. Video signals and audio signals can be communicated from the device 800 to an audio device and / or a display device through an RF (radio frequency) link, an S-video link, a Composite video link, a component video link, DVI (digital video interface), an analog audio connection or other similar communication link. In one embodiment, the audio system 828 and / or the screen system 830 is implemented as external components to the device 800. Alternatively, the audio system 828 and / or the screen system 830 is implemented as integrated components of the device 800 of example.

conclusion

Although the invention has been described in a specific language for structural features and / or methodological actions, it should be understood that the invention defined in the appended claims is not necessarily limited to the specific features or actions described. On the contrary, the specific characteristics and actions are described as exemplary forms of implementation of the claimed invention.

ES 2 736 673 T3