保护胖客户端应用程序中的API密钥

Question

在应用程序中，我使用Secret Keys来计算API调用的哈希值。在.NET应用程序中，使用像Reflector这样的程序来从程序集中提取信息以包含这些键是相当容易的。

将程序集混淆是保护这些密钥的好方法吗？

Answer 1

可能不是。

查看加密和Windows的内置信息隐藏机制（例如，DPAPI并将密钥存储在ACL限制的注册表项中）。这就像你要获得安全性一样好，你需要与你的应用程序保持同一系统。

如果您正在寻找一种方法来阻止身体坐在机器上的人获取您的信息，请忘掉它。如果有人确定，并且无限制地访问不受您控制的计算机，则无法100％确定数据在任何情况下都受到保护。如果他们愿意，那些有决心的人会得到它。

Answer 2

我不这么认为，因为混淆（至少我理解）会简单地搞乱方法名称，以使理解代码变得困难（但并非不可能）。这不会改变实际密钥的数据（我猜你已经存储在一个常量的某个地方）。

如果你只是想让它更难看，你可以在明文上运行一个简单的密码（比如ROT-13或其他东西），这样它至少不会在代码本身中以明文形式存储。但这肯定不会阻止任何坚定的黑客访问你的密钥。更强大的加密方法无济于事，因为您仍然需要在代码中存储THAT密钥，并且没有任何保护措施。

我能想到的唯一真正安全的事情就是将密钥以某种方式保留在应用程序之外，然后限制对密钥的访问。例如，您可以将密钥保存在单独的文件中，然后使用基于操作系统级别的基于用户的限制来保护该文件;这可能会奏效。您可以对数据库连接执行相同的操作（同样，依靠基于用户的访问限制将非授权用户保留在数据库之外）。

我已经玩弄了为我的应用做这个的想法，但我从来没有实现它。

Answer 3

DannySmurf是正确的，你无法隐藏运行应用程序的人的密钥;如果应用程序可以访问密钥，那么这个人也可以。

但是，你想要完成的是什么？

根据具体情况，通常有一些方法可以实现您的目标，而不仅仅是依靠在用户机器上保密“秘密”。

Answer 4

这里比赛的后期......

将密钥存储在汇编/汇编配置中的方法基本上是不安全的。由于确定的用户可以访问，因此没有可能存储它的铁定方法。如果您使用地球上最好/最昂贵的混淆产品，我不在乎。如果您使用PDAPI来保护数据，我并不在意（尽管这样做更好）。如果您使用本地受操作系统保护的密钥存储区，我不在乎（这甚至更好）。没有一个是理想的，因为所有人都遇到相同的核心问题：用户可以访问密钥，他们在那里，几天，几周甚至几个月甚至几年不变。

更安全的方法是使用久经考验的PKI保护您的API调用。但是，如果您的API调用很繁琐，这会产生明显的性能开销，但对于绝大多数应用程序而言，这不是问题。

如果需要考虑性能，可以使用Diffie-Hellman而不是非对称PKI来建立共享密钥对称密钥，以便与AES等密码一起使用。 ＆＃34;共享＆＃34;在这种情况下意味着客户端和服务器之间共享，而不是所有客户端/用户密钥中没有硬编码/烘焙。任何地方。

每次用户运行程序时，键都是暂时的，重新生成，或者如果你真的是偏执狂，它们可能会超时并需要重新创建。

计算出的共享密钥对称密钥本身仅存储在SecureString中的内存中。它们很难提取，即使你这样做，它们只能在很短的时间内完成，并且仅用于特定客户端之间的通信（即该会话）。换句话说，即使有人破解了他们的本地密钥，它们也只能干扰本地通信。他们不能使用这些知识来影响其他用户，这与所有用户通过代码/配置共享的烘焙密钥不同。

此外，整个密钥本身永远不会通过网络传递。客户端Alice和服务器Bob独立地计算它们。为了做到这一点，他们传递的信息理论上可以被第三方查理截获，允许他独立计算共享密钥。这就是为什么你使用那个（显着更多costLy）非对称PKI来保护Alice和Bob之间密钥生成的原因。

在这些系统中，密钥生成通常与身份验证相关联，因此会话创建。你＆＃34;登录＆＃34;并创建你的＆＃34;会话＆＃34;在PKI之后，在完成之后，客户端和服务器都独立地具有对称密钥，该密钥可用于对该会话中的所有后续通信进行数量级更快的加密。对于高规模服务器，这对于解密而不是使用TLS来节省解密计算周期非常重要。

但等等：我们还不安全。我们只是阻止阅读邮件。

请注意，仍然需要使用消息摘要机制来防止中间操作。虽然没有人能够读取正在传输的数据，但没有MD就没有什么能阻止他们修改它。因此，您在加密前对消息进行散列，然后将散列与消息一起发送。然后，服务器在解密时重新散列有效负载，并验证它是否与作为消息一部分的散列相匹配。如果邮件在传输过程中被修改，则他们不会被删除/忽略整个邮件。

需要防范的最终机制是重播攻击。此时，您已阻止人们阅读您的数据以及修改您的数据，但您无法阻止他们再次发送数据。如果这是您的应用程序的问题，它的协议必须提供数据，并且客户端和服务器必须具有足够的有状态信息来检测重放。这可能是一个简单的计数器，它是加密有效载荷的一部分。请注意，如果您使用的是UDP等传输，则可能已经有了处理重复数据包的机制，因此可以处理重放攻击。

显而易见的是，要做到这一点并不容易。因此，除非你绝对不能使用PKI。

请注意，这种方法在游戏行业中得到了大量使用，因此非常希望在每个播放器上花费尽可能少的计算来实现更高的可扩展性，同时提供来自黑客/窥探眼睛的安全性。

总而言之，如果这确实是一个问题，而不是试图找到一个安全存储API密钥，不要。相反，请更改您的应用使用此API的方式（假设您可以自然控制双方）。如果PKI太慢（这几天很可能是一个问题），请使用PKI，或使用PKI共享的对称混合。然后你就不会存储任何安全问题。