JP4172131B2 - データ処理装置、データ処理システムおよびその方法 - Google Patents
データ処理装置、データ処理システムおよびその方法 Download PDFInfo
- Publication number
- JP4172131B2 JP4172131B2 JP2000076391A JP2000076391A JP4172131B2 JP 4172131 B2 JP4172131 B2 JP 4172131B2 JP 2000076391 A JP2000076391 A JP 2000076391A JP 2000076391 A JP2000076391 A JP 2000076391A JP 4172131 B2 JP4172131 B2 JP 4172131B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- block
- processing
- encrypted
- encryption
- 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.)
- Expired - Lifetime
Links
Images
Landscapes
- Storage Device Security (AREA)
Description
【０００１】
【発明の属する技術分野】
この発明は、例えば圧縮などの所定の処理ブロックを単位で処理されたデータを所定の暗号化ブロックを単位として暗号化して記憶手段に記憶するデータ処理装置、データ処理手段およびその方法に関する。
【０００２】
【従来の技術】
例えば、著作権侵害となる不正利用を防止するために、オーディオデータなどのデータを所定のデータ長の暗号化ブロックを単位として暗号化して記憶媒体に記憶することがある。この場合に、暗号化しようとするデータは、通常、所定の圧縮処理ブロックを単位として圧縮されていることが多い。
【０００３】
【発明が解決しようとする課題】
ところで、上述したように圧縮されたデータを暗号化して記憶媒体に記録する場合に、圧縮ブロックと暗号化ブロックと通常一致しない。そのため、例えば、圧縮ブロックを単位として記憶媒体からデータを読み出すと暗号化ブロックのうちの一部のブロックのデータが読み出されないことがあり、正確な復号を行えなくなる。このような事態を回避するために、圧縮ブロックおよびおよび暗号化ブロックの双方を考慮して読み出しを行うと、処理が煩雑となる問題がある。
【０００４】
また、記憶媒体に記録したデータを編集する場合などは、例えば圧縮ブロックを単位としてデータの分割および結合などが行われるが、この場合にも、編集後のデータに暗号化ブロックの一部のデータが含まれなくなる可能性が高く、同様に、正確な復号が行えなくなるという問題がある。また、圧縮されていないデータであっても、例えば音楽用のＣＤ(Compact Disc:登録商標 )フォーマットなどのように、所定のブロックを単位として処理が行われる場合にも上述した場合と同様の問題が生じる。
【０００５】
この発明の目的は、上述した従来技術の問題点に鑑みてなされ、例えば圧縮などの所定の処理ブロック単位で処理されたデータを所定の暗号化ブロックを単位として暗号化して記憶媒体に記憶する際に、所定の処理ブロックに基づいた処理と復号処理とを簡単な構成で正確に行うことができるデータ処理装置、データ処理システムおよびその方法を提供することにある。
【０００６】
【課題を解決するための手段】
上述した課題を解決するために、請求項１の発明は、所定のデータ長の暗号化ブロックを単位としてデータを暗号化する暗号化手段と、暗号化ブロックの整数倍のデータ長を持つ処理ブロックを単位としてデータに圧縮処理を行う処理手段と、暗号化したデータを記憶する記憶手段と、一の暗号化ブロックを構成するデータが同じ処理ブロック内に位置するように、暗号化したデータを記憶手段に書き込み、処理ブロックを単位としてデータを記憶手段から読み出す制御手段とを有し、制御手段は、単数または複数の処理ブロックを暗号化された順で記憶手段の連続したアドレスに記憶し、さらに、処理ブロック内の単数または複数の暗号化ブロックを暗号化された順で記憶手段の連続したアドレスに記憶し、クラスタ内で最初に暗号化された処理ブロック内でさらに最初に暗号化された暗号化ブロックが記憶された記憶手段のアドレスの直前のアドレスにブロック暗号化初期値を記憶するデータ処理装置である。
【０００７】
請求項１１の発明は、所定のデータ長の暗号化ブロックを単位としてデータを暗号化し、暗号化ブロックの整数倍のデータ長を持つ処理ブロックを単位としてデータに圧縮処理を行い、一の暗号化ブロックを構成するデータが同じ処理ブロック内に位置するように、暗号化したデータを記憶手段に書き込み、処理ブロックを単位としてデータを記憶手段から読み出し、単数または複数の処理ブロックを暗号化された順で記憶手段の連続したアドレスに記憶し、さらに、処理ブロック内の単数または複数の暗号化ブロックを暗号化された順で記憶手段の連続したアドレスに記憶し、クラスタ内で最初に暗号化された処理ブロック内でさらに最初に暗号化された暗号化ブロックが記憶された記憶手段のアドレスの直前のアドレスにブロック暗号化初期値を記憶するデータ処理方法である。
【０００８】
請求項７の発明は、記憶装置とデータ処理装置との間で相互認証を行いながらデータの入出力を行うデータ処理システムにおいて、記憶装置は、データ処理装置との間で相互認証処理を行う第１の相互認証処理手段と、データを記憶する記憶手段と、相互認証処理によってデータ処理装置が正当な相手であると認めたときに、データ処理装置と記憶手段との間でデータの入出力を行わせる第１の制御手段とを有し、データ処理装置は、記憶装置との間で相互認証処理を行う第２の相互認証処理手段と、所定のデータ長の暗号化ブロックを単位としてデータを暗号化する暗号化手段と、暗号化ブロックの整数倍のデータ長を持つ処理ブロックを単位としてデータに圧縮処理を行う処理手段と、相互認証処理によって、記憶装置が正当な相手であると認めたときに、書き込み処理および読み出し処理の少なくとも一方を行い、書き込み処理において、一の暗号化ブロックを構成するデータが同じ処理ブロック内に位置するように、暗号化したデータを記憶手段に書き込み、読み出し処理において、処理ブロックを単位としてデータを記憶手段から読み出す第２の制御手段とを有し、第２の制御手段は、単数または複数の処理ブロックを暗号化された順で記憶手段の連続したアドレスに記憶し、さらに、処理ブロック内の単数または複数の暗号化ブロックを暗号化された順で記憶手段の連続したアドレスに記憶し、クラスタ内で最初に暗号化された処理ブロック内でさらに最初に暗号化された暗号化ブロックが記憶された記憶手段のアドレスの直前のアドレスにブロック暗号化初期値を記憶するデータ処理システムである。
【０００９】
【発明の実施の形態】
以下、この発明の実施形態に係わるオーディオシステムについて説明する。図１は、一実施形態のオーディオシステム１のシステム構成図、図２は図１に示す携帯用記憶装置３および携帯用プレーヤ４の内部構成図である。図１に示すように、オーディオシステム１は、例えば、コンピュータ２、携帯用記憶装置３、携帯用プレーヤ４、ＣＤ−ＲＯＭドライブ６およびＣＤプレーヤ７を有する。
【００１０】
コンピュータ２
コンピュータ２は、ネットワーク５に接続されており、例えば、ＥＭＤ(Electronic Music Distribution: 電子音楽配信）などのサービスを提供する図示しないサービスプロバイダのホストコンピュータから、ネットワーク５を介してオーディオデータ（トラックデータ）を受信し、当該受信したオーディオデータを必要に応じて復号して、携帯用プレーヤ４に出力する。また、コンピュータ２は、コンテンツデータを受信するに当たって、必要に応じて、サービスプロバイダのホストコンピュータとの間で認証処理および課金処理などを行う。また、コンピュータ２は、例えば、ＣＤ−ＲＯＭドライブ６から入力したオーディオデータを携帯用プレーヤ４に出力する。
【００１１】
携帯用記憶装置３
携帯用記憶装置３は、携帯用プレーヤ４に対して着脱自在とされ、例えば、メモリスティック(Memory Stick:商標）であり、フラッシュメモリなどの書き換え可能な半導体メモリを内蔵している。本明細書において、メモリカードの用語が使用されることもあるが、メモリカードは、携帯用記憶装置を指すものとして使用している。図２に示すように、携帯用記憶装置３は、例えば、主制御モジュール３１、通信インターフェイス３２、制御モジュール３３、フラッシュメモリ３４およびフラッシュメモリ管理モジュール３５を有する。
【００１２】
〔制御モジュール３３〕
図２に示すように、制御モジュール３３は、例えば、乱数発生ユニット５０、記憶ユニット５１、鍵生成／演算ユニット５２、相互認証ユニット５３、暗号化／復号ユニット５４および制御ユニット５５を有する。制御モジュール３３は、シングルチップの暗号処理専用の集積回路であり、多層構造を有し、内部のメモリセルはアルミニウム層などのダミー層に挟まれている。また、制御モジュール３３は、動作電圧または動作周波数の幅が狭く、外部から不正にデータを読み出せないように耐タンパー性を有している。乱数発生ユニット５０は、乱数発生指示を受けると、６４ビット（８バイト）の乱数を発生する。
【００１３】
記憶ユニット５１は、例えば、ＥＥＰＲＯＭ(Electrically Erasable Programmable Read Only Memory) などの不揮発性メモリであり、認証処理に必要な鍵データなどの種々のデータを記憶している。図３は、記憶ユニット５１に記憶されているデータを説明するための図である。図３に示すように、記憶ユニット５１は、認証鍵データＩＫ0 〜ＩＫ31、装置識別データＩＤm および記憶用鍵データＳＫm を記憶している。
【００１４】
認証鍵データＩＫ0 〜ＩＫ31は、携帯用記憶装置３が携帯用プレーヤ４との間で相互認証を行う際に用いられる鍵データであり、後述するように相互認証を行う度に認証鍵データＩＫ0 〜ＩＫ31のうち一の認証鍵データがランダムに選択される。なお、認証鍵データＩＫ0 〜ＩＫ31および記憶用鍵データＳＫm は、携帯用記憶装置３の外部から読めないようになっている。装置識別データＩＤm は、携帯用記憶装置３に対してユニークに付けられた識別データであり、後述するように、携帯用記憶装置３が携帯用プレーヤ４との間で相互認証を行う際に読み出されて携帯用プレーヤ４に出力される。記憶用鍵データＳＫm は、後述するように、コンテンツ鍵データＣＫを暗号化してフラッシュメモリ３４に記憶する際に用いられる。
【００１５】
鍵生成／演算ユニット５２は、例えば、ＩＳＯ／ＩＥＣ９７９７のＭＡＣ(Message Authentication Code) 演算などの種々の演算を行って鍵データを生成する。このとき、ＭＡＣ演算には、例えば、"Block cipher Algorithm"としてＦＩＰＳＰＵＢ４６−２に規定されるＤＥＳ(Data Encryption Standard)が用いられる。ＭＡＣ演算は、任意の長さのデータを固定の長さに圧縮する一方向性ハッシュ関数演算であり、関数値が秘密鍵に依存して定まる。
【００１６】
相互認証ユニット５３は、携帯用プレーヤ４からオーディオデータを入力してフラッシュメモリ３４に書き込む動作を行うのに先立って、携帯用プレーヤ４との間で相互認証処理を行う。また、相互認証ユニット５３は、フラッシュメモリ３４からオーディオデータを読み出して携帯用プレーヤ４に出力する動作を行うのに先立って、携帯用プレーヤ４との間で相互認証処理を行う。また、相互認証ユニット５３は、相互認証処理において、前述したＭＡＣ演算を行う。当該相互認証処理では、記憶ユニット５１に記憶されているデータが用いられる。
【００１７】
暗号化／復号ユニット５４は、ＤＥＳ、ＩＤＥＡ、ＭＩＳＴＹなどのブロック暗号アルゴリズムでの暗号化を行う。使用するモードは、ＦＩＰＳ ＰＵＢ８１”ＤＥＳ ＭＯＤＥＳ ＯＦ ＯＰＥＲＡＴＩＯＮ”に規定されているようなＥＣＢ(Electronic Code Book)モードおよびＣＢＣ(Cipher Block Chaining) モードである。また、暗号化／復号ユニット５４は、ＤＥＳ、ＩＤＥＡ、ＭＩＳＴＹなどのブロック復号アルゴリズムでの復号を行う。使用するモードは、上記ＥＣＢモードおよびＣＢＣモードである。当該ＥＣＢモードおよびＣＢＣモードのブロック暗号化／復号では、指定された鍵データを用いて指定されたデータを暗号化／復号する。制御ユニット５５は、乱数発生ユニット５０、記憶ユニット５１、鍵生成／演算ユニット５２、相互認証ユニット５３および暗号化／復号ユニット５４の処理を統括して制御する。
【００１８】
〔フラッシュメモリ３４〕
フラッシュメモリ３４は、例えば、３２Ｍバイトの記憶容量を有する。フラッシュメモリ３４には、相互認証ユニット５３による相互認証処理によって正当な相手であると認められたときに、携帯用プレーヤ４から入力したオーディオデータが書き込まれる。また、フラッシュメモリ３４からは、相互認証ユニット５３による相互認証処理によって正当な相手であると認められたときに、オーディオデータが読み出されて携帯用プレーヤ４に出力される。
【００１９】
以下、フラッシュメモリ３４に記憶されるデータおよびそのフォーマットについて説明する。図４は、フラッシュメモリ３４に記憶されるデータを説明するための図である。図４に示すように、フラッシュメモリ３４には、例えば、再生管理ファイル１００、トラックデータファイル１０１0 ，１０１1 ，１０１2 ，１０１3 が記憶されている。ここで、再生管理ファイル１００はトラックデータファイル１０１0 〜１０１3 の再生を管理する管理データを有し、トラックデータファイル１０１0 〜１０１3 はそれぞれ対応するトラックデータ（オーディオデータ）を有している。なお、本実施形態では、トラックデータは、例えば、１曲分のオーディオデータを意味する。
【００２０】
図５は、再生管理ファイルの構成を示し、図６が一つ（１曲）のトラックデータファイル（以下においてＡＴＲＡＣ３データファイルの用語がさすものもトラックデータファイルと同義である）の構成を示す。再生管理ファイルは、１６ＫＢ固定長のファイルである。ＡＴＲＡＣ３データファイルは、曲単位でもって、先頭の属性ヘッダと、それに続く実際の暗号化された音楽データとからなる。属性ヘッダも１６ＫＢ固定長とされ、再生管理ファイルと類似した構成を有する。
【００２１】
再生管理ファイルは、ヘッダ、１バイトコードのメモリカードの名前ＮＭ１−Ｓ、２バイトコードのメモリカードの名前ＮＭ２−Ｓ、曲順の再生テーブルＴＲＫＴＢＬ、メモリカード全体の付加情報ＩＮＦ−Ｓとからなる。データファイルの先頭の属性ヘッダは、ヘッダ、１バイトコードの曲名ＮＭ１、２バイトコードの曲名ＮＭ２、トラックのキー情報等のトラック情報ＴＲＫＩＮＦ、パーツ情報ＰＲＴＩＮＦと、トラックの付加情報ＩＮＦとからなる。ヘッダには、総パーツ数、名前の属性、付加情報のサイズの情報等が含まれる。
【００２２】
属性ヘッダに対してＡＴＲＡＣ３の音楽データが続く。音楽データは、１６ＫＢのブロック毎に区切られ、各ブロックの先頭にヘッダが付加されている。ヘッダには、暗号を復号するための初期値が含まれる。なお、暗号化の処理を受けるのは、ＡＴＲＡＣ３データファイル中の音楽データのみであって、それ以外の再生管理ファイル、ヘッダ等のデータは、暗号化されない。
【００２３】
図７は、再生管理ファイルＰＢＬＩＳＴのより詳細なデータ構成を示し、図８Ａ、図８Ｂは、再生管理ファイルＰＢＬＩＳＴを構成するヘッダとそれ以外の部分をそれぞれ示す。再生管理ファイルＰＢＬＩＳＴは、１クラスタ（１ブロック＝１６ＫＢ）のサイズである。ヘッダ（図８Ａ）が３２バイトである。ヘッダ以外の部分（図８Ｂ）がメモリカード全体に対する名前ＮＭ１−Ｓ（２５６バイト）、名前ＮＭ２−Ｓ（５１２バイト）、ＣＯＮＴＥＮＴＳ ＫＥＹ、ＭＡＣ、Ｓ−ＹＭＤｈｍｓと、再生順番を管理するテーブルＴＲＫＴＢＬ（８００バイト）と、メモリカード全体に対する付加情報ＩＮＦ−Ｓ（１４７２０バイト）であり、最後にヘッダ中の情報の一部が再度記録される。これらの異なる種類のデータ群のそれぞれの先頭は、再生管理ファイル内で所定の位置となるように規定されている。
【００２４】
再生管理ファイルは、（０ｘ００００）および（０ｘ００１０）で表される先頭から３２バイト（図８Ａ）がヘッダである。なお、ファイル中で先頭から１６バイト単位で区切られた単位をスロットと称する。ファイルの第１および第２のスロットに配されるヘッダには、下記の意味、機能、値を持つデータが先頭から順に配される。なお、Ｒｅｓｅｒｖｅｄと表記されているデータは、未定義のデータを表している。通常ヌル（０ｘ００）が書かれるが、何が書かれていてもＲｅｓｅｒｖｅｄのデータが無視される。将来のバージョンでは、変更がありうる。また、この部分への書き込みは禁止する。Ｏｐｔｉｏｎと書かれた部分も使用しない場合は、全てＲｅｓｅｒｖｅｄと同じ扱いとされる。
【００２５】
ＢＬＫＩＤ−ＴＬ０（４バイト）
意味：BLOCKID FILE ID
機能：再生管理ファイルの先頭であることを識別するための値
値：固定値＝”ＴＬ＝０”（例えば０ｘ５４４Ｃ２Ｄ３０）
ＭＣｏｄｅ（２バイト）
意味：MAKER CODE
機能：記録した機器の、メーカー、モデルを識別するコード
値：上位１０ビット（メーカーコード） 下位６ビット（機種コード）
ＲＥＶＩＳＩＯＮ（４バイト）
意味：ＰＢＬＩＳＴの書き換え回数
機能：再生管理ファイルを書き換える度にインクリメント
値：０より始まり＋１づつ増加する
【００２６】
ＳＮ１Ｃ＋Ｌ（２バイト）
意味：ＮＭ１−Ｓ領域に書かれるメモリカードの名前（１バイト）の属性を表す
機能：使用する文字コードと言語コードを各１バイトで表す
値：文字コード（Ｃ）は上位１バイトで下記のように文字を区別する
00: 文字コードは設定しない。単なる２進数として扱うこと
01: ASCII 02:ASCII+KANA 03:modifided8859-1
81:MS-JIS 82:KS C 5601-1989 83:GB2312-80 90:S-JIS(for Voice) 。
【００２７】
言語コード（Ｌ）は下位１バイトで下記のようにEBU Tech 3258 規定に準じて言語を区別する
00: 設定しない 08:German 09:English 0A:Spanish
0F:French 15:Italian 1D:Dutch
65:Korean 69:Japanese 75:Chinese
データが無い場合オールゼロとすること。
【００２８】
ＳＮ２Ｃ＋Ｌ（２バイト）
意味：ＮＭ２−Ｓ領域に書かれるメモリカードの名前（２バイト）の属性を表す
機能：使用する文字コードと言語コードを各１バイトで表す
値：上述したＳＮ１Ｃ＋Ｌと同一
ＳＩＮＦＳＩＺＥ（２バイト）
意味：ＩＮＦ−Ｓ領域に書かれるメモリカード全体に関する付加情報の全てを合計したサイズを表す
機能：データサイズを１６バイト単位の大きさで記述、無い場合は必ずオールゼロとすること
値：サイズは０ｘ０００１から０ｘ３９Ｃ（９２４）
Ｔ−ＴＲＫ（２バイト）
意味：TOTAL TRACK NUMBER
機能：総トラック数
値：１から０ｘ０１９０（最大４００トラック）、データが無い場合はオールゼロとすること
【００２９】
上述したヘッダに続く領域に書かれるデータ（図８Ｂ）について以下に説明する。
【００３０】
ＮＭ１−Ｓ
意味：メモリカード全体に関する１バイトの名前
機能：１バイトの文字コードで表した可変長の名前データ（最大で２５６）
名前データの終了は、必ず終端コード（０ｘ００）を書き込むこと
サイズはこの終端コードから計算すること、データの無い場合は少なくとも先頭（０ｘ００２０）からヌル（０ｘ００）を１バイト以上記録すること
値：各種文字コード
ＮＭ２−Ｓ
意味：メモリカード全体に関する２バイトの名前
機能：２バイトの文字コードで表した可変長の名前データ（最大で５１２）
名前データの終了は、必ず終端コード（０ｘ００）を書き込むこと
サイズはこの終端コードから計算すること、データの無い場合は少なくとも先頭（０ｘ０１２０）からヌル（０ｘ００）を２バイト以上記録すること
値：各種文字コード。
【００３１】
ＣＯＮＴＥＮＴＳ ＫＥＹ
意味：曲ごとに用意された値でＭＧ（Ｍ）で保護されてから保存される。ここでは、１曲目に付けられるＣＯＮＴＥＮＴＳ ＫＥＹと同じ値
機能：Ｓ−ＹＭＤｈｍｓのＭＡＣの計算に必要となる鍵となる
値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦまで
ＭＡＣ
意味：著作権情報改ざんチェック値
機能：Ｓ−ＹＭＤｈｍｓの内容とＣＯＮＴＥＮＴＳ ＫＥＹから作成される値
値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦまで。
【００３２】
ＴＲＫ−ｎｎｎ
意味：再生するＡＴＲＡＣ３データファイルのＳＱＮ（シーケンス）番号
機能：ＴＲＫＩＮＦの中のＦＮｏを記述する
値：１から４００（０ｘ１９０）
トラックが存在しない時はオールゼロとすること
ＩＮＦ−Ｓ
意味：メモリカード全体に関する付加情報データ（例えば写真、歌詞、解説等の情報）
機能：ヘッダを伴った可変長の付加情報データ
複数の異なる付加情報が並べられることがある。それぞれにＩＤとデータサイズが付けられている。個々のヘッダを含む付加情報データは最小１６バイト以上で４バイトの整数倍の単位で構成される。その詳細については、後述する
値：付加情報データ構成を参照
【００３３】
再生管理ファイルの最後のスロットとして、ヘッダ内のものと同一のＢＬＫＩＤ−ＴＬ０と、ＭＣｏｄｅと、ＲＥＶＩＳＩＯＮとが書かれる。
【００３４】
民生用オーディオ機器として、メモリカードが記録中に抜かれたり、電源が切れることがあり、復活した時にこれらの異常の発生を検出することが必要とされる。上述したように、ＲＥＶＩＳＩＯＮをブロックの先頭と末尾に書き込み、この値を書き換える度に＋１インクリメントするようにしている。若し、ブロックの途中で異常終了が発生すると、先頭と末尾のＲＥＶＩＳＩＯＮの値が一致せず、異常終了を検出することができる。ＲＥＶＩＳＩＯＮが２個存在するので、高い確率で異常終了を検出することができる。異常終了の検出時には、エラーメッセージの表示等の警告が発生する。
【００３５】
また、１ブロック（１６ＫＢ）の先頭部分に固定値ＢＬＫＩＤ−ＴＬ０を挿入しているので、ＦＡＴが壊れた場合の修復の目安に固定値を使用できる。すなわち、各ブロックの先頭の固定値を見れば、ファイルの種類を判別することが可能である。しかも、この固定値ＢＬＫＩＤ−ＴＬ０は、ブロックのヘッダおよびブロックの終端部分に二重に記述するので、その信頼性のチェックを行うことができる。なお、再生管理ファイルＰＢＬＩＳＴの同一のものを二重に記録しても良い。
【００３６】
ＡＴＲＡＣ３データファイルは、トラック情報管理ファイルと比較して、相当大きなデータ量（例えば数千のブロックが繋がる場合もある）であり、ＡＴＲＡＣ３データファイルに関しては、後述するように、ブロック番号ＢＬＯＣＫ ＳＥＲＩＡＬが付けられている。但し、ＡＴＲＡＣ３データファイルは、通常複数のファイルがメモリカード上に存在するので、ＣＯＮＮＵＭ０でコンテンツの区別を付けた上で、ＢＬＯＣＫ ＳＥＲＩＡＬを付けないと、重複が発生し、ＦＡＴが壊れた場合のファイルの復旧が困難となる。
【００３７】
同様に、ＦＡＴの破壊までにはいたらないが、論理を間違ってファイルとして不都合のあるような場合に、書き込んだメーカーの機種が特定できるように、メーカーコード（ＭＣｏｄｅ）がブロックの先頭と末尾に記録されている。
【００３８】
図８Ｃは、付加情報データの構成を示す。付加情報の先頭に下記のヘッダが書かれる。ヘッダ以降に可変長のデータが書かれる。
【００３９】
ＩＮＦ
意味：FIELD ID
機能：付加情報データの先頭を示す固定値
値：０ｘ６９
ＩＤ
意味：付加情報キーコード
機能：付加情報の分類を示す
値：０から０ｘＦＦ
ＳＩＺＥ
意味：個別の付加情報の大きさ
機能：データサイズは自由であるが、必ず４バイトの整数倍でなければならない。また、最小１６バイト以上のこと。データの終わりより余りがでる場合はヌル（０ｘ００）で埋めておくこと
値：１６から１４７８４（０ｘ３９Ｃ０）
ＭＣｏｄｅ
意味：MAKER CODE
機能：記録した機器の、メーカー、モデルを識別するコード
値：上位１０ビット（メーカーコード） 下位６ビット（機種コード）
Ｃ＋Ｌ
意味：先頭から１２バイト目からのデータ領域に書かれる文字の属性を表す
機能：使用する文字コードと言語コードを各１バイトで表す
値：前述のＳＮ１Ｃ＋Ｌと同じ
ＤＡＴＡ
意味：個別の付加情報データ
機能：可変長データで表す。実データの先頭は常に１２バイト目より始まり、長さ（サイズ）は最小４バイト以上、常に４バイトの整数倍でなければならない。データの最後から余りがある場合はヌル（０ｘ００）で埋めること
値：内容により個別に定義される。
【００４０】
以下、トラックデータファイル１０１0 〜１０１3 について説明する。図９は、トラックデータファイル１０１0 の構成を説明するための図である。図９に示すように、トラックデータファイル１０１0 は、１個のパーツからなり、当該パーツが５個のクラスタＣＬ（０），ＣＬ（１），ＣＬ（２），ＣＬ（３），ＣＬ（４）で構成されている。当該パーツは、クラスタＣＬ（０）の先頭から開始し、クラスタＣＬ（４）のサウンドユニットＳＵ（４）で終了している。なお、トラックデータファイル１０１1 〜１０１3 は、基本的に、図９に示す構成をしているが、パーツ数、クラスタ数およびクラスタ内に含まれるサウンドユニットＳＵの数は、図９に示すものには限定されず、独立して決められている。
【００４１】
１トラックは、１曲を意味する。１曲は、１つのＡＴＲＡＣ３データファイル（図６参照）で構成される。ＡＴＲＡＣ３データファイルは、ＡＴＲＡＣ３により圧縮されたオーディオデータである。メモリカード４０に対しては、クラスタと呼ばれる単位で記録される。１クラスタは、例えば１６ＫＢの容量である。１クラスタに複数のファイルが混じることがない。フラッシュメモリ４２を消去する時の最小単位が１ブロックである。音楽データを記録するのに使用するメモリカード４０の場合、ブロックとクラスタは、同意語であり、且つ１クラスタ＝１セクタと定義されている。
【００４２】
１曲は、基本的に１パーツで構成されるが、編集が行われると、複数のパーツから１曲が構成されることがある。パーツは、録音開始からその停止までの連続した時間内で記録されたデータの単位を意味し、通常は、１トラックが１パーツで構成される。曲内のパーツのつながりは、各曲の属性ヘッダ内のパーツ情報ＰＲＴＩＮＦで管理する。すなわち、パーツサイズは、ＰＲＴＩＮＦの中のパーツサイズＰＲＴＳＩＺＥという４バイトのデータで表す。パーツサイズＰＲＴＳＩＺＥの先頭の２バイトがパーツが持つクラスタの総数を示し、続く各１バイトが先頭および末尾のクラスタ内の開始サウンドユニット（ＳＵと略記する）の位置、終了ＳＵの位置を示す。このようなパーツの記述方法を持つことによって、音楽データを編集する際に通常、必要とされる大量の音楽データの移動をなくすことが可能となる。ブロック単位の編集に限定すれば、同様に音楽データの移動を回避できるが、ブロック単位は、ＳＵ単位に比して編集単位が大きすぎる。
【００４３】
ＳＵは、パーツの最小単位であり、且つＡＴＲＡＣ３でオーディオデータを圧縮する時の最小のデータ単位である。４４．１ｋHzのサンプリング周波数で得られた１０２４サンプル分（１０２４×１６ビット×２チャンネル）のオーディオデータを約１／１０に圧縮した数百バイトのデータがＳＵである。１ＳＵは、時間に換算して約２３ｍ秒になる。通常は、数千に及ぶＳＵによって１つのパーツが構成される。１クラスタが４２個のＳＵで構成される場合、１クラスタで約１秒の音を表すことができる。１つのトラックを構成するパーツの数は、付加情報サイズに影響される。パーツ数は、１ブロックの中からヘッダや曲名、付加情報データ等を除いた数で決まるために、付加情報が全く無い状態が最大数（６４５個）のパーツを使用できる条件となる。
【００４４】
図１０は、１ＳＵがＮバイト（例えばＮ＝３８４バイト）の場合のＡＴＲＡＣ３データファイルＡ３Ｄｎｎｎｎのデータ配列を示す。図１０には、データファイルの属性ヘッダ（１ブロック）と、音楽データファイル（１ブロック）とが示されている。図１０では、この２ブロック（１６×２＝３２Ｋバイト）の各スロットの先頭のバイト（０ｘ００００〜０ｘ７ＦＦ０）が示されている。図１１に分離して示すように、属性ヘッダの先頭から３２バイトがヘッダであり、２５６バイトが曲名領域ＮＭ１（２５６バイト）であり、５１２バイトが曲名領域ＮＭ２（５１２バイト）である。属性ヘッダのヘッダには、下記のデータが書かれる。
【００４５】
ＢＬＫＩＤ−ＨＤ０（４バイト）
意味：BLOCKID FILE ID
機能：ＡＴＲＡＣ３データファイルの先頭であることを識別するための値
値：固定値＝”ＨＤ＝０”（例えば０ｘ４８４４２Ｄ３０）
ＭＣｏｄｅ（２バイト）
意味：MAKER CODE
機能：記録した機器の、メーカー、モデルを識別するコード
値：上位１０ビット（メーカーコード） 下位６ビット（機種コード）
ＢＬＯＣＫ ＳＥＲＩＡＬ（４バイト）
意味：トラック毎に付けられた連続番号
機能：ブロックの先頭は０から始まり次のブロックは＋１づつインクリメント
編集されても値を変化させない
値：０より始まり０ｘＦＦＦＦＦＦＦＦまで。
【００４６】
Ｎ１Ｃ＋Ｌ（２バイト）
意味：トラック（曲名）データ（ＮＭ１）の属性を表す
機能：ＮＭ１に使用される文字コードと言語コードを各１バイトで表す
値：ＳＮ１Ｃ＋Ｌと同一
Ｎ２Ｃ＋Ｌ（２バイト）
意味：トラック（曲名）データ（ＮＭ２）の属性を表す
機能：ＮＭ２に使用される文字コードと言語コードを各１バイトで表す
値：ＳＮ１Ｃ＋Ｌと同一
ＩＮＦＳＩＺＥ（２バイト）
意味：トラックに関する付加情報の全てを合計したサイズを表す
機能：データサイズを１６バイト単位の大きさで記述、無い場合は必ずオールゼロとすること
値：サイズは０ｘ００００から０ｘ３Ｃ６（９６６）
Ｔ−ＰＲＴ（２バイト）
意味：トータルパーツ数
機能：トラックを構成するパーツ数を表す。通常は１
値：１から０ｘ２８５（６４５dec ）
Ｔ−ＳＵ（４バイト）
意味：トータルＳＵ数
機能：１トラック中の実際の総ＳＵ数を表す。曲の演奏時間に相当する
値：０ｘ０１から０ｘ００１ＦＦＦＦＦ
ＩＮＸ（２バイト）（Ｏｐｔｉｏｎ）
意味：INDEX の相対場所
機能：曲のさびの部分（特徴的な部分）の先頭を示すポインタ。曲の先頭からの位置をＳＵの個数を１／４した数で指定する。これは、通常のＳＵの４倍の長さの時間（約９３ｍ秒）に相当する
値：０から０ｘＦＦＦＦ（最大、約６０８４秒）
ＸＴ（２バイト）（Ｏｐｔｉｏｎ）
意味：INDEX の再生時間
機能：ＩＮＸ-nnnで指定された先頭から再生すべき時間のＳＵの個数を１／４した数で指定する。これは、通常のＳＵの４倍の長さの時間（約９３ｍ秒）に相当する
値：０ｘ００００：無設定 ０ｘ０１から０ｘＦＦＦＥ（最大６０８４秒）
０ｘＦＦＦＦ：曲の終わりまで。
【００４７】
次に曲名領域ＮＭ１およびＮＭ２について説明する。
【００４８】
ＮＭ１
意味：曲名を表す文字列
機能：１バイトの文字コードで表した可変長の曲名（最大で２５６）
名前データの終了は、必ず終端コード（０ｘ００）を書き込むこと
サイズはこの終端コードから計算すること、データの無い場合は少なくとも先頭（０ｘ００２０）からヌル（０ｘ００）を１バイト以上記録すること
値：各種文字コード
ＮＭ２
意味：曲名を表す文字列
機能：２バイトの文字コードで表した可変長の名前データ（最大で５１２）
名前データの終了は、必ず終端コード（０ｘ００）を書き込むこと
サイズはこの終端コードから計算すること、データの無い場合は少なくとも先頭（０ｘ０１２０）からヌル（０ｘ００）を２バイト以上記録すること
値：各種文字コード。
【００４９】
属性ヘッダの固定位置（０ｘ３２０）から始まる、８０バイトのデータをトラック情報領域ＴＲＫＩＮＦと呼び、主としてセキュリティ関係、コピー制御関係の情報を一括して管理する。図１２にＴＲＫＩＮＦの部分を示す。ＴＲＫＩＮＦ内のデータについて、配置順序に従って以下に説明する。
【００５０】
ＣＯＮＴＥＮＴＳ ＫＥＹ（８バイト）
意味：曲毎に用意された値で、メモリカードのセキュリティブロックで保護されてから保存される
機能：曲を再生する時、まず必要となる最初の鍵となる。ＭＡＣ計算時に使用される
値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦまで
ＭＡＣ（８バイト）
意味：著作権情報改ざんチェック値
機能：コンテンツ累積番号を含む複数のＴＲＫＩＮＦの内容と隠しシーケンス番号から作成される値
隠しシーケンス番号とは、メモリカードの隠し領域に記録されているシーケンス番号のことである。著作権対応でないレコーダは、隠し領域を読むことができない。また、著作権対応の専用のレコーダ、またはメモリカードを読むことを可能とするアプリケーションを搭載したパーソナルコンピュータは、隠し領域をアクセスすることができる。
【００５１】
Ａ（１バイト）
意味：パーツの属性
機能：パーツ内の圧縮モード等の情報を示す
値：図１３を参照して以下に説明する
ただし、Ｎ＝０，１のモノラルは、ｂｉｔ７が１でサブ信号を０、メイン信号（Ｌ＋Ｒ）のみの特別なＪｏｉｎｔモードをモノラルとして規定する。ｂｉｔ２，１の情報は通常の再生機は無視しても構わない。
【００５２】
Ａのビット０は、エンファシスのオン／オフの情報を形成し、ビット１は、再生ＳＫＩＰか、通常再生かの情報を形成し、ビット２は、データ区分、例えばオーディオデータか、ＦＡＸ等の他のデータかの情報を形成する。ビット３は、未定義である。ビット４、５、６を組み合わせることによって、図示のように、ＡＴＲＡＣ３のモード情報が規定される。すなわち、Ｎは、この３ビットで表されるモードの値であり、モノ（Ｎ＝０，１），ＬＰ（Ｎ＝２），ＳＰ（Ｎ＝４），ＥＸ（Ｎ＝５），ＨＱ（Ｎ＝７）の５種類のモードについて、記録時間（６４ＭＢのメモリカードの場合）、データ転送レート、１ブロック内のＳＵ数がそれぞれ示されている。１ＳＵのバイト数は、（モノ：１３６バイト、ＬＰ：１９２バイト、ＳＰ：３０４バイト、ＥＸ：３８４バイト、ＨＱ：５１２バイト）である。さらに、ビット７によって、ＡＴＲＡＣ３のモード（０：Dual １：Joint ）が示される。
【００５３】
一例として、６４ＭＢのメモリカードを使用し、ＳＰモードの場合について説明する。６４ＭＢのメモリカードには、３９６８ブロックがある。ＳＰモードでは、１ＳＵが３０４バイトであるので、１ブロックに５３ＳＵが存在する。１ＳＵは、（１０２４／４４１００）秒に相当する。従って、１ブロックは、
（１０２４／４４１００）×５３×（３９６８−１６）＝４８６３秒＝８１分
転送レートは、
（４４１００／１０２４）×３０４×８＝１０４７３７ bps
となる。
【００５４】
ＦＮｏ（２バイト）
意味：ファイル番号
機能：最初に記録された時のトラック番号、且つこの値は、メモリカード内の隠し領域に記録されたＭＡＣ計算用の値の位置を特定する
値：１から０ｘ１９０（４００）
ＭＧ（Ｄ）ＳＥＲＩＡＬ−ｎｎｎ（１６バイト）
意味：記録機器のセキュリティブロック（制御モジュ−ル４３）のシリアル番号
機能：記録機器ごとに全て異なる固有の値
値：０から0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
ＣＯＮＮＵＭ（４バイト）
意味：コンテンツ累積番号
機能：曲毎に累積されていく固有の値で記録機器のセキュリティブロックによって管理される。２の３２乗、４２億曲分用意されており、記録した曲の識別に使用する
値：０から０ｘＦＦＦＦＦＦＦＦ。
【００５５】
ＹＭＤｈｍｓ−Ｓ（４バイト）（Ｏｐｔｉｏｎ）
意味：再生制限付きのトラックの再生開始日時
機能：ＥＭＤで指定する再生開始を許可する日時
値：上述した日時の表記と同じ
ＹＭＤｈｍｓ−Ｅ（４バイト）（Ｏｐｔｉｏｎ）
意味：再生制限付きのトラックの再生終了日時
機能：ＥＭＤで指定する再生許可を終了する日時
値：上述した日時の表記と同じ
【００５６】
ＣＣ（１バイト）
意味：COPY CONTROL
機能：コピー制御
値：図１４に示すように、ビット６および７によってコピー制御情報を表し、ビット４および５によって高速ディジタルコピーに関するコピー制御情報を表し、ビット２および３によってセキュリティブロック認証レベルを表す。ビット０および１は、未定義
ＣＣの例：（ｂｉｔ７，６）１１：無制限のコピーを許可、０１：コピー禁止、００：１回のコピーを許可
（ｂｉｔ３，２）００：アナログないしディジタルインからの録音、ＭＧ認証レベルは０とする
ＣＤからのディジタル録音では（ｂｉｔ７，６）は００、（ｂｉｔ３，２）は００となる
ＣＮ（１バイト）（Ｏｐｔｉｏｎ）
意味：高速ディジタルコピーＨＳＣＭＳ(High speed Serial Copy Management System)におけるコピー許可回数
機能：コピー１回か、コピーフリーかの区別を拡張し、回数で指定する。コピー第１世代の場合にのみ有効であり、コピーごとに減算する
値：００：コピー禁止、０１から０ｘＦＥ：回数、０ｘＦＦ：回数無制限。
【００５７】
上述したトラック情報領域ＴＲＫＩＮＦに続いて、０ｘ０３７０から始まる２４バイトのデータをパーツ管理用のパーツ情報領域ＰＲＴＩＮＦと呼び、１つのトラックを複数のパーツで構成する場合に、時間軸の順番にＰＲＴＩＮＦを並べていく。図１５にＰＲＴＩＮＦの部分を示す。ＰＲＴＩＮＦ内のデータについて、配置順序に従って以下に説明する。
【００５８】
ＰＲＴＳＩＺＥ（４バイト）
意味：パーツサイズ
機能：パーツの大きさを表す。クラスタ：２バイト（最上位）、開始ＳＵ：１バイト（上位）、終了ＳＵ：１バイト（最下位）
値：クラスタ：１から０ｘ１Ｆ４０（８０００）、開始ＳＵ：０から０ｘＡ０（１６０）、終了ＳＵ：０から０ｘＡ０（１６０）（但し、ＳＵの数え方は、０，１，２，と０から開始する）
ＰＲＴＫＥＹ（８バイト）
意味：パーツを暗号化するための値
機能：初期値＝０、編集時は編集の規則に従うこと
値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦ
ＣＯＮＮＵＭ０（４バイト）
意味：最初に作られたコンテンツ累積番号キー
機能：コンテンツをユニークにするためのＩＤの役割
値：コンテンツ累積番号初期値キーと同じ値とされる。
【００５９】
ＡＴＲＡＣ３データファイルの属性ヘッダ中には、図１０に示すように、付加情報ＩＮＦが含まれる。この付加情報は、開始位置が固定化されていない点を除いて、再生管理ファイル中の付加情報ＩＮＦ−Ｓ（図７および図８Ｂ参照）と同一である。１つまたは複数のパーツの最後のバイト部分（４バイト単位）の次を開始位置として付加情報ＩＮＦのデータが開始する。
【００６０】
ＩＮＦ
意味：トラックに関する付加情報データ
機能：ヘッダを伴った可変長の付加情報データ。複数の異なる付加情報が並べられることがある。それぞれにＩＤとデータサイズが付加されている。個々のヘッダを含む付加情報データは、最小１６バイト以上で４バイトの整数倍の単位
値：再生管理ファイル中の付加情報ＩＮＦ−Ｓと同じである。
【００６１】
上述した属性ヘッダに対して、ＡＴＲＡＣ３データファイルの各ブロックのデータが続く。図１６に示すように、ブロック毎にヘッダが付加される。各ブロックのデータについて以下に説明する。
【００６２】
ＢＬＫＩＤ−Ａ３Ｄ（４バイト）
意味：BLOCKID FILE ID
機能：ＡＴＲＡＣ３データの先頭であることを識別するための値
値：固定値＝”Ａ３Ｄ”（例えば０ｘ４１３３４４２０）
ＭＣｏｄｅ（２バイト）
意味：MAKER CODE
機能：記録した機器の、メーカー、モデルを識別するコード
値：上位１０ビット（メーカーコード） 下位６ビット（機種コード）
ＣＯＮＮＵＭ０（４バイト）
意味：最初に作られたコンテンツ累積番号
機能：コンテンツをユニークにするためのＩＤの役割、編集されても値は変化させない
値：コンテンツ累積番号初期値キーと同じ値とされる
ＢＬＯＣＫ ＳＥＲＩＡＬ（４バイト）
意味：トラック毎に付けられた連続番号
機能：ブロックの先頭は０から始まり次のブロックは＋１づつインクリメント編集されても値を変化させない
値：０より始まり０ｘＦＦＦＦＦＦＦＦまで
ＢＬＯＣＫ−ＳＥＥＤ（８バイト）
意味：１ブロックを暗号化するための１つの鍵
機能：ブロックの先頭は、記録機器のセキュリティブロックで乱数を生成、続くブロックは、＋１インクリメントされた値、この値が失われると、１ブロックに相当する約１秒間、音が出せないために、ヘッダとブロック末尾に同じものが二重に書かれる。編集されても値を変化させない
値：初期は８バイトの乱数
ＩＮＩＴＩＡＬＩＺＡＴＩＯＮ ＶＥＣＴＯＲ（８バイト）
意味：ブロック毎にＡＴＲＡＣ３データを暗号化、復号化する時に必要な初期値
機能：ブロックの先頭は０から始まり、次のブロックは最後のＳＵの最後の暗号化された８バイトの値。デバイドされたブロックの途中からの場合は開始ＳＵの直前の最後の８バイトを用いる。編集されても値を変化させない
値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦ
ＳＵ−ｎｎｎ
意味：サウンドユニットのデータ
機能：１０２４サンプルから圧縮されたデータ、圧縮モードにより出力されるバイト数が異なる。編集されても値を変化させない（一例として、ＳＰモードの時では、Ｎ＝３８４バイト）
値：ＡＴＲＡＣ３のデータ値。
【００６３】
図１０では、Ｎ＝３８４であるので、１ブロックに４２ＳＵが書かれる。また、１ブロックの先頭の２つのスロット（４バイト）がヘッダとされ、最後の１スロット（２バイト）にＢＬＫＩＤ−Ａ３Ｄ、ＭＣｏｄｅ、ＣＯＮＮＵＭ０、ＢＬＯＣＫ ＳＥＲＩＡＬが二重に書かれる。従って、１ブロックの余りの領域Ｍバイトは、（１６，３８４−３８４×４２−１６×３＝２０８（バイト）となる。この中に上述したように、８バイトのＢＬＯＣＫ ＳＥＥＤが二重に記録される。
【００６４】
また、サウンドユニットＳＵ（０）〜（１０１）は、図２に示す暗号化／復号ユニット６４においてＣＢＣ(Cipher Block Chainning)モードで６４ビット（８バイト）の暗号化ブロックを単位として暗号化して生成された８バイトの暗号文Ｃi によって構成される。本実施形態では、サウンドユニットＳＵのバイト数（例えば１６０バイト）を、暗号化の単位である暗号化ブロックのバイト数（例えば８バイト）の整数倍にしている。すなわち、１サウンドユニットＳＵは例えば２０個の暗号文Ｃi からなる。このとき、個々の暗号文Ｃi は一のサウンドユニットＳＵ内に位置し、一の暗号文Ｃi が複数のサウンドユニットＳＵに跨がって位置することはない。
【００６５】
ここで、フラッシュメモリ３４に記憶されているオーディオデータは、後述するように例えば、ＡＴＲＡＣ３方式で圧縮されており、当該圧縮の単位がサウンドユニットＳＵである。従って、携帯用記憶装置３から携帯用プレーヤ４にオーディオデータを読み出す場合には、読み出しの最小単位は当該サウンドユニットＳＵとなる。
【００６６】
このようにすることで、フラッシュメモリ３４に記憶されている暗号化されたオーディオデータにアクセスする際に、暗号化ブロックの区切りを意識する必要がなくなり、当該アクセスに伴う処理負担を軽減できる。なお、各クラスタ内に含まれるサウンドユニットＳＵの数は、１個以上１０２個以下の範囲で任意である。また、オーディオデータの圧縮方式は、ＡＴＲＡＣ３などのＡＴＲＡＣ方式以外のＣＯＤＥＣ方式でもよい。
【００６７】
ブロックシードデータＢＳは、各ブロック毎に例えば乱数を発生して生成されたデータであり、後述するように、携帯用プレーヤ４内でブロック毎にブロック鍵データＢＫを生成する際に用いられる。当該ブロックシードデータＢＳは、エラー対策としてブロック内の２箇所に格納されている。なお、各クラスタに含まれるサウンドユニットは、暗号化された順でフラッシュメモリ３４の連続したアドレスに記憶される。また、各サウンドユニット内の暗号化ブロックは、暗号化された順にフラッシュメモリ３４の連続したアドレスに記憶される。
【００６８】
〔フラッシュメモリ管理モジュール３５〕
フラッシュメモリ管理モジュール３５は、フラッシュメモリ３４へのデータの書き込み、フラッシュメモリ３４からのデータの読み出しなどの制御を行う。
【００６９】
携帯用プレーヤ４
図２に示すように、携帯用プレーヤ４は、例えば、主制御モジュール４１、通信インターフェイス４２、制御モジュール４３、編集モジュール４４、圧縮／伸長モジュール４５、スピーカ４６、Ｄ／Ａ変換器４７およびＡ／Ｄ変換器４８を有する。
【００７０】
〔主制御モジュール４１〕
主制御モジュール４１は、携帯用プレーヤ４の処理を統括的に制御する。
【００７１】
〔制御モジュール４３〕
図２に示すように、制御モジュール４３は、例えば、乱数発生ユニット６０、記憶ユニット６１、鍵生成／鍵演算ユニット６２、相互認証ユニット６３、暗号化／復号ユニット６４および制御ユニット６５を有する。制御モジュール４３は、制御モジュール３３と同様に、シングルチップの暗号処理専用の集積回路であり、多層構造を有し、内部のメモリセルはアルミニウム層などのダミー層に挟まれている。また、制御モジュール４３は、動作電圧または動作周波数の幅が狭く、外部から不正にデータを読み出せないように耐タンパー性を有している。乱数発生ユニット６０は、乱数発生指示を受けると、６４ビット（８バイト）の乱数を発生する。記憶ユニット６１は、認証処理に必要な種々のデータを記憶している。
【００７２】
図１７は、記憶ユニット６１に記憶されているデータを説明するための図である。図１７に示すように、記憶ユニット６１は、マスター鍵データＭＫ0 〜ＭＫ31および装置識別データＩＤd を記憶している。ここで、マスター鍵データＭＫ0 〜ＭＫ31と、認証鍵データＩＫ0 〜ＩＫ31との間には、前述した携帯用記憶装置３の装置識別データＩＤm を用いて、下記式（１）に示す関係がある。なお、下記式において、ｆ（ａ，ｂ）は、例えば、引数ａ，ｂから値を導出する関数である。
【００７３】
【数１】
ＩＫj ＝ｆ（ＭＫj ，ＩＤm ） ・・・（１）
但し、ｉは、０≦ｊ≦３１の整数。
【００７４】
また、記憶ユニット６１における認証鍵データＩＫ0 〜ＩＫ31の記憶アドレスは、例えば５ビットで表現され、それぞれ記憶ユニット５１におけるマスター鍵データＭＫ0 〜ＭＫ31と同じ記憶アドレスが割り当てられている。
【００７５】
鍵生成／鍵演算ユニット６２は、例えば、ＩＳＯ／ＩＥＣ９７９７のＭＡＣ演算方式を用いた演算などの種々の演算を行って鍵データを生成する。このとき、"Block cipher Algorithm"としてＦＩＰＳ ＰＵＢ ４６−２に規定されるＤＥＳが用いられる。
【００７６】
相互認証ユニット６３は、例えば、コンピュータ２から入力したオーディオデータを携帯用記憶装置３に出力する動作を行うのに先立って、携帯用記憶装置３との間で相互認証処理を行う。また、相互認証ユニット６３は、携帯用記憶装置３からオーディオデータを入力する動作を行うのに先立って、携帯用記憶装置３との間で相互認証処理を行う。また、相互認証ユニット６３は、相互認証処理において、前述したＭＡＣ演算を行う。当該相互認証処理では、記憶ユニット６１に記憶されているデータが用いられる。なお、相互認証ユニット６３は、必要に応じて、例えば、コンピュータ２あるいはネットワーク５上のコンピュータとの間でオーディオデータの入出力を行う動作に先立って、コンピュータ２あるいはネットワーク５上のコンピュータとの間で相互認証処理を行う。
【００７７】
暗号化／復号ユニット６４は、前述したように、ＦＩＰＳ ＰＵＢ ８１に規定されたＥＣＢモードおよびＣＢＣモードを選択的に用いてブロック暗号化を行う。ここで、暗号化／復号ユニット６４は、ＣＢＣモードにおいて、５６ビットの鍵データｋを用いて、コンピュータ２あるいはＣＤプレーヤ７から入力したオーディオデータ（平文）を、６４ビットからなる暗号化ブロックを単位として下記式（２）に基づいて暗号化して暗号化されたオーディオデータ（暗号文）を生成する。下記式（２）から分かるように、ＣＢＣモードでは、一つ前の暗号文と次の平文との排他的論理和を暗号化するため、同一の平文が入力されても異なる暗号文が出力され、解読が困難であるという利点がある。
【００７８】
【数２】
Ｃi ＝Ｅk （Ｐi ＸＯＲ Ｃi-1 ） ・・・（２）
ｉ：１以上の整数
Ｐi ：平文（６４ビット）
Ｃi ：暗号文（６４ビット）
ＸＯＲ：排他的論理和
Ｅk ：５６ビットの鍵データｋを用いたＤＥＳ方式の暗号処理
上記式（２）の演算は、図１８で表現される。なお、図１８において、「ＩＶ」は、ブロック暗号化初期値（６４ビット）であり、図２に示す携帯用記憶装置３のフラッシュメモリ３４において、図８に示すようにクラスタＣＬ内のサウンドユニットＳＵ（０）の直前に記憶される。
【００７９】
なお、コンピュータ２あるいはＣＤプレーヤ７から入力したオーディオデータ（平文）は、ＡＴＲＡＣ(Adaptive TRansform Audio Coder)方式を改良したＡＴＲＡＣ３方式で圧縮されている。なお、ＡＴＲＡＣは、ＭＤ(Mini Disk：商標) のための符号化圧縮方式であり、例えば、２８８ｋｂｉｔ／ｓで４４．１ｋＨｚサンプルのステレオ信号が、帯域分割とＭＤＣＴ(Modified Discrete Cosine Transform)とを併用して符号化されている。すなわち、先ず、帯域分割フィルタで１／４，１／４，１／２の３つの帯域に分割され、それぞれの帯域の信号がダウンサンプルされ、時間領域の信号としてＭＤＣＴで周波数領域に変換され、当該ＭＤＣＴの係数が適応ビット配分を行ってスカラ量子化されている。
【００８０】
暗号化／復号ユニット６４は、ＦＩＰＳ８１のモードのうち、前述したＥＣＢモードおよびＣＢＣモードの復号を選択的に行う。ここで、暗号化／復号ユニット６４は、ＣＢＣモードにおいて、５６ビットの鍵データｋを用いて、暗号文を、６４ビットからなる暗号化ブロックを単位として下記式（３）に基づいて復号して平文を生成する。
【００８１】
【数３】
Ｐi ＝Ｃi-1 ＸＯＲ Ｄk （Ｃi ） ・・・（３）
ｉ：１以上の整数
Ｐi ：平文（６４ビット）
Ｃi ：暗号文（６４ビット）
ＸＯＲ：排他的論理和
Ｄk ：５６ビットの鍵データｋを用いたＤＥＳ方式の復号処理
上記式（３）の演算は、図１９で表現される。なお、図１９において、「ＩＶ」は、ブロック暗号化初期値（６４ビット）であり、図２に示す携帯用記憶装置３のフラッシュメモリ３４において図８に示すようにクラスタＣＬ内のサウンドユニットＳＵ（０）の直前に記憶されたものが用いられる。
【００８２】
制御ユニット６５は、乱数発生ユニット６０、記憶ユニット６１、鍵生成／鍵演算ユニット６２、相互認証ユニット６３および暗号化／復号ユニット６４の処理を統括的に制御する。
【００８３】
〔編集モジュール４４〕
編集モジュール４４は、例えば、図４に示すように携帯用記憶装置３のフラッシュメモリ３４内に記憶されたトラックデータファイル１０１0 〜１０１3 を、ユーザからの操作指示に基づいて編集して新たなトラックデータファイルを生成する。当該編集には、１個のトラックデータファイルを分割して２個のトラックデータファイルを生成する分割編集処理と、２個のトラックデータファイルを結合して１個のトラックデータファイルを生成する結合編集処理とがある。なお、当該編集にあたって、再生管理ファイル１００およびトラックデータファイル１０１0 〜１０１3 が書き換えられる。編集モジュール４４における編集処理については後に詳細に説明する。
【００８４】
〔圧縮／伸長モジュール４５〕
圧縮／伸長モジュール４５は、例えば、携帯用記憶装置３から入力した暗号化されたオーディオデータを復号した後に再生する際に、ＡＴＲＡＣ３方式で圧縮されているオーディオデータを伸長し、当該伸長したオーディオデータをＤ／Ａ変換器４７に出力する。また、例えば、ＣＤプレーヤ７あるいはコンピュータ２から入力したオーディオデータを、携帯用記憶装置３に記憶する際に、当該オーディオデータをＡＴＲＡＣ３方式で圧縮する。
【００８５】
〔Ｄ／Ａ変換器４７〕
Ｄ／Ａ変換器４７は、圧縮／伸長モジュール４５から入力したデジタル形式のオーディオデータをアナログ形式のオーディオデータに変換してスピーカ４６に出力する。
【００８６】
〔スピーカ４６〕
スピーカ４６は、Ｄ／Ａ変換器４７から入力したオーディオデータに応じた音響を出力する。
【００８７】
〔Ａ／Ｄ変換器４８〕
Ａ／Ｄ変換器４８は、例えば、ＣＤプレーヤ７から入力したアナログ形式のオーディオデータをデジタル形式に変換して圧縮／伸長モジュール４５に出力する。
【００８８】
以下、図１に示すオーディオシステム１の動作について説明する。
【００８９】
携帯用記憶装置３への書き込み動作
図２０は、携帯用プレーヤ４から携帯用記憶装置３への書き込み動作を説明するためのフローチャートである。
【００９０】
ステップＳ１：携帯用プレーヤ４から携帯用記憶装置３に、書き込み要求信号が出力される。
【００９１】
ステップＳ２：携帯用記憶装置３と携帯用プレーヤ４との間で、相互認証処理を行う際に用いる認証鍵データＩＫj の選択処理が行われる。当該処理については後述する。
【００９２】
ステップＳ３：携帯用記憶装置３と携帯用プレーヤ４との間で相互認証処理が行われる。当該処理については後述する。
【００９３】
ステップＳ４：ステップＳ３の相互認証処理によって携帯用記憶装置３および携帯用プレーヤ４の双方が相手を正当であると認めた場合には、ステップＳ５の処理が行われ、そうでない場合には処理が終了する。
【００９４】
ステップＳ５：携帯用記憶装置３および携帯用プレーヤ４において、セッション鍵データＳｅｋが生成される。当該処理については後述する。
【００９５】
ステップＳ６：携帯用プレーヤ４から携帯用記憶装置３に、通信インターフェイス３２，４２を介して、暗号化したオーディオデータを出力して書き込む。当該処理については後述する。
【００９６】
このように、オーディオシステム１によれば、携帯用記憶装置３と携帯用プレーヤ４との間で相互認証が行われ、双方が相手を正当であると認めた場合にのみ、携帯用プレーヤ４から携帯用記憶装置３に、暗号化されたオーディオデータが書き込まれる。そのため、著作権侵害を招くようなオーディオデータの不正な複製が容易に行われることを回避できる。
【００９７】
〔認証鍵データＩＫj の選択処理（図２０に示すステップＳ２）〕
図２１は、認証鍵データＩＫj の選択処理を説明するための図である。図２１に示すように、図２に示す携帯用プレーヤ４の乱数発生ユニット６０によって６４ビットの乱数Ｒj が生成される。当該乱数Ｒj は、携帯用プレーヤ４から携帯用記憶装置３に出力される。そして、携帯用記憶装置３の相互認証ユニット５３によって、６４ビットの乱数Ｒj の下位５ビットを用いて、記憶ユニット５１に記憶されている認証鍵データＩＫ0 〜ＩＫ31のうち一の認証鍵データＩＫj （ｊは０≦ｊ≦３１を満たす整数）が特定される。
【００９８】
また、携帯用記憶装置３の記憶ユニット５１から読み出された装置識別データＩＤm が、携帯用記憶装置３から携帯用プレーヤ４に出力される。
【００９９】
そして、携帯用プレーヤ４の相互認証ユニット６３によって、乱数Ｒj の下位５ビットを用いて、マスター鍵データＭＫ0 〜ＭＫ31のうち一のマスター鍵データＭＫj が特定される。
【０１００】
そして、鍵生成／鍵演算ユニット６２において、前記特定されたマスター鍵データＭＫj と、携帯用記憶装置３から入力した装置識別データＩＤm とを用いて、下記式（４）に基づいて、認証鍵データＩＫj を生成する。下記式（４）において、ｆ（ａ，ｂ）は、例えば、引数ａ，ｂから値を導出する任意の関数である。
【０１０１】
【数４】
ＩＫj ＝ｆ（ＭＫj ，ＩＤm ） ・・・（４）
これにより、携帯用記憶装置３と携帯用プレーヤ４とが、上記式（４）に示す関係を持つ認証鍵データＩＫ0 〜ＩＫ31およびマスター鍵データＭＫ0 〜ＭＫ31を有している場合には、図２１に示す処理によって同じ認証鍵データＩＫj が選択される。当該選択された認証鍵データＩＫj は、後述する相互認証処理を行う際に、秘密鍵として用いられる。また、このとき、３２個の認証鍵データＩＫj のうち選択される認証鍵データは、図２１に示す処理を行う毎に乱数Ｒj に応じてランダムに決定される。そのため、不正な認証が成功する確率を、一の認証鍵データを固定して用いる場合の１／３２倍にすることができ、不正な認証が行われることを高い確率で回避できる。
【０１０２】
なお、上述した実施形態では、乱数を用いて８個の認証鍵データＩＫj のうち一の認証鍵データを選択する場合を例示したが、携帯用記憶装置３および携帯用プレーヤ４の外部から入力した鍵指定信号に基づいて選択する認証鍵データを決定してもよい。
【０１０３】
〔携帯用記憶装置３と携帯用プレーヤ４との間の相互認証処理（図２０に示すステップＳ３）〕
図２２は、携帯用記憶装置３と携帯用プレーヤ４との間の相互認証処理を説明するための図である。なお、当該相互認証処理を開始するときには、前述した図２１に示す認証鍵データＩＫj の選択処理が終了しており、携帯用プレーヤ４の相互認証ユニット５３と携帯用記憶装置３の相互認証ユニット６３は、選択した認証鍵データＩＫj 、携帯用記憶装置３の装置識別データＩＤm を有している。
【０１０４】
ステップＳ１０：携帯用記憶装置３の乱数発生ユニット５０において、６４ビットの乱数Ｒmsを生成し、これを携帯用プレーヤ４に出力する。
【０１０５】
ステップＳ１１：携帯用プレーヤ４の乱数発生ユニット６０において、６４ビットの乱数Ｒd およびＳd を生成する。
【０１０６】
ステップＳ１２：携帯用プレーヤ４の相互認証ユニット６３において、図２０に示すステップＳ２で得た認証鍵データＩＫj および「Ｒd ‖Ｒms‖ＩＤm 」を用いて、下記式（５）に基づいてＭＡＣ演算を行い、ＭＡＣA を求める。
【０１０７】
ここで、Ａ‖Ｂは、ＡとＢの連結（ｎビットのＡの後ろにｍビットのＢを結合して（ｎ＋ｍ）ビットとしたもの）を示す。
【０１０８】
【数５】
ＭＡＣA ＝ＭＡＣ（ＩＫj ，Ｒd ‖Ｒms‖ＩＤm ） ・・・（５）
ステップＳ１３：携帯用プレーヤ４は、「Ｒd ‖Ｓd ‖ＭＡＣA ‖ｊ」を携帯用記憶装置３に出力する。
【０１０９】
ステップＳ１４：携帯用記憶装置３の相互認証ユニット５３において、図２０に示すステップＳ２で得た認証鍵データＩＫj および「Ｒd ‖Ｒms‖ＩＤm 」を用いて、下記式（６）に基づいてＭＡＣ演算を行い、ＭＡＣB を求める。
【０１１０】
【数６】
ＭＡＣB ＝ＭＡＣ（ＩＫj ，Ｒd ‖Ｒms‖ＩＤm ） ・・・（６）
ステップＳ１５：携帯用記憶装置３の相互認証ユニット５３において、ステップＳ１４で求めたＭＡＣB とステップＳ１３で入力したＭＡＣA とを比較し、一致していれば、携帯用プレーヤ４が適切な認証鍵データＩＫj を有していることが分かるため、携帯用記憶装置３は携帯用プレーヤ４が正当な相手であると認証する。
【０１１１】
ステップＳ１６：携帯用記憶装置３の相互認証ユニット５３において、図２０に示すステップＳ２で得た認証鍵データＩＫj および「Ｒms‖Ｒd 」を用いて、下記式（７）に基づいてＭＡＣ演算を行い、ＭＡＣC を求める。
【０１１２】
【数７】
ＭＡＣC ＝ＭＡＣ（ＩＫj ，Ｒms‖Ｒd ） ・・・（７）
ステップＳ１７：携帯用記憶装置３の乱数発生ユニット５０において、６４ビットの乱数Ｓmsを生成する。
【０１１３】
ステップ１８：携帯用記憶装置３から携帯用プレーヤ４に、「Ｓms‖ＭＡＣC 」を出力する。
【０１１４】
ステップＳ１９：携帯用プレーヤ４の相互認証ユニット６３において下記式（８）に基づいてＭＡＣ演算を行い、ＭＡＣd を求める。
【０１１５】
【数８】
ＭＡＣd ＝ＭＡＣ（ＩＫj ，Ｒms‖Ｒd ） ・・・（８）
ステップＳ２０：携帯用プレーヤ４の相互認証ユニット６３において、ステップＳ１９で求めたＭＡＣd とステップＳ１８で入力したＭＡＣC とを比較し、一致していれば、携帯用記憶装置３が適切な認証鍵データＩＫj を有していることが分かるため、携帯用プレーヤ４は携帯用記憶装置３が正当な相手であると認証する。以上の処理によって、携帯用記憶装置３と携帯用プレーヤ４との間の相互認証が行われる。
【０１１６】
〔セッション鍵データＳｅｋの生成処理（図２０に示すステップＳ５）〕
図２３は、セッション鍵データＳｅｋの生成処理を説明するための図である。なお、当該セッション鍵データＳｅｋの生成処理を開始するときには、前述した図２１に示す認証鍵データＩＫj の選択処理および図２２に示す相互認証処理が終了しており、携帯用記憶装置３および携帯用プレーヤ４の双方は、選択した認証鍵データＩＫj および乱数Ｓd ，Ｓmsを有している。
【０１１７】
ステップＳ３０：携帯用プレーヤ４の相互認証ユニット６３は、選択した認証鍵データＩＫj および「Ｓd ‖Ｓms」を用いて、下記式（９）に基づいてＭＡＣ演算を行い、セッション鍵データＳｅｋを生成する。
【０１１８】
【数９】
セッション鍵データＳｅｋ＝ＭＡＣ（ＩＫj ，Ｓd ‖Ｓms） ・・・（９）
ステップＳ３１：携帯用記憶装置３の相互認証ユニット５３は、選択した認証鍵データＩＫj および「Ｓd ‖Ｓms」を用いて、下記式（１０）に基づいてＭＡＣ演算を行い、セッション鍵データＳｅｋを生成する。当該セッション鍵データＳｅｋは、正当な相手同士であれば、携帯用プレーヤ４で生成したセッション鍵データＳｅｋと同じになる。
【０１１９】
【数１０】
セッション鍵データＳｅｋ＝ＭＡＣ（ＩＫj ，Ｓd ‖Ｓms） ・・・（１０）
〔携帯用記憶装置３へのオーディオデータの書き込み処理（図２０に示すステップＳ６）〕
図２４は、携帯用プレーヤ４から携帯用記憶装置３へのオーディオデータの書き込み処理を説明するための図である。なお、当該書き込み処理を開始するときには、前述した図２３に示すセッション鍵データＳｅｋの生成処理は終了しており、携帯用記憶装置３および携帯用プレーヤ４は同じセッション鍵データＳｅｋを有している。
【０１２０】
ステップＳ４０：携帯用プレーヤ４は、乱数発生ユニット６０にトラックデータファイル毎に乱数を発生させ、当該乱数に応じたコンテンツ鍵データＣＫを生成する。
【０１２１】
ステップＳ４１：携帯用プレーヤ４は、暗号化／復号ユニット６４において、ステップＳ４０で生成したコンテンツ鍵データＣＫを、セッション鍵データＳｅｋを用いて暗号化する。
【０１２２】
ステップ４２：携帯用プレーヤ４は、ステップＳ４１で暗号化したコンテンツ鍵データＣＫを携帯用記憶装置３に出力する。
【０１２３】
ステップＳ４３：携帯用記憶装置３は、ステップＳ４２で入力した暗号化されたコンテンツ鍵データＣＫを、暗号化／復号ユニット５４において復号する。
【０１２４】
ステップＳ４４：携帯用記憶装置３は、暗号化／復号ユニット５４において、ステップＳ４３で復号したコンテンツ鍵データＣＫを、記憶ユニット５１から読み出した記憶用鍵データＳＫm を用いて暗号化する。
【０１２５】
ステップＳ４５：携帯用記憶装置３は、当該暗号化されたコンテンツ鍵データＣＫを携帯用プレーヤ４に出力する。
【０１２６】
ステップＳ４６：携帯用プレーヤ４は、当該暗号化されたコンテンツ鍵データＣＫを、トラックデータファイル１００ｎ内のＴＲＫＩＮＦ内に設定する。
【０１２７】
ステップＳ４７：携帯用プレーヤ４は、乱数発生ユニット６０にパーツ毎に乱数を発生させ、当該乱数に応じたパーツ鍵データＰＫを生成する。また、携帯用プレーヤ４は、当該生成したパーツ鍵データＰＫを、トラックデータファイル１０１ｎの管理データＰＲＴＩＮＦ内に設定する。
【０１２８】
ステップＳ４８：携帯用プレーヤ４は、例えば、パーツ毎に、鍵生成／演算ユニット６２において、下記式（１１）に示すように、ステップＳ４７で生成したパーツ鍵データＰＫとコンテンツ鍵データＣＫとの排他的論理和を演算し、当該演算結果をテンポラリ鍵データＴＭＫとする。なお、テンポラリ鍵データＴＭＫの生成は、排他的論理和を用いるものには限定されず、例えば、パーツ鍵データＰＫとコンテンツ鍵データＣＫとを加算する加算演算やその他の関数演算を用いるようにしてもよい。
【０１２９】
【数１１】
ＴＭＫ＝ＰＫ ＸＯＲ ＣＫ ・・・（１１）
ステップＳ４９：携帯用プレーヤ４は、乱数発生ユニット６０にブロック毎に乱数を発生させ、当該乱数に応じたブロックシードデータＢＳを生成する。また、携帯用プレーヤ４は、当該生成したブロックシードデータＢＳを、当該ブロック内の図１０に示す対応する位置に設定する。
【０１３０】
ステップＳ５０：携帯用プレーヤ４は、例えば、鍵生成／鍵演算ユニット６２において、下記式（１２）に示すように、ステップＳ４６で生成したテンポラリ鍵データＴＭＫと、ステップＳ４７で生成したブロックシードデータＢＳとを用いてＭＡＣ演算を行い、ブロック毎にブロック鍵データＢＫを生成する。
【０１３１】
【数１２】
ＢＫ＝ＭＡＣ（ＴＭＫ，ＢＳ） ・・・（１２）
なお、ＭＡＣ演算の他に、例えば、ＳＨＡ−１(Secure Hash Algorithm) 、ＲＩＰＥＭＤ−１６０などの一方向性ハッシュ関数(one-way hash function) の入力に秘密鍵を用いた演算を行ってブロック鍵データＢＫを生成してもよい。
【０１３２】
ここで、一方向性関数ｆとは、ｘよりｙ＝ｆ（ｘ）を計算することは容易であるが、逆にｙよりｘを求めることが難しい関数をいう。一方向性ハッシュ関数については、例えば、"Handbook of Applied Cryptography,CRC Press"などに詳しく記述されている。
【０１３３】
ステップＳ５１：携帯用プレーヤ４は、コンピュータ２あるいは携帯用プレーヤ４から入力したオーディオデータを、圧縮／伸長モジュール４５において、ＡＴＲＡＣ３方式で圧縮する。そして、暗号化／復号ユニット６４において、ステップＳ５０で生成したブロック鍵データＢＫを用いて、前記圧縮したオーディオデータをＣＢＣモードで暗号化する。
【０１３４】
ステップＳ５２：携帯用プレーヤ４は、ステップＳ５１で暗号化したオーディオデータに属性ヘッダを付加して、通信インターフェイス３２，４２を介して、携帯用記憶装置３に出力する。
【０１３５】
ステップＳ５３：携帯用記憶装置３は、ステップＳ５２で入力した暗号化されたオーディオデータと属性ヘッダを、フラッシュメモリ３４にそのまま書き込む。以上の処理によって、携帯用プレーヤ４から携帯用プレーヤ４へのオーディオデータの書き込み処理が終了する。なお、ここでは、図４のトラックデータファイル１０１0 〜１０１3 についてのみ述べたが、携帯用プレーヤ４は、図４の再生管理ファイルについても同様に適宜更新を行う。
【０１３６】
携帯用記憶装置３からの読み出し動作
図２５は、携帯用記憶装置３から携帯用プレーヤ４への読み出し動作を説明するためのフローチャートである。
【０１３７】
ステップＳ６１：携帯用プレーヤ４から携帯用記憶装置３に、読み出しを要求するトラックデータ（曲）を特定した読み出し要求信号が出力される。
【０１３８】
ステップＳ２：図２１を用いて前述したように、携帯用記憶装置３と携帯用プレーヤ４との間で相互認証処理を行う際に用いる認証鍵データＩＫj の選択処理が行われる。
【０１３９】
ステップＳ３：図２２を用いて前述したように、携帯用記憶装置３と携帯用プレーヤ４との間で相互認証処理が行われる。
【０１４０】
ステップＳ４：ステップＳ３の相互認証処理によって携帯用記憶装置３および携帯用プレーヤ４の双方が相手を正当であると認めた場合には、ステップＳ５の処理が行われ、そうでない場合には処理が終了する。
【０１４１】
ステップＳ５：携帯用記憶装置３および携帯用プレーヤ４において、セッション鍵データＳｅｋが生成される。
【０１４２】
ステップＳ６３：暗号化されたオーディオデータを、通信インターフェイス３２，４２を介して、携帯用記憶装置３から携帯用プレーヤ４に読み出す。当該処理については後述する。
【０１４３】
すなわち、オーディオシステム１では、携帯用記憶装置３と携帯用プレーヤ４との間で相互認証が行われ、双方が相手を正当であると認めた場合にのみ、後述するように、携帯用プレーヤ４において、携帯用記憶装置３から携帯用プレーヤ４に出力された暗号化されたコンテンツ鍵データＣＫを適切なセッション鍵データＳｅｋで解読できる。そのため、著作権侵害を招くようなオーディオデータの不正な利用が容易に行われることを回避できる。
【０１４４】
〔携帯用記憶装置３からのオーディオデータの読み出し処理（図２５に示すステップＳ６３）〕
図２６は、携帯用記憶装置３から携帯用プレーヤ４へのオーディオデータの読み出し処理を説明するための図である。なお、当該読み出し処理は、前述した図２０に示す書き込み処理の後に行われるため、図４に示すトラックデータファイル１０１0 〜１０１3 には、図１０に示すように、ＴＲＩＮＦにコンテンツ鍵データＣＫが設定され、パーツ毎にパーツ鍵データＰＫが設定され、各クラスタＣＬ内にはブロックシードデータＢＳが設定されている。また、ステップＳ５の処理が終了しているため、携帯用記憶装置３および携帯用プレーヤ４は、正当な相手同士であれば、同じセッション鍵データＳｅｋを有している。
【０１４５】
ステップＳ７１：携帯用記憶装置３は、フラッシュメモリ３４に記憶されている図４に示すトラックデータファイル１０１0 〜１０１3 のうち読み出し要求信号で特定されるトラックデータに対応するトラックデータファイルを特定し、当該特定したトラックデータファイルを構成するクラスタ内のオーディオデータを、サウンドユニットＳＵを単位として読み出して携帯用プレーヤ４に出力する。携帯用記憶装置３は、また、上記トラックデータファイルの属性ヘッダを読み出して携帯用プレーヤ４に出力する。
【０１４６】
ステップＳ７２：携帯用プレーヤ４は、当該入力された属性ヘッダのうち、ＴＲＩＮＦから暗号化されたコンテンツ鍵ＣＫを抽出し、携帯用記憶装置３に出力する。
【０１４７】
ステップＳ７３：携帯用記憶装置３の暗号化／復号ユニット５４は、ステップＳ７２で入力されたコンテンツ鍵データＣＫを、記憶ユニット５１に記憶されている記憶用鍵データＳＫm を用いて復号する。
【０１４８】
ステップＳ７４：携帯用記憶装置３の暗号化／復号ユニット５４は、ステップＳ７３で復号したコンテンツ鍵データＣＫを、図２５に示すステップＳ５で得られたセッション鍵データＳｅｋを用いて暗号化する。
【０１４９】
ステップＳ７５：携帯用記憶装置３は、ステップＳ７４で暗号化したコンテンツ鍵データＣＫを携帯用プレーヤ４に出力する。
【０１５０】
ステップＳ７６：携帯用プレーヤ４の暗号化／復号ユニット６４は、ステップＳ７３で携帯用記憶装置３から入力したコンテンツ鍵データＣＫを、セッション鍵データＳｅｋを用いて復号する。
【０１５１】
ステップＳ７７：携帯用プレーヤ４の鍵生成／演算ユニット６２は、ステップＳ７６で復号されたコンテンツ鍵データＣＫと、ステップＳ７１で入力された属性ヘッダの中のＰＲＴＩＮＦに含まれるパーツ鍵データＰＫとの排他的論理和を演算し、当該演算結果をテンポラリ鍵データＴＭＫとする。
【０１５２】
【数１３】
ＴＭＫ＝ＰＫ ＸＯＲ ＣＫ ・・・（１３）
ステップＳ７８：携帯用プレーヤ４の鍵生成／鍵演算ユニット６２において、ステップＳ７６で生成したテンポラリ鍵データＴＭＫと、ステップＳ７１で入力されたトラックデータファイルのクラスタ内の図１０に示すブロックシードデータＢＳとを用いて、下記式（１４）に示すＭＡＣ演算を行い、当該演算結果をブロック鍵データＢＫとする。ブロック鍵データＢＫは、ブロック毎に求められる。
【０１５３】
【数１４】
ＢＫ＝ＭＡＣ（ＴＭＫ，ＢＳ） ・・・（１４）
ステップＳ７９：携帯用プレーヤ４は、暗号化／復号ユニット６４において、ステップＳ７８で生成したブロック鍵データＢＫを用いて、ステップＳ７１で入力したオーディオデータを復号する。このとき、オーディオデータの復号は、各ブロック毎に、それそれ個別に求められたブロック鍵データＢＫを用いて行われる。また、復号は、暗号化の単位である８バイトのブロックを単位として行われる。
【０１５４】
ステップＳ８０：携帯用プレーヤ４は、圧縮／伸長モジュール４５において、ステップＳ７９で復号したオーディオデータをＡＴＲＡＣ３方式で伸長し、当該伸長したオーディオデータを、Ｄ／Ａ変換器４７でデジタル形式に変換した後に、スピーカ４６に出力する。このとき、圧縮／伸長モジュール４５は、ステップＳ７８で復号したオーディオデータを、サウンドユニットＳＵを単位として伸長する。以上の処理によって、携帯用記憶装置３から携帯用プレーヤ４４へのオーディオデータの読み出しおよび再生が終了する。
【０１５５】
〔トラックデータファイルの分割編集処理〕
前述したように、携帯用プレーヤ４の編集モジュール４４は、１個のトラックデータファイルを分割して２個のトラックデータファイルを生成する分割編集処理と、２個のトラックデータファイルを結合して１個のトラックデータファイルを生成する結合編集処理とを行う。
【０１５６】
先ず、分割編集処理について説明する。図２７は、携帯用プレーヤ４の編集モジュール４４によるトラックデータファイルの分割編集処理を説明するための図である。編集モジュール４４は、例えば、図２７Ａに示す１個のトラックデータファイル（１）を、図２７Ｂに示すトラックデータファイル（１）と、図２７Ｃに示すトラックデータファイル（２）とに分割する。このとき、分割の区切りとなる最小単位はサウンドユニットＳＵであり、当該例では、図２７Ｂに示すように、トラックデータファイル（１）のクラスタＣＬ（２）のサウンドユニットＳＵ（３）とＳＵ（４）との間で分割されている。
【０１５７】
当該分割により、分割後のトラックデータファイル（１）のクラスタＣＬ（２）は図２８Ａに示すようになり、新たに生成されたトラックデータファイル（２）のクラスタＣＬ（０）は図２８Ｂに示すようになる。このとき、図２８Ｂに示すように、トラックデータファイル（２）のクラスタＣＬ（０）のサウンドユニットＳＵ（０）は分割前のトラックデータファイル（１）のクラスタ（２）のサウンドユニットＳＵ（４）となり、ラックデータファイル（２）のクラスタＣＬ（０）のサウンドユニットＳＵ（１）は分割前のトラックデータファイル（１）のクラスタ（２）のサウンドユニットＳＵ（５）となる。また、図２８Ｂに示すトラックデータファイル（２）のクラスタＣＬ（０）のブロック暗号化初期値ＩＶには、図２７Ａ，Ｂに示すトラックデータファイル（１）のクラスタＣＬ（２）内のサウンドユニットＳＵ（３）の最後の８バイトが設定される。
【０１５８】
本実施形態では、前述したように各クラスタ内において、最初のサウンドユニットＳＵ（０）の直前にブロック暗号化初期値ＩＶを配置したことで、分割の際に、分割位置の直前の８バイトをそのままブロック暗号化初期値ＩＶとして用いれば良く、新たなトラックデータファイルを作成する際の処理を簡単にできる。また、再生時に、サウンドユニットＳＵ（０）と共に、その直前のブロック暗号化初期値ＩＶを読み出せばよいため、再生処理も簡単になる。
【０１５９】
本実施形態では、分割前のトラックデータファイル（１）のコンテンツ鍵データ、パーツ鍵データおよびブロック鍵データは、それぞれＣＫ＿１、ＰＫ＿１およびＢＫ＿１である。また、分割後のトラックデータファイル（１）のコンテンツ鍵データ、パーツ鍵データおよびブロック鍵データは、それぞれＣＫ＿１’、ＰＫ＿１’およびＢＫ＿１である。また、トラックデータファイル（２）のコンテンツ鍵データ、パーツ鍵データおよびブロック鍵データは、それぞれＣＫ＿２、ＰＫ＿２およびＢＫ＿１である。
【０１６０】
図２９は、携帯用プレーヤ４の編集モジュール４４において、新たなトラックデータファイル（２）のコンテンツ鍵データおよびパーツ鍵データを生成する方法を説明するための図である。分割により生成された新たなトラックデータファイル（２）は、トラックデータファイル（１）とは別に新たなコンテンツ鍵データＣＫ＿２を有する。本実施形態では、パーツ鍵データＰＫ＿２を以下に示すように算出することで、ブロック鍵データＢＫ＿１を分割前と同じにする。
【０１６１】
ステップＳ９０：編集モジュール４４は、トラックデータファイルの分割指示を入力したか否かを判断し、入力したと判断した場合にはステップＳ９１の処理を実行し、入力していないと判断した場合にはステップＳ９０の処理を繰り返す。
【０１６２】
ステップＳ９１：編集モジュール４４は、乱数発生ユニット６０に乱数を発生させ、当該乱数に応じたコンテンツ鍵データＣＫ＿２を新たに生成する。
【０１６３】
ステップＳ９２：携帯用記憶装置３の暗号化／復号ユニット５４において、ステップＳ９１で生成したコンテンツ鍵データＣＫ＿２を、記憶ユニット５１に記憶されている記憶用鍵データＳＫm を用いて暗号化する。
【０１６４】
ステップＳ９３：編集モジュール４４は、当該暗号化されたコンテンツ鍵データＣＫ＿２を、当該トラックデータファイルのＴＲＫＩＮＦに書き込む。
【０１６５】
ステップＳ９４：編集モジュール４４は、トラックデータファイル（２）のパーツ鍵データＰＫ＿２を下記式（１５）に基づいて生成する。
【０１６６】
【数１５】
ＰＫ＿２＝ＣＫ＿１ ＸＯＲ ＰＫ＿１ ＸＯＲ ＣＫ＿２・・・（１５）
これにより、トラックデータファイル（２）について、前記式（１１）に基づいてされるテンポラリ鍵データは、トラックデータファイル（１）のテンポラリ鍵データと同じになり、前記式（１２）に基づいて生成されるブロック鍵データも分割前のブロック鍵データＢＫ＿１と同じにできる。そのため、トラックデータファイル（２）内のサウンドユニットＳＵを新たなブロック鍵データを用いて再度暗号化する必要がない。
【０１６７】
ステップＳ９５：編集モジュール４４は、ステップＳ９４で生成したパーツ鍵データＰＫ＿２を、当該トラックデータファイルＰＲＴＩＮＦにそのまま書き込む。
【０１６８】
このように、オーディオシステム１では、分割して新たに生成したトラックデータファイル（２）のコンテンツ鍵データとして、新たなコンテンツ鍵データＣＫ＿２を用いた場合でも、上記式（１５）に基づいてパーツ鍵データＰＫ＿２を生成することで、テンポラリ鍵データを分割前のテンポラリ鍵データと同じにできる。その結果、ブロック鍵データも分割前のブロック鍵データＢＫ＿１と同じにでき、トラックデータファイル（２）内のサウンドユニットＳＵを新たなブロック鍵データを用いて再度暗号化する必要がない。また、同様に、分割後のトラックデータファイル（１）のパーツ鍵データＰＫ＿１’も、ブロック鍵データＢＫ＿１を変えないように、コンテンツ鍵データＣＫ＿１’に応じた決定される。その結果、分割後のトラックデータファイル（１）内のサウンドユニットＳＵを新たなブロック鍵データを用いて再度暗号化する必要もない。そのため、トラックデータファイルの分割編集に伴い演算量が大幅に増加することを回避できる。なお、ここでは、図４のトラックデータファイルについてのみ述べたが、編集モジュール４４は、図４の再生管理ファイル１００についても同様に適宜更新を行う。
【０１６９】
次に、トラックデータファイルの結合編集処理について説明する。図３０は、携帯用プレーヤ４の編集モジュール４４によるトラックデータファイルの結合編集処理を説明するための図である。図３０に示すように、編集モジュール４４は、例えば、図３０Ａに示すトラックデータファイル（１）と、図３０Ｂに示すトラックデータファイル（２）とを結合して、図３０Ｃに示すトラックデータファイル（３）を生成する。
【０１７０】
当該結合により、結合前のトラックデータファイル（１）からなるパーツ（１）と、結合前のトラックデータファイル（２）からなるパーツ（２）とを含む新たなトラックデータファイル（３）が生成される。また、トラックデータファイル（３）のコンテンツ鍵データとして新たなコンテンツ鍵データＣＫ＿３が生成され、パーツ（１）のパーツ鍵データＰＫ＿３＿１およびパーツ（２）のパーツ鍵データＰＫ＿３＿２が後述するようにして新たに生成される。また、当該トラックデータファイル（３）のＴＲＫＩＮＦおよびＰＲＴＩＮＦに、新たに生成された鍵データが後述するように設定される。
【０１７１】
また、パーツ（１）の図６に示すＰＲＴＳＩＺＥが示す開始クラスタおよび終了クラスタとして、結合前のトラックデータファイル（１）のクラスタＣＬ（０）およびＣＬ（４）がそれぞれ設定される。また、パーツ（２）のＰＲＴＳＩＺＥが示す開始クラスタおよび終了クラスタとして、結合前のトラックデータファイル（２）のクラスタＣＬ（０）およびＣＬ（５）がそれぞれ設定される。
【０１７２】
図３１は、携帯用プレーヤ４の編集モジュール４４において、新たに生成したトラックデータファイル（３）のパーツ（１）および（２）のパーツ鍵データを生成する処理を説明するための図である。なお、本実施形態では、結合の対象となるトラックデータファイル（１）がコンテンツ鍵データＣＫ＿１、パーツ鍵データＰＫ＿１およびブロック鍵データＢＫ＿１を用いており、トラックデータファイル（２）がコンテンツ鍵データＣＫ＿２、パーツ鍵データＰＫ＿２およびブロック鍵データＢＫ＿２を用いてる場合を例示して説明する。
【０１７３】
ここで、トラックデータファイル（３）は新たなコンテンツ鍵データＣＫ＿３を得るが、パーツ（１）および（２）のパーツ鍵データを以下に示すように算出することで、各ブロックのブロック鍵データＢＫ＿１およびＢＫ＿２を結合前と同じにできる。
【０１７４】
ステップＳ１００：編集モジュール４４は、トラックデータファイルの結合指示を入力したか否かを判断し、入力したと判断した場合にはステップＳ１０１の処理を実行し、入力していないと判断した場合にはステップＳ１００の処理を繰り返す。
【０１７５】
ステップＳ１０１：編集モジュール４４は、乱数発生ユニット６０に乱数を発生させ、当該乱数に応じたコンテンツ鍵データＣＫ＿３を新たに生成する。
【０１７６】
ステップＳ１０２：携帯用記憶装置３の暗号化／復号ユニット５４において、ステップＳ１０１で生成したコンテンツ鍵データＣＫ＿３を、記憶ユニット５１に記憶されている記憶用鍵データＳＫm を用いて暗号化する。
【０１７７】
ステップＳ１０３：編集モジュール４４は、当該暗号化されたコンテンツ鍵データＣＫ＿３を当該トラックデータファイルのＴＲＫＩＮＦに書き込む。
【０１７８】
ステップＳ１０４：編集モジュール４４は、トラックデータファイル（３）のパーツ（１）のパーツ鍵データＰＫ＿３＿１を下記式（１６）に基づいて生成する。
【０１７９】
【数１６】
ＰＫ＿３＿１＝ＣＫ＿１ ＸＯＲ ＰＫ＿１ ＸＯＲ ＣＫ＿３・・・（１６）
これにより、前記式（１１）に基づいて生成されるパーツ（１）のテンポラリ鍵データを結合前のトラックデータファイル（１）のテンポラリ鍵データと同じにでき、その結果、前記式（１２）に基づいて生成されるパーツ（１）のブロック鍵データも結合前のトラックデータファイル（１）のブロック鍵データＢＫ＿１と同じにできる。そのため、パーツ（１）のサウンドユニットＳＵを新たなブロック鍵データを用いて再度暗号化する必要がない。
【０１８０】
ステップＳ１０５：編集モジュール４４は、トラックデータファイル（３）のパーツ（２）のパーツ鍵データＰＫ＿３＿２を下記式（１７）に基づいて生成する。
【０１８１】
【数１７】
ＰＫ＿３＿２＝ＣＫ＿２ ＸＯＲ ＰＫ＿２ ＸＯＲ ＣＫ＿３・・・（１７）
これにより、前記式（１１）に基づいて生成されるパーツ（２）のテンポラリ鍵データを結合前のトラックデータファイル（２）のテンポラリ鍵データと同じにでき、その結果、前記式（１２）に基づいて生成されるパーツ（２）のブロック鍵データも結合前のトラックデータファイル（２）のブロック鍵データＢＫ＿２と同じにできる。そのため、パーツ（２）のサウンドユニットＳＵを新たなブロック鍵データを用いて再度暗号化する必要がない。
【０１８２】
ステップＳ１０６：編集モジュール４４は、ステップＳ１０４で生成したパーツ鍵データＰＫ＿３＿１をトラックデータファイル（３）のパーツ（１）のＰＲＴＩＮＦにそのまま書き込む。
【０１８３】
ステップＳ１０７：編集モジュール４４は、ステップＳ１０５で生成したパーツ鍵データＰＫ＿３＿２をトラックデータファイル（３）のパーツ（２）のＰＲＴＩＮＦにそのまま書き込む。
【０１８４】
このように、オーディオシステム１では、結合して新たに生成したトラックデータファイル（３）のコンテンツ鍵データとして、新たなコンテンツ鍵データＣＫ＿３を用いた場合でも、上記式（１６）および（１７）に基づいてパーツ鍵データＰＫ＿３＿１およびＰＫ＿３＿２を生成することで、各パーツのテンポラリ鍵データを結合前と同じにできる。その結果、各パーツのブロック鍵データも結合前のブロック鍵データＢＫ＿１およびＢＫ＿２とそれぞれ同じにでき、パーツ（１）および（２）内のサウンドユニットＳＵを新たなブロック鍵データを用いて再度暗号化する必要がない。そのため、トラックデータファイルの結合編集に伴い演算量が大幅に増加することを回避できる。なお、ここでは、図４のトラックデータファイルについてのみ述べたが、編集モジュール４４は、図４の再生管理ファイルについても同様に適宜更新を行う。
【０１８５】
この発明は、上述した実施形態等に限定されるものでは無く、この発明の要旨を逸脱しない範囲内で様々な変形や応用が可能である。例えば、上述した実施形態では、ＡＴＲＡＣ３方式の圧縮の単位であるサウンドユニットＳＵのバイト数（１６０バイト）が、ＣＢＣモードの暗号化の単位である暗号化ブロックのバイト数（８バイト）の整数倍になる場合を例示したが、この発明は、例えば、整数倍にならない場合には、サウンドユニットＳＵにデータ長調整用のデータであるパディング(padding) を挿入して調整するようにしてもよい。
【０１８６】
また、上述した実施形態では、携帯用記憶装置３と携帯用プレーヤ４との間で相互認証処理を行う場合に、図２２に示すように、先ず始めに携帯用記憶装置３で生成した乱数Ｒmsを携帯用プレーヤ４に出力する場合を例示したが、先ず始めに携帯用プレーヤ４で生成した乱数を携帯用記憶装置３に出力するようにしてもよい。
【０１８７】
また、上述した実施形態では、図２１に示すように、記憶ユニット５１および６１に３２組の認証鍵データおよびマスター鍵データを記憶した場合を例示したが、これらの組の数は２以上であれば任意である。
【０１８８】
また、上述した実施形態では、図２１に示すように、携帯用プレーヤ４において、マスター鍵データＭＫ0 〜ＭＫ31から認証鍵データＩＫ0 〜ＩＫ31を生成する場合を例示したが、携帯用プレーヤ４に、携帯用記憶装置３と同じように、認証鍵データＩＫ0 〜ＩＫ31を記憶し、乱数Ｒj に応じた認証鍵データを選択するようにしてもよい。
【０１８９】
また、上述した実施形態では、図２１に示すように、携帯用記憶装置３および携帯用プレーヤ４において、携帯用プレーヤ４で生成した乱数Ｒj を用いて、認証鍵データＩＫj およびマスタ−鍵データＭＫj を選択する場合を例示したが、携帯用記憶装置３で生成した乱数を用いてもよいし、携帯用記憶装置３および携帯用プレーヤ４の双方で発生した乱数を用いてもよい。
【０１９０】
また、上述した実施形態では、図２１に示すように、携帯用記憶装置３および携帯用プレーヤ４において乱数Ｒj に基づいて認証鍵データＩＫj およびマスタ−鍵データＭＫj を選択する場合を例示したが、この発明は、例えば、携帯用記憶装置３および携帯用プレーヤ４に外部から５ビットの鍵選択指示データを入力し、当該鍵選択指示データで指示される相互に対応する認証鍵データＩＫj およびマスタ−鍵データＭＫj を、携帯用記憶装置３および携帯用プレーヤ４で選択してもよい。
【０１９１】
また、上述した実施形態では、トラックデータとしてオーディオデータを含むデータを例示したが、この発明は、その他、動画像データ、静止画像データ、文書データおよびプログラムデータなどを含むトラックデータをフラッシュメモリ３４に記憶する場合にも適用できる。
【０１９２】
【発明の効果】
以上説明したように、この発明のデータ処理システムおよびその方法によれば、記憶手段に記憶された暗号化されたデータを、所定の処理ブロックを単位として効率的に処理できる。
【図面の簡単な説明】
【図１】この発明の一実施形態のオーディオシステムのシステム構成を示すブロック図である。
【図２】携帯用記憶装置および携帯用プレーヤの内部構成を示すブロック図である。
【図３】携帯用記憶装置内の記憶ユニットに記憶されているデータを説明するための略線図である。
【図４】携帯用記憶装置のフラッシュメモリに記憶されるデータを説明するための略線図である。
【図５】再生管理ファイルのデータ構成を概略的に示す略線図である。
【図６】データファイルのデータ構成を概略的に示す略線図である。
【図７】再生管理ファイルのデータ構成をより詳細に示す略線図である。
【図８】再生管理ファイルの各部分と付加情報領域の構成を示す略線図である。
【図９】携帯用プレーヤの記憶ユニットに記憶されているデータを説明するための略線図である。
【図１０】データファイルのデータ構成をより詳細に示す略線図である。
【図１１】データファイルの属性ヘッダの一部を示す略線図である。
【図１２】データファイルの属性ヘッダの一部を示す略線図である。
【図１３】録音モードの種類と、各録音モードにおける録音時間等を示す略線図である。
【図１４】コピー制御情報を説明するための略線図である。
【図１５】データファイルの属性ヘッダの一部を示す略線図である。
【図１６】データファイルの各データブロックのヘッダを示す略線図である。
【図１７】携帯用プレーヤの記憶ユニットに記憶されているデータを説明するための略線図である。
【図１８】携帯用プレーヤの暗号化／復号ユニットのＣＢＣモードにおける暗号化処理を説明するための略線図である。
【図１９】携帯用プレーヤの暗号化／復号ユニットのＣＢＣモードにおける復号処理を説明するための略線図である。
【図２０】携帯用プレーヤから携帯用記憶装置への書き込み動作を説明するためのフローチャートである。
【図２１】相互認証ユニットによる認証鍵データＩＫj の選択処理を説明するための略線図である。
【図２２】携帯用記憶装置と携帯用プレーヤとの間の相互認証処理を説明するためのフローチャートである。
【図２３】セッション鍵データＳｅｋの生成処理を説明するための略線図である。
【図２４】携帯用プレーヤから携帯用記憶装置へのオーディオデータの書き込み処理を説明するためのフローチャートである。
【図２５】携帯用記憶装置から携帯用プレーヤへの読み出し動作を説明するためのフローチャートである。
【図２６】携帯用記憶装置から携帯用プレーヤへのオーディオデータの読み出し処理を説明するためのフローチャートである。
【図２７】携帯用プレーヤの編集モジュールによるトラックデータファイルの分割編集処理を説明するための略線図である。
【図２８】分割編集処理を行った後のクラスタ内のデータを説明するための略線図である。
【図２９】携帯用プレーヤの編集モジュールにおいて、分割編集時に、新たなトラックデータファイルのコンテンツ鍵データおよびパーツ鍵データを生成する方法を説明するためのフローチャートである。
【図３０】携帯用プレーヤの編集モジュールによるトラックデータファイルの結合編集処理を説明するための略線図である。
【図３１】携帯用プレーヤ４の編集モジュールにおいて、新たに生成したトラックデータファイル（３）のパーツ（１）および（２）のパーツ鍵データを生成する処理を説明するための略線図である。
【符号の説明】
１・・・オーディオシステム、２・・・コンピュータ、３・・・携帯用記憶装置、４・・・携帯用プレーヤ、５・・・ネットワーク、３３，４３・・・制御モジュール、５０，６０・・・乱数発生ユニット、５１，６１・・・記憶ユニット、５２，６２・・・鍵生成／演算ユニット、５３，６３・・・相互認証ユニット、５４，７４・・・暗号化／復号ユニット、５５，６５・・・制御ユニット、３４・・・フラッシュメモリ、４４・・・編集モジュール、４５・・・圧縮／伸長モジュール、４６・・・スピーカ
【発明の属する技術分野】
この発明は、例えば圧縮などの所定の処理ブロックを単位で処理されたデータを所定の暗号化ブロックを単位として暗号化して記憶手段に記憶するデータ処理装置、データ処理手段およびその方法に関する。
【０００２】
【従来の技術】
例えば、著作権侵害となる不正利用を防止するために、オーディオデータなどのデータを所定のデータ長の暗号化ブロックを単位として暗号化して記憶媒体に記憶することがある。この場合に、暗号化しようとするデータは、通常、所定の圧縮処理ブロックを単位として圧縮されていることが多い。
【０００３】
【発明が解決しようとする課題】
ところで、上述したように圧縮されたデータを暗号化して記憶媒体に記録する場合に、圧縮ブロックと暗号化ブロックと通常一致しない。そのため、例えば、圧縮ブロックを単位として記憶媒体からデータを読み出すと暗号化ブロックのうちの一部のブロックのデータが読み出されないことがあり、正確な復号を行えなくなる。このような事態を回避するために、圧縮ブロックおよびおよび暗号化ブロックの双方を考慮して読み出しを行うと、処理が煩雑となる問題がある。
【０００４】
また、記憶媒体に記録したデータを編集する場合などは、例えば圧縮ブロックを単位としてデータの分割および結合などが行われるが、この場合にも、編集後のデータに暗号化ブロックの一部のデータが含まれなくなる可能性が高く、同様に、正確な復号が行えなくなるという問題がある。また、圧縮されていないデータであっても、例えば音楽用のＣＤ(Compact Disc:登録商標 )フォーマットなどのように、所定のブロックを単位として処理が行われる場合にも上述した場合と同様の問題が生じる。
【０００５】
この発明の目的は、上述した従来技術の問題点に鑑みてなされ、例えば圧縮などの所定の処理ブロック単位で処理されたデータを所定の暗号化ブロックを単位として暗号化して記憶媒体に記憶する際に、所定の処理ブロックに基づいた処理と復号処理とを簡単な構成で正確に行うことができるデータ処理装置、データ処理システムおよびその方法を提供することにある。
【０００６】
【課題を解決するための手段】
上述した課題を解決するために、請求項１の発明は、所定のデータ長の暗号化ブロックを単位としてデータを暗号化する暗号化手段と、暗号化ブロックの整数倍のデータ長を持つ処理ブロックを単位としてデータに圧縮処理を行う処理手段と、暗号化したデータを記憶する記憶手段と、一の暗号化ブロックを構成するデータが同じ処理ブロック内に位置するように、暗号化したデータを記憶手段に書き込み、処理ブロックを単位としてデータを記憶手段から読み出す制御手段とを有し、制御手段は、単数または複数の処理ブロックを暗号化された順で記憶手段の連続したアドレスに記憶し、さらに、処理ブロック内の単数または複数の暗号化ブロックを暗号化された順で記憶手段の連続したアドレスに記憶し、クラスタ内で最初に暗号化された処理ブロック内でさらに最初に暗号化された暗号化ブロックが記憶された記憶手段のアドレスの直前のアドレスにブロック暗号化初期値を記憶するデータ処理装置である。
【０００７】
請求項１１の発明は、所定のデータ長の暗号化ブロックを単位としてデータを暗号化し、暗号化ブロックの整数倍のデータ長を持つ処理ブロックを単位としてデータに圧縮処理を行い、一の暗号化ブロックを構成するデータが同じ処理ブロック内に位置するように、暗号化したデータを記憶手段に書き込み、処理ブロックを単位としてデータを記憶手段から読み出し、単数または複数の処理ブロックを暗号化された順で記憶手段の連続したアドレスに記憶し、さらに、処理ブロック内の単数または複数の暗号化ブロックを暗号化された順で記憶手段の連続したアドレスに記憶し、クラスタ内で最初に暗号化された処理ブロック内でさらに最初に暗号化された暗号化ブロックが記憶された記憶手段のアドレスの直前のアドレスにブロック暗号化初期値を記憶するデータ処理方法である。
【０００８】
請求項７の発明は、記憶装置とデータ処理装置との間で相互認証を行いながらデータの入出力を行うデータ処理システムにおいて、記憶装置は、データ処理装置との間で相互認証処理を行う第１の相互認証処理手段と、データを記憶する記憶手段と、相互認証処理によってデータ処理装置が正当な相手であると認めたときに、データ処理装置と記憶手段との間でデータの入出力を行わせる第１の制御手段とを有し、データ処理装置は、記憶装置との間で相互認証処理を行う第２の相互認証処理手段と、所定のデータ長の暗号化ブロックを単位としてデータを暗号化する暗号化手段と、暗号化ブロックの整数倍のデータ長を持つ処理ブロックを単位としてデータに圧縮処理を行う処理手段と、相互認証処理によって、記憶装置が正当な相手であると認めたときに、書き込み処理および読み出し処理の少なくとも一方を行い、書き込み処理において、一の暗号化ブロックを構成するデータが同じ処理ブロック内に位置するように、暗号化したデータを記憶手段に書き込み、読み出し処理において、処理ブロックを単位としてデータを記憶手段から読み出す第２の制御手段とを有し、第２の制御手段は、単数または複数の処理ブロックを暗号化された順で記憶手段の連続したアドレスに記憶し、さらに、処理ブロック内の単数または複数の暗号化ブロックを暗号化された順で記憶手段の連続したアドレスに記憶し、クラスタ内で最初に暗号化された処理ブロック内でさらに最初に暗号化された暗号化ブロックが記憶された記憶手段のアドレスの直前のアドレスにブロック暗号化初期値を記憶するデータ処理システムである。
【０００９】
【発明の実施の形態】
以下、この発明の実施形態に係わるオーディオシステムについて説明する。図１は、一実施形態のオーディオシステム１のシステム構成図、図２は図１に示す携帯用記憶装置３および携帯用プレーヤ４の内部構成図である。図１に示すように、オーディオシステム１は、例えば、コンピュータ２、携帯用記憶装置３、携帯用プレーヤ４、ＣＤ−ＲＯＭドライブ６およびＣＤプレーヤ７を有する。
【００１０】
コンピュータ２
コンピュータ２は、ネットワーク５に接続されており、例えば、ＥＭＤ(Electronic Music Distribution: 電子音楽配信）などのサービスを提供する図示しないサービスプロバイダのホストコンピュータから、ネットワーク５を介してオーディオデータ（トラックデータ）を受信し、当該受信したオーディオデータを必要に応じて復号して、携帯用プレーヤ４に出力する。また、コンピュータ２は、コンテンツデータを受信するに当たって、必要に応じて、サービスプロバイダのホストコンピュータとの間で認証処理および課金処理などを行う。また、コンピュータ２は、例えば、ＣＤ−ＲＯＭドライブ６から入力したオーディオデータを携帯用プレーヤ４に出力する。
【００１１】
携帯用記憶装置３
携帯用記憶装置３は、携帯用プレーヤ４に対して着脱自在とされ、例えば、メモリスティック(Memory Stick:商標）であり、フラッシュメモリなどの書き換え可能な半導体メモリを内蔵している。本明細書において、メモリカードの用語が使用されることもあるが、メモリカードは、携帯用記憶装置を指すものとして使用している。図２に示すように、携帯用記憶装置３は、例えば、主制御モジュール３１、通信インターフェイス３２、制御モジュール３３、フラッシュメモリ３４およびフラッシュメモリ管理モジュール３５を有する。
【００１２】
〔制御モジュール３３〕
図２に示すように、制御モジュール３３は、例えば、乱数発生ユニット５０、記憶ユニット５１、鍵生成／演算ユニット５２、相互認証ユニット５３、暗号化／復号ユニット５４および制御ユニット５５を有する。制御モジュール３３は、シングルチップの暗号処理専用の集積回路であり、多層構造を有し、内部のメモリセルはアルミニウム層などのダミー層に挟まれている。また、制御モジュール３３は、動作電圧または動作周波数の幅が狭く、外部から不正にデータを読み出せないように耐タンパー性を有している。乱数発生ユニット５０は、乱数発生指示を受けると、６４ビット（８バイト）の乱数を発生する。
【００１３】
記憶ユニット５１は、例えば、ＥＥＰＲＯＭ(Electrically Erasable Programmable Read Only Memory) などの不揮発性メモリであり、認証処理に必要な鍵データなどの種々のデータを記憶している。図３は、記憶ユニット５１に記憶されているデータを説明するための図である。図３に示すように、記憶ユニット５１は、認証鍵データＩＫ0 〜ＩＫ31、装置識別データＩＤm および記憶用鍵データＳＫm を記憶している。
【００１４】
認証鍵データＩＫ0 〜ＩＫ31は、携帯用記憶装置３が携帯用プレーヤ４との間で相互認証を行う際に用いられる鍵データであり、後述するように相互認証を行う度に認証鍵データＩＫ0 〜ＩＫ31のうち一の認証鍵データがランダムに選択される。なお、認証鍵データＩＫ0 〜ＩＫ31および記憶用鍵データＳＫm は、携帯用記憶装置３の外部から読めないようになっている。装置識別データＩＤm は、携帯用記憶装置３に対してユニークに付けられた識別データであり、後述するように、携帯用記憶装置３が携帯用プレーヤ４との間で相互認証を行う際に読み出されて携帯用プレーヤ４に出力される。記憶用鍵データＳＫm は、後述するように、コンテンツ鍵データＣＫを暗号化してフラッシュメモリ３４に記憶する際に用いられる。
【００１５】
鍵生成／演算ユニット５２は、例えば、ＩＳＯ／ＩＥＣ９７９７のＭＡＣ(Message Authentication Code) 演算などの種々の演算を行って鍵データを生成する。このとき、ＭＡＣ演算には、例えば、"Block cipher Algorithm"としてＦＩＰＳＰＵＢ４６−２に規定されるＤＥＳ(Data Encryption Standard)が用いられる。ＭＡＣ演算は、任意の長さのデータを固定の長さに圧縮する一方向性ハッシュ関数演算であり、関数値が秘密鍵に依存して定まる。
【００１６】
相互認証ユニット５３は、携帯用プレーヤ４からオーディオデータを入力してフラッシュメモリ３４に書き込む動作を行うのに先立って、携帯用プレーヤ４との間で相互認証処理を行う。また、相互認証ユニット５３は、フラッシュメモリ３４からオーディオデータを読み出して携帯用プレーヤ４に出力する動作を行うのに先立って、携帯用プレーヤ４との間で相互認証処理を行う。また、相互認証ユニット５３は、相互認証処理において、前述したＭＡＣ演算を行う。当該相互認証処理では、記憶ユニット５１に記憶されているデータが用いられる。
【００１７】
暗号化／復号ユニット５４は、ＤＥＳ、ＩＤＥＡ、ＭＩＳＴＹなどのブロック暗号アルゴリズムでの暗号化を行う。使用するモードは、ＦＩＰＳ ＰＵＢ８１”ＤＥＳ ＭＯＤＥＳ ＯＦ ＯＰＥＲＡＴＩＯＮ”に規定されているようなＥＣＢ(Electronic Code Book)モードおよびＣＢＣ(Cipher Block Chaining) モードである。また、暗号化／復号ユニット５４は、ＤＥＳ、ＩＤＥＡ、ＭＩＳＴＹなどのブロック復号アルゴリズムでの復号を行う。使用するモードは、上記ＥＣＢモードおよびＣＢＣモードである。当該ＥＣＢモードおよびＣＢＣモードのブロック暗号化／復号では、指定された鍵データを用いて指定されたデータを暗号化／復号する。制御ユニット５５は、乱数発生ユニット５０、記憶ユニット５１、鍵生成／演算ユニット５２、相互認証ユニット５３および暗号化／復号ユニット５４の処理を統括して制御する。
【００１８】
〔フラッシュメモリ３４〕
フラッシュメモリ３４は、例えば、３２Ｍバイトの記憶容量を有する。フラッシュメモリ３４には、相互認証ユニット５３による相互認証処理によって正当な相手であると認められたときに、携帯用プレーヤ４から入力したオーディオデータが書き込まれる。また、フラッシュメモリ３４からは、相互認証ユニット５３による相互認証処理によって正当な相手であると認められたときに、オーディオデータが読み出されて携帯用プレーヤ４に出力される。
【００１９】
以下、フラッシュメモリ３４に記憶されるデータおよびそのフォーマットについて説明する。図４は、フラッシュメモリ３４に記憶されるデータを説明するための図である。図４に示すように、フラッシュメモリ３４には、例えば、再生管理ファイル１００、トラックデータファイル１０１0 ，１０１1 ，１０１2 ，１０１3 が記憶されている。ここで、再生管理ファイル１００はトラックデータファイル１０１0 〜１０１3 の再生を管理する管理データを有し、トラックデータファイル１０１0 〜１０１3 はそれぞれ対応するトラックデータ（オーディオデータ）を有している。なお、本実施形態では、トラックデータは、例えば、１曲分のオーディオデータを意味する。
【００２０】
図５は、再生管理ファイルの構成を示し、図６が一つ（１曲）のトラックデータファイル（以下においてＡＴＲＡＣ３データファイルの用語がさすものもトラックデータファイルと同義である）の構成を示す。再生管理ファイルは、１６ＫＢ固定長のファイルである。ＡＴＲＡＣ３データファイルは、曲単位でもって、先頭の属性ヘッダと、それに続く実際の暗号化された音楽データとからなる。属性ヘッダも１６ＫＢ固定長とされ、再生管理ファイルと類似した構成を有する。
【００２１】
再生管理ファイルは、ヘッダ、１バイトコードのメモリカードの名前ＮＭ１−Ｓ、２バイトコードのメモリカードの名前ＮＭ２−Ｓ、曲順の再生テーブルＴＲＫＴＢＬ、メモリカード全体の付加情報ＩＮＦ−Ｓとからなる。データファイルの先頭の属性ヘッダは、ヘッダ、１バイトコードの曲名ＮＭ１、２バイトコードの曲名ＮＭ２、トラックのキー情報等のトラック情報ＴＲＫＩＮＦ、パーツ情報ＰＲＴＩＮＦと、トラックの付加情報ＩＮＦとからなる。ヘッダには、総パーツ数、名前の属性、付加情報のサイズの情報等が含まれる。
【００２２】
属性ヘッダに対してＡＴＲＡＣ３の音楽データが続く。音楽データは、１６ＫＢのブロック毎に区切られ、各ブロックの先頭にヘッダが付加されている。ヘッダには、暗号を復号するための初期値が含まれる。なお、暗号化の処理を受けるのは、ＡＴＲＡＣ３データファイル中の音楽データのみであって、それ以外の再生管理ファイル、ヘッダ等のデータは、暗号化されない。
【００２３】
図７は、再生管理ファイルＰＢＬＩＳＴのより詳細なデータ構成を示し、図８Ａ、図８Ｂは、再生管理ファイルＰＢＬＩＳＴを構成するヘッダとそれ以外の部分をそれぞれ示す。再生管理ファイルＰＢＬＩＳＴは、１クラスタ（１ブロック＝１６ＫＢ）のサイズである。ヘッダ（図８Ａ）が３２バイトである。ヘッダ以外の部分（図８Ｂ）がメモリカード全体に対する名前ＮＭ１−Ｓ（２５６バイト）、名前ＮＭ２−Ｓ（５１２バイト）、ＣＯＮＴＥＮＴＳ ＫＥＹ、ＭＡＣ、Ｓ−ＹＭＤｈｍｓと、再生順番を管理するテーブルＴＲＫＴＢＬ（８００バイト）と、メモリカード全体に対する付加情報ＩＮＦ−Ｓ（１４７２０バイト）であり、最後にヘッダ中の情報の一部が再度記録される。これらの異なる種類のデータ群のそれぞれの先頭は、再生管理ファイル内で所定の位置となるように規定されている。
【００２４】
再生管理ファイルは、（０ｘ００００）および（０ｘ００１０）で表される先頭から３２バイト（図８Ａ）がヘッダである。なお、ファイル中で先頭から１６バイト単位で区切られた単位をスロットと称する。ファイルの第１および第２のスロットに配されるヘッダには、下記の意味、機能、値を持つデータが先頭から順に配される。なお、Ｒｅｓｅｒｖｅｄと表記されているデータは、未定義のデータを表している。通常ヌル（０ｘ００）が書かれるが、何が書かれていてもＲｅｓｅｒｖｅｄのデータが無視される。将来のバージョンでは、変更がありうる。また、この部分への書き込みは禁止する。Ｏｐｔｉｏｎと書かれた部分も使用しない場合は、全てＲｅｓｅｒｖｅｄと同じ扱いとされる。
【００２５】
ＢＬＫＩＤ−ＴＬ０（４バイト）
意味：BLOCKID FILE ID
機能：再生管理ファイルの先頭であることを識別するための値
値：固定値＝”ＴＬ＝０”（例えば０ｘ５４４Ｃ２Ｄ３０）
ＭＣｏｄｅ（２バイト）
意味：MAKER CODE
機能：記録した機器の、メーカー、モデルを識別するコード
値：上位１０ビット（メーカーコード） 下位６ビット（機種コード）
ＲＥＶＩＳＩＯＮ（４バイト）
意味：ＰＢＬＩＳＴの書き換え回数
機能：再生管理ファイルを書き換える度にインクリメント
値：０より始まり＋１づつ増加する
ＳＮ１Ｃ＋Ｌ（２バイト）
意味：ＮＭ１−Ｓ領域に書かれるメモリカードの名前（１バイト）の属性を表す
機能：使用する文字コードと言語コードを各１バイトで表す
値：文字コード（Ｃ）は上位１バイトで下記のように文字を区別する
00: 文字コードは設定しない。単なる２進数として扱うこと
01: ASCII 02:ASCII+KANA 03:modifided8859-1
81:MS-JIS 82:KS C 5601-1989 83:GB2312-80 90:S-JIS(for Voice) 。
【００２７】
言語コード（Ｌ）は下位１バイトで下記のようにEBU Tech 3258 規定に準じて言語を区別する
00: 設定しない 08:German 09:English 0A:Spanish
0F:French 15:Italian 1D:Dutch
65:Korean 69:Japanese 75:Chinese
データが無い場合オールゼロとすること。
【００２８】
ＳＮ２Ｃ＋Ｌ（２バイト）
意味：ＮＭ２−Ｓ領域に書かれるメモリカードの名前（２バイト）の属性を表す
機能：使用する文字コードと言語コードを各１バイトで表す
値：上述したＳＮ１Ｃ＋Ｌと同一
ＳＩＮＦＳＩＺＥ（２バイト）
意味：ＩＮＦ−Ｓ領域に書かれるメモリカード全体に関する付加情報の全てを合計したサイズを表す
機能：データサイズを１６バイト単位の大きさで記述、無い場合は必ずオールゼロとすること
値：サイズは０ｘ０００１から０ｘ３９Ｃ（９２４）
Ｔ−ＴＲＫ（２バイト）
意味：TOTAL TRACK NUMBER
機能：総トラック数
値：１から０ｘ０１９０（最大４００トラック）、データが無い場合はオールゼロとすること
上述したヘッダに続く領域に書かれるデータ（図８Ｂ）について以下に説明する。
【００３０】
ＮＭ１−Ｓ
意味：メモリカード全体に関する１バイトの名前
機能：１バイトの文字コードで表した可変長の名前データ（最大で２５６）
名前データの終了は、必ず終端コード（０ｘ００）を書き込むこと
サイズはこの終端コードから計算すること、データの無い場合は少なくとも先頭（０ｘ００２０）からヌル（０ｘ００）を１バイト以上記録すること
値：各種文字コード
ＮＭ２−Ｓ
意味：メモリカード全体に関する２バイトの名前
機能：２バイトの文字コードで表した可変長の名前データ（最大で５１２）
名前データの終了は、必ず終端コード（０ｘ００）を書き込むこと
サイズはこの終端コードから計算すること、データの無い場合は少なくとも先頭（０ｘ０１２０）からヌル（０ｘ００）を２バイト以上記録すること
値：各種文字コード。
【００３１】
ＣＯＮＴＥＮＴＳ ＫＥＹ
意味：曲ごとに用意された値でＭＧ（Ｍ）で保護されてから保存される。ここでは、１曲目に付けられるＣＯＮＴＥＮＴＳ ＫＥＹと同じ値
機能：Ｓ−ＹＭＤｈｍｓのＭＡＣの計算に必要となる鍵となる
値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦまで
ＭＡＣ
意味：著作権情報改ざんチェック値
機能：Ｓ−ＹＭＤｈｍｓの内容とＣＯＮＴＥＮＴＳ ＫＥＹから作成される値
値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦまで。
【００３２】
ＴＲＫ−ｎｎｎ
意味：再生するＡＴＲＡＣ３データファイルのＳＱＮ（シーケンス）番号
機能：ＴＲＫＩＮＦの中のＦＮｏを記述する
値：１から４００（０ｘ１９０）
トラックが存在しない時はオールゼロとすること
ＩＮＦ−Ｓ
意味：メモリカード全体に関する付加情報データ（例えば写真、歌詞、解説等の情報）
機能：ヘッダを伴った可変長の付加情報データ
複数の異なる付加情報が並べられることがある。それぞれにＩＤとデータサイズが付けられている。個々のヘッダを含む付加情報データは最小１６バイト以上で４バイトの整数倍の単位で構成される。その詳細については、後述する
値：付加情報データ構成を参照
再生管理ファイルの最後のスロットとして、ヘッダ内のものと同一のＢＬＫＩＤ−ＴＬ０と、ＭＣｏｄｅと、ＲＥＶＩＳＩＯＮとが書かれる。
【００３４】
民生用オーディオ機器として、メモリカードが記録中に抜かれたり、電源が切れることがあり、復活した時にこれらの異常の発生を検出することが必要とされる。上述したように、ＲＥＶＩＳＩＯＮをブロックの先頭と末尾に書き込み、この値を書き換える度に＋１インクリメントするようにしている。若し、ブロックの途中で異常終了が発生すると、先頭と末尾のＲＥＶＩＳＩＯＮの値が一致せず、異常終了を検出することができる。ＲＥＶＩＳＩＯＮが２個存在するので、高い確率で異常終了を検出することができる。異常終了の検出時には、エラーメッセージの表示等の警告が発生する。
【００３５】
また、１ブロック（１６ＫＢ）の先頭部分に固定値ＢＬＫＩＤ−ＴＬ０を挿入しているので、ＦＡＴが壊れた場合の修復の目安に固定値を使用できる。すなわち、各ブロックの先頭の固定値を見れば、ファイルの種類を判別することが可能である。しかも、この固定値ＢＬＫＩＤ−ＴＬ０は、ブロックのヘッダおよびブロックの終端部分に二重に記述するので、その信頼性のチェックを行うことができる。なお、再生管理ファイルＰＢＬＩＳＴの同一のものを二重に記録しても良い。
【００３６】
ＡＴＲＡＣ３データファイルは、トラック情報管理ファイルと比較して、相当大きなデータ量（例えば数千のブロックが繋がる場合もある）であり、ＡＴＲＡＣ３データファイルに関しては、後述するように、ブロック番号ＢＬＯＣＫ ＳＥＲＩＡＬが付けられている。但し、ＡＴＲＡＣ３データファイルは、通常複数のファイルがメモリカード上に存在するので、ＣＯＮＮＵＭ０でコンテンツの区別を付けた上で、ＢＬＯＣＫ ＳＥＲＩＡＬを付けないと、重複が発生し、ＦＡＴが壊れた場合のファイルの復旧が困難となる。
【００３７】
同様に、ＦＡＴの破壊までにはいたらないが、論理を間違ってファイルとして不都合のあるような場合に、書き込んだメーカーの機種が特定できるように、メーカーコード（ＭＣｏｄｅ）がブロックの先頭と末尾に記録されている。
【００３８】
図８Ｃは、付加情報データの構成を示す。付加情報の先頭に下記のヘッダが書かれる。ヘッダ以降に可変長のデータが書かれる。
【００３９】
ＩＮＦ
意味：FIELD ID
機能：付加情報データの先頭を示す固定値
値：０ｘ６９
ＩＤ
意味：付加情報キーコード
機能：付加情報の分類を示す
値：０から０ｘＦＦ
ＳＩＺＥ
意味：個別の付加情報の大きさ
機能：データサイズは自由であるが、必ず４バイトの整数倍でなければならない。また、最小１６バイト以上のこと。データの終わりより余りがでる場合はヌル（０ｘ００）で埋めておくこと
値：１６から１４７８４（０ｘ３９Ｃ０）
ＭＣｏｄｅ
意味：MAKER CODE
機能：記録した機器の、メーカー、モデルを識別するコード
値：上位１０ビット（メーカーコード） 下位６ビット（機種コード）
Ｃ＋Ｌ
意味：先頭から１２バイト目からのデータ領域に書かれる文字の属性を表す
機能：使用する文字コードと言語コードを各１バイトで表す
値：前述のＳＮ１Ｃ＋Ｌと同じ
ＤＡＴＡ
意味：個別の付加情報データ
機能：可変長データで表す。実データの先頭は常に１２バイト目より始まり、長さ（サイズ）は最小４バイト以上、常に４バイトの整数倍でなければならない。データの最後から余りがある場合はヌル（０ｘ００）で埋めること
値：内容により個別に定義される。
【００４０】
以下、トラックデータファイル１０１0 〜１０１3 について説明する。図９は、トラックデータファイル１０１0 の構成を説明するための図である。図９に示すように、トラックデータファイル１０１0 は、１個のパーツからなり、当該パーツが５個のクラスタＣＬ（０），ＣＬ（１），ＣＬ（２），ＣＬ（３），ＣＬ（４）で構成されている。当該パーツは、クラスタＣＬ（０）の先頭から開始し、クラスタＣＬ（４）のサウンドユニットＳＵ（４）で終了している。なお、トラックデータファイル１０１1 〜１０１3 は、基本的に、図９に示す構成をしているが、パーツ数、クラスタ数およびクラスタ内に含まれるサウンドユニットＳＵの数は、図９に示すものには限定されず、独立して決められている。
【００４１】
１トラックは、１曲を意味する。１曲は、１つのＡＴＲＡＣ３データファイル（図６参照）で構成される。ＡＴＲＡＣ３データファイルは、ＡＴＲＡＣ３により圧縮されたオーディオデータである。メモリカード４０に対しては、クラスタと呼ばれる単位で記録される。１クラスタは、例えば１６ＫＢの容量である。１クラスタに複数のファイルが混じることがない。フラッシュメモリ４２を消去する時の最小単位が１ブロックである。音楽データを記録するのに使用するメモリカード４０の場合、ブロックとクラスタは、同意語であり、且つ１クラスタ＝１セクタと定義されている。
【００４２】
１曲は、基本的に１パーツで構成されるが、編集が行われると、複数のパーツから１曲が構成されることがある。パーツは、録音開始からその停止までの連続した時間内で記録されたデータの単位を意味し、通常は、１トラックが１パーツで構成される。曲内のパーツのつながりは、各曲の属性ヘッダ内のパーツ情報ＰＲＴＩＮＦで管理する。すなわち、パーツサイズは、ＰＲＴＩＮＦの中のパーツサイズＰＲＴＳＩＺＥという４バイトのデータで表す。パーツサイズＰＲＴＳＩＺＥの先頭の２バイトがパーツが持つクラスタの総数を示し、続く各１バイトが先頭および末尾のクラスタ内の開始サウンドユニット（ＳＵと略記する）の位置、終了ＳＵの位置を示す。このようなパーツの記述方法を持つことによって、音楽データを編集する際に通常、必要とされる大量の音楽データの移動をなくすことが可能となる。ブロック単位の編集に限定すれば、同様に音楽データの移動を回避できるが、ブロック単位は、ＳＵ単位に比して編集単位が大きすぎる。
【００４３】
ＳＵは、パーツの最小単位であり、且つＡＴＲＡＣ３でオーディオデータを圧縮する時の最小のデータ単位である。４４．１ｋHzのサンプリング周波数で得られた１０２４サンプル分（１０２４×１６ビット×２チャンネル）のオーディオデータを約１／１０に圧縮した数百バイトのデータがＳＵである。１ＳＵは、時間に換算して約２３ｍ秒になる。通常は、数千に及ぶＳＵによって１つのパーツが構成される。１クラスタが４２個のＳＵで構成される場合、１クラスタで約１秒の音を表すことができる。１つのトラックを構成するパーツの数は、付加情報サイズに影響される。パーツ数は、１ブロックの中からヘッダや曲名、付加情報データ等を除いた数で決まるために、付加情報が全く無い状態が最大数（６４５個）のパーツを使用できる条件となる。
【００４４】
図１０は、１ＳＵがＮバイト（例えばＮ＝３８４バイト）の場合のＡＴＲＡＣ３データファイルＡ３Ｄｎｎｎｎのデータ配列を示す。図１０には、データファイルの属性ヘッダ（１ブロック）と、音楽データファイル（１ブロック）とが示されている。図１０では、この２ブロック（１６×２＝３２Ｋバイト）の各スロットの先頭のバイト（０ｘ００００〜０ｘ７ＦＦ０）が示されている。図１１に分離して示すように、属性ヘッダの先頭から３２バイトがヘッダであり、２５６バイトが曲名領域ＮＭ１（２５６バイト）であり、５１２バイトが曲名領域ＮＭ２（５１２バイト）である。属性ヘッダのヘッダには、下記のデータが書かれる。
【００４５】
ＢＬＫＩＤ−ＨＤ０（４バイト）
意味：BLOCKID FILE ID
機能：ＡＴＲＡＣ３データファイルの先頭であることを識別するための値
値：固定値＝”ＨＤ＝０”（例えば０ｘ４８４４２Ｄ３０）
ＭＣｏｄｅ（２バイト）
意味：MAKER CODE
機能：記録した機器の、メーカー、モデルを識別するコード
値：上位１０ビット（メーカーコード） 下位６ビット（機種コード）
ＢＬＯＣＫ ＳＥＲＩＡＬ（４バイト）
意味：トラック毎に付けられた連続番号
機能：ブロックの先頭は０から始まり次のブロックは＋１づつインクリメント
編集されても値を変化させない
値：０より始まり０ｘＦＦＦＦＦＦＦＦまで。
【００４６】
Ｎ１Ｃ＋Ｌ（２バイト）
意味：トラック（曲名）データ（ＮＭ１）の属性を表す
機能：ＮＭ１に使用される文字コードと言語コードを各１バイトで表す
値：ＳＮ１Ｃ＋Ｌと同一
Ｎ２Ｃ＋Ｌ（２バイト）
意味：トラック（曲名）データ（ＮＭ２）の属性を表す
機能：ＮＭ２に使用される文字コードと言語コードを各１バイトで表す
値：ＳＮ１Ｃ＋Ｌと同一
ＩＮＦＳＩＺＥ（２バイト）
意味：トラックに関する付加情報の全てを合計したサイズを表す
機能：データサイズを１６バイト単位の大きさで記述、無い場合は必ずオールゼロとすること
値：サイズは０ｘ００００から０ｘ３Ｃ６（９６６）
Ｔ−ＰＲＴ（２バイト）
意味：トータルパーツ数
機能：トラックを構成するパーツ数を表す。通常は１
値：１から０ｘ２８５（６４５dec ）
Ｔ−ＳＵ（４バイト）
意味：トータルＳＵ数
機能：１トラック中の実際の総ＳＵ数を表す。曲の演奏時間に相当する
値：０ｘ０１から０ｘ００１ＦＦＦＦＦ
ＩＮＸ（２バイト）（Ｏｐｔｉｏｎ）
意味：INDEX の相対場所
機能：曲のさびの部分（特徴的な部分）の先頭を示すポインタ。曲の先頭からの位置をＳＵの個数を１／４した数で指定する。これは、通常のＳＵの４倍の長さの時間（約９３ｍ秒）に相当する
値：０から０ｘＦＦＦＦ（最大、約６０８４秒）
ＸＴ（２バイト）（Ｏｐｔｉｏｎ）
意味：INDEX の再生時間
機能：ＩＮＸ-nnnで指定された先頭から再生すべき時間のＳＵの個数を１／４した数で指定する。これは、通常のＳＵの４倍の長さの時間（約９３ｍ秒）に相当する
値：０ｘ００００：無設定 ０ｘ０１から０ｘＦＦＦＥ（最大６０８４秒）
０ｘＦＦＦＦ：曲の終わりまで。
【００４７】
次に曲名領域ＮＭ１およびＮＭ２について説明する。
【００４８】
ＮＭ１
意味：曲名を表す文字列
機能：１バイトの文字コードで表した可変長の曲名（最大で２５６）
名前データの終了は、必ず終端コード（０ｘ００）を書き込むこと
サイズはこの終端コードから計算すること、データの無い場合は少なくとも先頭（０ｘ００２０）からヌル（０ｘ００）を１バイト以上記録すること
値：各種文字コード
ＮＭ２
意味：曲名を表す文字列
機能：２バイトの文字コードで表した可変長の名前データ（最大で５１２）
名前データの終了は、必ず終端コード（０ｘ００）を書き込むこと
サイズはこの終端コードから計算すること、データの無い場合は少なくとも先頭（０ｘ０１２０）からヌル（０ｘ００）を２バイト以上記録すること
値：各種文字コード。
【００４９】
属性ヘッダの固定位置（０ｘ３２０）から始まる、８０バイトのデータをトラック情報領域ＴＲＫＩＮＦと呼び、主としてセキュリティ関係、コピー制御関係の情報を一括して管理する。図１２にＴＲＫＩＮＦの部分を示す。ＴＲＫＩＮＦ内のデータについて、配置順序に従って以下に説明する。
【００５０】
ＣＯＮＴＥＮＴＳ ＫＥＹ（８バイト）
意味：曲毎に用意された値で、メモリカードのセキュリティブロックで保護されてから保存される
機能：曲を再生する時、まず必要となる最初の鍵となる。ＭＡＣ計算時に使用される
値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦまで
ＭＡＣ（８バイト）
意味：著作権情報改ざんチェック値
機能：コンテンツ累積番号を含む複数のＴＲＫＩＮＦの内容と隠しシーケンス番号から作成される値
隠しシーケンス番号とは、メモリカードの隠し領域に記録されているシーケンス番号のことである。著作権対応でないレコーダは、隠し領域を読むことができない。また、著作権対応の専用のレコーダ、またはメモリカードを読むことを可能とするアプリケーションを搭載したパーソナルコンピュータは、隠し領域をアクセスすることができる。
【００５１】
Ａ（１バイト）
意味：パーツの属性
機能：パーツ内の圧縮モード等の情報を示す
値：図１３を参照して以下に説明する
ただし、Ｎ＝０，１のモノラルは、ｂｉｔ７が１でサブ信号を０、メイン信号（Ｌ＋Ｒ）のみの特別なＪｏｉｎｔモードをモノラルとして規定する。ｂｉｔ２，１の情報は通常の再生機は無視しても構わない。
【００５２】
Ａのビット０は、エンファシスのオン／オフの情報を形成し、ビット１は、再生ＳＫＩＰか、通常再生かの情報を形成し、ビット２は、データ区分、例えばオーディオデータか、ＦＡＸ等の他のデータかの情報を形成する。ビット３は、未定義である。ビット４、５、６を組み合わせることによって、図示のように、ＡＴＲＡＣ３のモード情報が規定される。すなわち、Ｎは、この３ビットで表されるモードの値であり、モノ（Ｎ＝０，１），ＬＰ（Ｎ＝２），ＳＰ（Ｎ＝４），ＥＸ（Ｎ＝５），ＨＱ（Ｎ＝７）の５種類のモードについて、記録時間（６４ＭＢのメモリカードの場合）、データ転送レート、１ブロック内のＳＵ数がそれぞれ示されている。１ＳＵのバイト数は、（モノ：１３６バイト、ＬＰ：１９２バイト、ＳＰ：３０４バイト、ＥＸ：３８４バイト、ＨＱ：５１２バイト）である。さらに、ビット７によって、ＡＴＲＡＣ３のモード（０：Dual １：Joint ）が示される。
【００５３】
一例として、６４ＭＢのメモリカードを使用し、ＳＰモードの場合について説明する。６４ＭＢのメモリカードには、３９６８ブロックがある。ＳＰモードでは、１ＳＵが３０４バイトであるので、１ブロックに５３ＳＵが存在する。１ＳＵは、（１０２４／４４１００）秒に相当する。従って、１ブロックは、
（１０２４／４４１００）×５３×（３９６８−１６）＝４８６３秒＝８１分
転送レートは、
（４４１００／１０２４）×３０４×８＝１０４７３７ bps
となる。
【００５４】
意味：ファイル番号
機能：最初に記録された時のトラック番号、且つこの値は、メモリカード内の隠し領域に記録されたＭＡＣ計算用の値の位置を特定する
値：１から０ｘ１９０（４００）
ＭＧ（Ｄ）ＳＥＲＩＡＬ−ｎｎｎ（１６バイト）
意味：記録機器のセキュリティブロック（制御モジュ−ル４３）のシリアル番号
機能：記録機器ごとに全て異なる固有の値
値：０から0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
ＣＯＮＮＵＭ（４バイト）
意味：コンテンツ累積番号
機能：曲毎に累積されていく固有の値で記録機器のセキュリティブロックによって管理される。２の３２乗、４２億曲分用意されており、記録した曲の識別に使用する
値：０から０ｘＦＦＦＦＦＦＦＦ。
【００５５】
ＹＭＤｈｍｓ−Ｓ（４バイト）（Ｏｐｔｉｏｎ）
意味：再生制限付きのトラックの再生開始日時
機能：ＥＭＤで指定する再生開始を許可する日時
値：上述した日時の表記と同じ
ＹＭＤｈｍｓ−Ｅ（４バイト）（Ｏｐｔｉｏｎ）
意味：再生制限付きのトラックの再生終了日時
機能：ＥＭＤで指定する再生許可を終了する日時
値：上述した日時の表記と同じ
ＣＣ（１バイト）
意味：COPY CONTROL
機能：コピー制御
値：図１４に示すように、ビット６および７によってコピー制御情報を表し、ビット４および５によって高速ディジタルコピーに関するコピー制御情報を表し、ビット２および３によってセキュリティブロック認証レベルを表す。ビット０および１は、未定義
ＣＣの例：（ｂｉｔ７，６）１１：無制限のコピーを許可、０１：コピー禁止、００：１回のコピーを許可
（ｂｉｔ３，２）００：アナログないしディジタルインからの録音、ＭＧ認証レベルは０とする
ＣＤからのディジタル録音では（ｂｉｔ７，６）は００、（ｂｉｔ３，２）は００となる
ＣＮ（１バイト）（Ｏｐｔｉｏｎ）
意味：高速ディジタルコピーＨＳＣＭＳ(High speed Serial Copy Management System)におけるコピー許可回数
機能：コピー１回か、コピーフリーかの区別を拡張し、回数で指定する。コピー第１世代の場合にのみ有効であり、コピーごとに減算する
値：００：コピー禁止、０１から０ｘＦＥ：回数、０ｘＦＦ：回数無制限。
【００５７】
上述したトラック情報領域ＴＲＫＩＮＦに続いて、０ｘ０３７０から始まる２４バイトのデータをパーツ管理用のパーツ情報領域ＰＲＴＩＮＦと呼び、１つのトラックを複数のパーツで構成する場合に、時間軸の順番にＰＲＴＩＮＦを並べていく。図１５にＰＲＴＩＮＦの部分を示す。ＰＲＴＩＮＦ内のデータについて、配置順序に従って以下に説明する。
【００５８】
ＰＲＴＳＩＺＥ（４バイト）
意味：パーツサイズ
機能：パーツの大きさを表す。クラスタ：２バイト（最上位）、開始ＳＵ：１バイト（上位）、終了ＳＵ：１バイト（最下位）
値：クラスタ：１から０ｘ１Ｆ４０（８０００）、開始ＳＵ：０から０ｘＡ０（１６０）、終了ＳＵ：０から０ｘＡ０（１６０）（但し、ＳＵの数え方は、０，１，２，と０から開始する）
ＰＲＴＫＥＹ（８バイト）
意味：パーツを暗号化するための値
機能：初期値＝０、編集時は編集の規則に従うこと
値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦ
ＣＯＮＮＵＭ０（４バイト）
意味：最初に作られたコンテンツ累積番号キー
機能：コンテンツをユニークにするためのＩＤの役割
値：コンテンツ累積番号初期値キーと同じ値とされる。
【００５９】
ＡＴＲＡＣ３データファイルの属性ヘッダ中には、図１０に示すように、付加情報ＩＮＦが含まれる。この付加情報は、開始位置が固定化されていない点を除いて、再生管理ファイル中の付加情報ＩＮＦ−Ｓ（図７および図８Ｂ参照）と同一である。１つまたは複数のパーツの最後のバイト部分（４バイト単位）の次を開始位置として付加情報ＩＮＦのデータが開始する。
【００６０】
ＩＮＦ
意味：トラックに関する付加情報データ
機能：ヘッダを伴った可変長の付加情報データ。複数の異なる付加情報が並べられることがある。それぞれにＩＤとデータサイズが付加されている。個々のヘッダを含む付加情報データは、最小１６バイト以上で４バイトの整数倍の単位
値：再生管理ファイル中の付加情報ＩＮＦ−Ｓと同じである。
【００６１】
上述した属性ヘッダに対して、ＡＴＲＡＣ３データファイルの各ブロックのデータが続く。図１６に示すように、ブロック毎にヘッダが付加される。各ブロックのデータについて以下に説明する。
【００６２】
ＢＬＫＩＤ−Ａ３Ｄ（４バイト）
意味：BLOCKID FILE ID
機能：ＡＴＲＡＣ３データの先頭であることを識別するための値
値：固定値＝”Ａ３Ｄ”（例えば０ｘ４１３３４４２０）
ＭＣｏｄｅ（２バイト）
意味：MAKER CODE
機能：記録した機器の、メーカー、モデルを識別するコード
値：上位１０ビット（メーカーコード） 下位６ビット（機種コード）
ＣＯＮＮＵＭ０（４バイト）
意味：最初に作られたコンテンツ累積番号
機能：コンテンツをユニークにするためのＩＤの役割、編集されても値は変化させない
値：コンテンツ累積番号初期値キーと同じ値とされる
ＢＬＯＣＫ ＳＥＲＩＡＬ（４バイト）
意味：トラック毎に付けられた連続番号
機能：ブロックの先頭は０から始まり次のブロックは＋１づつインクリメント編集されても値を変化させない
値：０より始まり０ｘＦＦＦＦＦＦＦＦまで
ＢＬＯＣＫ−ＳＥＥＤ（８バイト）
意味：１ブロックを暗号化するための１つの鍵
機能：ブロックの先頭は、記録機器のセキュリティブロックで乱数を生成、続くブロックは、＋１インクリメントされた値、この値が失われると、１ブロックに相当する約１秒間、音が出せないために、ヘッダとブロック末尾に同じものが二重に書かれる。編集されても値を変化させない
値：初期は８バイトの乱数
ＩＮＩＴＩＡＬＩＺＡＴＩＯＮ ＶＥＣＴＯＲ（８バイト）
意味：ブロック毎にＡＴＲＡＣ３データを暗号化、復号化する時に必要な初期値
機能：ブロックの先頭は０から始まり、次のブロックは最後のＳＵの最後の暗号化された８バイトの値。デバイドされたブロックの途中からの場合は開始ＳＵの直前の最後の８バイトを用いる。編集されても値を変化させない
値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦ
ＳＵ−ｎｎｎ
意味：サウンドユニットのデータ
機能：１０２４サンプルから圧縮されたデータ、圧縮モードにより出力されるバイト数が異なる。編集されても値を変化させない（一例として、ＳＰモードの時では、Ｎ＝３８４バイト）
値：ＡＴＲＡＣ３のデータ値。
【００６３】
図１０では、Ｎ＝３８４であるので、１ブロックに４２ＳＵが書かれる。また、１ブロックの先頭の２つのスロット（４バイト）がヘッダとされ、最後の１スロット（２バイト）にＢＬＫＩＤ−Ａ３Ｄ、ＭＣｏｄｅ、ＣＯＮＮＵＭ０、ＢＬＯＣＫ ＳＥＲＩＡＬが二重に書かれる。従って、１ブロックの余りの領域Ｍバイトは、（１６，３８４−３８４×４２−１６×３＝２０８（バイト）となる。この中に上述したように、８バイトのＢＬＯＣＫ ＳＥＥＤが二重に記録される。
【００６４】
また、サウンドユニットＳＵ（０）〜（１０１）は、図２に示す暗号化／復号ユニット６４においてＣＢＣ(Cipher Block Chainning)モードで６４ビット（８バイト）の暗号化ブロックを単位として暗号化して生成された８バイトの暗号文Ｃi によって構成される。本実施形態では、サウンドユニットＳＵのバイト数（例えば１６０バイト）を、暗号化の単位である暗号化ブロックのバイト数（例えば８バイト）の整数倍にしている。すなわち、１サウンドユニットＳＵは例えば２０個の暗号文Ｃi からなる。このとき、個々の暗号文Ｃi は一のサウンドユニットＳＵ内に位置し、一の暗号文Ｃi が複数のサウンドユニットＳＵに跨がって位置することはない。
【００６５】
ここで、フラッシュメモリ３４に記憶されているオーディオデータは、後述するように例えば、ＡＴＲＡＣ３方式で圧縮されており、当該圧縮の単位がサウンドユニットＳＵである。従って、携帯用記憶装置３から携帯用プレーヤ４にオーディオデータを読み出す場合には、読み出しの最小単位は当該サウンドユニットＳＵとなる。
【００６６】
このようにすることで、フラッシュメモリ３４に記憶されている暗号化されたオーディオデータにアクセスする際に、暗号化ブロックの区切りを意識する必要がなくなり、当該アクセスに伴う処理負担を軽減できる。なお、各クラスタ内に含まれるサウンドユニットＳＵの数は、１個以上１０２個以下の範囲で任意である。また、オーディオデータの圧縮方式は、ＡＴＲＡＣ３などのＡＴＲＡＣ方式以外のＣＯＤＥＣ方式でもよい。
【００６７】
ブロックシードデータＢＳは、各ブロック毎に例えば乱数を発生して生成されたデータであり、後述するように、携帯用プレーヤ４内でブロック毎にブロック鍵データＢＫを生成する際に用いられる。当該ブロックシードデータＢＳは、エラー対策としてブロック内の２箇所に格納されている。なお、各クラスタに含まれるサウンドユニットは、暗号化された順でフラッシュメモリ３４の連続したアドレスに記憶される。また、各サウンドユニット内の暗号化ブロックは、暗号化された順にフラッシュメモリ３４の連続したアドレスに記憶される。
【００６８】
〔フラッシュメモリ管理モジュール３５〕
フラッシュメモリ管理モジュール３５は、フラッシュメモリ３４へのデータの書き込み、フラッシュメモリ３４からのデータの読み出しなどの制御を行う。
【００６９】
携帯用プレーヤ４
図２に示すように、携帯用プレーヤ４は、例えば、主制御モジュール４１、通信インターフェイス４２、制御モジュール４３、編集モジュール４４、圧縮／伸長モジュール４５、スピーカ４６、Ｄ／Ａ変換器４７およびＡ／Ｄ変換器４８を有する。
【００７０】
〔主制御モジュール４１〕
主制御モジュール４１は、携帯用プレーヤ４の処理を統括的に制御する。
【００７１】
〔制御モジュール４３〕
図２に示すように、制御モジュール４３は、例えば、乱数発生ユニット６０、記憶ユニット６１、鍵生成／鍵演算ユニット６２、相互認証ユニット６３、暗号化／復号ユニット６４および制御ユニット６５を有する。制御モジュール４３は、制御モジュール３３と同様に、シングルチップの暗号処理専用の集積回路であり、多層構造を有し、内部のメモリセルはアルミニウム層などのダミー層に挟まれている。また、制御モジュール４３は、動作電圧または動作周波数の幅が狭く、外部から不正にデータを読み出せないように耐タンパー性を有している。乱数発生ユニット６０は、乱数発生指示を受けると、６４ビット（８バイト）の乱数を発生する。記憶ユニット６１は、認証処理に必要な種々のデータを記憶している。
【００７２】
図１７は、記憶ユニット６１に記憶されているデータを説明するための図である。図１７に示すように、記憶ユニット６１は、マスター鍵データＭＫ0 〜ＭＫ31および装置識別データＩＤd を記憶している。ここで、マスター鍵データＭＫ0 〜ＭＫ31と、認証鍵データＩＫ0 〜ＩＫ31との間には、前述した携帯用記憶装置３の装置識別データＩＤm を用いて、下記式（１）に示す関係がある。なお、下記式において、ｆ（ａ，ｂ）は、例えば、引数ａ，ｂから値を導出する関数である。
【００７３】
【数１】
ＩＫj ＝ｆ（ＭＫj ，ＩＤm ） ・・・（１）
但し、ｉは、０≦ｊ≦３１の整数。
【００７４】
また、記憶ユニット６１における認証鍵データＩＫ0 〜ＩＫ31の記憶アドレスは、例えば５ビットで表現され、それぞれ記憶ユニット５１におけるマスター鍵データＭＫ0 〜ＭＫ31と同じ記憶アドレスが割り当てられている。
【００７５】
鍵生成／鍵演算ユニット６２は、例えば、ＩＳＯ／ＩＥＣ９７９７のＭＡＣ演算方式を用いた演算などの種々の演算を行って鍵データを生成する。このとき、"Block cipher Algorithm"としてＦＩＰＳ ＰＵＢ ４６−２に規定されるＤＥＳが用いられる。
【００７６】
相互認証ユニット６３は、例えば、コンピュータ２から入力したオーディオデータを携帯用記憶装置３に出力する動作を行うのに先立って、携帯用記憶装置３との間で相互認証処理を行う。また、相互認証ユニット６３は、携帯用記憶装置３からオーディオデータを入力する動作を行うのに先立って、携帯用記憶装置３との間で相互認証処理を行う。また、相互認証ユニット６３は、相互認証処理において、前述したＭＡＣ演算を行う。当該相互認証処理では、記憶ユニット６１に記憶されているデータが用いられる。なお、相互認証ユニット６３は、必要に応じて、例えば、コンピュータ２あるいはネットワーク５上のコンピュータとの間でオーディオデータの入出力を行う動作に先立って、コンピュータ２あるいはネットワーク５上のコンピュータとの間で相互認証処理を行う。
【００７７】
暗号化／復号ユニット６４は、前述したように、ＦＩＰＳ ＰＵＢ ８１に規定されたＥＣＢモードおよびＣＢＣモードを選択的に用いてブロック暗号化を行う。ここで、暗号化／復号ユニット６４は、ＣＢＣモードにおいて、５６ビットの鍵データｋを用いて、コンピュータ２あるいはＣＤプレーヤ７から入力したオーディオデータ（平文）を、６４ビットからなる暗号化ブロックを単位として下記式（２）に基づいて暗号化して暗号化されたオーディオデータ（暗号文）を生成する。下記式（２）から分かるように、ＣＢＣモードでは、一つ前の暗号文と次の平文との排他的論理和を暗号化するため、同一の平文が入力されても異なる暗号文が出力され、解読が困難であるという利点がある。
【００７８】
【数２】
Ｃi ＝Ｅk （Ｐi ＸＯＲ Ｃi-1 ） ・・・（２）
ｉ：１以上の整数
Ｐi ：平文（６４ビット）
Ｃi ：暗号文（６４ビット）
ＸＯＲ：排他的論理和
Ｅk ：５６ビットの鍵データｋを用いたＤＥＳ方式の暗号処理
上記式（２）の演算は、図１８で表現される。なお、図１８において、「ＩＶ」は、ブロック暗号化初期値（６４ビット）であり、図２に示す携帯用記憶装置３のフラッシュメモリ３４において、図８に示すようにクラスタＣＬ内のサウンドユニットＳＵ（０）の直前に記憶される。
【００７９】
なお、コンピュータ２あるいはＣＤプレーヤ７から入力したオーディオデータ（平文）は、ＡＴＲＡＣ(Adaptive TRansform Audio Coder)方式を改良したＡＴＲＡＣ３方式で圧縮されている。なお、ＡＴＲＡＣは、ＭＤ(Mini Disk：商標) のための符号化圧縮方式であり、例えば、２８８ｋｂｉｔ／ｓで４４．１ｋＨｚサンプルのステレオ信号が、帯域分割とＭＤＣＴ(Modified Discrete Cosine Transform)とを併用して符号化されている。すなわち、先ず、帯域分割フィルタで１／４，１／４，１／２の３つの帯域に分割され、それぞれの帯域の信号がダウンサンプルされ、時間領域の信号としてＭＤＣＴで周波数領域に変換され、当該ＭＤＣＴの係数が適応ビット配分を行ってスカラ量子化されている。
【００８０】
暗号化／復号ユニット６４は、ＦＩＰＳ８１のモードのうち、前述したＥＣＢモードおよびＣＢＣモードの復号を選択的に行う。ここで、暗号化／復号ユニット６４は、ＣＢＣモードにおいて、５６ビットの鍵データｋを用いて、暗号文を、６４ビットからなる暗号化ブロックを単位として下記式（３）に基づいて復号して平文を生成する。
【００８１】
【数３】
Ｐi ＝Ｃi-1 ＸＯＲ Ｄk （Ｃi ） ・・・（３）
ｉ：１以上の整数
Ｐi ：平文（６４ビット）
Ｃi ：暗号文（６４ビット）
ＸＯＲ：排他的論理和
Ｄk ：５６ビットの鍵データｋを用いたＤＥＳ方式の復号処理
上記式（３）の演算は、図１９で表現される。なお、図１９において、「ＩＶ」は、ブロック暗号化初期値（６４ビット）であり、図２に示す携帯用記憶装置３のフラッシュメモリ３４において図８に示すようにクラスタＣＬ内のサウンドユニットＳＵ（０）の直前に記憶されたものが用いられる。
【００８２】
制御ユニット６５は、乱数発生ユニット６０、記憶ユニット６１、鍵生成／鍵演算ユニット６２、相互認証ユニット６３および暗号化／復号ユニット６４の処理を統括的に制御する。
【００８３】
〔編集モジュール４４〕
編集モジュール４４は、例えば、図４に示すように携帯用記憶装置３のフラッシュメモリ３４内に記憶されたトラックデータファイル１０１0 〜１０１3 を、ユーザからの操作指示に基づいて編集して新たなトラックデータファイルを生成する。当該編集には、１個のトラックデータファイルを分割して２個のトラックデータファイルを生成する分割編集処理と、２個のトラックデータファイルを結合して１個のトラックデータファイルを生成する結合編集処理とがある。なお、当該編集にあたって、再生管理ファイル１００およびトラックデータファイル１０１0 〜１０１3 が書き換えられる。編集モジュール４４における編集処理については後に詳細に説明する。
【００８４】
〔圧縮／伸長モジュール４５〕
圧縮／伸長モジュール４５は、例えば、携帯用記憶装置３から入力した暗号化されたオーディオデータを復号した後に再生する際に、ＡＴＲＡＣ３方式で圧縮されているオーディオデータを伸長し、当該伸長したオーディオデータをＤ／Ａ変換器４７に出力する。また、例えば、ＣＤプレーヤ７あるいはコンピュータ２から入力したオーディオデータを、携帯用記憶装置３に記憶する際に、当該オーディオデータをＡＴＲＡＣ３方式で圧縮する。
【００８５】
〔Ｄ／Ａ変換器４７〕
Ｄ／Ａ変換器４７は、圧縮／伸長モジュール４５から入力したデジタル形式のオーディオデータをアナログ形式のオーディオデータに変換してスピーカ４６に出力する。
【００８６】
〔スピーカ４６〕
スピーカ４６は、Ｄ／Ａ変換器４７から入力したオーディオデータに応じた音響を出力する。
【００８７】
〔Ａ／Ｄ変換器４８〕
Ａ／Ｄ変換器４８は、例えば、ＣＤプレーヤ７から入力したアナログ形式のオーディオデータをデジタル形式に変換して圧縮／伸長モジュール４５に出力する。
【００８８】
以下、図１に示すオーディオシステム１の動作について説明する。
【００８９】
携帯用記憶装置３への書き込み動作
図２０は、携帯用プレーヤ４から携帯用記憶装置３への書き込み動作を説明するためのフローチャートである。
【００９０】
ステップＳ１：携帯用プレーヤ４から携帯用記憶装置３に、書き込み要求信号が出力される。
【００９１】
ステップＳ２：携帯用記憶装置３と携帯用プレーヤ４との間で、相互認証処理を行う際に用いる認証鍵データＩＫj の選択処理が行われる。当該処理については後述する。
【００９２】
ステップＳ３：携帯用記憶装置３と携帯用プレーヤ４との間で相互認証処理が行われる。当該処理については後述する。
【００９３】
ステップＳ４：ステップＳ３の相互認証処理によって携帯用記憶装置３および携帯用プレーヤ４の双方が相手を正当であると認めた場合には、ステップＳ５の処理が行われ、そうでない場合には処理が終了する。
【００９４】
ステップＳ５：携帯用記憶装置３および携帯用プレーヤ４において、セッション鍵データＳｅｋが生成される。当該処理については後述する。
【００９５】
ステップＳ６：携帯用プレーヤ４から携帯用記憶装置３に、通信インターフェイス３２，４２を介して、暗号化したオーディオデータを出力して書き込む。当該処理については後述する。
【００９６】
このように、オーディオシステム１によれば、携帯用記憶装置３と携帯用プレーヤ４との間で相互認証が行われ、双方が相手を正当であると認めた場合にのみ、携帯用プレーヤ４から携帯用記憶装置３に、暗号化されたオーディオデータが書き込まれる。そのため、著作権侵害を招くようなオーディオデータの不正な複製が容易に行われることを回避できる。
【００９７】
〔認証鍵データＩＫj の選択処理（図２０に示すステップＳ２）〕
図２１は、認証鍵データＩＫj の選択処理を説明するための図である。図２１に示すように、図２に示す携帯用プレーヤ４の乱数発生ユニット６０によって６４ビットの乱数Ｒj が生成される。当該乱数Ｒj は、携帯用プレーヤ４から携帯用記憶装置３に出力される。そして、携帯用記憶装置３の相互認証ユニット５３によって、６４ビットの乱数Ｒj の下位５ビットを用いて、記憶ユニット５１に記憶されている認証鍵データＩＫ0 〜ＩＫ31のうち一の認証鍵データＩＫj （ｊは０≦ｊ≦３１を満たす整数）が特定される。
【００９８】
また、携帯用記憶装置３の記憶ユニット５１から読み出された装置識別データＩＤm が、携帯用記憶装置３から携帯用プレーヤ４に出力される。
【００９９】
そして、携帯用プレーヤ４の相互認証ユニット６３によって、乱数Ｒj の下位５ビットを用いて、マスター鍵データＭＫ0 〜ＭＫ31のうち一のマスター鍵データＭＫj が特定される。
【０１００】
そして、鍵生成／鍵演算ユニット６２において、前記特定されたマスター鍵データＭＫj と、携帯用記憶装置３から入力した装置識別データＩＤm とを用いて、下記式（４）に基づいて、認証鍵データＩＫj を生成する。下記式（４）において、ｆ（ａ，ｂ）は、例えば、引数ａ，ｂから値を導出する任意の関数である。
【０１０１】
【数４】
ＩＫj ＝ｆ（ＭＫj ，ＩＤm ） ・・・（４）
これにより、携帯用記憶装置３と携帯用プレーヤ４とが、上記式（４）に示す関係を持つ認証鍵データＩＫ0 〜ＩＫ31およびマスター鍵データＭＫ0 〜ＭＫ31を有している場合には、図２１に示す処理によって同じ認証鍵データＩＫj が選択される。当該選択された認証鍵データＩＫj は、後述する相互認証処理を行う際に、秘密鍵として用いられる。また、このとき、３２個の認証鍵データＩＫj のうち選択される認証鍵データは、図２１に示す処理を行う毎に乱数Ｒj に応じてランダムに決定される。そのため、不正な認証が成功する確率を、一の認証鍵データを固定して用いる場合の１／３２倍にすることができ、不正な認証が行われることを高い確率で回避できる。
【０１０２】
なお、上述した実施形態では、乱数を用いて８個の認証鍵データＩＫj のうち一の認証鍵データを選択する場合を例示したが、携帯用記憶装置３および携帯用プレーヤ４の外部から入力した鍵指定信号に基づいて選択する認証鍵データを決定してもよい。
【０１０３】
〔携帯用記憶装置３と携帯用プレーヤ４との間の相互認証処理（図２０に示すステップＳ３）〕
図２２は、携帯用記憶装置３と携帯用プレーヤ４との間の相互認証処理を説明するための図である。なお、当該相互認証処理を開始するときには、前述した図２１に示す認証鍵データＩＫj の選択処理が終了しており、携帯用プレーヤ４の相互認証ユニット５３と携帯用記憶装置３の相互認証ユニット６３は、選択した認証鍵データＩＫj 、携帯用記憶装置３の装置識別データＩＤm を有している。
【０１０４】
ステップＳ１０：携帯用記憶装置３の乱数発生ユニット５０において、６４ビットの乱数Ｒmsを生成し、これを携帯用プレーヤ４に出力する。
【０１０５】
ステップＳ１１：携帯用プレーヤ４の乱数発生ユニット６０において、６４ビットの乱数Ｒd およびＳd を生成する。
【０１０６】
ステップＳ１２：携帯用プレーヤ４の相互認証ユニット６３において、図２０に示すステップＳ２で得た認証鍵データＩＫj および「Ｒd ‖Ｒms‖ＩＤm 」を用いて、下記式（５）に基づいてＭＡＣ演算を行い、ＭＡＣA を求める。
【０１０７】
ここで、Ａ‖Ｂは、ＡとＢの連結（ｎビットのＡの後ろにｍビットのＢを結合して（ｎ＋ｍ）ビットとしたもの）を示す。
【０１０８】
【数５】
ＭＡＣA ＝ＭＡＣ（ＩＫj ，Ｒd ‖Ｒms‖ＩＤm ） ・・・（５）
ステップＳ１３：携帯用プレーヤ４は、「Ｒd ‖Ｓd ‖ＭＡＣA ‖ｊ」を携帯用記憶装置３に出力する。
【０１０９】
ステップＳ１４：携帯用記憶装置３の相互認証ユニット５３において、図２０に示すステップＳ２で得た認証鍵データＩＫj および「Ｒd ‖Ｒms‖ＩＤm 」を用いて、下記式（６）に基づいてＭＡＣ演算を行い、ＭＡＣB を求める。
【０１１０】
【数６】
ＭＡＣB ＝ＭＡＣ（ＩＫj ，Ｒd ‖Ｒms‖ＩＤm ） ・・・（６）
ステップＳ１５：携帯用記憶装置３の相互認証ユニット５３において、ステップＳ１４で求めたＭＡＣB とステップＳ１３で入力したＭＡＣA とを比較し、一致していれば、携帯用プレーヤ４が適切な認証鍵データＩＫj を有していることが分かるため、携帯用記憶装置３は携帯用プレーヤ４が正当な相手であると認証する。
【０１１１】
ステップＳ１６：携帯用記憶装置３の相互認証ユニット５３において、図２０に示すステップＳ２で得た認証鍵データＩＫj および「Ｒms‖Ｒd 」を用いて、下記式（７）に基づいてＭＡＣ演算を行い、ＭＡＣC を求める。
【０１１２】
【数７】
ＭＡＣC ＝ＭＡＣ（ＩＫj ，Ｒms‖Ｒd ） ・・・（７）
ステップＳ１７：携帯用記憶装置３の乱数発生ユニット５０において、６４ビットの乱数Ｓmsを生成する。
【０１１３】
ステップ１８：携帯用記憶装置３から携帯用プレーヤ４に、「Ｓms‖ＭＡＣC 」を出力する。
【０１１４】
ステップＳ１９：携帯用プレーヤ４の相互認証ユニット６３において下記式（８）に基づいてＭＡＣ演算を行い、ＭＡＣd を求める。
【０１１５】
【数８】
ＭＡＣd ＝ＭＡＣ（ＩＫj ，Ｒms‖Ｒd ） ・・・（８）
ステップＳ２０：携帯用プレーヤ４の相互認証ユニット６３において、ステップＳ１９で求めたＭＡＣd とステップＳ１８で入力したＭＡＣC とを比較し、一致していれば、携帯用記憶装置３が適切な認証鍵データＩＫj を有していることが分かるため、携帯用プレーヤ４は携帯用記憶装置３が正当な相手であると認証する。以上の処理によって、携帯用記憶装置３と携帯用プレーヤ４との間の相互認証が行われる。
【０１１６】
〔セッション鍵データＳｅｋの生成処理（図２０に示すステップＳ５）〕
図２３は、セッション鍵データＳｅｋの生成処理を説明するための図である。なお、当該セッション鍵データＳｅｋの生成処理を開始するときには、前述した図２１に示す認証鍵データＩＫj の選択処理および図２２に示す相互認証処理が終了しており、携帯用記憶装置３および携帯用プレーヤ４の双方は、選択した認証鍵データＩＫj および乱数Ｓd ，Ｓmsを有している。
【０１１７】
ステップＳ３０：携帯用プレーヤ４の相互認証ユニット６３は、選択した認証鍵データＩＫj および「Ｓd ‖Ｓms」を用いて、下記式（９）に基づいてＭＡＣ演算を行い、セッション鍵データＳｅｋを生成する。
【０１１８】
【数９】
セッション鍵データＳｅｋ＝ＭＡＣ（ＩＫj ，Ｓd ‖Ｓms） ・・・（９）
ステップＳ３１：携帯用記憶装置３の相互認証ユニット５３は、選択した認証鍵データＩＫj および「Ｓd ‖Ｓms」を用いて、下記式（１０）に基づいてＭＡＣ演算を行い、セッション鍵データＳｅｋを生成する。当該セッション鍵データＳｅｋは、正当な相手同士であれば、携帯用プレーヤ４で生成したセッション鍵データＳｅｋと同じになる。
【０１１９】
【数１０】
セッション鍵データＳｅｋ＝ＭＡＣ（ＩＫj ，Ｓd ‖Ｓms） ・・・（１０）
〔携帯用記憶装置３へのオーディオデータの書き込み処理（図２０に示すステップＳ６）〕
図２４は、携帯用プレーヤ４から携帯用記憶装置３へのオーディオデータの書き込み処理を説明するための図である。なお、当該書き込み処理を開始するときには、前述した図２３に示すセッション鍵データＳｅｋの生成処理は終了しており、携帯用記憶装置３および携帯用プレーヤ４は同じセッション鍵データＳｅｋを有している。
【０１２０】
ステップＳ４０：携帯用プレーヤ４は、乱数発生ユニット６０にトラックデータファイル毎に乱数を発生させ、当該乱数に応じたコンテンツ鍵データＣＫを生成する。
【０１２１】
ステップＳ４１：携帯用プレーヤ４は、暗号化／復号ユニット６４において、ステップＳ４０で生成したコンテンツ鍵データＣＫを、セッション鍵データＳｅｋを用いて暗号化する。
【０１２２】
ステップ４２：携帯用プレーヤ４は、ステップＳ４１で暗号化したコンテンツ鍵データＣＫを携帯用記憶装置３に出力する。
【０１２３】
ステップＳ４３：携帯用記憶装置３は、ステップＳ４２で入力した暗号化されたコンテンツ鍵データＣＫを、暗号化／復号ユニット５４において復号する。
【０１２４】
ステップＳ４４：携帯用記憶装置３は、暗号化／復号ユニット５４において、ステップＳ４３で復号したコンテンツ鍵データＣＫを、記憶ユニット５１から読み出した記憶用鍵データＳＫm を用いて暗号化する。
【０１２５】
ステップＳ４５：携帯用記憶装置３は、当該暗号化されたコンテンツ鍵データＣＫを携帯用プレーヤ４に出力する。
【０１２６】
ステップＳ４６：携帯用プレーヤ４は、当該暗号化されたコンテンツ鍵データＣＫを、トラックデータファイル１００ｎ内のＴＲＫＩＮＦ内に設定する。
【０１２７】
ステップＳ４７：携帯用プレーヤ４は、乱数発生ユニット６０にパーツ毎に乱数を発生させ、当該乱数に応じたパーツ鍵データＰＫを生成する。また、携帯用プレーヤ４は、当該生成したパーツ鍵データＰＫを、トラックデータファイル１０１ｎの管理データＰＲＴＩＮＦ内に設定する。
【０１２８】
ステップＳ４８：携帯用プレーヤ４は、例えば、パーツ毎に、鍵生成／演算ユニット６２において、下記式（１１）に示すように、ステップＳ４７で生成したパーツ鍵データＰＫとコンテンツ鍵データＣＫとの排他的論理和を演算し、当該演算結果をテンポラリ鍵データＴＭＫとする。なお、テンポラリ鍵データＴＭＫの生成は、排他的論理和を用いるものには限定されず、例えば、パーツ鍵データＰＫとコンテンツ鍵データＣＫとを加算する加算演算やその他の関数演算を用いるようにしてもよい。
【０１２９】
【数１１】
ＴＭＫ＝ＰＫ ＸＯＲ ＣＫ ・・・（１１）
ステップＳ４９：携帯用プレーヤ４は、乱数発生ユニット６０にブロック毎に乱数を発生させ、当該乱数に応じたブロックシードデータＢＳを生成する。また、携帯用プレーヤ４は、当該生成したブロックシードデータＢＳを、当該ブロック内の図１０に示す対応する位置に設定する。
【０１３０】
ステップＳ５０：携帯用プレーヤ４は、例えば、鍵生成／鍵演算ユニット６２において、下記式（１２）に示すように、ステップＳ４６で生成したテンポラリ鍵データＴＭＫと、ステップＳ４７で生成したブロックシードデータＢＳとを用いてＭＡＣ演算を行い、ブロック毎にブロック鍵データＢＫを生成する。
【０１３１】
【数１２】
ＢＫ＝ＭＡＣ（ＴＭＫ，ＢＳ） ・・・（１２）
なお、ＭＡＣ演算の他に、例えば、ＳＨＡ−１(Secure Hash Algorithm) 、ＲＩＰＥＭＤ−１６０などの一方向性ハッシュ関数(one-way hash function) の入力に秘密鍵を用いた演算を行ってブロック鍵データＢＫを生成してもよい。
【０１３２】
ここで、一方向性関数ｆとは、ｘよりｙ＝ｆ（ｘ）を計算することは容易であるが、逆にｙよりｘを求めることが難しい関数をいう。一方向性ハッシュ関数については、例えば、"Handbook of Applied Cryptography,CRC Press"などに詳しく記述されている。
【０１３３】
ステップＳ５１：携帯用プレーヤ４は、コンピュータ２あるいは携帯用プレーヤ４から入力したオーディオデータを、圧縮／伸長モジュール４５において、ＡＴＲＡＣ３方式で圧縮する。そして、暗号化／復号ユニット６４において、ステップＳ５０で生成したブロック鍵データＢＫを用いて、前記圧縮したオーディオデータをＣＢＣモードで暗号化する。
【０１３４】
ステップＳ５２：携帯用プレーヤ４は、ステップＳ５１で暗号化したオーディオデータに属性ヘッダを付加して、通信インターフェイス３２，４２を介して、携帯用記憶装置３に出力する。
【０１３５】
ステップＳ５３：携帯用記憶装置３は、ステップＳ５２で入力した暗号化されたオーディオデータと属性ヘッダを、フラッシュメモリ３４にそのまま書き込む。以上の処理によって、携帯用プレーヤ４から携帯用プレーヤ４へのオーディオデータの書き込み処理が終了する。なお、ここでは、図４のトラックデータファイル１０１0 〜１０１3 についてのみ述べたが、携帯用プレーヤ４は、図４の再生管理ファイルについても同様に適宜更新を行う。
【０１３６】
携帯用記憶装置３からの読み出し動作
図２５は、携帯用記憶装置３から携帯用プレーヤ４への読み出し動作を説明するためのフローチャートである。
【０１３７】
ステップＳ６１：携帯用プレーヤ４から携帯用記憶装置３に、読み出しを要求するトラックデータ（曲）を特定した読み出し要求信号が出力される。
【０１３８】
ステップＳ２：図２１を用いて前述したように、携帯用記憶装置３と携帯用プレーヤ４との間で相互認証処理を行う際に用いる認証鍵データＩＫj の選択処理が行われる。
【０１３９】
ステップＳ３：図２２を用いて前述したように、携帯用記憶装置３と携帯用プレーヤ４との間で相互認証処理が行われる。
【０１４０】
ステップＳ４：ステップＳ３の相互認証処理によって携帯用記憶装置３および携帯用プレーヤ４の双方が相手を正当であると認めた場合には、ステップＳ５の処理が行われ、そうでない場合には処理が終了する。
【０１４１】
ステップＳ５：携帯用記憶装置３および携帯用プレーヤ４において、セッション鍵データＳｅｋが生成される。
【０１４２】
ステップＳ６３：暗号化されたオーディオデータを、通信インターフェイス３２，４２を介して、携帯用記憶装置３から携帯用プレーヤ４に読み出す。当該処理については後述する。
【０１４３】
すなわち、オーディオシステム１では、携帯用記憶装置３と携帯用プレーヤ４との間で相互認証が行われ、双方が相手を正当であると認めた場合にのみ、後述するように、携帯用プレーヤ４において、携帯用記憶装置３から携帯用プレーヤ４に出力された暗号化されたコンテンツ鍵データＣＫを適切なセッション鍵データＳｅｋで解読できる。そのため、著作権侵害を招くようなオーディオデータの不正な利用が容易に行われることを回避できる。
【０１４４】
〔携帯用記憶装置３からのオーディオデータの読み出し処理（図２５に示すステップＳ６３）〕
図２６は、携帯用記憶装置３から携帯用プレーヤ４へのオーディオデータの読み出し処理を説明するための図である。なお、当該読み出し処理は、前述した図２０に示す書き込み処理の後に行われるため、図４に示すトラックデータファイル１０１0 〜１０１3 には、図１０に示すように、ＴＲＩＮＦにコンテンツ鍵データＣＫが設定され、パーツ毎にパーツ鍵データＰＫが設定され、各クラスタＣＬ内にはブロックシードデータＢＳが設定されている。また、ステップＳ５の処理が終了しているため、携帯用記憶装置３および携帯用プレーヤ４は、正当な相手同士であれば、同じセッション鍵データＳｅｋを有している。
【０１４５】
ステップＳ７１：携帯用記憶装置３は、フラッシュメモリ３４に記憶されている図４に示すトラックデータファイル１０１0 〜１０１3 のうち読み出し要求信号で特定されるトラックデータに対応するトラックデータファイルを特定し、当該特定したトラックデータファイルを構成するクラスタ内のオーディオデータを、サウンドユニットＳＵを単位として読み出して携帯用プレーヤ４に出力する。携帯用記憶装置３は、また、上記トラックデータファイルの属性ヘッダを読み出して携帯用プレーヤ４に出力する。
【０１４６】
ステップＳ７２：携帯用プレーヤ４は、当該入力された属性ヘッダのうち、ＴＲＩＮＦから暗号化されたコンテンツ鍵ＣＫを抽出し、携帯用記憶装置３に出力する。
【０１４７】
ステップＳ７３：携帯用記憶装置３の暗号化／復号ユニット５４は、ステップＳ７２で入力されたコンテンツ鍵データＣＫを、記憶ユニット５１に記憶されている記憶用鍵データＳＫm を用いて復号する。
【０１４８】
ステップＳ７４：携帯用記憶装置３の暗号化／復号ユニット５４は、ステップＳ７３で復号したコンテンツ鍵データＣＫを、図２５に示すステップＳ５で得られたセッション鍵データＳｅｋを用いて暗号化する。
【０１４９】
ステップＳ７５：携帯用記憶装置３は、ステップＳ７４で暗号化したコンテンツ鍵データＣＫを携帯用プレーヤ４に出力する。
【０１５０】
ステップＳ７６：携帯用プレーヤ４の暗号化／復号ユニット６４は、ステップＳ７３で携帯用記憶装置３から入力したコンテンツ鍵データＣＫを、セッション鍵データＳｅｋを用いて復号する。
【０１５１】
ステップＳ７７：携帯用プレーヤ４の鍵生成／演算ユニット６２は、ステップＳ７６で復号されたコンテンツ鍵データＣＫと、ステップＳ７１で入力された属性ヘッダの中のＰＲＴＩＮＦに含まれるパーツ鍵データＰＫとの排他的論理和を演算し、当該演算結果をテンポラリ鍵データＴＭＫとする。
【０１５２】
【数１３】
ＴＭＫ＝ＰＫ ＸＯＲ ＣＫ ・・・（１３）
ステップＳ７８：携帯用プレーヤ４の鍵生成／鍵演算ユニット６２において、ステップＳ７６で生成したテンポラリ鍵データＴＭＫと、ステップＳ７１で入力されたトラックデータファイルのクラスタ内の図１０に示すブロックシードデータＢＳとを用いて、下記式（１４）に示すＭＡＣ演算を行い、当該演算結果をブロック鍵データＢＫとする。ブロック鍵データＢＫは、ブロック毎に求められる。
【０１５３】
【数１４】
ＢＫ＝ＭＡＣ（ＴＭＫ，ＢＳ） ・・・（１４）
ステップＳ７９：携帯用プレーヤ４は、暗号化／復号ユニット６４において、ステップＳ７８で生成したブロック鍵データＢＫを用いて、ステップＳ７１で入力したオーディオデータを復号する。このとき、オーディオデータの復号は、各ブロック毎に、それそれ個別に求められたブロック鍵データＢＫを用いて行われる。また、復号は、暗号化の単位である８バイトのブロックを単位として行われる。
【０１５４】
ステップＳ８０：携帯用プレーヤ４は、圧縮／伸長モジュール４５において、ステップＳ７９で復号したオーディオデータをＡＴＲＡＣ３方式で伸長し、当該伸長したオーディオデータを、Ｄ／Ａ変換器４７でデジタル形式に変換した後に、スピーカ４６に出力する。このとき、圧縮／伸長モジュール４５は、ステップＳ７８で復号したオーディオデータを、サウンドユニットＳＵを単位として伸長する。以上の処理によって、携帯用記憶装置３から携帯用プレーヤ４４へのオーディオデータの読み出しおよび再生が終了する。
【０１５５】
〔トラックデータファイルの分割編集処理〕
前述したように、携帯用プレーヤ４の編集モジュール４４は、１個のトラックデータファイルを分割して２個のトラックデータファイルを生成する分割編集処理と、２個のトラックデータファイルを結合して１個のトラックデータファイルを生成する結合編集処理とを行う。
【０１５６】
先ず、分割編集処理について説明する。図２７は、携帯用プレーヤ４の編集モジュール４４によるトラックデータファイルの分割編集処理を説明するための図である。編集モジュール４４は、例えば、図２７Ａに示す１個のトラックデータファイル（１）を、図２７Ｂに示すトラックデータファイル（１）と、図２７Ｃに示すトラックデータファイル（２）とに分割する。このとき、分割の区切りとなる最小単位はサウンドユニットＳＵであり、当該例では、図２７Ｂに示すように、トラックデータファイル（１）のクラスタＣＬ（２）のサウンドユニットＳＵ（３）とＳＵ（４）との間で分割されている。
【０１５７】
当該分割により、分割後のトラックデータファイル（１）のクラスタＣＬ（２）は図２８Ａに示すようになり、新たに生成されたトラックデータファイル（２）のクラスタＣＬ（０）は図２８Ｂに示すようになる。このとき、図２８Ｂに示すように、トラックデータファイル（２）のクラスタＣＬ（０）のサウンドユニットＳＵ（０）は分割前のトラックデータファイル（１）のクラスタ（２）のサウンドユニットＳＵ（４）となり、ラックデータファイル（２）のクラスタＣＬ（０）のサウンドユニットＳＵ（１）は分割前のトラックデータファイル（１）のクラスタ（２）のサウンドユニットＳＵ（５）となる。また、図２８Ｂに示すトラックデータファイル（２）のクラスタＣＬ（０）のブロック暗号化初期値ＩＶには、図２７Ａ，Ｂに示すトラックデータファイル（１）のクラスタＣＬ（２）内のサウンドユニットＳＵ（３）の最後の８バイトが設定される。
【０１５８】
本実施形態では、前述したように各クラスタ内において、最初のサウンドユニットＳＵ（０）の直前にブロック暗号化初期値ＩＶを配置したことで、分割の際に、分割位置の直前の８バイトをそのままブロック暗号化初期値ＩＶとして用いれば良く、新たなトラックデータファイルを作成する際の処理を簡単にできる。また、再生時に、サウンドユニットＳＵ（０）と共に、その直前のブロック暗号化初期値ＩＶを読み出せばよいため、再生処理も簡単になる。
【０１５９】
本実施形態では、分割前のトラックデータファイル（１）のコンテンツ鍵データ、パーツ鍵データおよびブロック鍵データは、それぞれＣＫ＿１、ＰＫ＿１およびＢＫ＿１である。また、分割後のトラックデータファイル（１）のコンテンツ鍵データ、パーツ鍵データおよびブロック鍵データは、それぞれＣＫ＿１’、ＰＫ＿１’およびＢＫ＿１である。また、トラックデータファイル（２）のコンテンツ鍵データ、パーツ鍵データおよびブロック鍵データは、それぞれＣＫ＿２、ＰＫ＿２およびＢＫ＿１である。
【０１６０】
図２９は、携帯用プレーヤ４の編集モジュール４４において、新たなトラックデータファイル（２）のコンテンツ鍵データおよびパーツ鍵データを生成する方法を説明するための図である。分割により生成された新たなトラックデータファイル（２）は、トラックデータファイル（１）とは別に新たなコンテンツ鍵データＣＫ＿２を有する。本実施形態では、パーツ鍵データＰＫ＿２を以下に示すように算出することで、ブロック鍵データＢＫ＿１を分割前と同じにする。
【０１６１】
ステップＳ９０：編集モジュール４４は、トラックデータファイルの分割指示を入力したか否かを判断し、入力したと判断した場合にはステップＳ９１の処理を実行し、入力していないと判断した場合にはステップＳ９０の処理を繰り返す。
【０１６２】
ステップＳ９１：編集モジュール４４は、乱数発生ユニット６０に乱数を発生させ、当該乱数に応じたコンテンツ鍵データＣＫ＿２を新たに生成する。
【０１６３】
ステップＳ９２：携帯用記憶装置３の暗号化／復号ユニット５４において、ステップＳ９１で生成したコンテンツ鍵データＣＫ＿２を、記憶ユニット５１に記憶されている記憶用鍵データＳＫm を用いて暗号化する。
【０１６４】
ステップＳ９３：編集モジュール４４は、当該暗号化されたコンテンツ鍵データＣＫ＿２を、当該トラックデータファイルのＴＲＫＩＮＦに書き込む。
【０１６５】
ステップＳ９４：編集モジュール４４は、トラックデータファイル（２）のパーツ鍵データＰＫ＿２を下記式（１５）に基づいて生成する。
【０１６６】
【数１５】
ＰＫ＿２＝ＣＫ＿１ ＸＯＲ ＰＫ＿１ ＸＯＲ ＣＫ＿２・・・（１５）
これにより、トラックデータファイル（２）について、前記式（１１）に基づいてされるテンポラリ鍵データは、トラックデータファイル（１）のテンポラリ鍵データと同じになり、前記式（１２）に基づいて生成されるブロック鍵データも分割前のブロック鍵データＢＫ＿１と同じにできる。そのため、トラックデータファイル（２）内のサウンドユニットＳＵを新たなブロック鍵データを用いて再度暗号化する必要がない。
【０１６７】
ステップＳ９５：編集モジュール４４は、ステップＳ９４で生成したパーツ鍵データＰＫ＿２を、当該トラックデータファイルＰＲＴＩＮＦにそのまま書き込む。
【０１６８】
このように、オーディオシステム１では、分割して新たに生成したトラックデータファイル（２）のコンテンツ鍵データとして、新たなコンテンツ鍵データＣＫ＿２を用いた場合でも、上記式（１５）に基づいてパーツ鍵データＰＫ＿２を生成することで、テンポラリ鍵データを分割前のテンポラリ鍵データと同じにできる。その結果、ブロック鍵データも分割前のブロック鍵データＢＫ＿１と同じにでき、トラックデータファイル（２）内のサウンドユニットＳＵを新たなブロック鍵データを用いて再度暗号化する必要がない。また、同様に、分割後のトラックデータファイル（１）のパーツ鍵データＰＫ＿１’も、ブロック鍵データＢＫ＿１を変えないように、コンテンツ鍵データＣＫ＿１’に応じた決定される。その結果、分割後のトラックデータファイル（１）内のサウンドユニットＳＵを新たなブロック鍵データを用いて再度暗号化する必要もない。そのため、トラックデータファイルの分割編集に伴い演算量が大幅に増加することを回避できる。なお、ここでは、図４のトラックデータファイルについてのみ述べたが、編集モジュール４４は、図４の再生管理ファイル１００についても同様に適宜更新を行う。
【０１６９】
次に、トラックデータファイルの結合編集処理について説明する。図３０は、携帯用プレーヤ４の編集モジュール４４によるトラックデータファイルの結合編集処理を説明するための図である。図３０に示すように、編集モジュール４４は、例えば、図３０Ａに示すトラックデータファイル（１）と、図３０Ｂに示すトラックデータファイル（２）とを結合して、図３０Ｃに示すトラックデータファイル（３）を生成する。
【０１７０】
当該結合により、結合前のトラックデータファイル（１）からなるパーツ（１）と、結合前のトラックデータファイル（２）からなるパーツ（２）とを含む新たなトラックデータファイル（３）が生成される。また、トラックデータファイル（３）のコンテンツ鍵データとして新たなコンテンツ鍵データＣＫ＿３が生成され、パーツ（１）のパーツ鍵データＰＫ＿３＿１およびパーツ（２）のパーツ鍵データＰＫ＿３＿２が後述するようにして新たに生成される。また、当該トラックデータファイル（３）のＴＲＫＩＮＦおよびＰＲＴＩＮＦに、新たに生成された鍵データが後述するように設定される。
【０１７１】
また、パーツ（１）の図６に示すＰＲＴＳＩＺＥが示す開始クラスタおよび終了クラスタとして、結合前のトラックデータファイル（１）のクラスタＣＬ（０）およびＣＬ（４）がそれぞれ設定される。また、パーツ（２）のＰＲＴＳＩＺＥが示す開始クラスタおよび終了クラスタとして、結合前のトラックデータファイル（２）のクラスタＣＬ（０）およびＣＬ（５）がそれぞれ設定される。
【０１７２】
図３１は、携帯用プレーヤ４の編集モジュール４４において、新たに生成したトラックデータファイル（３）のパーツ（１）および（２）のパーツ鍵データを生成する処理を説明するための図である。なお、本実施形態では、結合の対象となるトラックデータファイル（１）がコンテンツ鍵データＣＫ＿１、パーツ鍵データＰＫ＿１およびブロック鍵データＢＫ＿１を用いており、トラックデータファイル（２）がコンテンツ鍵データＣＫ＿２、パーツ鍵データＰＫ＿２およびブロック鍵データＢＫ＿２を用いてる場合を例示して説明する。
【０１７３】
ここで、トラックデータファイル（３）は新たなコンテンツ鍵データＣＫ＿３を得るが、パーツ（１）および（２）のパーツ鍵データを以下に示すように算出することで、各ブロックのブロック鍵データＢＫ＿１およびＢＫ＿２を結合前と同じにできる。
【０１７４】
ステップＳ１００：編集モジュール４４は、トラックデータファイルの結合指示を入力したか否かを判断し、入力したと判断した場合にはステップＳ１０１の処理を実行し、入力していないと判断した場合にはステップＳ１００の処理を繰り返す。
【０１７５】
ステップＳ１０１：編集モジュール４４は、乱数発生ユニット６０に乱数を発生させ、当該乱数に応じたコンテンツ鍵データＣＫ＿３を新たに生成する。
【０１７６】
ステップＳ１０２：携帯用記憶装置３の暗号化／復号ユニット５４において、ステップＳ１０１で生成したコンテンツ鍵データＣＫ＿３を、記憶ユニット５１に記憶されている記憶用鍵データＳＫm を用いて暗号化する。
【０１７７】
ステップＳ１０３：編集モジュール４４は、当該暗号化されたコンテンツ鍵データＣＫ＿３を当該トラックデータファイルのＴＲＫＩＮＦに書き込む。
【０１７８】
ステップＳ１０４：編集モジュール４４は、トラックデータファイル（３）のパーツ（１）のパーツ鍵データＰＫ＿３＿１を下記式（１６）に基づいて生成する。
【０１７９】
【数１６】
ＰＫ＿３＿１＝ＣＫ＿１ ＸＯＲ ＰＫ＿１ ＸＯＲ ＣＫ＿３・・・（１６）
これにより、前記式（１１）に基づいて生成されるパーツ（１）のテンポラリ鍵データを結合前のトラックデータファイル（１）のテンポラリ鍵データと同じにでき、その結果、前記式（１２）に基づいて生成されるパーツ（１）のブロック鍵データも結合前のトラックデータファイル（１）のブロック鍵データＢＫ＿１と同じにできる。そのため、パーツ（１）のサウンドユニットＳＵを新たなブロック鍵データを用いて再度暗号化する必要がない。
【０１８０】
ステップＳ１０５：編集モジュール４４は、トラックデータファイル（３）のパーツ（２）のパーツ鍵データＰＫ＿３＿２を下記式（１７）に基づいて生成する。
【０１８１】
【数１７】
ＰＫ＿３＿２＝ＣＫ＿２ ＸＯＲ ＰＫ＿２ ＸＯＲ ＣＫ＿３・・・（１７）
これにより、前記式（１１）に基づいて生成されるパーツ（２）のテンポラリ鍵データを結合前のトラックデータファイル（２）のテンポラリ鍵データと同じにでき、その結果、前記式（１２）に基づいて生成されるパーツ（２）のブロック鍵データも結合前のトラックデータファイル（２）のブロック鍵データＢＫ＿２と同じにできる。そのため、パーツ（２）のサウンドユニットＳＵを新たなブロック鍵データを用いて再度暗号化する必要がない。
【０１８２】
ステップＳ１０６：編集モジュール４４は、ステップＳ１０４で生成したパーツ鍵データＰＫ＿３＿１をトラックデータファイル（３）のパーツ（１）のＰＲＴＩＮＦにそのまま書き込む。
【０１８３】
ステップＳ１０７：編集モジュール４４は、ステップＳ１０５で生成したパーツ鍵データＰＫ＿３＿２をトラックデータファイル（３）のパーツ（２）のＰＲＴＩＮＦにそのまま書き込む。
【０１８４】
このように、オーディオシステム１では、結合して新たに生成したトラックデータファイル（３）のコンテンツ鍵データとして、新たなコンテンツ鍵データＣＫ＿３を用いた場合でも、上記式（１６）および（１７）に基づいてパーツ鍵データＰＫ＿３＿１およびＰＫ＿３＿２を生成することで、各パーツのテンポラリ鍵データを結合前と同じにできる。その結果、各パーツのブロック鍵データも結合前のブロック鍵データＢＫ＿１およびＢＫ＿２とそれぞれ同じにでき、パーツ（１）および（２）内のサウンドユニットＳＵを新たなブロック鍵データを用いて再度暗号化する必要がない。そのため、トラックデータファイルの結合編集に伴い演算量が大幅に増加することを回避できる。なお、ここでは、図４のトラックデータファイルについてのみ述べたが、編集モジュール４４は、図４の再生管理ファイルについても同様に適宜更新を行う。
【０１８５】
この発明は、上述した実施形態等に限定されるものでは無く、この発明の要旨を逸脱しない範囲内で様々な変形や応用が可能である。例えば、上述した実施形態では、ＡＴＲＡＣ３方式の圧縮の単位であるサウンドユニットＳＵのバイト数（１６０バイト）が、ＣＢＣモードの暗号化の単位である暗号化ブロックのバイト数（８バイト）の整数倍になる場合を例示したが、この発明は、例えば、整数倍にならない場合には、サウンドユニットＳＵにデータ長調整用のデータであるパディング(padding) を挿入して調整するようにしてもよい。
【０１８６】
また、上述した実施形態では、携帯用記憶装置３と携帯用プレーヤ４との間で相互認証処理を行う場合に、図２２に示すように、先ず始めに携帯用記憶装置３で生成した乱数Ｒmsを携帯用プレーヤ４に出力する場合を例示したが、先ず始めに携帯用プレーヤ４で生成した乱数を携帯用記憶装置３に出力するようにしてもよい。
【０１８７】
また、上述した実施形態では、図２１に示すように、記憶ユニット５１および６１に３２組の認証鍵データおよびマスター鍵データを記憶した場合を例示したが、これらの組の数は２以上であれば任意である。
【０１８８】
また、上述した実施形態では、図２１に示すように、携帯用プレーヤ４において、マスター鍵データＭＫ0 〜ＭＫ31から認証鍵データＩＫ0 〜ＩＫ31を生成する場合を例示したが、携帯用プレーヤ４に、携帯用記憶装置３と同じように、認証鍵データＩＫ0 〜ＩＫ31を記憶し、乱数Ｒj に応じた認証鍵データを選択するようにしてもよい。
【０１８９】
また、上述した実施形態では、図２１に示すように、携帯用記憶装置３および携帯用プレーヤ４において、携帯用プレーヤ４で生成した乱数Ｒj を用いて、認証鍵データＩＫj およびマスタ−鍵データＭＫj を選択する場合を例示したが、携帯用記憶装置３で生成した乱数を用いてもよいし、携帯用記憶装置３および携帯用プレーヤ４の双方で発生した乱数を用いてもよい。
【０１９０】
また、上述した実施形態では、図２１に示すように、携帯用記憶装置３および携帯用プレーヤ４において乱数Ｒj に基づいて認証鍵データＩＫj およびマスタ−鍵データＭＫj を選択する場合を例示したが、この発明は、例えば、携帯用記憶装置３および携帯用プレーヤ４に外部から５ビットの鍵選択指示データを入力し、当該鍵選択指示データで指示される相互に対応する認証鍵データＩＫj およびマスタ−鍵データＭＫj を、携帯用記憶装置３および携帯用プレーヤ４で選択してもよい。
【０１９１】
また、上述した実施形態では、トラックデータとしてオーディオデータを含むデータを例示したが、この発明は、その他、動画像データ、静止画像データ、文書データおよびプログラムデータなどを含むトラックデータをフラッシュメモリ３４に記憶する場合にも適用できる。
【０１９２】
【発明の効果】
以上説明したように、この発明のデータ処理システムおよびその方法によれば、記憶手段に記憶された暗号化されたデータを、所定の処理ブロックを単位として効率的に処理できる。
【図面の簡単な説明】
【図１】この発明の一実施形態のオーディオシステムのシステム構成を示すブロック図である。
【図２】携帯用記憶装置および携帯用プレーヤの内部構成を示すブロック図である。
【図３】携帯用記憶装置内の記憶ユニットに記憶されているデータを説明するための略線図である。
【図４】携帯用記憶装置のフラッシュメモリに記憶されるデータを説明するための略線図である。
【図５】再生管理ファイルのデータ構成を概略的に示す略線図である。
【図６】データファイルのデータ構成を概略的に示す略線図である。
【図７】再生管理ファイルのデータ構成をより詳細に示す略線図である。
【図８】再生管理ファイルの各部分と付加情報領域の構成を示す略線図である。
【図９】携帯用プレーヤの記憶ユニットに記憶されているデータを説明するための略線図である。
【図１０】データファイルのデータ構成をより詳細に示す略線図である。
【図１１】データファイルの属性ヘッダの一部を示す略線図である。
【図１２】データファイルの属性ヘッダの一部を示す略線図である。
【図１３】録音モードの種類と、各録音モードにおける録音時間等を示す略線図である。
【図１４】コピー制御情報を説明するための略線図である。
【図１５】データファイルの属性ヘッダの一部を示す略線図である。
【図１６】データファイルの各データブロックのヘッダを示す略線図である。
【図１７】携帯用プレーヤの記憶ユニットに記憶されているデータを説明するための略線図である。
【図１８】携帯用プレーヤの暗号化／復号ユニットのＣＢＣモードにおける暗号化処理を説明するための略線図である。
【図１９】携帯用プレーヤの暗号化／復号ユニットのＣＢＣモードにおける復号処理を説明するための略線図である。
【図２０】携帯用プレーヤから携帯用記憶装置への書き込み動作を説明するためのフローチャートである。
【図２１】相互認証ユニットによる認証鍵データＩＫj の選択処理を説明するための略線図である。
【図２２】携帯用記憶装置と携帯用プレーヤとの間の相互認証処理を説明するためのフローチャートである。
【図２３】セッション鍵データＳｅｋの生成処理を説明するための略線図である。
【図２４】携帯用プレーヤから携帯用記憶装置へのオーディオデータの書き込み処理を説明するためのフローチャートである。
【図２５】携帯用記憶装置から携帯用プレーヤへの読み出し動作を説明するためのフローチャートである。
【図２６】携帯用記憶装置から携帯用プレーヤへのオーディオデータの読み出し処理を説明するためのフローチャートである。
【図２７】携帯用プレーヤの編集モジュールによるトラックデータファイルの分割編集処理を説明するための略線図である。
【図２８】分割編集処理を行った後のクラスタ内のデータを説明するための略線図である。
【図２９】携帯用プレーヤの編集モジュールにおいて、分割編集時に、新たなトラックデータファイルのコンテンツ鍵データおよびパーツ鍵データを生成する方法を説明するためのフローチャートである。
【図３０】携帯用プレーヤの編集モジュールによるトラックデータファイルの結合編集処理を説明するための略線図である。
【図３１】携帯用プレーヤ４の編集モジュールにおいて、新たに生成したトラックデータファイル（３）のパーツ（１）および（２）のパーツ鍵データを生成する処理を説明するための略線図である。
【符号の説明】
１・・・オーディオシステム、２・・・コンピュータ、３・・・携帯用記憶装置、４・・・携帯用プレーヤ、５・・・ネットワーク、３３，４３・・・制御モジュール、５０，６０・・・乱数発生ユニット、５１，６１・・・記憶ユニット、５２，６２・・・鍵生成／演算ユニット、５３，６３・・・相互認証ユニット、５４，７４・・・暗号化／復号ユニット、５５，６５・・・制御ユニット、３４・・・フラッシュメモリ、４４・・・編集モジュール、４５・・・圧縮／伸長モジュール、４６・・・スピーカ
Claims (15)
- 所定のデータ長の暗号化ブロックを単位としてデータを暗号化する暗号化手段と、
上記暗号化ブロックの整数倍のデータ長を持つ処理ブロックを単位としてデータに圧縮処理を行う処理手段と、
上記暗号化したデータを記憶する記憶手段と、
一の上記暗号化ブロックを構成するデータが同じ上記処理ブロック内に位置するように、上記暗号化したデータを上記記憶手段に書き込み、上記処理ブロックを単位として上記データを上記記憶手段から読み出す制御手段とを有し、
上記制御手段は、単数または複数の上記処理ブロックを暗号化された順で上記記憶手段の連続したアドレスに記憶し、さらに、上記処理ブロック内の単数または複数の暗号化ブロックを暗号化された順で上記記憶手段の連続したアドレスに記憶し、クラスタ内で最初に暗号化された処理ブロック内でさらに最初に暗号化された暗号化ブロックが記憶された上記記憶手段のアドレスの直前のアドレスにブロック暗号化初期値を記憶するデータ処理装置。 - 請求項１において、
上記制御手段は、上記処理ブロックにデータ長調整用のデータを入れて、上記処理ブロックのデータ長が上記暗号化ブロックのデータ長の整数倍になるように調整するデータ処理装置。 - 請求項１において、
上記暗号化手段は、上記暗号化を行おうとする上記暗号化ブロックと当該暗号化ブロックの直前の暗号化ブロックを暗号化して得た暗号文との排他的論理演算を行い、当該演算の結果を暗号化するデータ処理装置。 - 請求項１において、
上記制御手段は、単数または複数の上記処理ブロックと、上記ブロック暗号化初期値とを含むクラスタ単位で、上記記憶手段に記憶された上記暗号化されたデータを管理するデータ処理装置。 - 請求項１において、
上記制御手段は、上記処理ブロック単位で読み出した上記データを上記処理手段に出力するデータ処理装置。 - 請求項１において、
上記データは、圧縮されており、上記処理手段は、上記記憶手段から読み出された上記データを、上記処理ブロックを単位として伸長するデータ処理装置。 - 記憶装置とデータ処理装置との間で相互認証を行いながらデータの入出力を行うデータ処理システムにおいて、
上記記憶装置は、
上記データ処理装置との間で相互認証処理を行う第１の相互認証処理手段と、
上記データを記憶する記憶手段と、
上記相互認証処理によって上記データ処理装置が正当な相手であると認めたときに、上記データ処理装置と上記記憶手段との間でデータの入出力を行わせる第１の制御手段とを有し、
上記データ処理装置は、
上記記憶装置との間で相互認証処理を行う第２の相互認証処理手段と、
所定のデータ長の暗号化ブロックを単位としてデータを暗号化する暗号化手段と、上記暗号化ブロックの整数倍のデータ長を持つ処理ブロックを単位としてデータに圧縮処理を行う処理手段と、
上記相互認証処理によって、上記記憶装置が正当な相手であると認めたときに、書き込み処理および読み出し処理の少なくとも一方を行い、上記書き込み処理において、一の上記暗号化ブロックを構成するデータが同じ上記処理ブロック内に位置するように、上記暗号化したデータを上記記憶手段に書き込み、上記読み出し処理において、上記処理ブロックを単位として上記データを上記記憶手段から読み出す第２の制御手段とを有し、
上記第２の制御手段は、単数または複数の上記処理ブロックを暗号化された順で上記記憶手段の連続したアドレスに記憶し、さらに、上記処理ブロック内の単数または複数の暗号化ブロックを暗号化された順で上記記憶手段の連続したアドレスに記憶し、上記クラスタ内で最初に暗号化された処理ブロック内でさらに最初に暗号化された暗号化ブロックが記憶された上記記憶手段のアドレスの直前のアドレスにブロック暗号化初期値を記憶するデータ処理システム。 - 請求項７において、
上記第２の制御手段は、上記処理ブロックにデータ長調整用のデータを入れて、上記処理ブロックのデータ長が上記暗号化ブロックのデータ長の整数倍になるように調整するデータ処理システム。 - 請求項７において、
上記暗号化手段は、上記暗号化を行おうとする上記暗号化ブロックと当該暗号化ブロックの直前の暗号化ブロックを暗号化して得た暗号文との排他的論理演算を行い、当該演算の結果を暗号化するデータ処理システム。 - 請求項７において、
上記第２の制御手段は、単数または複数の上記処理ブロックと、上記ブロック暗号化初期値とを含むクラスタ単位で、上記記憶手段に記憶された上記暗号化されたデータを管理するデータ処理システム。 - 所定のデータ長の暗号化ブロックを単位としてデータを暗号化し、
上記暗号化ブロックの整数倍のデータ長を持つ処理ブロックを単位としてデータに圧縮処理を行い、一の上記暗号化ブロックを構成するデータが同じ上記処理ブロック内に位置するように、上記暗号化したデータを上記記憶手段に書き込み、上記処理ブロックを単位として上記データを上記記憶手段から読み出し、
単数または複数の上記処理ブロックを暗号化された順で記憶手段の連続したアドレスに記憶し、さらに、上記処理ブロック内の単数または複数の暗号化ブロックを暗号化された順で上記記憶手段の連続したアドレスに記憶し、上記クラスタ内で最初に暗号化された処理ブロック内でさらに最初に暗号化された暗号化ブロックが記憶された上記記憶手段のアドレスの直前のアドレスにブロック暗号化初期値を記憶するデータ処理方法。 - 請求項１１において、
上記処理ブロックにデータ長調整用のデータを入れて、上記処理ブロックのデータ長が上記暗号化ブロックのデータ長の整数倍になるように調整するデータ処理方法。 - 請求項１１において、
上記暗号化を行おうとする上記暗号化ブロックと当該暗号化ブロックの直前の暗号化ブロックを暗号化して得た暗号文との排他的論理演算を行い、当該演算の結果を暗号化して上記暗号化を行うデータ処理方法。 - 請求項１１において、
単数または複数の上記処理ブロックと、上記ブロック暗号化初期値とを含むクラスタ単位で、記憶された上記暗号化されたデータを管理するデータ処理方法。 - 請求項１１において、
読み出された上記データを、上記処理ブロックを単位として伸長するデータ処理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000076391A JP4172131B2 (ja) | 1999-03-15 | 2000-03-14 | データ処理装置、データ処理システムおよびその方法 |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP11-69152 | 1999-03-15 | ||
| JP6915299 | 1999-03-15 | ||
| JP2000076391A JP4172131B2 (ja) | 1999-03-15 | 2000-03-14 | データ処理装置、データ処理システムおよびその方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000330872A JP2000330872A (ja) | 2000-11-30 |
| JP4172131B2 true JP4172131B2 (ja) | 2008-10-29 |
Family
ID=26410342
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000076391A Expired - Lifetime JP4172131B2 (ja) | 1999-03-15 | 2000-03-14 | データ処理装置、データ処理システムおよびその方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4172131B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9143326B2 (en) | 2012-03-29 | 2015-09-22 | International Business Machines Corporation | Method and system for encrypting data |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4534382B2 (ja) * | 2001-02-09 | 2010-09-01 | ソニー株式会社 | 符号列生成装置及び方法、信号再生装置及び方法、並びにコンテンツ供給システム |
| JP2003143015A (ja) * | 2001-11-07 | 2003-05-16 | Sony Corp | 信号処理方法及び装置並びに符号列生成方法及び装置 |
| JP4608931B2 (ja) | 2004-01-09 | 2011-01-12 | ソニー株式会社 | 情報処理装置および方法、プログラム、並びに記録媒体 |
| JP4853026B2 (ja) * | 2006-01-10 | 2012-01-11 | 富士ゼロックス株式会社 | 情報処理装置及びプログラム |
| JP5772031B2 (ja) * | 2011-02-08 | 2015-09-02 | 富士通株式会社 | 通信装置およびセキュアモジュール |
| JP6453202B2 (ja) * | 2015-10-30 | 2019-01-16 | 日本電産サンキョー株式会社 | 相互認証装置及び相互認証方法 |
-
2000
- 2000-03-14 JP JP2000076391A patent/JP4172131B2/ja not_active Expired - Lifetime
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9143326B2 (en) | 2012-03-29 | 2015-09-22 | International Business Machines Corporation | Method and system for encrypting data |
| US9344274B2 (en) | 2012-03-29 | 2016-05-17 | International Business Machines Corporation | Method and system for encrypting data |
| US9634827B2 (en) | 2012-03-29 | 2017-04-25 | International Business Machines Corporation | Encrypting data |
| US10396977B2 (en) | 2012-03-29 | 2019-08-27 | International Business Machines Corporation | Encrypting data |
| US11539505B2 (en) | 2012-03-29 | 2022-12-27 | Kyndryl, Inc. | Encrypting data |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000330872A (ja) | 2000-11-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR100718477B1 (ko) | 암호화된 데이터 전송을 위한 처리 방법 및 장치 | |
| KR100648388B1 (ko) | 장치간의 상호 식별용 데이터 처리 시스템 및 방법 | |
| JP4366845B2 (ja) | データ処理装置およびデータ処理方法、並びにプログラム提供媒体 | |
| JP4660899B2 (ja) | データ処理装置およびデータ処理方法、並びにプログラム提供媒体 | |
| JP4608749B2 (ja) | データ処理装置、データ処理方法、およびライセンスシステム、並びにプログラム提供媒体 | |
| JP4543554B2 (ja) | データ処理装置およびデータ処理方法 | |
| KR100934108B1 (ko) | 암호화된 데이터 전송을 위한 데이터 처리 방법, 장치 및시스템 | |
| JP4779183B2 (ja) | 再生装置および再生方法 | |
| US6601140B1 (en) | Memory unit, data processing unit, and data processing method using memory unit type | |
| US7155013B2 (en) | Recording apparatus, recording method, reproducing apparatus, and reproducing method | |
| JP2002108710A (ja) | 情報処理システム、情報処理方法、および情報処理装置、並びにプログラム提供媒体 | |
| KR100699189B1 (ko) | 비휘발성 기록 매체, 기록 방법, 및 기록 장치 | |
| JP4172131B2 (ja) | データ処理装置、データ処理システムおよびその方法 | |
| JP3925033B2 (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 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070215 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080129 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080331 |
|
| 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: 20080722 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080804 |
|
| R151 | Written notification of patent or utility model registration |
Ref document number: 4172131 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110822 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120822 Year of fee payment: 4 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130822 Year of fee payment: 5 |
|
| 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 |
|
| EXPY | Cancellation because of completion of term |