保护https密钥库时,Wildfly保险库(JCEKS)有什么意义?

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了保护https密钥库时,Wildfly保险库(JCEKS)有什么意义?相关的知识,希望对你有一定的参考价值。

我觉得我完全忽略了Wildfly中新的JCEKS密钥库格式。也许你可以让我直截了当。

我们配置Wildfly的方式(以及互联网的大部分指示我们,for example):

  • 我们将标准密钥库条目放在带有密码(“jks_pw”)的标准Java密钥库(“keystore.jks”)文件中
  • 然后,我们使用密码,salt和round-count(“jceks_s_n”)创建一个JCEKS密钥库(“keystore.jceks”)。
  • 然后我们将“pks_pw”放入“keystore.jceks”
  • 然后我们将JCEKS密码/ etc(“jceks_s_n”)作为纯文本添加到我们的jboss配置(standalone.xml)中,定义一个条目
  • 然后,我们将保管库存储的JKS密码的引用添加到我们的jboss https连接器(standalone.xml),作为“password =”$ {VAULT :: jks :: jks :: 1}“。

他们所做的一切完成了什么?

如果我们只使用嵌入在standalone.xml中的JKS文件和密码,系统很容易:

  • 攻击者获取standalone.xml和JKS文件的副本,在这种情况下,所有机密都是已知的。
  • 攻击者获取JKS文件的副本,在这种情况下,攻击者可以使用暴力攻击或查找表攻击。

如果我们按照描述的方式使用JCEKS容器,系统很容易:

  • (相同)攻击者获取standalone.xml的副本,即JKS / JCEKS文件,在这种情况下,所有机密都是已知的。
  • (相同)攻击者获取JKS文件的副本,在这种情况下,攻击者可以使用暴力攻击或查找表攻击。

如果我们将实际的证书放在JCEKS文件中,这将是有意义的,在这种情况下,暴力和查找表攻击在第二种攻击情况下会更难,但到目前为止我还没有找到使用方法直接使用https连接器的JCEKS格式的密钥库。

真的,我对此过分关注的唯一原因是我们显然有使用“保险库”的安全要求,但这似乎毫无意义。

更新:值得注意的是,通过使用保险库,您在jboss配置文件中使用了“屏蔽”密码到保险库,但我无法弄清楚这意味着什么。显然你的蒙面密码+盐+轮可以解锁JCEKS密钥库(source),所以我不确定完全屏蔽完成的是什么。它似乎是第三级重定向。我必须遗漏一些东西......

答案

JBoss声称“金库”背后的安全机制是默默无闻的安全(https://developer.jboss.org/wiki/JBossAS7SecuringPasswords

这有多安全?

  • Vault的默认实现使用Java KeyStore。它的配置使用基于密码的加密,这是默默无闻的安全性。这不是100%的安全性。它只是摆脱了配置文件中明文密码的问题。总是存在薄弱环节。 (正如mentallurg在评论中建议的那样,密钥库密码是最薄弱的环节)。
  • 理想情况下,第三方ISV强大的Vault实施应提供必要的安全性。

Vault使用未知密码,算法对密钥库密码执行对称加密。如果没有HSM,您将始终面临“存储例如数据源密码”的问题。因此,通常您使用Access-Control-List定义属性文件并在其中存储编码密码。

保险库只会增加获取安全密码的工作量,让攻击者可以读取内存中的pw或者对Vault加密算法+密钥进行反向工程。

另一答案

重要的是要知道“保险库”背后的安全机制是默默无闻的安全性,这意味着您只是屏蔽您的感知数据。这意味着如果攻击者可以访问您的standalone.xml和密钥库,他就可以轻松读取您的所有数据。保险库“增加了工作量” - >攻击者不能直接看到它们,而是通过一些(一点点)努力。

以上是关于保护https密钥库时,Wildfly保险库(JCEKS)有什么意义?的主要内容,如果未能解决你的问题,请参考以下文章

码头:初始化密钥库时出错

keytool 如何保护密钥?

将公共证书导入密钥库时出错

使用多个读卡器加载 PKCS 密钥库时出错

当我推送到 GitHub 时如何处理秘密 API 密钥,以便在克隆存储库时我的项目仍然有效?

从密钥保险库将证书上载到App Service