要約

  • コード署名証明書の更新やローテーションは、将来のリリースに使う鍵を変えるだけであり、旧証明書の有効期間中に正しく署名・時刻証明されたバイナリを自動的に無効化しない。
  • 切り替えは成果物単位で管理する。ハッシュ、署名証明書、RFC 3161トークン、実効失効時刻、配布場所、検証器の観測結果を一つの台帳で結ぶべきだ。

正午、ソフトウェア発行者がリリース工程を新しい証明書へ切り替える。最初のビルドは正常に署名され、ダッシュボードは緑になる。しかし前夜のインストーラーは地域ミラーに残り、有効なタイムスタンプを持ち、顧客端末でも引き続き検証に通る。

この状態は必ずしも故障ではない。誤りは、証明書の切り替えを信頼の切り替え完了と報告することにある。

コード署名は、ソフトウェアのバイト列を署名者の身元に結び付ける。タイムスタンプは別の事実を加える。信頼された時刻認証局が、あるハッシュが特定の時刻に存在したことを証明する。その組み合わせにより、通常の証明書有効期限を過ぎても署名が受け入れられることがある。鍵の侵害が疑われた場合は、実効失効時刻より前と後の成果物を分ける材料にもなる。

したがって、コード署名証明書には運用上二つの終点がある。一つは有効期限であり、それ以後は新しい有効な署名に使うべきではない。もう一つは、検証器がその署名権限を認めなくなる時刻だ。両者が一致する場合はあるが、仕組み上、常に同じとは限らない。

タイムスタンプが証明する範囲

RFC 3161はMessageImprintを中心に構成される。そこにはハッシュアルゴリズム識別子とデータのハッシュ値が入る。時刻認証局はアルゴリズムと長さを確認するが、元のプログラムを審査しない。トークンにはポリシー、固有のシリアル番号、genTimeが入り、タイムスタンプ専用鍵で署名される。

つまり、トークンはソフトウェアの安全性を保証しない。特定のハッシュが、所定のポリシーの下で提示されたことを証明するだけだ。発行者が全署名経路を支配していたことも、旧版が全ミラーから消えたことも証明しない。

検証側にも作業が残る。RFC 3161は、応答状態、時刻認証局の証明書、データのハッシュ、アルゴリズム、署名、応答時刻の妥当性を確認するよう求める。Microsoft の SignTool もsign、timestamp、verifyを別々の操作としている。RFC 3161方式では/trでサーバーを、/tdで時刻署名のダイジェストを指定する。署名構造の存在だけでなく、証明書チェーンや失効状態も検証対象になり得る。

ClickOnce の文書は実際の効果を明記している。有効なタイムスタンプがあれば、署名証明書の期限後もアプリケーションは受け入れられ得る。健全な過去版を証明書更新のたびに再署名しなくてよい点は重要だ。しかし、この持続性がある以上、次のビルドだけを見て完了とは言えない。

失効は時間の境界を作る

CA/Browser Forum のコード署名基準は、公的に信頼されるコード署名証明書と関連する時刻認証局を対象とする。該当証明書を発行する CA は、RFC 3161準拠のサービスを運用し、利用を推奨し、SHA-1 のMessageImprintを拒否しなければならない。

基準は、失効が単純な削除ではない理由も示す。一つの証明書が一個の成果物だけでなく、何千個もの正常な成果物に署名しているかもしれない。失効は疑わしいコードだけでなく、健全なコードも無効にし得る。CA は、もっともらしい問題報告を受けて二十四時間以内に調査を始める。鍵侵害なら、実効失効日は、証拠で支えられる最も早い疑わしい時刻とすべきだ。

その時刻で影響範囲を区切れる。基準は、失効日より前のタイムスタンプを持つ成果物は引き続き有効として扱うべきだとしている。ただし、これは全プラットフォームの実装が同じ結果になる証明ではない。

時刻認証局には独自の障害境界もある。RFC 3161は、鍵侵害のない通常の廃止と、秘密鍵侵害を区別する。適切な理由を伴う通常廃止なら、以前のトークンは有効性を保ち得る。鍵が侵害されたなら、その鍵が作ったトークンを無条件には信頼できず、監査記録や別の独立タイムスタンプが重要になる。

分母は配布済み成果物のすべて

証明書台帳だけでは足りない。どの成果物を誰が署名し、どのトークンが付き、どこから取得でき、対象検証器がどう判定するかを知る必要がある。

公式ダウンロード、パッケージリポジトリ、CDN キャッシュ、企業向けストア、更新チャネル、オフラインインストーラー、復旧媒体が対象になる。最新ページから削除しても、他の配布面から消えたとは限らない。一方、健全な旧版の所在を確認せず一括失効すれば、セキュリティ対応が回避可能な停止を起こす。

最低限必要なのは、成果物権限の切り替え台帳だ。各ハッシュに、ビルドと版、証明書の指紋とシリアル、署名方式、トークンと時刻認証局、genTime、期限、失効状態と実効時刻を結ぶ。さらに各配布場所、撤去・置換状態、検証ポリシー、実測した受容・拒否結果を関連付ける。

これで完了条件を反証可能にできる。将来のビルドが意図した署名者だけを使い、残す旧成果物には明示的な判断があり、撤去対象は管理下の配布面から消え、代表的な検証器が期待通りに動いた時にのみ完了である。

証拠の限界

RFC 3161はトークン仕様を定めるが、特定の事業者を保証しない。CA/Browser Forum 基準は全 OS やパッケージ管理を同一にしない。Microsoft 文書が示すのは SignTool、Authenticode、ClickOnce の記載上の挙動であり、全エコシステムではない。

本稿は侵害を申し立てるものではない。有効期限、ローテーション、失効、時刻認証局の障害は別々の事象であり、説明可能な切り替えは証拠と判断の双方でそれらを分ける。

情報源