BE1024381B1 - Distributed blockchain-based method for maintaining the validity of a file - Google Patents

Abstract

The present invention is related to a computer-implemented method for maintaining the validity of a file by two users being a receiver and a validating authority, said method consisting of sequentially performing the next set of steps for each of said two users: (a) providing said file to the user; (b) looking up a publisher-related file signature in a blockchain, said publisher-related file signature associated with said file; (c) confirming the validity of said publisher-related file signature; (d) determining an identification string associated with said file based on said file and / or optionally based on said publisher-related file signature; (e) drafting a renewed file signature based on at least both said identification string associated with said file and a private key associated with the user; (f) registering said renewed file signature in said blockchain.

Description

Priority date:

International Classification: H04L 9/06, G06F 21/31, H04L 9/32 Application Number: BE2016 / 5966

Date of submission: 22/12/2016

Holder:

iText Group NV 9050, GENTBRUGGE Belgium

Inventor:

LOWAGIE Bruno 9050 GHENT BRUGES Belgium

Distributed blockchain-based method of maintaining file validity

The present invention is related to a computer-implemented method for maintaining the validity of a file by two users being a recipient and a validating instance, said method comprising sequentially performing the next set of steps for each of said two users: (a) providing said file to the user; (b) looking up a publisher-related file signature in a blockchain, said publisher-related file signature associated with said file; (c) confirming the validity of said publisher-related file signature; (d) determining an identification string associated with said file based on said file and / or optionally based on said publisher-related file signature; (e) preparing a renewed file signature based on at least one of said identification string associated with said file as a private key associated with the user; (f) registering said renewed file signature in said blockchain.

BELGIAN INVENTION PATENT

FPS Economy, K.M.O., Self-employed & Energy

Publication number: 1024381 Filing number: BE2016 / 5966

Intellectual Property Office

International classification: H04L 9/06 G06F 21/31 H04L 9/32 Date of issue: 05/02/2018

The Minister of Economy,

Having regard to the Paris Convention of 20 March 1883 for the Protection of Industrial Property;

Having regard to the Law of March 28, 1984 on inventive patents, Article 22, for patent applications filed before September 22, 2014;

Having regard to Title 1 Invention Patents of Book XI of the Economic Law Code, Article XI.24, for patent applications filed from September 22, 2014;

Having regard to the Royal Decree of 2 December 1986 on the filing, granting and maintenance of inventive patents, Article 28;

Having regard to the application for an invention patent received by the Intellectual Property Office on 22/12/2016.

Whereas for patent applications that fall within the scope of Title 1, Book XI, of the Code of Economic Law (hereinafter WER), in accordance with Article XI.19, § 4, second paragraph, of the WER, the granted patent will be limited. to the patent claims for which the novelty search report was prepared, when the patent application is the subject of a novelty search report alleging a lack of unity of invention as referred to in paragraph 1, and when the applicant does not limit his filing and does not file a divisional application in accordance with the search report.

Decision:

Article 1. - iText Group NV, Kerkstraat 108, 9050 GENTBRUGGE Belgium;

represented by

BRANTS Johan Philippe Emile, Pauline Van Pottelsberghelaan 24, 9051, GHENT;

a Belgian invention patent with a term of 20 years, subject to payment of the annual fees as referred to in Article XI.48, § 1 of the Economic Law Code, for: Distributed blockchain-based method of maintaining validity of a file.

INVENTOR (S):

LOWAGIE Bruno, Kerkstraat 108, 9050, GENTBRUGGE;

PRIORITY:

BREAKDOWN:

Split from basic application: Filing date of the basic application:

Article 2. - This patent is granted without prior investigation into the patentability of the invention, without warranty of the Merit of the invention, nor of the accuracy of its description and at the risk of the applicant (s).

Brussels, 05/02/2018,

With special authorization:

BE2016 / 5966

DISTRIBUTED BLOCKCHAIN-BASED METHOD FOR MAINTAINING THE VALIDITY OF A FILE

TECHNICAL DOMAIN

The invention relates to the technical domain of maintaining the validity of digitally signed data such as files.

STATE OF THE ART

All digital signatures associated with data such as files are subject to a finite shelf life. It is therefore necessary that the validity of the data be provided with new signatures in order not to lose its validity. A problem with the known methods of maintaining the validity of files is that they need a central authority for this conservation. A further problem is that conservation becomes problematic when the original file publisher is no longer available. This makes the user all too dependent on this publisher.

US 6,584,565 describes a concept which makes it possible to extend the time during which a digital signature can be verified until after the expiration of any or all certificates on which this signature depends. A save state approach is described, in which an archive facility is used to store public key infrastructure (PKI), e.g. cryptographic information, such as certificates and certificate revocation lists (CRLs), in addition to non-cryptographic information, such as trust policy statements, or the document itself. This information includes everything necessary to go through the signature verification process again at a later time. When a user wishes to recheck the signature on a document, possibly years later, a long-term signature verification (LTSV) server re-creates the exact state of the PKI when the document was originally submitted. The LTSV server restores the state, and the signature verification process performs exactly the same process as it would have performed at the time.

A problem with a method according to US 6,584,565 is that it does not provide mechanisms to avoid a central authority (in this case, at least one LTSV server). Also, there is no flexibility regarding the order of signing. Furthermore, a concept according to US 8,560,853 is not adapted to the specific nature of, for example, PDF documents.

BE2016 / 5966

US 2016/0212146 describes Systems and methods that use a blockchain to record a file date and prevent manipulation, even for documents that are secret and also those stored in uncontrolled environments. These Systems and Practices do not require the trust of a timestamping authority or a document filing service. A trusted timestamping authority can be used, but even if this timestamping authority loses credibility or if a third party refuses to recognize the validity of a timestamp, an electronic document date can still be set.

A lack of a method according to US 2016/0212146 is the lack of a mechanism for long-term verification of files.

US 2013/0226810 discloses a system for certifying the status of a will with a security adapted to be attached to a will. A server provides an account reference number and a version identification. The version identification corresponds to a version of a will on which the safety device is attached. The security device contains information which includes at least one of the account number and the version identification.

A problem with a system according to US 2013/0226810 is that it is based on the use of a central server. In addition, the concept is limited to a single type of data, especially a will.

The present invention aims to solve at least some of the above-mentioned Problems.

There is a need for an improved file validation method, with no need for a central authority for this conservation. In addition, it is important for the user not to depend on the publisher of a file or a central authority to maintain the validity of the file.

SUMMARY OF THE INVENTION

In a first aspect, the invention relates to a computer-implemented method for maintaining the validity of a file by two users being a recipient and a validator, said method comprising sequentially performing the next set of steps for each of said two users:

BE2016 / 5966 (a) providing said file to the user;

(b) looking up a publisher-related file signature in a blockchain, said publisher-related file signature associated with said file;

(c) confirming the validity of said publisher-related file signature;

(d) determining an identification string associated with said file based on said file and / or optionally based on said publisher-related file signature;

(e) preparing a renewed file signature based on at least both said identification string associated with said file and a private key associated with the user;

(f) registering said renewed file signature in said blockchain;

wherein said publisher-related file signature includes a publisher identity associated with a publisher; wherein said publisher is different from each of said two users; wherein confirming the validity in step (c) comprises determining the validity of said publisher identity; wherein said renewed file signature at least allows uniquely identifying said file relative to the blockchain; wherein said arrangement in step (e) comprises encrypting said identification string using said private key belonging to a key pair associated with said user to obtain a signed identification string, said key pair consisting of said private key and a public key ; wherein said renewed file signature includes said signed identification string; wherein said renewed file signature includes a user identity for retrieving said public key; and wherein said sustain is accomplished once step (f) is performed for each user.

Two main advantages of such a method are the decentralized nature of each file signature, and the fact that the validating body that maintains validity may differ from the file publisher.

BE2016 / 5966

Thanks to its decentralized character, the file signature can be considered as a decentralized signed file. This no longer makes the user dependent on a central authority to sign or renew the signature of the file. The present invention bases itself herein on a blockchain, a technology of proven utility that allows irreversible, irrefutable and distributed capture of the file and its signature, inherent in the operation of the blockchain that this distributed capture also includes a -adjustable and irrefutable timestamp. This is in contrast to a prior art method in which at least one of these aspects is either not treated or treated according to a centralized model.

Due to the fact that the publisher and the validating agency may be different, the invention solves the problem where a recipient of a file cannot renew the signature proving the validity of his / her file because the publisher of the file is not available to renew it. This is the case, for example, when a publisher no longer exists. In a prior art method, the signatures associated with the file can no longer be renewed, so that the file loses its validity. In a method according to the present invention, this is possible because a reliable validating body, such as, for example, a government, takes over the role of the publisher.

In a preferred embodiment, said sequential execution of said set of steps for a first of said two users constitutes a trigger for sequentially performing said set of steps for a second of said two users. This is in contrast to the case where the signatures are essentially independent, with the only link that the maintenance is realized once both users have completed step (f). In a preferred embodiment, however, a first of said two users goes through all steps (a) to (f), and registering in step (f) preferably generates a notification with the second of said two users. This notification can, for example, be passed on via contact details linked to the user identity, whether or not linked to a joint registration in a web-of-trust. After receiving said notification, the second of said two users can go through steps (a) to (f), after which the validity of the file is renewed.

BE2016 / 5966

In a preferred embodiment, said registration occurs in step (f) provided that said user identity associated with said recipient and said user identity associated with said validating entity belong to a plurality of user identities registered in a web-of-trust. This allows to ensure the authority of the recipient and in particular the validating body. In a further preferred embodiment said registration takes place in step (f) on the further condition that said user identity associated with said validating body satisfies an additional criterion for reliability. A suitable criterion for reliability typically imposes conditions on several factors simultaneously. In a preferred embodiment, a validating agency within said web-of-trust must have been involved in a number of previous file signatures greater than a predetermined first number, e.g. 10, associated with a number of recipient user identities greater than a predetermined second number, eg 5. As the said first and second numbers are chosen higher, the additional criterion for reliability becomes stricter.

A further advantage of the present invention is the decentralized approach to signing, with provisions for non-repudiation. Signing the file includes the application of Public Key Infrastructure (PKI). Because the user, ie both the recipient and the validating agency, encrypts the identification string with his / her own private key, a third party to whom the encrypted hash is available can use the public key that has been made freely available to verify that no one else then said user has encrypted the given hash. A signature with the private key can therefore be traced back to an action by the owner of that private key, which is important in realizing non-repudiation.

Another advantage of the invention is that there can never be any dispute among users about the contents of the file. After all, each file is identified by an identification string for which it is established that it is unique in relation to the blockchain. In a preferred embodiment, this is uniquely assured through the use of a hash function and / or the use of a document ID pair. The use of a document ID pair is preferably done in conjunction with an implementation where the file is a PDF document or a PDF-based document, but it may not be. In an alternative embodiment, the file is not a PDF document or a PDF-based document, and the file nevertheless includes the document ID pair, preferably in the metadata and / or file properties of the file. Thus, the invention solves the problem that a party, after joint signature, can claim that the file it received is a

BE2016 / 5966 had adapted content compared to the copy that the other parties received. In a preferred embodiment, explicit provisions ensure that the identification string is unique relative to the blockchain. For example, this could be sub-steps in which the document ID pair is iteratively modified until both the hash and document ID pair are unique to the blockchain, should it exceptionally prove that the hash is not unique to the blockchain.

In a preferred embodiment, said determining in step (b) comprises calculating a hash from said file using a cryptographic hash function, wherein said identification string is determined based on at least said hash. In a further preferred embodiment, the identification string comprises said hash. This has the advantage that the user can check for himself whether the unique identification string and the file actually belong together. After all, the hash is a fingerprint of the file. Each user can therefore apply the cryptographic hash function to the file and check whether the resulting hash matches the hash present in the unique identification string. In this way, the invention solves the problem in which a recipient of a file determines that the unique identification string is unique to the blockchain, but cannot verify whether the connection between this identification string and the file is correct. Note that it is not important whether the content of the file is confidential or publicly accessible, since no portions of the actual file are registered in the blockchain in the method.

A further advantage of the method of the present invention is that there is no need for a Timestamp Authority (TSA) to supervise the allocation of timestamps, which is typically the case with a prior art method. The use of such a TSA is therefore unnecessarily complex. Related to this there is also no need for a Certificate Authority (CA) that supervises authorship. The use of such a CA is also unnecessarily complex.

Another advantage of the present invention is that the blockchain realizes a user-friendly and transparent inventory of signed files in this way. First, a simple search for files signed by a particular user can instantly return a complete list of signatures to anyone who has access to the blockchain. Furthermore, in an embodiment in which the unencrypted (or, equivalent, unsigned) hash is included in the file signature, it is also very easy to perform a search on this hash to find out whether the file is registered, and whether none

BE2016 / 5966

Problems with this, such as in the case that there are multiple signatures in the blockchain that do not have a logical connection.

Another advantage of the present invention is that file signatures are available collectively, so that anyone accessing the blockchain can see details about the type of hash function used and / or PKI encryption and / or signing technique. If a particular technique becomes known that it is no longer considered reliable, large groups of users can be notified immediately, and by extension encouraged to renew the signature of their existing files using a replacement, more secure Technic. It is also easy to check whether this innovation is actually happening. Such a large-scale problem identification is inconceivable in a case where electronic signatures are sent with the actual file.

In a second aspect, the invention relates to a system for maintaining the validity of a file by a plurality of users, said system comprising a plurality of interconnected devices, each of the devices including a processor, tangible non-volatile memory, instructions on said memory for driving said processor, a client application, the client application being configured for each device to execute a method according to the present invention, wherein a user identity for retrieving a public key for ten at least one of the users is linked one-to-one to the client application on the device belonging to said user.

Such a system has the advantage that a more controllable environment can be created, which allows for quick action in various situations, such as the case of a promised HSM.

In a third aspect, the invention relates to a use of the method according to the present invention in a system according to the present invention.

In a fourth aspect, the invention relates to a computer program product for performing a computer-implemented method for maintaining file validity by a plurality of users according to the present invention, said computer program product having at least one readable medium which stores computer-readable program code portions, which program code portions comprise instructions for performing said method.

BE2016 / 5966

Further preferred embodiments of the present invention are described in the detailed description and the claims.

DETAILED DESCRIPTION

Several aspects are important in maintaining the validity of a file according to the present invention. Based on a successful previous registration and signing of the file in the blockchain, the following three causes, among others, may require the signing to be renewed.

(01) The hash function has expired since the previous signing. In a preferred embodiment, the identification string includes a hash that is calculated from said file using this hash function. This hash function expires as soon as it is compromised, for example by finding a method to match more than one file with the same hash (hash collision). In such a case, the hash function can no longer fulfill its original role because it allows someone to modify a file without changing the hash or identification string of the file. It can thus be made to appear as if a file modified at a later time already contained the changes made at an earlier time. Re-registering the same file in the blockchain using a better hash function is a solution to this problem.

(02) The registration of the user identity of one or more users in the web-of-trust has lapsed since the previous signature. This is also obviated in a variety of embodiments of the present invention. After all, the web-of-trust allows to verify that the user's identity was valid at the time of the previous signature. In a preferred embodiment, the web-of-trust is also recorded in the blockchain. And since the blockchain is not customizable, this older data can be continued to ensure that the user's identity can be re-registered and that all file signatures signed by the user's identity can be renewed.

(03) The way in which one or more users signed the file with their private key has become unreliable since the previous signing. On the one hand, this may be due to the algorithm used for this. On the other hand, this may be related to the key itself, for example because it is no longer judged to be sufficiently long due to the development of new methods and / or increasing computing power. In

BE2016 / 5966 a preferred embodiment in which the web-of-trust is recorded in a blockchain, it is possible to revert to the previous signature if the algorithm and the key-length are still reliable at the time of recording the previous signature. After all, the blockchain also ensures that this recording is not adjustable.

Any of the causes (01), (02) and (03) mentioned may be a reason to perform the method of the present invention in order to maintain the validity of the file. According to a preferred embodiment, a new signature must be registered for both the recipient and the validating agency in order to renew the file signature. This makes sense because it achieves increased security thanks to a proof of trust from more than one party. This is in line with the principle underlying the web-of-trust.

In an alternative embodiment, it is not necessary for both the recipient and the validating agency to register a new signature to maintain the validity of the file, and it is sufficient that at least one of the users register a new signature. In theory this always leads to a decrease in safety, but in particular for cause (01) the decrease in safety is limited. Also for cause (02) and (03) an embodiment in which only at least one of users registers is possible. In the case of cause (01), in an alternative embodiment it may suffice that one of the two users, for example the receiver (since this typically has the greatest interest in maintenance), derives a new hash from the file with a new hash function, and register it in the blockchain. This registration therefore counts as a renewed registration. After all, in the case of cause (01) it is possible for anyone to check afterwards whether a file complies with both the previously registered (which has become unsafe) and the later registered (more secure) hash. But even in this case, a security risk is not inconceivable. For example, after the expiration of the original hash function with the resulting first (unsafe) hash, a user could create a custom file that meets exactly the same (unsafe) first hash. For this custom file, the user could then calculate the new hash and register accordingly with a file signature in the blockchain. Both in an embodiment where both users sign as an embodiment where only at least one user signs, this may be important. After all, it is conceivable that the recipient makes the adjustment. And since the validating authority does not have to be the same as the publisher, it may not have the original file available, but on the contrary a

BE2016 / 5966 receives modified version from the recipient, which the recipient claims is the original file. The validating authority cannot unmask this modification based on the original hash and the newly modified hash. Therefore, in a preferred embodiment, the identification string comprises one or more complementary hashes calculated with one or more complementary hash functions that are different from and different from said hash function. This allows to further increase reliability and negate the impact of expiring a hash function. After all, it is very unlikely that several different hash functions will expire at the same time. For this reason, when using multiple hash functions, at least one hash function will usually not have expired, which then allows any changes to be noticed. Only if all the hash functions used have already expired when a renewal is required, it is hypothesized that there may still be an unauthorized modification of the original document. However, the latter requires that the unauthorized modification does not have an impact on any of the hashes, which is very unlikely.

The invention relates to a file, being a digital file relating to one or more interested parties, whereby it is important for at least one of these interested parties that the validity and / or correctness and / or value of said digital file, either directly or indirectly, long-term. The said digital file can be stored in any format, and may, but need not necessarily, be suitable for printing on paper. It can therefore be a format for word processing or text reproduction, but it can also be an image (either pixel-based or vector-based), a media file such as a sound fragment or a film fragment, or a specialized file format such as a computer aided design (CAD) file. An example of a possible file format is PDF, the Portable Document Format file format. Another example is a PDF-based document, a category that includes all PDF documents, as well as all other files that contain portions of code related to the PDF standard. What follows is a non-exhaustive list of examples. A first example of a PDF-based document is a PDF document. A second example is a PDF portfolio, a container format that is suitable for containing multiple PDF documents and related data. A third example is an XFA (XML Forms Architecture) file, a markup language where a dynamic form is formatted in extensible Markup Language (XML), but the XML code is compressed and stored in a PDF file. Such an XFA file can be processed by PDF processors that support the XFA specification. A fourth example is a successor

BE2016 / 5966 or variant of the current PDF file format, the purpose of which is similar to that of the current PDF file format.

In the context of this document, a user signs and registers a file signature associated with the file. The author of the document is the person or entity who wrote the document and / or to whom the document belongs. The publisher of the file is the person who has previously registered the document in the blockchain, whether or not in consultation with the recipient, and may or may not coincide with the author of the file. The recipient of the file is the person to whom the file and / or the content of the file pertains, or at least somehow has an interest in maintaining the validity of the file. The validating body is a party that supervises the maintenance of said file, and may be abusive to the publisher, although the validating body and publisher may also be the same party. Both the recipient and the validating agency are users in the context of this document. It is to be understood that this involves a variety of embodiments of the present invention, and that the publisher and users may be individuals, but each may include companies. It is also possible that at the time of signing by the publisher, the recipient is a different party than the recipient in maintaining the file.

In a preferred embodiment, the publisher-related file signature is the file signature actually made by the original publisher itself, i.e. the publisher who completed the first registration of the file in the blockchain. In an alternative version, the role of publisher is transferred from renewal to renewal. In the case of a second or later renewal, the publisher is then either the original publisher on the first registration or the validating body that acted on an earlier renewal. In this document, however, this role is always referred to by the term publisher, while the term validating body refers to the user acting on the current renewal.

In this document, the term hash refers to a second bit string obtained by allowing a cryptographic hash function to act on a file, being a first bit string. The concepts of hash function and hashing algorithm are equivalent. To make sense, this hash function needs to convert the long first bit string into a (much) shorter second bit string. Furthermore, the chance that the hash already appears as hash of another file must be very small, so that the hash can count as a workable form of unique fingerprint of the file. To this

BE2016 / 5966 fingerprint is commonly referred to as the message digest. Also, it must be impossible to reconstruct from the obtained hash portions of the original file, i.e. the hash function must be one-way. In a preferred embodiment, the cryptographic hash function is therefore a function that meets all of these criteria, such as an algorithm belonging to the Secure-Hash-Algorithms (SHA) family, more preferably SHA-256. It should be noted that the possibility of a non-unique hash cannot theoretically be ruled out; when two files correspond to the same hash after separate application of the same hash function, this is called a hash collision. In a preferred embodiment of the present invention, the invention includes features to take this possibility into account, for example, by using a complementary hash and / or using a document ID pair.

In this document, the terms public key and private key refer to aspects of Public Key Infrastructure (PKI). PKI is used to record the identity of a person or organization. PKI involves the use of a key pair comprising two keys:

- a private key that must be kept secret by the owner of the private key. Typically, this private key is stored on a Hardware Security Module (HSM) and / or smart card and / or USB token and / or similar device from which it cannot be traced;

- a public key that can be shared with the world, and includes information about the owner.

The private key can never be retrieved from the public key, but they are a pair in the sense that a message encrypted with one key can only be decrypted using the other key. In the context of this document, such a key pair is used to sign a hash. By signing the hash with the private key, it is possible for a recipient of the encrypted hash to retrieve the original hash, using the public key, which in a method according to the present invention can be retrieved based on the users, for example -identity. If this decryption is successful, then none other than the owner of the private key can have the hash encrypted. In this way, the recipient is sure of the origin of the encrypted hash.

In the context of this document, the terms document reference, document signature and file signature are interchangeable. The terms file and document are also interchangeable.

BE2016 / 5966

In this document, the term blockchain refers to a distributed database that maintains a continuously growing list of registrations in blocks, which are irrefutably recorded, maintained and cannot be modified. In the context of this document, registrations are file signatures; in the known case of bitcoin, the registrations concern, for example, transactions. The database is stored and maintained at a variety of nodes, each of which separately participates in the calculations required when growing the list of registrations. Inherent in the design of the blockchain is that none of the nodes make adjustments to the existing list of registrations, and that each of the registrations has a time or timestamp associated with the recording. Strictly speaking, these modifications are possible, but only on the condition that a majority of the computing power represented in the nodes conspires, which becomes more unlikely as the blockchain is larger and has more users. Due to its advantageous properties, a blockchain can serve as a distributed ledger or distributed ledger.

Throughout this document, the term web-of-trust refers to a decentralized cryptographic model and related distributed system for reliably relating a public key to a user, and by extension, considering a user identity to be reliable. In an embodiment of a web of trust according to the present invention, a given user identity is reliable if a sufficient number of user identities already belonging to the web of trust consider the given user identity to be reliable. The said number can be considered sufficiently large if it exceeds a predetermined number.

One, de and the in this document refer to both the singular and the plural unless the context clearly assumes otherwise. For example, a blockchain means one or more than one blockchain.

In a preferred embodiment, the file signature is constructed in exactly the same way as the renewed file signature. In an alternative version this is not the case; this is important mainly because security standards evolve, and thus the shape of the file signature can evolve. For example, it is conceivable that the renewed file signature will have a longer identification string and / or a longer hash than the publisher-related file signature, because the time between the original release of the file and the renewal has been opted for security.

BE2016 / 5966

In a preferred embodiment, explicit provisions ensure that the identification string is unique relative to the blockchain. In the case of a file, this should preferably already be insured by the publisher. However, in an alternative embodiment, such provisions are not taken, for instance because a sufficiently advanced hash function has been used, whereby the chance of hash collision can be neglected. Even in such an alternative embodiment, Problems with the uniqueness of the identification string can be easily avoided. One possibility is to use said document ID pair. Another possibility is to include in the identification string of the file, in addition to the result of the hash function, a further attribute of the registration as a form of supplementary hash. In a preferred embodiment, such a complementary hash includes a timestamp related to the current or previous registration, preferably the first registration of the file in the blockchain. In a further preferred embodiment, the complementary hash includes data related to any other feature of the current or previous record, such as a user identity. It should also be noted that even an embodiment is possible in which the identification string consists only of the hash of the file and in which no checks are made of the hash's uniqueness. After all, when using a sufficiently advanced hash function such as SHA-256, the chance of hash collision is negligibly small. If such a collision should occur exceptionally, this hash collision is easily detectable by looking up the blockchain.

In an alternative embodiment, there is provided both a (default) hash and a complementary hash, wherein the hash is linked to a (default) hash function, and the complementary hash is linked to a complementary hash function different from said (default) hash function . Both hash functions are executed on the file, thus leading to two different hashes, which are included in the identification string. As argued above, the advantage of such a method is that it guarantees security if either hash function is compromised.

In a method according to the present invention, the file signature includes a user identity for retrieving the public key associated with the user. In a preferred embodiment, the user identity includes the actual public key. In an alternative embodiment, the user identity only includes a key-related reference that allows a recipient to associate a user identity with the public key. For example, the user identity could include a user identification number, which

BE2016 / 5966 via a related aspect of the invention, for instance with the aid of a web-of-trust and / or a second blockchain or the same said blockchain, is linked to one or more public keys including said public key.

In a further preferred embodiment, said blockchain is publicly accessible. This has the additional advantage of increased transparency. It allows users to provide the list of user-signed files publicly within the secure context of the present invention. For recipients and consumers of files, it provides a useful tool to verify the integrity, authenticity and non-repudiation of a given file, without restrictions on access to the blockchain.

In a further preferred embodiment, said blockchain is the same for each of said plurality of users. This has the advantage that a single blockchain is the reference for all signatures, resulting in increased transparency for the users. In an alternative embodiment, the file signatures are spread across more than one blockchain. This is possible, for example, if the users are spread over different countries or continents, each of which attaches value and / or authority to a certain, possibly different blockchain. In such a case, the present invention can be applied undiminished.

In a further preferred embodiment, the file signature comprises said unencrypted hash as obtained in step (b), i.e. the unencrypted hash. This has the advantage that searches of a file can be carried out in a very simple manner, without having to know the user of the file and his public key.

In a further preferred embodiment, said registration takes place in step (d) provided that said user identity belongs to a plurality of user identities registered in a web-of-trust. This has the advantage that file signatures in the blockchain already meet a certain quality characteristic when recorded. This preferred embodiment preferably involves the use of a blockchain that is adapted for the signature of PDF files, rather than a blockchain that is already used for another purpose such as the bitcoin blockchain.

In a further preferred embodiment, said web-of-trust is at least partially registered in said blockchain. The advantage of such an embodiment is that

BE2016 / 5966 no separate model has to be used for the web-of-trust, which benefits simplicity. Moreover, the web-of-trust thus enjoys the known benefits of the blockchain, which allows irreversible, irrefutable and distributed capture of the user identity-related data, including timestamping.

In a further preferred embodiment, said file comprises, for example, a PDF document, a document ID pair comprising a first document ID and a second document ID, the identification string determined in step (b) comprising said document ID pair , said document ID pair being unique from the blockchain. This has the advantage that the document can be identified and retrieved using an identification contained in the file itself, rather than being external to it, such as in the case of a hash. This has the advantage that the user who only has a file is not required to have facilities to calculate a hash, and can also query the blockchain purely on the document ID pair. This document ID pair can be determined at the first registration of the file in the blockchain, which amounts to the first signing of the file in the blockchain.

In a further preferred embodiment, said private key is stored on a hardware security module (HSM) and / or smart card and / or USB token and / or similar device. This reduces the risk of theft of the private key.

In a further preferred embodiment, a replacement of said key pair belonging to said user by a new key pair belonging to the same said user comprises a registration on said web-of-trust. This has the advantage that said web-of-trust can keep the files of the same user together under the same user identity, with greater simplicity as a result. In a preferred embodiment it is thereby possible to redraw existing files with the new private key. In principle, this is not necessary because the outdated private key was valid at the time of signing. And since the blockchain invariably captures all data, the signing then remains a valid proof of signing. However, legal regulation may require certain files to be signed with a certain minimum encryption level. Legal provisions may also imply that there is always a signed version with a key that has not expired. This is an additional reason why it is useful to allow this re-signing or re-registering a file. In a preferred embodiment it is otherwise possible to have a better hash function with such a re-signing

BE2016 / 5966 as a better hash encryption algorithm. This occurs, for example, when a file signature is renewed as a result of an expired hash function, and in addition to an improved hash function, a better encryption algorithm is also applied immediately. This brings a clear advantage of the renewal: the more recent the registration (either an initial registration or a renewal), the more reliable the file signature will be.

In a further preferred embodiment, said blockchain overlaps at least partially with the technology of the bitcoin blockchain. This has the advantage that it is possible to build on an existing system. Due to the nature of the blockchain, in which data can be tampered with if a majority of the computing power represented in the nodes conspires, it may be beneficial to use such a large blockchain as the bitcoin blockchain. After all, in a large blockchain it is very unlikely that a majority of the computing power will be taken over by an attacker.

In a further preferred embodiment, said cryptographic hash function belongs to the Secure-Hash-Algorithms (SHA) family, more preferably SHA-255. The advantage of this algorithm is that it has been tested and that efficient algorithms are available to perform hashing.

In a further preferred embodiment, said file signature includes a complementary hash different from said hash as obtained in step (b) and different from said signed hash. In a possible embodiment, said supplemental hash can be utilized to prevent any hash collision problems by using not only the hash obtained in step (b) but the combination of this hash with the complementary hash as a unique identifier.

According to yet another preferred embodiment, said file signature includes one or more signature specific properties such as a status related to said file and / or said file signature. This has the advantage that the invention can be used even more flexibly for different forms of use.

In a further preferred embodiment of a system according to the present invention, at least one of said plurality of devices comprises a hardware security module and / or smart card and / or USB token and / or similar device. This has the advantage that the risk of theft of the private key is limited.

BE2016 / 5966

In a further preferred embodiment of a system according to the present invention, the notification of a user identity linked to a client application leads to the removal of said registered communication user identity from said plurality of user identities registered in said web-of-trust. This leads to a greater clarity of said web-of-trust.

In addition, the present invention is described by the following non-limiting examples, which are intended to illustrate the invention in a particular embodiment.

EXAMPLE 1: decentralized working method and decentralized system

This example assumes a system according to the present invention. This system includes several of said devices, here called SYSTEM entities, which are interconnected via a network such as the Internet. Each SYSTEM entity includes a CLIENT clause and an HSM. The CLIENT component corresponds to said client application and may, for example, be built into a document management system present on the SYSTEM entity and / or a web browser present on the SYSTEM entity. The user identity, here called IDENTITY specification, is used to identify the person or company who owns the CLIENT clause, the HSM and the SYSTEM entity. The said web-of-trust includes every IDENTITY specification. A new IDENTITY specification is only trusted if it logs into the web-of-trust and is approved by a sufficient number of other IDENTITY specifications contained in the web-of-trust, such as companies that know and trust each other. The web-of-trust is used, for example, if an HSM needs to be replaced or if the key pair on the HSM has expired, or because the encryption algorithm used in conjunction with the key pair needs to be updated.

Each CLIENT component maintains a copy of the BLOCKCHAIN database consisting of blocks, corresponding to said blockchain. Each block in the BLOCKCHAIN database includes a list of said document ID pairs, said signed hashes of the PDF files, and user information contained in the user identity. The BLOCKCHAIN database itself is public, and does not allow access to file contents. For the possible distribution of files, the decision lies entirely with the SYSTEM entity. The signed hash is hereby called SIGNATURE, and is registered in the BLOCKCHAIN database in combination with the documentID pair and the IDENTITY specification.

BE2016 / 5966

Here, the combination of SIGNATURE, document ID pair and IDENTITY specification corresponds to said file signature.

In this example embodiment, the combination of document ID pair, SIGNATURE and IDENTITY specification is a unique and irrevocable proof of the existence of said file at any given time. Registering this combination in the blockchain by signing therefore also leads to the recording of the content of the file, and the creation of a link between the user who signs and the file in question. This concerns both the publisher-related document signature and the renewed file signature.

Each signature checks whether all notifications in the blockchain are valid for the same file. This should be the case, since the CLIENT application would not allow adding a corrupt SIGNATURE. In a preferred embodiment, the corresponding system includes features that prohibit signing in the BLOCKCHAIN database with an IDENTITY specification known to be compromised, and already signed signatures with corrupt SIGNATURE are marked invalid. In a preferred embodiment, the existing invalid SIGNATURE is invoked by a new SIGNATURE, for which the private key is registered via the web-of-trust.

In a preferred embodiment, the method according to the current embodiment is used to renew a file that is a form of contract between two parties. In such a case, the file publisher is the first party, and registers the first renewed file signature in the BLOCKCHAIN. The second party registers a second renewed file signature in the BLOCKCHAIN for the same file, thereby confirming that the contract remains valid.

It is believed that the present invention is not limited to the embodiments described above and that some modifications or changes to the described examples can be added without revaluating the added claims. For example, the present invention has been described with reference to a separate blockchain intended for signed registration of PDF files, but it should be clear that the invention can be applied with a blockchain that also has a different use, such as for instance the bitcoin blockchain.

EXAMPLE 2: JSON Study Results Document

2016/5966

2016/5966

In a specific example of the present invention, the file is a JSON document (JavaScript Object Notation). The publisher is a first educational institution, such as a university, which awards study results to a recipient, being a student. The results are awarded in the context of a study program, for example a bachelor's program. The file contains portions of JSON code in which the various subjects taken are listed, with a number of credits (eg ECTS credits) and a score indicated. The file is registered in the blockchain with a publisher-related file signature and is preferably also signed by the recipient of the Study Results at that time. Years later, the student wants to present these study results to a second educational institution in another country to follow a master's program. This master's program can only be taken if proof of a previous bachelor's program can be presented. The file mentioned is part of this proof. However, the original publisher-related signature of the file must be renewed, for example for the reasons mentioned (01), (02) and / or (03). The student contacts the first educational institution but finds no audience. The student subsequently contacts a validating body such as the government of the country to which the first training institution mentioned belongs, via the web-of-trust in which he is also registered. This validating body co-signs for the re-signing of the file in the blockchain, thereby maintaining the validity of the file. Thanks to this new signature, the file is valid proof of a bachelor's degree. This evidence can then be presented (whether or not in combination with further evidence) to the said second training institution.

BE2016 / 5966

Claims (20)

CONCLUSIONS A computer-implemented method for maintaining the validity of a file by two users being a recipient and a validating authority, said method comprising sequentially performing the following set of steps for each of said two users: (a) providing said file to the user; (b) looking up a publisher-related file signature in a blockchain, said publisher-related file signature associated with said file; (c) confirming the validity of said publisher-related file signature; (d) determining an identification string associated with said file based on said file and / or optionally based on said publisher-related file signature; (e) preparing a renewed file signature based on at least both said identification string associated with said file and a private key associated with the user; (f) registering said renewed file signature in said blockchain; wherein said publisher-related file signature includes a publisher identity associated with a publisher; wherein said publisher is different from each of said two users; wherein confirming the validity in step (c) comprises determining the validity of said publisher identity; wherein said renewed file signature at least allows uniquely identifying said file relative to the blockchain; wherein said arrangement in step (e) comprises encrypting said identification string using said private key belonging to a key pair associated with said user to obtain a signed identification string, said key pair consisting of said private key and a public key ; wherein said renewed file signature includes said signed identification string; wherein said renewed file signature is a user22 BE2016 / 5966 includes identity for retrieving said public key; and wherein said sustain is accomplished once step (f) is performed for each user. The method of claim 1, characterized in that said sequentially executing said set of steps for a first of said two users is a trigger for sequentially executing said set of steps for a second of said two users. The method according to previous claims 2, characterized in that said registering in step (f) takes place on condition that said user identity belonging to said recipient and said user identity belonging to said validating entity belong to a plurality of user identities registered in a web-of-trust. The method according to previous claim 3, characterized in that said registering in step (f) takes place on the further condition that said user identity associated with said validating agency satisfies an additional criterion for reliability. The method according to any one of the preceding claims 1 to 4, characterized in that said file is a PDF-based document, preferably a PDF document (Portable Document Format). The method according to any of the preceding claims 1 to 5, characterized in that said determining in step (d) comprises calculating a hash from said file using a cryptographic hash function, said identification string is determined based on at least said hash. The method according to any of the preceding claims 1 to 5, characterized in that said blockchain is publicly accessible. The method according to any of the preceding claims 1 to 7, characterized in that said blockchain is the same for each of said plurality of users. The method according to any of the preceding claims 5 to 8, characterized in that said file signature comprises said non-encrypted hash as obtained in step (d). BE2016 / 5966 The method according to any of the preceding claims 1 to 9, characterized in that said file, preferably a PDF document, comprises a document ID pair comprising a first document ID and a second document ID wherein the identification string determined in step (d) comprises said document ID pair, said document ID pair being unique from the blockchain. The method according to any of the preceding claims 1 to 10, characterized in that said private key is stored on a hardware security module (HSM) and / or smart card and / or USB token. The method according to any of the preceding claims 3 to 11, characterized in that a replacement of said key pair belonging to said user by a new key pair belonging to the same said user comprises a registration on said web-of-trust. The method according to any of the preceding claims 1 to 12, characterized in that said blockchain overlaps at least partially with the technology of the bitcoin blockchain. The method according to any of the preceding claims 6 to 13, characterized in that said cryptographic hash function belongs to the family of Secure-Hash-Algorithms (SHA). The method according to any of the preceding claims 6 to 14, characterized in that said file signature comprises a complementary hash from said hash obtained in step (b) and from said signed hash. The method according to any of the preceding claims 1 to 15, characterized in that said file signature includes one or more signature specific properties such as a status related to said file and / or said file signature. A system for maintaining the validity of a file by a plurality of users, said system comprising a plurality of interconnected devices associated with said plurality of users, each of the devices comprising a processor, tangible non-volatile memory, instructions on said memory for controlling said processor, a client application, the client application being configured for each device to perform a method according to 2016/5966 BE2016 / 5966 above claims 1 to 16, wherein a user identity for retrieving the public key for at least one of the users is linked one-to-one to the client application on the device associated with said user. 5 The system according to claim 17, characterized in that at least one of said plurality of devices comprises a hardware security module and / or smart card and / or USB token. The system according to any of the preceding claims 17 and 18, characterized in that recording a file signature in one Blockchain occurs on condition that said user identity belongs to a plurality of user identities registered in a web oftrust; and that the notification of the user identity associated with the client application gives rise to the removal of said notification of the user identity from said plurality of 15 user identities registered in said web-of-trust. Use of the method according to claims 1 to 16 in the system according to claims 17 to 19. 21. Computer program product for performing a computer implemented method for maintaining the validity of A file by a plurality of users according to any of the preceding claims 1 to 16, which computer program product comprises at least one readable medium on which computer-readable program code portions are stored, which program code portions comprise instructions for executing said method. 2016/5966 BE2016 / 5966 DISTRIBUTED BLOCKCHAIN-BASED METHOD FOR MAINTAINING THE VALIDITY OF A FILE