JP4963425B2 - セッション鍵共有システム、第三者機関装置、要求側装置、および応答側装置 - Google Patents

Description

この発明は、セッション鍵共有システム、第三者機関装置、要求側装置、および応答側装置に関する。

従来より、インターネットやＩＰ（Internet Protocol）網などのネットワークにおいて、セキュリティを確保したセッション（セキュアセッション）をユーザ間で実現する手法として、セッション鍵（共通鍵や、ＲＳＡ（Rivest Shamir Adleman）やＤＨ（Diffie-Hellman）などの公開鍵）で暗号化したデータをユーザ間で送受信する手法がある。かかる手法による場合、セッション鍵は、ユーザ間で予め共有されなければならないことから、一般的には、セッションがユーザ間で確立される前に、ユーザ間でセッション鍵が転送されたり交換されたりすることになる。

具体的には、ユーザ間で互いの公開鍵または共通の秘密鍵が予め交換されていること、または、信頼された第三者機関によって保証された公開鍵証明書をユーザが持つことなど、エンドエンドでの認証が予め確保されていることを前提として、セッションがユーザ間で確立される前に、セッション鍵が転送されたり交換されたりすることになる。例えば、非特許文献１に開示されているＲＦＣ（Request for Comments）４５６７は、Ｓ／ＭＩＭＥ（Secure Multipurpose Internet Mail Extensions）やＩＰｓｅｃ（Security Architecture for Internet Protocol）などを利用しつつ、ＳＤＰ（Session Description Protocol）上でセッション鍵が転送されたり交換されたりするためのプロトコルを規定するものであり、ユーザ間で互いの公開鍵が予め交換されていることなどを前提とすることで、中間者攻撃（Man in the Middle）などによる鍵情報の不正利用を防止している。

"Key Management Extensions for Session Description Protocol(SDP) and Real Time Streaming Protocol(RTSP)"、［online］、［平成１９年１月９日検索］、インターネット＜http://www.ietf.org/rfc/rfc4567.txt＞

ところで、上記した従来の技術では、以下に説明するように、セッション鍵を共有（転送、交換）するにあたり、例えば、ユーザ間で互いの公開鍵が予め交換されるなど、エンドエンドでの認証が予め確保されていなければならないという課題がある。言い換えれば、ユーザ間で互いの公開鍵または秘密鍵が予め交換されていること、または、信頼された第三者機関によって保証された公開鍵証明書をユーザが持つことなどが前提となる。すると、前者については、任意のユーザ間で鍵を予め交換することはしばしば困難であり、仮に交換が実現されたとしても、膨大な鍵を適切に管理しなくてはならないといった課題が生じる。また、後者についても、全ての一般ユーザが信頼された公開鍵証明書を持つことはしばしば困難であるといった課題が生じる。

そこで、この発明は、上記した従来技術の課題を解決するためになされたものであり、エンドエンドでの認証が予め確保されていることを前提とせずに、セッション鍵を共有（転送、交換）することが可能なセッション鍵共有システム、第三者機関装置、要求側装置、および応答側装置を提供することを目的とする。

上述した課題を解決し、目的を達成するため、本発明は、セッションを確立することを要求する要求側装置と、当該要求に応答して当該要求側装置との間でセッションを確立する応答側装置と、当該要求側装置および当該応答側装置の認証に関する処理を行う第三者機関装置とで構成され、前記セッションを暗号化するセッション鍵を、互いを通信相手とする当該要求側装置と当該応答側装置との間で当該セッションの確立前に共有するセッション鍵共有システムであって、前記第三者機関装置は、前記要求側装置および前記応答側装置の各々の認証に用いる認証情報を保持する認証情報保持手段と、前記要求側装置および前記応答側装置を認証することを要求する認証要求の各々を当該要求側装置および当該応答側装置の各々から受信すると、前記認証情報保持手段によって保持された認証情報を用いて当該要求側装置および当該応答側装置の各々を認証する認証手段と、前記要求側装置および前記応答側装置の各々による前記認証要求が前記認証手段によって認証された結果が成功の場合に、当該要求側装置と当該応答側装置との間で前記セッション鍵を共有させるように、当該セッション鍵を当該要求側装置および／または当該応答側装置に送信するセッション鍵共有手段とを備え、前記要求側装置は、当該要求側装置を認証することを要求する認証要求を前記第三者機関装置に対して送信する認証要求送信手段を備え、前記応答側装置は、当該応答側装置を認証することを要求する認証要求を前記第三者機関装置に対して送信する認証要求送信手段を備えたことを特徴とする。

また、本発明は、上記の発明において、前記第三者機関装置は、前記通信相手にセッション鍵を取得させる前記要求側装置および／または前記応答側装置に、当該セッション鍵を取得するための情報であるセッション鍵取得情報を送信するセッション鍵取得情報送信手段をさらに備え、前記通信相手にセッション鍵を取得させる前記要求側装置および／または前記応答側装置は、前記セッション鍵取得情報送信手段によって送信された前記セッション鍵取得情報を、前記セッションを確立するに際して必要とされる信号に付加した形態で当該通信相手に転送するセッション鍵取得情報転送手段をさらに備え、セッション鍵を取得する前記要求側装置および／または前記応答側装置は、前記セッション鍵取情報転送手段によって前記通信相手から転送された前記セッション鍵取得情報を受信すると、当該セッション鍵取得情報を前記第三者機関装置に送信することで、当該セッション鍵取得情報によって取得することが可能なセッション鍵の取得を前記第三者機関装置に要求するセッション鍵取得要求手段をさらに備え、前記セッション鍵共有手段は、前記セッション鍵取得要求手段によって送信された前記セッション鍵取得情報を受信すると、当該セッション鍵取得情報によって取得することが可能なセッション鍵を、当該セッション鍵取得情報を送信した前記要求側装置および／または前記応答側装置に送信することを特徴とする。

また、本発明は、上記の発明において、前記セッション鍵共有手段は、前記要求側装置および／または前記応答側装置で作成された前記セッション鍵を共有させることを特徴とする。

また、本発明は、上記の発明において、前記セッション鍵共有手段は、前記第三者機関装置で作成された前記セッション鍵を共有させることを特徴とする。

また、本発明は、上記の発明において、前記セッション鍵共有手段は、前記セッション鍵を送信するとともに、当該セッション鍵の属性を示す属性情報をさらに送信することを特徴とする。

また、本発明は、上記の発明において、前記第三者機関装置は、互いの公開鍵を予め交換している複数の第三者機関装置で構成されるものであって、前記複数の第三者機関装置の内の所定の第三者機関装置は、当該所定の第三者機関装置以外のその他の第三者機関装置において電子署名が添付された前記セッション鍵に関する情報を受信すると、当該セッション鍵に関する情報について検証する検証手段をさらに備えたことを特徴とする。

また、本発明は、上記の発明において、前記第三者機関装置は、前記要求側装置と前記応答側装置との間でセッションを確立するに際して必要とされる信号を制御するＳＩＰプロキシと同一の装置で構成されるものであって、前記セッション鍵共有手段は、前記セッション鍵を前記第三者機関装置が制御する前記信号に付加する形態で送信することを特徴とする。

また、本発明は、上記の発明において、セッションを確立することを要求する要求側装置と、当該要求に応答して当該要求側装置との間でセッションを確立する応答側装置と、当該要求側装置および当該応答側装置の認証に関する処理を行う第三者機関装置とで構成され、前記セッションを暗号化するセッション鍵を、互いを通信相手とする当該要求側装置と当該応答側装置との間で当該セッションの確立前に共有するセッション鍵共有システムにおける前記第三者機関装置であって、前記要求側装置および前記応答側装置の各々の認証に用いる認証情報を保持する認証情報保持手段と、前記要求側装置および前記応答側装置を認証することを要求する認証要求の各々を当該要求側装置および当該応答側装置の各々から受信すると、前記認証情報保持手段によって保持された認証情報を用いて当該要求側装置および当該応答側装置の各々を認証する認証手段と、前記要求側装置および前記応答側装置の各々による前記認証要求が前記認証手段によって認証された結果が成功の場合に、当該要求側装置と当該応答側装置との間で前記セッション鍵を共有させるように、当該セッション鍵を当該要求側装置および／または当該応答側装置に送信するセッション鍵共有手段と、を備えたことを特徴とする。

また、本発明は、セッションを確立することを要求する要求側装置と、当該要求に応答して当該要求側装置との間でセッションを確立する応答側装置と、当該要求側装置および当該応答側装置の認証に関する処理を行う第三者機関装置とで構成され、前記セッションを暗号化するセッション鍵を、互いを通信相手とする当該要求側装置と当該応答側装置との間で当該セッションの確立前に共有するセッション鍵共有システムにおける前記要求側装置であって、前記要求側装置を認証することを要求する認証要求を前記第三者機関装置に対して送信することで、当該第三者機関装置において当該要求側装置を認証させ、当該認証の結果が成功の場合には、当該第三者機関装置に、前記要求側装置と前記応答側装置との間で前記セッション鍵を共有させるように当該セッション鍵を当該要求側装置および／または当該応答側装置に送信させる認証要求送信手段を備えたことを特徴とする。

また、本発明は、セッションを確立することを要求する要求側装置と、当該要求に応答して当該要求側装置との間でセッションを確立する応答側装置と、当該要求側装置および当該応答側装置の認証に関する処理を行う第三者機関装置とで構成され、前記セッションを暗号化するセッション鍵を、互いを通信相手とする当該要求側装置と当該応答側装置との間で当該セッションの確立前に共有するセッション鍵共有システムにおける前記応答側装置であって、前記応答側装置を認証することを要求する認証要求を前記第三者機関装置に対して送信することで、当該第三者機関装置において当該応答側装置を認証させ、当該認証の結果が成功の場合には、当該第三者機関装置に、前記要求側装置と前記応答側装置との間で前記セッション鍵を共有させるように当該セッション鍵を当該要求側装置および／または当該応答側装置に送信させる認証要求送信手段を備えたことを特徴とする。

本発明によれば、セッションを確立することを要求する要求側装置と、要求に応答して要求側装置との間でセッションを確立する応答側装置と、要求側装置および応答側装置の認証に関する処理を行う第三者機関装置とで構成され、セッションを暗号化するセッション鍵を、互いを通信相手とする要求側装置と応答側装置との間でセッションの確立前に共有するセッション鍵共有システムであって、第三者機関装置は、要求側装置および応答側装置の各々の認証に用いる認証情報を保持し、要求側装置および応答側装置を認証することを要求する認証要求の各々を要求側装置および応答側装置の各々から受信すると、保持された認証情報を用いて要求側装置および応答側装置の各々を認証し、要求側装置および応答側装置の各々による認証要求が認証された結果が成功の場合に、要求側装置と応答側装置との間でセッション鍵を共有させるように、セッション鍵を要求側装置および／または応答側装置に送信し、要求側装置は、要求側装置を認証することを要求する認証要求を第三者機関装置に対して送信し、応答側装置は、応答側装置を認証することを要求する認証要求を第三者機関装置に対して送信するので、エンドエンドでの認証が予め確保されていることを前提とせずに、セッション鍵を共有（転送、交換）することが可能になる。

また、本発明によれば、第三者機関装置は、通信相手にセッション鍵を取得させる要求側装置および／または応答側装置に、セッション鍵を取得するための情報であるセッション鍵取得情報を送信し、通信相手にセッション鍵を取得させる要求側装置および／または応答側装置は、送信されたセッション鍵取得情報を、セッションを確立するに際して必要とされる信号に付加した形態で通信相手に転送し、セッション鍵を取得する要求側装置および／または応答側装置は、通信相手から転送されたセッション鍵取得情報を受信すると、セッション鍵取得情報を第三者機関装置に送信することで、セッション鍵取得情報によって取得することが可能なセッション鍵の取得を第三者機関装置に要求し、送信されたセッション鍵取得情報を受信すると、セッション鍵取得情報によって取得することが可能なセッション鍵を、セッション鍵取得情報を送信した要求側装置および／または応答側装置に送信ので、セッション鍵を取得するための情報を、セッションを確立するに際して必要とされる信号として、例えば、既存のＳＩＰ（Session Initiation Protocol）信号にのせることで、簡易にセッション鍵を共有（転送、交換）することが可能になる。

また、本発明によれば、要求側装置および／または応答側装置で作成されたセッション鍵を共有させるので、エンドエンドでの認証が予め確保されていることを前提とせずに、要求側装置や応答側装置で作成されたセッション鍵を共有することが可能になる。

また、本発明によれば、第三者機関装置で作成されたセッション鍵を共有させるので、エンドエンドでの認証が予め確保されていることを前提とせずに、第三者機関装置で作成されたセッション鍵を共有することが可能になる。

また、本発明によれば、セッション鍵を送信するとともに、セッション鍵の属性を示す属性情報をさらに送信するので、セッション鍵を取得した要求側装置（または応答側装置）において、セッション鍵に関する属性を知ることが可能になる。この場合には、セッション鍵を取得した要求側装置（または応答側装置）において、セッション鍵に関する属性を知ることが可能になる。例えば、属性情報として「セッション鍵の作成者」を送信すると、セッションを取得した要求側装置（または応答側装置）において、いずれの装置において作成されたセッション鍵であるかを判断することが可能になる。なお、その他の属性情報としては、「セッション鍵の受取者」、「有効期限」、「セッション鍵の種類」などが挙げられる。

また、本発明によれば、第三者機関装置は、互いの公開鍵を予め交換している複数の第三者機関装置で構成されるものであって、複数の第三者機関装置の内の所定の第三者機関装置は、所定の第三者機関装置以外のその他の第三者機関装置において電子署名が添付されたセッション鍵に関する情報を受信すると、セッション鍵に関する情報について検証するので、第三者機関装置が複数の第三者機関装置で構成されている場合にも、エンドエンドでの認証が予め確保されていることを前提とせずに、セッション鍵を共有することが可能になる。

また、本発明によれば、第三者機関装置は、要求側装置と応答側装置との間でセッションを確立するに際して必要とされる信号を制御するＳＩＰプロキシと同一の装置で構成されるものであって、セッション鍵を第三者機関装置が制御する信号に付加する形態で送信するので、第三者機関装置がＳＩＰプロキシと同一の装置で構成されている場合にも、エンドエンドでの認証が予め確保されていることを前提とせずに、セッション鍵を共有することが可能になる。

以下に添付図面を参照して、本発明に係るセッション鍵共有システムの実施例を説明する。以下では、実施例で用いる主要な用語、実施例１に係るセッション鍵共有システムの概要および特徴、実施例１に係るセッション鍵共有システムの構成、実施例１に係るセッション鍵共有システムによる処理の手順、実施例１の効果を順に説明し、続いて、他の実施例について説明する。なお、以下では、一つの要求側装置、一つの応答側装置、および一つの第三者機関装置で構成されるセッション鍵共有システムについて説明するが、本発明はこれに限られるものではなく、複数の要求側装置、複数の応答側装置、および一つの第三者機関装置で構成されるセッション鍵共有システムや、一つの要求側装置、一つの応答側装置、および複数の第三者機関装置で構成されるセッション鍵共有システムなど、他の異なる構成においても本発明を同様に適用することができる。

［用語の説明］
まず最初に、以下の実施例で用いる主要な用語を説明する。「セッション鍵」とは、インターネットやＩＰ（Internet Protocol）網などのネットワークにおいて、セキュリティを確保したセッション（セキュアセッション）を実現することを目的として用いられる鍵情報のことである。具体的には、共通鍵である「セッション鍵」や、ＲＳＡ（Rivest Shamir Adleman）やＤＨ（Diffie-Hellman）などの公開鍵である「セッション鍵」で暗号化したデータをユーザ間で送受信することで、セキュアセッションは実現される。このため、ユーザ間でセキュアセッションを実現するには、セッションがユーザ間で確立される前に、「セッション鍵」がユーザ間で予め共有されなければならない。以下の実施例では、「セッション鍵」が、ユーザ「ＵＡＣ（User Account）−１」（特許請求の範囲に記載の「要求側装置」に対応する）と、ユーザ「ＵＡＣ−２」（特許請求の範囲に記載の「応答側装置」に対応する）との間で予め共有されることになる。

ところで、上記したように、「セッション鍵」は、セッションがユーザ間で確立される前に、ユーザ間で予め共有されなければならないものであるが、任意のユーザ間でも共有されなければならないという点、公開鍵を持たない一般のユーザにおいても共有されなければならないという点、中間者攻撃（Man in the Middle）などの脅威に対して安全に共有されなければならないという点などに留意しつつ、どのようにして「セッション鍵」を共有するかが重要になる。以下の実施例では、「ＵＡＣ−１」と「ＵＡＣ−２」と「ＩｄＰ（Identity Provider）」（特許請求の範囲に記載の「第三者機関装置」に対応する）とで「セッション鍵共有システム」を構成し、これらの点を解決している。

なお、以下では、「ＵＡＣ−１」または「ＵＡＣ−２」と「ＩｄＰ」との間は、セキュリティが確保された通信路であることを前提とする一方で、「ＵＡＣ−１」または「ＵＡＣ−２」と「ＳＩＰプロキシ」との間は、セキュリティが確保されていない通信路であることを前提とする。このため、以下では、セッション鍵に関する情報が「ＳＩＰプロキシ」を経由する場合には、セッション鍵に関する情報をＳＡＭＬ（Security Assertion Markup Language）で規定されるような形式で送信する手法を採用し、セッション鍵に関する情報が「ＳＩＰプロキシ」を経由しない場合には、セッション鍵に関する情報をそのままの形式で送信する手法を採用しているが、本発明はこれに限られるものではなく、セッション鍵に関する情報の形式は、運用の形態に併せて適宜変更することが可能である。

また、以下では、「ＵＡＣ−１」と「ＵＡＣ−２」との間の通信が、「ＳＩＰプロキシ」を経由する「ＳＩＰ」によって行われ、「ＵＡＣ−１」または「ＵＡＣ−２」と「ＩｄＰ」との間の通信が、「ＨＴＴＰＳ（Hypertext Transfer Protocol Security）」によって行われる手法について説明するが、本発明はこれに限られるものではなく、例えば、Ｈ．３２３など「ＳＩＰ」以外のＩＰ電話用のプロトコルや、「ＨＴＴＰＳ」以外のプロトコルなどによって行われる手法にも、本発明を同様に適用することができる。

［実施例１に係るセッション鍵共有システムの概要および特徴］
続いて、図１を用いて、実施例１に係るセッション鍵共有システムの概要および特徴を説明する。図１は、実施例１に係るセッション鍵共有システムの概要および特徴を説明するための図である。

実施例１に係るセッション鍵共有システムは、上記したように、セッションを確立することを要求する要求側装置（ＵＡＣ−１）と、かかる要求に応答して要求側装置との間でセッションを確立する応答側装置（ＵＡＣ−２）と、要求側装置および応答側装置の認証に関する処理を行う第三者機関装置（ＩｄＰ）とで構成され、要求側装置と応答側装置との間で確立されるセッションを暗号化するセッション鍵を、要求側装置と応答側装置との間でセッションの確立前に共有することを概要とし、エンドエンドでの認証が予め確保されていることを前提とせずに、セッション鍵を共有（転送、交換）することを主たる特徴とする。

この主たる特徴について簡単に説明すると、実施例１に係るセッション鍵共有システムを構成するＩｄＰは、図１に示すように、認証情報保持部（特許請求の範囲に記載の「認証情報保持手段」に対応する）において、ＵＡＣ−１およびＵＡＣ−２の各々の認証に用いる認証情報を保持している（図１の（１）を参照）。例えば、ＩｄＰは、認証情報保持部において、ユーザアカウントとＩＤとパスワードとを対応づけて保持している。なお、実施例１においては、ユーザアカウントとＩＤとパスワードとを対応づけて保持する手法を説明するが、本発明はこれに限られるものではなく、ＩｄＰがＵＡＣ−１およびＵＡＣ−２の各々の認証に用いる認証情報であれば、保持する情報の種類や保持する形態などはいずれでもよい。

このような構成のもと、実施例１におけるＵＡＣ−１は、ＵＡＣ−１を認証することを要求する認証要求をＩｄＰに送信する（図１の（２）を参照）。また、実施例１におけるＵＡＣ−２は、ＵＡＣ−２を認証することを要求する認証要求をＩｄＰに送信する（図１の（３）を参照）。

すると、ＩｄＰは、ＵＡＣ−１およびＵＡＣ−２を認証することを要求する認証要求の各々を、ＵＡＣ−１およびＵＡＣ−２の各々から受信すると、認証情報保持部によって保持された認証情報を用いて、ＵＡＣ−１およびＵＡＣ−２の各々を認証する（図１の（４）を参照）。例えば、ＩｄＰは、ＵＡＣ−１にＩＤおよびパスワードを送信させ、認証情報保持部によってＵＡＣ−１に対応づけられて保持されたＩＤおよびパスワードと、受信したＩＤおよびパスワードとを照合することで、ＵＡＣ−１を認証する。

そして、ＩｄＰは、ＵＡＣ−１およびＵＡＣ−２の各々による認証要求が認証された結果が成功の場合に、ＵＡＣ−１とＵＡＣ−２との間でセッション鍵を共有させるように、セッション鍵をＵＡＣ−２に送信（手法によっては、ＵＡＣ−１に送信、ＵＡＣ−１およびＵＡＣ−２に送信）する（図１の（５）を参照）。

なお、上記した内容は、本発明に係るセッション鍵共有システムの主たる特徴を説明するものであり、セッション鍵共有システムによる具体的な処理の手順を示すものではない。セッション鍵共有システムの具体的な処理の手順については、後に詳述する。

このようにして、実施例１に係るセッション鍵共有システムは、エンドエンドでの認証が予め確保されていることを前提とせずに、セッション鍵を共有（転送、交換）することが可能になる。

［実施例１に係るセッション鍵共有システムの構成］
次に、図２および図３を用いて、実施例１に係るセッション鍵共有システムの構成を説明する。図２は、実施例１に係るセッション鍵共有システムの構成を示すブロック図であり、図３は、認証情報保持部を説明するための図である。なお、本発明に係るセッション鍵共有システムは、図２に示すように、第三者機関装置３００（ＩｄＰ）と要求側装置１００（ＵＡＣ−１）と応答側装置２００（ＵＡＣ−２）とで構成されるものであるので、以下では、第三者機関装置３００（ＩｄＰ）、要求側装置１００（ＵＡＣ−１）、応答側装置２００（ＵＡＣ−２）を順に説明する。また、実施例１においては、要求側装置１００（ＵＡＣ−１）がセッション鍵を作成し、応答側装置２００（ＵＡＣ−２）にセッション鍵を取得させる事例について説明する。

［第三者機関装置３００（ＩｄＰ）］
第三者機関装置３００（ＩｄＰ）は、要求側装置１００（ＵＡＣ−１）および応答側装置２００（ＵＡＣ−２）の認証に関する処理を行う装置であり、特に本発明に密接に関連するものとしては、図２に示すように、通信部３１１と、記憶部３２０と、制御部３３０とを備える。

通信部３１１は、ＨＴＴＰＳ（Hypertext Transfer Protocol Security）通信用の一般的なライブラリを備え、要求側装置１００（ＵＡＣ−１）や応答側装置２００（ＵＡＣ−２）との間でＨＴＴＰＳによる通信を行う。具体的には、通信部３１１は、要求側装置１００（ＵＡＣ−１）および応答側装置２００（ＵＡＣ−２）から、要求側装置１００（ＵＡＣ−１）および応答側装置２００（ＵＡＣ−２）を認証することを要求する認証要求の各々をＨＴＴＰＳで受信したり、応答側装置２００（ＵＡＣ−２）にセッション鍵をＨＴＴＰＳで送信するなどする。

例えば、通信部３１１は、要求側装置１００（ＵＡＣ−１）および応答側装置２００（ＵＡＣ−２）から、認証要求をＨＴＴＰＳの「ＰＯＳＴ」メッセージに付加された形態で受信したり、応答側装置２００（ＵＡＣ−２）に対して、セッション鍵をＨＴＴＰＳの「２００ ＯＫ」メッセージに付加した形態で送信するなどする。

記憶部３２０は、制御部３３０による各種処理に用いるデータを記憶する記憶手段であり、特に本発明に密接に関連するものとしては、図２に示すように、認証情報保持部３２１を備える。なお、認証情報保持部３２１は、特許請求の範囲に記載の「認証情報保持手段」に対応する。

認証情報保持部３２１は、認証に用いる認証情報を保持する。具体的には、認証情報保持部３２１は、要求側装置１００（ＵＡＣ−１）および応答側装置２００（ＵＡＣ−２）の各々の認証に用いる認証情報を保持し、保持した認証情報は、後述する認証部３３１による処理に利用されるなどする。認証情報保持部３２１は、要求側装置１００（ＵＡＣ−１）や応答側装置２００（ＵＡＣ−２）など、複数の装置の認証情報を予め保持するものである。

例えば、認証情報保持部３２１は、図３に示すように、ユーザアカウントとＩＤとパスワードとを対応づけて保持している。なお、実施例１においては、ユーザアカウントとＩＤとパスワードとを対応づけて保持する手法を説明するが、本発明はこれに限られるものではなく、認証情報保持部３２１が要求側装置１００（ＵＡＣ−１）および応答側装置２００（ＵＡＣ−２）の各々の認証に用いる認証情報であれば、保持する情報の種類や保持する形態などはいずれでもよい。

制御部３３０は、第三者機関装置３００（ＩｄＰ）を制御して各種処理を実行する制御手段であり、特に本発明に密接に関連するものとしては、図２に示すように、認証部３３１と、セッション鍵取得情報送信部３３２と、セッション鍵共有部３３３とを備える。なお、認証部３３１は、特許請求の範囲に記載の「認証手段」に対応し、セッション鍵取得情報送信部３３２は、特許請求の範囲に記載の「セッション鍵取得情報送信手段」に対応し、セッション鍵共有部３３３は、特許請求の範囲に記載の「セッション鍵共有手段」に対応する。

認証部３３１は、認証要求の各々を受信すると、要求側装置１００（ＵＡＣ−１）および応答側装置２００（ＵＡＣ−２）を認証する。具体的には、認証部３３１は、要求側装置１００（ＵＡＣ−１）および応答側装置２００（ＵＡＣ−２）を認証することを要求する認証要求の各々を、要求側装置１００（ＵＡＣ−１）および応答側装置２００（ＵＡＣ−２）の各々から通信部３１１を介して受信すると、認証情報保持部３２１によって保持された認証情報を用いて、要求側装置１００（ＵＡＣ−１）および応答側装置２００（ＵＡＣ−２）を認証し、認証した結果を後述するセッション鍵共有部３３２に送信するなどする。

例えば、認証部３３１は、要求側装置１００（ＵＡＣ−１）にＩＤおよびパスワードを送信させ、認証情報保持部３２１によって要求側装置１００（ＵＡＣ−１）に対応づけられて保持されたＩＤおよびパスワードと、受信したＩＤおよびパスワードとを照合することで、要求側装置１００（ＵＡＣ−１）を認証する。

セッション鍵取得情報送信部３３２は、セッション鍵を取得するための情報であるセッション鍵取得情報を送信する。具体的には、セッション鍵取得情報送信部３３２は、応答側装置２００（ＵＡＣ−２）にセッション鍵を取得させる要求側装置１００（ＵＡＣ−１）に、セッション鍵取得情報を送信する。例えば、セッション鍵取得情報送信部３３２は、セッション鍵取得情報を、ＳＡＭＬ（Security Assertion Markup Language）で規定されるような形式に記述して、例えば、ＨＴＴＰＳの「２００ ＯＫ」メッセージに付加した形態で、通信部３１１を介して要求側装置１００（ＵＡＣ−１）に送信する。

セッション鍵共有部３３３は、認証要求が認証された結果が成功の場合に、要求側装置１００（ＵＡＣ−１）と応答側装置２００（ＵＡＣ−２）との間でセッション鍵を共有させるように、セッション鍵を送信する。具体的には、セッション鍵共有部３３３は、要求側装置１００（ＵＡＣ−１）および応答側装置２００（ＵＡＣ−２）の各々による認証要求が認証部３３１によって認証された結果が成功の場合に、要求側装置１００（ＵＡＣ−１）と応答側装置２００（ＵＡＣ−２）との間でセッション鍵を共有させるように、応答側装置２００（ＵＡＣ−２）にセッション鍵を送信する。

例えば、セッション鍵共有部３３３は、応答側装置２００（ＵＡＣ−２）からセッション鍵取得情報を受信すると、セッション鍵取得情報によって取得することが可能なセッション鍵を、ＨＴＴＰＳの「２００ ＯＫ」メッセージに付加した形態で、応答側装置２００（ＵＡＣ−２）に送信する。

［要求側装置１００（ＵＡＣ−１）］
要求側装置１００（ＵＡＣ−１）は、後述する応答側装置２００（ＵＡＣ−２）との間でセッションを確立することを要求する装置であり、特に本発明に密接に関連するものとしては、図２に示すように、入出力部１１１と、通信部１１２と、記憶部１２０と、制御部１３０とを備える。

入出力部１１１は、要求側装置１００（ＵＡＣ−１）においてＩＤやパスワードをキーボードなどで入力する入力手段や、セッション鍵共有に関する処理の結果をディスプレイなどに出力する出力手段などである。

通信部１１２は、ＨＴＴＰＳ（Hypertext Transfer Protocol Security）通信用の一般的なライブラリや、ＳＩＰ（Session Initiation Protocol）通信用の一般的なライブラリを備え、第三者機関装置３００（ＩｄＰ）との間でＨＴＴＰＳによる通信を行ったり、応答側装置２００（ＵＡＣ−２）との間でＳＩＰによる通信を行う。具体的には、通信部１１２は、要求側装置１００（ＵＡＣ−１）を認証することを要求する認証要求をＨＴＴＰＳで第三者機関装置３００（ＩｄＰ）に送信したり、セッション鍵取得情報などをＳＩＰで応答側装置２００（ＵＡＣ−２）に送信するなどする。

例えば、通信部１１２は、第三者機関装置３００（ＩｄＰ）に対して、認証要求を、例えば、ＨＴＴＰＳの「ＰＯＳＴ」メッセージに付加した形態で送信したり、応答側装置２００（ＵＡＣ−２）に対して、第三者機関装置３００（ＩｄＰ）から受信したセッション鍵取得情報を、例えば、ＳＩＰの「ＩＮＶＩＴＥ」メッセージに付加した形態で送信するなどする。

記憶部１２０は、制御部１３０による各種処理に用いるデータを記憶する記憶手段であり、特に本発明に密接に関連するものとしては、図２に示すように、セッション鍵保持部１２１を備える。

セッション鍵保持部１２１は、セッションを暗号化するセッション鍵を保持する。具体的には、セッション鍵保持部１２１は、要求側装置１００（ＵＡＣ−１）と応答側装置２００（ＵＡＣ−２）との間で確立されるセッションを暗号化するセッション鍵であって、本発明に係るセッション鍵共有システムによって要求側装置１００（ＵＡＣ−１）と応答側装置２００（ＵＡＣ−２）との間で共有されたセッション鍵を保持し、保持したセッション鍵は、要求側装置１００（ＵＡＣ−１）と応答側装置２００（ＵＡＣ−２）との間でセッションが確立された後、後述する暗号化部１３３による処理などに利用される。

制御部１３０は、要求側装置１００（ＵＡＣ−１）を制御して各種処理を実行する制御手段であり、特に本発明に密接に関連するものとしては、図２に示すように、認証要求送信部１３１と、セッション鍵取得情報転送部１３２と、暗号化部１３３とを備える。なお、認証要求送信部１３１は、特許請求の範囲に記載の「認証要求送信手段」に対応し、セッション鍵取得情報転送部１３２は、特許請求の範囲に記載の「セッション鍵取得情報転送手段」に対応する。

認証要求送信部１３１は、認証要求を送信する。具体的には、認証要求送信部１３１は、要求側装置１００（ＵＡＣ−１）を認証することを要求する認証要求を、第三者機関装置３００（ＩｄＰ）に対して通信部１１２を介して送信する。例えば、認証要求送信部１３１は、認証要求をＨＴＴＰＳの「ＰＯＳＴ」メッセージに付加した形態で第三者機関装置３００（ＩｄＰ）に対して送信する。

セッション鍵取得情報転送部１３２は、セッション鍵取得情報を応答側装置２００（ＵＡＣ−２）に送信する。具体的には、第三者機関装置３００（ＩｄＰ）によって送信されたセッション鍵取得情報を、セッションを確立するに際して必要とされる信号に付加した形態で、応答側装置２００（ＵＡＣ−２）に送信する。例えば、セッション鍵取得情報転送部１３２は、ＳＡＭＬ規定されるような形式に記述されたセッション鍵取得情報を、例えば、ＳＩＰの「ＩＮＶＩＴＥ」メッセージに付加した形態で、通信部１１２を介して応答側装置２００（ＵＡＣ−２）に送信する。

暗号化部１３３は、セッション鍵を用いてセッションを暗号化する。具体的には、暗号化部１３３は、セッション鍵保持部１２１によって保持されたセッション鍵を用いて、要求側装置１００（ＵＡＣ−１）と応答側装置２００（ＵＡＣ−２）との間で確立されたセッションを暗号化する。暗号化部１３２によって暗号化されたセッションは、セキュリティを確保したセッション（セキュアセッション）となる。

［応答側装置２００（ＵＡＣ−２）］
応答側装置２００（ＵＡＣ−２）は、要求側装置１００（ＵＡＣ−１）の要求に応答して要求側装置１００（ＵＡＣ−１）との間でセッションを確立する装置であり、特に本発明に密接に関連するものとしては、図２に示すように、入出力部２１１と、通信部２１２と、記憶部２２０と、制御部２３０とを備える。

入出力部２１１は、応答側装置２００（ＵＡＣ−２）においてＩＤやパスワードをキーボードなどで入力する入力手段や、セッション鍵共有に関する処理の結果をディスプレイなどに出力する出力手段などである。

通信部２１２は、ＨＴＴＰＳ（Hypertext Transfer Protocol Security）通信用の一般的なライブラリや、ＳＩＰ（Session Initiation Protocol）通信用の一般的なライブラリを備え、第三者機関装置３００（ＩｄＰ）との間でＨＴＴＰＳによる通信を行ったり、要求側装置１００（ＵＡＣ−１）との間でＳＩＰによる通信を行う。具体的には、通信部２１２は、応答側装置２００（ＵＡＣ−２）を認証することを要求する認証要求をＨＴＴＰＳで第三者機関装置３００（ＩｄＰ）に送信したり、セッション鍵取得情報などをＳＩＰで要求側装置１００（ＵＡＣ−１）から受信するなどする。

例えば、通信部２１２は、第三者機関装置３００（ＩｄＰ）に対して、認証要求を、例えば、ＨＴＴＰＳの「ＰＯＳＴ」メッセージに付加した形態で送信したり、要求側装置１００（ＵＡＣ−１）に対して、セッション鍵の共有が完了したことを示すメッセージとして、例えば、ＳＩＰの「２００ ＯＫ」メッセージを送信するなどする。

記憶部２２０は、制御部２３０による各種処理に用いるデータを記憶する記憶手段であり、特に本発明に密接に関連するものとしては、図２に示すように、セッション鍵保持部２２１を備える。

セッション鍵保持部２２１は、セッションを暗号化するセッション鍵を保持する。具体的には、セッション鍵保持部２２１は、要求側装置１００（ＵＡＣ−１）と応答側装置２００（ＵＡＣ−２）との間で確立されるセッションを暗号化するセッション鍵であって、本発明に係るセッション鍵共有システムによって要求側装置１００（ＵＡＣ−１）と応答側装置２００（ＵＡＣ−２）との間で共有されたセッション鍵を保持し、保持したセッション鍵は、要求側装置１００（ＵＡＣ−１）と応答側装置２００（ＵＡＣ−２）との間でセッションが確立された後、後述する暗号化部２３３による処理などに利用される。

制御部２３０は、応答側装置２００（ＵＡＣ−２）を制御して各種処理を実行する制御手段であり、特に本発明に密接に関連するものとしては、図２に示すように、認証要求送信部２３１と、セッション鍵取得要求部２３２と、暗号化部２３３とを備える。なお、認証要求送信部２３１は、特許請求の範囲に記載の「認証要求送信手段」に対応し、セッション鍵取得要求部２３２は、特許請求の範囲に記載の「セッション鍵取得要求手段」に対応する。

認証要求送信部２３１は、認証要求を送信する。具体的には、認証要求送信部２３１は、応答側装置２００（ＵＡＣ−２）を認証することを要求する認証要求を、第三者機関装置３００（ＩｄＰ）に対して通信部２１２を介して送信する。例えば、認証要求送信部２３１は、認証要求をＨＴＴＰＳの「ＰＯＳＴ」メッセージに付加した形態で第三者機関装置３００（ＩｄＰ）に対して送信する。

セッション鍵取得要求送信部２３２は、セッション鍵取得情報によって取得することが可能なセッション鍵の取得を第三者機関装置３００（ＩｄＰ）に要求する。具体的には、セッション鍵取得要求送信部２３２は、要求側装置１００（ＵＡＣ−１）から転送されたセッション鍵取得情報を受信すると、セッション鍵取得情報を第三者機関装置３００（ＩｄＰ）に送信することで、セッション鍵取得情報によって取得することが可能なセッション鍵の取得を第三者機関装置３００（ＩｄＰ）に要求する。

例えば、セッション鍵取得要求送信部２３２は、ＳＡＭＬ規定されるような形式に記述されたセッション鍵取得情報を、例えば、ＨＴＴＰの「ＰＯＳＴ」メッセージに付加した形態で、通信部２１２を介して第三者機関装置３００（ＩｄＰ）に送信する。

暗号化部２３３は、セッション鍵を用いてセッションを暗号化する。具体的には、暗号化部２３３は、セッション鍵保持部２２１によって保持されたセッション鍵を用いて、要求側装置１００（ＵＡＣ−１）と応答側装置２００（ＵＡＣ−２）との間で確立されたセッションを暗号化する。暗号化部２３３によって暗号化されたセッションは、セキュリティを確保したセッション（セキュアセッション）となる。

［実施例１に係るセッション鍵共有システムによる処理の手順］
次に、図４を用いて、実施例１に係るセッション鍵共有システムによる処理の手順を説明する。図４は、実施例１に係るセッション鍵共有システムによる処理の手順を示すシーケンス図である。なお、実施例１は、ＵＡＣ−１とＵＡＣ−２とが、セッション鍵として、対称鍵（共通鍵）を共有する事例であるので、以下では、セッション鍵に関する情報が「ＳＩＰプロキシ」を経由する場合には、通信路において盗聴されないようにすること（暗号化すること）と、受信したセッション鍵が確かに通信相手のＵＡＣから取得したセッション鍵であることを確認できることとを、必須条件としなければならないと考える。

このため、以下では、ＩｄＰは、セッション鍵取得情報をＩｄＰ自身が保持する鍵で暗号化することで、セッション鍵取得情報を通信路において盗聴されないようにしている。また、ＩｄＰは、セッション鍵取得情報を、ＳＡＭＬ（Security Assertion Markup Language）に規定するような形式で記述している。ここで、ＳＡＭＬ形式とは、認証のための情報をＸＭＬ（Extensible Markup Language）で記述されたデータで交換することを目的として策定されたプロトコルであり、電子署名によって検証が可能な形式である。すなわち、ＩｄＰは、セッション鍵取得情報をＳＡＭＬ形式で記述し、ＩｄＰの秘密鍵で署名をすることで、受信したセッション鍵取得情報が確かにＩｄＰ自身によって発行されたセッション鍵取得情報であること（改竄もないこと）を確認できることを保証するようにしており、ひいては、セッション鍵を受信したＵＡＣが、確かに通信相手のＵＡＣから取得したセッション鍵であることを確認できることを保証するようにしている。また、ＩｄＰは、ＵＡＣ−１およびＵＡＣ−２の各々の認証に用いる認証情報を予め保持している。

まず、ＵＡＣ−１は、ＵＡＣ−２との間で確立されるセッションを暗号化するセッション鍵を作成する（ステップＳ４０１）。具体的には、ＵＡＣ−１は、ＵＡＣ−２との間で確立されるセッションを暗号化する対称鍵を作成する。

次に、ＵＡＣ−１は、ＩｄＰに対して、「ＵＡＣ−２との間でセッションを確立することを指定するとともに、ＵＡＣ−１を認証することを要求する認証要求」を送信する（ステップＳ４０２）。具体的には、実施例１においては、ＵＡＣ−１においてセッション鍵が作成されるので（ステップＳ４０１を参照）、ＵＡＣ−１は、ＩｄＰに対して、認証要求とセッション鍵とを、例えば、ＨＴＴＰＳ（Hypertext Transfer Protocol Security）の「ＰＯＳＴ」メッセージに付加した形態で送信する。

すると、ＩｄＰは、「ＵＡＣ−２との間でセッションを確立することを指定するとともに、ＵＡＣ−１を認証することを要求する認証要求」をＵＡＣ−１から受信すると、ＵＡＣ−１を認証するとともに、セッション鍵取得情報（セッション鍵を取得するための情報）をセッションを確立するに際して必要とされる信号に付加した形態で、ＵＡＣ−１に送信する（ステップＳ４０３）。具体的には、実施例１においては、ＩｄＰは、認証要求とセッション鍵とをＵＡＣ−１から受信するので、ＵＡＣ−１を、保持する認証情報を用いて認証するとともに、ＵＡＣ−１から受信したセッション鍵を取得するための情報を、ＳＡＭＬで規定されるような形式に記述して、例えば、ＨＴＴＰＳの「２００ ＯＫ」メッセージに付加した形態で、ＵＡＣ−１に送信する。また、実施例１においては、ＩｄＰは、セッション鍵取得情報をＩｄＰ自身が保持する鍵で暗号化している。

続いて、ＵＡＣ−１は、ＵＡＣ−２に対して、ＩｄＰから受信したセッション鍵取得情報を、セッションを確立するに際して必要とされる信号に付加した形態で転送する（ステップＳ４０４）。具体的には、ＵＡＣ−１は、ＵＡＣ−２に対して、ＩｄＰから受信したセッション鍵取得情報（ＳＡＭＬで規定されるような形式で記述された情報であって、ＵＡＣ−１で作成したセッション鍵を取得するための情報）を、例えば、ＳＩＰの「ＩＮＶＩＴＥ」メッセージに付加した形態で、転送する。なお、この「ＩＮＶＩＴＥ」メッセージは、図４に示すように、ＳＩＰプロキシを経由することになる。

次に、ＵＡＣ−２は、ＩｄＰに対して、セッション鍵取得情報を送信する（ステップＳ４０５）。具体的には、実施例１においては、ＵＡＣ−２は未だＩｄＰによって認証されていないので、ＵＡＣ−２は、ＩｄＰに対して、認証要求（ＵＡＣ−２を認証することを要求する認証要求）とセッション鍵に関する情報（ＳＡＭＬで規定されるような形式で記述された情報であって、ＵＡＣ−１で作成したセッション鍵を取得するための情報）とを、例えば、ＨＴＴＰＳの「ＰＯＳＴ」メッセージに付加した形態で送信する。

すると、ＩｄＰは、セッション鍵取得情報をＵＡＣ−２から受信すると、このセッション鍵取得情報によって取得することが可能なセッション鍵を、ＵＡＣ−２に送信する（ステップＳ４０６）。具体的には、実施例１においては、ＩｄＰは、認証要求とセッション鍵取得情報とをＵＡＣ−２から受信するので、ＵＡＣ−２を、保持する認証情報を用いて認証するとともに、ＵＡＣ−２から受信したセッション鍵取得情報によって取得することが可能なセッション鍵を、例えば、ＨＴＴＰＳの「２００ ＯＫ」メッセージに付加した形態で、ＵＡＣ−２に送信する。なお、実施例１においては、ＩｄＰは、ステップＳ４０５に続き、ＳＡＭＬの署名を検証することで、セッション鍵取得情報が確かにＩｄＰ自身によって発行されたセッション鍵取得情報であることを確認するなどしている。また、ＩｄＰは、ＩｄＰ自身が保持する鍵によって暗号化されたセッション鍵取得情報を復号することで、セッション鍵を取り出すなどしている。

こうして、ＵＡＣ−１とＵＡＣ−２との間でセッション鍵を共有することができたので、その後、ＵＡＣ−２は、ＵＡＣ−１に対して、例えば、ＳＩＰの「２００ ＯＫ」メッセージを送信し（ステップＳ４０７）、ＵＡＣ−１は、ＵＡＣ−２に対して、例えば、ＳＩＰの「ＡＣＫ」メッセージを送信するなどして（ステップＳ４０８）、ＵＡＣ−１とＵＡＣ−２との間でセッションが確立される（ステップＳ４０９）。

なお、実施例１においては、「セッション鍵取得情報」とは、ＩｄＰがＵＡＣ−２に取得させるべきセッション鍵を識別するための識別情報を含む場合や、ＵＡＣ−２がセッション鍵の正当な受取り者であることを確認するための識別情報を含む場合、セッション鍵そのものをＩｄＰ内で保持する鍵で暗号化した情報を含む場合などが考えられる。なお、「セッション鍵取得情報」が、セッション鍵そのものをＩｄＰ内で保持する鍵で暗号化した情報を含む場合には、上記したように、ＩｄＰは、ＵＡＣ−２から暗号化されたセッション鍵を受信すると、受信したセッション鍵を復号することでセッション鍵を取り出し、取り出したセッション鍵をＵＡＣ−２に送信することになる。この結果、ＩｄＰは、セッション鍵を管理するデータベースを不要とすることができる。

また、実施例１においては、ＩｄＰが、セッション鍵取得情報をＩｄＰ自身が保持する鍵で暗号化することで、セッション鍵取得情報を通信路において盗聴されないようにし、ＩｄＰが、セッション鍵取得情報をＳＡＭＬ形式で記述し、ＩｄＰの秘密鍵で署名をし、ＩｄＰが署名を検証することで、受信したセッション鍵取得情報が確かにＩｄＰ自身によって発行されたセッション鍵取得情報であることを確認できることを保証する手法について説明してきたが、本発明はこれに限られるものではない。例えば、セッション鍵取得情報の暗号化について、ＩｄＰとＵＡＣ−２との間で事前に共有の秘密鍵が交換されている場合や、ＵＡＣ−２の公開鍵をＩｄＰが事前に保持している場合には、ＩｄＰが、セッション鍵取得情報をこれらの鍵を用いて暗号化することで、セッション鍵取得情報を通信路において盗聴されないようにする手法などにも、本発明を同様に適用することができる。また、セッション鍵取得情報の署名について、ＵＡＣ−２がＩｄＰの公開鍵を事前に取得している場合や、公開鍵証明書を検証することで信頼性を確認することが可能な場合には、ＵＡＣ−２自身で署名の検証をすることで、受信したセッション鍵取得情報が確かにＩｄＰ自身によって発行されたセッション鍵取得情報であることを確認できることを保証する手法などにも、本発明を同様に適用することができる。

［実施例１の効果］
上記してきたように、実施例１によれば、セッションを確立することを要求する要求側装置と、要求に応答して要求側装置との間でセッションを確立する応答側装置と、要求側装置および応答側装置の認証に関する処理を行う第三者機関装置とで構成され、セッションを暗号化するセッション鍵を、互いを通信相手とする要求側装置と応答側装置との間でセッションの確立前に共有するセッション鍵共有システムであって、第三者機関装置は、要求側装置および応答側装置の各々の認証に用いる認証情報を保持し、要求側装置および応答側装置を認証することを要求する認証要求の各々を要求側装置および応答側装置の各々から受信すると、保持された認証情報を用いて要求側装置および応答側装置の各々を認証し、要求側装置および応答側装置の各々による認証要求が認証された結果が成功の場合に、要求側装置と応答側装置との間でセッション鍵を共有させるように、セッション鍵を要求側装置および／または応答側装置に送信し、要求側装置は、要求側装置を認証することを要求する認証要求を第三者機関装置に対して送信し、応答側装置は、応答側装置を認証することを要求する認証要求を第三者機関装置に対して送信するので、エンドエンドでの認証が予め確保されていることを前提とせずに、セッション鍵を共有（転送、交換）することが可能になる。

言い換えると、公開鍵を持たない要求側装置や応答側装置などのエンドユーザ装置間で、セッション鍵を共有することが可能になる。また、セッション鍵としてＤＨなどの非対称鍵を共有する事例においても、エンドユーザ装置がＳ／ＭＩＭＥなどによってＳＩＰ通信を暗号化する必要がなくなることから、エンドユーザ装置にインストールされるクライアントプログラムへの負荷を軽減することも可能になる。さらに、要求側装置や応答側装置などのエンドユーザ装置側は、各々一つの第三者機関装置にアカウント（認証情報）が保持されているだけで、任意のエンドユーザ装置とセッション鍵を共有することが可能になる。

また、第三者機関装置との間における認証が強固であるという環境においては、同時に、セッション鍵を共有した後に確立されるセッションのセキュリティ確保のレベル（安全性）についても、第三者機関装置との間における強固な認証と同等のレベルにすることが可能になる。

また、実施例１によれば、第三者機関装置は、通信相手にセッション鍵を取得させる要求側装置および／または応答側装置に、セッション鍵を取得するための情報であるセッション鍵取得情報を送信し、通信相手にセッション鍵を取得させる要求側装置および／または応答側装置は、送信されたセッション鍵取得情報を、セッションを確立するに際して必要とされる信号に付加した形態で通信相手に転送し、セッション鍵を取得する要求側装置および／または応答側装置は、通信相手から転送されたセッション鍵取得情報を受信すると、セッション鍵取得情報を第三者機関装置に送信することで、セッション鍵取得情報によって取得することが可能なセッション鍵の取得を第三者機関装置に要求し、送信されたセッション鍵取得情報を受信すると、セッション鍵取得情報によって取得することが可能なセッション鍵を、セッション鍵取得情報を送信した要求側装置および／または応答側装置に送信ので、セッション鍵を取得するための情報を、セッションを確立するに際して必要とされる信号として、例えば、既存のＳＩＰ（Session Initiation Protocol）信号にのせることで、簡易にセッション鍵を共有（転送、交換）することが可能になる。

また、実施例１によれば、要求側装置および／または応答側装置で作成されたセッション鍵を共有させるので、エンドエンドでの認証が予め確保されていることを前提とせずに、要求側装置や応答側装置で作成されたセッション鍵を共有することが可能になる。

ところで、これまで実施例１として、要求側装置と応答側装置とが、セッション鍵として、対称鍵（共通鍵）を共有する事例について説明したが、本発明はこれに限られるものではなく、セッション鍵として、非対称鍵（ＲＳＡ（Rivest Shamir Adleman）やＤＨ（Diffie-Hellman）などの公開鍵）を共有する事例にも、本発明を同様に適用することができる。そこで、以下では、実施例２として、セッション鍵として、非対称鍵を共有する事例について説明する。

なお、実施例２に係るセッション鍵共有システムは、実施例１におけるセッション鍵共有システムとほぼ同様に構成され、要求側装置が実施例１における応答側装置と同様の処理をさらに行い、応答側装置が実施例１における要求側装置と同様の処理をさらに行う点について、実施例１と異なるものである。以下では、実施例２に係るセッション鍵共有システムによる処理の手順および実施例２の効果についてのみ説明する。

［実施例２に係るセッション鍵共有システムによる処理の手順］
図５を用いて、実施例２に係るセッション鍵共有システムによる処理の手順を説明する。図５は、実施例２に係るセッション鍵共有システムによる処理の手順を示すシーケンス図である。なお、実施例２は、ＵＡＣ−１とＵＡＣ−２とが、セッション鍵として、非対称鍵（公開鍵）を共有する事例であるので、以下では、セッション鍵に関する情報が「ＳＩＰプロキシ」を経由する場合には、通信路において盗聴されないようにすること（暗号化すること）は必須条件ではないが、受信したセッション鍵が確かに通信相手のＵＡＣから取得したセッション鍵であることを確認できることを必須条件としなければならないと考える。このため、以下では、ＩｄＰは、実施例１と異なり、セッション鍵取得情報をＩｄＰ自身が保持する鍵で暗号化することはしないが、実施例１と同様、セッション鍵取得情報をＳＡＭＬ形式で記述し、ＩｄＰの秘密鍵で署名をしている。

また、実施例２に係るセッション鍵共有システムによる処理の手順は、実施例１に係るセッション鍵共有システムによる処理の手順（図４を参照）と比較すると、セッション鍵として、非対称鍵（セッション鍵−１がＵＡＣ−２に取得され、セッション鍵−２がＵＡＣ−１に取得されることで、同一のセッション鍵がＵＡＣ−１とＵＡＣ−２とで共有されることになる）を共有する事例であることから、実施例１と同様に、ＵＡＣ−１で作成されたセッション鍵がＵＡＣ−２において取得される処理（ステップＳ５０１〜Ｓ５０７）と、かかる処理と対比するようにして、ＵＡＣ−２で作成されたセッション鍵がＵＡＣ−１において取得される処理（ステップＳ５０５〜Ｓ５１０）とがある。このため、以下では、実施例１と重複する処理については、簡潔に説明することとする。

まず、ＵＡＣ−１は、実施例１と同様、ＵＡＣ−２との間で確立されるセッションを暗号化するセッション鍵（セッション鍵−１）を作成し（ステップＳ５０１）、次に、ＵＡＣ−１は、実施例１と同様、ＩｄＰに対して、認証要求とセッション鍵−１とをＨＴＴＰＳの「ＰＯＳＴ」メッセージに付加した形態で送信し（ステップＳ５０２）、すると、ＩｄＰは、実施例１と同様、ＵＡＣ−１を認証するとともに、ＵＡＣ−１から受信したセッション鍵−１取得情報をＳＡＭＬで規定されるような形式に記述して、ＨＴＴＰＳの「２００ ＯＫ」メッセージに付加した形態でＵＡＣ−１に送信し（ステップＳ５０３）、続いて、ＵＡＣ−１は、実施例１と同様、ＵＡＣ−２に対して、ＩｄＰから受信したセッション鍵−１取得情報をＳＩＰの「ＩＮＶＩＴＥ」メッセージに付加した形態で転送する（ステップＳ５０４）。

ところで、実施例２においては、ここから、ＵＡＣ−２で作成されたセッション鍵がＵＡＣ−１において取得される処理が開始される。すなわち、ＵＡＣ−２は、ＵＡＣ−１との間で確立されるセッションを暗号化するセッション鍵（セッション鍵−２）を作成する（ステップＳ５０５）。

次に、ＵＡＣ−２は、実施例１と同様、ＩｄＰに対して、認証要求（ＵＡＣ−２を認証することを要求する認証要求）とセッション鍵−１取得情報（ＳＡＭＬで規定されるような形式で記述された情報であって、ＵＡＣ−１で作成したセッション鍵−１を取得するための情報）とを送信する他に、実施例１と異なり、実施例２においては、ＵＡＣ−２においてセッション鍵−２が作成されるので（ステップＳ５０５を参照）、セッション鍵−２をも、例えば、ＨＴＴＰＳの「ＰＯＳＴ」メッセージに付加した形態で送信する（ステップＳ５０６）。

すると、ＩｄＰは、実施例１と同様、認証要求とセッション鍵−１取得情報とをＵＡＣ−２から受信するので、ＵＡＣ−２を認証するとともに、ＵＡＣ−２から受信したセッション鍵−１取得情報で指定されるセッション鍵−１をＵＡＣ−２に送信する他に、実施例１と異なり、実施例２においては、ＩｄＰは、セッション鍵−２をＵＡＣ−２から受信するので（ステップＳ５０６を参照）、ＵＡＣ−２から受信したセッション鍵−２取得情報を、ＳＡＭＬで規定されるような形式に記述して、例えば、ＨＴＴＰＳの「２００ ＯＫ」メッセージに付加した形態で、ＵＡＣ−２に送信する（ステップＳ５０７）。この段階で、ＵＡＣ−２は、セッション鍵−１を取得したことになる。なお、実施例２においても、実施例１と同様、ＩｄＰは、ステップＳ５０６に続き、ＳＡＭＬの署名を検証することで、セッション鍵−１取得情報が確かにＩｄＰ自身によって発行されたセッション鍵−１取得情報であることを確認するなどしている。

続いて、ＵＡＣ−２は、実施例１と異なり、ＵＡＣ−１に対して、ＩｄＰから受信したセッション鍵−２に関する情報を、セッションを確立するに際して必要とされる信号のいずれかに付加した形態で転送する（ステップＳ５０８）。具体的には、ＵＡＣ−２は、ＵＡＣ−１に対して、ＩｄＰから受信したセッション鍵−２取得情報を、例えば、ＳＩＰの「２００ ＯＫ」メッセージに付加した形態で転送する。なお、この「２００ ＯＫ」メッセージは、図５に示すように、ＳＩＰプロキシを経由することになる。

次に、ＵＡＣ−１は、ＩｄＰに対して、セッション鍵−２取得情報を送信する（ステップＳ５０９）。具体的には、実施例２においては、セッション鍵−２取得情報を、例えば、ＨＴＴＰＳの「ＰＯＳＴ」メッセージに付加した形態で送信する。

すると、ＩｄＰは、セッション鍵−２取得情報をＵＡＣ−１から受信すると、このセッション鍵−２取得情報によって取得することが可能なセッション鍵−２を、ＵＡＣ−１に送信する（ステップＳ５１０）。具体的には、ＵＡＣ−１から受信したセッション鍵−２取得情報によって取得することが可能なセッション鍵−２を、例えば、ＨＴＴＰＳの「２００ ＯＫ」メッセージに付加した形態で、ＵＡＣ−１に送信する。なお、実施例２においては、ＩｄＰは、ステップＳ５０９に続き、ＳＡＭＬの署名を検証することで、セッション鍵−２取得情報が確かにＩｄＰ自身によって発行されたセッション鍵−２取得情報であることを確認するなどしている。

こうして、セッション鍵−１がＵＡＣ−２に取得され、セッション鍵−２がＵＡＣ−１に取得されることで、同一のセッション鍵をＵＡＣ−１とＵＡＣ−２との間で共有することができたので、その後、ＵＡＣ−１は、ＵＡＣ−２に対して、例えば、ＳＩＰの「ＡＣＫ」メッセージを送信するなどして（ステップＳ５１１）、ＵＡＣ−１とＵＡＣ−２との間でセッションが確立される（ステップＳ５１２）。

なお、実施例２においては、ＩｄＰが、セッション鍵取得情報をＳＡＭＬ形式で記述し、ＩｄＰの秘密鍵で署名をし、ＩｄＰが署名を検証することで、受信したセッション鍵取得情報が確かにＩｄＰ自身によって発行されたセッション鍵取得情報であることを確認できることを保証する手法について説明してきたが、本発明はこれに限られるものではない。例えば、ＵＡＣ−１やＵＡＣ−２がＩｄＰの公開鍵を事前に取得している場合や、公開鍵証明書を検証することで信頼性を確認することが可能な場合には、ＵＡＣ−１やＵＡＣ−２自身で署名の検証をすることで、受信したセッション鍵取得情報が確かにＩｄＰ自身によって発行されたセッション鍵取得情報であることを確認できることを保証する手法などにも、本発明を同様に適用することができる。

また、実施例２においては、ＩｄＰが、暗号化されたセッション鍵−１（あるいは暗号化されたセッション鍵−２）をＵＡＣ−２（あるいはＵＡＣ−１）から受信し、復号したセッション鍵−１（あるいは復号したセッション鍵−２）をＵＡＣ−２（あるいはＵＡＣ−１）に送信する手法について説明したが、本発明はこれに限られるものではない。例えば、ＩｄＰが、セッション鍵−１取得情報（あるいはセッション鍵−２取得情報）として署名情報をＵＡＣ−２（あるいはＵＡＣ−１）から受信し、署名情報を検証し、検証した結果のみをＵＡＣ−２（あるいはＵＡＣ−１）に送信する手法にも、本発明を同様に適用することができる。すなわち、実施例２は、ＵＡＣ−１とＵＡＣ−２とが、セッション鍵として、非対称鍵（公開鍵）を共有する事例であるので、セッション鍵を通信路において盗聴されないようにすること（暗号化すること）は必須条件ではない。とすると、実施例２におけるＵＡＣ−２（あるいはＵＡＣ−１）は、セッション鍵−１（あるいはセッション鍵−２）をそのまま取得することができ、ＩｄＰは、署名情報を検証するのみでもよいことになる。

［実施例２の効果］
上記してきたように、実施例２によれば、実施例１と同様、エンドエンドでの認証が予め確保されていることを前提とせずに、セッション鍵を共有（転送、交換）することが可能になる。

ところで、これまで実施例１および２として、セッション鍵共有システムにおいて第三者機関装置が一つの装置で構成される事例について説明したが、本発明はこれに限られるものではなく、第三者機関装置が複数の装置で構成される事例（要求側装置と応答側装置とが異なる第三者機関装置に所属している事例）にも、本発明を同様に適用することができる。そこで、以下では、実施例３として、第三者機関装置が二つの装置で構成される事例について説明する。

なお、実施例３に係るセッション鍵共有システムは、実施例１および２におけるセッション鍵共有システムとほぼ同様に構成され、第三者機関装置が二つの装置で構成される点について、実施例１および２と異なるものである。以下では、実施例３に係るセッション鍵共有システムによる処理の手順および実施例３の効果についてのみ説明する。

［実施例３に係るセッション鍵共有システムによる処理の手順］
図６および７を用いて、実施例３に係るセッション鍵共有システムによる処理の手順を説明する。図６および７は、実施例３に係るセッション鍵共有システムによる処理の手順を示すシーケンス図である。なお、図６は、要求側装置と応答側装置とが、セッション鍵として、対称鍵（共通鍵）を共有する事例であり、図７は、セッション鍵として、非対称鍵（公開鍵）を共有する事例である。

また、実施例３に係るセッション鍵共有システムによる処理の手順は、実施例１に係るセッション鍵共有システムによる処理の手順（図４を参照）および実施例２に係るセッション鍵共有システムによる処理の手順（図５を参照）とそれぞれ比較すると、ＩｄＰが、ＩｄＰ−１とＩｄＰ−２との二つの装置で構成される点と、ＩｄＰにおけるＳＡＭＬ検証の処理（ステップＳ６０６、Ｓ７０７およびＳ７１１）が追加されている点とが異なる。このため、以下では、実施例１および２と重複する処理については、簡潔に説明することとする。

図６（対称鍵を共有する事例）について説明すると、ＩｄＰ−１は、ＵＡＣ−１を認証する認証情報を予め保持しており、ＩｄＰ−２は、ＵＡＣ−２を認証する認証情報を予め保持しているものとする。また、ＩｄＰ−１とＩｄＰ−２との間では、互いの公開鍵が予め交換されるなどして、認証が予め確保された状態である（ＩｄＰ−１とＩｄＰ−２とは信頼関係にある）。

まず、ＵＡＣ−１は、実施例１と同様、ＵＡＣ−２との間で確立されるセッションを暗号化する対称鍵を作成し（ステップＳ６０１）、次に、ＵＡＣ−１は、実施例１と同様、自らが登録されているＩｄＰ−１に対して、認証要求とセッション鍵とを、ＨＴＴＰＳの「ＰＯＳＴ」メッセージに付加した形態で送信する（ステップＳ６０２）。

すると、ＩｄＰ−１は、実施例１と同様、ＵＡＣ−１を認証するとともに、ＵＡＣ−１から受信したセッション鍵を取得するための情報（セッション鍵取得情報）を、ＳＡＭＬで規定されるような形式に記述して、ＨＴＴＰＳの「２００ ＯＫ」メッセージに付加した形態でＵＡＣ−１に送信するが、実施例１と異なり、セッション鍵取得情報をＩｄＰ−１の秘密鍵で署名するとともに、ＵＡＣ−２が所属するＩｄＰ−２の公開鍵を用いてセッション鍵取得情報を暗号化した上で、ＵＡＣ−１に送信する（ステップＳ６０３）。

続いて、ＵＡＣ−１は、実施例１と同様、ＵＡＣ−２に対して、ＩｄＰから受信したセッション鍵取得情報を、ＳＩＰの「ＩＮＶＩＴＥ」メッセージに付加した形態で転送する（ステップＳ６０４）。

ここで、実施例３においては、ＵＡＣ−２は、ＩｄＰ−１に対して、セッション鍵取得情報を送信するのではなく、自らが登録されているＩｄＰ−２に対して、セッション鍵取得情報を送信する点で、実施例１と異なる。すなわち、ＵＡＣ−２は、ＩｄＰ−２に対して、セッション鍵取得情報を送信する（ステップＳ６０５）。具体的には、実施例３においては、ＵＡＣ−２は未だＩｄＰ−２によって認証されていないので、ＵＡＣ−２は、ＩｄＰ−２に対して、認証要求とセッション鍵取得情報とを、例えば、ＨＴＴＰＳの「ＰＯＳＴ」メッセージに付加した形態で送信する。

すると、実施例３においては、実施例１と異なり、ＩｄＰ−２において、ＳＡＭＬ検証の処理が行われる（ステップＳ６０６）。ここで、ＳＡＭＬ検証とは、例えば、実施例３においては、ＩｄＰ−１が、セッション鍵取得情報をＳＡＭＬ形式で記述し、ＩｄＰ−１の秘密鍵で署名しているので、ＩｄＰ−２は、この署名から、セッション鍵取得情報のハッシュ値を取り出す。一方で、ＩｄＰ−２は、取得したセッション鍵取得情報（ＩｄＰ−２の公開鍵で暗号化されたセッション鍵取得情報を、ＩｄＰ−２の秘密鍵で復号した情報）のハッシュ値を算出し、署名から取り出したハッシュ値と、算出したハッシュ値とを比較する。比較の結果、二つのハッシュ値が同一であれば、ＩｄＰ−２は、セッション鍵取得情報に関する事実として、確かに、ＩｄＰ−１から発行されたセッション鍵取得情報であること（セッション鍵取得情報がＩｄＰ−１によって保証されていること）、また、セッション鍵取得情報に改竄が行われていないことを検証することができる。なお、ＩｄＰ−１がセッション鍵取得情報を送信した事実を否認しないことなども検証することができる。

その後、ＩｄＰ−２は、実施例１と同様、復号したセッション鍵取得情報によって取得することが可能なセッション鍵を、ＵＡＣ−２に送信する（ステップＳ６０７）。具体的には、実施例３においては、ＩｄＰ−２は、ＵＡＣ−２を認証するとともに、ＵＡＣ−２から受信したセッション鍵取得情報によって取得することが可能なセッション鍵（ＩｄＰ−２の公開鍵によって暗号化されたセッション鍵取得情報を復号するなど）を、例えば、ＨＴＴＰＳの「２００ ＯＫ」メッセージに付加した形態で、ＵＡＣ−２に送信する。

こうして、ＵＡＣ−１とＵＡＣ−２との間でセッション鍵を共有することができたので、その後、実施例１と同様、ＵＡＣ−２は、ＵＡＣ−１に対して、例えば、ＳＩＰの「２００ ＯＫ」メッセージを送信し（ステップＳ６０８）、ＵＡＣ−１は、ＵＡＣ−２に対して、例えば、ＳＩＰの「ＡＣＫ」メッセージを送信するなどして（ステップＳ６０９）、ＵＡＣ−１とＵＡＣ−２との間でセッションが確立される（ステップＳ６１０）。

次に、図７（非対称鍵を共有する事例）について説明すると、まず、ＵＡＣ−１は、実施例２と同様、ＵＡＣ−２との間で確立されるセッションを暗号化するセッション鍵（セッション鍵−１）を作成し（ステップＳ７０１）、次に、ＵＡＣ−１は、実施例２と同様、自らが登録されているＩｄＰ−１に対して、認証要求とセッション鍵−１とを、ＨＴＴＰＳの「ＰＯＳＴ」メッセージに付加した形態で送信する（ステップＳ７０２）。

すると、ＩｄＰ−１は、実施例２と同様、ＵＡＣ−１を認証するとともに、ＵＡＣ−１から受信したセッション鍵−１を取得するための情報（セッション鍵−１取得情報）を、ＳＡＭＬで規定されるような形式に記述して、ＨＴＴＰＳの「２００ ＯＫ」メッセージに付加した形態で、ＵＡＣ−１に送信するが、実施例２と異なり、セッション鍵−１取得情報をＩｄＰ−１の秘密鍵で署名するとともに、ＵＡＣ−２が所属するＩｄＰ−２の公開鍵を用いてセッション鍵−１取得情報を暗号化した上で、ＵＡＣ−１に送信する（ステップＳ７０３）。

続いて、ＵＡＣ−１は、実施例２と同様、ＵＡＣ−２に対して、ＩｄＰから受信したセッション鍵−１取得情報を、ＳＩＰの「ＩＮＶＩＴＥ」メッセージに付加した形態で転送し（ステップＳ７０４）、そして、ＵＡＣ−２は、実施例２と同様、ＵＡＣ−１との間で確立されたセッションを暗号化するセッション鍵（セッション鍵−２）を作成する（ステップＳ７０５）。

次に、ＵＡＣ−２は、実施例２と同様、ＩｄＰに対して、認証要求とセッション鍵−１に関する情報とセッション鍵−２とを、例えば、ＨＴＴＰＳの「ＰＯＳＴ」メッセージに付加した形態で送信するが、実施例２と異なり、図６で説明した事例と同様に、ＵＡＣ−２は、ＩｄＰ−２に対して、これらの情報を送信する（ステップＳ７０６）。すなわち、ＵＡＣ−２は、ＩｄＰ−２に対して、認証要求とセッション鍵−１取得情報とセッション鍵−２とを送信する。

すると、実施例３においては、実施例２と異なり、図６で説明した事例と同様に、ＩｄＰ−２において、ＳＡＭＬ検証の処理がおこなわれる（ステップＳ７０７）。すなわち、実施例３においては、ＩｄＰ−１が、セッション鍵−１取得情報をＳＡＭＬ形式で記述し、ＩｄＰ−１の秘密鍵で署名しているので、ＩｄＰ−２は、この署名から、セッション鍵−１取得情報のハッシュ値を取り出す。一方で、ＩｄＰ−２は、取得したセッション鍵−１取得情報（ＩｄＰ−２の公開鍵で暗号化されたセッション鍵−１取得情報を、ＩｄＰ−２の秘密鍵で復号した情報）のハッシュ値を算出し、署名から取り出したハッシュ値と、算出したハッシュ値とを比較する。比較の結果、二つのハッシュ値が同一であれば、ＩｄＰ−２は、セッション鍵−１取得情報に関する事実として、確かに、ＩｄＰ−１から発行されたセッション鍵−１取得情報であること（セッション鍵−１取得情報がＩｄＰ−１によって保証されていること）、また、セッション鍵−１取得情報に改竄が行われていないことを検証することができる。なお、ＩｄＰ−１がセッション鍵−１取得情報を送信した事実を否認しないことなども検証することができる。

その後、ＩｄＰ−２は、実施例２と同様、ＵＡＣ−２を認証するとともに、セッション鍵−１取得情報で指定されるセッション鍵−１をＵＡＣ−２に送信する他に、ＵＡＣ−２から受信したセッション鍵−２取得情報を、ＳＡＭＬで規定されるような形式に記述して、例えば、ＨＴＴＰＳの「２００ ＯＫ」メッセージに付加した形態で、ＵＡＣ−２に送信するが、実施例２と異なり、セッション鍵−２取得情報をＩｄＰ−２の秘密鍵で署名するとともに、ＵＡＣ−１が所属するＩｄＰ−１の公開鍵を用いてセッション鍵−２取得情報を暗号化した上で、ＵＡＣ−２に送信する（ステップＳ７０８）。

なお、以下、実施例２と同様の処理の手順に、上記したようなＳＡＭＬの検証処理（ステップＳ７１１）を追加するなどして、実施例３における処理は終了する（ステップＳ７０９〜Ｓ７１４）。

［実施例３の効果］
上記してきたように、実施例３によれば、第三者機関装置は、互いの公開鍵を予め交換している複数の第三者機関装置で構成されるものであって、複数の第三者機関装置の内の所定の第三者機関装置は、所定の第三者機関装置以外のその他の第三者機関装置において電子署名が添付されたセッション鍵に関する情報を受信すると、セッション鍵に関する情報について検証するので、第三者機関装置が複数の第三者機関装置で構成されている場合にも、エンドエンドでの認証が予め確保されていることを前提とせずに、セッション鍵を共有することが可能になる。

例えば、他の第三者機関装置と互いの公開鍵を予め交換している第三者機関装置が、ＳＡＭＬ（Security Assertion Markup Language）で規定されるような形式でセッション鍵に関する情報を発行し、他の第三者機関装置がこのセッション鍵に関する情報を受信すると、情報を受信した第三者機関装置は、予め交換している公開鍵などを用いて、セッション鍵に関する情報に関する事実として、確かに、情報を送信した第三者機関装置から発行されたセッション鍵に関する情報であること（セッション鍵に関する情報が第三者機関装置によって保証されていること）、また、セッション鍵に関する情報に改竄が行われていないことを検証することができる。なお、第三者機関装置がセッション鍵に関する情報を送信した事実を否認しないことなども検証することができる。

また、要求側装置や応答側装置に関する情報や有効期限など、セッション鍵を取得するための取得条件を、ＳＡＭＬで規定されるような形式で発行されたセッション鍵に関する情報に含ませておくことで、セッション鍵を取得するための情報を第三者に不正に取得された場合にも、セッション鍵自体が第三者に不正に取得されることを防ぐことが可能になる。

ところで、これまで実施例１〜３として、第三者機関装置とＳＩＰ（Session Initiation Protocol）プロキシとが異なる装置で構成される事例について説明したが、本発明はこれに限られるものではなく、第三者機関装置がＳＩＰプロキシと同一の装置で構成される事例にも、本発明を同様に適用することができる。そこで、以下では、実施例４として、第三者機関装置がＳＩＰプロキシと同一の装置で構成される事例について説明する。

なお、実施例４に係るセッション鍵共有システムは、実施例２および３に係るセッション鍵共有システムとほぼ同様に構成され、第三者機関装置がＳＩＰプロキシと同一の装置で構成される点について、実施例２および３と異なるものである。以下では、実施例４に係るセッション鍵共有システムによる処理の手順および実施例４の効果についてのみ説明する。

［実施例４に係るセッション鍵共有システムによる処理の手順］
図８および９を用いて、実施例４に係るセッション鍵共有システムによる処理の手順を説明する。図８および９は、実施例４に係るセッション鍵共有システムによる処理の手順を示すシーケンス図である。なお、図８は、第三者機関装置が一つの装置で構成される事例であり、図９は、第三者機関装置が二つの装置で構成される事例である。

また、実施例４に係るセッション鍵共有システムによる処理の手順は、実施例２に係るセッション鍵共有システムによる処理の手順（図５を参照）および実施例３に係るセッション鍵共有システムによる処理の手順（図７を参照）とそれぞれ比較すると、ＩｄＰがＳＩＰプロキシと同一の装置で構成されており、ＵＡＣ−１またはＵＡＣ−２とＩｄＰとの間がセキュリティが確保された通信路であることから、ＵＡＣ−１またはＵＡＣ−２とＳＩＰプロキシとの間では、セッション鍵に関する情報として、セッション鍵自体が送受信されている点が特に異なる。

図８（第三者機関装置が一つの装置）について説明すると、まず、実施例４においては、ＵＡＣ−２が、予め、ＳＩＰプロキシ（ＩｄＰ）に対して、「ＵＡＣ−２を認証することを要求する認証要求」を、セッションを確立するに際して必要とされる信号に付加した形態で送信する（ステップＳ８０１）。具体的には、ＵＡＣ−２は、ＳＩＰプロキシ（ＩｄＰ）に対して、認証要求を、例えば、ＳＩＰの「ＲＥＧＩＳＴＥＲ」メッセージに付加した形態で送信する。

すると、ＳＩＰプロキシ（ＩｄＰ）は、「ＵＡＣ−２を認証することを要求する認証要求」を、セッションを確立するに際して必要とされる信号に付加された形態でＵＡＣ−２から受信すると、ＵＡＣ−２を認証し、認証結果を、ＵＡＣ−２に送信する（ステップＳ８０２）。具体的には、ＳＩＰプロキシ（ＩｄＰ）は、例えば、ＳＩＰの「２００ ＯＫ」メッセージによって、ＵＡＣ−２の認証に成功したとの認証結果を、ＵＡＣ−２に送信する。かかるステップＳ８０１〜８０２の処理は、ステップＳ８０３以降の処理を開始するにあたり、予め行われているものである。

ステップＳ８０１〜Ｓ８０２が予め行われていることを前提として、ＵＡＣ−１は、実施例２と同様、ＵＡＣ−２との間で確立されたセッションを暗号化するセッション鍵（セッション鍵−１）を作成する（ステップＳ８０３）。

次に、ＵＡＣ−１は、実施例２と同様、ＩｄＰに対して、認証要求とセッション鍵−１とを送信するが、実施例２と異なり、ＩｄＰがＳＩＰプロキシと同一の装置であることから、例えば、ＳＩＰの「ＩＮＶＩＴＥ」メッセージに付加した形態で送信する（ステップＳ８０４）。

すると、ＩｄＰは、実施例２と同様、ＵＡＣ−１を認証するが、実施例２と異なり、ＵＡＣ−１から受信したセッション鍵−１自体を、例えば、ＳＩＰの「ＩＮＶＩＴＥ」メッセージに付加した形態で、ＵＡＣ−２に送信する（ステップＳ８０５）。この段階で、ＵＡＣ−２は、セッション鍵−１を取得したことになる。

続いて、実施例２と同様、ＵＡＣ−２は、ＵＡＣ−１との間で確立されたセッションを暗号化するセッション鍵（セッション鍵−２）を作成する（ステップＳ８０６）。

次に、ＵＡＣ−２は、実施例２と同様、ＩｄＰに対して、セッション鍵−２を送信するが、実施例２と異なり、ＩｄＰがＳＩＰプロキシと同一の装置であることから、例えば、ＳＩＰの「２００ ＯＫ」メッセージに付加した形態で送信する（ステップＳ８０７）。

すると、ＳＩＰプロキシ（ＩｄＰ）は、実施例２と異なり、ＵＡＣ−２をすでに認証しているので（ステップＳ８０１〜Ｓ８０２を参照）、ＵＡＣ−２から受信したセッション鍵−２自体を、例えば、ＳＩＰの「２００ ＯＫ」メッセージに付加した形態で、ＵＡＣ−１に送信する（ステップＳ８０７）。この段階で、ＵＡＣ−１は、セッション鍵−２を取得したことになる。

その後、実施例２と同様、ＵＡＣ−１は、ＵＡＣ−２に対して、例えば、ＳＩＰの「ＡＣＫ」メッセージを送信するなどして（ステップＳ８０８）、ＵＡＣ−１とＵＡＣ−２との間でセッションが確立される（ステップＳ８０９）。

次に、図９（第三者機関装置が二つの装置）について、図８（第三者機関装置が一つの装置）との違いに特に着目して説明すると、図９の事例は、ＳＩＰプロキシ（ＩｄＰ）が、ＳＩＰプロキシ−１とＳＩＰプロキシ−２との二つの装置で構成されることに起因して、ＳＩＰプロキシ−２でのＳＡＭＬ検証（ステップＳ９０６）と、ＳＩＰプロキシ−１でのＳＡＭＬ検証（ステップＳ９１１）とが追加されている点が、図８の事例と異なることがわかる。

すなわち、ＳＩＰプロキシ−１（ＩｄＰ−１）は、ＵＡＣ−１を認証する認証情報を予め保持しており、ＳＩＰプロキシ−２（ＩｄＰ−２）は、ＵＡＣ−２を認証する認証情報を予め保持しており、ＳＩＰプロキシ−１（ＩｄＰ−１）とＳＩＰプロキシ−２（ＩｄＰ−２）との間では、互いの公開鍵が予め交換されるなどして、認証が予め確保された状態である（ＳＩＰプロキシ−１（ＩｄＰ−１）とＳＩＰプロキシ−２（ＩｄＰ−２）とは信頼関係にある）。

しかしながら、実施例４においては、ＳＩＰプロキシ−１（ＩｄＰ−１）とＳＩＰプロキシ−２（ＩｄＰ−２）との間の通信路は、セキュリティが確保されているとはいえないと考えるので、ＳＩＰプロキシ−１（ＩｄＰ−１）は、ＵＡＣ−１からセッション鍵−１を受信すると（ステップＳ９０４を参照）、セッション鍵−１自体をＳＩＰプロキシ−２（ＩｄＰ−２）に送信するのではなく、まず、セッション鍵−１をＳＩＰプロキシ−１（ＩｄＰ−１）の秘密鍵で署名するとともに、ＳＩＰプロキシ−２（ＩｄＰ−２）の公開鍵を用いてセッション鍵−１を暗号化した上で、ＳＩＰプロキシ−２（ＩｄＰ−２）に送信する（ステップＳ９０５を参照）。

すると、ＳＩＰプロキシ−２（ＩｄＰ−２）においては、ＳＡＭＬ検証の処理がおこなわれる（ステップＳ９０６を参照）。すなわち、実施例４においては、ＳＩＰプロキシ−１（ＩｄＰ−１）が、セッション鍵−１取得情報をＳＡＭＬ形式で記述し、ＳＩＰプロキシ−１（ＩｄＰ−１）の秘密鍵で署名しているので、ＳＩＰプロキシ−２（ＩｄＰ−２）は、この署名から、セッション鍵−１取得情報のハッシュ値を取り出す。一方で、ＳＩＰプロキシ−２（ＩｄＰ−２）は、取得したセッション鍵取得情報（ＳＩＰプロキシ−２（ＩｄＰ−２）の公開鍵で暗号化されたセッション鍵−１取得情報を、ＳＩＰプロキシ−２（ＩｄＰ−２）の秘密鍵で復号した情報）のハッシュ値を算出し、署名から取り出したハッシュ値と、算出したハッシュ値とを比較する。比較の結果、二つのハッシュ値が同一であれば、ＳＩＰプロキシ−２（ＩｄＰ−２）は、セッション鍵−１取得情報に関する事実として、確かに、ＳＩＰプロキシ−１（ＩｄＰ−１）から発行されたセッション鍵−１取得情報であること（セッション鍵−１取得情報がＳＩＰプロキシ−１（ＩｄＰ−１）によって保証されていること）、また、セッション鍵−１取得情報に改竄が行われていないことを検証することができる。なお、ＳＩＰプロキシ−１（ＩｄＰ−１）がセッション鍵−１取得情報を送信した事実を否認しないことなども検証することができる。

また、上記と同様に、ＳＩＰプロキシ−２（ＩｄＰ−２）も、ＵＡＣ−２からセッション鍵−２を受信すると（ステップＳ９０９を参照）、セッション鍵−２自体をＳＩＰプロキシ−１（ＩｄＰ−１）に送信するのではなく、まず、セッション鍵−２をＳＩＰプロキシ−２（ＩｄＰ−２）の秘密鍵で署名するとともに、ＳＩＰプロキシ−１（ＩｄＰ−１）の公開鍵を用いてセッション鍵−２を暗号化した上で、ＳＩＰプロキシ−１（ＩｄＰ−１）に送信する（ステップＳ９１０を参照）。すると、上記と同様に、ＳＩＰプロキシ−１（ＩｄＰ−１）においては、ＳＡＭＬ検証の処理がおこなわれる（ステップＳ９１１を参照）。

［実施例４の効果］
上記してきたように、実施例４によれば、第三者機関装置は、要求側装置と応答側装置との間でセッションを確立するに際して必要とされる信号を制御するＳＩＰプロキシと同一の装置で構成されるものであって、セッション鍵を第三者機関装置が制御する信号に付加する形態で送信するので、第三者機関装置がＳＩＰプロキシと同一の装置で構成されている場合にも、エンドエンドでの認証が予め確保されていることを前提とせずに、セッション鍵を共有することが可能になる。

また、ＳＩＰ通信のセキュリティが確保されているという環境においては、同時に、セッションのセキュリティも確保されていると考えることが可能になる。

ところで、これまで実施例１〜４として、セッション鍵の作成が、要求側装置または応答側装置において行われる事例について説明したが、本発明はこれに限られるものではなく、セッション鍵の作成が、第三者機関装置において行われる事例にも、本発明を同様に適用することができる。そこで、以下では、実施例５として、セッション鍵の作成が、第三者機関装置において行われる事例について説明する。

なお、実施例５に係るセッション鍵共有システムは、実施例１〜４に係るセッション鍵共有システムとほぼ同様に構成され、セッション鍵の作成が、第三者機関装置において行われる点について、実施例１〜４と異なるものである。以下では、実施例５に係るセッション鍵共有システムによる処理の手順および実施例５の効果についてのみ説明する。

［実施例５に係るセッション鍵共有システムによる処理の手順］
図１０〜１５を用いて、実施例５に係るセッション鍵共有システムによる処理の手順を説明する。図１０〜１５は、実施例５に係るセッション鍵共有システムによる処理の手順を示すシーケンス図である。

図１０は、実施例１に係るセッション鍵共有システムとして説明した事例とほぼ同様の事例であって、セッション鍵の作成が、ＩｄＰにおいて行われる点のみ、異なるものである。したがって、図１０を図４と対比するとわかるように、ステップＳ１００１の「ＰＯＳＴ」メッセージには、セッション鍵が付加されておらず、一方、ＩｄＰによって作成されたセッション鍵は（ステップＳ１００２）、ステップＳ１００３の「２００ ＯＫ」メッセージに付加された形態で、ＵＡＣ−１に送信される。

図１１は、実施例２に係るセッション鍵共有システムとして説明した事例とほぼ同様の事例であって、セッション鍵の作成が、ＩｄＰにおいて行われる点のみ、異なるものである。したがって、図１１を図５と対比するとわかるように、ステップＳ１１０１の「ＰＯＳＴ」メッセージには、セッション鍵−１が付加されておらず、一方、ＩｄＰによって作成されたセッション鍵−１は（ステップＳ１１０２）、ステップＳ１１０３の「２００ ＯＫ」メッセージに付加された形態で、ＵＡＣ−１に送信される。

また、ステップＳ１１０５の「ＰＯＳＴ」メッセージには、セッション鍵−２が付加されておらず、一方、ＩｄＰによって作成されたセッション鍵−２は（ステップＳ１１０６）、ステップＳ１１０７の「２００ ＯＫ」メッセージに付加された形態で、ＵＡＣ−２に送信される。

図１２は、実施例３に係るセッション鍵共有システムとして説明した事例とほぼ同様の事例であって、セッション鍵の作成が、ＩｄＰにおいて行われる点のみ、異なるものである。したがって、図１２を図６と対比するとわかるように、ステップＳ１２０１の「ＰＯＳＴ」メッセージには、セッション鍵が付加されておらず、一方、ＩｄＰ−１によって作成されたセッション鍵は（ステップＳ１２０２）、ステップＳ１２０３の「２００ ＯＫ」メッセージに付加された形態で、ＵＡＣ−１に送信される。

図１３も、実施例３に係るセッション鍵共有システムとして説明した事例とほぼ同様の事例であって、セッション鍵の作成が、ＩｄＰにおいて行われる点のみ、異なるものである。したがって、図１３を図７と対比するとわかるように、ステップＳ１３０１の「ＰＯＳＴ」メッセージには、セッション鍵−１が付加されておらず、一方、ＩｄＰ−１によって作成されたセッション鍵−１は（ステップＳ１３０２）、ステップＳ１３０３の「２００ ＯＫ」メッセージに付加された形態で、ＵＡＣ−１に送信される。

また、ステップＳ１３０５の「ＰＯＳＴ」メッセージには、セッション鍵−２が付加されておらず、一方、ＩｄＰ−２によって作成されたセッション鍵−２は（ステップＳ１３０６）、ステップＳ１３０８の「２００ ＯＫ」メッセージに付加された形態で、ＵＡＣ−２に送信される。

図１４は、実施例４に係るセッション鍵共有システムとして説明した事例とほぼ同様の事例であって、セッション鍵の作成が、ＳＩＰプロキシ（ＩｄＰ）において行われる点のみ、異なるものである。したがって、図１４を図８と対比するとわかるように、ステップＳ１４０３の「ＩＮＶＩＴＥ」メッセージには、セッション鍵が付加されておらず、一方、ＳＩＰプロキシ（ＩｄＰ）によって作成されたセッション鍵は（ステップＳ１４０４）、ステップＳ１４０６の「２００ ＯＫ」メッセージに付加された形態で、ＳＩＰプロキシ（ＩｄＰ）からＵＡＣ−１に送信される。

図１５も、実施例４に係るセッション鍵共有システムとして説明した事例とほぼ同様の事例であって、セッション鍵の作成が、ＳＩＰプロキシ（ＩｄＰ）において行われる点のみ、異なるものである。したがって、図１５を図９と対比するとわかるように、ステップＳ１５０３の「ＩＮＶＩＴＥ」メッセージには、セッション鍵−１が付加されておらず、一方、ＳＩＰプロキシ−１（ＩｄＰ−１）によって作成されたセッション鍵−１は（ステップＳ１５０４）、ステップＳ１５１２の「２００ ＯＫ」メッセージに付加された形態で、ＳＩＰプロキシ−１（ＩｄＰ−１）からＵＡＣ−１に送信される。

また、ステップＳ１５０８の「２００ ＯＫ」メッセージには、セッション鍵−２が付加されておらず、一方、ＳＩＰプロキシ−２（ＩｄＰ−２）によって作成されたセッション鍵−２は（ステップＳ１５０９）、ステップＳ１５１３の「ＡＣＫ」メッセージに付加された形態で、ＳＩＰプロキシ−２（ＩｄＰ−２）からＵＡＣ−２に送信される。

［実施例５の効果］
上記してきたように、実施例５によれば、第三者機関装置で作成されたセッション鍵を共有させるので、エンドエンドでの認証が予め確保されていることを前提とせずに、第三者機関装置で作成されたセッション鍵を共有することが可能になる。

［他の実施例］
さて、これまで本発明の実施例について説明してきたが、本発明は上記した実施例１〜５以外にも、種々の異なる形態にて実施されてよいものである。以下では、実施例６として、異なる形態の実施例について説明する。

まず、実施例１〜３などにおいては、第三者機関装置が、セッション鍵取得情報を要求側装置（または、応答側装置）に送信し、要求側装置（または、応答側装置）が、セッション鍵取得情報をセッションを確立するに際して必要とされる信号に付加した形態で応答側装置（または、要求側装置）に転送し、応答側装置（または、要求側装置）が、セッション鍵取得情報を第三者機関装置に送信することでセッション鍵の取得を第三者機関装置に要求し、第三者機関装置が、セッション鍵を応答側装置（または、要求側装置）に送信する手法について説明してきたが、本発明はこれに限られるものではない。第三者機関装置がセッション鍵取得情報を送信せず、したがって要求側装置（または、応答側装置）がセッション鍵取得情報を転送せず、応答側装置（または、要求側装置）もセッション鍵取得情報を第三者機関装置に送信せずに、第三者機関装置がセッション鍵を応答側装置（または、要求側装置）に送信する手法にも、本発明を同様に適用することができる。

具体的に例を挙げて説明すると、例えば、まず、ＵＡＣ−１（要求側装置）は、ＵＡＣ−２（応答側装置）との間で確立されるセッションを暗号化するセッション鍵を作成する。次に、ＵＡＣ−１は、ＩｄＰ（第三者機関装置）に対して、認証要求、セッション鍵、および、セッション鍵の受取者であるＵＡＣ−２を特定する特定情報（例えば、ＵＡＣ−２のＩＤやＩＰアドレスなど）を、ＨＴＴＰＳの「ＰＯＳＴ」メッセージに付加した形態で送信する。すると、ＩｄＰは、保持する認証情報を用いてＵＡＣ−１を認証し、ＨＴＴＰＳの「２００ ＯＫ」メッセージをＵＡＣ−１に送信する。続いて、ＵＡＣ−１は、ＵＡＣ−２に対して、暗号化通信開始要求を送信する。この時、ＵＡＣ−２においては、通信自体は暗号化されているが、通信相手であるＵＡＣ−１のＩＰアドレスを取得することは可能である。そこで、ＵＡＣ−２は、ＩｄＰに対して、認証要求と、セッション鍵の生成者であるＵＡＣ−１を特定する特定情報（例えば、取得したＵＡＣ−１のＩＰアドレスなど）を、ＨＴＴＰＳの「ＰＯＳＴ」メッセージに付加した形態で送信する。すると、ＩｄＰは、保持する認証情報を用いてＵＡＣ−２を認証し、認証した「ＵＡＣ−２」と、ＵＡＣ−１から取得した特定情報で特定されるセッション鍵の受取者とが一致するので、ＨＴＴＰＳの「２００ ＯＫ」に付加する形態で、ＵＡＣ−１のＩＰアドレスで特定されるＵＡＣ−１から受信したセッション鍵を、ＵＡＣ−２に送信する。その後、ＵＡＣ−１とＵＡＣ−２との間で、セッション鍵を用いて暗号化された暗号化通信が行われる。

また、実施例１〜５においては、第三者機関装置が、セッション鍵の属性を示す属性情報を送信せず、セッション鍵のみを送信する手法について説明したが、第三者機関装置が、セッション鍵を送信するとともに、セッション鍵の属性を示す属性情報を送信する手法にも、本発明を同様に適用することができる。この場合には、セッション鍵を取得した要求側装置（または応答側装置）において、セッション鍵に関する属性を知ることが可能になる。例えば、属性情報として「セッション鍵の作成者」を送信すると、セッションを取得した要求側装置（または応答側装置）において、いずれの装置において作成されたセッション鍵であるかを判断することが可能になる。なお、その他の属性情報としては、「セッション鍵の受取者」、「有効期限」、「セッション鍵の種類」などが挙げられる。

また、実施例１〜５においては、第三者機関装置が、ネットワーク上に設置された汎用的なコンピュータなどによって実現される形態を想定しているが、本発明はこれに限られるものではない。例えば、第三者機関装置が、移動体端末によって実現される形態や、ホームゲートウェイ装置によって実現される形態などにも、本発明を同様に適用することができる。このような形態においては、認証情報の保持や、上記してきたような暗号、署名検証の機能などを、ＳＩＭ（Subscriber Identity Module）カードによって実現する手法が考えられる。なお、保持する認証情報を用いた認証は、例えば、「同一の宅内であること」で認証する手法や、「ＰＩＮ（Personal Identity Number）コード」で認証する手法などが考えられる。

［システム構成等］
本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示（例えば、図２など）の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

なお、本実施例で説明したセッション鍵共有方法は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。

以上のように、本発明に係るセッション鍵共有システム、第三者機関装置、要求側装置、および応答側装置は、セッションを確立することを要求する要求側装置と、かかる要求に応答して要求側装置との間でセッションを確立する応答側装置と、要求側装置および応答側装置の認証に関する処理を行う第三者機関装置とで構成され、要求側装置と応答側装置との間で確立されるセッションを暗号化するセッション鍵を、要求側装置と応答側装置との間でセッションの確立前に共有することに有用であり、特に、エンドエンドでの認証が予め確保されていることを前提とせずに、セッション鍵を共有（転送、交換）することに適する。

実施例１に係るセッション鍵共有システムの概要および特徴を説明するための図である。 実施例１に係るセッション鍵共有システムの構成を示すブロック図である。 認証情報保持部を説明するための図である。 実施例１に係るセッション鍵共有システムによる処理の手順を示すシーケンス図である。 実施例２に係るセッション鍵共有システムによる処理の手順を示すシーケンス図である。 実施例３に係るセッション鍵共有システムによる処理の手順を示すシーケンス図である。 実施例３に係るセッション鍵共有システムによる処理の手順を示すシーケンス図である。 実施例４に係るセッション鍵共有システムによる処理の手順を示すシーケンス図である。 実施例４に係るセッション鍵共有システムによる処理の手順を示すシーケンス図である。 実施例５に係るセッション鍵共有システムによる処理の手順を示すシーケンス図である。 実施例５に係るセッション鍵共有システムによる処理の手順を示すシーケンス図である。 実施例５に係るセッション鍵共有システムによる処理の手順を示すシーケンス図である。 実施例５に係るセッション鍵共有システムによる処理の手順を示すシーケンス図である。 実施例５に係るセッション鍵共有システムによる処理の手順を示すシーケンス図である。 実施例５に係るセッション鍵共有システムによる処理の手順を示すシーケンス図である。

符号の説明

１００ 要求側装置
１１１ 入出力部
１１２ 通信部
１２０ 記憶部
１２１ セッション鍵保持部
１３０ 制御部
１３１ 認証要求送信部
１３２ セッション鍵取得情報転送部
１３３ 暗号化部
２００ 応答側装置
２１１ 入出力部
２１２ 通信部
２２０ 記憶部
２２１ セッション鍵保持部
２３０ 制御部
２３１ 認証要求送信部
２３２ セッション鍵取得要求部
２３３ 暗号化部
３００ 第三者機関装置
３１１ 通信部
３２０ 記憶部
３２１ 認証情報保持部
３３０ 制御部
３３１ 認証部
３３２ セッション鍵取得情報送信部
３３３ セッション鍵共有部

Claims (8)

1. セッションを確立することを要求する要求側装置と、当該要求に応答して当該要求側装置との間でセッションを確立する応答側装置と、当該要求側装置および当該応答側装置の認証に関する処理を行う第三者機関装置とで構成され、前記セッションを暗号化するセッション鍵を、互いを通信相手とする当該要求側装置と当該応答側装置との間で当該セッションの確立前に共有するセッション鍵共有システムであって、
   前記第三者機関装置は、
   前記要求側装置および前記応答側装置の各々の認証に用いる認証情報を保持する認証情報保持手段と、
   通信相手にセッション鍵を取得させる前記要求側装置および前記応答側装置の少なくとも一方から認証要求を受信すると、前記認証情報保持手段によって保持された認証情報を用いて当該要求側装置および当該応答側装置の少なくとも一方を認証する認証手段と、
   前記認証手段によって認証された結果が成功の場合に、前記通信相手が前記セッション鍵を取得するための情報であるセッション鍵取得情報であって、当該セッション鍵取得情報が当該第三者機関装置によって発行されたこと、および、改竄が行われていないことを当該第三者機関装置にて検証可能な形式で、前記認証要求を送信した前記要求側装置および前記応答側装置の少なくとも一方に送信するセッション鍵取得情報送信手段と、
   セッション鍵を取得する前記要求側装置および前記応答側装置の少なくとも一方から前記セッション鍵取得情報を受信すると、当該セッション鍵取得情報を検証し、当該検証した結果が成功の場合に、当該セッション鍵取得情報によって取得することが可能なセッション鍵を、セキュリティが確保された第１の通信を用いて、当該セッション鍵取得情報を送信した前記要求側装置および前記応答側装置の少なくとも一方に送信するセッション鍵共有手段とを備え、
   前記通信相手にセッション鍵を取得させる前記要求側装置および前記応答側装置の少なくとも一方は、
   前記認証要求を前記第三者機関装置に対して送信する認証要求送信手段と、
   前記セッション鍵取得情報送信手段によって送信された前記セッション鍵取得情報を、前記セッションを確立するに際して必要とされる信号に付加した形態で、セキュリティが確保されていない第２の通信を用いて、前記通信相手に転送するセッション鍵取得情報転送手段とを備え、
   
   セッション鍵を取得する前記要求側装置および前記応答側装置の少なくとも一方は、
   前記セッション鍵取情報転送手段によって前記通信相手から転送された前記セッション鍵取得情報を受信すると、当該セッション鍵取得情報を前記第三者機関装置に送信することで、当該セッション鍵取得情報によって取得することが可能なセッション鍵の取得を前記第三者機関装置に要求するセッション鍵取得要求手段と
   を備えたことを特徴とするセッション鍵共有システム。
2. 前記セッション鍵共有手段は、前記要求側装置および前記応答側装置の少なくとも一方で作成された前記セッション鍵を共有させることを特徴とする請求項１に記載のセッション鍵共有システム。
3. 前記セッション鍵共有手段は、前記第三者機関装置で作成された前記セッション鍵を共有させることを特徴とする請求項１に記載のセッション鍵共有システム。
4. 前記セッション鍵共有手段は、前記セッション鍵を送信するとともに、当該セッション鍵の属性を示す属性情報をさらに送信することを特徴とする請求項１〜３のいずれか一つに記載のセッション鍵共有システム。
5. 前記第三者機関装置は、互いの公開鍵を予め交換している複数の第三者機関装置で構成されるものであって、
   前記複数の第三者機関装置の内の所定の第三者機関装置は、
   当該所定の第三者機関装置以外のその他の第三者機関装置において電子署名が添付された前記セッション鍵に関する情報を受信すると、当該セッション鍵に関する情報について検証する検証手段をさらに備えたことを特徴とする請求項１〜４のいずれか一つに記載のセッション鍵共有システム。
6. セッションを確立することを要求する要求側装置と、当該要求に応答して当該要求側装置との間でセッションを確立する応答側装置と、当該要求側装置および当該応答側装置の認証に関する処理を行う第三者機関装置とで構成され、前記セッションを暗号化するセッション鍵を、互いを通信相手とする当該要求側装置と当該応答側装置との間で当該セッションの確立前に共有するセッション鍵共有システムにおける前記第三者機関装置であって、
   前記要求側装置および前記応答側装置の各々の認証に用いる認証情報を保持する認証情報保持手段と、
   通信相手にセッション鍵を取得させる前記要求側装置および前記応答側装置の少なくとも一方から認証要求を受信すると、前記認証情報保持手段によって保持された認証情報を用いて当該要求側装置および当該応答側装置の少なくとも一方を認証する認証手段と、
   前記認証手段によって認証された結果が成功の場合に、前記通信相手が前記セッション鍵を取得するためにセキュリティが確保されていない通信を用いて当該通信相手に転送される情報であるセッション鍵取得情報であって、当該セッション鍵取得情報が当該第三者機関装置によって発行されたこと、および、改竄が行われていないことを当該第三者機関装置にて検証可能な形式で、前記認証要求を送信した前記要求側装置および前記応答側装置の少なくとも一方に送信するセッション鍵取得情報送信手段と、
   セッション鍵を取得する前記要求側装置および前記応答側装置の少なくとも一方から前記セッション鍵取得情報を受信すると、当該セッション鍵取得情報を検証し、当該検証した結果が成功の場合に、当該セッション鍵取得情報によって取得することが可能なセッション鍵を、セキュリティが確保された通信を用いて、当該セッション鍵取得情報を送信した前記要求側装置および前記応答側装置の少なくとも一方に送信するセッション鍵共有手段と、
   を備えたことを特徴とする第三者機関装置。
7. セッションを確立することを要求する要求側装置と、当該要求に応答して当該要求側装置との間でセッションを確立する応答側装置と、当該要求側装置および当該応答側装置の認証に関する処理を行う第三者機関装置とで構成され、前記セッションを暗号化するセッション鍵を、互いを通信相手とする当該要求側装置と当該応答側装置との間で当該セッションの確立前に共有するセッション鍵共有システムにおける前記要求側装置であって、
   前記通信相手にセッション鍵を取得させる場合に、認証要求を前記第三者機関装置に対して送信する認証要求送信手段と、
   前記通信相手が前記セッション鍵を取得するための情報として前記第三者機関装置から送信されたセッション鍵取得情報であって、当該セッション鍵取得情報が当該第三者機関装置によって発行されたこと、および、改竄が行われていないことを当該第三者機関装置にて検証可能な形式で送信されたセッション鍵取得情報を、前記セッションを確立するに際して必要とされる信号に付加した形態で、セキュリティが確保されていない通信を用いて、前記通信相手に転送するセッション鍵取得情報転送手段と、
   セッション鍵を取得する場合に、前記通信相手から転送された前記セッション鍵取得情報を受信すると、当該セッション鍵取得情報を前記第三者機関装置に送信することで、当該セッション鍵取得情報によって取得することが可能なセッション鍵の取得を前記第三者機関装置に要求するセッション鍵取得要求手段と
   を備えたことを特徴とする要求側装置。
8. セッションを確立することを要求する要求側装置と、当該要求に応答して当該要求側装置との間でセッションを確立する応答側装置と、当該要求側装置および当該応答側装置の認証に関する処理を行う第三者機関装置とで構成され、前記セッションを暗号化するセッション鍵を、互いを通信相手とする当該要求側装置と当該応答側装置との間で当該セッションの確立前に共有するセッション鍵共有システムにおける前記応答側装置であって、
   前記通信相手にセッション鍵を取得させる場合に、認証要求を前記第三者機関装置に対して送信する認証要求送信手段と、
   前記通信相手が前記セッション鍵を取得するための情報として前記第三者機関装置から送信されたセッション鍵取得情報であって、当該セッション鍵取得情報が当該第三者機関装置によって発行されたこと、および、改竄が行われていないことを当該第三者機関装置にて検証可能な形式で送信されたセッション鍵取得情報を、前記セッションを確立するに際して必要とされる信号に付加した形態で、セキュリティが確保されていない通信を用いて、前記通信相手に転送するセッション鍵取得情報転送手段と、
   セッション鍵を取得する場合に、前記通信相手から転送された前記セッション鍵取得情報を受信すると、当該セッション鍵取得情報を前記第三者機関装置に送信することで、当該セッション鍵取得情報によって取得することが可能なセッション鍵の取得を前記第三者機関装置に要求するセッション鍵取得要求手段と
   を備えたことを特徴とする応答側装置。

Images