security - 证书和哈希检查？

Question

我问这个问题是为了 100% 确定。

link

To validate the certificate to ensure it contains the information digitally signed by the certificate authority, the web browser verifies the digital signature. Because the digital signature is an encrypted hash value that was computed based on the contents of the certificate, the web browser needs to compare hash values. The web browser computes a hash value based on the contents of the certificate it received. It then decrypts the digital signature to determine the hash value that the certificate authority computed. If the two hash values match, the web browser is assured that the certificate contains the information that the certificate authority verified and digitally signed.

问题:

The web browser computes a hash value based on the contents of the certificate it received

浏览器知道证书在内部使用了哪种摘要算法，因此他还使用它来计算散列 - 基于证书内容。

It then decrypts the digital signature to determine the hash value that the certificate authority computed

浏览器知道哪个 CA 创建了证书，因此他从适当的计算机存储位置获取公钥并将其应用于加密的哈希值。结果是解密的哈希值。

然后查看两者是否相同。

我说得对吗？

Answer 1

(您可能对 Security.SE 上的 this question 感兴趣。)

这是 structure of an X.509 certificate :

Certificate  ::=  SEQUENCE  {
     tbsCertificate       TBSCertificate,
     signatureAlgorithm   AlgorithmIdentifier,
     signatureValue       BIT STRING  }

TBSCertificate  ::=  SEQUENCE  {
     version         [0]  EXPLICIT Version DEFAULT v1,
     serialNumber         CertificateSerialNumber,
     signature            AlgorithmIdentifier,
     issuer               Name,
     validity             Validity,
     subject              Name,
     subjectPublicKeyInfo SubjectPublicKeyInfo,
     issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                          -- If present, version MUST be v2 or v3
     subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                          -- If present, version MUST be v2 or v3
     extensions      [3]  EXPLICIT Extensions OPTIONAL
                          -- If present, version MUST be v3
     }

当收到证书时，浏览器会从证书本身获取签名算法。通常，这类似于 RSAwithSHA1。

在这种情况下，它确实可以重新计算TBSCertificate(证书的实际内容)的SHA-1摘要。

此外，从 TBSCertificate 中，它可以找到颁发者名称:这是用来从已知的 CA 证书中找到信任 anchor 的(颁发者名称必须与 CA 证书的主题相匹配) ).当它在它已经信任的列表中找到具有正确名称的 CA 证书时，它可以从该 CA 证书中获取公共(public) RSA key 。

同时拥有 SHA-1 摘要和 RSA 公钥，它可以验证 signatureValue 是否匹配。

the digital signature is an encrypted hash value

尽管人们普遍这么说，但这并不完全正确。数字签名是数字签名，不是加密。

问题在于 RSA 使用相同的算法来加密和签名:使用公钥加密，使用私钥签名。通常，一个与另一个混淆(即使在 OpenSSL API 中)。用私钥“加密”是没有意义的，因为“加密”意味着隐藏(如果你放弃公钥，你就不会隐藏任何东西，这样它就可以“解密”签名)。

这种关于数字签名的哈希和加密的微妙之处不适用于其他一些算法，例如仅用于签名的 DSA。

这就是为什么许多数字签名 API 将散列和 key 用法组合到单个“签名”或“验证”操作中的原因。这就是 Java Signature API 确实如此，例如:你告诉它使用 RSAwithSHA1 或 DSAwithSHA1，给它 key 和消息，并告诉它签名或验证，你没有手动进行摘要或“加密”。

为了证书验证的目的:浏览器从证书中获取颁发者并找到对应的公钥(来自受信任的CA证书)，它还从证书中获取签名算法，然后用该公钥验证签名和 TBSCertificate 内容，根据签名算法的规定。