Secured no. 1
BLS Primitives Under the Microscope: Lessons Learned from Our Bug Bounty Program
As we continue to push the boundaries of blockchain technology, security remains a top priority. Earlier this year, we launched a bug bounty program focused on finding issues in the beacon chain specification, and/or in client implementations (Lighthouse, Nimbus, Teku, Prysm, etc.). The results have been enlightening, and the lessons learned while patching potential issues have been invaluable. In this series, we aim to explore and share some of the insights we've gained from our security work to date and as we move forward.
BLS is Everywhere
A few years ago, Diego F. Aranha gave a talk at the 21st Workshop on Elliptic Curve Cryptography with the title: "Pairings are not dead, just resting." How prophetic. Here we are in 2021, and pairings are one of the primary actors behind many of the cryptographic primitives used in the blockchain space (and beyond): BLS aggregate signatures, ZK-SNARKS systems, etc.
Development and standardization work related to BLS signatures has been an ongoing project for EF researchers for a while now, driven in-part by Justin Drake and summarized in a recent post of his on reddit. The latest and greatest is that BLS12-381 is now universally recognized as the pairing curve to be used given our present knowledge.
Three IRTF Drafts: A Work in Progress
There have been plenty of updates, and three different IRTF drafts are currently under development:
- Pairing-Friendly Curves: This draft aims to provide a standardized approach to pairing-friendly curves, which are essential for BLS signatures.
- BLS Signatures: This draft focuses on the BLS signature scheme itself, including the basic scheme, message augmentation, and proof of possession.
- Hashing to Elliptic Curves: This draft explores the use of hashing to elliptic curves, which is a crucial component of BLS signatures.
Recent Lessons Learned
After collecting submissions targeting the BLS primitives used in the consensus-layer, we're able to split reported bugs into three areas:
IRTF Draft Oversights
One of the reporters, Nguyen Thoi Minh Quan, found discrepancies in the IRTF draft and published two white papers with findings:
- "Splitting zero" attack: This attack exploits a vulnerability in the BLS aggregate signature scheme, allowing an attacker to split a single signature into multiple signatures.
- Attacks and weaknesses of BLS aggregates signatures: This paper highlights several weaknesses in the BLS aggregate signature scheme, including the lack of transparency and the potential for attacks.
While the specific inconsistencies are still subject for debate, Quan's findings have shed light on potential vulnerabilities in the BLS aggregate signature scheme.
Implementation Mistakes
Guido Vranken was able to uncover several "little" issues in BLST using differential fuzzing. Some examples include:
- blst: Inverse modulo hangs on i386 if input is 0 or multiple of modulo: This bug causes the blst library to hang when performing an inverse modulo operation on certain inputs.
- blst: Using non-standard 'dst' parameter branches on uninitialized memory: This bug causes the blst library to access uninitialized memory when using a non-standard 'dst' parameter.
- Moderate vulnerability affecting the BLST's blst_fp_eucl_inverse function: This bug allows an attacker to perform a moderate vulnerability in the blst_fp_eucl_inverse function.
Vranken's findings highlight the importance of thorough testing and validation in cryptographic libraries.
IRTF Draft Implementation Violations
A third category of bug was related to IRTF draft implementation violations. The first one affected the Prysm client.
In order to describe this, we need to provide a bit of background. The BLS signatures IRTF draft includes three schemes:
- Basic scheme: This scheme is the most basic form of BLS signature.
- Message augmentation: This scheme adds additional information to the basic scheme.
- Proof of possession: This scheme requires the signer to prove possession of a private key.
The Prysm client doesn't make any distinction between the three in its API, which is unique among implementations (e.g. py_ecc). One peculiarity about the basic scheme is quoting verbatim: "This function first ensures that all messages are distinct." This was not ensured in the AggregateVerify function. Prysm fixed this discrepancy by deprecating the usage of AggregateVerify (which is not used anywhere in the beacon chain specification).
A second issue impacted py_ecc. In this case, the serialization process described in the ZCash BLS12-381 specification that stores integers are always within the range of [0, p - 1]. The py_ecc implementation did this check for the G2 group of BLS12-381 only for the real part but did not perform the modulus operation for the imaginary part. The issue was fixed with the following pull request: Insufficient Validation on decompress_G2 Deserialization in py_ecc.
Wrapping Up
Today, we took a look at the BLS related reports we have received as part of our bug bounty program, but this is definitely not the end of the story for security work or for adventures related to BLS. We strongly encourage you to help ensure the consensus-layer continues to grow safer over time. With that, we look forward to hearing from you and encourage you to DIG! If you think you've found a security vulnerability or any bug related to the beacon chain or related clients, submit a bug report!
Source: https://blog.ethereum.org/en/2021/09/09/secured-no-1
