[Music]
hello thanks for the introduction so
today I'm going to talk about uh
vulnerabilities mainly in the
implementation of uh uh snarks or ZK
snarks and also on what can go wrong
when we deploy snarks in production uh
this is a joint work with collaborators
from TM the theum Foundation ZK security
the scroll foundation and also Imperial
College London okay so let's start um
okay what is the state of uh zkp
applications uh today we have ZK rollups
that have become uh very popular in the
last two years they have more than 5
billion USD in uh tvl in them uh we have
Zas which is a payment system system it
was deployed I think the ver version
around 2015 2016 we have many ZK
applications both for infrastructure
such as ZK
Bridges but also for private payments
for um using wallets without having to
use S phrases like ZK login we have
private programmable l1s and l2s like
Mina Alo azdc and also we have some of
chain applications and although all of
those systems have been deployed we
haven't seen any major exploits like uh
the Dow exploit we had in smart
contracts and although we haven't seen
any exploit there have been bugs in
systems deployed uh in production so
zikas had a vulnerability sorry for the
pictures might be a bit small but I will
go through through them so zikas had the
vulnerability for I think more than a
year in it um people from within the
zikas found it and ped it uh then one of
the most popular mixers had a
vulnerability that if someone exploited
uh it could have basically drained the
smart contracts of that
protocol one of the most popular zik
rollups had the major vulnerability that
someone could again potentially could
have exploited and get everything out of
that rollup and also I would say that uh
in audits in z protocols even in
topnotch protocols if you compare it
with top notot uh smart contract
protocols the ratio of critical
vulnerabilities it's even higher so
there are many vulnerabilities and
people for many years suggested that zps
are very difficult and very hard and not
many people uh actually understand them
and also they have suggested that to
exploit a ZK protocol it's much more
difficult to exploit for example is smk
contract uh vulnerability I would say
the first one is not true anymore right
because if you see the number of
presentations in ZK in Devcon this year
and compared with three years ago we
have an exponential increase and also
although it might be true that some ZK
vulnerabilities is difficult to exploit
I would say that some of them are pretty
simple and for example here we have a
circum circuit
it's uh a very old circuit but this
anyone who has written a circum circuit
could probably understand what's going
on here and still there are such
vulnerabilities in Z protocols that I
think are pretty easy to exploit so
there is a huge risk uh if there are
still vulnerabilities in deployed
protocols to be able to exploit them at
some
point okay so uh let's start with uh
explaining what are the properties of a
ZK protocol right we have knowledge
sness which M basically means that a
dishonest Trover cannot convince a
verifier of an invalid statement except
with a negligible probability we have
perfect completeness which means that if
you have a valid statement an approver
will always be able to convince H an
honest verifier of the correctness of
that statement and also we have zero
knowledge which means that the proof
pass
that we produce with a zero knowledge
proof does not reveal anything about the
weakness we are uh
proving so what is our thread model in
uh uh ZK uh word right we have three
adversaries we have the network
adversary who observe the system and its
public values but cannot interact with
the system we have the adversarial user
which basically is able to submit some
inputs for proof generation in a nonest
and non malicious prover and finally we
have the adversary approver which is the
most common uh thread model and it's our
thread model when we actually need the
ZK property right but I would argue that
even if we don't need it if we want to
have a fully permissionless system then
that's the addresser we have and has the
ability to produce proofs and has the
ability basically to do everything to
try to trick the
verifier uh to give you an example of
what I mean with the second category
because it might be a bit confusing
consider ZK rollups at the moment right
where we have a single centralized
trusted um L2 node that is both the
sequencer and the prover so users can
only submit the transactions there and
then that centralized node will produce
a proof so in that case we have an
adversarial user
basically and and what can be the impact
of a vulnerabilities so we might be able
to try to break soundness which means
that aover can convince a verifier of a
false statement and that could result in
basically for example in Zig rollup to
get all the funds out of it we can break
completeness which means that a verifier
cannot verify proofs or basically that
reprover might generate invalid proofs
right and for example such a
vulnerability uh could basically have a
high impact in the liveness of Zur olabs
and we might also break zero knowledge
which means we have some information
leakage um okay so what we did is we
analyzed 141 uh bugs and vulnerabilities
from audit reports for from
vulnerability disclosures and from backt
trackers and our goal was to split those
vulnerabilities in layers and understand
what can go wrong in each layer and also
create a taxonomy of
vulnerabilities so let's start with that
figure so in the real work non snar work
we'll have a relation a specification
some idea that we want to actually
create a zkp about it and we might have
some public and private inputs so the
first uh step is to manually encode that
specification that idea in a circuit and
get the circuit implementation so we
figure out that in that level it's where
most of the level vulnerabilities happen
and the main reason in our understanding
is because it's confusing for most
developers to write circuits because
they have to be to think both about
computation and also about constraints
and they might do a very aggressive
optimizations there and they might try
to apply some trigs and that typically
leads to vulnerabilities so we
identified three main vulnerabilities
under constraint vulnerabilities which
means that uh you forgot some constrains
or some of your variables are partially
constrained we might have and that
typically leads to soundness
vulnerabilities which is the worst
vulnerability can happen in Z in the Z
system then we have over constraint
vulnerabilities which is the exact
opposite that most typically will lead
to completeness issues and we also have
comput or hint errors which is on just
on the computation part and accordingly
you might have messed up constraints but
the root cause was in the computation
part um so we did a complete root cause
analysis and I will share with you uh a
QR code for our paper to look into
examples and to look on how you can fix
some of those vulnerabilities Etc but
very briefly here we have categorized
them in three main root cause classes
first is that in When developing
circuits we have a different programming
model and that could lead to many
vulnerabilities secondly we observed
that the root cause of vulnerabilities
were optimizations and also having
cryptography at the outer layer and in
very uh lowlevel dsls that could
introduce many vulnerabilities and also
common errors like in any software
uh like uh specification issues or API
misuses
Etc so the next layer is uh the front
end uh which is basically composed from
uh two components a compiler and a
witness generator the compiler will take
the circuit and will try to produce an
intermediate representation that it's on
what our proof system works on top for
example R1 Cs and then witness gener
generator will take the circuit will
take the public and the private
variables we have and it will produce a
witness and the next one is a backend
the backend is composed of three main
functions setup proving and uh
verification and things can go wrong in
all those functions so the
vulnerabilities we identified here in
the front end is incorrect constraint
compilation and errors in witness
generation and in the previous
presentation we saw how things can go
bad uh there and it's very critical to
actually trust and be able to H have um
correct implementations of front ends
and in the back end the situation is
quite similar um we from our data we
found out that UNS safe verifier it's a
very common issue and can lead to Major
vulnerabilities um and let's go to the
next one the next one and the last one
is the integration layer which is
basically you can think of it in the
blockchain space as the JavaScript that
is responsible to run your prover client
side and create a proof and also the
smart contract that um consumes that uh
proof and calls the verifier you have
implemented or it was produced
automatically and try to do some things
and we have some very interesting
vulnerabilities in uh that layer I want
to focus in the first one which is
passing unchecked data uh and what does
that mean sometimes as already H said we
might try to do some optimizations in
the circuits and for example one thing
that it's pretty common is for people to
say okay uh in that circuit let's have
some implicit assumptions that our
inputs are in a specific range and then
the delegate that check to the actual
code that will call the verifier so in
that example we forgot we forgot to do H
such a check and that could lead to
Major vulnerabilities then in our
infrastructure and uh in the last uh
year or so there has been a major change
in some architectures where instead of
circuits we have zvm circuits right so
the developers now only care about
writing some program typical in a high
level language like rust and then
compile that program and uh giving it as
an input to zvm still circuit bugs can
happen in the zvm itself and I would say
a suppled uh new thread here is
traditional compilation errors that
might happen to the rust compiler for
example that that could lead to have
invalid proofs so that's something that
people should take into consideration
when using uh zvm
Souls so another way to see what we
currently uh described is in a
hierarchal uh way and here I have an
example of all the stack uh when we use
uh the programming languages and
snack J with growth 16 Azure proof
system I have two new layers here one is
fil arithmetic elliptic ear which have
nothing nothing to do with ZK but when
we construct and Implement um a proof
system we have to have such a very
efficient library and things can go
wrong there and also things can go wrong
in the hardware in the operating system
in the blockchain we are using right so
you should always um
be very
uh basically think about what you're are
going to use and apply all traditional
best security practices
we know from other
fields and one last thing is that in the
proof system there could be errors there
that could be errors in the initial
description in the papers of proof
systems so if something goes wrong there
it doesn't matter if you have formally
verified uh circum circuits if you have
the best back end or front end it could
be exploitable and that basically it's
true for any layer so if your front end
or the back end it's uh vulnerable then
even if you have formally verify uh your
circuits they could be
exploitable okay uh so we did that
analysis and now I want to present some
of the results uh so we categorize the
bugs in uh all those layers and also
based on their impacts and we can see
that circuits was uh the number one uh
threat in the whole infrastructure of
using uh
zkps and also most of the
vulnerabilities
are res can result in soundness
issues so what can we do uh fortunately
there has been like a lot of development
and a lot of research of uh creating uh
security tools for ZK circuits
for specifically for ZK VMS or ZK EVMS
and also in the last month two new
papers were published and tools circus
which was presented in the previous um
talk and also MTZ K which is great
because such novel tools can detect
infrastructure bugs uh in circuits in uh
zkps but I would say there are still
still a lot of work that needs to be
done uh for example most of the circuit
tools they target a specific DSL
and also they typically Target a
specific uh vulnerability class and then
we have uh some tools like static analys
tools like circum spect which might have
tons of U false positives and then we
have some really nice tools and very
novel tools like pus that try to
formally verify and find any under
constraint issues in the circuits but
unfort fortunately uh th those tools do
not scale that well uh so there's a lot
of uh space to do to have Innovation uh
and try to build better tools and uh
here I have a list of um security tools
you can scar that QR code and it's
basically GitHub repository if I don't
have any of the tools that you are know
of please add them and yeah we need to
do a better job here and one also major
issue I see in the space is that we
don't have good uh tools for writing
tests and most of the code base that us
your knowledge proes are unfortunately
not that uh good in having like a
complete test Suites and try to to
understand in the testing uh part both
uh soundness and completeness
issues okay so in conclusion why do we
have bugs well one of the reasons is
that because zkps are not just mods
there are implementations and many
things can go wrong in those
implementations uh why
else H this is a quote from Ron rivest
in a completely uh different context but
I really like it and I would say that in
the ZK space unfortunately we have give
to the poor developer uh enough rope
with which to hun himself circuit
languages are are typically very low
level so they don't have good
abstractions for developers to write U
uh safe code uh we expose a lot of
cryptography to the outo layers and also
there is a lot of complexity and a
different uh threat model than what uh
developers are used
to and there is a lack of specification
throughout um the whole uh uh
infrastructure and
the whole stack for using zkps so we
need to write more
specifications so what can we do
basically we have to negate everything
from the previous slide we need more
learning resources which I think we are
doing a great job in that as a community
uh we need to write specifications and
get used to write specifications because
uh if we have complete specification
then we know exactly what checks we
should put uh in each uh layer and what
vulnerabilities can happen in each layer
and that's how we can help developers
but also Auditors into doing a better uh
job in trying to find vulnerabilities uh
in those systems we need easier and more
secure programming languages which I
think it's kind of where we are heading
to uh for example Noir is a is a great
language that it's much more safer than
writing uh circuits in ccom or hello2
but in some cases people will still need
to write circuits in hello2 or ccom
because they need to do some specific
optimizations or they need to deploy to
specific uh uh blockchains for example
and then we need the better testing and
security tooling from simple Frameworks
to write unit test to do property based
testing to formal verification and not
just formal
verification uh so that's it I have
there a link with our paper where you
can find many examples and how to try to
avoid some of those pitfalls and we also
have a blog post that uh uh we uh
publish many blogs about uh ZK Security
in general so thanks a
lot thank you Stefanos this was
enlightening um all right people as
usual you can ask your questions here
we're going to go through them in order
and let's take the first one several
times in your slides you refer to
Witnesses what are witnesses are those
private inputs uh so a witness I would
say it's composed from both the private
inputs the public inputs and all the
intermediate steps and the outputs for
our circuit so I will say it's a a trace
that then we create a proof about that
Trace thank you all right all right next
next question I've put a bunch of those
so do ask serious questions please we
have a bit of time what is your favorite
bug ever what is the most interesting
bug you've ever found H that's a very
good question I think I can't pick one
uh but I would say typically the simple
bugs right uh for example the bug I have
in one of the first lights that could
have lead to basically draining uh one
of the major mixers we have in the space
um but also bugs that have to do with
using cryptography in the circuits and
typically due to some optimizations or
some logic errors in those circuits
there could be like pretty interesting
exploits that someone can do pretty cool
thank you all right the next one you're
doing research looking for bugs you're
paying your bills and buying your Foods
by finding bugs can we consider you have
a bug based
diet we can consider that yeah
definitely I hope that in some future
world there won't be that many bugs and
maybe I will have a better diet but
unfortunately at the moment we have tons
of bugs fantastic thank you what are
your thoughts on T okay that's the
question of Dev conal everyone asking
that question uh I would say it's a
different you have different security
assumptions when you use tees right it's
I think it can work a along with the GPS
but they can't replace GPS H you have a
much weaker uh thread model when you are
working with tees so yeah people should
use them when they have to use them but
also don't trust them like a black box
that will do everything for you and you
are secure if you use a te wonderful
thank you um what can we do to make more
secure languages like Noir faster
compared to circum particularly with
respect to gas cost how do we make more
how do we make it more efficient SO gas
cost I have I will say that it's uh
independent kind of of uh what
programming language you you're using
it's more about like what proof system
you are using right and if that proof
system is has very efficient
verification that's the main factor but
also more General in the circuit uh
layer um I would say that indeed someone
if you don't like really use unsafe inir
which then breaks the whole purpose of
using Noir um you can write more
optimized ciruits at that point in
circum but I would hope that we will
have uh uh major advances in compilers
for zkps and then we can have like
compiler optimizations that very strong
like in any other field
and uh rely on those optimizations to
get like pretty optimized uh circuits
but if we do that then we need very very
solid uh testing for our compilers to
detect any issues in those
optimizations thank you you mentioned in
your slide that you know sometimes we
give too much rope to the users to
angang themselves with I think the
design in ZK circuits is difficult but
also using them is not very common place
right a lot of users are not used to
using this kind of systems and what goes
in what goes out what you can do with
them what can be what is safe Behavior
to do that you mentioned learning
resources do you think there's something
to do with users also to explain to them
what are the benefits and what should be
done or is it entirely on the app
developer yeah yeah that's a great
question I think as researchers it's our
responsibility uh to create uh learning
resources that are easy to follow by
almost everyone
uh so I think we are doing kind of a
good job there uh for example at ziki
security we published a book on hello 2
and basically many teams in that space
develop a pretty nice learning resources
and what I really like is that they also
have a section about security
vulnerabilities and what you should look
at when you use a specific DSL so yeah I
think we are doing a great job on that
and in the few years it will be even
better fantastic stanos thank you we're
over time uh so thank you for your talk
thank you thanks a lot