Android - 更安全地保存静态密钥

转载请注明出处: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中定义了一个字符串:

<string name="AES_KEY_PART3">7890</string>
第四部分:MyConstant.AES_KEY_PART4

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

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

总结

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值