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