JP2008524758A - 多目的コンテンツ制御をするコントロール構造の生成システム - Google Patents

Abstract

【解決手段】
モバイルストレージデバイスは、異なるレベルにあるノードを有する少なくとも1つの階層的ツリーを生成できるシステムエージェントを、備えることができ、これにより、対応するエンティティによるメモリに記憶されたデータへのアクセスをコントロールしている。ツリーのそれぞれのノードは、メモリデータにアクセスするための対応するエンティティの許可を指定する。それぞれのツリーのノードにおけるパーミッションは、同じツリーの内での、より高い、より低い、あるいは同じレベルのノードにおけるパーミッションと、所定の関係を有する。したがって、モバイルストレージデバイスは、既に作られたツリーなしに完成され、これにより、デバイスの購入者には、購入者が想定しているアプリケーションに適した階層的ツリーを生成する際に、自由裁量がある。あるいは、モバイルストレージデバイスは、ツリーが既に生成された状態で完成することもでき、これにより、購入者は、ツリーを生成するというような煩わしさを受けずにすむ。どちらの状況でも、デバイスが作成された後、ツリーのある機能を、固定することができ、さらに変更や部分変更することができないほうが好ましい。ツリーのある機能を、固定することができる。これにより、コンテンツオーナーによる、デバイス中のコンテンツへのアクセスに対するより優れたコントロールを、提供する。したがって、ある実施形態では、好ましくは、システムエージェントは無効とすることができ、これにより、追加のツリーを生成することができないようにできる。
【選択図】 図６

Description

本発明は、概してメモリシステムに関し、特に多目的なコンテンツ制御の機能を備えたメモリシステムに関する。

コンピュータデバイス市場は、さらなるデータ交換を行うことにより平均収益を増加させるべく、モバイルストレージデバイスにコンテンツストレージを組み込む方向に発展している。これは、コンピュータデバイスで使用する際に、モバイルストレージメディアのコンテンツを保護する必要があることを意味する。コンテンツは貴重なデータを含むが、これはストレージデバイスの製造者または販売者以外の者が所有するデータであるかもしれない。

米国特許第６４５７１２６号には、暗号機能を備えた一つの種類のストレージデバイスが記載されている。しかし、当該デバイスにより提供される機能はかなり制限（ｑｕｉｔｅ ｌｉｍｉｔｅｄ）されている。したがって、メモリシステムにより多目的にコンテンツを制御する機能を提供することが望ましい。

モバイルストレージメディア内のコンテンツの保護には、権限のあるユーザまたはアプリケーションのみがメディアに保存されたデータを暗号化するために使用された鍵へのアクセスを有するように、メディア内のデータの暗号化を含めることが可能である。幾つかの従来のシステムでは、データの暗号化および復号に使用された鍵がモバイルストレージメディアの外部のデバイスに保存されている。こうした環境では、コンテンツの所有権を有する企業または個人は、メディア内のコンテンツ利用に関してそれ程管理していない場合がある。メディア内のデータを暗号化するために使用された鍵がメディアの外部に存在するので、当該鍵はコンテンツ所有者による管理を前提としない方法で、あるデバイスから別のデバイスへ渡される可能性がある。本発明の機能の一つによれば、暗号・復号鍵がメディア自体に保存されており、外部デバイスに実質的にアクセス不可能であれば、所有権の所有者は、メディア内のコンテンツへのアクセスを管理し易い。

原則的にメディア外部からの鍵へのアクセスを不可能にすることにより、当該機能は保護されたコンテンツに移植性（ｐｏｒｔａｂｉｌｉｔｙ）を与える。このように、そうした鍵で暗号化された保護コンテンツを含むストレージデバイスは、鍵へのアクセスに関して排他的制御を有しているので、機密保護違反の危険性を有することなく、様々なホストデバイスによるアクセスに使用することが可能となる。適切な証明書をもつホストデバイスのみが、鍵へアクセスできる。

モバイルストレージメディアに保存されたコンテンツの商業価値を高めるために、コンテンツ中の所有権の所有者が、当該コンテンツへのアクセスに関して、様々なエンティティ（ｅｎｔｉｔｙ）に様々なパーミッション（ｐｅｒｍｉｓｓｉｏｎ）を与えることができることが望ましい。したがって、本発明の他の機能は、メディアに保存されたデータへのアクセスに関して、様々なパーミッションを（例えば、様々な認定エンティティに対して）与えるといったアクセスポリシー（ａｃｃｅｓｓ ｐｏｌｉｃｙ）を保存し得るという認識に基づいている。上記２つの機能の組み合わせを組み込むシステムは特に有益である。ひとつは、コンテンツ所有者または所有権者は、外部デバイスに実質的にアクセス不可能な鍵の使用によりコンテンツへのアクセスを管理する能力をもち、同時に、メディアのコンテンツをアクセスするためのパーミッションを与える能力をもつ。このように、外部デバイスがアクセスを獲得したとしても、それらのアクセスは、いまだストレージメディアに記録されたコンテンツの所有者または所有権者によって設定された様々なパーミッションに従い得る。

他の機能は、様々な権限のあるエンティティに異なるパーミッションを与えるという上記ポリシーがフラッシュメモリで実行される場合、コンテンツ保護に特に有用なメディアをもたらすという認識に基づく。

多くのコンピュータホストデバイスは、ファイル形式でデータの読み出しおよび書き込みを実行するが、多くのストレージデバイスはファイルシステムを認識しない。他の機能によれば、ホストデバイスはキーリファレンス（ｋｅｙ ｒｅｆｅｒｅｎｃｅ）またはＩＤを提供し、これに応じてメモリシステムは、鍵ＩＤ（ｋｅｙ ＩＤ）に関連する鍵値（ｋｅｙ ｖａｌｕｅ）を生成し、ここで、鍵値は鍵ＩＤに関連しているファイル中のデータを暗号処理する際に使用される。ホストは、鍵ＩＤをメモリシステムによって暗号処理されるファイルと関連付ける。このように、ホストがファイルの制御を維持しつつ、鍵ＩＤは、メモリが暗号プロセス用の鍵値の生成および使用に対して完全で排他的な制御を維持するハンドル（ｈａｎｄｌｅ）として、コンピュータデバイスおよびメモリによって使用される。

スマートカード等のモバイルストレージデバイスの中には、カードコントローラがファイルシステムを管理する。例えば、フラッシュメモリ、磁気ディスクまたは光ディスク等、多くの他の種類のモバイルストレージデバイスでは、デバイスコントローラがファイルシステムを認識しない。その代わりに、デバイスコントローラはファイルシステムを管理するために、ホストデバイス（例えば、パーソナルコンピュータ、デジタルカメラ、ＭＰ３プレーヤ、携帯情報端末、携帯電話）に依存している。本発明の様々な態様は、デバイスコントローラがファイルシステムを認識しないタイプのストレージデバイスに直ちに組み込むことが可能である。これは、本発明の様々な機能が、多種多様の既存のモバイルストレージデバイスにデバイスを再設計することなく、デバイスがファイルシステムを認識して管理するようにデバイスコントローラを作ることが実施し得ることを意味する。

ストレージメディアに保存されたツリー構造は、エンティティがアクセスの獲得後でさえ実行可能な事柄に対して制御することを与えるものである。ツリーを構成する複数ノード（ｎｏｄｅ）の各々は、当該ツリーのノードを通じたエントリ（ｅｎｔｒｙ）を獲得したエンティティによるパーミッションを特定する。ツリーの中には、異なるレベル（ｌｅｖｅｌ）を有しているものもあり、この場合、ツリーのノードにおける一または複数のパーミッションが、同一ツリー内の高位レベル、低位レベル、または同一レベルとなる他のノードにおける一つまたは複数のパーミッションと所定の関係を有する。エンティティに対して、各ノードでこのように特定されたパーミッションに従うことを要求することにより、このアプリケーションのツリーの機能は、ツリーが異なるレベルを有しているか否かに関係なく、どのエンティティが動作可能で、且つ、各エンティティのどの動作が可能であるかについてコンテンツ所有者に制御することを可能とする。

モバイルストレージメディアにより提供可能な商業価値を高めるために、モバイルストレージデバイスが複数のアプリケーションを同時にサポート可能であることが望ましい。２以上のアプリケーションがモバイルストレージデバイスに同時にアクセスする場合、当該アプリケーションが、ここでクロストーク（ｃｒｏｏｓｔａｌｋ）と称す現象で相互干渉しないように、当該アプリケーションのオペレーションを分離可能であることが重要になる。したがって、本発明の他の機能は、好ましくは階層構造になっている２以上のツリーを、メモリへのアクセス制御に提供し得るという認識に基づく。各ツリーは、対応する複数のエンティティセットによるデータへのアクセスを制御するために、異なるレベルのノードを備えており、この場合、各ツリーのノードは、対応する一または複数のエンティティがメモリデータにアクセスするための一または複数のパーミッションを特定する。各ツリーのノードにおける一または複数のパーミッションが、同一ツリー内の高位レベルまたは低位レベルの他のノードにおける一または複数のパーミッションと所定の関係を有する。少なくとも、２つのツリー間でクロストークが存在しないことが好ましい。

以上から、ツリーがコンテンツセキュリティに使用可能な強力な構造であることは明白である。提供される重要な制御の一つは、ツリー生成に対する制御である。このように、本発明に係る他の機能によれば、モバイルストレージデバイスは、対応するエンティティによりメモリ内に保存されたデータへのアクセス制御のために、異なるレベルのノードを備えた少なくとも一つの階層ツリーを生成可能なシステムエージェント（ｓｙｓｔｅｍ ａｇｅｎｔ）が備えられてもよい。ツリーの各ノードは、メモリデータへのアクセスのために、対応する一または複数のエンティティの一つ又は複数のパーミッションを特定する。各ツリーのノードにおける一または複数のパーミッションが、同一ツリー内の高位レベル、低位レベル、または同一レベルのノードでの一または複数のパーミッションと所定の関係を有する。このように、モバイルストレージデバイスは、デバイス購入者が自身の考えるアプリケーションに適用される階層ツリーを自由に生成できるように、既に生成された任意のツリーを使用することなく発行（ｉｓｓｕｅｄ）されてもよい。あるいは、モバイルストレージデバイスは、購入者が面倒なツリーの生成をする必要がないように、既に生成されたツリーを使用して発行されてもよい。両方の状況において、ツリーの所定の機能をさらに変更または修正できないように、デバイス製造後に当該機能を確定可能であることが好ましい。これは、コンテンツ所有者によるデバイス内のコンテンツへのアクセスに対して、さらなる制御を提供する。このように、一実施形態においては、追加のツリーを生成できないように、システムエージェントの無効化が可能であることが好ましい。

モバイルストレージデバイスの中には、コンテンツ保護は、保護領域へのアクセスが事前認証を必要とする別々の領域にメモリを分割することにより得られるものがある。このような態様により、何らかの保護が提供されるのであるが、違法な手段でパスワードを取得したユーザから保護するものではない。このように、本発明の他の態様は、メカニズムまたは構造がメモリを複数のパーティションに分割するようにすることができて、少なくともパーティションにおけるデータの中には、鍵を用いて暗号化することが可能なものもあるという認識に基づくものであり、結果として、複数のパーティションの一部へのアクセスに必要な認証に加えて、一または複数の鍵へのアクセスがこうしたパーティションにおける暗号化データの復号に必要となる。

幾つかのアプリケーションでは、ユーザが一つのアプリケーションを使用してメモリシステムにログインし、その後、再度ログインすることなく保護コンテンツにアクセスするために、異なるアプリケーションを使用可能であるという点が、さらに便利であるかもしれない。こうしたイベントでは、この方法でユーザがアクセスを望むコンテンツのすべてが、第１のアカウントに関連付けられ、結果として、複数回数のログインを必要とせず、異なるアプリケーション（例えば、音楽プレーヤ、Ｅメール、移動体通信等）を経由して、当該コンテンツにアクセス可能となるようにしてもよい。そして、異なる認証情報セットは、たとえ異なる複数アカウントが同一ユーザまたはエンティティに設定されている場合であっても、第１のアカウントとは異なるアカウントに存在する保護コンテンツにアクセスするためのログインに使用されてもよい。

上記機能は、コンテンツ所有者に対する制御および／または保護のさらなる汎用性（ｖｅｒｓａｔｉｌｉｔｙ）を提供するためのストレージシステムにおいて、個別に使用し、または如何なるコンビネーションで組み合わせてもよい。
米国特許第６４５７１２６号

本発明に関する様々な態様を実施し得るメモリシステムの一例が、図１のブロック図により例示されている。図１に図示されているように、メモリシステム１０は、中央演算装置（CPU）１２、バッファマネジメントユニット（ｂｕｆｆｅｒ ｍａｎａｇｅｍｅｎｔ ｕｎｉｔ；ＢＭＵ）１４、ホストインタフェイスモジュール（ｈｏｓｔ ｉｎｔｅｒｆａｃｅ ｍｏｄｕｌｅ；ＨＩＭ）１６、フラッシュインタフェイスモジュール（ｆｌａｓｈ ｉｎｔｅｒｆａｃｅ ｍｏｄｕｌｅ；ＦＩＭ）１８、フラッシュメモリ２０およびペリフェラルアクセスモジュール（ｐｅｒｉｐｈｅｒａｌ ａｃｃｅｓｓ Ｍｏｄｕｌｅ；ＰＡＭ）２２を備える。メモリシステム１０は、ホストインタフェイスバス２６およびポート２６ａを介してホストデバイス２４と通信する。フラッシュメモリ２０（ＮＡＮＤ型であってもよい）は、ホストデバイス２４にデータストレージを提供する。ＣＰＵ１２用のソフトウェアコードもフラッシュメモリ２０に保存されてもよい。ＦＩＭ１８は、フラッシュインタフェイスバス２８およびポート２８ａを介してフラッシュメモリ２０に接続する。ＨＩＭ１６は、例えば、デジタルカメラ、パーソナルコンピュータ、携帯情報端末（ＰＤＡ）、デジタルメディアプレーヤ、ＭＰ３プレーヤ、携帯電話、その他のデジタルデバイス等のホストシステムへの接続に適している。ペリフェラルアクセスモジュール２２は、例えば、ＣＰＵ１２と通信するためのＦＩＭ，ＨＩＭおよびＢＭＵ等の適切なコントローラモジュールを選択する。一実施形態においては、点線で示すボックス内のシステム１０の全構成要素が、例えばメモリカードやスティック１０’等の単一ユニットに含まれていてもよく、カプセル化されていることが好ましい。

ここで、本発明はフラッシュメモリを参照することにより説明されているが、例えば磁気ディスクや光学式ＣＤ等の他のタイプのメモリだけでなく、あらゆるタイプの書き換え可能な不揮発性メモリシステムに適用してもよい。

バッファマネジメントユニット１４は、ホストダイレクトメモリアクセス（ｈｏｓｔ ｄｉｒｅｃｔ ｍｅｍｏｒｙ ａｃｃｅｓｓ；ＨＤＭＡ）３２、フラッシュダイレクトメモリアクセス（ｆｌａｓｈ ｄｉｒｅｃｔ ｍｅｍｏｒｙ ａｃｃｅｓｓ；ＦＤＭＡ）３４、アービタ（ａｒｂｉｔｅｒ）３６、バッファランダムアクセスメモリ（ｂｕｆｆｅｒ ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ；ＢＲＡＭ）３８および暗号化エンジン（ｃｒｙｐｔｏ−ｅｎｇｉｎｅ）４０を備える。アービタ３６は共有バスアービタであり、これにより、一つのマスタまたはイニシエータ（ｉｎｉｔｉａｔｏｒ；ＨＤＭＡ３２、ＦＤＭＡ３４またはＣＰＵ１２がこれに該当し得る）のみが常時アクティブになることが可能である。また、スレーブまたはターゲットはＢＲＡＭ３８である。アービタは、適切なイニシエータ要求をＢＲＡＭ３８にチャネル接続させる役割を担う。ＨＤＭＡ３２およびＦＤＭＡ３４は、ＨＩＭ１６、ＦＩＭ１８およびＢＲＡＭ３８またはＣＰＵランダムアクセスメモリ（ＣＰＵ ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ；ＣＰＵ ＲＡＭ）１２ａ間で伝送されたデータに対する役割を担う。ＨＤＭＡ３２のオペレーションおよびＦＤＭＡ３４のオペレーションは従来から実施されているので、ここでは詳細な説明を省略する。ＢＲＡＭ３８は、ホストデバイス２４およびフラッシュメモリ２０間で伝送されたデータを保存するために使用される。ＨＤＭＡ３２およびＦＤＭＡ３４は、ＨＩＭ１６／ＦＩＭ１８およびＢＲＡＭ３８、またはＣＰＵ ＲＡＭ１２ａ間のデータ伝送、およびセクタ完了の表示に関する役割を担う。

メモリシステム１０は、メモリ２０に保存されたコンテンツの安全性を向上させるために、暗号化および／または復号用に使用される（一または複数の）鍵値を生成し、ここでは、当該鍵値は、ホストデバイス２４等の外部デバイスへのアクセスが実質的に不可能である。しかし、暗号化および復号は典型的にはファイル単位で実行されるが、これは、ホストデバイスがメモリシステム１０に対してファイル形式でデータの読み出しおよび書き込みを実行するからである。多くの他の種類のストレージデバイスと同様に、メモリデバイス１０はファイルまたはファイルシステムを認識しない。メモリ２０はファイルの論理アドレスが識別されるファイルアロケーションテーブル（ｆｉｌｅ ａｌｌｏｃａｔｉｏｎ ｔａｂｌｅ；ＦＡＴ）を保存するが、ＦＡＴは、典型的にはコントローラ１２ではなくホストデバイス２４によってアクセスおよび管理される。したがって、特定ファイルのデータを暗号化するために、特定ファイルのデータはシステム１０にのみ利用可能な（一または複数の）鍵値を使用するシステム１０によって認識されて、暗号化および／または復号できるように、コントローラ１２はメモリ２０内のファイルのデータの論理アドレスを送信するために、ホストデバイスに依存しなければならない。

ファイル内のデータを暗号処理する（一または複数の）同一鍵を参照するホストデバイス２４およびメモリシステム１０の両方にハンドルを提供するために、ホストデバイスは、システム１０により生成された各々の鍵値に対して参照を提供し、ここでは、当該参照は単なる鍵ＩＤとしてもよい。このように、ホスト２４はシステム１０により暗号化処理される各ファイルを鍵ＩＤと関連付け、システム１０はデータの暗号処理に使用される各鍵値をホストにより提供された鍵ＩＤと関連付ける。このように、ホストがファイルの暗号化処理を要求する場合、ホストは、鍵ＩＤと、メモリ２０からフェッチされ、またはメモリ２０に保存されるデータの論理アドレスと共に、当該要求をシステム１０に送信する。システム１０は鍵値を生成し、ホスト２４により提供された鍵ＩＤと当該値を関連付けて、暗号化プロセスを実行する。この方法では、メモリシステム１０の動作方法に変更を加える必要はないが、システム１０が（一または複数の）鍵値への排他的アクセスを含む（一または複数の）鍵を使用する暗号化処理を完全に制御することができる。即ち、ＦＡＴの排他的制御により、システム１０はホスト２４のファイル管理を継続して可能にする。その一方で、システム１０は暗号化処理に使用される（一または複数の）鍵値の生成および管理を行うために排他的制御を維持する。ホストデバイス２４は、データの暗号処理に使用される（一または複数の）鍵値の生成および管理に一切関与しない。

ホスト２４により提供された鍵ＩＤおよびメモリシステムにより生成された鍵値は、以下、実施形態の一つにおいて「コンテンツ暗号鍵（ｃｏｎｔｅｎｔ ｅｎｃｒｙｐｔｉｏｎ ｋｅｙ）」またはＣＥＫとして称される、数量に関する２つの属性を形成する。ホスト２４は各鍵ＩＤを一または複数のファイルと関連付けるが、ホスト２４は、各鍵ＩＤを整理されていないデータまたは何らかの方法で整理されたデータとも関連付けるものの、これは完全なファイルに整理されたデータに限定されない。

ユーザまたはアプリケーションは、システム１０における保護コンテンツまたは保護領域へのアクセスを獲得するために、システム１０に事前登録された証明書を使用して認証を受ける必要がある。証明書（ｃｒｅｄｅｎｔｉａｌ）とは、証明書を有する特定のユーザまたはアプリケーションに許可されるアクセス権限に関係するものである。事前登録プロセスにおいて、システム１０はユーザまたはアプリケーションの身元（ｉｄｅｎｔｉｔｙ）および証明書の記録、およびユーザまたはアプリケーションにより決定され、ホスト２４を通じて提供された当該身元および証明書と関連付けられたアクセス権限（ａｃｃｅｓｓ ｒｉｇｈｔｓ）を保存する。事前登録の完了後、ユーザまたはアプリケーションがメモリ２０へのデータ書き込みを要求する場合、ホストデバイスを通じて、その身元および証明書、データ暗号化用の鍵ＩＤおよび暗号化データが保存される論理アドレスを提供する必要がある。システム１０は、鍵値を生成し、当該値をホストデバイスにより提供された鍵ＩＤと関連付け、書き込まれるデータの暗号化に使用される鍵値に対応する鍵ＩＤを当該ユーザまたはアプリケーションに関する記録またはテーブルに保存する。その後、システム１０はデータを暗号化し、生成した鍵値だけでなく、暗号化データをホストにより指定されたアドレスに保存する。

ユーザまたはアプリケーションがメモリ２０からの暗号化データの読み出しを要求する場合、その身元および証明書と、要求されたデータを暗号化するために以前使用された鍵に対応する鍵ＩＤと、暗号化データが保存される論理アドレスと、を提供する必要がある。その後、システム１０はホストにより提供されたユーザまたはアプリケーションの身元および証明書と、その記録内に保存された身元および証明書と、を照合する。両者が一致した場合、システム１０は、ユーザまたはアプリケーションにより提供された鍵ＩＤに関連付けられた鍵値をメモリからフェッチし、鍵値を使用して、ホストデバイスにより指定されたアドレスに保存されたデータを復号し、復号されたデータをユーザまたはアプリケーションに送信する。

認証証明書を暗号化処理に使用される鍵の管理と分離することにより、証明書を共有することなくデータへのアクセス権限を共有することが可能となる。このように、異なる証明書を有するユーザグループまたはアプリケーショングループは、同一データにアクセスするための同一鍵へのアクセスを有することが可能であるが、当該グループ以外のユーザはアクセスすることができない。グループ内のすべてのユーザまたはアプリケーションは、同一データへのアクセスを有することが可能であるが、当該ユーザまたはアプリケーションは異なる権利を有する。このように、ユーザまたはアプリケーションの中に、読み出しのみのアクセスを有する者があってもよく、それ以外のユーザまたはアプリケーションが書き込みのみのアクセスを有しても良く、その他のユーザまたはアプリケーションが両方のアクセスを有してもよい。システム１０は、ユーザまたはアプリケーションの身元および証明書の記録、ユーザまたはアプリケーションがアクセスする鍵ＩＤ、および各鍵ＩＤに対する関連付けられたアクセス権限を維持するので、システム１０は、鍵ＩＤの追加または削除、および特定のユーザまたはアプリケーション用の当該鍵ＩＤに関連付けられたアクセス権限の変更、あるユーザまたはアプリケーションから他のユーザまたはアプリケーションへのアクセス権限の委譲、複数ユーザまたはアプリケーション用の記録またはテーブルの削除または追加までも実行することが可能となり、これらすべてが適切に認証されたホストデバイスにより制御される。保存された記録は、セキュアチャネル（ｓｅｃｕｒｅ ｃｈａｎｎｅｌ）が所定の鍵へのアクセスに必要であることを特定してもよい。認証は、パスワードだけでなく、対称アルゴリズム（ｓｙｍｍｅｔｒｉｃ ａｌｇｏｒｉｔｈｍ）または非対称アルゴリズム（ａｓｙｍｍｅｔｒｉｃ ａｌｇｏｒｉｔｈｍ）を使用して実行されてもよい。

特に重要なのは、メモリシステム１０における保護されたコンテンツ（ｓｅｃｕｒｅｄ ｃｏｎｔｅｎｔ）の移植性である。鍵値はメモリシステムにより生成され、実質的に外部システムには利用できないので、メモリシステムまたは当該システムを組み込んでいるストレージデバイスが、ある外部システムから他の外部システムに伝送される場合、そこに保存されたコンテンツの安全性が維持され、外部システムは、メモリシステムに完全制御された方法で認証を受けない限り、当該コンテンツにアクセスすることができない。こうした認証後でさえ、アクセスはメモリシステムにより完全制御され、外部システムはメモリシステムに事前設定された記録に応じて制御される方法でのみアクセス可能である。要求は、そうした記録と適合しない場合には拒否される。

コンテンツ保護をさらに柔軟にするために、以下パーティション（ｐａｒｔｉｔｉｏｎ）と称すメモリの所定の領域が適切に認証されたユーザまたはアプリケーションによってのみアクセス可能であることが想定される。上記の鍵ベースのデータ暗号化の特性を組み合わせた場合、システム１０は優れたデータ保護機能を提供する。図２に示されるように、フラッシュメモリ２０は多くのパーティション、即ち、ユーザ領域（ｕｓｅｒ ａｒｅａ）またはユーザパーティション（ｕｓｅｒ ｐａｒｔｉｔｉｏｎ）、およびカスタムパーティション（ｃｕｓｔｏｍ ｐａｒｔｉｔｉｏｎ）、に分割されたストレージ容量を有してもよい。ユーザ領域またはパーティションＰ０は、認証なしですべてのユーザおよびアプリケーションによるアクセスが可能である。ユーザ領域に保存されたデータのすべてのビット値（ｂｉｔ ｖａｌｕｅ）は、任意のアプリケーションまたはユーザによって読み出しまたは書き込みが可能であるが、データの読み出しが暗号化される場合、復号パーミッションを有していないユーザまたはアプリケーションは、ユーザ領域に保存されたビット値で表現された情報にアクセスすることはできないことになる。例えば、これはユーザエリアＰ０に保存されたファイル１０２および１０４により説明されている。例えば、すべてのアプリケーションおよびユーザにより読み出しおよび理解が可能なファイル１０６等の暗号化されていないファイルもユーザ領域に保存されている。このように、暗号化されるファイルは、例えばファイル１０２および１０４のように、当該ファイルに関連付けられた錠前と共に象徴的に示されている。

ユーザ領域Ｐ０における暗号化ファイルは、非許可のアプリケーションまたはユーザには理解することができないが、そのアプリケーションまたはユーザが、一部のアプリケーションにとって望ましくない可能性のあるファイルを削除または破壊することが可能であってもよい。また、この目的のために、メモリ２０は事前認証なしでアクセス不可能な、例えばパーティションＰ１およびＰ２等の保護されたカスタムパーティションを備える。以下、本出願に係る複数の実施形態で可能となる認証プロセスについて説明する。

図２に示されるように、様々なユーザまたはアプリケーションがメモリ２０内のファイルにアクセスしてもよい。このように、図２には、ユーザ１乃至２および（デバイスで実行する）アプリケーション１乃至４が示されている。こうしたエンティティは、メモリ２０の保護コンテンツへのアクセスを許可される前に、第一に以下で説明する方法の認証プロセスで認証される。当該プロセスでは、アクセスを要求するエンティティは、ロールベースアクセスコントロール（ｒｏｌｅ ｂａｓｅｄ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ）を行うために、ホスト側で認証される必要がある。このように、アクセスを要求するエンティティは、第一に、例えば「こちらアプリケーション２、ファイル１を読み出せ」等の情報を提供することにより、身元を示す。そして、コントローラ１２は、身元、認証情報および要求をメモリ２０またはコントローラ１２に保存された記録と照合する。すべての要求が満たされた場合、当該エンティティにアクセスが許可される。図２に示すように、ユーザ１はＰ０のファイル１０６に対する読み出しおよび書き込みに関して無制限の権利を有していることに加え、パーティションＰ１のファイル１０１に対する読み出しおよび書き込みを許可されているが、ファイル１０２および１０４に対しては読み出しのみが可能である。一方、ユーザ２はファイル１０１および１０４に対するアクセスを許可されていないが、ファイル１０２に対する読み出しおよび書き込みアクセスを有する。図２で示すように、ユーザ１および２は同一のログインアルゴリズム（ＡＥＳ）を有しているが、アプリケーション１および３は異なるログインアルゴリズム（例えば、ＲＳＡおよび００１００１）を有し、ここで、当該異なるログインアルゴリズムは、ユーザ１および２のログインアルゴリズムとも異なる。

セキュアストレージアプリケーション（ＳＳＡ）はメモリシステム１０のセキュリティアプリケーションで、本発明の一実施形態を説明するものである。当該アプリケーションは上記機能の多くを実施するために使用可能である。ＳＳＡはメモリ２０またはＣＰＵ１２の不揮発性メモリ（不図示）に保存されたデータベースを有するソフトウェアまたはコンピュータコードとして具現化することができ、ＲＡＭ１２ａに読み込まれ、ＣＰＵ１２により実行される。
ＳＳＡを参照して使用される略語（ａｃｒｏｎｙｍｓ）は、以下のテーブルで説明される。

《ＳＳＡシステム記述》
データの安全性（ｓｅｃｕｒｉｔｙ）、完全性（ｉｎｔｅｇｒｉｔｙ）およびアクセス制御がＳＳＡの主要な役割である。データは、本来、何らかの大容量記憶装置に単純に保存されるファイルである。ＳＳＡシステムはストレージシステム内に位置し、保存されたホストファイルに対してセキュリティレイヤ（ｓｅｃｕｒｉｔｙ ｌａｙｅｒ）を追加する。

ＳＳＡの主なタスクは、メモリに保存された（そして保護された）コンテンツに関連付けられた異なる権利を管理することにある。メモリアプリケーションは、複数のユーザおよび複数の保存コンテンツに対応するコンテンツ権を管理する必要がある。ホストアプリケーションは、ホストアプリケーション側から、こうしたアプリケーションが視認可能なドライブおよびパーティションと、ストレージデバイスに保存されたファイルの位置を管理および表現するファイルアロケーションテーブル（ＦＡＴ）と、を確認する。

この場合、ストレージデバイスはパーティションに分割されたＮＡＮＤフラッシュチップ（ＮＡＮＤ ｆｌａｓｈ ｃｈｉｐ）を使用するが、ここで他のモバイルストレージデバイスを使用してもよく、当該デバイスは本発明の範囲内に属するものである。これらのパーティションは論理アドレスの連続スレッドであり、ここでは「開始（ｓｔａｒｔ）」アドレスおよび「終了（ｅｎｄ）」アドレスがパーティションの境界を画定する。したがって、必要に応じて、ソフトウェア（例えば、メモリ２０に保存されたソフトウェア）により隠しパーティション（ｈｉｄｄｅｎ ｐａｒｔｉｔｉｏｎ）へのアクセスに制限を加えてもよいが、当該ソフトウェアは、こうした制限を境界内のアドレスと関連付ける。パーティションは、ＳＳＡの管理するパーティションの論理アドレス境界により、ＳＳＡが完全に認識可能である。ＳＳＡシステムは、権限のないホストアプリケーションから物理的にデータを保護するためにパーティションを使用する。ホストに対しては、パーティションはデータファイルを保存するための所有権空間を定義するメカニズムである。これらのパーティションは、ストレージデバイスへのアクセスを有する者であればデバイス上のパーティションの存在を確認し、認識することが可能であるという点で公的（ｐｕｂｌｉｃ）であると言える。また、選択されたホストアプリケーションのみがストレージデバイス上でのパーティションへのアクセスを有し、その存在を認識するという点で私的（ｐｒｉｖａｔｅ）であると言える。

図３は、メモリのパーティション、即ち、Ｐ０、Ｐ１、Ｐ２およびＰ３（４つ未満または４つを超えるパーティションを採用してもよいことは明白である）を説明するメモリの概略図であり、ここで、Ｐ０は認証なしで任意のエンティティがアクセス可能なパブリックパーティション（ｐｕｂｌｉｃ ｐａｒｔｉｔｉｏｎ）である。

（例えば、Ｐ１、Ｐ２、またはＰ３の）プライベートパーティション（ｐｒｉｖａｔｅ ｐａｒｔｉｔｉｏｎ）は、その範囲内にファイルへのアクセスを隠している。ホストによるパーティションへのアクセスを妨げることにより、フラッシュデバイス（例えば、フラッシュカード）はパーティション内のデータファイルの保護を実現する。しかし、この種の保護は、パーティション内の論理アドレスに保存されたデータへのアクセスに制限を課すことによって、隠しパーティションに存在するすべてのファイルを対象とする。即ち、当該制限は論理アドレスの範囲に関連付けられている。当該パーティションへのアクセスを有する「ユーザ／ホスト」のすべては、内部のすべてのファイルに対して無制限のアクセスを有する。異なるファイルまたはファイルグループを互いに分離するために、ＳＳＡシステムは鍵およびキーリファレンス、または鍵ＩＤを使用して、ファイル単位またはファイルグループ単位で他のレベルの安全性および完全性を提供する。異なるメモリアドレスでデータを暗号化するために使用される特定の鍵値に関するキーリファレンスまたは鍵ＩＤは、暗号化データを含むコンテナ（ｃｏｎｔａｉｎｅｒ）またはドメイン（ｄｏｍａｉｎ）に類推することができる。こうした理由により、図４においては、キーリファレンスまたは鍵ＩＤ（例えば、「鍵１」および「鍵２」）が鍵ＩＤに関連付けられた鍵値を使用して暗号化されたファイルの周辺領域として図示されている。

例えば、図４を参照すると、ファイルＡは鍵ＩＤで囲まれていないので、認証なしですべてのエンティティがアクセス可能である。パブリックパーティションのファイルＢは、すべてのエンティティが読み出しおよび上書き可能であるが、ファイルＢはＩＤ「鍵１」を有する鍵で暗号化されたデータを含む。したがって、ファイルＢに含まれる情報については、鍵へのアクセスを有していない限り、エンティティがアクセスすることはできない。この方法では、鍵値およびキーリファレンス、または鍵ＩＤの使用により、論理保護のみが提供される。これは、上述のパーティションにより提供された種類の保護とは相反する。従って、（パブリックまたはプライベート）パーティションにアクセス可能な任意のホストは、暗号化データを含むパーティション全体のデータの読み出しおよび書き込みが可能である。しかし、データが暗号化されているので、権限のないユーザはデータを破壊することしかできない。権限のないユーザは、検出なしでデータを変更することや、データを使用することができないことが好ましい。暗号鍵および／または復号鍵へのアクセスを制限することにより、この機能は、権限のあるエンティティのみに対してデータの使用を可能にする。また、ファイルＢおよびＣは、Ｐ０の鍵ＩＤ「鍵２」を有する鍵を使用して暗号化されている。

データの機密性（ｃｏｎｆｉｄｅｎｔｉａｌｉｔｙ）および完全性は、コンテンツ暗号鍵（Ｃｏｎｔｅｎｔ Ｅｎｃｒｙｐｔｉｏｎ Ｋｅｙｓ；ＣＥＫ）を使用する対称暗号法を通じて、各ＣＥＫに対して提供可能である。ＳＳＡ実施形態において、ＣＥＫはフラッシュデバイス（例えば、フラッシュカード）により生成され、内部でのみ使用され、外部からは秘密にされる。また、暗号化（ｅｎｃｒｙｐｔｅｄ ｏｒ ｃｉｐｈｅｒｅｄ）されたデータは、ハッシュ化（ｈａｓｈｅｄ）されてもよく、データの完全性を確実にするために、暗号がチェーンブロックされてもよい。

必ずしもパーティションのすべてのデータが異なる鍵で暗号化され、異なる鍵ＩＤに関連付けられる訳ではない。パブリックファイルまたはユーザファイルの所定の論理アドレス、またはオペレーティングシステム領域（即ちＦＡＴ）の所定の論理アドレスは、任意の鍵またはキーリファレンスと関連付けられなくてもよく、これにより、パーティション自体にアクセス可能な任意のエンティティによって利用可能となる。

鍵およびパーティションの生成能力に加えて、それらのデータの書き込みおよび読み出し、または鍵の使用に関する能力を必要とするエンティティは、アクセス制御記録（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｒｅｃｏｒｄ；ＡＣＲ）を通じてＳＳＡシステムにログインすることが必要である。ＳＳＡシステムのＡＣＲの権限は「アクション（Ａｃｔｉｏｎｓ）」と呼ばれる。各ＡＣＲは以下３つのカテゴリのアクション、即ち、パーティションおよび鍵／鍵ＩＤの生成、パーティションおよび鍵へのアクセス、および他のＡＣＲの生成／更新、の３つのカテゴリのアクションを実行する「パーミッション（Ｐｅｒｍｉｓｓｉｏｎｓ）」を有してもよい。

ＡＣＲはＡＣＲグループまたはＡＧＰと呼ばれるグループに整理される。ＡＣＲの認証に一旦成功すれば、ＳＳＡシステムはＡＣＲのアクションの何れかを実行可能な「セッション」（Ｓｅｓｓｉｏｎ）を開始する。

《ユーザパーティション（一または複数）》
ＳＳＡは一または複数のパブリックパーティションを管理し、これをユーザパーティション（一または複数の）と称すこともある。当該パーティションはストレージデバイスに存在し、ストレージデバイスの標準的な読み出しおよび書き込みコマンドによりアクセス可能な一または複数のパーティションである。デバイスにおけるパーティションの存在だけでなく、パーティション（一または複数の）のサイズに関する情報の取得は、ホストシステムから隠蔽不可能であることが好ましい。

ＳＳＡシステムは、標準的な読み出しおよび書き込みコマンド、またはＳＳＡコマンドの何れかにより当該パーティションにアクセス可能である。したがって、パーティションへのアクセスを特定ＡＣＲに制限できないことが好ましい。しかし、ＳＳＡシステムにより、ホストデバイスはユーザパーティションへのアクセス制限を有効にすることが可能である。読み書きアクセスは、個別に有効／無効にすることができる。４つの組み合わせすべて（例えば、書き込みのみ、読み出しのみ（書き込み禁止）、読み書き、アクセス不可）が可能である。

ＳＳＡシステムにより、ＡＣＲは鍵ＩＤをユーザパーティション内のファイルと関連付け、そうした鍵ＩＤと関連付けられた鍵を使用して、個々のファイルを暗号化することが可能である。パーティションへのアクセス権限の設定だけでなく、ユーザパーティション内の暗号化ファイルへのアクセスは、ＳＳＡコマンドセットを使用して実行される（ＳＳＡコマンドの詳細な記述に関する付録Ａを参照。当該付録では、鍵ＩＤを「ドメイン」と称す）。また、上述の機能はファイルに整理されていないデータに適用する。

《ＳＳＡパーティション》
これらは（ホストオペレーティングシステムまたはＯＳから）隠されたパーティションであり、ＳＳＡコマンドを通じてのみアクセス可能である。ＳＳＡシステムによって、ホストデバイスがＡＣＲにログインすることにより確立される（以下に示す）セッションを介すことなくＳＳＡパーティションにアクセスすることができないことが好ましい。同様に、確立されたセッションを通じて当該要求がなされない限り、ＳＳＡはＳＳＡパーティションの存在、サイズおよびアクセス許可に関する情報を提供しないことが好ましい。

パーティションへのアクセス権限はＡＣＲパーミッションに基づいている。ＡＣＲは、ＳＳＡシステムに一旦ログインすると、パーティションを（以下に示す）他のＡＣＲと共有することができる。パーティションの生成時に、ホストは参照名またはＩＤ（例えば、図３および４のＰ０乃至Ｐ３）をパーティションに供給する。当該参照はパーティションに対するさらなる読み出しおよび書き込みコマンドで使用される。

《ストレージデバイスのパーティション化》
デバイスの利用可能なストレージ容量のすべてが、ユーザパーティションおよび現段階で設定されたＳＳＡパーティションに割り当てられることが好ましい。したがって、任意の再パーティションオペレーション（ｒｅｐａｒｔｉｔｉｏｎ ｏｐｅｒａｔｉｏｎ）は既存のパーティションの再設定を含んでも良い。デバイス容量（全パーティションの合計サイズ）に対する純変化（ｎｅｔ ｃｈａｎｇｅ）はゼロになる。デバイスメモリ空間におけるパーティションのＩＤは、ホストシステムにより定義される。

ホストシステムは、既存のパーティションの一つを二つのより小さなパーティションに再パーティション化する、または（隣接してもよいし、隣接しなくてもよい）二つの既存のパーティションを一つのパーティションに結合することが可能である。分割パーティションまたは結合パーティションのデータは、ホストの裁量で消去可能であるし、そのままの状態にすることも可能である。

ストレージデバイスの再パーティション化は、（ストレージデバイスの論理アドレス空間におけるデータの消去または移動が原因で）データ損失を引き起し得るので、ＳＳＡシステムにより、再パーティション化の実行に厳重な制限が課される。（以下に示す）ルートＡＧＰに存在するＡＣＲのみが再パーティションコマンドの発行を許可され、それが所有するパーティションを参照することのみ可能である。ＳＳＡシステムは、データが如何にしてパーティション（ＦＡＴまたは他のファイルシステム構造）に整理されるのかを認識しないので、デバイスが再パーティション化される場合は常に、こうした構造を再構築するのはホストの責任となる。

ホストＯＳによって確認されながら、当該パーティションのサイズおよび他の属性は、ユーザパーティションの再パーティション化により変更される。

再パーティション化の実行後、ＳＳＡシステムの任意のＡＣＲが実在しないパーティションを参照しないことを確認するのは、ホストシステムの責任である。こうしたＡＣＲが適切に削除または更新されない場合、こうしたＡＣＲに代わって、実在しないパーティションにアクセスする以後の試みはシステムにより削除および拒否される。削除された鍵および鍵ＩＤに関しても、同様の配慮がなされる。

《鍵、鍵ＩＤおよび論理保護》
ファイルが所定の隠しパーティションに書き込まれる場合、当該ファイルは不特定多数者から隠される。しかし、（敵意があるか否かは別として）一旦あるエンティティが当該パーティションに関する知識およびアクセスを取得すると、ファイルは利用可能で視認容易なものになる。ファイルをさらに保護するために、ＳＳＡは隠しパーティションでファイルを暗号化することができる。この場合、ファイルを復号するための鍵へのアクセスに関する証明書は、パーティションへのアクセスに関する証明書と異なることが好ましい。ファイルは（ホストにより完全に制御および管理され）ＳＳＡが認識するものではないという事実を考慮すると、ＣＥＫをファイルと関連付けることには問題がある。ファイルをＳＳＡが応答する何らかのもの（例えば、鍵ＩＤ）とリンクすることによりこれを修正する。このように、ＳＳＡにより鍵が生成される場合、ホストはＳＳＡにより生成された鍵を使用して、当該鍵に関する鍵ＩＤを暗号化データと関連付ける。

鍵値および鍵ＩＤは論理的セキュリティ（ｌｏｇｉｃａｌ ｓｅｃｕｒｉｔｙ）を提供する。所定の鍵ＩＤに関連づけられたすべてのデータは、その位置にかかわらず、ホストアプリケーションにより生成時に一意的に参照名または鍵ＩＤを与えられた同一のコンテンツ暗号鍵（ＣＥＫ）を用いて暗号化される。エンティティが（ＡＣＲを通じた認証により）隠しパーティションへのアクセスを獲得し、当該パーティション内の暗号化ファイルの読み出しまたは書き込みの実行を望む場合、ファイルに関連付けられた鍵ＩＤへのアクセスを有する必要がある。ＳＳＡは、当該鍵ＩＤに対応する鍵へのアクセスを許可する場合、当該鍵ＩＤに関連付けられたＣＥＫの鍵値をロードし、ホストへのデータ送信前にこれを復号する、または、フラッシュメモリ２０へのデータ書き込み前にこれを暗号化する。鍵ＩＤに関連付けられたＣＥＫの鍵値は、ＳＳＡシステムにより一旦ランダムに生成され、維持される。ＳＳＡシステムの外部でＣＥＫの当該鍵値に関する知識またはアクセスを有するものはいない。外部では、ＣＥＫの鍵値ではなく、参照または鍵ＩＤが提供される、または使用されるだけである。鍵値はＳＳＡにより完全に管理され、ＳＳＡのみがアクセス可能である。

ＳＳＡシステムは、以下の暗号モードの内（ユーザが定義した）任意のモードを使用して、鍵ＩＤに関連付けられたデータを保護する（なお、ＣＥＫの鍵値だけでなく、使用される実際の暗号アルゴリズムは、システム制御され、外部に漏れることはない）：

《ブロックモード（Ｂｌｏｃｋ ｍｏｄｅ）》
データがブロックに分割され、各ブロックは個別に暗号化される。
このモードは一般的に安全性がそれほど高くなく、辞書攻撃を受けやすいと考えられている。しかし、このモードでは、ユーザがデータブロック（ｄａｔａ ｂｌｏｃｋｓ）の任意のブロックにランダムにアクセス可能である。

《連鎖モード（Ｃｈａｉｎｅｄ ｍｏｄｅ）》
データがブロックに分割され、暗号化プロセス中にブロックがチェーン化される。
各ブロックは、次のブロックの暗号化プロセスに対するインプットの一つとして使用される。このモードはより安全性が高いと考えられているが、データの書き込みおよび読み出しが常に開始から終了まで順に実行されることを必要とし、ユーザが必ずしも受け入れ可能ではないオーバーヘッド（ｏｖｅｒｈｅａｄ）を生成する。

《ハッシュモード（Ｈａｓｈｅｄ）》
データの完全性の確認に使用可能なデータダイジェスト（ｄａｔａ ｄｉｇｅｓｔ）の付加生成を伴う連鎖モードである。

《ＡＣＲおよびアクセス制御》
ＳＳＡは複数アプリケーションを処理するように設計されており、各アプリケーションはシステムデータベースにおいて、ノードからなるツリーとして表現される。アプリケーション間の相互排除は、ツリーのブランチ（ｂｒａｎｃｈ）間でクロストークを確実に発生しないようにすることにより達成される。

ＳＳＡシステムへのアクセスを獲得するために、エンティティはシステムのＡＣＲの一つを経由して接続を確立する必要がある。ログイン手順は、ユーザが接続を選択したＡＣＲに組み込まれた定義に応じて、ＳＳＡシステムにより実行される。

ＡＣＲはＳＳＡシステムへの個別のログインポイントである。ＡＣＲはログイン証明書および認証方法を有する。また、ＳＳＡシステム内のログインパーミッションが当該記録に属しており、その中には読み出しおよび書き込み権限がある。これは図５において説明されており、同図では同一ＡＧＰにおいてｎ個のＡＣＲが図示されている。これは、ｎ個のＡＣＲの内、少なくとも幾つかは同一鍵へのアクセスを共有し得ることを意味する。このように、ＡＣＲ＃１およびＡＣＲ＃ｎは、鍵ＩＤ「鍵３」を有する鍵へのアクセスを共有しているが、ここで、ＡＣＲ＃１およびＡＣＲ＃ｎはＡＣＲのＩＤであり、「鍵３」は「鍵３」に関連付けられたデータの暗号化に使用される鍵に対応する鍵ＩＤである。また、同一鍵は複数ファイルまたは複数のデータを暗号化および／または復号するために使用可能である。

ＳＳＡシステムはシステムへの幾つかの種類のログイン形式をサポートしているが、ここで、ユーザが一旦ログインに成功すれば、システムにおけるユーザの権限が変化するように、認証アルゴリズムおよびユーザ証明書が変化してもよい。さらに、図５は異なるログインアルゴリズムおよび証明書を説明している。ＡＣＲ＃１はパスワードログインアルゴリズムおよび証明書としてのパスワードを必要とする。一方、ＡＣＲ＃２はＰＫＩ（公開鍵基盤；ｐｕｂｌｉｃ ｋｅｙ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）ログインアルゴリズムおよび証明書としての公開鍵を必要とする。このように、ログインするために、エンティティは正しいログインアルゴリズムおよび証明書だけでなく、有効なＡＣＲのＩＤを提示する必要がある。

エンティティが一旦ＳＳＡシステムのＡＣＲにログインすると、パーミッション、即ち、ＳＳＡコマンドの使用権は、ＡＣＲに関連付けられたパーミッション制御記録（Ｐｅｒｍｉｓｓｉｏｎｓ Ｃｏｎｔｒｏｌ Ｒｅｃｏｒｄ；ＰＣＲ）において定義される。図５において、ＡＣＲ＃１は「鍵３」と関連付けられたデータに対して読み出しのみのパーミッションを認め、ＡＣＲ＃２は示されたＰＣＲに応じて、「鍵５」と関連付けられたデータの読み出しおよび書き込みのパーミッションを認める。

異なるＡＣＲはシステム、例えば、読み出しおよび書き込みに関連付けられた鍵等、において共通の所有権および権限を共有してもよい。これを達成するために、何らかの共通するものを有するＡＣＲは、ＡＧＰにグループ化、即ち、ＡＣＲグループにグループ化される。このように、ＡＣＲ＃１およびＡＣＲ＃ｎは、鍵ＩＤ「鍵３」を有する鍵へのアクセスを共有する。

機密データの安全性を保つセキュア鍵の生成は別として、ＡＧＰおよびその中のＡＣＲは、階層ツリーに整理される。すなわち、ＡＣＲは、鍵ＩＤ／パーティションに対応する他のＡＣＲエントリを生成可能であることが好ましい。これらの子ＡＣＲ（ＡＣＲ ｃｈｉｌｄｒｅｎ）は、親（ｆａｔｈｅｒ）即ちクリエータ（ｃｒｅａｔｏｒ）と同一のパーミッションまたは限られたパーミッションを有しており、親ＡＣＲ自身が生成した鍵へのパーミッションが与えられても良い。言うまでもなく、子ＡＣＲは生成する任意の鍵へのアクセスパーミッションを得る。これは図６において説明されている。このように、ＡＧＰ１２０におけるすべてのＡＣＲは、ＡＣＲ１２２により生成され、当該ＡＣＲの２つはＡＣＲ１２２から「鍵３」と関連付けられたデータへのアクセスパーミッションを引き継いでいる。

《ＡＧＰ》
ＳＳＡシステムへのログインは、ＡＧＰおよびＡＧＰ内のＡＣＲを特定することにより実行される。

各ＡＧＰには固有のＩＤ（参照名）があり、当該ＩＤはＳＳＡデータベースへのエントリ用のインデックスとして使用される。ＡＧＰの生成時に、ＡＧＰ名がＳＳＡシステムに供給される。供給されたＡＧＰ名が当該システムにおいて既に存在する場合、ＳＳＡは生成オペレーションを拒否する。

以下のセクションで記載するように、ＡＧＰはアクセスおよび管理パーミッションの委譲に制限を課すために使用される。図６の２つのツリーが果たす機能の一つは、例えば２つの異なるアプリケーションまたは２つの異なるコンピュータユーザ等、エンティティを完全に分離することによってアクセスを与えることである。当該目的のためには、２つのアクセスプロセスが同時に発生するとしても、実質的に互いに独立する（即ち、実質的にクロストークがない）ことが重要となり得る。これは、各ツリーにおけるＡＣＲおよびＡＧＰのさらなる生成だけでなく、認証およびパーミッションも、他のツリーのそれらと接続されておらず、それらに依存しないことを意味する。したがって、ＳＳＡシステムがメモリ１０で使用される場合、これによりメモリシステム１０が複数のアプリケーションを同時に扱うことができる。また、これにより、２つのアプリケーションが互いに独立する２つの個別のデータ（例えば、複数の写真からなる写真一組および複数の歌曲からなる歌曲一組）にアクセスすることができる。これは図６において説明されている。このように、アプリケーションまたはユーザが図６の上部のツリーにおけるノード（ＡＣＲ）を経由してアクセスする「鍵３」、「鍵Ｘ」および「鍵Ｚ」に関連付けられたデータが複数の写真を含んでもよい。アプリケーションまたはユーザが図６の下部のツリーのノード（ＡＣＲ）を経由してアクセスする「鍵５」および「鍵Ｙ」に関連付けられたデータが複数の歌曲を含んでもよい。ＡＧＰを生成したＡＣＲは、当該ＡＧＰにＡＣＲエントリが存在しない場合にのみ、これを削除するパーミッションを有する。

《エンティティのＳＳＡエントリポイント：アクセス制御記録（ＡＣＲ）》
ＳＳＡシステムにおけるＡＣＲは、エンティティがシステムにログインパーミッションされる方法を記載している。エンティティは、ＳＳＡシステムにログインする場合、実行しようとする認証プロセスに対応するＡＣＲを特定する必要がある。ＡＣＲはパーミッション制御記録（ＰＣＲ）を含み、当該ＰＣＲは、図５で説明されＡＣＲに定義されているように、一旦認証されるとユーザが実施可能なパーミッションされたアクションを説明している。ホスト側のエンティティは、ＡＣＲデータフィールドのすべてを供給する。

エンティティのＡＣＲへのログインが成功した場合、エンティティはＡＣＲのパーティション、鍵アクセスパーミッションおよび（以下で説明する）ＡＣＡＭパーミッションのすべてにクエリを行うことが可能となる。

《ＡＣＲのＩＤ》
ＳＳＡシステムのエンティティがログインプロセスを開始した場合、当該エンティティは（ＡＣＲの生成時にホストにより提供されるように）ログイン方法に対応するＡＣＲのＩＤを特定する必要がある。この結果、すべてのログイン要件が満たされた場合、ＳＳＡは正しいアルゴリズムをセットアップし、正しいＰＣＲを選択する。ＡＣＲの生成時に、ＡＣＲのＩＤがＳＳＡに供給される。

《ログイン／認証アルゴリズム》
認証アルゴリズムは、エンティティにより使用されるログイン手順の種類、およびユーザの身元の証拠を提供するのに必要となる証明書の種類を特定する。ＳＳＡシステムは幾つかの標準的なログインアルゴリズムをサポートしており、当該アルゴリズムは、手順なし（および証明書なし）およびパスワードベースの手順から、対称暗号化または非対称暗号化の何れかに基づく２方向認証プロトコルに及ぶ。

《証明書》
エンティティの証明書は、ログインアルゴリズムに対応し、ユーザの照合および認証を行うためにＳＳＡにより使用される。証明書の例としては、パスワード認証用のパスワード／ＰＩＮ番号、ＡＥＳ認証用のＡＥＳ鍵等を挙げることができる。証明書（即ち、ＰＩＮ、対称鍵等）の種類／フォーマットは、事前に定義されており、認証モードに基づいている。即ち、それらはＡＣＲの生成時にＳＳＡに供給される。ＳＳＡシステムは、ＰＫＩベースの認証に関する例外はあるものの、こうした証明書の定義、分配および管理とは関係なく、ＰＫＩベースの認証では、ＲＳＡ鍵ペアを生成するためにデバイス（例えば、フラッシュカード）を使用可能であり、証明書の生成に対して公開鍵をエクスポート可能である。

《パーミッション制御記録（ＰＣＲ）》
ＰＣＲは、ＳＳＡシステムにログインし、ＡＣＲの認証プロセスの通過に成功した後、エンティティに対して何が許可されるのかを示している。３タイプのパーミッションカテゴリ、即ち、パーティションおよび鍵に関する生成パーミッション、パーティションおよび鍵へのアクセスパーミッション、およびエンティティ・ＡＣＲ属性の管理パーミッションが存在する。

《パーティションへのアクセス》
ＰＣＲに関する当該セクションは、ＡＣＲ段階を首尾良く完了した場合にエンティティがアクセス可能な（ＳＳＡシステムに提供されているようにＩＤを使用する）パーティションのリストを含む。各パーティションのアクセスの種類は、書き込みのみ、または読み出しのみに制限されてもよいし、書き込み／読み出しのフルアクセス権限を指定してもよい。このように、図５のＡＣＲ＃１は、パーティション＃１ではなく、パーティション＃２へのアクセスを有している。ＰＣＲで特定される制約は、ＳＳＡパーティションおよびパブリックパーティションに適用する。

パブリックパーティションは、ＳＳＡシステムをホスティングするデバイス（例えば、フラッシュカード）に対する正規の読み出しおよび書き込みコマンド、または、ＳＳＡコマンドの何れかによりアクセス可能である。（以下で説明する）ルートＡＣＲがパブリックパーティションを制限するパーミッションを用いて生成される場合、当該ＡＣＲはそれを子に伝えることが可能である。ＡＣＲは、正規の読み出しおよび書き込みコマンドがパブリックパーティションにアクセスしないように制限することのみ可能であることが好ましい。ＳＳＡシステムにおけるＡＣＲは、生成に対してのみ制限可能であることが好ましい。ＡＣＲが一旦パブリックパーティションに対する読み出しおよび書き込みに関するパーミッションを有すると、当該パーミッションを取り消しできないことが好ましい。

《鍵ＩＤへのアクセス》
ＰＣＲに関する当該セクションは、ＡＣＲポリシーがエンティティのログインプロセスにより満たされた場合、（ホストによりＳＳＡシステムに供給されるように）エンティティがアクセス可能な鍵ＩＤのリストに関連付けられたデータを含む。指定された鍵ＩＤは、ＰＣＲに登場するパーティションに存在する一または複数のファイルに関連付けられる。鍵ＩＤはデバイス（例えば、フラッシュカード）の論理アドレスに関連付けられていないので、複数のパーティションが特定ＡＣＲと関連付けられる場合、ファイルはパーティションの何れか一つに存在することが可能である。ＰＣＲで指定された複数の鍵ＩＤは、それぞれ異なるセットの複数のアクセス権限を有することができる。鍵ＩＤにより指令されたデータへのアクセスは、書き込みのみ、または読み出しのみに限定することが可能であり、または書き込み／読み出しのフルアクセス権限を指定しても良い。

《ＡＣＲ属性管理（ＡＣＲ Ａｔｔｒｉｂｕｔｅｓ Ｍａｎａｇｅｍｅｎｔ；ＡＣＡＭ）》
このセクションは、ＡＣＲのシステム属性が特定の状況で如何に変化し得るかを記載している。

ＳＳＡシステムにおいて許可し得るＡＣＡＭアクションは、以下の通りである：

ＡＧＰおよびＡＣＲの生成／削除／更新

パーティションおよび鍵の生成／削除

鍵およびパーティションへのアクセス権限の委譲

親ＡＣＲはＡＣＡＭパーミッションを編集できないことが望ましい。これは、望ましくはＡＣＲの削除および作り直しを必要とする。また、ＡＣＲにより生成された鍵ＩＤへのアクセスパーミッションを取り除くことはできないことが望ましい。

ＡＧＰおよびＡＣＲの生成／削除／更新

ＡＣＲは、他のＡＣＲおよびＡＧＰを生成する能力を有しても良い。また、ＡＣＲの生成は、クリエータが所有するＡＣＡＭパーミッションの一部またはすべてを生成するＡＣＲに委譲することを意味してもよい。ＡＣＲの生成パーミッションを有することは、以下のアクションに対するパーミッションを有することを意味する：
１．子の証明書の定義および編集、即ち、認証方法は、生成ＡＣＲにより一旦設定されると、編集できないことが好ましい。証明書は既に子に対して定義されている認証アルゴリズムの境界内で変更されてもよい。
２．ＡＣＲの削除
３．子ＡＣＲへの生成権の委譲（これにより子ＡＣＲは孫（ｇｒｏｕｎｄｃｈｉｌｄｒｅｎ）を有す）

他のＡＣＲの生成パーミッションを有するＡＣＲは、（恐らくＡＣＲをブロック解除するパーミッションを有していないが）当該ＡＣＲが生成するＡＣＲに対してブロック解除するパーミッションを委譲するパーミッションを有する。親ＡＣＲは自身の非ブロッカーへの参照を子ＡＣＲに設置する。

親ＡＣＲは自身の子ＡＣＲを削除するパーミッションを有する唯一のＡＣＲである。ＡＣＲが自身の生成した低位レベルのＡＣＲを削除する場合、自動的に当該低位レベルのＡＣＲにより生み出されたすべてのＡＣＲも同様に削除される。ＡＣＲが削除される場合、それが生成したすべての鍵ＩＤおよびパーティションが削除される。

下記の通り、ＡＣＲが自身の記録を更新可能な２つの例外が存在する。

パスワード／ＰＩＮは、クリエータＡＣＲにより設定されているのだが、それらを含むＡＣＲによってのみ更新可能である。

ルートＡＣＲは自身およびそれが存在するＡＧＰを削除してもよい。

《鍵およびパーティションへのアクセス権限の委譲》
ＡＣＲおよびそれらのＡＧＰは、階層ツリーにまとめられる。当該階層ツリーでは、ルートＡＧＰおよびその中のＡＣＲがツリーの先端部に位置する（例えば、図６のルートＡＧＰ１３０および１３２）。ＳＳＡシステムにはいくつかのＡＧＰツリーが存在しており、それらは互いに完全に分離している。ＡＧＰ内のＡＣＲは、自身が存在する同一ＡＧＰ内のすべてのＡＣＲ、およびそれらが生成したすべてのＡＣＲに対して、鍵へのアクセスパーミッションを委譲することができる。鍵の生成パーミッションは、鍵を使用するためのアクセスパーミッションを委譲するパーミッションを含むことが好ましい。
鍵へのパーミッションは以下の３つのカテゴリに分割される。
１．アクセス（これは鍵に対するアクセスパーミッション、即ち、読み出し、書き込みを定義する）
２．所有権（鍵を生成したＡＣＲが明らかにその所有者となる） 当該所有権は、（ＡＣＲが同一ＡＧＰまたは子ＡＧＰに存在するという条件で）あるＡＣＲから他のＡＣＲに委譲される。鍵の所有権は、他のＡＣＲにパーミッションを委譲するだけでなく、それを削除するパーミッションを与える。
３．アクセス権限の委譲（このパーミッションにより、ＡＣＲは自身が保有する権利を委譲可能となる）

ＡＣＲは、自身がアクセス権限を有する他のパーティションだけでなく、自身が生成したパーティションへのアクセス権限を委譲することが可能である。

パーミッションの委譲は、指定されたＡＣＲのＰＣＲにパーティションおよび鍵ＩＤ名を追加することにより実行される。鍵へのアクセスパーミッションの委譲は、鍵ＩＤによるものであってもよいし、アクセスパーミッションが委譲するＡＣＲのすべての生成された鍵に対するパーミッションであるという主張によるものであってもよい。

《ＡＣＲのブロックおよびブロック解除》
ＡＣＲは、システムとのエンティティのＡＣＲ認証プロセスに失敗した場合にインクリメントするブロッキングカウンタ（ｂｌｏｃｋｉｎｇ ｃｏｕｎｔｅｒ）を有しても良い。認証の失敗回数が所定の最大値（ＭＡＸ）に達した場合、ＡＣＲはＳＳＡシステムによりブロック（ｂｌｏｃｋ）される。

ブロックされたＡＣＲは、ブロックされたＡＣＲが参照する他のＡＣＲによりブロック解除（ｕｎｂｌｏｃｋ）可能である。ブロック解除を行うＡＣＲを参照することは、当該ＡＣＲのクリエータにより設定される。ブロックを解除するＡＣＲは、ブロックされたＡＣＲのクリエータとして同一ＡＧＰに存在し、「ブロック解除」のパーミッションを有することが好ましい。

当該システムにおいて、ブロックされたＡＣＲをブロック解除可能なＡＣＲは、他には存在しない。ＡＣＲは、ブロック解除ＡＣＲ（ｕｎｂｌｏｃｋｅｒ ＡＣＲ）を用いずに、ブロッキングカウンタを用いて構成されてもよく、この場合、当該ＡＣＲがブロックされた場合には、それをブロック解除することはできない。

《ルートＡＧＰ―アプリケーションデータベースの生成》
ＳＳＡシステムは、複数のアプリケーションを処理し、各アプリケーションのデータを分離するように設計されている。ＡＧＰシステムのツリー構造は、アプリケーション固有のデータを識別および分離するために使用される主なツールである。ルートＡＧＰは、アプリケーションＳＳＡデータベースツリーの先端部に存在し、幾分異なる行動規範に従う。幾つかのルートＡＧＰはＳＳＡシステムにおいて設定可能である。２つのルートＡＧＰ１３０および１３２が図６に示されている。これより少ない、または多くのＡＧＰを使用しても良く、又、このことが本発明の範囲内にあることは明白である。

新たなアプリケーションに対するデバイス（例えば、フラッシュカード）の登録、および／または、デバイスに対する新たなアプリケーションの証明書の発行は、新たなＡＧＰ／ＡＣＲツリーをデバイスに追加するプロセスを通じて実行される。

ＳＳＡシステムは、（ルートＡＧＰの全てのＡＣＲおよびそれらのパーミッションだけでなく）ルートＡＧＰの生成に関する３つの異なるモードをサポートしている：
１．オープンモード（Ｏｐｅｎ）：如何なる種類の認証も必要としない任意のユーザまたはエンティティ、または（以下に説明する）システムＡＣＲを通じて認証されたユーザ／エンティティは、新たなルートＡＧＰを生成することができる。オープンモードは、すべてのデータ伝送がオープンチャネル（即ち、発行機関（ｉｓｓｕａｎｃｅ ａｇｅｎｃｙ）の安全な環境の中）で実行される間に、何もセキュリティ手段を使用することなく、または、システムＡＣＲ認証（即ち、無線（Ｏｖｅｒ Ｔｈｅ Ａｉｒ；ＯＴＡ）および事後発行手順（ｐｏｓｔ ｉｓｓｕａｎｃｅ ｐｒｏｃｅｄｕｒｅ））を通じて確立されたセキュアチャネルを通じて、ルートＡＧＰの生成を可能にする。
システムＡＣＲが設定されず（これは随意的な機能である）、ルートＡＧＰ生成モードがオープンに設定されている場合、オープンチャネルオプション（ｏｐｅｎ ｃｈａｎｎｅｌ ｏｐｔｉｏｎ）のみが利用可能である。
２．制御モード（Ｃｏｎｔｒｏｌｌｅｄ）：システムＡＣＲを通じて認証されたエンティティのみが新たなルートＡＧＰを生成することができる。ＳＳＡシステムは、システムＡＣＲが設定されていない場合、このモードに設定することができない。
３．ロックモード（Ｌｏｃｋｅｄ）：ルートＡＧＰの生成が不可能であり、増設ルートＡＧＰをシステムに追加することができない。
２つのＳＳＡコマンドがこの機能を制御する（これらのコマンドは認証無しで任意のユーザ／エンティティに利用可能である）：
１．方法設定コマンド（Ｍｅｔｈｏｄ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｃｏｍｍａｎｄ）―３つのルートＡＧＰ生成モードの何れか一つを使用するようにＳＳＡシステムを設定するために使用される。以下のモード変更のみが許可される：オープンモード
-> 制御モード（Ｏｐｅｎ −＞ Ｃｏｎｔｒｏｌｌｅｄ）、制御モード−＞ロックモード（Ｃｏｎｔｒｏｌｌｅｄ−＞Ｌｏｃｋｅｄ）（即ち、ＳＳＡシステムが制御モードに現在設定されている場合、ロックモードへの変更のみ可能である）。
２．方法設定ロックコマンド（Ｍｅｔｈｏｄ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｌｏｃｋ ｃｏｍｍａｎｄ）―方法設定コマンドを無効にし、現在選択されているモードを永久にロックするために使用される。

ルートＡＧＰが生成される時、（ルートＡＧＰの生成に適用されたのと同一のアクセス制限を使用して）ＡＣＲの生成および設定を可能にするのは、特別の初期化モードにおいてである。ルートＡＧＰ設定プロセスの最後に、エンティティが明確にそれをオペレーションモードに切り替えると、既存のＡＣＲはそれ以後の更新が不可能となり、追加のＡＣＲを生成することが不可能となる。

ルートＡＧＰが一旦標準モードになると、ルートＡＧＰは、ルートＡＧＰの削除パーミッションを与えられたルートＡＧＰ内のＡＣＲの１つを通じてシステムにログインすることによってのみ、削除可能となる。特別の初期化モードに加えて、これはルートＡＧＰのもう一つの例外なのである；即ち、ツリー内の次のレベルのＡＧＰとは対照的に、自身が属するＡＧＰの削除パーミッションを有するＡＣＲを含むことが可能であるのは、当該ＡＧＰのみであることが好ましい。

ルートＡＣＲと標準的なＡＣＲとの３つ目の、且つ、最後の相違点は、ルートＡＣＲが、パーティションの生成および削除パーミッションを有することができるシステム内における唯一のＡＣＲであるという点である。

《ＳＳＡシステムＡＣＲ》
システムＡＣＲは以下の２つのＳＳＡオペレーションに使用することができる：
１．厳しい環境における保護チャネルの保護下でのＡＣＲ／ＡＧＰツリーの生成。
２．ＳＳＡシステムをホスティングするデバイスの識別および認証。

ＳＳＡにシステムＡＣＲが１つだけ存在することが好ましく、一旦定義されたら、変更不可能であることが好ましい。システムＡＣＲの生成時にはシステム認証を必要としない；即ち、ＳＳＡコマンドのみが必要なのである。システムＡＣＲ生成機能を無効にすることが可能である（ルートＡＧＰ生成機能についても同様）。一つのシステムＡＣＲのみが許可されることが好ましいので、システムＡＣＲの生成後には、システムＡＣＲ生成コマンドは効果を持たない。

生成プロセスにおいては、システムＡＣＲは使用することができない。完了した時には、システムＡＣＲが生成され、準備完了であることを示す特別のコマンドを発行する必要がある。これより後の時点で、システムＡＣＲの更新または差し替えは不可能であることが好ましい。

システムＡＣＲはＳＳＡにおいてルートＡＣＲ／ＡＧＰを生成する。システムＡＣＲは、ホストがそれに満足し、ブロックする時までは、ルートレベルを追加／変更するパーミッションを有する。ルートＡＧＰをブロックすることは、本質的には、システムＡＣＲとの接続を遮断し、それを改ざん防止状態にすることである。この時点で、ルートＡＧＰおよびその中のＡＣＲを変更／編集することができるものはない。これはＳＳＡコマンドを通じて実行される。ルートＡＧＰの生成を無効にすることは、永久的な効果があり、覆すことはできない。システムＡＣＲを含む上記の機能は、図７において説明されている。システムＡＣＲは３つの異なるルートＡＧＰを生成するために使用される。これらが生成された後の一定の時間にシステムＡＣＲからルートＡＧＰをブロックするために、ＳＳＡコマンドがホストから送信され、これにより、図７においてシステムＡＣＲをルートＡＧＰに接続する破線で示しているように、ルートＡＧＰ生成機能が無効となる。これにより、３つのルートＡＧＰが改ざん防止の状態になる。３つのルートＡＧＰは、ルートＡＧＰがブロックされる前でもされた後でも、３つの別々のツリーを形成する子ＡＧＰを生成することに使用することができる。

上記機能は、コンテンツを備えたセキュア製品の設定において、コンテンツ所有者に高い柔軟性をもたらす。セキュア製品は、「発行される（Ｉｓｓｕｅｄ）」必要がある。発行とは、デバイスによるホストの識別およびホストによるデバイスの識別が可能な識別鍵を設置するプロセスである。デバイス（例えば、フラッシュカード）を識別することにより、ホストは、識別鍵を備えた秘密を信用できるか否かを決定することができる。一方、ホストを識別することにより、デバイスは、ホストが許可される場合にのみ、セキュリティポリシーを実行することができる（特定のホストコマンドを許可し、実行する）。

複数のアプリケーションを扱うように設計された製品は、幾つかの識別鍵を有する。当該製品は「事前発行」（ｐｒｅ−ｉｓｓｕａｒａｎｃｅ）、即ち、鍵を発送前の製造工程で保存すること、または、「事後発行」（ｐｏｓｔ−ｉｓｓｕｒａｎｃｅ）、即ち、新しい鍵を発送後に追加することが可能である。事後発行に関しては、メモリデバイス（例えば、メモリカード）は、何らかのマスタ（ｍａｓｔｅｒ）、またはデバイスへのアプリケーションの追加を許可されたエンティティの識別に使用されているデバイスレベル鍵を含む必要がある。

上記機能により、製品は事後発行の有効化／無効化を設定することができる。さらに、事後発行設定が、発送後に安全に実施することができる。デバイスは、上記のマスタまたはデバイスレベル鍵の他には、鍵を備えていない小売製品として購入され、その後に、新たな所有者により、さらに事後発行アプリケーションの有効化または無効化の何れかが設定されてもよい。

このように、システムＡＣＲ機能により、上記目的を達成するための以下の機能が与えられる。
・システムＡＣＲを備えていないメモリデバイスは、無制限かつ規制のないアプリケーションの追加を許可する。
・システムＡＣＲを備えていないメモリデバイスは、システムＡＣＲの生成を無効にするように設定可能である。これは、（新たなルートＡＧＰの生成機能が同様に無効にならない限り）新たなアプリケーションの追加を制御する方法がないことを意味する。
・システムＡＣＲを備えたメモリデバイスは、セキュアチャネルを経由する制御されたアプリケーションの追加のみを、システムＡＣＲ証明書を使用する認証手続きを通じて確立することができる。
・システムＡＣＲを備えたメモリデバイスは、アプリケーションの追加前または追加後に、アプリケーション追加機能を無効にするように設定してもよい。

《鍵ＩＤリスト》
鍵ＩＤは、特定のＡＣＲ要求毎に生成される。しかし、メモリシステム１０においては、鍵ＩＤはＳＳＡシステムのみにより使用される。鍵ＩＤの生成時に、以下のデータは生成するＡＣＲにより提供される、または生成するＡＣＲに対して提供される。
１．鍵ＩＤ。ＩＤはホストを通じてエンティティにより提供され、鍵と、さらなる読み出しアクセスまたは書き込みアクセスにおいて、鍵を使用して暗号化または復号されるデータを参照するために使用される。
２．鍵暗号化およびデータ完全性モード（上記のブロックモード、チェーンモードおよびハッシュモードと下記の説明の通り）

ホストにより提供された属性に加えて、以下のデータはＳＳＡシステムによって維持される。
１．鍵ＩＤ所有者。所有者であるＡＣＲのＩＤ。鍵ＩＤの生成時に、クリエータＡＣＲがその所有者となる。しかし、鍵ＩＤの所有権は、他のＡＣＲに譲渡されてもよい。鍵ＩＤの所有者のみが、鍵ＩＤの所有権の譲渡（ｔｒａｎｓｆｅｒ）および委譲（ｄｅｌｅｇａｔｅ）を許可されることが好ましい。関連する鍵へのアクセスパーミッションの委譲、およびこれらの権利の無効化は、鍵ＩＤ所有者または委譲パーミッションを与えられた任意の他のＡＣＲの何れかにより実行可能である。これらのオペレーションの何れか一つを実行するための試みがなされる時は常に、要求するＡＣＲに権限が与えられている場合に限って、ＳＳＡシステムが当該試みを許可する。
２．ＣＥＫ。これは、鍵ＩＤと関連付けられ、鍵ＩＤにより示されたコンテンツを暗号化するために使用されるＣＥＫである。ＣＥＫは、ＳＳＡシステムによって生成された１２８ビットのＡＥＳ乱数鍵であってもよい。
３．ＭＡＣおよびＩＶ値（ＩＶ ｖａｌｕｅｓ）。チェーンブロック暗号（ＣＢＣ）暗号アルゴリズムで使用される動的情報（メッセージ暗号コードおよび初期化ベクトル）。

また、ＳＳＡの様々な機能が図８Ａ乃至１６のフローチャートを参照して説明されており、当該図面において、ステップの左側に記載された「Ｈ」はオペレーションがホストにより実行されることを意味し、「Ｃ」はオペレーションがカードにより実行されることを意味する。システムＡＣＲを生成するために、ホストはメモリデバイス１０のＳＳＡに対して、システムＡＣＲを生成するコマンドを発行する（矩形２０２）。デバイス１０は、システムＡＣＲが既に存在するか否かをチェックすることにより対応する（矩形２０４、菱形２０６）。システムＡＣＲが既に存在する場合、デバイス１０は失敗ステータスを返し、ストップする（楕円２０８）。システムＡＣＲが存在しない場合、メモリ１０はシステムＡＣＲの生成が許可されるか否かを確認するためにチェックを行い（菱形２１０）、許可されない場合、失敗ステータスを返す（矩形２１２）。このように、例えば、システムＡＣＲを必要としないように、必要なセキュリティ機能が予め定められている場合、デバイス発行者がシステムＡＣＲの生成を許可しないこともある。ＡＣＲの生成が許可される場合、デバイス１０はＯＫステータスを返し、ホストからのシステムＡＣＲ証明書を待つ（矩形２１４）。ホストは、ＳＳＡのステータスをチェックし、デバイス１０がシステムＡＣＲの生成が許可されることを示しているか否かをチェックする（矩形２１６および菱形２１８）。生成が許可されない場合、またはシステムＡＣＲが既に存在する場合、ホストはストップする（楕円２２０）。デバイス１０がシステムＡＣＲの生成パーミッションを示している場合、ホストはそのログイン証明書を定義するためのＳＳＡコマンドを発行し、これをデバイス１０に送信する（矩形２２２）。デバイス１０は受信した証明書を使用してシステムＡＣＲ記録を更新し、ＯＫのステータスを返す（矩形２２４）。このステータス信号に対応して、ホストはシステムＡＣＲの準備完了を示すＳＳＡコマンドを発行する（矩形２２６）。デバイス１０は、システムＡＣＲの更新または差し換えができないように、システムＡＣＲをロックすることにより対応する（矩形２２８）。これは、システムＡＣＲの機能およびホストに対してデバイス１０を識別するための身元を確定する。

新たなツリー（新たなルートＡＧＰ（Ｎｅｗ Ｒｏｏｔ ＡＧＰｓ）およびＡＣＲ）の生成手順は、これらの機能がデバイスに設定される方法により決定される。図９はこの手順を説明している。ホスト２４およびメモリシステム１０の両方がこれに従う。新たなルートＡＧＰの追加が完全に無効となる場合、新たなルートＡＧＰを追加することはできない（菱形２４６）。新たなＡＧＰの追加が有効であるが、システムＡＣＲを必要とする場合、ホストはルートＡＧＰ生成コマンドの発行前に（矩形２５４）、システムＡＣＲを通じて認証し、セキュアチャネルを確立する（菱形２５０、矩形２５２）。システムＡＣＲを必要としない場合（菱形２４８）、ホスト２４は認証なしでルートＡＧＰ生成コマンド（Ｒｏｏｔ ＡＧＰ ｃｏｍｍａｎｄ）を発行することが可能であり、矩形２５４に進む。システムＡＣＲが存在する場合には、システムＡＣＲを必要としない場合であっても（フローチャートには図示せず）、ホストはこれを使用してもよい。デバイス（例えば、フラッシュカード）は、上記機能が無効の場合には、新たなルートＡＧＰを生成する如何なる試みも拒否し、システムＡＣＲを必要とする場合には、認証なしで新たなルートＡＧＰを生成する試みを拒否する（菱形２４６および２５０）。矩形２５４で新たに生成されたＡＧＰおよびＡＣＲは、ＡＧＰ内のＡＣＲの更新、さもなければ変更ができないように、ここでオペレーションモードに切り替えられる。これにより、ＡＣＲをさらに追加できないようになる（矩形２５６）。そして、さらにルートＡＧＰを生成できないように、システムが選択可能にロックされる（矩形２５８）。矩形２５８は、このステップが選択可能なステップであることを示すために、慣例として破線で図示されている。本出願の図面のフローチャートにおいて破線で示す矩形のすべては選択的なステップである。これにより、コンテンツ所有者は、合法的なコンテンツを有する本物のメモリデバイスを模倣し得る他の違法目的のデバイス１０のユーザをブロックすることが可能となる。

図１０に示されているように、（上記の通り、ルートＡＧＰ内のＡＣＲ以外の）ＡＣＲを生成するために、ＡＣＲを生成する権利を有する任意のＡＣＲから開始してもよい（矩形２７０）。エンティティは、エントリポイントＡＣＲアイデンティティ（ｅｎｔｒｙ ｐｏｉｎｔ ＡＣＲ ｉｄｅｎｔｉｔｙ）と、それが生成したいあらゆる必要な属性を備えたＡＣＲと、を提供することにより、ホスト２４を通じてツリーへのエントリを試みるかもしれない（矩形２７２）。ＳＳＡは、ＡＣＲの身元との照合をチェックし、当該身元を有するＡＣＲがＡＣＲの生成パーミッションを有するか否かをチェックする（菱形２７４）。当該要求に権限があると証明された場合、デバイス１０のＳＳＡはＡＣＲを生成する（矩形２７６）。

図１１は、図１０の方法を使用するセキュリティアプリケーションにおいて有用なツリーを説明する２つのＡＧＰを示している。このように、マーケティングＡＧＰにおいて身元ｍ１を備えたＡＣＲは、ＡＣＲの生成パーミッションを有する。また、ＡＣＲ ｍ１は、鍵ＩＤ「マーケティング情報（Ｍａｒｋｅｔｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ）」に関連付けられたデータ、および、鍵ＩＤ「価格リスト（Ｐｒｉｃｅ Ｌｉｓｔ）」に関連付けられたデータを読み出しおよび書き込みするための鍵の使用パーミッションを有する。図１０の方法を使用して、ＡＣＲ ｍ１は２つのＡＣＲを備えたセールスＡＧＰを生成するが、ここで、２つのＡＣＲとは、ｓ１およびｓ２であり、鍵ＩＤ「マーケティング情報」に関連付けられたデータへのアクセスに必要な鍵ではなく、鍵ＩＤ「価格リスト」に関連付けられた価格データにアクセスするための鍵の読み出しパーミッションのみを備えている。この方法で、ＡＣＲｓ ｓ１およびｓ２を備えたエンティティは、価格データの読み出しのみが可能であり、同データを変更することはできず、マーケティングデータへのアクセスを有していない。一方、ＡＣＲ ｍ２は、ＡＣＲの生成パーミッションを有していないが、鍵ＩＤ「価格リスト」および鍵ＩＤ「マーケティング情報」に関連付けられたデータにアクセスするための鍵の読みだしパーミッションのみを有している。

このように、ｍ１がｓ１およびｓ２に対して価格データの読み出し権を委譲するという上述の方法で、アクセス権限が委譲されてもよい。大規模なマーケティングおよびセールスグループが関与している状況では、特にこの方法は有用である。営業担当者が存在するが、その人数が１名または数名の場合には、図１０の方法を使用する必要はない。その代わりに、図１２に図示すように、ＡＣＲが同一ＡＧＰ内の低位レベルまたは同一レベルのＡＣＲにアクセス権限を委譲してもよい。第一に、上述の方法でホストを通じてツリー上のＡＣＲを特定することにより、エンティティはそうしたＡＧＰに対するツリーに入る（矩形２８０）。次に、ホストはＡＣＲおよび委譲する権利を特定する。ＳＳＡは、当該ＡＣＲに対する一または複数のツリーをチェックし、ＡＣＲが特定された他のＡＣＲに権利を委譲するパーミッションを有するか否かをチェックする（菱形２８２）。権利を有する場合、権利は委譲され（矩形２８４）、権利を有さない場合には、権利委譲をストップする。この結果が図１３で説明されている。この場合、ＡＣＲ ｍ１はＡＣＲ ｓ１に対して読み出しパーミッションを委譲するパーミッションを有しており、ｓ１はパーミッションの委譲後に価格データにアクセスする鍵を使用することが可能となる。これは、ｍ１が価格データにアクセスする権利と同一またはより高位レベルの権利を有し、このように委譲するパーミッションを有する場合に実行されてもよい。一実施形態に於いて、ｍ１はパーミッションの委譲後に当該アクセス権限を保有する。アクセス権限は、好ましくは、例えば限られた時間、限られたアクセス回数等、（その後、むしろ永遠に）制限された状況下で委譲されてもよい。

図１４には、鍵および鍵ＩＤの生成プロセスが示されている。エンティティがＡＣＲを通じて認証を行う（矩形３０２）。エンティティがホストにより特定されたＩＤを備えた鍵の生成を要求する（矩形３０４）。ＳＳＡは、特定されたＡＣＲが鍵の生成パーミッションを有するか否かをチェックし確認する（菱形３０６）。例えば、鍵が特定のパーティションにおけるデータにアクセスするために使用される場合、ＳＳＡはＡＣＲが当該パーティションにアクセス可能か否かをチェックし確認する。ＡＣＲが権限を有する場合、メモリデバイス１０はホストにより供給された鍵ＩＤに関連付けられた鍵値を生成し（矩形３０８）、鍵ＩＤをＡＣＲに保存し、鍵値をそのメモリ（コントローラ関連メモリまたはメモリ２０）に保存する。そして、エンティティにより供給された情報に従って、権利およびパーミッションを割り当て（矩形３１０）、当該割り当てられた権利およびパーミッションを用いて、当該ＡＣＲのＰＣＲを修正する（矩形３１２）。このように、鍵のクリエータは、例えば、読み出しおよび書き込みパーミッション、委譲権および同一ＡＧＰの他のＡＣＲまたは低位レベルのＡＣＲとの共有権、鍵の所有権の譲渡権など、あらゆる利用可能な権利を有する。

図１５に図示すように、ＡＣＲはＳＳＡシステムにおいて他のＡＣＲのパーミッション（またはその存在すべて）を変更することが可能である。エンティティは、既に述べたように、ＡＣＲを通じてツリーに入ることが可能である。即ち、一例ではエンティティが認証されると、ＡＣＲを特定する（矩形３３０、３３２）。エンティティは、ターゲットＡＣＲの削除またはターゲットＡＣＲにおけるパーミッションを要求する（矩形３３４）。特定されたＡＣＲまたはこの時点でアクティブなＡＣＲが当該要求に関する権利を有する場合（菱形３３６）、ターゲットＡＣＲが削除されるか、ターゲットＡＣＲのＰＣＲが当該パーミッションを削除するために変更される（矩形３３８）。これが権限を与えられない場合、システムはストップする。

上記のプロセス後、ターゲットは、当該プロセス以前にアクセス可能であったデータにアクセスすることができなくなる。図１６に示されているように、エンティティはターゲットＡＣＲでツリーに入ろうとするかもしれないが（矩形３５０）、以前存在していたＡＣＲのＩＤがＳＳＡにもはや存在していないので、認証プロセスに失敗していることが判明する。その結果、アクセス権限は拒否される（菱形３５２）。ＡＣＲのＩＤが削除されていないことを想定した場合、エンティティはＡＣＲを特定し（矩形３５４）、特定のパーティションにおける鍵ＩＤおよび／またはデータを特定する（矩形３５６）。そして、ＳＳＡはそうしたＡＣＲのＰＣＲにしたがって、鍵ＩＤまたはパーティションアクセス要求が許可されたか否かを確認するためにチェックする（菱形３５８）。パーミッションが削除されている、または期限切れとなっている場合、当該要求は再び拒否される。それ以外の場合、当該要求は認められる（矩形３６０）。

上記のプロセスは、ＡＣＲおよびＡＣＲのＰＣＲが他のＡＣＲによって変更されたかどうか、または、初めからそのように設定されていたかどうかに関係なく、保護データへのアクセスがデバイス（例えば、フラッシュカード）によってどのように管理されるかを説明している。

《セッション》
ＳＳＡシステムは、同時にログインした複数ユーザを処理するように設計されている。この機能は、ＳＳＡにより受信された各コマンドが特定のエンティティに関連付けられており、このエンティティの認証に使用されたＡＣＲが要求されたアクションに対するパーミッションを有する場合にのみ実行されることを必要とする。

複数のエンティティはセッションコンセプト（ｓｅｓｓｉｏｎ ｃｏｎｃｅｐｔ）を通じてサポートされる。セッションは認証プロセス中に確立され、ＳＳＡシステムによりセッションＩＤが割り当てられる。セッションＩＤは、システムへのログインに使用されるＡＣＲと内部的に関連付けられており、さらなるＳＳＡコマンドすべてにおいて使用されるエンティティに対してエクスポートされる。

ＳＳＡシステムは以下の２種類のセッションをサポートする。すなわち、オープンセッション（ｏｐｅｎ ｓｅｓｓｉｏｎ）とセキュアセッション（ｓｅｃｕｒｅ ｓｅｓｓｉｏｎ）である。特定の認証プロセスに関連付けられたセッションタイプは、ＡＣＲで定義される。ＳＳＡシステムは、認証自体を実行する方法と類似の方法でセッションの確立を実行する。ＡＣＲはエンティティのパーミッションを定義するので、このメカニズムにより、システム設計者はセキュアトンネル（ｓｅｃｕｒｅ ｔｕｎｎｅｌｉｎｇ）を、特定の鍵ＩＤへのアクセスと、特定のＡＣＲ管理オペレーションの呼び出し（ｉｎｖｏｋｉｎｇ）（即ち、新しいＡＣＲの生成および証明書の設定）と、の何れかと関連付けることが可能になる。

《オープンセッション》
オープンセッションとは、バス暗号化を使用せずに、セッションＩＤを使用して識別されるセッションであり、すべてのコマンドおよびデータが問題なく通過する。このオペレーションモードは、エンティティが脅威モデルの一部ではなく、バスの盗聴もしていない、複数ユーザまたは複数エンティティの環境で使用されることが好ましい。

データの伝送保護も、ホスト側アプリケーション間の効果的なファイアウォールの有効化も行わないが、オープンセッションモードにより、ＳＳＡシステムは、現状で認証されたＡＣＲに許可された情報のみへのアクセスを許可することができる。

また、オープンセッションは、パーティションまたは鍵の保護が必要となる場合に使用することが可能である。しかし、妥当な認証プロセス後に、アクセスはホストにおけるすべてのエンティティに認められる。認証されたＡＣＲのパーミッションを獲得するために様々なホストアプリケーションが唯一共有する必要があるのは、セッションＩＤである。これは図１７Ａにおいて説明されている。ライン部４００より上に記載されているステップは、ホスト２４が実行するステップである。エンティティは、ＡＣＲ１に対して認証された後（矩形４０２）、メモリデバイス１０において鍵ＩＤＸに関連付けられたファイルへのアクセスを要求する（矩形４０４、４０６、４０８）。ＡＣＲ１のＰＣＲが当該アクセスを許可する場合、デバイス１０は当該要求を認める（菱形４１０）。それ以外の場合、システムは矩形４０２に戻る。 認証完了後、メモリシステム１０は、割り当てられたセッションＩＤ（ＡＣＲ証明書ではない）によってのみコマンドを発行するエンティティを識別する。一旦ＡＣＲ１がそのＰＣＲにおける鍵ＩＤに関連付けられたデータへのアクセスを獲得すると、オープンセッションにおいて、任意の他のアプリケーションまたはユーザが、ホスト２４における異なるアプリケーション間で共有される正しいセッションＩＤを特定することにより、同一データにアクセスすることが可能である。この機能がアプリケーションで有益であるのは、一度だけでログイン可能であり、異なるアプリケーションに対してログインが実行されるアカウントに関連付けられたすべてのデータにアクセス可能であるので、ユーザの利便性がより高いという点である。このように、携帯電話のユーザは、ログインを複数回数行うことなく、保存されたＥメールにアクセスし、メモリ２０に保存された音楽を聴くことが可能であってもよい。一方、ＡＣＲ１に含まれていないデータにはアクセス不可能である。このように、同一の携帯電話ユーザは、別のアカウントＡＣＲ２を通じてアクセス可能な、例えばゲームおよび写真等の有益なコンテンツを有するかもしれない。ユーザが自身の最初のアカウントＡＣＲ１を通じて利用可能なデータに他者がアクセスすることを気にしないとしても、これは、ユーザが自身の電話を借りる他者がアクセスすることを望まないデータなのである。オープンセッションにおいてＡＣＲ１へのアクセスを許可しつつ、データへのアクセスを２つの別々のアカウントに分割することにより、価値のあるデータの保護を利用可能にするだけでなく、利便性も提供する。

ホストアプリケーション間のセッションＩＤを共有するプロセスをさらに容易にするために、ＡＣＲがオープンセッションを要求する際に、ＡＣＲはセッションに「０（ゼロ）」ＩＤを割り当てることを具体的に要求することが可能である。このように、アプリケーションを事前に定義されたセッションＩＤを使用するように設計することが可能である。明白な理由から、唯一の制約は、セッション０を要求する一つのＡＣＲだけを特定の時間に認証可能であるということである。セッション０を要求する他のＡＣＲを認証する試みは拒否される。

《セキュアセッション（ｓｅｃｕｒｅ ｓｅｓｓｉｏｎ）》
図１７Ｂに示すように、セキュリティレイヤ（ｌａｙｅｒ ｏｆ ｓｅｃｕｒｉｔｙ）を追加するために、セッションＩＤを使用してもよく、この場合、メモリ１０はアクティブなセッションのセッションＩＤを保存する。図１７Ｂにおいて、例えば、鍵ＩＤＸに関連付けられたファイルへのアクセスを可能にするために、エンティティは、ファイルへのアクセスを許可される前に、例えばセッションＩＤ「Ａ」等のセッションＩＤを提供する必要もある（矩形４０４、４０６、４１２および４１４）。この方法では、要求するエンティティが正しいセッションＩＤを認識しない限り、エンティティはメモリ１０にアクセスすることができない。セッション終了後にセッションＩＤは削除され、セッションＩＤがセッション毎に異なるので、エンティティはセッション番号を供給可能な状況にある場合に限りアクセスを獲得することができる。

ＳＳＡシステムは、セッション番号を使用する以外に、実際にコマンドが適切に認証されたエンティティから送信されていることを確かめる方法がない。攻撃者が悪意のあるコマンドを送信するためにオープンチャネルの使用を試みる脅威が存在する場合でのアプリケーションの使用に際して、ホストアプリケーションはセキュアセッション（セキュアチャネル）を使用する。

セキュアチャネルを使用する場合、コマンド全体だけでなく、セッションＩＤもセキュアチャネル暗号（セッション）鍵で暗号化され、セキュリティレベルはホスト側で実行されているセキュリティレベルと同程度に高い。

《セッションの終了》
下記のシナリオの内、何れか一つのシナリオでセッションは終了し、ＡＣＲはログオフされる。
１．エンティティが明確なセッション終了コマンドを発行する。
２．通信時のタイムアウト。特定のエンティティが、ＡＣＲパラメータの一つとして定義された期間（ｔｉｍｅ ｐｅｒｉｏｄ）において、コマンドを発行しなかった。
３．デバイス（例えば、フラッシュカード）の再起動および／または電源の入れ直し後、すべてのオープンセッションが終了する。

《データ完全性サービス（ｄａｔａ ｉｎｔｅｇｒｉｔｙ ｓｅｒｖｉｃｅｓ）》
ＳＳＡシステムは、（ＡＣＲ，ＰＣＲ等のすべてを含む）ＳＳＡデータベースの完全性を検証する。さらに、データ完全性サービスが鍵ＩＤメカニズムを通じてエンティティデータに提供される。

鍵ＩＤに暗号アルゴリズムとしてハッシュアルゴリズムが組み込まれている場合、ハッシュ値（ｈａｓｈ ｖａｌｕｅ）がＣＥＫおよびＩＶとともにＣＥＫ記録に保存される。ハッシュ値は書き込みオペレーション中に算出され、保存される。ハッシュ値は読み出しオペレーション中に再び算出され、以前の書き込みオペレーション中に保存されたハッシュ値と比較される。エンティティが鍵ＩＤにアクセスする度に、追加のデータが古いデータおよび更新された（読み出しまたは書き込みに対する）適切なハッシュ値に（暗号方法的に）連結される。

ホストのみが、鍵ＩＤに関連付けられた、または鍵ＩＤにより示されたデータファイルを区別しているので、ホストは以下に示す方法で、データ完全性機能の幾つかの面を明確に管理する：
１．鍵ＩＤに関連付けられた、または鍵ＩＤにより示されたデータファイルが最初から最後まで書き込まれ、読み出される。ＳＳＡシステムがＣＢＣ暗号法を使用し、データ全体のハッシュ化メッセージダイジェスト（ｈａｓｈｅｄ ｍｅｓｓａｇｅ ｄｉｇｅｓｔ）を生成するので、ファイルの一部にアクセスする任意の試みは失敗する。
２．中間ハッシュ値がＳＳＡシステムにより維持されるので、連続ストリームにおいてデータを処理する必要はない（データストリームは他の鍵ＩＤのデータストリームと交互配置する（ｉｎｔｅｒｌｅａｖｅｄ）ことができ、複数セッションに亘って分割してもよい）。しかし、データストリームが再起動される場合、エンティティは明確にＳＳＡシステムに対してハッシュ値をリセットするように指示する必要がある。
３．読み出しオペレーションの完了時に、ホストは、読み出しハッシュを書き込みオペレーション中に算出されたハッシュ値と比較することにより、明確にＳＳＡシステムに対して読み出しハッシュを認証するように要求しなければならない。
４．さらに、ＳＳＡシステムは「ダミー読み出し（ｄｕｍｍｙ ｒｅａｄ）」オペレーションを提供する。この機能は、暗号化エンジンを通じてデータをストリームするが、ホストに対してデータを送信しない。この機能は、実際にデータデバイス（例えば、フラッシュカード）から読み出される前に、データ完全性を検証するために使用可能である。

《乱数の生成》
ＳＳＡシステムは、外部のエンティティが内部の乱数ジェネレータ（ｒｕｎｄｏｍ ｎｕｍｂｅｒ ｇｅｎｅｒａｔｏｒ）を利用し、ＳＳＡシステムの外部で使用される乱数を要求することを可能にする。このサービスは任意のホストに利用可能であり、認証を必要としない。

《ＲＳＡ鍵ペアの生成》
ＳＳＡシステムは、外部のユーザが、内部のＲＳＡ鍵ペア生成機能を利用し、ＳＳＡシステムの外部で使用されるＲＳＡ鍵ペアを要求することを可能にする。このサービスは任意のホストに利用可能であり、認証を必要としない。

《代替実施形態》
図１８で説明するように、階層アプローチを使用する代わりに、データベースアプローチを使用して同様の結果を達成することが可能である。

図１８に示すように、エンティティに対する証明書のリスト、認証方法、失敗した試行の最大回数、およびブロック解除に必要な証明書の最小数が、コントローラ１２またはメモリ２０に保存されたデータベースに入力されてもよく、これは、そうした証明書の要求をメモリ１０のコントローラ１２により実行されたデータベースにおけるポリシー（鍵およびパーティションに対する読み出し、書き込みアクセス、およびセキュアチャネル要求）に関連付けるものである。また、鍵およびパーティションへのアクセスに関する制約（ｃｏｎｓｔｒａｉｎｔｓ）および制限（ｌｉｍｉｔａｔｉｏｎ）がデータベースに保存されている。このように、エンティティ（例えば、システム管理者）の中には、ホワイトリストに掲載されものがいるかもしれないが、これは、これらのエンティティが常にすべての鍵およびパーティションにアクセス可能であることを意味する。他のエンティティはブラックリストに掲載されるかもしれないが、他のエンティティが任意の情報にアクセスを試みる場合にはブロックされる。制限はグローバル（ｇｌｏｂａｌ）であってもよいし、鍵および／またはパーティション固有（ｋｅｙ ａｎｄ／ｏｒ ｐａｒｔｉｔｉｏｎ ｓｐｅｃｉｆｉｃ）であってもよい。これは、所定のエンティティのみが常に特定の鍵およびパーティションにアクセス可能であり、所定のエンティティは常にこれが不可能であることを意味する。コンテンツが存在するパーティションまたはコンテンツを暗号化または復号するために使用される鍵に関係なく、制約もコンテンツ自体に課すことができる。このように、所定のデータ（例えば、歌曲）は、どのエンティティがアクセスしたかに関係なく、所定のデータにアクセスする最初の５つのホストデバイスによってのみ、当該所定のデータにアクセス可能であるという属性、または、他のデータ（例えば、映画）が限られた回数だけ読み出し可能であるという属性を有してもよい。
《認証》
パスワード保護
・ パスワード保護は、保護領域にアクセスするためにパスワードを提示する必要があることを意味する。パスワード保護が２つ以上のパスワードになることが不可能でなければ、パスワードは、例えば読み出しアクセス、または読み出し／書き込みアクセス等の異なる権利と関係付けることができる。
・ パスワード保護とは、デバイス（例えば、フラッシュカード）がホストにより提供されたパスワードを検証することができることを意味する。即ち、デバイスもデバイスが管理するセキュアメモリ領域に保存されたパスワードを有する。
問題および限界
・ パスワードは、リプライ攻撃（ｒｅｐｌｙ ａｔｔａｃｋ）を受けやすい。パスワードは、毎回提示された後に変化しないので、全く同じようにパスワードを再送することができる。これは、保護されるデータに価値があり、コミュニケーションバスが容易にアクセス可能である場合、パスワードをそのまま使用してはならないということを意味している。
・ パスワードは保存されたデータへのアクセスを保護することはできるが、（鍵ではなく）データの保護に使用すべきではない。
・ ハッカーがシステム全体を破壊しないように、パスワードに関連付けられたセキュリティレベルを高めるためには、マスタ鍵を使用してパスワードを多様化することができる。パスワード送信のために、セキュアコミュニケーションチャネルに基づくセッション鍵を使用可能である。

図１９は、パスワードを使用する認証を説明するフローチャートである。エンティティは、アカウントＩＤおよびパスワードをシステム１０（例えば、フラッシュメモリカード）に送信する。システムは、パスワードがメモリ内のパスワードと一致するか否かを確認するためにチェックする。一致する場合、認証ステータスが返される。そうでなければ、そのアカウントに対してエラーカウンタがインクリメントされ、エンティティはアカウントＩＤおよびパスワードを再入力するよう求められる。カウンタがオーバーフロー（ｏｖｅｒｆｌｏｗ）した場合、システムはアクセス拒否のステータスを返す。

《チャレンジレスポンス（ｃｈａｌｌｅｎｇｅ ｒｅｓｐｏｎｓｅ）》
図２０は、チャレンジ／レスポンス型の方法を使用する認証を説明するフローチャートである。エンティティは、アカウントＩＤを送信し、システム１０からチャレンジ（ｃｈａｌｌｅｎｇｅ）を要求する。システム１０は乱数を生成し、ホストに提示する。ホストは、当該乱数からレスポンス（ｒｅｓｐｏｎｓｅ）を算出し、これをシステム１０に送信する。システム１０は当該レスポンスと保存された値を比較する。残りのステップは、図１９のアクセスを認めるか否かを決定するステップと同様である。

図２１は、他のチャレンジ／レスポンス型の方法を使用する認証を説明するフローチャートである。図２１に示す認証は以下の点で図２０の認証と異なる。即ち、図２１の認証は、ホストがシステム１０により認証されることを要求するだけでなく、システム１０がチャレンジ／レスポンスにより認証されることも要求するのであり、当該チャレンジ／レスポンスでは、システム１０はホストからのチャレンジを要求し、ホストによりチェックされるレスポンスを返す。

図２２は、他のチャレンジ／レスポンス型の方法を使用する認証を説明するフローチャートである。この場合、システム１０の認証のみが必要であり、当該認証ではホストはシステム１０にチャレンジを送信する。システム１０は、システム１０に関する記録との照合のためにホストによりチェックされるレスポンスを算出する。

《対称鍵》
対称鍵アルゴリズムとは、ホスト側およびデバイス側でＳＡＭＥ鍵(ＳＡＭＥ Ｋｅｙ)が暗号化および復号に使用されることを意味する。即ち、これは鍵がコミュニケーション前に事前に合意されていることを意味する。また、ホスト側およびデバイス側のそれぞれが、互いのリバースアルゴリズム（ｒｅｖｅｒｓｅ ａｌｇｏｒｉｔｈｍ）を実行すべきである。即ち、一方で暗号化アルゴリズムを実行し、他方で復号アルゴリズムを実行するということである。ホスト側およびデバイス側の双方がコミュニケーションのために両方のアルゴリズムを実行する必要はない。
《認証》
対称鍵認証とは、デバイス（例えば、フラッシュカード）およびホストが同一の鍵を共有し、同一の暗号アルゴリズム（ダイレクトアルゴリズムおよびリバースアルゴリズム、例えば、ＤＥＳおよびＤＥＳ−１）を有することを意味する。
対称鍵認証とは、（リプライ攻撃から保護する）チャレンジレスポンスを意味する。保護されたデバイスは、他のデバイスに対してチャレンジを生成し、両者がレスポンスを算出する。認証デバイスはレスポンスを返信し、保護されたデバイスは、当該レスポンスをチェックし、これにより認証を確認する。そして、認証に関連付けられた権利を認めることができる。
可能な認証の種類は下記の通りである：
外部認証：デバイス（例えば、フラッシュカード）が外部を認証する。即ち、デバイスが所定のホストまたはアプリケーションの証明書を確認する。
相互認証：チャレンジがデバイス側およびホスト側で生成される。
内部認証：ホストアプリケーションがデバイス（例えば、フラッシュカード）を認証する。即ち、ホストが、そのアプリケーションに対してデバイスが本物であるか否かをチェックする。
システム全体のセキュリティレベルを高めるためには（即ち、破壊者がすべてを破壊しない）、
・通常、対称鍵がマスタ鍵を使用する多様化（ｄｉｖｅｒｓｉｆｉｃａｔｉｏｎ）と併用される。
・相互認証が、チャレンジが本物のチャレンジであることを確実にするために、デバイス側およびホスト側からのチャレンジを使用する。
暗号化：対称鍵暗号化も暗号化に使用されているが、これは、対称鍵暗号化が非常に効果的なアルゴリズムだからである。すなわち、対称鍵暗号化は暗号化処理に強力なＣＰＵを必要としない。

コミュニケーションチャネルの保護に使用される場合：
両デバイスは、チャネルの保護に使用されるセッション鍵を理解しなければならない（即ち、すべての発信データを暗号化し、すべての着信データを復号する）。通常、当該セッション鍵は、事前に共有された秘密対称鍵またはＰＫＩを用いて確立される。
両デバイスは、同一の暗号アルゴリズムを理解し、実行しなければならない。

《署名》
また、対称鍵をデータの署名に使用することが可能であり、この場合、署名は暗号化の部分的な結果である。結果を部分的に維持することにより、鍵値を暴露することなく、必要な回数だけ署名することを許可する。

《問題および限界》
対称アルゴリズムは非常に効果的で安全であるが、事前に共有された秘密に基づいている。問題は、この秘密を動的な方法で安全に共有すること、および、恐らく秘密を（例えば、セッション鍵のように）ランダムにすることである。つまり、共有された秘密を長期間安全に守ることは困難であり、複数の人々と共有することは殆ど不可能だということである。

このオペレーションを促進するために、公開鍵アルゴリズムが発明されたが、これは、当該アルゴリズムにより、秘密を共有することなく秘密の交換が可能となるからである。

《公開鍵暗号化》
非対称鍵アルゴリズムは、一般に公開鍵暗号と称す。これは非常に複雑であり、通常、ＣＰＵによる集中的な数学的処理により実行される。当該アルゴリズム、対称鍵アルゴリズムに関連する鍵分配（ｋｅｙ ｄｉｓｔｒｉｂｕｔｉｏｎ）の問題を解決するために発明された。また、これはデータの完全性を確実にするために使用される署名機能を提供する。

非対称鍵アルゴリズムは、それぞれが秘密鍵および公開鍵と称される、秘密要素および公開要素を有する鍵を使用する。秘密鍵と公開鍵の両方は、数学的に関連付けられている。公開鍵は共有可能であり、一方、秘密鍵は秘匿性を維持しなければならない。これらの鍵に関しては、ラップ（ｗｒａｐ）およびラップ解除（ｕｎｗｒａｐ）、または署名および照合を提供するために、（一つが秘密鍵用であり、一つが公開鍵用の）２つの数学的関数を使用する。

《鍵交換および鍵分配》
鍵交換は、ＰＫアルゴリズムを使用すれば非常に簡単になる。デバイスは公開鍵を他のデバイスに送信する。他のデバイスは、この公開鍵を用いて自身の秘密鍵をラップし、前者のデバイスに暗号化されたデータを返す。前者のデバイスは、データのラップ解除に自身の秘密鍵を使用し、両者に周知であって且つデータ交換に使用可能な秘密鍵を取り出す。対称鍵はこのように容易に交換可能であることから、通常、乱数鍵が使用される。

《署名》
通常、公開鍵アルゴリズムは、その性質上、小量のデータの署名のみに使用される。データの完全性を確実にするために、その後、公開鍵アルゴリズムはメッセージの一方向フットプリント（ｏｎｅ−ｗａｙ ｆｏｏｔ ｐｒｉｎｔ）を提供するハッシュ関数と併用される。

秘密鍵はデータの署名に使用される。（自由に利用可能な）公開鍵は署名の照合を許可する。

《認証》
通常、認証は署名を必要とする。即ち、チャレンジが署名され、照合のために返される。

鍵の公開部分が照合に使用される。誰でも鍵ペアを生成できるので、公開鍵の所有者が正しい鍵を使用している正しい人物であることを証明するために、当該所有者を認証する必要がある。認証局（ｃｅｒｔｉｆｉｃａｔｉｏｎ ａｕｔｈｏｒｉｔｙ）は、証明書を供給し、署名された証明書に公開鍵を組み込む。当該証明書は認証局自身により署名される。そして、署名の照合に公開鍵を使用するということは、その鍵を組み込む証明書を発行した認証局が信用できるものであり、証明書がハッキングされてない、即ち、認証局によりハッシュ署名された証明書が正しいことを検証可能であることを意味する。また、これはユーザが認証局の公開鍵証明書を有しており、これを信用していることを意味する。

ＰＫ認証の提供に関する最も一般的な方法は、認証局またはルート証明書（ｒｏｏｔ ｃｅｒｔｉｆｉｃａｔｅ）を信用し、且つ、所定の認証局に認証されたすべての鍵ペアを間接的に信用することである。そして認証は、チャレンジに署名し、チャレンジレスポンスおよび証明書を提供することにより、各々が有する秘密鍵が証明書と一致することを証明する問題となる。そして、証明書は、ハッキングされておらず、信用できる認証局により署名されていることを確かめるためにチェックされる。そして、チャレンジレスポンスが照合される。証明書が信用できるものであり、チャレンジレスポンスが正しい場合、認証は成功する。

デバイス（例えば、フラッシュカード）における認証は、デバイスが信用できるルート証明書を使用してロードされており、デバイスがハッシュ署名された証明書だけでなくチャレンジレスポンスを照合可能であることを意味する。

《ファイルの暗号化》
ＰＫアルゴリズムは過度にＣＰＵに依存しているので、大量のデータの暗号化には使用されない。しかし、通常、ＰＫアルゴリズムはコンテンツの暗号化のために生成されたランダム暗号化／復号鍵を保護するために使用される。例えば、ＳＭＩＭＥ（セキュアＥメール；ｓｅｃｕｒｅ ｅｍａｉｌ）は、すべての受信者の公開鍵を用いて暗号化される鍵を生成する。

《問題および限界》
何でも鍵ペアを生成することが可能であるので、鍵ペアの出所を確実にするために認証を受けなければならない。鍵の交換中に、秘密鍵が正しいデバイスに提供されているかを確かめたいと思うかもしれない。即ち、提供された公開鍵の出所はチェックを受ける必要がある。そして、証明書管理が鍵の妥当性に関する情報と、鍵が無効な状態であるか否かに関する情報を提供することができることから、証明書管理がセキュリティの一部となる。

本発明は、様々な実施形態を参照することにより上述の通り記載されているが、当然のことながら、変更および修正は本発明の範囲から逸脱することなく可能であり、本発明は添付の請求項およびそれらの等価物によってのみ定義されるべきである。ここで参照されたすべての参考文献は、参照することにより本発明に組み込まれる。

本発明の説明に好適なホストデバイスと通信するメモリシステムのブロック図である。 本発明の一実施形態を説明する概略図であって、メモリの異なるパーティションと異なるパーティションに保存された暗号化されていないファイルおよび暗号化ファイルに関するもので、ここでは、あるパーティションおよび暗号化ファイルへのアクセスがアクセスポリシーおよび認証手順により制御されるものである。 メモリ内の異なるパーティションを例示するメモリの概略図である。 本発明の一実施形態を説明するための、図３に図示されたメモリ内の異なるパーティションに関するファイルロケーションテーブルの概略図であって、ここではパーティション内のいくつかのファイルが暗号化されているものである。 本発明の一実施形態を説明するための、アクセス制御された記録グループおよび関連するキーリファレンスにおけるアクセス制御記録に関する概略図である。 本発明の一実施形態を説明するためアクセス制御された記録グループおよびアクセス制御された記録によって形成されたツリー構造の概略図である。 ツリーの形成プロセスを説明するためアクセス制御された記録グループの３階層ツリーを例示したツリーの概略図である。 ホストデバイスおよびメモリデバイス（例えば、システムアクセス制御記録を生成および使用するためのメモリカード等）が実行するプロセスを例示したフローチャートである。 ホストデバイスおよびメモリデバイス（例えば、システムアクセス制御記録を生成および使用するためのメモリカード等）が実行するプロセスを例示したフローチャートである。 本発明を説明するためアクセス制御された記録グループを生成するためにシステムアクセス制御記録を使用するプロセスを例示したフローチャートである。 アクセス制御記録の生成プロセスを例示したフローチャートである。 階層ツリーの特定アプリケーションの説明に好適な２つのアクセス制御記録グループの概略図である。 特定の権利の委譲プロセスを例示したフローチャートである。 図１２の委譲プロセスを説明するためアクセス制御された記録グループおよびアクセス制御記録の概略図である。 暗号化および／または復号目的の鍵生成プロセスを例示したフローチャートである。 アクセスされ制御された記録に応じて、アクセス権限および／またはデータアクセスパーミッションを取り除くプロセスを例示したフローチャートである。 アクセス権限および／またはアクセスパーミッションが削除された、または期限切れになった場合のアクセス要求プロセスを例示したフローチャートである。 本発明の他の実施形態を説明するための、暗号鍵へのアクセスを許可するための認証およびポリシーに対するルール構造の構成を例示した概略図である。 本発明の他の実施形態を説明するための、暗号鍵へのアクセスを許可するための認証およびポリシーに対するルール構造の構成を例示した概略図である。 幾つかのセッションがオープン状態での認証セッションおよびアクセスセッションを例示したフローチャートである。 図１９は、他の認証プロセスを例示したフローチャートである。 図２０は、他の認証プロセスを例示したフローチャートである。 図２１は、他の認証プロセスを例示したフローチャートである。 図２２は、他の認証プロセスを例示したフローチャートである。 本出願においては、説明を簡略化するために、同一部分については同一符号が付与されている。

《付録Ａ》
１ ＳＳＡコマンド
ＳＳＡシステムコマンドは、スタンダード（関連のフォームファクタプロトコルに対して）書き込み・読み取りコマンドを用いて、メモリーカードに渡される。したがって、ホストから見て、ＳＳＡコマンドを送信することは、実際には、データをメモリデバイス上でバッファ・ファイルとして用いられる特別なファイルに書き込むことを意味する。ＳＳＡシステムから情報を得ることは、バッファファイルからデータを読み取ることによって行われる。ホストアプリケーションは、データが常に書き込まれて、バッファファイルの第１のＬＢＡから読み取られることを確認する必要がある。ホストＯＳにおいてバッファファイルを管理することは、この明細書の範囲外である。
１．１ＳＳＡシステムとの通信
以下のセクションは、どのように、フォームファクタスタンダード書き込み／読み取りコマンドを用いることによって、ＳＳＡと関連するコマンドおよびデータがＳＳＡシステムと通信されるかを定義する。
１．１．１ コマンド／データのＳＳＡシステムへの送信
すべての書き込みコマンドごとの第１データブロックは、シグネチャを通じてパスに対してスキャンされる。見つかった場合、データがＳＳＡコマンドとして解釈される。見つからなかった場合、データは、指定されたアドレスに書き込まれる。
ＳＳＡアプリケーション特定の書込コマンドは、マルチプルセクタトランスファを含むことができる。ここで、第１セクタは必要なシグネチャおよびコマンドの引数を保持し、残りのデータブロックが関連するデータを保持する（もしあれば）。
テーブル．．．ＳＳＡコマンドの第１ブロックのフォーマット（スタンダードＯＳファイルシステムにおいて用いられる場合、データブロックは常に５１２バイトである）を定義する。

１．１．２ ＳＳＡシステムからのデータ読み取り
読み取りコマンドは、２つのパートで実行される：
１．読み取りコマンドのすべての引数を定義する単一データブロックを備えた書込コマンドをまず送信することにより、読み取りコマンドを開始する。
２．書き込みコマンドが、カードアプリケーションを転送の正しい状態にセットした後、読み取りコマンドを用いてカードからホストへの実際のデータ転送を開始する。読み取りコマンドは、先の書込コマンドが用いたのと同じＬＢＡアドレスを用いなければならない。これは、カードに対しホストがＳＳＡデータを得ようとしているという唯一の指示である（先に要求された）。
書き込み／読み取りコマンド・ペアは注意深く同期されなければならない。次のセッションは、どのようにシーケンスエラーが扱われ、回復されるかを定義する。定義された通り、ＳＳＡシステムは、同時にログオンできる複数のホスト側ユーザをサポートする。それぞれのユーザは、独立且つ非同期で書き込み／読み取りコマンド・ペアを開始することを希望するため、ホストＯＳの特別な行動は必要ではない。カードの点から見て、これらの個々のペアは、シーケンスのライト（書き込み）ハーフにおいて用いられるＬＢＡアドレスによって識別される。ホストから見て、それぞれのユーザが異なるファイルバッファを用いなければならないことを意味する。
１．１．３ 書き込み／読み取りシーケンス・エラー
１．２コマンドの詳細な説明
テーブル２は、ＳＳＡコマンドの全体的な概要を提供する。
コマンド名欄は、コマンド使用法の基本的な説明およびコマンドの詳細な説明のインデックスを提供する コマンド・Ｏｐ−ｃｏｄｅは、ＳＳＡコマンドにおいて用いられる実際の値である。引数長さ（Ａｒｇ Ｌｅｎ）欄は、コマンドの引数フィールドのサイズ（ゼロの値は、引数がないことを意味する）を定義する。
引数は、コマンド特定であり、詳細なコマンド説明中で指定される。
データ長さは、コマンドと関連づけられた追加のデータ・ブロックにおけるコマンド・データのサイズである。ゼロの値は、データがないことを意味する。「Ｖａｒ」の値は、コマンドが、変数データサイズを持っていることを意味し、実際のサイズはコマンド自体の中で指定される。固定サイズのデータ・コマンドについては、この欄は、データサイズのサイズを記憶する。
データ方向は、コマンドがデータを持たない（テーブル１に指定されたコマンド引数が、すべて、バイト７６とバイト５１１との間のスペースに収まることを意味する−これを越えることは、コマンド・セクタに伴うデータ・ペイロードを課す）場合、ブランクであり、データがホストからカードに移っている（書込コマンドの引数ブロックに付加されて）場合、「ｗｒｉｔｅ」であり、あるいは、データがカードからホストへ移っている（上述の通り、引数を提供する書込コマンドに続く、読み取りコマンドにおいて）場合、「ｒｅａｄ」である。
すべてのサイズに関連する欄は、バイト単位を用いる。

１．２．１ Ｃｒｅａｔｅ Ｓｙｓｔｅｍ ＡＣＲ
Ｃｒｅａｔｅ Ｓｙｓｔｅｍ ＡＣＲは、ＳＳＡデータベース内にシステムＡＣＲエントリを構築する。一度エントリが生成されると、指定されたログインアルゴリズムにしたがって信用証明を構成することができる。最後に、ＣＲＥＡＴＥ＿ＳＹＳＴＥＭ＿ＡＣＲ＿ＤＯＮＥコマンドがシーケンスを終了し、かつシステムＡＣＲをアクティブにするために用いられる。
ＡＣＲエントリが既に存在する場合、あるいは、システムＡＣＲの生成機能が無効にされている場合には、Ｃｒｅａｔｅ Ｓｙｓｔｅｍ ＡＣＲコマンドは拒絶される。システムＡＣＲを、利用可能なログイン・モードのサブセットのみで構成することができる（詳細には、セクション１．３．２を参照）。無効モードが用いられている場合、コマンドは拒絶される。
コマンド引数は、表３に示される。バイトオフセットは、コマンド引数ＬＢＡの開始と関連がある（セクション１．１．１を参照）。引数の長さは、バイト単位で示される。引数名は、引数の目的を定義しており、詳細な引数の説明へのインデックスとして用いることができる。

１．２．２ Ｓｙｓｔｅｍ ＡＣＲ Ｃｒｅａｔｉｏｎ Ｄｏｎｅ
このコマンドは、システムＡＣＲ生成が開始した後のみ送信される。他のタイミングでは、コマンドは拒絶される。このコマンドの送信により、システムＡＣＲ生成を終了し、ＡＣＲを恒久的に現在の構成とする。このコマンドに対する引数はない。
１．２．３ ＰＡＳＳＷＯＲＤ ＣＲＥＤＥＮＴＩＡＬ
ＳＳＡコマンド［２８］―ＣＲＥＡＴＥ＿ＡＣＲを送信した後に、ＡＣＲの信用証明の送信が、続けて行われる。この場合、それはある特定の長さのパスワードであり、−バイトの最大長は２０である。

１．２．４ ＳＹＭＭＥＴＲＩＣ ＣＲＥＤＥＮＴＩＡＬ
ＡＣＲに対する対称的ログイン手順を選択する場合、ＡＥＳ、ＤＥＳあるいは３ＤＥＳキーの態様をとるＡＣＲの対称的信用証明の送信が続けて行われる。アルゴリズムの特性は、バイトでの信用証明の（キー）長さを示す。このコマンドは、正規のＡＣＲおよびシステムＡＣＲ作成時に、用いることができる。
Ｅｒｒｏｒ！ Ｒｅｆｅｒｅｎｃｅ ｓｏｕｒｃｅ ｎｏｔ ｆｏｕｎｄ．テーブル１３は、異なるタイプの非対称的信用証明について説明する。

１．２．５ 非対称形信用証明
非対称形ログイン手順を備えたＡＣＲについては、ＳＳＡに渡されなければならないいくつかの信用証明がある。以下のテーブル１４は、異なるタイプの非対称形信用証明について説明する。

１．２．６ 公開鍵のエクスポート（ＥＸＰＯＲＴ ＰＵＢＬＩＣ ＫＥＹ）
１．２．７ 証明書のインポート（ＩＭＰＯＲＴ ＣＥＲＴＩＦＩＣＡＴＥ）
１．２．８ ＡＣＡＭの設定
このコマンドの送信は、ＡＣＲ管理パーミッションを構成する。コマンドは、システムＡＣＲ生成の際のみ送信される。コマンドは、システムＡＣＲに対しては有効ではない。ＡＣＡＭタイプおよびコードは「表１６：ＡＣＡＭタイプ」に示す。

１．２．９ ルートＡＧＰの生成
セキュアなチャンネルでルートＡＧＰを生成するために、システムＡＣＲを通したＳＳＡシステムログインを実行しなければならない。ログインの後、セッションＩＤが生成され、生成シーケンスに用いられる。セッションＩＤは、システムＡＣＲログインシーケンスが行われた直後にシステム−コマンド・リターン・ステータスを要求する場合には、利用可能である。システムＡＣＲに最初にログインせず、ルートＡＧＰを生成する（セキュアなチャンネルでルートＡＧＰを生成する）ことは、セッションＩＤを必要としない。
テーブル８は、コマンド引数を再表示する。システムＡＣＲを用いない場合、セッションＩＤフィールドは、ＮＵＬＬ（ＮＡ）とされる。そのＡＧＰ名／ＩＤは、それの長さのバイト数に先行している。

コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＣＲＥＡＴＥ＿ＲＯＯＴ＿ＡＧＰ＿ＣＭＤ［３］
・コマンド引数
１．セッションＩＤ−必要か？
２．バイトでのＡＧＰ名／ＩＤ長さ−１バイト
３．ＡＧＰ名／ＩＤ−
１．２．１０ ルートＡＧＰ生成完了
ルートＡＧＰが完了した−ＡＧＰにおけるＡＣＲのすべてが生成されたことを意味する−とき、このコマンドは送信される。このコマンドはＡＧＰをロックして、これ以上のＡＣＲが生成されないようにする。
このコマンドに対する引数はない。
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＲＯＯＴ＿ＡＧＰ＿ＣＲＥＡＴＩＯＮ＿ＤＯＮＥ＿ＣＭＤ［４］
・コマンド引数
１．セッションＩＤ−必要か？
２．バイトでのＡＧＰ名／ＩＤ長さ−１バイト
３．ＡＧＰ名／ＩＤ−
１．２．１１ システムＡＣＲ生成不可（ＤＩＳＢＡＬＥ＿ＳＹＳＴＥＭ＿ＡＣＲ＿ＣＲＥＡＴＩＯＮ）
このコマンドの送信は、システムＡＣＲを生成する機能を終了させる。このコマンドは、引数を持たない。
１．２．１２ ルートＡＧＰ生成モードの設定（ＳＥＴ＿ＲＯＯＴ＿ＡＧＰ＿ＣＲＥＡＴＩＯＮ ＭＯＤＥ）
ルートＡＧＰの生成のコントロールは、ＳＳＡコマンド［１９］ＳＥＴ＿ＲＯＯＴ＿ＡＧＰ＿ＣＲＥＡＴＩＯＮ＿ＭＯＤＥで扱われる。異なるモードに対するコードは、テーブル９において説明される。このコマンドは、ＳＳＡにログインする必要がなく、したがって、セッションＩＤは、必要とされない。

１．２．１３ ルートＡＧＰ変更不可モード（ＤＩＳＢＡＬＥ＿ＲＯＯＴ＿ＡＧＰ＿ＣＨＡＮＧＥ＿ＭＯＤＥ）
このコマンドは、ＳＥＴ＿ＲＯＯ＿ＡＧＰ＿ＣＲＥＡＴＩＯＮ＿ＭＯＤＥコマンドを作動不能にする。また、ＳＳＡによって拒絶される場合もある。このコマンドは、引数を持たない。
１．２．１４ ＡＧＰの生成（Ｃｒｅａｔｅ ＡＧＰ）

コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＣＲＥＡＴＥ＿ＡＧＰ＿ＣＭＤ［５］
・コマンド引数
１．セッションＩＤ−１バイト
２．バイトでのＡＧＰ名／ＩＤ長さ−１バイト
３．ＡＧＰ名／ＩＤ−
１．２．１５ ＡＧＰの削除（Ｄｅｌｅｔｅ ＡＧＰ）
このコマンドは、ＡＧＰを生成したＡＣＲに有効である、ただし、そのＡＧＰには、ＡＣＲがない場合。
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＤＥＬＥＴＥ＿ＡＧＰ＿ＣＭＤ［６］
・コマンド引数
１．セッションＩＤ−１バイト
２．バイトでのＡＧＰ名／ＩＤ長さ−１バイト
３．ＡＧＰ名／ＩＤ−
１．２．１６ Ｃｒｅａｔｅ ＡＣＲ
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＣＲＥＡＴＥ＿ＡＣＲ＿ＣＭＤ［７］
・コマンド引数
１．ＡＧＰ名／ＩＤ−
２．ＡＣＲ名／ＩＤ−
３．ログインアルゴリズム−１バイト
４．キー長さ
５．ブロック解除するＡＣＲ名／ＩＤ
６．管理権の数（ＡＣＡＭ）−１バイト
７．ＡＣＡＭ＃１
８．ＡＣＡＭ＃ｎ
１．２．１７ ＡＣＲのアップデート（Ｕｐｄａｔｅ ＡＣＲ）
このコマンドは、ＡＣＲクリエータによってのみ送信することができ、これにより、子ＡＣＲを更新する。ルートＡＧＰに存在するＡＣＲは、それらに親ＡＣＲがないとき、更新することができない。
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＵＰ＿ＤＡＴＥ＿ＡＣＲ＿ＣＭＤ［８］
・コマンド引数
１．セッションＩＤ−１バイト
２．バイトでのＡＧＰ名／ＩＤ長さ−１バイト
３．ＡＧＰ名／ＩＤ−
４．バイトでのＡＣＲ名／ＩＤ長さ−１バイト
５．ＡＣＲ名／ＩＤ−
１．２．１８ ＡＣＲの削除（Ｄｅｌｅｔｅ ＡＣＲ）
このコマンドは、ＡＣＲクリエータによってのみ送信することができ、これにより、子ＡＣＲを削除する。ルートＡＧＰに存在するＡＣＲは、それら自身を削除する機能を持っている。
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＤＥＬＥＴＥ＿ＡＣＲ＿ＣＭＤ［９］
・コマンド引数−
１．セッションＩＤ−１バイト
２．バイトでのＡＧＰ名／ＩＤ長さ−１バイト
３．ＡＧＰ名／ＩＤ−
４．バイトでのＡＣＲ名／ＩＤ長さ−１バイト
５．ＡＣＲ名／ＩＤ−
１．２．１９ ＡＣＲのブロック解除（Ｕｎｂｌｏｃｋ ＡＣＲ）
このコマンドは、この明示的なパーミッションを備えたＡＣＲによってのみ送信することができ、これにより、ある特定のＡＣＲをブロック解除する。
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＵＮＢＬＯＣＫ＿ＡＣＲ＿ＣＭＤ［１０］
・コマンド引数
１．セッションＩＤ−１バイト
２．バイトでのＡＧＰ名／ＩＤ長さ−１バイト
３．ＡＧＰ名／ＩＤ−
４．バイトでのＡＣＲ名／ＩＤ長さ−１バイト
５．ＡＣＲ名／ＩＤ−
１．２．２０ ドメインパーミッションの委譲（Ｄｅｌｅｇａｔｅ Ｄｏｍａｉｎ Ｐｅｒｍｉｓｓｉｏｎｓ）
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＤＥＬＥＧＡＴＥ＿ＤＯＭＡＩＮ＿ＰＥＲＭＩＳＳＩＯＮ＿ＣＭＤ［１１］
・コマンド引数
１．セッションＩＤ−１バイト
２．委譲するパーミッションの数−１バイト
３．委譲されるパーミッションコード
４．バイトでのドメイン名／ＩＤ長さ−１バイト
５．ドメイン名／ＩＤ
１．２．２１ パーミッションの生成（Ｃｒｅａｔｅ Ｐａｒｔｉｔｉｏｎ）
このコマンドは、ルートＡＧＰに存在するＡＣＲによってのみ送信することができる。
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＣＲＥＡＴＥ＿ＰＡＲＴＩＴＩＯＮ＿ＣＭＤ［１２］
・コマンド引数
１．セッションＩＤ−１バイト
２．バイトでのパーティション名／ＩＤ長さ−１バイト
３．パーティション名／ＩＤ
４．セクター［５１２バイト］内におけるパーティションサイズ−４バイト
５．バイトでの減少されるパーティション名／ＩＤ長さ−１バイト
６．減少されるパーティション名／ＩＤ
１．２．２２ パーミッションのアップデート（Ｕｐｄａｔｅ Ｐａｒｔｉｔｉｏｎ）
このコマンドは、ルートＡＧＰに存在するＡＣＲによってのみ送信することができる。
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＵＰＤＡＴＥ＿ＰＡＲＴＩＴＩＯＮ＿ＣＭＤ［１３］
・コマンド引数
１．セッションＩＤ−１バイト
２．バイトでのパーティション名／ＩＤ長さ−１バイト
３．パーティション名／ＩＤ
４．セクター［５１２バイト］内におけるパーティションサイズ−４バイト
５．バイトでの減少されるパーティション名／ＩＤ長さ−１バイト
６．減少されるパーティション名／ＩＤ

１．２．２３ パーミッションの削除（Ｄｅｌｅｔｅ Ｐａｒｔｉｔｉｏｎ）
このコマンドは、ルートＡＧＰに存在するＡＣＲによってのみ送信することができる。
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＤＥＬＥＴＥ＿ＰＡＲＴＩＴＩＯＮ＿ＣＭＤ［１４］
・コマンド引数
６．セッションＩＤ−１バイト
７．バイトでのパーティション名／ＩＤ長さ−１バイト
８．パーティション名／ＩＤ
１．２．２４ 公開ドメインへのアクセスの制限（Ｒｅｓｔｒｉｃｔ Ｐｕｂｌｉｃ Ｄｏｍａｉｎ Ａｃｃｅｓｓ）
このコマンドは、正規の、公開パーティション（別名ユーザエリア）を／に、読み取り／書き込むコマンド（ホストによって送信されたコマンドであって、ＳＳＡコマンド・プロトコルの一部でない）を、制限する。
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＲＥＳＴＲＩＣＴ＿ＰＡＵＢＬＩＣ＿ＰＡＲＴＩＴＩＯＮ＿ＣＭＤ［１５］
・コマンド引数
１．セッションＩＤ−１バイト
２．公開パーティション制限コード−１バイト
１．２．２５ Ｃｒｅａｔｅ Ｄｏｍａｉｎ
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＣＲＥＡＴＥ＿ＤＯＭＡＩＮ＿ＣＭＤ［１６］
・コマンド引数
１．セッションＩＤ−１バイト
２．バイトでのパーティション名／ＩＤ長さ−１バイト
３．パーティション名／ＩＤ
４．バイトでのドメイン名／ＩＤ長さ−１バイト
５．ドメイン名／ＩＤ
１．２．２６ ドメインの削除（Ｄｅｌｅｔｅ Ｄｏｍａｉｎ）
ドメイン・オーナーのみが、このコマンドを送信し、ドメインを削除できる。
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＤＥＬＥＴＥ＿ＤＯＭＡＩＮ＿ＣＭＤ［１７］
・コマンド引数
１．セッションＩＤ−１バイト
２．バイトでのパーティション名／ＩＤ長さ−１バイト
３．パーティション名／ＩＤ
４．バイトでのドメイン名／ＩＤ長さ−１バイト
５．ドメイン名／ＩＤ
１．２．２７ システムログイン（Ｓｙｓｔｅｍ Ｌｏｇｉｎ）
このコマンドは、ホストユーザがＡＣＲのうちの１つを通してＳＳＡシステムを用いたい場合、発行される。コマンドは、ログイン／認証プロセスを開始する。
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＳＹＳＴＥＭ＿ＬＯＧＩＮ＿ＣＭＤ［１８］
・コマンド引数
１．バイトでのＡＧＰ名／ＩＤ長さ−１バイト
２．ＡＧＰ名／ＩＤ−
３．バイトでのＡＣＲ名／ＩＤ長さ−１バイト
４．ＡＣＲ名／ＩＤ−
１．２．２８ システムログアウト（Ｓｙｓｔｅｍ Ｌｏｇｏｕｔ）
このコマンドは、ホストユーザがＳＳＡシステムによる作業セッションを終了したい場合、発行される。コマンドは、現在のログインセッションに対するユーザ活動のすべてを終了する。このコマンドの後では、ホストユーザが、ＳＳＡシステムによるさらなるアクションを実行することができるようにするには、再びログインプロセスを開始する必要がある。
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＳＹＳＴＥＭ＿ＬＯＧＯＵＴ＿ＣＭＤ［１９］
・コマンド引数
１．バイトでのＡＧＰ名／ＩＤ長さ−１バイト
２．ＡＧＰ名／ＩＤ−
３．バイトでのＡＣＲ名／ＩＤ長さ−１バイト
４．ＡＣＲ名／ＩＤ−
１．２．２９ 読み込み（Ｒｅａｄ）
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＲＥＡＤ＿ＣＭＤ［２０］
・コマンド引数
１．セッションＩＤ−１バイト
２．バイトでのパーティション名長さ−１バイト
３．パーティション名
４．バイトでのドメイン名長さ−１バイト
５．ドメイン名
６．パーティションアドレス（ＬＢＡ）−４バイト
７．読み取るＬＢＡの数（セクター（Ｓｅｃｔｏｒｓ）−セクター（Ｓｅｃｔｏｒ）＝５１２バイト）−４バイト
１．２．３０ 書き込み（Ｗｒｉｔｅ）
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＷＲＩＴＥ＿ＣＭＤ［２１］
・コマンド引数
１．セッションＩＤ−１バイト
２．バイトでのパーティション名長さ−１バイト
３．パーティション名
４．バイトでのドメイン名長さ−１バイト
５．ドメイン名
６．パーティションアドレス（ＬＢＡ）−４バイト
７．読み取るＬＢＡの数（セクター（Ｓｅｃｔｏｒｓ）−セクター（Ｓｅｃｔｏｒ）＝５１２バイト）−４バイト
１．２．３１ コマンドステータス（Ｃｏｍｍａｎｄ Ｓｔａｔｕｓ）
このステータスコマンドを送信することで、先に送信したコマンドのリターン・ステータスを得ることができる。ステータスは、コマンド・プロセスおよびＳＳＡシステム状態を扱う。
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＣＭＤ＿ＳＴＡＴＵＳ＿ＣＭＤ［２２］
・コマンド引数−
１セッションＩＤ−１バイト
１．２．３２ システムクエリー（Ｓｙｓｔｅｍ Ｑｕｅｒｙ）
システムクエリーコマンドは、ログインされるＡＣＲの範囲にあるＳＳＡ情報を読み取る。
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＳＹＳ＿ＱＵＥＲＹ＿ＣＭＤ［２３］
・コマンド引数−
１セッションＩＤ−１バイト
１．２．３３ パスワード認証コマンド
１．２．３３．１ ＳＳＡへのパスワード送信
コマンドは、ＳＳＡによって確認される実際のＡＣＲパスワードを送信する。Ｃｏｍｍａｎｄ Ｓｔａｔｕｓコマンド（２２）を送信することで、ホストは、コマンド・ステータスと、そして、コマンド完了と同時に、認証プロセスのステータス−ＰＡＳＳ／ＦＡＩＬ−と、を読み取ることができる。
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＰＷＤ＿ＡＵＴＨ＿ＳＥＮＤ ＰＷＤ＿ＣＭＤ［２４］
・コマンド引数
１．バイトでのパスワード長さ−１バイト
２．パスワードデータ
１．２．３４ 対称形的認証コマンド
１．２．３４．１ ＳＳＡからのチャレンジ受け取り
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＳＹＭ＿ＡＵＴＨ＿ＧＥＴ＿ＣＨＬＧ＿ＣＭＤ［２５］
・コマンド引数
１．２．３４．２ ＳＳＡへのチャレンジ送信
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＳＹＭ＿ＡＵＴＨ＿ＳＥＮＤ＿ＣＨＬＧ＿ＣＭＤ［２６］
・コマンド引数
１．２．３４．３ ＳＳＡからのチャレンジレスポンス受け取り
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＳＹＭ＿ＡＵＴＨ＿ＧＥＴ＿ＣＨＬＧ＿ＲＥＳ＿ＣＭＤ［２７］
・コマンド引数
１．２．３４．４ ＳＳＡからのチャレンジレスポンス送信
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＳＹＭ＿ＡＵＴＨ＿ＳＥＮＤ＿ＣＨＬＧ＿ＲＥＳ＿ＣＭＤ［２８］
・コマンド引数
１．２．３５ 非対称形認証プロセスコマンド
１．２．３５．１ ＳＳＡへのチャレンジ送信
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＡＳＹＭ＿ＡＵＴＨ＿ＳＥＮＤ＿ＣＨＬＧ＿ＣＭＤ［２９］
・コマンド引数−チャレンジ乱数−２８バイト
１．２．３５．２ ＳＳＡからのチャレンジ受け取り
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＡＳＹＭ＿ＡＵＴＨ＿ＧＥＴ＿ＣＨＬＧ＿ＣＭＤ［３０］
・コマンド引数−ＮＡ
１．２．３５．３ ＳＳＡへのＣＡ証明書の送信
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＡＳＹＭ＿ＡＵＴＨ＿ＳＥＮＤ＿ＣＡ＿ＣＥＲＴ＿ＣＭＤ［３１］
・コマンド引数
１．２．３５．４ ＳＳＡプレ・マスター・シークレットの受け取り
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＡＳＹＭ＿ＡＵＴＨ＿ＧＥＴ＿ＰＲＥ＿ＭＡＳＴＥＲ＿ＳＥＣＲＥＴ＿ＣＭＤ［３２］
・コマンド引数
１．２．３５．５ ＳＳＡからのＡＣＲ証明書の受け取り
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＡＳＹＭ＿ＡＵＴＨ＿ＧＥＴ＿ＣＨＬＧ＿ＣＭＤ［３３］
・コマンド引数
１．２．３５．６ ＳＳＡへのホスト・プレ・マスター・シークレットの送信
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＡＳＹＭ＿ＡＵＴＨ＿ＳＥＮＤ＿ＰＲＥ＿ＭＡＳＴＥＲ＿ＳＥＣＲＥＴ＿ＣＭＤ［３４］
・コマンド引数
１．２．３５．７ スタート・セッション・マッサージの送信
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＡＳＹＭ＿ＡＵＴＨ＿ＳＥＮＤ＿ＳＴＡＲＴ＿ＳＥＳＳＩＯＮ＿ＭＳＧ＿ＣＭＤ［３５］
・コマンド引数
１．ＰＩＮオプション−
２．バイトでのＰＩＮ長さ
３．ＰＩＮストリング
１．２．３５．８ ＳＳＡからの認証の総合的なメッセージの受け取り
コマンド構造：
・コマンド名／ＯＰ Ｃｏｄｅ−１バイト：ＳＳＡ＿ＳＹＭ＿ＡＵＴＨ＿ＧＥＴ＿ＣＨＬＧ＿ＣＭＤ［３６］
・コマンド引数
１．３ ＳＳＡコマンド引数
１．３．１ Ｎｏｔ Ａｐｐｌｉｃａｂｌｅ
引数リストにおいてＮｏｔ Ａｐｐｌｉｃａｂｌｅ （ＮＡ）として定義されたすべてのフィールドは、０でなければならない。
１．３．２ パスワードおよびＰＩＮ構造
パスワードおよびＰＩＮフレーズは２０バイトの長さであり、ＳＳＡシステムに対してバイナリー値である。２０バイトより短いフレーズには「０」を追加しなければならない。

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

１．３．４ 対称的信用証明シンボル

１．３．５ 非対称形信用証明タイプ

１．３．６ パーティション権

１．３．７ ドメイン権

１．３．８ ドメインパーミッションコード

１．３．９ ＡＣＡＭ

１．３．１０ 公開パーティション制限コード

１．３．１１ コマンドステータス

１．３．１２ ＳＳＡクエリー

１．３．１３ コマンドシーケンス
１．３．１３．１ ＳＳＡログインに対する相互対称的認証を介したコマンドシーケンス

このシーケンスが正常に行われた場合、ＳＳＡのＡＣＲがログインされ、ＳＳＡオペレーションを開始することができる。
１．３．１３．２ ルートＡＧＰを生成するコマンドシーケンス
ルートＡＧＰは、システムＡＣＲ（システムＡＣＲへのログインシーケンスを実行するよう、要求する）を介して、あるいはセキュアなチャンネルを断念し、システムＡＣＲ認証プロセスをスキップして生成することができる。コマンドＳＳＡ＿ＣＲＥＡＴＥ＿ＲＯＯＴ＿ＡＧＰ＿ＣＭＤ［３］は、ルートＡＧＰのアイデンティティとともに送信される。
このコマンドは、ＳＳＡ＿ＣＭＤ＿ＳＴＡＴＵＳ＿ＣＭＤ［２２］に続いて行うことができ、これにより、ＳＳＡがコマンドを拒絶せず、それがエラーなしで終わったことを確かめる。ルートＡＧＰが執行された且つその全てのＡＣＲが生成され、これにより、ルートＡＧＰが封印された場合、ＳＳＡ＿ＲＯＯＴ＿ＡＧＰ＿ＣＲＥＡＴＩＯＮ＿ＤＯＮＥ＿ＣＭＤ［４］コマンドが送信される。
１．３．１３．３ ＡＧＰを生成するコマンドシーケンス
ＡＧＰを生成するためには、ユーザは、１．３．１３．１に示したログイン・コマンド・シーケンスを実行することにより、ＳＳＡにまずログインしなければならない。ＡＧＰは、ＡＣＲの新しいグループを生成する前に、生成されなければならない。ＡＧＰは、コマンドＳＳＡ ＣＲＥＡＴＥ＿ＡＧＰ＿ＣＭＤ［５］をＡＧＰ名／ＩＤとともに送信するよって、生成される。
ＣＭＤ［５］がエラーなく受け取られ実行されたことを確認するために、ユーザはＳＳＡ＿ＣＭＤ＿ＳＴＡＴＵＳ＿ＣＭＤ［２２］を送信し、先に送信されたコマンドのステータスを読み取る。ユーザがＡＧＰを生成し終えたとき、続いて、ＡＣＲを生成する、あるいはＳＳＡシステムからログアウトことができる。
１．３．１３．４ ＡＣＲを生成するコマンドシーケンス
ＡＣＲを生成するためには、ユーザは、１．３．１３．１に示したログイン・コマンド・シーケンスを実行することにより、ＳＳＡにまずログインしなければならない。また、新しいＡＣＲに属するＡＧＰがあるはずである。そして、ユーザは、新しいＡＣＲデータ（名前、ＡＧＰ、ログイン方法等）のすべてとともに、コマンドＳＳＡ＿ＣＲＥＡＴＥ＿ＡＣＲ＿ＣＭＤ［７］を送信する。ＣＭＤ［７］がエラーなく受け取られ実行されたことを確認するために、ユーザはＳＳＡ＿ＣＭＤ＿ＳＴＡＴＵＳ＿ＣＭＤ［２２］を送信し、先に送信されたコマンドのステータスを読み取る。ユーザがＡＣＲを生成し終えたとき、続いて、他のＳＳＡオペレーション、あるいはＳＳＡシステムからログアウトを行うことができる。
１．４ プロダクトパラメータ
・すべてのエンティティの最大値（ＭＡＲＯ、ＡＲＣＲ、並列セッションなど）
・適用可能である暗号パラメータ、つまりＲＳＡキー長さ、に対する定義を追加
・プロトコル当たりのエラー条件およびメッセージを定義する必要
・タイムアウトおよびビジーの扱いを定義する必要。
・ツリーのレベル数の指定
・ルートＭＡＲＯの制限＃
・子（ルート上の）制限＃すべて？委譲はそこまで
・並列におけるＣＢＣコンテキストの数には、５〜１０などの制限がある。
・プロトコルおよびプロダクトバージョン

Claims (26)

1. 不揮発性メモリと、前記メモリへのアクセスをコントロールするコントローラと、を備えるストレージシステムに用いられるセキュアストレージ方法であって、
   コントローラあるいはメモリに記憶されたシステムエージェントを用いて、対応するエンティティによる前記メモリに記憶されたデータへのアクセスをコントロールするための異なるレベルのノードを有する少なくとも１つの階層的ツリーを、生成するステップであって、そのうち、前記少なくとも１つのツリーのそれぞれのノードが、メモリデータにアクセスする、対応するエンティティのパーミッションを指定しており、前記ツリーのそれぞれのノードにおけるパーミッションは、同じツリーのより高いあるいはより低いレベルでの他のノードにおけるパーミッションと、所定の関係を有している生成ステップと、
   メモリデータへのアクセスをコントロールするよう少なくとも１つの階層的ツリーを用いるステップと、
   を備える方法。
2. 前記生成ステップは、少なくとも２つのツリーを生成し、前記エージェントによって生成された前記少なくとも２つのツリー間には、クロストークがない請求項１に記載の方法。
3. 前記エージェントによって生成されたいずれのツリーの最初のノードはルートノードであり、エージェントを無効にするステップをさらに備え、前記エージェントによって生成されたいずれのツリーの前記ルートノードも、前記エージェントが無効になされた後は、変更することができない、請求項１に記載の方法。
4. 前記エージェントを無効にするステップをさらに備え、追加ツリーが生成できなくなるようにする、請求項１に記載の方法。
5. それぞれの前記ツリーのノードにおける前記パーミッションは、前記同じツリーのより低いレベルのノードにおけるパーミッションによって示されるアクセス権限以上の前記メモリ内のデータへのアクセス権限を示す、請求項１に記載の方法。
6. 前記ツリーの前記ノードは、前記メモリ中のデータへのエンティティによるアクセスを可能にする下位レベルの子ノードを生成する機能を有しており、前記子ノードを生成するステップをさらに備える、請求項１に記載の方法。
7. 前記子ノードの前記パーミッションは、前記子ノードを生成したノードのパーミッションより上位でない、請求項６に記載の方法。
8. ツリーのノードにおける前記パーミッションは、対応するエンティティが、前記同じツリーにおいて他のノードを生成および／または削除すること、および／または前記同じツリーにおけるノードのパーミッションを変更すること、および／または前記同じツリーにおける他のノードにパーミッションを委譲すること、および／または前記同じツリーにおけるノードと他のノードとの関連を譲渡することを許可する方法であって、
   前記パーミッションに応じて、前記同じツリーにおいて、他のノードを削除するステップ、ノードにおいてパーミッションを変更するステップ、他のノードにパーミッションを委譲するステップ、および／または、ノードと他のノードとの関連を譲渡するステップ、をさらに備える請求項１に記載の方法。
9. ツリーのノードにおける前記パーミッションは、前記メモリ中のデータを暗号化および／または復号するためのキーへアクセスするためのものである、請求項１に記載の方法。
10. ツリーのノードにおける前記パーミッションは、前記メモリの１つ以上のパーティションにアクセスするためのものであり、前記パーミッションに応じて、前記メモリの前記１つ以上のパーティションにアクセスするステップをさらに備える、請求項１に記載の方法。
11. ノードにおける前記パーミッションは、データの暗号化および／または復号に対する鍵がエンティティの代わりに生成されることを許可し、前記パーミッションに応じて前記鍵を生成するステップをさらに備える、請求項１に記載の方法。
12. ノードにおける前記パーミッションは、対応するエンティティが、当該エンティティの代わりに生成された鍵のオーナーシップ、および／または鍵へのアクセスのパーミッションを委譲することを許可し、前記キーは、前記メモリに記憶されたデータを暗号化および／または復号する際に使用されたものであり、前記パーミッションに対応して、当該エンティティの代わりに生成された鍵のオーナーシップ、および／または鍵へのアクセスのパーミッションを委譲するステップをさらに備える、請求項１１に記載の方法。
13. ノードにおけるパーミッションは、鍵が既に作成された、対応するエンティティが前記鍵を削除することを許可し、前記パーミッションに対応して、前記キーを削除するステップをさらに備える、請求項１１に記載の方法。
14. 不揮発性メモリと、前記メモリへのアクセスをコントロールするコントローラと、を備えるセキュアストレージシステムであって、
    前記コントローラあるいはメモリは、対応するエンティティによるメモリに記憶されたデータへのアクセスをコントロールするための異なるレベルのノードを有する少なくとも1つの階層的ツリーを生成することが可能なシステムエージェントを記憶し、
    そのうち、少なくとも１つのツリーのそれぞれのノードが、メモリデータにアクセスするための対応するエンティティのパーミッションを指定しており、
    前記ツリーのそれぞれのノードにおけるパーミッションは、前記同じツリーのより高いあるいはより低いレベルにある他のノードにおけるパーミッションと、所定の関係を有しているシステム。
15. 前記エージェントによって生成された前記少なくとも２つのツリー間には、クロストークがない請求項１４に記載のシステム。
16. 前記エージェントによって生成されたいずれのツリーの最初のノードは前記ルートノードであり、前記エージェントが無効にされると、前記エージェントによって生成されたいずれのツリーの前記ルートノードも変更することができない、請求項１４に記載のシステム。
17. 前記エージェントが無効にされると、追加ツリーを生成できなくなる、請求項１４に記載のシステム。
18. 前記ツリーのそれぞれのノードにおける前記パーミッションは、前記同じツリーのより低いレベルのノードにおけるパーミッションによって示されるアクセス権限以上の前記メモリ内のデータへのアクセス権限を示す、請求項１４に記載のシステム。
19. ツリーのノードは、前記メモリ中のデータへのエンティティによるアクセスを可能にするより下位レベルの子ノードを生成する機能を有している、請求項１４に記載のシステム。
20. 前記子ノードの前記パーミッションは、前記子ノードを生成した前記ノードのパーミッションより上位でない、請求項１９に記載のシステム。
21. ツリーのノードにおける前記パーミッションは、対応するエンティティが、前記同じツリーにおいて他のノードを生成および／または削除すること、および／または前記同じツリーにおけるノードの前記パーミッションを変更すること、および／または前記同じツリーにおける他のノードにパーミッションを委譲すること、または前記同じツリーにおけるノードと他のノードとの関連を譲渡することを許可する、請求項１４に記載のシステム。
22. ツリーのノードにおける前記パーミッションは、前記メモリ中のデータを暗号化および／または復号するためのキーへのアクセスするためのものである、請求項１４に記載のシステム。
23. ツリーのノードにおける前記パーミッションは、前記メモリの１つ以上のパーティションにアクセスするためのものある、請求項１４に記載のシステム。
24. ノードにおける前記パーミッションは、データの暗号化および／または復号に対する鍵が対応するエンティティの代わりに生成されることを許可する、請求項１４に記載のシステム。
25. ノードにおける前記パーミッションは、当該エンティティの代わりに生成された鍵のオーナーシップ、および／または鍵へのアクセスのパーミッションを委譲することを許可し、前記鍵は、前記メモリに記憶されたデータを暗号化および／または復号する際に使用されたものである、請求項２４に記載のシステム。
26. ノードにおける前記パーミッションは、鍵が既に作成された、対応するエンティティが前記鍵を削除することを許可する、請求項２４に記載のシステム。

Images