I am writing a mobile app which would be expected to store sensitive data. It needs to be stored for offline use. I am wondering now that Android and iOS provide encryption at rest do I need to encrypt the data stored in an database within the App.

The main concern would be that the phone could be stolen. What would someone have to do to get the data from the application. Also what state would the phone have to be in, for example turned on, beyond the pin lock screen, logged into the app.

If the data is vulnerable where would I store the encryption key. If someone can root/jailbreak the phone surely the key is compromised and therefore so is the data.

Any help/advice would be really appreciated.

  • 1
    Would it be possible to encrypt the data with a separate password for your application? i.e the user enters a password to open the app, which is also used to encrypt the app's data. This would be Password Based Encryption and you'd have to use key derivation functions and enforce a long password (20+ characters) to make this secure enough. Nov 30, 2014 at 17:03
  • Thanks for your response SilverlightFox, but I just really want to know the attack vectors so that I can assess the risk, the provide an appropriate solution to mitigate the issues. Nov 30, 2014 at 17:23
  • @rideintothesun - Did you ever come up with a good solution to this issue?
    – mc01
    Jun 15, 2018 at 22:43
  • Have a look at Realm at realm.io Jul 2, 2018 at 9:52

3 Answers 3


I will first address the various attack vectors possible if the device is on or off and whether full disk encryption (FDE) is on or off. After that, I want to comment about the need for app-level encryption and the capabilities that it offers in your particular scenario.

Here, we assume the attacker has obtained control of the device. Furthermore, we assume that he or she is a well-educated hacker who has the time and resources to extract data out of the device. In real life, you may meet these people (but you may also meet those who are just interested in wiping the data and reselling the device).

Oftentimes, it comes down to the user’s habits that ultimately determine the security of the device. Let me mention a few of them (non-exhaustive).

(a) How does the user unlock his device? Pin code, swype pattern, picture, Touch ID, or none at all? Pin code is the strongest if there are sufficient digits. Swype patterns can be deduced by shining some light onto the phone and tracing out the oil stains. Picture and Touch ID are not fool proof either. See proof of concept videos on YouTube showing Touch ID being hacked.

(b) In addition, is the user conscious of his surroundings when unlocking his device? People may simply peek and memorize the patterns.

(c) How many seconds of standby before the phone automatically locks itself?

(d) Is the user running third party lock screen apps or any other types of apps which may introduce specific security vulnerabilities?

If the phone is unlocked, then the next thing stopping the attacker is any security authentication features built into your specific app (which I cannot comment on since I do not know your implementation). Just imagine you are an attacker now. How easy is it for you to launch up your app and see the data? What if the user recently switched apps? Does switching back to your app afterwards allow you the access the app or not (i.e. is the “login” persistent across app lifecycle states?)

Now, assuming the pin code is secure and the phone is locked at the time of theft, then a manual brute force attack (i.e. the attacker using his fingers to guess the password) is unlikely to work out. However, the attacker may try to do an automatic brute force attack using software tools. Just like ‘password recovery’ or ‘data recovery’ tools out there, you have to connect the phone to the computer and run the recovery tool. In this case, the phone is on. The success of running such forensic tools depends on the following:

(a) Is the device rooted or jail-broken into? Many recovery tools rely on this in order to get superuser rights and security privileges to crack the password or extract the data.

(b) Is developer mode on? Legitimate tools like Android Debug Bridge (adb) may be able to get data out of the phone if developer privileges are enabled. However, in later versions of Android, this should not succeed if the phone is plugged into a completely new PC since authorization must be given on the phone itself (an RSA fingerprint is registered). I am not sure about Apple or iOS.

(c) Is there a malicious or vulnerable third party app already installed in advance that the hacker can communicate with? For example, there may be some bad app that can remotely unlock the victim’s phone once the attacker gets hold of it.

P.S. If you can find a brand new device that can be hacked without the aforementioned conditions, do let Google or Apple know immediately, as this means their default OS implementation is insecure.

Notice that I did not mention FDE as it does not really help prevent the aforementioned attack vectors. If an FDE-enabled device is on at the time of theft, the OS is automatically triggered to do on-the-fly encryption and decryption of the disk sectors that are required by any app anyway. That’s how users can use their apps normally. Similarly, if the attacker’s tools are allowed to run on the phone, then FDE is not going to help, since the OS will cooperate and decrypt the information on-the-fly. In other literature, you may encounter the saying the FDE is mainly there to protect against offline attacks, and not online attacks.

Okay, let’s assume our phone has survived the attacker up to this point, due to our prudent user habits and the fact that we didn’t root and mess up the default security in our device. We have also enabled FDE, so the attacker cannot simply plug the phone in and read out all the data. Even if he transplants the hard disk from one phone to another, the other phone should not be able to read the data since the data is encrypted at rest.

The attacker is left with 2 main options to defeat FDE.

(a) Cold boot attack

(b) Direct memory access (DMA) attack

Now, cold boot attack takes advantage of the encryption key being in volatile memory (RAM). By cooling down the device, the electrical charge stays on for just a bit longer, long enough to plug into some other device/OS and read out the contents of RAM, thereby obtaining the key. In my opinion, this doesn’t seem as easy to do on a phone compared to a desktop with upgradeable memory, given that memory is built together with the motherboard. Also, this is quite impractical as the attacker has to train his skills on a specific hardware phone model.

Cold boot attacks might be mitigated if the phone is switched off at the time of the theft since the key should not be released to memory, however it does not apply to all systems! It ultimately boils down to how Android and Google have implemented their encryption schemes in their operating systems. At least for Android, I know the user has 30 tries to key in the right password upon turning on the phone before Android is booted. This seems to suggest that Android does not release the decryption key until the correct password is given. In a totally separate computing platform, Windows Bitlocker with TPM will release the decryption keys as long as it verifies that the boot partition hasn’t been tampered with; it has nothing to do with the user account credentials that one uses to log into Windows. In other words, shutting down the computer will not make a difference since the attacker can start it up again and the TPM will still release the keys as long as the integrity check passes. Of course, Bitlocker does come with two-factor authentication to counter this problem if you really want it.

In short, I just want to caution that while shutting down the device may seem a good practice, it is not a practical one in the mobile world, and it may or may not mitigate the cold boot attack depending on the details of the implementation.

The next attack used to defeat FDE is the DMA attack. Since Android phones do not come with DMA ports, I think this should not be possible. As for Apple mobile devices, thunderbolt may be exploitable, but I have not researched into this area to give a conclusive answer to this.

Now, let us move on to the real problem where FDE is concerned.

Security experts are happy that Android has finally caught up to Apple in providing default encryption with Lollipop, however, that’s only for new Lollipop devices. FDE is not enabled by default on pre-Lollipop Android devices (even if you upgraded from Kitkat to Lollipop, you still have to turn it on manually). That is a huge number of devices that would persist for the next few years!

Therefore, it may be wise to attempt to have an app-level encryption of our app data for a specific app, as you have alluded to. However, the devil lies in the implementation details. Many “secure” apps on the app store cannot really be trusted unless the source code is available for scrutiny.

One vulnerable implementation I can think of is to ship the app together with the encryption/decryption key. This sounds really convenient for the user – just fire up the app and everything works. No need to keep keying in passwords, since the key is stored somewhere. Okay, so the app data is encrypted and decrypted using the key is stored in plaintext. However, assuming that the device does not have FDE, the attacker can still obtain the key and use it the decrypt the app data (although it may slow him down if we do some obfuscation). This is definitely insecure.

One secure implementation I can refer you to is that of Truecrypt. It is an offline encryption software for computers that is open source. Although it has been a discontinued project as of 2014, experts believe it is still secure and some groups are trying to continue to maintain Truecrypt. It does not store the encryption key on the hard disk. Take a look at the details of its encryption scheme here http://andryou.com/truecrypt/docs/encryption-scheme.php . You can also check out the FAQ to find out more.

I believe you can adapt the scheme to your app. At the cost of convenience, make the user key in a password every time they start your app. The password will be input into a key generating function to generate a long AES key, and the key will persist in RAM until the app closes (like others have mentioned). It is never stored on the hard disk, In this case, it is still vulnerable to Cold Boot and DMA but it does not seem to be likely on mobiles at this point in time.

Another example I can point you to is Lastpass for mobile. It is a secure password manager that has extended its functionality to the mobile space. Maybe you can delve into how they implement their crypto schemes securely and how their app works (if I recall correctly, it also works offline).

Once again I like to stress that encryption does not defeat all attack vectors. If there is a malware running, then that malware could still get hold of the data while the user is using your app. Best weapon to fight this is user education.

Some final comments for now:

If a device is compromised, the user should do a remote wipe of the device. If FDE is enabled, the data is most likely unrecoverable since the key is lost after wiping.

In addition, the user should immediately change all of his passwords for active accounts logged into the compromised device.


You could, like Mozilla Firefox, use a "master password" to encrypt "sensitive" data (like the password database). People would need to enter the password on your app before the database of sensitive "stuff" is useable.

On Firefox, this feature is off by default (actually the encryption password is hard-wired into the Firefox code).

You can have a timeout that wipes out the secret, so that after 10 min the user will need to enter the password again. If you request the password too often, you will annoy users, and also discourage the use of a complicated password, or encourage users to type the password without checking context. A rogue app cannot access other apps memory (systems like Android have strong isolation), but it might trick the user into giving it the password (like a phishing website).

If someone can root/jailbreak the phone surely the key is compromised and therefore so is the data.

If an attacker can jailroot the phone without you noticing, then you will at some point enter your password on a rooted phone and the attacker will be able to get it.

Google Chrome doesn't implement this password encryption feature, for exactly this reason:

  • The files of a particular user (including password database) are only accessible to this user on an uncompromised system.
  • On a compromised system, everything the user does can be monitored, recorded, and exfiltrated, notably everything he types, notably his "master password" that unlocks the password database. This is even more likely to happen with such password that needs to be entered on every browser startup and after some time of inactivity.

So Google Chrome doesn't try to defend against such local attacks, and expect the OS to protect it.

This strong defining design choice to not protect a sensitive database (and be proud of that) has caused much controversy:

Google's answer:

Hi everybody,

We understand that many of you want a master password for your saved passwords in Google Chrome. You’ve laid out many scenarios in which this might be useful, but the most common is that if your computer were to fall into the wrong hands, that person would then have access to your saved passwords.

While we agree that this situation would be terrible, we believe that a master password would not sufficiently protect you from danger. Someone with physical access to your computer could install a keylogger to steal your passwords or go to the sites where your passwords are stored and get them from the automatically filled-in password fields. A master password required to show saved passwords would not prevent these outcomes.

Currently, the best method for protecting your saved passwords is to lock your computer whenever you step away from it, even for a short period of time. We encrypt your saved passwords on your hard disk. To access these passwords, someone would either need to log in as you or circumvent the encryption.

We know this is a long-standing issue, and we see where you're coming from. Please know that your security is our highest priority, and our decision not to implement the master password feature is based on our belief that it creates a false sense of security instead of actually providing a strong security benefit.

Best, Blair

also here:

I'm the Chrome browser security tech lead, so it might help if I explain our reasoning here. The only strong permission boundary for your password storage is the OS user account. So, Chrome uses whatever encrypted storage the system provides to keep your passwords safe for a locked account. Beyond that, however, we've found that boundaries within the OS user account just aren't reliable, and are mostly just theater. Consider the case of someone malicious getting access to your account. Said bad guy can dump all your session cookies, grab your history, install malicious extension to intercept all your browsing activity, or install OS user account level monitoring software. My point is that once the bad guy got access to your account the game was lost, because there are just too many vectors for him to get what he wants. We've also been repeatedly asked why we don't just support a master password or something similar, even if we don't believe it works. We've debated it over and over again, but the conclusion we always come to is that we don't want to provide users with a false sense of security, and encourage risky behavior. We want to be very clear that when you grant someone access to your OS user account, that they can get at everything. Because in effect, that's really what they get.

To me this is a very reasoned and sound design choice, and this controversy and lack of encryption has increased my confidence in Google Chrome security. Security is about sound design based on reasonable hypotheses, not just on wrapping everything into layers of encryption, or "security in depth" where some layers are extremely weak.

I understand that others disagree and want "security in depth" even when some layers are not as strong as others.

  • Disregarding the fact that you didn't answer a few of the guy's main questions... The chrome decision was silly. A person may know who they want to hide passwords from, and if it's their little brother, or grandparent, a master password would be exactly what they'd want. Nov 30, 2014 at 19:26
  • Thanks for the info. The app would have its own password to access it. I'm more concerned that if the phone was unlocked at the pin level but not the app level, could someone connect it to the computer and remove the database? Nov 30, 2014 at 19:41
  • @ParthianShot Unless you don't have your browser opened all the time (which would be quite exceptional), and you don't use need your passwords all the time (the remember password feature is useful when you have many passwords and use these often), and your little brother could still get your passwords and use your online accounts. Conclusion: Lock your computer.
    – curiousguy
    Nov 30, 2014 at 20:53
  • @sisterray The problem with a browser is that it is almost always used; if you app is used for short period of times, it might make sense to protect its data with a specific password.
    – curiousguy
    Nov 30, 2014 at 21:05
  • Just to be clear the app will be a native app. Not a browser based app. If we forget about rooting, if the pin has been entered successfully but the app has not been logged into yet, could someone remove the database from the phone Nov 30, 2014 at 21:39

On iOS devices there is the Data Protection API which enables apps to encrypt data so that it is only available when the device is unlocked i.e. after the user has entered their PIN/password, some information here: iOS Developer Library. I think this link will answer your questions, but in a nutshell provided a phone is locked when it is stolen the data should remain confidential.

I know little about Android so I don't know whether there is an equivalent.

  • Thanks R15. On ios if the phone was unlocked but the app was protected by its own password, could someone connect it to a computer and remove the database? I accept if the steal it when the app is running they could see any data until the app locks itself. Nov 30, 2014 at 19:43
  • @Sis Yes they could because they could then disable the phone lock and proceed to root the phone. Nov 30, 2014 at 21:10
  • Hi SilverlightFox, I accept they could root the phone, but without rooting it could they remove the database from the phone or somehow read it. Nov 30, 2014 at 21:40
  • @Sis Possibly, with backup software. Nov 30, 2014 at 22:41
  • Ok so they steal the phone, back it up and somehow extract the database from the backup files. This would definitely be a case for encrypting the data. Nov 30, 2014 at 22:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .