Re: Security of the keyboard
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. Why not write the driver yourself? I don't see the reason to jump and reinvent wheels (that are rather complicated) every time some alarmist invents yet another improbable threat. //art
Re: Security of the keyboard
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). But I guess if you run this long enough and the admin comes to the console and types the root password and you see root in the keystroke stream and you have luck that no other activity created too much fake keystrokes, then you can know or at least well guess for the password. Of course this will be a local exploit only. This stuf is generally called side channels (don't confuse with covert channels). The idea is that a secret information leaks out and can be read in supposedly irrelevant signs of the CPU operation. It's the CPU equivalent of trashdiving - picking up those yellow post-it notes from the dustbin and searching for the root passwords. Like if you ask someone and he needs a time to think even for a trivial question, then he's probably lying - he needs brain CPU time to carefully make things up in a way it doesn't create apparent discrepancies. But if you ask him are you lying, he tells you no. You are getting an access to a secret through the timing. Mikulas said he even knew some link to where they cracked OpenSSL this way - Mikulas can you post it? CL On 6/19/07, Karel Kulhavy [EMAIL PROTECTED] wrote: A friend who is happening to write his own operating system just pointed out to me that a keyboard driver cannot use - lookup tables, because timing accessing these lookup tables would yield information what key was pressed when entering a root password - tests and jumps, because the same would be possible with the BTB (branch target buffer). He said he had to write the whole driver using logical operation masking. Does OpenBSD also have this trick? How is the keyboard security designed in OpenBSD to prevent these covert channels leaking the information to an unprivileged process? CL
Re: Security of the keyboard
Yay ! Let's map everything uncached from now on! For great justice! [I was tempted to write some stuff about how keyboard keycode translation works in wscons, but it's not worth my time] Miod
Re: Security of the keyboard
Miod Vallat [EMAIL PROTECTED] writes: Yay ! Let's map everything uncached from now on! For great justice! Yay! Then we can start inlining code again for greater performance! //art
Re: Security of the keyboard
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
Re: Security of the keyboard
Artur Grabowski [EMAIL PROTECTED] writes: 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 don't forget the aps(4) sensor on Thinkpads! The accelerometer can probably measure the acceleration caused by various key strokes and that acceleration will be different depending on where on the keyboard you hit (different angles) and with which finger (different strength). //art
Re: Security of the keyboard
Artur Grabowski [EMAIL PROTECTED] writes: And don't forget the aps(4) sensor on Thinkpads! The accelerometer can probably measure the acceleration caused by various key strokes and that acceleration will be different depending on where on the keyboard you hit (different angles) and with which finger (different strength). Now that last bit is almost certainly pure speculation, since, as the aps man page says, IBM has not provided any useful documentation. Who knows what a suitably knowledgeable attacker who sits patiently waiting for your keystrokes to be caught by the sensors could do with the data? Don't ask me, ask USENET. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ First, we kill all the spammers The Usenet Bard, Twice-forwarded tales delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Security of the keyboard
Yay ! Let's map everything uncached from now on! For great justice! [I was tempted to write some stuff about how keyboard keycode translation works in wscons, but it's not worth my time] Miod You don't have to map keyboard map uncached, just change the way code is written --- instead of x = a[i] you write something like x = 0; for (j = 0; j sizeof a/sizeof *a; j++) x |= a[j] (-(i ^ j) 31) - 1; Keyboard reading code is in sys/dev/wscons/wskbdutil.c, function wskbd_get_mapentry. It scans the keymap linearly until it finds the key pressed. So, by amount of L2 cache lines eaten, an attacker could tell which class of keys was pressed. Mikulas
Re: Security of the keyboard
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
Re: Security of the keyboard
On Wed, Jun 20, 2007 at 06:14:07PM +0200, Karel Kulhavy wrote: 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. 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. -- Darrin Chandler| Phoenix BSD User Group | MetaBUG [EMAIL PROTECTED] | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation
Re: Security of the keyboard
Karel Kulhavy wrote: 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. Or, on exit to user mode, flush the caches, TLB, and branch target cache. This would kill any such leaks. Or, compile to PIC, and use a random number generator to reassign load addresses every time the kernel is loaded, and break up the kernel into chunks so the addresses used by the keyboard code are unknown. Or, for any process which is CPU bound, sample its instruction stream and if it is using instructions which probe CPU resources, kill the process. Or, who knows... there are probably dozens of ways to prevent leakage of this kind. It's still amazingly improbable that any information could usefully get through this way. Banging on the walls deliberately trying to transfer information from process to process can only send a few bits a second in most cases, which is why getting information about computationally intensive things like cryptography might work.
Re: Security of the keyboard
On 6/20/07, Karel Kulhavy [EMAIL PROTECTED] wrote: 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. so why don't you provide us with a program that recovers the root password? that will make it much easier to assess whether the attack is real or not.
Re: Security of the keyboard
On Wednesday 20 June 2007 12:28:28 Darrin Chandler wrote: On Wed, Jun 20, 2007 at 06:14:07PM +0200, Karel Kulhavy wrote: 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. 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. Karel, If you want to control the keyboard, look for the TEMPEST standard for emi/rf reduction. I'm sure the standard has been leaked by now. That will solve your fears of folks getting data from it. --STeve Andre'
Re: Security of the keyboard
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 don't forget the aps(4) sensor on Thinkpads! The accelerometer can probably measure the acceleration caused by various key strokes and that acceleration will be different depending on where on the keyboard you hit (different angles) and with which finger (different strength). well, and dont' forget the physical attack angle. Between the screen leakage perhaps being used to detect a large number of pink pixels and the aps(4) sensor leakage could probably detect the rythmic thumping when the laptop owner is doing some one handed laptop driving when the other hand is occupied. An attacker could use this information to then physically take control of the machine while the operator has both hands busy and is vulnerable! -Bob
Re: Security of the keyboard
* Bob Beck wrote: 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 don't forget the aps(4) sensor on Thinkpads! The accelerometer can probably measure the acceleration caused by various key strokes and that acceleration will be different depending on where on the keyboard you hit (different angles) and with which finger (different strength). well, and dont' forget the physical attack angle. Between the screen leakage perhaps being used to detect a large number of pink pixels and the aps(4) sensor leakage could probably detect the rythmic thumping when the laptop owner is doing some one handed laptop driving when the other hand is occupied. An attacker could use this information to then physically take control of the machine while the operator has both hands busy and is vulnerable! I just unplugged all my keyboards.
Re: Security of the keyboard
someone already hacked you and sent that message -- be afraid On 6/20/07, Marc Balmer [EMAIL PROTECTED] wrote: * Bob Beck wrote: 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 don't forget the aps(4) sensor on Thinkpads! The accelerometer can probably measure the acceleration caused by various key strokes and that acceleration will be different depending on where on the keyboard you hit (different angles) and with which finger (different strength). well, and dont' forget the physical attack angle. Between the screen leakage perhaps being used to detect a large number of pink pixels and the aps(4) sensor leakage could probably detect the rythmic thumping when the laptop owner is doing some one handed laptop driving when the other hand is occupied. An attacker could use this information to then physically take control of the machine while the operator has both hands busy and is vulnerable! I just unplugged all my keyboards.
Re: Security of the keyboard
That's ok, you can use my wep enabled wireless keyboard!! On 6/20/07, Marc Balmer [EMAIL PROTECTED] wrote: * Bob Beck wrote: 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 don't forget the aps(4) sensor on Thinkpads! The accelerometer can probably measure the acceleration caused by various key strokes and that acceleration will be different depending on where on the keyboard you hit (different angles) and with which finger (different strength). well, and dont' forget the physical attack angle. Between the screen leakage perhaps being used to detect a large number of pink pixels and the aps(4) sensor leakage could probably detect the rythmic thumping when the laptop owner is doing some one handed laptop driving when the other hand is occupied. An attacker could use this information to then physically take control of the machine while the operator has both hands busy and is vulnerable! I just unplugged all my keyboards. -- This officer's men seem to follow him merely out of idle curiosity. -- Sandhurst officer cadet evaluation.
Re: Security of the keyboard
On Wed, 20 Jun 2007, Mikulas Patocka wrote: Yay ! Let's map everything uncached from now on! For great justice! [I was tempted to write some stuff about how keyboard keycode translation works in wscons, but it's not worth my time] Miod You don't have to map keyboard map uncached, just change the way code is written --- instead of x = a[i] you write something like x = 0; for (j = 0; j sizeof a/sizeof *a; j++) x |= a[j] (-(i ^ j) 31) - 1; What an improvement - that is so much more maintainable.
Re: Security of the keyboard
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 don't forget the aps(4) sensor on Thinkpads! The accelerometer can probably measure the acceleration caused by various key strokes and that acceleration will be different depending on where on the keyboard you hit (different angles) and with which finger (different strength). well, and dont' forget the physical attack angle. Between the screen leakage perhaps being used to detect a large number of pink pixels and the aps(4) sensor leakage could probably detect the rythmic thumping when the laptop owner is doing some one handed laptop driving when the other hand is occupied. An attacker could use this information to then physically take control of the machine while the operator has both hands busy and is vulnerable! Physically AND emotionally vulnerable. That's the worst possible scenario. It's bad enough to be pwn3d, nevermind when your blood pressure is up!
Re: Security of the keyboard
Karel Kulhavy [EMAIL PROTECTED] writes: A friend who is happening to write his own operating system just pointed out to me that a keyboard driver cannot use - lookup tables, because timing accessing these lookup tables would yield information what key was pressed when entering a root password - tests and jumps, because the same would be possible with the BTB (branch target buffer). He said he had to write the whole driver using logical operation masking. Does OpenBSD also have this trick? How is the keyboard security designed in OpenBSD to prevent these covert channels leaking the information to an unprivileged process? Your friend needs to get a life. If the environment is so hostile that someone will actually try to extract such data from so much noise without actually visting the admin and convincing him to give access to the machine with money/pain, you shouldn't really allow hostile users on such a machine. //art
