Bỏ qua để đến nội dung

Xác thực dài hạn

Spec: ETSI EN 319 142-1 Spec: RFC 6960 Spec: ISO 32000-2, §12.8.4 Evidence: Standard-backed

Một chữ ký mà bạn xác thực hôm nay dựa vào những dữ kiện không tồn tại mãi: chứng chỉ sẽ hết hạn, máy chủ thu hồi sẽ ngừng hoạt động, và thuật toán băm sẽ yếu dần. Xác thực dài hạn ghi lại bằng chứng vào tài liệu khi vẫn còn lấy được. Nhờ đó, chữ ký vẫn có thể được kiểm tra sau nhiều năm mà không cần hỏi bất kỳ dịch vụ bên ngoài nào.

Điểm nguy hiểm của chữ ký số là nó có thể âm thầm không còn xác thực được nữa dù bề ngoài không hề thay đổi. Không có byte nào trong tệp thay đổi. Tổ chức cấp chứng chỉ ngừng trả lời truy vấn về một chứng chỉ đã hết hạn từ lâu. Trình xác thực cần câu trả lời đó thì nay không còn lấy được nữa. Một hợp đồng chắc chắn hợp lệ vào ngày được ký lại trở thành “không thể xác định” sau một thập kỷ. Mà một thập kỷ sau thường chính là lúc tranh chấp dễ xảy ra nhất và rủi ro cao nhất. Nếu nghĩa vụ lưu giữ của bạn được tính bằng năm, thì chữ ký không có xác thực dài hạn là một rủi ro chỉ lộ ra về sau.

  • Tính hợp lệ của chữ ký phụ thuộc vào các dữ kiện bên ngoài nhạy cảm với thời gian: thời hạn hiệu lực của chứng chỉ, và trạng thái thu hồi từ một máy chủ.
  • Những dữ kiện đó trở nên không thể lấy được sau khi chứng chỉ hết hạn — các tổ chức không có nghĩa vụ phải trả lời mãi mãi.
  • Xác thực dài hạn thu thập bằng chứng tại thời điểm ký — chứng chỉ, phản hồi OCSP, CRL — và nhúng nó vào Document Security Store (DSS) của tài liệu.
  • Sau đó, một dấu thời gian tài liệu chứng minh rằng chính bằng chứng đó đã tồn tại và hợp lệ tại thời điểm ấy, và có thể được làm mới trước khi mức bảo vệ của chính nó yếu đi.
  • Kết quả: tài liệu tự mang theo bằng chứng của mình. Việc xác minh không còn phụ thuộc vào chuyện một máy chủ có còn hoạt động hay không.

Nguyên tắc là “thu thập bằng chứng khi bạn vẫn còn có thể, rồi niêm phong nó.” Khi NextPDF tạo một chữ ký dài hạn, nó thu thập chuỗi chứng chỉ và các phản hồi thu hồi chứng minh rằng chứng chỉ ký vẫn còn tốt vào thời điểm ký. Nó ghi các dữ liệu đó vào DSS dưới dạng giá trị được nhúng, không phải liên kết. Sau đó, nó thêm một dấu thời gian tài liệu lên toàn bộ. Các giá trị được nhúng chính là điểm mấu chốt. Liên kết tới máy chủ thu hồi chính là sự phụ thuộc mà xác thực dài hạn được sinh ra để loại bỏ.

Các lớp dài hạn được ghi dưới dạng các bản sửa đổi tài liệu riêng biệt, nối thêm vào mà không chạm đến phạm vi byte của chữ ký gốc. Chữ ký đầu tiên vẫn tiếp tục xác thực được. Phần dữ liệu dài hạn được thêm vào xung quanh nó, chứ không phải vào trong nó. Khi mức bảo vệ của chính dấu thời gian tài liệu cũ đi, mức lưu trữ cho phép xếp thêm một dấu thời gian khác lên trên. Kết quả là một chuỗi trong đó mỗi dấu thời gian bảo chứng cho mọi thứ nằm bên dưới nó.

  1. Sign The signature and its signed attributes are written (B-B).
  2. Capture evidence Certificate chain, OCSP responses, and CRLs proving the certificate was valid at signing time are gathered.
  3. Embed in the DSS The evidence is written into the document as embedded values, not links (B-LT).
  4. Seal with a document timestamp A timestamp proves the embedded evidence existed and was valid at that moment (B-LTA).
  5. Renew before it weakens Another timestamp is layered before the previous one’s protection ages, extending verifiability.
Cách xác thực dài hạn giữ cho một chữ ký luôn xác thực được theo thời gian: chữ ký được tạo, bằng chứng được thu thập khi nó vẫn còn lấy được, bằng chứng được niêm phong bằng một dấu thời gian tài liệu, và con dấu được làm mới trước khi nó yếu đi.

Evidence: Standard-backed Nhu cầu này được nêu rõ ràng bởi Spec: RFC 6960, §4.4.4 : trạng thái thu hồi có thể tồn tại lâu hơn thời hạn hiệu lực của chứng chỉ, và cơ chế điểm cắt lưu trữ cung cấp cho trình xác thực bối cảnh lịch sử để quyết định một chữ ký có đáng tin cậy vào thời điểm được tạo ra hay không, ngay cả sau khi chứng chỉ dùng để xác thực đã hết hạn. Đó là lý do xác thực dài hạn tồn tại. Phản hồi thu hồi chỉ có thể lấy được trong một thời gian giới hạn, nên bạn phải thu thập chúng trước khi khoảng thời gian đó kết thúc.

Cơ chế này thuộc ETSI. Spec: ETSI EN 319 142-2, §5.5 nêu rằng hành vi dài hạn đòi hỏi một Document Security Store mang theo dữ liệu xác thực dưới dạng giá trị, tiếp theo là một dấu thời gian tài liệu. Spec: ISO 32000-2, §12.8.3.3 kết nối tất cả lại với nhau: PAdES là CAdES CMS kết hợp với xác thực dài hạn (§12.8.4) và từ điển dấu thời gian tài liệu (§12.8.5). Và Spec: ETSI EN 319 142-2, §6.3.2.2 là lý do dấu thời gian được áp dụng sớm: dấu thời gian nên được áp dụng ngay sau khi ký để thời điểm được ghi lại sát với thời gian thực nhất có thể.

Engine của NextPDF hiện thực hóa điều này dưới dạng các mức B-LTB-LTA: các giá trị thu hồi được nhúng trong DSS, một dấu thời gian tài liệu niêm phong chúng, và vòng lặp lưu trữ làm mới con dấu — tất cả được ghi dưới dạng các bản sửa đổi nối thêm, giữ nguyên vẹn phạm vi byte của chữ ký gốc.

Mức bạn chọn chính là quyết định dài hạn. API làm rõ yêu cầu trước khi bạn cam kết.

<?php
declare(strict_types=1);
use NextPDF\Security\Signature\SignatureLevel;
// B-LT embeds validation material; B-LTA adds the renewable seal.
$level = SignatureLevel::PAdES_B_LTA;
$level->requiresDss(); // true → certificates + revocation embedded
$level->requiresDocumentTimestamp(); // true → a document timestamp seals the DSS
// The high-level seam produces the level end to end: it embeds the DSS
// dictionary and appends the DocTimeStamp revision in one call.
$document
->setSignature($cert, SignatureLevel::PAdES_B_LTA, $tsaClient)
->save();
// The engine produces this only if the deployment can supply what it needs
// (a TSA, and revocation data reachable at signing time). It fails with an
// actionable error rather than embedding nothing and reporting success.

Đường nối cấp cao được trình bày ở trên — setSignature($cert, SignatureLevel::PAdES_B_LTA, $tsaClient)->save() — hiện đã được nối hoàn chỉnh từ đầu đến cuối; các bản phát hành trước đó có enum mức nhưng chưa có đường nối tạo ra mức đó. Phần được ghi là cấu trúc: từ điển DSS và bản sửa đổi DocTimeStamp được mô tả bởi Spec: ISO 32000-2, §12.8 . Cấu trúc đó chưa được kiểm thử về tuân thủ profile, và đường nối không khẳng định bất cứ điều gì về tuân thủ ETSI hay tính hợp lệ pháp lý. Các mức B-LTB-LTA đòi hỏi cả Pro lẫn Enterprise; ở bất kỳ phân hạng nào khác, đường nối sẽ thất bại an toàn thay vì tạo ra kết quả không trọn vẹn. Tài liệu được mã hóa cũng thất bại an toàn đối với B-LTB-LTA; DSS và dấu thời gian tài liệu không được ghi đè lên nội dung đã mã hóa, vì làm vậy sẽ ghi chúng sai cách.

Lựa chọn này không thể bổ sung lại với chi phí thấp. Bằng chứng thu hồi phải được thu thập tại thời điểm ký, khi các phản hồi vẫn còn tồn tại. Quyết định “chúng ta sẽ thêm xác thực dài hạn sau” thường đồng nghĩa với quyết định “chúng ta sẽ không có bằng chứng khi cần đến nó.”

Hiểu lầm là “xác thực dài hạn làm cho một chữ ký hợp lệ mãi mãi.” Nó không làm cho bất cứ thứ gì trở nên hợp lệ. Nó giữ lại khả năng kiểm tra một tính hợp lệ đã được thiết lập tại thời điểm ký. Nếu chứng chỉ đã bị thu hồi khi tài liệu được ký, thì việc nhúng dữ kiện đó không cứu được chữ ký. Thay vào đó, nó ghi lại thất bại đó một cách vĩnh viễn. Xác thực dài hạn là cơ chế bảo tồn bằng chứng, chứ không phải cơ chế tạo ra bằng chứng. Hiểu lầm thứ hai là tin rằng B-LTA là “thiết lập rồi quên đi.” Dấu thời gian lưu trữ bảo vệ bằng những thuật toán mà bản thân chúng cũng cũ đi. Nếu không được làm mới, tệp B-LTA cuối cùng vẫn thừa hưởng chính sự mong manh mà nó vốn nhằm thoát khỏi.

NextPDF thu thập và nhúng bằng chứng, đồng thời ghi các dấu thời gian. Nó không kiểm soát tính đúng đắn của bằng chứng hay lịch làm mới bằng chứng. Phản hồi thu hồi chỉ đáng tin cậy trong phạm vi tổ chức đã phát hành chúng và thời điểm chúng được lấy về. Khả năng kết nối tới tổ chức đó tại thời điểm ký là trách nhiệm của bên triển khai. Engine không thể bịa ra một phản hồi thu hồi mà nó không lấy được. Việc làm mới lưu trữ là một quy trình vận hành. Engine có thể thêm một dấu thời gian khác, nhưng nó không thể quyết định khi nào chính sách lưu giữ của bạn yêu cầu điều đó. Việc dữ liệu được nhúng về sau có được đánh giá là đủ hay không là câu hỏi thuộc về trình xác thực và chính sách, được đề cập trong Xác thực chữ ký đúng cách. Trang này không khẳng định khả năng được chấp nhận về mặt pháp lý, điều vốn phụ thuộc vào thẩm quyền tài phán, người ký, và chứng chỉ.

Mức độ khả dụng của xác thực dài hạn theo phân hạng:

Long-term validation (DSS embedding and the archival timestamp loop) — edition availability
Edition Availability
Core Not in this edition
Pro

PAdES B-T — một dấu thời gian tin cậy trên giá trị chữ ký — là khả dụng, nhưng tư liệu xác thực được nhúng (DSS) không thuộc B-T.

Enterprise

PAdES B-LTB-LTA: các giá trị chứng chỉ và thu hồi được nhúng trong DSS, dấu thời gian tài liệu niêm phong, và vòng lặp lưu trữ có thể làm mới.

  • Xác thực dài hạn (LTV) — việc nhúng các bằng chứng cần thiết để xác thực chữ ký, để việc xác minh về sau không phụ thuộc vào các dịch vụ bên ngoài.
  • Document Security Store (DSS) — cấu trúc PDF chứa các chứng chỉ và dữ liệu thu hồi được nhúng để phục vụ xác thực dài hạn.
  • Phản hồi OCSP — một tuyên bố được ký về trạng thái thu hồi của một chứng chỉ tại một thời điểm (Online Certificate Status Protocol, RFC 6960).
  • CRL — Certificate Revocation List; một danh sách được ký gồm các chứng chỉ đã bị thu hồi.
  • Dấu thời gian tài liệu — một dấu thời gian RFC 3161 được áp dụng cho toàn bộ tài liệu, chứng minh rằng bằng chứng được nhúng đã tồn tại và hợp lệ tại thời điểm đó.
  • Vòng lặp lưu trữ — việc liên tục thêm một dấu thời gian tài liệu mới trước khi mức bảo vệ của dấu trước yếu đi, qua đó kéo dài khả năng xác thực.