1
$\begingroup$

I have been reading and thinking about timing attacks on cryptographic systems. The answer to this question mentions the following:

"The way to defend against timing attacks is to make sure the time taken to execute cryptographic operations does not depend on any secret information."

My question is, assuming a model where an adversary is connected to an oracle via networking, would write buffering socket.send at the application level to only occur every x milliseconds protect against crypto operations that would otherwise leak data?

My idea is to use the select system call say, every .01 seconds, to handle any reads and writes. Since data would only leave the server at constant intervals, does it matter if short circuit comparisons or the like were used?

The most obvious downside I can think of is that it would add some latency to all application network requests, even non crypto related ones.

Is this a valid defense against side channel attacks in situations where networking delivers the queries/responses?

Improve this question
$\endgroup$

1 Answer 1

Reset to default
3
$\begingroup$

It will only help to a certain degree.

If you want to protect against ciphertext attacks you cannot just add random time. The reason for that is that the random time you add is probably in a range. Or in your case, the period between calls will be in a certain range.

This means that if you have a large enough sample set you can figure out the deviation of the calls. Say you find out the maximum timeout. If the call takes maximum + x then x will be the time that the cryptographic operation takes.

Of course, for this to become a problem, you need to have a bigger data set. Computers and networks are however insanely fast, so usually creating a bigger data set is often not a problem.

If you try to mess with things like buffering of networked data you may also have to protect against attackers trying to circumvent the buffering issue. The network is the initial interface for an attacker, so it will be the primary attack surface.

The network buffering and cryptographic computations are not directly related. This solution would tie the network implementations with the protection of cryptographic algorithms. This is probably not a relationship that you want to maintain.

Your solution will also not protect against DPA attacks or attacks on the CPU itself (using access to the CPU from user accounts). So the protection is limited to the networking interface.

Another issue is that CPU scheduling can be pretty obnoxious. Sometimes an operation may take much longer than average. In that case the timeout may not be sufficient.

All in all, this should definitely not be the only protection against side channel attacks, and the limitations of the approach should be well understood.

Improve this answer
$\endgroup$
2
  • $\begingroup$ How might attackers circumvent it? In my particular case, for non cryptographic reasons, the thread that select's my sockets runs every .01 seconds already; However only reads are buffered, as I saw no reason to increase latency on writes. It would be a very small change to implement this in my case, and fortunately networking is agnostic to application code thanks to a remote procedure call layer. It sounds like you're thinking it's not a panacea (of course, nothing is), but in the worst case it's not harmful aside from some added latency? $\endgroup$
    – Ella Rose
    Jan 2, 2016 at 4:01
  • 1
    $\begingroup$ Adding some jitter can indeed help. However adding a change to the random response time to avoid timing attacks can be circumvented by statistics. This is the most important point of my answer. I don't know how well your solution would work in practice; if the added time is too low or too high then it obviously won't work. I don't know if an attacker can attack the nw interface; the point is that it is the interface where the countermeasures are implemented. $\endgroup$
    – Maarten Bodewes ♦
    Jan 2, 2016 at 10:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.