セキュリティに関するご質問 ‐ 2003 年 2 月

  • [アーティクル]

Steve Riley, MCS Trustworthy Computing Services, Senior Consultant

トピック

ワイヤレス LAN の認証 ワイヤレス LAN の認証

ワイヤレス LAN の認証を構成する ワイヤレス LAN の認証を構成する

証明書とスマート カード 証明書とスマート カード

ワイヤレス LAN の認証

ワイヤレス ネットワークには、認証問題だけでなくデータのプライバシーや整合性に至るまで、克服すべきセキュリティ問題が数多くあります。電波は制御が難しい物理媒体であるため、意図的なデータ遮断や挿入が行われても、これを物理的に回避する方法はありません。どのような場合でも、安全なワイヤレス ネットワークを構築するには、強力な認証手段と暗号化が必要条件となります。

802.11 規格のワイヤレス ネットワークの暗号化方式として使用される、WEP (Wired Equivalent Privacy) の RC4 暗号化方式の実装には、ある欠陥1 が存在します。これは、データの一部をキャプチャし、そのデータを一般的に入手できるキー生成プログラム2 に渡すことで、攻撃者が暗号化キーを特定し、ワイヤレス ネットワークにアクセスできてしまうというものです。さまざまな標準化団体が、WEP に代わる技術の開発に取り組んでいます。しかし、現在この問題を回避するために一般的に行われているのは、キー解読に必要な量のデータが攻撃者の手に渡らないよう、暗号化キーを周期的に変更するという方法です。本来は有線 LAN のためのプロトコルである 802.1x の認証プロトコルは、この問題を回避する方法としても使用できます。

従来、ネットワーク ポートへのアクセスは、有線、ワイヤレスに関係なく MAC アクセス リストで制御されてきました。MAC ベースのアクセス制御は、大規模ネットワークには十分対応することができません。それは、新しいコンピュータの導入やネットワーク カードの交換が発生するたびに、スイッチやワイヤレス アクセス ポイントで MAC アクセス リストの更新作業が必要になるなど、管理作業の負荷が非常に高いためです。

802.1x

802.1x3 は IEEE で規定されているポート ベースのアクセス制御方式で、ネットワーク ポートへのアクセスを効率的に制御する方法が示されています。この仕様では、認証方式の選択に柔軟性があります。ワイヤレスの場合、特定の認証方式を指定するためのフレームワークである、EAP4 (拡張認証プロトコル) を使用するのが一般的です。どの方式を使用するかは、認証時に、認証要求側と認証側により決定されます。

EAP クライアント ("認証要求側") が認証側 (ワイヤレス アクセス ポイント、VPN サーバーなど) に接続すると、認証側はクライントに認証情報を要求してチャレンジを送信します。認証側はこの情報を受け取ると、その情報を認証サーバー (通常、RADIUS サーバー) に送ります。この時点では、認証要求側はまだ認証されていないため、認証要求側がこれ以上の通信を行うことはできません。認証サーバーはログオン要求を検証し、ログオン許可またはログオン拒否のメッセージを認証要求側に返します。ログオン要求が許可されると、認証サーバーは認証要求側に固有の WEP キーを生成し、そのキーをアクセス ポイント経由で認証要求側に送ります。これにより認証要求側は、認証側システムの先にある、ネットワーク内部にアクセスすることができます。

802.1x の認証では、PEAP 方式でパスワードを使用する場合でも、EAP-TLS 方式でクライアント証明書を使用する場合でも、認証サーバーに証明書が必要になります。これは、WEP のもう 1 つの脆弱性である、アクセス ポイントと認証サーバーの成り済ましの可能性を防ぐための方法です。認証サーバーが証明書を提示することで、認証要求側はその証明書の妥当性を検証し、通信先の相手が正当なアクセス ポイントまたは認証サーバーであることを確認できます。

EAP だけでは、認証情報の交換に使用する暗号化メカニズムを指定することはできません。次に説明するさまざまな EAP への拡張技術が、この問題を解決します。

Windows ドメインへのログオン

Windows ネットワークでは 2 度ログオンが発生します。コンピュータを起動するとコンピュータは、コンピュータのアカウントを使用してドメインにログオンします。コンピュータ認証を行うことで、ドメインはそのコンピュータを認証することができます。認証は、コンピュータ グループ ポリシーの適用やソフトウェア インストール設定を行ううえで必要な動作です。ログオンの最後の段階で、ユーザー ログオンのダイアログ ボックスが表示されます。ユーザーは資格情報を使用してログオンします。これにより、ユーザーがドメインに認証され、ユーザー グループ ポリシーが適用されます。

ドメインの SID、ユーザーの SID、および、ユーザーが属している全グループの SID を保持するアクセス トークンが作成され、ローカル コンピュータにキャッシュされます。このトークンは、ユーザーがリソースにアクセスするたびに提示され、リソースはこれらの SID をアクセス制御リストと照合することで、そのユーザーが認証されたユーザーであるかを判定します。このように資格情報がコンピュータにキャッシュされるのは、コンピュータとユーザーが同じドメインに属している場合のみです。コンピュータが違うドメインに属している場合やどのドメインにも属していない場合、トークンのキャッシュは行われません。ユーザーは、ドメイン リソースにアクセスするたびに、ID、パスワード、ドメインの入力を求められます。

ワイヤレス認証の必要条件

物理的なネットワークの種類 (有線/ワイヤレス) に関係なく、上記で説明した 2 段階のログオン シーケンスは必ず必要になります。コンピュータ ログオンとユーザー ログオンは同一のプロセスのため、Windows での EAP 実装は、この要件を満たすように設計されています。Windows XP では、EAP-TLS および EAP-MD5 という 2 種類の EAP を利用できます。また、Windows XP Service Pack 1 では PEAP (Protected EAP) もサポートしています。

  • EAP-TLS5 TLS (SSL) は、EAP によるデータ交換を保護するために使用される暗号化方式です。Windows の場合、TLS はコンピュータとユーザーのログオンに証明書を使用します。まず、コンピュータがコンピュータ証明書を使用して、ネットワークに対する認証を受けます。これにより、ユーザー ログオンの前に、Active Directory のコンピュータ ポリシーおよび SMS パッケージがコンピュータに適用されます。次にユーザーがログオンします。このときユーザーは、サブジェクト代替名にユーザーの Active Directory の UPN が含まれたユーザー証明書を使用して認証を受けます。この時点でワイヤレス接続の認証が完全に終了し、ユーザー ポリシーが適用されます。EAP-TLS には公開キー基盤が必要です。
  • EAP-MD5 MD5 では、チャレンジ/レスポンス方式の処理である CHAP を使用してユーザー認証を行います。MD5 には、TLS のように認証側と認証要求側間に暗号化されたセッションを確立する能力がないため、パスワード ハッシュが自由に転送されてしまいます。このため EAP-MD5 は、802.1x のワイヤレス環境での認証方式としては明示的に無効に設定します。
  • PEAP6 EAP-TLS と同様、PEAP は、EAP 内で行われる認証情報の交換を保護します。ただし、PEAP の場合、TLS を使用する必要はありません。TLS を使用することもできますが、安全な認証情報交換のメカニズムを任意に選んで使用できます。Windows では、PEAP は TLS のほかに MS-CHAPv2 もサポートしています。PEAP-MSCHAPv2 では、コンピュータの資格情報とユーザーの資格情報を使用して認証を行います。コンピュータとユーザーのパスワード ハッシュは、周期的に変更されるキーを使用して暗号化します。クライアントがサーバーを認証できるように、依然として認証サーバー (IAS) には証明書が必要になります。資格情報は MSCHAPv2 内でやりとりされるもので、サーバーがクライアントを認証するのに使用されます。コンピュータ証明書とユーザー証明書は必要なくなります。

PEAP (Protected EAP) で使用するパスワードおよび MS-CHAPv2 について

PEAP は、次の製品を組み合わせることで使用することができます。

  • クライアント Windows XP Sservice Pack 1
  • IAS (RADIUS) サーバー Windows Server 2003 (RC1 以降)

IAS サーバーは Windows 2000 のドメインに属することができます。ドメイン コントローラに Windows Server 2003 は必要ありません。

ワイヤレス クライアントが起動されると、クライアントはまず 802.11 のアソシエーションを行います。この時点でクライントは認証されていないため、そのクライアントはアクセス ポイントにブロックされ、アクセス ポイントの先にあるネットワークと通信することはできません。次に、PEAP がコンピュータ アカウントを使用してアクセス ポイントに対する認証を試みます。ログオンが有効の場合、RADIUS サーバーがクライアント固有の WEP キーを生成し、クライアントに送ります。コンピュータがドメインにログオンすると、そのコンピュータは、コンピュータ アカウントに許可されているネットワーク リソースのみにアクセスできます。次に、ユーザーがユーザーの資格情報を使用してログオンを行います。PEAP はワイヤレス アクセスが可能となるように、ユーザーの資格情報を使用して認証を行い、ログオンは完了します。ログオンが完了すると、ユーザー ポリシーが適用され、クライントは通常どおりにネットワークにアクセスできます。

コンピュータ ログオンの後、ユーザー パスワードの有効期限が切れてしまっている場合でも、PEAP はこの状況を適切に処理します。コンピュータ自体はドメインにログオンできるので、PEAP はコンピュータの認証を行い、その後ユーザーに自分のパスワードの変更を要求します。標準の LAN 接続と同じように、パスワードの変更はドメイン コントローラに伝達され、キャッシュされていた資格情報が更新されます。その結果、ユーザーはログオンすることができます。

その他の EAP ベースの 802.1x 認証方式と同じように、PEAP を使用するとワイヤレス クライアントの WEP キーをハードコード化する必要がなくなります。コンピュータとユーザーの認証を RADIUS に依存するため、PEAP は、802.1x で通常採用されている手法にならって、WEP キーを定期的に失効させます。有効期限の失効間隔は任意に構成できます。また、移動ユーザーが異なるアクセス ポイントに移った場合は、新しい WEP キーの使用を強制します。現在のところ、WEP の RC4 暗号化方式の実装に存在する欠陥を回避するには、このように定期的に WEP キーを変更する方法しかありません。

ワイヤレス アクセス ポイントでは、802.1x をサポートしていることが必要です。これは一般的な EAP のサポートのみでかまいません。アクセス ポイント (AP) は、クライントと RADIUS サーバー間のネゴシエーションに使用される特殊な EAP は認識しません。

 

ワイヤレス LAN の認証を構成する

ワイヤレス環境に PEAP ベースの認証方式を導入するには、次のような手順が必要になります。

  • Windows Server 2003 (インターネット認証サービス (IAS) を含む) のインストール
  • 各 IAS サーバーのコンピュータ証明書の入手
  • 各 IAS サーバーの Active Directory への登録
  • 各 IAS サーバーのログの構成
  • ワイヤレス アクセス ポイントを RADIUS クライントとして追加し、各アクセス ポイントを EAP 用に構成
  • ワイヤレス アクセス用にリモート アクセス ポリシーを作成
  • Windows XP クライアントを PEAP 認証用に構成

証明書

各 IAS サーバーにはコンピュータ証明書が必要になります。この証明書はクライアントが信頼する証明機関から発行されている必要があります。つまり、クライアントの、信頼されたルート証明書ストア内に、その証明機関のパブリック ルートが存在する必要があります。これを行う方法として推奨するのは、既定のドメイン ポリシーにあるコンピュータ自動登録を設定する方法です。ドメインにログオンする各コンピュータは、コンピュータ証明書を受け取ります。また、証明書 MMC スナップインを使用して、個々のコンピュータにコンピュータ証明書を登録する方法もあります。

IAS の Active Directory (AD) への登録

IAS によるユーザー アカウント データベースへの照会が可能になるよう、IAS サーバーを AD に登録する必要があります。この登録により IAS サーバーは、ドメインの既存の "RAS および IAS サーバー" セキュリティ グループに追加されます。この作業には、ドメインの管理者権限が必要になります。詳しい手順はヘルプを参照してください。

IAS ログ

認証のためのインフラストラクチャでは、ログ記録は非常に重要な要素です。IAS は、テキスト ファイルと SQL Server のデータベースにログを記録することができます。テスト段階ではテキスト ファイルにログを記録してもかまいませんが、本稼動する IAS サーバーでは、ログは SQL Server のデータベースに記録するようにしてください。詳しい手順はヘルプを参照してください。

WAP (ワイヤレス アクセス ポイント) を RADIUS クライアントとして追加

RADIUS クライアントは IAS の構成に追加しておく必要があります。各ワイヤレス アクセス ポイントについて、次の設定を行います。

  • IP アドレスを追加します。
  • [クライアント製造元] を "Microsoft" にします。
  • 正しい共有シークレットを入力します。すべての WAP で同じ共有シークレットを使用しても、それぞれの WAP で異なる共有シークレットを使用してもかまいません。
  • EAP ではメッセージ認証属性の使用が必要です。

WAP のセキュリティ構成 PEAP と連携するため、WAP は 802.1x 認証方式をサポートしている必要があります。現在 AP が LEAP と連携して動作している場合は、PEAP とも連携できます。特定の EAP 方式の選択にアクセス ポイント自体は含まれていません。AP のセキュリティ設定で、IAS サーバーの IP アドレスを入力し、EAP 認証を有効にし、RADIUS 共有シークレットを入力します。WEP キーの構成も行います。このキーは、AP がすべてのワイヤレス クライアントに対してブロードキャスト情報を送信するときのみ使用されます。AP に関連付けられている個々のワイヤレス クライアントとの通信時に使用されるものではありません。

ワイヤレスアクセスポリシーの作成

IAS のリモート アクセス ポリシーにより、ワイヤレス ユーザーはネットワークへの接続を許可されます。既定のリモート アクセス ポリシーを削除して、ワイヤレス用のポリシーを新しく作成します。

  • "NAS-port-type" が、[ワイヤレス – IEEE 802.11] と [ワイヤレス – その他] の 2 つの値に合致するポリシー条件を追加します。
  • リモート アクセス許可を与えます。

ポリシーで次のようにプロファイルを構成します。

  • すべての認証方式の選択を解除します。
  • EAP を構成します。EAP の種類は [保護された EAP]、証明書は既に入手しているコンピュータ証明書、[高速な再接続を有効にする] を有効にします。
  • [最強の暗号化 (MPPE 128 bit)] のみ許可します。
  • 属性を変更します。([詳細] タブ) [Ignore-user-dialin-properties] を追加して「True」に設定し、[Framed-protocol] を削除します。

このポリシーは、VPN や RAS アクセス用ではなく、ワイヤレス アクセス用であるため、ユーザー アカウントのダイヤルイン プロパティは無視します。

Windows XP クライアントを PEAP 用に構成

Windows XP に備わっているワイヤレス ゼロ設定により、PEAP は簡単に使用できるようになります。PEAP には、Service Pack 1 が必要です。SP1 の適用後、次の設定を行います。

  • ワイヤレス NIC のプロパティを開きます。
  • PEAP を有効にするワイヤレス ネットワークの SSID を選択します。
  • 認証方式を PEAP に変更し、高速な再接続を有効にするオプションをクリックします。
  • オプションで IAS サーバーの証明書を検証するように設定できます。これには、証明書内で発行された CRL が実際に存在し、アクセスできる必要があります。また、ログオン プロセスの速度も遅くなります。通常、証明書の検証を推奨していますが、IAS サーバーが侵害された場合、サーバーの証明書が無効にされ、IAS サーバー経由のアクセスができなくなる可能性があります。このような場合は、CRL を更新してください。

ワイヤレス クライアントは、あらかじめドメインに属していることが必要なことに注意してください。ドメインに属していないとアクセスは拒否されます。また、ワイヤレス経由でドメインに参加することはできません。あらかじめ、有線接続でクライントをドメインに参加させてください。

 

証明書とスマート カード

証明書を使用せずに安全なワイヤレス環境を実現するという差しあたってのニーズは、PEAP を導入することで満たすことができます。PEAP は、Cisco 社の LEAP プロトコルに存在する、パスワードの変更処理能力がないという問題も克服します。ユーザー側の操作に変更が必要ないという利点もあります。しかし PEAP を使用しても、パスワードにはさまざまな問題が伴います。ユーザーはパスワードを忘れたり、書き留めることもあります。また、パスワードを共有したり、パスワードの複雑さ要件のポリシーをうまく回避しようとすることもあります。パスワードは、信頼度の低い認証方法なのです。

将来、ビジネス プロセスが変更されたり新しいビジネス プロセスの導入によって、認証に、より高いレベルの信頼性が求められる可能性もあります。より高いレベルの信頼性は、証明書を使用することで確保できます。デジタル証明書は秘密キーを、高いレベルで認証された ID に結び付けます。証明書は ID とパスワードの代替物となり、Active Directory のユーザー アカウントに関連付けられます。証明書が主張する信頼性の強度は、登録プロセスで行われる認証手続き程度でしかありません。認証担当員の前に立って写真付きの身分証明書を提示することは、もちろん、非常に信頼性の高い認証手続きとなります。新入社員の手続きに証明書の発行を含めることも有効な手段です。

しかし、デジタル証明書を管理し続けることは非常に難しいことです。デジタル証明書は人間のユーザーの身元を主張できますが、デジタル証明書自体はコンピュータのハード ドライブに格納されます。そのため、ユーザーが複数のコンピュータを使用する場合、デジタル証明書をコンピュータ間で移動させるのはほとんど不可能です。この問題は、多くの PKI 導入で発生している問題です。次のような理由から、デジタル証明書をコンピュータに保存することは好ましくありません。

  • 証明書は人間の身元を主張するものです。これを人間が保持する代わりにコンピュータに格納するということは、"個人が所有権を持つ" という要素を弱めることになります。たとえば、盗まれたコンピュータには盗まれた証明書が格納されています。
  • コンピュータに保存された証明書を管理することは非常に困難です。オペレーティング システムの再インストールやアップグレードのたびに証明書のエクスポートが必要になります。
  • ユーザーが複数のコンピュータを使用する移動ユーザーの場合、コンピュータに保存された証明書を管理するのは不可能です。

この問題を論理的に解決するのが、スマート カードです。スマート カードは、コンピュータではなく人間に伴って移動します。また、スマート カードは、コンピュータ自体とは切り離して保存されます。また、そのようにすべきものです。ネットワークにログオンしたい場合ユーザーは、財布や小物入れなどからスマート カードを取り出し、スマート カード リーダーに挿入してログオンします。Windows 2000 と Windows XP では、スマート カードを使用したネットワーク アクセスを完全にサポートしています。キーと証明書がコンピュータのハード ドライブではなくカードに保存されているため、ユーザーが別のコンピュータに移動して使用することが容易になります。他のコンピュータを使用する場合、ユーザーはスマート カードを引き抜いて (これにより自動的にログオフされます)、使用するコンピュータに挿入すればログオンできます。ユーザーの資格情報がローカル コンピュータに保存されることは決してありません。

スマート カードに証明書を保存することで、より強力な認証に対する高い信頼性と、ユーザーが期待するモバイル性が同時に実現します。ただしカード自体には、検討が必要な、ある社会的な問題が含まれています。スマート カードの使用がネットワーク リソースにアクセスするための唯一の方法だとしてもカード自体に価値が蓄積されているわけではないため、スマート カードがクレジット カードや定期券と同じように大事に扱われることはありません。社員証よりも粗末に扱われることすらあります。よくユーザーが起こす間違いは、スマート カードを机の中にしまったり、ラップトップ コンピュータと同じ鞄に入れて持ち歩くことです。スマート カードを使用していないときは、ユーザーは常にカードを携帯することが必要です。これを実践させる方法の 1 つは、スマート カードとしても機能する社員証バッジを新しく導入することです。ユーザーはカードを別々に管理する必要がなくなり、社員証バッジを財布や小物入れの中に入れて持ち歩くようになります。スマート カードには価値が付加されたのです。これは実際 Microsoft が採用しているアプローチです。今後 1 年にわたり、55,000 人分のすべての社員証が、スマート カードと近接型 (非接触読み取り) バッジを統合したものに交換される予定です。

PC カード リーダーと USB リーダーの両方を使用できます。ドライバや暗号化サービス プロバイダ (CSP) を追加インストールしなくても済むように、次の 2 つのいずれかを使用してください。これらのドライバと CSP は Windows に含まれています。

  • Gemplus 社 GemSAFE
  • Schlumberger 社 Cryptoflex

スマート カードはグループ単位で導入するのが最も妥当です。たとえば、スマート カードの登録ステーションを使用して、管理者が 50 人分のユーザーのスマート カードを登録し (場合によってはアクティベーションも行う)、ユーザーにカードが準備できたことを知らせます。ユーザーは自分自身でスマート カードを受け取りに行きます。社内郵便を使用してカードを配布することは避けてください。最初のグループがリーダーを設置し、スマート カードによるアクセスが成功したら、次のグループにカードを導入します。

アクティベーションには、スマート カードに PIN を割り当てることも含まれます。管理者がカードの登録作業とアクティベーションを行う場合は、ユーザーが PIN を変更するまでユーザーの PIN を管理者が把握していることになりますが、この場合、ユーザーは VPN 認証でスマート カードを使用するのに何の作業も必要ありません。ユーザーにアクティベーションを行わせる場合、カードの受け渡しを行う場所にアクティベーション専用のコンピュータを 1 台用意し、その場所で行わせるのが一番よい方法です。ユーザーはカードをコンピュータのリーダーに挿入後、アクティベーション プログラムを開始し、自由に PIN を決めて、自分のカードに割り当てます。

カードの登録とアクティベーションに特別なカード リーダーは必要ありません。任意のスマート カード リーダーを使用できます。

スマートカードと証明書のワイヤレスネットワークへの追加 PEAP の導入では、ほとんどの場合、コンピュータとユーザーのネットワークに対する認証をパスワード ベースで行う EAP-MSCHAPv2 が使用されます。PEAP では、証明書ベースで認証を行うための仕様である EAP-TLS も使用できます。スマート カードの導入作業が終了したら、EAP-TLS を EAP の種類として、IAS の現行の PEAP アクセス ポリシーに追加します。コンピュータ証明書およびユーザー証明書が利用できる場合、PEAP は EAP-TLS とネゴシエーションを行いますが、証明書が利用できない場合は EAP-MSCHAPv2 とネゴシエーションを行います。すべてのユーザーにスマート カードを配布したら、EAP-MSCHAPv2 を EAP の種類の一覧から削除してかまいません。

必要不可欠な証明書失効リスト

スマート カードやハード ドライブに保存された証明書を使用してユーザーを認証し、RADIUS 認証プロバイダを使用すると、いくつかのステップから成るログオン シーケンスが開始されます。証明書ベースの認証の場合、クライアントによりデジタル署名が行われ、その署名がサーバーにより次の方法で検証されます。

  1. サーバーがクライアントに、署名を行うハッシュを送信します。サーバーはこのハッシュのコピーを保持します。

  2. クライアントがハッシュに署名を行います。

    1. クライアント側にある秘密キーを使用して、ハッシュを暗号化します。
    2. 暗号化したハッシュとクライアントの証明書を PKCS#7 の BLOB にバインドします。
    3. BLOB をサーバーに送信します。

  3. サーバーが署名を検証します。

    1. 証明書に含まれている公開キーを使用して、暗号化されたハッシュを解読します。

    2. 解読したハッシュと、サーバーが保持していたオリジナルのコピーと合致するか確認します。これらは合致している必要があります。

    3. 証明書が有効かどうかを確認します。

      i. サーバーが信頼している CA から発行された証明書であること (信頼されたルートまでの証明書チェーンを形成)。

      ii. 証明書が改ざんされていないかを確認します。これは、ブール演算ではなく、暗号上の演算操作で確認します。

      iii. 証明書の有効期間を確認します。

      iv. 証明書が失効していないかを確認します。AD が自動的に CRL を確認します。

  4. すべての条件を満たしていることが確認されると、ユーザーはドメインにログオンできます。

    1. Windows AD の UPN を含んでいる、証明書内のサブジェクト代替名 (SAN) を読み取ります。
    2. SAN に記載されたドメインのドメイン コントローラと通信します。
    3. 証明書の SAN と合致する UPN を持つアカウントを探します。
    4. Kerberos の資格情報を入手し、それをクライアントに提供します。

これらの通信の流れはすべて、EAP-TLS および EAP-TLS over RADIUS の仕様に従って、TLS で保護されます。RRAS と RADIUS 間では EAP-TLS は RADIUS 内にカプセル化されます。RADIUS サーバーがこれを受け取り、カプセル化解除し、上記で説明したようにログオン プロセスを行います。ログオン シーケンスが成功すると、EAP-TLS セッション中でも、RADIUS サーバーはクライントに "ACCESS-ACCEPT" を送信します。成功しなかった場合、RADIUS は "ACCESS-REJECT" を送信します。

理解しておくべき基本事項 この時点でサーバーは、署名を行ったクライアントがクライアント自身の秘密キーを使用したことを確信します。これは、証明書内にある対応する公開キーでハッシュを解読することができ、使用された DC 証明書を発行したのは CA 自身であるためです。証明書のログオン プロセスの信頼性は、CA に対する信頼性と証明書の有効性に完全に依存しています。

それでは、ユーザーのラップトップが盗まれた場合を想定してみます。そのユーザーは新しいラップトップと新しい証明書を入手しましたが、盗まれた証明書はまだ存在しています。有効性を確認するための証明書失効リスト (CRL) がなければ、その証明書によるログオンを防ぐ手段はありません。

  1. 盗まれたコンピュータには依然として秘密キーが残っており、ハッシュの署名に使用できます。
  2. 盗まれた証明書は依然として BLOB にバインドされています。
  3. DC がハッシュの解読に成功します。
  4. DC は CRL を確認しようとしますが CRL がない場合、ユーザーはログオンできてしまいます。

Active Directory は、ユーザーの証明書と秘密キーのコピーをディレクトリに保存していますが、これらは電子メール署名を検証するためのもので認証には使用できません。アカウントと証明書間の、明示的な参照またはリンクは存在しません。ユーザー自身の証明書はユーザー アカウントの "証明書マッピング" には表示されません。

信頼性が DC に依存する ID やパスワードの場合と違って、証明書を使用したログオンでは、それ自体に信頼性が存在します。その信頼性は、証明書の有効性を検証する能力の中に存在します。そのため、CRL を持つことだけがその実現方法となります。これを考慮して設計されているのが X.509 です。

このような理由から、RRAS への証明書ベースのログオンには CRL が必須となります。この詳細については、Windows 2000 のヘルプとリソース キットに記述されています。https://www.microsoft.com/windows2000/ja/server/help/sag_CS_CertRevoke.htm および https://www.microsoft.com/Windows2000/techinfo/reskit/en-us/distrib/dscj_mcs_eako.asp (英語) を参照してください。

1 「Security of the WEP Algorithm」 (英語)

http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html

2 例 : WEPCrack (英語)

http://sourceforge.net/projects/wepcrack/

3 「802.1x – Port Based Network Access Control」 (英語)

http://www.ieee802.org/1/pages/802.1x.html

4 RFC 2284、「PPP Extensible Authentication Protocol」 (英語)

http://www.ietf.org/rfc/rfc2284.txt

5 RFC 2176、「PPP EAP-TLS Authentication Protocol」 (英語)

http://www.ietf.org/rfc/rfc2176.txt

6 「Protected EAP Protocol」 (英語)

ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-josefsson-pppext-eap-tls-eap-06.txt