Довідка / Докази
Часові мітки
Часові мітки RFC 3161 для підписаних контрольних точок: що надсилається до центру авторизації та як перевіряється відповідь.
TgWitness формує запити за стандартом RFC 3161 та перевіряє відповіді від органу авторизації часових міток (TSA). Ця ручна процедура не передбачає ні вибору TSA, ні надсилання даних; режим доказового збору виконує обидві ці дії за графіком (формат доказового збору). Підготовлений запит ще не є доказом часової мітки.
Що фіксує цей журнал доказів#
Діаграма у вигляді тексту
- Спостереження за акаунтами → Ланцюжок SHA-256 та підписи Ed25519
- Ланцюжок SHA-256 та підписи Ed25519 → Підписаний контрольний пункт
- Підписаний контрольний пункт → Хеш з точністю до байта та випадковий нонс
- Хеш з точністю до байта та випадковий нонс → Запит RFC 3161
- Запит RFC 3161 → Незалежна TSA
- Незалежна TSA → Підписана відповідь TSA
- Підписаний контрольний пункт → Перевірка даних, одноразового коду та явного довірчого сертифіката
- Підписана відповідь TSA → Перевірка даних, одноразового коду та явного довірчого сертифіката
Підпис збирача пов’язує записи з його ключем. Довірений відповідь TSA може підтвердити, що певний контрольний пункт існував на зазначений TSA час. Потім контрольний пункт може прив’язати префікс журналу. Це не встановлює час кожної дії в Telegram або достовірність зафіксованого вмісту.
Процедура#
- Зберігайте відбиток ключа колектора через окремий надійний канал. Ключ, наданий лише перевіреним ZIP-файлом, є недостатнім для ідентифікації колектора.
- У розділі «Експорт» → «Підготувати запит на часові мітки» завантажте ZIP-файл із запитом
для обраної робочої області. Розпакуйте файли
checkpoint.json,timestamp.tsq,SHA256SUMSтаREADME.txt. Не змінюйте байти контрольних точок. - Оберіть TSA, що відповідає вимогам розслідування. Надішліть
timestamp.tsq, використовуючи задокументований метод, а такожapplication/timestamp-queryдля HTTP-сервісу. Збережіть оригінальну бінарну відповідь як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 технічно є необов’язковим, але його пропуск унеможливлює перевірку
оригінального нонсу. Для виконання цієї процедури в цілому результат request_checked повинен дорівнювати «true».
Перевірка сертифікатів здійснюється згідно з правилами та термінами, встановленими для встановленого OpenSSL.
Для довгострокового зберігання необхідна окрема політика щодо сертифікатів та доказів їх скасування.
Дійсний криптографічний підпис не є автоматично кваліфікованим часовим штампом або визначенням юридичної допустимості. Якщо оператор сфабрикував спостереження до нанесення часового штампу, TSA фіксує ці байти; це не підтверджує їхню правдивість.
Запис про передачу#
Зафіксуйте ідентифікатор справи, відправника та одержувача, час передачі за UTC та її джерело, мету, імена файлів/значення SHA-256, відбиток колектора, діапазон послідовностей, відомі пропуски, версію верифікатора та результат верифікації. Підпишіть та зберігайте цей запис незалежно у рамках процедур вашої організації. Система зберігання записів для декількох користувачів у TgWitness не реалізована.
Під час розробки не було здійснено зв’язку з жодною незалежною TSA в режимі реального часу. У ході локальних тестів створюється синтетична CA/TSA для перевірки сумісності та відхилення змінених даних, нонсу або CA.