文章总结： GM/T0031-2025《安全电子签章密码技术规范》在GB/T38540-2020基础上进行了重要升级，核心变化包括：电子印章数据结构版本从v4升级至v5，新增timeStamp可选字段为签名值提供可信时间戳；在生成流程中新增制章者证书有效性验证步骤；验证流程细化了证书失效判定逻辑，增加了制章时间有效性和时间戳验证。该规范通过PKI公钥密码技术、数字签名和时间戳机制，确保电子印章和电子签章的真实性、完整性和不可否认性，为电子签名法的实施提供了更完善的技术保障。 综合评分： 85 文章分类： 技术标准,数据安全,应用安全,解决方案,政策法规
一文读懂 GM/T 0031-2025《安全电子签章密码技术规范》
原创
利刃信安 利刃信安
利刃信安
2026年7月14日 15:30 北京
在小说阅读器读本章
去阅读
一文读懂 GM/T 0031-2025
《安全电子签章密码技术规范》
电子印章 · 电子签章 · 时间戳 · ASN.1 · SM2签名
01
PART
密码应用安全机制
SECURITY MECHANISM
本标准主要按照《电子签名法》的要求，采用密码技术从安全数据格式定义以及安全处理流程两个方面来规范并保障电子印章、电子签章的安全性。
首先，安全电子印章和电子签章的数据结构安全性是基于 PKI 公钥密码技术，采用数字签名等技术应用来统一定义。
其次，电子印章和电子签章的生成和验证流程需要遵循严格的数据格式定义，经历严谨的密码运算过程，环环相扣，从而确保电子印章和电子签章的真实性、数据完整性，以及制章或签章行为的不可否认性。
安全电子签章是通过采用 PKI 公钥密码技术，将数字图像处理技术与电子签名技术进行结合，以电子形式对加盖印章图像数据的电子文档进行数字签名，以确保文档来源的真实性以及文档的完整性，防止对文档未经授权的篡改，并确保签章行为的不可否认性。
为了确保电子印章的完整性、不可伪造性，以及合法用户才能使用，需要定义一个安全的电子印章数据格式，通过数字签名，将印章图像数据与签章者等印章属性进行安全绑定，形成安全电子印章。在使用印章过程中，应对电子印章进行安全性验证。
在使用电子印章对各种文档进行电子签章过程中，签章者通过数字签名对文档数据进行签章处理，从而达到与传统纸质文件盖章操作相同的可视化效果，同时又利用数字签名技术保障了文档数据的真实性、完整性以及签章者行为的不可否认性。
02
PART
密码应用协议
CRYPTOGRAPHIC PROTOCOL
2.1 电子印章
2.1.1 数据格式
2.1.1.1 印章数据结构
电子印章由印章信息、制章者证书、签名算法标识、签名值、时间戳等部分组成，其数据结构如下。
电子印章数据的 ASN.1 定义为：
…asn1
SESeal ::= SEQUENCE {
eSealInfo SES_SealInfo, — 印章信息
cert OCTET STRING, — 制章者证书
signAlgID OBJECT IDENTIFIER, — 签名算法标识
signedValue BIT STRING, — 签名值
timeStamp [0] BIT STRING OPTIONAL — 对签名值的时间戳 [新增]
}
说明：与 GB/T 38540-2020 相比，SESeal 结构中新增了 timeStamp 可选字段，用于对签名值加盖时间戳，增强印章的时效性保障能力。
2.1.1.2 印章信息
2.1.1.2.1 数据结构
印章信息 eSealInfo 由印章头、印章标识、印章属性、印章图像数据、自定义数据等部分组成。
印章信息 eSealInfo 的 ASN.1 定义如下：
…asn1
SES_SealInfo ::= SEQUENCE {
header SES_Header, — 印章头
esID IA5String, — 印章标识
property SES_ESPropertyInfo, — 印章属性
picture SES_ESPictureInfo, — 印章图像数据
extDatas ExtensionDatas OPTIONAL — 自定义数据
}
2.1.1.2.2 印章头
印章头由头标识、版本号和厂商标识等组成。
印章头的 ASN.1 定义为：
…asn1
SES_Header ::= SEQUENCE {
ID IA5String, — 头标识
version INTEGER, — 印章版本号
Vid IA5String — 厂商标识
}
其中：
ID：固定值 “ES”。
version：电子印章数据结构版本号，本标准设定数值为 5，代表当前版本为 v5。
Vid：电子印章厂商标识，在互联互通时，用于识别不同的软件厂商实现。
说明：与 GB/T 38540-2020 相比，version 从 4（v4）升级为 5（v5）。
2.1.1.2.3 印章标识
esID：区分电子印章的唯一标识编码，用于查找和索引其他信息。
2.1.1.2.4 印章属性
印章属性由印章类型、印章名称、签章者证书信息类型、签章者证书信息列表、制作时间、有效期起始时间、有效期终止时间等部分组成。
印章属性的 ASN.1 定义为：
…asn1
SES_ESPropertyInfo ::= SEQUENCE {
type INTEGER, — 印章类型
name UTF8String, — 印章名称
certListType INTEGER, — 签章者证书信息类型
certList SES_CertList, — 签章者证书信息列表
createDate GeneralizedTime, — 印章制作时间
validStart GeneralizedTime, — 印章有效期起始时间
validEnd GeneralizedTime — 印章有效期终止时间
}
其中：
type：代表印章类型，可根据业务需要自定义。
name：印章名称，如”××公司财务专用章”，对于在公安部门进行备案的印章，其印章名称与备案的名称保持一致。
certListType：签章者证书信息类型，1——数字证书，2——数字证书的杂凑值。
certList：签章者证书信息列表，一个或多个签章者证书或签章者证书杂凑值组成的列表。
createDate：印章制作时间。
validStart：印章有效期起始时间。
validEnd：印章有效期终止时间。
…asn1
SES_CertList ::= CHOICE {
certs CertInfoList, — 签章者证书
certDigestList CertDigestList — 签章者证书杂凑值
}
CertInfoList ::= SEQUENCE OF Cert
CertDigestList ::= SEQUENCE OF CertDigestObj
Cert ::= OCTET STRING
— Cert 符合 GB/T 20518 中 Certificate 定义，按 DER 编码格式存放
CertDigestObj ::= SEQUENCE {
type ObjType, — 自定义类型
value CertDigestValue — 证书杂凑值
}
ObjType ::= PrintableString
CertDigestValue ::= OCTET STRING
2.1.1.2.5 印章图像数据
印章图像数据由图像类型、图像数据、图像显示宽度和图像显示高度等部分组成。
印章图像数据的 ASN.1 定义为：
…asn1
SES_ESPictureInfo ::= SEQUENCE {
type IA5String, — 图像类型
data OCTET STRING, — 图像数据
width INTEGER, — 图像显示宽度
height INTEGER — 图像显示高度
}
其中：
type：印章图像数据格式类型，如 GIF、BMP、JPG、PNG、SVG 等。
data：印章图像数据，机构的电子印章宜采用相关国家管理部门指定的印模。
width：图像显示宽度，单位为毫米（mm）。
height：图像显示高度，单位为毫米（mm）。
2.1.1.2.6 自定义数据
自定义数据包含一系列自定义属性字段，可用于支持电子印章扩展特性，其 ASN.1 定义为：
…asn1
ExtensionDatas ::= SEQUENCE SIZE (0..MAX) OF ExtData
ExtData ::= SEQUENCE {
extnID OBJECT IDENTIFIER, — 自定义扩展字段标识
critical BOOLEAN DEFAULT FALSE, — 自定义扩展字段是否关键
extnValue OCTET STRING — 自定义扩展字段数据值
}
2.1.1.3 制章者证书
cert：对电子印章进行签名的制章者的数字证书，应符合 GB/T 20518 中 Certificate 定义，按 DER 编码格式存放。
2.1.1.4 签名算法标识
signAlgID：代表签名算法 OID 标识，应符合 GB/T 33560 的规定。
示例：基于 SM2 算法和 SM3 算法的签名 OID 为 1.2.156.10197.1.501。
2.1.1.5 签名值
signedValue：制章者对电子印章格式中印章信息域 SES_SealInfo，按 SEQUENCE 方式组成的信息内容进行数字签名所得的结果。
如果签名算法使用 SM2，应符合 GB/T 35276 的规定。
2.1.1.6 时间戳 【新增】
timeStamp：对签名值 signedValue 的时间戳，应符合 GB/T 20520—2025 的规定，时间戳格式按 DER 编码存放。该字段为可选字段。
时间戳令牌（TimeStampToken）采用 ContentInfo 结构封装，内部为 SignedData 结构，核心时间信息定义在 TSTInfo 结构中。TSTInfo 包含版本号（v2）、TSA 安全策略 OID、消息摘要（MessageImprint，其 hashedMessage 为 signedValue 的杂凑值）、时间戳序列号、可信时间 genTime（UTC 格式）、时间精度 accuracy、随机数 nonce 等字段。完整的数据结构定义及签名验签过程见附录 B。
说明：本字段为 GM/T 0031-2025 相比 GB/T 38540-2020 的新增内容，在电子印章数据格式层面引入时间戳机制，为印章的创建时间提供可信证明。
2.1.2 电子印章生成流程
电子印章生成流程如下：
a) 验证制章者证书的有效性。验证项至少包括：制章者证书信任链验证、制章者证书有效期验证、制章者证书是否被撤销、密钥用法是否正确。如果制章者证书验证失败，返回错误代码并退出生成流程。
说明：本步骤为 GM/T 0031-2025 相比 GB/T 38540-2020 的新增步骤，在生成印章前先验证制章者证书，确保制章者身份的合法性。
b) 按 2.1.1.2 定义的数据格式，将印章头、印章标识、印章属性、印章图像数据、自定义数据等数据按 SEQUENCE 方式组成印章信息；
c) 根据签名算法标识 signAlgID，对上述步骤 b) 的印章信息域进行数字签名运算，形成签名值；
d) 生成时间戳。利用上述签名值产生相应的时间戳。
说明：本步骤为 GM/T 0031-2025 相比 GB/T 38540-2020 的新增步骤，在印章生成过程中增加时间戳，为印章创建时间提供可信证明。
e) 将上述步骤 b)、c) 和 d) 的数据以及制章者证书、签名算法标识组成 2.1.1.1 定义的电子印章数据格式。
2.1.3 电子印章验证流程
电子印章验证流程如下：
a) 验证电子印章数据格式的正确性
按照电子印章格式解析电子印章，验证是否符合 2.1.1 定义的电子印章数据格式。
如果电子印章数据格式不正确，则验证失败，返回错误代码并退出验证流程。
b) 验证电子印章签名值是否正确
根据印章信息、制章者证书、签名算法标识来验证电子印章中的签名值是否正确。
如果电子印章签名验证失败，返回错误代码并退出验证流程。
c) 验证制章时间的有效性 【新增】
根据印章属性中的印章制作时间 createDate，验证在制章时间点上电子印章数据是否有效。
如果制章时间验证失败，返回错误代码并退出验证流程。
说明：本步骤为 GM/T 0031-2025 相比 GB/T 38540-2020 的新增步骤，确保印章在制作时间点是有效的。
d) 验证电子印章制章者证书的有效性 【增强】
验证制章者证书的有效性，验证项至少包括：制章者证书信任链验证、制章者证书有效期验证、制章者证书是否被撤销、密钥用法是否正确。
如果制章者证书验证失败，需结合制章时间综合判断：
若制章者证书因有效期过期或吊销导致验证失败，但在制章时间点上制章者证书是有效的，则记录为提示信息，继续进行后续验证；
若在制章时间点上制章者证书也是无效的（已过期或已吊销），则返回错误代码并退出验证流程；
若制章者证书因信任链验证或密钥用法不正确导致验证失败，则返回错误代码并退出验证流程。
说明：与 GB/T 38540-2020 相比，本步骤细化了证书失效的判定逻辑。GB/T 38540-2020 原逻辑为”如果制章者证书验证失败，返回错误代码并退出验证流程”，未区分失效原因和时间点。GM/T 0031-2025 增加了制章时间点的综合判断，区分了证书过期/吊销场景，使验证逻辑更加精细合理。
e) 验证电子印章的有效期
根据印章属性中的印章有效期起始时间 validStart 和有效期终止时间 validEnd，验证电子印章是否过期。
如果电子印章已过期，则验证失败，返回错误代码并退出验证流程。
f) 验证电子印章中时间戳的有效性 【新增】
如果电子印章数据中包含时间戳（即 2.1.1.1 中 SESeal 的 timeStamp 字段存在），则应进行时间戳的有效性验证。
若时间戳验证不通过，则返回错误代码并退出验证流程。
比对时间戳中的时间与印章制作时间 createDate，若制作时间晚于时间戳中的时间，则返回错误代码并退出验证流程。
说明：本步骤为 GM/T 0031-2025 相比 GB/T 38540-2020 的新增步骤，验证印章关联的时间戳有效性。
g) 如果上述步骤都验证成功，则电子印章验证正确有效，可正常退出验证流程。
2.2 电子签章
2.2.1 数据格式
2.2.1.1 签章数据结构
电子签章数据由签章信息、签章者证书、签名算法标识、签名值、时间戳等组成。
电子签章数据的 ASN.1 定义为：
…asn1
SES_Signature ::= SEQUENCE {
toSign TBS_Sign, — 签章信息
cert OCTET STRING, — 签章者证书
signatureAlgID OBJECT IDENTIFIER, — 签名算法标识
signature BIT STRING, — 签名值
timeStamp [0] BIT STRING OPTIONAL — 对签名值的时间戳
}
2.2.1.2 签章信息
签章信息由版本号、电子印章、签章时间、原文杂凑值、原文属性、自定义数据等组成。
…asn1
TBS_Sign ::= SEQUENCE {
version INTEGER, — 电子签章版本号
eseal SESeal, — 电子印章
timeInfo GeneralizedTime, — 签章时间
dataHash BIT STRING, — 原文杂凑值
propertyInfo IA5String, — 原文数据的属性
extDatas [0] ExtensionDatas OPTIONAL — 自定义数据
}
其中：
version：电子签章版本号，该版本号与电子印章版本号保持一致，本标准设定数值为 5，代表当前版本为 v5。
eseal：生成电子签章使用的电子印章。
timeInfo：电子签章对应的时间，可以是 GeneralizedTime 时间。
dataHash：待签名原文的杂凑值。
propertyInfo：原文数据的属性，如文档 ID、日期、段落、原文内容的字节数、指示信息、签名保护范围等，此部分受签名保护。propertyInfo 的具体结构可自行定义，但至少应包含签名保护范围。
extDatas：厂商自定义数据。
说明：与 GB/T 38540-2020 相比，version 从 4（v4）升级为 5（v5），与电子印章版本号保持一致。
2.2.1.3 签章者证书
cert：签章者的数字证书，应符合 GB/T 20518 的规定，按 DER 编码格式存放。
2.2.1.4 签名算法标识
signatureAlgID：签名算法标识，应符合 GB/T 33560 的规定，应与签章者证书中的算法声明保持一致。
示例：基于 SM2 算法和 SM3 算法的数字签名 OID 为 1.2.156.10197.1.501。
2.2.1.5 签名值
signature：签章者对签章信息 TBS_Sign 进行数字签名的结果。注意签名过程中的原文杂凑所采用的算法应与签名算法保持协调，如果签名算法是 SM2，则杂凑算法应采用 SM3 算法。
如果签名算法使用 SM2，应符合 GB/T 35276 的规定。
2.2.1.6 时间戳
timeStamp：对签名值 signature 的时间戳，应符合 GB/T 20520—2025 的规定，时间戳格式按 DER 编码存放。
时间戳令牌（TimeStampToken）采用 ContentInfo 结构封装，内部为 SignedData 结构，核心时间信息定义在 TSTInfo 结构中。TSTInfo 包含版本号（v2）、TSA 安全策略 OID、消息摘要（MessageImprint，其 hashedMessage 为 signature 的杂凑值）、时间戳序列号、可信时间 genTime（UTC 格式）、时间精度 accuracy、随机数 nonce 等字段。验证过程包括：验证时间戳令牌格式正确性、验证签名值、验证 TSA 证书有效性（含 id-kp-timeStamping 扩展密钥用途）、验证摘要匹配、验证时间戳时间。完整的数据结构定义及签名验签过程见附录 B。
当签名算法为 SM2 时，SignedData 结构定义见 GB/T 35275；当为 SM9 时，见 GM/T 0081。
2.2.2 电子签章生成流程
电子签章生成流程如下：
a) 准备电子印章，并验证电子印章的正确性和有效性，具体步骤如下：
说明：与 GB/T 38540-2020 相比，本步骤调整了子步骤的验证顺序，优先验证电子签章证书的匹配性，使验证流程更加高效。
1) 选择拟进行电子签章的签章者证书，并验证该证书的有效性。验证项至少包括：证书信任链、证书有效期验证、证书是否被撤销、密钥用法是否正确。
2) 根据电子印章中的签章者证书列表类型，提取电子印章中的签章者证书信息列表，并用来判断步骤 1) 选择的签章者证书是否在列表中。如果证书信息类型值为 1，则直接比对证书；如果值为 2，则计算步骤 1) 中的证书的杂凑再进行比对：
如果拟签章者在电子印章的签章者列表中，则进行后续流程；
如果比对失败，返回错误代码并退出签章流程。根据错误代码进一步判断，如果比对失败是因为签章者证书执行更新、重签发等操作而导致，程序应提示重新制作印章。
3) 按照 2.1.3 验证电子印章的正确性和有效性。
b) 对原文进行电子签章，具体步骤如下：
1) 按照 propertyInfo 中的签名保护范围来准备待签名原文；
2) 将待签名原文数据进行杂凑运算，形成原文杂凑值；
3) 按照 2.2.1.2 电子签章数据格式组成签章信息；
4) 签章者对签章信息进行数字签名，生成签名值；
5) 如果需要加盖时间戳，则利用上述签名值产生相应的时间戳；
6) 将步骤 3)、4)、5) 以及签章者信息、签名算法标识组成 2.2.1.1 定义的电子签章数据。
2.2.3 电子签章验证流程
电子签章验证流程如下：
a) 验证电子签章数据格式的正确性
1) 根据 2.2.1 数据格式来解析电子签章数据。
2) 若解析失败，则返回错误代码并退出验证流程。
3) 按照 2.1.3 流程来验证上述电子签章中的电子印章的正确性。
4) 如果电子签章或电子印章数据格式不正确，则返回错误代码并退出验证流程。
b) 验证电子签章签名值是否正确
1) 根据步骤 a) 解析所得的签章信息、签章者证书和签名算法标识，验证电子签章签名值。
2) 如果签名值验证失败，则返回错误代码并退出验证流程。
c) 验证签章者证书与电子印章的匹配性
1) 提取电子印章中的签章者证书信息类型与签章者证书信息列表。
2) 如果上述签章者证书信息类型值为 1，则需要比对数字证书。将步骤 a) 解析所得的签章者证书与电子印章中签章者证书信息列表内的证书逐一作二进制比对，若均比对失败，则返回错误代码并退出验证流程。
3) 如果上述签章者证书信息类型值为 2，则需要比对证书的杂凑值。先计算步骤 a) 解析所得的签章者证书的杂凑值，再与电子印章中签章者证书信息列表内的杂凑值逐一作比对，若均比对失败，则返回错误代码并退出验证流程。
d) 验证电子印章的有效性
1) 从签章信息中提取电子印章，按照 2.1.3 电子印章验证流程验证印章的有效性，若验证失败，需结合签章信息中的签章时间综合判断。
2) 若电子印章失效因制章者证书失效导致，且在签章时间点上制章者证书也是无效的，则应记录为提示信息。
3) 若电子印章失效因过期或被撤销所导致，且在签章时间不在电子印章有效期内，或当时电子印章不在正常状态，则返回错误代码并退出验证流程。
4) 验证签章时刻，电子印章是否处于正常状态，如不处于正常状态，则返回错误代码并退出验证流程。
e) 验证签章者证书有效性
1) 从电子签章数据获得签章者证书，验证签章者证书有效性，验证项至少包括：证书信任链验证、证书有效期验证、证书是否被撤销、密钥用法是否正确。
2) 若签章者证书有效性验证失败且是由于证书信任链验证或密钥用法不正确导致的，则返回错误代码并退出验证流程。
3) 若签章者证书有效性验证失败且是由于证书过期或证书状态已撤销导致的，则按步骤 f) 进一步判断。
f) 验证签章时间的有效性
1) 比对签章者证书有效期和签章时间，如果签章时间不在签章者证书有效期内，则签章无效，验证失败，返回错误代码并退出验证流程。
2) 如果签章时间处于签章者证书有效期内，则检查对应的撤销列表，如果证书在签章时间处于失效状态，则签章无效，验证失败，返回错误代码并退出验证流程。
g) 验证原文杂凑
1) 从电子签章数据中提取 propertyInfo 数据，从 propertyInfo 中提取签名保护范围，提取待验证原文。
2) 将待验证原文数据进行杂凑运算，形成待验证原文杂凑值。
3) 从电子签章数据中提取原文杂凑值，与上述待验证原文杂凑值进行二进制比对，如果比对失败，则电子签章验证失败，返回错误代码并退出验证流程。
h) 验证时间戳的有效性
1) 如果电子签章数据中包含时间戳，则应进行时间戳的有效性验证。
2) 若时间戳验证不通过，则签章无效，返回错误代码并退出验证流程。
3) 比对时间戳中的时间与签章时间，若签章时间晚于时间戳中的时间，则签章无效，返回错误代码并退出验证流程。
4) 按照步骤 f) 验证时间戳中时间的有效性，若不通过，返回错误代码并退出验证流程。
如果上述各步骤验证均有效，那么电子签章验证结果为有效，可正常退出验证流程。
说明：电子签章验证流程与 GB/T 38540-2020 保持兼容，无明显变更，确保原有系统可平滑过渡。
A1
PART
与 GB/T 38540-2020 的主要差异汇总
DIFFERENCES
| 类别 | GB/T 38540-2020 | GM/T 0031-2025 | 差异类型 | | — | — | — | — | | 电子印章数据格式 | 版本号 v4，无时间戳字段 | 版本号 v5，新增加时间戳可选项 | 新增字段 + 版本升级 | | 电子印章生成流程 | 3 步骤（组成印章信息→签名→组成数据） | 5 步骤（验证证书→组成印章信息→签名→生成时间戳→组成数据） | 新增 2 个步骤 | | 电子印章验证流程 | 4 步骤（格式→签名值→证书→有效期） | 7 步骤（格式→签名值→制章时间→证书→有效期→时间戳→完成） | 新增 3 个步骤 + 证书判定逻辑细化 | | 电子签章数据格式 | 版本号 v4 | 版本号 v5 | 版本升级 | | 电子签章过程 | 验证顺序：印章→证书→匹配性 | 验证顺序：证书匹配性→印章→证书 | 验证顺序调整 | | 电子签章验证过程 | 8 步骤完整流程 | 8 步骤完整流程 | 无变化（兼容） |
B1
PART
时间戳数据结构与签名验签详解
TIMESTAMP DETAILS
本附录根据 GB/T 20520—2025《网络安全技术 公钥基础设施 时间戳规范》附录 A 以及本标准 2.1.1.6、2.2.1.6 中对时间戳的引用，系统梳理时间戳的完整数据结构、申请颁发流程和签名验签机制。
B.1 时间戳系统组成
时间戳系统由以下三个部分组成：
可信时间源：时间戳系统的时间来源，负责为系统颁发的时间戳提供可信的时间来源。在颁发时间戳时，依据可信时间源填写时间。可信时间源产生的时间应能溯源至标准时间（如国家授时中心）。
签名系统：负责接收时间戳申请、验证申请合法性、产生和颁发时间戳。使用专门的签名密钥对时间戳进行签名，签名密钥的数字证书应符合 GB/T 20518—2018 的规定，且证书的扩展密钥用途中应包含 id-kp-timeStamping。
时间戳数据库：负责保存签名系统颁发的所有时间戳。
B.2 时间戳申请与颁发流程
时间戳申请和颁发的过程如下：
-
请求方向 TSA 提交时间戳申请请求，TSA 签名系统接收到申请请求后，对请求消息的合法性进行检验。
-
如果请求消息格式不正确或由于某种内部原因无法颁发，TSA 产生时间戳失败响应，并在响应中详细描述申请被拒绝的原因。
-
如果请求消息合法，TSA 签名系统填写时间戳并进行签名。同一个 TSA 可在不同场景下使用多个不同签名密钥的私钥进行签名。
-
TSA 签名系统通过可信信道把新生成的时间戳发送给时间戳数据库，由时间戳数据库将其归档保存。
-
TSA 通过与用户申请方式对应的颁发方式，将新生成的时间戳发给用户。
-
用户在收到时间戳后，使用 TSA 的证书验证时间戳的合法性，并检验时间戳内容是否有错误。
B.3 时间戳请求消息格式（TimeStampReq）
时间戳请求消息的 ASN.1 定义如下：
…asn1
TimeStampReq ::= SEQUENCE {
version INTEGER{v2(2)}, — 版本号，本标准为v2
messageImprint MessageImprint, — 待加盖时间戳数据的摘要
reqPolicy TSAPolicyId OPTIONAL, — 请求的安全策略OID
nonce INTEGER OPTIONAL, — 随机数（防重放攻击）
certReq BOOLEAN DEFAULT FALSE, — 是否请求TSA公钥证书
extensions [0] IMPLICIT Extensions OPTIONAL — 扩展域
}
其中：
version：时间戳申请消息格式的版本号，依据 GB/T 20520—2025 生成的申请消息版本为 v2。
messageImprint：包含需要加盖时间戳的数据的摘要，摘要值为 OctetString 类型，长度是相应杂凑算法的杂凑值长度。
reqPolicy：安全策略 OID。如果用户需要指明时间戳应在什么样的安全策略下生成，可设置此域。
nonce：随机数，用于在没有可靠的本地时钟的情况下检验响应消息的合法性并防止重放攻击。
certReq：如果请求消息中 certReq 为 true，则 TSA 在其响应消息中给出其公钥证书。
extensions：扩展域，用于为申请消息添加额外信息。对于其中任何一个扩展，无论其是否是关键扩展，当它在请求消息中出现且又无法被 TSA 识别时，TSA 应不为该请求生成时间戳并返回失败信息（unacceptedExtension）。
MessageImprint 结构：
…asn1
MessageImprint ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier, — 杂凑算法OID
hashedMessage OCTET STRING — 摘要值
}
B.4 时间戳响应消息格式（TimeStampResp）
时间戳响应消息的 ASN.1 定义如下：
…asn1
TimeStampResp ::= SEQUENCE {
status PKIStatusInfo, — 响应状态
timeStampToken TimeStampToken OPTIONAL — 时间戳令牌
}
PKIStatusInfo 结构：
…asn1
PKIStatusInfo ::= SEQUENCE {
status PKIStatus, — 状态码
statusString PKIFreeText OPTIONAL, — 状态描述字符串
failInfo PKIFailureInfo OPTIONAL — 失败原因
}
PKIStatus 枚举值：
…asn1
PKIStatus ::= INTEGER {
granted (0), — 授予
grantedWithMods (1), — 授予（有修改）
rejection (2), — 拒绝
waiting (3), — 等待
revocationWarning (4), — 吊销警告
revocationNotification (5) — 吊销通知
}
当且仅当 PKIStatusInfo 中的 status 值为 0 或 1 时，响应消息中应包含 TimeStampToken。
PKIFailureInfo 失败原因位串：
…asn1
PKIFailureInfo ::= BIT STRING {
badAlg (0), — 申请使用了不支持的算法
badRequest (2), — 非法的申请
badDataFormat (5), — 数据格式错误
timeNotAvailable (14), — TSA的可信时间源出现问题
unacceptedPolicy (15), — 不支持申请消息中声明的策略
unacceptedExtension (16), — 申请消息中包括了不支持的扩展
addInfoNotAvailable (17), — 有不理解或不可用的附加信息
systemFailure (25) — 系统内部错误
}
B.5 时间戳令牌核心结构（TimeStampToken / TSTInfo）
时间戳令牌整体采用 ContentInfo 结构封装：
…asn1
TimeStampToken ::= ContentInfo
— contentType 为 id-signedData
— content 为 SignedData
当签名算法为 SM2 时，SignedData 结构定义见 GB/T 35275；当为 SM9 时，见 GM/T 0081。TimeStampToken 不应含有除 TSA 签名以外的任何其他数字签名。
TSTInfo 核心时间信息结构：
…asn1
TSTInfo ::= SEQUENCE {
version INTEGER{v2(2)}, — 版本号，本标准为v2
policy TSAPolicyId, — 响应消息的TSA安全策略OID
messageImprint MessageImprint, — 待加盖时间戳数据的摘要
serialNumber INTEGER, — 时间戳序列号
genTime GeneralizedTime, — 可信时间（UTC格式）
accuracy Accuracy OPTIONAL, — 时间精度
ordering BOOLEAN DEFAULT FALSE, — 是否要求排序
nonce INTEGER OPTIONAL, — 随机数
tsa [0] GeneralName OPTIONAL, — TSA名称
extensions [1] IMPLICIT Extensions OPTIONAL — 扩展域
}
其中各域说明：
| 字段 | 说明 | | — | — | | version | 时间戳版本号，本标准为 v2 | | policy | 响应消息是根据 TSA 的哪个策略生成的。如果类似的域出现在 TimeStampReq 中，该域具有相同的值 | | messageImprint | 与 TimeStampReq 中类似的域有相同的值，前提是杂凑值的长度与 hashAlgorithm 标记的算法预期的长度相同 | | serialNumber | TSA 分配的一个整数。对同一个 TSA 发出的每一个时间戳，serialNumber 应是唯一的，即使经历一个可能的服务中断（例如崩溃）后，该特性也应保留 | | genTime | TSA 创建时间戳的时间，采用 UTC 时间表示，语法结构为 YYYYMMDDhhmmss[.s…]Z | | accuracy | 表示时间可能出现的最大误差。genTime + accuracy 得到 TSA 创建这个时间戳的时间上限，genTime – accuracy 得到时间下限 | | ordering | 如果出现并被置为 true，则同一个 TSA 签发的每一个时间戳都可依据 genTime 排序，而不必考虑 genTime 精确度 | | nonce | 如果在 TimeStampReq 中出现了 nonce 域，则此处也应出现，其值应等于 TimeStampReq 中的值 | | tsa | 为鉴别 TSA 的名称提供的一个线索。如果出现，应与用于验证时间戳的 TSA 证书里的主体名称中的一个相同 | | extensions | 扩展域，为将来增加额外的信息而采用的一种通常的做法 |
时间精度 Accuracy 结构：
…asn1
Accuracy ::= SEQUENCE {
seconds INTEGER OPTIONAL, — 秒
millis [0] INTEGER (1..999) OPTIONAL, — 毫秒
micros [1] INTEGER (1..999) OPTIONAL — 微秒
}
如果 seconds、millis 或 micros 未出现，则未出现域的值应被赋为 0。当这个可选项不出现时，精确度可从别的途径得到（例如 TSAPolicyId）。
B.6 时间戳签名过程
TSA 签名系统生成时间戳签名的过程如下：
1. 组装 TSTInfo 结构：填写版本号（v2）、安全策略OID、消息摘要（MessageImprint，包含待签名数据的杂凑值和杂凑算法OID）、序列号、可信时间 genTime、时间精度 accuracy 等字段，按 SEQUENCE 方式组成 TSTInfo 结构。
2. DER 编码：对 TSTInfo 结构按 DER 编码规则进行编码。
3. 计算杂凑值：对 DER 编码后的 TSTInfo 数据进行杂凑运算，形成杂凑值。当签名算法为 SM2 时，杂凑算法采用 SM3。
4. 数字签名：使用 TSA 签名私钥对杂凑值进行数字签名，生成签名值。TSA 签名私钥对应的数字证书应符合 GB/T 20518—2018 的规定，且证书扩展密钥用途中必须包含 id-kp-timeStamping（OID: 1.3.6.1.5.5.7.3.8）。
5. 封装 SignedData：将 DER 编码后的 TSTInfo（作为 content）、签名算法集合、TSA 证书集合、签名信息集合等封装为 SignedData 结构。
6. 封装 TimeStampToken：将 SignedData 封装为 ContentInfo 结构（contentType 为 id-signedData），即得到 TimeStampToken。
7. DER 编码输出：对 TimeStampToken 按 DER 编码，得到最终的时间戳数据，放入 SESeal 或 SES_Signature 的 timeStamp 字段。
B.7 时间戳验证过程
验证时间戳需要执行以下步骤：
1. 验证时间戳令牌格式正确性：按 ContentInfo→SignedData 结构解析，验证 DER 编码合法性。若解析失败，则时间戳格式不正确，验证失败。
2. 验证签名值：使用 TSA 公钥证书验证 SignedData 中的签名值，确认 TSTInfo 未被篡改。若签名验证失败，返回错误代码并退出验证流程。
3. 验证 TSA 证书有效性：验证 TSA 证书的信任链、有效期、撤销状态。确认证书扩展密钥用途包含 id-kp-timeStamping（OID: 1.3.6.1.5.5.7.3.8）。若 TSA 证书验证失败，返回错误代码并退出验证流程。
4. 验证摘要匹配：将 TSTInfo 中 messageImprint 的 hashedMessage 与待验证数据（即 SESeal 的 signedValue 或 SES_Signature 的 signature）的杂凑值进行比对。若比对失败，则时间戳不是针对该签名值签发的，验证失败。
5. 验证时间戳时间：确认 genTime 在 TSA 证书有效期内，且 TSA 证书在该时间点上未被撤销（通过 CRL 或 OCSP 检查）。若时间不在有效期内，验证失败。
6. 验证时间戳与关联时间的关系（本标准特有）：
对于电子印章的时间戳：比对 genTime 与印章制作时间 createDate，若 createDate 晚于 genTime，则返回错误代码并退出验证流程。
对于电子签章的时间戳：比对 genTime 与签章时间 timeInfo，若 timeInfo 晚于 genTime，则签章无效，返回错误代码并退出验证流程。
B.8 时间戳与 GM/T 0031-2025 的关联关系
| 使用场景 | 数据来源 | 加盖时间戳的对象 | 时间戳存放位置 | | — | — | — | — | | 电子印章 | 2.1.1.6 | 印章签名值 signedValue | SESeal.timeStamp | | 电子签章 | 2.2.1.6 | 签章签名值 signature | SES_Signature.timeStamp |
时间戳在电子印章/电子签章领域的作用：
时间可信性：为签章行为提供可信的时间证明，防止签章时间被伪造或回溯。
证据链完整性：结合电子印章和电子签章数据，形成完整的时间证据链，满足司法审计与合规追溯需求。
抗抵赖性增强：通过 TSA 的可信时间戳，强化签章行为的不可否认性。
我是利刃信安，网络安全和密码安全、数据安全领域的小白。
如果你觉得今天这篇有收获，欢迎点赞、在看、转发三连，我们下篇见
点赞
在看
转发
如有疑问，请联系： Mannix6
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：利刃信安 利刃信安 利刃信安《一文读懂 GM/T 0031-2025《安全电子签章密码技术规范》》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论