Hyperledger Foundation Events, 2 Jan 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Cryptography, Security Modelling, Privacy, and Confidentiality in Hyperledger

Description

Hart Montgomery, Fujitsu Laboratories of America

Achieving strong privacy and confidentiality on a blockchain can be a difficult thing to get right. In fact, it can even be difficult to map real-world privacy and confidentiality requirements into functional blockchain requirements. In this talk we discuss various aspects of cryptography, security modelling, and the techniques involved in different Hyperledger projects--including things like threshold signatures, SNARKs, security games, universally composable cryptography, the shared crypto-lib, Sawtooth's private data objects, and Fabric's channels--that enable us to build blockchains that have various privacy and confidentiality properties. We will give an overview of what it means to be a "secure" blockchain with regards to privacy and confidentiality and explain the best practices towards achieving this.

----
Hyperledger – Open Source Blockchain Technologies

Hyperledger is an open source community focused on developing a suite of stable frameworks, tools and libraries for enterprise-grade blockchain deployments.
It serves as a neutral home for various distributed ledger frameworks including Hyperledger Besu, Fabric, Sawtooth, Indy, as well as tools like Hyperledger Avalon, Cactus and libraries like Hyperledger Aries, Ursa. Learn more about Hyperledger projects: https://www.hyperledger.org/use

Case Studies: https://www.hyperledger.org/learn/case-studies
Training & Certification: https://www.hyperledger.org/learn/training
Tutorials: https://www.hyperledger.org/use/tutorials
Webinars: https://www.hyperledger.org/learn/webinars
Events: https://www.hyperledger.org/events
Vendor Directory: https://www.hyperledger.org/use/vendor-directory

Subscribe to the Hyperledger Newsletter: https://www.hyperledger.org/newsletter

Follow-us on Twitter @Hyperledger

Learn about Hyperledger Membership: https://www.hyperledger.org/about/join

#Hyperledger #HyperledgerGlobalForum2018 #Blockchain

A

All right, hi everybody can you hear me awesome so today, I'm Hart and I'm gonna talk about cryptography security, modeling privacy, confidentiality, just a lot of things about securing block chains from a cryptographic perspective. So some background.

A

Who am I I'm, a research scientist in cryptography at Fujitsu labs in America my day, job is building secure, crypto systems for practical purposes, I have a number of interests outside of blockchain, but I do a lot of work for cryptography for blockchain and before fujitsu, I was a broke grad student in hyper ledger: I am an Ursa maintainer of a TSC member and I've been involved in some other things as well. So that's basically my background with that in mind. Let's move to the talk overview, so what this will not be today.

A

This is not a talk designed to teach cryptographic techniques. We will present some schemes, but that will not be the focus of this talk. If you're interested in this and I think if you're going to build block teams that require privacy and confidentiality you should be I would really recommend the free online Stanford crypto course check that out. If you're interested instead, what I want to talk about today is how to think about security for blockchain, so that we can design practically secure block chains and how to use the cryptographic tools.

A

We have in hyper ledger to achieve best security practices, so this is what I'll focus on today. So, let's start by talking about you know just what people think about security. So at least for me, when I ask people about blockchain security, what do they say?

A

You almost always get a response about tools or techniques rather than formal guarantees, so things like I use, ECDSA signatures or everything is encrypted with 128-bit security, or only hashes and z:k proofs are posted on the chain and I claim that this is usually the wrong way to think about security. So I'm going to start by providing some examples about. So this is something I hear a lot from people on blockchains. They say: oh, we anonymize all users, so we're okay.

A

So if you want to see my blood pressure, spiked mention that you do this on your blockchain, so an example of why this isn't the best idea. So can anybody tell me what this is.

A

It's my credit card history from earlier this year. So if we just go through this, you know it's completely anonymous. What can you learn about me? So you can see. I have some purchases from some snack machines in the South Bay in San, Francisco I have a credit card bill for a restaurant in Sunnyvale, so you can probably start to guess where I work.

A

You can definitely guess where I work it turns out, then you can start telling where I live so I'm buying gas and I'm buying groceries in Redwood City. These places are located and it does turn out that I live sort of in the average of these places there's a receipt from the Stanford gym. So you can probably figure out I have some relationship with Stanford there's a redwood city gastropub so again reinforces where I live and I'm taking uber is around, so you can probably guess that I had some cocktails of this a gastropub.

A

So, just from this, like you know, five-day transaction history, which was completely anonymous, you've learned that you know I work in Sunnyvale, I live in Redwood City I'm, probably a Stanford alum I enjoy beer cocktails, and so you know there probably are multiple people that fit this week in the world. So it might not totally D anonymize me, but if you had my transactions over the course of an entire month, you could probably pinpoint me individually out of everyone in the world.

A

So what this means is being anonymous, didn't really buy me much, and this is especially challenging in the permission setting where I have to have some credentials to participate in the blockchain on the first place and unlike say a public Chane where I can completely. You know refresh my credentials every time, but this is even problematic in the public setting, so many cryptocurrencies incorporate privacy or anonymity techniques.

A

People have no idea what they're doing about you know. What's the best way to to have a private transaction, the guarantees are far from explicit and there have been a lot of misunderstandings about some of these systems. So there's been a number of papers, sort of analyzing the link ability or the traceability of some of these systems, which is sort of the opposite of anonymity.

A

So this is one classic pitfall, so another one I frequently see is people who say well, everything is encrypted or hashed. No data is given in the clear, so I'm, totally okay right so has anybody here seen the movie Wall Street? Maybe so one of the iconic scenes in Wall Street? Is this scene between bud Fox and Gordon Gekko, where they are tracking down Lawrence and trying to figure out his activities?

A

So you can go through the script, but if you remember the movie, there's a phone call between bud Fox and Gordon Gekko, where they figure out that Lawrence who's, a competitive banker he's flying to Erie Pennsylvania. He talked to some accountants, so they correctly deduce that Lawrence is buying a nikhat steel. They make a huge amount of money off of this and calls Lawrence to have a loss. So it turns out that side, channel information like this, which is the name of what this sort of knowledge is called, is everywhere.

A

On blockchains, so just because your data is hashed or encrypted doesn't mean that people can't learn about it. So transaction patterns right, even if we have fully zero knowledge transactions. The mere fact that transactions exist in certain patterns could break privacy or confidentiality. So here's an example, so I've presented two hypothetical complicated financial deals and they have different transaction patterns right.

A

So, if I'm, just an observer on the blockchain I, can tell whether this T alpha or this T beta happened based solely on the transaction flow I, don't need to see anything I can, oh, you know, even if I only see proofs or encrypted data or hashes, the transaction flow tells me what happens so.

A

What I'm, really trying to say here is what cryptography you use is not equal to what security you get so instead, when you're building secure block chains, try to aim for more formal guarantees so for privacy instead of saying something like my users are, and my users are anonymized say it's cryptographically hard to distinguish the participants in any transaction from random right, so you're laughing, but clearly what I did or what I showed you with my credit cards doesn't meet this second definition right for data security right we said everything is encrypted or hashed.

A

Well, what we really want to say and what we were trying to say is it's hard to learn any information about any transaction on the blockchain right. So the main point of this is to design secure systems. You should start by writing down the security properties. You need and then pick the tools you need to achieve the desired security properties.

A

Unfortunately, for most of the blockchain development I see, this is the opposite. Where people pick tools and then sort of just get the security properties they want, and this can lead to bad consequences. So, of course, you're going to tell me defining security is hard. Yes, it can be even for people who have spent their entire working lives.

A

Studying cryptography and I will leave this Easter egg up for anyone who follows cryptographic, literature, but when in doubt, ask someone ask a cryptographer the hyper ledger, privacy and confidentiality working group is actually a great place to get started if you're interested in this sort of thing and I want to mention that weaker guarantees are okay too. So a weak guarantee with the proof about security is much stronger than just throwing potentially strong tools at a problem and hoping that it solves the problem.

A

So, okay, well we've defined what security means for us right.

A

The next step is to build a system that meets these definitions of security right, and so this really is two steps, so we want to build a system and then prove it meets the required definitions of security and yes, proofs are very hard to, but it's important to get right when you have a system that has lots of user data, you really can't afford to not get this right again.

A

Lots of resources in hyper ledger on this, and so one of the earliest cryptographers and most famous ones to get in on blockchain sort of always told the story. Don't get cryptography, get a cryptographer.

A

So this is my advice for people who are looking to build such a system and I would say that if you are building a system, in fact that needs these strong guarantees, I'd highly recommend having someone with knowledge of cryptography on your team, so all right, well, I've kind of gone over a process and some points on how to design secure blockchain systems. What does this look like in practice? So for the rest of the talk, I'm going to talk about tools and hyper ledger that make this easier and a brief warning about tools?

A

Don't design your own cryptographic? Algorithms, unless you have the background and even if you do don't use them until they've, been peer reviewed. There are numerous examples of blockchain of of people violating this practice with hilariously catastrophic results. So I don't really need to go into all of these, because you know this crowd. People are probably pretty comfortable with this principle, but you know we still see people who make this mistake so.

A

Next I want to talk about hyper ledger ursa, so the goal of the project is to build a modular, flexible, cryptography library. You know I think I've been scooped with this line by many other people and talks today, but ursa is intended for and certainly not limited to use by other projects in hyper ledger, and we want to make it much safer and easier for our projects and people who are building on them to use existing time. Trusted.

A

Excuse me time-tested and trusted crypto libraries, but also new crypto library, implementations that are a little bit closer to research stage. So things like exciting new snarks or zero knowledge proof. So here's some links if you're, interested and I will post this slide deck immediately after the talk so feel free to to check these out. So why are sub so people have, you know, mentioned various reasons, but sort of the biggest reason for me was that Ursa allows us to concentrate our cryptographic and security talent and in a single place.

A

The classic example of this not happening is: we've had multiple hyper ledger projects that have attempted to implement pairing based multi signatures without really running them by cryptographers, and all of these projects have gotten it wrong, and while this has been fixed, we really want to avoid these kind of bugs from happening in the future.

A

In addition, as Dan pointed out, Birsa will allow us to avoid a lot of duplication, so there isn't need for lots of implementations of the same protocols. So right now we have a number of projects with essentially identical signature schemes. There's no need for that. It only hurts security.

A

So Dan briefly alluded to this in his talk, but I wanted to talk about the ursa layout, so versus split up into two modules. What we have called the base, crypto Lib and Z mix, so the base crypto Lib, contains basic cryptography wrapped in a modular way very standardized crypto, and the goal is to allow developers to use standard crypto in a plug-and-play manner.

A

So the idea is, if you want to change between particular signal, excuse-me signature implementations say you just change a flag in your belt and you can switch from you know, ECDSA to pls signatures. If you want or something like that. On the other hand, Z mix, which is our more advanced crypto library, contains sort of more complicated novel and less standard cryptography. So Z mix currently has things like smart signatures, which are pairing based, say, aggregate and multi signatures and zero knowledge related cryptographic, algorithms, and this is kind of a work in development.

A

So you can't go download and use these today, but we hope to have them available in the not-too-distant future. The purpose here is to allow developers to use sort of cutting-edge cryptography for blockchain privacy and confidentiality, knowing that they're using secure protocols.

A

So again, the ursa philosophy is essentially to concentrate the talent and hyper ledger to collaborate on a single crypto code base. So this is really three layers. This is the theoretical cryptographers, the crypto engineers and the security experts, and really there isn't a single person in hyper ledger or probably well very few in the world who can cover all of these levels. So it's important that we have everyone. One of our other goals is to help enable interoperability between blockchain platforms, and we do this through modular cryptographic interfaces.

A

We also well hope to help hyper ledger, maintain high standards for security across all of the platforms, and if this sounds interesting to you, please feel free to join again. We are an open community, so come to their meetings, join the mailing list and so forth. So with this in mind, I want to show you of how excuse me I want to show you an example of how you could possibly use ursa.

A

So suppose, I want to institute the following security requirement. I want to say that no adversary that compromises less than K nodes should be able to sign transactions and I realized. This is a little bit vague, but this is something that could be used in numerous places across block chains, so I'm going to throw some notation at you here so so bear with me for a little bit. But everyone here is familiar with basic digital signatures. Right I assume everyone should raise their hand.

A

So so I've defined some notation. You know don't get too worried about it, but it's pretty simple right. So we have a key generation algorithm, a sign algorithm, a verify, algorithm right. You all are familiar with these, so security right intuitively. We can't Forge signatures, but how many people here know the actual security game for digital signatures?

A

Marta anybody else.

A

Thanks for paying attention so.

A

Here's the to give you an illustration of what you want to think about when you're defining security, here's the game for digital signatures, so we have an adversary, who's allowed to query assigning McCorkle.

A

He sends the Oracle messages em and gets back signatures and at some point he has to forge a signature on a message that he is not queried. So this is all really simple, but I just wanted to point this out to show you kind of why it's important to think about security protocols, because otherwise you know you might come up with a signature algorithm where an adversary doesn't get to see signatures which would not be realistic. So going back to our original problem, which is the security requirement.

A

Well, what are we going to use and I? Think a lot of people here can probably say that well we're going to use threshold signatures right. So what's a threshold signature if you're not quite familiar with the math, this is a little difficult to digest, but I'll explain it. So what a threshold signature is? Is we share keys between n players, so any K out of the end players?

A

Can create signature shares that when they combine them together, they form a valid signature, and that's all that this notation is saying and again I'll just put this up. There I'm not going to go through this, but this is you know what a threshold signature security game looks like and well.

A

You can think about this kind of thing when you're designing secure blockchain systems, so that was a lot if you weren't used to it.

A

So there was no Methot right, so a lot of people when they think about crypto get very involved in the math, but the proper thing to do when you're designing systems is to think about things at our protocol level. So how can people interact with your blockchain? What can they do? What can they learn and incorporate this in your model when you're building a secure system so now I want to talk about another tool which is channels how many people are familiar with channels and fabric?

A

Okay, awesome, a good number of people, so a security requirement for which channels might be a good tool to use is to say something like no adversary. Who is not a party to a series of transactions should be able to distinguish anything about the transactions that cannot be inferred from the start and end State.

A

So, basically, if we move something to a channel right, we're going to do a bunch of stuff and move it back and an adversary shouldn't be able to figure out kind of what's going on in the middle, and this is a very useful guarantee to kind of avoid our Wall Street example with the financial deal. So if you recall t alpha and T beta well, if we use a tool like this, we might hope to make it so that an adversary can't learn which transaction took place.

A

So for those of you that don't know what channels are, the basic idea is a channel as a subnet or sub blockchain for a subset of participants to perform private and confidential transactions. So nodes not on the channel, should not know channel specific information. So how many people are familiar with lighting network awesome, so you can kind of think of channels as a permission version of lighting network, not exactly identical, but it's good for intuition purposes and the other thing about channels is. They still require a pretty good amount of development.

A

If you want to get these properties, so here's a graphic of sort of what a channel use might look like. So imagine we have some typical blockchain activity, we're kind of along and then all of a sudden we move an asset to a channel. We escrow the asset in the original blockchain and then you know we can have typical blockchain activity on both the channel and the original chain. So we sort of perceived as follows, and then at some point we want to move the asset back to the original blockchain and close the channel.

A

So we do that and the goal should be that only participants on the channel can figure out these intermediate states. So if we kind of look at the the top channel right, no one should know what's going on with that asset unless, unless they're on the channel.

A

So again, channels are a very general tool, but the exact security properties and definitions depend highly on how you use them and what you use them with so be sure your algorithms, with the channels compose properly, has anyone use channels in a system in their blockchain yeah, so be very careful that your your algorithms compose, because in general, composing cryptographic protocols is very tricky and there's a whole field on this called universally composable security.

A

We don't have time to talk about it today, but if you're interested I highly recommend looking it up and again channels aren't quite ready out of the box, so you might be saying at this point you know well, I've only told you things that have really weak guarantees right and you want strong guarantees. So suppose you want something like the following: no adversaries should be able to learn anything about any transaction in which it is not involved, say outside of traffic analysis.

A

So it's ok to weaken your guarantees a little bit sometimes right, we'll let an adversary, learn the traffic patterns, but nothing else. So this is what's called a black box Oracle right. So things go into the black box, they come out, but you can't see what's happening inside the box.

A

So the problem with this is it's actually too strong, and if we want to achieve this, we're going to have to make another assumption. So we're going to have to assume that no adversary can sting wish. A certain trusted execution environment from a virtual black box.

A

There exists something that will help us solve this problem that it's currently a hyper ledger lab that works with hyper, larger, sawtooth and I will say: I'm surprised, I, didn't get any eyes raised or laughter when I mentioned this assumption, because this is a huge, pretty huge limitation of the adversary.

A

Many trusted execution environments are currently leaky sips when it comes to things like side channel attacks. So what is a trusted execution environment before I? Go any further? Do people are people comfortable with these? Do people know what they are who's heard of Intel SGX, awesome perfect. So, roughly speaking, they are processors that are difficult for an adversary to look inside, even when they have physical access.

A

So here's kind of an illustration, so a malicious node operator, with physical access to a chip shouldn't be able to do anything more than observe the inputs and outputs, and this is not quite a reasonable assumption, given our knowledge of side-channel attacks, but it's one still a lot of people use so there's a currently a hyper ledger, lab called private data objects and, in a nutshell, what this involves is running. All smart contracts inside the tea which in this case is SGX.

A

This gives you fantastic efficiency for most applications using SGX is not much slower than native code and you sort of get best possible security, so ignoring traffic and transaction patterns. If you trust the chip manufacturer and ignore many known side channel attacks, but this is a Faustian bargain.

A

So when you use cryptographic protocols that you know don't meet the model of security, you have you you're playing with fire.

A

So that's about all I wanted to say today and I'm, not too much time is left, so I'll just conclude and offer some takeaway points before answering questions. So the first thing I want to reinforce is that when you're designing secure systems think about the security properties, you need. What do you need in terms of protecting user data, protecting transaction confidence? Utila excuse me transaction confidentiality and so forth, and then pick the appropriate tools to meet the security properties. You need to many people today seem to do it in the opposite way.

A

I'd also recommend using standardized and peer review tools. This pretty much goes without saying, but we see a lot of people not do it and get help if you need it, there's help out there. So at this point, thank you for your time and I'd like to answer any questions. Thanks.

B

Hi, so why would you choose the language roster when implementing also.

A

Why rust so rust is C? Callable is the short answer. Has a lot of good safety features and it's relatively easy to to port to other languages. I think Dave can probably give you a better answer, because he is something of a rust religious fanatic.

A

Dave can can convert you to the the temple of rust.

A

Any other questions.

C

How would you compare security models or attack the vectors for different hyper ledger frameworks? I.

A

Think it really depends on the application right, so the attack surface is really more application based than platform paste. So it's. What are you doing? What are you doing in chain code? What are you doing in smart contracts, more so than the platform itself? So there are attacks on the on platforms, but those those are kind of orthogonal and and I really wanted to to kind of focus on the the privacy and confidentiality to applications.

B

Dave, so if someone wanted to get involved with the ursa project, where would they go and what are the kinds of people we're looking forward to help out.

A

Great question No, so there's a link to the project page. We have a mailing list Ursa at list hyper Ledger. We have Rocket chat, channel versa, so I'd highly recommend joining the mailing lists, joining the rocket chat and joining the meetings. We have bi-weekly meetings, I guess they're Wednesday afternoon, Switzerland time there, unfortunately early for me in San Francisco, but that's just life.

A

So yes, please reach out, and you know you're more than welcome to email, one of us to as well. If you're interested.

D

Just one point: for the last one you mentioned: which was DS right: could you could you say that there are the hardware equivalent of nice well tested cryptographic, library in the way right so.

A

If you ignore side-channel attacks and and Trust Hardware completely, then they're actually much more powerful than anything we can build in cryptography today. So I refer to them as virtual black boxes. So virtual black box, obfuscation in software has been shown to be impossible.

A

There's a famous results from Boas Barak around 2002 showed this yeah.

D

Because there is no masking is like, at least if use a library of software library, you can look into it if it's open source you're using you write compiling for hearted, so that it's a lot harder right. So you really have to rely on the constructor. Normally, it's fine, but you it's very hard to do any sort of audit ability if you ever wanted without going absolutely.

A

No you're correct, you do have to trust the chip manufacturer and you know, like the Intel guys here, will give you a lot of good reasons why you should trust them, but.

D

It runs on that yeah.

A

But you know it's: it's certainly a viable choice to make to say: hey, there's some things for which we don't want to trust the chip manufacturer. You know if you're moving some ungodly amounts of money. You know. Well, maybe someone can use all of the physical hardware. Crypt analysis tools. You know shine. Lasers induced the faults, all that stuff and break the chip that's expensive, but if the incentive is enough, then people will probably do it.

C

Sorry, this mic cheap compared with.

A

Which smart ship are you referring to like.

C

The one that Gulino created to.

A

Go in Oh in credit cards, so SGX is, is universal, so SGX you can do basically any computation you want inside. There are some memory limitations and it's a bit tricky to handle those. But SGX is a universal cpu.

B

This might be an offline question, but when you have a lot of different parties, so say banks that need to participate with each other, but only on yeah. You don't want them to be able to see all of the transactions. We were planning to use fabric channels, but as the number of parties increases, you created another problem so from a scalability and potential long-term architectural effects, you can't have a thousand banks on it on a single channel because the thousand squared. So how is there?

B

Is there any sort of generalizable recommendations that you might be able to put forward forward as a best practice? Yes,.

A

So I'd recommend opening and closing channels right. So so there isn't currently a really good mechanism in fabric where you can close a channel and dump sort of the output to the main state right. So this is what I mentioned in some of the slides right. So if we go back right, so channel opens channel closes right.

A

So if you can sort of close channels in dump state, then you can avoid this sort of crazy proliferation because well, if you don't need a channel anymore, you dump the state to the to the main blockchain, no one figures out, except the parties in the channel. What's going what sort of happened in the channel and you can derive pretty good security properties? That way, and in my experience it's actually much worse than what you described instead of a thousand squared, you know well what?

A

If you have channels that that what, if you have transactions that need multiple parties right, if all of your transactions need? You know five parties, then you're talking a thousand to the five channels. So so, yes, I think that you need some kind of way to gracefully closed channels.

A

Graybow ah yeah.

B

I mean in fabric, there are also other privacy protection technologies, including the side database and also the IT mix the new in the latest release. Maybe you can have a look at there's a suggestion.

A

Any other questions hi.

C

This is my shirt. I have a question on the the private transaction data, the newer versions of the fabric have that feature and before that we've been hearing about channels. So could you talk a little bit more about the newer those private transactions data and we have also been getting the feeling that the channels probably might get phased out if I'm not mistaken, so was interested in hearing your thoughts on that so.

A

I'm not probably as familiar with some of these fabric specific technologies as I should be so I can direct you to some of the fabric. Maintainer is involved in this. Who can probably answer your precise questions.

B

Hey I'm, so continuing on the transaction privacy thing. Have you seen any developments in I? Guess any of the the hyper ledger chains for incorporating things like like bring signatures with Manero that obfuscate, the different parties that are interacting in a transaction, because that would kind of generalize the problem. So, instead of having to go into a channel in order to have private transactions, it's just kind of the default for the blockchain itself that no one would be able to interact with one another. Yeah.

A

So that's basically what the goal of Z mix is to do is to provide tools for things like that. So that's going to be a part of ursa the problem with the approach of doing it. This way is that it still reveals the transaction patterns, so so, depending on the security model you need. You know, you might decide. That's okay, that you know it's! Okay! If people see that internal transaction details there's some applications where that's almost totally up so, for instance, a lot of indie, there aren't complicated transactions.

A

There are very simple transactions, so if we reveal some of the underlying transaction details, not a big deal for other things, it's not so good and when you, when those things, aren't good, that's when you need channels or something like that, so I think we're out of time, I'm happy to answer more questions I'll be outside. If you have any more but I think we should probably turn the room over to the next speaker. So thanks a lot for your time.