TgWitness / 문서

참고 문헌 / 증거

타임스탬프

서명된 체크포인트에 대한 RFC 3161 타임스탬프: 인증 기관에 전송되는 내용과 응답을 검증하는 방법.

TgWitness는 RFC 3161 요청을 생성하고 타임스탬프 인증 기관(TSA)의 응답을 검증합니다. 이 수동 절차는 TSA를 선택하거나 데이터를 제출하지 않지만, 증거 모드는 일정에 따라 두 가지 작업을 모두 수행합니다(증거 형식). 생성된 요청만으로는 아직 타임스탬프 증거가 아닙니다.

증거가 입증하는 바#

흐름도계정 관찰 사항 → SHA-256 체인 및 Ed25519 서명; SHA-256 체인 및 Ed25519 서명 → 서명된 체크포인트; 서명된 체크포인트 → 정확한 바이트 단위 해시 및 무작위 논스; 정확한 바이트 단위 해시 및 무작위 논스 → RFC 3161 요청; RFC 3161 요청 → 독립적인 TSA; 독립적인 TSA → 서명된 TSA 응답; 서명된 체크포인트 → 데이터, 논스(nonce) 및 명시적 CA 신뢰도 확인; 서명된 TSA 응답 → 데이터, 논스(nonce) 및 명시적 CA 신뢰도 확인계정관찰사항SHA-256 체인및 Ed25519서명서명된체크포인트정확한바이트단위해시및무작위논스RFC 3161 요청독립적인 TSA서명된 TSA 응답데이터, 논스(nonce) 및명시적 CA 신뢰도확인
도표를 텍스트로 변환
  1. 계정 관찰 사항 → SHA-256 체인 및 Ed25519 서명
  2. SHA-256 체인 및 Ed25519 서명 → 서명된 체크포인트
  3. 서명된 체크포인트 → 정확한 바이트 단위 해시 및 무작위 논스
  4. 정확한 바이트 단위 해시 및 무작위 논스 → RFC 3161 요청
  5. RFC 3161 요청 → 독립적인 TSA
  6. 독립적인 TSA → 서명된 TSA 응답
  7. 서명된 체크포인트 → 데이터, 논스(nonce) 및 명시적 CA 신뢰도 확인
  8. 서명된 TSA 응답 → 데이터, 논스(nonce) 및 명시적 CA 신뢰도 확인

수집자의 서명은 기록을 해당 키에 바인딩합니다. 신뢰할 수 있는 TSA 응답을 통해 TSA가 명시한 시각에 특정 체크포인트가 존재했음을 입증할 수 있습니다. 그러면 해당 체크포인트는 저널 접두사를 바인딩할 수 있습니다. 이는 각 텔레그램 작업의 발생 시각이나 캡처된 콘텐츠의 진위를 입증하는 것은 아닙니다.

절차#

  1. 별도의 신뢰할 수 있는 채널을 통해 수집기 키 지문을 보관하십시오. 조사 대상 ZIP 파일에서만 제공되는 키만으로는 수집기를 식별하기에 불충분합니다.
  2. ‘내보내기 → 타임스탬프 요청 준비’에서 선택한 작업 공간의 요청 ZIP 파일을 다운로드합니다. checkpoint.json, timestamp.tsq, SHA256SUMS 및 README.txt 파일을 추출합니다. 체크포인트 바이트는 변경하지 마십시오.
  3. 조사에 적합한 TSA를 선택하십시오. 문서화된 방법을 사용하여 timestamp.tsq를 제출하고, HTTP 서비스의 경우 application/timestamp-query를 함께 제출하십시오. 원본 바이너리 응답을 timestamp.tsr로 저장하고, 엔드포인트, 검색 시간 및 요청 결과를 기록하십시오. 요청에는 메시지 대신 해시와 논스가 포함되며, 네트워크 메타데이터를 통해 요청 내용을 여전히 파악할 수 있습니다.
  4. 응답 내용과 관계없이 신뢰할 수 있는 루트 인증서와 필요한 중간 인증서를 별도로 확보하십시오. 응답에 포함된 인증서가 단순히 거기에 포함되어 있다는 이유만으로 신뢰할 수 있는 인증서가 되는 것은 아닙니다.
  5. 신뢰할 수 있는 TgWitness 설치 환경에서 다음 사항을 확인하십시오:
python -m tgwitness.anchor verify --checkpoint checkpoint.json --request timestamp.tsq --response timestamp.tsr --ca trusted-tsa-root.pem

필요한 경우 --intermediates tsa-intermediates.pem 또는 --openssl /path/to/openssl를 추가하십시오. OpenSSL은 ts를 지원해야 합니다. Windows에서는 검증기가 표준 Git 설치 경로도 검색합니다. OpenSSL 3.5.9는 합성 CA/TSA를 사용하여 로컬에서 테스트되었습니다.

  1. 체크포인트 이후에 서명된 기록 ZIP 파일을 내보내면 해당 접두사가 포함됩니다. 독립적으로 확인된 지문을 사용하여 검증하십시오:
python tgwitness/verify.py evidence.zip --fingerprint TRUSTED_SHA256 --checkpoint checkpoint.json
  1. ZIP 파일, 체크포인트, 요청, 응답, 인증서 체인, 검증 결과 및 수집기 외부에서의 인계 기록을 보존합니다. 수신 시 검증을 반복합니다.

저장된 체크포인트에서 요청을 준비하려면:

python -m tgwitness.anchor prepare checkpoint.json --out timestamp-request.zip

이 준비 과정은 JSON을 정규화하고 해당 체크포인트를 아카이브에 포함시킵니다. 입력 파일의 공백 처리 방식이 달랐더라도, TSA 검증을 위해 해당 아카이브의 체크포인트 바이트를 사용하십시오.

검증 범위#

확인 현재 동작
데이터 정확한 체크포인트 바이트의 SHA-256 해시가 응답과 일치해야 합니다.
요청 --request를 통해 원본 쿼리와 논스가 검증됩니다.
TSA 서명 OpenSSL은 서명과 명시된 CA까지의 인증 체인을 검증합니다.
수집기 서명 고정된 키를 사용하여 저널 검증자가 별도로 검증함
취소 자동 OCSP/CRL 검색 기능 없음
장기적인 유효성 인증서 만료 후 아카이브 유효성 검증 불가
예정된 제출 증거 모드, 기본적으로 비활성화됨

--request는 기술적으로 선택 사항이지만, 이를 생략하면 원본 논스(nonce)의 검증이 불가능해집니다. 이 전체 절차를 수행하려면 결과인 request_checked가 참(true)이어야 합니다. 인증서 검증은 설치된 OpenSSL의 규칙과 검증 시간을 따릅니다. 장기 보존을 위해서는 별도의 인증서/해지 증거 정책이 필요합니다.

유효한 암호화 서명이 자동으로 적격 타임스탬프나 법적 증거 능력 판단을 의미하는 것은 아닙니다. 운영자가 타임스탬프를 찍기 전에 관측 내용을 조작한 경우, TSA는 해당 바이트를 고정할 뿐, 그 진실성을 입증하지는 않습니다.

인계 기록#

사건 식별자, 발신자 및 수신자, UTC 전송 시간 및 그 출처, 목적, 파일명/SHA-256 값, 수집기 지문, 시퀀스 범위, 알려진 누락 부분, 검증기 버전 및 검증 결과를 기록합니다. 조직의 절차에 따라 이 기록에 서명하고 독립적으로 보관하십시오. TgWitness에는 다중 사용자 보관 기록 시스템이 구현되어 있지 않습니다.

개발 과정에서 독립적인 실시간 TSA와는 연락을 취하지 않았습니다. 로컬 테스트에서는 호환성 및 변경된 데이터, 논스(nonce) 또는 CA에 대한 거부 여부를 확인하기 위해 합성 CA/TSA를 생성합니다.