3
votes

I'm reading about store a secretkey (to encrypt/to decrypt data) and seems there is no way achieve that. One can only increase difficult for an attacker accomplish this.

It's really like that?

What I've got so far:

Store in shared preference ( private mode ) - Rooted phone will be able to retrieve it.

NDK C/C++ native code, create .so file - Hard to decompile, but one could call this .so file and retrieve it.

A webserver to store the key, looks useless, if a have to send credentials, a malicious ware could log key taps.

Am I too paranoic?

2
You are never quite paranoid but you have to come to a partnership with usabilitypedrofb
@pedrofb I guess so...ramires.cabral

2 Answers

9
votes

Why do not you use Android Keystore?it is designed for this purpose https://developer.android.com/training/articles/keystore.html

The Android Keystore system lets you store cryptographic keys in a container to make it more difficult to extract from the device

It has considerable advantages over shared preferences or private files like extraction prevention or key use authorization I do not consider storing private keys on the server

Security Features

Android Keystore system protects key material from unauthorized use. Firstly, Android Keystore mitigates unauthorized use of key material outside of the Android device by preventing extraction of the key material from application processes and from the Android device as a whole. Secondly, Android KeyStore mitigates unauthorized use of key material on the Android device by making apps specify authorized uses of their keys and then enforcing these restrictions outside of the apps' processes.

In some devices with dedicated hardware it is implemented on it. As a programmer you can know is a key is hardware-protected

The concept is similar to iOS KeyChain, but whereas IOS KeyChain can store passwords, generate and import cryptographic keys, Android KeyStore only allows to generate cryptographic secret keys by the application ( no import functions)

The keys also can be protected requiring user to unlock the device and / or presenting the fingerprint

For example, to secure a password, is possible to generate a cipher key protected with fingerprint, and use it to encrypt user's credentials that could be stored in preferences

2
votes

You are correct. Most security experts will tell you there is no such thing as an absolutely secure system. The proper way to think of it is in terms of the level of resources an attacker must use to break your system.

You then balance your security measures between the value of the data and other considerations like the complexity of your solution and other costs.

To elaborate on your examples, assuming you aren't worried about the legitimate owner/user of the phone being the attacker, you can assess as follows:

  1. Rooting a phone is a risk if an attacker gets physical possession. To assess, how valuable is the data versus the likelihood of a phone getting lost/stolen, the person who then has it caring to get the key and knowing how to root a phone.
  2. Obscuring secret information is generally considered useless. I personally think it depends a little bit on the circumstances. Here, again, an attacker would need to root the phone, etc. The problem with obscuring secret information is it only takes one person to figure out what you've done and make that information available to completely lose the value in doing it.
  3. If you have a key logger, what security do you have anyway?

You should look at the possibility of using a "secure element". See this post on the security Stack Exchange for some good information.