METHOD FOR STORING ELECTRONICALLY SIGNED DOCUMENTS

Description

[0001] The present invention relates to a method for storing electronically signed documents, in which at least one signature file of a signatory of the signed document, stored in a database of a database server in connection with the signed document, is associated with an electronically signed document as a link between the document itself and a certificate uniquely assigned to the signatory.

[0002] Such a method is already known from AT 509 043 B1. Further prior art references are WO 01 / 13574 A1 and US 2016 / 335479 A1.

[0003] Such methods are already well-known in the prior art. For many centuries, contracts, declarations, and other documents of various kinds have been authenticated by their signatures. The signature transforms a simple document into a legally binding document, so the authenticity of a signature has always been questioned. For example, legal acts in the Middle Ages were authenticated by stamped seals, which were practically forgery-proof for that time.

[0004] Later, handwritten signatures, sometimes in the presence of witnesses, became the legally binding signature in Europe, while in Asia, name stamps are still frequently used. Particularly important contracts are still signed before a notary public today so that their certification can be relied upon.

[0005] However, these solutions can only be transferred imperfectly to electronic legal transactions, where, in particular, communication and the signing of contracts or other documents no longer necessarily take place in the presence of the contracting party or recipient of the declaration.

[0006] A simple, rather rudimentary way to transfer handwritten signatures to electronic legal transactions is to use an image of the signature. With appropriate software, this can either be placed in its entirety on a signature field or transferred directly into an input field via an electronic input device. However, since the other party is usually not personally present when signing, there is a risk that the signature could be used by an unauthorized person, thus concluding a legal transaction in the signatory's name that they may not have intended or even been aware of.

[0007] A well-known system takes this a step further, using a document stored in the so-called cloud—a database system accessible via the internet. To obtain a signature for this document, a cover letter is sent to the desired signatory's email address, who can then sign the document by clicking on a link in the internet. However, authentication in this system relies solely on the assumption that the email actually reaches the intended recipient. If, for example, a third party gains access to this cover letter due to intercepted emails, email forwarding, or shared login credentials, then this third party can conclude the legal transaction in the name of the intended recipient without any further authentication.

[0008] Once a document has been signed and is stored in this state in an online archive, there is no guarantee that no further changes will be made to the document after the signature. A document signed in the manner described above could be tampered with and saved again with changes without a subsequent viewer necessarily noticing.

[0009] Against this background, the present invention aims to provide a method for storing electronically signed documents which overcomes the disadvantages of the prior art and enables both a secure method of storing signed documents and an associated method for signing electronic documents.

[0010] This object is achieved by a method according to the features of claim 1. Further useful embodiments of such a method can be found in the subclaims.

[0011] According to the invention, a database is implemented in the broadest sense, in which a document is stored that is to receive a legally binding signature. A document is understood to be any type of binary content, including text documents, videos, images, and data streams. A database can be a dedicated database system or a simple storage system, such as one organized via a directory structure. Once the signature has been created, which can be done by any number of signatories per document, a signature file is generated using a certificate uniquely assigned to at least one signatory and stored in the database in conjunction with the document, i.e., linked to it. In the case of a single signatory, a fully signed document therefore consists of the document itself and a signature file, which is a link between a certificate and the document.

[0012] An optional aspect of the invention is that the database server to which the database is assigned creates an electronic fingerprint for both the signature file and the document itself, and preferably also a further electronic fingerprint encompassing all components. If the signature associated with the document is questioned, both files, and optionally their combination, are checked and verified for integrity using these fingerprints. Only if the integrity of all components is preserved can it be determined with certainty that the document and its associated signature are still the correct document.

[0013] Creating such a fingerprint, and conversely, verifying its integrity on the part of the database server, can be achieved, for example, by calculating a checksum. Using a so-called hash function is also a common method for creating such an electronic fingerprint. This involves mapping complex input values ​​to compact hash values, which are preferably scalar variables. The computability of a scalar hash value for complex input values ​​allows for the derivation of a compact electronic 'fingerprint' of a document, which can be quickly verified. If one document differs from another, its hash value will also differ in the case of a perfect, i.e., unique, hash function.

[0014] To later determine during integrity checks whether the checksums or hash values ​​match the files—that is, the signature file and the document—these are recalculated based on the available documents and compared with the stored electronic signature file. If the stored signature file differs from the recalculated values, the integrity of the document is called into question. This can be done, for example, via a web browser accessing the database server. However, it can also be done directly via a mobile device app, possibly using a QR code that is scanned by the mobile device and accessed through the app.

[0015] Other possible forms of electronic signatures for documents can also be used without hesitation and can seamlessly integrate into the context of the invention; however, a limitation of the invention to checksums or hash functions is not intended.

[0016] If a document is now stored in the database, the database server will first create an electronic fingerprint, thus protecting it from changes. The person storing the document, or another authorized person, can then add the identifier of a signatory to the document, from whom a signature is required. This doesn't necessarily have to involve the signature of a contract or the like; rather, the simple approval of an order, confirmation of the authenticity of information, and much more can be handled by storing and subsequently signing a corresponding document using the inventive solution.

[0017] An identifier for the signatory must be pre-stored on the database server, and different authentication levels can be used for this purpose. The system allows for simple or more complex authentications, which must be performed once before using the system. After this initial authentication, the inventive method proceeds identically for all authentication levels. For example, if a signatory is personally known, they receive a high authentication level. If authentication is performed solely via email, the authentication level is exceptionally low.

[0018] Once the ID of the desired signatory is stored, the database server will link the ID to the document to be signed, thus determining the corresponding signatory of the document. This makes it impossible for another signatory to sign the document. If, during the signatory's authentication, the signatory's signature file and the ID assigned to the document do not match, the database server will not accept the signature. However, if the database server accepts the signatory's signature file because it matches the ID, the database server will store the signature file provided by the signatory in the database and link it to the document. Electronic fingerprints are also created for the signature file and the link.

[0019] It is advantageous to import the signature file from the signer's mobile device, on which the signer both stores the certificate and can perform authentication. For this to work, the mobile device must have not only the certificate itself but also a means of document identification and signer authentication.

[0020] Specifically, document identification can occur simply by displaying the document on the mobile device's screen. The mobile device then links the displayed document to the signer's authorization and, after authentication, generates the signature file using the certificate stored on the mobile device and uploads it to the database server. If, however, the signer receives the document by mail or opens it on another device (for example, for ease of reading), a machine-readable graphic code associated with the document, such as a QR code, barcode, or similar, can be read by the mobile device's optical reader. This allows the mobile device to establish a link between the document to be signed and the certificate when it submits the signature file to the database server for upload.

[0021] To ensure the signatory is notified that a document awaits signature, the database server will send a notification to an address associated with the signatory's identifier. This notification may be via email, a push notification to a mobile application, an SMS, or similar messages personally accessible to the signatory. Advantageously, the notification includes a direct link to the document in the database, allowing the document to be opened using the mobile application or a web browser. The signing process then proceeds from there. If a mobile application is used, the QR code scan step can be omitted, as the application can directly access the stored data.

[0022] A certificate can be created from various perspectives. Furthermore, the issuance of certificates can be reserved for specific institutions. In particular, these can be specially designated external certificate authorities that issue certificates as part of their services and enjoy a corresponding reputation. However, certificates can also be generated internally by the database server or the mobile device application.

[0023] Certificates can also be generated based on contextual data. For example, a mobile application can issue a certificate if it is to be created at a specific location and requires a signature. If the signature and location are plausible as identification of a person, a certificate can be issued. A wide variety of contextual data can be used for this purpose, including images, text, numerical codes, GPS data, identifiers, MAC addresses, IP addresses, SIM card numbers, or IMEI numbers; this list is not exhaustive.

[0024] The invention described above is explained in more detail below using an exemplary embodiment.

[0025] It shows Figure 1 shows a handshake diagram of the communication process in the signing according to the invention, in which the document to be signed is displayed on a computer, and Figure 2 shows a simplified version of the in Figure 1 The process shown, in which the document is displayed directly on the sharing mobile device.

[0026] Figure 1 This diagram shows a handshake between four communication participants, where a document presented to a user is to be authenticated by a signer. This text can be of any origin. However, the user wants to be certain that the text is authentic and therefore needs to receive secure confirmation from the signer.

[0027] To do this, the user uploads the document to be confirmed from a user computer 1 to the database server 2 in step 5. Furthermore, in step 6, the user assigns a signatory identifier to the document, so that the database server 2 stores information about who should sign the document. The identifier is the signatory's email address, which the database server 2 can then use to address the signatory.

[0028] In step 7, database server 2 will first generate an electronic fingerprint of the document in the form of a hash value, which uniquely identifies the document. It will then read the identifier associated with the document. In step 8, based on the data received from the user's computer, database server 2 will create a notification, which it will send as an email to the signatory's email address used as the identifier. The notification contains a link that allows the receiving signatory to access the document on their signatory computer 3.However, since access should only be granted to the signatory and not to any third party, in step 9 the database server 2 will only grant access to the document if the signatory can authenticate themselves to the database server 2, for example by logging into the database server 2 with login data that matches the identifier stored with the document.

[0029] Then, in step 10, the document is displayed to the signer on their signing computer 3 in conjunction with a barcode. The signer now checks the document. If the signer decides to sign the document, they will pick up their mobile device 4 and scan the barcode. This is done using a dedicated authentication application. In step 11, scanning the barcode initiates an authentication request. After checking the text of the document on the mobile device 4, the signer is prompted to authenticate by reading biometric data, such as their biometric fingerprint, or measuring their face. In step 12, the mobile device 4 checks whether the identifier and biometric data match.If it can be determined on mobile device 4 that the signer actually grants the release himself, then in step 13 a signature file generated using a certificate of the signer stored in the memory of mobile device 4 is transferred to database server 2, which represents a link between the document and the certificate.

[0030] In step 14, database server 2 receives the signature file from mobile device 4, stores it along with the document, and generates unique hash values ​​for the signature file in addition to a hash value for the document. The document is now signed and remains in the database of database server 2. To complete the process, database server 2 sends confirmation of the successful signing to the user computer 1, the signing computer 3, and mobile device 4.

[0031] Will be, as in Figure 2As shown, if the document is displayed directly on the mobile device, the process may differ slightly. Here too, in step 5, the user uploads the document to be confirmed from user computer 1 to database server 2 and adds the signer's identifier in step 6. In step 7, database server 2 adds a hash value for the document.

[0032] In step 8, the database server now sends a notification as a push message directly to the authentication application on mobile device 4. If the signer opens this application on their mobile device 4, the mobile device will retrieve the document from database server 2 in step 9 and display it to the signer in step 16. Since this process takes place directly in the authentication application, there is no need to display an additional barcode, nor is there any subsequent step of scanning the barcode.

[0033] Otherwise, authentication now proceeds as before. The signer is again prompted to review the text, can then scan their biometric data, and thus complete the signature. Mobile device 4 forwards the authentication to database server 2 and, in step 13, sends the signature file to database server 2, where the signature file is stored along with the document and associated hash values. The final confirmation of successful signing is now sent only to mobile device 4 and user computer 1.

[0034] The above describes a method for storing electronically signed documents, wherein the signature file, as a link between the document and a signatory's certificate, is provided by the database server associated with a database with an electronic fingerprint, and preferably also with a shared electronic fingerprint. This enables secure authentication. LIST OF REFERENCE SYMBOLS

[0035] 1 User computer 2 Database server 3 Signer computer 4 Mobile device 5 Saving a document 6 Assigning an identifier 7 Assigning a hash value to the document 8 Creating and sending a notification 9 Retrieving the document in the database 10 Displaying the document with a barcode 11 Requesting authentication 12 Verifying identifier and biometric data 13 Authenticating and sending a signature file 14 Linking / creating hash values ​​to signature / document 15 Confirmation 16 Displaying the document on the mobile device

Claims

1. Method for storing electronically signed documents, in which an electronically signed document is assigned at least one signature file of a signatory of the signed document, stored in connection with the signed document in a database of a database server (2), as a link between the document itself and a certificate uniquely assigned to the signatory, characterized in that after a signature has taken place, a signature file is generated, using a certificate that is uniquely assigned to the at least one signatory, and is stored in connection with the document in the database, i.e. linked to it, so that a fully signed document consists of the document itself as well as a signature file for each signatory, which is a link between a certificate uniquely assigned to the relevant signatory and the document itself, wherein the database server (2) performs an integrity check on request and confirms the validity of the signature only if the integrity of the document and the at least one signature file is established.

2. Method according to claim 1, characterized in that, during a signature process, the at least one signature file is created by means of the certificate of the signatory, imported into the database of the database server (2) and linked to the document, and an electronic fingerprint is created for the signature file provided that the database server (2) receives authentication of the signatory assigned to the signature file and establishes a correspondence between the signature file and the unique identifier of the signatory assigned to the document.

3. Method according to claim 2, characterized in that an electronic fingerprint is created for a document immediately after storage in the database and at least one unique identifier of a signatory stored in the database is assigned to the document.

4. Method according to any one of claims 2 or 3, characterized in that a signature file is generated by means of the certificate stored on a mobile device (4) of a signatory and is imported into the database after identification of the document and authentication of the signatory has taken place on the mobile device (4).

5. Method according to claim 4, characterized in that, in order to identify the document, the database server (2) sends a notification containing the unique identifier of the signatory to the signatory, which notification refers to the document stored in the database, the document being displayed directly on a screen of the mobile device (4) for identification by the signatory, or the document being identified by reading in a graphic code associated with the otherwise displayed document via an optical reading device of the mobile device (4).

6. Method according to any one of claims 4 or 5, characterized in that the signatory is authenticated by code entry or biometric scanning by means of biometric capture devices of the mobile device, provided that the identifier associated with the document matches the signature file of the signatory.

7. Method according to any one of claims 3 to 6, characterized in that the unique identifier of the signatory is stored in the database server (2) prior to signing.

8. Method according to any one of claims 2 to 7, characterized in that the database server (2) sends the signatory a notification in the form of an e-mail or a push message about the linking of their unique identifier with a document to an address linked to the unique identifier.

9. Method according to any one of the preceding claims, characterized in that the electronic fingerprint is a checksum calculation, preferably the calculation of a hash value.

10. Method according to claim 9, characterized in that the integrity check consists in the repeated calculation of the checksums, preferably a hash value, of both the stored document and all the signatures linked thereto and the links.

11. Method according to any one of the preceding claims, characterized in that the certificate is created by the database server (2), a mobile device application or an external certificate authority.

12. Method according to claim 11, characterized in that the certificate is created using situational data, in particular images, texts, number codes, GPS data, identifiers, MAC addresses, IP addresses, SIM card numbers or IMEI numbers.