# タイムスタンプ

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

署名付きチェックポイントにおけるRFC 3161タイムスタンプ：認証機関に送信される内容と、応答の検証方法について。

TgWitnessは、RFC 3161リクエストを作成し、タイムスタンプ認証機関（TSA）からの応答を検証します。 この手動手順では、TSAの選択もデータの送信も行われませんが、証拠モードでは、 スケジュールに従ってその両方を実行します（[証拠形式](https://phishdestroy.github.io/TgWitness/ja/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が指定した時刻に特定のチェックポイントが存在していたことを立証できます。 その後、そのチェックポイントはジャーナルのプレフィックスを紐付けることができます。ただし、これによって 個々のTelegramの操作が行われた時刻や、キャプチャされた内容の真実性が立証されるわけではありません。

## 手順

1. コレクターの鍵のフィンガープリントは、別の信頼できるチャネルを通じて保持してください。調査対象のZIPファイルから 提供される鍵のみでは、コレクターを特定するには不十分です。
2. 「**エクスポート**」**→「タイムスタンプリクエストの準備」**で、選択したワークスペースの リクエストZIPをダウンロードしてください。`checkpoint.json`、`timestamp.tsq`、`SHA256SUMS`、および `README.txt`を解凍してください。チェックポイントのバイトは変更しないでください。
3. 調査に適したTSAを選択してください。`timestamp.tsq`を、 文書化された方法に従って送信し、HTTPサービスの場合は`application/timestamp-query`を使用してください。 元のバイナリ応答を`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`はtrueでなければなりません。 証明書の検証は、インストール済みのOpenSSLのルールおよび検証時間に従います。 長期保存には、別途の証明書／失効に関する証拠ポリシーが必要です。

有効な暗号署名が、自動的に適格なタイムスタンプや 法的証拠能力の認定となるわけではありません。もしオペレーターがタイムスタンプを付与する前に 観測データを捏造していた場合、TSAはそのバイトを固定するものの、その真実性を立証するものではありません。

## 引き継ぎ記録

ケース識別子、送信者および受信者、UTC 送信時刻とその送信元、 目的、ファイル名／SHA-256 値、コレクターのフィンガープリント、シーケンス範囲、既知の 欠落箇所、検証ツールのバージョン、および検証結果を記録します。 この記録に署名し、 組織のプロセスに従って独立して保管してください。TgWitnessには、 マルチユーザー対応の保管記録システムは実装されていません。

開発中は、独立したライブTSAには一切連絡を取りませんでした。ローカルテストでは、 互換性の確認および変更されたデータ、ノンス、CAの拒否を確認するために、合成CA/TSAを作成します。