JP2009543210A5 - - Google Patents

Download PDF

Info

Publication number
JP2009543210A5
JP2009543210A5 JP2009518355A JP2009518355A JP2009543210A5 JP 2009543210 A5 JP2009543210 A5 JP 2009543210A5 JP 2009518355 A JP2009518355 A JP 2009518355A JP 2009518355 A JP2009518355 A JP 2009518355A JP 2009543210 A5 JP2009543210 A5 JP 2009543210A5
Authority
JP
Japan
Prior art keywords
certificate
entity
data
key
host
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.)
Granted
Application number
JP2009518355A
Other languages
English (en)
Other versions
JP2009543210A (ja
JP4972165B2 (ja
Filing date
Publication date
Priority claimed from US11/557,039 external-priority patent/US20080010458A1/en
Priority claimed from US11/557,041 external-priority patent/US8639939B2/en
Application filed filed Critical
Priority claimed from PCT/US2007/015430 external-priority patent/WO2008008243A2/en
Publication of JP2009543210A publication Critical patent/JP2009543210A/ja
Publication of JP2009543210A5 publication Critical patent/JP2009543210A5/ja
Application granted granted Critical
Publication of JP4972165B2 publication Critical patent/JP4972165B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Description

用途によっては、メモリカード等のメモリ装置と関連付けられた実体に自身のアイデンティティの証拠を提示することが求められる。このアイデンティティの証拠を容易く入手できないと不都合が生じることがある。この他にも用途によっては、メモリカード等のメモリ装置に記憶されるデータを安全な方法で保護することが必要な場合がある。
さらに別の実施形態において、メモリシステムの制御データ構造によって実体が認証された後に、アイデンティティオブジェクトの公開鍵と、公開鍵を証明するための少なくとも1つの証明書とを、実体へ提供する。この実施形態の一実用的応用において、アイデンティティオブジェクトの公開鍵によって暗号化された暗号化データを実体から受信する場合、メモリシステムは、アイデンティティオブジェクトの中にある秘密鍵を使って暗号化データを復号化できる。アイデンティティオブジェクトと少なくとも1つの証明書とが不揮発性メモリに記憶され、このメモリはコントローラによって制御される。好ましくは、メモリとコントローラとを筐体で取り囲む。
本発明を例示するのに有用である、ホスト装置と通信するメモリシステムのブロック図である。 本発明の種々の実施形態を例示するのに有用である、特定のパーティションと暗号化ファイルへのアクセスをアクセス方針と認証手続きとによって制御するメモリの種々のパーティションと種々のパーティションに記憶される非暗号化および暗号化ファイルとの概略図である。 メモリ内の種々のパーティションを示すメモリの概略図である。 本発明の種々の実施形態を例示するのに有用である、パーティション内のいくつかのファイルが暗号化される図3に示すメモリの種々のパーティションのファイルロケーションテーブルの概略図である。 本発明の種々の実施形態を例示するのに有用である、アクセス制御記録グループ内のアクセス制御記録と対応する鍵参照符との概略図である。 本発明の種々の実施形態を例示するのに有用である、アクセス制御記録グループとアクセス制御記録とによって形成されるツリー構造の概略図である。 ツリーの形成プロセスを例示するための、アクセス制御記録グループからなる3つの階層ツリーを示すツリーの概略図である。 システムアクセス制御記録を作成し、かつ使用する場合にホスト装置とメモリカード等のメモリ装置とによって実行されるプロセスを示すフローチャートである。 システムアクセス制御記録を作成し、かつ使用する場合にホスト装置とメモリカード等のメモリ装置とによって実行されるプロセスを示すフローチャートである。 種々の実施形態を例示するのに有用である、システムアクセス制御記録を使ってアクセス制御記録グループを作成するプロセスを示すフローチャートである。 アクセス制御記録を作成するプロセスを示すフローチャートである。 階層ツリーの一応用を例示するのに有用である、2つのアクセス制御記録グループの概略図である。 特定の権利を委譲するプロセスを示すフローチャートである。 図12の委譲プロセスを例示するための、アクセス制御記録グループとアクセス制御記録との概略図である。 暗号化および/または復号化の目的で鍵を作成するプロセスを示すフローチャートである。 アクセス制御記録に従いアクセス権および/またはデータアクセス権限を削除するプロセスを示すフローチャートである。 アクセス権および/またはアクセス権限が削除されたか、あるいは期限切れになった場合にアクセスを要求するプロセスを示すフローチャートである。 本発明の種々の実施形態の例示に有用である、認証ルール構造と暗号鍵アクセス許諾方針の構成を示す概略図である。 本発明の種々の実施形態の例示に有用である、認証ルール構造と暗号鍵アクセス許諾方針の構成を示す概略図である。 方針に従い被保護情報へのアクセスを制御する代替的な方法を示すデータベース構造のブロック図である。 パスワードを用いた認証プロセスを示すフローチャートである。 多数のホスト証明書チェーンを示す図である。 多数のデバイス証明書チェーンを示す図である。 一方向および相互認証方式のプロセスを示すプロトコル図である。 一方向および相互認証方式のプロセスを示すプロトコル図である。 本発明の一実施形態を例示するのに有用である、証明書チェーンの図である。 本発明の別の実施形態を例示するための、メモリ装置へ最終証明書を送信する場合のホストによって送信される証明書バッファに先行する制御セクタ内の情報を示す表であって、この証明書が証明書チェーンにおける最終証明書であることを伝える標示を示す。 メモリカードがホスト装置を認証する認証方式でカードとホストのプロセスをそれぞれ示すフローチャートである。 メモリカードがホスト装置を認証する認証方式でカードとホストのプロセスをそれぞれ示すフローチャートである。 ホスト装置がメモリカードを認証する認証方式でカードとホストのプロセスをそれぞれ示すフローチャートである。 ホスト装置がメモリカードを認証する認証方式でカードとホストのプロセスをそれぞれ示すフローチャートである。 本発明の別の実施形態を例示するための、メモリ装置に記憶された証明書失効リストがホスト装置によって検索される場合にホスト装置とメモリ装置とによってそれぞれ実行されるプロセスを示すフローチャートである。 本発明の別の実施形態を例示するための、メモリ装置に記憶された証明書失効リストがホスト装置によって検索される場合にホスト装置とメモリ装置とによってそれぞれ実行されるプロセスを示すフローチャートである。 本発明のさらに別の実施形態を示すための、証明書失効リスト内のフィールドを示す証明書失効リストの図である。 証明書失効リストを使って証明書をベリファイするカードとホストのプロセスをそれぞれ示すフローチャートである。 証明書失効リストを使って証明書をベリファイするカードとホストのプロセスをそれぞれ示すフローチャートである。 カードがホストへ送信されるデータに署名し、かつホストからのデータを復号化するカードプロセスを示すフローチャートである。 カードがホストへ送信されるデータに署名する場合のホストプロセスを示すフローチャートである。 ホストが暗号化データをメモリカードへ送信する場合のホストプロセスを示すフローチャートである。 一般情報および非公開情報クエリのプロセスをそれぞれ示すフローチャートである。 一般情報および非公開情報クエリのプロセスをそれぞれ示すフローチャートである。 本発明の一実施形態を例示するための、ホスト装置へ接続されたメモリ装置(フラッシュメモリカード等)におけるシステムアーキテクチャの機能ブロック図である。 図40AのSSMコアの内部ソフトウェアモジュールの機能ブロック図である。 使い捨てパスワードを生成するシステムのブロック図である。 使い捨てパスワード(OTP)シード提供とOTP生成とを示す機能ブロック図である。 シード提供段階を示すプロトコル図である。 使い捨てパスワード生成段階を示すプロトコル図である。 DRMシステムを示す機能ブロック図である。 ライセンスオブジェクトの中で鍵が提供される場合のライセンス提供とコンテンツダウンロードのプロセスを示すプロトコル図である。 再生操作のプロセスを示すプロトコル図である。 ライセンスオブジェクトの中で鍵が提供されない場合のライセンス提供とコンテンツダウンロードのプロセスを示すプロトコル図である。
メモリシステム10は、一実施形態において、暗号化および/または復号化に用いる鍵値を生成し、この値は、好ましくはホスト装置24等の外部装置にとって事実上アクセス不能である。代替的に、システム10の外部で、例えばライセンスサーバによって、鍵値を生成し、システム10へ送信することもできる。鍵値を生成する方法にかかわりなく、いったんシステム10に記憶された鍵値にアクセスできるものは認証済み実体のみとなる。しかし、ホスト装置はメモリシステム10におけるデータの読み書きをファイルの形で行うため、暗号化と復号化は通常であればファイル単位で行われる。メモリ装置10は、タイプが異なる他の多数の記憶装置と同様に、ファイルを管理しない。メモリ20は、ファイルの論理アドレスを識別するファイルアロケーションテーブル(FAT)を記憶するが、このFATにアクセスし管理するのは通常であればホスト装置24であって、コントローラ12ではない。このため、ある特定のファイルのデータを暗号化する場合、コントローラ12はメモリ20におけるこのファイルのデータの論理アドレスをホスト装置に送信してもらう必要があり、このため、システム10はこのファイルのデータを見つけ、システム10のみが使用できる鍵値を使ってデータを暗号化および/または復号化できる。
同じく図2に示されているように、メモリ20のファイルには様々なユーザまたはアプリケーションがアクセスする。そこで図2には、ユーザ1および2とアプリケーション1〜4(装置上で実行)が示されている。これらの実体は、これより説明する認証プロセスによって認証された後にメモリ20の被保護コンテンツへのアクセスが認められる。このプロセスでは、アクセスを要求する実体をロール方式のアクセス制御のためにホスト側で識別する必要がある。そこでアクセスを要求する実体はまず、「私はアプリケーション2であってファイル1を読み出したい」等の情報を供給することによって自身を識別する。コントローラ12はそのアイデンティティと、認証情報と、要求とを、メモリ20またはコントローラ12に記憶された記録に突き合せる。すべての要件が満たされる場合、そのような実体にアクセスが認められる。図2に示すように、ユーザ1はパーティションP1のファイル101を読み書きでき、P0ではファイル106に対する無制限の読み出し・書き込み権利を有しているが、これ以外に読み出し可能なファイルはファイル102および104のみである。他方、ユーザ2は、ファイル101および104へのアクセスを許可されないが、ファイル102に対する読み出し・書き込みアクセス権は有している。図2に示すように、ユーザ1および2のログインアルゴリズム(AES)は同じであるが、アプリケーション1および3のログインアルゴリズムはそれぞれ異なり(例えば、RSAと001001)、ユーザ1および2のものとも異なる。
セキュアストレージアプリケーション(SSA)は本発明の一実施形態を例示するメモリシステム10のセキュリティアプリケーションであり、前述した機能の多くはこれを用いて実行できる。SSAはソフトウェアまたはコンピュータコードとして実装でき、メモリ20またはCPU12の不揮発性メモリ(図示せず)に記憶されたデータベースがRAM12aに読み込まれ、CPU12によって実行される。次の表には、SSAに言及する場合に用いる頭字語が記されている。
Figure 2009543210
図3はメモリのパーティションP0、P1、P2、およびP3を示すメモリの概略図であり(言うまでもなく5つ以上のパーティションが使われることも、あるいは3つ以下のパーティションが使われることもある)、P0はいずれの実体でも認証なしでアクセスできる公開パーティションである。
図4を参照し、例えばファイルAは鍵IDで囲まれていないため、いずれの実体でも認証なしでファイルAにアクセスできる。公開パーティションの中にあるファイルBはいずれの実体でも読み出しや上書きを行えるが、その中のデータはID「鍵1」を有する鍵で暗号化されているため、このような鍵にアクセスできるこのような実体でない限り、ファイルBの中にある情報にはアクセスできない。このような鍵値と鍵参照符すなわち鍵IDの使用は、前述したパーティションによる保護とは異なり、論理的な保護のみを提供する。つまり、パーティション(公開または非公開)にアクセスできるホストであればいずれでもそのパーティションの中で暗号化データを含むデータを読み書きできる。しかし、データは暗号化されているため、権限を有していないユーザはデータを壊すことしかできない。権限を有していないユーザは、好ましくは発覚することなくこのデータを変更できない。暗号化および/または復号化鍵へのアクセスを制限することにより、権限を有する実体のみにデータの使用を認めることができる。P0ではファイルBおよびCも鍵ID「鍵2」を有する鍵を使って暗号化されている。
パーティション内のすべてのデータが異なる鍵によって暗号化され、異なる鍵IDが割り振られるわけではない。公開またはユーザファイルの中またはオペレーティングシステム領域(すなわち、FAT)の中で、論理アドレスに鍵または鍵参照符が割り振られない場合があり、この場合、パーティション自体にアクセスできる実体であればいずれでもこれにアクセスできる。
鍵やパーティションの作成や、パーティションにおけるデータの読み書きや、鍵の使用を望む実体は、アクセス制御記録(ACR)を通じてSSAシステムにログインする必要がある。SSAシステムにおけるACRの特権はアクションと呼ばれる。どのACRでも3種類のアクション、すなわちパーティションおよび鍵/鍵IDの作成と、パーティションおよび鍵へのアクセスと、他のACRの作成/更新とを実行する権限を有することができる。
鍵、鍵ID、論理的保護
ある特定の非表示パーティションに書き込まれたファイルは公から非表示にされる。しかし、いったん実体(敵対的な実体、またはそうでない実体)が情報を得てこのパーティションにアクセスすると、そのファイルは使用可能となり一目瞭然となる。そのファイルのさらなる安全確保のため、SSAは非表示パーティションでファイルを暗号化でき、このファイルの復号化に用いる鍵にアクセスするための信用証明は、好ましくはパーティションにアクセスするためのものとは異なるものにする。ファイルはホストによって全面的に制御され、管理されるため、ファイルにCEKを割り振ることには問題がある。これを解決するには、SSAが了解する何か、すなわち鍵IDにファイルを関連付ける。つまりSSAによって鍵が作成されたら、ホストはその鍵を使って暗号化されるデータに鍵IDを割り振る。鍵が鍵IDと併せてSSAに送られる場合、鍵と鍵IDを互いに関連付けることは容易い。
鍵値と鍵IDは論理的セキュリティを提供する。特定の鍵IDが割り振られたデータはいずれも、その場所にかかわりなく、コンテンツ暗号化鍵(CEK)の同じ鍵値で暗号化され、ホストアプリケーションからは一意な参照名すなわち鍵IDが提供される。(ACR認証により)非表示パーティションにアクセスし、そのパーティション内にある暗号化ファイルの読み出しまたは書き込みを望む実体は、そのファイルに割り振られた鍵IDにアクセスする必要がある。この鍵IDの鍵に対するアクセスを許諾する場合、SSAはこの鍵IDと関連付けられたCEKに鍵値をロードし、データを復号化してからホストへ送信するか、あるいはデータを暗号化してからフラッシュメモリ20に書き込む。一実施形態において、鍵IDと関連付けられたCEKの鍵値がSSAシステムによって無作為に作成され、SSAシステムによって維持される。SSAシステムの外でCEKの鍵値を知るか、あるいはアクセスする者はいない。外部から提供され外部で使用するのは参照符すなわち鍵IDのみであり、CEKの鍵値ではない。鍵値はSSAによって全面的に制御され、好ましくはSSAのみがこれにアクセスできる。代替的に、SSAシステムに鍵を提供することもできる。
SSAシステムにアクセスする場合、実体はシステムのいずれか1つのACRを通じて接続を確立する必要がある。SSAシステムは、接続する場合、ユーザが選ぶACRの規定に従ってログイン手続きを運営する。
SSAシステムは数通りのシステムログインをサポートし、認証アルゴリズムとユーザ信用証明は様々であってもよく、ログインに成功したユーザのシステムにおける特権も様々であってもよい。図5には様々なパスワードログインアルゴリズムと信用証明とが例示されている。ACR#1ではパスワードログインアルゴリズムとパスワードとが、信用証明として指定され、ACR#2ではPKI(公開鍵基盤)ログインアルゴリズムと公開鍵が信用証明として指定されている。したがって、実体はログインにおいて有効なACR
IDを提示するほか、適切なログインアルゴリズムと信用証明とを提示する必要がある。
SSAシステムのACRにログインした実体の権限、すなわちSSAコマンドを使用する権利は、ACRと関連付けられた権限制御記録(PCR)の中で設定する。図5のPCRに示すように、ACR#1は「鍵3」と関連付けられたデータに対して読み出し限定権限を許諾し、ACR#2は「鍵5」と関連付けられたデータの読み出し権限と書き込み権限とを許諾する。
以降のセクションで説明するように、アクセス権限や管理権限の委譲に関わる制限事項はAGPを使って管理運営する。完全に独立した実体、例えば2つの異なるアプリケーションまたは2つの異なるコンピュータユーザによるアクセスの制御運営は、図6の2つのツリーが果たす役割の1つである。ここで大切なり得ることは、2つのアクセスプロセスが、たとえ同時に発生する場合でも、事実上互いに独立する(すなわち、事実上クロストークをなくす)ことである。これは、それぞれのツリーにおけるACRとAGPの認証、権限、追加作成等が他のツリーにおけるものと無関係であり、かつ他のツリーにおけるものに左右されないことを意味する。このため、SSAシステムを使用するメモリシステム10では、複数のアプリケーションを同時に処理できる。また、2つのアプリケーションが互いに自立的に2つの別々のデータ群(例えば、1組の写真と1組の歌)にアクセスすることも可能になる。これは図6に例示されている。図6の上部で、ツリーの中にあるノード(ACR)を通じてアクセスするアプリケーションまたはユーザにとって、「鍵3」、「鍵X」、および「鍵Z」と関連付けられたデータは写真であってもよい。図6の下部で、ツリーのノード(ACR)を通じてアクセスするアプリケーションまたはユーザにとって、「鍵5」および「鍵Y」と関連付けられたデータは歌であってもよい。AGPを作成したACRは、このAGPにACR項目がなく空になっている場合に限りこのAGPを削除できる。
実体にとってのSSAの入口:アクセス制御記録(ACR)
SSAシステムのACRは、実体によるシステムログインのあり方を記述するものである。SSAシステムにログインする実体は、これから始まる認証プロセスに該当するACRを指定する必要がある。図5に示すように、ACRの中にある権限制御記録(PCR)は、ACRの認証を終えたユーザが実行できる許諾アクションを明らかにするものである。ホスト側実体はすべてのACRデータフィールドを提供する。
ACRへのログインに成功した実体は、そのACRのパーティション・鍵アクセス権限やACAM権限(後述)を照会できる。
ACR ID
SSAシステムの実体はログインプロセスを開始するときに、そのログイン方法に該当するACR IDを指定する必要がある(ACRが作成される場合にホストより支給される)ので、SSAは正しいアルゴリズムを準備し、すべてのログイン条件が満たされたら正しいPCRを選択する。ACR IDはACRの作成時にSSAシステムに提供される。
ログイン/認証アルゴリズム
実体によって使われるログイン手続きと、ユーザのアイデンティティを証明する場合に必要となる信用証明は、認証アルゴリズムによって決まる。手続きなし(信用証明なし)からパスワードに基づく手続き、対称暗号法か非対称暗号法に基づく双方向認証プロトコルまで、SSAシステムは数通りの標準的なログインアルゴリズムをサポートする。
信用証明
実体の信用証明はログインアルゴリズムに対応し、SSAがユーザをベリファイし認証するのに使われる。パスワード認証のためのパスワード/PIN番号やAES認証のためのAES鍵等は信用証明の一例であり得る。信用証明のタイプ/書式(PIN、対称鍵等)は予め決まり、認証モードから検索され、ACRの作成時にSSAシステムに提供される。SSAシステムはこれら信用証明の設定、配布、管理に関与しないが、例外としてPKI方式の認証では装置(例えば、フラッシュカード)を使ってRSA等の鍵対を生成でき、証明書生成のための公開鍵をエクスポートできる。
権限制御記録(PCR)
PCRは、SSAシステムにログインしACRの認証プロセスに合格した後の実体に対する許諾事項を明らかにするものである。権限には、パーティションおよび鍵の作成権限と、パーティションおよび鍵へのアクセス権限と、実体−ACR属性の管理権限の3種類がある。
パーティションへのアクセス
PCRのこの部分には、ACR段階を首尾よく完了した実体からアクセスできるパーティションのリストが入る(SSAシステムへ提供されるパーティションのIDを使用)。パーティションごとに書き込み限定または読み出し限定にアクセスのタイプが制限される場合があったり、あるいは完全書き込み/読み出しアクセス権が指定される場合もある。図5のACR#1はパーティション#2にアクセスできてもパーティション#1にはアクセスできない。PCRの中で指定される制限はSSAパーティションと公開パーティションとに適用される。
鍵IDアクセス
PCRのこの部分には、実体のログインプロセスによってACR方針が満たされた場合に該当する実体からアクセスできる、鍵IDのリスト(ホストからSSAシステムへの提供)と関連付けられたデータが入る。PCRに記載されたパーティション内のファイルには指定された鍵IDが割り振られる。デバイス(例えば、フラッシュカード)の論理アドレスに鍵IDは割り振られないため、ある特定のACRに対して2つ以上のパーティションがある場合、それらのパーティションのいずれかの中にはファイルがある。PCRの中で指定された鍵IDはそれぞれ異なる1組のアクセス権を有することができる。鍵IDによって指示されるデータへのアクセスは、書き込み限定または読み出し限定に制限される場合があったり、あるいは完全書き込み/読み出しアクセス権が指定される場合もある。
ACRの遮断と解除
システムによる実体のACR認証プロセスが失敗すると、ACRの遮断カウンタが増加する場合がある。一定の最大失敗認証数(MAX)に達すると、SSAシステムによってACRは遮断されることになる。
遮断されたACRは、この遮断されたACRから参照する別のACRによって解除できる。この解除されたACRに対する参照は、その作成元にたるACRによって設定される。解除されたACRは、好ましくは遮断されたACRの作成元と同じAGPの中にあり、「解除」権限を有する。
システムの中でこれ以外のACRは遮断されたACRを解除できない。遮断カウンタがあるACRでも解除ACRがなければ、遮断された場合に解除できない。
SSAシステムはルートAGP(ならびにルートAGPの全ACRとその権限)を作成する場合に3通りのモードをサポートする。
1.オープンモード:いずれのユーザまたは実体でも認証なしで、あるいはシステムACR(後述)を通じて認証されたユーザ/実体が、新規ルートAGPを作成できる。オープンモードによるルートAGPの作成は、セキュリティ対策なしですべてのデータ転送がオープンチャネル(発行機関のセキュア環境内)で行われる場合と、システムACR認証(Over The Air(OTA)と後発行手順)を通じて確立するセキュアチャネルを通じて行われる場合とがある。
システムACRが構成されず(オプションとして)、ルートAGP作成モードをオープンに設定する場合に選べるオプションはオープンチャネルのみである。
2.制御モード:システムACRを通じて認証された実体のみが新規ルートAGPを作成できる。システムACRが構成されなければ、SSAシステムをこのモードに設定することはできない。
3.ロックモード:ルートAGPの作成は無効になり、さらなるルートAGPをシステムに加えることはできない。
この機能は2つのSSAコマンドで制御する(これらコマンドはいずれのユーザ/実体でも認証なしで使用できる)。
1.方法構成コマンド:3通りのルートAGP作成モードのいずれか1つを使用する形にSSAシステムを構成するために使用する。オプションから制御へ、制御からロックへのモード変更のみが可能である(つまり、SSAシステムが現在制御モードに構成されている場合、ロックモードにしか変更できない)。
2.方法構成固定コマンド:方法構成コマンドを無効にし、現在選択されている方法で永続的に固定するために使用する。
作成されたルートAGPは特別な初期化モードに入り、ACRの作成、構成(ルートAGPの作成に適用されたものと同じアクセス制限を使用)が可能になる。ルートAGP構成プロセスの最後に実体がこれを明示的に作動モードに切り替えると、既存のACRは更新できなくなり、ACRを追加で作成できなくなる。
複数のアプリケーションに対応するように設計された製品は、様々な識別鍵を有することになる。製品は「前発行」するか(出荷に先立つ製造中に鍵を記憶する)、あるいは「後発行」する(出荷後に新たな鍵を追加する)。後発行の場合、ある種の親鍵または装置レベル鍵をメモリ装置(例えば、メモリカード)に入れる必要があり、この鍵は、装置へのアプリケーションの追加が許される実体を識別するために使われる。
鍵IDリスト
鍵IDは具体的なACR要求に従って作成されるが、メモリシステム10でこれを使用するのはSSAシステムのみである。鍵IDの作成時に作成元ACRから提供されるか、あるいは作成元ACRへ提供されるデータは次のとおりである。
1.鍵ID:このIDはホストを通じて実体から提供され、以降の読み出しアクセスや書き込みアクセスで、鍵と、その鍵を使って暗号化または暗号化されるデータとを参照するために使われる。
2.鍵暗号およびデータ保全モード(後述する前述したブロック、チェーン、およびハッシュモード)
ACR(前述したルートAGPの中にあるACRとは別のACR)を作成するには、図10に示すように、ACRを作成する権利を有するACRから開始できる(ブロック270)。ホスト24を通じて入ることを試みる実体は、入口にあたるACRのアイデンティティと作成したいがための必要となる属性のすべてを含むACRとを提供する(ブロック272)。SSAはACRアイデンティティの一致をチェックし、さらにそのアイデンティティを有するACRにACRを作成する権限があるかどうかをチェックする(菱形274)。要求が証明される場合、装置10のSSAはACRを作成する(ブロック276)。
図11の2つのAGPは、図10の方法を使用するセキュリティアプリケーションで役に立つツリーを例示するものである。従って、マーケティングAGPの中でアイデンティティm1を有するACRには、ACRを作成する権限がある。ACR m1は、鍵ID「マーケティング情報」と関連付けられたデータと鍵ID「価格リスト」と関連付けられたデータを鍵を使って読み書きする権限も有する。これにより、図10の方法を用いて2つのACR s1およびs2を含む販売AGPを作成する。ACR s1およびs2には鍵ID「価格リスト」と関連付けられた価格データにアクセスするための鍵の読み出し権限のみあるが、鍵ID「マーケティング情報」と関連付けられたデータにアクセスする場合に必要となる鍵の権限はない。このように、ACR s1およびs2を有する実体は、価格データを読み出されてもこれを変更することはできず、さらにマーケティングデータにはアクセスできない。一方、ACR m2にはACRを作成する権限がなく、鍵ID「価格リスト」と鍵ID「マーケティング情報」と関連付けられたデータにアクセスするための鍵の読み出し権限のみを有する。
従って、アクセス権は前述したやり方で委譲でき、m1は価格データを読み出す権利をs1およびs2に委譲する。これは特に大規模なマーケティング組織や販売組織が関わる場合に有用である。しかし、販売員が1名〜少数であれば図10の方法を使う必要はない場合がある。代わりに、図12に示すように、ACRから同じAGPの下位レベルまたは同じレベルに位置するACRにアクセス権を委譲できる。実体はまず、そのAGPのツリーに入るため、ホストを通じてツリーの中のACRを前述したように指定する(ブロック280)。次に、ホストはACRと委譲する権利を指定する。SSAはツリーでこのACRをチェックし、指定された別のACRに権利を委譲する権限がこのACRにあるかどうかをチェックする(菱形282)。権限があるなら権利は委譲され(ブロック284)、そうでないなら停止する。図13はその結果を示す。この場合、ACR m1には読み出し権限をACR s1に委譲する権限があるため、委譲の後、s1は鍵を使って価格データにアクセスできるようになる。これは、m1が価格データにアクセスするための権利またはそれ以上の権利を有し、さらにそれを委譲する権限を有する場合に果たすことができる。m1は、一実施形態において、委譲の後にそのアクセス権を保持する。好ましくは、時間やアクセス数を制限するなどにより(永続的にではなく)一定の条件のもとでアクセス権を委譲する。
図14は、鍵と鍵IDを作成するプロセスを示す。実体はACRを通じて認証を受ける(ブロック302)。実体は、ホストによって指定されたIDによる鍵の作成を要求する(ブロック304)。SSAは、指定されたACRにその権限があるかどうかをチェックする(菱形306)。例えば、ある特定のパーティションにあるデータにアクセスするために鍵が使われる場合、SSAはそのパーティションにACRがアクセスできるかどうかをチェックすることになる。ACRにその権限がある場合、メモリ装置10はホストから提供された鍵IDと関連付けられた鍵値を作成し(ブロック308)、鍵IDをACRに記憶し、鍵値をメモリ(コントローラ関連メモリまたはメモリ20のいずれか)に記憶し、実体から提供された情報に従って権利と権限を付与し(ブロック310)、付与された権利および権限で該当するACRのPCRを修正する(ブロック312)。従って、読み出しおよび書き込み権限、同じAGPの中にある他のACRまたは下位レベルのACRに委譲し共有する権利、鍵の所有権を譲渡する権利等、鍵の作成元はすべての権利を有する。
図15に示すように、ACRはSSAシステムの中にある別のACRの権限(またはACRの存在そのもの)を変更できる。実体はこれまでどおりACRを通じてツリーに入る場合がある。この場合は実体の認証が行われ、実体はACRを指定する(ブロック330、332)。実体はターゲットACRの削除またはターゲットACRの権限の削除を要求する(ブロック334)。指定されたACRまたはその時点でアクティブなACRにその権利があるなら(菱形336)、ターゲットACRを削除し、あるいはそのような権限を削除するためにターゲットACRのPCRを変更する(ブロック338)。これが認可されない場合、システムは停止する。
前述したプロセスの後、ターゲットはプロセスの前にアクセスできたデータにアクセスできなくなる。図16に示すように、かつて存在したACR IDはもはやSSAに存在しないため、ターゲットACRに入ることを試みる実体は認証プロセスの失敗に気づくので、アクセス権は拒否される場合がある(菱形352)。ACR IDが削除されていないと仮定した場合、実体はACRを指定し(ブロック354)、鍵IDおよび/または特定のパーティションのデータを指定し(ブロック356)、SSAはそのようなACRのPCRに従って鍵IDまたはパーティションアクセス要求が許可されるかどうかをチェックする(菱形358)。権限が削除されているか、あるいは失効している場合、要求は再度却下される。そうでない場合、要求は許諾される(ブロック360)。
前述したプロセスは、ACRとそのPCRが別のACRによって変更された場合であれ、あるいは初めからそのように構成されていた場合であれ、被保護データに対するアクセスが装置(例えば、フラッシュカード)によってどのように管理されるかを説明するものである。
セッション
SSAシステムは、同時にログインする複数のユーザを処理するように設計されている。この機能を使用する場合、SSAによって受信されるコマンドには特定の実体が対応し、コマンドは、この実体の認証に用いるACRに要求された動作を行う権限がある場合に限り実行される。
複数の実体はセッションのコンセプトによってサポートされる。セッションは認証プロセスで確立し、SSAシステムによってセッションidが割り当てられる。セッションidはシステムへのログインに使われたACRに内部で関連付けられ、実体へエクスポートされ、それ以降のSSAコマンドで使われる。
SSAシステムは、2通りのセッション、すなわちオープンセッションとセキュアセッションとをサポートする。認証プロセスと関連付けられたセッションのタイプはACRの中で設定される。SSAシステムは、認証の施行と同様のやり方でセッション確立を施行する。実体の権限はACRで設定されるため、システム設計者は特定の鍵IDに対するアクセスまたは特定のACR管理操作(新規ACRの作成、信用証明の設定等)の実行にセキュアトンネルを関連付けることができる。
オープンセッション
オープンセッションはセッションidで識別されるセッションであるが、バス暗号化は行われないため、コマンドとデータはいずれも暗号化されずに引き渡される。この動作モードは、好ましくは実体が脅威モデルに該当せずバス上で傍受を行わない多数のユーザまたは多数の実体環境に使用される。
オープンセッションはパーティションまたは鍵を保護する必要がある場合にも使用できる。しかし、有効な認証プロセスの後にはホスト側のすべての実体にアクセスが許諾される。ホストアプリケーションはセッションidさえあれば認証済みACRの権限を得ることができる。これは図17Aに例示されている。線400より上のステップはホスト24によって実行されるステップである。ACR1の認証(ブロック402)を終えた実体は、メモリ装置10で鍵ID Xと関連付けられたファイルへのアクセスを要求する(ブロック404、406、および408)。ACR1のPCRがこのアクセスを認める場合、装置10は要求を許諾する(菱形410)。そうでない場合、システムはブロック402まで戻る。認証が完了した後、メモリシステム10はコマンドを発行する実体を(ACR信用証明ではなく)割り当てられたセッションidのみで識別する。オープンセッションでいったんACR1がPCRの鍵IDと関連付けられたデータに到達すると、他のどのアプリケーションまたはユーザでも、ホスト24上の様々なアプリケーションによって共有される正しいセッションidを指定することによって同じデータにアクセスできる。この機能は、一度のみログインし、様々なアプリケーションに対してログインに使われたアカウントに結合されたすべてのデータにアクセスできることがユーザにとって好都合な場合のアプリケーションに有利である。携帯電話機のユーザの場合、記憶されたeメールにアクセスし、ログインを繰り返すことなくメモリ20に記憶された音楽を聞くことができる。一方、ACR1に該当しないデータにはアクセスできないことになる。このため、ゲームや写真等の同じ携帯電話機のユーザにとって貴重となり得るコンテンツは、別のアカウントACR2を通じてアクセスされる。これは、携帯電話機のユーザの電話機を借りる人にアクセスさせたくないデータであるが、携帯電話機のユーザにとって、最初のアカウントACR1でアクセスできるデータなら他人がアクセスしてもよい。データへのアクセスを2つの別々のアカウントに分け、ACR1へのアクセスをオープンセッションで行うことにより、使い易くなるばかりでなく貴重なデータを保護できる。
セキュアセッション
セキュリティ層を追加するため、セッションidは図17Bに示すように使ってもよい。この場合はメモリ10もアクティブセッションのセッションidを記憶する。図17Bで、例えば鍵ID Xと関連付けられたファイルにアクセスするには、実体もセッションid、例えばセッションid「A」を提供する必要があり、その上でファイルへのアクセスが許可されることになる(ブロック404、406、412、および414)。このように、要求する実体は正しいセッションidを知らない限りメモリ10にアクセスできない。セッションidはセッションが終わった後に削除され、セッションのたびに異なるため、実体はセッション番号を提供できた場合に限りアクセスできる。
SSAシステムは、コマンドが実際に正しい認証済み実体から届いているかどうかを、セッション番号を使って追跡する。攻撃者がオープンチャネルを使って悪質なコマンドの送信を試みるおそれがある用途や使用がある場合、ホストアプリケーションはセキュアセッション(セキュアチャネル)を使用する。
セキュアチャネルを使用する場合、セッションidとコマンド全体がセキュアチャネル暗号化(セッション)鍵を使って暗号化され、そのセキュリティ水準はホスト側の実施例と同じくらい高くなる。
セッションの終了
セッションは次に記すシナリオのいずれか1つで終了し、ACRはログオフされる。
1.実体が明示的なセッション終了コマンドを発行する。
2.通信タイムアウトが発生する。ある特定の実体がACRパラメータの一パラメータとして設定された期間にわたってコマンドを発行しなかった。
3.装置(例えば、フラッシュカード)のリセットおよび/またはパワーサイクルの後にはすべてのオープンセッションが終了する。
データ保全サービス
SSAシステムは、SSAデータベース(ACR、PCR等を収容)が完全な状態に保たれていることをベリファイする。このほかに、鍵ID機構による実体データのデータ保全サービスも提供される。
鍵IDの暗号化アルゴリズムがハッシュモードに設定される場合、CEKおよびIVと併せてハッシュ値がCEK記録に記憶される。書き込み操作中にはハッシュ値の計算と記憶が行われる。読み出し操作のときにも再度ハッシュ値を計算し、前の書き込み操作中に記憶された値と比較する。実体が鍵IDにアクセスするたびに追加のデータが古いデータに(暗号的に)連結され、該当するハッシュ値(読み出しまたは書き込みのため)が更新される。
鍵IDと関連付けられた、または鍵IDによって指示される、データファイルを知るのはホストのみであるため、データ保全機能の各態様はホストが明示的に次のように管理する。
1.鍵IDと関連付けられた、または鍵IDによって指示される、データファイルは最初から最後まで書き込まれるか、または読み出される。SSAシステムはCBC暗号方式を使用し、データ全体のハッシュ化メッセージダイジェストを生成するため、ファイルの一部分にアクセスする試みによってファイルは混乱することになる。
2.中間ハッシュ値はSSAシステムによって管理されるため、連続するストリームの中でデータを処理する必要はない(このデータストリームは他の鍵IDのデータストリームでインターリーブでき、複数のセッションにわたって分割できる)。しかし、実体は、データストリームが再度始まる場合にハッシュ値のリセットをシステムに明示的に指示する必要がある。
3.ホストは読み出し操作が完了すると、読み出されたハッシュを書き込み操作中に計算したハッシュ値と比較することによって有効にすることをSSAシステムに明示的に要求する。
4.SSAシステムは「ダミー読み出し」操作も提供する。この機能によりデータは暗号化エンジンを通過するが、ホストには送出されないことになる。この機能を利用すれば、データが実際に装置(例えば、フラッシュカード)から読み出される前に、データが完全な状態に保たれていることをベリファイすることができる。
乱数生成
外部実体はSSAシステムの内部乱数生成器を利用でき、乱数はSSAシステムの外で使用できる。このサービスはいずれのホストでも利用でき、認証は必要ない。
代替の実施形態
階層アプローチを使う代わりに、図18に示すデータベースアプローチを使って同様の結果を達成できる。
図18に示すように、コントローラ12またはメモリ20に記憶されたデータベースに入力された実体の信用証明リスト、認証方法、最大失敗数、遮断解除に必要な最小信用証明数等は、メモリ10のコントローラ12によって実行されるデータベース内の方針(鍵・パーティションに対する読み出し、書き込みアクセス、セキュアチャネル要件)に結び付いている。鍵・パーティションアクセスに対する制約事項や制限事項もデータベースに記憶される。ホワイトリストにある可能性がある実体(例えば、システム管理者)はすべての鍵とパーティションにアクセスできる。ブラックリストにある可能性がある実体による情報アクセスの試みは阻止される。制限は全域におよぶ場合と鍵および/またはパーティションごとに適用される場合とがある。これは、特定の実体のみが特定の鍵・パーティションにアクセスでき、特定の実体はアクセスできないことを意味する。コンテンツのパーティションや、コンテンツの暗号化または復号化に使う鍵にかかわりなく、コンテンツ自体に制約を課すこともできる。したがって、データ(例えば、歌)にアクセスする可能性がある最初の5ホスト装置のみにアクセスを許可したり、あるいはデータ(例えば、映画)にアクセスしたりする実体は問わず、データの読み出し回数を制限することができる。
認証
パスワード保護
・パスワード保護は、被保護領域へアクセスする場合にパスワードの提示が求められることを意味する。パスワードが1つに限られる場合を除き、それぞれのパスワードには読み出しアクセスや読み出し/書き込みアクセス等、別々の権利を割り振ることができる。 ・パスワード保護は、ホストから提供されるパスワードを装置(例えば、フラッシュカード)がベリファイできること、すなわち装置もまた装置によって管理され保護されたメモリ領域にパスワードを記憶することを意味する。
問題と限界
・パスワードはリプレー攻撃を被ることがある。提示のたびに変わらないパスワードは同じ状態で再送できる。つまり、保護の対象となるデータが貴重で、通信バスへのアクセスが容易い場合、パスワードを現状のまま使用するべきではない。
・パスワードによって記憶データへのアクセスは保護できるが、(鍵ではなく)データの保護のためにパスワードを使用するべきではない。
・パスワードに関わるセキュリティ水準を上げるため、親鍵を使ってパスワードを多様化すれば、1つのパスワードがハッキングされてもシステム全体が破られることはない。パスワードの送信にはセッション鍵方式のセキュア通信チャネルを使用できる。
図19は、パスワードを使った認証を示すフローチャートである。実体はアカウントidとパスワードをシステム10(例えば、フラッシュメモリカード)へ送信する。システムは、パスワードが自身のメモリにあるパスワードに一致するかどうかをチェックする。一致する場合は認証済みステータスを返す。そうでない場合はそのアカウントのエラーカウンタが増加し、実体にはアカウントidとパスワードの再入力が求められる。システムはカウンタが一杯になるとアクセス拒否ステータスを返す。
SSAは証明書チェーンに対応する。これは、識別される側の公開鍵が別のCA、すなわち識別する側が信用するCAとは異なるCAによって署名されることを意味する。この場合の識別される側は、自分自身の証明書のほかに、その公開鍵に署名したCAの証明書を提供する。この第2レベルの証明書さえも相手方によって信用されない(信用CAによって署名されていない)場合、第3レベルの証明書を提供できる。この証明書チェーンアルゴリズムでは、各当事者が公開鍵の認証に必要な証明書の完全なリストを所有する。このことは、図23および24に例示されている。この種のACRによる相互認証に必要な信用証明は、一定の長さを有するRSA鍵対である。
SSA証明書
SSAは[X.509]バージョン3デジタル証明書を採用する。[X.509]は汎用規格であり、ここで説明するSSA証明書プロファイルは証明書の所定フィールドの内容をさらに指定し、制限する。この証明書プロファイルは、証明書チェーンの管理に用いる信頼階層と、SSA証明書の検査と、証明書失効リスト(CRL)プロファイルも規定する。
証明書は公開情報(内部の公開鍵として)とみなされるため、暗号化されない。しかし、証明書はRSA署名を含み、このRSA署名によって公開鍵やその他の情報フィールドが改竄されていないことをベリファイする。
[X.509]はASN.1規格を使った各フィールドのフォーマットを定め、ASN.1規格はデータ符号化にDERフォーマットを使用する。
ホスト証明書階層
装置は、2つの要素、すなわち装置に記憶されたルートCA証明書(ACR信用証明としてACRの作成時に記憶)と、装置への(その特定のACRへの)アクセスを試みる実体から提供される証明書/証明書チェーンとに基づき、ホストを認証する。
ホスト証明機関は、それぞれのACRに対してルートCA(ACR信用証明の中にある証明書)の役割を果たす。例えば、ある1つのACRにとってのルートCAは「ホスト1 CA(レベル2)証明書」であり、別のACRにとってのルートCAは「ホストルートCA証明書」である。それぞれのACRに対して、ルートCAによって署名された証明書(またはルートCAを末端実体証明書までつなげる証明書チェーン)を保持するすべての実体が、末端実体証明書の対応する秘密鍵を有している場合、そのACRにログインできる。前述したように、証明書は公知であり、秘密にしない。
ルートCAによって発行された証明書(ならびに対応する秘密鍵)の所有者は誰でもそのACRにログインできるということは、ある特定のACRに対する認証がそのACRの信用証明に記憶されたルートCAの発行者によって決まることを意味する。換言すると、ルートCAの発行者がACRの認証方式を管理する実体になる。
ホストルート証明書
ルート証明書は、ログインを試みる実体(ホスト)の公開鍵のベリファイを開始するのにSSAが使われるときに使用する信用CA証明書である。この証明書はACRの作成時にACR信用証明の一部として提供される。これはPKIシステムに対する信用の根元にあたるものであるため、信用された実体(父ACR、または製造/構成信頼環境)から提供されることが前提となる。この証明書をベリファイするSSAは、その公開鍵を使って証明書の署名をベリファイする。ホストルート証明書は暗号化された状態で不揮発性メモリ(図1には示されていない)に記憶され、装置の秘密鍵にアクセスできるものは、好ましくは図1のシステム10のCPU12のみである。
ホスト証明書チェーン
これらの証明書は認証中にSSAへ提供される。チェーンの処理が完了した後にホストの証明書チェーンを再度集めて装置に記憶することはしない。
図20は、多数のホスト証明書チェーンを示す、ホスト証明書レベル階層の概略図である。図20に示すように、ホスト証明書は多数の証明書チェーンを有することがあり、ここでは3つの証明書チェーンのみが例示されている。
A1.ホストルートCA証明書502、ホスト1 CA(レベル2)証明書504、
ホスト証明書506
B1.ホストルートCA証明書502、ホストn CA(レベル2)証明書508、
ホスト1 CA(レベル3)証明書510、ホスト証明書512
C1.ホストルートCA証明書502、ホストn CA(レベル2)証明書508、
ホスト証明書514
前述した3つの証明書チェーンA1、B1、およびC1は、ホストの公開鍵が真正であることを証明するために使われてもよい3通りのホスト証明書チェーンを例示するものである。図20と前述した証明書チェーンA1を参照し、ホスト1のCA(レベル2)証明書504の公開鍵はホストルートCAの秘密鍵によって署名され(すなわち、公開鍵のダイジェストを暗号化)、この公開鍵はホストルートCA証明書502にある。したがって、ホストルートCAの公開鍵を有する実体は、前述した証明書チェーンA1の信憑性をベリファイできることになる。この実体は最初のステップとして、ホストから送信されたホスト1のCA(レベル2)証明書504の署名済み公開鍵を、自身が所有するホストルートCAの公開鍵を使って復号化し、復号化した署名済み公開鍵を、ホストから送信されたホスト1のCA(レベル2)証明書504の署名されていない公開鍵のダイジェストと比較する。2つが一致する場合、ホスト1のCA(レベル2)の公開鍵は認証され、実体は次に、ホストから送信されたホスト証明書506の中にあるホスト1のCA(レベル2)の秘密鍵によって署名されたホストの公開鍵を、ホスト1のCA(レベル2)の認証済み公開鍵を用いて復号化することになる。この復号化された署名済みの値が、ホストから送信されたホスト証明書506の中にある公開鍵のダイジェストの値に一致する場合、ホストの公開鍵も認証される。証明書チェーンB1およびC1を使った認証も同様に行われる。
チェーンA1が関わる前述したプロセスから分かるように、ホストから送信され実体によってベリファイされる最初の公開鍵は、ホストルートCA証明書ではなくホスト1のCA(レベル2)の公開鍵である。このため、ホストが実体へ送る必要があるものはホスト1のCA(レベル2)証明書504とホスト証明書506であって、ホスト1のCA(レベル2)証明書はチェーンの中で最初に送信される必要があることになる。前述したように、証明書のベリファイ順序は次のとおりである。ベリファイする側の実体、すなわちこの場合のメモリ装置10はまず、チェーンの中で最初の証明書の公開鍵の真性をベリファイし、この場合のものはルートCAの下に位置するCAの証明書504である。この証明書の公開鍵が真正であることをベリファイした後、装置10は次の証明書のベリファイに進み、この場合のものはホスト証明書506である。証明書チェーンが3つ以上の証明書を含む場合のベリファイ順序も同様に、ルート証明書のすぐ下に位置する証明書から始まり、認証の対象となる実体の証明書で終わる。
装置証明書階層
ホストは2つの要素、すなわちホストに記憶された装置ルートCAと、装置からホストへ提供される(ACRの作成時に信用証明として装置に提供される)証明書/証明書チェーンとに基づき装置を認証する。ホストによる装置の認証プロセスは、前述した装置によるホスト認証プロセスに類似する。
装置証明書チェーン
これらの証明書はACRの鍵対の証明書である。これらの証明書はACRの作成時にカードに提供される。SSAはこれらの証明書を個別に記憶し、認証のときにはそれらを1つずつホストに提供する。SSAはこれらの証明書を使ってホストの認証を受ける。装置は3つの証明書からなるチェーンを処理できるが、証明書数が3以外になる場合がある。証明書の数はACRによって異なることがある。これはACRが作成されるときに決まる。装置はホストに向けて証明書チェーンを送信できるが、証明書チェーンデータを使用するわけではないので、証明書チェーンを解析する必要はない。
図21は、SSAを使用する記憶装置等の装置で1〜n通りの証明書チェーンを示す、装置証明書レベル階層の概略図である。図21に示されたn通りの証明書チェーンは次のとおりである。
A2.装置ルートCA証明書520、装置1 CA(製造業者)証明書522、
装置証明書524
B2.装置ルートCA証明書520、装置n CA(製造業者)証明書526、
装置証明書528
図22に示すように、装置10のSSMシステム542がホストシステム540を認証するプロセスには3つの段階がある。最初の公開鍵ベリファイ段階では、ホストシステム540がSSMコマンドでホスト証明書チェーンをSSMシステム542へ送信する。SSMシステム542は、ホスト証明書544の真性とホスト公開鍵546の真性を、ACR550のホストルート証明書548にあるルート証明機関公開鍵を用いてベリファイする(ブロック552)。ルート証明機関とホストの間に中間証明機関が介在する場合、中間証明書549もブロック552のベリファイに使われる。ベリファイまたはプロセス(ブロック552)が成功したと仮定し、SSMシステム542は第2段階へ進む。
図24は、本発明の一実施形態を例示する証明書チェーン590の図である。前述したように、ベリファイする場合に提示の必要がある証明書チェーンは多数の証明書を含むことがある。図24の証明書チェーンは全部で9つの証明書を含み、認証する場合にはこれらの証明書をすべてベリファイすることが必要となる場合がある。背景技術の欄で前に説明したように、既存の証明書ベリファイシステムでは、送信される証明書チェーンに不備があったり、信用証明全体が送信されたり、証明書が特定の順序で送信されないと、受信側は証明書を一通り受信し記憶するまで証明書を解析できない。しかし、チェーンに含まれる証明書の数は事前に分からないため、問題が生じることがある。長さが定かでない証明書チェーンを記憶するために大量の記憶容量を確保する必要になることがある。これはベリファイを行う記憶装置にとって問題になることがある。
本発明の一実施形態は、証明書チェーンが記憶装置によってベリファイされる順序と同じ順序でホスト装置が証明書チェーンを送信するシステムによってこの問題を軽減できるという認識に基づく。よって、図24に示すように、証明書のチェーン590は、ホストルート証明書のすぐ下に位置する証明書590(1)から始まり、ホスト証明書に相当する証明書590(9)で終わる。したがって、装置10はまず、証明書590(1)で公開鍵をベリファイし、その後に証明書590(2)で公開鍵のベリファイ等を行い、最後に証明書590(9)で公開鍵をベリファイする。これで証明書チェーン590全体のベリファイプロセスは完了する。ホスト装置が証明書チェーン590をベリファイと同じ順序でメモリ装置10へ送信する場合、メモリ装置10は証明書が届くたびにベリファイを開始することができ、チェーン590に含まれる9つの証明書が一通り届くまで待つ必要はない。
したがって、ホスト装置は、一実施形態において、メモリ装置10に対してチェーン590の証明書を一度に1つずつ送信する。メモリ装置10は一度に1つの証明書を記憶することになる。チェーンの中の最後の証明書を除き、ベリファイ済みの証明書はホストから送信される次の証明書で上書きできる。このため、メモリ装置10には、1つのみの証明書を随時記憶する容量を確保すればよい。
メモリ装置は、チェーン590が一通り届いたことを知る必要がある。このため、好ましくは、最後の証明書590(9)には、これがチェーンの中で最後の証明書であることを伝える標識または標示を入れる。これを例示する図25の表は、ホストからメモリ装置10へ送信される証明書バッファに先行する制御セクタ内の情報を示す。図25に示すように、証明書590(9)の制御セクタには引数名「最終」フラグがある。メモリ装置10は、「最終」フラグが設定されているかどうかをチェックして受信した証明書がチェーンにおける最終証明書であるかどうかを判断することにより、チェーンの中で証明書590(9)が最後の証明書であることをベリファイできる。
代替的な実施形態では、チェーン590の証明書を1つずつ送信するのではなく、1つ、2つ、または3つの証明書からなるグループで送信してもよい。当然ながら、グループで使用する証明書の数は異なる場合があったり、あるいは同じになる場合がある。チェーン590には5つの連続する証明書列591、593、595、597、および599がある。それぞれの列は少なくとも1つの証明書を含む。ある1つの証明書の列には、チェーンの中で該当する1列の先行列に隣接する証明書(先頭証明書)と、チェーンの中で該当する1列の後続列に隣接する証明書(終端証明書)と、先頭証明書と終端証明書との間にある全証明書が含まれる。例えば列593の中には、全部で3つの証明書590(2)、証明書590(3)、および証明書590(4)がある。メモリ装置10による5つの証明書の列のベリファイは591、593、595、597の順で行われ、599で終わる。したがって、5つの列がメモリ装置10によるベリファイと同じ順序で送信され、受信される場合、ベリファイ済みの列をメモリ装置で記憶する必要はなくなり、最後の列を除く列はいずれも、ホストから到着する次の列で上書きできる。前の実施形態と同様に、チェーン内の最後の証明書には標識、例えばこれがチェーンにおける最後の証明書であることを伝える特定の値に設定されたフラグを入れるのが望ましい。この実施形態の場合、メモリ装置は5つの列のうち、証明書数が最も多い列の証明書を記憶する十分な容量を確保するだけでよい。よって、ホストが送ろうとする列のうちの最も大きい列を事前にメモリ装置10に知らせる場合、メモリ装置10は最も大きい列のための十分な容量を確保するだけでよい。
好ましくは、ホストによって送信されるチェーン中の各証明書の長さは、その証明書によって証明される公開鍵の長さの4倍以下である。同様に、メモリ装置の公開鍵を証明するためにメモリ装置10からホスト装置へ送信される証明書の長さは好ましくは、その証明書によって証明される公開鍵の長さの4倍以下である。
図26のフローチャートは、前述した証明書チェーンベリファイの実施形態を示すものであり、ここでは簡潔を図るため、各グループ内の証明書数を1と仮定する。図26に示すように、ホストはカードに向けてチェーン内の証明書を順次送信する。チェーンの中の第1の証明書(前述したように、通常はルート証明書の後続証明書)から始まって、カードは、認証の対象となるホストから証明書チェーンを順次受信する(ブロック602)。そして、カードは受信する証明書の各々をベリファイし、証明書のいずれかでベリファイに失敗した場合はプロセスを中止する。カードは、証明書のいずれかでベリファイに失敗した場合、ホストに通知する(ブロック604、606)。次に、カードは、最後の証明書が受信されベリファイされたかどうかを検出する(菱形608)。最終証明書の受信とベリファイとがまだであれば、カードはブロック602まで戻り、ホストからの証明書の受信とベリファイを続行する。最終証明書を受信し、ベリファイしたら、カードは証明書ベリファイの後に続く次の段階へ進む(610)。図26とそれ以降の図の内容は例としてメモリカードを参照するが、物理的形態がメモリカードではないメモリ装置にもこれらの内容が当てはまることが理解できる。
図27は、カードがホストを認証する場合にホストによって実行されるプロセスを示す。図27に示すように、ホストはチェーンの中の次の証明書をカードに送信する(ブロック620)(通常はルート証明書の後続証明書から始まる。ホストは、認証の失敗を伝える中止通知がカードから届いているかどうかを判断する(菱形622)。中止通知が届いているならホストは停止する(ブロック624)。中止通知が届いてなければ、ホストは送信された最後の証明書で「最終フラグ」が設定されているかどうかをチェックすることにより、チェーンの最終証明書が送信済みかどうかを確認する。最終証明書が送信済みであれば、ホストは証明書ベリファイの後に続く次の段階へ進む(ブロック628)。図22および23に示すように、次の段階はチャレンジ・レスポンスであり、その後にセッション鍵の作成が続いてもよい。チェーンの最終証明書が送信済みでなければ、ホストはブロック620まで戻り、チェーン内の次の証明書を送信する。
図28および図29は、カードが認証される場合にカードとホストがとる動作を示す。図28に示すように、カードは開始後、チェーンの中で証明書の送信を求めるホストからの要求を待つ(ブロック630、菱形632)。ホストから要求が届かなければ、カードは菱形632へ戻る。ホストから要求が届く場合、カードはチェーンの中の次の証明書を送信することになり、これは送信すべき最初の証明書から始まる(通常はルート証明書の後続証明書から始まる)(ブロック634)。カードは、ホストから失敗通知が届いたかどうかを判断する(菱形636)。失敗通知が届いた場合、カードは停止する(ブロック637)。失敗通知が届かない場合、カードは最終証明書が送信済みかどうかを判断する(菱形638)。最終証明書が送信済みでなければ、カードは菱形632まで戻り、チェーン内の次の証明書の送信を求める次の要求をホストから受け取るまで待つ。最終証明書が送信済みであれば、カードは次の段階へ進む(ブロック639)。
図29は、カードが認証される場合にホストがとる動作を示す。ホストは、チェーン内の次の証明書を求める要求をカードへ送り、これは送信されるべき最初の証明書に対する要求から始まる(ブロック640)。ホストは受信するそれぞれの証明書をベリファイし、ベリファイに失敗した場合はプロセスを中止し、カードに通知する(ブロック642)。ベリファイに合格した場合、ホストは最終証明書が受信済みでベリファイに成功したかどうかをチェックする(菱形644)。最終証明書の受信とベリファイがまだであれば、ホストはブロック640まで戻り、チェーン内の次の証明書を求める要求を送る。最終証明書が受信済みでベリファイに成功した場合、ホストは証明書ベリファイの後に続く次の段階へ進む(ブロック646)。
従来の証明書ベリファイ方法では、認証する側またはベリファイする側の実体が、証明書失効リストを所有しているか、あるいはそうでないかにかかわらず、証明機関(CA)から取り込むことができ、認証のために提示される証明書のシリアル番号をリストに照らしてチェックし、提示された証明書が失効しているかどうかを判断することになっている。認証またはベリファイする側の実体がメモリ装置の場合、そのメモリ装置自体が使われなかったら、CAから証明書失効リストは取り込まれない。予め装置に記憶された証明書失効リストが時間を経て古くなると、インストールされた日より後に失効した証明書はリストに現れない。その結果、ユーザは失効した証明書を使ってその記憶装置にアクセスできることになる。これは望ましくない。
一実施形態において、認証を受けようとする実体が、認証の対象となる証明書と併せて証明書失効リストを、認証する側の実体、例えばメモリ装置10に提示するシステムによって前述した問題を解決できる。認証する側の実体は、受け取った証明書の真偽と証明書失効リストの真偽をベリファイする。認証する側の実体は、失効リストで証明書の識別情報の有無、例えば証明書のシリアル番号の有無をチェックすることにより、証明書が失効リストに登記されているかどうかをチェックする。
前述したことを踏まえ、ホスト装置とメモリ装置10との相互認証に非対称認証方式を使うことができる。メモリ装置10の認証を受けようとするホスト装置は、証明書チェーンと対応するCRLの両方を提供する必要がある。一方、ホスト装置は予めCAに接続してCRLを入手しているため、ホスト装置がメモリ装置10を認証する場合、メモリ装置は、証明書または証明書チェーンと併せてCRLをホスト装置に提示する必要はない。
図33および図34は、前述した失効制度の特徴を示す。認証する側の実体(例えば、メモリカード等のメモリ装置)では、認証を受けようとする実体から証明書とCRLを受信する(ブロック702)。暗号化されていないCRLの一部分を処理し(例えば、ハッシュ化し)、それと同時に、提示された証明書の識別情報(例えば、シリアル番号)をそのような部分で検索する。処理された(例えば、ハッシュ化された)CRL部分を完全なハッシュ化CRLに組み立て、認証を受ける側の実体から受信した部分から復号化されたCRL部分を組み立てることによって形成される完全な復号化・ハッシュ化CRLとこれを比較する。一致しないことが比較で明らかになる場合、認証は失敗に終わる。また、認証する側の実体は、現在の時間に照らしてCETと次回更新時間の両方をチェックする(ブロック706、708)。提示された証明書の識別情報がCRLに記載されていることが判明する場合、あるいは現在の時間がCETの範囲内にない場合、あるいはCRLの次回更新時間が過ぎている場合にも、認証は失敗に終わる(ブロック710)。実行に際して、ハッシュ化CRL部分と復号化・ハッシュ化CRL部分を組み立てるために記憶する場合、大量の記憶容量は必要ない場合がある。
認証を受けようとする実体(例えば、ホスト)は、その証明書とCRLを認証する側の実体へ送信し(ブロック722)、次の段階へ進む(ブロック724)。これは図34に示されている。
実体が認証のために証明書チェーンを示する場合にも前述したものと同様のプロセスを実施できる。この場合、チェーンの中の各証明書とその対応するCRLにつき前述したプロセスを繰り返すことになる。各々の証明書とそのCRLを受信したらその都度処理でき、証明書チェーンの残りの部分とその対応するCRLの受信を待たずにすむ。
アイデンティティオブジェクト(IDO)
アイデンティティオブジェクトは、フラッシュメモリカード等のメモリ装置10がRSA鍵対またはその他の暗号IDを記憶するための被保護オブジェクトである。アイデンティティの署名とベリファイ、データの暗号化と復号化に使う暗号IDであればどのようなタイプのものでもアイデンティティオブジェクトに入れることができる。鍵対の公開鍵が真正であることを証明するCAの証明書(または複数のCAの証明書チェーン)もアイデンティティオブジェクトに入れる。アイデンティティオブジェクトを使えば、外部実体や内部カード実体(すなわち、アイデンティティオブジェクトの所有者と呼ばれる装置自体、内部のアプリケーション、その他)のアイデンティティの証拠を提出できる。したがって、カードは、チャレンジ・レスポンス機構でホストを認証するためにRSA鍵対またはその他のタイプの暗号IDを使うのではなく、識別情報の証拠としてカードに提示されるデータストリームに署名する。換言すると、アイデンティティオブジェクトはその所有者の暗号IDを収容する。アイデンティティオブジェクトの中の暗号IDにアクセスするにはまず、ホストを認証する必要がある。後述するように、この認証プロセスはACRによって管理される。ホストの認証に成功したら、アイデンティティオブジェクトの所有者は相手方に対して暗号IDを使って自身のアイデンティティを立証できる。例えば、相手方からホストを通じて提示されるデータには暗号ID(例えば、公開−秘密鍵対の秘密鍵)を使って署名できる。アイデンティティオブジェクトの署名済みデータと証明書はアイデンティティオブジェクトの所有者に代わって相手方へ提示される。証明書にある公開−秘密鍵の公開鍵が真正であることはCA(すなわち、信用機関)によって証明されるため、相手方はこの公開鍵が真正であると信用できる。そこで相手方は証明書の公開鍵を使って署名済みデータを復号化し、復号化されたデータを相手方によって送信されたデータと比較できる。復号化されたデータが相手方によって送信されたデータに一致する場合、アイデンティティオブジェクトの所有者は真正の秘密鍵にアクセスできる自称するとおりの実体であることが分かる。
IDOはどのようなタイプのACRでも作成できるオブジェクトである。ACRは、一実施形態において、1つのみのIDOオブジェクトを有していてもよい。データの署名と保護はいずれも、ACRの認証を受ける実体に対してSSAシステムから提供されるサービスである。IDOの保護水準はACRのログイン認証方式と同じくらい高い。IDOを有することになるACRには任意の認証アルゴリズムを選ぶことができる。IDO運用を良好に保護し得るアルゴリズムを評価し決定するのは作成元(ホスト)である。IDOを有するACRは、IDO公開鍵取得コマンドに応じて証明書チェーンを提供する。
データ保護にIDOを使用する場合でも、カードから出力される復号化データにはさらなる保護が必要になることがある。そのような場合には、いずれかの認証アルゴリズムによって確立されるセキュアチャネルの使用がホストに推奨される。
IDOを作成するときには鍵の長さとPKCS#1バージョンを選択する。一実施形態において、PKCS#1バージョン2.1が定める(指数、係数)表現を公開および秘密鍵に使用する。
IDOの作成中に盛り込まれるデータは、一実施形態において、選択された長さを有するRSA鍵対と、公開鍵の信憑性を帰納的に証明する証明書チェーンである。
図35〜図37はIDOを使った操作を示すものであり、ここでメモリ装置10はフラッシュメモリカードであり、このカードがIDOの所有者である。図35は、ホストへ送信されるデータに署名する場合にカードによって実行されるプロセスを示す。図35を参照し、前述したツリー構造のノードに位置するACRの管理下でホストが認証された後(ブロック802)、カードは証明書を求めるホスト要求を待つ(菱形804)。要求を受け取ったカードは証明書を送り、菱形804へ戻り、次のホスト要求を待つ(ブロック806)。カードが所有するIDOの公開鍵を証明するために証明書チェーンを送信する必要がある場合、チェーンの中のすべての証明書がホストへ送信されるまで前述した操作を繰り返す。それぞれの証明書がホストに送信された後、カードはホストから別のコマンドが届くのを待つ(菱形808)。所定の期間内にホストからコマンドが届かなければ、カードは菱形804へ戻る。ホストからデータとコマンドを受け取ったカードは、そのコマンドをチェックし、データに署名するためのものであるかどうかを確認する(菱形810)。データに署名するためのコマンドである場合、カードはIDOの秘密鍵を使ってデータに署名し、署名したデータをホストへ送信し(ブロック812)、菱形804まで戻る。ホストからのコマンドがホストからのデータに署名するためのものでなければ、カードはIDOの秘密鍵を使って受信データを復号化し(ブロック814)、菱形804まで戻る。
図36は、ホストへ送信されるデータにカードが署名する場合にホストによって実行されるプロセスを示す。図36を参照すると、ホストはカードへ認証情報を送信する(ブロック822)。前述したツリー構造のノードに位置するACRの制御下で認証に成功したら、ホストは証明書チェーンを求める要求をカードへ送り、チェーンを受け取る(ブロック824)。カードの公開鍵のベリファイが終わったら、ホストは署名されるデータをカードへ送信し、カードの秘密鍵で署名されたデータを受信する(ブロック826)。
図37は、ホストがカードの公開鍵を使ってデータを暗号化し、暗号化したデータをカードへ送信するときにホストによって実行されるプロセスを示す。図37を参照すると、ホストはカードへ認証情報を送信する(ブロック862)。ACRの管理下で認証に成功したら、ホストはIDOの中にあるカードの公開鍵をベリファイする場合に必要となる証明書チェーンの要求をカードへ送り(ブロック864)、さらにデータを求める要求をカードに送る。IDOの中にあるカードの公開鍵をベリファイした後、ホストはカードのベリファイ済み公開鍵を使ってカードから届いたデータを暗号化し、カードへ送信する(ブロック866、868)。
一般情報クエリ
このクエリはシステム公開情報を無制限に放出する。メモリ装置に記憶される機密情報は2つの部分、すなわち共有部分と非共有部分とからなる。機密情報の一部分には個々の実体にとっての専有情報が入り、それぞれの実体は自身の専有情報に限りアクセスが認められ、他の実体の専有機密情報にはアクセスできない。この種の機密情報は共有されず、機密情報の非共有部位または部分を形成する。
一般情報クエリによる公開情報へアクセスする場合、ホスト/ユーザはACRにログインする必要がない。このため、SSA規格に精通する者であれば誰でも実行可能であり、情報を受け取ることができる。SSAの規定ではセッション番号なしでこのクエリコマンドが処理される。しかし、機密情報の共有部分へのアクセスを望む実体は最初に、メモリ装置のデータに対するアクセスを制御する制御構造(例えば、ACR)のいずれかを通じて認証を受ける必要がある。認証に成功した実体は、一般情報クエリを使って機密情報の共有部分にアクセスできるようになる。前述したように、認証プロセスの結果としてアクセスのためのSSAセッション番号またはidが割り当てられる。
図38は、一般情報クエリをともなう操作を示すフローチャートである。図38を参照すると、実体から一般情報クエリを受け取ったSSAシステムは(902)、その実体が認証済みかどうかを判断する(菱形904)。認証済みである場合には、システムは公開情報と機密情報の共有部分とを実体に供給する(ブロック906)。認証済みでなければ、システムは公開情報のみを実体に供給する(ブロック908)。
図39は、非公開情報クエリをともなう操作を示すフローチャートである。図39を参照すると、実体から非公開情報クエリを受け取ったSSAシステムは(922)、その実体が認証済みかどうかを判断する(菱形924)。認証済みである場合には、システムは実体に機密情報を供給する(ブロック926)。認証済みでない場合には、システムは機密情報に対する実体のアクセスを拒否する(ブロック(928)。
SSA FSEでカード機能群を拡張するには2つの方法を使う。
・サービス提供:認可された実体が通信パイプと呼ばれる独自のコマンドチャネルを使って内部アプリケーションと直に通信することによって実現する。
・SSA標準アクセス制御方針の拡張:内部の被保護データオブジェクト(CEK、後述するセキュアデータオブジェクト、すなわちSDO等)に内部カードアプリケーションを関連付けさせることによって実現する。そのようなオブジェクトにアクセスするときに所定の標準SSA方針が満たされる場合は関連付けアプリケーションが起動して、標準SSA方針に加えて少なくとも1つの条件を課す。この条件は好ましくは、標準SSA方針とは対峙しない。この追加条件も満たされる場合に限りアクセスが許諾される。FSEの能力をさらに詳述する前に、FSEの構造的態様と通信パイプとSDOをここで取り上げる。
通信(またはパススルー)パイプ
パススルーパイプオブジェクトは、SSMコアとSAMMの制御下で認可されたホスト側実体と内部アプリケーションとの通信を可能にする。ホストと内部アプリケーションとのデータ転送はSENDコマンドとRECEIVEコマンドで行われる(後述)。実際のコマンドはアプリケーションによって異なる。パイプを作る実体(ACR)は、パイプ名とチャネルの開通によってつながるアプリケーションのIDとを提供することが必要になる。他の被保護オブジェクトと同様に、このACRがパイプの所有者になり、標準の委譲ルールおよび制限に従って他のACRに使用権や所有権を委譲できる。
認証済みの実体は、そのACAMでCREATE_PIPE権限が設定されている場合にパイプオブジェクトの作成が許可されることになる。内部アプリケーションとの通信は、そのPCRでパイプ書き込み権限またはパイプ読み出し権限が設定されている場合に限り許可される。所有権とアクセス権の委譲は、実体がパイプの所有者か、あるいはそのPCRでアクセス権委譲が設定されている場合に限り許可される。他のすべての権限と同様に、別のACRへ所有権を委譲する当初の所有者は、好ましくはこの装置アプリケーションに対するすべての権限から引き離される。
書き込みパススルーコマンドと読み出しパススルーコマンドでは、ホストが通信しようとする相手方の装置内部アプリケーション1008のIDをパラメータとして提供する。実体の権限をベリファイし、要求される側のアプリケーションにつながるパイプを使用する権限が要求する側の実体(すなわち、この実体が使っているセッションを運営するACR)にある場合、データバッファを解釈し、コマンドを実行する。
この通信方法により、ホストアプリケーションはSSA ACRセッションチャネルを通じて内部装置アプリケーションにベンダー固有/独自なコマンドを引き渡すことができる。
内部ACR
内部ACRはPCRを有するACRに類似するが、装置10にとって外部の実体はこのACRにログインできない。代替的に、これの管理下にあるオブジェクトか、あるいはこのオブジェクトと関連付けするアプリケーションが呼び出されるときに、図40BのSSA管理部1024が自動的に内部ACRにログインする。アクセスを試みる実体はカードまたはメモリ装置にとって内部の実体であるため、認証の必要はない。SSA管理部1024は内部通信を可能にするために内部ACRにセッション鍵を渡すことになる。
図40Aおよび図40Bを参照すると、ACRとデータ構造が関わるセキュリティ関連操作(例えば、セッション中のデータ転送、暗号化、復号化、ハッシュ計算等の操作)は、モジュール1030がインターフェイス1032と暗号ライブラリ1012の支援を受けて処理する。SSMコアAPI1006は、ホストと受け渡しするACR(外部ACR)が関わる操作と、ホストと受け渡ししない内部ACRが関わる操作を区別しないため、ホストが関わる操作と装置内部アプリケーション1010が関わる操作に区別はない。ホスト側実体によるアクセスと装置内部アプリケーション1010によるアクセスは、同じ制御機構によって制御される。このため、ホスト側アプリケーションと装置内部アプリケーション1010とでデータ処理を柔軟に区別できる。内部アプリケーション1010(例えば、図42のFSE1102)は内部ACR(例えば、図42のACR1103)と関連付けし、これの管理のもとで起動する。
OTP操作は2つの段階、すなわち図43に示すシード提供段階と図44に示すOTP生成段階とを伴う。図40〜図42も併せて参照することで、この説明に役立つ。図43はシード提供プロセスを示すプロトコル図である。図43に示すように、ホスト24等のホストとカードは様々な動作をとる。SSMコア1004を含む図40Aおよび40BのSSMシステムは、カード側で様々な動作をとる1実体である。図42に示すFSE1102もカード側で様々な動作をとる実体である。
SSMシステムはIDOの公開鍵を用いてシード要求に署名し、署名の完了をアプリケーションに通知する(矢印1132)。次に、起動アプリケーションはIDOの証明書チェーンを要求する(矢印1134)。これに応じて、SSMシステムは、ACR1103の制御下でIDOの証明書チェーンを提供する。起動アプリケーションは通信パイプを通じて署名済みシード要求とIDOの証明書チェーンをSSMシステムへ提供し、SSMシステムは同じものをホストへ転送する(矢印1138)。通信パイプにおける署名済みシード要求とIDO証明書チェーンの送信は、図40AのSAMM1008とSSMコア1004との間で確立するコールバック関数によって行われるが、このコールバック関数については以降で詳述する。
ホストが受け取った署名済みシード要求とIDO証明書チェーンは、図41に示す認証サーバ1052へ送信される。署名済みシード要求の出所が信用できるトークンであることはカードから提供される証明書チェーンで証明されているため、認証サーバ1052には秘密シードをカードに提供する用意がある。そこで認証サーバ1052は、IDOの公開鍵で暗号化されたシードをユーザACR情報と併せてホストに送信する。このユーザ情報により、N個のユーザACRのうち、これから生成するOTPにユーザがアクセスするためのユーザACRがいずれであるのかが明らかになる。ホストはアプリケーションIDを提供することによってFSE1102でOTPアプリケーションを起動し、これによりこのアプリケーションに対応する通信パイプも選択され、さらにホストはユーザACR情報をSSMシステムへ転送する(矢印1140)。暗号化されたシードとユーザACR情報は通信パイプを通じて選択されたアプリケーションへ転送される(矢印1142)。起動したアプリケーションは、IDOの秘密鍵を使ってシードを復号化する要求をSSMシステムに送る(矢印1144)。SSMシステムはシードを復号化し、復号化の完了を伝える通知をアプリケーションに送る(矢印1146)。起動アプリケーションは、セキュアデータオブジェクトを作成し、そのセキュアデータオブジェクトにシードを記憶することを要求する。起動アプリケーションは、使い捨てパスワードを生成するため、そのSDOにOTPアプリケーション(要求するアプリケーションと同じアプリケーションであってもよい)のIDを割り振ることも要求する。SSMシステムはSDO1114のいずれか1つを作成し、そのSDOの中にシードを記憶し、OTPアプリケーションのIDをSDOに割り振り、完了したらアプリケーションに通知を送る(矢印1150)。アプリケーションは、ホストから提供されたユーザ情報に基づきSDO1114にアクセスするためのアクセス権を内部ACRから該当するユーザACRへ委譲することをSSMシステムに要求する(矢印1152)。委譲が完了したらSSMシステムはアプリケーションに通知する(矢印1154)。アプリケーションは、コールバック関数によりSDOの名前(スロットID)を通信パイプ経由でSSMシステムへ送信する(矢印1156)。SSMシステムは同じものをホストへ転送する(矢印1158)。ホストはSDOの名前をユーザACRに結合し、このため、ユーザはSDOにアクセスできるようになる。
前述した実施形態から提供される別の利点として、ユーザ等の外部実体と装置内部アプリケーションはいずれもセキュリティデータ構造によって制御されるデータを利用するが、ユーザがアクセスできるものは装置内部アプリケーションによって記憶データから検索される結果のみである。OTP実施形態の場合、ホスト装置を通じてユーザが入手できるものはOTPのみであって、シード値は入手できない。DRM実施形態の場合、ホスト装置を通じてユーザが入手できるものは再生されたコンテンツのみであって、ライセンスファイルまたは暗号鍵のいずれにもアクセスできない。このため、セキュリティを損なうことなく消費者の便宜を図ることができる。
DRMの一実施形態において、装置内部アプリケーションもホストも暗号鍵にアクセスせず、セキュリティデータ構造のみがこれにアクセスする。別の実施形態において、セキュリティデータ構造以外の実体も暗号鍵にアクセスできる。鍵が装置内部アプリケーションによって生成され、セキュリティデータ構造によって制御される場合もある。

Claims (17)

  1. 不揮発性記憶装置であって、
    コントローラと、
    秘密鍵と公開鍵とを備える鍵対と、前記鍵対を認証するための証明書とを記憶する不揮発性メモリと、
    実体を認証するための前記コントローラによって使用可能な情報と、さらに前記実体が前記コントローラによって認証され次第、前記実体を許可できるかどうかを判断して前記鍵対と証明書とにアクセスするための前記コントローラによって使用可能な情報とを含むアクセス制御構造と、を備え、
    前記コントローラは、
    前記アクセス制御構造を用いて前記不揮発性記憶装置に対して実体を認証し、
    前記実体が成功裏に認証された後、データとコマンドを受信して前記実体からのデータに署名し、
    秘密鍵を使用してデータまたは前記データから検索される情報に署名し、
    前記証明書と前記データまたは前記データから検索される情報とを前記実体へ送信するように操作される不揮発性記憶装置。
  2. 請求項1記載の不揮発性記憶装置において、
    前記不揮発性メモリとコントローラとを囲い込む筐体をさらに備える不揮発性記憶装置。
  3. 請求項2記載の不揮発性記憶装置において、
    前記筐体は、カードの形状を有する不揮発性記憶装置。
  4. 請求項1記載の不揮発性記憶装置において、
    前記証明書は、証明書チェーンである不揮発性メモリシステム。
  5. 請求項1記載の不揮発性記憶装置において、
    前記不揮発性メモリは、フラッシュメモリである不揮発性記憶装置。
  6. 請求項1記載の不揮発性記憶装置において、
    前記アクセス制御構造によって、認証済み実体のみがデータにアクセスできる不揮発性記憶装置。
  7. 請求項1記載の不揮発性記憶装置において、
    前記コントローラは、前記アクセス制御構造を用いて実体を認証し、公開鍵を証明するために前記証明書を認証済み実体に供給する不揮発性記憶装置。
  8. 実体のアイデンティティの証拠を提供する方法であって、
    (i)コントローラと、(ii)秘密鍵と公開鍵とを備える鍵対と、前記鍵対を認証するための証明書とを記憶する不揮発性メモリと、(iii)実体を認証するための前記コントローラによって使用可能な情報と、さらに前記実体が前記コントローラによって認証され次第、前記実体を許可できるかどうかを判断して前記鍵対と証明書とにアクセスするための前記コントローラによって使用可能な情報とを含むアクセス制御構造とを備える不揮発性記憶装置内で次のステップを実行するステップであって
    前記アクセス制御構造を用いて前記不揮発性記憶装置に対して実体を認証するステップと、
    前記実体が成功裏に認証された後、
    データとコマンドを受信して前記実体からのデータに署名するステップと、
    秘密鍵を使用してデータまたは前記データから検索される情報に署名するステップと、
    前記証明書と前記データまたは前記データから検索される情報とを前記実体へ送信するステップと、
    を含む方法。
  9. 請求項8記載の方法において、
    前記実体が成功裏に認証された後、公開鍵を証明するために前記証明書を実体に供給するステップと、
    公開鍵によって暗号化されたデータを受信するステップと、
    秘密鍵を用いてデータを復号化するステップと、
    をさらに含む方法。
  10. 請求項8記載の方法において、
    前記不揮発性記憶装置は、前記不揮発性メモリとコントローラとを囲い込む筐体を備える方法。
  11. 請求項10記載の方法において、
    前記筐体は、カードの形状を有する方法。
  12. 請求項8記載の方法において、
    前記証明書は、証明書チェーンである方法。
  13. 請求項8記載の方法において、
    前記不揮発性メモリは、フラッシュメモリである方法。
  14. 請求項8記載の方法において、
    前記アクセス制御構造によって、認証済み実体のみがデータにアクセスできる方法。
  15. 請求項8記載の方法において、
    前記コントローラは、前記アクセス制御構造を用いて実体を認証し、公開鍵を証明するために前記証明書を認証済み実体に供給する方法。
  16. 請求項1記載の不揮発性記憶装置において、
    前記実体は、取り外し可能な状態で記憶装置へ接続されるホスト装置を備える不揮発性記憶装置。
  17. 請求項8記載の方法において、
    前記実体は、取り外し可能な状態で記憶装置へ接続されるホスト装置を備える方法。
JP2009518355A 2006-07-07 2007-06-28 アイデンティティオブジェクトを使用する制御システムおよび方法 Expired - Fee Related JP4972165B2 (ja)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US81950706P 2006-07-07 2006-07-07
US60/819,507 2006-07-07
US11/557,041 2006-11-06
US11/557,039 US20080010458A1 (en) 2006-07-07 2006-11-06 Control System Using Identity Objects
US11/557,039 2006-11-06
US11/557,041 US8639939B2 (en) 2006-07-07 2006-11-06 Control method using identity objects
PCT/US2007/015430 WO2008008243A2 (en) 2006-07-07 2007-06-28 Control system and method using identity objects

Publications (3)

Publication Number Publication Date
JP2009543210A JP2009543210A (ja) 2009-12-03
JP2009543210A5 true JP2009543210A5 (ja) 2012-04-12
JP4972165B2 JP4972165B2 (ja) 2012-07-11

Family

ID=38728800

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009518355A Expired - Fee Related JP4972165B2 (ja) 2006-07-07 2007-06-28 アイデンティティオブジェクトを使用する制御システムおよび方法

Country Status (5)

Country Link
EP (1) EP2038799A2 (ja)
JP (1) JP4972165B2 (ja)
KR (1) KR20090034332A (ja)
TW (1) TW200822669A (ja)
WO (1) WO2008008243A2 (ja)

Families Citing this family (4)

* 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
FR2954656B1 (fr) 2009-12-23 2016-01-08 Oberthur Technologies Dispositif electronique portable et procede associe de mise a disposition d'informations
JP2016019120A (ja) * 2014-07-08 2016-02-01 日本電気通信システム株式会社 復号装置、通信システム、復号方法、および、プログラム
CN112738643B (zh) * 2020-12-24 2022-09-23 北京睿芯高通量科技有限公司 一种使用动态密钥实现监控视频安全传输的系统及方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3012407B2 (ja) * 1992-08-31 2000-02-21 日本電気アイシーマイコンシステム株式会社 レベル変換回路
US5473692A (en) * 1994-09-07 1995-12-05 Intel Corporation Roving software license for a hardware agent
US5778071A (en) * 1994-07-12 1998-07-07 Information Resource Engineering, Inc. Pocket encrypting and authenticating communications device
US6584495B1 (en) * 1998-01-30 2003-06-24 Microsoft Corporation Unshared scratch space
US6779113B1 (en) * 1999-11-05 2004-08-17 Microsoft Corporation Integrated circuit card with situation dependent identity authentication
CN100583117C (zh) * 2004-12-21 2010-01-20 桑迪士克股份有限公司 具有分区的通用内容控制方法

Similar Documents

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