(57)【要約】  ホスト装置は、メモリ装置自体がリストを入手する必要がないように、ホスト証明書および関係証明書失効リストの両方を認証のためにメモリ装置に提示する。証明書失効リストの処理と証明書識別情報の検索は、メモリ装置によって同時に実施されてよい。ホスト装置からメモリ装置への認証を行う証明書失効リストは、メモリ装置がホスト証明書を受信する前にキャッシュされて認められる。【選択図】図５０
2013514587.tif 000002
【特許請求の範囲】
【請求項１】
証明書が失効とされるかどうかを判定する方法であって、
不揮発性記憶装置が動作可能にホストに接続されている間に、不揮発性記憶装置で実行され、
（ａ）前記ホストの前記不揮発性記憶装置への認証を試行するために、前記ホストから証明書を受信するステップと、
（ｂ）前記不揮発性記憶装置にキャッシュされた証明書失効リスト内を、証明書についてのリファレンスを検索することによって、証明書が失効とされるかどうかを判定するステップと、
を備え、
前記ホストの前記不揮発性記憶装置への認証を試行するための前記証明書を前記不揮発性記憶装置が受信する前に、前記証明書失効リストはキャッシュされて最新の状態にされる、方法。
【請求項２】
前記検索によって前記証明書失効リスト内から証明書についてのリファレンスが取得される場合に、前記ホストを認証するための前記試行を拒絶するステップをさらに備える、請求項１に記載の方法。
【請求項３】
前記ホストから証明書失効リストを受信するステップ、をさらに備え、
前記ホストから受信した前記証明書失効リストが前記不揮発性記憶装置内の現在の証明書失効リストよりも新しく、前記受信した証明書失効リストが前記証明書の発行者によって発行されたと判定されることによって前記ホストから受信した前記証明書失効リストが検証される場合に、（ｂ）のステップを実行する代わりに、
前記現在の証明書失効リストを前記新しい証明書失効リストに置換するステップと、
前記ホストからの前記証明書が失効とされるかどうか判定するために、前記新しい証明書失効リストを使用するステップと、を実行する、請求項１に記載の方法。
【請求項４】
前記不揮発性記憶装置の製造時に、前記証明書失効リストが前記不揮発性記憶装置に記憶される、請求項１に記載の方法。
【請求項５】
前記証明書失効リストはアカウントに関連付けられており、
前記証明書失効リストは前記アカウントの生成時に記憶される、請求項１に記載の方法。
【請求項６】
前記ホストによる前記不揮発性記憶装置を認証するための試行の前に、前記不揮発性記憶装置に記憶された証明書失効リストが実質的に存在する場合に、（ｂ）のステップは実行され、
そうでない場合には、
前記ホストから証明書失効リストを受信するステップと、
前記ホストから受信した前記証明書失効リストをキャッシュするステップと、
前記ホストからの前記証明書が失効かどうかを判定するために、前記ホストから受信されキャッシュされた証明書失効リストを使用するステップと、を実行する、請求項１に記載の方法。
【請求項７】
前記ホストによる前記不揮発性記憶装置を認証するための試行の前に、前記不揮発性記憶装置に記憶された証明書失効リストが実質的に存在する場合に、（ｂ）のステップは実行され、
そうでない場合には、証明書失効リストが前記ホストによって供給されない場合に、前記試行を拒絶する、請求項１に記載の方法。
【請求項８】
前記証明書失効リストは、失効とされた証明書の通し番号を備えている、請求項１に記載の方法。
【請求項９】
不揮発性記憶装置であって、
証明書失効リストを記憶するメモリと、
（ａ）前記ホストの前記不揮発性記憶装置への認証を試行するために、前記ホストから証明書を受信するステップと、（ｂ）前記不揮発性記憶装置にキャッシュされた証明書失効リスト内を、証明書についてのリファレンスを検索することによって、証明書が失効とされるかどうかを判定するステップと、を実行する制御部と、
を備える不揮発性記憶装置。
【請求項１０】
前記制御部は、
前記検索によって前記証明書失効リスト内から証明書についてのリファレンスが取得される場合に、前記ホストを認証するための前記試行を拒絶するステップをさらに実行する、請求項９に記載の不揮発性記憶装置。
【請求項１１】
前記制御部は、
前記ホストから証明書失効リストを受信するステップと、
前記ホストから受信した前記証明書失効リストが前記不揮発性記憶装置内の現在の証明書失効リストよりも新しく、前記受信した証明書失効リストが前記証明書の発行者によって発行されたと判定されることによって前記ホストから受信した前記証明書失効リストが検証される場合に、（ｂ）のステップを実行する代わりに、前記現在の証明書失効リストを前記新しい証明書失効リストに置換するステップと、
前記ホストからの前記証明書が失効とされるかどうか判定するために、前記新しい証明書失効リストを使用するステップと、
をさらに実行する、請求項９に記載の不揮発性記憶装置。
【請求項１２】
前記不揮発性記憶装置の製造時に、前記証明書失効リストが前記不揮発性記憶装置に記憶される、請求項９に記載の不揮発性記憶装置。
【請求項１３】
前記証明書失効リストはアカウントに関連付けられており、
前記証明書失効リストは前記アカウントの生成時に記憶される、請求項９に記載の不揮発性記憶装置。
【請求項１４】
前記制御部は、
前記ホストによる前記不揮発性記憶装置を認証するための試行の前に、前記不揮発性記憶装置に記憶された証明書失効リストが実質的に存在する場合に、（ｂ）のステップを実行し、
そうでない場合には、
前記ホストから証明書失効リストを受信するステップと、
前記ホストから受信した前記証明書失効リストをキャッシュするステップと、
前記ホストからの前記証明書が失効かどうかを判定するために、前記ホストから受信されキャッシュされた証明書失効リストを使用するステップと、を実行する、請求項９に記載の不揮発性記憶装置。
【請求項１５】
前記制御部は、
前記ホストによる前記不揮発性記憶装置を認証するための試行の前に、前記不揮発性記憶装置に記憶された証明書失効リストが実質的に存在する場合に、（ｂ）のステップを実行し、
そうでない場合には、証明書失効リストが前記ホストによって供給されない場合に、前記試行を拒絶する、請求項９に記載の不揮発性記憶装置。
【請求項１６】
前記証明書失効リストは、失効とされた証明書の通し番号を備えている、請求項９に記載の不揮発性記憶装置。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の相互参照）
本出願は、２００６年１１月６日に出願された米国特許出願第１１／５５７，００６号の一部継続出願であり、参照により本明細書に組み込まれ、２００６年７月７日に出願された米国仮特許出願第６０／８１９，５０７号の利益を主張するものである。
【０００２】
本出願は２００５年１２月２０日に出願された米国特許出願第１１／３１３，８７０号に関し、同出願は２００４年１２月２１日に出願された米国仮特許出願第６０／６３８，８０４号の利益を主張するものである。本出願はさらに２００５年１２月２０日に出願された米国特許出願第１１／３１４，４１１号に関する。本出願はさらに２００５年１２月２０日に出願された米国特許出願第１１／３１４，４１０号に関する。本出願はさらに２００５年１２月２０日に出願された米国特許出願第１１／３１３，５３６号に関する。本出願はさらに２００５年１２月２０日に出願された米国特許出願第１１／３１３，５３８号に関する。本出願はさらに２００５年１２月２０日に出願された米国特許出願第１１／３１４，０５５号に関する。本出願はさらに２００５年１２月２０日に出願された米国特許出願第１１／３１４，０５２号に関する。本出願はさらに２００５年１２月２０日に出願された米国特許出願第１１／３１４，０５３号に関する。
【０００３】
本出願は、２００６年１１月６日に出願された「Ｃｏｎｔｅｎｔ  Ｃｏｎｔｒｏｌ  Ｍｅｔｈｏｄ  Ｕｓｉｎｇ  Ｃｅｒｔｉｆｉｃａｔｅ  Ｃｈａｉｎｓ」と題するＨｏｌｔｚｍａｎらの米国特許出願第１１／５５７，０２８号と、２００６年１１月６日に出願された「Ｃｏｎｔｅｎｔ  Ｃｏｎｔｒｏｌ  Ｓｙｓｔｅｍ  Ｕｓｉｎｇ  Ｃｅｒｔｉｆｉｃａｔｅ  Ｃｈａｉｎｓ」と題するＨｏｌｔｚｍａｎらの米国特許出願第１１／５５７，０１０号と、２００６年１１月６日に出願された「Ｃｏｎｔｅｎｔ  Ｃｏｎｔｒｏｌ  Ｓｙｓｔｅｍ  Ｕｓｉｎｇ  Ｃｅｒｔｉｆｉｃａｔｅ  Ｒｅｖｏｃａｔｉｏｎ  Ｌｉｓｔｓ」と題するＨｏｌｔｚｍａｎらの米国特許出願第１１／５５７，０２６号と、２００６年１１月６日に出願された「Ｃｏｎｔｅｎｔ  Ｃｏｎｔｒｏｌ  Ｍｅｔｈｏｄ  Ｕｓｉｎｇ  Ｖｅｒｓａｔｉｌｅ  Ｃｏｎｔｒｏｌ  Ｓｔｒｕｃｔｕｒｅ」と題するＨｏｌｔｚｍａｎらの米国特許出願第１１／５５７，０４９号と、２００６年１１月６日に出願された「Ｃｏｎｔｅｎｔ  Ｃｏｎｔｒｏｌ  Ｓｙｓｔｅｍ  Ｕｓｉｎｇ  Ｖｅｒｓａｔｉｌｅ  Ｃｏｎｔｒｏｌ  Ｓｔｒｕｃｔｕｒｅ」と題するＨｏｌｔｚｍａｎらの米国特許出願第１１／５５７，０５６号と、２００６年１１月６日に出願された「Ｍｅｔｈｏｄ  ｆｏｒ  Ｃｏｎｔｒｏｌｌｉｎｇ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｓｕｐｐｌｉｅｄ  Ｆｒｏｍ  Ｍｅｍｏｒｙ  Ｄｅｖｉｃｅ」と題するＨｏｌｔｚｍａｎらの米国特許出願第１１／５５７，０５２号と、２００６年１１月６日に出願された「Ｓｙｓｔｅｍ  ｆｏｒ  Ｃｏｎｔｒｏｌｌｉｎｇ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｓｕｐｐｌｉｅｄ  Ｆｒｏｍ  Ｍｅｍｏｒｙ  Ｄｅｖｉｃｅ」と題するＨｏｌｔｚｍａｎらの米国特許出願第１１／５５７，０５１号と、２００６年１１月６日に出願された「Ｃｏｎｔｒｏｌ  Ｍｅｔｈｏｄ  Ｕｓｉｎｇ  Ｉｄｅｎｔｉｔｙ  Ｏｂｊｅｃｔｓ」と題するＨｏｌｔｚｍａｎらの米国特許出願第１１／５５７，０４１号と、２００６年１１月６日に出願された「Ｃｏｎｔｒｏｌ  Ｓｙｓｔｅｍ  Ｕｓｉｎｇ  Ｉｄｅｎｔｉｔｙ  Ｏｂｊｅｃｔｓ」と題するＨｏｌｔｚｍａｎらの米国特許出願第１１／５５７，０３９号と、に関する。
【０００４】
前述の出願は、あたかも本明細書で完全に説明されるかのように、その内容全体が参照により本明細書に組み込まれる。
【背景技術】
【０００５】
本発明は、一般にメモリシステムに関し、特に汎用的なコンテンツ管理機能を備えるメモリシステムに関する。
【０００６】
フラッシュ・メモリ・カードなどの記憶装置は、写真などのデジタルコンテンツを記憶するのに最適な記憶媒体となっている。また、フラッシュ・メモリ・カードは他の種類の媒体コンテンツの配信に使用される場合もある。さらに、コンピュータ、デジタルカメラ、携帯電話、携帯端末（ＰＤＡ）、およびＭＰ３プレーヤなどのメディアプレーヤなど、ホスト装置の多様化は、フラッシュ・メモリ・カード内に記憶される媒体コンテンツを提供する可能性を今や有している。それゆえ、フラッシュ・メモリ・カードは、他の種類の携帯記憶装置と同様に、デジタルコンテンツを配信する、幅広く使用される媒体となる可能性が大きい。
【０００７】
デジタルコンテンツのオーナーおよび配信業者にとって主要な関心事の１つは、インターネットなどのネットワークからのダウンロードを通じて、あるいは記憶装置上のコンテンツの配信を通じてコンテンツが配信された後、認可取得者のみがコンテンツへのアクセスを許可されるべきであるということである。不正アクセスを回避する方法の１つは、コンテンツへのアクセスが当事者に許諾される前に当事者のアイデンティティを確認するシステムを採用することである。公開鍵基盤（ＰＫＩ）などのシステムがこの目的で開発されている。ＰＫＩシステムでは、証明機関（ＣＡ）として知られる信頼された機関が、個人または組織のアイデンティティを確認する証明書を発行する。アイデンティティの証拠を確認したい組織および個人などの当事者は、自身のアイデンティティを確認する十分な証拠を証明機関に登録することができる。当事者のアイデンティティがＣＡに確認されると、ＣＡは証明書をこうした当事者に発行することになる。証明書は、典型的に、証明書を発行したＣＡの名称、証明書の発行の対象となった当事者の名称、当事者の公開鍵、およびＣＡの秘密鍵により署名された（典型的に公開鍵のダイジェストを暗号化することにより）当事者の公開鍵を含む。
【０００８】
ＣＡの秘密鍵および公開鍵は、公開鍵を用いて暗号化されたデータが秘密鍵によって復号化されるように関係付けられ、逆も同様である。それゆえ、秘密鍵および公開鍵は鍵対を形成する。暗号化技術に関する秘密鍵および公開鍵対の説明は、ＲＳＡセキュリティ（ＲＳＡ  Ｓｅｃｕｒｉｔｙ  Ｉｎｃ．）の２００２年６月１４日付、「ＰＫＣＳ＃１  ｖ２．１：ＲＳＡ  Ｃｒｙｐｔｏｇｒａｐｈｙ  Ｓｔａｎｄａｒｄ」に記載されている。ＣＡの公開鍵は一般に利用可能となっている。したがって、一当事者が別の当事者によって提示された証明書を真正かどうか検証したい場合、検証する当事者は、復号化アルゴリズムを用いて証明書内の公開鍵の暗号化されたダイジェストを復号化するために、ＣＡの公開鍵を使用するだけでよい。また、復号化アルゴリズムは、典型的に、証明書の中でも識別される。証明書の中の公開鍵の復号化されたダイジェストが、証明書の中の暗号化されていない公開鍵のダイジェストに一致する場合、これは、証明書の中の公開鍵がＣＡ内の信用とＣＡの公開鍵の信頼性とに基づいて改ざんされておらず真正であることを証明している。
【０００９】
ある当事者のアイデンティティを検証するために、検証する側は、典型的に、質問（例えば、乱数）を送信し、相手方には自身の証明書と質問に対する回答（すなわち、相手方の秘密鍵で暗号化された乱数）の送信を求める。回答と証明書が受信されると、検証する側はまず、証明書の公開鍵が真正かどうかを前述したプロセスによって検証する。公開鍵が真正であると検証された場合、検証する側は証明書内の中にある公開鍵を使用して回答を復号化し、その結果を当初送信した乱数と比較することができる。それらが一致する場合は相手方が正しい秘密鍵を所持していることを意味し、これをもって相手方は自身のアイデンティティを証明したことになる。証明書の中の公開鍵が真正でないか、あるいは復号化された回答が質問に一致しないと、認証は失敗に終わる。それゆえ、自身のアイデンティティを証明することを望む当事者は、証明書および対応する秘密鍵の両方を所持する必要がある。
【００１０】
前述したメカニズムにより、ことによると互いを信用できない両方の当事者でも、前述したプロセスを用いて、相手方の証明書の中にある相手方の公開鍵を検証することよって信用を成立させることができる。国際電気通信連合（ＩＴＵ）電気通信標準化部門（ＩＴＵ−Ｔ）の勧告Ｘ．５０９は証明書の枠組みを定める規格書である。証明書とその運用に関する詳しい情報はこの規格書で確認することができる。
【００１１】
運営管理と大規模組織の便宜を図るため、ルートＣＡ（root CA）として知られる上位ＣＡが、証明書発行の責務をいくつかの下位機関に委譲するとよい場合がある。例えば、２レベル階層において、最上位のルートＣＡは下位機関の公開鍵が真正であることを証明するための下位ＣＡに証明書を発行する。そして、下位ＣＡは前述した登録プロセスを通じて当事者に証明書を発行する。検証プロセスは証明書連鎖の頂点から始まる。検証する側はまず、ルートＣＡの公開鍵（真正と判明）を使用して、下位ＣＡの公開鍵の真性を検証する。下位ＣＡの公開鍵の真性が検証されると、下位ＣＡから証明書の発行を受けた当事者の公開鍵の真性を、下位ＣＡの検証済み公開鍵を使用して検証することができる。このように、ルートＣＡと下位ＣＡとによって発行される証明書により、アイデンティティ検証の対象となる当事者の２つの証明書からなる連鎖が形成される。
【００１２】
当然ながら、証明書階層のレベルは２レベルを超えることもあり、ルートＣＡを除く下位レベルの各ＣＡはその権限を上位ＣＡから受け取り、上位ＣＡによって発行された公開鍵を含む証明書を所持する。したがって、相手方の公開鍵の真性を検証するには、ルートＣＡに至る経路、すなわち証明書の連鎖をたどる必要がある。換言すると、アイデンティティを立証するには、アイデンティティを証明する必要がある側が、自身の証明書からルートＣＡ証明書にかけて一連の証明書を提示する必要がある可能性がある。
【発明の概要】
【発明が解決しようとする課題】
【００１３】
証明書は一定の有効期間にわたって発行される。しかしながら、名称の変更、証明書発行元との関係の変化、対応する秘密鍵の侵害または侵害の疑いなどにより、有効期間の満了に先立ち証明書が無効になることもある。このような場合には証明機関（ＣＡ）が証明書を失効させる必要がある。証明機関は、失効させた全証明書の通し番号が記載された証明書失効リストを定期的に公表する。従来の証明書検証方法では、認証する側のエンティティ（entity）には、証明書失効リストを所持するか、あるいは証明機関（ＣＡ）から証明書失効リストを取り寄せることができ、認証のために提示される証明書の通し番号をリストに照らしてチェックして、提示された証明書が失効済みかどうかを判断することが求められる。認証する側のエンティティがメモリまたは記憶装置である場合、装置そのものを使用して証明機関から証明書失効リストを取り寄せることはしていない。その結果、認証のために提示される証明書を、メモリまたは記憶装置で検証することはできない。したがって、証明書失効リストを入手せずとも、メモリまたは記憶装置で証明書を検証できる改良されたシステムの提供が望まれる。
【課題を解決するための手段】
【００１４】
メモリ装置は、それだけで証明書失効リストを入手するために使用されてはいない。したがって、ホスト装置が証明書に関する証明書失効リストを併せて提示することなく認証のために記憶装置に証明書を提示する場合、ホスト装置から提示される証明書が関連証明書失効リストに載っているか否かを、記憶装置は確認できないことになる。そのため、本発明の一実施形態は、証明書、さらには証明書に関する証明書失効リストに加えて、ホスト装置が提示するシステムによってこの問題を回避しうるとの認識に基づくものである。こうして、記憶装置は、ホスト装置から送信される証明書失効リストの中の証明書の通し番号など、証明書の識別情報を照合することによって証明書が真性であることを検証することができる。
【００１５】
証明書失効リストが、その通し番号などの失効した証明書についての多くの識別情報を含む場合、リストはきわめて冗長になる可能性がある。それゆえ、別の実施形態では、証明書失効リストの一部分が装置によって受信され、装置はその一部分を順番に処理する。また、装置は、処理および検索が同時に行われる場合にリスト上のホストから受信された証明書についての、リファレンスまたは識別情報を検索する。処理および検索は同時に行われるので、証明書を検証する処理は効率化が進む。
【００１６】
前述のように、記憶装置は証明書失効リストを入手するために使用されてこなかったが、ホスト装置は証明書失効リストを入手するために使用されてきた。それゆえ、別の実施形態では、ホスト装置はホスト装置の認証のために証明書とともに証明書失効リストを提示する必要があるが、記憶装置、すなわちメモリ装置に対してはそのような必要性がなく、証明書を提示するだけで済むことになる。その結果、メモリ装置証明書を検証する適正な証明書失効リストを入手できるかどうかは、ホスト装置次第である。
【００１７】
証明書失効リストを自由に入手するためにホスト装置を利用することが可能であるものの、記憶装置の中の暗号化コンテンツにアクセスしたいときなど、その都度頻繁にそうせねばならないのは、多くの消費者にとって煩わしい可能性がある。それゆえ、別の実施形態では、少なくとも１つの証明書失効リストがメモリの共有領域に記憶され、メモリはユーザまたは消費者がアクセスしたい被保護データまたはコンテンツも記憶する。こうすると、消費者またはユーザは、メモリに記憶されたコンテンツにアクセスしたいときに、その都度証明書失効リストを証明機関から入手する必要がなくなる。代わりに、消費者またはユーザは、メモリの共有領域に記憶された少なくとも１つの証明書失効リストを検索してから、この証明書失効リストを認証とコンテンツへのアクセスのためにメモリに提示するだけでよい。多くの種類のメモリの共有領域は、典型的に、ホスト装置によって管理され、メモリそのものによっては管理されない。
【００１８】
別の実施形態では、不揮発性記憶装置は、既に装置に記憶された証明書失効リストを利用することができ、ホストが証明書失効リストを装置から検索し、検索したリストを装置に再び提示する必要はない。
【００１９】
本明細書において言及するすべての特許、特許出願、論文、書籍、仕様書、規格書、その他の出版物、文書、およびその他の事物は、あらゆる目的でその全体が参照により本明細書に援用されている。援用される出版物、文書、または事物のいずれかと本明細書の本文章との間の用語の定義および用法に不一致や対立がある場合、本明細書における用語の定義および用法が優先するものとする。
【図面の簡単な説明】
【００２０】
【図１】本発明を示すために有用である、ホスト装置と通信するメモリシステムのブロック図である。
【００２１】
【図２】本発明の種々の実施形態を例示するのに有用である、特定パーティションと暗号化ファイルへのアクセスをアクセスポリシーと認証手続きとによって制御する、メモリの種々のパーティションと種々のパーティションに記憶される非暗号化ファイルおよび暗号化ファイルとの概略図である。
【００２２】
【図３】メモリ内の種々のパーティションを示すメモリの概略図である。
【００２３】
【図４】本発明の種々の実施形態を例示するのに有用である、パーティション内のいくつかのファイルが暗号化される図３に示すメモリの種々のパーティションのファイル・ロケーション・テーブルの概略図である。
【００２４】
【図５】本発明の種々の実施形態を説明するのに有用なアクセス制御記録グループにおける、アクセス制御記録および関連鍵リファレンスの概略図である。
【００２５】
【図６】本発明の種々の実施形態を説明するのに有用なアクセス制御記録グループおよびアクセス制御記録によって形成されるツリー構造の概略図である。
【００２６】
【図７】ツリーの形成のプロセスを説明するためのアクセス制御記録グループの３つの階層ツリーを示すツリーの概略図である。
【００２７】
【図８Ａ】ホスト装置と、システムアクセス制御記録を作成して用いるメモリカードなどのメモリ装置とによって実行されるプロセスを示すフローチャートである。
【図８Ｂ】ホスト装置と、システムアクセス制御記録を作成して用いるメモリカードなどのメモリ装置とによって実行されるプロセスを示すフローチャートである。
【００２８】
【図９】種々の実施形態を説明するのに有用なアクセス制御記録グループを作成するためにシステムアクセス制御記録を用いるプロセスを示すフローチャートである。
【００２９】
【図１０】アクセス制御記録を作成するプロセスを示すフローチャートである。
【００３０】
【図１１】階層ツリーの特定の用途を例示するのに有用な２つのアクセス制御記録グループの概略図である。
【００３１】
【図１２】特定の権利を委譲するプロセスを示すフローチャートである。
【００３２】
【図１３】図１２の委譲プロセスを例示するための、アクセス制御記録グループおよびアクセス制御記録の概略図である。
【００３３】
【図１４】暗号化および／または復号化のために鍵を作成するプロセスを示すフローチャートである。
【００３４】
【図１５】アクセス制御記録に従ってアクセス権および／またはデータアクセス権限を削除するプロセスを示すフローチャートである。
【００３５】
【図１６】アクセス権および／またはアクセス権限が削除されたか、あるいは期限切れになった場合にアクセスを要求するプロセスを示すフローチャートである。
【００３６】
【図１７Ａ】本発明の様々な実施形態の例示に有用である、認証ルール構造と暗号鍵アクセス許諾ポリシー構成を示す概略図である。
【図１７Ｂ】本発明の様々な実施形態の例示に有用である、認証ルール構造と暗号鍵アクセス許諾ポリシー構成を示す概略図である。
【００３７】
【図１８】ポリシーに従って被保護情報へのアクセスを制御する代替的な方法を示すデータベース構造のブロック図である。
【００３８】
【図１９】パスワードを用いた認証プロセスを示すフローチャートである。
【００３９】
【図２０】複数のホスト証明書連鎖を示す図である。
【００４０】
【図２１】複数の装置証明書連鎖を示す図である。
【００４１】
【図２２】一方向および相互認証方式のプロセスを示すプロトコル図である。
【図２３】一方向および相互認証方式のプロセスを示すプロトコル図である。
【００４２】
【図２４】本発明の一実施形態を例示するのに有用である、証明書連鎖の図である。
【００４３】
【図２５】本発明の別の実施形態を例示するための、メモリ装置に最終証明書を送信する場合のホストによって送信される証明書バッファに先行する制御セクタ内の情報を示す表であり、この証明書が証明書連鎖における最終証明書であることを伝える標示を示す。
【００４４】
【図２６】メモリカードがホスト装置を認証する認証方式のための、カードとホストのプロセスのそれぞれを示すフローチャートである。
【図２７】メモリカードがホスト装置を認証する認証方式のための、カードとホストのプロセスのそれぞれを示すフローチャートである。
【００４５】
【図２８】ホスト装置がメモリカードを認証する認証方式のための、カードとホストのプロセスのそれぞれを示すフローチャートである。
【図２９】ホスト装置がメモリカードを認証する認証方式のための、カードとホストのプロセスのそれぞれを示すフローチャートである。
【００４６】
【図３０】本発明の別の実施形態を例示するための、メモリ装置に記憶された証明書失効リストがホスト装置によって検索される場合に、ホスト装置とメモリ装置によってそれぞれ実行されるプロセスを示すフローチャートである。
【図３１】本発明の別の実施形態を例示するための、メモリ装置に記憶された証明書失効リストがホスト装置によって検索される場合に、ホスト装置とメモリ装置によってそれぞれ実行されるプロセスを示すフローチャートである。
【００４７】
【図３２】本発明のさらに別の実施形態を示すための、証明書失効リスト内のフィールドを示す証明書失効リストの図である。
【００４８】
【図３３】証明書失効リストを用いて証明書を検証する、カードとホストのプロセスのそれぞれを示すフローチャートである。
【図３４】証明書失効リストを用いて証明書を検証する、カードとホストのプロセスのそれぞれを示すフローチャートである。
【００４９】
【図３５】カードがホストに送信されるデータに署名し、かつホストからのデータを復号化するカードプロセスを示すフローチャートである。
【００５０】
【図３６】カードがホストに送信されるデータに署名する場合のホストプロセスを示すフローチャートである。
【００５１】
【図３７】ホストがメモリカードに暗号化データを送信する場合のホストプロセスを示すフローチャートである。
【００５２】
【図３８】一般情報および取扱い注意情報のクエリのプロセスをそれぞれ示すフローチャートである。
【図３９】一般情報および取扱い注意情報のクエリのプロセスをそれぞれ示すフローチャートである。
【００５３】
【図４０Ａ】本発明の実施形態を例示するための、ホスト装置に接続されたメモリ装置（フラッシュ・メモリ・カードなど）におけるシステムアーキテクチャの機能ブロック図である。
【００５４】
【図４０Ｂ】図４０ＡのＳＳＭコアの内部ソフトウェアモジュールの機能ブロック図である。
【００５５】
【図４１】ワン・タイム・パスワードを生成するシステムのブロック図である。
【００５６】
【図４２】ワン・タイム・パスワード（ＯＴＰ）シード提供およびＯＴＰ生成を示す機能ブロック図である。
【００５７】
【図４３】シード提供段階を説明するプロトコル図である。
【００５８】
【図４４】ワン・タイム・パスワード生成段階を示すプロトコル図である。
【００５９】
【図４５】ＤＲＭシステムを説明する機能ブロック図である。
【００６０】
【図４６】ライセンスオブジェクトの中で鍵が提供される場合のライセンス提供およびコンテンツダウンロードのプロセスを示すプロトコル図である。
【００６１】
【図４７】再生操作のプロセスを示すプロトコル図である。
【００６２】
【図４８】ライセンスオブジェクトの中で鍵が提供されない場合のライセンス提供およびコンテンツダウンロードのプロセスを示すプロトコル図である。
【００６３】
【図４９】証明書失効リストを用いてアクセス制御記録を構成する例示的なステップを示すフローチャートである。
【００６４】
【図５０】認証中に不揮発性記憶装置にキャッシュされ、あるいは装置に提供された証明書失効リストを用いて不揮発性記憶装置を認証する例示的なステップを示すフローチャートである。
【００６５】
図は本発明の態様の様々な実施形態における特徴を説明している。説明を簡単にするために、本出願では同一の構成要素を同じ数字で表示する。
【発明を実施するための形態】
【００６６】
本発明の様々な態様が実施されうる場合のメモリシステムの例を、図１のブロック図によって説明する。図１に示すように、メモリシステム１０は、中央処理装置（ＣＰＵ）１２、バッファ管理ユニット（ＢＭＵ）１４、ホスト・インターフェース・モジュール（ＨＩＭ）１６およびフラッシュ・インターフェース・モジュール（ＦＩＭ）１８、フラッシュメモリ２０および周辺アクセスモジュール（ＰＡＭ）２２を含む。メモリシステム１０は、ホスト・インターフェース・バス２６およびポート２６ａを通じてホスト装置２４と通信する。フラッシュメモリ２０は、ＮＡＮＤタイプのものであってもよく、ホスト装置２４に対してデータ記憶を提供する。ホスト装置２４は、デジタルカメラ、パーソナルコンピュータ、携帯端末（ＰＤＡ）、ＭＰ３プレーヤなどのデジタルメディアプレーヤ、携帯電話、セット・トップ・ボックス、あるいはその他のデジタル装置またはデジタル家電であってもよい。また、ＣＰＵ１２のソフトウェアコードは、フラッシュメモリ２０に記憶されてもよい。ＦＩＭ１８は、フラッシュ・インターフェース・バス２８およびポート２８ａを通じてフラッシュメモリ２０に接続する。ＨＩＭ１６はホスト装置への接続に適している。周辺アクセスモジュール２２は、ＣＰＵ１２と通信するＦＩＭ、ＨＩＭ、およびＢＭＵなどの適切なコントローラモジュールを選択する。一実施形態では、点線枠内のシステム１０の構成要素のすべては、メモリカードまたはスティック１０’などの単一ユニットに入れられてもよく、好ましくはカプセル化される。メモリシステム１０はホスト装置２４に取外し可能に接続され、したがって、システム１０内のコンテンツは多くの異なるホスト装置の各々によってアクセスされうる。
【００６７】
以下の説明では、メモリシステム１０は、さらに、メモリ装置１０、あるいは簡単にメモリ装置または装置と称される。本発明は本明細書においてフラッシュメモリを参照して説明されるが、本発明は、磁気ディスク、光学ＣＤ、ならびにその他あらゆるタイプの書換え可能な不揮発性メモリシステムなど、他のタイプのメモリにも適用されてもよい。
【００６８】
バッファ管理ユニット１４は、ホスト・ダイレクト・メモリ・アクセス（ＨＤＭＡ）３２、フラッシュ・ダイレクト・メモリ・アクセス（ＦＤＭＡ）３４、アービタ（an arbiter）３６、バッファ・ランダム・アクセス・メモリ（ＢＲＡＭ）３８、および暗号エンジン４０を含む。アービタ３６は共有バスアービタであり、これにより、唯一のマスタまたはイニシエータ（これはＨＤＭＡ３２、ＦＤＭＡ３４、またはＣＰＵ１２）がいつでもアクティブとなることができるとともに、スレーブまたはターゲットがＢＲＡＭ３８となる。アービタは、ＢＲＡＭ３８に適切なイニシエータ要求を送信することに関与する。ＨＤＭＡ３２およびＦＤＭＡ３４は、ＨＩＭ１６、ＦＩＭ１８、およびＢＲＡＭ３８またはＣＰＵランダム・アクセス・メモリ（ＣＰＵ＿ＲＡＭ）１２ａの間で輸送されるデータに関与する。ＨＤＭＡ３２およびＦＤＭＡ３４の動作は、従来通りであり、本明細書において詳しく説明する必要はない。ＢＲＡＭ３８は、ホスト装置２４とフラッシュメモリ２０の間で伝達されるデータを記憶するために使用される。ＨＤＭＡ３２およびＦＤＭＡ３４は、ＨＩＭ１６／ＦＩＭ１８とＢＲＡＭ３８またはＣＰＵ＿ＲＡＭ１２ａとの間でデータを転送しセクタ完了を示すことに関与する。
【００６９】
一実施形態では、メモリシステム１０は、暗号化および／または復号化に使用される鍵値を生成し、この値は、ホスト装置２４などの外部装置に実質的にアクセス可能でないことが好ましい。あるいは、また、鍵値はライセンスサーバなどによってシステム１０の外部で生成されてシステム１０に送信されてもよい。鍵値の生成方法に関わらず、鍵値がシステム１０内に記憶された時点で、認証エンティティのみが鍵値にアクセスしうるようになる。しかしながら、ホスト装置はメモリシステム１０にデータをファイル形式で読み書きするので、暗号化および復号化は、典型的に、ファイルごとに行われる。他の多くのタイプの記憶装置と同様に、メモリ装置１０はファイルを管理しない。メモリ２０は、ファイルの論理アドレスが識別される場合にファイル・アロケーション・テーブル（ＦＡＴ）を必ず記憶するが、ＦＡＴは典型的にコントローラ１２によってではなく、ホスト装置２４によってアクセスされて管理される。したがって、特定ファイル内のデータを暗号化するために、コントローラ１２はホスト装置を頼りにメモリ２０内のファイルにあるデータの論理アドレスを送信する必要があり、したがって、特定ファイルのデータはシステム１０のみに利用可能な鍵値を用いてシステム１０によって検索され、暗号化および／または復号化することができる。
【００７０】
ファイル内のデータの暗号処理に際して、ホスト装置２４およびメモリシステム１０の両方に同じ鍵を参照する機会を提供するために、ホスト装置は、システム１０によって生成される鍵値あるいはシステム１０に送信される鍵値の各々に対してリファレンスを提供する。この場合、このようなリファレンスは、単に鍵ＩＤであってよい。それゆえ、ホスト２４は、システム１０によって暗号処理される各ファイルを鍵ＩＤと関連付け、システム１０は、データを暗号処理するために使用される各鍵値をホストによって提供される鍵ＩＤと関連付ける。それゆえ、ホストは、データの暗号処理を要求するとき、その要求を、メモリ２０から取り出されあるいはメモリ２０に記憶されるデータの論理アドレスおよび鍵ＩＤとともに、システム１０に送信することになる。システム１０は、鍵値を生成しあるいは受信し、ホスト２４によって提供される鍵ＩＤをこの鍵値と関連付けて暗号処理を実施する。こうすると、メモリシステム１０の動作方法を変更しなくて済む一方、鍵値への排他的アクセスを含む、鍵を用いた暗号処理を完全に制御することができる。換言すると、いったん鍵値がシステム１０に記憶されるか、あるいはシステム１０によって生成されると、システムは、ＦＡＴの独占的制御によるファイルの管理をホスト２４に継続させつつ、暗号処理に用いる鍵値の管理を一手に引き受ける。鍵値がメモリシステム１０に記憶された後、ホスト装置２４は、データの暗号処理に用いる鍵値の管理に一切関与しない。
【００７１】
ホスト２４によって提供される鍵ＩＤと、メモリシステムによって送信または生成される鍵値とは、実施形態の１つにおいて、「コンテンツ暗号化鍵」またはＣＥＫと以下で称される量の、２つの属性を形成する。ホスト２４は、各鍵ＩＤを１つまたは複数のファイルと関連付けてもよい。またホスト２４は、各鍵ＩＤを非編集データと関連付けるか、あるいは、何らかの方法で編集され、かつ完全なファイルに編集されたデータに限定されないデータと関連付けてもよい。
【００７２】
ユーザまたはアプリケーションが、システム１０の保護されたコンテンツまたは領域にアクセスするためには、システム１０に事前に登録される認証情報を用いて認証される必要がある。認証情報は、このような認証情報によって特定のユーザまたはアプリケーションに与えられたアクセス権に関係している。事前登録プロセスでは、システム１０は、アイデンティティの記録およびユーザまたはアプリケーションの認証情報と、ユーザまたはアプリケーションによって決定されホスト２４を通じて提供されるこうしたアイデンティティおよび認証情報に関連するアクセス権と、を記憶する。事前登録の完了後、ユーザまたはアプリケーションがメモリ２０へのデータの書込みを要求するとき、ホスト装置を通じてそのアイデンティティおよび認証情報と、データを暗号化する鍵ＩＤと、暗号化データを記憶する必要がある場合の論理アドレスと、を提供する必要がある。システム１０は、鍵値を生成または受信し、この値をホスト装置によって提供される鍵ＩＤと関連付け、書き込まれるデータを暗号化するために使用される鍵値に対する鍵ＩＤをこのユーザまたはアプリケーションのための記録または表に記憶する。この後、システムはデータを暗号化し、暗号化されたデータを、生成または受信された鍵値とともに、ホストによって指定されたアドレスに記憶する。
【００７３】
ユーザまたはアプリケーションが、メモリ２０から暗号化されたデータの読出しを要求するとき、そのアイデンティティおよび認証情報と、要求されたデータを暗号化するために事前使用される鍵に対する鍵ＩＤと、暗号化されたデータが記憶される論理アドレスと、を提供する必要がある。システム１０は、この後、ホストによって提供されるユーザまたはアプリケーションアイデンティティおよび認証情報を、その記録に記憶されたユーザまたはアプリケーションアイデンティティおよび認証情報と照合する。これらが一致する場合、システム１０は、ユーザまたはアプリケーションによって提供された鍵ＩＤに関連する鍵値をそのメモリから取り出し、鍵値を用いてホスト装置によって指定されたアドレスに記憶されたデータを復号化し、復号化されたデータをユーザまたはアプリケーションに送信する。
【００７４】
認証のための認証情報を、暗号化処理に使用される鍵の管理から分離することによって、認証情報を共有せずにデータにアクセスする権利を共有することが可能である。それゆえ、種々の認証情報を有するユーザまたはアプリケーションのグループは、同じデータにアクセスするために同じ鍵にアクセスすることができるが、このグループ外部のユーザはアクセスすることができない。グループ内のすべてのユーザまたはアプリケーションは同じデータにアクセスしてもよいが、これらのユーザまたはアプリケーションは異なる権利をさらに有していてもよい。それゆえ、一部のユーザまたはアプリケーションはリード・オンリー・アクセスしてもよく、他のユーザまたはアプリケーションはライト・オンリー・アクセスしてもよく、さらに他のユーザまたはアプリケーションはこれら両方のアクセスをしてもよい。システム１０は、ユーザまたはアプリケーションのアイデンティティおよび認証情報と、ユーザまたはアプリケーションがアクセスする鍵ＩＤと、鍵ＩＤの各々に対する関連アクセス権と、の記録を維持する。そのため、すべてが適正に認証されたホスト装置によって制御されるものとして、システム１０では、特定のユーザまたはアプリケーションの鍵ＩＤの追加または削除を行うことで、当該鍵ＩＤに関連するアクセス権を変更したり、あるユーザまたはアプリケーションから別のユーザまたはアプリケーションにアクセス権を委譲したり、さらにはユーザまたはアプリケーションの記録または表を削除または追加したりすることができる。記憶された記録は、一定の鍵にアクセスするためにセキュアチャネルが必要であることを規定してもよい。認証は、パスワードとともに対称または非対称アルゴリズムを使用して行われてもよい。
【００７５】
特に重要なのは、メモリシステム１０内の保護されたコンテンツの移植性である。鍵値へのアクセスがメモリシステムによって制御される実施形態では、システムを組み込むメモリシステムまたは記憶装置が、ある外部システムから別の外部システムに移動されるとき、そこに記憶されたコンテンツのセキュリティが維持される。鍵がメモリシステムによって生成されようとメモリシステムの外部に由来しようと、外部システムはメモリシステムによって完全に制御されるように認証されていない限り、システム１０内のこのようなコンテンツにアクセスすることができない。このように認証された後でさえ、アクセスはメモリシステムによって全体として制御され、外部システムはメモリシステム内のプリセットされた記録に従って制御された形でしかアクセスすることができない。要求がこのような記録に適合しなければ、要求は拒絶されることになる。
【００７６】
コンテンツを保護する際の柔軟性を高めるために、以下でパーティションと称するメモリの一定領域が、適正に認証されたユーザまたはアプリケーションのみによってアクセスされうることが想定される。鍵ベースのデータ暗号化についての前述の特徴を併用した場合、システム１０はより優れたデータ保護能力を備える。図２に示すように、フラッシュメモリ２０は、その記憶容量が複数のパーティション（ユーザ領域またはパーティションおよびカスタムパーティション）に分割されてもよい。ユーザ領域またはパーティションＰ０は、認証なしですべてのユーザおよびアプリケーションにアクセス可能である。ユーザ領域に記憶されたデータのすべてのビット値は、どんなアプリケーションまたはユーザによっても読み書きされうるが、データ読出しが暗号化される場合、復号化する権限のないユーザまたはアプリケーションは、ユーザ領域に記憶されたビット値により表される情報にアクセスできないことになる。これは、例えば、ユーザ領域Ｐ０に記憶されたファイル１０２および１０４によって説明される。さらにユーザ領域に記憶されるのは、すべてのアプリケーションおよびユーザによって読み出され理解されうる１０６などの暗号化されていないファイルである。それゆえ、図面上では、ファイル１０２および１０４などのように、暗号化されたファイルはロック付きで示す。
【００７７】
権限のないアプリケーションまたはユーザは、ユーザ領域Ｐ０で暗号化されたファイルを解釈できないが、このようなアプリケーションまたはユーザであってもファイルを削除したり破壊したりすることは可能であり、用途によっては好ましくない場合がある。このためメモリ２０には、パーティションＰ１およびＰ２などの、事前の認証なくしてアクセスできない被保護カスタムパーティションもある。この用途の実施形態に使える認証プロセスを、以下で説明する。
【００７８】
同じく図２に示されているように、メモリ２０のファイルには様々なユーザまたはアプリケーションがアクセスしうる。それゆえ、図２には、ユーザ１および２とアプリケーション１〜４（装置上で実行）が示されている。これらのエンティティは、以下で説明する認証プロセスによって認証された後に、メモリ２０の被保護コンテンツへのアクセスが認められる。このプロセスでは、アクセスを要求するエンティティを、ロール方式のアクセス制御のためにホスト側で識別する必要がある。それゆえ、アクセスを要求するエンティティはまず、「私はアプリケーション２であってファイル１を読み出したい」などの情報を供給することによって、自身を識別する。コントローラ１２は、この後、そのアイデンティティと、認証情報と、要求とを、メモリ２０またはコントローラ１２に記憶された記録に突き合せる。すべての要件が満たされる場合、そのようなエンティティにアクセスが認められる。図２に示すように、ユーザ１はパーティションＰ１のファイル１０１を読み書きすることができ、Ｐ０ではファイル１０６に対する無制限の読出しおよび書込み権利を有しているが、これ以外に読出し可能なファイルはファイル１０２および１０４のみである。一方、ユーザ２は、ファイル１０１および１０４へのアクセスを許可されないが、ファイル１０２に対する読出しおよび書込みアクセス権は有している。図２に示すように、ユーザ１および２のログインアルゴリズム（ＡＥＳ）は同じであるが、アプリケーション１および３のログインアルゴリズムは異なり（例えば、ＲＳＡと００１００１）、ユーザ１および２のものとも異なる。
【００７９】
セキュア・ストレージ・アプリケーション（ＳＳＡ）は本発明の一実施形態を例示するメモリシステム１０のセキュリティアプリケーションであり、前述した機能の多くはこれを用いて実施することができる。ＳＳＡは、メモリ２０またはＣＰＵ１２の不揮発性メモリ（図示せず）に記憶されたデータベースを備えるソフトウェアまたはコンピュータコードとして実装でき、ＲＡＭ１２ａに読み込まれ、ＣＰＵ１２によって実行される。下表には、ＳＳＡに言及する場合に用いる頭字語が記されている。
【表１】
2013514587.tif 000003
【００８０】
＜ＳＳＡシステムの説明＞
ＳＳＡの主な役割は、データの保護と完全性とアクセス制御である。データとは、ある種の大容量記憶装置に一目瞭然な状態で記憶される場合があるファイルである。ＳＳＡシステムは記憶システムの上部に位置し、記憶されたホストファイルのためのセキュリティ層を加え、後述するセキュリティデータ構造を通じてセキュリティ機能を提供する。
【００８１】
ＳＳＡの主な仕事は、メモリに記憶された（保護された）コンテンツに関わる様々な権利を管理することである。メモリアプリケーションは、複数の記憶コンテンツに対する、複数のユーザおよびコンテンツ権利を管理する必要がある。ホストアプリケーションは、ホスト側から、提示されたドライブとパーティションを見るほか、記憶装置に記憶されたファイルの位置を管理し表現するファイル・アロケーション・テーブル（ＦＡＴ）を見る。
【００８２】
この場合の記憶装置は、パーティションに分割されたＮＡＮＤフラッシュチップを使用するが、他の携帯型記憶装置も使用でき、本発明の範囲内にある。これらのパーティションは一連の論理アドレスであり、その境界は開始アドレスと終端アドレスで区切られる。したがって、必要に応じて、非表示のパーティションへのアクセスに制限を設けることができ、それにはソフトウェア（メモリ２０に記憶されたソフトウェアなど）によって上記の境界内のアドレスにそのような制限を関連付ける。ＳＳＡは、自身が管理する論理アドレスの境界によって、パーティションを完全に認識しうる。ＳＳＡシステムは、パーティションを用いて、権限を有していないホストアプリケーションからデータを物理的に保護する。ホストにとってのパーティションは、データファイルが記憶される専有空間を規定するメカニズムである。これらのパーティションは公開しても、非公開もしくは非表示としてもよい。公開する場合、記憶装置にアクセスできる者であれば誰でも装置におけるこれらのパーティションの存在を見取って、かつ認識することができる。非公開もしくは非表示にする場合、選ばれたホストアプリケーションのみがこれらのパーティションにアクセスでき、記憶装置におけるこれらの存在を認識できる。
【００８３】
図３は、メモリのパーティションＰ０、Ｐ１、Ｐ２、およびＰ３を示すメモリの概略図であり（当然ながら５つ以上のパーティションが使われることも、あるいは３つ以下のパーティションが使われることもある）、Ｐ０はいずれのエンティティでも認証なしでアクセスできる公開パーティションである。
【００８４】
非公開パーティション（Ｐ１、Ｐ２、またはＰ３など）の中にあるファイルへのアクセスは非表示にされる。ホストによるパーティションへのアクセスを阻止することにより、フラッシュ装置（例えば、フラッシュカード）は、パーティションの中でデータファイルの保護を達成する。しかしながら、この種の保護は、非表示パーティションに常駐する論理アドレスに記憶されたデータへのアクセスに制限を設けることによって、非表示パーティションの中にあるすべてのファイルを囲い込むものである。換言すると、一連の論理アドレスに制限を関連付けるものである。そのパーティションにアクセスできるユーザ／ホストはいずれも、内部にあるすべてのファイルに無制限にアクセス可能である。様々なファイル（またはファイル群）を互いに分離するため、ＳＳＡシステムは、鍵と、鍵のリファレンスすなわち鍵ＩＤとを用いて、別の保護および完全性レベルをファイル（またはファイル群）単位で提供する。様々なメモリアドレスでデータを暗号化するために用いられる特定の鍵値の鍵リファレンス（すなわち鍵ＩＤ）は、暗号化データを含む容器または領域に例えることができる。このため、図４では、鍵ＩＤと関連付けられた鍵値を用いて暗号化されたファイルを取り囲む領域として、鍵リファレンス（すなわち鍵ＩＤ）（例えば、「鍵１」および「鍵２」）が図形で示されている。
【００８５】
図４を参照すると、例えば、ファイルＡは鍵ＩＤで囲まれていないため、いずれのエンティティでも認証なしでファイルＡにアクセスすることができる。公開パーティションの中にあるファイルＢは、いずれのエンティティでも読出しや上書きを行えるが、その中のデータはＩＤ「鍵１」を有する鍵で暗号化されているため、このような鍵にアクセスできるエンティティでない限り、ファイルＢの中にある情報にはアクセスすることができない。このような鍵値と鍵リファレンス（すなわち、鍵ＩＤ）の使用は、前述したパーティションによる保護とは異なり、論理的な保護のみを提供する。つまり、パーティション（公開または非公開）にアクセスできるホストであればいずれでもパーティション全体の中で暗号化データを含むデータを読み書きすることができる。しかしながら、データは暗号化されているため、権限を有していないユーザはデータを破壊することしかできない。権限を有していないユーザは、発覚することなく、このデータを変更できない。暗号化および／または復号化鍵へのアクセスを制限することにより、権限を有するエンティティのみにデータの使用を認めることができる。Ｐ０では、ファイルＢおよびＣも、鍵ＩＤ「鍵２」を有する鍵を使用して暗号化されている。
【００８６】
データの機密保護と完全性は、コンテンツ暗号化鍵（ＣＥＫ）をＣＥＫ当たり１つずつ使用する、対称暗号化法で提供することができる。ＳＳＡの実施形態では、ＣＥＫの鍵値がフラッシュ装置（例えば、フラッシュカード）によって生成または受信され、内部でのみ使用され、外部に対して秘密に保たれる。暗号化されるデータでハッシュ計算を行うか、あるいは暗号を連鎖ブロック化することによって、データ完全性を確保することもできる。
【００８７】
パーティション内のすべてのデータが、異なる鍵によって暗号化されるとともに、異なる鍵ＩＤが割り振られるわけではない。公開またはユーザファイルの中、またはオペレーティングシステム領域（すなわち、ＦＡＴ）の中で、一定の論理アドレスに、鍵または鍵リファレンスが割り振られない場合がある。それゆえ、パーティション自体にアクセスできるエンティティであれば、いずれもこれにアクセスすることができる。
【００８８】
鍵およびパーティションの作成や、パーティションにおけるデータの読み書きや、鍵の使用を望むエンティティは、アクセス制御記録（ＡＣＲ）を通じてＳＳＡシステムにログインする必要がある。ＳＳＡシステムにおけるＡＣＲの特権は、「アクション」と呼ばれる。どのＡＣＲでも３種類のアクション、すなわちパーティションおよび鍵／鍵ＩＤの作成と、パーティションおよび鍵へのアクセスと、他のＡＣＲの作成／更新と、を実行する「権限」を有することができる。
【００８９】
ＡＣＲは、ＡＣＲグループ、すなわち、ＡＧＰと呼ばれるグループに整理される。ＡＣＲの認証に成功するとＳＳＡシステムがセッションを開放し、このセッションの中でＡＣＲのアクションを実行することができる。ＡＣＲとＡＧＰは、ポリシーに従ってパーティションや鍵へのアクセスを制御するためのセキュリティデータ構造である。
【００９０】
＜ユーザパーティション＞
ＳＳＡシステムは、ユーザパーティションとも称される、１つまたは複数の公開パーティションを管理する。このパーティションは、記憶装置に存在し、記憶装置の標準的な読み書きコマンドによってアクセスされうるパーティションである。パーティションのサイズと装置上のパーティションの存在とに関する情報の取得は、ホストシステムから隠されないことが好ましい。
【００９１】
ＳＳＡシステムでは、一般的な読み書きコマンドまたはＳＳＡコマンドのいずれかによって、このパーティションにアクセスすることができる。したがって、パーティションへのアクセスは、特定のＡＣＲに限定されないことが好ましい。しかしなら、ＳＳＡシステムでは、ホスト装置をユーザパーティションへのアクセスに限定しうるようにすることができる。読出しおよび書込みのアクセスは、個別に有効／無効にされうる。４つすべての組合せ（例えば、書込み限定、読出し限定（書込み防止）、読出しおよび書込み、およびアクセスなし）が可能である。
【００９２】
ＳＳＡシステムは、ＡＣＲによって、鍵ＩＤをユーザパーティション内のファイルと関連付け、このような鍵ＩＤに関連する鍵を用いて個々のファイルを暗号化することができる。ユーザパーティション内の暗号化されたファイルへのアクセスと、パーティションに対するアクセス権の設定とは、ＳＳＡコマンドセットを用いて行われることになる。前述の機能は、ファイルに編成されないデータにも適用される。
【００９３】
＜ＳＳＡパーティション＞
ＳＳＡパーティションは、ＳＳＡコマンドのみによってアクセスされうる、（認証されていない当事者から）隠されたパーティションである。ＳＳＡシステムでは、ＡＣＲへのログオンによって確立されたセッション（後述する）以外からは、ホスト装置がＳＳＡパーティションにアクセスできないことが好ましい。同様に、ＳＳＡは、確立されたセッションからの要求がない限り、ＳＳＡパーティションの存在、サイズ、およびアクセス権限に関する情報を提供しないことが好ましい。
【００９４】
パーティションへのアクセス権は、ＡＣＲ許可から得られる。ＡＣＲがＳＳＡシステムにログインされた時点で、ＳＳＡシステムは他のＡＣＲとパーティションを共有することができる（後述）。パーティションが作成されると、ホストは、そのパーティションに対するリファレンス名またはＩＤ（例えば、図３および４におけるＰ０〜Ｐ３）を提供する。このリファレンスは、パーティションへのさらなる読出しおよび書込みコマンドに使用される。
【００９５】
＜記憶装置の分割＞
装置の使用可能な記憶容量のすべてが、ユーザパーティションと、その時点で構成済みのＳＳＡパーティションとに割り当てられることが好ましい。したがって、再分割において、既存のパーティションの再構成を伴うことがある。装置容量（全パーティションの合計サイズ）の正味の変化は、ゼロである。装置メモリ空間におけるパーティションのＩＤは、ホストシステムによって設定される。
【００９６】
ホストシステムは、既存パーティションのいずれか１つを２つのより小さいパーティションに再分割したり、２つの既存パーティション（隣接する場合とそうでない場合とがある）を１つに併合したりすることができる。分割されたパーティションや併合されたパーティションの中のデータは、ホストの判断で消去するか、あるいは現状のまま残すことができる。
【００９７】
記憶装置の再分割によってデータが（記憶装置の論理アドレス空間の中での消去や移動により）失われるおそれがあるため、ＳＳＡシステムは、再分割において厳重な制限を課す。つまり、ルートＡＧＰ（後述）に常駐するＡＣＲにのみ再分割コマンドの発行が許可され、これが参照できるパーティションは自身が所有するパーティションのみである。パーティションの中でデータがどのように構成されているかはＳＳＡシステムには分からないため（ＦＡＴまたはその他のファイルシステム構造）、装置の再分割において構成を組み直すことに関与するのはホストである。
【００９８】
ユーザパーティションの再分割によって、ホストＯＳから見たこのパーティションのサイズおよびその他の属性は変化する。
【００９９】
再分割の後、ホストシステムは、ＳＳＡシステムにおけるＡＣＲが不在パーティションを参照していないことを確認する責任がある。これらのＡＣＲが適切に削除または更新されなければ、不在パーティションに対してこれらのＡＣＲに代わって行われるアクセスの試みは以後システムによって検出され、拒絶される。削除される鍵および鍵ＩＤについても同様の配慮がなされる。
【０１００】
＜鍵、鍵ＩＤ、および論理的保護＞
ある特定の非表示パーティションに書き込まれたファイルは、不特定多数の人に対して非表示にされる。しかし、いったんエンティティ（敵対的なエンティティ、またはそうでないエンティティ）が情報を得てこのパーティションにアクセスすると、そのファイルは使用可能となり一目瞭然となる。そのファイルのさらなる安全確保のため、ＳＳＡは非表示パーティションでファイルを暗号化でき、このファイルの復号化に用いる鍵にアクセスするための認証情報は、好ましくはパーティションにアクセスするためのものとは異なるものにする。ファイルはホストによって全面的に制御され、管理されるため、ファイルにＣＥＫを割り振ることには問題がある。これを解決するには、ＳＳＡが了解する何か、すなわち鍵ＩＤにファイルを関連付ける。つまりＳＳＡによって鍵が作成されると、ホストはその鍵を用いて暗号化されるデータにこの鍵の鍵ＩＤを割り振る。鍵が鍵ＩＤとともにＳＳＡに送信される場合、鍵と鍵ＩＤを互いに関連付けることは容易である。
【０１０１】
鍵値および鍵ＩＤは論理セキュリティを提供する。所与の鍵ＩＤに関連付けられたすべてのデータは、その場所とは関係なく、そのリファレンス名または鍵ＩＤがホストアプリケーションによって作成されて一意的に提供されるコンテンツ暗号化鍵（ＣＥＫ）における同じ鍵値で暗号化される。あるエンティティが（ＡＣＲによる認証によって）非表示パーティションへのアクセスを得て、このパーティション内の暗号化されたファイルに対して読出しまたは書込みを行いたい場合、そのエンティティは、ファイルと関連付けられる鍵ＩＤにアクセスする必要がある。ＳＳＡは、この鍵ＩＤに対する鍵へのアクセスを認めるとき、この鍵ＩＤに関連付けられたＣＥＫの鍵値をロードし、これをホストに送信する前にデータを復号化するか、あるいはこれをフラッシュメモリ２０に書き込む前にデータを暗号化する。一実施形態では、鍵ＩＤに関連付けられたＣＥＫの鍵値は、ＳＳＡシステムによって一度無作為に作成されて、ＳＳＡシステムによって維持される。ＳＳＡシステムの外部には、ＣＥＫのこの鍵値を認識し、またはこれにアクセスする者は誰もいない。外界は、リファレンスまたは鍵ＩＤを提供して使用するだけで、ＣＥＫの鍵値を提供も使用もしない。鍵値は、完全に管理され、好ましくはＳＳＡのみによりアクセス可能であることが好ましい。あるいは、鍵はＳＳＡシステムに提供されてもよい。
【０１０２】
ＳＳＡシステムは、以下の暗号モードのいずれか１つ（ユーザ定義の）を用いて、鍵ＩＤと関連付けられたデータを保護する（ＣＥＫの鍵値とともに使用される実際の暗号アルゴリズムは、システムによって制御されて外界に暴露されない）。
【０１０３】
ブロックモード：データはブロックに分割され、それらの一つ一つが個々に暗号化される。このモードは、一般に機密性がさほど高くなく、かつ辞書攻撃に敏感であると考えられる。しかしながら、このモードによりユーザは、データブロックのいずれか１つに無作為にアクセスすることができる。
【０１０４】
連鎖モード：データはブロックに分割され、ブロックは暗号化プロセス中に連鎖される。あらゆるブロックが次の１つの暗号化プロセスへの入力の１つとして使用される。このモードでは、機密性が比較的高いと考えられるが、データは最初から最後まで順番に読み書きされ、ユーザには受け入れられない可能性があるオーバーヘッドを作成する。
【０１０５】
ハッシュ化：データの完全性を実証するために使用されうるデータダイジェストを新たに作成する連鎖モード。
【０１０６】
＜ＡＣＲおよびアクセス制御＞
ＳＳＡは、複数のアプリケーションの一つ一つがシステムデータベースにおけるノードのツリーとして表される複数のアプリケーションを処理するように、設計される。ツリーブランチ間のクロストークがないようにして、アプリケーション間の相互排除が実現される。
【０１０７】
ＳＳＡシステムにアクセスするために、あるエンティティは、システムのＡＣＲの１つを介して接続を確立する必要がある。ユーザが接続の対象として選定したＡＣＲに組み込まれた定義に従って、ログイン手続きがＳＳＡシステムによって管理される。
【０１０８】
ＡＣＲは、ＳＳＡシステムに至る個々のログイン地点である。ＡＣＲは、ログイン認証情報と認証方法を保持する。読出し特権や書込み特権を含むＳＳＡシステムの中でのログイン権限も、この記録の中にある。これを示す図５には、同じＡＧＰの中にｎ個のＡＣＲがある。これは、ｎ個のＡＣＲのうちの少なくとも一部のＡＣＲが、同じ鍵へのアクセスを共有しうることを意味する。それゆえ、ＡＣＲ＃１とＡＣＲ＃ｎは鍵ＩＤ「鍵３」を有する鍵へのアクセス権を共有する。ここで、ＡＣＲ＃１とＡＣＲ＃ｎはＡＣＲ＿ＩＤであり、「鍵３」は鍵の鍵ＩＤであり、この鍵を用いて「鍵３」に関連するデータが暗号化される。複数ファイルまたは複数データ群の、暗号化および／または復号化に、同じ鍵を使用することもできる。
【０１０９】
ＳＳＡシステムは、ログインに成功した時点でシステムにおけるユーザの特権が変わる場合など、認証アルゴリズムおよびユーザ認証情報が変わる可能性のあるシステムに対して、複数のタイプのログインをサポートする。図５は、さらに別のログインアルゴリズムおよび認証情報を示している。ＡＣＲ＃１はパスワード・ログイン・アルゴリズムおよび認証情報としてのパスワードを規定しているのに対して、ＡＣＲ＃２はＰＫＩ（公開鍵基盤）ログインアルゴリズムおよび認証情報としての公開鍵を規定している。それゆえ、ログインするために、あるエンティティは、有効なＡＣＲ＿ＩＤとともに正しいログインアルゴリズムおよび認証情報を提示する必要がある。
【０１１０】
ＳＳＡシステムのＡＣＲにログインしたエンティティの権限、すなわちＳＳＡコマンドを使用する権利は、ＡＣＲと関連付けられた権限制御記録（ＰＣＲ）の中で設定する。図５のＰＣＲに示すように、ＡＣＲ＃１は「鍵３」と関連付けられたデータに対して読出し限定権限を許諾し、ＡＣＲ＃２は「鍵５」と関連付けられたデータの読出し権限と書込み権限とを許諾する。
【０１１１】
読出しや書込みに使う鍵などの異なるＡＣＲが、システムで共通の利益や特権を共有することがある。このため、共通する部分があるＡＣＲはＡＧＰ、すなわちＡＣＲグループにグループ分けされる。それゆえ、ＡＣＲ＃１とＡＣＲ＃ｎはいずれも、鍵ＩＤ「鍵３」を有する鍵へのアクセス権がある。
【０１１２】
ＡＧＰとその中にあるＡＣＲは階層状のツリーの中で編成されるため、ＡＣＲは重要データの安全性を保つ安全鍵を作成できるほか、好ましくは自身の鍵ＩＤ／パーティションに対応する他のＡＣＲ項目を作成することもできる。これらの子ＡＣＲは、その父、すなわち作成元と同じ権限を有するかそれよりも少ない権限を有することになり、父ＡＣＲ自身が作成した鍵の権限が付与される場合がある。言うまでもなく、子ＡＣＲは自身が作成する任意の鍵に対するアクセス権限を取得する。これは図６に例示されている。このように、ＡＧＰ１２０の中にあるＡＣＲはいずれもＡＣＲ１２２によって作成されたものであり、これらのＡＣＲのうちの２つは、「鍵３」と関連付けられたデータへのアクセス権限をＡＣＲ１２２から継承している。
【０１１３】
＜ＡＧＰ＞
ＳＳＡシステムへのログインにおいて、ＡＧＰと、そのＡＧＰの中にあるＡＣＲを指定する。
【０１１４】
ＡＧＰはいずれも一意なＩＤ（リファレンス名）を有し、ＳＳＡデータベースにおける該当する項目への索引として使用される。ＡＧＰ名は、ＡＧＰの作成時にＳＳＡシステムに提供される。ＳＳＡは、提供されるＡＧＰ名がシステムに既に存在する場合に、作成動作を拒絶することになる。
【０１１５】
以降の節で説明するように、アクセス権限や管理権限の委譲に関わる制限事項は、ＡＧＰを使用して管理運営される。完全に独立したエンティティ、例えば２つの異なるアプリケーションまたは２つの異なるコンピュータユーザによるアクセスの制御運営は、図６の２つのツリーが果たす役割の１つである。ここで重要でありうることは、２つのアクセスプロセスが、たとえ同時に発生する場合でも、事実上互いに独立する（すなわち、事実上クロストークをなくす）ことである。これは、それぞれのツリーにおけるＡＣＲとＡＧＰの認証、権限、追加作成などが他のツリーにおけるものと無関係であり、かつ他のツリーにおけるものに左右されないことを意味する。このため、ＳＳＡシステムを使用するメモリ１０では、複数のアプリケーションを同時に処理することができる。また、２つのアプリケーションが、互いに自立的に２つの別々のデータ群（例えば、１組の写真と１組の曲）にアクセスすることも可能になる。これは図６に例示されている。それゆえ、図６の上部で、ツリーの中にあるノード（ＡＣＲ）を通じてアクセスするアプリケーションまたはユーザにとって、「鍵３」、「鍵Ｘ」、および「鍵Ｚ」と関連付けられたデータは、写真を備えていてもよい。図６の下部で、ツリーのノード（ＡＣＲ）を通じてアクセスするアプリケーションまたはユーザにとって、「鍵５」および「鍵Ｙ」と関連付けられたデータは、曲を備えていてもよい。ＡＧＰを作成したＡＣＲは、このＡＧＰにＡＣＲ項目がなく空になっている場合に限り、このＡＧＰを削除する権限を有する。
【０１１６】
＜エンティティにとってのＳＳＡの入口：アクセス制御記録（ＡＣＲ）＞
ＳＳＡシステムのＡＣＲは、エンティティによるシステムログインのあり方を記述するものである。ＳＳＡシステムにログインするエンティティは、これから始まる認証プロセスに該当するＡＣＲを指定する必要がある。図５に示すように、ＡＣＲの中にある権限制御記録（ＰＣＲ）は、ＡＣＲに記載の認証を終えたユーザが実行できる許諾アクションを説明するものである。ホスト側エンティティは、すべてのＡＣＲデータフィールドを提供する。
【０１１７】
ＡＣＲへのログオンに成功したエンティティは、ＡＣＲのパーティションおよび鍵アクセス権限およびＡＣＭ権限（後述）のすべてを照会することができることになる。
【０１１８】
＜ＡＣＲ＿ＩＤ＞
ＳＳＡシステムのエンティティがログインプロセスを開始する場合、すべてのログイン要件が満たされているときにＳＳＡが正しいアルゴリズムをセットアップして正しいＰＣＲを選択するように、ログイン方法に対応するＡＣＲ＿ＩＤ（ＡＣＲが作成されたときにホストによって提供される）を指定する必要がある。ＡＣＲ＿ＩＤは、ＡＣＲが作成されるときにＳＳＡシステムに提供される。
【０１１９】
＜ログイン／認証アルゴリズム＞
認証アルゴリズムは、エンティティによって使用されるログイン手続きと、ユーザのアイデンティティを証明するために必要な認証情報と、を指定するものである。ＳＳＡシステムは、手続きなし（および認証情報なし）から、パスワードに基づく手続き、対称暗号法または非対称暗号法に基づく双方向認証プロトコルまで、複数の標準ログインアルゴリズムをサポートする。
【０１２０】
＜認証情報＞
エンティティの認証情報は、ログインアルゴリズムに対応しており、ＳＳＡがユーザを検証して認証するために使用される。認証情報の例として、パスワード認証用のパスワード／ＰＩＮ数、ＡＥＳ認証用のＡＥＳ鍵、などが挙げられる。認証情報のタイプ／形式（すなわち、ＰＩＮ、対称鍵など）は、事前に決められ、認証モードから得られ、ＡＣＲを作成するときにＳＳＡシステムに提供される。ＳＳＡシステムはこれら認証情報の設定、提供、および管理に関与しないが、例外としてＰＫＩベースの認証では装置（例えば、フラッシュカード）を使用してＲＳＡなどのタイプの鍵対を生成することができ、証明書生成のための公開鍵をエクスポートすることができる。
【０１２１】
＜権限制御記録（ＰＣＲ）＞
ＰＣＲは、ＳＳＡシステムにログインしＡＣＲの認証プロセスに合格した後の、エンティティに対する許諾内容を示すものである。権限には、パーティションおよび鍵の作成権限と、パーティションおよび鍵へのアクセス権限と、エンティティ−ＡＣＲ属性の管理権限の３種類がある。
【０１２２】
＜パーティションへのアクセス＞
ＰＣＲのこの部分には、ＡＣＲ段階を首尾よく終了したエンティティがアクセスしうるパーティションのリストが含まれる（ＳＳＡシステムへ提供されるパーティションのＩＤを使用）。各パーティションに対して、アクセスのタイプが、書込み限定または読出し限定に制限される場合があり、あるいは完全書込み／読出しアクセス権が指定される場合もある。図５のＡＣＲ＃１は、パーティション＃２にアクセスすることができてもパーティション＃１にはアクセスすることができない。ＰＣＲにおいて指定される制限は、ＳＳＡパーティションおよび公開パーティションに適用される。
【０１２３】
公開パーティションには、ＳＳＡシステムをホストする装置（例えば、フラッシュカード）に対する通常の読出しおよび書込みコマンドによってアクセスすることや、ＳＳＡコマンドによってアクセスすることができる。公開パーティションを制限する権限を有するルートＡＣＲ（後述）が作成されると、このルートＡＣＲは、その権限を自身の子に渡すことができる。ＡＣＲは、通常の読出しおよび書込みコマンドによる公開パーティションへのアクセスのみを制限することができることが好ましい。ＳＳＡシステムのＡＣＲは、これが作成されるときにのみ制限することができることが好ましい。公開パーティションに対する読出し／書込み権限をＡＣＲが取得した時点では、その権限を剥奪することができないことが好ましい。
【０１２４】
＜鍵ＩＤへのアクセス＞
ＰＣＲのこの部分は、エンティティのログインプロセスによってＡＣＲポリシーが満たされているときにエンティティがアクセスできる、鍵ＩＤのリスト（ホストによってＳＳＡシステムに提供される）と関連付けられたデータを含んでいる。ＰＣＲに記載されたパーティションに常駐するファイルには、指定された鍵ＩＤが関連付けられる。装置（例えば、フラッシュカード）の論理アドレスに鍵ＩＤは関連付けられないので、ある特定のＡＣＲに対して２つ以上のパーティションが関連付けられるとき、それらのパーティションのいずれか１つの中にはファイルがありうる。ＰＣＲ内で指定された鍵ＩＤは、それぞれ異なる１組のアクセス権を有しうる。鍵ＩＤによって指示されるデータへのアクセスは、書込み限定または読出し限定に制限される場合があり、あるいは完全書き込み／読出しアクセス権が指定される場合もある。
【０１２５】
＜ＡＣＲ属性管理（ＡＣＡＭ）＞
この節では、ＡＣＲのシステム属性を変更しうる場合について説明する。
【０１２６】
ＳＳＡシステムで許可されうるＡＣＡＭアクションは、次の通りである。
１．ＡＧＰおよびＡＣＲの作成／削除／更新
２．パーティションおよび鍵の作成／削除
３．鍵およびパーティションに対するアクセス権の委譲
【０１２７】
父ＡＣＲは、ＡＣＡＭ権限を編集することができないことが好ましい。この場合、好ましくはＡＣＲの削除と再作成が必要となる。また、ＡＣＲによって作成された鍵ＩＤに対するアクセス権限を、剥奪することができないことが好ましい。
【０１２８】
ＡＣＲは、他のＡＣＲおよびＡＧＰを作成する能力を有していてもよい。ＡＣＲを作成するということは、その作成元が所有するＡＣＡＭ権限の一部または全部が、作成されたＡＣＲへ委譲されることを意味する場合もある。ＡＣＲを作成する権限を有するということは、次のアクションの権限を有することを意味する。
１．子の認証情報を設定し編集する：作成元ＡＣＲによっていったん設定された認証方法は編集することができないことが好ましい。子向けに既に設定された認証アルゴリズムの範囲内で、認証情報を変更してもよい。
２．ＡＣＲを削除する。
３．作成権限を子ＡＣＲへ委譲する（それゆえ孫を有する）。
【０１２９】
他のＡＣＲを作成する権限を有するＡＣＲは、これが作成するＡＣＲに遮断解除権限を委譲する権限を有する（ただし、ＡＣＲの遮断を解除する権限を有しない場合もある）。父ＡＣＲは、解除ＡＣＲのリファレンスを子ＡＣＲの中に入れる。
【０１３０】
父ＡＣＲは、自身の子ＡＣＲを削除する権限を有する唯一のＡＣＲである。ＡＣＲが作成した下位ＡＣＲを削除すると、この下位ＡＣＲから生まれたすべてのＡＣＲも自動的に削除される。ＡＣＲを削除すると、そのＡＣＲによって作成された鍵ＩＤとパーティションはすべて削除される。
【０１３１】
例外として、ＡＣＲが自身の記録を更新できる場合が２つある。
１．作成元ＡＣＲによって設定されたパスワード／ＰＩＮであっても、それらを含むＡＣＲによってのみ更新されうる。
２．ルートＡＣＲは、それ自体と、それ自体が常駐するＡＧＰと、を削除しうる。
【０１３２】
＜鍵およびパーティションへのアクセス権の委譲＞
ＡＣＲとそのＡＧＰは階層状のツリーで組み立てられ、ルートＡＧＰとその中にあるＡＣＲは、ツリーの最上部に位置する（例えば、図６のルートＡＧＰ１３０および１３２）。ＳＳＡシステムには複数のＡＧＰツリーが存在することがあるが、それらは互いに完全に分離されている。ＡＧＰの中にあるＡＣＲは、それ自体の鍵に対するアクセス権限を、同じＡＧＰの中にある全ＡＣＲと、それらによって作成されるこの全ＡＣＲに委譲しうる。鍵を作成する権限は、その鍵を使用するためのアクセス権限を委譲する権限を含むことが好ましい。
【０１３３】
鍵に対する権限は３種類に分けられる。
１．アクセス：これは鍵に対するアクセス権限、すなわち読出しと書込みとを設定する。
２．所有権：当然ながら、鍵を作成したＡＣＲがその所有者である。この所有権は、ある１つのＡＣＲから別のＡＣＲ（同じＡＧＰの中にあるか、あるいは子ＡＧＰの中にあるＡＣＲという条件で）に委譲することができる。鍵の所有権は、鍵を削除する権限のほかに、鍵に対する権限を委譲する権限を提供する。
３．アクセス権委譲：この権限により、ＡＣＲは、自身が保持する権利を委譲することができる。
【０１３４】
ＡＣＲは、自身が作成したパーティションのほかに、自身が所有するアクセス権限の対象となる他のパーティションに対するアクセス権限を、委譲することができる。
【０１３５】
権限を委譲するには、パーティションの名前と鍵ＩＤを、指定されたＡＣＲのＰＣＲに追加する。鍵のアクセス権限を委譲するには、鍵ＩＤを使用してもよいし、あるいは委譲する側のＡＣＲのすべての作成された鍵がアクセス権限の対象となることを表明してもよい。
【０１３６】
＜ＡＣＲの遮断および解除＞
システムによるエンティティのＡＣＲ認証プロセスが失敗すると、ＡＣＲの遮断カウンタがインクリメントする場合がある。一定の最大失敗認証数（ＭＡＸ）に達すると、ＳＳＡシステムによってＡＣＲは遮断されることになる。
【０１３７】
遮断されたＡＣＲは、この遮断されたＡＣＲから参照される別のＡＣＲによって、解除されうる。この解除されたＡＣＲに対するリファレンスは、その作成元によるＡＣＲによって設定される。解除するＡＣＲは、遮断されたＡＣＲの作成元と同じＡＧＰの中にあり、「解除」権限を有することが好ましい。
【０１３８】
システムの中のほかのＡＣＲは、いずれも遮断されたＡＣＲを解除することができない。遮断カウンタを用いて構成されるＡＣＲであっても、解除ＡＣＲがなければ、遮断された場合に解除することができない。
【０１３９】
＜ルートＡＧＰ−アプリケーションデータベースの作成＞
ＳＳＡシステムは、複数のアプリケーションを処理し、各アプリケーションのデータを分離するように設計されている。アプリケーション特有のデータを識別し、かつ分離する場合には、ＡＧＰシステムのツリー構造が主要なツールとして使用される。ルートＡＧＰは、アプリケーションＳＳＡデータベースツリーの先端に位置し、いくぶん異なる挙動ルールに従う。ＳＳＡシステムでは、複数のルートＡＧＰを構成することができる。図６には、２つのルートＡＧＰ１３０および１３２が示されている。もちろん、これよりも少ないＡＧＰやこれよりも多いＡＧＰが使用されてもよく、その場合も本発明の範囲内にある。
【０１４０】
新規アプリケーションのための装置（例えば、フラッシュカード）の登録、および／または、装置の新規アプリケーションの認証情報発行は、装置に新たなＡＧＰ／ＡＣＲツリーを追加する過程で行われる。
【０１４１】
ＳＳＡシステムは、ルートＡＧＰ（ならびにルートＡＧＰの全ＡＣＲとその権限）を作成する場合に、以下の３種類のモードをサポートする。
１．オープンモード：どんな認証も必要としないすべてのユーザまたはエンティティ、あるいはシステムＡＣＲ（後述）を通じて認証されたユーザ／エンティティは、新規ルートＡＧＰを作成することができる。オープンモードによるルートＡＧＰの作成は、セキュリティ対策なしですべてのデータ転送がオープンチャネル（すなわち、発行エンティティのセキュア環境内）で行われる場合と、システムＡＣＲ認証（すなわち、Ｏｖｅｒ  Ｔｈｅ  Ａｉｒ（ＯＴＡ）および後発行手続き）を通じて確立されるセキュアチャネルを通じて行われる場合と、がある。
【０１４２】
システムＡＣＲが構成されず（これはオプション機能である）、かつルートＡＧＰ作成モードをオープンに設定する場合に、オープン・チャネル・オプションのみが利用される。
２．制御モード：システムＡＣＲを通じて認証されたエンティティのみが、新規ルートＡＧＰを作成することができる。システムＡＣＲが構成されなければ、ＳＳＡシステムをこのモードに設定することはできない。
３．ロックモード：ルートＡＧＰの作成は無効にされ、さらなるルートＡＧＰをシステムに加えることはできない。
【０１４３】
２つのＳＳＡコマンドで、この機能を制御する（これらのコマンドは、いずれのユーザ／エンティティでも認証なしで利用可能である）。
１．方法構成コマンド：３つのルートＡＧＰ作成モードのいずれか１つを使用するようにＳＳＡシステムを構成するために、使用される。オプション→制御、制御→ロックのモード変更のみが可能である（すなわち、ＳＳＡシステムが現在制御モードとして構成されている場合は、ロックモードにしか変更することができない）。
２．方法構成固定コマンド：方法構成コマンドを無効にし、現在選択されている方法を永続的に固定するために使用される。
【０１４４】
ルートＡＧＰが作成されるとき、特別な初期化モードに入り、ＡＣＲの作成、構成（ルートＡＧＰの作成に適用されたものと同じアクセス制限を使用）が可能になる。ルートＡＧＰ構成プロセスの最後に、エンティティがこれを明示的に作動モードに切り替えると、既存のＡＣＲは更新できなくなり、ＡＣＲを新たに作成できなくなる。
【０１４５】
標準モードに入ったルートＡＧＰを削除するには、そのＡＣＲのうち、ルートＡＧＰの削除する権限が割り当てられるＡＣＲの１つを通じて、システムにログインしなければならない。特別の初期化モードと同様に、これもルートＡＧＰの例外の一例である。上記のＡＧＰは、次のツリーレベルにあるＡＧＰとは対照的に、それ自体のＡＧＰを削除する権限を有するＡＣＲを含みうる唯一のＡＧＰであることが好ましい。
【０１４６】
ルートＡＣＲと標準ＡＣＲとの３番目にして最後の違いは、パーティションを作成し削除する権限を有しうるシステム内で、唯一のＡＣＲであるということである。
【０１４７】
＜ＳＳＡシステムＡＣＲ＞
システムＡＣＲは、次の２つのＳＳＡ操作に使用されてもよい。
１．不利な状況にある保護されたチャネルの保護下で、ＡＣＲ／ＡＧＰツリーを作成する。
２．ＳＳＡシステムをホストする装置を識別し、認証する。
【０１４８】
ＳＳＡの中にシステムＡＣＲが１つだけある事が好ましく、いったん設定されたシステムＡＣＲは変更することができないことが好ましい。システムＡＣＲを作成するときにシステム認証は必要でなく、必要なのはＳＳＡコマンドのみである。システムＡＣＲ作成機能は、無効にすることができる（ルートＡＧＰ作成機能と同様）。１つのみのシステムＡＣＲが認められることが好ましいため、システムＡＣＲ作成コマンドはシステムＡＣＲの作成後には影響を及ぼさない。
【０１４９】
システムＡＣＲは、その作成プロセスにおいて機能しない。作成が終了した時点で、システムＡＣＲが作成されて準備が整ったことを伝える専用のコマンドを発行する必要がある。この時点以後、システムＡＣＲの更新や差替えは行うことができないことが好ましい。
【０１５０】
システムＡＣＲは、ＳＳＡにおいてルートＡＣＲ／ＡＧＰを作成する。システムＡＣＲは、ホストがルートレベルに満足し遮断するまで、ルートレベルを追加／変更する権限を有する。ルートＡＧＰを遮断すると、基本的にはシステムＡＣＲとの接続が遮断され、改ざん不能となる。この時点で、ルートＡＧＰとその中にあるＡＣＲを、誰も変更／編集することができない。これは、ＳＳＡコマンドを介して行われる。ルートＡＧＰの作成を無効にする作用は永続し、元に戻すことはできない。図７には、システムＡＣＲが関わる前述した機能が示されている。システムＡＣＲを使用して、３種類のルートＡＧＰが作成される。図７で、システムＡＣＲをルートＡＧＰに接続する点線で示すように、これらのルートＡＧＰが作成された後のある時点で、システムＡＣＲからルートＡＧＰを遮るＳＳＡコマンドがホストから送信され、ルートＡＧＰ作成機能が無効になる。これで３つのルートＡＧＰは改ざん不能となる。ルートＡＧＰが遮断される前または後に、３つのルートＡＧＰを使用して子ＡＧＰを作ることにより、３つの別々のツリーが形成される。
【０１５１】
前述した機能は、コンテンツの所有者が、コンテンツを使用して安全な製品を構成する際に、優れた柔軟性を提供する。セキュア製品は「発行（issued）」する必要がある。発行とは、装置がホストを識別しホストが装置を識別するための識別鍵を出すプロセスである。ホストは、装置（例えば、フラッシュカード）を識別することにより、これの秘密を信用できるかどうかを判定することができる。一方、装置はホストを識別することにより、ホストが実施を許容されている範囲でのみ、セキュリティポリシーを実施する（特定のホストコマンドを許諾し実行する）ことができる。
【０１５２】
複数のアプリケーションに対応するように設計される製品は、複数の識別鍵を有することになる。製品は「前発行」するか（出荷に先立つ製造中に鍵を記憶する）、あるいは「後発行」する（出荷後に新たな鍵を追加する）。後発行の場合、ある種の親鍵または装置レベル鍵をメモリ装置（例えば、メモリカード）に入れる必要があり、この鍵は、装置へのアプリケーションの追加が許可されるエンティティを識別するために使用される。
【０１５３】
前述した機能により、後発行を有効／無効にするように、製品を構成することができる。さらに、後発行構成は出荷後に安全に果たすことができる。装置は、前述した親鍵または装置レベル鍵のほかには鍵のない状態で小売製品として購入され、この後、新たな所有者により、さらなる後発行アプリケーションを有効または無効にするように構成することができる。
【０１５４】
それゆえ、システムＡＣＲ機能は、前述の目的を達成するための能力を提供する。
・システムＡＣＲがないメモリ装置は、アプリケーションを無制限かつ自由に追加することができる。
・システムＡＣＲがないメモリ装置は、システムＡＣＲの作成を無効にするように構成することができ、これは新規アプリケーションの追加を制御できないことを意味する（新規ルートＡＧＰ作成機能も無効にしない限り）。
・システムＡＣＲがあるメモリ装置は、システムＡＣＲ認証情報を用いた認証手続きによって確立されるセキュアチャネルを介して、アプリケーションの追加を制御できるだけである。
・システムＡＣＲがあるメモリ装置は、アプリケーションが追加される前かあるいは追加された後に、アプリケーション追加機能を無効にするように構成することができる。
【０１５５】
＜鍵ＩＤリスト＞
鍵ＩＤは、具体的なＡＣＲ要求に従って作成されるが、メモリシステム１０でこれを使用するのはＳＳＡシステムのみである。鍵ＩＤの作成時に作成元ＡＣＲから提供されるか、あるいは作成元ＡＣＲに提供されるデータは、次の通りである。
１．鍵ＩＤ：このＩＤはホストを通じてエンティティから提供され、以降のすべての読出しアクセスや書込みアクセスにおいて、鍵と、その鍵を使って暗号化または復号化されるデータと、を参照するために使用される。
２．鍵暗号およびデータ完全性モード（前述した、および以下に述べる、ブロック、連鎖、およびハッシュモード）
【０１５６】
ホストから提供される属性に加えて、ＳＳＡシステムは次のデータを維持する。
１．鍵ＩＤの所有者：所有者であるＡＣＲのＩＤ。鍵ＩＤが作成されたとき、作成元ＡＣＲがその所有者である。しかしながら、鍵ＩＤの所有権は、別のＡＣＲに譲渡されてもよい。鍵ＩＤの所有権を譲渡し、かつ鍵ＩＤを委譲できるものは、鍵ＩＤの所有者のみであることが好ましい。関連する鍵のアクセス権限の委譲と、これらの権利の失効を管理できるのは、鍵ＩＤの所有者か、または委譲権限を割り当てられたその他のＡＣＲである。ＳＳＡシステムは、これらの操作のいずれか１つが試みられるときに、操作を要求するＡＣＲにその権限が付与されている場合に限り、操作を許諾することになる。
２．ＣＥＫ：このＣＥＫの鍵値は、鍵ＩＤが関連付けられたコンテンツ、または、鍵ＩＤによって指示されたコンテンツの暗号化に使用される。鍵値は、ＳＳＡシステムによって生成される１２８ビットＡＥＳランダム鍵であってもよい。
３．ＭＡＣおよびＩＶ値：連鎖ブロック暗号（ＣＢＣ）暗号化アルゴリズムで使用される動的情報（メッセージ認証コードと開始ベクトル）。
【０１５７】
図８Ａ〜図１６のフローチャートを参照して、ＳＳＡの様々な機能を例示する。これらの図で、ステップの左側に記された「Ｈ」はホストによって実施される操作を意味し、「Ｃ」はカードによって実施される操作を意味する。メモリカードを参照してＳＳＡ機能を例示するが、物理的形態が異なるメモリ装置にも、これらの機能が当てはまることは理解されよう。システムＡＣＲを作成するため、ホストはメモリ装置１０のＳＳＡに向けて、システムＡＣＲ作成コマンドを発行する（ブロック２０２）。装置１０はこれに応じて、システムＡＣＲが既に存在するかどうかをチェックする（ブロック２０４、菱形２０６）。装置１０は、これが既に存在する場合に失敗ステータスを返し、停止する（長円形２０８）。メモリ１０は、これが既に存在しない場合に、システムＡＣＲの作成が許可されるかどうかをチェックし（菱形２１０）、許可されない場合は失敗ステータスを返す（ブロック２１２）。それゆえ、必要なセキュリティ機能が事前に決まるので、システムＡＣＲが必要とされない場合など、装置発行者がシステムＡＣＲの作成を許可しない場合もある。許可される場合、装置１０はＯＫステータスを返し、ホストからシステムＡＣＲ認証情報が届くのを待つ（ブロック２１４）。ホストはＳＳＡステータスをチェックし、システムＡＣＲの作成が許可されていることを装置１０が伝えているかどうかをチェックする（ブロック２１６および菱形２１８）。作成が許可されないか、あるいはシステムＡＣＲが既に存在する場合、ホストは停止する（長円形２２０）。システムＡＣＲの作成が許可されていることを装置１０が伝える場合、ホストはそのログイン認証情報を設定するＳＳＡコマンドを発行し、これを装置１０へ送信する（ブロック２２２）。装置１０は、受信した認証情報でシステムＡＣＲ記録を更新し、ＯＫステータスを返す（ブロック２２４）。ホストはこのステータス信号に応じて、システムＡＣＲの準備が整っていることを示すＳＳＡコマンドを発行する（ブロック２２６）。これに応じて装置１０はシステムＡＣＲをロックするので、システムＡＣＲの更新や差替えはできなくなる（ブロック２２８）。これにより、システムＡＣＲの機能と、ホストに対して装置１０を識別するためのアイデンティティと、が固定される。
【０１５８】
新規ツリー（新規ルートＡＧＰおよびＡＣＲ）の作成手順は、それらの機能が装置でどのように構成されているかによって決まる。図９は、その手順を説明するものである。ホスト２４とメモリシステム１０は、いずれもこの手順を辿る。新規ルートＡＧＰの追加が完全に無効になっている場合、新規ルートＡＧＰを追加することができない（菱形２４６）。これが有効になっているが、システムＡＣＲが要求される場合、ホストはルートＡＧＰ作成コマンドの発行（ブロック２５４）に先立ち、システムＡＣＲを通じて認証し、セキュアチャネルを確立する（菱形２５０、ブロック２５２）。システムＡＣＲが要求されない場合（菱形２４８）、ホスト２４は認証なしでルートＡＧＰ作成コマンドを発行することができ、ブロック２５４へ進む。ホストは、システムＡＣＲが存在する場合、たとえこれが要求されない場合でも、これを使用することがある（フローチャートには示されていない）。装置（例えば、フラッシュカード）は、新規ルートＡＧＰ作成機能が無効になっている場合には、新規ルートＡＧＰを作成する試行を拒絶する。また、システムＡＣＲが要求される場合には、認証なしで新規ルートＡＧＰを作成する試行を拒絶する（菱形２４６および２５０）。ブロック２５４で新たに作成されるＡＧＰおよびＡＣＲは作動モードに切り替わるので、そのＡＧＰの中にあるＡＣＲの更新や変更はできなくなり、ＡＧＰへＡＣＲを追加することもできなくなる（ブロック２５６）。ここでオプションとしてシステムはロックされるので、ルートＡＧＰは追加で作成できなくなる（ブロック２５８）。点線の枠２５８は、このステップがオプションのステップであることを示す表記法である。本出願の図のフローチャートにおいて、点線で示された枠はいずれもオプションのステップである。このように、コンテンツの所有者は、正当なコンテンツを含む真正のメモリ装置を装う違法な目的に、装置１０を利用できないようにすることができる。
【０１５９】
ＡＣＲ（前述したルートＡＧＰの中にあるＡＣＲとは別のＡＣＲ）を作成するには、図１０に示すように、ＡＣＲを作成する権利を有するＡＣＲから開始することができる（ブロック２７０）。エンティティは、入口にあたるＡＣＲのアイデンティティと、作成に必要となる属性のすべてを含むＡＣＲとを提供して、ホスト２４を通じて入ることを試行することができる（ブロック２７２）。ＳＳＡは、ＡＣＲアイデンティティの一致をチェックし、さらにそのアイデンティティを有するＡＣＲにＡＣＲを作成する権限があるかどうかをチェックする（菱形２７４）。要求が認証されると証明される場合、装置１０のＳＳＡは、ＡＣＲを作成する（ブロック２７６）。
【０１６０】
図１１の２つのＡＧＰは、図１０の方法を使用するセキュリティアプリケーションで役に立つツリーを例示するものである。したがって、マーケティングＡＧＰの中でアイデンティティｍ１を有するＡＣＲには、ＡＣＲを作成する権限がある。ＡＣＲ＿ｍ１は、鍵ＩＤ「マーケティング情報」と関連付けられたデータと、鍵ＩＤ「価格リスト」と関連付けられたデータとを、鍵を用いて読み書きする権限も有する。これにより、図１０の方法を用いて、２つのＡＣＲ＿ｓ１およびｓ２を含む販売ＡＧＰを作成する。ＡＣＲ＿ｓ１およびｓ２には、鍵ＩＤ「価格リスト」と関連付けられた価格データにアクセスするための鍵の読出し権限のみあるが、鍵ＩＤ「マーケティング情報」と関連付けられたデータにアクセスする場合に必要となる鍵の権限はない。このように、ＡＣＲ＿ｓ１およびｓ２を有するエンティティは、価格データを読み出してもこれを変更することはできず、さらにマーケティングデータにはアクセスすることができない。一方、ＡＣＲ＿ｍ２にはＡＣＲを作成する権限がなく、鍵ＩＤ「価格リスト」と鍵ＩＤ「マーケティング情報」とに関連付けられたデータにアクセスするための鍵の読出し権限のみを有する。
【０１６１】
それゆえ、アクセス権は前述した方法で委譲することができ、ｍ１は、価格データを読み出す権利をｓ１およびｓ２に委譲する。これは、特に大規模なマーケティング組織や販売組織が関わる場合に有用である。しかし、販売員が１名〜少数であれば図１０の方法を使用する必要はない場合がある。代わりに、図１２に示すように、ＡＣＲから、同じＡＧＰの下位レベルまたは同じレベルに位置するＡＣＲに、アクセス権を委譲することができる。エンティティはまず、そのＡＧＰのツリーに入るため、ホストを通じてツリーの中のＡＣＲを前述したように指定する（ブロック２８０）。次にホストは、ＡＣＲと、委譲する権利と、を指定する。ＳＳＡはツリーでこのＡＣＲをチェックし、指定された別のＡＣＲに権利を委譲する権限がこのＡＣＲにあるかどうかをチェックする（菱形２８２）。権限があれば権利は委譲され（ブロック２８４）、そうでなければ停止する。図１３はその結果を示す。この場合、ＡＣＲ＿ｍ１には読出し権限をＡＣＲ＿ｓ１に委譲する権限があるため、委譲の後、ｓ１は鍵を使用して価格データにアクセスできるようになる。これは、ｍ１が価格データにアクセスするための権利またはそれ以上の権利を有し、さらにそれを委譲する権限を有する場合に実施することができる。一実施形態では、ｍ１は委譲の後にそのアクセス権を保持する。時間やアクセス数を制限するなどにより、（永続的にではなく）一定の条件のもとでアクセス権が委譲されることが好ましい。
【０１６２】
図１４は、鍵と鍵ＩＤを作成するプロセスを示す。エンティティは、ＡＣＲを通じて認証を受ける（ブロック３０２）。エンティティは、ホストによって指定されたＩＤによる鍵の作成を要求する（ブロック３０４）。ＳＳＡは、指定されたＡＣＲにその権限があるかどうかをチェックする（菱形３０６）。例えば、ある特定のパーティションにあるデータにアクセスするために鍵が使用される場合、ＳＳＡはそのパーティションにＡＣＲがアクセスできるかどうかをチェックすることになる。ＡＣＲにその権限がある場合、メモリ装置１０は、ホストから提供された鍵ＩＤと関連付けられた鍵値を作成し（ブロック３０８）、鍵ＩＤをＡＣＲに記憶し、鍵値をメモリ（コントローラ関連メモリまたはメモリ２０のいずれか）に記憶し、エンティティから提供された情報に従って権利および権限を割り当て（ブロック３１０）、割り当てられた権利および権限で該当するＡＣＲのＰＣＲを修正する（ブロック３１２）。それゆえ、読出しおよび書込み権限、同じＡＧＰの中にある他のＡＣＲまたは下位レベルのＡＣＲに委譲し共有する権利、鍵の所有権を譲渡する権利など、鍵の作成元はすべての権利を有する。
【０１６３】
図１５に示すように、ＡＣＲは、ＳＳＡシステムの中にある別のＡＣＲの権限（またはＡＣＲの存在そのもの）を変更することができる。エンティティは、これまで通りＡＣＲを通じてツリーに入る場合がある。ある事例ではエンティティの認証が行われ、エンティティはＡＣＲを指定する（ブロック３３０、３３２）。エンティティは、ターゲットＡＣＲの削除、または、ターゲットＡＣＲの権限の削除を要求する（ブロック３３４）。指定されたＡＣＲまたはその時点でアクティブなＡＣＲにその権利があれば（菱形３３６）、ターゲットＡＣＲを削除し、あるいはそのような権限を削除するためにターゲットＡＣＲのＰＣＲを変更する（ブロック３３８）。これが認可されない場合、システムは停止する。
【０１６４】
前述したプロセスの後、ターゲットは、プロセスの前にアクセスできたデータにアクセスすることができなくなる。図１６に示すように、かつて存在したＡＣＲ＿ＩＤはもはやＳＳＡに存在しないため、ターゲットＡＣＲに入ることを試行する（ブロック３５０）エンティティは認証プロセスの失敗に気付くので、アクセス権は拒絶される場合がある（菱形３５２）。ＡＣＲ＿ＩＤが削除されていないと仮定した場合、エンティティはＡＣＲを指定し（ブロック３５４）、鍵ＩＤおよび／または特定のパーティションのデータを指定し（ブロック３５６）、ＳＳＡはそのようなＡＣＲのＰＣＲに従って鍵ＩＤまたはパーティションアクセス要求が許可されるかどうかをチェックする（菱形３５８）。権限が削除されているか、あるいは失効している場合、要求は再度却下される。そうでない場合、要求は許諾される（ブロック３６０）。
【０１６５】
前述したプロセスは、ＡＣＲとそのＰＣＲが別のＡＣＲによって変更された場合であれ、あるいは初めからそのように構成されていた場合であれ、被保護データに対するアクセスが装置（例えば、フラッシュカード）によってどのように管理されるかを説明するものである。
【０１６６】
＜セッション＞
ＳＳＡシステムは、同時にログインする複数のユーザを処理するように設計されている。この機能を使用する場合、ＳＳＡによって受信されるコマンドには特定のエンティティが関連しており、コマンドは、このエンティティの認証に用いるＡＣＲに要求された動作を行う権限がある場合に限り実行される。
【０１６７】
複数のエンティティは、セッションのコンセプトによってサポートされる。セッションは認証プロセスで確立し、ＳＳＡシステムによってセッションｉｄが割り当てられる。セッションｉｄは、システムへのログインに使用されたＡＣＲに内部で関連付けられ、エンティティへエクスポートされ、それ以降のＳＳＡコマンドで使用される。
【０１６８】
ＳＳＡシステムは、２種類のセッション、すなわちオープンセッションとセキュアセッションとをサポートする。特定の認証プロセスと関連付けられたセッションのタイプは、ＡＣＲの中で設定される。ＳＳＡシステムは、認証そのものの施行と同様の方法で、セッション確立を施行する。エンティティの権限はＡＣＲで設定されるため、システム設計者は特定の鍵ＩＤに対するアクセスまたは特定のＡＣＲ管理操作（すなわち、新規ＡＣＲの作成、認証情報の設定）の実行に、セキュアトンネルを関連付けることができる。
【０１６９】
＜オープンセッション＞
オープンセッションはセッションｉｄで識別されるセッションであるが、バス暗号化は行われないため、コマンドおよびデータはいずれも暗号化されずに引き渡される。この動作モードは、エンティティが脅威モデルに該当せずバス上で傍受を行わない、多数のユーザまたは多数のエンティティ環境に使用されることが好ましい。
【０１７０】
オープン・セッション・モードではデータ送信が保護されず、ホスト側のアプリケーション間に効率的なファイアウォールは実施されないが、ＳＳＡシステムが認証済みのＡＣＲでアクセスできる情報のみにアクセスが許可されうる。
【０１７１】
オープンセッションは、パーティションまたは鍵を保護する必要がある場合にも使用することができる。しかしながら、有効な認証プロセスの後には、ホスト側のすべてのエンティティにアクセスが許諾される。様々なホストアプリケーションは、セッションｉｄさえあれば認証済みＡＣＲの権限を得ることができる。これは図１７Ａに例示されている。線４００より上のステップは、ホスト２４によって実行されるステップである。ＡＣＲ１の認証（ブロック４０２）を終えたエンティティは、メモリ装置１０で鍵ＩＤ＿Ｘと関連付けられたファイルへのアクセスを要求する（ブロック４０４、４０６、および４０８）。ＡＣＲ１のＰＣＲがこのアクセスを認める場合、装置１０は要求を許諾する（菱形４１０）。そうでない場合、システムはブロック４０２まで戻る。認証が完了した後、メモリシステム１０は、コマンドを発行するエンティティを、（ＡＣＲ認証情報ではなく）割り当てられたセッションｉｄのみで識別する。オープンセッションでＡＣＲ１がＰＣＲの鍵ＩＤと関連付けられたデータに到達した時点で、他のどのアプリケーションまたはユーザでも、ホスト２４上の様々なアプリケーションによって共有される正しいセッションＩＤを指定することによって、同じデータにアクセスすることができる。この機能は、一度のみログインし、様々なアプリケーションに対してログインに使われたアカウントに結合されたすべてのデータにアクセスできることがユーザにとって好都合な場合のアプリケーションに、有利である。それゆえ、携帯電話のユーザの場合、記憶されたｅメールにアクセスし、ログインを繰り返すことなくメモリ２０に記憶された音楽を聞くことができる。一方、ＡＣＲ１に該当しないデータにはアクセスできないことになる。それゆえ、ゲームや写真等の、同じ携帯電話のユーザにとって貴重となり得るコンテンツは、別のアカウントＡＣＲ２を通じてアクセスされる。これは、携帯電話のユーザの電話を借りる人にアクセスさせたくないデータであるが、携帯電話のユーザにとって、最初のアカウントＡＣＲ１でアクセスできるデータなら他人がアクセスしてもよい。データへのアクセスを２つの別々のアカウントに分け、ＡＣＲ１へのアクセスをオープンセッションで行うことにより、使い易くなるばかりでなく、貴重なデータを保護することができる。
【０１７２】
ホストアプリケーション間でのセッションｉｄの共有プロセスをさらに簡単にするには、オープンセッションを要求するＡＣＲが、セッションに「０（ゼロ）」ｉｄを割り当てることを具体的に要求することができる。このように、アプリケーションは所定のセッションｉｄを使用するように設計することができる。当然ながら、セッション０を要求するＡＣＲは、特定の時間において一度に１つしか認証することができないという制限がある。セッション０を要求する別のＡＣＲを認証するための試行は、拒絶されることになる。
【０１７３】
＜セキュアセッション＞
セキュリティ層を追加するため、セッションｉｄは図１７Ｂに示すように使用してもよい。このとき、メモリ１０もアクティブセッションのセッションｉｄを記憶する。図１７Ｂで、例えば、鍵ＩＤ＿Ｘと関連付けられたファイルにアクセスするためには、エンティティもセッションｉｄ「Ａ」などのセッションｉｄを提供する必要があり、その上でファイルへのアクセスが許可されることになる（ブロック４０４、４０６、４１２、および４１４）。このように、要求するエンティティは正しいセッションｉｄを知らない限りメモリ１０にアクセスすることができない。セッションｉｄはセッションが終了した後に削除され、セッションのたびに異なるため、エンティティはセッション番号を提供できた場合に限りアクセスすることができる。
【０１７４】
ＳＳＡシステムは、コマンドが実際に正しい認証済みエンティティに由来しているかどうかを、セッション番号を使用して追跡する。攻撃者がオープンチャネルを用いて悪質なコマンドを送信しようとするおそれがある用途や使用がある場合、ホストアプリケーションはセキュアセッション（セキュアチャネル）を使用する。
【０１７５】
セキュアチャネルを使用するとき、セッションｉｄとコマンド全体がセキュアチャネル暗号化（セッション）鍵により暗号化され、そのセキュリティレベルはホスト側の実施態様と同じように高くなる。
【０１７６】
＜セッションの終了＞
セッションは次のシナリオのいずれか１つで終了し、ＡＣＲはログオフされる。
１．エンティティが、明示的なセッション終了コマンドを発行する。
２．通信タイムアウトが発生する。ある特定のエンティティが、ＡＣＲパラメータの１つとして設定された期間にわたってコマンドを発行しなかった。
３．装置（例えば、フラッシュカード）のリセットおよび／またはパワーサイクルの後には、すべてのオープンセッションが終了する。
【０１７７】
＜データ完全性サービス＞
ＳＳＡシステムは、ＳＳＡデータベース（ＡＣＲ、ＰＣＲなど、すべてを含む）の完全性を検証する。さらに、鍵ＩＤ機構によるエンティティデータのデータ完全性サービスも提供される。
【０１７８】
鍵ＩＤの暗号化アルゴリズムがハッシュモードに設定される場合、ＣＥＫおよびＩＶと併せてハッシュ値がＣＥＫ記録に記憶される。書込み操作中に、ハッシュ値が計算されて記憶される。読出し操作中にも再度ハッシュ値が計算され、前の書込み操作中に記憶された値と比較される。エンティティが鍵ＩＤにアクセスするたびに追加データが古いデータに（暗号的に）連結され、該当するハッシュ値（読出しまたは書込みのため）が更新される。
【０１７９】
鍵ＩＤと関連付けられ、あるいは鍵ＩＤによって指示されるデータファイルを知るのはホストのみであるため、データ完全性機能の複数の態様は、ホストが明示的に次のように管理する。
１．鍵ＩＤと関連付けられた、または鍵ＩＤによって指示されるデータファイルは、最初から最後まで書き込まれ、あるいは読み出される。ＳＳＡシステムはＣＢＣ暗号方式を使用し、データ全体のハッシュ化メッセージダイジェストを生成するため、ファイルの一部分にアクセスしようとするとファイルは混乱することになる。
２．中間ハッシュ値はＳＳＡシステムによって維持されるため、連続するストリームの中でデータを処理する必要はない（このデータストリームは他の鍵ＩＤのデータストリームでインターリーブすることができ、複数のセッションにわたって分割されてもよい）。しかしながら、エンティティは、データストリームが再開される場合にハッシュ値をリセットするようＳＳＡシステムに明示的に指示する必要がある。
３．ホストは読出し操作が完了すると、読み出されたハッシュを書込み操作中に計算されたハッシュ値と比較することによって有効にするよう、ＳＳＡシステムに明示的に要求する。
４．ＳＳＡシステムは「ダミー読出し」操作も提供する。この機能によりデータは暗号化エンジンを通過するが、ホストには送出されないことになる。この機能を利用すると、データが実際に装置（例えば、フラッシュカード）から読み出される前に、データの完全性を検証することができる。
【０１８０】
＜乱数生成＞
外部エンティティはＳＳＡシステムの内部乱数生成器を利用することができ、乱数をＳＳＡシステムの外部で使用することもできる。このサービスはいずれのホストでも利用することでき、認証を必要としない。
【０１８１】
＜ＲＳＡ鍵対生成＞
外部ユーザはＳＳＡシステムの内部ＲＳＡ鍵対生成機能を利用することができ、鍵対をＳＳＡシステムの外部で使用することもできる。このサービスはいずれのホストでも利用することができ、認証を必要としない。
【０１８２】
＜代替実施形態＞
階層アプローチを使用する代わりに、図１８に例示するデータベースアプローチを使用して同様の結果を実現することができる。
【０１８３】
図１８に示すように、コントローラ１２またはメモリ２０に記憶されるデータベースに入力されたエンティティの認証情報、認証方法、最大失敗数、遮断解除に必要な最小認証情報数のリストは、このような認証情報要件を、メモリ１０のコントローラ１２によって実行されるデータベース内のポリシー（鍵およびパーティションに対する読出し、書込みアクセス、セキュアチャネル要件）に関連付けている。鍵およびパーティションへのアクセスに対する制約事項や制限事項も、データベースに記憶される。こうして、ホワイトリストにある可能性があるエンティティ（例えば、システム管理者）は、すべての鍵およびパーティションにアクセスすることができる。ブラックリストにある可能性があるエンティティによる任意の情報へのアクセスの試行は、阻止される。制限は、全域におよぶ場合と、鍵および／またはパーティションに特異的に適用される場合とがある。これは、特定のエンティティのみが特定の鍵およびパーティションにアクセスでき、特定のエンティティはアクセスできないことを意味する。コンテンツのパーティションや、コンテンツの暗号化または復号化に使用される鍵にかかわらず、コンテンツ自体に制約を課すこともできる。それゆえ、特定のデータ（例えば、曲）にアクセスする可能性がある最初の５つのホスト装置のみにアクセスを許可したり、他のデータ（例えば、映画）にアクセスするエンティティを問わず、データの読出し回数を制限したりすることができる。
＜認証＞
パスワード保護
・パスワード保護は、保護領域にアクセスする場合にパスワードの提示が求められることを意味する。パスワードが１つに限られる場合を除き、それぞれのパスワードには読出しアクセスまたは読出し／書込みアクセスなど、別々の権利を関連付けることができる。
・パスワード保護は、ホストから提供されるパスワードを装置（例えば、フラッシュカード）が検証しうること、すなわち、装置もまた装置によって管理され保護されたメモリ領域にパスワードを記憶することを意味する。
問題および限界
・パスワードはリプレー攻撃を被ることがある。提示のたびに変わらないパスワードは、同じ状態で再送されうる。つまり、保護の対象となるデータが貴重で、通信バスへのアクセスが容易な場合、パスワードを現状のまま使用するべきではない。
・パスワードは記憶データへのアクセスを保護しうるが、（鍵ではなく）データの保護のためにパスワードが使用されるべきではない。
・パスワードに関連するセキュリティレベルを上げるため、親鍵を用いてパスワードを多様化すれば、１つのパスワードがハッキングされてもシステム全体が破壊されることはない。パスワードの送信には、セッション鍵方式のセキュア通信チャネルを使用することができる。
【０１８４】
図１９は、パスワードを使用した認証を示すフローチャートである。エンティティは、アカウントｉｄおよびパスワードをシステム１０（例えば、フラッシュメモリカード）へ送信する。システムは、パスワードがそのメモリにあるパスワードに一致するかどうかをチェックする。一致する場合は認証済みステータスが返される。そうでない場合はそのアカウントのエラーカウンタがインクリメントされ、エンティティにはアカウントｉｄおよびパスワードの再入力が求められる。カウンタがオーバーフローすると、システムはアクセス拒絶ステータスを返す。
【０１８５】
＜対称鍵＞
対称鍵アルゴリズムは、暗号化と復号化の両側で同じ鍵が使用されることを意味する。これは、通信に先立って、予め鍵を取り決めておくことを意味する。それぞれの側では、相手側の逆のアルゴリズムを実行すべきである。すなわち、一方は暗号化アルゴリズムになり、他方は復号化アルゴリズムになる。通信する場合に両側で両方のアルゴリズムを実行する必要はない。
認証
・対称鍵認証は、装置（例えば、フラッシュカード）およびホストが同じ鍵を共有し、同じ暗号アルゴリズム（ダイレクトおよびリバース、例えば、ＤＥＳおよびＤＥＳ−１）を有することを意味する。
・対称鍵認証は、チャレンジ・レスポンス（リプレー攻撃対策）を意味する。被保護装置が他の装置に対する質問を生成し、両方の装置で回答を計算する。認証を受ける側の装置は回答を返送し、被保護装置はその回答をチェックし、それに応じて認証の正当性を実証する。そして、認証に応じて権利が付与される。
認証には次のものがある。
・外部認証：装置（例えば、フラッシュカード）が外部を認証する。すなわち、装置は所与のホストまたはアプリケーションの認証情報を実証する。
・相互認証：両側で質問を生成する。
・内部認証：ホストアプリケーションが装置（例えば、フラッシュカード）を認証する。すなわち、ホストは、装置がそのアプリケーションにとって真正であるかどうかをチェックする。
システム全体のセキュリティレベルを上げるために（すなわち、１つが低下してもすべてが低下しないようにするため）
・対称鍵には、通常、親鍵を使用した多様化が組み入れられる。
・質問が真正な質問であるようにするため、相互認証により両側からの質問を使用する。
暗号化
対称鍵暗号法はすこぶる効率的なアルゴリズムで、暗号処理する場合に強力なＣＰＵを必要としないため、暗号化にも使用される。
【０１８６】
通信チャネルを安全に使用するとき：
・チャネルの安全を確保する（すなわち、全発信データを暗号化し全受信データを復号化する）ために使用されるセッション鍵を、両方の装置が知らなければならない。このセッション鍵は、通常、事前共有秘密対称鍵を使用するか、あるいはＰＫＩを使用して確立される。
・両方の装置が同じ暗号アルゴリズムを知り、実行しなければならない。
【０１８７】
＜署名＞
対称鍵を使用してデータに署名することもできる。この場合の署名は、暗号化の部分的な結果である。結果を一部分に留めることで、鍵値を露出することなく必要に応じて何度でも署名することができる。
【０１８８】
＜問題および限界＞
対称アルゴリズムは非常に効率的で安全ではあるが、事前共有秘密に基づいている。問題は、この秘密を動的に安全に共有することと、場合により（セッション鍵のように）ランダムにすることである。つまり、共有秘密を長期間にわたって安全に保つのは困難であり、多数の人々と共有することはほぼ不可能である。
【０１８９】
この作業を容易にするために、秘密を共有せずに交換できる公開鍵アルゴリズムが考案されている。
【０１９０】
＜非対称認証手続き＞
非対称鍵に基づく認証では、一連のコマンドを使用してデータを受け渡ししながら、最終的にはセキュアチャネル通信のためのセッション鍵を作る。その基本的プロトコルでは、ＳＳＡシステムに対してユーザを認証する。多様なプロトコルにより、ユーザが使用したいＡＣＲを検証する相互認証や二因子認証も可能である。
【０１９１】
ＳＳＡの非対称認証プロトコルでは、公開鍵基盤（ＰＫＩ）アルゴリズムおよびＲＳＡアルゴリズムを使用することが好ましい。これらのアルゴリズムで規定することで、認証プロセスの各当事者に独自のＲＳＡ鍵対を作成することができる。各対は公開鍵および秘密鍵からなる。これらの鍵は秘匿の鍵であるために、アイデンティティの証拠を提供することはできない。ＰＫＩ層では、信頼された第三者機関が公開鍵の各々に署名することを求められる。この信用機関の公開鍵は、互いを認証する当事者間で事前共有され、当事者の公開鍵を検証するために使用されている。信用が成立すると（両当事者が相手方から提供される公開鍵を信用できると判定すると）、プロトコルによる認証（各当事者が所有する秘密鍵の一致を検証する）と鍵の交換が続行される。これは、後述する図２２および２３のチャレンジ・レスポンス機構によって行うことができる。
【０１９２】
署名済みの公開鍵を含む構造は、証明書と称される。証明書に署名した信用機関は、証明機関（ＣＡ）と称される。認証を受ける側は、ＲＳＡ鍵対と公開鍵の信頼性を立証する証明書とを有する。証明書は、相手方（認証する側）が信用する証明機関によって署名される。認証する側には、信用ＣＡの公開鍵の所有が求められる。
【０１９３】
ＳＳＡは証明書連鎖に対応する。これは、識別される側の公開鍵が別のＣＡ、すなわち識別する側が信用するＣＡとは異なるＣＡによって署名されることを意味する。この場合の識別される側は、自分自身の証明書のほかに、その公開鍵に署名したＣＡの証明書を提供する。この第２レベルの証明書さえも相手方によって信用されない（信用ＣＡによって署名されていない）場合、第３レベルの証明書を提供することができる。この証明書連鎖アルゴリズムでは、各当事者が公開鍵の認証に必要な証明書の完全なリストを所有する。このことは、図２３および２４に例示されている。この種のＡＣＲによる相互認証に必要な認証情報は、選択された長さを有するＲＳＡ鍵対である。
【０１９４】
＜ＳＳＡ証明書＞
ＳＳＡは、［Ｘ．５０９］バージョン３デジタル証明書を採用する。［Ｘ．５０９］は汎用規格であり、ここで説明するＳＳＡ証明書プロファイルは証明書の所定フィールドの内容をさらに指定し、制限する。この証明書プロファイルは、証明書連鎖の管理のために定められた信頼階層と、ＳＳＡ証明書の実証と、証明書失効リスト（ＣＲＬ）プロファイルも規定する。
【０１９５】
証明書は公開情報（内部の公開鍵として）とみなされ、したがって、暗号化されない。しかしながら、証明書はＲＳＡ署名を含み、このＲＳＡ署名によって公開鍵やその他すべての情報フィールドが改ざんされていないことを検証する。
【０１９６】
［Ｘ．５０９］はＡＳＮ．１規格を使用した各フィールドのフォーマットを定め、ＡＳＮ．１規格ではデータ符号化にＤＥＲフォーマットを使用する。
【０１９７】
＜ＳＳＡ証明書の概要＞
図２０および図２１に示されたＳＳＡ証明書管理アーキテクチャの一実施形態は、ホストの無限階層レベルと装置の３階層レベルからなるが、装置で使用する階層レベルは３レベルより多い場合または３レベルより少ない場合がある。
【０１９８】
＜ホスト証明書階層＞
装置は、２つの要素、すなわち、装置に記憶されたルートＣＡ証明書（ＡＣＲ認証情報としてＡＣＲの作成時に記憶）と、装置への（その特定のＡＣＲへの）アクセスを試行するエンティティから提供される証明書／証明書連鎖とに基づいて、ホストを認証する。
【０１９９】
ホスト証明機関は、それぞれのＡＣＲに対してルートＣＡ（ＡＣＲ認証情報に常駐する証明書）としての役割を果たす。例えば、ある１つのＡＣＲにとってのルートＣＡは「ホスト１＿ＣＡ（レベル２）証明書」であり、別のＡＣＲにとってのルートＣＡは「ホストルートＣＡ証明書」である。各々のＡＣＲに対して、ルートＣＡによって署名された証明書（またはルートＣＡを末端エンティティ証明書までつなげる証明書連鎖）を保持するすべてのエンティティが、末端事業者証明書の対応する秘密鍵を有している場合、そのＡＣＲにログインすることができる。前述のように、証明書は公知であり、秘密にされない。
【０２００】
ルートＣＡによって発行された証明書（ならびに対応する秘密鍵）の所有者は誰でもそのＡＣＲにログイン可能であるということは、ある特定のＡＣＲに対する認証がそのＡＣＲの認証情報に記憶されたルートＣＡの発行者によって決まることを意味する。換言すると、ルートＣＡの発行者がＡＣＲの認証方式を管理するエンティティになりうる。
【０２０１】
＜ホストルート証明書＞
ルート証明書は、ログインを試行するエンティティ（ホスト）の公開鍵の検証を開始するためにＳＳＡが使用している信用ＣＡ証明書である。この証明書は、ＡＣＲの作成時にＡＣＲ認証情報の一部として提供される。これはＰＫＩシステムに対する信用の根元にあたるものであり、したがって、信用されたエンティティ（父ＡＣＲ、または製造／構成信頼環境）から提供されることが前提となる。この証明書を検証するＳＳＡは、その公開鍵を使用して証明書の署名を検証する。ホストルート証明書は暗号化された状態で不揮発性メモリ（図１には示されていない）に記憶され、装置の秘密鍵にアクセスできるのは、好ましくは図１のシステム１０のＣＰＵ１２のみである。
【０２０２】
＜ホスト証明書連鎖＞
これらの証明書は認証中にＳＳＡへ提供される。連鎖の処理が完了した後にホストの証明書連鎖を再収集して装置に記憶することはすべきでない。
【０２０３】
図２０は、多数の異なるホスト証明書連鎖を示す、ホスト証明書レベル階層の概略図である。図２０に示すように、ホスト証明書は多数の異なる証明書連鎖を有することがあり、ここでは３つの証明書連鎖のみが例示されている。
Ａ１．ホストルートＣＡ証明書５０２、ホスト１＿ＣＡ（レベル２）証明書５０４、およびホスト証明書５０６
Ｂ１．ホストルートＣＡ証明書５０２、ホストｎ＿ＣＡ（レベル２）証明書５０８、ホスト１＿ＣＡ（レベル３）証明書５１０、ホスト証明書５１２
Ｃ１．ホストルートＣＡ証明書５０２、ホストｎ＿ＣＡ（レベル２）証明書５０８、ホスト証明書５１４
【０２０４】
前述した３つの証明書連鎖Ａ１、Ｂ１、およびＣ１は、ホストの公開鍵が真正であることを証明するために使用されてもよい、３つの考えられるホスト証明書連鎖を例示するものである。前述した証明書連鎖Ａ１と図２０とを参照し、ホスト１のＣＡ（レベル２）証明書５０４の公開鍵はホストルートＣＡの秘密鍵（すなわち、公開鍵のダイジェストを暗号化することによって）によって署名され、この公開鍵はホストルートＣＡ証明書５０２にある。さらに、ホスト証明書５０６のホスト公開鍵は、ホスト１のＣＡ（レベル２）の秘密鍵によって署名され、この公開鍵はホスト１ＣＡ（レベル２）証明書５０４において提供される。したがって、ホストルートＣＡの公開鍵を有するエンティティは、前述した証明書連鎖Ａ１の信頼性を検証できることになる。このエンティティは最初のステップとして、ホストから送信されたホスト１のＣＡ（レベル２）証明書５０４の署名済み公開鍵を、自身が所有するホストルートＣＡの公開鍵を使用して復号化し、復号化した署名済み公開鍵を、ホストから送信されたホスト１のＣＡ（レベル２）証明書５０４の署名されていない公開鍵のダイジェストと比較する。２つが一致する場合、ホスト１のＣＡ（レベル２）の公開鍵は認証され、エンティティは次に、ホストから送信されたホスト証明書５０６の中にあるホスト１のＣＡ（レベル２）の秘密鍵によって署名されたホストの公開鍵を、ホスト１のＣＡ（レベル２）の認証済み公開鍵を使用して復号化することになる。この復号化された署名済みの値が、ホストから送信されたホスト証明書５０６の中にある公開鍵のダイジェストの値に一致する場合、ホストの公開鍵も認証される。証明書連鎖Ｂ１およびＣ１を使用した認証も同様に行われる。
【０２０５】
連鎖Ａ１が関わる前述したプロセスから分かるように、ホストから送信されエンティティによって検証される必要のある最初の公開鍵は、ホストルートＣＡ証明書ではなく、ホスト１のＣＡ（レベル２）の公開鍵である。このため、ホストがエンティティへ送信する必要があるものは、ホスト１のＣＡ（レベル２）証明書５０４とホスト証明書５０６であって、ホスト１のＣＡ（レベル２）証明書は連鎖の中で最初に送信される必要があることになる。前述したように、証明書の検証順序は次の通りである。検証する側のエンティティ、すなわちこの場合のメモリ装置１０はまず、連鎖の中で最初の証明書の公開鍵の真性を検証し、この場合のものはルートＣＡの下に位置するＣＡの証明書５０４である。この証明書の公開鍵が真正であることを検証した後、装置１０は次の証明書の検証に進み、この場合のものはホスト証明書５０６である。証明書連鎖が３つ以上の証明書を含む場合の検証順序も同様に、ルート証明書のすぐ下に位置する証明書から始まり、認証の対象となるエンティティの証明書で終わる。
【０２０６】
＜装置証明書階層＞
ホストは２つの要素、すなわちホストに記憶された装置ルートＣＡと、装置からホストへ提供される（ＡＣＲの作成時に認証情報として装置に提供される）証明書／証明書連鎖とに基づいて装置を認証する。ホストによる装置の認証プロセスは、前述した装置によるホスト認証プロセスに類似している。
【０２０７】
＜装置証明書連鎖＞
これらの証明書は、ＡＣＲの鍵対の証明書である。これらの証明書は、ＡＣＲの作成時にカードに提供される。ＳＳＡはこれらの証明書を個別に記憶し、認証の際にはそれらを１つずつホストに提供する。ＳＳＡは、これらの証明書を使用してホストを認証する。装置は３つの証明書からなる連鎖を処理しうるが、使用される証明書数が３以外になる場合がある。証明書の数は、ＡＣＲによって変わることがある。これは、ＡＣＲが作成されるときに決まる。装置はホストに向けて証明書連鎖を送信しうるが、証明書連鎖データを使用するわけではないので、証明書連鎖を解析する必要はない。
【０２０８】
図２１は、記憶装置などのＳＳＡを使用する装置で１〜ｎ種類の証明書連鎖を示す、装置証明書レベル階層の概略図である。図２１に例示されたｎ種類の証明書連鎖は次の通りである。
Ａ２．装置ルートＣＡ証明書５２０、装置１ＣＡ（製造業者）証明書５２２、装置証明書５２４
Ｂ２．装置ルートＣＡ証明書５２０、装置ｎ  ＣＡ（製造業者）証明書５２６、装置証明書５２８
【０２０９】
ＳＳＡ装置は、それぞれ独自の装置ＣＡ証明書を有する１〜ｎ種類の製造業者によって製造されうる。したがって、ある特定の装置の装置証明書の公開鍵はその異なる製造業者の秘密鍵によって署名され、製造業者の公開鍵は装置ルートＣＡの秘密鍵によって署名される。装置の公開鍵を検証する方法は、前述したホストの公開鍵の場合の方法に類似する。ホストについて前述した連鎖Ａ１の検証の場合と同様に、装置ルートＣＡ証明書を送信する必要はなく、連鎖の中で送信すべき最初の証明書は装置ｉ＿ＣＡ（製造業者）証明書であって、その後に装置証明書が続き、ｉは１〜ｎの整数である。
【０２１０】
図２１に示す実施形態において、装置は２つの証明書、つまり装置ｉ＿ＣＡ（製造業者）証明書と、その後に自身の装置証明書とを送信する。装置ｉ＿ＣＡ（製造業者）証明書は、このような装置を製造し、装置の公開鍵に署名するための秘密鍵を提供する製造業者の証明書である。装置ｉ＿ＣＡ（製造業者）証明書を受信したホストは、自身が所有するルートＣＡの公開鍵を使用して装置ｉ＿ＣＡ（製造業者）公開鍵を復号化し、検証する。ホストはこの検証に失敗した場合、プロセスを中断し、認証が失敗したことを装置に通知する。ホストが認証に成功した場合、次の証明書を求める要求を装置へ送信する。この後、装置は自身の装置証明書を送信し、ホストはこれを同様に検証する。
【０２１１】
図２２および図２３は、前述した検証プロセスをさらに詳しく示すものである。図２２の「ＳＳＭシステム」は、本明細書で説明するＳＳＡシステムと後述するその他の機能とを実行するソフトウェアモジュールである。ＳＳＭは、ソフトウェアまたはコンピュータコードとして具体化することができ、メモリ２０またはＣＰＵ１２の不揮発性メモリ（図示せず）にデータベースを記憶し、ＲＡＭ＿１２ａに読み込まれてＣＰＵ＿１２によって実行される。
【０２１２】
図２２に示すように、装置１０のＳＳＭシステム５４２がホストシステム５４０を認証するプロセスには、３つの段階がある。最初の公開鍵検証段階では、ホストシステム５４０が、ＳＳＭコマンドでホスト証明書連鎖をＳＳＭシステム５４２へ送信する。ＳＳＭシステム５４２は、ホスト証明書５４４の真性とホスト公開鍵５４６の真性を、ＡＣＲ５５０のホストルート証明書５４８にあるルート証明機関公開鍵を用いて検証する（ブロック５５２）。ルート証明機関とホストの間に中間証明機関が介在する場合、中間証明書５４９もブロック５５２の検証に使用される。検証またはプロセス（ブロック５５２）が成功したと仮定し、ＳＳＭシステム５４２は、この後、第２段階へ進む。
【０２１３】
ＳＳＭシステム５４２は乱数５５４を生成し、これを質問としてホストシステム５４０に送信する。システム５４０はホストシステムの秘密鍵５４７を使用して乱数５５４に署名し（ブロック５５６）、質問に対する回答として署名済みの乱数を送信する。その回答はホスト公開鍵５４６を使用して復号化され（ブロック５５８）、乱数５５４と比較される（ブロック５６０）。復号化された回答が乱数５５４に一致したと仮定すると、チャレンジ・レスポンスは成功である。
【０２１４】
第３段階では、ホスト公開鍵５４６を使用して乱数５６２を暗号化する。この乱数５６２は、この後、セッション鍵となる。ホストシステム５４０は、ＳＳＭシステム５４２からの暗号化数５６２を秘密鍵を使用して復号化（ブロック５６４）することによってセッション鍵を得ることができる。このセッション鍵により、ホストシステム５４０とＳＳＭシステム５４２との間でセキュア通信が開始されうる。図２２に示す一方向非対称認証では、装置１０のＳＳＭシステム５４２によってホストシステム５４０が認証される。図２３は、図２２の一方向認証プロトコルに類似した双方向相互認証プロセスを示すプロトコル図であり、図２３ではＳＳＭシステム５４２もホストシステム５４０によって認証される。
【０２１５】
図２４は、本発明の一実施形態を例示する証明書連鎖５９０の図である。前述したように、検証する場合に提示する必要がある証明書連鎖は、多数の証明書を含むことがある。図２４の証明書連鎖は全部で９つの証明書を含み、認証する場合にはこれらの証明書をすべて検証することが必要となる場合がある。背景技術の節で先に説明したように、既存の証明書検証システムでは、送信される証明書連鎖に不備があったり、証明全体が送信されたり、証明書が特定の順序で送信されないと、受信側は証明書を一通り受信し記憶するまで証明書を解析することができない。しかし、連鎖に含まれる証明書の数は事前に分からないため、問題が生じることがある。長さが不確かな証明書連鎖を記憶するために大量の記憶容量を確保する必要になることがある。これは検証を実施する記憶装置にとって問題になることがある。
【０２１６】
本発明の一実施形態は、証明書連鎖が記憶装置によって検証される順序と同じ順序でホスト装置がその証明書連鎖を送信するシステムによって、この問題を軽減できるという認識に基づく。それゆえ、図２４に示すように、証明書の連鎖５９０は、ホストルート証明書のすぐ下に位置する証明書５９０（１）から始まり、ホスト証明書である証明書５９０（９）で終わる。したがって、装置１０はまず、証明書５９０（１）で公開鍵を検証し、その後に証明書５９０（２）で公開鍵の検証などを行い、最後に証明書５９０（９）でホスト公開鍵を検証する。これで、証明書連鎖５９０全体の検証プロセスは完了する。それゆえ、ホスト装置が証明書連鎖５９０を検証と同じ順序でメモリ装置１０へ送信する場合、メモリ装置１０は証明書を受信するたびに検証を開始することができ、連鎖５９０に含まれる９つの証明書全部が受信されるまで待つ必要はない。
【０２１７】
それゆえ、ホスト装置は、一実施形態において、メモリ装置１０に対して連鎖５９０の証明書を一度に１つずつ送信する。メモリ装置１０は、一度に１つの証明書を記憶することになる。連鎖の中の最後の証明書を除き、検証済みの証明書は、ホストから送信される次の証明書で上書きすることができる。このように、メモリ装置１０には、いつも１つだけの証明書を記憶する容量を確保する必要がある。
【０２１８】
メモリ装置は、連鎖５９０全体が受信されていることを知る必要がある。それゆえ、最後の証明書５９０（９）には、これが連鎖の中で最後の証明書であることを伝える標識または標示を含んでいることが好ましい。これを例示する図２５の表は、ホストからメモリ装置１０へ送信される証明書バッファに先行する制御セクタ内の情報を示す。図２５に示すように、証明書５９０（９）の制御セクタには、引数名「最終」フラグがある。メモリ装置１０は、「最終」フラグが設定されているかどうかをチェックして受信した証明書が連鎖における最終証明書であるかどうかを判定することにより、連鎖の中で証明書５９０（９）が最後の証明書であることを検証することができる。
【０２１９】
代替的な実施形態では、連鎖５９０の証明書を１つずつ送信するのではなく、１つ、２つ、または３つの証明書からなるグループで送信してもよい。当然ながら、グループで使用する証明書の数は異なる場合も、あるいは同じになる場合もある。それゆえ、連鎖５９０には５つの連続する証明書列５９１、５９３、５９５、５９７、および５９９がある。それぞれの列は、少なくとも１つの証明書を含む。ある１つの証明書の列には、連鎖の中で該当する１列の先行列に隣接する証明書（先頭証明書）と、連鎖の中で該当する１列の後続列に隣接する証明書（終端証明書）と、先頭証明書と終端証明書との間にある全ての証明書が含まれる。例えば、列５９３の中には、全部で３つの証明書５９０（２）、証明書５９０（３）、および証明書５９０（４）がある。メモリ装置１０による５つの証明書の列の検証は５９１、５９３、５９５、５９７の順で行われ、５９９で終わる。したがって、５つの列がメモリ装置１０によって実施される検証と同じ順序で送信され、受信される場合、検証済みの列をメモリ装置で記憶する必要はなくなり、最後の列を除く列はいずれも、ホストから到着する次の列で上書きされうる。前の実施形態と同様に、連鎖内の最後の証明書には標識、例えばこれが連鎖における最後の証明書であることを伝える特定の値に設定されたフラグを含むことが望ましい。この実施形態では、メモリ装置は、５つの列のうち、証明書数が最も多い列の証明書を記憶する十分な容量を確保するだけでよい。それゆえ、ホストが送ろうとする列のうちの最も長い列を事前にメモリ装置１０に知らせる場合、メモリ装置１０は、最も長い列のための十分な容量を確保するだけでよい。
【０２２０】
ホストによって送信される連鎖の中の各証明書の長さは、その証明書によって証明される公開鍵の長さの４倍以下であることが好ましい。同様に、メモリ装置の公開鍵を証明するためにメモリ装置１０からホスト装置へ送信される証明書の長さは、その証明書によって証明される公開鍵の長さの４倍以下であることが好ましい。
【０２２１】
図２６のフローチャートは、前述した証明書連鎖検証の実施形態を示すものであり、ここでは簡単にするために、各グループ内の証明書数を１と仮定する。図２６に示すように、ホストは、カードに向けて連鎖内の証明書を順次送信する。連鎖の中の第１の証明書（前述したように、通常はルート証明書の後続証明書）から始まって、カードは、認証の対象となるホストから証明書連鎖を順次受信する（ブロック６０２）。そしてカードは、受信する証明書の各々を検証し、証明書のいずれかで検証に失敗した場合はプロセスを中止する。カードは、証明書のいずれかで検証に失敗した場合、ホストに通知する（ブロック６０４、６０６）。この後、カードは、最後の証明書が受信され検証されたかどうかを検出する（菱形６０８）。最終証明書が受信されずに検証されていなければ、カードはブロック６０２まで戻り、ホストからの証明書の受信および検証を続ける。最終証明書が受信されて検証されれば、カードは証明書検証の後に続く次の段階へ進む（６１０）。図２６とそれ以降の図の内容は、例としてメモリカードについて言及しているが、物理的形態がメモリカードではないメモリ装置にもこれらの内容が適用されうることは理解されよう。
【０２２２】
図２７は、カードがホストを認証するときに、ホストによって実行されるプロセスを示す。図２７に示すように、ホストは、連鎖の中の次の証明書をカードに送信する（ブロック６２０）（典型的に、ルート証明書の後続証明書から始まる）。ホストは、認証の失敗を伝える中止通知がカードから受信されているかどうかを判定する（菱形６２２）。中止通知が受信されていれば、ホストは停止する（ブロック６２４）。中止通知が受信されていなければ、ホストは送信された最後の証明書で「最終フラグ」が設定されているかどうかをチェックすることにより、連鎖の最終証明書が送信済みかどうかを確認する（菱形６２６）。最終証明書が送信済みであれば、ホストは証明書検証の後に続く次の段階に進む（ブロック６２８）。図２２および２３に示すように、次の段階はチャレンジ・レスポンスであり、その後にセッション鍵の作成が続いてもよい。連鎖の最終証明書が送信済みでなければ、ホストはブロック６２０まで戻り、連鎖内の次の証明書を送信する。
【０２２３】
図２８および図２９は、カードが認証されるときに、カードおよびホストが取るアクションを示す。図２８に示すように、カードは開始後、連鎖の中で証明書の送信を求めるホストからの要求を待つ（ブロック６３０、菱形６３２）。ホストから要求が受信されなければ、カードは菱形６３２に戻ることになる。ホストから要求が受信される場合、カードは連鎖の中の次の証明書を送信することになり、これは送信されるべき最初の証明書から始まる（典型的に、ルート証明書の後続証明書から始まる）（ブロック６３４）。カードは、ホストから失敗通知が受信されたかどうかを判定する（菱形６３６）。失敗通知が受信されている場合、カードは停止する（ブロック６３７）。失敗通知が受信されていない場合、カードは最終証明書が送信済みかどうかを判定する（菱形６３８）。最終証明書が送信済みでなければ、カードは菱形６３２まで戻り、連鎖内の次の証明書の送信を求める次の要求をホストから受信するまで待つ。最終証明書が送信済みであれば、カードは次の段階に進む（ブロック６３９）。
【０２２４】
図２９は、カードが認証されるときにホストが取るアクションを示す。ホストは、連鎖内の次の証明書を求める要求をカードに送り、これは送信されるべき最初の証明書に対する要求から始まる（ブロック６４０）。ホストは、この後、受信する各々の証明書を検証し、検証に失敗した場合はプロセスを中止し、カードに通知する（ブロック６４２）。検証に合格した場合、ホストは最終証明書が受信済みで検証に成功しているかどうかをチェックする（菱形６４４）。最終証明書が受信されておらず検証が成功していなければ、ホストはブロック６４０まで戻り、連鎖内の次の証明書を求める要求を送信する。最終証明書が受信済みで検証が成功している場合、ホストは証明書検証に続く次の段階に進む（ブロック６４６）。
【０２２５】
＜証明書失効＞
発行された証明書は、その有効期間全体にわたって使用されることが予想される。しかし、様々な事情から、有効期間の満了の前に証明書が無効になる場合がある。名称の変更、対象とＣＡとの関係の変化（例えば、従業員の退職）、対応する秘密鍵の侵害または侵害の疑い等がこれにあたる。このような場合には、ＣＡが証明書を無効にする必要がある。
【０２２６】
ＳＳＡにおける証明書の失効には別の方法があり、ＡＣＲは各々が別々の証明書失効制度によって構成されうる。まず、失効制度をサポートしない形にＡＣＲを構成することができる。この場合の各証明書は、有効期限まで有効とみなされる。証明書失効リスト（ＣＲＬ）を使用することもできる。さらに別の代案として、後述するようにある特定のアプリケーションに失効制度を限定する、つまりアプリケーション別の限定となるようにしてもよい。ＡＣＲでは、失効値を指定することによって、３つの失効制度のどれが採用されているかを指定する。失効制度なしで作成されたＡＣＲでは、そのＡＣＲの所有者が決定する失効制度を採用することができる。メモリ装置証明書の失効は、ＳＳＡセキュリティシステムではなくホストによって執行される。ホストルート証明書の失効管理はＡＣＲの所有者が担当し、これはＡＣＲの認証情報を更新することによって行われる。
【０２２７】
＜証明書失効リスト（ＣＲＬ）＞
ＳＳＡシステムで失効制度を使用するには、各ＣＡが証明書失効リスト（ＣＲＬ）と呼ばれる署名済みデータ構造を定期的に発行する。ＣＲＬは、失効した証明書を識別するタイムスタンプ付きリストであり、ＣＡ（該当する証明書を発行したＣＡ）によって署名され、一般に公開されて自由に利用することができる。ＣＲＬの中では、失効した証明書を、それぞれの証明書通し番号で識別する。ＣＲＬのサイズは、任意なものであって、期限切れ前に失効する証明書の数で決まる。（例えば、ホストのアイデンティティを検証するために）証明書を使用する装置は、証明書の署名（ならびに有効性）をチェックするだけでなく、ＣＲＬを通じて受信された通し番号のリストにこれを照らして検証する。証明書の発行元にあたるＣＡから発行されるＣＲＬでその証明書の識別情報、例えば、通し番号が見つかる場合、これは、その証明書が失効し、もはや有効でないことを意味する。
【０２２８】
証明書の有効性を検査する目的をＣＲＬで果たすには、ＣＲＬについても、これが真正であることを検証する必要がある。ＣＲＬには、その発行元にあたるＣＡの秘密鍵を使用して署名し、ＣＡの公開鍵を使用して署名済みＣＲＬを復号化することによってこれが真正であることを検証することができる。復号化されたＣＲＬが、無署名ＣＲＬのダイジェストに一致する場合、そのＣＲＬに改ざんがなく、真正であることを意味する。ＣＲＬのダイジェストを得るためにハッシュアルゴリズムを使用して頻繁にＣＲＬのハッシュ計算が行われ、そのダイジェストはＣＡの秘密鍵で暗号化される。ＣＲＬが有効かどうかを検証するには、ＣＡの公開鍵を使用して署名済みＣＲＬ（すなわち、ハッシュ化および暗号化されたＣＲＬ）を復号化し、復号化されハッシュ化されたＣＲＬ（すなわち、ＣＲＬのダイジェスト）を得る。そして、これをハッシュ化ＣＲＬと比較する。それゆえ、検証プロセスでは、復号化されハッシュ化されたＣＲＬとの比較のためのＣＲＬのハッシュ計算ステップを頻繁に伴うことがある。
【０２２９】
ＣＲＬ方式の特徴の１つとして、（ＣＲＬを使用した）証明書の妥当性の検証は、ＣＲＬの入手とは別に実施することができる。ＣＲＬもまた適切な証明書の発行元によって署名され、証明書の検証と同様に、ＣＲＬの発行元にあたるＣＡの公開鍵を使用して前述したように検証される。メモリ装置は、署名がＣＲＬのものであることを検証し、さらにＣＲＬの発行元と証明書の発行元との一致を検証する。ＣＲＬ方式の別の特徴として、ＣＲＬは証明書自体と全く同じ方法で、（具体的には信頼性のないサーバと信頼性のない通信を通じて、）提供することができる。Ｘ．５０９規格には、ＣＲＬとその特徴が詳述されている。
【０２３０】
＜ＣＲＬのためのＳＳＡ基盤＞
ＳＳＡは、ＣＲＬ方式を使用したホスト失効のための基盤を提供する。ＣＲＬ失効制度を採用するＲＳＡ方式ＡＣＲで認証するとき、ホストは、Ｓｅｔ  Ｃｅｒｔｉｆｉｃａｔｅコマンドに対して追加のフィールドとして、１つのＣＲＬ（恐らく、発行元ＣＡによって無効にされた証明書がない場合は空のＣＲＬ）を加える。このフィールドには、証明書の発行元によって署名されたＣＲＬが含まれる。このフィールドが存在する場合、メモリ装置１０は最初にＳｅｔ  Ｃｅｒｔｉｆｉｃａｔｅコマンドで証明書を検証する。ＣＲＬリポジトリの入手とアクセスは、全面的にホストが担当する。ＣＲＬが有効であり続ける期間（ＣＲＬ有効期間、すなわちＣＥＴ）も、ＣＲＬと併せて発行される。現在の時間がこの期間から外れていることが検証中に判明すると、そのＣＲＬには不備があるとみなされ、証明書の検証に使用することはできない。その結果、証明書の認証は失敗する。
【０２３１】
従来の証明書検証方法では、認証する側または検証する側のエンティティが、証明書失効リストを所有しているかあるいは証明機関（ＣＡ）から取り込むことができ、認証のために提示される証明書の通し番号をリストに照らしてチェックし、提示された証明書が失効しているかどうかが判定されるはずである。認証または検証する側のエンティティがメモリ装置の場合、そのメモリ装置自体が使用されなかったら、ＣＡから証明書失効リストが取り込まれていない可能性がある。装置に予め記憶された証明書失効リストが時間を経て古くなると、インストールされた日より後に失効した証明書はリストに現れない。その結果、ユーザは、失効した証明書を使用してその記憶装置にアクセスすることになる。これは望ましくない。
【０２３２】
一実施形態において、認証を受けようとするエンティティが、認証の対象となる証明書と併せて証明書失効リストを、認証する側のエンティティ（例えばメモリ装置１０）に提示するシステムによって、前述した問題を解決できる可能性がある。認証する側のエンティティは、受信した証明書の信頼性と証明書失効リストの信頼性を検証する。認証する側のエンティティは、失効リストで証明書の識別情報の有無、例えば証明書の通し番号の有無をチェックすることにより、証明書が失効リストに登記されているかどうかをチェックする。
【０２３３】
前述したことを踏まえ、ホスト装置とメモリ装置１０との相互認証に、非対称認証方式を使用することができる。メモリ装置１０の認証を受けようとするホスト装置は、証明書連鎖および対応するＣＲＬの両方を提供する必要がある。一方、ホスト装置は予めＣＡに接続してＣＲＬを入手しているため、ホスト装置がメモリ装置１０を認証するとき、メモリ装置は、証明書または証明書連鎖と併せて、ＣＲＬをホスト装置に提示する必要はない。
【０２３４】
種々の内蔵または独立型ミュージックプレーヤ、ＭＰ３プレーヤ、携帯電話機、個人用携帯情報端末、およびノートブックコンピュータなど、近年コンテンツの再生に使用できる種々のタイプの携帯型装置は増えている。証明機関から証明書検証リストへアクセスするため、そのような装置をワールド・ワイド・ウェブに接続することは可能であるが、多数のユーザは典型的に、ウェブに毎日接続するのではなく、例えば数週間に一度、新たなコンテンツを入手したり契約を更新したりするときに、これを行う。そのようなユーザにとって、証明機関からより頻繁に証明書失効リストを入手するのは面倒な場合がある。そのようなユーザについて、証明書失効リスト、さらに必要であれば被保護コンテンツへアクセスする場合に記憶装置に提示する必要のあるホスト証明書を、好ましくは記憶装置自体の非保護領域に記憶してもよい。多くのタイプの記憶装置（例えば、フラッシュメモリ）で、記憶装置の非保護領域は、記憶装置自体によって管理されるのではなく、ホスト装置によって管理される。これにより、ユーザはより新しい証明書失効リストを入手するため（ホスト装置を通じて）ウェブに接続する必要がない。ホスト装置は、記憶装置の非保護領域からそのような情報を検索し、その後、記憶装置またはメモリ装置に証明書とリストを提示して、記憶装置の被保護コンテンツにアクセスすることができる。被保護コンテンツにアクセスするための証明書とその対応する証明書失効リストは、典型的に一定の期間にわたって有効であるため、それらが有効である限り、ユーザは最新の証明書または証明書失効リストを入手する必要はない。このため、ユーザは、適度に長い期間にわたって有効な証明書と証明書失効リストを容易く入手でき、最新情報を得るために証明機関に接続する必要はない。
【０２３５】
図３０および図３１のフローチャートには、前述したプロセスが示されている。図３０に示すように、ホスト２４は、認証のためにメモリ装置に提示する証明書に付随するＣＲＬを、メモリ装置１０の非保護公開領域から読み出す（ブロック６５２）。ＣＲＬはメモリの非保護領域に記憶されているため、ホストによるＣＲＬの入手より前に認証は必要でない。ＣＲＬはメモリ装置の公開領域に記憶されているため、ＣＲＬの読出しはホスト装置２４によって管理される。そして、ホストは、ＣＲＬを検証の対象となる証明書と併せてメモリ装置へ送信し（ブロック６５４）、メモリ装置１０から失敗通知を受け取らなければ次の段階へ進む（ブロック６５６）。図３１を参照し、メモリ装置はホストからＣＲＬおよび証明書を受信し（ブロック６５８）、ＣＲＬにおける証明書通し番号の有無やその他の点（例えば、ＣＲＬが失効しているかどうか）をチェックする（ブロック６６０）。証明書通し番号がＣＲＬで見つかるか、あるいはその他の理由で失敗に終わる場合、メモリ装置はホストに失敗通知を送信する（ブロック６６２）。このように、同じＣＲＬを異なるホストの認証に使用できるため、それぞれのホストはメモリ装置の公開領域に記憶されたＣＲＬを入手することができる。前述したように、ＣＲＬを使用して検証する証明書もまた、ユーザの便宜を図るため、メモリ装置１０の非保護領域に、ＣＲＬと併せて記憶されていることが好ましい。しかしながら、メモリ装置に対して認証する場合に証明書を使用できるホストは、証明書の発行を受けたホストのみである。
【０２３６】
図３２に示すように、ＣＲＬのフィールドに次回の更新時間が含まれる場合、装置１０のＳＳＡは、現在の時間をこの時間に照らしてチェックし、現在の時間がこの時間を過ぎているかどうかを確認し、過ぎている場合は認証が失敗する。それゆえ、ＳＳＡは、現在の時間（またはメモリ装置１０でＣＲＬを受信した時間）に照らしてＣＥＴをチェックするばかりでなく、次回更新の時間もチェックすることが好ましい。
【０２３７】
前述したように、ＣＲＬに含まれる失効済み証明書の識別情報のリストが長くなると、リストの処理（例えば、ハッシュ計算）と、ホストによって提示される証明書の通し番号の検索とに時間を要し、処理と検索が順次に行われる場合は特に時間がかかる。それゆえ、このプロセスを加速するために、処理と検索とを同時に行ってもよい。さらに、ＣＲＬの全体を受信した後でないとＣＲＬの処理と検索にかかれない場合にも、プロセスに時間がかかることがある。本出願人らは、ＣＲＬの一部分を受信の時点で（その都度）処理し検索すれば、ＣＲＬの最終部分を受信するときにはプロセスは完了間際となり、プロセスが捗ることに気付いた。
【０２３８】
図３３および図３４は、前述した失効制度の特徴を示す。認証する側のエンティティ（例えば、メモリカードなどのメモリ装置）では、認証を受けようとするエンティティから、証明書およびＣＲＬを受信する（ブロック７０２）。暗号化されていないＣＲＬの一部分を処理し（例えば、ハッシュ化し）、それと同時に、提示された証明書の識別情報（例えば、通し番号）をそのような部分で検索する。処理された（例えば、ハッシュ化された）ＣＲＬ部分は、ハッシュ化された完全ＣＲＬにコンパイルされ、完全に復号化されハッシュ化されたＣＲＬと比較される。完全に復号化されハッシュ化されたＣＲＬは、認証を受ける側のエンティティから受信した復号化されたＣＲＬ部分をコンパイルすることによって、形成される。一致しないことが比較で明らかになる場合、認証は失敗に終わる。また、認証する側のエンティティは、現在の時間に照らして、ＣＥＴと次回更新時間の両方をチェックする（ブロック７０６、７０８）。提示された証明書の識別情報がＣＲＬに記載されていることが判明した場合、あるいは現在の時間がＣＥＴの範囲内にない場合、あるいはＣＲＬの次回更新時間が過ぎている場合にも、認証は失敗に終わる（ブロック７１０）。ハッシュ化されたＣＲＬ部分と、復号化されハッシュ化されたＣＲＬ部分とを、組み立てるために記憶する場合、大量の記憶容量を必要としない場合がある。
【０２３９】
認証を受けようとするエンティティ（例えば、ホスト）は、その証明書とＣＲＬを、認証する側のエンティティへ送信し（ブロック７２２）、次の段階へ進む（ブロック７２４）。これは図３４に示されている。
【０２４０】
エンティティが認証のために証明書連鎖を提示する場合にも、前述したものと同様のプロセスを実施することができる。この場合、連鎖の中の各証明書とその対応するＣＲＬにつき、前述したプロセスを繰り返す必要がある。各証明書とそのＣＲＬを受信したら、その都度処理することができ、証明書連鎖の残りの部分とその対応するＣＲＬの受信を待たなくてよい。
【０２４１】
前述の一部の実施形態では、認証を受けることを望むホストまたはエンティティは、認証の対象となる証明書と併せて、証明書失効リストを認証する側のエンティティに提示する。これらの実施形態では、証明機関から証明書失効リストを取り込むことができない不揮発性記憶装置に、エンティティの認証時に更新された証明書失効リストを利用することができる。しかしながら、これらの実施形態では、ホストを頼りに最新の証明書失効リストを提供し、ホストは証明機関から証明書失効リストを取り込むことができることを前提としている。非接続ホスト、例えばＭＰ３プレーヤは、認証中に不揮発性記憶装置に提示するための最新の証明書失効リストを取り込むことができないことがある。その結果、非接続ホストは、認証プロセス中に不揮発性記憶装置に、証明書失効リストの古いバージョンを提示してよい。
【０２４２】
別の実施形態では、不揮発性記憶装置に提示される証明書失効リストの最新バージョンを記憶（キャッシュ）することによって、この問題が回避される。新たに製造されるカードは、製造中に得られる最新または現在の証明書失効リストがプログラムされてもよい。認証中にホストがキャッシュされた失効リストを提供しない場合には、このキャッシュされた失効リストを不揮発性記憶装置に使用してもよい。さらに、ホスト装置が同じ機関から発行された証明書失効リストの古いバージョンを提示するとき、不揮発性記憶装置は、その記憶された証明書失効リストを使用してもよい。また、不揮発性記憶装置では、認証を受けることを求めるホストまたはエンティティから更新された証明書失効リストを提示されるとき、その証明書失効リストをオポチュニスティックに更新してもよい。それゆえ、別の実施形態では、証明書が失効しているかどうかを判定する方法および不揮発性記憶装置が開示される。この実施形態では、不揮発性記憶装置は、ホストのこの装置への認証を試行するために、ホストから証明書を受信する。不揮発性記憶装置は、証明書失効リストを含み、ホストに動作可能に結合される。そして、不揮発性記憶装置は、証明書失効リストの中にある証明書のリファレンスを検索することによって、証明書が失効しているかどうかを判定する。この実施形態では、証明書失効リストは、不揮発性記憶装置がホストから不揮発性記憶装置への認証を試行するために証明書を受信する前にキャッシュされて最新とされる。証明書失効リストの中にある証明書に対するリファレンスが、検索によって生成されると、ホストによる認証の試行は拒絶される。
【０２４３】
不揮発性記憶装置がホストから証明書失効リストを受信すると、不揮発性記憶装置は、ホストから受信した証明書失効リストを検証し、受信された証明書失効リストが不揮発性記憶装置の中にある現在の証明書失効リストよりも新しいかどうかを判定する。受信された証明書失効リストが検証されて、不揮発性記憶装置の中にある現在の証明書失効リストよりも新しければ、現在の証明書失効リストはホストから受信された新しい証明書失効リストに置換される。そして、不揮発性記憶装置に過去に記憶された現在の証明書失効リストを使用する代わりに、新しい証明書失効リストが使用されて、ホストからの証明書が失効しているかどうかが判定される。
【０２４４】
不揮発性記憶装置がホストから証明書失効リストを受信し、不揮発性記憶装置がその発行機関からの証明書失効リストを現在記憶していない場合、不揮発性記憶装置が首尾よく検証されているならば、不揮発性記憶装置は受信された証明書失効リストを記憶し使用する。
【０２４５】
証明書失効リストは、証明書失効リストを記憶する専用のメモリの領域などの、不揮発性記憶装置１０のメモリの中に記憶されてもよい。一実施形態では、証明書失効リストは、証明書失効リストのデータベースに記憶されてもよい。証明書失効リストを記憶するデータベース、メモリ、または記憶容量は、例えば、アクセス権限のないエンティティによる証明書失効リストの変更や削除を防止するように保護されてもよい。
【０２４６】
これまでに一般的に説明した上記実施形態のほかに、以下の段落では、採用しうる具体的な実施形態を提示する。この実施形態は単なる例であって、本明細書に記載する詳細は、本明細書において明示的に列挙されない限り、特許請求の範囲に引用されるはずがないことに留意されたい。この具体的な実施形態では、証明書失効リストがアクセス制御記録（ＡＣＲ）に関連付けられる。エンティティがＡＣＲを用いて認証される場合、関連付けられた証明書失効リストは、提示された証明書が失効しているかどうかを判定するためにチェックされる。ＣＲＬを利用するこのようなＡＣＲを作成する場合、初期のＣＲＬを受信してＡＣＲと関連付けることができる。この実施態様を図４９と関連させて説明する。
【０２４７】
図４９は、証明書失効リストを用いてアクセス制御記録を構成する、例示的なステップ４９００を示すフローチャートである。例示的ステップ４９００は、新たなＡＣＲを作成または構成するために利用されるプロセスの一部であってもよい。制御は、ステップ４９０２で開始する。制御はステップ４９０８に進み、ここで、作成されているＡＣＲが１つまたは複数のキャッシュＣＲＬをサポートするか、それともこのＣＲＬに関連付けられるかが判定される。作成されているＡＣＲがキャッシュＣＲＬをサポートしなければ、制御はＡＣＲの作成および構成を終了するためにステップ４９０４に進み、この後、ＡＣＲが作成されて構成されると、ステップ４９０６に進む。作成されているＡＣＲがキャッシュＣＲＬをサポートする場合、制御はステップ４９０８からステップ４９１０に進み、ここでＣＲＬデータが、ＡＣＲを作成するエンティティから受信される。ステップ４９１２において、受信されたＣＲＬデータは、キャッシュＣＲＬデータベースにキャッシュされる。制御はステップ４９１４に進み、ここでＣＲＬデータのすべてが受信されているかどうかが判定される。ＣＲＬデータのすべてがまだ受信されていなければ、制御はステップ４９１４からステップ４９１０に進み、ステップ４９１０、４９１２、および４９１４はＣＲＬデータのすべてが受信されるまで繰り返される。ステップ４９１０、４９１２、および４９１４は大量のセクタのＣＲＬデータの受信を表しているが、ビット、バイト、ワード、および長いワードなどの他のインクリメントのＣＲＬデータを受信することも可能である。ＣＲＬデータのすべてが受信されている場合、制御はステップ４９１４からステップ４９１６に進み、ここで、受信されたＣＲＬがキャッシュＣＲＬとしてＡＣＲと関連付けられて解析される。制御は、この後、ＡＣＲの作成および構成を終了するためにステップ４９０４に進み、さらに、ＡＣＲが作成されて構成された後、ステップ４９０６に進む。ステップ４９００は、１つのＣＲＬとＡＣＲの関連を示しているが、証明書連鎖に対する複数のＣＲＬが受信され、キャッシュされ、ＡＣＲと関連付けられてもよい。
【０２４８】
図５０は、認証中に、不揮発性記憶装置にキャッシュされあるいはこの装置に提供される証明書失効リストを使用して不揮発性記憶装置を認証する、例示的なステップを示すフローチャートである。例示的なステップ５０００は、不揮発性記憶装置によりエンティティを認証するステップの一部分または一側面であってもよい。制御は、ステップ５０００で開始する。ステップ５００４に進み、ここで、認証に使用されるアカウントまたはＡＣＲがチェックされて、これがキャッシュＣＲＬをサポートするか、それともキャッシュＣＲＬに関連付けられるかを判定する。ＡＣＲがキャッシュＡＣＲと関連付けられなければ、制御はステップ５００６に進む。ＡＣＲがキャッシュＣＲＬと関連付けられなければ、認証を求めるホストまたはエンティティは、証明書と併せてＣＲＬを提供しなければならない。ステップ５００６は、証明書を処理するときに使用されるＣＲＬを、ホストが提供しているかどうかを試験する。ホストがＣＲＬを提供していなければ、制御は５００８に進み、証明書が引き続き有効かどうかを判定するためのＣＲＬが不揮発性記憶装置に提供されておらず、当該ＣＲＬにアクセスできないため、認証は失敗する。ホストがＣＲＬを提供していれば、制御はステップ５００６からステップ５０１０に進み、ここでＣＲＬが処理されて証明書が失効しているかどうかが判定される。制御はこの後ステップ５０１２に進み、他の認証処理を再開するか、または終了する。
【０２４９】
ＡＣＲがキャッシュＣＲＬをサポートするように構成される場合、制御はステップ５００４からステップ５０１４に進む。ステップ５０１４は、認証を求めるホストからＣＲＬヘッダが受信されているかを判定する。認証を求めるホストからＣＲＬヘッダが受信されていなければ、制御はステップ５０２２に進み、ここで不揮発性記憶装置はキャッシュＣＲＬ（キャッシュＣＲＬが証明機関から得られる場合）を使用してホストが提示する証明書を検証し、証明書が失効しているかどうかを判定する。さらに、制御はステップ５０１２に進み、他の認証処理を再開するかまたは終了する。図には示されていないが、不揮発性記憶装置により使用されるキャッシュＣＲＬが得られなければ、認証は失敗する。
【０２５０】
認証を求めるホストがＣＲＬヘッダを提供している場合、ステップ５０００は、不揮発性記憶装置が同じ証明機関からのＣＲＬを現在記憶しているかどうか、および、記憶している場合には、キャッシュＣＲＬがホストが提示しようとしているＣＲＬよりも新しいためにキャッシュＣＲＬが認証に使用されるべきかどうか、を判定しなければならない。それゆえ、制御はステップ５０１４からステップ５０１６に進む。ステップ５０１６において、ＣＲＬヘッダは、ＣＲＬのバージョンとＣＲＬの発行者に関する情報を抽出するために、解析される。
【０２５１】
ステップ５０１８において、抽出されたＣＲＬ発行者情報は、同じ発行者（証明機関）からのキャッシュＣＲＬがＡＣＲと関連付けられているかどうかを判定するために、キャッシュＣＲＬ情報と比較される。例えば、ＡＣＲは複数のＣＲＬと関連付けられてもよい。ＡＣＲが作成されるとき、あるいは装置が製造されるとき、ＡＣＲは発行者Ｘにより発行されたキャッシュＣＲＬを有していてもよい（あるいは、キャッシュＣＲＬが全くなくてよい）。不揮発性記憶装置がフィールドにあるとき、ＡＣＲを認証するホストは、発行者Ｙにより発行されたＣＲＬを提示してもよい。この例で適用されるようなステップ５０１８は、ＡＣＲが発行者Ｙにより発行されたＣＲＬを有していないことを確認し、発行者ＹからのＣＲＬが認証を求めるホストから受信されて検証される場合は、ＡＣＲと関連付けられ、証明書が失効していないことを検証するために使用されてもよいように、制御をステップ５０２４に指示することになる。
【０２５２】
認証のために提示される証明書に対応する証明機関からのキャッシュＣＲＬを不揮発性記憶装置が現在記憶している場合、制御はステップ５０２０に進む。そして、抽出されたＣＲＬバージョン情報がキャッシュＣＲＬバージョンと比較されて、ホストにより提示されているＣＲＬがキャッシュＣＲＬよりも新しいかどうかが判定される。ホストにより提示されているＣＲＬがキャッシュＣＲＬよりも新しい場合、制御はステップ５０２２に進む。そして、不揮発性記憶装置がキャッシュＣＲＬを使用して、ホストにより提示された証明書を検証し、証明書が失効しているかどうかを判定する。この後、ステップ５０１２に進んで、他の認証処理を再開するかまたは終了する。
【０２５３】
認証のために提示されている証明書に対応する証明機関からのキャッシュＣＲＬを不揮発性記憶装置が現在記憶していない場合、検証を求めるホストからＣＲＬが受信されるように、制御はステップ５０１８から５０２４に進む。そして検証される場合には、受信したＣＲＬが新しいキャッシュＣＲＬとして設定され、証明書が失効していないことを検証するために、設定されたキャッシュＣＲＬを使用してもよい。同様に、ホストから提示されるＣＲＬのバージョンがキャッシュバージョンよりも新しい場合、制御はステップ５０２４に進み、ホストから受信された新しいバージョンによってキャッシュＣＲＬの更新を試行する。ステップ５０２４において、ＣＲＬデータがホストから受信される。ステップ５０２６では、受信されたＣＲＬデータがキャッシュＣＲＬデータベースにキャッシュされる。制御はステップ５０２８に進み、ここで、ＣＲＬデータがすべて受信されているかどうかが判定される。ＣＲＬデータのすべてがまだ受信されていなければ、制御はステップ５０２８からステップ５０２４に進み、ＣＲＬデータのすべてが受信されるまでステップ５０２４、５０２６、および５０２８が繰り返される。
【０２５４】
ＣＲＬデータのすべてがホストから受信されると、制御はステップ５０３０から進み、受信されたＣＲＬの署名が検証されて、受信されたＣＲＬが証明書の発行者により発行されたかどうかが判定される。受信されたＣＲＬが証明書の同じ発行者により発行されている場合、制御はステップ５０３４に進み、ステップ５０２６において受信されキャッシュされたＣＲＬがＡＣＲと関連付けられて、新しいキャッシュＣＲＬとして設定される。制御は、この後ステップ５０２２に進む。不揮発性記憶装置は、キャッシュＣＲＬを使用してホストにより提示された証明書を検証し、証明書が失効しているかどうかを判定する。この後、ステップ５０１２に進んで、他の認証処理を再開するかまたは終了する。
【０２５５】
ＣＲＬがステップ５０３２において検証されない場合、制御はステップ５０２２に進む。ここで、不揮発性記憶装置はキャッシュＣＲＬ（これが証明機関から得られる場合）を使用してホストにより提示された証明書を検証し、証明書が失効しているかどうかを判定する。制御は、この後ステップ５０１２に進んで、他の認証処理を再開するかまたは終了する。図には示されていないが、キャッシュＣＲＬが不揮発性記憶装置により使用できなければ、認証は失敗する。
【０２５６】
前述のように、ＳＳＡでは証明書連鎖が可能である。これは、認証される側のエンティティの公開鍵が、認証する側のエンティティとは異なる証明機関（ＣＡ）によって署名されてもよいことを意味する。この場合、認証される側のホストは、それ自体の証明書のほかに、その公開鍵に署名したＣＡの証明書を提供することになる。この第２レベルの証明書が、不揮発性記憶装置によりまだ信用されなければ（ＡＣＲに関連付けられた、信頼されたＣＡによって署名されなければ）、第３レベルの証明書が提供される。一実施形態では、ステップ５０００が繰り返されて、不揮発性記憶装置は、証明書連鎖の一部としてホストにより提示された各証明書を処理することができる。この実施形態では、連鎖の中の各証明書は、証明書が失効しているかどうかを判定するために使用される個別のＣＲＬと関連付けられてもよい。不揮発性記憶装置は、証明書連鎖の中で各証明書と関連付けられたＣＲＬのバージョンをキャッシュしてもよく、図５に示された例示的なステップ５０００に従ってそのＣＲＬを利用または更新してもよい。
【０２５７】
それゆえ、一実施形態において、アカウントまたはＡＣＲでは、ホストが送信するＣＲＬを使用してホスト証明書を検証するのではなく、内部キャッシュＣＲＬを使用してホスト証明書を検証することができる。内部キャッシュＣＲＬは認証中に使用することができるため、ホストは、認証中に提示されるホスト証明書に結合されたＣＲＬを、ＡＣＲに送信する必要がない。不揮発性記憶装置は、失効している証明書を識別する製造時に、ＣＲＬ（または証明書連鎖に対する複数のＣＲＬ）がプログラムされてもよい。製造後、不揮発性記憶装置は、ホストを認証するときに遭遇するより新しいＣＲＬで、更新されてもよい。
【０２５８】
一実施形態では、内部キャッシュＣＲＬは、ＡＣＲが作成されるときに使用が可能であってもよい。ＡＣＲの作成中に、ホスト証明書連鎖に対する１つまたは複数のＣＲＬは、不揮発性記憶装置で受信され、不揮発性記憶装置にキャッシュされ、ＡＣＲと関連付けられる。このようなＡＣＲへの認証を試行するためにＣＲＬを送信するとき、不揮発性記憶装置は、受信されたＣＲＬを以前にキャッシュされたＣＲＬと比較する。キャッシュされたＣＲＬバージョンがホストから受信されたＣＲＬよりも新しければ、不揮発性記憶装置は、キャッシュＣＲＬを使用してホスト証明書を検証する。ホストから受信されたＣＲＬのバージョンがキャッシュバージョンよりも新しければ、不揮発性記憶装置は、受信されたＣＲＬの署名を検証してこれが証明書の発行者により発行されたものかどうかを判定する。受信されたＣＲＬが証明書の発行者と同じ発行者によって発行される場合、キャッシュＣＲＬは新しいものに置換される。不揮発性記憶装置は、この後、更新された証明書失効リストを使用してホストが失効していなかったことを検証する。一実施形態では、カードが証明書そのものを検証した後、証明書の通し番号をＣＲＬの中の通し番号のリストと比較することにより、ホストが失効していないことを検証する。
【０２５９】
ホストの認証中に、不揮発性記憶装置の中にキャッシュされたＣＲＬをホスト証明書が有していない場合には、不揮発性記憶装置はホストにより受信されたＣＲＬを使用してもよい。ＣＲＬをキャッシュするデータベースがまだ満杯でなければ、不揮発性記憶装置は、受信されたＣＲＬを将来の使用に備えてキャッシュすることになる。
【０２６０】
証明書に対応するＣＲＬがキャッシュされない場合、またホストがＣＲＬを提供しない場合、証明書を処理するためのＣＲＬが得られないため認証は失敗する。例えば、ホストは、認証中に証明書を送信した後、不揮発性記憶装置に対してＣＲＬを送信してもよく、あるいは連鎖の中の次の証明書を不揮発性記憶装置に送信してもよい。後者の場合、不揮発性記憶装置は、キャッシュＣＲＬを用いて第１の証明書を検証することになる。証明書の発行者に対してＣＲＬがキャッシュされなければ、認証は失敗する。
【０２６１】
それゆえ、新しい不揮発性記憶装置を製造するときに、更新された失効リストを装置に記憶させてもよい。ＣＲＬは、既に信頼されていない、フィールド中のホストを識別することができる。そのホストの証明書は、不揮発性記憶装置の製造より前に失効している。この実施形態では、キャッシュされた証明書失効リストをチェックすることにより、ホストの証明書が失効しているかどうかを不揮発性記憶装置が検証できるため、ホストが証明書失効リストを不揮発性記憶装置に送信する必要がない。ＣＲＬを不揮発性記憶装置に伝達すると、認証を長引かせる可能性がある。それゆえ、キャッシュＣＲＬを使用することで、認証プロセスを短縮することができる。
【０２６２】
しかしながら、証明機関は長期にわたってＣＲＬを更新することができ、それゆえに、キャッシュＣＲＬは時間の経過とともに期限切れとなり使用されなくなる可能性がある。ホストが更新されたバージョンのＣＲＬを用いて認証を試行する場合には、不揮発性記憶装置は、キャッシュＣＲＬをオポチュニスティックに更新する可能性がある。不揮発性記憶装置にアクセスしようとする一部のホストは、証明書発行機関に（有線または無線接続によって）接続して、認証中に提示するための更新されたＣＲＬを入手することができる。このような接続ホストが、不揮発性記憶装置の認証を試行するときに更新されたＣＲＬを提供すると、不揮発性記憶装置は、更新されたＣＲＬをキャッシュして将来これを利用することができる。このプロセスを使用するＣＲＬのオポチュニスティック型の更新は、更新されたＣＲＬに対するバイラル方式の配布システムとして、効果的に機能を果たすことができる。
【０２６３】
例えば、不揮発性記憶装置は、ＭＰ３プレーヤに動作可能に接続されてもよい。この例では、ＭＰ３プレーヤには、有線または無線接続を介して証明機関に接続するなどして、更新された証明書失効リストにアクセスする能力がない。それゆえ、ＭＰ３プレーヤは、不揮発性記憶装置にアクセスしようとするたびに、同じ証明書と証明書失効リストを提示する。時間の経過とともに証明機関は証明書失効リストを更新するため、ＭＰ３プレーヤにより提示されるそのリストは無効になる可能性がある。不揮発性記憶装置がＭＰ３プレーヤに単に動作可能に結合されている限り、そのＣＲＬのキャッシュコピーは、ＭＰ３プレーヤにより提示されるＣＲＬと同じバージョンになる。それゆえ、キャッシュＣＲＬはやはり時間の経過に伴って無効になる。
【０２６４】
その後、不揮発性記憶装置が、更新されたＣＲＬを受信できる装置に動作可能に結合されると、不揮発性記憶装置は、ＣＲＬの「バイラル形式」の更新をオポチュニスティックに受信することができる。例えば、不揮発性記憶装置がＭＰ３プレーヤから取り出されて携帯電話に動作可能に結合されると、装置に記憶されたコンテンツにアクセスするために、不揮発性記憶装置への認証を試行することができる。携帯電話は、更新された証明書失効リストを証明機関に要求することができる。更新された証明書失効リストは、携帯電話がコンテンツにアクセスするために使用しようとする証明書に対応する。携帯電話は、有線または無線接続を介して更新された証明書失効リストを、受信することができる。携帯電話が、不揮発性記憶装置を認証して記憶されたコンテンツにアクセスするために、証明書と併せて更新された証明書失効リストを提示すると、不揮発性記憶装置は、そのキャッシュ証明書失効リストを、携帯電話から受信されたコピーで更新することになる。このようにして、証明機関に接触して更新された証明書失効リストをそれ自体で受信できる独立した機能を有していない不揮発性記憶素子に対して、証明書失効リストを分配するために、携帯電話、パーソナルコンピュータ、およびインターネット家電などの接続装置を使用することができる。
【０２６５】
＜アイデンティティ・オブジェクト（ＩＤＯ）＞
アイデンティティ・オブジェクトは、フラッシュ・メモリ・カードなどのメモリ装置１０が、ＲＳＡ鍵対またはその他の暗号ＩＤを記憶できるように設計された、被保護オブジェクトである。アイデンティティの署名および検証や、データの暗号化および復号化に使用することができる暗号ＩＤであれば、どのようなタイプのものでも、アイデンティティ・オブジェクトに含めることができる。鍵対の公開鍵が真正であることを証明するＣＡの証明書（または複数のＣＡの証明書連鎖）も、アイデンティティ・オブジェクトに含まれる。アイデンティティ・オブジェクトを使用すれば、外部エンティティや内部カードエンティティ（すなわち、アイデンティティ・オブジェクトの所有者と称される装置自体、内部のアプリケーションなど）のアイデンティティの証拠を、提供することができる。したがって、カードは、チャレンジ・レスポンス機構でホストを認証するためにＲＳＡ鍵対またはその他のタイプの暗号ＩＤを使用せずに、識別情報の証拠として、カードに提示されるデータストリームに署名する。換言すると、アイデンティティ・オブジェクトは、その所有者の暗号ＩＤを含む。アイデンティティ・オブジェクトの中の暗号ＩＤにアクセスするには、まずホストを認証する必要がある。後述するように、この認証プロセスはＡＣＲによって管理される。ホストの認証に成功すると、アイデンティティ・オブジェクトの所有者は、相手方に対して暗号ＩＤを使用して自身のアイデンティティを立証することができる。例えば、相手方からホストを通じて提示されるデータには、暗号ＩＤ（例えば、公開−秘密鍵対の秘密鍵）を使用して署名することができる。アイデンティティ・オブジェクトの署名済みデータと証明書は、アイデンティティ・オブジェクトの所有者に代わって相手方に提示される。証明書にある公開−秘密鍵対の公開鍵が真正であることは、ＣＡ（すなわち、信用機関）によって証明されるため、相手方はこの公開鍵が真正であると信用することができる。そこで相手方は、証明書の公開鍵を使用して署名済みデータを復号化し、復号化されたデータを相手方によって送信されたデータと比較することができる。復号化されたデータが相手方によって送信されたデータに一致する場合、アイデンティティ・オブジェクトの所有者は、真正な秘密鍵にアクセスできる自称通りのエンティティであることが分かる。
【０２６６】
アイデンティティ・オブジェクトの第２の利用法は、ＲＳＡ鍵自体などの暗号化ＩＤを用いて、ＩＤＯの所有者に対して指定されるデータを保護することである。データは、ＩＤＯ公開鍵を用いて暗号化されるものと予想される。メモリカードなどのメモリ装置１０は、公開鍵を使用してデータを復号化する。
【０２６７】
ＩＤＯは、いかなるタイプのＡＣＲに対しても作成できるオブジェクトである。一実施形態では、ＡＣＲは、１つのみのＩＤＯオブジェクトを有していてもよい。データ署名および保護機能は、いずれも、ＡＣＲを認証できるすべてのエンティティに対してＳＳＡシステムから提供されるサービスである。ＩＤＯの保護レベルは、ＡＣＲのログイン認証方式と同じくらい高い。ＩＤＯを必ず有することになるＡＣＲに対しては、任意の認証アルゴリズムを選定することができる。ＩＤＯ運用を良好に保護しうるアルゴリズムを評価し決定するのは、作成元（ホスト）である。ＩＤＯを有するＡＣＲは、ＩＤＯ公開鍵取得コマンドに応じて証明書連鎖を提供する。
【０２６８】
データ保護にＩＤＯを使用する場合でも、カードから出力される復号化データにはさらなる保護が必要になることがある。そのような場合、いずれかの認証アルゴリズムによって確立されるセキュアチャネルを使用することが、ホストに推奨される。
【０２６９】
ＩＤＯを作成するときに、鍵の長さとともに、ＰＫＣＳ＃１バージョンを選択する。一実施形態において、公開鍵および秘密鍵に、ＰＫＣＳ＃１バージョン２．１で定める（指数、係数）表現を使用する。
【０２７０】
一実施形態において、ＩＤＯの作成中に含められるデータは、選択された長さを有するＲＳＡ鍵対と、公開鍵の信頼性を帰納的に証明する証明書連鎖である。
【０２７１】
ＩＤＯを所有するＡＣＲは、ユーザデータの署名を許可する。これは、２つのＳＳＡコマンドによって行われる。
・Ｓｅｔ  ｕｓｅｒ  ｄａｔａ：署名の対象となる自由書式のデータバッファを提供する。
・Ｇｅｔ  ＳＳＡ  ｓｉｇｎａｔｕｒｅ：カードは、ＲＳＡ署名を提供する（ＡＣＲ秘密鍵を使用）。署名の形式とサイズは、オブジェクトのタイプに応じて、ＰＫＣＳ＃１バージョン１．５またはＶ２．１に従って設定することができる。
【０２７２】
図３５〜図３７はＩＤＯを使用した操作を示すものである。ここで、メモリ装置１０はフラッシュ・メモリ・カードであり、このカードがＩＤＯの所有者である。図３５は、ホストに送信されるデータに署名する場合に、カードによって実行されるプロセスを示す。図３５を参照し、前述したツリー構造のノードに位置するＡＣＲの管理下でホストが認証された後（ブロック８０２）、カードは証明書を求めるホスト要求を待つ（菱形８０４）。要求を受信したカードは証明書を送信し、菱形８０４に戻り、次のホスト要求を待つ（ブロック８０６）。カードが所有するＩＤＯの公開鍵を証明するために、証明書連鎖を送信する必要がある場合、連鎖の中のすべての証明書がホストへ送信されるまで、前述したアクションが繰り返される。各証明書がホストに送信された後、カードは、ホストから他のコマンドが届くのを待つ（菱形８０８）。所定の期間内にホストからのコマンドが受信されなければ、カードは菱形８０４に戻る。ホストからデータとコマンドを受信したカードは、そのコマンドをチェックし、データに署名するためのものであるかどうかを確認する（菱形８１０）。データに署名するためのコマンドである場合、カードはＩＤＯの秘密鍵を使用してデータに署名し、署名したデータをホストへ送信し（ブロック８１２）、菱形８０４に戻る。ホストからのコマンドがホストからのデータに署名するためのものでなければ、カードはＩＤＯの秘密鍵を使用して受信データを復号化し（ブロック８１４）、菱形８０４に戻る。
【０２７３】
図３６は、ホストへ送信されるデータにカードが署名する際に、ホストによって実行されるプロセスを示す。図３６を参照すると、ホストは、カードに認証情報を送信する（ブロック８２２）。前述したツリー構造のノードに位置するＡＣＲの制御下で認証に成功すると、ホストは、証明書連鎖を求める要求をカードに送信し、連鎖を受信する（ブロック８２４）。カードの公開鍵が検証されると、ホストは署名されるデータをカードに送信し、カードの秘密鍵により署名されたデータを受信する（ブロック８２６）。
【０２７４】
図３７は、ホストがカードの公開鍵を使用してデータを暗号化し、暗号化されたデータをカードに送信するときに、ホストによって実行されるプロセスを示す。図３７を参照すると、ホストは、カードへ認証情報を送信する（ブロック８６２）。ＡＣＲの管理下で認証に成功すると、ホストは、ＩＤＯの中にあるカードの公開鍵を検証するために必要となる証明書連鎖の要求をカードに送信し（ブロック８６４）、さらにデータを求める要求をカードに送信する。ＩＤＯの中にあるカードの公開鍵を検証した後、ホストは、カードの検証済み公開鍵を使用してカードから受信したデータを暗号化し、これをカードに送信する（ブロック８６６、８６８）。
【０２７５】
＜クエリ＞
ホストおよびアプリケーションは、システム操作を実行するために、相手方のメモリ装置またはカードに関する一定の情報を所有する必要がある。例えば、ホストおよびアプリケーションは、メモリカードに記憶されたアプリケーションのうち、実行できるアプリケーションがいずれであるかを知る必要がある。ホストにとっての必要情報は公知でない場合があり、これはその情報を所有する権利を有する者とそうでない者があることを意味する。権限を持つユーザと持たないユーザとを区別するには、ホストで使用できるクエリを２通り用意する必要がある。
【０２７６】
＜一般情報クエリ＞
このクエリは、システム公開情報を無制限に放出する。メモリ装置に記憶される機密情報は、２つの部分、すなわち、共有部分および非共有部分からなる。各エンティティが自身の専有情報のみへのアクセスが認められ、他のエンティティの専有機密情報にアクセスすることができないように、機密情報の一部分には、個々のエンティティにとっての専有情報が含まれている。この種の機密情報は共有されず、機密情報の非共有部位または部分を形成する。
【０２７７】
カードに常駐するアプリケーションの名称とそのライフサイクル状態など、通常は公の情報と考えられるものでも、場合によっては機密とみなされることがある。別の例として、公の情報とされるルートＡＣＲ名であっても、ＳＳＡを使用する一部の場合には、機密になることがある。このような場合には、一般情報クエリに応じて情報をすべて認証済みユーザに限って利用させ、認証されていないユーザには利用させないようにするためのオプションを、システムに用意しなければならない。このような情報は、機密情報の共有部分を占める。ルートＡＣＲリスト、すなわち装置上に現在存在する全ルートＡＣＲのリストは、機密情報の共有部分の一例となりうる。
【０２７８】
一般情報クエリにより公開情報へアクセスする場合、ホスト／ユーザはＡＣＲにログインする必要がない。それゆえ、ＳＳＡ規格に精通する者であれば誰でも実行可能であり、情報を受信することができる。ＳＳＡの規定では、セッション番号なしでこのクエリコマンドが処理される。しかしながら、機密情報の共有部分へのアクセスを望むエンティティは、最初に、メモリ装置のデータに対するアクセスを制御する制御構造のいずれか（例えば、ＡＣＲのいずれか）を通じて認証される必要がある。認証に成功したエンティティは、一般情報クエリを使用して、機密情報の共有部分にアクセスできるようになる。前述したように、認証プロセスの結果として、アクセスするためのＳＳＡセッション番号またはｉｄが得られる。
【０２７９】
＜取扱い注意情報クエリ＞
個々のＡＣＲとそのシステムアクセスおよび資産に関する私的情報は、取扱い注意とされ、明確な認証を必要とする。この種の情報クエリでは、情報クエリの認証を受信する前に、ＡＣＲのログインと認証（認証がＡＣＲで指定されている場合）が必要になる。このクエリには、ＳＳＡセッション番号が必要である。
【０２８０】
２種類のクエリを詳述する前に、クエリを実行する現実的な解決策として、インデックスグループの概念をまず説明することが有益である。
【０２８１】
＜インデックスグループ＞
ポテンシャルＳＳＡホストで実行するアプリケーションには、読出しの対象となるセクタ数を指定することが、ホスト上のオペレーティングシステム（ＯＳ）とシステムドライバとにより求められる。これは、ホストアプリケーションが、ＳＳＡ読出し操作のたびに読み出す必要のあるセクタ数を知る必要があることを意味する。
【０２８２】
クエリ操作で供給される情報は、一般的には、これを要求する側にとって未知の情報であるため、ホストアプリケーションがクエリを発行し、その操作に必要なセクタの量を推測することは困難である。
【０２８３】
この問題を解決するため、ＳＳＡのクエリ出力バッファは、各クエリ要求につき１つのみのセクタ（５１２バイト）からなる。出力情報の一部であるオブジェクトは、インデックスグループと呼ばれるものに編成される。オブジェクトのバイトサイズはオブジェクトのタイプによって異なり、そこから１セクタに収まるオブジェクトの数が明らかになる。これによって、オブジェクトのインデックスグループが決まる。オブジェクトのサイズが２０バイトである場合、このオブジェクトのインデックスグループは最大２５オブジェクトを含む。このようなオブジェクトが全部で５６個ある場合、それらは３つのインデックスグループに編成され、第１のインデックスグループの先頭はオブジェクト「０」（第１のオブジェクト）となり、第２のインデックスグループの先頭はオブジェクト「２５」となり、第３の最終インデックスグループの先頭はオブジェクト５０となる。
【０２８４】
＜システムクエリ（一般情報クエリ）＞
このクエリは、装置がサポートするＳＳＡシステムと、ツリー状に構成された現行のシステムと、装置で実行するアプリケーションとに関する一般公開情報を提供する。後述するＡＣＲクエリ（取扱い注意クエリ）と同様に、システムクエリは、複数のクエリオプションを提供するように構成される。
・Ｇｅｎｅｒａｌ：サポートされたＳＳＡバージョン
・ＳＳＡ  Ａｐｐｌｉｃａｔｉｏｎｓ：現在装置に存在する全ＳＳＡアプリケーションのリストで、アプリケーションの実行状態を含む。
【０２８５】
前述した情報は公開情報である。ＡＣＲクエリと同様に、ホストがクエリ出力バッファのための読出しセクタ数を知らずに済ませるため、装置からは１セクタが返送され、ホストは引き続きさらなるインデックスグループを照会することができる。ルートＡＣＲオブジェクトの数が、インデックスグループ「０」のための出力バッファサイズの数を超える場合、ホストは、後続のインデックスグループ（「１」）で、別のクエリ要求を送信することができる。
【０２８６】
＜ＡＣＲクエリ（取扱い注意情報クエリ）＞
ＳＳＡのＡＣＲクエリコマンドは、鍵ＩＤ、アプリケーションＩＤ、パーティション、子ＡＣＲなど、ＡＣＲのシステムリソースに関する情報をＡＣＲユーザに供給するためのものである。そのクエリ情報は、ログインされたＡＣＲに関するもののみであり、システムツリー上の他のＡＣＲに関するものはない。換言すると、アクセスは、関与するＡＣＲの許可のもとでアクセス可能な機密情報の部分のみに限られる。
【０２８７】
ユーザが照会できるＡＣＲオブジェクトには、以下の３つがある。
・パーティション：名称とアクセス権（所有者、読出し、書込み）。
・鍵ＩＤとアプリケーションＩＤ：名称とアクセス権（所有者、読出し、書込み）。
・子ＡＣＲ：ＡＣＲ、および、直接の子にあたるＡＣＲのＡＧＰ名称。
・ＩＤＯとセキュア・データ・オブジェクト（後述）：名称とアクセス権（所有者、読出し、書込み）。
【０２８８】
ＡＣＲに結び付いたオブジェクトの数は、変化する場合があり、情報は５１２バイト、すなわち１セクタを上回ることがある。オブジェクトの数が事前に分からない限り、ユーザは、リストすべてを得るために装置内のＳＳＡシステムから読み出される必要があるセクタの数を知ることはできない。そこで、前述したシステムクエリの場合と同様に、ＳＳＡシステムによって提供される各オブジェクトリストは、インデックスグループに分割される。インデックスグループはセクタに収まるオブジェクトの数であり、すなわち、装置内のＳＳＡシステムからホストに１セクタで送信できるオブジェクトの数である。これにより、装置内のＳＳＡシステムは、要求されたインデックスグループを１セクタで送信することができる。ホスト／ユーザは、照会したオブジェクトのバッファ、バッファ内のオブジェクト数を受信することになる。バッファが一杯である場合、ユーザは次のオブジェクト・インデックス・グループを照会することができる。
【０２８９】
図３８は、一般情報クエリを伴う操作を示すフローチャートである。図３８を参照すると、エンティティから一般情報クエリを受信したＳＳＡシステムは（ブロック９０２）、そのエンティティが認証済みかどうかを判定する（菱形９０４）。認証済みである場合には、システムは、公開情報と機密情報の共有部分とをエンティティに供給する（ブロック９０６）。認証済みでなければ、システムは、公開情報のみをエンティティに供給する（ブロック９０８）。
【０２９０】
図３９は、取扱い注意情報クエリを伴う操作を示す、フローチャートである。図３９を参照すると、エンティティから取扱い注意情報クエリを受信したＳＳＡシステムは（９２２）、そのエンティティが認証済みかどうかを判定する（菱形９２４）。認証済みである場合には、システムは、エンティティに機密情報を供給する（ブロック９２６）。認証済みでない場合には、システムは、機密情報に対するエンティティのアクセスを拒絶する（ブロック（９２８）。
【０２９１】
＜フィーチャ・セット・エクステンション（ＦＳＥ）＞
多くの場合、データ処理活動（例えば、ＤＲＭライセンスオブジェクト検査）をカード上のＳＳＡの内部で実行できることは、大変有利である。その結果、データ処理タスクのすべてをホストで実行する代替的な解決策に比べて、より安全でより効率的なシステムとなり、ホストへの依存度も低くなる。
【０２９２】
ＳＳＡセキュリティシステムは、メモリカードによって記憶され、管理され、保護されるオブジェクトのアクセス、使用、収集を制御する、１組の認証アルゴリズムと認可ポリシーとを備える。アクセスを得たホストは、メモリ装置に記憶されたデータに対して処理を実行し、メモリ装置に対するアクセスはＳＳＡによって制御される。しかしながら、データは、本質的にアプリケーションに非常に依存するものであると考えられるため、装置に記憶されたデータを取り扱わないＳＳＡでは、データ形式またはデータ処理は定義されない。
【０２９３】
本発明の一実施形態は、通常であればホストによって実施される機能の一部を、メモリカードで実行するように、ＳＳＡシステムを強化できるという認識に基づく。そこで、ホストのソフトウェア機能のいくつかは、２つの部分、すなわち引き続きホストによって実施される部分と、カードによって実施される部分とに分かれる場合がある。こうすることで、多くの用途にとって、データ処理の安全性と効率性が向上する。この目的のため、ＦＳＥと呼ばれる機構を加えることによって、ＳＳＡの能力を高める場合がある。このように、カードによって実行されるＦＳＥのホストアプリケーションを、本明細書では、内部アプリケーションまたは装置内部アプリケーションと呼ぶ場合がある。
【０２９４】
強化ＳＳＡシステムは、カードの認証およびアクセス制御を提供する基本ＳＳＡコマンド群を、カードアプリケーションの導入により拡張する機構を提供する。カードアプリケーションは、ＳＳＡ以外のサービス（例えば、ＤＲＭスキーム、ｅコマーストランザクション）を実行することになっている。ＳＳＡフィーチャ・セット・エクステンション（ＦＳＥ）は、独自開発のデータ処理ソフトウェア／ハードウェアモジュールで、標準ＳＳＡセキュリティシステムを強化するように設計された機構である。ＳＳＡ＿ＦＳＥシステムのサービスにより、ホスト装置は、前述したクエリ用いて得られる情報のほかに、カードで使用可能なアプリケーションを照会し、特定のアプリケーションを選択し、これと通信することができる。前述した一般クエリと取扱い注意クエリを、この目的に使用することもできる。
【０２９５】
＜ＳＳＡ＿ＦＳＥでカード機能群を拡張するには２つの方法を利用する：＞
・サービス提供：この機能は、認可されたエンティティが、通信パイプと呼ばれる独自のコマンドチャネルを使用して内部アプリケーションと直接通信することによって実現する。
・ＳＳＡ標準アクセス制御ポリシーの拡張：この機能は、内部の被保護データオブジェクト（例えば、ＣＥＫ、後述するセキュア・データ・オブジェクト、すなわちＳＤＯ等）に内部カードアプリケーションを関連付けることによって、実現する。このようなオブジェクトにアクセスするときに、所定の標準ＳＳＡポリシーが満たされる場合は、関連付けアプリケーションが起動して、標準ＳＳＡポリシーに加えて少なくとも１つの条件を課す。この条件は、標準ＳＳＡポリシーとは衝突しないことが好ましい。この追加条件も満たされる場合に限り、アクセスが許諾される。ＦＳＥの能力をさらに詳述する前に、ＦＳＥの構造的態様と通信パイプとＳＤＯをここで取り上げる。
【０２９６】
＜ＳＳＭモジュールおよび関連モジュール＞
図４０Ａは、ホスト装置２４に接続されたメモリ装置１０（フラッシュ・メモリ・カードなど）におけるシステムアーキテクチャ１０００の機能ブロック図であり、本発明のある実施形態を例示するものである。カード２０のメモリ装置にあるソフトウェアモジュールの主要な構成要素は、次の通りである。
【０２９７】
＜ＳＳＡトランスポート層１００２＞
ＳＳＡトランスポート層は、カードプロトコルに依存する。これは、カード１０のプロトコル層でホスト側ＳＳＡ要求（コマンド）を処理し、処理された要求をＳＳＭ＿ＡＰＩに送る。ホスト−カードの同期とＳＳＡコマンドの識別は、すべてこのモジュールで行われる。ホスト２４とカード１０との間のすべてのＳＳＡデータ転送にも、トランスポート層が関与する。
【０２９８】
＜セキュア・サービス・モジュール・コア（ＳＳＭコア）１００４＞
このモジュールは、ＳＳＡの実施態様の重要な部分である。ＳＳＭコアは、ＳＳＡアーキテクチャを実施する。より具体的には、ＳＳＭコアは、ＳＳＡツリーと、ＡＣＲシステムと、システムを構成する前述の対応するすべてのルールと、を実施する。ＳＳＭコアモジュールは、暗号ライブラリ１０１２を使用して、ＳＳＡセキュリティと、暗号化、復号化、ハッシュ計算などの暗号機能と、をサポートする。
【０２９９】
＜ＳＳＭコアＡＰＩ＿１００６＞
これは、ホストと内部アプリケーションが、ＳＳＭコアと連携しながらＳＳＡ操作を実行する層である。図４０Ａに示すように、ホスト２４と内部装置アプリケーション１０１０は、いずれも同じＡＰＩを使用する。
【０３００】
＜セキュアアプリケーション管理モジュール（ＳＡＭＭ）１００８＞
ＳＡＭＭは、ＳＳＡシステムの一部ではないが、ＳＳＡシステムと連携しながら内部装置アプリケーションを制御する、カードの重要なモジュールである。
【０３０１】
ＳＡＭＭは、以下を含むアプリケーションを実行する内部装置のすべてを管理する。
１．アプリケーションライフサイクルの監視と制御
２．アプリケーションの初期化
３．アプリケーション／ホスト／ＳＳＡインターフェース
【０３０２】
＜装置内部アプリケーション１０１０＞
これらは、カード側での実行が許可されたアプリケーションである。これらはＳＡＭＭによって管理され、ＳＳＡシステムにアクセスできる場合がある。また、ホスト側アプリケーションと内部アプリケーションとの間の通信パイプは、ＳＳＭコアから提供される。ＤＲＭアプリケーションや以下で詳しく説明するワン・タイム・パスワード（ＯＴＰ）アプリケーションは、内部実行アプリケーションの例である。
【０３０３】
＜装置管理システム（ＤＭＳ）１０１１＞
これは、カードのシステムおよびアプリケーションファームウェアを更新したり、出荷後（一般的に後発行と称される）モードでサービスを追加／削除したりするための、プロセスおよびプロトコルを含むモジュールである。
【０３０４】
図４０Ｂは、ＳＳＭコア１００４の内部ソフトウェアモジュールの機能ブロック図である。図４０Ｂに示すように、コア１００４は、ＳＳＡコマンド処理部１０２２を含む。処理部１０２２は、ホストまたは装置内部アプリケーション１０１０から発行されたＳＳＡコマンドを解析した後、これをＳＳＡ管理部１０２４に渡す。ＡＧＰやＡＣＲなどのＳＳＡセキュリティデータ構造や、すべてのＳＳＡのルールとポリシーは、いずれもＳＳＡデータベース１０２６に記憶される。ＳＳＡ管理部１０２４は、データベース１０２６に記憶されたＡＣＲやＡＧＰやその他の制御構造によって、制御を実施する。ＩＤＯやセキュア・データ・オブジェクトをはじめとするその他のオブジェクトも、ＳＳＡデータベース１０２６に記憶される。ＳＳＡ管理部１０２４は、データベース１０２６に記憶されたＡＣＲやＡＧＰやその他の制御構造によって、制御を実施する。ＳＳＡが関与しない非セキュア操作は、ＳＳＡ非セキュア操作モジュール１０２８によって処理される。ＳＳＡアーキテクチャのもとでのセキュア操作は、ＳＳＡセキュア操作モジュール１０３０によって処理される。モジュール１０３２は、モジュール１０３０を暗号ライブラリ１０１２に接続するインターフェースである。１０３４は、モジュール１０２６および１０２８を、図１のフラッシュメモリ２０に接続する層である。
【０３０５】
＜通信（またはパススルー）パイプ＞
パススルー・パイプ・オブジェクトは、ＳＳＭコアとＳＡＭＭの制御下で認可されたホスト側エンティティと、内部アプリケーションとの通信を可能にする。ホストと内部アプリケーションとのデータ転送は、ＳＥＮＤコマンドとＲＥＣＥＩＶＥコマンドで行われる（後述）。実際のコマンドは、アプリケーションによって異なる。パイプを作成するエンティティ（ＡＣＲ）は、パイプ名と、チャネルの開通によってつながるアプリケーションのＩＤと、を提供することが必要になる。他の被保護オブジェクトと同様に、このＡＣＲがパイプの所有者になり、標準の委譲ルールおよび制限に従って、他のＡＣＲに使用権や所有権を委譲することが許可される。
【０３０６】
認証済みのエンティティは、そのＡＣＡＭでＣＲＥＡＴＥ＿ＰＩＰＥ権限が設定されている場合に、パイプオブジェクトの作成が許可されることになる。内部アプリケーションとの通信は、そのＰＣＲでパイプ書込み権限またはパイプ読出し権限が設定されている場合に限り、許可される。所有権とアクセス権の委譲は、エンティティがパイプの所有者か、あるいはそのＰＣＲでアクセス権委譲が設定されている場合に限り、許可される。他のすべての権限と同様に、別のＡＣＲへ所有権を委譲する当初の所有者は、この装置アプリケーションに対するすべての権限から引き離されることが好ましい。
【０３０７】
ある特定のアプリケーションにつき、１つのみの通信パイプが作成されることが好ましい。第２のパイプを作成し、作成したパイプを接続済みのアプリケーションに接続する試行は、ＳＳＭシステム１０００によって拒絶されることが好ましい。それゆえ、装置内部アプリケーション１０１０の１つと通信パイプとの間に、１対１の関係があることが好ましい。しかしながら、（委譲機構により）複数のＡＣＲが１つの装置内部アプリケーションと通信する場合がある。（種々のアプリケーションに接続された複数パイプの委譲または所有権により、）１つのＡＣＲが、複数の装置アプリケーションと通信する場合がある。通信パイプ間のクロストークをなくすため、種々のパイプを制御するＡＣＲは、全く別個のツリーノードに位置することが好ましい。
【０３０８】
ホストと特定のアプリケーションとのデータ転送は、次のコマンドを使用して行われる。
・書込みパススルー：ホストから装置内部アプリケーションに、非定型データバッファを転送する。
・読出しパススルー：ホストから装置内部アプリケーションに非定型データバッファを転送し、内部処理が完了したら非定型データバッファをホストに戻す。
【０３０９】
書込みパス・スルー・コマンドと読出しパス・スルー・コマンドでは、ホストが通信しようとする相手方の装置内部アプリケーション１００８のＩＤを、パラメータとして提供する。エンティティの権限を検証し、要求される側のアプリケーションにつながるパイプを使用する権限が、要求する側のエンティティ（すなわち、このエンティティが使用しているセッションを運営するＡＣＲ）にある場合、データバッファを解釈し、コマンドを実行する。
【０３１０】
この通信方法により、ホストアプリケーションは、ＳＳＡ＿ＡＣＲセッションチャネルを通じて、内部装置アプリケーションにベンダー固有／独自のコマンドを引き渡すことができる。
【０３１１】
＜ソース・データ・オブジェクト（ＳＤＯ）＞
ＳＤＯは、ＦＳＥと併せて使用できる便利なオブジェクトである。
【０３１２】
ＳＤＯは、汎用容器として、機密情報を安全に記憶する役割を果たす。ＣＥＫオブジェクトと同様に、ＳＤＯはＡＣＲによって所有され、ＡＣＲとの間でアクセス権と所有権を委譲することができる。ＳＤＯは、所定の規制に従って保護され使用されるデータを含み、オプションとして、装置内部アプリケーション１００８へ至るリンクを有する。機密データは、ＳＳＡシステムによって使用されることも解釈されることもなく、オブジェクトの所有者とユーザがこれを使用し、解釈することが好ましい。換言すると、ＳＳＡシステムは、取り扱うデータの情報を認識しない。このため、オブジェクトの中にあるデータの所有者とユーザは、ホストとデータオブジェクトとの間でデータが受け渡しされるときに、ＳＳＡシステムとの橋渡しによって機密情報が失われることをさほど心配せずに済む。ＳＤＯオブジェクトは、ホストシステム（または内部アプリケーション）によって作成され、ＣＥＫを作成する場合と同様に、文字列ＩＤが割り当てられる。作成する場合に、ホストは、名前のほかに、ＳＤＯにリンクするアプリケーションのアプリケーションＩＤと、ＳＳＡによって記憶され、完全性検証が行われ、検索されるデータブロックと、を提供する。
【０３１３】
ＳＤＯは、ＣＥＫと同様に、ＳＳＡセッションの中でのみ作成されることが好ましい。このセッションを開放するために使用されるＡＣＲが、ＳＤＯの所有者となり、ＳＤＯを削除する権利や機密データを読み書きする権利を有するほか、ＳＤＯの所有権やこれにアクセスする権限を別のＡＣＲ（その子ＡＣＲまたは同一ＡＧＰ内のＡＣＲ）に委譲する権利を有する。
【０３１４】
書込み操作と読出し操作は、ＳＤＯの所有者に限定される。書込み操作は、既存のＳＤＯオブジェクトデータを、提示されたデータバッファで上書きする。読出し操作は、ＳＤＯのデータ記録一式を検索する。
【０３１５】
正式なアクセス権限を有する所有者以外のＡＣＲには、ＳＤＯのアクセス操作が許可される。次の操作が定められている。
・ＳＤＯ＿Ｓｅｔ、アプリケーションＩＤの指定：データは、このアプリケーションＩＤを有する内部ＳＳＡアプリケーションによって処理される。アプリケーションは、ＳＤＯとの関連付けによって起動する。オプションとして、アプリケーションがＳＤＯオブジェクトの書込みを行う場合がある。
・ＳＤＯ＿Ｓｅｔ、アプリケーションＩＤの不在：このオプションは無効であり、不正コマンドエラーを促す。Ｓｅｔコマンドには、カードで実行する内部アプリケーションが必要となる。
・ＳＤＯ＿Ｇｅｔ、アプリケーションＩＤの指定：要求は、このアプリケーションＩＤを有する装置内部アプリケーションによって処理される。アプリケーションは、ＳＤＯとの関連付けによって起動する。出力は、指定がなくとも、要求する側に返送される。オプションとして、アプリケーションがＳＤＯオブジェクトの読出しを行う場合がある。
・ＳＤＯ＿Ｇｅｔ、アプリケーションＩＤの不在：このオプションは無効であり、不正コマンドエラーを促す。Ｇｅｔコマンドには、カードで実行する内部アプリケーションが必要となる。
・ＳＤＯ関連の権限：ＡＣＲには、ＳＤＯの所有者になるものと、アクセス権限（Ｓｅｔ、Ｇｅｔ、または両方）を有するのみのものとがある。ＡＣＲには、自身が所有しないＳＤＯに対する自身のアクセス権を、別のＡＣＲへ譲渡することが許可される。ＡＣＡＭ権限を有するＡＣＲには、ＳＤＯの作成とアクセス権の委譲が、明示的に許可される場合がある。
【０３１６】
＜内部ＡＣＲ＞
装置１０にとって外部のエンティティがＡＣＲにログインすることができない点以外は、内部ＡＣＲは、ＰＣＲを有するＡＣＲに類似している。代替的に、これの管理下にあるオブジェクトか、あるいはこのオブジェクトと関連付けするアプリケーションが呼び出されるときに、図４０ＢのＳＳＡ管理部１０２４が、自動的に内部ＡＣＲにログインする。アクセスを試みるエンティティは、カードまたはメモリ装置にとって内部のエンティティであるため、認証の必要はない。ＳＳＡ管理部１０２４は、内部通信を可能にするために、内部ＡＣＲにセッション鍵を渡すだけになる。
【０３１７】
これより、ワン・タイム・パスワード生成とデジタル権利管理という２つの例を引いて、ＦＳＥの能力を例示する。ワン・タイム・パスワード生成の例を説明する前に、二因子認証のテーマを取り上げる。
【０３１８】
＜ＯＴＰ実施形態＞
＜二因子認証（ＤＦＡ）＞
ＤＦＡは、標準のユーザ認証情報（すなわち、ユーザ名およびパスワード）に追加の秘密、すなわち「第２の因子」を加えることにより、ウェブ・サービス・サーバなどへの私的なログインでセキュリティを高めるように意図された認証プロトコルである。この第２の秘密は、典型的に、ユーザが所有する物理的で安全なトークンに記憶されるものである。ユーザは、ログインの過程で、ログイン認証情報の一部として所有の証拠を提供する必要がある。所有の証明には、ワン・タイム・パスワード（ＯＴＰ）がよく使われ、これはセキュアトークンで生成され出力される、１回のログインのみで通用するパスワードである。トークンなしでＯＴＰを計算するのは暗号技術的に不可能であるため、ユーザが正しいＯＴＰを提供できる場合、これをもってトークン所有の十分な証拠とみなされる。ＯＴＰは１回のログインのみで通用し、前のログインから得た古いパスワードは通用しないことになるため、ユーザはログインのときにトークンを所有していなければならない。
【０３１９】
以下の節で説明する製品は、ＳＳＡのセキュリティデータ構造と、一連のＯＴＰで次のパスワードを計算する１つのＦＳＥ設計とを利用しながら、フラッシュ・メモリ・カードで、それぞれ異なるパスワード系列（異なるウェブサイトへのログインに使用）を生成する、複数の「仮想」セキュアトークンを実行するものである。図４１は、このシステムのブロック図を示す。
【０３２０】
システム一式１０５０は、認証サーバ１０５２と、インターネットサーバ１０５４と、トークン１０５８を有するユーザ１０５６と、を備える。最初のステップでは、認証サーバとユーザとの間で、共有秘密を取り決める（シード提供とも称される）。ユーザ１０５６は、秘密またはシードの発行を要求し、これをセキュアトークン１０５８に記憶する。次のステップでは、発行された秘密またはシードを、特定のウェブ・サービス・サーバに結合する。これを果たした時点で、認証に取りかかることができる。ユーザは、ＯＴＰの生成をトークンに指示する。ＯＴＰは、ユーザ名およびパスワードとともに、インターネットサーバ１０５４に送信される。インターネットサーバ１０５４は、認証サーバ１０５２にＯＴＰを転送し、ユーザアイデンティティの検証を依頼する。認証サーバもＯＴＰを生成するが、これはトークンとの共有秘密から生成されるため、トークンから生成されたＯＴＰに一致するはずである。一致が判明する場合、ユーザアイデンティティは検証され、認証サーバがインターネットサーバ１０５４に肯定応答を返すと、ユーザ・ログイン・プロセスは完了することになる。
【０３２１】
ＦＳＥによるＯＴＰ生成には、次のような特徴がある。
・ＯＴＰシードは、安全な状態で（暗号化されて）カードに記憶される。
・パスワード生成アルゴリズムは、カードの内部で実行される。
・装置１０は、複数の仮想トークンをエミュレートすることができ、それぞれの仮想トークンでは異なるシードを記憶し、異なるパスワード生成アルゴリズムを使用することができる。
・認証サーバから装置にシードを移すセキュアプロトコルは、装置１０が提供する。
【０３２２】
図４２は、ＳＳＡのＯＴＰシード提供機能とＯＴＰ生成機能を示すものである。ここで実線の矢印は所有権またはアクセス権を示し、破線の矢印は関連付けまたはリンクを示している。図４２に示すように、ＳＳＡ＿ＦＳＥシステム１１００では、Ｎ個のアプリケーションＡＣＲ１１０６によってそれぞれ管理される１つまたは複数の通信パイプ１１０４を通じて、ソフトウェア・プログラム・コードＦＳＥ＿１１０２にアクセスすることができる。後述する実施形態では、１つのみのＦＳＥソフトウェアアプリケーションを例示しており、各ＦＳＥアプリケーションにつき、１つのみの通信パイプがある。しかしながら、複数のＦＳＥアプリケーションを利用できることが理解されよう。図４２には、１つのみの通信パイプが例示されているが、複数の通信パイプを利用できることは理解されよう。このような変形例は、いずれも可能である。図４０Ａ、４０Ｂ、および４２を参照すると、ＦＳＥ＿１１０２はＯＴＰ提供に用いるアプリケーションであって、図４０Ａの装置内部アプリケーション１０１０の一部をなす場合がある。制御構造（ＡＣＲ＿１１０１、１１０３、１１０６、１１１０）はＳＳＡのセキュリティデータ構造の一部であり、ＳＳＡデータベース１０２６に記憶される。ＩＤＯ＿１１２０、ＳＤＯオブジェクト１１２２などのデータ構造、および、通信パイプ１１０４は、ＳＳＡデータベース１０２６に記憶される。
【０３２３】
図４０Ａおよび図４０Ｂを参照すると、ＡＣＲおよびデータ構造に関わるセキュリティ関連操作（例えば、セッション中のデータ転送、暗号化、復号化、ハッシュ計算等の操作）は、インターフェース１０３２と暗号ライブラリ１０１２の支援を受けて、モジュール１０３０が処理する。ＳＳＭコアＡＰＩ＿１００６は、ホストと受渡しするＡＣＲ（外部ＡＣＲ）が関わる操作と、ホストと受渡ししない内部ＡＣＲが関わる操作を区別しないため、ホストが関わる操作と装置内部アプリケーション１０１０が関わる操作に区別はない。このように、ホスト側エンティティによるアクセスと装置内部アプリケーション１０１０によるアクセスは、同じ制御機構によって制御される。このため、ホスト側アプリケーションと装置内部アプリケーション１０１０とで、データ処理を柔軟に区別することができる。内部アプリケーション１０１０（例えば、図４２のＦＳＥ＿１１０２）は内部ＡＣＲ（例えば、図４２のＡＣＲ＿１１０３）と関連付けされ、これの管理のもとで起動する。
【０３２４】
さらに、重要情報へのアクセス、例えば、ＳＤＯの内容またはそのＳＤＯの内容から検索される情報へのアクセスは、好ましくはＡＣＲやＡＧＰなどのセキュリティデータ構造とＳＳＡのルールとポリシーとによって管理されるため、外部または内部アプリケーションは、ＳＳＡのルールとポリシーとに従う限りにおいてその内容または情報にアクセスすることができる。例えば、２名のユーザが、データを処理するために個々の装置内部アプリケーション１０１０を起動する場合、別々の階層ツリーに位置する内部ＡＣＲを使用して２名のユーザによるアクセスが制御されるため、アプリケーション間のクロストークはない。このように、両ユーザは、データ処理する場合に共通の装置内部アプリケーション１０１０にアクセスすることができ、ＳＤＯの内容または情報の所有者の側では、内容または情報制御の喪失を心配せずに済む。例えば、データを記憶するＳＤＯに対する装置内部アプリケーション１０１０によるアクセスは、別々の階層ツリーに位置するＡＣＲによって制御できるため、アプリケーション間のクロストークはない。この制御方法は、前述した、データに対するアクセスをＳＳＡが制御する方法に似ている。これは、データオブジェクトに記憶されたデータのセキュリティを、内容の所有者とユーザに提供する。
【０３２５】
図４２を参照すると、ＯＴＰ関連ホストアプリケーションに必要なソフトウェア・アプリケーション・コードの一部分を、ＦＳＥ＿１１０２のアプリケーションとしてメモリ装置１０に記憶（メモリカード発行前に予め記憶、またはメモリカード発行後にロード）することは可能である。そのようなコードを実行する場合、ホストは、まずＮ個の認証ＡＣＲ＿１１０６のいずれか１つを通じて認証し、パイプ１１０４にアクセスする必要がある。ここで、Ｎは正の整数である。ホストは、起動しようとするＯＴＰ関連アプリケーションを識別するためのアプリケーションＩＤを提供する必要もある。認証に成功すると、ＯＴＰ関連アプリケーションと関連付けられたパイプ１１０４を通じてそのようなコードにアクセスし、実行することができる。前述したように、パイプ１１０４と、ＯＴＰ関連内部アプリケーションなどの特定アプリケーションとの間には、好ましくは１対１の関係がある。図４２に示すように、複数のＡＣＲ＿１１０６が、共通のパイプ１１０４を制御することがある。１つのＡＣＲで、複数のパイプを制御する場合もある。
【０３２６】
図４２には、オブジェクト１１１４と総称されるセキュア・データ・オブジェクトＳＤＯ１、ＳＤＯ２、およびＳＤＯ３が示されている。セキュア・データ・オブジェクトの各々は、ＯＴＰ生成のためのシードなどのデータを含んでおり、そのシードは有益であるため、暗号化されていることが好ましい。３つのデータオブジェクトとＦＳＥ＿１１０２との間のリンクまたは関連付け１１０８は、これらのオブジェクトの一属性を図示している。いずれか１つのオブジェクトにアクセスするときには、ＳＤＯ属性内のアプリケーションＩＤに一致するＦＳＥ＿１１０２のアプリケーションが起動する。このアプリケーションは、メモリ装置のＣＰＵ＿１２によって実行され、さらなるホストコマンドを受け取る必要はない（図１）。
【０３２７】
図４２を参照すると、ＯＴＰプロセスを制御するためのセキュリティデータ構造（ＡＣＲ＿１１０１、１１０３、１１０６、および１１１０）とそのＰＣＲは、ユーザがＯＴＰプロセスを開始する前に作成済みである。ユーザは、認証サーバＡＣＲ＿１１０６のいずれか１つを通じて、ＯＴＰ装置内部アプリケーション１１０２を起動するためのアクセス権を得る必要がある。ユーザは、Ｎ個のユーザＡＣＲ＿１１１０のいずれか１つを通じて、作成されるＯＴＰに対するアクセス権を得る必要もある。ＳＤＯ＿１１１４は、ＯＴＰのシード提供プロセスで作成することができる。ＩＤＯ＿１１１６は、作成済みで内部ＡＣＲ＿１１０３によって制御されてもよい。内部ＡＣＲ＿１１０３は、作成されたＳＤＯ＿１１１４も制御する。ＳＤＯ＿１１１４にアクセスするときには、図４０ＢのＳＳＡ管理部１０２４が、自動的にＡＣＲ＿１１０３にログインする。内部ＡＣＲ＿１１０３には、ＦＳＥ＿１１０２が関連付けられる。破線１１０８で示すように、ＯＴＰのシード提供プロセスではＳＤＯ＿１１１４にＦＳＥを関連付けられるようになる。関連付けが成立した後、ホストがＳＤＯにアクセスするときには、ホストからさらなる要求がなくとも、関連付け１１０８によってＦＳＥ１１０２が起動する。Ｎ個のＡＣＲ＿１１０６のいずれか１つを通じて通信パイプ１１０４にアクセスするときにも、図４０ＢのＳＳＡ管理部１０２４が、ＡＣＲ＿１１０３に自動的にログインする。いずれの場合でも（ＳＤＯ＿１１１４とパイプ１１０４へのアクセス）、ＳＳＡ管理部はＦＳＥ＿１１０２にセッション番号を渡し、このセッション番号によって内部ＡＣＲ＿１１０３に至るチャネルが識別される。
【０３２８】
ＯＴＰ操作は、２つの段階、すなわち図４３に示すシード提供段階と、図４４に示すＯＴＰ生成段階とを伴う。図４０〜図４２も併せて参照することで、この説明に役立つ。図４３は、シード提供プロセスを示すプロトコル図である。図４３に示すように、ホスト２４などのホストとカードは、様々な動作をとる。ＳＳＭコア１００４を含む図４０Ａおよび４０ＢのＳＳＭシステムは、カード側で様々な動作をとる１エンティティである。図４２に示すＦＳＥ＿１１０２も、カード側で様々な動作をとるエンティティである。
【０３２９】
二因子認証では、ユーザがシードの発行を要求し、発行されたシードはセキュアトークンに記憶される。この例のセキュアトークンは、メモリ装置またはカードである。ユーザは、ＳＳＭシステムにアクセスするため、図４２の認証ＡＣＲ＿１１０６のいずれか１つを認証する（矢印１１２２）。認証に成功したと仮定すると（矢印１１２４）、ユーザはシードを要求する（矢印１１２６）。ホストは、シード要求に署名するためのアプリケーション１１０２を選択して、シード要求に署名する要求をカードへ送信する。起動すべきアプリケーションＩＤをユーザが知らない場合、例えば装置に対する取扱い注意クエリにより、この情報を装置１０から入手することができる。そして、ユーザは、起動するべきアプリケーションのアプリケーションＩＤを入力し、これによりこのアプリケーションに対応する通信パイプも選択される。パス・スルー・コマンドにより、ユーザから、対応する通信パイプを通じて、アプリケーションＩＤで指定されたアプリケーションに、ユーザコマンドが転送される（矢印１１２８）。起動したアプリケーションは、図４２のＩＤＯ＿１１１２などの所定のＩＤＯの公開鍵による署名を要求する。
【０３３０】
ＳＳＭシステムは、ＩＤＯの公開鍵を用いてシード要求に署名し、署名の完了をアプリケーションに通知する（矢印１１３２）。次に、起動アプリケーションはＩＤＯの証明書連鎖を要求する（矢印１１３４）。これに応じて、ＳＳＭシステムは、ＡＣＲ＿１１０３の制御下でＩＤＯの証明書連鎖を提供する。起動アプリケーションは、通信パイプを通じて署名済みシード要求とＩＤＯの証明書連鎖をＳＳＭシステムに提供し、ＳＳＭシステムは、同じものをホストへ転送する（矢印１１３８）。通信パイプにおける署名済みシード要求とＩＤＯ証明書連鎖の送信は、図４０ＡのＳＡＭＭ＿１００８とＳＳＭコア１００４との間で確立するコールバック関数によって行われるが、このコールバック関数については以降で詳しく説明する。
【０３３１】
ホストによって受信されたＩＤＯ証明書連鎖および署名済みシード要求は、図４１に示す認証サーバ１０５２へ送信される。署名済みシード要求の出所が信用できるトークンであることは、カードから提供される証明書連鎖で証明されているため、認証サーバ１０５２には、秘密シードをカードに提供する用意がある。そこで認証サーバ１０５２は、ＩＤＯの公開鍵で暗号化されたシードを、ユーザＡＣＲ情報とともにホストに送信する。このユーザ情報により、Ｎ個のユーザＡＣＲのうち、これから生成するＯＴＰにユーザがアクセスするためのユーザＡＣＲがいずれであるかが明らかになる。ホストは、アプリケーションＩＤを提供することによってＦＳＥ＿１１０２でＯＴＰアプリケーションを起動し、これによりこのアプリケーションに対応する通信パイプも選択され、さらにホストはユーザＡＣＲ情報をＳＳＭシステムへ転送する（矢印１１４０）。暗号化されたシードとユーザＡＣＲ情報は、この後、通信パイプを通じて、選択されたアプリケーションに転送される（矢印１１４２）。起動アプリケーションは、ＩＤＯの秘密鍵を用いてシードを復号化する要求を、ＳＳＭシステムに送信する（矢印１１４４）。ＳＳＭシステムはシードを復号化し、復号化の完了を伝える通知をアプリケーションに送信する（矢印１１４６）。起動アプリケーションは、この後、セキュア・データ・オブジェクトを作成し、そのセキュア・データ・オブジェクトにシードを記憶することを要求する。起動アプリケーションは、ワン・タイム・パスワードを生成するため、そのＳＤＯにＯＴＰアプリケーション（要求するアプリケーションと同じアプリケーションであってもよい）のＩＤを割り振ることも要求する。ＳＳＭシステムは、ＳＤＯ＿１１１４のいずれか１つを作成し、そのＳＤＯの中にシードを記憶し、ＯＴＰアプリケーションのＩＤをＳＤＯに割り振り、完了するとアプリケーションに通知を送信する（矢印１１５０）。アプリケーションは、この後、ホストから提供されたユーザ情報に基づき、ＳＤＯ＿１１１４にアクセスするためのアクセス権を内部ＡＣＲから該当するユーザＡＣＲへ委譲することを、ＳＳＭシステムに要求する（矢印１１５２）。委譲が完了すると、ＳＳＭシステムはアプリケーションに通知する（矢印１１５４）。アプリケーションは、この後、コールバック関数により、ＳＤＯの名前（スロットＩＤ）を通信パイプ経由でＳＳＭシステムに送信する（矢印１１５６）。ＳＳＭシステムは、この後、同じものをホストへ転送する（矢印１１５８）。ホストは、この後、ＳＤＯの名前をユーザＡＣＲに結合し、このため、ユーザはＳＤＯにアクセスできるようになる。
【０３３２】
ここで、図４４のプロトコル図を参照して、ＯＴＰ生成プロセスを説明する。ユーザは、ワン・タイム・パスワードを入手するため、アクセス権があるユーザＡＣＲにログインする（矢印１１７２）。認証に成功した場合を仮定すると、ＳＳＭシステムはホストに通知し、ホストは「ｇｅｔ＿ＳＤＯ」コマンドをＳＳＭへ送信する（矢印１１７４、１１７６）。前述したように、シードを記憶するＳＤＯには、ＯＴＰを生成するアプリケーションが関連付けられている。したがって、これまでのように通信パイプ経由でアプリケーションを選択する代わりに、矢印１１７６のコマンドでアクセスするＳＤＯと、ＯＴＰ生成アプリケーションと、の関連付けによって、ＯＴＰ生成アプリケーションを起動する（矢印１１７８）。ＯＴＰ生成アプリケーションは、この後、ＳＤＯからコンテンツ（すなわち、シード）を読み出すことを、ＳＳＭシステムに要求する。ＳＳＭは、ＳＤＯのコンテンツに含まれる情報を認識せず、ＦＳＥの指示に従ってＳＤＯのデータを処理するだけであることが好ましい。シードが暗号化されている場合、ＦＳＥの指示に従い読出しを行う前に、シードを復号化することが必要となる場合がある。ＳＳＭシステムは、ＳＤＯからシードを読み出し、ＯＴＰ生成アプリケーションにシードを提供する（矢印１１８２）。ＯＴＰ生成アプリケーションは、この後、ＯＴＰを生成し、これをＳＳＭシステムに提供する（矢印１１８４）。ＯＴＰは、ＳＳＭによってホストへ転送され（矢印１１８６）、さらにホストから認証サーバ１０５２にＯＴＰが転送され、二因子認証プロセスは完了する。
【０３３３】
＜コールバック関数＞
図４０ＡのＳＳＭコア＿１００４とＳＡＭＭ＿１００８との間では、汎用コールバック関数が確立する。このような関数には、様々な装置内部アプリケーションと通信パイプを登録することができる。起動した装置内部アプリケーションは、このコールバック関数を使用することにより、アプリケーションへのホストコマンドの引渡しに使用されたものと同じ通信パイプを使用して、処理後のデータをＳＳＭシステムへ引き渡すことができる。
【０３３４】
＜ＤＲＭシステム実施形態＞
図４５は、ＤＲＭシステムを示す機能ブロック図である。このシステムは、通信パイプ１１０４’と、ＦＳＥアプリケーション１１０２’に至るリンク１１０８’を備えるＣＥＫ１１１４’と、ＤＲＭ機能の実行機能を制御する制御構造１１０１’、１１０３’、１１０６’と、を採用している。見て分かるように、セキュリティデータ構造が、認証サーバＡＣＲとユーザＡＣＲの代わりにライセンスサーバＡＣＲ１１０６’と再生ＡＣＲ１１１０’とを含んでおり、ＳＤＯの代わりにＣＥＫ１１１４’を含んでいる点を除いて、図４５のアーキテクチャは図４２のものによく似ている。加えて、ＩＤＯは関係しないので、図４５では省かれている。ＣＥＫ１１１４’は、ライセンス提供プロセスの中で作成することができる。プロトコル図である図４６は、ライセンス提供とコンテンツダウンロードのプロセスを示すものであり、ここではライセンスオブジェクトの中で鍵が提供される。ＯＴＰの実施形態に見られるように、ライセンスの取得を望むユーザはまず、Ｎ個のＡＣＲ１１０６’のいずれか１つとＮ個のＡＣＲ１１１０’のいずれか１つのもとでアクセス権を取得する必要があり、そうすることで、メディア・プレーヤ・ソフトウェア・アプリケーションなどのメディアプレーヤによってコンテンツを提供できるようになる。
【０３３５】
図４６に示すように、ホストは、ライセンスサーバＡＣＲ１１０６’を認証する（矢印１２０２）。認証に成功したと仮定すると（矢印１２０４）、ライセンスサーバは、ライセンスファイルをＣＥＫ（鍵ＩＤと鍵値）とともにホストに提供する。ホストは、カード上のＳＳＭシステムにアプリケーションＩＤを提供することによって、起動すべきアプリケーションも選択する。ホストは、プレーヤ情報（例えば、メディア・プレーヤ・ソフトウェア・アプリケーションの情報）も送信する（矢印１２０６）。このプレーヤ情報により、Ｎ個の再生ＡＣＲ＿１１１０’のうち、プレーヤのアクセス権がある再生ＡＣＲがいずれであるかが明らかになる。ＳＳＭシステムは、選択されたアプリケーションに対応する通信パイプを通じて、ライセンスファイルとＣＥＫをＤＲＭアプリケーションへ転送する（矢印１２０８）。起動したアプリケーションは、この後、ライセンスファイルを非表示パーティションに書き込むことをＳＳＭシステムに要求する（矢印１２１０）。ライセンスファイルがその通りに書き込まれると、ＳＳＭシステムは、アプリケーションに通知する（矢印１２１２）。ＤＲＭアプリケーションは、この後、ＣＥＫオブジェクト１１１４’の作成を要求し、ライセンスファイルからその中に鍵値を記憶する。ＤＲＭアプリケーションは、提供された鍵に関連するライセンスをチェックするＤＲＭアプリケーションのＩＤを、ＣＥＫオブジェクトに割り振ることも要求する（矢印１２１４）。ＳＳＭシステムはこれらのタスクを完了し、その旨をアプリケーションに通知する（矢印１２１６）。アプリケーションは、この後、ホストから送信されたプレーヤ情報に基づいて、ＣＥＫ１１１４’に対するコンテンツの読出しアクセス権をプレーヤがアクセスできる再生ＡＣＲに委譲することを要求する（矢印１２１８）。ＳＳＭシステムは委譲を行い、その旨をアプリケーションに通知する（矢印１２２０）。ライセンスの記憶が完了したことを伝えるメッセージが、アプリケーションから通信パイプを経由しＳＳＭシステムへ送信され、ＳＳＭシステムはこれをライセンスサーバに転送する（矢印１２２２および１２２４）。通信パイプ経由のこのアクションには、コールバック関数を使用する。この通知を受信したライセンスサーバは、この後、提供されたＣＥＫの鍵値によって暗号化されたコンテンツファイルをカードに提供する。暗号化されたコンテンツは、ホストによってカードの公開領域に記憶される。暗号化されたコンテンツファイルの記憶にセキュリティ機能は関与しないため、ＳＳＭシステムは記憶に関与しない。
【０３３６】
図４７は、再生操作を示す。ユーザは、ホストを通じて、該当する再生ＡＣＲ（すなわち、前述した矢印１１５２および１１５４で読出し権を委譲された再生ＡＣＲ）を認証する（矢印１２４２）。認証に成功したと仮定すると（矢印１２４４）、ユーザは、この後、鍵ＩＤと関連付けられたコンテンツの読出し要求を送信する（矢印１２４６）。要求を受信したＳＳＭシステムは、アクセスされているＤＲＭアプリケーションのＩＤがＣＥＫオブジェクトに関連付けられていることに気付き、識別されたＤＲＭアプリケーションを起動する（矢印１２４８）。このＤＲＭアプリケーションは、鍵ＩＤと関連付けられたデータ（すなわち、ライセンス）の読出しを、ＳＳＭシステムに要求する（矢印１２５０）。読出し要求があったデータの情報を認識しないＳＳＭは、ＦＳＥからの要求を処理してデータの読出しプロセスを実行するだけである。ＳＳＭシステムは、非表示パーティションからデータ（すなわち、ライセンス）を読み出し、そのデータをＤＲＭアプリケーションに提供する（矢印１２５２）。ＤＲＭアプリケーションは、この後、データを解釈し、データの中にあるライセンス情報をチェックして、ライセンスが有効かどうかを確認する。ライセンスがなお有効である場合、ＤＲＭアプリケーションは、コンテンツの復号化が許可されることをＳＳＭシステムに知らせる（矢印１２５４）。ＳＳＭシステムは、この後、要求のあったコンテンツをＣＥＫオブジェクトの鍵値を使用して復号化し、復号化されたコンテンツを再生するためにホストに提供する（矢印１２５６）。ライセンスが既に有効でない場合、コンテンツアクセスの要求は拒絶される。
【０３３７】
ライセンスサーバからのライセンスファイルで鍵が提供されない場合の、ライセンス提供とコンテンツのダウンロードは、図４６に示す場合といくぶん異なる。図４８のプロトコル図は、そのような別方式を示す。図４６および図４８で同じステップは、同じ数字で識別されている。それゆえ、ホストとＳＳＭシステムは、まず初めに認証に取り組む（矢印１２０２、１２０４）。ライセンスサーバは、ホストにライセンスファイルと鍵ＩＤを提供するが鍵値は提供せず、ホストはそれらを、起動しようとするＤＲＭアプリケーションのアプリケーションＩＤとともに、ＳＳＭシステムへ転送する。ホストは、プレーヤ情報も送信する（矢印１２０６’）。ＳＳＭシステムは、この後、選択されたアプリケーションに対応する通信パイプを通じて選択されたＤＲＭアプリケーションに、ライセンスファイルと鍵ＩＤを転送する（矢印１２０８）。ＤＲＭアプリケーションは、非表示パーティションへのライセンスファイル書込みを要求する（矢印１２１０）。ライセンスファイルがその通りに書き込まれると、ＳＳＭシステムは、ＤＲＭアプリケーションに通知する（矢印１２１２）。ＤＲＭアプリケーションは、この後、鍵値を生成することと、ＣＥＫオブジェクトを作成することと、そこに鍵値を記憶することと、ＣＥＫオブジェクトにＤＲＭアプリケーションのＩＤを割り振ることと、をＳＳＭシステムに要求する（矢印１２１４’）。要求に応じたＳＳＭシステムは、ＤＲＭアプリケーションへ通知を送信する（矢印１２１６）。ＤＲＭアプリケーションは、この後、ホストからのプレーヤ情報に基づいて、ＣＥＫオブジェクトに対する読出しアクセス権を再生ＡＣＲに委譲することを、ＳＳＭシステムに要求する（矢印１２１８）。これが完了すると、ＳＳＭシステムは、その旨をＤＲＭアプリケーションに通知する（矢印１２２０）。ＤＲＭアプリケーションは、この後、ライセンスが記憶されたことをＳＳＭシステムに通知するが、この通知は、コールバック関数により通信パイプ経由で送信される（矢印１２２２）。この通知は、ＳＳＭシステムによってライセンスサーバに転送される（矢印１２２４）。ライセンスサーバは、この後、鍵ＩＤと関連付けられたコンテンツファイルをＳＳＭシステムへ送信する（矢印１２２６）。ＳＳＭシステムは、鍵ＩＤによって識別された鍵値でコンテンツファイルを暗号化するが、アプリケーションはこれに一切関与しない。暗号化されカードに記憶されたコンテンツは、図４７のプロトコルを用いて再生することができる。
【０３３８】
前述したＯＴＰ実施形態とＤＲＭ実施形態で、ホスト装置は、様々なＯＴＰアプリケーションとＤＲＭアプリケーションを、ＦＳＥ１１０２および１１０２’で選ぶことができる。ユーザは、所望の装置内部アプリケーションを選択し、起動することができる。しかし、ＳＳＭモジュールとＦＳＥとの全体的な関係は常に同じであるため、ユーザとデータの提供者は、ＳＳＭモジュールとの受渡しやＦＳＥを起動する場合に標準のプロトコル群を使用することができる。ユーザと提供者は、独自に開発されたものを含む様々な装置内部アプリケーションの詳細に関わる必要はない。
【０３３９】
さらに、図４６および図４８の場合と同様に、提供プロトコルはいくぶん異なることがある。図４６の場合、ライセンスオブジェクトは鍵値を含むが、図４８の場合は鍵値を含まない。このような違いから、前述したような若干異なるプロトコルが必要となる。しかしながら、図４７における再生は、ライセンス提供のあり方にかかわりなく同じである。したがって、この違いが問題となるのは、通常であればコンテンツの提供者と配布者のみであって、再生段階にしか通常かかわらない消費者には関係ない。それゆえ、このアーキテクチャは、プロトコルをカスタマイズする場合にコンテンツの提供者や配布者に多大な柔軟性を提供しつつ、消費者にとっては扱い易い状態のままである。当然ながら、３つ以上の提供プロトコル群によって提供されるデータから検索される情報でも、第２のプロトコルを用いてアクセスすることができる。
【０３４０】
前述した実施形態から提供される別の利点として、ユーザなどの外部エンティティと装置内部アプリケーションは、いずれもセキュリティデータ構造によって制御されるデータを利用するが、ユーザがアクセスできるものは装置内部アプリケーションによって記憶データから検索される結果のみである。それゆえ、ＯＴＰ実施形態の場合、ホスト装置を通じてユーザが入手できるものはＯＴＰのみであって、シード値は入手することができない。ＤＲＭ実施形態では、ホスト装置を通じてユーザが入手できるものは再生されたコンテンツのみであって、ライセンスファイルまたは暗号鍵のいずれにもアクセスすることができない。このため、セキュリティを損なうことなく消費者の便宜を図ることができる。
【０３４１】
ＤＲＭの一実施形態では、装置内部アプリケーションもホストも暗号鍵にアクセスせず、セキュリティデータ構造のみがこれにアクセスする。他の実施形態では、セキュリティデータ構造以外のエンティティも暗号鍵にアクセスすることができる。鍵が装置内部アプリケーションによって生成され、セキュリティデータ構造によって制御される場合もある。
【０３４２】
装置内部アプリケーションと情報（例えば、ＯＴＰや再生コンテンツ）へのアクセスは、同じセキュリティデータ構造によって制御される。これは、制御システムの複雑さとコストを抑える。
【０３４３】
装置内部アプリケーションに対するアクセスを制御する内部ＡＣＲから、装置内部アプリケーションを起動することによって得られる情報に対するホストのアクセスを制御するＡＣＲに、アクセス権を委譲する能力を提供することにより、前述した特徴および機能が実現可能となる。
【０３４４】
＜アプリケーション別失効制度＞
セキュリティデータ構造のアクセス制御プロトコルは、装置内部アプリケーションの起動時に修正することもできる。例えば、証明書失効プロトコルは、ＣＲＬを使用する標準のプロトコルまたは独自のプロトコルのいずれでもよい。それゆえ、ＦＳＥを起動することにより、標準のＣＲＬ失効プロトコルをＦＳＥ独自プロトコルに差し替えることができる。
【０３４５】
ＣＲＬ失効制度をサポートすることに加えて、ＳＳＡは、装置内部アプリケーションとＣＡあるいはその他の取消機関との間の私的通信チャネルを通じて、装置に常駐する内部アプリケーションにホストを無効にさせることができる。内部アプリケーション独自の失効制度は、ホスト−アプリケーションの関係に限定される。
【０３４６】
アプリケーション別失効制度が構成される場合、ＳＳＡシステムは、ＣＲＬ（提供される場合）を拒絶することになり、そうでない場合には証明書と独自のアプリケーションデータ（アプリケーション別通信パイプを通じて提供済みのデータ）を用いて所与の証明書が失効済みか否かを判定する。
【０３４７】
前述したように、ＡＣＲでは、失効値を指定することによって３つの失効制度（失効制度なし、標準ＣＲＬ制度、アプリケーション別失効制度）のどれを採用するかを指定する。アプリケーション別失効制度を選定する場合、その失効制度を担当する内部アプリケーションＩＤもＡＣＲで指定し、ＣＥＴ／ＡＰＰ＿ＩＤフィールドの値は失効制度を担当する内部アプリケーションＩＤに対応することになる。装置を認証する場合、ＳＳＡシステムは、内部アプリケーション独自の制度に準拠する。
【０３４８】
１組のプロトコルを別のものに差し替える代わりに、装置内部アプリケーションを起動する場合、ＳＳＡによって既に施行されているアクセス制御に、追加のアクセス条件を設けることもできる。例えば、ＣＥＫの鍵値に対するアクセス権を、ＦＳＥで精査することができる。鍵値のアクセス権がＡＣＲにあると判定したＳＳＡシステムは、ＦＳＥと相談のうえでアクセスを許諾する。これは、コンテンツへのアクセスを制御する場合にコンテンツの所有者に多大な柔軟性を提供する。
【０３４９】
これまで様々な実施形態を参照して本発明を説明してきたが、本発明の範囲から逸脱することなく変更や修正を施すことができ、本発明の範囲が専ら添付の特許請求の範囲とその同等物とによって定まるものであることは理解されよう。
【図１】
2013514587.tif 000004
【図２】
2013514587.tif 000005
【図３】
2013514587.tif 000006
【図４】
2013514587.tif 000007
【図５】
2013514587.tif 000008
【図６】
2013514587.tif 000009
【図７】
2013514587.tif 000010
【図８Ａ】
2013514587.tif 000011
【図８Ｂ】
2013514587.tif 000012
【図９】
2013514587.tif 000013
【図１０】
2013514587.tif 000014
【図１１】
2013514587.tif 000015
【図１２】
2013514587.tif 000016
【図１３】
2013514587.tif 000017
【図１４】
2013514587.tif 000018
【図１５】
2013514587.tif 000019
【図１６】
2013514587.tif 000020
【図１７Ａ】
2013514587.tif 000021
【図１７Ｂ】
2013514587.tif 000022
【図１８】
2013514587.tif 000023
【図１９】
2013514587.tif 000024
【図２０】
2013514587.tif 000025
【図２１】
2013514587.tif 000026
【図２２】
2013514587.tif 000027
【図２３】
2013514587.tif 000028
【図２３Ａ】
2013514587.tif 000029
【図２３Ｂ】
2013514587.tif 000030
【図２４】
2013514587.tif 000031
【図２５】
2013514587.tif 000032
【図２６】
2013514587.tif 000033
【図２７】
2013514587.tif 000034
【図２８】
2013514587.tif 000035
【図２９】
2013514587.tif 000036
【図３０】
2013514587.tif 000037
【図３１】
2013514587.tif 000038
【図３２】
2013514587.tif 000039
【図３３】
2013514587.tif 000040
【図３４】
2013514587.tif 000041
【図３５】
2013514587.tif 000042
【図３６】
2013514587.tif 000043
【図３７】
2013514587.tif 000044
【図３８】
2013514587.tif 000045
【図３９】
2013514587.tif 000046
【図４０Ａ】
2013514587.tif 000047
【図４０Ｂ】
2013514587.tif 000048
【図４１】
2013514587.tif 000049
【図４２】
2013514587.tif 000050
【図４３】
2013514587.tif 000051
【図４４】
2013514587.tif 000052
【図４５】
2013514587.tif 000053
【図４６】
2013514587.tif 000054
【図４７】
2013514587.tif 000055
【図４８】
2013514587.tif 000056
【図４９】
2013514587.tif 000057
【図５０】
2013514587.tif 000058
【国際調査報告】
2013514587.tif 000059
2013514587.tif 000060