JP2000330872A

JP2000330872A - データ処理装置、データ処理システムおよびその方法

Info

Publication number: JP2000330872A
Application number: JP2000076391A
Authority: JP
Inventors: Takeo Oishi; 丈於大石; Takumi Okanoe; 拓己岡上
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 1999-03-15
Filing date: 2000-03-14
Publication date: 2000-11-30
Anticipated expiration: 2020-03-14
Also published as: JP4172131B2

Abstract

(57)【要約】【課題】所定の処理ブロックを単位として圧縮などの
処理されたデータを所定の暗号化ブロックを単位として
暗号化して記憶媒体に記憶する際に、所定の処理ブロッ
クに基づいた処理と復号処理とを簡単な構成で正確に行
う。【解決手段】所定のデータ長の暗号化ブロックを単位
としてデータを暗号化／復号ユニット６４と、暗号化ブ
ロックの整数倍のデータ長を持つ処理ブロックを単位と
してデータに所定の処理を行う圧縮／伸長モジュール４
５と、暗号化したデータを記憶するフラッシュメモリ３
４とを有し、携帯用プレーヤ４は、同じ暗号化ブロック
内に位置するデータが同じ処理ブロック内に位置するよ
うに暗号化したデータをフラッシュメモリ３４に書き込
み、処理ブロックを単位としてデータをフラッシュメモ
リ３４から読み出す。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、例えば圧縮など
の所定の処理ブロックを単位で処理されたデータを所定
の暗号化ブロックを単位として暗号化して記憶手段に記
憶するデータ処理装置、データ処理手段およびその方法
に関する。

【０００２】

【従来の技術】例えば、著作権侵害となる不正利用を防
止するために、オーディオデータなどのデータを所定の
データ長の暗号化ブロックを単位として暗号化して記憶
媒体に記憶することがある。この場合に、暗号化しよう
とするデータは、通常、所定の圧縮処理ブロックを単位
として圧縮されていることが多い。

【０００３】

【発明が解決しようとする課題】ところで、上述したよ
うに圧縮されたデータを暗号化して記憶媒体に記録する
場合に、圧縮ブロックと暗号化ブロックと通常一致しな
い。そのため、例えば、圧縮ブロックを単位として記憶
媒体からデータを読み出すと暗号化ブロックのうちの一
部のブロックのデータが読み出されないことがあり、正
確な復号を行えなくなる。このような事態を回避するた
めに、圧縮ブロックおよびおよび暗号化ブロックの双方
を考慮して読み出しを行うと、処理が煩雑となる問題が
ある。

【０００４】また、記憶媒体に記録したデータを編集す
る場合などは、例えば圧縮ブロックを単位としてデータ
の分割および結合などが行われるが、この場合にも、編
集後のデータに暗号化ブロックの一部のデータが含まれ
なくなる可能性が高く、同様に、正確な復号が行えなく
なるという問題がある。また、圧縮されていないデータ
であっても、例えば音楽用のＣＤ(Compact Disc:登録商
標 )フォーマットなどのように、所定のブロックを単位
として処理が行われる場合にも上述した場合と同様の問
題が生じる。

【０００５】この発明の目的は、上述した従来技術の問
題点に鑑みてなされ、例えば圧縮などの所定の処理ブロ
ック単位で処理されたデータを所定の暗号化ブロックを
単位として暗号化して記憶媒体に記憶する際に、所定の
処理ブロックに基づいた処理と復号処理とを簡単な構成
で正確に行うことができるデータ処理装置、データ処理
システムおよびその方法を提供することにある。

【０００６】

【課題を解決するための手段】上述した課題を解決する
ために、請求項１の発明は、所定のデータ長の暗号化ブ
ロックを単位としてデータを暗号化する暗号化手段と、
暗号化ブロックの整数倍のデータ長を持つ処理ブロック
を単位としてデータに所定の処理を行う処理手段と、暗
号化したデータを記憶する記憶手段と、同じ暗号化ブロ
ック内に位置するデータが同じ処理ブロック内に位置す
るように、暗号化したデータを記憶手段に書き込み、処
理ブロックを単位としてデータを記憶手段から読み出す
制御手段とを有するデータ処理装置である。

【０００７】請求項１３の発明は、所定のデータ長の暗
号化ブロックを単位としてデータを暗号化し、暗号化ブ
ロックの整数倍のデータ長を持つ処理ブロックを単位と
してデータに所定の処理を行い、同じ暗号化ブロック内
に位置するデータが同じ処理ブロック内に位置するよう
に、暗号化したデータを記憶手段に書き込み、処理ブロ
ックを単位としてデータを記憶手段から読み出すデータ
処理方法である。

【０００８】請求項８の発明は、記憶装置とデータ処理
装置との間で相互認証を行いながらデータの入出力を行
うデータ処理システムにおいて、記憶装置は、データ処
理装置との間で相互認証処理を行う第１の相互認証処理
手段と、データを記憶する記憶手段と、相互認証処理に
よってデータ処理装置が正当な相手であると認めたとき
に、データ処理装置と記憶手段との間でデータの入出力
を行わせる第１の制御手段とを有し、データ処理装置
は、記憶装置との間で相互認証処理を行う第２の相互認
証処理手段と、所定のデータ長の暗号化ブロックを単位
としてデータを暗号化する暗号化手段と、暗号化ブロッ
クの整数倍のデータ長を持つ処理ブロックを単位として
データに所定の処理を行う処理手段と、相互認証処理に
よって、記憶装置が正当な相手であると認めたときに、
書き込み処理および読み出し処理の少なくとも一方を行
い、書き込み処理において、同じ暗号化ブロック内に位
置するデータが同じ処理ブロック内に位置するように、
暗号化したデータを記憶手段に書き込み、読み出し処理
において、処理ブロックを単位としてデータを記憶手段
から読み出す制御手段とを有するデータ処理システムで
ある。

【０００９】

【発明の実施の形態】以下、この発明の実施形態に係わ
るオーディオシステムについて説明する。図１は、一実
施形態のオーディオシステム１のシステム構成図、図２
は図１に示す携帯用記憶装置３および携帯用プレーヤ４
の内部構成図である。図１に示すように、オーディオシ
ステム１は、例えば、コンピュータ２、携帯用記憶装置
３、携帯用プレーヤ４、ＣＤ−ＲＯＭドライブ６および
ＣＤプレーヤ７を有する。

【００１０】コンピュータ２コンピュータ２は、ネットワーク５に接続されており、
例えば、ＥＭＤ(Electronic Music Distribution: 電子
音楽配信）などのサービスを提供する図示しないサービ
スプロバイダのホストコンピュータから、ネットワーク
５を介してオーディオデータ（トラックデータ）を受信
し、当該受信したオーディオデータを必要に応じて復号
して、携帯用プレーヤ４に出力する。また、コンピュー
タ２は、コンテンツデータを受信するに当たって、必要
に応じて、サービスプロバイダのホストコンピュータと
の間で認証処理および課金処理などを行う。また、コン
ピュータ２は、例えば、ＣＤ−ＲＯＭドライブ６から入
力したオーディオデータを携帯用プレーヤ４に出力す
る。

【００１１】携帯用記憶装置３携帯用記憶装置３は、携帯用プレーヤ４に対して着脱自
在とされ、例えば、メモリスティック(Memory Stick:商
標）であり、フラッシュメモリなどの書き換え可能な半
導体メモリを内蔵している。本明細書において、メモリ
カードの用語が使用されることもあるが、メモリカード
は、携帯用記憶装置を指すものとして使用している。図
２に示すように、携帯用記憶装置３は、例えば、主制御
モジュール３１、通信インターフェイス３２、制御モジ
ュール３３、フラッシュメモリ３４およびフラッシュメ
モリ管理モジュール３５を有する。

【００１２】〔制御モジュール３３〕図２に示すよう
に、制御モジュール３３は、例えば、乱数発生ユニット
５０、記憶ユニット５１、鍵生成／演算ユニット５２、
相互認証ユニット５３、暗号化／復号ユニット５４およ
び制御ユニット５５を有する。制御モジュール３３は、
シングルチップの暗号処理専用の集積回路であり、多層
構造を有し、内部のメモリセルはアルミニウム層などの
ダミー層に挟まれている。また、制御モジュール３３
は、動作電圧または動作周波数の幅が狭く、外部から不
正にデータを読み出せないように耐タンパー性を有して
いる。乱数発生ユニット５０は、乱数発生指示を受ける
と、６４ビット（８バイト）の乱数を発生する。

【００１３】記憶ユニット５１は、例えば、ＥＥＰＲＯ
Ｍ(Electrically Erasable Programmable Read Only Me
mory) などの不揮発性メモリであり、認証処理に必要な
鍵データなどの種々のデータを記憶している。図３は、
記憶ユニット５１に記憶されているデータを説明するた
めの図である。図３に示すように、記憶ユニット５１
は、認証鍵データＩＫ₀〜ＩＫ₃₁、装置識別データＩＤ
_mおよび記憶用鍵データＳＫ_mを記憶している。

【００１４】認証鍵データＩＫ₀〜ＩＫ₃₁は、携帯用記
憶装置３が携帯用プレーヤ４との間で相互認証を行う際
に用いられる鍵データであり、後述するように相互認証
を行う度に認証鍵データＩＫ₀〜ＩＫ₃₁のうち一の認証
鍵データがランダムに選択される。なお、認証鍵データ
ＩＫ₀〜ＩＫ₃₁および記憶用鍵データＳＫ_mは、携帯用
記憶装置３の外部から読めないようになっている。装置
識別データＩＤ_mは、携帯用記憶装置３に対してユニー
クに付けられた識別データであり、後述するように、携
帯用記憶装置３が携帯用プレーヤ４との間で相互認証を
行う際に読み出されて携帯用プレーヤ４に出力される。
記憶用鍵データＳＫ_mは、後述するように、コンテンツ
鍵データＣＫを暗号化してフラッシュメモリ３４に記憶
する際に用いられる。

【００１５】鍵生成／演算ユニット５２は、例えば、Ｉ
ＳＯ／ＩＥＣ９７９７のＭＡＣ(Message Authenticatio
n Code) 演算などの種々の演算を行って鍵データを生成
する。このとき、ＭＡＣ演算には、例えば、"Block cip
her Algorithm"としてＦＩＰＳＰＵＢ４６−２に規定さ
れるＤＥＳ(Data Encryption Standard)が用いられる。
ＭＡＣ演算は、任意の長さのデータを固定の長さに圧縮
する一方向性ハッシュ関数演算であり、関数値が秘密鍵
に依存して定まる。

【００１６】相互認証ユニット５３は、携帯用プレーヤ
４からオーディオデータを入力してフラッシュメモリ３
４に書き込む動作を行うのに先立って、携帯用プレーヤ
４との間で相互認証処理を行う。また、相互認証ユニッ
ト５３は、フラッシュメモリ３４からオーディオデータ
を読み出して携帯用プレーヤ４に出力する動作を行うの
に先立って、携帯用プレーヤ４との間で相互認証処理を
行う。また、相互認証ユニット５３は、相互認証処理に
おいて、前述したＭＡＣ演算を行う。当該相互認証処理
では、記憶ユニット５１に記憶されているデータが用い
られる。

【００１７】暗号化／復号ユニット５４は、ＤＥＳ、Ｉ
ＤＥＡ、ＭＩＳＴＹなどのブロック暗号アルゴリズムで
の暗号化を行う。使用するモードは、ＦＩＰＳＰＵＢ
８１”ＤＥＳＭＯＤＥＳＯＦＯＰＥＲＡＴＩＯ
Ｎ”に規定されているようなＥＣＢ(Electronic Code B
ook)モードおよびＣＢＣ(Cipher Block Chaining) モー
ドである。また、暗号化／復号ユニット５４は、ＤＥ
Ｓ、ＩＤＥＡ、ＭＩＳＴＹなどのブロック復号アルゴリ
ズムでの復号を行う。使用するモードは、上記ＥＣＢモ
ードおよびＣＢＣモードである。当該ＥＣＢモードおよ
びＣＢＣモードのブロック暗号化／復号では、指定され
た鍵データを用いて指定されたデータを暗号化／復号す
る。制御ユニット５５は、乱数発生ユニット５０、記憶
ユニット５１、鍵生成／演算ユニット５２、相互認証ユ
ニット５３および暗号化／復号ユニット５４の処理を統
括して制御する。

【００１８】〔フラッシュメモリ３４〕フラッシュメモ
リ３４は、例えば、３２Ｍバイトの記憶容量を有する。
フラッシュメモリ３４には、相互認証ユニット５３によ
る相互認証処理によって正当な相手であると認められた
ときに、携帯用プレーヤ４から入力したオーディオデー
タが書き込まれる。また、フラッシュメモリ３４から
は、相互認証ユニット５３による相互認証処理によって
正当な相手であると認められたときに、オーディオデー
タが読み出されて携帯用プレーヤ４に出力される。

【００１９】以下、フラッシュメモリ３４に記憶される
データおよびそのフォーマットについて説明する。図４
は、フラッシュメモリ３４に記憶されるデータを説明す
るための図である。図４に示すように、フラッシュメモ
リ３４には、例えば、再生管理ファイル１００、トラッ
クデータファイル１０１₀，１０１₁，１０１₂，１０
１₃が記憶されている。ここで、再生管理ファイル１０
０はトラックデータファイル１０１₀〜１０１₃の再生
を管理する管理データを有し、トラックデータファイル
１０１₀〜１０１₃はそれぞれ対応するトラックデータ
（オーディオデータ）を有している。なお、本実施形態
では、トラックデータは、例えば、１曲分のオーディオ
データを意味する。

【００２０】図５は、再生管理ファイルの構成を示し、
図６が一つ（１曲）のＡＴＲＡＣ３データファイルの構
成を示す。再生管理ファイルは、１６ＫＢ固定長のファ
イルである。ＡＴＲＡＣ３データファイルは、曲単位で
もって、先頭の属性ヘッダと、それに続く実際の暗号化
された音楽データとからなる。属性ヘッダも１６ＫＢ固
定長とされ、再生管理ファイルと類似した構成を有す
る。

【００２１】再生管理ファイルは、ヘッダ、１バイトコ
ードのメモリカードの名前ＮＭ１−Ｓ、２バイトコード
のメモリカードの名前ＮＭ２−Ｓ、曲順の再生テーブル
ＴＲＫＴＢＬ、メモリカード全体の付加情報ＩＮＦ−Ｓ
とからなる。データファイルの先頭の属性ヘッダは、ヘ
ッダ、１バイトコードの曲名ＮＭ１、２バイトコードの
曲名ＮＭ２、トラックのキー情報等のトラック情報ＴＲ
ＫＩＮＦ、パーツ情報ＰＲＴＩＮＦと、トラックの付加
情報ＩＮＦとからなる。ヘッダには、総パーツ数、名前
の属性、付加情報のサイズの情報等が含まれる。

【００２２】属性ヘッダに対してＡＴＲＡＣ３の音楽デ
ータが続く。音楽データは、１６ＫＢのブロック毎に区
切られ、各ブロックの先頭にヘッダが付加されている。
ヘッダには、暗号を復号するための初期値が含まれる。
なお、暗号化の処理を受けるのは、ＡＴＲＡＣ３データ
ファイル中の音楽データのみであって、それ以外の再生
管理ファイル、ヘッダ等のデータは、暗号化されない。

【００２３】図７は、再生管理ファイルＰＢＬＩＳＴの
より詳細なデータ構成を示し、図８Ａ、図８Ｂは、再生
管理ファイルＰＢＬＩＳＴを構成するヘッダとそれ以外
の部分をそれぞれ示す。再生管理ファイルＰＢＬＩＳＴ
は、１クラスタ（１ブロック＝１６ＫＢ）のサイズであ
る。ヘッダ（図８Ａ）が３２バイトである。ヘッダ以外
の部分（図８Ｂ）がメモリカード全体に対する名前ＮＭ
１−Ｓ（２５６バイト）、名前ＮＭ２−Ｓ（５１２バイ
ト）、ＣＯＮＴＥＮＴＳＫＥＹ、ＭＡＣ、Ｓ−ＹＭＤ
ｈｍｓと、再生順番を管理するテーブルＴＲＫＴＢＬ
（８００バイト）と、メモリカード全体に対する付加情
報ＩＮＦ−Ｓ（１４７２０バイト）であり、最後にヘッ
ダ中の情報の一部が再度記録される。これらの異なる種
類のデータ群のそれぞれの先頭は、再生管理ファイル内
で所定の位置となるように規定されている。

【００２４】再生管理ファイルは、（０ｘ００００）お
よび（０ｘ００１０）で表される先頭から３２バイト
（図８Ａ）がヘッダである。なお、ファイル中で先頭か
ら１６バイト単位で区切られた単位をスロットと称す
る。ファイルの第１および第２のスロットに配されるヘ
ッダには、下記の意味、機能、値を持つデータが先頭か
ら順に配される。なお、Ｒｅｓｅｒｖｅｄと表記されて
いるデータは、未定義のデータを表している。通常ヌル
（０ｘ００）が書かれるが、何が書かれていてもＲｅｓ
ｅｒｖｅｄのデータが無視される。将来のバージョンで
は、変更がありうる。また、この部分への書き込みは禁
止する。Ｏｐｔｉｏｎと書かれた部分も使用しない場合
は、全てＲｅｓｅｒｖｅｄと同じ扱いとされる。

【００２５】ＢＬＫＩＤ−ＴＬ０（４バイト）意味：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-J
IS(for Voice) 。

【００２７】言語コード（Ｌ）は下位１バイトで下記の
ようにEBU Tech 3258 規定に準じて言語を区別する 00: 設定しない 08:German 09:English 0A:Spanish 0F:French 15:Italian 1D:Dutch 65:Korean 69:Japanese 75:Chinese データが無い場合オールゼロとすること。

【００２８】ＳＮ２Ｃ＋Ｌ（２バイト）意味：ＮＭ２−Ｓ領域に書かれるメモリカードの名前
（２バイト）の属性を表す機能：使用する文字コードと言語コードを各１バイトで
表す値：上述したＳＮ１Ｃ＋Ｌと同一ＳＩＮＦＳＩＺＥ（２バイト）意味：ＩＮＦ−Ｓ領域に書かれるメモリカード全体に関
する付加情報の全てを合計したサイズを表す機能：データサイズを１６バイト単位の大きさで記述、
無い場合は必ずオールゼロとすること値：サイズは０ｘ０００１から０ｘ３９Ｃ（９２４）Ｔ−ＴＲＫ（２バイト）意味：TOTAL TRACK NUMBER 機能：総トラック数値：１から０ｘ０１９０（最大４００トラック）、デー
タが無い場合はオールゼロとすることＶｅｒＮｏ（２バイト）意味：フォーマットのバージョン番号機能：上位がメジャーバージョン番号、下位がマイナー
バージョン番号値：例０ｘ０１００（Ｖｅｒ１．０）０ｘ０２０３（Ｖｅｒ２．３）。

【００２９】上述したヘッダに続く領域に書かれるデー
タ（図８Ｂ）について以下に説明する。

【００３０】ＮＭ１−Ｓ意味：メモリカード全体に関する１バイトの名前機能：１バイトの文字コードで表した可変長の名前デー
タ（最大で２５６）名前データの終了は、必ず終端コード（０ｘ００）を書
き込むことサイズはこの終端コードから計算すること、データの無
い場合は少なくとも先頭（０ｘ００２０）からヌル（０
ｘ００）を１バイト以上記録すること値：各種文字コードＮＭ２−Ｓ意味：メモリカード全体に関する２バイトの名前機能：２バイトの文字コードで表した可変長の名前デー
タ（最大で５１２）名前データの終了は、必ず終端コード（０ｘ００）を書
き込むことサイズはこの終端コードから計算すること、データの無
い場合は少なくとも先頭（０ｘ０１２０）からヌル（０
ｘ００）を２バイト以上記録すること値：各種文字コード。

【００３１】ＣＯＮＴＥＮＴＳＫＥＹ意味：曲ごとに用意された値でＭＧ（Ｍ）で保護されて
から保存される。ここでは、１曲目に付けられるＣＯＮ
ＴＥＮＴＳＫＥＹと同じ値機能：Ｓ−ＹＭＤｈｍｓのＭＡＣの計算に必要となる鍵
となる値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦまでＭＡＣ意味：著作権情報改ざんチェック値機能：Ｓ−ＹＭＤｈｍｓの内容とＣＯＮＴＥＮＴＳＫ
ＥＹから作成される値値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦま
で。

【００３２】ＴＲＫ−ｎｎｎ意味：再生するＡＴＲＡＣ３データファイルのＳＱＮ
（シーケンス）番号機能：ＴＲＫＩＮＦの中のＦＮｏを記述する値：１から４００（０ｘ１９０）トラックが存在しない時はオールゼロとすることＩＮＦ−Ｓ意味：メモリカード全体に関する付加情報データ（例え
ば写真、歌詞、解説等の情報）機能：ヘッダを伴った可変長の付加情報データ複数の異なる付加情報が並べられることがある。それぞ
れにＩＤとデータサイズが付けられている。個々のヘッ
ダを含む付加情報データは最小１６バイト以上で４バイ
トの整数倍の単位で構成される。その詳細については、
後述する値：付加情報データ構成を参照Ｓ−ＹＭＤｈｍｓ（４バイト）（Ｏｐｔｉｏｎ）意味：信頼できる時計を持つ機器で記録した年・月・日
・時・分・秒機能：最終記録日時を識別するための値、ＥＭＤの時は
必須値：２５〜３１ビット年０〜９９（１９８０〜２０
７９）２１〜２４ビット月０〜１２１６〜２０ビット日０〜３１１１〜１５ビット時０〜２３０５〜１０ビット分０〜５９００〜０４ビット秒０〜２９（２秒単位）。

【００３３】再生管理ファイルの最後のスロットとし
て、ヘッダ内のものと同一のＢＬＫＩＤ−ＴＬ０と、Ｍ
Ｃｏｄｅと、ＲＥＶＩＳＩＯＮとが書かれる。

【００３４】民生用オーディオ機器として、メモリカー
ドが記録中に抜かれたり、電源が切れることがあり、復
活した時にこれらの異常の発生を検出することが必要と
される。上述したように、ＲＥＶＩＳＩＯＮをブロック
の先頭と末尾に書き込み、この値を書き換える度に＋１
インクリメントするようにしている。若し、ブロックの
途中で異常終了が発生すると、先頭と末尾のＲＥＶＩＳ
ＩＯＮの値が一致せず、異常終了を検出することができ
る。ＲＥＶＩＳＩＯＮが２個存在するので、高い確率で
異常終了を検出することができる。異常終了の検出時に
は、エラーメッセージの表示等の警告が発生する。

【００３５】また、１ブロック（１６ＫＢ）の先頭部分
に固定値ＢＬＫＩＤ−ＴＬ０を挿入しているので、ＦＡ
Ｔが壊れた場合の修復の目安に固定値を使用できる。す
なわち、各ブロックの先頭の固定値を見れば、ファイル
の種類を判別することが可能である。しかも、この固定
値ＢＬＫＩＤ−ＴＬ０は、ブロックのヘッダおよびブロ
ックの終端部分に二重に記述するので、その信頼性のチ
ェックを行うことができる。なお、再生管理ファイルＰ
ＢＬＩＳＴの同一のものを二重に記録しても良い。

【００３６】ＡＴＲＡＣ３データファイルは、トラック
情報管理ファイルと比較して、相当大きなデータ量（例
えば数千のブロックが繋がる場合もある）であり、ＡＴ
ＲＡＣ３データファイルに関しては、後述するように、
ブロック番号ＢＬＯＣＫＳＥＲＩＡＬが付けられてい
る。但し、ＡＴＲＡＣ３データファイルは、通常複数の
ファイルがメモリカード上に存在するので、ＣＯＮＮＵ
Ｍ０でコンテンツの区別を付けた上で、ＢＬＯＣＫＳ
ＥＲＩＡＬを付けないと、重複が発生し、ＦＡＴが壊れ
た場合のファイルの復旧が困難となる。

【００３７】同様に、ＦＡＴの破壊までにはいたらない
が、論理を間違ってファイルとして不都合のあるような
場合に、書き込んだメーカーの機種が特定できるよう
に、メーカーコード（ＭＣｏｄｅ）がブロックの先頭と
末尾に記録されている。

【００３８】図８Ｃは、付加情報データの構成を示す。
付加情報の先頭に下記のヘッダが書かれる。ヘッダ以降
に可変長のデータが書かれる。

【００３９】ＩＮＦ意味：FIELD ID 機能：付加情報データの先頭を示す固定値値：０ｘ６９ＩＤ意味：付加情報キーコード機能：付加情報の分類を示す値：０から０ｘＦＦＳＩＺＥ意味：個別の付加情報の大きさ機能：データサイズは自由であるが、必ず４バイトの整
数倍でなければならない。また、最小１６バイト以上の
こと。データの終わりより余りがでる場合はヌル（０ｘ
００）で埋めておくこと値：１６から１４７８４（０ｘ３９Ｃ０）ＭＣｏｄｅ意味：MAKER CODE 機能：記録した機器の、メーカー、モデルを識別するコ
ード値：上位１０ビット（メーカーコード）下位６ビット
（機種コード）Ｃ＋Ｌ意味：先頭から１２バイト目からのデータ領域に書かれ
る文字の属性を表す機能：使用する文字コードと言語コードを各１バイトで
表す値：前述のＳＮ１Ｃ＋Ｌと同じＤＡＴＡ意味：個別の付加情報データ機能：可変長データで表す。実データの先頭は常に１２
バイト目より始まり、長さ（サイズ）は最小４バイト以
上、常に４バイトの整数倍でなければならない。データ
の最後から余りがある場合はヌル（０ｘ００）で埋める
こと値：内容により個別に定義される。

【００４０】以下、トラックデータファイル１０１₀〜
１０１₃について説明する。図９は、トラックデータフ
ァイル１０１₀の構成を説明するための図である。図９
に示すように、トラックデータファイル１０１₀は、１
個のパーツからなり、当該パーツが５個のクラスタＣＬ
（０），ＣＬ（１），ＣＬ（２），ＣＬ（３），ＣＬ
（４）で構成されている。当該パーツは、クラスタＣＬ
（０）の先頭から開始し、クラスタＣＬ（４）のサウン
ドユニットＳＵ（４）で終了している。なお、トラック
データファイル１０１₁〜１０１₃は、基本的に、図９
に示す構成をしているが、パーツ数、クラスタ数および
クラスタ内に含まれるサウンドユニットＳＵの数は、図
９に示すものには限定されず、独立して決められてい
る。

【００４１】１トラックは、１曲を意味する。１曲は、
１つのＡＴＲＡＣ３データファイル（図６参照）で構成
される。ＡＴＲＡＣ３データファイルは、ＡＴＲＡＣ３
により圧縮されたオーディオデータである。メモリカー
ド４０に対しては、クラスタと呼ばれる単位で記録され
る。１クラスタは、例えば１６ＫＢの容量である。１ク
ラスタに複数のファイルが混じることがない。フラッシ
ュメモリ４２を消去する時の最小単位が１ブロックであ
る。音楽データを記録するのに使用するメモリカード４
０の場合、ブロックとクラスタは、同意語であり、且つ
１クラスタ＝１セクタと定義されている。

【００４２】１曲は、基本的に１パーツで構成される
が、編集が行われると、複数のパーツから１曲が構成さ
れることがある。パーツは、録音開始からその停止まで
の連続した時間内で記録されたデータの単位を意味し、
通常は、１トラックが１パーツで構成される。曲内のパ
ーツのつながりは、各曲の属性ヘッダ内のパーツ情報Ｐ
ＲＴＩＮＦで管理する。すなわち、パーツサイズは、Ｐ
ＲＴＩＮＦの中のパーツサイズＰＲＴＳＩＺＥという４
バイトのデータで表す。パーツサイズＰＲＴＳＩＺＥの
先頭の２バイトがパーツが持つクラスタの総数を示し、
続く各１バイトが先頭および末尾のクラスタ内の開始サ
ウンドユニット（ＳＵと略記する）の位置、終了ＳＵの
位置を示す。このようなパーツの記述方法を持つことに
よって、音楽データを編集する際に通常、必要とされる
大量の音楽データの移動をなくすことが可能となる。ブ
ロック単位の編集に限定すれば、同様に音楽データの移
動を回避できるが、ブロック単位は、ＳＵ単位に比して
編集単位が大きすぎる。

【００４３】ＳＵは、パーツの最小単位であり、且つＡ
ＴＲＡＣ３でオーディオデータを圧縮する時の最小のデ
ータ単位である。４４．１ｋHzのサンプリング周波数で
得られた１０２４サンプル分（１０２４×１６ビット×
２チャンネル）のオーディオデータを約１／１０に圧縮
した数百バイトのデータがＳＵである。１ＳＵは、時間
に換算して約２３ｍ秒になる。通常は、数千に及ぶＳＵ
によって１つのパーツが構成される。１クラスタが４２
個のＳＵで構成される場合、１クラスタで約１秒の音を
表すことができる。１つのトラックを構成するパーツの
数は、付加情報サイズに影響される。パーツ数は、１ブ
ロックの中からヘッダや曲名、付加情報データ等を除い
た数で決まるために、付加情報が全く無い状態が最大数
（６４５個）のパーツを使用できる条件となる。

【００４４】図１０は、１ＳＵがＮバイト（例えばＮ＝
３８４バイト）の場合のＡＴＲＡＣ３データファイルＡ
３Ｄｎｎｎｎのデータ配列を示す。図１０には、データ
ファイルの属性ヘッダ（１ブロック）と、音楽データフ
ァイル（１ブロック）とが示されている。図１０では、
この２ブロック（１６×２＝３２Ｋバイト）の各スロッ
トの先頭のバイト（０ｘ００００〜０ｘ７ＦＦ０）が示
されている。図１１に分離して示すように、属性ヘッダ
の先頭から３２バイトがヘッダであり、２５６バイトが
曲名領域ＮＭ１（２５６バイト）であり、５１２バイト
が曲名領域ＮＭ２（５１２バイト）である。属性ヘッダ
のヘッダには、下記のデータが書かれる。

【００４５】ＢＬＫＩＤ−ＨＤ０（４バイト）意味：BLOCKID FILE ID 機能：ＡＴＲＡＣ３データファイルの先頭であることを
識別するための値値：固定値＝”ＨＤ＝０”（例えば０ｘ４８４４２Ｄ３
０）ＭＣｏｄｅ（２バイト）意味：MAKER CODE 機能：記録した機器の、メーカー、モデルを識別するコ
ード値：上位１０ビット（メーカーコード）下位６ビット
（機種コード）ＢＬＯＣＫＳＥＲＩＡＬ（４バイト）意味：トラック毎に付けられた連続番号機能：ブロックの先頭は０から始まり次のブロックは＋
１づつインクリメント編集されても値を変化させない値：０より始まり０ｘＦＦＦＦＦＦＦＦまで。

【００４６】Ｎ１Ｃ＋Ｌ（２バイト）意味：トラック（曲名）データ（ＮＭ１）の属性を表す機能：ＮＭ１に使用される文字コードと言語コードを各
１バイトで表す値：ＳＮ１Ｃ＋Ｌと同一Ｎ２Ｃ＋Ｌ（２バイト）意味：トラック（曲名）データ（ＮＭ２）の属性を表す機能：ＮＭ２に使用される文字コードと言語コードを各
１バイトで表す値：ＳＮ１Ｃ＋Ｌと同一ＩＮＦＳＩＺＥ（２バイト）意味：トラックに関する付加情報の全てを合計したサイ
ズを表す機能：データサイズを１６バイト単位の大きさで記述、
無い場合は必ずオールゼロとすること値：サイズは０ｘ００００から０ｘ３Ｃ６（９６６）Ｔ−ＰＲＴ（２バイト）意味：トータルパーツ数機能：トラックを構成するパーツ数を表す。通常は１値：１から０ｘ２８５（６４５dec ）Ｔ−ＳＵ（４バイト）意味：トータルＳＵ数機能：１トラック中の実際の総ＳＵ数を表す。曲の演奏
時間に相当する値：０ｘ０１から０ｘ００１ＦＦＦＦＦＩＮＸ（２バイト）（Ｏｐｔｉｏｎ）意味：INDEX の相対場所機能：曲のさびの部分（特徴的な部分）の先頭を示すポ
インタ。曲の先頭からの位置をＳＵの個数を１／４した
数で指定する。これは、通常のＳＵの４倍の長さの時間
（約９３ｍ秒）に相当する値：０から０ｘＦＦＦＦ（最大、約６０８４秒）ＸＴ（２バイト）（Ｏｐｔｉｏｎ）意味：INDEX の再生時間機能：ＩＮＸ-nnnで指定された先頭から再生すべき時間
のＳＵの個数を１／４した数で指定する。これは、通常
のＳＵの４倍の長さの時間（約９３ｍ秒）に相当する値：０ｘ００００：無設定０ｘ０１から０ｘＦＦＦ
Ｅ（最大６０８４秒）０ｘＦＦＦＦ：曲の終わりまで。

【００４７】次に曲名領域ＮＭ１およびＮＭ２について
説明する。

【００４８】ＮＭ１意味：曲名を表す文字列機能：１バイトの文字コードで表した可変長の曲名（最
大で２５６）名前データの終了は、必ず終端コード（０ｘ００）を書
き込むことサイズはこの終端コードから計算すること、データの無
い場合は少なくとも先頭（０ｘ００２０）からヌル（０
ｘ００）を１バイト以上記録すること値：各種文字コードＮＭ２意味：曲名を表す文字列機能：２バイトの文字コードで表した可変長の名前デー
タ（最大で５１２）名前データの終了は、必ず終端コード（０ｘ００）を書
き込むことサイズはこの終端コードから計算すること、データの無
い場合は少なくとも先頭（０ｘ０１２０）からヌル（０
ｘ００）を２バイト以上記録すること値：各種文字コード。

【００４９】属性ヘッダの固定位置（０ｘ３２０）から
始まる、８０バイトのデータをトラック情報領域ＴＲＫ
ＩＮＦと呼び、主としてセキュリティ関係、コピー制御
関係の情報を一括して管理する。図１２にＴＲＫＩＮＦ
の部分を示す。ＴＲＫＩＮＦ内のデータについて、配置
順序に従って以下に説明する。

【００５０】ＣＯＮＴＥＮＴＳＫＥＹ（８バイト）意味：曲毎に用意された値で、メモリカードのセキュリ
ティブロックで保護されてから保存される機能：曲を再生する時、まず必要となる最初の鍵とな
る。ＭＡＣ計算時に使用される値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦまでＭＡＣ（８バイト）意味：著作権情報改ざんチェック値機能：コンテンツ累積番号を含む複数のＴＲＫＩＮＦの
内容と隠しシーケンス番号から作成される値隠しシーケンス番号とは、メモリカードの隠し領域に記
録されているシーケンス番号のことである。著作権対応
でないレコーダは、隠し領域を読むことができない。ま
た、著作権対応の専用のレコーダ、またはメモリカード
を読むことを可能とするアプリケーションを搭載したパ
ーソナルコンピュータは、隠し領域をアクセスすること
ができる。

【００５１】Ａ（１バイト）意味：パーツの属性機能：パーツ内の圧縮モード等の情報を示す値：図１３を参照して以下に説明するただし、Ｎ＝０，１のモノラルは、ｂｉｔ７が１でサブ
信号を０、メイン信号（Ｌ＋Ｒ）のみの特別なＪｏｉｎ
ｔモードをモノラルとして規定する。ｂｉｔ２，１の情
報は通常の再生機は無視しても構わない。

【００５２】Ａのビット０は、エンファシスのオン／オ
フの情報を形成し、ビット１は、再生ＳＫＩＰか、通常
再生かの情報を形成し、ビット２は、データ区分、例え
ばオーディオデータか、ＦＡＸ等の他のデータかの情報
を形成する。ビット３は、未定義である。ビット４、
５、６を組み合わせることによって、図示のように、Ａ
ＴＲＡＣ３のモード情報が規定される。すなわち、Ｎ
は、この３ビットで表されるモードの値であり、モノ
（Ｎ＝０，１），ＬＰ（Ｎ＝２），ＳＰ（Ｎ＝４），Ｅ
Ｘ（Ｎ＝５），ＨＱ（Ｎ＝７）の５種類のモードについ
て、記録時間（６４ＭＢのメモリカードの場合）、デー
タ転送レート、１ブロック内のＳＵ数がそれぞれ示され
ている。１ＳＵのバイト数は、（モノ：１３６バイト、
ＬＰ：１９２バイト、ＳＰ：３０４バイト、ＥＸ：３８
４バイト、ＨＱ：５１２バイト）である。さらに、ビッ
ト７によって、ＡＴＲＡＣ３のモード（０：Dual １：
Joint ）が示される。

【００５３】一例として、６４ＭＢのメモリカードを使
用し、ＳＰモードの場合について説明する。６４ＭＢの
メモリカードには、３９６８ブロックがある。ＳＰモー
ドでは、１ＳＵが３０４バイトであるので、１ブロック
に５３ＳＵが存在する。１ＳＵは、（１０２４／４４１
００）秒に相当する。従って、１ブロックは、（１０２４／４４１００）×５３×（３９６８−１６）
＝４８６３秒＝８１分転送レートは、（４４１００／１０２４）×３０４×８＝１０４７３７
bps となる。

【００５４】ＬＴ（１バイト）意味：再生制限フラグ（ビット７およびビット６）とセ
キュリティバージョン（ビット５〜ビット０）機能：このトラックに関して制限事項があることを表す値：ビット７：０＝制限なし１＝制限有りビット６：０＝期限内１＝期限切れビット５〜ビット０：セキュリティバージョン０（０以
外であれば再生禁止とする）ＦＮｏ（２バイト）意味：ファイル番号機能：最初に記録された時のトラック番号、且つこの値
は、メモリカード内の隠し領域に記録されたＭＡＣ計算
用の値の位置を特定する値：１から０ｘ１９０（４００）ＭＧ（Ｄ）ＳＥＲＩＡＬ−ｎｎｎ（１６バイト）意味：記録機器のセキュリティブロック（セキュリティ
ＩＣ２０）のシリアル番号機能：記録機器ごとに全て異なる固有の値値：０から0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF ＣＯＮＮＵＭ（４バイト）意味：コンテンツ累積番号機能：曲毎に累積されていく固有の値で記録機器のセキ
ュリティブロックによって管理される。２の３２乗、４
２億曲分用意されており、記録した曲の識別に使用する値：０から０ｘＦＦＦＦＦＦＦＦ。

【００５５】ＹＭＤｈｍｓ−Ｓ（４バイト）（Ｏｐｔｉｏｎ）意味：再生制限付きのトラックの再生開始日時機能：ＥＭＤで指定する再生開始を許可する日時値：上述した日時の表記と同じＹＭＤｈｍｓ−Ｅ（４バイト）（Ｏｐｔｉｏｎ）意味：再生制限付きのトラックの再生終了日時機能：ＥＭＤで指定する再生許可を終了する日時値：上述した日時の表記と同じＭＴ（１バイト）（Ｏｐｔｉｏｎ）意味：再生許可回数の最大値機能：ＥＭＤで指定される最大の再生回数値：１から０ｘＦＦ未使用の時は、０ｘ００ＬＴのｂｉｔ７の値が０の場合はＭＴの値は００とする
ことＣＴ（１バイト）（Ｏｐｔｉｏｎ）意味：再生回数機能：再生許可された回数の内で、実際に再生できる回
数。再生の度にデクリメントする値：０ｘ００〜０ｘＦＦ未使用の時は、０ｘ００であ
るＬＴのｂｉｔ７が１でＣＴの値が００の場合は再生を
禁止すること。

【００５６】ＣＣ（１バイト）意味：COPY CONTROL 機能：コピー制御値：図１４に示すように、ビット６および７によってコ
ピー制御情報を表し、ビット４および５によって高速デ
ィジタルコピーに関するコピー制御情報を表し、ビット
２および３によってセキュリティブロック認証レベルを
表す。ビット０および１は、未定義ＣＣの例：（ｂｉｔ７，６）１１：無制限のコピーを許
可、０１：コピー禁止、００：１回のコピーを許可（ｂｉｔ３，２）００：アナログないしディジタルイン
からの録音、ＭＧ認証レベルは０とするＣＤからのディジタル録音では（ｂｉｔ７，６）は０
０、（ｂｉｔ３，２）は００となるＣＮ（１バイト）（Ｏｐｔｉｏｎ）意味：高速ディジタルコピーＨＳＣＭＳ(High speed Se
rial Copy ManagementSystem)におけるコピー許可回数機能：コピー１回か、コピーフリーかの区別を拡張し、
回数で指定する。コピー第１世代の場合にのみ有効であ
り、コピーごとに減算する値：００：コピー禁止、０１から０ｘＦＥ：回数、０ｘ
ＦＦ：回数無制限。

【００５７】上述したトラック情報領域ＴＲＫＩＮＦに
続いて、０ｘ０３７０から始まる２４バイトのデータを
パーツ管理用のパーツ情報領域ＰＲＴＩＮＦと呼び、１
つのトラックを複数のパーツで構成する場合に、時間軸
の順番にＰＲＴＩＮＦを並べていく。図１５にＰＲＴＩ
ＮＦの部分を示す。ＰＲＴＩＮＦ内のデータについて、
配置順序に従って以下に説明する。

【００５８】ＰＲＴＳＩＺＥ（４バイト）意味：パーツサイズ機能：パーツの大きさを表す。クラスタ：２バイト（最
上位）、開始ＳＵ：１バイト（上位）、終了ＳＵ：１バ
イト（最下位）値：クラスタ：１から０ｘ１Ｆ４０（８０００）、開始
ＳＵ：０から０ｘＡ０（１６０）、終了ＳＵ：０から０
ｘＡ０（１６０）（但し、ＳＵの数え方は、０，１，
２，と０から開始する）ＰＲＴＫＥＹ（８バイト）意味：パーツを暗号化するための値機能：初期値＝０、編集時は編集の規則に従うこと値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＣＯＮＮＵＭ０（４バイト）意味：最初に作られたコンテンツ累積番号キー機能：コンテンツをユニークにするためのＩＤの役割値：コンテンツ累積番号初期値キーと同じ値とされる。

【００５９】ＡＴＲＡＣ３データファイルの属性ヘッダ
中には、図１０に示すように、付加情報ＩＮＦが含まれ
る。この付加情報は、開始位置が固定化されていない点
を除いて、再生管理ファイル中の付加情報ＩＮＦ−Ｓ
（図７および図８Ｂ参照）と同一である。１つまたは複
数のパーツの最後のバイト部分（４バイト単位）の次を
開始位置として付加情報ＩＮＦのデータが開始する。

【００６０】ＩＮＦ意味：トラックに関する付加情報データ機能：ヘッダを伴った可変長の付加情報データ。複数の
異なる付加情報が並べられることがある。それぞれにＩ
Ｄとデータサイズが付加されている。個々のヘッダを含
む付加情報データは、最小１６バイト以上で４バイトの
整数倍の単位値：再生管理ファイル中の付加情報ＩＮＦ−Ｓと同じで
ある。

【００６１】上述した属性ヘッダに対して、ＡＴＲＡＣ
３データファイルの各ブロックのデータが続く。図１６
に示すように、ブロック毎にヘッダが付加される。各ブ
ロックのデータについて以下に説明する。

【００６２】ＢＬＫＩＤ−Ａ３Ｄ（４バイト）意味：BLOCKID FILE ID 機能：ＡＴＲＡＣ３データの先頭であることを識別する
ための値値：固定値＝”Ａ３Ｄ”（例えば０ｘ４１３３４４２
０）ＭＣｏｄｅ（２バイト）意味：MAKER CODE 機能：記録した機器の、メーカー、モデルを識別するコ
ード値：上位１０ビット（メーカーコード）下位６ビット
（機種コード）ＣＯＮＮＵＭ０（４バイト）意味：最初に作られたコンテンツ累積番号機能：コンテンツをユニークにするためのＩＤの役割、
編集されても値は変化させない値：コンテンツ累積番号初期値キーと同じ値とされるＢＬＯＣＫＳＥＲＩＡＬ（４バイト）意味：トラック毎に付けられた連続番号機能：ブロックの先頭は０から始まり次のブロックは＋
１づつインクリメント編集されても値を変化させない値：０より始まり０ｘＦＦＦＦＦＦＦＦまでＢＬＯＣＫ−ＳＥＥＤ（８バイト）意味：１ブロックを暗号化するための１つの鍵機能：ブロックの先頭は、記録機器のセキュリティブロ
ックで乱数を生成、続くブロックは、＋１インクリメン
トされた値、この値が失われると、１ブロックに相当す
る約１秒間、音が出せないために、ヘッダとブロック末
尾に同じものが二重に書かれる。編集されても値を変化
させない値：初期は８バイトの乱数ＩＮＩＴＩＡＬＩＺＡＴＩＯＮＶＥＣＴＯＲ（８バイ
ト）意味：ブロック毎にＡＴＲＡＣ３データを暗号化、復号
化する時に必要な初期値機能：ブロックの先頭は０から始まり、次のブロックは
最後のＳＵの最後の暗号化された８バイトの値。デバイ
ドされたブロックの途中からの場合は開始ＳＵの直前の
最後の８バイトを用いる。編集されても値を変化させな
い値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＳＵ−ｎｎｎ意味：サウンドユニットのデータ機能：１０２４サンプルから圧縮されたデータ、圧縮モ
ードにより出力されるバイト数が異なる。編集されても
値を変化させない（一例として、ＳＰモードの時では、
Ｎ＝３８４バイト）値：ＡＴＲＡＣ３のデータ値。

【００６３】図１０では、Ｎ＝３８４であるので、１ブ
ロックに４２ＳＵが書かれる。また、１ブロックの先頭
の２つのスロット（４バイト）がヘッダとされ、最後の
１スロット（２バイト）にＢＬＫＩＤ−Ａ３Ｄ、ＭＣｏ
ｄｅ、ＣＯＮＮＵＭ０、ＢＬＯＣＫＳＥＲＩＡＬが二
重に書かれる。従って、１ブロックの余りの領域Ｍバイ
トは、（１６，３８４−３８４×４２−１６×３＝２０
８（バイト）となる。この中に上述したように、８バイ
トのＢＬＯＣＫＳＥＥＤが二重に記録される。

【００６４】また、サウンドユニットＳＵ（０）〜（１
０１）は、図２に示す暗号化／復号ユニット６４におい
てＣＢＣ(Cipher Block Chainning)モードで６４ビット
（８バイト）の暗号化ブロックを単位として暗号化して
生成された８バイトの暗号文Ｃ_iによって構成される。
本実施形態では、サウンドユニットＳＵのバイト数（例
えば１６０バイト）を、暗号化の単位である暗号化ブロ
ックのバイト数（例えば８バイト）の整数倍にしてい
る。すなわち、１サウンドユニットＳＵは例えば２０個
の暗号文Ｃ_iからなる。このとき、個々の暗号文Ｃ_iは
一のサウンドユニットＳＵ内に位置し、一の暗号文Ｃ_i
が複数のサウンドユニットＳＵに跨がって位置すること
はない。

【００６５】ここで、フラッシュメモリ３４に記憶され
ているオーディオデータは、後述するように例えば、Ａ
ＴＲＡＣ３方式で圧縮されており、当該圧縮の単位がサ
ウンドユニットＳＵである。従って、携帯用記憶装置３
から携帯用プレーヤ４にオーディオデータを読み出す場
合には、読み出しの最小単位は当該サウンドユニットＳ
Ｕとなる。

【００６６】このようにすることで、フラッシュメモリ
３４に記憶されている暗号化されたオーディオデータに
アクセスする際に、暗号化ブロックの区切りを意識する
必要がなくなり、当該アクセスに伴う処理負担を軽減で
きる。なお、各クラスタ内に含まれるサウンドユニット
ＳＵの数は、１個以上１０２個以下の範囲で任意であ
る。また、オーディオデータの圧縮方式は、ＡＴＲＡＣ
３などのＡＴＲＡＣ方式以外のＣＯＤＥＣ方式でもよ
い。

【００６７】ブロックシードデータＢＳは、各ブロック
毎に例えば乱数を発生して生成されたデータであり、後
述するように、携帯用プレーヤ４内でブロック毎にブロ
ック鍵データＢＫを生成する際に用いられる。当該ブロ
ックシードデータＢＳは、エラー対策としてブロック内
の２箇所に格納されている。なお、各クラスタに含まれ
るサウンドユニットは、暗号化された順でフラッシュメ
モリ３４の連続したアドレスに記憶される。また、各サ
ウンドユニット内の暗号化ブロックは、暗号化された順
にフラッシュメモリ３４の連続したアドレスに記憶され
る。

【００６８】〔フラッシュメモリ管理モジュール３５〕
フラッシュメモリ管理モジュール３５は、フラッシュメ
モリ３４へのデータの書き込み、フラッシュメモリ３４
からのデータの読み出しなどの制御を行う。

【００６９】携帯用プレーヤ４図２に示すように、携帯
用プレーヤ４は、例えば、主制御モジュール４１、通信
インターフェイス４２、制御モジュール４３、編集モジ
ュール４４、圧縮／伸長モジュール４５、スピーカ４
６、Ｄ／Ａ変換器４７およびＡ／Ｄ変換器４８を有す
る。

【００７０】〔主制御モジュール４１〕主制御モジュー
ル４１は、携帯用プレーヤ４の処理を統括的に制御す
る。

【００７１】〔制御モジュール４３〕図２に示すよう
に、制御モジュール４３は、例えば、乱数発生ユニット
６０、記憶ユニット６１、鍵生成／鍵演算ユニット６
２、相互認証ユニット６３、暗号化／復号ユニット６４
および制御ユニット６５を有する。制御モジュール４３
は、制御モジュール３３と同様に、シングルチップの暗
号処理専用の集積回路であり、多層構造を有し、内部の
メモリセルはアルミニウム層などのダミー層に挟まれて
いる。また、制御モジュール４３は、動作電圧または動
作周波数の幅が狭く、外部から不正にデータを読み出せ
ないように耐タンパー性を有している。乱数発生ユニッ
ト６０は、乱数発生指示を受けると、６４ビット（８バ
イト）の乱数を発生する。記憶ユニット６１は、認証処
理に必要な種々のデータを記憶している。

【００７２】図１７は、記憶ユニット６１に記憶されて
いるデータを説明するための図である。図１７に示すよ
うに、記憶ユニット６１は、マスター鍵データＭＫ₀〜
ＭＫ₃₁および装置識別データＩＤd を記憶している。こ
こで、マスター鍵データＭＫ₀〜ＭＫ₃₁と、認証鍵デー
タＩＫ₀〜ＩＫ₃₁との間には、前述した携帯用記憶装置
３の装置識別データＩＤ_mを用いて、下記式（１）に示
す関係がある。なお、下記式において、ｆ（ａ，ｂ）
は、例えば、引数ａ，ｂから値を導出する関数である。

【００７３】

【数１】ＩＫ_j＝ｆ（ＭＫ_j，ＩＤ_m）・・・（１）但し、ｉは、０≦ｊ≦３１の整数。

【００７４】また、記憶ユニット６１における認証鍵デ
ータＩＫ₀〜ＩＫ₃₁の記憶アドレスは、例えば５ビット
で表現され、それぞれ記憶ユニット５１におけるマスタ
ー鍵データＭＫ₀〜ＭＫ₃₁と同じ記憶アドレスが割り当
てられている。

【００７５】鍵生成／鍵演算ユニット６２は、例えば、
ＩＳＯ／ＩＥＣ９７９７のＭＡＣ演算方式を用いた演算
などの種々の演算を行って鍵データを生成する。このと
き、"Block cipher Algorithm"としてＦＩＰＳＰＵＢ
４６−２に規定されるＤＥＳが用いられる。

【００７６】相互認証ユニット６３は、例えば、コンピ
ュータ２から入力したオーディオデータを携帯用記憶装
置３に出力する動作を行うのに先立って、携帯用記憶装
置３との間で相互認証処理を行う。また、相互認証ユニ
ット６３は、携帯用記憶装置３からオーディオデータを
入力する動作を行うのに先立って、携帯用記憶装置３と
の間で相互認証処理を行う。また、相互認証ユニット６
３は、相互認証処理において、前述したＭＡＣ演算を行
う。当該相互認証処理では、記憶ユニット６１に記憶さ
れているデータが用いられる。なお、相互認証ユニット
６３は、必要に応じて、例えば、コンピュータ２あるい
はネットワーク５上のコンピュータとの間でオーディオ
データの入出力を行う動作に先立って、コンピュータ２
あるいはネットワーク５上のコンピュータとの間で相互
認証処理を行う。

【００７７】暗号化／復号ユニット６４は、前述したよ
うに、ＦＩＰＳＰＵＢ８１に規定されたＥＣＢモー
ドおよびＣＢＣモードを選択的に用いてブロック暗号化
を行う。ここで、暗号化／復号ユニット６４は、ＣＢＣ
モードにおいて、５６ビットの鍵データｋを用いて、コ
ンピュータ２あるいはＣＤプレーヤ７から入力したオー
ディオデータ（平文）を、６４ビットからなる暗号化ブ
ロックを単位として下記式（２）に基づいて暗号化して
暗号化されたオーディオデータ（暗号文）を生成する。
下記式（２）から分かるように、ＣＢＣモードでは、一
つ前の暗号文と次の平文との排他的論理和を暗号化する
ため、同一の平文が入力されても異なる暗号文が出力さ
れ、解読が困難であるという利点がある。

【００７８】

【数２】Ｃ_i＝Ｅ_k（Ｐ_iＸＯＲＣ_i-1）・・・（２）ｉ：１以上の整数Ｐ_i：平文（６４ビット）Ｃ_i：暗号文（６４ビット）ＸＯＲ：排他的論理和Ｅ_k：５６ビットの鍵データｋを用いたＤＥＳ方式の暗
号処理上記式（２）の演算は、図１８で表現される。なお、図
１８において、「ＩＶ」は、ブロック暗号化初期値（６
４ビット）であり、図２に示す携帯用記憶装置３のフラ
ッシュメモリ３４において、図８に示すようにクラスタ
ＣＬ内のサウンドユニットＳＵ（０）の直前に記憶され
る。

【００７９】なお、コンピュータ２あるいはＣＤプレー
ヤ７から入力したオーディオデータ（平文）は、ＡＴＲ
ＡＣ(Adaptive TRansform Audio Coder)方式を改良した
ＡＴＲＡＣ３方式で圧縮されている。なお、ＡＴＲＡＣ
は、ＭＤ(Mini Disk：商標)のための符号化圧縮方式で
あり、例えば、２８８ｋｂｉｔ／ｓで４４．１ｋＨｚサ
ンプルのステレオ信号が、帯域分割とＭＤＣＴ(Modifie
d Discrete Cosine Transform)とを併用して符号化され
ている。すなわち、先ず、帯域分割フィルタで１／４，
１／４，１／２の３つの帯域に分割され、それぞれの帯
域の信号がダウンサンプルされ、時間領域の信号として
ＭＤＣＴで周波数領域に変換され、当該ＭＤＣＴの係数
が適応ビット配分を行ってスカラ量子化されている。

【００８０】暗号化／復号ユニット６４は、ＦＩＰＳ８
１のモードのうち、前述したＥＣＢモードおよびＣＢＣ
モードの復号を選択的に行う。ここで、暗号化／復号ユ
ニット６４は、ＣＢＣモードにおいて、５６ビットの鍵
データｋを用いて、暗号文を、６４ビットからなる暗号
化ブロックを単位として下記式（３）に基づいて復号し
て平文を生成する。

【００８１】

【数３】Ｐ_i＝Ｃ_i-1ＸＯＲＤ_k（Ｃ_i）・・・（３）ｉ：１以上の整数Ｐ_i：平文（６４ビット）Ｃ_i：暗号文（６４ビット）ＸＯＲ：排他的論理和Ｄ_k：５６ビットの鍵データｋを用いたＤＥＳ方式の復
号処理上記式（３）の演算は、図１９で表現される。なお、図
１９において、「ＩＶ」は、ブロック暗号化初期値（６
４ビット）であり、図２に示す携帯用記憶装置３のフラ
ッシュメモリ３４において図８に示すようにクラスタＣ
Ｌ内のサウンドユニットＳＵ（０）の直前に記憶された
ものが用いられる。

【００８２】制御ユニット６５は、乱数発生ユニット６
０、記憶ユニット６１、鍵生成／鍵演算ユニット６２、
相互認証ユニット６３および暗号化／復号ユニット６４
の処理を統括的に制御する。

【００８３】〔編集モジュール４４〕編集モジュール４
４は、例えば、図４に示すように携帯用記憶装置３のフ
ラッシュメモリ３４内に記憶されたトラックデータファ
イル１０１₀〜１０１₃を、ユーザからの操作指示に基
づいて編集して新たなトラックデータファイルを生成す
る。当該編集には、１個のトラックデータファイルを分
割して２個のトラックデータファイルを生成する分割編
集処理と、２個のトラックデータファイルを結合して１
個のトラックデータファイルを生成する結合編集処理と
がある。なお、当該編集にあたって、再生管理ファイル
１００およびトラックデータファイル１０１₀〜１０１
₃が書き換えられる。編集モジュール４４における編集
処理については後に詳細に説明する。

【００８４】〔圧縮／伸長モジュール４５〕圧縮／伸長
モジュール４５は、例えば、携帯用記憶装置３から入力
した暗号化されたオーディオデータを復号した後に再生
する際に、ＡＴＲＡＣ３方式で圧縮されているオーディ
オデータを伸長し、当該伸長したオーディオデータをＤ
／Ａ変換器４７に出力する。また、例えば、ＣＤプレー
ヤ７あるいはコンピュータ２から入力したオーディオデ
ータを、携帯用記憶装置３に記憶する際に、当該オーデ
ィオデータをＡＴＲＡＣ３方式で圧縮する。

【００８５】〔Ｄ／Ａ変換器４７〕Ｄ／Ａ変換器４７
は、圧縮／伸長モジュール４５から入力したデジタル形
式のオーディオデータをアナログ形式のオーディオデー
タに変換してスピーカ４６に出力する。

【００８６】〔スピーカ４６〕スピーカ４６は、Ｄ／Ａ
変換器４７から入力したオーディオデータに応じた音響
を出力する。

【００８７】〔Ａ／Ｄ変換器４８〕Ａ／Ｄ変換器４８
は、例えば、ＣＤプレーヤ７から入力したアナログ形式
のオーディオデータをデジタル形式に変換して圧縮／伸
長モジュール４５に出力する。

【００８８】以下、図１に示すオーディオシステム１の
動作について説明する。

【００８９】携帯用記憶装置３への書き込み動作図２０
は、携帯用プレーヤ４から携帯用記憶装置３への書き込
み動作を説明するためのフローチャートである。

【００９０】ステップＳ１：携帯用プレーヤ４から携帯
用記憶装置３に、書き込み要求信号が出力される。

【００９１】ステップＳ２：携帯用記憶装置３と携帯用
プレーヤ４との間で、相互認証処理を行う際に用いる認
証鍵データＩＫ_jの選択処理が行われる。当該処理につ
いては後述する。

【００９２】ステップＳ３：携帯用記憶装置３と携帯用
プレーヤ４との間で相互認証処理が行われる。当該処理
については後述する。

【００９３】ステップＳ４：ステップＳ３の相互認証処
理によって携帯用記憶装置３および携帯用プレーヤ４の
双方が相手を正当であると認めた場合には、ステップＳ
５の処理が行われ、そうでない場合には処理が終了す
る。

【００９４】ステップＳ５：携帯用記憶装置３および携
帯用プレーヤ４において、セッション鍵データＳｅｋが
生成される。当該処理については後述する。

【００９５】ステップＳ６：携帯用プレーヤ４から携帯
用記憶装置３に、通信インターフェイス３２，４２を介
して、暗号化したオーディオデータを出力して書き込
む。当該処理については後述する。

【００９６】このように、オーディオシステム１によれ
ば、携帯用記憶装置３と携帯用プレーヤ４との間で相互
認証が行われ、双方が相手を正当であると認めた場合に
のみ、携帯用プレーヤ４から携帯用記憶装置３に、暗号
化されたオーディオデータが書き込まれる。そのため、
著作権侵害を招くようなオーディオデータの不正な複製
が容易に行われることを回避できる。

【００９７】〔認証鍵データＩＫ_jの選択処理（図２０
に示すステップＳ２）〕図２１は、認証鍵データＩＫ_j
の選択処理を説明するための図である。図２１に示すよ
うに、図２に示す携帯用プレーヤ４の乱数発生ユニット
６０によって６４ビットの乱数Ｒ_jが生成される。当該
乱数Ｒ_jは、携帯用プレーヤ４から携帯用記憶装置３に
出力される。そして、携帯用記憶装置３の相互認証ユニ
ット５３によって、６４ビットの乱数Ｒ_jの下位５ビッ
トを用いて、記憶ユニット５１に記憶されている認証鍵
データＩＫ₀〜ＩＫ₃₁のうち一の認証鍵データＩＫ
_j（ｊは０≦ｊ≦３１を満たす整数）が特定される。

【００９８】また、携帯用記憶装置３の記憶ユニット５
１から読み出された装置識別データＩＤ_mが、携帯用記
憶装置３から携帯用プレーヤ４に出力される。

【００９９】そして、携帯用プレーヤ４の相互認証ユニ
ット６３によって、乱数Ｒ_jの下位５ビットを用いて、
マスター鍵データＭＫ₀〜ＭＫ₃₁のうち一のマスター鍵
データＭＫ_jが特定される。

【０１００】そして、鍵生成／鍵演算ユニット６２にお
いて、前記特定されたマスター鍵データＭＫ_jと、携帯
用記憶装置３から入力した装置識別データＩＤ_mとを用
いて、下記式（４）に基づいて、認証鍵データＩＫ_jを
生成する。下記式（４）において、ｆ（ａ，ｂ）は、例
えば、引数ａ，ｂから値を導出する任意の関数である。

【０１０１】

【数４】ＩＫ_j＝ｆ（ＭＫ_j，ＩＤ_m）・・・（４）これにより、携帯用記憶装置３と携帯用プレーヤ４と
が、上記式（４）に示す関係を持つ認証鍵データＩＫ₀
〜ＩＫ₃₁およびマスター鍵データＭＫ₀〜ＭＫ₃₁を有し
ている場合には、図２１に示す処理によって同じ認証鍵
データＩＫ_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 Cryptog
raphy,CRC Press"などに詳しく記述されている。

【０１３３】ステップＳ５１：携帯用プレーヤ４は、コ
ンピュータ２あるいは携帯用プレーヤ４から入力したオ
ーディオデータを、圧縮／伸長モジュール４５におい
て、ＡＴＲＡＣ３方式で圧縮する。そして、暗号化／復
号ユニット６４において、ステップＳ５０で生成したブ
ロック鍵データＢＫを用いて、前記圧縮したオーディオ
データをＣＢＣモードで暗号化する。

【０１３４】ステップＳ５２：携帯用プレーヤ４は、ス
テップＳ５１で暗号化したオーディオデータに属性ヘッ
ダを付加して、通信インターフェイス３２，４２を介し
て、携帯用記憶装置３に出力する。

【０１３５】ステップＳ５３：携帯用記憶装置３は、ス
テップＳ５２で入力した暗号化されたオーディオデータ
と属性ヘッダを、フラッシュメモリ３４にそのまま書き
込む。以上の処理によって、携帯用プレーヤ４から携帯
用プレーヤ４へのオーディオデータの書き込み処理が終
了する。なお、ここでは、図４のトラックデータファイ
ル１０１0 〜１０１3 についてのみ述べたが、携帯用プ
レーヤ４は、図４の再生管理ファイルについても同様に
適宜更新を行う。

【０１３６】携帯用記憶装置３からの読み出し動作図２５は、携帯用記憶装置３から携帯用プレーヤ４への
読み出し動作を説明するためのフローチャートである。

【０１３７】ステップＳ６１：携帯用プレーヤ４から携
帯用記憶装置３に、読み出しを要求するトラックデータ
（曲）を特定した読み出し要求信号が出力される。

【０１３８】ステップＳ２：図２１を用いて前述したよ
うに、携帯用記憶装置３と携帯用プレーヤ４との間で相
互認証処理を行う際に用いる認証鍵データＩＫ_jの選択
処理が行われる。

【０１３９】ステップＳ３：図２２を用いて前述したよ
うに、携帯用記憶装置３と携帯用プレーヤ４との間で相
互認証処理が行われる。

【０１４０】ステップＳ４：ステップＳ３の相互認証処
理によって携帯用記憶装置３および携帯用プレーヤ４の
双方が相手を正当であると認めた場合には、ステップＳ
５の処理が行われ、そうでない場合には処理が終了す
る。

【０１４１】ステップＳ５：携帯用記憶装置３および携
帯用プレーヤ４において、セッション鍵データＳｅｋが
生成される。

【０１４２】ステップＳ６３：暗号化されたオーディオ
データを、通信インターフェイス３２，４２を介して、
携帯用記憶装置３から携帯用プレーヤ４に読み出す。当
該処理については後述する。

【０１４３】すなわち、オーディオシステム１では、携
帯用記憶装置３と携帯用プレーヤ４との間で相互認証が
行われ、双方が相手を正当であると認めた場合にのみ、
後述するように、携帯用プレーヤ４において、携帯用記
憶装置３から携帯用プレーヤ４に出力された暗号化され
たコンテンツ鍵データＣＫを適切なセッション鍵データ
Ｓｅｋで解読できる。そのため、著作権侵害を招くよう
なオーディオデータの不正な利用が容易に行われること
を回避できる。

【０１４４】〔携帯用記憶装置３からのオーディオデー
タの読み出し処理（図２５に示すステップＳ６３）〕図
２６は、携帯用記憶装置３から携帯用プレーヤ４へのオ
ーディオデータの読み出し処理を説明するための図であ
る。なお、当該読み出し処理は、前述した図２０に示す
書き込み処理の後に行われるため、図４に示すトラック
データファイル１０１0 〜１０１3 には、図１０に示す
ように、ＴＲＩＮＦにコンテンツ鍵データＣＫが設定さ
れ、パーツ毎にパーツ鍵データＰＫが設定され、各クラ
スタＣＬ内にはブロックシードデータＢＳが設定されて
いる。また、ステップＳ５の処理が終了しているため、
携帯用記憶装置３および携帯用プレーヤ４は、正当な相
手同士であれば、同じセッション鍵データＳｅｋを有し
ている。

【０１４５】ステップＳ７１：携帯用記憶装置３は、フ
ラッシュメモリ３４に記憶されている図４に示すトラッ
クデータファイル１０１0 〜１０１3 のうち読み出し要
求信号で特定されるトラックデータに対応するトラック
データファイルを特定し、当該特定したトラックデータ
ファイルを構成するクラスタ内のオーディオデータを、
サウンドユニットＳＵを単位として読み出して携帯用プ
レーヤ４に出力する。携帯用記憶装置３は、また、上記
トラックデータファイルの属性ヘッダを読み出して携帯
用プレーヤ４に出力する。

【０１４６】ステップＳ７２：携帯用プレーヤ４は、当
該入力された属性ヘッダのうち、ＴＲＩＮＦから暗号化
されたコンテンツ鍵ＣＫを抽出し、携帯用記憶装置３に
出力する。

【０１４７】ステップＳ７３：携帯用記憶装置３の暗号
化／復号ユニット５４は、ステップＳ７２で入力された
コンテンツ鍵データＣＫを、記憶ユニット５１に記憶さ
れている記憶用鍵データＳＫm を用いて復号する。

【０１４８】ステップＳ７４：携帯用記憶装置３の暗号
化／復号ユニット５４は、ステップＳ７３で復号したコ
ンテンツ鍵データＣＫを、図２５に示すステップＳ５で
得られたセッション鍵データＳｅｋを用いて暗号化す
る。

【０１４９】ステップＳ７５：携帯用記憶装置３は、ス
テップＳ７４で暗号化したコンテンツ鍵データＣＫを携
帯用プレーヤ４に出力する。

【０１５０】ステップＳ７６：携帯用プレーヤ４の暗号
化／復号ユニット６４は、ステップＳ７３で携帯用記憶
装置３から入力したコンテンツ鍵データＣＫを、セッシ
ョン鍵データＳｅｋを用いて復号する。

【０１５１】ステップＳ７７：携帯用プレーヤ４の鍵生
成／演算ユニット６２は、ステップＳ７６で復号された
コンテンツ鍵データＣＫと、ステップＳ７１で入力され
た属性ヘッダの中のＰＲＴＩＮＦに含まれるパーツ鍵デ
ータＰＫとの排他的論理和を演算し、当該演算結果をテ
ンポラリ鍵データＴＭＫとする。

【０１５２】

【数１３】ＴＭＫ＝ＰＫＸＯＲＣＫ・・・（１３）ステップＳ７８：携帯用プレーヤ４の鍵生成／鍵演算ユ
ニット６２において、ステップＳ７６で生成したテンポ
ラリ鍵データＴＭＫと、ステップＳ７１で入力されたト
ラックデータファイルのクラスタ内の図１０に示すブロ
ックシードデータＢＳとを用いて、下記式（１４）に示
すＭＡＣ演算を行い、当該演算結果をブロック鍵データ
ＢＫとする。ブロック鍵データＢＫは、ブロック毎に求
められる。

【０１５３】

【数１４】ＢＫ＝ＭＡＣ（ＴＭＫ，ＢＳ）・・・（１４）ステップＳ７９：携帯用プレーヤ４は、暗号化／復号ユ
ニット６４において、ステップＳ７８で生成したブロッ
ク鍵データＢＫを用いて、ステップＳ７１で入力したオ
ーディオデータを復号する。このとき、オーディオデー
タの復号は、各ブロック毎に、それそれ個別に求められ
たブロック鍵データＢＫを用いて行われる。また、復号
は、暗号化の単位である８バイトのブロックを単位とし
て行われる。

【０１５４】ステップＳ８０：携帯用プレーヤ４は、圧
縮／伸長モジュール４５において、ステップＳ７９で復
号したオーディオデータをＡＴＲＡＣ３方式で伸長し、
当該伸長したオーディオデータを、Ｄ／Ａ変換器４７で
デジタル形式に変換した後に、スピーカ４６に出力す
る。このとき、圧縮／伸長モジュール４５は、ステップ
Ｓ７８で復号したオーディオデータを、サウンドユニッ
トＳＵを単位として伸長する。以上の処理によって、携
帯用記憶装置３から携帯用プレーヤ４４へのオーディオ
データの読み出しおよび再生が終了する。

【０１５５】〔トラックデータファイルの分割編集処
理〕前述したように、携帯用プレーヤ４の編集モジュー
ル４４は、１個のトラックデータファイルを分割して２
個のトラックデータファイルを生成する分割編集処理
と、２個のトラックデータファイルを結合して１個のト
ラックデータファイルを生成する結合編集処理とを行
う。

【０１５６】先ず、分割編集処理について説明する。図
２７は、携帯用プレーヤ４の編集モジュール４４による
トラックデータファイルの分割編集処理を説明するため
の図である。編集モジュール４４は、例えば、図２７Ａ
に示す１個のトラックデータファイル（１）を、図２７
Ｂに示すトラックデータファイル（１）と、図２７Ｃに
示すトラックデータファイル（２）とに分割する。この
とき、分割の区切りとなる最小単位はサウンドユニット
ＳＵであり、当該例では、図２７Ｂに示すように、トラ
ックデータファイル（１）のクラスタＣＬ（２）のサウ
ンドユニットＳＵ（３）とＳＵ（４）との間で分割され
ている。

【０１５７】当該分割により、分割後のトラックデータ
ファイル（１）のクラスタＣＬ（２）は図２８Ａに示す
ようになり、新たに生成されたトラックデータファイル
（２）のクラスタＣＬ（０）は図２８Ｂに示すようにな
る。このとき、図２８Ｂに示すように、トラックデータ
ファイル（２）のクラスタＣＬ（０）のサウンドユニッ
トＳＵ（０）は分割前のトラックデータファイル（１）
のクラスタ（２）のサウンドユニットＳＵ（４）とな
り、ラックデータファイル（２）のクラスタＣＬ（０）
のサウンドユニットＳＵ（１）は分割前のトラックデー
タファイル（１）のクラスタ（２）のサウンドユニット
ＳＵ（５）となる。また、図２８Ｂに示すトラックデー
タファイル（２）のクラスタＣＬ（０）のブロック暗号
化初期値ＩＶには、図２７Ａ，Ｂに示すトラックデータ
ファイル（１）のクラスタＣＬ（２）内のサウンドユニ
ットＳＵ（３）の最後の８バイトが設定される。

【０１５８】本実施形態では、前述したように各クラス
タ内において、最初のサウンドユニットＳＵ（０）の直
前にブロック暗号化初期値ＩＶを配置したことで、分割
の際に、分割位置の直前の８バイトをそのままブロック
暗号化初期値ＩＶとして用いれば良く、新たなトラック
データファイルを作成する際の処理を簡単にできる。ま
た、再生時に、サウンドユニットＳＵ（０）と共に、そ
の直前のブロック暗号化初期値ＩＶを読み出せばよいた
め、再生処理も簡単になる。

【０１５９】本実施形態では、分割前のトラックデータ
ファイル（１）のコンテンツ鍵データ、パーツ鍵データ
およびブロック鍵データは、それぞれＣＫ＿１、ＰＫ＿
１およびＢＫ＿１である。また、分割後のトラックデー
タファイル（１）のコンテンツ鍵データ、パーツ鍵デー
タおよびブロック鍵データは、それぞれＣＫ＿１’、Ｐ
Ｋ＿１’およびＢＫ＿１である。また、トラックデータ
ファイル（２）のコンテンツ鍵データ、パーツ鍵データ
およびブロック鍵データは、それぞれＣＫ＿２、ＰＫ＿
２およびＢＫ＿１である。

【０１６０】図２９は、携帯用プレーヤ４の編集モジュ
ール４４において、新たなトラックデータファイル
（２）のコンテンツ鍵データおよびパーツ鍵データを生
成する方法を説明するための図である。分割により生成
された新たなトラックデータファイル（２）は、トラッ
クデータファイル（１）とは別に新たなコンテンツ鍵デ
ータＣＫ＿２を有する。本実施形態では、パーツ鍵デー
タＰＫ＿２を以下に示すように算出することで、ブロッ
ク鍵データＢＫ＿１を分割前と同じにする。

【０１６１】ステップＳ９０：編集モジュール４４は、
トラックデータファイルの分割指示を入力したか否かを
判断し、入力したと判断した場合にはステップＳ９１の
処理を実行し、入力していないと判断した場合にはステ
ップＳ９０の処理を繰り返す。

【０１６２】ステップＳ９１：編集モジュール４４は、
乱数発生ユニット６０に乱数を発生させ、当該乱数に応
じたコンテンツ鍵データＣＫ＿２を新たに生成する。

【０１６３】ステップＳ９２：携帯用記憶装置３の暗号
化／復号ユニット５４において、ステップＳ９１で生成
したコンテンツ鍵データＣＫ＿２を、記憶ユニット５１
に記憶されている記憶用鍵データＳＫm を用いて暗号化
する。

【０１６４】ステップＳ９３：編集モジュール４４は、
当該暗号化されたコンテンツ鍵データＣＫ＿２を、当該
トラックデータファイルのＴＲＫＩＮＦに書き込む。

【０１６５】ステップＳ９４：編集モジュール４４は、
トラックデータファイル（２）のパーツ鍵データＰＫ＿
２を下記式（１５）に基づいて生成する。

【０１６６】

【数１５】ＰＫ＿２＝ＣＫ＿１ＸＯＲＰＫ＿１ＸＯＲＣＫ＿２・・・（１５）これにより、トラックデータファイル（２）について、
前記式（１１）に基づいてされるテンポラリ鍵データ
は、トラックデータファイル（１）のテンポラリ鍵デー
タと同じになり、前記式（１２）に基づいて生成される
ブロック鍵データも分割前のブロック鍵データＢＫ＿１
と同じにできる。そのため、トラックデータファイル
（２）内のサウンドユニットＳＵを新たなブロック鍵デ
ータを用いて再度暗号化する必要がない。

【０１６７】ステップＳ９５：編集モジュール４４は、
ステップＳ９４で生成したパーツ鍵データＰＫ＿２を、
当該トラックデータファイルＰＲＴＩＮＦにそのまま書
き込む。

【０１６８】このように、オーディオシステム１では、
分割して新たに生成したトラックデータファイル（２）
のコンテンツ鍵データとして、新たなコンテンツ鍵デー
タＣＫ＿２を用いた場合でも、上記式（１５）に基づい
てパーツ鍵データＰＫ＿２を生成することで、テンポラ
リ鍵データを分割前のテンポラリ鍵データと同じにでき
る。その結果、ブロック鍵データも分割前のブロック鍵
データＢＫ＿１と同じにでき、トラックデータファイル
（２）内のサウンドユニットＳＵを新たなブロック鍵デ
ータを用いて再度暗号化する必要がない。また、同様
に、分割後のトラックデータファイル（１）のパーツ鍵
データＰＫ＿１’も、ブロック鍵データＢＫ＿１を変え
ないように、コンテンツ鍵データＣＫ＿１’に応じた決
定される。その結果、分割後のトラックデータファイル
（１）内のサウンドユニットＳＵを新たなブロック鍵デ
ータを用いて再度暗号化する必要もない。そのため、ト
ラックデータファイルの分割編集に伴い演算量が大幅に
増加することを回避できる。なお、ここでは、図４のト
ラックデータファイルについてのみ述べたが、編集モジ
ュール４４は、図４の再生管理ファイル１００について
も同様に適宜更新を行う。

【０１６９】次に、トラックデータファイルの結合編集
処理について説明する。図３０は、携帯用プレーヤ４の
編集モジュール４４によるトラックデータファイルの結
合編集処理を説明するための図である。図３０に示すよ
うに、編集モジュール４４は、例えば、図３０Ａに示す
トラックデータファイル（１）と、図３０Ｂに示すトラ
ックデータファイル（２）とを結合して、図３０Ｃに示
すトラックデータファイル（３）を生成する。

【０１７０】当該結合により、結合前のトラックデータ
ファイル（１）からなるパーツ（１）と、結合前のトラ
ックデータファイル（２）からなるパーツ（２）とを含
む新たなトラックデータファイル（３）が生成される。
また、トラックデータファイル（３）のコンテンツ鍵デ
ータとして新たなコンテンツ鍵データＣＫ＿３が生成さ
れ、パーツ（１）のパーツ鍵データＰＫ＿３＿１および
パーツ（２）のパーツ鍵データＰＫ＿３＿２が後述する
ようにして新たに生成される。また、当該トラックデー
タファイル（３）のＴＲＫＩＮＦおよびＰＲＴＩＮＦ
に、新たに生成された鍵データが後述するように設定さ
れる。

【０１７１】また、パーツ（１）の図６に示すＰＲＴＳ
ＩＺＥが示す開始クラスタおよび終了クラスタとして、
結合前のトラックデータファイル（１）のクラスタＣＬ
（０）およびＣＬ（４）がそれぞれ設定される。また、
パーツ（２）のＰＲＴＳＩＺＥが示す開始クラスタおよ
び終了クラスタとして、結合前のトラックデータファイ
ル（２）のクラスタＣＬ（０）およびＣＬ（５）がそれ
ぞれ設定される。

【０１７２】図３１は、携帯用プレーヤ４の編集モジュ
ール４４において、新たに生成したトラックデータファ
イル（３）のパーツ（１）および（２）のパーツ鍵デー
タを生成する処理を説明するための図である。なお、本
実施形態では、結合の対象となるトラックデータファイ
ル（１）がコンテンツ鍵データＣＫ＿１、パーツ鍵デー
タＰＫ＿１およびブロック鍵データＢＫ＿１を用いてお
り、トラックデータファイル（２）がコンテンツ鍵デー
タＣＫ＿２、パーツ鍵データＰＫ＿２およびブロック鍵
データＢＫ＿２を用いてる場合を例示して説明する。

【０１７３】ここで、トラックデータファイル（３）は
新たなコンテンツ鍵データＣＫ＿３を得るが、パーツ
（１）および（２）のパーツ鍵データを以下に示すよう
に算出することで、各ブロックのブロック鍵データＢＫ
＿１およびＢＫ＿２を結合前と同じにできる。

【０１７４】ステップＳ１００：編集モジュール４４
は、トラックデータファイルの結合指示を入力したか否
かを判断し、入力したと判断した場合にはステップＳ１
０１の処理を実行し、入力していないと判断した場合に
はステップＳ１００の処理を繰り返す。

【０１７５】ステップＳ１０１：編集モジュール４４
は、乱数発生ユニット６０に乱数を発生させ、当該乱数
に応じたコンテンツ鍵データＣＫ＿３を新たに生成す
る。

【０１７６】ステップＳ１０２：携帯用記憶装置３の暗
号化／復号ユニット５４において、ステップＳ１０１で
生成したコンテンツ鍵データＣＫ＿３を、記憶ユニット
５１に記憶されている記憶用鍵データＳＫm を用いて暗
号化する。

【０１７７】ステップＳ１０３：編集モジュール４４
は、当該暗号化されたコンテンツ鍵データＣＫ＿３を当
該トラックデータファイルのＴＲＫＩＮＦに書き込む。

【０１７８】ステップＳ１０４：編集モジュール４４
は、トラックデータファイル（３）のパーツ（１）のパ
ーツ鍵データＰＫ＿３＿１を下記式（１６）に基づいて
生成する。

【０１７９】

【数１６】ＰＫ＿３＿１＝ＣＫ＿１ＸＯＲＰＫ＿１ＸＯＲＣＫ＿３・・・（１６）これにより、前記式（１１）に基づいて生成されるパー
ツ（１）のテンポラリ鍵データを結合前のトラックデー
タファイル（１）のテンポラリ鍵データと同じにでき、
その結果、前記式（１２）に基づいて生成されるパーツ
（１）のブロック鍵データも結合前のトラックデータフ
ァイル（１）のブロック鍵データＢＫ＿１と同じにでき
る。そのため、パーツ（１）のサウンドユニットＳＵを
新たなブロック鍵データを用いて再度暗号化する必要が
ない。

【０１８０】ステップＳ１０５：編集モジュール４４
は、トラックデータファイル（３）のパーツ（２）のパ
ーツ鍵データＰＫ＿３＿２を下記式（１７）に基づいて
生成する。

【０１８１】

【数１７】ＰＫ＿３＿２＝ＣＫ＿２ＸＯＲＰＫ＿２ＸＯＲＣＫ＿３・・・（１７）これにより、前記式（１１）に基づいて生成されるパー
ツ（２）のテンポラリ鍵データを結合前のトラックデー
タファイル（２）のテンポラリ鍵データと同じにでき、
その結果、前記式（１２）に基づいて生成されるパーツ
（２）のブロック鍵データも結合前のトラックデータフ
ァイル（２）のブロック鍵データＢＫ＿２と同じにでき
る。そのため、パーツ（２）のサウンドユニットＳＵを
新たなブロック鍵データを用いて再度暗号化する必要が
ない。

【０１８２】ステップＳ１０６：編集モジュール４４
は、ステップＳ１０４で生成したパーツ鍵データＰＫ＿
３＿１をトラックデータファイル（３）のパーツ（１）
のＰＲＴＩＮＦにそのまま書き込む。

【０１８３】ステップＳ１０７：編集モジュール４４
は、ステップＳ１０５で生成したパーツ鍵データＰＫ＿
３＿２をトラックデータファイル（３）のパーツ（２）
のＰＲＴＩＮＦにそのまま書き込む。

【０１８４】このように、オーディオシステム１では、
結合して新たに生成したトラックデータファイル（３）
のコンテンツ鍵データとして、新たなコンテンツ鍵デー
タＣＫ＿３を用いた場合でも、上記式（１６）および
（１７）に基づいてパーツ鍵データＰＫ＿３＿１および
ＰＫ＿３＿２を生成することで、各パーツのテンポラリ
鍵データを結合前と同じにできる。その結果、各パーツ
のブロック鍵データも結合前のブロック鍵データＢＫ＿
１およびＢＫ＿２とそれぞれ同じにでき、パーツ（１）
および（２）内のサウンドユニットＳＵを新たなブロッ
ク鍵データを用いて再度暗号化する必要がない。そのた
め、トラックデータファイルの結合編集に伴い演算量が
大幅に増加することを回避できる。なお、ここでは、図
４のトラックデータファイルについてのみ述べたが、編
集モジュール４４は、図４の再生管理ファイルについて
も同様に適宜更新を行う。

【０１８５】この発明は、上述した実施形態等に限定さ
れるものでは無く、この発明の要旨を逸脱しない範囲内
で様々な変形や応用が可能である。例えば、上述した実
施形態では、ＡＴＲＡＣ３方式の圧縮の単位であるサウ
ンドユニットＳＵのバイト数（１６０バイト）が、ＣＢ
Ｃモードの暗号化の単位である暗号化ブロックのバイト
数（８バイト）の整数倍になる場合を例示したが、この
発明は、例えば、整数倍にならない場合には、サウンド
ユニットＳＵにデータ長調整用のデータであるパディン
グ(padding) を挿入して調整するようにしてもよい。

【０１８６】また、上述した実施形態では、携帯用記憶
装置３と携帯用プレーヤ４との間で相互認証処理を行う
場合に、図２２に示すように、先ず始めに携帯用記憶装
置３で生成した乱数Ｒ_msを携帯用プレーヤ４に出力する
場合を例示したが、先ず始めに携帯用プレーヤ４で生成
した乱数を携帯用記憶装置３に出力するようにしてもよ
い。

【０１８７】また、上述した実施形態では、図２１に示
すように、記憶ユニット５１および６１に３２組の認証
鍵データおよびマスター鍵データを記憶した場合を例示
したが、これらの組の数は２以上であれば任意である。

【０１８８】また、上述した実施形態では、図２１に示
すように、携帯用プレーヤ４において、マスター鍵デー
タＭＫ₀〜ＭＫ₃₁から認証鍵データＩＫ₀〜ＩＫ₃₁を生
成する場合を例示したが、携帯用プレーヤ４に、携帯用
記憶装置３と同じように、認証鍵データＩＫ₀〜ＩＫ₃₁
を記憶し、乱数Ｒ_jに応じた認証鍵データを選択するよ
うにしてもよい。

【０１８９】また、上述した実施形態では、図２１に示
すように、携帯用記憶装置３および携帯用プレーヤ４に
おいて、携帯用プレーヤ４で生成した乱数Ｒ_jを用い
て、認証鍵データＩＫ_jおよびマスタ−鍵データＭＫ_j
を選択する場合を例示したが、携帯用記憶装置３で生成
した乱数を用いてもよいし、携帯用記憶装置３および携
帯用プレーヤ４の双方で発生した乱数を用いてもよい。

【０１９０】また、上述した実施形態では、図２１に示
すように、携帯用記憶装置３および携帯用プレーヤ４に
おいて乱数Ｒ_jに基づいて認証鍵データＩＫ_jおよびマ
スタ−鍵データＭＫ_jを選択する場合を例示したが、こ
の発明は、例えば、携帯用記憶装置３および携帯用プレ
ーヤ４に外部から５ビットの鍵選択指示データを入力
し、当該鍵選択指示データで指示される相互に対応する
認証鍵データＩＫ_jおよびマスタ−鍵データＭＫ_jを、
携帯用記憶装置３および携帯用プレーヤ４で選択しても
よい。

【０１９１】また、上述した実施形態では、トラックデ
ータとしてオーディオデータを含むデータを例示した
が、この発明は、その他、動画像データ、静止画像デー
タ、文書データおよびプログラムデータなどを含むトラ
ックデータをフラッシュメモリ３４に記憶する場合にも
適用できる。

【０１９２】

【発明の効果】以上説明したように、この発明のデータ
処理システムおよびその方法によれば、記憶手段に記憶
された暗号化されたデータを、所定の処理ブロックを単
位として効率的に処理できる。

【図面の簡単な説明】

【図１】この発明の一実施形態のオーディオシステムの
システム構成を示すブロック図である。

【図２】携帯用記憶装置および携帯用プレーヤの内部構
成を示すブロック図である。

【図３】携帯用記憶装置内の記憶ユニットに記憶されて
いるデータを説明するための略線図である。

【図４】携帯用記憶装置のフラッシュメモリに記憶され
るデータを説明するための略線図である。

【図５】再生管理ファイルのデータ構成を概略的に示す
略線図である。

【図６】データファイルのデータ構成を概略的に示す略
線図である。

【図７】再生管理ファイルのデータ構成をより詳細に示
す略線図である。

【図８】再生管理ファイルの各部分と付加情報領域の構
成を示す略線図である。

【図９】携帯用プレーヤの記憶ユニットに記憶されてい
るデータを説明するための略線図である。

【図１０】データファイルのデータ構成をより詳細に示
す略線図である。

【図１１】データファイルの属性ヘッダの一部を示す略
線図である。

【図１２】データファイルの属性ヘッダの一部を示す略
線図である。

【図１３】録音モードの種類と、各録音モードにおける
録音時間等を示す略線図である。

【図１４】コピー制御情報を説明するための略線図であ
る。

【図１５】データファイルの属性ヘッダの一部を示す略
線図である。

【図１６】データファイルの各データブロックのヘッダ
を示す略線図である。

【図１７】携帯用プレーヤの記憶ユニットに記憶されて
いるデータを説明するための略線図である。

【図１８】携帯用プレーヤの暗号化／復号ユニットのＣ
ＢＣモードにおける暗号化処理を説明するための略線図
である。

【図１９】携帯用プレーヤの暗号化／復号ユニットのＣ
ＢＣモードにおける復号処理を説明するための略線図で
ある。

【図２０】携帯用プレーヤから携帯用記憶装置への書き
込み動作を説明するためのフローチャートである。

【図２１】相互認証ユニットによる認証鍵データＩＫ_j
の選択処理を説明するための略線図である。

【図２２】携帯用記憶装置と携帯用プレーヤとの間の相
互認証処理を説明するためのフローチャートである。

【図２３】セッション鍵データＳｅｋの生成処理を説明
するための略線図である。

【図２４】携帯用プレーヤから携帯用記憶装置へのオー
ディオデータの書き込み処理を説明するためのフローチ
ャートである。

【図２５】携帯用記憶装置から携帯用プレーヤへの読み
出し動作を説明するためのフローチャートである。

【図２６】携帯用記憶装置から携帯用プレーヤへのオー
ディオデータの読み出し処理を説明するためのフローチ
ャートである。

【図２７】携帯用プレーヤの編集モジュールによるトラ
ックデータファイルの分割編集処理を説明するための略
線図である。

【図２８】分割編集処理を行った後のクラスタ内のデー
タを説明するための略線図である。

【図２９】携帯用プレーヤの編集モジュールにおいて、
分割編集時に、新たなトラックデータファイルのコンテ
ンツ鍵データおよびパーツ鍵データを生成する方法を説
明するためのフローチャートである。

【図３０】携帯用プレーヤの編集モジュールによるトラ
ックデータファイルの結合編集処理を説明するための略
線図である。

【図３１】携帯用プレーヤ４の編集モジュールにおい
て、新たに生成したトラックデータファイル（３）のパ
ーツ（１）および（２）のパーツ鍵データを生成する処
理を説明するための略線図である。

【符号の説明】

１・・・オーディオシステム、２・・・コンピュータ、
３・・・携帯用記憶装置、４・・・携帯用プレーヤ、５
・・・ネットワーク、３３，４３・・・制御モジュー
ル、５０，６０・・・乱数発生ユニット、５１，６１・
・・記憶ユニット、５２，６２・・・鍵生成／演算ユニ
ット、５３，６３・・・相互認証ユニット、５４，７４
・・・暗号化／復号ユニット、５５，６５・・・制御ユ
ニット、３４・・・フラッシュメモリ、４４・・・編集
モジュール、４５・・・圧縮／伸長モジュール、４６・
・・スピーカ

─────────────────────────────────────────────────────

【手続補正書】

【提出日】平成１２年４月４日（２０００．４．４）

【手続補正１】

【補正対象書類名】明細書

【補正対象項目名】００２０

【補正方法】変更

【補正内容】

【００２０】図５は、再生管理ファイルの構成を示し、
図６が一つ（１曲）のトラックデータファイル（以下に
おいてＡＴＲＡＣ３データファイルの用語がさすものも
トラックデータファイルと同義である）の構成を示す。
再生管理ファイルは、１６ＫＢ固定長のファイルであ
る。ＡＴＲＡＣ３データファイルは、曲単位でもって、
先頭の属性ヘッダと、それに続く実際の暗号化された音
楽データとからなる。属性ヘッダも１６ＫＢ固定長とさ
れ、再生管理ファイルと類似した構成を有する。

【手続補正２】

【補正対象書類名】明細書

【補正対象項目名】００５４

【補正方法】変更

【補正内容】

【００５４】ＬＴ（１バイト）意味：再生制限フラグ（ビット７およびビット６）とセ
キュリティバージョン（ビット５〜ビット０）機能：このトラックに関して制限事項があることを表す値：ビット７：０＝制限なし１＝制限有りビット６：０＝期限内１＝期限切れビット５〜ビット０：セキュリティバージョン０（０以
外であれば再生禁止とする）ＦＮｏ（２バイト）意味：ファイル番号機能：最初に記録された時のトラック番号、且つこの値
は、メモリカード内の隠し領域に記録されたＭＡＣ計算
用の値の位置を特定する値：１から０ｘ１９０（４００）ＭＧ（Ｄ）ＳＥＲＩＡＬ−ｎｎｎ（１６バイト）意味：記録機器のセキュリティブロック（制御モジュ−
ル４３）のシリアル番号機能：記録機器ごとに全て異なる固有の値値：０から0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF ＣＯＮＮＵＭ（４バイト）意味：コンテンツ累積番号機能：曲毎に累積されていく固有の値で記録機器のセキ
ュリティブロックによって管理される。２の３２乗、４
２億曲分用意されており、記録した曲の識別に使用する値：０から０ｘＦＦＦＦＦＦＦＦ。

Claims

【特許請求の範囲】

【請求項１】所定のデータ長の暗号化ブロックを単位
としてデータを暗号化する暗号化手段と、上記暗号化ブロックの整数倍のデータ長を持つ処理ブロ
ックを単位としてデータに所定の処理を行う処理手段
と、上記暗号化したデータを記憶する記憶手段と、同じ上記暗号化ブロック内に位置するデータが同じ上記
処理ブロック内に位置するように、上記暗号化したデー
タを上記記憶手段に書き込み、上記処理ブロックを単位
として上記データを上記記憶手段から読み出す制御手段
とを有するデータ処理装置。
【請求項２】請求項１において、上記制御手段は、上記処理ブロックにデータ長調整用の
データを入れて、上記処理ブロックのデータ長が上記暗
号化ブロックのデータ長の整数倍になるように調整する
データ処理装置。
【請求項３】請求項１において、上記暗号化手段は、上記暗号化を行おうとする上記暗号
化ブロックと当該暗号化ブロックの直前の暗号化ブロッ
クを暗号化して得た暗号文とを用いて演算を行い、当該
演算の結果を暗号化するデータ処理装置。
【請求項４】請求項１において、上記制御手段は、単数または複数の上記処理ブロック
と、当該単数または複数の上記処理ブロックのうち最初
に暗号化された上記処理ブロック内で最初に暗号化され
た上記暗号化ブロックを暗号化する際に用いられた初期
値とを含むクラスタを用いて、上記記憶手段に記憶され
た上記暗号化されたデータを管理するデータ処理装置。
【請求項５】請求項１において、上記制御手段は、単数または複数の上記処理ブロックを
暗号化された順で上記記憶手段の連続したアドレスに記
憶し、さらに、上記処理ブロック内の単数または複数の
暗号化ブロックを暗号化された順で上記記憶手段の連続
したアドレスに記憶し、上記クラスタ内で最初に暗号化
された処理ブロック内でさらに最初に暗号化された暗号
化ブロックが記憶された上記記憶手段のアドレスの直前
のアドレスに上記初期値を記憶するデータ処理装置。
【請求項６】請求項１において、上記制御手段は、上記処理ブロック単位で読み出した上
記データを上記処理手段に出力するデータ処理装置。
【請求項７】請求項１において、上記データは、圧縮されており、上記処理手段は、上記記憶手段から読み出された上記デ
ータを、上記処理ブロックを単位として伸長するデータ
処理装置。
【請求項８】記憶装置とデータ処理装置との間で相互
認証を行いながらデータの入出力を行うデータ処理シス
テムにおいて、上記記憶装置は、上記データ処理装置との間で相互認証処理を行う第１の
相互認証処理手段と、上記データを記憶する記憶手段と、上記相互認証処理によって上記データ処理装置が正当な
相手であると認めたときに、上記データ処理装置と上記
記憶手段との間でデータの入出力を行わせる第１の制御
手段とを有し、上記データ処理装置は、上記記憶装置との間で相互認証処理を行う第２の相互認
証処理手段と、所定のデータ長の暗号化ブロックを単位としてデータを
暗号化する暗号化手段と、上記暗号化ブロックの整数倍のデータ長を持つ処理ブロ
ックを単位としてデータに所定の処理を行う処理手段
と、上記相互認証処理によって、上記記憶装置が正当な相手
であると認めたときに、書き込み処理および読み出し処
理の少なくとも一方を行い、上記書き込み処理におい
て、同じ上記暗号化ブロック内に位置するデータが同じ
上記処理ブロック内に位置するように、上記暗号化した
データを上記記憶手段に書き込み、上記読み出し処理に
おいて、上記処理ブロックを単位として上記データを上
記記憶手段から読み出す制御手段とを有するデータ処理
システム。
【請求項９】請求項８において、上記第２の制御手段は、上記処理ブロックにデータ長調
整用のデータを入れて、上記処理ブロックのデータ長が
上記暗号化ブロックのデータ長の整数倍になるように調
整するデータ処理システム。
【請求項１０】請求項８において、上記暗号化手段は、上記暗号化を行おうとする上記暗号
化ブロックと当該暗号化ブロックの直前の暗号化ブロッ
クを暗号化して得た暗号文とを用いて演算を行い、当該
演算の結果を暗号化するデータ処理システム。
【請求項１１】請求項８において、上記第２の制御手段は、単数または複数の上記処理ブロ
ックと、当該単数または複数の上記処理ブロックのうち
最初に暗号化された上記処理ブロック内で最初に暗号化
された上記暗号化ブロックを暗号化する際に用いられた
初期値とを含むクラスタを用いて、上記記憶手段に記憶
された上記暗号化されたデータを管理するデータ処理シ
ステム。
【請求項１２】請求項８において、上記第２の制御手段は、単数または複数の上記処理ブロ
ックを暗号化された順で上記記憶手段の連続したアドレ
スに記憶し、さらに、上記処理ブロック内の単数または
複数の暗号化ブロックを暗号化された順で上記記憶手段
の連続したアドレスに記憶し、上記クラスタ内で最初に
暗号化された処理ブロック内でさらに最初に暗号化され
た暗号化ブロックが記憶された上記記憶手段のアドレス
の直前のアドレスに上記初期値を記憶するデータ処理シ
ステム。
【請求項１３】所定のデータ長の暗号化ブロックを単
位としてデータを暗号化し、上記暗号化ブロックの整数倍のデータ長を持つ処理ブロ
ックを単位としてデータに所定の処理を行い、同じ上記暗号化ブロック内に位置するデータが同じ上記
処理ブロック内に位置するように、上記暗号化したデー
タを上記記憶手段に書き込み、上記処理ブロックを単位
として上記データを上記記憶手段から読み出すデータ処
理方法。
【請求項１４】請求項１３において、上記処理ブロックにデータ長調整用のデータを入れて、
上記処理ブロックのデータ長が上記暗号化ブロックのデ
ータ長の整数倍になるように調整するデータ処理方法。
【請求項１５】請求項１３において、上記暗号化を行おうとする上記暗号化ブロックと当該暗
号化ブロックの直前の暗号化ブロックを暗号化して得た
暗号文とを用いて演算を行い、当該演算の結果を暗号化
して上記暗号化を行うデータ処理方法。
【請求項１６】請求項１３において、単数または複数の上記処理ブロックと、当該単数または
複数の上記処理ブロックのうち最初に暗号化された上記
処理ブロック内で最初に暗号化された上記暗号化ブロッ
クを暗号化する際に用いられた初期値とを含むクラスタ
を用いて、記憶された上記暗号化されたデータを管理す
るデータ処理方法。
【請求項１７】請求項１３において、単数または複数の上記処理ブロックを暗号化された順で
記憶手段の連続したアドレスに記憶し、さらに、上記処
理ブロック内の単数または複数の暗号化ブロックを暗号
化された順で上記記憶手段の連続したアドレスに記憶
し、上記クラスタ内で最初に暗号化された処理ブロック
内でさらに最初に暗号化された暗号化ブロックが記憶さ
れた上記記憶手段のアドレスの直前のアドレスに上記初
期値を記憶するデータ処理方法。
【請求項１８】請求項１３において、読み出された上記データを、上記処理ブロックを単位と
して伸長するデータ処理方法。