(57)【要約】  特にリアルタイム通信における、通信相手のアイデンティティを検証する方法を提供する。発呼者（Ａ）が被呼者（Ｂ）へメッセージを送信し、発呼者（Ａ）は自己署名証明書を上記メッセージに添付する。本方法において、発呼者（Ａ）および被呼者（Ｂ）は信用の輪に属し、該信用の輪内のユーザの証明書は１つ以上の鍵サーバ（３）によって保存される。上記信用の輪内のユーザ間の信頼関係を用いることにより、上記メッセージに添付された証明書および被呼者の証明書に基づいて、発呼者（Ａ）と被呼者（Ｂ）との間の信頼チェインを計算する。被呼者（Ｂ）によって受信された上記メッセージのさらなる処理は、導出された信頼チェインの長さに基づく。また、対応するシステムも開示される。
2011519215.tif 000002
【特許請求の範囲】
【請求項１】
特にリアルタイム通信における、通信相手のアイデンティティを検証する方法において、発呼者（Ａ）が被呼者（Ｂ）へメッセージを送信し、前記発呼者（Ａ）は自己署名証明書を前記メッセージに添付し、該方法は、
前記発呼者（Ａ）および前記被呼者（Ｂ）が信用の輪に属し、該信用の輪内のユーザの証明書は１つ以上の鍵サーバ（３）によって保存され、
前記信用の輪内のユーザ間の信頼関係を用いることにより、前記メッセージに添付された証明書および前記被呼者の証明書に基づいて、前記発呼者（Ａ）と前記被呼者（Ｂ）との間の信頼チェインを計算し、
前記被呼者（Ｂ）によって受信された前記メッセージのさらなる処理が、導出された信頼チェインの長さに基づく
ことを特徴とする、通信相手のアイデンティティを検証する方法。
【請求項２】
前記発呼者（Ａ）がその秘密鍵で前記メッセージに署名し、対応する公開鍵を含む自己署名証明書を前記メッセージに付加することを特徴とする請求項１に記載の方法。
【請求項３】
ユーザが、他のユーザによって署名された証明書を前記１つ以上の鍵サーバ（３）にアップロードすることを特徴とする請求項１または２に記載の方法。
【請求項４】
前記信用の輪内のユーザ間の信頼関係が、リアルタイムで、または、少なくとも近似的にリアルタイムで、通話時に導出されることを特徴とする請求項１ないし３のいずれか１項に記載の方法。
【請求項５】
前記１つ以上の鍵サーバ（３）が、受信する各証明書内の署名を検証する特化鍵サーバ（４）を含むことを特徴とする請求項１ないし４のいずれか１項に記載の方法。
【請求項６】
前記特化鍵サーバ（４）が、前記特化鍵サーバ（４）によって検証されたすべての証明書間の信頼関係を含むファイルを周期的に計算することを特徴とする請求項５に記載の方法。
【請求項７】
前記ファイルが前記特化鍵サーバ（４）によって周期的に公開されることを特徴とする請求項６に記載の方法。
【請求項８】
前記ファイルの計算および／または公開の周期が、前記特化鍵サーバ（４）が証明書を受信するペースに動的に適応されることを特徴とする請求項６または７に記載の方法。
【請求項９】
検証された証明書間の信頼関係が、圧縮された機械可読なフォーマットで前記ファイルに含まれることを特徴とする請求項６ないし９のいずれか１項に記載の方法。
【請求項１０】
導出された信頼チェインの長さが所定の第１しきい値を下回る場合、前記被呼者（Ｂ）は前記メッセージを受理することを特徴とする請求項１ないし９のいずれか１項に記載の方法。
【請求項１１】
導出された信頼チェインの長さが所定の第２しきい値を超える場合、前記被呼者（Ｂ）は前記メッセージを拒否することを特徴とする請求項１ないし１０のいずれか１項に記載の方法。
【請求項１２】
導出された信頼チェインの長さが所定の第３しきい値を超える場合、前記被呼者（Ｂ）は前記メッセージの信頼性をチェックするためにさらなるステップを呼び出すことを特徴とする請求項１ないし１１のいずれか１項に記載の方法。
【請求項１３】
使用される信用の輪がＰＧＰ（Pretty Good Privacy）の信用の輪であることを特徴とする請求項１ないし１２のいずれか１項に記載の方法。
【請求項１４】
事前検証された証明書の数を制限するためにフィルタリングが設けられることを特徴とする請求項５ないし１３のいずれか１項に記載の方法。
【請求項１５】
事前検証された証明書の制限がドメインに基づくことを特徴とする請求項１４に記載の方法。
【請求項１６】
事前検証プロセスが複数の特化鍵サーバ（４）間に分散されることを特徴とする請求項５ないし１５のいずれか１項に記載の方法。
【請求項１７】
特にリアルタイム通信における、通信相手のアイデンティティを検証するシステムにおいて、発呼者（Ａ）が被呼者（Ｂ）へメッセージを送信し、前記発呼者（Ａ）は自己署名証明書を前記メッセージに添付し、該システムは、
前記発呼者（Ａ）および前記被呼者（Ｂ）が属する信用の輪と、
前記信用の輪内のユーザの証明書を保存する１つ以上の鍵サーバ（３）と、
前記信用の輪内のユーザ間の信頼関係を用いることにより、前記メッセージに添付された証明書および前記被呼者の証明書に基づいて、前記発呼者（Ａ）と前記被呼者（Ｂ）との間の信頼チェインを計算するエンティティと、
前記被呼者（Ｂ）によって受信された前記メッセージのさらなる処理を、導出された信頼チェインの長さに基づいて実行するように構成されたメッセージ処理要素と
を備えたことを特徴とする、通信相手のアイデンティティを検証するシステム。
【請求項１８】
前記１つ以上の鍵サーバ（３）が鍵サーバフェデレーション（２）を構成することを特徴とする請求項１７に記載のシステム。
【請求項１９】
前記鍵サーバフェデレーション（２）の鍵サーバ（３）が、相互の鍵データベースを更新するように構成されることを特徴とする請求項１８に記載のシステム。
【請求項２０】
前記１つ以上の鍵サーバ（３）が、受信する各証明書内の署名を検証するように構成された特化鍵サーバ（４）を含むことを特徴とする請求項１７ないし１９のいずれか１項に記載のシステム。
【請求項２１】
前記特化鍵サーバ（４）が、保存しているすべての証明書間の信頼関係を含むファイルを周期的に公開するように構成されることを特徴とする請求項２０に記載のシステム。
【請求項２２】
前記メッセージ処理要素は、導出された信頼チェインの長さが所定の第１しきい値を下回る場合に前記メッセージを受理するように構成されることを特徴とする請求項１７ないし２１のいずれか１項に記載のシステム。
【請求項２３】
前記メッセージ処理要素は、導出された信頼チェインの長さが所定の第２しきい値を超える場合に前記メッセージを拒否するように構成されることを特徴とする請求項１７ないし２２のいずれか１項に記載のシステム。
【請求項２４】
前記メッセージ処理要素は、導出された信頼チェインの長さが所定の第３しきい値を超える場合に前記メッセージの信頼性をチェックするためにさらなるステップを呼び出す専用サービスへ、前記メッセージを転送するように構成されることを特徴とする請求項１７ないし２３のいずれか１項に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、特にリアルタイム通信における、通信相手のアイデンティティを検証する方法およびシステムに関する。ここで、発呼者が被呼者へメッセージを送信し、発呼者は自己署名証明書を該メッセージに添付する。
【背景技術】
【０００２】
現在の通信ネットワークは、多様な方法で相互に通信する可能性をユーザに提供している。例えば、ユーザは、相互に電子メールメッセージやＳＭＳ（ショートメッセージサービス）を交換したり、相互にインスタントメッセージング（ＩＭ）経由で通信したりすることができるが、これらは、テキストメッセージによる通信として最も普及しているサービスを挙げたに過ぎない。特に、例えばＶｏＩＰ（Voice over IP）等のリアルタイム通信は、近年ますます重要になっている。最近では非常に多くのユーザが、これらすべての通信形態の多様な便益を活用しているが、依然としていくつかの重大な欠点も伴う。以下では、１つの特定の問題について、ＶｏＩＰを例に説明するが、この問題は他の通信形態でも同様に起こる。
【０００３】
ＶｏＩＰプロトコル（例えば、ＳＩＰ, Session Initiation Protocol）は、多くの種類の攻撃を受けやすい。例として、サービス中断攻撃（すなわち、サービス妨害（ＤｏＳ, Denial of Service）およびソーシャル攻撃（すなわち、SPam over Internet Telephony, ＳＰＩＴ）がある。これらの攻撃を防ぐためには、入来メッセージ（例えば、ＳＩＰ−Ｉｎｖｉｔｅ）が信頼できるか、それとも悪意があるかを評価する必要がある。１つの中心的課題は、入来メッセージが、ＳＩＰメッセージ内の発呼者のアイデンティティ（すなわち、Ｆｒｏｍヘッダ内のＵＲＩ（Uniform Resource Identifier））に属するユーザによって発信されたかどうかを検証することである。この問題を解決するのは容易ではない。というのは、ＶｏＩＰアイデンティティ（例えば、ＳＩＰ−ＵＲＩ）は、なりすましの可能性があるからである。このため、ＳＰＩＴや迷惑通信のようなソーシャル攻撃の検出は一般に複雑な問題となる。
【０００４】
入来メッセージが発呼者アイデンティティに属するユーザによって送信されたかどうかを評価するための、現在提案されている多くのメカニズムは、いわゆる「強いアイデンティティ」に依拠している。すなわち、受信側によって信頼されている集中管理機関によってアイデンティティが署名されている場合、このアイデンティティから受信されるメッセージは悪意がないと考えられる。ＳＩＰの場合、アイデンティティはＳＩＰ−ＵＲＩであり、このアイデンティティを発呼者のドメインに署名させることが提案されている。発呼者が発呼する際には、ドメインが発呼者に対して認証要求を行う。適正な認証後にはじめて、ドメインは、発信メッセージに署名する。着呼の際には、被呼者のプロキシが、発呼者のドメインの公開鍵で署名を検証する。この技術は、ＲＦＣ４４７４（Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP), http://tools.ietf.org/html/rfc4474Draft SPIT）に記載されている。
【０００５】
しかし、上記のアプローチはいくつかの点で不利であることがわかる。第１に、このアプローチは、ドメイン間で公開鍵を交換するメカニズムの存在を要求する。さらに、取得した公開鍵が、送信者のドメインにバインドしていることを検証するメカニズムが必要である。そして、アイデンティティの表明に関連するユーザの挙動に関して信頼性がない。はじめの２つの問題を解決するために慣例となっているのは、公開鍵基盤（ＰＫＩ, Public Key Infrastructure）の利用である。認証局（ＣＡ, Certificate Authority）の階層を利用して、システム内の任意の２つのエンティティ間に、暗号検証可能な信頼チェインを確立する。これは、このＣＡ階層の最上位の中央機関であるルートＣＡが、システム内のすべてのエンティティによって信頼されることを意味する。ルートＣＡは、このようなシステムにおけるアイデンティティの表明に関連するすべての信頼の基本構成要素である。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
したがって、本発明の目的は、通信相手のアイデンティティを検証するための頭書のような方法およびシステムにおいて、上記の問題点を広範に回避するとともに、メッセージの信頼性の評定が可能となるような改良およびさらなる展開を行うことである。
【課題を解決するための手段】
【０００７】
本発明によれば、上記の目的は、請求項１の構成を備えた方法によって達成される。この請求項に記載の通り、本方法は、以下の構成を備えたことを特徴とする。すなわち、発呼者および被呼者が信用の輪（web-of-trust）に属し、該信用の輪内のユーザの証明書が１つ以上の鍵サーバによって保存される。上記信用の輪内のユーザ間の信頼関係を用いることにより、上記メッセージに添付された証明書および被呼者の証明書に基づいて、発呼者と被呼者との間の信頼チェインを計算する。被呼者によって受信された上記メッセージのさらなる処理は、導出された信頼チェインの長さに基づく。
【０００８】
また、上記の目的は、独立請求項１７の構成を備えたシステムによって達成される。この請求項に記載の通り、本システムは、発呼者および被呼者が属する信用の輪と、該信用の輪内のユーザの証明書を保存する１つ以上の鍵サーバと、上記信用の輪内のユーザ間の信頼関係を用いることにより、上記メッセージに添付された証明書および被呼者の証明書に基づいて、発呼者と被呼者との間の信頼チェインを計算するエンティティと、被呼者によって受信された上記メッセージのさらなる処理を、導出された信頼チェインの長さに基づいて実行するように構成されたメッセージ処理要素と、を備えたことを特徴とする。
【０００９】
本発明によって初めて認識されたこととして、入来メッセージが発呼者アイデンティティに属するユーザによって送信されたかどうかを評価するための既存のメカニズムは、認証局の階層構造を必要とすることから、かなり複雑である。ＰＫＩを用いた集中型アプローチとは異なり、本発明は、ＰＫＩの代わりに、署名されたアイデンティティを検証するために信用の輪を用いる分散型アプローチを追求する。この信用の輪内のユーザの証明書が、１つ以上の鍵サーバによって保存される。信用の輪内のユーザ間の信頼関係を用いることにより、信用の輪にも属する発呼者と被呼者との間の信頼チェインを計算する。２つのアイデンティティＡとＢとの間の信頼チェインは、推移的な証明書チェインである。すなわち、ＡがアイデンティティＩＤ１からの証明書に署名し、さらにアイデンティティＩＤ１がアイデンティティＩＤ２からの証明書に署名し、...、ＩＤｎがアイデンティティＢの証明書に署名する。
【００１０】
メッセージが、そのメッセージに固有のアイデンティティに属するユーザによって実際に送信されたことを検証するため、被呼者は、発呼者と被呼者との間の上記信頼チェインを計算するアルゴリズムを呼び出す。このアルゴリズムへの入力は、受信されたメッセージに添付された証明書と、被呼者の証明書とである。発呼者と被呼者との間の導出された信頼チェインの長さに応じて、メッセージのさらなる処理を決定することができる。
【００１１】
本発明の主要な利点は、信用の輪において、エンドユーザは、ユーザと公開鍵との間のバインディングを表明するだけでなく、（先行するインタラクションで認識された）表明されたアイデンティティの信頼性をも表明することである。これに対して、ＰＫＩは通常、技術的認証に基づいてアイデンティティに署名する（例えば、ユーザ（あるいはＳＩＰユーザエージェント）が、認証要求を技術的に解決する）。一方、本発明によれば、技術的認証のみに依拠する代わりに、（他のユーザから見た）アイデンティティの実際の挙動と、現実のものとなり得る信頼性とに依拠する。迷惑通信を検出するために、信用の輪の利用は有利である。というのは、信用の輪は、信頼を技術的表明と関連づけるからである。さらに、信頼は、ＰＫＩに基づく解決法の場合のような中央機関には依拠しない。信用の輪において、信頼は分散化される。信用の輪は、ユーザ間のソーシャルな関係を利用する。これは、ＳＰＩＴのような迷惑通信に対処するための主要な構成要素となり得る。
【００１２】
なお、「通信相手」、「発呼者」および「被呼者」という用語は広義に解すべきであり、特定の通信形態に限定されない。例えばＳＩＰに基づくＶｏＩＰアプリケーションにおいては、本発明が特に有効であることがわかっているが、ＶｏＩＰアプリケーション以外に、本発明は、例えば電子メール通信やインスタントメッセージングのアプリケーションにも同様に適用可能である。これらの場合、発呼者はメッセージの発信者に対応し、被呼者はメッセージの受信者に対応することになる。
【００１３】
また、本発明による方法およびシステムは、階層の最上位に中央機関を有する階層構造を必要としないが、ＣＡ階層を備えたＰＫＩ構成にも適用可能であることに注意すべきである。この場合、ＣＡ階層における認証局は、ＣＡ階層内で発行される証明書の事前検証を実行することができる。これは、検証プロセスを顕著に高速化することになる。というのは、発呼者の発信プロキシの署名を、実際の通話の前に検証することができるからである。
【００１４】
具体的実施形態によれば、発呼者がその秘密鍵でメッセージに署名し、対応する公開鍵を含む自己署名証明書を付加する。自己の秘密鍵でメッセージに署名することは、ＰＫＩに基づくアプローチの場合と同様に、特定のヘッダ（例えば、Ｆｒｏｍヘッダフィールドを含み、さらに、メッセージの本文を含んでもよい）に対するハッシュを計算し、結果として得られるハッシュ値に署名することによって実行可能である。自己署名証明書の付加は、Ｓ／ＭＩＭＥ（Secure/Multipurpose Internet Mail Extensions）により実行可能である。
【００１５】
有利な態様として、ユーザは、他のユーザによって署名された証明書を上記１つ以上の鍵サーバにアップロードする。証明書をアップロードすることによって参加するユーザが多いほど、発呼者と被呼者との間の（短い）信頼チェインを計算する際のシステムの有効性が高くなる。
【００１６】
具体的実施形態によれば、信用の輪内のユーザ間の信頼関係が、リアルタイムで、または、少なくとも近似的にリアルタイムで、通話時に導出される。リアルタイム通信の場合であっても、通話に影響を及ぼすことなく、ユーザ間の導出された信頼関係に基づいて、発呼者と被呼者との間の信頼チェインを計算することができる。
【００１７】
しかし、特に信頼チェインの暗号検証に関しては、ユーザ間の信頼関係が通話前に既知であると有利であることがわかる。このためには、上記１つ以上の鍵サーバが、ユーザからまたは他のサーバから受信する各証明書内の署名を検証する特化鍵サーバを含むとよい。暗号検証を含む信頼関係を前処理することにより、信頼性の評定をリアルタイムで行うことができる。
【００１８】
特化鍵サーバは、この特化鍵サーバによって検証されたすべての証明書間の信頼関係を含むファイルを周期的に計算するように構成されてもよい。特化鍵サーバは、このファイルを用いて、２つのアイデンティティ間の信頼チェインを計算するサービスを提供することができる。別法として、またはこれに加えて、特化鍵サーバは、信頼関係を含むファイルを周期的に公開するように構成されてもよい。この場合、他のエンティティあるいは装置は、このファイルを利用して、自ら信頼チェインを計算することができる。ファイルの計算およびファイルの公開の両方の周期は、特化鍵サーバが証明書を受信するペースに動的に適応させてもよい。これにより、呼が信頼できるか否かを識別するために使用される信頼関係を常にできるだけ更新することが可能となる。なお、所定の長さの周期を設けてもよい。
【００１９】
ファイル内には、検証された証明書間の信頼関係が、圧縮された機械可読なフォーマットで含まれてもよい。これにより、２つのアイデンティティ間の信頼チェインのリアルタイム計算がさらに容易になる。具体的には、知られている .wot ファイルフォーマットが使用可能である。圧縮形式で信頼パスを保存するためのこのファイルフォーマットは、従来のＰＧＰ（Pretty Good Privacy）鍵サーバによってすでに使用・作成されている。しかし、ＰＧＰ型の信用の輪においては、鍵サーバは信頼されず、任意のユーザが鍵サーバ上に任意の証明書を保存することができる。すなわち、従来のＰＧＰ鍵サーバは、信頼パスファイルを作成する前には、証明書の署名を検証しない。この作業はユーザに委ねられる。
【００２０】
被呼者によって受信されたメッセージを、導出された信頼チェインの長さに基づいてさらに処理する際には、しきい値を設定すると有益である。このしきい値は、被呼者自身によって設定されても、追加的なメッセージ処理要素によって設定されてもよい。追加的なメッセージ処理要素は、例えば、被呼者のプロキシサーバであってもよい。特に、３つのしきい値を設定するとよい。導出された信頼チェインの長さが所定の第１しきい値を下回る場合、メッセージを受理する。実際の（電話またはＶｏＩＰ）呼の場合、これは、被呼者との間に呼が設定されることを意味する。導出された信頼チェインの長さが所定の第２しきい値を超える場合、メッセージは拒否される（すなわち、被呼者との間に呼は設定されない）。また、第３しきい値が設定される。導出された信頼チェインの長さがこの第３しきい値を超える場合、専用サービスにメッセージを転送する。このサービスは、メッセージの信頼性をチェックするためにさらなるステップを呼び出してもよい。
【００２１】
ユーザが多数となり得る実際のシステムにおけるスケーラビリティの問題に対処するためには、事前検証された証明書の数を制限するフィルタリングメカニズムを設けてもよい。例えば、証明書の制限は、ドメインに基づくことが可能である。別法として、またはこれに加えて、スケーラビリティの問題は、複数の特化鍵サーバ間に事前検証プロセスを分散させることによって対処してもよい。
【００２２】
本発明を好適な態様で実施するにはいくつもの可能性がある。このためには、一方で請求項１および１７に従属する諸請求項を参照しつつ、他方で図面により例示された本発明の好ましい実施形態についての以下の説明を参照されたい。図面を用いて本発明の好ましい実施形態を説明する際には、本発明の教示による好ましい実施形態一般およびその変形例について説明する。
【図面の簡単な説明】
【００２３】
【図１】本発明による方法の一実施形態の具体例の模式図である。
【図２】本発明の一実施形態によるメッセージフローを例示する図である。
【発明を実施するための形態】
【００２４】
図１は、本発明による方法の一実施形態の具体例の全般的アーキテクチャを示す。ユーザＡ（発呼者）が、呼設定のためのメッセージ、例えばＳＩＰ  ＩＮＶＩＴＥメッセージを、ユーザＢ（被呼者として作用する）へ送信する。ユーザＡからのメッセージは、メッセージリレーすなわちプロキシ１によってユーザＢへ転送される。ＳＩＰ  ＩＮＶＩＴＥメッセージに対する応答をユーザＡに返送することによって呼を設定する前に、ユーザＢは、その呼が迷惑呼ではないこと、および、その入呼が、その発呼者のアイデンティティに属するユーザによって実際に発信されたものであることを確認したいと考える。発呼者のアイデンティティは、この場合には、ＳＩＰ  ＩＮＶＩＴＥメッセージのＦｒｏｍヘッダ内のユーザＡのＵＲＩである。
【００２５】
発呼者Ａのアイデンティティを検証するために使用されるアーキテクチャは、鍵サーバネットワーク２を有する。鍵サーバネットワーク２は、複数の、好ましくは冗長化された、鍵サーバ３を備える。そのうちの３つを例として図示している。鍵サーバ３は、ユーザの鍵および／または証明書を保存する。具体的には、ユーザは、他のユーザによって署名された証明書を鍵サーバ３にアップロードする。鍵サーバ３どうしは、専用の通信プロトコルを用いて、相互の鍵データベースを更新する。
【００２６】
従来のＰＧＰ型の信用の輪においては、鍵サーバは信頼されず、任意のユーザが鍵サーバ上に任意の証明書を保存することができる。すなわち、証明書の署名は鍵サーバによって検証されない。この作業はユーザに委ねられる。これに対して、図１に示す実施形態によれば、鍵サーバフェデレーション２に属する特化鍵サーバ４（図１の下側の鍵サーバ）が設けられ、フェデレーション２内で通常の動作を行うだけでなく、以下のことも行う。
【００２７】
ユーザから、または他のサーバから特化鍵サーバ４が受信するそれぞれの証明書について、特化鍵サーバ４は、証明書内の署名を検証する。このサーバがこれを行うことができるのは、鍵サーバとして、証明書に署名した秘密鍵に対応する公開鍵を所有しているからである。また、特化鍵サーバ４は、このサーバによって検証されたすべての証明書間の信頼関係を含む信頼関係ファイルを周期的に計算する。このファイルを用いて、特化鍵サーバ４は、２つのアイデンティティ間の信頼チェインを計算するサービスを提供することができる。その結果、信頼チェインの計算および暗号検証をリアルタイムで行うことが実現される。
【００２８】
なお、別の実施形態によれば、信頼関係ファイルは、他者が使用するために、特化鍵サーバ４によって周期的に公開されることも可能である。しかし、図１に示す例では、ＡからＢへのメッセージを受信するメッセージリレーすなわちプロキシ１が、特化鍵サーバ４によって提供されるサービスを用いて、ＡとＢとの間の信頼チェインの長さを求める。このためには、被呼者Ｂが、例えば公開鍵をハッシュすることによって鍵ＩＤを計算し、これを発呼者Ａの鍵ＩＤとともにプロキシ１へ転送する。この情報に基づいて、プロキシ１は特化鍵サーバ４と交信する。本具体例では、特化鍵サーバ４は、ＡがアイデンティティＣを信頼し、さらにアイデンティティＣがアイデンティティＢを信頼していることを検出する。Ａ、Ｂ、およびＣの対応する証明書内のすべての署名は、特化鍵サーバ４によって事前に検証されているので、信頼チェインは計算されるだけでなく検証もなされる。これは重要である。というのは、ＡとＢとの間の信頼チェインを計算することはリアルタイムで実行できるが、対応する検証はリアルタイムでは実行不可能だからである。したがって、それはサーバによって事前に実行される必要がある。
【００２９】
図２は、本発明の一実施形態による、発呼者として作用するユーザＡと被呼者として作用するユーザＢとの間のメッセージフローを例示している。本具体例では、プロキシサーバ１（例えばＳＩＰプロキシ）は、外部サービス５を使用する。外部サービス５は、図１に関して説明した特化鍵サーバとしての特別の信用の輪の鍵サーバであってもよく、あるいは別法として、上記のような特化鍵サーバから信用の輪の情報を周期的に取得する独立のサービスであってもよい。また、プロキシサーバ１は、信頼チェインの計算を自ら行うことも可能である。その場合、プロキシサーバ１およびサービス５は同じ装置／エンティティ内に配置される。
【００３０】
図２に示す実施形態によるメッセージフローにおいて、プロキシサーバ１は、ユーザＡによって署名された、ユーザＢを宛先とするメッセージを受信する。このメッセージが信頼できるかどうかを判断するため、プロキシサーバ１は、Ａの自己署名証明書およびＢのアイデンティティ（例えば、ＳＩＰメッセージの場合には、Ｔｏヘッダ内に存在する）とをサービス５へ転送する。サービス５は、信用の輪においてＡとＢとの間の信頼チェインが存在すれば、そのチェインの長さをプロキシサーバ１に返し、そのようなチェインが存在しなければエラーメッセージをプロキシサーバ１に返す。そして、プロキシサーバ１は、署名されたメッセージを、導出された信頼チェインの長さとともに、Ｂへ転送する。これにより、Ｂは、信頼チェインの長さに応じて、メッセージをどのように処理すべきかをローカルに決定することができる。なお、図２には明示していないが、（ユーザＢの代わりに）プロキシサーバ１が、信頼チェインの長さに応じて相異なるアクションを行うことも可能である。特に、ユーザＢが、プロキシサーバ１上に、カスタマイズされたコンフィグレーションを設定することができるようにしてもよい。これを用いて、プロキシサーバ１による呼処理がユーザＢのニーズに従って指定される。
【００３１】
上記の説明および添付図面の記載に基づいて、当業者は本発明の多くの変形例および他の実施形態に想到し得るであろう。したがって、本発明は、開示した具体的実施形態に限定されるものではなく、変形例および他の実施形態も、添付の特許請求の範囲内に含まれるものと解すべきである。本明細書では特定の用語を用いているが、それらは総称的・説明的意味でのみ用いられており、限定を目的としたものではない。
【図１】
2011519215.tif 000003
【図２】
2011519215.tif 000004
【国際調査報告】
2011519215.tif 000005
2011519215.tif 000006