JP2006109518A - 無線通信システム、送信装置、及び、受信装置 - Google Patents

Abstract

【課題】 無線環境においても安全な著作権保護を実現可能な無線通信システムを提供す
ること。
【解決手段】 著作権保護すべきＭＰＥＧ４データを送信する携帯ＭＰＥＧ４プレーヤ１
０１と、該プレーヤ１０１から該データを受信し、デコードして表示する携帯ビューア１
０２との間で、無線リンクレイヤネットワークの認証・鍵交換手続きを行い、この認証・
鍵交換手続きの成功によってプレーヤ１０１とビューア１０２との間で共有された暗号鍵
を用いた暗号通信を利用して、プレーヤ１０１とビューア１０２との間で、ＤＴＣＰの認
証・鍵交換手続きを行い、この認証・鍵交換手続きの成功によってプレーヤ１０１とビュ
ーア１０２との間で共有された暗号鍵を用いた暗号通信を利用して、プレーヤ１０１から
ビューア１０２へ、安全に該データを転送する。
【選択図】 図１

Description

本発明は、無線を介して著作権保護を必要とするデータの転送を行う無線通信システム
、送信装置、及び、受信装置に関する。

近年、デジタルネットワーク技術の発展が急である。携帯電話やインターネットをはじ
めとしたネットワーク技術の進歩は、とどまる所を知らず、アプリケーションも、単なる
音声通話にとどまらず、多彩なものになってきた。例えば、インターネットにおける音楽
配信、あるいは携帯電話に対する無線データ網（ｉ−ｍｏｄｅ（Ｒ）など）を介した音楽
配信等は、その典型的な例といえよう。

一方、デジタル家電と呼ばれる新しい分野も注目を集めている。これは、デジタル技術
を用いた新しい家電技術であり、特にデジタル放送の開始や、ＭＤ、ＤＶＤ等のデジタル
ＡＶ技術を駆使した「デジタルＡＶ家電」の分野は、大変大きな成長が見込まれている。

これらの分野が融合したと考えられるものが「ネットワーク家電」の分野である。ＩＥ
ＥＥ１３９４等のネットワークを介してデジタルＡＶデータ（ＭＰＥＧ２映像等）をやり
取りすることができ、多くのアプリケーションを新たに生み出すことも可能である。

このような状況で考慮しなければならないのが、著作権保護の問題である。デジタルデ
ータは、加工や蓄積が容易、劣化が無い、等の利点がある反面、「コピーしやすい」等の
特徴があり、本来、何らかの対価を支払って購入すべきデジタルデータ（例えば映画や音
楽など）であっても、これを不正にコピーして入手しあるいは譲渡することが可能なわけ
である。よって、著作権に係るデジタルデータに対する不正行為を未然に防ぐ仕組みを構
築することが重要になる。その代表
的な例が、ＩＥＥＥ１３９４におけるＤＴＣＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉ
ｏｎ Ｃｏｎｔｅｎｔｓ Ｐｒｏｔｅｃｔｉｏｎ）である。これは、ＩＥＥＥ１３９４上
のＡＶデータの送信装置と受信装置との間で、認証・鍵交換の手順を行ない、ＡＶデータ
を暗号化・復号化するための暗号鍵を共有した上で、この暗号鍵によって、ＡＶデータを
暗号化した上でＩＥＥＥ１３９４上を転送することで、第三者による盗聴を防止すること
ができる。また、あらかじめ安全性
を保証する機器にしか、上記認証・鍵交換（さらに具体的には、証明書／Ｃｅｒｔｉｆｉ
ｃａｔｅの交換）を行なわせないような工夫をすることで、不正な受信装置での不正コピ
ーを未然に防ぐような仕組みが備わっている。
特開２０００−１７４７９７公報

しかしながら、上記の仕組みはＩＥＥＥ１３９４やＵＳＢなどの有線ネットワークを前
提とした仕組みである。すなわち、無線ネットワークを使ったＡＶデータの転送を考えた
場合、装置間でＡＶデータを転送することができてしまうため（ケーブルで装置間を接続
する必要が無く、単に無線を経由して、送信を指示するだけでＡＶデータを送信して貰う
ことが可能であるため）、第三者がコンテンツを傍受することが可能になってしまい、不
正行為を防止することができない、と言う問題点があった。

本発明は、上記事情を考慮してなされたもので、無線環境においても安全な著作権保護
を実現可能な無線通信システム、送信装置、及び、受信装置を提供することを目的とする
。

本発明は、コンテンツデータを送信する送信装置と、この送信装置から送信された前記
コンテンツデータを受信する受信装置が無線の通信路を介して接続される無線通信システ
ムにおいて、 前記受信装置と前記送信装置とが互いに通信することを許可された機器で
あるか否かを判断するための第１の認証を行う第１の認証手段と、前記送信装置と前記受
信装置とが互いにある著作権保護機能を備えた機器であるか否かを判断するための第２の
認証を行う第２の認証手段と、前記第１の認証手段により、前記送信装置と前記受信装置
との間で前記第１の認証が成功した場合に、前記送信装置と前記受信装置との間で共通に
使用される第１の暗号鍵を生成し、共有する第１の鍵交換手続き手段とを備え、前記第１
の鍵交換手続き手段で共有された前記第１の暗号鍵を用いた無線の暗号通信路を確立し、
前記第２の認証手段による前記第２の認証を行うようにした。

また、本発明は、コンテンツデータを無線の通信路を介して受信装置へ送信する送信装
置において、前記受信装置が通信することを許可された機器であるか否かを判断するため
の第１の認証を行う第１の認証手段と、前記受信装置が著作権保護機能を備えた機器であ
るか否かを判断するための第２の認証を行う第２の認証手段と、前記第１の認証手段によ
り、前記受信装置との間で前記第１の認証が成功した場合に、前記受信装置との間で共通
に使用される第１の暗号鍵を生成し、共有する第１の鍵交換手続き手段とを備え、前記第
１の鍵交換手続き手段で共有された前記第１の暗号鍵を用いて無線の暗号通信路を確立し
、前記第２の認証手段による前記第２の認証を行うようにした。

また、本発明は、送信装置からコンテンツデータを無線の通信路を介して受信する受信
装置において、前記送信装置が通信することを許可された機器であるか否かを判断するた
めの第１の認証を行う第１の認証手段と、前記送信装置が著作権保護機能を備えた機器で
あるか否かを判断するための第２の認証を行う第２の認証手段と、前記第１の認証手段に
より、前記送信装置との間で前記第１の認証が成功した場合に、前記送信装置との間で共
通に使用される第１の暗号鍵を生成し、共有する第１の鍵交換手続き手段とを備え、前記
第１の鍵交換手続き手段で共有された前記第１の暗号鍵を用いて無線の暗号通信路を確立
し、前記第２の認証手段による前記第２の認証を行うようにした。

なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に
係る発明としても成立する。

また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行
させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための
、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムを記
録したコンピュータ読取り可能な記録媒体としても成立する。

本発明では、認証手続きを成功させることのできる正当な装置間でのみ、正しく暗号鍵
を共有することができ、正しく暗号鍵を共有することができた装置間でのみ、暗号通信に
よるデータ転送が可能になる。

以下、図面を参照しながら発明の実施の形態を説明する。

（第１の実施形態）
図１に、本実施形態の無線通信システムの構成例を示す。

図１に示されるように、ソース機器となる携帯ＭＰＥＧ４プレーヤ１０１と、これに対
するシンク機器となる携帯ビューア１０２とが、ローカルエリア無線ネットワークで接続
できる範囲内に位置している（携帯ＭＰＥＧ４プレーヤ１０１と携帯ビューア１０２はそ
れぞれこのローカルエリア無線ネットワークの無線インタフェースを有するものとする）
。

ここで、図１に示されるように、携帯ＭＰＥＧ４プレーヤ１０１と携帯ビューア１０２
の他に、携帯ビューア１０３（携帯ビューア１０２と同様の基本構成とする）も携帯ＭＰ
ＥＧ４プレーヤ１０１へローカルエリア無線ネットワークで接続できる範囲内に位置して
いる場合を考える。

すなわち、これら３つの携帯端末が同一の無線ＬＡＮ（Ｂｌｕｅｔｏｏｔｈの（登録商
標、以下同様）場合は単一ピコネット）内に存在しており、携帯ＭＰＥＧ４プレーヤから
Ｂｌｕｅｔｏｏｔｈ経由でどちらの携帯ビューアに対してもＭＰＥＧ４映像を転送するこ
とができる範囲内に存在しているものとする。そして、携帯ＭＰＥＧ４プレーヤ１０１と
携帯ビューア１０２は同一人物…Ａ氏とする…の携帯物であり（Ａ氏が対にして使用しよ
うとしているものであり）、携帯ビューア１０３はＡ氏とは異なる人物…Ｂ氏とする…の
携帯物である（Ａ氏が使用しようとしていないものである）とする。なお、ここでは簡単
のために携帯ビューア１０３について考えるが、Ａ氏以外の人物の携帯する携帯ビューア
が他に接続範囲内に存在していても携帯ビューア１０３と同様である。

また、転送するＭＰＥＧ４映像（ＭＰＥＧ４データ）は、著作権保護をかけた上で転送
すべきものである場合を考える。

なお、ここでは、ローカルエリア無線ネットワークとしては、Ｂｌｕｅｔｏｏｔｈを仮
定して説明する。Ｂｌｕｅｔｏｏｔｈは、低コスト、低消費電力などを特徴とする無線Ｌ
ＡＮの一種であり、多くの携帯端末や家電製品などへの搭載が期待されている（例えば、
ｈｔｔｐ：／／ｗｗｗ．ｂｌｕｅｔｏｏｔｈ．ｃｏｍにて取得可能に開示されている文書
に説明が詳しい）。また、以下で用いるＢＴの表記は、Ｂｌｕｅｔｏｏｔｈを略したもの
である。

以下、図１のような状況において、携帯ＭＰＥＧ４プレーヤ１０１から携帯ビューア１
０２に対してのみＭＰＥＧ４映像を転送可能（携帯ビューア１０２においてのみ再生、視
聴可能）とするための構成について説明する。

図２に、携帯ＭＰＥＧ４プレーヤ１０１の内部構造の一例を示す。

図２に示されるように、携帯ＭＰＥＧ４プレーヤ１０１は、Ｂｌｕｅｔｏｏｔｈの物理
レイヤ処理を実行するＢｌｕｅｔｏｏｔｈインタフェース（Ｉ／Ｆ）処理部１１、Ｂｌｕ
ｅｔｏｏｔｈのデータリンクレイヤ処理を実行するｂｌｕｅｔｏｏｔｈ通信処理部１２を
備えている。

Ｂｌｕｅｔｏｏｔｈは、そのスペック内に「Ｂｌｕｅｔｏｏｔｈ Ｓｅｃｕｒｉｔｙ」
なる認証、鍵交換、データ暗号化の方式が規定されている。つまり、Ｂｌｕｅｔｏｏｔｈ
というリンクレイヤ方式内部に、データ暗号化や、認証・鍵交換の方式が定められている
。携帯ＭＰＥＧ４プレーヤ１０１は、この処理部（ＢＴ認証・鍵交換手続き（データのや
り取り）を行うためのＢＴ認証・鍵交換処理部１３、ＰＩＮコードを入力するためのＰＩ
Ｎコード入力部１４、送信すべきデータを暗号化し、受信したデータを復号化するための
ＢＴレイヤ暗号・復号化部１５）を、内部に持っている。Ｂｌｕｅｔｏｏｔｈレベルの認
証は、ＰＩＮコードと呼ばれるコード（例えば、数桁の数字やパスワード、あるいは指紋
情報などの身体情報、等）の照合によって行われる。

この他、携帯ＭＰＥＧ４プレーヤ１０１は、ＭＰＥＧ４ＡＶデータを蓄積しておくＭＰ
ＥＧ４ストレージ１９、これをＢｌｕｅｔｏｏｔｈパケットに変換するパケット化部１８
、さらにＭＰＥＧ４のデータを暗号化して転送するための著作権保護レイヤ（アプリケー
ションレベル）の処理部（ＤＴＣＰ認証・鍵交換手続き（データのやり取り）を行うため
のＤＴＣＰ認証・鍵交換部１６、送信すべきデータを暗号化するためのＤＴＣＰ暗号化部
１７）を内部に持つ。

ここで、ＤＴＣＰとは、Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ
ｓ Ｐｒｏｔｅｃｔｉｏｎの略で、ＩＥＥＥ１３９４やＵＳＢなどでデファクトスタンダ
ードとなっている著作権保護の方式である。著作権保護が必要なＡＶデータ（例えば、Ａ
Ｖデータに著作権保護が必要か否かを示す情報が付加されている）に対して、送信装置と
受信装置との間で、認証・鍵交換を行ない、ＡＶデータを暗号化して転送する仕組みが備
わっている（例えば、ｈｔｔｐ：／／ｗｗｗ．ｄｔｌａ．ｃｏｍにて取得可能に開示され
ている文書に説明が詳しい）。

図３に、携帯ビューア１０２（１０３）の内部構造の一例を示す。

図３に示されるように、携帯ビューア１０２は、Ｂｌｕｅｔｏｏｔｈインタフェース（
Ｉ／Ｆ）処理部２１およびｂｌｕｅｔｏｏｔｈ通信処理部２２、Ｂｌｕｅｔｏｏｔｈレベ
ルの認証・鍵交換や暗号化の処理部（ＢＴ認証・鍵交換手続き（データのやり取り）を行
うためのＢＴ認証・鍵交換処理部２３、ＰＩＮコードを入力するためのＰＩＮコード入力
部２４、送信すべきデータを暗号化し、受信したデータを復号化するためのＢＴレイヤ暗
号・復号化部２５）、ＡＶデータ（アプリケーションレベル）の認証・鍵交換や暗号化を
行う処理部（ＤＴＣＰ認証・鍵交換手続き（データのやり取り）を行うためのＤＴＣＰ認
証・鍵交換部２６、受信したデータを復号化するためのＤＴＣＰ復号化部２７）を備えて
いる。

また、携帯ビューア１０２は、ＢｌｕｅｔｏｏｔｈパケットをＭＰＥＧ４データにリア
センブリするパケットリアセンブリ部２８、ＭＰＥＧ４データをデコードするＭＰＥＧ４
デコーダ２９、ＭＰＥＧ４データを表示するためのディスプレイ３０を備えている。

図４に、Ｂｌｕｅｔｏｏｔｈレイヤの認証手順の概要を示す。
各々の装置（携帯ＭＰＥＧ４プレーヤ、携帯ビューア）では、ＰＩＮコードが入力され
る（ステップＳ１）。なお、ＰＩＮコードは、その都度入力する方法や、予め入力して設
定しておく方法などがある。
両装置は、（ＢＴ認証・鍵交換処理部１３，２３により）Ｂｌｕｅｔｏｏｔｈレイヤの
認証手順を行う（ステップＳ２）。
両装置間でＰＩＮコードを交換し、それらのＰＩＮコードが一致して認証に成功すれば
（ステップＳ３）、ｂｌｕｅｔｏｏｔｈレイヤの鍵交換手順が行われ、鍵共有に成功する
（ステップＳ４）。
この後、（ＢＴレイヤ暗号・復号化部１５，２５が）共有したｂｌｕｅｔｏｏｔｈレイ
ヤの鍵を用いるによって、（ＤＴＣＰ認証・鍵交換部１６，２６による）ＤＴＣＰ認証・
鍵交換を安全に行うことができる。これによって、ＤＴＣＰの鍵を共有し、ＭＰＥＧ４デ
ータの暗号通信が可能になる（ＤＴＣＰ暗号化部１７で暗号化し、ＤＴＣＰ復号化部２７
で復号化することが可能になる）。
一方、両装置のＰＩＮコードが一致せず認証に失敗すれば（ステップＳ３）、ｂｌｕｅ
ｔｏｏｔｈレイヤの鍵交換手順が行われるが、鍵共有に失敗する（ステップＳ５）。
この場合には、ｂｌｕｅｔｏｏｔｈレイヤの鍵が共有されていないので、たとえ（ＤＴ
ＣＰ認証・鍵交換部１６，２６による）ＤＴＣＰ認証・鍵交換が動作しても、（間違った
ｂｌｕｅｔｏｏｔｈレイヤの鍵で復号化を行うことになり）、ＤＴＣＰ認証・鍵交換を成
功させることができない（ＤＴＣＰの鍵を共有することができない）。さらに、ＤＴＣＰ
認証・鍵交換が成功していなければ、たとえ（ＤＴＣＰ暗号化部１７でＤＴＣＰの鍵を用
いて）暗号化されたＭＰＥＧ４データを受信しても、（ＤＴＣＰ復号化部２７では正しい
ＤＴＣＰの鍵を知らないので）その復号化ができない。
なお、両装置のＰＩＮコードが一致せず認証に失敗した場合には、ｂｌｕｅｔｏｏｔｈ
レイヤの鍵交換手順自体を行わないようにしてもよい。

なお、本実施形態では、両装置のＰＩＮコードの値の一致をもって認証の成功としてい
るが、その他、一方のＰＩＮコードの値と他方のＰＩＮコードの値とが予め定められた一
定の関係（例えば、ユーザ属性情報として住所情報の一部を利用する関係、等）にある場
合に、認証の成功とするようにしてもよい（なお、両装置のＰＩＮコードの値が一致する
という関係も、一定の関係の一場合である）。

ここで、ＰＩＮコードのバリエーションについて説明する。

まず、ＰＩＮコードの入力あるいは設定方法として、種々のバリエーションがある。

例えば、（１）ユーザがその都度入力する方法、（２）ユーザが予め設定しておく方法
、（３）製造者または販売者等が（ユーザが変更できない形で）予め設定しておく方法、
（４）上記の（１）〜（３）の全部又は一部を併用する方法（例えば、（１）コードと（
３）のコードを連結する等）など、種々の方法が考えられる。また、例えば、ユーザが上
記の（１）または（２）について適宜選択可能とする方法もある。

また、ＰＩＮコードの内容としても、種々のバリエーションがある。

（１）または（２）の方法の場合、例えば、ＰＩＮコードをユーザがその都度決定する
方法がある。また、例えば、一方の装置…例えば携帯ＭＰＥＧ４プレーヤ…内でランダム
にパスワードを発生させ、これを該一方の装置側でＰＩＮコードとして記憶するとともに
ユーザに呈示し、これを読み取ったユーザが同一のパスワードを他方の装置…例えば携帯
ビューア…に入力する方法もある。また、指紋情報、声門情報、あるいは角膜情報等を用
いる方法もある（この場合、それら情報を採取する装置が、携帯ＭＰＥＧ４プレーヤや携
帯ビューアに内蔵されているか、または携帯ＭＰＥＧ４プレーヤや携帯ビューアに外部接
続可能である必要がある）。

また、（２）の方法の場合に、携帯ＭＰＥＧ４プレーヤや携帯ビューアに、ユーザ属性
情報が登録されているならば、この情報（例えば、ユーザ名、住所、年令、学校名、職業
、会社名、部課名、家族名等）に基づいてＰＩＮコードを生成する方法もある（ただし、
ＰＩＮコードを生成するもととなる情報は、両装置でＰＩＮコードを同一にするような値
…例えば同一の値…にしておく必要がある）。

また、（３）の方法の場合に、製造者または販売者等が、製造時または販売時に、１セ
ットの携帯ＭＰＥＧ４プレーヤや携帯ビューアに同一の乱数を設定しておく方法がある。
また、販売者が、販売時に、ユーザの指紋情報等を採取して１セットの携帯ＭＰＥＧ４プ
レーヤや携帯ビューアに設定しておく方法がある。

さて、本実施形態の携帯ＭＰＥＧ４プレーヤおよび携帯ビューアは、「正当な対になる
プレーヤ／ビューア間では、ＡＶデータ転送アプリが正常に稼動する」、「正当な対でな
いプレーヤ／ビューア間では、ＡＶデータ転送アプリが正常に稼動しない（ビューアでＡ
Ｖデータは正常に再生できない）」という状況を実現している。例えば、同一人物が所有
する携帯ＭＰＥＧ４プレーヤおよび携帯ビューアを正当な対とした場合に、自分の所有す
る携帯ＭＰＥＧ４プレーヤからのデータが自分の所有る携帯ビューアで再生されるが、自
分の所有する携帯ＭＰＥＧ４プレーヤからのデータが他人の所有る携帯ビューアで再生さ
れず、かつ、自分の所有する携帯ビューアで他人の所有する携帯ＭＰＥＧ４プレーヤから
のデータが再生されない、という環境を実現できる。

つまり、一般的に、インタフェースが無線の場合には、プレーヤから出力された電波は
自ずと一定範囲内のビューアにて受信し得る状態にさらされるので、これをビューア側か
ら見ると、各々の携帯ビューアは、正当な対になる携帯プレーヤにも、それ以外の携帯プ
レーヤにも、アクセスする（送信を指示する）ことが可能であり得てしまう。ここで、著
作権保護レイヤにおいては、両方の装置（送信側の装置と受信側の装置）がＤＴＣＰコン
プライアント（ＤＴＣＰ準拠）なデバイスであれば、認証鍵交換は、どちらの場合にも成
立し得てしまう。つまり、著作権保護レイヤでは、相手側の装置が正当な対になる装置で
あるのか、それ以外の装置であるのかについて区別することができない。そこで、相手側
の装置が正当な対になる装置であるのか、それ以外の装置であるのかを区別するために、
本実施形態では、Ｂｌｕｅｔｏｏｔｈレベルの認証を用いるようにしている。

すなわち、Ｂｌｕｅｔｏｏｔｈレベルでの認証・鍵交換が成立すると、それは「正当な
対になる装置である」と判断し、アプリケーションレベル（ＤＴＣＰレベル）の認証・鍵
交換に移行する。Ｂｌｕｅｔｏｏｔｈレベルでの認証・鍵交換が成立しないと、それは「
正当な対になる装置ではない」と判断して、アプリケーションレベル（ＤＴＣＰレベル）
の認証・鍵交換に移行することを拒否することとする。

これは、Ｂｌｕｅｔｏｏｔｈレベルの認証・鍵交換のレベルで認証が成立すれば、その
両装置（送信装置と受信装置）が正当な対になる装置であると認識することができること
による。すなわち、Ｂｌｕｅｔｏｏｔｈレベルの認証が、「両装置（送信装置と受信装置
）に、同一のＰＩＮコード（例えば、数桁の数字やパスワード、あるいは指紋情報等）を
入力することができる」あるいは「両装置（送信装置と受信装置）に、同一のＰＩＮコー
ドが設定されている」ことを根拠として、この値を用いて認証手続きを行なっていること
から、この結果、両装置は正当な対であると推測・認識するのに十分である（正当な対で
ない装置に入力されたＰＩＮコード同士が偶然一致する確立はきわめて小さい）と考えら
れるためである。

例えば、同一人物が所有する（あるいは占有する）携帯ＭＰＥＧ４プレーヤと携帯ビュ
ーアが正当な対をなすものとした場合に、Ａ氏が自分の持つ携帯ＭＰＥＧ４プレーヤと携
帯ビューアに同一のＰＩＮコード（パスワード）を入力することはできるが、Ｂ氏がこれ
と同じＰＩＮコード（パスワード）を推測して自分の持つ携帯ビューアに入力することは
大変な困難が伴うので、ＭＰＥＧ４プレーヤと携帯ビューアで入力されたＰＩＮコードが
同一ならば同一人物が所有する正当な対であると判定し、ＭＰＥＧ４プレーヤと携帯ビュ
ーアで入力されたＰＩＮコードが相違するならば異なる人物が所有する正当でない対であ
ると判定することができる。また、ＰＩＮコードに指紋情報等を用いる場合には、Ｂ氏が
Ａ氏と同じＰＩＮコード（指紋情報等）を自分の持つ携帯ビューアに入力することは、Ａ
氏の指紋情報等を盗用でもできないかぎり、不可能である。

ここで、図１の携帯ＭＰＥＧ４プレーヤ１０１と携帯ビューア１０２との間のやり取り
および携帯ＭＰＥＧ４プレーヤ１０１と携帯ビューア１０３との間のやり取りを例にとっ
て説明する。

図５に、正当な対になるＡ氏の携帯ＭＰＥＧ４プレーヤ１０１と携帯ビューア１０２と
の間で行われるシーケンスの一例を示す。

なお、図５においてリンクレイヤによる暗号化および復号化に関する記載は自明である
ので省いてある。

この場合、まず、携帯ＭＰＥＧ４プレーヤ１０１と携帯ビューア１０２の両装置には、
それぞれ、所定のタイミングで（例えば、事前に、あるいは使用時に）、所定の方法によ
るＰＩＮコードの入力がなされる（ステップＳ１１，Ｓ１２）。ここでは、携帯ＭＰＥＧ
４プレーヤ１０１側で入力されたＰＩＮコードの値をｘとし、携帯ビューア１０２側でも
ＰＩＮコードの値として同じ値ｘが入力されたものとする。両装置のＰＩＮコードの値が
一致することで、続くＢｌｕｅｔｏｏｔｈレイヤ・認証手順を成功裡に終了させることが
できる。

続いて、Ｂｌｕｅｔｏｏｔｈレイヤ・リンクキー共有手順を行って（ステップＳ１３）
、それに引き続く認証・鍵交換に用いるリンクキーＫｌの値を共有する（ステップＳ１４
，Ｓ１５）。

続いて、Ｂｌｕｅｔｏｏｔｈレイヤの認証手順を行う（ステップＳ１６）。この場合は
、ＰＩＮコードの共有により、認証が成立する。

続いて、Ｂｌｕｅｔｏｏｔｈレイヤ鍵交換手順を行って（ステップＳ１７）、Ｂｌｕｅ
ｔｏｏｔｈレイヤ暗号鍵Ｋｂｔの値を共有する（ステップＳ１８，Ｓ１９）。

これによって、Ｂｌｕｅｔｏｏｔｈレイヤにおいて、両装置間で、任意のデータの交換
を暗号化の上（他人に盗聴、書き換えができないようにして）行うことができるようにな
る。

次に、携帯ＭＰＥＧ４プレーヤ１０１と携帯ビューア１０２の両装置は、ＤＴＣＰ（著
作権保護レイヤ）の認証・鍵交換を行うフェーズに移る。ここで、両装置は、ＤＴＣＰの
認証・鍵交換の手順の全部又は一部を、Ｂｌｕｅｔｏｏｔｈレベルの暗号化を行った上で
行うと好ましい。このようにすることで、ＤＴＣＰ認証・鍵交換を、「（Ｂｌｕｅｔｏｏ
ｔｈレベルでの認証・鍵交換に成功した）正当な対をなす装置間でのみ」行なう（完遂す
る）ことを保証できるようになり、
ひいては「正当な対をなす（例えば、同一人物の携帯する）装置間でのみ、著作権保護レ
イヤ（ＤＴＣＰ）の認証・鍵交換が成立する」、「正当な対をなす（例えば、同一人物の
携帯する）装置間でのみ、著作権保護レイヤ（ＤＴＣＰ）レベルの暗号鍵の共有が出来る
」ということが可能になる。

さて、携帯ＭＰＥＧ４プレーヤ１０１と携帯ビューア１０２の両装置は、ＤＴＣＰ認証
・鍵交換を、Ｂｌｕｅｔｏｏｔｈレイヤレベルの暗号化を利用して行ない（ステップＳ２
０）、両装置間でのＤＴＣＰレイヤ（著作権保護レイヤ）の暗号鍵Ｋｃの共有が達成され
る（ステップＳ２１，Ｓ２２）。

これを受けて、送信側装置である携帯ＭＰＥＧ４プレーヤ１０１は、送信するＡＶコン
テンツ（ＭＰＥＧ４データ）を暗号鍵Ｋｃで暗号化して（ステップＳ２３）、受信側装置
である携帯ビューア１０２に送信する（ステップＳ２４）。携帯ビューア１０２は、ＤＴ
ＣＰレベルの暗号鍵Ｋｃを共有しているため、この暗号化コンテンツを復号化することが
出来、ＭＰＥＧ４データのとりだしを行うことができる。すなわち、携帯ビューア１０２
は、受信した暗号化コンテンツをＤＴＣＰレベルの暗号鍵Ｋｃで復号化し（ステップＳ２
５）、ディスプレイに表示する。

これに対して、同じＢｌｕｅｔｏｏｔｈピコネット内にいる別の受信装置は、ＤＴＣＰ
レベルの認証・鍵交換を行なっていないため、暗号鍵Ｋｃを共有しておらず、このデータ
を再生することはできない。これを以下に説明する。

図６に、正当な対にならないＡ氏の携帯ＭＰＥＧ４プレーヤ１０１とＢ氏の携帯ビュー
ア１０３との間で行われるシーケンスの一例を示す。

まず、携帯ＭＰＥＧ４プレーヤ１０１と携帯ビューア１０３の両装置では、それぞれ、
所定のタイミングで（例えば、事前に、あるいは使用時に）、所定の方法によるＰＩＮコ
ードの入力がなされる（ステップＳ３１，Ｓ３２）。

しかし、この場合、前述のように携帯ＭＰＥＧ４プレーヤ１０１側で入力されたＰＩＮ
コードの値をｘとした場合に、携帯ビューア１０３側で入力されたＰＩＮコードの値ｘ’
がｘに一致することはないか、または確率的に極めて低い。すなわち、例えば、ＰＩＮコ
ードをユーザが手入力する場合には、両装置は、異なる人物が携帯する装置であるため、
両装置に同一のＰＩＮコードが入力されることは非常に難しい。また、正当な対をなす装
置に予め固有のＰＩＮコードを書き込んでおく場合には、この例ではＡ氏の携帯ＭＰＥＧ
４プレーヤ１０１とＢ氏の携帯ビューア１０３の両装置は正当な対をなす装置ではないも
のとしているので、両装置のＰＩＮコードが一致することはない。

よって、たとえＢｌｕｅｔｏｏｔｈレイヤ・リンクキー共有手順を行って（ステップＳ
３３）、それに引き続く認証・鍵交換に用いるリンクキーの値の共有を試みても（ステッ
プＳ３４，Ｓ３５）、ＰＩＮコードが一致していないので、これに基づいて生成された携
帯ＭＰＥＧ４プレーヤ１０１側のリンクキーＫｌと、携帯ビューア１０３側のリンクキー
Ｋｌ’とは一致せず、リンクキーの共有は失敗に終わることになる。

従って、続くＢｌｕｅｔｏｏｔｈレイヤ認証手順を行っても（ステップＳ３６）、これ
は失敗に終わることになる。この結果、これに引き続くＢｌｕｅｔｏｏｔｈレイヤ鍵交換
手順が行なわれない。

そして、Ｂｌｕｅｔｏｏｔｈ暗号化が成立しないため、ＤＴＣＰ認証・鍵交換手順に入
ることができず、ＤＴＣＰの認証・鍵交換を成功裡に行うことができない。すなわち、送
信側の携帯ＭＰＥＧ４プレーヤ１０１は、もし、受信側の携帯ビューア１０３より、ＤＴ
ＣＰレベルの認証・鍵交換の要求が来たとしても（ステップＳ３７）、これがＢｌｕｅｔ
ｏｏｔｈレベルの暗号化がなされない形で送信されてきた場合には、これを拒否する（ス
テップＳ３８）。よって、正当な対でない（例えば、所有者が異なる）装置同士では、著
作権保護レベルの認証・鍵交換が成立せず、著作権を保護すべきＡＶデータの転送は、行
なえないこととなる。

なお、ステップＳ３８の拒否メッセージを相手に通知する際に、その拒否の理由（リン
クレイヤすなわちＢｌｕｅｔｏｏｔｈレイヤの暗号化がかかっていないため、あるいはＢ
ｌｕｅｔｏｏｔｈレイヤの認証が行われていないため）を併せて通知するようにしてもよ
い。これは、相手が正当なもの（例えば同一所有者のもの）である場合に、Ｂｌｕｅｔｏ
ｏｔｈレイヤの認証・鍵交換の実行を促すものとなる。

なお、以上では、携帯ＭＰＥＧ４プレーヤにＭＰＥＧ４データが蓄積されているものと
しているが、ＭＰＥＧ４データを外部から取得するものであってもよいし、符号化する前
のソースデータが蓄積されていてＭＰＥＧ４コーダを備えてＭＰＥＧ４を生成してもよい
し、ソースデータを外部から取得しＭＰＥＧ４コーダでＭＰＥＧ４を生成してもよい。ま
た、ＭＰＥＧ４映像（ＭＰＥＧ４データ）以外のデータの送受信にも本発明はもちろん適
用可能である。

また、以上では、送信装置１台に対して受信装置を１台とする通信を前提として説明し
たが、送信装置から複数台の受信装置へのデータ転送も可能である。この場合には、例え
ば、図５のシーケンスにおいて、携帯ＭＰＥＧ４プレーヤと各々の携帯ビューアとの間で
、暗号鍵Ｋｃの共有までの手順を、逐次行って、認証・鍵交換に成功した全装置で暗号鍵
Ｋｃを共有するようにしてもよい。この結果、携帯ＭＰＥＧ４プレーヤがＡＶコンテンツ
を暗号鍵Ｋｃで暗号化して送信すれば、暗号鍵Ｋｃの共有に成功した正当な携帯ビューア
は、暗号化コンテンツを復号化し、表示することができる。なお、この場合に、送信装置
ごとに、あるいはコンテンツごとに、送信装置から同時にデータ転送可能な受信装置の台
数の上限を設定可能にしてもよい。

（第２の実施形態）
第１の実施形態では、著作権保護レイヤ（ＤＴＣＰ）の認証・鍵交換の手順の全部又は
一部を、Ｂｌｕｅｔｏｏｔｈレイヤの暗号・復号化部を通して行うものであった。これに
対して、第２の実施形態は、ＭＰＥＧ４データ（ＡＶデータ）の転送そのものについても
、Ｂｌｕｅｔｏｏｔｈレイヤの暗号・復号化部を通して行うようにしたものである。

本実施形態では、第１の実施形態と相違する部分を中心に説明する。

図７に、第１の実施形態における図２に対応する本実施形態の携帯ＭＰＥＧ４プレーヤ
１０１の内部構造の一例を示す。また、図８に、第１の実施形態における図３に対応する
本実施形態の携帯ビューア１０２（１０３）の内部構造の一例を示す。いずれも、第１の
実施形態に対して、ＢＴレイヤ暗号・復号化部がｂｌｕｅｔｏｏｔｈ通信処理部とＤＴＣ
Ｐ暗号化部との間に接続されている点が相違する。

また、図９に、第１の実施形態における図５のシーケンス例に対応する本実施形態にお
けるシーケンスの一例を示す。

なお、図９においてリンクレイヤによる暗号化および復号化に関する記載は自明である
ので省いてある。

これは、第１の実施形態に対して、ＡＶデータが、ＤＴＣＰレイヤ（著作権保護レイヤ
）の暗号鍵ＫｃとＢｌｕｅｔｏｏｔｈレイヤ暗号鍵Ｋｂｔによって多重に暗号化されてい
る点が相違する。すなわち、携帯ＭＰＥＧ４プレーヤは、送信する著作権保護すべきＡＶ
コンテンツを暗号鍵Ｋｃで暗号化した後に、暗号鍵Ｋｂｔで暗号化する。また、携帯ビュ
ーア１０２は、受信した暗号化されたＡＶコンテンツを暗号鍵Ｋｂｔで復号化した後に、
暗号鍵Ｋｃで復号化する。

本実施形態は、第１の実施形態と比べ、ＤＴＣＰの認証・鍵交換手順及びデータ暗号化
・復号化の両方について、Ｂｌｕｅｔｏｏｔｈ暗号化をかけて行うため、処理速度は遅く
なるものの、装置構成は単純なものにすることが可能となる（例えば、ＤＴＣＰ処理を単
一のＬＳＩで行なっている場合には、全ての入出力を、Ｂｌｕｅｔｏｏｔｈレイヤ暗号・
復号化部を経由させることで、構成が単純になる）。

なお、本実施形態においても、正当な対でない（例えば、異なる人物の）装置間では、
両装置に同一のＰＩＮコードが入力されることは非常に難しいため、Ｂｌｕｅｔｏｏｔｈ
レイヤ認証手順が失敗してしまう。よって、これに引き続くＢｌｕｅｔｏｏｔｈレイヤ鍵
交換手順が行なわれない。よって、この後、Ｂｌｕｅｔｏｏｔｈ暗号化が成立しないため
、ＤＴＣＰ認証・鍵交換手順に入ることができず、ＤＴＣＰの認証・鍵交換を成功裡に行
うことができない。よって、正当な対でない（例えば、所有者が異なる）装置同士では、
著作権を保護すべきＡＶデータの転送は、第１の実施形態と同じく、行なえないこととな
る。

なお、本実施形態では、無線ＬＡＮとして、Ｂｌｕｅｔｏｏｔｈを例に説明してきたが
、８０２．１１無線ＬＡＮや、ＷＥＣＡ方式、ＨｏｍｅＲＦ方式の無線ＬＡＮ等、リンク
レイヤレベルで認証・鍵交換、暗号化等のセキュリティ機能を持つ無線ＬＡＮは多い。本
発明は、これらの種々の無線ＬＡＮに適用することが可能である。

なお、以上の各機能は、ソフトウェアとしても実現可能である。

また、本実施形態は、コンピュータに所定の手段を実行させるための（あるいはコンピ
ュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現
させるための）プログラムを記録したコンピュータ読取り可能な記録媒体としても実施す
ることもできる。

なお、各実施形態で例示した構成は一例であって、それ以外の構成を排除する趣旨のも
のではなく、例示した構成の一部を他のもので置き換えたり、例示した構成の一部を省い
たり、例示した構成に別の機能あるいは要素を付加したり、それらを組み合わせたりする
ことなどによって得られる別の構成も可能である。また、例示した構成と論理的に等価な
別の構成、例示した構成と論理的に等価な部分を含む別の構成、例示した構成の要部と論
理的に等価な別の構成なども可能である。また、例示した構成と同一もしくは類似の目的
を達成する別の構成、例示した構成と同一もしくは類似の効果を奏する別の構成なども可
能である。
また、各種構成部分についての各種バリエーションは、適宜組み合わせて実施すること
が可能である。
また、各実施形態は、個別装置としての発明、関連を持つ２以上の装置についての発明
、システム全体としての発明、個別装置内部の構成部分についての発明、またはそれらに
対応する方法の発明等、種々の観点、段階、概念またはカテゴリに係る発明を包含・内在
するものである。

従って、この発明の実施の形態に開示した内容からは、例示した構成に限定されること
なく発明を抽出することができるものである。

本発明は、上述した実施の形態に限定されるものではなく、その技術的範囲において種
々変形して実施することができる。

本発明の一実施形態に係る無線通信システムの構成例を示す図 同実施形態に係る携帯ＭＰＥＧ４プレーヤの内部構造の一例を示す図 同実施形態に係る携帯ビューアの内部構造の一例を示す図 Ｂｌｕｅｔｏｏｔｈレイヤの認証手順の概要を説明するためのフローチャート 正当な対になる携帯ＭＰＥＧ４プレーヤと携帯ビューアとの間で行われるシーケンスの一例を示す図 正当な対にならない携帯ＭＰＥＧ４プレーヤと携帯ビューアとの間で行われるシーケンスの一例を示す図 同実施形態に係る携帯ＭＰＥＧ４プレーヤの内部構造の他の例を示す図 同実施形態に係る携帯ビューアの内部構造の他の例を示す図 正当な対になる携帯ＭＰＥＧ４プレーヤと携帯ビューアとの間で行われるシーケンスの他の例を示す図

符号の説明

１１，２１…Ｂｌｕｅｔｏｏｔｈインタフェース処理部
１２，２２…ｂｌｕｅｔｏｏｔｈ通信処理部
１３，２３…ＢＴ認証・鍵交換処理部
１４，２４…ＰＩＮコード入力部
１５，２５…ＢＴレイヤ暗号・復号化部
１６，２６…ＤＴＣＰ認証・鍵交換部
１７…ＤＴＣＰ暗号化部
１８…パケット化部
１９…ＭＰＥＧ４ストレージ
２７…ＤＴＣＰ復号化部
２８…パケットリアセンブリ部
２９…ＭＰＥＧ４デコーダ
３０…ディスプレイ
１０１…ＭＰＥＧ４プレーヤ
１０２，１０３…携帯ビューア

Claims (12)

1. コンテンツデータを送信する送信装置と、この送信装置から送信された前記コンテンツデ
   ータを受信する受信装置が無線の通信路を介して接続される無線通信システムにおいて、
   前記受信装置と前記送信装置とが互いに通信することを許可された機器であるか否かを
   判断するための第１の認証を行う第１の認証手段と、
   前記送信装置と前記受信装置とが互いにある著作権保護機能を備えた機器であるか否か
   を判断するための第２の認証を行う第２の認証手段と、
   前記第１の認証手段により、前記送信装置と前記受信装置との間で前記第１の認証が成
   功した場合に、前記送信装置と前記受信装置との間で共通に使用される第１の暗号鍵を生
   成し、共有する第１の鍵交換手続き手段とを備え、
   前記第１の鍵交換手続き手段で共有された前記第１の暗号鍵を用いた無線の暗号通信路
   を確立し、前記第２の認証手段による前記第２の認証を行うようにしたことを特徴とする
   無線通信システム。
2. 前記第２の認証手段により、前記送信装置と前記受信装置との間で前記第２の認証が成功
   した場合に、前記送信装置と前記受信装置との間で共通に使用される第２の暗号鍵を生成
   し、共有する第２の鍵交換手続き手段を更に備えたことを特徴とする請求項１に記載の無
   線通信システム。
3. 前記無線の暗号通信路を用いて、前記送信装置から前記受信装置へ前記コンテンツデータ
   を転送することを特徴とする請求項１または２に記載の無線通信システム。
4. 前記無線の暗号通信路を用いて、前記送信装置から前記受信装置へ、前記第２の暗号鍵で
   暗号化された前記コンテンツデータを転送することを特徴とする請求項１または２に記載
   の無線通信システム。
5. コンテンツデータを無線の通信路を介して受信装置へ送信する送信装置において、
   前記受信装置が通信することを許可された機器であるか否かを判断するための第１の認
   証を行う第１の認証手段と、
   前記受信装置が著作権保護機能を備えた機器であるか否かを判断するための第２の認証
   を行う第２の認証手段と、
   前記第１の認証手段により、前記受信装置との間で前記第１の認証が成功した場合に、
   前記受信装置との間で共通に使用される第１の暗号鍵を生成し、共有する第１の鍵交換手
   続き手段とを備え、
   前記第１の鍵交換手続き手段で共有された前記第１の暗号鍵を用いて無線の暗号通信路
   を確立し、前記第２の認証手段による前記第２の認証を行うようにしたことを特徴とする
   送信装置。
6. 前記第２の認証手段により、前記受信装置との間で前記第２の認証が成功した場合に、前
   記送信装置と前記受信装置との間で共通に使用される第２の暗号鍵を生成し、共有する第
   ２の鍵交換手続き手段を更に備えたことを特徴とする請求項５に記載の送信装置。
7. 前記無線の暗号通信路を用いて、前記受信装置へ前記コンテンツデータを転送することを
   特徴とする請求項５または６に記載の送信装置。
8. 前記無線の暗号通信路を用いて、前記受信装置へ前記第２の暗号鍵で暗号化された前記コ
   ンテンツデータを送信することを特徴とする請求項５または６に記載の送信装置。
9. 送信装置からコンテンツデータを無線の通信路を介して受信する受信装置において、
   前記送信装置が通信することを許可された機器であるか否かを判断するための第１の認
   証を行う第１の認証手段と、
   前記送信装置が著作権保護機能を備えた機器であるか否かを判断するための第２の認証
   を行う第２の認証手段と、
   前記第１の認証手段により、前記送信装置との間で前記第１の認証が成功した場合に、
   前記送信装置との間で共通に使用される第１の暗号鍵を生成し、共有する第１の鍵交換手
   続き手段とを備え、
   前記第１の鍵交換手続き手段で共有された前記第１の暗号鍵を用いて無線の暗号通信路
   を確立し、前記第２の認証手段による前記第２の認証を行うようにしたことを特徴とする
   受信装置。
10. 前記第２の認証手段により、前記送信装置との間で前記第２の認証が成功した場合に、前
    記送信装置と前記受信装置との間で共通に使用される第２の暗号鍵を生成し、共有する第
    ２の鍵交換手続き手段を更に備えたことを特徴とする請求項９に記載の受信装置。
11. 前記無線の暗号通信路を用いて、前記送信装置から前記コンテンツデータを受信すること
    を特徴とする請求項９または１０に記載の受信装置。
12. 前記無線の暗号通信路を用いて、前記送信装置から前記第２の暗号鍵で暗号化された前記
    コンテンツデータを受信することを特徴とする請求項９または１０に記載の送信装置。

Images