증거 형식

관찰 결과는 결론이 아닙니다. 발신자 ID는 실제 신원을 의미하지 않습니다. 계정에서 확인할 수 있는 서비스 업데이트가 정보의 출처이며, 텔레그램은 제3자 조사관을 위해 이러한 저장된 기록에 암호화 서명을 하지 않습니다.

서명된 증거란 무엇인가#

이 수집 도구는 모든 내보내기 형식을 생성하기 전에 저널 서명을 검증합니다. 이러한 소스 검증을 통해 별도로 다운로드된 CSV 또는 HTML 파일에 서명이 생성되지는 않습니다. 마찬가지로, 유효한 JSONL 이벤트 서명만으로는 첨부 파일의 바이트 정보를 제공하지 않으며, 관찰된 전체 저널이 제공되었음을 독립적으로 입증하지도 않습니다.

조사 업무 인계#

1. 사건 참조 번호, 담당자, 텔레그램 계정 ID, 선택된 정보원, 수집 정책 및 수집 기간을 사건 기록에 기재하십시오. TgWitness는 관찰 내용을 보존하며, 사건 배정 및 증거 관리 기록은 애플리케이션 외부에서 관리됩니다. 실시간 승인 절차를 통해 의도된 수집 설정을 검증하십시오.
2. 수집기의 내보내기 기능을 사용하기 전에 작업 공간의 공개 키 지문을 별도로 보관하십시오. 수집 과정에서 서명된 체크포인트를 수집기 외부에 저장하십시오. 중단 사항 및 계정의 가시성 한계를 기록하십시오.
3. 서명된 ZIP 파일을 내보내고 서명된 실행 영수증을 보관하십시오. 내보낸 저널 경계 지점 이전 또는 해당 지점에 체크포인트를 설정하십시오. 이후의 체크포인트는 이전 내보내기 파일이 너무 짧다는 이유로 이를 올바르게 거부할 수 있습니다. 내보내기 파일에는 패널 필터와 관계없이 전체 작업 공간 저널이 포함되므로, 공유하기 전에 내용을 검토하십시오.

4. 수신자는 신뢰할 수 있는 검증기 사본과 별도로 제공된 지문/체크포인트를 사용하여 ZIP 파일을 검증해야 합니다. Python 환경이 활성화된 신뢰할 수 있는 체크아웃 환경에서 다음을 수행하십시오:

   python -m tgwitness.verify evidence.zip --fingerprint TRUSTED_PUBLIC_KEY_SHA256 --checkpoint retained-checkpoint.json

   두 입력값이 모두 제공되고 승인된 경우, 출력 보고서에 key_pinned: true 및 checkpoint_checked: true 가 성공적으로 표시됩니다. 검증 결과를 그대로 유지하십시오.

   For a handover requiring the final exported record to be witnessed, use
   `--witness witness.zip --witness-fingerprint TRUSTED_WITNESS_SHA256 --require-witness`.
   This refuses an export with an unwitnessed tail. See the
   [witness handover procedure](WITNESS.md#require-a-witnessed-export-boundary).
   

   5. 보관 기록에 아카이브의 SHA-256, 내보내기 경계, 전송 날짜, 발신자 및 수신자를 기록하십시오. 원본 패키지는 그대로 보존하고 사본을 사용하여 작업하십시오. 계정 세션 및 서명 비밀 키가 포함된 애플리케이션의 개인 데이터 디렉터리 대신 증거 파일을 공유하십시오. 전송 시, 내보낸 파일을 암호로 보호된 AES-256 ZIP 파일로 압축할 수 있습니다. 암호는 기밀성만 보호하며 저장되지 않습니다. 수신자는 아카이브를 압축 해제하고, 내부에 포함된 서명된 내보낸 파일이 변경되지 않았음을 확인합니다.
   6. 독립적인 시간 고정(time anchoring)이 필요한 경우, RFC 3161 절차를 따르고 요청, 체크포인트, 신뢰할 수 있는 CA 정보 및 검증된 권한 응답을 보관하십시오. 요청을 준비하는 것만으로는 타임스탬프를 획득할 수 없습니다.

성공적인 검증은 신뢰할 수 있는 수집기 키 및 유지된 경계와 관련하여 무결성을 입증합니다. 원본의 진실성, 텔레그램 메시지의 완전한 전달, 신뢰할 수 있는 시간, 그리고 법적 증거 능력은 별도의 증거가 필요합니다. 이 버전은 아직 실제 텔레그램 환경에서의 적합성 검증이나 독립적인 포렌식/보안 평가를 완료하지 않았습니다.

복사된 수집기 키는 조작된 대체 저널에 서명할 수 있습니다. 독립적으로 보관된 체크포인트 또는 증인 기록과 대조하여 검증하면 이전 접두사가 변경된 것을 감지할 수 있지만, 서명 검증만으로는 이를 감지할 수 없습니다. 위트니스는 수집기가 제시한 내용을 수정하므로, 첫 번째 외부 체크포인트 이전에 조작된 기록의 진위를 독립적으로 입증하지는 못합니다. 클라우드 배포 보고서는 구성 및 수집기가 보고한 측정값을 확인하지만, 부트스트랩 과정에서 개인 키가 복사된 적이 없다는 사실을 입증하지는 않습니다.

Apprise를 통해 전송되는 알림에는 작업 공간 및 채팅 이름과 개수가 포함되며, 삭제 및 편집된 메시지의 짧은 발췌문은 운영자가 해당 기능을 켠 경우에만 추가됩니다(기본적으로 꺼져 있음). 이는 편의성을 위한 신호일 뿐 증거가 아닙니다. 전달이 보장되지 않으며, 관찰된 내용은 일지와 서명된 내보내기 파일에만 기록됩니다. 워크스페이스 프록시를 사용하는 경우 알림도 동일한 경로를 따르며, 이를 사용할 수 없는 서비스와 MTProxy 경로는 거부됩니다.

이벤트 정규화#

해시 입력은 정확히 다음 필드로 구성됩니다:

seq, observed_at, source_at, kind, chat_id, message_id, actor_id, payload, previous_hash

UTF-8을 사용하는 Python 호환 JSON 형식으로 직렬화하며, 객체 키는 정렬되고, ASCII 에스케이핑이 없으며, 의미 없는 공백이 없고, NaN/무한대가 포함되지 않아야 합니다:

json.dumps(value, ensure_ascii=False, sort_keys=True,
           separators=(",", ":"), allow_nan=False).encode("utf-8")

해당 바이트의 SHA-256 값이 이벤트 해시가 됩니다. 서명은 32바이트의 원시 해시에 대해 Ed25519 알고리즘을 적용한 후 Base64로 인코딩됩니다. 첫 번째 previous_hash는 64개의 0으로 구성됩니다. 시퀀스 번호는 1부터 시작하여 1씩 증가합니다. 운영 이벤트를 포함한 모든 이벤트는 하나의 체인을 공유합니다. 중복 전달 억제 기능은 없습니다. 즉, 반복된 관측 결과는 서로 다른 수신 기록일 뿐, 서로 다른 텔레그램 동작을 의미하지는 않습니다.

텔레그램의 원시 날짜는 ISO 문자열이며, 바이너리 필드는 bytes_base64를 포함하는 객체로 변환됩니다. 메시지 본문, 엔티티, 미디어 설명자, 답장 메타데이터, 반응, 및 서비스 작업은 제공된 경우 원시 메시지 메타데이터에 그대로 유지됩니다.

observed_at는 수집기의 UTC 기준 시각입니다. source_at는 제공된 텔레그램 날짜이며, 사용 가능한 경우에만 표시됩니다. 삭제 알림에는 정확한 삭제 시간이 포함되지 않으므로 source_at는 null로 유지됩니다. 전송 수신 순서가 반드시 소스 이벤트 순서와 일치하는 것은 아닙니다. 기록 스냅샷은 오래된 소스 날짜를 사용하지만 현재 관측 시간을 반영합니다.

행위자 의미론#

message.new의 actor_id는 메시지 발신자입니다. message.edited에는 추론된 편집자가 없습니다. payload.sender_id는 관찰된 메시지의 발신자를 기록합니다. 삭제 actor_id는 null로 유지됩니다. 멤버십 서비스 메시지는 모든 제거를 자발적 탈퇴로 간주하지 않고 발신자와 작업 유형을 유지합니다. 원시 참여자 업데이트는 제공된 그대로 actor_id를 유지합니다. 반응 스냅샷은 변경 행위자를 임의로 생성하지 않습니다.

비공개 채팅 및 일반 그룹의 삭제 알림에는 메시지 ID만 포함됩니다. 이러한 채팅은 계정 전체에 걸쳐 하나의 ID 시퀀스를 공유하므로, ID는 해당 계정의 단일 메시지를 식별합니다. 해당 ID를 가진 메시지가 이전에 이 저널에 저장된 적이 있다면, 삭제 내역은 해당 채팅에서 message.deleted로 기록되며, 메서드 이름은 payload.chat_resolution 으로 지정됩니다. 저장된 적이 없는 ID는 chat_id 없이 deletion.unscoped로 유지되며, 어떤 추측도 이루어지지 않습니다. 채널과 슈퍼그룹은 채팅별로 메시지 번호를 부여하며, 이러한 방식으로 일치되는 일은 절대 없습니다. 삭제된 메시지가 관찰 대상 계정에 의해 전송된 경우, payload.deleted_message_was_outgoing이 true가 되지만, 삭제자는 여전히 제공되지 않습니다.

다루는 내용: 연속성, 누락 및 감지되지 않은 ID#

모든 서명된 ZIP 파일에는 coverage.json가 포함되어 있으며, HTML 보고서는 동일한 요약으로 시작됩니다. 또한 verify.py는 파일을 그대로 신뢰하지 않고 events.jsonl를 기반으로 요약 내용을 재계산합니다:

• X부터 Y까지 지속적으로 관찰되었습니다. 기간은 observation.started로 시작하여 일시 정지, 중지, 텔레그램 연결 끊김, 로그아웃, 정상적인 종료 절차 없이 시작된 프로세스, 또는 관찰 중 기록이 전혀 없는 상태가 3분 이상 지속될 때 (하트비트는 1분마다 기록되므로, 기록이 없는 것은 프로세스가 중지되었거나 멈췄거나 컴퓨터가 절전 모드에 들어간 것을 의미합니다). ‘매개변수’에서 하트비트 간격이 변경되면, 각 하트비트 마다 이를 기록하며, 허용되는 기록 공백 시간은 3개의 간격이 되며, 3분 미만일 수는 없습니다.
• ‘공백(Gaps)’ 항목에는 기간 간의 간격과 그 이유가 나열됩니다. 마지막 기록 시점에 여전히 해결되지 않은 공백은 not_resumed_by_last_record로 표시됩니다.
• 메시지 ID가 확인되지 않은 경우. 채팅별로 메시지 번호를 부여하는 채널 및 슈퍼그룹의 경우, 확인된 ID 사이에 누락된 ID는 범위 형태로 나열됩니다. 이러한 ID는 ‘확인되지 않음’ — 삭제됨, 전달되지 않음, 또는 저장된 기록 외부 — 으로 보고되며, 절대 ‘삭제됨’으로 표시되지 않습니다. 비공개 채팅과 일반 그룹은 계정 전체에 걸쳐 동일한 순서 번호를 사용하므로, 해당 부분의 공백은 아무런 의미가 없으며 나열되지 않습니다.
• 채팅 수준의 누락 알림(예: 텔레그램이 특정 채널에서 차이점 복구를 요청하는 경우)은 메모로 간주되며, 전체 기록 범위를 방해하지 않습니다.

‘커버리지(Coverage)’는 이 수집 도구가 무엇을 기록했는지를 설명합니다. 이는 텔레그램이 일정 기간 동안 모든 업데이트를 전달했다는 증거는 아닙니다.

제작자#

증거 ZIP 파일, 채팅 내역 내보내기, 증언 기록부 및 사용자 프로필 파일의 진술서에 포함된 서명된 매니페스트에는 producer (소프트웨어, 버전, 프로젝트(PhishDestroy), 홈페이지 및 소스 저장소)가 포함됩니다. HTML 보고서에도 동일한 행이 표시되며, verify.py 는 이를 검증 결과의 일부로 출력합니다. 이 필드가 생성되기 전에 생성된 아카이브는 이전과 동일하게 검증되며, 생성자가 명시되지 않은 것으로 보고됩니다.

사용자 프로필#

프로필 파일(tgwitness-dossier-v1, JSON)은 요청 시 특정 채팅에 대한 저널에 이미 기록된 내용을 바탕으로 생성되며, 텔레그램에서 어떤 정보도 가져오지 않으며 프로필 내용은 절대 저널에 기록되지 않습니다(프로필 활성화 및 비활성화는 dossier.changed로 기록됨). 저장된 메시지가 있는 모든 사용자에 대해 이름과 사용자 이름 이력, 저장 시점에 표시된 텔레그램 플래그 (봇, 사기, 가짜, 프리미엄, 인증됨, 제한됨, 삭제됨), 프로필 사진 ID, 로컬 아바타 캐시에 저장된 아바타의 SHA-256 및 지각적 해시(pHash, imagehash.phash와 호환), 활동 내역(첫 번째 및 마지막 메시지, 수치, 수정 및 삭제된 공유 내역, UTC 시간대별 메시지), 누가 누구에게 답장했는지, 해당 인물이 글을 작성한 , 해당 인물이 글을 작성한 이 저널 내의 다른 채팅, 언급된 지갑(BTC, EVM, TRON, TON, LTC, DOGE, XMR, SOL; Base58Check 주소는 체크섬 검증을 거침), 전화번호, 사용자 이름 및 텍스트 뒤에 숨겨진 링크를 포함한 링크 등이 포함됩니다.

모든 사실 항목에는 해당 사실이 유래한 저널 기록(seq)이 명시되어 있으며, record_hashes에는 참조된 각 기록의 해시가 저장되어 있습니다. 이 진술은 워크스페이스 키로 서명됩니다:

python verify.py tgwitness-dossier-CHAT.json --fingerprint TRUSTED_SHA256 --evidence tgwitness-evidence.zip

서명을 확인하고, 증거 내보내기 파일 자체(서명, 해시 체인 및 파일)를 검증하며, 참조된 모든 기록이 동일한 작업 공간의 해당 내보내기 파일에 변경 없이 존재하는지 확인합니다. 아바타 해시는 로컬 캐시에서 유래한 것으로 표시됩니다 (저널 기록이 아님). 멘션은 패턴 일치 결과로, 확인해야 할 단서일 뿐 검증된 사실이 아닙니다. 프로필은 채팅별로 활성화되며, 암호로 보호된 AES-256 ZIP 파일로 내보낼 수 있고, 비활성화되거나 채팅이 소스에서 제거되면 삭제됩니다.

독립적인 증인#

증인 기록부(tgwitness-witness-v1)와 해당 채널의 게시물은 verify.py --witness … --channel …를 통해 내보낸 증거 자료와 대조하여 확인됩니다. 독립 증인 항목을 참조하십시오.

매니페스트 및 체크포인트#

manifest.json에는 형식, 내보내기 시간, 공개 키, 지문, 저널 길이, 헤드 해시, 범위, 생성자, 제한 사항 및 manifest.json와 manifest.sig 자체를 제외한 모든 콘텐츠 구성원의 SHA-256 해시가 포함됩니다. manifest.sig는 정규화된 매니페스트 JSON에 대한 base64 Ed25519 서명입니다. 검증기는 예상치 못한 항목이나 누락된 항목, 중복된 이름, 손상된 파일, 파손된 시퀀스/체인, 유효하지 않은 서명, 제공된 체크포인트와의 불일치를 거부합니다. 아카이브 경로는 절대 추출하지 않습니다. 선언된 총 압축 해제 크기를 4 GiB로 제한하며, 매개변수 한도를 높인 --max-gib N를 사용하면 더 큰 아카이브를 만들 수 있습니다.

신뢰할 수 있는 체크아웃 또는 검토를 거친 독립적인 사본에서 검증 코드를 확보하십시오. 신뢰할 수 없는 아카이브 내의 검증 코드는 해당 아카이브 작성자가 제공한 실행 가능한 자료이며, 그 존재는 이식성을 위한 편의일 뿐, 독립적인 신뢰의 근거가 아닙니다.

체크포인트는 공개 키, 저널 길이, 헤드 해시 및 생성 시간을 포함하는 진술서에 서명합니다. 검증자는 이후 아카이브에 동일한 접두사가 포함되어 있는지 확인할 수 있습니다. 분쟁의 소지가 있는 변경이 발생하기 전에 수집기 외부에 체크포인트를 보관하십시오: 아카이브와 체크포인트를 모두 제어하는 공격자는 두 가지를 모두 대체할 수 있습니다.

고정되지 않은 키로 생성된 유효한 서명은 내부적 일관성만을 입증할 뿐입니다. 기록 전에 수집기나 키가 침해된 경우, 고정된 키라 하더라도 원본 콘텐츠의 진실성을 입증할 수 없습니다. 외부 타임스탬핑 및 신뢰할 수 있는 캡처는 별도의 요구 사항입니다. TgWitness는 증거 채택 가능성이나 법의학적 인증을 보장하지 않습니다.

첨부 파일#

파일은 media/ 디렉터리 내에서 SHA-256 해시로 식별됩니다. media.saved 이벤트는 해시와 바이트 길이를 특정 메시지 이벤트에 연결합니다. 원본 파일명은 메타데이터이며, 절대 로컬 경로가 아닙니다. 미디어 바이트는 비동기 방식으로 다운로드되므로, 즉시 삭제할 경우 캡처가 이루어지지 않을 수 있습니다. 수집 비활성화, 크기 초과/알 수 없는 크기의 파일, 다운로드 실패, 및 중단된 다운로드는 결과로 표시됩니다. 프로세스 충돌 시 참조가 없는 부분 파일이 남을 수 있으며, 이러한 파일은 내보내기 대상에 포함되지 않습니다.

ZIP 내보내기 기능은 저장된 미디어 파일을 파일명과 대조하여 검증합니다. JSONL, CSV 및 HTML 내보내기 기능은 이벤트 서명을 검증하지만 미디어 바이트는 포함하지 않습니다. 파생 보고서는 편의상 제공되는 것이며, events.jsonl 파일이 공식적인 이벤트 표현입니다.

내구성 있는 수집 및 처리 영수증 (0.2)#

미디어 작업과 해당 메시지 이벤트 커밋이 하나의 트랜잭션으로 처리됩니다. 이 작업은 원본 TL 메시지 설명자를 저장하며, 서명된 관측 기록은 SHA-256, 계정, 및 크기 정책을 바인딩합니다. 복구 과정에서는 다운로드 전에 해당 바인딩을 검증합니다. 이 도구는 현재 메시지를 가져오지 않으며, 새로운 첨부 파일을 자동으로 대체합니다. 중단된 작업은 재시도되지만, 영구적인 실패는 명시적인 결과로 남습니다.

각 작업 공간에는 고유한 저널과 서명 주체가 있습니다. process.started 이벤트에는 실행 ID, 로컬 시계, 종속성 버전, 소스 파일 해시, 초기 계정/범위, 및 캡처 설정이 포함됩니다. 하트비트에는 실행 ID, 단조로운 시간, 및 큐 상태가 포함됩니다. 프로세스 영수증은 별도로 서명된 명세서로도 다운로드할 수 있습니다. 파일 측정값은 자체 보고된 것이며, 신뢰할 수 있는 하드웨어 인증은 아닙니다.

자동 체크포인트는 시작 시, 모니터링 중 5분마다 (매개변수 → ‘서명된 체크포인트 간격’), 그리고 정상 종료 시 로컬에 보관됩니다. 시작 시 검증 및 내보내기 과정에서는 저널을 가장 최근에 로컬에 보관된 체크포인트와 비교합니다. 이를 통해 체크포인트가 남아 있는 경우 데이터베이스 롤백을 탐지할 수 있으나, 두 가지를 모두 제어하는 운영자는 여전히 둘 다 교체할 수 있습니다. 독립적인 보존 및 외부 신뢰할 수 있는 타임스탬프는 여전히 별도의 요구 사항으로 남아 있습니다.

재시작 후 저장된 텔레그램 업데이트 위치(catch_up_from에서 observation.started)가 재개되며, 누락된 업데이트가 요청됩니다. 주기적인 재확인 과정을 통해 누락된 메시지에 대해서는 message.recovered가 기록되고, 텔레그램이 더 이상 저장된 메시지를 반환하지 않을 경우 message.missing_on_recheck가 기록됩니다. 후자는 삭제 알림이 아니며, 삭제자나 시간을 명시하지 않습니다.

오프사이트 백업 및 복원 (S3)#

오프사이트 사본(내보내기, 기본적으로 비활성화됨)은 저널 세그먼트, 보존된 파일, 체크포인트 및 해당 타임스탬프, 완료된 채팅 내보내기 데이터를 S3 호환 스토리지에 업로드하며, 업로드 전 AES-256-GCM으로 암호화되어 업로드되며, 버킷이 이를 지원하는 경우 Object Lock 보존 정책이 적용됩니다. 다운로드된 키가 없으면 복사본을 읽을 수 없습니다. 복원 및 검증은 python -m tgwitness.replica restore --key-file KEY.json --out DIR 명령어를 사용하여 수행합니다.

복원 작업에는 빈 일반 디렉터리가 필요합니다. 다운로드된 파일과 복호화된 객체는 전체 저널과 모든 보존된 체크포인트가 검증될 때까지 비공개 임시 저장소에 보관됩니다. 안전하지 않은 객체 경로, 일관되지 않은 세그먼트 범위, 체크포인트보다 짧은 저널은 거부되며, 검증에 실패한 경우 복원된 파일은 게시되지 않습니다. 보존 기간 확인은 반환된 오브젝트 잠금 모드와 날짜를 업로드 시 전송된 마감 기한과 비교합니다(1초의 반올림 허용 오차 적용). 만료되었거나, 유효하지 않거나, 단축된 마감 기한은 검증된 것으로 간주되지 않습니다. 상태는 해당 업로드 과정에서 보존 기간 정보가 읽혀진 표본 오브젝트를 보고합니다.

복사 진행 상황은 대상 위치와 암호화 키에 따라 범위가 지정됩니다. 엔드포인트, 버킷 또는 접두사를 변경하면 로컬에 보관된 저널, 미디어 및 체크포인트가 해당 대상 위치로 완전히 복사됩니다. 범위가 지정되지 않은 이전 진행 상황은 보존되지만, 업그레이드 후 한 번만 재실행됩니다. 로컬 발신함에서 이미 삭제된 과거 채팅 내역은 이전 대상 위치에 그대로 남아 있습니다.

누락되거나 손상된 로컬 미디어는 해당 패스의 오류로 보고되며, 미디어 커서는 해당 위치 앞에 유지되므로 다음 패스에서 파일이 다시 시도됩니다. 그 이후의 파일, 체크포인트 및 내보낸 데이터는 여전히 복사됩니다. 복원 과정에서는 보존된 모든 미디어 참조를 복호화된 해시 및 기록된 크기와 대조하여 확인합니다. 중단된 업로드에서 발생한 동일한 중복 저널 세그먼트는 중복 제거되며, 충돌하는 중복 부분은 거부됩니다. 업로드 중에 생성된 체크포인트는 해당 체크포인트가 포함하는 저널 기록이 복사될 때까지 보류되므로, 완료된 패스는 해당 저널보다 앞서 체크포인트를 게시하지 않습니다.

스트리밍 내보내기 스냅샷#

스트리밍 내보내기는 안정적인 SQLite 읽기 스냅샷을 사용합니다. 다운로드가 완료될 때 이 스냅샷의 최상위 항목은 현재의 실시간 저널보다 오래된 것일 수 있습니다. 해당 스냅샷 이후에 생성된 체크포인트는 아카이브의 크기가 더 작다고 올바르게 보고할 수 있습니다. 임의의 이후 체크포인트가 아닌, 내보낸 접두사 시점 또는 그 이전의 체크포인트와 비교해야 합니다.

RFC 3161 준비 및 응답 검증 (0.2)#

증거 모드(기본적으로 비활성화됨)는 각 서명된 체크포인트의 SHA-256 해시값만을 나열된 RFC 3161 인증 기관 및 OpenTimestamps 캘린더로 전송하며, 이 과정은 워크스페이스 경로를 통해 이루어지며 MTProxy를 절대 경유하지 않습니다. 응답은 checkpoints/anchors/에 보관되고, 내보내진 후 verify.py에 의해 검증됩니다(--tsa-ca는 TSA 서명을 검증하며, OpenTimestamps 증명은 ots upgrade 및 ots verify를 통해 확인됩니다).

이 패널은 표준화된 checkpoint.json 바이트, SHA-256 메시지 임프린트, timestamp.tsq 파일 내의 무작위 논스, 체크섬 및 지침이 포함된 요청 아카이브를 생성합니다. 네트워크 요청은 수행되지 않습니다. 이 준비 과정은 신뢰할 수 있는 타임스탬프가 아닙니다.

python -m tgwitness.anchor verify는 OpenSSL ts를 두 번 호출합니다: 한 번은 체크포인트 바이트에 대해, 다른 한 번은 원본 요청에 대해 수행됩니다. 신뢰할 수 있는 CA 파일이 명시적으로 필요하며, 포함된 인증서는 자동으로 신뢰되지 않습니다. CLI에서는 요청 검사가 선택 사항이므로, nonce를 확인하려면 --request 옵션을 유지하고 전달하십시오. 결과에는 검사가 수행되었는지 여부가 표시됩니다. 수집기의 체크포인트 서명과 저널은 여전히 신뢰할 수 있는 수집기 지문을 사용하여 별도로 검증해야 합니다.

현재 검증기는 인증서 취소 정보를 가져오지 않으며, 인증서 만료 후 장기 보관 검증 기능도 구현하지 않습니다. 서명 검증의 성공을 공인 타임스탬프나 법적 증거 능력으로 간주해서는 안 됩니다. 개발 과정에서 실제 독립적인 TSA(인증서 타임스탬프 기관)와는 연락을 취하지 않았습니다. 절차를 참조하십시오.