解説
インサイド .NET Framework
第10回 コード・アクセス・セキュリティ（その2）
インフォテリア株式会社
吉松 史彰
2002/10/18
|
 |
X.509証明書によるエビデンスの提供
ここまでの説明では、アセンブリがどこから来たものか（Zone、Url、Site）というエビデンスと、どのアセンブリなのか（StrongName、Hash）というエビデンスが取得できていた。だが場合によっては、だれが作ったアセンブリなのかによってセキュリティ設定を変えたいこともあるだろう。特定のパートナー会社製のアセンブリには高い特権を与え、それ以外はデフォルトで運用するといったニーズがあるはずだ。
アセンブリに厳密名を付けると、アセンブリにデジタル署名が施されて、結果としてアセンブリが署名後に改ざんされていないことの確認ができるようになる。しかし、アセンブリに厳密名が付いているからという理由だけで、そのアセンブリをセキュリティ上「信頼」することはできない。なぜなら、悪意を持った開発者でもデジタル署名自体は簡単にできるからだ。デジタル署名には署名者の情報はまったく含まれていない。つまり、StrongNameというエビデンスでは、「だれが作ったものなのか？」は分からないということだ。例えば、.NET FrameworkをインストールすればMicrosoftのpublicKeyの値が分かるので、それとほかのアセンブリのpublicKeyとを比較すれば「これはMicrosoftの秘密キーで署名されていない」ということは分かる。しかし、「それに署名した人の名前は？」という問いには答えられない。
この疑問に答えるためには、証明書と呼ばれるデータをコードに添付する必要がある。通常の証明書は第三者機関が発行するため、証明書を取得する人はまず自分自身をその第三者機関に証明しなければならない。その上で、自分が間違いなく名乗ったとおりの開発者であることを証明する書類（電子的なデータ）をもらい、それを自分の開発物に添付して、自分が開発したものであることを証明する。実行する側のユーザーは、証明書を確認した上で、その開発者に悪意がないことを信用する（または信用しない）。信用できれば、そのコードを実行する。ユーザーが信用してくれるかどうかは、証明書に書いてある自分に関する情報と、その証明書の内容を証明してくれる第三者機関に関する情報を、ユーザーがどの程度信用できるかということにかかってくる。いくら証明書が添付されていても、そこに示されている名前が「Benny/29A」や「Gigabyte」などとなっていたときに*1、彼らを信用してインターネットからそのアセンブリをダウンロードする人はまずいないだろう。結局のところ、証明書も信用判断の基準にすぎない。証明書自身が信用を提供することはないので注意して欲しい。
| *1 「Benny/29A」は「初の.NETウイルス」として騒がれたW32.Donutの作者で、「Gigabyte」は「C#を使って開発された初のウイルス」としてこれまた騒がれたSharpeiの作者だ。 |
.NET Frameworkのアセンブリには、この証明書を添付することができる。ちょうどActiveXコントロールに証明書が添付できるのと同じだ。正規の手順を踏んで、第三者機関から証明書を発行してもらっている場合は、それを利用すればよい。単にテストをしたいだけであれば、.NET Framework SDKにmakecert.exeというテスト用の証明書作成ツールがある。また、Microsoftがテスト用に公開しているCertificate ServiceのWebサイトにアクセスして**、証明書を発行してもらうこともできる（コラム参照）。アセンブリに証明書を添付するには、.NET Framework SDKに付属のsigncode.exeを利用する。
| ** 編集部注： 2002年10月末現在、Microsoftが公開しているこのテスト用サイトにはアクセスできなくなっています。 |
signcode.exeを実行すると、[デジタル署名ウィザード]が起動する。
 |
| [デジタル署名ウィザード]の起動画面 |
|
.NET Framework SDKに付属するsigncode.exeを実行すると起動する。 |
次へボタンをクリックすると、署名対象のファイルを選択する画面になる。ここではアセンブリのプライマリ・モジュール・ファイルを選択する。
 |
| [デジタル署名ウィザード]の[ファイルの選択] |
| 署名対象のファイルとしてアセンブリのプライマリ・モジュール・ファイル（今回の場合はFileReader.dll）を選択 |
次へボタンをクリックすると、署名に関するオプションを指定するかどうかを選択する画面になる。
 |
| [デジタル署名ウィザード]の[署名のオプション] |
|
今回は、ここで[通常]を選択する。 |
[カスタム]を選択すると、証明書に関するさまざまな設定を行うことができるが、通常は文字通り[通常]を選択すればよいだろう。次へボタンをクリックすると、証明書を選択する画面になるので、用意した証明書を選択する。
 |
| [デジタル署名ウィザード]の[証明書の署名] |
| ここではあらかじめ用意しておいた証明書を選択する。 |
次へボタンをクリックし、説明やWebサイトの情報を必要に応じて入力する。
 |
| [デジタル署名ウィザード]の[データの説明] |
| 説明やWebサイトの情報を入力する。入力内容はアセンブリのエビデンスには関係ない。 |
ここで入力した内容は、アセンブリのエビデンスには関係ないので、何を入力してもよい。次へボタンをクリックし、タイムスタンプ・サービスは特に設定せずに、
 |
| [デジタル署名ウィザード]の[タイムスタンプ] |
| 今回は特にタイムスタンプ・サービスは設定しない。 |
また次へボタンをクリックすると完了画面が表示されるので、
 |
| [デジタル署名ウィザード]の完了画面 |
完了ボタンをクリックして終了する。これでアセンブリ（のファイル）に証明書が添付された。
ここで、証明書を添付したFileReader.dllをあらためて適切な場所にコピーして、もう一度MainClass.exeを実行してみると、今度は次のような情報が表示される。またホスト・エビデンスが1つ増えて6つになっているのが分かる*2。
*2 もしここでホスト・エビデンスが5つのままだった場合は、ダウンロード・キャッシュに前のものが残っている可能性があるので、次のコマンドでキャッシュを削除する。
C:\TEMP>gacutil -cdl |
C:\TEMP>MainClass.exe C:\Boot.ini
Zone:Intranet
Url:http://localhost/filereader.dll
Site:localhost
StrongName:name=FileReader, version=1.0.0.0, publicKey=0024…（略）
Hash:C0 23 A1 AA 2C 61 3B BC 83 AB 26 A9 FE EC 6D CB 82 5B 8D 26
0:6
|
|
| FileReader.dllに証明書を添付してからMainClass.exeを実行した結果の例 |
| またホスト・エビデンスの数が6つに増えている。 |
もう一度最初のコードで増えたエビデンスを確かめてみると、増えたのはSystem.Security.Policy.Publisherというエビデンスであることが分かる。そこで、次のようなコードを追加する。
case "System.Security.Policy.Publisher":
System.Security.Policy.Publisher pub
= (System.Security.Policy.Publisher)e2.Current;
Console.WriteLine("Publisher:{0}", pub.Certificate.GetName());
break;
|
|
| MainClass.csに追加するPublisherエビデンスに対応したcase文 |
|
これによりPublisherエビデンスに含まれている値が表示される。 |
こうしてMainClass.exeを実行すると、結果は次のようになる。
C:\TEMP>MainClass.exe C:\Boot.ini
Zone:Intranet
Url:http://localhost/filereader.dll
Site:localhost
Publisher:CN=Fumiaki Yoshimatsu
StrongName:name=FileReader, version=1.0.0.0, publicKey=0024…（略）
Hash:C0 23 A1 AA 2C 61 3B BC 83 AB 26 A9 FE EC 6D CB 82 5B 8D 26
0:6
|
|
| 追加したcase文により表示されるPublisherエビデンスの値 |
このように、証明書によってアセンブリの開発者を特定するためのエビデンスが収集されるようになるのだ。先に「ActiveXコントロールと同じだ」と書いたが、.NET FrameworkのアセンブリはActiveXコントロールをダウンロードするときとは違い、証明書が添付されていてもそれだけで自動的に何らかの特権が与えられるわけではない。証明書はあくまでもエビデンスになるだけだ。そのエビデンスに対してどんな特権を与えるか（または与えないか）はシステム管理者（ポリシーの管理者）の専権事項だ。その証明書が名乗っているアセンブリの作者の信用度に応じて、強い権限を与えたり逆に権限を弱めたりすることもできるのだ。
今回のまとめ
今回はコード・アクセス・セキュリティが適用されるための第1段階である、エビデンスの収集にスポットを当てた。アセンブリの作成方法、構成ファイルによるダウンロード元の変更がエビデンスに及ぼす影響、アセンブリに証明書を付加することによるエビデンスの追加が確認できた。次回は、このようにして収集したエビデンスを元に、アセンブリにどのようにポリシーが適用されるのかを解説する。
