JP2000332748A - データ処理システムおよびその方法 - Google Patents
データ処理システムおよびその方法Info
- Publication number
- JP2000332748A JP2000332748A JP2000076392A JP2000076392A JP2000332748A JP 2000332748 A JP2000332748 A JP 2000332748A JP 2000076392 A JP2000076392 A JP 2000076392A JP 2000076392 A JP2000076392 A JP 2000076392A JP 2000332748 A JP2000332748 A JP 2000332748A
- Authority
- JP
- Japan
- Prior art keywords
- data
- data processing
- processing device
- key
- key data
- 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.)
- Pending
Links
Landscapes
- Telephonic Communication Services (AREA)
Abstract
ことができるデータ処理システムを提供する。 【解決手段】 記憶ユニット61はマスタ鍵データMK
0 〜MK31を記憶し、記憶ユニット51は認証鍵データ
IK0 〜IK31を記憶し、乱数発生ユニット60で発生
したRj を用いて、相互認証ユニット53,63におい
て、対応する一のマスタ鍵データおよび認証鍵データを
それぞれ選択する。相互認証ユニット63は、選択した
マスタ鍵データから認証鍵データを生成し、相互認証ユ
ニット53との間で相互認証を行う際の共通鍵として用
いる。
Description
相互間で相互認証を行うデータ処理システムおよびその
方法に関する。
止するために、第1のデータ処理装置から第2のデータ
処理装置へのオーディオデータなどのデータの出力を、
相互認証処理を行って相互に正当な相手であると認めた
場合にのみ行うことがある。
あるが、その一つに共通鍵方式がある。共通鍵方式で
は、第1のデータ処理装置および第2のデータ処理装置
の双方が1個の共通鍵を持ち、例えば、一方で発生した
乱数を他方に通知し、双方で当該乱数および共通鍵を使
用した演算を行い、当該演算結果を他方に出力する。そ
して、第1のデータ処理装置および第2のデータ処理装
置のそれぞれにおいて、自らが得た演算結果と、他方か
ら入力した演算結果とを比較して一致していれば、正当
な相手であると認証する。このような共通鍵方式では、
当事者以外の者に共通鍵を秘密にする必要がある。
たように、1個の共通鍵を用いた場合には、当該共通鍵
を不正者が取得してしまうと、当該不正者による不正な
相互認証処理が略確実に成功してしまうという問題があ
る。
みてなされ、共通鍵を用いた場合の相互認証能力を高め
ることができるデータ処理システムおよびその方法を提
供することを目的とする。
ために、請求項1の発明は、第1のデータ処理装置と第
2のデータ処理装置との間で相互認証を行うデータ処理
システムにおいて、第1のデータ処理装置は、複数の異
なる第1の鍵データを記憶する第1の記憶手段と、複数
の第1の鍵データのうち一の第1の鍵データを選択し、
当該選択した第1の鍵データを用いて、第2のデータ処
理装置との間で相互認証を行う第1の相互認証処理手段
とを有し、第2のデータ処理装置は、複数の異なる第2
の鍵データを記憶する第2の記憶手段と、複数の第2の
鍵データのうち、第1の相互認証処理手段が選択した第
1の鍵データに対応した第2の鍵データを選択し、当該
選択した第2の鍵データを用いて、第1のデータ処理装
置との間で相互認証を行う第2の相互認証処理手段とを
有するデータ処理システムである。
と第2のデータ処理装置との間で相互認証を行うデータ
処理方法において、第1のデータ処理装置において、複
数の異なる第1の鍵データのうち一の第1の鍵データを
選択し、当該選択した第1の鍵データを用いて、第2の
データ処理装置との間で相互認証を行い、第2のデータ
処理装置において、複数の異なる第2の鍵データのう
ち、選択した第1の鍵データに対応した第2の鍵データ
を選択し、当該選択した第2の鍵データを用いて、第1
のデータ処理装置との間で相互認証を行う データ処理
方法である。
るオーディオシステムについて説明する。図1は、一実
施形態のオーディオシステム1のシステム構成図、図2
は図1に示す携帯用記憶装置3および携帯用プレーヤ4
の内部構成図である。図1に示すように、オーディオシ
ステム1は、例えば、コンピュータ2、携帯用記憶装置
3、携帯用プレーヤ4、CD−ROMドライブ6および
CDプレーヤ7を有する。
例えば、EMD(Electronic Music Distribution: 電子
音楽配信)などのサービスを提供する図示しないサービ
スプロバイダのホストコンピュータから、ネットワーク
5を介してオーディオデータ(トラックデータ)を受信
し、当該受信したオーディオデータを必要に応じて復号
して、携帯用プレーヤ4に出力する。また、コンピュー
タ2は、コンテンツデータを受信するに当たって、必要
に応じて、サービスプロバイダのホストコンピュータと
の間で認証処理および課金処理などを行う。また、コン
ピュータ2は、例えば、CD−ROMドライブ6から入
力したオーディオデータを携帯用プレーヤ4に出力す
る。
在とされ、例えば、メモリスティック(Memory Stick:商
標)であり、フラッシュメモリなどの書き換え可能な半
導体メモリを内蔵している。本明細書において、メモリ
カードの用語が使用されることもあるが、メモリカード
は、携帯用記憶装置を指すものとして使用している。図
2に示すように、携帯用記憶装置3は、例えば、主制御
モジュール31、通信インターフェイス32、制御モジ
ュール33、フラッシュメモリ34およびフラッシュメ
モリ管理モジュール35を有する。
に、制御モジュール33は、例えば、乱数発生ユニット
50、記憶ユニット51、鍵生成/演算ユニット52、
相互認証ユニット53、暗号化/復号ユニット54およ
び制御ユニット55を有する。制御モジュール33は、
シングルチップの暗号処理専用の集積回路であり、多層
構造を有し、内部のメモリセルはアルミニウム層などの
ダミー層に挟まれている。また、制御モジュール33
は、動作電圧または動作周波数の幅が狭く、外部から不
正にデータを読み出せないように耐タンパー性を有して
いる。乱数発生ユニット50は、乱数発生指示を受ける
と、64ビット(8バイト)の乱数を発生する。
M(Electrically Erasable Programmable Read Only Me
mory) などの不揮発性メモリであり、認証処理に必要な
鍵データなどの種々のデータを記憶している。図3は、
記憶ユニット51に記憶されているデータを説明するた
めの図である。図3に示すように、記憶ユニット51
は、認証鍵データIK0 〜IK31、装置識別データID
m および記憶用鍵データSKm を記憶している。
憶装置3が携帯用プレーヤ4との間で相互認証を行う際
に用いられる鍵データであり、後述するように相互認証
を行う度に認証鍵データIK0 〜IK31のうち一の認証
鍵データがランダムに選択される。なお、認証鍵データ
IK0 〜IK31および記憶用鍵データSKm は、携帯用
記憶装置3の外部から読めないようになっている。装置
識別データIDm は、携帯用記憶装置3に対してユニー
クに付けられた識別データであり、後述するように、携
帯用記憶装置3が携帯用プレーヤ4との間で相互認証を
行う際に読み出されて携帯用プレーヤ4に出力される。
記憶用鍵データSKm は、後述するように、コンテンツ
鍵データCKを暗号化してフラッシュメモリ34に記憶
する際に用いられる。
SO/IEC9797のMAC(Message Authenticatio
n Code) 演算などの種々の演算を行って鍵データを生成
する。このとき、MAC演算には、例えば、"Block cip
her Algorithm"としてFIPSPUB46−2に規定さ
れるDES(Data Encryption Standard)が用いられる。
MAC演算は、任意の長さのデータを固定の長さに圧縮
する一方向性ハッシュ関数演算であり、関数値が秘密鍵
に依存して定まる。
4からオーディオデータを入力してフラッシュメモリ3
4に書き込む動作を行うのに先立って、携帯用プレーヤ
4との間で相互認証処理を行う。また、相互認証ユニッ
ト53は、フラッシュメモリ34からオーディオデータ
を読み出して携帯用プレーヤ4に出力する動作を行うの
に先立って、携帯用プレーヤ4との間で相互認証処理を
行う。また、相互認証ユニット53は、相互認証処理に
おいて、前述したMAC演算を行う。当該相互認証処理
では、記憶ユニット51に記憶されているデータが用い
られる。
DEA、MISTYなどのブロック暗号アルゴリズムで
の暗号化を行う。使用するモードは、FIPS PUB
81”DES MODES OF OPERATIO
N”に規定されているようなECB(Electronic Code B
ook)モードおよびCBC(Cipher Block Chaining) モー
ドである。また、暗号化/復号ユニット54は、DE
S、IDEA、MISTYなどのブロック復号アルゴリ
ズムでの復号を行う。使用するモードは、上記ECBモ
ードおよびCBCモードである。当該ECBモードおよ
びCBCモードのブロック暗号化/復号では、指定され
た鍵データを用いて指定されたデータを暗号化/復号す
る。制御ユニット55は、乱数発生ユニット50、記憶
ユニット51、鍵生成/演算ユニット52、相互認証ユ
ニット53および暗号化/復号ユニット54の処理を統
括して制御する。
リ34は、例えば、32Mバイトの記憶容量を有する。
フラッシュメモリ34には、相互認証ユニット53によ
る相互認証処理によって正当な相手であると認められた
ときに、携帯用プレーヤ4から入力したオーディオデー
タが書き込まれる。また、フラッシュメモリ34から
は、相互認証ユニット53による相互認証処理によって
正当な相手であると認められたときに、オーディオデー
タが読み出されて携帯用プレーヤ4に出力される。
データおよびそのフォーマットについて説明する。図4
は、フラッシュメモリ34に記憶されるデータを説明す
るための図である。図4に示すように、フラッシュメモ
リ34には、例えば、再生管理ファイル100、トラッ
クデータファイル1010 ,1011 ,1012 ,10
13 が記憶されている。ここで、再生管理ファイル10
0はトラックデータファイル1010 〜1013 の再生
を管理する管理データを有し、トラックデータファイル
1010 〜1013 はそれぞれ対応するトラックデータ
(オーディオデータ)を有している。なお、本実施形態
では、トラックデータは、例えば、1曲分のオーディオ
データを意味する。
図6が一つ(1曲)のATRAC3データファイルの構
成を示す。再生管理ファイルは、16KB固定長のファ
イルである。ATRAC3データファイルは、曲単位で
もって、先頭の属性ヘッダと、それに続く実際の暗号化
された音楽データとからなる。属性ヘッダも16KB固
定長とされ、再生管理ファイルと類似した構成を有す
る。
ードのメモリカードの名前NM1−S、2バイトコード
のメモリカードの名前NM2−S、曲順の再生テーブル
TRKTBL、メモリカード全体の付加情報INF−S
とからなる。データファイルの先頭の属性ヘッダは、ヘ
ッダ、1バイトコードの曲名NM1、2バイトコードの
曲名NM2、トラックのキー情報等のトラック情報TR
KINF、パーツ情報PRTINFと、トラックの付加
情報INFとからなる。ヘッダには、総パーツ数、名前
の属性、付加情報のサイズの情報等が含まれる。
ータが続く。音楽データは、16KBのブロック毎に区
切られ、各ブロックの先頭にヘッダが付加されている。
ヘッダには、暗号を復号するための初期値が含まれる。
なお、暗号化の処理を受けるのは、ATRAC3データ
ファイル中の音楽データのみであって、それ以外の再生
管理ファイル、ヘッダ等のデータは、暗号化されない。
より詳細なデータ構成を示し、図8A、図8Bは、再生
管理ファイルPBLISTを構成するヘッダとそれ以外
の部分をそれぞれ示す。再生管理ファイルPBLIST
は、1クラスタ(1ブロック=16KB)のサイズであ
る。ヘッダ(図8A)が32バイトである。ヘッダ以外
の部分(図8B)がメモリカード全体に対する名前NM
1−S(256バイト)、名前NM2−S(512バイ
ト)、CONTENTS KEY、MAC、S−YMD
hmsと、再生順番を管理するテーブルTRKTBL
(800バイト)と、メモリカード全体に対する付加情
報INF−S(14720バイト)であり、最後にヘッ
ダ中の情報の一部が再度記録される。これらの異なる種
類のデータ群のそれぞれの先頭は、再生管理ファイル内
で所定の位置となるように規定されている。
よび(0x0010)で表される先頭から32バイト
(図8A)がヘッダである。なお、ファイル中で先頭か
ら16バイト単位で区切られた単位をスロットと称す
る。ファイルの第1および第2のスロットに配されるヘ
ッダには、下記の意味、機能、値を持つデータが先頭か
ら順に配される。なお、Reservedと表記されて
いるデータは、未定義のデータを表している。通常ヌル
(0x00)が書かれるが、何が書かれていてもRes
ervedのデータが無視される。将来のバージョンで
は、変更がありうる。また、この部分への書き込みは禁
止する。Optionと書かれた部分も使用しない場合
は、全てReservedと同じ扱いとされる。
めの値 値:固定値=”TL=0”(例えば0x544C2D3
0) MCode(2バイト) 意味:MAKER CODE 機能:記録した機器の、メーカー、モデルを識別するコ
ード 値:上位10ビット(メーカーコード) 下位6ビット
(機種コード) REVISION(4バイト) 意味:PBLISTの書き換え回数 機能:再生管理ファイルを書き換える度にインクリメン
ト 値:0より始まり+1づつ増加する S−YMDhms(4バイト)(Option) 意味:信頼できる時計を持つ機器で記録した年・月・日
・時・分・秒 機能:最終記録日時を識別するための値 値:25〜31ビット 年 0〜99(1980〜20
79) 21〜24ビット 月 0〜12 16〜20ビット 日 0〜31 11〜15ビット 時 0〜23 05〜10ビット 分 0〜59 00〜04ビット 秒 0〜29(2秒単位)。
(1バイト)の属性を表す 機能:使用する文字コードと言語コードを各1バイトで
表す 値:文字コード(C)は上位1バイトで下記のように文
字を区別する 00: 文字コードは設定しない。単なる2進数として扱う
こと 01: ASCII 02:ASCII+KANA 03:modifided8859-1 81:MS-JIS 82:KS C 5601-1989 83:GB2312-80 90:S-J
IS(for Voice) 。
ようにEBU Tech 3258 規定に準じて言語を区別する 00: 設定しない 08:German 09:English 0A:Spanish 0F:French 15:Italian 1D:Dutch 65:Korean 69:Japanese 75:Chinese データが無い場合オールゼロとすること。
(2バイト)の属性を表す 機能:使用する文字コードと言語コードを各1バイトで
表す 値:上述したSN1C+Lと同一 SINFSIZE(2バイト) 意味:INF−S領域に書かれるメモリカード全体に関
する付加情報の全てを合計したサイズを表す 機能:データサイズを16バイト単位の大きさで記述、
無い場合は必ずオールゼロとすること 値:サイズは0x0001から0x39C(924) T−TRK(2バイト) 意味:TOTAL TRACK NUMBER 機能:総トラック数 値:1から0x0190(最大400トラック)、デー
タが無い場合はオールゼロとすること VerNo(2バイト) 意味:フォーマットのバージョン番号 機能:上位がメジャーバージョン番号、下位がマイナー
バージョン番号 値:例 0x0100(Ver1.0) 0x0203(Ver2.3)。
タ(図8B)について以下に説明する。
タ(最大で256) 名前データの終了は、必ず終端コード(0x00)を書
き込むこと サイズはこの終端コードから計算すること、データの無
い場合は少なくとも先頭(0x0020)からヌル(0
x00)を1バイト以上記録すること 値:各種文字コード NM2−S 意味:メモリカード全体に関する2バイトの名前 機能:2バイトの文字コードで表した可変長の名前デー
タ(最大で512) 名前データの終了は、必ず終端コード(0x00)を書
き込むこと サイズはこの終端コードから計算すること、データの無
い場合は少なくとも先頭(0x0120)からヌル(0
x00)を2バイト以上記録すること 値:各種文字コード。
から保存される。ここでは、1曲目に付けられるCON
TENTS KEYと同じ値 機能:S−YMDhmsのMACの計算に必要となる鍵
となる 値:0から0xFFFFFFFFFFFFFFFFまで MAC 意味:著作権情報改ざんチェック値 機能:S−YMDhmsの内容とCONTENTS K
EYから作成される値 値:0から0xFFFFFFFFFFFFFFFFま
で。
(シーケンス)番号 機能:TRKINFの中のFNoを記述する 値:1から400(0x190) トラックが存在しない時はオールゼロとすること INF−S 意味:メモリカード全体に関する付加情報データ(例え
ば写真、歌詞、解説等の情報) 機能:ヘッダを伴った可変長の付加情報データ 複数の異なる付加情報が並べられることがある。それぞ
れにIDとデータサイズが付けられている。個々のヘッ
ダを含む付加情報データは最小16バイト以上で4バイ
トの整数倍の単位で構成される。その詳細については、
後述する 値:付加情報データ構成を参照 S−YMDhms(4バイト)(Option) 意味:信頼できる時計を持つ機器で記録した年・月・日
・時・分・秒 機能:最終記録日時を識別するための値、EMDの時は
必須 値:25〜31ビット 年 0〜99(1980〜20
79) 21〜24ビット 月 0〜12 16〜20ビット 日 0〜31 11〜15ビット 時 0〜23 05〜10ビット 分 0〜59 00〜04ビット 秒 0〜29(2秒単位)。
て、ヘッダ内のものと同一のBLKID−TL0と、M
Codeと、REVISIONとが書かれる。
ドが記録中に抜かれたり、電源が切れることがあり、復
活した時にこれらの異常の発生を検出することが必要と
される。上述したように、REVISIONをブロック
の先頭と末尾に書き込み、この値を書き換える度に+1
インクリメントするようにしている。若し、ブロックの
途中で異常終了が発生すると、先頭と末尾のREVIS
IONの値が一致せず、異常終了を検出することができ
る。REVISIONが2個存在するので、高い確率で
異常終了を検出することができる。異常終了の検出時に
は、エラーメッセージの表示等の警告が発生する。
に固定値BLKID−TL0を挿入しているので、FA
Tが壊れた場合の修復の目安に固定値を使用できる。す
なわち、各ブロックの先頭の固定値を見れば、ファイル
の種類を判別することが可能である。しかも、この固定
値BLKID−TL0は、ブロックのヘッダおよびブロ
ックの終端部分に二重に記述するので、その信頼性のチ
ェックを行うことができる。なお、再生管理ファイルP
BLISTの同一のものを二重に記録しても良い。
情報管理ファイルと比較して、相当大きなデータ量(例
えば数千のブロックが繋がる場合もある)であり、AT
RAC3データファイルに関しては、後述するように、
ブロック番号BLOCK SERIALが付けられてい
る。但し、ATRAC3データファイルは、通常複数の
ファイルがメモリカード上に存在するので、CONNU
M0でコンテンツの区別を付けた上で、BLOCK S
ERIALを付けないと、重複が発生し、FATが壊れ
た場合のファイルの復旧が困難となる。
が、論理を間違ってファイルとして不都合のあるような
場合に、書き込んだメーカーの機種が特定できるよう
に、メーカーコード(MCode)がブロックの先頭と
末尾に記録されている。
付加情報の先頭に下記のヘッダが書かれる。ヘッダ以降
に可変長のデータが書かれる。
数倍でなければならない。また、最小16バイト以上の
こと。データの終わりより余りがでる場合はヌル(0x
00)で埋めておくこと 値:16から14784(0x39C0) MCode 意味:MAKER CODE 機能:記録した機器の、メーカー、モデルを識別するコ
ード 値:上位10ビット(メーカーコード) 下位6ビット
(機種コード) C+L 意味:先頭から12バイト目からのデータ領域に書かれ
る文字の属性を表す 機能:使用する文字コードと言語コードを各1バイトで
表す 値:前述のSN1C+Lと同じ DATA 意味:個別の付加情報データ 機能:可変長データで表す。実データの先頭は常に12
バイト目より始まり、長さ(サイズ)は最小4バイト以
上、常に4バイトの整数倍でなければならない。データ
の最後から余りがある場合はヌル(0x00)で埋める
こと 値:内容により個別に定義される。
1013 について説明する。図9は、トラックデータフ
ァイル1010 の構成を説明するための図である。図9
に示すように、トラックデータファイル1010 は、1
個のパーツからなり、当該パーツが5個のクラスタCL
(0),CL(1),CL(2),CL(3),CL
(4)で構成されている。当該パーツは、クラスタCL
(0)の先頭から開始し、クラスタCL(4)のサウン
ドユニットSU(4)で終了している。なお、トラック
データファイル1011 〜1013 は、基本的に、図9
に示す構成をしているが、パーツ数、クラスタ数および
クラスタ内に含まれるサウンドユニットSUの数は、図
9に示すものには限定されず、独立して決められてい
る。
1つのATRAC3データファイル(図6参照)で構成
される。ATRAC3データファイルは、ATRAC3
により圧縮されたオーディオデータである。メモリカー
ド40に対しては、クラスタと呼ばれる単位で記録され
る。1クラスタは、例えば16KBの容量である。1ク
ラスタに複数のファイルが混じることがない。フラッシ
ュメモリ42を消去する時の最小単位が1ブロックであ
る。音楽データを記録するのに使用するメモリカード4
0の場合、ブロックとクラスタは、同意語であり、且つ
1クラスタ=1セクタと定義されている。
が、編集が行われると、複数のパーツから1曲が構成さ
れることがある。パーツは、録音開始からその停止まで
の連続した時間内で記録されたデータの単位を意味し、
通常は、1トラックが1パーツで構成される。曲内のパ
ーツのつながりは、各曲の属性ヘッダ内のパーツ情報P
RTINFで管理する。すなわち、パーツサイズは、P
RTINFの中のパーツサイズPRTSIZEという4
バイトのデータで表す。パーツサイズPRTSIZEの
先頭の2バイトがパーツが持つクラスタの総数を示し、
続く各1バイトが先頭および末尾のクラスタ内の開始サ
ウンドユニット(SUと略記する)の位置、終了SUの
位置を示す。このようなパーツの記述方法を持つことに
よって、音楽データを編集する際に通常、必要とされる
大量の音楽データの移動をなくすことが可能となる。ブ
ロック単位の編集に限定すれば、同様に音楽データの移
動を回避できるが、ブロック単位は、SU単位に比して
編集単位が大きすぎる。
TRAC3でオーディオデータを圧縮する時の最小のデ
ータ単位である。44.1kHzのサンプリング周波数で
得られた1024サンプル分(1024×16ビット×
2チャンネル)のオーディオデータを約1/10に圧縮
した数百バイトのデータがSUである。1SUは、時間
に換算して約23m秒になる。通常は、数千に及ぶSU
によって1つのパーツが構成される。1クラスタが42
個のSUで構成される場合、1クラスタで約1秒の音を
表すことができる。1つのトラックを構成するパーツの
数は、付加情報サイズに影響される。パーツ数は、1ブ
ロックの中からヘッダや曲名、付加情報データ等を除い
た数で決まるために、付加情報が全く無い状態が最大数
(645個)のパーツを使用できる条件となる。
384バイト)の場合のATRAC3データファイルA
3Dnnnnのデータ配列を示す。図10には、データ
ファイルの属性ヘッダ(1ブロック)と、音楽データフ
ァイル(1ブロック)とが示されている。図10では、
この2ブロック(16×2=32Kバイト)の各スロッ
トの先頭のバイト(0x0000〜0x7FF0)が示
されている。図11に分離して示すように、属性ヘッダ
の先頭から32バイトがヘッダであり、256バイトが
曲名領域NM1(256バイト)であり、512バイト
が曲名領域NM2(512バイト)である。属性ヘッダ
のヘッダには、下記のデータが書かれる。
識別するための値 値:固定値=”HD=0”(例えば0x48442D3
0) MCode(2バイト) 意味:MAKER CODE 機能:記録した機器の、メーカー、モデルを識別するコ
ード 値:上位10ビット(メーカーコード) 下位6ビット
(機種コード) BLOCK SERIAL(4バイト) 意味:トラック毎に付けられた連続番号 機能:ブロックの先頭は0から始まり次のブロックは+
1づつインクリメント編集されても値を変化させない 値:0より始まり0xFFFFFFFFまで。
1バイトで表す 値:SN1C+Lと同一 N2C+L(2バイト) 意味:トラック(曲名)データ(NM2)の属性を表す 機能:NM2に使用される文字コードと言語コードを各
1バイトで表す 値:SN1C+Lと同一 INFSIZE(2バイト) 意味:トラックに関する付加情報の全てを合計したサイ
ズを表す 機能:データサイズを16バイト単位の大きさで記述、
無い場合は必ずオールゼロとすること 値:サイズは0x0000から0x3C6(966) T−PRT(2バイト) 意味:トータルパーツ数 機能:トラックを構成するパーツ数を表す。通常は1 値:1から0x285(645dec ) T−SU(4バイト) 意味:トータルSU数 機能:1トラック中の実際の総SU数を表す。曲の演奏
時間に相当する 値:0x01から0x001FFFFF INX(2バイト)(Option) 意味:INDEX の相対場所 機能:曲のさびの部分(特徴的な部分)の先頭を示すポ
インタ。曲の先頭からの位置をSUの個数を1/4した
数で指定する。これは、通常のSUの4倍の長さの時間
(約93m秒)に相当する 値:0から0xFFFF(最大、約6084秒) XT(2バイト)(Option) 意味:INDEX の再生時間 機能:INX-nnnで指定された先頭から再生すべき時間
のSUの個数を1/4した数で指定する。これは、通常
のSUの4倍の長さの時間(約93m秒)に相当する 値:0x0000:無設定 0x01から0xFFF
E(最大6084秒) 0xFFFF:曲の終わりまで。
説明する。
大で256) 名前データの終了は、必ず終端コード(0x00)を書
き込むこと サイズはこの終端コードから計算すること、データの無
い場合は少なくとも先頭(0x0020)からヌル(0
x00)を1バイト以上記録すること 値:各種文字コード NM2 意味:曲名を表す文字列 機能:2バイトの文字コードで表した可変長の名前デー
タ(最大で512) 名前データの終了は、必ず終端コード(0x00)を書
き込むこと サイズはこの終端コードから計算すること、データの無
い場合は少なくとも先頭(0x0120)からヌル(0
x00)を2バイト以上記録すること 値:各種文字コード。
始まる、80バイトのデータをトラック情報領域TRK
INFと呼び、主としてセキュリティ関係、コピー制御
関係の情報を一括して管理する。図12にTRKINF
の部分を示す。TRKINF内のデータについて、配置
順序に従って以下に説明する。
ティブロックで保護されてから保存される 機能:曲を再生する時、まず必要となる最初の鍵とな
る。MAC計算時に使用される 値:0から0xFFFFFFFFFFFFFFFFまで MAC(8バイト) 意味:著作権情報改ざんチェック値 機能:コンテンツ累積番号を含む複数のTRKINFの
内容と隠しシーケンス番号から作成される値 隠しシーケンス番号とは、メモリカードの隠し領域に記
録されているシーケンス番号のことである。著作権対応
でないレコーダは、隠し領域を読むことができない。ま
た、著作権対応の専用のレコーダ、またはメモリカード
を読むことを可能とするアプリケーションを搭載したパ
ーソナルコンピュータは、隠し領域をアクセスすること
ができる。
信号を0、メイン信号(L+R)のみの特別なJoin
tモードをモノラルとして規定する。bit2,1の情
報は通常の再生機は無視しても構わない。
フの情報を形成し、ビット1は、再生SKIPか、通常
再生かの情報を形成し、ビット2は、データ区分、例え
ばオーディオデータか、FAX等の他のデータかの情報
を形成する。ビット3は、未定義である。ビット4、
5、6を組み合わせることによって、図示のように、A
TRAC3のモード情報が規定される。すなわち、N
は、この3ビットで表されるモードの値であり、モノ
(N=0,1),LP(N=2),SP(N=4),E
X(N=5),HQ(N=7)の5種類のモードについ
て、記録時間(64MBのメモリカードの場合)、デー
タ転送レート、1ブロック内のSU数がそれぞれ示され
ている。1SUのバイト数は、(モノ:136バイト、
LP:192バイト、SP:304バイト、EX:38
4バイト、HQ:512バイト)である。さらに、ビッ
ト7によって、ATRAC3のモード(0:Dual 1:
Joint )が示される。
用し、SPモードの場合について説明する。64MBの
メモリカードには、3968ブロックがある。SPモー
ドでは、1SUが304バイトであるので、1ブロック
に53SUが存在する。1SUは、(1024/441
00)秒に相当する。従って、1ブロックは、 (1024/44100)×53×(3968−16)
=4863秒=81分 転送レートは、 (44100/1024)×304×8=104737
bps となる。
キュリティバージョン(ビット5〜ビット0) 機能:このトラックに関して制限事項があることを表す 値:ビット7: 0=制限なし 1=制限有り ビット6: 0=期限内 1=期限切れ ビット5〜ビット0:セキュリティバージョン0(0以
外であれば再生禁止とする) FNo(2バイト) 意味:ファイル番号 機能:最初に記録された時のトラック番号、且つこの値
は、メモリカード内の隠し領域に記録されたMAC計算
用の値の位置を特定する 値:1から0x190(400) MG(D)SERIAL−nnn(16バイト) 意味:記録機器のセキュリティブロック(セキュリティ
IC20)のシリアル番号 機能:記録機器ごとに全て異なる固有の値 値:0から0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF CONNUM(4バイト) 意味:コンテンツ累積番号 機能:曲毎に累積されていく固有の値で記録機器のセキ
ュリティブロックによって管理される。2の32乗、4
2億曲分用意されており、記録した曲の識別に使用する 値:0から0xFFFFFFFF。
on) 意味:再生制限付きのトラックの再生開始日時 機能:EMDで指定する再生開始を許可する日時 値:上述した日時の表記と同じ YMDhms−E(4バイト)(Option) 意味:再生制限付きのトラックの再生終了日時 機能:EMDで指定する再生許可を終了する日時 値:上述した日時の表記と同じ MT(1バイト)(Option) 意味:再生許可回数の最大値 機能:EMDで指定される最大の再生回数 値:1から0xFF 未使用の時は、0x00 LTのbit7の値が0の場合はMTの値は00とする
こと CT(1バイト)(Option) 意味:再生回数 機能:再生許可された回数の内で、実際に再生できる回
数。再生の度にデクリメントする 値:0x00〜0xFF 未使用の時は、0x00であ
る LTのbit7が1でCTの値が00の場合は再生を禁
止すること。
ピー制御情報を表し、ビット4および5によって高速デ
ィジタルコピーに関するコピー制御情報を表し、ビット
2および3によってセキュリティブロック認証レベルを
表す。ビット0および1は、未定義 CCの例:(bit7,6)11:無制限のコピーを許
可、01:コピー禁止、00:1回のコピーを許可 (bit3,2)00:アナログないしディジタルイン
からの録音、MG認証レベルは0とする CDからのディジタル録音では(bit7,6)は0
0、(bit3,2)は00となる CN(1バイト)(Option) 意味:高速ディジタルコピーHSCMS(High speed Se
rial Copy ManagementSystem)におけるコピー許可回数 機能:コピー1回か、コピーフリーかの区別を拡張し、
回数で指定する。コピー第1世代の場合にのみ有効であ
り、コピーごとに減算する 値:00:コピー禁止、01から0xFE:回数、0x
FF:回数無制限。
続いて、0x0370から始まる24バイトのデータを
パーツ管理用のパーツ情報領域PRTINFと呼び、1
つのトラックを複数のパーツで構成する場合に、時間軸
の順番にPRTINFを並べていく。図15にPRTI
NFの部分を示す。PRTINF内のデータについて、
配置順序に従って以下に説明する。
上位)、開始SU:1バイト(上位)、終了SU:1バ
イト(最下位) 値:クラスタ:1から0x1F40(8000)、開始
SU:0から0xA0(160)、終了SU:0から0
xA0(160)(但し、SUの数え方は、0,1,
2,と0から開始する) PRTKEY(8バイト) 意味:パーツを暗号化するための値 機能:初期値=0、編集時は編集の規則に従うこと 値:0から0xFFFFFFFFFFFFFFFF CONNUM0(4バイト) 意味:最初に作られたコンテンツ累積番号キー 機能:コンテンツをユニークにするためのIDの役割 値:コンテンツ累積番号初期値キーと同じ値とされる。
中には、図10に示すように、付加情報INFが含まれ
る。この付加情報は、開始位置が固定化されていない点
を除いて、再生管理ファイル中の付加情報INF−S
(図7および図8B参照)と同一である。1つまたは複
数のパーツの最後のバイト部分(4バイト単位)の次を
開始位置として付加情報INFのデータが開始する。
異なる付加情報が並べられることがある。それぞれにI
Dとデータサイズが付加されている。個々のヘッダを含
む付加情報データは、最小16バイト以上で4バイトの
整数倍の単位値:再生管理ファイル中の付加情報INF
−Sと同じである。
3データファイルの各ブロックのデータが続く。図16
に示すように、ブロック毎にヘッダが付加される。各ブ
ロックのデータについて以下に説明する。
ための値 値:固定値=”A3D”(例えば0x4133442
0) MCode(2バイト) 意味:MAKER CODE 機能:記録した機器の、メーカー、モデルを識別するコ
ード 値:上位10ビット(メーカーコード) 下位6ビット
(機種コード) CONNUM0(4バイト) 意味:最初に作られたコンテンツ累積番号 機能:コンテンツをユニークにするためのIDの役割、
編集されても値は変化させない 値:コンテンツ累積番号初期値キーと同じ値とされる BLOCK SERIAL(4バイト) 意味:トラック毎に付けられた連続番号 機能:ブロックの先頭は0から始まり次のブロックは+
1づつインクリメント編集されても値を変化させない 値:0より始まり0xFFFFFFFFまで BLOCK−SEED(8バイト) 意味:1ブロックを暗号化するための1つの鍵 機能:ブロックの先頭は、記録機器のセキュリティブロ
ックで乱数を生成、続くブロックは、+1インクリメン
トされた値、この値が失われると、1ブロックに相当す
る約1秒間、音が出せないために、ヘッダとブロック末
尾に同じものが二重に書かれる。編集されても値を変化
させない 値:初期は8バイトの乱数 INITIALIZATION VECTOR(8バイ
ト) 意味:ブロック毎にATRAC3データを暗号化、復号
化する時に必要な初期値 機能:ブロックの先頭は0から始まり、次のブロックは
最後のSUの最後の暗号化された8バイトの値。デバイ
ドされたブロックの途中からの場合は開始SUの直前の
最後の8バイトを用いる。編集されても値を変化させな
い 値:0から0xFFFFFFFFFFFFFFFF SU−nnn 意味:サウンドユニットのデータ 機能:1024サンプルから圧縮されたデータ、圧縮モ
ードにより出力されるバイト数が異なる。編集されても
値を変化させない(一例として、SPモードの時では、
N=384バイト) 値:ATRAC3のデータ値。
ロックに42SUが書かれる。また、1ブロックの先頭
の2つのスロット(4バイト)がヘッダとされ、最後の
1スロット(2バイト)にBLKID−A3D、MCo
de、CONNUM0、BLOCK SERIALが二
重に書かれる。従って、1ブロックの余りの領域Mバイ
トは、(16,384−384×42−16×3=20
8(バイト)となる。この中に上述したように、8バイ
トのBLOCK SEEDが二重に記録される。
01)は、図2に示す暗号化/復号ユニット64におい
てCBC(Cipher Block Chainning)モードで64ビット
(8バイト)の暗号化ブロックを単位として暗号化して
生成された8バイトの暗号文Ci によって構成される。
本実施形態では、サウンドユニットSUのバイト数(例
えば160バイト)を、暗号化の単位である暗号化ブロ
ックのバイト数(例えば8バイト)の整数倍にしてい
る。すなわち、1サウンドユニットSUは例えば20個
の暗号文Ci からなる。このとき、個々の暗号文Ci は
一のサウンドユニットSU内に位置し、一の暗号文Ci
が複数のサウンドユニットSUに跨がって位置すること
はない。
ているオーディオデータは、後述するように例えば、A
TRAC3方式で圧縮されており、当該圧縮の単位がサ
ウンドユニットSUである。従って、携帯用記憶装置3
から携帯用プレーヤ4にオーディオデータを読み出す場
合には、読み出しの最小単位は当該サウンドユニットS
Uとなる。
34に記憶されている暗号化されたオーディオデータに
アクセスする際に、暗号化ブロックの区切りを意識する
必要がなくなり、当該アクセスに伴う処理負担を軽減で
きる。なお、各クラスタ内に含まれるサウンドユニット
SUの数は、1個以上102個以下の範囲で任意であ
る。また、オーディオデータの圧縮方式は、ATRAC
3などのATRAC方式以外のCODEC方式でもよ
い。
毎に例えば乱数を発生して生成されたデータであり、後
述するように、携帯用プレーヤ4内でブロック毎にブロ
ック鍵データBKを生成する際に用いられる。当該ブロ
ックシードデータBSは、エラー対策としてブロック内
の2箇所に格納されている。なお、各クラスタに含まれ
るサウンドユニットは、暗号化された順でフラッシュメ
モリ34の連続したアドレスに記憶される。また、各サ
ウンドユニット内の暗号化ブロックは、暗号化された順
にフラッシュメモリ34の連続したアドレスに記憶され
る。
フラッシュメモリ管理モジュール35は、フラッシュメ
モリ34へのデータの書き込み、フラッシュメモリ34
からのデータの読み出しなどの制御を行う。
御モジュール41、通信インターフェイス42、制御モ
ジュール43、編集モジュール44、圧縮/伸長モジュ
ール45、スピーカ46、D/A変換器47およびA/
D変換器48を有する。
ル41は、携帯用プレーヤ4の処理を統括的に制御す
る。
に、制御モジュール43は、例えば、乱数発生ユニット
60、記憶ユニット61、鍵生成/鍵演算ユニット6
2、相互認証ユニット63、暗号化/復号ユニット64
および制御ユニット65を有する。制御モジュール43
は、制御モジュール33と同様に、シングルチップの暗
号処理専用の集積回路であり、多層構造を有し、内部の
メモリセルはアルミニウム層などのダミー層に挟まれて
いる。また、制御モジュール43は、動作電圧または動
作周波数の幅が狭く、外部から不正にデータを読み出せ
ないように耐タンパー性を有している。乱数発生ユニッ
ト60は、乱数発生指示を受けると、64ビット(8バ
イト)の乱数を発生する。記憶ユニット61は、認証処
理に必要な種々のデータを記憶している。
いるデータを説明するための図である。図17に示すよ
うに、記憶ユニット61は、マスター鍵データMK0 〜
MK31および装置識別データIDd を記憶している。こ
こで、マスター鍵データMK0 〜MK31と、認証鍵デー
タIK0 〜IK31との間には、前述した携帯用記憶装置
3の装置識別データIDm を用いて、下記式(1)に示
す関係がある。なお、下記式において、f(a,b)
は、例えば、引数a,bから値を導出する関数である。
ータIK0 〜IK31の記憶アドレスは、例えば5ビット
で表現され、それぞれ記憶ユニット51におけるマスタ
ー鍵データMK0 〜MK31と同じ記憶アドレスが割り当
てられている。
ISO/IEC9797のMAC演算方式を用いた演算
などの種々の演算を行って鍵データを生成する。このと
き、"Block cipher Algorithm"としてFIPS PUB
46−2に規定されるDESが用いられる。
ュータ2から入力したオーディオデータを携帯用記憶装
置3に出力する動作を行うのに先立って、携帯用記憶装
置3との間で相互認証処理を行う。また、相互認証ユニ
ット63は、携帯用記憶装置3からオーディオデータを
入力する動作を行うのに先立って、携帯用記憶装置3と
の間で相互認証処理を行う。また、相互認証ユニット6
3は、相互認証処理において、前述したMAC演算を行
う。当該相互認証処理では、記憶ユニット61に記憶さ
れているデータが用いられる。なお、相互認証ユニット
63は、必要に応じて、例えば、コンピュータ2あるい
はネットワーク5上のコンピュータとの間でオーディオ
データの入出力を行う動作に先立って、コンピュータ2
あるいはネットワーク5上のコンピュータとの間で相互
認証処理を行う。
うに、FIPS PUB 81に規定されたECBモー
ドおよびCBCモードを選択的に用いてブロック暗号化
を行う。ここで、暗号化/復号ユニット64は、CBC
モードにおいて、56ビットの鍵データkを用いて、コ
ンピュータ2あるいはCDプレーヤ7から入力したオー
ディオデータ(平文)を、64ビットからなる暗号化ブ
ロックを単位として下記式(2)に基づいて暗号化して
暗号化されたオーディオデータ(暗号文)を生成する。
下記式(2)から分かるように、CBCモードでは、一
つ前の暗号文と次の平文との排他的論理和を暗号化する
ため、同一の平文が入力されても異なる暗号文が出力さ
れ、解読が困難であるという利点がある。
号処理 上記式(2)の演算は、図18で表現される。なお、図
18において、「IV」は、ブロック暗号化初期値(6
4ビット)であり、図2に示す携帯用記憶装置3のフラ
ッシュメモリ34において、図8に示すようにクラスタ
CL内のサウンドユニットSU(0)の直前に記憶され
る。
ヤ7から入力したオーディオデータ(平文)は、ATR
AC(Adaptive TRansform Audio Coder)方式を改良した
ATRAC3方式で圧縮されている。なお、ATRAC
は、MD(Mini Disk:商標)のための符号化圧縮方式で
あり、例えば、288kbit/sで44.1kHzサ
ンプルのステレオ信号が、帯域分割とMDCT(Modifie
d Discrete Cosine Transform)とを併用して符号化され
ている。すなわち、先ず、帯域分割フィルタで1/4,
1/4,1/2の3つの帯域に分割され、それぞれの帯
域の信号がダウンサンプルされ、時間領域の信号として
MDCTで周波数領域に変換され、当該MDCTの係数
が適応ビット配分を行ってスカラ量子化されている。
1のモードのうち、前述したECBモードおよびCBC
モードの復号を選択的に行う。ここで、暗号化/復号ユ
ニット64は、CBCモードにおいて、56ビットの鍵
データkを用いて、暗号文を、64ビットからなる暗号
化ブロックを単位として下記式(3)に基づいて復号し
て平文を生成する。
号処理 上記式(3)の演算は、図19で表現される。なお、図
19において、「IV」は、ブロック暗号化初期値(6
4ビット)であり、図2に示す携帯用記憶装置3のフラ
ッシュメモリ34において図8に示すようにクラスタC
L内のサウンドユニットSU(0)の直前に記憶された
ものが用いられる。
0、記憶ユニット61、鍵生成/鍵演算ユニット62、
相互認証ユニット63および暗号化/復号ユニット64
の処理を統括的に制御する。
4は、例えば、図4に示すように携帯用記憶装置3のフ
ラッシュメモリ34内に記憶されたトラックデータファ
イル1010 〜1013 を、ユーザからの操作指示に基
づいて編集して新たなトラックデータファイルを生成す
る。当該編集には、1個のトラックデータファイルを分
割して2個のトラックデータファイルを生成する分割編
集処理と、2個のトラックデータファイルを結合して1
個のトラックデータファイルを生成する結合編集処理と
がある。なお、当該編集にあたって、再生管理ファイル
100およびトラックデータファイル1010 〜101
3 が書き換えられる。編集モジュール44における編集
処理については後に詳細に説明する。
モジュール45は、例えば、携帯用記憶装置3から入力
した暗号化されたオーディオデータを復号した後に再生
する際に、ATRAC3方式で圧縮されているオーディ
オデータを伸長し、当該伸長したオーディオデータをD
/A変換器47に出力する。また、例えば、CDプレー
ヤ7あるいはコンピュータ2から入力したオーディオデ
ータを、携帯用記憶装置3に記憶する際に、当該オーデ
ィオデータをATRAC3方式で圧縮する。
は、圧縮/伸長モジュール45から入力したデジタル形
式のオーディオデータをアナログ形式のオーディオデー
タに変換してスピーカ46に出力する。
変換器47から入力したオーディオデータに応じた音響
を出力する。
は、例えば、CDプレーヤ7から入力したアナログ形式
のオーディオデータをデジタル形式に変換して圧縮/伸
長モジュール45に出力する。
動作について説明する。
書き込み動作を説明するためのフローチャートである。
用記憶装置3に、書き込み要求信号が出力される。
プレーヤ4との間で、相互認証処理を行う際に用いる認
証鍵データIKj の選択処理が行われる。当該処理につ
いては後述する。
プレーヤ4との間で相互認証処理が行われる。当該処理
については後述する。
理によって携帯用記憶装置3および携帯用プレーヤ4の
双方が相手を正当であると認めた場合には、ステップS
5の処理が行われ、そうでない場合には処理が終了す
る。
帯用プレーヤ4において、セッション鍵データSekが
生成される。当該処理については後述する。
用記憶装置3に、通信インターフェイス32,42を介
して、暗号化したオーディオデータを出力して書き込
む。当該処理については後述する。
ば、携帯用記憶装置3と携帯用プレーヤ4との間で相互
認証が行われ、双方が相手を正当であると認めた場合に
のみ、携帯用プレーヤ4から携帯用記憶装置3に、暗号
化されたオーディオデータが書き込まれる。そのため、
著作権侵害を招くようなオーディオデータの不正な複製
が容易に行われることを回避できる。
に示すステップS2)〕図21は、認証鍵データIKj
の選択処理を説明するための図である。図21に示すよ
うに、図2に示す携帯用プレーヤ4の乱数発生ユニット
60によって64ビットの乱数Rj が生成される。当該
乱数Rj は、携帯用プレーヤ4から携帯用記憶装置3に
出力される。そして、携帯用記憶装置3の相互認証ユニ
ット53によって、64ビットの乱数Rj の下位5ビッ
トを用いて、記憶ユニット51に記憶されている認証鍵
データIK0 〜IK31のうち一の認証鍵データIK
j (jは0≦j≦31を満たす整数)が特定される。
1から読み出された装置識別データIDm が、携帯用記
憶装置3から携帯用プレーヤ4に出力される。
ット63によって、乱数Rj の下位5ビットを用いて、
マスター鍵データMK0 〜MK31のうち一のマスター鍵
データMKj が特定される。
いて、前記特定されたマスター鍵データMKj と、携帯
用記憶装置3から入力した装置識別データIDm とを用
いて、下記式(4)に基づいて、認証鍵データIKj を
生成する。下記式(4)において、f(a,b)は、例
えば、引数a,bから値を導出する任意の関数である。
が、上記式(4)に示す関係を持つ認証鍵データIK0
〜IK31およびマスター鍵データMK0 〜MK31を有し
ている場合には、図21に示す処理によって同じ認証鍵
データIKj が選択される。当該選択された認証鍵デー
タIKj は、後述する相互認証処理を行う際に、秘密鍵
として用いられる。また、このとき、32個の認証鍵デ
ータIKjのうち選択される認証鍵データは、図21に
示す処理を行う毎に乱数Rj に応じてランダムに決定さ
れる。そのため、不正な認証が成功する確率を、一の認
証鍵データを固定して用いる場合の1/32倍にするこ
とができ、不正な認証が行われることを高い確率で回避
できる。
て8個の認証鍵データIKj のうち一の認証鍵データを
選択する場合を例示したが、携帯用記憶装置3および携
帯用プレーヤ4の外部から入力した鍵指定信号に基づい
て選択する認証鍵データを決定してもよい。
の間の相互認証処理(図20に示すステップS3)〕図
22は、携帯用記憶装置3と携帯用プレーヤ4との間の
相互認証処理を説明するための図である。なお、当該相
互認証処理を開始するときには、前述した図21に示す
認証鍵データIKj の選択処理が終了しており、携帯用
プレーヤ4の相互認証ユニット53と携帯用記憶装置3
の相互認証ユニット63は、選択した認証鍵データIK
j 、携帯用記憶装置3の装置識別データIDm を有して
いる。
発生ユニット50において、64ビットの乱数Rmsを生
成し、これを携帯用プレーヤ4に出力する。
発生ユニット60において、64ビットの乱数Rd およ
びSd を生成する。
認証ユニット63において、図20に示すステップS2
で得た認証鍵データIKj および「Rd ‖Rms‖I
Dm 」を用いて、下記式(5)に基づいてMAC演算を
行い、MACA を求める。
トのAの後ろにmビットのBを結合して(n+m)ビッ
トとしたもの)を示す。
MACA ‖j」を携帯用記憶装置3に出力する。
認証ユニット53において、図20に示すステップS2
で得た認証鍵データIKj および「Rd ‖Rms‖I
Dm 」を用いて、下記式(6)に基づいてMAC演算を
行い、MACB を求める。
53において、ステップS14で求めたMACB とステ
ップS13で入力したMACA とを比較し、一致してい
れば、携帯用プレーヤ4が適切な認証鍵データIKj を
有していることが分かるため、携帯用記憶装置3は携帯
用プレーヤ4が正当な相手であると認証する。
認証ユニット53において、図20に示すステップS2
で得た認証鍵データIKj および「Rms‖Rd 」を用い
て、下記式(7)に基づいてMAC演算を行い、MAC
C を求める。
50において、64ビットの乱数Smsを生成する。
用プレーヤ4に、「Sms‖MACC」を出力する。
認証ユニット63において下記式(8)に基づいてMA
C演算を行い、MACd を求める。
63において、ステップS19で求めたMACd とステ
ップS18で入力したMACC とを比較し、一致してい
れば、携帯用記憶装置3が適切な認証鍵データIKj を
有していることが分かるため、携帯用プレーヤ4は携帯
用記憶装置3が正当な相手であると認証する。以上の処
理によって、携帯用記憶装置3と携帯用プレーヤ4との
間の相互認証が行われる。
(図20に示すステップS5)〕図23は、セッション
鍵データSekの生成処理を説明するための図である。
なお、当該セッション鍵データSekの生成処理を開始
するときには、前述した図21に示す認証鍵データIK
j の選択処理および図22に示す相互認証処理が終了し
ており、携帯用記憶装置3および携帯用プレーヤ4の双
方は、選択した認証鍵データIKj および乱数Sd ,S
msを有している。
認証ユニット63は、選択した認証鍵データIKj およ
び「Sd ‖Sms」を用いて、下記式(9)に基づいてM
AC演算を行い、セッション鍵データSekを生成す
る。
53は、選択した認証鍵データIKj および「Sd ‖S
ms」を用いて、下記式(10)に基づいてMAC演算を
行い、セッション鍵データSekを生成する。当該セッ
ション鍵データSekは、正当な相手同士であれば、携
帯用プレーヤ4で生成したセッション鍵データSekと
同じになる。
理(図20に示すステップS6)〕図24は、携帯用プ
レーヤ4から携帯用記憶装置3へのオーディオデータの
書き込み処理を説明するための図である。なお、当該書
き込み処理を開始するときには、前述した図23に示す
セッション鍵データSekの生成処理は終了しており、
携帯用記憶装置3および携帯用プレーヤ4は同じセッシ
ョン鍵データSekを有している。
数発生ユニット60にトラックデータファイル毎に乱数
を発生させ、当該乱数に応じたコンテンツ鍵データCK
を生成する。
号化/復号ユニット64において、ステップS40で生
成したコンテンツ鍵データCKを、セッション鍵データ
Sekを用いて暗号化する。
ップS41で暗号化したコンテンツ鍵データCKを携帯
用記憶装置3に出力する。
テップS42で入力した暗号化されたコンテンツ鍵デー
タCKを、暗号化/復号ユニット54において復号す
る。
号化/復号ユニット54において、ステップS43で復
号したコンテンツ鍵データCKを、記憶ユニット51か
ら読み出した記憶用鍵データSKm を用いて暗号化す
る。
該暗号化されたコンテンツ鍵データCKを携帯用プレー
ヤ4に出力する。
該暗号化されたコンテンツ鍵データCKを、トラックデ
ータファイル100n内のTRKINF内に設定する。
数発生ユニット60にパーツ毎に乱数を発生させ、当該
乱数に応じたパーツ鍵データPKを生成する。また、携
帯用プレーヤ4は、当該生成したパーツ鍵データPK
を、トラックデータファイル101nの管理データPR
TINF内に設定する。
えば、パーツ毎に、鍵生成/演算ユニット62におい
て、下記式(11)に示すように、ステップS47で生
成したパーツ鍵データPKとコンテンツ鍵データCKと
の排他的論理和を演算し、当該演算結果をテンポラリ鍵
データTMKとする。なお、テンポラリ鍵データTMK
の生成は、排他的論理和を用いるものには限定されず、
例えば、パーツ鍵データPKとコンテンツ鍵データCK
とを加算する加算演算やその他の関数演算を用いるよう
にしてもよい。
ト60にブロック毎に乱数を発生させ、当該乱数に応じ
たブロックシードデータBSを生成する。また、携帯用
プレーヤ4は、当該生成したブロックシードデータBS
を、当該ブロック内の図10に示す対応する位置に設定
する。
えば、鍵生成/鍵演算ユニット62において、下記式
(12)に示すように、ステップS46で生成したテン
ポラリ鍵データTMKと、ステップS47で生成したブ
ロックシードデータBSとを用いてMAC演算を行い、
ブロック毎にブロック鍵データBKを生成する。
Hash Algorithm) 、RIPEMD−160などの一方向
性ハッシュ関数(one-way hash function) の入力に秘密
鍵を用いた演算を行ってブロック鍵データBKを生成し
てもよい。
f(x)を計算することは容易であるが、逆にyよりx
を求めることが難しい関数をいう。一方向性ハッシュ関
数については、例えば、"Handbook of Applied Cryptog
raphy,CRC Press"などに詳しく記述されている。
ンピュータ2あるいは携帯用プレーヤ4から入力したオ
ーディオデータを、圧縮/伸長モジュール45におい
て、ATRAC3方式で圧縮する。そして、暗号化/復
号ユニット64において、ステップS50で生成したブ
ロック鍵データBKを用いて、前記圧縮したオーディオ
データをCBCモードで暗号化する。
テップS51で暗号化したオーディオデータに属性ヘッ
ダを付加して、通信インターフェイス32,42を介し
て、携帯用記憶装置3に出力する。
テップS52で入力した暗号化されたオーディオデータ
と属性ヘッダを、フラッシュメモリ34にそのまま書き
込む。以上の処理によって、携帯用プレーヤ4から携帯
用プレーヤ4へのオーディオデータの書き込み処理が終
了する。なお、ここでは、図4のトラックデータファイ
ル1010 〜1013 についてのみ述べたが、携帯用プ
レーヤ4は、図4の再生管理ファイルについても同様に
適宜更新を行う。
読み出し動作を説明するためのフローチャートである。
帯用記憶装置3に、読み出しを要求するトラックデータ
(曲)を特定した読み出し要求信号が出力される。
うに、携帯用記憶装置3と携帯用プレーヤ4との間で相
互認証処理を行う際に用いる認証鍵データIKj の選択
処理が行われる。
うに、携帯用記憶装置3と携帯用プレーヤ4との間で相
互認証処理が行われる。
理によって携帯用記憶装置3および携帯用プレーヤ4の
双方が相手を正当であると認めた場合には、ステップS
5の処理が行われ、そうでない場合には処理が終了す
る。
帯用プレーヤ4において、セッション鍵データSekが
生成される。
データを、通信インターフェイス32,42を介して、
携帯用記憶装置3から携帯用プレーヤ4に読み出す。当
該処理については後述する。
帯用記憶装置3と携帯用プレーヤ4との間で相互認証が
行われ、双方が相手を正当であると認めた場合にのみ、
後述するように、携帯用プレーヤ4において、携帯用記
憶装置3から携帯用プレーヤ4に出力された暗号化され
たコンテンツ鍵データCKを適切なセッション鍵データ
Sekで解読できる。そのため、著作権侵害を招くよう
なオーディオデータの不正な利用が容易に行われること
を回避できる。
タの読み出し処理(図25に示すステップS63)〕図
26は、携帯用記憶装置3から携帯用プレーヤ4へのオ
ーディオデータの読み出し処理を説明するための図であ
る。なお、当該読み出し処理は、前述した図20に示す
書き込み処理の後に行われるため、図4に示すトラック
データファイル1010 〜1013 には、図10に示す
ように、TRINFにコンテンツ鍵データCKが設定さ
れ、パーツ毎にパーツ鍵データPKが設定され、各クラ
スタCL内にはブロックシードデータBSが設定されて
いる。また、ステップS5の処理が終了しているため、
携帯用記憶装置3および携帯用プレーヤ4は、正当な相
手同士であれば、同じセッション鍵データSekを有し
ている。
ラッシュメモリ34に記憶されている図4に示すトラッ
クデータファイル1010 〜1013 のうち読み出し要
求信号で特定されるトラックデータに対応するトラック
データファイルを特定し、当該特定したトラックデータ
ファイルを構成するクラスタ内のオーディオデータを、
サウンドユニットSUを単位として読み出して携帯用プ
レーヤ4に出力する。携帯用記憶装置3は、また、上記
トラックデータファイルの属性ヘッダを読み出して携帯
用プレーヤ4に出力する。
該入力された属性ヘッダのうち、TRINFから暗号化
されたコンテンツ鍵CKを抽出し、携帯用記憶装置3に
出力する。
化/復号ユニット54は、ステップS72で入力された
コンテンツ鍵データCKを、記憶ユニット51に記憶さ
れている記憶用鍵データSKm を用いて復号する。
化/復号ユニット54は、ステップS73で復号したコ
ンテンツ鍵データCKを、図25に示すステップS5で
得られたセッション鍵データSekを用いて暗号化す
る。
テップS74で暗号化したコンテンツ鍵データCKを携
帯用プレーヤ4に出力する。
化/復号ユニット64は、ステップS73で携帯用記憶
装置3から入力したコンテンツ鍵データCKを、セッシ
ョン鍵データSekを用いて復号する。
成/演算ユニット62は、ステップS76で復号された
コンテンツ鍵データCKと、ステップS71で入力され
た属性ヘッダの中のPRTINFに含まれるパーツ鍵デ
ータPKとの排他的論理和を演算し、当該演算結果をテ
ンポラリ鍵データTMKとする。
ニット62において、ステップS76で生成したテンポ
ラリ鍵データTMKと、ステップS71で入力されたト
ラックデータファイルのクラスタ内の図10に示すブロ
ックシードデータBSとを用いて、下記式(14)に示
すMAC演算を行い、当該演算結果をブロック鍵データ
BKとする。ブロック鍵データBKは、ブロック毎に求
められる。
ニット64において、ステップS78で生成したブロッ
ク鍵データBKを用いて、ステップS71で入力したオ
ーディオデータを復号する。このとき、オーディオデー
タの復号は、各ブロック毎に、それそれ個別に求められ
たブロック鍵データBKを用いて行われる。また、復号
は、暗号化の単位である8バイトのブロックを単位とし
て行われる。
縮/伸長モジュール45において、ステップS79で復
号したオーディオデータをATRAC3方式で伸長し、
当該伸長したオーディオデータを、D/A変換器47で
デジタル形式に変換した後に、スピーカ46に出力す
る。このとき、圧縮/伸長モジュール45は、ステップ
S78で復号したオーディオデータを、サウンドユニッ
トSUを単位として伸長する。以上の処理によって、携
帯用記憶装置3から携帯用プレーヤ44へのオーディオ
データの読み出しおよび再生が終了する。
理〕前述したように、携帯用プレーヤ4の編集モジュー
ル44は、1個のトラックデータファイルを分割して2
個のトラックデータファイルを生成する分割編集処理
と、2個のトラックデータファイルを結合して1個のト
ラックデータファイルを生成する結合編集処理とを行
う。
27は、携帯用プレーヤ4の編集モジュール44による
トラックデータファイルの分割編集処理を説明するため
の図である。編集モジュール44は、例えば、図27A
に示す1個のトラックデータファイル(1)を、図27
Bに示すトラックデータファイル(1)と、図27Cに
示すトラックデータファイル(2)とに分割する。この
とき、分割の区切りとなる最小単位はサウンドユニット
SUであり、当該例では、図27Bに示すように、トラ
ックデータファイル(1)のクラスタCL(2)のサウ
ンドユニットSU(3)とSU(4)との間で分割され
ている。
ファイル(1)のクラスタCL(2)は図28Aに示す
ようになり、新たに生成されたトラックデータファイル
(2)のクラスタCL(0)は図28Bに示すようにな
る。このとき、図28Bに示すように、トラックデータ
ファイル(2)のクラスタCL(0)のサウンドユニッ
トSU(0)は分割前のトラックデータファイル(1)
のクラスタ(2)のサウンドユニットSU(4)とな
り、ラックデータファイル(2)のクラスタCL(0)
のサウンドユニットSU(1)は分割前のトラックデー
タファイル(1)のクラスタ(2)のサウンドユニット
SU(5)となる。また、図28Bに示すトラックデー
タファイル(2)のクラスタCL(0)のブロック暗号
化初期値IVには、図27A,Bに示すトラックデータ
ファイル(1)のクラスタCL(2)内のサウンドユニ
ットSU(3)の最後の8バイトが設定される。
タ内において、最初のサウンドユニットSU(0)の直
前にブロック暗号化初期値IVを配置したことで、分割
の際に、分割位置の直前の8バイトをそのままブロック
暗号化初期値IVとして用いれば良く、新たなトラック
データファイルを作成する際の処理を簡単にできる。ま
た、再生時に、サウンドユニットSU(0)と共に、そ
の直前のブロック暗号化初期値IVを読み出せばよいた
め、再生処理も簡単になる。
ファイル(1)のコンテンツ鍵データ、パーツ鍵データ
およびブロック鍵データは、それぞれCK_1、PK_
1およびBK_1である。また、分割後のトラックデー
タファイル(1)のコンテンツ鍵データ、パーツ鍵デー
タおよびブロック鍵データは、それぞれCK_1’、P
K_1’およびBK_1である。また、トラックデータ
ファイル(2)のコンテンツ鍵データ、パーツ鍵データ
およびブロック鍵データは、それぞれCK_2、PK_
2およびBK_1である。
ール44において、新たなトラックデータファイル
(2)のコンテンツ鍵データおよびパーツ鍵データを生
成する方法を説明するための図である。分割により生成
された新たなトラックデータファイル(2)は、トラッ
クデータファイル(1)とは別に新たなコンテンツ鍵デ
ータCK_2を有する。本実施形態では、パーツ鍵デー
タPK_2を以下に示すように算出することで、ブロッ
ク鍵データBK_1を分割前と同じにする。
トラックデータファイルの分割指示を入力したか否かを
判断し、入力したと判断した場合にはステップS91の
処理を実行し、入力していないと判断した場合にはステ
ップS90の処理を繰り返す。
乱数発生ユニット60に乱数を発生させ、当該乱数に応
じたコンテンツ鍵データCK_2を新たに生成する。
化/復号ユニット54において、ステップS91で生成
したコンテンツ鍵データCK_2を、記憶ユニット51
に記憶されている記憶用鍵データSKm を用いて暗号化
する。
当該暗号化されたコンテンツ鍵データCK_2を、当該
トラックデータファイルのTRKINFに書き込む。
トラックデータファイル(2)のパーツ鍵データPK_
2を下記式(15)に基づいて生成する。
前記式(11)に基づいてされるテンポラリ鍵データ
は、トラックデータファイル(1)のテンポラリ鍵デー
タと同じになり、前記式(12)に基づいて生成される
ブロック鍵データも分割前のブロック鍵データBK_1
と同じにできる。そのため、トラックデータファイル
(2)内のサウンドユニットSUを新たなブロック鍵デ
ータを用いて再度暗号化する必要がない。
ステップS94で生成したパーツ鍵データPK_2を、
当該トラックデータファイルPRTINFにそのまま書
き込む。
分割して新たに生成したトラックデータファイル(2)
のコンテンツ鍵データとして、新たなコンテンツ鍵デー
タCK_2を用いた場合でも、上記式(15)に基づい
てパーツ鍵データPK_2を生成することで、テンポラ
リ鍵データを分割前のテンポラリ鍵データと同じにでき
る。その結果、ブロック鍵データも分割前のブロック鍵
データBK_1と同じにでき、トラックデータファイル
(2)内のサウンドユニットSUを新たなブロック鍵デ
ータを用いて再度暗号化する必要がない。また、同様
に、分割後のトラックデータファイル(1)のパーツ鍵
データPK_1’も、ブロック鍵データBK_1を変え
ないように、コンテンツ鍵データCK_1’に応じた決
定される。その結果、分割後のトラックデータファイル
(1)内のサウンドユニットSUを新たなブロック鍵デ
ータを用いて再度暗号化する必要もない。そのため、ト
ラックデータファイルの分割編集に伴い演算量が大幅に
増加することを回避できる。なお、ここでは、図4のト
ラックデータファイルについてのみ述べたが、編集モジ
ュール44は、図4の再生管理ファイル100について
も同様に適宜更新を行う。
処理について説明する。図30は、携帯用プレーヤ4の
編集モジュール44によるトラックデータファイルの結
合編集処理を説明するための図である。図30に示すよ
うに、編集モジュール44は、例えば、図30Aに示す
トラックデータファイル(1)と、図30Bに示すトラ
ックデータファイル(2)とを結合して、図30Cに示
すトラックデータファイル(3)を生成する。
ファイル(1)からなるパーツ(1)と、結合前のトラ
ックデータファイル(2)からなるパーツ(2)とを含
む新たなトラックデータファイル(3)が生成される。
また、トラックデータファイル(3)のコンテンツ鍵デ
ータとして新たなコンテンツ鍵データCK_3が生成さ
れ、パーツ(1)のパーツ鍵データPK_3_1および
パーツ(2)のパーツ鍵データPK_3_2が後述する
ようにして新たに生成される。また、当該トラックデー
タファイル(3)のTRKINFおよびPRTINF
に、新たに生成された鍵データが後述するように設定さ
れる。
IZEが示す開始クラスタおよび終了クラスタとして、
結合前のトラックデータファイル(1)のクラスタCL
(0)およびCL(4)がそれぞれ設定される。また、
パーツ(2)のPRTSIZEが示す開始クラスタおよ
び終了クラスタとして、結合前のトラックデータファイ
ル(2)のクラスタCL(0)およびCL(5)がそれ
ぞれ設定される。
ール44において、新たに生成したトラックデータファ
イル(3)のパーツ(1)および(2)のパーツ鍵デー
タを生成する処理を説明するための図である。なお、本
実施形態では、結合の対象となるトラックデータファイ
ル(1)がコンテンツ鍵データCK_1、パーツ鍵デー
タPK_1およびブロック鍵データBK_1を用いてお
り、トラックデータファイル(2)がコンテンツ鍵デー
タCK_2、パーツ鍵データPK_2およびブロック鍵
データBK_2を用いてる場合を例示して説明する。
新たなコンテンツ鍵データCK_3を得るが、パーツ
(1)および(2)のパーツ鍵データを以下に示すよう
に算出することで、各ブロックのブロック鍵データBK
_1およびBK_2を結合前と同じにできる。
は、トラックデータファイルの結合指示を入力したか否
かを判断し、入力したと判断した場合にはステップS1
01の処理を実行し、入力していないと判断した場合に
はステップS100の処理を繰り返す。
は、乱数発生ユニット60に乱数を発生させ、当該乱数
に応じたコンテンツ鍵データCK_3を新たに生成す
る。
号化/復号ユニット54において、ステップS101で
生成したコンテンツ鍵データCK_3を、記憶ユニット
51に記憶されている記憶用鍵データSKm を用いて暗
号化する。
は、当該暗号化されたコンテンツ鍵データCK_3を当
該トラックデータファイルのTRKINFに書き込む。
は、トラックデータファイル(3)のパーツ(1)のパ
ーツ鍵データPK_3_1を下記式(16)に基づいて
生成する。
ツ(1)のテンポラリ鍵データを結合前のトラックデー
タファイル(1)のテンポラリ鍵データと同じにでき、
その結果、前記式(12)に基づいて生成されるパーツ
(1)のブロック鍵データも結合前のトラックデータフ
ァイル(1)のブロック鍵データBK_1と同じにでき
る。そのため、パーツ(1)のサウンドユニットSUを
新たなブロック鍵データを用いて再度暗号化する必要が
ない。
は、トラックデータファイル(3)のパーツ(2)のパ
ーツ鍵データPK_3_2を下記式(17)に基づいて
生成する。
ツ(2)のテンポラリ鍵データを結合前のトラックデー
タファイル(2)のテンポラリ鍵データと同じにでき、
その結果、前記式(12)に基づいて生成されるパーツ
(2)のブロック鍵データも結合前のトラックデータフ
ァイル(2)のブロック鍵データBK_2と同じにでき
る。そのため、パーツ(2)のサウンドユニットSUを
新たなブロック鍵データを用いて再度暗号化する必要が
ない。
は、ステップS104で生成したパーツ鍵データPK_
3_1をトラックデータファイル(3)のパーツ(1)
のPRTINFにそのまま書き込む。
は、ステップS105で生成したパーツ鍵データPK_
3_2をトラックデータファイル(3)のパーツ(2)
のPRTINFにそのまま書き込む。
結合して新たに生成したトラックデータファイル(3)
のコンテンツ鍵データとして、新たなコンテンツ鍵デー
タCK_3を用いた場合でも、上記式(16)および
(17)に基づいてパーツ鍵データPK_3_1および
PK_3_2を生成することで、各パーツのテンポラリ
鍵データを結合前と同じにできる。その結果、各パーツ
のブロック鍵データも結合前のブロック鍵データBK_
1およびBK_2とそれぞれ同じにでき、パーツ(1)
および(2)内のサウンドユニットSUを新たなブロッ
ク鍵データを用いて再度暗号化する必要がない。そのた
め、トラックデータファイルの結合編集に伴い演算量が
大幅に増加することを回避できる。なお、ここでは、図
4のトラックデータファイルについてのみ述べたが、編
集モジュール44は、図4の再生管理ファイルについて
も同様に適宜更新を行う。
れるものでは無く、この発明の要旨を逸脱しない範囲内
で様々な変形や応用が可能である。例えば、上述した実
施形態では、ATRAC3方式の圧縮の単位であるサウ
ンドユニットSUのバイト数(160バイト)が、CB
Cモードの暗号化の単位である暗号化ブロックのバイト
数(8バイト)の整数倍になる場合を例示したが、この
発明は、例えば、整数倍にならない場合には、サウンド
ユニットSUにデータ長調整用のデータであるパディン
グ(padding) を挿入して調整するようにしてもよい。
装置3と携帯用プレーヤ4との間で相互認証処理を行う
場合に、図22に示すように、先ず始めに携帯用記憶装
置3で生成した乱数Rmsを携帯用プレーヤ4に出力する
場合を例示したが、先ず始めに携帯用プレーヤ4で生成
した乱数を携帯用記憶装置3に出力するようにしてもよ
い。
すように、記憶ユニット51および61に32組の認証
鍵データおよびマスター鍵データを記憶した場合を例示
したが、これらの組の数は2以上であれば任意である。
すように、携帯用プレーヤ4において、マスター鍵デー
タMK0 〜MK31から認証鍵データIK0 〜IK31を生
成する場合を例示したが、携帯用プレーヤ4に、携帯用
記憶装置3と同じように、認証鍵データIK0 〜IK31
を記憶し、乱数Rj に応じた認証鍵データを選択するよ
うにしてもよい。
すように、携帯用記憶装置3および携帯用プレーヤ4に
おいて、携帯用プレーヤ4で生成した乱数Rj を用い
て、認証鍵データIKj およびマスタ−鍵データMKj
を選択する場合を例示したが、携帯用記憶装置3で生成
した乱数を用いてもよいし、携帯用記憶装置3および携
帯用プレーヤ4の双方で発生した乱数を用いてもよい。
すように、携帯用記憶装置3および携帯用プレーヤ4に
おいて乱数Rj に基づいて認証鍵データIKj およびマ
スタ−鍵データMKj を選択する場合を例示したが、こ
の発明は、例えば、携帯用記憶装置3および携帯用プレ
ーヤ4に外部から5ビットの鍵選択指示データを入力
し、当該鍵選択指示データで指示される相互に対応する
認証鍵データIKj およびマスタ−鍵データMKj を、
携帯用記憶装置3および携帯用プレーヤ4で選択しても
よい。
ータとしてオーディオデータを含むデータを例示した
が、この発明は、その他、動画像データ、静止画像デー
タ、文書データおよびプログラムデータなどを含むトラ
ックデータをフラッシュメモリ34に記憶する場合にも
適用できる。
処理システムおよびその方法によれば、共通鍵を用いた
場合の相互認証能力を高めることができる。
システム構成を示すブロック図である。
成を示すブロック図である。
いるデータを説明するための略線図である。
るデータを説明するための略線図である。
略線図である。
線図である。
す略線図である。
成を示す略線図である。
るデータを説明するための略線図である。
す略線図である。
線図である。
線図である。
録音時間等を示す略線図である。
る。
線図である。
を示す略線図である。
いるデータを説明するための略線図である。
BCモードにおける暗号化処理を説明するための略線図
である。
BCモードにおける復号処理を説明するための略線図で
ある。
込み動作を説明するためのフローチャートである。
の選択処理を説明するための略線図である。
互認証処理を説明するためのフローチャートである。
するための略線図である。
ディオデータの書き込み処理を説明するためのフローチ
ャートである。
出し動作を説明するためのフローチャートである。
ディオデータの読み出し処理を説明するためのフローチ
ャートである。
ックデータファイルの分割編集処理を説明するための略
線図である。
タを説明するための略線図である。
分割編集時に、新たなトラックデータファイルのコンテ
ンツ鍵データおよびパーツ鍵データを生成する方法を説
明するためのフローチャートである。
ックデータファイルの結合編集処理を説明するための略
線図である。
て、新たに生成したトラックデータファイル(3)のパ
ーツ(1)および(2)のパーツ鍵データを生成する処
理を説明するための略線図である。
3・・・携帯用記憶装置、4・・・携帯用プレーヤ、5
・・・ネットワーク、33,43・・・制御モジュー
ル、50,60・・・乱数発生ユニット、51,61・
・・記憶ユニット、52,62・・・鍵生成/演算ユニ
ット、53,63・・・相互認証ユニット、54,74
・・・暗号化/復号ユニット、55,65・・・制御ユ
ニット、34・・・フラッシュメモリ、44・・・編集
モジュール、45・・・圧縮/伸長モジュール、46・
・・スピーカ
図6が一つ(1曲)のトラックデータファイル(以下に
おいてATRAC3データファイルの用語がさすものも
トラックデータファイルと同義である)の構成を示す。
再生管理ファイルは、16KB固定長のファイルであ
る。ATRAC3データファイルは、曲単位でもって、
先頭の属性ヘッダと、それに続く実際の暗号化された音
楽データとからなる。属性ヘッダも16KB固定長とさ
れ、再生管理ファイルと類似した構成を有する。
キュリティバージョン(ビット5〜ビット0) 機能:このトラックに関して制限事項があることを表す 値:ビット7: 0=制限なし 1=制限有り ビット6: 0=期限内 1=期限切れ ビット5〜ビット0:セキュリティバージョン0(0以
外であれば再生禁止とする) FNo(2バイト) 意味:ファイル番号 機能:最初に記録された時のトラック番号、且つこの値
は、メモリカード内の隠し領域に記録されたMAC計算
用の値の位置を特定する 値:1から0x190(400) MG(D)SERIAL−nnn(16バイト) 意味:記録機器のセキュリティブロック(制御モジュ−
ル43)のシリアル番号 機能:記録機器ごとに全て異なる固有の値 値:0から0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF CONNUM(4バイト) 意味:コンテンツ累積番号 機能:曲毎に累積されていく固有の値で記録機器のセキ
ュリティブロックによって管理される。2の32乗、4
2億曲分用意されており、記録した曲の識別に使用する 値:0から0xFFFFFFFF。
Claims (16)
- 【請求項1】 第1のデータ処理装置と第2のデータ処
理装置との間で相互認証を行うデータ処理システムにお
いて、 上記第1のデータ処理装置は、 複数の異なる第1の鍵データを記憶する第1の記憶手段
と、 上記複数の第1の鍵データのうち一の第1の鍵データを
選択し、当該選択した第1の鍵データを用いて、上記第
2のデータ処理装置との間で相互認証を行う第1の相互
認証処理手段とを有し、 上記第2のデータ処理装置は、 複数の異なる第2の鍵データを記憶する第2の記憶手段
と、 上記複数の第2の鍵データのうち、上記第1の相互認証
処理手段が上記選択した上記第1の鍵データに対応した
第2の鍵データを選択し、当該選択した第2の鍵データ
を用いて、上記第1のデータ処理装置との間で相互認証
を行う第2の相互認証処理手段とを有するデータ処理シ
ステム。 - 【請求項2】 請求項1において、 上記第1のデータ処理装置および上記第2のデータ処理
装置のうち少なくとも一方で乱数を発生し、当該発生し
た乱数を他方に通知し、 上記第1の相互認証処理手段は、上記乱数に基づいて上
記第1の鍵データの選択を行い、 上記第2の相互認証処理手段は、上記乱数に基づいて上
記第2の鍵データの選択を行うデータ処理システム。 - 【請求項3】 請求項1において、 上記第1のデータ処理装置は、 上記選択した第1の鍵データから、上記第2の相互認証
処理手段で選択した上記第2の鍵データを算出する鍵デ
ータ算出手段をさらに有し、 上記第1の相互認証処理手段は、上記第2の相互認証処
理手段との間で、上記算出した第2の鍵データを共通鍵
として用いて上記相互認証処理を行うデータ処理システ
ム。 - 【請求項4】 請求項1において、 上記第2のデータ処理装置の上記第2の相互認証処理手
段は、 上記第1のデータ処理装置から入力した乱数および上記
選択した第2の鍵データを引数として一方向性ハッシュ
関数演算を行って第1の演算結果を算出し、当該第1の
演算結果を上記第1のデータ処理装置に出力し、 上記第1のデータ処理装置は、 上記乱数を発生して上記第2の相互認証処理手段に出力
する乱数発生手段をさらに有し、 上記第1の相互認証処理手段は、 上記乱数発生手段が発生した乱数および上記算出した第
2の鍵データを引数として上記一方向性ハッシュ関数演
算を行って第2の演算結果を生成し、上記第2のデータ
処理装置から入力した上記第1の演算結果と、上記第2
の演算結果とが一致した場合に、上記第2のデータ処理
装置を正当な相手であると認証するデータ処理システ
ム。 - 【請求項5】 請求項4において、 上記第1のデータ処理装置の上記第1の相互認証処理手
段は、 上記第2のデータ処理装置から入力した乱数および上記
算出した第2の鍵データを引数として上記一方向性ハッ
シュ関数演算を行って第3の演算結果を算出し、当該第
3の演算結果を上記第2のデータ処理装置に出力し、 上記第2のデータ処理装置は、 上記乱数を発生して上記第1の相互認証処理手段に出力
する乱数発生手段をさらに有し、 上記第2の相互認証処理手段は、 上記第2のデータ処理装置の上記乱数発生手段が発生し
た乱数および上記選択した第2の鍵データを引数として
上記一方向性ハッシュ関数演算を行って第4の演算結果
を生成し、上記第1のデータ処理装置から入力した上記
第3の演算結果と、上記第4の演算結果とが一致した場
合に、上記第1のデータ処理装置を正当な相手であると
認証するデータ処理システム。 - 【請求項6】 請求項1において、 上記第1のデータ処理装置および上記第2のデータ処理
装置は、鍵選択データを入力し、 上記第1の相互認証処理手段は、上記鍵選択データに基
づいて、上記複数の第1の鍵データのうち一の第1の鍵
データを選択し、 上記第2の相互認証処理手段は、上記鍵選択データに基
づいて、上記複数の第2の鍵データのうち一の第2の鍵
データを選択するデータ処理システム。 - 【請求項7】 請求項1において、 上記第1のデータ処理装置および上記第2のデータ処理
装置は、 上記第1の相互認証処理手段および上記第2の相互認証
処理手段が相互に正当な相手であると認めたときに、一
方から他方にデータを復号するための鍵データを出力す
るデータ処理システム。 - 【請求項8】 請求項7において、 上記第2のデータ処理装置は、 上記第1のデータ処理装置から入力した暗号化されたデ
ータを記憶する記憶手段をさらに有するデータ処理シス
テム。 - 【請求項9】 第1のデータ処理装置と第2のデータ処
理装置との間で相互認証を行うデータ処理方法におい
て、 上記第1のデータ処理装置において、複数の異なる第1
の鍵データのうち一の第1の鍵データを選択し、当該選
択した第1の鍵データを用いて、上記第2のデータ処理
装置との間で相互認証を行い、 上記第2のデータ処理装置において、複数の異なる第2
の鍵データのうち、上記選択した上記第1の鍵データに
対応した第2の鍵データを選択し、当該選択した第2の
鍵データを用いて、上記第1のデータ処理装置との間で
相互認証を行うデータ処理方法。 - 【請求項10】 請求項9において、 上記第1のデータ処理装置および上記第2のデータ処理
装置のうち少なくとも一方で乱数を発生し、当該発生し
た乱数を他方に通知し、 上記第1のデータ処理装置において、上記乱数に基づい
て上記第1の鍵データの選択を行い、 上記第2のデータ処理装置において、上記乱数に基づい
て上記第2の鍵データの選択を行うデータ処理方法。 - 【請求項11】 請求項9において、 上記第1のデータ処理装置において、上記選択した第1
の鍵データから、上記第2のデータ処理装置が選択した
上記第2の鍵データを算出し、 上記第1のデータ処理装置と上記第2のデータ処理装置
との間で、上記算出した第2の鍵データを共通鍵として
用いて上記相互認証処理を行うデータ処理方法。 - 【請求項12】 請求項9において、 上記第2のデータ処理装置において、上記第1のデータ
処理装置から入力した乱数および上記選択した第2の鍵
データを引数として一方向性ハッシュ関数演算を行って
第1の演算結果を算出し、当該第1の演算結果を上記第
1のデータ処理装置に出力し、 上記第1のデータ処理装置において、上記乱数を発生し
て上記第2のデータ処理装置に出力し、上記乱数および
上記算出した第2の鍵データを引数として上記一方向性
ハッシュ関数演算を行って第2の演算結果を生成し、上
記第2のデータ処理装置から入力した上記第1の演算結
果と、上記第2の演算結果とが一致した場合に、上記第
2のデータ処理装置を正当な相手であると認証するデー
タ処理方法。 - 【請求項13】 請求項12において、 上記第1のデータ処理装置において、上記第2のデータ
処理装置から入力した乱数および上記算出した第2の鍵
データを引数として上記一方向性ハッシュ関数演算を行
って第3の演算結果を算出し、当該第3の演算結果を上
記第2のデータ処理装置に出力し、 上記第2のデータ処理装置において、上記乱数を発生し
て上記第1のデータ処理装置に出力し、当該乱数および
上記選択した第2の鍵データを引数として上記一方向性
ハッシュ関数演算を行って第4の演算結果を生成し、上
記第1のデータ処理装置から入力した上記第3の演算結
果と、上記第4の演算結果とが一致した場合に、上記第
1のデータ処理装置を正当な相手であると認証するデー
タ処理方法。 - 【請求項14】 請求項9において、 上記第1のデータ処理装置および上記第2のデータ処理
装置は、鍵選択データを入力し、 上記第1のデータ処理装置において、上記鍵選択データ
に基づいて、上記複数の第1の鍵データのうち一の第1
の鍵データを選択し、 上記第2のデータ処理装置において、上記鍵選択データ
に基づいて、上記複数の第2の鍵データのうち一の第2
の鍵データを選択するデータ処理方法。 - 【請求項15】 請求項9において、 上記第1のデータ処理装置および上記第2のデータ処理
装置が相互に正当な相手であると認めたときに、一方か
ら他方にデータを復号するための鍵データを出力するデ
ータ処理方法。 - 【請求項16】 請求項15において、 上記第1のデータ処理装置から上記第2のデータ処理装
置に出力した暗号化されたデータを、上記第2のデータ
処理装置の記憶手段に記憶するデータ処理方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2000076392A JP2000332748A (ja) | 1999-03-15 | 2000-03-14 | データ処理システムおよびその方法 |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP11-69151 | 1999-03-15 | ||
JP6915199 | 1999-03-15 | ||
JP2000076392A JP2000332748A (ja) | 1999-03-15 | 2000-03-14 | データ処理システムおよびその方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2000332748A true JP2000332748A (ja) | 2000-11-30 |
Family
ID=26410339
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2000076392A Pending JP2000332748A (ja) | 1999-03-15 | 2000-03-14 | データ処理システムおよびその方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2000332748A (ja) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002281009A (ja) * | 2001-03-15 | 2002-09-27 | Sony Corp | 相互認証システム、相互認証方法、およびメモリ搭載デバイス、メモリアクセス機器、並びにプログラム記憶媒体 |
WO2004028072A1 (ja) * | 2002-09-19 | 2004-04-01 | Sony Corporation | データ処理方法、そのプログラムおよびその装置 |
JPWO2004053699A1 (ja) * | 2002-12-06 | 2006-04-13 | ソニー株式会社 | 記録再生装置、データ処理装置および記録再生処理システム |
US7426277B2 (en) | 2001-02-27 | 2008-09-16 | Sony Corporation | Encryption of information input to portable card terminal using encryption key information associated to portable card terminal identifier |
JP2010124376A (ja) * | 2008-11-21 | 2010-06-03 | Mitsubishi Electric Corp | 認証装置及び暗号処理装置 |
JP2011170530A (ja) * | 2010-02-17 | 2011-09-01 | Tokai Rika Co Ltd | 認証システムの暗号演算式設定装置 |
JP2015023414A (ja) * | 2013-07-18 | 2015-02-02 | 株式会社メガチップス | 情報処理システム |
-
2000
- 2000-03-14 JP JP2000076392A patent/JP2000332748A/ja active Pending
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7426277B2 (en) | 2001-02-27 | 2008-09-16 | Sony Corporation | Encryption of information input to portable card terminal using encryption key information associated to portable card terminal identifier |
JP2002281009A (ja) * | 2001-03-15 | 2002-09-27 | Sony Corp | 相互認証システム、相互認証方法、およびメモリ搭載デバイス、メモリアクセス機器、並びにプログラム記憶媒体 |
WO2004028072A1 (ja) * | 2002-09-19 | 2004-04-01 | Sony Corporation | データ処理方法、そのプログラムおよびその装置 |
US7716477B2 (en) | 2002-09-19 | 2010-05-11 | Sony Corporation | Data processing method, program of the same, and device of the same |
JPWO2004053699A1 (ja) * | 2002-12-06 | 2006-04-13 | ソニー株式会社 | 記録再生装置、データ処理装置および記録再生処理システム |
JP4600042B2 (ja) * | 2002-12-06 | 2010-12-15 | ソニー株式会社 | 記録再生装置およびデータ処理装置 |
JP2010124376A (ja) * | 2008-11-21 | 2010-06-03 | Mitsubishi Electric Corp | 認証装置及び暗号処理装置 |
JP2011170530A (ja) * | 2010-02-17 | 2011-09-01 | Tokai Rika Co Ltd | 認証システムの暗号演算式設定装置 |
JP2015023414A (ja) * | 2013-07-18 | 2015-02-02 | 株式会社メガチップス | 情報処理システム |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6792539B1 (en) | Processing method and apparatus for encrypted data transfer | |
US6799273B1 (en) | Data processing system and method for mutual identification between apparatuses | |
JP4366845B2 (ja) | データ処理装置およびデータ処理方法、並びにプログラム提供媒体 | |
US8607069B2 (en) | Data processing apparatus, data processing method, terminal unit, and transmission method of data processing apparatus | |
JP4660899B2 (ja) | データ処理装置およびデータ処理方法、並びにプログラム提供媒体 | |
KR100712377B1 (ko) | 재생 장치 및 재생 방법 | |
US7155013B2 (en) | Recording apparatus, recording method, reproducing apparatus, and reproducing method | |
US6820203B1 (en) | Security unit for use in memory card | |
US7673153B1 (en) | Data processing method, apparatus and system for encrypted data transfer | |
JP4608749B2 (ja) | データ処理装置、データ処理方法、およびライセンスシステム、並びにプログラム提供媒体 | |
US6601140B1 (en) | Memory unit, data processing unit, and data processing method using memory unit type | |
JP2002108710A (ja) | 情報処理システム、情報処理方法、および情報処理装置、並びにプログラム提供媒体 | |
US6985584B1 (en) | Non-volatile record medium, recording method, and recording apparatus | |
JP3925033B2 (ja) | データ処理装置、記憶装置、データ処理システムおよびその方法 | |
JP4172131B2 (ja) | データ処理装置、データ処理システムおよびその方法 | |
JP2000332748A (ja) | データ処理システムおよびその方法 | |
RU2253146C2 (ru) | Воспроизводящее устройство и способ воспроизведения |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040212 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060516 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060718 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20060808 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061010 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061115 |
|
A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20061120 |
|
A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20070126 |