 All right. So my name is Marcus. I'm with IBM Research and today my colleague Bono Vavallafon Interleps will join us through this computer and present as well. And today we will talk about Fabric Private Chain Code. So someone in the room who has heard about that project before, raise your hands. Oh, wow. Okay. Have you also used it? Oh, yeah. Okay. Cool. All right. Let's start easy. Okay. So why do we want something like Fabric Private Chain Code? So there are many use cases where the blockchain actually makes sense in order to trace data on the blockchain. Everyone can see the data and verify that certain things are going on correctly. However, some use cases come with very privacy-sensitive requirements. And there are a bunch of examples like sealed auctions, voting, healthcare supply chain. And all these use cases, they have some portion of privacy requirement in it. So for a sealed auction, we understand that if we submit a bid, it should be private until we evaluate the auction and release the winner. For a voting mechanism, we should actually never reveal the individual bids. For healthcare data, well, I don't want my patient's data stored on the blockchain. Not good. And for supply chain use cases, so we can think that, I mean, people are making contracts, making good deals for buying certain gifts. Storing that on the blockchain might be nice for traceability, but sometimes we don't want to reveal the good price we got to our competitors. Luckily, Hyperledger Fabric already comes with a few of built-in mechanisms to solve those use cases or to solve those issues. For instance, we have channels where we can basically establish multiple blockchains on our network in order to split the participants that only the participants can see the data, what they should see on the transactions. Then we have private data collections where we only exchange the data among the people who need to know the data and submit essentially a hash or commitment of that data on the blockchain. And then we have private or transient fields, which allows us to put data in a transaction which do not show up in the end of the day on the ledger. However, all these mechanisms are making a good contribution towards privacy-sensitive use cases. We still have a problem. And the problem is that all the data is still visible to the endorsing peers. What do I mean with that? So I mean, endorsing peer which executes our functionality or smart contract needs certain data, most probably the sensitive data, in order to process this chain code. So let's think about that. In a voting example where the government then runs an endorsing peer, well, maybe that's not a good idea that the government then when they execute the smart contract can basically encrypt or basically see our data and clear and process it. That's not nice. In order to understand that a little bit better, I have a single slide which represents hyperledger fabric where we can see we have the clients, we have the peers in the middle and the ordering service. And the peers, as I already said, they are responsible to execute the chain code, maintain the word state and the ledger. So if you're saying, okay, for my use case, I'm actually fine that a certain organization can process that data, that's fine for me. However, think about deployment use cases where your fabric peer is deployed somewhere in the cloud where you don't have control over your data. So you do not know if the Adlin maybe is malicious. What should you do then? So in order to overcome this as those issues, we have introduced fabric private chain code, which is the framework to build, deploy and run private chain codes on top of hyperledger fabric, which is exactly built in order to tackle those use cases where privacy is an issue. And we solve or we tackle that problem by leveraging trusted execution technology or confidential computing code nowadays, like InterSGX. Who of you have heard about InterSGX? Very good. All right. And so by leveraging this technology for our smart contract, we get essentially three nice properties. So the first one is confidential compute, where all the transactions and the ledger only contain encrypted data. And only the smart contract or chain code running inside the trusted execution environment will get access to our data in clear. That means that the endorsing peer does not see the data in clear, only encrypted data. The second property is verifiable operations. So with fabric private chain code and the use of trusted execution, all the transactions, they are actually verified through a mechanism called attestation that allows us as a user to verify that our smart contract is protected in such a trusted execution environment. And this we can basically then transitively show for each transaction and say, okay, this transaction has been executed by a trusted execution environment. Here's the attestation that it's using InterSGX, things like that. And this also brings us to the last property, which is data misuse prevention, because we now bind our data through encryption to our actual chain codes. We can get a measure in order to control who's allowed to access our data. And now I will give the word to Bruno. Let's see. Hi, everyone. FPC announces confidentiality for fabric chain codes by using harder based security mechanisms to isolate the chain code from the rest of the platform. Our current implementation uses Intel SGX to create an enclave, which is a protected environment where the sensitive chain code runs. The hardware enforces the isolation of the enclave, which means that outside components such as other hardware, the advertiser, the operating system and any other application cannot tamper with it nor read any sensitive data. These are laws to preserve integrity and confidentiality at fabric gears. Finally, a hardware-based attestation allows to distinguish an FPC chain code from a regular fabric chain code. These are laws to establish trust in an FPC chain code running remotely before communicating any sensitive data to it. Here is an overview of FPC, and now it integrates with fabric without modifying fabric itself. So you can use FPC in your existing deployments. As in fabric, so in FPC, orgs have to install and approve the chain code that they want to execute. In FPC, additionally, the chain code definition includes the MRA enclave, roughly corresponding to the hash of the chain code attested to by the hardware for integrity purposes. At initialization time, the chain code enclave generates and attests some cryptographic keys, which are crucial for the authenticated encryption of client communications and data storage on the ledger. The orgs can then look up an enclave's keys using the enclave registry, and this is a regular fabric chain code which collects, verifies and shares such information on the ledger. At this point, the FPC chain code is ready to execute transactions by receiving encrypted invocations from clients and delivering encrypted responses to clients. All of the lookup, cryptographic and storage operations are handled transparently by the FPC client SDK at the client side, and by the FPC shim at the chain code side. Both components expose interfaces similar to the fabric client SDK and to the fabric shim. Now, back to Marcus. Thank you Bruno. Isn't that real? Yes, please. So say that again. So right now, fabric private chain code does not integrate private data collections, but we would like to work on that. Well, that depends, I guess, on the configuration of the private data collections. But if chain code needs that data in order to make a decision to run your logic, then that endorsing peer, assuming it has the rights to basically consume the data from the private data collection, basically needs that data. Yes, that's correct. I mean, so the contrast with using confidential computing is here that we're basically idolating the execution of the chain code from the endorsing peer. So the endorsing peer does not see the content. So when the admin of that machine does a memory dump, he will not see the data in clear text. Yes, exactly. So can I suggest that we do that discussion maybe after the talk? I mean, super interesting that let's definitely have that discussion. Any other question quickly related to your understanding of FPC? We did a very fast one on one here. Okay. So let's see. I mean, how can we use this stuff now? I mean, the easiest thing you can do, I mean, get out your laptop and type this command in the console, and then you get everything you need to getting started with Fabric Private Chain Code. So in our repository, we have an SDK to build Fabric Private Chain Code in two languages right now, C++ and GO, which I talk more about in a second. We also have an FPC client SDK, which is very similar as Bruno already mentioned, to the traditional Fabric client SDK for GO. But it basically helps you with all the, let's say, nasty parts of the security, in particular the encryption or data protection when you're communicating to your chain code. We also integrated recently the Fabric smart client. So from your Fabric smart client application, you can also call Fabric Private Chain Codes. And you will find many more examples how to take your FPC chain code, deploy it on a Fabric test network, for instance. We also provide a docker-rise development environment, which comes with all the tools you need in order to get started without installing a lot of stuff on your machine. Let's quickly talk about, I mean, how to write FPC chain code. So as I said, there is C++ chain code. The reason why we introduced C++ chain code is when Intel released their Intel SGX technology, they only provided an SDK, which allowed you to program your code in C++. So we had to go that direction when we started that. As a usual chain code, you basically start writing your invoke method, and then you can do all the things like, I mean, getting the parameters from the transaction inputs, you can get the state and put state operations. The nice thing from the user perspective is that our FPC shim basically provides you all the features to protect your data. So this is very similar to traditional chain code where you just write your data in clear. However, our FPC shim takes care of encrypting and decrypting those data before it's going on the ledger. But moreover, the shim provides mechanisms in order to produce a signature on our transaction saying, hey, this transaction was really executed inside the trusted execution environment using the remote attestation capability of Intel SGX. So now you may think, hey, Marcus, are you serious? Do you really want me to implement my chain code now in C++? Nah. And this is why we have FPC plus Ego, which is a Go compiler to compile your Go application to run it inside Intel SGX, which leads us or which gives us now the possibility to take your Go chain code and run it inside, run it with FPC. So this is maybe now more familiar to you. So we can now write a normal Go chain code, also use the functions which are provided by the shim or by the stub. We can run put state, get state, things like that. And very similar to the C++ version, all the complexity is hidden behind our framework implementation. And what I really find pretty cool in that project, that this was a collaboration with the University of Bern with the crypto group. And there, a student, Ricardo Zappoli spent quite a lot of time to hack this together and had to build our preview. In order to integrate now FPC, there are actually very minimal changes you need to do on your application. So you just import the FPC library and wrap your chain code as a new private chain code and compile it with the tools we are providing in our repository. So now the scary part, I will try to do a live table in order to show you that this is really real. So the idea is, hey, let's pick one of the samples which we have in the fabric samples repository. And I would suggest that we go with an asset transfer basic sample. There we go to the go chain code. If we go there to chain code again, you will see here the smart contract implementation of a chain code. And let's look at this for instance. So here we have a method or a function which is implemented to create an asset. The asset has an ID, a color, size, owner and a value. And that looks pretty straightforward. So the chain code checks if the asset exists, it will create an asset, marshal it to JSON and then performs a put state. So as a traditional chain code, you understand now that in the right set of that transaction, this object as a serialized JSON string will appear unclear. Our goal with FPC is that this is not unclear anymore. So how do we do that? So I created a little sample which is available in our FPC repository on the samples demo's Hyperledger global form. And here I basically only have a single main function which we need to modify now. Let's see if this works. So what we need to do is, so with Fabric Private Chain Code, we use the chain code as a service model to run our chain code. So what we're going to do is we go here to the main file of the asset transfer, take this asset chain code. I think we can ignore this error for a moment. And then we also need to import the logic. So now in order to make it an FPC chain code, we need to wrap it. So luckily, GoLand will help me figure on the right Go imports here. That's good. So next thing is we need to build this. We will use our tools building on top of the ego compiler. Since that might involve multiple commands in the command line tool, I provide here a little make file with a reference make file which you can use for your application. The only thing what we need to configure is here to give the chain code a name. FPC basic asset transfer. So and that should be it. Let's see if we can build it. That's cross fingers. FPC pass, sub, demo. We are here. Right. There's our make file. That's cross fingers. Doesn't work. Okay. So the thing is that it complains that there is no ego compiler on my machine installed, which is also reasonable. It's a Mac. It does not support into SGX. But as I promised before, we have a development environment for Docker. So I'm switching now into a Docker container which also runs on this machine, having all this stuff installed. Samples, demo. Right. Here's our stuff. So let's hit make. So now you can see it uses the ego compiler to build our chain code. And then it also packages for us a Docker image containing the binary plus the runtime things you need in order to run an SGX application essentially. So if we look here what we got now, we got now a binary, we got a public and private keeper which is used to sign actually the binary so that we can make sure that me as a developer that the correct chain code is actually executed. And more interestingly, we also got this little file here, which contains the MR enclave of our chain code. And the MR enclave is basically, as Bruno said, a hash of our of our chain code logic, which clearly identifies our logic. We will need that later. So let's. So now we have a Docker image. Let's see. Yes. So this is apparently the Docker image we just built. Cool. So next step would be let's run our chain code. However, when running the check, now we're actually entering the, let's say the madness of deploying or running chain code or running hyperledger fabric in order to make this easier as a developer. We would like to use the fabric smart client integration test suite, which allows us to spawn up easily a fabric network, install our FPC chain code or any other chain code with a few lines and just run and test it. So you don't need to deploy your actual an actual network. So for that, we have in our samples and deployment fabric smart client. There we have a project and this project here has a topology dot go. And in the topology, we can specify now our network. What you can see here is that we specify a fabric network with two organizations. We enable FPC and we install an FPC chain code with a given chain code name and a chain code image because I don't want to actually, I would like to reuse this project now. I don't change here the code. But in the other terminal, we saw that we basically have these export statements, which we can load for that example. So in order to do that, we source this little file and then we can just make a run, which hopefully does something now. Yes. So it's starting now a network. Now you can see, hey, orders are spawning, fabric peers are spawning. We can also see that we install chain codes here. Maybe you cannot see that. I mean, I saw that quite often, which is very nice for debugging, but maybe for presentation, not really ideal. Sorry for that. But so what we will also start is an Hyperledger Explorer instance in order to see then which chain code is running on our network. So it's still installing. It takes a little bit. Any questions so far? Yes. So the MR enclave is part of the attestation you get from an enclave. And the attestation essentially will say, hey, I'm an enclave. I'm running this particular code, which is corresponds to the MR enclave. And then this entire attestation thing, in case of the APID-based attestation is signed by Intel. So then you basically get that. You can verify that the statement is signed by Intel. You can check that this attestation contains the MR enclave you are happy with. Yes. So as Bruno said in his part, we put the MR enclave as part of the chain code definition. So in the normal fabric life cycle, we need to install the chain code, we need to create a chain code definition, let this approve, and by adding the MR enclave, all the participants on that channel or using that chain code, they agree on a certain MR enclave. And under the assumption, we have a reproducible build that actually works pretty well. All right. So now our network is up and running. Let's quickly see if Explorer is there. It's loading. All right. So we can see there are two nodes, two chain codes. When I go to the chain code panel here, I can see now that our FPC basic asset transfer chain code is installed and another one, which is our enclave registry chain code. And the enclave registry chain code is basically our entry point in the system in order to store the attestations in order to track or maintain a list of what are the enclaves installed on our channel and what are their public keys, what are their encryption keys I need to use in order to send a message in a way that the endorsing peer does not learn the contents of it. Yes. Not at the moment. So right now, when we install or when we register our enclave, we essentially also store the IP address of the endorsing peer, which runs that particular enclave. So therefore, the ERCC is right now used for us as a discovery. Okay. So we see now the FPC chain code is installed. And so in order to produce a transaction out, we will need to use the fabric private chain code SDK in order to let the invocations be encrypted, protected, things like that. In order to demonstrate that, I would like to use also in our samples under applications, a simple CLI, which is essentially, I mean, a little CLI too, which allows me to invoke transactions on the inside. It uses the fabric private chain code client SDK to encrypt the data. So let's quickly build this. I think I also need to source again in order to, in order to configure now the client very similar to all the configurations you do normally for the peer command, you need to provide, I mean, the endpoint of the peer you would like to connect to things like that. Let's do that quickly. And our test network also provides us now a little script to get all these writing and talking is sometimes incompatible. So we would like to now configure our client as org one. So this is the stuff we need to specify. And now we can use this client to invoke a chain code. The function we would like to invoke, let's quickly double check again what was the actual command in the code. So we need to provide an ID, color, size, owner. Okay, so ID, it makes this thing blue. We make it size 10. Who wants to own it here? Hard. Perfect. And let's give it a good value. All right. So now you can see that something is not working. Uh-huh. So I forgot something. I forgot the function name. And I think this was create asset, create asset. Let's try again. Cool, worked. So here in the terminal you can, since I've enabled debugging that you can actually see that something is going on. You can see quite a lot that the enclaves are now doing something, I mean, running the chain code, endorsing the transactions, things like that. If we now look at the explorer, we should see in our latest transaction, which is this one. Can you read this? How does this work? So let's quickly open the right set. I'm trying to make it as big as I can. No, that's worse. Okay. So what we can see in the right set is that we see the key 101. This is the ID we specified in our command. And at the value, we don't see so much. I mean, we see something. However, if we would run this as a traditional chain code, we would see here the JSON string of our asset as produced here. So maybe for you an exercise at home is install the normal, this chain code as a traditional chain code, run this open and hyperlink explorer. And then you will see that the traditional one will appear in clear text, but with FPC not. Okay. So this is the data we see now on the letter. Let's see if we can get back the data in clear. So now we do a query. I think it's called read asset. Yay, we got it back. All right. So this concludes my hands-on demo on FPC. And it worked. Yay. So if you think that's a nice thing and you would like to see more of it, there is another demo today by Koshy. He's also here in the room. He will also show FPC in action with a different, with a real use case, let's say, not with my little toy application here. And yeah, please go and enjoy his talk. And also check out our GitHub repository, join our community meetings, talk to me here at the Hyperledger Global Forum, and get in touch with us and use it if you find it useful. Thank you. Question. Well, so the rich, as you said, rich queries actually require you to, I mean, have some meaningful information inside of your keys in order to make a good query. So this is the reason that we write now by default do not encrypt the keys, only the values, in order to allow rich queries. However, we all have, we have all the code in place that you as a user, if you also would like to encrypt the keys as well, you can do that. But then you're sacrificing the usage of range queries. That's true. Yeah. So, I mean, as a researcher, I would say, yeah. So if your trust model says, okay, trust the trusted execution environment, then you're fine and don't care about side channels. But this is, reality looks different, right? So what you were saying, this is a real thing. I personally believe that Intel does a very good job in going to academia and, I mean, to the open source community, throwing the hardware and letting people, I mean, really fire on it in order to basically reveal such limitations of the technology. But on the other hand, they also provide fixes and improve that. So that's a good thing. And I mean, as any other technology we built in the security space, it's most probably never perfect. It always has to have something, but we definitely would need to integrate additional measurements in order to deal with it. So for instance, in Fabric Private Jenkins, you could say, okay, my enclave code is only or in attestation, my enclave is only valid, I don't know, for a week. After that, you do a key rotation, things like that. But those are really additional means you have to put on top on that. So yeah, you should not always rely on one single security measurement, right? Yeah. No, no, that's no. So the other thing, what we would like to look is to extend also FPC to different trusted execution technologies other than into SGX, which is not a trivial task. I mean, the Linux Foundation, they created this confidential computing consortium in order to bring all the manufacturers on the same table and see, okay, how compatible are our different technologies here. And if we could also use this for Fabric Private Jenkins, that would be ideal. So we could imagine that we build then a policy that a certain chain code runs in SGX and on AMD SEV or whatever. And if both agree, come to the same result when they execute, then this is considered to be even more trusted than just executed by Inter-SGX. Welcome. Any other questions? So I think right now we require at least Fabric to point three. Right now, our client SDK does not work with the gateway work we just have seen here. Because there, think about that with the gateway, we as a client, we sent our request to the gateway. The gateway then does all the magic with it and then needs to end up in the enclave. However, that would be something we could actually solve by just engineering work. So that still the client does the protection of the data sent to the gateway sink like that. Then as dependency, we have the ego compiler, which we need, or for the C++ chain code, the Inter-SGX SDK that you need to use. But other than that, okay, so I mean, as a requirement, you definitely need a machine which is capable, which has Inter-SGX available. In Koshy's talk, you will learn about how FPC can run on the Azure Cloud, for instance. Otherwise, you basically, you just need the hardware. But for just playing with it, I mean, I tried to demonstrate this on my Mac using our Docker-based development environment. So you mean, this is right now not implemented, that's true. So right now, we have basic functionality for a chain code. But for every other feature we need to think about, okay, if one chain code codes another one, that chain code might need to also verify that the other enclave is an enclave running the expected code, things like that. So this is not yet implemented. I think that's it, and we go for lunch.