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 project I elected to use Ethereum as my blockchain platform, to gain hands-on experience with the technology and programming smart contracts in Solidity and javascript, and also because I reasoned that using a public blockchain would plainly reveal any security issues which might have been hidden or obscured in a private or permissioned blockchain. By using the public Ethereum network, everything that was written to the blockchain would be in plain sight — a challenging environment for secure information sharing!
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).
- I’d deliberately added a complication by wanting to share media content, as I knew the blockchain is not a good place to store data of any real size (it needs to be replicated out to every node, so is very expensive in terms of resources, and hence in the payment required from the user), so the model generally adopted is to store the media elsewhere and then store a reference to the media location on the blockchain so that it can be retrieved when needed. There are two ways to store the information, either on the cloud — eg. using AWS, or in a decentralised manner — which is the route I elected to take, as I was keen to preserve the decentralised (no need to ask, always available) purity of my system. In the decentralised storage world there are two leading projects: Storj and IPFS, and I chose the latter as it seemed more approachable. The outcome was that when Alice uploaded a piece of media to share I used IPFS (and a javascript interface) to provide file storage and saved the returned hash of the content (which is how IPFS indexes and locates files) to the blockchain message contract. When Bob accessed the message the IPFS hash was used to find and download the content, and display it in Bob’s browser. In a future version of the project, I would either encrypt the media before storing it in IPFS, or encrypt the hash before writing it to the blockchain — otherwise the content could be located and accessed by anyone without security.
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.
There were hefty requirements placed on the users of the system, in that both Alice and Bob had to have local Ethereum and IPFS nodes running, use Chrome with a Metamask plugin, and have copies of the project’s html and javascript libraries and code to get access to the contracts on the Etheruem blockchain. But I considered this a reasonable proof-of-concept, and this could be improved later — ideally, the works behind this project could be simplified to the point where a user could download a free (and open-source) app and have ready access to a secure public information sharing channel. I’m also assuming that issues around congestion in the Ethereum blockchain will be fixed, or that an alternative public blockchain will emerge as a suitable deployment alternative (and if it includes encryption and “read receipts” as capabilities, then so much the better).
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.
Update: My dissertation submission is now available at ResearchGate.
PS. A more recent post came to my attention, with some other nice ideas in this area: https://medium.com/@pfh/kimono-trustless-secret-sharing-using-time-locks-on-ethereum-8e7e696494d
