DE102018113148A1 - Method for audit-proof storage of data - Google Patents

Abstract

The present invention relates to a method for tamper-proof storage of data, by means of which changes to electronic documents, in particular e-mails, electronic invoices, POS data or the like, which are present as electronic file (D) can be detected, whereby from the file (D), which is stored on a client computer (client, 100), in the first step a hash value (CS) is calculated (101), this hash value CS via a network (in particular via the Internet) to a second server computer (server, 200 ) is transmitted via an interface (201), on the server a continuous, not yet assigned document number (DOKNR) is determined (202), (CS) and (DOKNR) stored in a file or database (DB, 203) on the server in which the server has an interface (201) which at least allows it to receive a hash value CS in order to store it in a file or database (DB, 203) which at least avoids it to return a stored record (CS, DOKNR) that does not allow any records (CS, DOKNR) stored on the server to be removed, changed, or overwritten.

Description

The present invention relates to a method for audit-proof storage of data, by means of which changes to electronic documents, in particular e-mails, electronic invoices, POS data or the like, which are present as an electronic file (D) can be determined, the immutability of the documents verifiable and manipulations are preventable.

In the prior art, the storage of data usually takes place on a data carrier such as a WORM medium (CD, DVD, WORM tape drive), ie a storage medium which can only be written once and the deletion, overwriting or Permanently excludes changing the data on the storage medium.

Another possibility is the use of electronic archive systems, which work with mechanisms such as containers, hash codes, authorizations and logging. In addition, authorizations in the operating system of the clients and servers, the database and the backup process can be assigned and organizational regulations, such as the dual control principle in administration, regular audits, access controls and work instructions are met.

The object of the present invention is to provide a method for audit-proof storage of data which meets higher security requirements than the previously known methods and in particular also satisfies the principles of proper bookkeeping and documentation according to GoBD.

The solution to this problem provides a method for audit-proof storage of data with the features of claim 1.

The present invention thus provides a method for detecting changes, in particular to accounting-related electronic documents, in particular e Emails, electronic invoices, cash register data or the like, which are available as an electronic file D with the aim of making the documents immutable by the accounting subject P ensure or prevent tampering, from this file D displayed on a client computer (client, 100 ), in the first step a hash value CS the file D is calculated ( 101 )
this hash value CS via a network (in particular via the Internet) to a second server computer (server, 200 ) via an interface ( 201 ) is transmitted
where on the server is a continuous, not yet issued document number DOKNR is determined ( 202 )
CS and DOKNR in a file or database ( DB . 203 ) are stored on the server,
where the server has an interface ( 201 ) that at least allows it,
a hash value CS to receive it in a file or database (DB, 203 ) to save
which at least allows a stored data set ( CS . DOKNR ) return,
However, it does not allow records stored on the server ( CS . DOKNR ), changed or overwritten.

According to the invention, the hash value of an electronic file is calculated in the first step. This can be done according to a common method, for example a "message digest algorithm 5 "( MD5 ) happen. The hash value calculated in this way is then stored, for example, on a server on the Internet. The storing person has no deleting access to this Internet server. It can not change or delete a stored value there.

Since the hash value of the file changes when the file itself changes, for example, by adding or deleting one or more characters in the file, this method can be used to detect a subsequent change of the file. This is particularly important for accounting-related electronic documents (invoices, POS data, etc.) that must be stored in accordance with the "Principles for the Proper Management and Retention of Books, Records and Records in Electronic Form and for Data Access (GoBD)" subsequent changes become visible.

By comparing the hash value of the file at a particular time and the hash value of the file stored on the Internet server (unchangeable for the person storing or another person in the company), it can be determined whether the file is changing in the meantime has been. This is the case if the hash values are different.

The inventive method has the advantage that the hash value is not stored on the local computer or on another computer in the local network of the accountable person, but is transmitted via the Internet to a second computer to which the person has no deleting or changing access , It is therefore not a process that can be realized solely by software.

In order to rule out that the hash value of a file stored on the Internet server may be changed / deleted by the Internet server administrator, the hash value can additionally or alternatively also be stored in a blockchain, which generally guarantees an unchangeable storage of values. A blockchain is a continuously expandable list of records called "blocks" that are concatenated using cryptographic techniques. Each block typically contains a cryptographically secure hash value (scatter value) of the previous block, a time stamp and transaction data. The blockchain approach can be used to decentralize an accounting system and to reach consensus on the correct state of accounting, with a larger number of people taking part in the bookkeeping.

Compared to known methods, the inventive method has a number of advantages. To ensure the immutability of a file, the file does not need to be copied to a so-called WORM medium, which may cause additional costs and / or poorly suited for automatic operation, but may be stored in any location.

To ensure the immutability of a file, the file need not be transferred to a web server on the Internet. This might not be desirable for sensitive (accounting) data. It is sufficient to transfer only the hash value of the file.

To ensure the immutability of a file, the hash value of the file is not stored locally, for example, in a database to which a person of the company has access rights, which makes a subsequent change by a person of the company possible. Instead, the hash value is transferred to a server where the hash value can no longer be changed, overwritten or deleted by the storing person. This is ensured by a suitable interface on the server.

By storing the hash value of the file additionally or exclusively in a blockchain, it can also be ensured that the stored hash value can not be changed by any person (not even, for example, by the administrator of the internet server) after storage.

The immutability of a file can be ensured by comparing the hash value of the file stored on the server with the hash value of the file calculated at the time of the comparison. If the two values are different, the file was changed after the hash value of the file was saved to the server. Through an appropriate interface, the hash value of the file stored on the server can be retrieved from the server.

According to a preferred embodiment of the invention, in addition to the hash value CS additional data belonging to the file ZUS transferred from the client to the server and stored on the server in a file or database ( DB . 203 ), which may be, in particular, a file name and a file path of the file.

According to a preferred embodiment of the invention may be on the server 200 next to the hash value CS and optionally the previously described data ZUS and the document number DOKNR In addition, the current date DAT determined and stored in a file or database ( DB . 203 ) get saved.

According to a preferred embodiment of the invention may be on the server 200 next to the hash value CS and optionally the data described above ZUS . DAT and the document number DOKNR additionally a hash value CS2 of this data (which is determined by all or part of these data 205 ), together with the data described above in a file or database ( DB . 203 ) get saved.

According to a preferred embodiment of the invention, the client 100 in addition to the data described above, a string BID which uniquely identifies the respective user and which together with the data described above in a file or database ( DB . 203 ) can be stored.

According to a preferred embodiment of the invention, the client 100 in addition to the data described above, a string PW to the server 200 transfer, which serves as a password and the interface 201 makes it possible to carry out subsequent actions only when the correct password is transmitted, or to refrain from doing so if the password is incorrect, in which case the password is BID assigned.

According to a preferred embodiment of the invention, the above data CS , possibly ZUS , possibly DAT . DOKNR , possibly CS2 , possibly BN - possibly only partially - from the server 200 additionally or alternatively for storage in a database ( DB . 203 ) in a blockchain 300 be transferred and stored there.

According to a preferred embodiment of the invention, the above-mentioned data CS, if necessary ZUS , possibly DAT . DOKNR , possibly CS2 , possibly BN - possibly only partially - directly from the client 100 be transferred over the Internet in a block chain and stored there and this data can DOKNR and optionally DAT and optionally BN on the client 100 be determined.

According to a preferred embodiment of the method according to the invention, for example, more than one file can be processed simultaneously.

The features mentioned in the dependent claims relate to preferred developments of the task solution according to the invention. Further advantages of the invention will become apparent from the following detailed description.

• 1 eine schematische Darstellung der Arbeitsweise der erfindungsgemäßen Verfahrens gemäß beispielhafter Ausführungsvarianten.

Hereinafter, the present invention will be explained in more detail by means of embodiments with reference to the accompanying drawings. It shows

• 1 a schematic representation of the operation of the method according to the invention according to exemplary embodiments.

EXAMPLE 1:

In a first exemplary embodiment, a sets PC the client 100 on which, for example, a Windows program is installed, which has the hash value CS a revision-proof file to be filed D (For example, an e-mail with attached invoice in PDF format or an outgoing invoice in MS-Word format) via a common method (eg MD5 or SHA- 1 , SHA- 2 ) and this value CS , additional data ZUS such as the local file path and file name of this file as well as a user ID stored in the Windows program BID and a password PW via an HTTP request S1 . 201 to a server 200 sent. This server 200 is over the internet with the client 100 connected and evaluates the data sent via HTTP. First, it checks if the BID on the server 200 is known and if the password PW correct is. If so, the following procedures are performed.

In the following step, a new, unique document number will be created DOKNR determined for the file D. 202 , This is done by checking which document numbers have already been stored on the server. For example, if the document numbers are numeric, the new one may be DOKNR can be determined by adding 1 to the last-generated document numbers DOKNR_i-1. In an alternative embodiment, however, other algorithms are possible that have a unique DOKNR generate, for example, for alphanumeric document numbers. In the next step 204 will be the current date including time DAT on the server 200 certainly. Subsequently, the whole data set D1A = (CS, ZUS, BID, DOKNR, DAT) becomes a hash value CS2 with a common method (eg MD5 or SHA- 1 , SHA- 2 ) certainly. Depending on the design can CS2 also from a reduced data set, such as D1B = (CS, ZUS, BID, DOKNR). A new record D2 = (CS, ZUS, BID, DOKNR, DAT, CS2 ) is then entered as a new line in the database ( DB . 203 ) saved.

In addition, there is a blockchain client on the server (eg for the Ethereum Blockchain) 206 installed, with the help of which data from the previously discussed record D2 into the appropriate blockchain 300 can be stored. Depending on the version, this could also be a subset of D2 D2A = (DOKNR, CS), D2B = (BID, DOKNR, CS), D2C = (DOKNR, CS2), D2D = (BID, DOKNR, CS2), etc.

To check that the respective files are from the client 100 have not been changed, via an interface on the server 201 , for example, with an HTTP request that is in the database DB 203 stored data sets are retrieved completely or partially. For example, the CS to a certain DOKNR or a list of all on the server 200 stored CS and their respective ones DOKNR be retrieved via HTTP and with the actual hash values of the respective files on the client 100 be compared.

Similarly, through a suitable blockchain client, the records stored in the blockchain can be retrieved and compared against the client data.

EXAMPLE 2

In a second exemplary embodiment of the invention, the client is 100 a computer (eg a Raspberry Pi) with a Linux operating system installed on it. On the client 100 In addition, cash register software runs which, as part of a financial statement (for example, daily), creates a file containing all business transactions relevant to accounting, such as products sold and information about these business transactions, such as the amount of revenue. This file is then stored in a revision-proof manner as described in Example 1, beginning with the determination of a hash value CS for this file.

LIST OF REFERENCE NUMBERS

100

Client computer

101

Calculation of the hash value

200

Server computers

201

interface

202

Determination of the document number

203

Database

204

Determination of the date

205

Determination of the hash value CS2

206

Block Chain client

300

block Chain

Claims (9)

Method for audit-proof storage of data, by means of which changes to electronic documents, in particular e-mails, electronic invoices, cash register data or the like, which are present as electronic file (D), can be ascertained, the immutability of the documents can be ensured and manipulations can be prevented, characterized in that, in the first step, a hash value (CS) is calculated (101) by the file (D) which is stored on a client computer (client, 100), this hash value CS via a network (in particular via the Internet) a second server computer (server, 200) is transmitted via an interface (201) that a continuous, not yet assigned document number (DOKNR) is determined on the server (202), (CS) and (DOKNR) in a file or Database (DB, 203) are stored on the server, wherein the server has an interface (201) that at least allows to receive a hash value CS, d to save them to a file or database (DB, 203) which at least allows to return a stored record (CS, DOKNR), which does not however allow records (CS, DOKNR) stored on the server to be removed, changed or overwritten become. Method according to Claim 1 , characterized in that in addition to the hash value CS additional data belonging to the file ZUS transferred from the client to the server and stored on the server in a file or database (DB, 203), in particular a file name and / or a file path of the file. Method according to Claim 1 or 2 , characterized in that on the server (200) in addition to the hash value CS and possibly the in Claim 2 also describes the current date, if necessary with time DAT and stored in a file or database (DB, 203). Method according to one of Claims 1 to 3 , characterized in that on the server (200) in addition to the hash value CS and possibly the in Claim 2 and 3 In addition, a hash value CS2 of this data (over all of these data mentioned or partially) is also determined 205 (205) and together with the data described in FIG Claim 1 to 3 stored data in a file or database (DB, 203) is stored. Method according to one of Claims 1 to 4 , characterized in that the client (100) in addition to the in Claim 1 and 2 described data transmits a string BID, which uniquely identifies the respective user and together with the in Claim 1 to 4 stored data in a file or database (DB, 203) is stored. Method according to one of Claims 1 to 5 , characterized in that the client (100) in addition to the in Claim 1 . 2 and 5 described data transmits a string PW to the server (200), which serves as a password and the interface (201) allows to perform subsequent actions only on transmission of the correct password or to omit this in an incorrect password, the password is assigned to the BID , Method according to one of Claims 1 to 6 , characterized in that the in Claim 1 to 5 CS, possibly ZUS, if necessary DAT, DOKNR, possibly CS2, possibly BN - possibly only partially - from the server (200) additionally or alternatively for storage in a database (DB, 203) in a block chain (300) and there get saved. Method according to one of Claims 1 to 6 , characterized in that the in Claim 1 to 5 CS, possibly ZUS, possibly DAT, DOKNR, optionally CS2, possibly BN - possibly even only partially - directly from the client (100) via the Internet into a blockchain and stored there and that in this case the data DOKNR and possibly DAT and optionally BN on the client (100) are determined. Method according to one of Claims 1 to 8th , characterized in that more than one file are processed simultaneously.

Images