今天聊聊技术,现实中的最普遍的场景中引申出来的安全问题
一、实际应用场景及问题
假设 Alice 要向 Bob 借款 100 万,双方需通过网络完成借贷。核心问题是:如何保证数据在传输中不被篡改,且能证明是 Alice 本人发出、事后无法抵赖。
起初考虑用非对称加密:Bob 生成公钥和私钥,把公钥给 Alice。Alice 用 Bob 的公钥加密数据发送,这样黑客就算中途截获数据,没有 Bob 的私钥也改不了内容。但这里有两个大问题:
-
真假数据难分辨:如果黑客拿到 Bob 的公钥,也能伪造数据加密后发给 Bob,Bob 无法知道哪份是 Alice 真发的。
-
抵赖和伪造风险:要是 Bob 自己偷偷改数据金额(比如把 100 万写成 200 万),Alice 无法证明这不是自己签的。
非对称加密只能解决数据传输中的防篡改问题,那如何保证抗抵赖性呢?这里就需要非对称加密除数据加密外的另一个应用 —— 数字签名。
先介绍下何为数字签名:数字签名就像现实中用印章签字一样,是一种在数字世界里证明 “这份信息确实由我发出,且内容没被改过” 的技术。它的核心作用是解决电子信息的身份认证、内容完整性验证和不可抵赖性。
二、数字签名
- 私钥与公钥的关系:
每个人有一对 “电子钥匙” —— 私钥(只有自己知道,相当于个人专属印章)和 公钥(可以公开给所有人,相当于印章的 “样式模板”)。私钥和公钥是一一对应的,用私钥 “盖章” 的内容,只能用对应的公钥验证是否有效。
- 签名过程:
比如 Alice 要发送消息给 Bob,她会用自己的私钥给消息 “盖章”,生成一个数字签名。这个签名就像附在消息上的 “电子指纹”,只有 Alice 的私钥能生成,别人无法伪造。
- 验证过程:
Bob 收到消息和签名后,用 Alice 的公钥检查签名是否正确。如果验证通过,就说明:
-
消息确实是 Alice 发的(因为只有她的私钥能生成这个签名);
-
消息在传输中没被篡改过(如果内容被改,签名会失效)。
利用数字签名如何解决上述场景中的问题呢?
- Alice 操作:
① 写好数据内容,用哈希函数生成指纹码;
② 用自己的私钥给指纹码 “盖章”(签名),把数据和签名一起发给 Bob。
- Bob 验证:
① 用 Alice 的公开 “电子公章”(公钥)检查签名是否有效,确认这是 Alice 亲手 “盖章” 的;
② 对收到的数据再生成一次指纹码,和 Alice 附带的指纹码对比,看内容是否一致。
这样一来:
-
若内容被篡改过,指纹码对不上,篡改行为会直接被识破;
-
签名验证通过,说明数据确实是 Alice 用自己的私钥签发的,她事后不能赖账;
-
Bob 也没法伪造 Alice 的签名,因为私钥只有 Alice 才有。
三、数字证书
在数字签名应用时,很多人会忽略一个致命漏洞:如何确保你拿到的公钥真的属于对方?
公钥同样是通过网络传输给对方的,假设 Alice 想给 Bob 发送签名消息,正常流程是:
-
Alice 需要 Bob 的公钥来验证 Bob 的回复(或 Bob 需要 Alice 的公钥来验证 Alice 的签名);
-
但如果黑客 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 网站时:
-
服务器发送自己的数字证书(由 DigiCert、Let's Encrypt 等 CA 签发);
-
浏览器用内置的 CA 公钥验证证书,确认服务器身份(比如确认访问的确实是银行官网,而非钓鱼网站);
-
验证通过后,才会用服务器公钥建立加密连接,防止数据被中间人篡改或窃取。
数字签名解决了 “消息是否被篡改、是否由本人发送” 的问题,但缺少数字证书,就无法解决 “公钥对应的身份是否真实” 的问题。两者的关系就像:
-
数字签名是 “电子印章”,负责签内容;
-
数字证书是 “印章的备案证明”,负责证明 “这枚印章确实属于某人”。
只有两者结合,才能在开放的网络环境中构建真正安全的信任体系,避免 “假公钥 + 真签名” 的欺诈风险。
原文始发于微信公众号(YY的黑板报):数字签名及数字证书
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论