Earlier this year, we initiated a bug bounty initiative concentrating on identifying problems within the beacon chain specification, and/or within client executions (Lighthouse, Nimbus, Teku, Prysm, etc.). The findings (and security reports) have been enlightening, as have been the lessons acquired while rectifying potential problems.
In this new series, our intention is to delve into and share some of the knowledge we’ve gathered from security efforts thus far and as we progress.
This inaugural post will examine some of the contributions specifically focusing on BLS primitives.
Disclaimer: All vulnerabilities referenced in this post have been rectified.
BLS is omnipresent
A few years back, Diego F. Aranha presented a talk at the 21st Workshop on Elliptic Curve Cryptography with the title: Pairings are not deceased, merely resting. How prophetic.
Now in 2021, pairings have become one of the key components behind numerous cryptographic primitives applied in the blockchain realm (and beyond): BLS aggregate signatures, ZK-SNARKS systems, etc.
The development and standardization efforts concerning BLS signatures have been a continuous undertaking for EF researchers for some time, motivated in part by Justin Drake and encapsulated in a recent post he made on reddit.
The most recent and outstanding
In the interim, there have been numerous enhancements. BLS12-381 is now universally acknowledged as the pairing curve to employ with our current understanding.
There are currently three distinct IRTF drafts being developed:
Furthermore, the beacon chain specification has advanced and is already partially in use. As previously noted, BLS signatures are a crucial piece of the puzzle behind proof-of-stake (PoS) and the beacon chain.
Recent insights gained
After gathering submissions focused on the BLS primitives utilized in the consensus-layer, we have been able to categorize reported vulnerabilities into three categories:
- IRTF draft oversights
- Implementation errors
- IRTF draft execution contraventions
Let’s delve into each category.
IRTF draft oversights
One of the contributors, (Nguyen Thoi Minh Quan), discovered inconsistencies within the IRTF draft, and released two white papers with his analysis:
While the particular discrepancies are still open for discussion, he identified some intriguing implementation issues while conducting his investigation.
Implementation errors
Guido Vranken was able to reveal several “minor” issues in BLST utilizing differential fuzzing. Below are examples of those findings:
He concluded this with the discovery of a moderate vulnerability concerning the BLST’s blst_fp_eucl_inverse function.
IRTF draft execution contraventions
Another category of vulnerability was associated with IRTF draft execution contraventions. The first instance impacted the Prysm client.
To explain this, we first need to provide some context. The BLS signatures IRTF draft encompasses 3 methods:
- Fundamental method
- Message enhancement
- Ownership proof
The Prysm client does not differentiate between the 3 in its API, distinguishing itself among implementations (e.g. py_ecc). A notable aspect of the fundamental method is stating verbatim: ‘This function first guarantees that all messages are unique’. This assurance was not maintained in the AggregateVerify function. Prysm rectified this inconsistency by phasing out the use of AggregateVerify (which is not utilized anywhere in the beacon chain specification).
A second concern affected py_ecc. Here, the serialization method outlined in the ZCash BLS12-381 specification stipulates that integers are always within the range of [0, p – 1]. The py_ecc implementation conducted this check solely for the G2 group of BLS12-381 for the real component but failed to execute the modulus operation for the imaginary component. This problem was resolved with the subsequent pull request: Insufficient Validation on decompress_G2 Deserialization in py_ecc.
Conclusion
Today, we examined the BLS-related reports we have received as part of our bug bounty initiative, but this is certainly not the conclusion of the narrative for security efforts or for experiences connected to BLS.
We firmly urge you to assist in ensuring that the consensus layer continues to advance in safety over time. With that, we eagerly anticipate hearing from you and encourage you to DIG! If you believe you’ve identified a security vulnerability or any malfunction associated with the beacon chain or its related clients, submit a bug report! 💜🦄
