As cryptographers who develop data security tools that heavily involve cryptography (surprise surprise), we get asked a lot of questions about “crypto”. Unfortunately, not “cryptozoology”* crypto, but neither it is cryptography. Very often it is about blockchain.
More and more tools claim to have “unprecedented levels of security” or “GDPR compliance & security by design” when using security designs based on blockchain and distributed consensus systems. But blockchain solutions have pre-defined threat model. While they protect well against some of the threats, they are counter-productive in other cases.
Since It’s not optimally efficient to repeat our arguments against “blockchain as a silver bullet for GDPR” (there isn’t one, sorry) over and over again, we wrote them down. Enjoy!
What is blockchain? Let’s start with a basic definition:
A blockchain,originally block chain, is a growing list of records, called blocks, which are linked using cryptography. Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data (generally represented as a merkle tree root hash). — “Blockchain”, Wikipedia.
Technically speaking, blockchain is a sequential, immutable data structure with integrity/authenticity control, achieved through signature chaining. When blockchain is used in a distributed fashion, implemented over a peer to peer network, the trust is reinforced through the consensus algorithm between the nodes, ensuring that the changes are generally accepted throughout the system and injecting falsified transactions is hard.
We won’t bother discussing all the various types of blockchains and crypto-currencies here. They all share the core security features:
Authentication and integrity security of the stored data.
No single centralized trusted authority (the whole system is assumed to be resistant to server dishonesty and centralised attacks on a data store).
Read engineering advice how to handle GDPR requirements without re-writing the system:
GDPR for Engineers: Implementing Rights and Security Demands
A methodical developer’s perspective on mapping privacy regulations to changes in the database structure, updates in DevOps practices, backups, and restricted processing.
Which is a perfect set of security guarantees for an accounting ledger book.
As with any security systems, blockchain-based security narrows down to having the following issues:
Implementation problems (choice of algorithms, data structures, assumptions).
Protecting the client’s private key.
Making sure that the distributed protocol will not be abused for shifting consensus or limiting the availability.
Problems of the first type hit all “home-brewed crypto” developers sooner or later. Because you don’t roll your own crypto**, period.
The problems of the second type with blockchain are also well known and studied, and the consumer-grade HSMs have been suggested for solving them, but only to some extent (with a new generation of fault injections still emerging).
The problems of the third kind are more subtle (i.e. the possibility of consensus bending, distributed architecture attacks, the known issues with Bitcoin). Sometimes they require one to stop obsessing over the implementation details and think the whole system through:
If the client code is shipped by some central authority, it is only as good (or as bad) as the classic design — you still have to trust the server and assume it is honest and is shipping the right code to you.
In a private blockchain over a limited amount of nodes, there is a good the question to ask yourself: is the number of uncompromised nodes sufficient for avoiding the “51% attack” at any given moment? Is the architecture resistant to the Sybil attack?
If you’re building a blockchain-based product that needs encryption and GDPR compliance, we can help!
Using blockchain in security tools for compliance with data privacy regulations
Based on the purely theoretical speculations (as we are yet to see an actual blockchain-based security tool implemented in a real-world production setting), what are the things to do and to avoid with blockchain, privacy regulation-wise? Let us provide a list of do’s and don’ts from the POV of cryptographers when it comes to “blockchain meets GDPR”.
Use blockchain to store the data that doesn’t need to be changed (non-volatile data storage): ledgers, logs, transaction-based registers.
For example, you can use blockchain to secure a number of demands towards digital rights and data privacy as demanded in GDPR or perform access logging in HIPAA/PCI DSS. It can also be handy for distributed transactions of any kind where data sensitivity is a secondary concern, while integrity/authenticity without centralized trust is the primary concern.
Distributed PKI: Securely managing a distributed PKI is often a challenge in itself. The very nature of blockchain makes implementing a truly secure PKI hard. We’ve once toyed with the idea of having blockchain-based distributed PKI for Hermes (in its architecture, it’s called Credential store), but the performance and proof assumptions proved this idea be next to unusable.
The problems of blockchain vs PKI are also addressed in the slides accompanying our engineer Anastasiia Vixentael’s conference talk “Blockchain solutions: the balance of safety and efficiency or just a trend?”
Syncing data between devices. Having peer-to-peer content propagation network with some kind of consensus on addresses is not a very new idea (BitTorrent, anyone?). But having strong security on top of it makes the sync trusted and reliable to some extent. However, a secure channel for key distribution would be necessary if we want to encrypt the files. We’re not sure if dealing with two blockchains is going to help here: having immutable keystore and immutable storage makes the actual sensitive data doomed to be leaked, sooner or later. Although, the ongoing research this field looks look quite promising.
So, let’s imagine that the syncing problem is solved for a certain narrow use-case… what would we want to use that sync for?
For instance, to synch notes and send messages. Indeed, both of these domains can boast significant recent advancements. However, we are yet to see some truly great and usable solutions with a claim to better security that’s based on something more viable than a battle cry: “but it is blockchain!” alone.
But we’d like to stay optimistic and list a few current noteworthy blockchain-based tools:
- Dust / Mercury Protocol — “smart contracts”-based suite.
- e-Chat — instant messaging platform.
- Status.im — mobile and desktop secure messaging app.
- NoteChain — note taking, synchronisation, and sharing app.
We are yet to see whitepapers explaining the exact strength of the cryptographic designs under the hood of these (and many other emerging) blockchain-based solutions. If we missed something and you’re aware of the existence of such whitepapers, could you kindly drop us a link?
If you’re trying to implement data storage while also attempting to make it “out of the box”-compliant with a privacy regulation like GDPR with the help of blockchain, there are still some points you cannot solve using blockchain alone. You’re still going to:
Need encryption (despite many claims we’ve heard about “some products not needing encryption to comply with GDPR”, the recently published official GDPR checklist for data controllers explicitly stated the need for encryption).
Have very expensive writes: propagating updates on consensus-based decentralized network are time-consuming.
Implementing the right to rectification as described in GDPR is going to be complicated — and only possible through versioning records and making each update as costly as a new write.
Implementing the right to be forgotten as described in GDPR is also very problematic — if it’s on the chain, it’s there forever. Either the data is stored in an encrypted form and keys are elsewhere, or it is in pseudonymized form and then the PII references are stored elsewhere. In both cases, it’s rather problematic to implement such a thing while preserving the pure decentralized principles (but this is an interesting challenge and we’ll be glad to see developments in this area).
Expensive writes in blockchain, illustrated in the most bizarre way possible. A blockchain based collectors game for breeding cartoon pets “CryptoKitties” became so popular in 2017 that it took up a significant amount of the available transaction space on the Ethereum open source blockchain platform, jamming up the network, leading to delayed and unprocessed transactions.
Blockchain is a great invention that solves several pressing technical challenges. Sadly, while it can help you grow a collection of virtual cats or anonymously buy a fake Bulgarian passport, using it won't make your product "secure".
Security and compliance with the demands of various personal data privacy regulations remain firmly out of the scope of the problems that can be solved with the help of blockchain and its numerous “crypto”-derivatives. You don’t have to search hard to find some research on existing security threats or an example of security flaws in blockchain-based projects, and Blockchain Graveyard can serve as a particularly morbid example of numerous security incidents causing shutdowns of blockchain-based products after security incidents.
So, aside from securing the keys, building trust to code and protecting consensus from consensus attacks, you need to:
Until then, blockchain remains little more than a very promising technology for storing public and private logs of state changes of digital assets. Which is a huge advance in many areas, if treated with appropriate expectations.
We can help you to build a secure system from scratch or
improve security in your existing products.
* If you want to talk about cryptozoology, ping us any day, conspiracies are fun!;)
Want to get “Don’t Roll Your Own Crypto” stickers? Write us a few words about you and your company, we’ll send you some.