1

背景

根据一篇新的 Android 开发者博客文章（可在此处获得），您应该使用一种新技术来加密和解密存储在数据库或 sharedPreferences 中的敏感数据（例如密码），这样即使具有 root 权限的人也可以很难读。

新方法是：

public static SecretKey generateKey() throws NoSuchAlgorithmException {
    // Generate a 256-bit key
    final int outputKeyLength = 256;

    SecureRandom secureRandom = new SecureRandom();
    // Do *not* seed secureRandom! Automatically seeded from system entropy.
    KeyGenerator keyGenerator = KeyGenerator.getInstance("AES");
    keyGenerator.init(outputKeyLength, secureRandom);
    SecretKey key = keyGenerator.generateKey();
    return key;
}

问题

根据文章（以及我尝试过的内容），此代码每次调用它时都会创建一个新的不同键，所以我对此事有一些疑问：

  1. 应用程序会为旧版本的 Android 做什么？

  2. 此类应用程序将如何处理将 android OS 更新为它应该工作的新方式（API post 17 到 API 17）？

  3. 由于它不是确定性的，这意味着解密不能重新创建相同的密钥，那么这是否意味着密钥也被存储以便将其用于解密（以及以后的加密）？这样的事情不会错过重点吗？

  4. 假设我有代码生成的密钥，我将如何使用它来加密和解密来自 DB 和 sharedPreferences 的数据？

  5. 在文章中，他们说：

事实上，Android 现有的安全模型已经为这​​类数据提供了充足的保护。用户凭据应与设置的 MODE_PRIVATE 标志一起存储并存储在内部存储中

这是什么意思？不需要整个密钥生成，因为 Android 已经加密了所有内容？我的设备是 root 的，我可以轻松地说数据从未加密并且易于阅读（尤其是只是 xml 的 sharedPreferences）。

4

1 回答 1

3

应用程序会为旧版本的 android 做什么？

不是这个，因为它在所有版本的 Android 上都没有用，正如博客文章所指出的那样。

由于它不是确定性的，这意味着解密不能重新创建相同的密钥，那么这是否意味着密钥也被存储以便将其用于解密（以及以后的加密）？这样的事情不会错过重点吗？

恰恰。引用博客文章：“请注意，这种方法的安全性依赖于保护生成的密钥，这取决于内部存储的安全性。目标文件不加密（但设置为 MODE_PRIVATE）将提供类似的安全性。”

老实说，我不知道为什么博客文章是这样写的。唯一具有重要价值的加密形式是用户提供密码（或高级形式，例如双因素身份验证）。

这是什么意思？不需要整个密钥生成，因为 android 已经加密了所有内容？

不，这意味着任何可以获取加密文件的人也可以获取加密密钥，这使得加密在很大程度上毫无意义。

请注意，Android将在用户打开全盘加密的那些设备上“加密所有内容”。

于 2013-02-24T01:55:07.770 回答