I want to store some small but critical piece of information such as AES keys in my Android application. What would be the recommended way to do this? I do not want to hardcode keys as part of my application.
I look at KeyStore but it does not really solve my problem. It can store my keys given that I can provide a password. Then I need to find a secure place to store this password which is same as my original problem.
Is there a built in Android class to perform this task? Or should I look for third party libraries? Using NDK is also acceptable for me.
I was hoping to find an Android API for storage such that guarantees that only the application that stored some information can retrieve it back. Android OS could have enforced this based on signing signatures of the application. This way my application can generate a random key on first run and store it in secure storage for later use. Are there any API for this?
Is there a built in Android class to
perform this task?
Or should I look for third party
You can try, but I suspect most will look like the solution you already rejected. Most secure data stores involve passwords and assume the passwords are held elsewhere (e.g., in a user’s head). For example, OI Safe has an Intent-based system of allowing applications to store stuff in the safe, but then the user is involved in unlocking the safe, IIRC.
One solution, if you end up with using the KeyStore API, is to generate your password dynamically at run time every time the app needs to access the KeyStore. If you base your password algorithm on a simple, but changeable, variable tied to the specific installation such as the device MEID (or other specific ID of the physical device gained at run time) you could provide a key to the lock that becomes increasingly difficult to pick.
Example: use an ID from the physical device, cut in three positions and append them to the end position in the ID string, then append your initials to the string programmatically. I would think this approach would give a layer of security that cannot be easily broken unless the cracker knows how you made the key (i.e. has your source code).
MEID = MEID + "fluffy" + "2008";
Where MEID is a string with some ID from the device, “fluffy” is the name of your best friends cat, and “2008” is the year of an important event in your life. Then feed this new string into an array, parse through a number that suits you (the day of the month that you got your drivers licence for example), grab three chars out and drop those chars at the end of the string. Clip from the front of the string to the number of positions you need for your key and away you go. This should not be a very processor intensive task so, with some fault tolerance code for the variables, you should be able to run this in your main process even with out too much worry of getting an ANR from the system. If you really want to get froggy, convert the string to bits at some point and ‘bitwise op’ the changes. Viola, a low overhead, dynamic key that is unique to the device it is run on!
As @RedWarp pointed out, decompiling an .apk is always within the realm of possiblility for any object code with the proper tools and motivation. If the “key” generation is a really important process then abstracting the key gen outside the scope of the app is a must.
The real point that I am trying to make with this answer is that a little fore thought can go a ways with regards to minimal security. Stronger security is more in depth than a simple answer from me.
You have to distinguish here between keys and app data.
The “AndroidKeyStore” KeyPairGenerator and KeyGenerator stores the keys they generate from your app under an alias in the KeyStore and associates the keys to your app. If the device has “secure hardware” you can specify that it be used and the keys will be stored there.
There is no password for the keys. You use the alias to specify which key you want to use. Only your app can retrieve the keys it had generated.
For your app’s private data, if I understand “.. an Android API for storage such that guarantees that only the application that stored some information can retrieve it back. ..”, you might look at these: