When transacting or exchanging business documents, trading partners may require certain elements of privacy.
- (1) Privacy of transaction data: the data should only be readable by the parties involved in the transaction.
- (2) Confidentiality of the volume of transactions and the identity of counterparties involved: the number of transactions carried out by a company and the counterparties with whom it deals are competitive information that must not be leaked.
- (3) Temporal visibility: employees who join a competitor and therefore still gain access to the system should not see old transactions.
- (4) Partial visibility: not all parties involved shall see the same information. For example, the buyer and seller can see all the fields of the transaction, but the shipping company should only have access to the delivery address, not the prices.
- (5) Add / delete counterparties: it may be necessary to be able to add or remove counterparties to a transaction along the way, and to grant them access to relevant documents.
Using a public blockchain to store and exchange transaction data creates major privacy hurdles: by default, all data entered in the ledger is in clear. Since each node has a complete copy of the ledger, confidentiality of data cannot be preserved.
Data protection by encryption
Data encryption protects the privacy of transaction data, but the multiplicity of counterparties in the network and the trustless nature of the environment requires a specific algorithm. The main steps of this algorithm are highlighted below:
- All network stakeholders issue an asymmetric key pair and exchange their public keys outside the network.
- Then, when exchanging a message:
- A random number is generated
- A symmetrical AES 256 key is generated from this number
- The sender signs the AES key with his private key (=> the “signature”)
- The message is encrypted using the AES key (=> the “encrypted message”)
- For each recipient, the AES key is encrypted with the recipient’s public key (=> the “encrypted key”)
- Thus, the following are recorded in the ledger: The signature / The encrypted message / The encrypted key
- When the recipient receives the message:
- The AES 256 key is decrypted using the recipient’s private key
- The AES 256 key is controlled by verifying the signature with the sender’s public key
- The content is decrypted using the AES 256 key
How well does this encryption algorithm ensure privacy constraints?
This algorithm provides security and non-repudiation, it also minimizes storage requirements in the ledger by writing only once the (encrypted) content. It respects privacy constraint (1).
In addition, the symmetrical encryption key can be shared later with a controller, for example, hence privacy constraint (5) is respected.
An employee who leaves the company is no longer expected to have access to the symmetrical keys and can no longer see the content of past transactions: privacy constraint (3) is respected.
Finally, the same transaction can use several symmetrical keys to encrypt different fields of the transaction and share the keys with stakeholders in such a way that only the information of interest to them is disclosed: privacy constraint (4) is respected.
The downside of this algorithm is that it requires an exchange of keys outside the network. And above all, it does not hide the parties involved in the transaction, and therefore does not respect privacy constraint (2).
Encryption, an impediment to business logic?
Looking past the need for privacy, encrypting data also creates serious limitations on the scope and use of Smart Contracts in the blockchain because, of course, they can only act on data that is recorded in the ledger and therefore visible to everyone.
This introduces a new class of challenges: how to encrypt data in such a way that it complies with privacy requirements, while letting “trusted” business logic manipulate this data? A number of researchers are already working on this topic, and it will be interesting to see how the topic evolves.