Security & Trust Assumptions for Evaluating Non-Custodial Wallet Providers| TJ Connolly - Fireblocks
Ethereum Denver·Wed, Oct 9, 2024, 12:00 AM
“Security & Trust Assumptions for Evaluating Non-Custodial Wallet Providers" which will cover the basics of what to look for in wallet technology providers for business end-users. Non-custodial wallets are going to enable the on-boarding of crypto's next billion users, and it is paramount that as an industry we build non-custodial wallet experiences with the highest level of security and lowest amount of implied trust. I will compare and contrast several non-custodial wallet models to assist executive and technical decision makers in creating a framework to evaluate which model will work best for their business and ensure a trustful and truly non-custodial wallet offering.
Transcript
we're ready for our next talk thanks for joining us here at the Trident stage eth Denver 2024 I'd like to welcome our next speaker we've got TJ Connelly he's a principal engineer at fireblocks and the talk today is called security and Trust assumptions for evaluating non-custodial wallet providers thank you everyone welcome thank you um so hey everybody uh first thing you should probably notice here right non-custodial in quotation marks I think that means a lot of different things to a lot of different people it's a very nuanced subject um and once you start getting into the really the underlying security models um that can mean a lot of different things right is a wallet truly noncustodial if the wallet provider is able to you know ease drop on sensitive activity things like that so the purpose of this presentation is to you know help educate uh if you are looking to use use non-custodial wallets maybe you're a web3 business or a Dap looking to onboard users um this talk can help you ask some of those hard questions to look for you know what are the most kind of secure models to do this and really the the most trustworthy as well uh so quick about me that's me uh background cyber security um you know specifically kind of in this field around uh applied cryptography uh pen testing and things like that um so first off you know why why would you as a business want to offer non-custodial wallets we all know that you know you have to onboard users right so what are your options to onboard users number one they need a wallet right without a wallet then it's a you know a web two facade over over web 3 and doesn't really provide any of those benefits of web 3 so your options are number one let them bring their own wallet right this requires the user to be a crypto native have expertise this may limit the amount of users that you can onboard number two is you provision custodial Wallets on their behalf so this is what a lot of exchanges will do right you go and you trade on coinbase or Robin Hood your crypto is physically sitting on a wallet that those exchanges control right it's not your keys it's not your crypto um this is a you know obviously tons of risks here right counterparty risk uh everything along with that but also as a web3 business or adap trying to onboard users that is a big uh regulatory concern as well because now you have to hold all those users Assets in your custody on your balance sheet and assume all the risk that that entitles right we have things like sab1 121 here in the US that really prevents that and kind of makes that impossible for most uh publicly traded corporations good news is hopefully that's changing um but some big challenges with with that model as well and so the the third model uh which we've seen with embedded wallets and non- custodia wallets is that you user comes to your platform you provision them a web3 wallet because they don't have one already and it allows them you know all the benefits of self- custody and allows them to easily interact uh and on board to your application so again all these have trade-offs um you know non-custodial wallets AKA and beta wallets they've seen a re a recent surgeon demand um you know really trying to onboard web 2 users and one of the things that I think is really overlooked too is if you can control the wallet which is effectively where all of that users identity economic activity occurs there's a lot of value that you can extract from that both you know for the benefit of the user or the benefit of your platform or some hybrid thereof right so quote here that I really like is from the uh the Salesforce web3 lead you know he says the wallet is now the new cookie right if I can give a user an identity and track that identity across different boundaries I can start creating a profile start doing really interesting things like targeting them with different ads um you know for better for worse um and then there's also you know direct Revenue opportunities my favorite example is metamask within metamask you can do Native swaps they're not doing any of that swapping themselves they're just routing through you know Unis Swap and other uh routers um but they've been you know because of the use of uh ease of use of that swapping capability they're able to charge about 87 basis points you compare that to most swaps which are you know five to 30 basis points um and they've been able to do that because it's a great user experience right and the users are okay uh paying for that because they can do it all natively within that uh within that wallet experience so you know this is what the current market looks like you you obviously have providers like metamask or Ledger Hardware devices where you bring your own wallet to the to the uh the DAP or the web3 business uh we have wallet widgets these are the ones that have definitely gotten the biggest uptick um so far because of ease of use and convenience and then you have the white label wallet sdks uh which is where fire block sits among some of these other other players uh where you know you have more bespoke programmability and sdks uh to be able to build a more bespoke non-custodial experience so that being said right what is the trust assumption when you go to a wallet provider uh or a Dap and they provision you a wallet you're inheriting a lot of trust assumptions right you're inheriting the trust that hey that wallet issuer whether or not the tech provider or the business they haven't backdoored it they haven't Eaves dropped on any of the sensitive key material um and they can't you know maybe censor transactions or things like that um so what we've seen is a lot of issues with this right again in the the race for convenience and ease of onboarding for web to a lot of sacrifices have been made for security and Trust so here are just a couple of examples of that and I don't want to throw shade at like any particular model here really the purpose of this talk is to you know educate all of us to be able to ask these hard questions there are going to be businesses where you care more about convenience right you care more about onboarding users easily right and you want to get to Market fast totally get that but understand you know what it what the tradeoffs are so a lot of these wallet widgets uh what they use is some form of a magic link so user comes into the app they authenticate typically a web 2 authentication like a a social login using you know your Google credentials or your iCloud credentials and then the wallet provider uh produces a one-time link which then once you click on that one-time link it does something in the background and a wallet is provisioned that link itself um you know I don't agree with uh this particular headline calling this vulnerability uh it's more of a fishing scenario right there's opportunities for a man in the middle to go and manipulate that magic link or control that magic link prior to actually clicking on it such that they can control and uh uh own that underlying wallet that's that's being provisioned we saw this here with friendch um very similar model right there's a magic link uh there's some other issues with with with with that which we'll get into uh but same thing right there's a supply chain of where that wallet gets provision from how it uh uh gets uh accepted and authenticated by the end user and with that supply chain there's lots of opportunities for vulnerabilities the next one down here this is pretty interesting because on the bottom left um this is not a noncustodial wallet per se uh this is just you know a typical self- custody wallet uh this is in the Buy bance trust wallet I don't think it has anything to do with binance anymore I think it's it's its own thing um but you know typical wallet it's on your phone uh they found uh you know a pretty severe vulnerability this is in the the nist uh uh vulnerability database and you know there's basically not intentional there's a back door in one of the crypto crypto cryptography libraries uh that that wallet uses right so what does that mean was that there intentional was it there not intentional we don't know it doesn't matter really uh all that matters is that the C generation on those types of wallets is now vulnerable and you know the wallet issuer may may or may not have been aware of that the other one here is another supply chain type vulnerability um where you have fake wallets being listed in the app stores right app stores are supposed to be these super secure walled Gardens uh but we found that you know fake wallets that have drained users fund have actually been able to get through uh the Apple and Google uh Security checks so again you know in the idea of Education right I think everyone here if you're looking at wallet Technologies you need to uh understand this right this is the private key and digital signature life cycle this is how accounts on blockchains work right this is how TJ on the blockchain is somebody different than Satoshi um so you have you know four key components here you have how the key is generated uh how the key is stored how the digital signature which authenticates and authorizes that user uh is created and then lastly this is where the blockchain comes in the blockchain just says yes that's a correct signature use the correct corresponding public and private key sign the correct data and you know we'll go ahead and settle this transaction so the attack vectors here right every piece piece of that life cycle that's happening within your wallet right so if I'm bad guy here right and I steal you know your uh your credentials to your laptop you have metamask running there right I can go in and I can do whatever I want at that point right I have your password I don't need to get I don't need to steal private keys or anything I can just go and use metamask now as the wallet provider you also have insight into all these different levels of activities right so as the wallet provider you're generating the seed that then those private keys are generated from you're storing those private keys in some form or fashion you're also prompting the user to sign transactions that they authenticate with those private keys right so tin foil hat lots of opportunities here if you were a wall provider uh to kind of take advantage of this so you know don't want to be doomsday scenario here you know I think I think we can find a happy medium here between you know being both secure trustworthy and convenient um again not a one- siiz fits-all you may find yourself as a business more focused on the convenience factor Less on the secure and trustworthy again that's fine um you know we all have different objectives and goals um but you know if you are looking to build in this really take the time uh to understand what those trade-offs are that you're making the trustworthy one is is tough because in this space right if you lose trust as a technology provider it's very hard for that to come back right we've seen this with protocols that have gotten hacked or you know obviously if a protocol you know does a rug pull they're never going to come back from that right so trust is is super important in this industry so going back to you know how how should you look at different uh non-custodial wall providers uh we're big fans obviously a multi-party computation uh this is what fire blocks does we provide uh MPC based wallet infrastructure um some of the other providers generally uh the kind of key architectures that you see is that the first one on the left where there's some Cloud Server you know it's an AWS server and the basically the the wallet provider is generating the key you know in a secure Enclave or in an HSM um and they're doing that on your behalf right this really isn't non-custodial cuz it's all happening on somebody else's infrastructure that you don't control right the other one is going to be Shamir secret sharing um by itself uh you should kind of look at this with some concern uh because Shamir secret sharing if that's all they're using without MPC then basically what it means is that there's a single private key that gets generated at a single point on a single device and again that device could be you know know uh on their infrastructure on your infrastructure but there's still a single private key and that's a single point of compromise and so with multiparty computation all of that key uh life cycle that I showed you that is done in a distributed manner in a trustless manner and I'll I'll explain that uh here so we have our private key we have uh Alice Bob and uh Charlie um with MPC and threshold signature schemes what it's allowing you to do is jointly compute a function over different inputs while keeping those inputs private so in the example of a digital signature and key generation right we have to generate the key can we do that in distributed manner uh can we store the key in a distributed Manner and then when it comes time to sign a transaction can we do that in a distributed and trustless manner um this is useful in scenarios where no one trusts each other so take the example of okay I'm a user coming to a web 3 app you're provisioning me a wallet how do we create a trustless setup where I have really kind of the most uh important input into that key generation but I still you know can use other parties uh to help distribute that and make it more secure so again the full Keef life cycle here is that it can be generated and calculate the signatures interactively through these different multiple parties and most importantly the private is never assembled in one place and when it implemented properly all three of these pieces of key material here this could be arbitrary you could have a two of two MPC you could have a four of4 MPC there's different models for that uh but what the important thing to note is that if you're a bad guy uh whether or not you're the wallet issuer and you want to back door the wallet uh or you're you know compromising their infrastructure you need to get all of those key shares in order to recreate the master private key right this is the concept of perfect secrecy so also want to reiterate that with everything in security uh there is no Silver Bullet when it comes to security uh and MPC is definitely not u a silver bullet uh it is something to Aspire to and again I think it's you know the best model to to look at um but you know we found uh a couple of researchers at fire blocks found multiple zero day vulnerabilities in some of the most widely used MPC protocols out there uh gg8 gg20 lindol 17 uh these are prior uh uh implementations then fireblocks is MPC CMP if you're familiar with that um the vulnerability here is in that threat model right if you remember Alice Bob and Charlie in the in those implementations Alice here is actually a malicious party right so this might be the wallet issuer that's a malicious party um so we found found about 15 different vendors uh whose implementations were vulnerable to this where it resulted in uh total compromise of the underlying key material right so just a friendly reminder right and the underlying issue here was that a lot of those uh again they're very different compared to the different wallets but generally speaking a lot of them did not use required zero knowledge proofs to basically verify securely that the key was generated correctly they were stored correctly and that the signature was generated correctly um if you do that in this trustless man in uh you know this this uh multi-party environment and you don't do that with also verifying and without exposing sensitive data to the network then you're going to find yourself susceptible to these types of vulnerabilities so again friendly reminder security should never be a a commodity um this is what I see a lot of people say oh you're an NPC well we got NPC we're good you know it's it should be more than just that uh you know we got a firewall we're good right it's it's it's more than that um so you know partner with security and cryptography experts to help you focus on your core business right you're you're trying to onboard users you don't want to worry about this you know there's resources out there and when it comes to end users right this is something we didn't talk too much about but if you don't understand those trust assumptions for your users and being proactive with with address in those um then you know that can put you in a very challenging spot um once once that trust has been lost okay so what about account abstraction you have did a great job uh touching on this a little bit one thing to take away is that every account abstraction enabled Wallet requires to be deployed from an EA and an EA may or may not be part of the signing scheme of that uh account abstraction enabled wallet so you want to make sure that you know again MPC uh you know we think that MPC Plus account abstraction is really the way forward I call it a match made in crypto Heaven um so that wraps it up uh if you guys are interested in building with fire blocks non-custodial uh wallets as a service uh we have free sand boxes so you can go and and sign up don't have to put in any credit card information or anything like that you get in start building and um you can find that right there uh on our website non custodia Wallet developers. Fire blocks.com feel free to email me directly uh if you have any questions or need any help and uh thank you very much
Automatic transcript — names and jargon may be misspelled.