# 타임스탬프

Canonical page: https://phishdestroy.github.io/TgWitness/ko/docs/reference/timestamp/

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

TgWitness는 RFC 3161 요청을 생성하고 타임스탬프 인증 기관(TSA)의 응답을 검증합니다. 이 수동 절차는 TSA를 선택하거나 데이터를 제출하지 않지만, 증거 모드는 일정에 따라 두 가지 작업을 모두 수행합니다([증거 형식](https://phishdestroy.github.io/TgWitness/ko/docs/reference/evidence/#rfc-3161-preparation-and-response-verification-02)). 생성된 요청만으로는 **아직 타임스탬프 증거가 아닙니다**.

## 증거가 입증하는 바

흐름도 · 계정 관찰 사항 → 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를 생성합니다.