跳到页面内容
跳到互动练习
互动课堂 / 签名与信任校验台DAILY / SECURITY TERMS

024 / 数据与密码 / Digital Signature

验签通过了,就一定是他同意?

数字签名 · Digital Signature

同一份文件,换一把公钥就验不过;文件改了,旧签名也不再匹配。可如果用的是陌生人的钥匙,或者私钥已经泄露,即使数学检查通过,也还不能放心把它当成预期签署人的批准。

开始探索 ↓9–12 分钟
动手实验 · 场景判断 · 实用检查

左边人物用羽毛笔在包裹文件上签字,箱中放着钥匙;右边用蓝色工具检查完整包裹,下方损坏包裹对应红光。它比喻签名与变更检测,钥匙和光罩并不表示文件已加密,也没有展示证书链或签署人真实意愿。

数字签名 · 本课场景

Digital Signature 概念寓意:用私钥对数据签名,让接收方验证来源、完整性与不可否认性。

左边人物用羽毛笔在包裹文件上签字,箱中放着钥匙;右边用蓝色工具检查完整包裹,下方损坏包裹对应红光。它比喻签名与变更检测,钥匙和光罩并不表示文件已加密,也没有展示证书链或签署人真实意愿。

按 Esc 或点击画面外侧关闭。打开原图 ↗

本课任务 / 数字签名

分别验证内容与签名的对应关系、公钥属于谁,以及当前使用它是否符合信任与业务政策。

  • 区分私钥签名、公钥验签与内容加密
  • 观察文件改变和公钥不匹配的不同失败原因
  • 解释身份绑定、密钥失陷与授权证据的边界

数字签名验证什么?

签署方按具体算法用私钥生成签名,验证方用对应公钥核验数据与签名。安全性依赖合适算法、实现和密钥保护。它能为来源与完整性提供密码学证据,不是把手写名字的图片贴到文件上。[2][3]

签名会把文件藏起来吗?

不会。签名与加密承担不同目标,带签名的内容仍可能明文可读。也不要把所有签名算法描述成“私钥加密、公钥解密”;现实应使用成熟算法与库,课堂只用符号化状态展示验证关系。[1][3]

公钥能验证,就知道是谁了吗?

还要有可信的公钥与预期身份绑定。攻击者自己的钥匙也能生成对自己公钥有效的签名。证书链、受信配置或其他可信分发机制提供绑定依据,验签计算本身不会替你决定该信任哪个名字或根证书。[4]

亲手探索 / 不同条件,不同结果

把“签名匹配”与“可以信任”分成两张检验单。

对固定的虚构订单消息切换签名钥匙、验签公钥、内容与签名是否被改动,再检查身份绑定、密钥状态及独立加密条件。所有 SIG 和钥匙都是符号,不计算真实签名或密文。

数据与信任工作台 · 封闭离线模型

验签通过,为什么还不能直接信任?

先检查消息、签名与公钥是否匹配,再检查公钥属于谁、私钥是否失陷。最后单独观察保密性:签名本身不负责隐藏消息。

示意签封原文固定为“教学订单:3 箱”。小珊是本例授权发布者;陌生方也能用自己的密钥给自己的消息签名。所有密钥和签名都是标签,无真实密钥、算法、证书或安全强度。

第一步:消息、签名与验证公钥
第二步:身份信任与独立的保密条件
本例登记只授权小珊;不能把随包附带的陌生公钥直接当作小珊的公钥。
这里指验签公钥对应的私钥。失陷者可能生成数学上有效的签名,因此验签成功不能排除密钥被盗。
加密保护是独立预设条件,本页不实现或验证任何真实加密通道。

尚未检查当前条件。修改选择会清除旧结论,请重新检查。

默认的陌生方签封能通过对应公钥的示意验签,却不能代表小珊。改为小珊密钥与可信绑定,再依次改变消息、签名、公钥或私钥状态,观察失败发生在哪一层。真实签名验证还要处理算法、证书链、时效、撤销、时间戳与业务上下文。

随手查 / 把理解带回实际工作

理解机制之后,检查这些细节。

实验是简化模型。真实环境需要明确业务规则、验证失败路径,并持续维护配置与证据。

01 / 实用细节

验证的是约定范围内的准确数据

签名绑定算法输入的数据表示。改动被签名的内容会使原验证关系失败;文件容器可能还含签名范围以外的数据,所以应说明究竟覆盖哪些字节或字段。仅看阅读器里的绿色图标,不足以确认所有附件与可见内容都在保护范围内。[2][6]

02 / 实用细节

摘要、MAC 和签名的证据能力不同

普通摘要没有私有密钥参与,攻击者可能同时替换文件与摘要。MAC 使用共享秘密,持有同一秘密的多方都能生成有效结果;数字签名让验证方通常只需公钥,而不用获得签署私钥。选择哪种机制取决于验证者和威胁模型。[3]

03 / 实用细节

证书检查不止看有没有过期

采用 X.509 时,按应用政策验证证书路径、可信锚点、有效期、用途和相关状态,还要确认身份是预期对象。证书自带的显示名称不能单独建立信任;签名有效也不表示该主体有权批准这项业务。[4][6]

04 / 实用细节

私钥失陷后,真格式也可能是伪造意图

获得私钥的一方可能生成数学上有效的新签名。按事件流程停止受损密钥的新使用、处理撤销与替换,并调查受影响的签名范围。课堂用失陷状态解释为何拒绝信任,不把它误写成公钥验签算法必然返回失败。[3]

05 / 实用细节

签名时间不能只相信文件里写的日期

签署方自报时间并不独立证明何时签署。可信时间戳可为数据在某时点已存在提供证据,但还要验证时间戳和相关信任材料。长期验证应结合签署时的证据、后续密钥状态与适用政策,不能只用今天是否过期一刀切。[5][4]

06 / 实用细节

来源证据不替代内容审查与真实意愿

签名可以支持责任追溯,但私钥是否受控、签名是否覆盖预期内容、操作者是否有权限仍需证据。若用于重要操作,应让用户看清并确认实际内容。验签通过不承诺文件无恶意、陈述属实,也不单独作出法律效力或不可争议的结论。[2][6][4]

从模拟,到验证

找一个获准的环境,实际检查一次。

勾选用于本页自查,不会自动标记整课已学会。练习与清单刷新后重置。

本页已检查 0 / 5 项

实际检查清单
30 秒场景小测

更新包签名有效,能否说明内容已被加密?

能解释原因,再标记学会。

小测结果同步错题本;“已学会”沿用原有本地学习记录。

资料与依据

  1. NIST · Digital Signature ↗

    签名与公私钥关系,完整性和来源认证不提供机密性;按原定义上下文理解

  2. NIST FIPS 186-5 · Digital Signature Standard ↗

    签名生成、完整性和来源证据;本课不复制算法参数或宣称合规实现

  3. OWASP · Key Management Cheat Sheet ↗

    公私钥、摘要/MAC/签名区别、密钥用途与失陷响应

  4. IETF RFC 5280 · X.509 Certificates and CRLs ↗

    信任锚点、证书路径、用途、时间与撤销;不规定法律效力

  5. IETF RFC 3161 · Time-Stamp Protocol ↗

    数据在特定时间前已存在的证据与可信时间源;不是自报时间

  6. OWASP · Transaction Authorization ↗

    让确认绑定重要数据、区分身份认证与操作授权

本页场景、人物与数据均为教学示例。互动选择不会上传;收藏、已学会与错题沿用当前浏览器本地存储。来源正文核对日期:2026-10-11。