Android app logs keystrokes using phone movements Computer scientists have developed an Android app that logs keystrokes using a smartphone's sensors to measure the locations a user taps on the touch screen. TouchLogger, as their demo app is dubbed, allowed its creators at the University of California at Davis to demonstrate a vulnerability in smartphones and tablets that has …
... would seem to be to turn off accelerometers, gyroscopes, and (optionally) cameras after the first keypress on a device's (virtual or physical) keyboard, then don't let the sensors reactivate for, say, the first 500ms to 2 seconds after the last-registered keypress.
Since passwords, social security numbers, and other ID-oriented strings are likely to be entered quickly, because of the advantage of "muscle memory," it's improbable the device would encounter long delays between the keypresses used to enter often-repeated data. Therefore, a 1/2-second to 2-second delay in re-enabling the sensors should suffice to reduce the input inference score to 5 percent or less, depending on the length of the string being entered.
Make the number pad that comes up to unlock the phone random i.e. numbers randomly placed so you're never hitting the same sequence, as far a layout is concerned, every time. Would take a bit of getting used to as opposed to 'muscle memory' typing of the pass code, but would be a small price to pay.
Not sure I follow... How so?
I'm sure the keypress event processor could be written so that when an app is requesting purely textual input (i.e., such as a web browser pointed at a bank's login page), the motion and optical sensors are turned off, but when the keyboard is being used for non-confidential input in conjunction with motion events (such as during a game), the sensors remain on.
The disadvantage to this method (selective disarming of sensors during keyboard use) is that you're removing a side-channel attack at the expense of introducing API feature that needs to be heavily debugged to make sure it can stand up to code injection/redirection attacks.
http://www.theregister.co.uk/2011/08/12/amazon_patent_jets/ describes a patent application for detecting that you have dropped your phone. I think I'd go for deploying a shock absorber of some kind, or maybe pegs at points around the screen so that the pegs hit the ground before, and instead of, the glass. Or a pulse of sound from the audio to hurl the device in the opposite direction just as it hits. Or just The Wilhelm Scream. Actually, it may be more applicable to military tablet devices.
Having said all that, I think that disabling the motion sensors when the device is being typed, tapped, or written on is completely appropriate. Then again, not everything that you do on your device is so confidential.
Since it allows multitasking only by a WebOS-inspired event-based model, with a program declaring itself to be within one of a few well-defined categories. Other programs put into the background are completely suspended.
In fact, I'd assume WebOS is safe too. But I'm not as up on that as iOS and Android.
Effectively yes - or at least it doesn't affect iOS.
Android remember boasts 'full multitasking', which means a background process can be capturing this info while you are browsing the web or entering password data into a different App.
iOS also has a sandbox model that will (as of iOS 5), require Apps to specify exactly what permissions they need - and during the Approval process explain exactly why they need them.
Won't help you, I suspect. The movement of the bus will generate completely different waveforms from a keypress; generally much higher amplitude and longer wavelength. Possibly the vibration from a low-revving diesel might drown out the keypresses, but a held phone is probably quite well isolate from that sort of thing by its holder.
Worst case (for the application) I imagine that an offline postprocess would be able to filter out a wide range of environmental noise given a bit of human guidance.
But...
Think of the range of Android devices. All shapes and sizes. The software would be thrown a bit because, say, your Samsung screen is closer to the edge of the phone than someone else's HTC. Different battery locations inside the body of the phone will alter the vibrations too.
iPhones have only a few different models. More likely to be calibrated for the device.
Sure on a tablet the buttons can be bigger, but the angular acceleration is not. ie. button size/ distance is about the same.
Further, the mass is larger so the acceleration will be reduced (a= F/m).
As for killing this off, it might be enough to just add noise and degrade the accelerometer/gyro while the keyboard is active.
1. Design for mobiles and tablets a stabilizer similar to what camera handlers use, what, a steadycam or gyroscopic stabilizer.
2. If the phone is not mesh-EMI/Tempest shielded, then do so so that signal leakage is reduced
3. Sell the user a black box. Really, a furry, fuzzy, round or other-shaped box - with a lid, like Spock's raster scanner or something like colored, shielded swim goggles.
4. Redesign the phone to delay the entry of keys in one buffer so they don't correspond to what is displayed, sort of like one of the earlier suggestions. Have them randomly present in oval, circular, square, star, and helical shapes -- the keys themslves and the paths they take. Yes, paths. The user would have to slide together two or more fingers to "assemble" the letter being keyed so that gyroscopic effect is reduced.
5. Scramble the gyros, accelerometers, and other devices to all record one letter, or spew out War and Peace. Yes, War and Peace. Or, some trash called Whore (data) and Piece (you've been shafted, snooper)...
Just some quick ideas...
(This is released into whatever GPL/GNU/Creative Commons/et all that obstruct/s any attempts to proprietarized these ideas posted here by me regarding this privacy issue.)
But, attribution is not required. I just want to make sure this idea stream 1-5 will be available to any and all who wish to resolve this privacy risk.
Android allows custom keyboards to be used. Different keyboard layouts are going to have different movement characteristics.
BTW, I hereby announce I have a patent pending on varying keyboard layout for entering secure information by above or any other in decipherable means. I'm sure if I reworded it carefully I could sue Apple, Google, MS and everyone in the world for non clear text passwords, I'll split the money with most water tight wording.
This post has been deleted by its author
I don't believe this at all.
Sure, it may work fairly well under certain circumstances but I bet it can't take into account texting while walking or any other activity (like someone else said travelling on cars/buses), Swype sotware, whether a person uses two thumbs to text in landscape or a single digit in portrait etc etc.
The point is there are so many variables I don't think this would work at all in practice and is just a way for the Uni Of California to raise its profile...
"iOS also has a sandbox model that will (as of iOS 5), require Apps to specify exactly what permissions they need - and during the Approval process explain exactly why they need them."
Just randomly putting something in about iOS 5, even though it would not help with this at all. Android has fine grained permissions, requiring approval from the user, before installation and is sandboxed. Doesnt help, as its not accessing any other apps, its using its own access rights to the handset, which arent interacting with anyother apps. Create a game, which is controlled by moving the phone about, have an online score board, you require gyroscope, accelerometer and internet access, approved as it needs them, there we go I have access to what is need to log this.
Sandboxing, no help at all, and fine grained permissions will not help if the app you are installing uses those functions and has this logging hidden in it.
If events for suspended applications dont include the detection of movement to wake them up, or doesnt allow them access to them when an event is triggered, then it is safe. But because it doesnt do full multitasking, not because of any new features in iOS.
As opposed to saying "oh god, this is horrible", could it be used to implement an alternative input method that lets people type on the back of the device, rather than having their fingers in the way of the screen? (I know there are devices with touchscreens on the back, but this sounds like a less accurate but possibly useful alternative.)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
