Zero-Knowledge Proofs for Keyless Blockchain Accounts

Transcript

all right hi everyone uh let's get started my name is alen I am the head of cryptography at apos Labs we're a layer One Network on for smart contracts using the move programming language today I want to tell you about this feature not just applicable to apos blockchain but also to any other blockchain out there for building blockchain accounts that are keyless so that you don't have to worry about secret Keys you don't have to worry about pneumonics you don't have to worry about anything anything like that if you're an noice users so basically what you're going to do instead is you're going to sign transactions with your Google account not with your nemonic so the kind of idea behind this this this thing is this question of how could a blockchain account work if we lived in an Ideal World right so the way

I see it is I would go to a web wallet here I'm showing you ours appsc connect.app this web wallet would ask me to sign in with Google I'd select my Google account I'd sign in and now I'd have access to my my wallet I could connect it to a dup I could do whatever I want and in fact it wouldn't have to even be a wallet it could be a DA app directly that I could sign in instead of actually using a wallet I could even have a prompt lless uh uh ux so if you get one thing from the stock it's that your blockchain account is your Google account right so that's what a keyless account is this means that it's as hard to lose as your Google account it's as secure as your Google account or really any other oidc open ID connect account

Facebook GitHub and so on and most importantly there's no NPC custody right so there's no third party system or decentralized or Not that we're trusting with your keys it's literally just Google um there are no secret Keys involved at least none that you have to worry about losing or having them stolen from you uh your Google account is your secret key is the way to think about this uh and it's privacy preserving this is where the zero knowledge part comes in this is where Noir comes in um and this is why you guys are here so it's privacy preserving in two ways the first way is Google does not learn your blockchain address nor your transaction history it would be really bad if that were to happen and the blockchain does not learn your your email address right it would also be bad if if that were to

happen because you might not want people to know how much money you have right and so why enable this feature um the the goal is really to expand safe seamless access to cryptocurrencies we want cryptocurrencies in the hands of more people most of these people will lose their secret keys if they have to set up one so how are they to use cryptocurrency uh they have to install a wallet they have to write down this pneumonic as a result they're going to lose their account they have to deal with the transaction prompts what is a transaction prompt is very confusing for novice users if they want to do this from their phone their laptop or their iPad they're going to run into a lot of difficulty moving over their nimonic and again if they're not as users they're

going to get fished like they're going to put their secret keys in some Discord this happens all the time um so instead the way things can work is things can be wallets and prompts uh you don't need to have a pneumonic it's very hard to lose your account as long as you can recover your Google account you can recover your blockchain account it's cross device as long as you can sign in with Google from any device and you can even get some nice perks like you can send money straight to an email address you don't have to type in a 64 character hexadecimal string right uh now why not do this so usually the main objection to to not doing such a thing is that people don't trust Google or they don't want to trust Google and that's fair and for those people I would

say you should do self- custody especially if you're a power user but keep in mind there there's been billions of dolls in Lost cryptocurrency assets so not a lot of us are qualified to do self- custody or you can do something like two out of three you can have Google and apple uh um and you have three total factors um or you can do kind of minimize the Reliance on Google so instead of uh uh trusting Google to sign your transactions all the time you can trust Google to just help you cover your account right so only there's like a really small window in which Google could screw you over and steal your account right and happy to talk about that at the end of to talk more uh since this is a very genuine legitimate objection uh so basically what this talk is about is how does this feature work

so I want to show you some very simple cryptography digital signatures hash functions zero knowledge proofs and what I'm hoping to get from this is I hope you guys will take this and implement it in no okay because that's what I I want to try doing and I need some help um and I also hope you you take kind of the Paradigm as a whole uh and consider it for your systems that you're building because I think it's very very useful and very very user friendly okay so let's begin by kind of going through this signin with Google flow that all of you guys are probably familiar so you know we have a user we have Google and we have some application which is registered with Google and got this application identifier from Google called the client ID right so that it can support the signin with Google flow

so the way typically think work is the user goes to the app the app displays a prompt for the user to sign in the user selects their Google account and in this request the application includes its identifier as a URL parameter but it also very importantly can include any arbitrary data and this is really key for enabling kyos accounts I'm going to show you in a few slides why right so keep this in mind the application as it signs you into Google can include any data advance in there and so now that the user signed in if he has a valid cookie and if he typed in the password correctly Google will send back to the application a digital signature over the following things so first there will be um one of the signed Fields will be the users's email address that successfully

logged in the other field will be the the applications identifier that the user signed in successfully and the last field is this arbitrary data that the application included right and so now if you look at this you realize that well this application could take this signature Sigma IDC and give it to any third party who has Google public key to verify right it's a digital signature it can be verifiable by anyone so that's the first observation the second observation is that this third party can actually be a blockchain right why not why can't it be a blockchain and that the the third observation is that the application can be a wallet like the appos connect wallet that I just showed you that you sign into and so it can also be a d app like a defi app if you

don't want if you want a wallet lless experience and so that's kind of the the brings me to the last observation which is that the data that that that the application includes for Google to sign can be a transaction right so now what we've done effectively is as Alice signed into her wallet the wallet put a transaction in the arbitrary data and Google gave a signature back to the wallet over Alice's email the application's identity and the transaction right and so this is the key idea behind keyless if you take one thing from the stock it's kind of this image right here but we're going to polish it some more because there's a lot of privacy aspects to take care of right and one thing I want mention here is that if this is to work then the blockchain has to have access to Google's public key under which IT

issues signatures and this public key keeps rotating and so you actually need to build an onchain oracle so this is kind of difficult to do uh on on some blockchains at least um right so put another way what we have is like the the the wallet can send a transaction for an address to the blockchain together with the signature from Google the application's identifier and the users identifier right and what does the blockchain do it takes the signature the user identif the application identifier and the transaction and verifies it against Google's publicy right so far so good okay great and of course like the last thing it has to do is make sure that the address that it wants to execute this transaction for matches the user and the application ID in the signature right uh well this is great

but it has really big privacy problems right so the the the data that the wallet has to include for this transaction is Alice's email and the application ID maybe the application ID you don't care about but your email you do care a lot about right so how do we hide this well this is kind of uh kind of our bread and butter here we're just going to do it via zero knowledge proof right so instead of giving the signature the the application identifier and the email address we're going to give a zero knowledge proof of knowledge of a signature application identifier and email such that this this signature verification passes over the secret data and the address is derived from the secret data correctly right so in effect what this is doing it's convincing the

blockchain that hey for this address Google with this public key has signed this transaction right that's what this is doing now uh I I should say here kind of again getting back to Noir and and to Computing zero knowledge proves fast is that this can be kind of slow to compute so the way we do it on opos is we have an external approver service to do this and kind of writing the ZK relation in a fast enough DSL with a fast enough ZK snark scheme is a really exciting not only research area but also engineering challenge uh but we're not done yet so there's kind of a problem here like every time you want to sign a transaction the way I've explained things so far you would have to sign into Google include the transaction as arbitrary data so that you could get a

signature from Google on it so that's pretty bad from a ux you don't want to sign in every time right so how we're going to solve this this is kind of trivial it's every problem in computer science is just add a layer of indirection right so instead of signing the transaction and instead of asking Google to sign the transaction I'm gonna ask Google to sign an ephemeral pup key whose corresponding ephemeral secret key the user knows right and the user would have generated this um and it's fine if the user loses this fmal secret key because it can just sign into Google again with a new one and get a new uh zkp for it right so now in effect what the zkp means is that for this address the zkp convinces the validators that transaction signatures can come from the CPK right and we kind of have to augment

the transaction format to include the the signature over the transaction from the corresponding es right because now the transaction is not implicitly signed by the zkp we have to sign it more explicitly with the es whose EPK is vouched for by the zkp right and lastly of course the blockchain has to verify this ephemeral signature yeah uh so this is kind of we're almost done here the only problem is that Google Sees the CPK so as as a result when it sees transactions on chain with the same EPK can tell that Alice gmail.com is signing these transactions so that's not so good but that's actually very trivial to solve right um

well oh actually this was not going to be the next problem I introduced I'm going to introduce a different problem before I solved that one so that actually I should have said the first problem is that the address right is low entropy it commits to a low entropy email address and a low entropy client ID which is actually even public so how do we solve that we're going to turn this hash into a commitment we're going to add a high entropy blinding factor in there we call this blinding factor a pepper right where you get this pepper from you get it in our deployment from a pepper service what if this pepper service gets compromised or hacked it's okay it just breaks your your privacy it doesn't break your security you still need your Google to access your account the pepper is not enough right uh but

how do you authenticate yourself to this pepper service so that other people can't get your pepper well you actually use the same oidc flow that I've explained so far to convince the pepper service that you are you and it should give you your pepper and then you can create the zkp with the peppers being one of the secret inputs right so that takes care of the address privacy but what about the CPK privacy that I was mentioned before well here um the solution is very simple you can just uh commit to the EPK using some other blinding Factor this is kind of an Emeral blinding Factor you don't need to persist it over time unlike the pepper which is kind of permanent right um and so basically this is the full keyless picture so um if you take a

second thing from the stock it's this image right here so again the idea is I'm getting a signature from Google over my email and the application ID and an EPK as a commitment to preserve privacy then the blockchain can verify that via the zero knowledge proof that the address that I'm trying to transact for has the same email and client ID as in this signature from Google and as a result the blockchain delegates signing right from my keyless address to the CPK and then I can send the transaction signed by that EPK to the blockchain yeah this is a great time to ask questions by the way since there's a lot of moving Parts here yeah okay so you said they could send to an email address I'm trying to

think ah great yeah so I can explain that via another slide uh if you want the idea will be that I will derive a pepper for you instead of relying on a pepper service I'll put the email in there and I'll put the application identifier and I'm going to send you the pepper so even if they haven't gotten the pepper on their own that's right can I'll just send you the pepper for you right yeah um so that's how that can work one way it can work there there may be others but yeah okay so this kind of brings me to how did how did we implement this keyless zkp uh and one thing I want to stress here is that as you can see in this picture the blockchain is doing the zkp verification yeah and so that means means that we actually the slower the

verification is the higher the gas cost of these keyless transactions so for us the verification is something that we want to minimize uh and so that doesn't give us a lot of options in terms of ZK snarks to use so we use gr 16 which is the fastest verifier time snark right over this bn24 elliptic curve and we have an implementation in circom and I know this is noon but that's why I'm giving the stock here because if you want a really tough ZK relation to implement and and actually as a result kind of write some new noiron STD light liaries you should take a look at our relation we have a lot of documentations and when we have a great circum implementation that you can use as a reference and we'd be really happy to collaborate on on such an implementation and it it takes about 2,800 lines of

code and 1.4 million are oncs constraints for those of you who are familiar with what this means um and as kind of the challenges of doing this efficiently from the pro time perspective there is the first thing shot 2256 hashing this is a a really annoying thing it takes half of our constraints right it's very inefficient to prove shot 2256 unfortunately because of the way Google and other IDC providers sign messages we have to use shot 56 so we cannot throw cck we cannot throw Poseidon at the problem we have to use this hash function so finding more efficient ways to implement this in in in R1 CS is is kind of an open problem uh often times people throw lookup tables at this but that kind of

increases the proof size so what can we do here um another challenge not as big is we're doing string operations to match the email address in this large message that Google signs right and we have to do substring checks and and convert strings to integers and so on all sorts of things and we have to par this sign message by Google which happens to be a Json web token and we have to be kind of careful because when we parse for example the email field we have to parse it at the right depth in the Json it has to be at depth zero not at a higher depth where it can be adversarially controlled so there's some kind of uh you know nitty-gritty ways of doing this in a circuit that would be great to optimize um and and probably other challenges as well but these are the

first three that seem the biggest to me uh so in a future zkp implementation um again the consideration is I would start with this technique is meant to secure user funds so for us a safety oriented DSL like Noir is very very important um the zkps that we generate are verified on so the gas cost is proportional to the verifier time and the and the proof size and so that doesn't leave us with a lot of options it could be gr 16 it could be plank maybe Marlin although the proof size is kind of big there um it's really we just need a new ZK snark scheme this kind of an open research problem uh we're dealing with PRI uh private uh information of users and so

in that sense we'd ideally like to do client side proving um um so we cannot do that when a zvm because zvm is actually a little bit too slow to prove and even if it it is fast enough to prove the prove is kind of too big and then you have to wrap at client side and then it becomes slow again and so once again this opens a great research problem what are efficient ZK snar schemes that are that are fast to prove and efficient to verify and of course this is a in production system we update It We Fix circuit soundness bugs we fix correctness bugs uh we'd like to avoid trusted setups so again that leaves us with a few options on the table plun or Marlin um and and yeah basically what

I'm what I'm here to to kind of ask you to do is look at our relation think about implementing it in R and uh I think it's a great great fascinating thing to to work on in the space um and with that said I want to give acknowledgements to the Aptos keyless team for working on this the broader apos team and geometry research who helped us audit the circuit um if you want some developer resources for keyless as well as access to these slides you can go to my website um I should say there's kind of a shorter url url here that I could have put um and there's a bunch of academic references that I that I am including

here in fact like this approach of signing transactions with your Google account was pioneered as early as 2019 as far as I'm aware in a ethereum research post uh so please take a look at that uh so it's kind of surprising that not more blockchains are doing this so I encourage you to look at it and explore if if it's useful for you uh and yeah that's that thank you so much yeah oh yeah know yeah function perspective right

that's right are you aware yeah so both both sui and Os we both uh I think use circom uh as far as I'm aware that the sui circom implementation is not open source uh it would be great to see kind of what what Avenue they took the in terms of R1 CS constraints I I believe they should be around the same number but it's I don't I don't know if if uh um yeah and also we've taken a slightly different approach uh to be more open source so our prover service is open source our pepper service is open source our circuit is open source and we're trying to get more people to look at this approach and adopt it in their ecosystem because if I think cryptocurrency is to

be in the hands of most people for now not everybody's going to be able to manage their account uh so as as onboarding I see this as a really good tradeoff yeah does this mechm work yeah yeah so the way I've presented it here is as a mechanism to just have an account and sign transactions right but with account abstraction you could do anything you could imagine right so you could have these policies of having like a secret key and a Google account and if you lose your secret key you can use the Google account to rotate but only after some lock up expires and and stuff like that or you could if you if

Google is malicious and tries to rotate your secret key you can use your secret key to undo that you could do all sorts of of things here uh and that's I think what's really kind of exciting about this is that because we've put everything open source you know you could take our code use it on ethereum right in in ethereum's account abstraction yeah um yeah and I guess uh if uh for for those of you who are sort of interested on seeing the the full n to N Flow there's some slides in the appendix that kind of showcase all of the parties involved here you know uh user Google D

Prov Service uh pepper service guardian and kind of all of the messages flying around and um kind of everything fitting in one slide yeah so I hope that's helpful yeah yeah yeah uh yeah it'll work for any open ID connect provider so GitHub um Apple uh Microsoft uh any anybody that supports open ID connect and that's a lot of providers yeah yeah yeah zero for example yeah they use

what right it's an RSA public key yeah yeah so what what this um yeah sorry this public key is an RSA public key and it's published at a URL and it kind of rotates every two weeks but there's no guarantees it could rotate every two hours you just don't know you have to pull it constantly so what we do is we have custom Logic on the UPS validators to reach consensus on this URL so this is kind of really crucial right because if somebody can lie to you about what what what's at that URL that would be bad so you wouldn't want to trust one validator or you wouldn't want to trust one entity to tell you what's at that URL because that entity can take over your users's accounts so what we do

is we rely on the whole appos validator network to agree at what's at at URL are you are you tracking yeah I mean yeah so what we do is whatever public is Google publishes those are the only ones we allow so if it was pk1 pk2 and now it's just pk1 we ignore pk2 any IDC signature with pk2 is useless from our perspective and any zkp of an IDC signature under pk2 is useless right and

you want to do that because you want to follow Google's lead as quickly as possible and potentially prevent uh account theft there's a reason why Google would revoke pk2 right yeah it's it's relevant at the time of transacting uh the way I'm I'm presenting it here it's um every time you transact you wrap oidc signature in a zkp right U it so happens that you only need to do that once and then you can sign with the ephemeral secret key and reuse the same zkp right but at some point that zkp will expire and you'll need to redo it uh because you don't want it to kind of

be indefinite you know stuff does get lost from client devices you do want to give it an expiration date so it's like it could expire and then you TR to um the expiration is orthogonal to the public key issue right it's um independent if the public key has changed then your zkp becomes invalid automatically because the signature is under an expired pup key yeah so then you you would have the good news is though that it's really easy to requery Google for a new signature right and you wrap that and you're done you don't even

have to resign in if that makes sense so for the same message signed under the expired pk2 Google will gladly resign it for you under the new pk2 prime or pk3 right and then you can rewrap that in a zp we're done the user doesn't notice anything yeah yeah there's there's some it's very nice that you're asking this because this kind of brings to the Forefront some you know implementation complexities here it's not exactly um easy to take care of all edge cases yeah yeah how's the expiry of edk is uh

effect and is there any consequences if those Epal public does not expire um good let me start with the last question so the the consequence with the upk not expiring is if the zkp pi is leaked from your device um then and and an attacker also gets its hands on on your es then it has your account right so you want to give it an expiration just like reasonable operational security I would say dictates that you make it expire um now how do we make it expire so the EPK is part of the public input to the zero knowledge proof right um so here when I say EPK I implicitly mean an EPK concatenated with an expiration date so

that means the blockchain validators have access to the expiration date and can check against the current time on chain is it expired so it's pretty straightforward I'm just not showing it too explicitly here to keep things a little bit more digestible yeah yeah okay thank you guys so much cheers than [Applause]