2026年8月18日
CAdES（CMS 高級電子簽名，CMS Advanced Electronic Signatures）是 ETSI 標準——EN 319 122——用於在加密訊息語法（CMS）之上構建高級電子簽名。CMS 格式定義於 RFC 5652，最初稱為 PKCS#7。簡單來說：CAdES 在常規 CMS/PKCS#7 數碼簽名的基礎上，加入必要的簽名屬性，用來證明是誰簽的、甚麼時候簽的，以及簽署後數據未被改動。它最常用於簽署任意數據或檔案（軟件套件、電子發票、登記紀錄、交易報文），而非面向可視化呈現的 PDF 文件——那是 PAdES 的領域——也不是 XML 原生數據，那屬於 XAdES 的範疇。
如果你的團隊在歐盟營運或向歐盟銷售，CAdES 之所以重要，是因為它是 ETSI 為滿足 eIDAS 對高級電子簽名和合格電子簽名的要求而標準化的三種簽名格式之一。本文將講清 CAdES 是甚麼、它如何滿足 eIDAS 高級簽名要求、各基線 Profile 分別增加了甚麼，以及在真實系統中如何在 CAdES、PAdES、XAdES 之間作出選擇。
CAdES 是甚麼？
CAdES 是 CMS Advanced Electronic Signatures 的縮寫。現行規範是 ETSI EN 319 122，它定義了如何使用 CMS SignedData 結構構建電子簽名——這正是 S/MIME 電郵、代碼簽名和眾多 PKI 應用所使用的二進制封裝格式（RFC 5652，歷史上的 PKCS#7）。
一個普通的 CMS 簽名本身已包含簽署者證書，以及對內容（或對簽名屬性）計算出的簽名值。CAdES 在此基礎上增加一組受控的簽名屬性和未簽名屬性，把一個原始的密碼學簽名變成一份具證據效力的物件：
- 簽名證書（signing-certificate）屬性：將簽名綁定到具體的簽署者證書，防止證書替換攻擊。
- 簽名時間戳（signature time-stamp）：由可信時間源出具的時間戳，證明簽名在某一時刻已經存在。
- 完整驗證數據（更高層級 Profile）：內嵌的證書鏈、吊銷回應（CRL/OCSP）以及後續的歸檔時間戳，使簽名在密鑰過期、CA 消失之後很久仍可驗證。
由於 CAdES 與內容無關，被簽的載荷可以是任何東西：一個二進制檔案、一筆 JSON 交易、一批紀錄。這使它成為系統間簽名、某些法域的電子發票流水線、簽名數據集的長期歸檔，以及任何被簽對象並非人類可讀 PDF 的工作流程的自然選擇。
CAdES 如何滿足 eIDAS 高級電子簽名要求
在 eIDAS 下，高級電子簽名（AdES）必須滿足四項要求：與簽署人唯一關聯、能夠識別簽署人、使用簽署人獨自控制的簽名創建數據生成，並與被簽數據相關聯，從而任何後續改動都可被偵測。
CAdES 的設計正是為了讓合規簽名能夠證明以上四點：
- 唯一關聯與識別：簽名內嵌對簽署者證書的引用，該證書由 CA 在完成身份核驗後簽發。
- 獨自控制：產生簽名的私鑰僅由簽署人持有（存放於令牌、HSM 或由其控制的遠程簽名服務中）。格式本身無法強制這一點，但 CAdES 是承載和證明此類「獨自控制」簽名的容器。
- 篡改偵測：簽名是針對內容計算的（透過包含訊息摘要在內的簽名屬性），任何修改都會在數學上使簽名失效。
當簽名密鑰存放於合格簽名創建設備（QSCD）中、且證書為合格證書時，同樣的 CAdES 結構即構成合格電子簽名（QES）——eIDAS 的最高等級，在整個歐盟與手寫簽名具有同等法律效力。關於法律等級的深入解讀，請參閱我們的高級電子簽名作為商業標準、合格電子簽名，以及實踐中符合 eIDAS 的電子簽名需要滿足甚麼條件的相關指南。
CAdES 基線 Profile：B-B、B-T、B-LT、B-LTA
ETSI 定義了四個基線 Profile。每個 Profile 都在前一個的基礎上疊加屬性，延長簽名可被驗證的時間跨度並提升驗證可信度。
一個實用的理解方式：B-B 是高級簽名的底線；B-T 是大多數商業交易的合理預設；B-LT 適合需要按保存期限留存的合約與紀錄；B-LTA 面向法定保存期長達多年的歸檔級證據。注意，CAdES-B-LT 和 B-LTA 簽名通常是在既有簽名之上追加驗證數據而生成的——這項工作往往由接收方系統或歸檔服務完成，而非簽署人。
分離式簽名與內嵌式簽名
CMS SignedData 支援兩種打包方式，CAdES 兩者都繼承：
- 內嵌式（enveloping，attached）：被簽內容嵌入簽名結構內部。一個檔案承載一切，便於儲存和傳輸，但接收方需要支援 CMS 的工具才能提取內容。
- 分離式（detached）：簽名結構中只有簽名本身，內容存放於獨立檔案中。原始檔案保持字節級不變、可被任何工具讀取，但你必須同時保存和傳輸兩個部分——遺失分離式簽名就意味着遺失證據。
當被簽產物必須能被非密碼學系統使用（例如下游流水線要解析的數據檔案）時，選擇分離式簽名；當一個自包含的證據包比載荷的直接可讀性更重要時，選擇內嵌式簽名。
CAdES vs PAdES vs XAdES：如何選擇格式
三種 ETSI AdES 格式共享同一套基線 Profile 邏輯（B-B、B-T、B-LT、B-LTA）和同樣的 eIDAS 目標，區別在於它們簽署的容器。
經驗法則：
- 簽署人們會閱讀和打印的文件 → PAdES。我們的 PDF 高級電子簽名 PAdES 指南和甚麼是面向 PDF 的 PAdES詳解了這條路徑。
- 在文件級或元素級簽署 XML（符合 EN 16931 Profile 的電子發票、SOAP/XML 服務）→ XAdES。
- 簽署任意檔案、數據塊或批量數據，且已有 CMS/PKCS#7 工具鏈 → CAdES。
在同一 Profile 層級上，三者沒有誰「更強」；選擇取決於你的生態使用哪種數據格式。
驗證與長期歸檔
創建 CAdES 簽名只是故事的一半；驗證它——今天以及十年後——是另一半。B-LT 或 B-LTA 簽名的驗證可以離線進行，因為所需的一切（證書鏈、吊銷數據、時間戳）都隨簽名攜帶。而裸 B-B 簽名的驗證依賴對 CA 吊銷服務的實時存取，多年後這些服務可能已不存在。
一個健全的驗證流程會檢查：簽名的密碼學完整性、到可信根的證書路徑、所聲稱簽署時刻的吊銷狀態、時間戳令牌本身的有效性，以及（對 B-LTA）歸檔時間戳鏈條。關於日常檢查簽名的實操層面，請參閱我們的數碼簽名驗證指南。
對於長期歸檔，把「B-LTA + 定期重新加蓋時間戳」當作標準模式：隨着雜湊或簽名算法老化，歸檔方用當前算法加蓋新的歸檔時間戳，無需原始簽署人再次參與，即可保全證據效力。
企業落地建議
在將 CAdES 定為標準之前，幾條務實的建議：
- 先確認你的生態的期望。如果合作夥伴、監管機構或行業方案（電子發票網絡、海關、登記系統）指定了格式，遵從其要求；當對方只說「AdES」時，讓容器匹配你的數據。
- 任何交易性簽名至少預設使用 B-T；TSA 時間戳的邊際成本相對其證據價值微不足道。
- 規劃好由誰追加驗證數據。從 B-T 升級到 B-LT 需要在驗證時捕獲吊銷證據——把這一步明確指派給你的接收／歸檔系統。
- 當你需要 QES 級效力時，優先選用合格證書，並在需要時使用 QSCD 或同等合格的遠程簽名服務。
- 不要自己手寫 CMS。使用持續維護的函式庫，或已處理好 Profile 合規、TSA 整合和驗證數據捕獲的簽名平台；細微的屬性錯誤會悄無聲息地破壞合規性。
用 Nota Sign 構建合規的高級電子簽名
Nota Sign 是法大大旗下的全球電子簽名平台，其基礎設施連續多年被 IDC 評為中國電子簽名軟件市場第一。平台支援 SES、AES、QES 三個簽名等級，覆蓋 100+ 國家和地區，具備深厚的亞太合規能力——包括香港的 iAM Smart 和新加坡的 Singpass——並設有區域數據中心以滿足數據駐留要求。
無論你的工作流程需要對合約做基於 PDF 的 PAdES 簽名，還是對數據載荷做基於 CMS 的簽名，Nota Sign 的平台和 API 都會處理證書管理、可信時間戳和長期驗證證據，讓你的團隊不必自己搭建底層管道。定價設計對成長型團隊友好：小型企業無按席位收費，中大型及企業級需求可提供定制方案。
準備好討論你的合規架構了嗎？聯絡 Nota Sign 團隊，聊聊你的簽名格式與驗證需求。
