Security Vulnerabilities in ZK
An exploration of the common vulnerabilities in the context of ZK.
Security Vulnerabilities in ZK
Intro
The growth of Zero Knowledge technology adoption over the past year is a promising sign for the future. However, as these systems become more prevalent, a challenge has emerged. The nature of Zero Knowledge systems makes it challenging to identify vulnerabilities promptly, which puts both users and systems at risk. It is important for companies to address this issue and take measures to ensure the safety and security of their systems.
Inadvertent disclosures of zero knowledge cryptography have occurred as a result of the expertise of developers, academic research, and the observation of successful exploits in the real world.
To maintain the robustness of cryptographic systems and prevent potential security breaches, it is crucial to address the resolution of bugs and exploits in zk-applications.
Sign up for our quarterly State of ZK report
State of Affairs
During Q2, some bugs and vulnerabilities were discovered in upcoming ZK systems.
Polygon zkEVM
A security audit of Polygon zkEVM Mainnet Beta identified and addressed vulnerabilities related to ZKPs. The audit revealed 10 critical, 1 high, and 4 medium-level vulnerabilities within the codebase. These vulnerabilities were specific to the prover component, which generates proofs for valid state transitions in ZK rollups. The security firm conducted multiple audits and found 2 critical and 2 low-level vulnerabilities in the prover, all fixed before the Mainnet Beta launch.
Nova
On the research front, Shrinath Setty along with Nguyen and Boneh, described an exploit they discovered in an earlier version of the Nova system. This was also described in a recent blog post from the auditing firm zksecurity.xyz, one of a handful of emerging auditing firms taking on ZK security projects.
Additionally, the 00 attack targeted a bad implementation and there was a counterfeiting vulnerability on Zcash discovered in 2018, which could have allowed anyone to produce false proofs for their circuits, due to a vulnerability in the setup phase of the original paper. Most recently, Microsoft’s zero knowledge proof (ZKP) system implementation, Nova, was broken.
Common vulnerabilities
According to the ZK Bug Tracker developed by 0xParc, here are some of the common vulnerabilities in Zero Knowledge applications:
| Vulnerability | Explanation |
|---|---|
| Under-constrained Circuits | Attacks on circuits with insufficient constraints can exhibit significant variability based on the absent constraints. In certain instances, this vulnerability can result in serious outcomes, such as enabling a user to repeatedly deplete funds.To mitigate these vulnerabilities, it is crucial to conduct thorough testing with extreme scenarios and perform meticulous manual reviews of the circuit's logic. |
| Nondeterministic Circuits | Nondeterministic circuits, a subset of under-constrained circuits, arise due to missing constraints that introduce multiple valid proof paths for specific outcomes. For instance, a common example of this phenomenon is seen in the nondeterministic nullifier generation process. These nullifiers play a crucial role in zk applications, such as TornadoCash, where they prevent double actions by requiring the posting of a nullifier on-chain when a note commitment is spent. However, not all nondeterministic circuits pose security risks; in some cases, they can optimize circuits without compromising security. Nevertheless, it remains essential to exercise caution and conduct thorough manual reviews to ensure deterministic behavior where needed, including the addition of constraints to rectify nondeterministic vulnerabilities. |
| Arithmetic Over/Under Flows | Circom circuits are constructed over a scalar field with a specific order denoted as 'p.' It's easy to overlook this detail and neglect considerations for overflows and underflows. These nuances can lead to unintended consequences if not appropriately addressed. For instance, in a scenario where a circuit computes a user's new balance, inputting a withdrawal amount greater than the current balance may result in a new balance output that underflows, yielding an excessively large value close to 'p,' which is not the intended outcome. To rectify such issues, the Circomlib provides templates like LessThan and Num2Bits, which ensure proper value bounds and prevent overflows or underflows, safeguarding against malicious inputs that exploit these vulnerabilities. |
| Mismatching Bit Lengths | In ZK systems, circuits within CircomLib often expect a specific number of bits in their inputs for accurate constraints and results. For example, the LessThan circuit works with 'n' bits. However, vulnerabilities arise when input parameters aren't properly constrained to this maximum bit length outside the CircomLib circuit. For instance, the LessThan circuit outputs 1 if the first input is less than the second input. An attacker could exploit this by using a small number for the first input and a larger one exceeding 'n' bits for the second input. This would cause the Num2Bits input to behave unexpectedly, potentially yielding an output of 0, even when the first input is genuinely smaller. To prevent such issues, it's essential to conduct bit length checks on the inputs themselves using CircomLib's Num2Bits circuit, rather than only applying it to the intermediate calculations as currently done in the LessThan circuit. |
| Unused Public Inputs Optimized Out | Vulnerabilities can arise in ZK systems when circuits include public inputs without constraints, as optimization tools in certain systems, like Circom 2.0, may remove these unconstrained inputs. In this scenario, attackers can manipulate these inputs during proof verification. For instance, in Semaphore, where users prove group membership with hashed signals, if no constraints are placed on the signal hash, attackers can modify it in a valid proof and resend it, forging signals. To mitigate this, non-linear constraints should be introduced to involve public inputs, preventing their unintended removal by optimizers, as seen in systems like TornadoCash and Semaphore. |
| Frozen Heart: Forging of Zero Knowledge Proofs | In the realm of zero-knowledge proof protocols, "Frozen Heart" vulnerabilities pose a serious threat. These vulnerabilities enable malicious provers to create forged proofs that can pass verification, essentially allowing them to "prove" false claims. Many zero-knowledge protocols rely on the Fiat-Shamir transformation, which, if not implemented securely, can facilitate proof forgery. These vulnerabilities are named "Frozen Heart" by the TrailOfBits team, emphasizing the need for heightened awareness in the cryptography community. Addressing these issues requires better implementation guidance, as many protocols lack clear instructions, making it easier for attackers to exploit insecure implementations. To improve security, TrailOfBits has introduced ZKDocs, offering developers comprehensive guidance for safer zero-knowledge proof implementations. |
| Trusted Setup Leak | Many widely-used zk protocols rely on a trusted setup to generate essential parameters that enable provers to construct valid zk proofs. However, within this setup, certain parameters, known as "toxic waste," must remain hidden from all parties. If this toxic waste is exposed to any entity, it could empower them to forge zk proofs for that specific system. To safeguard against such risks, multi-party computation is often employed to maintain the privacy of toxic waste. Older zk protocols like Pinocchio and Groth16 require a new trusted setup for each unique circuit, which becomes problematic when projects need to update their circuits, necessitating a complete redo of the trusted setup. In contrast, newer protocols like MARLIN and PLONK only require a single trusted setup, often referred to as "universal," which can be applied to multiple programs, simplifying upgrades. |
Conclusion
It is imperative that security be considered a top priority in the adoption of ZK technology, on the same level as any other technological factor. The risk of losing trust due to potential bugs is a significant concern that cannot be disregarded.
