搜索结果: GB/T 20520-2025, GB/T20520-2025, GBT 20520-2025, GBT20520-2025
| 标准编号 | GB/T 20520-2025 (GB/T20520-2025) | | 中文名称 | 网络安全技术 公钥基础设施 时间戳规范 | | 英文名称 | Cybersecurity technology - Public key infrastructure - Specification for time stamp | | 行业 | 国家标准 (推荐) | | 中标分类 | L80 | | 国际标准分类 | 35.030 | | 字数估计 | 22,229 | | 发布日期 | 2025-08-01 | | 实施日期 | 2026-02-01 | | 旧标准 (被替代) | GB/T 20520-2006 | | 发布机构 | 国家市场监督管理总局、国家标准化管理委员会 | GB/T 20520-2025: 网络安全技术 公钥基础设施 时间戳规范
ICS 35.030
CCSL80
中华人民共和国国家标准
代替GB/T 20520-2006
网络安全技术 公钥基础设施
时间戳规范
2025-08-01发布
2026-02-01实施
国 家 市 场 监 督 管 理 总 局
国 家 标 准 化 管 理 委 员 会 发 布
目次
前言 Ⅲ
1 范围 1
2 规范性引用文件 1
3 术语和定义 1
4 缩略语 2
5 时间戳系统组成、内容及申请颁发 2
5.1 时间戳系统组成 2
5.2 时间戳内容 3
5.3 时间戳申请和颁发 3
6 时间戳基本要求 3
6.1 申请和颁发方式要求 3
6.2 可信时间产生要求 4
6.3 时间同步要求 4
6.4 请求和响应消息格式要求 4
7 时间戳系统安全要求 4
7.1 安全管理要求 4
7.2 安全技术要求 6
8 测试评价方法 8
8.1 申请和颁发方式 8
8.2 可信时间产生 8
8.3 时间同步 8
8.4 请求和响应消息格式 8
8.5 时间戳系统安全管理要求 8
8.6 时间戳系统安全技术要求 11
附录A(规范性) 时间戳请求与响应消息格式的ASN.1描述 13
A.1 基本要求 13
A.2 时间戳请求格式 13
A.3 时间戳响应格式 13
A.4 KeyUsage扩展域OID定义 16
参考文献 17
前言
本文件按照GB/T 1.1-2020《标准化工作导则 第1部分:标准化文件的结构和起草规则》的规定
起草。
本文件代替GB/T 20520-2006《信息安全技术 公钥基础设施 时间戳规范》。与GB/T 20520-
2006相比,除结构调整和编辑性改动外,主要技术变化如下:
a) 更改了标准的范围(见第1章,2006年版的第1章);
b) 将“时间戳系统的组成”更改为“时间戳系统组成、内容及申请颁发”(见第5章,2006年版的第
5章、6.4、第8章);
c) 将“时间戳的产生和颁发”更改为“时间戳基本要求”,在“申请和颁发方式要求”中增加了使用
SOAP的方式(见6.1),更改了“可信时间的产生方法”的部分要求(见6.2,2006年版的6.2);
d) 将“对TSA的要求”更改为“通用要求”(见7.1.1,2006年版的8.1),并删除了部分要求[见
7.1.1,2006年版的8.1c)、d)];
e) 删除了“在用户方的保存”(见2006年版的7.1.2);
f) 删除了备份介质、异地备份和备份密码算法的要求[见2006年版的7.2b)、c)、f)];
g) 将“物理安全”“软件安全”更改为“通用安全”,增加了通信网络、区域边界、计算环境和管理中
心相关要求(见7.2.1,2006年版的9.1、9.2);
h) 更改了“签名系统”密码应用安全的要求(见7.2.2,2006年版的9.2.3);
i) 删除了“时间戳数据库”的安全要求(见2006年版的9.2.4);
j) 删除了“保存文件”文件扩展名的要求(见2006年版的8.2.5);
k) 增加了“测试评价方法”,给出了与安全要求对应的测试评价方法(见第8章);
l) 更改了时间戳请求与响应消息格式的ASN.1结构及其描述(见附录A,2006年版的8.4)。
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。
本文件由全国网络安全标准化技术委员会(SAC/TC260)提出并归口。
本文件起草单位:中国科学院软件研究所、中国科学院大学、长春吉大正元信息技术股份有限公司、
中科信息安全共性技术国家工程研究中心有限公司、北京数字认证股份有限公司、中电科网络安全科技
股份有限公司、北京中关村实验室、公安部第三研究所、工业和信息化部网络安全产业发展中心(工业和
信息化部信息中心)、广东省电子商务认证有限公司、北京天融信网络安全技术有限公司、博雅中科
(北京)信息技术有限公司、数安时代科技股份有限公司、同智伟业软件股份有限公司、亚数信息科技
(上海)有限公司、上海市数字证书认证中心有限公司、国网区块链科技(北京)有限公司、陕西省信息化
工程研究院、郑州信大捷安信息技术股份有限公司、杭州海康威视数字技术股份有限公司、长扬科技
(北京)股份有限公司、北京时代新威信息技术有限公司、北京芯盾时代科技有限公司、北京天融信网络
安全技术有限公司、深圳市电子商务安全证书管理有限公司、江南信安(北京)科技有限公司、浙江大华
技术股份有限公司、奇安信网神信息技术(北京)股份有限公司、浙江九州量子信息技术股份有限公司、
中孚信息股份有限公司、工信通(北京)信息技术有限公司、中国电子信息产业集团有限公司第六研究所。
本文件主要起草人:冯登国、张严、张立武、荆继武、杨领波、张宝欣、刘丽敏、胡建勋、赵松、李官麟、
孟佳颖、陈妍、潘毅、陈子雄、肖磉、张超、程科伟、邓钊汉、焦正坤、魏一才、王玉林、高振鹏、杨珂、赵晓荣、
刘为华、王滨、赵华、杜云浩、王在方、梁珍权、汪海洋、陈芳、黄亮、於建江、陈腾、王斌、陈怀凤。
本文件及其所代替文件的历次版本发布情况为:
---2006年首次发布为GB/T 20520-2006;
---本次为第一次修订。
网络安全技术 公钥基础设施
时间戳规范
1 范围
本文件给出了时间戳系统组成、时间戳的内容和申请颁发流程,规定了时间戳安全要求,描述了相
应的测试评价方法。
本文件适用于时间戳系统及其应用的设计、开发与测试。
2 规范性引用文件
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中,注日期的引用文
件,仅该日期对应的版本适用于本文件;不注日期的引用文件,其最新版本(包括所有的修改单)适用于
本文件。
GB/T 16262.1 信息技术 抽象语法记法一(ASN.1) 第1部分:基本记法规范
GB/T 20518-2018 信息安全技术 公钥基础设施 数字证书格式
GB/T 22239-2019 信息安全技术 网络安全等级保护基本要求
GB/T 25069 信息安全技术 术语
GB/T 39786 信息安全技术 信息系统密码应用基本要求
3 术语和定义
GB/T 25069界定的以及下列术语和定义适用于本文件。
3.1
时间戳 timestamp
时间戳令牌 timestamptoken
对包括原始数据信息、签名参数、签名时间等确认后,使用数字签名技术产生的以证明原始数据在
签名时间之前已经存在的数据。
3.2
可信时间 trustedtime
准确的、可信赖的当前时间值。
3.3
时间戳机构 timestampauthority
用来产生和管理时间戳的可信服务机构。
[来源:GM/Z0001-2013,2.101]
3.4
时间戳服务 timestampservice
用以证明原始数据在某一时刻前已存在的服务。
注:由请求方提供数据,时间戳系统为此数据签发时间戳。
[来源:ISO/IEC 18014-1:2008,3.18,有修改]
3.5
请求方 requester
向时间戳机构(3.3)发出申请时间戳请求的实体。
3.6
时间戳系统 timestampsystem
公钥基础设施密码应用技术体系中实现时间戳申请接收、申请合法性验证、时间戳产生和颁发、时
间戳管理等功能的信息系统。
3.7
基于公钥密码技术,具有普适性,可用于提供机密性、完整性、真实性及抗抵赖性等安全服务的基础
设施。
[来源:GB/T 25069-2022,3.212]
4 缩略语
下列缩略语适用于本文件。
TSA:时间戳机构(TimeStampAuthority)
5.1 时间戳系统组成
公钥基础设施密码应用技术体系中的时间戳系统组成见图1,包括以下三个部分。
---可信时间源:时间戳系统的时间来源,负责为系统颁发的时间戳提供可信的时间来源,在颁发
时间戳时,依据可信时间源填写时间。
---签名系统:负责接收时间戳申请,验证申请合法性,产生和颁发时间戳。
---时间戳数据库:负责保存签名系统颁发的时间戳。
图1 时间戳系统组成
5.2 时间戳内容
时间戳中包括以下内容:
---时间戳的版本号;
---表明时间戳生成时的安全策略的唯一标识符;
---生成该时间戳时的可信时间值;
---与可信时间值绑定的数据的杂凑值;
---该时间戳的序列号;
---TSA使用其签名密钥对待签名数据的签名;
---计算数据杂凑时使用的杂凑算法的对象标识符;
---时间戳的可能误差及排序条件(可选项);
---TSA的名称(可选项);
---TSA支持的,与请求方通过申请消息扩展域内提出的额外要求对应的扩展信息(可选项)。
5.3 时间戳申请和颁发
请求方与TSA交互进行时间戳申请和颁发过程包括以下步骤。
a) 请求方向TSA提交申请请求,TSA的签名系统接收到申请请求后,对请求消息的合法性进行
检验。
b) 如果请求消息格式不正确或者由于某种内部原因TSA无法颁发这个时间戳,TSA产生时间
戳失败响应,并在响应中详细描述申请被拒绝的原因。
c) 如果请求消息合法,TSA的签名系统填写时间戳并进行签名,同一个TSA可在不同场景下使
用多个不同签名密钥的私钥进行签名,例如:为适应不同的策略、不同的算法、不同的密钥长度
和不同的性能要求。
d) TSA的签名系统通过可信信道把新生成的时间戳发送给时间戳数据库,由时间戳数据库将其
归档保存,对于申请被拒绝而产生的时间戳失败响应,由TSA本身的策略决定是否将其保存。
e) TSA通过与用户申请方式对应的颁发方式,将新生成的时间戳发给用户。
f) 用户在收到时间戳后,使用TSA的证书验证时间戳的合法性,并检验时间戳内容是否有错误。
如果时间戳不合法或者有错误,用户通过TSA提供的用户反馈渠道向TSA管理者报告异常
情况,如果时间戳有效,用户自行保存此时间戳。
6 时间戳基本要求
6.1 申请和颁发方式要求
TSA应支持采用以下一种或多种方式接收时间戳申请并颁发时间戳。
---通过电子邮件方式。用户使用电子邮件向一个 TSA 指定的电子邮件地址发送时间戳申
请,TSA将颁发的时间戳通过电子邮件返回给用户。
---通过文件传输方式。用户将申请消息编码存储在一个扩展名为.tsr的文件中传送给TSA,
TSA将产生的响应消息编码保存在一个扩展名为.tsr的文件中返回给用户,文件的传送可使
用任意可信赖的方法,例如:SFTP协议等。
---通过套接层连接方式。TSS通过某个端口监听用户发来的申请,而用户在与这个端口建立一
个安全的套接层连接后,与TSS传输申请消息和响应消息。
---通过HTTP/HTTPS方式。用户通过HTTP/HTTPS协议将申请消息发送给TSA,TSA通
过HTTP/HTTPS协议返回时间戳响应消息。
---通过SOAP方式。用户通过SOAP协议将申请消息的 DER编码发送给 TSA,TSA 通过
SOAP协议返回时间戳的DER编码响应消息。
6.2 可信时间产生要求
在产生可信时间时,对时间来源、准确性和安全性保障等方面的要求包括:
a) 可信时间源产生的时间应能溯源至标准时间,可从标准时间的发布机构(例如:国家授时中心
等)使用某种硬件或软件授时方法获得,包括使用无线装置通过长波信号、卫星信号等获得,使
用某种时间同步协议从发布机构指定的网络地址通过安全信道获得等;
b) 在获取标准时间时,应采取完整性保护措施抵御传输错误和篡改攻击;
c) 应根据所采用的授时方法评估所产生的可信时间与标准时间的误差,并公布最大可能误差作
为可信程度的一个标志;
d) 可信时间源可首先使用多种方法分别产生多个时间值,然后依据每种方法的可能误差和可信
程度使用特定方案(例如:计算加权平均)产生最终的时间值;
e) 应采用措施确保从可信时间源到签名系统的传输过程中时间信息的完整性,使得签名系统有
能力发现对时间信息的篡改,并向TSA管理者发出警告。
6.3 时间同步要求
时间戳系统根据可信时间源对各组件进行时间同步时,满足以下要求:
a) 应定期从可信时间源获得可信时间,再根据可信时间进行时间同步;
b) 在获得可信时间后,应根据可信时间对所有组件的时间进行调整,时间同步的优先级应高于其
他操作(例如:时间戳请求的处理);
c) 每次同步的间隔时间不应长于30min,可根据运行策略以及运行的硬件或软件时钟的可靠性
等因素使用更短的同步间隔;
d) 每次同步的间隔时间应可配置;
e) 时间戳系统各个组件应采取统一行动检验并同步时间;
f) 在启动时间戳系统的过程中,可信时间源应在开始提供时间戳服务之前启动,可信时间源启动
后,TSA在开始提供时间戳服务之前应先等待一段时间,以保证开始颁发时间戳时,各组件已
经完成了与可信时间源的同步;
g) 在定期同步时间的过程中,如果获得可信时间失败或者发现收到的时间信息被篡改,应立即停
止时间同步和接收时间戳申请,同时向管理者发出警报并写入审计日志。
6.4 请求和响应消息格式要求
请求者与TSA间发送的时间戳请求和响应消息格式应符合附录A的要求。
7 时间戳系统安全要求
7.1 安全管理要求
7.1.1 通用要求
通用要求包括以下内容。
a) 应拥有可信时间源,并保证除可信时间源以外的其他实体(包括签名系统和时间戳请求方等)
无法对时间源进行控制。
b) 应确保每一个时间戳中都包含一个来自可信时间源的时间值。
c) 在生成时间戳时,应在其中包含表明了该时间戳生成时采用的安全策略的对象标识符。
d) 应只对数据的杂凑值生成时间戳,使用的杂凑函数应拥有唯一的对象标识符。
e) 应检验杂凑函数的标识符,并且验证数据的杂凑值长度是否符合该杂凑函数预期的结果长度。
f) 不应对杂凑值数据进行除杂凑值长度以外的任何检验。
g) 应检验在时间戳请求中表示的杂凑算法是否符合国家或密码行业相关标准,如果无法识别给
出的杂凑算法或该杂凑算法不符合国家或密码行业相关标准,应拒绝提供时间戳服务,并在返
回消息中包含相关信息,例如:设置pkiStatusInfo域中的PKIFailureInfo结构数据为badAlg
(0)。
h) 时间戳内不应包含任何请求方的标识,如果需要鉴别请求方的身份,应另外进行双向身份
鉴别。
i) 应使用专门的签名密钥对时间戳签名,时间戳签名密钥的数字证书格式应符合GB/T 20518-
2018的规定,且证书的扩展密钥用途中应包含id-kp-timeStamping,扩展密钥用途的格式见
GB/T 20518-2018中5.2.4.2.5。
j) 如果请求方在申请消息的扩展域内提出了请求并且时间戳系统支持这些扩展,应在生成的时
间戳内包含相应的额外信息,如果时间戳系统不支持其中的某些扩展,应返回错误信息。
k) 应对用户异常报告具有完备的处理预案,当管理员收到用户的异常报告时,通过检验审计日志
和时间戳数据库等找出错误原因。
7.1.2 时间戳的保存
时间戳保存的要求包括:
a) 时间戳数据库应负责保存由TSA产生的所有时间戳;
b) 时间戳数据库可在一定时间后或者数据库中的数据达到一定的量后,将数据库中的所有或部
分数据转移到他处保存,这一过程应配置为仅能由管理员执行,并且转移后数据的保存应符合
7.1.3对时间戳备份的要求;
c) 对于每一个时间戳,时间戳数据库在保存它们时至少应保存时间戳入库的时间、时间戳的序列
号与时间戳的完整编码数据。
7.1.3 时间戳的备份
时间戳备份的要求包括:
a) 管理员应定期执行备份操作,对时间戳数据库的所有数据进行备份;
b) 备份数据应以方便检索的方式存放;
c) 备份数据的访问应仅在管理员在场并对其进行身份鉴别后才能执行。
7.1.4 时间戳的恢复
时间戳恢复的要求包括:
a) 应支持通过时间戳备份数据恢复时间戳;
b) 时间戳恢复操作应仅在管理员在场并对其进行身份鉴别后才能执行。
7.1.5 时间戳的检索
时间戳检索的要求包括:
a) 应向请求方提供能方便地检索时间戳的方法,使请求方可通过网络或者面对面的方式检索和
获得时间戳;
b) 向请求方提供的可检索的时间戳应包括时间戳数据库中保存的时间戳和以前备份的时间戳;
c) 应至少支持通过以下三种信息检索时间戳,并满足下列要求:
● 根据时间戳入库的时间检索,该方式可返回多个结果,再由用户自行选择;
● 根据时间戳的序列号检索,该方式应返回至多一个结果;
● 根据时间戳的完整编码检索,该方式应返回至多一个结果。
7.1.6 时间戳的删除
时间戳删除的要求包括:
a) 应支持对时间戳数据库中错误时间戳数据的删除;
b) 所有即将从时间戳数据库中删除的时间戳数据应先进行备份,因删除而备份的错误数据应与
正常备份数据区分并单独存放,并符合7.1.3中对时间戳数据备份的要求;
c) 应及时通过公开渠道公布所有被删除时间戳的详细信息;
d) 时间戳的删除操作应配置为仅能由管理员执行。
7.1.7 时间戳的销毁
在确定时间戳已经丧失其价值后,可完全销毁时间戳,时间戳的销毁包括从时间戳数据库和时间戳
备份中同时删除。时间戳销毁的要求包括:
a) 时间戳应只在TSA证书失效后被销毁;
b) TSA可根据策略决定时间戳的保存时间,这一保存时间应足够长,以确保在超过保存时间
时,时间戳已丧失使用价值,TSA应在用户申请时间戳时向用户详细说明时间戳保存时间的
策略;
c) 时间戳的销毁操作应配置为仅能由管理员执行。
7.1.8 时间戳的查看
应向请求方提供查看已颁发的时间戳的方式,使请求方可凭借此方法查看时间戳中所有可查看的
内容,例如:提供查看软件等。
7.1.9 时间戳的验证
时间戳验证的要求如下。
a) 应向请求方提供对时间戳进行验证的方式,使请求方可对已颁发的时间戳的正确性和有效性
进行验证,例如:提供验证软件或者通过互联网验证等。
b) 应向用户提供TSA证书及验证该证书所需的必要数据,确保验证时间戳前,用户能验证TSA
证书的有效性。
c) 提供的验证服务应包括对以下内容的验证:
● 使用TSA证书验证用户给定的时间戳是否是由该TSA签发;
● 使用用户提供的时间戳和源文件,验证该时间戳是否对应该文件。
7.2 安全技术要求
7.2.1 通用安全
时间戳系统的物理环境、通信网络、区域边界、计算环境和管理中心安全应满足 GB/T 22239-
2019中第7章的要求。
7.2.2 签名系统
签名系统的密码应用应满足GB/T 39786第二级或以上要求。
7.2.3 时间戳文件保存
通过文件对时间戳进行保存时,存储时间戳申请和响应消息内容的文件中应只包含消息的DER编
码,不应有额外的消息头和消息尾。
7.2.4 日志审计
日志审计的要求包括以下内容。
a) 签名系统应通过审计功能组件提供日志审计功能,对审计功能的启动和结束以及表1中的事
件产生审计记录。
b) 审计记录应包括事件的日期和时间、用户、事件类型、事件是否成功,以及表1中附加信息栏中
的相应内容。
表1 审计事件及审计记录内容
功能 事件 附加信息
安全审计
对审计变量的修改
对审计记录进行删除或尝试删除的操作
审计日志签名
审计日志的数字签名、杂凑值或消息鉴
别码
本地数据输入 所有安全相关数据的输入
远程数据输入 所有被系统接受的安全相关信息
数据输出 对关键或安全相关信息进行输出的请求
私钥载入 组件私钥的载入
私钥存储
对为密钥恢复而保存的证书主体私钥的
读取
公钥的输入、删除和存储 对公钥的改变 公钥和与公钥相关的信息
私钥和秘密密钥的输出
对私钥和秘密密钥的输出,包括一次性会话
密钥
时间戳申请 所有的时间戳申请请求
若申请成功,保存申请请求和所产生的
时间戳的拷贝
若申请失败,保存申请请求和所产生的
时间戳响应的拷贝
组件的配置 所有与安全相关的配置
可信时间的获取和同步 根据可信时间源同步时间
可信时间与本地时间不匹配时,对本地
时间的改变
同步过程中发生的所有错误
审计日志时间戳生成 为审计日志生成时间戳 生成的时间戳
c) 审计记录中的秘密密钥、私钥和其他安全相关的秘密参数不应以明文形式出现。
d) 审计功能组件应能将可审计事件与发起该事件的系统用户身份相关联。
e) 审计功能组件应为审计员提供查看日志信息的能力,并以适于阅读和解释的方式显示。
f) 审计功能组件应在审计事件存储过程中防止对审计记录的非授权修改,并可检测对审计记录
的修改。
g) 当审计日志存储已满时,审计功能组件应能阻止除由管理员发起以外的所有审计事件的发
生,以防止审计数据丢失。
h) 审计功能组件应确保每一条审计记录都具有正确、可信的时间。
i) 审计功能组件应定期为审计日志生成时间戳,时间戳中签名的对象包含上次生成时间戳后加
入的所有审计日志条目以及上次生成的时间戳的值,为审计日志生成时间戳的周期应可配置。
8 测试评价方法
8.1 申请和颁发方式
申请和颁发方式的测试评价方法......
|