1 of 34

Zero Knowledge VM Hijinks

Dean Pierce

@deanpierce

​

Hushcon 2023

2 of 34

$ whoami

  • Current Polygon Labs - Appsec, focus on ZkEVM
  • Previously Red Team / Pentest
  • Previously Solidity auditing at ConsenSys
  • Previously a bunch of Intel stuff

​

  • Offensive Security Research
    • Make crime economically uninteresting
  • No PhD, just into weird stuff
  • Not speaking on behalf of company today
  • Expect a lot of wacky half-baked ideas

3 of 34

WTF are Zero Knowledge Virtual Machines?

  • Two actors, the Prover and the Verifier
  • Prover runs an arbitrary program in a ZkVM with arbitrary inputs and outputs, some of which might be private, which generates a "receipt" proving that execution was performed correctly.
  • Verifier inspects the "receipt" and confirms that execution was legit without needing to know any private inputs or outputs.
  • Programs take a longer time to execute in a zkVM, but verifier knows for certain* that the program executed exactly the way it says it did.

* more about this in Part 4

4 of 34

Part 1 : ZK History

  • Zero Knowledge Proofs
  • Zero Knowledge Gadgets
  • Zero Knowledge Circuits
  • Zero Knowledge Virtual Machines

​

(things are about to get really handwavy)

5 of 34

Cave of Ali Baba

Victor and Peggy play in caves.

​

​

​

​

How to Explain Zero-Knowledge Protocols to Your Children (1990)

(interactive)

6 of 34

ZK Gadgets

​

​

​

​

​

​

​

​

(from Cathie Yun's SBC'19 talk)

7 of 34

ZK Circuits

​

​

​

​

​

​

​

​

(from Cathie Yun's SBC'19 talk)

8 of 34

ZK Circuits

  • CIRCOM
  • Zk Verilog?

9 of 34

ZK Virtual Machines (Polygon ZkEVM)

​

​

​

​

​

​

​

​

10 of 34

ZK Virtual Machines (Polygon ZkEVM)

​

​

​

​

​

​

​

All still just polynomials multiplied by massive prime fields.

11 of 34

ZK Virtual Machines (RiscZero)

12 of 34

ZK Virtual Machines (RiscZero)

13 of 34

Part 2 : ZK Applications

  • ZK Identity
    • Prove you possess credentials with certain properties without disclosing them
  • Tornado.cash
    • prove that you've made a deposit and never a withdrawal
  • Dark Forest (zkga.me)
    • ZK MMO
    • ZK Perlin noise generator = decentralized "fog of war"
  • ZKML
    • prove that a given response was run through expected models
  • Blockchain scaling
    • no need to verify transactions individually (ZkEVM)
    • basically unlimited scaling
  • Governance
    • voting mechanisms with arbitrary privacy and transparency properties
  • Proof of Exploitability
    • prove I have a bug in software X without disclosing information
    • automated triage / private bug markets

14 of 34

Part 2 : ZK Applications

  • ZK Identity
    • Prove you possess credentials with certain properties without disclosing them
  • Tornado.cash
    • prove that you've made a deposit and never a withdrawal
  • Dark Forest (zkga.me)
    • ZK MMO
    • ZK Perlin noise generator = decentralized "fog of war"
  • ZKML
    • prove that a given response was run through expected models
  • Blockchain scaling
    • no need to verify transactions individually (ZkEVM)
    • basically unlimited scaling
  • Governance
    • voting mechanisms with arbitrary privacy and transparency properties
  • Proof of Exploitability <------ !!!!
    • prove I have a bug in software X without disclosing information
    • automated triage / private bug markets

15 of 34

ZK Identity

  • Holder
  • Issuer
  • Verifier

​

  • Verifiable Credentials
    • selective disclosures

​

  • UniRep also cool

16 of 34

Tornado.cash

17 of 34

Dark Forest (zkga.me)

  • Dark Forest Theory
  • Fully Transparent
  • Fog of War
  • ZK Perlin Noise

18 of 34

ZK Machine Learning

  • ezkl
  • zk training
  • zk inferencing

​

  • Model provenance

19 of 34

Blockchain Scaling

  • Recursive Proofs
  • Rollups
  • Verifiable state transitions

20 of 34

Proof of Exploitability

  • program: VM that runs something from a target piece of software.
    • Basically a fuzzing harness.
  • inputs: the malicious input (hidden), hash of input
  • output: crash data / proof

21 of 34

22 of 34

23 of 34

Part 3: Automated Bounty Markets

  • Problems in current bug markets / bounty programs
    • triage is hard
    • impact is subjective
    • paying and getting paid is hard

24 of 34

Prereq: Automated Markets

  • Blockchainy stuff
  • Connecting producers and consumers directly
  • No companies, just decentralized protocols
  • Smart contracts exist "on-chain"
  • Publish once, execute forever

​

  • Uniswap
  • Tornado Cash

25 of 34

Prereq: Icicle-emu

  • fuzzing tool
  • high speed greybox
  • emulates archs
  • pure rust!

​

  • remember risc0?

26 of 34

BugMart.org Market Flow

Seller posts: (all information posted on public smart contract)

  • target program (executable code)
  • trace analyzer (a program) and analysis (bug legit/not legit)
  • encrypted input to reach bug
  • encrypted trace and report info
  • proof of execution, that input leads to trace and bug is legit (proof is tiny)

Buyer posts:

  • intent to buy, plus funds to make purchase
  • pubkey

Seller confirms purchase order:

  • decryption key for bug info, encrypted with buyer's pubkey
  • proof that decryption key actually decrypts the data

Final claim is verified by smart contract, which will not pay seller unless the proof checks out

27 of 34

ZkBounty.org Market Flow

Sponsor posts a bounty / security claim:

  • Funds intended to claimant of bounty
  • Target program
  • Output/trace analyzer (another program to confirm impact)
  • pubkey

Researcher pulls down target, adds to fuzz infrastructure, finds bug, and submits:

  • Crash inputs encrypted with sponsor's pubkey
  • Analyzer output (demonstrating impact)
  • Proof that the input leads to the analyzed output
  • Proof that input was encrypted with the sponsor's pubkey

If researcher's proofs are valid, smart contract automatically sends funds to the researcher

  • Automated triage!!

28 of 34

ZkBounty.org Market Flow

29 of 34

ZkRansom.org Market Flow

Unintended "encryption event" initiated on victim system

  • agent generates random ephemeral key in memory
  • agent uses key to encrypt files into a large zip file
  • agent encrypts ephemeral key with attacker's pubkey
  • agent extracts zip2john style challenge from zipfile
  • zip2john and encrypted ephemeral key posted to smart contract

Victim informed of encryption event, told to visit website

  • victim submits payment to smart contract (option to refund after delay)

Attacker generates proof and claims payment by posting:

  • decryption key
  • proof that decryption key decrypts the zip2john challenge

Attacker only gets paid after the contract validates the proof

  • Data never actually needs to get exfilled
  • victim has 100% guarantee that if they pay, they will get data back

30 of 34

31 of 34

Automated Bounty Market Utopia

  • Can be automatically built into global software supply chain
  • Users of software can directly contribute bounty incentives
  • Economically quantifiable attack paths
    • immediately highlights weak links
    • fully transparent to customers / users
  • Not limited purely to software, any attack network you can model

32 of 34

Part 4 : Soundness bugs

  • New overpowered bug class unlocked!
  • ZkVM soundness is classic VM security
  • Remember verifiable state transitions?

​

  • Attacker submits tiny "I have all the money" proof
  • State root is updated to a state where the attacker has all the money
  • Zero knowledge of how TF attacker generated the proof

33 of 34

​

d

​

​

​

​

​

​

l2beat.com

  • Realistically, centralized controls exist today.
  • They are being removed for the sake of credible neutrality.

34 of 34

Call to action!

  • Learn cool shit.
  • learn.0xparc.org, risczero youtube, zero knowledge podcast

​

​

@deanpierce on all the things

Xitter, Lens, Warpcast, BlueSky,

defcon.social, Telegram, Discord, ..