| |||||||||||||
Random instruction timingsRandom instruction timingsPosted Oct 6, 2009 5:49 UTC (Tue) by kleptog (subscriber, #1183)Parent article: Scenes from the Real Time Linux Workshop
The note about instruction timings being random rings true to me. A while back I created a small kernel driver that created random bits by taking the last few bits of a high-resolution timer whenever the timer interrupt went off.
I tried some of the standard toolkits for measuring randomness and they all concluded the data was totally random. The basic conclusion was that you could easily generate hundreds of random bits per second without too much effort. This would be useful for machines currently suffering from loss of randomness because they're headless.
It also seems a much better option than extracting randomness from network traffic, since while an attacker might be able to affect the network card, there's no way they're going to be able to affect the system timer.
(Log in to post comments)
Random instruction timings Posted Oct 6, 2009 9:06 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
this brings into question the tactic of checking timing to see what commands were executed by other processes in order to guess encryption keys. (along with things like measuring power consumption, etc as well)
you may be able to do this on simple CPUs used for embedded applications, but this makes it pretty clear that this path of attack is not that big a risk on current x86 cpus
Random instruction timings Posted Oct 8, 2009 14:01 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link]
The magnitude of an external cache miss is still high enough that I imagine you could see its signature even over the LS-bit noise in the TSC. It may take several runs to correlate things well enough, though, so an isolated encryption event may still hide in the noise.
|
|||||||||||||