【问题标题】:Android Secure Storage安卓安全存储
【发布时间】:2010-07-27 00:11:35
【问题描述】:

我想在我的 Android 应用程序中存储一些小而关键的信息,例如 AES 密钥。推荐的方法是什么?我不想将密钥硬编码为我的应用程序的一部分。

我查看了KeyStore,但它并没有真正解决我的问题。鉴于我可以提供密码,它可以存储我的密钥。然后我需要找到一个安全的地方来存储这个密码,这和我原来的问题一样。

是否有内置的 Android 类来执行此任务?还是我应该寻找第三方库?使用 NDK 对我来说也是可以接受的。

更新:

我希望找到一个用于存储的 Android API,以保证只有存储了某些信息的应用程序才能将其取回。 Android OS 可以根据应用程序的签名来强制执行此操作。这样我的应用程序可以在第一次运行时生成一个随机密钥并将其存储在安全存储中以供以后使用。有没有这方面的 API?

【问题讨论】:

  • 如果您将数据存储在应用程序的/data/data/<packagename>/ 中,那么只有该应用程序可以访问它。但是,如果手机已植根,则情况并非如此。但除此之外,您应该可以在那里存储密码数据。

标签: android key-management


【解决方案1】:

是否有内置的 Android 类 执行此任务?

除了java.io.File,没有。

或者我应该寻找第三方 图书馆?

您可以尝试,但我怀疑大多数看起来像您已经拒绝的解决方案。大多数安全数据存储都涉及密码,并假设密码保存在其他地方(例如,在用户的脑海中)。例如,OI Safe 有一个基于 Intent 的系统,允许应用程序将东西存储在保险箱中,但随后用户参与解锁保险箱 IIRC。

【讨论】:

  • 感谢您的回答。它并不能真正解决我的问题,但很高兴知道这些限制。
  • 没有这样的API是什么意思?此保证是应用程序存储在内部存储中的所有文件的默认行为,因为每个应用程序都被赋予一个唯一的用户 ID,并且应用程序创建的文件的默认模式只能由创建者的 uid 读取/写入。唯一的例外是 (a) 放置在外部存储上的文件,以及 (b) 使用标志创建的文件,以使它们在世界范围内可读/可写。另一个应用程序可以使用您的 uid 运行的唯一方法是(a)它使用您的证书签名,并且(b)你们都有相同的 android:sharedUserId。
  • @hackbod:我的印象是 OP 正在寻找能够在 root 设备中存活的东西。您的解决方案虽然完全不合适,但可以通过生根轻松击败。但是,防根解决方案绝对是我的一个假设,如果根不是特别关注的问题,我向 OP 道歉。
  • 哦,如果用户有 root 权限,就没有您可以保护的数据,句号,故事结束。您可以尝试让事情变得更加困难,但实际的保护已经没有了。
  • @hackbod 这不是真的。虽然 ARM 芯片可能不支持它。使用支持可信计算组规范的芯片,您可以创建一个只能通过具有特定哈希值的代码访问的私钥。硬件的工作是确保这种保护到位,并且植根设备不会改变这一点。所以这在技术上是可行的,但我不确定 ARM 芯片是否实现了这项技术。
【解决方案2】:

如果您最终使用 KeyStore API,一个解决方案是在应用程序每次需要访问 KeyStore 时在运行时动态生成您的密码。如果您的密码算法基于与特定安装相关的简单但可更改的变量,例如设备 MEID(或在运行时获得的物理设备的其他特定 ID),您可以提供锁的钥匙,这变得越来越困难选择。

示例:使用物理设备中的 ID,剪切三个位置并将它们附加到 ID 字符串的末尾位置,然后以编程方式将您的姓名首字母附加到字符串中。我认为这种方法会提供一层不易破解的安全性,除非破解者知道您是如何制作密钥的(即拥有您的源代码)。

MEID = MEID + "fluffy" + "2008";

MEID 是一个带有设备 ID 的字符串,“fluffy”是你最好的朋友猫的名字,“2008”是你生活中重要事件的年份。然后将这个新字符串输入一个数组,解析一个适合您的数字(例如,您获得驾照的那一天),取出三个字符并将这些字符放在字符串的末尾。从琴弦的前面剪辑到您需要放置钥匙的位置数,然后离开。这不应该是一个处理器密集型任务,因此,使用变量的一些容错代码,您应该能够在您的主进程中运行它,即使不太担心从系统中获得 ANR。如果您真的想变得青蛙,请在某个时候将字符串转换为位并“按位运算”更改。 Viola,一种低开销的动态密钥,它是运行它的设备所独有的!

编辑:

正如@RedWarp 指出的那样,对于任何具有适当工具和动机的目标代码,反编译 .apk 始终是可行的。如果“密钥”生成是一个非常重要的过程,那么将密钥生成抽象到应用程序范围之外是必须的。

我试图用这个答案来表达的真正观点是,在最低限度的安全性方面,稍微提前考虑一下就可以了。更强的安全性比我的简单回答更深入。

【讨论】:

  • 通过默默无闻的安全性可能只会延迟持久的攻击者。它确实为食谱增添了香料。它不应该被用作唯一可行的选择。
  • @SamQuest 当然,这并不是唯一可行的选择,而是一个开始,让人们以其他独特的方式思考密钥安全性。但除非所讨论的应用程序是金融应用程序或其他高安全性实施,否则这应该提供足够的隐蔽性。另一种选择可能是通过 RPC 脚本或其他方式远程提供隐藏密钥,但这种方法可能会增加额外的复杂性。
  • 反转一个.apk很容易,因此得到算法
【解决方案3】:

您必须在此处区分键和应用数据。

“AndroidKeyStore”KeyPairGenerator 和 KeyGenerator 将它们从您的应用生成的密钥存储在 KeyStore 中的别名下,并将这些密钥与您的应用相关联。如果设备具有“安全硬件”,您可以指定使用它并且密钥将存储在那里。

密钥没有密码。您使用别名来指定要使用的密钥。只有您的应用可以检索它生成的密钥。

见:https://developer.android.com/training/articles/keystore.html

对于您应用的私有数据,如果我理解“.. 一个用于存储的 Android API,这样可以保证只有存储了某些信息的应用才能将其取回......”,您可以查看以下内容:

https://developer.android.com/guide/topics/data/data-storage.html#filesInternal https://developer.android.com/guide/topics/data/data-storage.html#db

【讨论】:

    猜你喜欢
    • 2012-10-14
    • 2017-04-07
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2023-03-12
    • 1970-01-01
    相关资源
    最近更新 更多