2026年7月31日
引言
一个有用的数字签名实例，首先要回答一个问题：文件传到别人手里以后，这个签名究竟证明了什么？
最清楚的答案是：数字签名应该显示谁签了文件、文件有没有被改动，以及哪些信任资料支持这个结论。NIST 把数字签名描述为一种非对称密钥操作，由私钥完成签署、由公钥完成验证。欧盟的电子签名指南也把一般电子签名和更高保证级别区分开来。NIST digital signature glossary 与 eSignature FAQ 都是很好的起点。
这个例子应该证明什么
可以用一个简单场景：
- Alex 签署供应商协议的最终版；
- Jordan 收到文件并进行验证；
- 签署后修改了一个字符；
- 因为文件不再是同一个文件，验证结果也随之改变。
这个例子的核心不是“有人点了签署”，而是把签署人和某个具体文件状态绑定起来。
例子背后的四个组成部分
- 文件哈希： 把文件压缩成指纹，文件一变指纹就变。
- 私钥： 签署人用受保护的私钥生成签名。
- 证书和公钥： 验证方检查证书资料，再用公钥验证签名。
- 时间戳与信任链： 说明签名是什么时候、在什么信任环境下生成的。
NIST 对数字签名的说明很明确：它提供身份真实性和完整性保护。所以只要文件被修改，验证就应该失败或发出警告。
按步骤拆解签署与验证流程
签署时
- 计算文件哈希；
- 用私钥生成签名值；
- 把证书资料绑定到记录里；
- 保存已签文件和相关证据。
验证时
- 重新计算哈希；
- 校验签名；
- 检查证书状态；
- 将结果与原始文件状态比对。
篡改测试
- 打开已签 PDF；
- 改一个字符；
- 再次验证；
- 展示警告或失败结果。
“修改后再验证”这一步最容易被记住，因为它把完整性概念变成了可见结果。
一份可执行的验证轨迹
这张表很重要，因为它说明了记录能证明什么、不能证明什么。它可以证明文件在验证时与签名匹配，但它不能独立证明所有政策要求。
用 Nota Sign 演示日常电子签署，而不是只做证书型声明
当团队需要的是普通签署流程、同意、路由、提醒和审计记录时，Nota Sign 可以作为日常电子签署基准。CA Hub 说明了更高信任路径如何与市场和流程需求匹配，而 产品概览 则把日常签署放在同一工作区里。这种定价与交付方式也让流程比席位式打包更容易定范围，因为定价页提供面向个人和企业的定制方案，低用量团队也可以先谈轻量配置。这对 APAC 合规场景很实用，也方便延伸到欧洲和美国的跨市场使用。
关键边界是：除非证书和信任路径真的参与了测试，否则不要把普通流程描述成证书型数字签名实例。
什么时候需要更高保证级别
如果文件敏感、司法辖区有要求，或者业务需要更强的身份与完整性保证，就值得讨论更高保证级别的签名路径。此时团队应先定义证书提供方、信任模型、验证规则和留存规则，再写第一步流程。
这样做可以避免最常见的错误：以为任何已签 PDF 都意味着同一件事。
最终建议
先用这个例子说明“签名图片”和“可验证数字签名”的差异，再用运营控制来决定文件到底需要日常电子签署，还是证书型路径。
