Mobile Data Storage With Limited Access to a Specific Application
This article describes some basic principles of data storage and solution we found to solve its security problem by providing quick access to the local storage of mobile devices (android/ios) from a single application without the necessity to use Central Authentication Service (CAS).
- Local storage (LS) is a file on a mobile device at which static application data is recorded.
- Master key (MK) is a key we use to encrypt data on the LS.
Private keys in cryptowallets or whole data bases are the kind of data requiring higher attention when launching an application. Instead of entering a key every time we try to read or write any data from data base we want user to enter it only once when starting an application. We believe it a better approach to UI/UX. However it causes several problems:
1. Since adversary can easily access Local Storage of an application;
2. (1) We need to encrypt data before writing it to LS;
3. (2) We need a Master Key to encrypt LS and some secure place to store it;
4. It is impossible to store MK in LS (chicken-and-egg problem);
5. We can’t use CAS as it will lead to poor app’s performance and will not let us to get access to MK if there is no Internet connection;
6. Using local mobile certification authority adds new problems to the process of app’s implementation, worsens UI, and puts all the confidential data in jeopardy (in caselocal CA is hacked);
7. Hardcoding MK is not an option since app can be reverse engineered;
8. You can not force users to memorize MK just because an ordinary user can not remember a more or less secure key/password.
Is there any sense in storing MK at all? What if MK will be generated in application just before we need it. This MK will be kept in the RAM of the device for some time and then delete itself.
We can split the task into several smaller, but specific problems in this case:
- f1() – binding MK to the installation life-cycle;
- f2() – binding MK to the secret user password/fingerprint;
- f3() – binding MK to a specific device.
MK = SHA3-512( f1() + f2() + f3() )
f1 () – Binding Master Key to the installation life-cycle
Why is it necessary?
Any installation/removal operations with an application must result generation of a new MK.
We prevent adversaries from being able to log MK by modifying the source code in this way. In other words, if an application has been uninstalled, new installation will lead to generation of a different MK as a result of f1()’s execution. It means that the data encrypted with the MK before (i.e. previous installation) will be safe.
Still we should be able to update applications.
The right solution is to get installation ID of an application that will:
- be generated from the application’s code;
- not change with application’s updates;
- change when deleting and reinstalling an app;
- not let user manipulations change/delete it.
f2() – Binding Master Key to a secret user password/fingerprint
Why is it necessary?
System can generate only a limited amount of secure keys. Using additional user password will solve this problem successfully. In order to increase chances of secure data storage we can set a minimal limit to this password.
This password can be used for Master Key generation. Only user will know his password what creates great obstacles for hackers.
What is more, when returning from the background mode Multy will always require to enter password (at this moment application data will not be displayed). This feature eliminates any chance of getting access to application data in case user’s telephone has been stolen.
It means that:
f2() = SHA3-512(localPassword)
f3() – binding MK to a specific device
Why is it necessary?
Assuming adversaries are able to transfer an app to other devices or emulators (but such cases have not been recorded yet) means that we have to find the way to be able to verify that an application is running on the device on which it has been installed before. Such popular device identifiers as EMEI, deviceID and etc are suitable instruments in this case.
But still these identifiers can be easily faked. So this solution should be perceived as salt when calculating SHA3-512().
!!! One should understand that the following: if use interferes in these device data settings the former MK will not be generated again. Therefore, decision whether to use this function or not largely depends on the security context of the application itself.
This solution is a perfect one to generate a unique MK for data encryption. But it does not protect us from RAM dumping at the moment an app is executed. In this case adversaries will have an access to the data they want to get no matter if it is encrypted or not.