ZK7: Security of ZKP projects: same but different - JP Aumasson - Taurus

Transcript

[Music] so i want to introduce jp omason yes uh who's going to be talking about the security of zkp projects same but different please take it away thank you anna hello hello summit um it's my first submit so i'm a bit intimidated but i i kind of like the event it's quite different from the usual you know pure security hacking events so like anna said that's the official talk the official title of my talk the unofficial title is should you pay for security audits i don't mean to offend the people who

the security audits are doing all this myself so that's pretty much why i'm here today um and it's based on my experience so doing security ideas for ck projects uh in the last few years and before that i've done been doing a lot of security instead of crypto audits and i can tell you that's very different uh and i even found approaching zk projects more difficult uh and more confusing than contact systems such as mpc tss racial signing even though it's with threshold signing you have quite complex notions you either you have the interactivity to handle but getting rid of the interactivity somehow

makes things more complicated so i was confused i was frustrated i was frustrated not to found not to find more bugs than i expected i was like oh i suck uh i do a job and i ended up developing a kind of new methodology and trying to understand why i was so frustrated um so that's the talk so generally why do we need to study zika security so it's not just about security on paper security proof soundness completeness dkns sdks it's about real-world security so to speak so of course for the projects using zk snarks well if you don't have sdk security then well that's quite kind of pointless and there's a lot of

value a lot of money at stake and a lot of reputation at stake so it's important for you but it's not important for me uh what is cool for me as a cryptographer is that i've been doing crypto for 15 years and when i told this some people are like more than crypto before bitcoin i was like yes uh cryptography and i have seen a whole lot of different applications of crypto in my life uh open stuff non-open stuff and i find what we're talking about today by far the most interesting because it's that's intellectually challenging it's non-trivial uh there are many moving parts you have subcomponents as complex as polynomial commitments and all this stuff is

uh subject to papers relatively well written to code and it's deployed at scale and if it fails it's a disaster and i've yeah but rarely seen this uh in crypto and that's what also a bit you know annoying as an auditor because i think like david was commenting before what you implement is rarely exactly the same logic as in the paper so that's why i love his project gargoyle specs so what does it mean zk is not security in practice so it depends a lot on the application it depends on what are your assets uh beat your transaction data uh your user privacy it depends on how you're using your pro system

it depends on your private inputs your public inputs but i tried to find some common denominators so i find that soundness that might be obvious to everyone but it was not to me initially souness is oftentimes the highest risk in practice because if you accept invalid proofs then well again you have a little problem and it's the most obvious attack vector so it's not just about complete forgery it's about malleability of proofs and it's about replay of proofs so hashtag not for example then we have zero knowledge so the zk but if you have a constant size proof you have only so much space to leak data

and i've often found some big difference between a failure to be zika on paper and an actual exploitation of zika in practice so i've seen situations where uh people were telling me oh yeah we need this blinding coefficients because otherwise the proof doesn't work i'm like okay but without it how can you exploit it like not sure but yeah so as a security guy i find this a bit weird that you you know i've seen many cryptographic designs that were over designed uh by the designers because they wanted to make their life easier when writing the security proof and i have the feeling that it's a bit the same situation um with zika pro sometimes so

completeness it seems to be the easiest to achieve and the least annoying if you fail but i'm pretty sure there are situations where if you fail at completeness then you are in in quite big trouble so who's finding the bugs um different types of people type to put the main categories here so oftentimes it's the people who know the code the best so the people who write the code people who review the code in the organization people who run the test and so on sometimes it's also people from other projects concurrent projects who might reuse the code from the code or just look the code for inspiration and sometimes it's also external auditors who get hired and paid by the

projects and you have dne so it might be the users that's when it's too late to deploy something in production and accidentally or maliciously people find and may exploit some some bugs and vulnerabilities so your goal if you're in project like i don't know i don't want to give the names but all the sponsors that you can see here your goal is to make sure that the abc guys will find the bugs before d and e uh and what's the biggest challenge when you're a security auditor so you have limited experience because it's relatively new nobody has 10 years of experience in plank you have limited knowledge if you're general journalist doing many security audits

you have most likely not spend as much time studying zika proofs as people who wrote the code and you don't have a body of knowledge a corpus of bugs that you can refer to as a checklist there's very few documentation about this and you have limited tooling limited methodologies limited write-ups online so you have to use your brain which is hard from some people and the documentation so oftentimes i would ask the clients okay what's your documentation ah we have some documentation yeah cool but it's completely outdated oh and there's very little documentation that is purely about security purely about threat modeling about attack vectors it's documentation about maybe

how to use the code what the code do is doing but not in terms of you know security requirements and security goals and maybe because it's obvious for these guys i don't want to blame them so what i found to work and what i've tried to do differently for this type of project is to do more interactive collaboration with the developers so have more discussions organize occasional calls uh house them with questions on slack why do you do this this way what does that mean i don't understand this part please explain it to me this kind of thing and i also tried to do the threat model myself uh trying to understand what was the main

value what were the main assets in the application that i was looking at what are the attack vectors what are the capabilities of an attacker what you do in any in any security engineering project normally uh and your experience so i say you don't learn by reading you learn by doing so try to do stuff myself write some code write my own circuits try to play with uh for example the cargo language the legal language the ziki heart challenges this kind of stuff and i did a whole work of let's say archaeology trying to find the public information about the the bugs so it's not just about looking for write-ups but try to dig into the github issues the github prs and see what

patch qualifies as fixing a security packet so to give you a general id if you break down if you do the usual breakdown in terms of computation down to integration in the application there are 10 000 ways to fail uh if your computation if your program is not secure in the first place then no matter how good is your proof it's not going to turn your insecure program into a secure one if you use an insecure cipher it's not going to become a secure cipher if your circuit is not equivalent to the programmer then again you have a problem it doesn't depend on the proof itself and if your constraint system is built in a way that it will fail to enforce certain constraints certain types of constraint even if your program is safe then again it might break soundness completely

and in your proof system where you have multiple moving parts you want to make sure that you have a good chance of printing primitives parameters and a kind of consistency across the components so if you are shooting for 256-bit security you want to make sure that you have 256-bit security across the board well most of the time you have 208-b security anyway and then even if all this stuff is secure and safe then how do you use it in your application how do you generate the keys how do you pick the nonsense this kind of stuff so how to break zika snarks so you can break sourness obviously that's quite obvious to you you can break your knowledge i've seen cases for example if you treat data that is private as public in some

way then it might leak information of course at the application level as i will discuss later you can imagine scenarios whereby usage patterns might leak data might leak information on the data that is protected even though it's zika on paper and and completeness so there are also quite a few ways to fill out completeness but most let's say more precisely it's not just about these three notions because ultimately you write software and software has bugs uh even if it's in rust even if it's in okaml and you have different ways to write code you have like moxie says you can

optimize for writeability you can optimize for readability as an auditor i prefer the code that is optimized for readability that is commented and that use variables with names that that make sense so you can have software dependent bugs you can have things like buffer overflows even in rest you can have stationary timing attacks which may or may not be exploitable and you can enter in some insecure state that can just you know jeopardize the security uh because it might be locked into an insecure state uh and then all this supply chain what we call supply chain uh security these days so in short dependencies platform your ci pipeline your review pipeline so all the

boring stuff which is super important and last but not least the on-chain situation so i heard that some smart contracts were found to have bugs last week yeah this happens too so i put a pyramid i have a friend who loves pyramids so i put a pyramid i hope you you like it and i try to understand let's say i tried to break down the proof system in different parts in terms of what security notion could be impacted and when i audit something i also try to identify what are the attack vectors what can be completely manipulated by an attacker what cannot or what can partially be influenced by an attacker

most of the time most of these zk failures would be at the application level it doesn't mean it cannot happen underneath but it's in my experience mostly at the application level and whereas soundness and completeness are more about the prover itself and what is uh underneath so all the way from the the platform security uh from the os you're using to the arithmetic the elective charadomatic the field arithmetic and the actual uh prover that combines the primitives that you're using so speaking of primitives it's an example of all the components you might have in something like maybe splunk or marlin so hash functions

algebraic hash functions prf's marks commitments it's crazy to me when i looked at this i'm like man the goal of these guys was to put all the possible crypto primitives that exist and do something of this i mean well you could argue that people like stock that do pretty much everything with only hash functions but it doesn't mean that it's simple or easy to review so you're quite different components quite different security notions and if for example you have some polynomial commitment being used that's supposed to be binding and or hiding and you see that some place it's not completely hiding or biting you're like oh that's a problem and then you think about okay how can i exploit it does not

occur and so maybe i know too little about zika approach but oftentimes it was not trivial to me how to exploit um a problem in one subcomponent but this should still be reported as a problem to be to be fixed um another problem that is common in all software development is the contract between uh different components between functions and their colors and their colleagues uh well maybe the the poster style of this is a how where do you verify that the scala you receive lies in the the right range um there are multiple ways to do it i've seen many recent projects doing it in very interesting ways for example you

can enforce that this is under well below the order of the group that it is non-zero but i've also seen some horror stories along these lines so as a developer i think you need to make it clear which component is responsible of checking the sanity of whatever value you receive especially attacker control value and it doesn't hurt to do the same check twice or thrice okay i rushed a bit because i only have so much time and i want to go through this collection of bugs um because some people collect nfts and i collect bugs and decay proof systems and i don't make enfts of this maybe i should but

um so this is the favorite uh class of my my friend kobe um and he helped me find some of these uh so this is maybe you're familiar with this kind of bug you receive a scalar so in that case a nullifier and they should be unique per payment per sheeted payment but if it's bigger than the order of the group then you can have different numbers that reduce modulo down to the same value so something non-unique becomes unique and when you check that it's non-unique it's oh it's fine it's not unique but then it becomes the same so it results in a in double spend another case uh in another project about

the same about the same situation so found by kobe another one this one not not a nullifier so again in a different project i think it was a public public input another one another public input i think you understand the point you know the point um so this one is in an r1cs constraint system it was in the rest and the artworks uh the rust artworks uh r1cs software and it was failing to enforce that one element was the inverse of of another um and this could have directly been used in manual sending to to forge proofs because you just took

the numbers and one is not inverse whereas it's supposed to be and then it's validated um so but by this i don't i don't mean to say oh look at these videos they wrote this bug no my point is just to say look the kind of bugs you can have and if all these smart people write the code with these bugs it tells you a lot about the complexity of the of these systems so this one was a funny one it was not really in the hash function it was in the verification of the of the hash so instead of using the equal operator it was using this which is not equal so it was not checking equality

and yeah so just two characters and complete disaster um yeah it was internal cache i guess um so this is the famous bug in uh that ariel gabison found in indycarch a few years ago and interestingly uh so back then ariel was working for zcash so again it also suggests that people who know the bezel code that the most qualified to find these very subtle very complex bugs and it was actually a problem in the paper itself so that they implemented what was in the paper but the paper was not completely safe so this happens as well another case a recent one so there was a

very nice series of write-ups from turtlebeats where they found several occurrences where the fiat shamir hushing of the transcript of the proof was not including all the public variables i think it applied to uh to plonk to the geoproof system and bulletproofs so some implementations of this not the system themselves of course and in one case for bullet proofs it was also a shortcoming of the paper the paper was not describing all the stuff you had to to fiat charmian to to be secure so long story short if you have in your fiat chemical should put as much as you can it doesn't hurt much i don't think it hurts to put too much um this one was a documentation or

writer by an aztec i think in the context of their internal audits so it in that case was a mishandling of the nonsense they were not using the right type of notes in their um in a payment in the encrypted notes specifically and privacy went by was impacted so it was a buggy and of zero knowledge that from my perspective can be seen as a bug in the application because it's not in the proof system it's how you choose the inputs that you give to the proof system uh this very nice one very nice quark by uh camera bonnet and paterson so maybe you're familiar with this was a few years ago uh these were

yeah timing attacks so side channel attacks on zcash and monroe so that again did not contract it contradict the security claims of the paper but that exploited some that's a real world artifact piece of information correlations to leak data on some secret values and they were also using timing leaks to get oracle so an oracle is just something that you interact with and that tells you something that you don't know it might be a secret value or it might be whether some some stuff is valid or not or if some decrypted message has

some specific pattern and i think they have three or four different types of attacks very very interesting it's a nice paper i recommend that you deteriorate it um this one in blank up again so yeah that's maybe one case where i was a bit confused uh i mean the people who know plonk much better than me they probably have the answer but blinding factors were missing the randomizers and i was like okay so you don't get full zkns here and i think like adrian explained to me that it's not very clear but still not clear to me um so this one case i was talking about cairo with someone before um i know very about cairo so one day i just opened the

code i'm like okay this open source oh cool oh it's python and um the only stuff i know is crypto so i look at the crypto i looked at signature and i i found what i think is a bug in the signature system but maybe maybe i'm just missing something so i don't know if there's someone from cairo in the room or someone who knows carol well i would be happy to discuss this i i created the github issue and i don't think anyone responded at this point okay um so yeah just to conclude that now what's the time situation ah looks okay one minute perfect okay um so surprisingly i've been frustrated not only not to find many bugs myself but not to see

more bugs being found maybe just because it's written in russ or maybe because people are so smart that would be great news as well um so yeah maybe it's because people have been developing robust uh frameworks from the beginning projects like i don't know like like what zika is doing like bellman like the artwork suite of projects uh there's also many efforts to make it easier to write safe code for example the diamond specific languages carol leon wires link and others and gadgets or chips that other projects can reuse so if something has been let's say battle tested so to speak it might make sense to reuse it in your own project and also in practice when you look at how the proof systems are used

there's very little attack surface for an attacker it's not like an apache server that will receive whatever you send it uh in practice you cannot control much information as an attacker which is a good thing so why being scared uh well scale is maybe a big word but uh i tend to believe that we are still in a relatively well immature state i mean we haven't had this pro system for years and i wouldn't be surprised if one day we discover a big class of bugs that impacts like all the plonk and variants across the board and it's a complete disaster i hope it doesn't happen but i will not

be surprised because we have very very shortage of tooling and i mean no offense to the project but the way people think about security you know what you learn at security school is that the first thing you should do when you start a project it is to set out the security requirements uh what you want to achieve in terms of security rather than do it uh exposed so to speak rather than doing security after the fact uh i don't think we will ever learn this uh but that's fine that's that's how it is also the more many many more people are coming to the zk summit many more projects are being created many more let's say

assets depend on zika pro security so there will just be economic incentives for attackers to invest in breaking these systems and maybe to withhold the the bugs they found so to conclude um okay i'm concluding uh i think we need more because you need to conclude with open questions and messages for the next generations so we need more testing more fuzzing i've seen very little fuzzing i know that um guido franken did some i believe but we needed more smartphones and furthering specific to the api uh again i mentioned the project from the project from from david and also we need more write-ups like trailer bits data which i think is very useful for many people and last but maybe not least maybe we can use insights from the

people from the field of you know hardware engineering where you you have a high level language so a very log of vhdl and you transform it into a netlist which is essentially a circuit and they have a whole body of literature about testing bugs uh tooling associated to this so i wonder if we can reuse some of their ids experience and tools to improve the state of zika proofs thank you very much [Applause] [Music] [Applause] so i do think i think we could do one question we are kind of catching up right now but yes let's do one question hi uh thank you stanford for great talk

actually just want to add a bit of information to your slides where you describe this kind of soundness and completeness things that that could be missing i think one important uh also aspect kind of part of the security that are interesting for us in uh zero knowledge aspect is availability the thing is uh zero knowledge proofs are often used to transit a state from one uh well from one state to another state and we produce we provide the proof that the transition is correct but the thing is in order to produce further proofs we must know what the state is and we must the data that

needed to reconstruct the state must be available and some bugs that we did find in in real applications is that some data is not really provided so the proofs are correct uh everything is complete everything is sound but uh the data is incomplete so that in the worst case uh it might not be possible to reconstruct the state in the variant yeah it makes a lot of sense there good point imagery thank you cool well thank you so much for the talk okay [Applause]