歴史
コード署名
コード署名とは、実行可能ファイルとスクリプトにデジタル署名して、ソフトウェアの作成者を確認し、コードが署名されてからコードが変更または破損されていないことを保証するプロセスです。このプロセスでは、暗号化ハッシュを使用して、信頼性と整合性を検証します。
コード署名は、いくつかの貴重な機能を提供できます。コード署名の最も一般的な用途は、展開時にセキュリティを提供することです。一部のプログラミング言語では、名前空間の競合を防ぐためにも使用できます。ほぼすべてのコード署名実装は、作成者またはビルドシステムの身元を確認するための何らかのデジタル署名メカニズムと、オブジェクトが変更されていないことを確認するためのチェックサムを提供します。また、オブジェクトに関するバージョン情報を提供したり、オブジェクトに関する他のメタデータを保存したりするためにも使用できます。
ソフトウェアの認証メカニズムとしてのコード署名の有効性は、署名キーを支えるセキュリティに依存します。他の公開キー基盤（PKI）テクノロジと同様に、システムの整合性は、発行者が秘密キーを不正アクセスから保護することに依存しています。汎用コンピューターのソフトウェアに保存されているキーは、侵害されやすいです。したがって、ハードウェアセキュリティモジュールまたはHSMと呼ばれる、安全で改ざん防止された暗号化ハードウェアデバイスにキーを格納する方が、より安全であり、ベストプラクティスです。
セキュリティの提供
多くのコード署名実装は、TLSまたはSSHで採用されているプロセスと同様に、公開キーと秘密キーのペアを含むシステムを使用してコードに署名する方法を提供します。たとえば、.NETの場合、開発者はプライベートキーを使用して、ビルドするたびにライブラリまたは実行可能ファイルに署名します。このキーは、開発者またはグループに固有であるか、アプリケーションまたはオブジェクトごとに固有です。開発者は、このキーを自分で生成するか、信頼できる認証局（CA）から取得できます。
コード署名は、Javaアプレット、ActiveXコントロール、その他のアクティブなWebおよびブラウザスクリプトコードなど、特定のコードのソースがすぐにはわからない分散環境で特に役立ちます。 Windows、Mac OS X、およびほとんどのLinuxディストリビューションは、コード署名を使用してアップデートを提供し、他の人がパッチシステムを介して悪意を持ってコードを配布できないようにします。更新がサードパーティまたは物理メディア（ディスク）によって配信された場合でも、受信側のオペレーティングシステムが更新が正当であることを確認できます。
コード署名はWindowsおよびMac OS Xで最初の実行時にソフトウェアを認証するために使用され、サードパーティのディストリビューターまたはダウンロードサイトによってソフトウェアが不正に改ざんされていないことを保証します。このプラットフォームの分散型の性質のため、この形式のコード署名はLinuxでは使用されません。パッケージマネージャーは、すべての形式のソフトウェア（更新やパッチだけでなく）の主要な配布モードであり、直接検査が可能なオープンソースモデルです必要に応じてソースコードの（特に）DebianベースのLinuxディストリビューションは、公開キー暗号化を使用してダウンロードしたパッケージを検証します。
認証局（CA）を使用した信頼できるID
コード署名の認証に使用する公開鍵は、できればセキュアな公開鍵インフラストラクチャ（PKI）を使用して、信頼されたルート機関CAにさかのぼって追跡できる必要があります。これは、コード自体が信頼できることを保証するものではなく、指定されたソース（または、より明確に、特定の秘密鍵）からのものであるということだけを保証します。 CAはルート信頼レベルを提供し、プロキシによって他のユーザーに信頼を割り当てることができます。ユーザーがCAを信頼する場合、そのCAまたはそのプロキシのいずれかによって生成されたキーで署名されたコードの正当性をユーザーはおそらく信頼できます。多くのオペレーティングシステムとフレームワークには、1つ以上の既存のCA（Entrust Datacard、VeriSign / Symantec、DigiCert、Comodo、GoDaddy、GlobalSignなど）に対する組み込みの信頼が含まれています。大規模な組織では、組織内にプライベートCAを実装することも一般的であり、パブリックCAと同じ機能を提供しますが、組織内でのみ信頼されます。
CAの代替
もう1つのモデルは、開発者が独自の自己生成キーを提供することを選択できる場所です。このシナリオでは、通常、ユーザーは何らかの方法で開発者から直接公開キーを取得して、初めてオブジェクトが自分のものであることを確認する必要があります。多くのコード署名システムは、署名内に公開鍵を保存します。実行前にコードの署名をチェックするソフトウェアフレームワークとOSによっては、最初の実行後のその時点からその開発者を信頼することを選択できます。アプリケーション開発者は、公開キーをインストーラーに含めることにより、同様のシステムを提供できます。その後、キーを使用して、アップグレード、プラグイン、別のアプリケーションなど、実行する必要がある後続のオブジェクトがすべて同じ開発者からのものとして検証されるようにすることができます。
タイムスタンプ
タイムスタンプは、有効期限が切れた証明書の場合に表示される信頼警告を回避するように設計されています。実際、タイムスタンプは、コードの信頼を証明書の有効期間を超えて拡張します。
侵害により証明書を失効させる必要がある場合、侵害イベントの特定の日時が失効記録の一部になります。この場合、タイムスタンプは、証明書が侵害される前または後にコードが署名されたかどうかを確認するのに役立ちます。
Xcodeのコード署名
開発者は、iOSおよびtvOSアプリを実際のデバイスで実行する前、およびApp Storeにアップロードする前に署名する必要があります。これは、開発者が有効なApple Developer IDを所有していることを証明するために必要です。アプリケーションは、デバイスで実行できるように有効なプロファイルまたは証明書を必要とします。
問題点
他のセキュリティ対策と同様に、コード署名は無効にすることができます。ユーザーをだまして、署名されていないコードを実行したり、検証を拒否するコードを実行したりすることもできます。システムは、秘密キーが秘密である限り安全です。
また、コード署名はエンドユーザーを悪意のある活動やソフトウェア作成者による意図しないソフトウェアのバグから保護するものではなく、ソフトウェアが作成者以外によって変更されていないことを保証するだけです。タイムスタンプが間違っているか、RAMが過剰に使用されているため、サンドボックスシステムが証明書を受け入れない場合があります。
実装
IBMのLotus Notesには、リリース1からのコードのPKI署名があり、クライアントソフトウェアとサーバーソフトウェアの両方に、特定のユーザーに許可されるデータ、環境、およびファイルシステムへのアクセスレベルを制御する実行制御リストがあります。スクリプト、アクション、エージェントなどのアクティブなアイテムを含む個々の設計要素は、エディターとドメインの公開キーの両方を含むエディターのIDファイルを使用して常に署名されます。メールテンプレートなどのコアテンプレートは、Lotusテンプレート開発チームが保持する専用IDで署名されます。
Microsoftは、Microsoftがテストしたドライバーに提供される（Authenticodeに基づく）コード署名の形式を実装しています。ドライバーはカーネルで実行されるため、システムを不安定にしたり、システムをセキュリティホールにさらしたりする可能性があります。このため、Microsoftは、WHQLプログラムに提出されたドライバーをテストします。ドライバーが合格すると、Microsoftはそのバージョンのドライバーに安全であると署名します。 32ビットシステムでのみ、コードが署名されていないことをユーザーに警告するプロンプトでインストールを許可すると、Microsoftで検証されていないドライバーをインストールできます。 .NET（マネージド）コードの場合、証明書ではなく公開/秘密キーとSHA-1ハッシュを使用する厳密な名前の署名と呼ばれる追加のメカニズムがあります。ただし、Microsoftは、Authenticodeの代わりとして厳密な名前の署名に依存することを推奨していません。
ゲーム機器および民生機器の未署名コード
ゲームコンソールなどのコンシューマデバイスのコンテキストでは、通常、ソフトウェアの受け入れと実行に必要な暗号化キーで署名されていないアプリケーションを参照するために、署名されていないコードが使用されます。ほとんどのコンソールゲームは、コンソールメーカーが設計した秘密キーで署名する必要があります。そうしないと、ゲームがコンソールにロードされません。署名されていないコードを実行するには、ソフトウェアの悪用、modchipの使用、スワップトリックまたはsoftmodの実行として知られる手法など、いくつかの方法があります。
署名済みのアプリケーションを別のDVDにコピーするだけでは起動できない理由は、最初は明らかではないかもしれません。 Xboxでは、Xbox実行可能ファイル（XBE）にメディアタイプフラグが含まれており、XBEが起動可能なメディアのタイプを指定しているためです。ほとんどすべてのXboxソフトウェアでは、これは実行可能ファイルが工場で作成されたディスクからのみ起動するように設定されているため、実行可能ファイルを書き込み可能なメディアにコピーするだけでソフトウェアの実行を停止できます。
ただし、実行可能ファイルは署名されているため、フラグの値を単に変更することはできません。これにより、実行可能ファイルの署名が変更され、チェック時に検証に失敗します。
接続されたデバイスの増殖
接続されたデバイスの増殖は、デバイスを識別および認証する能力を得るために必要です。この機能は、モノのインターネット（IoT）の分野に適用されます。 IoTでは、デバイスを信頼する必要があります。 IoTでは、ソフトウェアリリースプロセスのコード署名により、IoTデバイスのソフトウェアとファームウェアの更新の整合性が確保され、デバイスまたはデバイスに組み込まれたコードの改ざんに関連するリスクから保護されます。デバイスクレデンシャルにより、ハイテク製品の製造プロセスを制御し、偽造品の不正生産を防止できます。このテクノロジーは、コード署名とともに、物理的信頼性と、デジタル出生証明書の使用による製造時、または製品ライフサイクル中のコード検証によるその後のアップグレード時に、所有するコードの信頼性と整合性を保証します。これにより、コード署名の新しい次元が生まれ、セキュリティ意識が高まり、専用の保護された環境内で秘密署名キーを保護してシステム全体の信頼のルートを確立する必要性が高まります。マルウェアとAdvanced Persistent Threats（APT）のGiven延を考えると、多くのソフトウェアベンダー、オンラインサービスのプロバイダー、エンタープライズIT組織、およびハイテクIoTデバイスのメーカーは、ハイテク製造およびコード署名プロセスのセキュリティを強化する圧力を受けています。
