[Cryptography] Defeating timing attacks

Henry Baker hbaker1 at pipeline.com
Fri Jul 14 20:59:47 EDT 2017


At 05:23 PM 7/14/2017, Ray Dillinger wrote:
>From: Ray Dillinger <bear at sonic.net>
>
>On 07/14/2017 09:21 AM, Henry Baker wrote:
>> [Follow-up on attackers always win.]
>> 
>> Consider the following theoretical exercise:
>> 
>> Suppose that a computer's instruction set was *purposely designed* to leak as much secret information through a timing side-channel as possible.  E.g., *asynchronous logic* from the 1960's/1970's might qualify, as the timing of essentially every operation is data-dependent!
>> 
>> Is there any way for a *compiler* to generate code to generate enough deliberate jitter to mask the leaked information?
>
>Cooperative timesharing (software driven as opposed to the current,
>sane, standard of preemptive hardware-driven timesharing) has very low
>context-switch overhead, and allows very fine granularity of thread
>changing.  It allows an application to determine its own CPU slice,
>and gives the scheduler no compelling reason to ignore the application's
>instructions.  Cooperative timesharing under BeOs(?) moved tens of
>thousands of threads per second, per core, a few instructions at a
>time.
>
>An application under cooperative timesharing that wants to defend
>itself against emitting leaked information via side channels would
>just yield the CPU, often, after processing very few instructions.

>It should take time slices so small - say, 5 to 10 machine instructions
>at a time - that the sequences are sequences that could be found in
>pretty much any program.  Low-overhead context switching would allow
>it to work.

You could *literally* take "sequences that could be[^H^H^H^H^H^H^H^H
ACTUALLY ARE] found in pretty much any program": this is now called
"return-oriented programming" (ROP).

https://en.wikipedia.org/wiki/Return-oriented_programming

"In this technique, an attacker gains control of the call stack to hijack program control flow and then executes carefully chosen machine instruction sequences that are ***already present*** in the machine's memory, called "gadgets".  Each gadget typically ends in a return instruction and is located in a subroutine within the existing program and/or shared library code.  Chained together, these gadgets allow an attacker to perform arbitrary operations on a machine employing defenses that thwart simpler attacks."

---
Perhaps ROP should become a standard technique for crypto codes.  Perhaps ROP can be used for something good, rather than malware.  OpenSSL, are you listening?



More information about the cryptography mailing list