什么是时间戳服务器(TSA)?
全面指南
那个从不阅读你文件的公证人:RFC 3161 如何将哈希值转化为时间证明。
03:12:07 UTC
位于无窗房间里的一台构建服务器完成了固件版本的编译,对其进行了签名,然后转而处理下一项任务。没有人正在关注。未来六年里,再也不会有人想起这个文件了。
随后,监管机构发来一封信函。签名证书早已过期。在此期间,某处有一把密钥被撤销了。摆在桌面上的问题只有三个字:这是什么时候签的?
服务器自身的日志显示是3月。这当然没错。它是房间里唯一的证人,而且它所作的证词正是关于它自身的。
这就是时间戳服务器存在的意义——为了解决这个问题。
简而言之
在某个精确时刻,一个可信的时间戳会通过加密方式将您数据的哈希值与一个经过独立验证的时间点绑定,从而生成可验证的证明,表明该数据最迟在该时刻之前就已存在。此后若更改其中任何一位,验证过程都会将其暴露出来。
什么是时间戳服务器?
试想一位从不阅读合同的公证员。你将一枚密封的指纹印章推过桌子。公证员瞥了一眼只遵循协调世界时(UTC)而非你个人时间的时钟,并将两者都写在一张已签名的收据上。随后你离开,而公证员早已忘记你曾到过那里。多年后,那张收据依然能向任何人证明——无需任何人联系公证员——就在这一确切时刻,这枚确切的指纹确实存在过。
该公证机构是一个时间戳服务器。它不依赖于创建或签署文件的机器上的时钟,而是借助独立的时间源,并签发一个经过数字签名的时戳令牌:这是一种证据,即使在事件发生很久之后,任何持有正确信任锚点的人都可以离线进行验证。
在基于标准的时间戳技术中,服务器背后的实体是时间戳授权机构(TSA)。RFC 3161定义了请求如何到达 TSA、响应的格式,以及该机构必须满足的安全要求。
值得信赖的时间戳是数字签名、软件发布、商业记录、知识产权、审计证据和电子交易的基础:凡是其完整性日后可能需要经受交叉质询检验的事物,都离不开它。
时间戳服务器、TSA、TSU、时间戳服务:各指什么?
| 术语 | 是什么 | 在哪里能见到它 |
|---|---|---|
| 时间戳服务器 | 网络端点。它接受时间戳请求,并返回一个带签名的响应。 | 您粘贴到签名工具或构建管道中的 URL。 |
| 时间戳授权机构(TSA) | 端点背后的可信实体,其政策、控制措施和审计机制为其签发的每个令牌提供保障。 | RFC 3161 中的正式术语,以及实践声明中指明的当事方。 |
| 时间戳单元(TSU) | ETSI对存储单个活动令牌签名密钥的硬件和软件的称谓。一个TSA可管理多个TSU。 | ETSI EN 319 421,以及令牌内的证书中。 |
| 时间戳服务 | 整个系统:TSU、HSM保护的密钥、可追溯至UTC的时间源、策略、监控、审计和验证基础设施。 | 采购文件和信任服务审计。 |
为什么普通的计算机时间戳不够用?
每个文件系统都会记录日志。每条数据库记录都有一个“created_at”字段。每个签名应用都能在签名旁打印日期。而这些日志无一例外都是由那些日后其诚信可能受到质疑的一方所记录的。只需执行一次“touch -d”命令,就能重写文件的修改时间;系统时钟则听命于拥有相应权限的人。
普通的时间戳只能告诉你系统记录了什么,却无法证明所记录的时间值得信赖。可信时间戳则引入了新的“见证者”:一个独立的服务、一个签名令牌,以及与数据哈希值之间的加密绑定。
| 普通时间戳 | 可信加密时间戳 |
|---|---|
| 通常由设备或应用程序生成 | 由可信的时间戳服务机构签发 |
| 可能取决于本地系统时钟 | 使用一个权威的、可追溯至UTC的时间源 |
| 可作为可编辑元数据进行存储 | 通过加密方式与数据的哈希值绑定 |
| 不一定能反映后续的变更 | 验证可显示数据是否仍与带时间戳的哈希值匹配 |
| 信任在很大程度上取决于源系统 | 信任基于TSA的签名、证书链、政策和控制措施 |
RFC 3161 时间戳服务器是如何工作的?
一笔以毫秒为单位衡量的交易,其后果却以年为单位来衡量。
RFC 3161 将时间戳协议定义为一种简单的请求-响应交互。以下是整个流程,从最初的哈希计算到验证,而验证可能在所有相关方都已离开很久之后才进行。

图1. RFC 3161协议的交互过程,从本地哈希计算到数年后的验证。只有摘要会通过网络传输。
1 · 客户端对数据进行哈希处理
加密哈希是数据的“指纹”:只要改变一个比特,只要使用任何可靠的算法,摘要就会发生无法辨认的变化。客户端会对文档、软件对象、交易、签名值或记录进行哈希运算。具体对什么进行哈希取决于工作流(对于签名时间戳而言,就是签名本身),而这一选择恰恰决定了最终生成的令牌能够证明什么。
2 · 客户发送的是印章,而不是文件
客户端构建一个 TimeStampReq:包括版本号、messageImprint(哈希算法标识符加上摘要),以及可选字段,例如请求的策略 OID、将响应与该请求绑定的随机非ce,以及请求 TSA 将其签名证书嵌入令牌中的 certReq 标志。通过 HTTP 传输时,该请求以 POST 方式发送,内容类型为 application/timestamp-query;RFC 3161 还描述了其他传输方式。
原始数据绝不会离开您的环境。TSA 对数据快照进行时间戳标记,而非对内容本身进行标记,这既是一项保密功能,也能节省带宽。
3 · TSA 负责铸造该代币
TSA 会决定是否接受该请求(哈希算法是否符合要求,摘要长度是否匹配?),读取其内部时钟,分配一个唯一的序列号,并构建一个TSTInfo 结构。随后,它使用专为此目的保留的密钥,将该结构作为 SignedData 进行签名,并将结果封装在一个带有状态信息的 TimeStampResp 中。其中的 TimeStampToken 才是关键部分。

请注意签名证书中内置的规范要求。RFC 3161 规定,TSA 的密钥必须专用于时间戳,其证书必须包含 id-kp-timeStamping 扩展密钥用途,该用途应标记为“关键”,且不得与其他用途并存。验证者若发现任何其他情况,应立即终止验证。
4 · 纪念币回到了家
客户端收到响应后,谨慎的客户端不会盲目信任该响应。它会检查状态,确认非ce(一次性编号)和印记与自己发送的内容一致,并在基于该响应构建任何内容之前验证令牌。随后,该令牌将与其所保护的对象一同传输:或作为未签名的属性嵌入 CMS 或 CAdES 签名中,或作为文档时间戳附加在 PDF 文件内,或作为独立响应文件与源文件并存。
5 · 验证员稍后会进行核查
多年后,验证器会按照固定的顺序处理该令牌:
- 使用令牌中指定的算法对数据进行哈希处理,并将哈希值与 messageImprint 逐字节进行比对。
- 使用 TSA 证书验证 TSTInfo 上的 CMS 签名。
- 验证 TSA 链与信任锚之间的关联,并评估其在相关时间点的有效性和撤销状态。
- 请根据您的验证策略所接受的标准,核对该策略的OID及其准确性。
- 如果请求是在生产环境中发出的,请确认非ce值。
如果重新计算出的哈希值不匹配,其结果虽然微妙,但值得明确说明:该令牌本身是真实的,但它所代表的是另一组数据。它无法验证此版本文件的真实性。
在终端中试一试
以上所有内容只需四条 OpenSSL 命令即可完成。下方的 TSA URL 仅为占位符;请替换为您的服务提供商的端点。
# 1. Build a request: SHA-256 imprint, ask the TSA to embed its certificateopenssl ts -query -data release.bin -sha256 -cert -out req.tsq# 2. Send it over HTTP (placeholder endpoint)curl -s -H "Content-Type: application/timestamp-query" \ --data-binary @req.tsq https://tsa.example.com/ -o resp.tsr# 3. Read the responseopenssl ts -reply -in resp.tsr -text# 4. Verify against the original data and the TSA's trust chainopenssl ts -verify -data release.bin -in resp.tsr -CAfile tsa-chain.pemRFC 3161 时间戳能证明什么?
这里精确性至关重要,因为过分夸大往往会导致时间戳在争论中站不住脚。
RFC 3161 时间戳可作为证据,证明特定哈希所代表的数据在令牌记录的时间之前或当时就已经存在。它还允许验证者检验,后来提交的数据是否与最初加盖时间戳的数据生成相同的哈希值。
像律师那样解读这一主张:先看“之前”这个词。代币中的 genTime 是一个上限,而非出生证明:数据可能更早,而代币无法说明具体早了多少。时间戳告诉你某物可能产生的最晚时刻,而非其实际产生的时刻。
时间戳本身并不能:
- 确定原始文件的创建者;
- 证明该文件中的每一条陈述都是正确的;
- 证明某人理解或同意其内容;
- 防止某人创建修改后的副本;
- 取代身份认证;或者
- 自动满足所有法律或监管要求。
这些问题需要采取其他控制措施:数字签名、身份验证、审计追踪、访问控制、数据保存服务或合格的信任服务。
时间戳服务器与证书颁发机构(CA)是一回事吗?
两个机构,两个不同的问题。
不。证书颁发机构(CA)负责签发和管理将公钥与身份或其他主体信息绑定的证书。时间戳机构则负责签发将数据哈希值与可信时间绑定的时间戳。两者虽均在同一PKI工具集(证书、签名密钥、策略和信任链)内运行,但所履行的信任职能却各不相同。
证书有助于确定谁或什么持有该密钥。可信时间戳有助于确定该数据何时存在。
这里有一个值得细细品味的转折:TSA 也是 CA 领域的客户之一。其签名证书由一家 CA 签发,拥有自己的有效期和撤销状态。因此,令牌的使用寿命取决于其底层的 PKI,而这正是“长期验证”这一话题所探讨的核心所在。
时间戳如何支持数字签名?
数字签名将签名人或签名系统与特定数据关联起来,并能检测到后续的修改。时间戳则提供了关于已签名数据或签名何时存在的独立证据。
当签名证书随后过期或被撤销时,这一机制的价值便显现出来。时间戳使验证者能够提出正确的问题——即该证书在当时是否有效,而不是错误的问题——即它现在是否有效。验证结果是否合格,取决于签名格式、验证策略、应用程序、证书状态信息、时间戳类型、算法强度以及所需验证证据的保存情况。GlobalSign 将其时间戳服务描述为:在签名证书过期后,仍能支持对已签名文档和代码的持续验证。
根据《eIDAS条例》,什么是合格的电子时间戳?
同样的礼节,身着司法制服。
根据 《欧洲电子信任服务条例》(eIDAS)框架,电子时间戳不得仅因其电子形式而被否认其法律效力或作为证据的可采性。合格的电子时间戳则更进一步。其所标示的日期和时间以及与其关联的数据的完整性均享有准确性推定(第41条),且必须在各成员国范围内得到认可。
如何获得该资格?第42条规定了三项要求,合格的信托服务提供商(QTSP)必须能够证明自己符合这些要求:
- 时间戳将日期和时间与数据绑定在一起,从而合理地防止无法被察觉的篡改。
- 它基于一个与协调世界时(UTC)同步的精确时间源。
- 该文件已使用QTSP的先进电子签名或电子印章签署或加盖,或采用同等效力的方式签署或加盖。
实际上,ETSI 标准将这些条款转化为可审计的控制措施:EN 319 421 规定了时间戳签发服务提供商的政策和安全要求,而 EN 319 422 则规定了时间戳协议和令牌配置文件。其中有一点值得注意:如果时间戳授权机构(TSA)的时钟偏差超出了其声明的精度范围,符合标准的服务将停止签发令牌,而不是进行估算。
欧盟委员会的“可信列表浏览器”允许您按服务提供商名称和信任服务类型(包括时间戳服务)搜索各国的可信列表。这是验证哪些服务被列为合格服务的权威途径。GlobalSign nv/sa 针对其 eIDAS 合格时间戳服务发布了一份专门的实践声明,其中声明该服务符合 ETSI EN 319 421 标准。
时间戳服务器的常见用途
四个因时间证据而改变结果的场景。
代码签名:比证书有效期更长的签名
时间戳记录了已签名软件的存在时间,因此,在证书有效期内签名的构建版本,日后仍可根据平台的验证策略和证书吊销状态进行评估。
知识产权记录
对设计稿、手稿、研究数据集或源代码树进行哈希计算,并为该哈希值添加时间戳,即可获得证明特定版本在指定时间点确实存在的证据。时间戳本身并不能确立法律上的所有权,但可以作为强有力的时间相关证据。
审计日志和交易
在记录的完整性和顺序至关重要的情况下,应在记录本身添加时间戳,或者定期为哈希链日志的头部或默克尔树的根节点添加时间戳,以便其下方的所有内容都能继承一个可验证的时间。
受监管的记录
法律、金融、政府、医疗保健、制造业和档案管理等工作流程可能需要提供可靠的证据,以证明记录何时存在或何时签署。具体要求取决于管辖区域、法规和验证政策。
组织在选择时间戳服务时应关注哪些方面?
应将其视为信任基础设施,而非添加到签名工具中的一个 URL。
- 标准支持。 确认是否支持 RFC 3161 以及与您的签名格式相匹配的配置文件(CAdES、PAdES、XAdES、代码签名工具链)。
- 已记录的政策和实践。请阅读时间戳政策、实践声明、证书政策和服务文档。
- 密钥保护。请询问TSU签名密钥是如何生成、存储和使用的,以及相关控制措施是否符合您的使用场景所要求的保证级别。
- 可靠的时间。应寻找可追溯至协调世界时(UTC)的时间源、有文档记录的同步控制措施,以及在时钟发生漂移时的明确行为。
- 可用性和容量。时间戳功能通常位于自动化签名、构建管道和大容量工作流的“热路径”上。延迟、吞吐量、监控和支持是运营必需的要求,而非可有可无的附加功能。
- 验证与长期支持。规划在记录存续期间,如何保留和验证令牌、TSA证书、证书状态信息及策略。
- 集成选项。检查与签名应用程序、文档系统、构建流程、API 以及企业工作流的兼容性。
《欧盟人工智能法案》第50条:可信时间何时适用
《欧盟人工智能法案》第50条自2026年8月2日起生效。该条文规定的透明度义务分为两个角色,将它们区分开来很有必要:
- 生成式人工智能系统的提供者必须确保,合成的音频、图像、视频和文本输出以机器可读的格式进行标注,并可被识别为人工生成或经过处理的内容(第50条第2款)。与人直接交互的系统提供者还必须确保该交互具有透明性(第50条第1款)。
- 发布者必须披露为向公众通报公共利益相关事项而发布的深度伪造内容以及由人工智能生成或篡改的文本(第50条第4款),并须告知那些受到情绪识别或生物特征分类系统影响的人员(第50条第3款)。
《人工智能数字综合法案》(欧盟法规(EU)2026/1744,自2026年7月27日起生效)保留了第50条的规定,但针对机器可读标识义务设定了较短的过渡期: 2026年8月2日前已在欧盟市场投放的生成式系统,须在2026年12月2日前落实第50条第2款规定的标识要求;而自2026年8月2日起投放市场的系统,则必须从一开始就符合该要求。
欧盟委员会于2026年6月10日发布的关于人工智能生成内容标记和标签的最终《行为准则》属于自愿性质。该准则并未规定特定的技术方案,而是引导服务提供商采用分层标记方式,其中加密元数据是其中一层。
时间戳是在什么地方起作用的?
第50条并未提及时间戳,且时间戳本身也不会对内容进行标记。它所能做的是回答每个审计最终都会提出的问题:何时?将内容哈希与其标记元数据一同封存于一个独立的时间戳之下,你就掌握了防篡改的证据,证明这一带有该标记的输出结果最迟在该时刻之前就已存在。
PKI爱好者会发现这种模式在实际应用中很常见。C2PA内容凭证是媒体上安全来源元数据的常见载体,它是一种经过COSE签名的清单,可在签名的未受保护的头部中携带一个RFC 3161令牌。正是该令牌使得清单签名在签名证书自身有效期结束后仍可验证。请确认您选择的TSA(信任服务提供商)被您所在生态系统所依赖的验证器和信任列表所接受。
在您的数字工作流程中融入可信时间
随着越来越多的文件、软件、交易和审计记录以数字形式产生,确定数据的存在时间变得与保护签署者身份以及确认数据是否被篡改同样重要。
GlobalSign 提供符合 RFC 3161 标准的 时间戳服务,适用于文档、代码签名和合格时间戳等使用场景,并配有已发布的时间戳实践文档作为支持。
请联系 GlobalSign,了解如何将可信时间戳集成到您的签名、合规或数字证据工作流程中。
编者按:本文提供一般性技术信息,不构成法律建议。各组织应针对不同司法管辖区和具体应用场景,评估适用的法律、法规、证据要求及保存政策。