【问题标题】:Encryption key: Can I use obfuscation?加密密钥:我可以使用混淆吗?
【发布时间】:2015-10-08 16:03:42
【问题描述】:

我正在为某人构建一个 iOS 应用程序。该应用程序将用于参加模拟考试以获得专业执照。问题数据存储在 Core Data 中,但问题和答案字符串需要加密,因为客户花费大量时间编写它们并且不希望其他人窃取他的工作以用于竞争产品。

所以我想要做的是将核心数据中的属性设置为可转换,使用自定义 NSValueTransformer 将字符串转换为 NSData,并在转换时使用 RNEncrypt 进行加密和解密。

到目前为止一切顺利。

这是我的困境:我需要使用密钥来加密和解密数据,但我如何获取/创建它?

我的选择:

  • 硬编码 == 糟糕!
  • 生成密钥并存储在钥匙串中 == 不是正确的安全类型。即不保护设备的所有者。
  • 根据用户密码生成密钥 == 用户无需登录。
  • 应用程序连接到服务器并获取带有一些身份验证内容的密钥(我不知道具体涉及什么)== 我不想依赖网络连接来使应用程序工作。
  • 混淆,我觉得如果我从其他字符串和方法 sig 的位创建一个字符串,然后对其进行哈希处理就足够了 == 可能不会。

那么我的问题是: - 混淆,就够了,还有其他人成功了吗? - 从我的研究中,我了解到拥有 ipa 的黑客可以看到所有硬编码的字符串、类名和方法信号,但他们看不到方法中的代码(对吗?),那么有人怎么能阅读如果它是在方法内部构建/生成的,则密钥? - 作为标题,我可以使用混淆吗? - 有没有我遗漏的选项?

为了记录,如果必须的话,我会让人们注册并登录。

【问题讨论】:

    标签: ios objective-c security encryption key


    【解决方案1】:

    无法在本地安全地存储数据。只要您能够解密它,攻击者也可以。这适用于每一种加密技术。不管你尝试什么。

    您必须为服务器上的每个数据点存储数据或不同的解密密钥,并且每次都一个一个地检索它。您还必须确保用户不只是发送 100 个请求并手动检索所有数据。

    请注意,在服务器上仅存储一个密钥与将其硬编码到应用程序中的结果完全相同。不限制请求只会导致攻击者需要更多的时间,而不仅仅是查看已经解密的本地数据库。

    当然,您可以对其进行模糊处理,使其看起来像是具有良好的加密功能 - 但如果有人想要获取数据,他将能够。

    关于 ipa 中的代码:您将无法看到原始代码,但您将能够看到产生与原始代码相同输出的一些代码。只要设备可以生成有效密钥,攻击者也可以。

    我不知道是否有一个庞大的社区正在通过随机应用程序窃取一些内部问题/答案/数据,我对此表示怀疑。

    您只需要将产品做得非常好,以使任何具有相同数据的竞争产品都没有机会与之抗衡。数据本身总是可能被“窃取”。

    【讨论】:

    • 感谢您的信息。我认为不太可能有人会尝试窃取数据,但他付出了很多努力来加密他赖以谋生的原始 Windows 版本的数据,我说过我会加密 iOS版本,所以这就是我必须做的,如果只有 1 人设法获取数据并使用它,那么我让他失望了,不是吗。
    • 我 10000000% 确信您也可以从 Windows 版本中提取数据 - 问题不是 iOS 特定的。如果没有攻击者能够做同样的事情,您就无法安全地对数据进行解密和加密。
    • 我很感激,我希望没有人试图破解它,但如果所有数据都未加密存储,那么现在可能已经有人复制了。不过,这个人对 Windows 版本所做的是,当客户从他的网站上付费并下载应用程序时,他们必须打电话给他并给他一个密码,然后他给他们一个解锁码。十多年来,这对他来说效果很好,但显然不是非常用户友好/方便,我看不到该系统通过了苹果审查过程。
    • @KristianFox 我可以向你保证,每个拥有这些解锁代码的人都可以在尝试时提取数据。它根本不会改变任何东西,本地存储的数据不安全
    • @luk2302 这一切都很好,但是......如果没有 HSM、TPM、安全元件或等效物,则无法在不使密钥在内存中可用的情况下进行解密。这并不意味着没有可以应用的“最佳实践”。缺少的是对所需安全级别的明确声明,即数据对所有者和攻击者的价值、攻击者是谁、他们的能力以及他们愿意/能够在资源中投入什么。需要围绕所需的标准设计安全性。在加密操作期间将密钥保存在内存中是可以接受的。
    猜你喜欢
    • 1970-01-01
    • 2010-10-19
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2010-10-02
    • 1970-01-01
    • 2016-05-01
    相关资源
    最近更新 更多