zkSummit - ZK0x02 - Privacy-preserving smart contracts - Noah Johnson (Oasis labs)

Transcript

okay hey everyone my name is Noah Johnson I'm going to talk about privacy preserving smart contracts so a bit about myself I'm a PhD student at UC Berkeley and also a co-founder and chief product officer at Oasis labs which is a company building a smart contract platform based on some of the research I'm going to talk about today so let's start with a brief history of a blockchain so of course blockchain became popular in 2009 with the introduction of Bitcoin later if the rim came along and introduced the concept of smart contracts and showed how to run general-purpose computations in a distributed way and then recently we've seen the rise of new sorts of

applications including games like crypto kiddies crypto kiddies is interesting because it's the first blockchain application that really went mainstream unfortunately crypto keys also exposed cracks in our current infrastructure when crypto kitty's was popular last December it caused major congestion in etherium it caused transaction costs to go through the roof so this is where we are today and there's a question of you know what what do we have to look forward to in the future if you're bullish about blockchain which I hope everyone here is then you'll agree that in the future blockchain will power a set of applications that are significantly more complex than crypto kitties and anything that we've seen so far these are

applications that people get excited about when they talk about blockchain and its revolutionary potential things like credit scoring medical diagnostics private auctions and so forth and so my talk today is going to focus on what are some of the challenges for supporting these applications and what are requirements of the underlying infrastructure in order to address some of those challenges just a quick teaser you'll notice here that all of these applications require a lot of computation and they all require a lot of data and oftentimes the data is sensitive so let's start with a concrete example to sort of motivate the challenges this is a credit scoring application so in this application you

have a number of institutions that contribute their data into a smart contract which is designed to train a machine learning model with that data and of course this runs on workers or miners that are part of the underlying platform and the smart contract might output you know a model from from this training data there are variations of this maybe the model would be stored inside the smart contract and the smart contract would expose a way to to query the model but but the challenges are the same either way so this is great it's a great use of blockchain in that all of these institutions know that if they do this with a smart contract the data will only be used for the purpose of training this credit scoring model and users who may

want to apply for a loan based on this model have visibility into how their data is used and how the model is trained so this is ideal unfortunately if you try to build something like this on today's platforms you would face a number of issues that essentially make these sorts of applications a non-starter the first issue is that of course the data is very sensitive and so there's nothing stopping workers that actually run the smart contract from stealing the data even if you trust the workers not to steal the data there's also this risk that when you're training a machine learning model on sensitive data the output model itself might leak information about the inputs now you might think well clearly a machine

learning model is you know already private right and hopefully by the end of this talk I'll convince you that that's not the case and then the final challenge of course is that today's block chains just fundamentally aren't designed to scale to complex workloads like machine learning already you know we saw crypto kitties even though the breeding algorithm in crypto kitties is not that complex even something like that you know significantly slowed down the entire aetherium network so fundamentally those platforms are not going to be able to accommodate these sorts of more advanced use cases so each of these problems actually requires a solution at different layers of the stack and so I'll talk about solutions for each of these at the lair of the workers that is the risk

the machines that run the smart contract leaking sensitive data we have a technique called confidentiality preserving smart contract execution at the layer of the application and specifically the risk of data leakage through the result of the computation we have a class of techniques called privacy preserving analytics and machine learning and then finally at the infrastructure level we have some new design that allows for more scalable smart contract execution for significantly more complex types of smart contracts not just simple transactions which is the focus of much of the work in this space so right so this requires a top-to-bottom approach from the application layer all the way down to the infrastructure and we'll see

to the hardware layer in this talk I'm not going to talk about scalability you know this is of course a hot topic in this space there are a lot of projects that are looking at how to build more scalable platforms given this as the zero zero knowledge summit I'm going to focus on the privacy related problems so I'll talk about confidentiality and privacy so the first one confidentiality preserving smart contracts so the basic abstraction of a smart contract of course it's a piece of code that takes some input and the current state and it runs the code on that input and outputs a new state which is recorded back to the ledger the abstraction of a confidentiality preserving smart contract is that all of these inputs and outputs are encrypted that means that

nobody can see the data not even the workers that are executing the smart contract now given that no one can see the inputs and outputs it's essential that the system provides a way for the workers to prove that the execution result is correct and we saw how this works for example for zero knowledge proof swear essentially zero knowledge allows you to run all of the computation locally and only output this proof but the more general version of this problem is you have some piece of code the data is sensitive you can't rerun the computation locally yourself to convince yourself that the result is correct right because the data is secret and so we need schemes that allow proving that the result is correct even if you can't see the underlying data so it turns out

there are a number of different technologies that can be used to implement confidentiality preserving smart contracts and these can be kind of broadly categorized into hardware based approaches and crypto based approaches so the challenges of these cryptographic approaches like multi-party computation zero knowledge proof and homomorphic encryption is that they tend to be very slow they incur often orders of magnitude performance overhead compared with native computation and so one of the research goals for our platform is actually to combine these different techniques together to allow the developer to choose which application makes sense because each one has different trade-offs in terms of the performance and the classes of applications that it can support in this talk I'll focus specifically on secure

Hardware because we've heard many of you know many discussions on you know really exciting new work for some of these other techniques so secure hardware is a technology there's various implementations of this but the fundamental abstraction is what's called a trusted execution environment also known as an enclave and an enclave essentially is a piece of technology that allows an application to run in a protected way so it Enclave provides two important security properties the first one is that it guarantees that the operating system and other applications can't modify or tamper with the execution of the application inside of the Enclave so this is what we call

integrity it means that the computation result is guaranteed to be correct the second property is confidentiality so this means again that the operating system and the applications as well as even the user of the machine can't actually inspect the state of the execution including the code and the data and secure enclaves also provide what's called remote attestation so the hardware can generate a a proof essentially of the contents of the Yun clave where that proof can be verified by a remote party even if they don't have physical access the machine to prove that the right code was running inside the Enclave and that the entire thing was running on authentic secure hardware so essentially you can think of secure enclaves as a black box that

can't be viewed or tampered with even by the operating system the hypervisor and the user of the machine itself so you might notice actually that this property of integrity that is in teeing that when a application runs on a remote machine the execution result is correct actually it's very similar to some of the goals of smart contract platforms it turns out that both of these technologies actually have similar goals they both try to run a piece of code in a way that achieves certain properties and they do this in very different and complementary ways so smart contracts and platforms like aetherium of course they guarantee integrity just by virtue of the

consensus protocol that's used also they have strong availability and persistence because they are replicated and decentralized and store state you know immutably on a distributed ledger but today's smart hotshot platforms don't provide any confidentiality now trusted execution environments also provide integrity that's enforced by the hardware on the other hand they provide no availability or persistence right you can just turn off the Machine and you lose all the state that's running but they do provide confidentiality so if we can combine these different technologies together essentially we can get the best of both worlds and that's exactly what we did in a recent research paper called akedan so this is a collaboration between Berkeley Cornell and UIUC and in

this paper we show how to combine secure hardware with block chains in order to essentially endow smart contracts with confidentiality so the key idea is to execute the smart contract itself inside of this secure Enclave and then store the state back to blockchain in order to get persistence so getting this all to work is actually quite a bit more complex than you might think you know you need to separate the execution from the consensus because secure enclaves have no you know Internet connectivity you need to design new cryptographic schemes to prevent replay attacks and rollback attacks so there's a lot of interesting details I encourage you to check out the paper if you're curious about that in this paper we implement several different applications that show

you know the advantages of being able to keep smart contracts state secret we also ported an EVM to run inside the Enclave so that any existing aetherium smart contract can immediately benefit from confidentiality and to you know to demonstrate this we ran the actual crypto kiddies breeding algorithm inside the Enclave so this is a good example actually of you know the advantage of keeping state secret the developers of crypto kitties actually intended to keep the breeding algorithm secret they obfuscated it and didn't release the source code but because on aetherium of course even the bytecode is public then people were able to reverse-engineer it and and sort of game the system in order to you know increase their likelihood of breeding valuable cats so this is really promising it suggests that trusted hardware could be

used as primitive for secure computing not just for block chains but for general computations in particular secure enclaves provide a number of strong security properties including the ability to authenticate the hardware itself the ability to authenticate the device and to guarantee the integrity and privacy of the execution even for you know executions that run on remote machines so this could become a platform for building new security applications and there's actually several recent research projects that show how to use secure enclaves for cloud computing these aren't specific for blockchain but they are solving a very similar problem and actually all hardware manufacturers or at least the major hardware manufacturers recognize the importance of this problem so they've all shipped

versions of secure Hardware in their recent chipsets most notably and well-known is Intel secure software guard extensions but nvidia and AMD have shipped secure hardware as well now not all of these provide the core features i described earlier for example and these version only guarantees confidentiality it doesn't guarantee integrity but this is clearly the direction that the industry is moving but there's still major challenges so all of the secure computing techniques i described earlier including the cryptographic techniques all have different trade-offs in terms of the adversary model and this is true of secure hardware as well so what I described earlier those properties are of course properties of the abstraction

those are ideal properties of a secure Enclave in practice of course there's no such thing as a perfectly secure system it's a matter of trade-offs and so there are some open questions of how secure can secure Hardware be and under what threat models you know an interesting thought experiment is you know what would you entrust to run inside one of these secure execution environments you Bitcoin Keys your financial day your health data you probably are already using some version of trusted hardware if you use a hardware based wallet right and you can see the advantage of having a hardware based mechanism to protect the sensitive material in this case your Bitcoin keys which means that even if your machine is infected with malware unless someone has physical access to the machine or to the

device they're not able to steal your keys and so in some sense secure enclaves are just a generalization of that concept and of course you could layer these other secure computing techniques on to secure enclaves to provide additional security like you could run multi-party computation inside of an enclave because multi-party computation has a different threat model that is complementary to secure enclaves multi-party computation assumes that multiple parties aren't going to collude and share answers whereas secure enclaves assume that someone can't physically tamper with and break the key properties of the hardware device so one of the research directions of Oasis is how can we do even better than what we have today in terms of the security and

so in order to get there let me list out what we think are the key properties of a secure Enclave the first and most important is that it needs to be an open source design so everything in the block chains everything in the blockchain space of course is is open source and so to the extent that you're relying on hardware for any part of the security or integrity of the platform the hardware itself had better be open source as well and there are advantages to having the hardware being open source that means that it's more transparent it allows other researchers and security experts to audit the design it's more amenable to formal verification and so unfortunately and as well as secure supply chain so if it's open source and

in the public domain then any chip maker can actually tape out one of these secure Hardware chips and so today's secure hardware technologies actually don't provide this property but we're working on a project that does so there's this ongoing project called Keystone which is a fully open source design for secure hardware and this is a collaboration between Berkeley and MIT and they expect an initial release in fall 2018 the key stone design is based on the risk 5 microarchitecture which was developed out of Berkeley and the nice thing about you know building on top of risk 5 is that it's already widely adopted in industry and so the plan for this project actually is to have an initial release in the fall that runs on FPGAs

and then a release later I think early next year that actually runs on an existing risk rife chipset last week we actually had a workshop at UC Berkeley that brought together industry and academic leaders in secure enclaves and the workshop was specifically focused on kind of open challenges and building a fully open source you know secure Enclave so that was exciting ok so that concludes the first part of my talk where I talk specifically about techniques for securing the computation now assuming that we've secured the computation so that workers can't leaked it now the natural application for smart contracts is let's do things with sensitive data because now we have assurances that the

workers can't leak data and so now this brings in a completely different set of challenges related to how do we safely use sensitive data in such a way that smart contracts can do useful things with the data but we can still guarantee the privacy of the users in the original data sets and I want to discuss this briefly because I think it's a problem that is still at least today less understood in the in the community so I'll discuss the challenges in general way but hopefully you can see how these apply directly to a lot of the smart contract applications I listed earlier so to motivate privacy risk let's suppose we have a data set of trips right and you know on the one hand we have a an analytics question that asks

how many people visited New York last year and on the right we have a you know a question that asks how many trips did Joe take last year so clearly the question on the left is safe right it doesn't violate anyone's privacy whereas the question on the right very clearly violates Joe's privacy now these questions are asked of exactly the same data right the only difference is specifically what type of question was asked and what information is revealed in the answer to that question and so there's sort of a broader question here how do we reason the difference between these two queries the fact that this one is sort of intuitively safe and non privacy violating and this one very clearly violates privacy and how do we you know

these are two extremes but how do we kind of bridge the gap and reason about something in between and in addition to kind of formalizing this there's a question how do we build a system that can automatically allow things that are safer and protect against things that are less safe so I want to point out that actually this isn't an access control problem this is not a problem of just restricting access to certain portions of the data because again both of these queries run on exactly the same data set and again the only difference is what specific question is asked of the data so that's privacy risks for statistical queries you also need to be very careful when training machine learning models on sensitive data so one

example and there's a paper that illustrates this is training a deep learning model on some email training data that had social security numbers and credit cards and this paper showed that actually an adversary can query the output model in order to reconstruct the original input data credit card numbers and social security numbers strictly from the model itself and in other work people showed how to if you know properties of one person's data it's very trivial given the model to determine whether that member was part of the original training data or not and one more example is here's a here on the right sorry the left is an image that

was reconstructed from an image classifier model that was trained on an image on the right okay so clearly there were major privacy risks even for things that seemed innocuous like statistical queries and machine learning on sensitive data what people have done today the sort of the state of the art technique for addressing these problems is called data anonymization and how data in autumn is a ssin works essentially is scrubbing fields in the data that could reveal individuals and there are different versions of this the basic idea is of course names could identify people IDs oftentimes can be linked so we're going mask that data certain information we might bucket so that it's more coarse right so that there are fewer distinct

values and so forth and so once we've done this process then this is the data set that would be released for analytics so this might seem good on the surface right we've removed PII we've masked any information that could be used to identify individuals it turns out there are actually a few problems with this the first is that the process of anonymizing data actually excuse the results of analytics on the data even analytics that would otherwise be be safe so for example you know if a doctor is training a model for detecting the risk of high blood pressure if this is what the actual result is then anonymizing the data set may very well produce a result like this and the reason for this phenomenon is that the

process of anonymizing the data is very blunt right it doesn't take into account specifically what's being done on the data and an example like this actually all the users would prefer probably that this particular model was trained on the original data set right because it clearly doesn't harm any of their privacy and all of them benefit by a more accurate result okay so that's one problem the second problem actually is that anonymization is ineffective so oftentimes an adversary can take an anonymized data set and combine it with other outside information in order to re-identify individuals in the data set and this isn't just a theoretical attack actually there are a few high-profile examples of exactly this type of attack

so the Netflix prize does anyone remember the Netflix prize netflix released anonymize records of customer movie ratings and they had this contest for data scientists to train better recommendation models for for movies and so they anonymize the data set according to best practices and released it to these researchers someone showed how to take movie ratings on IMDB and linked those to records in the original data set in order to reify certain individuals in another more recent example New York City released anonymized taxi logs and a security researcher went to celebrity gossip blogs and found pictures of celebrities getting into taxis and then from those

pictures it was trivial to link those rides to the original data set right because they knew exactly what time they got in and and from what location and so he could figure out where they went and how much they tempt so the point here is who knows what other data is out there right and if you're relying on them as uh Nenana zation to protect privacy you don't know what data set might be out there either today or in the future that would allow someone to do these sorts of attacks so this is not a viable solution turns out there is a better solution and it's called differential privacy so I'll discuss this kind of it at a conceptual level this is actually backed by you know rigorous math but I'll try to give you an intuition for for how differential privacy works the the basic

definition says that if you have any two databases that differ only in one users data so for example Joe is in database one but not database to differential privacy says that any query you run on those data sets or in our setting any smart contract the output against those two databases had better be essentially the same in other words there can be no way from the results to tell which of these databases was used to run the query so this means there's no way to tell whether Joe was in the data person or not so this the differential privacy actually says that this has to hold true for every user and every data set and so this is nice because it aligns very well with kind of our intuitive notion of

privacy that is to say this guarantees that well I might be comfortable allowing my data to be used for some purpose I don't want whatever you're doing with my data to be able to identify my record or even whether I was in the data set or not or not if you look in the literature there's some the formal definition is primer eyes by what's called a privacy budget so the nice thing about differential privacy is that because it's so general in such a strong definition it means that from a user's perspective if they know that differential privacy is enforced they don't need to worry about specifically what computation is running right as long as this property holds it doesn't matter what this query is doing now the

user might want to know anyways but from their perspective as long as the system can guarantee that this property holds there's no downside to the user contributing their data so they had better contribute their data anyways because the results would be the same and so this is a nice definition especially for blockchain the problem is that it's just the definition and so most of the previous work in this space is largely either theoretical or focuses on very specific applications so Google actually uses differential privacy to track website visits in in Google Chrome and Apple uses it to track statistics about emoji use on an iOS so outside of these limited domains there still today is no general purpose system for enforcing differential privacy

automatically so this was the subject actually of my dissertation is building a framework to automatically enforce differential privacy for general purpose queries in an automated way and so in the interest of time I'll skip over some of these details I want to point out first of all that the system is already deployed internally at uber so all internal queries that are submitted by a data analysts that uber actually go through this system to enforce difference or privacy and and other companies are starting to deploy it as well and the the entire thing is open source so it's available on github so the idea is to integrate some of this work into the application layer the development layer for smart contracts so that you know developers who are building new smart contracts on

sensitive data don't have to be security experts in order to build smart contracts that are you know by definition private and preserve privacy in follow-on work we showed how to build the system to automatically enforce differential privacy for machine learning models so a data scientist defines a machine learning pipeline the system automatically converts it into a new pipeline that when trained on sensitive data automatically enforces differential privacy the nice thing about machine learning actually is that differential privacy is a very good fit for a machine learning because the the goals of machine learning of course are not to over train on any individual's data so by satisfying differential privacy actually it turns out in certain cases you can produce a more robust

model that is more resilient against overtraining because that's exactly the property that is trying to be addressed by differential privacy that is the output can't overly influenced by any individuals data so I talked about this as a top-to-bottom approach now you understand a little bit more about confidentiality preserving smart contracts and privacy preserving smart contracts we think the combination of those properties together with you know increased scale ability is useful for a wide range of different applications that fundamentally can't be built today on on platforms like aetherium so here's a list of some of them in a collaboration between Berkeley ETH Zurich and Stanford healthcare there's already an application that is built

using this technology called Cara so Cara is trying to solve this problem that today a lot of data is the medical data is locked in these data silos so it's underutilized and the data is extremely valuable for research purposes but of course the data is very sensitive so oftentimes users and doctors are reluctant to share the data and so Cara essentially is it is a data market that's built on on blockchain that allows patients to input their data in the current version they scan it or input it with a mobile app that gets stored in a smart contract researchers who want to train models on that data can pay tokens and the smart contract will automatically train their model on the data and the users get tokens in compensation for for contributing their

data and the researchers get as output the trainer model so the nice thing about this number one is with confidentiality preserving smart contracts users and researchers have assurances that even the workers that are helping to train these models won't be able to view or leak the data and with differential privacy right patients don't have to worry about exactly what kind of model is being trained they know that there's no way from the model that a researcher could even identify them and of course you know the importance of scalability if you want to do something like machine learning and have this scale to you know millions of users and so forth and you want it all to run on chain without having to resort to off chain solutions for example because you want to integrate with tokens then it's important to have a platform that can

scale to these sorts of more sophisticated workloads so that's Cara and that concludes my presentation Thanks [Applause] are there any questions couple cool hi thanks for the talk I'm wondering if you can talk a bit more about where you see data living kind of like in its stagnant state whether that's encrypted whether it's on users own personal devices to me the idea of just data like personal data

on a blockchain doesn't really make sense I don't see like we have strategies for sharding great but ultimately data is something that should only ever live on devices of people who actually need it and so if you can just talk a bit about how you think about where data just resides in more of a stagnant State in these kinds of models yeah yeah so of course when the data is at rest it needs to be encrypted if it's stored remotely anywhere right that's just a fundamental property of security what I described doesn't presume necessarily that the sensitive data is stored directly on the blockchain so the platform that in practice the system provides flexibility for storing the data wherever you know users are comfortable with and the smart contract has a way to ingest data from different data sources so the platform can integrate with you know distributed data

stores it could allow users to directly send their data when they call in to the smart contract they could allow it to be stored on the blockchain but there are other reasons why you might not want to do that scalability reasons in addition to privacy back here in the back yeah when you were talking about the secure Enclave you had mentioned the smart contract executing inside of the secure Enclave and then you mentioned that that secure Enclave would be offline how would the results of that computation end up communicating back to an on chain event in the case that it's offline yes so there's software that runs outside of the Enclave that is responsible for constructing the Enclave in a secure way and getting the encrypted data into the Enclave once the Enclave finishes executing it returns the results you

know up the stack to the software that's running in the untrusted space but the date the results are encrypted inside the Enclave so it's only the encrypted results that are sent back and so the code that's inside the clave doesn't have network access but the worker that is actually running the computation runs some code in the untrusted space that is responsible for returning the results back to the blockchain so far as far as I remember for what I've read about a seeker in place especially provided by by manufacturers like like Intel it was required to have some sort of

collaboration with Intel about using the secure Enclave with a certification or some some process in place now if you put that in an open source design and put it on the blockchain wouldn't that be a very fertile ground for dark doubts to arise and actually run maybe maybe their own special version of a voting client inside that Enclave in return for some ether that I get once I I have the remotest attestation that I voted in in the way the dark doll will want it for me so I'm not sure I fully understand the attack but what you were describing earlier yes

and in Intel's current design they are a central party that needs that is responsible for verifying that enclaves are genuine and that these remote Etha station certificates were produced by genuine hardware because Intel is the one that embeds the private keys into the hardware so Intel is the one that knows which private keys are valid for these signatures as far as the attack on so the attack is rather is actually pretty straightforward so what could happen is that you promise someone to an ether if you vote on some whatever a random system in in his favor and then he provides you the attacker provides you with a code that actually does the

voting using your private key to actually authorize it so your private key never leaves your device and then he makes sure that you run this code in in Enclave providing the security station of the execution with that you can prove that you voted in his favor and he transfers the easer and and that is that's what's called a dark Dao and you could use that as a perfect fertile ground to actually run these things so it sounds like what you're describing actually is sort of a more fundamental concern with any privacy yeah the same way then not exactly any system but when you use a secure Enclave you have virtually anything at your disposal to do whatever you want without being actually

discovered by anyone so you can actually trick any other system by actually building a network of collude earth working together through through secure enclaves if you just put that on a public blockchain where everyone can just incentivize to run any smart contract in their own clave and as far as I know the only reason why this isn't happening already is that and and that is where my knowledge ends is that there is some sort of verification by the hardware manufacturer before you actually have access to that Enclave I I learned that from from that that hardware wallet what's it called the only one that actually uses the amount lief at the point yeah so I mean that's an that's sort of an application layer

concern right and that could be mitigated with some sort of stronger identity system what you just described is actually not a failure of the platform right yes do you have any ideas how to how to prevent that from happening because you don't want to introduce a trust model where you have to have someone certify your smart contract that that is executed and then in your Enclave depending on the specific application there's potentially mitigations for that I think what you're describing again is a sort of a fundamental property of any system that guarantees privacy and security right in the same way that you know anonymous crypto currencies allow people to launder money without being traced right that doesn't mean that the technology is inherently flawed just because there are certain bad use cases that are enabled

by you know by strong privacy guarantees um I actually got to wrap this sessions done so sorry I know that there's a few more questions but maybe do you want to stick around just outside if there's more questions cool thanks guys thank you [Applause]