Android Data Security

Android Data Security

The most fundamental decisions that we used to face as a mobile application developer is how to hide sensitive information and whether we’re going to leave the information on the phone/app or not.

In this section we’re going to look at the number of different ways that android developers try to hide sensitive data. We will also see how our application data can be stolen and how to protect them.

What is sensitive data

Any data can be sensitive if that is confidential for you or your organization and as developer it ‘s our responsibility to let it not leak via application. Few are some sensitive data as usual we should care about: 

1. Web service URLS.

2. User name, password and other user details.

3. Google API key for your application.  

Types of Attack

Basically there are two types of attack :

1. Decompiling the APK : There are several tools available to decompile the APK. This is called Reverse Engineering. Attackers can easily decompile the APK and see inside the code (String.xml, .java, AndroidManifest.xml etc) and can steal our sensitive data.

2. Man In Middle Attack (MITM) : We can’t assure our application is protected over the http transmission. Someone sitting there and watching our communication if the transmission is insecure. There are several tools available to access the network traffic and steal the information like ProxyDroid, CharlsProxy or BurpSuit. Sending data via https can make it impossible to visible data by proxying it.

Usual ways of storing data inside app

1. Hardcoded in Java.

2. Hidden in Strings.xml, assets or AndroidManifest.xml

3. Stored in Shared Preferences or sqlite.

4. Hidden in build.gradle

5. Encrypted strings.

Now let’s see for each data hiding way in details.

1. Hardcoded in Java

Some of us is hiding API key or other information directly in code. But this can be seen after decompiling the APK. 

public class Constants{

    public static final String API_KEY = "Nti4kWY-qRHTYq3dsbeip0P1tbGCzs2";

}

2. Hidden in Strings.xml assests or AndroidManifest.xml

Any .xml file doesn’t get encrypted after decompilation. We can easily see the data 

<resources>
    <string name="API_key">Nti4kWY-qRHTYq3dsbeip0P1tbGCzs2</string>
</resources>

3. Stored in Shared Preferences or sqlite.

Many used to store data in Shared Preference. Data can be restored and accessed using adb shell command.The adb backup command can recover the databases as well shared preferences.

adb backup [-f <file>][-apk|-noapk] [-shared|-noshared] [-all][-system|nosystem] [<packages...>]

4. Hidden in build.gralde

Some used to hide data in build.config file using groovy script as below.

buildTypes {
    release {
        minifyEnabled false
        def API_Key =”Nkjfdj4kWY-qRHTYq3dsbeip0P1tdkskjhkdh”    

    }
}

But this also doesn’t work and can be find easily.

6. Encrypted strings.

There are also some general hiding techniques some developers used to hide password or sensitive data:

private static final byte[] myHidingKey = new byte[]{
        'M','y','P','a','s','s','W','o','r','D'};

But after little more efforts, this also can be find by unzipping APK

$ unzip app-debug.apk

$ strings classes.dex | grep My

MyPassword

All above techniques are not going to work out if we are working for highly secure data processing. Hackers can easily crack down our secure data. No matter how much we’re going to make our app secure but still there is always a breaking way. But still there are few techniques we can secure our application data better then above strategies. 

Secure ways of hiding data in Android 

1. Hiding data in NDK using C/C++ JNI

2. Setting up Proguard rules 

3. Encrypting urls over http connection.

4. Hiding in web service and use https connection.

1. Hiding data in NDK using C/C++ JNI

Unlilke java code c++ code can’t be decompiled, it can be only disassembled. That’s why some developers used to hide their sensitive data in C/C++ using Native Developer Kit (NDK). NDK enables to write code as C++ library and use with android project.

Here is the C++ code sample i used to hide MyPassword. It will create one library libhelloc.so. 

HelloC.c

#include <jni.h>

jstring Java_com_invendis_hellojni_MainActivity_getString( JNIEnv* env, jobject thiz ) {
    return (*env)->NewStringUTF(env, "MyPassword");
}

We can get password by loading C++ lib in MainActivity.

MainActivity.java

static {
    try {
        System.loadLibrary("helloc");
    } catch (UnsatisfiedLinkError ule) {
        Log.e("HelloC", "WARNING: Could not load native library: " + ule.getMessage());
    }
}
public native String getString();

2. Setting up Proguard rules 

Android sdk provides Proguard tool to obfuscate  the code. We can setup our rules in file proguard-rules.pro. Which ever rule we set, the tool will encrypt the code which is difficult to understand. We need to configure the proguard in build.gradle file as below: 

build.gradle

buildTypes {
    release {
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
    }
}

We can set progaurd rules as below, this rule will change the class, method/fields name in class MainActivity. 

proguard-rules.pro

-keep public class com.invendis.MainActivity

More: http://referenceforu.blogspot.in/2013/08/proguard-tutorial-android.html 

3. Encrypting urls over http connection.

If we have to send data through url for web service then better way of hiding data is to encrypt it. Only encrypt data part in url.

String urldata = URLEncoder.encode("d=1&u=username&p=password&s", "utf-8");

String url = "http://invendis.com/search?" + urldata ;

4. Hiding in web service and use https connection.

The best way to hide API key or any sensitive data is always keep in your server not in application. Get the data using https web service whenever require in encrypted format. Please check here for more about https and ssl.

More: https://developer.android.com/training/articles/security-ssl.html 

Summary: There are several ways to hide data in application and in future there might be some more, but best way is never to keep in application. Instead to keep in server. But still there is requirement to keep in application then we should pick the scheme based on our realization. The hackers are always sitting to break out but we should only make it possible to do reverse engineering for our secrets.