Method and system for checking the integrity of a rules database
Patent Information
- Authority / Receiving Office
- EP · EP
- Patent Type
- Applications
- Current Assignee / Owner
- SIEMENS AG
- Filing Date
- 2024-07-18
- Publication Date
- 2026-05-20
Smart Images
Figure EP2024070354_06032025_PF_FP_ABST
Abstract
Description
[0001] 202314352 Foreign Version 1 Description Method and System for Checking the Integrity of a Rules Database The present invention relates to a method for checking the integrity of a rules database before executing an application. Furthermore, the present invention relates to a system for checking the integrity of a rules database before executing an application. Furthermore, the present invention relates to a computer program product that initiates the execution of the method as explained above on a program-controlled device.To prevent software or applications on a system from being modified or additionally installed in unauthorized installation processes after their original creation, and to ensure that the software or applications on the system can only be executed by specific user groups, so-called application whitelisting solutions exist, which are part of the operating system or are integrated into it. With the help of such solutions, execution rules can be configured in both audit and enforcement mode and stored in an application whitelisting rule database. These execution rules allow and / or prohibit the execution of certain programs based on predefined conditions (e.g., certain users).The execution rules can reference the programs to be executed by storing a path, a signature, or a hash value for them. A combination of the three criteria mentioned is also possible. One problem here is that software or applications delivered on installations can subsequently be expanded by OEM manufacturers and end customers through the installation of their own software components. However, this creates the problem that both the end customer's administrator and the OEM manufacturer themselves must have administrative permissions on the system to perform the necessary activities and thus also have access to the application whitelisting rule database stored locally on the system.Please note that, regardless of the grammatical gender of a particular term, this includes persons of male, female, or other gender identities. The aforementioned access to the application whitelisting rules database cannot be restricted when administrative permissions are granted. Consequently, the rules stored there by the original creator, which define the authenticity and integrity as well as the execution permissions for specific user groups of the creator's own software, are no longer protected and can be modified at will, for example, by the end user's administrator or the OEM manufacturer. As already mentioned above, access to the application whitelisting rules database can only be restricted as long as the user does not have administrative permissions.However, in most cases, these are required to install additional software, so the end customer's administrator or an OEM manufacturer, for example, must be trusted not to modify the execution permissions within the application whitelisting rule database. US 2020 / 272742A1 discloses the calculation of a checksum across multiple security application rule sets on a client device that receives the checksum from a server. The execution permission and checksum verification are performed during application execution. 202314352 Foreign Version 3 US 2011 / 029772A1 discloses the use of multiple levels of rule sets secured by a signature. The signatures of the rule sets (and thus also their checksums) are verified when these rule sets are loaded.US 2015 / 019857A1 discloses the verification of applications and policy signatures to allow an application to tighten the mobile device's parameters during execution. Both signatures are verified using checksums and certificate chains. Against this background, one object of the present invention is to provide a way for the manufacturer of an application on a system to assign certain execution permissions and restrictions to ensure integrity and authenticity, but in downstream processing steps, users with administrative permissions are allowed to make further adjustments, while simultaneously detecting unauthorized adjustments made by these users in these downstream processing steps.Accordingly, a method is proposed for checking the integrity of a rule database before executing an application, wherein one or more execution permissions for one or more applications are stored in the rule database, wherein the rule database further comprises rules for the one or more applications. Such a rule database is also referred to as an application whitelisting rule database. Execution permissions are stored therein, which can be checked in a first step by an operating system or an execution unit of the operating system (e.g., a kernel). The manufacturer of a software or application 202314352 Foreign Version 4 can include an application whitelisting rule database with the delivery of the application.In this context, an application is understood to be a program or software that can be stored on and / or made available to an operating system. The application can then be called by the operating system kernel, also known as the execution unit. Before an application is executed, the method involves an execution unit retrieving execution authorization for the application to be executed from the rules database and checking the execution authorization. In this way, it can be ensured that the application is not malware before the application is started or called. If a user wants to start the application, the execution authorization is first checked in the rules database.In the following, execution authorization is understood to mean the user's execution authorization and - if available - also the verification of the integrity and authenticity of the application to be started using hashes or signatures. This means that not only the user's execution authorization can be verified, but also the authenticity of the application itself. If the verification is successful, the program is initially released for execution by the execution unit, e.g. an operating system kernel and / or an application whitelisting component working with it. If the execution authorization verification is positive, the next step is for the application to check a stored checksum of the rules for this application stored in the rule database against a current checksum of the rules for this application stored in the rule database.The rules, also called a rule set, are user authorizations for the application to be executed and / or other execution restrictions of the application, possibly defined for other user (groups). If the stored checksum matches the current checksum, the application starts. This means that the application itself, after being called by the operating system's execution unit, compares a current checksum, e.g., a hash value or some other type of predefined checksum, with a checksum from the original rule set database. According to the invention, the application determines the checksum of the rules assigned to the application to be executed from the rule set database via an intermediate interface, primarily a proxy.By interposing such an interface, the application does not need to be given direct access to the stored rule set. If the application has direct access to the storage location of the rule set, i.e., the rule set database, the application or user of the application could also gain access to the execution restrictions implemented on the system and thus obtain information about their own or other user groups' execution permissions. The checksum of the original rule set database is a checksum that was created over the rule set database, or parts of the rule set database that are assigned to the application to be executed, before any changes were made to the rule set database by users, especially users with administrative permissions, or OEM providers.In this way, the application can check whether unauthorized changes have been made to the rules or data assigned to it in the rule database. This ensures that the application has not been modified and that the rules defined by the rule database have not been changed by adjusting the software or application configuration on the system, for example, by a privileged user with installation authorization. If the stored checksum of the rules stored in the rule database for this application does not match the current checksum, according to one embodiment, the application aborts, starts in a protected mode, or starts with a warning. The specific design of the execution in such a case can depend, for example, on the security level of the application.If the application has the potential to cause damage to the operating system or other components or data, the application should terminate immediately or at least start in a protected mode. In such a protected mode, for example, only restricted access to further data may be provided. If the application is less security-critical, it can also only issue a warning and start either immediately after the warning is issued or, for example, after confirmation by a user. According to a further embodiment, the rules of the application to be executed are divided into several areas in the rule database, with one or more areas being excluded from the calculation of the checksum.In this way, some of the areas of the rule database assigned to the application to be executed can be defined as being exempt from checking and can therefore be changed even after their original creation by a suitably privileged user, i.e., a user with the appropriate (administrator) rights, e.g., an OEM provider. For example, it can be defined that such privileged users can only make changes in these areas. Since these areas are not taken into account when calculating the stored and current checksums, changes in these areas have no influence on the result of a comparison of the current and stored checksums.According to a further embodiment, the stored checksum is stored in a file system of the system, in particular the operating system, or on a server, with the application retrieving the stored checksum from the file system or the server. Alternatively, the stored checksum can be stored in the application itself in a file system that ensures integrity and authenticity. In this context, "integrity and authenticity assured" means in particular that the stored checksum cannot be changed and is authentic. This can be ensured, for example, by a verifiable signature of the file in which the checksum is stored. It is also possible for the checksum, or a file containing the checksum, to be permanently compiled into the application.In this case, the application should be referenced within the rule database using a signature or hash to prevent an attacker from arbitrarily overwriting the checksum range. Signature-based checks can be performed by referencing a protected application within the rule database not by path or checksum, but by the application's file signature. This allows the creator of the rule database to create this database before the actual checksum of the data in the rule database associated with the application is known.202314352 Foreign version 8 According to a further embodiment, the rules of the application to be executed are divided into several areas in the rule database, wherein the application determines a current checksum for each of the several areas and compares it with corresponding stored checksums. The several areas can, for example, be one or more areas that were created when the application was initially created, and one or more areas that were subsequently changed by a user. Since not just one but several checksums can be compared, these different areas can also be checked individually. The checksum can therefore also be a checksum of parts of the rule database that were subsequently created, e.g. by an OEM provider.In this way, the application can not only check whether unauthorized changes have been made to the original data in the rule database, or the original data assigned to the application being executed, but also whether unauthorized changes have been made to further developments of the rule database. In this case, the application can, for example, perform a check of two different checksums (once of the original data sections and once of the modified data sections), whereby two corresponding stored checksums are also available. It should be noted that the data in the rule database to be checked is always data assigned to the application being executed. Additional data assigned to other applications can also be stored in the rule database.According to a further embodiment, the application to be executed defines which of the multiple areas are to be checked. This means that not only can different areas be checked, but it is also possible to specify that only some of the areas are to be checked, as already explained above in 202314352 Foreign Version 9. In this way, areas can be easily defined in which a user can create their own rules that have no influence on a check of the checksum of the rule database. According to a further embodiment, the application compares the checksum of the rules stored in the rule database for this application with a current checksum of the rules stored in the rule database for this application at predefined intervals. This means that not only at the beginning of starting orThe rule database can be checked not only when the application is called, but also during the application's runtime. This ensures that no unauthorized changes are made to the rule database data while the application is running. If, during a runtime check of the checksum, it is determined that the current checksum does not match the stored checksum, the application can, for example, abort, issue a warning, or switch to a protected mode. According to a further embodiment, the execution unit starts the application by calling a process of the application, whereby the call of the process starts the checksum of the rule database. As already explained above, the execution unit begins by checking the integrity and authenticity of the application itself by querying the rule database.The execution unit then starts the application, but this start only initiates a call to the checksum verification process. The application only starts fully if this checksum verification is also positive. During the checksum verification process, the application, or the actual process of the application, is still in a suspended state, i.e. it can still be aborted, started with restrictions, or started fully. 202314352 Foreign version 10 According to a further aspect, a system for checking the integrity of a rule database before executing an application is proposed. The system has a rule database in which one or more execution authorizations for one or more applications are stored, wherein the rule database further has rules for the one or more applications, and an execution unit which is designed to execute an application.The execution unit can, for example, be a kernel or core of an operating system on which the application is to be executed. The execution unit is designed to retrieve and check an execution authorization of the application to be executed from the rule database before executing the application. If the execution unit's check of the execution authorization of the application to be executed is positive, the application is designed to compare a stored checksum of the rules stored in the rule database for this application with a current checksum of the rules stored in the rule database for this application. If the stored checksum matches the current checksum, the application is designed to start.As already explained above, according to one embodiment, the rules of the application to be executed can be divided into several areas in the rule database, with one or more areas being excluded from the checksum calculation. In this way, areas can be provided in which users of the application can make changes without this having an impact on the checksum verification. Furthermore, different checksums can be defined for the multiple areas. This allows checksums for different areas to not only allow the creator of the application and the original rules, but also subsequent editors to have their newly added (own) rules included in a review (with their own checksum).Furthermore, the rules of the application to be executed can be divided into several areas in the rule database, but none of these areas can be excluded from the calculation of the checksum. In this case, the application can be designed to determine a current checksum for each of the several areas and compare it with corresponding stored checksums. This provides a particularly comprehensive check of the rule database. According to a further embodiment, the stored checksum is stored in a file system of the system or on a server with integrity and authenticity protection. The file system of the system can, for example, be part of an operating system. The server can, in particular, be a web server.This has the advantage that the checksum assigned to the application to be executed can be stored anywhere, separate from the application and / or the rule database. Alternatively, the stored checksum can be stored in the application in a way that ensures integrity and authenticity. According to the invention, the system has an interface, especially a proxy, arranged between the application and the rule database. The application therefore does not need to have direct access to the rule database. This also allows other data located in the rule database to be protected from access by the application or a user of the application. The application is designed to query the rules assigned to the application to be executed from the rule database via the interface. Alternatively, the application can also retrieve only the current checksum from the interface.In this case, the interface 202314352 Foreign Version 12 can calculate the checksum and pass the current checksum to the application. The application can then compare the current and the stored checksum. The respective unit, for example, execution unit, can be implemented in hardware and / or software. In a hardware implementation, the respective unit can be designed as a device or as part of a device, for example as a computer or as a microprocessor or as a control unit on a server or similar. In a software implementation, the respective unit can be designed as a computer program product, as a function, as a routine, as part of a program code, or as an executable object.The embodiments and features described for the proposed system apply accordingly to the proposed method and vice versa. Furthermore, a computer program product is proposed which causes the method explained above to be carried out on a program-controlled device. A computer program product, such as a computer program means, can be provided or delivered, for example, as a storage medium, such as a memory card, USB stick, CD-ROM, DVD, or in the form of a downloadable file from a server in a network. This can take place, for example, in a wireless communications network by transmitting a corresponding file with the computer program product or the computer program means.Further possible implementations of the invention also include combinations of features or embodiments described previously or below with regard to the exemplary embodiments that were not explicitly mentioned. In this case, the person skilled in the art will also add individual aspects as improvements or additions to the respective basic form of the invention. Further advantageous refinements and aspects of the invention are the subject of the dependent claims and the exemplary embodiments of the invention described below. The invention is explained in more detail below using preferred embodiments with reference to the attached figures. Fig. 1 shows a schematic block diagram of a system for checking the integrity of a rule database before executing an application; Fig. 2 shows a schematic sequence diagram of a method for checking the integrity of an application before executing the application; Fig.Fig. 3 shows a schematic sequence diagram of a method for checking the integrity of a rule database of an application before executing the application; and Fig. 4 shows a state diagram of the method of Fig. 3. In the figures, identical or functionally equivalent elements have been provided with the same reference numerals unless otherwise stated. Fig. 1 shows a system 1 for checking the integrity of a rule database 2, also called an application whitelisting rule set, in which rules for an application 4 are stored. The system 1 can be an operating system or have an operating system. The application 4 can be an application program or an integrated library or the like. The application 4 can be called by an operating system kernel 6 of an operating system.Before the application 4 is called, the operating system kernel 4 or an application whitelisting component 8 implemented therein can check the authenticity of the application 4. 202314352 Foreign version 14 This is explained in more detail with reference to Fig. 2. In a first step S1, a call to the application 4 by a user is first recognized by the operating system kernel 6. The kernel can then check the application 4 for its authenticity. The manufacturer of the application 4 supplies the rule database 2 with the delivery of its application 4 or pre-installs it. If the application 4 is called by the operating system kernel 6, the kernel or an application whitelisting component 8 of the operating system kernel 6 will first check the authorization of the application 4 itself with the help of the rule database 2. For this purpose, an authentication of the application 4 is retrieved from the rule database 2 in step S2.This information is passed to the operating system kernel 6 in step S3 and then verified by the operating system kernel 6 in step S4. If the result of the verification of the execution authorization of the application 4 by verifying the authenticity is positive, the application 4 can now be called by the operating system kernel 6 in a next step S5. As will now be described with reference to Fig. 3, in order to verify not only the authenticity of the application 4 itself, but also its supplied rules in the rule database 2, the application 4 can retrieve an expected checksum 10 in step S6. This checksum 10 is a checksum that was created using rules in the rule database 2 that are assigned to the application 4. This checksum 10 can be stored either with integrity assurance (e.g., using a file signature) on a file system of the operating system or, for example,be stored on a remote web server, which is called by the application 4 to be protected and called, or can be compiled into the application 4. In addition, the integrity-assured checksum file can contain not only the actual 202314352 foreign version 15 checksum, but also the desired behavior in the event of unsuccessful validation of the current rules of the application 4. The application 4 can receive the checksum 10 in step S7. Optionally, the integrity and authenticity of the checksum file, i.e. the file in which the checksum 10 is stored, can be validated in step S8 (e.g. by checking a signature of the file). If this is not possible, the execution of the application 4 can preferably be aborted at this time. The application 4 further retrieves the associated rules from the rule database 2 in steps S9, S10 and calculates a current checksum using these rules.This requires, however, that the application 4 must be granted direct read access to the rule database 2. This has the disadvantage, however, that the rules contained in the database 2 must be made visible to a non-administrative runtime user. Alternatively, the application 4 can retrieve the current checksum via an optional interface 12 (see Fig. 1), e.g. a proxy. In this case, the proxy 12 queries the rules from the rule database 2, step S10, and calculates the checksum, which it in turn makes available to the application 4, step S11. The checksum can be calculated by the proxy 12 or the application 4 uniquely calculating a checksum (e.g. a hash value) based on the queried contents of the rule database 2. When calculating the hash value, for example, individual rules that reference specific subdirectories with regard tobe excluded from the calculation, so that an OEM manufacturer or an administrator of the end customer can be given the opportunity to define their own rule sets for predefined file system areas. The exception to the calculation is achieved by marking the rules to be excluded, e.g., by assigning corresponding meta information to the rule. The application 4 then compares the current and the stored checksum in step S12. If these are identical, the application 4 is executed in step S13; otherwise, the action defined within the (preferably signed) checksum file 10 is executed. A defined action can be an abort of the application 4 or a reduced range of functions within the application 4 itself. A warning can also be issued that on the underlying system, iethe rule set database 2, an unauthorized change has occurred. As shown in Fig. 4, the retrieval of the current checksum (S9) can also occur before the retrieval of the stored checksum (S6) and the validation of the stored checksum (S8). Alternatively, these steps can also be performed simultaneously. The decision on how to proceed is then made in step S15. If the validation of the authenticity and integrity of the stored checksum or the checksum file 10 was unsuccessful in step S8, the application aborts in step S16 and the process ends in step S17. If the validation of the authenticity and integrity of the stored checksum or the checksum file 10 was successful in step S8, step 12 is then performed and the stored checksum 10 and the current checksum are compared (step S12).If these do not match, the application is also aborted or another defined action, such as running in a protected mode, is carried out (step S18). In this case, too, the process then ends in step S17. No further check takes place here. 202314352 Foreign version 17 If, on the other hand, the stored checksum 10 and the current checksum match in step S12, the application is started in normal mode and the process pauses in step S19 until a new check interval. The process then starts again at step S9 or alternatively steps S6, S8, as described above. In this way, application 4 can also be monitored during its runtime and the rules can be checked for unauthorized changes. Sub-areas can be defined in the rules assigned to application 4 in the rule database.These sub-areas can be excluded from verification, so that they are not included in the determination of the checksum. In this way, these sub-areas can also be changed by downstream units, i.e., after the original creation. Sub-areas that are to be verified can also be defined. A downstream manufacturer can create its own checksum. In this case, the entry point for validating the checksum must then be defined within the checksum file, for example, i.e., which sub-areas are to be considered, and this must also be passed to the proxy so that it calculates the checksums via the corresponding subdirectories. Alternatively, the rule areas defined in the downstream process and those originally present can also be taken into account.This means that both the initially created rules and rules created by subsequent users in the rule database 2 are taken into account in the checksums. The first method has the advantage that the executability of the downstream directories and components of application 4 does not depend on adjustments to the initially deployed components and their rule set. The latter has the advantage that the integrity of database 2 as a whole can be taken into account. 202314352 Foreign version 18 An OEM manufacturer or an administrator of the end customer can store their own software in certain file system areas, define their own rules for this area, and can also ensure their integrity and authenticity using the method described here. The method is therefore applicable to any application with rules stored in the rule database and can, in particular, also be used for multiple applications.In each case, the rules associated with the respective application, or a portion of these rules, are verified using the checksum, as described above. Although the present invention has been described using exemplary embodiments, it is susceptible to numerous modifications.
[0002] 202314352 Foreign version 19 List of reference symbols 1 System 2 Rule database 4 Application 6 Execution unit / operating system kernel 8 Application whitelisting component 10 Checksum / checksum file 12 Interface / Proxy S1-S13 Process steps S15-S19 Process steps
Claims
202314352 Foreign version 20 patent claims 1. Method for checking the integrity of a rule database (2) before executing an application (4), wherein one or more execution authorizations for one or more applications (4) are stored in the rule database (2), wherein the rule database (2) further comprises rules for the one or more applications (4), wherein the method comprises: before executing an application (4), retrieving (S2) an execution authorization of the application (4) to be executed from the rule database (2) by an 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), by the application (4),a stored checksum (10) of the rules stored in the rule database (2) for this application (4) with a current checksum of the rules stored in the rule database (2) for this application (4), and if the stored checksum (10) matches the current checksum, starting (S13) the application (4); characterized in that the application (4) queries the rules associated with the application (4) to be executed from the rule database (2) via an interposed proxy (S9).
2. The method according to claim 1, wherein, if the stored checksum (10) of the rules stored in the rule database (2) for this application (4) does not match the current checksum, the application (4) aborts (S17, S18), starts in a protected mode (S17, S18), or starts with the output of a warning (S17, S18).
3. Method according to one of the preceding claims,wherein the rules of the application to be executed (4) are divided into several areas in the rule database (2), wherein, 202314352 Foreign version 21 one or more areas are excluded from the calculation of the checksum.
4. The method according to one of the preceding claims, wherein the stored checksum (10) is stored in a file system of the system (1) or on a server with secured integrity and authenticity, and wherein the application (4) retrieves the stored checksum (10) from the file system or the server (S6, S7), or wherein the stored checksum (10) is stored in the application (4) with secured integrity and authenticity.
5. The method according to one of the preceding claims, wherein the rules of the application (4) to be executed are divided into a plurality of areas in the rule database (2), wherein the application (4) determines a current checksum for each of the plurality of areas (S10) and compares it with corresponding stored checksums (10) (S12). 6.Method according to claim 5, wherein the application (4) to be executed defines which of the plurality of areas are to be checked.
7. Method according to one of the preceding claims, wherein the application (4) compares the checksum of the rules stored in the rule database (2) for this application (4) with a current checksum of the rules stored in the rule database (2) for this application (4) at predefined intervals (S19).
8. Method according to one of the preceding claims, wherein the execution unit (6) starts the application (4) by calling a process of the application (S5), wherein the call of the process starts the checking of the checksum of the rule database (2). 202314352 Foreign version 22 9. System (1) for checking the integrity of a rule database (2) before executing an application (4), comprising: a rule database (2) in which one or more execution authorizations for one or more applications (4) are stored, wherein the rule database (2) further comprises rules for the one or more applications (4), and an execution unit (6) which is designed to execute an application (4), wherein the execution unit (6) is designed to retrieve and check an execution authorization of the application (4) to be executed from the rule database (2) before executing the application (4), wherein, if the check of the execution authorization of the application (4) to be executed by the execution unit (6) is positive, the application (4) is designed toto compare a stored checksum (10) of the rules stored in the rule database (2) for this application (4) with a current checksum of the rules stored in the rule database (2) for this application (4), and if the stored checksum (10) matches the current checksum, the application (4) is designed to start, characterized in that the application (4) queries the rules associated with the application (4) to be executed from the rule database (2) via an interposed proxy (S9).
10. System according to one of the preceding claims, wherein the rules of the application (4) to be executed in the rule database (2) are divided into several areas, wherein one or more areas are excluded from the calculation of the checksum.
11. System according to one of the preceding claims, wherein the stored checksum (10) is integrity- and, 202314352 Foreign Version 23 is stored in an authenticity-secure manner on a file system of the system (1) or on a server, or wherein the stored checksum (10) is stored in the application (4) in an integrity- and authenticity-secure manner.
12. System according to one of the preceding claims, wherein the system (1) has an interface (12), in particular a proxy, arranged between the application (4) and the rule database (2), and wherein the application (4) is configured to query the rules assigned to the application (4) to be executed from the rule database (2) via the interface (12). 13.System according to one of the preceding claims, wherein the rules of the application (4) to be executed are divided into several areas in the rule database (2), wherein the application (4) is configured to determine a current checksum for each of the several areas and to compare it with corresponding stored checksums (10).
14. A computer program product that initiates the implementation of the method according to one of claims 1 to 8 on a program-controlled device.