Windows 2000 公開キー基盤

  • [アーティクル]
トピック

はじめに はじめに
概念 概念
Windows 2000 PKI コンポーネント Windows 2000 PKI コンポーネント
認証機関 認証機関
ドメイン クライアントの有効化 ドメイン クライアントの有効化
Windows 2000 の PK セキュリティ ポリシー Windows 2000 の PK セキュリティ ポリシー
アプリケーションの概要 アプリケーションの概要
相互運用性 相互運用性
Windows 2000 PKI への準備 Windows 2000 PKI への準備
補足情報 補足情報

はじめに

Microsoft® Windows® 2000 (以下 Windows 2000) では、Windows プラットフォームに包括的な公開キー基盤が導入されました。これは、過去数年間にわたって導入されてきた Windows 公開キー (PK) 暗号化サービスを利用し、その拡充をはかるもので、PK ベースのアプリケーションを作成、展開、管理するための統合されたサービス群と管理ツールからなるものです。今回の導入により、アプリケーション開発者はそのときどきの必要に応じて、Windows NT の共有シークレット セキュリティ メカニズムと、PK ベースのセキュリティ メカニズムのいずれかを利用できます。企業にとっては、一貫性のあるツールとポリシー メカニズムに基づいて環境とアプリケーションを管理できるという利点があります。

以下では、Windows 2000 における公開キー基盤 (PKI) について概説します。

ページのトップへ ページのトップへ

概念

暗号化法は、データを保護するための技術です。暗号化アルゴリズムは、入力の平文データと暗号化キーを数学的に組み合わせ、暗号データ (暗号文) を作り出します。すぐれた暗号化アルゴリズムでは、暗号文から暗号化のプロセスを逆にたどることはできません。計算だけで平文データを導くことは不可能で、この逆算には別のデータ、いわゆる復号化キーが必要です。

従来のシークレット キー (または対称キー) による暗号化では、暗号化のためのキーと復号化のためのキーが同一で、機密データが共有されていました。シークレット キー暗号化を通信に使うときは、前もって当事者間で暗号化キーと復号化キーを安全な方法で交換しておかないと、暗号化したデータの交換ができません。

これと対照的に、PK 暗号化では、暗号化キーと復号化キーが異なります。公開キーによる暗号化は、"一方向" のみの機能です。平文を暗号文に簡単に変えられますが、ここで使われる暗号化キーは復号化には役立ちません。暗号文を平文に戻すには別に復号化キー (暗号化キーと関連はあるものの、同じではありません) があって、それを使用しなければなりません。こうして、PK 暗号化方式では、すべてのユーザーが公開キーと秘密キーという 1 対のキーを持つことになります。A 氏は公開キーを用いてデータを暗号化し、それを B 氏宛てに送信します。B 氏は自分の (B 氏だけの) 秘密キーでそのデータを解読します。同様に、B 氏が自分の秘密キーでデータを暗号化して、それを A 氏に送信すれば、A 氏は発信者が B 氏であることを確認できます。この後者の機能が、後述するデジタル署名の基本となります。

PK 暗号化方式では、公開キーと秘密キーを分離します。ここからいくつかの新技術が生まれました。そのうち最も重要なものは、デジタル署名、分散認証、公開キーを用いてのシークレット キー生成、事前のシークレット キー共有を要しないデータの一括暗号化です。

PK 暗号化アルゴリズムには、よく知られているものがいくつかあります。そのうち、RSA (Rivest-Shamir-Adleman) と ECC (楕円曲線暗号化技術) は、上記操作をすべてサポートするという意味で汎用のアルゴリズムです。機能の一部だけをサポートするアルゴリズムもあり、たとえば、連邦政府のデジタル署名標準 FIPS 186 の一部である DSA (デジタル署名アルゴリズム) はデジタル署名だけに使われ、Diffie-Hellman (D-H) はシークレット キーの生成だけに使われます。

以下では、PK 暗号化方式の主要な用途を簡単に説明します。ここでは、Bob と Alice という 2 人を例に考えます。Bob と Alice は情報を交換しますが、前もって準備されたシークレット キーを共有してはいません。

デジタル署名
公開キー暗号化で今最も活発な分野は、デジタル署名の作成と検査です。デジタル署名とは、"署名" の必要なデータを数学的変換によって秘密キーと結合し、次のようにします。

  • そのデジタル署名を作成できるのは、秘密キーの持ち主しかいない。

  • 対応する公開キーの持ち主であれば、誰でもそのデジタル署名が本物かどうかを検査できる。

  • 署名されたデータに少しでも変更があれば (大きなファイルの中の 1 ビットでも変更されていれば)、デジタル署名が無効になる。

デジタル署名はそれ自体がデータなので、"保護" 対象のデータそのものに添付し、署名入りデータとして伝送できます。たとえば、Bob が電子メール メッセージを作成し、そのメッセージ テキストに署名を添付して Alice に送信すれば、Alice はその情報に基づいてメッセージの発信元を確認できます。さらに、デジタル署名により、データが発信元から宛先に到達するまでの間、事故か意図的かを問わずいっさいの改ざんがなかったことが証明されます。したがって、デジタル署名を利用することで、きわめて信頼性の高いデータ保全メカニズムを実現できます。

認証
PK 暗号化を土台にすれば、堅牢な分散認証サービスを実現できます。エンティティ認証では、受信者の期待するエンティティとデータの送信者が一致することが保証されます。この具体的な方法としては、受信者の Alice がデータ送信者の Bob にチャレンジを送信する方法が考えられます。このチャレンジは、Bob の公開キーで暗号化されています。Bob はそのチャレンジを解読し、Alice に送り返します。Alice がチャレンジに使った公開キーに対応する秘密キーを、Bob が持っていることが証明されます。ほかにも、Alice が平文チャレンジを Bob に送信する方法もあります。Bob はそのチャレンジをほかの情報と結合し、デジタル署名を添付します。Alice は Bob の公開キーを使い、署名が本物であること、および Bob が対応する秘密キーを持っていることを確認します。チャレンジによりこのメッセージは一意なものとなり、悪意ある第三者による攻撃を阻止するのに役立ちます。いずれの方法でも、特定の秘密キーを送信者が持っていることを証明します。この手法は "所有の証明" プロトコルと呼ばれています。

公開キーを用いたシークレット キー生成
PK 暗号化の特徴の 1 つとして、安全が保証されていない公衆通信網上で、両当事者間でシークレット キーを共有できることが挙げられます。この手法は、基本的には、Bob と Alice がともに 1 つずつ乱数を生成し、それを共有シークレット キーの半分として使用します。Bob は自分の持つ半分を Alice の公開キーで暗号化して、Alice に送信します。Alice も自分の持つ半分を Bob の公開キーで暗号化して、Bob に送信します。2 人はそれぞれに相手から受信したメッセージを復号化し、相手の生成した半分を抽出して、それを自分の半分と結合し、共有シークレット キーを完成させます。このプロトコルが終了したら、その共有シークレット キーを用いて通信を行うことができます。

事前のシークレット キー共有によらないデータの一括暗号化
PK 暗号化から生まれた主要技術の 4 つ目は、大量データの一括暗号化を、事前にシークレット キーを共有することなく行えることです。既存の PK アルゴリズムは、シークレット キー アルゴリズムに比べて多量の計算を必要とします。そのため、大量のデータを暗号化する作業には不向きです。しかし、PK 技術とシークレット キー技術を組み合わせることによって、PK 暗号化の利点を活かしながら、大量のデータも効率よく暗号化できます。

まず、シークレット キーを用いるなんらかの暗号化アルゴリズムを選択し、データの暗号化に使用するランダム セッション キーを生成します。たとえば、Bob がメッセージを送信する場合には、まず Alice の公開キーを用いてこのセッション キーを暗号化し、得られた暗号文キーを、暗号化されたデータとともに Alice に送信します。Alice は自分の秘密キーでセッション キーを復号化し、そのセッション キーによってデータを復号化します。

シークレット キー暗号化では、Alice と Bob が共有シークレット キーを信頼しています。この共有シークレット キーが信頼できるのは、相互の合意があるか、または安全な方法でそのシークレット キーを交換したからです。両当事者はシークレット キーを安全に保管して、悪意ある第三者が入手できないようにしなければなりません。これに対して PK 暗号化では、Alice も Bob も自分の秘密キーを保護するだけで済みます。2 人の間で共有する情報は、相手の公開キーだけです。どちらも相手の公開キーを確実に特定できなければなりませんが、それらを安全に保管する必要はありません。PK 暗号化では、公開キーと既知のエンティティとの関連付けを信頼できることが非常に重要です。

Alice はなぜ Bob の公開キーを信頼できるのでしょうか。Bob 本人が安全な方法でAlice に直接教えた可能性もあります。しかし、それには、Alice と Bob がすでに何らかの安全な通信を行っていたことが前提になります。おそらく、安全とはいえないメカニズム (たとえば、公開ディレクトリ) で Bob の公開キーを入手した可能性のほうが高いでしょう。したがって、今手にしている "Bob" のものとされる公開キーが、確かに Bob の公開キーであることを別のメカニズムで確認できない限り、Alice は安心できません。そのようなメカニズムの 1 つに、認証機関によって発行された証明書があります。

証明書
証明書は、公開キーと特定エンティティ (その公開キーに対応する秘密キーを所有しているエンティティ) との関係を証明するメカニズムです。証明書とは、特定の公開キーに関する一種のデジタル署名入り声明文であり、発行元 (それ自身が 1 対の秘密キーと公開キーの所有者) の署名が入っています。証明書には、対象の公開キーに関連するその他の情報 (たとえば、対応する秘密キーを持つエンティティの身元情報など) も含まれるのが一般的です。つまり、証明書を発行することにより、発行元は対象の公開キーと対象身元情報の結び付きを保証しています。

今日使われている最も一般的な証明書は、ITU-T X.509 標準に則ったものです。Windows 2000 PKI でも、この標準を基本技術として採用しています。しかし、これ以外の形式の証明書もあり、たとえば、Pretty Good Privacy (PGP) セキュア電子メールは、PGP 固有の証明書形式を使用しています。

認証機関
認証機関 (CA) とは、証明書を発行するエンティティもしくはサービスのことです。発行する証明書に含まれている対象の公開キーとその身元情報の結び付きを保証する存在です。この結び付きを証明する手段は CA ごとに異なるため、特定の認証機関による公開キー証明を信頼する前に、その認証機関のポリシーと手順をよく理解しておくことが重要です。

信頼と検証
署名入りのメッセージを受信したときに Alice が直面する根本的な問題は、その署名を信頼してよいかどうかです。その署名が本物で、署名したと名乗っている人物のものかどうか、どう確かめたらよいのでしょうか。署名が本物かどうかは数学的に確認できます。つまり、既知の公開キーを使い、署名が信頼できることを検証できます。しかし、それでも、署名の検証に使った公開キーが、本当にその署名を行ったと主張している人物のものかという疑問が残ります。これを確かめなければなりません。公開キーが Bob のものであると、Alice が暗黙的に信頼できないときは、キーが確かに Bob のものであるという強力な証拠を入手しなければなりません。

Bob の公開キーについて CA が証明書を発行していて、Alice がその CA を暗黙的に信頼していれば、"Bob の公開キー" が確かに Bob のものであるということを受け入れやすくなります。つまり、次の条件を満たす証明書があれば、これは確かに Bob の公開キーであると、Alice が納得する可能性は高くなります。

  • 発行元の署名があって、暗号的に正しい。

  • "Bob" という名前と Bob の公開キーの結び付きを証明している。

  • Alice が信頼してよいと思っている発行元から発行されている。

Bob の公開キーについて、Alice の望むとおりの証明書が見つかったとしましょう。Alice は CA である "Ira" の公開キーを用いて、証明書が本物かどうかを確認できます。しかし、やはり問題が残ります。この公開キーは本当に Ira のものでしょうか。それはどう確かめればよいでしょう。Alice は Ira の身元を保証し、"Ira の公開キー" との結び付きを保証してくれる証明書を見つけなければなりません。

これを繰り返すと、証明書の連鎖が形成されます。この連鎖は、Bob と "Bob の公開キー" から始まり、一連の CA をたどって、最終的には Alice が暗黙的に信頼している誰か宛ての証明書に行き着きます。その最後の証明書は、Alice が信頼でき、納得できる公開キー/身元の結び付き階層の "ルート" であるため、信頼されたルート証明書と呼ばれます (セクション 4.1「証明書階層」を参照)。信頼されたルート証明書を明示的に信頼することは、その信頼されたルートから発行されたすべての証明書を暗黙的に信頼することになります。同時に、その信頼されたルートによって証明されている下位 CA が発行した証明書も、すべて信頼することになります。

こうして、Alice が安全な方法で取得しなければならない情報は、明示的に信頼している 1 組の "信頼されたルート証明書" だけとなります。この 1 組の証明書が Alice の信頼体系の根本であり、公開キー基盤への Alice の信頼を支えています。

ページのトップへ ページのトップへ

Windows 2000 PKI コンポーネント

図 1 に、Windows 2000 PKI を構成する最上位コンポーネントを示します。これは論理ビューであって、サーバーを物理的に分けるのではなく、実際には多くの機能を単一のサーバー システムに統合することも可能でしょう。PKI の中心的要素は Microsoft 証明書サービスで、このサービスに 1 つ以上のエンタープライズ CA を展開できます。CA はいずれも証明書の発行と失効をサポートします。CA は Active Directory に統合されるため、CA の所在情報や CA ポリシーは Active Directory から入手できます。また、証明書の失効情報も公表されます。

PKI は、Windows NT ドメイン間にすでに存在する、ドメイン コントローラ (DC) と Kerberos キー配布センター (KDC) に基づく信頼や認証のメカニズムの代わるものではありません。むしろそれらのサービスと協調して動作し、アプリケーションのスケーラビリティを向上させ、アプリケーションをエクストラネットやインターネットの要件に簡単に満たせるようにします。PKI の導入によって、特に身元特定と認証、整合性、機密性のスケーラビリティと分散性が強化されます。

2000pki1

図 1: Windows 2000 公開キー基盤のコンポーネント

PK ベースのアプリケーションの作成、展開、管理は、Windows NT が稼動するワークステーションやアプリケーション サーバーでも、Windows 95 や Windows 98 が稼動するワークステーションでも行うことができます。図 2 に、アプリケーション サーバーの概要を示します。これらのサービスで中心的役割を果たすのが Microsoft CryptoAPI です。インストール可能な暗号化サービス プロバイダ (CSP) に対しては、これが標準インターフェイスとして働きます。CSP にはソフトウェアを利用することも、暗号化ハードウェア デバイスを利用することもでき、後者の場合はハードウェアの高速性という恩恵が得られます。また、各種のアルゴリズムやキー長をサポートできます。図からわかるとおり、スマート カードをサポートするハードウェア ベースの CSP も可能です。Windows 2000 に含まれている CSP サンプルのなかには、Microsoft PC/SC 準拠のスマート カード インフラストラクチャを利用するものがいくつかあります (https://technet.microsoft.com/ja-jp/library/bb742533 と http://www.pcscworkgroup.com/ を参照)。

暗号化サービスの次のレイヤには、1 組の証明書管理サービスが存在します。このサービスは X.509 v3 証明書をサポートし、恒久ストレージ、列挙サービス、復号サポートを提供します。最後に、業界標準のメッセージ形式を扱うためのサービスがあり、主として PKCS 標準 (http://www.rsasecurity.com/japan/ を参照) と、現在策定中の IETF (Internet Engineering Task Forcehttp://www.ietf.org/) の PKIX (公開キー基盤 X.509) 草案標準をサポートします。

ほかに、CryptoAPI を利用したサービスがあり、アプリケーション開発者向けに各種機能を提供しています。たとえば、セキュア チャネル (schannel) は、業界標準の TLS プロトコルと SSL プロトコルを用いてネットワーク認証と暗号化をサポートします。プロトコルへのアクセスには、HTTP プロトコル (HTTPS) との併用なら Microsoft WinInet インターフェイス、その他のプロトコルとの併用なら SSPI インターフェイスを使用できます。AUTHENTICODE は、オブジェクトの署名と検証をサポートするサービスです。これは、主としてインターネットからダウンロードしたコンポーネントの作成元と整合性を調べるのに使われてきましたが、それ以外の用途にも使用できます。最後に、汎用スマート カード インターフェイスもサポートされています。このインターフェイスは、暗号化スマート カードをアプリケーションから独立した形で組み込むために使われ、Windows 2000 に組み込まれているスマート カード ログオン サポートを支えています。

2000pki2

図 2: 公開キー アプリケーション サービス

ページのトップへ

認証機関

Windows NT Server に含まれている Microsoft 証明書サービスは、業務で CA を必要とする企業のためのサービスです。これを使うことで、簡単に CA を設立できます。証明書サービスにはデフォルトのポリシー モジュールが含まれていますが、これはエンタプライズ エンティティ (ユーザー、マシン、サービス) 宛てに証明書を発行するのに適しています。具体的には、要求側エンティティの身元を証明し、要求された証明書の発行がドメインの PK セキュリティ ポリシーに違反しないことを確認できます。また、ポリシーの修正が拡張が容易なため、ほかのポリシー要件にも対応でき、さまざまなエクストラネットやインターネットの用途にまで CA サポートを拡大できます。証明書サービスは標準に準拠しているため、多様な環境で幅広く PK 対応アプリケーションをサポートできます。

PKI では、自社内 CA だけでなく、他社や商用サービス プロバイダなどの外部 CA も簡単にサポートできるため、企業はビジネス上の必要に応じて自由に環境を整えることができます。

Windows NT PKI では、階層的な CA モデルを念頭に置いて設計されています。階層モデルが選択された理由は、スケーラビリティ、管理のしやすさ、増加する市販のサードパーティ CA 製品との一貫性など、いくつもあります。最も単純な CA 階層は単一の CA ですが、一般的には明確に定義された親子関係を持つ複数の CA から構成されます。図 3 を参照してください。この図に示すとおり、親子関係にない複数の階層が存在することもあります。すべての CA が同じ最上位 CA (ルート) を共有している必要はありません。

このモデルでは、親 CA の発行する証明書で子が "証明" されます。この証明書で証明されるものは、ある CA の公開キーと、同 CA の身元やポリシーで定められたその他の属性との結び付きです。最上位階層の CA は、一般にルート CA と呼ばれます。下位の CA は中間 CA や発行 CA と呼ばれます。このホワイト ペーパーでは、末端エンティティを証明する CA を発行 CA、ほかの CA を証明する (ルート CA 以外の) CA を中間 CA と呼ぶことにします。

2000pki3

図 3: 認証機関の階層

このモデルの利点は、基本的に、少数のルート CA を信頼すれば証明書を検証できる一方で、発行 CA を柔軟に変更できることにあります。現実には、次に示すいくつもの理由から、複数の発行 CA を使用するほうが望ましいといえます。

  • 用途 証明書はさまざまな目的で発行されます (たとえば、電子メールのセキュリティ確保、ネットワーク認証など)。目的に応じて発行ポリシーも異なることがあり、各ポリシーを施行するうえで CA が異なっていたほうが都合がよいことがあります。

  • 組織上の区分 各エンティティが組織内で果たしている役割に応じて、証明書の発行ポリシーが異なることがあります。ポリシーごとに別個の発行 CA を設けておいたほうが、ポリシーが管理しやすくなります。

  • 地理上の区分 組織によっては、エンティティがいくつもの物理サイトに存在します。サイト間をネットワークで接続する必要上、複数の発行 CA を設けておかないと、使い勝手が悪くなることがあります。

このような CA 階層には、以下のような管理上の利点もあります。

  • CA セキュリティ環境 (キー長、物理的保護、ネットワーク攻撃に対する保護など) を柔軟に構成でき、セキュリティと使いやすさのバランスを調整できます。たとえば、ルート CA では、特殊な暗号化ハードウェアを導入し、物理的に安全な場所で稼動させたり、オフライン モードで稼動させたりできます。しかし、コストと使いやすさの点から、発行 CA ではこの方式を採用できないこともあります。

  • 発行 CA のキー/証明書は、最もねらわれやすい対象であるため、比較的頻繁に更新します。しかし、すでに確立されている信頼関係を変更する必要がありません。

  • 確立されている信頼関係を変えずに、CA 階層のある一部だけを "オフ" にできます。たとえば、ある地理的サイトと関連している発行 CA をシャットダウンし、その証明書を失効させても、組織のほかの部分にその影響が及ぶことを容易に避けられます。

CA 階層は一般に静的な性格のものですが、動的であってもかまいません。あるルート CA の下に発行 CA を追加したり、削除したりすることは、簡単にできます。さらに、既存の 2 つの CA 階層を 1 つにマージすることもできます。一方のルート CA が他方のルート CA を自分の中間 CA として証明してマージさせます。しかし、これを行うときは、マージによってポリシーの不一致が生じないかどうかを慎重に考える必要があります。また、既存の証明書に "深さ" の制約が存在する場合は、その影響も考慮しなければなりません。

Microsoft 証明書サービスの展開は、さほど複雑な作業ではありません。CA を作成する前に、ドメインを確立しておくことをお勧めします。そのあとで、エンタプライズ ルート CA (群) を作成します。証明書サービスのインストール過程では、管理者が最初から最後まで 1 つずつ作業を行っていかなければなりません。重要な作業は次のとおりです。

  • ホスト サーバーの選択 ルート CA は、DC を含むどのような Windows NT Server プラットフォーム上でも稼動できます。選択に際しては、物理的なセキュリティ要件、予想される負荷、接続要件などを考慮してください。

  • 命名 CA 名は証明書の中に書き込まれるため、変更はできません。組織の命名規則、将来の要件を考慮し、発行 CA どうしを識別できるような名前を付けます。

  • キーの生成 各 CA の公開キーのペアはインストールの過程で生成され、その CA に固有です。

  • CA 証明書 ルート CA では、インストールの過程で CA の公開/秘密キーのペアを使い、自動的に自己署名入りの CA 証明書が作成されます。子 CA では、証明要求が生成され、中間 CA またはルート CA に提出されます。

  • Active Directory 統合 CA に関係する情報は、インストール時に Active Directory 中の CA オブジェクトに書き込まれます。このため、どのような CA が存在し、どのような証明書を発行してくれるのかを、ドメイン クライアントはいつでも知ることができます。

  • 発行ポリシー エンタプライズ CA セットアップでは、CA 用に Microsoft 社から提供されるエンタプライズ ポリシー モジュールが自動的にインストールされ、構成されます。このポリシーは、権限のある管理者が修正できますが、ほとんどの場合その必要はありません。

ルート CA が確立できれば、そのルート CA の下に中間 CA や 発行 CA をインストールできます。インストール ポリシーはほぼ同じですが、唯一の違いは、証明書要求が生成されて、ルート CA または中間 CA に提出されることです。この要求は、Active Directory 経由でオンライン CA にルーティングすることも、オフライン時に手動でルーティングすることもできます。どちらの場合も、結果として発行された証明書を CA にインストールしないと、CA は認証機関としての動作を開始できません。

エンタプライズ CA と Windows NT ドメイン モデルの間には、明らかな相似関係があります。しかし、これは、CA の信頼関係とドメインの信頼関係が同じものだというわけではありません。1 つの CA が複数のドメインのエンティティに (ドメイン境界の外にあるエンティティであっても) サービスを提供したり、逆に 1 つのドメイン内に複数のエンタプライズ CA を設置することもあります。

CA は価値の高いリソースであるため、前述したように、通常は高度の保護を与えることが望ましいでしょう。たとえば、次のことを検討してください。

  • 物理的保護 CA は、企業内で高度に信頼されているエンティティなので、改ざんから十分に保護しなければなりません。保護の必要度は、CA が行う証明の価値に応じて異なります。CA サーバーを物理的に隔離し、セキュリティ管理者しか近づけない場所に設置すれば、攻撃や干渉の危険は劇的に低下します。

  • キー管理 証明プロセスへの信頼を支えるものは、CA の秘密キーです。キーは CA の最も価値ある資産といってよいでしょう。暗号化ハードウェア モジュールをインストールし、証明書サービスだけが CryptoAPI CSP 経由で秘密キーにアクセスできるようにしておけば、改ざんに強いキー管理を実現し、暗号操作をサーバー上の他ソフトウェアから切り離すことができます。当然、CA キーが破られる危険も大幅に低下します。

  • 復元 たとえばハードウェア故障などの理由で CA がダウンすると、管理上や操作上のさまざまな問題が発生するほか、既存の証明書を失効させることもできなくなります。証明書サービスは CA インスタンスのバックアップをサポートしており、障害から CA を復元できます。これは、CA 管理の全体の中で重要な部分を占めます。

これまでの説明から、Windows 2000 PKI が複数の CA 階層間の信頼関係を扱う必要があることがわかります。1 つの企業の CA 階層だけでなく、複数の企業の階層や商業ベースの CA (たとえば、Verisign、Thawte など) が関係してくる可能性もあります。

管理者は、PKI 内で Windows NT ドメイン マシン ポリシー オブジェクトに基づく CA ベースの信頼関係を構築して運用できます。信頼されるルート CA ごとに、その CA が発行する証明書に用途を制限できます。たとえば、ある CA が多くの用途に証明書を発行している場合、そのうちサーバー認証のために発行された証明書だけを有効にすることができます。

さらに、ユーザー レベルでも、各ユーザーは自分にのみ適用される CA 信頼関係を独自に追加できます。これはクライアント側から実行でき、管理者側での作業は必要ありません。

すべての信頼されるルート CA を明示的に 1 つのポリシー オブジェクトに含める代わりに、クロス証明書を使用することもできます。これは、あるベンダの PKI 製品で実際に使用されている方法で、ある 1 つの信頼されたルート CA から出発して、ほかの複数の CA に至る信頼の連鎖を形成していきます。Windows NT PKI にも、そのようなクロス証明書を処理し、それに基づいて信頼の適否を決定する機能がありますが、今取り上げているモデルではクロス証明書は扱いません。クロス証明書を選択しなかったのは、次のような理由からです。

  • 各 CA が整合しないポリシーを実施していると、組織の境界を越えるとき、クロス証明書の解釈に不確かさが発生する。

  • クロス証明書の用途について業務上の合意がないと、その解釈に問題が生じる。

  • クロス証明書の作成と維持が管理者の負担になる。

ページのトップへ

ドメイン クライアントの有効化

Windows 2000 には、相互運用可能な PK ベースのアプリケーションを開発し、展開するための包括的コア サービス群が用意されています。これらのコア サービスは、Windows NT、Windows 98、Windows 95 にもありましたが、Windows 2000 では新しい機能が追加されています。そのうち最も重要なのは、ドメイン管理とポリシー モデルとの統合です。これにより、企業内でのアプリケーション管理の煩雑さが劇的に減少しました。

以下では、PKI に用意されているコア アプリケーション サービスを取り上げて解説します。

PK 技術を使用できるかどうかは、1 つ以上の PK アルゴリズムでキーの生成や管理ができるかどうかにかかっています。Microsoft 社の CryptoAPI は、インストール可能な CSP をサポートしていて、さまざまな暗号化アルゴリズムでキーを生成し、管理できます。CryptoAPI は、キーの生成と管理のための標準インターフェイスを定義しており、このインターフェイスはすべての CSP で共通です。

キー マテリアルを保管するメカニズムは、どの CSP を選択するかで異なります。Microsoft 社が提供しているソフトウェア CSP (基本 CSP) は、ユーザーごとまたはマシンごとにキー マテリアルを暗号化して保管します。また、公開キー ペアのエクスポート管理 (CRYPT_EXPORTABLE フラグ) と用途管理 (CRYPT_USER_PROTECT フラグ) もサポートしています。前者は CSP からの秘密キーのエクスポートを管理し、後者はアプリケーションが秘密キーを使おうとしたとき、それをユーザーに通知します。ほかの CSP では異なるメカニズムを実装しています。たとえば、スマート カード CSP は、公開キーのペアをスマート カードの改ざん防止ハードウェア内に保管しており、通常は PIN コードを入力しないと、秘密キーを使用した操作を行うことができません。これらの "保護" メカニズムは透過的で、アプリケーションからは見えません。アプリケーションはすべてのキーのペアをキーセット名で参照します。キーセット名は、CSP 内では一意な名前になっています。

キーの回復
CryptoAPI アーキテクチャはキーの回復をサポートしていますが、キーの回復機能は必須ではありません。CryptoAPI では、キーの回復という場合、エンティティの秘密キーが恒久ストレージ内に保管されており、権限のある個人が所有しているエンティティに断りなく (知らせたり承諾も得ず) 秘密キーにアクセスできることを意味します。通常これは、事業上重要な通信へのアクセスを確保し、法執行機関からの要請に応えることを念頭に置いています。

キーの回復機能は、恒久データの暗号化に使用されるキーでのみ利用価値があります。PK ベースのアプリケーションでは、普通エンティティのキー交換キーが対象となります。身元特定やデジタル署名のための秘密キーをアーカイブに保存するのは、かなりの危険が伴うだけで、価値があるかは疑問です。この機能の現実的な用途としては、秘密キーの所有者になりすますことしかないためです。

現在 Microsoft Exchange では、暗号化された電子メールを読めるよう、キー交換キーの回復をサポートしています。また、サードパーティの CSP にも、キーの回復を全般的にサポートしているものがあります。ユーザーからの要求があれば、将来 Microsoft 社もキー回復機能の増強に踏み切るかもしれません。

すでに述べたとおり、実際に使用されている PK ベースの技術は、公開キーを既知のエンティティと結びつける証明書に依存しています。Windows 2000 PKI は、Microsoft エンタプライズ CA またはサードパーティ CA への証明書登録をサポートします。この登録サポートは、トランスポートから独立した形で実装され、業界標準の PKCS-10 証明書要求メッセージと、PKCS-7 応答 (この結果得られる証明書または証明書連鎖を含む) に基づいています。現時点でサポートされる証明書は、RSA キーと署名、デジタル署名アルゴリズム (DSA) キーと署名、Diffie-Hellman キーをサポートしている証明書です。

PKCS-10 メッセージと PKCS-7 メッセージへのサポートは、Microsoft 登録コントロール (Xenroll.dll) により実現されます。このコントロールを利用すると、スクリプトから呼び出して Web ベースの登録を行ったり、プログラムから呼び出してほかのトランスポート メカニズム (RPC、DCOM、電子メール) を使用できるようにします。このコントロールでは、PKCS-10 メッセージに含まれる属性をアプリケーションから指定できるほか、既存のキーのペアを使用することも、新しいキーのペアを生成することもできます。登録は非同期とみなされ、登録コントロールが状態管理を行って、発行された証明書と保留中の要求とを突き合わせます。そして、証明書、キーのペアを生成した CSP、およびキー ペア コンテナ名が内部的にリンクされます。

PKI は、Web ベース登録、登録ウィザード、ポリシーによる "自動登録" などの複数の登録方式をサポートします。自動登録方式は、ユーザーのログオン処理の一部として行われます。Microsoft 社では、IETF PKIX ワークグループの証明書要求構文 (CRS) 最新草案に基づき、自動登録プロセスを発展させる予定です。

証明書の書き換えは、概念的には登録に似ていますが、既存の証明書の信頼関係を利用する点が異なっています。書き換えでは、要求を出すエンティティが、既存の有効証明書と同じ属性を持つ新しい証明書を望み、その有効日付の延長を望んでいるとみなします。書き換えには、既存の公開キーと新規公開キーのどちらでも使用できます。

書き換えは、主として CA の利益となるプロセスです。既存の証明書の属性を再検証する必要がないぶん、書き換え要求のほうが処理効率が高いと予想できます。Windows 2000 PKI では、現在、自動登録された証明書の書き換えがサポートされています。その他のメカニズムでは、書き換えは新しい登録要求として扱われます。

証明書書き換えのための業界標準といえるメッセージ プロトコルは、今のところありません。しかし、IETF PKIX CRS 草案にはいくつかの標準が取り入れられていて、それが承認されれば、Microsoft 社も対応するメッセージ形式を実装する予定です。

Microsoft PKI では、暗号化キーと関連証明書が CryptoAPI サブシステムに保管され、管理されています。前述のとおり、キーは CSP で管理され、証明書は CryptoAPI 証明書ストアで管理されます。

証明書ストアとは、証明書と関連するプロパティを保管するデータベースのことです。PKI では、普通、5 つの標準証明書ストアを定義しています。

  • MY このストアには、関連秘密キーが取得 されるユーザーまたはマシンの証明書が保管されます。

  • CA このストアには、証明書検証連鎖の構築に使用される発行 CA 証明書または中間 CA 証明書が保管されます。

  • TRUST このストアには、証明書信頼リスト (CTL) が保管されます。CTL は、信頼される CA の集合を管理者が指定するメカニズムです。この方法の利点は、デジタル署名であるため、安全が保証されていないリンク上でも送信できることです。

  • ROOT このストアには、信頼されるルート CA の自己署名入り CA 証明書だけが保管されます。

  • UserDS このストアは、Active Directory に保管されている証明書データベース (たとえば、User オブジェクトの userCertificate プロパティ) の論理ビューです。このストアがあることで、それら外部データベースへのアクセスが簡単になります。

上記はいずれも論理ストアであり、実際には複数の物理ストア (ハードディスク、スマート カードなど) に格納されている証明書を、システム全体で一貫した形式で表示してくれます。これらのサービスを利用することでアプリケーション間における証明書の共有が実現され、管理ポリシーに基づく一貫した操作が保証されます。証明書の管理機能では、X.509 v3 証明書の復号化がサポートされます。また、特定証明書を探し出すための列挙機能も使用できます。

MY ストアには証明書プロパティが保管されており、関連秘密キーの CSP とキーセット名がわかります。したがって、アプリケーションに使用する証明書が決まりさえすれば、MY ストア情報に基づいて正しい秘密キーの CSP コンテキストを取得でき、アプリケーション開発がしやすくなります。

公開キーのペアと証明書は価値の高い資産です。これらがシステムの障害で失われると、置き換えに時間がかかり、金銭的な損失を受けます。そこで、Windows 2000 PKI では、証明書管理ツールによる証明書と関連キーのペアのバックアップと復元をサポートしています。

証明書マネージャによって証明書をエクスポートしようとするユーザーは、関連キーのペアもエクスポートするかどうかを指定しなければなりません。このオプションを選択すると、ユーザーがパスワードを入力後、証明書とキーが PKCS-12 メッセージに暗号化されエクスポートされます。このとき生成されたデータを後でインポートすれば (同じシステムでも別のシステムでも可能)、証明書とキーを復元できます。

この操作では、CSP がキーのペアをエクスポートできることが前提です。Microsoft 基本 CSP なら、キーの生成時にエクスポート可能フラグをセットしておいてください。サードパーティの CSP では、秘密キーのエクスポートはサポートされないこともあります。たとえば、スマート カード CSP は一般にエクスポートをサポートしません。キーのエクスポートをサポートしないソフトウェア CSP をバックアップするには、完全な (つまり、レジストリ情報も含む) システム イメージをバックアップをする以外の手はありません。

このホワイト ペーパーでいうローミングとは、企業の Windows NT 環境にある複数の物理マシン上で同じ PK ベース アプリケーションを使用することを指します。ローミングを実現するには、まずユーザーがどこにログオンしても、暗号化キーと証明書を使用できるようにしなければなりません。Windows 2000 PKI では、それを 2 通りの方法でサポートしています。

Microsoft 基本 CSP では、ローミング プロファイル メカニズムにより、キーと証明書のローミングがサポートされます。このサポートは透過的で、ローミング プロファイルがいったん有効になれば、ユーザーからは見えません。この機能がサードパーティの CSP でサポートされることは考えにくいでしょう。サードパーティ製品では、別の方法でキー データを保存しています (ハードウェア デバイスがよく使用されます)。

ハードウェア トークン デバイス (たとえば、スマート カード) は、物理的な証明書ストアを備えていれば、ローミングをサポートできます。Windows 2000 プラットフォームに組み込まれるスマート カード CSP は、ユーザーとあわせてハードウェア トークンを移動させることで、ローミング サポート機能を実現しています。

一般に、証明書は寿命の長い証明手段なので、いくつかの理由から、期限切れになる前に信頼性が失われる可能性も考えられます。

  • エンティティの秘密キーの改ざん、もしくは改ざんの疑い

  • 証明書の不正入手

  • 状況の変化

PK ベースの機能は、分散検証を前提としています。つまり、証明手段の安全性を保証してくれる中央の信頼できるエンティティと直接連絡をとらなくても、検証が行えることが前提条件です。証明書の検証を望んでいる個人に失効情報を配布する必要があります。

失効情報のニーズや配布するタイミングは、アプリケーションごとに異なります。Windows 2000 PKI では、できるだけ多様なケースに対応できるよう、業界標準である証明書失効リスト (CRL) のサポートを取り入れています。エンタプライズ CA は証明書の失効をサポートし、管理者の制御のもとで CRL を Active Directory に公表します。ドメイン クライアントはこの情報を取得し、ローカル キャッシュに保管しておいて、証明書の検証に役立てます。商業ベースの CA やサードパーティの証明書サーバー製品が公表する CRL も、同じメカニズムで扱えます。ただ、そのためには、公表される CRL がネットワーク経由でクライアントからアクセスできなければなりません。

PK ベースの機能を使用する場合、クライアントにとって最大の懸念事項は証明書の検証です。一般的に証明書の検証は、証明書を発行した CA への信頼に基づいて行われます。前述のとおり、PKI ではルートを起点とする CA 階層を想定し、ルート CA を信頼するかどうかの決定に基づいて信頼関係が制御されます。ある末端エンティティの証明書が、信頼されている既知のルート CA にまで "連鎖" していることが示され、しかもその証明書の用途がアプリケーションと矛盾していなければ、その証明書は有効とみなされます。この 2 つの条件のうち一方でも満たされないときは、証明書が無効とみなされます。

PKI では、各ユーザーの信頼に関する決定は、そのユーザーだけに影響します。ユーザーは信頼されるルート CA をインストール (もしくは削除) し、証明書管理ツールで用途を制限して、決定を具体化します。しかし、この方法は今後、一般的でなはく例外的なものになると考えられます。将来は、信頼関係がエンタプライズ ポリシーの一環として確立される方向に進んでいくでしょう (次の「Windows 2000 の PK セキュリティ ポリシー」を参照)。ポリシーとして確立された信頼関係は、自動的に Windows 2000 クライアント マシンにも伝えられます。

ページのトップへ

Windows 2000 の PK セキュリティ ポリシー

セキュリティ ポリシーは、サイト、ドメイン、組織単位 (OU) のどのレベルでも適用でき、ユーザーとコンピュータからなる関連セキュリティ グループを対象とします。PK セキュリティ ポリシーは、包括的 Windows NT セキュリティ ポリシーの 1 つの側面にすぎず、後者が形成する構造の中に統合されますが、集中的にポリシーを定義し、管理しながら、それをグローバルに実行します。PK セキュリティ ポリシーの持ついくつかの重要な側面について、以下で説明します。

ドメイン クライアントによる PK 証明書の検証には、信頼関係が必要です。その信頼関係を確立するには、まず、ポリシーを通じてルート CA への信頼を確定しておかなければなりません。グループ ポリシー エディタを使って、1 組の信頼される CA を設定します。マシンごとに設定すると、その設定がグローバルに (そのマシンの全ユーザーに) 適用されます。

信頼されるルート CA を設定するほか、CA の用途プロパティも設定できます。用途が指定されると、その CA が発行する証明書の用途が制約され、その用途のため発行された証明書以外は無効になります。制約の指定は、IETF PKIX 第 1 部草案に定義するオブジェクト ID (OID) に基づいて行われます。現在、次の諸項目が定義されており、これらを組み合わせて用途を制限できます。

  • サーバー認証

  • クライアント認証

  • コード署名

  • 電子メール

  • IPSec エンド システム

  • IPSec トンネル

  • IPSec ユーザー

  • タイム スタンプ

  • Microsoft 暗号化ファイル システム (EFS)

PKI と Windows 2000 の全体的統合の一環として、自動化された証明書登録プロセスをサポートするポリシー メカニズムが定義されました。この機能は、証明書の種類と自動登録オブジェクトという 2 つの中心的要素によって制御されます。いずれの要素もグループ ポリシー オブジェクトに統合されており、サイト、ドメイン、OU、マシン、ユーザーのどのレベルでも定義できます。

証明書の種類は証明書のテンプレートの役割を果たし、証明書と共通名を関連付け、管理を容易にします。このテンプレートでは、命名要件、有効期間、秘密キーの生成に使用できる CSP、アルゴリズム、証明書に組み込む拡張機能など、さまざまな要素が規定されます。証明書の種類は、論理的にはマシンの種類とユーザーの種類に分けられ、それぞれのポリシー オブジェクトに適用されます。いったん証明書の種類を定義すると、後で自動登録オブジェクトと証明書登録ウィザードで使用できるようになります。

このメカニズムは、エンタプライズ CA によるポリシーの発行に代わるものではなく、エンタプライズ CA に統合されます。CA サービスは、ポリシー オブジェクトの一部として 1 組の証明書の種類を受け取ります。エンタプライズ ポリシー モジュールはその情報に基づいて、CA が発行できる証明書の種類を規定します。許可されていない種類の証明書の発行を要求されると、CA はその要求を拒否します。

自動登録オブジェクトは、ドメイン中のエンティティに要求される証明書をポリシーとして定義するもので、マシンとユーザーのレベルで適用できます。証明書の種類オブジェクトを参照することで、証明書の種類を取り込むことができ、これは定義されているどのような種類であってもかまいません。自動登録オブジェクトには十分な情報が含まれているため、必要な証明書がエンティティにあるかどうかを見極めることができ、欠けている証明書があれば、エンタプライズ CA に登録して、それを受け取ることができます。自動登録オブジェクトは、また、証明書の書き換えについてのポリシーも定義します。管理者が証明書の期限切れの前に書き換えが行われるように設定しておけば、ユーザーが直接働きかけなくても、長期間にわたるサポートが可能です。ポリシーが更新されると (ログオン時、GPO 更新など) 、そのたびに自動登録オブジェクトが処理され、必要な処置が取られます。

スマート カード ログオンは、ユーザー オブジェクトと関連付けられているポリシーで制御されます。これは、パスワード ポリシーによる制御に似ています 。ポリシーでスマート カード ログオンを有効に設定しておけば、パスワードに基づくログオンと同時に使用できます。スマート カード ログオンを強制するよう設定すると、権限のないユーザーによるアクセスからアカウントの保護が強化されますが、スマート カードを忘れたユーザーはログオンできなくなりますし、スマート カード リーダーを持たないマシンからもログオンできません。

ページのトップへ

アプリケーションの概要

以下では、現在 PK ベースの機能を取り入れているアプリケーションのうち、重要なものをいくつか取り上げて概要を紹介します。PKI への投資を有効活用し、現実のビジネス ニーズに対応しているかを示す具体例としてお読みください。

全世界を対象に有効な情報交換ソリューションを編み出し、展開するうえで、Web が急速にその中心的要素となりつつあります。とくに、ビジネス目的での使用が劇的に増大していて、次のような場面ではセキュリティが重要な意味を持ちます。

  • サーバー認証 クライアントが通信相手のサーバーを検証できるようにします。

  • クライアント認証 サーバーがクライアントの身元を確認し、アクセス制御についての決定を下せるようにします。

  • 機密性 クライアントとサーバーの間で交わされるデータを暗号化し、データが無防備のまま公的なインターネット リンク上を伝送されないようにします。

こうしたセキュリティ ニーズに応えるうえで、Secure Sockets Layer (SSL) プロトコルと後から開発された IETF 標準、Transport Layer Security (TLS) プロトコルが重要です。SSL と TLS は柔軟性のあるセキュリティ プロトコルで、ほかのトランスポート プロトコル上で使用できます。どちらも PK ベースの認証技術に依存し、PK ベースのキー交渉によって、クライアント/サーバー セッションごとに一意の暗号化キーを生成します。一般には Web ベースのアプリケーションや HTTP プロトコルと併用されます (HTTPS と呼ばれます)。

SSL と TLS は、Windows プラットフォーム上ではセキュア チャネル (schannel) SSPI プロバイダによってサポートされます。たとえば、Microsoft 社の Internet Explorer と Internet Information Server も、schannel によってこの機能を実現しています。schannel は Microsoft SSPI アーキテクチャと統合されていて、いくつものプロトコルで使用でき、通信の認証や暗号化をサポートします。

SSL プロトコルと TLS プロトコルをフルに活用するためには、クライアントとサーバーの両方が共通の CA を信頼し、その CA が発行する ID 証明書を持っていて、相互認証できることが必要です。この条件が満たされると、データとともに証明書が交換され、対応する秘密キーの所有者であることが証明されます。これで、どちらも証明書が信頼できることを確認でき、その証明書の公開キーを用いて秘密キーの所有を検証できます。そして、証明書に含まれている ID の情報に基づいて、アクセス制御に関連する補足的判断を行います。たとえば、クライアントは、サーバーが事業上の取引にふさわしい相手かどうかを判断し、サーバーは、クライアントにどのようなデータへのアクセスを許可するかを判断します。

Windows NT PKI では、こうした補足的判断へのサポートが、Windows NT Server の標準機能として組み込まれています。ユーザー証明書を Active Directory 中のセキュリティ プリンシパル (ユーザー オブジェクト) に対して 1 対 1 または 1 対複数にマッピングできます。schannel はこの情報に基づいて自動的にクライアントのセキュリティ トークンを生成し、Windows NT の ACL メカニズムを用いて、リソースへのアクセス制御を実行できます。クライアントがどの認証メカニズム (PK または Kerberos) を用いているかに関係なく、いつも同じアクセス制御メカニズムを利用できるため、サービスにとってはメリットがあるといえます。

クライアントとサーバーの相互認証が終われば、セッション キーの交渉に進んで、安全な通信を開始できます。SSL と TLS は、クライアント認証を必要としないモードでも利用されることがあります。しかし、相互認証では Windows のアクセス制御メカニズムを活用できるため、エンタプライズ環境では相互認証を使用することお勧めします。また、PKI のもとでは証明書の登録と管理が大幅に単純化され、クライアントの負担が減ります。

PK ベースの安全な電子メール製品は、すでに数年前から広く出まわっており、Microsoft Exchange もその 1 つです。これらのシステムは、以下に PK 技術を利用しています。

  • デジタル署名 電子メール メッセージの送信元と、メッセージが本物であることを証明します。

  • 事前のシークレット キー共有によらない一括暗号化 通信者間の機密を維持します。

電子メールは分散的な性格を持っていて、ストア アンド フォワード方式で多くの受信者に伝送されます。このため、PK 技術が採用されました。これに代わる暗号化方式としてシークレット キーの共有がありますが、管理上や物理上のセキュリティ要件が厳しく、これを採用するのは困難でした。

初期の実装では、ベンダ間の相互運用性に欠けるところがありました。適切な標準がなく、各ベンダがそれぞれに独自のプロトコル、メッセージ エンコード、信頼条件を定め、それに基づくシステムを作り上げていたため、PKI 間の相互運用は実質的に不可能でした (メモ：PGP はかなり広く使われていますが、相互運用性に劣ります。PGP のメッセージ形式が業界全体で採用されることはなく、相互運用性があり、安全な電子メール アプリケーションの開発基盤にはなりませんでした)。大手ベンダにとって、相互運用性があり、安全な電子メール アプリケーションの基盤として使えるメッセージ形式が現れてきたのは、ほんの最近のことです。現在、IETF S/MIME v3 標準が提案されています。これは、RSA Data Security から提案されていた S/MIME v2 を発展させたもので、まだ草案の段階ではありますが、すでに、Microsoft Outlook Express や Microsoft Outlook 98 などの製品に実装されています。PK 暗号化と RSA アルゴリズムを使用するデジタル署名のベンダの間では、その相互運用性が既に実証済みです。

これらのシステムは、ユーザーの秘密キーを使って電子メールにデジタル署名します。受信者が署名を検証できるよう、電子メールにはユーザーの証明書が添付されます。S/MIME では、プロファイルを定義することで相互運用性を確保しているほか、階層的な CA モデルによって信頼管理のスケーラビリティを保証しています。あるユーザー宛ての電子メールを暗号化するには、まず、以前の電子メールかディレクトリ サービスから相手の暗号化証明書を入手します。この証明書の検証が済めば、そこに含まれている公開キーを使い、電子メールの暗号化に使うシークレット キーを暗号化します。

インターネットが多用されるようになり、Windows ベースのアプリケーションや ActiveXTM コントロール、Java アプレットなど、ダウンロードされるアクティブ コンテンツへの依存度が高まりました。しかし、ユーザーへの通知がないまま Web スクリプトが使用されるなど、安全への脅威という副作用が指摘され、ダウンロードの安全性への懸念が増大しました。1996 年、Microsoft 社はこの懸念を払拭すべく、AuthenticodeTM デジタル署名技術を発表しました。翌 1997 年には大幅な機能強化をはかり、Java アプレット署名と統合許可モデルも導入しました。

Authenticode のもとでは、ソフトウェア発行者がどのような形式のアクティブ コンテンツにも (たとえば、複数のファイルからなるアーカイブにも) デジタル署名を行うことができます。この署名は、ダウンロード時に行うコンテンツ発行者とコンテンツ内容の検証に使用できます。検証インフラストラクチャは階層的な CA 構造に依存しており、その階層内で少数の商用 CA がソフトウェア発行証明書を発行する形をとっているため、世界中の Windows ユーザーの数に応じて拡大できます。企業側のニーズに添うように Windows 2000 PKI により、社内の開発者/作成者宛てに Authenticode 証明書を発行して、ダウンロードしたアプリケーションの作成と信頼性をすべての従業員が検証できるようにしています。

Windows 2000 暗号化ファイル システム (EFS) は、Windows NT ファイル システム (NTFS) に格納されているファイルの透過的な暗号化と復号化をサポートします。ユーザーは暗号化したい個々のファイルを指定します。また、フォルダを指定して、その全内容を暗号化することもできます。ファイルが暗号化されていても、アプリケーションは暗号化されていないファイルと変わらず、それにアクセスできます。ただ、暗号化されている他人のファイルを解読することはできません。

EFS は PK ベースの技術を幅広く活用し、多くのユーザーにファイル暗号化メカニズムを提供するとともに、ファイルの回復もサポートします。この目的のために、EFS は事前のシークレット キー共有によらないデータの一括暗号化を重点的に使用します。実際の操作では、各 EFS ユーザーが公開キーのペアを生成し、EFS 証明書を取得します。この証明書は、Windows 2000 ドメインのエンタプライズ CA によって発行されますが、データ共有が問題にならないスタンドアロン操作の場合は、EFS が自己署名入りの証明書を発行します。また、EFS が回復ポリシーの中で、信頼できる回復エージェントを指定すれば、Windows 2000 はその回復ポリシーもサポートします。回復エージェントの働きは、EFS 回復公開キーのペアを生成することであり、エンタプライズ CA から EFS 回復証明書の発行を受けます。EFS 回復エージェントの証明書は、グループ ポリシー オブジェクトを通じてドメイン クライアントに公表されます。

実際の操作では、暗号化すべきファイルごとに EFS がランダム キーを作成し、そのキーによってファイルが暗号化されます。次に、ユーザーの EFS 公開キーによってこの "シークレット" キーが暗号化され、ファイルと関連付けられます。また、シークレット キーのコピーが各回復エージェントの EFS 公開キーで暗号化され、ファイルと関連付けられます。シークレット キーの平文コピーがシステム内に保管されることはありません。

ファイルを取り出すときは、まず、ユーザーの公開キーで暗号化されているシークレット キーを EFS がユーザーの秘密キーで復号化します。この復号化は透過的に行われます。こうして得られたシークレット キーは、ファイルの読み書き操作で、ファイル復号化のためにリアルタイムで使用されます。同様に、回復エージェントも秘密キーでシークレット キーにアクセスし、ファイルを復号化できます。

Windows 2000 では、パスワードによるドメイン認証の代わりに、PK ベースのスマート カード ログオンを使用できます。この方法には、PC/SC Workgroup 準拠のスマート カード インフラストラクチャ (1997 年 12 月に Windows NT と Windows 95 に初めて導入されました) と、RSA 対応のスマート カードおよびそれをサポートする CryptoAPI CSP が必要です。認証プロセスでは、IETF Kerberos ワークグループが提案している PKINIT プロトコルを使用して、PK ベースの認証を Windows 2000 Kerberos アクセス制御システムと統合しています。

実際の操作では、標準の CTRL + ALT + DEL セキュア アテンション シーケンスでログオンを開始する代わりに、システムによりスマート カード挿入イベントが認識されます。そしてユーザーにプロンプトを表示し、スマート カード PIN コードを要求します。PIN コードにより、スマート カードに格納されている秘密キーへのアクセスが制御されます。このシステムでは、ユーザーの証明書 (エンタプライズ CA が発行) のコピーもスマート カードに含まれているため、ドメイン内でのユーザーのローミングが実現されます。

IPSec は、ネットワーク暗号化のプロトコルを IP プロトコル レイヤに定義します。そこでは PK ベースの技術が必要とされず、暗号化にはネットワーク エンド ポイント間で共有されるシークレット キーを使用します。共有されるシークレット キーのやりとりは、帯域外のメカニズムを通じて安全に行われます。しかし、PK ベースの技術にスケーラブルな分散信頼アーキテクチャを構築する能力があり、そこから現実的ソリューションが生み出されることは、IETF IPSec ワークグループも認識しています。現在、IPSec デバイスどうしが相互認証を行い、前もってシークレット キーを共有しておかなくても暗号化キーに合意できる方法がないか、模索が続いています。

IPSec コミュニティ (Microsoft 社も参画) は、現在、相互運用可能な証明書と証明書登録や管理用プロトコルの標準策定に熱心に取り組んでいます。ある程度の相互運用性はすでに実現されていますが、IPSec デバイスと各種 PKI 実装のすべてを包含する幅広い相互運用性を実現するには、まだ多くの作業が残っています。Microsoft 社は、発展しつつあるこの標準に合わせ、Windows 2000 PKI を発展させていこうと考えています。

ページのトップへ

相互運用性

理想的には、PKI は文字どおりインフラストラクチャです。CA は、標準の証明書要求プロトコルに基づいて、完全に相互運用可能な証明書を発行し、PKI に依存するすべてのアプリケーションは、一貫した方法でその証明書を検証 (失効しているかどうかの検証も含む) します。このプロセスのどこにも、シンタックス上、セマンティクス上の曖昧さはありません。

しかし現実では、まだそのレベルの相互運用性には達していません。当面の問題は、すべてが "とにかく動いてくれる" ことを期待できるかどうか、です。PK ベースの技術を使用するアプリケーションが増えてくれば、比較的シームレスな相互運用性を実現できるでしょう。今日、いくつかのベンダの製品間では、SSL/TLS と S/MIME が問題なく協調してして動作します。問題があるのは、コード署名やデジタル署名フォームなど、使用頻度がさほど高くない新しいアプリケーションです。また、現在、異なる言語コード間で名前を比較するメカニズムがないことも懸念されます。しかも、この解決には困難が予想されます。たとえば、Unicode には、アクセント記号付の文字コードがいく通りも存在します。

長い目で見ると、この種の問題は、PK ベースの技術が比較的未熟なことに起因しています。将来的には、少なくとも 2 つの大きな力が働いて、相互運用性を前進させていくと考えられます。

  • 初期試行と、それに続く PK ベース システムへの依存度の高まり

  • 標準を求めていく流れ

Microsoft 社は PK 関連標準の開発に積極的に取り組み、自社 PKI の相互運用性を最大限高めるべく、事実上かつ成文上の標準に基づく製品作りに励んでいます。

インターネット標準は、相互運用性への助けにはなっても、それを保証するものではありません。歴史的に見た標準化の問題点は、商業製品の展開のペースがいつも共同研究の進展の先を行っていることです。とくに、PK 技術の進歩では、その傾向が顕著です。現在、IETF のいくつかのワークグループが PK ベースの技術を扱い、提案された標準の開発に取り組んでいます。しかし、それらの標準から恩恵を受けるはずのアプリケーションは、すでに製品として数多く出荷されています。さらに、どのような標準も、あらゆるアプリケーション要件やその付属要件を満たすことはできません。最も包括的な標準でさえ、実装に当たっては多少の逸脱が避けられません。この観点からすれば、相互運用性とは、標準が市場の現実で鍛えられた結果として生まれるものといえるでしょう。

相互運用可能な PKI の基礎作りを担当している IETF ワークグループは、PKIX (X.509) です。ほぼ 3 年間にわたる作業のすえ、基本アーキテクチャができあがりました。その仕様である "Internet Public Key Infrastructure X.509 Certificate and CRL Profile, Part 1" (インターネット公開キー基盤 X.509 証明書および CRL プロファイル、第 1 部。http://www.ietf.org/ids.by.wg/pkix.html を参照) が、今後の標準になっていくと思われます。Microsoft 社は IETF 内でもこの標準策定に深くかかわってきており、自社の PKI をそれに準拠したものにしていくことを表明しています。この仕様が承認されれば、堅牢な PKI 形成への重要な一歩となり、証明書の要求、解釈、失効になんらかの統一的方法が見いだされていくことになるでしょう。

IETF 内には、ほかにも、PKI の相互運用性に大きな影響を及ぼすと見られるいくつかの動きがあります。いずれも、PK ベースのアプリケーション、とくに TLS、S/MIME、IPSec からの要請を受けての動きです。どのアプリケーションでも、それぞれのニーズを満たす PKIX サブセット、もしくは PKIX で定義されている機能のスーパーセットを定義する必要性が認識されています。こうした動きは標準化を阻害するもののように映るかもしれませんが、実際は、PKI 設計者への貴重なフィードバックとなっています。

アプリケーション依存標準として最も攻撃的な案を打ち出しているのが IETF S/MIME ワークグループであることは、ある意味で当然です (http://www.ietf.org/ids.by.wg/smime.html)。ここが提案している標準のうち最も重要なものは、(S/MIME) "Cryptographic Message Syntax" (暗号化メッセージ構文) 、"S/MIME Version 3 Message Specification" (S/MIME v3 メッセージ仕様) 、"S/MIME Version 3 Certificate Handling," (S/MIME v3 証明書の取り扱い) 、"Certificate Request Syntax" (証明書要求構文) です。S/MIME コミュニティは、それ以前の TLS コミュニティ同様、事実上の標準から出発したという優位性を持っています。PKIX も標準 (X.509) から出発したといえないこともありませんが、その標準は相互運用可能な PK ベース システムの基礎としては不十分であることが証明済みでした。要するに、IETF 標準の土台である PKIX 第 1 部は、今、それを使おうとしているアプリケーションから "経験" を学びつつある段階です。最近のフィードバック例に、証明書連鎖の検証があります。

PKIX 第 1 部は、証明書連鎖の検証アルゴリズムを提案していますが、その仕様を定めてはいません。現行インターネット草案はいく通りかの解釈が可能です。1 つは、たとえ AuthorityKeyIdentifier (発行者の公開キー) などの情報があっても、名前連鎖 (証明書の発行者名と親証明書の該当フィールドにある CA 名との突き合わせ) を強制するという解釈です。この解釈には、2 つの重要な公開キー環境を受け入れられないという、本質的な問題があります。1 つは、ディレクトリが存在せず、名前では CA 証明書を探し当てられない環境、もう 1 つは、相互に証明し合う CA が入り組んだ網の目を構成している複雑な環境です。PKIX ワークグループはこの種の問題に気づかず、アプリケーションが連鎖検証アルゴリズムを一般化する過程で、初めて一般化が不可能であるという問題が浮上しました。しかし、肯定的な見方をすれば、フィードバック ループが機能しているということであり、問題を反映して新しいメカニズムが標準に取り込まれるということでもあります。

PKI の相互運用性を促す重要な "力" が、もう 1 つ登場しました。それは、米国連邦情報技術局 (NIST) が相互運用性のワークグループを発足させたことです。メンバーには、AT&T、CertCo、Certicom、Cylink、Digital Signature Trust、Dynacorp、Entrust、Frontier Technologies、GTE、ID Certify、MasterCard、Microsoft、Motorola、Spyrus、VeriSign、Visa が加わっています。このプロジェクトの目標は、各メンバーが実装する PKIX 第 1 部の間に最小限の相互運用性を実現することです。新しい PKIX 標準に曖昧さや誤りがあっても、このワークグループの活動のなかで洗い出され、解決されるだろうと、NIST は楽観的な見通しを持っています。

PKI 標準を定義する際には、IETF の外部に存在する条件も無視できません。たとえば、RSA Laboratories が開発し、すでに製品として広く展開されている事実上の暗号化メッセージ標準 ("PKCS") があります (http://www.rsa.com/rsalabs/node.asp?id=2124)。PKCS 標準は、1990 年に初めて発表されたもので、暗号化メッセージ構文を含んでいます。PKCS のうち PKI と最も関連が深い標準は、PKCS-7 "Cryptographic Message Syntax Standard," (暗号化メッセージ構文標準) と PKCS-10 "Certification Request Syntax Standard" (証明要求構文標準) です。RSA 標準の重要性は、基本的ながら、よく理解の行き届いた相互運用性の枠組みを提供していることにあります。実際に、PKIX ワークグループが新しい証明書管理標準を提案したのに対し、S/MIME ワークグループは PKCS に基づく独自提案を作成しているほどです。こうした食い違いは IETF には珍しいことではなく、市場認識をよく反映していることの結果ともいえます。一般に、事実上の標準こそ最上の標準であることが多く、Microsoft 社も現在の PKI 実装にはそれを取り入れて、最大限の相互運用性を実現しています。

今後どのような発展があるにせよ、標準が出発点となることは間違いないでしょうが、最終的には、いくつものベンダがなんらかのサブセットを自社製品に採用することで、相互運用可能なソリューションが形成されていくことになるでしょう。PK 相互運用性の決定に市場の力が果たす役割の大きさは、信頼モデルのしくみを見てもわかります。

インフラストラクチャという言葉は、PKI 自体の相互連結を想像させます。たとえば、ある企業の 1 部門がベンダ A の PKI モデルを部門アプリケーションに採用したところ、後になって会社本体がメール システムにベンダ B を採用したとします。ある程度、重なり合う部分があるだろうとは予想できます。しかし、会社 A と会社 B がビジネス本位のエクストラネットでそれぞれの PKI を選択的に結合させようとすると、状況はやや複雑になります。エンティティ間の信頼関係 (誰が誰を何について信頼するか) をマッピングし、長期的にその関係を追跡することが技術的に複雑だからです。現時点では、3 通りの信頼関係モデルが競合しています。

  • ルートを持つ階層 (たとえば、VeriSign、Microsoft、Netscape)

  • ネットワーク (たとえば、Entrust)

  • Web (たとえば、PGP)

この 3 通りの信頼モデルを 1 つのコンテキストの中で捕らえ直してみると、信頼関係をどう確立し、どう維持していくかについて、それぞれが異なる想定に立っていることがわかります。最終的には、信頼関係を直接作成するか、(仲介者を通しての) 間接的に作成するかの違いに帰着しますが、どの技術モデルやビジネス モデルの背後にも、PKI がどうあるべきかについての強い信念がうかがわれます。このような基本的な問題では、全員が単一の標準に賛成するとは思えず、結果として、さまざまな信頼モデルが並立し、相互運用は決してシームレスなものにはならないでしょう。望みうることは、どの PKI にも十分な柔軟性を持たせることかもしれません。そこに相互運用をサポートする管理ツールを添え、具体的なビジネス上の目的に限定して信頼モデル間の統合をはかれるようにすることではないでしょうか。

ページのトップへ

Windows 2000 PKI への準備

公開キー基盤に基づくセキュリティは、比較的新しい考え方です。世界的に見ても、PKI の展開の実例や研究事例はあまりありません。企業が PKI の大規模な展開に踏み切るためには、事前にユーザーを教育し、キー/証明書管理の問題を理解し、PKI に伴う危険と障害を理解しておかなければなりません。これらの問題での手助けを業務としている会社が、いくつか存在します。

PKI セキュリティを有効に使用できるアプリケーション分野は多いでしょう。電子メールもそうした分野の 1 つです。PKI に基づく S/MIME を使用すれば、デジタル署名し、暗号化した電子メールを送信できます。企業は、まず S/MIME ベースの電子メールを入り口として PKI 展開を開始し、経験と知識を積み重ねていくのがよいかもしれません。

Microsoft 社では、PKI の展開を考慮している顧客に、まず Microsoft Exchange Server 5.5 (SP1) と Microsoft Outlook 98 を導入するよう推奨しています。これらを導入すると S/MIME ベースの電子メールが使えます。Exchange および Outlook に組み込まれている PKI 機能は、次のとおりです。

  • キー管理サーバー (キー回復機能を組み込み済み)

  • X.509v3 証明書サーバー

  • LDAP ベースの Exchange ディレクトリ サービス

  • CryptoAPI を使用する S/MIME クライアント (Outlook)

Microsoft Exchange Server 5.5 と Microsoft Outlook なら、安全な電子メールとキー回復機能を実現できるほか、複数のキー管理サーバーと、証明書の信頼階層も実現できます。

Microsoft 社では、Exchange ユーザーのために、Windows 2000 Server で提供される PKI インフラストラクチャへの移行パスを用意しています。この PKI インフラストラクチャは従来より一般的な性格を持ち、共通エンタプライズ ディレクトリ サービス (Active Directory) と、共通エンタプライズ認証機関を含んでいます。将来のリリースでは、キー管理サーバーがいっそう汎用的なシステム機能になり、ほかのアプリケーションから利用しやすくなる予定です。

ページのトップへ

補足情報

Windows NT Server の最新情報は、Microsoft TechNet か、World Wide Web サイト https://www.microsoft.com/japan/products/ntserver/ を参照してください。

© 1999 Microsoft Corporation. All right reserved.

本書に記載されている情報は、発行時点で議論されている問題点に関する Microsoft Corporation の最新の見解を示しています。Microsoft は変化する市場状況に対処しなければならないため、本書の内容を Microsoft の確約事項として解釈してはならず、Microsoft は発行日以降に提示された情報の精度についてはいかなるものであれ保証致しません。

本書は、情報の通知のみを目的としており、Microsoft は本書に記載されている情報について明示的にも暗黙的にも一切の保証を致しません。

Microsoft、Active Directory、BackOffice、Windows、Windows NT は米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。

その他、記載されている会社名および製品名は、各社の商標および登録商標です。

Microsoft Corporation. One Microsoft Way. Redmond, WA 98052-6399 USA

ページのトップへ