Re: Side-channel Attacks (Time)

["Pascal J. Bourguignon" <pjb@informatimago.com>]

Shark8 <OneWingedShark@gmail.com> writes:

> On 24-Apr-14 23:09, Pascal J. Bourguignon wrote:
>> Shark8 <OneWingedShark@gmail.com> writes:
>>
>>> Considering the needs for a secure, verified security library [to
>>> replace OpenSSL] I was wondering about using the TASK construct in
>>> conjunction with DELAY UNTIL /OP_UPPERBOUND/* would be an acceptable
>>> countermeasure.
>>
>> It could help.
>>
>> Choosing an algorithm without branches, and with fixed count loops would
>> be better.
>
> Hm, there's a thought.
> I rather do like the DELAY UNTIL solution as it concisely states the
> intention as a timing-attack countermeasure. (Though I've got pretty
> much no experience in real-time systems, so I can't say if it's
> actually appropriate.)

The point is that it's too easy to detect the actual processing time,
vs. the sleeping time waiting for the delay.

For example, your electric counter could be monitored by the enemy, and
would let him deduce the processing time from the instaneous power
consumed by your computer.

Or for a purely software attack, another process can easily detect when
more processing time becomes available because other tasks are sleeping.

Even at small scale, on multicores, you could easily detect the
difference in RAM access contention.


>> But even in that case, if physical access to the processor is available,
>> physical side effects can be detected, and from them information about
>> the data can be deduced.
>
> I think physical security is well beyond the scope of a software library.
>
>> Of course, it's as always a matter of risk and graduated counter-measures.
>
> Certainly.

-- 
__Pascal Bourguignon__
http://www.informatimago.com/
"Le mercure monte ?  C'est le moment d'acheter !"