참고 문헌 / 증거
타임스탬프
서명된 체크포인트에 대한 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 신뢰도 확인
수집자의 서명은 기록을 해당 키에 바인딩합니다. 신뢰할 수 있는 TSA 응답을 통해 TSA가 명시한 시각에 특정 체크포인트가 존재했음을 입증할 수 있습니다. 그러면 해당 체크포인트는 저널 접두사를 바인딩할 수 있습니다. 이는 각 텔레그램 작업의 발생 시각이나 캡처된 콘텐츠의 진위를 입증하는 것은 아닙니다.
절차#
- 별도의 신뢰할 수 있는 채널을 통해 수집기 키 지문을 보관하십시오. 조사 대상 ZIP 파일에서만 제공되는 키만으로는 수집기를 식별하기에 불충분합니다.
- ‘내보내기 → 타임스탬프 요청 준비’에서 선택한 작업 공간의
요청 ZIP 파일을 다운로드합니다.
checkpoint.json,timestamp.tsq,SHA256SUMS및README.txt파일을 추출합니다. 체크포인트 바이트는 변경하지 마십시오. - 조사에 적합한 TSA를 선택하십시오. 문서화된 방법을 사용하여
timestamp.tsq를 제출하고, HTTP 서비스의 경우application/timestamp-query를 함께 제출하십시오. 원본 바이너리 응답을timestamp.tsr로 저장하고, 엔드포인트, 검색 시간 및 요청 결과를 기록하십시오. 요청에는 메시지 대신 해시와 논스가 포함되며, 네트워크 메타데이터를 통해 요청 내용을 여전히 파악할 수 있습니다. - 응답 내용과 관계없이 신뢰할 수 있는 루트 인증서와 필요한 중간 인증서를 별도로 확보하십시오. 응답에 포함된 인증서가 단순히 거기에 포함되어 있다는 이유만으로 신뢰할 수 있는 인증서가 되는 것은 아닙니다.
- 신뢰할 수 있는 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를 사용하여 로컬에서 테스트되었습니다.
- 체크포인트 이후에 서명된 기록 ZIP 파일을 내보내면 해당 접두사가 포함됩니다. 독립적으로 확인된 지문을 사용하여 검증하십시오:
python tgwitness/verify.py evidence.zip --fingerprint TRUSTED_SHA256 --checkpoint checkpoint.json
- 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를 생성합니다.