WO2006021174A1

WO2006021174A1 - Software backup method

Info

Publication number: WO2006021174A1
Application number: PCT/DE2005/001294
Authority: WO
Inventors: Joachim Seibert
Original assignee: Wincor Nixdorf International Gmbh
Priority date: 2004-08-20
Filing date: 2005-07-22
Publication date: 2006-03-02
Also published as: EP1779282A1

Abstract

The invention relates to a software backup method for a computer system which is provided with a defined operating system against the manipulation of workfiles that are stored in a utilized primary data area which is conventionally managed by the operating system. For this purpose, backup copies of the workfiles to be protected from manipulation are stored in a secondary data area and are protected by preferably asymmetric cryptography. A comparator compares the backup copies or the proof total thereof with the respective work files and initiates a corrective action if any differences are found.

Description

Software assurance procedures

The invention relates to securing the software of a computer system against manipulation.

For example, in ATMs, commercial computer systems are used to control the process, communication with a bank host, as well as the user interface. The use of commercial proprietary operating systems such as Microsoft Windows has the advantage of a large software base, but currently has the disadvantage of being insufficiently protected against manipulation, as may result from the unauthorized modification, in particular of files such as viruses, worms or other harmful software ,

Patent Specification US Pat. No. 5,224,160 describes a method in which, during the charging process of the operating system, the respectively active charging stage checks the respective subsequent charging stage for integrity by means of a cryptographic checksum and the charging process is continued only if the integrity is ensured. However, this does not check changes during ongoing operation. In addition, an intervention in the loading of the operating system is necessary and therefore in proprietary systems only feasible by the manufacturer.

In the patent US 5,361,359 it is proposed to store the executable programs and other data to be protected on a protected data carrier and to make programs only from there. This solution also requires an intervention in the respective operating system.

US Pat. No. 6,209,099 B1 proposes, similar to US Pat. No. 5,224,160, a cryptographic processor by which all executable programs are checked for integrity.

In the patent US Pat. No. 5,475,625, it is proposed that a monitoring computer regularly send checksums from the network to be monitored via a network Request files that are generated by a server process, sent to the monitoring client via the network and compared there with setpoints. This allows you to monitor any files. The separation of monitoring in client and server reliably prevents falsification of the stored checksums; however, a malicious program may substitute the server process on the host being monitored and still provide the previous checksums, even though the files have been modified. Although a monitoring computer can be assigned to several computers to be monitored; however, it always requires an additional computer and a network connection. Furthermore, there is no possibility for repair from this solution.

The present invention solves the problem of securing on one and the same computer system the software running on it and other constant databases against manipulation by early detection of manipulations and their automatic repair.

For this purpose, a backup copy of all files to be protected is stored by the files to be protected in an autonomous data area and regularly compared with the working files. If a deviation is detected, the working files are replaced by the backup files.

It is the backup of a computer system with a given operating system against manipulation of working files that are located in a conventionally managed and used by the operating primary data area, stored in a secondary data backup copies of protected against manipulation work files and preferred by asymmetric cryptography, a comparator that compares backup copies or their checksums with the respective working files and triggers a corrective action if differences are detected.

In Fig. 1, the arrangement is shown symbolically. A computer system (not shown) has a primary data area 1, which preferably is a partition of one

Hard disk is. Furthermore, there is a secondary data area 2, which is another partition of the same size, on the same hard disk. Of the primary data area 1 contains three working files 1A, 1B, 1C, of which the former and the latter have a back-up copy 2A ₁ 2C. A monitor 4 compares the working files 1A and 1C with the backup copies 2A and 2C. If a difference is detected, the corrective action 5 is initiated, for example, replacing the work file 1A with the backup file 2A. To create or modify a backup file, an update process 6 is used.

The primary data area is in particular a partition for a Microsoft Windows operating system, here formatted as an NT file system.

In the simplest case, the secondary data area 2 is also a partition with NT file system, in which the backup files are stored in relation to the naming conventions in the same way as in the primary data area 1. However, using Windows (NT based) safeguards, an additional administrative user is created who has sole access to the backup files. The monitoring is performed by a system service that is run under the identity of this user and thus has exclusive access to the backup files. The corrective action runs as started by the monitoring service with its privileges and can therefore access the backup copies.

Alternatively, the comparator may use a file system that is not supported by the operating system used, for example, a Linux extended file system, while the primary data area is formatted with an NT file system.

In this case, where the files are compared byte by byte, the backup copies should be cryptographically secured against change. This can be done by encryption. However, the comparator then can not easily tell if the decrypted backup file is correct. When using block ciphers, each input leads to a decrypted output that contains no easily recognizable redundancy, especially for binary files. This could be the change of a Backup copies by the automatic correction destroy the previously correct work file.

Therefore, preferably a cryptographically secured checksum per file is formed, also referred to as 'message digest'. This is additionally maintained in a table (database) in which these checksums are stored for each file. Then only this table needs to be protected against change.

A conventional solution is to encrypt the table with symmetric cryptography and provide redundancy so that an attacker without the corresponding key can not replace the table with another one. As redundancy, a title line with a predefined one is sufficient

String and a version number at the beginning and a sum line with

File version number at the end of the table file, if one of the 'chaining modes' is used to encrypt a wrong insertion

Prevent blocks.

Preferably asymmetric or public-key cryptography is used, in which the public key does not have to be kept secret. For the comparison process only the public key is necessary; only for

Changes the private key is needed to re-create the signature. Particularly useful here is the use of OpenPGP, the world's most widely used cryptographic standard for e-mails, with which not only files can be signed via a command interface, but also the keys can be managed. The public key is expediently stored in several places and checked for equality before use. So it can be stored both in the program code, in the table of checksums and in a file; a damage program would have to modify all three places simultaneously. Unlike private or secret keys, this measure increases rather than lowers security.

On a self-service device, a special keyboard, an EPP (Encrypted Pin Päd) is available for storing the keys, which protects the keys against unauthorized access. The comparator then only needs to compare the checksums of the working files with those stored in the table. If the work file containing the backup copy is to be replaced as a correction action, it must first be checked whether the checksum from the backup file matches that in the backed-up table. Both require only the integrity-secured public key. The programs are therefore preferably stored on write-protected data carriers such as CD-ROMs or hardware-protected FLASH memories, so that they can not be changed by a damage program.

When modifying the work files and thus the backup files, on the other hand, not only the checksums must be created, but also a new signature must be created using the table of checksums. The updater required for this must be present on the computer only for the duration of the update. For example, if the update is done on a CD-ROM, the updater is already protected against change. Since the time window for this is small compared to the other operating time, the necessary private key can be stored either in the program code of the updater or in a separate file. In the case of an update through network connections, the updater, possibly also the file with the private key, is only temporarily loaded onto the target computer and overwritten after use. Outside these times, a malicious program has no way to manipulate the checksum table. Instead of using an updater, the new table can also be created in a management computer, which in any case has the checksums of the software integrated on the computer. Then the update program only has to copy the changed work files to the secondary data area; the private key never appears on the computer to be monitored.

It makes sense to use several individually signed tables, possibly with different public keys. This is the case in particular when part of the checksums are provided by the management computer and the other part is calculated locally. The checksums for the comparator and updater are then expediently in the table signed by the administration computer. Since it frequently happens that several files belong together and may only be replaced together, it is provided in a further development of the invention that these groups of files are defined in the table or by other means. At a minimum, all files in the group are compared and then the changed files are copied. Alternatively, even when a change is made for the first time, it is important to ensure that all work files are replaced by their backup files.

A development of the invention uses a cryptographic processor, as it is installed, for example, as PIN-PAD in the keyboard of a cash dispenser. On the one hand, this provides a secure key memory with the usual cryptographic functions. Thus, the comparator can consist of a relatively small launcher and the remainder of the program, the launcher first checking its own integrity by sending its own code to the cryptographic processor. Conveniently, the request contains a random number ('nonce'), which is returned in the response and can be checked via a 'message authenticatio code' (MAC). The launcher then loads the remainder program, checks its integrity, and passes control if the test is positive.

A specialization of the training uses the condition that transactions are handled via the PIN-PAD. In this case, a valid code key must be transmitted to the PIN-PAD as part of a transaction. In the simplest case, the comparator forms the checksum over the checksums, signs them and sends them to the PIN-PAD. We prefer not to transmit the same checksum again and again; rather, a random number is requested from the PIN-PAD and included in the signed response, so that each time results in a different answer. Only when there is a validly signed answer is the transaction confirmed; otherwise the ATM is locked.

Claims

claims

1. Device for securing a computer system with a given operating system against manipulation of working files, having the features: - the working files are located in a primary data area conventionally managed and used by the operating system,

- in a secondary data area, backup copies of the work files to be protected against manipulation are stored,

a comparator is provided for checking the working files for the respective backup copies and for triggering a signal when differences are detected.

2. Device according to claim 1, wherein the working copy is replaced by the backup copy as a result of the triggered signal.

3. The device of claim 2, wherein groups of files are formed and the replacement of the modified working copies by the respective backup copies takes place as a unit.

4. Device according to one of claims 1 to 3, wherein the secondary data area is protected by security functions of the operating system against changes.

5. Device according to one of claims 1 to 3, wherein the secondary data area is protected against changes, that is used for formatting an unsupported by the operating system file system format.

6. Device according to one of claims 1 to 3, wherein the secondary data area is protected against changes that the files are backed up by cryptographic functions.

7. Device according to one of claims 1 to 3, wherein the examination of the working files by forming a cryptographic checksum is compared by means of a table, in the table, the checksums are stored on the backup copies and this table is cryptographically secured against unauthorized change ,

8. Device according to claim 7, wherein the safeguard against unauthorized change is achieved by asymmetric cryptographic methods.

9. Device according to claim 7 or 8, wherein an optionally provided updater and / or another file for cryptographic keys are present only for the duration of the update on the computer system.

10. The device of claim 7 or 8, wherein a cryptographic key is stored in a secure cryptographic processor.

The apparatus of claim 10, wherein the computer comprises means for handling transactions by means of a cryptographic processor, and each transaction must be released by the handover of a checksum from the comparator.

The apparatus of claim 12, wherein the checksum is supplemented by a random transaction ID issued immediately before by the cryptographic processor and then signed by the comparator.

13. A method for securing a computer system with a given operating system against manipulation of working files, having the features:

the work files are located in a primary data area conventionally managed and used by the operating system, in a secondary data area are stored backup copies of the work files to be protected against manipulation, a comparator checks the working files for the respective backups and triggers a signal if differences are detected.

14. The method of claim 13, wherein as a result of the triggered signal, the working copy is replaced by the backup copy.

15. The method of claim 14, wherein groups of files are formed and the replacement of the modified working copies by the respective backup copies takes place as a unit.

16. The method of claim 13, wherein the secondary data area is protected against changes by security functions of the operating system.

17. The method according to any one of claims 13 to 15, wherein the secondary data area is protected against changes that is used for formatting an unsupported by the operating system file system format.

18. The method according to any one of claims 13 to 15, wherein the secondary

Data area is protected against change by backing up the files with cryptographic functions.

19. The method according to any one of claims 13 to 15, wherein the examination of the work files by forming a cryptographic checksum is performed, which is compared by means of a table in which checksums on the Sicherungs¬ copies are stored, this table is cryptographically secured against unauthorized change ,

20. The method of claim 19, wherein the protection against unauthorized

Change is achieved by asymmetric cryptographic methods.

21. The method of claim 19 or 20, wherein an updater and a possibly needed file for cryptographic keys are not available or only for the duration of the update on the computer system.

22. The method according to claim 19 or 20, characterized in that the keys are stored in the EPP (Encrypted Pin Päd).