時間戳機構（TSA）整合：運作原理與已簽署檔案為何需要它

簡明答案：甚麼是 TSA 整合

時間戳機構（TSA）整合，是把你的簽署工作流程連接到一個受信任的第三方，由其簽發經加密簽名的證明，確認某個簽名——或某段內容——在何時已經存在。TSA 不會接觸你的檔案：你的系統先在本地為內容計算雜湊（通常是 SHA-256），只透過 RFC 3161 協定傳送該雜湊值，然後收到一個已簽名的時間戳權杖（token），把雜湊值與受信任的 UTC 時間綁定。把權杖附加到簽名上，日後便能證明該內容在該時刻已存在，且自此未曾改動。

簽署工作流程為何需要這一步？數碼簽名能證明誰簽了署、內容完整無缺，但「何時」卻依賴你自己掌控的本地時鐘。TSA 權杖以一個受信任、可審計的時鐘取代你的時鐘。標準做法是在建立簽名時即為其加上時間戳；對於長期保存的檔案，還要嵌入驗證數據和存檔時間戳，讓證據在多年後仍然可驗證。

TSA 如何簽發 RFC 3161 時間戳權杖

RFC 3161 的設計刻意簡潔，四個步驟足以釐清每個整合決策。

本地計算雜湊。 客戶端為要綁定時間的數據計算摘要——在 PAdES/CAdES 工作流程中即簽名值。檔案不會離開你的環境。
傳送時間戳請求（TimeStampReq）。 把雜湊值封裝進請求，可選擇附上政策 OID 和防止重放攻擊的隨機數（nonce）。
TSA 簽名。 機構把雜湊值、其同步 UTC 時鐘的時間，以及其政策放入 TSTInfo 結構，然後用 TSA 證書簽名——這就是 TimeStampToken。
綁定權杖。 你的應用程式把權杖嵌入簽名或存檔數據，驗證時便可對已雜湊的位元組重新核對。

這些特性是結構性的：權杖內含你的原始雜湊值和 TSA 簽名的時間，改動一個位元組就會破壞比對；質疑時間，等於質疑 TSA 那個經審計的時鐘。ETSI EN 319 421 與 422 界定了歐洲框架下 TSA 的政策及信任服務要求。

已簽署工作流程為何依賴受信任時間戳

三種失效情境，解釋了為何高風險工作流程必須整合 TSA。

不可抵賴性。 簽署人對合約提出爭議時，可以聲稱其金鑰已外洩或時鐘有誤。TSA 權杖能同時駁回兩者：它由無利益關係的第三方簽發，其時鐘可追溯至 UTC，而且針對的正是已簽署內容的雜湊值。

爭議證據。 合約往往取決於先後次序——要約在撤回前已獲接受、保密協議在洩密前已簽署。我們關於 DocuSign 完成證明與審計追蹤的指南，說明了平台證據紀錄包含甚麼，以及加密時間戳在哪些方面超越了普通日誌紀錄。

長期驗證（LTV）。 這是大多數團隊整合 TSA 的主因。簽名證書會到期——通常在一至三年內——若沒有額外證據，一份十年的舊合約在證書失效當天就變得無法驗證。PAdES、CAdES 與 XAdES 以漸進方式解決這問題：B-LT 把驗證材料（證書與撤銷數據）嵌入檔案，B-LTA 再加入定期存檔時間戳，把整套證據重新錨定在受信任時間上，可延續數十年。在 eIDAS 下，合格時間戳支撐最高保證級別的 QES 及 AdES 驗證鏈；我們的英國 QES 證書費用指南說明了合格保證如何影響定價。

TSA 時間戳的三種整合模式

整合模式有三種，選錯模式是最常見的規劃失誤。

模式一：平台託管時間戳。 電子簽名平台在簽署過程中自動請求並嵌入時間戳，每個完成的簽署信封都自帶受信任時間，無需編寫程式碼。你的工作轉為盡職審查：平台為哪一層加時間戳（簽名值、檔案，還是兩者）、是否嵌入 LTV 數據，以及若日後離開平台，證據如何保留。了解如何審視證書機構清單會有幫助，因為 TSA 證書來自同一套信任基礎設施。

模式二：經 API 或 SDK 在應用層整合。 你的應用程式直接調用 TSA：為簽名或檔案計算雜湊、提交 RFC 3161 請求、接收權杖，再嵌入簽名結構——在 PAdES 中，簽名時間戳和驗證數據時間戳是標準的附加位置。這適合自建簽署服務，以及時間戳必須在精確時刻觸發的工作流程，代價是要自行處理重試、時鐘偏差及權杖儲存。

模式三：存檔與證據系統。 存檔系統批量處理已簽署檔案：嵌入驗證數據（B-LT），並按計劃重新加時間戳（B-LTA）。這適合有保存期限要求的制度、知識產權證據及受規管存檔——還能為舊檔案補上更強的證據。

選擇 TSA 時要查證甚麼

把 TSA 選型當作信任決策：要查證，不要假設。

政策 OID 與合規。 每個權杖都帶有政策識別碼；確認它符合你的要求，且供應商已公開其對照 ETSI EN 319 421/422 的合規情況。
證書鏈與根信任。 TSA 的證書必須鏈接到你的驗證方信任的根，並具備正確的金鑰用途。相關的生命週期問題，與我們如何製作數碼簽名證書的指南互相呼應。
時鐘同步。 TSA 的時間必須透過冗餘、受監察的來源追溯至 UTC，並有文件記錄其方法。
可用性與冗餘。 TSA 一旦停運，模式一和模式二都會停擺。要問清楚正常運行時間、故障切換及備用 TSA 支援。
可審計性。 你需要的是法庭可查證的公開審計報告，而不只是你自己的日誌。

你的工作流程何時真正需要 TSA 整合

先用這張表界定工作範圍。

情境	是否需要 TSA 整合	需要甚麼
受規管或經公證的協議（金融、政府、合格電子簽名）	實務上必需	合格時間戳、嵌入式 LTV、可導出的證據
知識產權與法律證據（優先權或存在日期）	強烈建議	建立時即為內容雜湊加時間戳、B-LTA 存檔重新加戳
eIDAS 類框架下的跨境交易	最高保證級別必需	合格 TSA、政策 OID 對齊目標框架
長保存期（7–10 年以上），不論爭議風險	建議	至少 B-LT；按計劃執行 B-LTA 重新加戳
爭議價值低的日常商業合約	可選	平台提供的時間戳即可；記錄取捨理由

觸發點不在簽署量，而在時間：簽名需要保持可證明的時間越長，TSA 就越不可或缺。

驗證時間戳權杖與避開常見陷阱

整合往往在驗證環節悄悄失敗。四項檢查不可少。

權杖完整性。 重新計算時間綁定數據的雜湊，與權杖內的雜湊比對，再用 TSA 的證書鏈驗證其簽名。
信任與政策。 確認證書鏈到達受信任的根，且政策 OID 可接受。
時間合理性。 把權杖時間對照 TSA 證書的有效期，以及你的時鐘偏差容限。
LTV 完整性。 確認檔案已嵌入 TSA 證書及撤銷數據，否則時間戳會隨 TSA 證書一同失效。具體操作步驟，可參考如何在 PDF 中驗證簽名。

反覆出現的陷阱包括：

以為時間戳比 TSA 證書長命。 沒有嵌入驗證數據和存檔重新加戳，時間戳在證書到期時就無法驗證——LTV 正是解方。
忽略時鐘偏差。 把每個比本地時間差幾秒的權杖一律拒絕，只會製造假失敗。
雜湊演算法太弱。 堅持使用 SHA-256 或以上。
多重時間戳、次序不清。 PAdES 檔案會累積多個時間戳；驗證必須尊重其先後次序，否則 LTV 鏈會斷裂。
信任了錯誤的錨點。 來自你的驗證方不信任的 TSA 的權杖，表面看似有效，到了法庭卻會失效——這正是我們在自簽證書用於商業合約的安全性分析中剖析的信任失敗。

整合前技術檢查清單

在編寫程式碼或簽署供應商合約前，先過一遍這份清單。

界定你要綁定時間的對象：簽名值、完整檔案，還是驗證套件。
選定模式（平台、API 或存檔），並確認與你的簽名格式（PAdES、CAdES 或 XAdES）匹配。
查證 TSA 的政策 OID、證書鏈、根信任及公開審計報告。
確認雜湊與簽名演算法（至少 SHA-256）。
訂明 LTV 目標：簽署時達到 B-LT，並制定 B-LTA 重新加戳計劃。
規劃故障路徑：TSA 停運、重試、備用 TSA、簽署人體驗。
上線前用獨立驗證工具測試——包括一個證書已到期的權杖。

時間戳背書的簽署證據：Nota Sign

Nota Sign 是 FaDaDa 旗下的全球電子簽名平台，合規深度是其核心優勢：平台支援 SES／AES／QES 三級簽名，並整合 iAM Smart 與 Singpass 等國家數碼身份，配合區域數據中心滿足數據駐留要求，法律效力覆蓋 100 多個國家及地區。IDC 報告亦連續多年將 FaDaDa 列為中國電子簽名軟件市場佔有率第一。收費模式不設 per-seat（按席位）費用，中大型客戶可按自身簽署量要求定製方案。

若你正評估時間戳與簽署證據能力，不妨聯絡我們的團隊，按你的合規要求安排一次針對性的示範講解。