Coinbase Security Series: Open Source MPC Key Management

Hey everybody, thanks for joining us today. My name is Eli. I'm on the blockchain security team at Coinbase and I'm here with Arash from our applied cryptography team. Today's session is about CBNBC, the MPC library that Coinbase recently open sourced. As always, please observe the disclaimer at the bottom of the screen.

And Arash, if you're ready, please take it away.

Awesome. Thanks, Eli, for the introduction. Let me share my screen and start. All right. Right.

So, yes, thanks uh uh my Arash. I am uh part of the applied cryptography team and Coinbase and I'm presenting CBMPC which is our open-source MPC key management library. And this presentation is uh goes in more is it essentially continuation of what uh Eli presented a couple of sessions ago uh about best practices of key management. uh I'm going to go into more details into MPC by first introducing what MPC is, how can it be used for key management, then I will uh demo uh how the our CBNPC library can be used to uh key management. So generate a key, perform a threshold signatures and so on and so forth.

And then I will end by going over CBMPC's uh features and uh properties and what it offers in general. And of course I'll end with uh uh leave some room to uh answer any questions that you might have. All right. So let's start with MPC. Secure multi-party computation or MPC is a sub field of cryptography.

It is very well researched. uh it started in 1980s and thousands of papers have been uh published in this field. Uh it was purely theoretical up until a decade ago but in the past decade it has become extremely practical to the point that we have uh deployed it uh in larger scale inside Coinbase to secure uh customers funds. The idea of MPC in in a very short sense is to perform computation on private data. So you are probably familiar that we can protect private data at rest by encrypting it and putting it in a database, right?

We can protect the data in transit by using HTTPS or again some sort of encryption and sending it over the wire. But how do we protect the data when we are doing computation on it? So that's that's the part that MPC is focusing on. And the M in the MPC it stands for multiple parties. And throughout this presentation I will use parties or machines interchangeably.

Uh in the MPC world we have multiple parties. Each of them have a private input and they jointly want to perform a computation or a function on their data. Okay. uh and they care about two important properties. The first one is privacy, meaning that none of these participants want anything about their private inputs to be leaked other than whatever is the output of the computation and they of course want to get the correct output.

So for example, let's assume that the parties have uh some number and they want to compute the average of those numbers. So they don't want to leak their own number. So that's the privacy part. But at the end they want to get the proper uh average. So that's the correctness part.

The the important thing about this MPC is that the protocol still maintains these properties even when we have malicious adversaries. You can think of militia's adversaries as attackers or adversaries who are compromising a machine and are on the machine and actively doing something bad. So it's not just stealing some data and uh going away. They are on the machine they are changing the code of the machine. They are running a different program.

They're doing whatever they want. So that in that sense they are malicious. They are not just static uh or semiann sitting there. So they are actively doing something bad and in the MBC world we prove mathematically that our protocols are secure even when we have such malicious adversaries. All right.

So that was a little bit of uh abstract highle definition. Let's make it a bit more concrete by talking about a toy example. But let's say we have a couple of cryptographers. they each have uh some salary and they want to find uh the average of their salaries so that they can understand whether they are being underpaid or not. Okay.

Uh of course each of their salaries is private. They don't want to leak or uh anything about their salaries, right? So that that's why we want to have this uh protocol. They they don't trust each other. Of course, their they their salary is their private information and they don't trust anyone else.

So they need to do some sort of computation do run a protocol among themselves to be able to achieve this. So let's see how we can uh do this uh with a simple toy example. Alice uh is earning 120k right she is going to choose a large random number something way way over than what the typical salary uh in her field is going to be. So, for example, uh uh 652, and 195, right? And then she's going to add that to her salary, uh and send the result to Bob.

So, notice that when Bob receives this uh value 172, 195, I'm going to drop the 195 for the sake of uh the simplicity. 772K. Bob cannot tell what is Alice's salary, right? Because Alisa's salary could have been 100K and the random number was 672K, right? Or Alice's salary could have been just $1 and the random number was 771.

So just by looking at this number, Bob learns nothing about Alisa's salary. Okay. So Bob is going to do the same. He's going to add now his salary to this number and send the result to give. So the result is going to be 877K.

Uh by the same logic, Eve doesn't learn anything about Bob's salary nor Alice's salary. If which is being underpaid, uh is going to add her salary to the sum and send uh 942 uh K to Alice. And Alice at this point can subtract the original large random value get the total sum divide by three get the average and then announce the average to everyone. So this was a very simple protocol to show that with uh we can achieve MPC we can achieve computation over secret data without revealing anything about our private data. Okay.

So this was just about salaries and averages and whatnot. You might be wondering how does this relate to key management. So in the context of key management, we have a private signing key which is uh shown as SK uh short for signing key and our parties are going to have portions or shares of this signing key. So each party is going to have a private share of the signing key and uh the function that we want to perform or the computation that we want to perform is going to be the ECDSA signature. So we want to sign on a message using ECDSA given uh that the the private key is that SK.

So the privacy property is that we don't want the full signing K to be revealed to anyone. Okay. And the correctness property means that if everyone agrees on the message that they want to sign at the end they should get the signature on that message. So uh if we have these two properties and a protocol that can achieve that uh we get a very important security advantage and that is that we have removed the single point of failure because in without NPC the signing key will be in one place and attacker can go and compromise that single place and steal the key. with NPC we have a distributed manner and an attacker needs to compromise many different parties and that is the one of the important pieces of uh uh advantages that NPC has.

So I'm going to go over this again but this time slowly slowly and uh gradually just just to make sure that we all understand what is the role of the NPC and what do we get out of it. So in let's assume that you have a normal wallet you would go and generate a signing key using that wallet. So that uh and then you generate an ECDSA signature using that signing key. Okay. As I said, the problem here is that that signing key is sitting in the memory of a single machine.

And if the attacker can compromise that machine, then we are in in bad situation. And compromise can sometimes mean stealing the key. Compromise can sometimes mean just hacking the system and changing the destination and address. So you are you think that you are signing on a uh transaction sending for example one ETH to uh the address that you know and trust but in reality you are sending hundreds of e to another address. So the comp I just want to make sure that by compromise it could mean many different thing.

It's not just stealing the signing key. So because we have this single point of failure now we want to distribute it and make it harder for the attacker. So we are going to split that sign in key and give different machines different portions of this uh signing key or or in more cryptographically speaking we want to give shares of secret shares of the signing key to different machines and these machines if we are careful these machines will be different environment. For example, machine one could be an AWS server. Machine two could be a Google cloud.

Machine three could be a laptop, for example, a wallet extension. And machine four could be a mobile. So, different environments, uh, different location in the hands of different people, which makes it very hard for the attacker to compromise them all. It's very hard for the attacker to go and uh compromise all of them and steal all of them. it is going to be very hard for the attacker to trick all of these four different machines into signing something else.

Okay, so that's that's the main setting point. Now to get to this uh uh position, we need to use various MPC pro uh protocols. In particular, we need a distributed key generation or for short DKG. I'm not going to describe the details of DKG here but assume that there is a protocol that when you run it each of these parties will get their proper shares in a secure manner. Now the question is once you have it what happens next?

You have these shares you want to generate an ECDSA signature. The naive and insecure approach is for everyone to send their uh shares into a single machine. that single machine combines all these secret shares together and then generate a signature. It's insecure because we have gone against the rule that the all the secrets should not be in one place. Okay.

So, so this is not good. What we do want to have is to have some sort of protocol very similar to in concept to that uh average uh uh uh protocol toy example that we have in the beginning that these machines talk with each other send messages to each other. Maybe they they use some sort of encryption and work with each other to generate the signature. Okay, this protocol, this way of these people communicating with each other is going to be a MPC protocol for signing. In this particular example here, in this demonstration here, this is going to be a threshold signing.

Now, by threshold, it means that although we have four different parties and four different shares, we only need three of them to participate. So it is a it's a three out of four threshold signing protocol. All right. And CBMPC the open source library uh that uh Coinbase has provided gives you the tools and APIs that uh you can use to achieve this. So you don't necessarily need to know all the cryptography that's happening under the hood.

You just make a couple of API calls on each of these machines. they talk to each other and they run the MPC protocol for you. So and I and that's what I will demo uh shortly uh in this presentation. But before going to the demo, I want to talk I want to compare MPC with a couple of different concepts. The first thing is Shamir secret sharing.

Shamir secret sharing is a very good protocol or or algorithm that is used as part of an MPC protocol but on its own it is not an MPC protocol and it's not secure for our needs why because in Shamir secret sharing you would go to a in a single machine generates a signing key okay then secret shares it splits it into many parts and give it to give each share to machine and then at the end put all those shares back together again in a single machine so that it can generate an ECDSA. So by now you should be familiar that having full secret in one machine is a no no when it comes to MPC. So Shamir secret sharing on its own is not a fully secure MPC protocol but it is quite useful as part of a full pro. The next thing that I want to uh compare and contrast is MPC with multistake. Okay.

And they they both have their pros and cons and they are useful for different situations and in fact it's best if you use them uh together if you want maximum security. So in the MPC world as we discussed there are a couple of machines they talk with each other. They for example open a TLS channel, MTLS channel and they directly talk with each other, send messages to each other and then at the end a single signature comes out and that signature that signed the transaction can be submitted to a blockchain. In this way we are chain agnostic. We can generate the signature for any chain we want.

All that logic is offchain and then we end up submitting a single uh transaction. uh and we can implement all these concepts of threshold signing who who is going to participate who is not going to participate all that logic will leave offchain in the multisc that logic should should be implemented somewhere and that somewhere is going to be in a smart contract in blockchain and those machines are not going to be talking with each other directly anymore they're going to uh talk without a smart contract so they need to uh submit transactions uh in each of them individually need to submit transaction to that blockchain. So we are fully on chain and all that logic uh is going to be tied to a uh to a specific blockchain and if you want to work with multiple blockchains you need to create multiple smart contracts and each of your machines need to have the logic to work with multiple blockchains. All right. Of course, this means that when you are in the MC world, you pay less gas.

You just to do one transaction. In multisc you pay more gas because it's multiple transaction and the logic that complicated logic of handling these threshold concepts all lives inside a smart contract. The other difference is the public accountability. So in multisc is you have public accountability. It's clear who did what when and if something goes wrong, you know who was responsible.

In the MTC world, there is no public accountability. Everything is offchain. But this is not necessarily a bad thing. So in some situation, you may want to hide the uh uh privacy uh hide your signers. You don't want anyone to do any onchain analysis and figure out who your signers are.

Okay? So to safeguard their privacy, you may choose to do MPC and have your signers leave offchain. Okay. So it's again it's not saying that one is better than the other in all cases. Each of them have their own use cases based on what your requirements are.

In a PC your uh you should be synchronous. So everyone should be online. All those three parties should be online. they should be talking with each uh directly with each other to uh end up running the protocol. In multisync you can do it asynchronously.

Machine one and two and three could submit uh their transaction uh over many days and weeks. And finally uh with MPC you need complex cryptography uh to properly and securely run this protocol. And in multisc it's simple. You maybe for example uh some any standard uh signing uh scheme will uh that that would normally work with the blockchain will work here. All right.

So with that being said, let's uh go over and a demo. My whole screen this time. Uh you can find the steps of this demo uh in our uh repository by going to the repository demos go cmd threshold cd ecdsa web and readmi. This this has all the instruction on how you can run it. Uh I'm not going to go over all of that right now.

Uh instead I just show you the uh result. So these four browser tabs you can think of them as one machine. So they are essentially different processes running on different ports. And now we want with you a DKG a distributed key generation protocol an MPC way of generating uh protocols. Okay.

Now as I said before in the MPC parties need to talk directly with each other. They need a MTLS connection. So in this demo uh when you click on connect these parties are going to talk with each other establish the connection. Now that we have a connection, we need to uh configure the protocol. Do we want in in the signing phase, do we want three parties participate, two parties to participate?

How do we want uh the signing to work? So let's choose three. They run a protocol among each other. They are DKG protocol amongst each other. They all get the same public key.

So that's essentially going to be a representation of the uh address, the blockchain address essentially. And then each of them is going to get its own secret share of the signing key. So those SK1, SK2, SK3, SK4, these are essentially those values and these are private values to each of those parties and no one else uh knows about. Now that we have these, we can go to the signing session. In the signing, because we said it is a threshold of three, we need to choose which three parties to participate.

and we need to choose what message to sign on. Okay, so let's choose part the first three parties and then run a signature run a signature uh generation protocol. So this whole thing runs and it outputs a signature and you can imagine that if you put a blockchain transaction here then you get a signed transaction as the output and then you can go and submit this signed transaction uh to the blockchain. All right. So, so yeah, this is this is essentially a demo to show you how this all would look like uh in in practice and uh let's see if I go back to slideshow.

Can you see it? Okay, great. Okay, so this was a backup. Fortunately, things worked out. I don't need that.

Okay, so now here I want to show you how that signing code looks like. The goal here is to show how easy it is to run this implement and run this protocol without really knowing what is happening under the hood. Okay. So the threshold signing protocol starts by creating a job object. Job is our uh abstraction over the networking layer.

Okay. So essentially define who is who, what's the certificates and things of that nature. So we have this job object. Now that we have the job object, we do some sanity checks and then hash the message. Hash the message because ECDSA signature requires the input to be hashed.

Now we do this thing, these two additive share and this is because we had four parties. Each of them had their own uh sign in keys but we chose three of them to participate. So we need to do some data uh conversion uh and convert those uh shares into proper signing share. So again that's another API call that you do and get the proper share and then just a simple call just a single call to do an ECDSA sign and then this runs the whole thing and outputs the signature to you. Uh the rest of that is just conversion data type conversion to the produce uh signature format.

So you don't necessarily need to understand uh in this uh quick uh 30 second of description what is going on. The the takeaway that I want you to have is that using CBMPC to implement an MPC protocol a cube and MPC key management protocol is very simple. Just a couple of API calls and you're good to go. All right. So by this point hopefully you have come to appreciate that MPC is a very good fit for key management.

Uh and CBMPC gives you all the tools you need to do the typical key management operations. So generate the keys sign decrypt uh generate verifiable encryption and many many more features that I'm not going to uh go into details uh at this point. The uh uh the library is production grade has production grade security. It's heavily tested, documented and audited. The core of the library is implemented in C++ but we have comprehensive core wrappers.

In fact, what you just saw in the demo was all written in Go. The library is based on our production uh code but it's not an exact uh replica because of course our production code has uh some part of the code that is suitable for our products. So so we had to separate things so it's not an exact replica but uh very uh uh close the library is highly efficient. Uh if you want you can go to our benchmark page and for each of our protocols you can see the timings uh that it takes to do various operations. Um now we and we not only have open sourced the code we have open sourced all the research that we have done to get to the code.

So all the theoretical justification papers that we have done the research on all the uh detailed specifications and if you're interested you can go to the rhythmi file uh pick your favorite uh protocol and then you can read the theory read the specification read the code and make sure that all of these uh match with each other. If you're not interested you can simply just make an API Kai call and uh have a running application. Now we decided to open source this library because we believe that uh MPC is a great fit for key management as we have uh talked a lot throughout this uh presentation. It uh create it provides a higher level of security. It rem it removes the single point of uh failure, makes it very hard uh to uh steal the signing key and and also makes it very hard to trick the different signing parties into signing something that they uh they were not meant to do.

And uh now although we recognize that MPC is great fit for crypto key management, we also recognize that the MPC cryptographic expertise that's needed to implement a proper uh uh MPC protocol is very hard to come by and most of the open source libraries out there don't meet the bar uh of the production standard and if uh any organization or company out there uses something uh uh not great and ended up being breached, this breach is going to be bad for the whole field and by extension is going to be bad for Coinbase. So our hope is that by uh open sourcing this library we raise the security posture of the whole field and of course we gain trust uh more trust from our customers uh after they see our code the level of rigor and research that we have put uh into this and this this transparency is something that we strive for. We also hope to become more secure uh when when uh you all look at the code and if you find any uh security problem let us know and submit it through our budy program and uh yeah finally you can find the code under uh coinbase/zbnpc and github it is MIT license so there is no limit on uh how you want to use it and with that I'll end the presentation thank Thank you. If you have any question, happy to answer.

Great. Yeah, thanks for the presentation Arash. We'll move out of some questions now. And for folks that are watching live, feel free to, you know, drop a question as a reply to the broadcast and we'll pick it up and make sure it gets to Arash. But we'll start with a few questions that I had.

Um, first one being, can you give us a sense for how much effort went into developing the library?

Yeah, of course. Uh so this was a team of five or six people uh working over four yeah almost four years uh to lay the foundations and then uh making sure that it works internally and then extracting it out into uh an open source library. So it it was a lot of effort to get to this point.

Cool. Um and yeah just one I think if you stop sharing your screen too it'll help transition easier towards the end but um

all right so second question is how should outside contributors responsibly disclose flaws?

Yeah so there are two main ways of disclosing or submitting the flaws any potential flaws that you find one is through the hacker one bug bounty program. So in that in that sense you find a program and all of that is uh described in the security markdown file in the repository. So through the bug bounty program you will be eligible for a bug bounty. You submit it we work together and figure uh figure out validate the problem and then fix it. But some researchers out there may not necessarily be interested in the bounty.

They are more interested in publishing the result. In that case, you can send us an email directly. You wouldn't be eligible for bug one. But again, we work together, figure out the timeline and then you can uh release the result as your research.

Fantastic. Um, all right, next question. Uh, are there plans to extend the library and add more features?

Yes, absolutely. So, we we are constantly working on improving this. Uh, sometimes it is implementing new protocol. So a new signing protocol uh or a new key generation protocol sometimes it's just making the existing functionalities easier and more broad for example something that we are going to release very soon is that we want to give you the ability so that when you use our go wrappers you can connect it to for example any cloud KMS provider or UB key or whatever you choose. So the these are the enhancement and features that we will release over time as we uh work on them internally and make sure that they go through audits first and then release them.

Nice. Okay, cool. Last question. When should builders pick two party versus TN threshold? Are there any important differences in the implementation to call out?

Right. So uh the the main thing is whether it's T ofn or any I'm going to use a new term access structure which is going to describe how you want to control your access. So for example you can you might say that within your organization for any high value transaction you want the CEO to approve and you want the CFO to approve and either I don't know CTO whatever I've run out of sea level suits uh so and and uh other people so in this structure you have one party and another party and maybe two out of three other parties. So you can come up with very complex uh access structure based on your organization's need or maybe you are just simply looking for redundancy. Maybe it's 10 of you and you are in different time zones or whatever and you just at any given time maybe three of you are online or four of you are online.

Okay? Or maybe it's just it's just you and your customer. It's just two party. You're providing a service to you and your customer. It's just the two of you.

you're always going to be online and in which case you use the so it's all depends on the use case and what you want to get out it all right cool well thanks for your time Raj thanks for everybody watching please join us next time we'll discuss how to identify risk through penetration testing thanks for having