Using the blockchain as a digital signature scheme
Since late ’70s digital signatures have been successfully used to provide authentication, integrity and non-repudiation of a message and its source.
Algorithms such as DSA, PKCS #1 (RSA), ECDSA and others were or are used in digital signature solutions like Pretty Good Privacy (PGP) and Adobe Sign, among others.
Bitcoin’s blockchain background
Bitcoin uses digital signatures (ECDSA) to prove ownership of funds, so sending bitcoins requires the owner of them to digitally sign authorizing the transfer. This transaction is sent to Bitcoin’s public network and later recorded in Bitcoin’s public database (blockchain), so anyone can verify it by checking its digital signature.
Beyond that, Bitcoin has a scripting opcode called OP_RETURN that allows to embed up to 80 bytes of data when creating a transaction. It’s not much, but enough for a short phrase or metadata.
In summary, by spending a very small amount of bitcoins (transaction fee cost), we can record short authenticated pieces of immutable, irreversible and undeletable data in a public blockchain.
Employing the blockchain to sign documents
Let’s start simple to improve the idea step-by-step.
Starting point:
If a Bitcoin address is ours, and using funds from it we record data in the blockchain, then that data is digitally signed by us.
Hash functions:
Since we only have 80 bytes, that would only work for signing very tiny pieces of data. To resolve this, we can select a document, use a cryptographic hash function with it, and record the result in the Bitcoin transaction.
Because of how these one-way functions work, we would be signing the whole document, no matter the length or size of it, and without exposing its contents.
As an example for people not used to these functions, Bitcoin’s white paper (a nine pages PDF file sizing 184 kB) SHA-256 digest is “b1674191a88ec5cdd733e4240a81803105dc412d6c6708d53ab94fc248f4f553”.
So we can combine cryptographic digests with some other metadata to record digitally signed information using our own format.
Public-key cryptography:
When using digital signature we are using public-key cryptography. Under the hood, Bitcoin is using the same, but to verify a signature in traditional schemes we would be checking against a public key, and in my excessively basic example we were verifying against a Bitcoin address (which usually happens to be a ECDSA public key after some hashes, encoding and error checking).
Since most Bitcoin addresses (P2PKH) are created using their own public key, we could be showing that key instead of the address to verify our signed data. Or we could be using different P2SH addresses to record data in the blockchain, being all of them verifiable against the same public key (or against the same extended public key on hierarchical deterministic wallets).
Blockchain based digital signature
Combining everything we mentioned we achieve a digital signature scheme with unique characteristics. I will try to detail a few of those, and depending on the context, some could be considered advantages or disadvantages.
“Multisig” digital signatures:
Let’s first explain what is a “multisig” Bitcoin address. They are addresses that have multiple associated private keys, and a quorum of them is needed to spend its funds. So we can have an address with some bitcoins in it and make them spendable only if two-of-two, three-of-four, two-of-five or any other valid combination of private keys are available for signing (we can relate it to secret sharing as described by Adi Shamir).
Bringing this to digital signatures, we could record a cryptographic digest of a document in the blockchain using an address with any of this m-of-n combinations. Then, we would be signing the document with a preset combination of signatures.
By using traditional digital signature schemes we can have a contract signed by many people, but we can’t preset the required signatures according to the contract content, neither we can enforce that m-of-n predefined signatures are needed for the contract to be signed.
This method could make audits far simpler and was already used two months ago when we helped CESYT in being the first academic institution to record proof of all their official career diplomas on Bitcoin’s blockchain.
Smart signing:
Making m-of-n predefined signatures mandatory is not the only requirement we can set. Using a Bitcoin opcode like CHECKLOCKTIMEVERIFY (CLTV) we can define time conditions for a contract to be digitally signed.
Future Bitcoin features, as well as solutions like Ethereum, Counterparty or RSK, will further improve this functionality.
Timestamping:
Timestamps based in blockchain technology work quite differently than the ones generally used in digital signature. Bitcoin transactions are included in blocks being generated in 10-minute periods (average block time). When a transaction, or a signed document in our case, is included in a block and recorded in the blockchain, we get block’s timestamp for all its transactions.
Meanwhile, traditional timestamp solutions (RFC 3161/ANSI X9.95) need trusted third parties called Time Stamping Authorities (TSAs), and their long-term use (RFC 4998) involves an eternal maintenance to preserve the validity of the certified timestamp (linked timestamping).
The blockchain alternative has none of this problems, but its accuracy is in the range of several minutes (it may improve in future Bitcoin protocol revisions, or with new layers on top of it), not seconds like most TSAs. For signing contracts a date is more than enough, but a few use cases may need a more accurate time representation where adding a TSA hash to the blockchain record could be desired (best of both worlds).
Nevertheless, the advantages of blockchain timestamping are substantial, and particularly decisive in legal matters (no trusted third party) and long-term record archiving (no maintenance costs/risks).
Privacy:
The scheme we described works as a detached digital signature, where the signature is recorded in the public blockchain and kept separate from its signed data. It has the convenience of not needing to safeguard the signature itself somewhere else, while still being able to verify it with the appropriate document and public key.
This also means that anyone with our public key can notice when we are signing something or, when using “multisig”, with whom. Some use cases like certifications or notary services may need this property, but even if the data publicly recorded in the blockchain is a cryptographic digest that has no use without the original document, it’s still something to take into consideration.
Anyhow, the above-described behaviour could be made optional using Schnorr signatures, which may be supported by Bitcoin in the near future, and which are also planned in RSK’s white paper as one of their supported signature schemes.
Distributed consensus:
Digital signatures authenticate the source of a message and guarantee its integrity, but what we expect from these roles may be compromised if we require trusting the repository where those signatures are located.
For example, a software package and its signature could be replaced with older versions having an important vulnerability, which can be exploited to gain unauthorized access. In this case, the old but valid signature will assure source and integrity, even when deceived by an intruder.
Blockchain’s distributed consensus solves this with a public repository where we can all agree on latest signatures (a shared single source of truth). In fact, and more important, we can be sure that we are all seeing the same signatures, and no one can change them.
PKI:
The immutable, irreversible, undeletable and distributed consensus nature of the blockchain has appropriate attributes for the management and storage of public keys.
Key revocation could be publicly announced and timestamped in the same blockchain where documents using that key are signed and timestamped as well, making the whole process simple and straightforward.
Conclusion
We believe there are use cases where using the blockchain as a digital signature scheme provides useful features over traditional solutions.
As a result, we will be soon providing a platform and API where anyone can sign documents, records or contracts as described here, and we plan to use this as part of more specialized transparency, authentication and data integrity services. Stay tuned. :)
