低レイテンシーのピア・セッション確立
ソース・デバイスおよびターゲット・デバイスが安全な通信セッションを形成しようとしても、これによって、インターネットのような信頼性のないネットワークを通じて、暗号化されたメッセージを送信する場合がある。しかしながら、通信セッションの確立における多くのメッセージの交換は、特に、多くの通信セッション(例えば、ピア・ツー・ピア通信セッション)を特徴とするシナリオでは、かなりのレイテンシーや計算リソースを要する可能性がある。ソース・デバイスからターゲット・デバイスに送信されるメッセージの2回の交換のみで、または1つのメッセージだけでも通信セッションの開始を可能にするような、通信セッション開始技法を考案することができる。これらの技法の実施形態の中には、通信セッションの開始において必要とされるメッセージの数を増やすことなく、中間者攻撃を検出するための公開証明書による認証や、反射攻撃を検出するためのノンスの包含というような、有利なセキュリティー機構を含めることができるものもある。
【発明の詳細な説明】
【背景技術】
【0001】
[0001] 多くのコンピューター使用のシナリオでは、互いにアクセス可能な2つ以上のデバイスが(例えば、有線またはワイヤレス・ネットワークを通じて)通信セッションを確立しようとすることがある。この通信セッションは、機密情報の傍受または漏洩を防止するために暗号化されており、および/または各デバイスが、受信したメッセージが他のデバイスによって発生されたことを検証できるように、通信セッションを認証する。例えば、RSAアルゴリズムのような、非対称暗号鍵交換アルゴリズムを実装すると、セッションに対する公開鍵を交換することを2つのデバイスに可能にすることができる。公開鍵は、対応する秘密鍵と合わせて用いられ(そして秘密に保持する)、通信セッションの間における暗号化および認証された通信を可能にすることができる。
【0002】
[0002] 2つのデバイスがこのような通信セッションを確立しようとするとき、サポートされているプロトコルを特定し、鍵を交換するために、ハンドシェーク・プロトコルを用いることができる。例えば、トランスポート・レイヤー・セキュリティー(TLS)プロトコルは、ハンドシェークを開始するため、暗号アルゴリズム、圧縮アルゴリズム、公開鍵、および認証証明書を開示し選択するため、ならびに取り決められたアルゴリズムを用いて通信の開始を通知するために、各デバイスによって実装することができる。一旦通信セッションの詳細が決定されたなら、デバイスは安全な接続を確立することができ、暗号化されたチャネルを通じて通信を開始することができる。
【発明の概要】
【0003】
[0003] この摘要は、詳細な説明の章において以下で更に説明する概念から選択したものを紹介するために設けられている。この摘要は、特許請求する主題の主要な特徴や必須の特徴を特定することを意図するのではなく、特許請求する主題の範囲を限定するために用いられることを意図するのでもない。
【0004】
[0004] トランスポート・レイヤー・セキュリティー(TLS)プロトコルを含む多くのハンドシェーク・プロセスは、通信セッションのロジスティック(logistics)の取り決めにおいて、幅広いロバスト性を許容する。しかしながら、このロバスト性のために、実装の複雑さや、その結果起こり得るセキュリティー不備というような、種々のコストがかかる可能性がある。また、デバイスは取り決めを完了するために様々なメッセージを交換しなければならないこともあり、各メッセージが、デバイスを接続するネットワークを往復しなければならない場合がある。この情報交換は、特に、低帯域幅、高レイテンシー、および/または信頼性のない接続を経るときには(例えば、メッセージの欠落を伴うかもしれない低受信セルラー・ネットワーク)、時間がかかる可能性があり、または障害を受けやすい可能性がある。
【0005】
[0005] 代替技法では、通信セッションを確立するために、比較的少数のメッセージ交換で済む場合もある。本明細書において開示するこのような1組の技法では、ソース・デバイスからターゲット・デバイスへの、セッション招待を表す1組の情報(例えば、1つのメッセージ)の配信を伴い、このメッセージは、ソース・デバイスの1つ以上の候補アドレス、およびソース・デバイスによって発生されたセッション鍵を指定する。クライアント・デバイスは、このセッション招待を受信することができ、通信セッションの確立を許容することを選択する場合(そして、セッション招待の詳細を検証する、例えば、デバイスおよび/またはユーザーを、通信セッションを開始したものとして認証する場合)、それ自体のセッション鍵、およびターゲット・デバイスの1つ以上の候補アドレスと共に回答することができる。ソース・デバイスおよびターゲット・デバイスは、各々、ソース・セッション鍵およびターゲット・セッション鍵を用いて、セッション鍵を確立し、双方のデバイスはこのセッションのためにセッション鍵を用いることができる。安全を確保した通信セッションを可能にするのに十分な1組の情報を交換した後、ソース・デバイスは通信セッションを開始することができ、ターゲット・デバイスは同じように回答することができる。このように、デバイス間で交換するメッセージの数を減少させて(おそらくは最小数)、安全な通信セッションを確立ことができ、これによって通信セッションを確立する際のレイテンシーや障害の可能性を低減することができる。この方式において、他のセキュリティー機構を実装し含ませることもできる。例えば、安全な通信セッションが確立されるまで、ソース・デバイスおよびターゲット・デバイスの実際のアドレスを隠しておくことが可能なこともある。例えば、異なるアドレス(匿名にしたアドレスのような)をハンドシェーク・プロセスの間用いることもでき、その間、デバイスは、通信セッションの間に用いられる、各アドレスの他の(非匿名)アドレスを安全に送信することができる。
【0006】
[0006] 以上の目的および関係する目的の遂行のために、以下の説明および添付図面は、ある種の例示的態様および実施態様について明示する。これらは、1つ以上の態様を採用することができる種々の方法の内僅かなものを示すに過ぎない。本開示の他の態様、利点、および新規な特徴は、以下の詳細な説明を、添付図面と合わせて検討することにより、明白になるであろう。
【図面の簡単な説明】
【0007】
【図1】図1は、ソース・デバイスとターゲット・デバイスとの間における非対称暗号鍵対の発生および交換を描写するシナリオ例の図である。
【図2】図2は、安全な通信セッションを通じてソース・デバイスとターゲット・デバイスとの間においてメッセージを交換するための、非対称暗号鍵対の使用を描写するシナリオ例の図である。
【図3】図3は、トランスポート・レイヤー・セキュリティー(TLS)プロトコルの一バージョン例によるソース・デバイスとターゲット・デバイスとのハンドシェーク反復の図である。
【図4】図4は、本明細書において紹介する技法による、ソース・デバイスとターゲット・デバイスとのハンドシェーク反復の図である。
【図5】図5は、ソース・デバイスによってターゲット・デバイスとの通信セッションを確立する方法の一例を示すフロー・チャートである。
【図6】図6は、ターゲット・デバイスによってソース・デバイスとの通信セッションを確立する方法の一例を示すフロー・チャートである。
【図7】図7は、本明細書において明示する装備の内1つ以上を具体化するように構成されているプロセッサー実行可能命令を備えているコンピューター読み取り可能媒体の一例の図である。
【図8】図8は、本明細書において明示する技法にしたがって通信セッションを確立することができる1組のデバイスを、配備可能な計算環境内において表した図である。
【図9】図9は、通信セッションを確立している間にソース・デバイスおよび/またはターゲット・デバイスによってアクセスすることができる公開証明書を格納するように構成されている証明書サーバーを描写するシナリオ例の図である。
【図10】図10は、ソース・デバイスとソース・ノンスを利用するターゲット・デバイスとの間における通信セッションの確立を描写するシナリオ例の図である。
【図11】図11は、本明細書において明記する装備の内1つ以上を実現することができる、計算環境の一例を示す。
【発明を実施するための形態】
【0008】
[0018] これより図面を参照して、特許請求する主題について説明する。図面では、同様の参照番号は全体にわたって同様のエレメントを指すために用いられている。以下の記載では、説明の目的上、特許請求する主題の完全な理解を得るために、多数の具体的な詳細について明記する。しかしながら、特許請求する主題は、これらの具体的詳細がなくても、実施できることは明白であろう。一方、特許請求する主題を記述しやすくするために、構造およびデバイスをブロック図で示すこととする。
【0009】
[0019] 計算分野における多くのシナリオでは、インターネットを通じて接続されている2つのコンピューター、またはワイヤレス・ローカル・ネットワークを通じて接続されている2つのワイヤレス通信デバイスというような、ピア・デバイス間における通信セッションの確立を伴う。これらのシナリオでは、デバイスは、これらのデバイス間における通信が暗号化されるように、安全なチャネルを通じて通信セッションを確立しようとすることがある。更に、これらのデバイスは、パスワードを互いに共有しない方法でデーターを暗号化しようとすることもできる。これは、安全な通信セッションが確立される前では、パスワードを安全に交換することが困難である場合があるからである。つまり、デバイスは、暗号化されていないメッセージを送ることによって、物理的ネットワークを通じて通信することができるが、「オーバーレイ」ネットワークを案出する(devise)ことを望むこともあり、これによって、暗号化されたメッセージを、物理的ネットワークを通じて送ることおよび受信することができるが、各デバイスによってメッセージを自動的に暗号化および解読することもでき、これによって、各デバイス上で実行しているアプリケーションに、傍受からの安全を確保したデバイス間の仮想ネットワークを提示することができる。
【0010】
[0020] 図1および図2は、合わせて、安全に通信セッションを確立し利用しようとするソース・デバイス12(例えば、通信セッションの要求を発するクライアント)とターゲット・デバイス14(例えば、通信セッションを開始する要求を受信するサーバー)とを描写するシナリオ例を示す。図1のシナリオ例10では、ソース・デバイス12およびターゲット・デバイス14は、RSAアルゴリズムのような、非対称鍵暗号を特徴とする暗号アルゴリズム16の使用によって、通信セッションの安全を確保する際に必要となる何らかの情報を発生し交換する。このアルゴリズムは、公開鍵および秘密鍵から成る暗号鍵対を発生するように構成されている。この暗号鍵対は、次の2つの特性を有する。公開鍵を用いて秘密鍵を特定することはできない。公開鍵を用いて暗号化されたメッセージは、秘密鍵を用いることによってのみ、解読することができる。追加の利点として、秘密鍵を用いて、メッセージに暗号的に「署名」することもでき、公開鍵を用いてこの署名を検証し、こうしてメッセージの作者を秘密鍵の保持者として検証することができる(そして、メッセージの内容を検証することができる)。安全な通信セッションに備えるために、ソース・デバイス12は暗号アルゴリズム16を利用して、ソース秘密鍵20およびソース公開鍵18を発生することができ、ターゲット・デバイス14は、暗号アルゴリズム16を利用して、ターゲット公開鍵22およびターゲット秘密鍵24を発生することができる。次いで、ソース・デバイス12は、ソース秘密鍵20を秘密に保持しつつ、ソース公開鍵18をターゲット・デバイス14に送信することができ、ターゲット・デバイス14は、ターゲット秘密鍵24を秘密に保持しつつ、ターゲット公開鍵22をソース・デバイス12に送信することができる。
【0011】
[0021] 図2は、傍受を防ぐ安全な方法でメッセージを交換しつつ、パスワードを共有するときのセキュリティー上の難点を回避し(例えば、通信セッションが確立される前に通信セッションを暗号化するために共有パスワードを交換することの難点)、そして特定のメッセージの作者および内容の検証を可能にするための、ソース・デバイス12およびターゲット・デバイス14によるこれらの鍵対の使用を描写するシナリオ例30を示す。図1のシナリオ例10と同様に、ソース・デバイス12は、ターゲット・デバイス14と共有されているソース公開鍵18と、秘密に保持されるソース秘密鍵20とを既に発生しており、ターゲット・デバイス14は、ソース・デバイス12と共有されているターゲット公開鍵22と、秘密に保持されるターゲット秘密鍵24とを既に発生している。このシナリオ例30では、ソース・デバイス12およびターゲット・デバイス14はこの時点で通信セッション32に入っており、このセッションを通じて、メッセージ34をソース・デバイス12からターゲット・デバイス14に安全に送信することができる。例えば、通信セッション32は、インターネットのような、信頼性のないネットワーク上でも確立することができ、傍受が行われる虞れがある。したがって、ソース・デバイス12およびターゲット・デバイス14は、第三者によって容易に読み取り、変更、または改ざんを行うことができない、暗号化されたメッセージだけを通信セッション32において配信する。
【0012】
[0022] このシナリオ例30では、ソース・デバイス12は最初にメッセージ34をターゲット公開鍵22で暗号化して、暗号化メッセージ36を生成する。また、ソース・デバイス12は、ソース秘密鍵20で暗号化メッセージ36に署名して、暗号化/署名付きメッセージ38を生成する。この暗号化/署名付きメッセージ38は、通信セッション32においてターゲット・デバイス14に送信することができる。第三者が通信セッション32上において傍受し、暗号化/符号付きメッセージ38を読み取れるのであっても、傍受されたメッセージ34を解読することはできない。何故なら、第三者はターゲット秘密鍵24にアクセスできないからである。対照的に、ターゲット・デバイス14が暗号化/署名付きメッセージ40を受信するときには、ターゲット・デバイス14はターゲット秘密鍵24を用いて、解読メッセージ40を生成する。加えて、ターゲット・デバイス14は、ソース公開鍵18を用いて、解読されたメッセージ40の作者を検証すること(即ち、ソース・デバイス12のような、ソース秘密鍵20に対してアクセスすることができるデバイスによって、解読されたメッセージ40が発生されたことを検証する)、および/または解読されたメッセージ40の内容が、通信セッション32において傍受しているかもしれない第三者によって変更されていないことを検証することができる。このシナリオ例30の結果、ターゲット・デバイス14は、解読され、検証されたメッセージ42を受信することになる。メッセージ42は、信頼性のないチャネル(インターネットのような)を通じて送信されているが、第三者による傍受および/または改ざんの確率は検証可能に低い。
【0013】
[0023] 図1および図2のシナリオ例において図示した技法は、暗号化されたメッセージを、安全な通信セッションにおいて交換するために用いることができるが、通信セッションを確立するために公開鍵情報を交換する態様には、追加の考慮を伴ってもよい。第1の例として、第三者が鍵交換の開始時に他方のデバイスの替え玉を演じることが決してできないように、一方のデバイスが他方のデバイスを認証することが望ましい場合がある。例えば、第三者が、ソース・デバイス12からの通信セッション32を確立する要求を傍受する可能性があり、ターゲット・デバイス14の替え玉を演じつつ、ソース・デバイス12との鍵交換に関与することがあり得る。更に、「中間者攻撃」(man-in-the-middle attack)では、第三者がソース・デバイスの替え玉を演じて、ターゲット・デバイス14との第2通信セッション32を確立することを要求することもあり得る。双方の通信セッション32を開始することに成功した場合、第三者は、一方の通信セッション32から受信した全てのメッセージ34を他方の通信セッション32に受け渡すことができ、これによって、ソース・デバイス12とターゲット・デバイス14との間に安全な通信チャネル32があるように装うが、これを通じて交換されるメッセージ34に完全にアクセスすることができるようになる。この可能性を低減するために、ソース・デバイス12は、例えば、ターゲット・デバイスの個別情報(identity)を、信頼されているソースから受信した公開証明書と突き合わせて検査し、ターゲット・デバイス14を特定することによって、ターゲット・デバイス14を認証しようとしてもよい。これは、第三者にはおそらく遂行することができない。
【0014】
[0024] 第2の例として、メッセージを解読できない第三者がなおもソース・デバイス12および/またはターゲット・デバイス14を「反射攻撃」(replay attack)によって攻撃することもあり得る。この場合、第三者は、通信セッション32に送信された1つ以上の暗号化され署名されたメッセージ38を取り込み、後にそれらを受信側デバイスに再送信する。受信側デバイスは、再生されたメッセージを、以前に受信したメッセージの複製として認識し損ねて、それに対して反応(act)する可能性がある。例えば、ソース・デバイス12がターゲット・デバイス14に、ソース・デバイス12を認証する通信セッション32を確立する要求を送る場合、第三者がこのメッセージを取り込んで、これをターゲット・デバイス14に異なるアドレスから再送信することもできる。第三者は要求の内容を解読することができなくても、別のアドレスからのこの要求の再送(ソース・デバイス12の暗号化された信任状を含む)がターゲット・デバイス14によって首尾良く受け入れられることによって、ターゲット・デバイス14に、ソース・デバイス12の替え玉を演じる第三者との通信セッション32を確立することを促すことができる。このようなセキュリティー・リスクの脅威を低減するために、ソース・デバイス12および/またはターゲット・デバイス14は、種々のメッセージにおいて、「ノンス」を含ませることができる。「ノンス」は、1回だけの識別子(ランダムに発生されることが多い)を含み、受信側デバイスが、送信されたメッセージを特定することができるように、メッセージ34、通信セッション32等に、区別できる特性を付加するために用いられる。
【0015】
[0025] これらおよびその他の考慮事項のために、単に鍵情報の交換だけでなく、関連情報も伴って、ソース・デバイス12とターゲット・デバイス14との間において通信セッション32を確立する特定の方法を考案するとよい。多くのシナリオにおいて、この通信セッション32を確立する方法は、「ハンドシェーク」と呼ばれることもあり、入念に構造化された対話的な方法で大量の情報交換を伴うことができる。
【0016】
[0026] 図3は、トランスポート・レイヤー・セキュリティー(TLS)暗号プロトコルにおいて用いられる、ソース・デバイス12とターゲット・デバイス14との間における通信セッションの「ハンドシェーク」確立を描写する、シナリオ例50を示す。この場合も、ソース・デバイス12はソース公開鍵18およびソース秘密鍵20を発生し、一方、ターゲット・デバイス14はターゲット公開鍵22およびターゲット秘密鍵24を発生する。TLSプロトコルにしたがう1つの比較的簡素化された「ハンドシェーク」対話処理によれば、ソース・デバイス12は、ターゲット・デバイス14に、「クライアント・ハロー」 (Client Hello)メッセージとしてエンコードされたメッセージ52を送ることによって、対話処理を開始する。この「クライアント・ハロー」メッセージは、クライアント12によって用いられるTLSのバージョンおよびソース・ノンスを特定する。ターゲット・デバイス14は、「サーバー・ハロー」(Server Hello)メッセージ52で応答する。「サーバー・ハロー」メッセージも、サーバー12によって用いられるTLSのバージョン、およびターゲット・ノンスを特定する。また、ターゲット・デバイス14は「証明書」メッセージ52も送る。「証明書」メッセージ52は、シナリオによっては、ターゲット公開鍵22を含むこともある。次いで、ターゲット・デバイス14は、ソース・デバイス12に、「サーバー・ハロー・済み」(Server Hello Done)メッセージ52を送る。ソース・デバイス12は、ソース公開鍵18を特徴付ける「クライアント鍵交換」メッセージ52で回答し、次いで「暗号仕様変更」メッセージ52を送る。このメッセージ52は、ソース・デバイス12によって送られる後続のメッセージ52が、交換された信任状にしたがって暗号化されることを示す。最後に、ソース・デバイス12は「終了」メッセージ52を送り、ソース・デバイス12がハンドシェーク対話処理の担当部分を完了したことを示す。ターゲット・デバイス14は、同様の「暗号仕様変更」メッセージ52および「終了」メッセージ52で応答することによって、ハンドシェーク対話処理を完了し、安全な通信チャネル32を確立する。
【0017】
[0027] この比較的簡略化したハンドシェーク対話処理では、ソース・デバイス12およびターゲット・デバイス14は大量の情報を交換する。この対話処理は、9つのメッセージ52の交換を伴うものであり、各メッセージは、発送側デバイスによって利用され受信側デバイスにおいて特定の挙動を引き起こす、特定のフォーマットを有する。ハンドシェーク対話処理の複雑さのために、複雑化が生じる確率が高くなることもあり得る(例えば、正しくない順序でメッセージ52が交換された場合における予期しない結果または望ましくない結果、メッセージ52の配信失敗、および第三者による誤用の機会)。更に、各メッセージ52は、ネットワーク上における送信遅延を伴い、大量のレイテンシーが発生して、ソース・デバイス12とターゲット・デバイス14との間における通信チャネル32の確立が遅れる可能性がある。メッセージ52の交換回数を減らすために何らかの技法を用いることもできるが(例えば、図3のシナリオ例50において、関係するメッセージ52を組毎に纏めることによって、メッセージの交換回数を4に減らすことができる)、通信チャネルの追加の機構(例えば、特定のTLSバージョンおよび特定の暗号アルゴリズム16の取り決め)が、ハンドシェークを完了するために交換されるメッセージ52の数を更に増やすこともあり得る。また、このようなメッセージの発生、送信、受信、デコーディング、および処理は、ソース・デバイス12およびターゲット・デバイス14に計算の負担がかかり、接続数が多いこともあるシナリオでは(例えば、大きな1組のピア・デバイス間におけるピア・ツー・ピア・データー転送では、1つのデバイスが数百もの接続を動的に確立し維持する場合もある)、接続を確立する遅延およびコンピューター使用負担が容認可能な範囲を逸脱する可能性がある。
【0018】
[0028] したがって、好適に低いレイテンシーおよびコンピューター使用コストで通信セッション32の確立を可能にすべく、またそれと共に本明細書において論ずる特徴の一部(例えば、中間者攻撃または反射攻撃に対する保護)を可能とするよう、ハンドシェーク対話処理の複雑さを低減することが望ましいと考えられる。レイテンシーを低減する技法の1つでは、通信セッション32の確立において交換されるメッセージ52の数を減らすことが必要となる。例えば、各デバイスが他のデバイスに安全な通信セッション32の担当部分を定義する1組の情報を配信することを許容することによって、通信セッション32が1回のメッセージ52の交換によって開始できるようにする、ハンドシェーク対話処理を考案することもできる。
【0019】
[0029] 図4は、ソース・デバイス12およびターゲット・デバイス14が1回の情報交換で通信セッション32を確立することができる、これらの技法の一実施形態を描写するシナリオ例60を示す。例えば、ソース・デバイス12およびターゲット・デバイス14は、プロセッサー88を有し、インターネットまたはローカル・エリア・ネットワーク(LAN)のような有線またはワイヤレス通信ネットワークを通じて通信するコンピューターを含むことができる。このシナリオ例60では、ソース・デバイス12は、ソース公開証明書66によって識別可能とすることができ、ターゲット・デバイス14は、ターゲット公開証明書72によって識別可能とすることができる。これらの公開証明書は、信頼されているサーバー(例えば、公開証明書を格納し、他のデバイスによるデバイスの認証を促進するように構成されている認証サーバー)によって維持されているとよいが、他の方法で交換することもできる。ソース公開証明書66は、例えば、ソース証明書公開鍵62を収容することができる。ソース証明書公開鍵62は、既知の認証されているソース・デバイス12によって秘密に保持されているソース証明書秘密鍵64に対応する。そして、ターゲット公開鍵72は、例えば、ターゲット証明書公開鍵68を収容することができる。ターゲット証明書公開鍵68は、既知の認証されているターゲット・デバイス14によって秘密に保持されているターゲット証明書秘密鍵70に対応する。これらの公開証明書に付随する鍵対は、他のデバイスとの通信セッション32の間は、メッセージ52を暗号化するためにデバイスによって用いることができないが、デバイスの認証のために保持しておくことができる。ソース・デバイス12は、ターゲット証明書公開鍵68を含むターゲット公開証明書72にアクセスすることができ、ターゲット・デバイス14は、ソース証明書公開鍵62を含むソース公開証明書66にアクセスすることができる。加えて、ソース・デバイス12は、特定のネットワーク上におけるソース・アドレス78、例えば、インターネットまたはLANアクセスのために割り当てられるTCP/IPアドレスを有することもでき、ターゲット・デバイス14は、同じネットワーク上におけるターゲット・アドレス80を有することができる。このアドレスは、各デバイスがメッセージ52を他のデバイスにアドレスするために用いることができる。例えば、ターゲット・アドレス80をターゲット公開証明書72において指定することができ、これによって、ターゲット・デバイス14がターゲット・アドレス80でアクセス可能であり且つターゲット証明書秘密鍵70を所有している場合に、ターゲット・デバイス14の個体情報を認証することができる。
【0020】
[0030] ソース・デバイス12がターゲット・デバイス14との通信セッション32を開始する要求を(例えば、ユーザーから)受けたとき、ソース・デバイス12は以下のようにしてハンドシェークを開始することができる。最初に、ソース・デバイス12はソース・セッション鍵70を発生することができる。ソース・セッション鍵70は、このターゲット・デバイス14とのこの通信セッション32のためにのみ、メッセージ52を暗号化および解読するために用いられる。ソース・デバイス12は、セッション招待82を用意することができる。セッション招待82は、ソース・セッション鍵74およびソース・アドレス78を含む。ソース・デバイス12は、ターゲット公開証明書72の中にあるターゲット証明書公開鍵68を用いてメッセージを暗号化することができる。次いで、セッション招待82は、通信セッション32を開始する要求として、ターゲット・デバイス14に送信され得る。
【0021】
[0031] ターゲット・デバイス14がセッション招待82を受け取ると、ターゲット・デバイス14は、ターゲット証明書秘密鍵70を用いて、セッション招待82を解読することができ、この通信セッション32を開始する招待を受け入れるか否か判断することができる。ターゲット・デバイス14がこの招待を受け入れる場合、ターゲット・デバイス14は次にターゲット・セッション鍵76を発生することができる。ソース・セッション鍵74およびターゲット・セッション鍵76を用いて、ターゲット・デバイス14は、最終的な通信セッション32を解読するために用いることができるセッション鍵86を発生することができる。例えば、セッション鍵86は、Rijndael鍵のような、メッセージの暗号化および解読双方を行うために用いることができる、対象鍵を含むことができる。対象鍵は、例えば、ソース・セッション鍵74およびターゲット・セッション鍵76の単純な連携を構成することもできる。ターゲット・セッション鍵76を発生した後、ターゲット・デバイス14は、ターゲット・セッション鍵76およびターゲット・アドレス80を含む、セッション受入84を発生することができる。セッション受入84は、ソース公開証明書66によってエンコードすることができる。次いで、ターゲット・デバイス14はセッション受入84をソース・デバイス12に送信することができる。セッション受入84を受け取ると、ソース・デバイス12も、ソース・セッション鍵74およびターゲット・セッション鍵76を用いて、セッション鍵86を発生することができる。次いで、ソース・デバイス12は、セッション鍵86によって暗号化された、ターゲット・アドレス14との通信セッションを開始することができ、図2のシナリオ例30におけるように、通信セッション32を通じてメッセージを交換することができる。このように、ソース・デバイス12およびターゲット・デバイス14は、2つメッセージ52のみで、通信セッション32を開始するための関連情報を交換することができ、これによって、ハンドシェークのレイテンシーおよびコンピューター使用負担を軽減することができる。加えて、ターゲット公開証明書72の使用により、ソース・デバイス12に対するターゲット・デバイス14の個体情報の認証を容易にする一方、ハンドシェークにおいて追加メッセージ52の交換を必要としない。更に、これらの技法の改良では(図4には示されていない)、通信セッション32を確立するのに要するレイテンシーは、ターゲット・デバイス14が、セッション招待82を受け取ったときに、ソース・デバイス12との通信セッションを開始する場合、更に短縮することもできる。この実施形態では、セッション受入84は、確立された通信チャネル内において送ることができ、これによって、1つのメッセージ52の交換に対するハンドシェークを減らし、ハンドシェークのレイテンシーおよびコンピューター使用負担を軽減することができる。
【0022】
[0032] 図5は、これらの技法の第1実施形態を示し、プロセッサー88およびソース・アドレス78、ならびにソース公開鍵62およびソース秘密鍵64を有するソース・デバイス12によって通信セッション32を確立する方法の一例90として紹介する。したがって、ソース・デバイス12は、ソース公開鍵62を含むソース公開証明書66によって表される。通信セッション32は、ターゲット公開証明書72およびターゲット・アドレス80を有するターゲット・デバイス14と確立される。この方法例90は、例えば、ソース・デバイス12のメモリーに格納されている1組の命令として具体化することができる。方法例90は、92において開始し、本明細書において紹介した技法を実施するように構成されている命令をプロセッサー88上で実行する(94)ステップを含む。即ち、ソース・セッション鍵を発生する(96)ように、命令を構成することができる。また、命令は、ソース・アドレス78およびソース・セッション鍵74を含むセッション招待82を、ターゲット・デバイス14に送信する(98)ように構成することもでき、ここで、セッション招待82は、ターゲット公開証明書72(例えば、ターゲット公開証明書72に含まれているターゲット証明書公開鍵68)を用いて暗号化される。また、命令は、ターゲット・デバイス12から、ターゲット・アドレス80およびターゲット・セッション鍵76を含むセッション受入84を受け取ったとき(100)に、ソース公開証明書66を用いてセッション受入84を解読し(102)、ソース・セッション鍵74およびターゲット・セッション鍵76を用いて、セッション鍵86を発生する(104)ように構成することもできる。最後に、命令は、セッション受入84において指定されているターゲット・アドレス80において、ターゲット・デバイス14との通信セッション32を開始する(106)ように構成することもでき、通信セッション32は、セッション鍵86を用いて暗号化される。セッション招待82の送信およびセッション受入84の受信によってターゲット・デバイス14と鍵情報を交換し終えた後、方法例90は、メッセージ52の数を減らして、ターゲット・デバイス14との通信セッション32を確立し、こうして108において終了する。
【0023】
[0033] 図6は、これらの技法の第2実施形態を示し、プロセッサー88、ターゲット公開証明書72、およびターゲット・アドレス80を有するターゲット・デバイス14によって、ソース公開証明書66を有するソース・デバイス12との通信セッション32を確立する方法の一例110として図示する。方法例110は、例えば、ターゲット・デバイス14のメモリーに格納されている1組の命令として具体化することができる。方法例110は、112において開始し、本明細書において紹介した技法を実施するように構成されている命令をプロセッサー88上で実行するステップ114を含む。更に具体的には、命令は、ソース・アドレス78およびソース・セッション鍵74を含むセッション招待82をソース・デバイス12から受け取ったとき(116)、ターゲット公開証明書72を用いてセッション招待82を解読し(118)、ターゲット・セッション鍵76を発生する(120)ように構成することができる。ソース・セッション鍵74およびターゲット・セッション鍵76を用いて、セッション鍵86を発生する(122)ように、命令を構成することができる。また、ターゲット・アドレス80およびターゲット・セッション鍵76を含むセッション受入84をソース・デバイス12に送信する(124)ように命令を構成することもでき、セッション受入84は、ソース公開証明書66を用いて暗号化される。最後に、ソース・デバイス12から通信セッション32の開始を受け取ったときに、ソース・アドレス76においてソース・デバイス12との通信セッション32を開始する(124)ように、命令を構成することができ、通信セッション32は、セッション鍵86を用いて暗号化される。セッション招待82の受信およびセッション受入84の送信によってソース・デバイス12と鍵情報を交換し終えた後、方法例110は、メッセージ52の数を減らして、ソース・デバイス12との通信セッション32を確立し、こうして126において終了する。
【0024】
[0034] 更に他の実施形態は、本明細書において紹介した技法を応用するように構成されているプロセッサー実行可能命令を備えているコンピューター読み取り可能媒体を含む。これらの方法において考案することができるコンピューター読み取り可能媒体の一例を図7に示す。図7では、実施態様130は、コンピューター読み取り可能媒体132(例えば、CD−R、DVD−R、またはハード・ディスク・ドライブのプラッター)を備えており、その上にコンピューター読み取り可能データー134がエンコードされている。このコンピューター読み取り可能データー134は、一方、本明細書において明記した原理にしたがって動作するように構成されている1組のコンピューター命令136を構成する。このような実施形態の1つでは、プロセッサー実行可能命令136は、図5の方法例90のような、ターゲット・デバイスとの通信セッションを確立する方法を実行するように構成することができる。このような実施形態の他の1つでは、プロセッサー実行可能命令136は、図6の方法例110のような、ソース・デバイスとの通信セッションを確立する方法を実行するように構成することができる。本明細書において紹介した技法にしたがって動作するように構成されている、多くのこのようなコンピューター読み取り可能媒体を、当業者によって考案することができる。
【0025】
[0035] 本明細書において論じられた技法は、多くの態様において様々な変形と合わせて考案することができ、一部の変形は、これらおよびその他の技法の他の変形に関して、追加の利点を提供することおよび/または欠点を低減することができる。更に、一部の変形を組み合わせて実施することもでき、組み合わせの中は、相乗的協同による利点の増大および/または欠点の減少を特徴とするものもある。これらの変形は、種々の実施形態に対して個々の利点および/または相乗的利点を与えるように、これらの実施形態において組み込むことができる(例えば、図5の方法例90および図6の方法例110)。
【0026】
[0036] これらの技法の実施形態間で多様に変更することができる第1の態様は、本明細書において紹介したこれらの技法を利用することができるシナリオに関する。第1の例として、本技法は、インターネットまたはローカル・エリア・ネットワーク(LAN)のような有線ネットワーク、あるいはセルラー・ネットワークのようなワイヤレス・ネットワークを通じて接続されているコンピューター間において効率的に(そして低レイテンシーで)安全な通信セッションを確立するために利用することができる。また、本技法は、ユニバーサル・シリアル・バス(USB)ハブのような有線またはワイヤレス・デバイス・ネットワーク、あるいはBluetoothのようなパーソナル・エリア・ネットワーク(PAN)を通じて接続されているデバイス間において効率的に(そして低レイテンシーで)安全な通信セッションを確立するためにも利用することができる。また、これらのデバイスは、同じユーザーによってまたは異なるユーザーによって動作させることもできる。第2の例として、本技法は、クライアントとして動作するソース・デバイス12が、サーバーとして動作するターゲット・デバイス14に接触しようとするサーバー/クライアント構成、およびソース・デバイス12およびターゲット・デバイス14が分散データー共有方式においてピアとして動作するピア・ツー・ピア構成を含む、多くのタイプの通信セッションを確立するために利用することができる。これらの技法の更に他の実施形態では、2つよりも多いデバイスを接続することができ、本明細書において論じられた技法の何らかの変形を用いて、例えば、ソース・デバイス12および1組のターゲット・デバイス14間におけるマルチキャスト通信セッション(各々が同じ共有鍵対を用いるか、各々が個々の鍵対を有する等)を確立することができる。第3の例として、非対称暗号鍵対を発生するために、そして鍵対を用いてメッセージ52を暗号化および解読するために、多くのタイプの暗号アルゴリズムを用いることができる。
【0027】
[0037] これらの技法を利用することができる特定的なシナリオの1つでは、配備可能な計算環境において表されているデバイス間におけるメッセージの交換に関係する。多数のデバイス間において、一貫性があり、配備可能で、その上拡張可能な方法で、計算環境にアクセスする技法を開発する試みが最近行われている。また、これらの技法は、協同するデバイス間に1組の共通アプリケーションを提供し、更にこのようなデバイス間においてアプリケーションの調達、インストール、使用、およびアンインストールを管理する集中サービスを提供することも追求する。この1組のアプリケーションは、種々のデバイス間において必ずしも同一ではない。例えば、ワークステーションであれば、セル・フォン・デバイス上ではしかるべく実行することができない高性能アプリケーション(例えば、写真編集ソフトウェア、およびグラフィック満載のゲーム)を内蔵することができ、セル・フォン・デバイスは、携帯用でないワークステーションには関係のない、携行に関するアプリケーション(例えば、GPSに基づく地図作成ソフトウェア)を含むことができる。しかしながら、多くのアプリケーションおよびそれに関係するデーター・オブジェクトは、このようなデバイス間で共有することができ(例えば、ユーザーのカレンダー・オブジェクトを管理するように構成されているカレンダー・アプリケーション)、このようなデバイス間においてアプリケーションおよびデーター・オブジェクトの配布および同期を可能にするように、計算環境を適応させることができる。したがって、コンピューター・システムは、1組のデバイス間において計算環境の配備を可能にするように表すことができると有利であることが認めることができよう。
【0028】
[0038] このような技法の1つでは、1組のアプリケーションと、アプリケーション・リソースと、それらによって用いられるデーター・オブジェクトとを含む計算環境は、デバイスに付与されそのデバイスの能力に応じた機能を果たすような形で表される。オブジェクトは、ユーザーによって作成されたユーザー・ファイルおよびデーターというような、コンピューター・システムのデーター・オブジェクト、ならびにユーザーの計算環境を構成する無数のデバイスの表現を含む。このように表された計算環境は、いずれのデバイスに付与することもでき、そのデバイスの能力に適した方法で機能することができる。例えば、ワークステーションであれば、ロバストな汎用計算環境として情報を処理することができ、一方、公衆ワークステーションであれば、(例えば、ユーザーのセッション終了時には破棄されてもよい仮想マシンとして)ウェブ・ブラウザーを通じて異なる計算環境体験をもたらすことができ、携帯電話であれば、もっと軽いインターフェースを設けて、携帯電話関連情報(例えば、連絡先、カレンダー、およびナビゲーション・データー)にもっと素早くアクセスできるようにすることもできる。更に、情報集合に対する更新(例えば、好みの変更、およびその中に収容されているデーター・ファイルに対する更新)を、情報集合の基幹ソースに適用し、これによって、その情報集合が配信される他の全てのデバイスに更新を伝えることができる。
【0029】
[0039] 図8は、1つのこのようなシナリオ140を示す。この場合、オブジェクト階層144を格納し管理することができる計算環境ホスト142によって、計算環境をホストすることができる。計算環境ホスト142は、携帯電話デバイス146、パーソナル・ノートブック・コンピューター150、および公衆ワークステーション154のような、種々のデバイスに成り代わって、更に、異なるアクセス特権を有する異なるタイプのユーザーに成り代わって、異なる方法でオブジェクト階層144を与えることができる。計算環境に対する更新は、逆に計算環境ホスト142に伝えることができ、他のデバイスと自動的に同期させることができる。したがって、計算環境をクラウド計算アーキテクチャとして考案し、提示することができる。クラウド計算アーキテクチャは、同一の計算環境への協同ポータル(デバイス特定の特性を有する)のメッシュを形成する全てのデバイス(「クライアント」)にわたって一貫性がある機能として表現されている、デバイスに独立した表現(「クラウド」)を含む。本明細書において論じられた技法に関して、オブジェクト階層144において表されているデバイスは、本明細書において論じられた技法を用いて、安全かつ効率的に通信セッション32を確立することができる。当業者であれば、本明細書において論じられた技法を利用できる多くのシナリオを考案することができよう。
【0030】
[0040] これらの技法の実施形態間で多様に変更することができる第2の態様は、ターゲット・デバイス14のターゲット公開証明書72を得る方法に関する。ソース・デバイス12は、このターゲット公開証明書72を用いて、セッション招待82を暗号化することができる。一実施態様では、ターゲット公開証明書72は、ターゲット公開証明書72を含む種々の公開証明書を格納するように構成することができる証明書サーバーから得ることができる。例えば、大きな組織は、ローカル・エリア・ネットワーク(LAN)を通じてアクセス可能なコンピューターというような、その組織によって用いられる種々の既知のデバイスの公開証明書を収容する証明書サーバーを実装することができる。このような実施形態の1つにおいて、このようなデバイスが表される計算環境ホスト142は、オブジェクト階層144の中にターゲット公開証明書72を格納するように構成することができ、オブジェクト階層144は、ソース・デバイス12に対して容易にアクセス可能であるとよい。ネットワーク上で動作するソース・デバイス12は、最初に証明書サーバーに問い合わせてターゲット・デバイス14の公開証明書を求め、次いで、提供された公開証明書を用いてセッション招待82を暗号化することによって、特定のターゲット・デバイス14との通信セッションを確立しようとすることができる。こうすることによって、この技法は、対応する応答を受け取ったときに、ターゲット・デバイス14を認証する。これは、提供されたターゲット公開証明書72に対応するターゲット証明書秘密鍵70にアクセスしなければ、他のデバイスはセッション招待82を解読することができないからである。しかしながら、証明書サーバーはセキュリティーの弱点を表すこともある。何故なら、第三者によって能力が弱められた場合、多数のデバイスの認証が第三者によって改ざんされる虞れがあり、加えて、証明書サーバー自体を認証しなければならないこともあるからである。代替技法として、種々のデバイスのターゲット公開証明書72を、いずれかの適したチャネルによって、例えば、電子メール、ファイル転送、または物理的な記憶媒体によって、ソース・デバイス12に提供してもよい。ソース・デバイス12がどのようにしてターゲット公開証明書72へのアクセスを達成するかには関係なく、本明細書において論じられた技法は、それに応じて利用することができる。逆に、実施形態によっては、ターゲット・デバイス14が既知のソース・デバイスのみとの通信セッション32を確立するように構成されている場合、ターゲット・デバイス14はソース公開証明書(同様に証明書サーバー162によって提供することができる)を参照して、ハンドシェークの間にソース・デバイス12を認証することができる。
【0031】
[0041] これらの技法の更なる改良は、公開証明書のキャッシングに関する。例えば、ソース・デバイス12が証明書キャッシュを備えていることもあり、この場合、通信セッション32の開始中に(例えば、証明書サーバーから)得られたターゲット公開証明書72を格納することができ、同じターゲット・デバイス14との後続の通信セッションを開始する間に、ターゲット・デバイス14を再度認証するために、後に利用することもできる。更に、このキャッシングは、特定のデバイス14のターゲット公開証明書72の冗長な読み出しを減らすことによって、これらの技法の効率を高めることもできる。また、例えば、それぞれのターゲット公開証明書72の有効期間を確定し、期限が切れたターゲット公開証明書72を証明書キャッシュから削除することによって、セキュリティーを強化するためにも、キャッシュを維持するとよい。
【0032】
[0042] 図9は、本明細書において論じられた技法と合わせて、この第2の態様の変形の一部を描写するシナリオ例160を示す。このシナリオ例160では、特定のターゲット・デバイス14のターゲット公開証明書72を含む公開証明書を格納するように、証明書サーバー162を構成することができる。証明書サーバー162にアクセスすることができるソース・デバイス12は、ターゲット・デバイス14との第1通信セッション166を開始しようとすることがあり、したがって、ターゲット公開証明書72を得るために証明書サーバー162に問い合わせることができる。しかしながら、ソース・デバイス12も、公開証明書を格納するように構成されている証明書キャッシュ164を備えることができ、ターゲット・デバイス14のターゲット公開証明書72を得たときに、ソース・デバイス12はターゲット・デバイス14のターゲット公開証明書72を証明書キャッシュ164に格納するように構成することができる。次いで、ソース・デバイス12は、第1通信セッション166を確立しつつ、ターゲット・デバイス14を認証するために、ターゲット公開証明書を利用することができる。その後(例えば、第1通信セッション166が終了した後)、ソース・デバイス12がターゲット・デバイス14との第2通信セッション168を開始しようとすることがある。証明書サーバー162からターゲット公開証明書72を再度取得するのではなく、ソース・デバイス12はターゲット公開証明書72を証明書キャッシュ164から読み出すことができ、このターゲット公開証明書72は、第2通信セッション168を確立している間に、ターゲット・デバイス14を再度認証するために利用することができる。したがって、このキャッシングは、ターゲット公開証明書72の冗長な取得を回避することによって、第2通信セッション168を確立する効率を高めることができる。当業者であれば、本明細書において論じられた技法を実施しつつ、公開証明書の配信および使用を実現する多くの技法を考案することができよう。
【0033】
[0043] これらの技法の実施形態間で多様に変更することができる第3の態様は、ソース・デバイス12とターゲット・デバイス14との間において確立される通信セッション32を暗号化するために用いられるセッション鍵86を生成する(develop)方法に関する。第1の例として、セッション鍵86は対称鍵を含む場合があり、対称暗号アルゴリズム(例えば、Rijndaelアルゴリズム)にしたがってランダムに発生し利用することができ、これによって、メッセージを暗号化および解読するために、同じ鍵が用いられるようになる。対称鍵は、通信セッション32の安全を確保するために望ましいと考えられる。何故なら、このような鍵を用いるコンピューター使用負担は、非対称鍵を用いる場合よりも、かなり低くすることができるからである。次いで、セッション鍵86を発生することができ、このとき、例えば、ランダムに発生した鍵(ランダムに選択した整数または文字列のような)を含むソース・セッション鍵74を発生し、第2のランダムに発生した鍵を含むターゲット・セッション鍵76を発生し、そして第1のランダムに発生した鍵および第2のランダムに発生した鍵を用いて、対称ランダム・セッション鍵を発生する(例えば、ランダムに発生した鍵を繋げることによって)。
【0034】
[0044] 第2の例として、1組のセッション鍵を発生することもできる。対称鍵は非対称鍵よりも容易に解読される虞れがあるので、通信セッション32の間1組の鍵を順番に用いる(rotate through)ことが望ましい場合がある(例えば、ソース・デバイス12およびターゲット・デバイス14が、セッション鍵集合において周期的に次の鍵に切り替わるように構成されている場合)。例えば、セッション鍵86は、少なくとも2つのセッション鍵を備えているセッション鍵集合として発生することができ、その各々は他方のセッション鍵とは異なるものの、ソース・セッション鍵およびターゲット・セッション鍵を用いて発生される(異なる方法で)。開始時に、最初に第1セッション鍵を用いて通信セッション32を暗号化することができ、デバイスは、何らかの方法で(例えば、周期的に)第2セッション鍵をセッション鍵集合から選択し、この第2セッション鍵を用いて通信セッション32を暗号化するように構成することができる。当業者であれば、本明細書において論じられた技法を実施しつつ、セッション鍵を発生し使用する多くの方法を考案することができよう。
【0035】
[0045] これらの技法の実施形態間で多様に変更することができる第4の態様は、通信セッションを開始する方法に関する。第1の例として、ソース・デバイス12が、セッション受入84を受け取った後に、ターゲット・デバイス14との通信セッション32を開始することができる。第2の例として、ターゲット・デバイス14が、代わりに、セッション受入84を送った後に、ソース・デバイス12との通信セッション32を開始することもできる。第3の例として、ターゲット・デバイス14が、セッション受入84を送る前であっても、通信セッション32を開始することもでき、代わりに、通信セッション32を確立した後にセッション受入84を送ることができる。この技法は、1つのメッセージのみを送った後に、これらのデバイスに通信セッションを効果的に確立させることができる。例えば、ソース・デバイス12はセッション招待82をターゲット・デバイス14に送ることができ、次いで、通信セッション32内において続けるためにセッション受入84を用いて、ターゲット・デバイス14による通信セッション32の開始を待つように構成することができる。当業者であれば、本明細書において論じられた技法を実施しつつ、デバイス間において通信セッションを開始する多くの方法を考案することができよう。
【0036】
[0046] これらの技法の実施形態間で多様に変更することができる第5の態様は、異なるユーザーが動作させるデバイス間における通信セッション32の確立を伴うシナリオに関する。デバイスが同じユーザーによって動作させられる場合、個別情報に基づくセキュリティーの懸念は比較的少なくて済むと考えられる。しかし、ソース・デバイス12がソース・ユーザーによって動作させられ、ターゲット・デバイス14がターゲット・ユーザーによって動作させられる場合、一方または双方のユーザーが、通信セッション32を開始する前に、他方のユーザーの個人情報を認証することを望む場合がある。例えば、ターゲット・ユーザーが、ソース・デバイス14のソース・ユーザー12の内特定の1組とだけデーターを共有するように、ターゲット・デバイス14を構成しておくことができ、したがって、知らないユーザーまたは知っているが認証されていないユーザーとの通信セッション32を確立することを拒否するように、ターゲット・デバイス14を構成することができる。このような実施形態の1つでは、ソース・デバイス12によって提供されるセッション招待82は、パスワードまたは暗号署名のような、ソース・ユーザー認証部を含むことができ、この認証部がソース・デバイス12のソース・ユーザーの個体情報を認証することができる。したがって、ターゲット・デバイス14は、ソース・ユーザー認証部を用いてソース・ユーザーを認証し、ソース・ユーザーを認証した後に、ソース・デバイス12との通信セッション32を開始するように構成することができる。逆に、ターゲット・デバイス14によって提供されるセッション受入84は、ターゲット・ユーザー認証部を含むことができ、このターゲット・ユーザー認証部がターゲット・デバイス14のターゲット・ユーザーの個体情報を認証することができ、ソース・デバイス12は、ターゲット・ユーザー認証部を用いてターゲット・ユーザーを検証し、ターゲット・ユーザーを認証した後に、ターゲット・デバイス14との通信セッション32を開始するように構成することができる。当業者であれば、本明細書において論じられた技法を実施しつつ、ユーザーを認証する多くの方法を考案することができよう。
【0037】
[0047] これらの技法の実施形態間で多様に変更することができる第6の態様は、ソース・デバイス12およびターゲット・デバイス14の一方または双方が多数のアドレスでアクセス可能であるシナリオに関する。第1のこのようなシナリオでは、ソース・デバイス12およびターゲット・デバイス14が、Bluetoothネットワークのようなパーソナル・エリア・ネットワーク(PAN)、802.11(WiFi)ネットワークのようなローカル・エリア・ネットワーク(LAN)、およびインターネットのようなワイド・エリア・ネットワーク(WAN)というような、多数のネットワークに跨がって互いに同時にアクセスすることができる場合がある。また、物理的ネットワークは、ノードがサーバー、クライアント、および/または他のピアに対して1つ以上のピアとして動作することができるスーパー・ピア・ネットワークのような、他のタイプのネットワークも備えることができる。第2のシナリオでは、ある範囲のアドレスにおいてターゲット・デバイス14がアクセス可能であり、ソース・デバイス12にとって、他のアドレスと比較して、特定のアドレスを用いてターゲット・デバイス14に接触することが好ましい場合がある(例えば、ポート21を介してアクセスされるFTPチャネルの代わりに、ポート80を介してアクセスされるHTTPチャネル)。これらおよびその他のシナリオでは、ソース・デバイス12がターゲット・デバイス14に(例えば、セッション招待82の一部として)、ソース・デバイスがアクセスすることができる1組のソース候補アドレスを開示することができ、通信セッション32を確立している間に、ターゲット・デバイス14はソース候補アドレスの中からソース・アドレス76を選択することができ、この選択したソース・アドレス76との通信セッション32を開始することができる。逆にまたは加えて、ターゲット・デバイス14がソース・デバイス12に(例えば、セッション受入84の一部として)、ターゲット・デバイスがアクセスすることができる1組のターゲット候補アドレスを開示することができ、通信セッション32を確立している間に、ソース・デバイス12がソース候補アドレスの中からターゲット・アドレス80を選択することができ、選択したソース・アドレス80との通信セッション32を開始することができる。
【0038】
[0048] この第6の態様の第2の変形では、一方または双方のデバイスがハンドシェーク・プロセスの間に第1アドレスを用い、通信セッションの間は第2の(異なる)アドレスを用いることが望ましい場合がある。例えば、一方または双方のデバイスが、これらのデバイスと関連のあるアドレスを用いてハンドシェークに関与している場合、このハンドシェーク・プロセスの傍受者(eavesdropper)がこれらのアドレスを用いてデバイスの位置を特定すること、デバイス間のトランザクションを特定すること、および/またはサービス拒否攻撃(denial-of-service attack)によるというような、通信セッションを妨害することが可能になる虞れがある。代わりに、一方または双方のデバイスが1つのアドレス(例えば、匿名アドレス)を用いてハンドシェーク・プロセスに関与し、他のアドレス(例えば、匿名でないアドレス)を用いて、一旦認証され安全に確立された通信セッションに関与しようとすることもある。例えば、セッション受入84は、ソース・デバイス12がセッション招待82を送ったターゲット・デバイス14のターゲット・アドレス80とは異なる候補ターゲット・アドレスを含む場合もあり、ソース・デバイス12は、この候補ターゲット・アドレスにおいて、ターゲット・デバイス14との通信セッション32を開始することもできる。逆に、セッション招待82が、セッション招待82が送られた元のソース・デバイス12のソース・アドレス78とは異なる候補ソース・アドレスを含む場合もあり、ソース・デバイス12は、この候補ソース・アドレスからターゲット・デバイス14との通信セッション32を開始することもできる。このようなシナリオの1つでは、匿名化サーバーが、デバイスに、他のデバイスとハンドシェークするために、1回だけのアドレスを請求することを許容することができる。尚、この匿名化は、他のデバイスまたはそのユーザーの個体情報の、各デバイスによる認証の効果を減ずることなく実現可能であると考えられ、デバイスが匿名アドレスを用いることができても、公開証明書によって認証することができることは認められよう。当業者であれば、本明細書において論じられた技法を実施しつつ、ソース・デバイス12および/またはターゲット・デバイス14にアクセスすることができる複数のアドレスを開示し、それらの中から選択し、利用する多くの方法を考案することができよう。
【0039】
[0049] これらの技法の実施形態間で多様に変更することができる第7の態様は、通信チャネル32のセキュリティーを改善するための1つ以上のノンスの使用に関する。ノンスとは、ソース・デバイス12および/またはターゲット・デバイス14によって発生され、メッセージ52、通信セッション32等を区別して特定するためにメッセージ52に含まれる、特徴的な識別子である。第三者が、発信元の発生した暗号化メッセージを取り込むことができ、通信セッション32のセキュリティーを損なうため、または受信側デバイスの挙動を変化させるためにこの暗号化メッセージを受信機に再送信することができる状況においては、ノンスの使用により、「反射攻撃」を一層困難にすることができる。第1の例として、ソース・ノンスを発生するようにソース・デバイス12を構成することができ(例えば、乱数または連続数あるいは文字列)、このソース・ノンスをセッション招待82に含めることができ、これによってセッション招待82をはっきりと特定する。セッション招待82を受け取ったとき、ターゲット・デバイス14は、ソース・ノンスを検証するように構成することができる(例えば、同じソース・ノンスを有するセッション招待82を以前に受け取っていないことを確認することによって)。ソース・ノンスを検証するとき、ターゲット・デバイス14はセッション受入84をソース・デバイス12に送信することができ、このソース・ノンスを、1組の既に受け取ったソース・ノンスに記録することができる。加えて、ターゲット・デバイス14はソース・ノンスをセッション受入84に含めることができ、セッション招待82に応答するときに、ターゲット・デバイス14の個体情報を更に認証することができる(例えば、第三者が、以前に受け取ったセッション受入84に回答することによって、ターゲット・デバイス14になりすまそうとすることもあり得るが、セッション受入84においてソース・ノンスが一致しないと、ソース・デバイス12になりすましを警告することができる)。代わりにまたは加えて、ターゲット・デバイス14がターゲット・ノンスを発生することができ、このターゲット・ノンスをセッション受入84に含ませることもできる。セッション受入84を受け取ったときに、ソース・デバイス12は、ターゲット・デバイス14との通信セッション32を開始する前に、ターゲット・ノンスを検証することができる。
【0040】
[0050] 図10は、本明細書において紹介した技法にしたがって通信セッション32を確立しようとするソース・デバイス12およびターゲット・デバイス14を描写し、更にソース・ノンス172の使用を描写するシナリオ例170を示す。ソース・デバイス12は、ターゲット公開証明書72によって暗号化されたセッション招待82を発生し、ターゲット・デバイス14に送ることによって、通信セッション32を開始することを要求することができる。しかしながら、セッション招待82は、(他のエレメントに加えて)ランダムに発生された数値のような、ソース・ノンス172を含むことができる。ターゲット・デバイス14は、セッション招待82を受け取り、ソース・ノンス172が重要な役割を果たすセッション招待82を以前に受け取っていないことを確認することができる。ソース・ノンス172を確認することに成功すると、ターゲット・デバイス14は、ソース公開証明書66によって暗号化され、そして(他のエレメントに加えて)ソース・ノンス172を含むセッション受入84を発生し、ソース・デバイス12に送ることができる。ソース・デバイス12は、通信セッション32を開始する前に、セッション受入84において受け取ったソース・ノンス172が、セッション招待82において送られたソース・ノンス172と一致することを検証することができる。
【0041】
[0051] 図10のこのシナリオ例170においてソース・ノンス172を含ませることによって、少なくとも2つの面で通信セッション32のセキュリティーを改善することができる。第1に、第三者174はセッション招待82を傍受し、その後このセッション招待82をターゲット・デバイス14に送ることによってターゲット・デバイス14との別の通信セッション32を開始しようとし、これによって、ソース・デバイス12になりすますことがある。ターゲット・デバイス14は、再送信されたセッション招待82に含まれるソース・ノンス172を、ソース・デバイス12によってセッション招待82の最初の送信において既に受信されたものとして特定することができ、したがって第三者174との通信セッション32の開始を拒否することができる。第2に、第三者174は、ターゲット・デバイス14からソース・デバイス12に送信されたセッション受入84を、第1通信セッション開始の間に取り込むことがある。ソース・デバイス12によるターゲット・デバイス14との第2通信セッションを確立しようとするその後の試みにおいて、第三者174は次にセッション受入84を再送信することによって、ターゲット・デバイス14になりすまそうとすることができるが、第2セッション招待82におけるソース・ノンス172が、再送信されたセッション受入84において第三者174によって戻されたソース・ノンス172と一致しないことになり、これによって、ソース・デバイス12になりすましを警告する。尚、 当業者であれば、本明細書において論じられた技法を実施しつつ、ソース・デバイス12および/またはターゲット・デバイス14によって発生するノンスについて多くの用法を考案できるであろう。
【0042】
[0052] 以上、構造的特徴および/または方法論的動作に特定的な文言で主題について説明したが、添付した特許請求の範囲において定義されている主題は、必ずしも前述した特定の特徴や動作に限定されるのではないことは言うまでもない。逆に、前述した特定的な特徴や動作は、特許請求の範囲を実施する形態例として開示したまでである。
【0043】
[0053] 本願において用いる場合、「コンポーネント」、「モジュール」、「システム」、「インターフェース」などという用語は、一般に、コンピューター関連エンティティ、ハードウェア、ハードウェアおよびソフトウェアの組み合わせ、ソフトウェア、または実行中のソフトウェアのいずれかを指すことを意図している。例えば、コンポーネントは、限定ではなく、プロセッサーにおいて実行しているプロセス、プロセッサー、オブジェクト、エクゼキュータブル、実行のスレッド、プログラム、および/またはコンピューターであってもよい。例示として、コントローラーにおいて実行しているアプリケーションおよびこのコントローラーの双方が1つのコンポーネントになることができる。1つ以上のコンポーネントは、プロセスおよび/または実行のスレッドの内部に存在することができ、コンポーネントを1つのコンピューターに配置すること、および/または2つ以上のコンピューター間で分散することもできる。
【0044】
[0054] 更に、特許請求する主題は、方法、装置、あるいはソフトウェア、ファームウェア、ハードウェアを生産するための標準的なプログラミングおよび/または設計技法を用いた製造の品目、あるいは開示した主題を実現するようにコンピューターを制御するための組み合わせであればそのいずれとして実現することもできる。「製造の品目」という用語は、本明細書において用いられる場合、いずれかのコンピューター読み取り可能デバイス、担体(carrier)、または媒体からアクセス可能なコンピューター・プログラムを包含することを意図している。勿論、特許請求する主題の範囲や主旨から逸脱することなく、この構成に多くの変更を行い得ることは、当業者には認められよう。
【0045】
[0055] 図11および以下の論述は、本明細書において明示した機能(facilities)の1つ以上の実施形態を実現するのに適した計算環境の端的な総合的説明を行うためにある。図11の動作環境は、適した動作環境の一例に過ぎず、動作環境の使用範囲や機能について何の限定を示唆することも意図していない。計算機の例には、限定ではなく、パーソナル・コンピューター、サーバー・コンピューター、ハンド・ヘルドまたはラップトップ・デバイス、移動体デバイス(移動体電話機、パーソナル・ディジタル・アシスタント(PDA),メディア・プレーヤー等)、マルチプロセッサー・システム、消費者用電子機器、ミニ・コンピューター、メインフレーム・コンピューター、以上のシステムまたはデバイスの内いずれかを含む分散方計算環境などが含まれる。
【0046】
[0056] 必須ではないが、1つ以上の計算機によって実行される「コンピューター読み取り可能命令」という一般的なコンテキストで、実施形態が説明されている。コンピューター読み取り可能命令は、コンピューター読み取り可能媒体(以下で論ずる)を通じて分散することもできる。コンピューター読み取り可能命令は、関数、オブジェクト、アプリケーション・プログラミング・インターフェース(API)、データー構造などのようなプログラム・モジュールとして実現することができ、特定のタスクを実行するか、または特定の抽象データー・タイプを実装する。通例、コンピューター読み取り可能命令の機能は、種々の環境における所望に応じて、組み合わせることまたは分散することができる。
【0047】
[0057] 図11は、本明細書において示した1つ以上の実施形態を実現するように構成されている計算機182を備えているシステム180の一例を示す。一構成では、計算機182は少なくとも1つの演算装置186およびメモリー188を含む。計算機の正確な構成およびタイプに応じて、メモリー188は揮発性(例えば、RAMのような)、不揮発性(例えば、ROM、フラッシュ・メモリー等のような)、またはこれら2つの何らかの組み合わせとすることができる。この構成は、図11では破線184で示されている。
【0048】
[0058] 他の実施形態では、計算機182は追加の機構および/または機能を含むこともできる。例えば、計算機182は、追加のストレージ(例えば、リムーバブルおよび/または非リムーバブル)も含むことができる。限定ではなく、追加のストレージには、磁気ストレージ、光ストレージ等が含まれる。このような追加のストレージは、図11ではストレージ190によって例示されている。一実施形態では、本明細書において示した1つ以上の実施形態を実現するコンピューター読み取り可能命令は、ストレージ190の中にあるとよい。また、ストレージ190は、オペレーティング・システム、アプリケーション・プログラム等を実装するために、他のコンピューター読み取り可能命令も格納することができる。コンピューター読み取り可能命令は、例えば、演算装置186による実行のために、メモリー188にロードすることができる。
【0049】
[0059] 「コンピューター読み取り可能媒体」という用語は、本明細書において用いる場合、コンピューター記憶媒体を含む。コンピューター記憶媒体は、揮発性および不揮発性、リムーバブルおよび非リムーバブル媒体を含み、コンピューター読み取り可能命令または他のデーターのような情報の格納のためのいずれかの方法または技術で実現されている。メモリー188およびストレージ190は、コンピューター記憶媒体の例である。コンピューター記憶媒体は、限定ではなく、RAM、ROM、EEPROM、フラッシュ・メモリーまたはその他のメモリー技術、CD−ROM、ディジタル・バーサタイル・ディスク(DVD)またはその他の光ストレージ、磁気カセット、磁気テープ、磁気ディスク・ストレージまたはその他の磁気記憶デバイス、あるいは所望の情報を格納するために用いることができその上計算機182によってアクセスすることができるのであれば他のいずれの媒体をも含む。このようなコンピューター記憶媒体は、そのいずれもが計算機182の一部となってもよい。
【0050】
[0060] また、計算機182は、計算機182が他のデバイスと通信することを可能にする通信接続(1つまたは複数)196も含むことができる。通信接続(1つまたは複数)196は、限定ではなく、モデム、ネットワーク・インターフェース・カード(NIC)、統合ネットワーク・インターフェース、無線周波数送信機/受信機、赤外線ポート、USB接続、または計算機182を他の計算機と接続するためのその他のインターフェースを含むことができる。通信接続(1つまたは複数)196は、有線接続またはワイヤレス接続を含むことができる。通信接続(1つまたは複数)196は、通信媒体を送信および/または受信することができる。
【0051】
[0061] 「コンピューター読み取り可能媒体」という用語は、通信媒体を含むことができる。通信媒体は、通例、搬送波またはその他の伝達メカニズムのような「変調データー信号」にコンピューター読み取り可能命令またはその他のデーターを具体化し、いずれの情報配信媒体も含む。「変調データー信号」という用語は、情報を信号内に符号化するような態様で設定または変更したその特性の1つ以上を有する信号を含むことができる。
【0052】
[0062] 計算機182は、キーボード、マウス、ペン、音声入力デバイス、接触入力デバイス、赤外線カメラ、ビデオ入力デバイス、および/またはその他のあらゆる入力デバイスというような、入力デバイス(1つまたは複数)194を含むことができる。1つ以上のディスプレイ、スピーカー、プリンター、および/またはその他の出力デバイスというような出力デバイス(1つまたは複数)192も、計算機182に含むことができる。入力デバイス(1つまたは複数)194および出力デバイス(1つまたは複数)192は、有線接続、ワイヤレス接続、またはそのいずれの組み合わせによってでも、計算機182に接続することができる。一実施形態では、別の計算機からの入力デバイスまたは出力デバイスを、計算機182用の入力デバイス(1つまたは複数)194または出力デバイス(1つまたは複数)192として用いることもできる。
【0053】
[0063] 計算機182のコンポーネントは、バスのような、種々の相互接続によって接続することができる。このような相互接続は、PCI Expressのようなペリフェラル・コンポーネント相互接続(PCI)、ユニバーサル・シリアル・バス(USB)、ファイアワイヤ(IEEE1394)、光バス構造などを含むことができる。別の実施形態では、計算機182のコンポーネントは、ネットワークで相互接続することができる。例えば、メモリー188は、ネットワークによって相互接続されている異なる物理的位置にある多数の物理的メモリー・ユニットによって構成することもできる。
【0054】
[0064] コンピューター読み取り可能命令を格納するために利用される記憶デバイスは、ネットワークに跨って分散させてもよいことは、当業者には分かるであろう。例えば、ネットワーク198を通じてアクセス可能な計算機200は、本明細書において提唱した1つ以上の実施形態を実現するために、コンピューター読み取り可能命令を格納することができる。計算機182は、計算機200にアクセスし、コンピューター読み取り可能命令の一部または全部を実行のためにダウンロードすることができる。あるいは、計算機182は、必要に応じて、コンピューター読み取り可能命令の断片をダウンロードすることができ、または一部の命令を計算機182において実行し、一部を計算機200において実行することもできる。
【0055】
[0065] 本明細書では、実施形態の種々の動作について提唱した。一実施形態では、記載した動作の1つ以上が、1つ以上のコンピューター読み取り可能媒体上に格納されたコンピューター読み取り可能命令を構成することができ、計算機によって実行すると、当該計算機に、記載した動作を実行させる。これらの動作の一部または全部を記載した順序は、これらの動作に必然的な順序依存性があるように解釈すべきではない。この記載から援助を受けた当業者には、代わりの順序も認められよう。更に、本明細書において提唱した各実施形態において、全ての動作が必ずしも出てくる訳ではないことは言うまでもない。
【0056】
[0066] 更に、「一例の」という単語は、本明細書では、一例、実例、または例示としての役割を果たすことを意味するために用いられる。本明細書において「一例の」として記載される態様または設計はいずれも、他の態様または設計よりも有利であるとは必ずしも解釈されない。むしろ、一例のという用語の使用は、概念を具体的に紹介することを意図している。本明細書において用いる場合、「または」という用語は、排他的な「または」ではなく包含的な「または」を意味することを意図する。即ち、そうでないことが指定されていない限り、または文脈から明白でない限り、「XはAまたはBを採用する」とは、自然な包含的組み合わせ(permutation)のいずれでも意味することを意図する。即ち、XがAを採用する場合、XがBを採用する場合、またはXがAおよびBの双方を採用する場合、これらの実例のいずれにおいても、「XはAまたはBを採用する」が満たされる。加えて、冠詞「a」および「an」は、本願および添付した特許請求の範囲において用いられる場合、そうでないことが指定されていない限り、また文脈から単数形態を対象とすることが明白でない限り、「1つ以上」を意味するように通常解釈することができる。
【0057】
[0067] また、1つ以上の実施態様に関して本開示を示し説明したが、本明細書および添付図面の熟読および理解に基づいて、同等の変形や変更が当業者には想起されよう。本開示は、このような変更や変形を全て含み、以下の特許請求の範囲のみによって限定される。特に、以上で述べたコンポーネント(例えば、エレメント、リソース等)によって実行される種々の機能に関して、このようなコンポーネントを記載するために用いられた用語は、そうでないことが示されない限り、記載されたコンポーネント(例えば、機能的に同等な)の指定された機能を実行するのであれば、本開示のここで例示された実施態様例における機能を実行する、開示された構造に構造的に同等でなくても、いずれのコンポーネントにも対応することを意図している。加えて、本開示の特定的な機構を、様々な実施態様の内1つのみに関して開示したが、このような機構は、いずれの所与の用途または特定の用途にとっても望まれるまたは有利となるように、他の実施態様の1つ以上の別の機構と組み合わせることができる。更に、「含む」、「有している」(having)、「有する」(has)、「と」(with)という用語、またはその異形が詳細な説明または特許請求の範囲において用いられている限りにおいて、このような単語は、用語「備えている」(comprising)と同様に内包的であることを意図している。
【背景技術】
【0001】
[0001] 多くのコンピューター使用のシナリオでは、互いにアクセス可能な2つ以上のデバイスが(例えば、有線またはワイヤレス・ネットワークを通じて)通信セッションを確立しようとすることがある。この通信セッションは、機密情報の傍受または漏洩を防止するために暗号化されており、および/または各デバイスが、受信したメッセージが他のデバイスによって発生されたことを検証できるように、通信セッションを認証する。例えば、RSAアルゴリズムのような、非対称暗号鍵交換アルゴリズムを実装すると、セッションに対する公開鍵を交換することを2つのデバイスに可能にすることができる。公開鍵は、対応する秘密鍵と合わせて用いられ(そして秘密に保持する)、通信セッションの間における暗号化および認証された通信を可能にすることができる。
【0002】
[0002] 2つのデバイスがこのような通信セッションを確立しようとするとき、サポートされているプロトコルを特定し、鍵を交換するために、ハンドシェーク・プロトコルを用いることができる。例えば、トランスポート・レイヤー・セキュリティー(TLS)プロトコルは、ハンドシェークを開始するため、暗号アルゴリズム、圧縮アルゴリズム、公開鍵、および認証証明書を開示し選択するため、ならびに取り決められたアルゴリズムを用いて通信の開始を通知するために、各デバイスによって実装することができる。一旦通信セッションの詳細が決定されたなら、デバイスは安全な接続を確立することができ、暗号化されたチャネルを通じて通信を開始することができる。
【発明の概要】
【0003】
[0003] この摘要は、詳細な説明の章において以下で更に説明する概念から選択したものを紹介するために設けられている。この摘要は、特許請求する主題の主要な特徴や必須の特徴を特定することを意図するのではなく、特許請求する主題の範囲を限定するために用いられることを意図するのでもない。
【0004】
[0004] トランスポート・レイヤー・セキュリティー(TLS)プロトコルを含む多くのハンドシェーク・プロセスは、通信セッションのロジスティック(logistics)の取り決めにおいて、幅広いロバスト性を許容する。しかしながら、このロバスト性のために、実装の複雑さや、その結果起こり得るセキュリティー不備というような、種々のコストがかかる可能性がある。また、デバイスは取り決めを完了するために様々なメッセージを交換しなければならないこともあり、各メッセージが、デバイスを接続するネットワークを往復しなければならない場合がある。この情報交換は、特に、低帯域幅、高レイテンシー、および/または信頼性のない接続を経るときには(例えば、メッセージの欠落を伴うかもしれない低受信セルラー・ネットワーク)、時間がかかる可能性があり、または障害を受けやすい可能性がある。
【0005】
[0005] 代替技法では、通信セッションを確立するために、比較的少数のメッセージ交換で済む場合もある。本明細書において開示するこのような1組の技法では、ソース・デバイスからターゲット・デバイスへの、セッション招待を表す1組の情報(例えば、1つのメッセージ)の配信を伴い、このメッセージは、ソース・デバイスの1つ以上の候補アドレス、およびソース・デバイスによって発生されたセッション鍵を指定する。クライアント・デバイスは、このセッション招待を受信することができ、通信セッションの確立を許容することを選択する場合(そして、セッション招待の詳細を検証する、例えば、デバイスおよび/またはユーザーを、通信セッションを開始したものとして認証する場合)、それ自体のセッション鍵、およびターゲット・デバイスの1つ以上の候補アドレスと共に回答することができる。ソース・デバイスおよびターゲット・デバイスは、各々、ソース・セッション鍵およびターゲット・セッション鍵を用いて、セッション鍵を確立し、双方のデバイスはこのセッションのためにセッション鍵を用いることができる。安全を確保した通信セッションを可能にするのに十分な1組の情報を交換した後、ソース・デバイスは通信セッションを開始することができ、ターゲット・デバイスは同じように回答することができる。このように、デバイス間で交換するメッセージの数を減少させて(おそらくは最小数)、安全な通信セッションを確立ことができ、これによって通信セッションを確立する際のレイテンシーや障害の可能性を低減することができる。この方式において、他のセキュリティー機構を実装し含ませることもできる。例えば、安全な通信セッションが確立されるまで、ソース・デバイスおよびターゲット・デバイスの実際のアドレスを隠しておくことが可能なこともある。例えば、異なるアドレス(匿名にしたアドレスのような)をハンドシェーク・プロセスの間用いることもでき、その間、デバイスは、通信セッションの間に用いられる、各アドレスの他の(非匿名)アドレスを安全に送信することができる。
【0006】
[0006] 以上の目的および関係する目的の遂行のために、以下の説明および添付図面は、ある種の例示的態様および実施態様について明示する。これらは、1つ以上の態様を採用することができる種々の方法の内僅かなものを示すに過ぎない。本開示の他の態様、利点、および新規な特徴は、以下の詳細な説明を、添付図面と合わせて検討することにより、明白になるであろう。
【図面の簡単な説明】
【0007】
【図1】図1は、ソース・デバイスとターゲット・デバイスとの間における非対称暗号鍵対の発生および交換を描写するシナリオ例の図である。
【図2】図2は、安全な通信セッションを通じてソース・デバイスとターゲット・デバイスとの間においてメッセージを交換するための、非対称暗号鍵対の使用を描写するシナリオ例の図である。
【図3】図3は、トランスポート・レイヤー・セキュリティー(TLS)プロトコルの一バージョン例によるソース・デバイスとターゲット・デバイスとのハンドシェーク反復の図である。
【図4】図4は、本明細書において紹介する技法による、ソース・デバイスとターゲット・デバイスとのハンドシェーク反復の図である。
【図5】図5は、ソース・デバイスによってターゲット・デバイスとの通信セッションを確立する方法の一例を示すフロー・チャートである。
【図6】図6は、ターゲット・デバイスによってソース・デバイスとの通信セッションを確立する方法の一例を示すフロー・チャートである。
【図7】図7は、本明細書において明示する装備の内1つ以上を具体化するように構成されているプロセッサー実行可能命令を備えているコンピューター読み取り可能媒体の一例の図である。
【図8】図8は、本明細書において明示する技法にしたがって通信セッションを確立することができる1組のデバイスを、配備可能な計算環境内において表した図である。
【図9】図9は、通信セッションを確立している間にソース・デバイスおよび/またはターゲット・デバイスによってアクセスすることができる公開証明書を格納するように構成されている証明書サーバーを描写するシナリオ例の図である。
【図10】図10は、ソース・デバイスとソース・ノンスを利用するターゲット・デバイスとの間における通信セッションの確立を描写するシナリオ例の図である。
【図11】図11は、本明細書において明記する装備の内1つ以上を実現することができる、計算環境の一例を示す。
【発明を実施するための形態】
【0008】
[0018] これより図面を参照して、特許請求する主題について説明する。図面では、同様の参照番号は全体にわたって同様のエレメントを指すために用いられている。以下の記載では、説明の目的上、特許請求する主題の完全な理解を得るために、多数の具体的な詳細について明記する。しかしながら、特許請求する主題は、これらの具体的詳細がなくても、実施できることは明白であろう。一方、特許請求する主題を記述しやすくするために、構造およびデバイスをブロック図で示すこととする。
【0009】
[0019] 計算分野における多くのシナリオでは、インターネットを通じて接続されている2つのコンピューター、またはワイヤレス・ローカル・ネットワークを通じて接続されている2つのワイヤレス通信デバイスというような、ピア・デバイス間における通信セッションの確立を伴う。これらのシナリオでは、デバイスは、これらのデバイス間における通信が暗号化されるように、安全なチャネルを通じて通信セッションを確立しようとすることがある。更に、これらのデバイスは、パスワードを互いに共有しない方法でデーターを暗号化しようとすることもできる。これは、安全な通信セッションが確立される前では、パスワードを安全に交換することが困難である場合があるからである。つまり、デバイスは、暗号化されていないメッセージを送ることによって、物理的ネットワークを通じて通信することができるが、「オーバーレイ」ネットワークを案出する(devise)ことを望むこともあり、これによって、暗号化されたメッセージを、物理的ネットワークを通じて送ることおよび受信することができるが、各デバイスによってメッセージを自動的に暗号化および解読することもでき、これによって、各デバイス上で実行しているアプリケーションに、傍受からの安全を確保したデバイス間の仮想ネットワークを提示することができる。
【0010】
[0020] 図1および図2は、合わせて、安全に通信セッションを確立し利用しようとするソース・デバイス12(例えば、通信セッションの要求を発するクライアント)とターゲット・デバイス14(例えば、通信セッションを開始する要求を受信するサーバー)とを描写するシナリオ例を示す。図1のシナリオ例10では、ソース・デバイス12およびターゲット・デバイス14は、RSAアルゴリズムのような、非対称鍵暗号を特徴とする暗号アルゴリズム16の使用によって、通信セッションの安全を確保する際に必要となる何らかの情報を発生し交換する。このアルゴリズムは、公開鍵および秘密鍵から成る暗号鍵対を発生するように構成されている。この暗号鍵対は、次の2つの特性を有する。公開鍵を用いて秘密鍵を特定することはできない。公開鍵を用いて暗号化されたメッセージは、秘密鍵を用いることによってのみ、解読することができる。追加の利点として、秘密鍵を用いて、メッセージに暗号的に「署名」することもでき、公開鍵を用いてこの署名を検証し、こうしてメッセージの作者を秘密鍵の保持者として検証することができる(そして、メッセージの内容を検証することができる)。安全な通信セッションに備えるために、ソース・デバイス12は暗号アルゴリズム16を利用して、ソース秘密鍵20およびソース公開鍵18を発生することができ、ターゲット・デバイス14は、暗号アルゴリズム16を利用して、ターゲット公開鍵22およびターゲット秘密鍵24を発生することができる。次いで、ソース・デバイス12は、ソース秘密鍵20を秘密に保持しつつ、ソース公開鍵18をターゲット・デバイス14に送信することができ、ターゲット・デバイス14は、ターゲット秘密鍵24を秘密に保持しつつ、ターゲット公開鍵22をソース・デバイス12に送信することができる。
【0011】
[0021] 図2は、傍受を防ぐ安全な方法でメッセージを交換しつつ、パスワードを共有するときのセキュリティー上の難点を回避し(例えば、通信セッションが確立される前に通信セッションを暗号化するために共有パスワードを交換することの難点)、そして特定のメッセージの作者および内容の検証を可能にするための、ソース・デバイス12およびターゲット・デバイス14によるこれらの鍵対の使用を描写するシナリオ例30を示す。図1のシナリオ例10と同様に、ソース・デバイス12は、ターゲット・デバイス14と共有されているソース公開鍵18と、秘密に保持されるソース秘密鍵20とを既に発生しており、ターゲット・デバイス14は、ソース・デバイス12と共有されているターゲット公開鍵22と、秘密に保持されるターゲット秘密鍵24とを既に発生している。このシナリオ例30では、ソース・デバイス12およびターゲット・デバイス14はこの時点で通信セッション32に入っており、このセッションを通じて、メッセージ34をソース・デバイス12からターゲット・デバイス14に安全に送信することができる。例えば、通信セッション32は、インターネットのような、信頼性のないネットワーク上でも確立することができ、傍受が行われる虞れがある。したがって、ソース・デバイス12およびターゲット・デバイス14は、第三者によって容易に読み取り、変更、または改ざんを行うことができない、暗号化されたメッセージだけを通信セッション32において配信する。
【0012】
[0022] このシナリオ例30では、ソース・デバイス12は最初にメッセージ34をターゲット公開鍵22で暗号化して、暗号化メッセージ36を生成する。また、ソース・デバイス12は、ソース秘密鍵20で暗号化メッセージ36に署名して、暗号化/署名付きメッセージ38を生成する。この暗号化/署名付きメッセージ38は、通信セッション32においてターゲット・デバイス14に送信することができる。第三者が通信セッション32上において傍受し、暗号化/符号付きメッセージ38を読み取れるのであっても、傍受されたメッセージ34を解読することはできない。何故なら、第三者はターゲット秘密鍵24にアクセスできないからである。対照的に、ターゲット・デバイス14が暗号化/署名付きメッセージ40を受信するときには、ターゲット・デバイス14はターゲット秘密鍵24を用いて、解読メッセージ40を生成する。加えて、ターゲット・デバイス14は、ソース公開鍵18を用いて、解読されたメッセージ40の作者を検証すること(即ち、ソース・デバイス12のような、ソース秘密鍵20に対してアクセスすることができるデバイスによって、解読されたメッセージ40が発生されたことを検証する)、および/または解読されたメッセージ40の内容が、通信セッション32において傍受しているかもしれない第三者によって変更されていないことを検証することができる。このシナリオ例30の結果、ターゲット・デバイス14は、解読され、検証されたメッセージ42を受信することになる。メッセージ42は、信頼性のないチャネル(インターネットのような)を通じて送信されているが、第三者による傍受および/または改ざんの確率は検証可能に低い。
【0013】
[0023] 図1および図2のシナリオ例において図示した技法は、暗号化されたメッセージを、安全な通信セッションにおいて交換するために用いることができるが、通信セッションを確立するために公開鍵情報を交換する態様には、追加の考慮を伴ってもよい。第1の例として、第三者が鍵交換の開始時に他方のデバイスの替え玉を演じることが決してできないように、一方のデバイスが他方のデバイスを認証することが望ましい場合がある。例えば、第三者が、ソース・デバイス12からの通信セッション32を確立する要求を傍受する可能性があり、ターゲット・デバイス14の替え玉を演じつつ、ソース・デバイス12との鍵交換に関与することがあり得る。更に、「中間者攻撃」(man-in-the-middle attack)では、第三者がソース・デバイスの替え玉を演じて、ターゲット・デバイス14との第2通信セッション32を確立することを要求することもあり得る。双方の通信セッション32を開始することに成功した場合、第三者は、一方の通信セッション32から受信した全てのメッセージ34を他方の通信セッション32に受け渡すことができ、これによって、ソース・デバイス12とターゲット・デバイス14との間に安全な通信チャネル32があるように装うが、これを通じて交換されるメッセージ34に完全にアクセスすることができるようになる。この可能性を低減するために、ソース・デバイス12は、例えば、ターゲット・デバイスの個別情報(identity)を、信頼されているソースから受信した公開証明書と突き合わせて検査し、ターゲット・デバイス14を特定することによって、ターゲット・デバイス14を認証しようとしてもよい。これは、第三者にはおそらく遂行することができない。
【0014】
[0024] 第2の例として、メッセージを解読できない第三者がなおもソース・デバイス12および/またはターゲット・デバイス14を「反射攻撃」(replay attack)によって攻撃することもあり得る。この場合、第三者は、通信セッション32に送信された1つ以上の暗号化され署名されたメッセージ38を取り込み、後にそれらを受信側デバイスに再送信する。受信側デバイスは、再生されたメッセージを、以前に受信したメッセージの複製として認識し損ねて、それに対して反応(act)する可能性がある。例えば、ソース・デバイス12がターゲット・デバイス14に、ソース・デバイス12を認証する通信セッション32を確立する要求を送る場合、第三者がこのメッセージを取り込んで、これをターゲット・デバイス14に異なるアドレスから再送信することもできる。第三者は要求の内容を解読することができなくても、別のアドレスからのこの要求の再送(ソース・デバイス12の暗号化された信任状を含む)がターゲット・デバイス14によって首尾良く受け入れられることによって、ターゲット・デバイス14に、ソース・デバイス12の替え玉を演じる第三者との通信セッション32を確立することを促すことができる。このようなセキュリティー・リスクの脅威を低減するために、ソース・デバイス12および/またはターゲット・デバイス14は、種々のメッセージにおいて、「ノンス」を含ませることができる。「ノンス」は、1回だけの識別子(ランダムに発生されることが多い)を含み、受信側デバイスが、送信されたメッセージを特定することができるように、メッセージ34、通信セッション32等に、区別できる特性を付加するために用いられる。
【0015】
[0025] これらおよびその他の考慮事項のために、単に鍵情報の交換だけでなく、関連情報も伴って、ソース・デバイス12とターゲット・デバイス14との間において通信セッション32を確立する特定の方法を考案するとよい。多くのシナリオにおいて、この通信セッション32を確立する方法は、「ハンドシェーク」と呼ばれることもあり、入念に構造化された対話的な方法で大量の情報交換を伴うことができる。
【0016】
[0026] 図3は、トランスポート・レイヤー・セキュリティー(TLS)暗号プロトコルにおいて用いられる、ソース・デバイス12とターゲット・デバイス14との間における通信セッションの「ハンドシェーク」確立を描写する、シナリオ例50を示す。この場合も、ソース・デバイス12はソース公開鍵18およびソース秘密鍵20を発生し、一方、ターゲット・デバイス14はターゲット公開鍵22およびターゲット秘密鍵24を発生する。TLSプロトコルにしたがう1つの比較的簡素化された「ハンドシェーク」対話処理によれば、ソース・デバイス12は、ターゲット・デバイス14に、「クライアント・ハロー」 (Client Hello)メッセージとしてエンコードされたメッセージ52を送ることによって、対話処理を開始する。この「クライアント・ハロー」メッセージは、クライアント12によって用いられるTLSのバージョンおよびソース・ノンスを特定する。ターゲット・デバイス14は、「サーバー・ハロー」(Server Hello)メッセージ52で応答する。「サーバー・ハロー」メッセージも、サーバー12によって用いられるTLSのバージョン、およびターゲット・ノンスを特定する。また、ターゲット・デバイス14は「証明書」メッセージ52も送る。「証明書」メッセージ52は、シナリオによっては、ターゲット公開鍵22を含むこともある。次いで、ターゲット・デバイス14は、ソース・デバイス12に、「サーバー・ハロー・済み」(Server Hello Done)メッセージ52を送る。ソース・デバイス12は、ソース公開鍵18を特徴付ける「クライアント鍵交換」メッセージ52で回答し、次いで「暗号仕様変更」メッセージ52を送る。このメッセージ52は、ソース・デバイス12によって送られる後続のメッセージ52が、交換された信任状にしたがって暗号化されることを示す。最後に、ソース・デバイス12は「終了」メッセージ52を送り、ソース・デバイス12がハンドシェーク対話処理の担当部分を完了したことを示す。ターゲット・デバイス14は、同様の「暗号仕様変更」メッセージ52および「終了」メッセージ52で応答することによって、ハンドシェーク対話処理を完了し、安全な通信チャネル32を確立する。
【0017】
[0027] この比較的簡略化したハンドシェーク対話処理では、ソース・デバイス12およびターゲット・デバイス14は大量の情報を交換する。この対話処理は、9つのメッセージ52の交換を伴うものであり、各メッセージは、発送側デバイスによって利用され受信側デバイスにおいて特定の挙動を引き起こす、特定のフォーマットを有する。ハンドシェーク対話処理の複雑さのために、複雑化が生じる確率が高くなることもあり得る(例えば、正しくない順序でメッセージ52が交換された場合における予期しない結果または望ましくない結果、メッセージ52の配信失敗、および第三者による誤用の機会)。更に、各メッセージ52は、ネットワーク上における送信遅延を伴い、大量のレイテンシーが発生して、ソース・デバイス12とターゲット・デバイス14との間における通信チャネル32の確立が遅れる可能性がある。メッセージ52の交換回数を減らすために何らかの技法を用いることもできるが(例えば、図3のシナリオ例50において、関係するメッセージ52を組毎に纏めることによって、メッセージの交換回数を4に減らすことができる)、通信チャネルの追加の機構(例えば、特定のTLSバージョンおよび特定の暗号アルゴリズム16の取り決め)が、ハンドシェークを完了するために交換されるメッセージ52の数を更に増やすこともあり得る。また、このようなメッセージの発生、送信、受信、デコーディング、および処理は、ソース・デバイス12およびターゲット・デバイス14に計算の負担がかかり、接続数が多いこともあるシナリオでは(例えば、大きな1組のピア・デバイス間におけるピア・ツー・ピア・データー転送では、1つのデバイスが数百もの接続を動的に確立し維持する場合もある)、接続を確立する遅延およびコンピューター使用負担が容認可能な範囲を逸脱する可能性がある。
【0018】
[0028] したがって、好適に低いレイテンシーおよびコンピューター使用コストで通信セッション32の確立を可能にすべく、またそれと共に本明細書において論ずる特徴の一部(例えば、中間者攻撃または反射攻撃に対する保護)を可能とするよう、ハンドシェーク対話処理の複雑さを低減することが望ましいと考えられる。レイテンシーを低減する技法の1つでは、通信セッション32の確立において交換されるメッセージ52の数を減らすことが必要となる。例えば、各デバイスが他のデバイスに安全な通信セッション32の担当部分を定義する1組の情報を配信することを許容することによって、通信セッション32が1回のメッセージ52の交換によって開始できるようにする、ハンドシェーク対話処理を考案することもできる。
【0019】
[0029] 図4は、ソース・デバイス12およびターゲット・デバイス14が1回の情報交換で通信セッション32を確立することができる、これらの技法の一実施形態を描写するシナリオ例60を示す。例えば、ソース・デバイス12およびターゲット・デバイス14は、プロセッサー88を有し、インターネットまたはローカル・エリア・ネットワーク(LAN)のような有線またはワイヤレス通信ネットワークを通じて通信するコンピューターを含むことができる。このシナリオ例60では、ソース・デバイス12は、ソース公開証明書66によって識別可能とすることができ、ターゲット・デバイス14は、ターゲット公開証明書72によって識別可能とすることができる。これらの公開証明書は、信頼されているサーバー(例えば、公開証明書を格納し、他のデバイスによるデバイスの認証を促進するように構成されている認証サーバー)によって維持されているとよいが、他の方法で交換することもできる。ソース公開証明書66は、例えば、ソース証明書公開鍵62を収容することができる。ソース証明書公開鍵62は、既知の認証されているソース・デバイス12によって秘密に保持されているソース証明書秘密鍵64に対応する。そして、ターゲット公開鍵72は、例えば、ターゲット証明書公開鍵68を収容することができる。ターゲット証明書公開鍵68は、既知の認証されているターゲット・デバイス14によって秘密に保持されているターゲット証明書秘密鍵70に対応する。これらの公開証明書に付随する鍵対は、他のデバイスとの通信セッション32の間は、メッセージ52を暗号化するためにデバイスによって用いることができないが、デバイスの認証のために保持しておくことができる。ソース・デバイス12は、ターゲット証明書公開鍵68を含むターゲット公開証明書72にアクセスすることができ、ターゲット・デバイス14は、ソース証明書公開鍵62を含むソース公開証明書66にアクセスすることができる。加えて、ソース・デバイス12は、特定のネットワーク上におけるソース・アドレス78、例えば、インターネットまたはLANアクセスのために割り当てられるTCP/IPアドレスを有することもでき、ターゲット・デバイス14は、同じネットワーク上におけるターゲット・アドレス80を有することができる。このアドレスは、各デバイスがメッセージ52を他のデバイスにアドレスするために用いることができる。例えば、ターゲット・アドレス80をターゲット公開証明書72において指定することができ、これによって、ターゲット・デバイス14がターゲット・アドレス80でアクセス可能であり且つターゲット証明書秘密鍵70を所有している場合に、ターゲット・デバイス14の個体情報を認証することができる。
【0020】
[0030] ソース・デバイス12がターゲット・デバイス14との通信セッション32を開始する要求を(例えば、ユーザーから)受けたとき、ソース・デバイス12は以下のようにしてハンドシェークを開始することができる。最初に、ソース・デバイス12はソース・セッション鍵70を発生することができる。ソース・セッション鍵70は、このターゲット・デバイス14とのこの通信セッション32のためにのみ、メッセージ52を暗号化および解読するために用いられる。ソース・デバイス12は、セッション招待82を用意することができる。セッション招待82は、ソース・セッション鍵74およびソース・アドレス78を含む。ソース・デバイス12は、ターゲット公開証明書72の中にあるターゲット証明書公開鍵68を用いてメッセージを暗号化することができる。次いで、セッション招待82は、通信セッション32を開始する要求として、ターゲット・デバイス14に送信され得る。
【0021】
[0031] ターゲット・デバイス14がセッション招待82を受け取ると、ターゲット・デバイス14は、ターゲット証明書秘密鍵70を用いて、セッション招待82を解読することができ、この通信セッション32を開始する招待を受け入れるか否か判断することができる。ターゲット・デバイス14がこの招待を受け入れる場合、ターゲット・デバイス14は次にターゲット・セッション鍵76を発生することができる。ソース・セッション鍵74およびターゲット・セッション鍵76を用いて、ターゲット・デバイス14は、最終的な通信セッション32を解読するために用いることができるセッション鍵86を発生することができる。例えば、セッション鍵86は、Rijndael鍵のような、メッセージの暗号化および解読双方を行うために用いることができる、対象鍵を含むことができる。対象鍵は、例えば、ソース・セッション鍵74およびターゲット・セッション鍵76の単純な連携を構成することもできる。ターゲット・セッション鍵76を発生した後、ターゲット・デバイス14は、ターゲット・セッション鍵76およびターゲット・アドレス80を含む、セッション受入84を発生することができる。セッション受入84は、ソース公開証明書66によってエンコードすることができる。次いで、ターゲット・デバイス14はセッション受入84をソース・デバイス12に送信することができる。セッション受入84を受け取ると、ソース・デバイス12も、ソース・セッション鍵74およびターゲット・セッション鍵76を用いて、セッション鍵86を発生することができる。次いで、ソース・デバイス12は、セッション鍵86によって暗号化された、ターゲット・アドレス14との通信セッションを開始することができ、図2のシナリオ例30におけるように、通信セッション32を通じてメッセージを交換することができる。このように、ソース・デバイス12およびターゲット・デバイス14は、2つメッセージ52のみで、通信セッション32を開始するための関連情報を交換することができ、これによって、ハンドシェークのレイテンシーおよびコンピューター使用負担を軽減することができる。加えて、ターゲット公開証明書72の使用により、ソース・デバイス12に対するターゲット・デバイス14の個体情報の認証を容易にする一方、ハンドシェークにおいて追加メッセージ52の交換を必要としない。更に、これらの技法の改良では(図4には示されていない)、通信セッション32を確立するのに要するレイテンシーは、ターゲット・デバイス14が、セッション招待82を受け取ったときに、ソース・デバイス12との通信セッションを開始する場合、更に短縮することもできる。この実施形態では、セッション受入84は、確立された通信チャネル内において送ることができ、これによって、1つのメッセージ52の交換に対するハンドシェークを減らし、ハンドシェークのレイテンシーおよびコンピューター使用負担を軽減することができる。
【0022】
[0032] 図5は、これらの技法の第1実施形態を示し、プロセッサー88およびソース・アドレス78、ならびにソース公開鍵62およびソース秘密鍵64を有するソース・デバイス12によって通信セッション32を確立する方法の一例90として紹介する。したがって、ソース・デバイス12は、ソース公開鍵62を含むソース公開証明書66によって表される。通信セッション32は、ターゲット公開証明書72およびターゲット・アドレス80を有するターゲット・デバイス14と確立される。この方法例90は、例えば、ソース・デバイス12のメモリーに格納されている1組の命令として具体化することができる。方法例90は、92において開始し、本明細書において紹介した技法を実施するように構成されている命令をプロセッサー88上で実行する(94)ステップを含む。即ち、ソース・セッション鍵を発生する(96)ように、命令を構成することができる。また、命令は、ソース・アドレス78およびソース・セッション鍵74を含むセッション招待82を、ターゲット・デバイス14に送信する(98)ように構成することもでき、ここで、セッション招待82は、ターゲット公開証明書72(例えば、ターゲット公開証明書72に含まれているターゲット証明書公開鍵68)を用いて暗号化される。また、命令は、ターゲット・デバイス12から、ターゲット・アドレス80およびターゲット・セッション鍵76を含むセッション受入84を受け取ったとき(100)に、ソース公開証明書66を用いてセッション受入84を解読し(102)、ソース・セッション鍵74およびターゲット・セッション鍵76を用いて、セッション鍵86を発生する(104)ように構成することもできる。最後に、命令は、セッション受入84において指定されているターゲット・アドレス80において、ターゲット・デバイス14との通信セッション32を開始する(106)ように構成することもでき、通信セッション32は、セッション鍵86を用いて暗号化される。セッション招待82の送信およびセッション受入84の受信によってターゲット・デバイス14と鍵情報を交換し終えた後、方法例90は、メッセージ52の数を減らして、ターゲット・デバイス14との通信セッション32を確立し、こうして108において終了する。
【0023】
[0033] 図6は、これらの技法の第2実施形態を示し、プロセッサー88、ターゲット公開証明書72、およびターゲット・アドレス80を有するターゲット・デバイス14によって、ソース公開証明書66を有するソース・デバイス12との通信セッション32を確立する方法の一例110として図示する。方法例110は、例えば、ターゲット・デバイス14のメモリーに格納されている1組の命令として具体化することができる。方法例110は、112において開始し、本明細書において紹介した技法を実施するように構成されている命令をプロセッサー88上で実行するステップ114を含む。更に具体的には、命令は、ソース・アドレス78およびソース・セッション鍵74を含むセッション招待82をソース・デバイス12から受け取ったとき(116)、ターゲット公開証明書72を用いてセッション招待82を解読し(118)、ターゲット・セッション鍵76を発生する(120)ように構成することができる。ソース・セッション鍵74およびターゲット・セッション鍵76を用いて、セッション鍵86を発生する(122)ように、命令を構成することができる。また、ターゲット・アドレス80およびターゲット・セッション鍵76を含むセッション受入84をソース・デバイス12に送信する(124)ように命令を構成することもでき、セッション受入84は、ソース公開証明書66を用いて暗号化される。最後に、ソース・デバイス12から通信セッション32の開始を受け取ったときに、ソース・アドレス76においてソース・デバイス12との通信セッション32を開始する(124)ように、命令を構成することができ、通信セッション32は、セッション鍵86を用いて暗号化される。セッション招待82の受信およびセッション受入84の送信によってソース・デバイス12と鍵情報を交換し終えた後、方法例110は、メッセージ52の数を減らして、ソース・デバイス12との通信セッション32を確立し、こうして126において終了する。
【0024】
[0034] 更に他の実施形態は、本明細書において紹介した技法を応用するように構成されているプロセッサー実行可能命令を備えているコンピューター読み取り可能媒体を含む。これらの方法において考案することができるコンピューター読み取り可能媒体の一例を図7に示す。図7では、実施態様130は、コンピューター読み取り可能媒体132(例えば、CD−R、DVD−R、またはハード・ディスク・ドライブのプラッター)を備えており、その上にコンピューター読み取り可能データー134がエンコードされている。このコンピューター読み取り可能データー134は、一方、本明細書において明記した原理にしたがって動作するように構成されている1組のコンピューター命令136を構成する。このような実施形態の1つでは、プロセッサー実行可能命令136は、図5の方法例90のような、ターゲット・デバイスとの通信セッションを確立する方法を実行するように構成することができる。このような実施形態の他の1つでは、プロセッサー実行可能命令136は、図6の方法例110のような、ソース・デバイスとの通信セッションを確立する方法を実行するように構成することができる。本明細書において紹介した技法にしたがって動作するように構成されている、多くのこのようなコンピューター読み取り可能媒体を、当業者によって考案することができる。
【0025】
[0035] 本明細書において論じられた技法は、多くの態様において様々な変形と合わせて考案することができ、一部の変形は、これらおよびその他の技法の他の変形に関して、追加の利点を提供することおよび/または欠点を低減することができる。更に、一部の変形を組み合わせて実施することもでき、組み合わせの中は、相乗的協同による利点の増大および/または欠点の減少を特徴とするものもある。これらの変形は、種々の実施形態に対して個々の利点および/または相乗的利点を与えるように、これらの実施形態において組み込むことができる(例えば、図5の方法例90および図6の方法例110)。
【0026】
[0036] これらの技法の実施形態間で多様に変更することができる第1の態様は、本明細書において紹介したこれらの技法を利用することができるシナリオに関する。第1の例として、本技法は、インターネットまたはローカル・エリア・ネットワーク(LAN)のような有線ネットワーク、あるいはセルラー・ネットワークのようなワイヤレス・ネットワークを通じて接続されているコンピューター間において効率的に(そして低レイテンシーで)安全な通信セッションを確立するために利用することができる。また、本技法は、ユニバーサル・シリアル・バス(USB)ハブのような有線またはワイヤレス・デバイス・ネットワーク、あるいはBluetoothのようなパーソナル・エリア・ネットワーク(PAN)を通じて接続されているデバイス間において効率的に(そして低レイテンシーで)安全な通信セッションを確立するためにも利用することができる。また、これらのデバイスは、同じユーザーによってまたは異なるユーザーによって動作させることもできる。第2の例として、本技法は、クライアントとして動作するソース・デバイス12が、サーバーとして動作するターゲット・デバイス14に接触しようとするサーバー/クライアント構成、およびソース・デバイス12およびターゲット・デバイス14が分散データー共有方式においてピアとして動作するピア・ツー・ピア構成を含む、多くのタイプの通信セッションを確立するために利用することができる。これらの技法の更に他の実施形態では、2つよりも多いデバイスを接続することができ、本明細書において論じられた技法の何らかの変形を用いて、例えば、ソース・デバイス12および1組のターゲット・デバイス14間におけるマルチキャスト通信セッション(各々が同じ共有鍵対を用いるか、各々が個々の鍵対を有する等)を確立することができる。第3の例として、非対称暗号鍵対を発生するために、そして鍵対を用いてメッセージ52を暗号化および解読するために、多くのタイプの暗号アルゴリズムを用いることができる。
【0027】
[0037] これらの技法を利用することができる特定的なシナリオの1つでは、配備可能な計算環境において表されているデバイス間におけるメッセージの交換に関係する。多数のデバイス間において、一貫性があり、配備可能で、その上拡張可能な方法で、計算環境にアクセスする技法を開発する試みが最近行われている。また、これらの技法は、協同するデバイス間に1組の共通アプリケーションを提供し、更にこのようなデバイス間においてアプリケーションの調達、インストール、使用、およびアンインストールを管理する集中サービスを提供することも追求する。この1組のアプリケーションは、種々のデバイス間において必ずしも同一ではない。例えば、ワークステーションであれば、セル・フォン・デバイス上ではしかるべく実行することができない高性能アプリケーション(例えば、写真編集ソフトウェア、およびグラフィック満載のゲーム)を内蔵することができ、セル・フォン・デバイスは、携帯用でないワークステーションには関係のない、携行に関するアプリケーション(例えば、GPSに基づく地図作成ソフトウェア)を含むことができる。しかしながら、多くのアプリケーションおよびそれに関係するデーター・オブジェクトは、このようなデバイス間で共有することができ(例えば、ユーザーのカレンダー・オブジェクトを管理するように構成されているカレンダー・アプリケーション)、このようなデバイス間においてアプリケーションおよびデーター・オブジェクトの配布および同期を可能にするように、計算環境を適応させることができる。したがって、コンピューター・システムは、1組のデバイス間において計算環境の配備を可能にするように表すことができると有利であることが認めることができよう。
【0028】
[0038] このような技法の1つでは、1組のアプリケーションと、アプリケーション・リソースと、それらによって用いられるデーター・オブジェクトとを含む計算環境は、デバイスに付与されそのデバイスの能力に応じた機能を果たすような形で表される。オブジェクトは、ユーザーによって作成されたユーザー・ファイルおよびデーターというような、コンピューター・システムのデーター・オブジェクト、ならびにユーザーの計算環境を構成する無数のデバイスの表現を含む。このように表された計算環境は、いずれのデバイスに付与することもでき、そのデバイスの能力に適した方法で機能することができる。例えば、ワークステーションであれば、ロバストな汎用計算環境として情報を処理することができ、一方、公衆ワークステーションであれば、(例えば、ユーザーのセッション終了時には破棄されてもよい仮想マシンとして)ウェブ・ブラウザーを通じて異なる計算環境体験をもたらすことができ、携帯電話であれば、もっと軽いインターフェースを設けて、携帯電話関連情報(例えば、連絡先、カレンダー、およびナビゲーション・データー)にもっと素早くアクセスできるようにすることもできる。更に、情報集合に対する更新(例えば、好みの変更、およびその中に収容されているデーター・ファイルに対する更新)を、情報集合の基幹ソースに適用し、これによって、その情報集合が配信される他の全てのデバイスに更新を伝えることができる。
【0029】
[0039] 図8は、1つのこのようなシナリオ140を示す。この場合、オブジェクト階層144を格納し管理することができる計算環境ホスト142によって、計算環境をホストすることができる。計算環境ホスト142は、携帯電話デバイス146、パーソナル・ノートブック・コンピューター150、および公衆ワークステーション154のような、種々のデバイスに成り代わって、更に、異なるアクセス特権を有する異なるタイプのユーザーに成り代わって、異なる方法でオブジェクト階層144を与えることができる。計算環境に対する更新は、逆に計算環境ホスト142に伝えることができ、他のデバイスと自動的に同期させることができる。したがって、計算環境をクラウド計算アーキテクチャとして考案し、提示することができる。クラウド計算アーキテクチャは、同一の計算環境への協同ポータル(デバイス特定の特性を有する)のメッシュを形成する全てのデバイス(「クライアント」)にわたって一貫性がある機能として表現されている、デバイスに独立した表現(「クラウド」)を含む。本明細書において論じられた技法に関して、オブジェクト階層144において表されているデバイスは、本明細書において論じられた技法を用いて、安全かつ効率的に通信セッション32を確立することができる。当業者であれば、本明細書において論じられた技法を利用できる多くのシナリオを考案することができよう。
【0030】
[0040] これらの技法の実施形態間で多様に変更することができる第2の態様は、ターゲット・デバイス14のターゲット公開証明書72を得る方法に関する。ソース・デバイス12は、このターゲット公開証明書72を用いて、セッション招待82を暗号化することができる。一実施態様では、ターゲット公開証明書72は、ターゲット公開証明書72を含む種々の公開証明書を格納するように構成することができる証明書サーバーから得ることができる。例えば、大きな組織は、ローカル・エリア・ネットワーク(LAN)を通じてアクセス可能なコンピューターというような、その組織によって用いられる種々の既知のデバイスの公開証明書を収容する証明書サーバーを実装することができる。このような実施形態の1つにおいて、このようなデバイスが表される計算環境ホスト142は、オブジェクト階層144の中にターゲット公開証明書72を格納するように構成することができ、オブジェクト階層144は、ソース・デバイス12に対して容易にアクセス可能であるとよい。ネットワーク上で動作するソース・デバイス12は、最初に証明書サーバーに問い合わせてターゲット・デバイス14の公開証明書を求め、次いで、提供された公開証明書を用いてセッション招待82を暗号化することによって、特定のターゲット・デバイス14との通信セッションを確立しようとすることができる。こうすることによって、この技法は、対応する応答を受け取ったときに、ターゲット・デバイス14を認証する。これは、提供されたターゲット公開証明書72に対応するターゲット証明書秘密鍵70にアクセスしなければ、他のデバイスはセッション招待82を解読することができないからである。しかしながら、証明書サーバーはセキュリティーの弱点を表すこともある。何故なら、第三者によって能力が弱められた場合、多数のデバイスの認証が第三者によって改ざんされる虞れがあり、加えて、証明書サーバー自体を認証しなければならないこともあるからである。代替技法として、種々のデバイスのターゲット公開証明書72を、いずれかの適したチャネルによって、例えば、電子メール、ファイル転送、または物理的な記憶媒体によって、ソース・デバイス12に提供してもよい。ソース・デバイス12がどのようにしてターゲット公開証明書72へのアクセスを達成するかには関係なく、本明細書において論じられた技法は、それに応じて利用することができる。逆に、実施形態によっては、ターゲット・デバイス14が既知のソース・デバイスのみとの通信セッション32を確立するように構成されている場合、ターゲット・デバイス14はソース公開証明書(同様に証明書サーバー162によって提供することができる)を参照して、ハンドシェークの間にソース・デバイス12を認証することができる。
【0031】
[0041] これらの技法の更なる改良は、公開証明書のキャッシングに関する。例えば、ソース・デバイス12が証明書キャッシュを備えていることもあり、この場合、通信セッション32の開始中に(例えば、証明書サーバーから)得られたターゲット公開証明書72を格納することができ、同じターゲット・デバイス14との後続の通信セッションを開始する間に、ターゲット・デバイス14を再度認証するために、後に利用することもできる。更に、このキャッシングは、特定のデバイス14のターゲット公開証明書72の冗長な読み出しを減らすことによって、これらの技法の効率を高めることもできる。また、例えば、それぞれのターゲット公開証明書72の有効期間を確定し、期限が切れたターゲット公開証明書72を証明書キャッシュから削除することによって、セキュリティーを強化するためにも、キャッシュを維持するとよい。
【0032】
[0042] 図9は、本明細書において論じられた技法と合わせて、この第2の態様の変形の一部を描写するシナリオ例160を示す。このシナリオ例160では、特定のターゲット・デバイス14のターゲット公開証明書72を含む公開証明書を格納するように、証明書サーバー162を構成することができる。証明書サーバー162にアクセスすることができるソース・デバイス12は、ターゲット・デバイス14との第1通信セッション166を開始しようとすることがあり、したがって、ターゲット公開証明書72を得るために証明書サーバー162に問い合わせることができる。しかしながら、ソース・デバイス12も、公開証明書を格納するように構成されている証明書キャッシュ164を備えることができ、ターゲット・デバイス14のターゲット公開証明書72を得たときに、ソース・デバイス12はターゲット・デバイス14のターゲット公開証明書72を証明書キャッシュ164に格納するように構成することができる。次いで、ソース・デバイス12は、第1通信セッション166を確立しつつ、ターゲット・デバイス14を認証するために、ターゲット公開証明書を利用することができる。その後(例えば、第1通信セッション166が終了した後)、ソース・デバイス12がターゲット・デバイス14との第2通信セッション168を開始しようとすることがある。証明書サーバー162からターゲット公開証明書72を再度取得するのではなく、ソース・デバイス12はターゲット公開証明書72を証明書キャッシュ164から読み出すことができ、このターゲット公開証明書72は、第2通信セッション168を確立している間に、ターゲット・デバイス14を再度認証するために利用することができる。したがって、このキャッシングは、ターゲット公開証明書72の冗長な取得を回避することによって、第2通信セッション168を確立する効率を高めることができる。当業者であれば、本明細書において論じられた技法を実施しつつ、公開証明書の配信および使用を実現する多くの技法を考案することができよう。
【0033】
[0043] これらの技法の実施形態間で多様に変更することができる第3の態様は、ソース・デバイス12とターゲット・デバイス14との間において確立される通信セッション32を暗号化するために用いられるセッション鍵86を生成する(develop)方法に関する。第1の例として、セッション鍵86は対称鍵を含む場合があり、対称暗号アルゴリズム(例えば、Rijndaelアルゴリズム)にしたがってランダムに発生し利用することができ、これによって、メッセージを暗号化および解読するために、同じ鍵が用いられるようになる。対称鍵は、通信セッション32の安全を確保するために望ましいと考えられる。何故なら、このような鍵を用いるコンピューター使用負担は、非対称鍵を用いる場合よりも、かなり低くすることができるからである。次いで、セッション鍵86を発生することができ、このとき、例えば、ランダムに発生した鍵(ランダムに選択した整数または文字列のような)を含むソース・セッション鍵74を発生し、第2のランダムに発生した鍵を含むターゲット・セッション鍵76を発生し、そして第1のランダムに発生した鍵および第2のランダムに発生した鍵を用いて、対称ランダム・セッション鍵を発生する(例えば、ランダムに発生した鍵を繋げることによって)。
【0034】
[0044] 第2の例として、1組のセッション鍵を発生することもできる。対称鍵は非対称鍵よりも容易に解読される虞れがあるので、通信セッション32の間1組の鍵を順番に用いる(rotate through)ことが望ましい場合がある(例えば、ソース・デバイス12およびターゲット・デバイス14が、セッション鍵集合において周期的に次の鍵に切り替わるように構成されている場合)。例えば、セッション鍵86は、少なくとも2つのセッション鍵を備えているセッション鍵集合として発生することができ、その各々は他方のセッション鍵とは異なるものの、ソース・セッション鍵およびターゲット・セッション鍵を用いて発生される(異なる方法で)。開始時に、最初に第1セッション鍵を用いて通信セッション32を暗号化することができ、デバイスは、何らかの方法で(例えば、周期的に)第2セッション鍵をセッション鍵集合から選択し、この第2セッション鍵を用いて通信セッション32を暗号化するように構成することができる。当業者であれば、本明細書において論じられた技法を実施しつつ、セッション鍵を発生し使用する多くの方法を考案することができよう。
【0035】
[0045] これらの技法の実施形態間で多様に変更することができる第4の態様は、通信セッションを開始する方法に関する。第1の例として、ソース・デバイス12が、セッション受入84を受け取った後に、ターゲット・デバイス14との通信セッション32を開始することができる。第2の例として、ターゲット・デバイス14が、代わりに、セッション受入84を送った後に、ソース・デバイス12との通信セッション32を開始することもできる。第3の例として、ターゲット・デバイス14が、セッション受入84を送る前であっても、通信セッション32を開始することもでき、代わりに、通信セッション32を確立した後にセッション受入84を送ることができる。この技法は、1つのメッセージのみを送った後に、これらのデバイスに通信セッションを効果的に確立させることができる。例えば、ソース・デバイス12はセッション招待82をターゲット・デバイス14に送ることができ、次いで、通信セッション32内において続けるためにセッション受入84を用いて、ターゲット・デバイス14による通信セッション32の開始を待つように構成することができる。当業者であれば、本明細書において論じられた技法を実施しつつ、デバイス間において通信セッションを開始する多くの方法を考案することができよう。
【0036】
[0046] これらの技法の実施形態間で多様に変更することができる第5の態様は、異なるユーザーが動作させるデバイス間における通信セッション32の確立を伴うシナリオに関する。デバイスが同じユーザーによって動作させられる場合、個別情報に基づくセキュリティーの懸念は比較的少なくて済むと考えられる。しかし、ソース・デバイス12がソース・ユーザーによって動作させられ、ターゲット・デバイス14がターゲット・ユーザーによって動作させられる場合、一方または双方のユーザーが、通信セッション32を開始する前に、他方のユーザーの個人情報を認証することを望む場合がある。例えば、ターゲット・ユーザーが、ソース・デバイス14のソース・ユーザー12の内特定の1組とだけデーターを共有するように、ターゲット・デバイス14を構成しておくことができ、したがって、知らないユーザーまたは知っているが認証されていないユーザーとの通信セッション32を確立することを拒否するように、ターゲット・デバイス14を構成することができる。このような実施形態の1つでは、ソース・デバイス12によって提供されるセッション招待82は、パスワードまたは暗号署名のような、ソース・ユーザー認証部を含むことができ、この認証部がソース・デバイス12のソース・ユーザーの個体情報を認証することができる。したがって、ターゲット・デバイス14は、ソース・ユーザー認証部を用いてソース・ユーザーを認証し、ソース・ユーザーを認証した後に、ソース・デバイス12との通信セッション32を開始するように構成することができる。逆に、ターゲット・デバイス14によって提供されるセッション受入84は、ターゲット・ユーザー認証部を含むことができ、このターゲット・ユーザー認証部がターゲット・デバイス14のターゲット・ユーザーの個体情報を認証することができ、ソース・デバイス12は、ターゲット・ユーザー認証部を用いてターゲット・ユーザーを検証し、ターゲット・ユーザーを認証した後に、ターゲット・デバイス14との通信セッション32を開始するように構成することができる。当業者であれば、本明細書において論じられた技法を実施しつつ、ユーザーを認証する多くの方法を考案することができよう。
【0037】
[0047] これらの技法の実施形態間で多様に変更することができる第6の態様は、ソース・デバイス12およびターゲット・デバイス14の一方または双方が多数のアドレスでアクセス可能であるシナリオに関する。第1のこのようなシナリオでは、ソース・デバイス12およびターゲット・デバイス14が、Bluetoothネットワークのようなパーソナル・エリア・ネットワーク(PAN)、802.11(WiFi)ネットワークのようなローカル・エリア・ネットワーク(LAN)、およびインターネットのようなワイド・エリア・ネットワーク(WAN)というような、多数のネットワークに跨がって互いに同時にアクセスすることができる場合がある。また、物理的ネットワークは、ノードがサーバー、クライアント、および/または他のピアに対して1つ以上のピアとして動作することができるスーパー・ピア・ネットワークのような、他のタイプのネットワークも備えることができる。第2のシナリオでは、ある範囲のアドレスにおいてターゲット・デバイス14がアクセス可能であり、ソース・デバイス12にとって、他のアドレスと比較して、特定のアドレスを用いてターゲット・デバイス14に接触することが好ましい場合がある(例えば、ポート21を介してアクセスされるFTPチャネルの代わりに、ポート80を介してアクセスされるHTTPチャネル)。これらおよびその他のシナリオでは、ソース・デバイス12がターゲット・デバイス14に(例えば、セッション招待82の一部として)、ソース・デバイスがアクセスすることができる1組のソース候補アドレスを開示することができ、通信セッション32を確立している間に、ターゲット・デバイス14はソース候補アドレスの中からソース・アドレス76を選択することができ、この選択したソース・アドレス76との通信セッション32を開始することができる。逆にまたは加えて、ターゲット・デバイス14がソース・デバイス12に(例えば、セッション受入84の一部として)、ターゲット・デバイスがアクセスすることができる1組のターゲット候補アドレスを開示することができ、通信セッション32を確立している間に、ソース・デバイス12がソース候補アドレスの中からターゲット・アドレス80を選択することができ、選択したソース・アドレス80との通信セッション32を開始することができる。
【0038】
[0048] この第6の態様の第2の変形では、一方または双方のデバイスがハンドシェーク・プロセスの間に第1アドレスを用い、通信セッションの間は第2の(異なる)アドレスを用いることが望ましい場合がある。例えば、一方または双方のデバイスが、これらのデバイスと関連のあるアドレスを用いてハンドシェークに関与している場合、このハンドシェーク・プロセスの傍受者(eavesdropper)がこれらのアドレスを用いてデバイスの位置を特定すること、デバイス間のトランザクションを特定すること、および/またはサービス拒否攻撃(denial-of-service attack)によるというような、通信セッションを妨害することが可能になる虞れがある。代わりに、一方または双方のデバイスが1つのアドレス(例えば、匿名アドレス)を用いてハンドシェーク・プロセスに関与し、他のアドレス(例えば、匿名でないアドレス)を用いて、一旦認証され安全に確立された通信セッションに関与しようとすることもある。例えば、セッション受入84は、ソース・デバイス12がセッション招待82を送ったターゲット・デバイス14のターゲット・アドレス80とは異なる候補ターゲット・アドレスを含む場合もあり、ソース・デバイス12は、この候補ターゲット・アドレスにおいて、ターゲット・デバイス14との通信セッション32を開始することもできる。逆に、セッション招待82が、セッション招待82が送られた元のソース・デバイス12のソース・アドレス78とは異なる候補ソース・アドレスを含む場合もあり、ソース・デバイス12は、この候補ソース・アドレスからターゲット・デバイス14との通信セッション32を開始することもできる。このようなシナリオの1つでは、匿名化サーバーが、デバイスに、他のデバイスとハンドシェークするために、1回だけのアドレスを請求することを許容することができる。尚、この匿名化は、他のデバイスまたはそのユーザーの個体情報の、各デバイスによる認証の効果を減ずることなく実現可能であると考えられ、デバイスが匿名アドレスを用いることができても、公開証明書によって認証することができることは認められよう。当業者であれば、本明細書において論じられた技法を実施しつつ、ソース・デバイス12および/またはターゲット・デバイス14にアクセスすることができる複数のアドレスを開示し、それらの中から選択し、利用する多くの方法を考案することができよう。
【0039】
[0049] これらの技法の実施形態間で多様に変更することができる第7の態様は、通信チャネル32のセキュリティーを改善するための1つ以上のノンスの使用に関する。ノンスとは、ソース・デバイス12および/またはターゲット・デバイス14によって発生され、メッセージ52、通信セッション32等を区別して特定するためにメッセージ52に含まれる、特徴的な識別子である。第三者が、発信元の発生した暗号化メッセージを取り込むことができ、通信セッション32のセキュリティーを損なうため、または受信側デバイスの挙動を変化させるためにこの暗号化メッセージを受信機に再送信することができる状況においては、ノンスの使用により、「反射攻撃」を一層困難にすることができる。第1の例として、ソース・ノンスを発生するようにソース・デバイス12を構成することができ(例えば、乱数または連続数あるいは文字列)、このソース・ノンスをセッション招待82に含めることができ、これによってセッション招待82をはっきりと特定する。セッション招待82を受け取ったとき、ターゲット・デバイス14は、ソース・ノンスを検証するように構成することができる(例えば、同じソース・ノンスを有するセッション招待82を以前に受け取っていないことを確認することによって)。ソース・ノンスを検証するとき、ターゲット・デバイス14はセッション受入84をソース・デバイス12に送信することができ、このソース・ノンスを、1組の既に受け取ったソース・ノンスに記録することができる。加えて、ターゲット・デバイス14はソース・ノンスをセッション受入84に含めることができ、セッション招待82に応答するときに、ターゲット・デバイス14の個体情報を更に認証することができる(例えば、第三者が、以前に受け取ったセッション受入84に回答することによって、ターゲット・デバイス14になりすまそうとすることもあり得るが、セッション受入84においてソース・ノンスが一致しないと、ソース・デバイス12になりすましを警告することができる)。代わりにまたは加えて、ターゲット・デバイス14がターゲット・ノンスを発生することができ、このターゲット・ノンスをセッション受入84に含ませることもできる。セッション受入84を受け取ったときに、ソース・デバイス12は、ターゲット・デバイス14との通信セッション32を開始する前に、ターゲット・ノンスを検証することができる。
【0040】
[0050] 図10は、本明細書において紹介した技法にしたがって通信セッション32を確立しようとするソース・デバイス12およびターゲット・デバイス14を描写し、更にソース・ノンス172の使用を描写するシナリオ例170を示す。ソース・デバイス12は、ターゲット公開証明書72によって暗号化されたセッション招待82を発生し、ターゲット・デバイス14に送ることによって、通信セッション32を開始することを要求することができる。しかしながら、セッション招待82は、(他のエレメントに加えて)ランダムに発生された数値のような、ソース・ノンス172を含むことができる。ターゲット・デバイス14は、セッション招待82を受け取り、ソース・ノンス172が重要な役割を果たすセッション招待82を以前に受け取っていないことを確認することができる。ソース・ノンス172を確認することに成功すると、ターゲット・デバイス14は、ソース公開証明書66によって暗号化され、そして(他のエレメントに加えて)ソース・ノンス172を含むセッション受入84を発生し、ソース・デバイス12に送ることができる。ソース・デバイス12は、通信セッション32を開始する前に、セッション受入84において受け取ったソース・ノンス172が、セッション招待82において送られたソース・ノンス172と一致することを検証することができる。
【0041】
[0051] 図10のこのシナリオ例170においてソース・ノンス172を含ませることによって、少なくとも2つの面で通信セッション32のセキュリティーを改善することができる。第1に、第三者174はセッション招待82を傍受し、その後このセッション招待82をターゲット・デバイス14に送ることによってターゲット・デバイス14との別の通信セッション32を開始しようとし、これによって、ソース・デバイス12になりすますことがある。ターゲット・デバイス14は、再送信されたセッション招待82に含まれるソース・ノンス172を、ソース・デバイス12によってセッション招待82の最初の送信において既に受信されたものとして特定することができ、したがって第三者174との通信セッション32の開始を拒否することができる。第2に、第三者174は、ターゲット・デバイス14からソース・デバイス12に送信されたセッション受入84を、第1通信セッション開始の間に取り込むことがある。ソース・デバイス12によるターゲット・デバイス14との第2通信セッションを確立しようとするその後の試みにおいて、第三者174は次にセッション受入84を再送信することによって、ターゲット・デバイス14になりすまそうとすることができるが、第2セッション招待82におけるソース・ノンス172が、再送信されたセッション受入84において第三者174によって戻されたソース・ノンス172と一致しないことになり、これによって、ソース・デバイス12になりすましを警告する。尚、 当業者であれば、本明細書において論じられた技法を実施しつつ、ソース・デバイス12および/またはターゲット・デバイス14によって発生するノンスについて多くの用法を考案できるであろう。
【0042】
[0052] 以上、構造的特徴および/または方法論的動作に特定的な文言で主題について説明したが、添付した特許請求の範囲において定義されている主題は、必ずしも前述した特定の特徴や動作に限定されるのではないことは言うまでもない。逆に、前述した特定的な特徴や動作は、特許請求の範囲を実施する形態例として開示したまでである。
【0043】
[0053] 本願において用いる場合、「コンポーネント」、「モジュール」、「システム」、「インターフェース」などという用語は、一般に、コンピューター関連エンティティ、ハードウェア、ハードウェアおよびソフトウェアの組み合わせ、ソフトウェア、または実行中のソフトウェアのいずれかを指すことを意図している。例えば、コンポーネントは、限定ではなく、プロセッサーにおいて実行しているプロセス、プロセッサー、オブジェクト、エクゼキュータブル、実行のスレッド、プログラム、および/またはコンピューターであってもよい。例示として、コントローラーにおいて実行しているアプリケーションおよびこのコントローラーの双方が1つのコンポーネントになることができる。1つ以上のコンポーネントは、プロセスおよび/または実行のスレッドの内部に存在することができ、コンポーネントを1つのコンピューターに配置すること、および/または2つ以上のコンピューター間で分散することもできる。
【0044】
[0054] 更に、特許請求する主題は、方法、装置、あるいはソフトウェア、ファームウェア、ハードウェアを生産するための標準的なプログラミングおよび/または設計技法を用いた製造の品目、あるいは開示した主題を実現するようにコンピューターを制御するための組み合わせであればそのいずれとして実現することもできる。「製造の品目」という用語は、本明細書において用いられる場合、いずれかのコンピューター読み取り可能デバイス、担体(carrier)、または媒体からアクセス可能なコンピューター・プログラムを包含することを意図している。勿論、特許請求する主題の範囲や主旨から逸脱することなく、この構成に多くの変更を行い得ることは、当業者には認められよう。
【0045】
[0055] 図11および以下の論述は、本明細書において明示した機能(facilities)の1つ以上の実施形態を実現するのに適した計算環境の端的な総合的説明を行うためにある。図11の動作環境は、適した動作環境の一例に過ぎず、動作環境の使用範囲や機能について何の限定を示唆することも意図していない。計算機の例には、限定ではなく、パーソナル・コンピューター、サーバー・コンピューター、ハンド・ヘルドまたはラップトップ・デバイス、移動体デバイス(移動体電話機、パーソナル・ディジタル・アシスタント(PDA),メディア・プレーヤー等)、マルチプロセッサー・システム、消費者用電子機器、ミニ・コンピューター、メインフレーム・コンピューター、以上のシステムまたはデバイスの内いずれかを含む分散方計算環境などが含まれる。
【0046】
[0056] 必須ではないが、1つ以上の計算機によって実行される「コンピューター読み取り可能命令」という一般的なコンテキストで、実施形態が説明されている。コンピューター読み取り可能命令は、コンピューター読み取り可能媒体(以下で論ずる)を通じて分散することもできる。コンピューター読み取り可能命令は、関数、オブジェクト、アプリケーション・プログラミング・インターフェース(API)、データー構造などのようなプログラム・モジュールとして実現することができ、特定のタスクを実行するか、または特定の抽象データー・タイプを実装する。通例、コンピューター読み取り可能命令の機能は、種々の環境における所望に応じて、組み合わせることまたは分散することができる。
【0047】
[0057] 図11は、本明細書において示した1つ以上の実施形態を実現するように構成されている計算機182を備えているシステム180の一例を示す。一構成では、計算機182は少なくとも1つの演算装置186およびメモリー188を含む。計算機の正確な構成およびタイプに応じて、メモリー188は揮発性(例えば、RAMのような)、不揮発性(例えば、ROM、フラッシュ・メモリー等のような)、またはこれら2つの何らかの組み合わせとすることができる。この構成は、図11では破線184で示されている。
【0048】
[0058] 他の実施形態では、計算機182は追加の機構および/または機能を含むこともできる。例えば、計算機182は、追加のストレージ(例えば、リムーバブルおよび/または非リムーバブル)も含むことができる。限定ではなく、追加のストレージには、磁気ストレージ、光ストレージ等が含まれる。このような追加のストレージは、図11ではストレージ190によって例示されている。一実施形態では、本明細書において示した1つ以上の実施形態を実現するコンピューター読み取り可能命令は、ストレージ190の中にあるとよい。また、ストレージ190は、オペレーティング・システム、アプリケーション・プログラム等を実装するために、他のコンピューター読み取り可能命令も格納することができる。コンピューター読み取り可能命令は、例えば、演算装置186による実行のために、メモリー188にロードすることができる。
【0049】
[0059] 「コンピューター読み取り可能媒体」という用語は、本明細書において用いる場合、コンピューター記憶媒体を含む。コンピューター記憶媒体は、揮発性および不揮発性、リムーバブルおよび非リムーバブル媒体を含み、コンピューター読み取り可能命令または他のデーターのような情報の格納のためのいずれかの方法または技術で実現されている。メモリー188およびストレージ190は、コンピューター記憶媒体の例である。コンピューター記憶媒体は、限定ではなく、RAM、ROM、EEPROM、フラッシュ・メモリーまたはその他のメモリー技術、CD−ROM、ディジタル・バーサタイル・ディスク(DVD)またはその他の光ストレージ、磁気カセット、磁気テープ、磁気ディスク・ストレージまたはその他の磁気記憶デバイス、あるいは所望の情報を格納するために用いることができその上計算機182によってアクセスすることができるのであれば他のいずれの媒体をも含む。このようなコンピューター記憶媒体は、そのいずれもが計算機182の一部となってもよい。
【0050】
[0060] また、計算機182は、計算機182が他のデバイスと通信することを可能にする通信接続(1つまたは複数)196も含むことができる。通信接続(1つまたは複数)196は、限定ではなく、モデム、ネットワーク・インターフェース・カード(NIC)、統合ネットワーク・インターフェース、無線周波数送信機/受信機、赤外線ポート、USB接続、または計算機182を他の計算機と接続するためのその他のインターフェースを含むことができる。通信接続(1つまたは複数)196は、有線接続またはワイヤレス接続を含むことができる。通信接続(1つまたは複数)196は、通信媒体を送信および/または受信することができる。
【0051】
[0061] 「コンピューター読み取り可能媒体」という用語は、通信媒体を含むことができる。通信媒体は、通例、搬送波またはその他の伝達メカニズムのような「変調データー信号」にコンピューター読み取り可能命令またはその他のデーターを具体化し、いずれの情報配信媒体も含む。「変調データー信号」という用語は、情報を信号内に符号化するような態様で設定または変更したその特性の1つ以上を有する信号を含むことができる。
【0052】
[0062] 計算機182は、キーボード、マウス、ペン、音声入力デバイス、接触入力デバイス、赤外線カメラ、ビデオ入力デバイス、および/またはその他のあらゆる入力デバイスというような、入力デバイス(1つまたは複数)194を含むことができる。1つ以上のディスプレイ、スピーカー、プリンター、および/またはその他の出力デバイスというような出力デバイス(1つまたは複数)192も、計算機182に含むことができる。入力デバイス(1つまたは複数)194および出力デバイス(1つまたは複数)192は、有線接続、ワイヤレス接続、またはそのいずれの組み合わせによってでも、計算機182に接続することができる。一実施形態では、別の計算機からの入力デバイスまたは出力デバイスを、計算機182用の入力デバイス(1つまたは複数)194または出力デバイス(1つまたは複数)192として用いることもできる。
【0053】
[0063] 計算機182のコンポーネントは、バスのような、種々の相互接続によって接続することができる。このような相互接続は、PCI Expressのようなペリフェラル・コンポーネント相互接続(PCI)、ユニバーサル・シリアル・バス(USB)、ファイアワイヤ(IEEE1394)、光バス構造などを含むことができる。別の実施形態では、計算機182のコンポーネントは、ネットワークで相互接続することができる。例えば、メモリー188は、ネットワークによって相互接続されている異なる物理的位置にある多数の物理的メモリー・ユニットによって構成することもできる。
【0054】
[0064] コンピューター読み取り可能命令を格納するために利用される記憶デバイスは、ネットワークに跨って分散させてもよいことは、当業者には分かるであろう。例えば、ネットワーク198を通じてアクセス可能な計算機200は、本明細書において提唱した1つ以上の実施形態を実現するために、コンピューター読み取り可能命令を格納することができる。計算機182は、計算機200にアクセスし、コンピューター読み取り可能命令の一部または全部を実行のためにダウンロードすることができる。あるいは、計算機182は、必要に応じて、コンピューター読み取り可能命令の断片をダウンロードすることができ、または一部の命令を計算機182において実行し、一部を計算機200において実行することもできる。
【0055】
[0065] 本明細書では、実施形態の種々の動作について提唱した。一実施形態では、記載した動作の1つ以上が、1つ以上のコンピューター読み取り可能媒体上に格納されたコンピューター読み取り可能命令を構成することができ、計算機によって実行すると、当該計算機に、記載した動作を実行させる。これらの動作の一部または全部を記載した順序は、これらの動作に必然的な順序依存性があるように解釈すべきではない。この記載から援助を受けた当業者には、代わりの順序も認められよう。更に、本明細書において提唱した各実施形態において、全ての動作が必ずしも出てくる訳ではないことは言うまでもない。
【0056】
[0066] 更に、「一例の」という単語は、本明細書では、一例、実例、または例示としての役割を果たすことを意味するために用いられる。本明細書において「一例の」として記載される態様または設計はいずれも、他の態様または設計よりも有利であるとは必ずしも解釈されない。むしろ、一例のという用語の使用は、概念を具体的に紹介することを意図している。本明細書において用いる場合、「または」という用語は、排他的な「または」ではなく包含的な「または」を意味することを意図する。即ち、そうでないことが指定されていない限り、または文脈から明白でない限り、「XはAまたはBを採用する」とは、自然な包含的組み合わせ(permutation)のいずれでも意味することを意図する。即ち、XがAを採用する場合、XがBを採用する場合、またはXがAおよびBの双方を採用する場合、これらの実例のいずれにおいても、「XはAまたはBを採用する」が満たされる。加えて、冠詞「a」および「an」は、本願および添付した特許請求の範囲において用いられる場合、そうでないことが指定されていない限り、また文脈から単数形態を対象とすることが明白でない限り、「1つ以上」を意味するように通常解釈することができる。
【0057】
[0067] また、1つ以上の実施態様に関して本開示を示し説明したが、本明細書および添付図面の熟読および理解に基づいて、同等の変形や変更が当業者には想起されよう。本開示は、このような変更や変形を全て含み、以下の特許請求の範囲のみによって限定される。特に、以上で述べたコンポーネント(例えば、エレメント、リソース等)によって実行される種々の機能に関して、このようなコンポーネントを記載するために用いられた用語は、そうでないことが示されない限り、記載されたコンポーネント(例えば、機能的に同等な)の指定された機能を実行するのであれば、本開示のここで例示された実施態様例における機能を実行する、開示された構造に構造的に同等でなくても、いずれのコンポーネントにも対応することを意図している。加えて、本開示の特定的な機構を、様々な実施態様の内1つのみに関して開示したが、このような機構は、いずれの所与の用途または特定の用途にとっても望まれるまたは有利となるように、他の実施態様の1つ以上の別の機構と組み合わせることができる。更に、「含む」、「有している」(having)、「有する」(has)、「と」(with)という用語、またはその異形が詳細な説明または特許請求の範囲において用いられている限りにおいて、このような単語は、用語「備えている」(comprising)と同様に内包的であることを意図している。
【特許請求の範囲】
【請求項1】
プロセッサー(88)およびソース秘密鍵(64)を有するソース・デバイス(12)によって、ターゲット公開証明書(74)を有するターゲット・デバイス(14)との通信セッション(32)を確立する方法(90)であって、
ソース・セッション鍵(74)を発生し(96)、
ソース・アドレス(78)および前記ソース・セッション鍵(74)を備えているセッション招待(82)を前記ターゲット・デバイス(14)に送り、前記ターゲット公開証明書(72)を用いて前記セッション招待(82)を暗号化し、
前記ターゲット・デバイス(14)から、ターゲット・アドレス(78)およびターゲット・セッション鍵(76)を備えているセッション受入(84)を受け取ったとき(100)、
前記ソース秘密鍵(64)を用いて前記セッション受入(84)を解読し(102)、
前記ソース・セッション鍵(74)および前記ターゲット・セッション鍵(76)を用いて、セッション鍵(86)を発生し(104)、
前記ターゲット・アドレス(78)で前記ターゲット・デバイス(14)との通信セッション(32)を開始し(106)、前記セッション鍵(86)を用いて前記通信セッション(32)を暗号化する、
ように構成されている命令を前記プロセッサー(88)上において実行するステップ(94)を備えている、方法(90)。
【請求項2】
請求項1記載の方法において、前記ソース・デバイスおよび前記ターゲット・デバイスが、計算環境ホストによってホストされている、配備可能な計算環境において表されている、方法。
【請求項3】
請求項1記載の方法において、
前記ソース・セッション鍵が、第1のランダムに発生した鍵を備えており、
前記ターゲット・セッション鍵が、第2のランダムに発生した鍵を備えており、
前記セッション鍵が、前記第1のランダムに発生した鍵および前記第2のランダムに発生した鍵を用いて発生した対称ランダム・セッション鍵を備えている、方法。
【請求項4】
請求項1記載の方法において、
前記セッション鍵を発生する命令が、少なくとも2つのセッション鍵を備えているセッション鍵集合を発生する命令を含み、それぞれのセッション鍵が、前記ソース・セッション鍵および前記ターゲット・セッション鍵を用いて発生され、前記セッション鍵集合における他のセッション鍵とは異なり、
前記通信セッションを開始する命令が、前記ターゲット・アドレスにおいて前記ターゲット・デバイスとの通信セッションを開始する命令を含み、第1セッション鍵を用いて前記通信セッションを暗号化し、
前記方法が、前記通信セッションを開始した後、
前記セッション鍵集合から第2セッション鍵を選択するステップと、
前記第2セッション鍵を用いて、前記通信セッションを暗号化するステップと、
を備えている、方法。
【請求項5】
請求項1記載の方法において、
前記ソース・デバイスをソース・ユーザーによって動作させ、
前記ターゲット・デバイスをターゲット・ユーザーによって動作させ、
前記セッション受入が、ターゲット・ユーザー認証部を備えており、前記通信セッションを開始する命令が、
前記ターゲット・ユーザー認証部を用いて前記ターゲット・ユーザーを検証する命令と、
前記ターゲット・ユーザーを検証したときに、前記ターゲット・デバイスとの通信セッションを開始し、前記セッション鍵を用いて前記通信セッションを暗号化する命令と、
を含む、方法。
【請求項6】
請求項1記載の方法において、
前記ソース・デバイスが証明書キャッシュを備えており、
前記命令が、
前記ターゲット・デバイスのターゲット公開証明書を得たときに、前記証明書キャッシュに前記ターゲット公開証明書を格納し、
前記ターゲット公開証明書を前記証明書キャッシュから読み出すことによって、前記ターゲット・デバイスとの後続の通信セッションを確立する、
ように構成されている、方法。
【請求項7】
請求項1記載の方法において、
前記セッション受入が、少なくとも2つの候補ターゲット・アドレスを備えており、
前記ターゲット・デバイスとの通信セッションを開始する命令が、
前記少なくとも2つの候補ターゲット・アドレスの中から少なくとも1つを選択する命令と、
少なくとも1つの選択したターゲット・アドレスにおいて、前記ターゲット・デバイスとの通信セッションを開始し、前記セッション鍵を用いて前記通信セッションを暗号化する命令と、
を含む、方法。
【請求項8】
請求項1記載の方法において、
前記セッション受入が、前記ソース・デバイスがセッション招待を送る前記ターゲット・デバイスのターゲット・アドレスとは異なる候補ターゲット・アドレスを備えており、
前記通信セッションを開始する命令が、前記候補ターゲット・アドレスにおいて前記ターゲット・デバイスとの通信セッションを開始し、前記セッション鍵を用いて前記通信セッションを暗号化する命令を含む、方法。
【請求項9】
請求項1記載の方法において、
前記命令が、ソース・ノンスを発生するように構成されており、
前記セッション招待が、ソース・ノンスを備えている、方法。
【請求項10】
請求項1記載の方法において、
前記セッション受入が、ターゲット・ノンスを備えており、
前記通信セッションを開始する命令が、
前記ターゲット・ノンスを検証する命令と、
前記ターゲット・ノンスを検証したときに、前記ターゲット・デバイスとの通信セッションを開始し、前記セッション鍵を用いて前記通信セッションを暗号化する命令と、
を含む、方法。
【請求項11】
プロセッサー(88)およびターゲット秘密鍵(70)を有するターゲット・デバイス(14)によって、ソース公開証明書(66)を有するソース・デバイス(12)との通信セッション(32)を確立する方法(110)であって、
前記ソース・デバイス(12)から、ソース・セッション鍵(74)を備えているセッション招待(82)を受け取った(116)ときに、
前記ターゲット秘密鍵(70)を用いて前記セッション招待(82)を解読し(118)、
ターゲット・セッション鍵(76)を発生し(120)、
前記ソース・セッション鍵(74)および前記ターゲット・セッション鍵(76)を用いて、セッション鍵(86)を発生し(122)、
ターゲット・アドレス(78)および前記ターゲット・セッション鍵(76)を備えているセッション受入(84)を、前記ソース・デバイス(12)に送信し(24)、前記ソース公開証明書(66)を用いて前記セッション受入(84)を暗号化し、
前記ソース・デバイス(12)から通信セッション(32)の開始を受け取ったとき、前記ソース・アドレス(78)で前記ソース・デバイス(12)との通信セッション(32)を開始し(126)、前記セッション鍵(86)を用いて前記通信セッション(32)を暗号化する、
ように構成されている命令を前記プロセッサー(88)上で実行するステップ(114)を備えている、方法。
【請求項12】
請求項11記載の方法において、
前記セッション招待が、前記ソース・デバイスが前記セッション招待を送った前記ソース・デバイスのソース・アドレスとは異なる候補ソース・アドレスを備えており、
前記通信セッションを開始する命令が、前記候補アドレスにおいて前記ソース・デバイスとの通信セッションを開始し、前記セッション鍵を用いて前記通信セッションを暗号化する命令を含む、方法。
【請求項13】
請求項11記載の方法において、
前記ターゲット・デバイスが、少なくとも2つの候補ターゲット・アドレスにおいてアクセス可能であり、
前記セッション受入が、前記少なくとも2つの候補ターゲット・アドレスを備えており、
前記通信セッションが、前記ソース・デバイスによって、少なくとも1つの候補ターゲット・アドレスに対して開始される、方法。
【請求項14】
請求項11記載の方法において、
前記セッション招待が、ソース・ノンスを備えており、
前記命令が、前記セッション招待を受け取ったときに、
前記ソース・ノンスを検証し、
前記ソース・ノンスを検証したとき、前記セッション受入を前記ソース・デバイスに送信するように構成されている、方法。
【請求項15】
命令を備えているコンピューター読み取り可能記憶媒体(132)であって、ソース・ユーザーによって動作させられ、証明書キャッシュ(164)とソース秘密鍵(64)とを備え、少なくとも1つのソース・アドレス(78)を有するソース・デバイス(12)が、計算環境ホスト(142)によってホストされた配備可能な計算環境(144)において表されており、この計算環境(144)が、ターゲット・ユーザーによって動作させられ少なくとも1つのターゲット・アドレス(78)を有するターゲット・デバイス(14)も表し、前記ソース・デバイス(12)が、前記ターゲット・デバイス(14)を特定するターゲット公開証明書(72)を含む少なくとも1つの公開証明書を備えている証明書サーバー(162)にアクセスすることができ、前記ソース・デバイス(12)のプロセッサー(88)上において前記命令を実行すると、
前記証明書サーバー(162)から前記ターゲット・デバイス(14)の前記ターゲット公開証明書(72)を得て、
前記証明書キャッシュ(164)に前記ターゲット公開証明書(72)を格納し、
ソース・セッション鍵(74)を発生し、
ソース・ノンス(172)を発生し、
前記少なくとも1つのソース・アドレス(78)と、前記ソース・セッション鍵(74)と、前記ソース・ノンス(172)とを備えているセッション招待(82)を、前記ターゲット・デバイス(14)に送信し、前記ターゲット公開証明書(72)を用いて前記セッション招待(82)を暗号化し、
前記ターゲット・デバイス(14)から、前記少なくとも1つの候補ターゲット・アドレス(78)と、ターゲット・セッション鍵(76)と、ターゲット・ノンスと、ターゲット・ユーザー認証部とを備えているセッション受入(84)を受け取ったときに、
前記ソース秘密鍵(64)を用いて前記セッション受入(84)を解読し、
前記ターゲット・ノンスを検証し、
前記ターゲット・ユーザー認証部を用いて、前記ターゲット・ユーザーを検証し、
前記ターゲット・ユーザーおよび前記ターゲット・ノンスを検証したときに、
前記少なくとも2つの候補ターゲット・アドレス(78)の中から少なくとも1つのターゲット・アドレス(78)を選択し、
前記ソース・セッション鍵(74)および前記ターゲット・セッション鍵(76)を用いて、セッション鍵(86)を発生し、
前記選択したターゲット・アドレス(78)で前記ターゲット・デバイス(14)との通信セッション(32)を開始し、前記セッション鍵(86)を用いて前記通信セッション(32)を暗号化し、
前記証明書キャッシュ(164)から前記ターゲット公開証明書(72)を読み出すことによって、前記ターゲット・デバイス(14)との後続の通信セッション(32)を確立する、
ことによって前記ターゲット・デバイス(14)との通信セッション(32)を確立する、コンピューター読み取り可能記憶媒体。
【請求項1】
プロセッサー(88)およびソース秘密鍵(64)を有するソース・デバイス(12)によって、ターゲット公開証明書(74)を有するターゲット・デバイス(14)との通信セッション(32)を確立する方法(90)であって、
ソース・セッション鍵(74)を発生し(96)、
ソース・アドレス(78)および前記ソース・セッション鍵(74)を備えているセッション招待(82)を前記ターゲット・デバイス(14)に送り、前記ターゲット公開証明書(72)を用いて前記セッション招待(82)を暗号化し、
前記ターゲット・デバイス(14)から、ターゲット・アドレス(78)およびターゲット・セッション鍵(76)を備えているセッション受入(84)を受け取ったとき(100)、
前記ソース秘密鍵(64)を用いて前記セッション受入(84)を解読し(102)、
前記ソース・セッション鍵(74)および前記ターゲット・セッション鍵(76)を用いて、セッション鍵(86)を発生し(104)、
前記ターゲット・アドレス(78)で前記ターゲット・デバイス(14)との通信セッション(32)を開始し(106)、前記セッション鍵(86)を用いて前記通信セッション(32)を暗号化する、
ように構成されている命令を前記プロセッサー(88)上において実行するステップ(94)を備えている、方法(90)。
【請求項2】
請求項1記載の方法において、前記ソース・デバイスおよび前記ターゲット・デバイスが、計算環境ホストによってホストされている、配備可能な計算環境において表されている、方法。
【請求項3】
請求項1記載の方法において、
前記ソース・セッション鍵が、第1のランダムに発生した鍵を備えており、
前記ターゲット・セッション鍵が、第2のランダムに発生した鍵を備えており、
前記セッション鍵が、前記第1のランダムに発生した鍵および前記第2のランダムに発生した鍵を用いて発生した対称ランダム・セッション鍵を備えている、方法。
【請求項4】
請求項1記載の方法において、
前記セッション鍵を発生する命令が、少なくとも2つのセッション鍵を備えているセッション鍵集合を発生する命令を含み、それぞれのセッション鍵が、前記ソース・セッション鍵および前記ターゲット・セッション鍵を用いて発生され、前記セッション鍵集合における他のセッション鍵とは異なり、
前記通信セッションを開始する命令が、前記ターゲット・アドレスにおいて前記ターゲット・デバイスとの通信セッションを開始する命令を含み、第1セッション鍵を用いて前記通信セッションを暗号化し、
前記方法が、前記通信セッションを開始した後、
前記セッション鍵集合から第2セッション鍵を選択するステップと、
前記第2セッション鍵を用いて、前記通信セッションを暗号化するステップと、
を備えている、方法。
【請求項5】
請求項1記載の方法において、
前記ソース・デバイスをソース・ユーザーによって動作させ、
前記ターゲット・デバイスをターゲット・ユーザーによって動作させ、
前記セッション受入が、ターゲット・ユーザー認証部を備えており、前記通信セッションを開始する命令が、
前記ターゲット・ユーザー認証部を用いて前記ターゲット・ユーザーを検証する命令と、
前記ターゲット・ユーザーを検証したときに、前記ターゲット・デバイスとの通信セッションを開始し、前記セッション鍵を用いて前記通信セッションを暗号化する命令と、
を含む、方法。
【請求項6】
請求項1記載の方法において、
前記ソース・デバイスが証明書キャッシュを備えており、
前記命令が、
前記ターゲット・デバイスのターゲット公開証明書を得たときに、前記証明書キャッシュに前記ターゲット公開証明書を格納し、
前記ターゲット公開証明書を前記証明書キャッシュから読み出すことによって、前記ターゲット・デバイスとの後続の通信セッションを確立する、
ように構成されている、方法。
【請求項7】
請求項1記載の方法において、
前記セッション受入が、少なくとも2つの候補ターゲット・アドレスを備えており、
前記ターゲット・デバイスとの通信セッションを開始する命令が、
前記少なくとも2つの候補ターゲット・アドレスの中から少なくとも1つを選択する命令と、
少なくとも1つの選択したターゲット・アドレスにおいて、前記ターゲット・デバイスとの通信セッションを開始し、前記セッション鍵を用いて前記通信セッションを暗号化する命令と、
を含む、方法。
【請求項8】
請求項1記載の方法において、
前記セッション受入が、前記ソース・デバイスがセッション招待を送る前記ターゲット・デバイスのターゲット・アドレスとは異なる候補ターゲット・アドレスを備えており、
前記通信セッションを開始する命令が、前記候補ターゲット・アドレスにおいて前記ターゲット・デバイスとの通信セッションを開始し、前記セッション鍵を用いて前記通信セッションを暗号化する命令を含む、方法。
【請求項9】
請求項1記載の方法において、
前記命令が、ソース・ノンスを発生するように構成されており、
前記セッション招待が、ソース・ノンスを備えている、方法。
【請求項10】
請求項1記載の方法において、
前記セッション受入が、ターゲット・ノンスを備えており、
前記通信セッションを開始する命令が、
前記ターゲット・ノンスを検証する命令と、
前記ターゲット・ノンスを検証したときに、前記ターゲット・デバイスとの通信セッションを開始し、前記セッション鍵を用いて前記通信セッションを暗号化する命令と、
を含む、方法。
【請求項11】
プロセッサー(88)およびターゲット秘密鍵(70)を有するターゲット・デバイス(14)によって、ソース公開証明書(66)を有するソース・デバイス(12)との通信セッション(32)を確立する方法(110)であって、
前記ソース・デバイス(12)から、ソース・セッション鍵(74)を備えているセッション招待(82)を受け取った(116)ときに、
前記ターゲット秘密鍵(70)を用いて前記セッション招待(82)を解読し(118)、
ターゲット・セッション鍵(76)を発生し(120)、
前記ソース・セッション鍵(74)および前記ターゲット・セッション鍵(76)を用いて、セッション鍵(86)を発生し(122)、
ターゲット・アドレス(78)および前記ターゲット・セッション鍵(76)を備えているセッション受入(84)を、前記ソース・デバイス(12)に送信し(24)、前記ソース公開証明書(66)を用いて前記セッション受入(84)を暗号化し、
前記ソース・デバイス(12)から通信セッション(32)の開始を受け取ったとき、前記ソース・アドレス(78)で前記ソース・デバイス(12)との通信セッション(32)を開始し(126)、前記セッション鍵(86)を用いて前記通信セッション(32)を暗号化する、
ように構成されている命令を前記プロセッサー(88)上で実行するステップ(114)を備えている、方法。
【請求項12】
請求項11記載の方法において、
前記セッション招待が、前記ソース・デバイスが前記セッション招待を送った前記ソース・デバイスのソース・アドレスとは異なる候補ソース・アドレスを備えており、
前記通信セッションを開始する命令が、前記候補アドレスにおいて前記ソース・デバイスとの通信セッションを開始し、前記セッション鍵を用いて前記通信セッションを暗号化する命令を含む、方法。
【請求項13】
請求項11記載の方法において、
前記ターゲット・デバイスが、少なくとも2つの候補ターゲット・アドレスにおいてアクセス可能であり、
前記セッション受入が、前記少なくとも2つの候補ターゲット・アドレスを備えており、
前記通信セッションが、前記ソース・デバイスによって、少なくとも1つの候補ターゲット・アドレスに対して開始される、方法。
【請求項14】
請求項11記載の方法において、
前記セッション招待が、ソース・ノンスを備えており、
前記命令が、前記セッション招待を受け取ったときに、
前記ソース・ノンスを検証し、
前記ソース・ノンスを検証したとき、前記セッション受入を前記ソース・デバイスに送信するように構成されている、方法。
【請求項15】
命令を備えているコンピューター読み取り可能記憶媒体(132)であって、ソース・ユーザーによって動作させられ、証明書キャッシュ(164)とソース秘密鍵(64)とを備え、少なくとも1つのソース・アドレス(78)を有するソース・デバイス(12)が、計算環境ホスト(142)によってホストされた配備可能な計算環境(144)において表されており、この計算環境(144)が、ターゲット・ユーザーによって動作させられ少なくとも1つのターゲット・アドレス(78)を有するターゲット・デバイス(14)も表し、前記ソース・デバイス(12)が、前記ターゲット・デバイス(14)を特定するターゲット公開証明書(72)を含む少なくとも1つの公開証明書を備えている証明書サーバー(162)にアクセスすることができ、前記ソース・デバイス(12)のプロセッサー(88)上において前記命令を実行すると、
前記証明書サーバー(162)から前記ターゲット・デバイス(14)の前記ターゲット公開証明書(72)を得て、
前記証明書キャッシュ(164)に前記ターゲット公開証明書(72)を格納し、
ソース・セッション鍵(74)を発生し、
ソース・ノンス(172)を発生し、
前記少なくとも1つのソース・アドレス(78)と、前記ソース・セッション鍵(74)と、前記ソース・ノンス(172)とを備えているセッション招待(82)を、前記ターゲット・デバイス(14)に送信し、前記ターゲット公開証明書(72)を用いて前記セッション招待(82)を暗号化し、
前記ターゲット・デバイス(14)から、前記少なくとも1つの候補ターゲット・アドレス(78)と、ターゲット・セッション鍵(76)と、ターゲット・ノンスと、ターゲット・ユーザー認証部とを備えているセッション受入(84)を受け取ったときに、
前記ソース秘密鍵(64)を用いて前記セッション受入(84)を解読し、
前記ターゲット・ノンスを検証し、
前記ターゲット・ユーザー認証部を用いて、前記ターゲット・ユーザーを検証し、
前記ターゲット・ユーザーおよび前記ターゲット・ノンスを検証したときに、
前記少なくとも2つの候補ターゲット・アドレス(78)の中から少なくとも1つのターゲット・アドレス(78)を選択し、
前記ソース・セッション鍵(74)および前記ターゲット・セッション鍵(76)を用いて、セッション鍵(86)を発生し、
前記選択したターゲット・アドレス(78)で前記ターゲット・デバイス(14)との通信セッション(32)を開始し、前記セッション鍵(86)を用いて前記通信セッション(32)を暗号化し、
前記証明書キャッシュ(164)から前記ターゲット公開証明書(72)を読み出すことによって、前記ターゲット・デバイス(14)との後続の通信セッション(32)を確立する、
ことによって前記ターゲット・デバイス(14)との通信セッション(32)を確立する、コンピューター読み取り可能記憶媒体。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【公表番号】特表2013−509089(P2013−509089A)
【公表日】平成25年3月7日(2013.3.7)
【国際特許分類】
【出願番号】特願2012−535215(P2012−535215)
【出願日】平成22年9月24日(2010.9.24)
【国際出願番号】PCT/US2010/050282
【国際公開番号】WO2011/049712
【国際公開日】平成23年4月28日(2011.4.28)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.BLUETOOTH
2.EEPROM
【出願人】(500046438)マイクロソフト コーポレーション (3,165)
【Fターム(参考)】
【公表日】平成25年3月7日(2013.3.7)
【国際特許分類】
【出願日】平成22年9月24日(2010.9.24)
【国際出願番号】PCT/US2010/050282
【国際公開番号】WO2011/049712
【国際公開日】平成23年4月28日(2011.4.28)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.BLUETOOTH
2.EEPROM
【出願人】(500046438)マイクロソフト コーポレーション (3,165)
【Fターム(参考)】
[ Back to top ]