コードサイニング証明書は、ソフトウェアへ付けるデジタル署名で、公開鍵と発行元の情報を結び付けるために使う証明書です。署名を検証することで、発行元を確認し、署名対象の内容が署名後に変わっていないかを調べられます。
署名する側と検証する側
| 段階 | 主な役割 |
|---|---|
| 署名 | 発行元が秘密鍵でソフトウェアに署名する |
| 検証 | 受け取り側が公開鍵で署名を検証する |
| 証明書の検証 | 信頼する認証局へのつながり、用途、有効性などを確認する |
検証ではファイルから計算するハッシュなどと署名の関係を確認します。ハッシュ値を比べるだけでは、それが誰の出した値かまでは分かりません。署名と証明書の信頼関係を合わせて考えます。
学習例:配布ファイルが途中で変わったら
架空の会社Aが配布ファイルに署名した後、第三者が署名対象のコードを書き換えたとします。元の署名に対する検証は通常失敗し、変更を見つける手掛かりになります。一方、正当な更新版にも改めて署名が必要です。署名対象の範囲や形式は配布形式ごとに異なります。
署名が有効でも無害とは限らない
| 確認したいこと | 署名との関係 |
|---|---|
| 発行元を確認する | 証明書と署名を検証する |
| 署名対象の変更を検知する | 署名検証で調べる |
| マルウェアや欠陥がない | 署名だけでは証明できない |
| 実行してよいか | 配布元・用途・OSの保護機能なども考慮する |
発行元自身が有害なコードを署名した場合や、秘密鍵が不正利用された場合も考えられます。署名は安全性の審査済みマークとは違います。警告が出たときも、署名があるという理由だけで解除しないようにします。
期限・失効・タイムスタンプ
秘密鍵の保護と証明書の期限管理が必要です。信頼されたタイムスタンプが付いた署名は、証明書の期限後にも署名時点の有効性を評価できる場合があります。ただし、失効・アルゴリズム・検証ポリシーなどの条件があるため、永久に有効になるという意味ではありません。
失効の確認は証明書失効リスト(CRL)も参照してください。OSやストア、ドライバごとの署名要件は異なります。
確認問題
署名検証が成功すれば、そのアプリに悪意のある動作がないことまで保証されますか?
解答・解説を見る
いいえ。発行元や署名対象の完全性の確認と、ソフトウェアの動作が安全かという判断は別です。
署名・ハッシュの基礎をnoteで復習する
証明書を理解する前提として、公開鍵暗号・デジタル署名・ハッシュの役割を整理しましょう。無料noteのセキュリティ用語解説で、改ざん検知と暗号化の違いを復習できます。
資格・目的別のnote教材ナビから、関連教材も選べます。


コメント