We are working on some tooling. It has a networking kernel. We would like to think that jitter built into the kernel would help with timing attacks?
Is this true?
$\begingroup$
$\endgroup$
2
-
3$\begingroup$ Yes, but usually this can be overcome using statistical tools and a larger sample-size. $\endgroup$– SEJPMAug 12, 2018 at 17:54
-
$\begingroup$ Thank you. It suggests there is no point in trying that. Is there a technique that helps ? $\endgroup$– cryptoJimAug 12, 2018 at 19:50
Add a comment
|
1 Answer
$\begingroup$
$\endgroup$
8
Yes, and no.
Adding random jitter makes things harder, but since you cannot force the device to go faster then the minimum number of instructions it would take to perform the computation without interrupts, it would still be possible to perform a timing attack using a large number of traces and statistical tools such as low percentile filters, in a similar way as in this paper by Crosby et al.
In the end, the only reliable way to fight timing attacks is really to have constant time code. You can read more about constant time crypto on BearSSL's website.
But you can encrypt all the data you're sending over the network, using constant time crypto and that's it. No need to have the whole network stack constant time, if it's only sending encrypted data!
-
$\begingroup$ Thank you @Lery. Constant timing would be a nightmare for us to achieve. Thinking about this it seems there is no real defense against a statistical timing attack ? Crosby et al appear to confirm this for me. """s a consequence, we recom mend that the algorithms used inside web and other Internet servers that p rocess important secrets be carefully audited and, where necessary, be modifi ed to limit observ- able differences in execution times to at most a few microsec onds.""" But they talk about nano-second resolution attacks being possible... $\endgroup$ Aug 12, 2018 at 21:42
-
1$\begingroup$ Well, it's as always the difference between the practice and the theory. In practice, nanoseconds leaks are extremely hard to exploit without a controlled environment... I once found a 3ns leak on a RSA implementation that I couldn't exploit locally because the number of traces required to turn it into a reliable oracle was so huge and the number of oracle queries required was too large for it to be practically doable, even if in theory the leak is there and I could confirm it. It also depends on your CPU, for instance pulling timing attacks on Arduino Nano is much easier than on 3Ghz CPUs $\endgroup$– LeryAug 12, 2018 at 21:55
-
$\begingroup$ I worry about the micro-second leaks too, since the RNG may set a minimum compute time on an operation. A computer can be controlled down to micro-seconds of elapsed time. I dont know how to code lower than micro-second resolution. The round trips are definately > microseconds... There are several operations in the kernel that we could make 'constant-time', but the round-trips within we can't. $\endgroup$ Aug 12, 2018 at 21:55
-
$\begingroup$ But do you really need all operations to be constant time to guarantee the security of your protocol? That seems surprising. $\endgroup$– LeryAug 12, 2018 at 21:56
-
4$\begingroup$ @cryptojim Remember that "constant-time" code in cryptography does not mean the code always takes exactly the same amount of time to execute, but instead means that the time taken to execute is not dependent on secret information. It should not be a "nightmare" to achieve, especially with ready to go libraries like bearssl, CTTK, and libsodium. $\endgroup$ Aug 12, 2018 at 22:51