# Метки времени

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

Временные метки RFC 3161 для подписанных контрольных точек: что отправляется в центр авторизации и как проверяется ответ.

TgWitness формирует запросы в соответствии со стандартом RFC 3161 и проверяет ответы от органа временных меток (TSA). Данная ручная процедура не предусматривает ни выбора TSA, ни отправки данных; режим сбора доказательств выполняет обе эти операции в соответствии с графиком ([формат доказательств](https://phishdestroy.github.io/TgWitness/ru/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 время. Затем контрольный пункт может привязать префикс журнала. Это не устанавливает время каждого действия в Telegram или достоверность зафиксированного содержания.

## Порядок действий

1. Храните отпечаток ключа сборщика через отдельный доверенный канал. Ключа, предоставленного исключительно из проверяемого ZIP-файла, недостаточно для идентификации сборщика.
2. В разделе **«Экспорт» → «Подготовить запрос с временными метками**» загрузите ZIP-файл запроса для выбранной рабочей области. Распакуйте файлы `checkpoint.json`, `timestamp.tsq`, `SHA256SUMS` и `README.txt`. Не изменяйте байты контрольной точки.
3. Выберите TSA, подходящий для данного расследования. Отправьте запрос `timestamp.tsq`, используя описанный в документации метод, а также запрос `application/timestamp-query` для HTTP-сервиса. Сохраните исходный двоичный ответ как `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` технически не является обязательным, однако его пропуск препятствует проверке исходного нонса. Для выполнения данной полной процедуры значение `request_checked` в результате должно быть истинным. Проверка сертификатов осуществляется в соответствии с правилами и временем проверки, заданными в установленной версии OpenSSL. Для долгосрочного хранения требуется отдельная политика в отношении сертификатов и доказательств их отзыва.

Наличие действительной криптографической подписи не означает автоматически наличие квалифицированной временной метки или определения юридической допустимости. Если оператор сфабриковал данные перед проставлением временной метки, TSA фиксирует эти байты; однако это не подтверждает их достоверность.

## Протокол передачи дел

Зафиксируйте идентификатор дела, отправителя и получателя, время передачи по UTC и её источник, цель, имена файлов/значения SHA-256, отпечаток сборщика, диапазон последовательности, известные пробелы, версию средства проверки и результат проверки. Подпишите и независимо храните данную запись в соответствии с процедурами вашей организации. Система хранения записей с участием нескольких пользователей в TgWitness не реализована.

В ходе разработки не осуществлялось взаимодействия с каким-либо независимым действующим центром сертификации (TSA). В ходе локального тестирования создаётся синтетический центр сертификации (CA/TSA) для проверки совместимости и отклонения изменённых данных, нонса или центра сертификации (CA).