# برچسب‌های زمانی

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

تمبرهای زمانی RFC 3161 برای نقاط کنترل امضا شده: چه چیزی به مرجع ارسال می‌شود و چگونه پاسخ تأیید می‌شود.

TgWitness درخواست‌های RFC 3161 را آماده می‌کند و پاسخ‌های مرجع تاریخ‌نگاری (TSA) را تأیید می‌کند. این رویه دستی نه یک مرجع تاریخ‌نگاری را انتخاب می‌کند و نه داده‌ای را ارسال می‌نماید؛ حالت مدرک هر دو را طبق یک برنامه زمان‌بندی‌شده ([قالب مدرک](https://phishdestroy.github.io/TgWitness/fa/docs/reference/evidence/#rfc-3161-preparation-and-response-verification-02)) انجام می‌دهد. یک درخواست آماده‌شده **هنوز یک مدرک تاریخ‌نگاری نیست**.

## آنچه مدرک را پیوند می‌دهد

نمودار جریان · مشاهدات حساب کاربری → زنجیره SHA-256 و امضاهای Ed25519; زنجیره SHA-256 و امضاهای Ed25519 → نقطهٔ کنترل امضا شده; نقطهٔ کنترل امضا شده → هَش دقیق بایت‌به‌بايت و نانس تصادفی; هَش دقیق بایت‌به‌بايت و نانس تصادفی → درخواست RFC 3161; درخواست RFC 3161 → TSA مستقل; TSA مستقل → پاسخ امضا‌شده TSA; نقطهٔ کنترل امضا شده → تأیید داده‌ها، عدد یک‌بار مصرف و اعتماد صریح به CA; پاسخ امضا‌شده TSA → تأیید داده‌ها، عدد یک‌بار مصرف و اعتماد صریح به CA · مشاهدات حساب کاربری · زنجیره SHA-256 وامضاهای Ed25519 · نقطهٔ کنترل امضا شده · هَش دقیق بایت‌به‌بايتو نانس تصادفی · درخواست RFC 3161 · TSA مستقل · پاسخ امضا‌شده TSA · تأیید داده‌ها، عددیک‌بار مصرف و اعتمادصریح به CA

**نمودار به صورت متن**

1. مشاهدات حساب کاربری → زنجیره SHA-256 و امضاهای Ed25519
2. زنجیره SHA-256 و امضاهای Ed25519 → نقطهٔ کنترل امضا شده
3. نقطهٔ کنترل امضا شده → هَش دقیق بایت‌به‌بايت و نانس تصادفی
4. هَش دقیق بایت‌به‌بايت و نانس تصادفی → درخواست RFC 3161
5. درخواست RFC 3161 → TSA مستقل
6. TSA مستقل → پاسخ امضا‌شده TSA
7. نقطهٔ کنترل امضا شده → تأیید داده‌ها، عدد یک‌بار مصرف و اعتماد صریح به CA
8. پاسخ امضا‌شده TSA → تأیید داده‌ها، عدد یک‌بار مصرف و اعتماد صریح به CA

امضای گردآورنده، سوابق را به کلید خود متصل می‌کند. یک پاسخ معتبر از TSA می‌تواند اثبات کند که یک ایست بازرسی خاص در زمان اعلام‌شده توسط TSA وجود داشته است. سپس ایست بازرسی می‌تواند پیشوند دفترچه را متصل کند. این امر زمان هر اقدام تلگرام یا صحت محتوای ضبط‌شده را اثبات نمی‌کند.

## روند کار

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` پشتیبانی کند. در ویندوز، اعتبارسنج همچنین نصب استاندارد 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 را بررسی کنند.