转载请注明出处：https://blog.csdn.net/mythmayor/article/details/107228669

引言

在日常开发中我们经常需要保存一些私密的信息，例如加解密的密钥等等。这时候我们就要来考虑如何存储密钥了。先来简单介绍几种存储方式：

Java硬编码方式

SharedPreferences存储

文件存储

数据库存储

以上几种存储方式是很不安全的，例如采用硬编码方式存储，程序包很容易被反编译获取到密钥。SharedPreferences、文件和数据库又有可能因为用户的误删操作而丢失密钥，所以一般很少存储到这一类的文件中。那么问题来了，我们应该用什么方式来确保密钥的存储相对更安全呢？

密钥存储方案

在日常开发中，推荐运用若干种方案拼接起完整的密钥。

在下面的案例中，我将运用以下方式输出密钥各部分内容(后面会逐个讲解)

Java硬编码

gradle配置

特殊的算法

利用strings.xml

现在假设我们需要进行AES加解密，按要求来定义一个密钥，密钥的形式可能是这样的：

String AES_KEY = "1234567890!@#$%^";//硬编码方式定义AES密钥

是不是已经有同学看不下去了。。。

好吧，更好的方式是这样的：

String AES_KEY = ProjectUtil.getAESKeyPart1(3, 4)//根据自定义算法输出密钥第1部分

+ BuildConfig.AES_KEY_PART2//根据gradle配置输出密钥第2部分

+ CommonUtil.getString(R.string.AES_KEY_PART3)//根据string.xml输出密钥第3部分

+ MyConstant.AES_KEY_PART4;//根据硬编码方式输出密钥第4部分

String AES_KEY_PART4 = "!@#$%^";

怎么样？是不是瞬间感觉难懂了一些，下面就来逐一讲解。

第一部分：ProjectUtil.getAESKeyPart1(3, 4)

这部分很好说，这里我自定义了一个算法，用以迷惑“有缘人”

public static int getAESKeyPart1(int x, int y) {

for (int i = 1; i <= x * y; i++) {

if (i % x == 0 && i % y == 0)

return i;

}

return x * y;

}

我这里定义的算法主要输出的是数字，在实际开发中你也可以定义一些类似的算法。

第二部分：BuildConfig.AES_KEY_PART2

这里主要是通过gradle的配置来自动生成AES_KEY_PART2这个常量。具体操作如下：

打开Module下的build.gradle文件，在android标签下的buildTypes下添加配置。

buildTypes {

release {

buildConfigField "boolean", "LOG_DEBUG", "true"//显示Log

buildConfigField "String", "AES_KEY_PART2", "\"3456\""

minifyEnabled false

proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'

}

debug {

buildConfigField "boolean", "LOG_DEBUG", "false"//不显示Log

buildConfigField "String", "AES_KEY_PART2", "\"3456\""

minifyEnabled false

proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'

}

}

如上所见，我使用buildConfigField关键字添加了LOG_DEBUG和AES_KEY_PART2两个字段。LOG_DEBUG用以控制是否输出并显示Log。在添加完配置之后，就可以Rebuild项目了，然后你就可以打开自动生成的BuildConfig类，这时候你添加的常量就在此类当中了。

public final class BuildConfig {

// ...

public static final String AES_KEY_PART2 = "3456";

public static final boolean LOG_DEBUG = false;

}

需要注意的是，在定义字符串(尤其是数字字符串)的时候，一定要定义成：

buildConfigField "String", "AES_KEY_PART2", "\"3456\""

而不是

buildConfigField "String", "AES_KEY_PART2", "3456"

原因是第一种方式的话会在BuildConfig中生成

public static final String AES_KEY_PART2 = "3456";

而第二种方式则会在BuildConfig中生成

public static final String AES_KEY_PART2 = 3456;

第二种自然就会报编译错误了。

第三部分：CommonUtil.getString(R.string.AES_KEY_PART3)

在我的strings.xml中定义了一个字符串：

7890

第四部分：MyConstant.AES_KEY_PART4

在我的MyConstant类中定义了一个常量：

String AES_KEY_PART4 = "!@#$%^";

总结

上面介绍的密钥存储方式极大的增加了逆向的难度，辅以代码混淆等手段，在很大程度上提高了密钥存储的安全性。总体来说，在App端保存密钥并无法完全保证密钥的安全性，只能通过一些手段增加被反编译的难度。