Hacker News Reader

Comment by JoshTriplett | Hacker News Reader

Now if only it was possible to turn off remote installation of applications on both iOS and Android devices, this kind of security would actually mean something.

Right now, you can do full disk encryption on an Android device (which seems likely to become hardware-assisted on future devices similar to the solution mentioned in the article). If you pick a sufficiently strong passphrase, that should keep your data secure even on devices without hardware assistance. However, if the device is turned on and locked (the common case), it's trivial to remote-install an arbitrary app, including one that unlocks the phone. (You can do this yourself with your Google account, which means anyone with access to that account can do so as well.)

It would help to be able to disable remote installation of any kind; that wouldn't have to come at the expense of convenience, because the phone could just prompt (behind the lockscreen) to install a requested app.

View on HN

On Android devices at least, you can use the always-on VPN functionality and a VPN Server and HTTP/S proxy to achieve this, it's actually not as hard as you might think.

For home users, Sophos has a Home Edition of their UTM that you can install on an old PC. The requirements are a bit high, there's an IP limit (that you could always overcome with a NAT) and it doesn't allow dual-homed ISPs, but the UI is better than anything else I've tried (not saying there aren't plenty of warts). Once installed, you can setup a VPN and HTTPS proxy within literally 2 minutes.

Disclaimer, I worked there for a short time.

I've been thinking about the possiblity of commercial software updates being used as an attack vector to overcome WDE. Could you imagine if the NSA went to Apple or Microsoft and said "push this compromising update to computers from this IP address/MAC address/serial number"?

That's quite possibly no longer a theoretical scenario at this point. It would really surprise me if you were the first person to think of that trick (it's pretty obvious) and that + gag orders would do nicely. Parallel construction to plug any holes in case someone wises up that this is already done in practice.

Parallel construction has to be one of the most unconstitutional things I have ever heard of. It's fraud and perjury.

But but but... they're criminals! The ends justify the means, right?

As far as I know, it can install an app but not run it (EDIT: on Android, that is). So it shouldn't be able to do any such decryption.

The problem is the attack surface for an app on a device vs. in the wild is much, much larger and much, much less secure.

Once its on your phone, it can just screenshot things if nothing else.

I wrote myself a database that I use for passwords and the like. I get around this by masking text until I tap a button, and then waiting a random number of ticks before decrypting the value and progressively unmasking the text. It takes between ½ and two seconds. The problem I've yet to solve is hiding the text. Leaving it on-screen for, say 10 seconds before re-masking and encrypting is fine for now but sometimes that's not long enough.

The other thing it does is with a tap and waiting for the same random number of ticks is to copy the value to the clipboard so that I can paste it into a browser.

Not perfect but its a version 1 at least.

You should try 1Password: https://agilebits.com/onepassword

It's the most recommended password manager on Hacker News.

Thanks, I'm aware of it but it doesn't work for me.

Beyond what I described above, I need something that works on Windows and Windows Phone, and I need it to securely sync between the two.

This implies that there is a version of 1Password for windows phone?

https://discussions.agilebits.com/discussion/12133/1password...

Indeed there is: http://www.windowsphone.com/en-us/store/app/1password/21ed2e...

Can you use KeePass and just sync the database via dropbox?

Android requires root privilege and/or system-level app to take screenshots. iOS is probably similar. I don't think an app could spy like this without user enabling it (which is a valid but separate concern about how knowledgeable the average rooter/jailbreaker is.)

[0] http://android.stackexchange.com/questions/10930/why-do-we-n...

From http://stackoverflow.com/questions/12462944/how-to-take-a-sc...:

======

Using hardware partners

Now we get into the solutions which require commercial action.

Talking to the Android chipset makers often presents a solution. Since they design the hardware, they have access to the framebuffer - and they often are able to provide libraries which entirely avoid the Android permissions model by simply accessing their custom kernel drivers directly.

If you're aiming at a specific phone model, this is often a good way forward. Of course, the odds are you'll need to cooperate with the phone maker as well as the silicon manufacturer.

Sometimes this can provide outstanding results. For example I have heard it's possible on some hardware to pipe the phone hardware framebuffer directly into the phone hardware H.264 video encoder, and retrieve a pre-encoded video stream of whatever is on the phone screen. Outstanding. (Unfortunately, I only know this is possible on TI OMAP chips, which are gradually withdrawing from the phone market3).

======

Probably not something an average crapware author can do, but certainly within reach of the NSA.

On iOS it's possible to capture the framebuffers of other apps via the IOSurface APIs with an app that's running in the background. These APIs are not documented well, but it's certainly possible.

Maybe I'm not fully understanding here but the last two phones I've used do not require root or any app to take screenshots. Nexus 5 and Moto X.

By root, I meant that an app with root access could probably take screenshots, not that a root app is needed for the user to access the system's screenshot capability.

Once its on your phone, it can just screenshot things if nothing else.

If it can't run, how can it screenshot things?

It could be an update of an app that runs by default, or an update of a core component of the OS.

No apps "run by default". The OS's core components require user confirmation, as that's just a normal iOS update.

What about when you get a phone call -- the app that pops up the call UI could be updated, pushed, then triggered by calling the phone.

The obvious way to mitigate this threat vector is to not have a Google Account associated with your device that can install apps. At this point, a Google Account is just a huge privacy/security risk.

Reply on news.ycombinator.com