【问题标题】:Proper usage of EncryptedSharedPreferences正确使用 EncryptedSharedPreferences
【发布时间】:2020-02-25 06:08:45
【问题描述】:

Android 最近发布了 EncryptedSharedPreferences,它会自动加密 SharedPreferences 键/值数据。虽然这很好,但我发现我可以简单地挂接到 API 调用并检索解密的值。除了在调用 EncryptedSharedPreferences 之前手动加密数据(哪种方式违背了它的目的)并实施更强大的运行时篡改来检测挂钩之外,还有什么方法可以抵抗此类攻击?

此外,我还能够通过挂钩 javax.crypto.Cipher 并检查 SecretKeySpec 和 IvParameterSpec 来提取用于加密 EncryptedSharedPreferences 中的键/值对的加密密钥。这看起来很奇怪,因为加密密钥不是应该驻留在 Android 密钥库中并且永远不会离开吗?

【问题讨论】:

    标签: android security tampering androidx-security


    【解决方案1】:

    EncryptedSharedPreferences 的目的是保护其加密的数据,使黑客无法理解数据,它无法防止窃取数据。但是,如果您获得加密数据并且无法解密,您该怎么办?如果你不能,那么 EncryptedSharedPreferences 已经达到了它的目的。

    【讨论】:

    • 问题是,通过连接到 EncryptedSharedPreferences.encryptKeyValuePair,我能够转储解密数据,因此它似乎不提供运行时保护。
    • 那么你能得到加密数据然后成功解密吗?没有密钥怎么解密?我假设 EncryptedSharedPreferences 使用 AES 加密数据对吗?
    • 我不必自己解密。我只是用 Frida 挂钩相关的 API 调用并获取解密的数据。
    • 哦,我明白了。所以无论如何,无法阻止api挂钩,不是android系统:(
    • 实际上,除了通过挂钩 encryptKeyValuePair 转储出解密数据外,我还可以通过挂钩 javax.crypto.Cipher 并检查 SecretKeySpec 来提取用于加密键/值对的加密密钥和 IvParameterSpec。这似乎很奇怪,因为加密密钥不是应该驻留在 Android 密钥库中并且永远不会离开吗?
    猜你喜欢
    • 2020-09-21
    • 2019-12-03
    • 2020-06-08
    • 2020-04-22
    • 2021-04-02
    • 2020-08-05
    • 2021-06-19
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多