混淆密钥缓存中的漏洞?安卓许可
每当 Android Market Licensing ping 服务器返回 GRANT_ACCESS pong 时,我就会缓存用户的身份验证。
有人发现这个策略有什么漏洞吗?我相信它非常强大,因为我正在混淆密钥,而消除混淆的唯一方法就是知道盐。现在,可以想象有人可以打开 apk 并寻找盐,但这并不是我认为值得担心的破解程度。
正如您所看到的,设备特定信息被添加到混淆技术中。
// Try to use more data here. ANDROID_ID is a single point of attack.
String deviceId = Secure.getString(getContentResolver(), Secure.ANDROID_ID);
obfuscator = new AESObfuscator(SALT, getPackageName(), deviceId);
mChecker = new LicenseChecker(this, new ServerManagedPolicy(this, obfuscator), BASE64_PUBLIC_KEY );
接下来创建持久数据:
public void allow() {
SharedPreferences settings = getSharedPreferences(PREFERENCES_EULA, 0);
SharedPreferences.Editor editor = settings.edit();
String uid = UUID.randomUUID().toString();
if(!settings.contains(ACCESS_KEY)) {
editor.putString(ACCESS_KEY,uid);
editor.commit();
}
if(!settings.contains(OBFU_ACCESS_KEY)) {
String obfu = obfuscator.obfuscate(uid);
editor.putString(OBFU_ACCESS_KEY,obfu);
editor.commit();
}
然后,我使用另一种方法来检查缓存内容的状态:
boolean isCachedLicense() {
SharedPreferences settings = getSharedPreferences(PREFERENCES_EULA, 0);
if(settings.contains(ACCESS_KEY) && settings.contains(OBFU_ACCESS_KEY)) {
String accessKey = settings.getString(ACCESS_KEY, "");
String obAccessKey = settings.getString(OBFU_ACCESS_KEY, "");
try {
if(accessKey.equals(obfuscator.unobfuscate(obAccessKey))) {
return true;
} else {
return false;
}
} catch (ValidationException e) {
e.printStackTrace();
return false;
}
} else {
return false;
}
}
最后,我检查了 LicenseCheckerCallback
isCachedLicense >: @Override dontAllow
和 @override applicationError
。如果 isCachedLicense 为 true,则我让用户转发。
此外,完整的源代码位于此处。
I'm caching a user's authentication to whenever the Android Market Licensing ping server returns a GRANT_ACCESS pong.
Does anyone see any vulnerabilities with this strategy? I believe it is very strong, since I am obfuscating a key, and the only way to unobfuscate is to know the salt. Now, someone could conceivably open the apk and look for the salt, but this is not really the level of cracking I think is too important to worry about.
As you can see, device specific information is being added to the obfuscation technique.
// Try to use more data here. ANDROID_ID is a single point of attack.
String deviceId = Secure.getString(getContentResolver(), Secure.ANDROID_ID);
obfuscator = new AESObfuscator(SALT, getPackageName(), deviceId);
mChecker = new LicenseChecker(this, new ServerManagedPolicy(this, obfuscator), BASE64_PUBLIC_KEY );
Next the creation of the persisted data:
public void allow() {
SharedPreferences settings = getSharedPreferences(PREFERENCES_EULA, 0);
SharedPreferences.Editor editor = settings.edit();
String uid = UUID.randomUUID().toString();
if(!settings.contains(ACCESS_KEY)) {
editor.putString(ACCESS_KEY,uid);
editor.commit();
}
if(!settings.contains(OBFU_ACCESS_KEY)) {
String obfu = obfuscator.obfuscate(uid);
editor.putString(OBFU_ACCESS_KEY,obfu);
editor.commit();
}
Then, I used another method to check the state of the cached content:
boolean isCachedLicense() {
SharedPreferences settings = getSharedPreferences(PREFERENCES_EULA, 0);
if(settings.contains(ACCESS_KEY) && settings.contains(OBFU_ACCESS_KEY)) {
String accessKey = settings.getString(ACCESS_KEY, "");
String obAccessKey = settings.getString(OBFU_ACCESS_KEY, "");
try {
if(accessKey.equals(obfuscator.unobfuscate(obAccessKey))) {
return true;
} else {
return false;
}
} catch (ValidationException e) {
e.printStackTrace();
return false;
}
} else {
return false;
}
}
Finally, I checked if isCachedLicens
e in the following locations of the LicenseCheckerCallback
:@Override dontAllow
, and @override applicationError
. If isCachedLicense
is true, then I let the user forward.
Also, full source code is located at here.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
一般来说,用盐进行混淆是一种较弱的策略。攻击者只需要找出盐,一旦你知道你在寻找什么,这就相当简单,并且可以在不直接访问你的应用程序的情况下完成。一旦(任何人)发现盐,我们所有的安装基础都将受到损害。
最好的选择是,不要使用具有固定密钥的混淆算法,而是使用经过验证的加密库+算法,其密钥对于用户或您所运行的设备来说是唯一的。
Obfuscation with salt is generally speaking a weak strategy. The attacker just has to figure out the salt, which is fairly straight forward to do once you know what you're looking for, and can be done without direct access to your application. Once the salt is discovered (by anyone), all of our install base has been compromised.
Your best bet is, instead of using an obfuscation algorithm with a fixed key, to use a proven encryption library+algorithm with a key that is unique to either the user or the device that you're running on.