ZK11: Aptos Keyless: Blockchain Accounts without Secret Keys - Alin Tomescu

Transcript

[Music] um so my name is alen I'm the head of cryptography at Aptos labs and today I want to tell you about Aptos keyless accounts which are blockchain accounts that avoid the use of secret Keys um and what they base their security on is a traditional web to account like your Google account or your Facebook account or your Apple account so let's get started but before we do I want to say this is Joint work with the core team at abos Labs the core keyless theme uh Michael and Rex should be in the audience and you can meet them today uh Michael designed our circuit Rex audited it and worked on the prover service and

also the broader app TOS Labs team and the folks at geometry research some of them in the audience right here uh who helped us secure the ZK circuit so what is a keyless account uh well it's just the way I think about it your blockchain account is your Google account there are no user managed secret Keys uh and as a result you get many goodies which are going to which I'm going to mention throughout the talk and in the stock when I say Google I want you to think Facebook I want you to think GitHub or any open ID connect provider or oidc provider but for Simplicity I'm just going to say Google so why do this why enable keyless account the short answer is we want to onboard the next 1 billion users we don't think this is going to happen if

every time a user enters a space they have to write down 24 words and put them somewhere safely and lose them and then never engage with the space again so if we're going to get people in this space we need to find a way for them to join the space very easily so if you think about the current user experience of using a d app or a web 3 application you have to install a wallet what the hell is a wallet users are very confused they have to write down this memonic this is very combersome uh it's very easy for them to lose this pneumonic and lose their money uh they have to deal with transaction prompts what the hell is a transaction prompt most users don't know and it's very painful to move your device uh to move your account from your laptop to

your mobile phone to your tablet so what we want is kind of the opposite we want we still want wallets but we want the possibility of being wallets we want users to directly sign up for a d app without installing extra software we don't want users to write down the monics that's just painful uh nonetheless we still want the account to be very hard to lose and we'd like to avoid transaction prompts if possible and we'd also like to for things to work across device and additionally we might also want other goodies like we might want kyc via the IDC provider we might might want to be able to send transactions directly to an email address that would be great um so that's what I'm going to tell you about in this talk how to

enable all these things so how do keyless accounts work at a really high level there's four things I want to say here so first a keyless account its address is derived from two things your email address and the application ID of the wallet or the D app you're using so that means these accounts are app specific uh so they're associated with a D app like d app. XYZ or they're associated with a wallet like metamask and this is what prevents a malicious website like medium.com from stealing your keyless account associated with dxyz the fact that you have this the dab specific binding and this is also what allows for wallet list apps um the fact that we

have this binding now a keyless transaction signature the way this works is it's really the same thing as an open ID connect signature from the provider and really it's a zero knowledge proof of knowledge of such a signature for privacy reasons and this signature from Google is over a couple of things the transaction hash your email address and the application ID and lastly we add a splash of zero knowledge for privacy so we want to hide a couple of things we want to hide the email address and the application ID from the chain from the full nodes validators everybody but we also want to hide transactions from Google we don't want Google to be able to track which email addresses are are associated with each blockchain addresses and which

transactions are associated with an email address so at a high level this is the picture uh next I want to go a little bit deeper and actually show you some some details um so let's start with uh the open ID connect protocol and how applications register in this protocol in order to get a client ID a so-called client ID so if you have an application like media.com or dap. XYZ you go on the Google Cloud console for example and you register it in there and at the end of this sort of manual process you get a so-called client ID so this will be the application identifier that I mentioned before which is committed in your address and it's also signed by Google when it signs your transaction right so

that's the first step so now that the application is registered let's see how kind of uh open ID connect flow works so you're all familiar with this because you've all used websites that asked you to sign in with Google so this is what happens when you use those websites you you go to the app and the app displays to you this prompt uh by redirecting you to Google and in the URL that the app uh redirects you with you actually have a few param in there so you have this client ID that I mentioned before which is the identity of the application and very very importantly the application can specify any arbitrary data to Google and what Google will do when you sign in with your cookies is it'll send the app this signature right and the signature

will be over three things your email address that you successfully logged in with the app's identity and this arbitrary data that the app included right and this of course this arbitary data here will be very important because guess what that arbitrary data will be a transaction so and this is how we're going to get Google to sign your transactions for you and this is how we're going to make the account be keyless um and what's worth emphasizing here also is that this is a digital signature right so this is publicly verifiable so anyone who has Google's public key can take the signature and verify it so now here's a couple of observations what if this third party verifier is a blockchain and what if the application is a wallet or a d app and what if the

data being signed is a transaction right then you're basically looking at the keyless picture if you get one thing from the stock it's this slide this is basically 90% of a picture the next part of the talk I'm going to refine it a little bit since we we're going to need to deal with privacy um right so the way it works is your wallet will will sign you in and then you want to send transaction for your address and you will include this oidc signature from Google together with the application ID and your email address so so far this is not privacy preserving right we're going to fix it in a second and you can send this at the blockchain

validators and what the blockchain validators can do is they can verify the signature like I showed you before because they have your email address they have the client ID and they have the transaction and additionally they're going to match that the address you included in the transaction is indeed associated with the account in the signature right so they're going to verify for example the address is the hash of the email address and the client ID right so far so good but there's a problem you are revealing in plain text your email address and the application ID and in particular the email address is very worrisome but even the client ID could be problematic if you reveal it because it leaks which applications are doing

what so we got to fix that and obviously the very trivial fix is to just throw a zero knowledge proof at it right so instead of giving all of the secret witness like the client ID and the and the signature and the user email we're going to we're going to move it inside of a zero knowledge proof and we're going to do all of the work inside the zero knowledge relation here so this is a zero knowledge proof of knowledge of an oidc signature and an email address and a client ID such that the IDC signature verifies over the public input public key and over the public transaction input right and such that the public address input is derived from the secret email address and the secret client ID so from the blockchain

validator perspective all they see is an address and a transaction and Google's public key and this proof assures them that there is an oidc signature over the email address inside the blockchain address right and the client ID and over the public transaction okay so this is again a very you know it looks very simple when you put it on the slide it's very hard to implement but it's a very simple change you just throw a zero knowledge proof at things this is what we like to do in this community anyway good so there are some complications with the zero knowledge proof uh it takes I think about 30 seconds to compute in the browser so if we're going to use this for our users

it's going to be very bad ux so we'd like to speed it up so we have to rely on aover service um which is going to make the computation of the Zer knowledge proof much faster we can compute it in under two seconds but it's going to have some privacy implications and we can talk about those later because in particular the prover service will learn the secret witness so it learn the email address and the client ID uh nonetheless I should say it's very important to emphasize here that theover service cannot steal your funds I'll I'll describe that uh in a second as well uh nonetheless there's still more problems left so as you can see here Alice has to compute one zkp per transaction and the blockchain has to verify one zkp per transaction so we

don't like that for performance reasons so the way to fix that is using a layer of indirection that's every problem in computer science can be solved with a layer of indirection uh so what Alice is going to do is she's going to generate an ephemeral key pair let's see right I have an ephemeral key pair here es and an EPK and next what we're going to do is instead of signing the transaction we will give Google this EPK to sign and in the transaction signature we will include an ephemeral signature over the transaction under this es right and then the blockchain validators can simply verify this ephemeral signature so we've

added a layer of IND Direction so now you can think of the zkp as a certificate for this ephemeral public key and the transactions are signed by the ephemeral public key and this signature verification is in plain text right the validator see an Emeral public key and a signature on the transaction there's no privacy loss there and notice that although there's a key here these keys are ephemeral you can lose them it doesn't matter if you lose them you sign back in you generate a new es and Google will gladly sign it for you so they're not sensitive from a loss perspective and for those of you who are familiar this keare can actually be a web aen Pass key keare so this way you can actually be very secure that it

won't it won't be stolen right if it's backed up in your iPhone's Enclave let's say still we have more problems the address uh that uh is stored on chain is a function over the email address and the client ID so it obviously leaks an attacker can brute force your email address and the client ID and tell who you are on chain so we want to fix that too and the very simple fix there is to just make the address be a commitment rather than a hash of the email address right so we're going to use a blinding factor for that we call this blinding factor a pepper uh these are just random bits now if we did this naively the user

would have to pick those bits and remember them and if the user loses those bits then they can no longer access their account so that would defeat the purpose of this whole approach because the whole point is we want to avoid storing long-term secrets so instead what we're going to do is we're going to have a pepper service that's going to help users remember their pepper so the way this will work is the pepper service will evaluate a verifiable unpredictable function over the email address and the client ID and that defines the pepper in the blockchain address associated with these two and this actually makes the pepper service a very simple service it just has to store a 32 by VF key like a BLS key

and it's also very easy to decentralize so you can have a decentralized pepper service with 20 servers that just computes a threshold signature for the user to get the user the pepper and of course there's an access control issue because the pepper service better not give my pepper to somebody else it better only give it to me and the way we actually guarantee access control is also via the open ID connect protocol because the pepper service can actually verify these these signatures uh from Google before giving you your pepper um so that's the good news about the pepper service and right now the pepper service is not privacy preserving but we can actually make it price of reserving as well so the pepper service could in principle receive a zero knowledge proof

of knowledge of an IDC signature and a blinded um hash of the email address and the client ID and evaluate the BLS signature over that blinded hash so that so that it doesn't even learn which User it's Computing the pepper for uh we haven't down yet but that's plans for the future good so next step is one last tiny detail is that Google will actually see this EPK here in the nons right and if it can see this EPK then it can track transactions on chain um so now it knows which user is doing which transactions this is also a very trivial fix instead of putting the EPK in the open ID

connect signature we're going to put a commitment to the EPK using some different blind Factor R which is part of the secret witness of the zkp and basically we're done that's the design this is it so if you get a second thing from the stock it's this picture right here uh which is the complete privacy preserving story with the pepper service and the approver service for performance all right for the next part of the talk I just want to uh mention some things about our implementation so when we built this because because this is a layer one primitive right we are putting these kind of keyless signature on our transactions we have some pretty

aggressive performance goals so we want the verification time of such a keyless transaction to be very small and also the proof size the zkp to be very small uh in particular this is kind of stringent if you think about it because if an attacker puts bad zkps in your transactions you have no recourse like you're going to get dossed because if the zkp fails to verify there's no account that you can charge gas to right there's nothing you can do so you really have to make the implementation fast uh so our only choice was to do gr 16 over a fast curve b254 and to implement the relation in in uh in gr 16 we use circom we have 1.3 million R1 CS constraints and our code

is actually public we invite you to look at it we invite you to build over it um it's in a way very related to the ZK email work that you've seen before and some previous work on verifying jwt's in snarks um and what's interesting about our circuit is that we have some new polinomial based protocols for doing substring matching in a circuit which is otherwise very complicated to do and very expensive to do I should say so this is what helps us achieve a small number of constraints we did an NPC ceremony for the circuit we used potion uh fixed a couple of bugs in it and we had 140 participants over the duration of one week and our prover service is implemented

via a hardened version of Rapid snark which is a C++ code base it's really fast the only thing faster than rapid snark that I could find is maybe gar but I couldn't manage yet to Benchmark our circuit in gar because we have to take our circom circuit and put it in gnark if any of you know anything about that please talk to me uh our pepper service is just a rust based service uh that uses BLS uh to evaluate the pepper and that's it that's our implementation so to conclude the talk um I think ux is key for blockchains and good ux Is keyless so open source uh codebase please take a look at our rust validator

code at our repo uh at our MPC trusted ceremony and Prov service I think and pepper service are all public we have a test deployments uh active on the appos blockchain this is deployed in devet and in testnet and will become to main net pretty soon um it's also already been used in the app toss random hack where we've seen a few projects build on top of it so that's very exciting uh and if you want the nitty-gritty details and all of the security implications and details you can find them in an Aptos Improvement proposal that I wrote there's a PR open there's a couple of more things to address there um future work I think this kind of approach raises some interesting

questions about what kind of oidc providers would you be willing to trust with your blockchain accounts so this approach is not to say that all users should use it it's probably for 90% of users who are novice right but even for those users maybe Google is not the right choice so maybe we There's an opportunity here to think about identity providers for blockchain users and maybe there's even a business space in that um we want to try and move the pepper service on top of the validator so that it's as secure as our validators as well as making it privacy preserving we also want to try to potentially move the trusted setup on top of of our of our validator so we can easily bug fix and upgrade our circuit

or ideally move to a universal snark that meets our performance goals and obviously we want to work on faster proving to eliminate the prover service um and there's a lot of cool features that I did not get to discuss I'll I'll leave them here for you and also a lot of nuance and details in particular the this Emeral key that I mentioned actually has an expiration date it doesn't leave live indefinitely and there's implications around D specific accounts that you have to deal with and there's implication around wallet list D apps that you have to deal with and just this Json web token stuff this open ID signature format uh and and how we deal with it in our application uh but that's it uh thank you so much for your

attention and would love to get lots of questions thank thank you do we have any questions there's a microphone do you know the system by now okay don't sy so is it's coming up all right fantastic thanks great talk uh I had a question about malleability and whether it's an issue here so great if right so was the intuition um I'll wait for the slides to come yeah can I get the slides back yeah malleability was actually I think in the list of stuff it was sorry like I blanked at that point then I yeah so we we deal with it in a very simple way we get non-malleability by signing the proof with the ephemeral secret key

uh which is a nonmalleable signature as well um that's how we got nonm and and yeah we were worried about it in principle all of our transaction signatures are non-malleable because we don't want people to worry about malleability so so this solves the problem of malleability of the of the gr 16 yeah because the ephemeral signature itself is non malleable and then there's just gr 16 and then you have to be careful that other things like metadata next to the zkp and the FML signature is not malleable as far as we know it's not but if you want to take a look at our code thanks thanks for the answerers okay any other questions yes in the back there's a microphone down on on the

chair just press the button uh sometimes they don't work now now you can hear okay so I want want to ask what's your sensorship resistant model and more specifically what's the fallback in case the signature provider goes down or doesn't want to provide the signature for a specific user uh I couldn't hear it very well could you put the mic can you put here is it better okay so I'm going again what's your sensorship resistant model and to be more specific what the fallback in case the signature provider doesn't want to provide the signal to specific user or anyone else yeah that's that's a that's a very good question so there's a

few ways to deal with that um it so at a fundamental level you want to pick o IDC providers that you have recovery mechanisms for in case they stop playing bow that doesn't answer the question though because any provider can go down any day so if I have an account in an app using a kills model that means if the signning provider goes down for any reason reason or doesn't want to give a signature for my user for example that means that I lose everything yeah correct so if you if you have a bad provider that that's bad for you you don't pick bad providers you would pick really trustworthy providers I think the only risk here is that the provider probably says look I don't want to have

to do anything with blockchain applications so any client ID that is a wallet or a d app I'm just not going to provide signatures for and in that case you need a recovery mechanism for your users and there's two things that we can imagine doing one thing is we can use for example the ZK email approach to recover your account if you've been to their talk so basically you can send an email from your Google account which has a signature from Google and that email can authorize a key rotation for your keyless account so that that would be okay it would be kind of user unfriendly but in principle it would give you back access to your funds another way would be to have a recovery service so a recovery service with its own client ID that users log into and the only thing this Recovery Service does is it rotates

your key so maybe you know Google stops playing ball but it allows this recovery service to help users recover um so those are two things that you can do and in general that's what I mean by yanto IDC providers that admit recovery mechanism so let's say you use Twitter you could use a public tweet to rotate your account to a new publicy if you had an HTTP Oracle on chain right that's another recovery mechanism for another provider I I hope that answers your question but I'm happy yeah we can also talk after discusser yeah there's a microphone on the ground do you see it it should be red light yeah sometimes they don't

work okay thank you uh so you have mentioned that you are using proven service in your application is it is it trust us or to which degree is it trust I suppose uh I I fail to emphasize that huh not sure what happened with my slides uh it's trustless so if you think about it the prover Service uh gets this soidc signature over an EPK right it doesn't know the associated es to sign transactions with so the approver service simply you know you lose privacy with respect to the approver service but there's ways to deal with that you can MPC the appr service and in fact snarks like grat 16 admit very efficient MPC protocols but you know that's the only problem privacy

which which is addressable um stealing your account isn't impossible because the approver service doesn't have the es and it cannot get a new IDC signature over an EPK whose es it knows right does that make sense yeah thank you any other questions where the front Okay we have time for a couple questions I'll just take this one first out of proximity I'll come to you um does the pepper service generate the peppers or stores them too yeah good so um I mentioned in the talk that the pepper service is uh using a verifiable unpredictable function to generate a pepper given an email address and a

client ID by simply evaluating a VF over them a VF an example of a VF is a deterministic signature scheme like BLS why can't users do that themselves is it too expensive or what but well they would have to remember it if they did it that that themselves right so it does store it or generates it time it only stores is the secret key of the VF so that's 32 bytes and from that secret key and a email address and a client ID it can derive the pepper without ever having to store it but what happens if the pepper service fails if the pepper service fails then users are locked out of their account if they don't have their pepper right so it's very easy to mitigate against that so one one way is

for users to back up their peppers if they're paranoid but we don't like that uh another way is to actually decentralize the pepper service and make sure the key is never lost what you want to ensure is that the secret key of the pepper service is not lost now maybe you know the top 2% of users uh might just generate their own peppers and they won't use the pepper service we I don't think that's realistic for 90% of the users but some subset of users might want to uh in general we're not very worried about the secret key of the pepper service getting lost because it's really easy to protect the key for you know getting lost okay thanks good so many questions it's good thing your presentation was shorter yeah I just wanted to connect to

what was saying the person before so you say that the prover you have kind of no privacy to the prover but then since the secret key is in your possession then you know it can in reality gross 16 proofs can be are maleable in itself so the pro can randomize them to embed tagging information in the proof itself and then the user will sign and will go so yeah uh one second let me just okay uh you're saying a malicious prover could yeah because if the Malisha approver has access to the email address it can somehow embed it by randomizing the proof and until some bites match like grinding through proofs that's a really

interesting uh uh yeah I like that that's interesting I would say the way to mitigate against that is probably the same way you would mitigate against the uh the Privacy issue by MPC and the pro service which would which would fix that but yeah actually we haven't considered that I really like that thanks a lot okay we can discuss later yeah did we have another question here cool I think that's um hi can you derive uh public um address from email address like if I want to send some funds to someone who hasn't used the the service correct so what you could do if you wanted to send funds to someone that isn't signed up is you could derive an address for them so let's say you want to send fun to Alice

on some wallet or some pay application um like let's call it pay to email right so pay to email has a client ID you know it and you know Alice's email and then you just pick a pepper for Alice you pick it for her you pick random 256 bits and then you email Alice hey Alice I send you funds here's the pepper for your address Al Alice can rederive the same address and can sign in with Google into the application and obtain a open ID signature engage approver service get a zkp and as a result get access to those funds but the only difference in this case is that you're not using the pepper service Alice is simply using the pepper that Bob picked to pay her is is the pepper choosed by Bob or just Bob

initial initiated uh the pepper service I mean no it's it's it would be chosen by Bob would probably be the best way to do it but you could also imagine that the pay to email application could when I say chosen by Bob is really by that application right and then that application would email Alice with the pepper or maybe you would create a link and embed the pepper in the link um and Bob can can't use this pepper to gain an advant advantage of this account uh no no so remember that there's two things you need to access this keyless account for Alice you will need the pepper because you will need to do the address match but you're also going to need an oidc signature from

Google and Bob is not going to be able to get that IDC signature because he doesn't control Alice's Google account okay I think that's all we have time for so thank you so much elen another round of applause please thank you so much for the questions