ネットワークセキュリティ方法およびネットワークセキュリティシステム
少なくとも１つのクライアントとリソース間において、セキュリティマネージャを介して安全なネットワーク通信を確立する方法およびシステム。セキュリティマネージャとクライアント間で信頼関係が確立されると、セキュリティマネージャは第１識別子をクライアントに送信する。クライアントは第１識別子をリソースへ転送する。リソースでは第１識別子の有効性が確立され、当該リソースからクライアントへセッションキーが送信される。このセッションキーを用いて、クライアントリソース間のネットワーク通信が行われる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はリソースと外部エンティティ間の通信に関する。
【０００２】
外部ユーザは、多数のデバイスに囲まれている。業務タスクを実行中、ユーザは単一のデバイスだけでなく、タスクの遂行に最も適したあらゆる実行可能な組み合わせを用いる。図１はこのシナリオを示したものである。企業ドメイン２００の視点から見れば、プライベートドメイン１００およびパーソナルドメイン３００は信頼された環境である。一方、ベアラードメイン４００は信頼されないドメインまたは信頼されたドメインである。
【０００３】
最新の分散アプリケーションは、リモートクライアントを始点とするトランザクション処理に多数のサーバが関与する多層アーキテクチャに基づく。これまで、クライアントは企業ネットワークドメイン２００に統合されるか、遠隔地に位置する場合はダイヤルイン接続、インターネット、仮想プライベートネットワーク（ＶＰＮ）、またはインターネットセキュリティＩＰsecの中の１つあるいはそれらの組み合わせで接続される。
【０００４】
無線技術によって、ユーザと各種の機器１０１、１０２、３０１、３０２、および３０３の相互間および企業ネットワーク２００とのモビリティが実現されるので、企業ネットワークリソース２０１、２０２、および２０３へのアクセスを許可する安全なモバイルアプリケーションに対する解決策が望まれている。
【０００５】
したがって、利用可能な認証メカニズムと、当該メカニズムの環境に対する適切な度合いを考えることが必要である。
【背景技術】
【０００６】
認証とは、人間、機械、あるいは処理を含むいずれかのエンティティ同士で行われる処理のことである。エンティティ同士は、データを交換してお互いのアイデンティティを確立する。
【０００７】
図２は一般的な認証プロトコルの流れを示す。この例は、ＰＰＰ（Ｐｏｉｎｔ ｔｏ Ｐｏｉｎｔ）拡張認証プロトコル（ＥＡＰ）を取り上げている。ＥＡＰは、ポイントツーポイントリンク上の通信相手同士の通信で使われる認証プロトコルである。基本的に、認証者２００はクライアント１０１に身元証明をリクエストする。この身元証明は、たとえばワンタイムパスワードやチャレンジ／レスポンス型認証の簡単なもの、あるいはセッションキーの配布とネゴシエーションを行う拡張認証プロトコル／トランスポート層セキュリティプロトコル（ＥＡＰ―ＴＬＳ）などの複雑なプロトコルである。
【０００８】
認証のリクエスト１４は、認証者２００から通信相手またはクライアント１０１に送られる。通信相手１０１は、レスポンス１５を返答し、このレスポンスは認証者２００によって認証される。認証の結果に基づいて、正のまたは負のフィードバック１６がクライアント１０１へ送信される。
【０００９】
図３に示されるラディウスプロトコルは、把握している通信中のすべてのエンティティに関する個々の識別データを保存する中央サーバ２０２に対して認証が行われる間接認証方式である。
【００１０】
ラディウスと同様に、図４に示されるケルベロスは間接認証方式である。ケルベロスはユーザを認証し、サービスごとに認証を行う。
【００１１】
所有者が他のエンティティと認証を行うことを可能にする、チケットと呼ばれる認証処理データの一部分が生成されると、認証プロトコルで２つのステップが行われる。第一にエンティティは、エンティティのアイデンティティを認証してチケット保証チケット１２５と呼ばれるチケットを返送するケルベロスサーバで認証を行う。第二に、その後特定リソース２０３へのアクセスを希望する場合、既に発行されているチケット保証チケット１２５を使ってエンティティは、チケット保証サービスと呼ばれる他のサーバに対してリソース特定チケット１２６の発行をリクエストする。このチケットを使って、自身の認証とリソース２０３へのアクセスをするために、エンティティは認承メッセージ１２７を作り、リソースをホストするサーバへ認承メッセージとリソース特定チケット１２６を送信する。
【００１２】
ケルベロスでは、認証処理を行っている間、ケルベロスサーバによってセッションキーが生成され、当該キーは生成されたチケットの一部として配布される。セッションキーは、データ送信の際の暗号化を行うために使われ、データの受信側で同じ鍵で復号化される。データの送受信に関連するすべての当事者は、使われた暗号鍵に関する同じ情報を共有する。
【００１３】
一般的に用いられる他の方法は、公開鍵暗号方式である。公開鍵暗号方式は暗号化および復号化に利用されるＲＳＡアルゴリズムなどのシステムを構築するために用いられる。公開鍵暗号方式はデジタル署名や鍵交換での使用にも好都合である。公開鍵暗号方式では、公開鍵と秘密鍵という鍵のペアを用いる。これらの鍵は暗号化および相互の復号化に用いられる。まず鍵のペアが生成される。秘密鍵はエンティティが保持し、公開鍵は第三者に公開される。公開鍵を公開する一般的な方法は、公開鍵インフラストラクチャ（ＰＫＩ）を使うことである。ＰＫＩは、証明書の概念を中心にする。簡単に言えば、証明書は身元証明である。証明書は、他のエンティティの固有データ中に、エンティティの公開鍵を含む。証明書は通常、認証機関（ＣＡ）として知られる第三者機関によって署名される。署名は認証機関の秘密鍵を用いて行われる。あるエンティティが他のエンティティと認証を行う場合、自分の証明書を使う。認証を呼びかけられたエンティティは、認証機関の公開鍵を用いて、認証を呼びかけたエンティティを認証する。エンティティが証明書を持つのは上記の理由からである。通信エンティティの公開鍵は、認証に加えて、特にセッションキーを交換するために公衆網を介してデータを送信する場合、当該データの暗号化に使われる。
【００１４】
エンティティにアイデンティティを与えるのは証明書という方法に限られない。セルフ・デリゲーションとして知られる方法では、プライマリキーとセカンダリキーのペアの概念を用いる。これは、プライマリキーのペアは秘密に保持され、セカンダリキーのペアは信頼されていないデバイスに転送されるという考えである。セカンダリキーのペアには、
プライマリ秘密鍵で署名され、セカンダリキーのペアのあらゆる身元証明はプライマリキーの身元証明と同じ効力があると記述された委任証明書が添付されている。
【００１５】
このシステムは、各々のセルフ・デリゲーションには限られた量の秘密情報のみが開示されるように設計されている。情報が限られているので、そこから有益なことは得ることができない。一方で、セルフ・デリゲーションの増加が一定数に達すると、エネミーが効率的にプライマリ秘密鍵を計算できるように制御されている。
【００１６】
上記のシナリオは新たな要望を生ぜしめる。第一に、基本的なネットワーク接続をユーザに提供するための適切な技術に関する要望である。第二に、企業ネットワークドメインへのアクセス制御に関する要望である。第三に、モバイルデバイスと企業ネットワーク間で送受信されるデータの秘匿性、インテグリティ、およびアカウンタビリティに関する要望である。ここで、上記の技術における安全性のあるモバイルデバイス用分散アプリケーションに対する要望を検討する。特に、提供されなければならないメカニズムは、次の点に対応する必要がある。
・ モバイルクライアントデバイス同士、およびモバイルクライアントデバイスと企業ネットワーク間の認証。
関連するすべての当事者が、その通信相手が保証されたエンティティであるという信用証明を持つように、相互認証が必要とされる。
・ 交換されたメッセージに秘匿性および統一性を与えるために、モバイルデバイス同士、およびモバイルデバイスと企業ネットワーク間など、当事者であるすべてのエンティティ間での安全なエンドツーエンド通信リンクの確立。
・ 通信への参加の間違った承認拒否に対する保護策としての、否認防止あるいは通信イベントのアカウンタビリティ。
【００１７】
拡張認証プロトコル、ラディウス、ケルベロス、公開鍵インフラストラクチャ、デリゲーションはいずれも複数のクライアントを対象とするものの、拡張認証プロトコル、ラディウス、ケルベロスはクライアントとサーバ間の相互認証は認めず、デリゲーションはそのような機能をサポートするようには必ずしも構成されていない。上述の技術は、いずれも異なるクライアント間の相互認証には対応していない。デリゲーション、公開鍵インフラストラクチャ、およびケルベロスは、キーネゴシエーションに対応しており、公開鍵インフラストラクチャで使われる証明書が必要になるが、ＰＰＰ−ＥＡＰ−ＴＬＳ認証プロトコルが実行されると、その機能がＥＡＰにおいてもサポートされる。ＥＡＰ、ケルベロス、公開鍵インフラストラクチャではすでにハッシュ機能が使われているが、データの統一性は問題とされておれず、上述の方法からはデータの統一性はなんら導かれない。しかしながら、データの認証は必要であって、キーイングデータの配布における余分な労力も考慮されなければならない。最後に、公開鍵インフラストラクチャおよびデリゲーションだけが否認防止を十分に考慮する。ケルベロスの場合、双方の通信エンティティが同じ鍵を持っていて、他方のエンティティのアイデンティティを模倣することができるので、セッションキーは否認防止の目的で使われない。
【発明の開示】
【発明が解決しようとする課題】
【００１８】
したがって、安全な通信およびデータネットワークを確立するための既存の技術を改良した方法、システム、およびデバイスの提供が待たれている。
【００１９】
本発明は、クライアントとリソースの間で安全なネットワーク通信を確立する方法に関する。この方法は次のステップを含む。
・ セキュリティマネージャとクライアント間で信頼関係を確立。
・ セキュリティマネージャで第１識別子１２４を生成し、それをセキュリティマネージャからクライアントへ送信。
・ 第１識別子１２４をクライアントからリソースへ転送。
・ リソースで第１識別子１２４の有効性を確立し、リソースからクライアントへ第１暗号化データ１３１へ送信。
・ クライアントとリソース間でその後のネットワーク通信１２を第１暗号化データ１３１を使って実行。
【００２０】
本発明はまた、クライアントとリソースの間で安全なネットワーク通信を確立する方法に関する。この方法は
・ 第１クライアントメディエータおよび第２クライアントメディエータが設けられたクライアントと、
・ 第１リソースメディエータおよび第２リソースメディエータが設けられたリソースと、
・ 第１識別子を生成し、それを第２クライアントメディエータへ送信するセキュリティマネージャとを備える。
【００２１】
ここで、第２クライアントメディエータと第２リソースメディエータは、クライアントとリソースとの間で信頼関係を確立可能なように構成される。
【００２２】
第２クライアントメディエータへの適用においては、第２クライアントメディエータが、
・ セキュリティマネージャから第１識別子１２４を受信し、
・ 認証のために、第１識別子１２４をリソースに送信し、
・ リソースから第１暗号化データ１３１を受信し、
・ 第１暗号化データ１３１を使って、リソースとの安全なネットワーク通信１２を行うように構成される。
【００２３】
第２リソースメディエータへの適用においては、第２リソースメディエータが、
・ 第１識別子の有効性を確立し、
・ 第１暗号化データ１３１をクライアントへ送信し、
・ 第１暗号化データ１３１を使って、クライアントとその後のネットワーク通信１２を行うように構成される。
【００２４】
本発明は、ネットワークで安全な通信を確立するためのセキュリティマネージャにおいて具体化される。このセキュリティマネージャは、第１識別子１２４を生成するとともに、この第１識別子１２４を、解読用にクライアントに組み込まれた第２クライアントメディエータに送信するように構成されている。第１識別子は、第２クライアントメディエータが当該命令を第２リソースメディエータに転送することを促す。また第１識別子は、
・ 第２リソースメディエータが前記第１命令を有効化するための有効化処理９と、
・ 第１暗号化データ１３１の第２クライアントメディエータへの送信と、
第１暗号化データ１３１を使用して、リソースとその後のネットワーク通信１２を行うことを促す。
【００２５】
また本発明は、リソースとの安全な通信を開始するように構成された、第１クライアントメディエータと第２クライアントメディエータを備えたクライアントで具体化される。クライアントは、第１クライアントメディエータの動作によって、セキュリティマネージャと信頼関係を確立するように構成されている。第２クライアントメディエータと、リソースに組み込まれた第２リソースメディエータは、各々、クライアントとリソース間で信頼関係を構築するように構成される。
【００２６】
第２クライアントメディエータへの適用においては、第２クライアントメディエータが、
・ セキュリティマネージャによって生成された第１識別子１２４をセキュリティマネージャから受信し、
・ リソースから第１暗号化データ１３１を受信し、
・ 第１暗号化データ１３１を使用しているリソースとその後のネットワーク通信１２を行うように構成される。
【００２７】
第２リソースメディエータへの適用においては、第２リソースメディエータが
・ 第１識別子１２４の有効性を確立し、
・ 第１暗号化データ１３１を送信し、
・ 第１暗号化データを使用して、クライアントとその後のネットワーク通信１２を行うように構成される。
【００２８】
また本発明は、ネットワーク上での安全な通信を開始するように、第１リソースメディエータの動作によってセキュリティマネージャと信頼関係を確立するように構成されたリソースにおいて具体化される。第２リソースメディエータは、
・ セキュリティマネージャによって生成されてクライアントへ送信された後にリソースに転送された第１識別子１２４の有効性を確立し、
・ ソースにおいて第１暗号化データ１３１をクライアントへ送信し、
・ 第１暗号化データを使って、クライアントとその後のネットワーク通信１２を実行するように構成されている。
【００２９】
発明の理解を促進し、それがどのようにして実行されるかを示すために、以下、添付の図面が例として参照される。
【発明を実施するための最良の形態】
【００３０】
本発明は、リソースと、モバイルクライアントなどの外部クライアント間での安全な通信の確立に特に好適である。リソースは格納されるか、アプリケーションサーバを介してアクセス可能なソフトウェアアプリケーションである。図１を参照して上記で述べたように、本発明が実行される典型的な環境は、プライベートネットワーク内のリソース２０１と、外部ユーザが自身のパーソナルドメイン３００などでリソースにアクセスするためのさまざまなネットワーククライアントデバイス３０１、３０２、または３０３のいずれか１つを含む。リソースは、ネットワークの一部２０２、２０３へのアクセスを制御することが可能なサーバ２０１など、プライベートネットワーク２００の構成要素を含んでもよい。リソースは、サーバが有する所与のデータ２０３の集合や、ネットワークを通じて配信されるものであってもよい。外部ユーザのパーソナルドメイン内のエンドシステムは、スマートカードから携帯電話、そしてラップトップコンピュータに至るまでを対象とする。デバイス同士は、ＣＰＵパワー、メモリ、ディスプレイの大きさなどの観点から互いに明らかに異なる。末端の例としてはスマートカードなどが挙げられ、上端の例としてラップトップコンピュータが考えられる。他方で、システムはフレキシブルであるほど、セキュリティ面の危険およびそれに対する攻撃にさらされやすい。外部ユーザは、無線手段、有線経路または有線チャネル、光学チャネル、あるいは関連技術の当業者が容易に思い浮かぶさまざまなタイプの通信チャネルのいずれか、またはそれらの組み合わせによって、所有する機器が互いに接続されているモバイルユーザであってもよい。多数の機器のいくつかあるいは全ては、プライベートネットワークと直接あるいはインターネットなどの公衆網４００を介して通信を行うための手段を備えている。通信は、無線手段、有線経路または有線チャネル、光学チャネル、あるいは関連技術の当業者に容易に思い浮かぶさまざまなタイプの通信チャネルのいずれか、あるいはそれらの組み合わせによって行われうる。接続の際には、認証プロトコルの実行に先立ってエンドツーエンドの接続が確立されるか、あるいは当該処理を中断することなく確立されることが前提である。
【００３１】
従業員などの外部ユーザは、分散アプリケーションの実行環境をさまざまな外部デバイスから選ぶことができる。大きなスプレッドシートを更新するにはラップトップコンピュータを使い、仕事の割り当てをチェックするアプリケーションがプライベートネットワーク内の各データにアクセスするには携帯電話だけで済ませるのが合理的である。
【００３２】
次の語句は明細書全体で使用される。補足説明は一例である。
【００３３】
認証違反：エンティティが、使用すべきでないリソースを使用すること。
【００３４】
アカウンタビリティ：すべての通信イベントの責任を負うエンティティを特定することが可能であるべきこと。
【００３５】
認証：人間あるいは機械またはアプリケーションのいずれかのアイデンティティ認証を実行するプロセスのこと。
【００３６】
利用可能性：アプリケーション、デバイス、およびサービスが利用可能であって、かつ、正確に動作すべきであること。
【００３７】
ベアラーデバイス：セキュリティマネージャを物理的にホストするモバイルデバイス。
【００３８】
証明書：信頼された第三者（認証機関）によって認証され、偽造から保護された、ユーザの信用証明の集合。
【００３９】
クライアント同盟：セキュリティマネージャと認証を行っており、安全なチャネル上でのデータ交換が可能なすべてのクライアントデバイス。
【００４０】
機密性：転送されるか格納されたデータは、その意図する閲覧者にのみ示されるべきであること。
【００４１】
制御されたアクセス：認証されたエンティティのみが特定のサービスまたはデータにアクセス可能であるべきこと。
【００４２】
データ保全性：データのあらゆる書き換えが検知されるべきであること。
【００４３】
通信行為の拒否（拒絶）：エンティティがトランザクションや通信イベントなどのイベントへの参加を不当に拒否すること。
【００４４】
傍受：エンティティが読み取り目的でないデータを読み取ること。
【００４５】
偽造：エンティティが他のエンティティ名義で新たなデータを作ること。
【００４６】
データの喪失または修正：エンティティは、受信したデータパケットのシーケンスの１つまたは複数のパケットが喪失したことを検知することができる。エンティティは、受信したデータパケットまたはその一部が警告されたことを検知することができる。
【００４７】
仮装：エンティティが他のエンティティであると主張すること。
【００４８】
本発明に係る実施形態によれば、安全な通信は複数の外部クライアントデバイスとリソース間で確立される。これは、たとえばプライベートネットワーク内のサーバが、複数のクライアントデバイスとリソースを認証し、認証されたクライアント同士、および認証されたクライアントとリソース間で暗号鍵などの暗号化データを配布することによって行われる。とりわけ、さまざまな外部デバイスとリソース間の仲介役であると同時に、認証されていないデバイスや偽造されたデバイスが改変もしくは信頼できない状態で通信に参加しないことを保証するために、セキュリティマネージャが提供される。安全性が保証されたクライアントドメインは、クライアント同盟と呼ばれる。セキュリティマネージャは、クライアントデバイス内に搭載されるか、それ自身に固有のネットワーク通信能力を有する。
【００４９】
企業の、すなわちリソースの所有者の視点から見た場合、セキュリティマネージャおよびその内部に保存されたユーザの信用証明は、外部ユーザのパーソナルドメイン内で唯一信頼される要素である。個々のクライアントデバイス間、およびクラインデバイスと企業ネットワーク間で安全なエンドツーエンドの接続を確立するために、セキュリティマネージャはクライアントデバイスを認証し、プライベートネットワークまたは企業ネットワークと認証をする際に使われる信用証明をクライアントデバイスに発行し、鍵の生成とデータ署名を実行するといった各機能を実現する。本発明は全体的には１つのクライアント、セキュリティマネージャ、およびサーバが含まれる通信を主題にしているが、当業者は、多数のクライアントデバイスが関連する通信への本発明の適用を正しく認識するだろう。
【００５０】
第一のステップとして外部ユーザは、たとえば正しいパスフレーズ（個人識別番号またはパスワード）を、セキュリティマネージャをホストするデバイスに入力してセキュリティマネージャを起動させるなど、ユーザインタフェースに秘密情報を供給することで自分が合法的なユーザであることを証明する。
【００５１】
クライアントデバイスは、他のクライアントデバイスと、プライベートネットワークの構成要素（私有サーバやその他のリソースなどの企業ドメイン）に対しても自己を証明する。リソースは、プライベートドメインまたは下記で示すネットワークに位置しうる。
【００５２】
上述したように、本発明の環境では一定の安全性が確保されることが望ましい。これは、アプリケーションサーバの役割を担うサーバ２０１が、通信相手またはクライアントエンティティの身元証明を有することを含む。これは認証と呼ばれる。リソースへのアクセスは、適切な認証メカニズム、あるいは認可機関として知られるものによって許可されなければならない。言い換えると、リソースへのアクセスは認証されたエンティティのみに対して許可される。最後にすべての通信イベントが、後に記録をたどることができるように明らかにされなければならない。これは否認防止として知られる。
【００５３】
クライアントを認証するために、リソースはまず認証要求をクライアントデバイスに送信する。この認証要求は、クライアントに関連するセキュリティマネージャに送信される。
【００５４】
セキュリティマネージャは、たとえばホストまたはベアラーデバイスの通信機能を使って携帯電話に組み込まれるか又は関連付けられてネットワーク通信に参加し、ユーザからのからのパスフレーズを要求する。このコードは、個人識別番号またはパスワードなどである。パスフレーズの認証が成功すると、セキュリティマネージャは引き続き認証処理を行う。これは実際には、セキュリティマネージャが組み込まれたホストデバイスの電源が投入される都度行われる。
【００５５】
セキュリティマネージャは、パラメータとしての自己の証明書など、自身の識別子とともに認証応答を返送する。この識別子は、リソースの所有者によって発行されることが好ましい。識別子は、たとえばセキュリティマネージャの公開鍵や、クライアントの公開鍵によって暗号化される。公開鍵は識別子に含まれてもよい。
【００５６】
リソースは、受信した識別子証明書を認証して、セッションホストの公開鍵などのセッションキーを生成し、当該セッションキーをホストまたはベアラーデバイスに返送する。言い換えると、認証確認が送信される。
【００５７】
相互認証が必要な場合、リソースは第一認証要求または認証確認のいずれかに対して自分の証明書などの識別子を送信する。ホストまたはベアラーデバイスは、あらかじめインストールされた認証機関の識別子を使って、リソースの識別子を認証することができる。
【００５８】
このシナリオは、ラップトップなどの分離したクライアントデバイスを追加することで拡張することができる。上述の方法と同様に、セキュリティマネージャは携帯電話によってホストされる。こうして認証および鍵のネゴシエーションと交換が、双方のモバイルデバイスで行われ、最終的にエンドツーエンド（Ｅ２Ｅ）の安全な接続が確立される。
【００５９】
クライアントデバイスは、セキュリティマネージャ・ホストデバイスおよびセキュリティマネージャを管理する企業によって発行されたものと同じ識別子を保持する。
【００６０】
信頼されたセキュリティマネージャとクライアントデバイスのクライアント同盟において、セキュリティマネージャはラップトップが証明書の合法的な所有者であることを保証するに過ぎない。たとえば、企業ネットワークなどのプライベートネットワーク内のサーバは、セキュリティマネージャからの署名などによって認証された証明書のみを受け取る。
【００６１】
次に、クライアントが第三者識別子を保持するケースを検討する。セキュリティマネージャは、識別子がエンティティに属するなど、識別子を認証するだけでなく、識別子とクライアントが互いに密接に関連することを認証する役割も担う。そして最後に、セキュリティマネージャはクライアントが信頼できることをリソースに証明しなければならない。
【００６２】
次に、図５に関する本発明の実施形態を述べる。
【００６３】
図５は、本発明の第一実施形態に係る、クライアントデバイスとリソース間で安全なネットワーク通信を確立する方法を示す。
【００６４】
この方法では、クライアント１１１と、リソース１１２が提供される。先行技術を参照して述べたように、クライアントは１または複数の外部デバイスに設けられ、通信相手またはクライアントの役割を担う。第２ネットワークエンティティは、上述したように、プライベートネットワークなどに設けられたサーバまたはリソースである。前記クライアントは、このサーバまたはリソースと相互作用してデータを受信する。本明細書ではセキュリティマネージャ、リソース、サーバなどのネットワークエンティティを取り上げているが、これらは本発明で記載されたタスクおよびその他の必要な動作をデバイスに実行させる、複数の付属的ハードウェアやソフトウェアなどを包含する。特にサーバまたはリソースは、企業ネットワークなどの完全に私的なものを含む。
【００６５】
本実施形態ではさらにセキュリティマネージャ１１３１が設けられる。セキュリティマネージャは、証明書および暗号鍵の格納と、暗号化・復号化、および鍵の生成とデータ署名の実行が可能な、不正操作が行われないデバイスである。
【００６６】
第１ネットワークエンティティまたはクライアント１１１と、セキュリティマネージャ・ホストデバイス１１３は、各々、ソフトウェア、ハードウェア、あるいはそれらのあらゆる組み合わせによって実行される。第１ネットワークエンティティまたはクライアント、およびセキュリティマネージャ・ホストデバイスは、各々、パーソナルコンピュータ（特にラップトップコンピュータ）、電話（特に携帯電話）、ページャ、PDA、あるいはネットワーク通信が可能なあらゆるデバイスなど、適切なファームウェアおよびソフトウェアを含む、独立型のネットワークデバイスである。１つの実施形態では、第１ネットワークエンティティ１１１またはクライアントデバイスは、ネットワーク通信を確立する手段を備えるラップトップコンピュータを含む。セキュリティマネージャ１１３１は、SIMカード、スマートカード、専用シリコンチップ、あるいは適切なデータを有するカスタマイズ可能なチップまたはメモリや、適切な実施形態を実行するように構成されたソフトウェアルーティン、あるいは当業者が通常思い浮かべるさまざまな技術のいずれかを含む。
【００６７】
リソースは、通信において安全性が求められるプライベートネットワークや、企業ネットワークなどのドメイン、あるいはネットワーク通信が可能な構成要素などのネットワークエンティティを含む。
【００６８】
第１ネットワークエンティティまたはクライアントデバイスとセキュリティマネージャ・ホストデバイスは、GSM（移動体通信用グローバルシステム）、GPRS（汎用パケット無線サービス）、第３世代移動体通信システム、あるいは当業者が容易に思いつくあらゆる無線／有線通信システムなどの携帯電話通信網に接続する。あるいは第１ネットワークエンティティまたはクライアントデバイスとセキュリティマネージャ・ホストデバイスは、WLAN（無線LAN）などの無線ホットスポットに移動する。すべてのネットワーク技術は固有の認証方式およびセキュリティ方式を有しており、使われている方式の中にはプライベートドメインの制御が及ばないものがあることが考えられる。したがって、安全性のあるモバイル分散アプリケーションを実行するための実行可能な唯一の解決法は、必要とされるすべてのセキュリティ機構がプライベートドメインまたは企業ドメインによってサポートされ、かつ、プライベートネットワークまたは企業ネットワーク内だけでなく、モバイルデバイスとプライベートドメイン間にも適用可能なことである。
【００６９】
この実施形態ではセキュリティマネージャは、仮の証明書としての第１識別子を生成して、それを前記セキュリティマネージャが組み込まれたセキュリティマネージャ・ホストデバイスのネットワークシステムによって第１ネットワークエンティティまたはクライアントへ送信する。第１ネットワークエンティティまたはクライアントは、セキュリティマネージャから第１識別子を受信して、それをリソースに転送する。リソースは、第１識別子を受信して、この識別子の有効性を確立するように構成されている。この有効化処理は、受信した識別子が前記セキュリティマネージャで実際に生成されたものであって、前記クライアントが前記リソースへアクセスする権利を与えることを決定するステップを含む。
【００７０】
認証が行われると、リソース１１２は第１暗号化データを前記クライアントへ送信する。この第１暗号化データは、セッションキーや、暗号化されたもしくは安全な通信を保証するデータを含む。第１識別子は、仮の証明書である場合、たとえばセキュリティマネージャ１１３１の公開鍵や、クライアントの公開鍵を使って暗号化される。この場合、セキュリティマネージャの秘密鍵またはクライアントの秘密鍵で複合化される。この結果、第１暗号化データを使った、前記クライアントとリソース間の通信が開始される。クライアントとネージャ・ホストデバイスはいずれも、前記クライアントを介して、前記第２ネットワークエンティティまたはリソース１１２のデータへのアクセスを希望する外部ユーザによって使用される電子機器であってもよい。
【００７１】
このようにして、クライアント１１１とセキュリティマネージャ・ホストデバイス１１３の信頼関係が確立され、これを受けてセキュリティマネージャ・ホストデバイス１１３はクライアント１１１に第１識別子１２４を送信する権限を有することになる。この識別子は、リソースに第１暗号化データ１３１を第１ネットワークエンティティまたはクライアント１１１へ提供して、前記第１暗号化データ１３１に基づいた安全な通信を開始するように指示するものである。
【００７２】
したがってクライアント１１１は、セキュリティマネージャ１１３１から権限を与えられた場合のみ、リソースとの安全な通信を開始することができる。こうしてクライアントとリソース間の信頼関係が確立される。
【００７３】
よって本発明は、クライアントとリソース間の安全なネットワーク通信を確立する方法に関する。この方法は、セキュリティマネージャとクライアント間で信頼関係を確立するステップと、セキュリティマネージャで第１識別子１２４を生成して、その識別子をセキュリティマネージャからクライアントに送信するステップと、第１識別子１２４をクライアントからリソースへ転送するステップと、リソースでの第１識別子１２４の有効性を確立し、リソースからクライアントへ第１暗号化データ１３１を転送するステップと、第１暗号化データ１３１を使って、クライアントとリソース間でその後のネットワーク通信１２を行うステップを含む。
【００７４】
この方法の他の形態として、セキュリティマネージャとクライアント間の信頼関係を確立するステップはさらに、クライアントに関する第２識別子１２３を、クライアントからセキュリティマネージャへ送信するステップと、セキュリティマネージャで第２識別子１２３の有効性を確立するステップを含む。
【００７５】
この方法の他の形態として、第１識別子の生成に先立って、リソースとセキュリティマネージャ間の信頼関係を確立するステップが含まれる。
【００７６】
本発明の他の実施形態では、前記リソースと前記セキュリティマネージャとの間の信頼関係を確立する前記ステップは、前記セキュリティマネージャに関する第３識別子１２２を前記セキュリティマネージャから前記リソースへ送信するステップと、前記リソースにおいて、前記第３識別子１２２の有効性を確立するステップとをさらに備える。
【００７７】
本発明の他の実施形態では、前記リソースと前記セキュリティマネージャとの間の信頼関係を確立する前記ステップは、前記リソースに関する第２暗号化データ１３２を前記リソースから前記セキュリティマネージャへ送信するステップと、前記第２暗号化データ１３２を使用して、前記リソースと前記セキュリティマネージャとの間におけるその後のネットワーク通信１１を実行するステップとをさらに備える。
【００７８】
本発明の他の実施形態では、前記リソースと前記セキュリティマネージャとの間の信頼関係を確立するステップは、前記リソースに関する第４識別子１２１を前記リソースから前記セキュリティマネージャへ送信するステップと、前記セキュリティマネージャにおいて、前記第４識別子１２１の有効性を確立するステップとをさらに備える。
【００７９】
本発明の他の実施形態では、前記リソースと前記セキュリティマネージャとの間の信頼関係を確立する前記ステップと、前記セキュリティマネージャと前記クライアントとの間の信頼関係を確立する前記ステップと、前記クライアントと前記リソースとの間の信頼関係を確立する前記ステップのうち、少なくとも１のステップが繰り返される。
【００８０】
本発明の他の実施形態では、前記少なくとも１のステップの繰り返しは、予め定められた時間間隔もしくは任意の時間間隔で実行される。
【００８１】
本発明は、クライアントとリソースとの間で安全なネットワーク通信を行うための通信ネットワークであって、第１クライアントメディエータおよび第２クライアントメディエータが設けられたクライアントと、第１リソースメディエータおよび第２リソースメディエータが設けられたリソースと、第１識別子を生成し、それを前記第２クライアントメディエータへ送信するセキュリティマネージャとを備える通信ネットワークという観点から説明されてもよい。
【００８２】
前記第２クライアントメディエータと前記第２リソースメディエータは、前記クライアントと前記リソースとの間で信頼関係を確立するように構成される。
【００８３】
前記第２クライアントメディエータの構成は、前記第２クライアントメディエータが、前記セキュリティマネージャから前記第１識別子１２４を受信し、前記第１識別子１２４を有効化のために前記リソースに送信し、前記リソースから第１暗号化データ１３１を受信し、前記第１暗号化データ１３１を使用して、前記リソースとの間で安全なネットワーク通信１２を行う構成である。
【００８４】
前記第２リソースメディエータの構成は、前記第２リソースメディエータが、前記第１識別子の有効性を確立し、前記第１暗号化データ１３１を前記クライアントへ送信し、前記第１暗号化データ１３１を使用して、前記クライアントとの間で、その後のネットワーク通信１２を行う構成である。
【００８５】
この方法は、ユーザが任意の数のモバイルデバイスを利用して分散アプリケーションによって企業ネットワークへアクセスし、当該アクセスの安全性が確保されなければならないシナリオに適用できる。言い換えると、複数のデバイスとプライベートネットワークは互いにセッションキーを交換し、少なくとも１つのエンティティが秘密鍵を保持してデータ署名を行うことで相互認証を行う。本発明は、たとえば企業対被雇用者のシナリオに非常に適している。
【００８６】
この方法は、信用されないかもしれないネットワーク上を介して通信するあらゆる当事者間で信頼性を構築する際の先行技術の欠点を克服しており、その結果、企業ネットワークが、商取引などのあらゆる通信イベントに関連するすべてのエンティティの身元に関する証明を得ることができる。この仕組みと同様に、別々のデバイスの集まりに含まれるすべてのモバイルクライアントデバイスは、各々、同じ集まりに属する他のモバイルデバイスと企業ドメインの身元証明を持っている。またモバイルデバイス間、およびモバイルデバイスとネットワーク間で授受されるメッセージは傍受および修正（喪失を含む）から保護され、通信イベントが明らかにされるので、通信は拒絶されない。
【００８７】
本方法は、クライアントデバイスの数と種類が不明であって、モバイルデバイス同士、およびモバイルデバイスと企業ネットワーク間が信頼されていない環境に適用できる。
【００８８】
またセキュリティマネージャの公開鍵で第１暗号化データ１３１を暗号化することによって、セキュリティマネージャ（および間接的にリソース）の安全性は強化されることとなる。なぜなら、第１暗号化データを送信する際には、クライアントが第１暗号化データを使用するに先立ち、クライアント同盟が依然として機能していることが必要だからである。
【００８９】
セキュリティマネージャとクライアントがクライアント同盟に属していることを証明するために、セキュリティマネージャとクライアント、およびクライアントとリソースの認証が一意のまたは任意の間隔で繰り返される。この思想に基づき、同盟に属することなくクライアントデバイスが極秘の企業データにアクセスするという可能性は排除することができる。
【００９０】
図６は本発明の第２実施形態に係る、クライアントデバイスとリソース間で安全なネットワーク通信を確立する方法を示す。
【００９１】
上述の実施形態を改良した、図６に示される本発明の実施形態によると、第１ネットワークエンティティまたはクライアント１１１には第１クライアントメディエータ１１１１および第２クライアントメディエータ１１１２が設けられており、第２ネットワークエンティティまたはリソース１１２には第１リソースメディエータ１１２３および第２リソースメディエータ１１２４が設けられている。これらのメディエータは、ハードウェア、ファームウェアまたはソフトウェア、あるいはそれらの組み合わせによって実行される。
【００９２】
第１クライアントメディエータ１１１１はセキュリティマネージャ１１３１と相互作用して、第１ネットワークエンティティまたはクライアント１１１と、セキュリティマネージャ１１３を含むセキュリティマネージャ・ホストデバイスの信頼関係を確立する。第２クライアントメディエータ１１１２は、セキュリティマネージャ１１３１から前記第１識別子１２４を受け取って、それを第２ネットワークエンティティまたはリソース１１２の第２リソースメディエータへ転送する。次にリソースで、上述したように、第１識別子１２４を認証するプロセス９が実行される。第１識別子１２４が有効であると判断された場合、第２リソースメディエータは第１暗号化データ１３１をメッセージ１０でクライアント１１１の第２クライアントメディエータへ送信する。これを受けて第２クライアントメディエータ１１１２は、第１暗号化データ１３１を使用してリソースの第２リソースメディエータと安全な通信１２を開始する。
【００９３】
セキュリティマネージャ・ホストデバイス１１３のセキュリティ部１１３１の安全性とは、セキュリティマネージャと第２ネットワークエンティティまたはリソースの間に信頼関係があることを意味する。すなわち、第１識別子が、信頼されたセキュリティ部で生成されたことが判明した場合、リソース１１２は、本発明で想定される、当該リソースとセキュリティマネージャ１１３１、およびクライアント１１１とセキュリティマネージャ１１３１間の信頼関係に基づいてクライアント１１１との通信を安全に開始することができる。
【００９４】
セキュリティマネージャは不正操作できないように構成され、さらに、ユーザの信用証明を保持するように構成されている。セキュリティマネージャは、ベアラーデバイスまたはセキュリティマネージャ・ホストデバイスと一体であってもよい。ベアラーデバイスとクライアントデバイスなど、異なるモバイルデバイス間で通信リンクが確立される。これらのデバイスに、パスワード入力用のソフトウェアコンポーネントが設けられてもよい。
【００９５】
図７は、本発明の第三実施形態に係る、クライアントデバイスとリソース間で安全なネットワーク通信を確立する第二の方法を示す。
【００９６】
これまで述べてきた実施形態をさらに改良したものである図７は、クライアント１１１とセキュリティマネージャ・ホストデバイスの信頼関係が、各々、第１クライアントメディエータ１１１１およびセキュリティマネージャ１１３１によってどのように確立されるかをさらに具体的に示す。第１クライアントメディエータ１１１１は、第２識別子１２３をメッセージ５でセキュリティマネージャ・ホストデバイス１１３のセキュリティマネージャ１１３１へ送信する。そしてセキュリティマネージャ１１３１で処理ステップ６が実行され、第２識別子１２３の有効性が確立される。第２識別子１２３が適切なクライアントデバイスを表し有効であると判断された場合、第１識別子１２４がセキュリティマネージャ１１３１で生成される。第１識別子１２４は、クライアントにサーバへのアクセス権限を与える仮の証明書である。第１識別子１２４は、メッセージ７でクライアントデバイスへ送られる。そしてクライアントデバイスは、第１識別子をメッセージ８でサーバへ送信する。サーバはこの第１識別子に対して有効化処理９を実行する。この有効化処理は、たとえば、受信した識別子がセキュリティマネージャで実際に生成されたものであって、そのセキュリティマネージャがクライアントにリソースへのアクセス権限を与えたことを判定するステップを含む。この有効化処理９が成功した場合、サーバ１１２は暗号化または安全な通信を可能にするセッションキーやデータなどの第１暗号化データ１３１を生成し、当該データをメッセージ１０でクライアントデバイスへ送信する。この第１暗号化データは、証明書である第１識別子１２４の公開鍵で暗号化される。
【００９７】
次に、クライアントデバイスとサーバ間でセキュアチャネル１２が確立され、プライベートネットワークへのアクセスが可能になる。セキュアチャネルは、サーバ１１２がセキュリティマネージャ・ホストデバイス１１３のセキュリティマネージャ１１３１を信頼し、これによってクライアント１１１との信頼関係を確立することが可能になるため、クライアント１１１からの第１識別子１２４の受信によってサーバまたはリソース１１２が、クライアント１１１も信頼できるとの認識に基づいて確立される。これに基づき、第２ネットワークエンティティまたはリソース１１２が、第１暗号化データ１３１を第１ネットワークエンティティまたはクライアント１１１に送信する。
【００９８】
図８は、本発明の第４実施形態に係る、クライアントデバイスとリソース間で安全なネットワーク通信を確立する方法を示す。
【００９９】
上述の実施形態を改良した同図では、リソース１１２とセキュリティマネージャ・ホストデバイス１１３のセキュリティマネージャ１１３１間の信頼関係がどのように確立されるかがさらに具体的に示される。この実施形態では、第３識別子１２２がセキュリティマネージャ１１３１からリソース１１２の第１リソースメディエータ１１２３へ送られる。この第３識別子１２２は、リソース１１２によって発行された証明書を含む。第１リソースメディエータ１１２３は、第３識別子１１２を受信するとともに、処理ステップ２において第３識別子１２２の有効性を判定する。第３識別子１２２が有効である、すなわち、第２ネットワークエンティティまたはリソースから信頼されたエンティティによって発行されたと判断されると、第２ネットワークエンティティまたはリソース１１２の第１リソースメディエータは、セキュリティマネージャ・ホストデバイス１１３のセキュリティマネージャ１１３１へ第２暗号化データ１３２を送信する。こうしてセキュリティマネージャ１１３１は、リソース１１２と安全な通信１１を開始する。
【０１００】
図９は、本発明の第５実施形態に係る、クライアントデバイスとリソース間で安全なネットワーク通信を確立する方法を示す。
【０１０１】
上述の各実施形態さらに改良した本実施形態によると、リソース１１２の第１リソースメディエータ１１２３はセキュリティマネージャ１１３１へ第４識別子１２１を送信する。そしてセキュリティマネージャ１１３１で処理ステップ４が実行され、第４識別子の有効性が確立される。この結果、安全な通信１１の開始に先立ち、相互の信頼関係が確立される。この第４識別子は、リソースの証明書である。
【０１０２】
図１０は本発明の実施形態に係るリソースをさらに具体的に示す。
【０１０３】
この実施形態では、リソース１１２は記憶手段１１２１と処理手段１１２２を備える。リソースは本来有する機能に加えて、処理機能、記憶機能、またはそれらの組み合わせを持つ独立の構成要素を含む拡張ネットワークを備えてもよい。このように、本発明のリソースのコンポーネントは複数の分離したエレメントに対して配布される。本発明のリソース１１２は、少なくとも本発明のクライアント（図示されていない）と通信を行う手段を備えてもよい。記憶手段１１２１は、リソースの証明書である第４識別子１２１を格納する。記憶手段１１２１はさらに、クライアント１１１が本発明におけるアクセスを試みるデータ１１２５を格納する。このデータは静的データ、アプリケーションデータ、通信データのストリーム、クライアントで生成されたデータをリソース内で処理することによって得られるデータ、または外部クライアントがアクセスを所望する多数のリソースのいずれかを含む。処理手段１１２２は第１リソースメディエータ１１２３および第２リソースメディエータ１１２４を備える。第１リソースメディエータ１１２３は、すでに述べたように、リソースに含まれる一般的な通信手段（図示されていない）によって、セキュリティマネージャ１１３１と通信を行う。また第１リソースメディエータ１１２３は、第２暗号化データ生成器１１２６および第３識別子バリデータ１１２７と通信を行う。第３識別子バリデータ１１２７は、本発明にしたがってセキュリティマネージャ１１３１から第３識別子１２２を受信し、その有効性を判断する。第３識別子バリデータ１１２７は、第２暗号化データ生成器１１２６と接続され、第２暗号化データ１３２の生成および発行を第２暗号化データ生成器１１２６に促す。第２暗号化データは、記憶手段に格納された第４識別子１２１とともに、セキュリティマネージャ１１２６へ返送される。また第２暗号化データ生成器は記憶手段１１２１に接続されて、その内部に格納された情報に基づいて第２暗号化データ１３２を生成する。
【０１０４】
第２リソースメディエータ１１２４は、リソースに含まれる一般的な通信手段（図示されていない）によって、第２クライアントメディエータ１１２１と通信を行う。また第２リソースメディエータ１１２４は、第１暗号化データ生成器１１２８および第１識別子バリデータ１１２９と通信を行う。本発明に係る第１識別子バリデータ１１２９は、第２クライアントメディエータから第１識別子１２４を受信し、その有効性を判断する。第１識別子バリデータ１１２９は、第１暗号化データ生成器１１２８に連結されており、これによって、第２クライアントメディエータ１１２１に返送する第１暗号化データ１３１の生成および発行を第１暗号化データ生成器１１２８に促す。また第１暗号化データ生成器は記憶手段１１２１に連結されており、その内部に格納された情報に基づいて第１暗号化データ１３２を生成する。
【０１０５】
本発明は、ネットワーク上での安全な通信を開始するように、第１リソースメディエータの動作によってセキュリティマネージャと信頼関係を確立するように構成されたリソースにおいて具体化される。第２リソースメディエータは、セキュリティマネージャによって生成されてクライアントへ送信された後にリソースに転送された第１識別子１２４の有効性を確立し、リソースにおいて第１暗号化データ１３１をクライアントへ送信し、この第１暗号化データを使ってクライアントと新たな通信１２を実行するように構成されている。
【０１０６】
図１１は本発明の実施形態に係るセキュリティマネージャをさらに具体的に示す。
【０１０７】
図１１に示されるように、セキュリティマネージャ１１３１が組み込まれたセキュリティマネージャ・ホストデバイス１１３が提供される。セキュリティマネージャは、処理手段１１３８と記憶手段１１３７、およびセキュリティマネージャに割り当てられたタスク（以下で述べる）を実行するために必要な他の構成要素を備える。図１１に示されるようにセキュリティマネージャは、第１リソースメディエータによって提供された第４識別子の有効性を確立するための第４識別子バリデータ１１３４と、第１クライアントメディエータによって提供された第２識別子の有効性を確立するための第２識別子バリデータを備える。この有効化処理は、上述した有効化処理４および有効化処理６である。これらの機能は実質的には処理手段１１３８によって実行される。またセキュリティマネージャ１１３１は、第３識別子１２２を第１リソースメディエータに、第１識別子１２４または第１命令を第２クライアントメディエータに提供するように構成されている。各識別子は単に記憶手段１１３７に格納されたり、処理手段１１３８で生成されたり、記憶手段に格納されたデータに基づいて処理手段で生成されたり、あるいはたとえばリアルタイムクロックから得られたりする。
【０１０８】
上述したように、セキュリティマネージャ・ホストデバイス１１３はセキュリティマネージャ１１３１を含む。セキュリティマネージャ１１３１は、処理手段１１３８および記憶手段１１３７を備える。記憶手段と処理手段は、既存の演算システムの方法で協働する。記憶手段１１３７は、当業者が容易に思い浮かべるあらゆるデータ記憶装置を含む。たとえば、記憶手段はハードドライブ、固体メモリ、EEPROMである。記憶手段は、第２ネットワークエンティティまたはリソース１１２によって発行された証明書である第３識別子１２２と、上述したように、第１ネットワークエンティティまたはクライアント１１１向けの第１暗号化データ１３１を発行する許可を与えるためにリソースによって認識される第１識別子１２４を格納する。記憶手段１１３７は、上述したように、第３識別子１２２を第１リソースメディエータ１１２３に、第１識別子１２４を第２クライアントメディエータ１１２に送信する。この送信は、処理手段１１３８が制御して、セキュリティマネージャ・ホストデバイスに備わったネットワーク通信手段を介して実行される。また既に述べたように、処理手段１１３８は、第１リソースメディエータから第４識別子を、第１クライアントメディエータから第２識別子を受信するとともに、第４識別子バリデータ１１３４で第４ネットワーク識別子を認証する処理ステップ４と、第２識別子バリデータ１１３６で第２識別子を認証する処理ステップ６を実行する。また第４識別子バリデータは、第４識別子の有効性がひとたび確立されると、上述したように、記憶手段１１３７から第１リソースメディエータ１１２３へ第３識別子１２２が送信されるように構成されており、この結果、２者間の相互認証が行われる。これと同じく、第２識別子バリデータは、第２識別子の有効性がひとたび確立されると、記憶手段１１３７から第２クライアントメディエータ１１２へ第１識別子１２４が送信されるように構成されており、この結果、２者間の相互認証が行われる。
【０１０９】
イベントのシーケンスは上記のとおりであるが、他のイベントのシーケンスであってもよい。
【０１１０】
セキュリティマネージャ・ホストデバイスを本発明で採用するか否かは自由である。しかしながらセキュリティマネージャ・ホストデバイスは、他のクライアントデバイスおよびリソースと通信を行うための通信手段１１３３と、ユーザ１４と通信を行うためのユーザインタフェース１１３０を備えることが好ましい。セキュリティマネージャは、セキュリティマネージャ・ホストデバイスがユーザ、クライアント、リソースなどからの通信を正確に受け渡すように制御するホストインタフェース１１３２を備える。このホストインタフェース１１３２は処理手段１１３８に実装されてもよい。
【０１１１】
セキュリティマネージャ・ホストデバイスまたはセキュリティマネージャ１１３１は、非対称暗号化のための秘密鍵と公開鍵のペアと、対称暗号化用のセッションキーを格納する。モバイルユーザは、証明書発行機関（さらには他のエンティティ）に不可欠な証明書、個人識別番号（PIN）、セキュリティマネージャにアクセスしてそれを起動するためのパスフレーズやパスワードを有する。セキュリティマネージャ・ホストデバイスまたはセキュリティマネージャ１１３１は、ユーザ証明書の取り消しリストを格納してもよい。またセキュリティマネージャは、適切な鍵生成処理によって秘密鍵／公開鍵のペアを生成することなど、その外部に秘密鍵を公開することなくセキュリティに関連するすべての動作を実行する機能がある。セキュリティマネージャはモバイルユーザに対して、自身の証明書機関CAのリストと証明書を管理することを認めなければならない。またセキュリティマネージャは、証明書の送信、他のエンティティの公開鍵を使ったデータの暗号化、他のエンティティの多数の証明機関（CA）の認証に対処する。あるいはこれらの機能は、あらかじめ定められたセキュリティ分類に属する、信頼されたクライアントデバイスに委託してもよい。セキュリティマネージャは 好ましくはXS.17、FIPS 186-2適合の乱数を生成するための暗号用疑似乱数生成器を備えてもよい。またリアルタイムクロックを実装してもよい。
【０１１２】
第１識別子または第１命令１２４は、リソース１１２またはクライアント１１１などの本発明のネットワーク内の他の構成要素に、本発明にしたがって割り当てられたタスクを実行させるコーディングを含む。コーディングは、個々の構成要素によって直接解読可能なフォーマットに暗号化された命令を、デバイスの一般の低レベルコードから、そのデバイスで動作する特定のアプリケーションによってのみ解読可能な命令までを含むさまざまな実施レベルにおいて混合することである。
【０１１３】
実装されたすべての機能とセキュリティマネージャ内のユーザの信用証明は、信頼されたエンティティによって発行される。企業対被雇用者のシナリオにおいて、信頼されたエンティティは企業自身であってもよい。
【０１１４】
このように本発明は、ネットワークで安全な通信を確立するためのセキュリティマネージャにおいて具体化される。このセキュリティマネージャは、第１識別子１２４または第１命令を生成するとともに、この命令を、解読用にクライアントに組み込まれた第２クライアントメディエータに送信するように構成されている。第１命令は、第２クライアントメディエータに当該命令を第２リソースメディエータへ転送することを促す。
【０１１５】
また第１識別子命令は、第２リソースメディエータが前記第１命令を有効化するための有効化処理９と、第１暗号化データ１３１の第２クライアントメディエータへの送信と、第１暗号化データ１３１を使用しているリソースとのその後のネットワーク通信１２を行うことを促すために生成される。
【０１１６】
図１２は、本発明の１実施形態に係る、クライアントデバイスをさらに具体的に示す。上述したようにクライアントデバイス１１１は、本発明を実行するように構成された、ラップトップコンピュータ、携帯電話、PDAなどの既存のデバイスである。したがってクライアントデバイス１１１は、記憶手段１１１４、処理手段１１１３を備える。クライアントデバイスは、セキュリティマネージャ１１３１と相互作用する第１クライアントメディエータと、セキュリティマネージャ１１３１および第２リソースメディエータ１１２４の双方と相互作用する第２クライアントメディエータを備える。またクライアントデバイス１１１は、ユーザ１４と通信を行うためのユーザインタフェース１１１０を備えてもよい。クライアントデバイス１１１は他のクライアント、セキュリティマネージャ１１３１を仲介にするセキュリティマネージャ・ホストデバイス１１３およびリソース１１２と通信を行うための通信手段を備える。ユーザインタフェース１１１０および通信手段１１１５は、処理手段１１１５によって制御される。
【０１１７】
このように本発明は、リソースとの安全な通信を開始するように構成された、第１クライアントメディエータと第２クライアントメディエータを備えたクライアントで具体化される。クライアントは、第１クライアントメディエータの動作によって、セキュリティマネージャと信頼関係を確立するように構成されている。第２クライアントメディエータと、リソースに組み込まれた第２リソースメディエータは、各々、クライアントとリソース間で信頼関係を確立するように構成される。
【０１１８】
第２クライアントメディエータへの適用においては、第２クライアントメディエータが、セキュリティマネージャによって生成された第１識別子１２４をセキュリティマネージャから受信し、リソースから第１暗号化データ１３１を受信し、第１暗号化データ１３１を使用してリソースとその後のネットワーク通信１２を行うように構成されることを含む。
【０１１９】
第２リソースメディエータへの適用においては、第２リソースメディエータが、第１識別子１２４の有効性を確立し、第１暗号化データ１３１を送信し、第１暗号化データを使用しているリソースとその後のネットワーク通信１２を行うように構成されることを含む。
【０１２０】
第６の実施形態では、セキュリティマネージャとリソースが相互に認証を行い、それによって生成されたセッションキーがセキュリティマネージャに送信される。次に、セキュリティマネージャとラップトップが互いに認証する。ラップトップは当事者リクエストを送信して認証を開始する。このステップがないと企業ドメインが接続要求を受け付けないので、あることが好ましい。スマートカードなどのセキュリティマネージャは、ラップトップのアイデンティティを認証し、あるいは言い換えると、ラップトップの証明書を認証して、企業ネットワークとの間で認証を行うためにラップトップが使う仮の証明書を発行する。仮の証明書が企業ネットワークによって承認されると、セッションキーが生成され、セキュリティマネージャの公開鍵（あるいはラップトップの公開鍵）で暗号化された後にラップトップに返送される。
【０１２１】
セキュリティマネージャの公開鍵でセッションキーを暗号化することによって、セキュリティマネージャ（そして間接的には企業ドメイン）の安全性が高まる。なぜなら、セッションキーを送信する際には、モバイルデバイスがセッションキーを使用することに先立って、クライアント同盟が依然として機能している必要があるためである。
【０１２２】
セキュリティマネージャとラップトップデバイスが依然として同盟に属することを保証するために、セキュリティマネージャとラップトップ、およびラップトップと企業ネットワークの認証は所定のまたは任意の間隔で繰り返される。このことが一般規則として定められれば、同盟に参加することなくクライアントデバイスが秘密の企業データにアクセスすることはなくなる。
【０１２３】
＜クライアント同盟のブートストラッピング＞
認証には、関連するデバイスの性質に応じて証明書、個人識別番号（PIN）およびパスワードのいずれが使われてもよい。認証および個人識別番号は、セキュリティマネージャがスマートカードなどである場合には特に都合がよく、パスワードは（可能であるなら証明書とともに）ラップトップまたはPDAの場合に使うことが想定される。証明書は、企業に直接または第三者のいずれかによって生成される。これは、ラップトップまたはPDAなどの任意のデバイスが認証されてクライアント同盟に参加する場合には重要である。
【０１２４】
図１３は、本発明の第７実施形態に係る、クライアントデバイスとリソース間で安全なネットワーク通信を確立する方法を示す。
【０１２５】
上記の実施形態は、同盟に参加する外部デバイスが、自身を証明するためのデータを持つケースにおいて特に適切である。しかしながら、そのようなデータが利用できなかったり、認証には不向きであったりすることがある。
【０１２６】
この実施形態では、セキュリティマネージャが有効な信用証明を複数保持している。これらの複数の信用証明は、生成され、クライアントデバイスなどの外部デバイスに送信される。ゆえに本実施形態は、安全な通信または「ダイナミック・ウェブ・オブ・トラスト」のブートストラッピングに関する。そのようなタスクに関連する問題は、安全でないチャネル上でセキュリティマネージャとクライアントデバイスを接続することと、ユーザの信用証明を生成してそれを転送することを含む。
【０１２７】
本発明の実施形態は、セキュリティマネージャが信用証明を保持するとともに、鍵生成などの暗号化を行うための各機能を実行するという制約に基づいている。またセキュリティマネージャ、あるいはセキュリティマネージャ・ホストデバイスもしくはベアラーデバイス（セキュリティマネージャを実行するモバイルデバイスなど）は、認証、鍵生成、および配布プロトコルに対応していなければならない。また、外部のクライアントデバイスは対称暗号化および非対称暗号化を実行することができ、セキュリティマネージャとベアラーデバイスと同じ認証および鍵管理プロトコルを実行し、パスワード、ＰＩＮまたはパスフレーズを使ったユーザ認証に対応するという制約がある。
【０１２８】
セキュリティマネージャ１１３とクライアントデバイス１１１間には、セキュアチャネル１３が確立される。チャネル１３は、インターネットキー交換プロトコル、ディフィーへルマン鍵交換、ブルートゥースデバイス接続、および当業者が容易に思い浮かべるその他のプロトコルと類似の結果をもたらす、先行技術に関連して議論したあらゆる適切な手続きによって安全が確保される。
【０１２９】
使い捨てパスワード、ＰＩＮ、コードまたは文字列などの識別子１２５が、ディスプレイスクリーン、可聴プロンプトなどのセキュリティマネージャ・ホストデバイス１１３のユーザインタフェース１１３０を介して、ユーザ１４に通知される。ユーザ１４は、クライアントデバイス１１１のユーザインタフェース１１１０に識別子１２５を入力する。次に識別子１２５は、チャネル１３を介して、セキュリティマネージャ１１３に返送される。その結果、キーネゴシエーションおよび交換プロトコルがベアラーデバイスとモバイルデバイスによって実際に行われたことの証明書が発行される。
【０１３０】
上記の仮の証明書などの第１識別子または複数の信用証明１２４はセキュリティマネージャ１１３で生成される。
【０１３１】
この第１識別子は、チャネル１３を介してメッセージ７でクライアントデバイス１１１に送信される。クライアントデバイスは、そのアイデンティティを証明するために、第１識別子１２４をメッセージ８でリソース１１２に送信する。
【０１３２】
この第１識別子に対し、サーバが有効化処理９を行う。この有効化処理は、受信した識別子がセキュリティマネージャで生成されたものであるか否かを判定するステップと、前記リソースへアクセスする権利を前記クライアントに与えるステップを含む。鍵のペアを送信する場合には、セキュアチャネルで行うことが好ましい。
【０１３３】
この有効化処理９が成功した場合、サーバ１１２は暗号化または安全な通信を可能にするセッションキーやデータなどの第１暗号化データ１３１を生成して、そのデータをメッセージ１０でラップトップに送信する。この第１暗号化データは、証明書である第１識別子１２４の公開鍵で暗号化されることが好ましい。
【０１３４】
こうして、クライアントデバイスとサーバ間でセキュアチャネル１２が確立され、プライベートネットワークへのアクセスが利用可能となる。
【０１３５】
ゆえに本発明に係る本実施形態によれば、リソースとセキュリティマネージャ間で信頼関係を確立するステップではさらに、前記セキュリティマネージャと、信頼されていないクライアントの間でチャネルを確立するステップと、前記信頼されていないクライアントの側でユーザ認証情報の入力をリクエストするステップと、前記ユーザ認証情報を前記セキュリティマネージャで認証するステップが実行されてもよい。
【０１３６】
この方法をさらに発展させた態様において、チャネルはセキュアチャネルであって、このセキュアチャネルは、インターネット鍵交換プロトコル、ディフィーへルマン鍵交換、およびブルートゥースデバイス接続、あるいは当業者が容易に思い浮かべるプロトコルを使って確立される。
【０１３７】
この方法をさらに発展させた態様において、ユーザ認証情報は、セキュリティトークン、使い捨てパスワード、個人識別番号、コードまたは文字列のうちの少なくともいずれか１つである。
【０１３８】
図１４は、図１３に示す実施形態をさらに発展させた、クライアントデバイスとリソース間で安全なネットワーク通信を確立する方法を示す。
【０１３９】
第９の実施形態では、上記に提案した方法は、たとえば弱連結の無線モバイルデバイス同士と、デバイスとプライベートネットワーク（たとえば企業ネットワーク）間に適用できる認証アルゴリズムおよび認証プロトコルを定義する。特に、ユーザの信用証明として証明書が使われる。本発明によればセキュリティマネージャは、認証データの認証と、仮の証明書の生成とそのモバイルデバイス間での配布と、仮の認証データを任意の間隔で再認証することを行う。仮の認証データは、企業ネットワークへアクセスするために、あらゆるデバイスに使用されうる。この処理は、プライベートネットワークが認識できるモバイルデバイスは、プライベートネットワーク自身に属するデバイスと同じ程度に信頼されることを保証する。
【０１４０】
第１０の実施形態の方法は、セキュリティマネージャと企業ネットワークの認証を行うステップと、セキュリティマネージャおよび企業ネットワークにおいて、様々なモバイルデバイスの認証を行うステップと（なお、いずれのデバイスも信頼されている、すなわち証明書を発行されてその発行機関（企業）の支配下にあることが前提とされている）、セキュリティマネージャおよび企業ネットワークにおいて、第三者機関を出所とし、あらかじめインストールされた認証データ（証明書など）を有さないモバイルデバイスをいくつか含むモバイルデバイスの認証を行うステップとを含む。
【０１４１】
本発明は、モバイルデバイスと企業ネットワーク間で信頼できる通信関係と、あらかじめインストールされた共通の秘密情報を必要とすることなく、ビジネスアプリケーションへの円滑で安全なアクセスを実現する点で、先行技術に対して多くの利点を有する。
【０１４２】
とりわけ、本発明によってモバイルクライアントデバイス同士、およびモバイルクライアントデバイスと企業ネットワーク間の信頼関係の確立と、モバイルクライアントデバイス同士、およびモバイルクライアントデバイスと企業ネットワーク間の通信リンクが確立される。
【０１４３】
第２に、信頼と安全性のある通信リンクによって、モバイルユーザは企業ネットワークおよび当該ネットワークで実行される分配アプリケーションに時と場所を問わずアクセスできる。
【０１４４】
第３に、モバイルデバイスには、あらかじめインストールされた共通の秘密情報が必要とされないので、通信に参加することができる限り、信頼されたモバイルデバイスの集合に対して新規のデバイスの加入が受け付けられる。
【０１４５】
ユーザの信用証明で初期設定されると、セキュリティマネージャは新たな信用証明を生成し、それを認証済のまたは認証していないデバイスに送信してインストールする。
【０１４６】
本発明は、安全性のあるモバイルデバイス用分散アプリケーションを実行できるデバイスの任意の集合から形成される、トランスペアレントなセキュリティ環境を提供する。
【０１４７】
本発明は、さまざまなモバイルデバイスを使用する「一般販売委員」、およびユーザに厳密な認証を求めるモバイルデバイスなどのモバイルビジネスと、アイデンティティ認証、キーネゴシエーション、信頼関係の確立などの法人ビジネスへ適用するには特に都合がよい。
【０１４８】
上記の実施形態はすべて本発明の核となる発明の核となる概念に関するものであって、各実施形態のいずれか１つに関連して記載されたあらゆる特徴または詳細が他の実施形態に適用しうることは当業者に明らかである。
【図面の簡単な説明】
【０１４９】
【図１】モバイル用の分散アプリケーションの一例を示す図である。
【図２】第１の先行技術におけるネットワーク認証処理を示す図である。
【図３】第２の先行技術におけるネットワーク認証処理を示す図である。
【図４】第３の先行技術におけるネットワーク認証処理を示す図である。
【図５】本発明の第一実施形態に係る、クライアントデバイスとリソース間で安全なネットワーク通信を確立する方法を示す。
【図６】本発明の第二実施形態に係る、クライアントデバイスとリソース間で安全なネットワーク通信を確立する方法を示す。
【図７】本発明の第三実施形態に係る、クライアントデバイスとリソース間で安全なネットワーク通信を確立する方法を示す。
【図８】本発明の第四実施形態に係る、クライアントデバイスとリソース間で安全なネットワーク通信を確立する方法を示す。
【図９】本発明の第五実施形態に係る、クライアントデバイスとリソース間で安全なネットワーク通信を確立する方法を示す。
【図１０】本発明の一実施形態に係る、リソースをさらに詳細に示す図である。
【図１１】本発明の一実施形態に係る、セキュリティマネージャをさらに詳細に示す図である。
【図１２】本発明の一実施形態に係る、クライアントデバイスをさらに詳細に示す図である。
【図１３】本発明の第６実施形態に係る、クライアントデバイスとリソース間で安全なネットワーク通信を確立する方法を示す。
【図１４】図１３に示す実施形態をさらに改良した、クライアントデバイスとリソース間で安全なネットワーク通信を確立する方法を示す。
【技術分野】
【０００１】
本発明はリソースと外部エンティティ間の通信に関する。
【０００２】
外部ユーザは、多数のデバイスに囲まれている。業務タスクを実行中、ユーザは単一のデバイスだけでなく、タスクの遂行に最も適したあらゆる実行可能な組み合わせを用いる。図１はこのシナリオを示したものである。企業ドメイン２００の視点から見れば、プライベートドメイン１００およびパーソナルドメイン３００は信頼された環境である。一方、ベアラードメイン４００は信頼されないドメインまたは信頼されたドメインである。
【０００３】
最新の分散アプリケーションは、リモートクライアントを始点とするトランザクション処理に多数のサーバが関与する多層アーキテクチャに基づく。これまで、クライアントは企業ネットワークドメイン２００に統合されるか、遠隔地に位置する場合はダイヤルイン接続、インターネット、仮想プライベートネットワーク（ＶＰＮ）、またはインターネットセキュリティＩＰsecの中の１つあるいはそれらの組み合わせで接続される。
【０００４】
無線技術によって、ユーザと各種の機器１０１、１０２、３０１、３０２、および３０３の相互間および企業ネットワーク２００とのモビリティが実現されるので、企業ネットワークリソース２０１、２０２、および２０３へのアクセスを許可する安全なモバイルアプリケーションに対する解決策が望まれている。
【０００５】
したがって、利用可能な認証メカニズムと、当該メカニズムの環境に対する適切な度合いを考えることが必要である。
【背景技術】
【０００６】
認証とは、人間、機械、あるいは処理を含むいずれかのエンティティ同士で行われる処理のことである。エンティティ同士は、データを交換してお互いのアイデンティティを確立する。
【０００７】
図２は一般的な認証プロトコルの流れを示す。この例は、ＰＰＰ（Ｐｏｉｎｔ ｔｏ Ｐｏｉｎｔ）拡張認証プロトコル（ＥＡＰ）を取り上げている。ＥＡＰは、ポイントツーポイントリンク上の通信相手同士の通信で使われる認証プロトコルである。基本的に、認証者２００はクライアント１０１に身元証明をリクエストする。この身元証明は、たとえばワンタイムパスワードやチャレンジ／レスポンス型認証の簡単なもの、あるいはセッションキーの配布とネゴシエーションを行う拡張認証プロトコル／トランスポート層セキュリティプロトコル（ＥＡＰ―ＴＬＳ）などの複雑なプロトコルである。
【０００８】
認証のリクエスト１４は、認証者２００から通信相手またはクライアント１０１に送られる。通信相手１０１は、レスポンス１５を返答し、このレスポンスは認証者２００によって認証される。認証の結果に基づいて、正のまたは負のフィードバック１６がクライアント１０１へ送信される。
【０００９】
図３に示されるラディウスプロトコルは、把握している通信中のすべてのエンティティに関する個々の識別データを保存する中央サーバ２０２に対して認証が行われる間接認証方式である。
【００１０】
ラディウスと同様に、図４に示されるケルベロスは間接認証方式である。ケルベロスはユーザを認証し、サービスごとに認証を行う。
【００１１】
所有者が他のエンティティと認証を行うことを可能にする、チケットと呼ばれる認証処理データの一部分が生成されると、認証プロトコルで２つのステップが行われる。第一にエンティティは、エンティティのアイデンティティを認証してチケット保証チケット１２５と呼ばれるチケットを返送するケルベロスサーバで認証を行う。第二に、その後特定リソース２０３へのアクセスを希望する場合、既に発行されているチケット保証チケット１２５を使ってエンティティは、チケット保証サービスと呼ばれる他のサーバに対してリソース特定チケット１２６の発行をリクエストする。このチケットを使って、自身の認証とリソース２０３へのアクセスをするために、エンティティは認承メッセージ１２７を作り、リソースをホストするサーバへ認承メッセージとリソース特定チケット１２６を送信する。
【００１２】
ケルベロスでは、認証処理を行っている間、ケルベロスサーバによってセッションキーが生成され、当該キーは生成されたチケットの一部として配布される。セッションキーは、データ送信の際の暗号化を行うために使われ、データの受信側で同じ鍵で復号化される。データの送受信に関連するすべての当事者は、使われた暗号鍵に関する同じ情報を共有する。
【００１３】
一般的に用いられる他の方法は、公開鍵暗号方式である。公開鍵暗号方式は暗号化および復号化に利用されるＲＳＡアルゴリズムなどのシステムを構築するために用いられる。公開鍵暗号方式はデジタル署名や鍵交換での使用にも好都合である。公開鍵暗号方式では、公開鍵と秘密鍵という鍵のペアを用いる。これらの鍵は暗号化および相互の復号化に用いられる。まず鍵のペアが生成される。秘密鍵はエンティティが保持し、公開鍵は第三者に公開される。公開鍵を公開する一般的な方法は、公開鍵インフラストラクチャ（ＰＫＩ）を使うことである。ＰＫＩは、証明書の概念を中心にする。簡単に言えば、証明書は身元証明である。証明書は、他のエンティティの固有データ中に、エンティティの公開鍵を含む。証明書は通常、認証機関（ＣＡ）として知られる第三者機関によって署名される。署名は認証機関の秘密鍵を用いて行われる。あるエンティティが他のエンティティと認証を行う場合、自分の証明書を使う。認証を呼びかけられたエンティティは、認証機関の公開鍵を用いて、認証を呼びかけたエンティティを認証する。エンティティが証明書を持つのは上記の理由からである。通信エンティティの公開鍵は、認証に加えて、特にセッションキーを交換するために公衆網を介してデータを送信する場合、当該データの暗号化に使われる。
【００１４】
エンティティにアイデンティティを与えるのは証明書という方法に限られない。セルフ・デリゲーションとして知られる方法では、プライマリキーとセカンダリキーのペアの概念を用いる。これは、プライマリキーのペアは秘密に保持され、セカンダリキーのペアは信頼されていないデバイスに転送されるという考えである。セカンダリキーのペアには、
プライマリ秘密鍵で署名され、セカンダリキーのペアのあらゆる身元証明はプライマリキーの身元証明と同じ効力があると記述された委任証明書が添付されている。
【００１５】
このシステムは、各々のセルフ・デリゲーションには限られた量の秘密情報のみが開示されるように設計されている。情報が限られているので、そこから有益なことは得ることができない。一方で、セルフ・デリゲーションの増加が一定数に達すると、エネミーが効率的にプライマリ秘密鍵を計算できるように制御されている。
【００１６】
上記のシナリオは新たな要望を生ぜしめる。第一に、基本的なネットワーク接続をユーザに提供するための適切な技術に関する要望である。第二に、企業ネットワークドメインへのアクセス制御に関する要望である。第三に、モバイルデバイスと企業ネットワーク間で送受信されるデータの秘匿性、インテグリティ、およびアカウンタビリティに関する要望である。ここで、上記の技術における安全性のあるモバイルデバイス用分散アプリケーションに対する要望を検討する。特に、提供されなければならないメカニズムは、次の点に対応する必要がある。
・ モバイルクライアントデバイス同士、およびモバイルクライアントデバイスと企業ネットワーク間の認証。
関連するすべての当事者が、その通信相手が保証されたエンティティであるという信用証明を持つように、相互認証が必要とされる。
・ 交換されたメッセージに秘匿性および統一性を与えるために、モバイルデバイス同士、およびモバイルデバイスと企業ネットワーク間など、当事者であるすべてのエンティティ間での安全なエンドツーエンド通信リンクの確立。
・ 通信への参加の間違った承認拒否に対する保護策としての、否認防止あるいは通信イベントのアカウンタビリティ。
【００１７】
拡張認証プロトコル、ラディウス、ケルベロス、公開鍵インフラストラクチャ、デリゲーションはいずれも複数のクライアントを対象とするものの、拡張認証プロトコル、ラディウス、ケルベロスはクライアントとサーバ間の相互認証は認めず、デリゲーションはそのような機能をサポートするようには必ずしも構成されていない。上述の技術は、いずれも異なるクライアント間の相互認証には対応していない。デリゲーション、公開鍵インフラストラクチャ、およびケルベロスは、キーネゴシエーションに対応しており、公開鍵インフラストラクチャで使われる証明書が必要になるが、ＰＰＰ−ＥＡＰ−ＴＬＳ認証プロトコルが実行されると、その機能がＥＡＰにおいてもサポートされる。ＥＡＰ、ケルベロス、公開鍵インフラストラクチャではすでにハッシュ機能が使われているが、データの統一性は問題とされておれず、上述の方法からはデータの統一性はなんら導かれない。しかしながら、データの認証は必要であって、キーイングデータの配布における余分な労力も考慮されなければならない。最後に、公開鍵インフラストラクチャおよびデリゲーションだけが否認防止を十分に考慮する。ケルベロスの場合、双方の通信エンティティが同じ鍵を持っていて、他方のエンティティのアイデンティティを模倣することができるので、セッションキーは否認防止の目的で使われない。
【発明の開示】
【発明が解決しようとする課題】
【００１８】
したがって、安全な通信およびデータネットワークを確立するための既存の技術を改良した方法、システム、およびデバイスの提供が待たれている。
【００１９】
本発明は、クライアントとリソースの間で安全なネットワーク通信を確立する方法に関する。この方法は次のステップを含む。
・ セキュリティマネージャとクライアント間で信頼関係を確立。
・ セキュリティマネージャで第１識別子１２４を生成し、それをセキュリティマネージャからクライアントへ送信。
・ 第１識別子１２４をクライアントからリソースへ転送。
・ リソースで第１識別子１２４の有効性を確立し、リソースからクライアントへ第１暗号化データ１３１へ送信。
・ クライアントとリソース間でその後のネットワーク通信１２を第１暗号化データ１３１を使って実行。
【００２０】
本発明はまた、クライアントとリソースの間で安全なネットワーク通信を確立する方法に関する。この方法は
・ 第１クライアントメディエータおよび第２クライアントメディエータが設けられたクライアントと、
・ 第１リソースメディエータおよび第２リソースメディエータが設けられたリソースと、
・ 第１識別子を生成し、それを第２クライアントメディエータへ送信するセキュリティマネージャとを備える。
【００２１】
ここで、第２クライアントメディエータと第２リソースメディエータは、クライアントとリソースとの間で信頼関係を確立可能なように構成される。
【００２２】
第２クライアントメディエータへの適用においては、第２クライアントメディエータが、
・ セキュリティマネージャから第１識別子１２４を受信し、
・ 認証のために、第１識別子１２４をリソースに送信し、
・ リソースから第１暗号化データ１３１を受信し、
・ 第１暗号化データ１３１を使って、リソースとの安全なネットワーク通信１２を行うように構成される。
【００２３】
第２リソースメディエータへの適用においては、第２リソースメディエータが、
・ 第１識別子の有効性を確立し、
・ 第１暗号化データ１３１をクライアントへ送信し、
・ 第１暗号化データ１３１を使って、クライアントとその後のネットワーク通信１２を行うように構成される。
【００２４】
本発明は、ネットワークで安全な通信を確立するためのセキュリティマネージャにおいて具体化される。このセキュリティマネージャは、第１識別子１２４を生成するとともに、この第１識別子１２４を、解読用にクライアントに組み込まれた第２クライアントメディエータに送信するように構成されている。第１識別子は、第２クライアントメディエータが当該命令を第２リソースメディエータに転送することを促す。また第１識別子は、
・ 第２リソースメディエータが前記第１命令を有効化するための有効化処理９と、
・ 第１暗号化データ１３１の第２クライアントメディエータへの送信と、
第１暗号化データ１３１を使用して、リソースとその後のネットワーク通信１２を行うことを促す。
【００２５】
また本発明は、リソースとの安全な通信を開始するように構成された、第１クライアントメディエータと第２クライアントメディエータを備えたクライアントで具体化される。クライアントは、第１クライアントメディエータの動作によって、セキュリティマネージャと信頼関係を確立するように構成されている。第２クライアントメディエータと、リソースに組み込まれた第２リソースメディエータは、各々、クライアントとリソース間で信頼関係を構築するように構成される。
【００２６】
第２クライアントメディエータへの適用においては、第２クライアントメディエータが、
・ セキュリティマネージャによって生成された第１識別子１２４をセキュリティマネージャから受信し、
・ リソースから第１暗号化データ１３１を受信し、
・ 第１暗号化データ１３１を使用しているリソースとその後のネットワーク通信１２を行うように構成される。
【００２７】
第２リソースメディエータへの適用においては、第２リソースメディエータが
・ 第１識別子１２４の有効性を確立し、
・ 第１暗号化データ１３１を送信し、
・ 第１暗号化データを使用して、クライアントとその後のネットワーク通信１２を行うように構成される。
【００２８】
また本発明は、ネットワーク上での安全な通信を開始するように、第１リソースメディエータの動作によってセキュリティマネージャと信頼関係を確立するように構成されたリソースにおいて具体化される。第２リソースメディエータは、
・ セキュリティマネージャによって生成されてクライアントへ送信された後にリソースに転送された第１識別子１２４の有効性を確立し、
・ ソースにおいて第１暗号化データ１３１をクライアントへ送信し、
・ 第１暗号化データを使って、クライアントとその後のネットワーク通信１２を実行するように構成されている。
【００２９】
発明の理解を促進し、それがどのようにして実行されるかを示すために、以下、添付の図面が例として参照される。
【発明を実施するための最良の形態】
【００３０】
本発明は、リソースと、モバイルクライアントなどの外部クライアント間での安全な通信の確立に特に好適である。リソースは格納されるか、アプリケーションサーバを介してアクセス可能なソフトウェアアプリケーションである。図１を参照して上記で述べたように、本発明が実行される典型的な環境は、プライベートネットワーク内のリソース２０１と、外部ユーザが自身のパーソナルドメイン３００などでリソースにアクセスするためのさまざまなネットワーククライアントデバイス３０１、３０２、または３０３のいずれか１つを含む。リソースは、ネットワークの一部２０２、２０３へのアクセスを制御することが可能なサーバ２０１など、プライベートネットワーク２００の構成要素を含んでもよい。リソースは、サーバが有する所与のデータ２０３の集合や、ネットワークを通じて配信されるものであってもよい。外部ユーザのパーソナルドメイン内のエンドシステムは、スマートカードから携帯電話、そしてラップトップコンピュータに至るまでを対象とする。デバイス同士は、ＣＰＵパワー、メモリ、ディスプレイの大きさなどの観点から互いに明らかに異なる。末端の例としてはスマートカードなどが挙げられ、上端の例としてラップトップコンピュータが考えられる。他方で、システムはフレキシブルであるほど、セキュリティ面の危険およびそれに対する攻撃にさらされやすい。外部ユーザは、無線手段、有線経路または有線チャネル、光学チャネル、あるいは関連技術の当業者が容易に思い浮かぶさまざまなタイプの通信チャネルのいずれか、またはそれらの組み合わせによって、所有する機器が互いに接続されているモバイルユーザであってもよい。多数の機器のいくつかあるいは全ては、プライベートネットワークと直接あるいはインターネットなどの公衆網４００を介して通信を行うための手段を備えている。通信は、無線手段、有線経路または有線チャネル、光学チャネル、あるいは関連技術の当業者に容易に思い浮かぶさまざまなタイプの通信チャネルのいずれか、あるいはそれらの組み合わせによって行われうる。接続の際には、認証プロトコルの実行に先立ってエンドツーエンドの接続が確立されるか、あるいは当該処理を中断することなく確立されることが前提である。
【００３１】
従業員などの外部ユーザは、分散アプリケーションの実行環境をさまざまな外部デバイスから選ぶことができる。大きなスプレッドシートを更新するにはラップトップコンピュータを使い、仕事の割り当てをチェックするアプリケーションがプライベートネットワーク内の各データにアクセスするには携帯電話だけで済ませるのが合理的である。
【００３２】
次の語句は明細書全体で使用される。補足説明は一例である。
【００３３】
認証違反：エンティティが、使用すべきでないリソースを使用すること。
【００３４】
アカウンタビリティ：すべての通信イベントの責任を負うエンティティを特定することが可能であるべきこと。
【００３５】
認証：人間あるいは機械またはアプリケーションのいずれかのアイデンティティ認証を実行するプロセスのこと。
【００３６】
利用可能性：アプリケーション、デバイス、およびサービスが利用可能であって、かつ、正確に動作すべきであること。
【００３７】
ベアラーデバイス：セキュリティマネージャを物理的にホストするモバイルデバイス。
【００３８】
証明書：信頼された第三者（認証機関）によって認証され、偽造から保護された、ユーザの信用証明の集合。
【００３９】
クライアント同盟：セキュリティマネージャと認証を行っており、安全なチャネル上でのデータ交換が可能なすべてのクライアントデバイス。
【００４０】
機密性：転送されるか格納されたデータは、その意図する閲覧者にのみ示されるべきであること。
【００４１】
制御されたアクセス：認証されたエンティティのみが特定のサービスまたはデータにアクセス可能であるべきこと。
【００４２】
データ保全性：データのあらゆる書き換えが検知されるべきであること。
【００４３】
通信行為の拒否（拒絶）：エンティティがトランザクションや通信イベントなどのイベントへの参加を不当に拒否すること。
【００４４】
傍受：エンティティが読み取り目的でないデータを読み取ること。
【００４５】
偽造：エンティティが他のエンティティ名義で新たなデータを作ること。
【００４６】
データの喪失または修正：エンティティは、受信したデータパケットのシーケンスの１つまたは複数のパケットが喪失したことを検知することができる。エンティティは、受信したデータパケットまたはその一部が警告されたことを検知することができる。
【００４７】
仮装：エンティティが他のエンティティであると主張すること。
【００４８】
本発明に係る実施形態によれば、安全な通信は複数の外部クライアントデバイスとリソース間で確立される。これは、たとえばプライベートネットワーク内のサーバが、複数のクライアントデバイスとリソースを認証し、認証されたクライアント同士、および認証されたクライアントとリソース間で暗号鍵などの暗号化データを配布することによって行われる。とりわけ、さまざまな外部デバイスとリソース間の仲介役であると同時に、認証されていないデバイスや偽造されたデバイスが改変もしくは信頼できない状態で通信に参加しないことを保証するために、セキュリティマネージャが提供される。安全性が保証されたクライアントドメインは、クライアント同盟と呼ばれる。セキュリティマネージャは、クライアントデバイス内に搭載されるか、それ自身に固有のネットワーク通信能力を有する。
【００４９】
企業の、すなわちリソースの所有者の視点から見た場合、セキュリティマネージャおよびその内部に保存されたユーザの信用証明は、外部ユーザのパーソナルドメイン内で唯一信頼される要素である。個々のクライアントデバイス間、およびクラインデバイスと企業ネットワーク間で安全なエンドツーエンドの接続を確立するために、セキュリティマネージャはクライアントデバイスを認証し、プライベートネットワークまたは企業ネットワークと認証をする際に使われる信用証明をクライアントデバイスに発行し、鍵の生成とデータ署名を実行するといった各機能を実現する。本発明は全体的には１つのクライアント、セキュリティマネージャ、およびサーバが含まれる通信を主題にしているが、当業者は、多数のクライアントデバイスが関連する通信への本発明の適用を正しく認識するだろう。
【００５０】
第一のステップとして外部ユーザは、たとえば正しいパスフレーズ（個人識別番号またはパスワード）を、セキュリティマネージャをホストするデバイスに入力してセキュリティマネージャを起動させるなど、ユーザインタフェースに秘密情報を供給することで自分が合法的なユーザであることを証明する。
【００５１】
クライアントデバイスは、他のクライアントデバイスと、プライベートネットワークの構成要素（私有サーバやその他のリソースなどの企業ドメイン）に対しても自己を証明する。リソースは、プライベートドメインまたは下記で示すネットワークに位置しうる。
【００５２】
上述したように、本発明の環境では一定の安全性が確保されることが望ましい。これは、アプリケーションサーバの役割を担うサーバ２０１が、通信相手またはクライアントエンティティの身元証明を有することを含む。これは認証と呼ばれる。リソースへのアクセスは、適切な認証メカニズム、あるいは認可機関として知られるものによって許可されなければならない。言い換えると、リソースへのアクセスは認証されたエンティティのみに対して許可される。最後にすべての通信イベントが、後に記録をたどることができるように明らかにされなければならない。これは否認防止として知られる。
【００５３】
クライアントを認証するために、リソースはまず認証要求をクライアントデバイスに送信する。この認証要求は、クライアントに関連するセキュリティマネージャに送信される。
【００５４】
セキュリティマネージャは、たとえばホストまたはベアラーデバイスの通信機能を使って携帯電話に組み込まれるか又は関連付けられてネットワーク通信に参加し、ユーザからのからのパスフレーズを要求する。このコードは、個人識別番号またはパスワードなどである。パスフレーズの認証が成功すると、セキュリティマネージャは引き続き認証処理を行う。これは実際には、セキュリティマネージャが組み込まれたホストデバイスの電源が投入される都度行われる。
【００５５】
セキュリティマネージャは、パラメータとしての自己の証明書など、自身の識別子とともに認証応答を返送する。この識別子は、リソースの所有者によって発行されることが好ましい。識別子は、たとえばセキュリティマネージャの公開鍵や、クライアントの公開鍵によって暗号化される。公開鍵は識別子に含まれてもよい。
【００５６】
リソースは、受信した識別子証明書を認証して、セッションホストの公開鍵などのセッションキーを生成し、当該セッションキーをホストまたはベアラーデバイスに返送する。言い換えると、認証確認が送信される。
【００５７】
相互認証が必要な場合、リソースは第一認証要求または認証確認のいずれかに対して自分の証明書などの識別子を送信する。ホストまたはベアラーデバイスは、あらかじめインストールされた認証機関の識別子を使って、リソースの識別子を認証することができる。
【００５８】
このシナリオは、ラップトップなどの分離したクライアントデバイスを追加することで拡張することができる。上述の方法と同様に、セキュリティマネージャは携帯電話によってホストされる。こうして認証および鍵のネゴシエーションと交換が、双方のモバイルデバイスで行われ、最終的にエンドツーエンド（Ｅ２Ｅ）の安全な接続が確立される。
【００５９】
クライアントデバイスは、セキュリティマネージャ・ホストデバイスおよびセキュリティマネージャを管理する企業によって発行されたものと同じ識別子を保持する。
【００６０】
信頼されたセキュリティマネージャとクライアントデバイスのクライアント同盟において、セキュリティマネージャはラップトップが証明書の合法的な所有者であることを保証するに過ぎない。たとえば、企業ネットワークなどのプライベートネットワーク内のサーバは、セキュリティマネージャからの署名などによって認証された証明書のみを受け取る。
【００６１】
次に、クライアントが第三者識別子を保持するケースを検討する。セキュリティマネージャは、識別子がエンティティに属するなど、識別子を認証するだけでなく、識別子とクライアントが互いに密接に関連することを認証する役割も担う。そして最後に、セキュリティマネージャはクライアントが信頼できることをリソースに証明しなければならない。
【００６２】
次に、図５に関する本発明の実施形態を述べる。
【００６３】
図５は、本発明の第一実施形態に係る、クライアントデバイスとリソース間で安全なネットワーク通信を確立する方法を示す。
【００６４】
この方法では、クライアント１１１と、リソース１１２が提供される。先行技術を参照して述べたように、クライアントは１または複数の外部デバイスに設けられ、通信相手またはクライアントの役割を担う。第２ネットワークエンティティは、上述したように、プライベートネットワークなどに設けられたサーバまたはリソースである。前記クライアントは、このサーバまたはリソースと相互作用してデータを受信する。本明細書ではセキュリティマネージャ、リソース、サーバなどのネットワークエンティティを取り上げているが、これらは本発明で記載されたタスクおよびその他の必要な動作をデバイスに実行させる、複数の付属的ハードウェアやソフトウェアなどを包含する。特にサーバまたはリソースは、企業ネットワークなどの完全に私的なものを含む。
【００６５】
本実施形態ではさらにセキュリティマネージャ１１３１が設けられる。セキュリティマネージャは、証明書および暗号鍵の格納と、暗号化・復号化、および鍵の生成とデータ署名の実行が可能な、不正操作が行われないデバイスである。
【００６６】
第１ネットワークエンティティまたはクライアント１１１と、セキュリティマネージャ・ホストデバイス１１３は、各々、ソフトウェア、ハードウェア、あるいはそれらのあらゆる組み合わせによって実行される。第１ネットワークエンティティまたはクライアント、およびセキュリティマネージャ・ホストデバイスは、各々、パーソナルコンピュータ（特にラップトップコンピュータ）、電話（特に携帯電話）、ページャ、PDA、あるいはネットワーク通信が可能なあらゆるデバイスなど、適切なファームウェアおよびソフトウェアを含む、独立型のネットワークデバイスである。１つの実施形態では、第１ネットワークエンティティ１１１またはクライアントデバイスは、ネットワーク通信を確立する手段を備えるラップトップコンピュータを含む。セキュリティマネージャ１１３１は、SIMカード、スマートカード、専用シリコンチップ、あるいは適切なデータを有するカスタマイズ可能なチップまたはメモリや、適切な実施形態を実行するように構成されたソフトウェアルーティン、あるいは当業者が通常思い浮かべるさまざまな技術のいずれかを含む。
【００６７】
リソースは、通信において安全性が求められるプライベートネットワークや、企業ネットワークなどのドメイン、あるいはネットワーク通信が可能な構成要素などのネットワークエンティティを含む。
【００６８】
第１ネットワークエンティティまたはクライアントデバイスとセキュリティマネージャ・ホストデバイスは、GSM（移動体通信用グローバルシステム）、GPRS（汎用パケット無線サービス）、第３世代移動体通信システム、あるいは当業者が容易に思いつくあらゆる無線／有線通信システムなどの携帯電話通信網に接続する。あるいは第１ネットワークエンティティまたはクライアントデバイスとセキュリティマネージャ・ホストデバイスは、WLAN（無線LAN）などの無線ホットスポットに移動する。すべてのネットワーク技術は固有の認証方式およびセキュリティ方式を有しており、使われている方式の中にはプライベートドメインの制御が及ばないものがあることが考えられる。したがって、安全性のあるモバイル分散アプリケーションを実行するための実行可能な唯一の解決法は、必要とされるすべてのセキュリティ機構がプライベートドメインまたは企業ドメインによってサポートされ、かつ、プライベートネットワークまたは企業ネットワーク内だけでなく、モバイルデバイスとプライベートドメイン間にも適用可能なことである。
【００６９】
この実施形態ではセキュリティマネージャは、仮の証明書としての第１識別子を生成して、それを前記セキュリティマネージャが組み込まれたセキュリティマネージャ・ホストデバイスのネットワークシステムによって第１ネットワークエンティティまたはクライアントへ送信する。第１ネットワークエンティティまたはクライアントは、セキュリティマネージャから第１識別子を受信して、それをリソースに転送する。リソースは、第１識別子を受信して、この識別子の有効性を確立するように構成されている。この有効化処理は、受信した識別子が前記セキュリティマネージャで実際に生成されたものであって、前記クライアントが前記リソースへアクセスする権利を与えることを決定するステップを含む。
【００７０】
認証が行われると、リソース１１２は第１暗号化データを前記クライアントへ送信する。この第１暗号化データは、セッションキーや、暗号化されたもしくは安全な通信を保証するデータを含む。第１識別子は、仮の証明書である場合、たとえばセキュリティマネージャ１１３１の公開鍵や、クライアントの公開鍵を使って暗号化される。この場合、セキュリティマネージャの秘密鍵またはクライアントの秘密鍵で複合化される。この結果、第１暗号化データを使った、前記クライアントとリソース間の通信が開始される。クライアントとネージャ・ホストデバイスはいずれも、前記クライアントを介して、前記第２ネットワークエンティティまたはリソース１１２のデータへのアクセスを希望する外部ユーザによって使用される電子機器であってもよい。
【００７１】
このようにして、クライアント１１１とセキュリティマネージャ・ホストデバイス１１３の信頼関係が確立され、これを受けてセキュリティマネージャ・ホストデバイス１１３はクライアント１１１に第１識別子１２４を送信する権限を有することになる。この識別子は、リソースに第１暗号化データ１３１を第１ネットワークエンティティまたはクライアント１１１へ提供して、前記第１暗号化データ１３１に基づいた安全な通信を開始するように指示するものである。
【００７２】
したがってクライアント１１１は、セキュリティマネージャ１１３１から権限を与えられた場合のみ、リソースとの安全な通信を開始することができる。こうしてクライアントとリソース間の信頼関係が確立される。
【００７３】
よって本発明は、クライアントとリソース間の安全なネットワーク通信を確立する方法に関する。この方法は、セキュリティマネージャとクライアント間で信頼関係を確立するステップと、セキュリティマネージャで第１識別子１２４を生成して、その識別子をセキュリティマネージャからクライアントに送信するステップと、第１識別子１２４をクライアントからリソースへ転送するステップと、リソースでの第１識別子１２４の有効性を確立し、リソースからクライアントへ第１暗号化データ１３１を転送するステップと、第１暗号化データ１３１を使って、クライアントとリソース間でその後のネットワーク通信１２を行うステップを含む。
【００７４】
この方法の他の形態として、セキュリティマネージャとクライアント間の信頼関係を確立するステップはさらに、クライアントに関する第２識別子１２３を、クライアントからセキュリティマネージャへ送信するステップと、セキュリティマネージャで第２識別子１２３の有効性を確立するステップを含む。
【００７５】
この方法の他の形態として、第１識別子の生成に先立って、リソースとセキュリティマネージャ間の信頼関係を確立するステップが含まれる。
【００７６】
本発明の他の実施形態では、前記リソースと前記セキュリティマネージャとの間の信頼関係を確立する前記ステップは、前記セキュリティマネージャに関する第３識別子１２２を前記セキュリティマネージャから前記リソースへ送信するステップと、前記リソースにおいて、前記第３識別子１２２の有効性を確立するステップとをさらに備える。
【００７７】
本発明の他の実施形態では、前記リソースと前記セキュリティマネージャとの間の信頼関係を確立する前記ステップは、前記リソースに関する第２暗号化データ１３２を前記リソースから前記セキュリティマネージャへ送信するステップと、前記第２暗号化データ１３２を使用して、前記リソースと前記セキュリティマネージャとの間におけるその後のネットワーク通信１１を実行するステップとをさらに備える。
【００７８】
本発明の他の実施形態では、前記リソースと前記セキュリティマネージャとの間の信頼関係を確立するステップは、前記リソースに関する第４識別子１２１を前記リソースから前記セキュリティマネージャへ送信するステップと、前記セキュリティマネージャにおいて、前記第４識別子１２１の有効性を確立するステップとをさらに備える。
【００７９】
本発明の他の実施形態では、前記リソースと前記セキュリティマネージャとの間の信頼関係を確立する前記ステップと、前記セキュリティマネージャと前記クライアントとの間の信頼関係を確立する前記ステップと、前記クライアントと前記リソースとの間の信頼関係を確立する前記ステップのうち、少なくとも１のステップが繰り返される。
【００８０】
本発明の他の実施形態では、前記少なくとも１のステップの繰り返しは、予め定められた時間間隔もしくは任意の時間間隔で実行される。
【００８１】
本発明は、クライアントとリソースとの間で安全なネットワーク通信を行うための通信ネットワークであって、第１クライアントメディエータおよび第２クライアントメディエータが設けられたクライアントと、第１リソースメディエータおよび第２リソースメディエータが設けられたリソースと、第１識別子を生成し、それを前記第２クライアントメディエータへ送信するセキュリティマネージャとを備える通信ネットワークという観点から説明されてもよい。
【００８２】
前記第２クライアントメディエータと前記第２リソースメディエータは、前記クライアントと前記リソースとの間で信頼関係を確立するように構成される。
【００８３】
前記第２クライアントメディエータの構成は、前記第２クライアントメディエータが、前記セキュリティマネージャから前記第１識別子１２４を受信し、前記第１識別子１２４を有効化のために前記リソースに送信し、前記リソースから第１暗号化データ１３１を受信し、前記第１暗号化データ１３１を使用して、前記リソースとの間で安全なネットワーク通信１２を行う構成である。
【００８４】
前記第２リソースメディエータの構成は、前記第２リソースメディエータが、前記第１識別子の有効性を確立し、前記第１暗号化データ１３１を前記クライアントへ送信し、前記第１暗号化データ１３１を使用して、前記クライアントとの間で、その後のネットワーク通信１２を行う構成である。
【００８５】
この方法は、ユーザが任意の数のモバイルデバイスを利用して分散アプリケーションによって企業ネットワークへアクセスし、当該アクセスの安全性が確保されなければならないシナリオに適用できる。言い換えると、複数のデバイスとプライベートネットワークは互いにセッションキーを交換し、少なくとも１つのエンティティが秘密鍵を保持してデータ署名を行うことで相互認証を行う。本発明は、たとえば企業対被雇用者のシナリオに非常に適している。
【００８６】
この方法は、信用されないかもしれないネットワーク上を介して通信するあらゆる当事者間で信頼性を構築する際の先行技術の欠点を克服しており、その結果、企業ネットワークが、商取引などのあらゆる通信イベントに関連するすべてのエンティティの身元に関する証明を得ることができる。この仕組みと同様に、別々のデバイスの集まりに含まれるすべてのモバイルクライアントデバイスは、各々、同じ集まりに属する他のモバイルデバイスと企業ドメインの身元証明を持っている。またモバイルデバイス間、およびモバイルデバイスとネットワーク間で授受されるメッセージは傍受および修正（喪失を含む）から保護され、通信イベントが明らかにされるので、通信は拒絶されない。
【００８７】
本方法は、クライアントデバイスの数と種類が不明であって、モバイルデバイス同士、およびモバイルデバイスと企業ネットワーク間が信頼されていない環境に適用できる。
【００８８】
またセキュリティマネージャの公開鍵で第１暗号化データ１３１を暗号化することによって、セキュリティマネージャ（および間接的にリソース）の安全性は強化されることとなる。なぜなら、第１暗号化データを送信する際には、クライアントが第１暗号化データを使用するに先立ち、クライアント同盟が依然として機能していることが必要だからである。
【００８９】
セキュリティマネージャとクライアントがクライアント同盟に属していることを証明するために、セキュリティマネージャとクライアント、およびクライアントとリソースの認証が一意のまたは任意の間隔で繰り返される。この思想に基づき、同盟に属することなくクライアントデバイスが極秘の企業データにアクセスするという可能性は排除することができる。
【００９０】
図６は本発明の第２実施形態に係る、クライアントデバイスとリソース間で安全なネットワーク通信を確立する方法を示す。
【００９１】
上述の実施形態を改良した、図６に示される本発明の実施形態によると、第１ネットワークエンティティまたはクライアント１１１には第１クライアントメディエータ１１１１および第２クライアントメディエータ１１１２が設けられており、第２ネットワークエンティティまたはリソース１１２には第１リソースメディエータ１１２３および第２リソースメディエータ１１２４が設けられている。これらのメディエータは、ハードウェア、ファームウェアまたはソフトウェア、あるいはそれらの組み合わせによって実行される。
【００９２】
第１クライアントメディエータ１１１１はセキュリティマネージャ１１３１と相互作用して、第１ネットワークエンティティまたはクライアント１１１と、セキュリティマネージャ１１３を含むセキュリティマネージャ・ホストデバイスの信頼関係を確立する。第２クライアントメディエータ１１１２は、セキュリティマネージャ１１３１から前記第１識別子１２４を受け取って、それを第２ネットワークエンティティまたはリソース１１２の第２リソースメディエータへ転送する。次にリソースで、上述したように、第１識別子１２４を認証するプロセス９が実行される。第１識別子１２４が有効であると判断された場合、第２リソースメディエータは第１暗号化データ１３１をメッセージ１０でクライアント１１１の第２クライアントメディエータへ送信する。これを受けて第２クライアントメディエータ１１１２は、第１暗号化データ１３１を使用してリソースの第２リソースメディエータと安全な通信１２を開始する。
【００９３】
セキュリティマネージャ・ホストデバイス１１３のセキュリティ部１１３１の安全性とは、セキュリティマネージャと第２ネットワークエンティティまたはリソースの間に信頼関係があることを意味する。すなわち、第１識別子が、信頼されたセキュリティ部で生成されたことが判明した場合、リソース１１２は、本発明で想定される、当該リソースとセキュリティマネージャ１１３１、およびクライアント１１１とセキュリティマネージャ１１３１間の信頼関係に基づいてクライアント１１１との通信を安全に開始することができる。
【００９４】
セキュリティマネージャは不正操作できないように構成され、さらに、ユーザの信用証明を保持するように構成されている。セキュリティマネージャは、ベアラーデバイスまたはセキュリティマネージャ・ホストデバイスと一体であってもよい。ベアラーデバイスとクライアントデバイスなど、異なるモバイルデバイス間で通信リンクが確立される。これらのデバイスに、パスワード入力用のソフトウェアコンポーネントが設けられてもよい。
【００９５】
図７は、本発明の第三実施形態に係る、クライアントデバイスとリソース間で安全なネットワーク通信を確立する第二の方法を示す。
【００９６】
これまで述べてきた実施形態をさらに改良したものである図７は、クライアント１１１とセキュリティマネージャ・ホストデバイスの信頼関係が、各々、第１クライアントメディエータ１１１１およびセキュリティマネージャ１１３１によってどのように確立されるかをさらに具体的に示す。第１クライアントメディエータ１１１１は、第２識別子１２３をメッセージ５でセキュリティマネージャ・ホストデバイス１１３のセキュリティマネージャ１１３１へ送信する。そしてセキュリティマネージャ１１３１で処理ステップ６が実行され、第２識別子１２３の有効性が確立される。第２識別子１２３が適切なクライアントデバイスを表し有効であると判断された場合、第１識別子１２４がセキュリティマネージャ１１３１で生成される。第１識別子１２４は、クライアントにサーバへのアクセス権限を与える仮の証明書である。第１識別子１２４は、メッセージ７でクライアントデバイスへ送られる。そしてクライアントデバイスは、第１識別子をメッセージ８でサーバへ送信する。サーバはこの第１識別子に対して有効化処理９を実行する。この有効化処理は、たとえば、受信した識別子がセキュリティマネージャで実際に生成されたものであって、そのセキュリティマネージャがクライアントにリソースへのアクセス権限を与えたことを判定するステップを含む。この有効化処理９が成功した場合、サーバ１１２は暗号化または安全な通信を可能にするセッションキーやデータなどの第１暗号化データ１３１を生成し、当該データをメッセージ１０でクライアントデバイスへ送信する。この第１暗号化データは、証明書である第１識別子１２４の公開鍵で暗号化される。
【００９７】
次に、クライアントデバイスとサーバ間でセキュアチャネル１２が確立され、プライベートネットワークへのアクセスが可能になる。セキュアチャネルは、サーバ１１２がセキュリティマネージャ・ホストデバイス１１３のセキュリティマネージャ１１３１を信頼し、これによってクライアント１１１との信頼関係を確立することが可能になるため、クライアント１１１からの第１識別子１２４の受信によってサーバまたはリソース１１２が、クライアント１１１も信頼できるとの認識に基づいて確立される。これに基づき、第２ネットワークエンティティまたはリソース１１２が、第１暗号化データ１３１を第１ネットワークエンティティまたはクライアント１１１に送信する。
【００９８】
図８は、本発明の第４実施形態に係る、クライアントデバイスとリソース間で安全なネットワーク通信を確立する方法を示す。
【００９９】
上述の実施形態を改良した同図では、リソース１１２とセキュリティマネージャ・ホストデバイス１１３のセキュリティマネージャ１１３１間の信頼関係がどのように確立されるかがさらに具体的に示される。この実施形態では、第３識別子１２２がセキュリティマネージャ１１３１からリソース１１２の第１リソースメディエータ１１２３へ送られる。この第３識別子１２２は、リソース１１２によって発行された証明書を含む。第１リソースメディエータ１１２３は、第３識別子１１２を受信するとともに、処理ステップ２において第３識別子１２２の有効性を判定する。第３識別子１２２が有効である、すなわち、第２ネットワークエンティティまたはリソースから信頼されたエンティティによって発行されたと判断されると、第２ネットワークエンティティまたはリソース１１２の第１リソースメディエータは、セキュリティマネージャ・ホストデバイス１１３のセキュリティマネージャ１１３１へ第２暗号化データ１３２を送信する。こうしてセキュリティマネージャ１１３１は、リソース１１２と安全な通信１１を開始する。
【０１００】
図９は、本発明の第５実施形態に係る、クライアントデバイスとリソース間で安全なネットワーク通信を確立する方法を示す。
【０１０１】
上述の各実施形態さらに改良した本実施形態によると、リソース１１２の第１リソースメディエータ１１２３はセキュリティマネージャ１１３１へ第４識別子１２１を送信する。そしてセキュリティマネージャ１１３１で処理ステップ４が実行され、第４識別子の有効性が確立される。この結果、安全な通信１１の開始に先立ち、相互の信頼関係が確立される。この第４識別子は、リソースの証明書である。
【０１０２】
図１０は本発明の実施形態に係るリソースをさらに具体的に示す。
【０１０３】
この実施形態では、リソース１１２は記憶手段１１２１と処理手段１１２２を備える。リソースは本来有する機能に加えて、処理機能、記憶機能、またはそれらの組み合わせを持つ独立の構成要素を含む拡張ネットワークを備えてもよい。このように、本発明のリソースのコンポーネントは複数の分離したエレメントに対して配布される。本発明のリソース１１２は、少なくとも本発明のクライアント（図示されていない）と通信を行う手段を備えてもよい。記憶手段１１２１は、リソースの証明書である第４識別子１２１を格納する。記憶手段１１２１はさらに、クライアント１１１が本発明におけるアクセスを試みるデータ１１２５を格納する。このデータは静的データ、アプリケーションデータ、通信データのストリーム、クライアントで生成されたデータをリソース内で処理することによって得られるデータ、または外部クライアントがアクセスを所望する多数のリソースのいずれかを含む。処理手段１１２２は第１リソースメディエータ１１２３および第２リソースメディエータ１１２４を備える。第１リソースメディエータ１１２３は、すでに述べたように、リソースに含まれる一般的な通信手段（図示されていない）によって、セキュリティマネージャ１１３１と通信を行う。また第１リソースメディエータ１１２３は、第２暗号化データ生成器１１２６および第３識別子バリデータ１１２７と通信を行う。第３識別子バリデータ１１２７は、本発明にしたがってセキュリティマネージャ１１３１から第３識別子１２２を受信し、その有効性を判断する。第３識別子バリデータ１１２７は、第２暗号化データ生成器１１２６と接続され、第２暗号化データ１３２の生成および発行を第２暗号化データ生成器１１２６に促す。第２暗号化データは、記憶手段に格納された第４識別子１２１とともに、セキュリティマネージャ１１２６へ返送される。また第２暗号化データ生成器は記憶手段１１２１に接続されて、その内部に格納された情報に基づいて第２暗号化データ１３２を生成する。
【０１０４】
第２リソースメディエータ１１２４は、リソースに含まれる一般的な通信手段（図示されていない）によって、第２クライアントメディエータ１１２１と通信を行う。また第２リソースメディエータ１１２４は、第１暗号化データ生成器１１２８および第１識別子バリデータ１１２９と通信を行う。本発明に係る第１識別子バリデータ１１２９は、第２クライアントメディエータから第１識別子１２４を受信し、その有効性を判断する。第１識別子バリデータ１１２９は、第１暗号化データ生成器１１２８に連結されており、これによって、第２クライアントメディエータ１１２１に返送する第１暗号化データ１３１の生成および発行を第１暗号化データ生成器１１２８に促す。また第１暗号化データ生成器は記憶手段１１２１に連結されており、その内部に格納された情報に基づいて第１暗号化データ１３２を生成する。
【０１０５】
本発明は、ネットワーク上での安全な通信を開始するように、第１リソースメディエータの動作によってセキュリティマネージャと信頼関係を確立するように構成されたリソースにおいて具体化される。第２リソースメディエータは、セキュリティマネージャによって生成されてクライアントへ送信された後にリソースに転送された第１識別子１２４の有効性を確立し、リソースにおいて第１暗号化データ１３１をクライアントへ送信し、この第１暗号化データを使ってクライアントと新たな通信１２を実行するように構成されている。
【０１０６】
図１１は本発明の実施形態に係るセキュリティマネージャをさらに具体的に示す。
【０１０７】
図１１に示されるように、セキュリティマネージャ１１３１が組み込まれたセキュリティマネージャ・ホストデバイス１１３が提供される。セキュリティマネージャは、処理手段１１３８と記憶手段１１３７、およびセキュリティマネージャに割り当てられたタスク（以下で述べる）を実行するために必要な他の構成要素を備える。図１１に示されるようにセキュリティマネージャは、第１リソースメディエータによって提供された第４識別子の有効性を確立するための第４識別子バリデータ１１３４と、第１クライアントメディエータによって提供された第２識別子の有効性を確立するための第２識別子バリデータを備える。この有効化処理は、上述した有効化処理４および有効化処理６である。これらの機能は実質的には処理手段１１３８によって実行される。またセキュリティマネージャ１１３１は、第３識別子１２２を第１リソースメディエータに、第１識別子１２４または第１命令を第２クライアントメディエータに提供するように構成されている。各識別子は単に記憶手段１１３７に格納されたり、処理手段１１３８で生成されたり、記憶手段に格納されたデータに基づいて処理手段で生成されたり、あるいはたとえばリアルタイムクロックから得られたりする。
【０１０８】
上述したように、セキュリティマネージャ・ホストデバイス１１３はセキュリティマネージャ１１３１を含む。セキュリティマネージャ１１３１は、処理手段１１３８および記憶手段１１３７を備える。記憶手段と処理手段は、既存の演算システムの方法で協働する。記憶手段１１３７は、当業者が容易に思い浮かべるあらゆるデータ記憶装置を含む。たとえば、記憶手段はハードドライブ、固体メモリ、EEPROMである。記憶手段は、第２ネットワークエンティティまたはリソース１１２によって発行された証明書である第３識別子１２２と、上述したように、第１ネットワークエンティティまたはクライアント１１１向けの第１暗号化データ１３１を発行する許可を与えるためにリソースによって認識される第１識別子１２４を格納する。記憶手段１１３７は、上述したように、第３識別子１２２を第１リソースメディエータ１１２３に、第１識別子１２４を第２クライアントメディエータ１１２に送信する。この送信は、処理手段１１３８が制御して、セキュリティマネージャ・ホストデバイスに備わったネットワーク通信手段を介して実行される。また既に述べたように、処理手段１１３８は、第１リソースメディエータから第４識別子を、第１クライアントメディエータから第２識別子を受信するとともに、第４識別子バリデータ１１３４で第４ネットワーク識別子を認証する処理ステップ４と、第２識別子バリデータ１１３６で第２識別子を認証する処理ステップ６を実行する。また第４識別子バリデータは、第４識別子の有効性がひとたび確立されると、上述したように、記憶手段１１３７から第１リソースメディエータ１１２３へ第３識別子１２２が送信されるように構成されており、この結果、２者間の相互認証が行われる。これと同じく、第２識別子バリデータは、第２識別子の有効性がひとたび確立されると、記憶手段１１３７から第２クライアントメディエータ１１２へ第１識別子１２４が送信されるように構成されており、この結果、２者間の相互認証が行われる。
【０１０９】
イベントのシーケンスは上記のとおりであるが、他のイベントのシーケンスであってもよい。
【０１１０】
セキュリティマネージャ・ホストデバイスを本発明で採用するか否かは自由である。しかしながらセキュリティマネージャ・ホストデバイスは、他のクライアントデバイスおよびリソースと通信を行うための通信手段１１３３と、ユーザ１４と通信を行うためのユーザインタフェース１１３０を備えることが好ましい。セキュリティマネージャは、セキュリティマネージャ・ホストデバイスがユーザ、クライアント、リソースなどからの通信を正確に受け渡すように制御するホストインタフェース１１３２を備える。このホストインタフェース１１３２は処理手段１１３８に実装されてもよい。
【０１１１】
セキュリティマネージャ・ホストデバイスまたはセキュリティマネージャ１１３１は、非対称暗号化のための秘密鍵と公開鍵のペアと、対称暗号化用のセッションキーを格納する。モバイルユーザは、証明書発行機関（さらには他のエンティティ）に不可欠な証明書、個人識別番号（PIN）、セキュリティマネージャにアクセスしてそれを起動するためのパスフレーズやパスワードを有する。セキュリティマネージャ・ホストデバイスまたはセキュリティマネージャ１１３１は、ユーザ証明書の取り消しリストを格納してもよい。またセキュリティマネージャは、適切な鍵生成処理によって秘密鍵／公開鍵のペアを生成することなど、その外部に秘密鍵を公開することなくセキュリティに関連するすべての動作を実行する機能がある。セキュリティマネージャはモバイルユーザに対して、自身の証明書機関CAのリストと証明書を管理することを認めなければならない。またセキュリティマネージャは、証明書の送信、他のエンティティの公開鍵を使ったデータの暗号化、他のエンティティの多数の証明機関（CA）の認証に対処する。あるいはこれらの機能は、あらかじめ定められたセキュリティ分類に属する、信頼されたクライアントデバイスに委託してもよい。セキュリティマネージャは 好ましくはXS.17、FIPS 186-2適合の乱数を生成するための暗号用疑似乱数生成器を備えてもよい。またリアルタイムクロックを実装してもよい。
【０１１２】
第１識別子または第１命令１２４は、リソース１１２またはクライアント１１１などの本発明のネットワーク内の他の構成要素に、本発明にしたがって割り当てられたタスクを実行させるコーディングを含む。コーディングは、個々の構成要素によって直接解読可能なフォーマットに暗号化された命令を、デバイスの一般の低レベルコードから、そのデバイスで動作する特定のアプリケーションによってのみ解読可能な命令までを含むさまざまな実施レベルにおいて混合することである。
【０１１３】
実装されたすべての機能とセキュリティマネージャ内のユーザの信用証明は、信頼されたエンティティによって発行される。企業対被雇用者のシナリオにおいて、信頼されたエンティティは企業自身であってもよい。
【０１１４】
このように本発明は、ネットワークで安全な通信を確立するためのセキュリティマネージャにおいて具体化される。このセキュリティマネージャは、第１識別子１２４または第１命令を生成するとともに、この命令を、解読用にクライアントに組み込まれた第２クライアントメディエータに送信するように構成されている。第１命令は、第２クライアントメディエータに当該命令を第２リソースメディエータへ転送することを促す。
【０１１５】
また第１識別子命令は、第２リソースメディエータが前記第１命令を有効化するための有効化処理９と、第１暗号化データ１３１の第２クライアントメディエータへの送信と、第１暗号化データ１３１を使用しているリソースとのその後のネットワーク通信１２を行うことを促すために生成される。
【０１１６】
図１２は、本発明の１実施形態に係る、クライアントデバイスをさらに具体的に示す。上述したようにクライアントデバイス１１１は、本発明を実行するように構成された、ラップトップコンピュータ、携帯電話、PDAなどの既存のデバイスである。したがってクライアントデバイス１１１は、記憶手段１１１４、処理手段１１１３を備える。クライアントデバイスは、セキュリティマネージャ１１３１と相互作用する第１クライアントメディエータと、セキュリティマネージャ１１３１および第２リソースメディエータ１１２４の双方と相互作用する第２クライアントメディエータを備える。またクライアントデバイス１１１は、ユーザ１４と通信を行うためのユーザインタフェース１１１０を備えてもよい。クライアントデバイス１１１は他のクライアント、セキュリティマネージャ１１３１を仲介にするセキュリティマネージャ・ホストデバイス１１３およびリソース１１２と通信を行うための通信手段を備える。ユーザインタフェース１１１０および通信手段１１１５は、処理手段１１１５によって制御される。
【０１１７】
このように本発明は、リソースとの安全な通信を開始するように構成された、第１クライアントメディエータと第２クライアントメディエータを備えたクライアントで具体化される。クライアントは、第１クライアントメディエータの動作によって、セキュリティマネージャと信頼関係を確立するように構成されている。第２クライアントメディエータと、リソースに組み込まれた第２リソースメディエータは、各々、クライアントとリソース間で信頼関係を確立するように構成される。
【０１１８】
第２クライアントメディエータへの適用においては、第２クライアントメディエータが、セキュリティマネージャによって生成された第１識別子１２４をセキュリティマネージャから受信し、リソースから第１暗号化データ１３１を受信し、第１暗号化データ１３１を使用してリソースとその後のネットワーク通信１２を行うように構成されることを含む。
【０１１９】
第２リソースメディエータへの適用においては、第２リソースメディエータが、第１識別子１２４の有効性を確立し、第１暗号化データ１３１を送信し、第１暗号化データを使用しているリソースとその後のネットワーク通信１２を行うように構成されることを含む。
【０１２０】
第６の実施形態では、セキュリティマネージャとリソースが相互に認証を行い、それによって生成されたセッションキーがセキュリティマネージャに送信される。次に、セキュリティマネージャとラップトップが互いに認証する。ラップトップは当事者リクエストを送信して認証を開始する。このステップがないと企業ドメインが接続要求を受け付けないので、あることが好ましい。スマートカードなどのセキュリティマネージャは、ラップトップのアイデンティティを認証し、あるいは言い換えると、ラップトップの証明書を認証して、企業ネットワークとの間で認証を行うためにラップトップが使う仮の証明書を発行する。仮の証明書が企業ネットワークによって承認されると、セッションキーが生成され、セキュリティマネージャの公開鍵（あるいはラップトップの公開鍵）で暗号化された後にラップトップに返送される。
【０１２１】
セキュリティマネージャの公開鍵でセッションキーを暗号化することによって、セキュリティマネージャ（そして間接的には企業ドメイン）の安全性が高まる。なぜなら、セッションキーを送信する際には、モバイルデバイスがセッションキーを使用することに先立って、クライアント同盟が依然として機能している必要があるためである。
【０１２２】
セキュリティマネージャとラップトップデバイスが依然として同盟に属することを保証するために、セキュリティマネージャとラップトップ、およびラップトップと企業ネットワークの認証は所定のまたは任意の間隔で繰り返される。このことが一般規則として定められれば、同盟に参加することなくクライアントデバイスが秘密の企業データにアクセスすることはなくなる。
【０１２３】
＜クライアント同盟のブートストラッピング＞
認証には、関連するデバイスの性質に応じて証明書、個人識別番号（PIN）およびパスワードのいずれが使われてもよい。認証および個人識別番号は、セキュリティマネージャがスマートカードなどである場合には特に都合がよく、パスワードは（可能であるなら証明書とともに）ラップトップまたはPDAの場合に使うことが想定される。証明書は、企業に直接または第三者のいずれかによって生成される。これは、ラップトップまたはPDAなどの任意のデバイスが認証されてクライアント同盟に参加する場合には重要である。
【０１２４】
図１３は、本発明の第７実施形態に係る、クライアントデバイスとリソース間で安全なネットワーク通信を確立する方法を示す。
【０１２５】
上記の実施形態は、同盟に参加する外部デバイスが、自身を証明するためのデータを持つケースにおいて特に適切である。しかしながら、そのようなデータが利用できなかったり、認証には不向きであったりすることがある。
【０１２６】
この実施形態では、セキュリティマネージャが有効な信用証明を複数保持している。これらの複数の信用証明は、生成され、クライアントデバイスなどの外部デバイスに送信される。ゆえに本実施形態は、安全な通信または「ダイナミック・ウェブ・オブ・トラスト」のブートストラッピングに関する。そのようなタスクに関連する問題は、安全でないチャネル上でセキュリティマネージャとクライアントデバイスを接続することと、ユーザの信用証明を生成してそれを転送することを含む。
【０１２７】
本発明の実施形態は、セキュリティマネージャが信用証明を保持するとともに、鍵生成などの暗号化を行うための各機能を実行するという制約に基づいている。またセキュリティマネージャ、あるいはセキュリティマネージャ・ホストデバイスもしくはベアラーデバイス（セキュリティマネージャを実行するモバイルデバイスなど）は、認証、鍵生成、および配布プロトコルに対応していなければならない。また、外部のクライアントデバイスは対称暗号化および非対称暗号化を実行することができ、セキュリティマネージャとベアラーデバイスと同じ認証および鍵管理プロトコルを実行し、パスワード、ＰＩＮまたはパスフレーズを使ったユーザ認証に対応するという制約がある。
【０１２８】
セキュリティマネージャ１１３とクライアントデバイス１１１間には、セキュアチャネル１３が確立される。チャネル１３は、インターネットキー交換プロトコル、ディフィーへルマン鍵交換、ブルートゥースデバイス接続、および当業者が容易に思い浮かべるその他のプロトコルと類似の結果をもたらす、先行技術に関連して議論したあらゆる適切な手続きによって安全が確保される。
【０１２９】
使い捨てパスワード、ＰＩＮ、コードまたは文字列などの識別子１２５が、ディスプレイスクリーン、可聴プロンプトなどのセキュリティマネージャ・ホストデバイス１１３のユーザインタフェース１１３０を介して、ユーザ１４に通知される。ユーザ１４は、クライアントデバイス１１１のユーザインタフェース１１１０に識別子１２５を入力する。次に識別子１２５は、チャネル１３を介して、セキュリティマネージャ１１３に返送される。その結果、キーネゴシエーションおよび交換プロトコルがベアラーデバイスとモバイルデバイスによって実際に行われたことの証明書が発行される。
【０１３０】
上記の仮の証明書などの第１識別子または複数の信用証明１２４はセキュリティマネージャ１１３で生成される。
【０１３１】
この第１識別子は、チャネル１３を介してメッセージ７でクライアントデバイス１１１に送信される。クライアントデバイスは、そのアイデンティティを証明するために、第１識別子１２４をメッセージ８でリソース１１２に送信する。
【０１３２】
この第１識別子に対し、サーバが有効化処理９を行う。この有効化処理は、受信した識別子がセキュリティマネージャで生成されたものであるか否かを判定するステップと、前記リソースへアクセスする権利を前記クライアントに与えるステップを含む。鍵のペアを送信する場合には、セキュアチャネルで行うことが好ましい。
【０１３３】
この有効化処理９が成功した場合、サーバ１１２は暗号化または安全な通信を可能にするセッションキーやデータなどの第１暗号化データ１３１を生成して、そのデータをメッセージ１０でラップトップに送信する。この第１暗号化データは、証明書である第１識別子１２４の公開鍵で暗号化されることが好ましい。
【０１３４】
こうして、クライアントデバイスとサーバ間でセキュアチャネル１２が確立され、プライベートネットワークへのアクセスが利用可能となる。
【０１３５】
ゆえに本発明に係る本実施形態によれば、リソースとセキュリティマネージャ間で信頼関係を確立するステップではさらに、前記セキュリティマネージャと、信頼されていないクライアントの間でチャネルを確立するステップと、前記信頼されていないクライアントの側でユーザ認証情報の入力をリクエストするステップと、前記ユーザ認証情報を前記セキュリティマネージャで認証するステップが実行されてもよい。
【０１３６】
この方法をさらに発展させた態様において、チャネルはセキュアチャネルであって、このセキュアチャネルは、インターネット鍵交換プロトコル、ディフィーへルマン鍵交換、およびブルートゥースデバイス接続、あるいは当業者が容易に思い浮かべるプロトコルを使って確立される。
【０１３７】
この方法をさらに発展させた態様において、ユーザ認証情報は、セキュリティトークン、使い捨てパスワード、個人識別番号、コードまたは文字列のうちの少なくともいずれか１つである。
【０１３８】
図１４は、図１３に示す実施形態をさらに発展させた、クライアントデバイスとリソース間で安全なネットワーク通信を確立する方法を示す。
【０１３９】
第９の実施形態では、上記に提案した方法は、たとえば弱連結の無線モバイルデバイス同士と、デバイスとプライベートネットワーク（たとえば企業ネットワーク）間に適用できる認証アルゴリズムおよび認証プロトコルを定義する。特に、ユーザの信用証明として証明書が使われる。本発明によればセキュリティマネージャは、認証データの認証と、仮の証明書の生成とそのモバイルデバイス間での配布と、仮の認証データを任意の間隔で再認証することを行う。仮の認証データは、企業ネットワークへアクセスするために、あらゆるデバイスに使用されうる。この処理は、プライベートネットワークが認識できるモバイルデバイスは、プライベートネットワーク自身に属するデバイスと同じ程度に信頼されることを保証する。
【０１４０】
第１０の実施形態の方法は、セキュリティマネージャと企業ネットワークの認証を行うステップと、セキュリティマネージャおよび企業ネットワークにおいて、様々なモバイルデバイスの認証を行うステップと（なお、いずれのデバイスも信頼されている、すなわち証明書を発行されてその発行機関（企業）の支配下にあることが前提とされている）、セキュリティマネージャおよび企業ネットワークにおいて、第三者機関を出所とし、あらかじめインストールされた認証データ（証明書など）を有さないモバイルデバイスをいくつか含むモバイルデバイスの認証を行うステップとを含む。
【０１４１】
本発明は、モバイルデバイスと企業ネットワーク間で信頼できる通信関係と、あらかじめインストールされた共通の秘密情報を必要とすることなく、ビジネスアプリケーションへの円滑で安全なアクセスを実現する点で、先行技術に対して多くの利点を有する。
【０１４２】
とりわけ、本発明によってモバイルクライアントデバイス同士、およびモバイルクライアントデバイスと企業ネットワーク間の信頼関係の確立と、モバイルクライアントデバイス同士、およびモバイルクライアントデバイスと企業ネットワーク間の通信リンクが確立される。
【０１４３】
第２に、信頼と安全性のある通信リンクによって、モバイルユーザは企業ネットワークおよび当該ネットワークで実行される分配アプリケーションに時と場所を問わずアクセスできる。
【０１４４】
第３に、モバイルデバイスには、あらかじめインストールされた共通の秘密情報が必要とされないので、通信に参加することができる限り、信頼されたモバイルデバイスの集合に対して新規のデバイスの加入が受け付けられる。
【０１４５】
ユーザの信用証明で初期設定されると、セキュリティマネージャは新たな信用証明を生成し、それを認証済のまたは認証していないデバイスに送信してインストールする。
【０１４６】
本発明は、安全性のあるモバイルデバイス用分散アプリケーションを実行できるデバイスの任意の集合から形成される、トランスペアレントなセキュリティ環境を提供する。
【０１４７】
本発明は、さまざまなモバイルデバイスを使用する「一般販売委員」、およびユーザに厳密な認証を求めるモバイルデバイスなどのモバイルビジネスと、アイデンティティ認証、キーネゴシエーション、信頼関係の確立などの法人ビジネスへ適用するには特に都合がよい。
【０１４８】
上記の実施形態はすべて本発明の核となる発明の核となる概念に関するものであって、各実施形態のいずれか１つに関連して記載されたあらゆる特徴または詳細が他の実施形態に適用しうることは当業者に明らかである。
【図面の簡単な説明】
【０１４９】
【図１】モバイル用の分散アプリケーションの一例を示す図である。
【図２】第１の先行技術におけるネットワーク認証処理を示す図である。
【図３】第２の先行技術におけるネットワーク認証処理を示す図である。
【図４】第３の先行技術におけるネットワーク認証処理を示す図である。
【図５】本発明の第一実施形態に係る、クライアントデバイスとリソース間で安全なネットワーク通信を確立する方法を示す。
【図６】本発明の第二実施形態に係る、クライアントデバイスとリソース間で安全なネットワーク通信を確立する方法を示す。
【図７】本発明の第三実施形態に係る、クライアントデバイスとリソース間で安全なネットワーク通信を確立する方法を示す。
【図８】本発明の第四実施形態に係る、クライアントデバイスとリソース間で安全なネットワーク通信を確立する方法を示す。
【図９】本発明の第五実施形態に係る、クライアントデバイスとリソース間で安全なネットワーク通信を確立する方法を示す。
【図１０】本発明の一実施形態に係る、リソースをさらに詳細に示す図である。
【図１１】本発明の一実施形態に係る、セキュリティマネージャをさらに詳細に示す図である。
【図１２】本発明の一実施形態に係る、クライアントデバイスをさらに詳細に示す図である。
【図１３】本発明の第６実施形態に係る、クライアントデバイスとリソース間で安全なネットワーク通信を確立する方法を示す。
【図１４】図１３に示す実施形態をさらに改良した、クライアントデバイスとリソース間で安全なネットワーク通信を確立する方法を示す。
【特許請求の範囲】
【請求項１】
セキュリティマネージャとクライアントの間で信頼関係を構築するステップと、
前記セキュリティマネージャで第１の識別子（１２４）を生成するとともに、前記識別子を前記セキュリティマネージャから前記クライアントへ送信するステップと、
前記第１の識別子（１２４）を前記クライアントから前記リソースへ送信するステップと、
前記リソースで前記第１識別子（１２４）の存在を確立するステップと、
前記リソースから前記クライアントへ第１暗号化データ（１３１）を送信するステップと、
前記第１暗号化データ（１３１）を使って、前記クライアントと前記リソース間の.更なるネットワーク通信（１２）を実行するステップを含む、クライアントとリソース間の安全なネットワーク通信を確立する方法。
【請求項２】
前記セキュリティマネージャと前記クライアント間で信頼関係を構築するステップは、
前記クライアントに関連する第２識別子（１２３）を前記クライアントから前記セキュリティマネージャへ送信するステップと、
前記セキュリティマネージャで前記第２識別子（１２３）の存在を確立するステップを含む、請求項１に記載の方法。
【請求項３】
前記第１識別子を生成するに先立って、前記リソースと前記セキュリティマネージャ間の信頼関係を構築する、請求項１および２の少なくともいずれか１の項に記載の方法。
【請求項４】
前記リソースと前記セキュリティマネージャ間の信頼関係を構築するステップは、
セキュリティマネージャに関する第３識別子（１２２）を前記セキュリティマネージャから前記リソースへ送信するステップと、
前記リソースで前記第３識別子（１２２）の存在を確立するステップを含む、請求項１乃至３の少なくともいずれか１の項に記載の方法。
【請求項５】
前記リソースと前記セキュリティマネージャ間の信頼関係を構築するステップは、
前記リソースに関連する第２暗号化データ（１３２）を前記リソースから前記セキュリティマネージャへ送信するステップと、
前記第２暗号化データ（１３２）を使って、前記リソースと前記セキュリティマネージャ間の更なるネットワーク通信（１１）を行うステップを含む、請求項４に記載の方法。
【請求項６】
前記リソースと前記セキュリティマネージャ間の信頼関係を構築するステップは、
リソースに関する第４識別子（１２１）を前記リソースから前記セキュリティマネージャへ送信するステップと、
前記セキュリティマネージャで前記第４識別子（１２１）の存在を確立するステップを含む、請求項４または５に記載の方法。
【請求項７】
前記リソースと前記セキュリティマネージャ間の信頼関係を構築するステップと、
前記セキュリティマネージャと前記クライアント間の信頼関係を構築するステップと、
前記クライアントと前記リソースの信頼関係を構築するステップとを含むステップの少なくとも１のステップが繰り返される請求項１乃至６の少なくともいずれか１の項に記載の方法。
【請求項８】
前記少なくとも１のステップの繰り返しは、定められた間隔または任意の間隔で行われる請求項７に記載の方法。
【請求項９】
前記リソースと前記セキュリティマネージャ間の信頼関係を構築するステップは、
前記セキュリティマネージャと、信頼されていないクライアントの間でチャネルを確立するステップと、
前記信頼されていないクライアントの側でユーザ認証情報の入力をリクエストするステップと、
前記ユーザ認証情報を前記セキュリティマネージャで認証するステップを含む、請求項１乃至８の少なくともいずれか１の項に記載の方法。
【請求項１０】
前記チャネルはセキュアチャネルである請求項９に記載の方法。
【請求項１１】
前記セキュアチャネルは、インターネット鍵交換プロトコル、ディフィーへルマン鍵交換、ブルートゥースデバイス接続のいずれかを使って確立される請求項１０に記載の方法。
【請求項１２】
前記ユーザ認証情報は、使い捨てパスワード、個人識別番号、コードまたは文字列である。
【請求項１３】
第１クライアントメディエータおよび第２クライアントメディエータが設けられたクライアントと、
第１リソースメディエータおよび第２リソースメディエータが設けられたリソースと、
第１識別子を生成し、それを第２クライアントメディエータへ送信するセキュリティマネージャとを含み、
前記第２クライアントメディエータと前記第２リソースメディエータは、前記クライアントと前記リソースとの間で信頼関係を構築するように構成され、
前記第２クライアントメディエータへの適合は、前記第２クライアントメディエータが、
前記セキュリティマネージャから前記第１識別子（１２４）を受信し、
前記第１識別子（１２４）を前記リソースに送信して認証し、
前記リソースから第１暗号化データ（１３１）を受信し、
前記第１暗号化データ（１３１）を使って、前記リソースとの安全なネットワーク通信（１２）を行うように構成され、
前記第２リソースメディエータへの適合は、前記第２リソースメディエータが、
前記第１識別子の存在を確立し、
前記第１暗号化データ（１３１）を前記クライアントへ送信し、
前記第１暗号化データ（１３１）を使って、前記クライアントとさらなるネットワーク通信（１２）を行うように構成された
クライアントとリソース間の安全なネットワーク通信を行うための通信ネットワーク。
【請求項１４】
前記第１リソースメディエータと前記セキュリティマネージャは、前記リソースと前記セキュリティマネージャ間の信頼関係を構築するように構成された請求項１３に記載の通信ネットワーク。
【請求項１５】
前記第１リソースメディエータと前記セキュリティマネージャは、前記第１識別子の生成に先立ち、前記リソースと前記セキュリティマネージャ間の信頼関係を構築するように構成された請求項１３に記載の通信ネットワーク。
【請求項１６】
前記セキュリティマネージャは、該セキュリティマネージャに関する第３識別子（１２２）を前記リソースへ送信するように構成され、
前記第１リソースメディエータは、前記リソースで前記第３識別子（１２２）の存在を確立するように構成された請求項１４または１５に記載の通信ネットワーク。
【請求項１７】
前記第１リソースメディエータは、前記リソースに関連する第２暗号化データ（１３２）を前記リソースから前記セキュリティマネージャへ送信するように構成され、
前記第２暗号化データ（１３２）を使って、前記セキュリティマネージャと更なるネットワーク通信（１１）を行う請求項１６に記載の通信ネットワーク。
【請求項１８】
前記リソースと前記セキュリティマネージャ間の信頼関係を構築するステップは、
前記リソースが、当該リソースに関する第４識別子１２１を前記セキュリティマネージャへ送信し、
前記セキュリティマネージャが、前記第４識別子１２１の存在を確立するステップを含む請求項１７に記載の通信ネットワーク。
【請求項１９】
前記第１クライアントメディエータおよび前記セキュリティマネージャは、前記クライアントと前記セキュリティマネージャ間で信頼関係を構築するように構成された請求項１３乃至１８のいずれか１の項に記載の通信ネットワーク。
【請求項２０】
前記第１クライアントメディエータは、前記クライアントに関連する第２識別子（１２３）を前記セキュリティマネージャへ送信するように構成され、
前記セキュリティマネージャは、前記第２識別子（１２３）の存在を確立するように構成された請求項１９に記載の通信ネットワーク。
【請求項２１】
前記リソースと前記セキュリティマネージャ間の信頼関係を構築するステップと、
前記セキュリティマネージャと前記クライアント間の信頼関係を構築するステップと、
前記クライアントと前記リソースの信頼関係を構築するステップとを含むステップの少なくとも１のステップが繰り返される請求項１３乃至１９のいずれか１の項に記載の通信ネットワーク。
【請求項２２】
前記少なくとも１のステップの繰り返しは、定められた間隔または任意の間隔で行われる請求項２１に記載の通信ネットワーク。
【請求項２３】
前記セキュリティマネージャは、信頼されていないクライアントとチャネルを確立し、当該信頼されていないクライアントからユーザ認証情報の入力を受け付けて、当該ユーザ情報を認証するように構成された請求項１３乃至２２のいずれか１の項に記載の通信ネットワーク。
【請求項２４】
前記チャネルはセキュアチャネルである請求項２３に記載の通信ネットワーク。
【請求項２５】
第１識別子（１２４）を生成し、クライアントに組み込まれた解読用の第２クライアントメディエータに前記第１命令（１２４）を送信するように構成されたセキュリティマネージャであって、
前記第１識別子（１２４）は、第２クライアントメディエータに前記第１識別子を第２リソースメディエータへの再送信を行わせるように構成され、
前記第１識別子１２４はさらに、前記第２リソースメディエータに、
有効化処理（９）を行って前記第１識別子を有効化させ、
第１暗号化データ（１３１）を第２クライアントメディエータへ送信させ、
前記第１暗号化データ（１３１）を使ってリソースとの次のステップの通信（１２）を実行させるように構成された、
ネットワーク内で安全な通信を確立するためのセキュリティマネージャ。
【請求項２６】
前記リソースに組み込まれた第１リソースメディエータとの相互作用によって、前記リソースとの信頼関係を構築するように構成された請求項２５に記載のセキュリティマネージャ。
【請求項２７】
前記第１識別子の生成に先立って前記信頼関係を構築するように構成された請求項２５または２６に記載のセキュリティマネージャ。
【請求項２８】
前記第１リソースメディエータが前記リソースで前記第３識別子の存在を確立するように、セキュリティマネージャに関する第３識別子（１２２）を前記リソースへ送信するように構成された請求項２５乃至２７のいずれかの項に記載のセキュリティマネージャ。
【請求項２９】
前記リソースに関連する第２暗号化データ（１３２）を前記リソースから受信し、
前記第２暗号化データ（１３２）を使って、前記リソースと前記更なるネットワーク通信（１１）を行うように構成された請求項２８に記載のセキュリティマネージャ。
【請求項３０】
前記第１リソースメディエータが前記リソースで前記第４識別子の存在を確立するように、セキュリティマネージャに関する第４識別子（１２１）を前記リソースへ送信するように構成された請求項２９に記載のセキュリティマネージャ。
【請求項３１】
前記クライアントに組み込まれた第１クライアントメディエータとの相互作用によって、クライアントと前記セキュリティマネージャ間で信頼関係を構築するように構成された請求項２９または３０に記載のセキュリティマネージャ。
【請求項３２】
前記クライアントに関連する第２識別子（１２３）を前記クライアントから受信し、前記第２識別子（１２３）の存在を確立するように構成された請求項２９または３０に記載のセキュリティマネージャ。
【請求項３３】
前記セキュリティマネージャは、信頼されていないクライアントとチャネルを確立し、当該信頼されていないクライアントからユーザ認証情報の入力を受け付けて、当該ユーザ情報を認証するように構成された請求項３１または３２に記載のセキュリティマネージャ。
【請求項３４】
前記チャネルはセキュアチャネルである請求項３３に記載のセキュリティマネージャ。
【請求項３５】
クライアントは、リソースと安全な通信を開始して、第１クライアントメディエータの動作によって、セキュリティマネージャと信頼関係を構築するように構成され、第２クライアントメディエータと、リソースに組み込まれた第２リソースメディエータは、各々、クライアントとリソース間で信頼関係を構築するように構成され、
前記第２クライアントメディエータへの適合は、前記第２クライアントメディエータが、
セキュリティマネージャによって生成された第１識別子（１２４）を前記セキュリティマネージャから受信し、
前記リソースから第１暗号化データ（１３１）を受信し、
前記第１暗号化データ（１３１）を使って、前記リソースとの安全なネットワーク通信（１２）を行うように構成され、
前記第２リソースメディエータへの適合は、前記第２リソースメディエータが、
前記第１識別子（１２４）の存在を確立し、
前記第１暗号化データ（１３１）を前記クライアントへ送信し、
前記第１暗号化データを使って、前記クライアントとさらなるネットワーク通信（１２）を行うように構成された第１クライアントメディエータと第２クライアントメディエータを備えるクライアント。
【請求項３６】
前記第１クライアントメディエータは、認証のために、前記クライアントに関連する第２識別子（１２３）を前記セキュリティマネージャへ送信するように構成された請求項３５に記載のクライアント。
【請求項３７】
ユーザからユーザ認証情報の入力を受け付けるように構成され、
前記第１クライアントメディエータは、前記セキュリティマネージャとチャネルを確立して、前記チャネルを介して前記認証情報を前記セキュリティマネージャへ送信するように構成された請求項３５または３６に記載のクライアント。
【請求項３８】
前記チャネルはセキュアチャネルである請求項３７に記載のクライアント。
【請求項３９】
第１クライアントメディエータの動作によって、セキュリティマネージャと信頼関係を構築するように構成されたリソースであって、第２リソースメディエータは、
前記セキュリティマネージャによって生成され、クライアントに送信された後に前記リソースに送信された前記第１識別子（１２４）の存在を確立し、
前記第１暗号化データ（１３１）を前記クライアントへ送信し、
前記第１暗号化データを使って、前記クライアントとさらなるネットワーク通信（１２）を行うように構成された、ネットワークでの安全な通信を開始するように構成されたリソース。
【請求項４０】
前記第１クライアントメディエータは、前記第１識別子の生成に先立って、前記リソースと前記セキュリティマネージャ間の信頼関係を構築するように構成された請求項３９に記載のリソース。
【請求項４１】
前記第１リソースメディエータは、前記セキュリティマネージャから送信された、セキュリティマネージャに関する第３識別子（１２２）を確立するステップを含む、請求項３９または４０に記載のリソース。
【請求項４２】
前記第１リソースメディエータは、
前記リソースに関連した第２暗号化データ（１３２）を、前記リソースから前記セキュリティマネージャに送信し、
前記第２暗号化データ（１３２）を使って、前記セキュリティマネージャとさらなるネットワーク通信（１１）を行うように構成された請求項３９乃至４１のいずれか１の項に記載のリソース。
【請求項４３】
前記第１リソースメディエータが、リソースに関する第４識別子（１２１）の存在を前記セキュリティマネージャで確立するように、前記第４識別子を前記セキュリティマネージャへ送信するように構成された請求項３９乃至４２のいずれか１の項に記載のリソース。
【特許請求の範囲】
【請求項１】
クライアントとリソースとの間に安全なネットワーク通信を確立する方法であって、
スマートカードと前記クライアントとの間で信頼関係を確立するステップであって、前記クライアントに関するクライアント証明書（１２３）を前記クライアントから前記スマートカードへ送信するステップと、その有効性を前記スマートカードにおいて確立するステップとを含むステップと、
前記スマートカードにおいてカード証明書（１２４）を生成し、前記信頼関係を確立した後に、前記スマートカードから前記クライアントへ前記カード証明書を送信するステップと、
前記クライアントから前記リソースへ前記カード証明書（１２４）を送信するステップと、
前記リソースにおいて、前記カード証明書（１２４）の有効性を確立するステップと、
前記リソースから前記クライアントへセッションキー（１３１）を送信するステップと、
前記セッションキー（１３１）を使用して、前記クライアントと前記リソースとの間におけるその後のネットワーク通信（１２）を実行するステップと
を備える方法。
【請求項２】
前記カード証明書の生成に先立って、前記リソースと前記スマートカードとの間の信頼関係を確立するステップをさらに備える請求項１に記載の方法。
【請求項３】
前記リソースと前記スマートカードとの間の信頼関係を確立する前記ステップは、
前記スマートカードに関する識別子（１２２）を前記スマートカードから前記リソースへ送信するステップと、
前記リソースにおいて、前記識別子（１２２）の有効性を確立するステップと
をさらに備える請求項２に記載の方法。
【請求項４】
前記リソースと前記スマートカードとの間の信頼関係を確立する前記ステップは、
前記リソースに関する暗号化データ（１３２）を前記リソースから前記スマートカードへ送信するステップと、
前記暗号化データ（１３２）を使用して、前記リソースと前記スマートカードとの間におけるその後のネットワーク通信（１１）を実行するステップと
をさらに備える請求項３に記載の方法。
【請求項５】
前記リソースと前記スマートカードとの間の信頼関係を確立するステップは、
前記リソースに関する識別子（１２１）を前記リソースから前記スマートカードへ送信するステップと、
前記スマートカードにおいて、前記識別子（１２１）の有効性を確立するステップと
をさらに備える請求項３または４に記載の方法。
【請求項６】
前記リソースと前記スマートカードとの間の信頼関係を確立する前記ステップと、
前記スマートカードと前記クライアントとの間の信頼関係を確立する前記ステップと、
前記クライアントと前記リソースとの間の信頼関係を確立する前記ステップ
のうち、少なくとも１のステップが繰り返される請求項１乃至５の少なくともいずれかに記載の方法。
【請求項７】
前記少なくとも１のステップの繰り返しは、予め定められた時間間隔もしくは任意の時間間隔で実行される請求項６に記載の方法。
【請求項８】
前記スマートカードと前記クライアントとの間にセキュアチャネルを確立するステップをさらに備える請求項１乃至７の少なくともいずれかに記載の方法。
【請求項９】
前記セキュアチャネルは、インターネット鍵交換プロトコル、ディフィーへルマン、およびデバイスペアリングもしくはその他のブルートゥース、ののいずれか１を使用して確立される請求項８に記載の方法。
【請求項１０】
前記クライアント証明書は、使い捨てパスワード、ＰＩＮ、コードまたはフレーズのいずれか１である請求項９に記載の方法。
【請求項１１】
クライアントとリソースとの間で安全なネットワーク通信を行うための通信ネットワークであって、
第１クライアントメディエータおよび第２クライアントメディエータが設けられたクライアントと、
第１リソースメディエータおよび第２リソースメディエータが設けられたリソースと、
スマートカードとクライアントとの間で信頼関係を確立するスマートカードであって、前記クライアントに関するクライアント証明書（１２３）を前記クライアントから受信して、その有効性を確立するスマートカードとを備え、
前記スマートカードは、カード証明書を生成し、それを前記信頼関係の確立後に、前記第２クライアントメディエータへ送信するように構成され、
前記第２クライアントメディエータと前記第２リソースメディエータは、前記クライアントと前記リソースとの間で信頼関係を確立するように構成され、
前記第２クライアントメディエータの構成は、前記第２クライアントメディエータが、
前記スマートカードから前記カード証明書（１２４）を受信し、
前記カード証明書（１２４）を有効化のために前記リソースに送信し、
前記リソースからセッションキー（１３１）を受信し、
前記セッションキー（１３１）を使用して、前記リソースとの間で安全なネットワーク通信（１２）を行う構成であり、
前記第２リソースメディエータの構成は、前記第２リソースメディエータが、
前記カード証明書の有効性を確立し、
前記セッションキーを前記クライアントへ送信し、
前記セッションキー（１３１）を使用して、前記クライアントとの間で、その後のネットワーク通信（１２）を行う構成である通信ネットワーク。
【請求項１２】
前記第１リソースメディエータと前記スマートカードは、前記リソースと前記スマートカードとの間で信頼関係を確立するように構成された請求項１１に記載の通信ネットワーク。
【請求項１３】
前記第１リソースメディエータと前記スマートカードは、前記カード証明書の生成に先立ち、前記リソースと前記スマートカードとの間で信頼関係を確立するように構成された請求項１２に記載の通信ネットワーク。
【請求項１４】
前記スマートカードは、前記スマートカードに関する識別子（１２２）を前記リソースへ送信するように構成され、
前記第１リソースメディエータは、前記リソースにおいて、前記識別子（１２２）の有効性を確立するように構成された
請求項１２または１３に記載の通信ネットワーク。
【請求項１５】
前記第１リソースメディエータは、前記リソースに関する第２暗号化データ（１３２）を前記リソースから前記スマートカードへ送信し、
前記第２暗号化データ（１３２）を使用して、前記スマートカードとの間でその後のネットワーク通信（１１）を実行するように構成された
請求項１４に記載の通信ネットワーク。
【請求項１６】
前記リソースと前記スマートカードとの間で信頼関係を確立する前記ステップは、
前記リソースが、前記リソースに関する識別子（１２１）を前記スマートカードへ送信するステップと、
前記スマートカードが、前記識別子（１２１）の有効性を確立するステップと
をさらに備える請求項１５に記載の通信ネットワーク。
【請求項１７】
前記リソースと前記スマートカードとの間に信頼関係を確立するステップと、
前記スマートカードと前記クライアントとの間に信頼関係を確立するステップと、
前記クライアントと前記リソースとの間に信頼関係を確立するステップ
のうち、少なくとも１のステップが繰り返される
請求項１１乃至１６のいずれかに記載の通信ネットワーク。
【請求項１８】
前記少なくとも１のステップの繰り返しは、予め定められた時間間隔または任意の時間間隔で行われる請求項１７に記載の通信ネットワーク。
【請求項１９】
前記スマートカードは、前記クライアントとの間にセキュアチャンネルを確立するように構成された請求項１１乃至１８のいずれかに記載の通信ネットワーク。
【請求項２０】
ネットワーク内で安全な通信を確立するスマートカードであって、
スマートカードとクライアントとの間に信頼関係を確立し、当該確立において、前記クライアントに関するクライアント証明書（１２３）を前記クライアントから受信し、その有効性を確立し、
カード証明書（１２４）を生成し、前記信頼関係の確立後に前記カード証明書（１２４）を、前記クライアントに組み込まれた解読用の第２クライアントメディエータに送信する
ように構成され、
前記カード証明書（１２４）の生成が、前記第２クライアントメディエータによる、前記カード証明書の第２リソースメディエータへの再送信を促し、
前記カード証明書１２４の生成はさらに、前記第２リソースメディエータに、
有効化処理（９）を行って前記カード証明書を有効化し、
セッションキー（１３１）を第２クライアントメディエータへ送信し、
前記セッションキー（１３１）を使用して前記クライアントとの間でその後のネットワーク通信（１２）を実行するように促すスマートカード。
【請求項２１】
前記リソースに組み込まれた第１リソースメディエータとの相互通信によって、前記リソースとの間に信頼関係を確立するように構成された請求項２０に記載のスマートカード。
【請求項２２】
前記カード証明書の生成に先立ち、前記リソースとの間に前記信頼関係を確立するように構成された請求項２０または２１に記載のスマートカード。
【請求項２３】
前記リソースへ前記スマートカードに関する識別子（１２２）を送信し、その有効性を前記第１リソースメディエータが確立するように構成された請求項２０乃至２２のいずれかに記載のスマートカード。
【請求項２４】
前記リソースに関する第２暗号化データ（１３２）を前記リソースから受信し、
前記第２暗号化データ（１３２）を使用して、前記リソースとの間でその後のネットワーク通信（１１）を行うように構成された請求項２３に記載のスマートカード。
【請求項２５】
前記リソースへ前記スマートカードに関する識別子（１２１）を送信し、その有効性を前記第１リソースメディエータが確立するように構成された請求項２４に記載のスマートカード。
【請求項２６】
前記スマートカードは、前記クライアントとの間にセキュアチャネルを確立するように構成された請求項２０または２５に記載のスマートカード。
【請求項２７】
第１クライアントメディエータと第２クライアントメディエータを備えるクライアントであって、
前記クライアントは、リソースとの間で安全な通信を開始するように構成され、前記クライアントは、前記第１クライアントメディエータの動作によって、スマートカードとの間に信頼関係を確立するように構成され、前記第２クライアントメディエータと、リソースに組み込まれた第２リソースメディエータは、前記クライアントと前記リソースとの間の信頼関係を確立するように構成され、
前記第２クライアントメディエータの構成は、前記第２クライアントメディエータが、
前記スマートカードとクライアントとの間で、前記クライアントから前記クライアントに関するクライアント証明書（１２３）を送信して、その有効性を前記スマートカードにおいて確立することにより、信頼関係を確立し、
前記信頼関係の確立後、スマートカードによって生成されたカード証明書（１２４）を前記スマートカードから受信し、
前記リソースからセッションキー（１３１）を受信し、前記セッションキー（１３１）を使用して、前記リソースとの間でその後のネットワーク通信（１２）を行う構成であり、
前記第２リソースメディエータの構成は、前記第２リソースメディエータが、
前記カード証明書（１２４）の有効性を確立し、
前記セッションキー（１３１）を前記クライアントへ送信し、
前記セッションキー（１３１）を使用して、前記クライアントとの間でその後のネットワーク通信（１２）を行う構成であるクライアント。
【請求項２８】
前記第１クライアントメディエータは、前記スマートカードとの間にセキュアチャネルを確立するように構成された請求項２７に記載のクライアント。
【請求項２９】
ネットワークでの安全な通信を開始するように構成されたリソースであって、
前記第１リソースメディエータの動作によって、前記スマートカードとクライアントとの間の信頼関係を示すカード証明書を受信することにより、前記クライアントとの間に信頼関係を確立するように構成され、
前記第２リソースメディエータは、
前記スマートカードによって生成され、ク前記ライアントに送信され、前記リソースに転送されたカード証明書（１２４）の有効性を確立し、
セッションキー（１３１）を前記リソースの前記クライアントへ送信し、
前記セッションキーを使用して、前記クライアントとの間でその後のネットワーク通信（１２）を行うように構成されたリソース。
【請求項３０】
前記第１リソースメディエータは、前記カード証明書の生成に先立って、前記リソースと前記スマートカードとの間に信頼関係を確立するように構成された請求項２９に記載のリソース。
【請求項３１】
前記第１リソースメディエータは、前記スマートカードから送信された、前記スマートカードに関する識別子（１２２）の有効性を確立するように構成された請求項２９または３０に記載のリソース。
【請求項３２】
前記第１リソースメディエータは、
前記リソースに関する第２暗号化データ（１３２）を、前記リソースから前記スマートカードに送信し、
前記第２暗号化データ（１３２）を使用して、前記スマートカードとの間でその後のネットワーク通信（１１）を行う
ように構成された請求項２９乃至３１のいずれかに記載のリソース。
【請求項３３】
前記第１リソースメディエータが、前記スマートカードに、前記スマートカードに関する識別子（１２１）を送信し、その有効性を前記スマートカードが確立するように構成された請求項２９乃至３２のいずれかに記載のリソース。
【請求項１】
セキュリティマネージャとクライアントの間で信頼関係を構築するステップと、
前記セキュリティマネージャで第１の識別子（１２４）を生成するとともに、前記識別子を前記セキュリティマネージャから前記クライアントへ送信するステップと、
前記第１の識別子（１２４）を前記クライアントから前記リソースへ送信するステップと、
前記リソースで前記第１識別子（１２４）の存在を確立するステップと、
前記リソースから前記クライアントへ第１暗号化データ（１３１）を送信するステップと、
前記第１暗号化データ（１３１）を使って、前記クライアントと前記リソース間の.更なるネットワーク通信（１２）を実行するステップを含む、クライアントとリソース間の安全なネットワーク通信を確立する方法。
【請求項２】
前記セキュリティマネージャと前記クライアント間で信頼関係を構築するステップは、
前記クライアントに関連する第２識別子（１２３）を前記クライアントから前記セキュリティマネージャへ送信するステップと、
前記セキュリティマネージャで前記第２識別子（１２３）の存在を確立するステップを含む、請求項１に記載の方法。
【請求項３】
前記第１識別子を生成するに先立って、前記リソースと前記セキュリティマネージャ間の信頼関係を構築する、請求項１および２の少なくともいずれか１の項に記載の方法。
【請求項４】
前記リソースと前記セキュリティマネージャ間の信頼関係を構築するステップは、
セキュリティマネージャに関する第３識別子（１２２）を前記セキュリティマネージャから前記リソースへ送信するステップと、
前記リソースで前記第３識別子（１２２）の存在を確立するステップを含む、請求項１乃至３の少なくともいずれか１の項に記載の方法。
【請求項５】
前記リソースと前記セキュリティマネージャ間の信頼関係を構築するステップは、
前記リソースに関連する第２暗号化データ（１３２）を前記リソースから前記セキュリティマネージャへ送信するステップと、
前記第２暗号化データ（１３２）を使って、前記リソースと前記セキュリティマネージャ間の更なるネットワーク通信（１１）を行うステップを含む、請求項４に記載の方法。
【請求項６】
前記リソースと前記セキュリティマネージャ間の信頼関係を構築するステップは、
リソースに関する第４識別子（１２１）を前記リソースから前記セキュリティマネージャへ送信するステップと、
前記セキュリティマネージャで前記第４識別子（１２１）の存在を確立するステップを含む、請求項４または５に記載の方法。
【請求項７】
前記リソースと前記セキュリティマネージャ間の信頼関係を構築するステップと、
前記セキュリティマネージャと前記クライアント間の信頼関係を構築するステップと、
前記クライアントと前記リソースの信頼関係を構築するステップとを含むステップの少なくとも１のステップが繰り返される請求項１乃至６の少なくともいずれか１の項に記載の方法。
【請求項８】
前記少なくとも１のステップの繰り返しは、定められた間隔または任意の間隔で行われる請求項７に記載の方法。
【請求項９】
前記リソースと前記セキュリティマネージャ間の信頼関係を構築するステップは、
前記セキュリティマネージャと、信頼されていないクライアントの間でチャネルを確立するステップと、
前記信頼されていないクライアントの側でユーザ認証情報の入力をリクエストするステップと、
前記ユーザ認証情報を前記セキュリティマネージャで認証するステップを含む、請求項１乃至８の少なくともいずれか１の項に記載の方法。
【請求項１０】
前記チャネルはセキュアチャネルである請求項９に記載の方法。
【請求項１１】
前記セキュアチャネルは、インターネット鍵交換プロトコル、ディフィーへルマン鍵交換、ブルートゥースデバイス接続のいずれかを使って確立される請求項１０に記載の方法。
【請求項１２】
前記ユーザ認証情報は、使い捨てパスワード、個人識別番号、コードまたは文字列である。
【請求項１３】
第１クライアントメディエータおよび第２クライアントメディエータが設けられたクライアントと、
第１リソースメディエータおよび第２リソースメディエータが設けられたリソースと、
第１識別子を生成し、それを第２クライアントメディエータへ送信するセキュリティマネージャとを含み、
前記第２クライアントメディエータと前記第２リソースメディエータは、前記クライアントと前記リソースとの間で信頼関係を構築するように構成され、
前記第２クライアントメディエータへの適合は、前記第２クライアントメディエータが、
前記セキュリティマネージャから前記第１識別子（１２４）を受信し、
前記第１識別子（１２４）を前記リソースに送信して認証し、
前記リソースから第１暗号化データ（１３１）を受信し、
前記第１暗号化データ（１３１）を使って、前記リソースとの安全なネットワーク通信（１２）を行うように構成され、
前記第２リソースメディエータへの適合は、前記第２リソースメディエータが、
前記第１識別子の存在を確立し、
前記第１暗号化データ（１３１）を前記クライアントへ送信し、
前記第１暗号化データ（１３１）を使って、前記クライアントとさらなるネットワーク通信（１２）を行うように構成された
クライアントとリソース間の安全なネットワーク通信を行うための通信ネットワーク。
【請求項１４】
前記第１リソースメディエータと前記セキュリティマネージャは、前記リソースと前記セキュリティマネージャ間の信頼関係を構築するように構成された請求項１３に記載の通信ネットワーク。
【請求項１５】
前記第１リソースメディエータと前記セキュリティマネージャは、前記第１識別子の生成に先立ち、前記リソースと前記セキュリティマネージャ間の信頼関係を構築するように構成された請求項１３に記載の通信ネットワーク。
【請求項１６】
前記セキュリティマネージャは、該セキュリティマネージャに関する第３識別子（１２２）を前記リソースへ送信するように構成され、
前記第１リソースメディエータは、前記リソースで前記第３識別子（１２２）の存在を確立するように構成された請求項１４または１５に記載の通信ネットワーク。
【請求項１７】
前記第１リソースメディエータは、前記リソースに関連する第２暗号化データ（１３２）を前記リソースから前記セキュリティマネージャへ送信するように構成され、
前記第２暗号化データ（１３２）を使って、前記セキュリティマネージャと更なるネットワーク通信（１１）を行う請求項１６に記載の通信ネットワーク。
【請求項１８】
前記リソースと前記セキュリティマネージャ間の信頼関係を構築するステップは、
前記リソースが、当該リソースに関する第４識別子１２１を前記セキュリティマネージャへ送信し、
前記セキュリティマネージャが、前記第４識別子１２１の存在を確立するステップを含む請求項１７に記載の通信ネットワーク。
【請求項１９】
前記第１クライアントメディエータおよび前記セキュリティマネージャは、前記クライアントと前記セキュリティマネージャ間で信頼関係を構築するように構成された請求項１３乃至１８のいずれか１の項に記載の通信ネットワーク。
【請求項２０】
前記第１クライアントメディエータは、前記クライアントに関連する第２識別子（１２３）を前記セキュリティマネージャへ送信するように構成され、
前記セキュリティマネージャは、前記第２識別子（１２３）の存在を確立するように構成された請求項１９に記載の通信ネットワーク。
【請求項２１】
前記リソースと前記セキュリティマネージャ間の信頼関係を構築するステップと、
前記セキュリティマネージャと前記クライアント間の信頼関係を構築するステップと、
前記クライアントと前記リソースの信頼関係を構築するステップとを含むステップの少なくとも１のステップが繰り返される請求項１３乃至１９のいずれか１の項に記載の通信ネットワーク。
【請求項２２】
前記少なくとも１のステップの繰り返しは、定められた間隔または任意の間隔で行われる請求項２１に記載の通信ネットワーク。
【請求項２３】
前記セキュリティマネージャは、信頼されていないクライアントとチャネルを確立し、当該信頼されていないクライアントからユーザ認証情報の入力を受け付けて、当該ユーザ情報を認証するように構成された請求項１３乃至２２のいずれか１の項に記載の通信ネットワーク。
【請求項２４】
前記チャネルはセキュアチャネルである請求項２３に記載の通信ネットワーク。
【請求項２５】
第１識別子（１２４）を生成し、クライアントに組み込まれた解読用の第２クライアントメディエータに前記第１命令（１２４）を送信するように構成されたセキュリティマネージャであって、
前記第１識別子（１２４）は、第２クライアントメディエータに前記第１識別子を第２リソースメディエータへの再送信を行わせるように構成され、
前記第１識別子１２４はさらに、前記第２リソースメディエータに、
有効化処理（９）を行って前記第１識別子を有効化させ、
第１暗号化データ（１３１）を第２クライアントメディエータへ送信させ、
前記第１暗号化データ（１３１）を使ってリソースとの次のステップの通信（１２）を実行させるように構成された、
ネットワーク内で安全な通信を確立するためのセキュリティマネージャ。
【請求項２６】
前記リソースに組み込まれた第１リソースメディエータとの相互作用によって、前記リソースとの信頼関係を構築するように構成された請求項２５に記載のセキュリティマネージャ。
【請求項２７】
前記第１識別子の生成に先立って前記信頼関係を構築するように構成された請求項２５または２６に記載のセキュリティマネージャ。
【請求項２８】
前記第１リソースメディエータが前記リソースで前記第３識別子の存在を確立するように、セキュリティマネージャに関する第３識別子（１２２）を前記リソースへ送信するように構成された請求項２５乃至２７のいずれかの項に記載のセキュリティマネージャ。
【請求項２９】
前記リソースに関連する第２暗号化データ（１３２）を前記リソースから受信し、
前記第２暗号化データ（１３２）を使って、前記リソースと前記更なるネットワーク通信（１１）を行うように構成された請求項２８に記載のセキュリティマネージャ。
【請求項３０】
前記第１リソースメディエータが前記リソースで前記第４識別子の存在を確立するように、セキュリティマネージャに関する第４識別子（１２１）を前記リソースへ送信するように構成された請求項２９に記載のセキュリティマネージャ。
【請求項３１】
前記クライアントに組み込まれた第１クライアントメディエータとの相互作用によって、クライアントと前記セキュリティマネージャ間で信頼関係を構築するように構成された請求項２９または３０に記載のセキュリティマネージャ。
【請求項３２】
前記クライアントに関連する第２識別子（１２３）を前記クライアントから受信し、前記第２識別子（１２３）の存在を確立するように構成された請求項２９または３０に記載のセキュリティマネージャ。
【請求項３３】
前記セキュリティマネージャは、信頼されていないクライアントとチャネルを確立し、当該信頼されていないクライアントからユーザ認証情報の入力を受け付けて、当該ユーザ情報を認証するように構成された請求項３１または３２に記載のセキュリティマネージャ。
【請求項３４】
前記チャネルはセキュアチャネルである請求項３３に記載のセキュリティマネージャ。
【請求項３５】
クライアントは、リソースと安全な通信を開始して、第１クライアントメディエータの動作によって、セキュリティマネージャと信頼関係を構築するように構成され、第２クライアントメディエータと、リソースに組み込まれた第２リソースメディエータは、各々、クライアントとリソース間で信頼関係を構築するように構成され、
前記第２クライアントメディエータへの適合は、前記第２クライアントメディエータが、
セキュリティマネージャによって生成された第１識別子（１２４）を前記セキュリティマネージャから受信し、
前記リソースから第１暗号化データ（１３１）を受信し、
前記第１暗号化データ（１３１）を使って、前記リソースとの安全なネットワーク通信（１２）を行うように構成され、
前記第２リソースメディエータへの適合は、前記第２リソースメディエータが、
前記第１識別子（１２４）の存在を確立し、
前記第１暗号化データ（１３１）を前記クライアントへ送信し、
前記第１暗号化データを使って、前記クライアントとさらなるネットワーク通信（１２）を行うように構成された第１クライアントメディエータと第２クライアントメディエータを備えるクライアント。
【請求項３６】
前記第１クライアントメディエータは、認証のために、前記クライアントに関連する第２識別子（１２３）を前記セキュリティマネージャへ送信するように構成された請求項３５に記載のクライアント。
【請求項３７】
ユーザからユーザ認証情報の入力を受け付けるように構成され、
前記第１クライアントメディエータは、前記セキュリティマネージャとチャネルを確立して、前記チャネルを介して前記認証情報を前記セキュリティマネージャへ送信するように構成された請求項３５または３６に記載のクライアント。
【請求項３８】
前記チャネルはセキュアチャネルである請求項３７に記載のクライアント。
【請求項３９】
第１クライアントメディエータの動作によって、セキュリティマネージャと信頼関係を構築するように構成されたリソースであって、第２リソースメディエータは、
前記セキュリティマネージャによって生成され、クライアントに送信された後に前記リソースに送信された前記第１識別子（１２４）の存在を確立し、
前記第１暗号化データ（１３１）を前記クライアントへ送信し、
前記第１暗号化データを使って、前記クライアントとさらなるネットワーク通信（１２）を行うように構成された、ネットワークでの安全な通信を開始するように構成されたリソース。
【請求項４０】
前記第１クライアントメディエータは、前記第１識別子の生成に先立って、前記リソースと前記セキュリティマネージャ間の信頼関係を構築するように構成された請求項３９に記載のリソース。
【請求項４１】
前記第１リソースメディエータは、前記セキュリティマネージャから送信された、セキュリティマネージャに関する第３識別子（１２２）を確立するステップを含む、請求項３９または４０に記載のリソース。
【請求項４２】
前記第１リソースメディエータは、
前記リソースに関連した第２暗号化データ（１３２）を、前記リソースから前記セキュリティマネージャに送信し、
前記第２暗号化データ（１３２）を使って、前記セキュリティマネージャとさらなるネットワーク通信（１１）を行うように構成された請求項３９乃至４１のいずれか１の項に記載のリソース。
【請求項４３】
前記第１リソースメディエータが、リソースに関する第４識別子（１２１）の存在を前記セキュリティマネージャで確立するように、前記第４識別子を前記セキュリティマネージャへ送信するように構成された請求項３９乃至４２のいずれか１の項に記載のリソース。
【特許請求の範囲】
【請求項１】
クライアントとリソースとの間に安全なネットワーク通信を確立する方法であって、
スマートカードと前記クライアントとの間で信頼関係を確立するステップであって、前記クライアントに関するクライアント証明書（１２３）を前記クライアントから前記スマートカードへ送信するステップと、その有効性を前記スマートカードにおいて確立するステップとを含むステップと、
前記スマートカードにおいてカード証明書（１２４）を生成し、前記信頼関係を確立した後に、前記スマートカードから前記クライアントへ前記カード証明書を送信するステップと、
前記クライアントから前記リソースへ前記カード証明書（１２４）を送信するステップと、
前記リソースにおいて、前記カード証明書（１２４）の有効性を確立するステップと、
前記リソースから前記クライアントへセッションキー（１３１）を送信するステップと、
前記セッションキー（１３１）を使用して、前記クライアントと前記リソースとの間におけるその後のネットワーク通信（１２）を実行するステップと
を備える方法。
【請求項２】
前記カード証明書の生成に先立って、前記リソースと前記スマートカードとの間の信頼関係を確立するステップをさらに備える請求項１に記載の方法。
【請求項３】
前記リソースと前記スマートカードとの間の信頼関係を確立する前記ステップは、
前記スマートカードに関する識別子（１２２）を前記スマートカードから前記リソースへ送信するステップと、
前記リソースにおいて、前記識別子（１２２）の有効性を確立するステップと
をさらに備える請求項２に記載の方法。
【請求項４】
前記リソースと前記スマートカードとの間の信頼関係を確立する前記ステップは、
前記リソースに関する暗号化データ（１３２）を前記リソースから前記スマートカードへ送信するステップと、
前記暗号化データ（１３２）を使用して、前記リソースと前記スマートカードとの間におけるその後のネットワーク通信（１１）を実行するステップと
をさらに備える請求項３に記載の方法。
【請求項５】
前記リソースと前記スマートカードとの間の信頼関係を確立するステップは、
前記リソースに関する識別子（１２１）を前記リソースから前記スマートカードへ送信するステップと、
前記スマートカードにおいて、前記識別子（１２１）の有効性を確立するステップと
をさらに備える請求項３または４に記載の方法。
【請求項６】
前記リソースと前記スマートカードとの間の信頼関係を確立する前記ステップと、
前記スマートカードと前記クライアントとの間の信頼関係を確立する前記ステップと、
前記クライアントと前記リソースとの間の信頼関係を確立する前記ステップ
のうち、少なくとも１のステップが繰り返される請求項１乃至５の少なくともいずれかに記載の方法。
【請求項７】
前記少なくとも１のステップの繰り返しは、予め定められた時間間隔もしくは任意の時間間隔で実行される請求項６に記載の方法。
【請求項８】
前記スマートカードと前記クライアントとの間にセキュアチャネルを確立するステップをさらに備える請求項１乃至７の少なくともいずれかに記載の方法。
【請求項９】
前記セキュアチャネルは、インターネット鍵交換プロトコル、ディフィーへルマン、およびデバイスペアリングもしくはその他のブルートゥース、ののいずれか１を使用して確立される請求項８に記載の方法。
【請求項１０】
前記クライアント証明書は、使い捨てパスワード、ＰＩＮ、コードまたはフレーズのいずれか１である請求項９に記載の方法。
【請求項１１】
クライアントとリソースとの間で安全なネットワーク通信を行うための通信ネットワークであって、
第１クライアントメディエータおよび第２クライアントメディエータが設けられたクライアントと、
第１リソースメディエータおよび第２リソースメディエータが設けられたリソースと、
スマートカードとクライアントとの間で信頼関係を確立するスマートカードであって、前記クライアントに関するクライアント証明書（１２３）を前記クライアントから受信して、その有効性を確立するスマートカードとを備え、
前記スマートカードは、カード証明書を生成し、それを前記信頼関係の確立後に、前記第２クライアントメディエータへ送信するように構成され、
前記第２クライアントメディエータと前記第２リソースメディエータは、前記クライアントと前記リソースとの間で信頼関係を確立するように構成され、
前記第２クライアントメディエータの構成は、前記第２クライアントメディエータが、
前記スマートカードから前記カード証明書（１２４）を受信し、
前記カード証明書（１２４）を有効化のために前記リソースに送信し、
前記リソースからセッションキー（１３１）を受信し、
前記セッションキー（１３１）を使用して、前記リソースとの間で安全なネットワーク通信（１２）を行う構成であり、
前記第２リソースメディエータの構成は、前記第２リソースメディエータが、
前記カード証明書の有効性を確立し、
前記セッションキーを前記クライアントへ送信し、
前記セッションキー（１３１）を使用して、前記クライアントとの間で、その後のネットワーク通信（１２）を行う構成である通信ネットワーク。
【請求項１２】
前記第１リソースメディエータと前記スマートカードは、前記リソースと前記スマートカードとの間で信頼関係を確立するように構成された請求項１１に記載の通信ネットワーク。
【請求項１３】
前記第１リソースメディエータと前記スマートカードは、前記カード証明書の生成に先立ち、前記リソースと前記スマートカードとの間で信頼関係を確立するように構成された請求項１２に記載の通信ネットワーク。
【請求項１４】
前記スマートカードは、前記スマートカードに関する識別子（１２２）を前記リソースへ送信するように構成され、
前記第１リソースメディエータは、前記リソースにおいて、前記識別子（１２２）の有効性を確立するように構成された
請求項１２または１３に記載の通信ネットワーク。
【請求項１５】
前記第１リソースメディエータは、前記リソースに関する第２暗号化データ（１３２）を前記リソースから前記スマートカードへ送信し、
前記第２暗号化データ（１３２）を使用して、前記スマートカードとの間でその後のネットワーク通信（１１）を実行するように構成された
請求項１４に記載の通信ネットワーク。
【請求項１６】
前記リソースと前記スマートカードとの間で信頼関係を確立する前記ステップは、
前記リソースが、前記リソースに関する識別子（１２１）を前記スマートカードへ送信するステップと、
前記スマートカードが、前記識別子（１２１）の有効性を確立するステップと
をさらに備える請求項１５に記載の通信ネットワーク。
【請求項１７】
前記リソースと前記スマートカードとの間に信頼関係を確立するステップと、
前記スマートカードと前記クライアントとの間に信頼関係を確立するステップと、
前記クライアントと前記リソースとの間に信頼関係を確立するステップ
のうち、少なくとも１のステップが繰り返される
請求項１１乃至１６のいずれかに記載の通信ネットワーク。
【請求項１８】
前記少なくとも１のステップの繰り返しは、予め定められた時間間隔または任意の時間間隔で行われる請求項１７に記載の通信ネットワーク。
【請求項１９】
前記スマートカードは、前記クライアントとの間にセキュアチャンネルを確立するように構成された請求項１１乃至１８のいずれかに記載の通信ネットワーク。
【請求項２０】
ネットワーク内で安全な通信を確立するスマートカードであって、
スマートカードとクライアントとの間に信頼関係を確立し、当該確立において、前記クライアントに関するクライアント証明書（１２３）を前記クライアントから受信し、その有効性を確立し、
カード証明書（１２４）を生成し、前記信頼関係の確立後に前記カード証明書（１２４）を、前記クライアントに組み込まれた解読用の第２クライアントメディエータに送信する
ように構成され、
前記カード証明書（１２４）の生成が、前記第２クライアントメディエータによる、前記カード証明書の第２リソースメディエータへの再送信を促し、
前記カード証明書１２４の生成はさらに、前記第２リソースメディエータに、
有効化処理（９）を行って前記カード証明書を有効化し、
セッションキー（１３１）を第２クライアントメディエータへ送信し、
前記セッションキー（１３１）を使用して前記クライアントとの間でその後のネットワーク通信（１２）を実行するように促すスマートカード。
【請求項２１】
前記リソースに組み込まれた第１リソースメディエータとの相互通信によって、前記リソースとの間に信頼関係を確立するように構成された請求項２０に記載のスマートカード。
【請求項２２】
前記カード証明書の生成に先立ち、前記リソースとの間に前記信頼関係を確立するように構成された請求項２０または２１に記載のスマートカード。
【請求項２３】
前記リソースへ前記スマートカードに関する識別子（１２２）を送信し、その有効性を前記第１リソースメディエータが確立するように構成された請求項２０乃至２２のいずれかに記載のスマートカード。
【請求項２４】
前記リソースに関する第２暗号化データ（１３２）を前記リソースから受信し、
前記第２暗号化データ（１３２）を使用して、前記リソースとの間でその後のネットワーク通信（１１）を行うように構成された請求項２３に記載のスマートカード。
【請求項２５】
前記リソースへ前記スマートカードに関する識別子（１２１）を送信し、その有効性を前記第１リソースメディエータが確立するように構成された請求項２４に記載のスマートカード。
【請求項２６】
前記スマートカードは、前記クライアントとの間にセキュアチャネルを確立するように構成された請求項２０または２５に記載のスマートカード。
【請求項２７】
第１クライアントメディエータと第２クライアントメディエータを備えるクライアントであって、
前記クライアントは、リソースとの間で安全な通信を開始するように構成され、前記クライアントは、前記第１クライアントメディエータの動作によって、スマートカードとの間に信頼関係を確立するように構成され、前記第２クライアントメディエータと、リソースに組み込まれた第２リソースメディエータは、前記クライアントと前記リソースとの間の信頼関係を確立するように構成され、
前記第２クライアントメディエータの構成は、前記第２クライアントメディエータが、
前記スマートカードとクライアントとの間で、前記クライアントから前記クライアントに関するクライアント証明書（１２３）を送信して、その有効性を前記スマートカードにおいて確立することにより、信頼関係を確立し、
前記信頼関係の確立後、スマートカードによって生成されたカード証明書（１２４）を前記スマートカードから受信し、
前記リソースからセッションキー（１３１）を受信し、前記セッションキー（１３１）を使用して、前記リソースとの間でその後のネットワーク通信（１２）を行う構成であり、
前記第２リソースメディエータの構成は、前記第２リソースメディエータが、
前記カード証明書（１２４）の有効性を確立し、
前記セッションキー（１３１）を前記クライアントへ送信し、
前記セッションキー（１３１）を使用して、前記クライアントとの間でその後のネットワーク通信（１２）を行う構成であるクライアント。
【請求項２８】
前記第１クライアントメディエータは、前記スマートカードとの間にセキュアチャネルを確立するように構成された請求項２７に記載のクライアント。
【請求項２９】
ネットワークでの安全な通信を開始するように構成されたリソースであって、
前記第１リソースメディエータの動作によって、前記スマートカードとクライアントとの間の信頼関係を示すカード証明書を受信することにより、前記クライアントとの間に信頼関係を確立するように構成され、
前記第２リソースメディエータは、
前記スマートカードによって生成され、ク前記ライアントに送信され、前記リソースに転送されたカード証明書（１２４）の有効性を確立し、
セッションキー（１３１）を前記リソースの前記クライアントへ送信し、
前記セッションキーを使用して、前記クライアントとの間でその後のネットワーク通信（１２）を行うように構成されたリソース。
【請求項３０】
前記第１リソースメディエータは、前記カード証明書の生成に先立って、前記リソースと前記スマートカードとの間に信頼関係を確立するように構成された請求項２９に記載のリソース。
【請求項３１】
前記第１リソースメディエータは、前記スマートカードから送信された、前記スマートカードに関する識別子（１２２）の有効性を確立するように構成された請求項２９または３０に記載のリソース。
【請求項３２】
前記第１リソースメディエータは、
前記リソースに関する第２暗号化データ（１３２）を、前記リソースから前記スマートカードに送信し、
前記第２暗号化データ（１３２）を使用して、前記スマートカードとの間でその後のネットワーク通信（１１）を行う
ように構成された請求項２９乃至３１のいずれかに記載のリソース。
【請求項３３】
前記第１リソースメディエータが、前記スマートカードに、前記スマートカードに関する識別子（１２１）を送信し、その有効性を前記スマートカードが確立するように構成された請求項２９乃至３２のいずれかに記載のリソース。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公表番号】特表２００６−５２６１８４（Ｐ２００６−５２６１８４Ａ）
【公表日】平成１８年１１月１６日（２００６．１１．１６）
【国際特許分類】
【出願番号】特願２００４−５７１５１０（Ｐ２００４−５７１５１０）
【出願日】平成１５年５月１２日（２００３．５．１２）
【国際出願番号】ＰＣＴ／ＥＰ２００３／００４９４１
【国際公開番号】ＷＯ２００４／１００４８７
【国際公開日】平成１６年１１月１８日（２００４．１１．１８）
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【Ｆターム（参考）】
【公表日】平成１８年１１月１６日（２００６．１１．１６）
【国際特許分類】
【出願日】平成１５年５月１２日（２００３．５．１２）
【国際出願番号】ＰＣＴ／ＥＰ２００３／００４９４１
【国際公開番号】ＷＯ２００４／１００４８７
【国際公開日】平成１６年１１月１８日（２００４．１１．１８）
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【Ｆターム（参考）】
[ Back to top ]