Handset cohabitation: Ubuntu for Android [LWN.net]

Handset cohabitation: Ubuntu for Android

Posted Mar 5, 2012 23:15 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
In reply to: Handset cohabitation: Ubuntu for Android by oak
Parent article: Handset cohabitation: Ubuntu for Android

Android works fine with encryption (which is usually hardware accelerated).

However, mobile devices have problems with _passwords_. It's way too complicated to enter strong passwords using keyboards. And alternative methods like "draw a pattern on a grid" are too easy to brute-force (they barely have 30-40 bits of entropy).

to post comments

Handset cohabitation: Ubuntu for Android

Posted Mar 6, 2012 7:50 UTC (Tue) by khim (subscriber, #9252) [Link] (7 responses)

“Draw a pattern on a grid” is used to unlock the device which was already turned on. It has nothing to do with the encryption password. You enter encryption password about once per day at most (as I've said: you only need to enter it when the juice runs out) thus it can be quite long and complex.

Handset cohabitation: Ubuntu for Android

Posted Mar 6, 2012 11:00 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

It's still too much - for me it can take more than a minute to enter my 15-letter password. Especially if I have only one free hand at the moment.

I'm thinking about making a remotely-accessible 'password server' with weak PIN-like security.

Handset cohabitation: Ubuntu for Android

Posted Mar 6, 2012 18:16 UTC (Tue) by khim (subscriber, #9252) [Link] (5 responses)

It's still too much - for me it can take more than a minute to enter my 15-letter password. Especially if I have only one free hand at the moment.

And this is a problem… exactly why?

I'm thinking about making a remotely-accessible 'password server' with weak PIN-like security.

If you want to design "pipe-in-a-sky" solutions then it's simpler to just reuse already existing SIM care to store password. Still will require quite a lot of code on uncrypted "startup" partition but will be usable, for example, when your magic server will not be available (because your service plan does not include data roaming, for example).

Handset cohabitation: Ubuntu for Android

Posted Mar 6, 2012 18:37 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

>And this is a problem… exactly why?

If something is too complex - it won't be used.

>If you want to design "pipe-in-a-sky" solutions then it's simpler to just reuse already existing SIM care to store password. Still will require quite a lot of code on uncrypted "startup" partition but will be usable, for example,
I don't want to store the decryption key in permanent storage on my phone (or its SIM-card which can be read easily).

>when your magic server will not be available (because your service plan does not include data roaming, for example).
That's why I'm going to add an SMS-based protocol. 130 characters are more than enough for secure key exchange.

Handset cohabitation: Ubuntu for Android

Posted Mar 6, 2012 20:54 UTC (Tue) by khim (subscriber, #9252) [Link] (3 responses)

>And this is a problem… exactly why?

If something is too complex - it won't be used.

Well, thank you for explaining why your Goldberg-style solution will not be used. I wanted to see why single-password solution will not be used. Hint: it works and is actually used by real people on laptops, so why not on phone?

>If you want to design "pipe-in-a-sky" solutions then it's simpler to just reuse already existing SIM care to store password. Still will require quite a lot of code on uncrypted "startup" partition but will be usable, for example,

I don't want to store the decryption key in permanent storage on my phone (or its SIM-card which can be read easily).

Depends on the manufacturer. Cards used by banks to protect million-dollar transactions are not principally any different from SIM card.

>when your magic server will not be available (because your service plan does not include data roaming, for example).
That's why I'm going to add an SMS-based protocol. 130 characters are more than enough for secure key exchange.

130 characters are just 1040 bits. Not enough to organize robust asymmetric signature. And you'll need some payload, too. Feel free to invent some complex unreliable overengineered solution, but don't expect anyone to consider it seriously.

Actually... I take that back: if you'll handwave enthusiastically enough and will talk about advantages boisterously enough you can sell your snake oil to some phone companies.

I guess “anyone” should be replaced with “anyone who understands basic security principles”.

Handset cohabitation: Ubuntu for Android

Posted Mar 6, 2012 21:21 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

>Well, thank you for explaining why your Goldberg-style solution will not be used. I wanted to see why single-password solution will not be used. Hint: it works and is actually used by real people on laptops, so why not on phone?

Encryption is barely used in real-life on laptops - people just _like_ it when they can pop open the laptop lid and start typing without bothering to enter a password. Or having to enter a strong password during the login process. And that's on PCs that have an easy-to-use keyboard.

>Depends on the manufacturer. Cards used by banks to protect million-dollar transactions are not principally any different from SIM card.

Banks use HSMs to protect transactions. And then they also use unsecured SMS for million-dollar transaction confirmations. So "what the banks use" is not a good indicator of security.

>130 characters are just 1040 bits. Not enough to organize robust asymmetric signature.
That's enough for elliptic-curve signatures. But you don't need them, anyway.

>And you'll need some payload, too. Feel free to invent some complex unreliable overengineered solution, but don't expect anyone to consider it seriously.

Nope. Your phone and the password server would have a shared secret (apart from the PIN) established during the initial setup procedure, no need for anything asymmetric.

So you only need to pack a nonce (128 bits), an unlock PIN (128 bits should be enough), encrypt it with your shared secret and send as an SMS. Even with base-64 or binhex encoding it'll take less than 80 symbols.

>I guess “anyone” should be replaced with “anyone who understands basic security principles”.

How about "if a security feature is hard to use then it won't be used"?

Handset cohabitation: Ubuntu for Android

Posted Mar 7, 2012 8:46 UTC (Wed) by khim (subscriber, #9252) [Link] (1 responses)

Encryption is barely used in real-life on laptops

All company-ensued laptops are encrypted here. Encryption of phones is “strongly encouraged” (required by people in some sensitive positions).

people just _like_ it when they can pop open the laptop lid and start typing without bothering to enter a password.

It's their choice. BTW you do understand that even if phone is protected by strong password when it click the “power” button you are presented with usual “draw a pattern on a grid” screen, right? You only need to enter password if you tried to “draw a pattern” three times incorrectly or if your phone run out of juice and was powered off totally (not just went to sleep, but was fully powered off).

Banks use HSMs to protect transactions.

Yup. I'm talking about these. As someone who participated in creation of HSMs (albeit few years ago) I can assure you: they are made using the same principles as SIM card. If you want to stuff HSM in SIM, it's easy to do. Or you can embed it in phone SOC.

So "what the banks use" is not a good indicator of security.

It is. Security is not binary, it's a continuous scale. If you need security higher then “what's the banks use” then you probably need military grade security and in this realm you can just order people to use password of certain quality.

So you only need to pack a nonce (128 bits), an unlock PIN (128 bits should be enough), encrypt it with your shared secret and send as an SMS.

This scheme is quite vulnerable to MITM attack. Just catch first request, allow the next one (user will just assume first request was lost), then play it when the phone is in your possession. This is essentially the same level of protecting as HSM in SIM but with much larger infrastructure.

How about "if a security feature is hard to use then it won't be used"?

It depends on how much people value their information. Security and convenience are always at odds: you can try to improve security without adding “hard to use” steps, but you can only do so much.

Handset cohabitation: Ubuntu for Android

Posted Mar 7, 2012 9:24 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

>All company-ensued laptops are encrypted here. Encryption of phones is “strongly encouraged” (required by people in some sensitive positions).

Companies can force people to do quite a lot. How many end-users have their hard drives encrypted, though? Not much.

>It's their choice. BTW you do understand that even if phone is protected by strong password when it click the “power” button you are presented with usual “draw a pattern on a grid” screen, right? You only need to enter password if you tried to “draw a pattern” three times incorrectly or if your phone run out of juice and was powered off totally (not just went to sleep, but was fully powered off).

Of course, I understand that. But for me fully powering off my phone can happen several times a _day_ when I have to change batteries.

>Yup. I'm talking about these. As someone who participated in creation of HSMs (albeit few years ago) I can assure you: they are made using the same principles as SIM card. If you want to stuff HSM in SIM, it's easy to do. Or you can embed it in phone SOC.

Well, I had my SIM card's contents dumped without any troubles a couple of years ago when I was playing with software-defined radios. So I'm a bit skeptical about actual security, though of course one can fit almost anything on SIM cards these days.

>This scheme is quite vulnerable to MITM attack. Just catch first request, allow the next one (user will just assume first request was lost), then play it when the phone is in your possession.

No it isn't. I've specifically mentioned that nonces (numbers that are used only once) should be used, against this very attack.

>It depends on how much people value their information. Security and convenience are always at odds: you can try to improve security without adding “hard to use” steps, but you can only do so much.

And I intend to push limits a bit on some of the 'easy' ways to encrypt data.