Method and apparatus for generating and comparing signatures of software packets

Abstract

To provide a method, apparatus, and program for generating and comparing signatures of software packets.SOLUTION: The method determines various digital objects associated with a software packet, generates hash values of the individual digital objects from these digital objects by means of a hash method, and merges these hash values as a signature of the software packet, wherein a specific software packet or a version of a software packet or a specific variant of a software packet is uniquely determined by means of a signature of this kind. If, in addition, these hash values are stored when the software packet is created, a simple and reliable check is made in all possible applications, for example in the software of the machine tool, whether it is a modified variant of the software packet or an older version of the software packet, etc.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] explanation The present invention relates to an apparatus and method for generating and comparing signatures of software packets. These signatures are created based on hash values ​​of a wide variety of software-related digital objects. As a result, it is possible to determine in a reliable and easy (automated) manner whether a software packet can be identified based on its signature by comparison with a signature database, or whether the software packet has been subsequently modified. [Background technology]

[0002] Background of the Invention Controllers for machine tools often combine various software systems, which, depending on the controller used, are based on the common Windows or Linux operating systems, but may also be proprietary. To identify a particular software packet, information in a specific format is typically added to the software packet. However, the format of this information is not standardized and therefore varies depending on where the software is obtained. In some cases, the information is added separately in the form of metadata, for example, as an .xml file. Alternatively, the information is stored as an encoded part of the software packet itself. Furthermore, it is possible that a particular software packet does not have any metadata at all.

[0003] In summary, it can therefore be established that the information serving to identify a software packet is present in an easily manipulated format, that the storage format is possibly unknown and therefore difficult to access, or that the information cannot be obtained at all. Automatic identification may therefore not be possible for all relevant software components of the machine tool controller. Furthermore, correction of the software packet can consequently only be established with great effort (manual checking of all relevant data) or not at all.

[0004] It is therefore an object of the present invention to provide a method and apparatus for enabling the automatic and unique identification of software packets in a machine tool. Summary of the Invention [Problem to be solved by the invention]

[0005] Detailed Description of the Invention In order to achieve the above mentioned object, the features of the independent claims are proposed. The dependent claims relate to preferred exemplary embodiments of the invention. [Means for solving the problem]

[0006] The present invention provides a method and apparatus for generating and comparing signatures of software packets. For this purpose, digital objects belonging to a software packet are determined. These may be, for example, the software packet's installation file, a memory image of the installed software packet, or other binary representative data of the software packet. The memory image may be a memory image of a programmable logic controller (PLC), computerized numerical control (CNC), or human machine interface (HMI) system. Preferably, a partial memory image of a controller's HMI, CNC, or PLC system is considered. The partial memory image is determined, for example, based on statistically acquired knowledge or the specifications of a software manufacturer or system integrator. Thus, for example, rules can be defined to allow partial images to be selected based on their meaning or purpose with respect to the software packet. This allows, for example, to select portions of the memory image that are invariant to the input and output of the software packet based on the structure of this portion of the memory image. Furthermore, a software packet can be considered to represent a single piece of software or a collection of different pieces of software that fulfill a common purpose. After the digital objects are determined, respective hash values ​​are determined for each object in the digital objects. These hash values ​​are then merged into a signature for the software packet. This signature allows a specific software packet to be uniquely identified. This signature can therefore be created, for example, at the time of creation of the software packet or at the time of installation of the software packet. Thus, at a later point in time, the signature can be created again and compared with the original signature. In this way, it can be established whether the software packet has been modified since its original creation or installation.This comparison can be done in a fully automated manner (eg, periodically) and does not require any additional metadata.

[0007] Furthermore, preferably, the software packet is control software for a machine tool. The term machine tool is understood to include not only the machine tool itself, but also automation systems associated with the machine tool (e.g., automatic loading). Since machine tools often use their own systems for software installation, a system-independent check of the data integrity of the software installation is particularly advantageous. Furthermore, inadvertent or intentional modifications of the software installation can be quickly and easily established, even if they only concern one memory image of the machine tool's controller.

[0008] Preferably, the PLC memory image, the HMI memory image, and / or the CNC memory image include only a partial memory image of the corresponding entire memory image.

[0009] Advantageously, the partial memory images are selected based on predetermined rules, the predetermined rules being based on the purpose of using different parts of the memory images for the software packets.

[0010] Preferably, the digital objects of the software packets are determined by extracting them from the machine tool's control unit. Alternatively, this can be performed once immediately after installation and then periodically, for example, to ensure a continuous check. Advantageously, files can be copied from the subsystem, and partial memory image extractions can be obtained via an interface provided by the machine's manufacturer's controller. Communication telegrams can be reached via the communication protocol on which they are based.

[0011] Advantageously, the integrity check of the first software packet can be performed periodically.

[0012] Additionally, determining the digital object may involve reading the data memory in which the software packet is installed or running.

[0013] Preferably, hash values ​​are not generated for all digital objects, but only for a subset. The subset can be determined based on the relevance of individual digital objects with respect to the software packet. Hash values ​​are then generated only for digital objects within the selected subset. The relevance of digital objects can be based on the type of digital object (e.g., file type) or can be determined via statistics reflecting changes in the digital object across multiple versions of the same software packet (distribution of the digital object). The manufacturer of a particular software packet can determine a highly appropriate selection of the associated hash value based on detailed knowledge of the software and its runtime characteristics. This may provide convenient operating characteristics for evaluating a subset of the software's memory image.

[0014] Preferably, the hash value of the digital object is generated by applying a hashing algorithm to the individual digital object, where common methods such as MD-5, RIPEMD-160, SHA, Whirlpool, etc. can be used.

[0015] Preferably, the signatures can be created from the hash values ​​by storing the individual hash values ​​in a hash table, which allows for accurate output of the differences (different hash values) or signatures of different software packets between two compared software packets.

[0016] Alternatively, an overall hash value can be generated from the individual hash values. This can be done by applying a common hashing algorithm. Comparing the individual hash values ​​makes the comparison of two software packets particularly simple and efficient.

[0017] Alternatively, the individual hash values ​​and the overall hash value can be stored. The overall hash values ​​of both software packets can then be compared, with the individual comparison being performed only if the two hash values ​​are not equal. In this way, the integrity of the software packets can be efficiently checked, allowing for more accurate analysis of differences if necessary.

[0018] Optionally, metadata can further be generated for the software packet. This metadata can be, for example, an identifier for the software packet, a version number, or a content indication. This metadata can be determined in an automated manner, for example, from an existing digital object.

[0019] Preferably, the first created signature (after the creation or installation of the software) can be stored on a local computer or server. The local computer or server can then be connected to the medium on which the software packet is installed and used, for example, in the control unit of a machine tool, for the purpose of signature comparison. The local computer can be connected to the control unit of the machine tool both wired and wirelessly. The use of a server allows for simple and externally controlled (e.g., by the machine or software manufacturer) checks of the installed software to be performed. In contrast, a local computer has the advantage that checks can be performed without the need to transmit data externally.

[0020] Preferably, the software packets to which the signatures are compared are identical software packets, an original software packet and a manipulated software packet, two different versions of a software packet, an unmodified variant and a modified variant of a software packet, or two completely different software packets.

[0021] In a convenient development, generating the first signature can include merging the hash values ​​into a first signature of the first software packet and generating an overall hash value from the hash values. Still conveniently, comparing the first signature with the second signature can include comparing the overall hash value of the first signature with the overall hash value of the second signature.

[0022] Preferably, the comparison of two software packets can be used to check the integrity of the software packet, determine the version of the software packet (by comparing multiple signatures belonging to different versions of the software packet), detect multiple installations of the same software packet, or detect installations of different versions of the same software packet.

[0023] When all hash values ​​of two software packets are compared, the output of this comparison can preferably be used for an efficient software packet update process. In this case, the signature of the current version of the software packet is compared with the version of the software packet (i.e., its generated signature) installed on a medium (e.g., the control unit of a machine tool). In this case, all hash values ​​that do not match are output. Starting from the mismatched hash values, files corresponding to these hash values ​​are selected by the software manufacturer and provided to update the installed software packet. Thus, the comparison of individual hash values ​​allows for an optimized software update process, minimizing the amount of data transmitted, since only the files that differ need to be transmitted.

[0024] Furthermore, a computer readable storage medium storing a computer program according to one of the aforementioned aspects may be advantageously proposed.

[0025] Aspects of the present disclosure may be implemented by an apparatus. The apparatus may include a processor and a memory coupled to the processor. The processor may be configured to perform methods according to aspects and embodiments of the present disclosure.

[0026] Furthermore, aspects of the present disclosure can be implemented by a program. When the instructions of the program are executed by a processor, the processor can perform aspects and embodiments of the present disclosure. A computer-readable storage medium can store the program. Such a computer-readable storage medium can include storage devices such as those described herein, including but not limited to random access memory (RAM) devices, read-only memory (ROM) devices, etc. Thus, some innovative aspects of the subject matter described in this disclosure can be implemented by one or more computer-readable storage media having software stored thereon.

[0027] It will be understood that features of the apparatus and method steps may be interchanged in many respects. In particular, details of a disclosed method may be implemented by a corresponding apparatus and vice versa. Furthermore, all statements above relating to a method apply equally to a corresponding apparatus and vice versa. [Brief explanation of the drawings]

[0028] [Figure 1] 1 illustrates a flowchart of one embodiment of a method for generating and comparing signatures of software packets. [Figure 2] 1 shows a schematic diagram of one embodiment of the production portion of the method shown. [Figure 3] 1 shows a schematic diagram of one embodiment of a method for selecting a hash value for a signature. [Figure 4] 1 shows a schematic diagram of an embodiment of a comparison of two signatures. [Figure 5] 1 shows a schematic diagram of one embodiment of an apparatus for generating and comparing signatures of software packets. DETAILED DESCRIPTION OF THE INVENTION

[0029] Detailed Description of the Preferred Embodiments In the following, exemplary embodiments of the present invention will be described in detail with reference to the exemplary figures. The features of the exemplary embodiments can be combined in whole or in part, and the present invention is not limited to the exemplary embodiments described.

[0030] FIG. 1 illustrates one embodiment of a method for generating and comparing signatures of software packets.

[0031] Here, in a first step S101, the digital objects belonging to the software packet are determined or identified. The software packet may be a pre-installation or a post-installation software packet. The different digital objects of the software packet can be determined accordingly. The only condition for these digital objects is that a hash value can be created or generated from them. Advantageously, the digital objects are one or more of the following objects:

[0032] Pre-installation files for the software Files after the software installation is complete Files displayed by the software when it is run The entire memory image of the software at runtime or a specific or non-specifically determined part of it · communication telegrams or parts thereof generated and transmitted by the Software when run;

[0033] · Hardware firmware identifier / serial number, as already mentioned later in this document.

[0034] As can be seen in Figure 2, a wide variety of objects associated with a software packet can be used. Files of a software packet can be identified or specified regardless of the application. For example, these can be files present before the software packet is installed or after the software packet is installed. Furthermore, these can be files created by the software packet during execution. Furthermore, communication telegrams or parts thereof created and transmitted by the software packet during execution can also be used. In specific applications, additional digital objects suitable for signature creation can be determined. Thus, when controlling a machine tool, for example, there are runtime memory areas for the HMI, CNC, and PLC subsystems, from which images can be created after the software is installed. This image is also suitable for identifying the software packet and is therefore also considered a digital object of the software packet. Furthermore, other binary representative artifacts, such as digitally readable hardware serial numbers, type identifiers, or revision identifiers of hardware modules associated with the software packet, can also be used. Particularly advantageously, subsystems of the controller that are not specific to firmware or software in the classical sense can also be identified, for example, when the controller uses ASICs for subfunctions. However, if these identifier specifications are made accessible to the system integrator, ie via an interface, they may also be subject to the method according to the invention.

[0035] Depending on the type of digital object, determining the digital object for identifying the software packet may require extraction or reading of the digital object, for example, a file or memory image must be copied or read from the machine tool's mass memory or controller for use in creating the signature in the following steps.

[0036] After all the digital objects of the software packet have been determined, hash values ​​or digital fingerprints of each digital object are generated or created in step S102. For this purpose, known hash algorithms such as MD-5, RIPEMD-160, SHA, or Whirlpool can be used.

[0037] Before a signature is generated from hash values, specific hash values ​​can optionally be pre-selected. This pre-selection is illustrated in FIG. 3. Pre-selection can help reduce the number of hash values ​​and limit them to the most meaningful hash values ​​for the software packet, corresponding to the associated digital object. The selection of these hash values ​​from all hash values ​​is preferably performed in a partially automated or automated manner. Thus, for example, a specific file format can be determined that has greater significance than other file formats for identifying the software packet. As an example, an executable file format can be particularly meaningful for the software packet because changes to the executable file format provide an indication of changes to the software packet. Furthermore, the selection of hash values ​​can also be performed based on changes to the digital object in different versions of the software packet. Thus, a digital object with minimal changes in multiple versions of the software packet is selected as a starting point for identification.

[0038] For example, consider a user interface (HMI) based on the Windows operating system and developed in the C++ programming language. A file ending in .exe is intended to be directly supplied to a processor in a machine-readable format. The processor directly processes the instructions in the .exe file using the data it also contains. Additionally, any changes in the instruction sequence, whether process or data, have direct functional implications for the software package. This file may also change if it is produced using a different production tool, such as when the software is changed from running on a 32-bit system to running on a 64-bit processor system. In this case, the software is clearly a different version, although functionally unchanged. On the other hand, if the accompanying comments or log file are changed, this may only occur within a two-hour period of operation of the same software. This can be taken into account in the development of the method according to the present invention.

[0039] Preferably, signature generation is based on the content of the digital object and preferably does not rely on existing metadata, so that digital objects can also be processed without relying on the respective metadata files (which may already exist for the digital object). As a result, an objective signature creation that is safe for manipulation and error-free can be achieved, since erroneous or manipulated metadata is not taken into account. This ensures that all signatures required for identification and checking can be obtained in a running system population. Therefore, the assignment of signatures to metadata or software and software version identifiers can also be performed later, based on signature data collected over the system population and, possibly, on assignments of the delivery state of the systems that were not explicitly created before. In addition, a security aspect is provided, since the generated signatures can establish whether there is a deviation of the digital object from the actual expected signature, and therefore tampering (e.g., computer security—detecting whether software has been hacked) can be inferred. Likewise, the collection of signature data collected in this way provides a basis for analysis of correlations with a population of operating systems, the distribution of their software constellations, or otherwise observed operating characteristics or disturbance accumulations.

[0040] In an optional additional step, the digital object can be cleaned up before processing for signature creation, in particular so that LOG files can be deleted, which can result in a faster and more secure process.

[0041] After generating the hash value, the hash value is merged with the signature of the software packet in step S103. When doing so, the merging of the hash value with the signature can be performed in three different ways.

[0042] In the first case, the hash values ​​of the digital objects in the software packet are stored in a hash table. Thus, the signature of the software packet consists of the individual hash values. This procedure allows for a very detailed comparison of two signatures and an accurate analysis of the differences.

[0043] In the second case, a global hash value is generated from the hash values. The signature therefore consists of the global hash value only. This makes the subsequent comparison of the two signatures particularly simple and efficient.

[0044] In the third variant, a global hash value is still generated, but in contrast to the second variant, both the global hash value and the individual hash values ​​of the digital object are stored as signatures, thus combining the advantages of the two previous methods.

[0045] In addition to the hash value according to one of the aforementioned variants, additional data can be stored in the signature. This is also represented diagrammatically in FIG. 3. Thus, for example, the name, version identifier, or content of the software packet can be stored in the signature in the form of metadata (this method can also be implemented, for example, with character or alphanumeric identifiers). These data can be used, for example, to determine which signatures should be compared with each other, or, if a difference is found between two signatures, to establish whether they should represent the same or different software packets, in light of the different objectives of the considerations being made. Preferably, after startup and before delivery of the machine, it is possible to check whether the correct software is installed and correctly parameterized. Therefore, an efficient check before delivery can be advantageously achieved by this optional step. In a further example, software configuration information can also be ignored in service incidents.

[0046] After the signature is created, it can be stored or can be stored in a variety of ways. Thus, the signature can be stored, for example, on the software creator's server. Furthermore, the signature can be stored in memory in which the software packet itself is also installed. The memory can be located, for example, in the controller of a machine tool. Furthermore, the signature can be stored on a local computer that can be connected to memory in which one or more software packets are installed.

[0047] After the signature is stored, it can be used to compare it with another signature created in the same way. This comparison is performed in step S104. In this case, the time at which the comparison is performed is not limited. Thus, for example, the comparison can be performed immediately after the installation of the software packet to ensure correct installation. Furthermore, the comparison can also be performed periodically, for example, to check whether the software packet has been modified or whether the software packet is installed with the current version.

[0048] In this case, the manner in which the comparison is performed depends on the type of signature. If only a single overall hash value is stored for the signature, a separate comparison of the two hash values ​​is necessary. The result of this comparison is therefore whether the associated software packets are identical or not. This type of signature is therefore only suitable for pure integrity determination and identification. Preferably, in one embodiment, each detailed object can be individually enumerated and mapped to a signature, and the selection of the associated subset of signatures is performed, for example, manually or in an automated manner. In the case of complex software constellations, a later switch to merged signatures is even possible to reduce the impact on the system's runtime characteristics. All data required for this purpose can be present (pre-stored) in a central database and does not need to reach the systems delivered for this purpose.

[0049] Alternatively, if the individual hash values ​​of the digital objects of a software packet are stored as signatures, all the hash values ​​of one signature must be compared with all the hash values ​​of the other signatures. The result of this comparison provides information about the size of the difference between the two software packets. It is therefore possible to reconstruct which digital objects, e.g., files, have been modified or exchanged. This type of comparison is shown diagrammatically in Figure 4.

[0050] Furthermore, if both the overall hash value and the hash values ​​of the individual digital objects are stored as signatures, the above comparisons can be combined: in this case, only the two overall hash values ​​are compared, and only if they are unequal are the individual hash values ​​compared to each other.

[0051] Comparison of hash values ​​can be used for a variety of purposes. Thus, for example, the integrity of a software packet can be established, to establish modification of individual digital objects within the software packet. Furthermore, comparison can be used to establish multiple installations of the same software packet or different versions of a software packet. Furthermore, comparison can be used to establish the version of a software packet.

[0052] Advantageously, the comparison of the first signature with the second signature can serve one or more of the following purposes: checking the integrity of the first software packet, detecting the version of the first software packet, assigning the version of the first software packet, detecting multiple installations of the same software packet, and / or detecting installations of different versions of the same software packet.

[0053] The version check via the signature can further be used to perform an efficient update process of the software packet. If the version check establishes that the software packet is not the current version, files that differ between the current version and the old version of the software packet can be determined via a hash value of the current software packet (e.g., stored on a server) that does not match the hash value of the checked software packet. Therefore, only files that are actually different in both versions of the software packet can be provided for the update process. In this way, the update process can be performed very efficiently, and only the minimum required amount of data needs to be transmitted. In this way, the identification of the required data is automated.

[0054] While methods for generating and comparing signatures of software packets have been described above, the present disclosure also relates to corresponding apparatus, an embodiment of which provides such an apparatus is described below with reference to FIG.

[0055] As shown in FIG. 5 , the apparatus 500 includes a processor 501 and a memory 502. Here, the memory 502 is configured to store program code. The processor 501 is further configured to execute instructions in the program code so that the apparatus 500 performs the software signature generation and comparison in one of the above-described embodiments and implementations. Furthermore, the processor 501 can receive appropriate input data (e.g., files and memory images), among others, depending on the application and / or implementation. The processor 501 can be configured to execute a method described in the present disclosure (e.g., method 100 described above with reference to FIGS. 1-4) and generate corresponding output data (e.g., a generated signature or a result of comparing two signatures) depending on the application and / or implementation. The apparatus may be part of a server connected to a memory in which the software packet is located. Alternatively, the apparatus may be part of a local computer that can be connected to a memory, for example, a controller of a machine tool in which the software packet is installed. Furthermore, the apparatus can be part of the system of the machine tool's controller, as long as it is suitable for such system integration.

[0056] Depending on the desired use, the present features, components, and specific details can be interchanged and / or combined to create further embodiments, and any variations within the knowledge of one skilled in the art are implicitly disclosed herein.

Claims

1. A computer implementation for generating and comparing software packet signatures, - To determine the digital object belonging to the first software packet, - The hash value of the digital object, which generates a hash value corresponding to the digital object, - Merging the hash value into the first signature of the first software packet, - Comparing the first signature with the second signature, which is the signature for the second software packet. A method of implementation by a computer, including the methods described above.

2. The computer implementation method according to claim 1, wherein the digital object includes at least one of a file, a PLC memory image, an HMI memory image, a CNC memory image, or other binary representative data of the first software packet.

3. The computer implementation method according to claim 2, wherein the PLC memory image, the HMI memory image, and the CNC memory image include only partial memory images of the corresponding overall memory image, and / or the partial memory images are selected based on predetermined rules, the predetermined rules being based on the purpose of using different parts of the memory image relating to the software packets.

4. The computer implementation method according to claim 1, wherein the first and second software packets are control software for a machine tool and / or an automatic device for loading a machine tool.

5. A computer implementation method according to claim 4, wherein determining a digital object belonging to the first software packet includes extracting the digital object from the control unit of the machine tool, and / or determining a digital object belonging to the first software packet includes reading the digital object from a data memory storing the software packet.

6. Generating a hash value for the aforementioned digital object is, - Selecting a subset of the digital objects based on the relationships of the digital objects with respect to the first software packet, - To generate the hash value for each digital object within the subset. A method of implementation by a computer according to claim 1, including the method described in claim 1.

7. The computer implementation method according to claim 6, wherein the association is determined based on at least one of the type of the digital object and the distribution of the digital object across different versions of the first software packet.

8. The method implemented by the computer according to claim 1, wherein generating a hash value for the digital object comprises applying a hash algorithm to the digital object, the hash algorithm preferably comprising at least one of the following methods: MD-5, RIPEMD-160, SHA, or Whirlpool.

9. Merging the hash value into the first signature of the first software packet includes generating the first signature by storing the hash value as a hash table, and / or A computer implementation of claim 1, further comprising merging the hash value into a first signature of the first software packet to generate metadata for the first signature.

10. The computer implementation method according to claim 9, wherein the metadata includes at least one of the identifier, version number, or content instruction of the first software packet, and / or the metadata is determined from the digital object.

11. The computer implementation method according to claim 1, wherein the second signature from the second software packet is generated in the same manner as the first signature from the first software packet according to claim 1, and / or the second signature resides on a server or a local computer, the server or the local computer being connectable to the device on which the first software packet resides.

12. The first software packet and the second software packet have the following relationship, namely - The first software packet and the second software packet are identical. The first software packet is an manipulated variant of the second software packet. The first software packet and the second software packet are different versions of a certain software packet. - The first software packet is a modified variant of the second software packet, or - The first software packet and the second software packet are not similar. A method for a computer to implement the computer described in claim 1, having one of the following.

13. Comparing the first signature with the second signature is Comparing each hash value of the first signature with each hash value of the second signature. A method of implementation by a computer according to claim 12, including the following:

14. Output the match between the hash value of the first signature and the hash value of the second signature. A computer implementation method according to claim 13, further comprising:

15. If, during version detection, it is established that the second software packet is a more recent version of the first software packet, Based on the output of the match between the hash value of the first signature and the hash value of the second signature, the first software packet is updated to the second software packet. A computer implementation method according to claim 14, further comprising:

16. The computer implementation of claim 15, wherein updating the first software packet is performed only on digital objects corresponding to the hash value of the second signature that is not equal to the hash value of the first signature.

17. It comprises a processor and memory connected to the processor, The processor is configured to perform the method described in any one of claims 1 to 16.

18. A computer program comprising instructions, the instructions, when executed by the processor, causing the processor to perform the method according to any one of claims 1 to 16.

Images