[Cryptography] Defeating timing attacks

[Ray Dillinger]

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.

If you tried to do the same with a pre-emptive multitasking system,
the context-switch overhead would either effectively paralyze the
process, (Well, okay, says the scheduler, but if you really mean to
yield the cpu that many times, it'll take weeks to get the number of
time slices you're going to suddenly end...) or the scheduler would just
ignore its request to be interrupted and run it generating side channels
as usual (Yeah, says the scheduler, I can schedule a process now.  So
I'll just run a process to move things forward, and oh look, that
process is you.  Again.  Until I can get you out of my face.  Okay?).

Of course the problem with cooperative timesharing is the
non-cooperative process and the more-or-less complete lack of memory
barriers between processes.  You could control machine-level side
channels but you'd become more vulnerable to malware and memory-level
side channels than you've been since 1985.


					Bear





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170714/878969e9/attachment.sig>