4

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?

Patriot
  • 3,132
  • 3
  • 18
  • 65
cryptoJim
  • 51
  • 2

1 Answers1

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!

Lery
  • 7,679
  • 1
  • 26
  • 46
  • 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...

     – cryptoJim Aug 12 '18 at 21:42
  • 1
    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 – Lery Aug 12 '18 at 21:55
  • 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.

     – cryptoJim Aug 12 '18 at 21:55
  • But do you really need all operations to be constant time to guarantee the security of your protocol? That seems surprising. – Lery Aug 12 '18 at 21:56
  • This is it. I am not sure what constitutes secure in the face of stochastic techniques. – cryptoJim Aug 12 '18 at 22:00
  • You want constant time operations on your secret data... Typically on the secret keys you are using, but not on the whole networking stack. BTW, you should probably read this link about constant time crypto. You really want your crypto to be constant time, and then you want to encrypto all the data you're sending over the network, and that's it. No need to have the whole stack constant time. – Lery Aug 12 '18 at 22:03
  • OK, so, thanks to all here, we have a plan. We will implement a constant-time scheme.

    We'll still use the jitter code to help align the ops to distinct time bounderies.

    If the boundary is high enough, it can also cater for the networking LAN/WAN round-trips.

    We are thinking that will then get us closer to 'constant-time' across the stack?

    Does that make any sense and does it sound plausible ?

     – cryptoJim Aug 12 '18 at 22:12
  • 4
    @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. – Ella Rose Aug 12 '18 at 22:51