Karel Kulhavy <[EMAIL PROTECTED]> writes: > On Tue, Jun 19, 2007 at 07:05:38PM -0700, Don Scott wrote: > > I think Artur Grabowski too easily dismisses the question. > > > > I'd be interested to know if you get any informative responses that > > are not also posted to [EMAIL PROTECTED] > > Mikulas (the friend) told me the algorithm to hack the root > password. First you need to know the addresses of the individual > keys in the translation tables - that's probably doable from the > operating system kernel memory map. > > Then you need to know how many way associative your cache is and how > the addresses are shared. If it's say 4-way you use 4 addresses in > your userspace that share the cache entry. Then you read all of them > 4. > > Now comes the monitoring phase. You cyclically time how long it > takes to read each of these 4 addresses using rdtsc. When you get > anomalously high reading on any of them, you know the given address > in the key translation table has been accessed. > > This will probably suffer from some noise (made up keystrokes - > other process flushing the cache entry for you).
"probably"? "some noise"? In pure theory, when the keyboard input is the only thing going on in the machine, when the machine is disconnected from the network, has no disk I/O when the password is typed and no other processes running, you still get a few timer interrupts for every character being typed (you do not type faster than 100 characters per second). Not only that, but the whole path between the actual keyboard interrupt and whereever you could find a table lookup (guess what? many table entires share the same cache lines) stomps on so much cache that you'd be completly lost in the noise. This is assuming a hyperthreaded cpu where the monitoring thread can run uninterrupted all the time. Without that, you're even more screwed because the context switches will add even more noise to the side channel. These kinds of attacks are barely theoretically possible when the attacker completly controls the operation that he's snooping on (which happens with crypto operations). To use this for passive monitoring of events as rare as keyboard input sounds like sensationalism. Sure, in a very distant theory it might actually be doable, but rubber hose cryptoanalysis is much more realistic in almost all scenarios I can imagine. And guess what. Keyboards use a serial protocol. Which means that there will be slightly different voltage drops in the system varying with the keys you press. ZOMG! OpenBSD provides a side channel for attackers through the sensors framework! And you can also use the information about keyboard interrupts that you can get through sysctls to get more or less exact timing of when keys are pressed, which will give you much more accurate information about what's being typed since the timing between key strokes is much easier to analyze than the noise you'd get from cache timing. //art
