search

hyperboria / android

Android app for mesh networking with cjdns
GNU General Public License v3.0
159 stars 40 forks source link

Encrypted storage of credentials and everything else #24

Closed benhylau closed 9 years ago

benhylau commented 9 years ago

Almost all persistent data in this app need to be stored encrypted. We cannot rely on device-level encryption because it's not always enabled, and only enabled by default on Lollipop+. So we need to implement our own, which unfortunately would require the user to supply a PIN every time we start the app. The PIN itself, must not be stored on the device at all.

I am debating whether encryption should be optional or required. I am leaning towards making it a requirement, because the app holds not only this node's credentials, but also those of your peers. Though this PIN is kind of redundant when device-level encryption is used.

If you are feeling particularly adventurous, you can investigate whether we can implement something that works across devices using private APIs without requiring a PIN from the user. But then it still would require the user to have a device-level PIN set. So my suggestion is do the whole thing custom with NaCl, which needs to be in the app anyways because of wrbt peering.

kpcyrd commented 9 years ago

I don't think we should enforce encryption since the peering credentials are usually of low value. Also, we'd sacrify a lot of convinience. To make the encryption actually useful, the user would need to pick a long password, since (for example) 4 numbers are trivial to crack. It wouldn't hurt to store the credentials (and our cjdroute.conf) in the keystore, when available, though. Otherwise I would rely on androids filesystem permissions and offer optional encryption in the settings.

benhylau commented 9 years ago

That's true, yea I was also thinking how impractically long a PIN would need to be. Funny how an hour ago I was arguing how creds are not valuable enough for attackers to mim the exchange, and here I am trading user convenience to keep them encrypted. I guess the passwords are as valuable as revokable tokens to a service that routes scrambled data, though they do include the association between node operators (e.g. Clearnet IP, MAC address, etc.) and their node (i.e. cjdns IPv6). Not only of the compromised node, but also of its peers.

I am thinking about the case when fcAA hosts some controversial content, and is peered with fcBB. An attacker wants to figure out the personal identity of fcAA by looking at the conf of fcBB. This wouldn't be practical if fcBB's persistent data is encrypted with a long PIN. Is there value in protecting this information, or is the association between fcAA and its Clearnet IP already public information?

benhylau commented 9 years ago

@kpcyrd We can also consider just displaying the current encryption status of the device storage, and encourage people to enable device-level encryption.

See DevicePolicyManager#getStorageEncryptionStatus()

benhylau commented 9 years ago

Done! https://github.com/BerlinMeshnet/cjdns-android/pull/29