コード署名証明書または開発者証明書。 選択方法の種類

前回、 デジタルSSL証明書を調べましたが、今回はデジタル証明書の別のバージョンを検討します。

コード署名証明書-ソフトウェアまたはスクリプトに署名する証明書。プログラムの作成者を確認し、デジタル署名の適用後にコードが変更されないようにします。 開発者証明書とも呼ばれます。



そのため、開発者証明書にはいくつかのオプションがあります。 まず、使用するプログラムが特定の会社によって実際にリリースされたことを確認するデジタル署名メカニズムです。つまり、ソースの信頼性を保証します。 そして第二に、コンテンツの整合性、つまりソフトウェア製品に署名した瞬間から損傷や修正が加えられていないことを保証します。





Windows XP SP2以降のすべての最新バージョンのWindowsでは、このようなデジタル署名なしでソフトウェアをインストールすると、警告が表示されます。 同じことが、対応するデジタル署名のないドライバーのインストールにも当てはまります。



デジタル署名が見つからない場合、Windowsはこのプログラムに「不明な発行元」があるという警告を発行します。実行することはお勧めしません。





プログラムがデジタル署名されている場合、ウィンドウは異なって表示され、証明書に関する情報も確認できます。

コード署名証明書にはどのような種類があり、どのように違いますか？

まず最初に、それらを発行する証明機関の証明書を検討します。



異なる認証局からの証明書間の最良の違いは、ダッシュボードに表示されます。

列は証明機関の名前を示し、行には証明書の種類またはそれが使用されるテクノロジー/プラットフォームを示します。

プラットフォーム\認証局	シマンテック	タウテ	コモド	Digicert	グローバルサイン	Trustwave	Startcom
Microsoft Authenticode署名	+	+	+	+	+	+	+
Appleのコード署名	+	+		+	+	+	+
Microsoft Vba署名	+	+	+	+	+	+	+
Javaコード署名	+	+	+	+	+	+	+
Adobe Air Signing	+	+	+	+	+	+	+
カーネルモード署名	+			+	+		+
Android	+
Windows Phone	+
Qualcomm BREW	+
コスト、から	500ドル	250ドル	90ドル	220 $	220 $	330ドル	200 $

すべての認証機関が証明書が機能するプラットフォームに関する完全な情報を提供するわけではないため、認証機関によってサポートが明示的に記載されているプラ​​ットフォームのみにプラス記号が付いていることを明確にする必要があります。

Microsoft Authenticode

32ビットおよび64ビットファイル（.exe、.cab、.dll、.ocx、.msi、.xpi、および.xapファイル）の署名用。 また、Microsoft®Office、Microsoft VBA、Netscape Object Signing、Marimba Channel Signingのコード署名を許可します。

Silverlight 4アプリケーションをサポート

Appleのコード署名

開発者はMac OSのプログラムとソフトウェアの更新に署名できます

Microsoft Office Vba署名

Microsoft Office .doc、.xls、および.pptファイルのVBAオブジェクト、スクリプト、およびマクロに署名します

VBAを使用するMicrosoft Officeおよびアドオンの場合

Javaコード署名

Javaアプレットの署名用。 デスクトップおよびモバイルデバイス用の.jarファイルとJavaアプリケーションに署名できます。

認識されたJavaランタイム環境（JRE）

Adobe Air Signing

.airファイルに署名するには

すべてのAIRベースのアプリケーションに必要

カーネルモード署名

カーネルモード開発者証明書を使用すると、いわゆるカーネルモードアプリケーションとデバイスドライバーに署名できます。 64ビットバージョンのWindows VistaおよびWindows 7では、すべてのカーネルモードアプリケーションに証明書と信頼できる証明機関で署名する必要があります。

Android

Androidプラットフォーム用の.apkファイルに署名して最適化するには

Microsoft Windows Phone

Windows PhoneおよびXbox 360のデジタル署名アプリケーション用。MicrosoftApp Hubに必要

Qualcomm BREW

BREWプラットフォーム（ワイヤレス用バイナリランタイム環境）用のアプリケーションを開発する人向け

コード署名証明書の仕組み：

コード署名プロセス。

1. 発行者（開発者）は、証明機関にコード署名証明書を要求します
2. SIGNCODE.EXEまたは別の発行者コード署名ユーティリティを使用して、MD5またはSHAアルゴリズムを使用してコードハッシュを作成します
3. 秘密鍵を使用してハッシュをエンコードします
4. コード、暗号化されたハッシュ、および発行者証明書を含むパッケージを作成します

署名されたコードを検証するプロセス。

1. ユーザーは署名されたソフトウェアをダウンロードまたはインストールし、ユーザーのプラットフォームまたはシステムは発行者の証明書を確認します。発行者の証明書は、証明機関のルート秘密キーによって署名されています
2. システムは、パブリッシャーと同じハッシュアルゴリズムを使用してコードを実行し、新しいハッシュを作成します
3. 証明書に含まれている発行者の公開キーを使用して、システムは暗号化されたハッシュを解読します
4. そして、2つのハッシュを比較します

認証局

開発者がデジタル証明書を要求すると、認証局はそれを識別し、認証局のルート証明書に関連付けられた証明書を発行します。 プラットフォームとデバイスには、対応する証明機関のルート証明書が含まれています。 つまり、プラットフォームまたはデバイスが証明機関を信頼している場合、この証明機関によって署名された証明書を信頼します。

ハッシュが一致しない場合、そのようなソフトウェアの起動時にエラーが表示されます-これは、ソフトウェアがウイルスまたは攻撃者によって変更されたことを意味する場合があります。



ソフトウェアがデジタル署名を復号化するとき、検証された情報のソースであるシステムのルート証明書もチェックします。 自己署名証明書を使用すると、「発行元を確認できません」というエラーが表示されます。 したがって、ルート証明書がプログラムの対象ユーザーと共にシステムに既にインストールされている証明機関の証明書を使用することが重要です。



組織の検証プロセス自体については説明しません。 これは、 前の記事ですでに説明した組織の検証を伴うSSL証明書の場合と同じであるためです。

タイムスタンプに関するいくつかの言葉。

タイムスタンプまたはタイムスタンプは、デジタル署名がいつ作成されたかを示すために使用されます。 そのようなラベルが存在する場合、署名を検証するアプリケーションは、署名に関連付けられた証明書が署名時に有効であったかどうかを確認します。 そのようなマークがなく、証明書の有効期限が切れている場合、署名は無効と見なされます。



例：

証明書は、01.01から有効です。 2008年

証明書の有効期限：2010年12月31日

署名：2009年7月4日

署名の検証：2012年4月30日



署名時に証明書が有効だったため、タイムスタンプを使用して署名が検証されます。 このようなラベルがないと、検証時に証明書の有効期限が切れているため、証明書は検証に合格しません。

つまり、このようなラベルを使用すると、証明書の有効期限が切れた後でも、署名されたコードを使用できます。

まとめると

証明書を選択するには、最初に必要なプラットフォームの証明書を発行する証明機関を選択する必要があり、次に選択は基本的に価格と人気のために証明機関を選択することになります。多くの場合、顧客は以前に使用した証明機関を選択します。

いくつかのヒント。

1. ソフトウェア署名を実行するのと同じマシンから証明書のアプリケーションに記入することをお勧めします。
2. ほとんどの認証局は、インターネットエクスプローラーを介して証明書アプリケーションを生成することを推奨していますが、他のブラウザーを介してアプリケーションを生成することも問題ありませんでした。

私自身は開発者ではないので、自分の能力の範囲内で、開発者証明書に関する質問に喜んでお答えします。

また、このような証明書を使用する人からの追加や説明にも満足しています。



UPD：タイムスタンプ（タイムスタンプ）に関する重要な情報を追加、 TolTolとcrea7orに感謝