3

I want to be able to build a good file encryption on android for a cloud app. The files used are mainly pdfs, pngs, docs, audio, video, etc (all sorts of files).
Edit:
My constrains are that it should be fast enough, so the users of the cloud app don't wait forever to upload/download. Also, the encryption must be secure, thus, if the device gets stolen nobody can get a hand on the data.
I know a bit about encryption, I read about AES (understood the math behind, not so complicated), but I am not sure how to properly do a good file encryption, from the usability point of view.
I do hope you get my problem, if not, please tell what is not clear.

Therefore, my question is:

Which steps should I follow (things to read, etc) in order to have a proper encryption which is also fast enough?

Example: I saw that Spotify is doing a sort of encryption of their files which seems to be fast enough.

Known fact: All I know so far, is that the storage of the key used for encryption is safe enough, so that is not a problem.

  • Do you want a encryption prior to transferring a file to the cloud (so anyone with administrator access to cloud server cannot access user's files), or do you want some encryption to prevent access to files in case the Android is stolen? – sebastian nielsen Oct 22 '14 at 9:01
  • The first requirement is to prevent access to files when the device is stolen that's for sure, considering that some files are classified. Regarding the first condition, not sure yet, I tend to say yes but I am not sure. – Andrei Toader Oct 22 '14 at 9:06
  • The thing here is that either you have to trust the server or client. Somewhere you have to do the encryption/decryption, and its here data will be exposed. So usually, protecting the server from compromise with E2E will make the device vulnerable to theft, while protecting the device from theft means that you do encryption/decryption on the server. You could also have a password-derived key, but that would mean a unlocked device is vulnerable to theft. – sebastian nielsen Oct 22 '14 at 11:13
  • Didn't really understand what you meant by password derived-key but I think it has something to do with the location of the key. One thing that I forgot to mention is that the key is stored on a disk which is stored at the customer or at our place. We are using Skytrust if you know it. I am trying not to tell too much because it is not so ok to go into details. – Andrei Toader Oct 22 '14 at 11:26
  • If you for example require a password to start the app, and then using SHA512('password'), and then use the result of this as a encryption key for AES512, then you have a password-derived key. The problem you are facing is that you either need to put the weight on protecting stolen devices from access, thus you must store the key in your Place, and handle encryption/decryption off-device. Or you need to put weight on preventing leakage in case of your server get compromised, either by a dishonest employee or a hacker attack, thus you need to use keys in device. Seems you put weight on nr 1. – sebastian nielsen Oct 22 '14 at 11:35
1

According to the comments, I would suggest doing simple AES on the server side. Eg, when a customer wants to open a document, he request decryption, and then the document are sent to server, decrypted and then sent back. The decrypted document are then never stored on flash or memory, only in RAM. Once the user are inactive a certain period or switches to a Another app, delete the document from RAM.

Note that the Communication channel need to be secure (eg protected by VPN or similiar means), since cleartext data will be transmitted over the wire.

However, if you could afford (eg theres enough disk space so you does not need to leech on the device's disk space), you could instead store Everything at customers disk or your disk, unencrypted, and use a simple server-sided authentication process to make sure stolen devices cannot request documents off the server. That would mean no documents ever are stored on the device.

Then you simply send the documents for immediate vieweing in the app.

  • Is it possible(secure an fast included in the package) that the AES is also done on the client side and the key is taken from a disk provided by these guys? (considering the key is stored safe, etc). – Andrei Toader Oct 22 '14 at 12:08
  • Yes, but one thing you need to consider is that once the key touches the device, it can be potentially be compromised. Thats why you instead send the indivual file to be decrypted to the server instead. (Or simply let the server deliver files that the client request - provided the client is authorized to access the file). Thus you gain the advantage that if something is compromised, its only a few documents, not Everything protected by that key. You could also have a indivual key for each document, and send the requested key - and thus be able to store the encrypted files on-device. – sebastian nielsen Oct 22 '14 at 12:16
1

I would recommend using an existing solution such as SQLCipher, which already works fine on Android and let you store all kinds of data in one database (or if you wish, several separate ones). This would certainly be easier and more secure than trying to implement your own file encryption.

  • Thanks for the input. I Will check when I have some free time. I would up-vote your answer and the previous as useful, but because of my "reputation" I cannot. – Andrei Toader Oct 22 '14 at 14:47
1

There is an easy, solid way to add encrypted to storage to any Android app. For storing files, you can make an virtual encrypted disk using IOCipher. For encrypted database storage, use SQLCipher for Android. The CacheWord library makes it easy to manage the user password for that encrypted storage.

IOCipher uses the same API as java.io.* and SQLCipher uses the same API as android.database.*, so they are both really easy to use. Here's how to add them via gradle:

compile 'net.zetetic:android-database-sqlcipher:3.3.1-2@aar'
compile 'info.guardianproject.cacheword:cachewordlib:0.1'
compile 'info.guardianproject.iocipher:IOCipher:0.3'

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.