Handset cohabitation: Ubuntu for Android [LWN.net]

Handset cohabitation: Ubuntu for Android

Posted Feb 26, 2012 0:53 UTC (Sun) by dlang (guest, #313)
In reply to: Handset cohabitation: Ubuntu for Android by jspaleta
Parent article: Handset cohabitation: Ubuntu for Android

one thing that you (and many others) seem to be missing a little bit is that the most expensive external component is the screen, and in many cases that does not need to be a dedicated device, instead it can be a HDTV, i.e. anything with an HDMI input

I also disagree with you on the amount of storage needed. You don't need hundreds of gigs of storage, tens of gigs can do very nicely, and that is available today on phones (and will be even easier/cheaper going forward)

Ubuntu can be pretty comfortable in single-digit Gigs of space for a fairly complete installation, it's media files that eat up so much space for most people

At that point, external storage becomes a performance option, not a requirement, and the only 'dedicated' peripheral that is needed is a keyboard/mouse set, and those are pretty cheap, even if you want a wireless set, and dirt cheap if you get a Android device that will let you use UDB versions.

I fully expect that there will be more expensive dock sets out there, but the question will be what is it that you are looking for? if what you want is a laptop/phone (like the Atrix), you will pay a premium for it.

but if you want the ability to work the same way both at home and at the office, it should be pretty cheap.

I expect that the first round of manufacturers will be pushing this capability with proprietary docking stations and the associated prices, but I don't think it will be long for some of the other manufacturers to make cut-rate versions that just use standard peripherals

to post comments

Handset cohabitation: Ubuntu for Android

Posted Mar 5, 2012 22:01 UTC (Mon) by oak (guest, #2786) [Link] (10 responses)

You can also extend your storage space with a fairly large SD cards nowadays.

I think the main issues will be RAM and display size.

1GB of RAM is very little nowadays for typical desktop/office use-cases. I was using a laptop with 2GB of RAM until recently and just having Thunderbird (with lots of mails) and Firefox (with lots tabs) open it gets really slow with swapping when I try to view (with OpenOffice) some docs I get in mails...

Phones are unlikely to get a lot of RAM soonish because with larger amounts of RAM, the RAM refresh eats too much battery and the phone SW itself works fine with 1GB (or even 0.5GB) of RAM.

If one uses just Browser, like was assumed in the Moto case, I guess 1GB is mostly enough (now that we've gotten mostly rid of Flash).

The display problem is that the embedded gfx chips in the phones are intended for smaller resolutions. If you connect them to a full HD display, either you got something running on non-native resolution which looks unusably crappy for day-to-day work, or the resolution may go over the phone GPU capabilities or what its 3D driver has been tested for.

I think on travels having just phone, a smallish wireless keyboard and larger display at hotel / remote work place may be fine as phone+netbook combo replacement, but for day-to-day work it's not enough.

Security is also an interesting question... Companies typically require laptop disks to be encrypted, but how well phones work with encrypted file systems? (giving password to mount the disk etc)

Handset cohabitation: Ubuntu for Android

Posted Mar 5, 2012 22:24 UTC (Mon) by khim (subscriber, #9252) [Link]

Companies typically require laptop disks to be encrypted, but how well phones work with encrypted file systems? (giving password to mount the disk etc)

Even with full-disk encryption (ICS supports it at least on Galaxy Nexus) you only specify password once when you turn the device on after full power-off. It does happen often with phones.

Handset cohabitation: Ubuntu for Android

Posted Mar 5, 2012 23:15 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (8 responses)

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).

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.