On Wed, Jun 20, 2007 at 04:00:01PM +0200, Artur Grabowski wrote: > 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.
This kind of security design is assuming favourable constellation of uncontrollable environmental noises to scramble the information we are knowingly leaking. It's basically a snake oil. We have no proof that under every conceivable circumstances the noises will be present in a way that completely masks the information leak. Why not write the keyboard driver the same way how the friend did it in his OS - using bitmasking and avoiding conditional jumps and lookup tables? Then the security would be guaranteed and not just hoped for. > > And guess what. Keyboards use a serial protocol. Which means that > there will be slightly different voltage drops in the system varying The capacitors and regulator which are made to keep the voltage almost constant with a swing of tens of amperes (60W/1.5V=40A) will not permit a measurable swing when you change the current draw by a milliamp or so. The precision of voltage measurement is too low for this and the noise from other permanently running sources too high. CL<
