Differences

This shows you the differences between two versions of the page.

--- public:papers:minerva_tches20 [2020-07-02 11:31] – created xsvenda
+++ public:papers:minerva_tches20 [2020-09-07 13:33] (current) – [Edit - Panel] xjancar
@@ Line 32: / Line 32: @@
 <collapse id="bibtex" collapsed="true">
   @InProceedings{2020-tches-minerva,
-    Title         = {Biased RSA private keys: Origin attribution of GCD-factorable keys},
+    Title         = {Minerva: The curse of ECDSA nonces, Systematic analysis of lattice attacks on noisy leakage of bit-length of ECDSA nonces},
-    Author        = {Adam Janovsky, Matus Nemec, Petr Svenda, Peter Sekan and Vashek Matyas},
+    Author        = {Jan Jancar and Vladimir Sedlacek and Petr Svenda and Marek Sys},
-    BookTitle     = {25th European Symposium on Research in Computer Security (ESORICS) 2020},
+    BookTitle     = {Conference on Cryptographic Hardware and Embedded Systems (CHES) 2020},
     Year          = {2020},
-    Publisher     = {Springer},
+    Publisher     = {Ruhr-University of Bochum, Transactions on Cryptographic Hardware and Embedded Systems},
-    crocsweb      = {https://crocs.fi.muni.cz/papers/privrsa_esorics20},
+    ISSN          = {2569-2925}
-    Keywords      = {RSA, private key bias, origin attribution},
+    crocsweb      = {https://crocs.fi.muni.cz/papers/minerva_tches20},
+    Keywords      = {ECC, smartcard, cryptographic libraries},
   }
 </collapse>
 <panel type="default" title="Abstract">
-In 2016, Švenda et al. (USENIX 2016, The Million-key Question) reported that the implementation choices in cryptographic libraries allow for qualified guessing about the origin of public RSA keys.
+We present our discovery of a group of side-channel vulnerabilities in implementations of the ECDSA signature algorithm in a widely used Atmel AT90SC FIPS 140-2 certified smartcard chip and five cryptographic libraries (**libgcrypt**, **wolfSSL**, **MatrixSSL**, **SunEC/OpenJDK/Oracle JDK**, **Crypto++**).
-We extend the technique to two new scenarios when not only public but also private keys are available for the origin attribution -- analysis of a source of GCD-factorable keys in IPv4-wide TLS scans and forensic investigation of an unknown source. We learn several representatives of the bias from the private keys to train a model on more than 150 million keys collected from 70 cryptographic libraries, hardware security modules and cryptographic smartcards. Our model not only doubles the number of distinguishable groups of libraries (compared to public keys from Švenda et al.) but also improves more than twice in accuracy w.r.t. random guessing when a single key is classified. For a forensic scenario where at least 10 keys from the same source are available, the correct origin library is correctly identified with average accuracy of 89\% compared to 4\% accuracy of a random guess. The technique was also used to identify libraries producing GCD-factorable TLS keys, showing that only three groups are the probable suspects.
+Vulnerable implementations leak the bit-length of the scalar used in scalar multiplication via timing. Using leaked bit-length, we mount a lattice attack on a 256-bit curve, after observing enough signing operations. We propose two new methods to recover the full private key requiring just 500 signatures for simulated leakage data, 1200 for real cryptographic library data, and 2100 for smartcard data.
+The number of signatures needed for a successful attack depends on the chosen method and its parameters as well as on the noise profile, influenced by the type of leakage and used computation platform. We use the set of vulnerabilities reported in this paper, together with the recently published TPM-FAIL vulnerability as a basis for real-world benchmark datasets to systematically compare our newly proposed methods and all previously published applicable lattice-based key recovery methods. The resulting exhaustive comparison highlights the methods' sensitivity to its proper parametrization and demonstrates that our methods are more efficient in most cases. For the TPM-FAIL dataset, we decreased the number of required signatures from approximately 40 000 to mere 900.
 </panel>