Earlier this year, we initiated a bug bounty program aimed at identifying issues in the beacon chain specification and/or in client implementations (Lighthouse, Nimbus, Teku, Prysm, etc.). The results (and vulnerability reports) have been eye-opening, as have the lessons learned while patching potential issues.
In this new series, we plan to delve into and share some of the insights we’ve gained from our security efforts to date and as we progress further.
This first post will examine some of the submissions specifically aimed at BLS primitives.
Disclaimer: All bugs mentioned in this post have already been resolved.
BLS is everywhere
A few years ago, Diego F. Aranha delivered a presentation at the 21st Workshop on Elliptic Curve Cryptography titled: Pairings are not dead, just resting. How prophetic.
Here we are in 2021, and pairings have become one of the key components behind many of the cryptographic primitives utilized in the blockchain space (and beyond): BLS aggregate signatures, ZK-SNARKS systems, etc.
Efforts related to the development and standardization of BLS signatures have been an ongoing project for EF researchers for some time, driven in part by Justin Drake and summarized in a recent post of his on Reddit.
The latest and greatest
In the meantime, there have been numerous updates. BLS12-381 is now widely recognized as the pairing curve of choice given our current understanding.
Three different IRTF drafts are currently in progress:
- Pairing-Friendly Curves
- BLS signatures
- Hashing to Elliptic Curves
Furthermore, the beacon chain specification has evolved and is now partially deployed. As previously mentioned, BLS signatures are a crucial aspect of the framework underlying proof-of-stake (PoS) and the beacon chain.
Recent lessons learned
After gathering submissions focused on the BLS primitives utilized in the consensus layer, we can categorize the reported bugs into three main areas:
- IRTF draft oversights
- Implementation mistakes
- IRTF draft implementation violations
Let’s take a closer look at each category.
IRTF draft oversights
One of the reporters, Nguyen Thoi Minh Quan, identified discrepancies in the IRTF draft and published two white papers detailing his findings:
While the specific inconsistencies are still up for discussion, he discovered some intriguing implementation issues during his research.
Implementation mistakes
Guido Vranken managed to uncover several minor issues in BLST using differential fuzzing. Below are examples of those:
He concluded this with the discovery of a moderate vulnerability concerning the BLST’s blst_fp_eucl_inverse function.
IRTF draft implementation violations
A third category of bugs pertained to violations of the IRTF draft implementation. The first instance affected the Prysm client.
To explain this, we need to provide some background. The BLS signatures IRTF draft encompasses three schemes:
- Basic scheme
- Message augmentation
- Proof of possession
The Prysm client does not differentiate between the three in its API, which is unique compared to other implementations (e.g. py_ecc). An interesting quirk of the basic scheme is its statement: ‘This function first ensures that all messages are distinct.’ This was not guaranteed in the AggregateVerify function. Prysm remedied this discrepancy by deprecating the use of AggregateVerify (which is not implemented anywhere in the beacon chain specification).
A second issue affected py_ecc. In this case, the serialization process outlined in the ZCash BLS12-381 specification mandated that stored integers fall within the range of [0, p – 1]. However, the py_ecc implementation conducted this check for the G2 group of BLS12-381 only for the real part, neglecting to perform the modulus operation for the imaginary part. This issue was resolved with the following pull request: Insufficient Validation on decompress_G2 Deserialization in py_ecc.
Wrapping up
Today, we reviewed the BLS-related reports we received as part of our bug bounty program, but this is certainly not the conclusion of our security endeavors or our exploration of BLS.
We strongly encourage you to contribute to ensuring the consensus-layer continues to improve in safety over time. With that, we look forward to hearing from you and urge you to DIG! If you believe you’ve discovered a security vulnerability or any bug related to the beacon chain or its associated clients, please submit a bug report! 💜🦄
