(57)【要約】【課題】ＳＩＰ通信装置及び発信者認証方法に関し、発信者の収容ネットワークが不明な場合、或いはアンセキュアなネットワークが介在する場合でも、認証処理に関するパスワード等のデータ保管が不要な発信者認証を可能にする。【解決手段】着信者ＳＩＰ端末ＵＥ（ｋ）を収容する着信側ＳＩＰサーバ（Ｋ）において、呼設定要求メッセージである着信リクエスト（ＳＩＰ  ＩＮＶＩＴＥ）情報を受信した契機（１−２）で、その情報から発信者の端末ＵＥ（ｎ）を特定する。そして、着信側ＳＩＰサーバ（Ｋ）から、発信者の端末ＵＥ（ｎ）宛てに、折り返しの呼設定要求メッセージである発信リクエスト（ＳＩＰ  ＩＮＶＩＴＥ）情報を新規に送信する（１−３）。着信側ＳＩＰサーバ（Ｋ）では、該発信リクエストに対するレスポンスを受信し（１−４）、該レスポンスに含まれる呼情報（セッション状態）を基に発信者の認証を行う。【選択図】図１
2011217031.tif 000002
【特許請求の範囲】
【請求項１】
呼設定要求メッセージを受信したときに、該呼設定要求メッセージに含まれる発信者のアドレス情報を元に、該発信者のアドレス宛てに折り返しの呼設定要求メッセージを送信する折り返し発信手段と、
前記折り返しの呼設定要求メッセージに対する応答情報に含まれる呼設定状態を示す呼情報を取得し、該呼情報を元に前記発信者の認証を行う発信者認証手段と、
前記発信者の認証の結果、正規の発信者であることを確認すると、該発信者からの前記呼設定要求メッセージに対する応答情報を返送する応答返送手段と、
を備えたことを特徴とする通信装置。
【請求項２】
前記折り返しの呼設定要求メッセージを受信したとき、呼設定中又は通話中の他の呼が存在する場合に、該折り返しの呼設定要求メッセージに対して、該他の呼のセッション識別情報を含む応答情報を返送する応答情報返送手段を備えたことを特徴とする請求項１に記載の通信装置。
【請求項３】
前記応答情報に、呼設定中又は通話中の他の呼のセッション識別情報が含まれる場合に、該他の呼のセッション識別情報を指標として前記発信者の正当性を確認する前記発信者認証手段を備えたことを特徴とする請求項１又は２に記載の通信装置。
【請求項４】
前記折り返しの呼設定要求メッセージに対する応答情報の種別毎に、前記発信者の認証の成否又は不正通知サービスの起動要否を判定する判定手段を備えたことを特徴とする請求項１乃至３の何れかに記載の通信装置。
【請求項５】
前記発信者認証手段により、発信元情報が前記発信者の正規のアドレスでないと判定された場合に、該発信者の正規のアドレス宛て、又は該発信者により送信された呼設定要求メッセージの送信先のアドレス宛てに、不正な呼の発生を通知するメッセージを送信する通知手段を備えたことを特徴とする請求項１乃至４の何れかに記載の通信装置。
【請求項６】
通信装置の呼設定処理における発信者認証方法であって、
前記通信装置で呼設定要求メッセージを受信したときに、該呼設定要求メッセージに含まれる発信者のアドレス情報を元に、該発信者のアドレス宛てに折り返しの呼設定要求メッセージを送信するステップと、
前記折り返しの呼設定要求メッセージに対する応答情報に含まれる呼設定状態を示す呼情報を取得し、該呼情報を元に前記発信者の認証を行うステップと、
前記発信者の認証の結果、正規の発信者であることを確認した後、該発信者からの前記呼設定要求メッセージに対する応答情報を返送するステップと、
を含むことを特徴とする発信者認証方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はセッション開始プロトコル（ＳＩＰ：Session Initiation Protocol）の処理機能を有する通信装置、及び該通信装置の呼設定処理における発信者認証方法に関する。本発明は、例えば、ＩＰネットワークを介して通話信号等の信号を送受信するＶｏＩＰ装置（端末、サーバ又は専用アダプタ）等における呼設定処理の際の発信者認証に適用することができる。
【背景技術】
【０００２】
今般、通信システムにおけるユーザの認証、通信データの暗合化、送受データの改竄防止（デジタル署名）等の技術の標準化が進んでいる。しかしながら、認証局の運用、電子証明書又は暗合鍵等の生成又は登録等のようなユーザと通信システムとの間で共有するパスワード等の認証情報管理の処理負担が大きく、認証システムの運用や導入の点で障壁となっている。
【０００３】
一方、従来の電話網では、電話網側で電話番号や収容位置等を基に加入者の認証を実施するものの、加入者同士で直接相手を認証し得る基盤は提供されていない。しかし、電話網は閉じたネットワーク（クローズドネットワーク）であり、加入契約を締結した実在の加入者のみが接続可能であるという前提条件により、電話網の信頼性が担保されている。従来の電話網からＶｏＩＰ網への移行を経ても、同様の網の信頼性の担保が多くの通信事業者によって踏襲されている。
【０００４】
しかし、近年、ネットワークのオープン化が進み、電話サービスにもその影響が波及し、上述の前提条件が成り立たなくなっている。そのため、通信事業者は、アンセキュアなインターネットとの接続や、アンドロイド端末に代表されるようなオープン端末の相互接続におけるセキュリティ対策に取り組み始めている。
【０００５】
ＩＰネットワークで通話信号等の信号を送受するための呼設定を制御するＳＩＰ端末を直接収容するＳＩＰサーバ又はネットワークが、従来型技術の前提条件を基に接続の信憑性を担保し、ネットワーク間の相互接続を実現する通信事業者が多数存在する。
【０００６】
図９に従来のＳＩＰノード間の呼設定シーケンス例を示す。ＳＩＰノード間の呼設定シーケンスは、図９に示すように、発信者ユーザ端末ＵＥ（ｎ）から発信側ＳＩＰサーバ（Ｎ）に、着信者のユーザ端末ＵＥ（ｋ）宛ての発信リクエスト（ＩＮＶＩＴＥ）を送信する（９−１）。該発信リクエスト（ＩＮＶＩＴＥ）を受信した発信側ＳＩＰサーバ（Ｎ）は、着信側ＳＩＰサーバ（Ｋ）に該発信リクエスト（ＩＮＶＩＴＥ）を転送する（９−２）。
【０００７】
該発信リクエスト（ＩＮＶＩＴＥ）を受信した着信側ＳＩＰサーバ（Ｋ）は、着信者ユーザ端末ＵＥ（ｋ）に発信リクエスト（ＩＮＶＩＴＥ）を送信する（９−３）。なお、呼設定要求メッセージである発信リクエスト（ＩＮＶＩＴＥ）は、着信側では着信リクエスト（ＩＮＶＩＴＥ）とも称する。
【０００８】
着信リクエスト（ＩＮＶＩＴＥ）を受信した着信者ユーザ端末ＵＥ（ｋ）は、呼び出し中であることを示すメッセージ（１８０）を着信側ＳＩＰサーバ（Ｋ）に送信する（９−４）。該呼び出し中であることを示すメッセージ（１８０）は、着信側ＳＩＰサーバ（Ｋ）から、発信側ＳＩＰサーバ（Ｎ）を経由して発信者ユーザ端末（ｎ）に送信される（９−５，９−６）。
【０００９】
また、着信リクエスト（ＩＮＶＩＴＥ）を受信した着信者ユーザ端末ＵＥ（ｋ）は、呼び出しに対する着信者の応答を検出すると、リクエストの成功（受付け可）を示すメッセージ（２００）を着信側ＳＩＰサーバ（Ｋ）に送信する（９−７）。該リクエスト成功を示すメッセージ（２００）は、着信側ＳＩＰサーバ（Ｋ）から、発信側ＳＩＰサーバ（Ｎ）を経由して発信者ユーザ端末（ｎ）に送信される（９−８，９−９）。
【００１０】
発信者ユーザ端末（ｎ）は、リクエスト成功を示すメッセージ（２００）が正常に受信されたことを示すメッセージ（ＡＣＫ）を発信側ＳＩＰサーバ（Ｎ）に送信する（９−１０）。該正常受信を示すメッセージ（ＡＣＫ）は、発信側ＳＩＰサーバ（Ｎ）から着信側ＳＩＰサーバ（Ｋ）を経由して着信者ユーザ端末ＵＥ（ｋ）へ送信され（９−１１，９−１２）、通話中となる。
【００１１】
通話終了後、切断要求を示すメッセージ（ＢＹＥ）が発信者ユーザ端末（ｎ）から送信され（９−１３）、該切断要求を示すメッセージ（ＢＹＥ）は、発信側ＳＩＰサーバ（Ｎ）及び着信側ＳＩＰサーバ（Ｋ）を経由して着信者ユーザ端末ＵＥ（ｋ）へ送信される（９−１４，９−１５）。
【００１２】
切断要求を示すメッセージ（ＢＹＥ）を受信した着信者ユーザ端末ＵＥ（ｋ）は、該切断要求の受付け可を示すメッセージ（２００）を着信側ＳＩＰサーバ（Ｋ）に送信する（９−１６）。該受付け可を示すメッセージ（２００）は、着信側ＳＩＰサーバ（Ｋ）から、発信側ＳＩＰサーバ（Ｎ）を経由して発信者ユーザ端末（ｎ）に送信され（９−１７，９−１８）、一連の呼設定シーケンスが終了し、セッションが切断される。
【００１３】
インターネット網を含む網を利用した電話接続時における成りすましに対する本人確認システムに関して、着信者は、発信者の電話番号を基に、該電話番号の登録確認と該電話番号へのコールバック接続を行い、本人確認を行う認証技術は、例えば下記の特許文献１等により知られている。
【００１４】
また、ＩＰ網における成りすましに対する本人確認システムに関して、ＳＩＰサーバが発信者の通信端末の電話番号を用いてコールバック接続を行い、発信者認証を行う認証技術は、例えば下記の特許文献２等により知られている。また、セッション開始プロトコル（ＳＩＰ）については、例えば、下記の非特許文献１により知られている。
【先行技術文献】
【特許文献】
【００１５】
【特許文献１】特開２００６−０３３７８０号公報
【特許文献２】特開２００７−２８００９４号公報
【非特許文献】
【００１６】
【非特許文献１】J. Rosenberg dynamicsoft, H. Schulzrinne Columbia U , G. Camarillo Ericsson , A. Johnston WorldCom , J. Peterson Neustar. , R. Sparks dynamicsoft , M. Handley ICIR , E. Schooler AT&T ,"SIP:セッション開始プロトコル（Session Initiation Protocol）"［online］June 2002 (Network Working Group Request for Comments: 3261 Obsoletes: 2543 Category: Standards Track) ［平成 22年 3月 12日検索］、インターネット〈 URL：http://www.ietf.org/rfc/rfc3261.txt〉
【発明の概要】
【発明が解決しようとする課題】
【００１７】
インターネット等のオープンなネットワークの相互接続が行われるネットワーク環境では、発信者の詐称等の企みや予期せぬ不正な操作等が想定され、閉じたネットワークを前提にした従来技術のような接続のセキュリティを担保することが困難になっている。本発明は、発信者の収容ネットワークが不明な場合、或いはアンセキュアなネットワークが介在する場合でも、認証処理に関するパスワード等のデータ保管が不要な発信者認証を可能にする。
【課題を解決するための手段】
【００１８】
上記課題を解決する一形態としての通信装置は、呼設定要求メッセージを受信したときに、該呼設定要求メッセージに含まれる発信者のアドレス情報を元に、該発信者のアドレス宛てに折り返しの呼設定要求メッセージを送信する折り返し発信手段と、前記折り返しの呼設定要求メッセージに対する応答情報に含まれる呼設定状態を示す呼情報を取得し、該呼情報を元に前記発信者の認証を行う発信者認証手段と、前記発信者の認証の結果、正規の発信者であることを確認すると、該発信者からの前記呼設定要求メッセージに対する応答情報を返送する応答返送手段と、を備えたものである。
【発明の効果】
【００１９】
呼情報を発信者認証のための判断材料として用いるため、認証に関するパスワード等のデータ管理が不要であり、簡易な処理で発信者認証を行うことができ、認証に関わるネットワークの運用コストを軽減することができる。また、着側の通信装置で発信者認証を実施することができ、何れの発信側端末に対しても、発信者認証を実施することが可能である。従って、通信相手である発信者の端末の収容ネットワークが不明な場合、又はアンセキュアなネットワークが介在する場合でも、発信者の認証を行うことが可能となる。また、既存の標準ＳＩＰプロトコルとの互換性を保つことができる。
【００２０】
さらに、認証の処理過程で、悪意ユーザからの攻撃対象となった被害者や、名前を不正に利用された詐称被害者の情報を取得可能であり、悪意ユーザからの不正攻撃の予兆を検出し、悪意ユーザに関する情報を収集することが可能である。これらの情報を用いて接続のセキュリティの向上やサービス向上に活用することが可能である。
【図面の簡単な説明】
【００２１】
【図１】開示の発信者認証を採用したＳＩＰノード間の呼設定シーケンス例を示す図である。
【図２】発信元情報の詐称が行われた第１の例を示す図である。
【図３】発信元情報の詐称が行われた第２の例を示す図である。
【図４】認証機能を実現するためのシステム構成例を示す図である。
【図５】認証機能を具備するＳＩＰ通信装置の処理の動作例を示す図である。
【図６】開示の認証判定方法による処理フロー例を示す図である。
【図７】ＳＩＰパラメータを拡張したＳＩＰメッセージ例を示す図である。
【図８】音声ガイダンスにより被害通知を送信する処理フロー例を示す図である。
【図９】従来のＳＩＰノード間の呼設定シーケンス例を示す図である。
【発明を実施するための形態】
【００２２】
開示の発信者認証は、着信者端末又は該着信者端末を収容する着信側サーバにおいて、呼設定要求メッセージである着信リクエスト（ＳＩＰ  ＩＮＶＩＴＥ）情報を受信した契機で、その情報から発信者のアドレス（Ｆｒｏｍ情報）を特定する。そして、該着信者端末又は該着信側サーバから、該発信者のアドレス宛てに、折り返しの呼設定要求メッセージである発信リクエスト（ＳＩＰ  ＩＮＶＩＴＥ）情報を新規に送信する。
【００２３】
そして、該着信者端末又は該着信側サーバでは、該発信リクエスト情報に対するレスポンス情報に含まれる呼情報（セッション状態）を基に、該発信者の認証を行う。もし、前述の着信リクエストの情報に発信元情報の改竄がなければ、該着信リクエストの発信者の呼状態は、当該着信者端末又は該着信側サーバ宛（Ｔｏ情報）への呼設定中（発信中）のはずであり、そうでなければ、発信元情報の詐称の疑いが高いと判定する。
【００２４】
具体的なＳＩＰノード間のシーケンス例を基に、開示の発信者認証について以下に説明する。図１に開示の発信者認証を採用したＳＩＰノード間の呼設定シーケンス例を示す。図１に示すＳＩＰノード間の呼設定シーケンス例は、発信元情報の詐称が検出されなかった場合のシーケンス例を示している。
【００２５】
ＳＩＰノード間の呼設定シーケンスは、図１に示すように、発信者ユーザ端末ＵＥ（ｎ）から発信側ＳＩＰサーバ（Ｎ）に、着信者のユーザ端末ＵＥ（ｋ）宛ての発信リクエスト（ＩＮＶＩＴＥ）を送信する（１−１）。該発信リクエスト（ＩＮＶＩＴＥ）を受信した発信側ＳＩＰサーバ（Ｎ）は、着信側ＳＩＰサーバ（Ｋ）に該発信リクエスト（ＩＮＶＩＴＥ）を転送する（１−２）。
【００２６】
図１のシーケンス例は、正当なユーザ端末ＵＥ（ｎ）からの発信の場合の例であるが、着信側ＳＩＰサーバ（Ｋ）は、該ユーザ端末ＵＥ（ｎ）が正当なユーザ端末かどうかを判断することができない。そのため、着信側ＳＩＰサーバ（Ｋ）は、まず、折り返しの新規発信リクエストを該ユーザ端末ＵＥ（ｎ）宛てに送信する（１−３）。
【００２７】
すると、該新規発信リクエストを受信したユーザ端末ＵＥ（ｎ）を収容する発ＳＩＰサーバ（Ｎ）は、該ユーザ端末ＵＥ（ｎ）が現在、呼設定中であるため、それに付随する呼情報（４８６：ビジー）をレスポンスに含めて着信側ＳＩＰサーバ（Ｋ）に通知する（１−４）。着信側ＳＩＰサーバ（Ｋ）は、該レスポンスを正常に受信したことを示すメッセージ（ＡＣＫ）を送信した後（１−５）、該レスポンスに含まれる情報を判断材料として用い、ユーザ端末ＵＥ（ｎ）の認証を実施する。
【００２８】
認証の結果、ユーザ端末ＵＥ（ｎ）は、正当なユーザ端末であると判定され、着信側ＳＩＰサーバ（Ｋ）は、着信者ユーザ端末ＵＥ（ｋ）への接続を許可し、着信者ユーザ端末ＵＥ（ｋ）に着信リクエスト（ＩＮＶＩＴＥ）を送信する（１−６）。以降のシーケンス（１−７〜１−２１）は、図９の従来の呼設定シーケンス（９−４〜９−１８）と同様である。
【００２９】
尚、図１のシーケンス例では、発信側ＳＩＰサーバ（Ｎ）が着信側ＳＩＰサーバ（Ｋ）からの折り返しの新規発信リクエストに対してレスポンスを返送する例を示している。しかし、このレスポンスは、発信者ＳＩＰ端末ＵＥ（ｎ）が送信する形態とすることも、ＳＩＰプロトコルの範疇で許容されている。何れの形態でも、開示の発信者認証に実質的な影響は与えないので、以降説明するシーケンス例では、このレスポンスは、発信側ＳＩＰサーバ（Ｎ）で送信する形態について説明する。
【００３０】
図２に発信元の詐称が行われた第１のシーケンス例を示す。この例は、悪意ユーザが正当なユーザ端末ＵＥ（ｎ）の名前を不正に騙って、その攻撃対象であるユーザ端末ＵＥ（ｋ）に発信を行った例である。悪意ユーザが、着信者ユーザ端末ＵＥ（ｋ）を収容する着信側ＳＩＰサーバ（Ｋ）に対して、恰も正当なユーザ端末ＵＥ（ｎ）からの発信リクエストのメッセージ（ＩＮＶＩＴＥ）を送信したとする（２−１）。
【００３１】
着信側ＳＩＰサーバ（Ｋ）は、事前には該発信リクエストを送信したユーザが正当なユーザかどうかを判断することはできない。そこで、着信側ＳＩＰサーバ（Ｋ）は、発信者認証を実施するために、まず、該発信リクエストに含まれていた発信者ユーザ端末ＵＥ（ｎ）のアドレス宛てに、折り返しの新規発信リクエスト（ＩＮＶＩＴＥ）を送信する（２−２）。
【００３２】
正規のユーザ端末ＵＥ（ｎ）を実際に収容するＳＩＰサーバ（Ｎ）は、上記の折り返しの新規発信リクエストを受信すると、該ユーザ端末ＵＥ（ｎ）が該新規発信リクエストを受付け可能な状態であるかの確認を行う。受け付け可能な状態の場合、該ユーザ端末ＵＥ（ｎ）に該新規発信リクエストを転送する（２−３）。
【００３３】
正規のユーザ端末ＵＥ（ｎ）からは、リクエストの成功（受付け可）を示すレスポンス（２００）が、ＳＩＰサーバ（Ｎ）を経由してＳＩＰサーバ（Ｋ）に返送される（２−４）。ＳＩＰサーバ（Ｋ）は、そのレスポンスの正常受信を示す応答（ＡＣＫ）を、ＳＩＰサーバ（Ｎ）を経由して正規のユーザ端末ＵＥ（ｎ）に送信する（２−５）。
【００３４】
このＳＩＰによる呼設定シーケンスの結果、通話の状態に至り、着信側ＳＩＰサーバ（Ｋ）は、その呼情報を含むレスポンスを受信する。その際、着信側ＳＩＰサーバ（Ｋ）は、該レスポンスに含まれる呼情報を判断材料として、先の発信リクエスト（２−１）における発信者ユーザ端末ＵＥ（ｎ）に対する認証処理を実施する。
【００３５】
この例では、該発信者ユーザ端末ＵＥ（ｎ）に対する折り返しの発信リクエストによる認証処理で通話状態となったことから、発信元情報の詐称有りと判定する。以降は、着信側ＳＩＰサーバ（Ｋ）は、認証処理とは別の処理として、不正に発信者に成りすまされたれた被害者ユーザ端末ＵＥ（ｎ）に被害を通知する音声ガイダンスを送信する（２−６）。また、悪意ユーザの攻撃対象となった着信者ユーザ端末ＵＥ（ｋ）に、別途発信リクエストを送信し（２−７）、その被害を通知する音声ガイダンスを送信する（２−８）。
【００３６】
尚、想定される悪意ユーザの企みの例として、例えば、攻撃対象ユーザの金融機関の口座番号や個人情報を直接聞き出すなどのために、金融機関等の名称が発信元として表示されるよう、知名度の高い金融機関等の名称を不正に騙って発信する例などがある。また、オレオレ詐欺を企む場合に、実在する息子や近親者等の電話番号を不正に騙って、その親元等を攻撃対象として発信する例などがある。
【００３７】
このような発信者の詐称に対して上述の認証処理により、着信側ＳＩＰサーバ（Ｋ）で不正を検出した場合、該発信リクエストに対する処置については、該着信側ＳＩＰサーバ（Ｋ）が属するネットワークの運用ポリシーに依存する。その処置の一例としては、不正な発信リクエストを一切無視する、何らかのエラーレスポンスを返送する、或いは上述のように被害を通知するガイダンスを被害者に送信するなどの処理を行う構成とすることができる。
【００３８】
更に、着信側ＳＩＰサーバ（Ｋ）は、悪意ユーザからの不正発信を認識しつつも、該悪意ユーザについての情報収集を行うために、着信側ＳＩＰサーバ（Ｋ）が逆に被害者側のユーザ端末ＵＥ（ｋ）に成り代わって応答し、該悪意ユーザとの通話路を確立する構成とすることもできる。
【００３９】
図３に発信元情報の詐称が行われた第２の例を示す。この第２の例は、実在するユーザ端末ＵＥ（ｎ）を詐称した第１の例に対して、実在しないユーザ端末ＵＥ（ｎ）を悪意ユーザが詐称した例である。悪意ユーザが、着信者ユーザ端末ＵＥ（ｋ）を収容する着信側ＳＩＰサーバ（Ｋ）に対して、実在しないユーザ端末ＵＥ（ｎ）を発信元とする発信リクエスト（ＩＮＶＩＴＥ）を送信したとする（３−１）。
【００４０】
第１の例と同様に、着信側ＳＩＰサーバ（Ｋ）は、事前には該発信リクエストを送信したユーザが実在するのかどうかも含めて正当なユーザかどうかを判断することはできない。そこで、着信側ＳＩＰサーバ（Ｋ）は、発信者認証を実施するために、発信リクエストに含まれていた発信者ユーザ端末ＵＥ（ｎ）のアドレス宛てに、折り返しの新規発信リクエスト（ＩＮＶＩＴＥ）を送信する（３−２）。
【００４１】
このユーザ端末ＵＥ（ｎ）は実在しないため、該折り返しの新規発信リクエスト（ＩＮＶＩＴＥ）を受信した発信側のサーバ（Ｎ）は、不許可を示すレスポンス（４０３：Ｆｏｒｂｉｄｄｅｎ）を着信側ＳＩＰサーバ（Ｋ）に送信する（３−３）。着信側ＳＩＰサーバ（Ｋ）は、該レスポンスを受信し、該レスポンスの正常受信を示す応答（ＡＣＫ）を返送する（３−４）。
【００４２】
着信側ＳＩＰサーバ（Ｋ）は、該レスポンスの情報を判断材料として、該ユーザ端末ＵＥ（ｎ）に対する認証を実施し、発信元情報の詐称を検出する。着信側ＳＩＰサーバ（Ｋ）は、悪意ユーザの攻撃対象となった着信者ユーザ端末ＵＥ（ｋ）に、別途発信リクエストを送信し（３−５）、その被害を通知する音声ガイダンスを送信する（３−６）。
【００４３】
尚、ここで想定される悪意ユーザの企みとしては、ＳＩＰサーバ（Ｋ）が属するシステムの攻撃に対する耐性や、攻撃対象のユーザ端末ＵＥ（ｋ）へのリーチャビリティ等を調査するために、このような不正な発信リクエストを送信することが想定される。このような不正な発信に対して、この認証機能を有するＳＩＰサーバ（Ｋ）又はＳＩＰ端末ＵＥ（ｋ）を備えたシステムは、上述の認証シーケンスで得られる情報を、悪意ユーザからの攻撃開始の予兆として活用することができる。
【００４４】
上述の認証機能を実現するためのシステム構成について図４を参照して説明する。図４にＳＩＰサーバ又はＳＩＰ端末における上述の認証処理を行うための機能ブロック構成を示す。図４において、太枠で囲まれた機能部がこの認証機能を実現する機能部である。
【００４５】
上述の認証機能を実現する機能部について説明する。発信者認証を行う機能部として認証コールバック処理部４−１及び認証実施部４−２を備える。また、不正発信の被害に対する処理機能として、被害対応制御処理部４−３を備える。該被害対応制御処理部４−３には、被害情報通知処理部４−３１及び被害情報収集処理部４−３２を備える。
【００４６】
上述の認証コールバック処理部４−１及び被害対応制御処理部４−３は、ＳＩＰ処理の最上位のＳＩＰアプリケーション層４−５に、基本通話処理部４−４と共に配備される。ＳＩＰアプリケーション層４−５は、階層化されたＳＩＰのプロトコルにおけるＳＩＰトランザクション層４−７及びＳＩＰセッション層４−６の上位層に位置する。
【００４７】
上述の認証実施部４−２は、ＳＩＰ処理の機能部とは別に、ＳＩＰサーバ又はＳＩＰ端末内に配備される。また、ＳＩＰサーバ又はＳＩＰ端末内には、該認証機能の実行制御等に使用されるシステムコンフィグレーションファイル４−８が備えられる。
【００４８】
認証コールバック処理部４−１は、上述の認証機能を実行する際に起動され、折り返しの新規発信リクエストを生成し、該折り返しの新規発信のシーケンスを管理する機能部である。また、この認証コールバック処理部４−１では、ＳＩＰメッセージに含まれる呼情報から、認証実行に用いる情報を抽出して認証実施部４−２に通知し、該認証実施部４−２から認証の結果を受け取る。そして、認証の結果が不正発信の判定結果（ＮＧ）であった場合には、被害対応制御処理部４−３に該不正発信の認証結果の通知を行う。
【００４９】
認証実施部４−２への入力情報は、ＳＩＰメッセージであり、既存のＳＩＰ機能部からＳＩＰメッセージを受信する。認証実施部４−２は、認証処理を実行するのに用いる情報を認証コールバック処理部４−１から受け取り、発信者が正規の発信者である否かの認証を行い、その認証結果を認証コールバック処理部４−１に返却する。
【００５０】
被害対応制御処理部４−３は、不正発信の認証結果が通知された際に、認証コールバック処理部４−１から起動され、被害情報通知処理部４−３１又は被害情報収集処理部４−３２の一方又は双方を起動する。尚、認証コールバック処理部４−１からのこの被害対応制御処理部４−３への入力情報はＳＩＰメッセージとすることができる。
【００５１】
被害情報通知処理部４−３１は、被害者に発信者詐称等の被害を受けている旨を、音声ガイダンスやＳＭＳ（Short Message Service）等により通知するためのシーケンスを管理する。被害情報収集処理部４−３２は、発信者詐称等の被害情報に関するログ収集を行う。
【００５２】
更に被害情報収集処理部４−３２は、システムの運用ポリシーに応じて、例えば、不正ユーザからの発信リクエストを敢えて受け付け、悪意ユーザとの通話路を確立し、悪意ユーザを対象に更なる情報収集を行う構成とすることができる。尚、攻撃対象のユーザ端末を収容する着信側ＳＩＰサーバにおいて、この被害情報収集処理部４−３２が起動された場合には、該着信側ＳＩＰサーバが着信者ユーザ端末に成り代わって、悪意ユーザとの通話路を確立する。
【００５３】
以下に、この認証機能を具備するＳＩＰ通信装置の処理の動作例について図５を参照して説明する。図５はＳＩＰサーバ（Ｋ）における動作例を示している。まず、正当な発信者の端末ＵＥ（ｎ）から着信者のユーザ端末ＵＥ（ｋ）宛ての発信リクエスト（ＩＮＶＩＴＥ）が送信され、該発信リクエスト（ＩＮＶＩＴＥ）が着信側ＳＩＰサーバ（Ｋ）で受信されたとする。
【００５４】
該発信リクエスト（ＩＮＶＩＴＥ）を受信した着信側ＳＩＰサーバ（Ｋ）の基本通話処理部４−４は、該システムコンフィグレーションファイル４−８を参照して当該ＳＩＰサーバの認証方式を問い合わせ、認証方式の情報を取得する。該認証方式が上述の認証方式の場合、基本通話処理部４−４は、認証コールバック処理部４−１に対してコールバック処理のシナリオを起動する（Ａ）。
【００５５】
認証コールバック処理部４−１は、着信側ＳＩＰサーバ（Ｋ）を発信元とし、ユーザ端末ＵＥ（ｎ）を発信先とする折り返しの新規発信リクエストを送信する（Ｂ）。認証コールバック処理部４−１は、該新規発信リクエストに対するユーザ端末ＵＥ（ｎ）からのレスポンスを受信する（Ｃ）。
【００５６】
認証コールバック処理部４−１は、該レスポンスに含まれる情報の中から認証に用いる情報を抽出する（Ｄ）。認証コールバック処理部４−１は、該認証に用いる情報を認証実施部４−２に通知し、認証を要求する（Ｅ）。認証実施部４−２は、通知された情報を基に認証処理を実施し、認証結果を認証コールバック処理部４−１に応答する（Ｆ）。
【００５７】
認証コールバック処理部４−１は、該認証結果が正常（ＯＫ）の場合は、処理を基本通話処理部４−４へ返却する（Ｇ）。処理を返却された基本通話処理部４−４は、着信者端末ＵＥ（ｋ）に着信リクエスト（ＩＮＶＩＴＥ）を送信する。
【００５８】
一方、認証コールバック処理部４−１は、該認証結果が異常（ＮＧ）の場合は、被害対応制御処理部４−３を起動する（Ｈ）。被害対応制御処理部４−３は、被害情報通知処理部４−３１により、不正に発信者に成りすまされたれた被害者ユーザ端末ＵＥ（ｎ）又は悪意ユーザの攻撃対象となった着信者ユーザ端末ＵＥ（ｋ）に、被害を通知する音声ガイダンスを送信する。また、被害対応制御処理部４−３は、被害情報収集処理部４−３２により、悪意ユーザに関する情報収集を行い、悪意ユーザとの通話路を確立し、その過程のシーケンスで得られる呼情報を収集し、被害情報の収集を行う。
【００５９】
ここで、発信者認証の手法について説明する。まず、この認証処理で参照する呼情報について説明する。呼情報は、ＳＩＰ端末又はＳＩＰサーバのＳＩＰ通信装置で管理される情報であり、ＳＩＰメッセージのリクエスト又はレスポンスの情報及びそれらに含まれるヘッダ情報から得られるである。認証に用いる呼情報として、（１）発信者情報、（２）着信者情報、（３）セッションＩＤ、（４）セッション状態及び（５）起動中セッションＩＤを用いることができる。以下に、これらの情報について説明する。
【００６０】
（１）発信者情報
発信者情報のデータ属性はＳＩＰ−ＵＲＩ（アドレス情報）であり、ＳＩＰメッセージのＦｒｏｍヘッダから取得される。発信者は、ＳＩＰセッションの確立を要求する発側のユーザである。認証の判定材料として以下の情報が利用されるが、その情報（属性値）を抽出するための検索キーとしてこの発信者情報が用いられる。尚、この発信者情報は、詐称を受けた被害者情報である可能性があり、その場合には被害を該被害者に通知するための宛先情報として参照される。
【００６１】
（２）着信者情報
着信者情報のデータ属性はＳＩＰ−ＵＲＩ（アドレス情報）であり、ＳＩＰメッセージのＴｏヘッダから取得される。着信者情報は、発信を受けた着側のユーザ端末の情報である。発信者認証の処理で認証異常（ＮＧ）が検出された場合、この着信者情報は、悪意ユーザからの攻撃対象となっているユーザの情報である可能性があり、その場合には、その旨を通知するための宛先情報として参照される。
【００６２】
（３）セッションＩＤ
セッションＩＤのデータ属性は文字列であり、ＳＩＰメッセージのＣａｌｌ−ＩＤヘッダから取得される。セッションＩＤは、呼設定のセッションを特定するための情報である。
（４）セッション状態
セッション状態のデータ属性としては、初期状態、呼設定中、通話中又は切断中を示す情報である。ＳＩＰメッセージとの関係では、ＳＩＰ−Ｍｅｔｈｏｄ／Ｓｔａｔｕｓ−Ｃｏｄｅとして取得される。このセッション状態の情報は、呼設定時の特定のセッションの状態であり、発信者認証の主要な判断材料として用いられる。このセッション状態は、発信から終話までのＳＩＰシーケンスの各ポイントにおいて、各ＳＩＰトランザクションのＳＩＰ−Ｍｅｔｈｏｄ（ＳＩＰリクエストの種類）やＳｔａｔｕｓ−Ｃｏｄｅ（ＳＩＰレスポンス）を参照することにより把握される。
【００６３】
（５）起動中セッションＩＤ
起動中セッションＩＤのデータ属性は文字列であり、ＳＩＰメッセージとの関係では、ＳＩＰオプションパラメータの属性拡張により取得される。この属性拡張については後述する。用途としては、例えば、折り返しの新規発信リクエストを受けたＳＩＰ端末又は該ＳＩＰ端末を収容するＳＩＰサーバが、該ＳＩＰ端末が既に呼設定中のため応答不可の旨のＳＩＰエラーレスポンスを発信元に通知する際に、該ＳＩＰ端末で既に呼設定中のセッションＩＤの情報等を含めて通知する。この起動中セッションＩＤは、発信者認証に用いなくてもよいが、用いることにより一層精度の高い発信者認証を行うことが可能となる。
【００６４】
この発信者認証の手法は、着信側のＳＩＰ端末又はＳＩＰサーバにおいて、発信リクエストのＳＩＰメッセージ上に発信者として通知（表示）された発信者に対して、当該発信リクエストの着信者宛に正規に該発信者が発信している状態なのかどうかを問うことであり、その状態であれば、正規の発信者であると判定するものである。
【００６５】
そして、正規の発信者が発信をしている状態か否かは、前述の呼情報を基に判断する。この認証機能を具備するＳＩＰ通信装置（ＳＩＰ端末又はＳＩＰサーバ）は、発信者に対して新規に生成した折り返しの発信リクエスト（ＩＮＶＩＴＥ）を送信し、それに対するレスポンス情報から、当該発信者による呼のセッションの状態を特定し、発信者の認証判定を行う。
【００６６】
表１に認証判定方法の一覧を示す。表１において、Ｓｔａｔｕｓ−Ｃｏｄｅ（ＳＩＰ−Ｍｅｔｈｏｄ）は、レスポンスのＳＩＰメッセージに含まれるセッション状態を示す値である。起動中セッションＩＤは、レスポンスのＳＩＰメッセージに起動中セッションＩＤが含まれている場合は「有り」、含まれていない場合は「無し」と示している。
【００６７】
【表１】
2011217031.tif 000003
【００６８】
各セッション状態を示す値（１００以上２００未満、２００以上３００未満、３００以上４００未満、４００以上５００未満、５００以上７００未満）毎に、起動中セッションＩＤが含まれている場合と含まれていない場合とについて、認証判定方法及び認証実施の可否を示している。認証実施の可否の欄の「○」は認証実施可能を表し、「×」は認証実施不可を表し、「−」は認証実施が可能か不可かはそのセッション状態では判別できないことを示している。
【００６９】
図６に上述の認証判定方法による処理フロー例を示す。尚、この処理フロー例は、図４に示した認証実施部４−２における処理のフロー例である。まず、折り返し発信リクエストに対するレスポンスを受けると、該レスポンスに含まれる呼情報を読み出し（６−１）、該呼情報に起動中セッションＩＤが含まれているか否かを判定する（６−２）。
【００７０】
起動中セッションＩＤが含まれていない場合、ＳＩＰメッセージのＳｔａｔｕｓ−Ｃｏｄｅを読み出し、セッション状態を判定する（６−３）。まず、Ｓｔａｔｕｓ−Ｃｏｄｅが２００番未満か否かを判定する（６−４）。Ｓｔａｔｕｓ−Ｃｏｄｅが２００番台未満の場合は、呼び出し中又は転送中等の暫定的なレスポンスであり、認証判断は後続の最終レスポンス（２００番以上のレスポンス）を待って行うこととなる。従って、この場合の認証結果は判定不可となる。
【００７１】
Ｓｔａｔｕｓ−Ｃｏｄｅが２００番以上の場合、３００番未満であるか否かを判定する（６−５）。Ｓｔａｔｕｓ−Ｃｏｄｅが３００番未満である場合、折り返しの新規発信リクエストに対して受け付け可能（ＯＫ）を示すレスポンスが送信されたこととなり、この場合、該折り返し発信リクエストの送信先は、先の発信リクエストの発信者と異なることとなり、認証結果異常（ＮＧ）の判定結果を返却する（６−１１）。
【００７２】
Ｓｔａｔｕｓ−Ｃｏｄｅが３００番以上の場合、４００番未満であるか否かを判定する（６−６）。Ｓｔａｔｕｓ−Ｃｏｄｅが４００番未満の場合、セッション情報を特定することができず、認証の実施は不可であり、認証結果は判定不可と成る。
【００７３】
Ｓｔａｔｕｓ−Ｃｏｄｅが４００番以上の場合、Ｓｔａｔｕｓ−Ｃｏｄｅが５００番未満であるか否かを判定する（６−７）。Ｓｔａｔｕｓ−Ｃｏｄｅが５００番未満の場合、Ｓｔａｔｕｓ−Ｃｏｄｅが話中状態を示す４８６番又は４８８番であるか否かを判定し（６−８）、４８６番又は４８８番である場合は、認証結果正常（ＯＫ）の判定結果を返却する（６−１０）。Ｓｔａｔｕｓ−Ｃｏｄｅが４８６番又は４８８番以外である場合は、認証の実施は不可であり、認証結果は判定不可となる。
【００７４】
Ｓｔａｔｕｓ−Ｃｏｄｅが５００番以上の場合、Ｓｔａｔｕｓ−Ｃｏｄｅが６００番であるか否かを判定する（６−９）。Ｓｔａｔｕｓ−Ｃｏｄｅが６００番の場合、話中（Ｂｕｓｙ  Ｅｖｅｒｙｗｈｅｒｅ）であることを示すので、認証結果正常（ＯＫ）の判定結果を返却する（６−１０）。Ｓｔａｔｕｓ−Ｃｏｄｅが６００番以外である場合は、認証の実施は不可であり、認証結果は判定不可となる。
【００７５】
一方、前述の呼情報に起動中セッションＩＤが含まれている場合、該起動中セッションＩＤと先の発信リクエストのセッションＩＤとを比較し（６−１２）、一致するか否かを判定する（６−１３）。不一致の場合は、Ｓｔａｔｕｓ−Ｃｏｄｅの読み出しを実施する（６−３）。
【００７６】
起動中セッションＩＤと先の発信リクエストのセッションＩＤとが一致する場合、該起動中セッションＩＤのセッション状態を読み出す（６−１４）。該起動中セッションＩＤのセッション状態が、呼設定中であるか否かを判定し（６−１５）、呼設定中であれば、認証結果正常（ＯＫ）の判定結果を返却する（６−１０）。呼設定中でない場合は、Ｓｔａｔｕｓ−Ｃｏｄｅの読み出しを実施する（６−３）。
【００７７】
次に起動中セッションＩＤ通知のためのＳＩＰパラメータの属性拡張の一例について説明する。このパラメータの通知には、新規にＳＩＰヘッダを規定する方法、又は新規にＳＩＰパラメータを規定する方法があるが、ここでは後者の例を示す。ここではＲＦＣ３３２６規定のＲｅａｓｏｎヘッダにおけるＳＩＰパラメータ拡張の具体例を示す。
【００７８】
表２に起動中セッションＩＤ通知のためのＳＩＰパラメータ拡張の例を示す。
【表２】
2011217031.tif 000004
【００７９】
表２における下線を施したパラメータ“ｓｅｓｓｉｏｎ−ｉｄ”が起動中セッションＩＤ情報を通知のためのＳＩＰパラメータ拡張の部分である。具体的なＳＩＰメッセージ例を図７に示す。このパラメータの拡張により、どのセッションＩＤがどのセッション状態にあるかを相手に通知することが可能となる。
【００８０】
図７の（ａ）は、“ａｌｉｃｅ＠ｅｘａｍｐｌｅ．ｃｏｍ”のセッションが通話中であることを表し、図７の（ｂ）は、“ｂｏｂ＠ｅｘａｍｐｌｅ．ｃｏｍ”のセッションが終話の状態であることを表し、図７の（ｃ）は、“ｃａｒｏｌ＠ｅｘａｍｐｌｅ．ｃｏｍ”のセッションが話中であることを表し、図７の（ｄ）は、“ｄａｖｅ＠ｅｘａｍｐｌｅ．ｃｏｍ”のセッションがネゴシエーションエラーとなったことを表している。
【００８１】
尚、このＳＩＰパラメータ拡張を含むＲｅａｓｏｎヘッダは、複数のセッションを張ることが許容されている場合には、各々のセッション状態を通知するために複数ＳＩＰメッセージ上に設定されることが許容されるものである。
【００８２】
次にこの認証機能に関連する拡張サービスの実現について説明する。上述の発信者認証処理により認証異常（ＮＧ）、即ち発信元情報の詐称等を検出した場合、その被害者に関する情報が呼情報に含まれているため、この認証処理の延長として被害者に被害通知を送信するサービスの適用が可能である。ここでは一例として音声ガイダンスにより被害者へ被害通知を送信する処理フロー例を図８に示す。この処理フローは図２及び図３に対応するものである。
【００８３】
被害対応制御処理部４−３は、被害者へ音声ガイダンスを送信し、或いは悪意ユーザからの発信に敢えて応答して該発信に係る不正ログを記録するなどのサービスを実施する。ここで、悪意ユーザに不正に名前を悪用された被害者を被詐称被害者（前述のシーケンス例ではＵＥ（ｎ）に相当）、悪意ユーザの発信先となったユーザを攻撃被害者（前述のシーケンス例ではＵＥ（ｋ）に相当）と呼ぶことにする。被害者対応制御処理部４−３への入力として、認証実施部４−２への入力と同様、ＳＩＰメッセージの呼情報を含めることにより、被詐称被害者及び攻撃被害者の双方の情報を被害者対応制御処理部４−３で把握し、各々への音声ガイダンスを送出することが可能となる。
【００８４】
被害者対応制御処理部４−３は、認証実施部４−２において認証異常（ＮＧ）と判定された場合に起動され、被害者対応制御シナリオを実行する（８−１）。該被害者対応制御シナリオとして、被害情報通知シナリオ又は被害情報収集シナリオを選択する（８−２）。被害情報通知シナリオが選択された場合、折り返しの新規発信リクエストに対するレスポンスのＳｔａｔｕｓ−Ｃｏｄｅを読出す（８−３）。
【００８５】
該Ｓｔａｔｕｓ−Ｃｏｄｅが２００番（即ち、該新規発信リクエストが受付け可能）か否かを判定する（８−４）。該Ｓｔａｔｕｓ−Ｃｏｄｅが２００番の場合には、該新規発信リクエストにより被詐称被害者ＵＥ（ｎ）とのセッションが確立しているので、被害対応制御処理部４−３は当該セッションにより被害通知のサービスガイダンスを送信する（８−５）。該Ｓｔａｔｕｓ−Ｃｏｄｅが２００番以外の場合は、被詐称被害者ＵＥ（ｎ）とのセッションが確立していないので、被詐称被害者ＵＥ（ｎ）への被害通知のサービスガイダンスは送信しない。
【００８６】
一方、攻撃被害者ＵＥ（ｋ）とのセッションは未確立であるので、ＳＩＰのプロトコルの構成上、その下位に位置する基本通話処理部４−４の機能を用いて、新規に攻撃被害者端末ＵＥ（ｋ）とのセッションを確立し（８−６）、該攻撃被害者へのサービスガイダンスを送信する（８−７）。
【００８７】
被害対応制御処理部４−３が、被害情報収集シナリオを選択した場合、基本通話処理部４−４の既存機能部に悪意ユーザの発信リクエストに対する応答を送出するよう指示し（８−８）、悪意ユーザとのセッションを確立する。そして該セッションに対するＳＩＰシーケンスのログ記録を行う（８−９）。
【符号の説明】
【００８８】
４−１  認証コールバック処理部
４−２  認証実施部
４−３  被害対応制御処理部
４−３１  被害情報通知処理部
４−３２  被害情報収集処理部
４−４  基本通話処理部
４−５  ＳＩＰアプリケーション層
４−６  ＳＩＰセッション層
４−７  ＳＩＰトランザクション層
４−８  システムコンフィグレーションファイル
【図１】
2011217031.tif 000005
【図２】
2011217031.tif 000006
【図３】
2011217031.tif 000007
【図４】
2011217031.tif 000008
【図５】
2011217031.tif 000009
【図６】
2011217031.tif 000010
【図７】
2011217031.tif 000011
【図８】
2011217031.tif 000012
【図９】
2011217031.tif 000013