Stopping Screenlock Smudge Attacks On Android | Hacker News Reader

Stopping Screenlock Smudge Attacks On Android

whispersys.com

127 pointsmoxie31 comments

Open articleView on HN

I like the new trend of replacing the unlock button with a fingerprint reader-

http://cdn.cbsi.com.au/story_media/339308370/moto-atrix-fing...

Not only is is faster and more secure, but it also creates many interesting opportunities:

-User accounts with different permissions (your kids could play games but not access the dialer or edit files).

-different actions for different fingers (ring finger sends a call to voicemail).

-True wallet replacement (square could have a field day).

-A trustworthy form of temporary bricking would nearly eliminate simple theft (10 wrong swipes and you have to visit a vendor with some id to have it unlocked)

A fingerprint reader is probably more secure, but actually wouldn't solve the "smudge" problem. You've most likely left latent prints all over your phone. These can be used pretty easily to create a fake finger that would probably fool the sensor.

Additionally, the history of swipe sensors in laptops is a mixed bag as far as this sort of solution goes. They are in almost all laptops, but almost no one actually uses them. Most people perceive them as too much of a hassle compared to the standard username/password setup. Maybe if phones start holding data that people value more (like digital money) they'd be willing put up with the additional work of using the sensor.

The ultimate solution would probably be something that grabs the biometric data without the user having to do anything special. This would make it easier to use and more secure. Apple actually already has a patent on this: http://www.engadget.com/2009/03/27/recent-apple-patent-filin...

> These can be used pretty easily to create a fake finger that would probably fool the sensor.

At this point aren't all bets off? If a person is willing to do that, I would think they'd also be willing to disassemble the phone and extract the information that way. You would need a sort of whole-disk encryption too.

Main problem with any kind of biometric authentication is that it cannot be used as basis for generating encryption keys (eg. for whole disk encryption). Because in that case it's totally irrelevant if you can fool the sensor, you just have to process somehow "stolen" biometric data in same way as the sensor (+ encryption software) does.

For other authentication applications, all security lies in fact that it's not possible (for reasonable values of "possible") to fool the sensor or bypass it. But most commonly used fingerprint scanners are incredibly easy to fool (even including so called "high-security" sensors that happily accept photocopy of fingerprint as valid finger). Bypassing the sensor is often even easier, but on the other hand I've seen systems (for example BIOS level fingerprint authentication on ThinkPads) that are explicitly designed as to make that very expensive (in the ThinkPad case you would have to actually decapsulate the sensor chip from it's package).

Finger prints are good for identification (think username), but horrible at authentication (think password). We leave finger prints all over the place.

I disagree that fingerprints are a secure form of authentication. As the Chaos Computer Club has shown, it is relatively simple to create duplicates of fingerprints that can fool sensors.

In essence, relying on your fingerprint for authentication amounts to leaving a copy of your password on everything you touch.

Did you consider the idea of a combination (circular) lock?

I suppose it may be possible to decipher the stopping points, but if there's a final circle to confirm the code/cover them up, I could see that working.

edit: added "(circular)" to clarify

You could fix this by randomizing the orientation of the lock.

That would be a usability nightmare if I am picturing what you are saying correctly.

It wouldn't be that bad to have it start on a different number every time. It means that you would have to actually pay attention to the unlock process though, muscle memory wouldn't work.

I think that's exactly what I thought when I read his comment. I'm not sure why anyone else thinks it's a bad idea, though.

Let me clarify it a bit: Just like a rotary telephone, the numbers are in a circle. To open the lock, you drag your finger in a circle around the ring, alternating left and right like a combination lock.

But to make sure the smudges are meaningless, the device rotates the rings randomly before each attempt.

You still enter the same code, in the same pattern, but the rotation of the device changes each time.

A rotary dial lock seems like it would be a good idea... Especially if the set number of digits was variable. All you'd see is a round smudge.

I think if this worked like setting 'an alarm time' on iOS, it would work. I can't see how one would know where a dial's 'rotation' stopped; specially if the 'dials' always started from a random digit.

Let's say your combo is 74798; one occasion the unlock shows 31920, next 88935, etc. but never opening the phone on a collision. So if it lands on 74798 (your current combo), it would not unlock the phone automatically.

On the vertical PIN one: Wouldn't it be better to use something similar to the default PIN input and randomize the position of the numbers?

It shouldn't be too hard to catch someone PIN when they enter it on a static vertical list. Then again, neither is it on the default static PIN grid.

We considered this, but decided that people want to use muscle memory in order to quickly unlock their screens, rather than hunting for the correct digits in a randomized layout. This allows you to quickly go through the motions, and only adds one extra gesture.

But security is the whole point isn't it? Seems to me that having them hunt for the correct digits is the right thing to do.

Not being annoyed every time you unlock the phone is often a higher priority. Especially when you have to opt in.

Security and usability are 2 orthogonal design choices.

This is a great example of combining information into promotional material. Well done. Good luck with Whispercore.

just make sure you turn off usb debugging after installing, otherwise all of this is useless.

Interestingly if your 4 digit key for iPhone has a digit used twice then it is harder to guess the correct order given the smudge marks:

    4 distinct digits = 4! = 24 permutations
    3 distinct digits (one repeated) = 4!/2*3 = 36 permutations

Note: division by 2 is because of the symmetry of swapping the order of the repeated digit, multiplication by 3 is because it is not known which of the 3 digits is repeated.

Note2: Using 2 distinct digits (both used twice or one used 3 times) is not as ideal as that results in: 4c1*2 + 4c2 = 14 permutations

I wonder how secure the screen lock pattern option really is. I notice that the OS requires that the user draw at least four dots in their pattern. In theory, then, you have sum((9!/5!)+(9!/4!)+...)=9!(sum(1/n!)) options, where the integer n ranges from 0 to 5 (representing the 6 dot count options), or 985,824 total options. That's almost 20 bits strong, similar to a 6-digit base-10 pin.

BUT: That's if you use it like Swype for a 9-digit keypad, choosing a truly random 4- to 9-digit pin with no repeating digits. I'm not sure that's really possible: can you move between opposite corner dots without hitting the center dot? I speculate that in practice this input mechanism encourages a much smaller pool of options. For instance, in my anecdotal experience most users will only move to adjacent dots and won't cross their lines (presumably due to their cultural heritage of Tron and Ghostbusters). That turns this into a graph problem, and you would probably have to write a simulator to get the real numbers.

... Here's that simulation, in C++: http://pastebin.com/xKd7UMr3

Note that the adjacency constraint implies the no-crossing-lines constraint. Total possible paths given the constraints: 10096. That is a nontrivial reduction in bit strength, from 20 bits to less than 14, or from 7 to 5 base-10 digits. As a complimentary check, if you eliminate the adjacency constraint in the simulator you will see the expected 985,824 number.

Experimentation on my Droid X running the 2.2 OS indicates that you not only must wait 30 seconds after every 5 invalid patterns, but are locked out completely after 20 (at which point you have to login with your Google account to regain access). The OS remembers the number of invalid attempts across reboots, even if you abruptly cycle the power by pulling the battery out of your poor little Droid X.

Suppose an Android phone firmware was not quite properly implemented, and the invalid attempt count was only flushed to nonvolatile memory every, say, five attempts. I might then build a brute force pattern cracking machine, something servo-driven with a stylus to contact the screen (à la Clarke's "Rama II"). If my cracking device takes 3 seconds to try a pattern, and assuming a 40-second boot time, I would need 52 seconds to make 4 guesses, or 13s/guess. For the ideal case of 985,824 equally likely options, I would have to run that machine continuously for over 21 weeks to try every pattern. Given the adjacency constraint, however, I would need less than 37 hours -- a day and a half! -- to try all 10096 possible patterns, and would expect an average search time of about 18 hours.

Would the average user change their passwords if they accidentally left their smartphone in the office for the weekend (60 hours)? But this doesn't even need to be a single block of time. Does your significant other have access to your smartphone during weeknights (8hrs * 5 days = 40 hrs)?

Though if you have the kind of significant other who discovers your phone has a minor firmware flaw, builds a servo-driven cracking device to exploit it, and proceeds to steal your phone every night while you sleep, your life was going to be difficult anyway.

[EDIT: "No crossing lines" is a vague description. What I mean is that I don't see many users go back across a previously-visited dot to reach an unvisited dot. Since a dot on the other side of a previously-visited dot would have to be at least two dots away, the line-crossing constraint is covered by the adjacency constraint. As far as I can tell, the line-crossing constraint is actually somewhat enforced by the Android OS: you are not allowed to cross over unvisited dots without the OS forcibly "visiting" the intermediate dot on your behalf, although you are allowed to cross over visited dots.]

I don't understand the point of your post. You do a great job of calculating the strength of the Android pattern lock screen and then explain why that's totally irrelevant because of the 20 invalid entries hardlock. You could have just put that first, and saved yourself the tldr, but then you mention a few improbable hypotheticals for no discernable reason. Am I missing something?

The timeout behavior I describe is only for the Droid X model. For instance, I'm told that variants of the Galaxy S series (e.g. T959) have a 30s delay every 5 tries, but no limit on total tries. That would be a little easier than my 13s/try scenario above: (30+5*3)/5=9s/try, or 13 hours average crack time.

Regardless of whether your device has a limit on total attempts, you ought to be aware that the security of your lockout resides not in the complexity of your pattern, but rather in a subtle facet of your phone's volatile->nonvolatile memory transfer timing.

I use a password screen lock that repeats some keys (sometimes with caps lock). It leaves smudges around the keys, but you would have to guess what order they are in, how many times they were pressed, and whether it was an upper/lower case key or a symbol... Seems pretty good to me.

I would still like to have my data encrypted though...

Maybe its just me, but why not wipe your screen with a flannel cloth or even your t-shirt every so often. That would take care of most of the more egregiously straight-forward attacks won't it. This of course assumes that you have fairly secure number based key to begin with.

Is the "draw a shape" screen unlocking optional and do people find it preferable to a number pad?? It seems kind of like a silly gimmick to me.

the pattern locking is optional in android. i use it just like a pin, but because it's a pattern, i get to swipe between the numbers (which are points on the pattern screen) instead of tapping and lifting on each one, so it's faster.

It is one of the options - personally I find it much, much faster than a PIN or a password.

But in principle you can change it to anything you want (since you can replace the component).

It's actually a really nice feature. It's quick, potentially (barring grease smear issues) more secure since you can use all nine points on the screen, and always optional.

This is one thing I've found that my Apple using friends are always a bit jealous of because it is slightly easier than punching in a pin number.

Ah, I didn't realize you could use all nine points, my thinking was that it limited your options since there were fewer points and you couldn't repeat... but clearly that was wrong :)

Reply on news.ycombinator.com