如果您希望让运行您的程序的人不掌握私钥，那么它就行不通。嵌入在代码中的秘密不抵抗逆向工程（尤其是在使用 Java 时，这很容易进行逆向工程）。

尽管您没有详细说明您的情况（您只说“Java”和“程序”），但我可以给出以下一般性建议：将您的私钥安排为用户特定的，并且它是用户的私钥保持私密的最佳利益。在这种情况下，用户将协作到密钥安全性。然后，您可以将私钥（或解锁私钥的密码）存储在Java 首选项中。

这是一个非常好的问题，我希望看到更多好的答案。以下是我所知道的：

1. 在应用程序中对密码进行硬编码。
2. 将密码保存在文件中。
3. 将密码存储在外部系统中并在启动时检索它。

其中第一个是最常见的，通常密码是“password”或“changeit”等。第二个选项乍一看可能更好，但很难解释到底如何。最后一个选项可能是唯一有希望做任何有意义的事情的选项。我知道做这种事情并声称提高安全性的供应商解决方案。

这里的根本问题是，如果攻击者在主机上具有足够的访问权限来查看应用程序空间，那么您实际上无法阻止他们获取此密码。在某些时候，它必须清晰地存在于内存中。

正如我所看到的，密钥库上的密码主要在密钥库本身已从机器检索到而实际上没有直接访问该机器的情况下对其进行保护。使用该文件，攻击者可以随意敲击它以从中获取秘密。如果您没有强密码，游戏结束。如果攻击者可以提取该文件，那么他们很可能可以提取可以存储密码的其他文件。这使选项 1 和 2 受到质疑。

就第三个选项而言，问题现在转移到您如何验证客户端以检索密码。我知道有很多方案可以做到这一点，例如取决于主机/网络和在二进制文件上使用签名。您可以就如何执行此操作以及它带来的保护级别进行完整的讨论。

我正在完成一个运行 Grizzly Web/REST 服务器的 Java 应用程序。整个应用程序将部署为人们可以在 Microsoft Azure 云中购买的 VM 映像产品。

在我的情况下，我希望客户能够在他们选择的域名上运行我的产品的 Web 服务器。这要求客户完成获取域名和相关密钥的过程。这些密钥将安装到位于运行 Web 服务器的 VM 上的密钥/信任库中。我的应用程序允许用户以三种不同的方式提供密钥库和信任库文件路径和密码：

1. 在命令行上清除使用一组命令行参数，
2. 通过提供对包含密钥/信任存储路径和密码详细信息的属性文件的命令行引用，以及
3. 使用由命令行应用程序触发的 Java Swing 弹出对话框来收集密钥/信任存储路径和密码。

如果用户对没有人会通过命令窗口向后滚动感到满意，他们可以使用选项#1。

如果用户愿意将这些详细信息放在服务器上的属性文件中，他们可以使用选项 #2。

使用选项三可确保密码永远不会存储在磁盘上，并且无法从命令窗口中恢复。但是，这也意味着用户必须在场才能重新启动服务器。