서명에 사용된 인증서가 만료되거나 발급 기관(CA)의 키 갱신이 이루어진 먼 훗날에도 서명된 PDF 파일의 정합성을 정상 검증할 수 있도록, Windows용 PDFium 컴포넌트는 신뢰 가능한 시각 보증을 위한 RFC 3161 타임스탬프, 자체 검증 리소스를 수집하는 DSS(Document Security Store) 저장소, 그리고 파일 전체를 감싸는 감사용 DocTimeStamp를 동용하여 규격화된 장기 보존 PAdES 서명을 생성해 냅니다. 이 세 가지 요소가 각각 PAdES B-T, B-LT 및 B-LTA 표준 규격의 핵심 뼈대이며, PDFium 컴포넌트는 단 한 번의 signing 호출로 이 모든 단계를 자동 도달합니다. 본 기능은 PadesCryptoAvailable 검증 플래그로 제한되는 Windows 플랫폼 전용 스펙입니다
이 문서는 디지털 서명 연획 시리즈의 마지막 세 번째 가이드입니다. 첫 번째인 Delphi 환경에서의 PAdES B-B 서명 날인 구현 가이드는 기초 서명 기입을 다루었으며, 두 번째인 PDF 디지털 서명 검사 및 PAdES 레벨 판별 가이드는 기존 파일의 서명 등급을 분석하고 분류하는 법을 가이드했습니다. 이번 장의 핵심 관심사는 장기 보존(Archival)입니다: 인증서 만료 한계를 초월하여, 주 단위가 아닌 수년 단위로 책정되는 장기 보존 의무 기간 동안 서명의 법적 증빙력을 영구 수호하는 메커니즘을 탐구합니다
유효했던 PDF 서명이 시간이 흐르면 왜 검증 실패로 돌아서나요?
기초 등급 서명은 오직 한 가지 사실만 보증합니다: 서명 완료 직후 문서 바이트가 임의 수정되지 않았는지 여부입니다. 그 자체로는 서명이 '정확히 언제' 일어났는지 암호학적으로 입증해 주지 않으며, 바로 이 시간 정보의 유실이 미래의 검증 실패를 야기합니다. CMS 구조 내부에 서명 일시 속성이 기입되기는 하나, 이는 서명자의 로컬 시스템 시계에 의존해 임의 기록된 값이므로 검증 엔진은 이를 신뢰하지 않습니다. 훗날 서명 인증서가 만료되거나 발급 기관(CA)이 이를 해지 처리하면, 엄격한 검증 시스템은 해당 서명이 인증서의 유효 기간 내에 합법적으로 처리된 것인지 또는 만료 후 악의적으로 날짜를 조작해 사후 날인된 것인지 변별할 수 없게 됩니다. 날인 당시에는 완벽하게 유효했던 서명이 시간 경과에 따라 무기력하게 입증 불능 상태로 전락하는 현상입니다
장기 아카이빙 솔루션은 두 가지 기술 조치로 이 한계를 돌파합니다. 첫째, 공인된 제3의 기관인 타임스탬프 서비스 제공자(TSA)가 시간 정보를 암호학적으로 날인 보증(Attested)하여 서명자의 시계 주장에 의존하지 않도록 수립합니다. 둘째, 인증서 체인을 추적하고 신뢰 여부를 판별하는 데 필요한 모든 요소(인증서 체인 경로 전체 및 실시간 OCSP/CRL 해지 증빙값)를 PDF 파일 내부에 영구 병합하여, 훗날 발급 기관의 웹 서버가 정지되어 해지 조회가 불가능한 상황에서도 파일 스스로 서명의 무결성을 완벽히 증빙(LTV)할 수 있게 조율합니다. ETSI EN 319 142-1 표준으로 제정된 PAdES는 이 요건들을 규격 등급(Baseline level) 형태로 정의하며, PDFium 컴포넌트는 개별 레벨이 요구하는 암호학적 데이터 구조를 명확하게 시트에 기록해 냅니다
LTV 및 아카이브 타임스탬프 PDF 서명이란 무엇인가요?
PAdES 표준은 서로 유기적으로 상속 결합되는 4단계의 표준 규격 등급을 규정하며, PDFium 컴포넌트는 이를 TPadesLevel 열거형 구조(plB_B, plB_T, plB_LT, plB_LTA)로 노출합니다. B-B는 순수 서명 단계입니다. B-T는 서명 값 위에 공인 신용 시각을 증빙하는 타임스탬프를 보강합니다. B-LT(Long-Term)는 검증에 필수적인 공인 리소스들을 병합하며, 일반 대중이 흔히 'LTV'라 지칭하는 서명 상태가 바로 이 등급에 준합니다. B-LTA(Archive timestamp)는 DSS 정보를 포함한 문서 전체 영역을 타임스탬프(Document timestamp)로 재차 덮어씌움으로써, 파일 보관 처리 시점에 DSS 검증 리소스 자체가 물리적으로 완전했고 무변조 상태였음을 강력하게 증명해 냅니다
실제 정산 시에는 하나의 계단형 아키텍처로 도식화됩니다. B-T는 서명이 완료된 시점을 규명합니다. B-LT는 훗날 외부의 도움 없이 무엇을 활용해 독자 서명 검증을 마칠 수 있는지를 입증합니다. B-LTA는 밀봉된 이후 전체 정보가 단 1바이트도 오염되지 않았음을 보증하며, 이전 스탬프의 수명이 만료되기 전에 새 스탬프(DocTimeStamp)를 덧씌워 유효 기한을 무한 연장할 수 있게 돕는 아카이빙 표준의 최정상 등급입니다. 장기 법적 보존 의무가 수반되는 계약서나 기업 감사 장부의 경우 B-LTA가 최종 획득 목표점이며, 일상적인 정산 업무에서는 B-LT 등급이 실무적인 표준 요구선이 됩니다
신뢰할 수 있는 시각 정보 추가: RFC 3161 기반 PAdES B-T
PDFium 컴포넌트는 TPadesSignOptions 상의 두 가지 제어 속성을 지정하여 기본 B-B 서명을 B-T 서명으로 즉각 고도화합니다: Level 속성을 plB_T로 상향하고 TsaUrl 경로를 제공하는 것입니다. 두 항목이 확보되면, 날인 프로세스는 원시 서명 데이터를 SHA-256으로 해싱하여 RFC 3161 규격의 messageImprint 규격으로 가공한 뒤 WinHttp 모듈을 통해 TSA 공인 시각 센터로 POST 통신을 기동하며, 회신받은 시각 확인 토큰을 EN 319 142-1 §6.3 지침에 따라 SignerInfo의 비서명 속성 영역(unsignedAttrs, OID 1.2.840.113549.1.9.16.2.14)에 서명 타임스탬프 정보로 정밀하게 주입합니다. 이 스탬프는 개별 서명 값에 한정되어 보호를 적용하므로 신용 시각을 해당 서명 데이터에 강력하게 밀착시킵니다
uses
PDFium, FPdfPades;
procedure SignWithTimestamp;
var
Pdf: TPdf;
Options: TPadesSignOptions;
begin
Pdf := TPdf.Create(nil);
try
if not Pdf.PadesCryptoAvailable then
raise Exception.Create('PAdES 서명 엔진은 Windows 전용으로 동작합니다');
Pdf.FileName := 'contract.pdf';
Pdf.Active := True;
Options := TPadesSignOptions.Default;
Options.CertificateThumbprint := 'A1B2C3D4E5F6071829304152637485960A1B2C3D';
Options.Level := plB_T;
Options.TsaUrl := 'http://timestamp.example-tsa.com/tsr';
Options.Reason := 'Contract execution';
// Nonce 값을 0으로 비워두면 컴포넌트가 고유한 재전송 공격 방지용 nonce 값을 자동 생성합니다.
Pdf.SignPades('contract-bt.pdf', Options);
finally
Pdf.Free;
end;
end;검증 리소스 병합: 한 번의 호출로 구현하는 B-LT 및 B-LTA
장기 검증 표준 등급을 달성하기 위한 교정 조치는 매우 간단합니다: Level 사양을 plB_LTA로 격상하고 TsaUrl을 유지해 주는 것입니다. 그러면 PDFium 컴포넌트는 단 한 번의 SignPades 동작 과정에서 전체 단계를 순차 자동 수행합니다. 기본 서명(B-B)을 수립하고, B-T 등급용 시각 토큰을 기입한 뒤, B-LT 요구선인 DSS 정보 구조를 주입하고, 마지막으로 B-LTA용 아카이브 타임스탬프를 덧씌우는 연산을 각각 독립된 증분 업데이트 방식으로 안전하게 기입하여 이전 바이트 데이터가 훼손되지 않도록 정밀 보호합니다
procedure SignForArchive;
var
Pdf: TPdf;
Options: TPadesSignOptions;
begin
Pdf := TPdf.Create(nil);
try
Pdf.FileName := 'contract.pdf';
Pdf.Active := True;
Options := TPadesSignOptions.Default;
Options.CertificateThumbprint := 'A1B2C3D4E5F6071829304152637485960A1B2C3D';
Options.Level := plB_LTA; // B-B -> B-T -> B-LT -> B-LTA 순차 승급
Options.TsaUrl := 'http://timestamp.example-tsa.com/tsr';
Options.Location := 'Head Office';
// 한 번의 호출로 타임스탬프, DSS, 아카이브 DocTimeStamp를 모두 작성합니다.
Pdf.SignPades('contract-lta.pdf', Options);
finally
Pdf.Free;
end;
end;B-LT 기입 단계에서, PDFium 컴포넌트는 Windows API CertGetCertificateChain을 통해 인증서 경로 체인을 추출하며, EN 319 142-1 §5.4.2 규격 지침에 입각하여 서명 인증서 및 모든 중간 인증서 경로를 포함하는 /Certs 배열(및 병렬 관계인 /OCSPs, /CRLs 해지 조회 배열) 및 Level 1 준수를 뜻하는 /Extensions /ESIC 식별 지시자를 포함하는 /DSS 딕셔너리를 파일에 기록해 냅니다. 자가 서명된 최상위 루트 인증서는 RFC 5652 §10.2.3 명세에 따라 생략되는데, 검증자 시스템이 이미 신뢰 앵커(Trust anchor) 형태로 내장하고 있을 것이기 때문입니다. 이로써 외부 서버 연동 없이 파일 자체만으로 독자 유효성 검증을 마칠 수 있는 독립 완비성 서명이 완성됩니다
최종 B-LTA 연산 단계에서, 컴포넌트는 전체 파일 영역을 커버 범위(/ByteRange)로 지정하고 /SubFilter /ETSI.RFC3161 사양을 충족하는 문서 타임스탬프(Document Time-stamp) 딕셔너리를 추가 날인하여, 그 틈에 전체 바이너리를 방어하는 RFC 3161 공인 토큰을 기입하고 ESIC 마커 레벨을 Level 2로 격상합니다. 이것이 §5.4.3 및 TS 119 142-3 표준 아카이브 마감 공정입니다. 이 아카이브 스탬프는 최초의 서명뿐 아니라 중간에 주입한 DSS 정보 전체까지 포함하여 감싸기 때문에, 보관 개시 시점에 이미 DSS 검증 정보가 무변조 상태로 온전히 내장되어 실재했음을 법적으로 영구 규명해 줍니다
기존 서명 문서에 LTV 검증 정보 보강하기
간혹 서명은 파일 내에 이미 완료되어 있고 단지 장기 아카이빙을 위해 검증용 리소스(DSS) 정보만 사후 기입하거나 갱신해야 하는 상황(예: 외부 타사에서 기제출된 기초 B-B 서명 문서를 사내 아카이브에 영구 저장하기 전에 B-LT 수준으로 승급시키는 공정)이 발생합니다. PDFium 컴포넌트는 DSS 주입 기능을 SaveAsPadesDss 메서드로 전면 노출하고 있으며, 이는 기존에 날인된 원래의 서명 바이너리를 단 1바이트도 훼손하지 않고 깔끔하게 파일 후미에 /DSS 및 /Extensions 구조체만 증분 기입하는 방식으로 동작합니다
procedure AddValidationStore;
var
Pdf: TPdf;
DssOpts: TPadesDssOptions;
Cert: TPadesDssMaterial;
begin
Pdf := TPdf.Create(nil);
try
Pdf.FileName := 'already-signed.pdf';
Pdf.Active := True;
DssOpts := TPadesDssOptions.Default;
DssOpts.EsicExtensionLevel := 1; // 1은 B-LT, 2는 B-LTA 대응
Cert.DerBytes := LoadSignerCertDer; // DER 인코딩된 인증서 파일
SetLength(DssOpts.Certs, 1);
DssOpts.Certs[0] := Cert;
Pdf.SaveAsPadesDss('already-signed-lt.pdf', DssOpts);
finally
Pdf.Free;
end;
end;개발자는 검증 과정에 필요한 DER 인코딩 인증서 데이터와 필요에 따라 OCSP/CRL 해지 정보를 기입하면 됩니다. EsicExtensionLevel 속성은 일반 B-LT 보강일 경우 1로, 후속 아카이브 타임스탬프 처리가 수반될 경우에는 2로 조율합니다. 개별 서명별 검증 정보를 추적하는 IncludeVri 플래그는 기본값인 False로 두는 것이 권장됩니다: EN 319 142-1 §5.4.2.3 지침은 /VRI 딕셔너리를 선택 사양으로 규정하며 특정 리더기에서 이를 의무화하는 특수 환경이 아닌 한 비활성화할 것을 권고합니다
도입 비용 및 주의할 실무적 경계 사항
장기 아카이빙 디지털 서명 시스템 도입 시 반드시 고려해야 할 세 가지 현실적 임계선이 있습니다. 첫째, 디지털 서명 및 타임스탬프 서명 저작 엔진은 Windows 플랫폼 전용으로 가동됩니다: 내부적으로 Windows CNG 암호 모듈 및 WinHttp 통신 모듈을 활용하기 때문이며, 타 플랫폼에서는 PadesCryptoAvailable 속성이 False를 반환하고 SignPades 호출 시 예외를 던집니다. (이전 가이드에서 설명한 기존 서명을 정밀 판독하는 분석 모듈은 macOS, Linux 등 전 플랫폼에서 완전한 교차 기동이 보장됩니다.) 둘째, B-T 및 B-LTA 서명은 공인 TSA 시각 서버와 반드시 통신해야 하므로, 날인 동작 시 실시간 네트워크 왕복 통신 지연(Latency)이 동반되며 외부 TSA 서버의 가용성(Uptime) 및 트래픽 제한 조건이 프로그램 성능 설계에 직접 영향을 줍니다
셋째, 각 등급이 상향될수록 물리 저장 공간 비용이 소모됩니다. 서명 기입 공정은 원본 데이터를 보존하기 위해 파일을 덮어쓰지 않고 항상 증분 업데이트 방식으로 덧붙여 기입하며, DSS에는 비대한 인증서 체인이 내장되고, 아카이브 스탬프 영역도 일정 바이트 크기를 사전에 예약 확보하므로, 최종 B-LTA 문서 크기는 원본 파일보다 눈에 띄게 비대해집니다. 이는 미래의 법적 무결성 영구 증빙을 위해 현재의 바이트 용량을 투자하는 정밀한 트레이드오프(Trade-off)입니다. 장기 준수 의무가 부과되는 대다수 전자 문서 관리에서는 이 트레이드오프가 매우 타당하지만, 도입 전에 샘플 문서를 통해 용량 변화폭을 미리 진단해 보는 것을 추천합니다. 완성된 파일이 의도한 PAdES 등급에 정상 안착했는지는 연재 2편인 PDF 디지털 서명 검사 및 PAdES 레벨 판별 가이드의 실무 검사법을 통해 체크할 수 있으며, 시스템 전반의 문서 위변조 리스크를 정밀 단속하려 하신다면 PDF 보안 리스크 감사 가이드에서 주변부 보안 체크 요건들을 종합 파악하실 수 있습니다
여기에 소개된 PAdES 서명 기입, LTV DSS 주입 및 아카이브 타임스탬프 기능은 모두 Delphi 및 C++Builder용 PDFium 컴포넌트 패키지 최신 버전에 포함되어 제공됩니다