JP4219681B2 - 不揮発性メモリカード、コンパクトディスクまたはその他のメディアから記録されたオーディオ、ビデオまたはその他のコンテンツを再生するためのシステム、方法およびデバイス - Google Patents

Description

【０００１】
（関連出願の相互参照）
本願は、“不揮発性メモリカード、コンパクトディスクまたはその他のメディアから記録されたオーディオ、ビデオまたはその他のコンテンツを再生するためのセキュリティが保護されたソフトウェアシステム”という２０００年１２月７日出願の米国仮特許出願第６０／２５１，７３１号に関連し、該仮特許出願を優先権主張の基礎とするものであり、さらに、本願は、本願と同日付で、本願と同じ発明者を有する米国で同時出願された、“不揮発性メモリカード、コンパクトディスクまたはその他のメディアから記録されたオーディオ、ビデオまたはその他のコンテンツを再生するためのシステム、方法および装置（代理人整理番号：Ｍ−９９１３ＵＳ）という米国特許出願に関連する。
【０００２】
３７ＣＦＲ１．５２に従って、以下のファイルを含む添付書類としてコンパクトディスクでソースコードを提出する。上記ファイルの各々は本願において上記参照によりその全体が援用されている。

【０００３】
【発明の属する技術分野】
本発明は、一般にまた具体的には、メモリカード、コンパクトディスクまたはその他のメディアから得られるデジタル形式のオーディオ、ビデオまたはその他のコンテンツのセキュリティが保護された再生に関する。
【０００４】
【従来の技術】
別の通信システムによって、あるいは、小売店のキオスクを通じてインターネットによって著作権のある音楽の電子配信を実施する可能性には音楽の不法コピーに関する懸念による限界がある。これは他のオーディオ・コンテンツ並びにビデオコンテンツについても言えることである。一般にコンテンツは暗号化された形で最終顧客へ提供され、顧客は、パーソナル・コンピュータのメモリ、携帯用再生装置のメモリ、書込み可能なコンパクトディスク（ＣＤ）または不揮発性メモリカードのような何らかの記憶メディア上へ暗号化されたコンテンツファイルを記録する。コンテンツのプロバイダは、コンテンツの不法コピーが行われる可能性が取り除かれることを望んではいるが、不法に行われるコピーの量を最少化するステップをとることで満足せざるを得ない状況がある。これには記録メディア上のコンテンツに保護を与えることが含まれる。ここでは、具体例として、不揮発性メモリカード上に記憶されたコンテンツの保護について説明するが、この同じコンテンツ保護技法はコンパクトディスクや他の記録可能メディアにも適用可能である。
【０００５】
コンテンツデータの記憶メディアとして利用に適したいくつかの市販の不揮発性メモリカードが存在する。１つの不揮発性メモリカードとしてコンパクトフラッシュ（ＣＦ）カードがあり、別の不揮発性メモリカードとしてマルチメディアカード（ＭＭＣ）があり、さらに別の不揮発性メモリカードとしてＭＭＣカードと密接に関連するセキュリティの保護されたデジタル（ＳＤ）メモリカードがある。これら３つの不揮発性メモリカードのすべておよびその他の不揮発性メモリカードは、本願の譲受人であるカリフォルニア州サニーベールのサンディスク
コーポレイションから発売されている様々な容量の記憶デバイスで利用可能である。物理的および電気的仕様は“マルチメディアカードシステム仕様”に示されている。この仕様は、カリフォルニア州クパティーノのマルチメディアカード協会（“ＭＭＣＡ”）により時折更新され、公開されている。当該仕様のバージョン２．１１と２．２（１９９９年６月および２０００年１月版）はそれぞれ明白に本願明細書に参照により援用されている。ＭＭＣ製品については“マルチメディアカード製品マニュアル”（“改訂２版、２０００年４月付、サンディスク
コーポレイションにより発行）にも記載があり、このマニュアルは明白に本願明細書に参照により援用されている。ＭＭＣ製品についての電気的動作の或る局面については、Thomas N. ToombsとMicky Holtzmanによる同時継続特許出願第０９／１８５，６４９号および第０９／１８６，０６４号にも記載がある。上記特許出願は双方とも１９９８年１１月４日に出願され、サンディスク コーポレイションに譲渡されたものである。カードの物理的構造とその製造方法については、サンディスク コーポレイションに譲渡された米国特許第６，０４０，６２２号に記載がある。これらの特許出願と特許の双方も明白に本願明細書に参照により援用されている。
【０００６】
上記新しいＳＤカードはＭＭＣカードに類似したカードであり、平面図では同じ形をしている。これらのカード間の主要な相違点として、ＳＤカードがカードとホスト間のさらに高速なデータ転送を可能にするために追加のデータ用接点を備えているという点が挙げられる。ＳＤカードのその他の接点はＭＭＣカードの接点と同じであり、ＳＤカードを受け入れるように設計されているソケットはＭＭＣカードも受け入れるようにつくられている。ＳＤカードとの電気的インタフェースは、さらに、上記で引用したＭＭＣ製品の仕様書のバージョン２．１１に記載されているＭＭＣ製品と逆方向の互換性を有するように大部分がつくられており、双方のタイプのカードを適合させるように、ホストの動作に対応する２、３の変更を行う必要があるようにつくられている。ＳＤカードの電気的インタフェースおよびその動作については、２０００年８月１７日に出願の同時継続特許出願第０９／６４１，０２３号に記載がある。上記特許出願は本明細書にその全体が参照により援用されている。
【０００７】
（発明の開示）
暗号化されたコンテンツはアクセスが困難であり、暗号化されたコンテンツを含むメモリカードまたはコンパクトディスクは、暗号化コンテンツと未暗号化コンテンツにアクセスするための専用コマンドとルーチンとを必要とする固有の構造を各々有している。本発明のソフトウェアは簡単なソリューションであり、いずれの他社製部品組込み製品製造販売企業（ＯＥＭ）もインストールが可能で、無数の異なるタイプのマイクロプロセッサを備えた無数の異なるタイプのデバイス上で実行可能なソリューションである。これらのデバイスはパーソナル・コンピュータから携帯用デバイス、カーステレオまでをカバーし、これらのデバイスには、暗号化が可能なコンテンツへのアクセスを望む任意のデバイスが含まれる。上記携帯用デバイスとしては、携帯用オーディオ・プレイヤや携帯電話や携帯用情報機器あるいは、一般に、マイクロプロセッサにより制御される任意の携帯用デバイスを挙げることができる。記憶メディアとしてはフラッシュメモリまたは任意のタイプの記録可能ディスクを挙げることができる。デバイスとしては、少量または大量のメモリを持つ単純なまたは強力なマイクロプロセッサを備えたデバイスを挙げることができる。上記ソフトウェアは、暗号化を行うことを目的として小さなバッファのみを利用し、必要とするものであり、限られた処理パワーとメモリ環境においても効率的に機能するように設計されている。このソフトウェアは、任意のタイプの汎用マイクロプロセッサ、ＤＳＰやＡＳＩＣなどのような特定目的のマイクロプロセッサにより実行可能である。さらに、暗号化と解読（セキュリティ）エンジンのようなソフトウェアの計算要求部はＤＳＰによる実行が可能であり、一方ソフトウェアの別の部分は、別のマイクロプロセッサまたはＡＳＩＣにより実行が可能である。
【０００８】
上記ソフトウェアには、それぞれのタイプのファイルの各々に対するコマンドを受け取るためのオーディオ、ビデオおよび画像用インタフェースが含まれる。これらのインタフェースは、管理用再生リストおよびその他の都合のよい特徴を含む再生と記録の編成が可能である。したがって、デバイスは、その如何に関らず、インタフェースに対してコマンドを出すだけで十分であり、次いで、セキュリティ保護メディアからのデータの読出し処理または書込み処理、並びに、任意の周知のオーディオ、ビデオまたは画像ファイルフォーマットからのデータの復号化処理と解凍処理とがソフトウェアによりオーディオ、ビデオまたは画像エンジン内で行われる。
【０００９】
暗号化と解読は、アクセスが非常に困難な分離されたモジュール内で行われ、したがって該モジュールは、メディアまたはデバイスからファイルをコピーするために暗号化キーにアクセスしようとする、アクセス権限が与えられていない人からのいかなる試みからも分離されている。コンテンツは小部分で解読され、ダイナミックキーの作成および削除方法により解読対象キーの露出部分が最少化される。
【００１０】
【発明の実施の形態】
図１を参照して、コンテンツ保護が音楽のようなオーディオ・コンテンツに対して適用される例示システムについて説明する。ホスト・コンピュータデバイス１１は、図に示すようなパーソナル・コンピュータ（ＰＣ）（音楽やその他のコンテンツまたはその類似物を配信する小売店に置かれたキオスク）であってもよい。この例では、ＳＤメモリカード１３を用いて音楽が記憶される。カード１３は、このケースでは、携帯用デバイス（ＰＤ）１５である利用デバイスの中へ挿入することができる。上記携帯用デバイス（ＰＤ）１５は電池で作動し、カード１３に記録された音楽やその他のオーディオ・コンテンツの再生が個人のイヤホンを通じて行われる。カード１３がデバイス１５の中へ挿入されると、コンピュータ用のユニバーサル・シリアル・バス（ＵＳＢ）接続１７などを介してデバイス１５をホスト１１と接続することにより、そのカードに音楽を記憶することができる。或いは、デバイス１５にカード１３上へのコンテンツの記録能力が設けられていなければ、あるいは、デバイス１５が違った形で望ましいデバイスであれば、ＵＳＢ接続２１を介してコンピュータをカード書込み／読出し装置１９と接続してもよく、カードに音楽を記録するために、カード１３のコンピュータの中への挿入も可能である。次いで、書込み／読出し装置１９からカード１３を取り外し、このカードを携帯用デバイス１５の中へ挿入して、カードに記録されているオーディオ・コンテンツの再生が行われる。４ＣエンティティとＳＤグループのセキュリティおよび認証プロトコルに従ってコンテンツデータのカード１３への書込みおよびカード１３からのコンテンツデータの読出しに必要なソフトウェアがホスト１１に含まれている場合、ホスト１１は使用許諾を受けた対応モジュール（ＬＣＭ）と呼ばれる。
【００１１】
例示の携帯利用デバイス１５内の電子システムが図２に例示されている。好ましくは何らかの不揮発性フラッシュメモリ２５Ａを備えた計算用ユニット（ＭＣＵ）２５と、好ましくは高速ランダムアクセスメモリ（ＲＡＭ）であることが望ましいシステムメモリ２７と、メモリカード１３との接続用インタフェース回路２９とがバス２３を介して作動可能に一体に接続される。ＵＳＢ接続１７もオプションとしてＭＣＵ２５に設けられる。圧縮形式および／または暗号化形式で記憶された、オーディオまたはビデオデータのようなコンテンツデータの解凍用および／または解読に必要な場合、デジタル信号プロセッサ（ＤＳＰ）３１も含まれる。ＤＳＰ３１は、プロセッサの一部として設けられているＤＳＰ自身のＲＡＭメモリ３１Ａを有する。ＤＳＰ３１を設けてもよいし、設けなくてもよい。さらに、ＤＳＰプロセッサが設けられていれば、ＤＳＰプロセッサによるＭＣＵ２５の機能の実行が可能となり、したがって、ＭＣＵ２５を省くことが可能となる。リードオンリメモリ（ＲＯＭ）３２は本発明のソフトウェアの一部またはすべてを記憶することができる。ＲＯＭ３２内のソフトウェア命令とデータを実行したり、ＲＯＭ３２からこの命令とデータとを直接読出したり、デバイスの回路構成内のいずれかのＲＡＭメモリの中へこれらをまずコピーしたりすることができる。
【００１２】
記録可能メディアのコンテンツの保護仕様がインテル、ＩＢＭ、松下電気産業株式会社、東芝コーポレーション（４Ｃエンティティ）により共同で確定されている。特に本願と関連があるのは４Ｃエンティティの以下の３つの文献であり、これらの文献は明白に本願明細書に参照により援用されている。これらは、“記録可能メディア仕様のためのコンテンツ保護、導入、および共通暗号要素”（改訂版０．９４、２０００年１０月）、“記録可能メディア仕様書、ＳＤメモリカードブックのためのコンテンツ保護”（改訂版０．９５、２００１年５月）、および、“Ｃ２ブロック暗号仕様書”（改訂版０．９、２０００年１月１１日）と“記録可能メディア仕様書、ＤＶＤブックのためのコンテンツ保護”（改訂版０．９５、２００１年５月）である。ＳＤメモリカードに関するこれらの４Ｃエンティティ仕様を実現するための追加の詳細な仕様が松下電気産業株式会社（ＭＥＩ）、サンディスク コーポレイションおよび東芝コーポレーション（ＳＤグループ）により確定されている。
【００１３】
図３Ａを参照すると、メモリカード１３は４つの別個の層を有するものと考えることができる。このような層は別のタイプのセキュリティ保護メディアの中に存在するものであってもよい。
【００１４】
データの最も基本的レベルで、データは、メモリカード１３の物理層１３ｄのクラスタ内に構成されるメモリセルに記憶される。このデータは、著作権のあるもの、あるいは、暗号化に値するものであれば暗号化すなわちセキュリティの保護が行われる。セキュリティが保護されたコンテンツの暗号化と解読に用いるキーも暗号化され、物理層のセキュリティが保護された領域に記憶される。
【００１５】
本発明のソフトウェアはデバイス内で機能し、暗号化されたデータとキーとを含むメモリセルにアクセスするための非常に特殊な命令を製造業者（ＯＥＭ）がプログラムする必要なく、デバイスによる暗号化情報の記憶と検索とが可能となる。上記ソフトウェアには、デバイスへ暗号化データを送信し、デバイス内でデータを解読し、デバイスからの要求時にオーディオ、ビデオおよび画像ファイルを解凍し、このファイルの再生を行う方法が含まれる。要するに、デバイスは、“トラックを再生せよ”のようなコマンドを送信するだけで十分である。上記ソフトウェアはこのコマンドを受け入れ、メモリセルに記憶された暗号化データを検索し、暗号化キーを検索し、データの編成と解読とを行い、データの解凍とフォーマットとを行って歌を再生する。
【００１６】
論理層１３ｃには、物理層１３ｄのメモリセルとクラスタのための編成構造が含まれる。２つの層１３ｃと１３ｄにはカード１３のメモリが含まれ、これらの層によりカード１３のメモリが論理的に構造化される。カード１３はセキュリティが保護されたカードであるため、セキュリティ層１３ｂにより、下層に収納されているセキュリティが保護されたデータへのアクセスの制御と制限とが行われる。
【００１７】
アプリケーション層１３ａは、カードに記憶されたコンテンツにアクセスするデバイスと交信するメモリカード１３の一部である。アプリケーション層１３ａは、デバイスインタフェースまたは接点３９を介して上記交信を行う。メモリカード１３には、好ましくは、カードのすべての層１３ａ−ｄの制御と共に、カードの処理とアプリケーション層１３の機能とを管理するコントローラが含まれることが望ましい。
【００１８】
図３Ａの層１３ｃと１３ｄに対応する上記仕様に準拠する記録メディア（ＳＤカード１３）の物理構造と論理構造とが図３Ｂに例示されている。このカードにはメモリセル３３のアレイとメモリ・コントローラ３５とが含まれている。ユーザデータとコマンドと状態信号との交信が、コントローラ３５とメモリアレイ３３との間で回路３７を介して行われる。コントローラ３５は、カード上の一連の電気接点３９を介してカードが挿入されているソケットと接続されるホストデバイスと交信する。
【００１９】
アレイ３３のメモリセルは分割され、異なるタイプのデータを記憶するように個々に指定されるセルの４つの非オーバーラップ領域に分けられる。最大の記憶容量領域４１が指定されて、ユーザデータ、このケースでは、暗号化されたオーディオ、ビデオまたはその他のデータが記憶される。ユーザデータは、暗号化されていないデータを含むものであってもよいし、含まないものであってもよい。メモリのシステム領域４３はカード製造業者の６４ビットメディア識別子（ＩＤ_media ）と、４Ｃエンティティにより提供される１６個のメディアキー・ブロック（ＭＫＢ）とを記憶し、各ＭＫＢは最大４キロバイトのサイズを有する。これらはすべてカード製造業者により予め記録されている。１６ＭＫＢのうちの１ＭＫＢがオーディオユーザデータでの使用に指定されており、別の１ＭＫＢはビデオユーザデータ、画像データ等々の別の用途での使用に指定されている。システム領域４３はカードの外側からの読出し用としてアクセス可能な書込み領域である。隠された領域４５は、システム領域４３に記憶された１６個の別個のメディアキー・ブロック（ＭＫＢ）に対応する１６個の予め記録された一意的メディアキー（Ｋ_mu）を担持する。この隠された領域４５は、メモリカード自身でしかアクセスできない書込み保護領域である。この保護領域４７は、明確な相互認証に成功した後でしかアクセスできない読出し／書込み領域である。ランダムに選ばれたタイトルキー（Ｋ_t ）とコピー制御情報（ＣＣＩ）とが暗号化された形式で保護領域４７に記憶される。ユーザデータ領域４１に記憶されたコンテンツの各ピース（ファイル）は、やはり保護領域４７に暗号化された形式で記憶された一意的タイトルキーを用いて暗号化される。保護領域４７に記憶されたタイトルキーとＣＣＩは、一意的メディアキーによりまとめて連鎖され、暗号化される。上記一意的メディアキーは各メモリカードについて一意的に決められ、この一意的メディアキーの隠された領域４５に記憶される。ユーザデータ領域４１のファイルシステムは、一般に通常のＦＡＴファイルシステムである。
【００２０】
カードメモリのシステム領域４３に記憶されているようなメディアキー・ブロック（ＭＫＢ）には、一続きの連続するレコード、図４に例示されているような１つのレコードが含まれる。ＭＫＢ画像４９全体は６４キロバイトである。このＭＫＢ画像４９は５１２バイトからなる１２８チャンクに分割される。チャンク１は、第１のレコードの全てまたは一部を含み、図でＭＫＢチャンク５０のラベルがつけられているが、このチャンク１は拡大されて、その構成要素部分が示されている。チャンク５０は複数のレコードを含むものであってもよい。第１のフィールド５１にはレコードタイプが含まれ、第２のフィールド５３には上記レコードの全長が含まれ、残りのフィールド５５にはキー自身が含まれる。このレコードタイプのデータおよび長さフィールド５１と５３は暗号化されない。ＭＫＢの各レコードの全長は４の倍数のバイトである。図５のブロック５７により例示されているように、ＭＫＢのキーレコードは、携帯用デバイス（ＰＤ）、使用許諾を受けた対応モジュール（ＬＣＭ）、あるいは、メモリカードに記憶されたコンテンツデータの読出しまたはプログラミング用メモリカードを利用する別のデバイスに記憶されたデバイスキーにより解読される。デバイスキーＫｄ１、Ｋｄ２、Ｋｄ３…が、図２の携帯用オーディオ・プレイヤのＭＣＵ２５内の不揮発性フラッシュメモリのような利用デバイスのメモリの中へデバイス製造業者により書込まれる。これらのデバイスキーは４Ｃエンティティによりデバイス製造業者へ提供され、秘密に保持される。所定の利用デバイスに記憶されるデバイスキーの数はデバイスタイプに依存して決められる。
【００２１】
図５の処理を行う利用デバイス（ＰＤ、ＬＣＭまたは別のデバイス）はブロック５７の解読の一部としてメディアキーＫ_m を計算する。これについては図９と図１０を参照しながらさらに詳細に解説する。挿入されたメモリカードのシステム領域から読出されたＭＫＢの各レコード（図４）は通常以下のように処理される。ＭＫＢの処理の完了後、ブロック５７の秘密メディアキー出力として最も新しく計算されたＫ_m 値が用いられる。このメディアキーＫ_m とメディア識別子ＩＤ_media は図５のブロック５９により示されるようにＣ２の一方向機能により合成され、一意的メディアキーＫ_muが作成される。この処理についての追加の詳細は前に引用した４Ｃエンティティの文献を参照することにより得ることができる。
【００２２】
図６は、図３のメモリ空間割当てを有するメモリカード１３上へのオーディオ・コンテンツの記録時、または、上記メモリカード１３からのオーディオ・コンテンツの再生時のいずれかの際に行われる認証と暗号化処理の全てを示す。オーディオ・コンテンツまたは別のコンテンツのカード１３上への記録を行うための、パーソナル・コンピュータまたは別のＬＣＭ６３で行われる処理が例示されている。同様に、記録されたコンテンツをカード１３から読出すための携帯用オーディオまたは別の利用デバイス６５の処理が図示されている。図５と関連して記載した処理が上記双方のデバイスに含まれており、ブロック５７と５９の処理は利用デバイス６５の一部であり、対応するブロック５７’と５９’の処理はコンテンツ記録システム６３の一部である。
【００２３】
記録用コンテンツの一部として、任意に割り当てられたタイトルキーＫ_t が暗号化モジュール６９によりライン６７で入力され、ライン７１で入力されるオーディオ・コンテンツまたは別のコンテンツの１つのファイル（ピース）の暗号化に使用される。次いで、暗号化ファイルがメモリカード１３のユーザデータ領域４１に記憶される。記録されたコンテンツの解読にタイトルキーを利用できるようにするために、前述したように、タイトルキー（Ｋ_t ）の暗号化されたバージョンがセキュリティの保護されたカードの記憶領域４７に記憶される。タイトルキー（Ｋ_t ）の暗号化されたバージョンも、システムメモリ２７、ＭＣＵ２５のＲＡＭメモリ２５Ａ、または、ＤＳＰ３１のＲＡＭメモリ３１Ａのいずれかのメモリに記憶される。デバイスのメモリ内の暗号化されたタイトルキー（Ｋ_t ）を記憶することにより、セキュリティが保護されたカードの記憶領域４７にアクセスする必要がなくなる。これは重要なことである。なぜなら、そうすることによって、読出し毎に保護領域４７にアクセスする場合と比較して少なからぬ時間と処理能力の節減が行われるからである。このことについては図９を参照しながら後程解説する。ＬＣＭ６３内の一連の暗号化モジュール７５、７７、７９およびメモリカード６１のモジュール８１によりタイトルキーＫ_t とコピー制御情報ＣＣＩとが暗号化される。一意的メディアキーＫ_muはモジュール７７により使用される。認証キー交換（ＡＫＥ）モジュール８３は、一意的メディアキーＫ_muがモジュール５９’により計算された形でカード６１の隠された領域４５に記憶されたとき、一意的メディアキーＫ_muを合成して、モジュール７９と８１の各々が使用するセッションキーＫ_s を作成する。記録された暗号化コンテンツを解読できるようにするために、利用デバイス６５は、プライム記号（’）が付加して示したモジュールを除く同じ参照番号で示した対応モジュールを利用して、暗号化処理の逆の処理を行う。
【００２４】
図７は、認証、および、カードと何らかのＬＣＭまたは利用デバイス間でのキー交換（ＡＫＥ）呼掛／応答プロトコルを利用して、メモリカードの保護領域４７にアクセスする技法を示す。この認証が成功したとき、カードとその他のモジュールまたはデバイスはセキュリティが保護された共通のセッションキーＫ_s を共有することになる。前述の処理とプロトコルの追加の詳細については前に特定した４Ｃエンティティの文献を参照することにより得ることができる。
【００２５】
ＳＤメモリカードの認証領域にアクセスを行うには、前述したように、ＯＥＭが４Ｃエンティティから使用許諾を得る必要がある秘密デバイスキーの使用が要求される。ＳＤＫ ＳＷ１００ソフトウェア層の範囲内におけるこれらのキー値の保護およびこれらキー値の露出の制限は、このソフトウェアの設計時の中心的考慮事項の１つである。ＳＤメモリカードのデバイスドライバのようなセキュリティ保護メディアにより、これらの値に依存する処理の実行を可能にしながら、単一の内部モジュールの範囲内でのこれらのキー（およびセッションキーのような他の結果として生じる値）の分離が、頑丈でかつセキュリティが保護されたインタフェース方法論で達成される。再度、ＳＤメモリカードを用いて本発明を例示する。しかし、ＣＤや、カード内や遠隔地に配置された記憶デバイス内にさえ存在してもよいセキュリティが保護された他のメモリのような任意のセキュリティ保護メディアでも本発明の利用は可能である。
【００２６】
図８は、前述の処理を用いて暗号化した情報にアクセスするために、携帯用デバイスやＬＣＭで機能するように設計されたソフトウェアシステムの実施形態を例示する図である。サンディスク・ソフトウェア（ＳＷ１００）は、完全な簡単に使用可能なソフトウェアによるソリューションであり、ＯＥＭの音楽再生装置および録音装置がセキュリティの保護されたデジタル（ＳＤ）メモリカードを含むセキュリティ保護メディアを容易にサポートすることがこのソリューションにより可能となる。
【００２７】
ＳＤカード１３にアクセスするために携帯用デバイス１５の中へ移植された形でＳＷ１００が図８に示されている。ＳＷ１００は、パーソナル・コンピュータのような任意の使用許諾を受けた対応モジュールにインストールすることも可能である。オーディオインタフェース１０５と、ビデオインタフェース１１０と、画像処理用インタフェース１１５とがデバイスとの通信ポイントである。これらのインタフェースにより、デバイス用の単一通信ポイントが提供され、一般にこのデバイスから単純なコマンドが受信され、それによってデバイスは、暗号化データをセキュリティ保護メディアから取得し、次いで、該データの解読と処理とを行うための複雑な処理に関与する必要がなくなる。これらの複雑な処理のすべてがＳＷ１００により処理される。再生リストの管理のような再生の構成と、アーティストの歌や種々の再生リストとアーティストの画像のような画像との相関関係もインタフェース１０５、１１０、１１５により管理される。アプリケーション・プログラミング・インタフェース（ＡＰＩ）１３０Ａはコマンド・ディスパッチャ（ＣＤ）１３０内に常駐する。ＣＤ１３０とＡＰＩ１３０Ａとにより、インタフェース１０５、１１０、１１５からコマンドが受信され、インタフェースへ情報がリレーされ、ＳＷ１００で行われる処理のすべてが編成される。上記処理には、セキュリティ保護メディアに記憶されたコンテンツの再生と記録に関連するデバイス１５の処理が含まれ、必須の暗号化、解読および圧縮アルゴリズムのすべてが上記処理に伴う。この切れ目のないインタフェースと制御処理に関するさらに多くの情報については、本願と同日付で出願され、本願と同じ発明者を有する“不揮発性メモリカード、コンパクトディスクまたはその他のメディアから記録されたオーディオ、ビデオまたはその他のコンテンツを再生するためのシステム、方法およびデバイス（代理人整理番号：Ｍ−９９１３ＵＳ）という米国特許出願を参照されたい。
【００２８】
ＳＤオーディオエンジン（ＳＤＡＥ）１４０、ＳＤビデオエンジン（ＳＤＶＥ）１５０、ＳＤ画像エンジン（ＳＤＩＥ）１６０は、ＣＤ１３０からの命令の受信時にセキュリティ保護メディアに常駐するオーディオ、ビデオおよび画像コンテンツをそれぞれ処理する。これは、ＳＤＡＥ１４０が、ＡＡＣ、ＷＭＡ、ＭＰ３のようなオーディオ用の周知のフォーマットのいずれをも処理できることを意味する。同様に、ＳＤＶＥ１５０は、ウィンドウズ・メディア・ファイルや、リアル・ネットワーク・ファイルＭＰＥＧや、他の任意の周知のタイプのビデオファイルのようなビデオクリップ用の周知のフォーマットのいずれをも処理可能である。最終的に、ＳＤＩＥ１６０は、ＴＩＦ、ＧＩＦ、ＪＰＥＧ、ビットマップなどの周知のタイプのいずれの画像ファイルでも処理することができる。各インタフェースはセキュリティが保護されたＡＰＩ（ＳＡＰＩ）と、セキュリティが保護されていないＡＰＩ（ＮＳＡＰＩ）とを備える。処理されたコンテンツは暗号化されていても、暗号化されていなくてもよい。暗号化されたコンテンツはＳＡＰＩ１４０Ａ、１５０Ａ、１６０Ａを介してアクセスされる。これらのＳＡＰＩはサンディスク・セキュリティ・マネージャ（ＳＳＭ）１８０と交信する。セキュリティが保護されたコンテンツと関係するすべてのコマンドがＳＳＭ１８０を通じて導かれる。セキュリティが保護されたデジタルセキュリティ・エンジン（ＳＤＳＥ）１７５については後程さらに詳細に説明するが、このエンジンによってすべての暗号化処理と解読処理とが行われる。メディアの認証とコンテンツの解読とに使用されるキーがＳＤＳＥ１７５内に含まれ、ＳＤＳＥ１７５により独占的に処理される。カードに常駐する未暗号化コンテンツはＮＳＡＰＩ１４０Ｂ、１５０Ｂ、１６０Ｂを介してアクセスされる。これらのＮＳＡＰＩは、メディアの未暗号化コンテンツにアクセスするために、セキュリティが保護されていないファイルインタフェース（ＮＳＦＩ）１７０と交信する。
【００２９】
記憶メディアにおけるデータの読出しまたは書込みを目的として、ＮＳＦＩ１７０とＳＤＳＥ１７５とはデバイスドライバ１９０と交信する。ＳＤカードの例でのデバイスドライバ１９０は、ＳＤカード１３のデバイスインタフェース３９の接点間を往来する信号を管理し、駆動する。デバイスドライバ１９０は、種々のデバイスまたはメディアの専用のタイプのデバイスインタフェース３９に合わせて特製される。メモリカードデバイスの場合、ドライバ１９０は、デバイス１５に配置されている接点間を往来する信号を管理し、駆動する。光学メディアの場合には、デバイスドライバ１９０は、光ピックアップユニットを備えた種々のハードウェア・コンポーネントから出される信号を管理し、駆動することができる。デバイスドライバ１９０には、セキュリティが保護されたデバイスドライバ・インタフェース（ＳＤＤＩ）１９０Ａと、セキュリティが保護されていないデバイスドライバ・インタフェース（ＮＳＤＤＩ）１９０Ｂとが含まれる。ＳＤＤＩ１９０ＡとＮＳＤＤＩ１９０Ｂとは、デバイスドライバ１９０内で互いに分離される。ＳＤＤＩ１９０ＡがＳＤＳＥ１７５と独占的に交信するのに対して、ＮＳＤＤＩ１９０ＢはＮＳＦＩ１７０と独占的に交信する。
【００３０】
デバイスキーおよびＳＤ−オーディオセキュリティ方式にとって必要なその他の値が、制限されたセキュリティソフトウェア・モジュールであるＳＤセキュリティ・エンジン（ＳＤＳＥ）１７５内に収納される。これらの値の全ての操作はこのモジュールだけに限られている。値が出入りして、ＳＤＳＥ１７５の上位に在るソフトウェア層へ渡されることは決してない。これらのキーを含むセキュリティ・サービスに対する全ての要求はこのセキュリティ・モジュールを遮蔽しているＳＳＭ１８０により制御され、モニタされる。このセキュリティ・モジュールの下で、ＳＤメモリカード・デバイスドライバ１９０がセキュリティ・アクセスを実行する。これらのドライバサービスに対する要求は、秘密のドライバセキュリティ・インタフェースであるセキュリティが保護されたデバイスドライバ・インタフェース（ＳＤＤＩ）１９０Ａを介して行われるが、このインタフェースはセキュリティ・モジュールにしか認知されない。ＳＤＳＥ１７５はこのインタフェース１９０Ａを用いて、Ｇｅｔ Ｍｅｄｉａ Ｋｅｙ Ｂｌｏｃｋ（ＭＫＢ）のような特別のセキュリティコマンドを実行する。セキュリティが保護されていないデバイスドライバ・インタフェース（ＮＳＤＤＩ）１９０Ｂもデバイスドライバ１９０を利用して、カード１３のユーザ領域４１内の任意の暗号化されていないファイルにアクセスする。
【００３１】
ＳＷ１００のアーキテクチャのセキュリティはこのアーキテクチャのキーのセキュリティの中に常駐する。秘密の“ソフトキー”はセキュリティが保護された一時領域に長時間記憶されることはない。なぜなら、長時間の記憶を行うことにより、上記キーを漏洩し、したがって、暗号化されたコンテンツを漏洩する可能性が高くなるからである。ＳＷ１００では、ＳＤＳＥ１７５内で必要なキー（または“ソフトキー”）を動的に作成し、当該専用キーの必要性が当面存在しなければ、当該キーを削除する方式が利用されている。
【００３２】
次にＳＷ１００の処理についてさらに詳細に説明する。ＳＷ１００内でコマンドがデバイスに対して出されるが、このデバイスは、ＯＥＭの４Ｃから使用許諾を受けた使用デバイスキーを必要とする。これらのキーのすべての処理は、ＳＳＭ１８０の下に収納されているＳＤＳＥ１７５モジュールだけに限られている。
【００３３】
ＳＳＭ１８０は、セキュリティ・サービスに対する要求を受け取ると、ＳＤＳＥ１７５内のｐｒｏｃｅｓｓ＿ｓｅｃｕｒｉｔｙファンクションへコマンド要求パケットを渡すことによりこの要求を実行する。キー値が上記要求パケット内に含まれることは決してない。あるいはキー値がＳＤＳＥ１７５の上に在るソフトウェア層で露出されることも決してない。
【００３４】
ＳＤＳＥ１７５がデバイスキーを内部で必要とする場合、デバイスキーはファンクションコールを介して検索され、該キーはＯＥＭにより供給されるライブラリの中へ入れられる。ＳＤＳＥ１７５のライブラリ（ｓｅｃｕｒｉｔｙ．ｌｉｂ）には、解読されたキーがシステムのセキュリティが保護された領域に常駐する時間を短縮するように設計された以下のＡＰＩが含まれる。
１）ＳＥＣ＿ＡＫＥ ＡＰＩ
２）ＳＥＣ＿ＥＮＣ＿ＴＫＥＹ ＡＰＩ
３）ＳＥＣ＿ＤＥＣ＿ＴＫＥＹ ＡＰＩ
４）ＳＥＣ＿ＧＥＴＣＣＩ ＡＰＩ
５）ＳＥＣ＿ＵＰＤＡＴＥＣＣＩ ＡＰＩ
【００３５】
ＳＷ１００の機能と構造は本願明細書に記載されているが、さらに詳細には、上記ＡＰＩ１〜５の機能が図９のフローチャートに示されている。ＡＰＩは、その対応する実行機能の隣に示されている。これらのＡＰＩ並びにＳＷ１００のすべての実行についてのさらなる詳細は本願の添付書類で提出したソースコードで見ることができる。当該ソースコードは本願の一部を形成するものであり、明白に本願明細書に参照により援用されている。
【００３６】
デバイスキーは、一旦取得されると、ＳＤメモリカードから得られるメディアキー・ブロック（ＭＫＢ）と合成されて、“メディアキー”が形成される。この値はＳＤＳＥ１７５内に保持され、後続の要求を処理する際に利用される。しかし、“一意的メディアキー”（Ｋ_mu）がＳＤＳＥ１７５の内部に保持されることは決してないことに留意されたい。この値はすべてのセキュリティ・アクセスの基となる値であり、セキュリティ上の特別の予防策としてリアルタイム・ベースで常に計算され（かつ決してキャッシュされることはない）。ＳＤＳＥ１７５内でのキー処理の詳細な説明を以下続ける。
【００３７】
暗号化処理は、一般的用語で言えば、セキュリティ保護メディアに配置されているコンテンツの不法コピーを止めさせるように設計される。本発明にはこの暗号化処理を行う多くの局面が存在する。まず、例えば歌などのファイル全体が直ちに解読され、このファイル全体が危険に曝される可能性があるメモリの中へ記憶されることは決してない。携帯用デバイスによりバッファが割り当てられ、ＳＤＳＥ１７５により暗号化されたコンテンツのチャンクが一度に読出されて、これらのチャンクの解読が行われ、次いで、ファイルが終了するまで同じバッファ上に何度も書込みが行われる。
【００３８】
図６と図７で見られたように、一意的メディアキー（Ｋ_mu）とタイトルキー（Ｋ_t ）とはコンテンツの解読に最終的に用いられるキーである。このタイトルキーを保護する多くの方法がある。１つの方法として、デバイス１５の非常に良くセキュリティが保護された領域にキーを記憶する方法があり、別の方法として、暗号化されたバッファを読出し、解読する度に、カード１３の保護領域４７からタイトルキーを読出す方法がある。図９はこの好ましい方法を描くフローチャートである。
【００３９】
図９に戻ると、ステップ２０５で、図４で見られるような６４キロバイトのＭＫＢ画像が読出されて、図６に見られるようなメディアキー（Ｋ_m ）が処理され、一意的メディアキー（Ｋ_mu）が作成される。このステップがさらに詳細に図１０に示されているが、これについては後程説明する。デバイスとメディアとの相互認証がステップ２０５で完了した後、ＡＫＥ処理にかけられ、セッションキー（Ｋ_s ）が作成される。このセッションキーは、ステップ２１０で、（デバイスのスイッチが入っている限り、あるいは、デバイスが活動状態にある限り）当該セッションの間でしか使用することはできない。再度図６を参照することによりＡＫＥ処理を理解することができる。ステップ２１３で、一意的メディアキー（Ｋ_mu）は削除される。ステップ２１５で、セッションキー（Ｋ_s ）は、メモリカード１３の保護領域４７に記憶された２重暗号化タイトルキーＥ（Ｅ（Ｋ_t ））の解読に用いられる。その結果は単独に暗号化されたタイトルキー（Ｅ（Ｋ_t ））となる。ステップ２２０で、この暗号化されたタイトルキー（Ｅ（Ｋ_t ））はデバイス１５のメモリに記憶される。このタイトルキー（Ｅ（Ｋ_t ））は、システムメモリ２７、ＭＣＵ２５のＲＡＭメモリ２５Ａ、またはＤＳＰ３１のＲＡＭメモリ３１Ａに記憶されたものであってもよい。このタイトルキーＫ_t は、オーディオの領域ではトラックと呼ばれている各タイトルのための専用のキーであり、本発明を例示するために図９で使用される。各トラックは、例えば、長い古典的な歌などの場合には複数のファイルからつくられたものであってもよい。大きなビデオクリップの場合、タイトルの中に多くのファイルが含まれる場合がある。したがって、トラックの暗号化されたコンテンツのすべての後続する読出しと解読の場合、メモリカードからタイトルキーの検索を行う必要がなくなる。なぜなら、タイトルキーはローカル・メモリに記憶されており、貴重な時間と計算リソースの節減が可能であるが、同時に、このタイトルキーはセキュリティを保護することを目的として暗号化されたままとなっているからである。
【００４０】
ステップ２２５でトラックの一部が再生される。この部分はトラックを含むファイルのいずれであってもよい。ステップ２２５ａで、一意的メディアキー（Ｋ_mu）が再計算される。ステップ２２５ｂで、ローカル・メモリに記憶された暗号化タイトルキーが解読される。次いで、ステップ２２５ｃで、タイトルキーを用いて、デバイス１５のバッファから得られるコンテンツが解読されるが、上記バッファには、メモリカード１３のユーザ領域４１から得たコンテンツが含まれている。バッファが解読された直後に、タイトルキーはステップ２２５ｄで削除され、一意的メディアキーがステップ２２５ｅで削除される。ステップ２２５ｄと２２５ｅの順序は重要ではないが、トラック部分の読出しにかかる時間の間、双方のキーが専ら露出されるという点が重要である。このトラック部分は、１秒の数分の１の再生（解読、解凍、復号化）コンテンツ（オーディオやその他）から、約１０秒までのコンテンツのどの部分であってもよい。好ましくは上記部分は２秒であることが望ましい。この部分の読出しにかかる時間は、デバイスの処理速度とバッファ・サイズを含む多くのファクタに依存して決められる。前述したように、ＭＣＵ２５またはＤＳＰ３１のいずれかによりＳＷ１００の実行が可能であり、さらに、デバイス１５のメモリ２７、２５Ａ、３１Ａまたは３２のうちのいずれかにＳＷ１００を記憶することが可能であり、これによって処理時間の変更が可能となる。これは、ステップ２３０で見られるように、トラックのすべての部分が読出されるまで繰り返される。一旦すべての部分が読出されると、ステップ２３５に示すように、再生を続ける場合、システムは次のトラックへ移ることができる。例えば、ユーザが再生リスト全体の再生を選択した場合にこれが当てはまるかもしれない。
【００４１】
トラックのすべての部分が読出された後、次のトラックの読出しが始まると、ステップ２１５で処理が再開され、この処理によりカード１３の保護領域４７から次の２重暗号化タイトルキーが検索される。これは、一般に、ユーザが、複数のトラックを含む再生リスト全体の再生のために動いているデバイスをセットした場合のケースである。セッションが閉じられた（すなわち、デバイス１５のスイッチがオンかオフになった）場合、新しいセッションキーを作成する必要があり、ステップ２１０で処理が始まる。メモリカードが取り外されるか、新しく挿入された場合、デバイスとメディアは再認証を受ける必要があり、トラックの読出しをするためにステップ２０５で処理が再開する。
【００４２】
図１０は、メディアキー・ブロックの処理動作（上述の図９のステップ２０５）を示す図である。図４で見たように、ＭＫＢ画像４９は長さが６４キロバイトである。画像４９全体を同時に読出して、ＭＫＢを計算することは効率的ではなく、大容量のＲＡＭと長い処理時間とを必要とする。このシステムはＲＡＭ要件の低減と、処理時間の短縮とを図るものである。ＭＫＢ画像４９はチャンク１〜１２８に分割される。各チャンクは５１２バイトであり、ＭＫＢの４つの異なるタイプのレコード、すなわち、０×８１として知られる検証用メディアキーレコード（ＶＭＫＲ）と、０×０１として知られる計算用メディアキーレコード（ＣＭＫＲ）と、０×８２として知られる条件計算用メディアキーレコード（ＣＣＭＫＲ）、または０×０２として知られる終了用メディアキーレコード（ＥＭＫＲ）のうちの１つを各チャンクが含むものであってもよい。これらのレコードについては、前に引用した４Ｃエンティティの記録可能メディア（ＣＰＲＭ）仕様のコンテンツ保護に記載されている。
【００４３】
この例では、チャンク長とバッファ長は同じである。しかし、バッファ長とチャンク長は双方とも２５６バイトから４０９６バイトまでの範囲に及ぶ場合がある。各レコードがチェックされ、そのレコードタイプに基づいて専用の処理が行われて、或るデータが保存され、このデータはメディアキーを取得するために後で使用される。レコードが識別される度にそのレコード長がバッファオフセットの全長に加算される。この全長をチャンク長で除することによりチャンク番号が計算される。このチャンク番号は、選択されたチャンクデータのメディアキー・ブロックに対するインデックスである。全長の残り部分は選択されたチャンクデータに対するオフセット値である。行と列とを用いて、暗号化されたメディアキーと条件つきの暗号化されたメディアキーとがどこにあるかが計算される。これらの暗号化キーは保存され、次いで電子コードブックモード・アルゴリズムでの解読Ｃ２暗号化が実行されてメディアキーが取得される。次いで、このメディアキーは正しい最終メディアキー（Ｋ_m ）について検証される。
【００４４】
レコード数と関連するＭＫＢからメディアキー（Ｋ_m ）を取得するのに必要な、ＭＫＢチャンク当たりの読出し回数Ｔを以下に示す。
レコード数＜Ｔ＜（レコード数^* ２）
Ｔ：ＭＫＢチャンクのアクセスに必要な回数
【００４５】
各レコードは異なる長さとデータ値とを有する。各レコードの情報は２回の読出しの範囲内で取得が可能である。４つレコードが存在するため、４〜８回の読出しがＭＫＢチャンクの処理とレコードの取得には必要となる。
したがって、読出し回数Ｔは下記のようになる。
４＜Ｔ＜８
【００４６】
５１２バイトのＭＫＢデータのアクセスにＮミリ秒かかると仮定する。第１の方法では、６４ＫのＭＫＢ画像全体にアクセスして、メディアキーを取得するのに（１２８^* Ｎ）ミリ秒かかることになる。第２の方法では、最悪のケースのシナリオとしても、メディアキーを取得するのに（８^* Ｎ）ミリ秒しかかからない。したがって、この方式を利用すると相当の時間の節減になる。平均して、メディアキー（Ｋ_m ）の取得時の読出し回数は４〜６の範囲になり、必要な時間は上に示したものよりも比例して短くなる。
【００４７】
図１０で拡大されている図９のステップ２０５は、ステップ２０５．７５で最終メディアキーが作成されるまで、あるいは、ステップ２０５．８０でメディアが拒絶されるまで実行される。メディアキーの算出のために、１２８チャンクのすべてを読出す必要はない。また、チャンク当たり５１２バイトのすべてを読出す必要もない。ＭＫＢデータの処理は、１回に１チャンクのデータを必要とし、当該特定チャンク内の所望の位置を指示し、取得した値を計算する処理である。すべてのＭＫＢデータが必要となるわけではない。図１０に描かれているアルゴリズムは、どのようなチャンクのＭＫＢデータを必要とするか、どのようなレコードを処理すべきか、どこに暗号化データが位置するかを正確に計算するための数学的計算を行うものである。
【００４８】
ステップ２０５．５で、バッファポインタがデータバッファにセットされ、バッファオフセットがクリアされる。次に、ステップ２０５．１０で、チャンク番号が最大チャンク番号以上かどうかを調べるチェックが行われる。チャンク番号が最大チャンク番号以上であれば、ステップ２０５．１５でエラーが返される。チャンク番号が最大チャンク番号未満であれば、チャンク番号は増分され、ステップ２０５．２０で新しいデータがバッファの中へロードされる。次いで、ステップ２０５．２５でバッファオフセット値が更新される。このようにして正しい位置（チャンク番号＋オフセット値）にポインタをセットすることが可能となる。ステップ２０５．３０で、バッファポインタがバッファオフセット値にセットされる。ステップ２０５．４０で、ポインタが位置するオフセット位置からバッファが読出される。次いで、システムは、どのようなタイプのレコードが読出されているかを検出する。ステップ２０５．４０に示されているように、システムは、どのようなタイプのレコードが読出されているか、および、どのようなレコード長が当該レコードと関連するかのチェックをまず行う。その後に続くアクションはレコードタイプとレコード長とに応じて異なるものとなる。各レコードのレコード長を用いて、後続レコードの読出し時にバッファポインタがどこに位置するかが決定される。これはステップ２０５．４９により反映され、バッファオフセット値の更新と新しいオフセット値でバッファポインタのセットが行われる。
【００４９】
ステップ２０５．４２に示すようにレコードがＣＭＫＲであれば、システムは、ステップ２０５．４９で、暗号化されたメディアキー（Ｋ_m ）が位置する正しいＭＫＢ位置にバッファのチャンク番号とオフセット値とを更新する。各カードは１６ＭＫＢを持つ。したがって、システムは、暗号化されたメディアキーが存在する位置でオフセット値を取得し、特定のＭＫＢチャンク番号を見つけ、バッファ（１６ブロック×５１２バイト）を割り当て、各ブロック内のオフセット値へ進み、暗号化されたメディアキーを読出すことになる。次いで、システムは、デバイス１５から供給されたデバイスキー（Ｋ_d ）を用いて、ステップ２０５．５０でメディアキーの解読（計算）を行う。一旦メディアキーが計算されると、次のステップはメディアキーの検証である。
【００５０】
レコードがステップ２０５．４４で評価されたようなＶＭＫＲであれば、ステップ２０５．５０の第１の試み、あるいは、ステップ２０５．６５の後続の試みのいずれかの試みで前回計算されたメディアキーが、ステップ２０５．５５で基準メディアキー（Ｋ_m ）と比較される。これを行うために、基準メディアキーはまずローカルに記憶される。上記キーが同じであれば、パス（１６進でＤＥＡＤＢＥＥＦ）が返され、システムはメディアキーの条件計算を行う必要がなくなる。次のレコードの読出しをどこから開始するかを計算するために、ＶＭＫＲのレコード長を用いてバッファポインタを次のレコードへ移す。上記キーが同じでなければ、ステップ２０５．４６でＣＣＭＫＲレコードが読出されたとき、メディアキーの再計算が行われる。上記ＣＣＭＫＲレコードが読出されると、バッファポイントがセットされて、ステップ２０５．４９で更新されたバッファオフセット値で読出しが行われた後、ステップ２０５．６５でメディアキーが再計算され、次いで、このメディアキーは次のＶＭＫＲが読出されるとき、続いて検証される。ＣＣＭＫＲの最大計算回数がシステムにより設定されるが、この回数は好ましくは１回であることが望ましい。
【００５１】
第１の計算はＣＭＫＲが発見されたときに行われる。ＶＭＫＲが発見されたとき、開始された検証処理中にメディアキー（Ｋ_m ）が決定された形でメディアキーの計算に成功した場合、メディアキー（Ｋ_m ）の条件計算を行う必要はなくなる。検証が不成功に終わった場合、ＣＣＭＫＲが発見されれば、メディアキー（Ｋ_m ）の再計算と再検証とが行われる。これはメディアキーを計算する２つのチャンスが存在することを意味する。最後に、上記レコードが、ステップ２０５．４８で評価されるようなＥＭＫＲであれば、ステップ２０５．７５で、システムにより、上記レコードの終端に有効なメディアキー（Ｋ_m ）が存在すること、および、ステップ２０５．４９でバッファポインタがこのタイプのレコードに対する適切なオフセット値でセットされた後、ステップ２０５．７５で最終メディアキー（Ｋ_m ）の作成が検証される。しかし、ステップ２０５．７０で有効なメディアキーが返されなければ、ステップ２０５．８０でメディアは拒絶される。最終メディアキーがステップ２０５．７０で返されれば、ステップ２０５．８５により示されているように処理は図９のステップ２１０で継続する。このようにしてＭＫＢの処理は完了する。
【００５２】
ＳＤＳＥ１７５内のファンクションは、デバイスドライバ１９０と接続するセキュリティが保護されたデバイスドライバ・インタフェース（ＳＤＤＩ）１９０Ａを用いることにより、Ｇｅｔ ＭＫＢのようなセキュリティ・アクセスを実行する。この同じデバイスドライバ（ＳＤＤＩ１９０Ａ）は、直接呼び出しが可能なＳＤＳＥ１７５内のファンクションも利用する。例えば、認証領域の読出し命令を出す前に、ＳＤＤＩ１９０Ａは、ＳＤＳＥ１７５内のｓｅｃ＿ａｋｅファンクションをまず呼び出す必要がある。次いで、ｓｅｃ＿ａｋｅファンクションはＳＤＤＩ１９０Ａの中へコールバックを行う。ＳＤＳＥ１７５内でのデバイスキーの分離を容易にするこの“デュアル呼び出し関係”は、ＳＤオーディオ規格のＳＷ１００の実施構成にユニークなものである。
【００５３】
ＳＤＳＥ１７５は、すべてのキー指向型処理を処理し、さらに、オーディオインタフェース１０５、ビデオインタフェース１１０、あるいは、画像処理用インタフェース１１５が一定のＳＤコマンドを受信した場合、デバイスドライバは、これらの値を必要とするので、直接呼び出しが可能なＳＤＳＥ１７５内のファンクションを利用しなければならない。これらのファンクションを実行する場合、ＳＤＳＥモジュール１７５は、デバイスドライバ１９０の秘密のセキュリティ・インタフェース（ＳＤＤＩ１９０Ａ）の中へ次にコールバックを行わなければならない。この“デュアル呼び出し関係”により、ＳＤＳＥ１７５とデバイスドライバ１９０間でのない交ぜの（interwoven）要求が可能となり、これによってセキュリティ・モジュール内でキー値の分離が可能となる。
【００５４】
ＳＤＳＥ１７５ソフトウェア層は、セキュリティ・ドライバ要求パケットを開始し、要求パケットポインタを通過するセキュリティ・ドライバインタフェース・エントリポイントを呼び出すことにより、秘密のインタフェースを介してセキュリティデバイスドライバ・サービスの呼び出しを行う。
【００５５】
参照により援用されている添付のソースコードを明らかにするために、以下のテーブルが提供される。
【００５６】
要求パケット（ｓｄａｐｉ．ｈに定義される）は、以下のように定義されるデータ型ＳＳＭＳＥＲＶＥから構成される。

【００５７】
コマンド・インデックス（ＩＮＴ１６ｏｐＣｏｄｅ）は、要求されたサービスに対するコマンドを保持する。サポートされるコマンドには以下が含まれる。

【００５８】
セキュリティ・デバイスドライバ・サービス要求がＳＤＳＥ１７５モジュールから出される。例えば、呼掛１生成関数は以下のように呼掛１を送る。

【００５９】
すべてのキー操作はＳＤＳＥ１７５に限られているため、認証キー交換（ＡＫＥ）の実行またはバスの両端にわたって転送されるデータの解読を行うにはＳＳＤＩ１９０ＡはＳＤＳＥ１７５のファンクションに依拠しなければならない（バスの両端にわたって送られるすべてのデータは、各ＡＫＥから作成される“セッションキー”を用いてまず暗号化されることに留意されたい）。
【００６０】
ＡＫＥの実行時に、ＳＤＳＥ１７５はＳＤメモリカード１３へコマンドを送らなければならない。したがって、ＳＤＳＥ１７５はＳＤＤＩ１９０Ａの中へ次に呼び込みを行わなければならない。この呼び出し関係は、認証領域の読出し処理に必要なステップを描く図７に概略が示されている。
【００６１】
ＳＤＳＥ１７５内のｓｅｃ＿ａｋｅ関数は、セキュリティＳＤＤＩ１９０Ａにより呼び出されたとき、秘密のドライバインタフェースを介してセキュリティ・デバイスドライバの中へ４回のコールバックを行うことに留意されたい。これら４回の要求はＳＤＤＲＶ＿ＳＥＴＣＨＡＬＧＥ、ＳＤＤＲＶ＿ＧＥＴＣＨＡＬＧＥ、ＳＤＤＲＶ＿ＳＥＴＲＥＳＰ、ＳＤＤＲＶ＿ＧＥＴＲＥＳＰから構成される。これによって、図７に示すセキュリティ・モジュールによる必須の呼掛のセット／呼掛の取得、応答のセット／応答の取得ステップの実行が可能となる。この結果生じるセッションキーはセキュリティ・モジュール内に記憶される。セキュリティ・デバイスドライバが、ＳＤＤＩ１９０Ａから情報を得るために、ＳＤＳＥ１７５のｂｕｓ＿ｄｅｃｒｙｐｔファンクションの中へ呼び込まれるとき、上記セッションキーを用いてデータが解読される。
【００６２】
乱数発生
図６と図７に示すＡＫＥ処理８３は乱数の発生を必要とする。ＳＤ乱数生成（ＲＮＧ）の実現は、前回の乱数Ｖｔに基づく乱数シード値Ｖ（ｔ＋１）の計算を必要とする。乱数シード値Ｖ（ｔ＋１）はフラッシュメモリへのこのシード値の記憶を必要とし、該シード値は次の乱数を発生させるためのシード値として使用される。この乱数とシード値はＣ２＿Ｇで用いられる（Ｃ２暗号化１方向関数）。
【００６３】
乱数シード値Ｖｔ＋１の再書込みが不可能な低価格のコンピューティング・プラットフォーム（すなわち、シード値記憶用として指定されたＥＥＰＲＯＭを備えていない）では、ＲＮＧの実行により問題が生じる可能性がある。
【００６４】
プログラムが、乱数発生装置のシード値として一定の数または予測可能な数を使用した場合、ハッカーによりコピー保護を破られたり、キーを盗まれたりする可能性がある。固定シード値を用いた場合、同じＳＤカードアドレスがアクセスされれば、第１の乱数値と呼掛値も固定される。応答のトラッキングを行うことにより、おそらく一意的メディアキーが盗まれる可能性がある。本願ではシステムタイマがＰＣアプリケーション用ソリューションとして利用される。タイマにより生成されたシード値を予測不能にすることを保証するために、本願ではタイマのシャッフルが行われ、それによって乱数シード値の全てのバイトがランダムなものとなる。マイクロチップＰＩＣ１６ｘｘｘのようなシステムでは、シャッフル後の乱数生成のシード値としてタイマ１（実行命令数）の使用が可能である。
【００６５】
この主要な着想とは、常時増分する２以上のタイマを利用して、最も緩慢な更新（最上位）バイトの頻度を操作し、この最上位バイトがより高い頻度で更新を行うようにするということである。最も緩慢な更新（最上位）バイトの値が最も速い更新（最下位）バイトの関数として計算される。乱数発生の１つの方法としてシステムタイマを利用する方法がある。この方法では、４バイトのプロセッサクロックと４バイトの協定世界時とが用いられる。プロセッサクロックはプログラムが起動してからのプロセッサの時間数である。この時間は、本願では６０であるＣＬＯＣＫＳ＿ＰＥＲ＿ＳＥＣＯＮＤＳに合わせて微調整される。ＣＬＯＣＫＳ＿ＰＥＲ＿ＳＥＣＯＮＤＳは、マイクロソフトＣ＋＋実行時関数“ｃｌｏｃｋ（）”を通じて得られる。協定世界時はマイクロソフトＣ＋＋実行時関数“ｔｉｍｅ（）”を通じて得られる。この協定世界時は１８９９年１２月３１日０時からの秒数である。
【００６６】
プロセッサクロックはバイト０〜３の中へ読込まれ、協定世界時はバイト４〜７の中へ読込まれる。バイト０と１とは高速に変化するが、バイト２と３の変化の速度はバイト０と１の場合よりも遅い。したがって、本願では、バイト０と１が変化するペースに基づくペースでバイト２と３を変化させることによりバイト２と３の変化の速度を上げることができる。これは複数の方法で行うことが可能である。例えば、排他的論理和を用いる。
ｖｔ＿１［２］＝ｖｔ＿１［２］＾ｖｔ＿１［０］
ｖｔ＿１［３］＝ｖｔ＿１［３］＾ｖｔ＿１［１］＾ｖｔ＿１［０］
【００６７】
同様に、以下の例によりさらに高速のペースでバイト６および７を変化させることが可能である。
Ｖｔ＿１［６］＝ｖｔ＿１［０］＋ｖｔ＿１［１］＋ｖｔ＿１［２］
＋ｖｔ＿１［３］＋ｖｔ＿１［４］＋ｖｔ＿１［５］＋ｖｔ＿１［６］
Ｖｔ＿１［７］＝ｖｔ＿１［０］＾ｖｔ＿１［１］＾ｖｔ＿１［２］＾
ｖｔ＿１［３］＾ｖｔ＿１［４］＾ｖｔ＿１［５］＾ｖｔ＿１［６］＾
ｖｔ＿１［７］
【００６８】
変化のペースの増加は、一定のバイト位置でタイマ値の倍数を用いることによって、あるいは、緩慢な移動バイトをより高速に移動するバイトに依存させる別の方法よっても達成可能である。さらなる詳細については、本願の一部を形成する添付のソースコードを参照されたい。
【００６９】
したがって、固定シード値に対してＣ２暗号を適用することにより新しい乱数シード値Ｖ（ｔ＋１）が生成される。Ｃ２＿ＧはＣ２暗号化１方向関数である。Ｃ２＿Ｇは、固定シード値“ｖ０”に乱数キー“ｃ１”を適用して、第１のＡＫＥ用の異なる初期シード値“ｖ１”を生成するものである。
【００７０】
ＣｕｒｒｅｎｔＴｉｍｅは、ＤＯＳのソフトウェア割り込み“１Ａ”関数“０”を用いたタイマクロックの読出しようのアセンブリプログラムである。＿ＣｕｒｒｅｎｔＴｉｍｅ ＰＲＯＣ ＮＥＡＲのコードは以下のようである。
ｐｕｓｈ ｃｘ； ｍｏｖ ａｘ，０； ｉｎｔ ｌａｈ； ｍｏｖ ａｘ，ｄｘ； ｍｏｖ ｄｘ，ｃｘ； ｐｏｐ ｃｘ； ｒｅｔ；＿ＣｕｒｒｅｎｔＴｉｍｅＥＮＤＰ
【００７１】
利点
本発明のシステムおよび方法は多くの点で従来の技法よりも優れた利点を有する。デバイスキーと、結果として得られるセッションキーとがはっきりと分離され、保護されたソフトウェア層の中で操作される。これらのキーは上位層の中で露出されることは決してない。低位のデバイスドライバ層でさえキーへの直接アクセスは与えられない。メディアキーの作成時に、デバイスキーはＯＥＭから供給されるライブラリから検索される。このキーはセキュリティ・エンジン内に保持されるが、このセキュリティ方式の核心部分である一意的メディアキー（Ｋ_mu）には決して記憶されない。セキュリティ・エンジンとつながる秘密のインタフェースによって、すべてのセキュリティ関連キー（例えば、デバイスキー、メディアキー、セッションキーなど）の露出をセキュリティ・エンジン内に制限して保持しながら、セキュリティ・エンジンがメモリカードへの低レベルのアクセスを得ることが可能となる。“デュアル呼び出し関係”により、セキュリティ・エンジンとセキュリティ・デバイスドライバとが相互のサービスのない交ぜの（interwoven）利用を行うことが可能となる。
【００７２】
本発明の特定の実施形態とそれらの利点について図示し、説明してきたが、添付の請求項により画定されるような本発明の精神と範囲から逸脱することなく種々の改変、代替および変更を行うことが可能であることを理解されたい。例えば、本発明の機能を例示するためにＳＤメモリカードの利用を示したが、本発明は、暗号化されたコンテンツを含むいずれのメディアに対しても利用可能である。本発明は、任意のタイプのデバイスによっても利用可能である。
【図面の簡単な説明】
【図１】 セキュリティ保護メディアの読出しと書込みとを行うデバイスを示す例図である。
【図２】 セキュリティ保護メディアのアクセスに使用するデバイスの概略図である。
【図３Ａ】 セキュリティ保護メディア層の概略の例図である。
【図３Ｂ】 セキュリティ保護メディアのメモリセルの物理構造と論理構造とを示す例図である。
【図４】 メディアキー・ブロック（ＭＫＢ）の構成要素のチャンクに分割されたメディアキー・ブロック画像を示す例図である。
【図５】 認証および解読処理部を示す例図である。
【図６】 認証および暗号化処理を示す例図である。
【図７】 図６に示す認証キー交換処理を示す概略図である。
【図８】 本発明のソフトウェアのモジュールを例示するブロック図である。
【図９】 本発明に基づくオーディオトラックの再生を示すフローチャートの概観図である。
【図１０】 図９の１ステップである、図４に示すＭＫＢ画像の処理を示すフローチャートである。

Claims (12)

1. 取り外し可能なメディアの暗号化されたトラックにデバイスを用いてアクセスする方法であって、前記トラックがコンテンツを含むフレームを有する方法において、
   前記メディアを認証するステップと、
   前記トラックを解読するステップであって、
   （ａ）一意的メディアキーを計算するステップと、その後、
   （ｂ）前記一意的メディアキーを用いて前記デバイスのメモリに記憶されたタイトルキーを解読するステップと、その後、
   （ｃ）解読されたタイトルキーを有する前記トラック全体よりも少ないトラックの一部を有する１グループのフレームを解読するステップと、その後、
   （ｄ）前記解読されたタイトルキーを削除するステップと、
   （ｅ）前記一意的メディアキーを削除するステップと、
   （ｆ）前記トラック全体が完了するまで、ステップ（ａ）から（ｅ）を繰り返すステップと、を含む処理によりトラックを解読するステップと、
   を有することを特徴とする方法。
2. 請求項１記載の方法において、
   前記メディアを認証するステップが、
   メディアキーを計算するステップと、その後、
   前記メディアキーから一意的メディアキーを計算するステップと、その後、
   前記メディアキーを削除するステップと、その後、
   前記一意的メディアキーからセッションキーを計算するステップと、その後、
   前記一意的メディアキーを削除するステップと、
   を有することを特徴とする方法。
3. 請求項１記載の方法において、
   前記メディアを認証しながら、前記メディアに記憶された２重暗号化タイトルキーを計算されたセッションキーを用いて解読して、単独に暗号化されたタイトルキーを作成するステップと、
   前記単独に暗号化されたタイトルキーを前記メディアから前記デバイスのメモリの中へコピーするステップと、
   をさらに有することを特徴とする方法。
4. 請求項２記載の方法において、
   前記メディアキーを計算するステップが、
   （ａ）メディアキー・ブロックの第１のレコードをバッファから読出すステップと、
   （ｂ）前記第１のレコード長とレコードタイプとに基づいてバッファオフセットを更新するステップと、
   （ｃ）前記更新されたバッファオフセットで前記メディアキー・ブロックの別のレコードを読出すステップと、
   （ｄ）前記メディアキー・ブロックのすべての必要なレコードが読出され、前記メディアキーが計算されるまで、ステップ（ａ）から（ｃ）を繰り返すステップと、
   を有することを特徴とする方法。
5. 請求項１記載の方法において、
   前記グループのフレームが、復号化された形または解凍された形で１秒から５秒のコンテンツを含むことを特徴とする方法。
6. 請求項１記載の方法において、
   前記トラックを解読するステップが、１以上のファイルを解読するステップを有し、前記ファイルが前記フレームを含むことを特徴とする方法。
7. 請求項１記載の方法において、
   前記トラックを復号化し、解凍するステップをさらに有することを特徴とする方法。
8. 取り外し可能なメディアの暗号化されたデータファイルにデバイスを用いてアクセスする方法であって、前記データファイルがコンテンツを含むフレームを有する方法において、
   ユーザセッション用の前記メディアを認証するステップであって、
   メディアキーを計算するステップと、その後、
   前記メディアキーから一意的メディアキーを計算するステップと、その後、
   前記メディアキーを削除するステップと、その後、
   前記一意的メディアキーからセッションキーを計算するステップと、その後、
   前記一意的メディアキーを削除するステップと、を含む処理によりメディアを認証するステップと、
   前記メディアに記憶された２重暗号化タイトルキーを前記セッションキーを用いて解読して、単独に暗号化されたタイトルキーを作成するステップと、
   前記単独に暗号化されたタイトルキーを前記メディアから前記デバイスのメモリの中へコピーするステップと、
   前記ファイルを解読するステップであって、
   （ａ）前記一意的メディアキーを計算するステップと、その後、
   （ｂ）前記一意的メディアキーを用いて前記デバイスの前記メモリに記憶された前記タイトルキーを解読するステップと、その後、
   （ｃ）１グループのフレームを解読するステップと、その後、
   （ｄ）前記解読されたタイトルキーを削除するステップと、
   （ｅ）前記一意的メディアキーを削除するステップと、
   （ｆ）前記ファイル全体が完了するまでステップ（ａ）から（ｅ）を繰り返すステップと、を含む処理によりファイルを解読するステップと、
   を有することを特徴とする方法。
9. 請求項８記載の方法において、
   前記メディアキーを計算するステップが、
   メディアキー・ブロックをチャンクに分割し、前記チャンクが暗号化データのバイトを含むステップと、
   前記ブロックのある特定のチャンク内のオフセット値で読出しを行うために前記バッファをセットすることにより、前記メディアキー・ブロック内のキーを暗号化するステップと、
   を有することを特徴とする方法。
10. 請求項９記載の方法において、
    前記キーを解読するステップが、
    （ａ）第１のレコードからメディアキーを計算するステップと、
    （ｂ）前記バッファオフセットを更新するステップと、
    （ｃ）前記更新されたバッファオフセットで第２のレコードを読出すステップと、
    （ｄ）前記計算されたメディアキーを基準メディアキーと比較することにより、第２のレコードで前記メディアキーを検証するステップと、
    を有することを特徴とする方法。
11. 請求項１０記載の方法において、
    前記メディアキー・ブロックの第１のレコードのタイプと長さとにより前記バッファオフセットを決定することを特徴とする方法。
12. 請求項８記載の方法において、
    前記グループのフレームが、１秒から５秒の解凍され復号化されたオーディオ・コンテンツを含むことを特徴とする方法。

Images