This is the discussion thread of the Brainstorm proposal Another way to lock/unlock the device

Only to mentions that creative and innovative solutions are welcome. The person working in this area is Elena Reshetova, some of you met her in the maemo Summit in the Maemo 6 Security Framework session.

Hi qgil && Elena,

There is any proposal to have an API where a 3rd party app can make use of it
to lock or unlock the device?

Run an application in full screen grabbing all the inputs is not an
alternative, since that kind of approach inhibits the user to be visually
alerted about new calls or messages, for example.

The current implementation has a set of options to lock the screen, w/o
password protection, and also it can be annoying to the user to type a
numeric password instead of do a gesture, for example.

It is not clear for me that an API is the best solution, since a poorly
implementation can disclose some user information. If the platform
provides that API, it will be passing the control of its security to a 3rd
party application making a "vulnerability" point, a weakness. Unless if the
platform provide a kind of capability system.

Keeping in mind that an authentication can be done by validating at least of
the following [1]:
* Something you know, such as a PIN or password
* Something you have, such as a smart card or token
* Something you are, such as a fingerprint

Maybe the platform should provide all that kind of methods that can be
selected by a "theme-able" screen saver password dialog, configured by
the 3rd party application, but controlled by the platform.

Just to startup a discussion

Thanks :P

[1] CISSP Study Guide - www.isc2.org

How about something like MyKeyLock from Symbian ?
http://www.youtube.com/watch?v=JqHKzOW_mw8

First of all, physical access is jackpot. Therefore, advanced, high secure methods of authentication aren't very effective because all data is plain text on flash. They're rather necessary on a different layer such as in whole disk encryption (LUKS, TrueCrypt) or keyring (gnome-keyring, keepassx).

Therefore, it makes sense to provide authentication methods in a library so one can authenticate with other services as well. These layers can be disabled or enabled by user request. This could range from SSH access to login on t.m.o. Sounds scary? Perhaps. But if you use a password to access your keepassx database, and this is compromised, your data inside is wide open. Whether you use the SSH key automagically once authed, or have to manually use it, is of no concern.

• One time passwords; allow user to generate OPIE keys in situations high security is necessary.
• MicroSD with key

The following I came up with as well but they're rather easily circumvented however together with another method they're 'fun'. Also, it is important to note a PIN based authentication where user must press buttons to authenticate is not strong either because such can be read by human eye and camera (see skimming of ATM cards).

• Facial recognition on camera; more difficult to mimmick than next 2, but our photos are widely available, 3D printer should do the trick.
• Fingerprint recognition on camera; can be copied with magnesium + sticker (plenty available especially on device), should not be used only or for serious authentication.
• Voice recognition; can be copied by microphone (widely available and used by humans), should not be used only or for serious authentication.
• Blue Proximitry; BT addr can be cloned, rather more interesting to use the N900 for BlueTooth authentication with home computer or laptop.
• RFID; same as BT, and actually easily cloned (see Melanie Rieback's RFID research), but supposedly not widely abused yet.

The user can select several authentication methods, and is able to stack these. For examples:

• Requiring fingerprint AND MicroSD card
• Requiring OPIE OR PIN
• Requiring ONLY fingerprint

Besides BlueProximity, GPS can be used to determine the allowed and/or denied authentication methods. This allows one also, for example, to use different PIN in different situations.

Pseudo-plausible deniability: Something else cool, is that when authentication keeps failing, thing logs in, but its all dummy honeypot... which could provide some kind of plausible deniability when one is forced to log in to their phone.

Sidenote: None of the above covers locking the device again while this is important as well.

References: Linux-PAM modules, BSD_auth, RFC2289 A One Time Password System, RFC1760 The S/KEY One Time Password System.

The two most viable solutions of above post: One Time Passwords and Public Key Infrastructure are added in Brainstorm. The proposals suggest to use currently available PAM modules.

We have currently already 3 Methods to unlock the device, right?
1.) Click on the power Button once and use your finger to slide the regulator right
2.) open the camera slot to go from locked to unlocked camera mode directly
3.) use the lock-button (switch it up to lock or to unlock)

I think i'll be only using method 3, because it's the fastest method to go back to your homescreen & I honestly think we don't need any more methods, because things like double click would require an enabled touchscreen in lockmode even when the screen doesn't show anything, which means more battery consumption instead of pressing a physical button.

edit: When it comes to security, touchscreens can't scan fingerprints unfortunately, so I think we should stick to a predefined gesture that unlocks the device. Voice unlocking should be possible, too, but I wouldn't prefer that, since you need to unlock your phone in the public aswell.

solution no.1 is i think pretty cool for the end user in general...you guys could come up with something more innovative to unlock though

I would prefer solution number seven (#7)

Solution 1, although convenient, does not offer enough security IMO, due to it being develop by third party. I would prefer that it is something built-in with the OS. If password is not known and someone decides to reset the phone to factory, all data is erased; or all data is unreadable sort of like a HDD when you use its lock/unlock code, if you lock the drive, when you enter a wrong code it wont work, not even by formatting as it will not be readable.

As far as the other methods/solutions, honestly, i do not know/understand how they are intended to work, (solutions 4 and 3)

Also, i dont know if the Android interactive method of locking the phone can be used, but i think thats a little more convenient than typing a password out.
to play off of android's "draw lock", how about a simon says sequence:

there are rows of colors
column
row A B C D E
1 red red red red red
2 blue blue blue blue blue
3 green green green green green
4 white white white white white

[Edit: the grid did not come out like i thought it would but i hope you can see what i am trying to imply. 5 similar set columns with 4 different rows of colors. these colors represent the colored buttons that the operator will press in a sequence for his/her unlock pattern. Like "simon sez" the user will have to press the same color sequence they set initially to unlock the phone. see below for example]

your sequence of presses can be something simple as 1A, 2A, 3A, 4A or something complicated as 1C, 4C, 1C, 4C, 2B, 2D, 1A, 1B, 3E (although that sequence may look complicated, to me i would remember it as up, down, up down, left, right, A, B, start[old cheat nintendo cheat code])
The user could memorize by either color pattern/sequence or position of thumb placement or whatever they visualize in there head.

what if it was something fun

a bit different
plugin screensavers which respond to touch and let you unlock if you want.