Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Hertzbleed: data-dependent frequency

25 views
Skip to first unread message

Anton Ertl

unread,
Jun 16, 2022, 12:39:07 PM6/16/22
to
Hertzbleed <https://www.hertzbleed.com/> attacks SIKE (a key exchange
mechanism) through a power side channel, by observing the resulting
frequency of a core (which goes down if per-cycle power goes up).

Different bit patterns in the keys consume different amounts of power
in a "constant-time" (i.e., state-of-the-art) implementation of SIKE
which apparently allows to get some info about the bits in the keys by
observing the frequency.

So I was wondering if one could mitigate this by performing a
complementary computation that results in constant total power.
Letting both the key and the ones-complement of the key run through
SIKE is probably too naive. In an OoO CPU where every computation
overwrites a different physical register (and the original contents is
almost unpredictable), I don't see how to do the complementary
approach, but then I don't see how the exploit works. I guess I
should read the paper in more depth.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

MitchAlsup

unread,
Jun 16, 2022, 1:15:43 PM6/16/22
to
On Thursday, June 16, 2022 at 11:39:07 AM UTC-5, Anton Ertl wrote:
> Hertzbleed <https://www.hertzbleed.com/> attacks SIKE (a key exchange
> mechanism) through a power side channel, by observing the resulting
> frequency of a core (which goes down if per-cycle power goes up).
<
Sounds more like an argument to avoid using a frequency higher than can
be sustained long term.
>
> Different bit patterns in the keys consume different amounts of power
> in a "constant-time" (i.e., state-of-the-art) implementation of SIKE
> which apparently allows to get some info about the bits in the keys by
> observing the frequency.
<
There was a data pattern the CDC 7600 was sensitive to when performing
something like DGEMM. When this data pattern would show up it would
setup standing waves on the power supplies in the 7600 and after about
1 millisecond the machine would deadstop.
<
This is the reason the CRAY-1 provided a DC load to the power supplys.
No data pattern created any change in current demand--either long
term or instantaneous.
>
> So I was wondering if one could mitigate this by performing a
> complementary computation that results in constant total power.
<
Run sensitive code at frequencies where no frequency throttling will occur.
0 new messages