Wildfly 保险库 (JCEKS) 在保护 https 密钥库时有何意义？

Question

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

我们配置 Wildfly 的方式（以及大部分互联网指示我们，例如）：

• 我们将标准密钥库条目放入标准 Java 密钥库（“keystore.jks”）文件中，并带有密码（“jks_pw”）
• 然后，我们使用密码、salt 和轮次计数（“jceks_s_n”）创建一个 JCEKS 密钥库（“keystore.jceks”）。
• 然后我们将“pks_pw”放入“keystore.jceks”
• 然后我们将 JCEKS 密码/等（“jceks_s_n”）作为纯文本添加到我们的 jboss 配置（standalone.xml）中，定义一个条目
• 然后，我们向 jboss https 连接器 (standalone.xml) 添加对保管库存储的 JKS 密码的引用，如“password="${VAULT::jks::jks::1}”。

这一切到底完成了什么？？？

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

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

如果我们以描述的方式使用 JCEKS 容器，系统很容易受到：

• （相同）攻击者获得了 standalone.xml 的副本，即 JKS/JCEKS 文件，在这种情况下，所有秘密都是已知的。
• （相同）攻击者获得 JKS 文件的副本，在这种情况下，攻击者可以使用暴力破解或查找表攻击。

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

真的，我太在意这个的唯一原因是我们显然有使用“保险库”的安全要求，但这似乎毫无意义。

更新：值得注意的是，通过使用保管库，您在 jboss 配置文件中使用了保管库的“隐藏”密码，但我无法弄清楚这意味着什么。显然，您的掩码密码 + salt + rounds 可以解锁 JCEKS 密钥库（source），所以我不确定掩码到底能完成什么。这似乎是第三级重定向。我必须错过一些东西......

Answer 1

JBoss 指出“Vault”背后的安全机制是隐匿性安全（https://developer.jboss.org/wiki/JBossAS7SecuringPasswords）

这有多安全？

• Vault 的默认实现使用 Java KeyStore。它的配置使用基于密码的加密，这是一种隐蔽的安全性。这并不是 100% 安全。它只能解决配置文件中明文密码的问题。总有一个薄弱环节。（正如 mentallurg 在评论中建议的那样，密钥库密码是最薄弱的环节）。
• 理想情况下，第三方 ISV 稳健的 Vault 实施应提供必要的安全性。

Vault 使用未知密码和算法对密钥库密码执行对称加密。如果没有 HSM，您将始终面临“在哪里存储例如数据源密码”的问题。因此，通常您会定义一个带有访问控制列表的属性文件，并将编码后的密码存储在其中。

金库只是增加了获取安全密码的工作量，让攻击者可以读取内存中的密码或对金库加密算法+密钥进行逆向工程。