版式文档中的电子印章、电子签章、时间戳

一张电子合同盖了章，凭什么和纸质盖章具有同等法律效力？这背后是一套精密运转的密码学体系——电子印章、电子签章与时间戳三者协同工作，共同构建了数字世界的”信任基石”。

从一枚实物印章说起

在物理世界里，一枚印章之所以被信任，是因为它承载了三重保障：

1. 1. 来源可信 — 印章由权威机构刻制，他人无法伪造
2. 2. 内容绑定 — 盖在文件上后，印章与文件内容融为一体
3. 3. 时间证明 — 文件上的日期记录了盖章发生的时刻

那么问题来了：到了数字世界，这三个保障如何实现？

答案是：密码技术。具体来说，就是我国自主研发的国密算法体系（SM2/SM3/SM4）支撑下的三大机制——电子印章、电子签章、时间戳。

电子印章：数字化的”身份+权限”载体

它是什么？

电子印章不是一张图片，而是一段经过密码学处理的结构化数据。它的核心定义来自国家标准 GB/T 38540-2020《信息安全技术 安全电子签章密码技术规范》：

SESeal ::= SEQUENCE {    eSealInfo    SES_SealInfo,      -- 印章全部属性信息    cert          OCTET STRING,     -- 制章者证书（DER编码）    signAlgID     OBJECT IDENTIFIER,-- 签名算法标识（如 SM2+SM3: 1.2.156.10197.1.501）    signedValue   BIT STRING        -- 制章者对印章信息的签名值}

注意那个 signedValue 字段——这是整枚电子印章的灵魂。制章者用自己的 SM2 私钥对印章的全部属性（印模图像、名称、有效期、授权人证书列表等）进行了数字签名。这意味着：任何人都可以用制章者的公钥验证这枚印章是否被篡改过。

它包含什么？

关键点：印章里还嵌入了签章者证书列表——这意味着只有名单上的人才能使用这枚印章来签文件。

电子签章：把印章”盖”到文件上的过程

核心数据结构

当我们要对一份 OFD 版式文档进行签章时，产生的数据结构如下（同样来自 GB/T 38540-2020）：

SES_Signature ::= SEQUENCE {    toSign         TBS_Sign,           -- 待签名信息（签章信息）    cert           OCTET STRING,       -- 签章者证书（DER编码）    signatureAlgID  OBJECT IDENTIFIER, -- 签名算法 OID    signature      BIT STRING,        -- ⭐ 签章者的 SM2 签名值 (r, s)    timeStamp[0]   BIT STRING OPTIONAL -- 时间戳（可选但重要）}

其中最核心的是 TBS_Sign（To Be Signed，待签名信息）：

TBS_Sign ::= SEQUENCE {    version      INTEGER,         -- 电子签章版本号（与印章版本号保持一致）    eseal        SESeal,          -- 引用的电子印章    timeInfo     GeneralizedTime, -- 签章时间    dataHash      BIT STRING,     -- ⭐ 原文的 SM3 杂凑值（注意是 BIT STRING 类型）    propertyInfo  IA5String,       -- 原文属性（含签名保护范围等，注意是 IA5 String 类型）    extDatas[0]   ExtensionDatas OPTIONAL -- 自定义扩展数据}

类型提示：dataHash 为 BIT STRING 而非 OCTET STRING；propertyInfo 为 IA5 String 而非复杂结构体——这是 GB/T 38540-2020 的明确定义，容易混淆，需特别注意。

签章过程（三步走）

步骤①: 验证印章有效性  → 格式检查 → 签名值验签 → 证书信任链 → 有效期校验步骤②: 对原文进行签名  → 按 propertyInfo 指定的保护范围提取原文  → 计算 SM3 杂凑值 → 得到 dataHash  → 组装 TBS_Sign {eseal + timeInfo + dataHash + propertyInfo}  → 用签章者 SM2 私钥对 TBS_Sign 签名 → 得到 signature(r,s)步骤③: [可选] 申请时间戳  → 将签名值发给 TSA（时间戳机构）→ 获得带可信时间的戳

验证过程（十道关卡）

一份签了章的 OFD 文件在被验证时，需要通过以下检验（依据 GB/T 38540-2020 第7.3节及 GM/T 0047-2024）：

第⑨步是防篡改的核心：如果有人修改了文件内容哪怕一个标点符号，重新计算出的 SM3 杂凑值就会与 dataHash 不匹配，验证立刻失败。

时间戳：独立的第三方时间证人

为什么需要时间戳？

你可能会问：TBS_Sign 里已经有 timeInfo（签章时间）字段了，为什么还要时间戳？

因为 timeInfo 是签章者自己填写的——自报的时间不能作为独立证据。就像你不能自己给自己写一张”我此时此刻在场”的证明一样。

时间戳的作用是引入**可信第三方（TSA，Time Stamp Authority，时间戳机构）**作为时间证人：

签章流程中:  签章者生成签名(r,s)       ↓  将签名值发给 TSA（时间戳机构）       ↓  TSA 执行以下操作:  ① 获取可信时间（来自国家授时中心）  ② 组装 TSTInfo:     genTime: "2026-04-07T10:30:00Z",   ← 可信时间     messageImprint: <签名值的SM3杂凑值>, ← 绑定签名值     serialNumber: 12345678,             ← 全局唯一序号     nonce: 987654321                    ← 防重放随机数  ③ 用 TSA 的 SM2 私钥对 TSTInfo 签名       ↓  返回 TimeStampToken 给签章者       ↓  嵌入 SES_Signature.timeStamp 字段（DER 编码）

注：根据 GB/T 38540-2020 第7.2节b)步骤5的规定，时间戳是对签名值产生的——即 messageImprint 中存放的是签名值的 SM3 杂凑值，从而将签章行为与可信时间强绑定。

时间戳解决的关键问题

三者如何协同工作

┌─────────────────────────────────────────────────────┐│                 完整的签章信任链                      │├─────────────────────────────────────────────────────┤│                                                     ││   电子印章 (SESeal)                                 ││   ┌─────────────────────┐                           ││   │ "我是谁 + 我能授权谁" │ ← 制章者 SM2 签名     ││   └──────────┬──────────┘                           ││              │ 被引用                                   ││              ▼                                         ││   电子签章 (SES_Signature)                          ││   ┌─────────────────────┐                           ││   │ "我用这个章签了这个文件" │ ← 签章者 SM2 签名   ││   │ dataHash = SM3(原文)  │ ← 绑定文件内容         ││   └──────────┬──────────┘                           ││              │ [可选]                                  ││              ▼                                         ││   时间戳 (TimeStampToken / TSTInfo)                 ││   ┌─────────────────────┐                           ││   │ "我在这个时间做了这件事" │ ← TSA SM2 签名      ││   │ genTime = 国家授时中心   │ ← 第三方时间证明     ││   └─────────────────────┘                           ││                                                     ││   验证时: 印章可信 ✓ → 签名正确 ✓ → 内容未篡改 ✓  ││           → 时间戳可信 ✓ → 全链路闭环             ││                                                     │└─────────────────────────────────────────────────────┘

在OFD文档中的实际位置

一份签了章的 .ofd 文件（本质是 ZIP 压缩包），内部结构如下：

document.ofd (ZIP)├── OFD.xml                    主入口文件（唯一）├── Doc_1/│   ├── Document.xml           文档根节点│   └── Page_1/Content.xml      页面内容描述├── Signs/                     ⭐ 数字签名目录│   ├── Signatures.xml          签名列表（记录所有签名）│   └── Sign_1/│       ├── Signature.xml        签章描述（签名方案、保护范围、签名值路径）│       ├── SignedValue.dat     ⭐ 签名值（SES_Signature 的 DER 编码）│       └── Seal.esl            ⭐ 电子印章（SESeal 的 DER 编码）└── [Encryptions.xml]          加密入口（如有加密，OFD 2.0+）

注：根据 GM/T 0099-2020 的规定，Signs/ 目录由签名协议产生。当签名类型为电子签章时，SignedValue.dat 的格式遵循 GB/T 38540（即 SES_Signature）；当签名类型为**数字签名(SM2)**时，则遵循 GB/T 35275 / GM/T 0010（即 SignedData 封装格式）。

法律效力从何而来？

这套技术体系之所以能让电子签章与实物盖章具有同等法律效力，其法规和标准依据包括：

1. 1. 《中华人民共和国电子签名法》 — 确立可靠电子签名的法律地位
2. 2. 《中华人民共和国密码法》 — 规范密码技术的管理和应用
3. 3. 《中华人民共和国网络安全法》《数据安全法》 — 网络与数据安全基础
4. 4. 《电子印章管理办法》（国办发〔2025〕33号） — 明确规定：

   “符合本办法规定的电子印章与实物印章具有同等法律效力”

5. 5. GB/T 33190-2016 — 定义 OFD 版式文档格式（ZIP容器 + XML描述）
6. 6. GM/T 0099-2020 — 定义 OFD 签名/加密/完整性保护三大协议
7. 7. GB/T 38540-2020 / GM/T 0031-2025 — 定义电子印章与签章的数据结构和流程
8. 8. GM/T 0047-2024 — 定义检测方法（17项检测，一票否决制）

最终效果：一份 OFD 电子公文盖上电子签章后，在任何设备上打开都能看到一致的版式布局，且任何人都能验证其真实性（确实是这个人签的）、完整性（文件没被改过）、时间性（确实是在那个时间签的）。

总结

三者层层叠加，配合 OFD 版式文档固定布局、不随软硬件环境变化的特性，构成了数字世界中等效于实体盖章的完整信任体系。

而这整套体系背后的核心技术——SM2 椭圆曲线公钥密码、SM3 密码杂凑算法、SM4 分组密码，正是中国自主研发的国密算法体系，已在政务、金融、医疗、电子商务等领域得到广泛应用。

当你在手机上看到一份盖了电子印章的公文时，你知道：那不是一个简单的图片叠加，而是一次涉及多轮密码运算、多方证书验证、第三方时间戳证的精密操作——这就是数字时代”盖章”的真正含义。