コード署名

コード署名は、実行可能ファイルやスクリプトにデジタル署名して ソフトウェアの作成者を確認し、署名後にコードが変更または破損していないことを保証するプロセスです。このプロセスでは、暗号ハッシュを使用して真正性と整合性を検証します。^[1] コード署名は、1995 年に Michael Doyle によって、Eolas WebWish ブラウザ プラグインの一部として発明されました。これにより、公開鍵暗号化を使用して、秘密鍵を使用してダウンロード可能な Web アプリ プログラム コードに署名できるようになり、プラグイン コード インタープリターは、対応する公開鍵を使用してコードを認証してから、コード インタープリターの API へのアクセスを許可できるようになりました。^[2]

コード署名は、いくつかの貴重な機能を提供します。コード署名の最も一般的な用途は、展開時にセキュリティを提供することです。一部のプログラミング言語では、名前空間の競合を防ぐためにも使用できます。ほぼすべてのコード署名実装では、作成者またはビルドシステムの ID を確認するための何らかのデジタル署名メカニズムと、オブジェクトが変更されていないことを確認するためのチェックサムが提供されます。また、オブジェクトに関するバージョン情報を提供したり、オブジェクトに関するその他のメタデータを保存したりするためにも使用できます。 ^[3]

ソフトウェアの認証メカニズムとしてのコード署名の有効性は、基盤となる署名キーのセキュリティに依存します。他の公開鍵基盤 (PKI)テクノロジと同様に、システムの整合性は、発行者が不正アクセスから秘密キーを保護することに依存します。汎用コンピュータのソフトウェアに保存されたキーは、侵害される可能性があります。したがって、ハードウェア セキュリティ モジュールまたはHSMと呼ばれる、安全で改ざん防止の暗号化ハードウェア デバイスにキーを保存する方が安全であり、ベスト プラクティスです。^[4]

多くのコード署名の実装では、 TLSやSSHで採用されているプロセスと同様に、公開鍵と秘密鍵のペアを含むシステムを使用してコードに署名する方法が提供されます。たとえば、.NET の場合、開発者はビルドするたびに秘密鍵を使用してライブラリまたは実行ファイルに署名します。このキーは開発者またはグループごとに一意ですが、アプリケーションまたはオブジェクトごとに一意になる場合もあります。開発者は自分でこのキーを生成することも、信頼できる証明機関(CA) から取得することもできます。^[5]

コード署名は、Javaアプレット、ActiveXコントロール、その他のアクティブなWebおよびブラウザのスクリプトコードなど、特定のコードのソースがすぐには明らかでない可能性がある分散環境で特に役立ちます。もう1つの重要な用途は、既存のソフトウェアに更新とパッチを安全に提供することです。 ^[6] Windows、Mac OS X、およびほとんどのLinuxディストリビューションは、コード署名を使用して更新を提供し、パッチシステムを介して他の人が悪意を持ってコードを配布できないようにします。これにより、更新がサードパーティまたは物理メディア（ディスク）によって配信された場合でも、受信側のオペレーティングシステムは更新が正当であることを確認できます。^[7]

コード署名は、Windows および Mac OS X でソフトウェアの初回実行時に認証するために使用され、ソフトウェアがサードパーティの配布元またはダウンロード サイトによって悪意を持って改ざんされていないことを保証します。この形式のコード署名は、プラットフォームの分散化の性質、パッケージ マネージャーがすべての形式のソフトウェア (更新とパッチだけでなく) の配布の主なモードであること、および必要に応じてソース コードを直接検査できるオープン ソース モデルのため、Linux では使用されません。Debian ベースの Linux ディストリビューション (その他)は、ダウンロードされたパッケージを公開キー暗号化を使用して検証します。^[8]

コード署名の認証に使用される公開鍵は、できれば安全な公開鍵基盤(PKI) を使用して、信頼できるルート証明機関 CA までさかのぼって追跡可能である必要があります。これによってコード自体が信頼できることが保証されるわけではなく、指定されたソース (またはより明確には、特定の秘密鍵) からのものであることのみが保証されます。^[9] CA はルート信頼レベルを提供し、プロキシによって他のユーザーに信頼を割り当てることができます。ユーザーが CA を信頼する場合、そのユーザーは、その CA またはそのプロキシの 1 つによって生成された鍵で署名されたコードの正当性を信頼できると考えられます。多くのオペレーティング システムとフレームワークには、1 つ以上の証明機関に対する信頼が組み込まれています。また、大規模な組織では、組織内部にプライベート CA を実装することが一般的です。プライベート CA はパブリック CA と同じ機能を提供しますが、組織内でのみ信頼されます。

拡張検証(EV) コード署名証明書には、追加の検証および技術要件が適用されます。これらのガイドラインは、CA/B フォーラムのベースライン要件と拡張検証ガイドラインに基づいています。EV 固有の検証要件に加えて、EV コード署名ガイドラインでは、「加入者の秘密鍵は、FIPS 140-2 レベル 2 の要件を満たすかそれを超える暗号モジュールで生成、保存、使用される」と規定されています。^[10]

Windows 10カーネルモードドライバの署名など​​、特定のアプリケーションではEVコード署名証明書が必要です。^{[11]さらに、MicrosoftのIEBlogでは、「EVコード署名証明書で署名されたWindowsプログラムは、そのファイルまたは発行元に以前の評判が存在しなくても、} SmartScreen評判サービスですぐに評判を確立できます」と述べています。^[12]

これは、SSL.com がソフトウェアに署名するために使用する、デコードされた EV コード署名証明書の例ですSSL.com EV Code Signing Intermediate CA RSA R3。 は、発行者の commonName として表示され、これが EV コード署名証明書であることを示します。 証明書のSubjectフィールドには、SSL Corp が組織として記述されています。Code Signingは、唯一の X509v3 拡張キー使用法として表示されます。

証明書：
    データ：
        バージョン: 3 (0x2)
        シリアルナンバー：
            59:4e:2d:88:5a:2c:b0:1a:5e:d6:4c:7b:df:35:59:7d
    署名アルゴリズム: sha256WithRSAEncryption
        発行者:
            commonName = SSL.com EV コード署名中間 CA RSA R3
            組織名 = SSL Corp
            localityName = ヒューストン
            州または州名 = テキサス
            国名 = 米国
        有効
            以前: 2019年8月30日 20:29:13 GMT
            それ以降: 2022年11月12日 20:29:13 GMT
        主題：
            1.3.6.1.4.1.311.60.2.1.3 = 米国
            1.3.6.1.4.1.311.60.2.1.2 = ネバダ
            住所 = 3100 Richmond Ave Ste 503
            businessCategory = 民間組織
            郵便番号 = 77098
            commonName = SSL 社
            シリアル番号 = NV20081614243
            組織名 = SSL Corp
            localityName = ヒューストン
            州または州名 = テキサス
            国名 = 米国
        サブジェクト公開鍵情報:
            公開鍵アルゴリズム: rsaEncryption
                公開鍵: (2048 ビット)
                係数:
                    00:c3:e9:ae:be:d7:a2:6f:2f:24 ...
                指数: 65537 (0x10001)
        X509v3 拡張:
            X509v3 権限キー識別子:
                キーID:36:BD:49:FF:31:2C:EB:AF:6A:40:FE:99:C0:16:ED:BA:FC:48:DD:5F
                
            権限情報アクセス:
                CA 発行者 - URI:http://www.ssl.com/repository/SSLcom-SubCA-EV-CodeSigning-RSA-4096-R3.crt
                OCSP - URI:http://ocsps.ssl.com
                
            X509v3 証明書ポリシー:
                ポリシー: 2.23.140.1.3
                ポリシー: 1.2.616.1.113527.2.5.1.7
                ポリシー: 1.3.6.1.4.1.38064.1.3.3.2
                  リポジトリ: https://www.ssl.com/repository
                  
            X509v3 拡張キー使用法:
                コード署名
            X509v3 CRL配布ポイント:
            
                フルネーム：
                  URI:http://crls.ssl.com/SSLcom-SubCA-EV-CodeSigning-RSA-4096-R3.crl
                  
            X509v3 サブジェクトキー識別子:
                EC:6A:64:06:26:A7:7A:69:E8:CC:06:D5:6F:FA:E1:C2:9A:29:79:DE
            X509v3 キーの使用法: 重要
                デジタル署名
    署名アルゴリズム: sha256WithRSAEncryption
         17:d7:a1:26:58:31:14:2b:9f:3b ...

もう 1 つのモデルは初回使用時の信頼モデルで、開発者は自分で生成したキーを提供することができます。このシナリオでは、通常、ユーザーは何らかの方法で開発者から直接公開キーを取得し、オブジェクトが初めて自分のものであることを確認する必要があります。多くのコード署名システムでは、署名内に公開キーが格納されます。実行前にコードの署名を確認するソフトウェア フレームワークや OS の中には、初回実行後、その時点からその開発者を信頼することを選択できます。アプリケーション開発者は、インストーラーに公開キーを含めることで、同様のシステムを提供できます。その後、キーを使用して、アップグレード、プラグイン、または別のアプリケーションなど、実行する必要がある後続のオブジェクトがすべて同じ開発者からのものであることを検証できます。

タイムスタンプは、証明書の有効期限が切れた場合に表示される信頼の警告を回避するために設計されました。実際には、タイムスタンプはコードの信頼を証明書の有効期間を超えて拡張します。^[13]

侵害により証明書を取り消さなければならない場合、侵害が発生した日時が失効記録の一部となります。この場合、タイムスタンプは、コードが証明書の侵害前に署名されたか後に署名されたかを確認するのに役立ちます。^[13]

開発者は、 iOSおよびtvOSアプリを実際のデバイスで実行したりApp Storeにアップロードしたりする前に、アプリに署名する必要があります。これは、開発者が有効なApple Developer IDを所有していることを証明するために必要です。アプリケーションをデバイスで実行するには、有効なプロファイルまたは証明書が必要です。^[14]

他のセキュリティ対策と同様に、コード署名は破られる可能性があります。ユーザーは騙されて署名されていないコードを実行したり、検証を拒否するコードを実行したりする可能性があります。システムは秘密鍵が秘密である限り安全に保たれます。^{[15] [16]}

また、コード署名は、ソフトウェア作成者による悪意のあるアクティビティや意図しないソフトウェア バグからエンド ユーザーを保護するものではなく、ソフトウェアが作成者以外の誰によっても変更されていないことを保証するだけであることにも留意してください。サンドボックス システムでは、タイムスタンプが間違っているか、RAMが過剰に使用されているために、証明書が受け入れられない場合があります。

Microsoft は、テスト済みのドライバー向けに、Authenticode に基づくコード署名の形式を実装しています。ドライバーはカーネル内で実行されるため、システムを不安定にしたり、セキュリティ ホールを生じさせたりする可能性があります。このため、Microsoft はWHQL プログラムに提出されたドライバーをテストします。ドライバーがテストに合格すると、Microsoft はそのバージョンのドライバーを安全であると署名します。32 ビット システムのみ、コードが署名されていないことをユーザーに警告するプロンプトでインストールを許可することに同意すると、Microsoft で検証されていないドライバーをインストールできます。.NET (マネージド) コードには、証明書ではなく公開キー/秘密キーとSHA -1 ハッシュを使用するStrong Name Signingと呼ばれる追加のメカニズムがあります。ただし、Microsoft は Authenticode の代わりに Strong Name Signing を使用することを推奨していません。^[17]

CA/ブラウザフォーラムのコード署名ワーキンググループは、2023年6月1日から、すべてのコード署名証明書（EAのものだけでなく）で、少なくともFIPS 140-2レベル2またはCommon Criteria EAL 4+に準拠したハードウェア暗号モジュールなどの物理メディアへの秘密鍵の保存を義務付けることを決定しました。^[18] CAはその後、この決定への準拠に関する発表を行いました。^{[19] [20] [21] [22] [23] [24] [25]}

ゲーム コンソールなどの消費者向けデバイスのコンテキストでは、「署名されていないコード」という用語は、ソフトウェアが受け入れられて実行するために通常必要な暗号化キーで署名されていないアプリケーションを指すためによく使用されます。ほとんどのコンソール ゲームは、コンソール メーカーが設計した秘密キーで署名する必要があります。そうしないと、ゲームはコンソールに読み込まれません (ベンダー ロックインの強化とソフトウェアの著作権侵害の防止の両方の目的のため)。署名されていないコードを実行するには、ソフトウェアエクスプロイト、モッドチップの使用、スワップ トリックと呼ばれる手法、またはソフトモッドの実行など、いくつかの方法があります。

署名されたアプリケーションを別の DVD にコピーするだけでは起動できない理由は、最初は明らかではないかもしれません。Xbox の場合、その理由は、Xbox 実行ファイル (XBE) にメディア タイプ フラグが含まれており、このフラグによって XBE を起動できるメディアの種類が指定されているためです。ほぼすべての Xbox ソフトウェアでは、実行ファイルが工場で製造されたディスクからのみ起動するように設定されているため、実行ファイルを書き込み可能なメディアにコピーするだけで、ソフトウェアの実行を停止できます。

ただし、実行可能ファイルは署名されているため、フラグの値を単純に変更することはできません。これにより、実行可能ファイルの署名が変更され、チェック時に検証に失敗することになります。

• デジタル署名
• iOS の脱獄
• プレイステーションポータブル自作ソフト
• 権限の昇格
• ルート化（Android OS）
• Symbian OS セキュリティバイパス

• Apple コード署名ガイド
• Microsoft コード署名入門
• Debian セキュリティ インフラストラクチャ
• 強力な配布方法