我今天正在轮换我的 AWS X.509 证书和私钥（不要与 ssh 私钥/公钥对混淆），并决定在我的私钥上设置一个密码以更好地保护它。所以我做了一些研究并运行：
openssl rsa -in awsprivatekey.pem -des3 -out awsprivatekey.pem.new
并输入私钥的密码。在我尝试使用 ec2 api 工具后，我收到一个错误：
java.io.IOException: DER length more than 4 bytes
当我研究这个话题并发现这个链接时，这一点变得显而易见ec2 api 工具不支持带密码的私钥
我对这方面的信息缺乏以及像 Amazon EC2 这样重要的系统拥有不受保护的私钥的现状感到不安。
关于如何更好地保护我的私钥有什么建议吗？
答案1
我一直在做同样的尽职调查，我也担心所有的客户端工具和文档似乎都在推广糟糕的安全最佳实践。我对这个问题的回答是“你真的想为你输入的每一个命令重新输入密码吗？”——是的，或者至少我很高兴有像 ssh-agent 这样的工具帮我输入密码。我永远不想在我的文件系统上发现我的私钥或密码以纯文本的形式存在。我很惊讶，标准回答只是“加密你的整个文件系统”。
即使我挂载并加密一个 .ec2 目录并将所有内容都存放在其中，我仍然必须小心，不要遵循文档，文档建议在我的 bash_profile 脚本中将我的密钥设置为环境变量。所以也许我只是把它放在我的 .ec2 目录中的脚本中，并在命令行中传递它——哦，等等，现在我的密码在我的历史记录中（我仍然不敢相信 os x 竟然没有跳过存储我以空格为前缀的行）。所以为了安全起见，我真的需要加密我的整个用户目录。为什么使用 x.509 证书的非对称过程被弃用并被“密钥”身份验证过程取代呢？至少前者允许我将私钥存储在文件中——后者要求我将其作为参数传递（该参数的值遍布我的历史记录和脚本）。
问题是，虽然有这么多出色的安全协议，但没人愿意花时间去理解它们。相反，他们只想让事情正常运转——结果他们盲目地遵循一些分步文档，而这些文档是由盲目遵循他人分步文档的人编写的。没有人质疑这一切，因为他们不理解它，他们只想让它发挥作用。结果就是真正糟糕的安全实践泛滥成灾。
答案2
将它们保存在 TrueCrypt 加密磁盘上。当您不需要它们时，它们将被安全存储，并且只有在您真正需要使用它们时才可以挂载它。TrueCrypt 会创建一个文件，然后将其挂载为虚拟磁盘。
编辑： 如果你需要用非交互的代码来保护它，你显然可以加密私钥，然后用应用程序代码解密。有很多使用 Java 解密文件的示例。