JP2013507034A - 保護されたデータの通信ネットワークにおける送信 - Google Patents

保護されたデータの通信ネットワークにおける送信 Download PDF

Info

Publication number
JP2013507034A
JP2013507034A JP2012532040A JP2012532040A JP2013507034A JP 2013507034 A JP2013507034 A JP 2013507034A JP 2012532040 A JP2012532040 A JP 2012532040A JP 2012532040 A JP2012532040 A JP 2012532040A JP 2013507034 A JP2013507034 A JP 2013507034A
Authority
JP
Japan
Prior art keywords
unit
receiver unit
receiver
intermediate unit
certificate
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2012532040A
Other languages
English (en)
Other versions
JP5466764B2 (ja
Inventor
ロルフ ブロム，
フレドリク リンドホルム，
ジョン マットソン，
Original Assignee
テレフオンアクチーボラゲット エル エム エリクソン（パブル）
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by テレフオンアクチーボラゲット エル エム エリクソン（パブル） filed Critical テレフオンアクチーボラゲット エル エム エリクソン（パブル）
Publication of JP2013507034A publication Critical patent/JP2013507034A/ja
Application granted granted Critical
Publication of JP5466764B2 publication Critical patent/JP5466764B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3249—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using RSA or related signature schemes, e.g. Rabin scheme
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/34—Encoding or coding, e.g. Huffman coding or error correction

Abstract

保護されたデータを送信機ユニットから受信機ユニットへ、中間ユニットを介して送信するための方法である。中間ユニットは、受信機ユニットに属する証明書に関連付けられた情報と、中間ユニットに属する証明書に関連付けられた情報とを保存し、中間ユニットに属する証明書は受信機ユニットによって前もって署名されている。中間ユニットは送信機ユニットから、保護されたデータを受信機ユニットに送信するための要求を受信し、送信機ユニットに応答を送信する。応答は受信機ユニットに属する証明書に関連付けられた情報を含んでおり、それによって送信機ユニットは、中間ユニットが受信機ユニットに代ってデータを受信することを許可されていることを検証できる。そして中間ユニットは、送信機ユニットから、受信機ユニットに属する証明書に関連付けられた情報を用いて保護された、後で受信機ユニットに転送するためのデータを受信する。中間ユニットの証明書を受信機ユニットに署名させることにより、送信機ユニットが保護されたデータを中間ユニットを介して受信機ユニットに送信することを可能にするためのクレデンシャルの交換が可能になる。
【選択図】 図３

Description

本発明は保護されたものを通信ネットワーク内で送信する技術に関する。
リアルタイムトランスポートプロトコル(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 ボイスオーバＩＰ

Claims (21)

  1. 保護されたデータを送信機ユニットから受信機ユニットへ、中間ユニットを介して送信するための方法であって、
    前記中間ユニットが、
    前記受信機ユニットに属する証明書に関連付けられた情報と、前記中間ユニットに属する証明書に関連付けられた情報とを保存するステップと、
    前記送信機ユニットから、前記保護されたデータを前記受信機ユニットに送信するための要求を受信するステップと、
    前記受信機ユニットに属する前記証明書に関連付けられた前記情報を含んだ応答を、前記送信機ユニットに送信するステップと、
    前記送信機ユニットから、前記受信機ユニットに属する前記証明書に関連付けられた前記情報を用いて保護された、後で前記受信機ユニットに転送するためのデータを受信するステップとを有し、
    前記中間ユニットに属する前記証明書は前記受信機ユニットによって署名されていることを特徴とする方法。
  2. 前記受信機ユニットに属する前記証明書に関連付けられた前記情報が、前記受信機ユニットに属する前記証明書と、前記受信機ユニットに属する前記証明書の位置を特定する情報との一方を有し、
    前記中間ユニットに属する前記証明書に関連付けられた前記情報が、前記中間ユニットに属する前記証明書と、前記中間ユニットに属する前記証明書の位置を特定する情報との一方を有することを特徴とする請求項１記載の方法。
  3. 前記送信機ユニットからの、前記保護されたデータを前記受信機ユニットに送信するための要求が、前記送信機ユニットと前記中間ユニットとの間の、前記中間ユニットに属する前記証明書に基づくホップバイホップ保護の要求と、前記送信機ユニットと前記受信機ユニットとの間のエンドツーエンド保護の要求とを有し、
    前記応答が、前記中間ユニットと前記送信機ユニットとの間の前記ホップバイホップ保護の承諾と、前記中間ユニットと前記送信機ユニットとの間のエンドツーエンド保護の拒否とを有することを特徴とする請求項１または請求項２記載の方法。
  4. 前記中間ユニットが、
    前記受信機ユニットから、前記保護されたデータの要求であって、ホップバイホップおよびエンドツーエンド管理要求を含んだ要求、を受信するステップと、
    前記保護されたデータの前記要求に応答して、前記保護されたメディアデータを前記受信機ユニットに送信するステップと、をさらに有することを特徴とする請求項１乃至請求項３のいずれか１項に記載の方法。
  5. 前記保護されたデータが、セキュアリアルタイムトランスポートプロトコルデータと、セキュア多目的インターネットメール拡張データとの一方から選択されることを特徴とする請求項１乃至請求項４のいずれか１項に記載の方法。
  6. 前記中間ユニットがセキュアリアルタイムトランスポートプロトコル蓄積転送メールボックスであることを特徴とする請求項１乃至請求項５のいずれか１項に記載の方法。
  7. 通信ネットワークにおいて送信機ユニットから送信される保護されたデータを、受信機ユニットの代わりに受信するための中間ユニットであって、
    前記受信機ユニットに属する証明書に関連付けられた情報と、前記中間ユニットの証明書に関連付けられた情報とを保存するメモリと、
    前記送信機ユニットから、前記保護されたデータを前記受信機ユニットに送信するための要求を受信する通信機能と、
    メッセージを処理するプロセッサとを有し、
    前記中間ユニットに属する前記証明書は前記受信機ユニットによって署名されており、
    前記通信機能は、前記受信機ユニットに属する前記証明書に関連付けられた前記情報を含んだ応答を、前記送信機ユニットに送信するように構成され、
    前記通信機能はさらに、前記送信機ユニットから、前記受信機ユニットに属する前記証明書に関連付けられた前記情報を用いて保護されたデータを受信するように構成されることを特徴とする中間ユニット。
  8. 前記受信機ユニットに属する前記証明書に関連付けられた前記情報が、前記受信機ユニットに属する前記証明書と、前記受信機ユニットに属する前記証明書の位置を特定する情報との一方を有し、
    前記中間ユニットに属する前記証明書に関連付けられた前記情報が、前記中間ユニットに属する前記証明書と、前記中間ユニットに属する前記証明書の位置を特定する情報との一方を有することを特徴とする請求項７記載の中間ユニット。
  9. 前記プロセッサが、
    前記送信機ユニットと前記中間ユニットとの間の、前記中間ユニットに属する前記証明書に基づくホップバイホップ保護の要求と、
    前記送信機ユニットと前記受信機ユニットとの間のエンドツーエンド保護の要求とを処理するように構成され、
    前記プロセッサはさらに、前記中間ユニットと前記送信機ユニットとの間の前記ホップバイホップ保護の承諾と、前記中間ユニットと前記送信機ユニットとの間のエンドツーエンド保護の拒否とを有する前記応答メッセージを生成するように構成されることを特徴とする請求項７または請求項８記載の中間ユニット。
  10. 前記受信した保護されたデータを保存するための第２のメモリをさらに有することを特徴とする請求項７乃至請求項９のいずれか１項に記載の中間ユニット。
  11. 前記保護されたデータの要求であって、ホップバイホップおよびエンドツーエンド管理の要求を含んだ要求を前記受信機ユニットから受信するための第２の通信機能をさらに有し、
    前記第２の通信機能はさらに、前記保護されたデータの要求に応答して前記保護されたメディアデータを前記受信機ユニットに送信するように構成されることを特徴とする請求項７乃至請求項１０のいずれか１項に記載の中間ユニット。
  12. 前記中間ユニットがセキュアリアルタイムトランスポートプロトコル蓄積転送メールボックスであることを特徴とする請求項７乃至請求項１１のいずれか１項に記載の中間ユニット。
  13. 保護されたデータを、送信機ユニットが中間ユニットを介して受信機ユニットへ送信する通信ネットワークにおいて用いるための受信機ユニットであって、
    前記中間ユニットに属する証明書を取得する証明書取得機能と、
    前記中間ユニットに属する前記証明書を前記受信機ユニットに属する証明書を用いて署名する証明書処理機能と、
    前記中間ユニットに属する前記署名された証明書と前記受信機ユニットに属する前記証明書とを前記中間ユニットに送信する通信機能とを有することを特徴とする受信機ユニット。
  14. 前記中間ユニットに保存された前記受信機ユニット宛の保護されたデータの要求メッセージであって、ホップバイホップおよびエンドツーエンド管理の要求を含んだ要求メッセージを生成するメッセージ処理機能をさらに有し、
    前記通信機能が、前記要求メッセージを前記中間ユニットに送信し、その後前記要求した保護されたデータを前記中間ユニットから受信するように構成され、
    前記受信した保護されたデータを処理する保護データ処理機能をさらに有することを特徴とする請求項１３記載の受信機ユニット。
  15. 保護されたデータを、送信機ユニットが中間ユニットを介して受信機ユニットへ送信する通信ネットワークにおいて用いるための送信機ユニットであって、
    保護されたデータを送信するセッションの確立を要求する、前記受信機ユニット宛の要求メッセージを生成するメッセージ処理機能と、
    前記要求メッセージを前記受信機ユニットへ送信する通信機能であって、
    前記中間ユニットから前記要求メッセージに対する、前記受信機ユニットに属する証明書を特定する情報を有する応答を受信するように構成された通信機能と、
    前記受信機ユニットに属する前記証明書を用いてデータを保護するデータ処理機能とを有し、
    前記通信機能はさらに、前記中間ユニットに前記保護されたデータを送信するように構成されることを特徴とする送信機ユニット。
  16. 前記メッセージ処理機能は、前記送信機ユニットと前記中間ユニットとの間のホップバイホップ保護の要求と前記送信機ユニットと前記受信機ユニットとの間のエンドツーエンド保護の要求とを有するように前記要求メッセージを生成するように構成され、
    前記通信機能は、前記中間ユニットと前記送信機ユニットとの間の前記ホップバイホップ保護の承諾と、前記中間ユニットと前記送信機ユニットとの間のエンドツーエンド保護の拒否とを有する前記応答を受信するように構成されることを特徴とする請求項１５記載の送信機ユニット。
  17. 前記保護されたデータが、セキュアリアルタイムトランスポートプロトコルデータと、セキュア多目的インターネットメール拡張データとの一方から選択されることを特徴とする請求項１５または請求項１６に記載の送信機ユニット。
  18. 中間ユニットで実行された際に、請求項１乃至請求項６のいずれか１項に記載の方法を前記中間ユニットに行わせるためのコンピュータプログラム。
  19. 受信機ユニットで実行された際に、前記受信機ユニットを請求項１３または請求項１４に記載の受信機ユニットとして機能させるためのコンピュータプログラム。
  20. 送信機ユニットで実行された際に、前記送信機ユニットを請求項１５乃至請求項１７のいずれか１項に記載の送信機ユニットとして機能させるためのコンピュータプログラム。
  21. 請求項１８乃至請求項２０のいずれか１項に記載のコンピュータプログラムを格納したコンピュータ読み取り可能な記録媒体。
JP2012532040A 2009-10-01 2009-10-01 保護されたデータの通信ネットワークにおける送信 Active JP5466764B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/SE2009/051093 WO2011040847A1 (en) 2009-10-01 2009-10-01 Sending protected data in a communication network

Publications (2)

Publication Number Publication Date
JP2013507034A true JP2013507034A (ja) 2013-02-28
JP5466764B2 JP5466764B2 (ja) 2014-04-09

Family

ID=43826502

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012532040A Active JP5466764B2 (ja) 2009-10-01 2009-10-01 保護されたデータの通信ネットワークにおける送信

Country Status (5)

Country Link
US (1) US8745374B2 (ja)
EP (1) EP2484048B1 (ja)
JP (1) JP5466764B2 (ja)
CN (1) CN102577231B (ja)
WO (1) WO2011040847A1 (ja)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9112840B2 (en) * 2013-07-17 2015-08-18 Avaya Inc. Verifying privacy of web real-time communications (WebRTC) media channels via corresponding WebRTC data channels, and related methods, systems, and computer-readable media
CN103475639A (zh) * 2013-08-09 2013-12-25 杭州华三通信技术有限公司 一种rtp回退处理方法及装置
KR102021213B1 (ko) * 2014-10-31 2019-09-11 콘비다 와이어리스, 엘엘씨 엔드 투 엔드 서비스 계층 인증
CN105635078A (zh) * 2014-11-07 2016-06-01 中兴通讯股份有限公司 一种实现sip会话传输的方法及系统
JP2018518854A (ja) 2015-03-16 2018-07-12 コンヴィーダ ワイヤレス， エルエルシー 公開キー機構を用いたサービス層におけるエンドツーエンド認証
DE102017131302A1 (de) * 2017-12-27 2019-06-27 Huf Hülsbeck & Fürst GmbH & Co KG Verfahren zum Betreiben einer Reifendrucküberwachungseinheit
US10860692B1 (en) * 2019-06-16 2020-12-08 Shmuel Ur Innovation Ltd. Digital media verification

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000515649A (ja) * 1996-08-07 2000-11-21 バンカーズ・トラスト・コーポレーション 見ることができ信頼できる当事者による同時性電子トランザクション
JP2004248169A (ja) * 2003-02-17 2004-09-02 Nippon Telegr & Teleph Corp <Ntt> 通信制御システムと通信制御方法およびプログラムと通信端末装置
WO2008135389A1 (de) * 2007-05-07 2008-11-13 Novosec Ag Verfahren und vorrichtung zur sicheren übermittlung von informationen von verschiedenen absendern
US20090083538A1 (en) * 2005-08-10 2009-03-26 Riverbed Technology, Inc. Reducing latency of split-terminated secure communication protocol sessions

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6137884A (en) * 1995-03-21 2000-10-24 Bankers Trust Corporation Simultaneous electronic transactions with visible trusted parties
US6199052B1 (en) * 1998-03-06 2001-03-06 Deloitte & Touche Usa Llp Secure electronic transactions using a trusted intermediary with archive and verification request services
US7024688B1 (en) * 2000-08-01 2006-04-04 Nokia Corporation Techniques for performing UMTS (universal mobile telecommunications system) authentication using SIP (session initiation protocol) messages
DE60222871T2 (de) * 2002-07-01 2008-07-24 Telefonaktiebolaget Lm Ericsson (Publ) Anordnung und Verfahren zum Schutz von Endbenutzerdaten
US7555657B2 (en) * 2003-03-28 2009-06-30 Ricoh Company, Ltd. Communication device, software update device, software update system, software update method, and program
CN1838590B (zh) * 2005-03-21 2011-01-19 松下电器产业株式会社 在会话起始协议信号过程提供因特网密钥交换的方法及系统
US8707043B2 (en) * 2009-03-03 2014-04-22 Riverbed Technology, Inc. Split termination of secure communication sessions with mutual certificate-based authentication

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000515649A (ja) * 1996-08-07 2000-11-21 バンカーズ・トラスト・コーポレーション 見ることができ信頼できる当事者による同時性電子トランザクション
JP2004248169A (ja) * 2003-02-17 2004-09-02 Nippon Telegr & Teleph Corp <Ntt> 通信制御システムと通信制御方法およびプログラムと通信端末装置
US20090083538A1 (en) * 2005-08-10 2009-03-26 Riverbed Technology, Inc. Reducing latency of split-terminated secure communication protocol sessions
WO2008135389A1 (de) * 2007-05-07 2008-11-13 Novosec Ag Verfahren und vorrichtung zur sicheren übermittlung von informationen von verschiedenen absendern

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
CSND199800647009; 岡本 栄司: '"明るい情報化社会の実現をめざす暗号技術▲完▼ 認証，零知識証明方式"' ｂｉｔ Ｖｏｌ．２３，Ｎｏ．１３, 19911201, ｐ．９９-１１１, 共立出版株式会社 *
CSNG200900173042; 松中 隆志，蕨野 貴之，岸 洋司，中内 清秀，ベド カフレ，井上 真杉: '"ユーザ主導サービス構築のための仮想ネットワーキング技術 〜（２）オペレータ通信基盤を活用したデバイ' マルチメディア，分散，協調とモバイル（ＤＩＣＯＭＯ２００８）シンポジウム論文集 ［ＣＤ-ＲＯＭ］ 第２００８巻，第１号, 20080709, ｐ．３３３-３４０, 社団法人情報処理学会 *
JPN6013046661; 岡本 栄司: '"明るい情報化社会の実現をめざす暗号技術▲完▼ 認証，零知識証明方式"' ｂｉｔ Ｖｏｌ．２３，Ｎｏ．１３, 19911201, ｐ．９９-１１１, 共立出版株式会社 *
JPN6013046662; 松中 隆志，蕨野 貴之，岸 洋司，中内 清秀，ベド カフレ，井上 真杉: '"ユーザ主導サービス構築のための仮想ネットワーキング技術 〜（２）オペレータ通信基盤を活用したデバイ' マルチメディア，分散，協調とモバイル（ＤＩＣＯＭＯ２００８）シンポジウム論文集 ［ＣＤ-ＲＯＭ］ 第２００８巻，第１号, 20080709, ｐ．３３３-３４０, 社団法人情報処理学会 *
JPN6013046664; Ｒ．　Ｂｌｏｍ，　Ｙ．　Ｃｈｅｎｇ，　Ｆ．　Ｌｉｎｄｈｏｌｍ，　Ｊ．　Ｍａｔｔｓｓｏｎ，　Ｍ．　Ｎａｓｌｕｎｄ，　Ｋ．　Ｎｏｒｒｍａｎ: '"ＳＲＴＰ　Ｓｔｏｒｅ-ａｎｄ-Ｆｏｒｗａｒｄ　Ｕｓｅ　Ｃａｓｅｓ　ａｎｄ　Ｒｅｑｕｉｒｅｍｅｎｔｓ"' Ｎｅｔｗｏｒｋ　Ｗｏｒｋｉｎｇ　Ｇｒｏｕｐ　Ｉｎｔｅｒｎｅｔ-Ｄｒａｆｔ ｄｒａｆｔ-ｍａｔｔｓｓｏｎ-ｓｒｔｐ-ｓｔｏｒｅ-ａｎｄ-ｆｏｒｗａｒｄ-０３, 20090706, ［ｏｎｌｉｎｅ］ *
JPN6013046667; ＭＩＫＡＥＬ　ＧＲＯＥＮＭＡＲＫ: '"Ｒｅａｌｉｚｉｎｇ　ａｎ　Ａｎｓｗｅｒｉｎｇ　Ｍａｃｈｉｎｅ　ｗｉｔｈ　Ｓｅｃｕｒｅ　Ｒｅａｌ-ｔｉｍｅ　Ｔｒａｎｓｐｏｒｔ　Ｐｒｏｔｏｃｏｌ　Ｓｔｏｒｅ　ａｎｄ　Ｆｏｒｗａｒｄ"' ＫＴＨ　-　Ｒｏｙａｌ　Ｉｎｓｔｉｔｕｔｅ　ｏｆ　Ｔｅｃｈｎｏｌｏｇｙ ＴＲＩＴＡ-ＩＣＴ-ＥＸ-２００９：１８０, 2009, ［ｏｎｌｉｎｅ］ *

Also Published As

Publication number Publication date
JP5466764B2 (ja) 2014-04-09
US8745374B2 (en) 2014-06-03
EP2484048A4 (en) 2015-02-25
CN102577231B (zh) 2014-09-24
US20120191970A1 (en) 2012-07-26
WO2011040847A1 (en) 2011-04-07
CN102577231A (zh) 2012-07-11
EP2484048A1 (en) 2012-08-08
EP2484048B1 (en) 2015-12-23

Similar Documents

Publication Publication Date Title
JP5507689B2 (ja) マルチメディア通信システムにおけるセキュリティで保護された鍵管理
US8301883B2 (en) Secure key management in conferencing system
CN101420413B (zh) 会话密钥协商方法、认证服务器及网络设备
US8386767B2 (en) Methods and systems for bootstrapping security key information using session initiation protocol
US8935529B2 (en) Methods and systems for end-to-end secure SIP payloads
US9749318B2 (en) Key management in a communication network
JP5466764B2 (ja) 保護されたデータの通信ネットワークにおける送信
Westerlund et al. Options for securing RTP sessions
WO2010124482A1 (zh) Ip多媒体子系统中实现安全分叉呼叫会话的方法及系统
US8923279B2 (en) Prevention of voice over IP spam
WO2008040213A1 (fr) Procédé, système et dispositif de chiffrement et de signature de messages dans un système de communication
Wing et al. Requirements and analysis of media security management protocols
CN113114644B (zh) 一种基于sip架构的多级跨域对称密钥管理系统
Fries et al. On the applicability of various multimedia internet keying (mikey) modes and extensions
Shekokar et al. A novel approach to avoid billing attack on VoIP system
Fries et al. RFC 5197: On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions
Westerlund et al. RFC 7201: Options for Securing RTP Sessions
Marwaha Security in Peer-to-Peer SIP VoIP
Tschofenig et al. Network Working Group D. Wing, Ed. Request for Comments: 5479 Cisco Category: Informational S. Fries Siemens AG
Fries et al. RFC 5479: Requirements and Analysis of Media Security Management Protocols
KR20080041427A (ko) 무선통신 서비스를 위한 보안 통화 방법

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130920

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20131219

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20140120

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140124

R150 Certificate of patent or registration of utility model

Ref document number: 5466764

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250