(57)【特許請求の範囲】
【請求項１】
単数または複数の関連するモジュールから構成されるトラックデータを、当該トラックデータに割り当てられた第１の鍵データおよび上記モジュール毎に割り当てられた第２の鍵データを用いて暗号化して記憶装置に出力するデータ処理装置において、
上記モジュール毎に、上記第１の鍵データおよび上記モジュールに割り当てられた上記第２の鍵データから第３の鍵データを算出する鍵データ算出手段と、
上記トラックデータを上記モジュール毎に当該モジュールの上記第３の鍵データに応じて暗号化して上記記憶装置に出力する暗号化手段とを有し、
上記鍵データ算出手段は、編集によって上記モジュールが、上記トラックデータに割り当てられた上記第１の鍵データとは異なる第１の鍵データが割り当てられた新たなトラックデータに属するようになったときに、上記第３の鍵データを変更しないように、上記モジュール毎に上記第２の鍵データを変更するデータ処理装置。
【請求項２】
記憶装置から入力した単数または複数の関連するモジュールから構成されるトラックデータを、当該トラックデータに割り当てられた第１の鍵データおよび上記モジュール毎に割り当てられた第２の鍵データを用いて復号するデータ処理装置において、
上記モジュール毎に、上記第１の鍵データおよび上記モジュールに割り当てられた上記第２の鍵データから第３の鍵データを算出する鍵データ算出手段と、
上記記憶装置から入力した上記トラックデータを上記モジュール毎に当該モジュールの上記第３の鍵データに応じて復号する復号手段とを有し、
上記鍵データ算出手段は、編集によって上記モジュールが、上記トラックデータに割り当てられた上記第１の鍵データとは異なる第１の鍵データが割り当てられた新たなトラックデータに属するようになったときに、上記第３の鍵データを変更しないように、上記モジュール毎に上記第２の鍵データを変更するデータ処理装置。
【請求項３】
記憶装置とデータ処理装置との間で、単数または複数の関連するモジュールから構成されるトラックデータを入出力するデータ処理システムにおいて、
上記記憶装置は、記憶手段を有し、
上記データ処理装置は、上記モジュール毎に、上記トラックデータに割り当てられた第１の鍵データおよび上記モジュール毎に割り当てられた第２の鍵データから第３の鍵データを算出する鍵データ算出手段と、
上記トラックデータを上記モジュール毎に当該モジュールの上記第３の鍵データに応じて暗号化して上記記憶装置に出力する暗号化手段とを有し、
上記鍵データ算出手段は、編集によって上記モジュールが、上記トラックデータに割り当てられた上記第１の鍵データとは異なる第１の鍵データが割り当てられた新たなトラックデータに属するようになったときに、上記第３の鍵データを変更しないように、上記モジュール毎に上記第２の鍵データを変更するデータ処理システム。
【請求項４】
記憶装置とデータ処理装置との間で、単数または複数の関連するモジュールから構成されるトラックデータを入出力するデータ処理システムにおいて、
上記記憶装置は、記憶手段を有し、
上記データ処理装置は、上記モジュール毎に、上記トラックデータに割り当てられた第１の鍵データおよび上記モジュール毎に割り当てられた上記第２の鍵データから第３の鍵データを算出する鍵データ算出手段と、
上記記憶装置から入力した上記トラックデータを上記モジュール毎に当該モジュールの上記第３の鍵データに応じて復号する復号手段とを有し、
上記鍵データ算出手段は、編集によって上記モジュールが、上記トラックデータに割り当てられた第１の鍵データとは異なる第１の鍵データが割り当てられた新たなトラックデータに属するようになったときに、上記第３の鍵データを変更しないように、上記モジュール毎に上記第２の鍵データを変更するデータ処理システム。
【請求項５】
単数または複数の関連するモジュールから構成されるトラックデータを、上記トラックデータに割り当てられた第１の鍵データおよび上記モジュール毎に割り当てられた第２の鍵データを用いて暗号化して記憶装置に記憶するデータ処理方法において、
上記モジュール毎に、上記第１の鍵データおよび上記モジュールに割り当てられた上記第２の鍵データから第３の鍵データを算出し、
上記トラックデータを上記モジュール毎に当該モジュールの上記第３の鍵データに応じて暗号化して上記記憶装置に出力し、
編集によって上記モジュールが、上記トラックデータに割り当てられた上記第１の鍵データとは異なる第１の鍵データが割り当てられた新たなトラックデータに属するようになったときに、上記第３の鍵データを変更しないように、上記モジュール毎に上記第２の鍵データを変更するデータ処理方法。
【請求項６】
記憶装置から入力した単数または複数の関連するモジュールから構成されるトラックデータを、上記トラックデータに割り当てられた第１の鍵データおよび上記モジュール毎に割り当てられた第２の鍵データを用いて復号するデータ処理方法において、
上記モジュール毎に、上記第１の鍵データおよび上記モジュールに割り当てられた上記第２の鍵データから第３の鍵データを算出し、
上記記憶装置から入力した上記トラックデータを上記モジュール毎に当該モジュールの上記第３の鍵データに応じて復号し、
編集によって上記モジュールが、上記トラックデータに割り当てられた上記第１の鍵データとは異なる第１の鍵データが割り当てられた新たなトラックデータに属するようになったときに、上記第３の鍵データを変更しないように、上記モジュール毎に上記第２の鍵データを変更するデータ処理方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、楽曲などの単数または複数の関連するモジュールから構成されるトラックデータを暗号化して記憶装置に記憶するデータ処理装置、記憶装置、データ処理システムおよびその方法に関する。
【０００２】
【従来の技術】
例えば、著作権侵害となる不正利用を防止するために、１曲分のオーディオデータなどの複数の関連するモジュールから構成されるトラックデータを暗号化して記憶媒体に記憶することがある。この場合に、解読を困難にするために、例えば、個々のトラックデータに割り当てられたコンテンツ鍵データと、当該トラック内に規定されたモジュール（パーツ）に割り当てられたパーツ鍵データとを用いて演算を行ってパーツ毎にブロック鍵データを生成し、パーツ毎に異なるブロック鍵データを用いてトラックデータを暗号化する。
【０００３】
【発明が解決しようとする課題】
ところで、上述したブロック鍵データを用いてトラックデータを暗号化した場合に、例えば、編集処理などが行われて、既に暗号化されたパーツが以前とは異なるコンテンツ鍵データが割り当てられた新たなトラックデータに属するようになった場合に、当該コンテンツ鍵データの変更に応じて、当該パーツに用いられるブロック鍵データが変わってしまう。その結果、当該パーツを復号した後に、再度、新たなブロック鍵データを用いて暗号化する必要が生じる。しかしながら、編集処理を行う度に、既に暗号化したトラックデータの復号および再暗号化を行うのでは、編集処理の負荷が重くなり、編集時間が長くなるという問題がある。
【０００４】
この発明の目的は、上述した従来技術の問題点に鑑みてなされ、編集処理などが行われ、既に暗号化されたトラックデータに異なる鍵データが割り当てられた場合の処理の時間を短縮できるデータ処理装置、記憶装置、データ処理システムおよびその方法を提供することにある。
【０００５】
【課題を解決するための手段】
上述した課題を解決するために、請求項１の発明は、単数または複数の関連するモジュールから構成されるトラックデータを、当該トラックデータに割り当てられた第１の鍵データおよび上記モジュール毎に割り当てられた第２の鍵データを用いて暗号化して記憶装置に出力するデータ処理装置において、
モジュール毎に、第１の鍵データおよびモジュールに割り当てられた第２の鍵データから第３の鍵データを算出する鍵データ算出手段と、
トラックデータをモジュール毎に当該モジュールの第３の鍵データに応じて暗号化して記憶装置に出力する暗号化手段とを有し、
鍵データ算出手段は、編集によってモジュールが、トラックデータに割り当てられた第１の鍵データとは異なる第１の鍵データが割り当てられた新たなトラックデータに属するようになったときに、第３の鍵データを変更しないように、モジュール毎に第２の鍵データを変更するデータ処理装置である。
【０００６】
請求項１のデータ処理装置では、第１の鍵データが変更された場合でも、鍵データ処理手段によって第３の鍵データを変更しないように第２の鍵データが変更されるため、記憶装置に記憶した暗号化されたトラックデータを復号して再度暗号化する必要がなくなる。
【０００７】
請求項２の発明は、記憶装置から入力した単数または複数の関連するモジュールから構成されるトラックデータを、当該トラックデータに割り当てられた第１の鍵データおよび上記モジュール毎に割り当てられた第２の鍵データを用いて復号するデータ処理装置において、
モジュール毎に、第１の鍵データおよびモジュールに割り当てられた第２の鍵データから第３の鍵データを算出する鍵データ算出手段と、
記憶装置から入力したトラックデータをモジュール毎に当該モジュールの第３の鍵データに応じて復号する復号手段とを有し、
鍵データ算出手段は、編集によってモジュールが、トラックデータに割り当てられた第１の鍵データとは異なる第１の鍵データが割り当てられた新たなトラックデータに属するようになったときに、第３の鍵データを変更しないように、モジュール毎に第２の鍵データを変更するデータ処理装置である。
【０００８】
請求項３の発明は、記憶装置とデータ処理装置との間で、単数または複数の関連するモジュールから構成されるトラックデータを入出力するデータ処理システムにおいて、
記憶装置は、記憶手段を有し、
データ処理装置は、モジュール毎に、トラックデータに割り当てられた第１の鍵データおよびモジュール毎に割り当てられた第２の鍵データから第３の鍵データを算出する鍵データ算出手段と、
トラックデータをモジュール毎に当該モジュールの第３の鍵データに応じて暗号化して記憶装置に出力する暗号化手段とを有し、
鍵データ算出手段は、編集によってモジュールが、トラックデータに割り当てられた第１の鍵データとは異なる第１の鍵データが割り当てられた新たなトラックデータに属するようになったときに、第３の鍵データを変更しないように、モジュール毎に第２の鍵データを変更するデータ処理システムである。
【０００９】
請求項４の発明は、記憶装置とデータ処理装置との間で、単数または複数の関連するモジュールから構成されるトラックデータを入出力するデータ処理システムにおいて、
記憶装置は、記憶手段を有し、
データ処理装置は、モジュール毎に、トラックデータに割り当てられた第１の鍵データおよびモジュール毎に割り当てられた第２の鍵データから第３の鍵データを算出する鍵データ算出手段と、
記憶装置から入力したトラックデータをモジュール毎に当該モジュールの第３の鍵データに応じて復号する復号手段とを有し、
鍵データ算出手段は、編集によってモジュールが、トラックデータに割り当てられた第１の鍵データとは異なる第１の鍵データが割り当てられた新たなトラックデータに属するようになったときに、第３の鍵データを変更しないように、モジュール毎に第２の鍵データを変更するデータ処理システムである。
【００１０】
請求項５の発明は、単数または複数の関連するモジュールから構成されるトラックデータを、トラックデータに割り当てられた第１の鍵データおよびモジュール毎に割り当てられた第２の鍵データを用いて暗号化して記憶装置に記憶するデータ処理方法において、
モジュール毎に、第１の鍵データおよびモジュールに割り当てられた第２の鍵データから第３の鍵データを算出し、
トラックデータをモジュール毎に当該モジュールの第３の鍵データに応じて暗号化して記憶装置に出力し、
編集によってモジュールが、トラックデータに割り当てられた第１の鍵データとは異なる第１の鍵データが割り当てられた新たなトラックデータに属するようになったときに、第３の鍵データを変更しないように、モジュール毎に第２の鍵データを変更するデータ処理方法である。
【００１１】
請求項６の発明は、記憶装置から入力した単数または複数の関連するモジュールから構成されるトラックデータを、トラックデータに割り当てられた第１の鍵データおよびモジュール毎に割り当てられた第２の鍵データを用いて復号するデータ処理方法において、
モジュール毎に、第１の鍵データおよびモジュールに割り当てられた第２の鍵データから第３の鍵データを算出し、
記憶装置から入力したトラックデータをモジュール毎に当該モジュールの上記第３の鍵データに応じて復号し、
編集によってモジュールが、トラックデータに割り当てられた第１の鍵データとは異なる第１の鍵データが割り当てられた新たなトラックデータに属するようになったときに、第３の鍵データを変更しないように、モジュール毎に第２の鍵データを変更するデータ処理方法である。
【００１６】
【発明の実施の形態】
以下、この発明の実施形態に係わるオーディオシステムについて説明する。図１は、一実施形態のオーディオシステム１のシステム構成図、図２は図１に示す携帯用記憶装置３および携帯用プレーヤ４の内部構成図である。図１に示すように、オーディオシステム１は、例えば、コンピュータ２、携帯用記憶装置３、携帯用プレーヤ４、ＣＤ−ＲＯＭドライブ６およびＣＤプレーヤ７を有する。
【００１７】
コンピュータ２
コンピュータ２は、ネットワーク５に接続されており、例えば、ＥＭＤ(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 の選択処理を説明するための略線図である。
【図２２】携帯用記憶装置と携帯用プレーヤとの間の相互認証処理を説明するためのフローチャートである。
【図２３】セッション鍵データＳｅｋの生成処理を説明するための略線図である。
【図２４】携帯用プレーヤから携帯用記憶装置へのオーディオデータの書き込み処理を説明するためのフローチャートである。
【図２５】携帯用記憶装置から携帯用プレーヤへの読み出し動作を説明するためのフローチャートである。
【図２６】携帯用記憶装置から携帯用プレーヤへのオーディオデータの読み出し処理を説明するためのフローチャートである。
【図２７】携帯用プレーヤの編集モジュールによるトラックデータファイルの分割編集処理を説明するための略線図である。
【図２８】分割編集処理を行った後のクラスタ内のデータを説明するための略線図である。
【図２９】携帯用プレーヤの編集モジュールにおいて、分割編集時に、新たなトラックデータファイルのコンテンツ鍵データおよびパーツ鍵データを生成する方法を説明するためのフローチャートである。
【図３０】携帯用プレーヤの編集モジュールによるトラックデータファイルの結合編集処理を説明するための略線図である。
【図３１】携帯用プレーヤ４の編集モジュールにおいて、新たに生成したトラックデータファイル（３）のパーツ（１）および（２）のパーツ鍵データを生成する処理を説明するための略線図である。
【符号の説明】
１・・・オーディオシステム、２・・・コンピュータ、３・・・携帯用記憶装置、４・・・携帯用プレーヤ、５・・・ネットワーク、３３，４３・・・制御モジュール、５０，６０・・・乱数発生ユニット、５１，６１・・・記憶ユニット、５２，６２・・・鍵生成／演算ユニット、５３，６３・・・相互認証ユニット、５４，７４・・・暗号化／復号ユニット、５５，６５・・・制御ユニット、３４・・・フラッシュメモリ、４４・・・編集モジュール、４５・・・圧縮／伸長モジュール、４６・・・スピーカ
【図１】
0003925033.tif 000002
【図２】
0003925033.tif 000003
【図３】
0003925033.tif 000004
【図４】
0003925033.tif 000005
【図５】
0003925033.tif 000006
【図６】
0003925033.tif 000007
【図７】
0003925033.tif 000008
【図８】
0003925033.tif 000009
【図９】
0003925033.tif 000010
【図１０】
0003925033.tif 000011
【図１１】
0003925033.tif 000012
【図１２】
0003925033.tif 000013
【図１３】
0003925033.tif 000014
【図１４】
0003925033.tif 000015
【図１５】
0003925033.tif 000016
【図１６】
0003925033.tif 000017
【図１７】
0003925033.tif 000018
【図１８】
0003925033.tif 000019
【図１９】
0003925033.tif 000020
【図２０】
0003925033.tif 000021
【図２１】
0003925033.tif 000022
【図２２】
0003925033.tif 000023
【図２３】
0003925033.tif 000024
【図２４】
0003925033.tif 000025
【図２５】
0003925033.tif 000026
【図２６】
0003925033.tif 000027
【図２７】
0003925033.tif 000028
【図２８】
0003925033.tif 000029
【図２９】
0003925033.tif 000030
【図３０】
0003925033.tif 000031
【図３１】
0003925033.tif 000032