Save static secret key practices in Android

In this article, we'll talk about a possible problem with Android product development: How to save a static secret key in an app and keep it safe. Many mobile apps need to store some static string constants on the app side, which may be static keys, third-party appid, and so on. When you save these string constants, it involves how to guarantee the security of the secret key. How to ensure that the static secret key in the app is unique and safe, this is a very important problem, the company's product has a static string constant type of secret key, so an obvious question is how to generate a secret key, to ensure the security of the secret key?

several mainstream common practices for saving static keys today:(Reference: Android Security Development on key hard-coded)

• Save the static secret key by Sharedpreferences;

• Save in Java hard-coded way

• The static secret key is saved in so file by the Ndk method;

Several advantages and disadvantages of saving static secret key mode:

• The key directly plaintext exists in the Sharedprefs file, which is the least secure.

• The key is hard-coded directly in Java code, which is very insecure, and Dex files can easily be reversed into Java code.

• The key is divided into several paragraphs, some stored in the file, some stored in the code, and finally splicing them together, can be the entire operation is very complex, this because it is still in the Java layer, the reverse will only take a little time, it is also easy to reverse.

• Developed with the NDK, the key is placed in so files, encryption and decryption operations are in so files, which to a certain extent improved security, blocking some of the reverse, but experienced reverse will still use Ida cracked.

• In so file does not store the key, so file encryption and decryption operation of the key, the key is encrypted after the key is named other ordinary files, stored in the assets directory or other directories, and then add extraneous code in so file (flower instruction), although can increase the static analysis difficulty, However, you can use the dynamic mode method to trace the cryptographic decryption function, or find the key content.

It can be said that the safe storage key on the device is basically no solution, can only choose to increase the reverse cost. It takes a lot of effort to evaluate the importance of your app's application to select the appropriate technical solution, if you're an ordinary developer.

Keys to save in the product app:

Because the app needs to interact with the server, the client needs a default key to confirm the app's visitor identity if the user is logged in, so a default request key needs to be saved in the app.

• When the user is not logged in or is logged out, the requesting server uses the default key string;

• When a user logs on using a key string from the server or its;

This way we need to save a default key string on the app to identify the visitor identity of the user, and one question is how to ensure the security of the secret key string?

Several other ways to save keys are considered:

• Save the secret key information by saving the file;

• Storing secret key information through the database;

• Save the secret key information by configuring Gradle;

• Save the secret key information by configuring String.xml;

file Mode: the obvious way to save the secret key information by saving the file, one problem is that if the user maliciously delete the secret key information stored by the app, then the app will not be able to use the default key information, so the uniqueness of the secret key can not be guaranteed.

Database mode: As with the file to save the secret key information, save through the database is also unable to guarantee that malicious users delete the database information, so our app lost the default key information.

gradle Configuration: We explain how to configure variable information in Gradle by the following Gradle configuration variables.

String.xml: in the following we do a detailed introduction.

To configure variables by Gradle:

In Android Gradle, we can not only refer to dependent packages, but also execute scripts to configure static variables:

1 Buildtypes {2 Debug {3             //Show Log4Buildconfigfield "Boolean", "Log_debug", "true"5Buildconfigfield "String", "Appkeypre", "\" Xxx\ ""6             //confusing7Minifyenabledfalse8             //zipalign Optimization9ZipalignenabledtrueTen             //removing useless resource files OneShrinkresourcestrue A             //loading the default obfuscation configuration file -Proguardfiles getdefaultproguardfile (' proguard-android.txt '), ' Proguard-rules.pro ' -             //Signature the signingconfig Signingconfigs.debug -         } - Release { -             //do not display log +Buildconfigfield "Boolean", "Log_debug", "false" -Buildconfigfield "String", "Appkeypre", "\" Xxx\ "" +             //confusing AMinifyenabledtrue at             //zipalign Optimization -Zipalignenabledtrue -             //removing useless resource files -Shrinkresourcestrue -             //loading the default obfuscation configuration file -Proguardfiles getdefaultproguardfile (' proguard-android.txt '), ' Proguard-rules.pro ' in             //Signature - signingconfig Signingconfigs.relealse to         } +}

As shown in the code above, we have configured a string variable named Appkey in Gradle, and the compiled Gradle will generate the static variable in the Gradle compilation class: Buildconfig:

1 /**2 * Gradle compiled classes generated after compilation3  */4  Public Final classBuildconfig {5    Public Static Final BooleanDEBUG = Boolean.parseboolean ("true");6    Public Static FinalString application_id = "Com.sample.renter";7    Public Static FinalString build_type = "Debug";8    Public Static FinalString FLAVOR = "Internal";9    Public Static Final intVersion_code = 1;Ten    Public Static FinalString version_name = "1.0.0"; One   //Fields from build Type:debug A    Public Static Final BooleanLog_debug =true; -    Public Static FinalString appKey = "XXX"; -}

Can be found by configuring the Gradle configuration of static key decompile is also found when the secret key, but increased the difficulty of the reverse, and to avoid the malicious deletion by the user, so it is a good choice to save the static secret key in the app by gradle the configuration string.

Configuring secret key information via String.xml

Configuring secret key information via String.xml is also a good choice. After you define a string value in String.xml, get the decompile apk effect by code as follows:

You can see that the string string value cannot be explicitly displayed here, but there is an ID value for string string. However, it is necessary to note that a malicious attack can be found in the R.java file by the string ID of the corresponding string name in order to find the string value in String.xml. But this is also increased the difficulty of anti-compilation, relatively speaking is a good choice.

The practice of saving static keys in a product:

Finally, compared to the various static key storage scenarios, we decided to use the Gradle configuration + static code + string operation + String.xml value to implement the static secret key storage.

First, the static secret key is divided into four parts:

• The first part is stored by means of gradle configuration;

• The second part is stored in Java hard-coded way;

• The third part is stored by the way of Java string concatenation operation;

• Part IV is preserved through string.xml;

get Appkey The first part of the string:
Through the way of gradle configuration we have already introduced, it is in the Mudle in the Gradle file in the BuildType node to define the string variable, it is important to note that if there is a formal environment and test environment of the points, you need to define the string variables, So we can get the string of the first part of Appkay through Buildconfig.

1 /** 2 * Get Appkey part1 3  */ 4  Public Static String getBK1 () {5         return Buildconfig.appkey; 6     }

Get Appkey The second part of the string:

The second part of the Appkay string is out of the operation, where the operation can be arbitrary operation, the more complex the better, the more people can not understand the better, of course, the results need to be unique. Like what:

1  Public Static StringBuffer getBk2 () {2         New StringBuffer (); 3         Sb.append (Config.getgbs (2, 5)); 4         return sb; 5     }

And here's the implementation of the Getgbs method:

1  Public Static intGetgbs (intXinty) {2          for(inti = 1; i<= x * y; i++){3             if(i% x = = 0 && i% y = 0)4                 returni;5         }6 7         returnX *y;8}

The final result returned is: 10, of course, different strings require different algorithms;

Get Appkey The third part of the string:

This is just a simple hard-coded string.

1  Public Static String getBK3 () {2     return "Xhxh"; 3 }

Get Appkey Part fourth string

• Define the fourth part of Appkey in String.xml

<string name= "Bk4" >chs</string>

• Gets the string value defined in the string in the code

1  Public Static String GetBk4 () {2    mcontext (). Getresources (). getString (R.STRING.BK4); 3 }

Get the final Appkey string:

1 /**2 * Get the final Appkey string3  */4  Public Static byte[] Getdefaultkey () {5StringBuffer SB =NewStringBuffer ();6 Sb.append (GetBK1 ()). Append (GetBK2 ( )). Append (GetBk3 ()). Append (GetBk4 ());7 8         returnsb.tostring ();9}

So after a series of operations, we get the final static secret key. Of course, the best implementation of the product Code confusion function, which can also increase the difficulty of the reverse.

Summarize:

• Saving static keys on the app side can be implemented by Sharedpreferences, Java hard-coded, so files in the NDK, files, databases, gradle configuration;

• In order to ensure the security of secret keys can be mixed in a variety of ways, which can increase the difficulty of malicious anti-compilation;

• In the app side to save the secret key can not really guarantee the security of the secret key, can only increase the difficulty of anti-compilation;

• Static keys can be configured using the Gradle configuration and the String.xml configuration key is used to increase the difficulty of reverse decompile;

• It is not recommended to use the file, the database method to save the static secret key, easy to be malicious deletion by the user, and an unpredictable error;

In addition to product development technology, skills, practice interested students can refer to my:
Android Product Development (12) –>app Long Connection implementation
Android Product Development (13) –>app rotation operation
Android Product Development (14) –>app Upgrade and update
Android Product Development (15) –> Memory object serialization
Android Product Development (16) –> Developer Options
Android Product Development (17) –>hybrid Development
Android Product Development (18) –>webview problem Collection
Android Product Development (19) unit tests in –>android Studio
Android Product Development (20) –> code review
Android Product Development (21) UI optimization in –>android
Android product Development (22) –>android Practical Debugging skills

Transferred from: http://blog.csdn.net/qq_23547831/article/details/51953926

Save static secret key practices in Android (GO)