Centralized operation management

The identification and reliability of programs stored in and running on computer systems is a fundamental security issue for users. Basically, the user wants the interactive program to work as advertised. If a user trusts a particular program, but that program behaves unexpectedly, the user may run into problems. In some situations, the program may have been deliberately tampered with, or there may be a virus or other security issue. Often, a program simply behaves differently than the user initially expected. This is because the program is not from a trusted source, has been tampered with at some point and has become incompatible with other components, or has been disabled for some other reason.

Therefore, many security programs have been run on computers in recent years to try to address this issue. Each of these applications addresses a set of computer security needs, including antivirus applications, firewalls, malware detectors, signature checking mechanisms, and more. Some of these programs are offered as part of the operating system, some are integrated into Internet browsers, while others are purchased or even downloaded from third-party vendors.

However, these programs are not a consistent mechanism for establishing identity authentication. All operations performed within the operating system, even though some operations performed within the system introduce data objects from untrusted sources that can harm your computer. It is not always possible to rely on a comprehensive check of. These processes often fail to function optimally within the operating system and slow down the overall system. The mixed nature of these security programs makes it difficult or impossible for software developers to implement a set of unified security interface programming. To make matters worse, some of these miscellaneous combinations of security assessment programs may have come from sources that have not been certified as strictly credible.

A consistent mechanism is needed to establish identity authentication. Particularly needed is a security evaluation mechanism that is fully integrated with the operating system to provide consistent performance, comprehensive inspection of operations performed within the operating system, and homogeneous software development support. is there.

Some embodiments of the present invention provide novel security frameworks for devices. In some embodiments, this framework is part of the device's operating system. The framework of some embodiments includes a security evaluation module that evaluates security policies regarding various operations that need to be performed on an application running on the device. Examples of such operations include installing and running an application, as well as opening a content file (eg, opening a document) in the application.

In some embodiments, the device is provided with an operation start module that receives various operation requests for the application. Upon receiving such a request, the operation start module should check the security evaluation module for the feasibility of the requested operation based on the security policy rules stored in the security policy data storage. Instruct. In some embodiments, security policy rules are used to validate the downloaded program, verify the source or publisher of the program, and so on. If the requested operation is permitted by the security policy rule, the security evaluation module notifies the operation start module that the operation has been approved. The operation start module instructs the corresponding operation handler (for example, an installer, an execution module, or a module that opens a file) to perform the requested operation.

In some embodiments, the security policy is embodied in the form of various rules or instructions stored in the rules database. The rules in the rules database specify what a data object (eg, program code, or document to open) needs to comply with your computer's security policy. In some embodiments, in some embodiments, the rules database comprises various tables for efficient execution of queries against the rules database. Two examples of such tables are the authorization table and the cache table.

In some embodiments, when assessing the security of a data object under a security policy, the entries in the authorization table in the rules database need to be examined in the order indicated by their priority. In these embodiments, when performing any security evaluation on a data object, the low priority rule can be applied only when the high priority rule cannot be applied. When a high-priority rule and a low-priority rule overlap, the high-priority rule takes precedence over the low-priority rule. Therefore, if any change is made to a high-priority rule, the scope of the low-priority rule may change.

In some embodiments, the operation start module performs a security evaluation for each operation requested by the application. In another embodiment, the operation for which the operation start module performs the security evaluation is only a part of the operations required for the application. For example, in some embodiments, the evaluation is performed only for the installation of the newly received application or for the application to open the newly received file for the first time. To facilitate this approach, some embodiments of the device associate tags with newly received applications and newly received files. This tag association is made when such a file is first loaded on the device or opened for the first time (for example, when it is first downloaded over the network or through the device's peripheral interface). Is.

The security evaluation module of some embodiments approves or disapproves the validity of one or more data files by validating the data structure (such as "archive") that contains the data files. In some such embodiments, the archives retain an ID signature, which can be used to securely authenticate the data files and the source of the data files contained within those archives. Can be identified. More specifically, in the operating systems of these embodiments, there are rules in the rules database that approve or disapprove documents or data files based on signatures embedded in the archive structure containing those documents or data files. Included in. Documents in the approved archive are automatically approved.

The above outline is for briefly introducing some embodiments of the present invention. It does not mean an introduction or an outline of all the contents of the invention disclosed in the present specification. The following detailed description, and the drawings cited in the detailed description, further describe the embodiments described in the abstract as well as other embodiments. Therefore, in order to understand all the embodiments described herein, a thorough review of summaries, detailed descriptions and drawings is required. Furthermore, the claimed content is not limited by the abstract, detailed description and exemplary details in the drawings, and the claimed content can be implemented in other particular forms that do not deviate from the intent of the subject matter. Therefore, it is defined by the attached claims.

The novel features of the present invention will be described in the appended claims. However, for illustration purposes, some embodiments of the present invention are shown in the figures below.<figref num="1">It is a figure which shows the operating system of the computing device which evaluates the security of various operations requested to perform.</figref><figref num="2">It is a diagram conceptually showing the process that the operating system uses to process and approve the requested operation.</figref><figref num="3">It is a diagram conceptually showing an example of a process for carrying out a security evaluation of a requested operation based on an operating system security policy.</figref><figref num="4">It is a figure which shows the data flow in an operating system when performing a security evaluation using a security evaluation module and a rule database.</figref><figref num="5">It is a figure which shows the data flow in an operating system when performing a security evaluation using a security evaluation module and a rule database.</figref><figref num="6">It is a figure which shows the data flow in an operating system when performing a security evaluation using a security evaluation module and a rule database.</figref><figref num="7">It is a figure which conceptually shows the authority table which stores the rule or instruction for judging the security policy of an operating system.</figref><figref num="8">It is a figure which conceptually shows the authority table including an additional field.</figref><figref num="9">It is a figure which conceptually shows the authority table which contains only one rule field in each record or entry.</figref><figref num="10">It is a figure which shows the authority table which represents a single security policy by using a plurality of entries.</figref><figref num="11">It is a series of Venn diagrams showing an example of a security policy.</figref><figref num="12">It is a series of Venn diagrams showing an example of another security policy.</figref><figref num="13">It is a figure which conceptually shows the process for performing a security evaluation using an authorization table.</figref><figref num="14">It is a figure which shows the rule database which contains a permission table and a cache table.</figref><figref num="15">It is a figure which shows the security evaluation module which uses both authority table and cache table for security evaluation based on the request from the operation start module.</figref><figref num="16">It is a figure which shows that the cache table entry for a data object is generated and stored by a security evaluation module.</figref><figref num="17">It is a figure which conceptually shows the process which uses both a permission table and a cache table to perform a security evaluation.</figref><figref num="18">It is a figure which conceptually shows the process which maintains and manages a rule table after a user changes a rule database.</figref><figref num="19">It is a diagram conceptually showing a computer having an operating system that inserts its own identifier to perform a security evaluation.</figref><figref num="20">It is a figure which shows the operating system which checks a tag as a part of a security evaluation operation.</figref><figref num="21">It is a figure which shows the data flow in an operating system when the security evaluation is performed using the operation start module which identifies a tag in a data object.</figref><figref num="22">It is a figure which shows the data flow in an operating system when the security evaluation is performed using the operation start module which identifies a tag in a data object.</figref><figref num="23">It is a figure which shows the operating system which has a rule database which contains the rule for processing a tag bit.</figref><figref num="24">It is a figure which shows the computer which receives and stores the data archive containing a signature.</figref><figref num="25">It is a figure which shows the operating system which contains the rule for performing the security evaluation of a data file or a document based on the signature in the data archive in the rule database.</figref><figref num="26">It is a figure which conceptually shows the process which performs the security evaluation of the operation which opens a document.</figref><figref num="27">It is a figure which conceptually shows the electronic system in which some embodiments of this invention are carried out.</figref>

The text of the specification below will include a number of details for illustration purposes, but those skilled in the art will appreciate that the present invention can be practiced without the use of these specific details. In another example, well-known structures and devices are shown in the form of block diagrams so as not to obscure the description of the invention in extra detail.

I. Operating system with security rating Figure 1 shows the operating system 100 of a computing device that evaluates the security of various operations that are required to be performed. The requested operation can be running the application, installing the application, opening a document, and so on. The security of the requested operation is evaluated by the security evaluation module, which is part of the security framework provided by the operating system. Based on this security evaluation, either terminate the requested operation or allow the processing to continue.

As shown in FIG. 1, the operating system 100 includes a security evaluation module 110, a rule database 120, an operation start module 130, an operation request module 140, an installation module 170, an execution module 172, and a module for opening contents 174. And, including. Figure 1 also shows the application 150 and data file 160 for which the operating system 100 evaluates its security policy. The security evaluation module 110 and the rules database 120 are part of a security framework 180 that provides an application programming interface (API) 190.

The operating system 100 is a series of programs that manage computer hardware resources and provide common services to various software application programs. The operating system 100 performs functions such as input, output, and memory allocation as a bridge between the application program and the computer hardware. In some embodiments, the application code of a program is executed through hardware and interacts with the operating system via interrupts received from the operating system or calls made to the operating system.

Application 150 is an executable data object that runs on an operating system to perform its functions. Examples of application 150 include word processors, web browsers, games, media editing applications, and the like. In some embodiments, application 150 is an installation program that installs one or more executable programs on a computer running operating system 100.

In some embodiments, the application 150 embeds one or more ID signatures so that the user of the application can determine the authenticity of the application. The signature embedded in application 150 is the secure ID of the application's source, or publisher. A data object (eg, an application) is "signed" when a signature is generated based on the content of the data object using a secret private key known only to the signer of the data object. Therefore, such a signature can identify the signer or source of the data object and can protect the integrity of the data object. The data object (ie, operating) to authenticate the signature of the data object, i.e. to verify that the signature was actually generated from the data object by the proposed source / signer. The recipient of the system) uses the public key to authenticate the signature along with the contents of the data object. It is known that the public key comes from the source / signer who is said to be, and that the public key is really issued by the source / signer who is said to be. Can be independently verified by the recipient (eg, by contacting a trusted certificate authority or by checking the recipient's own database).

In some embodiments, the signature of the data object is extracted from the public key certificate associated with the data object. A public key certificate (also known as a digital certificate or ID certificate) is an electronic document that uses a digital signature to bind a public key to ID information such as the name of a person or organization, its address, and so on. The certificate can be used to verify that the public key belongs to an individual. The signature on the certificate is the one in which the signer of the certificate authenticates that both the ID information and the public key belong. A signature that is generated or signed based on both the content of the application data object and the information in the certificate must be authentic when the content of the application data object is tampered with and the information in the certificate is authentic. To prove. In addition to the signature and source identifier (eg, vendor ID and public key), the certificate also contains information about how the signature is authenticated (eg, the ID of the algorithm used to generate the signature).

In the example in Figure 1, the operating system 100 is performing the signature authentication operation. In some embodiments, the operating system 100 prohibits the execution or installation of the application 150 if it fails to authenticate the signature of the application 150. In some embodiments, the operating system 100 continues to operate an application, even for an authenticated application, unless the publisher of the application is determined to be reliable according to a set of security policies. Is prohibited.

Data file 160 is a data object associated with one or more applications that can run within an operating system. Examples of data files 160 include text files, word processor documents, spreadsheets, media files, and the like. The data file 160 is read or opened by an application that can read or open the data file. In some embodiments, the data file 160 includes a document that does not contain a signature or certificate. The data file may also be placed within the archive structure so that the data file can be associated with the signature or certificate. The mechanism by which the security evaluation module of some embodiments handles the data files in the data archive is shown in FIGS. 25 and 26 below.

Installation module 170 is a module inside operating system 100 that oversees the installation of applications such as application 150. In some embodiments, the installation module 170 waits for the "continue" command to be sent from the operation start module 130 before continuing the installation process of the application 150 through the operating system. In some of these embodiments, the installation module passes the application data object 150 to the security evaluation module 110 for the purpose of signing the application according to a set of security policies and verifying compliance with a set of requirements. The installation module 170 continues the installation of the application 150 only when it receives information from the operation start module 130 indicating that the application 150 has been authenticated and its source has been verified.

Execution module 172 is a module inside operating system 100 that launches applications that run within operating system 100, such as application 150. Execution module 172, like installation module 170, in some embodiments waits for a "continue" command from operation start module 130 before launching application 150 through operating system 100. In some of these embodiments, the execution module passes the application data object 150 to the security evaluation module 110 to verify the signature of the application according to a set of security policies and meet a set of requirements. After the application 150 is authenticated and its source is verified, the execution module 172 continues the execution of the application 150 only when the start command is received from the operation start module 130.

The content opening module 174 is a module inside the operating system 100 that oversees the opening of the data file 160. In some embodiments, opening the content involves identifying a suitable application for the content in the data file 160 and then passing that content to the application. As mentioned above, the content of the data file may or may not be signed and may or may not require authentication. When a document is required to be authenticated, the document is passed to the security evaluation module 110 for the purpose of verifying the signature of the document according to a set of security policies and meeting a set of requirements. The module 174 that opens the content proceeds to open the document, that is, the data file 160, only when the start command is received from the operation start module 130 after the data file 160 is authenticated and its source is verified.

In some embodiments, opening the data file 160 is associated with running the application. In some of these embodiments, the content opening module 174 first identifies the application for opening the data file 160. If the application identified by module 174 that opens the content is already running in the operating system, the module that opens the content passes the data file to the execution module 172 to be executed. If the identified application is not currently running, module 174 opening the content causes execution module 172 to start running the application. Only after the operating system 100 determines that the application has been authenticated and its source verified will the identified application be executed.

The operation request module 140 is a module that requests the operating system 100 to perform a specific operation. Such operations can include installing applications, running applications, opening documents, and so on. In some embodiments, the operation request module 140 receives a user command (for example, by selecting a graphical icon of a document or application) to open a document or execute a particular application, a user interface (GUI). Etc.). The operation request module 140 may also be another program running within the operating system that requests the operation start module 130 to perform an operation. In some embodiments, the operation request module 140 also fails to authenticate the signature of application 150 or the source of application 150 is trusted if the security policy of operating system 100 does not allow the operation to be performed. If not), you will receive a notification from the operation start module 130.

The operation start module 130 is a module that enforces an operating system security policy by allowing or prohibiting certain operations from being performed. The operation start module 130 receives a request for a specific operation from the operation request module 140. The operation start module 130 acquires the necessary data object (for example, application 150 or data file 160) based on the request. The operation start module 130 then requests the security evaluation module 110 to evaluate the operation requested under the security policy of the operating system 100. The operation start module also passes the received data object to the security evaluation module as part of the requested security evaluation operation.

The security evaluation module 110 is a module for determining whether or not an operation complies with the security policy of the operating system. The security evaluation module 110 receives a query from the operation start module 130 requesting the evaluation of the security policy for a specific operation. The security evaluation module 110 determines whether an operation complies with a security policy by examining the data objects associated with the operation. For example, a request based on an operation that installs application 150 may include some data objects that the security assessment module examines (eg, the installation file of the installation package for application 150, and the installation program itself). In another example, a request to open data file 160 in application 150 may include data objects for both application 150's executable program and data file 160 inspected by security assessment module 110. In some embodiments, the application 150 and the data file 160 are said to be subject to security evaluation. Subsequently, the security evaluation module 110 responds to the query received from the operation start module 130. For example, if a particular operation meets the security policy requirements, the security evaluation module notifies the operation start module 130 that it meets the security policy requirements. On the other hand, if the specific operation does not meet the security policy requirements, the security evaluation module responds to the operation start module that the specific operation does not meet the security policy requirements.

In some embodiments, the security evaluation module 110 and the rules database 120 are implemented as part of the security framework 180 that performs the security evaluation of the operating system 100. Other components of the operating system can use the security API 190 provided by Security Framework 180 to perform security assessments of operations. In the example of FIG. 1, the operation start module 130 is a component of the operating system 100 that communicates with the security evaluation module 110 via API 190.

Once the operation start module 130 receives a response to a query from the security evaluation module 110, the operation start module 130 allows or disallows (eg, prohibits) the continuation of a particular operation from the security policy. To enforce. If the operation is allowed to continue, the operation start module 130 initiates the execution of the operation requested by the operation request module 140 to the installation module 170, the execution module 172, or the content opening module 174. If the operation is not permitted, the operation start module 130 notifies the operation request module 140 to that effect. Upon receiving the notification, the operation request module 140 notifies the user this time and ends the requested operation. Figure 2 below illustrates an example of the process executed by the operation start module 130.

The signature embedded within the data object verifies that the data object comes from a particular source when authenticated by its recipient. In some embodiments, the security evaluation module 110 authenticates the signature in the data object and verifies the source of the data object. Data objects that cannot generate signatures that can be authenticated by the security evaluation module (eg, defective or incomplete) are likely to come from untrusted sources. In such a situation, the security evaluation module 110 notifies the operation start module 130 that the data object is not executed or opened under the security policy of the operating system. (In some embodiments, a signed document or program that could not be authenticated is not allowed to continue.) Conversely, if the security assessment module 110 can authenticate the signature of the data object. If the security assessment module also meets other requirements under the security policy (for example, if the source of the data object is trusted), then it is problematic to continue the requested operation with the operation start module. You can notify that there is no such thing.

Security policies implemented by some embodiments examine different data objects in different ways. For some types of data objects, operating system security policies may have additional requirements that need to be met in addition to signature authentication. For example, your security policy may require you to authenticate your signature based on a set of certificates, or the source of your data object (even if your code signing is successfully authenticated) is from a particular vendor. May be required. In some embodiments, the security policy can be modified by the user. For example, a trusted computer administrator can also modify an operating system security policy to allow a security evaluation module to accept certain data objects without performing any signature verification or authentication. In some embodiments, the security evaluation module 110 can be arbitrarily programmed to implement any security policy for any data object presented by the operation initiation module 130.

In some embodiments, the security policy used to evaluate the data object is implemented as a set of instructions executed by the security evaluation module 110 to determine if the data object conforms to the security policy. In the operating system example of Figure 1, the instruction set that implements the security policy is stored in the rules database 120. The security assessment module 110 retrieves the instruction set from the rules database 120 and uses the retrieved instructions to (i) analyze the data object (eg, to determine if the source of the data object is acceptable). ), And (ii) issue a response to the operation start module 130 based on the analysis. Each set of one or more rules stored in the rules database is sometimes referred to as a "code requirement". The name comes from the fact that this ruleset specifies what a data object (for example, executable program code such as application 150, or data file 160) needs to comply with an operating system security policy. To do. Figure 3 below illustrates an example of the process performed by the security evaluation module 110. The code requirements will be described in more detail later with reference to FIGS. 9 and 13.

The rules database 120 is a database that stores a set of instructions for implementing a security policy for operating system 100. The security evaluation module 110 gets a set of instructions from the rule database 120, thereby responding to the security query made by the operation start module 130. The rule database will be described in more detail later with reference to FIGS. 7 to 17.

FIG. 2 conceptually illustrates the process 200 used by some embodiments of the operating system to process and approve the requested operation. Specifically, the process requests a security assessment of the requested operation and initiates an approved operation. In some embodiments, process 200 is performed by a module within operating system 100 (eg, operation start module 130 in FIG. 1).

Process 200 is started when an operation request is obtained (for example, from the operation request module 140) (at 210). In some embodiments, the request is a user command to open a document or run an application. The request may also be prompted by the currently running application or system process to perform a particular operation within the operating system.

The request is then passed to the security assessment module by this process (at 220). In the example of FIG. 1, the request also includes a data object (eg, application 150 or data file 160) that the security evaluation module needs to evaluate the security of the request under the security policy. For example, an operation request initiated by a user command to open a document may require an application call to open the document, so multiple data objects need to be passed to the security evaluation module. Therefore, the request passed to the security evaluation module will include both document and application file handles.

The process then receives a response from the security assessment module (eg 110) (at 230) and decides whether to approve the requested operation (at 240). In some embodiments, the response from the security assessment module indicates whether the request has passed the operating system security policy (eg, by notifying the operation start module 130). In some embodiments, if the response indicates that the request has passed the security assessment (eg, from an acceptable source with an authenticated signature), process 200 will perform the requested operation. To continue. In some embodiments, process 200 was requested if the response instruction was otherwise (eg, if the security evaluation module was unable to authenticate the signature, or if the data object was not from an acceptable source). End or put the operation on hold.

When the request is approved, process 200 (at 250) receives the request and passes it to an operation handler that can perform the approved operation. As shown in Figure 1, some operation handlers can receive requests and perform operations. This includes installation module 170, execution module 172 and content opening module 174. Process 200 terminates after the request is passed to the operation handler.

On the other hand, if process 200 disapproves the request, it returns a default message to the operation request module (eg 140 in Figure 1) (at 260), followed by a notification to the user (not shown). Furthermore, if the request is not approved, process 200 does not pass the request to the operation handler. Therefore, if the request is not approved, none of the operation handlers (eg 170, 172 and 174) will perform the requested operation. Process 200 terminates after the default message is returned to the action request module.

In some embodiments, variations of process 200 are performed. For example, the specific operations of process 200 are not always performed in the exact order shown in the figure. The specific operation does not have to be performed in one continuous series of operations, and various specific operations may be performed in different embodiments.

Figure 3 conceptually shows an example of Process 300 for performing a security assessment of a requested operation based on an operating system security policy. Specifically, process 300 uses the rules database to match requests against rules that allow the process to perform security assessments on the requested operation. In some embodiments, process 300 is performed by a module within the operating system, such as the security evaluation module 110 of FIG.

Process 300 is started when a request is received from the operation start module (at 310). The request indicates that a security assessment is required for the particular operation requested.

The process then (at 320) queries the rules database to find a match. Process 300 checks to see if there are any rule entries in the rules database that match the request or are applicable to the request. Rules that do not match the request cannot be used to evaluate the security of the request. For example, a rule that checks an application with a specific name cannot be used to check an application with another name. As described further below, multiple entries in the rules database may match the request at the same time, but only the highest priority rule is applied.

The process then determines if a matching or applicable rule (at 330) has been found in the rules database. If process 300 finds at least one matching rule, process proceeds to 340. Otherwise, the process goes to 360.

In 360, the process returns a default response to the operation start module indicating that there are no applicable rules or instructions for the request. In some embodiments, the default security policy does not approve a request for an operation for which there is no matching rule in the rules database. In some embodiments, the default security policy allows requests that are not specifically prohibited by the rules database. In some embodiments, the default policy requires the operating system to notify the user. Process 300 terminates after the default response is returned.

At 340, the process performs a security assessment on the request. In some embodiments, the process performs a security assessment by applying a matching rule or applicable instruction set to the data objects associated with the request (eg, application 150 and / or data file 160). .. In some embodiments, the matching ruleset is executed as an executable program in the security evaluation module. In some embodiments, the matching ruleset causes the security assessment module to perform a security assessment based on variables such as the source of the data object, the ID of the data object, and the type of the data object.

Once the security evaluation has been performed, the process (in 350) returns the security evaluation to the operation start module to determine if the requested operation should be allowed to continue. After returning the security evaluation to the operation start module, process 300 ends.

Some embodiments perform variations of process 300. For example, certain operations in process 300 are not always performed in the exact order shown with the figure. The specific operation does not have to be performed in one continuous series of operations, and various specific operations may be performed in different embodiments.

Figures 4 to 6 show the data flow inside the operating system 100 when performing a security evaluation using the security evaluation module and the rules database. As shown in FIG. 1, the operating system 100 of FIGS. 4 to 6 includes a security evaluation module 110, a rule database 120, an operation start module 130, an operation request module 140, an installation module 170, an execution module 172, and contents. Consists of including module 174, which opens the.

Figure 4 shows the data flow inside the operating system 100 when the requested operation is intended to install an application. When the operation request module 140 requests the operation start module 130 to install the application X (operation '1'), the operation data flow is started in the operation request module 140. This request is based on user commands for installing application X in some embodiments. User commands can be received via the user interface.

The operation start module 130 then requests the security evaluation module 110 to evaluate the security of the application X installation under the operating system security policy (operation '2'). In some embodiments, this requirement for security evaluation module 110 includes handles to data objects (such as installation files and packages) needed to install application X.

Upon receiving the request, the security evaluation module 110 queries the rules database 120 (operation '3') to look for rules or instructions that match the installation request under the security policy. The rules database provides security evaluation module 110 with rules or instructions that match queries within that database (operation '4'). This query process between the security evaluation module 110 and the rules database 120 continues until a matching rule is found in the rules database or until it is determined that no applicable rule exists in the rules database.

Once a matching rule is found, the security evaluation module 110 performs a security evaluation by applying the matching rule to the data object associated with the installation of application X. In some embodiments, the rule takes the form of a program instruction for processing the data object and determining whether the data object complies with the security policy of the operating system. In some embodiments, processing a data object involves verifying the signature associated with the installation of application X inside the data object. In some embodiments, compliance with a security policy is determined based on whether the signature was successfully authenticated and whether the signature is derived from a trusted source. Subsequently, the security evaluation is returned to the operation start module 130 (operation '5'). In the example shown in FIG. 4, the security evaluation module shows that there is no problem even if application X is installed. This is a security assessment because the data objects associated with the application X installation were found to comply with the security policies stored in the rules database.

After receiving a security rating that it is okay to install application X, operation start module 130 tells installation module 170 to launch the installer and install application X on the computer. The dotted lines around the execution module 172 and the content-opening module 174 indicate that those two modules are not involved in this operation.

Figure 5 does not illustrate the data flow of an installation operation, but shows the data flow inside Operating System 100 when the requested operation is intended to execute (eg, launch or call) an application. Except, FIG. 5 is almost the same as FIG. When the operation request module 140 requests the operation start module 130 to execute the application X (operation '1'), the operation data flow is started in the operation request module 140. This request is, in some embodiments, a user command for executing application X. User commands can be received via the user interface.

Subsequently, the operation start module 130 requests the security evaluation module to evaluate the security regarding the execution of application X under the security policy of the operating system (operation '2'). In some embodiments, the request includes handles to data objects required to run Application X, such as Application X's executable machine code.

Upon receiving the request, the security evaluation module 110 queries the rules database 120 (operation '3') to find a rule or instruction that matches the request to run the application under the security policy. .. The rules database provides the security evaluation module 110 with rules or instructions that satisfy the query conditions in the database (operation '4'). This query process between the security evaluation module 110 and the rules database 120 continues until a matching rule is found in the rules database or until it is determined that no applicable rule exists in the rules database.

Once a matching rule is found, the security evaluation module 110 performs a security evaluation by applying a matching rule to the data object associated with running application X. In some embodiments, the rule takes the form of a program instruction for processing the data object and determining whether the data object complies with the security policy of the operating system. In some embodiments, processing a data object involves verifying the signature associated with running application X inside the data object. In some embodiments, compliance with a security policy is determined based on whether the signature was successfully authenticated and whether the signature is derived from a trusted source. Subsequently, the security evaluation is returned to the operation start module 130 (operation '5'). In the example shown in FIG. 5, the security evaluation module shows that there is no problem in executing the application X. This is a security assessment because the data objects associated with running Application X were found to comply with the security policies stored in the rules database.

After receiving the security evaluation that there is no problem in executing the application X, the operation start module 130 instructs the execution module 172 to start the application X. The dotted lines around the installation module 170 and the content-opening module 174 indicate that those two modules are not involved in this operation.

Figure 6 is similar to the two preceding figures, except that the data flow in Figure 6 is based on the request to open the document. When the operation request module 140 requests the operation start module 130 to open the document data file X (operation '1'), the data flow starts in the operation request module 140. This request is, in some embodiments, a user command to open the data file X. User commands can be received via the user interface.

Subsequently, the operation start module 130 requests the security evaluation module to evaluate the security for opening the data file X under the security policy of the operating system (operation '2'). In some embodiments, this request includes a handle to the data file X. If the data file X is a document to be opened by application Y, in some embodiments this request also includes a handle to application Y's executable binary file. In this example, both Document X and Application Y are considered to be the data objects needed to open Document X. Therefore, security assessments are performed on both of these data objects. On the other hand, in some embodiments, the application required to open the data file X is already running (hence, as in the example in Figure 5, it has already passed the security assessment). Therefore, only the handle for datafile X is passed to the security evaluation module as part of the request.

Upon receiving the request, the security evaluation module 110 queries the rules database 120 (operation '3') to find a rule or instruction that matches the request to open the document under the security policy. The rules database provides the rules or instructions in the database to security evaluation module 110 (operation '4'). This query process between the security evaluation module 110 and the rules database 120 continues until a matching rule is found in the rules database or until it is determined that no applicable rule exists in the rules database.

Once a matching rule is found, the security evaluation module 110 performs a security evaluation by applying a matching rule to the data object (eg, application Y) associated with opening the data file X. In some embodiments, the rule takes the form of a program instruction for processing the data object and determining whether the data object complies with the security policy of the operating system. In some embodiments, processing a data object involves verifying the signature associated with opening the data file X inside the data object. In some embodiments, the determination is made based on whether the signature was successfully authenticated and whether the signature is derived from a trusted source. Subsequently, the security evaluation is returned to the operation start module 130 (operation '5'). In the example shown in FIG. 6, the security evaluation module shows that there is no problem in opening the data file X. This is a security assessment because the data objects associated with opening datafile X (eg, datafile X itself, and application Y) were found to comply with the security policy stored in the rules database. ..

After receiving a security evaluation that it is okay to open the data file X, the operation start module 130 instructs the module 174 to open the content to start the application X. The dotted lines around the execution module 172 and the installation module 170 indicate that those two modules are not involved in this operation. In some embodiments, the operation start module also launches execution module 172 if it is necessary to run an application that is not currently running on the computer to open the document.

II. Rule database In the above example, the data object associated with the requested operation is evaluated according to the operating system security policy. These security policies are embodied in various rules or instructions stored in the rules database. Therefore, an "operating system security policy" is a set of programmable rules that control the operations performed within an operating system, but is not part of the program of the operating system itself. As described in Section II-C, these "operating system security policies" can be modified by the computer system user or vendor.

In some embodiments, the rules database comprises various tables to streamline the execution of queries against the rules database. Two such tables (ie, the authorization table and the cache table) will be discussed later.

A. Authorization table In some embodiments, the rules database comprises an authorization table. In some such embodiments, the authorization table includes a rule that the security evaluation module retrieves to determine whether to allow the performance of a particular operation within the operating system. The rules in the authorization table specify what a data object (eg, program code, or the document to open) needs to comply with your computer's security policy. Therefore, each one or more sets of these rules are referred to as "code requirements" in some embodiments.

The code requirements include arbitrary conditions for the certificate used to sign the principal, such as requiring the vendor ID and / or public key in the certificate to belong to a particular trusted source. I can express it. Code requirements may also require other things, such as configuration dictionary entries that are an integral part of these programs. For example, the code requirement may state that "an entitlement is required to allow the use of the address book" (an entitlement is one of the constituent dictionaries specified by something as an inclusion in the program. Is). This has nothing to do with its signature.

Figure 7 conceptually shows a permission table 700 that stores rules or instructions for determining an operating system security policy. The authorization table 700 contains a set of entries or records, and each entry or record contains a set of one or more rules or instructions that specify code requirements. A particular security policy can be represented by one or more entries in the authorization table.

As shown, the storage device 710 stores an authorization table 700, which contains several entries or records, including records 721, 722, and 723. The record represents several security policies, including policies 731, 732 and 733. Each record or entry also contains a set of fields 741 through 744. Fields 741 to 743 are labeled "Rule 1" to "Rule n". Field 744 is labeled "Action".

Each field of a record is a set of rules or instructions that tells the operating system security assessment module to perform a set of logical or arithmetic operations and make decisions according to the set of logical or arithmetic operations. For example, the'X'in field 741 of record 721 may be a set of operations to check if the security assessment is for the application, and the'Y' in field 742 of record 721 checks the expiration date of the certificate. It may be a set of operations, and the'Z'in field 742 of record 722 may be a rule that verifies whether the application is from a trusted vendor or source, while the'Z'in field 741. W'may be a rule that checks if the file to be opened is a file downloaded from the Internet. Not all fields of the entry need to be filled. For example, entry 723 contains only one rule field (741). The instruction in that field for record 723 can be a check to download the document requested to open from the Internet.

Each set of instructions in separate fields of a record jointly makes one decision. By using this one determination, it is determined whether or not the action described in the "action" field 744 should be performed. For example, because the action field 744 of record 722 says "approved," the data object being evaluated has a certificate validated under the X.509 standard and comes from a trusted vendor. When it is an application, the security evaluation module approves the request to launch a particular application. On the other hand, entry 723 is "unapproved", so when a particular content item is being downloaded from the Internet, the security assessment module disapproves the request to open that particular content item.

A security policy consists of a collection of such instructions or requirements. In the example of FIG. 7, security policy A731 consists of rules or instructions in record 721, security policy B732 consists of rules or instructions in record 722, and security policy C733 consists of rules or instructions in record 723. To. In some embodiments, a security policy is a collection of rules that span two or more records in an authorization table. Such an authorization table will be described further later with reference to FIG.

In some embodiments, some rules are for matching and some for verification. Matching rules determine whether a particular entry is applicable to a security evaluation request. The validation rule determines whether the request complies with the security policy embodied by a particular entry or record in the rules table. For example, a rule that rejects a type of data object from a particular vendor is a validation rule, while a rule that limits the scope of the rule to game applications is a matching rule.

Some embodiments include other fields in addition to the rule fields and fields for actions. FIG. 8 conceptually shows the authorization table 800. The authorization table 800 is similar to the authorization table 700, except that it includes additional fields in addition to the rule and action fields illustrated in FIG. The authorization table 800 also has several entries (821-823), and each entry has several fields (840-844). These fields include rule fields (841 to 843) and action fields (844). On the other hand, unlike the authorization table 700, each entry in the authorization table 800 also comprises a priority field 840.

The priority field 840 of some embodiments determines which entry in the authorization table to look first to find a rule that matches the request. In the priority field, look for entries with higher priority values, then look for entries with lower priority values. As shown in FIG. 8, in the priority field 840, record 822 has a priority value of 1.75, while record 823 has a priority value of 1.25. Therefore, record 822 is searched before record 823, while record 821 (with a priority value of 2.70) is searched before both records 822 and 823. Entry priorities can be determined in other ways (for example, by using integers, by arranging the highest priority entries to the lowest priority entries in the linked list, or by sorting by entry priority. May be written (by).

For any given security evaluation request, multiple entries in the authorization table may match the request. On the other hand, in some embodiments, if a matching entry is found, the security evaluation module suspends the search of the authorization table. For example, in a search that may have more than one match, the security assessment module uses only the first matching entry (ie, the highest priority matching entry). Therefore, using priority fields reduces the likelihood of multiple matching entries and ensures that only one matching entry is used for security evaluation.

In the examples of FIGS. 7 and 8, each entry in the authorization table comprises several fields, including several rule fields each containing an instruction set for performing a set of logical or arithmetic operations. On the other hand, some embodiments represent a set of instructions for all rule fields as a single rule and have only a single rule field in the authorization table. A single rule field in a record in the authorization table contains all the instructions needed to perform a security assessment under a particular security policy.

FIG. 9 conceptually illustrates the authorization table 900 of several other embodiments, including only one rule field within each record or entry. Privilege table 900, like privilege table 800, contains priority field 941, action field 943, and some entries (921-923). On the other hand, unlike the authorization table 800, which has several rule fields, the authorization table 900 has only one rule field 942.

A code requirement that includes rule field 942 for each record or entry includes all instructions, including both matching and validation instructions necessary to perform a security evaluation on the request. In some embodiments, as mentioned above, the code requirement can be a set of one or more concatenated rules. In some such embodiments, the code requirements apply to the requested data object in order to verify the source of the data object. For example, the instruction set in the code requirement that includes rule field 942 for entry 921 is (1) whether the security assessment request is for the application, (2) whether the application comes from a trusted vendor or source, and (3). ) It is possible to determine whether the information that identifies the source in the certificate (for example, vendor ID, public key, etc.) actually belongs to the trusted vendor or source. The action in action field 943 applies only if each of the three decisions meets the conditions of its corresponding rule. On the other hand, if one or more of the three decisions do not meet the conditions of the corresponding rule, the action field of the record does not apply. Therefore, the action specified by the action field is based on a single rule for the record (eg, approval or disapproval of the requested action) and is communicated to the security evaluation module.

The authorization table may have a format different from that shown in FIGS. 7-10. For example, authorization table entries can, in some embodiments, be skipped if the invalid field contains a value, and the security evaluation module does not consider the entry during the search "disable". Can include a field called.

As explained above with reference to Figure 7, operating system security policies are represented by rules and instructions in the rules database. In some embodiments, each entry in the authorization table is sufficient to represent one particular security policy (eg, to allow only applications with a valid signature from a particular vendor). In some embodiments, a security policy can be represented by two or more entries in the authorization table.

Figure 10 shows the authorization table 1000, which uses multiple entries to represent a single security policy. FIG. 10 will be described with reference to FIGS. 11 and 12. Privilege table 1000, like privilege table 900, has several entries (1021-1027), and each entry has three fields (priority field 1041, rule field 1042, and action field 1043). Meanwhile, FIG. 10 also shows an example of security policy 1031 (security policy 1) implemented with three entries in the authorization table (entries 1021, 1024 and 1026). Each of the three security policy entries has a different priority (P1, P5 and P8), and only the one with the highest matching priority is used for security evaluation. In this example, P1 has the highest priority, P5 has the lowest priority, and P8 has the lowest priority.

FIG. 11 shows a series of Venn diagrams showing an example of security policy 1031 in FIG. This diagram shows the logical relationship between the three privilege table entries (P1, P5 and P8). The diagram also illustrates the structure of an example security policy 1031 with priority.

FIG. 11 also includes security policy 1031, a two-dimensional Venn diagram 1120, and a three-dimensional diagram 1130. Security policy 1031 contains a record (or instruction set) for priority P1, a record for priority P5, and a record for priority P8. The rules in the priority P1 record (ie 1021) allow "all X word processing apps with a valid certificate". The rule in the priority P5 record (ie, 1024) is "Do not allow any X company apps". The rules in the priority P8 record (ie, 1026) allow all applications to be opened. In some embodiments, a certificate is considered "valid" if its signature is authenticated.

2D Venn diagram 1120 contains three elliptical shapes 1121-1123. 3D diagram 1130 shows the same three ellipses in a three-dimensional fashion. The elliptical 1121 represents the rule of priority P1, the elliptical 1122 represents the rule of priority P5, and the ellipse 1123 represents the rule of priority P8.

In this way, 2D Venn diagram 1120 shows the logical relationship between the three privilege table entries. Within the Venn diagram 1120, elliptical 1123 includes ellipses 1122 and 1121, and ellipse 1122 embraces elliptical 1121. This corresponds to the logical relationship between the rules in the three records. The scope of the P1 rule "All X word processing apps with valid certificates" is a subset of the scope of the P5 rule "X company apps", and the scope of the P5 rule is the P8 rule "All apps". Is a subset of the scope of application.

The 3D diagram shows a mechanism for determining which rule in security policy 1031 should be applied when performing a security evaluation by using the priority field in the authorization table. As shown, the oval 1121 is at the top and corresponds to the highest priority rule (P1) in security policy 1031. The oval 1122 ranks second and corresponds to the second highest priority rule (P5) in security policy 1031. Oval 1123 is at the bottom and corresponds to the lowest priority rule (P8) in security policy 1031. Higher priority rules when higher priority ellipses and lower priority ellipses intersect, much like higher priority ellipses cast shadows on lower priority ellipses. If the lower priority rule intersects with the lower priority rule, the higher priority rule takes precedence over the lower priority rule. The scope of higher priority rules is enabled, puncturing the scope of lower priority rules.

In this way, multiple entries in the authorization table 1000 can be used to create security policy 1031 without logical inconsistencies when performing security evaluations. The question of which rule to use when applying different entries in the authorization table to the same request is solved using priority fields.

Figure 12 shows a series of Venn diagrams that represent an example of another security policy 1231. This diagram shows the logical relationship between the three privilege table entries (P1, P5 and P8). This diagram also illustrates the structure of an example security policy 1231 with priorities. Permission table entries in security policy 1231, unlike permission table entries in security policy 1031, are not necessarily subsets of each other.

FIG. 12 includes security policy 1231, 2D Venn diagram 1220 and 3D diagram 1230. Security policy 1231 includes a record for priority P1 (ie, a set of instructions), a record for priority P5, and a record for priority P8. The rules in the priority P1 record allow "all word processing apps with a valid certificate". The rule in the priority P5 record is "Do not allow any X company products". The rules in the priority P8 record allow all applications with a valid certificate to be opened.

Venn diagram 1220 contains three elliptical shapes 1221 ~ 1223. 3D diagram 1230 shows three identical ellipses in a three-dimensional fashion. The elliptical 1221 represents the rule of priority P1, the elliptical 1222 represents the rule of priority P5, and the elliptical 1223 represents the rule of priority P8.

In this way, the 2D Venn diagram shows the logical relationship between the three privilege table entries. In Venn diagram 1220, the elliptical 1223 contains the elliptical 1221, while the elliptical 1222 overlaps both the elliptical 1221 and 1223. This corresponds to the logical relationship between the rules in the three records. Specifically, the scope of the P1 rule "all word processing apps with a valid certificate" is a subset of the scope of the P8 rule "all apps with a valid certificate". The scope of the P5 rule "Do not allow any X company products" intersects both P1 and P8 records without being a subset or superset of P1 and P8 records.

The 3D diagram 1230 shows a mechanism for determining which rule in security policy 1231 should be applied when performing a security evaluation by using the priority field in the authorization table. As shown, the oval 1221 is at the top and corresponds to the highest priority rule (P1) in security policy 1231. The oval 1222 is the second highest and corresponds to the second highest priority rule (P5) in security policy 1231. The oval 1223 is at the bottom and corresponds to the lowest priority rule (P8) in security policy 1231. Higher priority rules when higher priority ellipses and lower priority ellipses intersect, much like higher priority ellipses cast shadows on lower priority ellipses. When the lower priority rule intersects with the lower priority rule, the higher priority rule takes precedence over the lower priority rule.

In this way, multiple entries in the authorization table can be used to create security policy 1231 without logical inconsistencies when performing security evaluations. The question of which rule to use when applying different entries in the authorization table to the same request is solved by using the priority field. For example, making a request to a word processor manufactured by Company X that has a valid certificate will result in the word processor being approved. This is because the rules for "all word processing apps with valid certificates" have a higher priority than "don't allow any X company products". As another example, the "Do not allow any X company products" rule has a higher priority than "All apps with a valid certificate", so an X company web browser with a valid certificate. Requests to the application are not approved.

For some embodiments, the process 1300 for performing a security assessment using the authorization table is conceptually shown in Figure 13. This process receives a security evaluation request and matches an entry (or record) in the authorization table with the request. The process then performs a security assessment by verifying that the request data object meets the code requirements stored in the authorization table.

Process 1300 begins when it receives a query or request to perform a security assessment (at 1310). This request involves a data object (eg, application program code, installation package, or document to open) that is stored in the authorization table and to which the code requirements apply.

The process then (at 1320) extracts the code sign from the data object. In some embodiments, the signature is extracted from the public key certificate issued by the source of the data object. The process then (at 1325) determines if the extracted signature is authenticated. In some embodiments, a separate module within the security evaluation module performs code signing authentication (eg, code signing verification module). Once the code signing is extracted, the process uses the code signing verification module to check if the code signing was successfully authenticated. If the signature is successfully authenticated, the process proceeds to 1330. If the signature fails to authenticate, process 1300 terminates.

The process then (in 1330) finds the highest priority entry in the authorization table. In some embodiments, process 1300 determines which entry has the highest priority by comparing the priority fields of each entry in the authorization table. The process then (in 1340) determines if an entry was found. In some embodiments, this determination is made by recording which entry has already been examined. No more entries can be found after having already examined all the entries in the authorization table. If the highest priority entry is found, the process proceeds to 1350. If there are no more entries to check in the authorization table, process 1300 terminates.

In 1350, the process extracts the code requirement from the found authorization table entry. The process (in 1360) uses the retrieved code requirements to validate the source of the data object. Such verification may include verification of the vendor ID and the expiration date of the certificate used to generate the signature. The retrieved code requirements also validate other required attributes of the data object, such as the type of data object, the name of the data object, or any other attribute associated with the data object. used. So, for example, if a process can authenticate a signature from a data object, but the code requirements are not met (for example, if the data object is of the wrong type or does not come from a source that is considered reliable. ), The data object can still be rejected by the process.

In that case, the process (in 1370) determines if the code requirements match the query, that is, if it is applicable to the query. Security assessments cannot be based on code requirements that do not apply to the request. In some embodiments, the application of the code requirement up to this point in the process, because sometimes the scope of the code requirement cannot be determined until the process uses the code requirement to process the data object of the request. The range is not checked. In some embodiments, the scope of the code requirements is checked by the process as soon as sufficient information becomes available. If the code requirements match the query (ie, are applicable), the process proceeds to 1390. Otherwise, the process goes to 1380.

In the 1380, the process searches the authorization table for the next highest priority entry. Some embodiments mark the previously inspected entries with higher priority. That way, the entry with the highest priority that is simply unmarked is the entry with the next highest priority. The process then (in 1340) determines if an entry can be found. In that case, the process returns to 1350. Otherwise, process 1300 terminates.

In 1390, the process uses code requirements to determine the action the operation start module should take. In some embodiments, this action is specified in the action (ie, approved or disapproved) field of the matched entry, depending on whether the data object meets the code requirements. After responding to the request, process 1300 terminates.

B. Cache table Performing a security assessment using entries in the authorization table can involve many calculations in some embodiments. The rules that validate the information embedded in the certificate may include computationally intensive operations in some embodiments. Furthermore, it may be necessary to traverse across many entries in the authorization table to complete the search for entries that match the request. For example, it may be necessary to traverse the authorization table completely to ensure that no entry matches the request. Some embodiments save security evaluation time by limiting the execution of the security evaluation operation to only unevaluated data objects. That is, the query is executed against the authorization table only when the application program is started for the first time or when the data file is opened for the first time.

To further accelerate the security evaluation operation, the rule database of some embodiments incorporates a cache table in addition to the authorization table. In some embodiments, the cache table stores the actions required for the data object at an address location indexed by a hash value unique to the data object. For example, you can calculate the hash value of a unique code directory for an application program or data file. Therefore, the requirements for security assessment of running (or installing) an application or opening an archive (discussed in more detail in Section IV below with reference to Figures 24 and 25) are application executable files, installation files. Or you only need to calculate the hash value of the archive. The action (eg, approved or disapproved) is then retrieved from the address location of the cache table pointed to by the hash index value.

Unlike queries on authorization tables, queries on cache tables do not require traversing multiple entries according to rules, nor do they require time-consuming calculations. Therefore, the demand for evaluation of operations on data objects that have corresponding entries in the cache table can be significantly accelerated. In some embodiments, the security assessment request first attempts to find a matching entry in the cache table and then searches the authorization table. A cache table is also called an object table because each entry in the cache table corresponds to one data object (eg, an application executable or document). Because users tend to interact with recently interacted data objects (thus having entries in the cache table), using a cache table can significantly reduce security assessment time.

For some embodiments, a rule database 1400 containing an authorization table 1410 and a cache table 1460 is shown in FIG. The figure also shows examples of cache table entries and the relationship between cache table entries and authorization table entries. In some embodiments, the authorization and cache tables are stored in separate physical storage, while in other embodiments, the authorization and cache tables are stored in a single physical storage. ..

The authorization table 1410 is similar in format and content to the authorization table 900 of FIG. 9 and includes record entries 1421-1423, priority fields 1440, rule fields 1441, and action fields 1442.

The cache table 1460 has three entries 1471 to 1473. Cache table entries, unlike authorization table entries, do not have rule fields. The cache table, on the other hand, has other fields such as hash ID field 1491, expiration field 1492, action field 1493 and reference field 1494.

Entry 1471 in cache table 1460 is based on a data object (Data Object A) that matches entry 1421 in authorization table 1410. Entry 1472 in cache table 1460 is based on a data object (Data Object B) that matches entry 1422 in authorization table 1410. In some embodiments, these cache table entries are created when a security assessment request is made based on data objects A and B. Entry 1473 is based on a data object (Data Object C) that does not match any of the entries in authorization table 1410. If authorization table 1410 fails to bring a matching rule for a security evaluation request for data object C, a negative entry 1473 is created in cache table 1460. As a result, the presence of such negative entries in the cache table prevents an exhaustive search of authorization table 1410 for a long time.

Negative entry 1473 in the cache table does not inherit any fields from the authorization table because it is generated from an object that does not have a matching entry in authorization table 1410. In some embodiments, the negative entry includes an indication that it is a negative entry and that there is no matching entry for that data object in the authorization table 1410. In some such embodiments, the authorization table includes "virtual" entries that are not normally processed but serve as anchors for reference by negative entries in the cache table. That is, the cache record (ie, negative entry) created as a result of determining that no rule is applied is a virtual "unauthorized" rule (ie, virtual entry) stored in the authorization table. Refer to. This is primarily done to ensure the integrity of the data structures and does not affect the visible behavior of these embodiments.

The action field 1493 in the cache table entry records the action actually taken on the data object. This action approves or disapproves the data object based on the application of matching rules stored in authorization table 1410. For example, the action field of entry 1472 in the cache table indicates that object B is "not approved". This indicates that Object B was not approved because the matching rule for Object B (stored in authorization table entry 1422) evaluated Object B as not meeting its code requirements. In this case, retrieving this entry in the cache table with the next request based on object B is also not authorized. That is, the action field 1493 of each cache table entry stores the security evaluation of the data object for that entry.

The expiration field 1492 indicates when the cache entry expired. In some embodiments, the expiration date of a cache table entry for a data object is determined by the content of that data object. Some embodiments use the expiration date of the data object's certificate as the expiration date of the cache entry. For data objects whose signatures are derived from a set of certificates, the earliest revoked certificate expiration date is used in some of these embodiments. In some embodiments, the expiration date is determined by a rule in the authorization table and is inserted into the cache table when an entry in the cache table is created. In some embodiments, the operating system specifies its own expiration date based on information other than the data object certificate. In some embodiments, such information may be vendor-provided defaults, the type of operation requested, or any other information available to the operating system.

In some embodiments, the security evaluation module checks the expiration field of a cache table entry before applying it. Cache table entries that expire based on the expiration date are ignored (and treated as cache misses) by the Security Evaluation Module. This prevents the security evaluation module from making false security evaluations based on currently unused entries in cache table 1460. In some embodiments, expired cache table entries are purged when accessed. Some embodiments include a purge mechanism that periodically checks the cache table for expired entries and removes any expired entries from the table.

The hash ID field 1491 stores the hash value. In some embodiments, the hash ID field of the cache table entry stores the value associated with the hash of the data object of the cache table entry. Some other embodiments do not include this field in the cache table.

In some embodiments, reference field 1494 contains a link to an entry in the authorization table. Specifically, the reference field 1494 of each cache table entry contains a link to the entry in the authorization table used to generate the cache table entry (ie, the rule of that authorization table entry is cached. Used to perform a security assessment of the data object associated with the table entry). For example, the reference field of cache table entry 1471 indicates that cache table entry 1471 is generated from authorization table entry 1421, and the reference field of cache table entry 1472 contains cache table entry 1472 from authorization table entry 1422. Shown to be generated.

Some embodiments use reference fields in the cache table to purge the cache table of entries that are invalid because the authorization table has changed. In some embodiments, the cache table also includes priority fields inherited from the authorization table (not shown). Some embodiments use priority fields in the cache table to purge the cache table of entries that are invalid because the authorization table has changed. Purging cache table entries is described further in Section II-C below with reference to Figure 18.

In some embodiments, the cache table 1460 also includes other fields. Some content of these cache table fields is inherited from the authorization table entry used to create the cache table entry. In some embodiments, the entries in the cache table are not necessarily adjacent to each other. This is because the addresses of those entries are determined by the hash value of the data object used to generate the entry . In some embodiments, the hash value of the data object is generated by performing a hash operation on the data object. In some embodiments, the hash operation produces a hash value that uniquely identifies the data object from any other data object. In some embodiments, the hash operation includes an incremental hash operation. A description of the incremental hashing operation can be found, for example, in US Pat. No. 7,103,779, which is incorporated herein by reference.

In some embodiments, the hash operation includes a hash operation of the code directory. In some embodiments, the code directory hash is a unique value that references every unique entry in the cache table. Therefore, each data object with its corresponding code requirements is uniquely identified in the cache table by a unique code directory hash. A hash of the code directory and a description of its function can be found in US Patent Application Publication No. 2008/0168553, incorporated herein by reference.

In the example in Figure 14, object A's entry (1471) is stored where object A's hash value is indexed, and object B's entry (1472) is where object B's hash value is indexed. The entry for Object C (1473) is stored in the location indexed by the hash value of Object C.

For some embodiments, FIG. 15 shows a security evaluation module 1500 that uses both an authorization table and a cache table for security evaluation purposes based on a request from the operation start module. As shown, the security evaluation module 1500 receives the request from the operation start module 1505 and queries both the authorization table 1510 and the cache table 1515. The security evaluation module 1500 includes a query manager 1520 that executes a query on a permission table and a query manager 1525 that executes a query on a cache table. The security evaluation module 1500 also comprises a processor 1530 and a cache table record generator 1540. The query manager 1520, which queries the authorization table 1510, also includes a rule engine 1550, a record selection module 1560, and a signature verification module 1570.

The operation start module 1505 makes a security evaluation request and waits for the result of the security evaluation to come from the processor 1530 of the security evaluation module. Processor 1530 receives a security evaluation request from operation start module 1505. Based on this received security evaluation request, the processor communicates with both the query managers 1520 (for the authorization table) and 1525 (for the cache table) to determine whether to approve the security evaluation request. The processor also uses the cache table record generator 1540 to generate a new cache entry when there is a cache miss in the cache table 1515. The cache table record generator is also used to generate the address to the physical memory of the cache table 1515 by hashing the data object (ie, program code or document) that is the subject of the request.

The query manager 1525 for querying the cache table provides an interface between the processor 1530 and the physical memory that stores the cache table 1515. The query manager 1520 for querying the authorization table provides an interface between the processor 1530 and the physical memory that stores the authorization table 1510. The query manager 1520 also uses the record selection module 1560 to select and retrieve entries from the authorization table 1510. The retrieved entries are then relayed to the rules engine 1550 for analysis and execution. In some embodiments, the query manager 1520 uses the signature verification module 1570 to verify the code signing of a data object. In some such embodiments, the security evaluation module 1500 returns a disapproval message to the operation start module 1505 if for some reason the code signing cannot be properly authenticated. In some embodiments, the functions of the rules engine 1550, record selection module 1560, and signature verification module 1570 are performed by the processor 1530 instead of the query manager 1520.

The signature verification module 1570 authenticates the code signing of a data object. In some embodiments, the signature verification module authenticates the signature using the information in the public key certificate as well as the content of the data object itself. The signature verification module performs the signature authentication operation according to the signature authentication algorithm identified by the certificate. As soon as the signature verification process is complete, the signature verification module notifies the security assessment module 1500 whether the signature of the data object has been successfully authenticated.

FIG. 16 shows the generation and storage of cache table entries for data objects by the security evaluation module 1600. Specifically, the figure shows the generation of various fields in a cache table entry when a request is made to the security assessment module based on a data object. FIG. 16 shows the operation start module 1620 that makes a request for the data object 1625 to the authorization table 1605, the cache table 1610, and the security evaluation module 1600. The cache table has entries 1611-1613.

The security evaluation module 1600 includes a query manager 1630 for the authority table, a hash module 1650, a memory interface 1660, and an expiration date extraction module 1670. For some embodiments, Query Manager 1630 is similar to Query Manager 1520 in FIG. The functions of the hash module 1650 and the expiration date extraction module 1670 are performed by a processor similar to the processor 1530 in FIG. The security evaluation module 1600 also includes other modules, such as a signature verification module, but is not shown for the purpose of simplifying the diagram.

The operation start module 1620 makes a security evaluation request to the security evaluation module 1600 for an operation that requires the use of the data object 1625 ('data object X'). The data object 1625 is relayed to several modules within the security evaluation module 1600, including the query manager 1630, hash module 1650, and expiration extraction module 1670. Query Manager 1630 finds an entry in permission table 1605 that matches data object 1625. The query manager then applies the rules for the matching entry to determine the appropriate action for the data object 1625. This action, determined by the query manager, forms the action field 1642 for the new cache table entry 1612.

Hash module 1650 receives the data object 1625 and performs a hash operation on the received data object. In some embodiments, the hash operation is an incremental hash operation. Hash module 1650 has a unique code directory hash value of 1655 that acts as an index ('index for X') to specify the location of the newly created cache table entry for data object X in the cache table. Generate. The memory interface 1660 then uses this value as the physical address for the cache table. In some embodiments, the hash value of this uniquely generated code directory is stored in the hash ID field of entry 1612 for data object X.

The expiration date extraction module 1670 also receives the data object 1625 and calculates or extracts the expiration date from the data object 1625. In some embodiments, the expiration date of the data object is specified by the certificate used to create the signature of the data object. A data object may derive its signature from more than one certificate, or even a set of certificates. Some embodiments use the earliest expiration date of these certificates as the expiration date of the cache table entry. The extracted expiration date will be the expiration date field 1675. In some embodiments, the expiration date extraction module 1670 uses other information as a criterion for determining the expiration date. In some other embodiments, the expiration field 1675 is inherited from the authorization table and is not calculated by the expiration extraction module 1670.

The action field 1642 and the expiration field 1675 are concatenated together to form a new cache table entry 1612 for data object X with the hash ID field and reference field for data object X. The cache table 1610 has two other entries for the other two objects (entry 1611 for data object Y and entry 1613 for object Z).

In some embodiments, the contents of the cache table may be shared by different computers running similar operating systems. A computer can import a cache table generated by another computer or a pre-packaged cache table supplied by an operating system vendor. Computers that use such pre-filled cache tables can immediately accelerate their security evaluation operations without having to generate their own cache entries.

For some embodiments, Figure 17 conceptually shows process 1700, which uses both the authorization table and the cache table to perform security assessments. The process first attempts to find a matching entry in the cache table. If the process cannot find such an entry in the cache table (ie, a cache miss), it instead queries the authorization table to find a matching entry. When a query is executed against the authorization table, a new entry is generated in the cache table as a result. In some embodiments, this process is performed by the operating system security assessment module.

Process 1700 is started when an operation is requested by the operation start module (for example, running an application, installing an application, or opening a document). The process receives this request (in 1710), along with the data objects needed for the requested operation.

The process then determines (in 1720) the hash value for the data object (ie, the hash value of the unique code directory). In some embodiments, the hash value is calculated by an incremental hash operation. The calculated hash value acts as an index for placing entries in the cache table for the data object. The process then uses the hash value (at 1730) to determine if a cache table entry can be found. This determination is based on, in some embodiments, whether there is a valid entry stored at the location pointed to by the hash value. In some of these embodiments, each cache table entry is associated with a bit indicating whether the cache table entry is valid. If no cache entry has been entered for the data object, or if the cache table entry has been purged and no new cache entry has been entered, the cache table entry will be invalid. If the process can find a valid entry using the hash value of the data object (cache hit), the process proceeds to 1740. Otherwise (cache miss), the process goes to 1750.

At 1740, the process determines the response to a security evaluation request based on the content of the matching cache table entry. The process then determines (in 1780) whether the response is an approval of the requested operation. If the response approves the operation, the process proceeds to 1790, where the operation start module passes the request to an operation handler such as execution module 172, installation module 170, or content opening module 174 in Figure 1. If the response does not approve the operation, the operation start module prevents the request from being passed to the operation handler and stops the operation from continuing. Process 1700 terminates after responding to the operation start module based on the contents of the cache table entry.

In 1750, the process queries the authorization table because of a cache miss in the cache table. In some embodiments, this operation is performed by process 1300 in FIG. This process 1300 searches the authorization table for entries that match the request.

The process then determines (in 1755) whether it was able to find a matching entry in the authorization table. In that case, the process proceeds to 1760. Otherwise, the process goes to 1770, creates a negative cache entry for the data object, and then exits. As mentioned above, the negative cache entry for the data object allows the security assessment module to immediately verify that the operating system's security policy does not have rules applicable to a particular request.

At 1760, the process determines the response from the matching entries in the authorization table. The process then creates a new entry in the cache table based on this matching entry in the authorization table (in 1765). The process then proceeds to 1780 to determine whether the requested operation should be approved or disapproved. Process 1700 exits after responding to the operation start module based on the contents of the authorization table entry.

C. User override In some embodiments, a fully privileged user is allowed to make changes to the rules database by adding, deleting, or modifying entries in the authorization table. For example, a user with administrator privileges can bypass signature authentication to run a particular application. A user can do this bypass by adding a higher priority entry to the authorization table that takes precedence over a lower priority rule, thereby allowing the execution of a particular application.

On the other hand, as shown in Figure 10 above, security policies often include several table entries that are linked together on a priority basis. Therefore, in order to evaluate data objects under a security policy, these table entries must be examined in the order indicated by their priority. When performing some security evaluation on a data object, the lower priority rule can be applied only when the higher priority rule cannot be applied. Therefore, if any changes are made to the higher priority rules, the scope of the lower priority rules may change.

Since the cache table contains cache entries that reflect the scope of the rule before the authorization table was changed, in some embodiments, when the authorization table of a particular priority is modified, Purging all entries in the cache table that have the same or lower priority is triggered. For example, if a new authorization table entry has a priority value of 2.3, purging all entries in the cache table that have a priority equal to or lower than 2.3 is triggered. In some embodiments, this purge process uses a reference field within each cache table entry (eg, 1494 in Figure 14) to determine the priority of the authorization table entry used to create the cache table entry. To do. In some other embodiments, each cache table entry holds a priority field inherited from the authorization table for this purpose.

In some embodiments, the negative cache entry is assumed to have the lowest priority. Negative entries are cache table entries for data objects that have no matching entries in the authorization table, so any changes to the authorization table can affect the data object for negative entries (ie,). If the permissions are changed, the data object will now have matching entries in the permissions table, thus invalidating negative entries). In some of these embodiments, negative cache entries are purged whenever any changes to the authorization table are made.

For some embodiments, FIG. 18 conceptually shows the process by which the administrator user maintains and manages the rule table after modifying the rule database. This process purges lower priority entries from the cache table. Process 1800 is started when a privileged user (eg, an administrator) makes changes to the rules database. This process receives a rule change from a privileged user (in 1810) and determines if the rule change is for a rule that already exists in the authorization table (in 1820). If the rule change is for a rule that already exists in the authorization table, the process proceeds to 1840 and updates the authorization table entry. Otherwise, the process goes to 1830 and creates a new entry in the authorization table.

The process then determines if there are entries in the rules database that have a lower priority than the newly added or updated rules (in the 1850). If there is an entry, the process proceeds to 1860. Otherwise, process 1800 ends.

In 1860, the process deletes all lower priority entries in the cache table. In some embodiments, the process examines all entries in the cache table and purges all entries that have the same or lower priority than the newly added or updated authorization table entries. Process 1800 terminates after all lower priority cache table entries (including any negative entries) have been deleted.

III. Security evaluation of downloaded content Some of the above embodiments use certificates embedded within the data objects to perform a security assessment on these data objects. In most cases, these methods rely on the ID provided by the source of these data objects (eg, the signature in the certificate and the vendor ID). However, these source-provided IDs are not always available or reliable. Therefore, in addition to or instead relying on these source-provided identifiers for the purpose of performing security evaluations, some embodiments of operating systems provide their own IDs for data objects. .. In some of these embodiments, the operating system associates tags with data objects imported from external sources such as the Internet, USB flash drives, or any other peripheral interface of the device. The tag contains a quarantine bit that indicates that the data object comes from an external source. The presence of the quarantine bit further indicates that the system is not performing a security assessment on the data object. Once the operating system performs a security assessment on the data object, the tags are updated (for example, by removing the quarantine bit), the data object has already been evaluated under the operating system's security policy, and the data object. Indicates that the operating system security policy has been (or has not been) passed.

Figure 19 conceptually illustrates a computer 1900 with an operating system that uses its own identifier to perform security assessments. Specifically, the computer 1900 operating system adds tags or quarantine bits to content and / or applications downloaded from the Internet, for example. The computer 1900 includes a storage device 1910, a tag module 1920, an application 1930 currently running on the computer 1900, a network interface 1940, and a user interface (UI) module 1950. The UI module 1950 controls communication with the user via the input device driver 1960 and the display module 1970.

The network interface 1940 provides a communication interface between the computer 1900 and the outside world over a network. The network allows computers 1900 to communicate via the Internet 1980 and access data objects such as application files 1981-1982 and content files 1983-1984 from other computers. These content files can be text files, word processor documents, spreadsheets, media files, and so on. Application files can include installation and program files. These applications and content files can then be downloaded to the computer 1900. Although not shown in the figure, the computer 1900 can also download data objects from external sources other than the Internet (such as external flash drives).

Application 1930 is a set of programs or processes currently running on computer 1900 through an operating system. Application 1930 can be an internet browser, a word processor, a video game, a media editing application, or any program that can run on computer 1900. Application 1930 can perform operations that require communication over the Internet, including downloading data objects 1981-1984 from sources on the Internet via a network interface. Once the file has been downloaded, application 1930 stores the downloaded file in storage 1910. In some embodiments, the downloaded file must pass through tag module 1920 before being stored.

Tag module 1920 associates each downloaded file with a tag. In some embodiments, such tags include a quarantine bit indicating that the downloaded file comes from an external source and has not been inspected under the operating system's security policy. In some embodiments, the tag module inserts or adds tags to the downloaded file. In some embodiments, the tag module maintains a tag table that records which files come from the Internet or other external sources. Other processes or modules running on your computer can access the tag table to see which files or data objects are tagged as coming from an external source such as the Internet. In some embodiments, tagging of a file from an external source is done as soon as the file is downloaded by application 1930 and before the file is stored in storage 1910.

Storage device 1910 stores various data objects for computer 1900. These data objects may include content and application files downloaded from the Internet or other external sources. In some embodiments, these downloaded applications and content files are associated with tags supplied by the tag module 1920.

Once the downloaded file is stored and tagged, the operating system can perform a security assessment based on a security policy that considers whether the data object has been downloaded. FIG. 20 shows an operating system 2000 that requires a tag or quarantine bit presence check during a security evaluation operation. Specifically, the operating system 2000 provides a mechanism for identifying whether a data object is tagged before a security evaluation operation is performed. The security evaluation operation is similar to the security evaluation operation described in Sections I and II above.

As shown, the operating system 2000 includes an operation request module 2005, a security evaluation module 2020, a rule database 2030, and an operation start module 2010. The operation start module includes a processor 2040 and a tag identification module 2050. The operating system also includes installation module 2060 and module 2070 that opens content.

In some embodiments, the operating system 2000 is similar to the operating system 100 of FIG. Specifically, the operation request module 2005 requests the operation start module 130 to execute the operation, similarly to the operation request module 140. Like the installation module 170 and the content-opening module 174, the installation module 2060 and the content-opening module 2070 are operation handlers that receive approved requests and perform approved operations.

The security evaluation module 2020 and the rule database 2030 perform the same operations as the security evaluation module 110 and the rule database 120 shown in FIG. The functions of the security evaluation module and rule database are also described in Section II above with reference to Figures 7-17. For example, in some embodiments, the rules database 2030 includes both an authorization table and a cache table. In some embodiments, the security evaluation module 2020 performs a security evaluation of the tagged object based on user input. For example, does Security Evaluation Module 2020 notify the user that the requested operation contains downloaded objects as soon as it receives a request to evaluate the tagged objects and continue with risk awareness? Ask the user if.

The operation start module 2010, like the operation start module 130, enforces the operating system security policy by allowing or prohibiting the execution of specific operations. The operation start module 2010 receives a specific operation request from the operation request module 2005 and requests the security evaluation module 2020 to evaluate the requested operation under the security policy of the operating system 2000. On the other hand, unlike the operation start module 130 in FIG. 1, the operation start module 2010 checks whether the data object for the requested operation is tagged as coming from the Internet or any other external source. .. Data objects tagged as coming from an external source (eg, tagged with quarantine bits) are subject to security assessment. In order to avoid repetitive security evaluations for data objects that have already been evaluated, some embodiments update the tags after the security evaluations to indicate that the data objects have already been evaluated. In some embodiments, this is achieved by removing the isolation bit. In some embodiments, the updated tag also indicates whether the data object passed or failed the previous security assessment.

In the example of FIG. 20, the tag identification module 2050 inside the operation start module 2010 checks the tags and reports to the processor module 2040. In the operating system 2000, the security evaluation module 2020 does not perform its security evaluation based on the tag. It is the processor 2040 in the operation start module 2010 that uses the tag to determine whether to continue processing the requested operation. In some of these embodiments, the operation initiation module 2010 only if the data object associated with the requested operation is tagged as originating from an external source and has never been evaluated. Continues the security evaluation process. If the data object is not so tagged (for example, if the isolation bits have been removed, or if the data object has already been tagged as previously evaluated), the operation start module 2010 Do not require the security evaluation module to perform a security evaluation.

Figures 21-22 show the data flow in operating system 2000 when a security assessment is performed using the operation start module that identifies the tags in the data object. As shown in FIG. 20, the operating system 2000 of FIGS. 21 to 22 includes the security evaluation module 2020, the rule database 2030, the operation start module 2010, the operation request module 2005, the installation module 2060, and the module 2070 for opening the contents. ,including.

Figure 21 shows the data flow of an operation that installs an application within Operating System 2000. When a request is made to the operation start module 2010 to install the application X (operation '1'), the operation is started in the operation request module 2005. Processor 2040 then sends a command to tag identification module 2050 asking if application X is tagged (operation '2'). If application X is tagged as originating from an external source (eg, having an isolation bit), the processor will perform a security assessment when the tag identification module 2050 sends a confirmation to processor 2040 (operation '3'). Require security assessment module 2020 to perform (operation '4'). On the other hand, if application X is untagged, or if application X is tagged as previously evaluated (or the quarantine bit removed), processor 2040 in some embodiments is security. Does not require evaluation module 2020 to perform a security evaluation. In some embodiments, if application X is tagged as having failed a previous security evaluation, processor 2040 may terminate the installation process immediately without involving security evaluation module 2020. Conversely, if application X is tagged as having passed the previous security evaluation, processor 2040, in some embodiments, does the processing without involving security evaluation module 2020. You can immediately allow it to continue.

When a security evaluation request is made, the security evaluation module 2020 queries the rule database 2030 (operation '5'). Rule database 2030 supplies the rules or instructions in that database to security evaluation module 2020 (operation '6'). This query process between Security Evaluation Module 2020 and Rule Database 2030 continues until a matching rule is found in the rules database or it is determined that no applicable rule exists in the rules database. Ru.

Once a matching rule is found, Security Evaluation Module 2020 applies the matching rule to the data objects associated with the application X installation. After that, the security evaluation is returned to the operation start module 2010 (operation '7'). In the example of FIG. 21, the communication content from the security evaluation module to the operation start module was found to conform to the security policy stored in the rules database for the data object related to the installation of application X, so application X It shows that there is no problem even if you install.

As soon as application X learns that it has passed the security evaluation performed by security evaluation module 2020, processor 2040 determines whether to continue the process of installing application X. In addition to the security evaluation performed by the security evaluation module, in some embodiments, processor 2040 considers whether application X is tagged. If the processor decides that it is okay to continue with the application X installation process, it sends a command to the installation module 2060 to launch the application X installation (operation '8'). The dotted line around module 2070 that opens the content indicates that this module is not involved in this operation.

FIG. 22 shows a data flow diagram of a document opening operation in operating system 2000. When the operation start module 2010 is requested to open the data file X (operation '1'), the operation is started in the operation request module 2005. Processor 2040 then sends a command to tag identification module 2050 asking if datafile X is tagged (operation '2'). If the datafile X is tagged as originating from an external source (eg, having an isolation bit), the tag identification module 2050 sends a confirmation to processor 2040 (operation '3') and the processor performs a security assessment. Request security assessment module 2020 to do (operation '4'). On the other hand, if the data file X is untagged, or if the data file X is tagged as previously evaluated, in some embodiments the processor 2040 is secure against security evaluation module 2020. Do not require the evaluation to be carried out. In some embodiments, if data file X is tagged as having failed a previous security evaluation, processor 2040 immediately terminates the process of opening the file without involving security evaluation module 2020. it can. Conversely, if the datafile X is tagged as having passed the previous security assessment, in some embodiments the processor 2040 will populate the datafile without involving the security assessment module 2040. You can immediately allow the opening to continue.

If a security evaluation request is made, the security evaluation module 2020 then queries the rules database 2030 (operation '5'). Rule database 2030 supplies the rules or instructions in that database to security evaluation module 2020 (operation '6'). This query process between Security Evaluation Module 2020 and Rule Database 2030 continues until a matching rule is found in the rules database or it is determined that no applicable rule exists in the rules database. ..

Once a matching rule is found, Security Evaluation Module 2020 applies the matching rule to the data object associated with opening datafile X. Then, the security evaluation is returned to the operation start module 2010 (operation '7'). In the example in Figure 22, datafile X has been found to comply with the security policy stored in the rules database, so the communication returned from the security evaluation module to the operation start module opens datafile X. It shows that there is no problem.

Processor 2040 determines whether to continue opening datafile X as soon as it learns that datafile X has passed the security assessment performed by security assessment module 2020. In addition to the security evaluation made by the security evaluation module, in some embodiments the processor 2040 also considers whether the data file X is tagged. If the processor decides that it is okay to proceed to open datafile X, the processor sends a command to module 2070 to open the content and initiates opening datafile X (operation '8'). The dotted line around the installation module 2060 indicates that the installation module 2060 is not involved in this operation.

Figures 20-22 show operating system 2000 with an operation start module 2010 that determines if a data object is tagged as coming from an external source such as the Internet. The operating system 2000 operation start module 2010 also determines based on tags whether the operation should continue. The rules stored in the rules database do not consider or process tags. On the other hand, in some other embodiments, the operating system rules database contains rules that identify tags and perform security assessments based on the identified tags.

For some embodiments, FIG. 23 shows an operating system 2300 comprising a rules database containing rules for processing tags associated with downloaded data objects. In some such embodiments, the operation start module does not check the tag of the data object associated with the requested operation. Like Operating System 2000, Operating System 2300 includes Operation Request Module 2305, Security Evaluation Module 2320, Rule Database 2330, and Operation Initiation Module 2310. The operating system also includes an installation module 2360 and a module 2370 that opens content.

The operation start module 2310 receives an operation request from the operation request module 2305 and makes a security evaluation request to the security evaluation module 2320. On the other hand, unlike the operation start module 2010, the operation start module 2310 does not check the download tag.

The security evaluation module 2320 receives a security evaluation request from the operation start module 2310, queries the rules database, and searches for a rule that matches the data object associated with each security evaluation request.

The rules database 2330 stores rules for performing security evaluations. Also, rule database 2330, unlike rule database 2030, contains rules for analyzing data objects to see if they are tagged. If the data object is tagged, some embodiments then apply the rules in the rules database to perform a security evaluation on the data object and approve / disapprove the requested operation. Proceed to. As mentioned earlier in Section II, in some embodiments, the rule database 2330 includes both an authorization table and a cache table. For example, a data object that was disapproved in a previous security evaluation because it has a quarantine bit may have a cache entry with an action field that disapproves the data object.

IV. Document Security Evaluation The signature that identifies the source of the data object is partially derived based on the content of the data object, so the signature can be used to determine if the data object has been tampered with. This also means that data objects whose content is often modified by the user (eg, documents) cannot have their own signature. The data file, on the other hand, can be placed in a structure (eg, an archive) that can hold the certificate, including the signature. By using such a signature, the source of the data file in the structure can be safely identified. In some embodiments, the operating system includes a rule in the rules database that approves or disapproves a document or data file based on the identity of the certificate embedded in the archive structure. Some of these embodiments consider documents in approved archives to be approved as well.

FIG. 24 shows a computer 2400 that receives and stores a data archive with a certificate. You can then safely identify the source of the content in the archive by using a (signed) certificate with the computer 2400 operating system. As shown, the computer 2400 includes a storage device 2410, an application 2430 currently running on the computer 2400, a network interface 2440, and a user interface (UI) module 2450. The UI module 2450 controls communication with the user via the input device driver 2460 and the display module 2470.

The network interface 2440 provides a communication interface between the computer 2400 and the outside world via a network. By using the network, the computer 2400 can communicate via the Internet, and other computers can access data objects such as data archives 2481 to 2484. The contents of these archives can be text files, word processor documents, spreadsheets, media files, and so on. The contents of these archives can also be executable applications or application installation files. Some or all of these data archives have signed certificates that identify their sources. A data archive can include one content (such as data archive 2481) or multiple contents or files (such as data archive 2484). Although not shown in the figure, the computer 2400 can also access the data archive from other computers via other data communication means such as an external flash drive.

Application 2430 is a program or set of processes currently running on computer 2400 through the operating system. Application 2430 can be an internet browser, word processor, video game, media editing application, or any program that can run on computer 2400. Application 2430 can perform operations that require communication with the Internet, including downloading data archives 2481-2484 from the Internet via network interface 2440.

Once the data archive has been downloaded, the downloaded file is stored in storage 2410 by application 2430. The operation of storing the data archive in storage 2410 is similar to the operation of storing tagged or quarantined data, as described above with reference to FIG. A data archive is stored in the storage device 2410. Once the data archive is stored, the operating system can perform a security assessment by authenticating the signature and examining the certificate embedded within the data archive.

Figure 25 shows an operating system whose rules database contains rules for performing security assessments on data files or documents based on certificates in the data archive. Specifically, Figure 25 shows an example of a request to open a data file within operating system 2500. The data file is embedded in the data archive.

The operating system 2500 includes an operation request module 2505, a security evaluation module 2520, a rule database 2530, an operation start module 2510, and a content opening module 2570. Operating system 2500 can also access storage device 2560, which contains several data archives, including data archive 2580. In some embodiments, the storage device 2560 comprises the storage device 2410 of FIG. The storage device 2410 stores data archives downloaded from the Internet or other external sources.

In some embodiments, the operating system 2500 is similar to the operating system 100 of FIG. Specifically, the operation request module 2505 requests the operation start module 2510 to execute the operation, similarly to the operation request module 140. The operation start module 2510 receives a request from the operation request module 2505 and requests the security evaluation module 2520 to perform a security evaluation. In the example shown in FIG. 25, the request is a request to open a document or data file embedded in the data archive 2580. The operation start module 2510 makes a request to the security evaluation module 2520 by passing the data archive 2580 to the security evaluation module. Once the operation start module 2510 receives the response from the security evaluation module 2520, it activates the content opening module 2570 or terminates the requested operation based on the security evaluation.

The security evaluation module 2520 and the rule database 2530 perform the same operations as the security evaluation module 110 and the rule database 120. In some embodiments, the rule database has both an authorization table and a cache table, as described in Section II above with reference to FIGS. 7-17. To securely identify the source of a data file or document, Security Evaluation Module 2520 authenticates signatures before applying the rules stored in Rule Database 2530.

The content opening module 2570 is similar to the content opening module 174 in Figure 1. Once the start command is received from the operation start module 2510, the content open module 2570 proceeds to open the requested data file. In the example of FIG. 25, the data file requested to be opened in the data archive 2580 is stored in the storage device 2560. In some embodiments, to open the data file, the content opening module 2570 extracts the data file from the archive structure and then (eg, sends the data file to the application needed to open the data file). Open the data file (by doing).

For some embodiments, the process 2600 that performs a security assessment of the document opening operation is conceptually shown in Figure 26. Specifically, Process 2600 is performed by the operating system for the purpose of making security assessment decisions based on the signed certificate embedded in the data archive.

Process 2600 is started when it receives a request to open a data file (or document). The process (in 2610) receives the document requested to open. The process then (in 2620) determines if the document is of a safe type. In some embodiments, documents or files of a type that are unlikely to harm the computer are allowed to be opened, regardless of their source. For example, text files are considered secure and do not require signatures or identification of other sources. If the document is considered to be of a safe type, the process proceeds to 2670 and passes the document to an operation handler (such as module 2570, which opens the content in Figure 25). If the document is not considered a safe type, the process proceeds to 2630. In some embodiments, executable documents are not considered secure. Such, because in some embodiments, certain types of non-executable documents can retain malicious code that can harm the computer through the application that opens and uses those documents. Source validation for non-executable documents is also required.

The process then (at 2630) determines if the document is in the archive. As mentioned above, some data files or documents do not have a signature that identifies the source, but the data file can be placed within an archive structure that holds the signature. On the other hand, in some embodiments, certain documents may contain their own signature without being archived (eg, a document that is rarely modified has a signature that checks if the file has been tampered with. Can hold). If the document is not in the archive, process 2600 goes to 2650. Otherwise, the process proceeds to 2640 and performs a security assessment of the document on its own.

In 2640, the process performs a security evaluation based on the document's own certificate. The operation involves authenticating the signature of the document embedded within the certificate of the document, as well as additional security assessments based on other information in the certificate. In some embodiments, the process queries the rules database to find matching rules that can be used to perform a security assessment on a document. This operation involves applying code requirements to the document in some embodiments. Code requirements can include instructions for examining the certificate embedded in the document and checking if the source is trusted. After performing a security assessment, the process decides whether to approve the document to open based on matching rules (in 2660). In that case, the process (in 2670) passes the document to an operation handler (such as module 2570, which opens the content in Figure 25) to open it. Otherwise, the process ends.

At 2650, the process performs a security assessment based on the certificate of the archive. This operation includes authenticating the signature embedded within the archive's certificate, as well as additional security assessments based on other information in the certificate. In some embodiments, the process queries the rules database to find matching rules that can be used to perform a security assessment on the archive. In some embodiments, this operation involves applying code requirements to the archive. Code requirements can include instructions that examine the certificate in the archive to check if the source is trusted. The process then determines (in 2660) whether to approve the archive and even all documents in the archive to open it, based on matching rules. In that case, the process passes the document (in 2670) to an operation handler (such as module 2570, which opens the content in Figure 25). Otherwise, the process ends.

V. Electronic system Many of the aforementioned functions and applications are implemented as software processes designated as instruction sets recorded on a computer-readable storage medium (also called a computer-readable medium). When these instructions are executed by one or more compute or processing units (eg, one or more processors, processor cores, or other processing units), those instructions are indicated to the processing units. Perform the action taken. Examples of computer-readable media include CD-ROMs, flash drives, random access memory (RAM) chips, hard disks, erasable programmable read-only memory (EPROM), and electrically erasable programmable read-only memory (EEPROM). However, it is not limited to these. Computer-readable media do not include carrier and electronic signals that travel wirelessly or by wired connection.

As used herein, the term "software" includes firmware stored in read-only memory or an application stored in magnetic storage that can be read into memory for processing by a processor. Also, in some embodiments, the plurality of software inventions may be implemented as subdivisions of a larger program, leaving the separate software inventions intact. In some embodiments, multiple software inventions can also be executed as separate programs. Finally, any combination of separate programs that execute the software inventions described herein together is within the scope of the invention. In some embodiments, a software program defines one or more specific machine implementations that perform the actions of the software program when installed to run on one or more electronic systems.

FIG. 27 conceptually illustrates an electronic system 2700 in which some embodiments of the present invention are realized. The electronic system 2700 may be a computer (eg, desktop computer, personal computer, tablet computer, etc.), telephone, PDA, or other type of electronic device. Such electronic systems include interfaces for various types of computer-readable media, as well as various other types of computer-readable media. The electronic system 2700 includes a bus 2705, a processing unit 2710, a graphics processing unit (GPU) 2715, a system memory 2720, a network 2725, a read-only memory 2730, a permanent storage device 2735, an input device 2740 and an output device 2745.

Bus 2705 collectively represents all system buses, peripheral buses, and chipset buses that communicatively connect a large number of internal devices of the electronic system 2700. For example, bus 2705 connects the processing unit 2710 communicably with read-only memory 2730, GPU2715, system memory 2720, and permanent storage 2735.

From these various memory units, the processing unit 2710 searches for instructions to be executed and data to be processed in order to execute the process of the present invention. The processing unit may be a single processor or a multi-core processor in different embodiments. Some instructions are passed to GPU2715 and executed by GPU2715. The GPU2715 can offload various computations and complement the image processing provided by the processing unit 2710. In some embodiments, such functionality may be provided using Core Image's kernel shading language.

Read-only memory (ROM) 2730 stores static data and instructions required by the processing unit 2710 and other modules of the electronic system. On the other hand, the permanent storage device 2735 is a read / write memory device. This device is a non-volatile memory unit that stores instructions and data even when the electronic system 2700 is off. Some embodiments of the present invention use a large capacity storage device (such as a magnetic or optical disk and its corresponding disk drive) as the permanent storage device 2735.

Other embodiments use removable storage devices (floppy disks, flash memory devices, etc., and their corresponding disk drives) as permanent storage devices. Like the permanent storage device 2735, the system memory 2720 is a read / write memory device. However, unlike the storage device 2735, the system memory 2720 is a volatile read / write memory such as a random access memory. The system memory 2720 stores some of the instructions and data required by the processor during execution time. In some embodiments, the process of the invention is stored in system memory 2720, permanent storage 2735, and / or read-only memory 2730. For example, various memory units include instructions for processing multimedia clips, according to some embodiments. From these various memory units, the processing unit 2710 extracts the instructions to be executed and the data to be processed to execute the process of some embodiment.

Bus 2705 also connects to input device 2740 and output device 2745. The input device 2740 allows the user to transmit information to the electronic system and select commands. Input devices 2740 include alphanumeric keyboards and pointing devices (also referred to as "cursor control devices"), cameras (eg, webcams), microphones that receive voice commands, or similar devices. The output device 2745 displays the image generated by the electronic system or outputs the data in other ways. Output devices 2745 include display devices such as printers, cathode ray tubes (CRTs) or liquid crystal displays (LCDs), as well as speakers or similar audio output devices. Some embodiments include devices such as touch screens that act as both input and output devices.

Finally, as shown in FIG. 27, the bus 2705 also connects the electronic system 2700 to the network 2725 via a network adapter (not shown). Thus, a computer can be part of a computer's network (eg, a network of networks such as a local area network (LAN), a wide area network (WAN), an intranet, or the Internet. Any or all components of the electronic system 2700 may be used in the present invention.

Some embodiments include electronic configurations such as storage devices and memory that store computer program instructions on a microprocessor, machine-readable or computer-readable medium (also referred to as a computer-readable storage medium, machine-readable medium or machine-readable storage medium). Contains elements. Some examples of such computer-readable media include RAM, ROM, read-only compact discs (CD-ROMs), write-once compact discs (CD-R), rewritable compact discs (CD-RW), and read-only compact discs. Multipurpose discs (eg DVD-ROM, dual layer DVD-ROM), various recordable / rewritable DVDs (eg DVD-RAM, DVD-RW, DVD + RW, etc.), flash memory (eg SD card, mini) SD cards, micro SD cards, etc.), magnetic and / or solid state hard disks, read-only recordable Blu-ray® discs, ultra-high density optical discs, any other optical or magnetic media, and floppy discs. .. A computer-readable medium may be run by at least one processing unit and may contain a computer program containing an instruction set for performing various operations. Examples of computer programs or computer code include machine code as created by a compiler, and files containing high-level code executed by a computer, electronic component, or microprocessor using an interpreter.

The above discussion primarily refers to microprocessors or multi-core processors running software, but some embodiments include application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). Performed by one or more integrated circuits. In some embodiments, such an integrated circuit executes instructions stored in the circuit itself. In addition, some embodiments run software stored in a programmable logic device (PLD), ROM, or RAM device.

As used herein and in this application, the terms "computer," "server," "processor," and "memory" all refer to electronic or other technical equipment. These terms do not include people or groups of people. By definition, the term "display or display" means display on an electronic system. As used in this specification and in the claims of this application, the terms "computer-readable medium", "computer-readable medium", and "machine-readable medium" are tangible physical materials that store information in a computer-readable format. Completely restricted to objects. These terms exclude wireless signals, wired downloaded signals, and other interim signals.

Having described the invention in a number of specific details, one of ordinary skill in the art will appreciate that the invention can be practiced in other particular forms that do not deviate from the spirit of the invention. In addition, at least some figures (including FIGS. 2, 3, 13, 13, 17, 18 and 26) conceptually illustrate the process. The specific operations of these processes do not have to be performed in the exact order shown and described. The specific operation does not have to be performed in one continuous series of operations, and various specific operations may be performed in different embodiments. In addition, the process may be carried out using several subprocesses or as part of a larger macro process. Thus, one of ordinary skill in the art will appreciate that the invention is not limited by these exemplary details, but is defined by the appended claims.