JP2009543208A5 - - Google Patents

Description

証明書連鎖を使用するコンテンツ管理システムおよび方法

本発明は、一般的にはメモリシステムに関し、具体的には汎用コンテンツ制御機能を備
えるメモリシステムに関する。

関連出願の相互参照
本願は、２００６年７月７日に出願された米国仮特許出願第６０／８１９，５０７号（
特許文献１）の利益を主張する。

本願は、２００５年１２月２０日に出願された米国特許出願第１１／３１３，８７０号
（特許文献２）に関し、この出願は２００４年１２月２１に出願された米国仮特許出願第
６０／６３８，８０４号（特許文献３）の利益を主張する。本願はさらに、２００５年１
２月２０日に出願された米国特許出願第１１／３１４，４１１号（特許文献４）に関する
。本願はさらに、２００５年１２月２０日に出願された米国特許出願第１１／３１４，４
１０号（特許文献５）に関する。本願はさらに、２００５年１２月２０日に出願された米
国特許出願第１１／３１３，５３６号（特許文献６）に関する。本願はさらに、２００５
年１２月２０日に出願された米国特許出願第１１／３１３，５３８号（特許文献７）に関
する。本願はさらに、２００５年１２月２０日に出願された米国特許出願第１１／３１４
，０５５号（特許文献８）に関する。本願はさらに、２００５年１２月２０日に出願され
た米国特許出願第１１／３１４，０５２号（特許文献９）に関する。本願はさらに、２０
０５年１２月２０日に出願された米国特許出願第１１／３１４，０５３号（特許文献１０
）に関する。

本願は、２００６年１１月６日に出願されたHoltzmanらの「Content Control Method U
sing Certificate Chains 」という米国特許出願第１１／５５７，０２８号（特許文献１
１）と、２００６年１１月６日に出願されたHoltzmanらの「Content Control System Usi
ng Certificate Chains 」という米国特許出願第１１／５５７，０１０号（特許文献１２
）と、２００６年１１月６日に出願されたHoltzmanらの「Content Control Method Using
Certificate Revocation Lists 」という米国特許出願第１１／５５７，００６号（特許
文献１３）と、２００６年１１月６日に出願されたHoltzmanらの「Content Control Syst
em Using Certificate Revocation Lists 」という米国特許出願第１１／５５７，０２６
号（特許文献４）と、２００６年１１月６日に出願されたHoltzmanらの「Content Contro
l Method Using Versatile Control Structure」という米国特許出願第１１／５５７，０
４９号（特許文献１５）と、２００６年１１月６日に出願されたHoltzmanらの「Content
Control System Using Versatile Control Structure」という米国特許出願第１１／５５
７，０５６号（特許文献１６）と、２００６年１１月６日に出願されたHoltzmanらの「Me
thod for Controlling Information Supplied From Memory Device」という米国特許出願
第１１／５５７，０５２号（特許文献１７）と、２００６年１１月６日に出願されたHolt
zmanらの「System for Controlling Information Supplied From Memory Device」という
米国特許出願第１１／５５７，０５１号（特許文献１８）と、２００６年１１月６日に出
願されたHoltzmanらの「Control Method Using Identity Objects 」という米国特許出願
第１１／５５７，０４１号（特許文献１９）と、２００６年１１月６日に出願されたHolt
zmanらの「Control System Using Identity Objects 」という米国特許出願第１１／５５
７，０３９号（特許文献２０）とに関する。

これらの特許出願は、あたかも本願にもれなく記載されているかのごとく、それぞれの
全体が本願明細書において参照により援用されている。

フラッシュメモリカード等の記憶装置が、写真等のデジタルコンテンツを記憶する記憶
媒体として好んで使われるようになっている。フラッシュメモリカードはタイプの異なる
メディアコンテンツの配布に使われる場合がある。コンピュータ、デジタルカメラ、携帯
電話機、個人用携帯情報端末（ＰＤＡ）、ＭＰ３プレーヤをはじめとするメディアプレー
ヤ等のホスト装置の多様化が進み、フラッシュメモリカードに記憶されたメディアコンテ
ンツを再生できるようになっている。このため、フラッシュメモリカードやその他の可搬
型記憶装置がデジタルコンテンツの配布手段として幅広く利用される可能性が大きい。

デジタルコンテンツの所有者と配布者にとって最大の関心事のひとつは、インターネッ
ト等のネットワークからのダウンロードまたは記憶装置上でのコンテンツの配布を通じて
配布された後のコンテンツに対するアクセスを、権限を持つ当事者だけに許可することで
ある。不正アクセスを防ぐ一方法では、コンテンツへのアクセスを当事者に許諾する前に
当事者のアイデンティティを立証するシステムを使用する。公開鍵基盤（ＰＫＩ）等はこ
の目的のために開発されたシステムである。ＰＫＩシステムでは、証明局（ＣＡ）という
信用機関から人や組織のアイデンティティを証明するための証明書が発行される。アイデ
ンティティの立証を望む組織や人等の当事者は、それぞれのアイデンティティを証明する
にあたって十分な証拠を証明局に登録する。ＣＡに対して当事者のアイデンティティが証
明されたら、ＣＡからそのような当事者に証明書が発行される。この証明書は通常、証明
書を発行したＣＡの名称と、証明書の発行を受けた当事者の名称と、当事者の公開鍵と、
ＣＡの秘密鍵で署名された当事者の公開鍵（通常は公開鍵のダイジェストを暗号化するこ
とにより署名）とを含む。

ＣＡの公開鍵と秘密鍵にはつながりがあり、公開鍵を用いて暗号化されたデータは秘密
鍵によって復号化でき、その逆も可能である。したがって、秘密鍵と公開鍵とは、一対の
鍵をなす。RSA Security Inc. の２００２年６月１４日付「PKCS#1 v2.1:RSA Cryptograp
hy Standard 」では、暗号法のための一対の秘密鍵および公開鍵が説明されている。ＣＡ
の公開鍵は公に利用できる。したがって、ある当事者が相手方から提示される証明書の真
偽をベリファイするなら、ベリファイする側はＣＡの公開鍵を使用し、証明書の中にある
公開鍵の暗号化ダイジェストを復号化アルゴリズムを用いて復号化するだけでよい。この
復号化アルゴリズムもまた、通常ならば証明書の中で特定される。証明書の中にある公開
鍵の復号化ダイジェストが証明書の中にある暗号化されていない公開鍵のダイジェストに
一致するなら、ＣＡの信用とＣＡの公開鍵の真正性とに基づき、証明書の公開鍵に改竄が
なく本物であることが証明される。

ある当事者のアイデンティティをベリファイするにあたって、ベリファイする側は通常
、質問（例えば、乱数）を送り、相手方には自身の証明書と質問に対する回答（すなわち
、相手方の秘密鍵で暗号化された乱数）の送信を求める。回答と証明書が届いたら、ベリ
ファイする側はまず、証明書の公開鍵が真正か否かを前述したプロセスでベリファイする
。公開鍵の真正がベリファイされる場合、ベリファイする側は証明書の中にある公開鍵を
使って回答を復号化し、その結果を当初送信した乱数に比較する。それらが一致する場合
は相手方が正しい秘密鍵を所持していることを意味し、これをもって相手方は自身のアイ
デンティティを証明したことになる。証明書の中の公開鍵が真正でないか、あるいは復号
化された回答が質問に一致しないと、認証は失敗に終わる。したがって、自身のアイデン
ティティを証明することを望む当事者は、証明書と対応する秘密鍵の両方を所持する必要
がある。

前述したメカニズムにより、ことによると互いを信用できない２つの当事者でも、前述
したプロセスを用いて相手方の証明書の中にある相手方の公開鍵をベリファイすることよ
って信用を成立させることができる。国際電気通信連合（ＩＴＵ）電気通信標準化部門（
ＩＴＵ−Ｔ）の勧告Ｘ．５０９は証明書の枠組みを定める規格書である。証明書とその運
用に関する詳しい情報はこの規格書で確認できる。

運営管理と大規模組織の便宜を図るため、ルートＣＡと呼ばれる上位ＣＡが証明書発行
の責務をいくつかの下位ＣＡに委譲するとよい場合がある。例えば２レベル階層において
、最上位のルートＣＡは下位ＣＡの公開鍵が真正であることを証明するための下位ＣＡに
証明書を発行する。そして、下位ＣＡは前述した登録プロセスを通じて当事者に証明書を
発行する。ベリファイプロセスは証明書連鎖の頂点から始まる。ベリファイする側はまず
、ルートＣＡの公開鍵（真正と判明）を使用して、下位ＣＡの公開鍵の真性をベリファイ
する。下位ＣＡの公開鍵の真性がベリファイされたら、下位ＣＡから証明書の発行を受け
た当事者の公開鍵の真性を、下位ＣＡのベリファイ済み公開鍵を用いてベリファイできる
。このように、ルートＣＡと下位ＣＡとによって発行される証明書により、アイデンティ
ティベリファイの対象となる当事者の２つの証明書からなる連鎖が形成される。

勿論、証明書階層のレベルは２レベルを上回ることもあり、ルートＣＡを除く下位レベ
ルのＣＡはその権限を上位ＣＡから受け取り、上位ＣＡによって発行された公開鍵を含む
証明書を所持する。したがって、相手方の公開鍵の真性をベリファイするには、ルートＣ
Ａに至る経路、すなわち証明書の連鎖をたどる必要がある。換言すると、アイデンティテ
ィを立証するには、アイデンティティを証明する必要がある側が自身の証明書からルート
ＣＡ証明書にかけて一連の証明書を提示する必要がある。

前に指摘したように、ルート証明書と、ＣＡへ発行される全ての証明書、例えば前述し
た証明書階層の中で下位ＣＡへ発行される証明書は、公開される。今のところ、アイデン
ティティを証明するための証明書の提示には２通りの形式がある。最初の形式では、認証
を受けようとする側がＣＡによって発行された自身の証明書を提示するだけであり、この
証明書は証明書連鎖の中で最後の証明書にあたる。この証明書の発行元にあたるＣＡの公
開鍵をベリファイする側が持っていない場合、ＣＡの公開鍵を入手してベリファイを行う
かどうかはベリファイする側次第となる。ベリファイする側は、下位ＣＡの公開鍵をベリ
ファイするために上位証明局の公開鍵が必要となる場合、証明書の中にある発行元の名前
をもとに上位ＣＡの公開鍵と証明書に至る経路をたどる必要がある。このプロセスは、ベ
リファイする側が、さらなるベリファイがなくとも真正であることが分かる公開鍵のＣＡ
に到達するまで続く。

証明書認証の第２の形式では、認証を受けようとする側から連鎖内の証明書がすべて提
示されるが、それらの証明書は特定の順序で提示されるとは限らない。ベリファイする側
へ送信される連鎖の中での証明書の正確な順序に関する情報を、証明書と併せて、認証を
受けようとする側が提示しても、この情報がメッセージの後ろの方にあるなら、ベリファ
イする側は、証明書連鎖全体が届くまで証明書の正確な順序を知ることができない。

第１の証明書交換・ベリファイ形式では、ベリファイする側が不在の証明書にアクセス
できることが前提になっている。不在の証明書を入手するためにコンピュータや携帯電話
機等の装置でインターネット等のネットワークへアクセスすることはできても、これを果
たすためにフラッシュメモリカード等の記憶装置そのものが使われたわけではない。

第２の証明書交換・ベリファイ形式では、ベリファイする装置へ送信されるメッセージ
の中で全ての証明書が提示されるため、ベリファイする装置が証明書を入手する必要はな
い。しかし、証明書が特定の順序で送信されるとは限らず、連鎖における証明書の順序に
関する情報はメッセージのどこか、例えばメッセージの末尾に現れる。これは、連鎖の中
のいずれかの証明書をベリファイのために解析する前に、全ての証明書を受信し蓄積しな
ければベリファイにかかれないことを意味する。これはコンピュータ、ＰＤＡ、携帯電話
機等のホスト装置にとって問題にならないかもしれないが、記憶装置にとって問題になる
ことがある。記憶装置の内蔵メモリ容量と処理能力があまりにも限られていると、長い証
明書文字列を蓄積し効率よく解析することができない。

前述した様々な課題と問題のため、記憶装置とホスト装置で現在使われているシステム
で完全に満足のいくものはない。したがって、より良い特性を備える改良されたシステム
の提供が望まれる。

米国仮特許出願第６０／８１９，５０７号 米国特許出願第１１／３１３，８７０号 米国仮特許出願第６０／６３８，８０４号 米国特許出願第１１／３１４，４１１号 米国特許出願第１１／３１４，４１０号 米国特許出願第１１／３１３，５３６号 米国特許出願第１１／３１３，５３８号 米国特許出願第１１／３１４，０５５号 米国特許出願第１１／３１４，０５２号 米国特許出願第１１／３１４，０５３号 米国特許出願第１１／５５７，０２８号 米国特許出願第１１／５５７，０１０号 米国特許出願第１１／５５７，００６号 米国特許出願第１１／５５７，０２６号 米国特許出願第１１／５５７，０４９号 米国特許出願第１１／５５７，０５６号 米国特許出願第１１／５５７，０５２号 米国特許出願第１１／５５７，０５１号 米国特許出願第１１／５５７，０４１号 米国特許出願第１１／５５７，０３９号

証明書連鎖は複数の連続する証明書文字列を含む。それぞれの文字列は少なくとも１つ
の証明書を含む。ベリファイする実体にこれらの文字列が届くと、ベリファイする実体は
これらの文字列を順次ベリファイする。証明書の文字列がベリファイと同じ順序で受
信されるならば、前述した問題は回避される。このようなやり方で証明書の文字列を受信
し、かつ完全な証明書連鎖を受信するならば、記憶装置を使って連鎖内の証明書の真性を
ベリファイすることは容易い。

証明書連鎖の中で連続する証明書文字列がベリファイと同じ順序で順次受信されるなら
、ある１つの証明書文字列を受信しベリファイした後には、この証明書文字列の中にある
情報はもはや必要でなくなる。もうひとつの実施形態によると、受信されメモリ装置に蓄
積された少なくとも１つの証明書文字列は、順序の中の後続する文字列で上書きできる。
かくして、ベリファイにあたって連鎖内の証明書の蓄積に要する蓄積容量は格段に減らす
ことができる。

ここで参照する特許、特許出願、記事、書籍、仕様書、規格書、その他の出版物、文書
、物事はいずれも、あらゆる目的のためにその全体が本願明細書において参照により援用
されている。援用する出版物、文書、または物事のいずれかと本願明細書の本文との間で
用語の定義または使用に矛盾や食い違いがある場合、本願明細書における用語の定義また
は使用が優先するものとする。

本発明を例示するのに有用である、ホスト装置と通信するメモリシステムのブロック図である。 本発明の種々の実施形態を例示するのに有用である、特定のパーティションと暗号化ファイルへのアクセスをアクセス方針と認証手続きとによって制御するメモリの種々のパーティションと種々のパーティションに記憶される非暗号化および暗号化ファイルとの概略図である。 メモリ内の種々のパーティションを示すメモリの概略図である。 本発明の種々の実施形態を例示するのに有用である、パーティション内のいくつかのファイルが暗号化される図３に示すメモリの種々のパーティションのファイルロケーションテーブルの概略図である。 本発明の種々の実施形態を例示するのに有用である、アクセス制御記録グループ内のアクセス制御記録と対応する鍵参照符との概略図である。 本発明の種々の実施形態を例示するのに有用である、アクセス制御記録グループとアクセス制御記録とによって形成されるツリー構造の概略図である。 ツリーの形成プロセスを例示するための、アクセス制御記録グループからなる３つの階層ツリーを示すツリーの概略図である。 システムアクセス制御記録を作成し、かつ使用する場合にホスト装置とメモリカード等のメモリ装置とによって実行されるプロセスを示すフローチャートである。 システムアクセス制御記録を作成し、かつ使用する場合にホスト装置とメモリカード等のメモリ装置とによって実行されるプロセスを示すフローチャートである。 種々の実施形態を例示するのに有用である、システムアクセス制御記録を使ってアクセス制御記録グループを作成するプロセスを示すフローチャートである。 アクセス制御記録を作成するプロセスを示すフローチャートである。 階層ツリーの一応用を例示するのに有用である、２つのアクセス制御記録グループの概略図である。 特定の権利を委譲するプロセスを示すフローチャートである。 図１２の委譲プロセスを例示するための、アクセス制御記録グループとアクセス制御記録との概略図である。 暗号化および／または復号化の目的で鍵を作成するプロセスを示すフローチャートである。 アクセス制御記録に従いアクセス権および／またはデータアクセス権限を削除するプロセスを示すフローチャートである。 アクセス権および／またはアクセス権限が削除されたか、あるいは期限切れになった場合にアクセスを要求するプロセスを示すフローチャートである。 本発明の種々の実施形態の例示に有用である、認証ルール構造と暗号鍵アクセス許諾方針の構成を示す概略図である。 本発明の種々の実施形態の例示に有用である、認証ルール構造と暗号鍵アクセス許諾方針の構成を示す概略図である。 方針に従い被保護情報へのアクセスを制御する代替的な方法を示すデータベース構造のブロック図である。 パスワードを用いた認証プロセスを示すフローチャートである。 多数のホスト証明書連鎖を示す図である。 多数のデバイス証明書連鎖を示す図である。 一方向および相互認証方式のプロセスを示すプロトコル図である。 一方向および相互認証方式のプロセスを示すプロトコル図である。 本発明の一実施形態を例示するのに有用である、証明書連鎖の図である。 本発明の別の実施形態を例示するための、メモリ装置へ最終証明書を送信する場合のホストによって送信される証明書バッファに先行する制御セクタ内の情報を示す表であって、この証明書が証明書連鎖における最終証明書であることを伝える標示を示す。 メモリカードがホスト装置を認証する認証方式でカードとホストのプロセスをそれぞれ示すフローチャートである。 メモリカードがホスト装置を認証する認証方式でカードとホストのプロセスをそれぞれ示すフローチャートである。 ホスト装置がメモリカードを認証する認証方式でカードとホストのプロセスをそれぞれ示すフローチャートである。 ホスト装置がメモリカードを認証する認証方式でカードとホストのプロセスをそれぞれ示すフローチャートである。 本発明の別の実施形態を例示するための、メモリ装置に記憶された証明書失効リストがホスト装置によって検索される場合にホスト装置とメモリ装置とによってそれぞれ実行されるプロセスを示すフローチャートである。 本発明の別の実施形態を例示するための、メモリ装置に記憶された証明書失効リストがホスト装置によって検索される場合にホスト装置とメモリ装置とによってそれぞれ実行されるプロセスを示すフローチャートである。 本発明のさらに別の実施形態を示すための、証明書失効リスト内のフィールドを示す証明書失効リストの図である。 証明書失効リストを使って証明書をベリファイするカードとホストのプロセスをそれぞれ示すフローチャートである。 証明書失効リストを使って証明書をベリファイするカードとホストのプロセスをそれぞれ示すフローチャートである。 カードがホストへ送信されるデータに署名し、かつホストからのデータを復号化するカードプロセスを示すフローチャートである。 カードがホストへ送信されるデータに署名する場合のホストプロセスを示すフローチャートである。 ホストが暗号化データをメモリカードへ送信する場合のホストプロセスを示すフローチャートである。 一般情報および非公開情報クエリのプロセスをそれぞれ示すフローチャートである。 一般情報および非公開情報クエリのプロセスをそれぞれ示すフローチャートである。 本発明の一実施形態を例示するための、ホスト装置へ接続されたメモリ装置（フラッシュメモリカード等）におけるシステムアーキテクチャの機能ブロック図である。 図４０ＡのＳＳＭコアの内部ソフトウェアモジュールの機能ブロック図である。 使い捨てパスワードを生成するシステムのブロック図である。 使い捨てパスワード（ＯＴＰ）シード提供とＯＴＰ生成とを示す機能ブロック図である。 シード提供段階を示すプロトコル図である。 使い捨てパスワード生成段階を示すプロトコル図である。 ＤＲＭシステムを示す機能ブロック図である。 ライセンスオブジェクトの中で鍵が提供される場合のライセンス提供とコンテンツダウンロードのプロセスを示すプロトコル図である。 再生操作のプロセスを示すプロトコル図である。 ライセンスオブジェクトの中で鍵が提供されない場合のライセンス提供とコンテンツダウンロードのプロセスを示すプロトコル図である。

図面は、本発明の態様の様々な実施形態の特徴を示すものである。説明を簡潔にするた
め、本願では同じ構成要素を同じ数字で標示する。

図１のブロック図は、本発明の様々な態様を実装できる代表的なメモリシステムを示す
。図１に示すように、メモリシステム１０は、中央演算処理装置（ＣＰＵ）１２と、バッ
ファ管理部（ＢＭＵ）１４と、ホストインターフェイスモジュール（ＨＩＭ）１６と、フ
ラッシュインターフェイスモジュール（ＦＩＭ）１８と、フラッシュメモリ２０と、周辺
アクセスモジュール（ＰＡＭ）２２とを含む。メモリシステム１０は、ホストインターフ
ェイスバス２６とポート２６ａとを通じてホスト装置２４と通信する。フラッシュメモリ
２０はＮＡＮＤタイプのものであってもよく、ホスト装置２４のためのデータ記憶域を提
供し、ホスト装置２４はデジタルカメラ、パーソナルコンピュータ、個人用携帯情報端末
（ＰＤＡ）、ＭＰ３プレーヤ等のデジタルメディアプレーヤ、携帯電話機、セットトップ
ボックス、その他のデジタル装置または家電品であってもよい。ＣＰＵ１２のソフトウェ
アコードもフラッシュメモリ２０に記憶できる。ＦＩＭ１８は、フラッシュインターフェ
イスバス２８とポート２８ａとを通じてフラッシュメモリ２０へ接続する。ＨＩＭ１６は
ホスト装置への接続に適している。周辺装置アクセスモジュール２２はＣＰＵ１２との通
信においてＦＩＭ、ＨＩＭ、およびＢＭＵ等の適切なコントローラモジュールを選択する
。一実施形態において、点線の枠内にあるシステム１０の全構成要素をメモリカードまた
はスティック１０’等の単独装置で囲い込み、好ましくはこれに封入してもよい。メモリ
システム１０は脱着自在な状態でホスト装置２４へ接続されるため、多数の異なるホスト
装置からシステム１０の内容にアクセスできる。

以降の説明ではメモリシステム１０をメモリ装置１０と呼ぶ場合があり、あるいは単に
メモリ装置または装置と呼ぶ場合がある。ここではフラッシュメモリを参照しながら本発
明を例示するが、本発明は、磁気ディスク、光ＣＤ等のタイプの異なるメモリや他の書き
換え可能な不揮発性メモリシステムにも応用できる。

バッファ管理部１４は、ホストダイレクトメモリアクセス（ＨＤＭＡ）３２と、フラッ
シュダイレクトメモリアクセス（ＦＤＭＡ）３４と、アービタ３６と、バッファランダム
アクセスメモリ（ＢＲＡＭ）３８と、クリプトエンジン４０とを含む。アービタ３６は共
有バスアービタであるため、常に１つのみのマスタまたはイニシエータ（ＨＤＭＡ３２、
ＦＤＭＡ３４、またはＣＰＵ１２）が稼動し、そのスレーブまたはターゲットはＢＲＡＭ
３８である。アービタは、しかるべきイニシエータ要求をＢＲＡＭ３８へ振り向ける役割
を果たす。ＨＤＭＡ３２とＦＤＭＡ３４は、ＨＩＭ１６、ＦＩＭ１８、およびＢＲＡＭ３
８、またはＣＰＵランダムアクセスメモリ（ＣＰＵ ＲＡＭ）１２ａ間でデータの転送を
担当する。ＨＤＭＡ３２の動作とＦＤＭＡ３４の動作は従来どおりであり、ここで詳述す
る必要はない。ＢＲＡＭ３８は、ホスト装置２４とフラッシュメモリ２０との間で受け渡
しされるデータを記憶するために使用する。ＨＤＭＡ３２とＦＤＭＡ３４は、ＨＩＭ１６
／ＦＩＭ１８およびＢＲＡＭ３８またはＣＰＵ ＲＡＭ１２ａ間でデータを転送し、さら
にセクタの終了を指示する役割を果たす。

メモリシステム１０は、一実施形態において、暗号化および／または復号化に用いる鍵
値を生成し、この値は、好ましくはホスト装置２４等の外部装置にとって事実上アクセス
不能である。代替的に、システム１０の外部で、例えばライセンスサーバによって、鍵値
を生成し、システム１０へ送信することもできる。鍵値を生成する方法にかかわりなく、
いったんシステム１０に記憶された鍵値にアクセスできるものは認証済み実体のみとなる
。しかし、ホスト装置はメモリシステム１０におけるデータの読み書きをファイルの形で
行うため、暗号化と復号化は通常であればファイル単位で行われる。メモリ装置１０は、
タイプが異なる他の多数の記憶装置と同様に、ファイルを管理しない。メモリ２０は、フ
ァイルの論理アドレスを識別するファイルアロケーションテーブル（ＦＡＴ）を記憶する
が、このＦＡＴにアクセスし管理するのは通常であればホスト装置２４であって、コント
ローラ１２ではない。このため、ある特定のファイルのデータを暗号化する場合、コント
ローラ１２はメモリ２０におけるこのファイルのデータの論理アドレスをホスト装置に送
信してもらう必要があり、このため、システム１０はこのファイルのデータを見つけ、シ
ステム１０のみが使用できる鍵値を使ってデータを暗号化および／または復号化できる。

ファイルデータの暗号処理においてホスト装置２４とメモリシステム１０の双方が同じ
鍵を参照するための名前を用意するため、ホスト装置は、システム１０によって生成され
るか、あるいはシステム１０へ送信される各鍵値につき参照符を提供し、この参照符とは
要するに鍵ＩＤであってもよい。ホスト２４は、システム１０によって暗号処理される各
ファイルに鍵ＩＤを割り振り、システム１０は、データの暗号処理に用いる各鍵値にホス
トから提供される鍵ＩＤを割り振る。よって、ホストはデータの暗号処理を要求するとき
に、その要求を、鍵ＩＤと、メモリ２０から取り出すか、またはメモリ２０に記憶するデ
ータの論理アドレスと併せて、システム１０へ送信する。システム１０は鍵値を生成また
は受信し、ホスト２４から提供される鍵ＩＤをその値に割り振り、暗号処理を実行する。
メモリシステム１０の動作を変える必要はなく、メモリシステム１０は、鍵値に対する独
占的アクセス等、鍵を使った暗号処理を完全に制御できる。換言すると、いったん鍵値が
システム１０に記憶されるか、あるいはシステム１０によって生成されたら、システムは
、ＦＡＴの独占的制御によるファイルの管理をホスト２４に任せつつ、暗号処理に用いる
鍵値の管理を一手に引き受ける。鍵値がメモリシステム１０に記憶された後、ホスト装置
２４はデータの暗号処理に用いる鍵値の管理に関与しない。

ホスト２４から提供される鍵ＩＤとメモリシステムへ送信されるか、あるいはメモリシ
ステムによって生成される鍵値は、一実施形態において、これ以降「コンテンツ暗号化鍵
」もしくはＣＥＫと呼ぶ数量の２つの属性を形成する。ホスト２４は１つ以上のファイル
に鍵ＩＤを割り振ってもよく、組織化されていないデータあるいは完全なファイルの形に
組織化されたデータばかりでなく何らかのやり方で組織化されたデータに鍵ＩＤを割り振
る場合がある。

システム１０で保護されたコンテンツや領域にユーザまたはアプリケーションがアクセ
スするには、システム１０に予め登録された信用証明を使って認証を受ける必要がある。
信用証明はアクセス権に関連付けられ、この信用証明によって特定のユーザまたはアプリ
ケーションにアクセス権が付与される。このような事前登録ではユーザまたはアプリケー
ションのアイデンティティおよび信用証明の記録をシステム１０に記憶し、ユーザまたは
アプリケーションによって判定されたそのようなアイデンティティおよび信用証明に応じ
てアクセス権が割り振られ、ホスト２４を通じて提供される。事前登録が完了した後、メ
モリ２０へのデータ書き込みを要求するユーザまたはアプリケーションは、自身のアイデ
ンティティおよび信用証明と、データを暗号化するための鍵ＩＤと、暗号化されたデータ
を記憶するところの論理アドレスとを、ホスト装置を通じて提供する必要がある。システ
ム１０は鍵値を生成または受信し、ホスト装置から提供される鍵ＩＤをこの値に割り振り
、書き込みデータの暗号化に用いる鍵値の鍵ＩＤをこのユーザまたはアプリケーションの
記録またはテーブルに記憶する。そして、システム１０はデータを暗号化し、ホストによ
って指定されたアドレスに暗号化されたデータを記憶するほか、生成または受信した鍵値
を記憶する。

メモリ２０から暗号化データを読み出すことを要求するユーザまたはアプリケーション
は、自身のアイデンティティおよび信用証明と、要求するデータの暗号化に使われた鍵の
鍵ＩＤと、暗号化データが記憶されているところの論理アドレスとを提供する必要がある
。システム１０は、ホストから提供されたユーザまたはアプリケーションのアイデンティ
ティおよび信用証明を自身の記録に記憶されたものに突き合せる。システム１０は、それ
らが一致する場合、ユーザまたはアプリケーションから提供された鍵ＩＤと関連付けられ
た鍵値を自身のメモリから取り出し、ホスト装置が指定するアドレスに記憶されたデータ
を鍵値を用いて復号化し、復号化したデータをユーザまたはアプリケーションへ送信する
。

認証のための信用証明を暗号処理に用いる鍵の管理から分離することにより、異なる信
用証明で共通のデータアクセス権を有することが可能となる。つまり、信用証明がそれぞ
れ異なる１グループのユーザまたはアプリケーションは同じ鍵にアクセスして同じデータ
にアクセスできても、このグループ以外のユーザはアクセスできない。１グループ内のす
べてのユーザまたはアプリケーションが同じデータにアクセスする場合でも、それらのユ
ーザまたはアプリケーションの権利が依然として異なる場合がある。読み出し限定のアク
セス権を有するものもあれば、書き込みアクセス権のみを有するものもあれば、両方を有
するものもある。ユーザまたはアプリケーションのアイデンティティおよび信用証明と、
アクセスできる鍵ＩＤと、各々の鍵ＩＤに関連するアクセス権との記録を維持するシステ
ム１０では、正式に認証されたホスト装置の管理下で鍵ＩＤを追加または削除したり、特
定のユーザまたはアプリケーションの鍵ＩＤと関連付けられたアクセス権を変更したり、
あるユーザまたはアプリケーションから別のユーザまたはアプリケーションにアクセス権
を委譲できるほか、ユーザまたはアプリケーションの記録またはテーブルを削除または追
加することもできる。記憶された記録では、特定の鍵へのアクセスにおいてセキュアチャ
ネルを特定することができる。認証は、対称または非対称アルゴリズムとパスワードを使
って果たすことができる。

とりわけ重要なこととして、メモリシステム１０の中で保護されたコンテンツは移動で
きる。鍵値へのアクセスがメモリシステムによって制御される実施形態において、メモリ
システムまたはこのシステムを内蔵する記憶装置がある１つの外部システムから別の外部
システムへ移される場合、そこに記憶されたコンテンツの安全は保たれる。鍵がメモリシ
ステムによって生成されようが、メモリシステムの外から届くものであろうが、外部シス
テムは、メモリシステムによって完全に統制されたやり方で認証されない限り、システム
１０のコンテンツにアクセスできない。そのとおりに認証された後でもアクセスはメモリ
システムによって全面的に制御され、外部システムによるアクセスのあり方は、メモリシ
ステムに予め設定された記録に従って制御される。このような記録に準拠しない要求は拒
否される。

コンテンツ保護の柔軟性を高めるため、これ以降パーティションと呼ぶメモリの特定領
域が想定され、このパーティションには正式に認証されたユーザまたはアプリケーション
のみがアクセスできる。これを前述した鍵方式のデータ暗号化機能と組み合わせることに
より、システム１０のデータ保護能力は向上する。図２に示すように、フラッシュメモリ
２０の記憶容量は、多数のパーティション、すなわちユーザ領域またはパーティションと
カスタムパーティションに分割できる。ユーザ領域またはパーティションＰ０には、すべ
てのユーザまたはアプリケーションが認証なしでアクセスできる。ユーザ領域に記憶され
たデータのビット値のすべてがいずれのアプリケーションまたはユーザでも読み書きでき
るが、読み出しデータが暗号化されている場合、復号化の権限を有していないユーザまた
はアプリケーションは、ユーザ領域に記憶されたビット値表現の情報にアクセスできない
。例えば、ユーザ領域Ｐ０に記憶されたファイル１０２および１０４がこれにあたる。１
０６等のユーザ領域には暗号化されていないファイルも記憶され、すべてのアプリケーシ
ョンおよびユーザがこれを読み出し、解釈できる。ファイル１０２および１０４等の暗号
化されたファイルは錠前の記号を関連付けて表示されている。

権限のないアプリケーションまたはユーザはユーザ領域Ｐ０で暗号化されたファイルを
解釈できないが、そのようなアプリケーションまたはユーザであってもファイルを削除し
たり破壊したりすることは可能であり、用途によっては好ましくない場合がある。このた
め、メモリ２０には、パーティションＰ１およびＰ２等の事前の認証なくしてアクセスで
きない被保護カスタムパーティションもある。この用途の実施形態に使える認証プロセス
をこれより説明する。

同じく図２に示されているように、メモリ２０のファイルには様々なユーザまたはアプ
リケーションがアクセスする。そこで図２には、ユーザ１および２とアプリケーション１
〜４（装置上で実行）が示されている。これらの実体は、これより説明する認証プロセス
によって認証された後にメモリ２０の被保護コンテンツへのアクセスが認められる。この
プロセスでは、アクセスを要求する実体をロール方式のアクセス制御のためにホスト側で
識別する必要がある。そこでアクセスを要求する実体はまず、「私はアプリケーション２
であってファイル１を読み出したい」等の情報を供給することによって自身を識別する。
コントローラ１２はそのアイデンティティと、認証情報と、要求とを、メモリ２０または
コントローラ１２に記憶された記録に突き合せる。すべての要件が満たされる場合、その
ような実体にアクセスが認められる。図２に示すように、ユーザ１はパーティションＰ１
のファイル１０１を読み書きでき、Ｐ０ではファイル１０６に対する無制限の読み出し・
書き込み権利を有しているが、これ以外に読み出し可能なファイルはファイル１０２およ
び１０４のみである。他方、ユーザ２は、ファイル１０１および１０４へのアクセスを許
可されないが、ファイル１０２に対する読み出し・書き込みアクセス権は有している。図
２に示すように、ユーザ１および２のログインアルゴリズム（ＡＥＳ）は同じであるが、
アプリケーション１および３のログインアルゴリズムはそれぞれ異なり（例えば、ＲＳＡ
と００１００１）、ユーザ１および２のものとも異なる。

セキュアストレージアプリケーション（ＳＳＡ）は本発明の一実施形態を例示するメモ
リシステム１０のセキュリティアプリケーションであり、前述した機能の多くはこれを用
いて実行できる。ＳＳＡはソフトウェアまたはコンピュータコードとして実装でき、メモ
リ２０またはＣＰＵ１２の不揮発性メモリ（図示せず）に記憶されたデータベースがＲＡ
Ｍ１２ａに読み込まれ、ＣＰＵ１２によって実行される。次の表には、ＳＳＡに言及する
場合に用いる頭字語が記されている。

ＳＳＡシステムの説明
ＳＳＡの主な役割はデータの保護と保全とアクセス制御である。データとは、いくつか
の大容量記憶装置に一目瞭然な状態で記憶される場合があるファイルである。ＳＳＡシス
テムは記憶システムの上部に位置し、記憶されたホストファイルのためのセキュリティ層
を加え、後述するセキュリティデータ構造を通じてセキュリティ機能を提供する。

ＳＳＡの主な仕事は、メモリに記憶された（保護された）コンテンツに関わる様々な権
利を管理することである。メモリアプリケーションは、複数の記憶コンテンツに対する複
数のユーザおよびコンテンツ権利を管理する必要がある。ホストアプリケーションは提示
されたドライブとパーティションをホスト側から看取するほか、記憶装置に記憶されたフ
ァイルの位置を管理し表現するファイルアロケーションテーブル（ＦＡＴ）を看取する。

この場合の記憶装置はパーティションに分割されたＮＡＮＤフラッシュチップを使用す
るが、他の可搬型記憶装置も使用でき、本発明の範囲内にある。これらのパーティション
は一連の論理アドレスであり、その境界は開始アドレスと終端アドレスで区切られる。し
たがって、所望により、非表示のパーティションへのアクセスに制限を設けることができ
、それにはソフトウェア（メモリ２０に記憶されたソフトウェア等）によってそのような
境界内のアドレスにそのような制限を関連付ける。ＳＳＡは、自身が管理する論理アドレ
スの境界によってパーティションを完全に認識する。ＳＳＡシステムはパーティションを
用いて権限を有していないホストアプリケーションからデータを物理的に保護する。ホス
トにとってのパーティションは、データファイルが記憶されるところの専有空間を規定す
るメカニズムである。これらのパーティションを公開する場合、記憶装置にアクセスでき
る者であれば誰でも装置におけるこれらのパーティションの存在を看取して認識し、パー
ティションを非公開にする場合もしくは非表示にする場合、選ばれたホストアプリケーシ
ョンのみがこれらのパーティションにアクセスでき、記憶装置におけるこれらの存在をも
認識できる。

図３はメモリのパーティションＰ０、Ｐ１、Ｐ２、およびＰ３を示すメモリの概略図で
あり（言うまでもなく５つ以上のパーティションが使われることも、あるいは３つ以下の
パーティションが使われることもある）、Ｐ０はいずれの実体でも認証なしでアクセスで
きる公開パーティションである。

非公開パーティション（Ｐ１、Ｐ２、またはＰ３等）の中にあるファイルへのアクセス
は非表示にされる。ホストによるパーティションへのアクセスを阻止することにより、フ
ラッシュ装置（例えば、フラッシュカード）はパーティションの中でデータファイルの保
護を達成する。しかし、この種の保護は、非表示パーティションの中で論理アドレスに記
憶されたデータへのアクセスに制限を設けることによって、非表示パーティションの中に
あるすべてのファイルを囲い込むものである。換言すると、一連の論理アドレスに制限を
関連付けるものである。そのパーティションへアクセスできるユーザ／ホストはいずれも
、内部にあるすべてのファイルに無制限にアクセスできる。ファイル（またはファイル群
）を互いに分離するため、ＳＳＡシステムは鍵と鍵の参照符すなわち鍵ＩＤとを用いて別
の保護・保全レベルをファイル（またはファイル群）単位で提供する。様々なメモリアド
レスでデータを暗号化するのに用いられる鍵値の鍵参照符すなわち鍵ＩＤは、暗号化デー
タを収容する容器または領域にたとえることができる。このため、図４では、鍵ＩＤと関
連付けられた鍵値を用いて暗号化されたファイルを取り囲む領域として鍵参照符すなわち
鍵ＩＤ（例えば、「鍵１」および「鍵２」）が示されている。

図４を参照し、例えばファイルＡは鍵ＩＤで囲まれていないため、いずれの実体でも認
証なしでファイルＡにアクセスできる。公開パーティションの中にあるファイルＢはいず
れの実体でも読み出しや上書きを行えるが、その中のデータはＩＤ「鍵１」を有する鍵で
暗号化されているため、このような鍵にアクセスできるこのような実体でない限り、ファ
イルＢの中にある情報にはアクセスできない。このような鍵値と鍵参照符すなわち鍵ＩＤ
の使用は、前述したパーティションによる保護とは異なり、論理的な保護のみを提供する
。つまり、パーティション（公開または非公開）にアクセスできるホストであればいずれ
でもそのパーティションの中で暗号化データを含むデータを読み書きできる。しかし、デ
ータは暗号化されているため、権限を有していないユーザはデータを壊すことしかできな
い。権限を有していないユーザは、好ましくは発覚することなくこのデータを変更できな
い。暗号化および／または復号化鍵へのアクセスを制限することにより、権限を有する実
体のみにデータの使用を認めることができる。Ｐ０ではファイルＢおよびＣも鍵ＩＤ「鍵
２」を有する鍵を使って暗号化されている。

データの機密保護と保全は、コンテンツ暗号化鍵（ＣＥＫ）をＣＥＫ当たり１つずつ使
用する対称暗号化法で提供できる。ＳＳＡの実施形態では、ＣＥＫの鍵値がフラッシュ装
置（例えば、フラッシュカード）によって生成または受信され、内部でのみ使用され、外
部に対して秘密に保たれる。暗号化されるデータでハッシュ計算を行うか、あるいは暗号
を連鎖ブロック化することによってデータ保全を徹底することもできる。

パーティション内のすべてのデータが異なる鍵によって暗号化され、異なる鍵ＩＤが割
り振られるわけではない。公開またはユーザファイルの中またはオペレーティングシステ
ム領域（すなわち、ＦＡＴ）の中で、論理アドレスに鍵または鍵参照符が割り振られない
場合があり、この場合、パーティション自体にアクセスできる実体であればいずれでもこ
れにアクセスできる。

鍵やパーティションの作成や、パーティションにおけるデータの読み書きや、鍵の使用
を望む実体は、アクセス制御記録（ＡＣＲ）を通じてＳＳＡシステムにログインする必要
がある。ＳＳＡシステムにおけるＡＣＲの特権はアクションと呼ばれる。どのＡＣＲでも
３種類のアクション、すなわちパーティションおよび鍵／鍵ＩＤの作成と、パーティショ
ンおよび鍵へのアクセスと、他のＡＣＲの作成／更新とを実行する権限を有することがで
きる。

ＡＣＲは、ＡＣＲグループすなわちＡＧＰと呼ばれるグループに整理する。ＡＣＲの認
証に成功するとＳＳＡシステムがセッションを開放し、このセッションの中でＡＣＲのア
クションを実行できる。ＡＣＲとＡＧＰは、方針に従ってパーティションや鍵へのアクセ
スを制御するためのセキュリティデータ構造である。

ユーザパーティション
ＳＳＡシステムは、ユーザパーティションとも呼ばれる１つ以上の公開パーティション
を管理する。このパーティションは記憶装置上に存在し、記憶装置の標準的な読み出し・
書き込みコマンドを通じてアクセスできるパーティションである。このパーティションの
サイズと装置上でのこのパーティションの存在に関する情報は、好ましくはホストに対し
て非表示にしない。

ＳＳＡシステムでは、標準的な読み出し・書き込みコマンドまたはＳＳＡコマンドを通
じてこのパーティションにアクセスできる。このパーティションへのアクセスは、好まし
くは特定のＡＣＲに制限しない。しかし、ＳＳＡシステムの場合、ホスト装置はユーザパ
ーティションへのアクセスを制限できる。読み出し・書き込みアクセスは個別に有効／無
効にできる。４通りの組み合わせすべて（例えば、書き込み限定、読み出し限定（書き込
み保護）、読み出しおよび書き込み、アクセス不能）が可能である。

ＳＳＡシステムでは、ＡＣＲを使ってユーザパーティションの中にあるファイルに鍵Ｉ
Ｄを割り振り、そのような鍵ＩＤと関連付けられた鍵を使って個々のファイルを暗号化で
きる。ユーザパーティションの中にある暗号化ファイルへのアクセスとパーティションへ
のアクセス権設定は、ＳＳＡコマンドセットを使って行う。前述した機能はファイルの形
に組織されていないデータにも当てはまる。

ＳＳＡパーティション
これは、ＳＳＡコマンドでないとアクセスできない非表示（認証されていない者に対し
て非表示にされた）パーティションである。ＳＳＡシステムは好ましくは、ＡＣＲへのロ
グインによって確立するセッション（後述）の中でアクセスが行われる場合を除き、ホス
ト装置によるＳＳＡパーティションへのアクセスを許可しない。同様に、ＳＳＡは好まし
くは、ＳＳＡパーティションの存在と、サイズと、アクセス権限とに関する情報を、その
要求が確立されたセッションの中で発生する場合を除き、提供しない。

パーティションに対するアクセス権はＡＣＲ権限から検索される。ＳＳＡシステムにロ
グインしたＡＣＲは他のＡＣＲとパーティションを共用できる（後述）。パーティション
が作成されると、ホストはそのパーティションに参照名またはＩＤ（例えば、図３および
４におけるＰ０〜Ｐ３）を与える。この参照名は、このパーティションに対する以降の読
み出し・書き込みコマンドで使われる。

記憶装置の分割
好ましくは、装置の使用可能な記憶容量のすべてをユーザパーティションとその時点で
構成済みのＳＳＡパーティションとに割り当てる。このため、再分割において既存のパー
ティションの再構成をともなうことがある。装置容量（全パーティションの合計サイズ）
の正味の変化はゼロである。装置メモリ空間におけるパーティションのＩＤはホストシス
テムによって設定される。

ホストシステムは、既存パーティションのいずれか１つを２つのより小さいパーティシ
ョンに再分割したり、２つの既存パーティション（隣接する場合とそうでない場合とがあ
る）を１つに併合したりすることができる。分割されたパーティションや併合されたパー
ティションの中のデータは、ホストの判断で消去するか、あるいは現状のまま残すことが
できる。

記憶装置の再分割によってデータが（記憶装置の論理アドレス空間の中での消去や移動
により）失われるおそれがあるため、ＳＳＡシステムは再分割において厳重な制限を課す
。つまり、ルートＡＧＰ（後述）の中にあるＡＣＲにのみ再分割コマンドの発行が許され
、これが参照できるパーティションは自身が所有するパーティションのみである。パーテ
ィションの中でデータがどのように構成されているかはＳＳＡシステムには分からないか
ら（ＦＡＴまたはその他のファイルシステム構造）、装置の再分割において構成を組み直
す責任はホストにある。

ユーザパーティションの再分割によって、ホストＯＳから見たこのパーティションのサ
イズやその他の属性は変化する。

再分割の後、ホストシステムにはＳＳＡシステムで存在しないパーティションをＡＣＲ
が参照していないことを確認する責任がある。これらのＡＣＲが適切に削除または更新さ
れないと、不在パーティションに対してこれらのＡＣＲに代わって行われるアクセスの試
みはシステムによって検出され、拒否される。削除される鍵や鍵ＩＤについても同様の配
慮がなされる。

鍵、鍵ＩＤ、論理的保護
ある特定の非表示パーティションに書き込まれたファイルは公から非表示にされる。し
かし、いったん実体（敵対的な実体、またはそうでない実体）が情報を得てこのパーティ
ションにアクセスすると、そのファイルは使用可能となり一目瞭然となる。そのファイル
のさらなる安全確保のため、ＳＳＡは非表示パーティションでファイルを暗号化でき、こ
のファイルの復号化に用いる鍵にアクセスするための信用証明は、好ましくはパーティシ
ョンにアクセスするためのものとは異なるものにする。ファイルはホストによって全面的
に制御され、管理されるため、ファイルにＣＥＫを割り振ることには問題がある。これを
解決するには、ＳＳＡが了解する何か、すなわち鍵ＩＤにファイルを関連付ける。つまり
ＳＳＡによって鍵が作成されたら、ホストはその鍵を使って暗号化されるデータに鍵ＩＤ
を割り振る。鍵が鍵ＩＤと併せてＳＳＡに送られる場合、鍵と鍵ＩＤを互いに関連付ける
ことは容易い。

鍵値と鍵ＩＤは論理的セキュリティを提供する。特定の鍵ＩＤが割り振られたデータは
いずれも、その場所にかかわりなく、コンテンツ暗号化鍵（ＣＥＫ）の同じ鍵値で暗号化
され、ホストアプリケーションからは一意な参照名すなわち鍵ＩＤが提供される。（ＡＣ
Ｒ認証により）非表示パーティションにアクセスし、そのパーティション内にある暗号化
ファイルの読み出しまたは書き込みを望む実体は、そのファイルに割り振られた鍵ＩＤに
アクセスする必要がある。この鍵ＩＤの鍵に対するアクセスを許諾する場合、ＳＳＡはこ
の鍵ＩＤと関連付けられたＣＥＫに鍵値をロードし、データを復号化してからホストへ送
信するか、あるいはデータを暗号化してからフラッシュメモリ２０に書き込む。一実施形
態において、鍵ＩＤと関連付けられたＣＥＫの鍵値がＳＳＡシステムによって無作為に作
成され、ＳＳＡシステムによって維持される。ＳＳＡシステムの外でＣＥＫの鍵値を知る
か、あるいはアクセスする者はいない。外部から提供され外部で使用するのは参照符すな
わち鍵ＩＤのみであり、ＣＥＫの鍵値ではない。鍵値はＳＳＡによって全面的に制御され
、好ましくはＳＳＡのみがこれにアクセスできる。代替的に、ＳＳＡシステムに鍵を提供
することもできる。

ＳＳＡシステムは、次の暗号モードのいずれか１つ（ユーザにより設定）を用いて鍵Ｉ
Ｄと関連付けられたデータを保護する（実際に使われる暗号アルゴリズムとＣＥＫにおけ
る鍵値はシステムの管理下にあって、外部には明かされない）。
ブロックモード：データをブロックに分割し、それぞれのブロックを個別に暗号化する
。このモードは一般的に安全性が低いとされ、辞書攻撃を被りやすいが、ユーザはデータ
ブロックのいずれか１つにランダムにアクセスできる。
・連鎖モード：データをブロックに分割し、暗号化の過程で鎖状に繋ぎ合わせる。ブロ
ックはいずれも、次のブロックの暗号化プロセスへの入力として使われる。安全性は高い
とされているが、データの読み書きが最初から最後まで順次に行われるため、ユーザにと
って容認しがたいオーバーヘッドが発生することがある。
・ハッシュモード：連鎖モードに、データ保全性ベリファイに用いるデータダイジェス
トの作成を加えたもの。

ＡＣＲとアクセス制御
ＳＳＡは多数のアプリケーションを取り扱うように設計され、システムデータベースの
中では、ノードからなるツリーとしてそれぞれのアプリケーションを表現する。ツリーの
ブランチ間のクロストークをなくすことによりアプリケーション間の相互排除を達成する
。

ＳＳＡシステムにアクセスする場合、実体はシステムのいずれか１つのＡＣＲを通じて
接続を確立する必要がある。ＳＳＡシステムは、接続する場合、ユーザが選ぶＡＣＲの規
定に従ってログイン手続きを運営する。

ＡＣＲはＳＳＡシステムに至る個々のログイン地点である。ＡＣＲはログイン信用証明
と認証方法を保持する。読み出し特権や書き込み特権を含むＳＳＡシステムの中でのログ
イン権限もこの記録の中にある。これを示す図５には、同じＡＧＰの中にｎ個のＡＣＲが
ある。これは、ｎ個のＡＣＲのうちの少なくとも種々のＡＣＲが同じ鍵へのアクセス権を
共有することを意味する。つまり、ＡＣＲ＃１とＡＣＲ＃ｎは鍵ＩＤ「鍵３」を有する鍵
へのアクセス権を共有し、ここでＡＣＲ＃１とＡＣＲ＃ｎはＡＣＲ ＩＤであって、「鍵
３」は鍵の鍵ＩＤであって、この鍵を用いて「鍵３」に関連するデータが暗号化される。
複数ファイルまたは複数データ群の暗号化および／または復号化に同じ鍵を使うこともで
きる。

ＳＳＡシステムは数通りのシステムログインをサポートし、認証アルゴリズムとユーザ
信用証明は様々であってもよく、ログインに成功したユーザのシステムにおける特権も様
々であってもよい。図５には様々なパスワードログインアルゴリズムと信用証明とが例示
されている。ＡＣＲ＃１ではパスワードログインアルゴリズムとパスワードとが、信用証
明として指定され、ＡＣＲ＃２ではＰＫＩ（公開鍵基盤）ログインアルゴリズムと公開鍵
が信用証明として指定されている。したがって、実体はログインにおいて有効なＡＣＲＩ
Ｄを提示するほか、適切なログインアルゴリズムと信用証明とを提示する必要がある。

ＳＳＡシステムのＡＣＲにログインした実体の権限、すなわちＳＳＡコマンドを使用す
る権利は、ＡＣＲと関連付けられた権限制御記録（ＰＣＲ）の中で設定する。図５のＰＣ
Ｒに示すように、ＡＣＲ＃１は「鍵３」と関連付けられたデータに対して読み出し限定権
限を許諾し、ＡＣＲ＃２は「鍵５」と関連付けられたデータの読み出し権限と書き込み権
限とを許諾する。

読み出しや書き込みに使う鍵等の異なるＡＣＲがシステムで共通の利権・特権を有する
ことがある。このため、共通する部分があるＡＣＲはＡＧＰ、すなわちＡＣＲグループに
グループ分けする。ＡＣＲ＃１とＡＣＲ＃ｎはいずれも、鍵ＩＤ「鍵３」を有する鍵への
アクセス権がある。

ＡＧＰとその中にあるＡＣＲは階層状のツリーの中で編制されるため、ＡＣＲは重要デ
ータの安全性を保つ安全鍵を作成できるほか、好ましくは自身の鍵ＩＤ／パーティション
に対応する他のＡＣＲ項目を作成できる。これらの子ＡＣＲは、その父、すなわち作成元
と同じ権限を有するかそれよりも少ない権限を有することになり、父ＡＣＲ自身が作成し
た鍵の権限が付与される場合がある。言うまでもなく、子ＡＣＲは自身が作成する任意の
鍵に対するアクセス権限を取得する。これは図６に例示されている。ＡＧＰ１２０の中に
あるＡＣＲはいずれもＡＣＲ１２２によって作成されたものであり、これらのＡＣＲのう
ちの２つは、「鍵３」と関連付けられたデータへのアクセス権限をＡＣＲ１２２から継承
している。

ＡＧＰ
ＳＳＡシステムへのログインにおいて、ＡＧＰとそのＡＧＰの中にあるＡＣＲを指定す
る。
ＡＧＰはいずれも一意なＩＤ（参照名）を有し、ＳＳＡデータベースにおける該当する
項目への索引として使われる。ＡＧＰ名はＡＧＰの作成時にＳＳＡシステムに支給される
。ＳＳＡは、支給されるＡＧＰ名がシステムに既に存在する場合に作成動作を拒否する。

以降のセクションで説明するように、アクセス権限や管理権限の委譲に関わる制限事項
はＡＧＰを使って管理運営する。完全に独立した実体、例えば２つの異なるアプリケーシ
ョンまたは２つの異なるコンピュータユーザによるアクセスの制御運営は、図６の２つの
ツリーが果たす役割の１つである。ここで大切なり得ることは、２つのアクセスプロセス
が、たとえ同時に発生する場合でも、事実上互いに独立する（すなわち、事実上クロスト
ークをなくす）ことである。これは、それぞれのツリーにおけるＡＣＲとＡＧＰの認証、
権限、追加作成等が他のツリーにおけるものと無関係であり、かつ他のツリーにおけるも
のに左右されないことを意味する。このため、ＳＳＡシステムを使用するメモリシステム
１０では、複数のアプリケーションを同時に処理できる。また、２つのアプリケーション
が互いに自立的に２つの別々のデータ群（例えば、１組の写真と１組の歌）にアクセスす
ることも可能になる。これは図６に例示されている。図６の上部で、ツリーの中にあるノ
ード（ＡＣＲ）を通じてアクセスするアプリケーションまたはユーザにとって、「鍵３」
、「鍵Ｘ」、および「鍵Ｚ」と関連付けられたデータは写真であってもよい。図６の下部
で、ツリーのノード（ＡＣＲ）を通じてアクセスするアプリケーションまたはユーザにと
って、「鍵５」および「鍵Ｙ」と関連付けられたデータは歌であってもよい。ＡＧＰを作
成したＡＣＲは、このＡＧＰにＡＣＲ項目がなく空になっている場合に限りこのＡＧＰを
削除できる。

実体にとってのＳＳＡの入口：アクセス制御記録（ＡＣＲ）
ＳＳＡシステムのＡＣＲは、実体によるシステムログインのあり方を記述するものであ
る。ＳＳＡシステムにログインする実体は、これから始まる認証プロセスに該当するＡＣ
Ｒを指定する必要がある。図５に示すように、ＡＣＲの中にある権限制御記録（ＰＣＲ）
は、ＡＣＲの認証を終えたユーザが実行できる許諾アクションを明らかにするものである
。ホスト側実体はすべてのＡＣＲデータフィールドを提供する。

ＡＣＲへのログインに成功した実体は、そのＡＣＲのパーティション・鍵アクセス権限
やＡＣＡＭ権限（後述）を照会できる。
ＡＣＲ ＩＤ
ＳＳＡシステムの実体はログインプロセスを開始するときに、そのログイン方法に該当
するＡＣＲＩＤを指定する必要がある（ＡＣＲが作成される場合にホストより支給される
）ので、ＳＳＡは正しいアルゴリズムを準備し、すべてのログイン条件が満たされたら正
しいＰＣＲを選択する。ＡＣＲＩＤはＡＣＲの作成時にＳＳＡシステムに提供される。

ログイン／認証アルゴリズム
実体によって使われるログイン手続きと、ユーザのアイデンティティを証明する場合に
必要となる信用証明は、認証アルゴリズムによって決まる。手続きなし（信用証明なし）
からパスワードに基づく手続き、対称暗号法か非対称暗号法に基づく双方向認証プロトコ
ルまで、ＳＳＡシステムは数通りの標準的なログインアルゴリズムをサポートする。

信用証明
実体の信用証明はログインアルゴリズムに対応し、ＳＳＡがユーザをベリファイし認証
するのに使われる。パスワード認証のためのパスワード／ＰＩＮ番号やＡＥＳ認証のため
のＡＥＳ鍵等は信用証明の一例であり得る。信用証明のタイプ／書式（ＰＩＮ、対称鍵等
）は予め決まり、認証モードから検索され、ＡＣＲの作成時にＳＳＡシステムに提供され
る。ＳＳＡシステムはこれら信用証明の設定、配布、管理に関与しないが、例外としてＰ
ＫＩ方式の認証では装置（例えば、フラッシュカード）を使ってＲＳＡ等の鍵対を生成で
き、証明書生成のための公開鍵をエクスポートできる。

権限制御記録（ＰＣＲ）
ＰＣＲは、ＳＳＡシステムにログインしＡＣＲの認証プロセスに合格した後の実体に対
する許諾事項を明らかにするものである。権限には、パーティションおよび鍵の作成権限
と、パーティションおよび鍵へのアクセス権限と、実体−ＡＣＲ属性の管理権限の３種類
がある。

パーティションへのアクセス
ＰＣＲのこの部分には、ＡＣＲ段階を首尾よく完了した実体からアクセスできるパーテ
ィションのリストが入る（ＳＳＡシステムへ提供されるパーティションのＩＤを使用）。
パーティションごとに書き込み限定または読み出し限定にアクセスのタイプが制限される
場合があったり、あるいは完全書き込み／読み出しアクセス権が指定される場合もある。
図５のＡＣＲ＃１はパーティション＃２にアクセスできてもパーティション＃１にはアク
セスできない。ＰＣＲの中で指定される制限はＳＳＡパーティションと公開パーティショ
ンとに適用される。

公開パーティションには、ＳＳＡシステムをホストする装置（例えば、フラッシュカー
ド）に対する通常の読み出しおよび書き込みコマンドでアクセスするか、あるいはＳＳＡ
コマンドでアクセスする。公開パーティションを制限する権限を有するルートＡＣＲ（後
述）が作成されると、このルートＡＣＲはその権限を自身の子に渡すことができる。ＡＣ
Ｒは、好ましくは通常の読み出しおよび書き込みコマンドによる公開パーティションへの
アクセスのみを制限できる。ＳＳＡシステムのＡＣＲは、好ましくはこれが作成されると
きにのみ制限できる。公開パーティションに対する読み出し／書き込み権限をＡＣＲが得
た後、好ましくはその権限は剥奪できない。

鍵ＩＤアクセス
ＰＣＲのこの部分には、実体のログインプロセスによってＡＣＲ方針が満たされた場合
に該当する実体からアクセスできる、鍵ＩＤのリスト（ホストからＳＳＡシステムへの提
供）と関連付けられたデータが入る。ＰＣＲに記載されたパーティション内のファイルに
は指定された鍵ＩＤが割り振られる。デバイス（例えば、フラッシュカード）の論理アド
レスに鍵ＩＤは割り振られないため、ある特定のＡＣＲに対して２つ以上のパーティショ
ンがある場合、それらのパーティションのいずれかの中にはファイルがある。ＰＣＲの中
で指定された鍵ＩＤはそれぞれ異なる１組のアクセス権を有することができる。鍵ＩＤに
よって指示されるデータへのアクセスは、書き込み限定または読み出し限定に制限される
場合があったり、あるいは完全書き込み／読み出しアクセス権が指定される場合もある。

ＡＣＲ属性管理（ＡＣＡＭ）
このセクションではＡＣＲのシステム属性が変更できる場合について説明する。
ＳＳＡシステムで許可され得るＡＣＡＭアクションは次のとおりである。
１．ＡＧＰとＡＣＲの作成／削除／更新
２．パーティションと鍵の作成／削除
３．鍵およびパーティションに対するアクセス権の委譲
父ＡＣＲは、好ましくはＡＣＡＭ権限を編集できない。この場合、好ましくはＡＣＲの
削除と再作成が必要となる。また、ＡＣＲによって作成された鍵ＩＤに対するアクセス権
限は、好ましくは剥奪できない。

ＡＣＲには他のＡＣＲやＡＧＰを作成する容量があってもよい。ＡＣＲを作成するとい
うことは、作成元が所有するＡＣＡＭ権限の一部または全部が作成されたＡＣＲへ委譲さ
れることを意味する場合がある。ＡＣＲを作成する権限を有するということは、次のアク
ションの権限を有することを意味する。
１．子の信用証明を設定し編集する−作成元ＡＣＲによって一旦設定された認証方法は
、好ましくは編集できない。子向けに予め設定された認証アルゴリズムの範囲内で信用証
明を変更してもよい。
２．ＡＣＲを削除する。
３．作成権限を子ＡＣＲへ委譲する（よって孫ができる）。

他のＡＣＲを作成する権限を有するＡＣＲは、これが作成するＡＣＲに遮断解除権限を
委譲する権限を有する（しかし、ＡＣＲの遮断を解除する権限がない場合もある）。父Ａ
ＣＲは解除ＡＣＲの参照符を子ＡＣＲの中に入れる。

父ＡＣＲは、自身の子ＡＣＲを削除する権限を有する唯一のＡＣＲである。ＡＣＲが作
成した下位ＡＣＲを削除すると、この下位ＡＣＲから生まれたすべてのＡＣＲも自動的に
削除される。ＡＣＲを削除すると、そのＡＣＲによって作成された鍵ＩＤとパーティショ
ンはすべて削除される。
例外として、ＡＣＲが自身の記録を更新できる場合が２つある。
１．作成元ＡＣＲによって設定されたパスワード／ＰＩＮでも、それらを含むＡＣＲに
よってのみ更新できる。
２．ルートＡＣＲは自分自身と自身が所属するＡＧＰとを削除できる。

鍵・パーティションアクセス権の委譲
ＡＣＲとそのＡＧＰは階層状のツリーの中で構成され、ルートＡＧＰとその中にあるＡ
ＣＲはツリーの最上部に位置する（例えば、図６のルートＡＧＰ１３０および１３２）。
ＳＳＡシステムの中には数本のＡＧＰツリーが存在することがあるが、それらは互いに完
全に独立している。ＡＧＰの中にあるＡＣＲは、自身の鍵に対するアクセス権限を、同じ
ＡＧＰの中にある全ＡＣＲとそれらによって作成されるこの全ＡＣＲに委譲できる。鍵を
作成する権限は、好ましくはその鍵を使用するためのアクセス権限を委譲する権限を含む
。

鍵に対する権限は３種類に分かれる。
１．アクセス：鍵に対するアクセス権限、すなわち読み出しと書き込みとを設定する。
２．所有：当然ながら、鍵の所有者はその鍵を作成したＡＣＲである。この所有権は、
ある１つのＡＣＲから別のＡＣＲ（同じＡＧＰの中にあるか、あるいは子ＡＧＰの中にあ
るＡＣＲ）へ委譲できる。鍵の所有権は、鍵を削除する権限のほかに、鍵に対する権限を
委譲する権限を提供する。
３．アクセス権委譲：この権限により、ＡＣＲは自身が保持する権利を委譲できる。
ＡＣＲは、自身が作成したパーティションのほかに、自身が所有するアクセス権限の対
象となる他のパーティションに対するアクセス権限を委譲できる。
権限を委譲するには、パーティションの名前と鍵ＩＤを指定されたＡＣＲのＰＣＲに追
加する。鍵のアクセス権限を委譲するには、鍵ＩＤを使っても、あるいは委譲する側のＡ
ＣＲのすべての作成された鍵がアクセス権限の対象となってもよいことを表明する。

ＡＣＲの遮断と解除
システムによる実体のＡＣＲ認証プロセスが失敗すると、ＡＣＲの遮断カウンタが増加
する場合がある。一定の最大失敗認証数（ＭＡＸ）に達すると、ＳＳＡシステムによって
ＡＣＲは遮断されることになる。
遮断されたＡＣＲは、この遮断されたＡＣＲから参照する別のＡＣＲによって解除でき
る。この解除されたＡＣＲに対する参照は、その作成元にたるＡＣＲによって設定される
。解除されたＡＣＲは、好ましくは遮断されたＡＣＲの作成元と同じＡＧＰの中にあり、
「解除」権限を有する。
システムの中でこれ以外のＡＣＲは遮断されたＡＣＲを解除できない。遮断カウンタが
あるＡＣＲでも解除ＡＣＲがなければ、遮断された場合に解除できない。

ルートＡＧＰ−アプリケーションデータベースの作成
ＳＳＡシステムは複数のアプリケーションを処理し、各アプリケーションのデータを分
離するように設計されている。アプリケーションデータを識別し、かつ分離する場合には
ＡＧＰシステムのツリー構造がメインのツールとして用いられる。ルートＡＧＰはアプリ
ケーションＳＳＡデータベースツリーの先端に位置し、いくぶん異なる挙動ルールに準拠
する。ＳＳＡシステムでは数個のルートＡＧＰを構成できる。図６には２つのルートＡＧ
Ｐ１３０および１３２が示されている。当然、これよりも少ないＡＧＰやこれよりも多い
ＡＧＰが使われる場合があり、本発明の範囲内にある。
新規アプリケーションのための装置（例えば、フラッシュカード）の登録および／また
は装置の新規アプリケーションの信用証明発行は、装置に新たなＡＧＰ／ＡＣＲツリーを
追加する過程で行う。

ＳＳＡシステムはルートＡＧＰ（ならびにルートＡＧＰの全ＡＣＲとその権限）を作成
する場合に３通りのモードをサポートする。
１．オープンモード：いずれのユーザまたは実体でも認証なしで、あるいはシステムＡ
ＣＲ（後述）を通じて認証されたユーザ／実体が、新規ルートＡＧＰを作成できる。オー
プンモードによるルートＡＧＰの作成は、セキュリティ対策なしですべてのデータ転送が
オープンチャネル（発行機関のセキュア環境内）で行われる場合と、システムＡＣＲ認証
（Ｏｖｅｒ Ｔｈｅ Ａｉｒ（ＯＴＡ）と後発行手順）を通じて確立するセキュアチャネ
ルを通じて行われる場合とがある。
システムＡＣＲが構成されず（オプションとして）、ルートＡＧＰ作成モードをオープ
ンに設定する場合に選べるオプションはオープンチャネルのみである。
２．制御モード：システムＡＣＲを通じて認証された実体のみが新規ルートＡＧＰを作
成できる。システムＡＣＲが構成されなければ、ＳＳＡシステムをこのモードに設定する
ことはできない。
３．ロックモード：ルートＡＧＰの作成は無効になり、さらなるルートＡＧＰをシステ
ムに加えることはできない。

この機能は２つのＳＳＡコマンドで制御する（これらのコマンドはいずれのユーザ／実
体でも認証なしで使用できる）。
１．方法構成コマンド：３通りのルートＡＧＰ作成モードのいずれか１つを使用する形
にＳＳＡシステムを構成するために使用する。オプションから制御へ、制御からロックへ
のモード変更のみが可能である（つまり、ＳＳＡシステムが現在制御モードに構成されて
いる場合、ロックモードにしか変更できない）。
２．方法構成固定コマンド：方法構成コマンドを無効にし、現在選択されている方法で
永続的に固定するために使用する。

作成されたルートＡＧＰは特別な初期化モードに入り、ＡＣＲの作成、構成（ルートＡ
ＧＰの作成に適用されたものと同じアクセス制限を使用）が可能になる。ルートＡＧＰ構
成プロセスの最後に実体がこれを明示的に作動モードに切り替えると、既存のＡＣＲは更
新できなくなり、ＡＣＲを追加で作成できなくなる。

標準モードに入ったルートＡＧＰを削除するには、そのＡＣＲのうち、ルートＡＧＰの
削除する権限が付与されたＡＣＲを通じてシステムにログインしなければならない。特別
の初期化モードのほかに、これもルートＡＧＰの例外である。これは好ましくは、次のツ
リーレベルにあるＡＧＰではなく自身のＡＧＰを削除する権限を有するＡＣＲを含んでも
よい唯一のＡＧＰである。
ルートＡＣＲと標準ＡＣＲとの３番目にして最後の違いは、パーティションを作成し削
除する権限を有し得るシステム内で唯一のＡＣＲであるということである。

ＳＳＡシステムＡＣＲ
システムＡＣＲは次に記す２つのＳＳＡ操作に使用される。
１．不利な状況の中でセキュアチャネルの保護下でＡＣＲ／ＡＧＰツリーを作成する。
２．ＳＳＡシステムをホストする装置を識別し、認証する。
好ましくはＳＳＡの中でシステムＡＣＲは１つのみであってもよく、いったん設定され
たシステムＡＣＲは好ましくは変更できない。システムＡＣＲを作成するときにシステム
認証は必要なく、必要なものはＳＳＡコマンドのみである。システムＡＣＲ作成機能は無
効にできる（ルートＡＧＰ作成機能と同様）。好ましくは１つのみのシステムＡＣＲが認
められるため、システムＡＣＲ作成コマンドはシステムＡＣＲの作成後には作用しない。

システムＡＣＲはその作成プロセスでは機能しない。作成が完了したら、システムＡＣ
Ｒが作成され準備が整ったことを伝える専用のコマンドを発行する必要がある。好ましく
はこの時点でシステムＡＣＲの更新や差し替えは行えない。

システムＡＣＲはＳＳＡでルートＡＣＲ／ＡＧＰを作成する。システムＡＣＲは、ホス
トがルートレベルに満足し遮断するまでルートレベルを追加／変更する権限を有する。ル
ートＡＧＰを遮断すると、基本的にはシステムＡＣＲとのつながりは絶たれ、改竄不能と
なる。この時点でルートＡＧＰとその中にあるＡＣＲは誰も変更／編集できない。これは
ＳＳＡコマンドで果たす。ルートＡＧＰ作成を無効にする作用は永続し、元に戻すことは
できない。図７には、システムＡＣＲが関わる前述した機能が示されている。システムＡ
ＣＲを使って３通りのルートＡＧＰが作成されている。図７でシステムＡＣＲをルートＡ
ＧＰに結ぶ点線で示すように、これらのルートＡＧＰが作成された後のある時点で、シス
テムＡＣＲからルートＡＧＰを遮るＳＳＡコマンドがホストから送信され、ルートＡＧＰ
作成機能は無効になる。これで３つのルートＡＧＰは改竄不能となる。ルートＡＧＰが遮
断される前か後に、３つのルートＡＧＰを使って子ＡＧＰを作ることにより、３つの別々
のツリーが形成されている。

前述した機能は、コンテンツの所有者がコンテンツを使ってセキュア製品を構成する場
合に優れた柔軟性を提供する。セキュア製品は「発行」する必要がある。発行とは、装置
がホストを識別しホストが装置を識別するための識別鍵を出すプロセスである。ホストは
装置（例えば、フラッシュカード）を識別することにより、これの秘密を信用できるかど
うかを判断できる。一方、装置はホストを識別することにより、ホストが可能な範囲での
みセキュリティ方針を実施することができる（特定のホストコマンドを許諾し実行する）
。

複数のアプリケーションに対応するように設計された製品は、様々な識別鍵を有するこ
とになる。製品は「前発行」するか（出荷に先立つ製造中に鍵を記憶する）、あるいは「
後発行」する（出荷後に新たな鍵を追加する）。後発行の場合、ある種の親鍵または装置
レベル鍵をメモリ装置（例えば、メモリカード）に入れる必要があり、この鍵は、装置へ
のアプリケーションの追加が許される実体を識別するために使われる。

前述した機能により後発行を有効／無効にするように製品を構成できる。加えて、後発
行構成は出荷の後に安全に果たすことができる。装置は、前述した親鍵または装置レベル
鍵のほかには鍵のない状態で小売製品として購入され、新たな所有者により、さらなる後
発行アプリケーションを有効または無効にするように構成できる。

このようにシステムＡＣＲ機能は前述した目的を達成するための能力を提供する。
・システムＡＣＲがないメモリ装置の場合はアプリケーションを自由に無制限に追加で
きることになる。
・システムＡＣＲがないメモリ装置はシステムＡＣＲの作成を無効にするように構成で
き、これは新規アプリケーションの追加を制御できないことを意味する（新規ルートＡＧ
Ｐ作成機能も無効にする場合を除く）。
・システムＡＣＲがあるメモリ装置の場合はシステムＡＣＲ信用証明を使った認証手続
きで確立されるセキュアチャネル経由でアプリケーションを追加できる。
・システムＡＣＲがあるメモリ装置は、アプリケーションが追加される前か、あるいは
追加された後にアプリケーション追加機能を無効にするように構成できる。

鍵ＩＤリスト
鍵ＩＤは具体的なＡＣＲ要求に従って作成されるが、メモリシステム１０でこれを使用
するのはＳＳＡシステムのみである。鍵ＩＤの作成時に作成元ＡＣＲから提供されるか、
あるいは作成元ＡＣＲへ提供されるデータは次のとおりである。
１．鍵ＩＤ：このＩＤはホストを通じて実体から提供され、以降の読み出しアクセスや
書き込みアクセスで、鍵と、その鍵を使って暗号化または暗号化されるデータとを参照す
るために使われる。
２．鍵暗号およびデータ保全モード（後述する前述したブロック、連鎖、およびハッシ
ュモード）。

ホストから提供される属性に加えて、ＳＳＡシステムは次のデータを管理する。
１．鍵ＩＤの所有者：所有者にあたるＡＣＲのＩＤ。作成された鍵ＩＤの所有者は作成
元ＡＣＲである。しかし、鍵ＩＤの所有権は別のＡＣＲに譲渡できる。好ましくは、鍵Ｉ
Ｄの所有権を譲渡し、かつ鍵ＩＤを委譲できるものは鍵ＩＤの所有者のみである。鍵のア
クセス権限の委譲とこれらの権利の失効を行えるのは鍵ＩＤの所有者か、または委譲権限
を有するその他のＡＣＲである。ＳＳＡシステムは、これらの操作のいずれかが試みられ
るときに、操作を要求するＡＣＲにその権限が付与されている場合に限り操作を許諾する
ことになる。
２．ＣＥＫ：このＣＥＫの鍵値は、鍵ＩＤが割り振られたコンテンツまたは鍵ＩＤによ
って指示されるコンテンツの暗号化に使われる。鍵値は、ＳＳＡシステムによって生成さ
れる１２８ビットＡＥＳランダム鍵であってもよい。
３．ＭＡＣおよびＩＶ値：連鎖ブロック暗号（ＣＢＣ）符号化アルゴリズムで使われる
動的情報（メッセージ認証コードと開始ベクトル）。

図８Ａ〜図１６のフローチャートを参照しながらＳＳＡの様々な機能を例示するが、こ
れらの図でステップの左側に記された「Ｈ」はホストによって実行される操作を意味し、
「Ｃ」はカードによって実行される操作を意味する。メモリカードを参照しながらＳＳＡ
機能を例示するが、物理的形態が異なるメモリ装置にもこれらの機能が当てはまることが
理解できる。システムＡＣＲを作成するため、ホストはメモリ装置１０のＳＳＡに向けて
システムＡＣＲ作成コマンドを発行する（ブロック２０２）。装置１０はこれに応じてシ
ステムＡＣＲが既に存在するかどうかをチェックする（ブロック２０４、菱形２０６）。
装置１０はこれが既に存在する場合に失敗ステータスを返し、停止する（長円形２０８）
。メモリ１０はこれが既に存在しない場合にシステムＡＣＲの作成が許可されるかどうか
をチェックし（菱形２１０）、許可されない場合は失敗ステータスを返す（ブロック２１
２）。従って、例えば、必要なセキュリティ機能が事前に決まるので、システムＡＣＲが
必要とされない場合等、装置発行者がシステムＡＣＲの作成を許可しない場合もある。許
可される場合、装置１０はＯＫステータスを返し、ホストからシステムＡＣＲ信用証明が
届くのを待つ（ブロック２１４）。ホストはＳＳＡステータスをチェックし、システムＡ
ＣＲの作成が許可されていることを装置１０が伝えているかどうかをチェックする（ブロ
ック２１６と菱形２１８）。作成が許可されないか、あるいはシステムＡＣＲが既に存在
する場合、ホストは停止する（長円形２２０）。システムＡＣＲの作成が許可されている
ことを装置１０が伝える場合、ホストはそのログイン信用証明を設定するＳＳＡコマンド
を発行し、装置１０へ送信する（ブロック２２２）。装置１０は受信した信用証明でシス
テムＡＣＲ記録を更新し、ＯＫステータスを返す（ブロック２２４）。ホストはこのステ
ータス信号に応じて、システムＡＣＲの準備が整っていることを示すＳＳＡコマンドを発
行する（ブロック２２６）。これに応じて装置１０はシステムＡＣＲをロックするので、
システムＡＣＲの更新や差し替えはできなくなる（ブロック２２８）。これによりシステ
ムＡＣＲの機能と、ホストに対して装置１０を識別するためのアイデンティティとが固定
される。

新規ツリー（新規ルートＡＧＰおよびＡＣＲ）の作成手順は、それらの機能が装置でど
のように構成されているかによって決まる。図９は、その手順を説明するものである。ホ
スト２４とメモリシステム１０はいずれもこの手順をたどる。新規ルートＡＧＰの追加が
完全に無効になっている場合、新規ルートＡＧＰは追加できない（菱形２４６）。これが
有効になっているが、システムＡＣＲが要求される場合、ホストはルートＡＧＰ作成コマ
ンドの発行（ブロック２５４）に先立ちシステムＡＣＲを通じて認証し、セキュアチャネ
ルを確立する（菱形２５０、ブロック２５２）。システムＡＣＲが要求されない場合（菱
形２４８）、ホスト２４は認証なしでルートＡＧＰ作成コマンドを発行でき、ブロック２
５４へ進む。ホストは、システムＡＣＲが存在する場合、たとえこれが要求されない場合
でも、これを使用することがある（フローチャートには示されていない）。装置（例えば
、フラッシュカード）は、新規ルートＡＧＰ作成機能が無効になっている場合に新規ルー
トＡＧＰを作成する試みを拒否し、システムＡＣＲが要求される場合に認証なしで新規ル
ートＡＧＰを作成する試みを拒否する（菱形２４６および２５０）。ブロック２５４で新
たに作成されるＡＧＰとＡＣＲは作動モードに切り替わるので、そのＡＧＰの中にあるＡ
ＣＲの更新や変更はできなくなり、ＡＧＰへＡＣＲを追加することもできなくなる（ブロ
ック２５６）。ここでオプションとしてシステムはロックされるので、ルートＡＧＰは追
加で作成できなくなる（ブロック２５８）。点線の枠２５８は、このステップがオプショ
ンのステップであることを示す表記法である。本願の図のフローチャートにて点線で示さ
れた枠はいずれもオプションのステップである。このように、コンテンツの所有者は正当
なコンテンツを含む本物のメモリ装置を装う違法な目的に装置１０を利用できないように
することができる。

ＡＣＲ（前述したルートＡＧＰの中にあるＡＣＲとは別のＡＣＲ）を作成するには、図
１０に示すように、ＡＣＲを作成する権利を有するＡＣＲから開始できる（ブロック２７
０）。ホスト２４を通じて入ることを試みる実体は、入口にあたるＡＣＲのアイデンティ
ティと作成したいがための必要となる属性のすべてを含むＡＣＲとを提供する（ブロック
２７２）。ＳＳＡはＡＣＲアイデンティティの一致をチェックし、さらにそのアイデンテ
ィティを有するＡＣＲにＡＣＲを作成する権限があるかどうかをチェックする（菱形２７
４）。要求が証明される場合、装置１０のＳＳＡはＡＣＲを作成する（ブロック２７６）
。

図１１の２つのＡＧＰは、図１０の方法を使用するセキュリティアプリケーションで役
に立つツリーを例示するものである。従って、マーケティングＡＧＰの中でアイデンティ
ティｍ１を有するＡＣＲには、ＡＣＲを作成する権限がある。ＡＣＲ ｍ１は、鍵ＩＤ「
マーケティング情報」と関連付けられたデータと鍵ＩＤ「価格リスト」と関連付けられた
データを鍵を使って読み書きする権限も有する。これにより、図１０の方法を用いて２つ
のＡＣＲ ｓ１およびｓ２を含む販売ＡＧＰを作成する。ＡＣＲ ｓ１およびｓ２には鍵
ＩＤ「価格リスト」と関連付けられた価格データにアクセスするための鍵の読み出し権限
のみあるが、鍵ＩＤ「マーケティング情報」と関連付けられたデータにアクセスする場合
に必要となる鍵の権限はない。このように、ＡＣＲ ｓ１およびｓ２を有する実体は、価
格データを読み出されてもこれを変更することはできず、さらにマーケティングデータに
はアクセスできない。一方、ＡＣＲ ｍ２にはＡＣＲを作成する権限がなく、鍵ＩＤ「価
格リスト」と鍵ＩＤ「マーケティング情報」と関連付けられたデータにアクセスするため
の鍵の読み出し権限のみを有する。

従って、アクセス権は前述したやり方で委譲でき、ｍ１は価格データを読み出す権利を
ｓ１およびｓ２に委譲する。これは特に大規模なマーケティング組織や販売組織が関わる
場合に有用である。しかし、販売員が１名〜少数であれば図１０の方法を使う必要はない
場合がある。代わりに、図１２に示すように、ＡＣＲから同じＡＧＰの下位レベルまたは
同じレベルに位置するＡＣＲにアクセス権を委譲できる。実体はまず、そのＡＧＰのツリ
ーに入るため、ホストを通じてツリーの中のＡＣＲを前述したように指定する（ブロック
２８０）。次に、ホストはＡＣＲと委譲する権利を指定する。ＳＳＡはツリーでこのＡＣ
Ｒをチェックし、指定された別のＡＣＲに権利を委譲する権限がこのＡＣＲにあるかどう
かをチェックする（菱形２８２）。権限があるなら権利は委譲され（ブロック２８４）、
そうでないなら停止する。図１３はその結果を示す。この場合、ＡＣＲｍ１には読み出し
権限をＡＣＲ ｓ１に委譲する権限があるため、委譲の後、ｓ１は鍵を使って価格データ
にアクセスできるようになる。これは、ｍ１が価格データにアクセスするための権利また
はそれ以上の権利を有し、さらにそれを委譲する権限を有する場合に果たすことができる
。ｍ１は、一実施形態において、委譲の後にそのアクセス権を保持する。好ましくは、時
間やアクセス数を制限するなどにより（永続的にではなく）一定の条件のもとでアクセス
権を委譲する。

図１４は、鍵と鍵ＩＤを作成するプロセスを示す。実体はＡＣＲを通じて認証を受ける
（ブロック３０２）。実体は、ホストによって指定されたＩＤによる鍵の作成を要求する
（ブロック３０４）。ＳＳＡは、指定されたＡＣＲにその権限があるかどうかをチェック
する（菱形３０６）。例えば、ある特定のパーティションにあるデータにアクセスするた
めに鍵が使われる場合、ＳＳＡはそのパーティションにＡＣＲがアクセスできるかどうか
をチェックすることになる。ＡＣＲにその権限がある場合、メモリ装置１０はホストから
提供された鍵ＩＤと関連付けられた鍵値を作成し（ブロック３０８）、鍵ＩＤをＡＣＲに
記憶し、鍵値をメモリ（コントローラ関連メモリまたはメモリ２０のいずれか）に記憶し
、実体から提供された情報に従って権利と権限を付与し（ブロック３１０）、付与された
権利および権限で該当するＡＣＲのＰＣＲを修正する（ブロック３１２）。従って、読み
出しおよび書き込み権限、同じＡＧＰの中にある他のＡＣＲまたは下位レベルのＡＣＲに
委譲し共有する権利、鍵の所有権を譲渡する権利等、鍵の作成元はすべての権利を有する
。

図１５に示すように、ＡＣＲはＳＳＡシステムの中にある別のＡＣＲの権限（またはＡ
ＣＲの存在そのもの）を変更できる。実体はこれまでどおりＡＣＲを通じてツリーに入る
場合がある。この場合は実体の認証が行われ実体はＡＣＲを指定する（ブロック３３０、
３３２）。実体はターゲットＡＣＲの削除またはターゲットＡＣＲの権限の削除を要求す
る（ブロック３３４）。指定されたＡＣＲまたはその時点でアクティブなＡＣＲにその権
利があるなら（菱形３３６）、ターゲットＡＣＲを削除し、あるいはそのような権限を削
除するためにターゲットＡＣＲのＰＣＲを変更する（ブロック３３８）。これが認可され
ない場合、システムは停止する。

前述したプロセスの後、ターゲットはプロセスの前にアクセスできたデータにアクセスで
きなくなる。図１６に示すように、かつて存在したＡＣＲ ＩＤはもはやＳＳＡに存在し
ないため、ターゲットＡＣＲに入ることを試みる実体は認証プロセスの失敗に気づくので
、アクセス権は拒否される場合がある（菱形３５２）。ＡＣＲ ＩＤが削除されていない
と仮定した場合、実体はＡＣＲを指定し（ブロック３５４）、鍵ＩＤおよび／または特定
のパーティションのデータを指定し（ブロック３５６）、ＳＳＡはそのようなＡＣＲのＰ
ＣＲに従って鍵ＩＤまたはパーティションアクセス要求が許可されるかどうかをチェック
する（菱形３５８）。権限が削除されているか、あるいは失効している場合、要求は再度
却下される。そうでない場合、要求は許諾される（ブロック３６０）。 前述したプロセ
スは、ＡＣＲとそのＰＣＲが別のＡＣＲによって変更された場合であれ、あるいは初めか
らそのように構成されていた場合であれ、被保護データに対するアクセスが装置（例えば
、フラッシュカード）によってどのように管理されるかを説明するものである。

セッション
ＳＳＡシステムは、同時にログインする複数のユーザを処理するように設計されている
。この機能を使用する場合、ＳＳＡによって受信されるコマンドには特定の実体が対応し
、コマンドは、この実体の認証に用いるＡＣＲに要求された動作を行う権限がある場合に
限り実行される。

複数の実体はセッションのコンセプトによってサポートされる。セッションは認証プロ
セスで確立し、ＳＳＡシステムによってセッションｉｄが割り当てられる。セッションｉ
ｄはシステムへのログインに使われたＡＣＲに内部で関連付けられ、実体へエクスポート
され、それ以降のＳＳＡコマンドで使われる。

ＳＳＡシステムは、２通りのセッション、すなわちオープンセッションとセキュアセッ
ションとをサポートする。認証プロセスと関連付けられたセッションのタイプはＡＣＲの
中で設定される。ＳＳＡシステムは、認証の施行と同様のやり方でセッション確立を施行
する。実体の権限はＡＣＲで設定されるため、システム設計者は特定の鍵ＩＤに対するア
クセスまたは特定のＡＣＲ管理操作（新規ＡＣＲの作成、信用証明の設定等）の実行にセ
キュアトンネルを関連付けることができる。

オープンセッション
オープンセッションはセッションｉｄで識別されるセッションであるが、バス暗号化は
行われないため、コマンドとデータはいずれも暗号化されずに引き渡される。この動作モ
ードは、好ましくは実体が脅威モデルに該当せずバス上で傍受を行わない多数のユーザま
たは多数の実体環境に使用される。

オープンセッションモードではデータ送信が保護されず、ホスト側のアプリケーション
間に効率的なファイアウォールは実施されないが、ＳＳＡシステムが認証済みのＡＣＲで
アクセスできる情報のみにアクセスを許すことができる。

オープンセッションはパーティションまたは鍵を保護する必要がある場合にも使用でき
る。しかし、有効な認証プロセスの後にはホスト側のすべての実体にアクセスが許諾され
る。ホストアプリケーションはセッションｉｄさえあれば認証済みＡＣＲの権限を得るこ
とができる。これは図１７Ａに例示されている。線４００より上のステップはホスト２４
によって実行されるステップである。ＡＣＲ１の認証（ブロック４０２）を終えた実体は
、メモリ装置１０で鍵ＩＤ Ｘと関連付けられたファイルへのアクセスを要求する（ブロ
ック４０４、４０６、および４０８）。ＡＣＲ１のＰＣＲがこのアクセスを認める場合、
装置１０は要求を許諾する（菱形４１０）。そうでない場合、システムはブロック４０２
まで戻る。認証が完了した後、メモリシステム１０はコマンドを発行する実体を（ＡＣＲ
信用証明ではなく）割り当てられたセッションｉｄのみで識別する。オープンセッション
でいったんＡＣＲ１がＰＣＲの鍵ＩＤと関連付けられたデータに到達すると、他のどのア
プリケーションまたはユーザでも、ホスト２４上の様々なアプリケーションによって共有
される正しいセッションｉｄを指定することによって同じデータにアクセスできる。この
機能は、一度のみログインし、様々なアプリケーションに対してログインに使われたアカ
ウントに結合されたすべてのデータにアクセスできることがユーザにとって好都合な場合
のアプリケーションに有利である。携帯電話機のユーザの場合、記憶されたｅメールにア
クセスし、ログインを繰り返すことなくメモリ２０に記憶された音楽を聞くことができる
。一方、ＡＣＲ１に該当しないデータにはアクセスできないことになる。このため、ゲー
ムや写真等の同じ携帯電話機のユーザにとって貴重となり得るコンテンツは、別のアカウ
ントＡＣＲ２を通じてアクセスされる。これは、携帯電話機のユーザの電話機を借りる人
にアクセスさせたくないデータであるが、携帯電話機のユーザにとって、最初のアカウン
トＡＣＲ１でアクセスできるデータなら他人がアクセスしてもよい。データへのアクセス
を２つの別々のアカウントに分け、ＡＣＲ１へのアクセスをオープンセッションで行うこ
とにより、使い易くなるばかりでなく貴重なデータを保護できる。

ホストアプリケーション間でのセッションｉｄの共有をさらに簡単にするには、オープ
ンセッションを要求するＡＣＲが、セッションに「０（ゼロ）」ｉｄを割り当てることを
具体的に要求する。このように、アプリケーションは所定のセッションｉｄを使用するよ
うに設計できる。当然ながら、セッション０を要求するＡＣＲは一度に１つしか認証でき
ない。セッション０を要求する別のＡＣＲを認証する試みは拒否されることになる。

セキュアセッション
セキュリティ層を追加するため、セッションｉｄは図１７Ｂに示すように使ってもよい
。この場合はメモリ１０もアクティブセッションのセッションｉｄを記憶する。図１７Ｂ
で、例えば鍵ＩＤ Ｘと関連付けられたファイルにアクセスするには、実体もセッション
ｉｄ、例えばセッションｉｄ「Ａ」を提供する必要があり、その上でファイルへのアクセ
スが許可されることになる（ブロック４０４、４０６、４１２、および４１４）。このよ
うに、要求する実体は正しいセッションｉｄを知らない限りメモリ１０にアクセスできな
い。セッションｉｄはセッションが終わった後に削除され、セッションのたびに異なるた
め、実体はセッション番号を提供できた場合に限りアクセスできる。

ＳＳＡシステムは、コマンドが実際に正しい認証済み実体から届いているかどうかを、
セッション番号を使って追跡する。攻撃者がオープンチャネルを使って悪質なコマンドの
送信を試みるおそれがある用途や使用がある場合、ホストアプリケーションはセキュアセ
ッション（セキュアチャネル）を使用する。
セキュアチャネルを使用する場合、セッションｉｄとコマンド全体がセキュアチャネル
暗号化（セッション）鍵を使って暗号化され、そのセキュリティ水準はホスト側の実施例
と同じくらい高くなる。

セッションの終了
セッションは次に記すシナリオのいずれか１つで終了し、ＡＣＲはログオフされる。
１．実体が明示的なセッション終了コマンドを発行する。
２．通信タイムアウトが発生する。ある特定の実体がＡＣＲパラメータの一パラメータ
として設定された期間にわたってコマンドを発行しなかった。
３．装置（例えば、フラッシュカード）のリセットおよび／またはパワーサイクルの後
にはすべてのオープンセッションが終了する。

データ保全サービス
ＳＳＡシステムは、ＳＳＡデータベース（ＡＣＲ、ＰＣＲ等を収容）が完全な状態に保
たれていることをベリファイする。このほかに、鍵ＩＤ機構による実体データのデータ保
全サービスも提供される。
鍵ＩＤの暗号化アルゴリズムがハッシュモードに設定される場合、ＣＥＫおよびＩＶと
併せてハッシュ値がＣＥＫ記録に記憶される。書き込み操作中にはハッシュ値の計算と記
憶が行われる。読み出し操作のときにも再度ハッシュ値を計算し、前の書き込み操作中に
記憶された値と比較する。実体が鍵ＩＤにアクセスするたびに追加のデータが古いデータ
に（暗号的に）連結され、該当するハッシュ値（読み出しまたは書き込みのため）が更新
される。

鍵ＩＤと関連付けられた、または鍵ＩＤによって指示される、データファイルを知るの
はホストのみであるため、データ保全機能の各態様はホストが明示的に次のように管理す
る。
１．鍵ＩＤと関連付けられた、または鍵ＩＤによって指示される、データファイルは最
初から最後まで書き込まれるか、または読み出される。ＳＳＡシステムはＣＢＣ暗号方式
を使用し、データ全体のハッシュ化メッセージダイジェストを生成するため、ファイルの
一部分にアクセスする試みによってファイルは混乱することになる。
２．中間ハッシュ値はＳＳＡシステムによって管理されるため、連続するストリームの
中でデータを処理する必要はない（このデータストリームは他の鍵ＩＤのデータストリー
ムでインターリーブでき、複数のセッションにわたって分割できる）。しかし、実体は、
データストリームが再度始まる場合にハッシュ値のリセットをシステムに明示的に指示す
る必要がある。
３．ホストは読み出し操作が完了すると、読み出されたハッシュを書き込み操作中に計
算したハッシュ値と比較することによって有効にすることをＳＳＡシステムに明示的に要
求する。
４．ＳＳＡシステムは「ダミー読み出し」操作も提供する。この機能によりデータは暗
号化エンジンを通過するが、ホストには送出されないことになる。この機能を利用すれば
、データが実際に装置（例えば、フラッシュカード）から読み出される前に、データが完
全な状態に保たれていることをベリファイすることができる。

乱数生成
外部実体はＳＳＡシステムの内部乱数生成器を利用でき、乱数はＳＳＡシステムの外で
使用できる。このサービスはいずれのホストでも利用でき、認証は必要ない。

ＲＳＡ鍵対生成
外部ユーザはＳＳＡシステムの内部ＲＳＡ鍵対生成機能を利用でき、鍵対はＳＳＡシス
テムの外で使用できる。このサービスはいずれのホストでも利用でき、認証は必要ない。

代替の実施形態
階層アプローチを使う代わりに、図１８に示すデータベースアプローチを使って同様の
結果を達成できる。
図１８に示すように、コントローラ１２またはメモリ２０に記憶されたデータベースに
入力された実体の信用証明リスト、認証方法、最大失敗数、遮断解除に必要な最小信用証
明数等は、メモリ１０のコントローラ１２によって実行されるデータベース内の方針（鍵
・パーティションに対する読み出し、書き込みアクセス、セキュアチャネル要件）に結び
付いている。鍵・パーティションアクセスに対する制約事項や制限事項もデータベースに
記憶される。ホワイトリストにある可能性がある実体（例えば、システム管理者）はすべ
ての鍵とパーティションにアクセスできる。ブラックリストにある可能性がある実体によ
る情報アクセスの試みは阻止される。制限は全域におよぶ場合と鍵および／またはパーテ
ィションごとに適用される場合とがある。これは、特定の実体のみが特定の鍵・パーティ
ションにアクセスでき、特定の実体はアクセスできないことを意味する。コンテンツのパ
ーティションや、コンテンツの暗号化または復号化に使う鍵にかかわりなく、コンテンツ
自体に制約を課すこともできる。したがって、データ（例えば、歌）にアクセスする可能
性がある最初の５ホスト装置のみにアクセスを許可したり、あるいはデータ（例えば、映
画）にアクセスしたりする実体は問わず、データの読み出し回数を制限することができる
。
認証
パスワード保護
・パスワード保護は、被保護領域へアクセスする場合にパスワードの提示が求められる
ことを意味する。パスワードが１つに限られる場合を除き、それぞれのパスワードには読
み出しアクセスや読み出し／書き込みアクセス等、別々の権利を割り振ることができる。
・パスワード保護は、ホストから提供されるパスワードを装置（例えば、フラッシュカ
ード）がベリファイできること、すなわち装置もまた装置によって管理され保護されたメ
モリ領域にパスワードを記憶することを意味する。
問題と限界
・パスワードはリプレー攻撃を被ることがある。提示のたびに変わらないパスワードは
同じ状態で再送できる。つまり、保護の対象となるデータが貴重で、通信バスへのアクセ
スが容易い場合、パスワードを現状のまま使用するべきではない。
・パスワードによって記憶データへのアクセスは保護できるが、（鍵ではなく）データ
の保護のためにパスワードを使用するべきではない。
・パスワードに関わるセキュリティ水準を上げるため、親鍵を使ってパスワードを多様
化すれば、１つのパスワードがハッキングされてもシステム全体が破られることはない。
パスワードの送信にはセッション鍵方式のセキュア通信チャネルを使用できる。

図１９は、パスワードを使った認証を示すフローチャートである。実体はアカウントｉ
ｄとパスワードをシステム１０（例えば、フラッシュメモリカード）へ送信する。システ
ムは、パスワードが自身のメモリにあるパスワードに一致するかどうかをチェックする。
一致する場合は認証済みステータスを返す。そうでない場合はそのアカウントのエラーカ
ウンタが増加し、実体にはアカウントｉｄとパスワードの再入力が求められる。システム
はカウンタが一杯になるとアクセス拒否ステータスを返す。

対称鍵
対称鍵アルゴリズムは、暗号化と復号化の両側で同じ鍵が使われることを意味する。こ
れは、通信に先立ち予め鍵を取り決めておくことを意味する。それぞれの側では相手側の
逆のアルゴリズムを実行する。つまり、一方は暗号化アルゴリズムになり、他方は復号化
アルゴリズムになる。通信する場合に両側で両方のアルゴリズムを実行する必要はない。
認証
・対称鍵認証は、装置（例えば、フラッシュカード）とホストが同じ鍵を共有し、同じ
暗号アルゴリズム（ダイレクトおよびリバース、例えばＤＥＳ、ＤＥＳ−１）を具備する
ことを意味する。
・対称鍵認証は、チャレンジ・レスポンス（リプレー攻撃対策）を意味する。被保護装
置が他の装置に対する質問を生成し、両方の装置で回答を計算する。認証を受ける側の装
置は回答を送り返し、被保護装置はその回答をチェックして真贋を検査する。そして、認
証に応じて権利を付与する。
認証には次のものがある。
・外部認証：装置（例えば、フラッシュカード）が外部を認証する。つまり、装置は特
定のホストまたはアプリケーションの信用証明を検査する。
・相互認証：両側で質問を生成する。
・内部認証：ホストアプリケーションが装置（例えば、フラッシュカード）を認証する
。つまり、ホストは、装置がそのアプリケーションにとって真正であるかどうかをチェッ
クする。
システム全体のセキュリティ水準を上げるため（１つが破られてもすべてが破られない
ようにするため）
・対称鍵には通常、親鍵を使った多様化を組み合わせる。
・質問が真正な質問であることを確認するため、相互認証により両側からの質問を使用
する。
暗号化
対称鍵暗号法はすこぶる効率的なアルゴリズムで、暗号処理する場合に強力なＣＰＵを
必要としないため、暗号化にも使われる。

通信チャネルを安全に使う場合：
・チャネルの安全を確保する（つまり、全発信データを暗号化し全着信データを復号化
する）ために使うセッション鍵を、両方の装置が知らなければならない。このセッション
鍵は通常、事前共有秘密対称鍵を使うか、あるいはＰＫＩを使って設定する。
・両方の装置が同じ暗号アルゴリズムを知り、実行しなければならない。
署名
対称鍵を使ってデータに署名することもできる。この場合の署名は暗号化の部分的な結
果である。このため、鍵値を露出することなく必要に応じて何度でも署名できる。

問題と限界
対称アルゴリズムは非常に効率的で安全ではあるが、事前共有秘密を基礎とする。問題
は、この秘密を動的に安全に共有することと、（セッション鍵のように）ランダムにする
ことである。つまり、共有秘密を長期間にわたって安全に保つのは困難であり、多数の人
々と共有することはほぼ不可能である。
この作業を促進するために考案されたのが、秘密を共有せずに交換する公開鍵アルゴリ
ズムである。

非対称認証手続き
非対称鍵に基づく認証では、一連のコマンドを使ってデータを受け渡ししながら、最終
的にはセキュアチャネル通信のためのセッション鍵を作る。その基本的プロトコルではＳ
ＳＡシステムに対してユーザを認証する。プロトコルのバリエーションにより、ユーザが
使用するＡＣＲをベリファイする相互認証や二因子認証も可能である。

ＳＳＡの非対称認証プロトコルでは好ましくは、公開鍵基盤（ＰＫＩ）アルゴリズムと
ＲＳＡアルゴリズムを使用する。これらのアルゴリズムで規定することで、認証プロセス
の各当事者に独自のＲＳＡ鍵対を用意することができる。それぞれの対は公開鍵と秘密鍵
とからなる。これらの鍵は秘匿の鍵であるためにアイデンティティの証拠を提供すること
はできない。ＰＫＩ層では信頼された第三者機関が公開鍵に署名する。この信用機関の公
開鍵は、互いを認証する当事者間で事前共有され、当事者の公開鍵をベリファイするため
に使われる。信用が成立すると（両当事者が相手方から提供される公開鍵を信用できると
判断したら）、プロトコルによる認証（各当事者が所有する秘密鍵の一致をベリファイす
る）と鍵の交換が続行する。これは、後述する図２２および２３のチャレンジ・レスポン
ス機構で果たすことができる。

署名済みの公開鍵を収容する構造を証明書という。証明書に署名した信用機関を証明機
関（ＣＡ）という。認証を受ける側は公開鍵の信憑性を立証する証明書とＲＳＡ鍵対を有
する。証明書は、相手方（認証する側）が信用する証明機関によって署名される。認証す
る側には信用ＣＡの公開鍵の所有が求められる。

ＳＳＡは証明書連鎖に対応する。これは、識別される側の公開鍵が別のＣＡ、すなわち
識別する側が信用するＣＡとは異なるＣＡによって署名されることを意味する。この場合
の識別される側は、自分自身の証明書のほかに、その公開鍵に署名したＣＡの証明書を提
供する。この第２レベルの証明書さえも相手方によって信用されない（信用ＣＡによって
署名されていない）場合、第３レベルの証明書を提供できる。この証明書連鎖アルゴリズ
ムでは、各当事者が公開鍵の認証に必要な証明書の完全なリストを所有する。このことは
、図２３および２４に例示されている。この種のＡＣＲによる相互認証に必要な信用証明
は、一定の長さを有するＲＳＡ鍵対である。

ＳＳＡ証明書
ＳＳＡは［Ｘ．５０９］バージョン３デジタル証明書を採用する。［Ｘ．５０９］は汎
用規格であり、ここで説明するＳＳＡ証明書プロファイルは証明書の所定フィールドの内
容をさらに指定し、制限する。この証明書プロファイルは、証明書連鎖の管理に用いる信
頼階層と、ＳＳＡ証明書の検査と、証明書失効リスト（ＣＲＬ）プロファイルも規定する
。
証明書は公開情報（内部の公開鍵として）とみなされるため、暗号化されない。しかし
、証明書はＲＳＡ署名を含み、このＲＳＡ署名によって公開鍵やその他の情報フィールド
が改竄されていないことをベリファイする。
［Ｘ．５０９］はＡＳＮ．１規格を使った各フィールドのフォーマットを定め、ＡＳＮ
．１規格はデータ符号化にＤＥＲフォーマットを使用する。

ＳＳＡ証明書の概要
図２０と図２１とに示されたＳＳＡ証明書管理アーキテクチャの一実施形態は、ホスト
の無限階層レベルと装置の３階層レベルからなるが、装置で使用する階層レベルは３レベ
ルより多い場合または３レベルより少ない場合がある。

ホスト証明書階層
装置は、２つの要素、すなわち装置に記憶されたルートＣＡ証明書（ＡＣＲ信用証明と
してＡＣＲの作成時に記憶）と、装置への（その特定のＡＣＲへの）アクセスを試みる実
体から提供される証明書／証明書連鎖とに基づき、ホストを認証する。

ホスト証明機関は、それぞれのＡＣＲに対してルートＣＡ（ＡＣＲ信用証明の中にある
証明書）の役割を果たす。例えば、ある１つのＡＣＲにとってのルートＣＡは「ホスト１
ＣＡ（レベル２）証明書」であり、別のＡＣＲにとってのルートＣＡは「ホストルート
ＣＡ証明書」である。それぞれのＡＣＲに対して、ルートＣＡによって署名された証明書
（またはルートＣＡを末端実体証明書までつなげる証明書連鎖）を保持するすべての実体
が、末端実体証明書の対応する秘密鍵を有している場合、そのＡＣＲにログインできる。
前述したように、証明書は公知であり、秘密にしない。

ルートＣＡによって発行された証明書（ならびに対応する秘密鍵）の所有者は誰でもそ
のＡＣＲにログインできるということは、ある特定のＡＣＲに対する認証がそのＡＣＲの
信用証明に記憶されたルートＣＡの発行者によって決まることを意味する。換言すると、
ルートＣＡの発行者がＡＣＲの認証方式を管理する実体になる。

ホストルート証明書
ルート証明書は、ログインを試みる実体（ホスト）の公開鍵のベリファイを開始するの
にＳＳＡが使われるときに使用する信用ＣＡ証明書である。この証明書はＡＣＲの作成時
にＡＣＲ信用証明の一部として提供される。これはＰＫＩシステムに対する信用の根元に
あたるものであるため、信用された実体（父ＡＣＲ、または製造／構成信頼環境）から提
供されることが前提となる。この証明書をベリファイするＳＳＡは、その公開鍵を使って
証明書の署名をベリファイする。ホストルート証明書は暗号化された状態で不揮発性メモ
リ（図１には示されていない）に記憶され、装置の秘密鍵にアクセスできるものは、好ま
しくは図１のシステム１０のＣＰＵ１２のみである。

ホスト証明書連鎖
これらの証明書は認証中にＳＳＡへ提供される。連鎖の処理が完了した後にホストの証
明書連鎖を再度集めて装置に記憶することはしない。

図２０は、多数のホスト証明書連鎖を示す、ホスト証明書レベル階層の概略図である。
図２０に示すように、ホスト証明書は多数の証明書連鎖を有することがあり、ここでは３
つの証明書連鎖のみが例示されている。
Ａ１．ホストルートＣＡ証明書５０２、ホスト１ ＣＡ（レベル２）証明書５０４、
ホスト証明書５０６
Ｂ１．ホストルートＣＡ証明書５０２、ホストｎ ＣＡ（レベル２）証明書５０８、
ホスト１ ＣＡ（レベル３）証明書５１０、ホスト証明書５１２
Ｃ１．ホストルートＣＡ証明書５０２、ホストｎ ＣＡ（レベル２）証明書５０８、
ホスト証明書５１４

前述した３つの証明書連鎖Ａ１、Ｂ１、およびＣ１は、ホストの公開鍵が真正であるこ
とを証明するために使われてもよい３通りのホスト証明書連鎖を例示するものである。図
２０と前述した証明書連鎖Ａ１を参照し、ホスト１のＣＡ（レベル２）証明書５０４の公
開鍵はホストルートＣＡの秘密鍵によって署名され（すなわち、公開鍵のダイジェストを
暗号化）、この公開鍵はホストルートＣＡ証明書５０２にある。したがって、ホストルー
トＣＡの公開鍵を有する実体は、前述した証明書連鎖Ａ１の信憑性をベリファイできるこ
とになる。この実体は最初のステップとして、ホストから送信されたホスト１のＣＡ（レ
ベル２）証明書５０４の署名済み公開鍵を、自身が所有するホストルートＣＡの公開鍵を
使って復号化し、復号化した署名済み公開鍵を、ホストから送信されたホスト１のＣＡ（
レベル２）証明書５０４の署名されていない公開鍵のダイジェストと比較する。２つが一
致する場合、ホスト１のＣＡ（レベル２）の公開鍵は認証され、実体は次に、ホストから
送信されたホスト証明書５０６の中にあるホスト１のＣＡ（レベル２）の秘密鍵によって
署名されたホストの公開鍵を、ホスト１のＣＡ（レベル２）の認証済み公開鍵を用いて復
号化することになる。この復号化された署名済みの値が、ホストから送信されたホスト証
明書５０６の中にある公開鍵のダイジェストの値に一致する場合、ホストの公開鍵も認証
される。証明書連鎖Ｂ１およびＣ１を使った認証も同様に行われる。

連鎖Ａ１が関わる前述したプロセスから分かるように、ホストから送信され実体によっ
てベリファイされる最初の公開鍵は、ホストルートＣＡ証明書ではなくホスト１のＣＡ（
レベル２）の公開鍵である。このため、ホストが実体へ送る必要があるものはホスト１の
ＣＡ（レベル２）証明書５０４とホスト証明書５０６であって、ホスト１のＣＡ（レベル
２）証明書は連鎖の中で最初に送信される必要があることになる。前述したように、証明
書のベリファイ順序は次のとおりである。ベリファイする側の実体、すなわちこの場合の
メモリ装置１０はまず、連鎖の中で最初の証明書の公開鍵の真性をベリファイし、この場
合のものはルートＣＡの下に位置するＣＡの証明書５０４である。この証明書の公開鍵が
真正であることをベリファイした後、装置１０は次の証明書のベリファイに進み、この場
合のものはホスト証明書５０６である。証明書連鎖が３つ以上の証明書を含む場合のベリ
ファイ順序も同様に、ルート証明書のすぐ下に位置する証明書から始まり、認証の対象と
なる実体の証明書で終わる。

装置証明書階層
ホストは２つの要素、すなわちホストに記憶された装置ルートＣＡと、装置からホスト
へ提供される（ＡＣＲの作成時に信用証明として装置に提供される）証明書／証明書連鎖
とに基づき装置を認証する。ホストによる装置の認証プロセスは、前述した装置によるホ
スト認証プロセスに類似する。

装置証明書連鎖
これらの証明書はＡＣＲの鍵対の証明書である。これらの証明書はＡＣＲの作成時にカ
ードに提供される。ＳＳＡはこれらの証明書を個別に記憶し、認証のときにはそれらを１
つずつホストに提供する。ＳＳＡはこれらの証明書を使ってホストの認証を受ける。装置
は３つの証明書からなる連鎖を処理できるが、証明書数が３以外になる場合がある。証明
書の数はＡＣＲによって異なることがある。これはＡＣＲが作成されるときに決まる。装
置はホストに向けて証明書連鎖を送信できるが、証明書連鎖データを使用するわけではな
いので、証明書連鎖を解析する必要はない。

図２１は、ＳＳＡを使用する記憶装置等の装置で１〜ｎ通りの証明書連鎖を示す、装置
証明書レベル階層の概略図である。図２１に示されたｎ通りの証明書連鎖は次のとおりで
ある。
Ａ２．装置ルートＣＡ証明書５２０、装置１ ＣＡ（製造業者）証明書５２２、
装置証明書５２４
Ｂ２．装置ルートＣＡ証明書５２０、装置ｎ ＣＡ（製造業者）証明書５２６、
装置証明書５２８

ＳＳＡ装置は、それぞれ独自の装置ＣＡ証明書を有する１〜ｎ通りの製造業者によって
製造される。したがって、ある特定の装置の装置証明書の公開鍵はその異なる製造業者の
秘密鍵によって署名され、製造業者の公開鍵は装置ルートＣＡの秘密鍵によって署名され
る。装置の公開鍵をベリファイする方法は、前述したホストの公開鍵の場合の方法に類似
する。ホストについて前述した連鎖Ａ１のベリファイの場合と同様に、装置ルートＣＡ証
明書を送る必要はなく、連鎖の中で送信すべき最初の証明書は装置ｉＣＡ（製造業者）証
明書であって、その後に装置証明書が続き、ｉは１〜ｎの整数である。

図２１に示す実施形態において、装置は２つの証明書、つまり装置ｉ ＣＡ（製造業者
）証明書と、その後に自身の装置証明書とを送信する。装置ｉ ＣＡ（製造業者）証明書
は、このような装置を製造し、装置の公開鍵に署名するための秘密鍵を提供する製造業者
の証明書である。装置ｉ ＣＡ（製造業者）証明書を受信したホストは、自身が所有する
ルートＣＡの公開鍵を使って装置ｉ ＣＡ（製造業者）公開鍵を復号化し、ベリファイす
る。ホストはこのベリファイに失敗した場合、プロセスを中断し、認証が失敗したことを
装置に伝える。ホストが認証に成功した場合、次の証明書を求める要求を装置へ送信する
。そして、装置は自身の装置証明書を送信し、ホストはこれを同様にベリファイする。

図２２および図２３は、前述したベリファイプロセスをさらに詳しく示すものである。
図２２の「ＳＳＭシステム」は、本願明細書で説明するＳＳＡシステムと後述するその他
の機能とを実行するソフトウェアモジュールである。ＳＳＭはソフトウェアまたはコンピ
ュータコードとして具現化でき、メモリ２０またはＣＰＵ１２の不揮発性メモリ（図示せ
ず）にデータベースを記憶し、ＲＡＭ １２ａに読み込まれてＣＰＵ １２によって実行
される。

図２２に示すように、装置１０のＳＳＭシステム５４２がホストシステム５４０を認証
するプロセスには３つの段階がある。最初の公開鍵ベリファイ段階では、ホストシステム
５４０がＳＳＭコマンドでホスト証明書連鎖をＳＳＭシステム５４２へ送信する。ＳＳＭ
システム５４２は、ホスト証明書５４４の真性とホスト公開鍵５４６の真性を、ＡＣＲ５
５０のホストルート証明書５４８にあるルート証明機関公開鍵を用いてベリファイする（
ブロック５５２）。ルート証明機関とホストの間に中間証明機関が介在する場合、中間証
明書５４９もブロック５５２のベリファイに使われる。ベリファイまたはプロセス（ブロ
ック５５２）が成功したと仮定し、ＳＳＭシステム５４２は第２段階へ進む。

ＳＳＭシステム５４２は乱数５５４を生成し、これを質問としてホストシステム５４０
へ送信する。システム５４０はホストシステムの秘密鍵５４７を使って乱数５５４に署名
し（ブロック５５６）、質問に対する回答として署名済みの乱数を送信する。その回答は
ホスト公開鍵５４６を使って復号化され（ブロック５５８）、乱数５５４と比較される（
ブロック５６０）。復号化された回答が乱数５５４に一致したと仮定すると、チャレンジ
・レスポンスは成功である。

第３段階ではホスト公開鍵５４６を使って乱数５６２を暗号化する。この乱数５６２が
セッション鍵となる。ホストシステム５４０は、ＳＳＭシステム５４２からの暗号化数５
６２を秘密鍵を使って復号化（ブロック５６４）することによってセッション鍵を得るこ
とができる。このセッション鍵により、ホストシステム５４０とＳＳＭシステム５４２と
の間でセキュア通信を開始できる。図２２に示す一方向非対称認証では、装置１０のＳＳ
Ｍシステム５４２によってホストシステム５４０が認証される。図２３は、図２２の一方
向認証プロトコルに類似する双方向相互認証プロセスを示すプロトコル図であり、図２３
ではＳＳＭシステム５４２もホストシステム５４０によって認証される。

図２４は、本発明の一実施形態を例示する証明書連鎖５９０の図である。前述したよう
に、ベリファイする場合に提示の必要がある証明書連鎖は多数の証明書を含むことがある
。図２４の証明書連鎖は全部で９つの証明書を含み、認証する場合にはこれらの証明書を
すべてベリファイすることが必要となる場合がある。背景技術の欄で前に説明したように
、既存の証明書ベリファイシステムでは、送信される証明書連鎖に不備があったり、信用
証明全体が送信されたり、証明書が特定の順序で送信されないと、受信側は証明書を一通
り受信し記憶するまで証明書を解析できない。しかし、連鎖に含まれる証明書の数は事前
に分からないため、問題が生じることがある。長さが定かでない証明書連鎖を記憶するた
めに大量の記憶容量を確保する必要になることがある。これはベリファイを行う記憶装置
にとって問題になることがある。

本発明の一実施形態は、証明書連鎖が記憶装置によってベリファイされる順序と同じ順
序でホスト装置が証明書連鎖を送信するシステムによってこの問題を軽減できるという認
識に基づく。よって、図２４に示すように、証明書の連鎖５９０は、ホストルート証明書
のすぐ下に位置する証明書５９０（１）から始まり、ホスト証明書に相当する証明書５９
０（９）で終わる。したがって、装置１０はまず、証明書５９０（１）で公開鍵をベリフ
ァイし、その後に証明書５９０（２）で公開鍵のベリファイ等を行い、最後に証明書５９
０（９）で公開鍵をベリファイする。これで証明書連鎖５９０全体のベリファイプロセス
は完了する。ホスト装置が証明書連鎖５９０をベリファイと同じ順序でメモリ装置１０へ
送信する場合、メモリ装置１０は証明書が届くたびにベリファイを開始することができ、
連鎖５９０に含まれる９つの証明書が一通り届くまで待つ必要はない。

したがって、ホスト装置は、一実施形態において、メモリ装置１０に対して連鎖５９０
の証明書を一度に１つずつ送信する。メモリ装置１０は一度に１つの証明書を記憶するこ
とになる。連鎖の中の最後の証明書を除き、ベリファイ済みの証明書はホストから送信さ
れる次の証明書で上書きできる。このため、メモリ装置１０には、１つのみの証明書を随
時記憶する容量を確保すればよい。

メモリ装置は、連鎖５９０が一通り届いたことを知る必要がある。このため、好ましく
は、最後の証明書５９０（９）には、これが連鎖の中で最後の証明書であることを伝える
標識または標示を入れる。これを例示する図２５の表は、ホストからメモリ装置１０へ送
信される証明書バッファに先行する制御セクタ内の情報を示す。図２５に示すように、証
明書５９０（９）の制御セクタには引数名「最終」フラグがある。メモリ装置１０は、「
最終」フラグが設定されているかどうかをチェックして受信した証明書が連鎖における最
終証明書であるかどうかを判断することにより、連鎖の中で証明書５９０（９）が最後の
証明書であることをベリファイできる。

代替的な実施形態では、連鎖５９０の証明書を１つずつ送信するのではなく、１つ、２
つ、または３つの証明書からなるグループで送信してもよい。当然ながら、グループで使
用する証明書の数は異なる場合があったり、あるいは同じになる場合がある。連鎖５９０
には５つの連続する証明書列５９１、５９３、５９５、５９７、および５９９がある。そ
れぞれの列は少なくとも１つの証明書を含む。ある１つの証明書の列には、連鎖の中で該
当する１列の先行列に隣接する証明書（先頭証明書）と、連鎖の中で該当する１列の後続
列に隣接する証明書（終端証明書）と、先頭証明書と終端証明書との間にある全証明書が
含まれる。例えば列５９３の中には、全部で３つの証明書５９０（２）、証明書５９０（
３）、および証明書５９０（４）がある。メモリ装置１０による５つの証明書の列のベリ
ファイは５９１、５９３、５９５、５９７の順で行われ、５９９で終わる。したがって、
５つの列がメモリ装置１０によるベリファイと同じ順序で送信され、受信される場合、ベ
リファイ済みの列をメモリ装置で記憶する必要はなくなり、最後の列を除く列はいずれも
、ホストから到着する次の列で上書きできる。前の実施形態と同様に、連鎖内の最後の証
明書には標識、例えばこれが連鎖における最後の証明書であることを伝える特定の値に設
定されたフラグを入れるのが望ましい。この実施形態の場合、メモリ装置は５つの列のう
ち、証明書数が最も多い列の証明書を記憶する十分な容量を確保するだけでよい。よって
、ホストが送ろうとする列のうちの最も大きい列を事前にメモリ装置１０に知らせる場合
、メモリ装置１０は最も大きい列のための十分な容量を確保するだけでよい。

好ましくは、ホストによって送信される連鎖の中の各証明書の長さは、その証明書によ
って証明される公開鍵の長さの４倍以下である。同様に、メモリ装置の公開鍵を証明する
ためにメモリ装置１０からホスト装置へ送信される証明書の長さは好ましくは、その証明
書によって証明される公開鍵の長さの４倍以下である。

図２６のフローチャートは、前述した証明書連鎖ベリファイの実施形態を示すものであ
り、ここでは簡潔を図るため、各グループ内の証明書数を１と仮定する。図２６に示すよ
うに、ホストはカードに向けて連鎖内の証明書を順次送信する。連鎖の中の第１の証明書
（前述したように、通常はルート証明書の後続証明書）から始まって、カードは、認証の
対象となるホストから証明書連鎖を順次受信する（ブロック６０２）。そして、カードは
受信する証明書の各々をベリファイし、証明書のいずれかでベリファイに失敗した場合は
プロセスを中止する。カードは、証明書のいずれかでベリファイに失敗した場合、ホスト
に通知する（ブロック６０４、６０６）。次に、カードは、最後の証明書が受信されベリ
ファイされたかどうかを検出する（菱形６０８）。最終証明書の受信とベリファイとがま
だであれば、カードはブロック６０２まで戻り、ホストからの証明書の受信とベリファイ
を続行する。最終証明書を受信し、ベリファイしたら、カードは証明書ベリファイの後に
続く次の段階へ進む（６１０）。図２６とそれ以降の図の内容は例としてメモリカードを
参照するが、物理的形態がメモリカードではないメモリ装置にもこれらの内容が当てはま
ることが理解できる。

図２７は、カードがホストを認証する場合にホストによって実行されるプロセスを示す
。図２７に示すように、ホストは連鎖の中の次の証明書をカードに送信する（ブロック６
２０）（通常はルート証明書の後続証明書から始まる。ホストは、認証の失敗を伝える中
止通知がカードから届いているかどうかを判断する（菱形６２２）。中止通知が届いてい
るならホストは停止する（ブロック６２４）。中止通知が届いてなければ、ホストは送信
された最後の証明書で「最終フラグ」が設定されているかどうかをチェックすることによ
り、連鎖の最終証明書が送信済みかどうかを確認する。最終証明書が送信済みであれば、
ホストは証明書ベリファイの後に続く次の段階へ進む（ブロック６２８）。図２２および
２３に示すように、次の段階はチャレンジ・レスポンスであり、その後にセッション鍵の
作成が続いてもよい。連鎖の最終証明書が送信済みでなければ、ホストはブロック６２０
まで戻り、連鎖内の次の証明書を送信する。

図２８および図２９は、カードが認証される場合にカードとホストがとる動作を示す。
図２８に示すように、カードは開始後、連鎖の中で証明書の送信を求めるホストからの要
求を待つ（ブロック６３０、菱形６３２）。ホストから要求が届かなければ、カードは菱
形６３２へ戻る。ホストから要求が届く場合、カードは連鎖の中の次の証明書を送信する
ことになり、これは送信すべき最初の証明書から始まる（通常はルート証明書の後続証明
書から始まる）（ブロック６３４）。カードは、ホストから失敗通知が届いたかどうかを
判断する（菱形６３６）。失敗通知が届いた場合、カードは停止する（ブロック６３７）
。失敗通知が届かない場合、カードは最終証明書が送信済みかどうかを判断する（菱形６
３８）。最終証明書が送信済みでなければ、カードは菱形６３２まで戻り、連鎖内の次の
証明書の送信を求める次の要求をホストから受け取るまで待つ。最終証明書が送信済みで
あれば、カードは次の段階へ進む（ブロック６３９）。

図２９は、カードが認証される場合にホストがとる動作を示す。ホストは、連鎖内の次
の証明書を求める要求をカードへ送り、これは送信されるべき最初の証明書に対する要求
から始まる（ブロック６４０）。ホストは受信するそれぞれの証明書をベリファイし、ベ
リファイに失敗した場合はプロセスを中止し、カードに通知する（ブロック６４２）。ベ
リファイに合格した場合、ホストは最終証明書が受信済みでベリファイに成功したかどう
かをチェックする（菱形６４４）。最終証明書の受信とベリファイがまだであれば、ホス
トはブロック６４０まで戻り、連鎖内の次の証明書を求める要求を送る。最終証明書が受
信済みでベリファイに成功した場合、ホストは証明書ベリファイの後に続く次の段階へ進
む（ブロック６４６）。

証明書失効
発行された証明書はその有効期間全体にわたって使われることが予想される。しかし、
様々な事情から有効期間の満了に先立ち証明書が無効になる場合がある。名称の変更、対
象とＣＡとの関係の変化（例えば、従業員の退職）、対応する秘密鍵の侵害または侵害の
疑い等がこれにあたる。このような場合にはＣＡが証明書を無効にする必要がある。

ＳＳＡにおける証明書の失効には別の方法があり、ＡＣＲはそれぞれ別々の証明書失効
制度で構成できる。まず、失効制度をサポートしない形にＡＣＲを構成することができる
。この場合の証明書は有効期限まで有効とみなされる。証明書失効リスト（ＣＲＬ）を使
うこともできる。さらに別の代案として、後述するようにある特定のアプリケーションに
失効制度を限定する、つまりアプリケーション別にしてもよい。ＡＣＲでは、失効値を指
定することによって３通りの失効制度のどれが採用されているかを指定する。失効制度な
しで作成されたＡＣＲでは、そのＡＣＲの所有者の失効制度を採用できる。メモリ装置証
明書の失効は、ＳＳＡセキュリティシステムではなくホストによって執り行われる。ホス
トルート証明書の失効管理はＡＣＲの所有者が担当し、これはＡＣＲの信用証明を更新す
ることによって果たされる。

証明書失効リスト（ＣＲＬ）
ＳＳＡシステムで失効制度を使用するには、それぞれのＣＡが証明書失効リスト（ＣＲ
Ｌ）と呼ばれる署名済みデータ構造を定期的に発行する。ＣＲＬは失効した証明書を識別
するタイムスタンプ付きリストであり、ＣＡ（該当する証明書を発行したＣＡ）によって
署名され、一般に公開され自由に利用できる。ＣＲＬの中では、失効した証明書をそれぞ
れの証明書シリアル番号で識別する。ＣＲＬのサイズは任意なものであって、期限切れ前
に失効する証明書の数しだいで決まる。（例えば、ホストのアイデンティティをベリファ
イするため）証明書を使用する装置は、証明書の署名（ならびに有効性）をチェックする
だけでなく、ＣＲＬを通じて受け取ったシリアル番号のリストにこれを照らしてベリファ
イする。証明書の発行元にあたるＣＡから発行されるＣＲＬでその証明書の識別情報、例
えばシリアル番号が見つかる場合、これは、その証明書が失効し、もはや有効でないこと
を意味する。

証明書の有効性を検査する目的をＣＲＬで果たすには、ＣＲＬについても、これが真正
であることをベリファイする必要がある。ＣＲＬには、その発行元にあたるＣＡの秘密鍵
を使って署名し、ＣＡの公開鍵を使って署名済みＣＲＬを復号化することによってこれが
真正であることをベリファイする。復号化されたＣＲＬが無署名ＣＲＬのダイジェストに
一致する場合、そのＣＲＬに改竄がなく、真正であることを意味する。ＣＲＬのダイジェ
ストを得るためにハッシュアルゴリズムを使って頻繁にＣＲＬのハッシュ計算が行われ、
そのダイジェストはＣＡの秘密鍵で暗号化される。ＣＲＬが有効かどうかをベリファイす
るには、ＣＡの公開鍵を使って署名済みＣＲＬ（すなわち、ハッシュ化・暗号化ＣＲＬ）
を復号化して復号化・ハッシュ化ＣＲＬ（すなわち、ＣＲＬのダイジェスト）を得る。そ
して、これをハッシュ化ＣＲＬと比較する。このため、ベリファイプロセスでは、復号化
・ハッシュ化ＣＲＬとの比較のためのＣＲＬのハッシュ計算ステップを頻繁にともなうこ
とがある。

ＣＲＬ方式の一特徴として、（ＣＲＬを使った）証明書の妥当性のベリファイはＣＲＬ
の入手と分けて行うことができる。ＣＲＬも証明書の適切な発行元によって署名され、証
明書のベリファイと同様に、ＣＲＬの発行元にあたるＣＡの公開鍵を使って前述したよう
にベリファイされる。メモリ装置は署名がＣＲＬのものであることをベリファイし、さら
にＣＲＬの発行元と証明書の発行元との一致をベリファイする。ＣＲＬ方式の別の特徴と
して、ＣＲＬは証明書自体とまったく同じやり方で、具体的には信頼性のないサーバと信
頼性のない通信を通じて、配布できる。Ｘ．５０９規格ではＣＲＬとその特徴が詳述され
ている。

ＣＲＬのためのＳＳＡ基盤構造
ＳＳＡは、ＣＲＬ方式を使ったホスト失効のための基盤構造を提供する。ＣＲＬ失効制
度を採用するＲＳＡ方式ＡＣＲで認証する場合、ホストはＳｅｔ Ｃｅｒｔｉｆｉｃａｔ
ｅコマンドに対して追加のフィールドとして１つのＣＲＬ（発行元ＣＡによって無効にさ
れた証明書がない場合は空のＣＲＬ）を加える。このフィールドには、証明書の発行元に
よって署名されたＣＲＬが入る。このフィールドが存在する場合、メモリ装置１０は最初
にＳｅｔ Ｃｅｒｔｉｆｉｃａｔｅコマンドで証明書をベリファイする。ＣＲＬリポジト
リの入手とアクセスは全面的にホストが担当する。ＣＲＬが有効であり続ける期間（ＣＲ
Ｌ有効期間、すなわちＣＥＴ）もＣＲＬと併せて発行される。現在の時間がこの期間から
外れていることがベリファイ中に判明すると、そのＣＲＬには不備があるとみなされ、証
明書のベリファイに使うことはできない。その結果、証明書の認証は失敗する。

従来の証明書ベリファイ方法では、認証する側またはベリファイする側の実体が、証明
書失効リストを所有しているか、あるいはそうでないかにかかわらず、証明機関（ＣＡ）
から取り込むことができ、認証のために提示される証明書のシリアル番号をリストに照ら
してチェックし、提示された証明書が失効しているかどうかを判断することになっている
。認証またはベリファイする側の実体がメモリ装置の場合、そのメモリ装置自体が使われ
なかったら、ＣＡから証明書失効リストは取り込まれない。予め装置に記憶された証明書
失効リストが時間を経て古くなると、インストールされた日より後に失効した証明書はリ
ストに現れない。その結果、ユーザは失効した証明書を使ってその記憶装置にアクセスで
きることになる。これは望ましくない。

一実施形態において、認証を受けようとする実体が、認証の対象となる証明書と併せて
証明書失効リストを、認証する側の実体、例えばメモリ装置１０に提示するシステムによ
って前述した問題を解決できる。認証する側の実体は、受け取った証明書の真偽と証明書
失効リストの真偽をベリファイする。認証する側の実体は、失効リストで証明書の識別情
報の有無、例えば証明書のシリアル番号の有無をチェックすることにより、証明書が失効
リストに登記されているかどうかをチェックする。

前述したことを踏まえ、ホスト装置とメモリ装置１０との相互認証に非対称認証方式を
使うことができる。メモリ装置１０の認証を受けようとするホスト装置は、証明書連鎖と
対応するＣＲＬの両方を提供する必要がある。一方、ホスト装置は予めＣＡに接続してＣ
ＲＬを入手しているため、ホスト装置がメモリ装置１０を認証する場合、メモリ装置は、
証明書または証明書連鎖と併せてＣＲＬをホスト装置に提示する必要はない。

種々の内蔵または独立型ミュージックプレーヤ、ＭＰ３プレーヤ、携帯電話機、個人用
携帯情報端末（ＰＤＡ）、ノートブックコンピュータ等、近年コンテンツの再生に使える
種々の携帯型装置は増えている。証明機関から証明書失効リストへアクセスするため、そ
のような装置をワールドワイドウェブに接続することは可能であるが、多数のユーザは通
常、ウェブに毎日接続するのではなく、例えば数週間に１度、新たなコンテンツを入手し
たり契約を更新したりするときに、これを行う。そのようなユーザにとって、証明機関か
らより頻繁に証明書失効リストを入手するのは面倒な場合がある。そのようなユーザにつ
いて、証明書失効リスト、さらに必要であれば被保護コンテンツへアクセスする場合に記
憶装置に提示するホスト証明書を、好ましくは記憶装置自体の非保護領域に記憶する。多
数の記憶装置（例えば、フラッシュメモリ）で、記憶装置の非保護領域は記憶装置自体に
よって管理されるのではなくホスト装置によって管理される。これにより、ユーザはより
新しい証明書失効リストを入手するため（ホスト装置を通じて）ウェブに接続する必要が
ない。ホスト装置は記憶装置の非保護領域からそのような情報を検索し、記憶装置または
メモリ装置に証明書とリストを提示して、記憶装置の被保護コンテンツにアクセスできる
。被保護コンテンツにアクセスするための証明書とその対応する証明書失効リストは通常
であれば一定の期間にわたって有効であるため、それらが有効である限り、ユーザは最新
の証明書または証明書失効リストを入手する必要はない。このため、ユーザは、適度に長
い期間にわたって有効な証明書と証明書失効リストを容易く入手でき、最新情報を得るた
めに証明機関に接続する必要はない。

図３０および図３１のフローチャートには、前述したプロセスが示されている。図３０
に示すように、ホスト２４は、認証のためにメモリ装置に提示する証明書に付随するＣＲ
Ｌをメモリ装置１０の非保護公開領域から読み出す（ブロック６５２）。ＣＲＬはメモリ
の非保護領域に記憶されているため、ホストによるＣＲＬの入手より前に認証は必要ない
。ＣＲＬはメモリ装置の公開領域に記憶されているため、ＣＲＬの読み出しはホスト装置
２４によって管理される。そして、ホストは、ＣＲＬをベリファイの対象となる証明書と
併せてメモリ装置へ送信し（ブロック６５４）、メモリ装置１０から失敗通知を受け取ら
なければ次の段階へ進む（ブロック６５６）。図３１を参照し、メモリ装置はホストから
ＣＲＬと証明書を受信し（ブロック６５８）、ＣＲＬにおける証明書シリアル番号の有無
やその他の点（例えば、ＣＲＬが失効しているかどうか）をチェックする（ブロック６６
０）。証明書シリアル番号がＣＲＬで見つかるか、あるいはその他の理由で失敗に終わる
場合、メモリ装置はホストに失敗通知を送る（ブロック６６２）。このように同じＣＲＬ
を異なるホストの認証に使えるため、それぞれのホストはメモリ装置の公開領域に記憶さ
れたＣＲＬを入手する。前述したように、ＣＲＬを使ってベリファイする証明書もまた、
ユーザの便宜を図るため、好ましくはメモリ装置１０の非保護領域に、ＣＲＬと併せて、
記憶する。しかし、メモリ装置に対して認証する場合に証明書を使えるホストは、証明書
の発行を受けたホストのみである。

図３２に示すようにＣＲＬのフィールドに次回の更新時間が入る場合、装置１０のＳＳ
Ａは、現在の時間をこの時間に照らしてチェックし、現在の時間がこの時間を過ぎている
かどうかを確認し、過ぎている場合は認証に失敗する。つまり、ＳＳＡは好ましくは、現
在の時間（またはメモリ装置１０でＣＲＬを受信した時間）に照らしてＣＥＴをチェック
するばかりでなく次回更新の時間もチェックする。

前述したように、ＣＲＬに含まれる失効済み証明書の識別情報のリストが長くなると、
リストの処理（例えば、ハッシュ計算）と、ホストによって提示される証明書のシリアル
番号の検索とに時間を要し、処理と検索が順次に行われる場合は特に時間がかかる。この
プロセスを加速するために処理と検索とを同時に行う。また、ＣＲＬの全体を受信した後
でないとＣＲＬの処理と検索にかかれない場合にもプロセスに時間がかかる。発明者らは
、ＣＲＬの一部分を受信の時点で（その都度）処理し検索すれば、ＣＲＬの最終部分を受
信するときにはプロセスは完了間際となり、プロセスが捗ることに気づいた。

図３３および図３４は、前述した失効制度の特徴を示す。認証する側の実体（例えば、
メモリカード等のメモリ装置）では、認証を受けようとする実体から証明書とＣＲＬを受
信する（ブロック７０２）。暗号化されていないＣＲＬの一部分を処理し（例えば、ハッ
シュ化し）、それと同時に、提示された証明書の識別情報（例えば、シリアル番号）をそ
のような部分で検索する。処理された（例えば、ハッシュ化された）ＣＲＬ部分を完全な
ハッシュ化ＣＲＬに組み立て、認証を受ける側の実体から受信した部分から復号化された
ＣＲＬ部分を組み立てることによって形成される完全な復号化・ハッシュ化ＣＲＬとこれ
を比較する。一致しないことが比較で明らかになる場合、認証は失敗に終わる。また、認
証する側の実体は、現在の時間に照らしてＣＥＴと次回更新時間の両方をチェックする（
ブロック７０６、７０８）。提示された証明書の識別情報がＣＲＬに記載されていること
が判明する場合、あるいは現在の時間がＣＥＴの範囲内にない場合、あるいはＣＲＬの次
回更新時間が過ぎている場合にも、認証は失敗に終わる（ブロック７１０）。実行に際し
て、ハッシュ化ＣＲＬ部分と復号化・ハッシュ化ＣＲＬ部分を組み立てるために記憶する
場合、大量の記憶容量は必要ない場合がある。

認証を受けようとする実体（例えば、ホスト）は、その証明書とＣＲＬを認証する側の
実体へ送信し（ブロック７２２）、次の段階へ進む（ブロック７２４）。これは図３４に
示されている。
実体が認証のために証明書連鎖を提示する場合にも前述したものと同様のプロセスを実
施できる。この場合、連鎖の中の各証明書とその対応するＣＲＬにつき前述したプロセス
を繰り返すことになる。各々の証明書とそのＣＲＬを受信したらその都度処理でき、証明
書連鎖の残りの部分とその対応するＣＲＬの受信を待たずにすむ。

アイデンティティオブジェクト（ＩＤＯ）
アイデンティティオブジェクトは、フラッシュメモリカード等のメモリ装置１０がＲＳ
Ａ鍵対またはその他の暗号ＩＤを記憶するための被保護オブジェクトである。アイデンテ
ィティの署名とベリファイ、データの暗号化と復号化に使う暗号ＩＤであればどのような
タイプのものでもアイデンティティオブジェクトに入れることができる。鍵対の公開鍵が
真正であることを証明するＣＡの証明書（または複数のＣＡの証明書連鎖）もアイデンテ
ィティオブジェクトに入れる。アイデンティティオブジェクトを使えば、外部実体や内部
カード実体（すなわち、アイデンティティオブジェクトの所有者と呼ばれる装置自体、内
部のアプリケーション、その他）のアイデンティティの証拠を提出できる。したがって、
カードは、チャレンジ・レスポンス機構でホストを認証するためにＲＳＡ鍵対またはその
他のタイプの暗号ＩＤを使うのではなく、識別情報の証拠としてカードに提示されるデー
タストリームに署名する。換言すると、アイデンティティオブジェクトはその所有者の暗
号ＩＤを収容する。アイデンティティオブジェクトの中の暗号ＩＤにアクセスするにはま
ず、ホストを認証する必要がある。後述するように、この認証プロセスはＡＣＲによって
管理される。ホストの認証に成功したら、アイデンティティオブジェクトの所有者は相手
方に対して暗号ＩＤを使って自身のアイデンティティを立証できる。例えば、相手方から
ホストを通じて提示されるデータには暗号ＩＤ（例えば、公開−秘密鍵対の秘密鍵）を使
って署名できる。アイデンティティオブジェクトの署名済みデータと証明書はアイデンテ
ィティオブジェクトの所有者に代わって相手方へ提示される。証明書にある公開−秘密鍵
の公開鍵が真正であることはＣＡ（すなわち、信用機関）によって証明されるため、相手
方はこの公開鍵が真正であると信用できる。そこで相手方は証明書の公開鍵を使って署名
済みデータを復号化し、復号化されたデータを相手方によって送信されたデータと比較で
きる。復号化されたデータが相手方によって送信されたデータに一致する場合、アイデン
ティティオブジェクトの所有者は真正の秘密鍵にアクセスできる自称するとおりの実体で
あることが分かる。

アイデンティティオブジェクトの第２の用途は、暗号ＩＤ、例えばＲＳＡ鍵自体を使っ
て、ＩＤＯの所有者に指定されたデータを保護することである。このデータをＩＤＯの公
開鍵を使って暗号化する。メモリカード等のメモリ装置１０は秘密鍵を使ってデータを復
号化する。

ＩＤＯはどのようなタイプのＡＣＲでも作成できるオブジェクトである。ＡＣＲは、一
実施形態において、１つのみのＩＤＯオブジェクトを有していてもよい。データの署名と
保護はいずれも、ＡＣＲの認証を受ける実体に対してＳＳＡシステムから提供されるサー
ビスである。ＩＤＯの保護水準はＡＣＲのログイン認証方式と同じくらい高い。ＩＤＯを
有することになるＡＣＲには任意の認証アルゴリズムを選ぶことができる。ＩＤＯ運用を
良好に保護し得るアルゴリズムを評価し決定するのは作成元（ホスト）である。ＩＤＯを
有するＡＣＲは、ＩＤＯ公開鍵取得コマンドに応じて証明書連鎖を提供する。

データ保護にＩＤＯを使用する場合でも、カードから出力される復号化データにはさら
なる保護が必要になることがある。そのような場合には、いずれかの認証アルゴリズムに
よって確立されるセキュアチャネルの使用がホストに推奨される。
ＩＤＯを作成するときには鍵の長さとＰＫＣＳ＃１バージョンを選択する。一実施形態
において、ＰＫＣＳ＃１バージョン２．１が定める（指数、係数）表現を公開および秘密
鍵に使用する。
ＩＤＯの作成中に盛り込まれるデータは、一実施形態において、選択された長さを有す
るＲＳＡ鍵対と、公開鍵の信憑性を帰納的に証明する証明書連鎖である。

ＩＤＯを所有するＡＣＲはユーザデータの署名を許可する。これは２つのＳＳＡコマン
ドを使って果たす。
・Ｓｅｔ ｕｓｅｒ ｄａｔａ：署名の対象となる自由書式のデータバッファを提供す
る。
・Ｇｅｔ ＳＳＡ ｓｉｇｎａｔｕｒｅ：カードはＲＳＡ署名を提供する（ＡＣＲ秘密
鍵を使用）。署名の形式とサイズはオブジェクトのタイプに応じてＰＫＣＳ＃１バージョ
ン１．５またはＶ２．１に従い設定される。

図３５〜図３７はＩＤＯを使った操作を示すものであり、ここでメモリ装置１０はフラ
ッシュメモリカードであり、このカードがＩＤＯの所有者である。図３５は、ホストへ送
信されるデータに署名する場合にカードによって実行されるプロセスを示す。図３５を参
照し、前述したツリー構造のノードに位置するＡＣＲの管理下でホストが認証された後（
ブロック８０２）、カードは証明書を求めるホスト要求を待つ（菱形８０４）。要求を受
け取ったカードは証明書を送り、菱形８０４へ戻り、次のホスト要求を待つ（ブロック８
０６）。カードが所有するＩＤＯの公開鍵を証明するために証明書連鎖を送信する必要が
ある場合、連鎖の中のすべての証明書がホストへ送信されるまで前述した操作を繰り返す
。それぞれの証明書がホストに送信された後、カードはホストから別のコマンドが届くの
を待つ（菱形８０８）。所定の期間内にホストからコマンドが届かなければ、カードは菱
形８０４へ戻る。ホストからデータとコマンドを受け取ったカードは、そのコマンドをチ
ェックし、データに署名するためのものであるかどうかを確認する（菱形８１０）。デー
タに署名するためのコマンドである場合、カードはＩＤＯの秘密鍵を使ってデータに署名
し、署名したデータをホストへ送信し（ブロック８１２）、菱形８０４まで戻る。ホスト
からのコマンドがホストからのデータに署名するためのものでなければ、カードはＩＤＯ
の秘密鍵を使って受信データを復号化し（ブロック８１４）、菱形８０４まで戻る。

図３６は、ホストへ送信されるデータにカードが署名する場合にホストによって実行さ
れるプロセスを示す。図３６を参照すると、ホストはカードへ認証情報を送信する（ブロ
ック８２２）。前述したツリー構造のノードに位置するＡＣＲの制御下で認証に成功した
ら、ホストは証明書連鎖を求める要求をカードへ送り、連鎖を受け取る（ブロック８２４
）。カードの公開鍵のベリファイが終わったら、ホストは署名されるデータをカードへ送
信し、カードの秘密鍵で署名されたデータを受信する（ブロック８２６）。

図３７は、ホストがカードの公開鍵を使ってデータを暗号化し、暗号化したデータをカ
ードへ送信するときにホストによって実行されるプロセスを示す。図３７を参照すると、
ホストはカードへ認証情報を送信する（ブロック８６２）。ＡＣＲの管理下で認証に成功
したら、ホストはＩＤＯの中にあるカードの公開鍵をベリファイする場合に必要となる証
明書連鎖の要求をカードへ送り（ブロック８６４）、さらにデータを求める要求をカード
に送る。ＩＤＯの中にあるカードの公開鍵をベリファイした後、ホストはカードのベリフ
ァイ済み公開鍵を使ってカードから届いたデータを暗号化し、カードへ送信する（ブロッ
ク８６６、８６８）。

クエリ
ホストとアプリケーションは、システム操作をの実行する場合に相手方のメモリ装置ま
たはカードについてある種の情報を所有する必要がある。例えば、ホストとアプリケーシ
ョンは、メモリカードに記憶されたアプリケーションのうち、実行できるアプリケーショ
ンがいずれであるかを知る必要がある。ホストにとっての必要情報は公知でない場合があ
り、これはその情報を所有する権利を有する者とそうでない者があることを意味する。権
限を有するユーザと持たないユーザとを区別するには、ホストで使えるクエリを２通り用
意する必要がある。

一般情報クエリ
このクエリはシステム公開情報を無制限に放出する。メモリ装置に記憶される機密情報
は２つの部分、すなわち共有部分と非共有部分とからなる。機密情報の一部分には個々の
実体にとっての専有情報が入り、それぞれの実体は自身の専有情報に限りアクセスが認め
られ、他の実体の専有機密情報にはアクセスできない。この種の機密情報は共有されず、
機密情報の非共有部位または部分を形成する。

カードの中にあるアプリケーションの名前とそのライフサイクル状態等、通常であれば
公の情報と考えられるものでも、場合によっては機密とみなされることがある。別の例と
して、公の情報とされるルートＡＣＲ名でもＳＳＡの使用するといった場合によっては機
密になることがある。このような場合には、一般情報クエリに応じて情報をすべて認証済
みユーザに限って利用させ、認証されていないユーザには利用させないようにするための
オプションをシステムに用意しなければならない。このような情報は機密情報の共有部分
を占める。ルートＡＣＲリスト、すなわち装置上に現在存在する全ルートＡＣＲのリスト
は、機密情報の共有部分の一例となり得る。

一般情報クエリによる公開情報へアクセスする場合、ホスト／ユーザはＡＣＲにログイ
ンする必要がない。このため、ＳＳＡ規格に精通する者であれば誰でも実行可能であり、
情報を受け取ることができる。ＳＳＡの規定ではセッション番号なしでこのクエリコマン
ドが処理される。しかし、機密情報の共有部分へのアクセスを望む実体は最初に、メモリ
装置のデータに対するアクセスを制御する制御構造（例えば、ＡＣＲ）のいずれかを通じ
て認証を受ける必要がある。認証に成功した実体は、一般情報クエリを使って機密情報の
共有部分にアクセスできるようになる。前述したように、認証プロセスの結果としてアク
セスのためのＳＳＡセッション番号またはｉｄが割り当てられる。

非公開情報クエリ
個々のＡＣＲとそのシステムアクセスおよび資産に関する私的情報は非公開とされ、明
確な認証を必要とする。この種の情報クエリで許可を得るには、ＡＣＲのログインと認証
（認証がＡＣＲで指定されている場合）が事前に必要になる。このクエリにはＳＳＡセッ
ション番号が必要である。
２種類のクエリを詳述する前に、クエリを実行する現実的な解決策としてインデックス
グループの概念を説明することが有益である。

インデックスグループ
ポテンシャルＳＳＡホストで実行するアプリケーションには、読み出しの対象となるセ
クタ数を指定することがシステムドライバとホスト上のオペレーティングシステム（ＯＳ
）から求められる。これは、ホストアプリケーションがＳＳＡ読み出し操作のたびに読み
出しセクタ数を把握する必要があることを意味する。
クエリ操作で供給される情報は、一般的にはこれを要求する側にとって未知の情報であ
るため、ホストアプリケーションがクエリを発行し、その操作に必要なセクタの量を推測
するのは困難である。

この問題を解決するため、ＳＳＡのクエリ出力バッファは各クエリ要求につき１つのみ
のセクタ（５１２バイト）からなる。出力情報の一部をなすオブジェクトはインデックス
グループと呼ばれるものに編成される。オブジェクトのバイトサイズはオブジェクトのタ
イプによって異なり、そこから１セクタに収まるオブジェクトの数が明らかになる。これ
によってオブジェクトのインデックスグループが決まる。オブジェクトのサイズが２０バ
イトである場合、このオブジェクトのインデックスグループは２５オブジェクトまで収容
される。そのようなオブジェクトが全部で５６個ある場合、それらは３つのインデックス
グループに編成され、第１のインデックスグループの先頭はオブジェクト「０」（第１の
オブジェクト）となり、第２のインデックスグループの先頭はオブジェクト「２５」とな
り、第３の最終インデックスグループの先頭はオブジェクト５０となる。

システムクエリ（一般情報クエリ）
このクエリは、装置がサポートするＳＳＡシステムと、ツリー状に構成された現行のシ
ステムと、装置で実行するアプリケーションとについての一般公開情報を提供する。後述
するＡＣＲクエリ（非公開クエリ）と同様に、システムクエリは種々のクエリオプション
を提供するように構成されている。
・Ｇｅｎｅｒａｌ：サポートされたＳＳＡバージョン
・ＳＳＡ Ａｐｐｌｉｃａｔｉｏｎｓ：現在装置に存在する全ＳＳＡアプリケーション
のリストで、アプリケーションの実行状態を含む。

前述した情報は公開情報である。ＡＣＲクエリと同様に、ホストがクエリ出力バッファ
のための読み出しセクタ数を知らずにすませるため、装置からは１セクタが送り返され、
ホストが引き続きさらなるインデックスグループを照会できる。インデックスグループ「
０」でルートＡＣＲオブジェクトの数が出力バッファサイズの数を超過する場合、ホスト
は後続のインデックスグループ（「１」）で別のクエリ要求を送ることができる。

ＡＣＲクエリ（非公開情報クエリ）
ＳＳＡのＡＣＲクエリコマンドは、鍵ＩＤ、アプリケーションＩＤ、パーティション、
子ＡＣＲ等、ＡＣＲのシステムリソースに関する情報をＡＣＲユーザに供給するためのも
のである。そのクエリ情報はログインされたＡＣＲに関するもののみであり、システムツ
リー上の他のＡＣＲに関するものはない。換言すると、アクセスは、機密情報のうち、該
当するＡＣＲの許可のもとでアクセス可能な部分に限られる。
ユーザが照会できるＡＣＲオブジェクトには３通りある。
・パーティション：名前とアクセス権（所有者、読み出し、書き込み）。
・鍵ＩＤとアプリケーションＩＤ：名前とアクセス権（所有者、読み出し、書き込み）
。
・子ＡＣＲ：直接の子にあたるＡＣＲのＡＣＲおよびＡＧＰ名。
・ＩＤＯとセキュアデータオブジェクト（後述）：名前とアクセス権（所有者、読み出
し、書き込み）。

ＡＣＲに結び付いたオブジェクトの数は様々に異なる場合があり、情報は５１２バイト
、すなわち１セクタを上回ることがある。オブジェクトの数が事前に分からない限り、ユ
ーザはリストすべてを得るために装置内のＳＳＡシステムから読み出される必要があるセ
クタの数を知ることはできない。そこで前述したシステムクエリの場合と同様に、ＳＳＡ
システムによって提供される各オブジェクトリストはインデックスグループに分割される
。インデックスグループはセクタに収まるオブジェクトの数であり、例えば装置内のＳＳ
Ａシステムからホストにかけて１セクタで送信できるオブジェクトの数である。これによ
り、装置内のＳＳＡシステムは要求されたインデックスグループを１セクタで送信できる
。ホスト／ユーザは、照会したオブジェクトのバッファ、バッファ内のオブジェクト数を
受け取ることになる。バッファが一杯である場合、ユーザは次のオブジェクトインデック
スグループを照会できる。

図３８は、一般情報クエリをともなう操作を示すフローチャートである。図３８を参照
すると、実体から一般情報クエリを受け取ったＳＳＡシステムは（９０２）、その実体が
認証済みかどうかを判断する（菱形９０４）。認証済みである場合には、システムは公開
情報と機密情報の共有部分とを実体に供給する（ブロック９０６）。認証済みでなければ
、システムは公開情報のみを実体に供給する（ブロック９０８）。

図３９は、非公開情報クエリをともなう操作を示すフローチャートである。図３９を参
照すると、実体から非公開情報クエリを受け取ったＳＳＡシステムは（９２２）、その実
体が認証済みかどうかを判断する（菱形９２４）。認証済みである場合には、システムは
実体に機密情報を供給する（ブロック９２６）。認証済みでない場合には、システムは機
密情報に対する実体のアクセスを拒否する（ブロック（９２８）。

フィーチャセットエクステンション（ＦＳＥ）
多くの場合、データ処理活動（例えば、ＤＲＭライセンスオブジェクト検査）をカード
上のＳＳＡの内部で実行できることは大変有利である。その結果、データ処理タスクのす
べてをホストで実行する代替的な解決策に比べてより安全でより効率的なシステムとなり
、ホストへの依存度も低くなる。

ＳＳＡセキュリティシステムは、メモリカードによって記憶され、管理され、保護され
るオブジェクトのアクセス、使用、収集を制御する一連の認証アルゴリズムと認可方針と
を備える。アクセスを得たホストは、メモリ装置に記憶されたデータに対して処理を行い
、メモリ装置に対するアクセスはＳＳＡによって制御される。しかし、データは本質的に
用途によって大いに異なるため、装置に記憶されたデータを取り扱うわけではないＳＳＡ
ではデータ形式またはデータ処理は決まっていない。

本発明の一実施形態は、通常であればホストによって果たされる機能の一部をメモリカ
ードで実行する形にＳＳＡシステムを強化できるという認識に基づく。そこで、ホストの
ソフトウェア機能のいくつかは、２つの部分、すなわち引き続きホストによって果たされ
る部分と、カードによって果たされる部分とに分かれる場合がある。こうすることで多く
の用途にとってデータ処理の安全性と効率性が向上する。この目的のため、ＦＳＥと呼ば
れる機構を加えることによってＳＳＡの能力を高める場合がある。このようにカードによ
って実行されるＦＳＥのホストアプリケーションを、ここでは内部アプリケーションまた
は装置内部アプリケーションと呼ぶ場合がある。

強化ＳＳＡシステムは、カードの認証およびアクセス制御を提供する基本ＳＳＡコマン
ド群を、カードアプリケーションの導入により拡張する機構を提供する。カードアプリケ
ーションは、ＳＳＡ以外のサービスを（例えば、ＤＲＭスキーム、ｅコマーストランザク
ション）を実行することになっている。ＳＳＡフィーチャセットエクステンション（ＦＳ
Ｅ）は、独自開発のデータ処理ソフトウェア／ハードウェアモジュールで標準ＳＳＡセキ
ュリティシステムを強化する機構である。ＳＳＡ ＦＳＥシステムのサービスにより、ホ
スト装置は前述したクエリで得られる情報のほかに、カードで使用可能なアプリケーショ
ンを照会し、特定のアプリケーションを選択し、これと通信できる。前述した一般クエリ
と非公開クエリをこの目的に使うこともできる。

ＳＳＡ ＦＳＥでカード機能群を拡張するには２つの方法を使う。
・サービス提供：認可された実体が通信パイプと呼ばれる独自のコマンドチャネルを使
って内部アプリケーションと直に通信することによって実現する。
・ＳＳＡ標準アクセス制御方針の拡張：内部の被保護データオブジェクト（ＣＥＫ、後
述するセキュアデータオブジェクト、すなわちＳＤＯ等）に内部カードアプリケーション
を関連付けさせることによって実現する。そのようなオブジェクトにアクセスするときに
所定の標準ＳＳＡ方針が満たされる場合は関連付けアプリケーションが起動して、標準Ｓ
ＳＡ方針に加えて少なくとも１つの条件を課す。この条件は好ましくは、標準ＳＳＡ方針
とは対峙しない。この追加条件も満たされる場合に限りアクセスが許諾される。ＦＳＥの
能力をさらに詳述する前に、ＦＳＥの構造的態様と通信パイプとＳＤＯをここで取り上げ
る。

ＳＳＡモジュールと関連するモジュール
図４０Ａは、ホスト装置２４へ接続されたメモリ装置１０（フラッシュメモリカード等
）におけるシステムアーキテクチャ１０００の機能ブロック図であり、本発明の一実施形
態を例示するものである。カード２０のメモリ装置にあるソフトウェアモジュールの主要
コンポーネントは次のとおりである。

ＳＳＡトランスポート層１００２
ＳＳＡトランスポート層はカードプロトコルに依拠する。これはカード１０のプロトコ
ル層でホスト側ＳＳＡ要求（コマンド）を処理し、処理したものをＳＳＭ ＡＰＩに送る
。ホスト−カードの同期とＳＳＡコマンドの識別はすべてこのモジュールで行われる。ホ
スト２４とカード１０との間のＳＳＡデータ転送もトランスポート層がすべて担当する。

セキュアサービスモジュールコア（ＳＳＭコア）１００４
このモジュールはＳＳＡの実施例の重要部分である。ＳＳＭコアはＳＳＡアーキテクチ
ャを実装する。より具体的に、ＳＳＭコアはＳＳＡツリーと、ＡＣＲシステムと、前述し
たシステムを構成する全ルールを実行する。ＳＳＭコアモジュールは暗号ライブラリ１０
１２を使ってＳＳＡセキュリティと暗号化、復号化、ハッシュ計算等の暗号機能を支援す
る。

ＳＳＭコアＡＰＩ１００６
これは、ホストと内部アプリケーションがＳＳＭコアと連絡をとりながらＳＳＡ操作を
実行するところの層である。図４０Ａに示すように、ホスト２４と内部装置アプリケーシ
ョン１０１０はいずれも同じＡＰＩを使用する。

セキュアアプリケーション管理モジュール（ＳＡＭＭ）１００８
ＳＡＭＭはＳＳＡシステムの一部ではないが、ＳＳＡシステムと連絡をとりながら内部
装置アプリケーションを制御するカードの重要モジュールである。
実行する内部装置アプリケーションはいずれもＳＡＭＭによって管理される。
１．アプリケーションライフサイクルの監視と制御
２．アプリケーションの初期化
３．アプリケーション／ホスト／ＳＳＡインターフェイス

装置内部アプリケーション１０１０
これは、カード側での実行が許可されたアプリケーションである。ＳＡＭＭによって管
理され、ＳＳＡシステムにアクセスすることがある。ホスト側アプリケーションと内部ア
プリケーションとの間の通信パイプはＳＳＭコアから提供される。ＤＲＭアプリケーショ
ンや以降で詳述する使い捨てパスワード（ＯＴＰ）アプリケーションは内部実行アプリケ
ーションの一例である。

装置管理システム（ＤＭＳ）１０１１
これは、カードのシステムおよびアプリケーションファームウェアを更新したり、出荷
後（一般的に後発行と呼ばれる）モードでサービスを追加／削除したりするためのプロセ
スおよびプロトコルを収容するモジュールである。

図４０Ｂは、ＳＳＭコア１００４の内部ソフトウェアモジュールの機能ブロック図であ
る。図４０Ｂに示すように、コア１００４はＳＳＡコマンド処理部１０２２を含む。処理
部１０２２は、ホストまたは装置内部アプリケーション１０１０から発行されたＳＳＡコ
マンドを解析した後、ＳＳＡ管理部１０２４に引き渡す。ＡＧＰやＡＣＲ等のＳＳＡセキ
ュリティデータ構造や、すべてのＳＳＡのルールと方針はいずれもＳＳＡデータベース１
０２６に記憶される。ＳＳＡ管理部１０２４は、データベース１０２６に記憶されたＡＣ
ＲやＡＧＰやその他の制御構造によって制御を実施する。ＩＤＯやセキュアデータオブジ
ェクトをはじめとするその他のオブジェクトもＳＳＡデータベース１０２６に記憶される
。ＳＳＡ管理部１０２４は、データベース１０２６に記憶されたＡＣＲやＡＧＰやその他
の制御構造に制御を実施する。ＳＳＡが関与しない非セキュア操作はＳＳＡ非セキュア操
作モジュール１０２８によって処理される。ＳＳＡアーキテクチャのもとでのセキュア操
作はＳＳＡセキュア操作モジュール１０３０によって処理される。モジュール１０３２は
、モジュール１０３０を暗号ライブラリ１０１２へ接続するインターフェイスである。１
０３４は、モジュール１０２６および１０２８を図１のフラッシュメモリ２０へ接続する
層である。

通信（またはパススルー）パイプ
パススルーパイプオブジェクトは、ＳＳＭコアとＳＡＭＭの制御下で認可されたホスト
側実体と内部アプリケーションとの通信を可能にする。ホストと内部アプリケーションと
のデータ転送はＳＥＮＤコマンドとＲＥＣＥＩＶＥコマンドで行われる（後述）。実際の
コマンドはアプリケーションによって異なる。パイプを作る実体（ＡＣＲ）は、パイプ名
とチャネルの開通によってつながるアプリケーションのＩＤとを提供することが必要にな
る。他の被保護オブジェクトと同様に、このＡＣＲがパイプの所有者になり、標準の委譲
ルールおよび制限に従って他のＡＣＲに使用権や所有権を委譲できる。

認証済みの実体は、そのＡＣＡＭでＣＲＥＡＴＥ＿ＰＩＰＥ権限が設定されている場合
にパイプオブジェクトの作成が許可されることになる。内部アプリケーションとの通信は
、そのＰＣＲでパイプ書き込み権限またはパイプ読み出し権限が設定されている場合に限
り許可される。所有権とアクセス権の委譲は、実体がパイプの所有者か、あるいはそのＰ
ＣＲでアクセス権委譲が設定されている場合に限り許可される。他のすべての権限と同様
に、別のＡＣＲへ所有権を委譲する当初の所有者は、好ましくはこの装置アプリケーショ
ンに対するすべての権限から引き離される。

好ましくは、ある特定のアプリケーションにつき１つのみの通信パイプを作成する。第
２のパイプを作成し、接続済みのアプリケーションにそれを接続する試みは、好ましくは
ＳＳＭシステム１０００によって拒否される。したがって、好ましくは、装置内部アプリ
ケーション１０１０のいずれか１つと通信パイプとの間に１対１の関係がある。しかし、
（委譲機構により）複数のＡＣＲが１つの装置内部アプリケーションと通信する場合があ
る。（別々のアプリケーションに接続された複数パイプの委譲または所有権により）１つ
のＡＣＲが数個の装置アプリケーションと通信する場合がある。通信パイプ間のクロスト
ークをなくすため、別々のパイプを制御するＡＣＲは、好ましくは全く別個のツリーノー
ドに位置する。

ホストと特定のアプリケーションとのデータ転送は次のコマンドを使って行う。
・書き込みパススルー：ホストから装置内部アプリケーションへ非定型データバッファ
を転送する。
・読み出しパススルー：ホストから装置内部アプリケーションへ非定型データバッファ
を転送し、内部処理が完了したら非定型データバッファをホストに戻す。

書き込みパススルーコマンドと読み出しパススルーコマンドでは、ホストが通信しよう
とする相手方の装置内部アプリケーション１００８のＩＤをパラメータとして提供する。
実体の権限をベリファイし、要求される側のアプリケーションにつながるパイプを使用す
る権限が要求する側の実体（すなわち、この実体が使っているセッションを運営するＡＣ
Ｒ）にある場合、データバッファを解釈し、コマンドを実行する。この通信方法により、
ホストアプリケーションはＳＳＡＡＣＲセッションチャネルを通じて内部装置アプリケー
ションにベンダー固有／独自なコマンドを引き渡すことができる。

セキュアデータオブジェクト（ＳＤＯ）
ＳＤＯは、ＦＳＥと併せて使用できる便利なオブジェクトである。
ＳＤＯは汎用容器として機密情報を安全に記憶する役割を果たす。ＣＥＫオブジェクト
と同様に、ＳＤＯはＡＣＲが所有し、アクセス権と所有権はＡＣＲ間で委譲できる。ＳＤ
Ｏは所定の規制に従って保護され使用されるデータを収容し、オプションとして、装置内
部アプリケーション１００８へ至るリンクを有する。機密データは、好ましくはＳＳＡシ
ステムによって使用されることも解釈されることもなく、オブジェクトの所有者とユーザ
がこれを使用し、解釈する。換言すると、ＳＳＡシステムは取り扱うデータの情報を認識
しない。このため、オブジェクトの中にあるデータの所有者とユーザは、ホストとデータ
オブジェクトとの間でデータが受け渡しされるときにＳＳＡシステムとの結び付きによっ
て機密情報が失われることをさほど心配せずにすむ。ＳＤＯオブジェクトはホストシステ
ム（または内部アプリケーション）によって作成され、ＣＥＫを作成する場合と同様に、
文字列ＩＤが割り当てられる。作成する場合にホストは名前のほかに、ＳＤＯへリンクす
るアプリケーションのアプリケーションＩＤと、ＳＳＡによって記憶され、保全性ベリフ
ァイが行われ、検索されるデータブロックとを提供する。

ＳＤＯは、ＣＥＫと同様に、好ましくはＳＳＡセッションの中でのみ作成される。この
セッションを開放するために使われるＡＣＲがＳＤＯの所有者となり、ＳＤＯを削除する
権利や機密データを読み書きする権利を有するほかにも、ＳＤＯの所有権やこれにアクセ
スする権限を別のＡＣＲ（子ＡＣＲまたは同一ＡＧＰ内のＡＣＲ）に委譲する権利を有す
る。

書き込み操作と読み出し操作はＳＤＯの所有者に限定される。書き込み操作は既存のＳ
ＤＯオブジェクトデータを提示されたデータバッファで上書きする。読み出し操作はＳＤ
Ｏのデータ記録一式を検索する。

正式なアクセス権限を有する所有者以外のＡＣＲには、ＳＤＯのアクセス操作が許可さ
れる。次の操作が定められている。
・ＳＤＯ Ｓｅｔ、アプリケーションＩＤの指定：データはこのアプリケーションＩＤ
を有する内部ＳＳＡアプリケーションによって処理される。アプリケーションはＳＤＯと
の関連付けによって起動する。オプションとして、アプリケーションがＳＤＯオブジェク
トの書き込みを行う場合がある。
・ＳＤＯ Ｓｅｔ、アプリケーションＩＤの不在：このオプションは無効であり、不正
コマンドエラーを促す。Ｓｅｔコマンドにはカードで実行する内部アプリケーションが必
要となる。
・ＳＤＯ Ｇｅｔ、アプリケーションＩＤの指定：要求はこのアプリケーションＩＤを
有する装置内部アプリケーションによって処理される。アプリケーションはＳＤＯとの関
連付けによって起動する。出力は、指定がなくとも、要求する側へ送り返される。オプシ
ョンとして、アプリケーションがＳＤＯオブジェクトの読み出しを行う場合がある。
・ＳＤＯ Ｇｅｔ、アプリケーションＩＤの不在：このオプションは無効であり、不正
コマンドエラーを促す。Ｇｅｔコマンドにはカードで実行する内部アプリケーションが必
要となる。
・ＳＤＯ関連の権限：ＡＣＲにはＳＤＯの所有者になるものと、アクセス権限（Ｓｅｔ
、Ｇｅｔ、または両方）を有するのみのものとがある。ＡＣＲには、自身が所有しないＳ
ＤＯに対する自身のアクセス権を別のＡＣＲへ譲渡することが許可される。ＡＣＡＭ権限
を有するＡＣＲにはＳＤＯの作成とアクセス権の委譲が明示的に許可される。

内部ＡＣＲ
内部ＡＣＲはＰＣＲを有するＡＣＲに類似するが、装置１０にとって外部の実体はこの
ＡＣＲにログインできない。代替的に、これの管理下にあるオブジェクトか、あるいはこ
のオブジェクトと関連付けするアプリケーションが呼び出されるときに、図４０ＢのＳＳ
Ａ管理部１０２４が自動的に内部ＡＣＲにログインする。アクセスを試みる実体はカード
またはメモリ装置にとって内部の実体であるため、認証の必要はない。ＳＳＡ管理部１０
２４は内部通信を可能にするために内部ＡＣＲにセッション鍵を渡すことになる。

これより使い捨てパスワード生成とデジタル権利管理という２つの例を引いてＦＳＥの
能力を例示する。使い捨てパスワード生成の例を説明する前に、二因子認証のテーマを取
り上げる。

ＯＴＰ実施形態
二因子認証（ＤＦＡ）
ＤＦＡは、標準のユーザ信用証明（具体的にはユーザ名とパスワード）に追加の秘密、
すなわち「第２の因子」を加えることにより、ウェブサービスサーバ等への私的なログイ
ンでセキュリティを高める認証プロトコルである。この第２の秘密は通常、ユーザが所有
する物理的で安全なトークンに記憶される。ユーザはログインの過程でログイン信用証明
の一部として所有の証拠を提供する必要がある。所有の証明には使い捨てパスワード（Ｏ
ＴＰ）がよく使われ、これはセキュアトークンで生成され出力される、１回のログインの
みで通用するパスワードである。トークンなしでＯＴＰを計算するのは暗号技術的に不可
能であるため、ユーザが正しいＯＴＰを提供できる場合、これをもってトークン所有の十
分な証拠とみなされる。ＯＴＰは１回のログインのみで通用し、前のログインから得た古
いパスワードは通用しないことになるため、ユーザはログインのときにトークンを所有し
ていなければならない。

以降のセクションで説明する製品は、ＳＳＡのセキュリティデータ構造と、一連のＯＴ
Ｐで次のパスワードを計算するＦＳＥ設計とを利用しながら、フラッシュメモリでそれぞ
れ別々のパスワード系列（異なるウェブサイトへのログインに使用）を生成する複数の「
仮想」セキュアトークンを実行するものである。図４１は、このシステムのブロック図を
示す。

システム一式１０５０は、認証サーバ１０５２と、インターネットサーバ１０５４と、
トークン１０５８を有するユーザ１０５６とを備える。最初のステップでは、認証サーバ
とユーザとの間で共有秘密を取り決める（シード提供とも呼ばれる）。ユーザ１０５６は
秘密またはシードの発行を要求し、これをセキュアトークン１０５８に記憶する。次のス
テップでは、発行された秘密またはシードを特定のウェブサービスサーバに結合する。こ
れを果たしたら認証に取りかかることができる。ユーザはＯＴＰの生成をトークンに指示
する。ＯＴＰはユーザ名とパスワードと併せてインターネットサーバ１０５４へ送信され
る。インターネットサーバ１０５４は認証サーバ１０５２にＯＴＰを転送し、ユーザアイ
デンティティのベリファイを依頼する。認証サーバもＯＴＰを生成するが、これはトーク
ンとの共有秘密から生成されるため、トークンから生成されたＯＴＰに一致することにな
る。一致が判明する場合、ユーザアイデンティティはベリファイされ、認証サーバがイン
ターネットサーバ１０５４へ肯定応答を返すとユーザログインプロセスは完了することに
なる。

ＦＳＥによるＯＴＰ生成には次のような特徴がある。
・ＯＴＰシードは安全な状態で（暗号化されて）カードに記憶される。
・パスワード生成アルゴリズムはカードの内部で実行される。
・装置１０は複数の仮想トークンをエミュレートでき、それぞれの仮想トークンでは異
なるシードを記憶し、異なるパスワード生成アルゴリズムを使用できる。
・認証サーバから装置１０へシードを移すセキュアプロトコルは装置１０が提供する。

図４２は、ＳＳＡのＯＴＰシード提供機能とＯＴＰ生成機能を示すものであり、ここで
実線の矢印は所有権またはアクセス権を示し、破線の矢印は関連付けまたはリンクを示し
ている。図４２に示すように、ＳＳＡ ＦＳＥシステム１１００ではＮ個のアプリケーシ
ョンＡＣＲ１１０６によってそれぞれ管理される１つ以上の通信パイプ１１０４を通じて
ソフトウェアプログラムコードＦＳＥ１１０２にアクセスできる。後述する実施形態では
１つのみのＦＳＥソフトウェアアプリケーションを例示し、各ＦＳＥアプリケーションに
つき１つのみの通信パイプがある。しかし、複数のＦＳＥアプリケーションを使えること
が理解できる。図４２には１つのみの通信パイプが例示されているが、複数の通信パイプ
を使えることが理解できる。そのような変形例はいずれも可能である。図４０Ａ、４０Ｂ
、および４２を参照すると、ＦＳＥ１１０２はＯＴＰ提供に用いるアプリケーションであ
って、図４０Ａの装置内部アプリケーション１０１０の一部をなす場合がある。制御デー
タ構造（ＡＣＲ１１０１、１１０３、１１０６、１１１０）はＳＳＡのセキュリティデー
タ構造の一部であり、ＳＳＡデータベース１０２６に記憶される。ＩＤＯ１１２０やＳＤ
Ｏオブジェクト１１２２等のデータ構造と通信パイプ１１０４もＳＳＡデータベース１０
２６に記憶される。

図４０Ａおよび図４０Ｂを参照すると、ＡＣＲとデータ構造が関わるセキュリティ関連
操作（例えば、セッション中のデータ転送、暗号化、復号化、ハッシュ計算等の操作）は
、モジュール１０３０がインターフェイス１０３２と暗号ライブラリ１０１２の支援を受
けて処理する。ＳＳＭコアＡＰＩ１００６は、ホストと受け渡しするＡＣＲ（外部ＡＣＲ
）が関わる操作と、ホストと受け渡ししない内部ＡＣＲが関わる操作を区別しないため、
ホストが関わる操作と装置内部アプリケーション１０１０が関わる操作に区別はない。ホ
スト側実体によるアクセスと装置内部アプリケーション１０１０によるアクセスは、同じ
制御機構によって制御される。このため、ホスト側アプリケーションと装置内部アプリケ
ーション１０１０とでデータ処理を柔軟に区別できる。内部アプリケーション１０１０（
例えば、図４２のＦＳＥ１１０２）は内部ＡＣＲ（例えば、図４２のＡＣＲ１１０３）と
関連付けし、これの管理のもとで起動する。

さらに、重要情報へのアクセス、例えばＳＤＯの内容またはそのＳＤＯの内容から検索
される情報へのアクセスは、好ましくはＡＣＲやＡＧＰ等のセキュリティデータ構造とＳ
ＳＡのルールと方針とによって管理されるため、外部または内部アプリケーションは、Ｓ
ＳＡのルールと方針とに従う限りにおいてその内容または情報にアクセスできる。例えば
、２名のユーザがデータを処理するために個々の装置内部アプリケーション１０１０を起
動する場合、別々の階層ツリーに位置する内部ＡＣＲを使って２名のユーザによるアクセ
スが制御されるため、アプリケーション間のクロストークはない。両ユーザはデータ処理
する場合に共通の装置内部アプリケーション１０１０にアクセスでき、ＳＤＯの内容また
は情報の所有者の側では、内容または情報制御の喪失を心配せずにすむ。例えば、データ
を記憶するＳＤＯに対する装置内部アプリケーション１０１０によるアクセスは別々のツ
リーに位置するＡＣＲによって制御できるため、アプリケーション間のクロストークはな
い。この制御方法は、前述したデータに対するアクセスをＳＳＡが制御する方法に似てい
る。これは、データオブジェクトに記憶されたデータのセキュリティを内容の所有者とユ
ーザに提供する。

図４２を参照すると、ＯＴＰ関連ホストアプリケーションに必要なソフトウェアアプリ
ケーションコードの一部分を、ＦＳＥ１１０２のアプリケーションとしてメモリ装置１０
に記憶（メモリカード発行前に予め記憶、またはメモリカード発行後にロード）すること
は可能である。そのようなコードを実行する場合、ホストはまずＮ個の認証ＡＣＲ１１０
６のいずれか１つを通じて認証を受け、パイプ１１０４にアクセスする必要があり、Ｎは
正の整数である。ホストは、起動しようとするＯＴＰ関連アプリケーションを識別するた
めのアプリケーションＩＤを提供する必要もある。認証に成功したら、ＯＴＰ関連アプリ
ケーションと関連付けられたパイプ１１０４を通じてそのようなコードにアクセスし、実
行できる。前述したように、パイプ１１０４と、ＯＴＰ関連内部アプリケーション等のア
プリケーションとの間には、好ましくは１対１の関係がある。図４２に示すように、複数
のＡＣＲ１１０６が共通のパイプ１１０４を制御することがある。１つのＡＣＲで複数の
パイプを制御する場合がある。

図４２には、データ、例えばＯＴＰ生成のためのシードをそれぞれ収容するオブジェク
ト１１１４と総称するセキュアデータオブジェクトＳＤＯ１、ＳＤＯ２、およびＳＤＯ３
が示され、このシードは貴重であって、好ましくは暗号化する。３つのデータオブジェク
トとＦＳＥ１１０２との間のリンクまたは関連付け１１０８はこれらのオブジェクトの一
属性であり、いずれか１つのオブジェクトにアクセスするときには、アプリケーションＩ
ＤがＳＤＯ属性に一致するＦＳＥ１１０２のアプリケーションが起動し、このアプリケー
ションは装置のＣＰＵ１２によって実行され、さらなるホストコマンドを受け取る必要は
ない（図１）。

図４２を参照すると、ＯＴＰプロセスを制御するためのセキュリティデータ構造（ＡＣ
Ｒ１１０１、１１０３、１１０６、および１１１０）とそのＰＣＲは、ユーザがＯＴＰプ
ロセスを開始する前に作成済みである。ユーザは、認証サーバＡＣＲ１１０６のいずれか
１つを通じてＯＴＰ装置内部アプリケーション１１０２を起動するためのアクセス権を得
る必要がある。ユーザは、Ｎ個のユーザＡＣＲ１１１０のいずれか１つを通じてＯＴＰに
対するアクセス権を得る必要もある。ＳＤＯ１１１４はＯＴＰのシード提供過程で作成で
きる。ＩＤＯ１１１６は、好ましくは作成済みで内部ＡＣＲ１１０３によって制御される
。内部ＡＣＲ１１０３は、作成されたＳＤＯ１１１４も制御する。ＳＤＯ１１１４にアク
セスするときには、図４０ＢのＳＳＡ管理部１０２４が自動的にＡＣＲ１１０３にログイ
ンする。内部ＡＣＲ１１０３にはＦＳＥ１１０２が関連付けられる。破線１１０８に示す
ように、ＯＴＰのシード提供過程ではＳＤＯ１１１４にＦＳＥを関連付けさせる。関連付
けが成立した後、ホストがＳＤＯにアクセスするときには、ホストからさらなる要求がな
くとも関連付け１１０８によってＦＳＥ１１０２が起動する。Ｎ個のＡＣＲ１１０６のい
ずれか１つを通じて通信パイプ１１０４にアクセスするときにも、図４０ＢのＳＳＡ管理
部１０２４がＡＣＲ１１０３に自動的にログインする。いずれの場合でも（ＳＤＯ１１１
４とパイプ１１０４へのアクセス）、ＳＳＡ管理部はＦＳＥ１１０２にセッション番号を
渡し、このセッション番号によって内部ＡＣＲ１１０３に至るチャネルが識別される。

ＯＴＰ操作は２つの段階、すなわち図４３に示すシード提供段階と図４４に示すＯＴＰ
生成段階とを伴う。図４０〜図４２も併せて参照することで、この説明に役立つ。図４３
はシード提供プロセスを示すプロトコル図である。図４３に示すように、ホスト２４等の
ホストとカードは様々な動作をとる。ＳＳＭコア１００４を含む図４０Ａおよび４０Ｂの
ＳＳＭシステムは、カード側で様々な動作をとる１実体である。図４２に示すＦＳＥ１１
０２もカード側で様々な動作をとる実体である。

二因子認証ではユーザがシードの発行を要求し、発行されたシードはセキュアトークン
に記憶される。この例のセキュアトークンはメモリ装置またはカードである。ユーザはＳ
ＳＭシステムにアクセスするため、図４２の認証ＡＣＲ１１０６のいずれか１つで認証を
受ける（矢印１１２２）。認証に成功したと仮定し（矢印１１２４）、ユーザはシードを
要求する（矢印１１２６）。ホストは、シード要求に署名するためのアプリケーション１
１０２を選択してシード要求に署名する要求をカードへ送る。起動すべきアプリケーショ
ンＩＤをユーザが知らない場合、例えば装置に対する非公開クエリにより、この情報を装
置１０から入手できる。そして、ユーザは起動するべきアプリケーションのアプリケーシ
ョンＩＤを入力し、これによりこのアプリケーションに対応する通信パイプも選択される
。パススルーコマンドにより、ユーザから該当する通信パイプを通じてアプリケーション
ＩＤで指定されたアプリケーションにかけて、ユーザコマンドが転送される（矢印１１２
８）。起動したアプリケーションは、図４２のＩＤＯ１１１２等の所定のＩＤＯの公開鍵
による署名を要求する。

ＳＳＭシステムはＩＤＯの公開鍵を用いてシード要求に署名し、署名の完了をアプリケ
ーションに通知する（矢印１１３２）。次に、起動アプリケーションはＩＤＯの証明書連
鎖を要求する（矢印１１３４）。これに応じて、ＳＳＭシステムは、ＡＣＲ１１０３の制
御下でＩＤＯの証明書連鎖を提供する。起動アプリケーションは通信パイプを通じて署名
済みシード要求とＩＤＯの証明書連鎖をＳＳＭシステムへ提供し、ＳＳＭシステムは同じ
ものをホストへ転送する（矢印１１３８）。通信パイプにおける署名済みシード要求とＩ
ＤＯ証明書連鎖の送信は、図４０ＡのＳＡＭＭ１００８とＳＳＭコア１００４との間で確
立するコールバック関数によって行われるが、このコールバック関数については以降で詳
述する。

ホストが受け取った署名済みシード要求とＩＤＯ証明書連鎖は、図４１に示す認証サー
バ１０５２へ送信される。署名済みシード要求の出所が信用できるトークンであることは
カードから提供される証明書連鎖で証明されているため、認証サーバ１０５２には秘密シ
ードをカードに提供する用意がある。そこで認証サーバ１０５２は、ＩＤＯの公開鍵で暗
号化されたシードをユーザＡＣＲ情報と併せてホストに送信する。このユーザ情報により
、Ｎ個のユーザＡＣＲのうち、これから生成するＯＴＰにユーザがアクセスするためのユ
ーザＡＣＲがいずれであるのかが明らかになる。ホストはアプリケーションＩＤを提供す
ることによってＦＳＥ１１０２でＯＴＰアプリケーションを起動し、これによりこのアプ
リケーションに対応する通信パイプも選択され、さらにホストはユーザＡＣＲ情報をＳＳ
Ｍシステムへ転送する（矢印１１４０）。暗号化されたシードとユーザＡＣＲ情報は通信
パイプを通じて選択されたアプリケーションへ転送される（矢印１１４２）。起動したア
プリケーションは、ＩＤＯの秘密鍵を使ってシードを復号化する要求をＳＳＭシステムに
送る（矢印１１４４）。ＳＳＭシステムはシードを復号化し、復号化の完了を伝える通知
をアプリケーションに送る（矢印１１４６）。起動アプリケーションは、セキュアデータ
オブジェクトを作成し、そのセキュアデータオブジェクトにシードを記憶することを要求
する。起動アプリケーションは、使い捨てパスワードを生成するため、そのＳＤＯにＯＴ
Ｐアプリケーション（要求するアプリケーションと同じアプリケーションであってもよい
）のＩＤを割り振ることも要求する。ＳＳＭシステムはＳＤＯ１１１４のいずれか１つを
作成し、そのＳＤＯの中にシードを記憶し、ＯＴＰアプリケーションのＩＤをＳＤＯに割
り振り、完了したらアプリケーションに通知を送る（矢印１１５０）。アプリケーション
は、ホストから提供されたユーザ情報に基づきＳＤＯ１１１４にアクセスするためのアク
セス権を内部ＡＣＲから該当するユーザＡＣＲへ委譲することをＳＳＭシステムに要求す
る（矢印１１５２）。委譲が完了したらＳＳＭシステムはアプリケーションに通知する（
矢印１１５４）。アプリケーションは、コールバック関数によりＳＤＯの名前（スロット
ＩＤ）を通信パイプ経由でＳＳＭシステムへ送信する（矢印１１５６）。ＳＳＭシステム
は同じものをホストへ転送する（矢印１１５８）。ホストはＳＤＯの名前をユーザＡＣＲ
に結合し、このため、ユーザはＳＤＯにアクセスできるようになる。

今度は図４４のプロトコル図を参照しながらＯＴＰ生成プロセスを説明する。ユーザは
使い捨てパスワードを入手するため、アクセス権があるユーザＡＣＲにログインする（矢
印１１７２）。認証に成功したと仮定し、ＳＳＭシステムはホストに通知し、ホストは「
ｇｅｔ ＳＤＯ」コマンドをＳＳＭへ送信する（矢印１１７４、１１７６）。前述したよ
うに、シードを記憶するＳＤＯにはＯＴＰを生成するアプリケーションが関連付けられて
いる。したがって、これまでのように通信パイプ経由でアプリケーションを選択する代わ
りに、矢印１１７６のコマンドでアクセスするＳＤＯとＯＴＰ生成アプリケーションとの
関連付けによってＯＴＰ生成アプリケーションを起動する（矢印１１７８）。ＯＴＰ生成
アプリケーションは、ＳＤＯから内容（すなわち、シード）を読み出すことをＳＳＭシス
テムに要求する。好ましくは、ＳＳＭはＳＤＯの内容に含まれる情報を認識せず、ＦＳＥ
の指示に従ってＳＤＯのデータを処理するに過ぎない。シードが暗号化されている場合、
ＦＳＥの指示に従い読み出しを行う前にシードを復号化することが必要となる場合がある
。ＳＳＭシステムはＳＤＯからシードを読み出し、ＯＴＰ生成アプリケーションへシード
を提供する（矢印１１８２）。ＯＴＰ生成アプリケーションはＯＴＰを生成し、これをＳ
ＳＭシステムに提供する（矢印１１８４）。ＯＴＰはＳＳＭによってホストへ転送され（
矢印１１８６）、さらにホストから認証サーバ１０５２へＯＴＰが転送され、二因子認証
プロセスは完了する。

コールバック関数
図４０ＡのＳＳＭコア１００４とＳＡＭＭ１００８との間では汎用コールバック関数を
確立する。そのような関数には様々な装置内部アプリケーションと通信パイプを登録でき
る。起動した装置内部アプリケーションはこのコールバック関数を使用することにより、
アプリケーションへのホストコマンドの引き渡しに使われたものと同じ通信パイプを使っ
て処理後のデータをＳＳＭシステムへ引き渡すことができる。

ＤＲＭシステム実施形態
図４５はＤＲＭシステムを示す機能ブロック図であり、このシステムでは通信パイプ１
１０４’と、ＦＳＥアプリケーション１１０２’に至るリンク１１０８’を備えるＣＥＫ
１１１４’と、ＤＲＭ機能の実行機能を制御する制御構造１１０１’、１１０３’、１１
０６’とを使用する。見て分かるように、図４５のアーキテクチャはセキュリティデータ
構造として認証サーバＡＣＲとユーザＡＣＲの代わりにライセンスサーバＡＣＲ１１０６
’と再生ＡＣＲ１１１０’とを含み、さらにＳＤＯの代わりにＣＥＫ１１１４’を含む点
を除き、図４２のものによく似ている。加えて、ＩＤＯは関係しないから図４５で省かれ
ている。ＣＥＫ１１１４’はライセンス提供プロセスの中で作成できる。プロトコル図で
ある図４６はライセンス提供とコンテンツダウンロードのプロセスを示すものであり、こ
こではライセンスオブジェクトの中で鍵が提供される。ＯＴＰの実施例と同様に、ライセ
ンスの取得を望むユーザはまず、Ｎ個のＡＣＲ１１０６’のいずれか１つとＮ個のＡＣＲ
１１１０’のいずれか１つのもとでアクセス権を取得する必要があり、そうすることでメ
ディアプレーヤソフトウェアアプリケーション等のメディアプレーヤでコンテンツを再生
できるようになる。

図４６に示すように、ホストはライセンスサーバＡＣＲ１１０６’による認証を受ける
（矢印１２０２）。認証に成功したと仮定し（矢印１２０４）、ライセンスサーバはライ
センスファイルをＣＥＫ（鍵ＩＤと鍵値）と併せてホストに提供する。ホストは、カード
上のＳＳＭシステムにアプリケーションＩＤを提供することによって起動すべきアプリケ
ーションも選択する。ホストは、プレーヤ情報（例えば、メディアプレーヤーソフトウェ
アアプリケーションの情報）も送信する（矢印１２０６）。このプレーヤ情報により、Ｎ
個の再生ＡＣＲ１１１０’のうち、プレーヤのアクセス権がある再生ＡＣＲがいずれであ
るのかが明らかになる。ＳＳＭシステムは、選択されたアプリケーションに対応する通信
パイプを通じてライセンスファイルとＣＥＫをＤＲＭアプリケーションへ転送する（矢印
１２０８）。起動したアプリケーションは、ライセンスファイルを非表示パーティション
に書き込むことをＳＳＭシステムに要求する（矢印１２１０）。ライセンスファイルがそ
のとおりに書き込まれたら、ＳＳＭシステムはアプリケーションに通知する（矢印１２１
２）。ＤＲＭアプリケーションはＣＥＫオブジェクト１１１４’の作成を要求し、ライセ
ンスファイルからその中に鍵値を記憶する。ＤＲＭアプリケーションは、提供された鍵に
関連するライセンスをチェックするＤＲＭアプリケーションのＩＤをＣＥＫオブジェクト
に割り振ることも要求する（矢印１２１４）。ＳＳＭシステムはこれらのタスクを完了し
、その旨をアプリケーションに通知する（矢印１２１６）。アプリケーションは、ホスト
から送信されたプレーヤ情報に基づきＣＥＫ１１１４’に対するコンテンツの読み出しア
クセス権をプレーヤがアクセスできる再生ＡＣＲへ委譲することを要求する（矢印１２１
８）。ＳＳＭシステムは委譲を行い、その旨をアプリケーションに通知する（矢印１２２
０）。ライセンスの記憶が完了したことを伝えるメッセージがアプリケーションから通信
パイプを経由しＳＳＭシステムへ送信され、ＳＳＭシステムはこれをライセンスサーバへ
転送する（矢印１２２２および１２２４）。通信パイプ経由のこの操作にはコールバック
関数を使用する。この通知を受けたライセンスサーバは、提供されたＣＥＫの鍵値によっ
て暗号化されたコンテンツファイルをカードに提供する。暗号化されたコンテンツはホス
トによってカードの公開領域に記憶される。暗号化されたコンテンツファイルの記憶にセ
キュリティ機能は関与しないため、ＳＳＭシステムは記憶に関与しない。

図４７は、再生操作を示す。ユーザはホストを通じて該当する再生ＡＣＲ（すなわち、
前述した矢印１１５２および１１５４で読み出し権を委譲された再生ＡＣＲ）による認証
を受ける（矢印１２４２）。認証に成功したと仮定し（矢印１２４４）、ユーザは鍵ＩＤ
と関連付けられたコンテンツの読み出し要求を送る（矢印１２４６）。要求を受け取った
ＳＳＭシステムは、アクセスされているＤＲＭアプリケーションのＩＤがＣＥＫオブジェ
クトに関連付けられていることに気づき、識別されたＤＲＭアプリケーションを起動する
（矢印１２４８）。このＤＲＭアプリケーションは、鍵ＩＤと関連付けられたデータ（す
なわち、ライセンス）の読み出しをＳＳＭシステムに要求する（矢印１２５０）。読み出
し要求があったデータの情報を認識しないＳＳＭは、ＦＳＥからの要求を処理してデータ
の読み出しプロセスを実行するに過ぎない。ＳＳＭシステムは非表示パーティションから
データ（すなわち、ライセンス）を読み出し、そのデータをＤＲＭアプリケーションに提
供する（矢印１２５２）。ＤＲＭアプリケーションはデータを解釈し、データの中にある
ライセンス情報をチェックして、ライセンスが有効かどうかを確認する。ライセンスがな
お有効である場合、ＤＲＭアプリケーションはコンテンツの復号化が許可されることをＳ
ＳＭシステムに知らせる（矢印１２５４）。ＳＳＭシステムは要求のあったコンテンツを
ＣＥＫオブジェクトの鍵値を使って復号化し、復号化されたコンテンツを再生するために
ホストに提供する（矢印１２５６）。ライセンスがすでに有効でない場合、コンテンツア
クセスの要求は拒否される。

ライセンスサーバからのライセンスファイルで鍵が提供されない場合のライセンス提供
とコンテンツのダウンロードは、図４６に示す場合といくぶん異なる。図４８のプロトコ
ル図はそのような別方式を示す。図４６および図４８で同じステップは同じ数字で識別さ
れている。このため、ホストとＳＳＭシステムはまず初めに認証に取り組む（矢印１２０
２、１２０４）。ライセンスサーバはホストにライセンスファイルと鍵ＩＤを提供するが
鍵値は提供せず、ホストはそれらを、起動しようとするＤＲＭアプリケーションのアプリ
ケーションＩＤと併せて、ＳＳＭシステムへ転送する。ホストはプレーヤ情報も送信する
（矢印１２０６’）。ＳＳＭシステムは、選択されたアプリケーションに対応する通信パ
イプを通じて選択されたＤＲＭアプリケーションへライセンスファイルと鍵ＩＤを転送す
る（矢印１２０８）。ＤＲＭアプリケーションは、非表示パーティションへのライセンス
ファイル書き込みを要求する（矢印１２１０）。ライセンスファイルがそのとおりに書き
込まれたら、ＳＳＭシステムはＤＲＭアプリケーションに通知する（矢印１２１２）。Ｄ
ＲＭアプリケーションは、鍵値を生成することと、ＣＥＫオブジェクトを作成することと
、そこに鍵値を記憶することと、ＣＥＫオブジェクトにＤＲＭアプリケーションのＩＤを
割り振ることとをＳＳＭシステムに要求する（矢印１２１４’）。要求に応じたＳＳＭシ
ステムはＤＲＭアプリケーションへ通知を送る（矢印１２１６）。ＤＲＭアプリケーショ
ンは、ホストからのプレーヤ情報に基づきＣＥＫオブジェクトに対する読み出しアクセス
権を再生ＡＣＲに委譲することをＳＳＭシステムに要求する（矢印１２１８）。これが完
了すると、ＳＳＭシステムはその旨をＤＲＭアプリケーションに通知する（矢印１２２０
）。ＤＲＭアプリケーションはライセンスが記憶されたことをＳＳＭシステムに通知する
が、この通知はコールバック関数により通信パイプ経由で送信される（矢印１２２２）。
通知はＳＳＭシステムによってライセンスサーバへ転送される（矢印１２２４）。ライセ
ンスサーバは鍵ＩＤと関連付けられたコンテンツファイルをＳＳＭシステムへ送信する（
矢印１２２６）。ＳＳＭシステムは鍵ＩＤによって識別された鍵値でコンテンツファイル
を暗号化するが、アプリケーションはこれに一切関与しない。暗号化されカードに記憶さ
れたコンテンツは、図４７のプロトコルを用いて再生できる。

前述したＯＴＰ実施形態とＤＲＭ実施形態で、ホスト装置は様々なＯＴＰアプリケーシ
ョンとＤＲＭアプリケーションをＦＳＥ１１０２および１１０２’で選ぶことができる。
ユーザは所望の装置内部アプリケーションを選択し、起動できる。しかし、ＳＳＭモジュ
ールとＦＳＥとの全体的関係は常に同じであるため、ユーザとデータの提供者はＳＳＭモ
ジュールとの受け渡しやＦＳＥを起動する場合に標準のプロトコル群を使用することがで
きる。ユーザと提供者は、独自に開発されたものを含む様々な装置内部アプリケーション
の詳細に関わる必要はない。

さらに、図４６および図４８がそうであるように、提供プロトコルはいくぶん異なるこ
とがある。図４６の場合、ライセンスオブジェクトは鍵値を収容するが、図４８の場合は
鍵値を収容しない。このような違いから、前述したような若干異なるプロトコルが必要と
なる。しかし、図４７における再生は、ライセンス提供のあり方にかかわりなく同じであ
る。したがって、この違いが問題となるのは通常であればコンテンツの提供者と配布者の
みであって、再生段階にしか通常かかわらない消費者には関係ない。このアーキテクチャ
は、プロトコルのカスタマイズする場合にコンテンツの提供者や配布者に多大な柔軟性を
提供しつつ、消費者にとっては扱いやすい状態のままである。当然、３つ以上の提供プロ
トコル群によって提供されるデータから検索される情報でも、第２のプロトコルを用いて
アクセスできる。

前述した実施形態から提供される別の利点として、ユーザ等の外部実体と装置内部アプ
リケーションはいずれもセキュリティデータ構造によって制御されるデータを利用するが
、ユーザがアクセスできるものは装置内部アプリケーションによって記憶データから検索
される結果のみである。ＯＴＰ実施形態の場合、ホスト装置を通じてユーザが入手できる
ものはＯＴＰのみであって、シード値は入手できない。ＤＲＭ実施形態の場合、ホスト装
置を通じてユーザが入手できるものは再生されたコンテンツのみであって、ライセンスフ
ァイルまたは暗号鍵のいずれにもアクセスできない。このため、セキュリティを損なうこ
となく消費者の便宜を図ることができる。

ＤＲＭの一実施形態において、装置内部アプリケーションもホストも暗号鍵にアクセス
せず、セキュリティデータ構造のみがこれにアクセスする。別の実施形態において、セキ
ュリティデータ構造以外の実体も暗号鍵にアクセスできる。鍵が装置内部アプリケーショ
ンによって生成され、セキュリティデータ構造によって制御される場合もある。

装置内部アプリケーションと情報（例えば、ＯＴＰや再生コンテンツ）へのアクセスは
同じセキュリティデータ構造によって制御される。これは、制御システムの複雑さとコス
トを抑える。
装置内部アプリケーションに対するアクセスを制御する内部ＡＣＲから、装置内部アプ
リケーションを起動することによって得られる情報に対するホストのアクセスを制御する
ＡＣＲへ、アクセス権を委譲する能力を提供することにより、前述した特徴および機能が
実現可能となる。

アプリケーション別失効制度
セキュリティデータ構造のアクセス制御プロトコルは装置内部アプリケーションの起動
時に修正することもできる。例えば、証明書失効プロトコルには、ＣＲＬを使用する標準
のプロトコルまたは独自のプロトコルのいずれでもよい。そこで、ＦＳＥを起動すること
により、標準のＣＲＬ失効プロトコルをＦＳＥ独自プロトコルに差し替えることができる
。

ＳＳＡはＣＲＬ失効制度をサポートするほか、装置内部アプリケーションとＣＡ、ある
いはその他の取消機関との私的通信チャネルを通じて装置の内部アプリケーションからホ
ストを無効にすることができる。内部アプリケーション独自の失効制度はホスト−アプリ
ケーションの関係に限定される。

アプリケーション別失効制度が構成される場合、ＳＳＡシステムはＣＲＬ（提供される
場合）を拒絶することになり、そうでない場合には証明書と独自のアプリケーションデー
タ（アプリケーション別通信パイプを通じて提供済みのデータ）を用いて証明書が失効済
みか否かを判断する。

前述したように、ＡＣＲでは失効値を指定することによって３通りの失効制度（失効制
度なし、標準ＣＲＬ制度、アプリケーション別失効制度）のどれを採用するかを指定する
。アプリケーション別失効制度を選ぶ場合、その失効制度を担当する内部アプリケーショ
ンＩＤもＡＣＲで指定し、ＣＥＴ／ＡＰＰ＿ＩＤフィールドの値は失効制度を担当する内
部アプリケーションＩＤに一致することになる。装置を認証する場合、ＳＳＡシステムは
内部アプリケーション独自の制度に準拠する。

１組のプロトコルを別のものに差し替える代わりに、装置内部アプリケーションを起動
する場合、ＳＳＡによって既に施行されているアクセス制御に追加のアクセス条件を設け
ることもできる。例えば、ＣＥＫの鍵値に対するアクセス権をＦＳＥでより綿密に調べる
ことができる。鍵値のアクセス権がＡＣＲにあると判断したＳＳＡシステムは、ＦＳＥと
相談のうえでアクセスを許諾する。これは、コンテンツへのアクセスを制御する場合にコ
ンテンツの所有者に多大な柔軟性を提供する。

これまで様々な実施形態を参照しながら本発明を説明してきたが、本発明の範囲から逸
脱することなく変更や修正を施すことができ、本発明の範囲が専ら添付の特許請求の範囲
とその同等物とによって定まるものであることが理解できよう。

Claims (23)

1. 実体を記憶装置によって認証する方法であって、
   実体と通信する記憶装置で、
   記憶装置に対して実体を認証するため、複数の証明書を有し、実体の証明書で終わる
   証明書連鎖を実体から受信し、
   複数の証明書をベリファイし、
   複数の証明書のうちの最初の証明書を記憶装置に蓄積されたルート証明書と照らして
   ベリファイし、
   連鎖内の他の全ての証明書を連鎖からの他の証明書を用いてベリファイし、
   複数の証明書のうちの最後の証明書がベリファイされたか否かを検出し、かつ
   複数の証明書のうちの最後の証明書がベリファイされたならば、その最後の証明書を
   用いて記憶装置に対してホストを認証することが実行されることを含む方法。
2. 請求項１記載の方法において、
   複数の証明書のうちの最後の証明書は、これが最後の証明書であることの指示を収容す
   るメッセージの中で受信され、前記検出することは、前記指示をチェックすることによっ
   て実行される方法。
3. 請求項１記載の方法において、
   実体および記憶装置は、互いに取り外し可能な状態で接続される方法。
4. 請求項１記載の方法において、
   最後の証明書の受信後を除く各証明書の受信後に、複数の証明書のうちの次の証明書を
   求める要求を実体へ送信することをさらに含む方法。
5. 請求項４記載の方法において、
   各要求に応じて、次の証明書を前記実体から受信することをさらに含む方法。
6. 請求項１記載の方法において、
   実体は、取り外し可能な状態で記憶装置へ接続されるホスト装置を備える方法。
7. 請求項１記載の方法において、
   記憶装置は、メモリカードを備える方法。
8. 請求項１記載の方法において、
   複数の証明書のうちの最初の証明書を除き、事前に蓄積された証明書を上書きすること
   によって、一度に一つずつ複数の証明書を記憶装置に蓄積することをさらに含む方法。
9. 請求項８記載の方法において、
   記憶装置で複数の証明書のうちのもっとも大きい証明書を蓄積するのに必要なメモリ空
   間よりも多くのメモリ空間は割り当てないことをさらに含む方法。
10. 請求項１記載の方法において、
    前記実体は、記憶装置と通信するホスト装置上で実行されるソフトウェアアプリケーシ
    ョンである方法。
11. 請求項１記載の方法において、
    前記実体は、記憶装置と通信するホスト装置に接続された遠隔サーバ上で実行されるソ
    フトウェアアプリケーションである方法。
12. 請求項１記載の方法において、
    前記実体は、記憶装置と通信するホスト装置に接続された周辺装置上で実行されるソフ
    トウェアアプリケーションである方法。
13. 請求項１記載の方法において、
    前記実体は、記憶装置と通信するホスト装置である方法。
14. 請求項１記載の方法において、
    第２の証明書から開始する各証明書は、直前に受信した証明書と照らしてベリファイさ
    れる方法。
15. 記憶装置であって、
    ルート証明書を蓄積するメモリと、
    メモリと通信するコントローラであって、
    記憶装置に対して実体を認証するため、複数の証明書を有し、実体の証明書で終わる
    証明書連鎖を実体から受信し、
    複数の証明書をベリファイし、
    複数の証明書のうちの最初の証明書をメモリに蓄積されたルート証明書に照らしてベ
    リファイし、
    連鎖内の他の全ての証明書を連鎖からの他の証明書を用いてベリファイし、
    複数の証明書のうちの最後の証明書がベリファイされたか否かを検出し、かつ
    複数の証明書のうちの最後の証明書がベリファイされたならば、その最後の証明書を
    用いて記憶装置に対してホストを認証するように操作されるコントローラと、
    を備える記憶装置。
16. 請求項１５記載の記憶装置において、
    複数の証明書のうちの最後の証明書は、これが最後の証明書であることの指示を収容す
    るメッセージの中で受信され、前記コントローラは、前記指示をチェックすることによっ
    て複数の証明書のうちの最後の証明書がベリファイされたか否かを検出するように操作さ
    れる記憶装置。
17. 請求項１５記載の記憶装置において、
    実体および記憶装置は、互いに取り外し可能な状態で接続される記憶装置。
18. 請求項１５記載の記憶装置において、
    前記コントローラは、最後の証明書の受信後を除く各証明書の受信後に、複数の証明書
    のうちの次の証明書を求める要求を実体へ送信するように操作される記憶装置。
19. 請求項１８記載の記憶装置において、
    前記コントローラは、各要求に応じて、次の証明書を実体から受信するように操作され
    る記憶装置。
20. 請求項１５記載の記憶装置において、
    実体は、取り外し可能な状態で記憶装置へ接続されるホスト装置を備える記憶装置。
21. 請求項２０記載の記憶装置において、
    記憶装置は、メモリカードを備える記憶装置。
22. 請求項１５記載の記憶装置において、
    前記コントローラは、複数の証明書のうちの最初の証明書を除き、事前に蓄積された証
    明書を上書きすることによって、一度に一つずつ複数の証明書のそれぞれをメモリに蓄積
    するように操作される記憶装置。
23. 請求項２２記載の記憶装置において、
    前記コントローラは、メモリで複数の証明書のうちのもっとも大きい証明書を蓄積する
    のに必要なメモリ空間よりも多くのメモリ空間は割り当てないように操作される記憶装置
    。