数字签名及数字证书

admin 2025年6月19日21:03:09评论10 views字数 2410阅读8分2秒阅读模式

今天聊聊技术,现实中的最普遍的场景中引申出来的安全问题

一、实际应用场景及问题

假设 Alice 要向 Bob 借款 100 万,双方需通过网络完成借贷。核心问题是:如何保证数据在传输中不被篡改,且能证明是 Alice 本人发出、事后无法抵赖

起初考虑用非对称加密:Bob 生成公钥和私钥,把公钥给 Alice。Alice 用 Bob 的公钥加密数据发送,这样黑客就算中途截获数据,没有 Bob 的私钥也改不了内容。但这里有两个大问题:

  1. 真假数据难分辨:如果黑客拿到 Bob 的公钥,也能伪造数据加密后发给 Bob,Bob 无法知道哪份是 Alice 真发的。

  2. 抵赖和伪造风险:要是 Bob 自己偷偷改数据金额(比如把 100 万写成 200 万),Alice 无法证明这不是自己签的。

非对称加密只能解决数据传输中的防篡改问题,那如何保证抗抵赖性呢?这里就需要非对称加密除数据加密外的另一个应用 —— 数字签名。

先介绍下何为数字签名:数字签名就像现实中用印章签字一样,是一种在数字世界里证明 “这份信息确实由我发出,且内容没被改过” 的技术。它的核心作用是解决电子信息的身份认证、内容完整性验证和不可抵赖性

二、数字签名

  • 私钥与公钥的关系:

每个人有一对 “电子钥匙” —— 私钥(只有自己知道,相当于个人专属印章)和 公钥(可以公开给所有人,相当于印章的 “样式模板”)。私钥和公钥是一一对应的,用私钥 “盖章” 的内容,只能用对应的公钥验证是否有效。

  • 签名过程:

比如 Alice 要发送消息给 Bob,她会用自己的私钥给消息 “盖章”,生成一个数字签名。这个签名就像附在消息上的 “电子指纹”,只有 Alice 的私钥能生成,别人无法伪造。

  • 验证过程:

Bob 收到消息和签名后,用 Alice 的公钥检查签名是否正确。如果验证通过,就说明:

  1. 消息确实是 Alice 发的(因为只有她的私钥能生成这个签名);

  2. 消息在传输中没被篡改过(如果内容被改,签名会失效)。

利用数字签名如何解决上述场景中的问题呢?

  • Alice 操作:

① 写好数据内容,用哈希函数生成指纹码;

② 用自己的私钥给指纹码 “盖章”(签名),把数据和签名一起发给 Bob。

  • Bob 验证:

① 用 Alice 的公开 “电子公章”(公钥)检查签名是否有效,确认这是 Alice 亲手 “盖章” 的;

② 对收到的数据再生成一次指纹码,和 Alice 附带的指纹码对比,看内容是否一致。

这样一来:

  • 若内容被篡改过,指纹码对不上,篡改行为会直接被识破;

  • 签名验证通过,说明数据确实是 Alice 用自己的私钥签发的,她事后不能赖账;

  • Bob 也没法伪造 Alice 的签名,因为私钥只有 Alice 才有。

三、数字证书

在数字签名应用时,很多人会忽略一个致命漏洞:如何确保你拿到的公钥真的属于对方?

公钥同样是通过网络传输给对方的,假设 Alice 想给 Bob 发送签名消息,正常流程是:

  1. Alice 需要 Bob 的公钥来验证 Bob 的回复(或 Bob 需要 Alice 的公钥来验证 Alice 的签名);

  2. 但如果黑客 Eve 中途拦截了公钥传输过程,偷偷把自己的公钥伪装成 Bob 的公钥发给 Alice。

后果会有多严重?

  • Alice 以为用的是 Bob 的公钥,但实际用的是 Eve 的公钥,结果 Alice 用了 Eve 的公钥对数据进行了加密传输,过程中 Eve 可以随意解密 Alice 的数据并进行篡改。

  • 更危险的是,Eve 还能拦截 Alice 发给 Bob 的真实签名消息,用自己的公钥替换后再发给 Bob,Bob 会误以为消息被 Alice 篡改了(因为签名验证不通过)。

![[Pasted image 20250619095042.png]]

四、数字证书如何填补信任缺口

数字证书本质是由权威第三方机构(CA,Certificate Authority)签发的 “公钥身份证”,核心功能是绑定公钥与身份的对应关系,流程如下:

1. CA 的公信力基础

CA 就像 “数字世界的公安局”,其自身身份通过物理安全、法律合规性等方式被广泛信任(比如银行、政府认可的 CA)。

2. 证书签发流程

  • Bob 向 CA 提交身份信息(如营业执照、身份证)和自己的公钥;

  • CA 人工或自动验证 Bob 的身份真实性,确认无误后,用 CA 自己的私钥给 Bob 的公钥 “盖章”,生成数字证书(包含 Bob 的身份信息、公钥、有效期等)。

3. 证书解决公钥信任的逻辑

  • Alice 收到 Bob 的公钥时,会同时收到 Bob 的数字证书;

  • Alice 用 CA 的公开公钥(内置在操作系统、浏览器中,默认被信任)验证证书上的 CA 签名:

✅ 若验证通过,说明证书是 CA 签发的,Bob 的公钥确实属于他本人;

❌ 若验证不通过,说明公钥可能被篡改或证书是伪造的。

五、数字证书的核心价值:构建不可伪造的信任链

  • 没有证书时的信任断层:数字签名只能保证 “签名动作真实”,但无法保证 “公钥对应的身份真实”,就像有人拿着假身份证盖章,签名本身再真实也失去意义。

  • 有证书时的闭环验证

Alice 的验证逻辑:  收到 Bob 的公钥 → 用 CA 公钥验证 Bob 的证书有效性 → 确认公钥与 Bob 身份绑定 → 用该公钥验证 Bob 的签名  

这相当于通过 CA 的 “权威背书”,在数字世界建立了 “身份→公钥→签名” 的完整信任链条。

我们常用的 HTTPS 网站(网址以 https:// 开头)就是数字证书的典型应用:

  • 当浏览器访问 HTTPS 网站时:
  1. 服务器发送自己的数字证书(由 DigiCert、Let's Encrypt 等 CA 签发);

  2. 浏览器用内置的 CA 公钥验证证书,确认服务器身份(比如确认访问的确实是银行官网,而非钓鱼网站);

  3. 验证通过后,才会用服务器公钥建立加密连接,防止数据被中间人篡改或窃取。

数字签名解决了 “消息是否被篡改、是否由本人发送” 的问题,但缺少数字证书,就无法解决 “公钥对应的身份是否真实” 的问题。两者的关系就像:

  • 数字签名是 “电子印章”,负责签内容;

  • 数字证书是 “印章的备案证明”,负责证明 “这枚印章确实属于某人”。

只有两者结合,才能在开放的网络环境中构建真正安全的信任体系,避免 “假公钥 + 真签名” 的欺诈风险。

原文始发于微信公众号(YY的黑板报):数字签名及数字证书

免责声明:文章中涉及的程序(方法)可能带有攻击性,仅供安全研究与教学之用,读者将其信息做其他用途,由读者承担全部法律及连带责任,本站不承担任何法律及连带责任;如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截,联系方式见首页),望知悉。
  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2025年6月19日21:03:09
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   数字签名及数字证书https://cn-sec.com/archives/4181092.html
                  免责声明:文章中涉及的程序(方法)可能带有攻击性,仅供安全研究与教学之用,读者将其信息做其他用途,由读者承担全部法律及连带责任,本站不承担任何法律及连带责任;如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截,联系方式见首页),望知悉.

发表评论

匿名网友 填写信息