서명 검증: AdES / PAdES 암호학적 검증

한눈에 보기

NextPDF Enterprise는 디지털 서명을 암호학적으로 검증합니다. 검증 측은 PDF에서 CMS SignedData 또는 RFC 3161 타임스탬프 토큰을 읽고, 다이제스트를 다시 계산하며, 서명을 확인하고, 각 서명을 해당 서명 인증서에 바인딩하고, 인증서 정책 처리를 포함해 인증서 체인을 호출자가 제공한 신뢰 앵커 저장소 기준으로 검증합니다. 이 페이지는 동작 수준의 설명입니다. 무엇을 검증하고, 무엇을 fail-closed로 거부하며, 어떤 알고리즘을 지원하고, 신뢰 경계가 어디에 있는지를 명시합니다.

이는 Validation과 구별됩니다. Validation은 읽기 전용 구조적 정책 검사를 수행하며, 의도적으로 암호화 작업을 전혀 수행하지 않습니다. 또한 PAdES B-LT / B-LTA 구조를 작성하는 Signature producer에 대응하는 검증 측 기능입니다.

설치

composer require nextpdf/enterprise:^3

개념 개요

검증은 증거 기반이며 fail-closed입니다. 긍정적으로 확립할 수 없는 검사는 긍정적 결과를 산출하지 않습니다. 아래 구성 요소들은 하나의 ValidationReport에 담기는 단일 결과를 이룹니다.

CMS / 타임스탬프 토큰 암호학적 검증. 자체 완결형의 엄격한 한정 길이(definite-length) DER 스택이 CMS SignedData와 RFC 3161 타임스탬프 토큰을 파싱합니다. 토큰은 정확히 하나의 SignerInfo를 담고, 서명된 속성이 엄격하게 파싱되며, 서명자 인증서가 해석되고, message-digest 속성이 다시 계산된 다이제스트와 일치하며, 필수 서명 인증서(ESS signing-certificate-v2) 바인딩이 성립하고, SignerInfo 서명이 다시 태그된 서명된 속성에 대해 검증될 때에만 허용됩니다. 다이제스트 일치 규칙은 RFC 5652 §5.6 / §5.4 검증 모델을 따릅니다. 수신자가 콘텐츠 메시지 다이제스트를 다시 계산하고, 그 값이 messageDigest 서명된 속성과 같을 때에만 서명이 유효합니다 — 검증기는 생성자가 제공한 다이제스트를 결코 신뢰하지 않습니다.

genTime 시점의 TSA 인증서 검증. 타임스탬프의 genTime은 토큰이 생성된 UTC 시각입니다(RFC 3161 §2.4.2). TSA 서명 인증서는 “현재”가 아니라 그 시각에 검증됩니다. 확장 키 사용(EKU)은 단일의 critical id-kp-timeStamping이어야 하며(RFC 3161 §2.3), 유효 기간, 체인, 신뢰 앵커 출처, 폐기 상태는 모두 genTime을 기준으로 평가됩니다. 구조적으로는 적격하더라도 구성된 신뢰 앵커에 도달하지 못하는 체인은 결코 긍정적 결과를 뒷받침할 수 없습니다.

분리형(detached) PAdES 기본 문서 서명. 구체적인 추출기가 분리형 문서 서명에 대해 실제 AdES / PAdES 기본 검증을 수행합니다. 서명된 바이트 범위에 대해 메시지 다이제스트를 다시 계산해 비교하고, 서명을 검증하며, 서명 인증서 바인딩을 필수로 요구합니다. 이는 이전의 구조 전용 폴백을 대체합니다. 타임스탬프 검증기와 문서 서명 추출기는 동일한 ESS 발급자 및 일련번호 검증기를 공유하므로 인증서 바인딩 파싱에서 서로 어긋날 수 없습니다.

아카이브 DocTimeStamp 커버리지 체인. validateArchivalTimestampChain()은 PDF 바이트 범위에 대한 신뢰된 DocTimeStamp 토큰 체인을 B-LTA 아카이브 증거로 검증합니다. 각 토큰의 임프린트는 자신이 커버하는 실제 ByteRange 바이트에 바인딩되고, 체인은 엄격한 ETSI 순서를 따르며, 모든 토큰의 TSA 체인이 신뢰 앵커에 묶이고, 체인은 파일을 그 end-of-file 마커까지 커버해야 합니다. 완전하고, 신뢰 앵커에 묶이며, EOF까지 커버하는 체인에 대해서만 완전 통과 결과에 도달합니다.

인증서 정책 처리(RFC 5280 §6.1.4). 경로 검증은 전체 인증서 정책 처리를 적용합니다. 노드 구조의 정책 트리, anyPolicy 폴백을 갖춘 정책 매핑, policyConstraints / inhibitAnyPolicy 폴딩을 fail-closed 정책 확장 DER 리더가 뒷받침합니다. 경로 처리 상태 변수 explicit_policy와 inhibit_anyPolicy(RFC 5280 §6.1.2)는 비어 있지 않은 유효 정책 트리가 필요한지를 결정합니다. 마무리 단계는 유효 정책 트리를 user-initial-policy-set과 교집합합니다(RFC 5280 §6.1.4). 필수 정책이 없고 anyPolicy가 허용되면 처리가 제약되지 않습니다 — 이것이 기본값이며, 이전 동작에서 변경되지 않았습니다.

지원 알고리즘

검증 측은 아래 알고리즘 집합을 허용하며, 그 밖의 어떤 것에 대해서도 fail-closed합니다. 지원되지 않는 알고리즘은 거부된 검증이며, 결코 조용히 통과하지 않습니다.

계열	지원	비고
RSA (PKCS#1 v1.5)	`rsaEncryption`(SHA-2 사용), 그리고 `sha*WithRSAEncryption` OID	허용됨
ECDSA	곡선 P-256, P-384, P-521	허용됨
RSASSA-PSS	—	지원되지 않음 → fail-closed
EdDSA	—	지원되지 않음 → fail-closed
SHA-3 다이제스트	—	지원되지 않음 → fail-closed
SHA-1	—	약함: SHA-1로 검증되는 기본 서명은 통과가 아니라 암호학적 제약(crypto-constraints) 실패로 격하됩니다

API 표면

검증 측은 공개 엔진과 Core / Pki 계약을 통해 사용됩니다. 구체적인 전략 클래스는 내부용입니다.

유형	종류	역할
`AdESValidationEngine`	클래스	검증 측 진입점: 서명 및 아카이브 체인 검증.
`AdESValidationEngine::validateArchivalTimestampChain()`	메서드	PDF 바이트 범위에 대한 신뢰된 DocTimeStamp 커버리지 체인을 검증합니다.
`ValidationReport`	결과	구조화된 결과: 전체 상태와 검사별 발견 사항.
`PathValidatorInterface`	인터페이스(`NextPDF\…\Pki`)	엔진이 의존하는 인증 경로 검증 SPI.
`PathValidationOptions`	값 객체	정책 처리 제어: `requireExplicitPolicy`, `inhibitAnyPolicy`, `inhibitPolicyMapping`, `maxPolicyFanout`.
`TrustAnchorStoreInterface`	인터페이스	체인을 평가할 때 기준이 되는, 호출자가 제공한 신뢰 앵커 집합.

아카이브 체인 메서드의 시그니처는 다음과 같습니다.

public function validateArchivalTimestampChain(
    string $pdfBytes,
    array $dssData = [],
    ?TrustAnchorStoreInterface $anchors = null,
): ValidationReport;

DocTimeStamp 체인이 완전히 검증되고, 신뢰 앵커에 묶이며, 파일을 그 EOF 마커까지 커버할 때에만 완전 통과 결과에 도달합니다.

CertificateChainValidator::validate()는 초기 정책 집합(RFC 5280 user-initial-policy-set)을 받습니다. 기본값은 anyPolicy — 제약 없음 — 이므로 일반적인 체인은 영향을 받지 않습니다. 명시적 집합을 전달하거나, 비어 있지 않은 유효 정책 트리를 요구하려면 requireExplicitPolicy를 설정하십시오.

코드 샘플 — 빠른 시작

use NextPDF\Enterprise\Security\Validation\AdESValidationEngine;

$report = $engine->validateArchivalTimestampChain($pdfBytes, [], $trustAnchors);

if ($report->isTotalPassed()) {
    // A complete, trust-anchored, EOF-covering DocTimeStamp chain.
}

코드 샘플 — 프로덕션

use NextPDF\Enterprise\Security\Validation\AdESValidationEngine;
use Psr\Log\LoggerInterface;

final readonly class ArchivalEvidenceCheck
{
    public function __construct(
        private AdESValidationEngine $engine,
        private LoggerInterface $logger,
    ) {}

    public function check(string $pdfBytes, TrustAnchorStoreInterface $anchors): bool
    {
        $report = $this->engine->validateArchivalTimestampChain($pdfBytes, [], $anchors);

        foreach ($report->findings as $finding) {
            $this->logger->info('archival.finding', [
                'check'  => $finding->checkId,
                'status' => $finding->status->value,
            ]);
        }

        // A positive result proves byte-range coverage by a trusted timestamp
        // chain — it is one input to your decision, not a legal conclusion.
        return $report->isTotalPassed();
    }
}

동작 변경 및 업그레이드 참고 사항

검증 측은 구조적 / 시간적 수용에서 완전한 암호학적 검증으로 전환되었습니다. 더 관대했던 이전 동작에 의존하던 호출자는 다음 변경 사항을 검토해야 합니다.

인식되지만 검증할 수 없는 타임스탬프에 대한 fail-closed. 이전에 구조적·시간적 근거로 통과되던 DocTimeStamp 또는 아카이브 토큰은 이제 완전한 암호학적 검증 — 서명, message-digest, 서명 인증서 바인딩 — 을 요구합니다. 검증되지 않는 토큰은 더 이상 긍정적인 존재 증명을 산출하지 않으며, indeterminate 또는 실패 결과에 매핑됩니다.
SHA-1 기본 서명은 통과가 아니라 격하됩니다. 검증은 되지만 SHA-1을 사용하는 기본 문서 서명은 완전 통과가 아니라 암호학적 제약(crypto-constraints) 실패로 보고됩니다.
RFC 5280 §6.1.4 인증서 정책 처리가 강제됩니다. explicit_policy가 비어 있는 유효 정책 트리와 함께 0에 도달하는 체인은 이제 실패합니다 — 체인 내부의 policyConstraints requireExplicitPolicy가 이를 유발하는 경우를 포함합니다. 기본적으로 제약이 없는 체인(필수 정책 없음, anyPolicy 허용)은 영향을 받지 않습니다.
생성자 시그니처 변경(BC break). AdESValidationEngine::__construct()는 이제 $chainValidator 매개변수를 Pki\PathValidatorInterface SPI로 타이핑하며, Pki\CertificateChainValidator::withDefaults()으로 지연 기본값을 갖습니다. 이전에는 구체 클래스인 Ltv\CertificateChainValidator였습니다. 구체 LTV 검증기를 주입하던 호출자는 대신 Pki SPI 구현을 주입해야 합니다. Pki 검증기는 동일한 구조적 경로 엔진을 래핑하며 이름 제약(name-constraints)과 정책 처리를 추가합니다. 적합한 기본 입력에 대해서는 no-op입니다.

엣지 케이스 및 주의 사항

지원되지 않는 알고리즘 ≠ 불확정(inconclusive). RSASSA-PSS, EdDSA, SHA-3은 보류되는 것이 아니라 fail-closed로 거부됩니다. 서명자가 그것들을 사용한다면, 이 검증 측은 해당 서명에 대해 긍정적 결과를 반환하지 않습니다.
신뢰는 앵커에 상대적입니다. 검증은 항상 사용자가 제공하는 신뢰 앵커 저장소에 상대적입니다. 비어 있거나 잘못된 앵커 집합은 암호학적 정확성과 무관하게 not-trusted 결과를 산출합니다.
genTime이지, 현재가 아닙니다. TSA 인증서는 토큰의 genTime에 판정됩니다. 이후 만료된 TSA 인증서라도 유효했던 동안 생성된 토큰은 여전히 뒷받침할 수 있습니다. genTime에 아직 유효하지 않은 인증서는 뒷받침할 수 없습니다.
EOF 커버리지. 아카이브 체인은 문서를 그 EOF 마커까지 커버해야 합니다. 파일의 앞부분만 커버하는 타임스탬프는 문서 전체 커버리지를 확립하지 못합니다.
Not-proven-revoked는 Good이 아닙니다. Valid 판정에는 폐기되지 않았음이 결정적으로 확인된 상태가 필요합니다. OCSP와 CRL이 모두 Unknown 또는 Unavailable로 반환되면, 암호학적으로 건전하고 체인이 유효하며 신뢰 앵커에 묶인 서명이라도 Indeterminate로 귀결됩니다 — Valid에 도달하려면 서명자 인증서에 대한 임베디드 OCSP/CRL Good 자료를 제공하십시오.

성능

검증은 제공된 PDF 바이트와 임베디드 검증 자료에 대해 프로세스 내부에서 수행됩니다. 비용은 체인 길이와 타임스탬프 수에 따라 증가합니다. 검증 중에는 네트워크 왕복이 발생하지 않습니다 — 폐기 및 신뢰 자료는 호출자가 제공하거나 문서에 임베디드된 자료에서 가져옵니다. 검증은 결정적입니다. 동일한 입력과 동일한 신뢰 앵커는 동일한 보고서를 산출합니다.

보안 참고 사항

fail-closed가 기본값입니다. 모든 허용 단계는 긍정적으로 검증할 수 없는 자료의 수용을 거부합니다. 이는 문서가 엔진이 결코 확립하지 않은 유효성을 표시하는 것을 방지합니다.
Append-after-timestamp는 EOF 커버리지로 무력화됩니다. 각 아카이브 타임스탬프의 임프린트가 실제 ByteRange 바이트에 바인딩되고 체인이 EOF에 도달해야 하므로, 타임스탬프 이후에 추가된 콘텐츠는 해당 타임스탬프로 커버되지 않으며 그 증거력을 얻지 못합니다.
입력을 적대적인 것으로 취급하십시오. 신뢰할 수 없는 출처의 PDF 바이트, 임베디드 CMS, 타임스탬프 토큰은 잘못되었거나 비한정 길이(indefinite-length) 인코딩을 거부하는 엄격한 한정 길이 DER 리더로 파싱됩니다.

데이터 레지던시 및 PII 완화

검증은 네트워크 I/O 없이 로컬 프로세스 내부에서 수행됩니다. 인증서와 서명은 주체 신원을 담습니다. 보고서와 추출된 인증서 데이터에 대해 자체적인 보존 및 최소화 통제를 적용하십시오.

안전한 텔레메트리 및 로그 스크러빙

발견 사항은 검사 식별자와 상태를 담습니다. 일부 진단은 인증서 주체 이름이나 일련번호를 노출할 수 있습니다. 로그를 공유 싱크로 전달하기 전에 해당 필드를 스크러빙하거나 마스킹하십시오.

범위 경계

긍정적 결과가 과도하게 해석되지 않도록 이러한 사항을 사용자에게 표시되는 출력에 명시하십시오.

validateArchivalTimestampChain()은 바이트 범위 커버리지를 증명하며, xref 도달 가능성을 증명하지 않습니다. 이는 신뢰된 타임스탬프 체인이 문서의 바이트 범위를 EOF까지 암호학적으로 커버함을 확립합니다. xref 수준 또는 startxref 객체 도달 가능성 분석은 수행하지 않습니다. 이는 설계상 범위 밖입니다. Append-after-timestamp 공격은 객체 그래프 분석이 아니라 EOF 커버리지 규칙과 신뢰 앵커링이 함께 무력화합니다.
설계상 범위 밖. 증거 레코드(RFC 4998 / RFC 6283), RSASSA-PSS·EdDSA·SHA-3 타임스탬프 토큰의 검증, 신뢰 목록(TSL) 및 적격 TSA 통합, 온라인 TSA 폐기 정보 페치는 이 검증 측에서 제공하지 않습니다. 폐기는 검증기가 이미 사용할 수 있는 자료에서 평가됩니다.

적합성

동작	참조	상태
서명 값 / 타임스탬프 토큰을 DER 인코딩으로 저장하는 `/Contents`	ISO 32000-2 §12.8.1	파싱 및 검증됨
문서 타임스탬프 딕셔너리	ISO 32000-2 §12.8.5	아카이브 체인을 위해 읽음
수신자가 콘텐츠 다이제스트를 다시 계산하며, 이는 messageDigest 속성과 같아야 함	RFC 5652 §5.6 / §5.4	강제됨
TSA 인증서가 단일 critical `id-kp-timeStamping` EKU를 가짐	RFC 3161 §2.3	genTime에 확인됨
genTime은 UTC 생성 시각	RFC 3161 §2.4.2	검증 시각으로 사용됨
정책 처리 상태 변수(`explicit_policy`, `inhibit_anyPolicy`)	RFC 5280 §6.1.2	처리됨
마무리 단계가 유효 정책 트리를 user-initial-policy-set과 교집합함	RFC 5280 §6.1.4	강제됨
장기 서명을 위한 DSS 엔트리 및 문서 타임스탬프	ETSI EN 319 142-2 §5.5	아카이브 증거로 검증됨

모든 조항은 의역되었습니다. NextPDF는 규범 텍스트를 재현하지 않습니다. 권위 있는 문구는 발행된 표준을 참조하십시오. NextPDF는 어떠한 AdES / PAdES 인증(certification) 주장도 하지 않습니다. 검증 측은 인용된 명세가 기술하는 암호학적 검사를 구현합니다. 인증된(certified) 검증 서비스가 아니며 제3자 증명을 산출하지 않습니다.

FIPS 모드 동작

Enterprise FIPS 프로필이 활성화되면, 제약은 검증기가 허용하는 다이제스트 및 서명 알고리즘에 적용됩니다. 검증 로직 — 다이제스트 재계산, 서명 확인, 인증서 바인딩, 경로 검증 —은 변경되지 않습니다.

위협 모델

자산	공격자	위험	완화
타임스탬프 토큰	위조되거나 변조된 토큰	거짓 존재 증명	완전한 암호화 검증; 검증할 수 없는 어떤 것에 대해서도 fail-closed
TSA 인증서	신뢰할 수 없는 발급자	검증기가 단언해서는 안 되는 표면적 신뢰	체인이 genTime에 호출자가 제공한 앵커 기준으로 검증됨; 신뢰할 수 없는 체인은 결코 통과하지 않음
문서 바이트	Append-after-timestamp	콘텐츠가 커버리지 없이 타임스탬프의 증거력을 얻음	임프린트가 실제 ByteRange 바이트에 바인딩됨 + EOF 커버리지 규칙
약한 알고리즘	SHA-1 / 지원되지 않는 방식으로의 다운그레이드	약한 서명이 유효한 것으로 읽힘	SHA-1 격하; RSASSA-PSS / EdDSA / SHA-3 fail-closed

에디션 게이트

이 검증 측은 Enterprise 기능이며 nextpdf/enterprise 패키지로 제공됩니다. NextPDF Core는 서명 존재를 감지하고 B-B / B-T 서명을 생성합니다. 이 암호학적 검증 측은 제공하지 않습니다. 라이선스 받기.

라이선스 기능 플래그

검증 측은 Enterprise 에디션(license_feature_flag: enterprise)으로 게이트됩니다. 이는 Core 및 Pki 계약을 통해 해석되며, 에디션 업그레이드 시 공개 API는 변경되지 않습니다.

동작 계약

CMS 또는 타임스탬프 토큰은 정확히 하나의 SignerInfo, 엄격하게 파싱된 서명된 속성, 해석된 서명자 인증서, 일치하는 message-digest, 필수 서명 인증서 바인딩, 그리고 검증되는 SignerInfo 서명을 갖춘 경우에만 허용됩니다.
TSA 인증서는 토큰의 genTime에 검증됩니다: 단일 critical id-kp-timeStamping EKU, 유효 기간, 신뢰 앵커에 묶인 체인, 폐기.
최종 Valid 판정은 추가로 결정적으로 폐기되지 않았음이 확인된 상태를 요구합니다 — 적어도 하나의 권위 있는 Good(검증된-양호 OCSP 응답, 또는 일련번호가 만료되지 않은 목록에 포함되지 않았음을 보여 주는 신선한 CRL). 단지 not-proven-revoked일 뿐이고 OCSP와 CRL이 모두 Unknown 또는 Unavailable인 상태는 Indeterminate로 귀결되며, 결코 Valid가 아닙니다(ETSI EN 319 102-1: 폐기 상태 사용 불가 → INDETERMINATE). CRL 폴백 경로는 목록 신선도만 증명하고 일련번호별 폐기는 증명하지 않으므로, Good OCSP 없는 CRL 전용 체인은 흔히 Indeterminate입니다.
validateArchivalTimestampChain()은 완전하고, 신뢰 앵커에 묶이며, EOF까지 커버하는 DocTimeStamp 체인에 대해서만 완전 통과 결과에 도달합니다. 이는 바이트 범위 커버리지를 증명하며, xref 도달 가능성을 증명하지 않습니다.
인증서 정책 처리는 RFC 5280 §6.1.4 를 따릅니다. 기본의 제약 없는 체인은 영향을 받지 않습니다.
지원 알고리즘은 RSA(PKCS#1 v1.5, SHA-2)와 ECDSA(P-256/384/521)입니다. RSASSA-PSS, EdDSA, SHA-3은 fail-closed이고, SHA-1은 격하됩니다.

NDA 스캔 상태

이 공개 페이지는 외부에서 관찰 가능한 검증 측 동작만 기술합니다. 공개 엔진, Pki / 신뢰 앵커 계약, 그리고 지원되는 표면을 통한 validateArchivalTimestampChain() 메서드를 명명합니다. 구체적인 DER, CMS, 정책 처리기, 경로 검증기 내부는 NDA에 따라 게이트된 심층 레퍼런스에 있습니다.

Core 폴백

NextPDF Core는 서명의 존재를 감지하고 B-B / B-T 서명을 생성하지만, CMS나 타임스탬프 토큰을 암호학적으로 검증하거나, 아카이브 체인을 검증하거나, RFC 5280 §6.1.4 정책 처리를 실행하지는 않습니다. Core 전용 배포에는 동등한 검증 측이 없습니다. Security / Signing (Core)을 참조하십시오.

Pro 폴백

NextPDF Pro는 서명 전략과 전자 송장(e-invoice) 처리를 추가하지만 이 암호학적 검증 측은 제공하지 않습니다. 아카이브 체인 검증과 인증서 정책 처리는 nextpdf/enterprise에만 제공됩니다.

Enterprise 경계 참고

검증 측은 동작 수준에서 기술됩니다. 엄격한 DER 스택, CMS 파서, 정책 처리기, 경로 검증기 내부는 공개 표면의 범위 밖이며 여기서 재현하지 않습니다.

배포 경계

검증은 신뢰 앵커 저장소와, 호출자가 제공하거나 문서에 임베디드된 폐기 자료에 의존합니다. NextPDF Enterprise는 그 자료를 평가합니다. 신뢰 목록, TSA, 폐기 서비스를 운영하지는 않습니다. 운영자가 앵커 선택과 임베디드 폐기 자료의 신선도를 책임집니다.

법적 컴플라이언스 경계

이 페이지는 export_control_class: legal-review-required로 표시되어 있습니다. 이는 암호학적 검증에 관한 것입니다. publish 플래그를 설정하기 전에 법무 승인이 필요합니다. 긍정적 검증 결과는 문서의 서명과 타임스탬프에 관한 암호학적 진술입니다 — 법적 의견, eIDAS 적격성 판정, 또는 인증(certification)이 아닙니다. NextPDF는 어떠한 AdES / PAdES 인증(certification) 주장도 하지 않습니다. 귀하의 규제 의무에 대해서는 자체 컴플라이언스 및 법률 자문에 문의하십시오.