Hi all,
Hertzbleed is the name of this new and powerful side-channel timing attack by Wang et al. (https://www.hertzbleed.com/) that exploits the dynamic frequency scaling technology that is used by many modern processors.
The full implications for constant-time protected software *in general* are still unclear. But for now, it seems that the limitation of the practical attack is that it requires a sufficiently long computation of zeroes (or ones), and these computations should be somehow correlated to the secret key. In the case of SIKE, the attack is successful against it using a chosen ciphertext attack exploiting strategies that resemble zero-value attacks on standard ECC implementations (see https://eprint.iacr.org/2022/054).
To protect SIKE one needs to include a public-key validation step in the decapsulation function that rejects malformed, invalid public keys that produce such long series of zeroes. The countermeasure is now included in the SIDH library (https://github.com/microsoft/PQCrypto-SIDH), and the authors of the attack have confirmed its effectiveness. The countermeasure injects a 5%-6% slowdown to the whole protocol.
Note that these zero value attacks are not novel themselves, and were known to be exploitable via “physical” attacks such as power analysis. What is novel (and alarming) is that power consumption of certain computations can be leaked remotely via frequency scaling and execution time.
Best regards,
Patrick
From: pqc-...@list.nist.gov <pqc-...@list.nist.gov>
On Behalf Of Doge Protocol
Sent: Tuesday, June 14, 2022 12:42 PM
To: pqc-forum <pqc-...@list.nist.gov>
Subject: [EXTERNAL] [pqc-forum] HertzBleed : power side channel attacks on SIKE
You don't often get email from dogepr...@gmail.com. Learn why this is important |
Came across this today https://www.hertzbleed.com/herzbleed.pdf
The paper describes a side channel chosen-ciphertext attack on SIKE (even on constant-time imementations), allowing full key extraction via remote timing.
Has this been already discussed in this forum? Didn't see any previous references in this forum, hence sharing.
--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
pqc-forum+...@list.nist.gov.
To view this discussion on the web visit
https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/e82d7833-9bee-4879-a676-1c1756154a28n%40list.nist.gov.
--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/20220615050635.113967.qmail%40cr.yp.to.
On Jun 15, 2022, at 10:47 AM, Bo Lin <boli...@gmail.com> wrote:The paper reads "Attack scenario. We target a static key version of SIKE where a single secret key is used to decrypt several ciphertexts..." This means it does not apply to the standard SIKE which changes its secret keys (skA and skB) every time. In general, for ephemeral keys, only the "single trace" attack is valid because if an adversary is not able to figure out a secret with a single trace, they need to try again. However, the prosed attack in this paper can be a starting point to study single trace attack by using template or machine learning.
Attacks against implementation are important for products to be deployed into regulated markets because a cryptosystems may fail in its security function not because of a wrong choice of cryptographic mechanisms or protocols, but because of an insecure implementation. The implementation security is related to many factors, especially the semiconductor technology. The security evaluation of side-channel attacks and fault injection attacks has been conducted for many year if we think about the 12 billion payment cards in circulation (EMVCo Reports 12 Billion EMV<sup>®</sup> Chip Cards in Global Circulation - EMVCo).Because implementation security is tightly coupled with device manufacturing technology and with targeted markets, secure coding for implementation security can be left for product building. For NIST standardisation, crypto security has to be focused.
On Wed, 15 Jun 2022 at 06:07, D. J. Bernstein <d...@cr.yp.to> wrote:Running the CPU at a constant speed, independent of the data being
processed, is the obvious, straightforward, auditable way to eliminate
this problem, and nicely composes with the auditability of the usual
constant-time coding discipline. Constant speed isn't the typical OS
default these days, but there are tools to set it up. See, e.g.,
https://bench.cr.yp.to/supercop.html for Linux instructions to disable
Turbo Boost, Turbo Core, and downclocking.
Compared to running the CPU at a constant speed (and blaming the attack
on variable CPU frequencies), why is it supposed to be better to try to
modify code for specific cryptosystems (and to blame the attack on the
unmodified code, or on the cryptosystems)?
If there's supposed to be an "extreme system-wide" performance penalty
for the only auditable path to security, where's the quantification of
this penalty?
Hi Bo Lin and Dan,
On Wed, 15 Jun 2022 at 06:07, D. J. Bernstein <d...@cr.yp.to> wrote:
Running the CPU at a constant speed, independent of the data being
processed, is the obvious, straightforward, auditable way to eliminate
this problem, and nicely composes with the auditability of the usual
constant-time coding discipline. Constant speed isn't the typical OS
default these days, but there are tools to set it up. See, e.g.,
https://bench.cr.yp.to/supercop.html for Linux instructions to disable
Turbo Boost, Turbo Core, and downclocking.
Compared to running the CPU at a constant speed (and blaming the attack
on variable CPU frequencies), why is it supposed to be better to try to
modify code for specific cryptosystems (and to blame the attack on the
unmodified code, or on the cryptosystems)?
I assume you’re yelling at clouds here, but just to pqc-...@list.nist.gov: are you seriously arguing that CPUs, even laptop and phone CPUs, should universally be run at a constant frequency (not even just a workload-responsive but not thermally-responsive frequency) to mitigate crypto side-channel attacks?
--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAEkod36LBz6zg8-0v6GCR9NCfdn6B5kE1FPpC8vkFWh75HJDtw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CY4PR21MB082144D3076E6F9F806C74BFDAAA9%40CY4PR21MB0821.namprd21.prod.outlook.com.
Would the long series of zeroes be caught as malformed with existing pubkey checks? I'm assuming not as a change was applied, but just wanted to check.
...
Compared to running the CPU at a constant speed (and blaming the attack
on variable CPU frequencies), why is it supposed to be better to try to
modify code for specific cryptosystems (and to blame the attack on the
unmodified code, or on the cryptosystems)?
...
On Jun 15, 2022, at 10:30 PM, D. J. Bernstein <d...@cr.yp.to> wrote:Mike Hamburg writes:are you seriously arguing that CPUs, even laptop and phone CPUs,
should universally be run at a constant frequency (not even just a
workload-responsive but not thermally-responsive frequency)
Those are two separate issues.
"Constant" refers to dependence on the secret data being processed. Some
data is designated as secret; some---including timing---is designated as
public; the whole point of the security mechanism is to cut off all
information flow from the secret data to the public data, eliminating
the multiple-decade mess of evaluating whether nonzero information flow
from secrets to timing is exploitable.
My servers, including compute servers, have been running at
constant speed for many years.
I've also happily set my laptop to constant speed for many years,
more and more often choosing the minimum speed that the laptop
supports.
If the fix is constant CPU frequencies rather than tweaks to SIKE…
People suggesting that SIKE should be penalized, or using the "attack on
SIKE" terminology, are assigning blame to a specific cryptosystem rather
than to the use of non-constant CPU frequencies. But this assignment of
blame doesn't appear to be backed by a measurable action plan.
Why
should anyone believe that revised SIKE software, or software for other
KEMs, is safe when there's no serious proposal of an audit mechanism?
Are we supposed to allow data flow from power to timing and simply
_hope_ that the power variations aren't creating enough timing variation
to be exploitable?
* Heterogeneous cores, such as performance cores and efficiency cores.
Why do you think these are prohibited? The question of which core a job
is using has to be data-independent, of course.
* Extending clock periods or dropping cycles for hardware voltage
droop mitigation. This lowers the required supply voltage and saves
energy, and is present since at least Intel Nehalem.
What saves more energy is running at slightly lower clock speeds where
this corner case doesn't happen.
This is not going to happen industry-wide over a side-channel attack
on SIKE, or even on several cryptosystems.
Actually, it has been normal for many years (even though not universal)
for computer manufacturers to give users control over clock frequencies.
The user can turn off Turbo Boost, just like turning off hyperthreading;
this doesn't require any sort of "industry-wide" action.
The current histrionics about the "extreme system-wide performance
impact" of turning off Turbo Boost are about as well founded as picking
benchmarks where hyperthreading gains 2x and leaping to the conclusion
that hyperthreading can't possibly be turned off.
So to first order, on an i7-1280P’s performance cores, the performance
advantage of thermally-adaptive boost is 2.66x.
Not even close.
Multithreaded software typically gains a factor very close to 6 on those
6 performance cores, and vectorization typically gains a factor around
4. This 24x reduction in cycle counts eats up most of the power that
would have been used by Turbo Boost, so maybe the final speedup is
_only_ 10x, but this is a massive performance win---and one of the major
trends in software engineering, with the relevant tools constantly
becoming easier to use.
The only reasonable expectation, then, is that bottlenecks that matter
for the user will be handled by multithreaded vectorized code---which
also means that Turbo Boost is gaining relatively little. Many major
pieces of code have already made this switch. (Video games made the
switch many years ago.)
Cherry-picking unoptimized code is exaggerating the overall gain that
the user sees today from Turbo Boost, and the exaggeration becomes more
and more severe as more and more code takes advantage of multithreading
and vectorization. Are we supposed to tell future users that, yes, we
know how unoptimized code is skewing our performance evaluations away
from what matters to them, but we nevertheless insist on making
decisions for them on the basis of those performance evaluations?
Note that boosting is primarily aimed at interactive workloads, not
long-running compute-intensive ones. That is, it’s primarily for
launching an app or performing a CPU-intensive query during an
otherwise lower-power session.
This distinction between "interactive workloads" and "compute-intensive
ones" has little relevance to the performance issues under discussion.
Anything long enough for the user to be waiting for is _far_ above the
startup costs of a thread.
If the unspecified "CPU-intensive query" isn't yet vectorized and
multithreaded, maybe that's a hint that it's not something typical users
are spending much time waiting for---i.e., it's a corner case, not the
alleged "extreme system-wide performance impact".
So contrary to your assertion, it’s a great fit for your desired
cool-but-responsive laptop that’s not used for heavy compute, at least
if you can reduce the temperature threshold.
Um, which assertion is this supposed to be disputing? Here's what I
actually wrote about my desired laptop: "I've also happily set my laptop
to constant speed for many years, more and more often choosing the
minimum speed that the laptop supports. It's increasingly rare that I'm
waiting for my laptop to compute something, and I don't like the laptop
heating up, especially from background activity on browser pages."
--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/dce735d7-181a-43c1-8010-c8d41ee3e26e%40www.fastmail.com.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CANuKc3iahkH9hrUFtWvxFn01esZzujRn8ijcNsUqJ1A6wOcgag%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/20220622212108.708670.qmail%40cr.yp.to.
On Jun 23, 2022, at 7:06 AM, D. J. Bernstein <d...@cr.yp.to> wrote:Mike Hamburg writes:But I must be missing something, because if the decision on SIKE isn’t
going to be made for another year or two anyway
NIST has removed candidates in every round. What stops them from
responding to high-profile "attacks on SIKE", and expert comments about
how this maybe "makes SIKE less desirable", by removing SIKE right now?
I’ve also made it quite clear in this thread that I don’t think this
should affect SIKE’s standardization chances,
Sorry, can you please quote where you made this clear?
If the _attack on AES_ (ahem) has made you shift away from the positions
expressed in the above statements, let me suggest that it would be best
to issue clear retractions of these statements.
---D. J. Bernstein
P.S. While you're issuing retractions, please acknowledge that my first
message in this thread explicitly said "constant speed, independent of
the data being processed", and please withdraw your false claims that
the word "constant" had switched meanings. Thanks in advance!
--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/20220624072047.806186.qmail%40cr.yp.to.