I just read this article http://android-developers.blogspot.in/2013/02/using-cryptography-to-store-credentials.html where I learnt to generate security key.
I want to kn
Root
user has the permission to do anything on your android device. No matter where you save your generated key, a process running as root
will be able to read it (as long as it knows where to read from). You may decide to encrypt the key before storing it, but then you have to determine where you will save the encryption key (again, if it's on the phone, root
user can read it).
You may consider to ask the user of your app to provide the encryption key, and not store the encryption key on the device. However, even then it may be possible to get hold of that encryption key given enough time and effort from an attacker.
You should consider the requirements of your app, most probably, when the device is rooted your application should not provide any security guarantees to your users. After all, there is a reason why rooting your device voids the warranty.
if Android is rooted, there is no way to secure any thing, so you should better look for architectural changes in your application.
Upon installation, WhatsApp creates a user account using one’s phone number as the username (Jabber ID: [phone number]@s.whatsapp.net). A password is generated using an unknown algorithm on the server end and sent to the client.
But if phone is rooted you can easily extract this password as mention here.
WhatsApp uses End-to-End Encryption, it stores all its data in encrypted form in internal storage.
Snapchat has stated that Snapchatters using a Rooted Android device will be blocked from logging in.
What you can do is to use the mixture of techniques by both giant applications WhatsApp and Snapchat i.e
Rule one of security. Don't invent your own security. You can't create a way to store a private key safely on any device. When you've just learned to generate a key.
I just read this article http://android-developers.blogspot.in/2013/02/using-cryptography-to-store-credentials.html where I learnt to generate security key.
A way that has already been invented is to make the user enter a string (something that is not saved on the phone) and use the the string for encryption.
The unsaved string method is easily broken by copying the ROM to a powerful machine and using brute force.
This is the overall problem with keeping access to the sensitive data. There is always a way to decrypt, then the encryption key might leak.
You might use EncryptedPreferences to store simple data in an encrypted way.
However just a quick look into source code reveals, that you must pass a password on app init.
EncryptedPreferences encryptedPreferences = new EncryptedPreferences.Builder(this).withEncryptionPassword("password").build();
This is security leak, if the password is hardcoded. This is not preferred method.
You might make use of the link you provided and generate a One-time pad.
public static SecretKey generateKey() throws NoSuchAlgorithmException {
// Generate a 256-bit key
final int outputKeyLength = 256;
SecureRandom secureRandom = new SecureRandom();
// Do *not* seed secureRandom! Automatically seeded from system entropy.
KeyGenerator keyGenerator = KeyGenerator.getInstance("AES");
keyGenerator.init(outputKeyLength, secureRandom);
SecretKey key = keyGenerator.generateKey();
return key;
}
Of course an ideal situation is taken into account, where the key generating function is ideally random.
Generate this key on first application start and use it in the library, which link I provided before.
Advantage: the key is different for each application installation. That means if the cracker got to know the method how cipher works, he is still unable to decrypt other devices as long as he does not have an access to such device's SharedPreferences
.
If you are generating and using the key in the application, it may be interesting to use the new (API 18+) Android Keystore Provider. The key is stored by a special secure service, which may use secure hardware if available.
It does not store an existing key (created elsewhere), but allow you to create and use keys without having access to the secret key itself. The idea is that the secret key never leaves the secure service, so that nobody can extract it, even your application (or root, if a secure hardware is used).
It also allows you to put restriction on how the key is used (e.g. for a fixed duration after the user authentication)