GBT 20520-2006 信息安全技术 公钥基础设施 时间戳规范

TSA系统各部件根据可信时间同步自身的时间，这一行为应满足下列条件： a） 在获得可信时间后，TSA应迅速根据可信时间对所有部件的时间进行调整（尤其是最关键的 签名系统），TSA应该保证这一过程尽可能的快，并且尽可能保证其不被打断。 b) 为了保证TSA各个部件的时间精确性，TSA应该定期从可信时间源获得可信时间，再根据可 信时间检查自身时间，与可信时间源保持时间同步。 ) 每次同步的间隔时间应该是一个比较短的时间。具体时间视TSA的运行策略以及运行TSA 的硬件或软件时钟的可靠性而定，但应取得尽可能大的安全性，并且不应长于30min。 d) 每次同步的间隔时间应该是可配置的，在TSA运行的策略和环境变化后，可以调整这一时间 间隔以取得尽可能大的安全性。 e) TSA各个部件应该采取统一行动检查并同步时间，不允许出现一个部件检查同步了而其他部 件却不行动的情况。 ） 在启动TSA系统的过程中，可信时间源应是第个启动的部件。而且在TSA开始工作之前， 时间同步应该先进行一段时间，以保证TSA开始颁发时间戳时，各部件的时间已经同可信时 间源同步过了。 g) 在定期同步时间的过程中，如果获得可信时间失败或者发现收到的时间信息被篡改，TSA系 统应该立即停止接受时间截申请和时间同步，同时向管理者发出警报并写入审计日志。

无论TSA的运行方式使用6.1中说明的哪一种方法，整个申请和颁发时间戳的过程至少应该包括 下基本过程： a） 用户通过6.1中说明的一种方法，向TSA提交申请请求，请求消息的格式应该符合第8章的规定。 b) TSA的签名系统接收到申请请求后，根据第8章中对时间戳格式的说明，对请求消息的合法 性进行检查。

试验、检测与鉴定标准分享网WWDZTXxWCom免费下室

时间戳的失败响应，其格式也应该遵循第8章的规定。在其中TSA应该详细填写申请被拒绝 的原因。 d）如果请求消息合法，且系统也正常运转，TSA的签名系统就应该根据第8章中说明的时间戳截 格式，填写正常的时间截并签名。 e）TSA签名系统通过可信通道把新生成的时间戳发送给时间戳数据库，由时间戳数据库将其归 档保存。而由于申请被拒绝而产生的时间戳失败响应，应该由TSA本身的策略决定是否将其 保存，本标准不作硬性规定。 f）TSA通过与用户申请方式对应的颁发方式，将新生成的时间戳发给用户。 g） 用户在收到时间戳后，应该使用TSA的证书验证时间戳的合法性，并检查时间戳内容是否有 错误。如果时间截不合法或者有错误，用户应该立即向TSA管理者报告异常情况，TSA机构 应该提供一个用户反馈渠道，在用户发现异常情况时可以通过此渠道通知管理员。如果时间 戳一切正常，用户可以自行保存此时间戳，以备后用。 h）如果管理员收到用户的异常报告，应该立即检查审计日志和时间戳数据库，找出错误原因所 在。TSA应该对这种情况准备有完备的处理预案。

7. 1 时间戳的保存

7.1. 1在TSA方的保存

在TSA系统中，时间戳数据库应该负责保存由此TSA产生的所有时间戳。该时间戳数据库应符 合9.2.4对数据库的要求。 考虑到空间限制，时间戳数据库可以在一定时间后或者数据库中的数据达到一定的量后，将数据库 中的所有数据转移到它处，而将其自身清空。这一过程只能由管理员执行，并且转移后的保存要符合 7.2对时间戳备份的要求。 对于每一个时间戳，时间戳数据库在保存它们时至少要保存以下相关信息： a）时间戳入库的时间； b）时间戳的序列号； c）时间戳的完整编码。 除此之外，对于时间戳的保存，应考虑今后可能的用途，如用户查询、取证，存储的必要信息应便于 今后使用。

7.1.2在用户方的保存

在用户收到时间戳后，用户 文件中。由用户自行保证时间戳的安全性，如 果保存的时间戳发生了问题，用户可以向 购申请取回自己的时间载

时间戳应按如下要求备份： a) 每隔一定时间，管理员应该备份时间戳数据库的所有数据； b) 备份所使用的介质应符合9.1的要求； c) 备份应该使用异地备份的方式； d) 备份数据应该是以方便检索的方式存放； e) 备份数据的访问应在有管理员在场的时候进行； f) 备份数据不一定需要加密或签名，但如果使用，所选择的算法应符合国家密码管理部门的相关 规定。

TSA应该给用户提供一个能够方便的检索时间截的环境，使用户可以通过网络或者面对面的方式 检索和获得时间戳。 TSA提供给用户检索的时间截应该不仅仅是时间截数据库中保存的时间截，还应该包括以前备份 的时间戳。 TSA应该至少支持通过以下三种信息检索时间戳： a） 根据时间戳入库的时间检索，允许检索出多个结果，再由用户自行选择； b）根据时间截的序列号检索，由于序列号唯一，这种检索应该只有唯一一个结果； C 根据时间戳的完整编码检索，这种检索也应该只有唯一一个结果 时间戳的检索结果可以通过6.1的颁发方式发给用户，也可以通过另外的可靠方式，如使用IC卡、 光盘等，让用户带回。

7.4时间戳的删除和销毁

当TSA系统由于内部错误或者外部攻击导致产生错误的时间截时，应该允许删除时间戳数据库中 的错误数据。 所有从时间戳数据库中删除的时间戳应先进行备份，以备以后审计查询。这种备份数据应与正常 备份数据区分开来，单独存放，但同样也需要符合7.2中对备份的要求。 所有遭到删除的时间戳应在第一时间在公开渠道公布，如互联网等。公布的时间戳信息应该尽可 能的详细。 时间戳的删除只能由TSA管理员操作进行

7.4.2时间截的销毁

在确定时间截已经丧失其价值后，TSA可以完全销毁时间戳截，即不仅从时间截数据库中删除，也从 所有时间戳备份中删除。 在时间戳生成后，应经过足够长的时间，时间截才允许被销毁。这一保存时间应足够长，长到可以 确定该时间戳已丧失使用价值。此外，保存时间也可以由TSA的策略决定，但TSA应在用户申请时间 戳时向用户详细说明。但是无论采用什么方法决定保存时间，时间戳都只能在TSA证书失效后销毁。 时间戳的销毁只能由TSA管理员操作进行

7.5时间戳的查者和验证

TSA应该给用户提供一个方便安全的方法查看其颁发的时间截，例如提供一个查看软件等。 可以凭借此方法查看时间戳中所有可查看的内容

7.5. 2 时间载的验证

TSA应该给用户提供一个方便安全的方法对其颁发的时间戳进行验证，例如提供一个验证软件或 者通过互联网验证等。 验证前，用户应该可以通过CRL或OCSP协议先验证TSA证书的有效性。 TSA提供的验证服务应该包括以下两种： a）使用TSA证书验证用户给定的时间戳是否是由该TSA签发； b）用户提供时间戳和源文件，验证该时间戳是否是该文件的时间戳

8. 1 对 TSA 的要求

完成一个完整的时间戳，TSA系统应满足下列条件： a）拥有一个可信时间源，应满足9.2.2的要求，可信时间的产生要满足6.2的要求：

标准分享网WWDZTXxWCom免费下室

b）在每一个时间截里都要包含一个可信时间值； c）在每一个新生成的时间戳里都要包含一个一次性随机整数（nonce域）； d）！ 只要可能，当从个请求者处收到一个合法请求时，就要根据这个请求生成一个时间截； e) 当时间戳生成时，要在其内包含一个唯一的标识符，这个标识符表明了时间戳生成时的安全 策略； 只在数据的散列（Hash)值上盖时间戳，散列函数拥有一个唯一的对象标识符（OID)： g) 要能够检查单向散列函数的标识符，并且验证数据的散列值长度是否符合该散列函数的结果 长度； h) 除了g)中要求的对散列值长度的检查外，对于输入的散列值数据不做任何其它检查； i）不 在时间戳内不包含任何请求方的标识； 用专门的密钥对时间戳签名，在密钥相应的证书里应该说明该密钥的这个用途； k) 如果请求方在申请消息的扩展域内提出了一些额外要求并且TSA支持这些扩展，TSA就应 该在时间截内包含相应的额外信息。反之，如果TSA不支持这些扩展，就应该返回一个出错 信息。

时间戳中使用的时间应是UTC时间。其精度应至少精确到秒。 语法结构为：YYYYMMDDhhmmssL.s...JZ。 例如：20031101001326.34352Z。 各个位解释如下： a）YYYY为年份，应是4位数年份如2003； b) MM为月份，如果月份只有一位数，要加上一个前导0，如01、11； c) DD为日，如果只有一位数，要加上前导0，如01、20； d) hh为小时，如果只有一位数，要加上前导0，如00、23： e) mm为分钟，如果只有一位数，要加上前导0，如05、59； f）Ss为秒，如果只有一位数，要加上前导0，如01、59； g) ［.S..］是可选的，表示秒的小数部分。小数点如果出现应是“.”，秒的小数部分如果出现，应 把后面跟的0都省略掉，如果秒的小数部分等于0，则应全部都省略掉，小数点也应省略掉； h) 最后的Z表示这是一个UTC时间。 午夜（格林威治时间）应该表示成：“YYYYMMDDO00000Z”，其中的“YYYYMMDD”表示午夜之 的这一天，

8.4时间戳申请和响应消息格式

时间戳服务申请消息格式如下：

8.4.2响应消息格式

TSA在收到申请消息后，无论申请成功还是失败，都要给请求方发回一个响应消息。该响应 或者是正确的时间戳截，或者是包含了失败信息的时间截。时间截响应消息的具体格式如下：

TimeStampResp::=SEQUENCE status PKIStatusInfo, timeStampToken TimeStampToken OPTIONAL) 响应消息中的status具体定义如下： PKIStatusInfo::=SEQUENCE{ status PKIStatus, statusString PKIFreeText OPTIONAL,

faillnfo PK s有如下定义： :=INTEGER( granted grantedWithMods rejection waiting revocationWarning revocationNotificati

faillnfo PKIFailurelnfo OF 其中PKIStauts有如下定义： PKIStatus ::=INTEGER ( granted (0), grantedWithMods (1), rejection (2), waiting (3), revocationWarning (4), revocationNotification (5)

标准分享网WWDZTXxWCom免费下室

(0), (1)， (2)， （3）， （4)， (5)

标准分享网WWDZTXxWCom免费下室

当需要保存时间戳申请和响应消息在文件中时，文件里应只包含消息的DER编码，且不能有额外 的消息头和消息尾。 保存在文件中时，时间戳申请消息应该存放在一个扩展名为，tsq的文件中，时间戳响应消息应该 存放在扩展名为.tsI的文件中。

8.6所用MIME对象定义

8.6.2HTTP传输

<响应消息的DER编码

8.7时间戳格式的安全考虑

GB/T20520—2006

时间截系统的物理安全要求应遵循GB/T20271一2006中4.1的相关要求，保障环境、设备和记录 价质的安全。

TSA的时间源应是国家标准时间，其或者就是国家权威时间部门发布的时间，或者是用国家权威 时间部门认可的硬件和方法获得的时间。 无论采用什么方法获得可信时间，从可信时间源到签名系统的时间传递过程中，应采用严格措施保 证时间信息的完整性，保证其没有被任何人篡改。即使有入侵者中途修改了时间信息，签名系统应有能 力发现时间信息已被修改，同时向TSA管理者发出警报。 用于从时间源接收时间的软件也应检查时间的连续性、完整性，确保其真实有效，

9. 2. 3签名系统

签名系统对密钥的所有使用应遵照国家密码管理局有关规范执行。 对签名系统的访问，应有严格的访问控制，包括对密钥的访问控制也应遵照国家密码管理局的有关 规范。 签名系统要有完整的审计系统，符合9.2.5对审计的要求

9.2.4时间截数据库

时间戳数据库的安全等级应达到或高于GB/T20273一2006中规定的第二级“系统审计保护级 要求。

9.2.5. 1审计数据产生

TSA的签名系统应该有完善的审计功能部件，它应对下列事件产生审计记录 a）审计功能的启动和结束；

标准分享网WWDZTXxWCom免费下室

对于表1中的每一个事件高层标准规范范本，其审计记录应包括：事件的日期和时间、用户、事件类型、事 件是否成功切， 以及表中附加信息栏中要求的内容。 日志记录中不得出现明文形式的私钥、非对称密钥和其他安全相关的参数。 审计功能部件应能将可审计事件与发起该事件的系统用户身份相关联，

9.2.5.2审计查阅

审计功能部件应该为审计员提供查看日志所有信息的能力。 释的方 式向阅读者提供日志信息

9.2.5.3审计事件存储

审计功能部件应具有以下能力： a）受保护的审计踪迹存储，要求审计踪迹的存储受到应有的保护，能防止对审计记录的非授权修 改，并可以检测对审计记录的修改； b） 防止审计数据丢失，要求当审计踪迹存储已满时，审计功能部件应能够阻止所有审计事件的 发生，除非该事件是由审计员发起的

9.2.5.4可信的时间

9.2.5.5审计日志签名

对审计日志的签名应遵循如下规范： a 审计功能部件应定期让TSA给审计日志加盖时间戳； b) 时间戳签名的对象是从上次生成时间戳后加人的所有审计日志条目以及上次签名的时间戳 的值； c 审计功能部件给审计日志加盖时间戳的时间周期应该是可以配置的； d）对审计日志做时间截的事件应写入日志中建筑施工图集，时间截应包含在其中。