【问题标题】：Store an encryption key in Keychain while application installation process在应用程序安装过程中将加密密钥存储在 Keychain 中
【发布时间】：2010-10-27 13:52:42
【问题描述】：

我需要我的应用程序使用客户的电话号码为我的网络服务生成唯一 ID。当然，电话号码是唯一的，但它必须是安全的。所以它可以用对称加密来实现（非对称将在以后，因为资源泄漏），但我不知道在哪里存储加密密钥。

1.

我不知道为什么，但是在代码中将键存储为静态字段似乎不好。可能是因为从这里读取它太容易了，即使不运行应用程序。

2.

最好将密钥存储在 Keychain 中并通过请求从此处获取。但是为了避免#1，有必要在安装过程中安装钥匙串的钥匙。可能吗？该怎么做？

3.

我不知道证书的作用。它们对解决问题有帮助吗？

4.

从服务器传输密钥也是一个坏主意，因为很容易嗅探它。

【问题讨论】：

您是否考虑过使用设备 ID 而不是电话号码？如果您只需要唯一的 ID，它就可以完成这项工作。
我需要使用电话号码，因为有一些额外的短信服务。

标签： iphone objective-c security certificate keychain

【解决方案1】：

解决嗅探问题的方法是通过 HTTPS 为 Web 服务进行通信。 NSURLConnection 很容易做到这一点，我所知道的所有 Web 服务引擎都可以毫无问题地处理 HTTPS。这将立即解决您的许多问题。

100-1000x解密瓶颈在哪台机器上？您的服务器是否太忙以至于无法进行异步解密？你应该很少在电话上这样做，以至于它应该是无关紧要的。我不是说 asym 是这里的答案。只是它的性能开销不应该是保护单个字符串的问题，解密一次。

您的服务需要 SMS 以使所有用户都必须提供他们的电话号码？您是在尝试自动获取电话号码，还是让用户自己输入？通过私有 API（或非私有但未记录的配置数据）自动获取电话号码并将其发送到服务器可能会违反服务条款。这是 Apple 希望保护用户免受其侵害的特定用例。您绝对需要在您的 UI 中非常清楚您正在执行此操作并获得明确的用户许可。

我个人的身份验证如下：

服务器发送挑战字节
客户端发送 UUID、日期和哈希（UUID+challenge+userPassword+obfuscationKey+date）。
服务器计算相同，确保日期在合法范围内（30-60 秒是好的）并验证。
此时，我通常让服务器生成一个长的、稀疏的、随机的会话 ID，客户端可以将其用于此“会话”的剩余部分（从接下来的几分钟到下一年），而不是重新进行身份验证在每条消息中。

ObfuscationKey 是您将其硬编码到程序和服务器中的密钥，以使第三方更难创建虚假客户端。这是不可能的，期间，不可能，安全地确保只有您的客户端可以与您的服务器对话。然而，obfuscationKey 会有所帮助，尤其是在逆向工程更加困难的 iPhone 上。使用 UUID 也有帮助，因为它比电话号码更不为第三方所知。

请注意其中的“userPassword”。用户应该使用只有用户知道的东西进行身份验证。 UUID 和电话号码都不是这样的东西。

上面的系统，加上 HTTPS，应该很容易实现（我已经用多种语言做过很多次了），具有良好的性能，并且对于广泛的“适当”来说安全到适当的级别。

【讨论】：

1.我在哪里可以找到该服务条款来确定？ 2. 我应该使用哪些 iPhone SDK 类来散列？ 3. 谢谢！我需要一点时间思考，然后提出更多问题或接受。
1.阅读主要 iPhone 开发者门户上的“iPhone SDK 协议”。它当然引用了未指明的“Apple 的最佳实践”，这又回到了这样一个事实，即您永远无法 100% 确定您可以做什么和不可以做什么。 2. SHA1 适合这种散列。看看github.com/ameingast/cocoacryptohashing。
让我稍微说明一下我的需求：我有一个客户端-服务器游戏，不希望玩家因为经典的登录密码注册而感到疲倦。如果合法的话，我似乎可以改用 UUID。嗅探问题看起来是通过使用 HTTPS 解决的，因为我知道整个 HTTP 包是加密的并且不可能被嗅探。这似乎已经足够了，也是最简单的方法来替代注册并防止不诚实，对吧？
UUID 可能是解决此类问题的一个很好的选择，如果您正在寻找的是游戏的合理安全性。 UUID 不容易被猜到，但它们是一种常见的识别标记，因此其他开发人员可以创建这些数字的大型数据库并使用它们来冒充其他用户。对于跟踪高分，这没什么大不了的，因此 UUID 是 Apple 推荐的标识令牌。为了清楚起见，当我们在这里说“UUID”时，我们正在讨论 [[UIDevice currentDevice] uniqueIdentifier]。
谢谢。决定通过 https 使用 UUID。它足够节省和高效，虽然 UUID 不像 DB-key 那样短字符串）

【解决方案2】：

我认为您无法使用对称加密安全地做您想做的事。使用 asym，您可以发送公钥而无需过多担心（唯一的威胁是有人用自己的密钥替换您的密钥）并使用私钥验证您服务器上的加密唯一 ID。

【讨论】：

感谢您的快速回复。首先，非对称加密的解密时间要长 100-1000 倍，这样 CPU 就成为关键资源。所以我决定使用 sym 加密。其次，安全存储公钥的问题仍然存在，因为有人抓住了公钥，就可以以另一个人的身份发送数据。