証明書の保護された動的プロビジョニング
２つ以上のパーティ間で安全な通信をする方法とインプリメンテーションとを開示している。安全なトンネルは、暗号アルゴリズムを使用してパーティ間で構築される。認証プロセスは、安全なトンネルを介して行われる。証明書の配布は、その後パーティ間で実行される。
【発明の詳細な説明】
【発明の背景】
【０００１】
無線通信の出現により、ユーザにプライバシを提供し且つネットワークデータの秘密性を防御するセキュリティの構築要求が増してきている。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交換の成功例は以下のとおりである。
【表１】
【００１４】
究極のゴールは、仲間同士にネットワークアクセスを可能とすることであるので、認証者と仲間同士が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は、開示される方法と実行の動作ステップを描いている。
【発明の背景】
【０００１】
無線通信の出現により、ユーザにプライバシを提供し且つネットワークデータの秘密性を防御するセキュリティの構築要求が増してきている。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交換の成功例は以下のとおりである。
【表１】
【００１４】
究極のゴールは、仲間同士にネットワークアクセスを可能とすることであるので、認証者と仲間同士が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は、開示される方法と実行の動作ステップを描いている。
【特許請求の範囲】
【請求項１】
少なくとも第1と第2のパーティ間で通信を構築し、
前記少なくとも第1と第2のパーティ間で安全なトンネルを暗号アルゴリズムを使用して構築し、
前記少なくとも第1と第2のパーティ間で前記安全なトンネルを介して認証を行い、
前記少なくとも第1と第2のパーティ間で前記安全なトンネルを使用して安全な証明書を提供する
安全な通信方法。
【請求項２】
前記第1と第2のパーティ間の通信の構築は、少なくとも有線或いは無線での実行である、請求項1に記載の方法。
【請求項３】
前記暗号アルゴリズムは、非対称暗号アルゴリズムである、請求項1に記載の方法。
【請求項４】
前記非対称暗号アルゴリズムは、前記安全なトンネルを構築するステップでその後使用される分割されたシークレットを導出するのに使用される、請求項3に記載の方法。
【請求項５】
前記非対称暗号アルゴリズムは、ディフィ・ヘルマン鍵交換である、請求項3に記載の方法。
【請求項６】
前記認証ステップは、マイクロソフトMS-CHAP v2を使用して実行される、請求項１に記載の方法。
【請求項７】
前記少なくとも第1と第2のパーティの一方に公開/プライベート鍵対をプロビジョニングし、その後その公開鍵を前記少なくとも第1と第2のパーティの残りの1つに提供するステップを更に有する、請求項1に記載の方法。
【請求項８】
前記公開/プライベート鍵対をプロビジョニングするステップは、公開鍵基盤（PKI）によりサーバ側の証明書を提供することを含む、請求項7に記載の方法。
【請求項９】
第1と第2のパーティ間で通信を可能とするインプリメンテーションと、
前記少なくとも第1と第2のパーティ間で安全なトンネルを暗号アルゴリズムを使用して構築するインプリメンテーションと、
前記少なくとも第1と第2のパーティ間で前記安全なトンネルを介して安全な証明書を提供するインプリメンテーションと、
前記少なくとも第1と第2のパーティ間で前記安全なトンネルを介して認証を行うインプリメンテーションと、
を具備する安全な通信を可能とするインプリメンテーション。
【請求項１０】
前記第1と第2のパーティ間の通信を可能とするインプリメンテーションは、少なくとも有線或いは無線インプリメンテーションである、請求項９に記載のインプリメンテーション。
【請求項１１】
前記暗号アルゴリズムは、非対称暗号アルゴリズムである、請求項９に記載のインプリメンテーション。
【請求項１２】
前記非対称暗号アルゴリズムは、前記安全なトンネルを構築するステップでその後使用される分割されたシークレットを導出するのに使用される、請求項１１に記載のインプリメンテーション。
【請求項１３】
前記非対称暗号アルゴリズムは、ディフィ・ヘルマン鍵交換である、請求項１１に記載のインプリメンテーション。
【請求項１４】
前記認証インプリメンテーションは、マイクロソフトMS-CHAP v2を含む、請求項９に記載のインプリメンテーション。
【請求項１５】
前記少なくとも第1と第2のパーティの一方に公開/プライベート鍵対をプロビジョニングし、その後その公開鍵を前記少なくとも第1と第2のパーティの残りの1つに提供するインプリメンテーションを更に有する、請求項９に記載のインプリメンテーション。
【請求項１６】
前記公開/プライベート鍵対をプロビジョニングするインプリメンテーションは、公開鍵基盤（PKI)によりサーバ側の証明書提供するインプリメンテーションを含む、請求項１５に記載のインプリメンテーション。
【請求項１７】
安全な通信を可能とするコンピュータに読み取り可能なプログラムコードを有するコンピュータに使用可能な媒体であって、コンピュータプログラムプロダクトにおけるコンピュータ読み取り可能なプログラムコードは、
第1と第2のパーティ間の通信のためのインストラクションと、
前記少なくとも第1と第2のパーティ間で安全なトンネルを暗号アルゴリズムを使用して構築するインストラクションと、
前記少なくとも第1と第2のパーティ間で前記安全なトンネルを介して認証を行うインストラクションと、
前記少なくとも第1と第2のパーティ間で安全な証明書をプロビジョニングするインストラクションと、
を具備するコンピュータプログラムプロダクト。
【請求項１８】
前記第1と第2のパーティ間の通信のためのインストラクションは、無線インプリメンテーションのためのインストラクションを含む、請求項１７に記載のコンピュータプログラムプロダクト。
【請求項１９】
前記暗号アルゴリズムは、非対称暗号アルゴリズムである、請求項１７に記載のコンピュータプログラムプロダクト。
【請求項２０】
前記非対称暗号アルゴリズムは、前記安全なトンネルを構築するステップでその後使用される分割されたシークレットを導出するのに使用される、請求項１９に記載のコンピュータプログラムプロダクト。
【請求項２１】
前記非対称暗号アルゴリズムは、ディフィ・ヘルマン鍵交換である、請求項１９に記載のコンピュータプログラムプロダクト。
【請求項２２】
前記認証インストラクションは、マイクロソフトMS-CHAP v2を含む、請求項１７に記載のコンピュータプログラムプロダクト。
【請求項２３】
前記少なくとも第1と第2のパーティの一方に公開/プライベート鍵対をプロビジョニングし、その後その公開鍵を前記少なくとも第1と第2のパーティの残りの1つに提供するインストラクションを更に有する、請求項１７に記載のコンピュータプログラムプロダクト。
【請求項２４】
前記公開/プライベート鍵対をプロビジョニングするインストラクションは、公開鍵基盤（PKI）によりサーバ側の証明書提供するインストラクションを含む、請求項１７に記載のコンピュータプログラムプロダクト。
【請求項１】
少なくとも第1と第2のパーティ間で通信を構築し、
前記少なくとも第1と第2のパーティ間で安全なトンネルを暗号アルゴリズムを使用して構築し、
前記少なくとも第1と第2のパーティ間で前記安全なトンネルを介して認証を行い、
前記少なくとも第1と第2のパーティ間で前記安全なトンネルを使用して安全な証明書を提供する
安全な通信方法。
【請求項２】
前記第1と第2のパーティ間の通信の構築は、少なくとも有線或いは無線での実行である、請求項1に記載の方法。
【請求項３】
前記暗号アルゴリズムは、非対称暗号アルゴリズムである、請求項1に記載の方法。
【請求項４】
前記非対称暗号アルゴリズムは、前記安全なトンネルを構築するステップでその後使用される分割されたシークレットを導出するのに使用される、請求項3に記載の方法。
【請求項５】
前記非対称暗号アルゴリズムは、ディフィ・ヘルマン鍵交換である、請求項3に記載の方法。
【請求項６】
前記認証ステップは、マイクロソフトMS-CHAP v2を使用して実行される、請求項１に記載の方法。
【請求項７】
前記少なくとも第1と第2のパーティの一方に公開/プライベート鍵対をプロビジョニングし、その後その公開鍵を前記少なくとも第1と第2のパーティの残りの1つに提供するステップを更に有する、請求項1に記載の方法。
【請求項８】
前記公開/プライベート鍵対をプロビジョニングするステップは、公開鍵基盤（PKI）によりサーバ側の証明書を提供することを含む、請求項7に記載の方法。
【請求項９】
第1と第2のパーティ間で通信を可能とするインプリメンテーションと、
前記少なくとも第1と第2のパーティ間で安全なトンネルを暗号アルゴリズムを使用して構築するインプリメンテーションと、
前記少なくとも第1と第2のパーティ間で前記安全なトンネルを介して安全な証明書を提供するインプリメンテーションと、
前記少なくとも第1と第2のパーティ間で前記安全なトンネルを介して認証を行うインプリメンテーションと、
を具備する安全な通信を可能とするインプリメンテーション。
【請求項１０】
前記第1と第2のパーティ間の通信を可能とするインプリメンテーションは、少なくとも有線或いは無線インプリメンテーションである、請求項９に記載のインプリメンテーション。
【請求項１１】
前記暗号アルゴリズムは、非対称暗号アルゴリズムである、請求項９に記載のインプリメンテーション。
【請求項１２】
前記非対称暗号アルゴリズムは、前記安全なトンネルを構築するステップでその後使用される分割されたシークレットを導出するのに使用される、請求項１１に記載のインプリメンテーション。
【請求項１３】
前記非対称暗号アルゴリズムは、ディフィ・ヘルマン鍵交換である、請求項１１に記載のインプリメンテーション。
【請求項１４】
前記認証インプリメンテーションは、マイクロソフトMS-CHAP v2を含む、請求項９に記載のインプリメンテーション。
【請求項１５】
前記少なくとも第1と第2のパーティの一方に公開/プライベート鍵対をプロビジョニングし、その後その公開鍵を前記少なくとも第1と第2のパーティの残りの1つに提供するインプリメンテーションを更に有する、請求項９に記載のインプリメンテーション。
【請求項１６】
前記公開/プライベート鍵対をプロビジョニングするインプリメンテーションは、公開鍵基盤（PKI)によりサーバ側の証明書提供するインプリメンテーションを含む、請求項１５に記載のインプリメンテーション。
【請求項１７】
安全な通信を可能とするコンピュータに読み取り可能なプログラムコードを有するコンピュータに使用可能な媒体であって、コンピュータプログラムプロダクトにおけるコンピュータ読み取り可能なプログラムコードは、
第1と第2のパーティ間の通信のためのインストラクションと、
前記少なくとも第1と第2のパーティ間で安全なトンネルを暗号アルゴリズムを使用して構築するインストラクションと、
前記少なくとも第1と第2のパーティ間で前記安全なトンネルを介して認証を行うインストラクションと、
前記少なくとも第1と第2のパーティ間で安全な証明書をプロビジョニングするインストラクションと、
を具備するコンピュータプログラムプロダクト。
【請求項１８】
前記第1と第2のパーティ間の通信のためのインストラクションは、無線インプリメンテーションのためのインストラクションを含む、請求項１７に記載のコンピュータプログラムプロダクト。
【請求項１９】
前記暗号アルゴリズムは、非対称暗号アルゴリズムである、請求項１７に記載のコンピュータプログラムプロダクト。
【請求項２０】
前記非対称暗号アルゴリズムは、前記安全なトンネルを構築するステップでその後使用される分割されたシークレットを導出するのに使用される、請求項１９に記載のコンピュータプログラムプロダクト。
【請求項２１】
前記非対称暗号アルゴリズムは、ディフィ・ヘルマン鍵交換である、請求項１９に記載のコンピュータプログラムプロダクト。
【請求項２２】
前記認証インストラクションは、マイクロソフトMS-CHAP v2を含む、請求項１７に記載のコンピュータプログラムプロダクト。
【請求項２３】
前記少なくとも第1と第2のパーティの一方に公開/プライベート鍵対をプロビジョニングし、その後その公開鍵を前記少なくとも第1と第2のパーティの残りの1つに提供するインストラクションを更に有する、請求項１７に記載のコンピュータプログラムプロダクト。
【請求項２４】
前記公開/プライベート鍵対をプロビジョニングするインストラクションは、公開鍵基盤（PKI）によりサーバ側の証明書提供するインストラクションを含む、請求項１７に記載のコンピュータプログラムプロダクト。
【図１】
【公表番号】特表２００７−５１１１６７（Ｐ２００７−５１１１６７Ａ）
【公表日】平成１９年４月２６日（２００７．４．２６）
【国際特許分類】
【出願番号】特願２００６−５３９５０１（Ｐ２００６−５３９５０１）
【出願日】平成１６年１０月１２日（２００４．１０．１２）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０３３４７７
【国際公開番号】ＷＯ２００５／０４８５２４
【国際公開日】平成１７年５月２６日（２００５．５．２６）
【出願人】（３９８０３７２８４）シスコ テクノロジー インコーポレイテッド (15)
【Ｆターム（参考）】
【公表日】平成１９年４月２６日（２００７．４．２６）
【国際特許分類】
【出願日】平成１６年１０月１２日（２００４．１０．１２）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０３３４７７
【国際公開番号】ＷＯ２００５／０４８５２４
【国際公開日】平成１７年５月２６日（２００５．５．２６）
【出願人】（３９８０３７２８４）シスコ テクノロジー インコーポレイテッド (15)
【Ｆターム（参考）】
[ Back to top ]