Signature Anchoring

Introduction

Data anchoring is a very efficient way to prove the existence of data at a given point in time, and allows to address an important set of use cases. However, data anchoring is also often claimed as being able to address the problem of authenticating or certifying data, which ultimately consist of being able to reply to the questions « who is the creator of this data? » or « who approved this data? »

This claim is wrong at a practical level. Let’s see why. In order to authenticate or certify some data using only data anchoring, the creator or certifier of the data would need to create the anchoring transaction by himself, using his own Bitcoin address and paying the fees with his own bitcoins, which none of the above SaaS platform allow.

Because transaction fees are expensive (a few dollars for Bitcoin transactions as of writing) all platforms factorize as much anchors as possible into one transaction obviously signed by the platform and paid using the platform’s bitcoins.

So, YES, you can prove that the data existed at a given point in time with data anchoring, but NO, you cannot know who actually anchored the data (the owner of the transaction will always be Woleet, Tierion or Stampery).

What is signature anchoring?

To address this limitation, and allow a new set of use cases, Woleet propose an evolution of data anchoring: Signature anchoring on Bitcoin. The functionality is already available on the Woleet platform and the specification is open (described here and in the Woleet API documentation). Anybody is free to implement a similar functionality in a different way, but of course everyone would benefit from a standardization and interoperability of proofs of signature (which is the case for Chainpoint based proofs of existence).

The process of signature anchoring is actually similar to data anchoring, except it creates a timestamped proof of signature of the data. With such a proof, not only you can prove that some data existed at a given point in time, but additionally that it was signed by an actor (eg. the creator of the data of any other actor wanting to « put its stamp » on the data).

The same data can be signed by any number of actors, at any point in time. Each signature generate a new proof and never modify the source data. This allow for a set of new use cases:

Remote signing of documents
one can send a file to a set of signees and ask them for a proof of signature: the file don’t need to follow a workflow and is never tampered

Signature timestamping with no intermediate
legacy signature solutions are either not timestamped, or use a centralized authority to prove signature timestamp, while time stamping is inherent to signature anchoring

Data provenance verification
 — IoT sensors can emit data along with a signature proofs to prove data origin and creation time
— schools can certify the diploma they deliver
— e-document used as proof of residence (like utility bills) can be signed by their emitter to eradicate forgery

Data certification verification
within a data processing workflow, a certification authority can sign some data to prove it certified it at a given date

How does signature anchoring manage signee identity?

Signature anchoring uses Bitcoin’s legacy signature scheme. Thus, a signee is identified by his Bitcoin address (a cryptic number like 10cbJgAXivkAMXwfckMKSrTSrHWk3UCQWh). While sufficient for most use cases, it is not human friendly, and there is a need to know for sure who owns a given Bitcoin address.

Decentralized identity management on the blockchain is not mature: some open solutions start to emerge (like blockstack or namecoin) but there is not yet any consensus, and none of them is widely used. Moreover, none of these solutions integrate a real identity verification process, because it requires a costly manual or semi automated verification of legacy documents and additional human interactions.

Signature anchoring may benefits from using decentralized identity management systems in the future. Meanwhile, Woleet has chosen to leverage a currently available, well proven and widely used identity verification source: the Certification Authorities. Certification Authorities are the trusted third parties issuing the TLS certificates used to secure the web. Thanks to these certificates, you can securely surf the web and be sure you are talking with Google, with your bank or with your energy utility company.

Wherever the identity of a signee need to be verified, an identity verification URL can be added to the signature proof. This URL, hosted by the signee and protected by his TLS certificate (bought by the signee from a Certificate Authority that will verify his identity) allows the verifier to check that the owner of the certificate also own the signee Bitcoin address, by asking him to sign some random data using the same Bitcoin address. Of course, this process requires the signee to host a web service, but Woleet will soon provide some ready to deploy open source code implementing such a service (as part of Woleet’s signature anchoring kit for backends).

How does signature anchoring work?

Signature anchoring is similar to data anchoring, except that the anchored data is not the original data itself (ie. the one that is signed) but instead the signature of the original data (produced by the signee).

A signature anchoring receipt is a Chainpoint compatible receipt with an additional signature property containing 3 mandatory sub-properties, and 1 optional:

• signedHash: the SHA256 hash (ie. the fingerprint) of the original data (this hash is what is actually signed)
• pubKey: the Bitcoin address of the signee
• signature: the signature of the content of « signedHash » using the « pubKey » Bitcoin address of the signee
• identityURL: optional web hook to be called whenever the signee Bitcoin address has to be verified

Note also that the target_hash property of the Chainpoint receipt is the SHA256 hash of the signature instead of the SHA256 hash of the data. Consequently, verifying a signature anchoring receipt using the regular Chainpoint verification process proves that the signature (and by transitivity the data) existed at some point in time: a signature receipt is thus equivalent to a regular anchoring receipt.

The verification process is completed by a signature verification step: this step checks that the signature provided is a valid signature of the hash of the original data produced using the signee’s Bitcoin address.

Optionally, if the identityURL property is provided, the verification process is completed by an identity verification process (described in the previous part).

Concretely, how can I sign my data and create proof of signature?

For end-users, signing and creating signature anchors is a simple drag&drop operation using Woleet’s web app. The app currently requires the use of a Ledger Nano S or Ledger Blue Bitcoin hardware wallet. These hardware wallets are the most secured on the market: your private key cannot leak outside the hardware, even if you connect it on a compromised computer. If you lose your device or someone stole it, you will be able to regenerate your private key. Note that Google Chrome is currently required for communicating with the Ledger device (other browsers are about to integrate the required U2F API).

For backends wanting to automatically sign high volume of data with no human intervention, the Woleet API is available. Any Bitcoin compatible signature software can be used to sign data (eg. a Bitcoin full node, a Ledger HSM module, or Woleet’s upcoming signature anchoring kit for backends).