コンテンツにスキップ
getnextpdf.com

信頼できる時刻:タイムスタンプが「いつ」を証明する仕組み

Spec: RFC 3161Spec: RFC 5816Spec: ISO 32000-2, §12.8.5

タイムスタンプは、一つの、意外なほどとらえどころのない問いに答えます。すなわち、*このデータはすでに存在していたか?*ということです。誰が作ったかでも、それが正しいかどうかでもなく、ただ、ある名指しの瞬間に、まさにこのバイト列がすでに世界にあったということだけを答えます。このページは、その考え方を根本から組み立てます。タイムスタンプ局が行うこと、トークンが実際に何を含むのか、そして時計の上の数字がなぜエビデンスになるのか。

これは、エンジンに焦点を当てたタイムスタンプと信頼できる時刻の、第一原理からの伴侶です。「信頼できる時刻」が専門用語に聞こえるなら、まずこちらを読んでください。

あなたのコンピューターの時計は、証明ではなく自己申告です。好きな値に設定できますし、それは誰にでもできます。日付が第二者にとって重要になった瞬間――締め切り前に署名されなければならなかった契約、紛争の前に存在しなければならなかった記録――あなた自身の時計は、エビデンスとしては無価値です。あなたがそれを制御しているからです。信頼できる時刻という問題のすべては、あなたが動かせない時計を見つけることにあります。

これはニッチな関心事ではありません。長命な署名付き PDF はすべてこれに寄りかかっています。署名証明書はいずれ失効します。何年も後に、検証者は、署名が 証明書がまだ有効だった間に行われたことを知る必要があります。「いつ」の独立した記録がなければ、その問いに誠実な答えはありません。信頼できる時刻は、耐久性のある署名という建造物の全体が乗っている、静かな土台です。

  • タイムスタンプは、あるデータが、述べられた瞬間より前に存在していたことを証明します。それは年齢の 上限であり、それ以上の何物でもありません。
  • それは第三者、すなわち**タイムスタンプ局(TSA)**によって生成されます。その時計を信頼するのは、まさにそれがあなたのものではないからです。
  • TSA はあなたのデータを決して見ません。署名するのはそのハッシュであり、時刻値に結びつけ、小さな署名済みのトークンを返します。
  • トークンは三つのことをまとめて証明します。データはそのデータであること(ハッシュが一致)、時刻は TSA の時刻であること(その署名)、そして応答が送信したリクエストと一致すること(反映されるナンス。古い応答のリプレイから守る)です。
  • それは、誰がデータを書いたか、データが真実か、正確な作成の瞬間がいつかを証明するものではありません。証明するのはただ、これより後ではない、ということだけです。
  • 信頼は TSA へと流れます。公的に信頼された TSA はほとんどの記録に十分であり、eIDAS 適格の TSA は EU において法的な推定を伴います。

すべての中心にある仕掛けから始めましょう。あなたは見知らぬ相手に、データが いつ存在していたかを保証してほしいのですが、相手にデータを見せることはできません――機密かもしれませんし、いずれにせよ膨大かもしれません。だから見せないのです。代わりにハッシュを計算します。短い固定長のフィンガープリントで、元のたった一バイトが変わっても完全に変化し、そこから元を復元することはできません。ファイルではなく、フィンガープリントを送ります。

TSA はそのフィンガープリントを受け取り、自身の現在時刻を付し、その対を秘密鍵で署名して、タイムスタンプトークンを返します(Spec: RFC 3161, §2.1)。トークンは、永続化された結びつきです。すなわち、このフィンガープリントを、この時刻に、私が保証する。トークンは署名されているため、誰も――後になった TSA でさえ――署名を壊さずに時刻を変えることはできません。あなたのフィンガープリントを伴うため、他のどのファイルにとっても無用です。そしてリクエストには TSA が変更せずに反映する新しいランダムなナンスが含まれるため、応答が この特定のリクエストに対応していて古い応答のリプレイではないことが分かります――ナンスが証言するのは鮮度であって、誰が要求したかではありません(Spec: RFC 3161, §2.4.2)。

折りたたまれた手紙の上に押された蝋の封印を思い浮かべてください。封印は手紙を読みません。封印が押されたときに手紙が完全な状態でそこにあったことを証明するだけです。タイムスタンプは、あなたが所有していない時計によって、あなたのデータのフィンガープリントの上に押された封印です。

  1. Fingerprint the dataCompute a one-way hash of the file or the signature value. The data itself never leaves your hands.
  2. Ask the authoritySend the hash and a fresh random nonce to the Time-Stamp Authority.
  3. The TSA seals a timeIt signs the hash bound to its own clock and echoes your nonce, producing a small signed token.
  4. Store the tokenFor a PDF, the token is placed inside the file so the proof travels with the document.
  5. Verify laterAnyone who trusts the TSA can check the token: its signature against the TSA certificate, the matching hash, the echoed nonce, and the time — then concludes an upper bound on age.
信頼できるタイムスタンプがどのように取得され、何を証明するか。ハッシュと新しいナンスが TSA へ送られ、TSA はそのハッシュを自身の時刻に結びつけて署名し、ナンスを反映します。検証者は、データが述べられた時刻より前に存在していた証明としてトークンを扱う前に、すべての結びつきを確認します。

PDF の中では、この同じ仕組みが二つの役割を兼ねます。署名タイムスタンプは、署名の値にタイムスタンプを付すことで、署名がいつ適用されたかを封印します。文書タイムスタンプは、PDF 全体(トークンが占めることになるプレースホルダーを除く)をハッシュし、返されたトークンをそのプレースホルダーに格納することで、ファイル全体がいつ存在していたかを封印します(Spec: ISO 32000-2, §12.8.5)。後者こそが、長命なアーカイブ署名が信頼を新鮮に保つために、年月を超えて更新するものです。

知っておく価値のある現代的なディテールが一つあります。古いタイムスタンプ形式は、TSA 自身の証明書を名指すために、一つのハッシュアルゴリズムに自らを縛り付けていました。更新されたプロファイルは、トークンが現在のダイジェストで自らの証明書を名指すことを許します(Spec: RFC 5816, §2.1)。だから信頼できる時刻は、昨日の暗号技術を黙って受け継いだりはしません。

トークンを手作業で組み立てることはありませんし、そう望むべきでもありません。理解する価値があるのは、信頼の境界です。すなわち、どの時計を信じることにするか、です。NextPDF では、信頼できる時刻を必要とする署名レベルを要求することが、その選択を暗黙ではなく明示的にします。

<?php
declare(strict_types=1);
use NextPDF\Security\Signature\SignatureLevel;
// A baseline signature trusts only the signer's own clock.
$baseline = SignatureLevel::PAdES_B_B;
$baseline->requiresTimestamp(); // false → no third party vouches for "when"
// Stepping up to B-T means a Time-Stamp Authority must be supplied:
// from here on, "when" is attested by a clock you do not control.
$timestamped = SignatureLevel::PAdES_B_T;
$timestamped->requiresTimestamp(); // true → a TSA is now part of your trust model
// The decision is now visible at the call site, not buried in a default.
// Choosing the TSA is choosing whose time becomes your evidence.

この例の要点は API ではありません。「自分は信頼できる時刻を持っているか?」が、TSA がループの中にいたかどうかによって決まる、あなたの文書に関するイエスかノーかの事実であること――そしてエンジンが、その事実を曖昧なままにすることを拒否すること――が要点です。

罠は、タイムスタンプを *「これは 14:32 に作成された」*と読み取ってしまうことです。タイムスタンプはそのようなことを述べていません。述べているのは *「これは 14:32 より後ではなく存在していた」*ということです。この違いこそが全体の要点です。タイムスタンプは上限であり、下限では決してなく、正確な瞬間でも決してありません。あなたのデータは、タイムスタンプを付けるに至るまでに何年も前から存在していたかもしれません。トークンはそれについて沈黙しています。それは一本の線を引いて、こう言います。ここより後ではない、と。

二つ目の、よりコストの高い誤解は、タイムスタンプがあなたの文書が 本物または 正しいことを証明する、というものです。それはどちらもしません。意味には無関心です。完璧にタイムスタンプされた嘘は、依然として嘘です――今や証明可能なほどに古いだけです。真正性は 誰がを述べる署名から生まれ、真実は世界から生まれます。タイムスタンプが語るのは、いつまでも いつについてだけです。

タイムスタンプの届く範囲は、その信頼モデルが及ぶところでちょうど止まります。それは年齢の上限を証明し、そのことだけを、そしてそれを封印した局をあなたが信頼する場合に限って証明します。

区別する価値のある二つの局のティアがあります。公的に信頼された TSA は、あなたのソフトウェアがすでに受け入れている証明書にチェーンします。そのトークンは広く検証可能であり、ほとんどの記録に適しています。eIDAS 適格 TSA は EU の信頼リスト上の監督下のプロバイダーであり、適格電子タイムスタンプは、その日付の正確さとデータの完全性についての法的な推定を伴います――通常のタイムスタンプが伴わない推定です(Spec: eIDAS, Art. 41)。両者の選択は、あなたが必要とする 証拠としての重みに関する問いであって、バイトの動作の仕方に関する問いではありません。暗号技術は同じです。

タイムスタンプはまた、自身のトラストアンカーの寿命を受け継ぎます。TSA の証明書は失効または取り消されることがあり、使用したハッシュアルゴリズムは古びることがあります。だからこそ、長命な文書は一度タイムスタンプを付けて立ち去ったりはしません――古いエビデンスが弱まる前に、その上に新しい文書タイムスタンプを重ねて更新します。その更新ループはそれ自体が一つの主題です。長期検証を参照してください。

RFC 3161 trusted timestamping (signature and document timestamps) — edition availability
EditionAvailability
Core

PAdES B-B および B-T をサポートします。B-B はタイムスタンプのないベースライン署名です。B-T は、あなたが時計を選ぶデプロイメント提供の TSA に対して、検証済みの RFC 3161 署名タイムスタンプを要求し埋め込みます。

Pro

B-LT が、証明書の失効後も署名を検証可能に保つために必要とする、埋め込まれた長期検証データ(証明書、OCSP、CRL)を追加します。

Enterprise

B-LTA の更新ループを追加し、検証データを新しい文書タイムスタンプの下に封印し、 保護が弱まる前に再スタンプします。

  • タイムスタンプ局(TSA) ――署名済みのタイムスタンプトークンを発行する独立したサービス。その時計を信頼するのは、まさにそれがあなたのものではないからです。
  • タイムスタンプトークン ――TSA が返す小さな署名済みオブジェクトで、あなたのデータのハッシュを時刻値に結びつけるもの(Spec: RFC 3161, §2.1)。
  • ハッシュ(メッセージインプリント) ――データの短い一方向のフィンガープリント。TSA はこれに署名するのであってデータそのものには署名しないため、あなたのコンテンツは秘匿されたままです。
  • ナンス ――リクエストとともに送信され、応答の中に変更されずに反映される新しいランダムな数値。トークンが その特定のリクエストに対応していて古い応答のリプレイではないことを示すもの(要求者の識別情報ではなく、鮮度を証言します)。
  • 上限 ――タイムスタンプが確立するもの。データは述べられた瞬間 より後ではなく存在していました。正確な作成の瞬間では決してありません。
  • eIDAS 適格タイムスタンプ ――監督下の EU プロバイダーが発行するタイムスタンプで、日付の正確さとデータの完全性についての法的な推定を伴うもの。
  • 文書タイムスタンプ ――PDF ファイル全体に対するタイムスタンプで、長期検証のエビデンスを固定し更新するために使われるもの(Spec: ISO 32000-2, §12.8.5)。