iOS App场景中的安全密钥，是否安全？

Question

我试图隐藏我在其中一个应用中使用的2个秘密。

据我所知，钥匙串是一个好地方，但在提交应用程序之前我无法添加它们。

我想到了这个场景 -

• 通过将应用程序的CoreData数据库中的秘密传播到其他实体中来隐藏它们。 （我在该应用程序中已经有种子数据库）。
• 当应用程序首次启动时，生成并将密钥移动到钥匙串。
• 从CoreData中删除记录。

这样安全还是黑客能够看到这种情况并获得这些密钥？

*第三次编辑** 很抱歉没有从头开始解释这个场景 - 该应用程序有许多级别，每个级别包含文件（音频，视频，图像）。用户可以购买一个级别（IAP），购买完成后我需要将文件下载到他的设备。

对于iOS6，文件与Apple新的“托管内容”功能一起存储。对于iOS5，文件存储在amazon S3中。

所以在这个过程中我有2个键： 1. IAP密钥，用于验证Apple IAP的购买。 2. S3键，用于从iOS5用户获取文件：

NSString *secretAccessKey = @"xxxxxxxxx";
NSString *accessKey = @"xxxxxxxxx";

我是否需要保护这些密钥？我担心人们无需购买级别就可以从S3获取文件。或者，黑客将能够构建一个黑客版本，其中包含预先下载的所有级别。

Answer 1

让我试着将你的问题分解为多个子问题/假设：

假设：

a）钥匙串是安全的地方

实际上，它并不安全。如果您的应用程序安装在jailbrok设备上，黑客将能够从钥匙串获取您的密钥

的问题：

a）有没有办法将一些密钥放入应用程序（从AppStore交付的二进制文件）并且完全安全？

简短的回答是否定的。只要二进制文件中有某些内容，它就可以进行逆向工程。

b）混淆会有帮助吗？

是。这将增加黑客解决问题的时间。如果您在应用程序中使用的密钥“花费”的时间少于花在逆向工程上的时间 - 一般来说，您就是好的。

然而，在大多数情况下，通过默默无闻的安全是不好的做法，它让你觉得你是安全的，但你不是。

因此，这可能是安全措施之一，但您也需要采取其他安全措施。

c）在这种情况下我该怎么办？*

如果不知道背景你想做什么，很难给你一个很好的解决方案。

例如，为什么每个人都应该访问相同的Amazon S3？他们需要只读还是写（正如Kendall Helmstetter Gein所指出的那样）。

我相信最安全的场景之一就是：

• 您的应用程序应受密码保护
• 首次进入应用程序时，它会要求用户对服务器进行身份验证（输入用户名，密码）
• 对您的服务器或其他身份验证提供程序（例如Google）进行身份验证
• 服务器向设备发送一些身份验证令牌（通常是某种类型的cookie）。
• 您根据应用程序密码的哈希对此令牌进行加密，并以此形式将其保存在钥匙串中
• 现在你可以做以下两件事之一：
  • 将特定密钥从服务器移交给客户端（因此每个客户端都有自己的密钥）并使用应用程序密码的哈希加密它们
  • 在服务器上处理S3的所有操作（并要求客户端发送）

这样可以防止多种可能的攻击。<​​/ p>

c）Whoooa ....我不打算实施你刚才写的所有这些东西，因为这需要几个月的时间。有什么更简单的吗？

如果每个客户端都有一组密钥，我认为这会很有用。

如果这个太多了，那么从服务器下载加密密钥并将其以加密形式保存在设备上，并将解密密钥硬编码到您的应用程序中。我会说它是微创的，至少你的二进制文件没有密钥。

P.S。肯德尔和罗布都是对的。

更新1（基于新信息）

首先，您看过in app purchase programming guide。

服务器产品型号下有很好的绘图。这个模型可以防止没有购买新关卡的人。您的应用程序中不会嵌入亚马逊密钥，服务器端将在收到购买收据时交出级别。

没有完美的解决方案可以防止购买内容的人（并决定将其从您的应用程序中删除），因为在几天结束时，您的应用程序会将内容下载到设备并在平原中需要它（未加密的形式）在某个时间点。

在这种情况下，如果您真的关心这种情况，我建议您加密所有资产，并将其与加密密钥一起从服务器以加密形式移交给它。应该为每个客户端生成加密密钥，并且应该使用它来加密资产。

这不会阻止任何高级黑客，但至少它会保护使用iExplorer并只复制文件的人（因为它们会被加密）。

更新2

关于更新的另一件事1.你应该存储未加密的文件并在某处存储加密密钥（例如在钥匙串中）。

在这种情况下，如果您的游戏需要互联网连接，最好不要在设备上存储加密密钥。每次启动应用程序时，您都可以从服务器获取它。

Answer 2

请勿在您的应用中存储用于写入的S3密钥！在短时间内，某人嗅探流量会看到对S3的写入调用，他们会以较短的顺序找到该密钥并做任何他们喜欢的事情。

应用程序可以通过您控制的服务器以任何安全级别向S3写入内容的唯一方式。

如果它是用于只读使用的密钥，意味着您的S3无法公开读取，但密钥可用于无法写入的只读访问，那么您可以将其嵌入应用程序但任何​​人都想要可以把它拉出来。

要轻易隐藏预先加载的敏感数据，您可以在文件中对其进行加密，然后应用程序可以将其读入内存并在存储到钥匙串之前进行解密。再一次，有人能够获得这些密钥，所以如果可以的话，最好不要太多。

编辑：

根据新信息，您可能最好只在代码中嵌入秘密。使用像iExplorer这样的工具，因果用户可以轻松访问核心数据数据库或应用程序包中的任何其他内容，但目标文件有些加密。如果他们有一个越狱设备，他们可以轻松获得未加密的版本，但仍然很难找到有意义的字符串，可能将它们分成两部分并在代码中重新组合。

同样，它不会阻止一个坚定的黑客，但它足以让大多数人离开。

您可能还想添加一些代码，这些代码会尝试询问您的服务器是否有可下载的覆盖密码。这样，如果秘密被泄露，您可以通过更改用于您的应用程序的秘密来快速做出反应，同时使用复制的秘密关闭任何人。首先，没有覆盖下载。您不希望必须等待应用程序更新才能使用新密钥。

Answer 3

没有好方法可以隐藏您发送攻击者的一段代码中的秘密。与此类型的大多数事情一样，您需要更多地关注如何在密钥泄漏时缓解问题，而不是花费无限时间来保护密钥。例如，为每个用户生成不同的密钥允许您在滥用密钥时禁用密钥。或者通过中间服务器允许您控制协议（即服务器具有密钥，并且只愿意使用它执行某些操作）。

做一点混淆不是浪费时间。没关系。但是不要花很多时间在上面。如果它在程序中并且它非常有价值，那么它将被黑客攻击。重点关注如何检测何时发生，以及如何恢复。并尽可能将这种敏感数据移动到您控制的其他服务器中。