Re: Side-channel Attacks (Time)

[Shark8 <OneWingedShark@gmail.com>]

On 24-Apr-14 23:51, Pascal J. Bourguignon wrote:
> 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.

No, that's wrong.
If your processing time is 1 ms for 'fail' but response is padded to 10 
ms and your processing time for 'success' is 10 ms then trafficwise 
there is no difference: both are 10 ms form reception-to-response.

> 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.

Um, all of these presuppose (a) compromised physical security, and/or 
(b) compromised 'process security' [that is, an already-compromised 
system] -- I contend both of these are outside the scope of a SW library.