* Side-channel Attacks (Time) @ 2014-04-25 4:28 Shark8 2014-04-25 5:09 ` Pascal J. Bourguignon 0 siblings, 1 reply; 6+ messages in thread From: Shark8 @ 2014-04-25 4:28 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Side-channel Attacks (Time) 2014-04-25 4:28 Side-channel Attacks (Time) Shark8 @ 2014-04-25 5:09 ` Pascal J. Bourguignon 2014-04-25 5:36 ` Shark8 0 siblings, 1 reply; 6+ messages in thread From: Pascal J. Bourguignon @ 2014-04-25 5:09 UTC (permalink / raw) 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 !" ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Side-channel Attacks (Time) 2014-04-25 5:09 ` Pascal J. Bourguignon @ 2014-04-25 5:36 ` Shark8 2014-04-25 5:51 ` Pascal J. Bourguignon 2014-04-25 19:43 ` Simon Clubley 0 siblings, 2 replies; 6+ messages in thread From: Shark8 @ 2014-04-25 5:36 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Side-channel Attacks (Time) 2014-04-25 5:36 ` Shark8 @ 2014-04-25 5:51 ` Pascal J. Bourguignon 2014-04-25 6:26 ` Shark8 2014-04-25 19:43 ` Simon Clubley 1 sibling, 1 reply; 6+ messages in thread From: Pascal J. Bourguignon @ 2014-04-25 5:51 UTC (permalink / raw) 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 !" ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Side-channel Attacks (Time) 2014-04-25 5:51 ` Pascal J. Bourguignon @ 2014-04-25 6:26 ` Shark8 0 siblings, 0 replies; 6+ messages in thread From: Shark8 @ 2014-04-25 6:26 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Side-channel Attacks (Time) 2014-04-25 5:36 ` Shark8 2014-04-25 5:51 ` Pascal J. Bourguignon @ 2014-04-25 19:43 ` Simon Clubley 1 sibling, 0 replies; 6+ messages in thread From: Simon Clubley @ 2014-04-25 19:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-04-25 19:43 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-04-25 4:28 Side-channel Attacks (Time) Shark8 2014-04-25 5:09 ` Pascal J. Bourguignon 2014-04-25 5:36 ` Shark8 2014-04-25 5:51 ` Pascal J. Bourguignon 2014-04-25 6:26 ` Shark8 2014-04-25 19:43 ` Simon Clubley
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox