CA与区块链之数字签名详解-Toy模板网

这篇具有很好参考价值的文章主要介绍了CA与区块链之数字签名详解。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

CA与区块链验证本质上都是数字签名，首先，我们看一下什么是数字签名！

数字签名

数字签名是公钥密码学中的一种技术，用于验证信息的完整性和发送者的身份。简而言之，数字签名是一种确认信息来源和信息完整性的手段。它通常与区块链、数字证书、加密邮件等技术结合使用。

基本工作原理

核心要点：信息完整性与身份认证！数字签名的基本工作原理如下：

消息摘要：首先，使用某种哈希函数（如SHA-256）计算原始消息（或文档）的摘要（digest）。

摘要是消息的哈希值，是通过某种哈希函数（如SHA-256）从原始消息中产生的。哈希函数的特点是，哪怕只有一点点的输入变化，输出的哈希值也会发生巨大的变化。因此，哈希值可以作为消息的“指纹”。

加密摘要：然后，使用发送者的私钥加密上一步得到的摘要。这就得到了数字签名。

发送消息及签名：发送者将原始消息和数字签名一起发送给接收者。

验证签名：

接收者使用发送者的公钥解密数字签名，得到摘要A。

接收者使用相同的哈希函数计算收到的原始消息的摘要，得到摘要B。

比较摘要A和摘要B。如果它们匹配，这意味着消息没有被篡改。

为什么接收者能够知道发送者用的哈希函数呢？

标准化协议：在许多安全协议中，哈希函数（如SHA-256、SHA-3等）已经被明确规定。因此，当双方遵循同一协议时，他们都知道应使用哪个哈希函数。

数字证书：在使用数字证书的场景中（如TLS/SSL），证书中通常会包含用于签名的哈希函数的信息。当接收者收到证书时，它就可以知道应使用哪个哈希函数来验证签名。

明确声明：在某些情况下，发送者可以在消息的某个部分明确指定使用的哈希函数。这样，接收者在收到消息时就知道如何进行验证。

总之，为了数字签名的有效性和安全性，双方必须有一个共同的、已知的方式来确定使用哪个哈希函数。在大多数现实世界的应用中，这一点已经得到了很好的处理和规定。

数字签名的关键作用

身份验证：数字签名确保了交易的发送者是交易所声称的发送者。

不可否认性：一旦发送者签署了交易，他们不能否认进行了该交易。

完整性：任何对已签名的交易的修改都会导致签名无效，这确保了交易的完整性。

为什么数字签名是安全的？它的安全性来自于私钥的秘密性和公钥密码学的数学属性。私钥是只有发送者知道的，而公钥是可以公开分享的。没有私钥，就不能生成一个与给定公钥匹配的有效签名，这确保了只有私钥的持有者才能创建有效的签名。

中间人攻击

关于中间人攻击：

中间人攻击者确实可以使用发送者的公钥来解密数字签名得到摘要A。但是，攻击者不能使用公钥来创建一个新的有效签名，因为创建数字签名需要发送者的私钥，这是攻击者不知道的。

如果攻击者修改了消息，那么摘要（哈希值）自然会发生变化。这意味着，即使攻击者能够生成新的摘要，他们还需要使用发送者的私钥加密新摘要以产生一个新的数字签名。由于攻击者没有私钥，他们无法这样做。

因此，接收者在验证过程中会发现摘要A（从数字签名解密得到）与摘要B（从修改后的消息计算得到）不匹配，从而知道消息已被篡改。

即：任何人都可以得到摘要A和摘要B，但是如果没有发送者的私钥，就无法生成正确的数字签名（中间人用自己的私钥生成数字签名有个卵用，接收者又不用中间人的公钥验证）。所以，中间人只能修改信息，但是不能修改数字签名。

转眼中间人又把没法修改的数字签名（没有私钥，中间人是无法完美修改的）和修改后的信息给到了接收方，接收方首先通过发送者的公钥解密数字签名得到摘要A，又使用哈希函数包装中间人修改后的信息，得到摘要B'。

因为哈希函数即使只有一点点的输入变化，输出的哈希值也会发生巨大的变化，所以摘要B'和原本正确的、应该和摘要A的值相等的摘要B差别巨大，而接收方就是看摘要AB是否相同，现在变成了验证摘要AB'是否相同，很明显已经不同了，所以接收方能快速明白：

1. 经过数字签名的验证得到摘要A，该信息能够通过A的公钥解密，生成合理的有意义的摘要。说明该信息确实是来自于发送方，验证了发送方的身份。

2. 两种过程产生的摘要信息不同，说明发送过来的原始数据已经不完整不正确了，有可能受到中间人的干扰。

据此，我们说到数字签名和消息的验证，有两个主要的步骤：

验证发送者的身份：这是通过数字签名完成的。只有发送者的私钥能产生一个可以由其公钥解密的数字签名。如果攻击者没有私钥，他们无法为任何消息生成有效的签名。所以，当接收者使用公钥成功解密了数字签名并得到了摘要A，这验证了消息是从拥有私钥的发送者处发出的。
验证消息的完整性：这是通过比较两个摘要来完成的。
- 摘要A是从数字签名解密得到的，它是基于发送者发送的原始消息生成的。
- 摘要B是接收者从他们收到的消息计算其哈希得到的。

如果攻击者修改了消息，他们可以很容易地为这个修改后的消息计算出新的摘要B'（使用哈希函数就可以，发送者也是通过哈希函数生成摘要的，只不过数字签名是进一步使用私钥加密）。但问题是，这个摘要B'不会与摘要A匹配（除非攻击者同时拥有发送者的私钥，并且为修改后的消息创建了新的数字签名，这在实际应用中是极不可能的情况）。因此，接收者仍然可以检测到消息被篡改的事实。

只要有发送者的私钥，中间人就可以篡改信息？

理论上，如果攻击者获得了发送者的私钥，那么他们可以对任何消息进行签名，从而伪装成该发送者。这意味着攻击者可以：

生成一个篡改后的消息。

使用发送者的私钥为这个篡改后的消息创建一个数字签名。

将篡改后的消息和新的数字签名发送给接收者。

在这种情况下，当接收者进行验证时：

使用发送者的公钥，接收者可以解密数字签名并获得摘要。

接收者还会对篡改后的消息生成一个摘要。

由于这两个摘要是匹配的，接收者可能会认为这个篡改后的消息确实来自原始发送者。

因此，确实，如果攻击者获得了私钥，他们可以篡改消息并伪造有效的数字签名，从而欺骗接收者。

这就是为什么私钥的安全性非常关键，为什么它必须被严格保护。在实际应用中，私钥往往被存储在安全的环境中，如硬件安全模块（HSM），或使用其他加密手段进行保护，以防止未经授权的访问。

如果私钥被认为是丢失或被盗，应立即撤销相应的公钥证书，并生成一个新的公私钥对。这确保即使私钥落入错误的手中，它也不能被用于伪造签名。

作者思考

作者学到这里的时候，其实认为不需要比较摘要。原因是：如果中间人有私钥，那么数字签名被篡改，摘要AB都可以被轻松修改成新的值，并且相等，比较摘要也比较不出来；如果中间人没有私钥，他就不能生成一个合法的签名，解密后的结果也将是无意义的，也不用通过比较摘要得出结论。

是不是看上去很有道理？！其实作者并没有理清第二种情况，上面的想法是错误的！！

作者搞错了 “中间人没有私钥” 的情况，实际上，没有私钥，中间人未必不能生成正确的签名，他可以完全不修改签名啊！请读者明确一点：发送者传递的是原始信息和数字签名，如果对于数字签名，中间人一点都不改，但他修改了原始信息，这时，倘若没有摘要比较，那么接收者的行为会是什么样呢？下面我们综合比较讲解一下：

中间人没有私钥，但尝试篡改消息：
- 传递虚假消息与正确的签名：这种情况下，虽然签名是对原始消息的正确签名，但由于消息已被篡改，所以当接收者对篡改后的消息计算哈希得到新的摘要，并与签名解密得到的摘要进行比较时，会发现它们不匹配。因此，接收者可以确定消息已被篡改。如果不比较摘要，接收者可能会认为这是一个有效的、未被篡改的消息，这是不安全的。
  - 如果只依赖数字签名的解密，那么在这种情况下，接收者可能会误以为消息是有效的。因为实际上传递的签名中不包含所有的信息，只有摘要。签名正确，不意味着你额外传递的原始信息正确，除非将原始信息叶转换成摘要，和签名转换的摘要对比，才能验证原始信息正确，所以这种情况下摘要比较是必要的。
- 传递虚假消息与错误的签名：这种情况下，由于签名是错误的，当接收者尝试用公钥解密它时，解密后的结果将不是有效的摘要格式。即使解密操作可以完成，得到的结果与任何有效的摘要都不会匹配。此外，当接收者对篡改后的消息计算哈希得到新的摘要，并与签名解密得到的摘要进行比较时，会发现它们不匹配。因此，接收者会知道消息已被篡改。
  - 当接收者使用公钥对错误的签名进行解密时，得到的结果确实不会是一个有效的摘要，这时就已经能够确定消息或签名被篡改了。因此，确实没有必要再进行摘要比较。
中间人有私钥：这是一种非常罕见的情况，因为私钥应当被妥善保管，不应落入他人之手。但如果这确实发生了，那么中间人确实可以伪造任何消息，并为其创建有效的签名。这种情况下，数字签名和摘要验证的确都会失效。这也是为什么私钥的安全性是如此重要的原因。
“消息正确、签名错误”的情况通常不会发生。

比较摘要的意义（了解）

系统的健壮性：摘要比较提供了一个另外的安全层。这在系统设计中是一个常见的原则，即不完全依赖一个安全机制（数字签名），而是使用多重机制。这可以抵御未知的攻击和缺陷。

误操作或传输错误：在数字签名有效的情况下，消息在传输过程中可能会受到损坏，如因网络问题、存储问题等。通过比较摘要，可以验证消息的完整性。

旧的或延迟的消息：攻击者可能会重放旧的消息。虽然这些消息的数字签名是有效的，但它们可能不再是最新或者相关的。通过比较摘要，可以检查消息是否是最新的。

确认发送者的真实意图：比如，攻击者可能会截获一个有效的、签名过的消息，然后将它发送给另一个不相关的接收者。尽管数字签名是有效的，但消息可能不是发送者打算发送给这个特定接收者的。通过比较摘要，可以确保消息是发送者打算发送的。

未来证明：摘要比较也为未来可能出现的新的攻击或漏洞提供了保护。尽管现有的签名算法可能是安全的，但未来可能会发现它的弱点。摘要的存在和验证提供了一个额外的安全层，使得对消息的完整性和来源的验证更加严格。

现在我们对误操作或传输错误进行学习：

误操作或传输错误

发送过程：

Alice想向Bob发送一个简单的消息："Hello"。

Alice首先对这个消息进行哈希，得到一个摘要，例如（为了简化，假设摘要只是消息的第一个字母）：摘要 = "H"。

Alice使用她的私钥对摘要进行加密，得到数字签名。

然后，Alice将消息："Hello" 和数字签名一起发送给Bob。

传输过程中的错误：

在传输过程中，由于网络故障、软件错误或其他原因，消息的某个部分被误改。假设，由于这种错误，Bob收到的消息变成了："Hellp"，而不是原始的"Hello"。

Bob的验证过程：

Bob首先使用Alice的公钥解密数字签名，得到摘要A，这个摘要是"H"。

然后，Bob对他收到的消息"Hellp"进行哈希，得到一个摘要B，这个摘要是"P"（因为我们假设摘要只是消息的最后一个字母）。

Bob比较摘要A和摘要B，发现它们不匹配（"H"不等于"P"）。

因此，Bob知道他收到的消息已经在传输过程中被更改或损坏了。

如果Bob只解密数字签名，他会得到一个摘要。这个摘要是原始消息的摘要，但由于消息已经被修改，这个摘要不能与当前消息匹配。

如果Bob没有使用哈希函数再次对收到的消息进行哈希，他将无法知道消息已经被修改。只有当他使用哈希函数对收到的消息进行哈希并将其与解密的摘要进行比较时，他才会发现摘要不匹配。

此外，也请大家明确一点：

当接收到的消息出现错误或与数字签名不匹配时，这种不匹配可能是由于多种原因引起的：

中间人攻击：恶意的第三方可能已经修改了消息内容，试图篡改或伪造消息。
消息传输错误：在数据传输过程中，由于网络问题或其他因素，消息可能出现了误差。这可能是由于噪声、数据包丢失或数据包顺序错乱等原因引起的。
软件或硬件故障：发送或接收消息的设备可能出现了故障，导致消息被误改。

当数字签名验证失败时，我们只知道消息与原始签名不匹配，但我们不能确定是上述哪种情况导致的不匹配。因此，数字签名机制确实不能单独确定消息的不匹配是由于哪种原因引起的。

这也是为什么在实际的安全通信中，我们不仅依赖数字签名，还会使用其他机制，如错误检测和纠正代码、时间戳、证书、双向认证等，以提高消息的完整性、认证性和非否认性。

总而言之，数字签名只能确认消息与原始签名是否匹配。如果不匹配，数字签名不能告诉我们为什么不匹配，是由于中间人攻击、传输错误、还是其他原因。所以，虽然数字签名提供了数据完整性和身份验证，但在实际应用中，为了增强安全性，通常还需要结合其他安全措施和机制。

如何防止中间人篡改数字签名？

关于防止中间人攻击和消息篡改，以下是一些方法：

使用安全的通信协议：例如，使用TLS/SSL来加密传输中的数据。这确保了数据的机密性和完整性，并验证了双方的身份。

数字证书和CA（证书颁发机构）：数字证书包含公钥及其所有者的信息，并由受信任的第三方（即CA）签名。接收者可以验证数字证书的有效性来确定公钥的真实性和合法性，从而避免中间人攻击。

时间戳和过期时间：为消息或签名添加时间戳可以防止重放攻击，确保消息在特定的时间窗口内是有效的。

使用多重签名：在某些情况下，一个操作可能需要多方的批准。通过要求多个数字签名，可以增加系统的安全性。

数字签名在区块链中的应用

数字签名在区块链技术中起到了核心的作用，特别是在确保交易的完整性和不可否认性方面。在区块链中，不是保存上一个区块的公钥，而是保存上一个区块的哈希值。下面将详细解释区块链中的数字签名机制：

数字签名的基本原理:
- 当某人想在区块链上发送一个交易时，他们首先创建一个交易的描述，这通常包括发送者的地址、接收者的地址、金额等信息。
- 发送者使用他们的私钥对这个交易描述进行签名，生成数字签名。
- 交易（包括交易描述和数字签名）被发送到网络，并由网络中的其他参与者（例如比特币中的矿工）验证。
交易的验证:
- 网络中的验证者使用发送者的公钥来验证数字签名。如果签名验证通过，这意味着交易确实来自声称的发送者并且没有被篡改。
- 另外，验证者还会检查发送者是否拥有足够的资金来完成交易。
区块的创建:
- 一旦交易被验证，它会被放入待打包的交易池。
- 矿工或验证者将这些交易打包成一个新的区块。
- 新区块包含了这些交易的信息以及前一个区块的哈希值（而不是公钥）。这种链接方式确保了所有区块的连续性和不可更改性。
区块的添加:
- 新创建的区块会被添加到区块链上，成为链的一部分。
- 一旦区块被添加到链上，其中的交易就被认为是已确认的，并且难以更改。因为要更改一个区块中的信息，你不仅需要更改那个区块，还需要更改它之后的所有区块，这在计算上是非常困难的。

数字签名确保了区块链上的每个交易的真实性和完整性。同时，通过将每个新区块链接到前一个区块的哈希值，确保了区块链的不可更改性和安全性。

总之，数字签名和哈希函数都是区块链安全性的基石。数字签名确保交易的真实性，而哈希函数通过连续链接每个区块来确保整个链的不可更改性。

数字签名在信息安全证书中的作用

信息安全的证书，尤其是X.509证书，是在许多安全应用中使用的，包括SSL/TLS、电子邮件加密和身份验证。这些证书为公钥加密提供了一个框架，允许实体证明自己的数字身份，确保数据的完整性和机密性。

以下是关于X.509证书的详细介绍：

X.509证书的结构

版本号：表示证书的版本。

序列号：证书的唯一标识符。

签名算法标识：用于签名证书的算法。

颁发者：签发证书的证书颁发机构(CA)的名称。

有效期：证书的有效开始日期和结束日期。

主题：证书持有者的名称。

公钥信息：持有者的公钥及其相关信息。

扩展（可选）：关于证书的其他信息。

数字签名：由CA的私钥生成的签名。

证书的颁发

当实体（可以是个人、组织或设备）需要证书时，它会生成一个公钥和私钥对，然后创建一个证书签名请求（Certificate Signing Request, CSR），这个请求通常包括公钥、实体的名称（例如网站的域名）和其他相关信息，这个CSR会发送给CA。

CA验证实体的身份信息，然后生成一个证书，将实体的公钥和其他信息利用哈希函数（通常是SHA256）计算得到的摘要打包进去，并使用CA的私钥签名。

这个数字签名会与原始的公钥和其他信息一起被打包成一个X.509证书，然后返回给请求的实体。实体现在有了一个由CA签发的证书，并可以用它证明自己的身份。

证书的验证

当某个实体（例如，一个网站）向另一个实体（例如，一个浏览器）呈现其证书时，接收者可以使用CA的公钥来验证证书的签名。验证过程如下;

验证证书的实体（浏览器）会使用CA的公钥解密证书中的数字签名，得到摘要。

同时，浏览器会对证书中的公钥和其他信息生成一个新的摘要。

如果这两个摘要匹配，证书就被认为是有效的，这意味着它确实是由CA签发的，并且没有被篡改。

也就是说，验证证书就是数字签名验证数据完整性的过程。数字签名验证中，对原始信息计算得到摘要；在证书验证中，原始信息包括实体网站的公钥和其他信息。

如果签名验证成功，这证明证书是由受信任的CA签发的，因此接收者可以信任证书中的公钥。

证书的有效期和算法更新

证书有一个有效期，通常为一年或几年。这是为了安全考虑，确保即使私钥被泄露，它也不会被长时间地滥用。

随着时间的推移，加密算法可能会因为数学进展或计算能力的增强而变得不安全。当这发生时，证书需要使用新的、更安全的算法重新颁发。这就是证书需要定期更新，以及为什么证书的内容（如签名算法）可能会改变的原因。

CA层次结构

CA（证书颁发机构）层次结构是一个分层的体系，用于在安全和可信任的方式中管理和颁发数字证书。在这种层次结构中，各级的CA具有不同的角色和责任，它们彼此之间存在信任关系。以下是关于CA层次结构的详细解释：

根CA（Root CA）

根CA位于CA层次结构的最顶部。它是最受信任的实体，因为它为整个证书信任链提供基础。

根CA自签名其证书，意味着它的证书不是由其他CA签发的。

根证书通常具有很长的有效期，例如10年或20年。

当浏览器或操作系统预装了一个根证书，意味着它们信任该根CA及其签发的所有下级证书。

中间CA（Intermediate CA）

中间CA位于根CA和最终实体（如网站或个人）之间。

中间CA的证书是由上一级CA（可能是另一个中间CA或根CA）签发的。

使用中间CA可以提供更多的灵活性和安全性。例如，如果中间CA的私钥被泄露，只需要吊销该CA的证书，而不需要吊销整个层次结构的证书。

中间CA也可以用于组织内部的分部门或分功能管理，或者用于特定的业务或地理区域。

最终实体CA（End-entity CA）或叶证书（Leaf Certificates）

这些是实际被用于服务器、客户端或个人的证书。

它们是由中间CA或根CA签发的。

这些证书具有相对较短的有效期，例如1年或2年。

在实际应用中，当我们访问一个使用SSL/TLS的网站时，网站不仅会提供自身的证书，而且还会提供一个证书链。这个链从根证书开始，通过一个或多个中间证书，最终到达网站的证书。您的浏览器或操作系统会验证这个证书链，确保每个证书都是由其上级签发的，并且检查证书是否被吊销或过期。CA层次结构提供了一种分层的方法来管理和验证数字证书。这种结构使得数字证书系统既有灵活性又有安全性。

信任链（Trust Chain）

当客户端（例如，一个浏览器）接收到证书链时，它会尝试构建一个从受信任的根证书到服务器证书的路径。这就是信任链。

为了验证这个链，客户端首先检查第一个证书（服务器证书）是否是由第二个证书（中间CA）签发的，然后检查第二个证书是否是由第三个证书签发的，以此类推，直到达到一个预先知道和信任的根证书。

如果客户端可以成功地验证这个链，那么它就会信任服务器证书。

对于客户端来说，它接收到的是一个证书链，但它试图建立的是一个信任链。简而言之，证书链是服务器提供给客户端的，而信任链是客户端基于这个证书链和它本地受信任的根证书存储来建立的。文章来源地址https://www.toymoban.com/news/detail-765188.html

到了这里，关于CA与区块链之数字签名详解的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！