JP2013514587A - 証明書失効リストを用いたコンテンツ管理方法 - Google Patents

証明書失効リストを用いたコンテンツ管理方法 Download PDF

Info

Publication number
JP2013514587A
JP2013514587A JP2012544547A JP2012544547A JP2013514587A JP 2013514587 A JP2013514587 A JP 2013514587A JP 2012544547 A JP2012544547 A JP 2012544547A JP 2012544547 A JP2012544547 A JP 2012544547A JP 2013514587 A JP2013514587 A JP 2013514587A
Authority
JP
Japan
Prior art keywords
certificate
host
acr
revocation list
key
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
JP2012544547A
Other languages
English (en)
Inventor
ローテム セラー
ロン バーズライ
ミシェル ホルツマン
アブラハム シュムエル
ジェイソン ティー． リン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SanDisk Technologies LLC
Original Assignee
SanDisk Technologies LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by SanDisk Technologies LLC filed Critical SanDisk Technologies LLC
Publication of JP2013514587A publication Critical patent/JP2013514587A/ja
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G06F21/445—Program or device authentication by mutual authentication, e.g. between devices or programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/78—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
    • G06F21/80—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data in storage media based on magnetic or optical technology, e.g. disks with sectors
    • G06F21/805—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data in storage media based on magnetic or optical technology, e.g. disks with sectors using a security table for the storage sub-system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H04L9/3228—One-time or temporary data, i.e. information which is sent for every authentication or authorization, e.g. one-time-password, one-time-token or one-time-key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3265—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate chains, trees or paths; Hierarchical trust model
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H04L9/3273—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response for mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2129—Authenticate client device independently of the user
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60—Digital content management, e.g. content distribution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Storage Device Security (AREA)

Abstract

ホスト装置は、メモリ装置自体がリストを入手する必要がないように、ホスト証明書および関係証明書失効リストの両方を認証のためにメモリ装置に提示する。証明書失効リストの処理と証明書識別情報の検索は、メモリ装置によって同時に実施されてよい。ホスト装置からメモリ装置への認証を行う証明書失効リストは、メモリ装置がホスト証明書を受信する前にキャッシュされて認められる。
【選択図】図５０

Description

（関連出願の相互参照）
本出願は、２００６年１１月６日に出願された米国特許出願第１１／５５７，００６号の一部継続出願であり、参照により本明細書に組み込まれ、２００６年７月７日に出願された米国仮特許出願第６０／８１９，５０７号の利益を主張するものである。
本出願は２００５年１２月２０日に出願された米国特許出願第１１／３１３，８７０号に関し、同出願は２００４年１２月２１日に出願された米国仮特許出願第６０／６３８，８０４号の利益を主張するものである。本出願はさらに２００５年１２月２０日に出願された米国特許出願第１１／３１４，４１１号に関する。本出願はさらに２００５年１２月２０日に出願された米国特許出願第１１／３１４，４１０号に関する。本出願はさらに２００５年１２月２０日に出願された米国特許出願第１１／３１３，５３６号に関する。本出願はさらに２００５年１２月２０日に出願された米国特許出願第１１／３１３，５３８号に関する。本出願はさらに２００５年１２月２０日に出願された米国特許出願第１１／３１４，０５５号に関する。本出願はさらに２００５年１２月２０日に出願された米国特許出願第１１／３１４，０５２号に関する。本出願はさらに２００５年１２月２０日に出願された米国特許出願第１１／３１４，０５３号に関する。
本出願は、２００６年１１月６日に出願された「Ｃｏｎｔｅｎｔ Ｃｏｎｔｒｏｌ Ｍｅｔｈｏｄ Ｕｓｉｎｇ Ｃｅｒｔｉｆｉｃａｔｅ Ｃｈａｉｎｓ」と題するＨｏｌｔｚｍａｎらの米国特許出願第１１／５５７，０２８号と、２００６年１１月６日に出願された「Ｃｏｎｔｅｎｔ Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍ Ｕｓｉｎｇ Ｃｅｒｔｉｆｉｃａｔｅ Ｃｈａｉｎｓ」と題するＨｏｌｔｚｍａｎらの米国特許出願第１１／５５７，０１０号と、２００６年１１月６日に出願された「Ｃｏｎｔｅｎｔ Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍ Ｕｓｉｎｇ Ｃｅｒｔｉｆｉｃａｔｅ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔｓ」と題するＨｏｌｔｚｍａｎらの米国特許出願第１１／５５７，０２６号と、２００６年１１月６日に出願された「Ｃｏｎｔｅｎｔ Ｃｏｎｔｒｏｌ Ｍｅｔｈｏｄ Ｕｓｉｎｇ Ｖｅｒｓａｔｉｌｅ Ｃｏｎｔｒｏｌ Ｓｔｒｕｃｔｕｒｅ」と題するＨｏｌｔｚｍａｎらの米国特許出願第１１／５５７，０４９号と、２００６年１１月６日に出願された「Ｃｏｎｔｅｎｔ Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍ Ｕｓｉｎｇ Ｖｅｒｓａｔｉｌｅ Ｃｏｎｔｒｏｌ Ｓｔｒｕｃｔｕｒｅ」と題するＨｏｌｔｚｍａｎらの米国特許出願第１１／５５７，０５６号と、２００６年１１月６日に出願された「Ｍｅｔｈｏｄ ｆｏｒ Ｃｏｎｔｒｏｌｌｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｕｐｐｌｉｅｄ Ｆｒｏｍ Ｍｅｍｏｒｙ Ｄｅｖｉｃｅ」と題するＨｏｌｔｚｍａｎらの米国特許出願第１１／５５７，０５２号と、２００６年１１月６日に出願された「Ｓｙｓｔｅｍ ｆｏｒ Ｃｏｎｔｒｏｌｌｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｕｐｐｌｉｅｄ Ｆｒｏｍ Ｍｅｍｏｒｙ Ｄｅｖｉｃｅ」と題するＨｏｌｔｚｍａｎらの米国特許出願第１１／５５７，０５１号と、２００６年１１月６日に出願された「Ｃｏｎｔｒｏｌ Ｍｅｔｈｏｄ Ｕｓｉｎｇ Ｉｄｅｎｔｉｔｙ Ｏｂｊｅｃｔｓ」と題するＨｏｌｔｚｍａｎらの米国特許出願第１１／５５７，０４１号と、２００６年１１月６日に出願された「Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍ Ｕｓｉｎｇ Ｉｄｅｎｔｉｔｙ Ｏｂｊｅｃｔｓ」と題するＨｏｌｔｚｍａｎらの米国特許出願第１１／５５７，０３９号と、に関する。
前述の出願は、あたかも本明細書で完全に説明されるかのように、その内容全体が参照により本明細書に組み込まれる。
本発明は、一般にメモリシステムに関し、特に汎用的なコンテンツ管理機能を備えるメモリシステムに関する。
フラッシュ・メモリ・カードなどの記憶装置は、写真などのデジタルコンテンツを記憶するのに最適な記憶媒体となっている。また、フラッシュ・メモリ・カードは他の種類の媒体コンテンツの配信に使用される場合もある。さらに、コンピュータ、デジタルカメラ、携帯電話、携帯端末（ＰＤＡ）、およびＭＰ３プレーヤなどのメディアプレーヤなど、ホスト装置の多様化は、フラッシュ・メモリ・カード内に記憶される媒体コンテンツを提供する可能性を今や有している。それゆえ、フラッシュ・メモリ・カードは、他の種類の携帯記憶装置と同様に、デジタルコンテンツを配信する、幅広く使用される媒体となる可能性が大きい。
デジタルコンテンツのオーナーおよび配信業者にとって主要な関心事の１つは、インターネットなどのネットワークからのダウンロードを通じて、あるいは記憶装置上のコンテンツの配信を通じてコンテンツが配信された後、認可取得者のみがコンテンツへのアクセスを許可されるべきであるということである。不正アクセスを回避する方法の１つは、コンテンツへのアクセスが当事者に許諾される前に当事者のアイデンティティを確認するシステムを採用することである。公開鍵基盤（ＰＫＩ）などのシステムがこの目的で開発されている。ＰＫＩシステムでは、証明機関（ＣＡ）として知られる信頼された機関が、個人または組織のアイデンティティを確認する証明書を発行する。アイデンティティの証拠を確認したい組織および個人などの当事者は、自身のアイデンティティを確認する十分な証拠を証明機関に登録することができる。当事者のアイデンティティがＣＡに確認されると、ＣＡは証明書をこうした当事者に発行することになる。証明書は、典型的に、証明書を発行したＣＡの名称、証明書の発行の対象となった当事者の名称、当事者の公開鍵、およびＣＡの秘密鍵により署名された（典型的に公開鍵のダイジェストを暗号化することにより）当事者の公開鍵を含む。
ＣＡの秘密鍵および公開鍵は、公開鍵を用いて暗号化されたデータが秘密鍵によって復号化されるように関係付けられ、逆も同様である。それゆえ、秘密鍵および公開鍵は鍵対を形成する。暗号化技術に関する秘密鍵および公開鍵対の説明は、ＲＳＡセキュリティ（ＲＳＡ Ｓｅｃｕｒｉｔｙ Ｉｎｃ．）の２００２年６月１４日付、「ＰＫＣＳ＃１ ｖ２．１：ＲＳＡ Ｃｒｙｐｔｏｇｒａｐｈｙ Ｓｔａｎｄａｒｄ」に記載されている。ＣＡの公開鍵は一般に利用可能となっている。したがって、一当事者が別の当事者によって提示された証明書を真正かどうか検証したい場合、検証する当事者は、復号化アルゴリズムを用いて証明書内の公開鍵の暗号化されたダイジェストを復号化するために、ＣＡの公開鍵を使用するだけでよい。また、復号化アルゴリズムは、典型的に、証明書の中でも識別される。証明書の中の公開鍵の復号化されたダイジェストが、証明書の中の暗号化されていない公開鍵のダイジェストに一致する場合、これは、証明書の中の公開鍵がＣＡ内の信用とＣＡの公開鍵の信頼性とに基づいて改ざんされておらず真正であることを証明している。
ある当事者のアイデンティティを検証するために、検証する側は、典型的に、質問（例えば、乱数）を送信し、相手方には自身の証明書と質問に対する回答（すなわち、相手方の秘密鍵で暗号化された乱数）の送信を求める。回答と証明書が受信されると、検証する側はまず、証明書の公開鍵が真正かどうかを前述したプロセスによって検証する。公開鍵が真正であると検証された場合、検証する側は証明書内の中にある公開鍵を使用して回答を復号化し、その結果を当初送信した乱数と比較することができる。それらが一致する場合は相手方が正しい秘密鍵を所持していることを意味し、これをもって相手方は自身のアイデンティティを証明したことになる。証明書の中の公開鍵が真正でないか、あるいは復号化された回答が質問に一致しないと、認証は失敗に終わる。それゆえ、自身のアイデンティティを証明することを望む当事者は、証明書および対応する秘密鍵の両方を所持する必要がある。
前述したメカニズムにより、ことによると互いを信用できない両方の当事者でも、前述したプロセスを用いて、相手方の証明書の中にある相手方の公開鍵を検証することよって信用を成立させることができる。国際電気通信連合（ＩＴＵ）電気通信標準化部門（ＩＴＵ−Ｔ）の勧告Ｘ．５０９は証明書の枠組みを定める規格書である。証明書とその運用に関する詳しい情報はこの規格書で確認することができる。
運営管理と大規模組織の便宜を図るため、ルートＣＡ（root CA）として知られる上位ＣＡが、証明書発行の責務をいくつかの下位機関に委譲するとよい場合がある。例えば、２レベル階層において、最上位のルートＣＡは下位機関の公開鍵が真正であることを証明するための下位ＣＡに証明書を発行する。そして、下位ＣＡは前述した登録プロセスを通じて当事者に証明書を発行する。検証プロセスは証明書連鎖の頂点から始まる。検証する側はまず、ルートＣＡの公開鍵（真正と判明）を使用して、下位ＣＡの公開鍵の真性を検証する。下位ＣＡの公開鍵の真性が検証されると、下位ＣＡから証明書の発行を受けた当事者の公開鍵の真性を、下位ＣＡの検証済み公開鍵を使用して検証することができる。このように、ルートＣＡと下位ＣＡとによって発行される証明書により、アイデンティティ検証の対象となる当事者の２つの証明書からなる連鎖が形成される。
当然ながら、証明書階層のレベルは２レベルを超えることもあり、ルートＣＡを除く下位レベルの各ＣＡはその権限を上位ＣＡから受け取り、上位ＣＡによって発行された公開鍵を含む証明書を所持する。したがって、相手方の公開鍵の真性を検証するには、ルートＣＡに至る経路、すなわち証明書の連鎖をたどる必要がある。換言すると、アイデンティティを立証するには、アイデンティティを証明する必要がある側が、自身の証明書からルートＣＡ証明書にかけて一連の証明書を提示する必要がある可能性がある。
証明書は一定の有効期間にわたって発行される。しかしながら、名称の変更、証明書発行元との関係の変化、対応する秘密鍵の侵害または侵害の疑いなどにより、有効期間の満了に先立ち証明書が無効になることもある。このような場合には証明機関（ＣＡ）が証明書を失効させる必要がある。証明機関は、失効させた全証明書の通し番号が記載された証明書失効リストを定期的に公表する。従来の証明書検証方法では、認証する側のエンティティ（entity）には、証明書失効リストを所持するか、あるいは証明機関（ＣＡ）から証明書失効リストを取り寄せることができ、認証のために提示される証明書の通し番号をリストに照らしてチェックして、提示された証明書が失効済みかどうかを判断することが求められる。認証する側のエンティティがメモリまたは記憶装置である場合、装置そのものを使用して証明機関から証明書失効リストを取り寄せることはしていない。その結果、認証のために提示される証明書を、メモリまたは記憶装置で検証することはできない。したがって、証明書失効リストを入手せずとも、メモリまたは記憶装置で証明書を検証できる改良されたシステムの提供が望まれる。
メモリ装置は、それだけで証明書失効リストを入手するために使用されてはいない。したがって、ホスト装置が証明書に関する証明書失効リストを併せて提示することなく認証のために記憶装置に証明書を提示する場合、ホスト装置から提示される証明書が関連証明書失効リストに載っているか否かを、記憶装置は確認できないことになる。そのため、本発明の一実施形態は、証明書、さらには証明書に関する証明書失効リストに加えて、ホスト装置が提示するシステムによってこの問題を回避しうるとの認識に基づくものである。こうして、記憶装置は、ホスト装置から送信される証明書失効リストの中の証明書の通し番号など、証明書の識別情報を照合することによって証明書が真性であることを検証することができる。
証明書失効リストが、その通し番号などの失効した証明書についての多くの識別情報を含む場合、リストはきわめて冗長になる可能性がある。それゆえ、別の実施形態では、証明書失効リストの一部分が装置によって受信され、装置はその一部分を順番に処理する。また、装置は、処理および検索が同時に行われる場合にリスト上のホストから受信された証明書についての、リファレンスまたは識別情報を検索する。処理および検索は同時に行われるので、証明書を検証する処理は効率化が進む。
前述のように、記憶装置は証明書失効リストを入手するために使用されてこなかったが、ホスト装置は証明書失効リストを入手するために使用されてきた。それゆえ、別の実施形態では、ホスト装置はホスト装置の認証のために証明書とともに証明書失効リストを提示する必要があるが、記憶装置、すなわちメモリ装置に対してはそのような必要性がなく、証明書を提示するだけで済むことになる。その結果、メモリ装置証明書を検証する適正な証明書失効リストを入手できるかどうかは、ホスト装置次第である。
証明書失効リストを自由に入手するためにホスト装置を利用することが可能であるものの、記憶装置の中の暗号化コンテンツにアクセスしたいときなど、その都度頻繁にそうせねばならないのは、多くの消費者にとって煩わしい可能性がある。それゆえ、別の実施形態では、少なくとも１つの証明書失効リストがメモリの共有領域に記憶され、メモリはユーザまたは消費者がアクセスしたい被保護データまたはコンテンツも記憶する。こうすると、消費者またはユーザは、メモリに記憶されたコンテンツにアクセスしたいときに、その都度証明書失効リストを証明機関から入手する必要がなくなる。代わりに、消費者またはユーザは、メモリの共有領域に記憶された少なくとも１つの証明書失効リストを検索してから、この証明書失効リストを認証とコンテンツへのアクセスのためにメモリに提示するだけでよい。多くの種類のメモリの共有領域は、典型的に、ホスト装置によって管理され、メモリそのものによっては管理されない。
別の実施形態では、不揮発性記憶装置は、既に装置に記憶された証明書失効リストを利用することができ、ホストが証明書失効リストを装置から検索し、検索したリストを装置に再び提示する必要はない。
本明細書において言及するすべての特許、特許出願、論文、書籍、仕様書、規格書、その他の出版物、文書、およびその他の事物は、あらゆる目的でその全体が参照により本明細書に援用されている。援用される出版物、文書、または事物のいずれかと本明細書の本文章との間の用語の定義および用法に不一致や対立がある場合、本明細書における用語の定義および用法が優先するものとする。
本発明を示すために有用である、ホスト装置と通信するメモリシステムのブロック図である。
本発明の種々の実施形態を例示するのに有用である、特定パーティションと暗号化ファイルへのアクセスをアクセスポリシーと認証手続きとによって制御する、メモリの種々のパーティションと種々のパーティションに記憶される非暗号化ファイルおよび暗号化ファイルとの概略図である。
メモリ内の種々のパーティションを示すメモリの概略図である。
本発明の種々の実施形態を例示するのに有用である、パーティション内のいくつかのファイルが暗号化される図３に示すメモリの種々のパーティションのファイル・ロケーション・テーブルの概略図である。
本発明の種々の実施形態を説明するのに有用なアクセス制御記録グループにおける、アクセス制御記録および関連鍵リファレンスの概略図である。
本発明の種々の実施形態を説明するのに有用なアクセス制御記録グループおよびアクセス制御記録によって形成されるツリー構造の概略図である。
ツリーの形成のプロセスを説明するためのアクセス制御記録グループの３つの階層ツリーを示すツリーの概略図である。
ホスト装置と、システムアクセス制御記録を作成して用いるメモリカードなどのメモリ装置とによって実行されるプロセスを示すフローチャートである。 ホスト装置と、システムアクセス制御記録を作成して用いるメモリカードなどのメモリ装置とによって実行されるプロセスを示すフローチャートである。
種々の実施形態を説明するのに有用なアクセス制御記録グループを作成するためにシステムアクセス制御記録を用いるプロセスを示すフローチャートである。
アクセス制御記録を作成するプロセスを示すフローチャートである。
階層ツリーの特定の用途を例示するのに有用な２つのアクセス制御記録グループの概略図である。
特定の権利を委譲するプロセスを示すフローチャートである。
図１２の委譲プロセスを例示するための、アクセス制御記録グループおよびアクセス制御記録の概略図である。
暗号化および／または復号化のために鍵を作成するプロセスを示すフローチャートである。
アクセス制御記録に従ってアクセス権および／またはデータアクセス権限を削除するプロセスを示すフローチャートである。
アクセス権および／またはアクセス権限が削除されたか、あるいは期限切れになった場合にアクセスを要求するプロセスを示すフローチャートである。
本発明の様々な実施形態の例示に有用である、認証ルール構造と暗号鍵アクセス許諾ポリシー構成を示す概略図である。 本発明の様々な実施形態の例示に有用である、認証ルール構造と暗号鍵アクセス許諾ポリシー構成を示す概略図である。
ポリシーに従って被保護情報へのアクセスを制御する代替的な方法を示すデータベース構造のブロック図である。
パスワードを用いた認証プロセスを示すフローチャートである。
複数のホスト証明書連鎖を示す図である。
複数の装置証明書連鎖を示す図である。
一方向および相互認証方式のプロセスを示すプロトコル図である。 一方向および相互認証方式のプロセスを示すプロトコル図である。
本発明の一実施形態を例示するのに有用である、証明書連鎖の図である。
本発明の別の実施形態を例示するための、メモリ装置に最終証明書を送信する場合のホストによって送信される証明書バッファに先行する制御セクタ内の情報を示す表であり、この証明書が証明書連鎖における最終証明書であることを伝える標示を示す。
メモリカードがホスト装置を認証する認証方式のための、カードとホストのプロセスのそれぞれを示すフローチャートである。 メモリカードがホスト装置を認証する認証方式のための、カードとホストのプロセスのそれぞれを示すフローチャートである。
ホスト装置がメモリカードを認証する認証方式のための、カードとホストのプロセスのそれぞれを示すフローチャートである。 ホスト装置がメモリカードを認証する認証方式のための、カードとホストのプロセスのそれぞれを示すフローチャートである。
本発明の別の実施形態を例示するための、メモリ装置に記憶された証明書失効リストがホスト装置によって検索される場合に、ホスト装置とメモリ装置によってそれぞれ実行されるプロセスを示すフローチャートである。 本発明の別の実施形態を例示するための、メモリ装置に記憶された証明書失効リストがホスト装置によって検索される場合に、ホスト装置とメモリ装置によってそれぞれ実行されるプロセスを示すフローチャートである。
本発明のさらに別の実施形態を示すための、証明書失効リスト内のフィールドを示す証明書失効リストの図である。
証明書失効リストを用いて証明書を検証する、カードとホストのプロセスのそれぞれを示すフローチャートである。 証明書失効リストを用いて証明書を検証する、カードとホストのプロセスのそれぞれを示すフローチャートである。
カードがホストに送信されるデータに署名し、かつホストからのデータを復号化するカードプロセスを示すフローチャートである。
カードがホストに送信されるデータに署名する場合のホストプロセスを示すフローチャートである。
ホストがメモリカードに暗号化データを送信する場合のホストプロセスを示すフローチャートである。
一般情報および取扱い注意情報のクエリのプロセスをそれぞれ示すフローチャートである。 一般情報および取扱い注意情報のクエリのプロセスをそれぞれ示すフローチャートである。
本発明の実施形態を例示するための、ホスト装置に接続されたメモリ装置（フラッシュ・メモリ・カードなど）におけるシステムアーキテクチャの機能ブロック図である。
図４０ＡのＳＳＭコアの内部ソフトウェアモジュールの機能ブロック図である。
ワン・タイム・パスワードを生成するシステムのブロック図である。
ワン・タイム・パスワード（ＯＴＰ）シード提供およびＯＴＰ生成を示す機能ブロック図である。
シード提供段階を説明するプロトコル図である。
ワン・タイム・パスワード生成段階を示すプロトコル図である。
ＤＲＭシステムを説明する機能ブロック図である。
ライセンスオブジェクトの中で鍵が提供される場合のライセンス提供およびコンテンツダウンロードのプロセスを示すプロトコル図である。
再生操作のプロセスを示すプロトコル図である。
ライセンスオブジェクトの中で鍵が提供されない場合のライセンス提供およびコンテンツダウンロードのプロセスを示すプロトコル図である。
証明書失効リストを用いてアクセス制御記録を構成する例示的なステップを示すフローチャートである。
認証中に不揮発性記憶装置にキャッシュされ、あるいは装置に提供された証明書失効リストを用いて不揮発性記憶装置を認証する例示的なステップを示すフローチャートである。
図は本発明の態様の様々な実施形態における特徴を説明している。説明を簡単にするために、本出願では同一の構成要素を同じ数字で表示する。
本発明の様々な態様が実施されうる場合のメモリシステムの例を、図１のブロック図によって説明する。図１に示すように、メモリシステム１０は、中央処理装置（ＣＰＵ）１２、バッファ管理ユニット（ＢＭＵ）１４、ホスト・インターフェース・モジュール（ＨＩＭ）１６およびフラッシュ・インターフェース・モジュール（ＦＩＭ）１８、フラッシュメモリ２０および周辺アクセスモジュール（ＰＡＭ）２２を含む。メモリシステム１０は、ホスト・インターフェース・バス２６およびポート２６ａを通じてホスト装置２４と通信する。フラッシュメモリ２０は、ＮＡＮＤタイプのものであってもよく、ホスト装置２４に対してデータ記憶を提供する。ホスト装置２４は、デジタルカメラ、パーソナルコンピュータ、携帯端末（ＰＤＡ）、ＭＰ３プレーヤなどのデジタルメディアプレーヤ、携帯電話、セット・トップ・ボックス、あるいはその他のデジタル装置またはデジタル家電であってもよい。また、ＣＰＵ１２のソフトウェアコードは、フラッシュメモリ２０に記憶されてもよい。ＦＩＭ１８は、フラッシュ・インターフェース・バス２８およびポート２８ａを通じてフラッシュメモリ２０に接続する。ＨＩＭ１６はホスト装置への接続に適している。周辺アクセスモジュール２２は、ＣＰＵ１２と通信するＦＩＭ、ＨＩＭ、およびＢＭＵなどの適切なコントローラモジュールを選択する。一実施形態では、点線枠内のシステム１０の構成要素のすべては、メモリカードまたはスティック１０’などの単一ユニットに入れられてもよく、好ましくはカプセル化される。メモリシステム１０はホスト装置２４に取外し可能に接続され、したがって、システム１０内のコンテンツは多くの異なるホスト装置の各々によってアクセスされうる。
以下の説明では、メモリシステム１０は、さらに、メモリ装置１０、あるいは簡単にメモリ装置または装置と称される。本発明は本明細書においてフラッシュメモリを参照して説明されるが、本発明は、磁気ディスク、光学ＣＤ、ならびにその他あらゆるタイプの書換え可能な不揮発性メモリシステムなど、他のタイプのメモリにも適用されてもよい。
バッファ管理ユニット１４は、ホスト・ダイレクト・メモリ・アクセス（ＨＤＭＡ）３２、フラッシュ・ダイレクト・メモリ・アクセス（ＦＤＭＡ）３４、アービタ（an arbiter）３６、バッファ・ランダム・アクセス・メモリ（ＢＲＡＭ）３８、および暗号エンジン４０を含む。アービタ３６は共有バスアービタであり、これにより、唯一のマスタまたはイニシエータ（これはＨＤＭＡ３２、ＦＤＭＡ３４、またはＣＰＵ１２）がいつでもアクティブとなることができるとともに、スレーブまたはターゲットがＢＲＡＭ３８となる。アービタは、ＢＲＡＭ３８に適切なイニシエータ要求を送信することに関与する。ＨＤＭＡ３２およびＦＤＭＡ３４は、ＨＩＭ１６、ＦＩＭ１８、およびＢＲＡＭ３８またはＣＰＵランダム・アクセス・メモリ（ＣＰＵ＿ＲＡＭ）１２ａの間で輸送されるデータに関与する。ＨＤＭＡ３２およびＦＤＭＡ３４の動作は、従来通りであり、本明細書において詳しく説明する必要はない。ＢＲＡＭ３８は、ホスト装置２４とフラッシュメモリ２０の間で伝達されるデータを記憶するために使用される。ＨＤＭＡ３２およびＦＤＭＡ３４は、ＨＩＭ１６／ＦＩＭ１８とＢＲＡＭ３８またはＣＰＵ＿ＲＡＭ１２ａとの間でデータを転送しセクタ完了を示すことに関与する。
一実施形態では、メモリシステム１０は、暗号化および／または復号化に使用される鍵値を生成し、この値は、ホスト装置２４などの外部装置に実質的にアクセス可能でないことが好ましい。あるいは、また、鍵値はライセンスサーバなどによってシステム１０の外部で生成されてシステム１０に送信されてもよい。鍵値の生成方法に関わらず、鍵値がシステム１０内に記憶された時点で、認証エンティティのみが鍵値にアクセスしうるようになる。しかしながら、ホスト装置はメモリシステム１０にデータをファイル形式で読み書きするので、暗号化および復号化は、典型的に、ファイルごとに行われる。他の多くのタイプの記憶装置と同様に、メモリ装置１０はファイルを管理しない。メモリ２０は、ファイルの論理アドレスが識別される場合にファイル・アロケーション・テーブル（ＦＡＴ）を必ず記憶するが、ＦＡＴは典型的にコントローラ１２によってではなく、ホスト装置２４によってアクセスされて管理される。したがって、特定ファイル内のデータを暗号化するために、コントローラ１２はホスト装置を頼りにメモリ２０内のファイルにあるデータの論理アドレスを送信する必要があり、したがって、特定ファイルのデータはシステム１０のみに利用可能な鍵値を用いてシステム１０によって検索され、暗号化および／または復号化することができる。
ファイル内のデータの暗号処理に際して、ホスト装置２４およびメモリシステム１０の両方に同じ鍵を参照する機会を提供するために、ホスト装置は、システム１０によって生成される鍵値あるいはシステム１０に送信される鍵値の各々に対してリファレンスを提供する。この場合、このようなリファレンスは、単に鍵ＩＤであってよい。それゆえ、ホスト２４は、システム１０によって暗号処理される各ファイルを鍵ＩＤと関連付け、システム１０は、データを暗号処理するために使用される各鍵値をホストによって提供される鍵ＩＤと関連付ける。それゆえ、ホストは、データの暗号処理を要求するとき、その要求を、メモリ２０から取り出されあるいはメモリ２０に記憶されるデータの論理アドレスおよび鍵ＩＤとともに、システム１０に送信することになる。システム１０は、鍵値を生成しあるいは受信し、ホスト２４によって提供される鍵ＩＤをこの鍵値と関連付けて暗号処理を実施する。こうすると、メモリシステム１０の動作方法を変更しなくて済む一方、鍵値への排他的アクセスを含む、鍵を用いた暗号処理を完全に制御することができる。換言すると、いったん鍵値がシステム１０に記憶されるか、あるいはシステム１０によって生成されると、システムは、ＦＡＴの独占的制御によるファイルの管理をホスト２４に継続させつつ、暗号処理に用いる鍵値の管理を一手に引き受ける。鍵値がメモリシステム１０に記憶された後、ホスト装置２４は、データの暗号処理に用いる鍵値の管理に一切関与しない。
ホスト２４によって提供される鍵ＩＤと、メモリシステムによって送信または生成される鍵値とは、実施形態の１つにおいて、「コンテンツ暗号化鍵」またはＣＥＫと以下で称される量の、２つの属性を形成する。ホスト２４は、各鍵ＩＤを１つまたは複数のファイルと関連付けてもよい。またホスト２４は、各鍵ＩＤを非編集データと関連付けるか、あるいは、何らかの方法で編集され、かつ完全なファイルに編集されたデータに限定されないデータと関連付けてもよい。
ユーザまたはアプリケーションが、システム１０の保護されたコンテンツまたは領域にアクセスするためには、システム１０に事前に登録される認証情報を用いて認証される必要がある。認証情報は、このような認証情報によって特定のユーザまたはアプリケーションに与えられたアクセス権に関係している。事前登録プロセスでは、システム１０は、アイデンティティの記録およびユーザまたはアプリケーションの認証情報と、ユーザまたはアプリケーションによって決定されホスト２４を通じて提供されるこうしたアイデンティティおよび認証情報に関連するアクセス権と、を記憶する。事前登録の完了後、ユーザまたはアプリケーションがメモリ２０へのデータの書込みを要求するとき、ホスト装置を通じてそのアイデンティティおよび認証情報と、データを暗号化する鍵ＩＤと、暗号化データを記憶する必要がある場合の論理アドレスと、を提供する必要がある。システム１０は、鍵値を生成または受信し、この値をホスト装置によって提供される鍵ＩＤと関連付け、書き込まれるデータを暗号化するために使用される鍵値に対する鍵ＩＤをこのユーザまたはアプリケーションのための記録または表に記憶する。この後、システムはデータを暗号化し、暗号化されたデータを、生成または受信された鍵値とともに、ホストによって指定されたアドレスに記憶する。
ユーザまたはアプリケーションが、メモリ２０から暗号化されたデータの読出しを要求するとき、そのアイデンティティおよび認証情報と、要求されたデータを暗号化するために事前使用される鍵に対する鍵ＩＤと、暗号化されたデータが記憶される論理アドレスと、を提供する必要がある。システム１０は、この後、ホストによって提供されるユーザまたはアプリケーションアイデンティティおよび認証情報を、その記録に記憶されたユーザまたはアプリケーションアイデンティティおよび認証情報と照合する。これらが一致する場合、システム１０は、ユーザまたはアプリケーションによって提供された鍵ＩＤに関連する鍵値をそのメモリから取り出し、鍵値を用いてホスト装置によって指定されたアドレスに記憶されたデータを復号化し、復号化されたデータをユーザまたはアプリケーションに送信する。
認証のための認証情報を、暗号化処理に使用される鍵の管理から分離することによって、認証情報を共有せずにデータにアクセスする権利を共有することが可能である。それゆえ、種々の認証情報を有するユーザまたはアプリケーションのグループは、同じデータにアクセスするために同じ鍵にアクセスすることができるが、このグループ外部のユーザはアクセスすることができない。グループ内のすべてのユーザまたはアプリケーションは同じデータにアクセスしてもよいが、これらのユーザまたはアプリケーションは異なる権利をさらに有していてもよい。それゆえ、一部のユーザまたはアプリケーションはリード・オンリー・アクセスしてもよく、他のユーザまたはアプリケーションはライト・オンリー・アクセスしてもよく、さらに他のユーザまたはアプリケーションはこれら両方のアクセスをしてもよい。システム１０は、ユーザまたはアプリケーションのアイデンティティおよび認証情報と、ユーザまたはアプリケーションがアクセスする鍵ＩＤと、鍵ＩＤの各々に対する関連アクセス権と、の記録を維持する。そのため、すべてが適正に認証されたホスト装置によって制御されるものとして、システム１０では、特定のユーザまたはアプリケーションの鍵ＩＤの追加または削除を行うことで、当該鍵ＩＤに関連するアクセス権を変更したり、あるユーザまたはアプリケーションから別のユーザまたはアプリケーションにアクセス権を委譲したり、さらにはユーザまたはアプリケーションの記録または表を削除または追加したりすることができる。記憶された記録は、一定の鍵にアクセスするためにセキュアチャネルが必要であることを規定してもよい。認証は、パスワードとともに対称または非対称アルゴリズムを使用して行われてもよい。
特に重要なのは、メモリシステム１０内の保護されたコンテンツの移植性である。鍵値へのアクセスがメモリシステムによって制御される実施形態では、システムを組み込むメモリシステムまたは記憶装置が、ある外部システムから別の外部システムに移動されるとき、そこに記憶されたコンテンツのセキュリティが維持される。鍵がメモリシステムによって生成されようとメモリシステムの外部に由来しようと、外部システムはメモリシステムによって完全に制御されるように認証されていない限り、システム１０内のこのようなコンテンツにアクセスすることができない。このように認証された後でさえ、アクセスはメモリシステムによって全体として制御され、外部システムはメモリシステム内のプリセットされた記録に従って制御された形でしかアクセスすることができない。要求がこのような記録に適合しなければ、要求は拒絶されることになる。
コンテンツを保護する際の柔軟性を高めるために、以下でパーティションと称するメモリの一定領域が、適正に認証されたユーザまたはアプリケーションのみによってアクセスされうることが想定される。鍵ベースのデータ暗号化についての前述の特徴を併用した場合、システム１０はより優れたデータ保護能力を備える。図２に示すように、フラッシュメモリ２０は、その記憶容量が複数のパーティション（ユーザ領域またはパーティションおよびカスタムパーティション）に分割されてもよい。ユーザ領域またはパーティションＰ０は、認証なしですべてのユーザおよびアプリケーションにアクセス可能である。ユーザ領域に記憶されたデータのすべてのビット値は、どんなアプリケーションまたはユーザによっても読み書きされうるが、データ読出しが暗号化される場合、復号化する権限のないユーザまたはアプリケーションは、ユーザ領域に記憶されたビット値により表される情報にアクセスできないことになる。これは、例えば、ユーザ領域Ｐ０に記憶されたファイル１０２および１０４によって説明される。さらにユーザ領域に記憶されるのは、すべてのアプリケーションおよびユーザによって読み出され理解されうる１０６などの暗号化されていないファイルである。それゆえ、図面上では、ファイル１０２および１０４などのように、暗号化されたファイルはロック付きで示す。
権限のないアプリケーションまたはユーザは、ユーザ領域Ｐ０で暗号化されたファイルを解釈できないが、このようなアプリケーションまたはユーザであってもファイルを削除したり破壊したりすることは可能であり、用途によっては好ましくない場合がある。このためメモリ２０には、パーティションＰ１およびＰ２などの、事前の認証なくしてアクセスできない被保護カスタムパーティションもある。この用途の実施形態に使える認証プロセスを、以下で説明する。
同じく図２に示されているように、メモリ２０のファイルには様々なユーザまたはアプリケーションがアクセスしうる。それゆえ、図２には、ユーザ１および２とアプリケーション１〜４（装置上で実行）が示されている。これらのエンティティは、以下で説明する認証プロセスによって認証された後に、メモリ２０の被保護コンテンツへのアクセスが認められる。このプロセスでは、アクセスを要求するエンティティを、ロール方式のアクセス制御のためにホスト側で識別する必要がある。それゆえ、アクセスを要求するエンティティはまず、「私はアプリケーション２であってファイル１を読み出したい」などの情報を供給することによって、自身を識別する。コントローラ１２は、この後、そのアイデンティティと、認証情報と、要求とを、メモリ２０またはコントローラ１２に記憶された記録に突き合せる。すべての要件が満たされる場合、そのようなエンティティにアクセスが認められる。図２に示すように、ユーザ１はパーティションＰ１のファイル１０１を読み書きすることができ、Ｐ０ではファイル１０６に対する無制限の読出しおよび書込み権利を有しているが、これ以外に読出し可能なファイルはファイル１０２および１０４のみである。一方、ユーザ２は、ファイル１０１および１０４へのアクセスを許可されないが、ファイル１０２に対する読出しおよび書込みアクセス権は有している。図２に示すように、ユーザ１および２のログインアルゴリズム（ＡＥＳ）は同じであるが、アプリケーション１および３のログインアルゴリズムは異なり（例えば、ＲＳＡと００１００１）、ユーザ１および２のものとも異なる。
セキュア・ストレージ・アプリケーション（ＳＳＡ）は本発明の一実施形態を例示するメモリシステム１０のセキュリティアプリケーションであり、前述した機能の多くはこれを用いて実施することができる。ＳＳＡは、メモリ２０またはＣＰＵ１２の不揮発性メモリ（図示せず）に記憶されたデータベースを備えるソフトウェアまたはコンピュータコードとして実装でき、ＲＡＭ１２ａに読み込まれ、ＣＰＵ１２によって実行される。下表には、ＳＳＡに言及する場合に用いる頭字語が記されている。
Figure 2013514587
＜ＳＳＡシステムの説明＞
ＳＳＡの主な役割は、データの保護と完全性とアクセス制御である。データとは、ある種の大容量記憶装置に一目瞭然な状態で記憶される場合があるファイルである。ＳＳＡシステムは記憶システムの上部に位置し、記憶されたホストファイルのためのセキュリティ層を加え、後述するセキュリティデータ構造を通じてセキュリティ機能を提供する。
ＳＳＡの主な仕事は、メモリに記憶された（保護された）コンテンツに関わる様々な権利を管理することである。メモリアプリケーションは、複数の記憶コンテンツに対する、複数のユーザおよびコンテンツ権利を管理する必要がある。ホストアプリケーションは、ホスト側から、提示されたドライブとパーティションを見るほか、記憶装置に記憶されたファイルの位置を管理し表現するファイル・アロケーション・テーブル（ＦＡＴ）を見る。
この場合の記憶装置は、パーティションに分割されたＮＡＮＤフラッシュチップを使用するが、他の携帯型記憶装置も使用でき、本発明の範囲内にある。これらのパーティションは一連の論理アドレスであり、その境界は開始アドレスと終端アドレスで区切られる。したがって、必要に応じて、非表示のパーティションへのアクセスに制限を設けることができ、それにはソフトウェア（メモリ２０に記憶されたソフトウェアなど）によって上記の境界内のアドレスにそのような制限を関連付ける。ＳＳＡは、自身が管理する論理アドレスの境界によって、パーティションを完全に認識しうる。ＳＳＡシステムは、パーティションを用いて、権限を有していないホストアプリケーションからデータを物理的に保護する。ホストにとってのパーティションは、データファイルが記憶される専有空間を規定するメカニズムである。これらのパーティションは公開しても、非公開もしくは非表示としてもよい。公開する場合、記憶装置にアクセスできる者であれば誰でも装置におけるこれらのパーティションの存在を見取って、かつ認識することができる。非公開もしくは非表示にする場合、選ばれたホストアプリケーションのみがこれらのパーティションにアクセスでき、記憶装置におけるこれらの存在を認識できる。
図３は、メモリのパーティションＰ０、Ｐ１、Ｐ２、およびＰ３を示すメモリの概略図であり（当然ながら５つ以上のパーティションが使われることも、あるいは３つ以下のパーティションが使われることもある）、Ｐ０はいずれのエンティティでも認証なしでアクセスできる公開パーティションである。
非公開パーティション（Ｐ１、Ｐ２、またはＰ３など）の中にあるファイルへのアクセスは非表示にされる。ホストによるパーティションへのアクセスを阻止することにより、フラッシュ装置（例えば、フラッシュカード）は、パーティションの中でデータファイルの保護を達成する。しかしながら、この種の保護は、非表示パーティションに常駐する論理アドレスに記憶されたデータへのアクセスに制限を設けることによって、非表示パーティションの中にあるすべてのファイルを囲い込むものである。換言すると、一連の論理アドレスに制限を関連付けるものである。そのパーティションにアクセスできるユーザ／ホストはいずれも、内部にあるすべてのファイルに無制限にアクセス可能である。様々なファイル（またはファイル群）を互いに分離するため、ＳＳＡシステムは、鍵と、鍵のリファレンスすなわち鍵ＩＤとを用いて、別の保護および完全性レベルをファイル（またはファイル群）単位で提供する。様々なメモリアドレスでデータを暗号化するために用いられる特定の鍵値の鍵リファレンス（すなわち鍵ＩＤ）は、暗号化データを含む容器または領域に例えることができる。このため、図４では、鍵ＩＤと関連付けられた鍵値を用いて暗号化されたファイルを取り囲む領域として、鍵リファレンス（すなわち鍵ＩＤ）（例えば、「鍵１」および「鍵２」）が図形で示されている。
図４を参照すると、例えば、ファイルＡは鍵ＩＤで囲まれていないため、いずれのエンティティでも認証なしでファイルＡにアクセスすることができる。公開パーティションの中にあるファイルＢは、いずれのエンティティでも読出しや上書きを行えるが、その中のデータはＩＤ「鍵１」を有する鍵で暗号化されているため、このような鍵にアクセスできるエンティティでない限り、ファイルＢの中にある情報にはアクセスすることができない。このような鍵値と鍵リファレンス（すなわち、鍵ＩＤ）の使用は、前述したパーティションによる保護とは異なり、論理的な保護のみを提供する。つまり、パーティション（公開または非公開）にアクセスできるホストであればいずれでもパーティション全体の中で暗号化データを含むデータを読み書きすることができる。しかしながら、データは暗号化されているため、権限を有していないユーザはデータを破壊することしかできない。権限を有していないユーザは、発覚することなく、このデータを変更できない。暗号化および／または復号化鍵へのアクセスを制限することにより、権限を有するエンティティのみにデータの使用を認めることができる。Ｐ０では、ファイルＢおよびＣも、鍵ＩＤ「鍵２」を有する鍵を使用して暗号化されている。
データの機密保護と完全性は、コンテンツ暗号化鍵（ＣＥＫ）をＣＥＫ当たり１つずつ使用する、対称暗号化法で提供することができる。ＳＳＡの実施形態では、ＣＥＫの鍵値がフラッシュ装置（例えば、フラッシュカード）によって生成または受信され、内部でのみ使用され、外部に対して秘密に保たれる。暗号化されるデータでハッシュ計算を行うか、あるいは暗号を連鎖ブロック化することによって、データ完全性を確保することもできる。
パーティション内のすべてのデータが、異なる鍵によって暗号化されるとともに、異なる鍵ＩＤが割り振られるわけではない。公開またはユーザファイルの中、またはオペレーティングシステム領域（すなわち、ＦＡＴ）の中で、一定の論理アドレスに、鍵または鍵リファレンスが割り振られない場合がある。それゆえ、パーティション自体にアクセスできるエンティティであれば、いずれもこれにアクセスすることができる。
鍵およびパーティションの作成や、パーティションにおけるデータの読み書きや、鍵の使用を望むエンティティは、アクセス制御記録（ＡＣＲ）を通じてＳＳＡシステムにログインする必要がある。ＳＳＡシステムにおけるＡＣＲの特権は、「アクション」と呼ばれる。どのＡＣＲでも３種類のアクション、すなわちパーティションおよび鍵／鍵ＩＤの作成と、パーティションおよび鍵へのアクセスと、他のＡＣＲの作成／更新と、を実行する「権限」を有することができる。
ＡＣＲは、ＡＣＲグループ、すなわち、ＡＧＰと呼ばれるグループに整理される。ＡＣＲの認証に成功するとＳＳＡシステムがセッションを開放し、このセッションの中でＡＣＲのアクションを実行することができる。ＡＣＲとＡＧＰは、ポリシーに従ってパーティションや鍵へのアクセスを制御するためのセキュリティデータ構造である。
＜ユーザパーティション＞
ＳＳＡシステムは、ユーザパーティションとも称される、１つまたは複数の公開パーティションを管理する。このパーティションは、記憶装置に存在し、記憶装置の標準的な読み書きコマンドによってアクセスされうるパーティションである。パーティションのサイズと装置上のパーティションの存在とに関する情報の取得は、ホストシステムから隠されないことが好ましい。
ＳＳＡシステムでは、一般的な読み書きコマンドまたはＳＳＡコマンドのいずれかによって、このパーティションにアクセスすることができる。したがって、パーティションへのアクセスは、特定のＡＣＲに限定されないことが好ましい。しかしなら、ＳＳＡシステムでは、ホスト装置をユーザパーティションへのアクセスに限定しうるようにすることができる。読出しおよび書込みのアクセスは、個別に有効／無効にされうる。４つすべての組合せ（例えば、書込み限定、読出し限定（書込み防止）、読出しおよび書込み、およびアクセスなし）が可能である。
ＳＳＡシステムは、ＡＣＲによって、鍵ＩＤをユーザパーティション内のファイルと関連付け、このような鍵ＩＤに関連する鍵を用いて個々のファイルを暗号化することができる。ユーザパーティション内の暗号化されたファイルへのアクセスと、パーティションに対するアクセス権の設定とは、ＳＳＡコマンドセットを用いて行われることになる。前述の機能は、ファイルに編成されないデータにも適用される。
＜ＳＳＡパーティション＞
ＳＳＡパーティションは、ＳＳＡコマンドのみによってアクセスされうる、（認証されていない当事者から）隠されたパーティションである。ＳＳＡシステムでは、ＡＣＲへのログオンによって確立されたセッション（後述する）以外からは、ホスト装置がＳＳＡパーティションにアクセスできないことが好ましい。同様に、ＳＳＡは、確立されたセッションからの要求がない限り、ＳＳＡパーティションの存在、サイズ、およびアクセス権限に関する情報を提供しないことが好ましい。
パーティションへのアクセス権は、ＡＣＲ許可から得られる。ＡＣＲがＳＳＡシステムにログインされた時点で、ＳＳＡシステムは他のＡＣＲとパーティションを共有することができる（後述）。パーティションが作成されると、ホストは、そのパーティションに対するリファレンス名またはＩＤ（例えば、図３および４におけるＰ０〜Ｐ３）を提供する。このリファレンスは、パーティションへのさらなる読出しおよび書込みコマンドに使用される。
＜記憶装置の分割＞
装置の使用可能な記憶容量のすべてが、ユーザパーティションと、その時点で構成済みのＳＳＡパーティションとに割り当てられることが好ましい。したがって、再分割において、既存のパーティションの再構成を伴うことがある。装置容量（全パーティションの合計サイズ）の正味の変化は、ゼロである。装置メモリ空間におけるパーティションのＩＤは、ホストシステムによって設定される。
ホストシステムは、既存パーティションのいずれか１つを２つのより小さいパーティションに再分割したり、２つの既存パーティション（隣接する場合とそうでない場合とがある）を１つに併合したりすることができる。分割されたパーティションや併合されたパーティションの中のデータは、ホストの判断で消去するか、あるいは現状のまま残すことができる。
記憶装置の再分割によってデータが（記憶装置の論理アドレス空間の中での消去や移動により）失われるおそれがあるため、ＳＳＡシステムは、再分割において厳重な制限を課す。つまり、ルートＡＧＰ（後述）に常駐するＡＣＲにのみ再分割コマンドの発行が許可され、これが参照できるパーティションは自身が所有するパーティションのみである。パーティションの中でデータがどのように構成されているかはＳＳＡシステムには分からないため（ＦＡＴまたはその他のファイルシステム構造）、装置の再分割において構成を組み直すことに関与するのはホストである。
ユーザパーティションの再分割によって、ホストＯＳから見たこのパーティションのサイズおよびその他の属性は変化する。
再分割の後、ホストシステムは、ＳＳＡシステムにおけるＡＣＲが不在パーティションを参照していないことを確認する責任がある。これらのＡＣＲが適切に削除または更新されなければ、不在パーティションに対してこれらのＡＣＲに代わって行われるアクセスの試みは以後システムによって検出され、拒絶される。削除される鍵および鍵ＩＤについても同様の配慮がなされる。
＜鍵、鍵ＩＤ、および論理的保護＞
ある特定の非表示パーティションに書き込まれたファイルは、不特定多数の人に対して非表示にされる。しかし、いったんエンティティ（敵対的なエンティティ、またはそうでないエンティティ）が情報を得てこのパーティションにアクセスすると、そのファイルは使用可能となり一目瞭然となる。そのファイルのさらなる安全確保のため、ＳＳＡは非表示パーティションでファイルを暗号化でき、このファイルの復号化に用いる鍵にアクセスするための認証情報は、好ましくはパーティションにアクセスするためのものとは異なるものにする。ファイルはホストによって全面的に制御され、管理されるため、ファイルにＣＥＫを割り振ることには問題がある。これを解決するには、ＳＳＡが了解する何か、すなわち鍵ＩＤにファイルを関連付ける。つまりＳＳＡによって鍵が作成されると、ホストはその鍵を用いて暗号化されるデータにこの鍵の鍵ＩＤを割り振る。鍵が鍵ＩＤとともにＳＳＡに送信される場合、鍵と鍵ＩＤを互いに関連付けることは容易である。
鍵値および鍵ＩＤは論理セキュリティを提供する。所与の鍵ＩＤに関連付けられたすべてのデータは、その場所とは関係なく、そのリファレンス名または鍵ＩＤがホストアプリケーションによって作成されて一意的に提供されるコンテンツ暗号化鍵（ＣＥＫ）における同じ鍵値で暗号化される。あるエンティティが（ＡＣＲによる認証によって）非表示パーティションへのアクセスを得て、このパーティション内の暗号化されたファイルに対して読出しまたは書込みを行いたい場合、そのエンティティは、ファイルと関連付けられる鍵ＩＤにアクセスする必要がある。ＳＳＡは、この鍵ＩＤに対する鍵へのアクセスを認めるとき、この鍵ＩＤに関連付けられたＣＥＫの鍵値をロードし、これをホストに送信する前にデータを復号化するか、あるいはこれをフラッシュメモリ２０に書き込む前にデータを暗号化する。一実施形態では、鍵ＩＤに関連付けられたＣＥＫの鍵値は、ＳＳＡシステムによって一度無作為に作成されて、ＳＳＡシステムによって維持される。ＳＳＡシステムの外部には、ＣＥＫのこの鍵値を認識し、またはこれにアクセスする者は誰もいない。外界は、リファレンスまたは鍵ＩＤを提供して使用するだけで、ＣＥＫの鍵値を提供も使用もしない。鍵値は、完全に管理され、好ましくはＳＳＡのみによりアクセス可能であることが好ましい。あるいは、鍵はＳＳＡシステムに提供されてもよい。
ＳＳＡシステムは、以下の暗号モードのいずれか１つ（ユーザ定義の）を用いて、鍵ＩＤと関連付けられたデータを保護する（ＣＥＫの鍵値とともに使用される実際の暗号アルゴリズムは、システムによって制御されて外界に暴露されない）。
ブロックモード：データはブロックに分割され、それらの一つ一つが個々に暗号化される。このモードは、一般に機密性がさほど高くなく、かつ辞書攻撃に敏感であると考えられる。しかしながら、このモードによりユーザは、データブロックのいずれか１つに無作為にアクセスすることができる。
連鎖モード：データはブロックに分割され、ブロックは暗号化プロセス中に連鎖される。あらゆるブロックが次の１つの暗号化プロセスへの入力の１つとして使用される。このモードでは、機密性が比較的高いと考えられるが、データは最初から最後まで順番に読み書きされ、ユーザには受け入れられない可能性があるオーバーヘッドを作成する。
ハッシュ化：データの完全性を実証するために使用されうるデータダイジェストを新たに作成する連鎖モード。
＜ＡＣＲおよびアクセス制御＞
ＳＳＡは、複数のアプリケーションの一つ一つがシステムデータベースにおけるノードのツリーとして表される複数のアプリケーションを処理するように、設計される。ツリーブランチ間のクロストークがないようにして、アプリケーション間の相互排除が実現される。
ＳＳＡシステムにアクセスするために、あるエンティティは、システムのＡＣＲの１つを介して接続を確立する必要がある。ユーザが接続の対象として選定したＡＣＲに組み込まれた定義に従って、ログイン手続きがＳＳＡシステムによって管理される。
ＡＣＲは、ＳＳＡシステムに至る個々のログイン地点である。ＡＣＲは、ログイン認証情報と認証方法を保持する。読出し特権や書込み特権を含むＳＳＡシステムの中でのログイン権限も、この記録の中にある。これを示す図５には、同じＡＧＰの中にｎ個のＡＣＲがある。これは、ｎ個のＡＣＲのうちの少なくとも一部のＡＣＲが、同じ鍵へのアクセスを共有しうることを意味する。それゆえ、ＡＣＲ＃１とＡＣＲ＃ｎは鍵ＩＤ「鍵３」を有する鍵へのアクセス権を共有する。ここで、ＡＣＲ＃１とＡＣＲ＃ｎはＡＣＲ＿ＩＤであり、「鍵３」は鍵の鍵ＩＤであり、この鍵を用いて「鍵３」に関連するデータが暗号化される。複数ファイルまたは複数データ群の、暗号化および／または復号化に、同じ鍵を使用することもできる。
ＳＳＡシステムは、ログインに成功した時点でシステムにおけるユーザの特権が変わる場合など、認証アルゴリズムおよびユーザ認証情報が変わる可能性のあるシステムに対して、複数のタイプのログインをサポートする。図５は、さらに別のログインアルゴリズムおよび認証情報を示している。ＡＣＲ＃１はパスワード・ログイン・アルゴリズムおよび認証情報としてのパスワードを規定しているのに対して、ＡＣＲ＃２はＰＫＩ（公開鍵基盤）ログインアルゴリズムおよび認証情報としての公開鍵を規定している。それゆえ、ログインするために、あるエンティティは、有効なＡＣＲ＿ＩＤとともに正しいログインアルゴリズムおよび認証情報を提示する必要がある。
ＳＳＡシステムのＡＣＲにログインしたエンティティの権限、すなわちＳＳＡコマンドを使用する権利は、ＡＣＲと関連付けられた権限制御記録（ＰＣＲ）の中で設定する。図５のＰＣＲに示すように、ＡＣＲ＃１は「鍵３」と関連付けられたデータに対して読出し限定権限を許諾し、ＡＣＲ＃２は「鍵５」と関連付けられたデータの読出し権限と書込み権限とを許諾する。
読出しや書込みに使う鍵などの異なるＡＣＲが、システムで共通の利益や特権を共有することがある。このため、共通する部分があるＡＣＲはＡＧＰ、すなわちＡＣＲグループにグループ分けされる。それゆえ、ＡＣＲ＃１とＡＣＲ＃ｎはいずれも、鍵ＩＤ「鍵３」を有する鍵へのアクセス権がある。
ＡＧＰとその中にあるＡＣＲは階層状のツリーの中で編成されるため、ＡＣＲは重要データの安全性を保つ安全鍵を作成できるほか、好ましくは自身の鍵ＩＤ／パーティションに対応する他のＡＣＲ項目を作成することもできる。これらの子ＡＣＲは、その父、すなわち作成元と同じ権限を有するかそれよりも少ない権限を有することになり、父ＡＣＲ自身が作成した鍵の権限が付与される場合がある。言うまでもなく、子ＡＣＲは自身が作成する任意の鍵に対するアクセス権限を取得する。これは図６に例示されている。このように、ＡＧＰ１２０の中にあるＡＣＲはいずれもＡＣＲ１２２によって作成されたものであり、これらのＡＣＲのうちの２つは、「鍵３」と関連付けられたデータへのアクセス権限をＡＣＲ１２２から継承している。
＜ＡＧＰ＞
ＳＳＡシステムへのログインにおいて、ＡＧＰと、そのＡＧＰの中にあるＡＣＲを指定する。
ＡＧＰはいずれも一意なＩＤ（リファレンス名）を有し、ＳＳＡデータベースにおける該当する項目への索引として使用される。ＡＧＰ名は、ＡＧＰの作成時にＳＳＡシステムに提供される。ＳＳＡは、提供されるＡＧＰ名がシステムに既に存在する場合に、作成動作を拒絶することになる。
以降の節で説明するように、アクセス権限や管理権限の委譲に関わる制限事項は、ＡＧＰを使用して管理運営される。完全に独立したエンティティ、例えば２つの異なるアプリケーションまたは２つの異なるコンピュータユーザによるアクセスの制御運営は、図６の２つのツリーが果たす役割の１つである。ここで重要でありうることは、２つのアクセスプロセスが、たとえ同時に発生する場合でも、事実上互いに独立する（すなわち、事実上クロストークをなくす）ことである。これは、それぞれのツリーにおけるＡＣＲとＡＧＰの認証、権限、追加作成などが他のツリーにおけるものと無関係であり、かつ他のツリーにおけるものに左右されないことを意味する。このため、ＳＳＡシステムを使用するメモリ１０では、複数のアプリケーションを同時に処理することができる。また、２つのアプリケーションが、互いに自立的に２つの別々のデータ群（例えば、１組の写真と１組の曲）にアクセスすることも可能になる。これは図６に例示されている。それゆえ、図６の上部で、ツリーの中にあるノード（ＡＣＲ）を通じてアクセスするアプリケーションまたはユーザにとって、「鍵３」、「鍵Ｘ」、および「鍵Ｚ」と関連付けられたデータは、写真を備えていてもよい。図６の下部で、ツリーのノード（ＡＣＲ）を通じてアクセスするアプリケーションまたはユーザにとって、「鍵５」および「鍵Ｙ」と関連付けられたデータは、曲を備えていてもよい。ＡＧＰを作成したＡＣＲは、このＡＧＰにＡＣＲ項目がなく空になっている場合に限り、このＡＧＰを削除する権限を有する。
＜エンティティにとってのＳＳＡの入口：アクセス制御記録（ＡＣＲ）＞
ＳＳＡシステムのＡＣＲは、エンティティによるシステムログインのあり方を記述するものである。ＳＳＡシステムにログインするエンティティは、これから始まる認証プロセスに該当するＡＣＲを指定する必要がある。図５に示すように、ＡＣＲの中にある権限制御記録（ＰＣＲ）は、ＡＣＲに記載の認証を終えたユーザが実行できる許諾アクションを説明するものである。ホスト側エンティティは、すべてのＡＣＲデータフィールドを提供する。
ＡＣＲへのログオンに成功したエンティティは、ＡＣＲのパーティションおよび鍵アクセス権限およびＡＣＭ権限（後述）のすべてを照会することができることになる。
＜ＡＣＲ＿ＩＤ＞
ＳＳＡシステムのエンティティがログインプロセスを開始する場合、すべてのログイン要件が満たされているときにＳＳＡが正しいアルゴリズムをセットアップして正しいＰＣＲを選択するように、ログイン方法に対応するＡＣＲ＿ＩＤ（ＡＣＲが作成されたときにホストによって提供される）を指定する必要がある。ＡＣＲ＿ＩＤは、ＡＣＲが作成されるときにＳＳＡシステムに提供される。
＜ログイン／認証アルゴリズム＞
認証アルゴリズムは、エンティティによって使用されるログイン手続きと、ユーザのアイデンティティを証明するために必要な認証情報と、を指定するものである。ＳＳＡシステムは、手続きなし（および認証情報なし）から、パスワードに基づく手続き、対称暗号法または非対称暗号法に基づく双方向認証プロトコルまで、複数の標準ログインアルゴリズムをサポートする。
＜認証情報＞
エンティティの認証情報は、ログインアルゴリズムに対応しており、ＳＳＡがユーザを検証して認証するために使用される。認証情報の例として、パスワード認証用のパスワード／ＰＩＮ数、ＡＥＳ認証用のＡＥＳ鍵、などが挙げられる。認証情報のタイプ／形式（すなわち、ＰＩＮ、対称鍵など）は、事前に決められ、認証モードから得られ、ＡＣＲを作成するときにＳＳＡシステムに提供される。ＳＳＡシステムはこれら認証情報の設定、提供、および管理に関与しないが、例外としてＰＫＩベースの認証では装置（例えば、フラッシュカード）を使用してＲＳＡなどのタイプの鍵対を生成することができ、証明書生成のための公開鍵をエクスポートすることができる。
＜権限制御記録（ＰＣＲ）＞
ＰＣＲは、ＳＳＡシステムにログインしＡＣＲの認証プロセスに合格した後の、エンティティに対する許諾内容を示すものである。権限には、パーティションおよび鍵の作成権限と、パーティションおよび鍵へのアクセス権限と、エンティティ−ＡＣＲ属性の管理権限の３種類がある。
＜パーティションへのアクセス＞
ＰＣＲのこの部分には、ＡＣＲ段階を首尾よく終了したエンティティがアクセスしうるパーティションのリストが含まれる（ＳＳＡシステムへ提供されるパーティションのＩＤを使用）。各パーティションに対して、アクセスのタイプが、書込み限定または読出し限定に制限される場合があり、あるいは完全書込み／読出しアクセス権が指定される場合もある。図５のＡＣＲ＃１は、パーティション＃２にアクセスすることができてもパーティション＃１にはアクセスすることができない。ＰＣＲにおいて指定される制限は、ＳＳＡパーティションおよび公開パーティションに適用される。
公開パーティションには、ＳＳＡシステムをホストする装置（例えば、フラッシュカード）に対する通常の読出しおよび書込みコマンドによってアクセスすることや、ＳＳＡコマンドによってアクセスすることができる。公開パーティションを制限する権限を有するルートＡＣＲ（後述）が作成されると、このルートＡＣＲは、その権限を自身の子に渡すことができる。ＡＣＲは、通常の読出しおよび書込みコマンドによる公開パーティションへのアクセスのみを制限することができることが好ましい。ＳＳＡシステムのＡＣＲは、これが作成されるときにのみ制限することができることが好ましい。公開パーティションに対する読出し／書込み権限をＡＣＲが取得した時点では、その権限を剥奪することができないことが好ましい。
＜鍵ＩＤへのアクセス＞
ＰＣＲのこの部分は、エンティティのログインプロセスによってＡＣＲポリシーが満たされているときにエンティティがアクセスできる、鍵ＩＤのリスト（ホストによってＳＳＡシステムに提供される）と関連付けられたデータを含んでいる。ＰＣＲに記載されたパーティションに常駐するファイルには、指定された鍵ＩＤが関連付けられる。装置（例えば、フラッシュカード）の論理アドレスに鍵ＩＤは関連付けられないので、ある特定のＡＣＲに対して２つ以上のパーティションが関連付けられるとき、それらのパーティションのいずれか１つの中にはファイルがありうる。ＰＣＲ内で指定された鍵ＩＤは、それぞれ異なる１組のアクセス権を有しうる。鍵ＩＤによって指示されるデータへのアクセスは、書込み限定または読出し限定に制限される場合があり、あるいは完全書き込み／読出しアクセス権が指定される場合もある。
＜ＡＣＲ属性管理（ＡＣＡＭ）＞
この節では、ＡＣＲのシステム属性を変更しうる場合について説明する。
ＳＳＡシステムで許可されうるＡＣＡＭアクションは、次の通りである。
１．ＡＧＰおよびＡＣＲの作成／削除／更新
２．パーティションおよび鍵の作成／削除
３．鍵およびパーティションに対するアクセス権の委譲
父ＡＣＲは、ＡＣＡＭ権限を編集することができないことが好ましい。この場合、好ましくはＡＣＲの削除と再作成が必要となる。また、ＡＣＲによって作成された鍵ＩＤに対するアクセス権限を、剥奪することができないことが好ましい。
ＡＣＲは、他のＡＣＲおよびＡＧＰを作成する能力を有していてもよい。ＡＣＲを作成するということは、その作成元が所有するＡＣＡＭ権限の一部または全部が、作成されたＡＣＲへ委譲されることを意味する場合もある。ＡＣＲを作成する権限を有するということは、次のアクションの権限を有することを意味する。
１．子の認証情報を設定し編集する：作成元ＡＣＲによっていったん設定された認証方法は編集することができないことが好ましい。子向けに既に設定された認証アルゴリズムの範囲内で、認証情報を変更してもよい。
２．ＡＣＲを削除する。
３．作成権限を子ＡＣＲへ委譲する（それゆえ孫を有する）。
他のＡＣＲを作成する権限を有するＡＣＲは、これが作成するＡＣＲに遮断解除権限を委譲する権限を有する（ただし、ＡＣＲの遮断を解除する権限を有しない場合もある）。父ＡＣＲは、解除ＡＣＲのリファレンスを子ＡＣＲの中に入れる。
父ＡＣＲは、自身の子ＡＣＲを削除する権限を有する唯一のＡＣＲである。ＡＣＲが作成した下位ＡＣＲを削除すると、この下位ＡＣＲから生まれたすべてのＡＣＲも自動的に削除される。ＡＣＲを削除すると、そのＡＣＲによって作成された鍵ＩＤとパーティションはすべて削除される。
例外として、ＡＣＲが自身の記録を更新できる場合が２つある。
１．作成元ＡＣＲによって設定されたパスワード／ＰＩＮであっても、それらを含むＡＣＲによってのみ更新されうる。
２．ルートＡＣＲは、それ自体と、それ自体が常駐するＡＧＰと、を削除しうる。
＜鍵およびパーティションへのアクセス権の委譲＞
ＡＣＲとそのＡＧＰは階層状のツリーで組み立てられ、ルートＡＧＰとその中にあるＡＣＲは、ツリーの最上部に位置する（例えば、図６のルートＡＧＰ１３０および１３２）。ＳＳＡシステムには複数のＡＧＰツリーが存在することがあるが、それらは互いに完全に分離されている。ＡＧＰの中にあるＡＣＲは、それ自体の鍵に対するアクセス権限を、同じＡＧＰの中にある全ＡＣＲと、それらによって作成されるこの全ＡＣＲに委譲しうる。鍵を作成する権限は、その鍵を使用するためのアクセス権限を委譲する権限を含むことが好ましい。
鍵に対する権限は３種類に分けられる。
１．アクセス：これは鍵に対するアクセス権限、すなわち読出しと書込みとを設定する。
２．所有権：当然ながら、鍵を作成したＡＣＲがその所有者である。この所有権は、ある１つのＡＣＲから別のＡＣＲ（同じＡＧＰの中にあるか、あるいは子ＡＧＰの中にあるＡＣＲという条件で）に委譲することができる。鍵の所有権は、鍵を削除する権限のほかに、鍵に対する権限を委譲する権限を提供する。
３．アクセス権委譲：この権限により、ＡＣＲは、自身が保持する権利を委譲することができる。
ＡＣＲは、自身が作成したパーティションのほかに、自身が所有するアクセス権限の対象となる他のパーティションに対するアクセス権限を、委譲することができる。
権限を委譲するには、パーティションの名前と鍵ＩＤを、指定されたＡＣＲのＰＣＲに追加する。鍵のアクセス権限を委譲するには、鍵ＩＤを使用してもよいし、あるいは委譲する側のＡＣＲのすべての作成された鍵がアクセス権限の対象となることを表明してもよい。
＜ＡＣＲの遮断および解除＞
システムによるエンティティのＡＣＲ認証プロセスが失敗すると、ＡＣＲの遮断カウンタがインクリメントする場合がある。一定の最大失敗認証数（ＭＡＸ）に達すると、ＳＳＡシステムによってＡＣＲは遮断されることになる。
遮断されたＡＣＲは、この遮断されたＡＣＲから参照される別のＡＣＲによって、解除されうる。この解除されたＡＣＲに対するリファレンスは、その作成元によるＡＣＲによって設定される。解除するＡＣＲは、遮断されたＡＣＲの作成元と同じＡＧＰの中にあり、「解除」権限を有することが好ましい。
システムの中のほかのＡＣＲは、いずれも遮断されたＡＣＲを解除することができない。遮断カウンタを用いて構成されるＡＣＲであっても、解除ＡＣＲがなければ、遮断された場合に解除することができない。
＜ルートＡＧＰ−アプリケーションデータベースの作成＞
ＳＳＡシステムは、複数のアプリケーションを処理し、各アプリケーションのデータを分離するように設計されている。アプリケーション特有のデータを識別し、かつ分離する場合には、ＡＧＰシステムのツリー構造が主要なツールとして使用される。ルートＡＧＰは、アプリケーションＳＳＡデータベースツリーの先端に位置し、いくぶん異なる挙動ルールに従う。ＳＳＡシステムでは、複数のルートＡＧＰを構成することができる。図６には、２つのルートＡＧＰ１３０および１３２が示されている。もちろん、これよりも少ないＡＧＰやこれよりも多いＡＧＰが使用されてもよく、その場合も本発明の範囲内にある。
新規アプリケーションのための装置（例えば、フラッシュカード）の登録、および／または、装置の新規アプリケーションの認証情報発行は、装置に新たなＡＧＰ／ＡＣＲツリーを追加する過程で行われる。
ＳＳＡシステムは、ルートＡＧＰ（ならびにルートＡＧＰの全ＡＣＲとその権限）を作成する場合に、以下の３種類のモードをサポートする。
１．オープンモード：どんな認証も必要としないすべてのユーザまたはエンティティ、あるいはシステムＡＣＲ（後述）を通じて認証されたユーザ／エンティティは、新規ルートＡＧＰを作成することができる。オープンモードによるルートＡＧＰの作成は、セキュリティ対策なしですべてのデータ転送がオープンチャネル（すなわち、発行エンティティのセキュア環境内）で行われる場合と、システムＡＣＲ認証（すなわち、Ｏｖｅｒ Ｔｈｅ Ａｉｒ（ＯＴＡ）および後発行手続き）を通じて確立されるセキュアチャネルを通じて行われる場合と、がある。
システムＡＣＲが構成されず（これはオプション機能である）、かつルートＡＧＰ作成モードをオープンに設定する場合に、オープン・チャネル・オプションのみが利用される。
２．制御モード：システムＡＣＲを通じて認証されたエンティティのみが、新規ルートＡＧＰを作成することができる。システムＡＣＲが構成されなければ、ＳＳＡシステムをこのモードに設定することはできない。
３．ロックモード：ルートＡＧＰの作成は無効にされ、さらなるルートＡＧＰをシステムに加えることはできない。
２つのＳＳＡコマンドで、この機能を制御する（これらのコマンドは、いずれのユーザ／エンティティでも認証なしで利用可能である）。
１．方法構成コマンド：３つのルートＡＧＰ作成モードのいずれか１つを使用するようにＳＳＡシステムを構成するために、使用される。オプション→制御、制御→ロックのモード変更のみが可能である（すなわち、ＳＳＡシステムが現在制御モードとして構成されている場合は、ロックモードにしか変更することができない）。
２．方法構成固定コマンド：方法構成コマンドを無効にし、現在選択されている方法を永続的に固定するために使用される。
ルートＡＧＰが作成されるとき、特別な初期化モードに入り、ＡＣＲの作成、構成（ルートＡＧＰの作成に適用されたものと同じアクセス制限を使用）が可能になる。ルートＡＧＰ構成プロセスの最後に、エンティティがこれを明示的に作動モードに切り替えると、既存のＡＣＲは更新できなくなり、ＡＣＲを新たに作成できなくなる。
標準モードに入ったルートＡＧＰを削除するには、そのＡＣＲのうち、ルートＡＧＰの削除する権限が割り当てられるＡＣＲの１つを通じて、システムにログインしなければならない。特別の初期化モードと同様に、これもルートＡＧＰの例外の一例である。上記のＡＧＰは、次のツリーレベルにあるＡＧＰとは対照的に、それ自体のＡＧＰを削除する権限を有するＡＣＲを含みうる唯一のＡＧＰであることが好ましい。
ルートＡＣＲと標準ＡＣＲとの３番目にして最後の違いは、パーティションを作成し削除する権限を有しうるシステム内で、唯一のＡＣＲであるということである。
＜ＳＳＡシステムＡＣＲ＞
システムＡＣＲは、次の２つのＳＳＡ操作に使用されてもよい。
１．不利な状況にある保護されたチャネルの保護下で、ＡＣＲ／ＡＧＰツリーを作成する。
２．ＳＳＡシステムをホストする装置を識別し、認証する。
ＳＳＡの中にシステムＡＣＲが１つだけある事が好ましく、いったん設定されたシステムＡＣＲは変更することができないことが好ましい。システムＡＣＲを作成するときにシステム認証は必要でなく、必要なのはＳＳＡコマンドのみである。システムＡＣＲ作成機能は、無効にすることができる（ルートＡＧＰ作成機能と同様）。１つのみのシステムＡＣＲが認められることが好ましいため、システムＡＣＲ作成コマンドはシステムＡＣＲの作成後には影響を及ぼさない。
システムＡＣＲは、その作成プロセスにおいて機能しない。作成が終了した時点で、システムＡＣＲが作成されて準備が整ったことを伝える専用のコマンドを発行する必要がある。この時点以後、システムＡＣＲの更新や差替えは行うことができないことが好ましい。
システムＡＣＲは、ＳＳＡにおいてルートＡＣＲ／ＡＧＰを作成する。システムＡＣＲは、ホストがルートレベルに満足し遮断するまで、ルートレベルを追加／変更する権限を有する。ルートＡＧＰを遮断すると、基本的にはシステムＡＣＲとの接続が遮断され、改ざん不能となる。この時点で、ルートＡＧＰとその中にあるＡＣＲを、誰も変更／編集することができない。これは、ＳＳＡコマンドを介して行われる。ルートＡＧＰの作成を無効にする作用は永続し、元に戻すことはできない。図７には、システムＡＣＲが関わる前述した機能が示されている。システムＡＣＲを使用して、３種類のルートＡＧＰが作成される。図７で、システムＡＣＲをルートＡＧＰに接続する点線で示すように、これらのルートＡＧＰが作成された後のある時点で、システムＡＣＲからルートＡＧＰを遮るＳＳＡコマンドがホストから送信され、ルートＡＧＰ作成機能が無効になる。これで３つのルートＡＧＰは改ざん不能となる。ルートＡＧＰが遮断される前または後に、３つのルートＡＧＰを使用して子ＡＧＰを作ることにより、３つの別々のツリーが形成される。
前述した機能は、コンテンツの所有者が、コンテンツを使用して安全な製品を構成する際に、優れた柔軟性を提供する。セキュア製品は「発行（issued）」する必要がある。発行とは、装置がホストを識別しホストが装置を識別するための識別鍵を出すプロセスである。ホストは、装置（例えば、フラッシュカード）を識別することにより、これの秘密を信用できるかどうかを判定することができる。一方、装置はホストを識別することにより、ホストが実施を許容されている範囲でのみ、セキュリティポリシーを実施する（特定のホストコマンドを許諾し実行する）ことができる。
複数のアプリケーションに対応するように設計される製品は、複数の識別鍵を有することになる。製品は「前発行」するか（出荷に先立つ製造中に鍵を記憶する）、あるいは「後発行」する（出荷後に新たな鍵を追加する）。後発行の場合、ある種の親鍵または装置レベル鍵をメモリ装置（例えば、メモリカード）に入れる必要があり、この鍵は、装置へのアプリケーションの追加が許可されるエンティティを識別するために使用される。
前述した機能により、後発行を有効／無効にするように、製品を構成することができる。さらに、後発行構成は出荷後に安全に果たすことができる。装置は、前述した親鍵または装置レベル鍵のほかには鍵のない状態で小売製品として購入され、この後、新たな所有者により、さらなる後発行アプリケーションを有効または無効にするように構成することができる。
それゆえ、システムＡＣＲ機能は、前述の目的を達成するための能力を提供する。
・システムＡＣＲがないメモリ装置は、アプリケーションを無制限かつ自由に追加することができる。
・システムＡＣＲがないメモリ装置は、システムＡＣＲの作成を無効にするように構成することができ、これは新規アプリケーションの追加を制御できないことを意味する（新規ルートＡＧＰ作成機能も無効にしない限り）。
・システムＡＣＲがあるメモリ装置は、システムＡＣＲ認証情報を用いた認証手続きによって確立されるセキュアチャネルを介して、アプリケーションの追加を制御できるだけである。
・システムＡＣＲがあるメモリ装置は、アプリケーションが追加される前かあるいは追加された後に、アプリケーション追加機能を無効にするように構成することができる。
＜鍵ＩＤリスト＞
鍵ＩＤは、具体的なＡＣＲ要求に従って作成されるが、メモリシステム１０でこれを使用するのはＳＳＡシステムのみである。鍵ＩＤの作成時に作成元ＡＣＲから提供されるか、あるいは作成元ＡＣＲに提供されるデータは、次の通りである。
１．鍵ＩＤ：このＩＤはホストを通じてエンティティから提供され、以降のすべての読出しアクセスや書込みアクセスにおいて、鍵と、その鍵を使って暗号化または復号化されるデータと、を参照するために使用される。
２．鍵暗号およびデータ完全性モード（前述した、および以下に述べる、ブロック、連鎖、およびハッシュモード）
ホストから提供される属性に加えて、ＳＳＡシステムは次のデータを維持する。
１．鍵ＩＤの所有者：所有者であるＡＣＲのＩＤ。鍵ＩＤが作成されたとき、作成元ＡＣＲがその所有者である。しかしながら、鍵ＩＤの所有権は、別のＡＣＲに譲渡されてもよい。鍵ＩＤの所有権を譲渡し、かつ鍵ＩＤを委譲できるものは、鍵ＩＤの所有者のみであることが好ましい。関連する鍵のアクセス権限の委譲と、これらの権利の失効を管理できるのは、鍵ＩＤの所有者か、または委譲権限を割り当てられたその他のＡＣＲである。ＳＳＡシステムは、これらの操作のいずれか１つが試みられるときに、操作を要求するＡＣＲにその権限が付与されている場合に限り、操作を許諾することになる。
２．ＣＥＫ：このＣＥＫの鍵値は、鍵ＩＤが関連付けられたコンテンツ、または、鍵ＩＤによって指示されたコンテンツの暗号化に使用される。鍵値は、ＳＳＡシステムによって生成される１２８ビットＡＥＳランダム鍵であってもよい。
３．ＭＡＣおよびＩＶ値：連鎖ブロック暗号（ＣＢＣ）暗号化アルゴリズムで使用される動的情報（メッセージ認証コードと開始ベクトル）。
図８Ａ〜図１６のフローチャートを参照して、ＳＳＡの様々な機能を例示する。これらの図で、ステップの左側に記された「Ｈ」はホストによって実施される操作を意味し、「Ｃ」はカードによって実施される操作を意味する。メモリカードを参照してＳＳＡ機能を例示するが、物理的形態が異なるメモリ装置にも、これらの機能が当てはまることは理解されよう。システムＡＣＲを作成するため、ホストはメモリ装置１０のＳＳＡに向けて、システムＡＣＲ作成コマンドを発行する（ブロック２０２）。装置１０はこれに応じて、システムＡＣＲが既に存在するかどうかをチェックする（ブロック２０４、菱形２０６）。装置１０は、これが既に存在する場合に失敗ステータスを返し、停止する（長円形２０８）。メモリ１０は、これが既に存在しない場合に、システムＡＣＲの作成が許可されるかどうかをチェックし（菱形２１０）、許可されない場合は失敗ステータスを返す（ブロック２１２）。それゆえ、必要なセキュリティ機能が事前に決まるので、システムＡＣＲが必要とされない場合など、装置発行者がシステムＡＣＲの作成を許可しない場合もある。許可される場合、装置１０はＯＫステータスを返し、ホストからシステムＡＣＲ認証情報が届くのを待つ（ブロック２１４）。ホストはＳＳＡステータスをチェックし、システムＡＣＲの作成が許可されていることを装置１０が伝えているかどうかをチェックする（ブロック２１６および菱形２１８）。作成が許可されないか、あるいはシステムＡＣＲが既に存在する場合、ホストは停止する（長円形２２０）。システムＡＣＲの作成が許可されていることを装置１０が伝える場合、ホストはそのログイン認証情報を設定するＳＳＡコマンドを発行し、これを装置１０へ送信する（ブロック２２２）。装置１０は、受信した認証情報でシステムＡＣＲ記録を更新し、ＯＫステータスを返す（ブロック２２４）。ホストはこのステータス信号に応じて、システムＡＣＲの準備が整っていることを示すＳＳＡコマンドを発行する（ブロック２２６）。これに応じて装置１０はシステムＡＣＲをロックするので、システムＡＣＲの更新や差替えはできなくなる（ブロック２２８）。これにより、システムＡＣＲの機能と、ホストに対して装置１０を識別するためのアイデンティティと、が固定される。
新規ツリー（新規ルートＡＧＰおよびＡＣＲ）の作成手順は、それらの機能が装置でどのように構成されているかによって決まる。図９は、その手順を説明するものである。ホスト２４とメモリシステム１０は、いずれもこの手順を辿る。新規ルートＡＧＰの追加が完全に無効になっている場合、新規ルートＡＧＰを追加することができない（菱形２４６）。これが有効になっているが、システムＡＣＲが要求される場合、ホストはルートＡＧＰ作成コマンドの発行（ブロック２５４）に先立ち、システムＡＣＲを通じて認証し、セキュアチャネルを確立する（菱形２５０、ブロック２５２）。システムＡＣＲが要求されない場合（菱形２４８）、ホスト２４は認証なしでルートＡＧＰ作成コマンドを発行することができ、ブロック２５４へ進む。ホストは、システムＡＣＲが存在する場合、たとえこれが要求されない場合でも、これを使用することがある（フローチャートには示されていない）。装置（例えば、フラッシュカード）は、新規ルートＡＧＰ作成機能が無効になっている場合には、新規ルートＡＧＰを作成する試行を拒絶する。また、システムＡＣＲが要求される場合には、認証なしで新規ルートＡＧＰを作成する試行を拒絶する（菱形２４６および２５０）。ブロック２５４で新たに作成されるＡＧＰおよびＡＣＲは作動モードに切り替わるので、そのＡＧＰの中にあるＡＣＲの更新や変更はできなくなり、ＡＧＰへＡＣＲを追加することもできなくなる（ブロック２５６）。ここでオプションとしてシステムはロックされるので、ルートＡＧＰは追加で作成できなくなる（ブロック２５８）。点線の枠２５８は、このステップがオプションのステップであることを示す表記法である。本出願の図のフローチャートにおいて、点線で示された枠はいずれもオプションのステップである。このように、コンテンツの所有者は、正当なコンテンツを含む真正のメモリ装置を装う違法な目的に、装置１０を利用できないようにすることができる。
ＡＣＲ（前述したルートＡＧＰの中にあるＡＣＲとは別のＡＣＲ）を作成するには、図１０に示すように、ＡＣＲを作成する権利を有するＡＣＲから開始することができる（ブロック２７０）。エンティティは、入口にあたるＡＣＲのアイデンティティと、作成に必要となる属性のすべてを含むＡＣＲとを提供して、ホスト２４を通じて入ることを試行することができる（ブロック２７２）。ＳＳＡは、ＡＣＲアイデンティティの一致をチェックし、さらにそのアイデンティティを有するＡＣＲにＡＣＲを作成する権限があるかどうかをチェックする（菱形２７４）。要求が認証されると証明される場合、装置１０のＳＳＡは、ＡＣＲを作成する（ブロック２７６）。
図１１の２つのＡＧＰは、図１０の方法を使用するセキュリティアプリケーションで役に立つツリーを例示するものである。したがって、マーケティングＡＧＰの中でアイデンティティｍ１を有するＡＣＲには、ＡＣＲを作成する権限がある。ＡＣＲ＿ｍ１は、鍵ＩＤ「マーケティング情報」と関連付けられたデータと、鍵ＩＤ「価格リスト」と関連付けられたデータとを、鍵を用いて読み書きする権限も有する。これにより、図１０の方法を用いて、２つのＡＣＲ＿ｓ１およびｓ２を含む販売ＡＧＰを作成する。ＡＣＲ＿ｓ１およびｓ２には、鍵ＩＤ「価格リスト」と関連付けられた価格データにアクセスするための鍵の読出し権限のみあるが、鍵ＩＤ「マーケティング情報」と関連付けられたデータにアクセスする場合に必要となる鍵の権限はない。このように、ＡＣＲ＿ｓ１およびｓ２を有するエンティティは、価格データを読み出してもこれを変更することはできず、さらにマーケティングデータにはアクセスすることができない。一方、ＡＣＲ＿ｍ２にはＡＣＲを作成する権限がなく、鍵ＩＤ「価格リスト」と鍵ＩＤ「マーケティング情報」とに関連付けられたデータにアクセスするための鍵の読出し権限のみを有する。
それゆえ、アクセス権は前述した方法で委譲することができ、ｍ１は、価格データを読み出す権利をｓ１およびｓ２に委譲する。これは、特に大規模なマーケティング組織や販売組織が関わる場合に有用である。しかし、販売員が１名〜少数であれば図１０の方法を使用する必要はない場合がある。代わりに、図１２に示すように、ＡＣＲから、同じＡＧＰの下位レベルまたは同じレベルに位置するＡＣＲに、アクセス権を委譲することができる。エンティティはまず、そのＡＧＰのツリーに入るため、ホストを通じてツリーの中のＡＣＲを前述したように指定する（ブロック２８０）。次にホストは、ＡＣＲと、委譲する権利と、を指定する。ＳＳＡはツリーでこのＡＣＲをチェックし、指定された別のＡＣＲに権利を委譲する権限がこのＡＣＲにあるかどうかをチェックする（菱形２８２）。権限があれば権利は委譲され（ブロック２８４）、そうでなければ停止する。図１３はその結果を示す。この場合、ＡＣＲ＿ｍ１には読出し権限をＡＣＲ＿ｓ１に委譲する権限があるため、委譲の後、ｓ１は鍵を使用して価格データにアクセスできるようになる。これは、ｍ１が価格データにアクセスするための権利またはそれ以上の権利を有し、さらにそれを委譲する権限を有する場合に実施することができる。一実施形態では、ｍ１は委譲の後にそのアクセス権を保持する。時間やアクセス数を制限するなどにより、（永続的にではなく）一定の条件のもとでアクセス権が委譲されることが好ましい。
図１４は、鍵と鍵ＩＤを作成するプロセスを示す。エンティティは、ＡＣＲを通じて認証を受ける（ブロック３０２）。エンティティは、ホストによって指定されたＩＤによる鍵の作成を要求する（ブロック３０４）。ＳＳＡは、指定されたＡＣＲにその権限があるかどうかをチェックする（菱形３０６）。例えば、ある特定のパーティションにあるデータにアクセスするために鍵が使用される場合、ＳＳＡはそのパーティションにＡＣＲがアクセスできるかどうかをチェックすることになる。ＡＣＲにその権限がある場合、メモリ装置１０は、ホストから提供された鍵ＩＤと関連付けられた鍵値を作成し（ブロック３０８）、鍵ＩＤをＡＣＲに記憶し、鍵値をメモリ（コントローラ関連メモリまたはメモリ２０のいずれか）に記憶し、エンティティから提供された情報に従って権利および権限を割り当て（ブロック３１０）、割り当てられた権利および権限で該当するＡＣＲのＰＣＲを修正する（ブロック３１２）。それゆえ、読出しおよび書込み権限、同じＡＧＰの中にある他のＡＣＲまたは下位レベルのＡＣＲに委譲し共有する権利、鍵の所有権を譲渡する権利など、鍵の作成元はすべての権利を有する。
図１５に示すように、ＡＣＲは、ＳＳＡシステムの中にある別のＡＣＲの権限（またはＡＣＲの存在そのもの）を変更することができる。エンティティは、これまで通りＡＣＲを通じてツリーに入る場合がある。ある事例ではエンティティの認証が行われ、エンティティはＡＣＲを指定する（ブロック３３０、３３２）。エンティティは、ターゲットＡＣＲの削除、または、ターゲットＡＣＲの権限の削除を要求する（ブロック３３４）。指定されたＡＣＲまたはその時点でアクティブなＡＣＲにその権利があれば（菱形３３６）、ターゲットＡＣＲを削除し、あるいはそのような権限を削除するためにターゲットＡＣＲのＰＣＲを変更する（ブロック３３８）。これが認可されない場合、システムは停止する。
前述したプロセスの後、ターゲットは、プロセスの前にアクセスできたデータにアクセスすることができなくなる。図１６に示すように、かつて存在したＡＣＲ＿ＩＤはもはやＳＳＡに存在しないため、ターゲットＡＣＲに入ることを試行する（ブロック３５０）エンティティは認証プロセスの失敗に気付くので、アクセス権は拒絶される場合がある（菱形３５２）。ＡＣＲ＿ＩＤが削除されていないと仮定した場合、エンティティはＡＣＲを指定し（ブロック３５４）、鍵ＩＤおよび／または特定のパーティションのデータを指定し（ブロック３５６）、ＳＳＡはそのようなＡＣＲのＰＣＲに従って鍵ＩＤまたはパーティションアクセス要求が許可されるかどうかをチェックする（菱形３５８）。権限が削除されているか、あるいは失効している場合、要求は再度却下される。そうでない場合、要求は許諾される（ブロック３６０）。
前述したプロセスは、ＡＣＲとそのＰＣＲが別のＡＣＲによって変更された場合であれ、あるいは初めからそのように構成されていた場合であれ、被保護データに対するアクセスが装置（例えば、フラッシュカード）によってどのように管理されるかを説明するものである。
＜セッション＞
ＳＳＡシステムは、同時にログインする複数のユーザを処理するように設計されている。この機能を使用する場合、ＳＳＡによって受信されるコマンドには特定のエンティティが関連しており、コマンドは、このエンティティの認証に用いるＡＣＲに要求された動作を行う権限がある場合に限り実行される。
複数のエンティティは、セッションのコンセプトによってサポートされる。セッションは認証プロセスで確立し、ＳＳＡシステムによってセッションｉｄが割り当てられる。セッションｉｄは、システムへのログインに使用されたＡＣＲに内部で関連付けられ、エンティティへエクスポートされ、それ以降のＳＳＡコマンドで使用される。
ＳＳＡシステムは、２種類のセッション、すなわちオープンセッションとセキュアセッションとをサポートする。特定の認証プロセスと関連付けられたセッションのタイプは、ＡＣＲの中で設定される。ＳＳＡシステムは、認証そのものの施行と同様の方法で、セッション確立を施行する。エンティティの権限はＡＣＲで設定されるため、システム設計者は特定の鍵ＩＤに対するアクセスまたは特定のＡＣＲ管理操作（すなわち、新規ＡＣＲの作成、認証情報の設定）の実行に、セキュアトンネルを関連付けることができる。
＜オープンセッション＞
オープンセッションはセッションｉｄで識別されるセッションであるが、バス暗号化は行われないため、コマンドおよびデータはいずれも暗号化されずに引き渡される。この動作モードは、エンティティが脅威モデルに該当せずバス上で傍受を行わない、多数のユーザまたは多数のエンティティ環境に使用されることが好ましい。
オープン・セッション・モードではデータ送信が保護されず、ホスト側のアプリケーション間に効率的なファイアウォールは実施されないが、ＳＳＡシステムが認証済みのＡＣＲでアクセスできる情報のみにアクセスが許可されうる。
オープンセッションは、パーティションまたは鍵を保護する必要がある場合にも使用することができる。しかしながら、有効な認証プロセスの後には、ホスト側のすべてのエンティティにアクセスが許諾される。様々なホストアプリケーションは、セッションｉｄさえあれば認証済みＡＣＲの権限を得ることができる。これは図１７Ａに例示されている。線４００より上のステップは、ホスト２４によって実行されるステップである。ＡＣＲ１の認証（ブロック４０２）を終えたエンティティは、メモリ装置１０で鍵ＩＤ＿Ｘと関連付けられたファイルへのアクセスを要求する（ブロック４０４、４０６、および４０８）。ＡＣＲ１のＰＣＲがこのアクセスを認める場合、装置１０は要求を許諾する（菱形４１０）。そうでない場合、システムはブロック４０２まで戻る。認証が完了した後、メモリシステム１０は、コマンドを発行するエンティティを、（ＡＣＲ認証情報ではなく）割り当てられたセッションｉｄのみで識別する。オープンセッションでＡＣＲ１がＰＣＲの鍵ＩＤと関連付けられたデータに到達した時点で、他のどのアプリケーションまたはユーザでも、ホスト２４上の様々なアプリケーションによって共有される正しいセッションＩＤを指定することによって、同じデータにアクセスすることができる。この機能は、一度のみログインし、様々なアプリケーションに対してログインに使われたアカウントに結合されたすべてのデータにアクセスできることがユーザにとって好都合な場合のアプリケーションに、有利である。それゆえ、携帯電話のユーザの場合、記憶されたｅメールにアクセスし、ログインを繰り返すことなくメモリ２０に記憶された音楽を聞くことができる。一方、ＡＣＲ１に該当しないデータにはアクセスできないことになる。それゆえ、ゲームや写真等の、同じ携帯電話のユーザにとって貴重となり得るコンテンツは、別のアカウントＡＣＲ２を通じてアクセスされる。これは、携帯電話のユーザの電話を借りる人にアクセスさせたくないデータであるが、携帯電話のユーザにとって、最初のアカウントＡＣＲ１でアクセスできるデータなら他人がアクセスしてもよい。データへのアクセスを２つの別々のアカウントに分け、ＡＣＲ１へのアクセスをオープンセッションで行うことにより、使い易くなるばかりでなく、貴重なデータを保護することができる。
ホストアプリケーション間でのセッションｉｄの共有プロセスをさらに簡単にするには、オープンセッションを要求するＡＣＲが、セッションに「０（ゼロ）」ｉｄを割り当てることを具体的に要求することができる。このように、アプリケーションは所定のセッションｉｄを使用するように設計することができる。当然ながら、セッション０を要求するＡＣＲは、特定の時間において一度に１つしか認証することができないという制限がある。セッション０を要求する別のＡＣＲを認証するための試行は、拒絶されることになる。
＜セキュアセッション＞
セキュリティ層を追加するため、セッションｉｄは図１７Ｂに示すように使用してもよい。このとき、メモリ１０もアクティブセッションのセッションｉｄを記憶する。図１７Ｂで、例えば、鍵ＩＤ＿Ｘと関連付けられたファイルにアクセスするためには、エンティティもセッションｉｄ「Ａ」などのセッションｉｄを提供する必要があり、その上でファイルへのアクセスが許可されることになる（ブロック４０４、４０６、４１２、および４１４）。このように、要求するエンティティは正しいセッションｉｄを知らない限りメモリ１０にアクセスすることができない。セッションｉｄはセッションが終了した後に削除され、セッションのたびに異なるため、エンティティはセッション番号を提供できた場合に限りアクセスすることができる。
ＳＳＡシステムは、コマンドが実際に正しい認証済みエンティティに由来しているかどうかを、セッション番号を使用して追跡する。攻撃者がオープンチャネルを用いて悪質なコマンドを送信しようとするおそれがある用途や使用がある場合、ホストアプリケーションはセキュアセッション（セキュアチャネル）を使用する。
セキュアチャネルを使用するとき、セッションｉｄとコマンド全体がセキュアチャネル暗号化（セッション）鍵により暗号化され、そのセキュリティレベルはホスト側の実施態様と同じように高くなる。
＜セッションの終了＞
セッションは次のシナリオのいずれか１つで終了し、ＡＣＲはログオフされる。
１．エンティティが、明示的なセッション終了コマンドを発行する。
２．通信タイムアウトが発生する。ある特定のエンティティが、ＡＣＲパラメータの１つとして設定された期間にわたってコマンドを発行しなかった。
３．装置（例えば、フラッシュカード）のリセットおよび／またはパワーサイクルの後には、すべてのオープンセッションが終了する。
＜データ完全性サービス＞
ＳＳＡシステムは、ＳＳＡデータベース（ＡＣＲ、ＰＣＲなど、すべてを含む）の完全性を検証する。さらに、鍵ＩＤ機構によるエンティティデータのデータ完全性サービスも提供される。
鍵ＩＤの暗号化アルゴリズムがハッシュモードに設定される場合、ＣＥＫおよびＩＶと併せてハッシュ値がＣＥＫ記録に記憶される。書込み操作中に、ハッシュ値が計算されて記憶される。読出し操作中にも再度ハッシュ値が計算され、前の書込み操作中に記憶された値と比較される。エンティティが鍵ＩＤにアクセスするたびに追加データが古いデータに（暗号的に）連結され、該当するハッシュ値（読出しまたは書込みのため）が更新される。
鍵ＩＤと関連付けられ、あるいは鍵ＩＤによって指示されるデータファイルを知るのはホストのみであるため、データ完全性機能の複数の態様は、ホストが明示的に次のように管理する。
１．鍵ＩＤと関連付けられた、または鍵ＩＤによって指示されるデータファイルは、最初から最後まで書き込まれ、あるいは読み出される。ＳＳＡシステムはＣＢＣ暗号方式を使用し、データ全体のハッシュ化メッセージダイジェストを生成するため、ファイルの一部分にアクセスしようとするとファイルは混乱することになる。
２．中間ハッシュ値はＳＳＡシステムによって維持されるため、連続するストリームの中でデータを処理する必要はない（このデータストリームは他の鍵ＩＤのデータストリームでインターリーブすることができ、複数のセッションにわたって分割されてもよい）。しかしながら、エンティティは、データストリームが再開される場合にハッシュ値をリセットするようＳＳＡシステムに明示的に指示する必要がある。
３．ホストは読出し操作が完了すると、読み出されたハッシュを書込み操作中に計算されたハッシュ値と比較することによって有効にするよう、ＳＳＡシステムに明示的に要求する。
４．ＳＳＡシステムは「ダミー読出し」操作も提供する。この機能によりデータは暗号化エンジンを通過するが、ホストには送出されないことになる。この機能を利用すると、データが実際に装置（例えば、フラッシュカード）から読み出される前に、データの完全性を検証することができる。
＜乱数生成＞
外部エンティティはＳＳＡシステムの内部乱数生成器を利用することができ、乱数をＳＳＡシステムの外部で使用することもできる。このサービスはいずれのホストでも利用することでき、認証を必要としない。
＜ＲＳＡ鍵対生成＞
外部ユーザはＳＳＡシステムの内部ＲＳＡ鍵対生成機能を利用することができ、鍵対をＳＳＡシステムの外部で使用することもできる。このサービスはいずれのホストでも利用することができ、認証を必要としない。
＜代替実施形態＞
階層アプローチを使用する代わりに、図１８に例示するデータベースアプローチを使用して同様の結果を実現することができる。
図１８に示すように、コントローラ１２またはメモリ２０に記憶されるデータベースに入力されたエンティティの認証情報、認証方法、最大失敗数、遮断解除に必要な最小認証情報数のリストは、このような認証情報要件を、メモリ１０のコントローラ１２によって実行されるデータベース内のポリシー（鍵およびパーティションに対する読出し、書込みアクセス、セキュアチャネル要件）に関連付けている。鍵およびパーティションへのアクセスに対する制約事項や制限事項も、データベースに記憶される。こうして、ホワイトリストにある可能性があるエンティティ（例えば、システム管理者）は、すべての鍵およびパーティションにアクセスすることができる。ブラックリストにある可能性があるエンティティによる任意の情報へのアクセスの試行は、阻止される。制限は、全域におよぶ場合と、鍵および／またはパーティションに特異的に適用される場合とがある。これは、特定のエンティティのみが特定の鍵およびパーティションにアクセスでき、特定のエンティティはアクセスできないことを意味する。コンテンツのパーティションや、コンテンツの暗号化または復号化に使用される鍵にかかわらず、コンテンツ自体に制約を課すこともできる。それゆえ、特定のデータ（例えば、曲）にアクセスする可能性がある最初の５つのホスト装置のみにアクセスを許可したり、他のデータ（例えば、映画）にアクセスするエンティティを問わず、データの読出し回数を制限したりすることができる。
＜認証＞
パスワード保護
・パスワード保護は、保護領域にアクセスする場合にパスワードの提示が求められることを意味する。パスワードが１つに限られる場合を除き、それぞれのパスワードには読出しアクセスまたは読出し／書込みアクセスなど、別々の権利を関連付けることができる。
・パスワード保護は、ホストから提供されるパスワードを装置（例えば、フラッシュカード）が検証しうること、すなわち、装置もまた装置によって管理され保護されたメモリ領域にパスワードを記憶することを意味する。
問題および限界
・パスワードはリプレー攻撃を被ることがある。提示のたびに変わらないパスワードは、同じ状態で再送されうる。つまり、保護の対象となるデータが貴重で、通信バスへのアクセスが容易な場合、パスワードを現状のまま使用するべきではない。
・パスワードは記憶データへのアクセスを保護しうるが、（鍵ではなく）データの保護のためにパスワードが使用されるべきではない。
・パスワードに関連するセキュリティレベルを上げるため、親鍵を用いてパスワードを多様化すれば、１つのパスワードがハッキングされてもシステム全体が破壊されることはない。パスワードの送信には、セッション鍵方式のセキュア通信チャネルを使用することができる。
図１９は、パスワードを使用した認証を示すフローチャートである。エンティティは、アカウントｉｄおよびパスワードをシステム１０（例えば、フラッシュメモリカード）へ送信する。システムは、パスワードがそのメモリにあるパスワードに一致するかどうかをチェックする。一致する場合は認証済みステータスが返される。そうでない場合はそのアカウントのエラーカウンタがインクリメントされ、エンティティにはアカウントｉｄおよびパスワードの再入力が求められる。カウンタがオーバーフローすると、システムはアクセス拒絶ステータスを返す。
＜対称鍵＞
対称鍵アルゴリズムは、暗号化と復号化の両側で同じ鍵が使用されることを意味する。これは、通信に先立って、予め鍵を取り決めておくことを意味する。それぞれの側では、相手側の逆のアルゴリズムを実行すべきである。すなわち、一方は暗号化アルゴリズムになり、他方は復号化アルゴリズムになる。通信する場合に両側で両方のアルゴリズムを実行する必要はない。
認証
・対称鍵認証は、装置（例えば、フラッシュカード）およびホストが同じ鍵を共有し、同じ暗号アルゴリズム（ダイレクトおよびリバース、例えば、ＤＥＳおよびＤＥＳ−１）を有することを意味する。
・対称鍵認証は、チャレンジ・レスポンス（リプレー攻撃対策）を意味する。被保護装置が他の装置に対する質問を生成し、両方の装置で回答を計算する。認証を受ける側の装置は回答を返送し、被保護装置はその回答をチェックし、それに応じて認証の正当性を実証する。そして、認証に応じて権利が付与される。
認証には次のものがある。
・外部認証：装置（例えば、フラッシュカード）が外部を認証する。すなわち、装置は所与のホストまたはアプリケーションの認証情報を実証する。
・相互認証：両側で質問を生成する。
・内部認証：ホストアプリケーションが装置（例えば、フラッシュカード）を認証する。すなわち、ホストは、装置がそのアプリケーションにとって真正であるかどうかをチェックする。
システム全体のセキュリティレベルを上げるために（すなわち、１つが低下してもすべてが低下しないようにするため）
・対称鍵には、通常、親鍵を使用した多様化が組み入れられる。
・質問が真正な質問であるようにするため、相互認証により両側からの質問を使用する。
暗号化
対称鍵暗号法はすこぶる効率的なアルゴリズムで、暗号処理する場合に強力なＣＰＵを必要としないため、暗号化にも使用される。
通信チャネルを安全に使用するとき：
・チャネルの安全を確保する（すなわち、全発信データを暗号化し全受信データを復号化する）ために使用されるセッション鍵を、両方の装置が知らなければならない。このセッション鍵は、通常、事前共有秘密対称鍵を使用するか、あるいはＰＫＩを使用して確立される。
・両方の装置が同じ暗号アルゴリズムを知り、実行しなければならない。
＜署名＞
対称鍵を使用してデータに署名することもできる。この場合の署名は、暗号化の部分的な結果である。結果を一部分に留めることで、鍵値を露出することなく必要に応じて何度でも署名することができる。
＜問題および限界＞
対称アルゴリズムは非常に効率的で安全ではあるが、事前共有秘密に基づいている。問題は、この秘密を動的に安全に共有することと、場合により（セッション鍵のように）ランダムにすることである。つまり、共有秘密を長期間にわたって安全に保つのは困難であり、多数の人々と共有することはほぼ不可能である。
この作業を容易にするために、秘密を共有せずに交換できる公開鍵アルゴリズムが考案されている。
＜非対称認証手続き＞
非対称鍵に基づく認証では、一連のコマンドを使用してデータを受け渡ししながら、最終的にはセキュアチャネル通信のためのセッション鍵を作る。その基本的プロトコルでは、ＳＳＡシステムに対してユーザを認証する。多様なプロトコルにより、ユーザが使用したいＡＣＲを検証する相互認証や二因子認証も可能である。
ＳＳＡの非対称認証プロトコルでは、公開鍵基盤（ＰＫＩ）アルゴリズムおよびＲＳＡアルゴリズムを使用することが好ましい。これらのアルゴリズムで規定することで、認証プロセスの各当事者に独自のＲＳＡ鍵対を作成することができる。各対は公開鍵および秘密鍵からなる。これらの鍵は秘匿の鍵であるために、アイデンティティの証拠を提供することはできない。ＰＫＩ層では、信頼された第三者機関が公開鍵の各々に署名することを求められる。この信用機関の公開鍵は、互いを認証する当事者間で事前共有され、当事者の公開鍵を検証するために使用されている。信用が成立すると（両当事者が相手方から提供される公開鍵を信用できると判定すると）、プロトコルによる認証（各当事者が所有する秘密鍵の一致を検証する）と鍵の交換が続行される。これは、後述する図２２および２３のチャレンジ・レスポンス機構によって行うことができる。
署名済みの公開鍵を含む構造は、証明書と称される。証明書に署名した信用機関は、証明機関（ＣＡ）と称される。認証を受ける側は、ＲＳＡ鍵対と公開鍵の信頼性を立証する証明書とを有する。証明書は、相手方（認証する側）が信用する証明機関によって署名される。認証する側には、信用ＣＡの公開鍵の所有が求められる。
ＳＳＡは証明書連鎖に対応する。これは、識別される側の公開鍵が別のＣＡ、すなわち識別する側が信用するＣＡとは異なるＣＡによって署名されることを意味する。この場合の識別される側は、自分自身の証明書のほかに、その公開鍵に署名したＣＡの証明書を提供する。この第２レベルの証明書さえも相手方によって信用されない（信用ＣＡによって署名されていない）場合、第３レベルの証明書を提供することができる。この証明書連鎖アルゴリズムでは、各当事者が公開鍵の認証に必要な証明書の完全なリストを所有する。このことは、図２３および２４に例示されている。この種のＡＣＲによる相互認証に必要な認証情報は、選択された長さを有するＲＳＡ鍵対である。
＜ＳＳＡ証明書＞
ＳＳＡは、［Ｘ．５０９］バージョン３デジタル証明書を採用する。［Ｘ．５０９］は汎用規格であり、ここで説明するＳＳＡ証明書プロファイルは証明書の所定フィールドの内容をさらに指定し、制限する。この証明書プロファイルは、証明書連鎖の管理のために定められた信頼階層と、ＳＳＡ証明書の実証と、証明書失効リスト（ＣＲＬ）プロファイルも規定する。
証明書は公開情報（内部の公開鍵として）とみなされ、したがって、暗号化されない。しかしながら、証明書はＲＳＡ署名を含み、このＲＳＡ署名によって公開鍵やその他すべての情報フィールドが改ざんされていないことを検証する。
［Ｘ．５０９］はＡＳＮ．１規格を使用した各フィールドのフォーマットを定め、ＡＳＮ．１規格ではデータ符号化にＤＥＲフォーマットを使用する。
＜ＳＳＡ証明書の概要＞
図２０および図２１に示されたＳＳＡ証明書管理アーキテクチャの一実施形態は、ホストの無限階層レベルと装置の３階層レベルからなるが、装置で使用する階層レベルは３レベルより多い場合または３レベルより少ない場合がある。
＜ホスト証明書階層＞
装置は、２つの要素、すなわち、装置に記憶されたルートＣＡ証明書（ＡＣＲ認証情報としてＡＣＲの作成時に記憶）と、装置への（その特定のＡＣＲへの）アクセスを試行するエンティティから提供される証明書／証明書連鎖とに基づいて、ホストを認証する。
ホスト証明機関は、それぞれのＡＣＲに対してルートＣＡ（ＡＣＲ認証情報に常駐する証明書）としての役割を果たす。例えば、ある１つのＡＣＲにとってのルートＣＡは「ホスト１＿ＣＡ（レベル２）証明書」であり、別のＡＣＲにとってのルートＣＡは「ホストルートＣＡ証明書」である。各々のＡＣＲに対して、ルートＣＡによって署名された証明書（またはルートＣＡを末端エンティティ証明書までつなげる証明書連鎖）を保持するすべてのエンティティが、末端事業者証明書の対応する秘密鍵を有している場合、そのＡＣＲにログインすることができる。前述のように、証明書は公知であり、秘密にされない。
ルートＣＡによって発行された証明書（ならびに対応する秘密鍵）の所有者は誰でもそのＡＣＲにログイン可能であるということは、ある特定のＡＣＲに対する認証がそのＡＣＲの認証情報に記憶されたルートＣＡの発行者によって決まることを意味する。換言すると、ルートＣＡの発行者がＡＣＲの認証方式を管理するエンティティになりうる。
＜ホストルート証明書＞
ルート証明書は、ログインを試行するエンティティ（ホスト）の公開鍵の検証を開始するためにＳＳＡが使用している信用ＣＡ証明書である。この証明書は、ＡＣＲの作成時にＡＣＲ認証情報の一部として提供される。これはＰＫＩシステムに対する信用の根元にあたるものであり、したがって、信用されたエンティティ（父ＡＣＲ、または製造／構成信頼環境）から提供されることが前提となる。この証明書を検証するＳＳＡは、その公開鍵を使用して証明書の署名を検証する。ホストルート証明書は暗号化された状態で不揮発性メモリ（図１には示されていない）に記憶され、装置の秘密鍵にアクセスできるのは、好ましくは図１のシステム１０のＣＰＵ１２のみである。
＜ホスト証明書連鎖＞
これらの証明書は認証中にＳＳＡへ提供される。連鎖の処理が完了した後にホストの証明書連鎖を再収集して装置に記憶することはすべきでない。
図２０は、多数の異なるホスト証明書連鎖を示す、ホスト証明書レベル階層の概略図である。図２０に示すように、ホスト証明書は多数の異なる証明書連鎖を有することがあり、ここでは３つの証明書連鎖のみが例示されている。
Ａ１．ホストルートＣＡ証明書５０２、ホスト１＿ＣＡ（レベル２）証明書５０４、およびホスト証明書５０６
Ｂ１．ホストルートＣＡ証明書５０２、ホストｎ＿ＣＡ（レベル２）証明書５０８、ホスト１＿ＣＡ（レベル３）証明書５１０、ホスト証明書５１２
Ｃ１．ホストルートＣＡ証明書５０２、ホストｎ＿ＣＡ（レベル２）証明書５０８、ホスト証明書５１４
前述した３つの証明書連鎖Ａ１、Ｂ１、およびＣ１は、ホストの公開鍵が真正であることを証明するために使用されてもよい、３つの考えられるホスト証明書連鎖を例示するものである。前述した証明書連鎖Ａ１と図２０とを参照し、ホスト１のＣＡ（レベル２）証明書５０４の公開鍵はホストルートＣＡの秘密鍵（すなわち、公開鍵のダイジェストを暗号化することによって）によって署名され、この公開鍵はホストルートＣＡ証明書５０２にある。さらに、ホスト証明書５０６のホスト公開鍵は、ホスト１のＣＡ（レベル２）の秘密鍵によって署名され、この公開鍵はホスト１ＣＡ（レベル２）証明書５０４において提供される。したがって、ホストルートＣＡの公開鍵を有するエンティティは、前述した証明書連鎖Ａ１の信頼性を検証できることになる。このエンティティは最初のステップとして、ホストから送信されたホスト１のＣＡ（レベル２）証明書５０４の署名済み公開鍵を、自身が所有するホストルートＣＡの公開鍵を使用して復号化し、復号化した署名済み公開鍵を、ホストから送信されたホスト１のＣＡ（レベル２）証明書５０４の署名されていない公開鍵のダイジェストと比較する。２つが一致する場合、ホスト１のＣＡ（レベル２）の公開鍵は認証され、エンティティは次に、ホストから送信されたホスト証明書５０６の中にあるホスト１のＣＡ（レベル２）の秘密鍵によって署名されたホストの公開鍵を、ホスト１のＣＡ（レベル２）の認証済み公開鍵を使用して復号化することになる。この復号化された署名済みの値が、ホストから送信されたホスト証明書５０６の中にある公開鍵のダイジェストの値に一致する場合、ホストの公開鍵も認証される。証明書連鎖Ｂ１およびＣ１を使用した認証も同様に行われる。
連鎖Ａ１が関わる前述したプロセスから分かるように、ホストから送信されエンティティによって検証される必要のある最初の公開鍵は、ホストルートＣＡ証明書ではなく、ホスト１のＣＡ（レベル２）の公開鍵である。このため、ホストがエンティティへ送信する必要があるものは、ホスト１のＣＡ（レベル２）証明書５０４とホスト証明書５０６であって、ホスト１のＣＡ（レベル２）証明書は連鎖の中で最初に送信される必要があることになる。前述したように、証明書の検証順序は次の通りである。検証する側のエンティティ、すなわちこの場合のメモリ装置１０はまず、連鎖の中で最初の証明書の公開鍵の真性を検証し、この場合のものはルートＣＡの下に位置するＣＡの証明書５０４である。この証明書の公開鍵が真正であることを検証した後、装置１０は次の証明書の検証に進み、この場合のものはホスト証明書５０６である。証明書連鎖が３つ以上の証明書を含む場合の検証順序も同様に、ルート証明書のすぐ下に位置する証明書から始まり、認証の対象となるエンティティの証明書で終わる。
＜装置証明書階層＞
ホストは２つの要素、すなわちホストに記憶された装置ルートＣＡと、装置からホストへ提供される（ＡＣＲの作成時に認証情報として装置に提供される）証明書／証明書連鎖とに基づいて装置を認証する。ホストによる装置の認証プロセスは、前述した装置によるホスト認証プロセスに類似している。
＜装置証明書連鎖＞
これらの証明書は、ＡＣＲの鍵対の証明書である。これらの証明書は、ＡＣＲの作成時にカードに提供される。ＳＳＡはこれらの証明書を個別に記憶し、認証の際にはそれらを１つずつホストに提供する。ＳＳＡは、これらの証明書を使用してホストを認証する。装置は３つの証明書からなる連鎖を処理しうるが、使用される証明書数が３以外になる場合がある。証明書の数は、ＡＣＲによって変わることがある。これは、ＡＣＲが作成されるときに決まる。装置はホストに向けて証明書連鎖を送信しうるが、証明書連鎖データを使用するわけではないので、証明書連鎖を解析する必要はない。
図２１は、記憶装置などのＳＳＡを使用する装置で１〜ｎ種類の証明書連鎖を示す、装置証明書レベル階層の概略図である。図２１に例示されたｎ種類の証明書連鎖は次の通りである。
Ａ２．装置ルートＣＡ証明書５２０、装置１ＣＡ（製造業者）証明書５２２、装置証明書５２４
Ｂ２．装置ルートＣＡ証明書５２０、装置ｎ ＣＡ（製造業者）証明書５２６、装置証明書５２８
ＳＳＡ装置は、それぞれ独自の装置ＣＡ証明書を有する１〜ｎ種類の製造業者によって製造されうる。したがって、ある特定の装置の装置証明書の公開鍵はその異なる製造業者の秘密鍵によって署名され、製造業者の公開鍵は装置ルートＣＡの秘密鍵によって署名される。装置の公開鍵を検証する方法は、前述したホストの公開鍵の場合の方法に類似する。ホストについて前述した連鎖Ａ１の検証の場合と同様に、装置ルートＣＡ証明書を送信する必要はなく、連鎖の中で送信すべき最初の証明書は装置ｉ＿ＣＡ（製造業者）証明書であって、その後に装置証明書が続き、ｉは１〜ｎの整数である。
図２１に示す実施形態において、装置は２つの証明書、つまり装置ｉ＿ＣＡ（製造業者）証明書と、その後に自身の装置証明書とを送信する。装置ｉ＿ＣＡ（製造業者）証明書は、このような装置を製造し、装置の公開鍵に署名するための秘密鍵を提供する製造業者の証明書である。装置ｉ＿ＣＡ（製造業者）証明書を受信したホストは、自身が所有するルートＣＡの公開鍵を使用して装置ｉ＿ＣＡ（製造業者）公開鍵を復号化し、検証する。ホストはこの検証に失敗した場合、プロセスを中断し、認証が失敗したことを装置に通知する。ホストが認証に成功した場合、次の証明書を求める要求を装置へ送信する。この後、装置は自身の装置証明書を送信し、ホストはこれを同様に検証する。
図２２および図２３は、前述した検証プロセスをさらに詳しく示すものである。図２２の「ＳＳＭシステム」は、本明細書で説明するＳＳＡシステムと後述するその他の機能とを実行するソフトウェアモジュールである。ＳＳＭは、ソフトウェアまたはコンピュータコードとして具体化することができ、メモリ２０またはＣＰＵ１２の不揮発性メモリ（図示せず）にデータベースを記憶し、ＲＡＭ＿１２ａに読み込まれてＣＰＵ＿１２によって実行される。
図２２に示すように、装置１０のＳＳＭシステム５４２がホストシステム５４０を認証するプロセスには、３つの段階がある。最初の公開鍵検証段階では、ホストシステム５４０が、ＳＳＭコマンドでホスト証明書連鎖をＳＳＭシステム５４２へ送信する。ＳＳＭシステム５４２は、ホスト証明書５４４の真性とホスト公開鍵５４６の真性を、ＡＣＲ５５０のホストルート証明書５４８にあるルート証明機関公開鍵を用いて検証する（ブロック５５２）。ルート証明機関とホストの間に中間証明機関が介在する場合、中間証明書５４９もブロック５５２の検証に使用される。検証またはプロセス（ブロック５５２）が成功したと仮定し、ＳＳＭシステム５４２は、この後、第２段階へ進む。
ＳＳＭシステム５４２は乱数５５４を生成し、これを質問としてホストシステム５４０に送信する。システム５４０はホストシステムの秘密鍵５４７を使用して乱数５５４に署名し（ブロック５５６）、質問に対する回答として署名済みの乱数を送信する。その回答はホスト公開鍵５４６を使用して復号化され（ブロック５５８）、乱数５５４と比較される（ブロック５６０）。復号化された回答が乱数５５４に一致したと仮定すると、チャレンジ・レスポンスは成功である。
第３段階では、ホスト公開鍵５４６を使用して乱数５６２を暗号化する。この乱数５６２は、この後、セッション鍵となる。ホストシステム５４０は、ＳＳＭシステム５４２からの暗号化数５６２を秘密鍵を使用して復号化（ブロック５６４）することによってセッション鍵を得ることができる。このセッション鍵により、ホストシステム５４０とＳＳＭシステム５４２との間でセキュア通信が開始されうる。図２２に示す一方向非対称認証では、装置１０のＳＳＭシステム５４２によってホストシステム５４０が認証される。図２３は、図２２の一方向認証プロトコルに類似した双方向相互認証プロセスを示すプロトコル図であり、図２３ではＳＳＭシステム５４２もホストシステム５４０によって認証される。
図２４は、本発明の一実施形態を例示する証明書連鎖５９０の図である。前述したように、検証する場合に提示する必要がある証明書連鎖は、多数の証明書を含むことがある。図２４の証明書連鎖は全部で９つの証明書を含み、認証する場合にはこれらの証明書をすべて検証することが必要となる場合がある。背景技術の節で先に説明したように、既存の証明書検証システムでは、送信される証明書連鎖に不備があったり、証明全体が送信されたり、証明書が特定の順序で送信されないと、受信側は証明書を一通り受信し記憶するまで証明書を解析することができない。しかし、連鎖に含まれる証明書の数は事前に分からないため、問題が生じることがある。長さが不確かな証明書連鎖を記憶するために大量の記憶容量を確保する必要になることがある。これは検証を実施する記憶装置にとって問題になることがある。
本発明の一実施形態は、証明書連鎖が記憶装置によって検証される順序と同じ順序でホスト装置がその証明書連鎖を送信するシステムによって、この問題を軽減できるという認識に基づく。それゆえ、図２４に示すように、証明書の連鎖５９０は、ホストルート証明書のすぐ下に位置する証明書５９０（１）から始まり、ホスト証明書である証明書５９０（９）で終わる。したがって、装置１０はまず、証明書５９０（１）で公開鍵を検証し、その後に証明書５９０（２）で公開鍵の検証などを行い、最後に証明書５９０（９）でホスト公開鍵を検証する。これで、証明書連鎖５９０全体の検証プロセスは完了する。それゆえ、ホスト装置が証明書連鎖５９０を検証と同じ順序でメモリ装置１０へ送信する場合、メモリ装置１０は証明書を受信するたびに検証を開始することができ、連鎖５９０に含まれる９つの証明書全部が受信されるまで待つ必要はない。
それゆえ、ホスト装置は、一実施形態において、メモリ装置１０に対して連鎖５９０の証明書を一度に１つずつ送信する。メモリ装置１０は、一度に１つの証明書を記憶することになる。連鎖の中の最後の証明書を除き、検証済みの証明書は、ホストから送信される次の証明書で上書きすることができる。このように、メモリ装置１０には、いつも１つだけの証明書を記憶する容量を確保する必要がある。
メモリ装置は、連鎖５９０全体が受信されていることを知る必要がある。それゆえ、最後の証明書５９０（９）には、これが連鎖の中で最後の証明書であることを伝える標識または標示を含んでいることが好ましい。これを例示する図２５の表は、ホストからメモリ装置１０へ送信される証明書バッファに先行する制御セクタ内の情報を示す。図２５に示すように、証明書５９０（９）の制御セクタには、引数名「最終」フラグがある。メモリ装置１０は、「最終」フラグが設定されているかどうかをチェックして受信した証明書が連鎖における最終証明書であるかどうかを判定することにより、連鎖の中で証明書５９０（９）が最後の証明書であることを検証することができる。
代替的な実施形態では、連鎖５９０の証明書を１つずつ送信するのではなく、１つ、２つ、または３つの証明書からなるグループで送信してもよい。当然ながら、グループで使用する証明書の数は異なる場合も、あるいは同じになる場合もある。それゆえ、連鎖５９０には５つの連続する証明書列５９１、５９３、５９５、５９７、および５９９がある。それぞれの列は、少なくとも１つの証明書を含む。ある１つの証明書の列には、連鎖の中で該当する１列の先行列に隣接する証明書（先頭証明書）と、連鎖の中で該当する１列の後続列に隣接する証明書（終端証明書）と、先頭証明書と終端証明書との間にある全ての証明書が含まれる。例えば、列５９３の中には、全部で３つの証明書５９０（２）、証明書５９０（３）、および証明書５９０（４）がある。メモリ装置１０による５つの証明書の列の検証は５９１、５９３、５９５、５９７の順で行われ、５９９で終わる。したがって、５つの列がメモリ装置１０によって実施される検証と同じ順序で送信され、受信される場合、検証済みの列をメモリ装置で記憶する必要はなくなり、最後の列を除く列はいずれも、ホストから到着する次の列で上書きされうる。前の実施形態と同様に、連鎖内の最後の証明書には標識、例えばこれが連鎖における最後の証明書であることを伝える特定の値に設定されたフラグを含むことが望ましい。この実施形態では、メモリ装置は、５つの列のうち、証明書数が最も多い列の証明書を記憶する十分な容量を確保するだけでよい。それゆえ、ホストが送ろうとする列のうちの最も長い列を事前にメモリ装置１０に知らせる場合、メモリ装置１０は、最も長い列のための十分な容量を確保するだけでよい。
ホストによって送信される連鎖の中の各証明書の長さは、その証明書によって証明される公開鍵の長さの４倍以下であることが好ましい。同様に、メモリ装置の公開鍵を証明するためにメモリ装置１０からホスト装置へ送信される証明書の長さは、その証明書によって証明される公開鍵の長さの４倍以下であることが好ましい。
図２６のフローチャートは、前述した証明書連鎖検証の実施形態を示すものであり、ここでは簡単にするために、各グループ内の証明書数を１と仮定する。図２６に示すように、ホストは、カードに向けて連鎖内の証明書を順次送信する。連鎖の中の第１の証明書（前述したように、通常はルート証明書の後続証明書）から始まって、カードは、認証の対象となるホストから証明書連鎖を順次受信する（ブロック６０２）。そしてカードは、受信する証明書の各々を検証し、証明書のいずれかで検証に失敗した場合はプロセスを中止する。カードは、証明書のいずれかで検証に失敗した場合、ホストに通知する（ブロック６０４、６０６）。この後、カードは、最後の証明書が受信され検証されたかどうかを検出する（菱形６０８）。最終証明書が受信されずに検証されていなければ、カードはブロック６０２まで戻り、ホストからの証明書の受信および検証を続ける。最終証明書が受信されて検証されれば、カードは証明書検証の後に続く次の段階へ進む（６１０）。図２６とそれ以降の図の内容は、例としてメモリカードについて言及しているが、物理的形態がメモリカードではないメモリ装置にもこれらの内容が適用されうることは理解されよう。
図２７は、カードがホストを認証するときに、ホストによって実行されるプロセスを示す。図２７に示すように、ホストは、連鎖の中の次の証明書をカードに送信する（ブロック６２０）（典型的に、ルート証明書の後続証明書から始まる）。ホストは、認証の失敗を伝える中止通知がカードから受信されているかどうかを判定する（菱形６２２）。中止通知が受信されていれば、ホストは停止する（ブロック６２４）。中止通知が受信されていなければ、ホストは送信された最後の証明書で「最終フラグ」が設定されているかどうかをチェックすることにより、連鎖の最終証明書が送信済みかどうかを確認する（菱形６２６）。最終証明書が送信済みであれば、ホストは証明書検証の後に続く次の段階に進む（ブロック６２８）。図２２および２３に示すように、次の段階はチャレンジ・レスポンスであり、その後にセッション鍵の作成が続いてもよい。連鎖の最終証明書が送信済みでなければ、ホストはブロック６２０まで戻り、連鎖内の次の証明書を送信する。
図２８および図２９は、カードが認証されるときに、カードおよびホストが取るアクションを示す。図２８に示すように、カードは開始後、連鎖の中で証明書の送信を求めるホストからの要求を待つ（ブロック６３０、菱形６３２）。ホストから要求が受信されなければ、カードは菱形６３２に戻ることになる。ホストから要求が受信される場合、カードは連鎖の中の次の証明書を送信することになり、これは送信されるべき最初の証明書から始まる（典型的に、ルート証明書の後続証明書から始まる）（ブロック６３４）。カードは、ホストから失敗通知が受信されたかどうかを判定する（菱形６３６）。失敗通知が受信されている場合、カードは停止する（ブロック６３７）。失敗通知が受信されていない場合、カードは最終証明書が送信済みかどうかを判定する（菱形６３８）。最終証明書が送信済みでなければ、カードは菱形６３２まで戻り、連鎖内の次の証明書の送信を求める次の要求をホストから受信するまで待つ。最終証明書が送信済みであれば、カードは次の段階に進む（ブロック６３９）。
図２９は、カードが認証されるときにホストが取るアクションを示す。ホストは、連鎖内の次の証明書を求める要求をカードに送り、これは送信されるべき最初の証明書に対する要求から始まる（ブロック６４０）。ホストは、この後、受信する各々の証明書を検証し、検証に失敗した場合はプロセスを中止し、カードに通知する（ブロック６４２）。検証に合格した場合、ホストは最終証明書が受信済みで検証に成功しているかどうかをチェックする（菱形６４４）。最終証明書が受信されておらず検証が成功していなければ、ホストはブロック６４０まで戻り、連鎖内の次の証明書を求める要求を送信する。最終証明書が受信済みで検証が成功している場合、ホストは証明書検証に続く次の段階に進む（ブロック６４６）。
＜証明書失効＞
発行された証明書は、その有効期間全体にわたって使用されることが予想される。しかし、様々な事情から、有効期間の満了の前に証明書が無効になる場合がある。名称の変更、対象とＣＡとの関係の変化（例えば、従業員の退職）、対応する秘密鍵の侵害または侵害の疑い等がこれにあたる。このような場合には、ＣＡが証明書を無効にする必要がある。
ＳＳＡにおける証明書の失効には別の方法があり、ＡＣＲは各々が別々の証明書失効制度によって構成されうる。まず、失効制度をサポートしない形にＡＣＲを構成することができる。この場合の各証明書は、有効期限まで有効とみなされる。証明書失効リスト（ＣＲＬ）を使用することもできる。さらに別の代案として、後述するようにある特定のアプリケーションに失効制度を限定する、つまりアプリケーション別の限定となるようにしてもよい。ＡＣＲでは、失効値を指定することによって、３つの失効制度のどれが採用されているかを指定する。失効制度なしで作成されたＡＣＲでは、そのＡＣＲの所有者が決定する失効制度を採用することができる。メモリ装置証明書の失効は、ＳＳＡセキュリティシステムではなくホストによって執行される。ホストルート証明書の失効管理はＡＣＲの所有者が担当し、これはＡＣＲの認証情報を更新することによって行われる。
＜証明書失効リスト（ＣＲＬ）＞
ＳＳＡシステムで失効制度を使用するには、各ＣＡが証明書失効リスト（ＣＲＬ）と呼ばれる署名済みデータ構造を定期的に発行する。ＣＲＬは、失効した証明書を識別するタイムスタンプ付きリストであり、ＣＡ（該当する証明書を発行したＣＡ）によって署名され、一般に公開されて自由に利用することができる。ＣＲＬの中では、失効した証明書を、それぞれの証明書通し番号で識別する。ＣＲＬのサイズは、任意なものであって、期限切れ前に失効する証明書の数で決まる。（例えば、ホストのアイデンティティを検証するために）証明書を使用する装置は、証明書の署名（ならびに有効性）をチェックするだけでなく、ＣＲＬを通じて受信された通し番号のリストにこれを照らして検証する。証明書の発行元にあたるＣＡから発行されるＣＲＬでその証明書の識別情報、例えば、通し番号が見つかる場合、これは、その証明書が失効し、もはや有効でないことを意味する。
証明書の有効性を検査する目的をＣＲＬで果たすには、ＣＲＬについても、これが真正であることを検証する必要がある。ＣＲＬには、その発行元にあたるＣＡの秘密鍵を使用して署名し、ＣＡの公開鍵を使用して署名済みＣＲＬを復号化することによってこれが真正であることを検証することができる。復号化されたＣＲＬが、無署名ＣＲＬのダイジェストに一致する場合、そのＣＲＬに改ざんがなく、真正であることを意味する。ＣＲＬのダイジェストを得るためにハッシュアルゴリズムを使用して頻繁にＣＲＬのハッシュ計算が行われ、そのダイジェストはＣＡの秘密鍵で暗号化される。ＣＲＬが有効かどうかを検証するには、ＣＡの公開鍵を使用して署名済みＣＲＬ（すなわち、ハッシュ化および暗号化されたＣＲＬ）を復号化し、復号化されハッシュ化されたＣＲＬ（すなわち、ＣＲＬのダイジェスト）を得る。そして、これをハッシュ化ＣＲＬと比較する。それゆえ、検証プロセスでは、復号化されハッシュ化されたＣＲＬとの比較のためのＣＲＬのハッシュ計算ステップを頻繁に伴うことがある。
ＣＲＬ方式の特徴の１つとして、（ＣＲＬを使用した）証明書の妥当性の検証は、ＣＲＬの入手とは別に実施することができる。ＣＲＬもまた適切な証明書の発行元によって署名され、証明書の検証と同様に、ＣＲＬの発行元にあたるＣＡの公開鍵を使用して前述したように検証される。メモリ装置は、署名がＣＲＬのものであることを検証し、さらにＣＲＬの発行元と証明書の発行元との一致を検証する。ＣＲＬ方式の別の特徴として、ＣＲＬは証明書自体と全く同じ方法で、（具体的には信頼性のないサーバと信頼性のない通信を通じて、）提供することができる。Ｘ．５０９規格には、ＣＲＬとその特徴が詳述されている。
＜ＣＲＬのためのＳＳＡ基盤＞
ＳＳＡは、ＣＲＬ方式を使用したホスト失効のための基盤を提供する。ＣＲＬ失効制度を採用するＲＳＡ方式ＡＣＲで認証するとき、ホストは、Ｓｅｔ Ｃｅｒｔｉｆｉｃａｔｅコマンドに対して追加のフィールドとして、１つのＣＲＬ（恐らく、発行元ＣＡによって無効にされた証明書がない場合は空のＣＲＬ）を加える。このフィールドには、証明書の発行元によって署名されたＣＲＬが含まれる。このフィールドが存在する場合、メモリ装置１０は最初にＳｅｔ Ｃｅｒｔｉｆｉｃａｔｅコマンドで証明書を検証する。ＣＲＬリポジトリの入手とアクセスは、全面的にホストが担当する。ＣＲＬが有効であり続ける期間（ＣＲＬ有効期間、すなわちＣＥＴ）も、ＣＲＬと併せて発行される。現在の時間がこの期間から外れていることが検証中に判明すると、そのＣＲＬには不備があるとみなされ、証明書の検証に使用することはできない。その結果、証明書の認証は失敗する。
従来の証明書検証方法では、認証する側または検証する側のエンティティが、証明書失効リストを所有しているかあるいは証明機関（ＣＡ）から取り込むことができ、認証のために提示される証明書の通し番号をリストに照らしてチェックし、提示された証明書が失効しているかどうかが判定されるはずである。認証または検証する側のエンティティがメモリ装置の場合、そのメモリ装置自体が使用されなかったら、ＣＡから証明書失効リストが取り込まれていない可能性がある。装置に予め記憶された証明書失効リストが時間を経て古くなると、インストールされた日より後に失効した証明書はリストに現れない。その結果、ユーザは、失効した証明書を使用してその記憶装置にアクセスすることになる。これは望ましくない。
一実施形態において、認証を受けようとするエンティティが、認証の対象となる証明書と併せて証明書失効リストを、認証する側のエンティティ（例えばメモリ装置１０）に提示するシステムによって、前述した問題を解決できる可能性がある。認証する側のエンティティは、受信した証明書の信頼性と証明書失効リストの信頼性を検証する。認証する側のエンティティは、失効リストで証明書の識別情報の有無、例えば証明書の通し番号の有無をチェックすることにより、証明書が失効リストに登記されているかどうかをチェックする。
前述したことを踏まえ、ホスト装置とメモリ装置１０との相互認証に、非対称認証方式を使用することができる。メモリ装置１０の認証を受けようとするホスト装置は、証明書連鎖および対応するＣＲＬの両方を提供する必要がある。一方、ホスト装置は予めＣＡに接続してＣＲＬを入手しているため、ホスト装置がメモリ装置１０を認証するとき、メモリ装置は、証明書または証明書連鎖と併せて、ＣＲＬをホスト装置に提示する必要はない。
種々の内蔵または独立型ミュージックプレーヤ、ＭＰ３プレーヤ、携帯電話機、個人用携帯情報端末、およびノートブックコンピュータなど、近年コンテンツの再生に使用できる種々のタイプの携帯型装置は増えている。証明機関から証明書検証リストへアクセスするため、そのような装置をワールド・ワイド・ウェブに接続することは可能であるが、多数のユーザは典型的に、ウェブに毎日接続するのではなく、例えば数週間に一度、新たなコンテンツを入手したり契約を更新したりするときに、これを行う。そのようなユーザにとって、証明機関からより頻繁に証明書失効リストを入手するのは面倒な場合がある。そのようなユーザについて、証明書失効リスト、さらに必要であれば被保護コンテンツへアクセスする場合に記憶装置に提示する必要のあるホスト証明書を、好ましくは記憶装置自体の非保護領域に記憶してもよい。多くのタイプの記憶装置（例えば、フラッシュメモリ）で、記憶装置の非保護領域は、記憶装置自体によって管理されるのではなく、ホスト装置によって管理される。これにより、ユーザはより新しい証明書失効リストを入手するため（ホスト装置を通じて）ウェブに接続する必要がない。ホスト装置は、記憶装置の非保護領域からそのような情報を検索し、その後、記憶装置またはメモリ装置に証明書とリストを提示して、記憶装置の被保護コンテンツにアクセスすることができる。被保護コンテンツにアクセスするための証明書とその対応する証明書失効リストは、典型的に一定の期間にわたって有効であるため、それらが有効である限り、ユーザは最新の証明書または証明書失効リストを入手する必要はない。このため、ユーザは、適度に長い期間にわたって有効な証明書と証明書失効リストを容易く入手でき、最新情報を得るために証明機関に接続する必要はない。
図３０および図３１のフローチャートには、前述したプロセスが示されている。図３０に示すように、ホスト２４は、認証のためにメモリ装置に提示する証明書に付随するＣＲＬを、メモリ装置１０の非保護公開領域から読み出す（ブロック６５２）。ＣＲＬはメモリの非保護領域に記憶されているため、ホストによるＣＲＬの入手より前に認証は必要でない。ＣＲＬはメモリ装置の公開領域に記憶されているため、ＣＲＬの読出しはホスト装置２４によって管理される。そして、ホストは、ＣＲＬを検証の対象となる証明書と併せてメモリ装置へ送信し（ブロック６５４）、メモリ装置１０から失敗通知を受け取らなければ次の段階へ進む（ブロック６５６）。図３１を参照し、メモリ装置はホストからＣＲＬおよび証明書を受信し（ブロック６５８）、ＣＲＬにおける証明書通し番号の有無やその他の点（例えば、ＣＲＬが失効しているかどうか）をチェックする（ブロック６６０）。証明書通し番号がＣＲＬで見つかるか、あるいはその他の理由で失敗に終わる場合、メモリ装置はホストに失敗通知を送信する（ブロック６６２）。このように、同じＣＲＬを異なるホストの認証に使用できるため、それぞれのホストはメモリ装置の公開領域に記憶されたＣＲＬを入手することができる。前述したように、ＣＲＬを使用して検証する証明書もまた、ユーザの便宜を図るため、メモリ装置１０の非保護領域に、ＣＲＬと併せて記憶されていることが好ましい。しかしながら、メモリ装置に対して認証する場合に証明書を使用できるホストは、証明書の発行を受けたホストのみである。
図３２に示すように、ＣＲＬのフィールドに次回の更新時間が含まれる場合、装置１０のＳＳＡは、現在の時間をこの時間に照らしてチェックし、現在の時間がこの時間を過ぎているかどうかを確認し、過ぎている場合は認証が失敗する。それゆえ、ＳＳＡは、現在の時間（またはメモリ装置１０でＣＲＬを受信した時間）に照らしてＣＥＴをチェックするばかりでなく、次回更新の時間もチェックすることが好ましい。
前述したように、ＣＲＬに含まれる失効済み証明書の識別情報のリストが長くなると、リストの処理（例えば、ハッシュ計算）と、ホストによって提示される証明書の通し番号の検索とに時間を要し、処理と検索が順次に行われる場合は特に時間がかかる。それゆえ、このプロセスを加速するために、処理と検索とを同時に行ってもよい。さらに、ＣＲＬの全体を受信した後でないとＣＲＬの処理と検索にかかれない場合にも、プロセスに時間がかかることがある。本出願人らは、ＣＲＬの一部分を受信の時点で（その都度）処理し検索すれば、ＣＲＬの最終部分を受信するときにはプロセスは完了間際となり、プロセスが捗ることに気付いた。
図３３および図３４は、前述した失効制度の特徴を示す。認証する側のエンティティ（例えば、メモリカードなどのメモリ装置）では、認証を受けようとするエンティティから、証明書およびＣＲＬを受信する（ブロック７０２）。暗号化されていないＣＲＬの一部分を処理し（例えば、ハッシュ化し）、それと同時に、提示された証明書の識別情報（例えば、通し番号）をそのような部分で検索する。処理された（例えば、ハッシュ化された）ＣＲＬ部分は、ハッシュ化された完全ＣＲＬにコンパイルされ、完全に復号化されハッシュ化されたＣＲＬと比較される。完全に復号化されハッシュ化されたＣＲＬは、認証を受ける側のエンティティから受信した復号化されたＣＲＬ部分をコンパイルすることによって、形成される。一致しないことが比較で明らかになる場合、認証は失敗に終わる。また、認証する側のエンティティは、現在の時間に照らして、ＣＥＴと次回更新時間の両方をチェックする（ブロック７０６、７０８）。提示された証明書の識別情報がＣＲＬに記載されていることが判明した場合、あるいは現在の時間がＣＥＴの範囲内にない場合、あるいはＣＲＬの次回更新時間が過ぎている場合にも、認証は失敗に終わる（ブロック７１０）。ハッシュ化されたＣＲＬ部分と、復号化されハッシュ化されたＣＲＬ部分とを、組み立てるために記憶する場合、大量の記憶容量を必要としない場合がある。
認証を受けようとするエンティティ（例えば、ホスト）は、その証明書とＣＲＬを、認証する側のエンティティへ送信し（ブロック７２２）、次の段階へ進む（ブロック７２４）。これは図３４に示されている。
エンティティが認証のために証明書連鎖を提示する場合にも、前述したものと同様のプロセスを実施することができる。この場合、連鎖の中の各証明書とその対応するＣＲＬにつき、前述したプロセスを繰り返す必要がある。各証明書とそのＣＲＬを受信したら、その都度処理することができ、証明書連鎖の残りの部分とその対応するＣＲＬの受信を待たなくてよい。
前述の一部の実施形態では、認証を受けることを望むホストまたはエンティティは、認証の対象となる証明書と併せて、証明書失効リストを認証する側のエンティティに提示する。これらの実施形態では、証明機関から証明書失効リストを取り込むことができない不揮発性記憶装置に、エンティティの認証時に更新された証明書失効リストを利用することができる。しかしながら、これらの実施形態では、ホストを頼りに最新の証明書失効リストを提供し、ホストは証明機関から証明書失効リストを取り込むことができることを前提としている。非接続ホスト、例えばＭＰ３プレーヤは、認証中に不揮発性記憶装置に提示するための最新の証明書失効リストを取り込むことができないことがある。その結果、非接続ホストは、認証プロセス中に不揮発性記憶装置に、証明書失効リストの古いバージョンを提示してよい。
別の実施形態では、不揮発性記憶装置に提示される証明書失効リストの最新バージョンを記憶（キャッシュ）することによって、この問題が回避される。新たに製造されるカードは、製造中に得られる最新または現在の証明書失効リストがプログラムされてもよい。認証中にホストがキャッシュされた失効リストを提供しない場合には、このキャッシュされた失効リストを不揮発性記憶装置に使用してもよい。さらに、ホスト装置が同じ機関から発行された証明書失効リストの古いバージョンを提示するとき、不揮発性記憶装置は、その記憶された証明書失効リストを使用してもよい。また、不揮発性記憶装置では、認証を受けることを求めるホストまたはエンティティから更新された証明書失効リストを提示されるとき、その証明書失効リストをオポチュニスティックに更新してもよい。それゆえ、別の実施形態では、証明書が失効しているかどうかを判定する方法および不揮発性記憶装置が開示される。この実施形態では、不揮発性記憶装置は、ホストのこの装置への認証を試行するために、ホストから証明書を受信する。不揮発性記憶装置は、証明書失効リストを含み、ホストに動作可能に結合される。そして、不揮発性記憶装置は、証明書失効リストの中にある証明書のリファレンスを検索することによって、証明書が失効しているかどうかを判定する。この実施形態では、証明書失効リストは、不揮発性記憶装置がホストから不揮発性記憶装置への認証を試行するために証明書を受信する前にキャッシュされて最新とされる。証明書失効リストの中にある証明書に対するリファレンスが、検索によって生成されると、ホストによる認証の試行は拒絶される。
不揮発性記憶装置がホストから証明書失効リストを受信すると、不揮発性記憶装置は、ホストから受信した証明書失効リストを検証し、受信された証明書失効リストが不揮発性記憶装置の中にある現在の証明書失効リストよりも新しいかどうかを判定する。受信された証明書失効リストが検証されて、不揮発性記憶装置の中にある現在の証明書失効リストよりも新しければ、現在の証明書失効リストはホストから受信された新しい証明書失効リストに置換される。そして、不揮発性記憶装置に過去に記憶された現在の証明書失効リストを使用する代わりに、新しい証明書失効リストが使用されて、ホストからの証明書が失効しているかどうかが判定される。
不揮発性記憶装置がホストから証明書失効リストを受信し、不揮発性記憶装置がその発行機関からの証明書失効リストを現在記憶していない場合、不揮発性記憶装置が首尾よく検証されているならば、不揮発性記憶装置は受信された証明書失効リストを記憶し使用する。
証明書失効リストは、証明書失効リストを記憶する専用のメモリの領域などの、不揮発性記憶装置１０のメモリの中に記憶されてもよい。一実施形態では、証明書失効リストは、証明書失効リストのデータベースに記憶されてもよい。証明書失効リストを記憶するデータベース、メモリ、または記憶容量は、例えば、アクセス権限のないエンティティによる証明書失効リストの変更や削除を防止するように保護されてもよい。
これまでに一般的に説明した上記実施形態のほかに、以下の段落では、採用しうる具体的な実施形態を提示する。この実施形態は単なる例であって、本明細書に記載する詳細は、本明細書において明示的に列挙されない限り、特許請求の範囲に引用されるはずがないことに留意されたい。この具体的な実施形態では、証明書失効リストがアクセス制御記録（ＡＣＲ）に関連付けられる。エンティティがＡＣＲを用いて認証される場合、関連付けられた証明書失効リストは、提示された証明書が失効しているかどうかを判定するためにチェックされる。ＣＲＬを利用するこのようなＡＣＲを作成する場合、初期のＣＲＬを受信してＡＣＲと関連付けることができる。この実施態様を図４９と関連させて説明する。
図４９は、証明書失効リストを用いてアクセス制御記録を構成する、例示的なステップ４９００を示すフローチャートである。例示的ステップ４９００は、新たなＡＣＲを作成または構成するために利用されるプロセスの一部であってもよい。制御は、ステップ４９０２で開始する。制御はステップ４９０８に進み、ここで、作成されているＡＣＲが１つまたは複数のキャッシュＣＲＬをサポートするか、それともこのＣＲＬに関連付けられるかが判定される。作成されているＡＣＲがキャッシュＣＲＬをサポートしなければ、制御はＡＣＲの作成および構成を終了するためにステップ４９０４に進み、この後、ＡＣＲが作成されて構成されると、ステップ４９０６に進む。作成されているＡＣＲがキャッシュＣＲＬをサポートする場合、制御はステップ４９０８からステップ４９１０に進み、ここでＣＲＬデータが、ＡＣＲを作成するエンティティから受信される。ステップ４９１２において、受信されたＣＲＬデータは、キャッシュＣＲＬデータベースにキャッシュされる。制御はステップ４９１４に進み、ここでＣＲＬデータのすべてが受信されているかどうかが判定される。ＣＲＬデータのすべてがまだ受信されていなければ、制御はステップ４９１４からステップ４９１０に進み、ステップ４９１０、４９１２、および４９１４はＣＲＬデータのすべてが受信されるまで繰り返される。ステップ４９１０、４９１２、および４９１４は大量のセクタのＣＲＬデータの受信を表しているが、ビット、バイト、ワード、および長いワードなどの他のインクリメントのＣＲＬデータを受信することも可能である。ＣＲＬデータのすべてが受信されている場合、制御はステップ４９１４からステップ４９１６に進み、ここで、受信されたＣＲＬがキャッシュＣＲＬとしてＡＣＲと関連付けられて解析される。制御は、この後、ＡＣＲの作成および構成を終了するためにステップ４９０４に進み、さらに、ＡＣＲが作成されて構成された後、ステップ４９０６に進む。ステップ４９００は、１つのＣＲＬとＡＣＲの関連を示しているが、証明書連鎖に対する複数のＣＲＬが受信され、キャッシュされ、ＡＣＲと関連付けられてもよい。
図５０は、認証中に、不揮発性記憶装置にキャッシュされあるいはこの装置に提供される証明書失効リストを使用して不揮発性記憶装置を認証する、例示的なステップを示すフローチャートである。例示的なステップ５０００は、不揮発性記憶装置によりエンティティを認証するステップの一部分または一側面であってもよい。制御は、ステップ５０００で開始する。ステップ５００４に進み、ここで、認証に使用されるアカウントまたはＡＣＲがチェックされて、これがキャッシュＣＲＬをサポートするか、それともキャッシュＣＲＬに関連付けられるかを判定する。ＡＣＲがキャッシュＡＣＲと関連付けられなければ、制御はステップ５００６に進む。ＡＣＲがキャッシュＣＲＬと関連付けられなければ、認証を求めるホストまたはエンティティは、証明書と併せてＣＲＬを提供しなければならない。ステップ５００６は、証明書を処理するときに使用されるＣＲＬを、ホストが提供しているかどうかを試験する。ホストがＣＲＬを提供していなければ、制御は５００８に進み、証明書が引き続き有効かどうかを判定するためのＣＲＬが不揮発性記憶装置に提供されておらず、当該ＣＲＬにアクセスできないため、認証は失敗する。ホストがＣＲＬを提供していれば、制御はステップ５００６からステップ５０１０に進み、ここでＣＲＬが処理されて証明書が失効しているかどうかが判定される。制御はこの後ステップ５０１２に進み、他の認証処理を再開するか、または終了する。
ＡＣＲがキャッシュＣＲＬをサポートするように構成される場合、制御はステップ５００４からステップ５０１４に進む。ステップ５０１４は、認証を求めるホストからＣＲＬヘッダが受信されているかを判定する。認証を求めるホストからＣＲＬヘッダが受信されていなければ、制御はステップ５０２２に進み、ここで不揮発性記憶装置はキャッシュＣＲＬ（キャッシュＣＲＬが証明機関から得られる場合）を使用してホストが提示する証明書を検証し、証明書が失効しているかどうかを判定する。さらに、制御はステップ５０１２に進み、他の認証処理を再開するかまたは終了する。図には示されていないが、不揮発性記憶装置により使用されるキャッシュＣＲＬが得られなければ、認証は失敗する。
認証を求めるホストがＣＲＬヘッダを提供している場合、ステップ５０００は、不揮発性記憶装置が同じ証明機関からのＣＲＬを現在記憶しているかどうか、および、記憶している場合には、キャッシュＣＲＬがホストが提示しようとしているＣＲＬよりも新しいためにキャッシュＣＲＬが認証に使用されるべきかどうか、を判定しなければならない。それゆえ、制御はステップ５０１４からステップ５０１６に進む。ステップ５０１６において、ＣＲＬヘッダは、ＣＲＬのバージョンとＣＲＬの発行者に関する情報を抽出するために、解析される。
ステップ５０１８において、抽出されたＣＲＬ発行者情報は、同じ発行者（証明機関）からのキャッシュＣＲＬがＡＣＲと関連付けられているかどうかを判定するために、キャッシュＣＲＬ情報と比較される。例えば、ＡＣＲは複数のＣＲＬと関連付けられてもよい。ＡＣＲが作成されるとき、あるいは装置が製造されるとき、ＡＣＲは発行者Ｘにより発行されたキャッシュＣＲＬを有していてもよい（あるいは、キャッシュＣＲＬが全くなくてよい）。不揮発性記憶装置がフィールドにあるとき、ＡＣＲを認証するホストは、発行者Ｙにより発行されたＣＲＬを提示してもよい。この例で適用されるようなステップ５０１８は、ＡＣＲが発行者Ｙにより発行されたＣＲＬを有していないことを確認し、発行者ＹからのＣＲＬが認証を求めるホストから受信されて検証される場合は、ＡＣＲと関連付けられ、証明書が失効していないことを検証するために使用されてもよいように、制御をステップ５０２４に指示することになる。
認証のために提示される証明書に対応する証明機関からのキャッシュＣＲＬを不揮発性記憶装置が現在記憶している場合、制御はステップ５０２０に進む。そして、抽出されたＣＲＬバージョン情報がキャッシュＣＲＬバージョンと比較されて、ホストにより提示されているＣＲＬがキャッシュＣＲＬよりも新しいかどうかが判定される。ホストにより提示されているＣＲＬがキャッシュＣＲＬよりも新しい場合、制御はステップ５０２２に進む。そして、不揮発性記憶装置がキャッシュＣＲＬを使用して、ホストにより提示された証明書を検証し、証明書が失効しているかどうかを判定する。この後、ステップ５０１２に進んで、他の認証処理を再開するかまたは終了する。
認証のために提示されている証明書に対応する証明機関からのキャッシュＣＲＬを不揮発性記憶装置が現在記憶していない場合、検証を求めるホストからＣＲＬが受信されるように、制御はステップ５０１８から５０２４に進む。そして検証される場合には、受信したＣＲＬが新しいキャッシュＣＲＬとして設定され、証明書が失効していないことを検証するために、設定されたキャッシュＣＲＬを使用してもよい。同様に、ホストから提示されるＣＲＬのバージョンがキャッシュバージョンよりも新しい場合、制御はステップ５０２４に進み、ホストから受信された新しいバージョンによってキャッシュＣＲＬの更新を試行する。ステップ５０２４において、ＣＲＬデータがホストから受信される。ステップ５０２６では、受信されたＣＲＬデータがキャッシュＣＲＬデータベースにキャッシュされる。制御はステップ５０２８に進み、ここで、ＣＲＬデータがすべて受信されているかどうかが判定される。ＣＲＬデータのすべてがまだ受信されていなければ、制御はステップ５０２８からステップ５０２４に進み、ＣＲＬデータのすべてが受信されるまでステップ５０２４、５０２６、および５０２８が繰り返される。
ＣＲＬデータのすべてがホストから受信されると、制御はステップ５０３０から進み、受信されたＣＲＬの署名が検証されて、受信されたＣＲＬが証明書の発行者により発行されたかどうかが判定される。受信されたＣＲＬが証明書の同じ発行者により発行されている場合、制御はステップ５０３４に進み、ステップ５０２６において受信されキャッシュされたＣＲＬがＡＣＲと関連付けられて、新しいキャッシュＣＲＬとして設定される。制御は、この後ステップ５０２２に進む。不揮発性記憶装置は、キャッシュＣＲＬを使用してホストにより提示された証明書を検証し、証明書が失効しているかどうかを判定する。この後、ステップ５０１２に進んで、他の認証処理を再開するかまたは終了する。
ＣＲＬがステップ５０３２において検証されない場合、制御はステップ５０２２に進む。ここで、不揮発性記憶装置はキャッシュＣＲＬ（これが証明機関から得られる場合）を使用してホストにより提示された証明書を検証し、証明書が失効しているかどうかを判定する。制御は、この後ステップ５０１２に進んで、他の認証処理を再開するかまたは終了する。図には示されていないが、キャッシュＣＲＬが不揮発性記憶装置により使用できなければ、認証は失敗する。
前述のように、ＳＳＡでは証明書連鎖が可能である。これは、認証される側のエンティティの公開鍵が、認証する側のエンティティとは異なる証明機関（ＣＡ）によって署名されてもよいことを意味する。この場合、認証される側のホストは、それ自体の証明書のほかに、その公開鍵に署名したＣＡの証明書を提供することになる。この第２レベルの証明書が、不揮発性記憶装置によりまだ信用されなければ（ＡＣＲに関連付けられた、信頼されたＣＡによって署名されなければ）、第３レベルの証明書が提供される。一実施形態では、ステップ５０００が繰り返されて、不揮発性記憶装置は、証明書連鎖の一部としてホストにより提示された各証明書を処理することができる。この実施形態では、連鎖の中の各証明書は、証明書が失効しているかどうかを判定するために使用される個別のＣＲＬと関連付けられてもよい。不揮発性記憶装置は、証明書連鎖の中で各証明書と関連付けられたＣＲＬのバージョンをキャッシュしてもよく、図５に示された例示的なステップ５０００に従ってそのＣＲＬを利用または更新してもよい。
それゆえ、一実施形態において、アカウントまたはＡＣＲでは、ホストが送信するＣＲＬを使用してホスト証明書を検証するのではなく、内部キャッシュＣＲＬを使用してホスト証明書を検証することができる。内部キャッシュＣＲＬは認証中に使用することができるため、ホストは、認証中に提示されるホスト証明書に結合されたＣＲＬを、ＡＣＲに送信する必要がない。不揮発性記憶装置は、失効している証明書を識別する製造時に、ＣＲＬ（または証明書連鎖に対する複数のＣＲＬ）がプログラムされてもよい。製造後、不揮発性記憶装置は、ホストを認証するときに遭遇するより新しいＣＲＬで、更新されてもよい。
一実施形態では、内部キャッシュＣＲＬは、ＡＣＲが作成されるときに使用が可能であってもよい。ＡＣＲの作成中に、ホスト証明書連鎖に対する１つまたは複数のＣＲＬは、不揮発性記憶装置で受信され、不揮発性記憶装置にキャッシュされ、ＡＣＲと関連付けられる。このようなＡＣＲへの認証を試行するためにＣＲＬを送信するとき、不揮発性記憶装置は、受信されたＣＲＬを以前にキャッシュされたＣＲＬと比較する。キャッシュされたＣＲＬバージョンがホストから受信されたＣＲＬよりも新しければ、不揮発性記憶装置は、キャッシュＣＲＬを使用してホスト証明書を検証する。ホストから受信されたＣＲＬのバージョンがキャッシュバージョンよりも新しければ、不揮発性記憶装置は、受信されたＣＲＬの署名を検証してこれが証明書の発行者により発行されたものかどうかを判定する。受信されたＣＲＬが証明書の発行者と同じ発行者によって発行される場合、キャッシュＣＲＬは新しいものに置換される。不揮発性記憶装置は、この後、更新された証明書失効リストを使用してホストが失効していなかったことを検証する。一実施形態では、カードが証明書そのものを検証した後、証明書の通し番号をＣＲＬの中の通し番号のリストと比較することにより、ホストが失効していないことを検証する。
ホストの認証中に、不揮発性記憶装置の中にキャッシュされたＣＲＬをホスト証明書が有していない場合には、不揮発性記憶装置はホストにより受信されたＣＲＬを使用してもよい。ＣＲＬをキャッシュするデータベースがまだ満杯でなければ、不揮発性記憶装置は、受信されたＣＲＬを将来の使用に備えてキャッシュすることになる。
証明書に対応するＣＲＬがキャッシュされない場合、またホストがＣＲＬを提供しない場合、証明書を処理するためのＣＲＬが得られないため認証は失敗する。例えば、ホストは、認証中に証明書を送信した後、不揮発性記憶装置に対してＣＲＬを送信してもよく、あるいは連鎖の中の次の証明書を不揮発性記憶装置に送信してもよい。後者の場合、不揮発性記憶装置は、キャッシュＣＲＬを用いて第１の証明書を検証することになる。証明書の発行者に対してＣＲＬがキャッシュされなければ、認証は失敗する。
それゆえ、新しい不揮発性記憶装置を製造するときに、更新された失効リストを装置に記憶させてもよい。ＣＲＬは、既に信頼されていない、フィールド中のホストを識別することができる。そのホストの証明書は、不揮発性記憶装置の製造より前に失効している。この実施形態では、キャッシュされた証明書失効リストをチェックすることにより、ホストの証明書が失効しているかどうかを不揮発性記憶装置が検証できるため、ホストが証明書失効リストを不揮発性記憶装置に送信する必要がない。ＣＲＬを不揮発性記憶装置に伝達すると、認証を長引かせる可能性がある。それゆえ、キャッシュＣＲＬを使用することで、認証プロセスを短縮することができる。
しかしながら、証明機関は長期にわたってＣＲＬを更新することができ、それゆえに、キャッシュＣＲＬは時間の経過とともに期限切れとなり使用されなくなる可能性がある。ホストが更新されたバージョンのＣＲＬを用いて認証を試行する場合には、不揮発性記憶装置は、キャッシュＣＲＬをオポチュニスティックに更新する可能性がある。不揮発性記憶装置にアクセスしようとする一部のホストは、証明書発行機関に（有線または無線接続によって）接続して、認証中に提示するための更新されたＣＲＬを入手することができる。このような接続ホストが、不揮発性記憶装置の認証を試行するときに更新されたＣＲＬを提供すると、不揮発性記憶装置は、更新されたＣＲＬをキャッシュして将来これを利用することができる。このプロセスを使用するＣＲＬのオポチュニスティック型の更新は、更新されたＣＲＬに対するバイラル方式の配布システムとして、効果的に機能を果たすことができる。
例えば、不揮発性記憶装置は、ＭＰ３プレーヤに動作可能に接続されてもよい。この例では、ＭＰ３プレーヤには、有線または無線接続を介して証明機関に接続するなどして、更新された証明書失効リストにアクセスする能力がない。それゆえ、ＭＰ３プレーヤは、不揮発性記憶装置にアクセスしようとするたびに、同じ証明書と証明書失効リストを提示する。時間の経過とともに証明機関は証明書失効リストを更新するため、ＭＰ３プレーヤにより提示されるそのリストは無効になる可能性がある。不揮発性記憶装置がＭＰ３プレーヤに単に動作可能に結合されている限り、そのＣＲＬのキャッシュコピーは、ＭＰ３プレーヤにより提示されるＣＲＬと同じバージョンになる。それゆえ、キャッシュＣＲＬはやはり時間の経過に伴って無効になる。
その後、不揮発性記憶装置が、更新されたＣＲＬを受信できる装置に動作可能に結合されると、不揮発性記憶装置は、ＣＲＬの「バイラル形式」の更新をオポチュニスティックに受信することができる。例えば、不揮発性記憶装置がＭＰ３プレーヤから取り出されて携帯電話に動作可能に結合されると、装置に記憶されたコンテンツにアクセスするために、不揮発性記憶装置への認証を試行することができる。携帯電話は、更新された証明書失効リストを証明機関に要求することができる。更新された証明書失効リストは、携帯電話がコンテンツにアクセスするために使用しようとする証明書に対応する。携帯電話は、有線または無線接続を介して更新された証明書失効リストを、受信することができる。携帯電話が、不揮発性記憶装置を認証して記憶されたコンテンツにアクセスするために、証明書と併せて更新された証明書失効リストを提示すると、不揮発性記憶装置は、そのキャッシュ証明書失効リストを、携帯電話から受信されたコピーで更新することになる。このようにして、証明機関に接触して更新された証明書失効リストをそれ自体で受信できる独立した機能を有していない不揮発性記憶素子に対して、証明書失効リストを分配するために、携帯電話、パーソナルコンピュータ、およびインターネット家電などの接続装置を使用することができる。
＜アイデンティティ・オブジェクト（ＩＤＯ）＞
アイデンティティ・オブジェクトは、フラッシュ・メモリ・カードなどのメモリ装置１０が、ＲＳＡ鍵対またはその他の暗号ＩＤを記憶できるように設計された、被保護オブジェクトである。アイデンティティの署名および検証や、データの暗号化および復号化に使用することができる暗号ＩＤであれば、どのようなタイプのものでも、アイデンティティ・オブジェクトに含めることができる。鍵対の公開鍵が真正であることを証明するＣＡの証明書（または複数のＣＡの証明書連鎖）も、アイデンティティ・オブジェクトに含まれる。アイデンティティ・オブジェクトを使用すれば、外部エンティティや内部カードエンティティ（すなわち、アイデンティティ・オブジェクトの所有者と称される装置自体、内部のアプリケーションなど）のアイデンティティの証拠を、提供することができる。したがって、カードは、チャレンジ・レスポンス機構でホストを認証するためにＲＳＡ鍵対またはその他のタイプの暗号ＩＤを使用せずに、識別情報の証拠として、カードに提示されるデータストリームに署名する。換言すると、アイデンティティ・オブジェクトは、その所有者の暗号ＩＤを含む。アイデンティティ・オブジェクトの中の暗号ＩＤにアクセスするには、まずホストを認証する必要がある。後述するように、この認証プロセスはＡＣＲによって管理される。ホストの認証に成功すると、アイデンティティ・オブジェクトの所有者は、相手方に対して暗号ＩＤを使用して自身のアイデンティティを立証することができる。例えば、相手方からホストを通じて提示されるデータには、暗号ＩＤ（例えば、公開−秘密鍵対の秘密鍵）を使用して署名することができる。アイデンティティ・オブジェクトの署名済みデータと証明書は、アイデンティティ・オブジェクトの所有者に代わって相手方に提示される。証明書にある公開−秘密鍵対の公開鍵が真正であることは、ＣＡ（すなわち、信用機関）によって証明されるため、相手方はこの公開鍵が真正であると信用することができる。そこで相手方は、証明書の公開鍵を使用して署名済みデータを復号化し、復号化されたデータを相手方によって送信されたデータと比較することができる。復号化されたデータが相手方によって送信されたデータに一致する場合、アイデンティティ・オブジェクトの所有者は、真正な秘密鍵にアクセスできる自称通りのエンティティであることが分かる。
アイデンティティ・オブジェクトの第２の利用法は、ＲＳＡ鍵自体などの暗号化ＩＤを用いて、ＩＤＯの所有者に対して指定されるデータを保護することである。データは、ＩＤＯ公開鍵を用いて暗号化されるものと予想される。メモリカードなどのメモリ装置１０は、公開鍵を使用してデータを復号化する。
ＩＤＯは、いかなるタイプのＡＣＲに対しても作成できるオブジェクトである。一実施形態では、ＡＣＲは、１つのみのＩＤＯオブジェクトを有していてもよい。データ署名および保護機能は、いずれも、ＡＣＲを認証できるすべてのエンティティに対してＳＳＡシステムから提供されるサービスである。ＩＤＯの保護レベルは、ＡＣＲのログイン認証方式と同じくらい高い。ＩＤＯを必ず有することになるＡＣＲに対しては、任意の認証アルゴリズムを選定することができる。ＩＤＯ運用を良好に保護しうるアルゴリズムを評価し決定するのは、作成元（ホスト）である。ＩＤＯを有するＡＣＲは、ＩＤＯ公開鍵取得コマンドに応じて証明書連鎖を提供する。
データ保護にＩＤＯを使用する場合でも、カードから出力される復号化データにはさらなる保護が必要になることがある。そのような場合、いずれかの認証アルゴリズムによって確立されるセキュアチャネルを使用することが、ホストに推奨される。
ＩＤＯを作成するときに、鍵の長さとともに、ＰＫＣＳ＃１バージョンを選択する。一実施形態において、公開鍵および秘密鍵に、ＰＫＣＳ＃１バージョン２．１で定める（指数、係数）表現を使用する。
一実施形態において、ＩＤＯの作成中に含められるデータは、選択された長さを有するＲＳＡ鍵対と、公開鍵の信頼性を帰納的に証明する証明書連鎖である。
ＩＤＯを所有するＡＣＲは、ユーザデータの署名を許可する。これは、２つのＳＳＡコマンドによって行われる。
・Ｓｅｔ ｕｓｅｒ ｄａｔａ：署名の対象となる自由書式のデータバッファを提供する。
・Ｇｅｔ ＳＳＡ ｓｉｇｎａｔｕｒｅ：カードは、ＲＳＡ署名を提供する（ＡＣＲ秘密鍵を使用）。署名の形式とサイズは、オブジェクトのタイプに応じて、ＰＫＣＳ＃１バージョン１．５またはＶ２．１に従って設定することができる。
図３５〜図３７はＩＤＯを使用した操作を示すものである。ここで、メモリ装置１０はフラッシュ・メモリ・カードであり、このカードがＩＤＯの所有者である。図３５は、ホストに送信されるデータに署名する場合に、カードによって実行されるプロセスを示す。図３５を参照し、前述したツリー構造のノードに位置するＡＣＲの管理下でホストが認証された後（ブロック８０２）、カードは証明書を求めるホスト要求を待つ（菱形８０４）。要求を受信したカードは証明書を送信し、菱形８０４に戻り、次のホスト要求を待つ（ブロック８０６）。カードが所有するＩＤＯの公開鍵を証明するために、証明書連鎖を送信する必要がある場合、連鎖の中のすべての証明書がホストへ送信されるまで、前述したアクションが繰り返される。各証明書がホストに送信された後、カードは、ホストから他のコマンドが届くのを待つ（菱形８０８）。所定の期間内にホストからのコマンドが受信されなければ、カードは菱形８０４に戻る。ホストからデータとコマンドを受信したカードは、そのコマンドをチェックし、データに署名するためのものであるかどうかを確認する（菱形８１０）。データに署名するためのコマンドである場合、カードはＩＤＯの秘密鍵を使用してデータに署名し、署名したデータをホストへ送信し（ブロック８１２）、菱形８０４に戻る。ホストからのコマンドがホストからのデータに署名するためのものでなければ、カードはＩＤＯの秘密鍵を使用して受信データを復号化し（ブロック８１４）、菱形８０４に戻る。
図３６は、ホストへ送信されるデータにカードが署名する際に、ホストによって実行されるプロセスを示す。図３６を参照すると、ホストは、カードに認証情報を送信する（ブロック８２２）。前述したツリー構造のノードに位置するＡＣＲの制御下で認証に成功すると、ホストは、証明書連鎖を求める要求をカードに送信し、連鎖を受信する（ブロック８２４）。カードの公開鍵が検証されると、ホストは署名されるデータをカードに送信し、カードの秘密鍵により署名されたデータを受信する（ブロック８２６）。
図３７は、ホストがカードの公開鍵を使用してデータを暗号化し、暗号化されたデータをカードに送信するときに、ホストによって実行されるプロセスを示す。図３７を参照すると、ホストは、カードへ認証情報を送信する（ブロック８６２）。ＡＣＲの管理下で認証に成功すると、ホストは、ＩＤＯの中にあるカードの公開鍵を検証するために必要となる証明書連鎖の要求をカードに送信し（ブロック８６４）、さらにデータを求める要求をカードに送信する。ＩＤＯの中にあるカードの公開鍵を検証した後、ホストは、カードの検証済み公開鍵を使用してカードから受信したデータを暗号化し、これをカードに送信する（ブロック８６６、８６８）。
＜クエリ＞
ホストおよびアプリケーションは、システム操作を実行するために、相手方のメモリ装置またはカードに関する一定の情報を所有する必要がある。例えば、ホストおよびアプリケーションは、メモリカードに記憶されたアプリケーションのうち、実行できるアプリケーションがいずれであるかを知る必要がある。ホストにとっての必要情報は公知でない場合があり、これはその情報を所有する権利を有する者とそうでない者があることを意味する。権限を持つユーザと持たないユーザとを区別するには、ホストで使用できるクエリを２通り用意する必要がある。
＜一般情報クエリ＞
このクエリは、システム公開情報を無制限に放出する。メモリ装置に記憶される機密情報は、２つの部分、すなわち、共有部分および非共有部分からなる。各エンティティが自身の専有情報のみへのアクセスが認められ、他のエンティティの専有機密情報にアクセスすることができないように、機密情報の一部分には、個々のエンティティにとっての専有情報が含まれている。この種の機密情報は共有されず、機密情報の非共有部位または部分を形成する。
カードに常駐するアプリケーションの名称とそのライフサイクル状態など、通常は公の情報と考えられるものでも、場合によっては機密とみなされることがある。別の例として、公の情報とされるルートＡＣＲ名であっても、ＳＳＡを使用する一部の場合には、機密になることがある。このような場合には、一般情報クエリに応じて情報をすべて認証済みユーザに限って利用させ、認証されていないユーザには利用させないようにするためのオプションを、システムに用意しなければならない。このような情報は、機密情報の共有部分を占める。ルートＡＣＲリスト、すなわち装置上に現在存在する全ルートＡＣＲのリストは、機密情報の共有部分の一例となりうる。
一般情報クエリにより公開情報へアクセスする場合、ホスト／ユーザはＡＣＲにログインする必要がない。それゆえ、ＳＳＡ規格に精通する者であれば誰でも実行可能であり、情報を受信することができる。ＳＳＡの規定では、セッション番号なしでこのクエリコマンドが処理される。しかしながら、機密情報の共有部分へのアクセスを望むエンティティは、最初に、メモリ装置のデータに対するアクセスを制御する制御構造のいずれか（例えば、ＡＣＲのいずれか）を通じて認証される必要がある。認証に成功したエンティティは、一般情報クエリを使用して、機密情報の共有部分にアクセスできるようになる。前述したように、認証プロセスの結果として、アクセスするためのＳＳＡセッション番号またはｉｄが得られる。
＜取扱い注意情報クエリ＞
個々のＡＣＲとそのシステムアクセスおよび資産に関する私的情報は、取扱い注意とされ、明確な認証を必要とする。この種の情報クエリでは、情報クエリの認証を受信する前に、ＡＣＲのログインと認証（認証がＡＣＲで指定されている場合）が必要になる。このクエリには、ＳＳＡセッション番号が必要である。
２種類のクエリを詳述する前に、クエリを実行する現実的な解決策として、インデックスグループの概念をまず説明することが有益である。
＜インデックスグループ＞
ポテンシャルＳＳＡホストで実行するアプリケーションには、読出しの対象となるセクタ数を指定することが、ホスト上のオペレーティングシステム（ＯＳ）とシステムドライバとにより求められる。これは、ホストアプリケーションが、ＳＳＡ読出し操作のたびに読み出す必要のあるセクタ数を知る必要があることを意味する。
クエリ操作で供給される情報は、一般的には、これを要求する側にとって未知の情報であるため、ホストアプリケーションがクエリを発行し、その操作に必要なセクタの量を推測することは困難である。
この問題を解決するため、ＳＳＡのクエリ出力バッファは、各クエリ要求につき１つのみのセクタ（５１２バイト）からなる。出力情報の一部であるオブジェクトは、インデックスグループと呼ばれるものに編成される。オブジェクトのバイトサイズはオブジェクトのタイプによって異なり、そこから１セクタに収まるオブジェクトの数が明らかになる。これによって、オブジェクトのインデックスグループが決まる。オブジェクトのサイズが２０バイトである場合、このオブジェクトのインデックスグループは最大２５オブジェクトを含む。このようなオブジェクトが全部で５６個ある場合、それらは３つのインデックスグループに編成され、第１のインデックスグループの先頭はオブジェクト「０」（第１のオブジェクト）となり、第２のインデックスグループの先頭はオブジェクト「２５」となり、第３の最終インデックスグループの先頭はオブジェクト５０となる。
＜システムクエリ（一般情報クエリ）＞
このクエリは、装置がサポートするＳＳＡシステムと、ツリー状に構成された現行のシステムと、装置で実行するアプリケーションとに関する一般公開情報を提供する。後述するＡＣＲクエリ（取扱い注意クエリ）と同様に、システムクエリは、複数のクエリオプションを提供するように構成される。
・Ｇｅｎｅｒａｌ：サポートされたＳＳＡバージョン
・ＳＳＡ Ａｐｐｌｉｃａｔｉｏｎｓ：現在装置に存在する全ＳＳＡアプリケーションのリストで、アプリケーションの実行状態を含む。
前述した情報は公開情報である。ＡＣＲクエリと同様に、ホストがクエリ出力バッファのための読出しセクタ数を知らずに済ませるため、装置からは１セクタが返送され、ホストは引き続きさらなるインデックスグループを照会することができる。ルートＡＣＲオブジェクトの数が、インデックスグループ「０」のための出力バッファサイズの数を超える場合、ホストは、後続のインデックスグループ（「１」）で、別のクエリ要求を送信することができる。
＜ＡＣＲクエリ（取扱い注意情報クエリ）＞
ＳＳＡのＡＣＲクエリコマンドは、鍵ＩＤ、アプリケーションＩＤ、パーティション、子ＡＣＲなど、ＡＣＲのシステムリソースに関する情報をＡＣＲユーザに供給するためのものである。そのクエリ情報は、ログインされたＡＣＲに関するもののみであり、システムツリー上の他のＡＣＲに関するものはない。換言すると、アクセスは、関与するＡＣＲの許可のもとでアクセス可能な機密情報の部分のみに限られる。
ユーザが照会できるＡＣＲオブジェクトには、以下の３つがある。
・パーティション：名称とアクセス権（所有者、読出し、書込み）。
・鍵ＩＤとアプリケーションＩＤ：名称とアクセス権（所有者、読出し、書込み）。
・子ＡＣＲ：ＡＣＲ、および、直接の子にあたるＡＣＲのＡＧＰ名称。
・ＩＤＯとセキュア・データ・オブジェクト（後述）：名称とアクセス権（所有者、読出し、書込み）。
ＡＣＲに結び付いたオブジェクトの数は、変化する場合があり、情報は５１２バイト、すなわち１セクタを上回ることがある。オブジェクトの数が事前に分からない限り、ユーザは、リストすべてを得るために装置内のＳＳＡシステムから読み出される必要があるセクタの数を知ることはできない。そこで、前述したシステムクエリの場合と同様に、ＳＳＡシステムによって提供される各オブジェクトリストは、インデックスグループに分割される。インデックスグループはセクタに収まるオブジェクトの数であり、すなわち、装置内のＳＳＡシステムからホストに１セクタで送信できるオブジェクトの数である。これにより、装置内のＳＳＡシステムは、要求されたインデックスグループを１セクタで送信することができる。ホスト／ユーザは、照会したオブジェクトのバッファ、バッファ内のオブジェクト数を受信することになる。バッファが一杯である場合、ユーザは次のオブジェクト・インデックス・グループを照会することができる。
図３８は、一般情報クエリを伴う操作を示すフローチャートである。図３８を参照すると、エンティティから一般情報クエリを受信したＳＳＡシステムは（ブロック９０２）、そのエンティティが認証済みかどうかを判定する（菱形９０４）。認証済みである場合には、システムは、公開情報と機密情報の共有部分とをエンティティに供給する（ブロック９０６）。認証済みでなければ、システムは、公開情報のみをエンティティに供給する（ブロック９０８）。
図３９は、取扱い注意情報クエリを伴う操作を示す、フローチャートである。図３９を参照すると、エンティティから取扱い注意情報クエリを受信したＳＳＡシステムは（９２２）、そのエンティティが認証済みかどうかを判定する（菱形９２４）。認証済みである場合には、システムは、エンティティに機密情報を供給する（ブロック９２６）。認証済みでない場合には、システムは、機密情報に対するエンティティのアクセスを拒絶する（ブロック（９２８）。
＜フィーチャ・セット・エクステンション（ＦＳＥ）＞
多くの場合、データ処理活動（例えば、ＤＲＭライセンスオブジェクト検査）をカード上のＳＳＡの内部で実行できることは、大変有利である。その結果、データ処理タスクのすべてをホストで実行する代替的な解決策に比べて、より安全でより効率的なシステムとなり、ホストへの依存度も低くなる。
ＳＳＡセキュリティシステムは、メモリカードによって記憶され、管理され、保護されるオブジェクトのアクセス、使用、収集を制御する、１組の認証アルゴリズムと認可ポリシーとを備える。アクセスを得たホストは、メモリ装置に記憶されたデータに対して処理を実行し、メモリ装置に対するアクセスはＳＳＡによって制御される。しかしながら、データは、本質的にアプリケーションに非常に依存するものであると考えられるため、装置に記憶されたデータを取り扱わないＳＳＡでは、データ形式またはデータ処理は定義されない。
本発明の一実施形態は、通常であればホストによって実施される機能の一部を、メモリカードで実行するように、ＳＳＡシステムを強化できるという認識に基づく。そこで、ホストのソフトウェア機能のいくつかは、２つの部分、すなわち引き続きホストによって実施される部分と、カードによって実施される部分とに分かれる場合がある。こうすることで、多くの用途にとって、データ処理の安全性と効率性が向上する。この目的のため、ＦＳＥと呼ばれる機構を加えることによって、ＳＳＡの能力を高める場合がある。このように、カードによって実行されるＦＳＥのホストアプリケーションを、本明細書では、内部アプリケーションまたは装置内部アプリケーションと呼ぶ場合がある。
強化ＳＳＡシステムは、カードの認証およびアクセス制御を提供する基本ＳＳＡコマンド群を、カードアプリケーションの導入により拡張する機構を提供する。カードアプリケーションは、ＳＳＡ以外のサービス（例えば、ＤＲＭスキーム、ｅコマーストランザクション）を実行することになっている。ＳＳＡフィーチャ・セット・エクステンション（ＦＳＥ）は、独自開発のデータ処理ソフトウェア／ハードウェアモジュールで、標準ＳＳＡセキュリティシステムを強化するように設計された機構である。ＳＳＡ＿ＦＳＥシステムのサービスにより、ホスト装置は、前述したクエリ用いて得られる情報のほかに、カードで使用可能なアプリケーションを照会し、特定のアプリケーションを選択し、これと通信することができる。前述した一般クエリと取扱い注意クエリを、この目的に使用することもできる。
＜ＳＳＡ＿ＦＳＥでカード機能群を拡張するには２つの方法を利用する：＞
・サービス提供：この機能は、認可されたエンティティが、通信パイプと呼ばれる独自のコマンドチャネルを使用して内部アプリケーションと直接通信することによって実現する。
・ＳＳＡ標準アクセス制御ポリシーの拡張：この機能は、内部の被保護データオブジェクト（例えば、ＣＥＫ、後述するセキュア・データ・オブジェクト、すなわちＳＤＯ等）に内部カードアプリケーションを関連付けることによって、実現する。このようなオブジェクトにアクセスするときに、所定の標準ＳＳＡポリシーが満たされる場合は、関連付けアプリケーションが起動して、標準ＳＳＡポリシーに加えて少なくとも１つの条件を課す。この条件は、標準ＳＳＡポリシーとは衝突しないことが好ましい。この追加条件も満たされる場合に限り、アクセスが許諾される。ＦＳＥの能力をさらに詳述する前に、ＦＳＥの構造的態様と通信パイプとＳＤＯをここで取り上げる。
＜ＳＳＭモジュールおよび関連モジュール＞
図４０Ａは、ホスト装置２４に接続されたメモリ装置１０（フラッシュ・メモリ・カードなど）におけるシステムアーキテクチャ１０００の機能ブロック図であり、本発明のある実施形態を例示するものである。カード２０のメモリ装置にあるソフトウェアモジュールの主要な構成要素は、次の通りである。
＜ＳＳＡトランスポート層１００２＞
ＳＳＡトランスポート層は、カードプロトコルに依存する。これは、カード１０のプロトコル層でホスト側ＳＳＡ要求（コマンド）を処理し、処理された要求をＳＳＭ＿ＡＰＩに送る。ホスト−カードの同期とＳＳＡコマンドの識別は、すべてこのモジュールで行われる。ホスト２４とカード１０との間のすべてのＳＳＡデータ転送にも、トランスポート層が関与する。
＜セキュア・サービス・モジュール・コア（ＳＳＭコア）１００４＞
このモジュールは、ＳＳＡの実施態様の重要な部分である。ＳＳＭコアは、ＳＳＡアーキテクチャを実施する。より具体的には、ＳＳＭコアは、ＳＳＡツリーと、ＡＣＲシステムと、システムを構成する前述の対応するすべてのルールと、を実施する。ＳＳＭコアモジュールは、暗号ライブラリ１０１２を使用して、ＳＳＡセキュリティと、暗号化、復号化、ハッシュ計算などの暗号機能と、をサポートする。
＜ＳＳＭコアＡＰＩ＿１００６＞
これは、ホストと内部アプリケーションが、ＳＳＭコアと連携しながらＳＳＡ操作を実行する層である。図４０Ａに示すように、ホスト２４と内部装置アプリケーション１０１０は、いずれも同じＡＰＩを使用する。
＜セキュアアプリケーション管理モジュール（ＳＡＭＭ）１００８＞
ＳＡＭＭは、ＳＳＡシステムの一部ではないが、ＳＳＡシステムと連携しながら内部装置アプリケーションを制御する、カードの重要なモジュールである。
ＳＡＭＭは、以下を含むアプリケーションを実行する内部装置のすべてを管理する。
１．アプリケーションライフサイクルの監視と制御
２．アプリケーションの初期化
３．アプリケーション／ホスト／ＳＳＡインターフェース
＜装置内部アプリケーション１０１０＞
これらは、カード側での実行が許可されたアプリケーションである。これらはＳＡＭＭによって管理され、ＳＳＡシステムにアクセスできる場合がある。また、ホスト側アプリケーションと内部アプリケーションとの間の通信パイプは、ＳＳＭコアから提供される。ＤＲＭアプリケーションや以下で詳しく説明するワン・タイム・パスワード（ＯＴＰ）アプリケーションは、内部実行アプリケーションの例である。
＜装置管理システム（ＤＭＳ）１０１１＞
これは、カードのシステムおよびアプリケーションファームウェアを更新したり、出荷後（一般的に後発行と称される）モードでサービスを追加／削除したりするための、プロセスおよびプロトコルを含むモジュールである。
図４０Ｂは、ＳＳＭコア１００４の内部ソフトウェアモジュールの機能ブロック図である。図４０Ｂに示すように、コア１００４は、ＳＳＡコマンド処理部１０２２を含む。処理部１０２２は、ホストまたは装置内部アプリケーション１０１０から発行されたＳＳＡコマンドを解析した後、これをＳＳＡ管理部１０２４に渡す。ＡＧＰやＡＣＲなどのＳＳＡセキュリティデータ構造や、すべてのＳＳＡのルールとポリシーは、いずれもＳＳＡデータベース１０２６に記憶される。ＳＳＡ管理部１０２４は、データベース１０２６に記憶されたＡＣＲやＡＧＰやその他の制御構造によって、制御を実施する。ＩＤＯやセキュア・データ・オブジェクトをはじめとするその他のオブジェクトも、ＳＳＡデータベース１０２６に記憶される。ＳＳＡ管理部１０２４は、データベース１０２６に記憶されたＡＣＲやＡＧＰやその他の制御構造によって、制御を実施する。ＳＳＡが関与しない非セキュア操作は、ＳＳＡ非セキュア操作モジュール１０２８によって処理される。ＳＳＡアーキテクチャのもとでのセキュア操作は、ＳＳＡセキュア操作モジュール１０３０によって処理される。モジュール１０３２は、モジュール１０３０を暗号ライブラリ１０１２に接続するインターフェースである。１０３４は、モジュール１０２６および１０２８を、図１のフラッシュメモリ２０に接続する層である。
＜通信（またはパススルー）パイプ＞
パススルー・パイプ・オブジェクトは、ＳＳＭコアとＳＡＭＭの制御下で認可されたホスト側エンティティと、内部アプリケーションとの通信を可能にする。ホストと内部アプリケーションとのデータ転送は、ＳＥＮＤコマンドとＲＥＣＥＩＶＥコマンドで行われる（後述）。実際のコマンドは、アプリケーションによって異なる。パイプを作成するエンティティ（ＡＣＲ）は、パイプ名と、チャネルの開通によってつながるアプリケーションのＩＤと、を提供することが必要になる。他の被保護オブジェクトと同様に、このＡＣＲがパイプの所有者になり、標準の委譲ルールおよび制限に従って、他のＡＣＲに使用権や所有権を委譲することが許可される。
認証済みのエンティティは、そのＡＣＡＭでＣＲＥＡＴＥ＿ＰＩＰＥ権限が設定されている場合に、パイプオブジェクトの作成が許可されることになる。内部アプリケーションとの通信は、そのＰＣＲでパイプ書込み権限またはパイプ読出し権限が設定されている場合に限り、許可される。所有権とアクセス権の委譲は、エンティティがパイプの所有者か、あるいはそのＰＣＲでアクセス権委譲が設定されている場合に限り、許可される。他のすべての権限と同様に、別のＡＣＲへ所有権を委譲する当初の所有者は、この装置アプリケーションに対するすべての権限から引き離されることが好ましい。
ある特定のアプリケーションにつき、１つのみの通信パイプが作成されることが好ましい。第２のパイプを作成し、作成したパイプを接続済みのアプリケーションに接続する試行は、ＳＳＭシステム１０００によって拒絶されることが好ましい。それゆえ、装置内部アプリケーション１０１０の１つと通信パイプとの間に、１対１の関係があることが好ましい。しかしながら、（委譲機構により）複数のＡＣＲが１つの装置内部アプリケーションと通信する場合がある。（種々のアプリケーションに接続された複数パイプの委譲または所有権により、）１つのＡＣＲが、複数の装置アプリケーションと通信する場合がある。通信パイプ間のクロストークをなくすため、種々のパイプを制御するＡＣＲは、全く別個のツリーノードに位置することが好ましい。
ホストと特定のアプリケーションとのデータ転送は、次のコマンドを使用して行われる。
・書込みパススルー：ホストから装置内部アプリケーションに、非定型データバッファを転送する。
・読出しパススルー：ホストから装置内部アプリケーションに非定型データバッファを転送し、内部処理が完了したら非定型データバッファをホストに戻す。
書込みパス・スルー・コマンドと読出しパス・スルー・コマンドでは、ホストが通信しようとする相手方の装置内部アプリケーション１００８のＩＤを、パラメータとして提供する。エンティティの権限を検証し、要求される側のアプリケーションにつながるパイプを使用する権限が、要求する側のエンティティ（すなわち、このエンティティが使用しているセッションを運営するＡＣＲ）にある場合、データバッファを解釈し、コマンドを実行する。
この通信方法により、ホストアプリケーションは、ＳＳＡ＿ＡＣＲセッションチャネルを通じて、内部装置アプリケーションにベンダー固有／独自のコマンドを引き渡すことができる。
＜ソース・データ・オブジェクト（ＳＤＯ）＞
ＳＤＯは、ＦＳＥと併せて使用できる便利なオブジェクトである。
ＳＤＯは、汎用容器として、機密情報を安全に記憶する役割を果たす。ＣＥＫオブジェクトと同様に、ＳＤＯはＡＣＲによって所有され、ＡＣＲとの間でアクセス権と所有権を委譲することができる。ＳＤＯは、所定の規制に従って保護され使用されるデータを含み、オプションとして、装置内部アプリケーション１００８へ至るリンクを有する。機密データは、ＳＳＡシステムによって使用されることも解釈されることもなく、オブジェクトの所有者とユーザがこれを使用し、解釈することが好ましい。換言すると、ＳＳＡシステムは、取り扱うデータの情報を認識しない。このため、オブジェクトの中にあるデータの所有者とユーザは、ホストとデータオブジェクトとの間でデータが受け渡しされるときに、ＳＳＡシステムとの橋渡しによって機密情報が失われることをさほど心配せずに済む。ＳＤＯオブジェクトは、ホストシステム（または内部アプリケーション）によって作成され、ＣＥＫを作成する場合と同様に、文字列ＩＤが割り当てられる。作成する場合に、ホストは、名前のほかに、ＳＤＯにリンクするアプリケーションのアプリケーションＩＤと、ＳＳＡによって記憶され、完全性検証が行われ、検索されるデータブロックと、を提供する。
ＳＤＯは、ＣＥＫと同様に、ＳＳＡセッションの中でのみ作成されることが好ましい。このセッションを開放するために使用されるＡＣＲが、ＳＤＯの所有者となり、ＳＤＯを削除する権利や機密データを読み書きする権利を有するほか、ＳＤＯの所有権やこれにアクセスする権限を別のＡＣＲ（その子ＡＣＲまたは同一ＡＧＰ内のＡＣＲ）に委譲する権利を有する。
書込み操作と読出し操作は、ＳＤＯの所有者に限定される。書込み操作は、既存のＳＤＯオブジェクトデータを、提示されたデータバッファで上書きする。読出し操作は、ＳＤＯのデータ記録一式を検索する。
正式なアクセス権限を有する所有者以外のＡＣＲには、ＳＤＯのアクセス操作が許可される。次の操作が定められている。
・ＳＤＯ＿Ｓｅｔ、アプリケーションＩＤの指定：データは、このアプリケーションＩＤを有する内部ＳＳＡアプリケーションによって処理される。アプリケーションは、ＳＤＯとの関連付けによって起動する。オプションとして、アプリケーションがＳＤＯオブジェクトの書込みを行う場合がある。
・ＳＤＯ＿Ｓｅｔ、アプリケーションＩＤの不在：このオプションは無効であり、不正コマンドエラーを促す。Ｓｅｔコマンドには、カードで実行する内部アプリケーションが必要となる。
・ＳＤＯ＿Ｇｅｔ、アプリケーションＩＤの指定：要求は、このアプリケーションＩＤを有する装置内部アプリケーションによって処理される。アプリケーションは、ＳＤＯとの関連付けによって起動する。出力は、指定がなくとも、要求する側に返送される。オプションとして、アプリケーションがＳＤＯオブジェクトの読出しを行う場合がある。
・ＳＤＯ＿Ｇｅｔ、アプリケーションＩＤの不在：このオプションは無効であり、不正コマンドエラーを促す。Ｇｅｔコマンドには、カードで実行する内部アプリケーションが必要となる。
・ＳＤＯ関連の権限：ＡＣＲには、ＳＤＯの所有者になるものと、アクセス権限（Ｓｅｔ、Ｇｅｔ、または両方）を有するのみのものとがある。ＡＣＲには、自身が所有しないＳＤＯに対する自身のアクセス権を、別のＡＣＲへ譲渡することが許可される。ＡＣＡＭ権限を有するＡＣＲには、ＳＤＯの作成とアクセス権の委譲が、明示的に許可される場合がある。
＜内部ＡＣＲ＞
装置１０にとって外部のエンティティがＡＣＲにログインすることができない点以外は、内部ＡＣＲは、ＰＣＲを有するＡＣＲに類似している。代替的に、これの管理下にあるオブジェクトか、あるいはこのオブジェクトと関連付けするアプリケーションが呼び出されるときに、図４０ＢのＳＳＡ管理部１０２４が、自動的に内部ＡＣＲにログインする。アクセスを試みるエンティティは、カードまたはメモリ装置にとって内部のエンティティであるため、認証の必要はない。ＳＳＡ管理部１０２４は、内部通信を可能にするために、内部ＡＣＲにセッション鍵を渡すだけになる。
これより、ワン・タイム・パスワード生成とデジタル権利管理という２つの例を引いて、ＦＳＥの能力を例示する。ワン・タイム・パスワード生成の例を説明する前に、二因子認証のテーマを取り上げる。
＜ＯＴＰ実施形態＞
＜二因子認証（ＤＦＡ）＞
ＤＦＡは、標準のユーザ認証情報（すなわち、ユーザ名およびパスワード）に追加の秘密、すなわち「第２の因子」を加えることにより、ウェブ・サービス・サーバなどへの私的なログインでセキュリティを高めるように意図された認証プロトコルである。この第２の秘密は、典型的に、ユーザが所有する物理的で安全なトークンに記憶されるものである。ユーザは、ログインの過程で、ログイン認証情報の一部として所有の証拠を提供する必要がある。所有の証明には、ワン・タイム・パスワード（ＯＴＰ）がよく使われ、これはセキュアトークンで生成され出力される、１回のログインのみで通用するパスワードである。トークンなしでＯＴＰを計算するのは暗号技術的に不可能であるため、ユーザが正しいＯＴＰを提供できる場合、これをもってトークン所有の十分な証拠とみなされる。ＯＴＰは１回のログインのみで通用し、前のログインから得た古いパスワードは通用しないことになるため、ユーザはログインのときにトークンを所有していなければならない。
以下の節で説明する製品は、ＳＳＡのセキュリティデータ構造と、一連のＯＴＰで次のパスワードを計算する１つのＦＳＥ設計とを利用しながら、フラッシュ・メモリ・カードで、それぞれ異なるパスワード系列（異なるウェブサイトへのログインに使用）を生成する、複数の「仮想」セキュアトークンを実行するものである。図４１は、このシステムのブロック図を示す。
システム一式１０５０は、認証サーバ１０５２と、インターネットサーバ１０５４と、トークン１０５８を有するユーザ１０５６と、を備える。最初のステップでは、認証サーバとユーザとの間で、共有秘密を取り決める（シード提供とも称される）。ユーザ１０５６は、秘密またはシードの発行を要求し、これをセキュアトークン１０５８に記憶する。次のステップでは、発行された秘密またはシードを、特定のウェブ・サービス・サーバに結合する。これを果たした時点で、認証に取りかかることができる。ユーザは、ＯＴＰの生成をトークンに指示する。ＯＴＰは、ユーザ名およびパスワードとともに、インターネットサーバ１０５４に送信される。インターネットサーバ１０５４は、認証サーバ１０５２にＯＴＰを転送し、ユーザアイデンティティの検証を依頼する。認証サーバもＯＴＰを生成するが、これはトークンとの共有秘密から生成されるため、トークンから生成されたＯＴＰに一致するはずである。一致が判明する場合、ユーザアイデンティティは検証され、認証サーバがインターネットサーバ１０５４に肯定応答を返すと、ユーザ・ログイン・プロセスは完了することになる。
ＦＳＥによるＯＴＰ生成には、次のような特徴がある。
・ＯＴＰシードは、安全な状態で（暗号化されて）カードに記憶される。
・パスワード生成アルゴリズムは、カードの内部で実行される。
・装置１０は、複数の仮想トークンをエミュレートすることができ、それぞれの仮想トークンでは異なるシードを記憶し、異なるパスワード生成アルゴリズムを使用することができる。
・認証サーバから装置にシードを移すセキュアプロトコルは、装置１０が提供する。
図４２は、ＳＳＡのＯＴＰシード提供機能とＯＴＰ生成機能を示すものである。ここで実線の矢印は所有権またはアクセス権を示し、破線の矢印は関連付けまたはリンクを示している。図４２に示すように、ＳＳＡ＿ＦＳＥシステム１１００では、Ｎ個のアプリケーションＡＣＲ１１０６によってそれぞれ管理される１つまたは複数の通信パイプ１１０４を通じて、ソフトウェア・プログラム・コードＦＳＥ＿１１０２にアクセスすることができる。後述する実施形態では、１つのみのＦＳＥソフトウェアアプリケーションを例示しており、各ＦＳＥアプリケーションにつき、１つのみの通信パイプがある。しかしながら、複数のＦＳＥアプリケーションを利用できることが理解されよう。図４２には、１つのみの通信パイプが例示されているが、複数の通信パイプを利用できることは理解されよう。このような変形例は、いずれも可能である。図４０Ａ、４０Ｂ、および４２を参照すると、ＦＳＥ＿１１０２はＯＴＰ提供に用いるアプリケーションであって、図４０Ａの装置内部アプリケーション１０１０の一部をなす場合がある。制御構造（ＡＣＲ＿１１０１、１１０３、１１０６、１１１０）はＳＳＡのセキュリティデータ構造の一部であり、ＳＳＡデータベース１０２６に記憶される。ＩＤＯ＿１１２０、ＳＤＯオブジェクト１１２２などのデータ構造、および、通信パイプ１１０４は、ＳＳＡデータベース１０２６に記憶される。
図４０Ａおよび図４０Ｂを参照すると、ＡＣＲおよびデータ構造に関わるセキュリティ関連操作（例えば、セッション中のデータ転送、暗号化、復号化、ハッシュ計算等の操作）は、インターフェース１０３２と暗号ライブラリ１０１２の支援を受けて、モジュール１０３０が処理する。ＳＳＭコアＡＰＩ＿１００６は、ホストと受渡しするＡＣＲ（外部ＡＣＲ）が関わる操作と、ホストと受渡ししない内部ＡＣＲが関わる操作を区別しないため、ホストが関わる操作と装置内部アプリケーション１０１０が関わる操作に区別はない。このように、ホスト側エンティティによるアクセスと装置内部アプリケーション１０１０によるアクセスは、同じ制御機構によって制御される。このため、ホスト側アプリケーションと装置内部アプリケーション１０１０とで、データ処理を柔軟に区別することができる。内部アプリケーション１０１０（例えば、図４２のＦＳＥ＿１１０２）は内部ＡＣＲ（例えば、図４２のＡＣＲ＿１１０３）と関連付けされ、これの管理のもとで起動する。
さらに、重要情報へのアクセス、例えば、ＳＤＯの内容またはそのＳＤＯの内容から検索される情報へのアクセスは、好ましくはＡＣＲやＡＧＰなどのセキュリティデータ構造とＳＳＡのルールとポリシーとによって管理されるため、外部または内部アプリケーションは、ＳＳＡのルールとポリシーとに従う限りにおいてその内容または情報にアクセスすることができる。例えば、２名のユーザが、データを処理するために個々の装置内部アプリケーション１０１０を起動する場合、別々の階層ツリーに位置する内部ＡＣＲを使用して２名のユーザによるアクセスが制御されるため、アプリケーション間のクロストークはない。このように、両ユーザは、データ処理する場合に共通の装置内部アプリケーション１０１０にアクセスすることができ、ＳＤＯの内容または情報の所有者の側では、内容または情報制御の喪失を心配せずに済む。例えば、データを記憶するＳＤＯに対する装置内部アプリケーション１０１０によるアクセスは、別々の階層ツリーに位置するＡＣＲによって制御できるため、アプリケーション間のクロストークはない。この制御方法は、前述した、データに対するアクセスをＳＳＡが制御する方法に似ている。これは、データオブジェクトに記憶されたデータのセキュリティを、内容の所有者とユーザに提供する。
図４２を参照すると、ＯＴＰ関連ホストアプリケーションに必要なソフトウェア・アプリケーション・コードの一部分を、ＦＳＥ＿１１０２のアプリケーションとしてメモリ装置１０に記憶（メモリカード発行前に予め記憶、またはメモリカード発行後にロード）することは可能である。そのようなコードを実行する場合、ホストは、まずＮ個の認証ＡＣＲ＿１１０６のいずれか１つを通じて認証し、パイプ１１０４にアクセスする必要がある。ここで、Ｎは正の整数である。ホストは、起動しようとするＯＴＰ関連アプリケーションを識別するためのアプリケーションＩＤを提供する必要もある。認証に成功すると、ＯＴＰ関連アプリケーションと関連付けられたパイプ１１０４を通じてそのようなコードにアクセスし、実行することができる。前述したように、パイプ１１０４と、ＯＴＰ関連内部アプリケーションなどの特定アプリケーションとの間には、好ましくは１対１の関係がある。図４２に示すように、複数のＡＣＲ＿１１０６が、共通のパイプ１１０４を制御することがある。１つのＡＣＲで、複数のパイプを制御する場合もある。
図４２には、オブジェクト１１１４と総称されるセキュア・データ・オブジェクトＳＤＯ１、ＳＤＯ２、およびＳＤＯ３が示されている。セキュア・データ・オブジェクトの各々は、ＯＴＰ生成のためのシードなどのデータを含んでおり、そのシードは有益であるため、暗号化されていることが好ましい。３つのデータオブジェクトとＦＳＥ＿１１０２との間のリンクまたは関連付け１１０８は、これらのオブジェクトの一属性を図示している。いずれか１つのオブジェクトにアクセスするときには、ＳＤＯ属性内のアプリケーションＩＤに一致するＦＳＥ＿１１０２のアプリケーションが起動する。このアプリケーションは、メモリ装置のＣＰＵ＿１２によって実行され、さらなるホストコマンドを受け取る必要はない（図１）。
図４２を参照すると、ＯＴＰプロセスを制御するためのセキュリティデータ構造（ＡＣＲ＿１１０１、１１０３、１１０６、および１１１０）とそのＰＣＲは、ユーザがＯＴＰプロセスを開始する前に作成済みである。ユーザは、認証サーバＡＣＲ＿１１０６のいずれか１つを通じて、ＯＴＰ装置内部アプリケーション１１０２を起動するためのアクセス権を得る必要がある。ユーザは、Ｎ個のユーザＡＣＲ＿１１１０のいずれか１つを通じて、作成されるＯＴＰに対するアクセス権を得る必要もある。ＳＤＯ＿１１１４は、ＯＴＰのシード提供プロセスで作成することができる。ＩＤＯ＿１１１６は、作成済みで内部ＡＣＲ＿１１０３によって制御されてもよい。内部ＡＣＲ＿１１０３は、作成されたＳＤＯ＿１１１４も制御する。ＳＤＯ＿１１１４にアクセスするときには、図４０ＢのＳＳＡ管理部１０２４が、自動的にＡＣＲ＿１１０３にログインする。内部ＡＣＲ＿１１０３には、ＦＳＥ＿１１０２が関連付けられる。破線１１０８で示すように、ＯＴＰのシード提供プロセスではＳＤＯ＿１１１４にＦＳＥを関連付けられるようになる。関連付けが成立した後、ホストがＳＤＯにアクセスするときには、ホストからさらなる要求がなくとも、関連付け１１０８によってＦＳＥ１１０２が起動する。Ｎ個のＡＣＲ＿１１０６のいずれか１つを通じて通信パイプ１１０４にアクセスするときにも、図４０ＢのＳＳＡ管理部１０２４が、ＡＣＲ＿１１０３に自動的にログインする。いずれの場合でも（ＳＤＯ＿１１１４とパイプ１１０４へのアクセス）、ＳＳＡ管理部はＦＳＥ＿１１０２にセッション番号を渡し、このセッション番号によって内部ＡＣＲ＿１１０３に至るチャネルが識別される。
ＯＴＰ操作は、２つの段階、すなわち図４３に示すシード提供段階と、図４４に示すＯＴＰ生成段階とを伴う。図４０〜図４２も併せて参照することで、この説明に役立つ。図４３は、シード提供プロセスを示すプロトコル図である。図４３に示すように、ホスト２４などのホストとカードは、様々な動作をとる。ＳＳＭコア１００４を含む図４０Ａおよび４０ＢのＳＳＭシステムは、カード側で様々な動作をとる１エンティティである。図４２に示すＦＳＥ＿１１０２も、カード側で様々な動作をとるエンティティである。
二因子認証では、ユーザがシードの発行を要求し、発行されたシードはセキュアトークンに記憶される。この例のセキュアトークンは、メモリ装置またはカードである。ユーザは、ＳＳＭシステムにアクセスするため、図４２の認証ＡＣＲ＿１１０６のいずれか１つを認証する（矢印１１２２）。認証に成功したと仮定すると（矢印１１２４）、ユーザはシードを要求する（矢印１１２６）。ホストは、シード要求に署名するためのアプリケーション１１０２を選択して、シード要求に署名する要求をカードへ送信する。起動すべきアプリケーションＩＤをユーザが知らない場合、例えば装置に対する取扱い注意クエリにより、この情報を装置１０から入手することができる。そして、ユーザは、起動するべきアプリケーションのアプリケーションＩＤを入力し、これによりこのアプリケーションに対応する通信パイプも選択される。パス・スルー・コマンドにより、ユーザから、対応する通信パイプを通じて、アプリケーションＩＤで指定されたアプリケーションに、ユーザコマンドが転送される（矢印１１２８）。起動したアプリケーションは、図４２のＩＤＯ＿１１１２などの所定のＩＤＯの公開鍵による署名を要求する。
ＳＳＭシステムは、ＩＤＯの公開鍵を用いてシード要求に署名し、署名の完了をアプリケーションに通知する（矢印１１３２）。次に、起動アプリケーションはＩＤＯの証明書連鎖を要求する（矢印１１３４）。これに応じて、ＳＳＭシステムは、ＡＣＲ＿１１０３の制御下でＩＤＯの証明書連鎖を提供する。起動アプリケーションは、通信パイプを通じて署名済みシード要求とＩＤＯの証明書連鎖をＳＳＭシステムに提供し、ＳＳＭシステムは、同じものをホストへ転送する（矢印１１３８）。通信パイプにおける署名済みシード要求とＩＤＯ証明書連鎖の送信は、図４０ＡのＳＡＭＭ＿１００８とＳＳＭコア１００４との間で確立するコールバック関数によって行われるが、このコールバック関数については以降で詳しく説明する。
ホストによって受信されたＩＤＯ証明書連鎖および署名済みシード要求は、図４１に示す認証サーバ１０５２へ送信される。署名済みシード要求の出所が信用できるトークンであることは、カードから提供される証明書連鎖で証明されているため、認証サーバ１０５２には、秘密シードをカードに提供する用意がある。そこで認証サーバ１０５２は、ＩＤＯの公開鍵で暗号化されたシードを、ユーザＡＣＲ情報とともにホストに送信する。このユーザ情報により、Ｎ個のユーザＡＣＲのうち、これから生成するＯＴＰにユーザがアクセスするためのユーザＡＣＲがいずれであるかが明らかになる。ホストは、アプリケーションＩＤを提供することによってＦＳＥ＿１１０２でＯＴＰアプリケーションを起動し、これによりこのアプリケーションに対応する通信パイプも選択され、さらにホストはユーザＡＣＲ情報をＳＳＭシステムへ転送する（矢印１１４０）。暗号化されたシードとユーザＡＣＲ情報は、この後、通信パイプを通じて、選択されたアプリケーションに転送される（矢印１１４２）。起動アプリケーションは、ＩＤＯの秘密鍵を用いてシードを復号化する要求を、ＳＳＭシステムに送信する（矢印１１４４）。ＳＳＭシステムはシードを復号化し、復号化の完了を伝える通知をアプリケーションに送信する（矢印１１４６）。起動アプリケーションは、この後、セキュア・データ・オブジェクトを作成し、そのセキュア・データ・オブジェクトにシードを記憶することを要求する。起動アプリケーションは、ワン・タイム・パスワードを生成するため、そのＳＤＯにＯＴＰアプリケーション（要求するアプリケーションと同じアプリケーションであってもよい）のＩＤを割り振ることも要求する。ＳＳＭシステムは、ＳＤＯ＿１１１４のいずれか１つを作成し、そのＳＤＯの中にシードを記憶し、ＯＴＰアプリケーションのＩＤをＳＤＯに割り振り、完了するとアプリケーションに通知を送信する（矢印１１５０）。アプリケーションは、この後、ホストから提供されたユーザ情報に基づき、ＳＤＯ＿１１１４にアクセスするためのアクセス権を内部ＡＣＲから該当するユーザＡＣＲへ委譲することを、ＳＳＭシステムに要求する（矢印１１５２）。委譲が完了すると、ＳＳＭシステムはアプリケーションに通知する（矢印１１５４）。アプリケーションは、この後、コールバック関数により、ＳＤＯの名前（スロットＩＤ）を通信パイプ経由でＳＳＭシステムに送信する（矢印１１５６）。ＳＳＭシステムは、この後、同じものをホストへ転送する（矢印１１５８）。ホストは、この後、ＳＤＯの名前をユーザＡＣＲに結合し、このため、ユーザはＳＤＯにアクセスできるようになる。
ここで、図４４のプロトコル図を参照して、ＯＴＰ生成プロセスを説明する。ユーザは、ワン・タイム・パスワードを入手するため、アクセス権があるユーザＡＣＲにログインする（矢印１１７２）。認証に成功した場合を仮定すると、ＳＳＭシステムはホストに通知し、ホストは「ｇｅｔ＿ＳＤＯ」コマンドをＳＳＭへ送信する（矢印１１７４、１１７６）。前述したように、シードを記憶するＳＤＯには、ＯＴＰを生成するアプリケーションが関連付けられている。したがって、これまでのように通信パイプ経由でアプリケーションを選択する代わりに、矢印１１７６のコマンドでアクセスするＳＤＯと、ＯＴＰ生成アプリケーションと、の関連付けによって、ＯＴＰ生成アプリケーションを起動する（矢印１１７８）。ＯＴＰ生成アプリケーションは、この後、ＳＤＯからコンテンツ（すなわち、シード）を読み出すことを、ＳＳＭシステムに要求する。ＳＳＭは、ＳＤＯのコンテンツに含まれる情報を認識せず、ＦＳＥの指示に従ってＳＤＯのデータを処理するだけであることが好ましい。シードが暗号化されている場合、ＦＳＥの指示に従い読出しを行う前に、シードを復号化することが必要となる場合がある。ＳＳＭシステムは、ＳＤＯからシードを読み出し、ＯＴＰ生成アプリケーションにシードを提供する（矢印１１８２）。ＯＴＰ生成アプリケーションは、この後、ＯＴＰを生成し、これをＳＳＭシステムに提供する（矢印１１８４）。ＯＴＰは、ＳＳＭによってホストへ転送され（矢印１１８６）、さらにホストから認証サーバ１０５２にＯＴＰが転送され、二因子認証プロセスは完了する。
＜コールバック関数＞
図４０ＡのＳＳＭコア＿１００４とＳＡＭＭ＿１００８との間では、汎用コールバック関数が確立する。このような関数には、様々な装置内部アプリケーションと通信パイプを登録することができる。起動した装置内部アプリケーションは、このコールバック関数を使用することにより、アプリケーションへのホストコマンドの引渡しに使用されたものと同じ通信パイプを使用して、処理後のデータをＳＳＭシステムへ引き渡すことができる。
＜ＤＲＭシステム実施形態＞
図４５は、ＤＲＭシステムを示す機能ブロック図である。このシステムは、通信パイプ１１０４’と、ＦＳＥアプリケーション１１０２’に至るリンク１１０８’を備えるＣＥＫ１１１４’と、ＤＲＭ機能の実行機能を制御する制御構造１１０１’、１１０３’、１１０６’と、を採用している。見て分かるように、セキュリティデータ構造が、認証サーバＡＣＲとユーザＡＣＲの代わりにライセンスサーバＡＣＲ１１０６’と再生ＡＣＲ１１１０’とを含んでおり、ＳＤＯの代わりにＣＥＫ１１１４’を含んでいる点を除いて、図４５のアーキテクチャは図４２のものによく似ている。加えて、ＩＤＯは関係しないので、図４５では省かれている。ＣＥＫ１１１４’は、ライセンス提供プロセスの中で作成することができる。プロトコル図である図４６は、ライセンス提供とコンテンツダウンロードのプロセスを示すものであり、ここではライセンスオブジェクトの中で鍵が提供される。ＯＴＰの実施形態に見られるように、ライセンスの取得を望むユーザはまず、Ｎ個のＡＣＲ１１０６’のいずれか１つとＮ個のＡＣＲ１１１０’のいずれか１つのもとでアクセス権を取得する必要があり、そうすることで、メディア・プレーヤ・ソフトウェア・アプリケーションなどのメディアプレーヤによってコンテンツを提供できるようになる。
図４６に示すように、ホストは、ライセンスサーバＡＣＲ１１０６’を認証する（矢印１２０２）。認証に成功したと仮定すると（矢印１２０４）、ライセンスサーバは、ライセンスファイルをＣＥＫ（鍵ＩＤと鍵値）とともにホストに提供する。ホストは、カード上のＳＳＭシステムにアプリケーションＩＤを提供することによって、起動すべきアプリケーションも選択する。ホストは、プレーヤ情報（例えば、メディア・プレーヤ・ソフトウェア・アプリケーションの情報）も送信する（矢印１２０６）。このプレーヤ情報により、Ｎ個の再生ＡＣＲ＿１１１０’のうち、プレーヤのアクセス権がある再生ＡＣＲがいずれであるかが明らかになる。ＳＳＭシステムは、選択されたアプリケーションに対応する通信パイプを通じて、ライセンスファイルとＣＥＫをＤＲＭアプリケーションへ転送する（矢印１２０８）。起動したアプリケーションは、この後、ライセンスファイルを非表示パーティションに書き込むことをＳＳＭシステムに要求する（矢印１２１０）。ライセンスファイルがその通りに書き込まれると、ＳＳＭシステムは、アプリケーションに通知する（矢印１２１２）。ＤＲＭアプリケーションは、この後、ＣＥＫオブジェクト１１１４’の作成を要求し、ライセンスファイルからその中に鍵値を記憶する。ＤＲＭアプリケーションは、提供された鍵に関連するライセンスをチェックするＤＲＭアプリケーションのＩＤを、ＣＥＫオブジェクトに割り振ることも要求する（矢印１２１４）。ＳＳＭシステムはこれらのタスクを完了し、その旨をアプリケーションに通知する（矢印１２１６）。アプリケーションは、この後、ホストから送信されたプレーヤ情報に基づいて、ＣＥＫ１１１４’に対するコンテンツの読出しアクセス権をプレーヤがアクセスできる再生ＡＣＲに委譲することを要求する（矢印１２１８）。ＳＳＭシステムは委譲を行い、その旨をアプリケーションに通知する（矢印１２２０）。ライセンスの記憶が完了したことを伝えるメッセージが、アプリケーションから通信パイプを経由しＳＳＭシステムへ送信され、ＳＳＭシステムはこれをライセンスサーバに転送する（矢印１２２２および１２２４）。通信パイプ経由のこのアクションには、コールバック関数を使用する。この通知を受信したライセンスサーバは、この後、提供されたＣＥＫの鍵値によって暗号化されたコンテンツファイルをカードに提供する。暗号化されたコンテンツは、ホストによってカードの公開領域に記憶される。暗号化されたコンテンツファイルの記憶にセキュリティ機能は関与しないため、ＳＳＭシステムは記憶に関与しない。
図４７は、再生操作を示す。ユーザは、ホストを通じて、該当する再生ＡＣＲ（すなわち、前述した矢印１１５２および１１５４で読出し権を委譲された再生ＡＣＲ）を認証する（矢印１２４２）。認証に成功したと仮定すると（矢印１２４４）、ユーザは、この後、鍵ＩＤと関連付けられたコンテンツの読出し要求を送信する（矢印１２４６）。要求を受信したＳＳＭシステムは、アクセスされているＤＲＭアプリケーションのＩＤがＣＥＫオブジェクトに関連付けられていることに気付き、識別されたＤＲＭアプリケーションを起動する（矢印１２４８）。このＤＲＭアプリケーションは、鍵ＩＤと関連付けられたデータ（すなわち、ライセンス）の読出しを、ＳＳＭシステムに要求する（矢印１２５０）。読出し要求があったデータの情報を認識しないＳＳＭは、ＦＳＥからの要求を処理してデータの読出しプロセスを実行するだけである。ＳＳＭシステムは、非表示パーティションからデータ（すなわち、ライセンス）を読み出し、そのデータをＤＲＭアプリケーションに提供する（矢印１２５２）。ＤＲＭアプリケーションは、この後、データを解釈し、データの中にあるライセンス情報をチェックして、ライセンスが有効かどうかを確認する。ライセンスがなお有効である場合、ＤＲＭアプリケーションは、コンテンツの復号化が許可されることをＳＳＭシステムに知らせる（矢印１２５４）。ＳＳＭシステムは、この後、要求のあったコンテンツをＣＥＫオブジェクトの鍵値を使用して復号化し、復号化されたコンテンツを再生するためにホストに提供する（矢印１２５６）。ライセンスが既に有効でない場合、コンテンツアクセスの要求は拒絶される。
ライセンスサーバからのライセンスファイルで鍵が提供されない場合の、ライセンス提供とコンテンツのダウンロードは、図４６に示す場合といくぶん異なる。図４８のプロトコル図は、そのような別方式を示す。図４６および図４８で同じステップは、同じ数字で識別されている。それゆえ、ホストとＳＳＭシステムは、まず初めに認証に取り組む（矢印１２０２、１２０４）。ライセンスサーバは、ホストにライセンスファイルと鍵ＩＤを提供するが鍵値は提供せず、ホストはそれらを、起動しようとするＤＲＭアプリケーションのアプリケーションＩＤとともに、ＳＳＭシステムへ転送する。ホストは、プレーヤ情報も送信する（矢印１２０６’）。ＳＳＭシステムは、この後、選択されたアプリケーションに対応する通信パイプを通じて選択されたＤＲＭアプリケーションに、ライセンスファイルと鍵ＩＤを転送する（矢印１２０８）。ＤＲＭアプリケーションは、非表示パーティションへのライセンスファイル書込みを要求する（矢印１２１０）。ライセンスファイルがその通りに書き込まれると、ＳＳＭシステムは、ＤＲＭアプリケーションに通知する（矢印１２１２）。ＤＲＭアプリケーションは、この後、鍵値を生成することと、ＣＥＫオブジェクトを作成することと、そこに鍵値を記憶することと、ＣＥＫオブジェクトにＤＲＭアプリケーションのＩＤを割り振ることと、をＳＳＭシステムに要求する（矢印１２１４’）。要求に応じたＳＳＭシステムは、ＤＲＭアプリケーションへ通知を送信する（矢印１２１６）。ＤＲＭアプリケーションは、この後、ホストからのプレーヤ情報に基づいて、ＣＥＫオブジェクトに対する読出しアクセス権を再生ＡＣＲに委譲することを、ＳＳＭシステムに要求する（矢印１２１８）。これが完了すると、ＳＳＭシステムは、その旨をＤＲＭアプリケーションに通知する（矢印１２２０）。ＤＲＭアプリケーションは、この後、ライセンスが記憶されたことをＳＳＭシステムに通知するが、この通知は、コールバック関数により通信パイプ経由で送信される（矢印１２２２）。この通知は、ＳＳＭシステムによってライセンスサーバに転送される（矢印１２２４）。ライセンスサーバは、この後、鍵ＩＤと関連付けられたコンテンツファイルをＳＳＭシステムへ送信する（矢印１２２６）。ＳＳＭシステムは、鍵ＩＤによって識別された鍵値でコンテンツファイルを暗号化するが、アプリケーションはこれに一切関与しない。暗号化されカードに記憶されたコンテンツは、図４７のプロトコルを用いて再生することができる。
前述したＯＴＰ実施形態とＤＲＭ実施形態で、ホスト装置は、様々なＯＴＰアプリケーションとＤＲＭアプリケーションを、ＦＳＥ１１０２および１１０２’で選ぶことができる。ユーザは、所望の装置内部アプリケーションを選択し、起動することができる。しかし、ＳＳＭモジュールとＦＳＥとの全体的な関係は常に同じであるため、ユーザとデータの提供者は、ＳＳＭモジュールとの受渡しやＦＳＥを起動する場合に標準のプロトコル群を使用することができる。ユーザと提供者は、独自に開発されたものを含む様々な装置内部アプリケーションの詳細に関わる必要はない。
さらに、図４６および図４８の場合と同様に、提供プロトコルはいくぶん異なることがある。図４６の場合、ライセンスオブジェクトは鍵値を含むが、図４８の場合は鍵値を含まない。このような違いから、前述したような若干異なるプロトコルが必要となる。しかしながら、図４７における再生は、ライセンス提供のあり方にかかわりなく同じである。したがって、この違いが問題となるのは、通常であればコンテンツの提供者と配布者のみであって、再生段階にしか通常かかわらない消費者には関係ない。それゆえ、このアーキテクチャは、プロトコルをカスタマイズする場合にコンテンツの提供者や配布者に多大な柔軟性を提供しつつ、消費者にとっては扱い易い状態のままである。当然ながら、３つ以上の提供プロトコル群によって提供されるデータから検索される情報でも、第２のプロトコルを用いてアクセスすることができる。
前述した実施形態から提供される別の利点として、ユーザなどの外部エンティティと装置内部アプリケーションは、いずれもセキュリティデータ構造によって制御されるデータを利用するが、ユーザがアクセスできるものは装置内部アプリケーションによって記憶データから検索される結果のみである。それゆえ、ＯＴＰ実施形態の場合、ホスト装置を通じてユーザが入手できるものはＯＴＰのみであって、シード値は入手することができない。ＤＲＭ実施形態では、ホスト装置を通じてユーザが入手できるものは再生されたコンテンツのみであって、ライセンスファイルまたは暗号鍵のいずれにもアクセスすることができない。このため、セキュリティを損なうことなく消費者の便宜を図ることができる。
ＤＲＭの一実施形態では、装置内部アプリケーションもホストも暗号鍵にアクセスせず、セキュリティデータ構造のみがこれにアクセスする。他の実施形態では、セキュリティデータ構造以外のエンティティも暗号鍵にアクセスすることができる。鍵が装置内部アプリケーションによって生成され、セキュリティデータ構造によって制御される場合もある。
装置内部アプリケーションと情報（例えば、ＯＴＰや再生コンテンツ）へのアクセスは、同じセキュリティデータ構造によって制御される。これは、制御システムの複雑さとコストを抑える。
装置内部アプリケーションに対するアクセスを制御する内部ＡＣＲから、装置内部アプリケーションを起動することによって得られる情報に対するホストのアクセスを制御するＡＣＲに、アクセス権を委譲する能力を提供することにより、前述した特徴および機能が実現可能となる。
＜アプリケーション別失効制度＞
セキュリティデータ構造のアクセス制御プロトコルは、装置内部アプリケーションの起動時に修正することもできる。例えば、証明書失効プロトコルは、ＣＲＬを使用する標準のプロトコルまたは独自のプロトコルのいずれでもよい。それゆえ、ＦＳＥを起動することにより、標準のＣＲＬ失効プロトコルをＦＳＥ独自プロトコルに差し替えることができる。
ＣＲＬ失効制度をサポートすることに加えて、ＳＳＡは、装置内部アプリケーションとＣＡあるいはその他の取消機関との間の私的通信チャネルを通じて、装置に常駐する内部アプリケーションにホストを無効にさせることができる。内部アプリケーション独自の失効制度は、ホスト−アプリケーションの関係に限定される。
アプリケーション別失効制度が構成される場合、ＳＳＡシステムは、ＣＲＬ（提供される場合）を拒絶することになり、そうでない場合には証明書と独自のアプリケーションデータ（アプリケーション別通信パイプを通じて提供済みのデータ）を用いて所与の証明書が失効済みか否かを判定する。
前述したように、ＡＣＲでは、失効値を指定することによって３つの失効制度（失効制度なし、標準ＣＲＬ制度、アプリケーション別失効制度）のどれを採用するかを指定する。アプリケーション別失効制度を選定する場合、その失効制度を担当する内部アプリケーションＩＤもＡＣＲで指定し、ＣＥＴ／ＡＰＰ＿ＩＤフィールドの値は失効制度を担当する内部アプリケーションＩＤに対応することになる。装置を認証する場合、ＳＳＡシステムは、内部アプリケーション独自の制度に準拠する。
１組のプロトコルを別のものに差し替える代わりに、装置内部アプリケーションを起動する場合、ＳＳＡによって既に施行されているアクセス制御に、追加のアクセス条件を設けることもできる。例えば、ＣＥＫの鍵値に対するアクセス権を、ＦＳＥで精査することができる。鍵値のアクセス権がＡＣＲにあると判定したＳＳＡシステムは、ＦＳＥと相談のうえでアクセスを許諾する。これは、コンテンツへのアクセスを制御する場合にコンテンツの所有者に多大な柔軟性を提供する。
これまで様々な実施形態を参照して本発明を説明してきたが、本発明の範囲から逸脱することなく変更や修正を施すことができ、本発明の範囲が専ら添付の特許請求の範囲とその同等物とによって定まるものであることは理解されよう。

Claims (16)

  1. 証明書が失効とされるかどうかを判定する方法であって、
    不揮発性記憶装置が動作可能にホストに接続されている間に、不揮発性記憶装置で実行され、
    （ａ）前記ホストの前記不揮発性記憶装置への認証を試行するために、前記ホストから証明書を受信するステップと、
    （ｂ）前記不揮発性記憶装置にキャッシュされた証明書失効リスト内を、証明書についてのリファレンスを検索することによって、証明書が失効とされるかどうかを判定するステップと、
    を備え、
    前記ホストの前記不揮発性記憶装置への認証を試行するための前記証明書を前記不揮発性記憶装置が受信する前に、前記証明書失効リストはキャッシュされて最新の状態にされる、方法。
  2. 前記検索によって前記証明書失効リスト内から証明書についてのリファレンスが取得される場合に、前記ホストを認証するための前記試行を拒絶するステップをさらに備える、請求項１に記載の方法。
  3. 前記ホストから証明書失効リストを受信するステップ、をさらに備え、
    前記ホストから受信した前記証明書失効リストが前記不揮発性記憶装置内の現在の証明書失効リストよりも新しく、前記受信した証明書失効リストが前記証明書の発行者によって発行されたと判定されることによって前記ホストから受信した前記証明書失効リストが検証される場合に、（ｂ）のステップを実行する代わりに、
    前記現在の証明書失効リストを前記新しい証明書失効リストに置換するステップと、
    前記ホストからの前記証明書が失効とされるかどうか判定するために、前記新しい証明書失効リストを使用するステップと、を実行する、請求項１に記載の方法。
  4. 前記不揮発性記憶装置の製造時に、前記証明書失効リストが前記不揮発性記憶装置に記憶される、請求項１に記載の方法。
  5. 前記証明書失効リストはアカウントに関連付けられており、
    前記証明書失効リストは前記アカウントの生成時に記憶される、請求項１に記載の方法。
  6. 前記ホストによる前記不揮発性記憶装置を認証するための試行の前に、前記不揮発性記憶装置に記憶された証明書失効リストが実質的に存在する場合に、（ｂ）のステップは実行され、
    そうでない場合には、
    前記ホストから証明書失効リストを受信するステップと、
    前記ホストから受信した前記証明書失効リストをキャッシュするステップと、
    前記ホストからの前記証明書が失効かどうかを判定するために、前記ホストから受信されキャッシュされた証明書失効リストを使用するステップと、を実行する、請求項１に記載の方法。
  7. 前記ホストによる前記不揮発性記憶装置を認証するための試行の前に、前記不揮発性記憶装置に記憶された証明書失効リストが実質的に存在する場合に、（ｂ）のステップは実行され、
    そうでない場合には、証明書失効リストが前記ホストによって供給されない場合に、前記試行を拒絶する、請求項１に記載の方法。
  8. 前記証明書失効リストは、失効とされた証明書の通し番号を備えている、請求項１に記載の方法。
  9. 不揮発性記憶装置であって、
    証明書失効リストを記憶するメモリと、
    （ａ）前記ホストの前記不揮発性記憶装置への認証を試行するために、前記ホストから証明書を受信するステップと、（ｂ）前記不揮発性記憶装置にキャッシュされた証明書失効リスト内を、証明書についてのリファレンスを検索することによって、証明書が失効とされるかどうかを判定するステップと、を実行する制御部と、
    を備える不揮発性記憶装置。
  10. 前記制御部は、
    前記検索によって前記証明書失効リスト内から証明書についてのリファレンスが取得される場合に、前記ホストを認証するための前記試行を拒絶するステップをさらに実行する、請求項９に記載の不揮発性記憶装置。
  11. 前記制御部は、
    前記ホストから証明書失効リストを受信するステップと、
    前記ホストから受信した前記証明書失効リストが前記不揮発性記憶装置内の現在の証明書失効リストよりも新しく、前記受信した証明書失効リストが前記証明書の発行者によって発行されたと判定されることによって前記ホストから受信した前記証明書失効リストが検証される場合に、（ｂ）のステップを実行する代わりに、前記現在の証明書失効リストを前記新しい証明書失効リストに置換するステップと、
    前記ホストからの前記証明書が失効とされるかどうか判定するために、前記新しい証明書失効リストを使用するステップと、
    をさらに実行する、請求項９に記載の不揮発性記憶装置。
  12. 前記不揮発性記憶装置の製造時に、前記証明書失効リストが前記不揮発性記憶装置に記憶される、請求項９に記載の不揮発性記憶装置。
  13. 前記証明書失効リストはアカウントに関連付けられており、
    前記証明書失効リストは前記アカウントの生成時に記憶される、請求項９に記載の不揮発性記憶装置。
  14. 前記制御部は、
    前記ホストによる前記不揮発性記憶装置を認証するための試行の前に、前記不揮発性記憶装置に記憶された証明書失効リストが実質的に存在する場合に、（ｂ）のステップを実行し、
    そうでない場合には、
    前記ホストから証明書失効リストを受信するステップと、
    前記ホストから受信した前記証明書失効リストをキャッシュするステップと、
    前記ホストからの前記証明書が失効かどうかを判定するために、前記ホストから受信されキャッシュされた証明書失効リストを使用するステップと、を実行する、請求項９に記載の不揮発性記憶装置。
  15. 前記制御部は、
    前記ホストによる前記不揮発性記憶装置を認証するための試行の前に、前記不揮発性記憶装置に記憶された証明書失効リストが実質的に存在する場合に、（ｂ）のステップを実行し、
    そうでない場合には、証明書失効リストが前記ホストによって供給されない場合に、前記試行を拒絶する、請求項９に記載の不揮発性記憶装置。
  16. 前記証明書失効リストは、失効とされた証明書の通し番号を備えている、請求項９に記載の不揮発性記憶装置。
JP2012544547A 2009-12-17 2010-11-19 証明書失効リストを用いたコンテンツ管理方法 Withdrawn JP2013514587A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US12/641,160 US20100138652A1 (en) 2006-07-07 2009-12-17 Content control method using certificate revocation lists
US12/641,160 2009-12-17
PCT/US2010/057425 WO2011075281A1 (en) 2009-12-17 2010-11-19 Content control method using certificate revocation lists

Publications (1)

Publication Number Publication Date
JP2013514587A true JP2013514587A (ja) 2013-04-25

Family

ID=43608711

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012544547A Withdrawn JP2013514587A (ja) 2009-12-17 2010-11-19 証明書失効リストを用いたコンテンツ管理方法

Country Status (7)

Country Link
US (1) US20100138652A1 (ja)
EP (1) EP2513901A1 (ja)
JP (1) JP2013514587A (ja)
KR (1) KR20120093375A (ja)
CN (1) CN102906755A (ja)
TW (1) TW201136266A (ja)
WO (1) WO2011075281A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015092953A1 (ja) * 2013-12-16 2015-06-25 パナソニックＩｐマネジメント株式会社 認証システムおよび認証方法
JP2016534629A (ja) * 2013-08-23 2016-11-04 クアルコム，インコーポレイテッド プリコード化されたパケットのハッシュ処理を使用したセキュアなコンテンツ配信
JP2019521416A (ja) * 2016-05-11 2019-07-25 アリババ グループ ホウルディング リミテッド アイデンティティ検証方法及びシステム並びにインテリジェントウェアラブルデバイス

Families Citing this family (93)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7748031B2 (en) 2005-07-08 2010-06-29 Sandisk Corporation Mass storage device with automated credentials loading
US9794247B2 (en) * 2006-08-22 2017-10-17 Stmicroelectronics, Inc. Method to prevent cloning of electronic components using public key infrastructure secure hardware device
US20110191581A1 (en) * 2009-08-27 2011-08-04 Telcordia Technologies, Inc. Method and system for use in managing vehicle digital certificates
KR101490468B1 (ko) * 2010-02-04 2015-02-06 삼성전자 주식회사 데이터 처리 장치 및 방법
US9178869B2 (en) 2010-04-05 2015-11-03 Google Technology Holdings LLC Locating network resources for an entity based on its digital certificate
JP5552917B2 (ja) * 2010-06-24 2014-07-16 ソニー株式会社 情報処理装置、および情報処理方法、並びにプログラム
JP2012008756A (ja) * 2010-06-24 2012-01-12 Sony Corp 情報処理装置、および情報処理方法、並びにプログラム
US20120016999A1 (en) * 2010-07-14 2012-01-19 Sap Ag Context for Sharing Data Objects
US20130139242A1 (en) * 2010-08-20 2013-05-30 Zte Corporation Network Accessing Device and Method for Mutual Authentication Therebetween
US9240965B2 (en) 2010-08-31 2016-01-19 Sap Se Methods and systems for business interaction monitoring for networked business process
FR2970612B1 (fr) * 2011-01-19 2013-01-04 Natural Security Procede d'authentification d'un premier equipement de communication par un second equipement de communication
US20120294445A1 (en) * 2011-05-16 2012-11-22 Microsoft Corporation Credential storage structure with encrypted password
US9244956B2 (en) 2011-06-14 2016-01-26 Microsoft Technology Licensing, Llc Recommending data enrichments
US9628875B1 (en) * 2011-06-14 2017-04-18 Amazon Technologies, Inc. Provisioning a device to be an authentication device
US9147195B2 (en) * 2011-06-14 2015-09-29 Microsoft Technology Licensing, Llc Data custodian and curation system
JP5776432B2 (ja) * 2011-08-11 2015-09-09 ソニー株式会社 情報処理装置、および情報処理方法、並びにプログラム
US9785491B2 (en) * 2011-10-04 2017-10-10 International Business Machines Corporation Processing a certificate signing request in a dispersed storage network
KR102024869B1 (ko) * 2011-11-14 2019-11-22 삼성전자주식회사 저장 장치를 인증하기 위한 방법, 호스트 장치 및 기계로 읽을 수 있는 저장 매체
JP5786670B2 (ja) * 2011-11-17 2015-09-30 ソニー株式会社 情報処理装置、情報記憶装置、情報処理システム、および情報処理方法、並びにプログラム
US8918855B2 (en) * 2011-12-09 2014-12-23 Blackberry Limited Transaction provisioning for mobile wireless communications devices and related methods
US9026789B2 (en) 2011-12-23 2015-05-05 Blackberry Limited Trusted certificate authority to create certificates based on capabilities of processes
US9426145B2 (en) * 2012-02-17 2016-08-23 Blackberry Limited Designation of classes for certificates and keys
US10455071B2 (en) 2012-05-09 2019-10-22 Sprint Communications Company L.P. Self-identification of brand and branded firmware installation in a generic electronic device
JP5935883B2 (ja) * 2012-05-21 2016-06-15 ソニー株式会社 情報処理装置、情報処理システム、および情報処理方法、並びにプログラム
US9225675B2 (en) 2012-08-08 2015-12-29 Amazon Technologies, Inc. Data storage application programming interface
US9904788B2 (en) 2012-08-08 2018-02-27 Amazon Technologies, Inc. Redundant key management
US10558581B1 (en) * 2013-02-19 2020-02-11 Amazon Technologies, Inc. Systems and techniques for data recovery in a keymapless data storage system
US9811476B2 (en) 2013-02-28 2017-11-07 Panasonic Intellectual Property Management Co., Ltd. Encryption and recording apparatus, encryption and recording system, and encryption and recording method
CN104053149B (zh) * 2013-03-12 2017-11-14 电信科学技术研究院 一种实现车联网设备的安全机制的方法及***
US9306943B1 (en) * 2013-03-29 2016-04-05 Emc Corporation Access point—authentication server combination
US9743271B2 (en) * 2013-10-23 2017-08-22 Sprint Communications Company L.P. Delivery of branding content and customizations to a mobile communication device
US10506398B2 (en) 2013-10-23 2019-12-10 Sprint Communications Company Lp. Implementation of remotely hosted branding content and customizations
WO2015092967A1 (ja) * 2013-12-16 2015-06-25 パナソニックＩｐマネジメント株式会社 認証システム、認証方法および認証装置
US9280679B2 (en) 2013-12-31 2016-03-08 Google Inc. Tiered application permissions
US9256755B2 (en) * 2013-12-31 2016-02-09 Google Inc. Notification of application permissions
US9681251B1 (en) 2014-03-31 2017-06-13 Sprint Communications Company L.P. Customization for preloaded applications
CN105100031B (zh) * 2014-05-23 2019-05-17 北京奇虎科技有限公司 一种批量添加信任的方法、装置和***
JP6404928B2 (ja) * 2014-07-28 2018-10-17 エンクリプティア株式会社 ユーザ情報管理システム、及びユーザ情報管理方法
US9992326B1 (en) 2014-10-31 2018-06-05 Sprint Communications Company L.P. Out of the box experience (OOBE) country choice using Wi-Fi layer transmission
EP3223453B1 (en) * 2014-11-19 2019-03-06 Huawei Technologies Co., Ltd. Directional traffic statistics method, device and system
KR102485830B1 (ko) 2015-02-13 2023-01-09 삼성전자주식회사 보안 정보의 처리
US20160261412A1 (en) * 2015-03-04 2016-09-08 Avaya Inc. Two-Step Authentication And Activation of Quad Small Form Factor Pluggable (QFSP+) Transceivers
US9398462B1 (en) 2015-03-04 2016-07-19 Sprint Communications Company L.P. Network access tiered based on application launcher installation
US20160379207A1 (en) * 2015-06-25 2016-12-29 Intel Corporation Secured credential aggregator
US9760730B2 (en) * 2015-08-28 2017-09-12 Dell Products L.P. System and method to redirect and unlock software secure disk devices in a high latency environment
US10097534B2 (en) * 2015-08-28 2018-10-09 Dell Products L.P. System and method to redirect hardware secure USB storage devices in high latency VDI environments
US9882727B1 (en) 2015-10-02 2018-01-30 Digicert, Inc. Partitioning certificate revocation lists
KR102576417B1 (ko) * 2015-11-19 2023-09-08 로베르트 보쉬 게엠베하 네트워크화된 컴퓨터를 통한 임베디드 디바이스에 대한 보안 액세스 제어
US10778435B1 (en) * 2015-12-30 2020-09-15 Jpmorgan Chase Bank, N.A. Systems and methods for enhanced mobile device authentication
TWI600334B (zh) 2016-03-23 2017-09-21 財團法人工業技術研究院 車輛網路節點之安全憑證管理方法與應用其之車輛網路節 點
CN105868640A (zh) * 2016-04-04 2016-08-17 张曦 一种防范硬盘固件攻击的***和方法
US10637665B1 (en) 2016-07-29 2020-04-28 Workday, Inc. Blockchain-based digital identity management (DIM) system
US11088855B2 (en) 2016-07-29 2021-08-10 Workday, Inc. System and method for verifying an identity of a user using a cryptographic challenge based on a cryptographic operation
US11336432B2 (en) 2016-07-29 2022-05-17 Workday, Inc. System and method for blockchain-based device authentication based on a cryptographic challenge
US10715311B2 (en) * 2017-07-28 2020-07-14 Workday, Inc. System and method for blockchain-based user authentication based on a cryptographic challenge
US10700861B2 (en) 2016-07-29 2020-06-30 Workday, Inc. System and method for generating a recovery key and managing credentials using a smart blockchain contract
US10715312B2 (en) 2016-07-29 2020-07-14 Workday, Inc. System and method for blockchain-based device authentication based on a cryptographic challenge
US10735197B2 (en) 2016-07-29 2020-08-04 Workday, Inc. Blockchain-based secure credential and token management across multiple devices
KR101882685B1 (ko) * 2016-07-29 2018-08-24 주식회사 스패로우 클라우드 기반의 서비스 제공 방법
US9913132B1 (en) 2016-09-14 2018-03-06 Sprint Communications Company L.P. System and method of mobile phone customization based on universal manifest
US10021240B1 (en) 2016-09-16 2018-07-10 Sprint Communications Company L.P. System and method of mobile phone customization based on universal manifest with feature override
DK3334188T3 (da) * 2016-12-08 2021-06-28 Gn Hearing As Høreindretning, brugerapplikation og fremgangsmåde til oprettelse af en sikker forbindelse mellem en høreindretning og en brugerapplikation
US10990707B1 (en) * 2017-03-30 2021-04-27 Comodo Security Solutions, Inc. Device for safe data signing
US10306433B1 (en) 2017-05-01 2019-05-28 Sprint Communications Company L.P. Mobile phone differentiated user set-up
US11196722B2 (en) * 2017-06-14 2021-12-07 Thales Dis France Sa Method for mutual symmetric authentication between a first application and a second application
CN107508680B (zh) 2017-07-26 2021-02-05 创新先进技术有限公司 数字证书管理方法、装置及电子设备
US10586033B2 (en) * 2017-08-29 2020-03-10 International Business Machines Corporation Automatic upgrade from one step authentication to two step authentication via application programming interface
CN107679370B (zh) * 2017-10-13 2020-11-03 北京大学 一种设备标识生成方法及装置
CN107919955B (zh) * 2017-12-28 2021-02-26 北京奇虎科技有限公司 一种车辆网络安全认证方法、***、车辆、装置及介质
US11250164B2 (en) * 2018-03-27 2022-02-15 Desprez, Llc Systems for secure collaborative graphical design using secret sharing
US10848323B2 (en) * 2018-05-24 2020-11-24 Microsoft Technology Licensing, Llc Efficient certificate revocation list validation in multi-tenant cloud services
WO2020006572A2 (en) * 2018-06-29 2020-01-02 Syntegrity Networks Inc. Data stream identity
JP7113269B2 (ja) * 2018-08-28 2022-08-05 パナソニックＩｐマネジメント株式会社 通信システムおよび通信方法
US11057373B2 (en) 2018-11-16 2021-07-06 Bank Of America Corporation System for authentication using channel dependent one-time passwords
CN109598119B (zh) * 2018-11-28 2021-03-16 北京可信华泰信息技术有限公司 一种可信加解密方法
CN109598154B (zh) * 2018-11-28 2021-03-16 北京可信华泰信息技术有限公司 一种可信全盘加解密方法
CN109583197B (zh) * 2018-11-28 2021-05-14 北京可信华泰信息技术有限公司 一种可信叠层文件加解密方法
GB2579574B (en) * 2018-12-03 2021-08-11 Advanced Risc Mach Ltd Bootstrapping with common credential data
EP3681102B1 (de) * 2019-01-10 2022-03-16 Siemens Aktiengesellschaft Verfahren zur validierung eines digitalen nutzerzertifikats
CN110086624A (zh) * 2019-03-21 2019-08-02 平安科技（深圳）有限公司 数字证书撤销信息验证方法、装置及***
US11233650B2 (en) 2019-03-25 2022-01-25 Micron Technology, Inc. Verifying identity of a vehicle entering a trust zone
US11323275B2 (en) * 2019-03-25 2022-05-03 Micron Technology, Inc. Verification of identity using a secret key
US11218330B2 (en) 2019-03-25 2022-01-04 Micron Technology, Inc. Generating an identity for a computing device using a physical unclonable function
US11361660B2 (en) 2019-03-25 2022-06-14 Micron Technology, Inc. Verifying identity of an emergency vehicle during operation
US11316706B2 (en) * 2019-04-16 2022-04-26 Mastercard International Incorporated Method and system for using dynamic private keys to secure data file retrieval
US11411746B2 (en) * 2019-05-24 2022-08-09 Centrality Investments Limited Systems, methods, and storage media for permissioned delegation in a computing environment
US11032062B2 (en) * 2019-09-17 2021-06-08 Switchbit, Inc. Data processing permits system with keys
CN113132108B (zh) * 2019-12-31 2022-02-25 华为技术有限公司 一种数字证书的吊销、校验方法及装置
US11743058B2 (en) * 2020-03-05 2023-08-29 International Business Machines Corporation NVDIMM security with physically unclonable functions
JP2021149417A (ja) 2020-03-18 2021-09-27 キオクシア株式会社 記憶装置および制御方法
CN111858974B (zh) * 2020-07-17 2022-03-15 北京字节跳动网络技术有限公司 信息推送方法、装置、电子设备及存储介质
US20210103656A1 (en) * 2020-11-06 2021-04-08 Lilly Nahal Tahmasebi Method and apparatus using virtual isolation layer in data security
US11477027B1 (en) * 2021-05-11 2022-10-18 Dennis Palatov Apparatus and methods for management of controlled objects

Family Cites Families (97)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4575621A (en) * 1984-03-07 1986-03-11 Corpra Research, Inc. Portable electronic transaction device and system therefor
US5237609A (en) * 1989-03-31 1993-08-17 Mitsubishi Denki Kabushiki Kaisha Portable secure semiconductor memory device
US5148481A (en) * 1989-10-06 1992-09-15 International Business Machines Corporation Transaction system security method and apparatus
US5052040A (en) * 1990-05-25 1991-09-24 Micronyx, Inc. Multiple user stored data cryptographic labeling system and method
GB9412434D0 (en) * 1994-06-21 1994-08-10 Inmos Ltd Computer instruction compression
JPH08263438A (ja) * 1994-11-23 1996-10-11 Xerox Corp ディジタルワークの配給及び使用制御システム並びにディジタルワークへのアクセス制御方法
US5604801A (en) * 1995-02-03 1997-02-18 International Business Machines Corporation Public key data communications system under control of a portable security device
US5793868A (en) * 1996-08-29 1998-08-11 Micali; Silvio Certificate revocation system
US5857020A (en) * 1995-12-04 1999-01-05 Northern Telecom Ltd. Timed availability of secured content provisioned on a storage medium
JP3176030B2 (ja) * 1996-01-08 2001-06-11 株式会社東芝 複製制御方法及び複製制御装置
CA2245822A1 (en) * 1996-02-09 1997-08-14 Integrated Technologies Of America, Inc. Access control/crypto system
US6038551A (en) * 1996-03-11 2000-03-14 Microsoft Corporation System and method for configuring and managing resources on a multi-purpose integrated circuit card using a personal computer
US5903651A (en) * 1996-05-14 1999-05-11 Valicert, Inc. Apparatus and method for demonstrating and confirming the status of a digital certificates and other data
US5949877A (en) * 1997-01-30 1999-09-07 Intel Corporation Content protection for transmission systems
US6189097B1 (en) * 1997-03-24 2001-02-13 Preview Systems, Inc. Digital Certificate
US6513116B1 (en) * 1997-05-16 2003-01-28 Liberate Technologies Security information acquisition
US5930167A (en) * 1997-07-30 1999-07-27 Sandisk Corporation Multi-state non-volatile flash memory capable of being its own two state write cache
US6438666B2 (en) * 1997-09-26 2002-08-20 Hughes Electronics Corporation Method and apparatus for controlling access to confidential data by analyzing property inherent in data
US6094724A (en) * 1997-11-26 2000-07-25 Atmel Corporation Secure memory having anti-wire tapping
US6026402A (en) * 1998-01-07 2000-02-15 Hewlett-Packard Company Process restriction within file system hierarchies
US6584495B1 (en) * 1998-01-30 2003-06-24 Microsoft Corporation Unshared scratch space
US6073242A (en) * 1998-03-19 2000-06-06 Agorics, Inc. Electronic authority server
FR2779018B1 (fr) * 1998-05-22 2000-08-18 Activcard Terminal et systeme pour la mise en oeuvre de transactions electroniques securisees
US6609199B1 (en) * 1998-10-26 2003-08-19 Microsoft Corporation Method and apparatus for authenticating an open system application to a portable IC device
US6343291B1 (en) * 1999-02-26 2002-01-29 Hewlett-Packard Company Method and apparatus for using an information model to create a location tree in a hierarchy of information
US7073063B2 (en) * 1999-03-27 2006-07-04 Microsoft Corporation Binding a digital license to a portable device or the like in a digital rights management (DRM) system and checking out/checking in the digital license to/from the portable device or the like
FI108389B (fi) * 1999-04-15 2002-01-15 Sonera Smarttrust Oy Tilaajaidentiteettimoduulin hallinta
DE60011958T2 (de) * 1999-04-28 2005-08-25 Matsushita Electric Industrial Co., Ltd., Kadoma Optische Platte, optisches Plattenaufzeichnungs- und wiedergabegerät, und Verfahren zur Aufzeichnung und Wiedergabe
US6449720B1 (en) * 1999-05-17 2002-09-10 Wave Systems Corp. Public cryptographic control unit and system therefor
US6289450B1 (en) * 1999-05-28 2001-09-11 Authentica, Inc. Information security architecture for encrypting documents for remote access while maintaining access control
CN1967559A (zh) * 1999-07-06 2007-05-23 索尼株式会社 数据提供***、装置及其方法
GB9922665D0 (en) * 1999-09-25 1999-11-24 Hewlett Packard Co A method of enforcing trusted functionality in a full function platform
US6779113B1 (en) * 1999-11-05 2004-08-17 Microsoft Corporation Integrated circuit card with situation dependent identity authentication
JP3677001B2 (ja) * 1999-12-03 2005-07-27 三洋電機株式会社 データ配信システムおよびそれに用いられる記録装置
US20060161725A1 (en) * 2005-01-20 2006-07-20 Lee Charles C Multiple function flash memory system
EP1267515A3 (en) * 2000-01-21 2004-04-07 Sony Computer Entertainment Inc. Method and apparatus for symmetric encryption/decryption of recorded data
US7215771B1 (en) * 2000-06-30 2007-05-08 Western Digital Ventures, Inc. Secure disk drive comprising a secure drive key and a drive ID for implementing secure communication over a public network
US7350204B2 (en) * 2000-07-24 2008-03-25 Microsoft Corporation Policies for secure software execution
EP1312087B1 (en) * 2000-08-16 2007-10-03 Uqe, Llc Method and device for controlling distribution and use of digital works
EP1182551B1 (en) * 2000-08-21 2017-04-05 Texas Instruments France Address space priority arbitration
US6880084B1 (en) * 2000-09-27 2005-04-12 International Business Machines Corporation Methods, systems and computer program products for smart card product management
US7546334B2 (en) * 2000-11-13 2009-06-09 Digital Doors, Inc. Data security system and method with adaptive filter
US6970891B1 (en) * 2000-11-27 2005-11-29 Microsoft Corporation Smart card with volatile memory file subsystem
US7209893B2 (en) * 2000-11-30 2007-04-24 Nokia Corporation Method of and a system for distributing electronic content
JP2002271316A (ja) * 2001-03-13 2002-09-20 Sanyo Electric Co Ltd 再生装置
JP2002278838A (ja) * 2001-03-15 2002-09-27 Sony Corp メモリアクセス制御システム、デバイス管理装置、パーティション管理装置、メモリ搭載デバイス、およびメモリアクセス制御方法、並びにプログラム記憶媒体
US20020136410A1 (en) * 2001-03-26 2002-09-26 Sun Microsystems, Inc. Method and apparatus for extinguishing ephemeral keys
US7500104B2 (en) * 2001-06-15 2009-03-03 Microsoft Corporation Networked device branding for secure interaction in trust webs on open networks
US7925894B2 (en) * 2001-07-25 2011-04-12 Seagate Technology Llc System and method for delivering versatile security, digital rights management, and privacy services
US7036020B2 (en) * 2001-07-25 2006-04-25 Antique Books, Inc Methods and systems for promoting security in a computer system employing attached storage devices
US7418344B2 (en) * 2001-08-02 2008-08-26 Sandisk Corporation Removable computer with mass storage
NZ531200A (en) * 2001-08-13 2006-03-31 Qualcomm Inc Application level access privilege to a storage area on a computer device
JP2003085321A (ja) * 2001-09-11 2003-03-20 Sony Corp コンテンツ利用権限管理システム、コンテンツ利用権限管理方法、および情報処理装置、並びにコンピュータ・プログラム
US6456528B1 (en) * 2001-09-17 2002-09-24 Sandisk Corporation Selective operation of a multi-state non-volatile memory system in a binary mode
US6865555B2 (en) * 2001-11-21 2005-03-08 Digeo, Inc. System and method for providing conditional access to digital content
GB0205751D0 (en) * 2002-03-12 2002-04-24 James Barry E Improvements relating to memory devices
US6785790B1 (en) * 2002-05-29 2004-08-31 Advanced Micro Devices, Inc. Method and apparatus for storing and retrieving security attributes
JP2004013744A (ja) * 2002-06-10 2004-01-15 Takeshi Sakamura デジタルコンテンツの発行システム及び発行方法
GB2391082B (en) * 2002-07-19 2005-08-03 Ritech Internat Ltd Portable data storage device with layered memory architecture
US7083090B2 (en) * 2002-08-09 2006-08-01 Patrick Zuili Remote portable and universal smartcard authentication and authorization device
US20040083370A1 (en) * 2002-09-13 2004-04-29 Sun Microsystems, Inc., A Delaware Corporation Rights maintenance in a rights locker system for digital content access control
US20040059946A1 (en) * 2002-09-25 2004-03-25 Price Burk Pieper Network server system and method for securely publishing applications and services
US7197585B2 (en) * 2002-09-30 2007-03-27 International Business Machines Corporation Method and apparatus for managing the execution of a broadcast instruction on a guest processor
US20040139021A1 (en) * 2002-10-07 2004-07-15 Visa International Service Association Method and system for facilitating data access and management on a secure token
CN1708971A (zh) * 2002-10-24 2005-12-14 松下电器产业株式会社 将信息从服务提供商“推”到包括存储卡的通信终端的***与方法
US7478248B2 (en) * 2002-11-27 2009-01-13 M-Systems Flash Disk Pioneers, Ltd. Apparatus and method for securing data on a portable storage device
JP2004199138A (ja) * 2002-12-16 2004-07-15 Matsushita Electric Ind Co Ltd メモリデバイスとそれを使用する電子機器
KR100493885B1 (ko) * 2003-01-20 2005-06-10 삼성전자주식회사 공개키 기반 구조(ｐｋｉ) 도메인간의 이동 사용자를 위한스마트카드 인증서 등록 및 검증 시스템 및 방법
US7340615B2 (en) * 2003-01-31 2008-03-04 Microsoft Corporation Method and apparatus for managing power in network interface modules
US7322042B2 (en) * 2003-02-07 2008-01-22 Broadon Communications Corp. Secure and backward-compatible processor and secure software execution thereon
US7949877B2 (en) * 2003-06-30 2011-05-24 Realnetworks, Inc. Rights enforcement and usage reporting on a client device
US6988175B2 (en) * 2003-06-30 2006-01-17 M-Systems Flash Disk Pioneers Ltd. Flash memory management method that is resistant to data corruption by power loss
US6938136B2 (en) * 2003-07-14 2005-08-30 International Business Machines Corporation Method, system, and program for performing an input/output operation with respect to a logical storage device
US20050049931A1 (en) * 2003-08-29 2005-03-03 Wisnudel Marc Brian Digital content kiosk and associated methods for delivering selected digital content to a user
US7484090B2 (en) * 2003-10-10 2009-01-27 Panasonic Corporation Encryption apparatus, decryption apparatus, secret key generation apparatus, and copyright protection system
US7711951B2 (en) * 2004-01-08 2010-05-04 International Business Machines Corporation Method and system for establishing a trust framework based on smart key devices
US8019928B2 (en) * 2004-02-15 2011-09-13 Sandisk Il Ltd. Method of managing a multi-bit-cell flash memory
KR101100385B1 (ko) * 2004-03-22 2011-12-30 삼성전자주식회사 인증서 폐지 목록을 이용한 디지털 저작권 관리 방법 및장치
WO2005124582A1 (en) * 2004-03-22 2005-12-29 Samsung Electronics Co., Ltd. Method and apparatus for digital rights management using certificate revocation list
EP1758293A1 (en) * 2004-04-21 2007-02-28 Matsushita Electric Industrial Co., Ltd. Content providing system, information processing device, and memory card
US7363365B2 (en) * 2004-07-13 2008-04-22 Teneros Inc. Autonomous service backup and migration
US7797750B2 (en) * 2004-08-10 2010-09-14 Newport Scientific Research Llc Data security system
US8954751B2 (en) * 2004-10-08 2015-02-10 International Business Machines Corporation Secure memory control parameters in table look aside buffer data fields and support memory array
GB2434673B (en) * 2004-11-12 2009-10-14 Discretix Technologies Ltd Method, device, and system of securely storing data
WO2006056988A2 (en) * 2004-11-24 2006-06-01 Discretix Technologies Ltd. System, method and apparatus of securing an operating system
US20060129824A1 (en) * 2004-12-15 2006-06-15 Hoff James P Systems, methods, and media for accessing TPM keys
DE102004062203B4 (de) * 2004-12-23 2007-03-08 Infineon Technologies Ag Datenverarbeitungseinrichtung, Telekommunikations-Endgerät und Verfahren zur Datenverarbeitung mittels einer Datenverarbeitungseinrichtung
US7493656B2 (en) * 2005-06-02 2009-02-17 Seagate Technology Llc Drive security session manager
JP4654806B2 (ja) * 2005-07-15 2011-03-23 ソニー株式会社 情報処理装置、情報記録媒体製造装置、情報記録媒体、および方法、並びにコンピュータ・プログラム
US8046837B2 (en) * 2005-08-26 2011-10-25 Sony Corporation Information processing device, information recording medium, information processing method, and computer program
US7752382B2 (en) * 2005-09-09 2010-07-06 Sandisk Il Ltd Flash memory storage system and method
US7634629B2 (en) * 2005-12-19 2009-12-15 Intel Corporation Mechanism to control access to a storage device
US20070180210A1 (en) * 2006-01-31 2007-08-02 Seagate Technology Llc Storage device for providing flexible protected access for security applications
US8245031B2 (en) * 2006-07-07 2012-08-14 Sandisk Technologies Inc. Content control method using certificate revocation lists
US20080072060A1 (en) * 2006-08-28 2008-03-20 Susan Cannon Memory device for cryptographic operations
US8166326B2 (en) * 2007-11-08 2012-04-24 International Business Machines Corporation Managing power consumption in a computer
US20090144347A1 (en) * 2007-11-30 2009-06-04 Boyd James A Storage volume spanning with intelligent file placement and/or rearrangement

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016534629A (ja) * 2013-08-23 2016-11-04 クアルコム，インコーポレイテッド プリコード化されたパケットのハッシュ処理を使用したセキュアなコンテンツ配信
WO2015092953A1 (ja) * 2013-12-16 2015-06-25 パナソニックＩｐマネジメント株式会社 認証システムおよび認証方法
JPWO2015092953A1 (ja) * 2013-12-16 2017-03-16 パナソニックＩｐマネジメント株式会社 認証システムおよび認証方法
JP2019521416A (ja) * 2016-05-11 2019-07-25 アリババ グループ ホウルディング リミテッド アイデンティティ検証方法及びシステム並びにインテリジェントウェアラブルデバイス
US10878074B2 (en) 2016-05-11 2020-12-29 Advanced New Technologies Co., Ltd. Identity verification method and system, and intelligent wearable device
US10891364B2 (en) 2016-05-11 2021-01-12 Advanced New Technologies Co., Ltd. Identity verification method and system, and intelligent wearable device

Also Published As

Publication number Publication date
TW201136266A (en) 2011-10-16
CN102906755A (zh) 2013-01-30
US20100138652A1 (en) 2010-06-03
EP2513901A1 (en) 2012-10-24
WO2011075281A1 (en) 2011-06-23
KR20120093375A (ko) 2012-08-22

Similar Documents

Publication Publication Date Title
US8140843B2 (en) Content control method using certificate chains
US8639939B2 (en) Control method using identity objects
US8245031B2 (en) Content control method using certificate revocation lists
US8613103B2 (en) Content control method using versatile control structure
US8266711B2 (en) Method for controlling information supplied from memory device
JP2013514587A (ja) 証明書失効リストを用いたコンテンツ管理方法
JP5180203B2 (ja) メモリ装置から供給される情報を制御するシステムおよび方法
US20080034440A1 (en) Content Control System Using Versatile Control Structure
US20080010449A1 (en) Content Control System Using Certificate Chains
US20080022395A1 (en) System for Controlling Information Supplied From Memory Device
US20080010452A1 (en) Content Control System Using Certificate Revocation Lists
KR101238848B1 (ko) 파티셔닝을 포함한 다기능 컨텐트 제어
US20080010458A1 (en) Control System Using Identity Objects
JP4857284B2 (ja) 多目的コンテンツ制御をするコントロール構造の生成システム
JP2010182322A (ja) 多目的コンテンツ制御を備えたメモリシステム
JP2008524758A5 (ja)
JP2009543211A (ja) 汎用管理構造を使用するコンテンツ管理システムおよび方法
JP5178716B2 (ja) 証明書取消リストを使用するコンテンツ管理システムおよび方法
JP2009543208A (ja) 証明書連鎖を使用するコンテンツ管理システムおよび方法
JP2009543208A5 (ja)
JP4972165B2 (ja) アイデンティティオブジェクトを使用する制御システムおよび方法
JP2009543210A5 (ja)

Legal Events

Date Code Title Description
A300 Application deemed to be withdrawn because no request for examination was validly filed

Free format text: JAPANESE INTERMEDIATE CODE: A300

Effective date: 20140204