【実務・中級編】コード署名(Code Signing)によるバイナリの完全性保証と信頼の起点(Root of Trust) – 暗号理論・認証基盤 & エンドポイントセキュリティ防御ガイド

信頼の崩壊を防げ：コード署名が守る「実行の正義」と実戦的実装術

エンジニア諸君、お疲れ様。今日もどこかのサーバーで脆弱性が突かれ、誰かのPCで怪しげなバイナリが実行されている。

「暗号化してるから大丈夫だ」という言葉を耳にするたびに、俺は少し背筋が寒くなる。暗号はあくまで「手段」であって「目的」ではない。今日は、コード署名（Code Signing）という、いわば「デジタルな封印」について、現場の泥臭い現実を交えて話そう。

なぜ「中身が正しい」と言い切れるのか？

コード署名は、単なるファイルのハッシュ値計算ではない。公開鍵暗号（RSAやECDSA）の数学的信頼性を利用し、「このバイナリは間違いなく開発者本人が作成し、改ざんされていない」という事実を、OSや実行環境に証明させるプロセスだ。

攻撃者は、君たちがビルドしたバイナリを巧妙にすり替える。バックドアを仕込んだ .exe や .so ファイルを、オリジナルの更新プログラムに見せかけて配信する。これが「サプライチェーン攻撃」の入り口だ。署名がなければ、OSはそれが「正規のアップデート」なのか「悪意あるコード」なのかを判断できず、ただ実行するだけになる。

攻撃者の狙う「盲点」：Root of Trust（信頼の起点）

君たちが署名に使う秘密鍵が、もし開発者のデスクトップPCのデスクトップ上に private_key.pem として転がっていたら？攻撃者はその鍵を盗み出し、悪意あるコードに「正当な署名」を付与する。こうなれば、OSは「信頼できる署名」として喜んで実行してしまう。

これこそが、セキュリティの「信頼の起点（Root of Trust）」が侵害された状態だ。署名鍵は、HSM（ハードウェア・セキュリティ・モジュール）や、クラウドのKMS（Key Management Service）で厳重に保護しなければならない。

実践：Pythonを用いた署名検証の自動化

サーバーサイドでアップロードされたバイナリやプラグインの整合性を確認する際、署名をチェックしないエンジニアが多い。以下は、cryptography ライブラリを使用して、公開鍵で署名を検証する基本的な実装だ。

from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric import padding
from cryptography.hazmat.primitives import serialization

def verify_binary_signature(binary_data, signature, public_key_pem):
    """
    バイナリの署名を検証する関数
    :param binary_data: 検証対象のバイナリデータ
    :param signature: 付与された署名バイナリ
    :param public_key_pem: 署名者の公開鍵（PEM形式）
    """
    public_key = serialization.load_pem_public_key(public_key_pem)
    
    try:
        # SHA256でハッシュ化してRSA署名を検証
        public_key.verify(
            signature,
            binary_data,
            padding.PSS(
                mgf=padding.MGF1(hashes.SHA256()),
                salt_length=padding.PSS.MAX_LENGTH
            ),
            hashes.SHA256()
        )
        print("検証成功：このバイナリは信頼できます。")
        return True
    except Exception as e:
        print(f"検証失敗：改ざんの疑いあり！ 詳細: {e}")
        return False

# 運用上の注意: public_key_pem はハードコードせず、
# 安全な秘密鍵管理サービス(AWS KMS等)から取得すること。

インフラ層での防御：コード署名ポリシーの強制

OSレベルでの防御を忘れてはいけない。Windows環境であれば「AppLocker」や「WDAC (Windows Defender Application Control)」、Linuxであれば dm-verity を使ったファイルシステムの整合性保証が不可欠だ。

例えば、Nginx等でアップデートファイルを配信する場合、単にダウンロードさせるのではなく、署名付きのメタデータファイル（manifest.json.sig など）を併せて配信し、クライアント側で厳密に検証させる設計を徹底すること。

現場のエンジニアへ送る「鉄の掟」

1. 秘密鍵は人間が触るな: ローカルPCに鍵を置くのは論外だ。署名作業はビルドサーバーのCI/CDパイプライン内でのみ行い、鍵はHSMやKMSに閉じ込めろ。
2. 失効リスト(CRL/OCSP)を確認せよ: 証明書が漏洩した場合、即座に失効させなければならない。検証側も、常に最新の証明書失効情報を確認するロジックを組み込め。
3. 「とりあえず動く」を許すな: 署名検証でエラーが出たら、例外を握りつぶして実行を継続するなど言語道断だ。即座にログを吐き出し、プロセスを停止させろ。

セキュリティとは、完璧な製品を売ることではなく、「攻撃者が侵入したときに、どれだけ速やかにその不整合を検知し、被害を局所化できるか」という戦いだ。コード署名は、そのための最も強力な武器の一つになる。

今日から君たちのコードにも、「信頼の証」を刻み込んでくれ。それが、エンジニアとしてのプロ意識というものだ。