Using Blockchain for Secure Information Sharing
I recently completed a Master’s degree dissertation where I considered the suitability of using a blockchain implementation as a channel for securely sharing information. As the project explored some interesting technologies, I wanted to summarise it while it was fresh in my mind, and share the story with a wider audience.
The project was carried out at Cardiff University, with Professor Alun Preece from the Crime and Security Research Institute. The aim was to see if blockchain technology provided a means to securely share information among members of multi-agency groups. These groups could typified by a lack of a central control party, and perhaps no trust relationship between them, maybe arising from a lack of personal relationship, or knowledge of each other. My background reading tended to lean towards the needs of cross-functional teams that form after disasters or emergencies, where teams emerge and change quickly, and communications resources can be fragile. To be honest, I feel quite humble thinking of these incredible people — a far cry from me pondering tech at my laptop.
Anyway, in this post I’ll concentrate on the technology I used to achieve my project goals of having a secure communication system — which I thought of in the popular information security triad of Confidentiality, Integrity and Availability. I also wanted to consider non-repudiation, both in terms of proving that one party had shared information and that the information had been accessed (and likely read). I decided that a reasonable system should let users share a piece of media content (e.g. a photo or a video) and a short text caption, perhaps to provide context.
For the implementation, I wrote an Authoring Contract which could be called by Alice (my information sharer) to create a message to share with Bob (the recipient). The Authoring Contract used a factory model, so that it spawned a new Message Contract for each information sharing occurrence (i.e. it was like a factory for making new messages). When Alice created a message, she would give the new Message Contract address to Bob and he would be able to access the content at that address through a web interface. I encoded Bob’s Ethereum wallet address into the new Message Contract, and put a check into the Solidity code of the Message contract to only reveal the content when the requester had an address which matched Bob’s.
Sharing text content on the blockchain in this way proved to be straightforward — the open, public nature of the Ethereum blockchain provided permanent access to the shared information, without the need for an administrator to create an account for Alice or Bob, and the permanent transaction history could prove that Alice had shared some information with Bob. There was no server to setup or maintain, and no ongoing subscription payments required to keep the information available, all that came for free by using the Ethereum network (Ok, not exactly free — there was a small transaction charge to be paid to write the original information to the blockchain, a change in use model from how we are used to interacting with the internet, but no ongoing charges or commitments).
The intial deployment highlighted some issues which had to be addressed…
- Writing to the blockchain is a transaction, which requires payment and leaves a record — but reading from the blockchain doesn’t need a transaction, its free, but no record is made — in other words, there was no non-repudiation on the read side, so we couldn’t prove that Bob had accessed the information. The solution (or workaround, I suppose) was to force Bob to make a transaction in order for him to read the information — this meant that Bob had to make a small payment to read the message (a bit clunky) but then we could write a transaction to prove that Bob had seen the information (and we could also detect and write that an unauthorised party had tried to access the message).
This kind of worked, but…
- Everything on the blockchain was public, so Bob (or anyone) could just get the contract address and read the information from the blockchain directly, or by using the etherscan website. The solution here was to use encryption, which would mean that anyone reading the blockchain would only get to see the encrypted information. To get the plain text, Bob would have to use our web app, which would a) write a “read receipt” to the blockchain and b) decrypt the information and display it. To do the encryption and decryption I used the WebCrypto libraries, which are part of Chrome — this enabled me to let Alice enter plain text and to encrypt this in the browser before writing the encrypted text to the blockchain. When Bob accessed the message through the web interace, the encrypted text was retrieved from the blockchain and decrypted in Bob’s browser, then shown as plain text. The downside was that Alice and Bob had to have agreed or shared a password (but as Alice would already have needed to know Bob’s address, there was already some “set up” responsibility on them).
At the completion of the prototyping phase, I considered that I had created a solution that provided Confidentiality (through encryption), Integrity and Availability (both “for free” through public blockchain) and I’d created a “read receipt” scheme to provide Non-repudiation — and so proved that the public blockchain (and application code) could be used as a channel for secure information sharing.
There was a further issue with Confidentiality which arose as a result of using the public blockchain, in that all the transactions were visible — in other words, anyone could see that Alice had interacted with Bob (assuming they knew who Alice and Bob were), and more pertinently, Bob could see that Alice had also interacted with Carol, and Dave and Eric and so on. Maps of transactions and information flows could be developed, and the only way around this would be for each party to use a new identity for each communication. This would likely be cumbersome and impractical to be done manually, so any future system should try to address this automatically.
For me, the real takeaway from the project was that the public blockchain has a great utility as an open, permission-less, always-on resource, and that (in theory, anyway) there can be great advantage in using it to store small pieces of information permanently — proof of knowing something at a particular date and time perhaps. I think blockchain technology is well-suited to multi-agency or inter-company circumstances where there is no clear controlling party, and disaster relief is an area where we may well be able to apply the technology and see benefits.
This has been a fast tour through a three month project, but hopefully gives an insight into using a public blockchain and combining this with other infrastructure components to create a practical solution.
I’m very happy to share further experience as required, or provide advice on similar projects — please feel free to contact me.