Application data encryption

[rijvirajib]

Is there a roadmap plan for application data encryption to secure application data from potentially risky third party applications that may highjack root access?

[thestinger]

It isn't planned, but it could potentially be implemented. It would need to ask for a password upon launching a protected application to be useful though, and the attacker could just wait until the user launches it. I'm not sure there's much that can be done against an attacker who has already obtained root access, which implies a kernel compromise due to the SELinux policies that are in place.

[thestinger]

It isn't planned, but it could potentially be implemented. It would need to ask for a password upon launching a protected application to be useful though, and the attacker could just wait until the user launches it. I'm not sure there's much that can be done against an attacker who has already obtained root access, which implies a kernel compromise due to the SELinux policies that are in place.

[benhutchins]

If you were to secure application data with an additional level of authentication used for an application-specific encryption key, you'd need to request the details to get the key prior to the application actually opening. So the system would need to decrypt the files being requested on behalf of the application, either as a file system level or replacing all the APIs/SDKs methods used to read/write files to the application data directory.

If either was done that verified the requesting application, you could potentially restrict access from other applications, including those with root access, but only if the application with root access was not designed and targeted against this operating system since then it'd be essentially too late. If an application has root access, I believe most solutions are to try and prevent applications from getting root access to begin with. Not sure if there are many things to do once an application has root access.

Would this still be useful in the case of non-rooted applications. Would encrypting application data secure it any more? Essentially the APIs on Android are designed to secure applications from others if they're using their application data directories. Unless there was an attack that could get around this, encrypting application data wouldn't have much benefit. However, that might be benefit enough if you are trying to secure your data as much as possible.

[benhutchins]

If you were to secure application data with an additional level of authentication used for an application-specific encryption key, you'd need to request the details to get the key prior to the application actually opening. So the system would need to decrypt the files being requested on behalf of the application, either as a file system level or replacing all the APIs/SDKs methods used to read/write files to the application data directory.

If either was done that verified the requesting application, you could potentially restrict access from other applications, including those with root access, but only if the application with root access was not designed and targeted against this operating system since then it'd be essentially too late. If an application has root access, I believe most solutions are to try and prevent applications from getting root access to begin with. Not sure if there are many things to do once an application has root access.

Would this still be useful in the case of non-rooted applications. Would encrypting application data secure it any more? Essentially the APIs on Android are designed to secure applications from others if they're using their application data directories. Unless there was an attack that could get around this, encrypting application data wouldn't have much benefit. However, that might be benefit enough if you are trying to secure your data as much as possible.

[thestinger]

It wouldn't accomplish anything while the applications were running. It could only secure the data at rest. It would still be compromised as soon as the user ran the application and entered the encryption password. The complexity involved in implementing it (which implies attack surface) seems like it would outweigh any benefits.

[thestinger]

It wouldn't accomplish anything while the applications were running. It could only secure the data at rest. It would still be compromised as soon as the user ran the application and entered the encryption password. The complexity involved in implementing it (which implies attack surface) seems like it would outweigh any benefits.

[thestinger]

And this is assuming that users are really going to make a unique and strong encryption password for multiple applications in addition to the main encryption password. It would need to be entered whenever launching the applications, so it would be very inconvenient.

[thestinger]

And this is assuming that users are really going to make a unique and strong encryption password for multiple applications in addition to the main encryption password. It would need to be entered whenever launching the applications, so it would be very inconvenient.

[eighthave]

This is something that @n8fr8 and I have been thinking about for a long time, ever since we started SQLCipher for Android. I think it would actually be pretty easy to implement protecting all of an app's database usage by replacing the embedded SQLite with SQLCipher. SQLCipher is just a close fork of SQLite that only adds really nice encryption support. @zeteticllc, @guardianproject, and many others have been embedding SQLCipher into Android and iOS apps, so we know it is reliable and performant on mobile. And the API and code outside of the crypto extension is exactly the same, so it'll work fine for regular SQLite uses.

So the first question is: would you accept replacing the embedded SQLite with SQLCipher? That's something I could do. Then there would need to be some kind of system-based password prompt to unlock the encrypted databases. That of course would only cover data stored in a DB.

Handling the files would be trickier. We have https://github.com/guardianproject/IOCipher to provide per-app encrypted filesystems based on top of SQLCipher. It is totally feasible to use that embedded in the ROM which would then provide the base of the /data/data/packageName dir.

[eighthave]

This is something that @n8fr8 and I have been thinking about for a long time, ever since we started SQLCipher for Android. I think it would actually be pretty easy to implement protecting all of an app's database usage by replacing the embedded SQLite with SQLCipher. SQLCipher is just a close fork of SQLite that only adds really nice encryption support. @zeteticllc, @guardianproject, and many others have been embedding SQLCipher into Android and iOS apps, so we know it is reliable and performant on mobile. And the API and code outside of the crypto extension is exactly the same, so it'll work fine for regular SQLite uses.

So the first question is: would you accept replacing the embedded SQLite with SQLCipher? That's something I could do. Then there would need to be some kind of system-based password prompt to unlock the encrypted databases. That of course would only cover data stored in a DB.

Handling the files would be trickier. We have https://github.com/guardianproject/IOCipher to provide per-app encrypted filesystems based on top of SQLCipher. It is totally feasible to use that embedded in the ROM which would then provide the base of the /data/data/packageName dir.

[thestinger]

I think it should be implemented at the ext4 encryption layer with a key derived as another layer from the main encryption key. I don't want this to be done in the near future since it's invasive.

[thestinger]

I think it should be implemented at the ext4 encryption layer with a key derived as another layer from the main encryption key. I don't want this to be done in the near future since it's invasive.

[thestinger]

Closing since the threat model here doesn't make sense. Finer-grained encryption can and should be implemented via FDE, but the goals and mechanism to accomplish them need to be specific.

[thestinger]

Closing since the threat model here doesn't make sense. Finer-grained encryption can and should be implemented via FDE, but the goals and mechanism to accomplish them need to be specific.