OpenSSL Bellcore's Protection Helps Fault Attack

Carré, Sébastien; Desjardins, Matthieu; Facon, Adrien; Guilley, Sylvain

doi:10.1109/dsd.2018.00089

Cited by 18 publications

(19 citation statements)

References 9 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…They report ∼85% of the tested modules to be vulnerable to RowHammer. Since one can cause RowHammer bit flips solely by performing memory accesses, RowHammer quickly became a popular vector for developing real-world attacks [5], [11]- [13], [17], [23]- [25], [27], [28], [39], [66], [76]- [79], [81], [88], [89], [91], [92], [96], [98].…”

Section: B Rowhammermentioning

confidence: 99%

“…DDR4: Towards a RowHammer-less landscape. Most prior RowHammer research focuses on DDR3 systems [5], [11]- [13], [17], [23]- [25], [28], [39], [51], [77]- [79], [81], [88], [89], [91], [92], [96], [98]. While there are reports of bit flips on DDR4 chips in prior work [27], [56], [66], these results are on earlier generations of DDR4.…”

Section: B Rowhammermentioning

confidence: 99%

“…In their seminal work, Kim et al [51] are the first to rigorously introduce and characterize the RowHammer vulnerability. Following this work, a large number of of attacks compromising a variety of different systems [5], [12], [13], [17], [24], [25], [28], [39], [77], [79], [81], [89], [91], [92], [96], [98] and characterization studies [22], [23], [27], [78], [88] emerged, as described in a recent retrospective article [72]. Prior works rely on three main classes of RowHammer patterns to induce bit flips: (i) single-sided, (ii) double-sided, and (iii) one-location RowHammer.…”

Section: Related Workmentioning

confidence: 99%

See 2 more Smart Citations

TRRespass: Exploiting the Many Sides of Target Row Refresh

Frigo

Vannacc

Hassan

et al. 2020

2020 IEEE Symposium on Security and Privacy (SP)

126

204

View full text Add to dashboard Cite

After a plethora of high-profile RowHammer attacks, CPU and DRAM vendors scrambled to deliver what was meant to be the definitive hardware solution against the RowHammer problem: Target Row Refresh (TRR). A common belief among practitioners is that, for the latest generation of DDR4 systems that are protected by TRR, RowHammer is no longer an issue in practice. However, in reality, very little is known about TRR. How does TRR exactly prevent RowHammer? Which parts of a system are responsible for operating the TRR mechanism? Does TRR completely solve the RowHammer problem or does it have weaknesses?In this paper, we demystify the inner workings of TRR and debunk its security guarantees. We show that what is advertised as a single mitigation mechanism is actually a series of different solutions coalesced under the umbrella term Target Row Refresh. We inspect and disclose, via a deep analysis, different existing TRR solutions and demonstrate that modern implementations operate entirely inside DRAM chips. Despite the difficulties of analyzing in-DRAM mitigations, we describe novel techniques for gaining insights into the operation of these mitigation mechanisms. These insights allow us to build TRRespass, a scalable black-box RowHammer fuzzer that we evaluate on 42 recent DDR4 modules.TRRespass shows that even the latest generation DDR4 chips with in-DRAM TRR, immune to all known RowHammer attacks, are often still vulnerable to new TRR-aware variants of RowHammer that we develop. In particular, TRRespass finds that, on present-day DDR4 modules, RowHammer is still possible when many aggressor rows are used (as many as 19 in some cases), with a method we generally refer to as Many-sided RowHammer. Overall, our analysis shows that 13 out of the 42 modules from all three major DRAM vendors (i.e., Samsung, Micron, and Hynix) are vulnerable to our TRR-aware RowHammer access patterns, and thus one can still mount existing state-of-the-art system-level RowHammer attacks. In addition to DDR4, we also experiment with LPDDR4(X) 1 chips and show that they are susceptible to RowHammer bit flips too. Our results provide concrete evidence that the pursuit of better RowHammer mitigations must continue. 2 We turn off the in-DRAM RowHammer mitigation mechanism by disabling REFRESH commands, as we explain in Section V.

show abstract

Section: B Rowhammermentioning

confidence: 99%

Section: B Rowhammermentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

See 1 more Smart Citation

TRRespass: Exploiting the Many Sides of Target Row Refresh

Frigo

Vannacc

Hassan

et al. 2020

2020 IEEE Symposium on Security and Privacy (SP)

126

204

View full text Add to dashboard Cite

show abstract

“…These numbers must all be large for RSA to be secure, which makes the exponentiation rather slow. However, there is an algebraic shortcut for modular exponentiation: the Chinese Remainder Theorem (CRT), used in many RSA implementations, including in the WolfSSL we attack in Section 5 and in OpenSSL [CDFG18]. The basic form of the RSA-CRT signature algorithm is shown in Algorithm 1.…”

Section: Rsa-crt Signingmentioning

confidence: 99%

“…Protection Against Bellcore Attack Defenses against fault injection attacks proposed in the original Bellcore whitepaper [BDL97] include verifying the signature before releasing it, and random padding of the message before signing, which ensures that no unique message is ever signed twice and that the exact plaintext cannot be easily determined. OpenSSL protects against the Bellcore attack by verifying the signature with its plaintext and public key and recomputing the exponentiation by a slower but safer single exponentiation instead of by the CRT if verification does not match [CDFG18]. After we reported the vulnerability to WolfSSL, they issued a patch in version 4.3.0 including a signature verification to protect against Bellcore-style attacks.…”

Section: Disabling Hugepages and Virtualizing Afu Address Spacementioning

confidence: 99%

JackHammer: Efficient Rowhammer on Heterogeneous FPGA-CPU Platforms

Weissman¹,

Tiemann²,

Moghimi

et al. 2020

TCHES

View full text Add to dashboard Cite

After years of development, FPGAs are finally making an appearance on multi-tenant cloud servers. Heterogeneous FPGA-CPU microarchitectures require reassessment of common assumptions about isolation and security boundaries, as they introduce new attack vectors and vulnerabilities. In this work, we analyze the memory and cache subsystem and study Rowhammer and cache attacks enabled by two proposed heterogeneous FPGA-CPU platforms from Intel: the Arria 10 GX with an integrated FPGA-CPU platform, and the Arria 10 GX PAC expansion card which connects the FPGA to the CPU via the PCIe interface. We demonstrate JackHammer, a novel, efficient, and stealthy Rowhammer from the FPGA to the host’s main memory. Our results indicate that a malicious FPGA can perform twice as fast as a typical Rowhammer from the CPU on the same system and causes around four times as many bit flips as the CPU attack. We demonstrate the efficacy of JackHammer from the FPGA through a realistic fault attack on the WolfSSL RSA signing implementation that reliably causes a fault after an average of fifty-eight RSA signatures, 25% faster than a CPU Rowhammer. In some scenarios our JackHammer attack produces faulty signatures more than three times more often and almost three times faster than a conventional CPU Rowhammer. Finally, we systematically analyze new cache attacks in these environments following demonstration of a cache covert channel across FPGA and CPU.

show abstract