コード署名と Authenticode/notarization の信頼連鎖

コード署名が証明するもの・しないもの

コード署名（code signing）は、実行ファイルやスクリプトに対して配布者を同定し、配布後の改ざんを検知するための仕組みです。発行者の秘密鍵でファイルのハッシュに署名し、利用者側は対応する公開鍵（証明書）で検証します。ここで最初に押さえるべきは、コード署名が保証するのは「このファイルは確かにこの発行者が作り、署名後に1ビットも変わっていない」という出所と完全性であって、「そのコードが無害だ」ということではない、という線引きです。署名済みのマルウェアは存在し得ますし、過去にも盗まれた正規鍵で署名された攻撃ツールが多数報告されています。

つまりコード署名は信頼の根拠を与えますが、信頼の判断そのものは別レイヤ（後述の SmartScreen や notarization、あるいは利用者のポリシー）が担います。この役割分担を見失うと、「署名が通ったのに警告が出る」現象を説明できなくなります。

Authenticode：PE ファイルへの署名構造

Windows のコード署名形式である Authenticode を例に、署名の内部構造を見ます。対象は PE/COFF 形式の実行ファイル（.exe / .dll / .sys）です。署名は次の手順で生成されます。

[署名生成]
1. PE のうち「署名格納領域（Attribute Certificate Table）」と
   チェックサムフィールドを除いた範囲のハッシュを計算
   → このハッシュを Authenticode hash と呼ぶ
2. ハッシュを SpcIndirectDataContent という構造に包む
3. それを署名者の秘密鍵で署名し、PKCS#7 / CMS の
   SignedData として PE 末尾の証明書テーブルに埋め込む
4. SignedData には署名者証明書と中間 CA 証明書も同梱する

検証側は逆をたどります。同じ範囲を再ハッシュして埋め込まれた値と照合し（改ざん検知）、署名を署名者の公開鍵で検証し、その証明書からチェーンをたどって信頼されたルート CA に到達するかを確かめます。署名対象からチェックサムと証明書テーブル自身を除外するのは、署名を埋め込むとファイルが変化してしまう自己参照を避けるためです。除外領域を決め打ちにすることで、署名後のファイル全体が再現可能なハッシュ対象になります。

証明書チェーンの検証と EKU

署名者証明書からルート CA までのパス検証は、TLS サーバー証明書と同じ X.509 パス検証ですが、コード署名固有の制約が一つあります。証明書の **EKU（Extended Key Usage）**に「コード署名（id-kp-codeSigning, OID 1.3.6.1.5.5.7.3.3）」が含まれていなければなりません。Web サーバー証明書でコードに署名しても、EKU が一致せず拒否されます。これは鍵の用途を証明書レベルで縛り、用途外転用を防ぐためです。

さらに OS は「どのルートをコード署名用に信頼するか」を独自の証明書ストアで管理します。Windows のカーネルモードドライバ署名のように、Microsoft の特定ルートしか受け付けない、より厳格な信頼アンカー集合を用いる領域もあります。チェーンが数学的に正しくても、そのルートが当該用途で信頼ストアに入っていなければ検証は通りません。

タイムスタンプ：失効・期限切れ後も署名を生かす仕組み

ここがコード署名の最も重要かつ誤解されやすい論点です。署名者証明書には有効期限があり、鍵漏洩などで途中失効することもあります。素朴に考えると、証明書が期限切れになった瞬間に、過去に署名した全ファイルの署名が無効になりそうです。これではソフトウェアを配布し続けられません。

これを解決するのが**タイムスタンプ（timestamping）**です。署名生成時に、署名値を **TSA（Time Stamping Authority、信頼できる時刻認証局）**へ送り、TSA が「この署名はこの時刻に存在した」ことを TSA 自身の鍵で署名して返します（RFC 3161）。この時刻証明を署名に同梱（counter-signature）しておくと、検証側は次のように判断できます。

仕組みの核心は、検証の基準時刻を「今」から「署名された過去の時刻」へ移すことです。証明書失効は通常「失効日以降に作られた署名」を無効にしますが、TSA が「失効日より前に署名された」と証明していれば、その署名は失効の影響を受けません。鍵漏洩が判明したら、漏洩時点以降のタイムスタンプを持つ署名だけを疑えばよく、それ以前の正規署名を巻き添えにせずに済みます。TSA の証明書にも期限はありますが、TSA ルートは長期間有効に設計され、必要なら署名へ後からタイムスタンプ証明を更新（re-timestamp）して延命します。

EV 証明書と署名鍵の保護

コード署名証明書には大きく **OV（Organization Validation）**と EV（Extended Validation）があります。EV は発行時の組織実在性審査がより厳格で、決定的な違いは秘密鍵をハードウェアに隔離することが必須な点です。EV のコード署名鍵は HSM やハードウェアトークン、あるいはクラウドの鍵保管サービス内で生成・保持され、鍵そのものを取り出せません。署名はハードウェア内で行われ、鍵が平文でメモリやディスクに出ないため、マルウェアによる鍵窃取のリスクが大きく下がります（業界の基準変更により、現在は OV のコード署名鍵にも同様のハードウェア保護が要求される方向です）。

EV のもう一つの実務的価値は、後述の SmartScreen での扱いです。EV 署名は配布初期から評判を獲得しやすく、警告の発生を抑えられます。

SmartScreen と notarization：チェーン検証の「外側」の信頼判定

署名チェーンが正しく検証できても、OS が即座にユーザーへ実行を許すとは限りません。Windows と macOS は、署名検証とは別レイヤの信頼判定を重ねています。

Windows SmartScreen は、ダウンロードされた実行ファイル（Mark of the Web 付き）に対し、ファイルのハッシュや署名者の**評判（reputation）**を Microsoft のクラウドへ問い合わせます。署名が有効でも、その署名者やファイルがまだ十分にダウンロード・実行された実績を持たない場合、「発行元を確認できませんでした」式の警告を出します。評判は配布実績の蓄積で改善し、EV 証明書は署名者単位で評判が早く立ちやすい設計です。重要なのは、SmartScreen の警告は署名の不正を意味しないことで、正しく署名された新しいアプリでも初期は警告が出ます。

Apple notarization は、開発者が署名済みアプリを Apple のサービスへ提出し、Apple が自動マルウェアスキャンを実行、問題がなければ notarization ticket を発行する仕組みです。配布時にこのチケットを stapling（アプリに添付）しておくと、macOS の Gatekeeper はオフラインでもチケットを検証できます。Gatekeeper は起動時に、(1) Developer ID 証明書による署名が有効か、(2) notarization を通過しているか、を確認し、両方を満たして初めて警告なしに実行を許します。notarization はコードの配布前マルウェア検査であって署名そのものとは別軸で、署名と notarization のどちらが欠けても起動はブロックされます。

まとめ

コード署名は ハッシュ→署名→X.509 チェーン検証の三層で、実行ファイルの出所同定と改ざん検知を行います。Authenticode はチェックサムと証明書テーブルを除いた範囲をハッシュして PKCS#7 で PE に埋め込み、検証側はチェーンをルート CA までたどり、EKU にコード署名用途があることまで確認します。

証明書の期限切れ・失効でも署名を生かす鍵がタイムスタンプで、TSA が証明した署名時刻を検証基準にすることで、失効前に署名されたバイナリの有効性を維持します。長期配布物でこれを省くと、コード不変でも将来警告が出ます。EV 証明書は鍵のハードウェア隔離を必須化して鍵窃取を防ぎ、SmartScreen の評判も得やすくします。

最後に、**SmartScreen（評判）**と **notarization/Gatekeeper（Apple のマルウェア検査）**は署名チェーンの合否とは独立した信頼判定層であり、署名が有効でも警告やブロックは起こり得ます。署名は安全の保証ではなく、出所を同定し事後に失効・追跡できるようにする土台です。連鎖をたどって信頼の根に至る発想は セキュアブートの信頼連鎖 とも一本でつながります。