JP2005295468A

JP2005295468A - 通信装置及び通信システム

Info

Publication number: JP2005295468A
Application number: JP2004111685A
Authority: JP
Inventors: Hitomi Nakamura; 仁美中村; Minoru Hidaka; 稔日高; Masami Mineo; 正美峯尾; Koichi Shiraishi; 浩一白石
Original assignee: Hitachi Hybrid Network Co Ltd
Current assignee: Hitachi Information Technology Co Ltd
Priority date: 2004-04-06
Filing date: 2004-04-06
Publication date: 2005-10-20

Abstract

【課題】装置の処理能力不足により遅延やパケットロスが発生することを防止するとともに、他のアプリケーションの動作に影響を与えずに暗号化通信を行うことの可能な動画像通信装置を提供する。
【解決手段】動画像通信装置が、動画像のフレーム種別や動画像データに追加されるヘッダの内容をもとにして、選択的に暗号処理を行う。より具体的には、動画像の符号化がMPEG-2により行われる場合に、Iフレームを含むパケットのみを選択して暗号化を行う。
【選択図】図１

Description

本発明は、要求される実時間内に動画像を暗号化してネットワーク伝送する方式に関する。

近年、ネットワークの高速化や計算機の高性能化に伴い、IPテレビ電話などインターネットを利用した動画像通信が急速に普及している。このような通信では、まず通信方式(動画像符号化方式、IPアドレス、ポート番号など)を端末間で交渉した後、圧縮符号化した動画像や音声データをパケットの形に分割して伝送する。

通信方式の交渉には、通信セッションの確立/切断機能を持つSIP (Session Initiation Protocol: 非特許文献1参照)などが用いられる。典型的な通信開始シーケンスにおいては、通信端末はSIP INVITE、200 OK、ACKの3wayハンドシェイクを通して通信相手の呼び出しと通信方式の交渉を行うが、このうちのINVITEと200 OKのメッセージボディ部にはSDP(Session Description Protocol: 非特許文献2参照)で記述したセッション情報が含まれる。INVITEと200 OKのSDPは、それぞれ通信方式の提案(Offer)と選択(Answer)に対応しており、端末はこの情報をもとにして動画像の通信方式を決定する(非特許文献3参照)。

一方、動画像の符号化にはMPEG(MPEG-2、MPEG-4)のなどの動画像圧縮符号化技術が用いられる。MPEG-2は非特許文献4に、MPEG-4は非特許文献5に詳しく説明されている。また、動画像の転送には非特許文献6のRTP (Real-time Transport Protocol)などが用いられる。MPEG-2やMPEG-4で符号化された動画像符号化列をRTPパケットに格納する方法は、非特許文献7、非特許文献8にそれぞれ記載されている。

ところで、近年インターネットにおける通信セキュリティへの関心が高まっており、企業ユーザが顧客とテレビ会議を行う場合などには、動画像を暗号化して転送したいというニーズがある。暗号化通信を行う際には、まずSIP/SDPによるセッション確立時に端末間で暗号化方式や暗号化鍵の交渉(鍵交換処理)を行い、続いてRTP通信の暗号化を開始する。SDPで鍵交換処理を行う方法は、非特許文献9〜11に記載されている。また、RTP通信を暗号化する方式は、SRTP(Secure RTP)プロトコルとして非特許文献12に記載されている。

IETF RFC3261 "SIP: Session Initiation Protocol"、2002年6月

IETF RFC2327 "SDP: Session Description Protocol"、1998年4月 IETF RFC3264 "An Offer/Answer Model with the Session Description Protocol (SDP)"、2002年6月「ポイント図解式最新MPEG教科書」藤原洋監修/マルチメディア通信研究会編、アスキー出版局「H.323/MPEG-4教科書」大久保榮/川島正久監修、IE Institute IETF RFC3550"RTP: A Transport Protocol for Real-Time Applications"、2003年7月 IETF RFC2250"RTP Payload Format for MPEG1/MPEG2 Video"、1998年1月 IETF RFC3016"RTP Payload Format for MPEG-4 Audio/Visual Streams"、2000年11月 IETF Draft"Session Description Protocol Security Descriptions for Media Streams"、2004年2月、http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions-03.txt IETF Draft"MIKEY: Multimedia Internet KEYing"、2003年12月http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-08.txt IETF Draft"Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)"、2004年2月、http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-10.txt、 IETF RFC3771"The Secure Real-time Transport Protocol"、2004年3月

しかしながら、動画像のようにビットレートの大きなデータをリアルタイムに暗号化して送受信する際には、通信装置の処理能力に対して過負荷となり、遅延やパケットロス、が発生したり、通信装置上で動作する他のアプリケーションに影響を与えてしまうという問題があった。

例えば、Mobile Celeron 1GHz、メモリ256MBを搭載したPCにおける暗号処理速度は、AESで30Mb/s、3DESで5Mb/s程度である。従って、一般に数Mb/s以上の処理速度が要求される動画像通信では、暗号処理の負荷が著しいオーバヘッドとなる。
そこで本発明は、上記従来技術の問題点に鑑み、動画像のようにビットレートの大きいデータをリアルタイムに転送する通信装置が、選択的に暗号処理を行い計算コストを低減することを目的とする。

上記目的を達成するために、本発明は、動画像のフレーム種別や動画像データに追加されるヘッダの内容をもとにして、選択的に暗号処理を行うことの可能な動画像通信装置を提供する。より具体的には、動画像の符号化がMPEG-2により行われる場合に、Iフレームを含むパケットのみを選択して暗号化を行う。

上記発明によれば、動画像のようにビットレートの大きなデータに対して暗号処理を行う場合にも、情報の秘匿性を確保しながら計算量を低減することが可能となる。

以下、図面を参照して本発明の実施の形態を説明する。
図3は、本実施例における動画像送信装置と動画像受信装置が通信を行う際のシステム構成を示す。動画像送信端末3、動画像受信端末4、SIPサーバ2はデータ通信網1に接続されており、相互にデータ通信を行うことができる。また動画像送信端末3と動画像受信端末4は、SIPサーバ2に収容されており、セッション制御を行うSIP/SDPパケットはSIPサーバ2を介してやり取りする。一方、動画像の転送を行うRTPパケットは、動画像送信端末3と動画像受信端末4の間で直接通信を行う。

図4は、動画像送信端末3と動画像受信端末4が暗号化通信を行う際のシーケンス例を示す。動画像送信端末3と動画像受信端末4は動画像通信に先立ち、SIP INVITE(51)、200 OK(52)、ACK(53)を交換し、通信相手の呼び出しと通信方式の交渉を行う。INVITE(51)のメッセージボディ部に含まれるSDPには、特定のRTPストリームに対して適用される暗号処理の内容(暗号化アルゴリズム、メッセージ認証アルゴリズム、暗号化鍵、メッセージ認証鍵など)とともに、動画像送信端末3が希望する「セキュリティレベル」の提案が記載されている。また200 OK(52)のSDPには、動画像送信装置4が選択した暗号処理の内容やセキュリティレベルが含まれている。「セキュリティレベル」は、本発明により導入された概念であり、具体的には特定のRTPパケットに対して暗号処理を行うか否かを判断するためのアルゴリズムを指定する。

動画像送信端末3と動画像受信端末4は、INVITE(51)と200 OK(52)のSDPをもとに動画像の通信方法(動画像符号化方式、IPアドレス、ポート番号、暗号化処理の内容、セキュリティレベルなど)を決定する。
次に動画像送信装置3は、決定した通信方法に従い動画像の送信を開始する(54)。RTPによる動画像通信は、前述したSRTPなどを用いて保護されるが、動画像送信装置3は動画像受信装置4と事前に交渉したセキュリティレベルに基づいてパケットを選択的に暗号化する。また、そのパケットに対して暗号化処理を行ったか否かを暗号化フラグとしてパケットに追加し送信する。一方、動画像受信装置4は、受信した動画像パケットの復号化処理を行うか否かを、パケットに設定されている暗号化フラグを用いて判断する。なお、動画像送信端末3と動画像受信端末4は、55〜57に示すように通信中にINVITE、200 OK、ACKを再度交換してセキュリティレベルの変更を行ってもよい。

図5(a)は、動画像送信端末3と動画像受信端末4の間で交換されるSIPパケットのフォーマットを示す。SIPパケットは、IPヘッダ部(81)、UDPヘッダ部(82)、SIPメッセージ部(83)から構成され、SIPメッセージ部(83)はさらにSIPスタートライン(84)、SIPメッセージヘッダ(85)、空行(86)、SIPメッセージボディ部87)に分解される。空行とSIPメッセージボディ部が存在しない場合や、複数連続する場合もある。

図5(b)は、SIP INVITEメッセージ例を示す。INVITEはセッションの確立を要求するメソッドである。スタートラインには、メソッド名(INVITE)、リクエストの対象(sip:t2)、SIPバージョン情報(SIP/2.0)が含まれる。また、SIPメッセージヘッダには、メッセージの宛先(To: t2 <sip:t2>)、送信元(From: t1 <sip:t1>)、メッセージボディ部のデータ種別(Content-Type: application/sdp)、メッセージボディ部のデータ長(Content-Length: 290)などが含まれる。図5(b)の例では、この後さらに空行をはさんでメッセージボディ部が続き、SDPで記述されたセッション情報が格納されている。このSDPは、メッセージの送信元が希望する通信方式を提案するものであり、動画像符号化方式(m行の4番目のパラメータ)、通信に使用するIPアドレス(c行の3番目のパラメータ)、受信用ポート番号(m行の2番目のパラメータ)、暗号化処理の内容(a=crypto…行)などに加えて、本発明により規定されるセキュリティレベル(91:a=security-level行)を含む。

図5(c)は、SIP 200 OKのメッセージ例を示す。200 OKは、特定の要求(ここではINVITE)に対する成功応答である。スタートラインには、SIPバージョン(SIP/2.0)、ステータスコード(200)、テキストによるステータスコードの説明(OK)が含まれる。また、SIPメッセージヘッダには、図5(b)のINVITEと同様に、メッセージのあて先(To: t2 <sip:t2>)、送信元(From: t1 <sip:t1>)、メッセージボディ部のデータ種別(Content-Type: application/sdp)、メッセージボディ部のデータ長(Content-Length: 300)などが含まれる(メッセージのあて先や送信元は、対応するリクエストメッセージからコピーしたものである)。SIPメッセージのボディ部のSDPは、メッセージの送信元が選択したセッション情報を示しており、動画像符号化方式(m行の4番目のパラメータ)、通信に使用するIPアドレス(c行の3番目のパラメータ)、受信用ポート番号(m行の2番目のパラメータ)、暗号化処理の内容(a=crypto…行)などに加えて、本発明により規定されるセキュリティレベル(92:a=security-level行)が含まれる。ここで、IPアドレスやポート番号の値は200 OKを送信する端末の条件に応じて新規に選択するが、動画像符号化方式や暗号処理の内容は、INVITEのSDPに含まれているパラメータの中から適切なものを選択して設定する。

図5(b)INIVTE、図5(c)200 OKのSDPから動画像の通信方法を決定する際には、以下の処理を行う。まず、通信に使用するIPアドレスやポート番号に関しては、それぞれの端末が指定した値をそのまま採用する(ポート番号はあくまで動画像の受信用ポートを示すものであり、動画像送信用のポート番号は、送信側の端末が自由に選択することができる)。そして、動画像符号化方式や暗号処理の内容など、両者の合意が必要なパラメータに関しては、INVITEにより提案され、200 OKのなかで選択されたものを選ぶ。

図6を用いて、RTP/SRTPパケットフォーマットを説明する。図6(a)に示すように、RTP/SRTPパケット(103)は、IPヘッダ部(101)、UDPヘッダ部(102)の後ろに続く形となる。
図6(b)はRTPパケットフォーマットの例を示す。RTPパケットは、RTPヘッダ部とペイロード部に分けられる。RTPヘッダ部には、RTPバージョン(v)、パディングの有無を示すフラグ(P)、拡張ヘッダの有無を示すフラグ(x)、寄与情報源識別子(CSRC)の数(M)、ペイロードタイプに依存した意味を持つマーカビット(M)、ペイロードタイプ(PT)、シーケンス番号(Sequence Number)、タイムスタンプ(Time Stamp)、ストリーム識別子(SSRC)などが含まれる。ペイロード部には、ペイロードタイプごとに定義される形式に従い、音声や動画像データが格納される。例えば、動画像の符号化にMPEG-2やMPEG-4を用いる場合の形式は、前述の非特許文献7や非特許文献8にそれぞれ記載されている。

図6(c)は、SRTPパケットフォーマットの一例を示す。SRTPパケットフォーマットは、RTPパケットフォーマットとほぼ同様であるが、図の例ではSRTP MKI(Master Key Index: 暗号処理に使用した鍵を指定する識別子)とAuthentication Tag(メッセージ認証用のデータ。具体的にはRTPパケットのハッシュ値)が追加されている。また、SRTPペイロード部には、RTPペイロード部を暗号化したものが格納されている(SRTPの暗号化機能とメッセージ認証機能、SRTP MKIの追加はオプションであり、実際のパケットはここで説明したフォーマットとは異なることもある)。

図7(a)と図7(b)は、本発明により規定される「暗号化フラグ」を追加したRTP/SRTPパケットの例をそれぞれ示す。この例では、RTP/SRTPヘッダ部とペイロード部の間に暗号化フラグが追加しているが、実際はパケットの任意の箇所に追加してよい。なお、上では暗号化フラグはそのパケットの暗号化処理を行ったか否かを示すと説明したが、必要に応じて図7(c)のように構成してもよい。図7(c)の暗号化フラグ(E-flag)は、暗号化ビット(112:E-bit)とメッセージ認証ビット(113:A-bit)から成る。これらは、そのパケットに対してSRTPの暗号化処理とメッセージ認証処理を行ったか否かをそれぞれ示す。

図1は、第一の実施例における動画像送信装置(3)の機能ブロックを示す。動画像送信装置(3)は、外部との通信処理を行う通信処理部(21)、セッション制御処理を行う通信制御部(13)、SDPのパーサとして機能するSDP処理部(11)、SIPプロトコル処理を行うSIP処理部(15)、動画像の圧縮符号化を行う動画像符号化部(16)、RTPプロトコル処理を行うRTP送出部(17)、通信制御部から通知されたセキュリティレベルに基づき暗号処理を行うか否かを判定する暗号化判定部(18)、暗号化判定部(18)が判定した内容を暗号化フラグとしてパケットに追加するフラグ追加部(19)、RTPパケットに対して暗号化処理を行うSRTP送出部(20)を含み構成される。ここで、暗号化判定部(18)とフラグ追加部(19)は本特許により新規に導入される機能ブロックである。また本発明の動画像通信装置は、通信制御部(13)においてセッション確立時にセキュリティレベルを決定する手段(14)と、SDP処理部(11)においてセキュリティレベルを記述する手段(12)を備える。

暗号化判定部(18)は、前述したように特定のRTPパケットに対して暗号処理を行うか否かを判定する機能ブロックであるが、暗号化を行うパケットを選択する方法には少なくとも以下の二つが考えられる
(方式1)RTPヘッダのシーケンス番号をもとにして、一定の割合でパケットを選択する
(シーケンス番号が偶数のパケットのみ暗号化する、など。)
(方式2)動画像の圧縮符号化方式として特にMPEG-2を用いる場合、RTPペイロード
に含まれるフレーム種別(I/P/B)をもとにしてパケットを選択する
ここで、MPEGにおけるIフレーム、Pフレーム、Bフレームとは、それぞれIntra-Picture(イントラ符号化画像)、Predictive-Picture (フレーム間順方向予測符号化画像)、Bidirectionally predictive-Picture(双方向予測符号化画像)を示し、例えば単独で画像を再生可能なIフレームのみを暗号化することで、画像情報の多くを隠蔽することができる。

図2は、第一の実施例における動画像受信装置4の機能ブロックを示す。動画像送信装置(3)は、外部装置との通信処理を行う通信処理部(21)、セッション制御処理を行う通信制御部(13)、SDPのパーサとして機能するSDP処理部(11)、SIPプロトコル処理を行うSIP処理部(15)、暗号化フラグを用いてそのパケットの復号化を行うか否かを判定する復号化判定部(35)、RTPパケットの復号化処理を行うSRTP受信部(34)、RTPパケットから暗号化フラグを削除する暗号化フラグ削除部(33)、RTPプロトコル処理を行い動画像符号化列を出力するRTP受信部(32)、動画像符号化列を復号化し、ビデオ信号として出力する動画像復号化部(31)を含み構成される。復号化判定部(31)とフラグ削除部(33)は本特許により新規に導入される機能ブロックである。

第一の実施例における動画像送信端末の機能ブロック図。第二の実施例における動画像受信端末の機能ブロック図。第一の実施例におけるネットワーク構成図。第一の実施例における通信シーケンス図。 SIPパケットフォーマット。 RTPパケットフォーマット。拡張RTPパケットフォーマット。

符号の説明

３動画像送信装置、４動画像受信装置、１１ SDP処理部、１２セキュリティレベル記述手段、１３通信制御部、１４セキュリティレベル決定手段、１５ SIP処理部、１６動画像符号化部、１７ RTP送出部、１８暗号化判定部、１９フラグ追加部、２０ SRTP送出部、２１通信処理部、３１動画像復号化部、３２ RTP受信部、３３フラグ削除部、３４ SRTP受信部、３５復号化判定部、９１暗号化レベル(提案)、９２暗号化レベル(選択)、１１１暗号化フラグ。

Claims

データを圧縮符号化するデータ符号化部と、
上記圧縮符号化されたデータを、分割し、ＲＴＰヘッダを追加してＲＴＰパケットとするＲＴＰ送出部と、
上記ＲＴＰパケットを暗号化するか否かを判定する暗号化判定部と、
上記ＲＴＰパケットに上記判定の結果を反映したフラグを追加するフラグ追加部と、
上記フラグを追加されたＲＴＰパケットに対して、該フラグに基づいて暗号化を行う暗号化処理部と、
上記暗号化されたＲＴＰパケットを外部装置へ転送する通信処理部とを備えた通信装置。
上記符号化部が、複数のフレーム種別を規定するＭＰＥＧ−２に従って上記データの符号化を行い、
上記暗号化判定部が、上記ＲＴＰパケットに含まれるデータが属する上記フレーム種別に基づいて暗号化するか否かを判定する請求項１記載の通信装置。
上記暗号化判定部が、上記ＲＴＰパケットのヘッダ部に設定されたシーケンス番号に基づいて、暗号化するか否かを判定する請求項１記載の通信装置。
上記暗号化判定部が、外部装置から入力されたセキュリティレベル情報に基づいて、上記暗号化をするか否かの判定のアルゴリズムを変更する請求項１記載の通信装置。
圧縮符号化されたデータを含み、暗号化されているか否かを示すフラグを含むＲＴＰパケットを外部装置から受信する通信処理部と、
上記フラグに基づいて上記ＲＴＰパケットを復号化するか否かを判定する復号化判定部と、
上記ＲＴＰパケットに施された暗号化を復号してＲＴＰパケットとする復号化処理部と、
上記ＲＴＰパケットから上記フラグを削除するフラグ削除部と、
上記フラグを削除されたＲＴＰパケットからさらにＲＴＰヘッダを削除して、圧縮符号化されているデータを取得するＲＴＰ受信部と、
上記圧縮符号化されているデータを復号するデータ復号化部とを備えた通信装置。
ネットワークを介して接続された第一及び第二の端末を有する通信システムであって、
上記第一の端末は、
データの一部を選択的に暗号化する暗号化部と、
上記暗号化を行ったか否かを示すフラグを上記データに追加するフラグ追加部と、
上記フラグを追加されたデータを上記第二の端末へ送信する通信処理部とを備え、
上記第二の端末は、
上記第一の端末から送信されたデータを受信する通信処理部と、
上記受信したデータに追加されている上記フラグに基づいて復号化を行うか否かを判定する復号化判定部と、
上記判定に基づいて上記データを復号化する復号化部とを備えることを特徴とする通信システム。
上記データの通信前または通信中に、上記第一と第二の端末の間の通信によって暗号化を行うデータの選択方法を決定し、
上記第一の端末の暗号化部は、上記決定されたデータの選択方法によって選択されたデータを暗号化することを特徴とする請求項６記載の通信システム。