Date: Wed, 7 Nov 2018 09:42:46 +0200 From: Billy Brumley <bbrumley@...il.com> To: oss-security@...ts.openwall.com Subject: Re: CVE-2018-5407: new side-channel vulnerability on SMT/Hyper-Threading architectures > > For the 1.1.0 branch, at > > > > https://github.com/openssl/openssl/commits/OpenSSL_1_1_0-stable/crypto/ec/ec_mult.c > > > > everything starting from aab7c770353b1dc4ba045938c8fb446dd1c4531e This was not very responsible of me, since the changes are across several files. I reckon the best source is checking the diff between 1.1.0h and 1.1.0i releases. If you are a package maintainer, and are putting together a patch set for this, please reach out to me. My team can help test. > I assume ec_GFp_simple_dbl and ec_GFp_simple_add are in fact called via > EC_POINT_dbl and EC_POINT_add (via function pointer indirection inside > them, which I didn't follow), respectively. This code skips the call to > EC_POINT_add when digit is 0, and the setting and handling of is_neg is > also potentially leaky: The skipping when digit is 0: yea that's basically it, and what researchers have been targeting since 2009 (Section 3.2): https://www.iacr.org/archive/asiacrypt2009/59120664/59120664.pdf The setting and handling of is_neg: yea that leaks too (Section 6.4): https://eprint.iacr.org/2015/1141 > Also, while the newly introduced implementation is still called > ec_mul_consttime in OpenSSL_1_1_0-stable, it's renamed to > ec_scalar_mul_ladder in OpenSSL_1_1_1-stable and has this comment on it: > > * NB: This says nothing about the constant-timeness of the ladder step > * implementation (i.e., the default implementation is based on EC_POINT_add and > * EC_POINT_dbl, which of course are not constant time themselves) or the > * underlying multiprecision arithmetic. > > Is this still an issue needing fixing, or is it e.g. believed to be > sufficiently mitigated by blinding? Does it still leak? Yes. For example, browse this PR: https://github.com/openssl/openssl/pull/6116 Where David Benjamin (BoringSSL) states: "Note BN_mod_mul is itself not constant-time ..." So if a library's basic arithmetic function that takes two numbers, multiplies them, and returns the remainder after division is not constant time, that potentially affects quite a lot of public key cryptography across the board In the context of OpenSSL ECC, should people worry about it? Not immediately. But don't take my word -- look at the data: https://eprint.iacr.org/2018/651 (You can safely ignore the crazy Chinese crypto stuff -- that was just a way to academically sell the ECC improvements in OpenSSL.) That paper shows a concrete, measurable improvement in side-channel security with the changes that went into 1.1.1 and 1.1.0i. openssl-security reached out to me recently for some disclosure assistance -- here is a quote from me in that discussion: "In the future, you're going to see more and more SCA attacks drilling down into the BN module (where it's harder to exploit). It's a good trend, as lower hanging fruit is drying up!" OpenSSL knows that constant time crypto is important. At the same time, there is no quick fix because the set of crypto that OpenSSL must support is significantly larger than you'll find in other libraries that lack flexibility (and market share). For OpenSSL, it's windy at the top! You will see steady improvements in OpenSSL side-channel security moving forward. > P.S. Congrats on receiving the grant for "SCARE: Side-Channel Aware > Engineering", and I hope we'll see more excellent research from your > team in the next 5 years: > > https://pervasive.cs.tut.fi/?p=2747 Thanks :) If you're still reading, here at the end a call to action for researchers. If you are a side-channel researcher: Don't just approach openssl-security pointing at a line of code that you think might leak. At a bare minimum, accompany that with patches. Even better, bring them empirical data. They are not side-channel experts, and you are -- so act like it. BBB
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.