Secured No. 1


Earlier this year we started a bug bounty program that focuses on finding issues in the beacon chain specification and / or in client implementations (Lighthouse, Nimbus, Teku, Prysm, etc.). The results (and vulnerability reports) were as insightful as the insights gained from patching potential problems.

In this new series we would like to examine and share some of the insights we have gained from previous safety work and which we will pass on in the future.

This first post analyzes some of the submissions that specifically target BLS primitives.

Disclaimer of liability: All the bugs mentioned in this post have already been fixed.

BLS is everywhere

A few years ago, Diego F. Aranha gave a lecture 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 a major player 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 some time, driven in part by Justin Drake and summarized in a recent post by him on reddit.

The latest and greatest

There have been a lot of updates in the meantime. BLS12-381 is now widely recognized as the pairing curve to be used according to our current state of knowledge.

There are currently three different IRTF drafts in development:

  1. Mating-friendly curves
  2. BLS signatures
  3. Hashing to elliptic curves

In addition, the beacon chain specification is mature and is already being used in part. As mentioned above, BLS signatures are an important piece of the puzzle behind Proof-of-Stake (PoS) and the beacon chain.

Last lessons learned

After collecting submissions targeting the BLS primitives used in the consensus level, we can break down reported bugs into three areas:

  • IRTF Design Supervisors
  • Implementation error
  • Violations of the implementation of the IRTF draft

Let’s zoom in on each section.

IRTF Design Supervisors

One of the reporters (Nguyen Thoi Minh Quan) identified discrepancies in the IRTF draft and published two white papers with results:

While the specific inconsistencies are still the subject of discussion, he came across some interesting implementation problems during his research.

Implementation error

With differential fuzzing, Guido Vranken was able to uncover several “small” problems in BLST. See examples of this below:

He rounded this off with the discovery of a moderate vulnerability that affects the blst_fp_eucl_inverse function of the BLST.

Violations of the implementation of the IRTF draft

A third category of errors related to violations of the implementation of IRTF drafts. The first concerned the Prysm client.

To describe this, we first need to provide a little background information. The IRTF draft of the BLS signatures comprises 3 schemes:

  1. Basic scheme
  2. Increase message
  3. Proof of ownership

The Prysm client makes no difference between the 3 in its API, which is unique among implementations (e.g. py_ecc). A special feature of the basic scheme is the literal quotation: ‘This function first ensures that all messages are distinguishable’. This was not ensured in the AggregateVerify function. Prysm addressed this discrepancy by stopping the use of AggregateVerify (which is not used anywhere in the Beacon Chain specification).

A second problem related to py_ecc. In this case, the serialization process described in the ZCash BLS12-381 specification that stores integers is always in the range of [0, p – 1]. The py_ecc implementation performed 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 problem was fixed with the following pull request: Insufficient validation for decompress_G2 deserialization in py_ecc.

Wrap up

Today we checked out the BLS-related reports we received as part of our bug bounty program, but this is definitely not the end of the story for BLS-related security work or adventures.

we strong encourage them to help make the consensus level safer over time. With this in mind, we look forward to hearing from you and encourage you to DIG! If you believe you have found a security vulnerability or bug related to the beacon chain or related clients, send a bug report! 💜🦄

Leave a Reply

Your email address will not be published. Required fields are marked *

Contact Us