Demystifying the Security of Blockchains
Security is a word we hear a lot, especially in conversations about blockchain. But when a project claims security, what guarantees does it provide exactly? Maybe more importantly, are there some critical aspects of security missing from existing blockchains? To answer these questions, a clearer definition is needed. In this post we aim to clarify what security properties current blockchains have, how confidentiality and privacy are a critical missing feature, and ways we intend to fill that gap.
Classical Definition of Security
Let’s suppose Alice and Bob want to run a program f(x,y). The inputs to this program are private: Alice knows x, and Bob knows y. The challenge is they want to learn the result of the computation without letting others know the private inputs. This could be achieved if we had an (imaginary) trusted third party (TTP) who accepts the input from Alice and Bob, faithfully executes the program, and reliably hands back the result. This trusted party won’t do anything else beyond what’s prescribed — in particular, it won’t tell others about x and y.
One way to define security of a protocol is to compare it to this TTP. The security defined by the above TTP has the following three key properties (sometimes they’re referred to as CIA properties):
Does the imaginary TTP exist in the real world? Well, not really. But we can approximate one if we make some specific assumptions. For example, many people treat banks and governments as TTPs, based on their reputation, social position and other factors. Smart contracts, on the other hand, are an approach to achieving some of the key components of TTP’s without placing trust in centralized entities — however, the emphasis is on some because smart contracts don’t achieve them all by default.
Security of Smart Contracts — What’s Missing?
When people talk about the security of Bitcoin and Ethereum, they are really just talking about integrity and availability, not confidentiality and privacy.
Ethereum, the leading smart contract platform, for example, has a network that consists of thousands of nodes, with each node running a complete copy of the Ethereum blockchain. When you execute a smart contract at a certain address on the Ethereum network, its execution is verified by all mining nodes before being recorded. So if the majority of computing (hashing) power is controlled by nodes that are executing honestly and follow the Ethereum protocol, your smart contract evaluation will be correct; this correctness fulfills integrity. The Ethereum network also offers some guarantee of availability: unlike a centralized entity, which might have servers in a single datacenter, the Ethereum network is distributed around the world. So while it’s possible that some subset of nodes will go down at any point, it’s unlikely that every node will.
But what Ethereum and many other blockchain projects lack is confidentiality and privacy.
There is a common myth that since participation in a blockchain network doesn’t require a name and a social security number, it’s private. Unfortunately, this is a misleading and even dangerous misconception. Just because people use pseudonyms doesn’t mean their on-chain activity is invisible. In fact, since every single bit of the transaction activities (on Ethereum: addresses, amount, gas price, etc) is recorded and displayed on a public ledger, a lot of intelligence can be inferred and used against one’s privacy (e.g., using the transaction network structure to retrieve plaintext transaction information). Moreover, with more and more complex dApps developed, user data is becoming an important fuel to power applications such as credit scoring, insurance, and identity management. On Ethereum, the smart contract input data needs to be public and on the blockchain, because that’s how all nodes can perform verification.
Over the past few years, a number of cryptocurrency projects have attempted to address the lack of data confidentiality by using cryptographic techniques such as zero-knowledge proofs. But many of these projects have focused on simple payment transactions, rather than more complex applications such as machine learning and data analytics.
Achieving Data Privacy
The aforementioned confidentiality property is an important prerequisite to achieving data privacy, but it’s very important to point out that confidentiality is in general insufficient for data privacy. Specifically, confidentiality focuses on protecting the computation process from leaking sensitive information. It guarantees that nothing is revealed from the computation process besides the computed output. However, it says nothing about the potential data leakage via the computed output. In other words, a perfectly confidential computation might still give away information about the private inputs from its output.
Using the same paradigm as above, confidentiality means Alice and Bob only learn the result f(x, y) and the attacker learns nothing. Data privacy requires that in addition, the result — f(x, y) — can’t be used to infer x and/or y. A simple negative example would be f(x, y) = x+y, where Alice (knowing her input x) can immediately know Bob’s input given the result x+y. For a realistic example, our recent research (together with collaborators from Google and UC Berkeley) has shown that machine learning models can leak information about the sensitive data they were trained on. We refer to those computations that won’t leak the input through computed results as privacy-preserving. For example, differential privacy is a mechanism to achieve this.
At Oasis, we are building a privacy-first cloud computing platform on a blockchain. To achieve data privacy, Oasis builds in privacy at every layer of the platform. We enable confidentiality-preserving smart contract execution at the compute layer to protect the computation process from leaking sensitive information, and enable privacy-preserving data analytics and machine learning at the application layer, including differential privacy, to protect the computation outputs from leaking sensitive information about the inputs. We also design and develop a new blockchain architecture to enable high scalability with decentralized trust. We’ll dive into more details about the Oasis technology in upcoming posts. Stay tuned!
Join Us!
Please join the developer discussion with us on Gitter. We invite developers to join our private testnet: please fill out this form to join our private testnet.
For further information about Oasis Labs, please contact us at info@oasislabs.com.
