(57)【特許請求の範囲】
【請求項１】
保護されたデータを送信機ユニットから受信機ユニットへ、中間ユニットを介して送信するための方法であって、
前記中間ユニットが、
前記受信機ユニットに属する証明書に関連付けられた情報と、前記中間ユニットに属する証明書に関連付けられた情報とを保存するステップと、
前記送信機ユニットから、前記保護されたデータを前記受信機ユニットに送信するための要求を受信するステップと、
前記受信機ユニットに属する前記証明書に関連付けられた前記情報を含んだ応答を、前記送信機ユニットに送信するステップと、
前記送信機ユニットから、前記受信機ユニットに属する前記証明書に関連付けられた前記情報を用いて保護された、後で前記受信機ユニットに転送するためのデータを受信するステップとを有し、
前記中間ユニットに属する前記証明書は前記受信機ユニットによって署名されていることを特徴とする方法。
【請求項２】
前記受信機ユニットに属する前記証明書に関連付けられた前記情報が、前記受信機ユニットに属する前記証明書と、前記受信機ユニットに属する前記証明書の位置を特定する情報との一方を有し、
前記中間ユニットに属する前記証明書に関連付けられた前記情報が、前記中間ユニットに属する前記証明書と、前記中間ユニットに属する前記証明書の位置を特定する情報との一方を有することを特徴とする請求項１記載の方法。
【請求項３】
前記送信機ユニットからの、前記保護されたデータを前記受信機ユニットに送信するための要求が、前記送信機ユニットと前記中間ユニットとの間の、前記中間ユニットに属する前記証明書に基づくホップバイホップ保護の要求と、前記送信機ユニットと前記受信機ユニットとの間のエンドツーエンド保護の要求とを有し、
前記応答が、前記中間ユニットと前記送信機ユニットとの間の前記ホップバイホップ保護の承諾と、前記中間ユニットと前記送信機ユニットとの間のエンドツーエンド保護の拒否とを有することを特徴とする請求項１または請求項２記載の方法。
【請求項４】
前記中間ユニットが、
前記受信機ユニットから、前記保護されたデータの要求であって、ホップバイホップおよびエンドツーエンド管理要求を含んだ要求、を受信するステップと、
前記保護されたデータの前記要求に応答して、前記保護されたメディアデータを前記受信機ユニットに送信するステップと、をさらに有することを特徴とする請求項１乃至請求項３のいずれか１項に記載の方法。
【請求項５】
前記保護されたデータが、セキュアリアルタイムトランスポートプロトコルデータと、セキュア多目的インターネットメール拡張データとの一方から選択されることを特徴とする請求項１乃至請求項４のいずれか１項に記載の方法。
【請求項６】
前記中間ユニットがセキュアリアルタイムトランスポートプロトコル蓄積転送メールボックスであることを特徴とする請求項１乃至請求項５のいずれか１項に記載の方法。
【請求項７】
通信ネットワークにおいて送信機ユニットから送信される保護されたデータを、受信機ユニットの代わりに受信するための中間ユニットであって、
前記受信機ユニットに属する証明書に関連付けられた情報と、前記中間ユニットの証明書に関連付けられた情報とを保存するメモリと、
前記送信機ユニットから、前記保護されたデータを前記受信機ユニットに送信するための要求を受信する通信機能と、
メッセージを処理するプロセッサとを有し、
前記中間ユニットに属する前記証明書は前記受信機ユニットによって署名されており、
前記通信機能は、前記受信機ユニットに属する前記証明書に関連付けられた前記情報を含んだ応答を、前記送信機ユニットに送信するように構成され、
前記通信機能はさらに、前記送信機ユニットから、前記受信機ユニットに属する前記証明書に関連付けられた前記情報を用いて保護されたデータを受信するように構成されることを特徴とする中間ユニット。
【請求項８】
前記受信機ユニットに属する前記証明書に関連付けられた前記情報が、前記受信機ユニットに属する前記証明書と、前記受信機ユニットに属する前記証明書の位置を特定する情報との一方を有し、
前記中間ユニットに属する前記証明書に関連付けられた前記情報が、前記中間ユニットに属する前記証明書と、前記中間ユニットに属する前記証明書の位置を特定する情報との一方を有することを特徴とする請求項７記載の中間ユニット。
【請求項９】
前記プロセッサが、
前記送信機ユニットと前記中間ユニットとの間の、前記中間ユニットに属する前記証明書に基づくホップバイホップ保護の要求と、
前記送信機ユニットと前記受信機ユニットとの間のエンドツーエンド保護の要求とを処理するように構成され、
前記プロセッサはさらに、前記中間ユニットと前記送信機ユニットとの間の前記ホップバイホップ保護の承諾と、前記中間ユニットと前記送信機ユニットとの間のエンドツーエンド保護の拒否とを有する前記応答メッセージを生成するように構成されることを特徴とする請求項７または請求項８記載の中間ユニット。
【請求項１０】
前記受信した保護されたデータを保存するための第２のメモリをさらに有することを特徴とする請求項７乃至請求項９のいずれか１項に記載の中間ユニット。
【請求項１１】
前記保護されたデータの要求であって、ホップバイホップおよびエンドツーエンド管理の要求を含んだ要求を前記受信機ユニットから受信するための第２の通信機能をさらに有し、
前記第２の通信機能はさらに、前記保護されたデータの要求に応答して前記保護されたメディアデータを前記受信機ユニットに送信するように構成されることを特徴とする請求項７乃至請求項１０のいずれか１項に記載の中間ユニット。
【請求項１２】
前記中間ユニットがセキュアリアルタイムトランスポートプロトコル蓄積転送メールボックスであることを特徴とする請求項７乃至請求項１１のいずれか１項に記載の中間ユニット。
【請求項１３】
保護されたデータを、送信機ユニットが中間ユニットを介して受信機ユニットへ送信する通信ネットワークにおいて用いるための受信機ユニットであって、
前記中間ユニットに属する証明書を取得する証明書取得機能と、
前記中間ユニットに属する前記証明書を前記受信機ユニットに属する証明書に対応する秘密鍵を用いて署名する証明書処理機能と、
前記中間ユニットに属する前記署名された証明書と前記受信機ユニットに属する前記証明書とを前記中間ユニットに送信する通信機能とを有することを特徴とする受信機ユニット。
【請求項１４】
前記中間ユニットに保存された前記受信機ユニット宛の保護されたデータの要求メッセージであって、ホップバイホップおよびエンドツーエンド管理の要求を含んだ要求メッセージを生成するメッセージ処理機能をさらに有し、
前記通信機能が、前記要求メッセージを前記中間ユニットに送信し、その後前記要求した保護されたデータを前記中間ユニットから受信するように構成され、
前記受信した保護されたデータを処理する保護データ処理機能をさらに有することを特徴とする請求項１３記載の受信機ユニット。
【請求項１５】
保護されたデータを、送信機ユニットが中間ユニットを介して受信機ユニットへ送信する通信ネットワークにおいて用いるための送信機ユニットであって、
保護されたデータを送信するセッションの確立を要求する、前記受信機ユニット宛の要求メッセージを生成するメッセージ処理機能と、
前記要求メッセージを前記受信機ユニットへ送信する通信機能であって、
前記中間ユニットから前記要求メッセージに対する、前記受信機ユニットに属する証明書を特定する情報を有する応答を受信するように構成された通信機能と、
前記受信機ユニットに属する前記証明書を用いてデータを保護するデータ処理機能とを有し、
前記通信機能はさらに、前記中間ユニットに前記保護されたデータを送信するように構成されることを特徴とする送信機ユニット。
【請求項１６】
前記メッセージ処理機能は、前記送信機ユニットと前記中間ユニットとの間のホップバイホップ保護の要求と前記送信機ユニットと前記受信機ユニットとの間のエンドツーエンド保護の要求とを有するように前記要求メッセージを生成するように構成され、
前記通信機能は、前記中間ユニットと前記送信機ユニットとの間の前記ホップバイホップ保護の承諾と、前記中間ユニットと前記送信機ユニットとの間のエンドツーエンド保護の拒否とを有する前記応答を受信するように構成されることを特徴とする請求項１５記載の送信機ユニット。
【請求項１７】
前記保護されたデータが、セキュアリアルタイムトランスポートプロトコルデータと、セキュア多目的インターネットメール拡張データとの一方から選択されることを特徴とする請求項１５または請求項１６に記載の送信機ユニット。
【請求項１８】
中間ユニットで実行された際に、請求項１乃至請求項６のいずれか１項に記載の方法を前記中間ユニットに行わせるためのコンピュータプログラム。
【請求項１９】
受信機ユニットで実行された際に、前記受信機ユニットを請求項１３または請求項１４に記載の受信機ユニットとして機能させるためのコンピュータプログラム。
【請求項２０】
送信機ユニットで実行された際に、前記送信機ユニットを請求項１５乃至請求項１７のいずれか１項に記載の送信機ユニットとして機能させるためのコンピュータプログラム。
【請求項２１】
請求項１８乃至請求項２０のいずれか１項に記載のコンピュータプログラムを格納したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は保護されたものを通信ネットワーク内で送信する技術に関する。
【背景技術】
【０００２】
リアルタイムトランスポートプロトコル(RTP)は、音声および映像メディアデータをパケット交換ネットワーク上で配信するためのプロトコルである。ＲＴＰはリアルタイムに伝送し、インタラクティブオーディオおよびビデオのようなメディアデータをストリーミングするために用いられる。そのため、ＩＰＴＶ、会議、ＶｏＩＰ(Voice over IP)といった用途に用いられる。
【０００３】
IETF RFC 3711に規定されているセキュアリアルタイムトランスポートプロトコル(SRTP)は、暗号化されたＲＴＰの形式を提供する、トランスポートセキュリティプロトコルである。暗号化に加え、ＳＲＴＰは、ユニキャスト、マルチキャスト、およびブロードキャストアプリケーションにおけるメッセージ認証および完全性(integrity)、並びに再生保護を提供する。ＳＲＴＰは、ＲＴＰセッションにおけるピア間に配信されるコンテンツを保護するために用いられる。ＳＲＴＰはトランスポートセキュリティプロトコルであり、ＳＲＴＰを実行中の２つのピア間での搬送中にデータを保護することだけを目的としている。特に、ＳＲＴＰはＳＲＴＰセッションのエンドポイントに配信済みのデータの保護は行わない。加えて、送信ピアがメディアデータの暗号化による保護を提供する。つまり、全てのキーとなる情報(keying material)についての知見を送信ピアが有しており、送信ピアがデータの保護を適用するものとされている。
【０００４】
ＲＴＰはＲＴＰセッションを制御するために用いることのできるＲＴＣＰ（ＲＴＰ制御プロトコル）と密接な関係を有し、また同様にＲＴＣＰはセキュアＲＴＣＰ（またはＳＲＴＣＰ）と呼ばれるシスタープロトコルを有する。ＳＲＴＣＰは、ＳＲＴＰがＲＴＰに提供するものと同じセキュリティ関連機能をＲＴＣＰに提供する。
【０００５】
ＳＲＴＰまたはＳＲＴＣＰの利用は、ＲＴＰまたはＲＴＣＰの利用におけるオプションである。しかし、ＳＲＴＰ／ＳＲＴＣＰが用いられたとしても、（暗号化および認証といった）提供される機能の全てはオプションであり、また個別に有効化または無効化することができる。唯一の例外はメッセージ認証／完全性機能であり、ＳＲＴＣＰを用いる場合には必須とされる。ＳＲＴＰおよびＳＲＴＣＰにおける機密性保護はペイロードをカバーし、完全性保護はペイロードおよびフルパケットヘッダをカバーする。
【０００６】
図１を参照すると、多数のコンテンツ配信システムおよび通信サービスが蓄積交換(SaF)機構を含み、メディアのエンドツーエンドの機密性および完全性保護を必要としている。このような状況において、送信機ユニット１が送信機ユニット１と中間蓄積エンティティ２との間の第１ホップにメディアを送信し、その後（ほぼ直ちに、あるいは少し後に）メディアは、蓄積エンティティ２と意図された受信機ユニット３との間の第２ホップを横断する。なお、メディアは複数の中間ユニットを通ってもよい。しかし、（ＳａＦサーバのような）中間ユニットでの各ホップは、完全性保護されねばならない。（ここで、「ホップ」という用語は、ネットワーク内で論理的に隣接する２つのノード間の論理リンクを意味している）。これは、中間ユニット２が、例えば、メールボックスやネットワーク留守番電話がメディアを蓄積する場所に到着するメディアデータパケットの信憑性をチェックできるようにするために必要である。これは、装置の記憶装置を不要なデータで一杯にする攻撃者から保護するために必要である。しかし、メディアの暗号化を解いたり、エンドツーエンド(e2e)完全性保護の計算／変更を行ったりするために必要な鍵は、中間ユニットが操作されたりプレインテキストメディアデータにアクセスされたりしないために、中間ユニットが利用できるようにすべきでない。
【０００７】
ＳＲＴＰは、メディアデータを送信機ユニット１と受信機ユニット３との間のエンドツーエンド保護とともにメディアデータを提供することにより、中間ユニットがデータにアクセスしないことを保証しつつ、中間ユニットを介してデータが送信されるようにすることができる。
【０００８】
メディアデータを中間ユニット２から受信機ユニット３に転送するために考えられる方法は、例えばメディアデータを、メディアデータを蓄積するために用いていたフォーマットで送信することによるファイル転送である。しかし、この種の転送はＳＲＴＰでサポートされていない。
【０００９】
中間ユニット２を偽造データで埋めるかもしれない攻撃を避けるため、中間ユニット２がメディアデータの送信機ユニット１を認証し、さらにメディアデータの信憑性を検証することを保証することが好都合であろう。これは、ホップバイホップ(hbh)鍵／セキュリティコンテキストが送信機ユニット１と中間ユニット２との間で確立されることを必要とする。
【００１０】
従って、２つの独立したセキュリティコンテキスト、すなわち、送信機ユニット１と受信機ユニット３との間のデータを（暗号化または完全性保護によって）保護するための１つのエンドツーエンド(e2e)セキュリティコンテキストと、中間ユニット２が送信機ユニット１を認証するとともにメディアデータを認証できるようにするための、送信機ユニット１と中間ユニット２との間の１つのｈｂｈセキュリティコンテキスト、に対する必要性が存在する。ｈｂｈ鍵確立について、マルチメディアインターネットキーイング(MIKEY)やデータグラムトランスポートレイヤセキュリティーＳＲＴＰ（ＤＴＬＳーＳＲＴＰ）のような任意の既存の鍵管理手法を用いることができるであろう。ＳＲＴＰ（ＳａＦ）動作を取り扱うための小規模な拡張が必要かも知れない。これらの鍵管理プロトコルはまた、状況によってはｅ２ｅ鍵管理にも用いることができる。
【００１１】
ｈｂｈ保護のための鍵の確立は比較的容易であるが、メディアデータが中間ユニット２を通る場合の送信機ユニット１と受信機ユニット３との間のｅ２ｅ保護のための鍵の確立は容易な問題ではない。ｅ２ｅ保護のための鍵の確立にマルチメディアインターネットキーイング(MIKEY)が用いられる場合（MIKEYの詳細についてはＲＦＣ３８３０を参照）、鍵管理について以下のような様々なオプションが存在する。
【００１２】
1.  ＭＩＫＥＹを事前共有鍵(pre-shared key)モードで用いる。この場合、ｅ２ｅ事前共有鍵は発呼時に送信機ユニット１が利用できなければならない。これは、セキュアな方法でデータが送信されるより前に、事前共有鍵が配信されなければならないことを意味し、鍵ブートストラップ問題につながる。送信機ユニット１は、目的とする受信機ユニット３についての鍵を得るために特別な手順を用いなければならない。この手順は、送信機ユニット１が必要な際に鍵を取得することを可能にするオンライン手順であるかもしれないし、例えば、可能性のある全ての受信機ユニットについての鍵を送信者の電話帳にダウンロードすることかもしれない。
【００１３】
2.  ＭＩＫＥＹをＲＳＡ(Rivest, Shamir, および Adleman)モードで用いる。この場合、受信機ユニット３のクレデンシャルが送信機ユニット１側で事前に利用可能でなければならず、ＭＩＫＥＹを事前共有鍵モードで用いる場合と同じ問題が生じる。
【００１４】
3.  ＭＩＫＥＹをデルフィーヘルマン(Diffie-Hellman)モードで用いる。送信機ユニット１と受信機ユニット３との両方がメッセージ交換に関与することが求められるため、この状況は機能しない。
【００１５】
4.  ＭＩＫＥＹを逆ＲＳＡ（ＲＳＡーＲ）モード（ＲＦＣ４７３８参照）で用いる。エンドポイントが中間ユニット２となる必要があり、生成されるであろう鍵が、中間ユニット２がメディアデータにアクセスすることを許すことになるであろうため、この場合もまた機能しない。
【００１６】
様々な鍵管理手法とともに用いることができるであろう１つの選択肢は、送信機ユニット１が受信機ユニット３に直接接続した際にクレデンシャルを交換することである。そして、各パーティはクレデンシャルを記憶し、呼がメールボックスのような中間ユニット２にリダイレクトされる場合にそのクレデンシャルを用いることができるだろう。これは、ＭＩＫＥＹ ＲＳＡーＲおよびＤＴＬＳーＳＲＴＰ証明書配信について機能するであろう。この選択肢の問題は、何らかのデータが中間ユニット２にリダイレクトされる前に、送信機ユニット１と受信機ユニット３との間の少なくとも１つの直接接続が発生しなければならないことである。さらに、送信機ユニット１と受信機ユニット３の両方がクレデンシャルを保存しなければならず、また送信機ユニット１と受信機ユニット３とが直接接続しているときだけしかクレデンシャルを更新できないという問題もある。
【発明の概要】
【００１７】
発明者は、メディアデータが中間ユニットを介して送信される際のエンドツーエンド保護を可能とするための、送信機ユニットと受信機ユニットとの間でクレデンシャルの交換を可能とするための手法が存在しないことに気付いた。
【００１８】
本発明の第１の見地によれば、保護されたデータを、送信機ユニットから受信機ユニットに、中間ユニットを介して送信する方法が提供される。前記中間ユニットは前記受信機ユニットに属する証明書と関連付けられた情報と、前記中間ユニットに属する証明書に関連付けられた情報とを保存する。前記中間ユニットに属する前記証明書は、前記受信機ユニットによって前もって署名されている。前記中間ユニットは前記送信機ユニットから保護されたデータを前記受信機ユニットに送信する要求を受信し、前記受信機ユニットに属する前記証明書に関連付けられた前記情報を含んだ応答を前記送信機ユニットに送信する。これにより、前記送信機ユニットは、前記中間ユニットが前記受信機ユニットに代わってデータを受信することを許可されていることを検証できる。そして前記中間ユニットは前記送信機ユニットから、前記受信機ユニットに転送するための、前記受信機ユニットに属する前記証明書に関連付けられた前記情報を用いて保護されたデータを受信する。前記受信機ユニットに前記中間ユニットの証明書を前もって署名させることで、送信機ユニットが保護されたデータを受信機ユニットへ、中間ユニットを介して送信することが可能になる。
【００１９】
前記受信機ユニットに属する前記証明書に関連付けられた情報は、ノードが前記受信機ユニットに属する前記証明書を取得することを可能にする任意の情報である。例えば、情報は前記証明書そのものであってもよいし、前記受信機ユニットに属する前記証明書の場所を特定する情報であってもよい。同様に、前記中間ユニットに属する前記証明書に関連付けられた情報は、前記証明書そのものであっても、前記中間ユニットに属する前記証明書の場所を特定する情報であってもよい。
【００２０】
必要なら、前記受信機ユニットへ保護されたデータを送信するための前記送信機ユニットからの前記要求が、前記送信機ユニットと前記中間ユニットとの間のホップバイホップ保護の要求（前記ホップバイホップ保護は、前記中間ユニットに属する前記証明書に基づくものである）と、前記送信機ユニットと前記受信機ユニットとの間のエンドツーエンド保護の要求とを有してもよい。この場合、前記応答は前記中間ユニットと前記送信機ユニットとの間のホップバイホップ保護の承諾と、前記中間ユニットと前記送信機ユニットとの間のエンドツーエンド保護の拒否とを有する。
【００２１】
前記受信機ユニットが前記保護されたデータを受信できるようになると、前記中間ユニットは必要に応じて前記受信機ユニットから前記保護されたデータの要求を受信する。前記要求はホップバイホップおよびエンドツーエンド管理要求を含む。前記保護されたデータの要求に応答して、前記中間ユニットは前記保護されたメディアデータを前記受信機ユニットに送信する。
【００２２】
前記保護されたデータの種類は例えば、セキュアリアルタイムトランスポートプロトコルデータおよびセキュア多目的インターネットメール拡張データを含む。
【００２３】
中間ユニットとして機能するノードの例としては、セキュアリアルタイムトランスポートプロトコル蓄積転送メールボックスがある。
【００２４】
本発明の第２の見地によれば、通信ネットワークにおいて、送信機ユニットから保護されたデータを受信機ユニットの代わりに受信するための中間ユニットが提供される。前記中間ユニットは、前記受信機ユニットに属する証明書と関連付けられた情報と、前記中間ユニットに属する証明書に関連付けられ、前記受信機ユニットによって署名されている情報とを保存するためのメモリを有している。保護されたデータを前記受信機ユニットに送信するための、前記送信機ユニットからの要求を受信するための通信機能が設けられている。メッセージを処理するためにプロセッサもまた設けられている。前記通信機能は前記送信機ユニットに、前記受信機ユニットに属する前記証明書に関連付けられた前記情報を含む応答を送信するように構成されるとともに、前記送信機ユニットから、前記受信機ユニットに転送するための、前記受信機ユニットに属する前記証明書を用いて保護されたデータを受信するように構成される。
【００２５】
前記受信機ユニットに属する前記証明書に関連付けられた前記情報は、前記証明書そのもの、または前記証明書の場所を特定する情報を必要に応じて有する。同様に、前記中間ユニットに属する前記証明書に関連付けられた情報は、前記証明書そのもの、または前記中間ユニットに属する前記証明書の場所を特定する情報を有する。
【００２６】
前記プロセッサは、前記送信機ユニットと前記中間ユニットとの間のホップバイホップ保護の要求（前記ホップバイホップ保護は、前記中間ユニットに属する前記証明書に基づくものである）と、前記送信機ユニットと前記受信機ユニットとの間のエンドツーエンド保護の要求とを処理するように構成される。前記プロセッサはさらに、前記中間ユニットと前記送信機ユニットとの間のホップバイホップ保護の承諾と、前記中間ユニットと前記送信機ユニットとの間のエンドツーエンド保護の拒否とを有する応答メッセージを生成するように構成される。
【００２７】
前記中間ユニットは、前記受信した保護データを保存するための第２のメモリを必要に応じて有する。
【００２８】
前記受信機ユニットから前記保護されたデータの要求を受信するために第２の通信機能が必要に応じて設けられる。前記要求は、ホップバイホップおよびエンドツーエンド管理要求を含み、前記第２の通信機能は前記要求に応答して前記保護されたメディアデータを前記受信機ユニットに送信するようにさらに構成される。
【００２９】
中間ユニットの例としては、セキュアリアルタイムトランスポートプロトコル蓄積転送メールボックスがある。
【００３０】
本発明の第３の見地によれば、保護されたデータを、送信機ユニットが中間ユニットを介して受信機ユニットへ送信する通信ネットワークで用いるための、前記受信機ユニットが提供される。前記受信機ユニットは、前記中間ユニットに属する証明書を取得するための証明書取得機能を有する。前記受信機ユニットに送信する証明書に対応する秘密鍵を用いて、前記中間ユニットに属する前記証明書に署名するための証明書処理機能がさらに設けられる。前記署名された前記中間ユニットに属する前記証明書と、前記受信機ユニットに属する前記証明書とを前記中間ユニットに送信するための通信機能がさらに設けられる。これにより、前記中間ユニットは、保護されたデータを前記受信機の代わりに受信することが可能になる。
【００３１】
前記受信機ユニットは、前記中間ユニットに保存された前記受信機ユニット宛の保護されたデータに対する要求メッセージを生成するためのメッセージ処理機能を必要に応じて有する。前記要求メッセージはさらに、ホップバイホップおよびエンドツーエンド管理要求を有する。この場合、前記通信機能は、前記要求メッセージを前記中間ユニットに送信し、その後前記中間ユニットから前記要求した保護されたデータを受信するように構成される。前記受信した前記保護されたデータを処理するための保護データ処理機能がさらに設けられる。
【００３２】
本発明の第４の見地によれば、保護されたデータを、送信機ユニットが中間ユニットを介して受信機ユニットへ送信する通信ネットワークで用いるための、前記送信機ユニットが提供される。前記送信機ユニットは前記受信機ユニット宛の要求メッセージを生成するためのメッセージ処理機能を有する。前記要求メッセージは、保護されたデータを送信するためのセッションの確立を要求するものである。前記要求メッセージを前記受信機ユニットへ向けて送信するための通信機能が設けられる。前記通信機能は、前記要求メッセージに応答して、前記受信機ユニットに属する証明書を特定する情報を有する応答を前記中間ユニットから受信するように構成される。前記受信機ユニットに属する前記証明書を用いてデータを保護するためのデータ処理機能が設けられ、前記通信機能はさらに前記保護されたデータを前記中間ユニットに送信するように構成される。このように、前記送信機ユニットは、前記受信機ユニットではなく前記中間ユニットにデータを送信しなければならないことを認知すると、前記受信機ユニットの代わりを努める前記中間ユニットに前記保護されたデータを送信するために必要な前記証明書を与えられる。
【００３３】
必要であれば、前記メッセージ処理機能が、前記送信機ユニットと前記中間ユニットとの間のホップバイホップ保護の要求と、前記送信機ユニットと前記受信機ユニットとの間のエンドツーエンド保護の要求とを有するように前記要求メッセージを生成するように構成され、前記通信機能は前記応答を受信するように構成される。前記応答は、前記中間ユニットと前記送信機ユニットとの間のホップバイホップ保護の承諾と、前記中間ユニットと前記送信機ユニットとの間のエンドツーエンド保護の拒否とを有する。これは、前記送信機ユニットに、前記送信機ユニットが前記中間ユニットとｅ２ｅ保護ではなくｈｂｈ保護を確立しなければならないことを知らせる。
【００３４】
前記保護されたデータは、必要に応じて、セキュアリアルタイムトランスポートプロトコルデータおよびセキュア多目的インターネットメール拡張データの１つから選択される。
【００３５】
本発明の第５の見地によれば、中間ユニットで実行された際に前記中間ユニットに本発明の第１の見地について上述した方法を実行させる、コンピュータ可読コードを有するコンピュータプログラムが提供される。
【００３６】
本発明の第６の見地によれば、受信機ユニットで実行された際に、前記受信機ユニットを本発明の第３の見地について上述した受信機ユニットとして動作させるコンピュータ可読コードを有するコンピュータプログラムが提供される。
【００３７】
本発明の第７の見地によれば、送信機ユニットで実行された際に、前記送信機ユニットを本発明の第４の見地について上述した送信機ユニットとして動作させるコンピュータ可読コードを有するコンピュータプログラムが提供される。
【００３８】
本発明の第８の見地によれば、コンピュータ可読媒体と、本発明の第５、第６、第７の見地のいずれかで記載したコンピュータプログラムとを有するコンピュータプログラム製品が提供される。前記コンピュータプログラムは前記コンピュータ読み取り可能な媒体に格納される。
【図面の簡単な説明】
【００３９】
【図１】送信機ユニットが中間ユニットを介して情報を受信機ユニットに送信する場合のネットワークアーキテクチャを模式的に示すブロック図である。
【図２】本発明の実施形態に係る中間ユニットを模式的に示すブロック図である。
【図３】本発明の実施形態に係るシグナリングを示す信号図である。
【図４】本発明の実施形態に係る受信機ユニットを模式的に示すブロック図である。
【図５】本発明の実施形態に係る送信機ユニットを模式的に示すブロック図である。
【図６】本発明の別の実施形態に係る中間ユニットを模式的に示すブロック図である。
【図７】本発明の別の実施形態に係る受信機ユニットを模式的に示すブロック図である。
【図８】本発明の別の実施形態に係る送信機ユニットを模式的に示すブロック図である。
【発明を実施するための形態】
【００４０】
本発明はｅ２ｅ保護についてのクレデンシャルを証明書として利用するものである。証明書は、公開鍵をＩＤとバインドするデジタル署名を有するため、公開鍵を用いる人物は、公開鍵のＩＤの所有者を検証することが可能である。図２を参照すると、本発明はＳａＦメールボックスのような中間ユニット２を提供する。中間ユニットは、送信機ユニット１と通信するための、送受信器のような通信機能４を有する。また、メッセージを処理するためのプロセッサ５を有する。中間ユニット２は、受信機ユニット３と通信するために、送受信器のような別の通信機能６を有する。また、加入受信機ユニットに関する情報を保存するためのメモリ７を有している。
【００４１】
各加入者に関連付けられた情報の一部は、意図する受信機ユニット３に属する証明書８と、中間ユニット２に属し、意図する受信機ユニット３によって署名されている証明書９とを含んだ証明書チェインである。中間ユニット２に属する証明書９は意図する受信機ユニット３によって署名されているので、この証明書を、中間ユニット２が受信機ユニット３に代わってデータに署名することを可能にするために用いることができる。なお、証明書は秘密でない（パブリックな）情報のみを含んでいることに留意されたい。受信機ユニットの証明書８に対応する秘密鍵は、受信機ユニット３だけが知っているべきである。本明細書では証明書の保存について言及するが、パーティが証明書を取得することを可能にする、証明書に関連付けられた情報を代わりに保存することができることが理解されるであろう。例えば、証明書に関連付けられた情報は、証明書自体、証明書を特定するＵＲＬ、または、証明書の所有者および証明書の場所を特定する他の情報であってよい。
【００４２】
受信機ユニットの証明書８は、受信機ユニットのパブリックＩＤに関する情報を含み、送信したいかなるデータも意図した受信機ユニット３に到達するであろうこと送信機ユニット１が検証することを可能にする。そのようなパブリックＩＤの例は、ＩＰマルチメディアサブシステム（ＩＭＳ）におけるユーザのパブリックＩＤである。証明書情報は、（オンラインまたはオフラインで）共通ルート証明書を用いて証明書の有効性をチェックすることによって検証されてもよい。
【００４３】
図２の例において、意図した受信機ユニット３に属する証明書８および中間ユニット２に属する証明書９は、中間ユニット２に設けられたメモリ７に保存されているように示されている。しかし、中間ユニットがアクセス可能であれば、証明書８，９が中間ユニット２から離れて保存されてもよいことが理解されよう。
【００４４】
中間ユニット２は、何らかの方法で受信機ユニットの証明書８を取得しなければならない。典型的なシナリオでは、中間ユニット２はＳＲＴＰ ＳａＦメールボックスであり、この場合中間ユニット２は転送前のデータを保存するための第２のメモリ１０を有する必要がある。もちろん、第２のメモリ１０が、証明書８，９が保存されるメモリ７と同じ物理メモリの一部として実施されてもよい。ＳＲＴＰ ＳａＦメールボックスは複数の加入者を受け持つことができる。この例では、受信機ユニット３はＳＲＴＰ ＳａＦサービスに加入することを望んでいる。
【００４５】
図３を参照すると、受信機ユニット３と中間ユニット２との間の保護されたチャネルを用いてセットアップ通信（Ｓ１）が実行される。保護されたチャネルを確立するために、エンドポイント認証が用いられる。エンドポイント認証の一例は、サーバおよびクライアント証明書を用いるＴＬＳに基づく認証手順である。本発明がいかなる場合にも証明書を利用するものであるため、この方法は特に簡単である。ＭＩＫＥＹ ＲＳＡ、ＭＩＫＥＹ ＲＳＡーＲ、または他の証明書に基づく鍵交換プロトコルがｈｂｈ保護のために用いられる場合に必要となるため、中間ユニット２はサーバから証明書を提供される。中間ユニット証明書は、受信機ユニット３に署名された中間ユニット証明書９によって置換することができ、これにより、中間ユニットが受信機ユニット３の代わりにメッセージを記録することの信憑性を高めることができる。
【００４６】
中間ユニット２は、受信機ユニットの証明書８の写しを受信するとともに、受信機ユニット３によって署名された自身の証明書９の写しを持つと、送信機ユニット１が受信機ユニット３と事前にコンタクトしておらず、受信機ユニットの証明書の知見を持たない場合であっても、受信機ユニット３の代わりに呼を受信することが可能になる。
【００４７】
発呼時におけるセキュリティセットアップについて、シグナリングの例を参照して説明する。以下の例では、次のことが前提となっている。
・ｈｂｈ鍵管理がＭＩＫＥＹ ＲＳＡーＲを用いて実行される。使用されうる他の鍵管理プロトコルは、ＭＩＫＥＹ 事前共有鍵（ＰＳＫ）、ＭＩＫＥＹ ＲＳＡ、ＭＩＫＥＹ デルフィーヘルマン（ＤＨ）、およびＤＴＬＳーＳＲＴＰを含む
・ｅ２ｅ鍵管理が、ＭＩＫＥＹメッセージを用いて実行される。ＭＩＫＥＹメッセージはＳＩＰシグナリングのセッション記述プロトコル（ＳＤＰ）パート（INVITE, 200 OK, ACKなど。RFC 4567参照）で転送されるものとする。以下の例において、一部のパラメータ割り当ては省略されていることに留意されたい。
【００４８】
送信機ユニット１は、receiver@homeのアドレスを有する受信機ユニット３にINVITEを送信する（Ｓ２）。しかし、受信機ユニット３は現時点でＩＭＳシステムに登録されていないため、INVITEは（受信機ユニットのメールボックスである）中間ユニット２にリダイレクトされる。INVETEは、ｈｂｈセキュリティとｅ２ｅセキュリティの２つのオファーを含んでいる。この２つのオファーは、INVITEのSDPパート（RFC 4567参照）に含まれている。中間ユニット２は、このことから、送信機ユニット１がＳＲＴＰ ＳａＦをサポートすることを推測することができる。INVITEメッセージは以下のものを含んでよい。
【００４９】
INVITE
….
SDP
….
m=……..RTP/SAVP 99
a=rtpmap:99  AMR/8000
a=key-mgmt:mikey  <RSA-R I_MESSAGE>
a=e2e-key-mgmt:mikey  <RSA-R I_MESSAGE>
【００５０】
上述の例示的メッセージにおいては、いずれのオファーもＭＩＫＥＹ ＲＳＡーＲである。
【００５１】
INVITEを受信する中間ユニット２はＳＲＴＰ ＳａＦをサポートし、INVITEメッセージで送信されたｈｂｈおよびｅ２ｅオファーの両方に対して応答するために返信する（Ｓ３）。中間ユニット２は適切な応答メッセージ(MIKEY RSA-R R_MESSAGE)を生成して、ｈｂｈ鍵管理手順を承諾する。しかし、ｅ２ｅ保護についてのＭＩＫＥＹ ＲＳＡーＲの使用オファーは拒否される。これは、中間ユニット２が意図された受信機ユニット３ではなく、そのため、中間ユニット２を介してプレインテキストデータにアクセスできるべきではないからである。ｅ２ｅ保護の要求に対して、エラーメッセージが送信される。エラーメッセージは、中間ユニット２が意図された受信機ユニットではないことを示すエラーコードを含んでいる。エラーメッセージはさらに、受信機ユニットの証明書８（または証明書へのリンク）を含んでいる。エラーメッセージはまた、証明書チェイン情報および不失効(non-revocation)証明のような追加情報を含んでもよい。エラーメッセージは受信機ユニット３が署名した中間ユニット証明書９に対応する秘密鍵を用いて署名されてよい。INVITEメッセージに応答して送信される200 OKメッセージは以下のものを含んでよい。
【００５２】
200 OK / 18x provisional response
…..
SDP
…
m=…...RTP/SAVP 99
a=key-mgmt: mikey <RSA-R R_MESSAGE>
a=e2e-key-mgmt:mikey |<MIKEY RSA-R E_MESSAGE; signed>
【００５３】
なお、ＭＩＫＥＹが搬送されるＳＩＰメッセージは状況に依存することを理解されたい。200 OK（リソースなどが全てセットアップされたものと仮定した場合）であっても、18x仮応答（例えば、確認されていないリソースが残っている場合に用いられる）であってもよい。
【００５４】
送信機ユニット１は200 OK／18x仮応答を受信すると、ｅ２ｅオファーは拒否されたが、ｈｂｈセキュリティが承諾されたことに気付く。エラーメッセージは送信機ユニットに、エラーを生成したエンティティが受信機ユニット３ではないためにオファーが拒否されたことを教える。エラーメッセージは受信機ユニットの証明書８を含むとともに、受信機ユニット３が署名した中間ユニット証明書９に対応する秘密鍵を用いて中間ユニット２が署名したものである。エラーメッセージは完全な証明書チェイン、証明書失効情報などのような追加情報を含んでもよい。
【００５５】
RFC 3830に規定されたエラーメッセージは必要な情報を転送できないため、新たなエラーコードを定義する必要があることに留意されたい。
【００５６】
送信機ユニット１は受信機ユニットの証明書８を入手したので、ｅ２ｅ保護を設定するためにＭＩＫＥＹ ＲＳＡを利用できるようになる。従って、送信されるいかなるデータも送信機ユニット１と受信機ユニット３との間でｅ２ｅ保護されるようになるとともに、送信機ユニット１と中間ユニット２との間でｈｂｈ保護されるようになる。これにより、中間ユニット２がプレインテキストデータにアクセスできないことが保証される。送信機ユニット１は例えば以下のようなACKメッセージを送信する（Ｓ４）。
【００５７】
Update / ACK
….
SDP
….
m=……RTP/SAVP 99
a= e2e-key-mgmt: mikey <RSA I_MESSAGE >
【００５８】
送信機ユニットが既に受信機ユニットの証明書８を有している場合、（Ｓ２）の段階でｅ２ｅ設定のためにＭＩＫＥＹーＲＳＡを用いることができる。中間ユニット２は、適切な応答メッセージを生成してｈｂｈ鍵確立手順を承諾する。ｅ２ｄ保護についてＭＩＫＥＹーＲＳＡを用いるオファーもまた承諾される。ACKメッセージ（Ｓ４）では、いかなる鍵確立も行われない。
【００５９】
なお、ＭＩＫＥＹが搬送されるＳＩＰメッセージは状況に依存することを理解されたい。（中間ユニット２から200 OKが受信された例では）ACKであってよいし、（18x仮応答が中間ユニット２から受信された例では）UPDATEであってよい。
【００６０】
ＭＩＫＥＹ ＲＳＡメッセージは中間ユニット２で受信され、保存されたのち、受信機ユニット３がメッセージ（この例ではおそらくボイスメールメッセージ）を読み出すために中間ユニット２に発呼した際に受信機ユニット３に転送される。
【００６１】
ｅ２ｅおよびｈｂｈ保護が一旦設定されると、保護されたメディアデータが送信機ユニット１から中間ユニット２に送信され（Ｓ５）、受信機ユニット３がネットワーク内でメディアデータを受信できるようになるまで中間ユニット２に保存される。
【００６２】
受信機ユニット３がネットワークにアタッチすると、受信機ユニット３は、中間ユニット２から利用可能な（音声メッセージのような）メディアデータを有することを知らされる。受信機ユニット３は、ｅ２ｅおよびｈｂｈセキュリティの両方を含んだオファーとともにINVITEメッセージを中間ユニット２に送信する（Ｓ６）。このメッセージは中間ユニット２に、受信機ユニット３がＳＲＴＰ ＳａＦを理解することを教える。中間ユニット２は、いずれのオファーも承諾するために200 OKメッセージを送信し（Ｓ７）、応答に、記録されたメッセージについての全てのセキュリティコンテクストを含める。例示的な200 OK応答（または18x仮応答）は、以下の通りである。
【００６３】
200 OK / 18x 仮応答
…..
SDP
…
m=…...RTP/SAVP 99
a=key-mgmt: mikey <RSA-R R_MESSAGE>
a=e2e-key-mgmt:mikey <MIKEY RSA-R R_MESSAGE>
a = e2e-key-mgmt:mikey <MIKEY RSA I_MESSGE>    ; stored msg ctxt1
a = e2e-key-mgmt:mikey <MIKEY RSA I_MESSGE>    ; stored msg ctxt2
….
【００６４】
なお、a=key-mgmt: mikey <RSA-R R_MESSAGE>は、ｈｂｈ鍵管理に関するものであることに留意されたい。
【００６５】
ｅ２ｅおよびｈｂｈ保護が受信機ユニット３と確立すると、中間ユニット２は保存していた保護されたメディアデータを送信する（Ｓ８）ことが可能になる。
【００６６】
なお、INVITEは、ＳａＦメールボックスのような中間ユニット２に必ずしも送られなくてよいことが理解されよう。例えば、受信機ユニット３がネットワークに接続されていれば、INVITEは受信機ユニット３に直接送られるであろう。この場合、上述したように送信機ユニット１がINVITEを送信し、オファーが受信機ユニット３で受信されると、受信機ユニット３はｅ２ｅ保護についてのオファーを拒否し、ｈｂｈ保護について受諾および証明書８に対応する秘密鍵を用いて署名することができる。このようにして、送信機ユニット１は、意図した受信機ユニット３への直接接続の存在に気づき、受信機ユニット３のＩＤが証明書８によって検証される。もちろん、受信機ユニット３はｈｂｈオファーとｅ２ｅオファーの両方を受諾してもよいが、送信機ユニット１と受信機ユニット３の間に中間ＳａＦノードが存在しないため、必要性が存在しない。これは両パーティがオンラインであることを前提としており、この場合はｈｂｈ保護だけで十分である。しかし、メッセージのようなデータが記憶装置に残っており、蓄積装置が後で受信機ユニットに発行する場合には、ｈｂｈ保護に加えてｅ２ｅ保護が必要となるであろう。
【００６７】
受信機ユニット３を示した図４を参照する。受信機ユニット３は中間ユニット２に属する証明書を取得するための証明書取得機能１１を有している。証明書取得機能１１は証明書を証明機関から、メモリから、または他の外部ノードから取得してよい。受信機ユニットに属する証明書８に対応する秘密鍵を用いて、中間ユニット２に属する証明書９に署名するための証明書処理機能１２がさらに設けられている。署名された、中間ユニットに属する証明書９と、受信機ユニットに属する証明書８とを中間ユニットに送信するための（通常、送受信器または１つ以上の送信器および受信器の組み合わせである）通信機能１３が設けられている。受信機ユニット３は、中間ユニットに保存された受信機ユニット３宛の保護されたデータに対する要求メッセージを生成するためのメッセージ処理機能１４をさらに有している。この要求メッセージは、ホップバイホップ保護およびエンドツーエンド保護の要求をさらに有している。この場合、通信機能１３は、要求メッセージを中間ユニット２に送信し、その後中間ユニット２から要求した保護されたデータを受信するように構成される。受信した保護されたデータを処理するための保護データ処理機能１５がさらに設けられている。
【００６８】
図５を参照すると、送信機ユニット１は、受信機ユニット３宛の要求メッセージを生成するためのメッセージ処理機能１６を有している。要求メッセージは、保護されたデータを送信するためのセッションの確立を要求する。要求メッセージを受信機ユニットへ向けて送信するための通信機能１７がさらに設けられている。通信機能は、通常、送受信器または１つ以上の送信器および受信器の組み合わせであり、要求メッセージに対する応答を中間ユニット２から受信するように構成される。応答は受信機ユニット３に属する証明書８を特定する情報を含んでいる。受信機ユニット３に属する証明書８に対応する秘密鍵を用いてデータを保護するためのデータ処理機能１８が設けられており、保護されたデータを通信機能１７を用いて中間ユニット２に送信することができる。メッセージ処理機能１６は、送信機ユニット１と中間ユニット２との間のｈｂｈ保護の要求と、送信機ユニット１と受信機ユニットとの間のｅ２ｄ保護の要求とを有する要求メッセージを生成するように構成される。また通信機能１７は、中間ユニット２と送信機ユニット１との間のｈｂｈ保護の受諾と、中間ユニット２と送信機ユニット１との間のｅ２ｅ保護の拒否とを有するメッセージを受信するように構成される。
【００６９】
上述したハードウェアはソフトウェアを用いて実施されうることが理解されよう。それを説明するため、図６に中間ユニット２０の代替実施形態を示した。この場合、中間ユニット２０はプロセッサ２１、送信機ユニット１と通信するための通信機能２２、および受信機ユニット３と通信するための通信機能２２とを有する。中間ユニット２０はまた、メモリ２４の形態で、コンピュータプログラム製品を有している。メモリ２４はプロセッサによって実行可能なプログラム２５を有している。プログラム２５はメッセージ処理機能２６および保護データ処理機能２７を含んでいる。メモリ２４はまた、証明書２８と、受信機ユニット３に送信される前に送信機ユニット１から受信した保護されたデータ２９とを保存するためにも用いられてよい。もちろん、図６に示したメモリ２４は、プログラム２５、証明書２８、および保護されたデータ２９の各々を格納する１つのメモリであってよく、それぞれが異なる物理的メモリに格納されてよい。
【００７０】
図７は本発明を実施するためにソフトウェアを用いる受信機ユニットを示している。この場合、受信機ユニット３０は、中間ユニット２と通信するための通信機能３１と、メッセージおよびデータを処理するためのプロセッサ３２とを有する。メモリ３３の形態を有するコンピュータプログラム製品が設けられ、そこには、プロセッサが実行可能なプログラム３４が格納されている。プログラム３４は、中間ユニット２の証明書９に署名するとともに受信機ユニットの証明書８を提供するための証明書処理機能３６および証明書取得機能３５を含んでいる。プログラム３４はまた、シグナリングを処理するためのメッセージ処理機能３７と、中間ユニット２から受信した保護されたデータを処理するためのデータ処理機能３８とを含んでいる。
【００７１】
図８は本発明を実施するためにソフトウェアを用いる送信機ユニット３９を示している。本実施形態において、送信機ユニット３９は中間ユニット２と通信するための通信装置４０と、メッセージを処理したり、データ、認証などを送信するためのプロセッサ４１とを有している。メモリ４２の形態を有するコンピュータプログラム製品が設けられ、そこには、プロセッサ４１が実行可能なプログラム４３が格納されている。プログラムはメッセージ処理機能４４およびデータ処理機能４５を含んでいる。データソース４６は、ｅ２ｅおよびｈｂｈ保護され、中間ユニット２に送信されるデータを提供する。例えばリモートストリーミングサーバ、データを保持したメモリ、ＩＰＴＶヘッドエンドなど、任意の好適なデータソースを用いることができる。
【００７２】
本発明はＳａＦの存在する状況における鍵管理手順を提供するとともに、送信機ユニット１についての標準的なセキュリティ設定オファーを用いるため、保護されたデータを送信するために既存のシグナリングに対して必要な変更を最小化することができる。
【００７３】
本技術分野に属する当業者は、本発明の範囲内で、上述した実施形態に対して様々な変更を加えることが可能であることを理解するであろう。例えば、上述の説明では、中間ユニット２が、保護されたＳＲＴＰデータを受信し、保存し、その後送信するためのＳａＦメールボックスであるシナリオを用いて本発明を説明した。しかし、本発明はＳＲＴＰ以外のプロトコルとともに用いることができる。当業者は、本発明を例えば、最終的な受信機ユニットに転送する前に電子メールメッセージを保存しなくてはならない中間メールボックスのためのセキュア／多目的インターネットメール拡張（Ｓ／ＭＩＭＥ）プロトコルに適用する事が可能であろう。さらに、中間ユニット証明書９が受信機ユニット３によって署名されると説明したが、証明書９の生成／署名を異なる方法で行うことができる。セキュリティの観点からは、受信機ユニット３が公開秘密鍵対を生成して秘密鍵および証明書を中間ユニット２に送信すれば十分である。他の考えられる方法は、中間ユニットが公開秘密鍵対を生成し、証明書９を得るために受信機ユニット３に向けて登録プロトコル(enrolment protocol)を用いることである。
【００７４】
本明細書において用いてきた略語は以下の通りである。
e2e    エンドツーエンド
DLTS    データグラムトランスポートレイヤセキュリティ
hbh    ホップバイホップ
IMS    ＩＰマルチメディアサブシステム
MIKEY    マルチメディアインターネット鍵交換
RTCP    RTP制御プロトコル
RTP    リアルタイムトランスポートプロトコル
SaF    蓄積交換
SDP    セッション記述プロトコル
S/MIME  セキュア多目的インターネットメール拡張
SRTCP  セキュアRTCP
SRTP    セキュアリアルタイムトランスポートプロトコル
VoIP    ボイスオーバＩＰ
【図１】
0005466764.tif 000002
【図２】
0005466764.tif 000003
【図３】
0005466764.tif 000004
【図４】
0005466764.tif 000005
【図５】
0005466764.tif 000006
【図６】
0005466764.tif 000007
【図７】
0005466764.tif 000008
【図８】
0005466764.tif 000009