PKI 中的信任锚证书

Question

我正试图弄清楚信任锚在 PKI 中是如何发挥作用的。我了解它是证书链的根，用于验证证书是否受信任。它如何验证证书？ （例如，它如何使用公钥和证书链来验证证书？）

Answer 1

证书将身份绑定到公钥。

假设您收到我的数字签名电子邮件。如果您使用您拥有的公钥验证签名，那么只要您相信人们将私钥保密，您就知道电子邮件来自拥有与该公钥对应的私钥的人。

如果您确定您拥有的公钥是我的（例如，因为我亲自将它交给了您），那么您只需要知道这些。问题是你并不总是知道这一点。任何人都可以创建一个密钥对并在整个互联网上发送假称我的公钥，或者设置一个假称是 StackOverflow 的 Web 服务器，或其他任何事情。您可以从独立来源找到 Google 的电话号码并打电话给他们以确认您拥有正确的密钥，但如果您每次想要建立安全的 TLS 连接时都必须这样做，那么电子商务将大大增加比现在效率低。

一种解决方案是获取证书。这包含由证书颁发机构数字签名的公钥和身份信息（例如姓名和地址、域名、电子邮件地址）。如果您使用证书颁发机构的公钥验证证书中的签名，那么您知道有权访问证书颁发机构私钥的人很乐意签署证书，声明他们同意该身份与该公钥​​一起使用。如果您相信证书颁发机构不会这样做，除非它采取了合理的步骤来验证这是真的（例如，通过确保他们看到个人的个人身份文件，并验证该个人是否拥有与公钥对应的私钥）将出现在证书中），那么您可以相信您拥有适合个人的正确密钥。

但即使您有这种信任，这也只是将问题推到了链条上一步，因为要使用证书颁发机构的公钥验证签名中的证书，您首先需要确保您拥有正确的公钥对于该证书颁发机构。因此，您可能会获得该证书颁发机构的证书，然后发现它是由不同的证书颁发机构颁发的，等等。

您显然无法验证无限的证书链，因此在某些时候这一切都必须停止。最终，您必须验证您是否拥有顶级证书颁发机构的正确公钥，而无需依赖其他证书，这就是您的信任锚。

假设您有一个证书给我，并且您看到它是由 ABC 证书颁发机构签署的，这是一个您从未听说过的证书颁发机构。您获得 ABC 的证书并使用其中的公钥验证我的证书上的签名，这向您证明 ABC 证书颁发机构确实签发了我的证书。

然后您查看 ABC 证书颁发机构的证书，您会看到它是由 DEF 证书颁发机构签名的，这是您信任的证书颁发机构，并且您已经拥有自签名证书或信任锚。您使用 DEF 证书中的公钥来验证 ABC 证书中的签名，这向您证明 DEF 确实为 ABC 颁发了该证书。

为确保我的证书有效，因此您需要做一些事情并做出一些假设：

1. 您需要获取并信任 DEF 证书颁发机构的（自签名）证书，这是您的信任锚。在大多数情况下，您的浏览器和/或操作系统会预先加载制造商决定信任的一堆 CA 证书，您只会盲目相信制造商对此的判断，但您可以采取自己的步骤如果您愿意，请验证您对自己的信任。

2. 您需要确信 DEF 是一个合法且值得信赖的证书颁发机构，它将保证其私钥的安全，并且不会向任何人颁发证书，除非它有充分的理由这样做。同样，您很可能会信任制造商，但大多数 CA 都会对其证书颁发过程和控制进行定期审核，因此如果您担心，您可以获取该特定 CA 的最后一次审核报告，例如.请注意，这样做需要您信任审计师的判断，因此无论您走哪条路，在某些时候您都必须信任某个人，因为他们值得信赖。

3. 您需要确信 DEF 不会向 ABC 证书颁发机构颁发中间 CA 证书，除非它有充分的理由相信 ABC 也是一个合法且值得信赖的证书颁发机构，它将保证其私钥的安全并且没有充分的理由不颁发证书。在这里，您不直接信任 ABC - 您信任它是因为 DEF 信任它，而且您信任 DEF。

如果信任锚和最终用户证书之间的链中存在多个中间 CA 证书，则同样的逻辑适用 - 您实际上信任链中的每个中间 CA，因为前面的 CA 在chain 不会向他们颁发他们的 CA 证书，除非它确信他们是一个值得信赖的 CA，并且除非它已经验证了中间 CA 证书中的公钥确实属于那个中间 CA。通过使用链中 CA 的公钥验证每个中间 CA 证书中的签名，您可以证明前面的 CA 确实颁发了该证书。由于您明确信任根 CA，那么如果发现您的信任锚位于该链的底部，那么您已经构建了一个隐式信任链，让您确信您最初感兴趣的最终用户证书是好的.

最终这一切都基于这样一种想法：您只需明确信任少数知名的根 CA，然后如果您能找到有效证书链，您就可以隐含信任互联网上数十亿个其他身份中的任何一个。回到您明确信任的根之一，并且您是否愿意接受该链中的每个中间 CA 在此基础上都是值得信赖的概念。

现实情况是，证书颁发机构通常对颁发中间 CA 证书非常谨慎，在向第三方机构颁发中间 CA 证书时往往会对其进行限制，以至于颁发给 ACME Inc 的中间 CA 证书可能仅用于为 ACME 颁发证书Inc 员工，或仅为以 .acme.com 结尾的域颁发证书。

Answer 2

信任关系、信任链和信任锚

信任锚与在安全交易期间如何建立信任有关，例如在访问安全网站时。当一个网站给你一个证书时，你怎么知道你可以信任这个证书？好吧，因为它由属于您作为证书颁发机构 (CA) 信任的实体的另一个证书签名。 （下面有更多关于签名和验证的信息。）但是你怎么能信任CA证书呢？因为它是由属于您信任的实体的另一个证书签名的。您可以重复询问有关此实体的相同问题并获得有关另一个签名者的相同答案的步骤，直到您获得未由另一个证书签名的证书。事实上，它是自签名证书。这称为根证书。那么，您如何知道信任此证书？答案是您只需这样做，通常是因为它在您安装它时与您的浏览器或其他软件捆绑在一起，或者您只是接受您信任此证书。这组证书与 CA 证书相关，由另一个证书签名，由另一个证书签名。 . .由根证书签名，称为您的信任链，根证书是信任锚，因为它的信任不是来自另一个证书；它只是被接受为受信任的，而所有其他证书直接或间接地从信任锚获得信任。

什么是数字签名，如何验证？

非对称密钥 -- 有一对与数字证书相关的数字加密密钥。这对由一个 public 和一个 private 密钥组成，它们之间具有特殊的关系。用公钥加密的东西只能用私钥解密，反之亦然。 “非对称”是指如果一个用于加密，另一个必须用于解密，而不是一个密钥用于加密和解密。顾名思义，私钥由颁发证书的实体保密，但公钥可供任何人使用，事实上，它包含在公开可用的证书中。非对称密钥对使数字签名和一般 PKI 成为可能。

哈希（摘要）-- 理解数字签名的另一个概念是散列或摘要。哈希函数将任意大小的数据作为其输入，并生成该数据的固定大小表示作为其输出。此输出称为数据的散列或摘要。一个复杂的散列算法，例如 MD5，产生一个具有以下属性的散列值：

• 给定相同的数据和相同的哈希函数，产品总是 每次都使用相同的哈希值。
• 两组不同的数据几乎不会产生相同的哈希值。事实上，即使数据有微小的变化，两个哈希值也会完全不同。
• 与本次讨论无关，但作为一般说明，原始数据不能从散列中导出。因此，哈希有时也称为单向加密。

创建和验证签名 -- 可以通过获取文档的哈希（例如证书然后使用签名者的私钥加密哈希）来创建签名。因此，签名只是加密的哈希。证书颁发机构 (CA) 使用 CA 证书的私钥为 PKI 证书创建数字签名。签名始终包含在 PKI 证书中。

要验证签名，验证实体（例如浏览器）会：

• 使用签名者的公钥对 PKI 证书上的签名进行解密，这将为您提供 PKI 证书的哈希
• 创建另一个证书哈希
• 比较未加密的签名和您刚刚为同一证书创建的哈希。 如果相同，则签名已经过验证。

因此，因为您可以使用签名者的公钥对签名进行解密，所以您知道它只能使用签名者的私钥加密，因此除非私钥被泄露，唯一的实体谁可以签署证书是签署证书所属的 CA。

并且因为您使用相同的哈希算法创建了自己的相同数据的哈希并且它与未加密的签名匹配，所以您知道签名是从您尝试验证的证书创建的并且它没有被篡改。

总之，您已经确定这是一个有效的证书，因为它是由您信任的实体签署的，因为该实体的证书是由您信任的实体签署的，依此类推，直到您到达信任锚点（根）您通过接受而信任的。

希望这能回答您的两个问题。