デジタル署名は、プログラムの発行元を明らかにし、プログラムが改変されていないことを確認するものです。カスタマイズしたブラウザ パッケージやカスタム プログラムにはデジタル署名を施し、ユーザーがカスタム ブラウザをインストールするときに警告を受けないようにする必要があります。デジタル署名の施されていない ActiveX コントロールや Java パッケージは、ユーザーがインストールできないかもしれません。デジタル証明に関する情報は、Internet Explorer 管理者キット ウィザードを使用しているときに指定しなければなりません。
カスタム ブラウザ パッケージを作成する場合は、それらをインターネットまたはイントラネットに送る前に、IEAK で作成したカスタム キャビネット (.cab) ファイルにデジタル署名を施す必要があります。.cab ファイルおよびカスタム プログラムに署名を施すには、デジタル証明の取得とコードへの署名という 2 つの手順を実行する必要があります。
デジタル証明は、取得したら、コンピュータ上で認可しなければなりません。それが終わったら、Internet Explorer 管理者キット ウィザードの中で、パッケージ内のファイルの署名に使用する発行元の証明を選択するよう指示されます。
カスタム ブラウザ パッケージを作成し終えたら、次のファイルに署名しなければなりません。
注意
デジタル証明は、Authenticode テクノロジの一部であり、プログラムの発行元を識別し、プログラムが改ざんされていないことを確認するものです。この証明は、2 つの発行元のうちの 1 つから取得できます。VeriSign や GTE のような認証機関 (CA) が証明を発行する場合と、個別管理の認証サーバーが証明を発行する場合とがあります。証明には、商業用 または 個人用があります。
ある会社は、ローカルな登録機関 (LRA) になる場合もあります。LRA は、登録要求を調べて事実確認を行った後、署名処理を行う CA に承認済みの要求を渡します。CA と LRA では担当業務が異なっている場合もありますが、それは契約書で定められています。
では、大学の場合を例にとって、CA と LRA の関係を説明しましょう。VeriSign は、CA に関するサービスをすべて提供するルートの CA と言えるかもしれません。修士過程にいるすべての学生に、大学が証明書を発行する場合を考えてみましょう。大学側では、学生の身元を認証し、必要な事務処理を行います。しかし、その責任に関する問題は、背負いたくないかもしれません。そのような場合、大学は、責任に関する問題をルートの CA に委託することにより、自らは LRA として機能することができます。
証明の入手後、コード署名をする必要があります。IEAK リソース キットでは、コード署名ウィザード (Signcode.exe) のようなコード署名用のツールを利用することができます。これらのツールは、\Program Files\IEAK\Reskit\Tools フォルダに入っています。Microsoft Internet Client SDK には、そのほかの追加リソースがあります。
ソフトウェアの発行元が作成し、暗号化と解読にペアで使用されるパブリック キーとプライベート キーを知っておくことも必要です。これらのキーは、CA が証明を要求した時点で、ご使用のコンピュータ上で生成されます。プライベート キーが CA やその他の団体に送られることはありません。
ファイルにデジタル署名したり、正しく署名されたことを確認するために、次のプログラムを利用できます:
これらのツールは、IEAK と Microsoft Internet Client SDK の \Program Files\IEAK\Reskit\Tools フォルダに入っています。ツールについて詳しくは、「コード署名とテストのためのツール」を参照してください。
Authenticode は、業界で成功裡に使用されてきた仕様に基づくテクノロジであり、PKCS #7 (Cryptographic Message Syntax Standard の中の 1 つの規格)、PKCS #10 (証明要求形式)、X.509 (証明仕様)、SHA および MD5 ハッシュ アルゴリズムが含まれています。
CA は、ポリシーを発行し、さまざまな仕様で確立された基準に基づいてコード署名の認可 (証明) を付与します。また、証明の管理 (登録、更新、取り消し)、ルート キーの保管、申請者提出事項の検証、登録用ツールの提供、およびこれらの項目の処理に関連する責任の受諾も行います。CA は、その存在によってすべてのソフトウェア発行元が同じ規則に従って作業していることが保証されるため、重要な要素です。
証明の期限が切れた場合は、別のセキュリティ基準が必要になります。たとえば、すべての学生にデジタル ID で証明書を発行する場合、大学は学生が卒業するときに ID の期限が切れるように設定することもできます。コードに施した署名の証明期限が切れていると、そのコードは無効です。証明期限が切れた場合、ソフトウェアの発行元は該当コードに署名を再度施して、そのコードの新しいバージョンを送る必要があります。将来、インターネットでタイム スタンプが利用できるようになれば、ソフトウェアの発行元はタイム スタンプ付きでコードに署名を施し、コードに署名を施した時期を明らかにすることができるようになります。そうすれば、証明期限が切れた後でも、署名が施されたコードは依然として有効なものになります。
Internet Explorer では、インターネットを複数のゾーンに分類することで、セキュリティ レベルを複数個利用できます。セキュリティ ゾーンを使用すると、ユーザーはインターネット上に潜在している有害なコンテンツを避けることができます。
Internet Explorer のステータス バーの右側を見ると、現在の Web ページがどのセキュリティ ゾーンにあるかわかります。その Web ページからコンテンツを開いたり、ダウンロードしたりしようとすると、その Web サイトが属するゾーンのセキュリティ設定値が Internet Explorer によってチェックされます。
コンテンツは、いくつかの方法でゾーンに割り当てることができます。各セキュリティ レベルに対応した動作は定義済みですが、各レベルの独自の設定値はユーザーが作成することができます。
企業内管理者の方は、セキュリティ ゾーンや規制を事前に設定したり、認証機関をカスタマイズしたりできます。また、システム ポリシーと規制を使用して、セキュリティ設定値の変更をユーザーに許可するかどうかを制御することもできます。個々の設定値については、Internet Explorer のセキュリティ オプションを参照してください。
危険性のあるコンテンツをエンド ユーザーが表示しようとした場合は、警告をエンド ユーザーに表示することができます。また、署名のない ActiveX コントロールや Java パッケージのダウンロードをエンド ユーザーに禁止することもできます。
コードに対する署名は、簡単であり、短時間で行えます。コードに署名を施すとどうなるかについて、詳細に知っておく必要はありません。
コードを作成してテストした後、ソフトウェアの発行元はコードに署名を施します。すると、そのコードに単方向のハッシュ処理が適用され、固定長の "要約" が生成されます。次に、その要約は、ソフトウェア発行元のプライベート キーで暗号化された後、ハッシュ アルゴリズムの名前および証明 (ソフトウェア発行元の名前、パブリック キー、CA による証明の名前などが入っている) と一緒に署名ブロックに格納されます。今度は、この署名ブロックが、元の移植可能な実行可能 (PE) ファイル形式の予約済みセクションに挿入されます。この後、該当コードは、インターネットを通して配布されます。.cab キャビネット ファイルに署名を施すと、該当するキャビネット ファイルにも署名ブロックが格納されます。
ユーザーが該当コードをダウンロードすると、ダウンロードを実行するアプリケーションが WinVerifyTrust という API を呼び出します。システムは、署名を抽出した後、その証明を認証した CA を特定し、その CA によって配布されるソフトウェア発行元のパブリック キーを取得します。システムは次に、そのパブリック キーを使用して、要約を解読します。先ほどのハッシュ処理がコードに対して再度適用され、新しい要約が作成されます。署名以後にコードが改変されていなければ、新しい要約と以前の要約が一致するはずです。2 つの要約が一致しない場合は、コードが改変されたか、パブリック キーとプライベート キーが対応していないことになります。このいずれかの場合は、コードが疑わしいものと見なされ、ユーザーに警告が表示されます。