Side-channel Attacks (Time)

Side-channel Attacks (Time)

[Shark8]

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.

Psudeocode-ish Example:

task body Protocol is
   Upperbound : Time;
   Working    : Data;
begin
--...
   accept request ([...]) do
     Upperbound:= Clock + operation_length;
   end request;

   Working:= do_operation;
   delay until Upperbound;

   accept response ( Result : out Data )
     Result := Working;
   end response;
--...
end Protocol;


* OP_UPPERBOUND would be the the time the request was made plus the time 
needed to perform the [cryptographic] function.

Re: Side-channel Attacks (Time)

[Pascal J. Bourguignon]

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.

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.

Of course, it's as always a matter of risk and graduated counter-measures.

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

Re: Side-channel Attacks (Time)

[Shark8]

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

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

Re: Side-channel Attacks (Time)

[Pascal J. Bourguignon]

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 !"

Re: Side-channel Attacks (Time)

[Shark8]

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.

Re: Side-channel Attacks (Time)

[Simon Clubley]

On 2014-04-25, Shark8 <OneWingedShark@gmail.com> wrote:
> 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 problem is that you are making assumptions about the environment
your code is running in when you determine how long something is going
to take.

The static values you come up with for a 3GHz desktop processor will be
very different from the values you need for a 100MHz (or even less)
embedded system, which makes the values you choose fragile when they are
used in different environments.

If, OTOH, you try to calculate some dynamic values at program startup
time which reflect the system you are running on, then you are vulnerable
to bad values calculated due to varying system load.

I wonder if you could achieve what you want by introducing random
micro-delays into the calculations themselves ?

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world