Loading article…
コード署名とは、ソフトウェアの作成者を確認し、署名後にコードが改ざんまたは破損していないことを保証するため、実行可能ファイルやスクリプトにデジタル署名を 行うプロセスです。このプロセスでは、暗号学的ハッシュを使用して真正性と完全性を検証します。[ 1 ] コード署名は、1995 年に Michael Doyle によって、Eolas WebWish ブラウザ プラグインの一部として発明されました。このプラグインは、公開鍵暗号を使用して、秘密鍵でダウンロード可能な Web アプリ プログラム コードに署名することを可能にし、プラグイン コード インタプリタが対応する公開鍵を使用してコードを認証してから、コード インタプリタの API へのアクセスを許可できるようにします。[ 2 ] [ 3 ]
コード署名は、いくつかの貴重な機能を提供します。コード署名の最も一般的な用途は、デプロイ時のセキュリティを確保することです。一部のプログラミング言語では、名前空間の競合を防ぐためにも使用できます。ほぼすべてのコード署名実装は、作成者またはビルドシステムの身元を確認するための何らかのデジタル署名メカニズムと、オブジェクトが変更されていないことを確認するためのチェックサムを提供します。また、オブジェクトに関するバージョン情報を提供したり、オブジェクトに関するその他のメタデータを保存したりするためにも使用できます。 [ 4 ]
ソフトウェアの認証メカニズムとしてのコード署名の有効性は、基盤となる署名鍵のセキュリティに依存します。他の公開鍵基盤（PKI）技術と同様に、システムの完全性は、発行者が秘密鍵を不正アクセスから保護することに依存します。汎用コンピュータ上のソフトウェアに保存された鍵は、侵害される可能性があります。したがって、鍵をハードウェアセキュリティモジュール（ HSM）と呼ばれる安全で改ざん防止機能のある暗号化ハードウェアデバイスに保存する方が安全であり、ベストプラクティスです。[ 5 ]
多くのコード署名実装では、 TLSやSSHで採用されているプロセスと同様に、公開鍵と秘密鍵のペアを使用するシステムでコードに署名する方法が提供されます。たとえば、.NETの場合、開発者はライブラリや実行可能ファイルをビルドするたびに秘密鍵を使用して署名します。この鍵は、開発者またはグループごとに、あるいはアプリケーションやオブジェクトごとに一意になります。開発者は、この鍵を自分で生成することも、信頼できる認証局（CA）から取得することもできます。[ 6 ]
コード署名は、 Java アプレット、ActiveXコントロール、その他のアクティブな Web およびブラウザー スクリプト コードなど、特定のコードのソースがすぐには明らかにならない分散環境で特に価値があります。もう 1 つの重要な用途は、既存のソフトウェアに安全にアップデートとパッチを提供することです。 [ 7 ] Windows、Mac OS X、およびほとんどのLinux ディストリビューションは、パッチ システムを介して悪意を持ってコードを配布できないようにするために、コード署名を使用してアップデートを提供します。これにより、アップデートがサードパーティまたは物理メディア (ディスク) によって提供された場合でも、受信側のオペレーティングシステムがアップデートが正当であることを検証できます。[ 8 ]
コード署名は、Windows および Mac OS X でソフトウェアを初回実行時に認証するために使用され、ソフトウェアが第三者の配布者またはダウンロード サイトによって悪意を持って改ざんされていないことを保証します。Linux では、この形式のコード署名は使用されません。これは、Linux プラットフォームが分散型であり、パッケージ マネージャーがあらゆる種類のソフトウェア (アップデートやパッチだけでなく) の主要な配布方法であること、および必要に応じてソース コードを直接検査できるオープンソース モデルであるためです。Debianベースの Linux ディストリビューション (その他) は、公開鍵暗号を使用してダウンロードされたパッケージを検証します。[ 9 ]
コード署名の認証に使用される公開鍵は、信頼できるルート認証局 (CA) に遡って追跡可能である必要があり、できれば安全な公開鍵基盤 (PKI) を使用することが望ましい。これは、コード自体が信頼できることを保証するものではなく、指定されたソース (より具体的には、特定の秘密鍵) から来ていることを保証するだけである。[ 10 ] CA はルート信頼レベルを提供し、プロキシを介して他の認証局に信頼を割り当てることができる。ユーザーが CA を信頼する場合、その CA またはそのプロキシのいずれかによって生成された鍵で署名されたコードの正当性をユーザーは信頼できると考えられる。多くのオペレーティングシステムとフレームワークには、1 つ以上の認証局に対する信頼が組み込まれている。また、大規模な組織では、組織内部にプライベート CA を実装することが一般的であり、これは公開 CA と同じ機能を提供するが、組織内でのみ信頼される。
拡張検証(EV) コード署名証明書は、追加の検証および技術要件の対象となります。これらのガイドラインは、CA/B フォーラムのベースライン要件および拡張検証ガイドラインに基づいています。EV に特有の検証要件に加えて、EV コード署名ガイドラインでは、「加入者の秘密鍵は、FIPS 140-2レベル 2 の要件を満たすか、それを超える暗号モジュールで生成、保存、使用される」と規定されています。 [ 11 ]
Windows 10 カーネルモード ドライバーの署名など、特定のアプリケーションでは EV コード署名証明書が必要です。[ 12 ]さらに、Microsoft の IEBlog では、Windows プログラムは「EV コード署名証明書で署名されると、そのファイルや発行元に以前の評判がなくても、 SmartScreen評判サービスですぐに評判を確立できる」と述べています。[ 13 ]
これは、SSL.com がソフトウェアの署名に使用する、デコードされた EV コード署名証明書の例です。SSL.com EV Code Signing Intermediate CA RSA R3は発行者の共通名として表示され、これが 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 地域名 = ヒューストン 州または県名 = テキサス 国名 = 米国 有効 期限：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番地 スイート503 事業区分 = 民間組織 郵便番号 = 77098 commonName = SSL Corp シリアル番号 = NV20081614243 組織名 = SSL Corp 地域名 = ヒューストン 州または県名 = テキサス 国名 = 米国 主題公開鍵情報: 公開鍵暗号アルゴリズム：rsa暗号化 公開鍵: (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 CPS: 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 ...
もう一つのモデルは、初回使用時に信頼するモデルで、開発者が独自の自己生成キーを提供することを選択できます。このシナリオでは、ユーザーは通常、オブジェクトが初めて開発者から提供されたものであることを確認するために、何らかの方法で開発者から直接公開鍵を取得する必要があります。多くのコード署名システムは、署名内に公開鍵を保存します。コードの実行前に署名をチェックする一部のソフトウェアフレームワークやOSでは、初回実行後、その開発者を信頼するかどうかを選択できます。アプリケーション開発者は、インストーラーに公開鍵を含めることで、同様のシステムを提供できます。その後、この鍵を使用して、アップグレード、プラグイン、別のアプリケーションなど、実行する必要のある後続のオブジェクトがすべて同じ開発者から提供されたものであることを検証できます。
タイムスタンプは、証明書の有効期限が切れた場合に表示される信頼警告を回避するために設計されました。事実上、タイムスタンプは証明書の有効期間を超えてコードの信頼を延長します。[ 14 ]
証明書が侵害されたために失効する必要が生じた場合、侵害が発生した特定の日時が失効記録の一部となります。この場合、タイムスタンプは、コードが証明書の侵害前か侵害後に署名されたかを判断するのに役立ちます。[ 14 ]
開発者は、 iOSおよびtvOSアプリを実際のデバイスで実行したり、App Storeにアップロードしたりする前に、アプリに署名する必要があります。これは、開発者が有効なApple Developer ID を所有していることを証明するために必要です。アプリケーションがデバイス上で実行されるには、有効なプロファイルまたは証明書が必要です。[ 15 ]
他のセキュリティ対策と同様に、コード署名も破られる可能性があります。ユーザーは署名されていないコードを実行するように騙されたり、検証を拒否するコードを実行するように騙されたりすることがあり、システムは秘密鍵が秘密に保たれている限りにおいてのみ安全です。[ 16 ] [ 17 ]
また、コード署名は、ソフトウェア作成者による悪意のある行為や意図しないソフトウェアのバグからエンドユーザーを保護するものではなく、ソフトウェアが作成者以外によって変更されていないことを保証するものである点にも注意が必要です。サンドボックスシステムによっては、タイムスタンプの誤りやRAMの過剰使用などが原因で証明書が受け入れられない場合があります。
Microsoft は、Microsoft がテストしたドライバー向けに (Authenticode に基づく) コード署名方式を実装しています。ドライバーはカーネル内で実行されるため、システムを不安定にしたり、セキュリティホールを開いたりする可能性があります。そのため、Microsoft はWHQL プログラムに提出されたドライバーをテストしています。ドライバーがテストに合格すると、Microsoft はそのバージョンのドライバーが安全であることを示す署名を行います。32 ビット システムの場合のみ、Microsoft で検証されていないドライバーをインストールするには、コードが署名されていないことをユーザーに警告するプロンプトが表示され、インストールを許可することに同意する必要があります。.NET (マネージド) コードには、証明書の代わりに公開鍵/秘密鍵とSHA -1 ハッシュを使用するStrong Name Signingと呼ばれる追加のメカニズムがあります。ただし、Microsoft は Authenticode の代替として Strong Name Signing に依存することを推奨していません。[ 18 ]
CA/Browser Forumのコード署名ワーキンググループは、2023 年 6 月 1 日から、すべてのコード署名証明書 (EA 証明書だけでなく) は、少なくとも FIPS 140-2 レベル 2 またはCommon Criteria EAL 4+ に準拠したハードウェア暗号モジュールなどの物理メディアに秘密鍵を保存することを義務付ける必要があると決定しました。[ 19 ]その後、認証局は、この決定への準拠に関する発表を行いました。[ 20 ] [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ] [ 26 ]
ゲーム機などの消費者向けデバイスの文脈では、「署名なしコード」という用語は、ソフトウェアが受け入れられて実行されるために通常必要とされる暗号鍵で署名されていないアプリケーションを指すためによく使用されます。ほとんどのコンソールゲームは、コンソールメーカーが設計した秘密鍵で署名する必要があり、そうでないとゲームはコンソールにロードされません（ベンダーロックインを強制し、ソフトウェアの不正コピーに対抗するため）。署名なしコードを実行させる方法はいくつかあり、ソフトウェアの脆弱性を悪用したり、モッドチップを使用したり、スワップトリックと呼ばれるテクニックを使用したり、ソフトモッドを実行したりすることができます。
署名済みのアプリケーションを別のDVDにコピーするだけで起動できない理由が、最初は分かりにくいかもしれません。Xboxの場合、その理由は、Xbox実行ファイル（XBE）にメディアタイプフラグが含まれており、XBEが起動可能なメディアの種類を指定しているためです。ほぼすべてのXboxソフトウェアでは、このフラグは工場出荷時のディスクからのみ起動するように設定されているため、実行ファイルを書き込み可能なメディアにコピーするだけで、ソフトウェアの実行が停止してしまうのです。
しかし、実行ファイルは署名されているため、フラグの値を変更するだけでは実行ファイルの署名が変更され、検証時にエラーとなるため、変更することはできません。
（セクション1.2.2）[...] 2023年6月1日以降、コード署名証明書については、CAは、加入者の秘密鍵が、セクション6.2.7.4.1で指定された要件を満たすかそれを超える適切なハードウェア暗号モジュールで、6.2.7.4.2のいずれかの方法を使用して生成、保存、使用されることを保証しなければならない。