Coinbase's cb-mpc Open-Source Library

Transcript

100 will attack direct. Okay. [Music] [Music] Okay. Can everyone hear me?

Yeah. Yes. Hello. Welcome. Welcome you. I'm Sil from the staff team. Uh welcome. You are connected with the audience. Um I will manage the time. Uh I will just uh have a quick interruption to say you are to say to tell you you will have five minutes left uh before the hand of this time if it's okay for you. Do you need to um um to uh reserve a Q&A session at the end? Uh I hope hopefully there should be time for Q&A. So we'll see. Okay. Okay.

Okay. So should I get started then? Yeah. Yeah. Yeah. Yeah. Thank you. Okay. So, thank you very much. Uh, unfortunately, I was uh my flight was cancelled very last minute and I couldn't get any other flight out of Israel given all airspace closing and then reopening. So, apologies and I'm personally bummed out uh and not being there. But, uh, thank you for the organizers for at least enabling enabling me to give the talk this way. So, I'm going to talk about Coinbase's CBNPC open source library. It's a recent uh release that we've made and uh um and this is uh in this presentation I'm going to uh uh talk about uh everything

in that library. Okay. So um sorry about that. Okay. So just a very very brief introduction to MPC although it's a it's a well-known technology already in this field but uh secure multi-party computation is a technology that enables multiple parties to jointly compute a function over their private inputs and it's uh really proven to be ideal for crypto key management. uh the private signing key is shared amongst parties and uh and you need all of them or a quorum of them to uh approve and participate in the signing protocol and that the function so-called that we're computing here is the signing function and the private inputs of the

shares of the key and uh this is also known as threshold signing it's a special case of NPC and the reason why it's so powerful is that it eliminates single points of failure or compromise and therefore or prevents uh key theft but just as or even more importantly prevents or mitigates against key misuse. One of the thing which is really important to understand is that in order to steal all of your money I don't need to actually steal your key rather all I need to do is uh generate a fraudulent transaction and just transfer all of your money to my address. So with MPC we're able to uh implement on multiple different machines things like policy validation for example via allow list

and other things fraud detection techniques techniques we can verify signed atestations that you act the customer actually wants this transaction uh to be issued and in that way we can prevent any uh attacker from getting to a single machine and carrying out a fored transaction something which uh isn't possible to do using other technologies at least not in the same way as with NPC. So it's relevant for custody, consumer wallets and so on and so forth. This is well known. The key features of uh the CBMPC library are uh of course support for signing. So it supports ECDSA and EDDDSA orn they're actually essentially equivalent just

over different curves and that includes key generation. So distributed DK distributed key generation or DKG act the actual signing uh more advanced features like secure publicly verifiable backup. This is a backup method that enables you to encrypt a private share under some backup key that sits uh the private key sits somewhere else and completely disconnected but you're able to actually verify that the um backup encryption is to the correct value. So, it's essentially a cipher text or encryption together with a zero knowledge proof that you've encrypted the correct value. And this is extremely important to ensure that the backup is safe and that you know that you're not going to lose your key. Uh I always uh

tell people that in my opinion there's only one thing worse than your money being stolen and it's that you actually lo lose your money yourself. So backup is extremely important. The library uh has protocols for two-party computation and for multi-party. Of course, in some cases, two-party is just a special case, but there are other cases where we have more optimized protocols for two-party ECD say signing, for example. It also supports uh thresholds for rich access structure. So, yes, you can define I want four out of four people to sign. I can of course also define a threshold that I want five out of eight people to participate to sign. But I can also uh say things like I want five out of eight people from this group and four out of seven people from this group. And that

can be very useful if for example one group is in one organization maybe the uh service provider and the other group is is at the customer and you sort of have like a joint custodies setting or it could be that I want them different groups with inside um with inside the service provider or or something to that effect. You're able to define uh um really whatever you want in that sense. And the security is that any any subset smaller than the quorum even just by one will not be able to learn anything or sign on anything that's not approved. The uh library comes with very very rich documentation including theory documentation and specification as well as benchmarks and tests and I'll talk about them a little

bit later on. And our approach is security and rigorable for performance. It doesn't mean that the uh library is not performant but it wasn't our high top priority. We chose protocols, we chose methods. We're very conservative in the way uh we work because in our experience a few mill shaving a few milliseconds off here is not that interesting. And again I'll talk more about that as well afterwards. And the library is a C++ library um with go wrappers so that if you prefer to write in go you can uh um you can do that. The very very low level is uh um mostly OpenSSL. Then our layer on top of that is the CBMPC library and um and then there again go rappers and if you want

something else you can of course write it and uh it's based on our actual Coinbase production library but I just want to stress it's not an exact replica because within Coinbase we have very certain flows for and very certain setup for the products that we're we're supporting and we wanted the library to be a general purpose library. So in order to uh do that, we actually had to extract and make some changes um but uh um hopefully not introducing any bugs along the way and uh um but the it's very much the production code but just with those changes as well. So we're talking about a library which is in production has been in production for a good amount of time and is uh protecting

a large amount of money inside Coinbase. So why open source? Why would Coinbase uh invest so much money in MPC and then open source it for the public? So there are a few reasons. The first is that we uh truly believe that better security is better for everyone. So MPC is well recognized to be a the right or very very good solution which is well aligned in what we need for key management in this field. But NPC expertise is very hard to come by. So we have a lot of Coinbase. Coinbase truly invested uh heavily in the uh in the field in the technology and there are other companies who also made investments but there aren't enough MPC experts out there to really enable every company who wants to

deploy NPC to do it uh at at at a level which is uh um worthy for protecting billions and billions of dollars and uh in our position in our mind any bridge to any organization is bad for the industry and since it's bad for the industry it's also bad for Coinbase. So, helping everybody be more secure and providing a production standard library that can truly be trusted is something that will be better for everyone and therefore something that's also better for us. Second reason is transparency for transparency for our customers.

We're using MPC for custody, for the exchange, for other use cases. And we want our customers to be able to look and get trust in uh what we're actually doing and understand that we're working at a very very high level of rigor and security. And finally, uh no software is perfect and no cryptographer is perfect or no cryptography team is perfect. And uh by having an open source library that can undergo external scrutiny if there are bugs if we do have uh uh flaws then they can be found reported bug bounties can be issued and we can improve our security. So we may uh if there are bugs then we'll be happy to be publicly shamed so that we'll improve security.

Hopefully we won't be publicly shamed but not because uh no one finds it but because really there aren't major bugs but again nothing is 100% perfect. So having that external scrutiny is again better for us and better for everybody who's going to use the library. What are the uh what's the structure of the library? We have three main categories. Crypto is like the low-level modular arithmetic, elliptic curve, paire and so on and so forth. Secret sharing. We have the zero knowledge category. We have a lot of zero knowledge proofs for elliptic curve statements for proofs on pier keys and ciphers range proofs and so on and so forth. And uh we have the protocol layer which will give things of course like signing itself. of ECDSA and ED saying Schnore two-party multi-arty but also DKG distributed key generation

HD derivations we have MPC friendly HD derivation which is indistinguishable from BIP 32 derivation but it's not exactly the same I mentioned publicly verified encryption there al also things like oblivious transfer so if you want to use our library to implement a different ECDSA signing protocol for example that we haven't implemented then uh starting from uh using our uh lower level or or you not just the highest level signing will also shorten the time that you need and and we'll give you a very strong and good basis to start with. So it's also a possibility. We will also ourselves be adding protocols.

Uh we have a road map that we're we're planning on adding significant things as well. Uh but as it is already now you can sign uh you can back up you can generate keys you can do HD derivation. This this is really what you need to do key management in the space. I mentioned the theoretical rigor. We have theoretical justifications and proofs for all of our primitives. So, uh sometimes we just refer to a paper. Uh sometimes refer to a paper and say there are small changes here and there that we did. Sometimes the paper either didn't have a full proof or we didn't we didn't find it to be rigorous enough and we rewrote the proof entirely. But everything has a full justification. For example, the zero knowledge uh document I think is like 60 or 70 pages of full

proofs of everything uh that we're using. Very very detailed proofs uh been uh externally uh audited as well. Uh we have our cryptography team in Coinbase. We have another uh team within Coinbase that audits us and then and we've done external audits as well. There also exact specifications to bridge a theoretical papers and implementation. If you try to implement a paper directly, you'll find that there's a very big gap between that and code uh often checks very important checks are missing or it says use oblivious transfer and it's like which oblivious transfer should I use? What can I trust?

What protocols are out there that haven't been broken sometimes there are broken papers or papers where they it's known the proof doesn't go through and uh but it's not written anywhere. So therefore having everything here and having those specifications so you're able to follow exactly what's happening is crucial. uh in the library you can see on the in the repository you'll see this table for each of these primitives you have the specification the theory and the point to the code so you can really trace and get uh uh trust in what we're doing uh or find any flaws hopefully not um but really all the way from the theoretical beginnings and foundations to a clear specification which very exactly describes how to how toment that and then to the code itself

we also Additional documents. We have a design principles document which talks about our cryptographic philosophy, your full proofs, UC security which is the gold standard, our conservative approach to assumptions. We have a secure usage document if you are going to use the lower level not just the high level SEC CDSA but uh you want to use that as zero knowledge proofs commitments transfer there are things you need to know how do you handle session identifiers and things like that and that's described in that document and we also have a document which talks about how we deal with constant time uh our aim is to have everything constant time or to be a little bit more exact that the running time should not be dependent on private values and that's something which we uh have implemented throughout or attempted to in terms of benchmarks as I mentioned

we've chosen better security over better performance in our uh for most applications I won't say all because there are many many different use cases but in our experience a few extra millconds don't matter and that means that uh we're we've chosen conservative uh choices for protocols uh and assumptions uh but the library is still very performant and I'll give give you an example if you're looking at two party UCDSA so the Lindel paper which is widely used now. Uh the original paper talks about two and a half seconds for key generation and we do it in 291 milliseconds. Uh this is uh um this is primarily algorithmic improvements. So uh cryptographic research to have better

uh um zero knowledge proofs that are used during key generation. Signing is also half the time. So 18 milliseconds to sign there that's also improvements and also of course uh uh very uh well written code but it's it's code that we're not getting better better times because of compromising on security on the contrary everything is validated at every step along the way and we also have an enhanced signing uh for those familiar with it in that in that protocol uh if there's a certain error detected you have to abort everything and that sometimes that can work if you have a wallet who do sequential execution But in other use cases that's not something you want to do and and so we have uh we've added an enhanced signing where you don't have to do that global

abort and that takes 72 millcond. So there are full benchmarks for everything in the library and you can find that in the repository and here's an example of what it will look like for example in a lower level uh operations of elliptic curves you can see how much time it cost to add two cur two points to multiply a point by a scaler and so on and so forth. Here the numbers are in microsconds and you also have that for the higher level. So for example EDSA signing you can see here that for four parties it's around 49 milliseconds but you can also see in each round exactly how much time each party is working and also how much uh uh bandwidth is being used what is being what's the upload and the download and all of that information is very important for planning your

application and uh uh also for implementing other things using our primitives. uh having those benchmarks is something which is uh very useful at least we find it useful also for our internal usage. So I'll finish with a very brief demo. Uh here's an example of some uh uh um uh some go code which wraps uh ECDSA signing. So you can see there's a we start with a new job which is essentially setting up everything you need who the participants are communic communication channels between them and so on and so forth.

uh we want to check that there is a proper quorum that is uh going to be uh running uh as was defined. Yes. Uh two minutes left. Okay. So uh all right. I think that's um let me try and quickly you know what I'll just skip the demo then and skip to the conclusion. Um but there is a demo in the on the repository so you can go ahead and and take a look at it and compile it. Uh that's the GitHub uh address. It's MIT license so really unlimited use. We really want everybody you to use this.

This is not a library just to sort of take a look and say wow Coinbase is doing nice stuff. We want it to be available. We want people to use it. And there is a public bug bounty and security reporting. You can email us or use hacker one. So please uh take a look and contact us if you see anything. In in conclusion, CVNPC is a production ready robust open source MPC library for threshold signing. Uh it can be used for key protection and management for consumer wallets, institutional custody and so on. We we are this is what Coinbase is using. Uh exactly said it's not exact replica but very close and it has strong theoretical foundations. uh we've done extensive reviews internally and externally and audits and thank you

very much and if there are any questions I'll be happy to take them. Thank you Yuda. May maybe we can take one or two questions while the next speaker uh is setting up. Any questions in the audience? Yes, you will get the mic. Yeah, I have I have one question. What was the reasoning behind using C++ as opposed to like Rust for example?

So, uh I I think that it's uh um personal choice. you wanted to use the OpenSSL as a low-level library because it's a a library with many many years of inspection even the bugs that were in OpenSL or at the higher levels it is a very very robust low level um it's something that it's built on a library that we've been implementing MPC uh for key management since 2015 in unbound security and now in here in Coinbase we continued and extended it uh and that's uh um they were the choices that we made then uh we we for low-level cryptography we think that

it's a very good choice but uh you know one can one can argue either way I I know the arguments for in terms of memory management and others but we think that if you have the right experience in C++ it's a very performant and good library to use another question um for MPC I guess you need some sort of communication layer as well. I'm wondering if you have recommendations what to use there and do you also specify like messaging formats and stuff like that.

So there is uh the the library comes as an abstract uh messaging layer. It's not built into the library because uh each when you're writing an application, you'll have to decide what makes sense for you. Are you client server model? Are you multiple servers? Uh do you have are you going to use your organizational certificate authority or are you going to have pin certificates? So we decided as a conscious decision not to fix a communication layer. You can actually write your own communication layer according to the format that's in the library. The uh go demo that I was going to show has an example of a communication layer. Uh you really can use uh we we even though it's

strictly not absolutely required for dishonest majority protocols, we uh uh are assuming that you're using mutually authenticated TLS channels. Uh that's what we do internally. Uh the go demo is a good example of the type of communication layer to use. um how we want to set up the authentication is very critical but um yeah I would say TLS 1.3 with mutual authentication is is the way to go okay thank you Yoda we are running out of time many thanks for being here uh and thank you again uh see you thank you very

[Applause]