Java / C++ 加密和 JNI 接口答案

【问题标题】：Java / C++ Encryption and the JNI interfaceJava / C++ 加密和 JNI 接口
【发布时间】：2020-03-01 15:21:20
【问题描述】：

我们正在开发一个使用 Java 前端并在 C++ 端实现更复杂数学算法的应用程序。为此，有通过 JNI 实现的 Java native 函数，以通过 Java 访问 C++ 功能。

从历史上看，我们遇到了越来越多的凭证在相对较大的代码库中飞来飞去的问题，几乎都是 Java 端，一些可配置的凭证在应用程序特定的配置文件中，后者可以忽略 wrt这个问题的范围。

我们希望提高应用程序的安全性。我们面临的问题是我们的应用程序必须能够离线运行，因此无论我们使用什么私钥来解密我们的数据，它将与应用程序一起交付。我们正在考虑我们的选择，但它们似乎都不安全：

保留密码 Java 端并使用crypto 包 - 仍然可以识别加密算法，并且要加密的密码仍然必须公开存储在某个地方，因此可以相对容易地解密。此外，JAR 相对容易访问。
保留密码 C++ 端并使用函数decryptKey 传递密码，使用私钥对其进行 C++ 端解密，然后将其返回原样。在这种情况下，JNI 就成为了漏洞，因为很容易构建自己的 JAR，包含我们的 DLL，然后访问本机的 decryptKey 函数来检索纯文本密码。
将所有与键相关的逻辑转移到 C++。这没有什么意义，因为我们必须将逻辑转移到不属于它的地方。此外，一些实现需要需要提供凭据的第 3 方 Java API，因此遗憾的是，这不是一个选项。

想必这在业内并不少见，那么最明智的处理方法是什么？目前这些方法只引入了通过默默无闻的安全性，其有效性充其量是值得商榷的，最坏的情况是勉强高于零。行业内是否有标准程序如何处理？

【问题讨论】：

【解决方案1】：

首先，您的产品需要能够与可以保护您的私钥安全的产品集成。这些产品包括TPM, HSM and KMS。这将证明对本地和基于云的生产环境非常有用。

其次，您应该实现envelope encryption 机制，其中数据加密密钥使用将存储在 TPM/HSM/KMS 中的主密钥进行加密。加密后的数据加密密钥可以与数据一起存储。

第三，您应该实施key rotation，您可以在其中每隔一段时间更换一次主/数据键。

第四点也是最后一点，您应该咨询Information Security，而不是 Stackoverflow，了解未来的强化问题。

【讨论】：

感谢您的回复。我一直想知道的一件事是 - 即使密钥是安全存储的，因为它们是在 Java 端检索的，它们仍然可以轻松读取。除非我遗漏了什么，否则建议的内容并不能防止这种情况，除了可能引入密钥轮换/挑战-响应。
这些是不同的问题。 TPM/KMS/HSM 用于解决“静态加密”问题，如果有人窃取了带有数据的磁盘驱动器，它将无法使用。通过强化进程、操作系统和使用代码分析工具检测可能的安全漏洞（如 SQL 注入、跨站点脚本、缓冲区溢出等）来解决“实时”黑客攻击等其他问题。