LWN: Comments on "Nocera: iio-sensor-proxy 1.0 is out!"

keyboard sniffing

robbe — Wed, 03 Jun 2015 20:26:45 +0000

That one is easy: only give (real) accelerometer readings to an application/browser frame/UI element that has the keyboard focus. If you generalise "keyboard focus" to "input focus" it makes even more sense.

Other attacks, like the one determining your location in a train system by the experienced jumps and bumps, are harder to mitigate.

Nocera: iio-sensor-proxy 1.0 is out!

ssam — Tue, 26 May 2015 14:03:41 +0000

If the acceleration is exposed to javascript in your browser and is sensitive enough to give you the timing on keystrokes ( http://it.slashdot.org/story/05/09/13/1644259/keyboard-so... ), then you have a problem.

Nocera: iio-sensor-proxy 1.0 is out!

andreasn1 — Tue, 26 May 2015 11:08:38 +0000

Isn't it easier for it to ask X directly for that?

Nocera: iio-sensor-proxy 1.0 is out!

dlang — Tue, 26 May 2015 00:18:43 +0000

And if the attacker is good enough to get this sort of software on the system, why can't they just read the keystrokes directly?

Nocera: iio-sensor-proxy 1.0 is out!

mrjk — Mon, 25 May 2015 03:43:55 +0000

I am not seeing how this product would make you more vulnerable than before? If an attacker is sophisticated enough to decipher accelerometer readings to get keystrokes, and good enough to get software on a laptop to intercept those readings, aren't they good enough to get software on the laptop to read the accelerometer itself?

I guess this could make it easier for less sophisticated to make attacks, but this seems so high level in practice that you are at the professional level. I would expect any kit that could do the movement translation would include software to read the sensor if it was not present, either through this new subsystem or just direct read. I don't know why they wouldn't just insert a keystroke logger if they have that access.

Nocera: iio-sensor-proxy 1.0 is out!

dashesy — Sun, 24 May 2015 17:24:31 +0000

Yes, you can detect shocks/taps. Hard part is to distinguish a shock from another. First, you need a sensor that is not too noisy in that band, then either you have to have a high sample rate and then look for its profile, or rely on the internal sample rate of the chip and set up an interrupt for different tap events, while using lower rate for capture. The event approach will not be very useful though to detect *which* key is pressed (unless keys too far off do not register any event but closer ones do), the former can for example take into account the distance of a key to accel chip and use max amplitude (after some polynomial fitting to fix clipping). A better model should take all 3 axes and look at them individually (as 3 springs taking a shock), and solving wave equations to distinguish different keys on the same radius.

Nocera: iio-sensor-proxy 1.0 is out!

paulj — Sun, 24 May 2015 16:57:31 +0000

I've only tinkered with accelerometers, but it seemed to me the little 'shocks' from tapping a device could be seen in the accelerometer signals - least by eyeball.

Nocera: iio-sensor-proxy 1.0 is out!

dashesy — Sat, 23 May 2015 17:22:30 +0000

I agreed there is information, I use accel to detect activities after all [1], and with precise enough accel sensors we can read heart-rate too. However the setup in [2] uses smart phones but the article is about laptops. Different scale matters when it comes to acceleration (besides the fact that a major application of accel on phones is for games which need good sensors). While accel sensors perform well to detect orientation (stable state), detecting temporal changes in accel readings require high sample rate because you cannot keep it *accelerating* for long when displacement is short (think about taps-scale and it becomes more chaotic). If entering passwords we were tilting the keyboard, the way we do with pins on a phone they could be compared. Again, I agreed, you are right, with enough time, high enough sample-rate, on many devices the error will average out and you get some bits of information (interesting enough to write a paper and work for some 3-letter organization).

[1] <https://www.amiigo.com>
[2] <https://www.schneier.com/blog/archives/2013/02/guessing_s...>

Nocera: iio-sensor-proxy 1.0 is out!

oldtomas — Sat, 23 May 2015 12:48:04 +0000

To put Wahern's statement in other words: if you communicate slowly enough through your channel [1] (in Wahern's words: if you get enough attempts at it) you can compensate for any noise level (assuming the noise is uncorrelated to the signal). So yes, you can inch your way towards the password a fraction of a bit at a time. And a related attack has been demonstrated already [2]

[1] <https://en.wikipedia.org/wiki/Noisy-channel_coding_theorem>
[2] <https://www.schneier.com/blog/archives/2013/02/guessing_s...>

Nocera: iio-sensor-proxy 1.0 is out!

dashesy — Sat, 23 May 2015 02:45:02 +0000

If lets say accelerometer chip has 14 bits (+2 bits of noise), having 1.1mg/LSB is normal, they can be used to detect taps or double taps (with varying degree of success depending on sensor). This is not same as microphones, that after all have to be accurate or our ears will detect the smallest glitches. The original purpose of these accel chips is for manufacturers to detect a free fall, to void warranty. But yes you could be right, with high enough sample rate and capturing enough data.

Nocera: iio-sensor-proxy 1.0 is out!

wahern — Sat, 23 May 2015 02:01:34 +0000

Care to provide a rigorous elaboration and proof of that assertion?

The accuracy and precision necessary to provide a consistent user experience are far stronger than what can be useful to a password sniffing scheme. The past decade has seen tremendous advancements in side-channel attacks, and particularly the ability to derive useful bits from system noise. Maybe you can't deduce the password from a single input session, but 10? 100? 1000?

Basically, if you can't provide a proof of security--at a minimum, proof of constraints that can be usefully applied to gauge security--it's best to either assume it's possible, or at the very least abstain from asserting that it's impossible or probably impossible.

Nocera: iio-sensor-proxy 1.0 is out!

dashesy — Fri, 22 May 2015 23:06:02 +0000

It depends on the accelerometer sensor precision, if the key strokes fall below noise level then no amount of cleverness would suffice.

Nocera: iio-sensor-proxy 1.0 is out!

josh — Fri, 22 May 2015 22:38:55 +0000

For anyone wondering about the security issues with raw accelerometer readings: a sufficiently clever application could use accelerometer readings to get a pretty good idea about what the user typed. At the very least, that can provide enough information to drastically reduce the number of guesses required to get someone's password or passphrase.