חותמות זמן

TgWitness מכין בקשות לפי RFC 3161 ומאמת תגובות של רשות חותמת זמן (TSA). תהליך ידני זה אינו בוחר TSA ואינו שולח נתונים; מצב הראיות מבצע את שני הדברים על פי לוח זמנים (פורמט ראיות). בקשה שהוכנה אינה מהווה עדיין הוכחת חותמת זמן.

מה שהראיה מחייבת#

תרשים כטקסט

1. תצפיות על חשבונות → שרשרת SHA-256 וחתימות Ed25519
2. שרשרת SHA-256 וחתימות Ed25519 → נקודת ביקורת חתומה
3. נקודת ביקורת חתומה → השיג (hash) ברמת בייט מדויק ו-nonce אקראי
4. השיג (hash) ברמת בייט מדויק ו-nonce אקראי → בקשה לפי 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, את נקודת הקצה, זמן האחזור ותוצאת הבקשה. הבקשה מכילה hash ו-nonce במקום הודעות; מטא-נתוני הרשת עדיין חושפים את הבקשה.
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 סינתטי.

6. ייצא קובץ ZIP של היומן החתום לאחר נקודת הבדיקה, כך שיכלול את הקידומת הזו. אמת באמצעות טביעת האצבע הידועה באופן עצמאי:

python tgwitness/verify.py evidence.zip --fingerprint TRUSTED_SHA256 --checkpoint checkpoint.json

7. יש לשמור את קובץ ה-ZIP, נקודת הבדיקה, הבקשה, התשובה, שרשרת האישורים, תוצאות האימות ותיעוד העברת הנתונים מחוץ לאספן. יש לחזור על תהליך האימות עם קבלת הנתונים.

כדי להכין בקשה מנקודת ביקורת שנשמרה:

python -m tgwitness.anchor prepare checkpoint.json --out timestamp-request.zip

תהליך ההכנה מבצע קנוניזציה של JSON וכולל את נקודת הבדיקה התואמת בארכיון. יש להשתמש בבתים של נקודת הבדיקה מאותו ארכיון לאימות TSA, גם אם בקובץ הקלט היו רווחים שונים.

גבולות האימות#

--request הוא אופציונלי מבחינה טכנית, אך השמטתו מונעת אימות של ה- nonce המקורי. עבור הליך מלא זה, התוצאה request_checked חייבת להיות נכונה. אימות האישור מתבצע בהתאם לכללים ולזמן האימות של OpenSSL המותקן. שימור לטווח ארוך מצריך מדיניות נפרדת בנוגע לאישורים ולביטולים.

חתימה קריפטוגרפית תקפה אינה מהווה אוטומטית חותמת זמן מוסמכת או קביעה לגבי קבילות משפטית. אם מפעיל זייף תצפיות לפני הטבעת חותמת הזמן, ה-TSA מקבע את אותם ביטים; הוא אינו קובע את אמיתותם.

רישום העברה#

תעדו את מזהה התיק, השולח והנמען, זמן ההעברה ב-UTC ומקורו, המטרה, שמות הקבצים/ערכי SHA-256, טביעת האצבע של האספן, טווח הרצף, פערים ידועים, גרסת המאמת ותוצאת האימות. חתמו על תיעוד זה ושמרו אותו באופן עצמאי בהתאם לתהליך הארגוני שלכם. מערכת תיעוד שמירה רב-משתמשת אינה מיושמת ב-TgWitness.

במהלך הפיתוח לא נוצר קשר עם אף TSA עצמאי פעיל. בדיקות מקומיות יוצרות CA/TSA סינתטי כדי לבדוק תאימות ודחייה של נתונים ששונו, nonce או CA.