Android, Secure Those 3rd Party API Keys!
I see a lot of misinformation about this subject including articles in AndroidAuthority and so let’s make sure you have the right information. Let’s start with something easy, the application signing key.
Above all you want to avoid putting a 3rd party api key in assets or the xml files in the res folder as it is somewhat trivial if someone has root to device to find out those keys. If you doubt me unzip any apk file and look at the res folder xml files.
APPLICATION SIGNING KEY
Most continuous integration servers understand how to use your git SHA encryption key to decrypt stuff you want to encrypt so it is trivial to encrypt your password and alias password to your application key. In this case you are securing that key from 3rd party access as every developer that contributes to your app has a local git repo of the code on their particular laptop that may not always be under complete company control.
This secure access control works because you have only a select few knowing and controlling the SHA encryption key associated with that particular git account on say like github or bitbucket. That is not the individual developer SHA encryption key but the SHA key you set up for your organization.
OTHER 3rd PARTY API KEYS
Now begins the thorny problem, maniacal laugh insert here. You have two distinct areas to secure the 3rd party api. One, is in this BYOD workplace market you do not always have control of the particular machine that local copy of the git repo of your app code sits on. Two, how about securing the 3rd party key from being known by someone who roots a device to unzip the application apk file?
So what is the solution?
AndroidAuthority suggest as one of the methods to store the key in a NDK so suffixed C library. Nah, most C devs know how to read hex; let’s try something more awesome.
Assuming that you can supply the 3rd party api key in a compile java class and obfuscate using proguard with the twist being that its an encrypted value that is decrypted at application initialization. You would use a DIFFERENT ssh SHA key for your organization and encrypt the 3rd party key and de-encrypt at application start-up.
Note, that this only works by securing access to that ssh SHA key to only select few trusted parties. That means enforcing using computer machines with encrypted hard drives and hard to guess passwords.
Now for a perverse thing in mobile development. The mobile device that your application is sent to is the least secure as compared to that encrypted laptop your developer has and the combination of the contract and the relationship you have with that developer. Seems reversed does it not? Its a thing to remember and use as a guide.
Unlike AndroidAuthority’s suggestions its designed with the developer with limited resources-in-mind. You do not need a server to implement it.
There are THREE areas to secure keys; the devs laptop git repo local copy, the CI build server you use as it uses a copy of the git repo, and protecting against someone accessing via rooted device. If you can secure all three areas than that is the awesome. Always shoot for the awesome! Unfortunately, the author of the AndroidAuthority article(the author of Bulletproof Android:Practicla Advice for Building Secure Apps) lacks knowledge of securing android applications and android framework specifically and understanding humans(all three areas of understanding are required to secure an android applications).
It usually better to assume that the developer reading this may not have access to everything and at least in security to give the ultimate solution that can be used with the most limited developer resources. Its called, GIVING A SHIT!