Security Summit 🦺 Securing Zero-Knowledge Implementations: A Guide to Identifying Vulnerabilities

[Music] I'm Peter and I founded aario we're working with Zs with uh my partner Le mikov he is also today will help you guys to build the secure ZK uh circuits if you would like to participate there is a great uh sponsors like scroll and poly polygon and attec all of them are working on Z and this is where you uh field uh and so uh many typical mistakes people uh always repeating with their code we are here to help you to understand how we can um mitigate these things and what is the what the basic things and how we can um protect your code from attacks so we will start we will introduce you like seven most common things like basic attack vectors and how to protect them and also bring you some real wor examples of U the errors and attacks that was happened uh in ZK field uh okay I would like to start and I think I will give a talk to left we will start from our first most basic thing most like basic attack that you can see that every beginners happens because ZK uh circuits they very different from original for solidity or other things the first uh type of vulnerability is under constrainted and non-deterministic circuits we have merge them uh into one type just because uh those two uh types and non-deterministic circuits uh in vast majority of cases is simply under constraint circuits um that additionally involve uh the break of determinism principle so we we have decided to merge them um so I just cannot operate oh yeah I can move it so uh to understand uh that vulnerability first of all let's define what what are constraints in ZK circuits uh circuits uh are generally just a bunch of mathematical checks uh that uh are packed into mathematical equations that are stored in Air1 CS file so and if prover passes all of them uh for programming just means that he knows uh the secret witness and then he can uh produce a correct a valid proof for that witness uh if there are not enough constraints uh it just means that there are multiple ways to generate proof it means that we can produce several uh nullifiers and then uh the logic and uh the actions of our Pro of our malicious Prov will be unaccepted to us and uh it means that just our circuit is vulnerable so uh and also we have to possess that uh if our circuit is the constraint it just means that we cannot provide our users with the guarantee uh that our proof is legitimate and our soundness principle is broken um let's move deeper uh to understand that uh let's see the the following code example uh as you see it's just the template that takes three uh signals the first uh two are just Factor inputs in Factor one and Factor two and our program just checks that the product of those uh two uh signals is equal to our public um public signal Val and uh guys this question is to you uh how do you think how many uh problem problems here and uh you have the ability to watch that by yourself and write it into the chat while I'm going to uh explain that uh so there are three core problems here uh first is that our template doesn't check uh uh the the factors are not equal to one the second problem is that uh it doesn't check that the value of multipliers is positive uh and the third one is that uh the pro the product of factors is less than uh the order of the finite field which which is the typical um uh the typical example of wound effect so we will uh talk about that uh in in the near future so you can yeah you can see it here so if our field order is 100 and our Val is 10 we can uh just if we are malicious Pro we can just provide 10 and 11 we will get uh 110 which is more than the field order and then uh we will uh have the ability to create a malicious uh proof that will be valid so and also uh we have some part of the example of under constraint circuit uh so if our public param parameter uh p is uh 10 is nine so uh there are four uh cases in which uh we can create a valid proof so minus 3 3 1 and minus one uh all those inputs will be correct for our under concentrated circuit but of course um determinism says that uh we can create only one uh valid proof for one secret witness so our proof uh just our proven system just have some backs as you see yeah we have already watch this the second one is arithmetic overflows and underflows it's quite basic so it's just about when incomparable inputs are used together and we will see that uh first of all uh we have to uh possess that the this vulnerability cures uh due to the mathematics behind Prime finite Fields as you may know um it is all about linear algebra and model modu arithmetics so uh and to first of all let's understand what are prime finite Fields it's just algebraic fields that allows us to to perform addition and multiplication modu p on the on the set of elements that are constrained by from zero to P minus one so and overflow occur when when the result exceeds upper upper bound and underflow uh performs when the result is outside of the laow bounds so the classic example of that vulnerability is Sima 4 Double spending vulnerability which was conducted byan simov yeah pet and this is a real example of um like our friend that found that there are so many uh libraries that work with ZK are uh vulnerable for double spend and this happens because in solidity you you use feeli like power 256 and most of uh ZK circuits work on the BM 254 and when you just Port um numbers to the circuits you just get classical um overflow issue and this bug affected by like more than 10 uh working uh uh projects at that time so it happens in 2019 yeah and and we want to describe this example very briefly so how how it works pretty straightforward you just get uh uh where big number and get o o overflow and uh when you check the balance you can easily uh find the two witnesses that will give you the correct example so you can use it for double spend um so the next one um is um I don't think we will go into the deep details here so I think we can skip like to the basic thing you can check the Kobe F uh fix it quite quickly in uh ziky drops and circum was affected everything was fixed and luckily nobody was affected by this issue but this is classical overflow that really uh principle thing things that you have to worry there okay the next one is me sming bit length so also like you always work with a uh beat and bat masks uh in circus and it's very easy to just uh just found that you can skip some check inside and if you will give uh signal with the more bits that is assumed uh to be calculated inside that then you can get the mistake that uh uh give you wrong uh output maybe left you can give some more examples here yeah on the slide you just can see the classic attex scenario when we have uh an input zero that is uh that has a length of three in binary and nine which is four uh bit length in in binary so and we have a mismatch here so in at in in the result of processing we just can see that um it our one is more than nine which is of course is back so it so that's the classic example of that attack yeah and the mitigation Str strategic is just to use num to bits included components uh you just wrap them and constraint constrain out your inputs using that and then you give that those inputs into our less than vulnerable program and all works fine because we then just in ensure that our input is less than input less than the second input so all works okay and that's simple the next one is not quite uh but uh it's not obvious one it's happens with unused public inputs uh if you use uh signals and public signals that you will not use uh it could be optimized but uh and uh the from in the beginning it looks like it's not a problem but uh for example if you use and your your proof should be unique it can cuse [Music] some wrong assumptions for because um malicious person can give you different kind of signals for in this example like signal three can be any any kind of signal and if he provide input one and input two which is correct he can use any public input three for example in SEMA for uh it for example the next slide is attack scenario in Sea 4 when you use ZK for sending anonymous messages uh malicious person can generate as many proofs as he want with the different kind of messages yeah with the same basic inputs so that's the problem and uh the core mitigation strategy is just to use uh those variables in some logic in some mock logic that are not in demand uh but we declare our uh using uh variables and the all is fine Optimizer doesn't ignore that so all works okay MH okay we have last two minutes and let's go like very briefly uh the frozen heart is a general um name for uh set of the errors that uh company the trail of Beats is you can check the Z docs links and there are so many problems happened with them um for example with the broken of soundness and it's also related with trust setup leak I think we will talk together uh because of a very common thing and that happens in 2019 with Zach initial ceremony because of uh incorrect operations with toxic waste and different kind of parameters there was uh interconnected with each other so so but it should be independent but lately the uh researchers from zash found that you can recover uh the toxic waste and you can uh generate the proofs and you can emit as much money as you want luckily they uh fix it in next update and nobody affected um so we will skip the trust setup mechanism so because of lack of time I will tell you about we can just and U about uh but just uh check that you use uh standard libraries and uh use some basic things don't try to write your own cryptography this is the most important thing and the last one is just uh very minor thing looks like sometimes coders uh misplace uh constraints in variables so sometimes you think that you put more constraints and check some variables but actually you didn't it uh you can find it in many circuits these kind of problems and the IT CS the potential malfunction of your programs so here is example um they very basic example you can check uh how it works left do you want to add something there or no it's quite basic I guess we can skip that yeah okay so this is the end it's time to hack in conclusion I just want to say like programming of znar is not the typical programming check how fin primate Field Works check um more how you have to build these constraints because there are so many things that works completely different in circuits uh rather than in normal uh solidity programming on other languages we will uh here to help you we show you the seven common bux at pitfalls of course there are much more but this is the basic things like uh same as in solidity like double spans everyone have to know about this you have to know about these basic things and we're to here to help if you want to build uh circus feel free to contact us happy hacking guys and uh I hope you will be fine and safe if you need any advice feel free to ask me or my team ex where very welcome to help with the Consulting AUD thiss and just to help new hackers to dive into this field yeah so feel free to check our blog we have a lot of uh research papers there and happy hacking thanks