The ACM defines a research artifact as "a digital object that was either created by the authors to be used as part of the study or generated by the experiment itself." Find the most recent version of several of our FOSS projects from our GitLab page. Even better—collaborate with us and submit PRs!
CVE-2020-12399: research data and tooling • CVE-2020-12399: NSS timing attack on DSA • CVE-2020-12402: NSS RSA key generation side-channel attack • CVE-2020-12401: NSS timing-attack on ECDSA • CVE-2020-6829: NSS side-channel attacks on scalar multiplication • ECCKiila • ECCKAT: co-factor ECC CDH • Projective coordinates leakage: research data and tooling • CVE-2020-10932: Mbed TLS inversion leakage • CVE-2020-12400: NSS inversion leakage • CVE-2020-11735: wolfSSL inversion leakage • CVE-2019-18222: research data and tooling • CVE-2019-18222 • CVE-2019-1547: research data and tooling • CVE-2019-1547 • OpenSSL Triggerflow CI • Triggerflow • PortSmash • CVE-2018-5407 • SM2 EM traces • CVE-2018-0737 • libsuola • CVE-2016-7056 • CVE-2016-2178
This dataset and software tools are for reproducing the research results related to CVE-2020-12399. It contains the remote timing data used in Section 4 of the paper, and later in Section 9 for the lattice attack. The measurements were collected over Gbit Ethernet between a client (attacker) and server (victim) connected by a Cisco 9300 series enterprise switch. We released the data to ensure reproducibility and refute doubts on the feasibility of remote timing attacks with lattice-based cryptanalysis.
In DSA signing, Mozilla’s NSS uses a modular exponentiation function with microarchitecture attack mitigations to protect exponent digits. However, the function leaks leading zero digits, leading to a remote timing attack vulnerability similar to CVE-2011-1945 and Minerva.
NSS CVE-2020-12399 sneak peek: remote DSA key recovery with network timings across a Cisco 9300 switch w/as few as 1K samples. Preprint coming soon by @Sohaibuh, Iaroslav Gridin, Ignacio M. Delgado-Lozano, @CesarPereidaG @Jebus_dguez @acaldaya #sidechannel https://t.co/rllN4htgr0 pic.twitter.com/q1YRpI9xed
— NISEC (@NISEC_TAU) June 4, 2020
During RSA key generation, bignum implementations used a variation of the Binary Extended Euclidean Algorithm which entailed significantly input-dependent flow. This allowed us to perform electromagnetic-based side channel attacks to record traces leading to the recovery of the secret primes.
NSS CVE-2020-12402 sneak peek: single trace RSA key recovery with EM. Preprint coming soon by @Sohaibuh, Iaroslav Gridin, Ignacio M. Delgado-Lozano, @CesarPereidaG @Jebus_dguez @acaldaya #sidechannel #infosec #ResponsibleDisclosure https://t.co/Pw5NKSyZbj #ResearchImpactEU pic.twitter.com/R3sFUuIiPf
— NISEC (@NISEC_TAU) July 14, 2020
In Mozilla’s NSS, we discovered that nonce padding applied as a countermeasure to CVE-2011-1945 at high level ECDSA signing functions was in fact being removed in lower level scalar multiplication wrappers. This put ECDSA private keys at risk to remote timing attacks. Read more about it in Section 5 of the paper. Mozilla merged our patch eventually, after lower-level mitigations.
In ECDSA signing, we discovered that for curves NIST P-384 and NIST P-521, Mozilla’s NSS used a variable-time version of scalar multiplication function previously known to be vulnerable CVE-2018-5407. We leveraged EM side-channels to extract the ECDSA nonce information and recovered the 384-bit ECDSA private key using less than a hundred signatures. Furthermore, by using software controlled side-channels, we exploited the scalar recoding algorithm used in ECDSA point multiplication and retrieved the private key by acquiring only a handful of signatures.
To appear @acm_ccs 2020 "Déjà Vu: Side-Channel Analysis of Mozilla's NSS" by NISEC's @Sohaibuh, Iaroslav Gridin, Ignacio M. Delgado-Lozano, @CesarPereidaG @Jebus_dguez @acaldaya! CVE-2020-12399 CVE-2020-12402 CVE-2020-6829 CVE-2020-12401 #preprint https://t.co/XZx0vMbFIO pic.twitter.com/zkP5SfbY9S
— NISEC (@NISEC_TAU) August 14, 2020
We presented ECCKiila in Set It and Forget It! Turnkey ECC for Instant Integration, that fully automates the implementation, testing, and integration of ECC stacks.
"Set It and Forget It! Turnkey ECC for Instant Integration" to appear @ACSAC_Conf 2020: congrats to Dmitry Belyavsky, @luinxzama @Jebus_dguez Igor Ustinov! https://t.co/1K80PY3fzQ ECCKiila stacks already merged in gost-engine and NSS #ResearchImpactEU https://t.co/FBvIJAreWE pic.twitter.com/DgVEy0v92Y
— NISEC (@NISEC_TAU) August 19, 2020
We applied ECCKiila and seamlessly integrated into three real-world projects: OpenSSL, Mozilla’s NSS, and the GOST OpenSSL Engine.
This artifact contains one of the vulnerabilities included in ECCKAT, described in Section 3.4 ("OpenSSL: ECC CDH vulnerability") in the preprint. It demonstrates bypassing Elliptic Curve Co-factor Diffie Hellman (ECC CDH) security in an OpenSSL beta release, which should fail to derive a shared key if a peer point is not a multiple of the generator. We developed the fix for OpenSSL in PR 6535.
Is constant time projective to affine conversion important? Yes; yes it is. New #preprint by @acaldaya @CesarPereidaG to appear at #CHES2020! #ResponsibleDisclosure #mbedTLS CVE-2020-10932 #WolfSSL CVE-2020-11735 #OpenScience #OpenData https://t.co/ecl2YNGGuW #ResearchImpactEU https://t.co/tqih3Mr3yw
— NISEC (@NISEC_TAU) April 16, 2020
The data was used to carry out the projective coordinates attack against Libgcrypt in Section 6 of the article.
While converting ECC points from projective to affine coordinates, Mbed TLS failed to use a constant-time modular inversion function. This potentially put private keys at risk. Read more about it in our paper.
While converting ECC points from projective to affine coordinates, NSS failed to use a constant-time modular inversion function. This potentially put private keys of P-384 and P-521 at risk. Read more about it in our paper.
While converting ECC points from projective to affine coordinates, wolfSSL failed to use a constant-time modular inversion function. This potentially put private keys at risk. Read more about it in our paper.
This dataset relates to CVE-2019-18222 and contains the per-signature post-processed ECDSA nonce candidates. It also contains tooling that, after factoring a candidate, will enumerate the ECC keys to test for the correct nonce. The dataset and tooling were used to produce some of the Mbed TLS results in the paper and released to ensure reproducibility.
We discovered a side-channel vulnerability in the Mbed TLS implementation of a side-channel countermeasure. For ECDSA signatures, Mbed TLS uses multiplicative blinding of the nonce, but fails to reduce the product. Obtaining a trace of the subsequent inversion, attackers can factor the product and enumerate ECC keys.
An ECDSA #sidechannel attack with factoring? Read about #mbedtls CVE-2019-18222 in the latest NISEC #preprint by @acaldaya! To appear at #CHES2020. #infosec #ResponsibleDisclosure https://t.co/cl1VuTtofd #OpenScience #OpenData https://t.co/YYibt5tchh #ResearchImpactEU https://t.co/IACBUwUB1Z
— NISEC (@NISEC_TAU) January 21, 2020
This dataset relates to CVE-2019-1547, used to produce Figure 4 in the paper and is part of the remote timing attack data (Section 4.1). The included software tools help validate the data as well as show how to parse the JSON.
We introduced the concept of Certified Side Channels where many cryptography libraries make various runtime decisions when parsing private keys that leads to side channel vulnerabilities later when using the keys.
C. Pereida-García et al., “Certified Side Channels” […Surveying…widely deployed software libraries…design and implement key recovery attacks utilizing signals ranging from EM, to granular microarchitecture cache timings, to coarse wall clock timings…]https://t.co/DQ6kfd2wll
— Arrigo Triulzi (@cynicalsecurity) September 5, 2019
We discovered vulnerabilities in DSA, RSA, and EC key parsing, and submitted several PRs to the OpenSSL project to address these issues ( 9587 9727 9779 9797 9808 9821 10122 10140 10196 10209 10232 ). Find more information in the OpenSSL Security Advisory.
Continuous Integration system for OpenSSL, watching for known execution paths vulnerable to side channel attacks. Powered by Triggerflow.
Execution path tracking tool. Originally developed for dynamic analysis of software for side-channel vulnerabilities, it is a development tool automating the debugger to allow contextual inspection of breakpoints, with false positive considerations to facilitate automated regression testing.
Triggerflow: Regression Testing by Advanced Execution Path Inspection
"We further show-case the value of the tooling by presenting two novel discoveries facilitated by Triggerflow: one leak and one defect in OpenSSL."https://t.co/FFfrkrwYtH
— Damian Gryski (@dgryski) April 12, 2019
This proof-of-concept artifact demonstrates PortSmash in action against a vulnerable OpenSSL version performing non-constant-time scalar multiplications.
We backported the security fix to OpenSSL in 7593, now merged.
We discovered PortSmash, a novel microarchitecture side-channel attack technique exploiting port contention in architectures featuring Simultaneous Multi-Threading (SMT).
We applied PortSmash to steal the private key (elliptic curve P-384) of an OpenSSL-linked TLS server. Find more information in our oss-security post.
This dataset contains Electromagnetic (EM) side-channel traces of elliptic curve point multiplication during SM2 decryption in OpenSSL. The traces were used for Test Vector Leakage Assessment (TVLA) of SM2 decryption.
N. Tuveri et al., “Side-Channel Analysis of SM2: A Late-Stage Featurization Case Study” [Chinese cipher] https://t.co/QkBL6y71ke
— Arrigo Triulzi (@cynicalsecurity) July 10, 2018
We discovered several code paths in OpenSSL’s RSA key generation implementation leaking algorithm state. We exploited a code path performing co-primality tests using the variable-time greatest common divisor (GCD) algorithm. A side-channel cache-timing attack allowed us to recover RSA private keys after a single cache-timing trace.
I just learned about CVE-2018-0737 (cache timing attack on RSA keygen in OpenSSL: https://t.co/x9EfKNyQqu ). This is a coincidence; I had planned RSA keygen for a long time, and I made it constant-time out of a matter of principle. But yeah, turns out it matters.
— Thomas Pornin (@BearSSLnews) August 15, 2018
An ENGINE gluing together OpenSSL and NaCl-derived crypto. This project aims at developing an OpenSSL engine rigging cryptosystem implementations derived from NaCl into OpenSSL.
libsuola: Bridge btw OpenSSL and external crypto libraries [transparent shallow loadable module leveraging OpenSSL ENGINE API to provide alternative sw impl for X25519 & Ed25519; libsodium https://t.co/70Gb5JKHeV, HACL* https://t.co/EOza7MySJP ] https://t.co/6UZ5HyfNMa https://t.co/yzXKPiRC8e
— Daniel Bilar (@daniel_bilar) April 19, 2018
It supports different back-end providers, including implementations from alternative third party libraries like libsodium, formally verified implementations like the ones provided by the HACL* project or statically embedding an alternative implementation inside the ENGINE.
libsuola is meant to demonstrate a framework that can be used to bridge the gap between novel scientific results and real world applications.
We discovered a vulnerability in OpenSSL’s ECDSA signing implementation, affecting the 1.0.1 branch. The weakness is due to variable-time modular inversion, even when featuring P-256 constant-time scalar multiplication.
CVE-2016-7056 ECDSA P-256 timing attack key recovery (OpenSSL, LibreSSL, BoringSSL) https://t.co/hMfzxw2RUi
— Frank Denis (@jedisct1) January 10, 2017
Exploiting this vulnerability, we performed a side-channel cache-timing attack that allowed us to recover private keys from OpenSSL-linked TLS and SSH servers after a small number of attacker-initiated connections.
Find more information in our oss-security post.
We discovered a bug in OpenSSL’s DSA implementation that prevents the DSA signing algorithm from running in constant time even with appropriate flags set. This bug went unnoticed since 2005.
I've been told that OpenSSL advisories are going out pretty soon again because of an attack like that. Wait a week or two.
— mjosdwez (@mjos_crypto) June 3, 2016
Out today: This is the OpenSSL side-channel vulnerability I mentioned last week; now on ePrint. Also CVE-2016-2178. https://t.co/h0mT7bJ7Kj
— mjosdwez (@mjos_crypto) June 8, 2016
Exploiting this bug, we performed a side-channel cache-timing attack against two protocols that rely on OpenSSL: SSH and TLS.
For SSH (linked to OpenSSL) we recovered a 1024/160-bit DSA key, and for TLS (linked to OpenSSL) we recovered a 2048/256-bit DSA key, both after a small number of attacker-initiated connections. Find more information in an oss-security post.
We generated a dataset of 50,000 Twitter users. For each user, we created a unique profile containing 19 attributes. Our dataset contained only users whose tweets are public and have non-zero friends and followers. We used this dataset for our works: