JP2013509089A - 低レイテンシーのピア・セッション確立 - Google Patents

Abstract

ソース・デバイスおよびターゲット・デバイスが安全な通信セッションを形成しようとしても、これによって、インターネットのような信頼性のないネットワークを通じて、暗号化されたメッセージを送信する場合がある。しかしながら、通信セッションの確立における多くのメッセージの交換は、特に、多くの通信セッション（例えば、ピア・ツー・ピア通信セッション）を特徴とするシナリオでは、かなりのレイテンシーや計算リソースを要する可能性がある。ソース・デバイスからターゲット・デバイスに送信されるメッセージの２回の交換のみで、または１つのメッセージだけでも通信セッションの開始を可能にするような、通信セッション開始技法を考案することができる。これらの技法の実施形態の中には、通信セッションの開始において必要とされるメッセージの数を増やすことなく、中間者攻撃を検出するための公開証明書による認証や、反射攻撃を検出するためのノンスの包含というような、有利なセキュリティー機構を含めることができるものもある。
【選択図】図４

Description

[0001] 多くのコンピューター使用のシナリオでは、互いにアクセス可能な２つ以上のデバイスが（例えば、有線またはワイヤレス・ネットワークを通じて）通信セッションを確立しようとすることがある。この通信セッションは、機密情報の傍受または漏洩を防止するために暗号化されており、および／または各デバイスが、受信したメッセージが他のデバイスによって発生されたことを検証できるように、通信セッションを認証する。例えば、ＲＳＡアルゴリズムのような、非対称暗号鍵交換アルゴリズムを実装すると、セッションに対する公開鍵を交換することを２つのデバイスに可能にすることができる。公開鍵は、対応する秘密鍵と合わせて用いられ（そして秘密に保持する）、通信セッションの間における暗号化および認証された通信を可能にすることができる。

[0002] ２つのデバイスがこのような通信セッションを確立しようとするとき、サポートされているプロトコルを特定し、鍵を交換するために、ハンドシェーク・プロトコルを用いることができる。例えば、トランスポート・レイヤー・セキュリティー（ＴＬＳ）プロトコルは、ハンドシェークを開始するため、暗号アルゴリズム、圧縮アルゴリズム、公開鍵、および認証証明書を開示し選択するため、ならびに取り決められたアルゴリズムを用いて通信の開始を通知するために、各デバイスによって実装することができる。一旦通信セッションの詳細が決定されたなら、デバイスは安全な接続を確立することができ、暗号化されたチャネルを通じて通信を開始することができる。

[0003] この摘要は、詳細な説明の章において以下で更に説明する概念から選択したものを紹介するために設けられている。この摘要は、特許請求する主題の主要な特徴や必須の特徴を特定することを意図するのではなく、特許請求する主題の範囲を限定するために用いられることを意図するのでもない。

[0004] トランスポート・レイヤー・セキュリティー（ＴＬＳ）プロトコルを含む多くのハンドシェーク・プロセスは、通信セッションのロジスティック(logistics)の取り決めにおいて、幅広いロバスト性を許容する。しかしながら、このロバスト性のために、実装の複雑さや、その結果起こり得るセキュリティー不備というような、種々のコストがかかる可能性がある。また、デバイスは取り決めを完了するために様々なメッセージを交換しなければならないこともあり、各メッセージが、デバイスを接続するネットワークを往復しなければならない場合がある。この情報交換は、特に、低帯域幅、高レイテンシー、および／または信頼性のない接続を経るときには（例えば、メッセージの欠落を伴うかもしれない低受信セルラー・ネットワーク）、時間がかかる可能性があり、または障害を受けやすい可能性がある。

[0005] 代替技法では、通信セッションを確立するために、比較的少数のメッセージ交換で済む場合もある。本明細書において開示するこのような１組の技法では、ソース・デバイスからターゲット・デバイスへの、セッション招待を表す１組の情報（例えば、１つのメッセージ）の配信を伴い、このメッセージは、ソース・デバイスの１つ以上の候補アドレス、およびソース・デバイスによって発生されたセッション鍵を指定する。クライアント・デバイスは、このセッション招待を受信することができ、通信セッションの確立を許容することを選択する場合（そして、セッション招待の詳細を検証する、例えば、デバイスおよび／またはユーザーを、通信セッションを開始したものとして認証する場合）、それ自体のセッション鍵、およびターゲット・デバイスの１つ以上の候補アドレスと共に回答することができる。ソース・デバイスおよびターゲット・デバイスは、各々、ソース・セッション鍵およびターゲット・セッション鍵を用いて、セッション鍵を確立し、双方のデバイスはこのセッションのためにセッション鍵を用いることができる。安全を確保した通信セッションを可能にするのに十分な１組の情報を交換した後、ソース・デバイスは通信セッションを開始することができ、ターゲット・デバイスは同じように回答することができる。このように、デバイス間で交換するメッセージの数を減少させて（おそらくは最小数）、安全な通信セッションを確立ことができ、これによって通信セッションを確立する際のレイテンシーや障害の可能性を低減することができる。この方式において、他のセキュリティー機構を実装し含ませることもできる。例えば、安全な通信セッションが確立されるまで、ソース・デバイスおよびターゲット・デバイスの実際のアドレスを隠しておくことが可能なこともある。例えば、異なるアドレス（匿名にしたアドレスのような）をハンドシェーク・プロセスの間用いることもでき、その間、デバイスは、通信セッションの間に用いられる、各アドレスの他の（非匿名）アドレスを安全に送信することができる。

[0006] 以上の目的および関係する目的の遂行のために、以下の説明および添付図面は、ある種の例示的態様および実施態様について明示する。これらは、１つ以上の態様を採用することができる種々の方法の内僅かなものを示すに過ぎない。本開示の他の態様、利点、および新規な特徴は、以下の詳細な説明を、添付図面と合わせて検討することにより、明白になるであろう。

図１は、ソース・デバイスとターゲット・デバイスとの間における非対称暗号鍵対の発生および交換を描写するシナリオ例の図である。 図２は、安全な通信セッションを通じてソース・デバイスとターゲット・デバイスとの間においてメッセージを交換するための、非対称暗号鍵対の使用を描写するシナリオ例の図である。 図３は、トランスポート・レイヤー・セキュリティー（ＴＬＳ）プロトコルの一バージョン例によるソース・デバイスとターゲット・デバイスとのハンドシェーク反復の図である。 図４は、本明細書において紹介する技法による、ソース・デバイスとターゲット・デバイスとのハンドシェーク反復の図である。 図５は、ソース・デバイスによってターゲット・デバイスとの通信セッションを確立する方法の一例を示すフロー・チャートである。 図６は、ターゲット・デバイスによってソース・デバイスとの通信セッションを確立する方法の一例を示すフロー・チャートである。 図７は、本明細書において明示する装備の内１つ以上を具体化するように構成されているプロセッサー実行可能命令を備えているコンピューター読み取り可能媒体の一例の図である。 図８は、本明細書において明示する技法にしたがって通信セッションを確立することができる１組のデバイスを、配備可能な計算環境内において表した図である。 図９は、通信セッションを確立している間にソース・デバイスおよび／またはターゲット・デバイスによってアクセスすることができる公開証明書を格納するように構成されている証明書サーバーを描写するシナリオ例の図である。 図１０は、ソース・デバイスとソース・ノンスを利用するターゲット・デバイスとの間における通信セッションの確立を描写するシナリオ例の図である。 図１１は、本明細書において明記する装備の内１つ以上を実現することができる、計算環境の一例を示す。

[0018] これより図面を参照して、特許請求する主題について説明する。図面では、同様の参照番号は全体にわたって同様のエレメントを指すために用いられている。以下の記載では、説明の目的上、特許請求する主題の完全な理解を得るために、多数の具体的な詳細について明記する。しかしながら、特許請求する主題は、これらの具体的詳細がなくても、実施できることは明白であろう。一方、特許請求する主題を記述しやすくするために、構造およびデバイスをブロック図で示すこととする。

[0019] 計算分野における多くのシナリオでは、インターネットを通じて接続されている２つのコンピューター、またはワイヤレス・ローカル・ネットワークを通じて接続されている２つのワイヤレス通信デバイスというような、ピア・デバイス間における通信セッションの確立を伴う。これらのシナリオでは、デバイスは、これらのデバイス間における通信が暗号化されるように、安全なチャネルを通じて通信セッションを確立しようとすることがある。更に、これらのデバイスは、パスワードを互いに共有しない方法でデーターを暗号化しようとすることもできる。これは、安全な通信セッションが確立される前では、パスワードを安全に交換することが困難である場合があるからである。つまり、デバイスは、暗号化されていないメッセージを送ることによって、物理的ネットワークを通じて通信することができるが、「オーバーレイ」ネットワークを案出する(devise)ことを望むこともあり、これによって、暗号化されたメッセージを、物理的ネットワークを通じて送ることおよび受信することができるが、各デバイスによってメッセージを自動的に暗号化および解読することもでき、これによって、各デバイス上で実行しているアプリケーションに、傍受からの安全を確保したデバイス間の仮想ネットワークを提示することができる。

[0020] 図１および図２は、合わせて、安全に通信セッションを確立し利用しようとするソース・デバイス１２（例えば、通信セッションの要求を発するクライアント）とターゲット・デバイス１４（例えば、通信セッションを開始する要求を受信するサーバー）とを描写するシナリオ例を示す。図１のシナリオ例１０では、ソース・デバイス１２およびターゲット・デバイス１４は、ＲＳＡアルゴリズムのような、非対称鍵暗号を特徴とする暗号アルゴリズム１６の使用によって、通信セッションの安全を確保する際に必要となる何らかの情報を発生し交換する。このアルゴリズムは、公開鍵および秘密鍵から成る暗号鍵対を発生するように構成されている。この暗号鍵対は、次の２つの特性を有する。公開鍵を用いて秘密鍵を特定することはできない。公開鍵を用いて暗号化されたメッセージは、秘密鍵を用いることによってのみ、解読することができる。追加の利点として、秘密鍵を用いて、メッセージに暗号的に「署名」することもでき、公開鍵を用いてこの署名を検証し、こうしてメッセージの作者を秘密鍵の保持者として検証することができる（そして、メッセージの内容を検証することができる）。安全な通信セッションに備えるために、ソース・デバイス１２は暗号アルゴリズム１６を利用して、ソース秘密鍵２０およびソース公開鍵１８を発生することができ、ターゲット・デバイス１４は、暗号アルゴリズム１６を利用して、ターゲット公開鍵２２およびターゲット秘密鍵２４を発生することができる。次いで、ソース・デバイス１２は、ソース秘密鍵２０を秘密に保持しつつ、ソース公開鍵１８をターゲット・デバイス１４に送信することができ、ターゲット・デバイス１４は、ターゲット秘密鍵２４を秘密に保持しつつ、ターゲット公開鍵２２をソース・デバイス１２に送信することができる。

[0021] 図２は、傍受を防ぐ安全な方法でメッセージを交換しつつ、パスワードを共有するときのセキュリティー上の難点を回避し（例えば、通信セッションが確立される前に通信セッションを暗号化するために共有パスワードを交換することの難点）、そして特定のメッセージの作者および内容の検証を可能にするための、ソース・デバイス１２およびターゲット・デバイス１４によるこれらの鍵対の使用を描写するシナリオ例３０を示す。図１のシナリオ例１０と同様に、ソース・デバイス１２は、ターゲット・デバイス１４と共有されているソース公開鍵１８と、秘密に保持されるソース秘密鍵２０とを既に発生しており、ターゲット・デバイス１４は、ソース・デバイス１２と共有されているターゲット公開鍵２２と、秘密に保持されるターゲット秘密鍵２４とを既に発生している。このシナリオ例３０では、ソース・デバイス１２およびターゲット・デバイス１４はこの時点で通信セッション３２に入っており、このセッションを通じて、メッセージ３４をソース・デバイス１２からターゲット・デバイス１４に安全に送信することができる。例えば、通信セッション３２は、インターネットのような、信頼性のないネットワーク上でも確立することができ、傍受が行われる虞れがある。したがって、ソース・デバイス１２およびターゲット・デバイス１４は、第三者によって容易に読み取り、変更、または改ざんを行うことができない、暗号化されたメッセージだけを通信セッション３２において配信する。

[0022] このシナリオ例３０では、ソース・デバイス１２は最初にメッセージ３４をターゲット公開鍵２２で暗号化して、暗号化メッセージ３６を生成する。また、ソース・デバイス１２は、ソース秘密鍵２０で暗号化メッセージ３６に署名して、暗号化／署名付きメッセージ３８を生成する。この暗号化／署名付きメッセージ３８は、通信セッション３２においてターゲット・デバイス１４に送信することができる。第三者が通信セッション３２上において傍受し、暗号化／符号付きメッセージ３８を読み取れるのであっても、傍受されたメッセージ３４を解読することはできない。何故なら、第三者はターゲット秘密鍵２４にアクセスできないからである。対照的に、ターゲット・デバイス１４が暗号化／署名付きメッセージ４０を受信するときには、ターゲット・デバイス１４はターゲット秘密鍵２４を用いて、解読メッセージ４０を生成する。加えて、ターゲット・デバイス１４は、ソース公開鍵１８を用いて、解読されたメッセージ４０の作者を検証すること（即ち、ソース・デバイス１２のような、ソース秘密鍵２０に対してアクセスすることができるデバイスによって、解読されたメッセージ４０が発生されたことを検証する）、および／または解読されたメッセージ４０の内容が、通信セッション３２において傍受しているかもしれない第三者によって変更されていないことを検証することができる。このシナリオ例３０の結果、ターゲット・デバイス１４は、解読され、検証されたメッセージ４２を受信することになる。メッセージ４２は、信頼性のないチャネル（インターネットのような）を通じて送信されているが、第三者による傍受および／または改ざんの確率は検証可能に低い。

[0023] 図１および図２のシナリオ例において図示した技法は、暗号化されたメッセージを、安全な通信セッションにおいて交換するために用いることができるが、通信セッションを確立するために公開鍵情報を交換する態様には、追加の考慮を伴ってもよい。第１の例として、第三者が鍵交換の開始時に他方のデバイスの替え玉を演じることが決してできないように、一方のデバイスが他方のデバイスを認証することが望ましい場合がある。例えば、第三者が、ソース・デバイス１２からの通信セッション３２を確立する要求を傍受する可能性があり、ターゲット・デバイス１４の替え玉を演じつつ、ソース・デバイス１２との鍵交換に関与することがあり得る。更に、「中間者攻撃」(man-in-the-middle attack)では、第三者がソース・デバイスの替え玉を演じて、ターゲット・デバイス１４との第２通信セッション３２を確立することを要求することもあり得る。双方の通信セッション３２を開始することに成功した場合、第三者は、一方の通信セッション３２から受信した全てのメッセージ３４を他方の通信セッション３２に受け渡すことができ、これによって、ソース・デバイス１２とターゲット・デバイス１４との間に安全な通信チャネル３２があるように装うが、これを通じて交換されるメッセージ３４に完全にアクセスすることができるようになる。この可能性を低減するために、ソース・デバイス１２は、例えば、ターゲット・デバイスの個別情報(identity)を、信頼されているソースから受信した公開証明書と突き合わせて検査し、ターゲット・デバイス１４を特定することによって、ターゲット・デバイス１４を認証しようとしてもよい。これは、第三者にはおそらく遂行することができない。

[0024] 第２の例として、メッセージを解読できない第三者がなおもソース・デバイス１２および／またはターゲット・デバイス１４を「反射攻撃」(replay attack)によって攻撃することもあり得る。この場合、第三者は、通信セッション３２に送信された１つ以上の暗号化され署名されたメッセージ３８を取り込み、後にそれらを受信側デバイスに再送信する。受信側デバイスは、再生されたメッセージを、以前に受信したメッセージの複製として認識し損ねて、それに対して反応(act)する可能性がある。例えば、ソース・デバイス１２がターゲット・デバイス１４に、ソース・デバイス１２を認証する通信セッション３２を確立する要求を送る場合、第三者がこのメッセージを取り込んで、これをターゲット・デバイス１４に異なるアドレスから再送信することもできる。第三者は要求の内容を解読することができなくても、別のアドレスからのこの要求の再送（ソース・デバイス１２の暗号化された信任状を含む）がターゲット・デバイス１４によって首尾良く受け入れられることによって、ターゲット・デバイス１４に、ソース・デバイス１２の替え玉を演じる第三者との通信セッション３２を確立することを促すことができる。このようなセキュリティー・リスクの脅威を低減するために、ソース・デバイス１２および／またはターゲット・デバイス１４は、種々のメッセージにおいて、「ノンス」を含ませることができる。「ノンス」は、１回だけの識別子（ランダムに発生されることが多い）を含み、受信側デバイスが、送信されたメッセージを特定することができるように、メッセージ３４、通信セッション３２等に、区別できる特性を付加するために用いられる。

[0025] これらおよびその他の考慮事項のために、単に鍵情報の交換だけでなく、関連情報も伴って、ソース・デバイス１２とターゲット・デバイス１４との間において通信セッション３２を確立する特定の方法を考案するとよい。多くのシナリオにおいて、この通信セッション３２を確立する方法は、「ハンドシェーク」と呼ばれることもあり、入念に構造化された対話的な方法で大量の情報交換を伴うことができる。

[0026] 図３は、トランスポート・レイヤー・セキュリティー（ＴＬＳ）暗号プロトコルにおいて用いられる、ソース・デバイス１２とターゲット・デバイス１４との間における通信セッションの「ハンドシェーク」確立を描写する、シナリオ例５０を示す。この場合も、ソース・デバイス１２はソース公開鍵１８およびソース秘密鍵２０を発生し、一方、ターゲット・デバイス１４はターゲット公開鍵２２およびターゲット秘密鍵２４を発生する。ＴＬＳプロトコルにしたがう１つの比較的簡素化された「ハンドシェーク」対話処理によれば、ソース・デバイス１２は、ターゲット・デバイス１４に、「クライアント・ハロー」 (Client Hello)メッセージとしてエンコードされたメッセージ５２を送ることによって、対話処理を開始する。この「クライアント・ハロー」メッセージは、クライアント１２によって用いられるＴＬＳのバージョンおよびソース・ノンスを特定する。ターゲット・デバイス１４は、「サーバー・ハロー」(Server Hello)メッセージ５２で応答する。「サーバー・ハロー」メッセージも、サーバー１２によって用いられるＴＬＳのバージョン、およびターゲット・ノンスを特定する。また、ターゲット・デバイス１４は「証明書」メッセージ５２も送る。「証明書」メッセージ５２は、シナリオによっては、ターゲット公開鍵２２を含むこともある。次いで、ターゲット・デバイス１４は、ソース・デバイス１２に、「サーバー・ハロー・済み」(Server Hello Done)メッセージ５２を送る。ソース・デバイス１２は、ソース公開鍵１８を特徴付ける「クライアント鍵交換」メッセージ５２で回答し、次いで「暗号仕様変更」メッセージ５２を送る。このメッセージ５２は、ソース・デバイス１２によって送られる後続のメッセージ５２が、交換された信任状にしたがって暗号化されることを示す。最後に、ソース・デバイス１２は「終了」メッセージ５２を送り、ソース・デバイス１２がハンドシェーク対話処理の担当部分を完了したことを示す。ターゲット・デバイス１４は、同様の「暗号仕様変更」メッセージ５２および「終了」メッセージ５２で応答することによって、ハンドシェーク対話処理を完了し、安全な通信チャネル３２を確立する。

[0027] この比較的簡略化したハンドシェーク対話処理では、ソース・デバイス１２およびターゲット・デバイス１４は大量の情報を交換する。この対話処理は、９つのメッセージ５２の交換を伴うものであり、各メッセージは、発送側デバイスによって利用され受信側デバイスにおいて特定の挙動を引き起こす、特定のフォーマットを有する。ハンドシェーク対話処理の複雑さのために、複雑化が生じる確率が高くなることもあり得る（例えば、正しくない順序でメッセージ５２が交換された場合における予期しない結果または望ましくない結果、メッセージ５２の配信失敗、および第三者による誤用の機会）。更に、各メッセージ５２は、ネットワーク上における送信遅延を伴い、大量のレイテンシーが発生して、ソース・デバイス１２とターゲット・デバイス１４との間における通信チャネル３２の確立が遅れる可能性がある。メッセージ５２の交換回数を減らすために何らかの技法を用いることもできるが（例えば、図３のシナリオ例５０において、関係するメッセージ５２を組毎に纏めることによって、メッセージの交換回数を４に減らすことができる）、通信チャネルの追加の機構（例えば、特定のＴＬＳバージョンおよび特定の暗号アルゴリズム１６の取り決め）が、ハンドシェークを完了するために交換されるメッセージ５２の数を更に増やすこともあり得る。また、このようなメッセージの発生、送信、受信、デコーディング、および処理は、ソース・デバイス１２およびターゲット・デバイス１４に計算の負担がかかり、接続数が多いこともあるシナリオでは（例えば、大きな１組のピア・デバイス間におけるピア・ツー・ピア・データー転送では、１つのデバイスが数百もの接続を動的に確立し維持する場合もある）、接続を確立する遅延およびコンピューター使用負担が容認可能な範囲を逸脱する可能性がある。

[0028] したがって、好適に低いレイテンシーおよびコンピューター使用コストで通信セッション３２の確立を可能にすべく、またそれと共に本明細書において論ずる特徴の一部（例えば、中間者攻撃または反射攻撃に対する保護）を可能とするよう、ハンドシェーク対話処理の複雑さを低減することが望ましいと考えられる。レイテンシーを低減する技法の１つでは、通信セッション３２の確立において交換されるメッセージ５２の数を減らすことが必要となる。例えば、各デバイスが他のデバイスに安全な通信セッション３２の担当部分を定義する１組の情報を配信することを許容することによって、通信セッション３２が１回のメッセージ５２の交換によって開始できるようにする、ハンドシェーク対話処理を考案することもできる。

[0029] 図４は、ソース・デバイス１２およびターゲット・デバイス１４が１回の情報交換で通信セッション３２を確立することができる、これらの技法の一実施形態を描写するシナリオ例６０を示す。例えば、ソース・デバイス１２およびターゲット・デバイス１４は、プロセッサー８８を有し、インターネットまたはローカル・エリア・ネットワーク（ＬＡＮ）のような有線またはワイヤレス通信ネットワークを通じて通信するコンピューターを含むことができる。このシナリオ例６０では、ソース・デバイス１２は、ソース公開証明書６６によって識別可能とすることができ、ターゲット・デバイス１４は、ターゲット公開証明書７２によって識別可能とすることができる。これらの公開証明書は、信頼されているサーバー（例えば、公開証明書を格納し、他のデバイスによるデバイスの認証を促進するように構成されている認証サーバー）によって維持されているとよいが、他の方法で交換することもできる。ソース公開証明書６６は、例えば、ソース証明書公開鍵６２を収容することができる。ソース証明書公開鍵６２は、既知の認証されているソース・デバイス１２によって秘密に保持されているソース証明書秘密鍵６４に対応する。そして、ターゲット公開鍵７２は、例えば、ターゲット証明書公開鍵６８を収容することができる。ターゲット証明書公開鍵６８は、既知の認証されているターゲット・デバイス１４によって秘密に保持されているターゲット証明書秘密鍵７０に対応する。これらの公開証明書に付随する鍵対は、他のデバイスとの通信セッション３２の間は、メッセージ５２を暗号化するためにデバイスによって用いることができないが、デバイスの認証のために保持しておくことができる。ソース・デバイス１２は、ターゲット証明書公開鍵６８を含むターゲット公開証明書７２にアクセスすることができ、ターゲット・デバイス１４は、ソース証明書公開鍵６２を含むソース公開証明書６６にアクセスすることができる。加えて、ソース・デバイス１２は、特定のネットワーク上におけるソース・アドレス７８、例えば、インターネットまたはＬＡＮアクセスのために割り当てられるＴＣＰ／ＩＰアドレスを有することもでき、ターゲット・デバイス１４は、同じネットワーク上におけるターゲット・アドレス８０を有することができる。このアドレスは、各デバイスがメッセージ５２を他のデバイスにアドレスするために用いることができる。例えば、ターゲット・アドレス８０をターゲット公開証明書７２において指定することができ、これによって、ターゲット・デバイス１４がターゲット・アドレス８０でアクセス可能であり且つターゲット証明書秘密鍵７０を所有している場合に、ターゲット・デバイス１４の個体情報を認証することができる。

[0030] ソース・デバイス１２がターゲット・デバイス１４との通信セッション３２を開始する要求を（例えば、ユーザーから）受けたとき、ソース・デバイス１２は以下のようにしてハンドシェークを開始することができる。最初に、ソース・デバイス１２はソース・セッション鍵７０を発生することができる。ソース・セッション鍵７０は、このターゲット・デバイス１４とのこの通信セッション３２のためにのみ、メッセージ５２を暗号化および解読するために用いられる。ソース・デバイス１２は、セッション招待８２を用意することができる。セッション招待８２は、ソース・セッション鍵７４およびソース・アドレス７８を含む。ソース・デバイス１２は、ターゲット公開証明書７２の中にあるターゲット証明書公開鍵６８を用いてメッセージを暗号化することができる。次いで、セッション招待８２は、通信セッション３２を開始する要求として、ターゲット・デバイス１４に送信され得る。

[0031] ターゲット・デバイス１４がセッション招待８２を受け取ると、ターゲット・デバイス１４は、ターゲット証明書秘密鍵７０を用いて、セッション招待８２を解読することができ、この通信セッション３２を開始する招待を受け入れるか否か判断することができる。ターゲット・デバイス１４がこの招待を受け入れる場合、ターゲット・デバイス１４は次にターゲット・セッション鍵７６を発生することができる。ソース・セッション鍵７４およびターゲット・セッション鍵７６を用いて、ターゲット・デバイス１４は、最終的な通信セッション３２を解読するために用いることができるセッション鍵８６を発生することができる。例えば、セッション鍵８６は、Rijndael鍵のような、メッセージの暗号化および解読双方を行うために用いることができる、対象鍵を含むことができる。対象鍵は、例えば、ソース・セッション鍵７４およびターゲット・セッション鍵７６の単純な連携を構成することもできる。ターゲット・セッション鍵７６を発生した後、ターゲット・デバイス１４は、ターゲット・セッション鍵７６およびターゲット・アドレス８０を含む、セッション受入８４を発生することができる。セッション受入８４は、ソース公開証明書６６によってエンコードすることができる。次いで、ターゲット・デバイス１４はセッション受入８４をソース・デバイス１２に送信することができる。セッション受入８４を受け取ると、ソース・デバイス１２も、ソース・セッション鍵７４およびターゲット・セッション鍵７６を用いて、セッション鍵８６を発生することができる。次いで、ソース・デバイス１２は、セッション鍵８６によって暗号化された、ターゲット・アドレス１４との通信セッションを開始することができ、図２のシナリオ例３０におけるように、通信セッション３２を通じてメッセージを交換することができる。このように、ソース・デバイス１２およびターゲット・デバイス１４は、２つメッセージ５２のみで、通信セッション３２を開始するための関連情報を交換することができ、これによって、ハンドシェークのレイテンシーおよびコンピューター使用負担を軽減することができる。加えて、ターゲット公開証明書７２の使用により、ソース・デバイス１２に対するターゲット・デバイス１４の個体情報の認証を容易にする一方、ハンドシェークにおいて追加メッセージ５２の交換を必要としない。更に、これらの技法の改良では（図４には示されていない）、通信セッション３２を確立するのに要するレイテンシーは、ターゲット・デバイス１４が、セッション招待８２を受け取ったときに、ソース・デバイス１２との通信セッションを開始する場合、更に短縮することもできる。この実施形態では、セッション受入８４は、確立された通信チャネル内において送ることができ、これによって、１つのメッセージ５２の交換に対するハンドシェークを減らし、ハンドシェークのレイテンシーおよびコンピューター使用負担を軽減することができる。

[0032] 図５は、これらの技法の第１実施形態を示し、プロセッサー８８およびソース・アドレス７８、ならびにソース公開鍵６２およびソース秘密鍵６４を有するソース・デバイス１２によって通信セッション３２を確立する方法の一例９０として紹介する。したがって、ソース・デバイス１２は、ソース公開鍵６２を含むソース公開証明書６６によって表される。通信セッション３２は、ターゲット公開証明書７２およびターゲット・アドレス８０を有するターゲット・デバイス１４と確立される。この方法例９０は、例えば、ソース・デバイス１２のメモリーに格納されている１組の命令として具体化することができる。方法例９０は、９２において開始し、本明細書において紹介した技法を実施するように構成されている命令をプロセッサー８８上で実行する（９４）ステップを含む。即ち、ソース・セッション鍵を発生する（９６）ように、命令を構成することができる。また、命令は、ソース・アドレス７８およびソース・セッション鍵７４を含むセッション招待８２を、ターゲット・デバイス１４に送信する（９８）ように構成することもでき、ここで、セッション招待８２は、ターゲット公開証明書７２（例えば、ターゲット公開証明書７２に含まれているターゲット証明書公開鍵６８）を用いて暗号化される。また、命令は、ターゲット・デバイス１２から、ターゲット・アドレス８０およびターゲット・セッション鍵７６を含むセッション受入８４を受け取ったとき（１００）に、ソース公開証明書６６を用いてセッション受入８４を解読し（１０２）、ソース・セッション鍵７４およびターゲット・セッション鍵７６を用いて、セッション鍵８６を発生する（１０４）ように構成することもできる。最後に、命令は、セッション受入８４において指定されているターゲット・アドレス８０において、ターゲット・デバイス１４との通信セッション３２を開始する（１０６）ように構成することもでき、通信セッション３２は、セッション鍵８６を用いて暗号化される。セッション招待８２の送信およびセッション受入８４の受信によってターゲット・デバイス１４と鍵情報を交換し終えた後、方法例９０は、メッセージ５２の数を減らして、ターゲット・デバイス１４との通信セッション３２を確立し、こうして１０８において終了する。

[0033] 図６は、これらの技法の第２実施形態を示し、プロセッサー８８、ターゲット公開証明書７２、およびターゲット・アドレス８０を有するターゲット・デバイス１４によって、ソース公開証明書６６を有するソース・デバイス１２との通信セッション３２を確立する方法の一例１１０として図示する。方法例１１０は、例えば、ターゲット・デバイス１４のメモリーに格納されている１組の命令として具体化することができる。方法例１１０は、１１２において開始し、本明細書において紹介した技法を実施するように構成されている命令をプロセッサー８８上で実行するステップ１１４を含む。更に具体的には、命令は、ソース・アドレス７８およびソース・セッション鍵７４を含むセッション招待８２をソース・デバイス１２から受け取ったとき（１１６）、ターゲット公開証明書７２を用いてセッション招待８２を解読し（１１８）、ターゲット・セッション鍵７６を発生する（１２０）ように構成することができる。ソース・セッション鍵７４およびターゲット・セッション鍵７６を用いて、セッション鍵８６を発生する（１２２）ように、命令を構成することができる。また、ターゲット・アドレス８０およびターゲット・セッション鍵７６を含むセッション受入８４をソース・デバイス１２に送信する（１２４）ように命令を構成することもでき、セッション受入８４は、ソース公開証明書６６を用いて暗号化される。最後に、ソース・デバイス１２から通信セッション３２の開始を受け取ったときに、ソース・アドレス７６においてソース・デバイス１２との通信セッション３２を開始する（１２４）ように、命令を構成することができ、通信セッション３２は、セッション鍵８６を用いて暗号化される。セッション招待８２の受信およびセッション受入８４の送信によってソース・デバイス１２と鍵情報を交換し終えた後、方法例１１０は、メッセージ５２の数を減らして、ソース・デバイス１２との通信セッション３２を確立し、こうして１２６において終了する。

[0034] 更に他の実施形態は、本明細書において紹介した技法を応用するように構成されているプロセッサー実行可能命令を備えているコンピューター読み取り可能媒体を含む。これらの方法において考案することができるコンピューター読み取り可能媒体の一例を図７に示す。図７では、実施態様１３０は、コンピューター読み取り可能媒体１３２（例えば、ＣＤ−Ｒ、ＤＶＤ−Ｒ、またはハード・ディスク・ドライブのプラッター）を備えており、その上にコンピューター読み取り可能データー１３４がエンコードされている。このコンピューター読み取り可能データー１３４は、一方、本明細書において明記した原理にしたがって動作するように構成されている１組のコンピューター命令１３６を構成する。このような実施形態の１つでは、プロセッサー実行可能命令１３６は、図５の方法例９０のような、ターゲット・デバイスとの通信セッションを確立する方法を実行するように構成することができる。このような実施形態の他の１つでは、プロセッサー実行可能命令１３６は、図６の方法例１１０のような、ソース・デバイスとの通信セッションを確立する方法を実行するように構成することができる。本明細書において紹介した技法にしたがって動作するように構成されている、多くのこのようなコンピューター読み取り可能媒体を、当業者によって考案することができる。

[0035] 本明細書において論じられた技法は、多くの態様において様々な変形と合わせて考案することができ、一部の変形は、これらおよびその他の技法の他の変形に関して、追加の利点を提供することおよび／または欠点を低減することができる。更に、一部の変形を組み合わせて実施することもでき、組み合わせの中は、相乗的協同による利点の増大および／または欠点の減少を特徴とするものもある。これらの変形は、種々の実施形態に対して個々の利点および／または相乗的利点を与えるように、これらの実施形態において組み込むことができる（例えば、図５の方法例９０および図６の方法例１１０）。

[0036] これらの技法の実施形態間で多様に変更することができる第１の態様は、本明細書において紹介したこれらの技法を利用することができるシナリオに関する。第１の例として、本技法は、インターネットまたはローカル・エリア・ネットワーク（ＬＡＮ）のような有線ネットワーク、あるいはセルラー・ネットワークのようなワイヤレス・ネットワークを通じて接続されているコンピューター間において効率的に（そして低レイテンシーで）安全な通信セッションを確立するために利用することができる。また、本技法は、ユニバーサル・シリアル・バス（ＵＳＢ）ハブのような有線またはワイヤレス・デバイス・ネットワーク、あるいはBluetoothのようなパーソナル・エリア・ネットワーク（ＰＡＮ）を通じて接続されているデバイス間において効率的に（そして低レイテンシーで）安全な通信セッションを確立するためにも利用することができる。また、これらのデバイスは、同じユーザーによってまたは異なるユーザーによって動作させることもできる。第２の例として、本技法は、クライアントとして動作するソース・デバイス１２が、サーバーとして動作するターゲット・デバイス１４に接触しようとするサーバー／クライアント構成、およびソース・デバイス１２およびターゲット・デバイス１４が分散データー共有方式においてピアとして動作するピア・ツー・ピア構成を含む、多くのタイプの通信セッションを確立するために利用することができる。これらの技法の更に他の実施形態では、２つよりも多いデバイスを接続することができ、本明細書において論じられた技法の何らかの変形を用いて、例えば、ソース・デバイス１２および１組のターゲット・デバイス１４間におけるマルチキャスト通信セッション（各々が同じ共有鍵対を用いるか、各々が個々の鍵対を有する等）を確立することができる。第３の例として、非対称暗号鍵対を発生するために、そして鍵対を用いてメッセージ５２を暗号化および解読するために、多くのタイプの暗号アルゴリズムを用いることができる。

[0037] これらの技法を利用することができる特定的なシナリオの１つでは、配備可能な計算環境において表されているデバイス間におけるメッセージの交換に関係する。多数のデバイス間において、一貫性があり、配備可能で、その上拡張可能な方法で、計算環境にアクセスする技法を開発する試みが最近行われている。また、これらの技法は、協同するデバイス間に１組の共通アプリケーションを提供し、更にこのようなデバイス間においてアプリケーションの調達、インストール、使用、およびアンインストールを管理する集中サービスを提供することも追求する。この１組のアプリケーションは、種々のデバイス間において必ずしも同一ではない。例えば、ワークステーションであれば、セル・フォン・デバイス上ではしかるべく実行することができない高性能アプリケーション（例えば、写真編集ソフトウェア、およびグラフィック満載のゲーム）を内蔵することができ、セル・フォン・デバイスは、携帯用でないワークステーションには関係のない、携行に関するアプリケーション（例えば、ＧＰＳに基づく地図作成ソフトウェア）を含むことができる。しかしながら、多くのアプリケーションおよびそれに関係するデーター・オブジェクトは、このようなデバイス間で共有することができ（例えば、ユーザーのカレンダー・オブジェクトを管理するように構成されているカレンダー・アプリケーション）、このようなデバイス間においてアプリケーションおよびデーター・オブジェクトの配布および同期を可能にするように、計算環境を適応させることができる。したがって、コンピューター・システムは、１組のデバイス間において計算環境の配備を可能にするように表すことができると有利であることが認めることができよう。

[0038] このような技法の１つでは、１組のアプリケーションと、アプリケーション・リソースと、それらによって用いられるデーター・オブジェクトとを含む計算環境は、デバイスに付与されそのデバイスの能力に応じた機能を果たすような形で表される。オブジェクトは、ユーザーによって作成されたユーザー・ファイルおよびデーターというような、コンピューター・システムのデーター・オブジェクト、ならびにユーザーの計算環境を構成する無数のデバイスの表現を含む。このように表された計算環境は、いずれのデバイスに付与することもでき、そのデバイスの能力に適した方法で機能することができる。例えば、ワークステーションであれば、ロバストな汎用計算環境として情報を処理することができ、一方、公衆ワークステーションであれば、（例えば、ユーザーのセッション終了時には破棄されてもよい仮想マシンとして）ウェブ・ブラウザーを通じて異なる計算環境体験をもたらすことができ、携帯電話であれば、もっと軽いインターフェースを設けて、携帯電話関連情報（例えば、連絡先、カレンダー、およびナビゲーション・データー）にもっと素早くアクセスできるようにすることもできる。更に、情報集合に対する更新（例えば、好みの変更、およびその中に収容されているデーター・ファイルに対する更新）を、情報集合の基幹ソースに適用し、これによって、その情報集合が配信される他の全てのデバイスに更新を伝えることができる。

[0039] 図８は、１つのこのようなシナリオ１４０を示す。この場合、オブジェクト階層１４４を格納し管理することができる計算環境ホスト１４２によって、計算環境をホストすることができる。計算環境ホスト１４２は、携帯電話デバイス１４６、パーソナル・ノートブック・コンピューター１５０、および公衆ワークステーション１５４のような、種々のデバイスに成り代わって、更に、異なるアクセス特権を有する異なるタイプのユーザーに成り代わって、異なる方法でオブジェクト階層１４４を与えることができる。計算環境に対する更新は、逆に計算環境ホスト１４２に伝えることができ、他のデバイスと自動的に同期させることができる。したがって、計算環境をクラウド計算アーキテクチャとして考案し、提示することができる。クラウド計算アーキテクチャは、同一の計算環境への協同ポータル（デバイス特定の特性を有する）のメッシュを形成する全てのデバイス（「クライアント」）にわたって一貫性がある機能として表現されている、デバイスに独立した表現（「クラウド」）を含む。本明細書において論じられた技法に関して、オブジェクト階層１４４において表されているデバイスは、本明細書において論じられた技法を用いて、安全かつ効率的に通信セッション３２を確立することができる。当業者であれば、本明細書において論じられた技法を利用できる多くのシナリオを考案することができよう。

[0040] これらの技法の実施形態間で多様に変更することができる第２の態様は、ターゲット・デバイス１４のターゲット公開証明書７２を得る方法に関する。ソース・デバイス１２は、このターゲット公開証明書７２を用いて、セッション招待８２を暗号化することができる。一実施態様では、ターゲット公開証明書７２は、ターゲット公開証明書７２を含む種々の公開証明書を格納するように構成することができる証明書サーバーから得ることができる。例えば、大きな組織は、ローカル・エリア・ネットワーク（ＬＡＮ）を通じてアクセス可能なコンピューターというような、その組織によって用いられる種々の既知のデバイスの公開証明書を収容する証明書サーバーを実装することができる。このような実施形態の１つにおいて、このようなデバイスが表される計算環境ホスト１４２は、オブジェクト階層１４４の中にターゲット公開証明書７２を格納するように構成することができ、オブジェクト階層１４４は、ソース・デバイス１２に対して容易にアクセス可能であるとよい。ネットワーク上で動作するソース・デバイス１２は、最初に証明書サーバーに問い合わせてターゲット・デバイス１４の公開証明書を求め、次いで、提供された公開証明書を用いてセッション招待８２を暗号化することによって、特定のターゲット・デバイス１４との通信セッションを確立しようとすることができる。こうすることによって、この技法は、対応する応答を受け取ったときに、ターゲット・デバイス１４を認証する。これは、提供されたターゲット公開証明書７２に対応するターゲット証明書秘密鍵７０にアクセスしなければ、他のデバイスはセッション招待８２を解読することができないからである。しかしながら、証明書サーバーはセキュリティーの弱点を表すこともある。何故なら、第三者によって能力が弱められた場合、多数のデバイスの認証が第三者によって改ざんされる虞れがあり、加えて、証明書サーバー自体を認証しなければならないこともあるからである。代替技法として、種々のデバイスのターゲット公開証明書７２を、いずれかの適したチャネルによって、例えば、電子メール、ファイル転送、または物理的な記憶媒体によって、ソース・デバイス１２に提供してもよい。ソース・デバイス１２がどのようにしてターゲット公開証明書７２へのアクセスを達成するかには関係なく、本明細書において論じられた技法は、それに応じて利用することができる。逆に、実施形態によっては、ターゲット・デバイス１４が既知のソース・デバイスのみとの通信セッション３２を確立するように構成されている場合、ターゲット・デバイス１４はソース公開証明書（同様に証明書サーバー１６２によって提供することができる）を参照して、ハンドシェークの間にソース・デバイス１２を認証することができる。

[0041] これらの技法の更なる改良は、公開証明書のキャッシングに関する。例えば、ソース・デバイス１２が証明書キャッシュを備えていることもあり、この場合、通信セッション３２の開始中に（例えば、証明書サーバーから）得られたターゲット公開証明書７２を格納することができ、同じターゲット・デバイス１４との後続の通信セッションを開始する間に、ターゲット・デバイス１４を再度認証するために、後に利用することもできる。更に、このキャッシングは、特定のデバイス１４のターゲット公開証明書７２の冗長な読み出しを減らすことによって、これらの技法の効率を高めることもできる。また、例えば、それぞれのターゲット公開証明書７２の有効期間を確定し、期限が切れたターゲット公開証明書７２を証明書キャッシュから削除することによって、セキュリティーを強化するためにも、キャッシュを維持するとよい。

[0042] 図９は、本明細書において論じられた技法と合わせて、この第２の態様の変形の一部を描写するシナリオ例１６０を示す。このシナリオ例１６０では、特定のターゲット・デバイス１４のターゲット公開証明書７２を含む公開証明書を格納するように、証明書サーバー１６２を構成することができる。証明書サーバー１６２にアクセスすることができるソース・デバイス１２は、ターゲット・デバイス１４との第１通信セッション１６６を開始しようとすることがあり、したがって、ターゲット公開証明書７２を得るために証明書サーバー１６２に問い合わせることができる。しかしながら、ソース・デバイス１２も、公開証明書を格納するように構成されている証明書キャッシュ１６４を備えることができ、ターゲット・デバイス１４のターゲット公開証明書７２を得たときに、ソース・デバイス１２はターゲット・デバイス１４のターゲット公開証明書７２を証明書キャッシュ１６４に格納するように構成することができる。次いで、ソース・デバイス１２は、第１通信セッション１６６を確立しつつ、ターゲット・デバイス１４を認証するために、ターゲット公開証明書を利用することができる。その後（例えば、第１通信セッション１６６が終了した後）、ソース・デバイス１２がターゲット・デバイス１４との第２通信セッション１６８を開始しようとすることがある。証明書サーバー１６２からターゲット公開証明書７２を再度取得するのではなく、ソース・デバイス１２はターゲット公開証明書７２を証明書キャッシュ１６４から読み出すことができ、このターゲット公開証明書７２は、第２通信セッション１６８を確立している間に、ターゲット・デバイス１４を再度認証するために利用することができる。したがって、このキャッシングは、ターゲット公開証明書７２の冗長な取得を回避することによって、第２通信セッション１６８を確立する効率を高めることができる。当業者であれば、本明細書において論じられた技法を実施しつつ、公開証明書の配信および使用を実現する多くの技法を考案することができよう。

[0043] これらの技法の実施形態間で多様に変更することができる第３の態様は、ソース・デバイス１２とターゲット・デバイス１４との間において確立される通信セッション３２を暗号化するために用いられるセッション鍵８６を生成する(develop)方法に関する。第１の例として、セッション鍵８６は対称鍵を含む場合があり、対称暗号アルゴリズム（例えば、Rijndaelアルゴリズム）にしたがってランダムに発生し利用することができ、これによって、メッセージを暗号化および解読するために、同じ鍵が用いられるようになる。対称鍵は、通信セッション３２の安全を確保するために望ましいと考えられる。何故なら、このような鍵を用いるコンピューター使用負担は、非対称鍵を用いる場合よりも、かなり低くすることができるからである。次いで、セッション鍵８６を発生することができ、このとき、例えば、ランダムに発生した鍵（ランダムに選択した整数または文字列のような）を含むソース・セッション鍵７４を発生し、第２のランダムに発生した鍵を含むターゲット・セッション鍵７６を発生し、そして第１のランダムに発生した鍵および第２のランダムに発生した鍵を用いて、対称ランダム・セッション鍵を発生する（例えば、ランダムに発生した鍵を繋げることによって）。

[0044] 第２の例として、１組のセッション鍵を発生することもできる。対称鍵は非対称鍵よりも容易に解読される虞れがあるので、通信セッション３２の間１組の鍵を順番に用いる(rotate through)ことが望ましい場合がある（例えば、ソース・デバイス１２およびターゲット・デバイス１４が、セッション鍵集合において周期的に次の鍵に切り替わるように構成されている場合）。例えば、セッション鍵８６は、少なくとも２つのセッション鍵を備えているセッション鍵集合として発生することができ、その各々は他方のセッション鍵とは異なるものの、ソース・セッション鍵およびターゲット・セッション鍵を用いて発生される（異なる方法で）。開始時に、最初に第１セッション鍵を用いて通信セッション３２を暗号化することができ、デバイスは、何らかの方法で（例えば、周期的に）第２セッション鍵をセッション鍵集合から選択し、この第２セッション鍵を用いて通信セッション３２を暗号化するように構成することができる。当業者であれば、本明細書において論じられた技法を実施しつつ、セッション鍵を発生し使用する多くの方法を考案することができよう。

[0045] これらの技法の実施形態間で多様に変更することができる第４の態様は、通信セッションを開始する方法に関する。第１の例として、ソース・デバイス１２が、セッション受入８４を受け取った後に、ターゲット・デバイス１４との通信セッション３２を開始することができる。第２の例として、ターゲット・デバイス１４が、代わりに、セッション受入８４を送った後に、ソース・デバイス１２との通信セッション３２を開始することもできる。第３の例として、ターゲット・デバイス１４が、セッション受入８４を送る前であっても、通信セッション３２を開始することもでき、代わりに、通信セッション３２を確立した後にセッション受入８４を送ることができる。この技法は、１つのメッセージのみを送った後に、これらのデバイスに通信セッションを効果的に確立させることができる。例えば、ソース・デバイス１２はセッション招待８２をターゲット・デバイス１４に送ることができ、次いで、通信セッション３２内において続けるためにセッション受入８４を用いて、ターゲット・デバイス１４による通信セッション３２の開始を待つように構成することができる。当業者であれば、本明細書において論じられた技法を実施しつつ、デバイス間において通信セッションを開始する多くの方法を考案することができよう。

[0046] これらの技法の実施形態間で多様に変更することができる第５の態様は、異なるユーザーが動作させるデバイス間における通信セッション３２の確立を伴うシナリオに関する。デバイスが同じユーザーによって動作させられる場合、個別情報に基づくセキュリティーの懸念は比較的少なくて済むと考えられる。しかし、ソース・デバイス１２がソース・ユーザーによって動作させられ、ターゲット・デバイス１４がターゲット・ユーザーによって動作させられる場合、一方または双方のユーザーが、通信セッション３２を開始する前に、他方のユーザーの個人情報を認証することを望む場合がある。例えば、ターゲット・ユーザーが、ソース・デバイス１４のソース・ユーザー１２の内特定の１組とだけデーターを共有するように、ターゲット・デバイス１４を構成しておくことができ、したがって、知らないユーザーまたは知っているが認証されていないユーザーとの通信セッション３２を確立することを拒否するように、ターゲット・デバイス１４を構成することができる。このような実施形態の１つでは、ソース・デバイス１２によって提供されるセッション招待８２は、パスワードまたは暗号署名のような、ソース・ユーザー認証部を含むことができ、この認証部がソース・デバイス１２のソース・ユーザーの個体情報を認証することができる。したがって、ターゲット・デバイス１４は、ソース・ユーザー認証部を用いてソース・ユーザーを認証し、ソース・ユーザーを認証した後に、ソース・デバイス１２との通信セッション３２を開始するように構成することができる。逆に、ターゲット・デバイス１４によって提供されるセッション受入８４は、ターゲット・ユーザー認証部を含むことができ、このターゲット・ユーザー認証部がターゲット・デバイス１４のターゲット・ユーザーの個体情報を認証することができ、ソース・デバイス１２は、ターゲット・ユーザー認証部を用いてターゲット・ユーザーを検証し、ターゲット・ユーザーを認証した後に、ターゲット・デバイス１４との通信セッション３２を開始するように構成することができる。当業者であれば、本明細書において論じられた技法を実施しつつ、ユーザーを認証する多くの方法を考案することができよう。

[0047] これらの技法の実施形態間で多様に変更することができる第６の態様は、ソース・デバイス１２およびターゲット・デバイス１４の一方または双方が多数のアドレスでアクセス可能であるシナリオに関する。第１のこのようなシナリオでは、ソース・デバイス１２およびターゲット・デバイス１４が、Bluetoothネットワークのようなパーソナル・エリア・ネットワーク（ＰＡＮ）、８０２．１１（ＷｉＦｉ）ネットワークのようなローカル・エリア・ネットワーク（ＬＡＮ）、およびインターネットのようなワイド・エリア・ネットワーク（ＷＡＮ）というような、多数のネットワークに跨がって互いに同時にアクセスすることができる場合がある。また、物理的ネットワークは、ノードがサーバー、クライアント、および／または他のピアに対して１つ以上のピアとして動作することができるスーパー・ピア・ネットワークのような、他のタイプのネットワークも備えることができる。第２のシナリオでは、ある範囲のアドレスにおいてターゲット・デバイス１４がアクセス可能であり、ソース・デバイス１２にとって、他のアドレスと比較して、特定のアドレスを用いてターゲット・デバイス１４に接触することが好ましい場合がある（例えば、ポート２１を介してアクセスされるＦＴＰチャネルの代わりに、ポート８０を介してアクセスされるＨＴＴＰチャネル）。これらおよびその他のシナリオでは、ソース・デバイス１２がターゲット・デバイス１４に（例えば、セッション招待８２の一部として）、ソース・デバイスがアクセスすることができる１組のソース候補アドレスを開示することができ、通信セッション３２を確立している間に、ターゲット・デバイス１４はソース候補アドレスの中からソース・アドレス７６を選択することができ、この選択したソース・アドレス７６との通信セッション３２を開始することができる。逆にまたは加えて、ターゲット・デバイス１４がソース・デバイス１２に（例えば、セッション受入８４の一部として）、ターゲット・デバイスがアクセスすることができる１組のターゲット候補アドレスを開示することができ、通信セッション３２を確立している間に、ソース・デバイス１２がソース候補アドレスの中からターゲット・アドレス８０を選択することができ、選択したソース・アドレス８０との通信セッション３２を開始することができる。

[0048] この第６の態様の第２の変形では、一方または双方のデバイスがハンドシェーク・プロセスの間に第１アドレスを用い、通信セッションの間は第２の（異なる）アドレスを用いることが望ましい場合がある。例えば、一方または双方のデバイスが、これらのデバイスと関連のあるアドレスを用いてハンドシェークに関与している場合、このハンドシェーク・プロセスの傍受者(eavesdropper）がこれらのアドレスを用いてデバイスの位置を特定すること、デバイス間のトランザクションを特定すること、および／またはサービス拒否攻撃(denial-of-service attack)によるというような、通信セッションを妨害することが可能になる虞れがある。代わりに、一方または双方のデバイスが１つのアドレス（例えば、匿名アドレス）を用いてハンドシェーク・プロセスに関与し、他のアドレス（例えば、匿名でないアドレス）を用いて、一旦認証され安全に確立された通信セッションに関与しようとすることもある。例えば、セッション受入８４は、ソース・デバイス１２がセッション招待８２を送ったターゲット・デバイス１４のターゲット・アドレス８０とは異なる候補ターゲット・アドレスを含む場合もあり、ソース・デバイス１２は、この候補ターゲット・アドレスにおいて、ターゲット・デバイス１４との通信セッション３２を開始することもできる。逆に、セッション招待８２が、セッション招待８２が送られた元のソース・デバイス１２のソース・アドレス７８とは異なる候補ソース・アドレスを含む場合もあり、ソース・デバイス１２は、この候補ソース・アドレスからターゲット・デバイス１４との通信セッション３２を開始することもできる。このようなシナリオの１つでは、匿名化サーバーが、デバイスに、他のデバイスとハンドシェークするために、１回だけのアドレスを請求することを許容することができる。尚、この匿名化は、他のデバイスまたはそのユーザーの個体情報の、各デバイスによる認証の効果を減ずることなく実現可能であると考えられ、デバイスが匿名アドレスを用いることができても、公開証明書によって認証することができることは認められよう。当業者であれば、本明細書において論じられた技法を実施しつつ、ソース・デバイス１２および／またはターゲット・デバイス１４にアクセスすることができる複数のアドレスを開示し、それらの中から選択し、利用する多くの方法を考案することができよう。

[0049] これらの技法の実施形態間で多様に変更することができる第７の態様は、通信チャネル３２のセキュリティーを改善するための１つ以上のノンスの使用に関する。ノンスとは、ソース・デバイス１２および／またはターゲット・デバイス１４によって発生され、メッセージ５２、通信セッション３２等を区別して特定するためにメッセージ５２に含まれる、特徴的な識別子である。第三者が、発信元の発生した暗号化メッセージを取り込むことができ、通信セッション３２のセキュリティーを損なうため、または受信側デバイスの挙動を変化させるためにこの暗号化メッセージを受信機に再送信することができる状況においては、ノンスの使用により、「反射攻撃」を一層困難にすることができる。第１の例として、ソース・ノンスを発生するようにソース・デバイス１２を構成することができ（例えば、乱数または連続数あるいは文字列）、このソース・ノンスをセッション招待８２に含めることができ、これによってセッション招待８２をはっきりと特定する。セッション招待８２を受け取ったとき、ターゲット・デバイス１４は、ソース・ノンスを検証するように構成することができる（例えば、同じソース・ノンスを有するセッション招待８２を以前に受け取っていないことを確認することによって）。ソース・ノンスを検証するとき、ターゲット・デバイス１４はセッション受入８４をソース・デバイス１２に送信することができ、このソース・ノンスを、１組の既に受け取ったソース・ノンスに記録することができる。加えて、ターゲット・デバイス１４はソース・ノンスをセッション受入８４に含めることができ、セッション招待８２に応答するときに、ターゲット・デバイス１４の個体情報を更に認証することができる（例えば、第三者が、以前に受け取ったセッション受入８４に回答することによって、ターゲット・デバイス１４になりすまそうとすることもあり得るが、セッション受入８４においてソース・ノンスが一致しないと、ソース・デバイス１２になりすましを警告することができる）。代わりにまたは加えて、ターゲット・デバイス１４がターゲット・ノンスを発生することができ、このターゲット・ノンスをセッション受入８４に含ませることもできる。セッション受入８４を受け取ったときに、ソース・デバイス１２は、ターゲット・デバイス１４との通信セッション３２を開始する前に、ターゲット・ノンスを検証することができる。

[0050] 図１０は、本明細書において紹介した技法にしたがって通信セッション３２を確立しようとするソース・デバイス１２およびターゲット・デバイス１４を描写し、更にソース・ノンス１７２の使用を描写するシナリオ例１７０を示す。ソース・デバイス１２は、ターゲット公開証明書７２によって暗号化されたセッション招待８２を発生し、ターゲット・デバイス１４に送ることによって、通信セッション３２を開始することを要求することができる。しかしながら、セッション招待８２は、（他のエレメントに加えて）ランダムに発生された数値のような、ソース・ノンス１７２を含むことができる。ターゲット・デバイス１４は、セッション招待８２を受け取り、ソース・ノンス１７２が重要な役割を果たすセッション招待８２を以前に受け取っていないことを確認することができる。ソース・ノンス１７２を確認することに成功すると、ターゲット・デバイス１４は、ソース公開証明書６６によって暗号化され、そして（他のエレメントに加えて）ソース・ノンス１７２を含むセッション受入８４を発生し、ソース・デバイス１２に送ることができる。ソース・デバイス１２は、通信セッション３２を開始する前に、セッション受入８４において受け取ったソース・ノンス１７２が、セッション招待８２において送られたソース・ノンス１７２と一致することを検証することができる。

[0051] 図１０のこのシナリオ例１７０においてソース・ノンス１７２を含ませることによって、少なくとも２つの面で通信セッション３２のセキュリティーを改善することができる。第１に、第三者１７４はセッション招待８２を傍受し、その後このセッション招待８２をターゲット・デバイス１４に送ることによってターゲット・デバイス１４との別の通信セッション３２を開始しようとし、これによって、ソース・デバイス１２になりすますことがある。ターゲット・デバイス１４は、再送信されたセッション招待８２に含まれるソース・ノンス１７２を、ソース・デバイス１２によってセッション招待８２の最初の送信において既に受信されたものとして特定することができ、したがって第三者１７４との通信セッション３２の開始を拒否することができる。第２に、第三者１７４は、ターゲット・デバイス１４からソース・デバイス１２に送信されたセッション受入８４を、第１通信セッション開始の間に取り込むことがある。ソース・デバイス１２によるターゲット・デバイス１４との第２通信セッションを確立しようとするその後の試みにおいて、第三者１７４は次にセッション受入８４を再送信することによって、ターゲット・デバイス１４になりすまそうとすることができるが、第２セッション招待８２におけるソース・ノンス１７２が、再送信されたセッション受入８４において第三者１７４によって戻されたソース・ノンス１７２と一致しないことになり、これによって、ソース・デバイス１２になりすましを警告する。尚、 当業者であれば、本明細書において論じられた技法を実施しつつ、ソース・デバイス１２および／またはターゲット・デバイス１４によって発生するノンスについて多くの用法を考案できるであろう。

[0052] 以上、構造的特徴および／または方法論的動作に特定的な文言で主題について説明したが、添付した特許請求の範囲において定義されている主題は、必ずしも前述した特定の特徴や動作に限定されるのではないことは言うまでもない。逆に、前述した特定的な特徴や動作は、特許請求の範囲を実施する形態例として開示したまでである。

[0053] 本願において用いる場合、「コンポーネント」、「モジュール」、「システム」、「インターフェース」などという用語は、一般に、コンピューター関連エンティティ、ハードウェア、ハードウェアおよびソフトウェアの組み合わせ、ソフトウェア、または実行中のソフトウェアのいずれかを指すことを意図している。例えば、コンポーネントは、限定ではなく、プロセッサーにおいて実行しているプロセス、プロセッサー、オブジェクト、エクゼキュータブル、実行のスレッド、プログラム、および／またはコンピューターであってもよい。例示として、コントローラーにおいて実行しているアプリケーションおよびこのコントローラーの双方が１つのコンポーネントになることができる。１つ以上のコンポーネントは、プロセスおよび／または実行のスレッドの内部に存在することができ、コンポーネントを１つのコンピューターに配置すること、および／または２つ以上のコンピューター間で分散することもできる。

[0054] 更に、特許請求する主題は、方法、装置、あるいはソフトウェア、ファームウェア、ハードウェアを生産するための標準的なプログラミングおよび／または設計技法を用いた製造の品目、あるいは開示した主題を実現するようにコンピューターを制御するための組み合わせであればそのいずれとして実現することもできる。「製造の品目」という用語は、本明細書において用いられる場合、いずれかのコンピューター読み取り可能デバイス、担体(carrier)、または媒体からアクセス可能なコンピューター・プログラムを包含することを意図している。勿論、特許請求する主題の範囲や主旨から逸脱することなく、この構成に多くの変更を行い得ることは、当業者には認められよう。

[0055] 図１１および以下の論述は、本明細書において明示した機能(facilities)の１つ以上の実施形態を実現するのに適した計算環境の端的な総合的説明を行うためにある。図１１の動作環境は、適した動作環境の一例に過ぎず、動作環境の使用範囲や機能について何の限定を示唆することも意図していない。計算機の例には、限定ではなく、パーソナル・コンピューター、サーバー・コンピューター、ハンド・ヘルドまたはラップトップ・デバイス、移動体デバイス（移動体電話機、パーソナル・ディジタル・アシスタント（ＰＤＡ），メディア・プレーヤー等）、マルチプロセッサー・システム、消費者用電子機器、ミニ・コンピューター、メインフレーム・コンピューター、以上のシステムまたはデバイスの内いずれかを含む分散方計算環境などが含まれる。

[0056] 必須ではないが、１つ以上の計算機によって実行される「コンピューター読み取り可能命令」という一般的なコンテキストで、実施形態が説明されている。コンピューター読み取り可能命令は、コンピューター読み取り可能媒体（以下で論ずる）を通じて分散することもできる。コンピューター読み取り可能命令は、関数、オブジェクト、アプリケーション・プログラミング・インターフェース（ＡＰＩ）、データー構造などのようなプログラム・モジュールとして実現することができ、特定のタスクを実行するか、または特定の抽象データー・タイプを実装する。通例、コンピューター読み取り可能命令の機能は、種々の環境における所望に応じて、組み合わせることまたは分散することができる。

[0057] 図１１は、本明細書において示した１つ以上の実施形態を実現するように構成されている計算機１８２を備えているシステム１８０の一例を示す。一構成では、計算機１８２は少なくとも１つの演算装置１８６およびメモリー１８８を含む。計算機の正確な構成およびタイプに応じて、メモリー１８８は揮発性（例えば、ＲＡＭのような）、不揮発性（例えば、ＲＯＭ、フラッシュ・メモリー等のような）、またはこれら２つの何らかの組み合わせとすることができる。この構成は、図１１では破線１８４で示されている。

[0058] 他の実施形態では、計算機１８２は追加の機構および／または機能を含むこともできる。例えば、計算機１８２は、追加のストレージ（例えば、リムーバブルおよび／または非リムーバブル）も含むことができる。限定ではなく、追加のストレージには、磁気ストレージ、光ストレージ等が含まれる。このような追加のストレージは、図１１ではストレージ１９０によって例示されている。一実施形態では、本明細書において示した１つ以上の実施形態を実現するコンピューター読み取り可能命令は、ストレージ１９０の中にあるとよい。また、ストレージ１９０は、オペレーティング・システム、アプリケーション・プログラム等を実装するために、他のコンピューター読み取り可能命令も格納することができる。コンピューター読み取り可能命令は、例えば、演算装置１８６による実行のために、メモリー１８８にロードすることができる。

[0059] 「コンピューター読み取り可能媒体」という用語は、本明細書において用いる場合、コンピューター記憶媒体を含む。コンピューター記憶媒体は、揮発性および不揮発性、リムーバブルおよび非リムーバブル媒体を含み、コンピューター読み取り可能命令または他のデーターのような情報の格納のためのいずれかの方法または技術で実現されている。メモリー１８８およびストレージ１９０は、コンピューター記憶媒体の例である。コンピューター記憶媒体は、限定ではなく、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリーまたはその他のメモリー技術、ＣＤ−ＲＯＭ、ディジタル・バーサタイル・ディスク（ＤＶＤ）またはその他の光ストレージ、磁気カセット、磁気テープ、磁気ディスク・ストレージまたはその他の磁気記憶デバイス、あるいは所望の情報を格納するために用いることができその上計算機１８２によってアクセスすることができるのであれば他のいずれの媒体をも含む。このようなコンピューター記憶媒体は、そのいずれもが計算機１８２の一部となってもよい。

[0060] また、計算機１８２は、計算機１８２が他のデバイスと通信することを可能にする通信接続（１つまたは複数）１９６も含むことができる。通信接続（１つまたは複数）１９６は、限定ではなく、モデム、ネットワーク・インターフェース・カード（ＮＩＣ）、統合ネットワーク・インターフェース、無線周波数送信機／受信機、赤外線ポート、ＵＳＢ接続、または計算機１８２を他の計算機と接続するためのその他のインターフェースを含むことができる。通信接続（１つまたは複数）１９６は、有線接続またはワイヤレス接続を含むことができる。通信接続（１つまたは複数）１９６は、通信媒体を送信および／または受信することができる。

[0061] 「コンピューター読み取り可能媒体」という用語は、通信媒体を含むことができる。通信媒体は、通例、搬送波またはその他の伝達メカニズムのような「変調データー信号」にコンピューター読み取り可能命令またはその他のデーターを具体化し、いずれの情報配信媒体も含む。「変調データー信号」という用語は、情報を信号内に符号化するような態様で設定または変更したその特性の１つ以上を有する信号を含むことができる。

[0062] 計算機１８２は、キーボード、マウス、ペン、音声入力デバイス、接触入力デバイス、赤外線カメラ、ビデオ入力デバイス、および／またはその他のあらゆる入力デバイスというような、入力デバイス（１つまたは複数）１９４を含むことができる。１つ以上のディスプレイ、スピーカー、プリンター、および／またはその他の出力デバイスというような出力デバイス（１つまたは複数）１９２も、計算機１８２に含むことができる。入力デバイス（１つまたは複数）１９４および出力デバイス（１つまたは複数）１９２は、有線接続、ワイヤレス接続、またはそのいずれの組み合わせによってでも、計算機１８２に接続することができる。一実施形態では、別の計算機からの入力デバイスまたは出力デバイスを、計算機１８２用の入力デバイス（１つまたは複数）１９４または出力デバイス（１つまたは複数）１９２として用いることもできる。

[0063] 計算機１８２のコンポーネントは、バスのような、種々の相互接続によって接続することができる。このような相互接続は、ＰＣＩ Expressのようなペリフェラル・コンポーネント相互接続（ＰＣＩ）、ユニバーサル・シリアル・バス（ＵＳＢ）、ファイアワイヤ（ＩＥＥＥ１３９４）、光バス構造などを含むことができる。別の実施形態では、計算機１８２のコンポーネントは、ネットワークで相互接続することができる。例えば、メモリー１８８は、ネットワークによって相互接続されている異なる物理的位置にある多数の物理的メモリー・ユニットによって構成することもできる。

[0064] コンピューター読み取り可能命令を格納するために利用される記憶デバイスは、ネットワークに跨って分散させてもよいことは、当業者には分かるであろう。例えば、ネットワーク１９８を通じてアクセス可能な計算機２００は、本明細書において提唱した１つ以上の実施形態を実現するために、コンピューター読み取り可能命令を格納することができる。計算機１８２は、計算機２００にアクセスし、コンピューター読み取り可能命令の一部または全部を実行のためにダウンロードすることができる。あるいは、計算機１８２は、必要に応じて、コンピューター読み取り可能命令の断片をダウンロードすることができ、または一部の命令を計算機１８２において実行し、一部を計算機２００において実行することもできる。

[0065] 本明細書では、実施形態の種々の動作について提唱した。一実施形態では、記載した動作の１つ以上が、１つ以上のコンピューター読み取り可能媒体上に格納されたコンピューター読み取り可能命令を構成することができ、計算機によって実行すると、当該計算機に、記載した動作を実行させる。これらの動作の一部または全部を記載した順序は、これらの動作に必然的な順序依存性があるように解釈すべきではない。この記載から援助を受けた当業者には、代わりの順序も認められよう。更に、本明細書において提唱した各実施形態において、全ての動作が必ずしも出てくる訳ではないことは言うまでもない。

[0066] 更に、「一例の」という単語は、本明細書では、一例、実例、または例示としての役割を果たすことを意味するために用いられる。本明細書において「一例の」として記載される態様または設計はいずれも、他の態様または設計よりも有利であるとは必ずしも解釈されない。むしろ、一例のという用語の使用は、概念を具体的に紹介することを意図している。本明細書において用いる場合、「または」という用語は、排他的な「または」ではなく包含的な「または」を意味することを意図する。即ち、そうでないことが指定されていない限り、または文脈から明白でない限り、「ＸはＡまたはＢを採用する」とは、自然な包含的組み合わせ(permutation)のいずれでも意味することを意図する。即ち、ＸがＡを採用する場合、ＸがＢを採用する場合、またはＸがＡおよびＢの双方を採用する場合、これらの実例のいずれにおいても、「ＸはＡまたはＢを採用する」が満たされる。加えて、冠詞「ａ」および「ａｎ」は、本願および添付した特許請求の範囲において用いられる場合、そうでないことが指定されていない限り、また文脈から単数形態を対象とすることが明白でない限り、「１つ以上」を意味するように通常解釈することができる。

[0067] また、１つ以上の実施態様に関して本開示を示し説明したが、本明細書および添付図面の熟読および理解に基づいて、同等の変形や変更が当業者には想起されよう。本開示は、このような変更や変形を全て含み、以下の特許請求の範囲のみによって限定される。特に、以上で述べたコンポーネント（例えば、エレメント、リソース等）によって実行される種々の機能に関して、このようなコンポーネントを記載するために用いられた用語は、そうでないことが示されない限り、記載されたコンポーネント（例えば、機能的に同等な）の指定された機能を実行するのであれば、本開示のここで例示された実施態様例における機能を実行する、開示された構造に構造的に同等でなくても、いずれのコンポーネントにも対応することを意図している。加えて、本開示の特定的な機構を、様々な実施態様の内１つのみに関して開示したが、このような機構は、いずれの所与の用途または特定の用途にとっても望まれるまたは有利となるように、他の実施態様の１つ以上の別の機構と組み合わせることができる。更に、「含む」、「有している」(having)、「有する」(has)、「と」(with)という用語、またはその異形が詳細な説明または特許請求の範囲において用いられている限りにおいて、このような単語は、用語「備えている」(comprising)と同様に内包的であることを意図している。

Claims (15)

1. プロセッサー（８８）およびソース秘密鍵（６４）を有するソース・デバイス（１２）によって、ターゲット公開証明書（７４）を有するターゲット・デバイス（１４）との通信セッション（３２）を確立する方法（９０）であって、
   ソース・セッション鍵（７４）を発生し（９６）、
   ソース・アドレス（７８）および前記ソース・セッション鍵（７４）を備えているセッション招待（８２）を前記ターゲット・デバイス（１４）に送り、前記ターゲット公開証明書（７２）を用いて前記セッション招待（８２）を暗号化し、
   前記ターゲット・デバイス（１４）から、ターゲット・アドレス（７８）およびターゲット・セッション鍵（７６）を備えているセッション受入（８４）を受け取ったとき（１００）、
   前記ソース秘密鍵（６４）を用いて前記セッション受入（８４）を解読し（１０２）、
   前記ソース・セッション鍵（７４）および前記ターゲット・セッション鍵（７６）を用いて、セッション鍵（８６）を発生し（１０４）、
   前記ターゲット・アドレス（７８）で前記ターゲット・デバイス（１４）との通信セッション（３２）を開始し（１０６）、前記セッション鍵（８６）を用いて前記通信セッション（３２）を暗号化する、
   ように構成されている命令を前記プロセッサー（８８）上において実行するステップ（９４）を備えている、方法（９０）。
2. 請求項１記載の方法において、前記ソース・デバイスおよび前記ターゲット・デバイスが、計算環境ホストによってホストされている、配備可能な計算環境において表されている、方法。
3. 請求項１記載の方法において、
   前記ソース・セッション鍵が、第１のランダムに発生した鍵を備えており、
   前記ターゲット・セッション鍵が、第２のランダムに発生した鍵を備えており、
   前記セッション鍵が、前記第１のランダムに発生した鍵および前記第２のランダムに発生した鍵を用いて発生した対称ランダム・セッション鍵を備えている、方法。
4. 請求項１記載の方法において、
   前記セッション鍵を発生する命令が、少なくとも２つのセッション鍵を備えているセッション鍵集合を発生する命令を含み、それぞれのセッション鍵が、前記ソース・セッション鍵および前記ターゲット・セッション鍵を用いて発生され、前記セッション鍵集合における他のセッション鍵とは異なり、
   前記通信セッションを開始する命令が、前記ターゲット・アドレスにおいて前記ターゲット・デバイスとの通信セッションを開始する命令を含み、第１セッション鍵を用いて前記通信セッションを暗号化し、
   前記方法が、前記通信セッションを開始した後、
   前記セッション鍵集合から第２セッション鍵を選択するステップと、
   前記第２セッション鍵を用いて、前記通信セッションを暗号化するステップと、
   を備えている、方法。
5. 請求項１記載の方法において、
   前記ソース・デバイスをソース・ユーザーによって動作させ、
   前記ターゲット・デバイスをターゲット・ユーザーによって動作させ、
   前記セッション受入が、ターゲット・ユーザー認証部を備えており、前記通信セッションを開始する命令が、
   前記ターゲット・ユーザー認証部を用いて前記ターゲット・ユーザーを検証する命令と、
   前記ターゲット・ユーザーを検証したときに、前記ターゲット・デバイスとの通信セッションを開始し、前記セッション鍵を用いて前記通信セッションを暗号化する命令と、
   を含む、方法。
6. 請求項１記載の方法において、
   前記ソース・デバイスが証明書キャッシュを備えており、
   前記命令が、
   前記ターゲット・デバイスのターゲット公開証明書を得たときに、前記証明書キャッシュに前記ターゲット公開証明書を格納し、
   前記ターゲット公開証明書を前記証明書キャッシュから読み出すことによって、前記ターゲット・デバイスとの後続の通信セッションを確立する、
   ように構成されている、方法。
7. 請求項１記載の方法において、
   前記セッション受入が、少なくとも２つの候補ターゲット・アドレスを備えており、
   前記ターゲット・デバイスとの通信セッションを開始する命令が、
   前記少なくとも２つの候補ターゲット・アドレスの中から少なくとも１つを選択する命令と、
   少なくとも１つの選択したターゲット・アドレスにおいて、前記ターゲット・デバイスとの通信セッションを開始し、前記セッション鍵を用いて前記通信セッションを暗号化する命令と、
   を含む、方法。
8. 請求項１記載の方法において、
   前記セッション受入が、前記ソース・デバイスがセッション招待を送る前記ターゲット・デバイスのターゲット・アドレスとは異なる候補ターゲット・アドレスを備えており、
   前記通信セッションを開始する命令が、前記候補ターゲット・アドレスにおいて前記ターゲット・デバイスとの通信セッションを開始し、前記セッション鍵を用いて前記通信セッションを暗号化する命令を含む、方法。
9. 請求項１記載の方法において、
   前記命令が、ソース・ノンスを発生するように構成されており、
   前記セッション招待が、ソース・ノンスを備えている、方法。
10. 請求項１記載の方法において、
    前記セッション受入が、ターゲット・ノンスを備えており、
    前記通信セッションを開始する命令が、
    前記ターゲット・ノンスを検証する命令と、
    前記ターゲット・ノンスを検証したときに、前記ターゲット・デバイスとの通信セッションを開始し、前記セッション鍵を用いて前記通信セッションを暗号化する命令と、
    を含む、方法。
11. プロセッサー（８８）およびターゲット秘密鍵（７０）を有するターゲット・デバイス（１４）によって、ソース公開証明書（６６）を有するソース・デバイス（１２）との通信セッション（３２）を確立する方法（１１０）であって、
    前記ソース・デバイス（１２）から、ソース・セッション鍵（７４）を備えているセッション招待（８２）を受け取った（１１６）ときに、
    前記ターゲット秘密鍵（７０）を用いて前記セッション招待（８２）を解読し（１１８）、
    ターゲット・セッション鍵（７６）を発生し（１２０）、
    前記ソース・セッション鍵（７４）および前記ターゲット・セッション鍵（７６）を用いて、セッション鍵（８６）を発生し（１２２）、
    ターゲット・アドレス（７８）および前記ターゲット・セッション鍵（７６）を備えているセッション受入（８４）を、前記ソース・デバイス（１２）に送信し（２４）、前記ソース公開証明書（６６）を用いて前記セッション受入（８４）を暗号化し、
    前記ソース・デバイス（１２）から通信セッション（３２）の開始を受け取ったとき、前記ソース・アドレス（７８）で前記ソース・デバイス（１２）との通信セッション（３２）を開始し（１２６）、前記セッション鍵（８６）を用いて前記通信セッション（３２）を暗号化する、
    ように構成されている命令を前記プロセッサー（８８）上で実行するステップ（１１４）を備えている、方法。
12. 請求項１１記載の方法において、
    前記セッション招待が、前記ソース・デバイスが前記セッション招待を送った前記ソース・デバイスのソース・アドレスとは異なる候補ソース・アドレスを備えており、
    前記通信セッションを開始する命令が、前記候補アドレスにおいて前記ソース・デバイスとの通信セッションを開始し、前記セッション鍵を用いて前記通信セッションを暗号化する命令を含む、方法。
13. 請求項１１記載の方法において、
    前記ターゲット・デバイスが、少なくとも２つの候補ターゲット・アドレスにおいてアクセス可能であり、
    前記セッション受入が、前記少なくとも２つの候補ターゲット・アドレスを備えており、
    前記通信セッションが、前記ソース・デバイスによって、少なくとも１つの候補ターゲット・アドレスに対して開始される、方法。
14. 請求項１１記載の方法において、
    前記セッション招待が、ソース・ノンスを備えており、
    前記命令が、前記セッション招待を受け取ったときに、
    前記ソース・ノンスを検証し、
    前記ソース・ノンスを検証したとき、前記セッション受入を前記ソース・デバイスに送信するように構成されている、方法。
15. 命令を備えているコンピューター読み取り可能記憶媒体（１３２）であって、ソース・ユーザーによって動作させられ、証明書キャッシュ（１６４）とソース秘密鍵（６４）とを備え、少なくとも１つのソース・アドレス（７８）を有するソース・デバイス（１２）が、計算環境ホスト（１４２）によってホストされた配備可能な計算環境（１４４）において表されており、この計算環境（１４４）が、ターゲット・ユーザーによって動作させられ少なくとも１つのターゲット・アドレス（７８）を有するターゲット・デバイス（１４）も表し、前記ソース・デバイス（１２）が、前記ターゲット・デバイス（１４）を特定するターゲット公開証明書（７２）を含む少なくとも１つの公開証明書を備えている証明書サーバー（１６２）にアクセスすることができ、前記ソース・デバイス（１２）のプロセッサー（８８）上において前記命令を実行すると、
    前記証明書サーバー（１６２）から前記ターゲット・デバイス（１４）の前記ターゲット公開証明書（７２）を得て、
    前記証明書キャッシュ（１６４）に前記ターゲット公開証明書（７２）を格納し、
    ソース・セッション鍵（７４）を発生し、
    ソース・ノンス（１７２）を発生し、
    前記少なくとも１つのソース・アドレス（７８）と、前記ソース・セッション鍵（７４）と、前記ソース・ノンス（１７２）とを備えているセッション招待（８２）を、前記ターゲット・デバイス（１４）に送信し、前記ターゲット公開証明書（７２）を用いて前記セッション招待（８２）を暗号化し、
    前記ターゲット・デバイス（１４）から、前記少なくとも１つの候補ターゲット・アドレス（７８）と、ターゲット・セッション鍵（７６）と、ターゲット・ノンスと、ターゲット・ユーザー認証部とを備えているセッション受入（８４）を受け取ったときに、
    前記ソース秘密鍵（６４）を用いて前記セッション受入（８４）を解読し、
    前記ターゲット・ノンスを検証し、
    前記ターゲット・ユーザー認証部を用いて、前記ターゲット・ユーザーを検証し、
    前記ターゲット・ユーザーおよび前記ターゲット・ノンスを検証したときに、
    前記少なくとも２つの候補ターゲット・アドレス（７８）の中から少なくとも１つのターゲット・アドレス（７８）を選択し、
    前記ソース・セッション鍵（７４）および前記ターゲット・セッション鍵（７６）を用いて、セッション鍵（８６）を発生し、
    前記選択したターゲット・アドレス（７８）で前記ターゲット・デバイス（１４）との通信セッション（３２）を開始し、前記セッション鍵（８６）を用いて前記通信セッション（３２）を暗号化し、
    前記証明書キャッシュ（１６４）から前記ターゲット公開証明書（７２）を読み出すことによって、前記ターゲット・デバイス（１４）との後続の通信セッション（３２）を確立する、
    ことによって前記ターゲット・デバイス（１４）との通信セッション（３２）を確立する、コンピューター読み取り可能記憶媒体。

Images