説明

多目的コンテンツ制御をするコントロール構造及びコントロール構造を用いる方法

【解決手段】
記憶媒体に記憶されたツリー構造は、アクセス後であっても、エンティティが行うことに対するコントロールを提供する。ツリーのノードは各々、ツリーのノードのようなものを通じて得たエンティティによるパーミッションを指定する。いくつかのツリーには異なるレベルがある。そのツリーのあるノードにおけるパーミッションは、同じツリーのより高い、より低い、あるいは同じレベルの他のノードにおけるパーミッションと所定の関係を有する。エンティティに、ノードのそれぞれにおいてそのように指定されたパーミッションに適合することを要求することによって、本願のツリー機能は、ツリーが、異なるレベルを有するか否かにかかわらず、どのエンティティがアクションをとることができるか、そして、エンティティのそれぞれがどのアクションをとることができるかをコンテンツオーナーが、コントロールすることを可能にする。モバイル記憶媒体によって提供され得る商品価値を向上させるために、モバイルストレージデバイスが一つ以上のアプリケーションを同時にサポートできることが望ましい。二つ以上のアプリケーションが、モバイルストレージデバイスに同時にアクセスしている場合、二つ以上のアプリケーションのオペレーションを分離し、ここではクロストークとよぶ現象において、それらが他方と干渉しないようにすることが重要であろう。好ましくは、二つ以上の階層的ツリーが、メモリへのアクセスをコントロールする。それぞれのツリーは、異なるレベルにノードを有しており、これにより、対応するセットのエンティティによるデータへのアクセスをコントロールしている。ここでは、それぞれのツリーのノードが、メモリデータにアクセスするための対応するエンティティのパーミッションを指定している。ツリーのそれぞれのノードにおけるパーミッションは、同じツリーのより高い、あるいはより低い、他のノードにおけるパーミッションと所定の関係を有する。ツリーの少なくとも2つの間には、クロストークはないことが望ましい。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、概してメモリシステムに関し、特に多目的なコンテンツ制御の機能を備えたメモリシステムに関する。
【背景技術】
【0002】
コンピュータデバイス市場は、さらなるデータ交換を行うことにより平均収益を増加させるべく、モバイルストレージデバイスにコンテンツストレージを組み込む方向に発展している。これは、コンピュータデバイスで使用する際に、モバイルストレージメディアのコンテンツを保護する必要があることを意味する。コンテンツは貴重なデータを含むが、これはストレージデバイスの製造者または販売者以外の者が所有するデータであるかもしれない。
【0003】
米国特許第6457126号には、暗号機能を備えた一つの種類のストレージデバイスが記載されている。しかし、当該デバイスにより提供される機能はかなり制限(quite limited)されている。したがって、メモリシステムにより多目的にコンテンツを制御する機能を提供することが望ましい。
【発明の開示】
【0004】
モバイルストレージメディア内のコンテンツの保護には、権限のあるユーザまたはアプリケーションのみがメディアに保存されたデータを暗号化するために使用された鍵へのアクセスを有するように、メディア内のデータの暗号化を含めることが可能である。幾つかの従来のシステムでは、データの暗号化および復号に使用された鍵がモバイルストレージメディアの外部のデバイスに保存されている。こうした環境では、コンテンツの所有権を有する企業または個人は、メディア内のコンテンツ利用に関してそれ程管理していない場合がある。メディア内のデータを暗号化するために使用された鍵がメディアの外部に存在するので、当該鍵はコンテンツ所有者による管理を前提としない方法で、あるデバイスから別のデバイスへ渡される可能性がある。本発明の機能の一つによれば、暗号・復号鍵がメディア自体に保存されており、外部デバイスに実質的にアクセス不可能であれば、所有権の所有者は、メディア内のコンテンツへのアクセスを管理し易い。
【0005】
原則的にメディア外部からの鍵へのアクセスを不可能にすることにより、当該機能は保護されたコンテンツに移植性(portability)を与える。このように、そうした鍵で暗号化された保護コンテンツを含むストレージデバイスは、鍵へのアクセスに関して排他的制御を有しているので、機密保護違反の危険性を有することなく、様々なホストデバイスによるアクセスに使用することが可能となる。適切な証明書をもつホストデバイスのみが、鍵へアクセスできる。
【0006】
モバイルストレージメディアに保存されたコンテンツの商業価値を高めるために、コンテンツ中の所有権の所有者が、当該コンテンツへのアクセスに関して、様々なエンティティ(entity)に様々なパーミッション(permission)を与えることができることが望ましい。したがって、本発明の他の機能は、メディアに保存されたデータへのアクセスに関して、様々なパーミッションを(例えば、様々な認定エンティティに対して)与えるといったアクセスポリシー(access policy)を保存し得るという認識に基づいている。上記2つの機能の組み合わせを組み込むシステムは特に有益である。ひとつは、コンテンツ所有者または所有権者は、外部デバイスに実質的にアクセス不可能な鍵の使用によりコンテンツへのアクセスを管理する能力をもち、同時に、メディアのコンテンツをアクセスするためのパーミッションを与える能力をもつ。このように、外部デバイスがアクセスを獲得したとしても、それらのアクセスは、いまだストレージメディアに記録されたコンテンツの所有者または所有権者によって設定された様々なパーミッションに従い得る。
【0007】
他の機能は、様々な権限のあるエンティティに異なるパーミッションを与えるという上記ポリシーがフラッシュメモリで実行される場合、コンテンツ保護に特に有用なメディアをもたらすという認識に基づく。
【0008】
多くのコンピュータホストデバイスは、ファイル形式でデータの読み出しおよび書き込みを実行するが、多くのストレージデバイスはファイルシステムを認識しない。他の機能によれば、ホストデバイスはキーリファレンス(key reference)またはIDを提供し、これに応じてメモリシステムは、鍵ID(key ID)に関連する鍵値(key value)を生成し、ここで、鍵値は鍵IDに関連しているファイル中のデータを暗号処理する際に使用される。ホストは、鍵IDをメモリシステムによって暗号処理されるファイルと関連付ける。このように、ホストがファイルの制御を維持しつつ、鍵IDは、メモリが暗号プロセス用の鍵値の生成および使用に対して完全で排他的な制御を維持するハンドル(handle)として、コンピュータデバイスおよびメモリによって使用される。
【0009】
スマートカード等のモバイルストレージデバイスの中には、カードコントローラがファイルシステムを管理する。例えば、フラッシュメモリ、磁気ディスクまたは光ディスク等、多くの他の種類のモバイルストレージデバイスでは、デバイスコントローラがファイルシステムを認識しない。その代わりに、デバイスコントローラはファイルシステムを管理するために、ホストデバイス(例えば、パーソナルコンピュータ、デジタルカメラ、MP3プレーヤ、携帯情報端末、携帯電話)に依存している。本発明の様々な態様は、デバイスコントローラがファイルシステムを認識しないタイプのストレージデバイスに直ちに組み込むことが可能である。これは、本発明の様々な機能が、多種多様の既存のモバイルストレージデバイスにデバイスを再設計することなく、デバイスがファイルシステムを認識して管理するようにデバイスコントローラを作ることが実施し得ることを意味する。
【0010】
ストレージメディアに保存されたツリー構造は、エンティティがアクセスの獲得後でさえ実行可能な事柄に対して制御することを与えるものである。ツリーを構成する複数ノード(node)の各々は、当該ツリーのノードを通じたエントリ(entry)を獲得したエンティティによるパーミッションを特定する。ツリーの中には、異なるレベル(level)を有しているものもあり、この場合、ツリーのノードにおける一または複数のパーミッションが、同一ツリー内の高位レベル、低位レベル、または同一レベルとなる他のノードにおける一つまたは複数のパーミッションと所定の関係を有する。エンティティに対して、各ノードでこのように特定されたパーミッションに従うことを要求することにより、このアプリケーションのツリーの機能は、ツリーが異なるレベルを有しているか否かに関係なく、どのエンティティが動作可能で、且つ、各エンティティのどの動作が可能であるかについてコンテンツ所有者に制御することを可能とする。
【0011】
モバイルストレージメディアにより提供可能な商業価値を高めるために、モバイルストレージデバイスが複数のアプリケーションを同時にサポート可能であることが望ましい。2以上のアプリケーションがモバイルストレージデバイスに同時にアクセスする場合、当該アプリケーションが、ここでクロストーク(croostalk)と称す現象で相互干渉しないように、当該アプリケーションのオペレーションを分離可能であることが重要になる。したがって、本発明の他の機能は、好ましくは階層構造になっている2以上のツリーを、メモリへのアクセス制御に提供し得るという認識に基づく。各ツリーは、対応する複数のエンティティセットによるデータへのアクセスを制御するために、異なるレベルのノードを備えており、この場合、各ツリーのノードは、対応する一または複数のエンティティがメモリデータにアクセスするための一または複数のパーミッションを特定する。各ツリーのノードにおける一または複数のパーミッションが、同一ツリー内の高位レベルまたは低位レベルの他のノードにおける一または複数のパーミッションと所定の関係を有する。少なくとも、2つのツリー間でクロストークが存在しないことが好ましい。
【0012】
以上から、ツリーがコンテンツセキュリティに使用可能な強力な構造であることは明白である。提供される重要な制御の一つは、ツリー生成に対する制御である。このように、本発明に係る他の機能によれば、モバイルストレージデバイスは、対応するエンティティによりメモリ内に保存されたデータへのアクセス制御のために、異なるレベルのノードを備えた少なくとも一つの階層ツリーを生成可能なシステムエージェント(system agent)が備えられてもよい。ツリーの各ノードは、メモリデータへのアクセスのために、対応する一または複数のエンティティの一つ又は複数のパーミッションを特定する。各ツリーのノードにおける一または複数のパーミッションが、同一ツリー内の高位レベル、低位レベル、または同一レベルのノードでの一または複数のパーミッションと所定の関係を有する。このように、モバイルストレージデバイスは、デバイス購入者が自身の考えるアプリケーションに適用される階層ツリーを自由に生成できるように、既に生成された任意のツリーを使用することなく発行(issued)されてもよい。あるいは、モバイルストレージデバイスは、購入者が面倒なツリーの生成をする必要がないように、既に生成されたツリーを使用して発行されてもよい。両方の状況において、ツリーの所定の機能をさらに変更または修正できないように、デバイス製造後に当該機能を確定可能であることが好ましい。これは、コンテンツ所有者によるデバイス内のコンテンツへのアクセスに対して、さらなる制御を提供する。このように、一実施形態においては、追加のツリーを生成できないように、システムエージェントの無効化が可能であることが好ましい。
【0013】
モバイルストレージデバイスの中には、コンテンツ保護は、保護領域へのアクセスが事前認証を必要とする別々の領域にメモリを分割することにより得られるものがある。このような態様により、何らかの保護が提供されるのであるが、違法な手段でパスワードを取得したユーザから保護するものではない。このように、本発明の他の態様は、メカニズムまたは構造がメモリを複数のパーティションに分割するようにすることができて、少なくともパーティションにおけるデータの中には、鍵を用いて暗号化することが可能なものもあるという認識に基づくものであり、結果として、複数のパーティションの一部へのアクセスに必要な認証に加えて、一または複数の鍵へのアクセスがこうしたパーティションにおける暗号化データの復号に必要となる。
【0014】
幾つかのアプリケーションでは、ユーザが一つのアプリケーションを使用してメモリシステムにログインし、その後、再度ログインすることなく保護コンテンツにアクセスするために、異なるアプリケーションを使用可能であるという点が、さらに便利であるかもしれない。こうしたイベントでは、この方法でユーザがアクセスを望むコンテンツのすべてが、第1のアカウントに関連付けられ、結果として、複数回数のログインを必要とせず、異なるアプリケーション(例えば、音楽プレーヤ、Eメール、移動体通信等)を経由して、当該コンテンツにアクセス可能となるようにしてもよい。そして、異なる認証情報セットは、たとえ異なる複数アカウントが同一ユーザまたはエンティティに設定されている場合であっても、第1のアカウントとは異なるアカウントに存在する保護コンテンツにアクセスするためのログインに使用されてもよい。
【0015】
上記機能は、コンテンツ所有者に対する制御および/または保護のさらなる汎用性(versatility)を提供するためのストレージシステムにおいて、個別に使用し、または如何なるコンビネーションで組み合わせてもよい。
【特許文献1】米国特許第6457126号
【発明を実施するための最良の形態】
【0016】
本発明に関する様々な態様を実施し得るメモリシステムの一例が、図1のブロック図により例示されている。図1に図示されているように、メモリシステム10は、中央演算装置(CPU)12、バッファマネジメントユニット(buffer management unit;BMU)14、ホストインタフェイスモジュール(host interface module;HIM)16、フラッシュインタフェイスモジュール(flash interface module;FIM)18、フラッシュメモリ20およびペリフェラルアクセスモジュール(peripheral access Module;PAM)22を備える。メモリシステム10は、ホストインタフェイスバス26およびポート26aを介してホストデバイス24と通信する。フラッシュメモリ20(NAND型であってもよい)は、ホストデバイス24にデータストレージを提供する。CPU12用のソフトウェアコードもフラッシュメモリ20に保存されてもよい。FIM18は、フラッシュインタフェイスバス28およびポート28aを介してフラッシュメモリ20に接続する。HIM16は、例えば、デジタルカメラ、パーソナルコンピュータ、携帯情報端末(PDA)、デジタルメディアプレーヤ、MP3プレーヤ、携帯電話、その他のデジタルデバイス等のホストシステムへの接続に適している。ペリフェラルアクセスモジュール22は、例えば、CPU12と通信するためのFIM,HIMおよびBMU等の適切なコントローラモジュールを選択する。一実施形態においては、点線で示すボックス内のシステム10の全構成要素が、例えばメモリカードやスティック10’等の単一ユニットに含まれていてもよく、カプセル化されていることが好ましい。
【0017】
ここで、本発明はフラッシュメモリを参照することにより説明されているが、例えば磁気ディスクや光学式CD等の他のタイプのメモリだけでなく、あらゆるタイプの書き換え可能な不揮発性メモリシステムに適用してもよい。
【0018】
バッファマネジメントユニット14は、ホストダイレクトメモリアクセス(host direct memory access;HDMA)32、フラッシュダイレクトメモリアクセス(flash direct memory access;FDMA)34、アービタ(arbiter)36、バッファランダムアクセスメモリ(buffer random access memory;BRAM)38および暗号化エンジン(crypto−engine)40を備える。アービタ36は共有バスアービタであり、これにより、一つのマスタまたはイニシエータ(initiator;HDMA32、FDMA34またはCPU12がこれに該当し得る)のみが常時アクティブになることが可能である。また、スレーブまたはターゲットはBRAM38である。アービタは、適切なイニシエータ要求をBRAM38にチャネル接続させる役割を担う。HDMA32およびFDMA34は、HIM16、FIM18およびBRAM38またはCPUランダムアクセスメモリ(CPU random access memory;CPU RAM)12a間で伝送されたデータに対する役割を担う。HDMA32のオペレーションおよびFDMA34のオペレーションは従来から実施されているので、ここでは詳細な説明を省略する。BRAM38は、ホストデバイス24およびフラッシュメモリ20間で伝送されたデータを保存するために使用される。HDMA32およびFDMA34は、HIM16/FIM18およびBRAM38、またはCPU RAM12a間のデータ伝送、およびセクタ完了の表示に関する役割を担う。
【0019】
メモリシステム10は、メモリ20に保存されたコンテンツの安全性を向上させるために、暗号化および/または復号用に使用される(一または複数の)鍵値を生成し、ここでは、当該鍵値は、ホストデバイス24等の外部デバイスへのアクセスが実質的に不可能である。しかし、暗号化および復号は典型的にはファイル単位で実行されるが、これは、ホストデバイスがメモリシステム10に対してファイル形式でデータの読み出しおよび書き込みを実行するからである。多くの他の種類のストレージデバイスと同様に、メモリデバイス10はファイルまたはファイルシステムを認識しない。メモリ20はファイルの論理アドレスが識別されるファイルアロケーションテーブル(file allocation table;FAT)を保存するが、FATは、典型的にはコントローラ12ではなくホストデバイス24によってアクセスおよび管理される。したがって、特定ファイルのデータを暗号化するために、特定ファイルのデータはシステム10にのみ利用可能な(一または複数の)鍵値を使用するシステム10によって認識されて、暗号化および/または復号できるように、コントローラ12はメモリ20内のファイルのデータの論理アドレスを送信するために、ホストデバイスに依存しなければならない。
【0020】
ファイル内のデータを暗号処理する(一または複数の)同一鍵を参照するホストデバイス24およびメモリシステム10の両方にハンドルを提供するために、ホストデバイスは、システム10により生成された各々の鍵値に対して参照を提供し、ここでは、当該参照は単なる鍵IDとしてもよい。このように、ホスト24はシステム10により暗号化処理される各ファイルを鍵IDと関連付け、システム10はデータの暗号処理に使用される各鍵値をホストにより提供された鍵IDと関連付ける。このように、ホストがファイルの暗号化処理を要求する場合、ホストは、鍵IDと、メモリ20からフェッチされ、またはメモリ20に保存されるデータの論理アドレスと共に、当該要求をシステム10に送信する。システム10は鍵値を生成し、ホスト24により提供された鍵IDと当該値を関連付けて、暗号化プロセスを実行する。この方法では、メモリシステム10の動作方法に変更を加える必要はないが、システム10が(一または複数の)鍵値への排他的アクセスを含む(一または複数の)鍵を使用する暗号化処理を完全に制御することができる。即ち、FATの排他的制御により、システム10はホスト24のファイル管理を継続して可能にする。その一方で、システム10は暗号化処理に使用される(一または複数の)鍵値の生成および管理を行うために排他的制御を維持する。ホストデバイス24は、データの暗号処理に使用される(一または複数の)鍵値の生成および管理に一切関与しない。
【0021】
ホスト24により提供された鍵IDおよびメモリシステムにより生成された鍵値は、以下、実施形態の一つにおいて「コンテンツ暗号鍵(content encryption key)」またはCEKとして称される、数量に関する2つの属性を形成する。ホスト24は各鍵IDを一または複数のファイルと関連付けるが、ホスト24は、各鍵IDを整理されていないデータまたは何らかの方法で整理されたデータとも関連付けるものの、これは完全なファイルに整理されたデータに限定されない。
【0022】
ユーザまたはアプリケーションは、システム10における保護コンテンツまたは保護領域へのアクセスを獲得するために、システム10に事前登録された証明書を使用して認証を受ける必要がある。証明書(credential)とは、証明書を有する特定のユーザまたはアプリケーションに許可されるアクセス権限に関係するものである。事前登録プロセスにおいて、システム10はユーザまたはアプリケーションの身元(identity)および証明書の記録、およびユーザまたはアプリケーションにより決定され、ホスト24を通じて提供された当該身元および証明書と関連付けられたアクセス権限(access rights)を保存する。事前登録の完了後、ユーザまたはアプリケーションがメモリ20へのデータ書き込みを要求する場合、ホストデバイスを通じて、その身元および証明書、データ暗号化用の鍵IDおよび暗号化データが保存される論理アドレスを提供する必要がある。システム10は、鍵値を生成し、当該値をホストデバイスにより提供された鍵IDと関連付け、書き込まれるデータの暗号化に使用される鍵値に対応する鍵IDを当該ユーザまたはアプリケーションに関する記録またはテーブルに保存する。その後、システム10はデータを暗号化し、生成した鍵値だけでなく、暗号化データをホストにより指定されたアドレスに保存する。
【0023】
ユーザまたはアプリケーションがメモリ20からの暗号化データの読み出しを要求する場合、その身元および証明書と、要求されたデータを暗号化するために以前使用された鍵に対応する鍵IDと、暗号化データが保存される論理アドレスと、を提供する必要がある。その後、システム10はホストにより提供されたユーザまたはアプリケーションの身元および証明書と、その記録内に保存された身元および証明書と、を照合する。両者が一致した場合、システム10は、ユーザまたはアプリケーションにより提供された鍵IDに関連付けられた鍵値をメモリからフェッチし、鍵値を使用して、ホストデバイスにより指定されたアドレスに保存されたデータを復号し、復号されたデータをユーザまたはアプリケーションに送信する。
【0024】
認証証明書を暗号化処理に使用される鍵の管理と分離することにより、証明書を共有することなくデータへのアクセス権限を共有することが可能となる。このように、異なる証明書を有するユーザグループまたはアプリケーショングループは、同一データにアクセスするための同一鍵へのアクセスを有することが可能であるが、当該グループ以外のユーザはアクセスすることができない。グループ内のすべてのユーザまたはアプリケーションは、同一データへのアクセスを有することが可能であるが、当該ユーザまたはアプリケーションは異なる権利を有する。このように、ユーザまたはアプリケーションの中に、読み出しのみのアクセスを有する者があってもよく、それ以外のユーザまたはアプリケーションが書き込みのみのアクセスを有しても良く、その他のユーザまたはアプリケーションが両方のアクセスを有してもよい。システム10は、ユーザまたはアプリケーションの身元および証明書の記録、ユーザまたはアプリケーションがアクセスする鍵ID、および各鍵IDに対する関連付けられたアクセス権限を維持するので、システム10は、鍵IDの追加または削除、および特定のユーザまたはアプリケーション用の当該鍵IDに関連付けられたアクセス権限の変更、あるユーザまたはアプリケーションから他のユーザまたはアプリケーションへのアクセス権限の委譲、複数ユーザまたはアプリケーション用の記録またはテーブルの削除または追加までも実行することが可能となり、これらすべてが適切に認証されたホストデバイスにより制御される。保存された記録は、セキュアチャネル(secure channel)が所定の鍵へのアクセスに必要であることを特定してもよい。認証は、パスワードだけでなく、対称アルゴリズム(symmetric algorithm)または非対称アルゴリズム(asymmetric algorithm)を使用して実行されてもよい。
【0025】
特に重要なのは、メモリシステム10における保護されたコンテンツ(secured content)の移植性である。鍵値はメモリシステムにより生成され、実質的に外部システムには利用できないので、メモリシステムまたは当該システムを組み込んでいるストレージデバイスが、ある外部システムから他の外部システムに伝送される場合、そこに保存されたコンテンツの安全性が維持され、外部システムは、メモリシステムに完全制御された方法で認証を受けない限り、当該コンテンツにアクセスすることができない。こうした認証後でさえ、アクセスはメモリシステムにより完全制御され、外部システムはメモリシステムに事前設定された記録に応じて制御される方法でのみアクセス可能である。要求は、そうした記録と適合しない場合には拒否される。
【0026】
コンテンツ保護をさらに柔軟にするために、以下パーティション(partition)と称すメモリの所定の領域が適切に認証されたユーザまたはアプリケーションによってのみアクセス可能であることが想定される。上記の鍵ベースのデータ暗号化の特性を組み合わせた場合、システム10は優れたデータ保護機能を提供する。図2に示されるように、フラッシュメモリ20は多くのパーティション、即ち、ユーザ領域(user area)またはユーザパーティション(user partition)、およびカスタムパーティション(custom partition)、に分割されたストレージ容量を有してもよい。ユーザ領域またはパーティションP0は、認証なしですべてのユーザおよびアプリケーションによるアクセスが可能である。ユーザ領域に保存されたデータのすべてのビット値(bit value)は、任意のアプリケーションまたはユーザによって読み出しまたは書き込みが可能であるが、データの読み出しが暗号化される場合、復号パーミッションを有していないユーザまたはアプリケーションは、ユーザ領域に保存されたビット値で表現された情報にアクセスすることはできないことになる。例えば、これはユーザエリアP0に保存されたファイル102および104により説明されている。例えば、すべてのアプリケーションおよびユーザにより読み出しおよび理解が可能なファイル106等の暗号化されていないファイルもユーザ領域に保存されている。このように、暗号化されるファイルは、例えばファイル102および104のように、当該ファイルに関連付けられた錠前と共に象徴的に示されている。
【0027】
ユーザ領域P0における暗号化ファイルは、非許可のアプリケーションまたはユーザには理解することができないが、そのアプリケーションまたはユーザが、一部のアプリケーションにとって望ましくない可能性のあるファイルを削除または破壊することが可能であってもよい。また、この目的のために、メモリ20は事前認証なしでアクセス不可能な、例えばパーティションP1およびP2等の保護されたカスタムパーティションを備える。以下、本出願に係る複数の実施形態で可能となる認証プロセスについて説明する。
【0028】
図2に示されるように、様々なユーザまたはアプリケーションがメモリ20内のファイルにアクセスしてもよい。このように、図2には、ユーザ1乃至2および(デバイスで実行する)アプリケーション1乃至4が示されている。こうしたエンティティは、メモリ20の保護コンテンツへのアクセスを許可される前に、第一に以下で説明する方法の認証プロセスで認証される。当該プロセスでは、アクセスを要求するエンティティは、ロールベースアクセスコントロール(role based access control)を行うために、ホスト側で認証される必要がある。このように、アクセスを要求するエンティティは、第一に、例えば「こちらアプリケーション2、ファイル1を読み出せ」等の情報を提供することにより、身元を示す。そして、コントローラ12は、身元、認証情報および要求をメモリ20またはコントローラ12に保存された記録と照合する。すべての要求が満たされた場合、当該エンティティにアクセスが許可される。図2に示すように、ユーザ1はP0のファイル106に対する読み出しおよび書き込みに関して無制限の権利を有していることに加え、パーティションP1のファイル101に対する読み出しおよび書き込みを許可されているが、ファイル102および104に対しては読み出しのみが可能である。一方、ユーザ2はファイル101および104に対するアクセスを許可されていないが、ファイル102に対する読み出しおよび書き込みアクセスを有する。図2で示すように、ユーザ1および2は同一のログインアルゴリズム(AES)を有しているが、アプリケーション1および3は異なるログインアルゴリズム(例えば、RSAおよび001001)を有し、ここで、当該異なるログインアルゴリズムは、ユーザ1および2のログインアルゴリズムとも異なる。
【0029】
セキュアストレージアプリケーション(SSA)はメモリシステム10のセキュリティアプリケーションで、本発明の一実施形態を説明するものである。当該アプリケーションは上記機能の多くを実施するために使用可能である。SSAはメモリ20またはCPU12の不揮発性メモリ(不図示)に保存されたデータベースを有するソフトウェアまたはコンピュータコードとして具現化することができ、RAM12aに読み込まれ、CPU12により実行される。
SSAを参照して使用される略語(acronyms)は、以下のテーブルで説明される。

【0030】
《SSAシステム記述》
データの安全性(security)、完全性(integrity)およびアクセス制御がSSAの主要な役割である。データは、本来、何らかの大容量記憶装置に単純に保存されるファイルである。SSAシステムはストレージシステム内に位置し、保存されたホストファイルに対してセキュリティレイヤ(security layer)を追加する。
【0031】
SSAの主なタスクは、メモリに保存された(そして保護された)コンテンツに関連付けられた異なる権利を管理することにある。メモリアプリケーションは、複数のユーザおよび複数の保存コンテンツに対応するコンテンツ権を管理する必要がある。ホストアプリケーションは、ホストアプリケーション側から、こうしたアプリケーションが視認可能なドライブおよびパーティションと、ストレージデバイスに保存されたファイルの位置を管理および表現するファイルアロケーションテーブル(FAT)と、を確認する。
【0032】
この場合、ストレージデバイスはパーティションに分割されたNANDフラッシュチップ(NAND flash chip)を使用するが、ここで他のモバイルストレージデバイスを使用してもよく、当該デバイスは本発明の範囲内に属するものである。これらのパーティションは論理アドレスの連続スレッドであり、ここでは「開始(start)」アドレスおよび「終了(end)」アドレスがパーティションの境界を画定する。したがって、必要に応じて、ソフトウェア(例えば、メモリ20に保存されたソフトウェア)により隠しパーティション(hidden partition)へのアクセスに制限を加えてもよいが、当該ソフトウェアは、こうした制限を境界内のアドレスと関連付ける。パーティションは、SSAの管理するパーティションの論理アドレス境界により、SSAが完全に認識可能である。SSAシステムは、権限のないホストアプリケーションから物理的にデータを保護するためにパーティションを使用する。ホストに対しては、パーティションはデータファイルを保存するための所有権空間を定義するメカニズムである。これらのパーティションは、ストレージデバイスへのアクセスを有する者であればデバイス上のパーティションの存在を確認し、認識することが可能であるという点で公的(public)であると言える。また、選択されたホストアプリケーションのみがストレージデバイス上でのパーティションへのアクセスを有し、その存在を認識するという点で私的(private)であると言える。
【0033】
図3は、メモリのパーティション、即ち、P0、P1、P2およびP3(4つ未満または4つを超えるパーティションを採用してもよいことは明白である)を説明するメモリの概略図であり、ここで、P0は認証なしで任意のエンティティがアクセス可能なパブリックパーティション(public partition)である。
【0034】
(例えば、P1、P2、またはP3の)プライベートパーティション(private partition)は、その範囲内にファイルへのアクセスを隠している。ホストによるパーティションへのアクセスを妨げることにより、フラッシュデバイス(例えば、フラッシュカード)はパーティション内のデータファイルの保護を実現する。しかし、この種の保護は、パーティション内の論理アドレスに保存されたデータへのアクセスに制限を課すことによって、隠しパーティションに存在するすべてのファイルを対象とする。即ち、当該制限は論理アドレスの範囲に関連付けられている。当該パーティションへのアクセスを有する「ユーザ/ホスト」のすべては、内部のすべてのファイルに対して無制限のアクセスを有する。異なるファイルまたはファイルグループを互いに分離するために、SSAシステムは鍵およびキーリファレンス、または鍵IDを使用して、ファイル単位またはファイルグループ単位で他のレベルの安全性および完全性を提供する。異なるメモリアドレスでデータを暗号化するために使用される特定の鍵値に関するキーリファレンスまたは鍵IDは、暗号化データを含むコンテナ(container)またはドメイン(domain)に類推することができる。こうした理由により、図4においては、キーリファレンスまたは鍵ID(例えば、「鍵1」および「鍵2」)が鍵IDに関連付けられた鍵値を使用して暗号化されたファイルの周辺領域として図示されている。
【0035】
例えば、図4を参照すると、ファイルAは鍵IDで囲まれていないので、認証なしですべてのエンティティがアクセス可能である。パブリックパーティションのファイルBは、すべてのエンティティが読み出しおよび上書き可能であるが、ファイルBはID「鍵1」を有する鍵で暗号化されたデータを含む。したがって、ファイルBに含まれる情報については、鍵へのアクセスを有していない限り、エンティティがアクセスすることはできない。この方法では、鍵値およびキーリファレンス、または鍵IDの使用により、論理保護のみが提供される。これは、上述のパーティションにより提供された種類の保護とは相反する。従って、(パブリックまたはプライベート)パーティションにアクセス可能な任意のホストは、暗号化データを含むパーティション全体のデータの読み出しおよび書き込みが可能である。しかし、データが暗号化されているので、権限のないユーザはデータを破壊することしかできない。権限のないユーザは、検出なしでデータを変更することや、データを使用することができないことが好ましい。暗号鍵および/または復号鍵へのアクセスを制限することにより、この機能は、権限のあるエンティティのみに対してデータの使用を可能にする。また、ファイルBおよびCは、P0の鍵ID「鍵2」を有する鍵を使用して暗号化されている。
【0036】
データの機密性(confidentiality)および完全性は、コンテンツ暗号鍵(Content Encryption Keys;CEK)を使用する対称暗号法を通じて、各CEKに対して提供可能である。SSA実施形態において、CEKはフラッシュデバイス(例えば、フラッシュカード)により生成され、内部でのみ使用され、外部からは秘密にされる。また、暗号化(encrypted or ciphered)されたデータは、ハッシュ化(hashed)されてもよく、データの完全性を確実にするために、暗号がチェーンブロックされてもよい。
【0037】
必ずしもパーティションのすべてのデータが異なる鍵で暗号化され、異なる鍵IDに関連付けられる訳ではない。パブリックファイルまたはユーザファイルの所定の論理アドレス、またはオペレーティングシステム領域(即ちFAT)の所定の論理アドレスは、任意の鍵またはキーリファレンスと関連付けられなくてもよく、これにより、パーティション自体にアクセス可能な任意のエンティティによって利用可能となる。
【0038】
鍵およびパーティションの生成能力に加えて、それらのデータの書き込みおよび読み出し、または鍵の使用に関する能力を必要とするエンティティは、アクセス制御記録(Access Control Record;ACR)を通じてSSAシステムにログインすることが必要である。SSAシステムのACRの権限は「アクション(Actions)」と呼ばれる。各ACRは以下3つのカテゴリのアクション、即ち、パーティションおよび鍵/鍵IDの生成、パーティションおよび鍵へのアクセス、および他のACRの生成/更新、の3つのカテゴリのアクションを実行する「パーミッション(Permissions)」を有してもよい。
【0039】
ACRはACRグループまたはAGPと呼ばれるグループに整理される。ACRの認証に一旦成功すれば、SSAシステムはACRのアクションの何れかを実行可能な「セッション」(Session)を開始する。
【0040】
《ユーザパーティション(一または複数)》
SSAは一または複数のパブリックパーティションを管理し、これをユーザパーティション(一または複数の)と称すこともある。当該パーティションはストレージデバイスに存在し、ストレージデバイスの標準的な読み出しおよび書き込みコマンドによりアクセス可能な一または複数のパーティションである。デバイスにおけるパーティションの存在だけでなく、パーティション(一または複数の)のサイズに関する情報の取得は、ホストシステムから隠蔽不可能であることが好ましい。
【0041】
SSAシステムは、標準的な読み出しおよび書き込みコマンド、またはSSAコマンドの何れかにより当該パーティションにアクセス可能である。したがって、パーティションへのアクセスを特定ACRに制限できないことが好ましい。しかし、SSAシステムにより、ホストデバイスはユーザパーティションへのアクセス制限を有効にすることが可能である。読み書きアクセスは、個別に有効/無効にすることができる。4つの組み合わせすべて(例えば、書き込みのみ、読み出しのみ(書き込み禁止)、読み書き、アクセス不可)が可能である。
【0042】
SSAシステムにより、ACRは鍵IDをユーザパーティション内のファイルと関連付け、そうした鍵IDと関連付けられた鍵を使用して、個々のファイルを暗号化することが可能である。パーティションへのアクセス権限の設定だけでなく、ユーザパーティション内の暗号化ファイルへのアクセスは、SSAコマンドセットを使用して実行される(SSAコマンドの詳細な記述に関する付録Aを参照。当該付録では、鍵IDを「ドメイン」と称す)。また、上述の機能はファイルに整理されていないデータに適用する。
【0043】
《SSAパーティション》
これらは(ホストオペレーティングシステムまたはOSから)隠されたパーティションであり、SSAコマンドを通じてのみアクセス可能である。SSAシステムによって、ホストデバイスがACRにログインすることにより確立される(以下に示す)セッションを介すことなくSSAパーティションにアクセスすることができないことが好ましい。同様に、確立されたセッションを通じて当該要求がなされない限り、SSAはSSAパーティションの存在、サイズおよびアクセス許可に関する情報を提供しないことが好ましい。
【0044】
パーティションへのアクセス権限はACRパーミッションに基づいている。ACRは、SSAシステムに一旦ログインすると、パーティションを(以下に示す)他のACRと共有することができる。パーティションの生成時に、ホストは参照名またはID(例えば、図3および4のP0乃至P3)をパーティションに供給する。当該参照はパーティションに対するさらなる読み出しおよび書き込みコマンドで使用される。
【0045】
《ストレージデバイスのパーティション化》
デバイスの利用可能なストレージ容量のすべてが、ユーザパーティションおよび現段階で設定されたSSAパーティションに割り当てられることが好ましい。したがって、任意の再パーティションオペレーション(repartition operation)は既存のパーティションの再設定を含んでも良い。デバイス容量(全パーティションの合計サイズ)に対する純変化(net change)はゼロになる。デバイスメモリ空間におけるパーティションのIDは、ホストシステムにより定義される。
【0046】
ホストシステムは、既存のパーティションの一つを二つのより小さなパーティションに再パーティション化する、または(隣接してもよいし、隣接しなくてもよい)二つの既存のパーティションを一つのパーティションに結合することが可能である。分割パーティションまたは結合パーティションのデータは、ホストの裁量で消去可能であるし、そのままの状態にすることも可能である。
【0047】
ストレージデバイスの再パーティション化は、(ストレージデバイスの論理アドレス空間におけるデータの消去または移動が原因で)データ損失を引き起し得るので、SSAシステムにより、再パーティション化の実行に厳重な制限が課される。(以下に示す)ルートAGPに存在するACRのみが再パーティションコマンドの発行を許可され、それが所有するパーティションを参照することのみ可能である。SSAシステムは、データが如何にしてパーティション(FATまたは他のファイルシステム構造)に整理されるのかを認識しないので、デバイスが再パーティション化される場合は常に、こうした構造を再構築するのはホストの責任となる。
【0048】
ホストOSによって確認されながら、当該パーティションのサイズおよび他の属性は、ユーザパーティションの再パーティション化により変更される。
【0049】
再パーティション化の実行後、SSAシステムの任意のACRが実在しないパーティションを参照しないことを確認するのは、ホストシステムの責任である。こうしたACRが適切に削除または更新されない場合、こうしたACRに代わって、実在しないパーティションにアクセスする以後の試みはシステムにより削除および拒否される。削除された鍵および鍵IDに関しても、同様の配慮がなされる。
【0050】
《鍵、鍵IDおよび論理保護》
ファイルが所定の隠しパーティションに書き込まれる場合、当該ファイルは不特定多数者から隠される。しかし、(敵意があるか否かは別として)一旦あるエンティティが当該パーティションに関する知識およびアクセスを取得すると、ファイルは利用可能で視認容易なものになる。ファイルをさらに保護するために、SSAは隠しパーティションでファイルを暗号化することができる。この場合、ファイルを復号するための鍵へのアクセスに関する証明書は、パーティションへのアクセスに関する証明書と異なることが好ましい。ファイルは(ホストにより完全に制御および管理され)SSAが認識するものではないという事実を考慮すると、CEKをファイルと関連付けることには問題がある。ファイルをSSAが応答する何らかのもの(例えば、鍵ID)とリンクすることによりこれを修正する。このように、SSAにより鍵が生成される場合、ホストはSSAにより生成された鍵を使用して、当該鍵に関する鍵IDを暗号化データと関連付ける。
【0051】
鍵値および鍵IDは論理的セキュリティ(logical security)を提供する。所定の鍵IDに関連づけられたすべてのデータは、その位置にかかわらず、ホストアプリケーションにより生成時に一意的に参照名または鍵IDを与えられた同一のコンテンツ暗号鍵(CEK)を用いて暗号化される。エンティティが(ACRを通じた認証により)隠しパーティションへのアクセスを獲得し、当該パーティション内の暗号化ファイルの読み出しまたは書き込みの実行を望む場合、ファイルに関連付けられた鍵IDへのアクセスを有する必要がある。SSAは、当該鍵IDに対応する鍵へのアクセスを許可する場合、当該鍵IDに関連付けられたCEKの鍵値をロードし、ホストへのデータ送信前にこれを復号する、または、フラッシュメモリ20へのデータ書き込み前にこれを暗号化する。鍵IDに関連付けられたCEKの鍵値は、SSAシステムにより一旦ランダムに生成され、維持される。SSAシステムの外部でCEKの当該鍵値に関する知識またはアクセスを有するものはいない。外部では、CEKの鍵値ではなく、参照または鍵IDが提供される、または使用されるだけである。鍵値はSSAにより完全に管理され、SSAのみがアクセス可能である。
【0052】
SSAシステムは、以下の暗号モードの内(ユーザが定義した)任意のモードを使用して、鍵IDに関連付けられたデータを保護する(なお、CEKの鍵値だけでなく、使用される実際の暗号アルゴリズムは、システム制御され、外部に漏れることはない):
【0053】
《ブロックモード(Block mode)》
データがブロックに分割され、各ブロックは個別に暗号化される。
このモードは一般的に安全性がそれほど高くなく、辞書攻撃を受けやすいと考えられている。しかし、このモードでは、ユーザがデータブロック(data blocks)の任意のブロックにランダムにアクセス可能である。
【0054】
《連鎖モード(Chained mode)》
データがブロックに分割され、暗号化プロセス中にブロックがチェーン化される。
各ブロックは、次のブロックの暗号化プロセスに対するインプットの一つとして使用される。このモードはより安全性が高いと考えられているが、データの書き込みおよび読み出しが常に開始から終了まで順に実行されることを必要とし、ユーザが必ずしも受け入れ可能ではないオーバーヘッド(overhead)を生成する。
【0055】
《ハッシュモード(Hashed)》
データの完全性の確認に使用可能なデータダイジェスト(data digest)の付加生成を伴う連鎖モードである。
【0056】
《ACRおよびアクセス制御》
SSAは複数アプリケーションを処理するように設計されており、各アプリケーションはシステムデータベースにおいて、ノードからなるツリーとして表現される。アプリケーション間の相互排除は、ツリーのブランチ(branch)間でクロストークを確実に発生しないようにすることにより達成される。
【0057】
SSAシステムへのアクセスを獲得するために、エンティティはシステムのACRの一つを経由して接続を確立する必要がある。ログイン手順は、ユーザが接続を選択したACRに組み込まれた定義に応じて、SSAシステムにより実行される。
【0058】
ACRはSSAシステムへの個別のログインポイントである。ACRはログイン証明書および認証方法を有する。また、SSAシステム内のログインパーミッションが当該記録に属しており、その中には読み出しおよび書き込み権限がある。これは図5において説明されており、同図では同一AGPにおいてn個のACRが図示されている。これは、n個のACRの内、少なくとも幾つかは同一鍵へのアクセスを共有し得ることを意味する。このように、ACR#1およびACR#nは、鍵ID「鍵3」を有する鍵へのアクセスを共有しているが、ここで、ACR#1およびACR#nはACRのIDであり、「鍵3」は「鍵3」に関連付けられたデータの暗号化に使用される鍵に対応する鍵IDである。また、同一鍵は複数ファイルまたは複数のデータを暗号化および/または復号するために使用可能である。
【0059】
SSAシステムはシステムへの幾つかの種類のログイン形式をサポートしているが、ここで、ユーザが一旦ログインに成功すれば、システムにおけるユーザの権限が変化するように、認証アルゴリズムおよびユーザ証明書が変化してもよい。さらに、図5は異なるログインアルゴリズムおよび証明書を説明している。ACR#1はパスワードログインアルゴリズムおよび証明書としてのパスワードを必要とする。一方、ACR#2はPKI(公開鍵基盤;public key infrastructure)ログインアルゴリズムおよび証明書としての公開鍵を必要とする。このように、ログインするために、エンティティは正しいログインアルゴリズムおよび証明書だけでなく、有効なACRのIDを提示する必要がある。
【0060】
エンティティが一旦SSAシステムのACRにログインすると、パーミッション、即ち、SSAコマンドの使用権は、ACRに関連付けられたパーミッション制御記録(Permissions Control Record;PCR)において定義される。図5において、ACR#1は「鍵3」と関連付けられたデータに対して読み出しのみのパーミッションを認め、ACR#2は示されたPCRに応じて、「鍵5」と関連付けられたデータの読み出しおよび書き込みのパーミッションを認める。
【0061】
異なるACRはシステム、例えば、読み出しおよび書き込みに関連付けられた鍵等、において共通の所有権および権限を共有してもよい。これを達成するために、何らかの共通するものを有するACRは、AGPにグループ化、即ち、ACRグループにグループ化される。このように、ACR#1およびACR#nは、鍵ID「鍵3」を有する鍵へのアクセスを共有する。
【0062】
機密データの安全性を保つセキュア鍵の生成は別として、AGPおよびその中のACRは、階層ツリーに整理される。すなわち、ACRは、鍵ID/パーティションに対応する他のACRエントリを生成可能であることが好ましい。これらの子ACR(ACR children)は、親(father)即ちクリエータ(creator)と同一のパーミッションまたは限られたパーミッションを有しており、親ACR自身が生成した鍵へのパーミッションが与えられても良い。言うまでもなく、子ACRは生成する任意の鍵へのアクセスパーミッションを得る。これは図6において説明されている。このように、AGP120におけるすべてのACRは、ACR122により生成され、当該ACRの2つはACR122から「鍵3」と関連付けられたデータへのアクセスパーミッションを引き継いでいる。
【0063】
《AGP》
SSAシステムへのログインは、AGPおよびAGP内のACRを特定することにより実行される。
【0064】
各AGPには固有のID(参照名)があり、当該IDはSSAデータベースへのエントリ用のインデックスとして使用される。AGPの生成時に、AGP名がSSAシステムに供給される。供給されたAGP名が当該システムにおいて既に存在する場合、SSAは生成オペレーションを拒否する。
【0065】
以下のセクションで記載するように、AGPはアクセスおよび管理パーミッションの委譲に制限を課すために使用される。図6の2つのツリーが果たす機能の一つは、例えば2つの異なるアプリケーションまたは2つの異なるコンピュータユーザ等、エンティティを完全に分離することによってアクセスを与えることである。当該目的のためには、2つのアクセスプロセスが同時に発生するとしても、実質的に互いに独立する(即ち、実質的にクロストークがない)ことが重要となり得る。これは、各ツリーにおけるACRおよびAGPのさらなる生成だけでなく、認証およびパーミッションも、他のツリーのそれらと接続されておらず、それらに依存しないことを意味する。したがって、SSAシステムがメモリ10で使用される場合、これによりメモリシステム10が複数のアプリケーションを同時に扱うことができる。また、これにより、2つのアプリケーションが互いに独立する2つの個別のデータ(例えば、複数の写真からなる写真一組および複数の歌曲からなる歌曲一組)にアクセスすることができる。これは図6において説明されている。このように、アプリケーションまたはユーザが図6の上部のツリーにおけるノード(ACR)を経由してアクセスする「鍵3」、「鍵X」および「鍵Z」に関連付けられたデータが複数の写真を含んでもよい。アプリケーションまたはユーザが図6の下部のツリーのノード(ACR)を経由してアクセスする「鍵5」および「鍵Y」に関連付けられたデータが複数の歌曲を含んでもよい。AGPを生成したACRは、当該AGPにACRエントリが存在しない場合にのみ、これを削除するパーミッションを有する。
【0066】
《エンティティのSSAエントリポイント:アクセス制御記録(ACR)》
SSAシステムにおけるACRは、エンティティがシステムにログインパーミッションされる方法を記載している。エンティティは、SSAシステムにログインする場合、実行しようとする認証プロセスに対応するACRを特定する必要がある。ACRはパーミッション制御記録(PCR)を含み、当該PCRは、図5で説明されACRに定義されているように、一旦認証されるとユーザが実施可能なパーミッションされたアクションを説明している。ホスト側のエンティティは、ACRデータフィールドのすべてを供給する。
【0067】
エンティティのACRへのログインが成功した場合、エンティティはACRのパーティション、鍵アクセスパーミッションおよび(以下で説明する)ACAMパーミッションのすべてにクエリを行うことが可能となる。
【0068】
《ACRのID》
SSAシステムのエンティティがログインプロセスを開始した場合、当該エンティティは(ACRの生成時にホストにより提供されるように)ログイン方法に対応するACRのIDを特定する必要がある。この結果、すべてのログイン要件が満たされた場合、SSAは正しいアルゴリズムをセットアップし、正しいPCRを選択する。ACRの生成時に、ACRのIDがSSAに供給される。
【0069】
《ログイン/認証アルゴリズム》
認証アルゴリズムは、エンティティにより使用されるログイン手順の種類、およびユーザの身元の証拠を提供するのに必要となる証明書の種類を特定する。SSAシステムは幾つかの標準的なログインアルゴリズムをサポートしており、当該アルゴリズムは、手順なし(および証明書なし)およびパスワードベースの手順から、対称暗号化または非対称暗号化の何れかに基づく2方向認証プロトコルに及ぶ。
【0070】
《証明書》
エンティティの証明書は、ログインアルゴリズムに対応し、ユーザの照合および認証を行うためにSSAにより使用される。証明書の例としては、パスワード認証用のパスワード/PIN番号、AES認証用のAES鍵等を挙げることができる。証明書(即ち、PIN、対称鍵等)の種類/フォーマットは、事前に定義されており、認証モードに基づいている。即ち、それらはACRの生成時にSSAに供給される。SSAシステムは、PKIベースの認証に関する例外はあるものの、こうした証明書の定義、分配および管理とは関係なく、PKIベースの認証では、RSA鍵ペアを生成するためにデバイス(例えば、フラッシュカード)を使用可能であり、証明書の生成に対して公開鍵をエクスポート可能である。
【0071】
《パーミッション制御記録(PCR)》
PCRは、SSAシステムにログインし、ACRの認証プロセスの通過に成功した後、エンティティに対して何が許可されるのかを示している。3タイプのパーミッションカテゴリ、即ち、パーティションおよび鍵に関する生成パーミッション、パーティションおよび鍵へのアクセスパーミッション、およびエンティティ・ACR属性の管理パーミッションが存在する。
【0072】
《パーティションへのアクセス》
PCRに関する当該セクションは、ACR段階を首尾良く完了した場合にエンティティがアクセス可能な(SSAシステムに提供されているようにIDを使用する)パーティションのリストを含む。各パーティションのアクセスの種類は、書き込みのみ、または読み出しのみに制限されてもよいし、書き込み/読み出しのフルアクセス権限を指定してもよい。このように、図5のACR#1は、パーティション#1ではなく、パーティション#2へのアクセスを有している。PCRで特定される制約は、SSAパーティションおよびパブリックパーティションに適用する。
【0073】
パブリックパーティションは、SSAシステムをホスティングするデバイス(例えば、フラッシュカード)に対する正規の読み出しおよび書き込みコマンド、または、SSAコマンドの何れかによりアクセス可能である。(以下で説明する)ルートACRがパブリックパーティションを制限するパーミッションを用いて生成される場合、当該ACRはそれを子に伝えることが可能である。ACRは、正規の読み出しおよび書き込みコマンドがパブリックパーティションにアクセスしないように制限することのみ可能であることが好ましい。SSAシステムにおけるACRは、生成に対してのみ制限可能であることが好ましい。ACRが一旦パブリックパーティションに対する読み出しおよび書き込みに関するパーミッションを有すると、当該パーミッションを取り消しできないことが好ましい。
【0074】
《鍵IDへのアクセス》
PCRに関する当該セクションは、ACRポリシーがエンティティのログインプロセスにより満たされた場合、(ホストによりSSAシステムに供給されるように)エンティティがアクセス可能な鍵IDのリストに関連付けられたデータを含む。指定された鍵IDは、PCRに登場するパーティションに存在する一または複数のファイルに関連付けられる。鍵IDはデバイス(例えば、フラッシュカード)の論理アドレスに関連付けられていないので、複数のパーティションが特定ACRと関連付けられる場合、ファイルはパーティションの何れか一つに存在することが可能である。PCRで指定された複数の鍵IDは、それぞれ異なるセットの複数のアクセス権限を有することができる。鍵IDにより指令されたデータへのアクセスは、書き込みのみ、または読み出しのみに限定することが可能であり、または書き込み/読み出しのフルアクセス権限を指定しても良い。
【0075】
《ACR属性管理(ACR Attributes Management;ACAM)》
このセクションは、ACRのシステム属性が特定の状況で如何に変化し得るかを記載している。
【0076】
SSAシステムにおいて許可し得るACAMアクションは、以下の通りである:
【0077】
AGPおよびACRの生成/削除/更新
【0078】
パーティションおよび鍵の生成/削除
【0079】
鍵およびパーティションへのアクセス権限の委譲
【0080】
親ACRはACAMパーミッションを編集できないことが望ましい。これは、望ましくはACRの削除および作り直しを必要とする。また、ACRにより生成された鍵IDへのアクセスパーミッションを取り除くことはできないことが望ましい。
【0081】
AGPおよびACRの生成/削除/更新
【0082】
ACRは、他のACRおよびAGPを生成する能力を有しても良い。また、ACRの生成は、クリエータが所有するACAMパーミッションの一部またはすべてを生成するACRに委譲することを意味してもよい。ACRの生成パーミッションを有することは、以下のアクションに対するパーミッションを有することを意味する:
1.子の証明書の定義および編集、即ち、認証方法は、生成ACRにより一旦設定されると、編集できないことが好ましい。証明書は既に子に対して定義されている認証アルゴリズムの境界内で変更されてもよい。
2.ACRの削除
3.子ACRへの生成権の委譲(これにより子ACRは孫(groundchildren)を有す)
【0083】
他のACRの生成パーミッションを有するACRは、(恐らくACRをブロック解除するパーミッションを有していないが)当該ACRが生成するACRに対してブロック解除するパーミッションを委譲するパーミッションを有する。親ACRは自身の非ブロッカーへの参照を子ACRに設置する。
【0084】
親ACRは自身の子ACRを削除するパーミッションを有する唯一のACRである。ACRが自身の生成した低位レベルのACRを削除する場合、自動的に当該低位レベルのACRにより生み出されたすべてのACRも同様に削除される。ACRが削除される場合、それが生成したすべての鍵IDおよびパーティションが削除される。
【0085】
下記の通り、ACRが自身の記録を更新可能な2つの例外が存在する。
【0086】
パスワード/PINは、クリエータACRにより設定されているのだが、それらを含むACRによってのみ更新可能である。
【0087】
ルートACRは自身およびそれが存在するAGPを削除してもよい。
【0088】
《鍵およびパーティションへのアクセス権限の委譲》
ACRおよびそれらのAGPは、階層ツリーにまとめられる。当該階層ツリーでは、ルートAGPおよびその中のACRがツリーの先端部に位置する(例えば、図6のルートAGP130および132)。SSAシステムにはいくつかのAGPツリーが存在しており、それらは互いに完全に分離している。AGP内のACRは、自身が存在する同一AGP内のすべてのACR、およびそれらが生成したすべてのACRに対して、鍵へのアクセスパーミッションを委譲することができる。鍵の生成パーミッションは、鍵を使用するためのアクセスパーミッションを委譲するパーミッションを含むことが好ましい。
鍵へのパーミッションは以下の3つのカテゴリに分割される。
1.アクセス(これは鍵に対するアクセスパーミッション、即ち、読み出し、書き込みを定義する)
2.所有権(鍵を生成したACRが明らかにその所有者となる) 当該所有権は、(ACRが同一AGPまたは子AGPに存在するという条件で)あるACRから他のACRに委譲される。鍵の所有権は、他のACRにパーミッションを委譲するだけでなく、それを削除するパーミッションを与える。
3.アクセス権限の委譲(このパーミッションにより、ACRは自身が保有する権利を委譲可能となる)
【0089】
ACRは、自身がアクセス権限を有する他のパーティションだけでなく、自身が生成したパーティションへのアクセス権限を委譲することが可能である。
【0090】
パーミッションの委譲は、指定されたACRのPCRにパーティションおよび鍵ID名を追加することにより実行される。鍵へのアクセスパーミッションの委譲は、鍵IDによるものであってもよいし、アクセスパーミッションが委譲するACRのすべての生成された鍵に対するパーミッションであるという主張によるものであってもよい。
【0091】
《ACRのブロックおよびブロック解除》
ACRは、システムとのエンティティのACR認証プロセスに失敗した場合にインクリメントするブロッキングカウンタ(blocking counter)を有しても良い。認証の失敗回数が所定の最大値(MAX)に達した場合、ACRはSSAシステムによりブロック(block)される。
【0092】
ブロックされたACRは、ブロックされたACRが参照する他のACRによりブロック解除(unblock)可能である。ブロック解除を行うACRを参照することは、当該ACRのクリエータにより設定される。ブロックを解除するACRは、ブロックされたACRのクリエータとして同一AGPに存在し、「ブロック解除」のパーミッションを有することが好ましい。
【0093】
当該システムにおいて、ブロックされたACRをブロック解除可能なACRは、他には存在しない。ACRは、ブロック解除ACR(unblocker ACR)を用いずに、ブロッキングカウンタを用いて構成されてもよく、この場合、当該ACRがブロックされた場合には、それをブロック解除することはできない。
【0094】
《ルートAGP―アプリケーションデータベースの生成》
SSAシステムは、複数のアプリケーションを処理し、各アプリケーションのデータを分離するように設計されている。AGPシステムのツリー構造は、アプリケーション固有のデータを識別および分離するために使用される主なツールである。ルートAGPは、アプリケーションSSAデータベースツリーの先端部に存在し、幾分異なる行動規範に従う。幾つかのルートAGPはSSAシステムにおいて設定可能である。2つのルートAGP130および132が図6に示されている。これより少ない、または多くのAGPを使用しても良く、又、このことが本発明の範囲内にあることは明白である。
【0095】
新たなアプリケーションに対するデバイス(例えば、フラッシュカード)の登録、および/または、デバイスに対する新たなアプリケーションの証明書の発行は、新たなAGP/ACRツリーをデバイスに追加するプロセスを通じて実行される。
【0096】
SSAシステムは、(ルートAGPの全てのACRおよびそれらのパーミッションだけでなく)ルートAGPの生成に関する3つの異なるモードをサポートしている:
1.オープンモード(Open):如何なる種類の認証も必要としない任意のユーザまたはエンティティ、または(以下に説明する)システムACRを通じて認証されたユーザ/エンティティは、新たなルートAGPを生成することができる。オープンモードは、すべてのデータ伝送がオープンチャネル(即ち、発行機関(issuance agency)の安全な環境の中)で実行される間に、何もセキュリティ手段を使用することなく、または、システムACR認証(即ち、無線(Over The Air;OTA)および事後発行手順(post issuance procedure))を通じて確立されたセキュアチャネルを通じて、ルートAGPの生成を可能にする。
システムACRが設定されず(これは随意的な機能である)、ルートAGP生成モードがオープンに設定されている場合、オープンチャネルオプション(open channel option)のみが利用可能である。
2.制御モード(Controlled):システムACRを通じて認証されたエンティティのみが新たなルートAGPを生成することができる。SSAシステムは、システムACRが設定されていない場合、このモードに設定することができない。
3.ロックモード(Locked):ルートAGPの生成が不可能であり、増設ルートAGPをシステムに追加することができない。
2つのSSAコマンドがこの機能を制御する(これらのコマンドは認証無しで任意のユーザ/エンティティに利用可能である):
1.方法設定コマンド(Method configuration command)―3つのルートAGP生成モードの何れか一つを使用するようにSSAシステムを設定するために使用される。以下のモード変更のみが許可される:オープンモード
-> 制御モード(Open −> Controlled)、制御モード−>ロックモード(Controlled−>Locked)(即ち、SSAシステムが制御モードに現在設定されている場合、ロックモードへの変更のみ可能である)。
2.方法設定ロックコマンド(Method configuration lock command)―方法設定コマンドを無効にし、現在選択されているモードを永久にロックするために使用される。
【0097】
ルートAGPが生成される時、(ルートAGPの生成に適用されたのと同一のアクセス制限を使用して)ACRの生成および設定を可能にするのは、特別の初期化モードにおいてである。ルートAGP設定プロセスの最後に、エンティティが明確にそれをオペレーションモードに切り替えると、既存のACRはそれ以後の更新が不可能となり、追加のACRを生成することが不可能となる。
【0098】
ルートAGPが一旦標準モードになると、ルートAGPは、ルートAGPの削除パーミッションを与えられたルートAGP内のACRの1つを通じてシステムにログインすることによってのみ、削除可能となる。特別の初期化モードに加えて、これはルートAGPのもう一つの例外なのである;即ち、ツリー内の次のレベルのAGPとは対照的に、自身が属するAGPの削除パーミッションを有するACRを含むことが可能であるのは、当該AGPのみであることが好ましい。
【0099】
ルートACRと標準的なACRとの3つ目の、且つ、最後の相違点は、ルートACRが、パーティションの生成および削除パーミッションを有することができるシステム内における唯一のACRであるという点である。
【0100】
《SSAシステムACR》
システムACRは以下の2つのSSAオペレーションに使用することができる:
1.厳しい環境における保護チャネルの保護下でのACR/AGPツリーの生成。
2.SSAシステムをホスティングするデバイスの識別および認証。
【0101】
SSAにシステムACRが1つだけ存在することが好ましく、一旦定義されたら、変更不可能であることが好ましい。システムACRの生成時にはシステム認証を必要としない;即ち、SSAコマンドのみが必要なのである。システムACR生成機能を無効にすることが可能である(ルートAGP生成機能についても同様)。一つのシステムACRのみが許可されることが好ましいので、システムACRの生成後には、システムACR生成コマンドは効果を持たない。
【0102】
生成プロセスにおいては、システムACRは使用することができない。完了した時には、システムACRが生成され、準備完了であることを示す特別のコマンドを発行する必要がある。これより後の時点で、システムACRの更新または差し替えは不可能であることが好ましい。
【0103】
システムACRはSSAにおいてルートACR/AGPを生成する。システムACRは、ホストがそれに満足し、ブロックする時までは、ルートレベルを追加/変更するパーミッションを有する。ルートAGPをブロックすることは、本質的には、システムACRとの接続を遮断し、それを改ざん防止状態にすることである。この時点で、ルートAGPおよびその中のACRを変更/編集することができるものはない。これはSSAコマンドを通じて実行される。ルートAGPの生成を無効にすることは、永久的な効果があり、覆すことはできない。システムACRを含む上記の機能は、図7において説明されている。システムACRは3つの異なるルートAGPを生成するために使用される。これらが生成された後の一定の時間にシステムACRからルートAGPをブロックするために、SSAコマンドがホストから送信され、これにより、図7においてシステムACRをルートAGPに接続する破線で示しているように、ルートAGP生成機能が無効となる。これにより、3つのルートAGPが改ざん防止の状態になる。3つのルートAGPは、ルートAGPがブロックされる前でもされた後でも、3つの別々のツリーを形成する子AGPを生成することに使用することができる。
【0104】
上記機能は、コンテンツを備えたセキュア製品の設定において、コンテンツ所有者に高い柔軟性をもたらす。セキュア製品は、「発行される(Issued)」必要がある。発行とは、デバイスによるホストの識別およびホストによるデバイスの識別が可能な識別鍵を設置するプロセスである。デバイス(例えば、フラッシュカード)を識別することにより、ホストは、識別鍵を備えた秘密を信用できるか否かを決定することができる。一方、ホストを識別することにより、デバイスは、ホストが許可される場合にのみ、セキュリティポリシーを実行することができる(特定のホストコマンドを許可し、実行する)。
【0105】
複数のアプリケーションを扱うように設計された製品は、幾つかの識別鍵を有する。当該製品は「事前発行」(pre−issuarance)、即ち、鍵を発送前の製造工程で保存すること、または、「事後発行」(post−issurance)、即ち、新しい鍵を発送後に追加することが可能である。事後発行に関しては、メモリデバイス(例えば、メモリカード)は、何らかのマスタ(master)、またはデバイスへのアプリケーションの追加を許可されたエンティティの識別に使用されているデバイスレベル鍵を含む必要がある。
【0106】
上記機能により、製品は事後発行の有効化/無効化を設定することができる。さらに、事後発行設定が、発送後に安全に実施することができる。デバイスは、上記のマスタまたはデバイスレベル鍵の他には、鍵を備えていない小売製品として購入され、その後に、新たな所有者により、さらに事後発行アプリケーションの有効化または無効化の何れかが設定されてもよい。
【0107】
このように、システムACR機能により、上記目的を達成するための以下の機能が与えられる。
・システムACRを備えていないメモリデバイスは、無制限かつ規制のないアプリケーションの追加を許可する。
・システムACRを備えていないメモリデバイスは、システムACRの生成を無効にするように設定可能である。これは、(新たなルートAGPの生成機能が同様に無効にならない限り)新たなアプリケーションの追加を制御する方法がないことを意味する。
・システムACRを備えたメモリデバイスは、セキュアチャネルを経由する制御されたアプリケーションの追加のみを、システムACR証明書を使用する認証手続きを通じて確立することができる。
・システムACRを備えたメモリデバイスは、アプリケーションの追加前または追加後に、アプリケーション追加機能を無効にするように設定してもよい。
【0108】
《鍵IDリスト》
鍵IDは、特定のACR要求毎に生成される。しかし、メモリシステム10においては、鍵IDはSSAシステムのみにより使用される。鍵IDの生成時に、以下のデータは生成するACRにより提供される、または生成するACRに対して提供される。
1.鍵ID。IDはホストを通じてエンティティにより提供され、鍵と、さらなる読み出しアクセスまたは書き込みアクセスにおいて、鍵を使用して暗号化または復号されるデータを参照するために使用される。
2.鍵暗号化およびデータ完全性モード(上記のブロックモード、チェーンモードおよびハッシュモードと下記の説明の通り)
【0109】
ホストにより提供された属性に加えて、以下のデータはSSAシステムによって維持される。
1.鍵ID所有者。所有者であるACRのID。鍵IDの生成時に、クリエータACRがその所有者となる。しかし、鍵IDの所有権は、他のACRに譲渡されてもよい。鍵IDの所有者のみが、鍵IDの所有権の譲渡(transfer)および委譲(delegate)を許可されることが好ましい。関連する鍵へのアクセスパーミッションの委譲、およびこれらの権利の無効化は、鍵ID所有者または委譲パーミッションを与えられた任意の他のACRの何れかにより実行可能である。これらのオペレーションの何れか一つを実行するための試みがなされる時は常に、要求するACRに権限が与えられている場合に限って、SSAシステムが当該試みを許可する。
2.CEK。これは、鍵IDと関連付けられ、鍵IDにより示されたコンテンツを暗号化するために使用されるCEKである。CEKは、SSAシステムによって生成された128ビットのAES乱数鍵であってもよい。
3.MACおよびIV値(IV values)。チェーンブロック暗号(CBC)暗号アルゴリズムで使用される動的情報(メッセージ暗号コードおよび初期化ベクトル)。
【0110】
また、SSAの様々な機能が図8A乃至16のフローチャートを参照して説明されており、当該図面において、ステップの左側に記載された「H」はオペレーションがホストにより実行されることを意味し、「C」はオペレーションがカードにより実行されることを意味する。システムACRを生成するために、ホストはメモリデバイス10のSSAに対して、システムACRを生成するコマンドを発行する(矩形202)。デバイス10は、システムACRが既に存在するか否かをチェックすることにより対応する(矩形204、菱形206)。システムACRが既に存在する場合、デバイス10は失敗ステータスを返し、ストップする(楕円208)。システムACRが存在しない場合、メモリ10はシステムACRの生成が許可されるか否かを確認するためにチェックを行い(菱形210)、許可されない場合、失敗ステータスを返す(矩形212)。このように、例えば、システムACRを必要としないように、必要なセキュリティ機能が予め定められている場合、デバイス発行者がシステムACRの生成を許可しないこともある。ACRの生成が許可される場合、デバイス10はOKステータスを返し、ホストからのシステムACR証明書を待つ(矩形214)。ホストは、SSAのステータスをチェックし、デバイス10がシステムACRの生成が許可されることを示しているか否かをチェックする(矩形216および菱形218)。生成が許可されない場合、またはシステムACRが既に存在する場合、ホストはストップする(楕円220)。デバイス10がシステムACRの生成パーミッションを示している場合、ホストはそのログイン証明書を定義するためのSSAコマンドを発行し、これをデバイス10に送信する(矩形222)。デバイス10は受信した証明書を使用してシステムACR記録を更新し、OKのステータスを返す(矩形224)。このステータス信号に対応して、ホストはシステムACRの準備完了を示すSSAコマンドを発行する(矩形226)。デバイス10は、システムACRの更新または差し換えができないように、システムACRをロックすることにより対応する(矩形228)。これは、システムACRの機能およびホストに対してデバイス10を識別するための身元を確定する。
【0111】
新たなツリー(新たなルートAGP(New Root AGPs)およびACR)の生成手順は、これらの機能がデバイスに設定される方法により決定される。図9はこの手順を説明している。ホスト24およびメモリシステム10の両方がこれに従う。新たなルートAGPの追加が完全に無効となる場合、新たなルートAGPを追加することはできない(菱形246)。新たなAGPの追加が有効であるが、システムACRを必要とする場合、ホストはルートAGP生成コマンドの発行前に(矩形254)、システムACRを通じて認証し、セキュアチャネルを確立する(菱形250、矩形252)。システムACRを必要としない場合(菱形248)、ホスト24は認証なしでルートAGP生成コマンド(Root AGP command)を発行することが可能であり、矩形254に進む。システムACRが存在する場合には、システムACRを必要としない場合であっても(フローチャートには図示せず)、ホストはこれを使用してもよい。デバイス(例えば、フラッシュカード)は、上記機能が無効の場合には、新たなルートAGPを生成する如何なる試みも拒否し、システムACRを必要とする場合には、認証なしで新たなルートAGPを生成する試みを拒否する(菱形246および250)。矩形254で新たに生成されたAGPおよびACRは、AGP内のACRの更新、さもなければ変更ができないように、ここでオペレーションモードに切り替えられる。これにより、ACRをさらに追加できないようになる(矩形256)。そして、さらにルートAGPを生成できないように、システムが選択可能にロックされる(矩形258)。矩形258は、このステップが選択可能なステップであることを示すために、慣例として破線で図示されている。本出願の図面のフローチャートにおいて破線で示す矩形のすべては選択的なステップである。これにより、コンテンツ所有者は、合法的なコンテンツを有する本物のメモリデバイスを模倣し得る他の違法目的のデバイス10のユーザをブロックすることが可能となる。
【0112】
図10に示されているように、(上記の通り、ルートAGP内のACR以外の)ACRを生成するために、ACRを生成する権利を有する任意のACRから開始してもよい(矩形270)。エンティティは、エントリポイントACRアイデンティティ(entry point ACR identity)と、それが生成したいあらゆる必要な属性を備えたACRと、を提供することにより、ホスト24を通じてツリーへのエントリを試みるかもしれない(矩形272)。SSAは、ACRの身元との照合をチェックし、当該身元を有するACRがACRの生成パーミッションを有するか否かをチェックする(菱形274)。当該要求に権限があると証明された場合、デバイス10のSSAはACRを生成する(矩形276)。
【0113】
図11は、図10の方法を使用するセキュリティアプリケーションにおいて有用なツリーを説明する2つのAGPを示している。このように、マーケティングAGPにおいて身元m1を備えたACRは、ACRの生成パーミッションを有する。また、ACR m1は、鍵ID「マーケティング情報(Marketing Information)」に関連付けられたデータ、および、鍵ID「価格リスト(Price List)」に関連付けられたデータを読み出しおよび書き込みするための鍵の使用パーミッションを有する。図10の方法を使用して、ACR m1は2つのACRを備えたセールスAGPを生成するが、ここで、2つのACRとは、s1およびs2であり、鍵ID「マーケティング情報」に関連付けられたデータへのアクセスに必要な鍵ではなく、鍵ID「価格リスト」に関連付けられた価格データにアクセスするための鍵の読み出しパーミッションのみを備えている。この方法で、ACRs s1およびs2を備えたエンティティは、価格データの読み出しのみが可能であり、同データを変更することはできず、マーケティングデータへのアクセスを有していない。一方、ACR m2は、ACRの生成パーミッションを有していないが、鍵ID「価格リスト」および鍵ID「マーケティング情報」に関連付けられたデータにアクセスするための鍵の読みだしパーミッションのみを有している。
【0114】
このように、m1がs1およびs2に対して価格データの読み出し権を委譲するという上述の方法で、アクセス権限が委譲されてもよい。大規模なマーケティングおよびセールスグループが関与している状況では、特にこの方法は有用である。営業担当者が存在するが、その人数が1名または数名の場合には、図10の方法を使用する必要はない。その代わりに、図12に図示すように、ACRが同一AGP内の低位レベルまたは同一レベルのACRにアクセス権限を委譲してもよい。第一に、上述の方法でホストを通じてツリー上のACRを特定することにより、エンティティはそうしたAGPに対するツリーに入る(矩形280)。次に、ホストはACRおよび委譲する権利を特定する。SSAは、当該ACRに対する一または複数のツリーをチェックし、ACRが特定された他のACRに権利を委譲するパーミッションを有するか否かをチェックする(菱形282)。権利を有する場合、権利は委譲され(矩形284)、権利を有さない場合には、権利委譲をストップする。この結果が図13で説明されている。この場合、ACR m1はACR s1に対して読み出しパーミッションを委譲するパーミッションを有しており、s1はパーミッションの委譲後に価格データにアクセスする鍵を使用することが可能となる。これは、m1が価格データにアクセスする権利と同一またはより高位レベルの権利を有し、このように委譲するパーミッションを有する場合に実行されてもよい。一実施形態に於いて、m1はパーミッションの委譲後に当該アクセス権限を保有する。アクセス権限は、好ましくは、例えば限られた時間、限られたアクセス回数等、(その後、むしろ永遠に)制限された状況下で委譲されてもよい。
【0115】
図14には、鍵および鍵IDの生成プロセスが示されている。エンティティがACRを通じて認証を行う(矩形302)。エンティティがホストにより特定されたIDを備えた鍵の生成を要求する(矩形304)。SSAは、特定されたACRが鍵の生成パーミッションを有するか否かをチェックし確認する(菱形306)。例えば、鍵が特定のパーティションにおけるデータにアクセスするために使用される場合、SSAはACRが当該パーティションにアクセス可能か否かをチェックし確認する。ACRが権限を有する場合、メモリデバイス10はホストにより供給された鍵IDに関連付けられた鍵値を生成し(矩形308)、鍵IDをACRに保存し、鍵値をそのメモリ(コントローラ関連メモリまたはメモリ20)に保存する。そして、エンティティにより供給された情報に従って、権利およびパーミッションを割り当て(矩形310)、当該割り当てられた権利およびパーミッションを用いて、当該ACRのPCRを修正する(矩形312)。このように、鍵のクリエータは、例えば、読み出しおよび書き込みパーミッション、委譲権および同一AGPの他のACRまたは低位レベルのACRとの共有権、鍵の所有権の譲渡権など、あらゆる利用可能な権利を有する。
【0116】
図15に図示すように、ACRはSSAシステムにおいて他のACRのパーミッション(またはその存在すべて)を変更することが可能である。エンティティは、既に述べたように、ACRを通じてツリーに入ることが可能である。即ち、一例ではエンティティが認証されると、ACRを特定する(矩形330、332)。エンティティは、ターゲットACRの削除またはターゲットACRにおけるパーミッションを要求する(矩形334)。特定されたACRまたはこの時点でアクティブなACRが当該要求に関する権利を有する場合(菱形336)、ターゲットACRが削除されるか、ターゲットACRのPCRが当該パーミッションを削除するために変更される(矩形338)。これが権限を与えられない場合、システムはストップする。
【0117】
上記のプロセス後、ターゲットは、当該プロセス以前にアクセス可能であったデータにアクセスすることができなくなる。図16に示されているように、エンティティはターゲットACRでツリーに入ろうとするかもしれないが(矩形350)、以前存在していたACRのIDがSSAにもはや存在していないので、認証プロセスに失敗していることが判明する。その結果、アクセス権限は拒否される(菱形352)。ACRのIDが削除されていないことを想定した場合、エンティティはACRを特定し(矩形354)、特定のパーティションにおける鍵IDおよび/またはデータを特定する(矩形356)。そして、SSAはそうしたACRのPCRにしたがって、鍵IDまたはパーティションアクセス要求が許可されたか否かを確認するためにチェックする(菱形358)。パーミッションが削除されている、または期限切れとなっている場合、当該要求は再び拒否される。それ以外の場合、当該要求は認められる(矩形360)。
【0118】
上記のプロセスは、ACRおよびACRのPCRが他のACRによって変更されたかどうか、または、初めからそのように設定されていたかどうかに関係なく、保護データへのアクセスがデバイス(例えば、フラッシュカード)によってどのように管理されるかを説明している。
【0119】
《セッション》
SSAシステムは、同時にログインした複数ユーザを処理するように設計されている。この機能は、SSAにより受信された各コマンドが特定のエンティティに関連付けられており、このエンティティの認証に使用されたACRが要求されたアクションに対するパーミッションを有する場合にのみ実行されることを必要とする。
【0120】
複数のエンティティはセッションコンセプト(session concept)を通じてサポートされる。セッションは認証プロセス中に確立され、SSAシステムによりセッションIDが割り当てられる。セッションIDは、システムへのログインに使用されるACRと内部的に関連付けられており、さらなるSSAコマンドすべてにおいて使用されるエンティティに対してエクスポートされる。
【0121】
SSAシステムは以下の2種類のセッションをサポートする。すなわち、オープンセッション(open session)とセキュアセッション(secure session)である。特定の認証プロセスに関連付けられたセッションタイプは、ACRで定義される。SSAシステムは、認証自体を実行する方法と類似の方法でセッションの確立を実行する。ACRはエンティティのパーミッションを定義するので、このメカニズムにより、システム設計者はセキュアトンネル(secure tunneling)を、特定の鍵IDへのアクセスと、特定のACR管理オペレーションの呼び出し(invoking)(即ち、新しいACRの生成および証明書の設定)と、の何れかと関連付けることが可能になる。
【0122】
《オープンセッション》
オープンセッションとは、バス暗号化を使用せずに、セッションIDを使用して識別されるセッションであり、すべてのコマンドおよびデータが問題なく通過する。このオペレーションモードは、エンティティが脅威モデルの一部ではなく、バスの盗聴もしていない、複数ユーザまたは複数エンティティの環境で使用されることが好ましい。
【0123】
データの伝送保護も、ホスト側アプリケーション間の効果的なファイアウォールの有効化も行わないが、オープンセッションモードにより、SSAシステムは、現状で認証されたACRに許可された情報のみへのアクセスを許可することができる。
【0124】
また、オープンセッションは、パーティションまたは鍵の保護が必要となる場合に使用することが可能である。しかし、妥当な認証プロセス後に、アクセスはホストにおけるすべてのエンティティに認められる。認証されたACRのパーミッションを獲得するために様々なホストアプリケーションが唯一共有する必要があるのは、セッションIDである。これは図17Aにおいて説明されている。ライン部400より上に記載されているステップは、ホスト24が実行するステップである。エンティティは、ACR1に対して認証された後(矩形402)、メモリデバイス10において鍵IDXに関連付けられたファイルへのアクセスを要求する(矩形404、406、408)。ACR1のPCRが当該アクセスを許可する場合、デバイス10は当該要求を認める(菱形410)。それ以外の場合、システムは矩形402に戻る。 認証完了後、メモリシステム10は、割り当てられたセッションID(ACR証明書ではない)によってのみコマンドを発行するエンティティを識別する。一旦ACR1がそのPCRにおける鍵IDに関連付けられたデータへのアクセスを獲得すると、オープンセッションにおいて、任意の他のアプリケーションまたはユーザが、ホスト24における異なるアプリケーション間で共有される正しいセッションIDを特定することにより、同一データにアクセスすることが可能である。この機能がアプリケーションで有益であるのは、一度だけでログイン可能であり、異なるアプリケーションに対してログインが実行されるアカウントに関連付けられたすべてのデータにアクセス可能であるので、ユーザの利便性がより高いという点である。このように、携帯電話のユーザは、ログインを複数回数行うことなく、保存されたEメールにアクセスし、メモリ20に保存された音楽を聴くことが可能であってもよい。一方、ACR1に含まれていないデータにはアクセス不可能である。このように、同一の携帯電話ユーザは、別のアカウントACR2を通じてアクセス可能な、例えばゲームおよび写真等の有益なコンテンツを有するかもしれない。ユーザが自身の最初のアカウントACR1を通じて利用可能なデータに他者がアクセスすることを気にしないとしても、これは、ユーザが自身の電話を借りる他者がアクセスすることを望まないデータなのである。オープンセッションにおいてACR1へのアクセスを許可しつつ、データへのアクセスを2つの別々のアカウントに分割することにより、価値のあるデータの保護を利用可能にするだけでなく、利便性も提供する。
【0125】
ホストアプリケーション間のセッションIDを共有するプロセスをさらに容易にするために、ACRがオープンセッションを要求する際に、ACRはセッションに「0(ゼロ)」IDを割り当てることを具体的に要求することが可能である。このように、アプリケーションを事前に定義されたセッションIDを使用するように設計することが可能である。明白な理由から、唯一の制約は、セッション0を要求する一つのACRだけを特定の時間に認証可能であるということである。セッション0を要求する他のACRを認証する試みは拒否される。
【0126】
《セキュアセッション(secure session)》
図17Bに示すように、セキュリティレイヤ(layer of security)を追加するために、セッションIDを使用してもよく、この場合、メモリ10はアクティブなセッションのセッションIDを保存する。図17Bにおいて、例えば、鍵IDXに関連付けられたファイルへのアクセスを可能にするために、エンティティは、ファイルへのアクセスを許可される前に、例えばセッションID「A」等のセッションIDを提供する必要もある(矩形404、406、412および414)。この方法では、要求するエンティティが正しいセッションIDを認識しない限り、エンティティはメモリ10にアクセスすることができない。セッション終了後にセッションIDは削除され、セッションIDがセッション毎に異なるので、エンティティはセッション番号を供給可能な状況にある場合に限りアクセスを獲得することができる。
【0127】
SSAシステムは、セッション番号を使用する以外に、実際にコマンドが適切に認証されたエンティティから送信されていることを確かめる方法がない。攻撃者が悪意のあるコマンドを送信するためにオープンチャネルの使用を試みる脅威が存在する場合でのアプリケーションの使用に際して、ホストアプリケーションはセキュアセッション(セキュアチャネル)を使用する。
【0128】
セキュアチャネルを使用する場合、コマンド全体だけでなく、セッションIDもセキュアチャネル暗号(セッション)鍵で暗号化され、セキュリティレベルはホスト側で実行されているセキュリティレベルと同程度に高い。
【0129】
《セッションの終了》
下記のシナリオの内、何れか一つのシナリオでセッションは終了し、ACRはログオフされる。
1.エンティティが明確なセッション終了コマンドを発行する。
2.通信時のタイムアウト。特定のエンティティが、ACRパラメータの一つとして定義された期間(time period)において、コマンドを発行しなかった。
3.デバイス(例えば、フラッシュカード)の再起動および/または電源の入れ直し後、すべてのオープンセッションが終了する。
【0130】
《データ完全性サービス(data integrity services)》
SSAシステムは、(ACR,PCR等のすべてを含む)SSAデータベースの完全性を検証する。さらに、データ完全性サービスが鍵IDメカニズムを通じてエンティティデータに提供される。
【0131】
鍵IDに暗号アルゴリズムとしてハッシュアルゴリズムが組み込まれている場合、ハッシュ値(hash value)がCEKおよびIVとともにCEK記録に保存される。ハッシュ値は書き込みオペレーション中に算出され、保存される。ハッシュ値は読み出しオペレーション中に再び算出され、以前の書き込みオペレーション中に保存されたハッシュ値と比較される。エンティティが鍵IDにアクセスする度に、追加のデータが古いデータおよび更新された(読み出しまたは書き込みに対する)適切なハッシュ値に(暗号方法的に)連結される。
【0132】
ホストのみが、鍵IDに関連付けられた、または鍵IDにより示されたデータファイルを区別しているので、ホストは以下に示す方法で、データ完全性機能の幾つかの面を明確に管理する:
1.鍵IDに関連付けられた、または鍵IDにより示されたデータファイルが最初から最後まで書き込まれ、読み出される。SSAシステムがCBC暗号法を使用し、データ全体のハッシュ化メッセージダイジェスト(hashed message digest)を生成するので、ファイルの一部にアクセスする任意の試みは失敗する。
2.中間ハッシュ値がSSAシステムにより維持されるので、連続ストリームにおいてデータを処理する必要はない(データストリームは他の鍵IDのデータストリームと交互配置する(interleaved)ことができ、複数セッションに亘って分割してもよい)。しかし、データストリームが再起動される場合、エンティティは明確にSSAシステムに対してハッシュ値をリセットするように指示する必要がある。
3.読み出しオペレーションの完了時に、ホストは、読み出しハッシュを書き込みオペレーション中に算出されたハッシュ値と比較することにより、明確にSSAシステムに対して読み出しハッシュを認証するように要求しなければならない。
4.さらに、SSAシステムは「ダミー読み出し(dummy read)」オペレーションを提供する。この機能は、暗号化エンジンを通じてデータをストリームするが、ホストに対してデータを送信しない。この機能は、実際にデータデバイス(例えば、フラッシュカード)から読み出される前に、データ完全性を検証するために使用可能である。
【0133】
《乱数の生成》
SSAシステムは、外部のエンティティが内部の乱数ジェネレータ(rundom number generator)を利用し、SSAシステムの外部で使用される乱数を要求することを可能にする。このサービスは任意のホストに利用可能であり、認証を必要としない。
【0134】
《RSA鍵ペアの生成》
SSAシステムは、外部のユーザが、内部のRSA鍵ペア生成機能を利用し、SSAシステムの外部で使用されるRSA鍵ペアを要求することを可能にする。このサービスは任意のホストに利用可能であり、認証を必要としない。
【0135】
《代替実施形態》
図18で説明するように、階層アプローチを使用する代わりに、データベースアプローチを使用して同様の結果を達成することが可能である。
【0136】
図18に示すように、エンティティに対する証明書のリスト、認証方法、失敗した試行の最大回数、およびブロック解除に必要な証明書の最小数が、コントローラ12またはメモリ20に保存されたデータベースに入力されてもよく、これは、そうした証明書の要求をメモリ10のコントローラ12により実行されたデータベースにおけるポリシー(鍵およびパーティションに対する読み出し、書き込みアクセス、およびセキュアチャネル要求)に関連付けるものである。また、鍵およびパーティションへのアクセスに関する制約(constraints)および制限(limitation)がデータベースに保存されている。このように、エンティティ(例えば、システム管理者)の中には、ホワイトリストに掲載されものがいるかもしれないが、これは、これらのエンティティが常にすべての鍵およびパーティションにアクセス可能であることを意味する。他のエンティティはブラックリストに掲載されるかもしれないが、他のエンティティが任意の情報にアクセスを試みる場合にはブロックされる。制限はグローバル(global)であってもよいし、鍵および/またはパーティション固有(key and/or partition specific)であってもよい。これは、所定のエンティティのみが常に特定の鍵およびパーティションにアクセス可能であり、所定のエンティティは常にこれが不可能であることを意味する。コンテンツが存在するパーティションまたはコンテンツを暗号化または復号するために使用される鍵に関係なく、制約もコンテンツ自体に課すことができる。このように、所定のデータ(例えば、歌曲)は、どのエンティティがアクセスしたかに関係なく、所定のデータにアクセスする最初の5つのホストデバイスによってのみ、当該所定のデータにアクセス可能であるという属性、または、他のデータ(例えば、映画)が限られた回数だけ読み出し可能であるという属性を有してもよい。
《認証》
パスワード保護
・ パスワード保護は、保護領域にアクセスするためにパスワードを提示する必要があることを意味する。パスワード保護が2つ以上のパスワードになることが不可能でなければ、パスワードは、例えば読み出しアクセス、または読み出し/書き込みアクセス等の異なる権利と関係付けることができる。
・ パスワード保護とは、デバイス(例えば、フラッシュカード)がホストにより提供されたパスワードを検証することができることを意味する。即ち、デバイスもデバイスが管理するセキュアメモリ領域に保存されたパスワードを有する。
問題および限界
・ パスワードは、リプライ攻撃(reply attack)を受けやすい。パスワードは、毎回提示された後に変化しないので、全く同じようにパスワードを再送することができる。これは、保護されるデータに価値があり、コミュニケーションバスが容易にアクセス可能である場合、パスワードをそのまま使用してはならないということを意味している。
・ パスワードは保存されたデータへのアクセスを保護することはできるが、(鍵ではなく)データの保護に使用すべきではない。
・ ハッカーがシステム全体を破壊しないように、パスワードに関連付けられたセキュリティレベルを高めるためには、マスタ鍵を使用してパスワードを多様化することができる。パスワード送信のために、セキュアコミュニケーションチャネルに基づくセッション鍵を使用可能である。
【0137】
図19は、パスワードを使用する認証を説明するフローチャートである。エンティティは、アカウントIDおよびパスワードをシステム10(例えば、フラッシュメモリカード)に送信する。システムは、パスワードがメモリ内のパスワードと一致するか否かを確認するためにチェックする。一致する場合、認証ステータスが返される。そうでなければ、そのアカウントに対してエラーカウンタがインクリメントされ、エンティティはアカウントIDおよびパスワードを再入力するよう求められる。カウンタがオーバーフロー(overflow)した場合、システムはアクセス拒否のステータスを返す。
【0138】
《チャレンジレスポンス(challenge response)》
図20は、チャレンジ/レスポンス型の方法を使用する認証を説明するフローチャートである。エンティティは、アカウントIDを送信し、システム10からチャレンジ(challenge)を要求する。システム10は乱数を生成し、ホストに提示する。ホストは、当該乱数からレスポンス(response)を算出し、これをシステム10に送信する。システム10は当該レスポンスと保存された値を比較する。残りのステップは、図19のアクセスを認めるか否かを決定するステップと同様である。
【0139】
図21は、他のチャレンジ/レスポンス型の方法を使用する認証を説明するフローチャートである。図21に示す認証は以下の点で図20の認証と異なる。即ち、図21の認証は、ホストがシステム10により認証されることを要求するだけでなく、システム10がチャレンジ/レスポンスにより認証されることも要求するのであり、当該チャレンジ/レスポンスでは、システム10はホストからのチャレンジを要求し、ホストによりチェックされるレスポンスを返す。
【0140】
図22は、他のチャレンジ/レスポンス型の方法を使用する認証を説明するフローチャートである。この場合、システム10の認証のみが必要であり、当該認証ではホストはシステム10にチャレンジを送信する。システム10は、システム10に関する記録との照合のためにホストによりチェックされるレスポンスを算出する。
【0141】
《対称鍵》
対称鍵アルゴリズムとは、ホスト側およびデバイス側でSAME鍵(SAME Key)が暗号化および復号に使用されることを意味する。即ち、これは鍵がコミュニケーション前に事前に合意されていることを意味する。また、ホスト側およびデバイス側のそれぞれが、互いのリバースアルゴリズム(reverse algorithm)を実行すべきである。即ち、一方で暗号化アルゴリズムを実行し、他方で復号アルゴリズムを実行するということである。ホスト側およびデバイス側の双方がコミュニケーションのために両方のアルゴリズムを実行する必要はない。
《認証》
対称鍵認証とは、デバイス(例えば、フラッシュカード)およびホストが同一の鍵を共有し、同一の暗号アルゴリズム(ダイレクトアルゴリズムおよびリバースアルゴリズム、例えば、DESおよびDES−1)を有することを意味する。
対称鍵認証とは、(リプライ攻撃から保護する)チャレンジレスポンスを意味する。保護されたデバイスは、他のデバイスに対してチャレンジを生成し、両者がレスポンスを算出する。認証デバイスはレスポンスを返信し、保護されたデバイスは、当該レスポンスをチェックし、これにより認証を確認する。そして、認証に関連付けられた権利を認めることができる。
可能な認証の種類は下記の通りである:
外部認証:デバイス(例えば、フラッシュカード)が外部を認証する。即ち、デバイスが所定のホストまたはアプリケーションの証明書を確認する。
相互認証:チャレンジがデバイス側およびホスト側で生成される。
内部認証:ホストアプリケーションがデバイス(例えば、フラッシュカード)を認証する。即ち、ホストが、そのアプリケーションに対してデバイスが本物であるか否かをチェックする。
システム全体のセキュリティレベルを高めるためには(即ち、破壊者がすべてを破壊しない)、
・通常、対称鍵がマスタ鍵を使用する多様化(diversification)と併用される。
・相互認証が、チャレンジが本物のチャレンジであることを確実にするために、デバイス側およびホスト側からのチャレンジを使用する。
暗号化:対称鍵暗号化も暗号化に使用されているが、これは、対称鍵暗号化が非常に効果的なアルゴリズムだからである。すなわち、対称鍵暗号化は暗号化処理に強力なCPUを必要としない。
【0142】
コミュニケーションチャネルの保護に使用される場合:
両デバイスは、チャネルの保護に使用されるセッション鍵を理解しなければならない(即ち、すべての発信データを暗号化し、すべての着信データを復号する)。通常、当該セッション鍵は、事前に共有された秘密対称鍵またはPKIを用いて確立される。
両デバイスは、同一の暗号アルゴリズムを理解し、実行しなければならない。
【0143】
《署名》
また、対称鍵をデータの署名に使用することが可能であり、この場合、署名は暗号化の部分的な結果である。結果を部分的に維持することにより、鍵値を暴露することなく、必要な回数だけ署名することを許可する。
【0144】
《問題および限界》
対称アルゴリズムは非常に効果的で安全であるが、事前に共有された秘密に基づいている。問題は、この秘密を動的な方法で安全に共有すること、および、恐らく秘密を(例えば、セッション鍵のように)ランダムにすることである。つまり、共有された秘密を長期間安全に守ることは困難であり、複数の人々と共有することは殆ど不可能だということである。
【0145】
このオペレーションを促進するために、公開鍵アルゴリズムが発明されたが、これは、当該アルゴリズムにより、秘密を共有することなく秘密の交換が可能となるからである。
【0146】
《公開鍵暗号化》
非対称鍵アルゴリズムは、一般に公開鍵暗号と称す。これは非常に複雑であり、通常、CPUによる集中的な数学的処理により実行される。当該アルゴリズム、対称鍵アルゴリズムに関連する鍵分配(key distribution)の問題を解決するために発明された。また、これはデータの完全性を確実にするために使用される署名機能を提供する。
【0147】
非対称鍵アルゴリズムは、それぞれが秘密鍵および公開鍵と称される、秘密要素および公開要素を有する鍵を使用する。秘密鍵と公開鍵の両方は、数学的に関連付けられている。公開鍵は共有可能であり、一方、秘密鍵は秘匿性を維持しなければならない。これらの鍵に関しては、ラップ(wrap)およびラップ解除(unwrap)、または署名および照合を提供するために、(一つが秘密鍵用であり、一つが公開鍵用の)2つの数学的関数を使用する。
【0148】
《鍵交換および鍵分配》
鍵交換は、PKアルゴリズムを使用すれば非常に簡単になる。デバイスは公開鍵を他のデバイスに送信する。他のデバイスは、この公開鍵を用いて自身の秘密鍵をラップし、前者のデバイスに暗号化されたデータを返す。前者のデバイスは、データのラップ解除に自身の秘密鍵を使用し、両者に周知であって且つデータ交換に使用可能な秘密鍵を取り出す。対称鍵はこのように容易に交換可能であることから、通常、乱数鍵が使用される。
【0149】
《署名》
通常、公開鍵アルゴリズムは、その性質上、小量のデータの署名のみに使用される。データの完全性を確実にするために、その後、公開鍵アルゴリズムはメッセージの一方向フットプリント(one−way foot print)を提供するハッシュ関数と併用される。
【0150】
秘密鍵はデータの署名に使用される。(自由に利用可能な)公開鍵は署名の照合を許可する。
【0151】
《認証》
通常、認証は署名を必要とする。即ち、チャレンジが署名され、照合のために返される。
【0152】
鍵の公開部分が照合に使用される。誰でも鍵ペアを生成できるので、公開鍵の所有者が正しい鍵を使用している正しい人物であることを証明するために、当該所有者を認証する必要がある。認証局(certification authority)は、証明書を供給し、署名された証明書に公開鍵を組み込む。当該証明書は認証局自身により署名される。そして、署名の照合に公開鍵を使用するということは、その鍵を組み込む証明書を発行した認証局が信用できるものであり、証明書がハッキングされてない、即ち、認証局によりハッシュ署名された証明書が正しいことを検証可能であることを意味する。また、これはユーザが認証局の公開鍵証明書を有しており、これを信用していることを意味する。
【0153】
PK認証の提供に関する最も一般的な方法は、認証局またはルート証明書(root certificate)を信用し、且つ、所定の認証局に認証されたすべての鍵ペアを間接的に信用することである。そして認証は、チャレンジに署名し、チャレンジレスポンスおよび証明書を提供することにより、各々が有する秘密鍵が証明書と一致することを証明する問題となる。そして、証明書は、ハッキングされておらず、信用できる認証局により署名されていることを確かめるためにチェックされる。そして、チャレンジレスポンスが照合される。証明書が信用できるものであり、チャレンジレスポンスが正しい場合、認証は成功する。
【0154】
デバイス(例えば、フラッシュカード)における認証は、デバイスが信用できるルート証明書を使用してロードされており、デバイスがハッシュ署名された証明書だけでなくチャレンジレスポンスを照合可能であることを意味する。
【0155】
《ファイルの暗号化》
PKアルゴリズムは過度にCPUに依存しているので、大量のデータの暗号化には使用されない。しかし、通常、PKアルゴリズムはコンテンツの暗号化のために生成されたランダム暗号化/復号鍵を保護するために使用される。例えば、SMIME(セキュアEメール;secure email)は、すべての受信者の公開鍵を用いて暗号化される鍵を生成する。
【0156】
《問題および限界》
何でも鍵ペアを生成することが可能であるので、鍵ペアの出所を確実にするために認証を受けなければならない。鍵の交換中に、秘密鍵が正しいデバイスに提供されているかを確かめたいと思うかもしれない。即ち、提供された公開鍵の出所はチェックを受ける必要がある。そして、証明書管理が鍵の妥当性に関する情報と、鍵が無効な状態であるか否かに関する情報を提供することができることから、証明書管理がセキュリティの一部となる。
【0157】
本発明は、様々な実施形態を参照することにより上述の通り記載されているが、当然のことながら、変更および修正は本発明の範囲から逸脱することなく可能であり、本発明は添付の請求項およびそれらの等価物によってのみ定義されるべきである。ここで参照されたすべての参考文献は、参照することにより本発明に組み込まれる。
【図面の簡単な説明】
【0158】
【図1】本発明の説明に好適なホストデバイスと通信するメモリシステムのブロック図である。
【図2】本発明の一実施形態を説明する概略図であって、メモリの異なるパーティションと異なるパーティションに保存された暗号化されていないファイルおよび暗号化ファイルに関するもので、ここでは、あるパーティションおよび暗号化ファイルへのアクセスがアクセスポリシーおよび認証手順により制御されるものである。
【図3】メモリ内の異なるパーティションを例示するメモリの概略図である。
【図4】本発明の一実施形態を説明するための、図3に図示されたメモリ内の異なるパーティションに関するファイルロケーションテーブルの概略図であって、ここではパーティション内のいくつかのファイルが暗号化されているものである。
【図5】本発明の一実施形態を説明するための、アクセス制御された記録グループおよび関連するキーリファレンスにおけるアクセス制御記録に関する概略図である。
【図6】本発明の一実施形態を説明するためアクセス制御された記録グループおよびアクセス制御された記録によって形成されたツリー構造の概略図である。
【図7】ツリーの形成プロセスを説明するためアクセス制御された記録グループの3階層ツリーを例示したツリーの概略図である。
【図8A】ホストデバイスおよびメモリデバイス(例えば、システムアクセス制御記録を生成および使用するためのメモリカード等)が実行するプロセスを例示したフローチャートである。
【図8B】ホストデバイスおよびメモリデバイス(例えば、システムアクセス制御記録を生成および使用するためのメモリカード等)が実行するプロセスを例示したフローチャートである。
【図9】本発明を説明するためアクセス制御された記録グループを生成するためにシステムアクセス制御記録を使用するプロセスを例示したフローチャートである。
【図10】アクセス制御記録の生成プロセスを例示したフローチャートである。
【図11】階層ツリーの特定アプリケーションの説明に好適な2つのアクセス制御記録グループの概略図である。
【図12】特定の権利の委譲プロセスを例示したフローチャートである。
【図13】図12の委譲プロセスを説明するためアクセス制御された記録グループおよびアクセス制御記録の概略図である。
【図14】暗号化および/または復号目的の鍵生成プロセスを例示したフローチャートである。
【図15】アクセスされ制御された記録に応じて、アクセス権限および/またはデータアクセスパーミッションを取り除くプロセスを例示したフローチャートである。
【図16】アクセス権限および/またはアクセスパーミッションが削除された、または期限切れになった場合のアクセス要求プロセスを例示したフローチャートである。
【図17A】本発明の他の実施形態を説明するための、暗号鍵へのアクセスを許可するための認証およびポリシーに対するルール構造の構成を例示した概略図である。
【図17B】本発明の他の実施形態を説明するための、暗号鍵へのアクセスを許可するための認証およびポリシーに対するルール構造の構成を例示した概略図である。
【図18】幾つかのセッションがオープン状態での認証セッションおよびアクセスセッションを例示したフローチャートである。
【図19】図19は、他の認証プロセスを例示したフローチャートである。
【図20】図20は、他の認証プロセスを例示したフローチャートである。
【図21】図21は、他の認証プロセスを例示したフローチャートである。
【図22】図22は、他の認証プロセスを例示したフローチャートである。 本出願においては、説明を簡略化するために、同一部分については同一符号が付与されている。
【0159】
《付録A》
1 SSAコマンド
SSAシステムコマンドは、スタンダード(関連のフォームファクタプロトコルに対して)書き込み・読み取りコマンドを用いて、メモリーカードに渡される。したがって、ホストから見て、SSAコマンドを送信することは、実際には、データをメモリデバイス上でバッファ・ファイルとして用いられる特別なファイルに書き込むことを意味する。SSAシステムから情報を得ることは、バッファファイルからデータを読み取ることによって行われる。ホストアプリケーションは、データが常に書き込まれて、バッファファイルの第1のLBAから読み取られることを確認する必要がある。ホストOSにおいてバッファファイルを管理することは、この明細書の範囲外である。
1.1SSAシステムとの通信
以下のセクションは、どのように、フォームファクタスタンダード書き込み/読み取りコマンドを用いることによって、SSAと関連するコマンドおよびデータがSSAシステムと通信されるかを定義する。
1.1.1 コマンド/データのSSAシステムへの送信
すべての書き込みコマンドごとの第1データブロックは、シグネチャを通じてパスに対してスキャンされる。見つかった場合、データがSSAコマンドとして解釈される。見つからなかった場合、データは、指定されたアドレスに書き込まれる。
SSAアプリケーション特定の書込コマンドは、マルチプルセクタトランスファを含むことができる。ここで、第1セクタは必要なシグネチャおよびコマンドの引数を保持し、残りのデータブロックが関連するデータを保持する(もしあれば)。
テーブル...SSAコマンドの第1ブロックのフォーマット(スタンダードOSファイルシステムにおいて用いられる場合、データブロックは常に512バイトである)を定義する。

1.1.2 SSAシステムからのデータ読み取り
読み取りコマンドは、2つのパートで実行される:
1.読み取りコマンドのすべての引数を定義する単一データブロックを備えた書込コマンドをまず送信することにより、読み取りコマンドを開始する。
2.書き込みコマンドが、カードアプリケーションを転送の正しい状態にセットした後、読み取りコマンドを用いてカードからホストへの実際のデータ転送を開始する。読み取りコマンドは、先の書込コマンドが用いたのと同じLBAアドレスを用いなければならない。これは、カードに対しホストがSSAデータを得ようとしているという唯一の指示である(先に要求された)。
書き込み/読み取りコマンド・ペアは注意深く同期されなければならない。次のセッションは、どのようにシーケンスエラーが扱われ、回復されるかを定義する。定義された通り、SSAシステムは、同時にログオンできる複数のホスト側ユーザをサポートする。それぞれのユーザは、独立且つ非同期で書き込み/読み取りコマンド・ペアを開始することを希望するため、ホストOSの特別な行動は必要ではない。カードの点から見て、これらの個々のペアは、シーケンスのライト(書き込み)ハーフにおいて用いられるLBAアドレスによって識別される。ホストから見て、それぞれのユーザが異なるファイルバッファを用いなければならないことを意味する。
1.1.3 書き込み/読み取りシーケンス・エラー
1.2コマンドの詳細な説明
テーブル2は、SSAコマンドの全体的な概要を提供する。
コマンド名欄は、コマンド使用法の基本的な説明およびコマンドの詳細な説明のインデックスを提供する コマンド・Op−codeは、SSAコマンドにおいて用いられる実際の値である。引数長さ(Arg Len)欄は、コマンドの引数フィールドのサイズ(ゼロの値は、引数がないことを意味する)を定義する。
引数は、コマンド特定であり、詳細なコマンド説明中で指定される。
データ長さは、コマンドと関連づけられた追加のデータ・ブロックにおけるコマンド・データのサイズである。ゼロの値は、データがないことを意味する。「Var」の値は、コマンドが、変数データサイズを持っていることを意味し、実際のサイズはコマンド自体の中で指定される。固定サイズのデータ・コマンドについては、この欄は、データサイズのサイズを記憶する。
データ方向は、コマンドがデータを持たない(テーブル1に指定されたコマンド引数が、すべて、バイト76とバイト511との間のスペースに収まることを意味する−これを越えることは、コマンド・セクタに伴うデータ・ペイロードを課す)場合、ブランクであり、データがホストからカードに移っている(書込コマンドの引数ブロックに付加されて)場合、「write」であり、あるいは、データがカードからホストへ移っている(上述の通り、引数を提供する書込コマンドに続く、読み取りコマンドにおいて)場合、「read」である。
すべてのサイズに関連する欄は、バイト単位を用いる。





1.2.1 Create System ACR
Create System ACRは、SSAデータベース内にシステムACRエントリを構築する。一度エントリが生成されると、指定されたログインアルゴリズムにしたがって信用証明を構成することができる。最後に、CREATE_SYSTEM_ACR_DONEコマンドがシーケンスを終了し、かつシステムACRをアクティブにするために用いられる。
ACRエントリが既に存在する場合、あるいは、システムACRの生成機能が無効にされている場合には、Create System ACRコマンドは拒絶される。システムACRを、利用可能なログイン・モードのサブセットのみで構成することができる(詳細には、セクション1.3.2を参照)。無効モードが用いられている場合、コマンドは拒絶される。
コマンド引数は、表3に示される。バイトオフセットは、コマンド引数LBAの開始と関連がある(セクション1.1.1を参照)。引数の長さは、バイト単位で示される。引数名は、引数の目的を定義しており、詳細な引数の説明へのインデックスとして用いることができる。

1.2.2 System ACR Creation Done
このコマンドは、システムACR生成が開始した後のみ送信される。他のタイミングでは、コマンドは拒絶される。このコマンドの送信により、システムACR生成を終了し、ACRを恒久的に現在の構成とする。このコマンドに対する引数はない。
1.2.3 PASSWORD CREDENTIAL
SSAコマンド[28]―CREATE_ACRを送信した後に、ACRの信用証明の送信が、続けて行われる。この場合、それはある特定の長さのパスワードであり、−バイトの最大長は20である。

1.2.4 SYMMETRIC CREDENTIAL
ACRに対する対称的ログイン手順を選択する場合、AES、DESあるいは3DESキーの態様をとるACRの対称的信用証明の送信が続けて行われる。アルゴリズムの特性は、バイトでの信用証明の(キー)長さを示す。このコマンドは、正規のACRおよびシステムACR作成時に、用いることができる。
Error! Reference source not found.テーブル13は、異なるタイプの非対称的信用証明について説明する。

1.2.5 非対称形信用証明
非対称形ログイン手順を備えたACRについては、SSAに渡されなければならないいくつかの信用証明がある。以下のテーブル14は、異なるタイプの非対称形信用証明について説明する。

1.2.6 公開鍵のエクスポート(EXPORT PUBLIC KEY)
1.2.7 証明書のインポート(IMPORT CERTIFICATE)
1.2.8 ACAMの設定
このコマンドの送信は、ACR管理パーミッションを構成する。コマンドは、システムACR生成の際のみ送信される。コマンドは、システムACRに対しては有効ではない。ACAMタイプおよびコードは「表16:ACAMタイプ」に示す。

1.2.9 ルートAGPの生成
セキュアなチャンネルでルートAGPを生成するために、システムACRを通したSSAシステムログインを実行しなければならない。ログインの後、セッションIDが生成され、生成シーケンスに用いられる。セッションIDは、システムACRログインシーケンスが行われた直後にシステム−コマンド・リターン・ステータスを要求する場合には、利用可能である。システムACRに最初にログインせず、ルートAGPを生成する(セキュアなチャンネルでルートAGPを生成する)ことは、セッションIDを必要としない。
テーブル8は、コマンド引数を再表示する。システムACRを用いない場合、セッションIDフィールドは、NULL(NA)とされる。そのAGP名/IDは、それの長さのバイト数に先行している。

コマンド構造:
・コマンド名/OP Code−1バイト:SSA_CREATE_ROOT_AGP_CMD[3]
・コマンド引数
1.セッションID−必要か?
2.バイトでのAGP名/ID長さ−1バイト
3.AGP名/ID−
1.2.10 ルートAGP生成完了
ルートAGPが完了した−AGPにおけるACRのすべてが生成されたことを意味する−とき、このコマンドは送信される。このコマンドはAGPをロックして、これ以上のACRが生成されないようにする。
このコマンドに対する引数はない。
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_ROOT_AGP_CREATION_DONE_CMD[4]
・コマンド引数
1.セッションID−必要か?
2.バイトでのAGP名/ID長さ−1バイト
3.AGP名/ID−
1.2.11 システムACR生成不可(DISBALE_SYSTEM_ACR_CREATION)
このコマンドの送信は、システムACRを生成する機能を終了させる。このコマンドは、引数を持たない。
1.2.12 ルートAGP生成モードの設定(SET_ROOT_AGP_CREATION MODE)
ルートAGPの生成のコントロールは、SSAコマンド[19]SET_ROOT_AGP_CREATION_MODEで扱われる。異なるモードに対するコードは、テーブル9において説明される。このコマンドは、SSAにログインする必要がなく、したがって、セッションIDは、必要とされない。


1.2.13 ルートAGP変更不可モード(DISBALE_ROOT_AGP_CHANGE_MODE)
このコマンドは、SET_ROO_AGP_CREATION_MODEコマンドを作動不能にする。また、SSAによって拒絶される場合もある。このコマンドは、引数を持たない。
1.2.14 AGPの生成(Create AGP)

コマンド構造:
・コマンド名/OP Code−1バイト:SSA_CREATE_AGP_CMD[5]
・コマンド引数
1.セッションID−1バイト
2.バイトでのAGP名/ID長さ−1バイト
3.AGP名/ID−
1.2.15 AGPの削除(Delete AGP)
このコマンドは、AGPを生成したACRに有効である、ただし、そのAGPには、ACRがない場合。
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_DELETE_AGP_CMD[6]
・コマンド引数
1.セッションID−1バイト
2.バイトでのAGP名/ID長さ−1バイト
3.AGP名/ID−
1.2.16 Create ACR
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_CREATE_ACR_CMD[7]
・コマンド引数
1.AGP名/ID−
2.ACR名/ID−
3.ログインアルゴリズム−1バイト
4.キー長さ
5.ブロック解除するACR名/ID
6.管理権の数(ACAM)−1バイト
7.ACAM#1
8.ACAM#n
1.2.17 ACRのアップデート(Update ACR)
このコマンドは、ACRクリエータによってのみ送信することができ、これにより、子ACRを更新する。ルートAGPに存在するACRは、それらに親ACRがないとき、更新することができない。
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_UP_DATE_ACR_CMD[8]
・コマンド引数
1.セッションID−1バイト
2.バイトでのAGP名/ID長さ−1バイト
3.AGP名/ID−
4.バイトでのACR名/ID長さ−1バイト
5.ACR名/ID−
1.2.18 ACRの削除(Delete ACR)
このコマンドは、ACRクリエータによってのみ送信することができ、これにより、子ACRを削除する。ルートAGPに存在するACRは、それら自身を削除する機能を持っている。
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_DELETE_ACR_CMD[9]
・コマンド引数−
1.セッションID−1バイト
2.バイトでのAGP名/ID長さ−1バイト
3.AGP名/ID−
4.バイトでのACR名/ID長さ−1バイト
5.ACR名/ID−
1.2.19 ACRのブロック解除(Unblock ACR)
このコマンドは、この明示的なパーミッションを備えたACRによってのみ送信することができ、これにより、ある特定のACRをブロック解除する。
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_UNBLOCK_ACR_CMD[10]
・コマンド引数
1.セッションID−1バイト
2.バイトでのAGP名/ID長さ−1バイト
3.AGP名/ID−
4.バイトでのACR名/ID長さ−1バイト
5.ACR名/ID−
1.2.20 ドメインパーミッションの委譲(Delegate Domain Permissions)
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_DELEGATE_DOMAIN_PERMISSION_CMD[11]
・コマンド引数
1.セッションID−1バイト
2.委譲するパーミッションの数−1バイト
3.委譲されるパーミッションコード
4.バイトでのドメイン名/ID長さ−1バイト
5.ドメイン名/ID
1.2.21 パーミッションの生成(Create Partition)
このコマンドは、ルートAGPに存在するACRによってのみ送信することができる。
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_CREATE_PARTITION_CMD[12]
・コマンド引数
1.セッションID−1バイト
2.バイトでのパーティション名/ID長さ−1バイト
3.パーティション名/ID
4.セクター[512バイト]内におけるパーティションサイズ−4バイト
5.バイトでの減少されるパーティション名/ID長さ−1バイト
6.減少されるパーティション名/ID
1.2.22 パーミッションのアップデート(Update Partition)
このコマンドは、ルートAGPに存在するACRによってのみ送信することができる。
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_UPDATE_PARTITION_CMD[13]
・コマンド引数
1.セッションID−1バイト
2.バイトでのパーティション名/ID長さ−1バイト
3.パーティション名/ID
4.セクター[512バイト]内におけるパーティションサイズ−4バイト
5.バイトでの減少されるパーティション名/ID長さ−1バイト
6.減少されるパーティション名/ID

1.2.23 パーミッションの削除(Delete Partition)
このコマンドは、ルートAGPに存在するACRによってのみ送信することができる。
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_DELETE_PARTITION_CMD[14]
・コマンド引数
6.セッションID−1バイト
7.バイトでのパーティション名/ID長さ−1バイト
8.パーティション名/ID
1.2.24 公開ドメインへのアクセスの制限(Restrict Public Domain Access)
このコマンドは、正規の、公開パーティション(別名ユーザエリア)を/に、読み取り/書き込むコマンド(ホストによって送信されたコマンドであって、SSAコマンド・プロトコルの一部でない)を、制限する。
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_RESTRICT_PAUBLIC_PARTITION_CMD[15]
・コマンド引数
1.セッションID−1バイト
2.公開パーティション制限コード−1バイト
1.2.25 Create Domain
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_CREATE_DOMAIN_CMD[16]
・コマンド引数
1.セッションID−1バイト
2.バイトでのパーティション名/ID長さ−1バイト
3.パーティション名/ID
4.バイトでのドメイン名/ID長さ−1バイト
5.ドメイン名/ID
1.2.26 ドメインの削除(Delete Domain)
ドメイン・オーナーのみが、このコマンドを送信し、ドメインを削除できる。
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_DELETE_DOMAIN_CMD[17]
・コマンド引数
1.セッションID−1バイト
2.バイトでのパーティション名/ID長さ−1バイト
3.パーティション名/ID
4.バイトでのドメイン名/ID長さ−1バイト
5.ドメイン名/ID
1.2.27 システムログイン(System Login)
このコマンドは、ホストユーザがACRのうちの1つを通してSSAシステムを用いたい場合、発行される。コマンドは、ログイン/認証プロセスを開始する。
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_SYSTEM_LOGIN_CMD[18]
・コマンド引数
1.バイトでのAGP名/ID長さ−1バイト
2.AGP名/ID−
3.バイトでのACR名/ID長さ−1バイト
4.ACR名/ID−
1.2.28 システムログアウト(System Logout)
このコマンドは、ホストユーザがSSAシステムによる作業セッションを終了したい場合、発行される。コマンドは、現在のログインセッションに対するユーザ活動のすべてを終了する。このコマンドの後では、ホストユーザが、SSAシステムによるさらなるアクションを実行することができるようにするには、再びログインプロセスを開始する必要がある。
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_SYSTEM_LOGOUT_CMD[19]
・コマンド引数
1.バイトでのAGP名/ID長さ−1バイト
2.AGP名/ID−
3.バイトでのACR名/ID長さ−1バイト
4.ACR名/ID−
1.2.29 読み込み(Read)
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_READ_CMD[20]
・コマンド引数
1.セッションID−1バイト
2.バイトでのパーティション名長さ−1バイト
3.パーティション名
4.バイトでのドメイン名長さ−1バイト
5.ドメイン名
6.パーティションアドレス(LBA)−4バイト
7.読み取るLBAの数(セクター(Sectors)−セクター(Sector)=512バイト)−4バイト
1.2.30 書き込み(Write)
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_WRITE_CMD[21]
・コマンド引数
1.セッションID−1バイト
2.バイトでのパーティション名長さ−1バイト
3.パーティション名
4.バイトでのドメイン名長さ−1バイト
5.ドメイン名
6.パーティションアドレス(LBA)−4バイト
7.読み取るLBAの数(セクター(Sectors)−セクター(Sector)=512バイト)−4バイト
1.2.31 コマンドステータス(Command Status)
このステータスコマンドを送信することで、先に送信したコマンドのリターン・ステータスを得ることができる。ステータスは、コマンド・プロセスおよびSSAシステム状態を扱う。
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_CMD_STATUS_CMD[22]
・コマンド引数−
1セッションID−1バイト
1.2.32 システムクエリー(System Query)
システムクエリーコマンドは、ログインされるACRの範囲にあるSSA情報を読み取る。
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_SYS_QUERY_CMD[23]
・コマンド引数−
1セッションID−1バイト
1.2.33 パスワード認証コマンド
1.2.33.1 SSAへのパスワード送信
コマンドは、SSAによって確認される実際のACRパスワードを送信する。Command Statusコマンド(22)を送信することで、ホストは、コマンド・ステータスと、そして、コマンド完了と同時に、認証プロセスのステータス−PASS/FAIL−と、を読み取ることができる。
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_PWD_AUTH_SEND PWD_CMD[24]
・コマンド引数
1.バイトでのパスワード長さ−1バイト
2.パスワードデータ
1.2.34 対称形的認証コマンド
1.2.34.1 SSAからのチャレンジ受け取り
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_SYM_AUTH_GET_CHLG_CMD[25]
・コマンド引数
1.2.34.2 SSAへのチャレンジ送信
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_SYM_AUTH_SEND_CHLG_CMD[26]
・コマンド引数
1.2.34.3 SSAからのチャレンジレスポンス受け取り
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_SYM_AUTH_GET_CHLG_RES_CMD[27]
・コマンド引数
1.2.34.4 SSAからのチャレンジレスポンス送信
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_SYM_AUTH_SEND_CHLG_RES_CMD[28]
・コマンド引数
1.2.35 非対称形認証プロセスコマンド
1.2.35.1 SSAへのチャレンジ送信
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_ASYM_AUTH_SEND_CHLG_CMD[29]
・コマンド引数−チャレンジ乱数−28バイト
1.2.35.2 SSAからのチャレンジ受け取り
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_ASYM_AUTH_GET_CHLG_CMD[30]
・コマンド引数−NA
1.2.35.3 SSAへのCA証明書の送信
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_ASYM_AUTH_SEND_CA_CERT_CMD[31]
・コマンド引数
1.2.35.4 SSAプレ・マスター・シークレットの受け取り
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_ASYM_AUTH_GET_PRE_MASTER_SECRET_CMD[32]
・コマンド引数
1.2.35.5 SSAからのACR証明書の受け取り
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_ASYM_AUTH_GET_CHLG_CMD[33]
・コマンド引数
1.2.35.6 SSAへのホスト・プレ・マスター・シークレットの送信
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_ASYM_AUTH_SEND_PRE_MASTER_SECRET_CMD[34]
・コマンド引数
1.2.35.7 スタート・セッション・マッサージの送信
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_ASYM_AUTH_SEND_START_SESSION_MSG_CMD[35]
・コマンド引数
1.PINオプション−
2.バイトでのPIN長さ
3.PINストリング
1.2.35.8 SSAからの認証の総合的なメッセージの受け取り
コマンド構造:
・コマンド名/OP Code−1バイト:SSA_SYM_AUTH_GET_CHLG_CMD[36]
・コマンド引数
1.3 SSAコマンド引数
1.3.1 Not Applicable
引数リストにおいてNot Applicable (NA)として定義されたすべてのフィールドは、0でなければならない。
1.3.2 パスワードおよびPIN構造
パスワードおよびPINフレーズは20バイトの長さであり、SSAシステムに対してバイナリー値である。20バイトより短いフレーズには「0」を追加しなければならない。

1.3.3 ログインアルゴリズム
この引数は、ACRのログインアルゴリズムを定義する。それは、1バイトの長さである。利用可能な値は、以下のテーブルに定義される。

1.3.4 対称的信用証明シンボル

1.3.5 非対称形信用証明タイプ

1.3.6 パーティション権

1.3.7 ドメイン権

1.3.8 ドメインパーミッションコード

1.3.9 ACAM

1.3.10 公開パーティション制限コード

1.3.11 コマンドステータス

1.3.12 SSAクエリー

1.3.13 コマンドシーケンス
1.3.13.1 SSAログインに対する相互対称的認証を介したコマンドシーケンス

このシーケンスが正常に行われた場合、SSAのACRがログインされ、SSAオペレーションを開始することができる。
1.3.13.2 ルートAGPを生成するコマンドシーケンス
ルートAGPは、システムACR(システムACRへのログインシーケンスを実行するよう、要求する)を介して、あるいはセキュアなチャンネルを断念し、システムACR認証プロセスをスキップして生成することができる。コマンドSSA_CREATE_ROOT_AGP_CMD[3]は、ルートAGPのアイデンティティとともに送信される。
このコマンドは、SSA_CMD_STATUS_CMD[22]に続いて行うことができ、これにより、SSAがコマンドを拒絶せず、それがエラーなしで終わったことを確かめる。ルートAGPが執行された且つその全てのACRが生成され、これにより、ルートAGPが封印された場合、SSA_ROOT_AGP_CREATION_DONE_CMD[4]コマンドが送信される。
1.3.13.3 AGPを生成するコマンドシーケンス
AGPを生成するためには、ユーザは、1.3.13.1に示したログイン・コマンド・シーケンスを実行することにより、SSAにまずログインしなければならない。AGPは、ACRの新しいグループを生成する前に、生成されなければならない。AGPは、コマンドSSA CREATE_AGP_CMD[5]をAGP名/IDとともに送信するよって、生成される。
CMD[5]がエラーなく受け取られ実行されたことを確認するために、ユーザはSSA_CMD_STATUS_CMD[22]を送信し、先に送信されたコマンドのステータスを読み取る。ユーザがAGPを生成し終えたとき、続いて、ACRを生成する、あるいはSSAシステムからログアウトことができる。
1.3.13.4 ACRを生成するコマンドシーケンス
ACRを生成するためには、ユーザは、1.3.13.1に示したログイン・コマンド・シーケンスを実行することにより、SSAにまずログインしなければならない。また、新しいACRに属するAGPがあるはずである。そして、ユーザは、新しいACRデータ(名前、AGP、ログイン方法等)のすべてとともに、コマンドSSA_CREATE_ACR_CMD[7]を送信する。CMD[7]がエラーなく受け取られ実行されたことを確認するために、ユーザはSSA_CMD_STATUS_CMD[22]を送信し、先に送信されたコマンドのステータスを読み取る。ユーザがACRを生成し終えたとき、続いて、他のSSAオペレーション、あるいはSSAシステムからログアウトを行うことができる。
1.4 プロダクトパラメータ
・すべてのエンティティの最大値(MARO、ARCR、並列セッションなど)
・適用可能である暗号パラメータ、つまりRSAキー長さ、に対する定義を追加
・プロトコル当たりのエラー条件およびメッセージを定義する必要
・タイムアウトおよびビジーの扱いを定義する必要。
・ツリーのレベル数の指定
・ルートMAROの制限#
・子(ルート上の)制限#すべて?委譲はそこまで
・並列におけるCBCコンテキストの数には、5〜10などの制限がある。
・プロトコルおよびプロダクトバージョン

【特許請求の範囲】
【請求項1】
ストレージシステムのオペレーション方法であって、
前記システムは、不揮発性メモリと、前記メモリへのアクセスをコントロールするコントローラと、を備えており、そのうち、前記コントローラあるいはメモリは、少なくとも第1および第2の階層的ツリーを記憶し、その少なくとも第1および第2の階層的ツリーが、第1および第2の対応するセットエンティティによる前記メモリに記憶されたデータへのアクセスをコントロールする異なるレベルにおけるノードを含んでおり、
前記ツリーのそれぞれのノードは、メモリデータにアクセスするための対応するエンティティのパーミッションを指定し、
前記ツリーのそれぞれのノードにおけるパーミッションは、同じツリー内のより高いあるいはより低いレベルでの他のノードにおけるパーミッションと所定の関係を有しており、
前記方法は、
前記第1および第2の対応するセットのエンティティからのメモリデータへのアクセス要求を受信するステップと、
第1および第2の階層的ツリーのノードでのパーミッションに応じて、前記第1および第2の対応するセットのエンティティからのメモリデータへのアクセスをコントロールするステップであって、前記第1および第2の対応するセットのエンティティによるメモリデータへの前記アクセスにクロストークがないステップと、
を備えている方法。
【請求項2】
前記少なくとも2つのツリーは、メモリ内の2つの別々のセットのデータのへアクセスをコントロールし、前記コントロールは、前記第1および第2の対応するセットのエンティティのそれぞれが、前記2つのセットのデータの対応するセットにアクセスすることを可能にする、請求項1に記載の方法。
【請求項3】
前記コントロールは、前記第1および第2の対応するセットのエンティティが、2つの別々のコンピュータアプリケーションを用いて、データにアクセスすることを可能にする、請求項2に記載の方法。
【請求項4】
前記それぞれのツリーのノードにおける前記パーミッションは、前記ツリーにおけるより低いレベルでのノードのパーミッションによって示されるアクセス権限以上のメモリ内のデータへのアクセス権限を示す、請求項1に記載の方法。
【請求項5】
前記少なくとも1つのツリーの同じレベルでの複数のノードは、グループを形成し、
また、前記コントロールは、前記グループのノードの対応するエンティティが少なくとも1つの共通鍵を用いて前記メモリ中のデータにアクセスすることを許可する、請求項1に記載の方法。
【請求項6】
前記グループのノードの対応するエンティティのパーミッションは、前記少なくとも1つの共通鍵を用いて、前記メモリ中のデータにアクセスする際、異なる権限を許可する、請求項5に記載の方法。
【請求項7】
前記コントロールは、前記少なくとも1つの共通キーを用いた、第1のエンティティによる前記メモリ中のデータへの読み取り専用アクセスと、ツリーのノードのパーミッションに応じて、前記少なくとも1つの共通キーを用いた、第2のエンティティによる前記メモリ中のデータへの読み取りおよび書き込みアクセスと、を許可する、請求項6に記載の方法。
【請求項8】
ツリーのノードにおける前記パーミッションは、前記メモリ中のデータを暗号化および/または復号するための鍵へのアクセスするためのものである、請求項1に記載の方法。
【請求項9】
前記コントロールは、ツリーのノードのパーミッションに応じて、前記メモリの1つ以上のパーティションへのアクセスを許可する、請求項1に記載の方法。
【請求項10】
不揮発メモリと、
前記メモリへのアクセスをコントロールするコントローラと、
を備えるセキュアストレージシステムであって、
前記コントローラあるいはメモリは、少なくとも第1および第2の階層的ツリーを記憶し、その少なくとも第1および第2の階層的ツリーが、第1および第2の対応するセットのエンティティによるメモリに記憶されたデータへのアクセスをコントロールする異なるレベルにおけるノードを含んでおり、
前記ツリーのそれぞれのノードは、メモリデータにアクセスするための対応するエンティティのパーミッションを指定し、
前記ツリーのそれぞれのノードにおけるパーミッションは、同じツリーのより高いあるいはより低いレベルでの他のノードにおけるパーミッションと、所定の関係を有しており、
前記少なくとも2つのツリー間には、クロストークがない、
セキュアストレージシステム。
【請求項11】
前記少なくとも2つのツリーは、メモリ内の2つの別々のセットのデータのへアクセスをコントロールし、前記少なくとも2つのツリーのそれぞれが、前記2つのセットのデータの対応するセットへのアクセスをコントロールする、請求項10に記載のシステム。
【請求項12】
前記少なくとも2つのツリーは、2つの別々のコンピュータアプリケーションを用いてアクセスをコントロールする、請求項11に記載のシステム。
【請求項13】
前記それぞれのツリーのノードにおける前記パーミッションは、前記同じツリーのより低いレベルのノードにおけるパーミッションによって示されるアクセス権限以上の前記メモリ内のデータへのアクセス権限を示す、請求項10に記載のシステム。
【請求項14】
前記少なくとも1つのツリーの同じレベルの複数のノードは、グループを形成し、前記グループのノードにおいて対応するエンティティのパーミッションが、少なくとも1つの共通鍵を用いて前記メモリ中のデータにアクセスすることを許可する、請求項10に記載のシステム。
【請求項15】
前記グループのノードでの対応するエンティティのパーミッションは、前記少なくとも1つの共通鍵を用いて、前記メモリ中のデータにアクセスする際、異なる権限を許可する、請求項14に記載のシステム。
【請求項16】
前記グループのノードの前記1つでの対応するエンティティのパーミッションは、前記少なくとも1つの共通鍵を用いた、第1のエンティティによる前記メモリ中のデータへの読み取り専用アクセスと、前記少なくとも1つの共通鍵を用いた、第2のエンティティによる前記メモリ中のデータへの読み取りおよび書き込みアクセスと、を許可する、請求項15に記載の方法。
【請求項17】
ツリーのノードにおける前記パーミッションは、前記メモリ中のデータを暗号化および/または復号するためのキーへのアクセスするためのものである、請求項10に記載のシステム。
【請求項18】
ツリーのノードにおける前記パーミッションは、前記メモリの1つ以上のパーティションへアクセスするためのものである、請求項10に記載のシステム。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8A】
image rotate

【図8B】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate

【図12】
image rotate

【図13】
image rotate

【図14】
image rotate

【図15】
image rotate

【図16】
image rotate

【図17A】
image rotate

【図17B】
image rotate

【図18】
image rotate

【図19】
image rotate

【図20】
image rotate

【図21】
image rotate

【図22】
image rotate


【公表番号】特表2008−524757(P2008−524757A)
【公表日】平成20年7月10日(2008.7.10)
【国際特許分類】
【出願番号】特願2007−548522(P2007−548522)
【出願日】平成17年12月21日(2005.12.21)
【国際出願番号】PCT/US2005/046793
【国際公開番号】WO2006/069311
【国際公開日】平成18年6月29日(2006.6.29)
【出願人】(507208288)サンディスク コーポレーション (11)
【Fターム(参考)】