Java/C ++加密和JNI接口 [英] Java / C++ Encryption and the JNI interface

问题描述

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

We are developing an application that uses a Java frontend and implements more complex mathematical algorithms C++ side. For this purpose there are Java native functions implemented via JNI, to access C++ functionality via Java.

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

Historically we had the problem of more and more credentials flying around the relatively large codebase, almost all of it Java side, some configurable credentials in application specific configuration files, the latter can be ignored w.r.t. the scope of this question.

我们想提高应用程序的安全性.我们面临的问题是我们的应用程序必须能够脱机运行，因此，无论我们用来解密数据的私钥如何，它都将随应用程序一起提供.我们正在考虑我们的选择，但是似乎没有一个最安全:

We would like to increase application security. The problem we are facing is that our application must be able to run offline, therefore whatever private key we use to decrypt our data, it will be delivered with the application. We are considering our options, but none of them seem the least bit secure:

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

• Keep passwords Java side and use crypto package - still, the encryption algorithm can be identified and the password to encrypt with must still be stored openly somewhere, so this can be decrypted relatively easily. In addition JARs are relatively well accessible.
• Keep passwords C++ side and use a function decryptKey by passing it a password, decrypting it C++ side with a private key, then returning it plain. In this case JNI becomes the vulnerability, because it is easily conceivable to just build your own JAR, include our DLL and then access the native decryptKey function to retrieve plain-text passwords.
• Shift all key dependent logic to C++. This makes little sense, because we would have to shift logic where it does not belong. In addition some implementations require 3rd party Java APIs that need to be fed credentials, so this is sadly not an option.

大概这不是行业中常见的问题，那么处理此问题的最明智的方法是什么?目前，这些方法仅引入通过隐蔽性实现安全性，其有效性充其量是有争议的，而最糟糕的是几乎不超过零.在行业中有标准的处理程序吗?

Presumably this is not an uncommon problem in the industry, so what is the most sensible way to handle this? Currently these approaches only introduce security through obscurity, the effectiveness of which is at best debatable and at worst barely above zero. Are there standard procedures how this is handled in the industry?

推荐答案

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

First, your product needs to be able to integrate with products that can keep your private keys safe. These products include TPM, HSM and KMS. This will prove extermely usefult for local and cloud based prduction environments.

第二，您应该实现信封加密机制，其中的数据加密密钥使用主密钥进行加密，该主密钥将存储在TPM/HSM/KMS中.加密的数据加密密钥可以与数据一起存储.

Secondly, you should implement an envelope encryption mechanism, where the data encryption key is encrypted with a master key that will be stored in the TPM/HSM/KMS. The encrypted data encryption key can be stored with the data.

第三，您应该实施密钥旋转，在其中替换主密钥/data密钥每隔一段时间.

Thirdly, you should implement key rotation, where you replace your master/data keys every once in a while.

第四，最后，您应该咨询信息安全性，而不是关于将来的强化问题的Stackoverflow.

Fourthly and finally, you should consult Information Security instead of Stackoverflow with future hardening questions.

这篇关于Java/C ++加密和JNI接口的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！