콘텐츠로 이동

타임스탬프와 신뢰할 수 있는 시간

Spec: RFC 3161 Spec: RFC 5816 Spec: ISO 32000-2, §12.8.5 Evidence: Standard-backed

타임스탬프는 “이것이 언제 서명되었는지”를 기록하지 않습니다. 타임스탬프는 더 좁지만 더 강력한 사실을 증명합니다. 특정 데이터가 특정 시점 이전에 존재했음을 서명자가 아닌 제3자가 입증했다는 사실입니다. 이 구분이 바로 신뢰할 수 있는 시간의 가치 전체이며, 가장 흔히 오해되는 지점입니다.

서명 안에 포함된 서명 시각은 서명자의 컴퓨터가 주장한 값일 뿐입니다. 시계는 실수로든 의도적으로든 틀릴 수 있습니다. 언제에 대한 유일한 증거가 서명자 자신의 주장뿐이라면, 서명자는 문서의 시점을 마음대로 앞당기거나 늦출 수 있습니다. 어제 폐기된 인증서가 마치 작년에 서명한 것처럼 보이게 만들 수 있습니다. “언제”는 사소한 세부 사항이 아닙니다. 이는 지금은 만료되었거나 폐기된 인증서로 만든 서명이 여전히 유효한지를 결정합니다. 그리고 신뢰할 수 있는 시간이 틀리면, 그 위에 쌓은 모든 장기 유효성 논리가 무너집니다.

  • 서명자 자신의 서명 시각은 증거가 아니라 주장입니다. 이는 쉽게 조작할 수 있습니다.
  • RFC 3161 타임스탬프는 시각 인증 기관(TSA)이 발급한 서명된 토큰으로, 데이터의 해시TSA의 시간에 결속합니다.
  • 그것이 증명하는 바는 정밀합니다. 데이터가 TSA가 명시한 시간 이전에 존재했다는 것입니다. 정확한 생성 순간이 아니라 상한값입니다.
  • 토큰은 사용자의 **논스(nonce)**와 **메시지 임프린트(message imprint)**를 되돌려 주므로, 응답이 재전송 공격의 결과일 수 없고 다른 데이터에 관한 것일 수도 없습니다.
  • 문서 타임스탬프는 동일한 메커니즘을 PDF 전체에 적용하여, 그 아래에 있는 모든 것, 즉 서명과 그에 포함된 검증 증거를 신뢰할 수 있는 순간에 고정합니다.

NextPDF는 타임스탬프를 단지 획득하는 것이 아니라 검증해야 하는 대상으로 취급합니다. 토큰을 요청하는 것은 작업의 작은 절반에 불과합니다. 엔진의 입장은 검증되지 않은 토큰은 증거가 아니라는 것입니다.

엔진이 서명에 타임스탬프를 적용할 때는 TSA에 데이터의 해시와 새로 생성한 무작위 논스를 보내며, 데이터 자체는 결코 보내지 않습니다. 그 후 반환된 토큰은 증거로 의미를 갖게 하는 전체 속성 집합에 대해 검사됩니다. 응답 상태가 “granted”였는지, 토큰의 논스가 보낸 것과 일치하는지, 토큰의 메시지 임프린트가 보낸 해시와 일치하는지, 토큰 자체의 암호화 서명이 검증되는지, 토큰의 콘텐츠 유형이 타임스탬프 유형인지, 그리고 명시된 시간이 허용 오차 범위 안에 들어오는지입니다. 어떤 불일치든 유형화된 사유와 함께 하드 실패로 처리됩니다. “충분히 비슷해 보인다”는 경로는 없습니다. 문서 타임스탬프도 동일한 규칙을 따르되, 하나의 서명 값이 아니라 파일 전체에 적용합니다.

  1. Hash the data Only a digest of the signature value (or the whole PDF, for a document timestamp) is computed — never the data itself.
  2. Send hash + nonce The digest and a fresh random nonce go to the Time-Stamp Authority.
  3. TSA returns a token A signed token binds the digest to the TSA’s genTime and echoes the nonce.
  4. Verify the token Status granted, nonce matches, message imprint matches, token signature verifies, time within tolerance.
  5. Conclude an upper bound The data provably existed before the TSA’s stated time — attested by a party that is not the signer.
신뢰할 수 있는 타임스탬프가 어떻게 획득되고 무엇을 증명하는지: 해시와 논스를 TSA 에 보내면 TSA 는 그 해시를 자신의 시간에 결속하는 서명된 토큰을 반환하고, 검증자는 그 결속을 확인한 후에야 데이터가 그 시간 이전에 존재했다는 증거로 취급합니다.

Evidence: Standard-backed 그 정의는 정확합니다. Spec: ISO/IEC 18014-2, §3 는 시각 인증 서비스를 데이터 항목이 특정 시점 이전에 존재했다는 증거를 제공하는 서비스로 정의합니다 — 생성 순간이 아니라 상한값입니다. Spec: ISO/IEC 18014-2, §7 는 토큰의 TSTInfo 콘텐츠를 정의합니다. 여기에는 메시지 임프린트(데이터의 해시), 생성 시간, 일련번호, 선택적 논스가 포함됩니다. Spec: ISO/IEC 18014-2, §6 는 검증이 성공했을 때 검증자가 도출할 수 있는 결론을 명시합니다. 데이터 항목이 토큰의 시간 이전에 존재했다는 것, 그 이상도 그 이하도 아닙니다.

PDF의 경우, Spec: ISO 32000-2, §12.8.5 가 문서 타임스탬프를 규정합니다. 바이트 범위는 파일 전체를 포괄하되 Contents 값은 제외하고, 그 해시를 시각 인증 기관에 전송한 뒤 반환된 RFC 3161 토큰 — Spec: RFC 5816 에 의해 갱신된 — 이 Contents에 배치됩니다. 신원이 아니라 시간에 대해 서명과 동일한 바이트 범위 규율을 적용한 것입니다. 그리고 Spec: RFC 6960, §4.4.4 는 이것이 수명 측면에서 중요한 이유를 보여 줍니다. 신뢰할 수 있는 시간은 검증자가 인증서가 만료된 후에도 서명이 생성된 날에는 신뢰할 수 있었음을 증명할 수 있게 해 줍니다.

NextPDF의 엔진은 해시와 논스를 보낼 뿐 데이터는 결코 보내지 않으며, 반환된 토큰을 증거로 취급하기 전에 상태, 논스, 메시지 임프린트, 토큰 서명, 콘텐츠 유형, 시간 허용 오차에 대해 검증합니다.

타임스탬프 토큰을 직접 손으로 조립하지는 않습니다. 중요한 것은 신뢰가 연결되는 지점입니다. TSA는 구성하고 보호해야 하는 대상입니다. 그 시간이 사용자의 증거가 되기 때문입니다.

<?php
declare(strict_types=1);
use NextPDF\Security\Signature\SignatureLevel;
// Asking for any level at or above B-T requires a TSA.
$level = SignatureLevel::PAdES_B_T;
$level->requiresTimestamp(); // true → a Time-Stamp Authority must be supplied
// The TSA endpoint, its transport security, and its trust anchor are
// deployment-supplied. The engine sends a hash plus a fresh nonce — never the
// document — and verifies the returned token before the signature is accepted.
// A token that fails any check (status, nonce, imprint, signature, time)
// is a hard error, not a warning.

주목해야 할 지점은 엔진이 문서가 아니라 해시를 보낸다는 점입니다. 따라서 TSA는 사용자의 콘텐츠를 결코 보지 못합니다. 또한 엔진은 응답을 검증합니다. 검증할 수 없는 TSA는 신뢰할 수 있는 시간이 아닙니다. 그것은 또 하나의 시계일 뿐입니다.

가장 흔한 함정은 타임스탬프를 “이것은 이 날짜 정확히 14:32에 서명되었다”로 읽는 것입니다. 그것은 서명 이벤트를 재는 스톱워치가 아닙니다. 그것은 데이터가 TSA의 시간 이후가 아닌 시점에 존재했음을 증명하며, 이는 제3자가 설정한 상한값입니다. 생성 시점은 그 이전 어느 때였을 수도 있습니다. 두 번째 함정은 어떤 타임스탬프 서버든 신뢰할 수 있는 시간을 제공한다고 가정하는 것입니다. 토큰의 서명을 검증할 수 없거나 발급 기관을 신뢰할 수 없다면, 그 토큰은 아무것도 증명하지 못합니다. 그것은 믿을 이유가 없는 시계입니다. 신뢰할 수 있는 시간은 검증 가능한 TSA 검증을 마친 토큰에서 나오는 것이지, 서버에 숫자를 요청하는 행위에서 나오는 것이 아닙니다.

NextPDF는 요청을 구성하고, 해시만 보내며, 반환된 토큰을 검증합니다. 그러나 그 배후의 기관을 보증하지는 않습니다. TSA의 정확성, 자체 인증서의 유효성, 그리고 신뢰성은 그 서비스와 사용자의 배포 환경 구성의 속성이지 엔진의 속성이 아닙니다. 타임스탬프는 해시시간에 결속합니다. 그것은 데이터의 의미, 서명자의 신원, 또는 서명자의 인증서가 유효했는지에 대해서는 아무것도 말하지 않습니다. 이것들은 서명을 올바르게 검증하기에서 다루는 별도의 검사입니다. 엔진은 신뢰할 수 없는 TSA를 신뢰할 수 있게 만들 수 없습니다. 또한 이 페이지는 타임스탬프에 어떤 특정한 법적 효력도 주장하지 않습니다. 그 효력은 TSA의 상태와 관할권에 달려 있습니다. 수십 년 동안 서명을 검증 가능한 상태로 유지하기 위해 신뢰할 수 있는 시간을 어떻게 재사용하는지는 장기 검증에서 다룹니다.

등급별 타임스탬핑 제공 여부:

RFC 3161 timestamping (signature timestamp and document timestamp) — edition availability
Edition Availability
Core Not in this edition
Pro

PAdES B-T — 배포 환경에서 제공한 TSA에 대해 검증된, 서명 값에 대한 RFC 3161 타임스탬프입니다. TSA는 배포 환경에서 제공합니다.

Enterprise

B-LTB-LTA가 사용하는 문서 타임스탬프를 추가하여, 포함된 검증 증거를 고정하고 아카이브 갱신 루프를 구동합니다.

  • 장기 검증 — 문서 타임스탬프가 포함된 증거를 봉인하고 시간이 지나면서 갱신하는 방법.
  • PAdES 베이스라인 프로파일 — 서명 타임스탬프(B-T)와 문서 타임스탬프(B-LTA)가 레벨 진행에서 어디에 위치하는지.
  • 적격 서명 설명 — 적격 타임스탬프가 eIDAS 신뢰 구도에서 어디에 들어맞는지.
  • 타임스탬프(RFC 3161) — TSA가 발급한 서명된 토큰으로, 데이터의 해시를 TSA의 시간에 결속하여 데이터가 그 시간 이전에 존재했음을 증명합니다.
  • 시각 인증 기관(TSA) — 타임스탬프 토큰을 발급하는 신뢰할 수 있는 서비스.
  • TSTInfo — 토큰의 콘텐츠 구조입니다. 메시지 임프린트, 생성 시간, 일련번호, 선택적 논스를 담습니다.
  • 메시지 임프린트 — 타임스탬프 대상 데이터의 해시로, 토큰에 그대로 반영됩니다.
  • 논스(Nonce) — 요청과 함께 전송되어 토큰에 그대로 반영되는 새로 생성한 무작위 값으로, 응답이 재전송 공격일 수 없게 합니다.
  • 문서 타임스탬프 — PDF 전체에 대한 RFC 3161 타임스탬프(RFC 5816에 의해 갱신됨)로, 서명과 그 증거를 신뢰할 수 있는 순간에 고정합니다.