【誤訳訂正書】
【提出日】平成22年11月24日(2010.11.24)
【誤訳訂正１】
【訂正対象書類名】特許請求の範囲
【訂正対象項目名】全文
【訂正方法】変更
【訂正の内容】
【特許請求の範囲】
【請求項１】
関連するネットワークのサーバとピアとの間の安全なトンネルを、サーバが有するサーバ暗号鍵とピアが有するピア暗号鍵とを設定する暗号アルゴリズムを使用して構築するステップと、
前記サーバが有するサーバ認証鍵と、前記ピアが有するピア認証鍵とを設定して、前記安全なトンネルを介して、前記サーバで前記ピアを認証するステップと、
前記サーバ暗号鍵と前記サーバ認証鍵とをハッシングして、第１のハッシュを生成するステップと、
前記ピア暗号鍵と前記ピア認証鍵とをハッシングして、第２のハッシュを生成するステップと、
前記第１のハッシュと前記第２のハッシュとを比較することによって、前記ピアが前記サーバと同じ暗号鍵と認証鍵とを有していることを、前記サーバによって確認するステップと、
前記ピアが前記サーバと同じ暗号鍵と認証鍵とを有していることを確認することに応答して、前記安全なトンネルを使用して、前記サーバから前記ピアにネットワークアクセス証明書を配布するステップと、
前記配布されたネットワークアクセス証明書を使用して前記関連するネットワークで前記ピアを認証する前は、前記ネットワークアクセス証明書を配布することによって、許可不履行を前記ピアに通知して、前記配布されたネットワークアクセス証明書を使用して前記関連するネットワークで前記ピアを認証するまで、前記ピアによる前記ネットワークへのアクセスを前記サーバによって拒否するステップと、
を含む、安全な通信方法。
【請求項２】
前記少なくともサーバとピアとの間の通信は、有線と無線のうちの少なくとも一方で実行される、請求項1に記載の方法。
【請求項３】
前記暗号アルゴリズムは、非対称暗号アルゴリズムである、請求項1に記載の方法。
【請求項４】
前記非対称暗号アルゴリズムは、共有されたシークレットを抽出するために使用され、その後で、前記安全なトンネルを構築するステップで使用される、請求項3に記載の方法。
【請求項５】
前記非対称暗号アルゴリズムは、ディフィ・ヘルマン鍵交換であり、前記安全なトンネルは、ディフィ・ヘルマントンネルである、請求項3に記載の方法。
【請求項６】
前記認証するステップは、マイクロソフトMS-CHAP v2を使用して実行される、請求項１に記載の方法。
【請求項７】
前記少なくともサーバとピアの一方に公開/プライベート鍵のペアを提供し、その後その公開鍵を前記少なくともサーバとピアの残りの一方のそれぞれに提供するステップを更に有する、請求項1に記載の方法。
【請求項８】
前記公開/プライベート鍵のペアを提供するステップは、公開鍵基盤（PKI）に基づいてサーバ側の証明書を提供するステップを含む、請求項7に記載の方法。
【請求項９】
前記サーバと前記ピアとの間に前記安全なトンネルを構築することと、
前記安全なトンネルを介して、前記サーバで前記ピアを認証することと、
前記ピアが前記サーバと同じ暗号鍵と認証鍵とを有することを確認することと、
からなるグループのうちの少なくとも１つが失敗することに応答して、
前記ピアに対する安全証明書を無効にするステップ、を更に含む、請求項１に記載の方法。
【請求項１０】
前記ディフィ・ヘルマントンネルを介して、介入者攻撃を検出するステップと、
前記介入者攻撃を検出することに応答して、代わりの非対称暗号化アルゴリズムを選択するステップと、
を更に含む、請求項５に記載の方法。
【請求項１１】
前記ディフィ・ヘルマン鍵交換は、サーバで認証されるか、又は匿名であるか、の一方である、請求項５に記載の方法。
【請求項１２】
前記許可中に、前記安全なトンネルを介しての前記サーバへのアクセスを監視するステップと、
前記監視によって、攻撃がトンネルを通っていると決定するステップと、
を更に含む、請求項１に記載の方法。
【請求項１３】
関連するネットワークのサーバとピアとの間の安全な通信を可能にするシステムであって、
前記サーバと前記ピアとの間の安全なトンネルを、前記サーバが有するサーバ暗号鍵と前記ピアが有するピア暗号鍵とを設定する暗号アルゴリズムを使用して構築する手段と、
前記サーバが有するサーバ認証鍵と前記ピアが有するピア認証鍵とを用いて、暗号化によって、前記サーバで前記ピアを認証する手段と、
前記サーバ暗号鍵と前記サーバ認証鍵とをハッシングして、第１のハッシュを生成する手段と、
前記ピア暗号鍵と前記ピア認証鍵とをハッシングして、第２のハッシュを生成する手段と、
前記第１のハッシュと前記第２のハッシュとを比較することによって、前記ピアが前記サーバと同じ暗号鍵と認証鍵とを有することを、前記サーバによって確認する手段と、
前記ピアを認証することに成功して、前記ピアが同じ暗号鍵と認証鍵とを有することを前記サーバによって確認することに応答して、前記安全なトンネルを介して、前記サーバから前記ピアにネットワークアクセス証明書を配布する手段と、
前記配布されたネットワークアクセス証明書を使用して前記関連するネットワークで前記ピアを認証する前は、前記ネットワークアクセス証明書を配布することによって、許可不履行を前記ピアに通知して、前記配布されたネットワークアクセス証明書を使用して前記関連するネットワークで前記ピアを認証するまで、前記ピアによる前記ネットワークへのアクセスを前記サーバによって拒否する手段と、
を具備する、システム。
【請求項１４】
サーバとピアとの間の通信を可能とするシステムは、有線と無線とのうちの少なくとも一方を実行する、請求項１３に記載のシステム。
【請求項１５】
前記暗号アルゴリズムは、非対称暗号アルゴリズムである、請求項１３に記載のシステム。
【請求項１６】
前記非対称暗号アルゴリズムは、共有されたシークレットを抽出するために使用され、その後で、前記安全なトンネルを構築するステップで使用される、請求項１５に記載のシステム。
【請求項１７】
前記非対称暗号アルゴリズムは、ディフィ・ヘルマン鍵交換である、請求項１５に記載のシステム。
【請求項１８】
前記認証する手段は、マイクロソフトMS-CHAP v2を含む、請求項１３に記載のシステム。
【請求項１９】
前記少なくともサーバとピアとの一方に公開/プライベート鍵のペアを提供し、その後その公開鍵を前記少なくともサーバとピアとの残りの一方のそれぞれに提供する手段を更に有する、請求項１３に記載のシステム。
【請求項２０】
前記公開/プライベート鍵のペアを提供する手段は、公開鍵基盤（PKI)によりサーバ側の証明書を提供する手段を含む、請求項１９に記載のシステム。
【請求項２１】
前記許可中に、前記安全なトンネルを介しての前記サーバへのアクセスを監視する手段と、
前記監視する手段からの信号に従って、攻撃がトンネルを通っていると決定する手段と、
を更に含む、請求項１３に記載のシステム。
【誤訳訂正２】
【訂正対象書類名】明細書
【訂正対象項目名】全文
【訂正方法】変更
【訂正の内容】
【発明の詳細な説明】
【発明の名称】証明書の保護された動的プロビジョニング
【発明の背景】
【０００１】
無線通信の出現により、ユーザにプライバシを提供し且つネットワークデータの秘密性を防御するセキュリティの構築要求が増してきている。2以上の無線パーティ、即ちネットワークサーバとモバイルクライアントがセキュリティレベルの構築を望む場合、彼らが本当に誰であるかを互いに認証する“オーセンティケイト”を大体行う。一致性の証明は、“クレデンシャル（証明書）”のあるフォームによって大体なされている。これらの証明書は、産業界において異なる目的を達成するために使用される。例えば、“ユーザＩＤとパスワード”は、ユーザがバリッドであることをコンピュータに証明して、システムへのエントリを得るための証明書として機能する。同様にネットワークでは、“ユーザＩＤとパスワード”は、ネットワークへのアクセス得るためにクライアントが正しいことを証明するために使用される。また証明書は、２つのタイプの暗号規律、即ち“対象暗号法”或いは“非対称暗号法”のうちの1つによって正しさを証明するために大体使用される。
【０００２】
対象暗号法は、“予め分配されたシークレット”の使用に基づいていて、両方のパーティはある外部手段を介してシークレットを得る。即ち、両者が、“予め分配されたシークレット”を配分する配分元に頼ってもよいし、パーティの一方が、ある他の保護手段によって使用前にその“予め分配されたシークレット”を開示してもよい。例えば、予め分配されたシークレットは大体、ネットワーク管理者によりユーザに割り当てられた“ユーザＩＤとパスワード”である。そのような対象暗号法のセキュリティ強度は、“予め分配されたシークレット”の強さに依存し、そうであるから、代表的な“ユーザＩＤとパスワード”技術の使用はしばしば、パスワードに固有のセキュリティ弱点による辞書攻撃を受けやすい。
【０００３】
非対称暗号法は、“公開鍵基盤（ＰＫＩ）”のようなより新しい技術に基づいていて、ＰＫＩにより、より高度な計算負荷の負担の基で一致の証明を行うため“ゼロ知識”アプローチが可能となる。更に、対象アプローチで可能なレベルより高いレベルのセキュリティを提供する一方、公開鍵アプローチは2パーティ間で分配されたシークレットを必要としないが、証明書発行局のような第３者に頼るか、或いは公開鍵の証明価値を上げるためにあるアプリオリ知識に頼らねばならない。このようにＰＫＩ技術は非常にコストの掛かるものであり、ある無線ネットワークに搭載すると法外に高価なものとなる。更に、公開鍵アプローチはしばしば、第3者がＰＫＩ証明書を証明することを求める。
【０００４】
要約として、対象暗号化法或いは非対称暗号化法のどちらかが２つのパーティを認証するのに使用されようと、ある確立されたデータ或いは指紋が2パーティ間で共通でなければならない。対象暗号化法の場合には、予め分配されたシークレットが相互に分配され、一方非対称暗号化法の場合には、第３者が必要であって、第３者により確証が得られる前に証明書の有効性或いは指紋が各パーティに与えられる。現在の解決法では、無線或いは有線通信であろうとなかろうと、上記両方の暗号化法は、情報の形状や構築をマニュアルで行っている。対象暗号化法が使用される場合には、予め分配されたシークレットが外部ツールにより提供され、しばしば厄介な問題となる。非対称暗号化法では、信頼できる第３者により確認されるANSI X.509証明書のような証明とPKIを使用するか、或いはマニュアルにより指紋の輪郭を描いて証明書を確認するかである。このように、予め分配されたシークレット、証明書或いは指紋のような情報を保護された動的な手段により配分することが可能な解決法は現在存在していない。現在使用されているツールは、アウト・オブ・バンド(out-of band)かマニュアルにより情報の輪郭を描くことである。
【発明の概要】
【０００５】
以前のアプローチにおける困難性と欠点は、2つのパーティを認証するのに使用される情報伝達とプロビジョニングに関する本発明の方法と実行により解決される。安全なトンネルが暗号化を使用するパーティ間に構築される。証明書の配布がその後パーティ間で実行される。証明プロセスは、証明書を配布する前に適切な認証を保証するため、安全なトンネルを介してパーティ間で実行される。
【０００６】
実施に際しては、本発明はその他の異なる実施が可能であり、本発明から逸脱することなく種々の変形が可能である。したがって、図面や詳細な説明に記載された事項は例示であって、限定的なものではない。
【実施例の詳細な説明】
【０００７】
以下に説明されるように、本発明は、通信を保護するために使用される暗号化技術を使用して、サーバにより認証を行い、クライアントへの１組の証明書の配布を可能とするプロビジョニング方法を開示する。本発明は無線アプローチに特に応用可能であるが、本発明を逸脱することなく有線ネットワークへの応用も可能である。本発明の一実施例では、分配されたシークレットを相互に抽出するために第１と第2のパーティ１２、１４間で、ディフィ・ヘルマン鍵の交換が行われ、これにより保護された通信が達成される。もちろん、本発明を逸脱することなく、ディフィ・ヘルマンアプローチ以外のスキームが使用可能であることを認識されたい。分配されたシークレットは安全なトンネルを構築し、分配されたシークレットにより保護される。そして、パーティ１２、１４は、それぞれの証明書を認証することを開始して、活動している第３者の攻撃者Mと自分らが対話をしていなかったことを確かめ、自らは意図したクライアントとサーバであることを確かめる。更に、分配されたシークレットによって保護されている安全なトンネルを介して認証手順を実行することにより、パーティは、積極的な第３者の攻撃者Eが認証の交換を攻撃するという危険を冒さないことにしている。認証が成功すると、サーバはクライアントに異なる組の証明書を発行する。
【０００８】
もしもディフィ・ヘルマン鍵の交換が認証されず、またある理由により保護されている通信内部の認証手順が失敗すると、妥協的解決がパーティ１２、１４に可能である。特別なネットワークにより構築されたポリシーに依存して、いろいろな妥協的解決が可能である。あるシナリオでは、パーティ１２、１４は、認証に使用されている分配されたシークレットが妥協により解決されたと推定してよい。その際、第２パーティ１４がモバイルクライアントであり、第１パーティがサーバであると、サーバ１２はクライアント１２の証明書を無効にし、クライアント１４に対してアウト・オブ・バンドのチャネルを再構築するように求める。
【０００９】
セキュリティのほかのレベルは、クライアント１４がサーバ１２を証明できるようにすることによって得られる。この利点は、証明書を中央の証明機関からプロビジョニングすることにより得られる。中央の証明機関は、システム管理者にサーバへの公開鍵とプライベート鍵のペアを提供させ、そしてその公開鍵を全てのクライアントに提供する。このようにして、DH鍵の合意により、公開鍵の使用によるサーバの証明を有効にし、サーバによってクライアントに提供された指紋やサインを有効にする。その際、DHパラメータも提供される。そして、そのような公開鍵とプライベート鍵のペアを導入するのに余分なコストが必要ではあるが、そのような解決により、完全なPKIロールアウトの必要性を除去でき、エンドユーザに対してそのような解決による全出費を課さないでよくなる。もしもＰＫＩの使用が求められた際には、本発明のアプローチにより、全サーバの証明書の使用が可能になる点に注目すべきである。更に、本発明のアプローチによれば、配分されたシークレットの相互導出を行うがMitM攻撃に対して防御しなければならない任意の方法における鍵の交換メカニズムを可能とする。ディフィ・ヘルマン鍵の合意は、安全な鍵の合意メカニズムを可能とする例として選ばれている。ディフィ・ヘルマンへの可能なMitM攻撃を和らげるために、この実施例によれば更に、サーバ側において公開鍵とプライベート鍵のペアの使用を可能とし、サーバを証明する手段としてDHパラメータを署名することがしばしばなされる。更に、2次的な証明メカニズムでは、より弱い証明メカニズムによって証明を実行することをクライアントに可能としている。その証明には、任意のタイプの証明メカニズムが存在するが、好ましい実施例では、マイクロソフト（登録商標）のMS−CHAP v2が使用される。証明は、現在MitM攻撃に対して防御するために使用されており、アクセス制御に対する指標を提供することが意図されている。MitM攻撃に対する最後の防御は、ディフィル・ヘルマン鍵合意とMS−CHAP v2の両方からの暗号結果を結合したハッシュ値を含めさせて、両パーティ１２、１４がメッセージ交換に確実に成功することを保証することである。例えば、Mは存在しなかった。
【好ましい実施例の詳細】
【００１０】
好ましい実施例に基づき本発明を説明する。証明されたディフィ・ヘルマンプロトコル（ADHP)が、無線アプリケーションで安全なトンネルを構築する種に使用され、この安全なトンネルはディフィ・ヘルマンアプローチに限定されない。ここに開示されるADHPは、IEEE802.11基準に基づいて無線伝送に使用されている現在のプロトコルに成り代わるプロトコルの一部をなしている。ADHPは、ユーザ名とパスワード以上の入力を必要とせずに、証明書をエンドユーザに発行できるインバンドのメカニズムを提供する。
【００１１】
ADHPは、好ましくはEAP-TLSプロトコルを使用して、ディフィ・ヘルマン（DH)鍵合意に基づく交換により安全なトンネルを構築する。トンネルが2つのパーティ間に確立されると、クライアントとサーバは認証方法を実行し、両パーティは相互承認を達成する。ディフィ・ヘルマン鍵合意は、２つのDH TLS交渉の一方にトンネルを構築する話し合いにより達成される。
【００１２】
TLS_DH_anon_WITH_AES_128_CBC_SHA
において、ピアと認証サーバは、いずれのパーティの認証を確かめることなくトンネルを構築する。そして、
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
において、サーバはDHパラメータを提供する際にサインを提供する機会を与えられる。サイン付の短命なDHを使用する際には、サインはRSAの特定アルゴリズムを使用し、RAS公開鍵は、サインされた短命なDH付のクライアント交渉ADHPの前に、あるほかの独立した安全なメカニズムを介して、クライアントに適切に提供されていたことを理解してください。サーバは証明書を使用して自身の身元を十分に開示することに注意すること。トンネル構築ステップでは相互認証が達成されないので、ADHPはまた、証明書が発行される前に、相互承認を達成するためにMSCHAPv2交換を行う。
【００１３】
ADHPは、安全なチャネルがサーバから要求された際には、第1通信交換としてクライアントによってだけ、好ましくは話し合われる。クライアントが必要な証明書を持ち合わせていないと、クライアントは、サーバから証明書を動的に得るためにADHP交換を開始することを要求する。ADHP交換の成功例は以下のとおりである。
【表１】
2007511167.tif 000001
【００１４】
究極のゴールは、ピアにネットワークアクセスを可能とすることであるので、認証者とピアがEAPを話し合いながら会話が始まる。認証者は代表的にはEAP要求/アイデンティティパケットをピアに送り、ピアは、EAP応答/アイデンティティパケットで、EAPアイデンティティを有している認証者に応答する。ADHPにおいて、EAPアイデンティティはクライアントのアイデンティティを更に保護するために匿名であるかもしれない。ADHPに対して、ピアと認証サーバ間に会話が起こり、サーバはピアに唯一の証明書を発行する。
【００１５】
ピアと認証サーバ間の会話は、通常のTEAP交換として開始される。無線ピアとサーバに対する匿名のアイデンティティが、TEAP認証が起こるべきであると判断すると、EAPサーバは、TEAP/開始パケットで応答しなければならない。ピアがADHPを支持し、ピアがその装置に提供された証明書を有していないとすると、ピアはEAP-Type=ADHPで、EAP-応答パケットをおくる。更に、ピアは、ADHPのダイナミックなプロビジョニング段階を開始し、TLS クライアント・ハロー（ClientHello）においてディフィ・ヘルマンに基づく暗号の組（CipherSuite）を話し合い、ADHPの特定バージョンにおいて、RFC 3268で定義されたようにTLS_DH_anon_WITH_AES_128_CBC_SHAのTLS 暗号の組が好ましくは使用される。そして、ピアの応答は、128ビットのクライアント・ランダム値CSTAとTLS_DH_anon_WITH_AES_128_CBC_SHAの両方を含み、匿名のDH鍵合意交換が保護トンネルを確実に構築することを示している。保護トンネルは、秘密性のために128ビットのAES-CBCを使用し、メッセージの証明のためにHMAC-SHA１を使用する。
【００１６】
クライアント・ハローメッセージを受け取ると、サーバは次のように提供することによって親切に応答する。
【００１７】
サーバ・ハロー（ServerHello)記録において、
暗号の組＝TLS_DH_anon_WITH_AES_128_CBC_SHA（RFC 3268当たり）
ランダム＝ランダム値を生成した16オクテットサーバ
サーバ鍵交換(ServerKeyExchange)記録において
鍵交換アルゴリズム(KeyExchangeAlgorithm)＝diffie_hellman
サーバDHパラメータ(ServerDHParams)＝｛dh_p,dh_g,dh_Ys｝
サーバ・ハロー・ダン（ServerHelloDone)記録は、サーバ・ハローシーケンスの終わりが完璧であることを告げるのに使用される。
【００１８】
匿名の鍵交換が話し合われる場合には、記録のsha_hashは、その署名として使用される。サインされた鍵交換が話し合われている際には、サーバのプライベート鍵を使用してDHパラメータが書き込まれ、DHパラメータはサーバによって署名に与えられる。クライアントが証明書を認証することができるならば、ADHPは更に増強されて、暗号の組TLS_DHE_RSA_WITH_AES_128_CBC_SHAまたは
TLS_DH_RSA_WITH_AES_128_CBC_SHAを更に支援し、サーバはサーバ・ハロー(ServerHello)に有効なx.509証明書を提供でき、この証明書には、ピアがサーバの認証を有効にするDHパラメーターとRSAに基づく署名を含まれている、ことが、実施例において考慮されていている。最上のセキュリティを提供するために、サーバはRSA署名をパラメータ署名かまたは分離したサーバ証明書で提供して、サーバ側の認証を可能とすることが推奨される。更に、サーバは、サーバの証明書を伝送することによりサーバの全アイデンティティを提供する。必ずしも全ての装置が証明書とその有効性を処理するのに必要なインフラ構造をサポートすることができないので、証明書とサーバの公開鍵を使用すると、セキュリティとパフォーマンス間のトレードオフが生まれる。
【００１９】
ピアがサーバ・ハローメッセージからサーバ・DH・パラメータを受信すると、ピアは、master_secretとトンネル鍵を生成するのに必要な全ての情報を保持する。ピアは、挑戦者、CSTAとCAS、及びサーバとピアの公開DH鍵との両方に基づきRFC 2246によりmaster_secretを生成しなければならない。ピアは、またクライアント・鍵・交換に応答して、サーバにピアの公開DH鍵を提供しなければならず、終了（Finished)に応答して正しいmaster_secretが生成されたことを証明しなければならない。
【００２０】
ピアからクライアント・鍵・交換を受け取ると、サーバは、所定のCSTAとCAS及びサーバとピアの公開DH鍵とからmaster_secretを生成しなければならない。サーバはピアの終了概要を確かめ、自身のものを生成しなければならない。サーバは変化・暗号・スペック（ChangeCipherSpec)と終了（Finished)とに応答して、トンネル構築が成功したこと及びmaster_secretの存在とを確認しなければならない。
【００２１】
この交換が成功裏に完了すると、ピアと認証サーバ間で交換されるその後に続くメッセージが、CBCモードにおける128ビットのAESと、RFC 2246とRFC 3268の両方で定義されるHMAC-SHA1とを使用して保護される。
【００２２】
保護されるトンネルに関し、サーバがネットワークアクセス証明書を提供できる前に、ピアはサーバに対して自らを認証しなければならない。ピアの証明を促進するには、＜ユーザ名、パスワード＞証明が使用される。DH鍵合意での認証がない場合に、クライアントが介入者(man-in-the-middle)攻撃の可能性を検知できるためには、MSCHAPv2が好ましくは使用される。
【００２３】
MSCHAPv2会話に加わっているピアと認証サーバにより、クライアント認証が進められる。介入者攻撃を更に和らげるために、ピアと認証サーバにより提供される証明要求が、ADHPでのTLS構築の一部として生成され、MSCHAPv2によって要求されるサーバ・クライアント・証明要求(Server and Client Challengers)として伝達される。しかしながら、ランダムな証明要求が使用されるが、これらはMSCHAPv2メッセージの実際のADHP通信で伝達されないことに注意のこと。これらの値はゼロにされ、クライアントとサーバにより無視される。
【００２４】
MSCHAPv2認証交換の成功に続いて、サーバとクライアントは、トンネル構築とMSCHAPv2会話の両者において、両者の会話の結果得られる鍵をハッシングすることにより、保証したことを証明しなければならない。もしも両者が同じハッシング結果を計算したことを証明すると、サーバはその次にピアに対して唯一の証明書を発行できる。任意のタイプの証明書或いは１組の証明書が、このステップで発行される点に注意。証明書或いは１組の証明書を配布した結果、ADHPは許可不履行で締めくくり、証明書は発行されたが、パーティがプロビジョニングプロトコルに対して実際の認証で確認するまで、ネットワークアクセスは拒否されることを知らせる。
【００２５】
鍵を作成するに際して、DH計算が、pre_master_secretとして使用され、RFC 2246により特定されるmaster_secretに変換される。
【００２６】
pre_master_secret=(DH_Ys)peer-private-DH-keymod DH_p  クライアントに対して
pre_master_secret=(DH_Yc)server-private-DH-keymod DH_p  サーバに対して
master_secret=PRF(pre_master_secret, "master secret", ClientHello.random+ServerHello.random
TLSトンネル鍵は、MSCHAPv2交換で使用されて生成さるエクストラ３２を用いて、TLS鍵計算と同様に計算される。鍵の詳細を生成するために、以下のように計算される。
【００２７】
key_block=PRF(SecurityParameters.master_secret,
"key expansion",
SecurityParameters.server_random +
SecurityParameters.client_random);
が、十分な出力が生成されるまで計算される。そして、key_blockは以下のように分割される。
【００２８】
client_write_MAC_secret[hash_size]
server_write_MAC_secret[hash_size]
client_write_key[Key_material_length]
server_write_key[key_material_length]
client_write_IV[IV_size]
server_write_IV[IV_size]
MSCHAPv2 ServerChallenge
MSCHAPv2 ClientChallenge
余分な鍵の詳細、即ちServerChallengeとClientChallengeは、認証サーバのMSCHAPv2挑戦とピアのMSCHAPv2挑戦にそれぞれ対応している。
【００２９】
ピアの＜ユーザ名、パスワード＞を用いて認証を行うには、相互認証を実行するほかの方法が存在するが、介入者（MITM)が鮮明なテキストとしてのパスワードとクライアントの初期応答でのアイデンティティを得ることを防止するために、MSCHAPv2が選択された。MSCHAPv2は、MITMに強いて辞書攻撃を活発に開始させ、クライアントの認証応答に答えさせる。
【００３０】
MSCHAPv2交換は、サーバに強いて、応答の一部としてのサーバ証明、クライアント証明及びパスワードの関数としての有効なサーバ・証明・応答(ServerChallengeResponse)を提供させる。これにより、ADHPプロトコルの弱点の窓が減少し、サーバとして働いている介入者にクライアントの証明応答期限内にパスワードを成功裏に破壊させる。更に、証明書応答を計算するためにクライアントとサーバの両者で使用されているランダム値は、それらの値が成功したDH鍵合意に基づくものであるように、MITMから更に保護される。
【００３１】
本発明は、無線メディアにおけるアドレスセキュリティに関するものであり、その中身は、それ自体自ずと盗み聞きされ易いものである。有線メディアでは、攻撃者は有線メディアに物理的なアクセスをしなければならないが、無線メディアでは、誰でも空中を伝送される情報を捕獲でき、積極的な攻撃を可能とする。したがって、物理的なセキュリティは望むべくもなく、セキュリティの弱点は非常に大きくなる。
【００３２】
MitM攻撃は、MSCHAPv2サーバとクライアント証明とをDH鍵合意の関数として生成することにより取り扱われる。DH交換におけるMSCHAPv2証明の信用を強調する際に、MitMは、ピアと合法サーバの両方に安全なトンネルが構築されることのないようにされ、証明書を得ることに成功することを防止される。全ての方法で生成される鍵の内容を暗号的に結合することにより、ピアとASは、自分らが全ての知れ渡っている方法の単独関係者であることを保証される。
【００３３】
ピアは、プロビジョニングに対する通信を安全にする手段を特定しているので、例えば、匿名或いはサーバでの認証のような２つの方法のうちの1つにDH鍵合意を行うことができる。サーバで認証されたDH鍵合意により、サーバはつかの間のDHパラメータにRSAサインを供給しなければならず、一方サインは匿名のDH鍵合意に対して提供されない。
【００３４】
サーバで認証されたDH鍵合意において、保護されている通信は以下のことが保証される。即ち、ピアにAS公開（RSA)鍵が交渉の前に予め与えられていなければならないように、ASは真正であることを保証される。アイデンティティと（パスワード）証明書によりアイデンティティの証明を最初に行うのはクライアントであるので、相手は、辞書攻撃を成功裏に開始するために、ASとして単に振舞っておけばよい。ADHPプロトコルに従うためには、ピアへのAS公開鍵或いは核心となる証明書のプロビジョニングが、プロトコルの概念の範囲外の安全なメカニズムによって達成されなければならないことが保証されなければならない。このメカニズムによってのみ、サーバによる認証されたDH鍵合意が辞書攻撃に抵抗を与える。匿名のDH鍵合意において、相手がクライアントを演じようとしてもよいし、TEAPがプロビジョニングできるようにしてもよい。しかしながら、サーバから成功裏に証明書を得るには、DHトンネル内で成功裏に認証しなければならない。したがって、ピアの演技は、保護されたトンネル内でピアの認証を可能とすることにより軽減される。しかしながら、相手はピアのアイデンティティ及び証明書を得て演技するかもしれない。一方で相手は、プロビジョニングに対するADHPを交渉したく思っているピアとの接触に成功しなければならないが、これが起こることは可能であり、相手は辞書攻撃を開始可能となる。この理由から、ADHPの迎合的なやり方は、匿名のDH鍵合意がトンネル構築に使用される場合には、MSCHAPv2ピア認証をサポートしなければならない。
【００３５】
ASがMSCHAPv2サーバ承認応答を与えることに失敗すると、攻撃に晒されることをピアは検知しても良い。一連の失敗した企ての最大数として指定された輪郭値は、ピアにより実行されて、辞書攻撃の弱点を最小にする手段を提供する。もしも企ての最大値が同じ結果で失敗すると、ピアはMSCHAPv2証明書を変更しなければならない。ピアは、匿名のDH鍵合意よりもより良いセキュリティを提供するNACプロビジョニングに対してより安全なアウト・オブ・バンド機構を使用することを選択しても良い。同様に、ピアは、サーバの公開鍵を安全に予めプロビジョニングする手段を見つけて、サーバ認証DH鍵合意を求めても良い。匿名のDH鍵合意は、活発な辞書攻撃のリスクをより制限してそのリスクを喜んで受け入れる展開が存在するので、実行可能なオプションとして提示される。更に、匿名のDH鍵合意は、アウト・オブ・バンド・プロビジョニングを必要としない唯一のオプションである。
【００３６】
本アプローチは、サーバ側の証明という形態の公開鍵基盤（PKI)により更に能力を高められ、現在の解決法を反応的な防御から専門的な活発防御へと改善する。
【００３７】
本システムは、積極的なスキャニングに基づく辞書攻撃を受けにくく、PKIを必要としないプロビジョニングプロトコルを提供する。しかしながら、同時に、事後のMitM攻撃の可能性を検知することができるだけである。このことは、そのリスクを除去する公開/プライベート鍵を単に使用することにより克服でき、このことは、十分にスカラーであるPKIのコストに比較して、より受け入れやすいトレードオフである。同様に、最上に安全な実行がなされると、全てのサーバの証明書が最上のサーバ認証に対して使用される。
【００３８】
ここに開示したアプローチは、暗号化されていない交換の最初のフェーズを使用しているので、MitM攻撃を受けやすい鍵交換機構を攻撃者も使用するかどうかを特定するとことが可能である。したがって、認証ストリームが暗号化トンネルを通過している際に、認証サーバへのアクセスがモニタ可能であり、それによって認証フェーズをトンネルしている攻撃者を検知することが可能である。こうして、本システムの他の使用が検知可能である。
【００３９】
以上述べたように、本発明は以前のシステムに関する多くの問題点を解決する。しかしながら、本発明の特徴を説明するために説明され記述されてきた部分の詳細、内容及び配置に関して種々の変更が、本発明の原理や概念の範囲内で当業者には可能であり、本発明の範囲は特許請求の範囲に記載される。
【図面の簡単な説明】
【００４０】
【図１】図1は、開示される方法と実行の動作ステップを描いている。