Advantages of using Blockchain for Signing PDF documents

Suppose that we don't store the signature of a document in the document itself, but instead store it in the blockchain. In a blockchain system that relies on PKI, users already have a private key, which already lowers the threshold for adoption. Users of the system could be human beings, companies, or systems used within companies (such as a CRM, an ERP, a DMS,...). In the context of blockchain, the keypair is usually generated in a Web of Trust (WoT), but that's not a must. In some use cases (e.g. in the context of a permissionless blockchain), we might prefer to work with a keypair generated by a CA. As for the private key, some use cases might require that it's stored on a hardware device, such as an HSM, a smart card, or a USB token.

Signing a document would involve creating a hash of the document, signing that hash with a private key, and store that signed hash in the blockchain along with the corresponding public certificate. In this case, we use blockchain as a database for storing signatures with the unique ID pair of a document as the primary key for each record. Optionally, we can add metadata to the signature records, such as the status of the document (draft, final, unpaid, paid,...) and one or more locations (e.g. the URLs of different mirrors from which the document can be downloaded).

Verifying a signature can be done by retrieving all the signature records from the blockchain, based on the ID pair of the document you have at hand. You get a historical overview when each signature was applied. You can verify all of those signatures, or only a selection, for instance only the most recent signatures of every signer, or, if some signatures are expired, verify those records that confirm that the integrity of the document is still preserved.

How Blockchain can make you love the things you hate about PAdES

Storing the signature in the blockchain instead of the document itself has many advantages:

• We still meet the requirement of integrity, since we create the signature in exactly the same way. We only store the signature in a different place;

• We can still work with a CA to meet the requirements of authenticity and non-repudiation, but we don't have to. We can also rely on a Web-of-Trust stored in the blockchain;

• We don't need to work with a TSA anymore; timestamping is inherent to blockchain; once a record is added to a block, its contents are immutable and can't be changed;

• Since the signatures are stored outside of the document, signatures can be applied in parallel without a predefined order. Every signer can add a signature to the blockchain at any moment in time, and

• Everyone can check who signed a document, when, and in which order; this can be done without having to rely on a central service (e.g. Docusign);

• Keeping the signature of a document alive doesn't require any other approach; any eligible signer with access to the document can create a new signature in the blockchain using the latest hashing and encryption algorithms.

When discussing different use cases, you'll notice that we'll often talk about "registering a document" instead of "signing a document." In some sectors, people won't accept the fact that we store a signed hash in the blockchain as a valid signature, e.g. because the government doesn't accept such a signature as legally binding. Even in those cases, it makes sense to store hashes of documents along with some metadata in the blockchain.

• You can retrieve the records of a document based on its ID pair to inspect the metadata added by the person who signed the document. For instance: a document that is registered as an invoice with status "unpaid" by the CRM system of a vendor, can be registered as an invoice with status "accepted" by the ERP system of a buyer, and eventually be registered as an invoice with status "paid" by the buyer's bank.

• You could also do a search on the first part of the ID pair to find records of documents that are related. A document that starts its lifecycle as a quote request, could change into a quote, then be accepted as a purchase order, then fork into an invoice and a delivery note.

• If you find a document in the wild, e.g. a draft of a technical specification, and you want to know if that document is the latest version, you could search for a record that registers a more recent version of that draft, and use the location information stored in that record to retrieve that updated version. Obviously, there are also some disadvantages.

When not to use this approach?

Some governments might not accept signatures stored in the blockchain as legally binding. It might take time before this signature functionality is widely accepted in some sectors. We'll also have to make a distinction between registering a document (not legally binding) and signing a document (legally binding). In Belgium, this is typically solved by providing each citizen with two public/private key pairs: one for authentication and one for non-repudiation. Documents that are "digitally signed" (mind the use of quotes) with the private key for authentication aren't legally binding. They are "signed" in technical terms, but not in legal terms. Only documents that are signed with the private key for non-repudiation are legally binding.

The other big disadvantage is that you'll need a blockchain client to register sign a document. Today, the majority of CRM's, ERP's, DMS's don't provide PAdES functionality out-of-the-box. If we want our approach to be successful, every system that involves documents should also be a blockchain client.

Finally, this approach has all the same disadvantages as any other system based on DLT. A record with information about a single document can be kept really small, but we might be talking about quadrillions of documents that will eventually be stored per blockchain, especially if we want to keep track of the history of a document, and extend the life of a signed document. Fortunately, these problems can and will be addressed as blockchain adoption grows.