Leak the Secret Key of BBS Short Signature in Relic via Rowhammer

[liang-junkai]

Hi Team,

We are writing to report a potential security issue about the implementation of bbs short signature in the relic library while providing countermeasures.

Specifically, we cloned the relic repo from github on December 10, 2023 and have analyzed the source code of the Boneh Boyen short signature (or bbs) scheme (more precisely, relic_cp_bbs.c). Based on our analysis, the signature implementation (Line 70 in relic_cp_bbs.c) is vulnerable to fault attacks. As a proof-of-concept (PoC), we have recovered 190 bits out of 224 secret bits via Rowhammer.

As you may know, Rowhammer is software-induced DRAM fault, which can induce bit flips in main memory that runs a commodity system. In our PoC, a malicious user process co-resides in the same system with a victim process that runs the bbs short signature from the relic library. As both processes share the main memory, the adversary can induce bit flips to the secret key before it is used by the victim to sign a message, resulting in a faulty signature. With enough faulty signatures released, the adversary can recover/leak the secret key.

Before our report, RSA implementation in the WolfSSL library and the OpenSSL library have been reported to be vulnerable to Rowhammer-based fault attacks. For the WolfSSL library, its vulnerability is tracked via CVE-2019-19962. For the OpenSSL library, its RSA vulnerability is tracked by a commit. Clearly, we target a different cryptographic algorithm, i.e., bbs signature.

For more details of our analysis, PoC and possible countermeasures, they are provided in the following repository Relic-bbs-fault-injection and pdf report Vulner_report_relic.pdf.

Can you help us verify these issues? Thanks~

[dfaranha]

Hi,

Thank you for your report!

I'm not sure that a fix should be applied to RELIC, since it does not consider fault injection in its threat model, since it consists of a research library (see disclaimer in the main page). If RELIC did consider fault injection, then most of the library would have to be rewritten from scratch to accommodate for that.

Any person crazy enough to deploy RELIC in its current state in a production environment where fault injection is a concern can implement a signature algorithm that verifies the signature as a countermeasure using building blocks from the library.

[liang-junkai]

Hi Diego,

Thanks for your reply.

IMHO, a fix is needed to at least mitigate fault injection attacks that have been exposed. It sounds a bit weak if we claim fault injection attacks are beyond the scope, which sounds similar to the situation of Intel SGX where side channel attacks were not considered in its threat model but various side channel attacks have been proposed these years to break its security guarantees.

While RELIC is a research library, it is featured in its practicality and feasibility, and has been used by syscoin, a full-stack modular Proof-of-Work blockchain solution merge-mined with Bitcoin. It is expected to be used in more production environments. As people focus more on their business logic in their products with less attention to the underlying implementation details of RELIC, they are likely to be susceptible to fault injection and fix might not be there in time.

Given that signature verification does not cost much efforts, it may be worthwhile to fix the bbs scheme and other cryptographic algorithms case by case. Also, we may draw people’s attention explicitly to fault injection in the disclaimer.

[dfaranha]

Hi again,

A fix is only needed if fault injection is considered to be in the threat model. I just updated the disclaimer to make that limitation more explicit. You cannot compare RELIC deployments (at their own risk) with a product such as Intel SGX. I'm certainly not operating nowhere near Intel scale, and my work is not compensated in the same manner. We have fixed side-channel vulnerabilities in the past when it fit the threat model (look at LadderLeak for an example).

Lastly, signature verification is definitely not cheap, as it incurs a whole pairing computation. Including a signature verification in every signature computation would penalize signing by a 10x factor and make the current benchmarks quite confusing. Once more, it's pretty trivial to write a signature implementation that verifies the signature before returning it for any signing algorithm currently supported in RELIC.

[liang-junkai]

OK, thanks for your reply.