Method and system for verifying integrity of a ruleset database

Abstract

A method is proposed for checking the integrity of a rule set database (2) before execution of an application (4), wherein one or more execution authorizations of one or more applications (4) are stored in the rule set database (2), wherein the rule set database (2) also has rules of the one or more applications (4), wherein the method comprises: before execution of the application (4), calling (S2) the execution authorization of the application (4) to be executed from the rule set database (2) by the execution unit (6) and checking (S4) the execution authorization, if the check (S4) of the execution authorization of the application (4) to be executed by the execution unit (6) is positive, comparing (S12) the stored checksum (10) of the rules of the application (4) stored in the rule set database (2) with the current checksum of the rules of the application (4) stored in the rule set database (2) by the application (4), and if the stored checksum (10) is consistent with the current checksum, starting (S13) the application (4). The application (4) queries (S9) the rules assigned to the application (4) to be executed from the rule set database (2) via an intermediate connected proxy. Thus, not only the authenticity and integrity of the application can be checked, but also the rules stored for the application.

Description

Technical Field

[0001] This invention relates to a method for verifying the integrity of a rule set database before executing an application. Furthermore, this invention relates to a system for verifying the integrity of a rule set database before executing an application. Additionally, this invention relates to a computer program product that causes the implementation of the method described above on a programmably controlled device. Background Technology

[0002] To prevent software or applications on a system from being modified or additionally installed during unauthorized installations after their initial creation, and to ensure that software or applications on a system can only be executed by specific user groups, so-called application whitelisting solutions exist. These are part of or integrated into the operating system. With such solutions, execution rules can be configured in both audit mode and enforcement mode, and stored in an application whitelist rule set database. These execution rules allow and / or prohibit the execution of specific programs based on predefined framework conditions (e.g., specific users). Execution rules can reference the program to be executed by storing its path, signature, or hash value. Combinations of the above three criteria are also possible.

[0003] One issue here is that the software or application delivered and installed may subsequently be extended by the OEM manufacturer and end users by installing their own software components. However, the problem arises because both the end user's administrator and the OEM manufacturer themselves must have administrative privileges on the system to perform the necessary activities, and therefore gain access to a database of application whitelist rules stored locally on the system.

[0004] Access to the application whitelist rule set database described above cannot be restricted when granting administrative privileges. Therefore, the rule set stored there by the original creator, which defines the authenticity and integrity of the creator's own software and the execution permissions of specific user groups, is no longer protected and can be arbitrarily modified, for example, by the end-user's administrator or the OEM manufacturer.

[0005] As mentioned above, access to the application whitelist rule set database can only be restricted when a user does not have administrative privileges. However, in most cases, installing other software requires these privileges, thus necessitating trust with end-customer administrators or OEM manufacturers who do not modify execution permissions within the application whitelist rule set database.

[0006] US 2020 / 272742A1 discloses a method for calculating checksums of multiple security application rule sets on a client device, which obtains the checksums from a server. Here, the verification of execution permissions and checksums is performed during application execution.

[0007] US 2011 / 029772A1 discloses the use of multi-level rule sets that are protected by signatures. The signatures of the rule sets (and therefore their checksums) are verified when these rule sets are loaded.

[0008] US 2015 / 019857A1 discloses checks on application and rule set signatures to allow applications to tighten parameters on mobile devices during execution. Both signatures are verified through checksums and certificate chains. Summary of the Invention

[0009] In this context, the object of the present invention is to provide a possibility in which an application manufacturer can assign specific execution permissions and restrictions on a system to ensure integrity and authenticity, but allow users with administrative privileges to make further adjustments in subsequent processing steps, while simultaneously identifying when these users made unauthorized adjustments in these subsequent processing steps.

[0010] Therefore, a method is proposed for verifying the integrity of a rule set database before executing an application, wherein the rule set database stores one or more execution permissions for one or more applications, and the rule set database also contains rules for the one or more applications.

[0011] Such a rule set database is also known as an application whitelist rule set database. It stores execution permissions that can be verified in the first step by the operating system or its execution unit (e.g., the kernel or core). Software or application manufacturers can include the application whitelist rule set database with the application when it is delivered.

[0012] In this context, an application should be understood as a program or software that is stored on and / or provided to the operating system. The application can then be invoked by the operating system kernel (also known as the execution unit).

[0013] The method now includes, before executing the application, retrieving the execution permissions of the application to be executed from the rule set database via the execution unit and verifying those permissions. In this way, it can be ensured that the application is not malware before it is launched or invoked. If the user wants to launch the application, the execution permissions are first verified in the rule set database. Hereinafter, execution permissions are understood on the one hand as the user's execution permissions, and—if they exist—also as a verification of the integrity and authenticity of the application to be launched using a hash value or signature. Therefore, not only the user's execution permissions can be verified, but also the authenticity of the application itself. If the verification is successful, the program is first released by the execution unit (e.g., the operating system kernel and / or a cooperating application whitelisting component) for execution.

[0014] If the execution permission check is positive, the next step involves the application comparing the stored checksums of the rules for this application stored in the rule set database with the current checksums of the rules for this application stored in the rule set database. The rules (also called rule sets) relate to user permissions for the application to be executed and / or other execution restrictions that the application may define for other users (groups).

[0015] If the stored checksum matches the current checksum, the application starts. This means that after the application is invoked by the operating system's execution unit, the application itself compares the current checksum (e.g., a hash value or any other type of predefined checksum) with the checksum in the original rule set database.

[0016] According to the present invention, the application determines the checksum of the rules assigned to the application to be executed from the rule set database through an interface of an intermediate connection, particularly a proxy. Through such an interface, the application does not need to directly access the stored rule set. If the application could directly access the storage location of the rule set, i.e., the rule set database, then the application or its users could also potentially access the execution restrictions implemented on the system and thereby obtain information about their own or other user groups' execution permissions.

[0017] The checksum of the original rule set database is created here before any changes are made to the rule set database by a user (especially a user with administrative privileges) or the OEM provider, regarding the rule set database or the portion of the rule set database assigned to the application to be executed. In this way, the application can verify that the rules or data it assigns to the rule set database have not been altered without authorization. This ensures that the application has not been modified and that the rules defined by the rule set database have not been changed through adjustments to software or application configurations on the system (e.g., by a privileged user with installation permissions).

[0018] If the stored checksum of the rules for this application stored in the rule set database is inconsistent with the current checksum, the application is suspended according to one implementation, or starts in protected mode, or starts upon outputting a warning. The specific design of this action may, for example, depend on the application's security level. If the application is one that could potentially harm the operating system or other components or data, the application should be suspended immediately or at least started in protected mode. In such protected mode, for example, limited access to additional data may be provided. If the application is less security-critical, it may also simply output a warning and start immediately after the warning is output, or start, for example, upon user confirmation.

[0019] In another implementation, the rules for the application to be executed are divided into multiple regions in the rule set database, with one or more regions excluded from checksum calculation. In this way, certain regions of the rule set database assigned to the application to be executed can be defined, and these regions are excluded from verification, and therefore can be modified even after initial creation by users with appropriate privileges (i.e., users with appropriate (administrator) permissions, such as OEM providers). For example, it can be defined that such privileged users can only make changes within these regions. Since these regions are not considered when calculating the stored checksum and the current checksum, changes to these regions will not affect the result of comparing the current checksum with the stored checksum.

[0020] In another implementation, the stored checksum is stored in a manner protected by integrity and authenticity on the system's (especially the operating system's) file system or server, from which the application retrieves the stored checksum. Alternatively, the stored checksum may be stored in the application itself in a manner protected by integrity and authenticity.

[0021] In this context, the protection of integrity and authenticity is understood in particular to mean that the stored checksum cannot be altered and is genuine. This can be ensured, for example, by storing a verifiable signature of the file in which the checksum is stored.

[0022] It's also possible that the checksum, or a file containing the checksum, is hard-compiled into the application. In this case, the application should reference the signature or hash value from the ruleset database to prevent attackers from arbitrarily overwriting the checksum area.

[0023] Signature-based verification can be performed in such a way that, within the rule set, the protected application is referenced not by a path or checksum, but by the application's file signature.

[0024] In this way, creators of rule set databases can create the database before the actual, stored validations of the data in the rule set database assigned to the application are known.

[0025] In another implementation, the rules of the application to be executed are divided into multiple regions in a rule set database, wherein the application determines a current checksum for each of the multiple regions and compares it with a corresponding stored checksum. The multiple regions may be, for example, one or more regions created when the application is initially created, and one or more regions subsequently modified by the user. Because multiple checksums can be compared, not just one, these different regions can also be checked individually.

[0026] Therefore, the checksum can also be a checksum of a portion of the rule set database, which is subsequently performed, for example, by the OEM provider. In this way, the application can verify not only whether unauthorized changes have been made to the original data in the rule set database or the original data assigned to the application to be executed, but also whether unauthorized changes have been made to subsequent development of the rule set database. In this case, the application can, for example, perform checks on two different checksums (one for the original data portion and one for the modified data portion), and there are also two corresponding stored checksums.

[0027] It should be noted that the data to be tested in the rule set database is always data assigned to the application to be executed. The rule set database can also store other data assigned to other applications.

[0028] According to another implementation, the application to be executed defines which of the multiple regions to be inspected. Therefore, not only can different regions be inspected, but it can also be specified that only certain regions within a region be inspected, as described above. In this way, regions in which users can create their own rules can be defined in a simple manner, and these rules do not affect the checksum verification of the rule set database.

[0029] In another implementation, the application compares the checksums of rules specific to the application, stored in the rule set database, with the current checksums of those rules at predefined intervals. Therefore, the rule set database can be checked not only upon application startup or invocation but also during application runtime. This ensures that no unauthorized changes are made to the rule set database, even during application runtime. If a discrepancy is found between the current checksum and the stored checksum during runtime checksum verification, the application can, for example, abort, issue a warning, or switch to protected mode.

[0030] In another implementation, the execution unit starts the application by invoking its process, whereby the invoking process initiates a checksum verification against the rule set database. As described above, the execution unit begins by querying the rule set database to verify the integrity and authenticity of the application itself. Subsequently, although the execution unit starts the application, this start only initiates a call to the checksum verification process. The application only fully starts if this verification is also positive. During the checksum verification process, the application or its actual process remains suspended, meaning it can still be aborted, started with limited resources, or started fully.

[0031] According to another aspect, a system is proposed for verifying the integrity of a rule set database before executing an application. The system includes: a rule set database storing one or more execution permissions for one or more applications, wherein the rule set database also has rules for the one or more applications; and an execution unit configured to execute the application. The execution unit may, for example, be the kernel or core of the operating system on which the application will be executed.

[0032] The execution unit is configured to call and verify the execution permissions of the application to be executed from the rule set database before executing the application. If the execution permission verification of the application to be executed by the execution unit is positive, the application is configured to compare the stored checksum of the rules for this application stored in the rule set database with the current checksum of the rules for this application stored in the rule set database. If the stored checksum matches the current checksum, the application is configured to start.

[0033] As described above, according to one implementation, the rules of the application to be executed can be divided into multiple regions in a rule set database, where one or more regions are excluded from checksum calculation. In this way, regions can be provided where application users can make changes without affecting checksum verification.

[0034] Furthermore, different checksums can be defined for multiple regions. Thus, by using checksums for different regions, not only the application and the creator of the original rules, but also subsequent processors can incorporate their newly added (own) rules into the verification (with their own checksums).

[0035] Furthermore, although the rules of the application to be executed can be divided into multiple regions in the rule set database, none of these regions are excluded from checksum calculation. In this case, the application can be configured to determine the current checksum for each of the multiple regions separately and compare it with the corresponding stored checksum. This provides a particularly comprehensive verification of the rule set database.

[0036] According to another implementation, the stored checksums are stored on the system's file system or a server in a manner that protects their integrity and authenticity. The system's file system may, for example, be part of the operating system. The server may, in particular, be a web server. The advantage of this is that the checksums assigned to the application to be executed can be stored in any location, separately from the application and / or rule set database. Alternatively, the stored checksums can be stored in the application in a manner that protects their integrity and authenticity.

[0037] According to the present invention, the system includes an interface, particularly an agent, positioned between an application and a rule set database. Therefore, the application does not need to directly access the rule set database. This also protects other data located in the rule set database from access by the application or its users. The application is configured to query the rule set database for rules assigned to the application to be executed via this interface. Alternatively, the application may simply retrieve the current checksum from the interface. In this case, the interface can perform the checksum calculation and pass the current checksum to the application. The application can then perform a comparison between the current checksum and the stored checksum.

[0038] The corresponding unit, such as the execution unit, can be implemented using hardware and / or software technologies. In hardware implementation, the corresponding unit can be constructed as a device or part of a device, such as a control unit in a computer, microprocessor, or server. In software implementation, the corresponding unit can be constructed as a computer program product, function, routine, part of program code, or executable object.

[0039] The implementation methods and features described for the proposed system are applicable to the proposed method accordingly, and vice versa.

[0040] Furthermore, a computer program product is proposed that causes the execution of the method described above on a programmable device.

[0041] Computer program products, such as computer program devices, can be provided or delivered, for example, as storage media (e.g., memory cards, USB sticks, CD-ROMs, DVDs) or as files downloadable from a server on a network. This can be done, for example, by transmitting the corresponding files containing the computer program product or computer program device over a wireless communication network.

[0042] Other possible implementations of the invention include combinations of features or embodiments not explicitly mentioned above or below that are described with reference to the embodiments. Those skilled in the art will also consider individual aspects to be added as improvements or additions to the corresponding basic forms of the invention. Attached Figure Description

[0043] Other advantageous designs and aspects of the invention are the subject of the dependent claims and the embodiments described below. The invention will be explained in more detail below with reference to the accompanying drawings and preferred embodiments.

[0044] Figure 1 A schematic block diagram of a system for verifying the integrity of a rule set database before executing an application is shown. Figure 2A schematic sequence diagram of a method for verifying the integrity of an application before execution is shown. Figure 3 A schematic sequence diagram of a method for verifying the integrity of a rule set database of an application before execution is shown; and Figure 4 It shows Figure 3 State diagram of the method.

[0045] In the accompanying drawings, unless otherwise specified, the same or functionally equivalent elements are equipped with the same reference numerals. Detailed Implementation

[0046] Figure 1 System 1 is shown, which is used to verify the integrity of the rule set database 2 (also known as the application whitelist rule set), which stores the rules of application 4. System 1 can be an operating system or has an operating system. Application 4 can be an application or an integrated library, etc. Application 4 can be called by the operating system kernel 6 of the operating system. Before calling application 4, the operating system kernel 4 or the application whitelist component 8 implemented therein can verify the authenticity of application 4.

[0047] This reference Figure 2 Let's explain in more detail. In the first step S1, the operating system kernel 6 recognizes the user's call to application 4. Then, the operating system kernel 6 can verify the authenticity of application 4.

[0048] The manufacturer of application 4 includes or pre-installs the rule set database 2 when delivering application 4. When application 4 is invoked by operating system kernel 6, the operating system kernel or the application whitelist component 8 of operating system kernel 6 will first verify the permissions of application 4 itself with the help of rule set database 2.

[0049] Therefore, in step S2, the authentication of application 4 is invoked from the rule set database 2. This information is passed to the operating system kernel 6 in step S3, and then verified by the operating system kernel in step S4.

[0050] If the verification of the execution permission of application 4 is positive, application 4 can now be invoked by the operating system kernel 6 in the next step S5.

[0051] For reference now Figure 3To verify not only the authenticity of application 4 itself, but also the authenticity of the rules it attaches to in rule set database 2, application 4 can invoke the expected checksum 10 in step S6. This checksum 10 is a checksum created for the rules assigned to application 4 in rule set database 2. This checksum 10 can be stored in an integrity-protected manner (e.g., with file signing) on ​​the operating system's file system or, for example, on a remote network server invoked by application 4, which is to be protected and invoked, or it can be compiled into application 4. Additionally, in addition to the actual checksum, the integrity-protected checksum file can also store the expected behavior when the verification of the current rule for application 4 fails.

[0052] Application 4 can obtain checksum 10 in step S7.

[0053] Optionally, the integrity and authenticity of the checksum file (i.e., the file storing checksum 10) can be verified in step S8 (e.g., by checking the file's signature). If this is not possible, the execution of application 4 can preferably be aborted at a specific point in time.

[0054] In steps S9 and S10, application 4 also retrieves relevant rules from rule set database 2 and calculates the current checksum based on these rules. However, this requires application 4 to have direct read access to rule set database 2. The drawback of this is that the rules contained in database 2 must be visible to runtime users without administrative privileges.

[0055] Alternatively, application 4 can access the application via optional interface 12 (see...). Figure 1 For example, an agent 12 can invoke the current checksum. In this case, agent 12 queries the rule set database 2 for rules (step S10) and calculates the checksum, which it then provides to application 4 (step S11). The checksum can be calculated by agent 12 or application 4 calculating the checksum (e.g., hash value) of the content queried from the rule set database 2 in a unique way. When calculating the hash value, individual rules referencing specific subdirectories can be excluded from the calculation, for example, so as to provide the administrator of the OEM manufacturer or end customer with the possibility of defining their own rule set for a predefined file system area. Exclusion calculation is achieved by marking the rules to be excluded, for example, by assigning corresponding metadata to the rule.

[0056] Subsequently, in step S12, application 4 compares the current checksum with the stored checksum. If they are the same, application 4 executes in step S13; otherwise, it executes the action defined in the (preferably signed) checksum file 10. The defined action here could be to abort application 4 or reduce the scope of functionality within application 4 itself. A warning could also be output indicating that an unauthorized change has occurred on the underlying system, i.e., the rule set database 2.

[0057] like Figure 4 As shown, calling the current checksum (S9) can also be performed before calling the stored checksum (S6) and verifying the stored checksum (S8). Alternatively, these steps can also be performed simultaneously.

[0058] Then, in step S15, a further operation is determined. If the verification of the authenticity and integrity of the stored checksum or checksum file 10 is unsuccessful in step S8, the application terminates in step S16, and the process ends in step S17.

[0059] If the verification of the authenticity and integrity of the stored checksum or checksum file 10 is successful in step S8, then step S12 is executed, and the stored checksum 10 is compared with the current checksum (step S12). If they do not match, the application also aborts or performs another defined action, such as executing in protected mode (step S18). In this case, the process also ends in step S17. No further verification is performed here.

[0060] Conversely, if the checksum 10 stored in step S12 matches the current checksum, the application starts in normal mode, and the process pauses in step S19 until a new check interval. The process then restarts in step S9, or alternatively in steps S6 and S8, as described above. In this way, application 4 can also be monitored during its operation, and rules can be checked for unauthorized changes.

[0061] Sub-regions can be defined in the rules assigned to application 4 in rule set database 2. These sub-regions can be excluded from the checksum determination, thus avoiding their inclusion in the checksum determination. In this way, these sub-regions can also be modified by subsequent units (i.e., after the initial creation).

[0062] You can also define the sub-regions that should be checked. Subsequent manufacturers can create their own checksums here. In this case, for example, the entry point for verifying the checksum must be defined in the checksum file, i.e., which sub-regions to consider, and these sub-regions are also passed to the agent so that the agent can calculate the checksum with respect to the corresponding subdirectories.

[0063] Alternatively, rule regions defined in subsequent processes and those initially existing can also be considered. This means that the rules initially created in rule set database 2, as well as rules created by subsequent users, are taken into account in the checksum. The advantage of the first approach is that the operational capability of subsequent directories and components of application 4 does not depend on adjustments to the initially released components and their rule sets. The advantage of the latter approach is that the integrity of database 2 can be considered holistically.

[0064] OEM manufacturers or end-customer administrators can store their software in specific file system areas, define their own rules for those areas, and similarly utilize the methods described here to ensure integrity and authenticity. Therefore, this method can be applied to any application with rules stored in a rule set database, and in particular, to multiple applications. In any case, rules belonging to the respective application, or parts of those rules, are verified using checksums as described above.

[0065] Although the invention has been described with reference to embodiments, it can be modified in a wide variety of ways.

[0066] List of reference numerals 1 System 2. Rule set database 4 Applications 6. Execution Unit / Operating System Kernel 8. Application whitelist component 10. Checksum / Checksum file 12 Interfaces / Proxy S1-S13 Method Steps S15-S19 Method and Steps.

Claims

1. A method for verifying the integrity of a rule set database (2) before executing an application (4), wherein the rule set database (2) stores one or more execution permissions for one or more applications (4), wherein the rule set database (2) also has rules for said one or more applications (4), wherein the method comprises: Before executing the application (4), the execution unit (6) calls (S2) the execution permissions of the application (4) to be executed from the rule set database (2), and verifies (S4) the execution permissions. If the execution permission check (S4) of the application to be executed by the execution unit (6) is positive, then the application (4) compares the stored checksum (10) of the rule for this application (4) stored in the rule set database (2) with the current checksum of the rule for this application (4) stored in the rule set database (2) (S12), and If the stored checksum (10) matches the current checksum, then start (S13) the application (4). The feature is that the application (4) queries (S9) the rules assigned to the application (4) to be executed from the rule set database (2) through the intermediary proxy.

2. The method according to claim 1, wherein, If the stored checksum (10) of the rule for this application (4) stored in the rule set database (2) is inconsistent with the current checksum, the application (4) is aborted (S17, S18), started in protected mode (S17, S18), or started with an output warning (S17, S18).

3. The method according to any one of the preceding claims, wherein, The rules of the application (4) to be executed are divided into multiple regions in the rule set database (2), one or more of which are excluded from the calculation of the checksum.

4. The method according to any one of the preceding claims, wherein the stored checksum (10) is stored on the file system of the system (1) or on a server in a manner that protects its integrity and authenticity, and wherein the application (4) invokes (S6, S7) the stored checksum (10) from the file system or the server, or wherein the stored checksum (10) is stored in the application (4) in a manner that protects its integrity and authenticity.

5. The method according to any one of the preceding claims, wherein, The rules of the application (4) to be executed are divided into multiple regions in the rule set database (2), wherein the application (4) determines (S10) the current checksum for each of the multiple regions and compares it with the corresponding stored checksum (10) (S12).

6. The method according to claim 5, wherein, The application (4) to be executed defines which of the multiple regions to be inspected.

7. The method according to any one of the preceding claims, wherein the application (4) compares (S19) the checksum of the rules for the application (4) stored in the rule set database (2) at predefined intervals with the current checksum of the rules for the application (4) stored in the rule set database (2).

8. The method according to any one of the preceding claims, wherein, The execution unit (6) starts the application (4) by calling the process of the application, wherein the process is called to start the verification of the checksum of the rule set database (2).

9. A system (1) for verifying the integrity of a rule set database (2) before executing an application (4), the system having: A rule set database (2) stores one or more execution permissions for one or more applications (4), wherein the rule set database (2) also contains rules for said one or more applications (4), and The execution unit (6) is configured to execute the application (4). in, The execution unit (6) is configured to call and verify the execution permissions of the application (4) to be executed from the rule set database (2) before executing the application (4). If the execution permission of the application (4) to be executed is verified by the execution unit (6), then the application (4) is configured to compare the stored checksum (10) of the rules for this application (4) stored in the rule set database (2) with the current checksum of the rules for this application (4) stored in the rule set database (2), and If the stored checksum (10) matches the current checksum, then the application (4) is constructed to start. The feature is that the application (4) queries (S9) the rules assigned to the application (4) to be executed from the rule set database (2) through the intermediary proxy.

10. The system according to any one of the preceding claims, wherein, The rules of the application (4) to be executed are divided into multiple regions in the rule set database (2), one or more of which are excluded from the calculation of the checksum.

11. The system according to any one of the preceding claims, wherein, The stored checksum (10) is stored on the file system or server of the system (1) in a manner that protects its integrity and authenticity, or the stored checksum (10) is stored in the application (4) in a manner that protects its integrity and authenticity.

12. The system according to any one of the preceding claims, wherein, The system (1) has an interface (12), in particular an agent, which is arranged between the application (4) and the rule set database (2), and wherein the application (4) is configured to query the rule set database (2) for rules assigned to the application (4) to be executed through the interface (12).

13. The system according to any one of the preceding claims, wherein, The rules of the application (4) to be executed are divided into multiple regions in the rule set database (2), wherein the application (4) is configured to determine the current checksum for each of the multiple regions and compare it with the corresponding stored checksum (10).

14. A computer program product that causes execution of the method according to any one of claims 1 to 8 on a program-controlled device.

Images