WO2002076012A1

WO2002076012A1 - Systeme de controle d'acces a la memoire et procede de gestion faisant appel a un ticket de controle d'acces

Info

Publication number: WO2002076012A1
Application number: PCT/JP2002/002112
Authority: WO
Inventors: Kenji Yoshino; Yoshihito Ishibashi; Taizo Shirai; Masayuki Takada
Original assignee: Sony Corporation
Priority date: 2001-03-15
Filing date: 2002-03-07
Publication date: 2002-09-26
Also published as: EP1276271A4; JP2002278838A; HK1063115A1; EP1276271A1; US20030149854A1; CN1465161A; KR100874061B1; CN100449507C; KR20030001498A; US7225341B2

Description

アクセス制御チケットを用いたメモリアクセス制御システムおよび管理方

法メモリアクセス制御システム、デバイス管理装置、パーティション管理装置、メモリ搭載デバイス、およびメモリアクセス制御方法、並びにプログラム記憶媒体技術分野

本発明は、メモリアクセス制御システム、デバイス管理装置、パーティション管理装置、メモリ搭載デバイス、およびメモリアクセス制御方法、並びにプログラム記憶媒体に関する。さらに、詳細には、 1つのメモリを複数の領域（パ一テイシヨン）に区分けし、各パーティション内にサービス提供者あるいは関係ェンティティの管理するデ一夕を格納して、ユーザが 1つのメモリ搭載デバイスを用いて様々なサ一ビスに供用することを可能としたメモリアクセス制御システム、デバイス管理装置、パーティション管理装置、メモリ搭載デバイス、およびメモリアクセス制御方法、並びにプログラム記憶媒体に関する。背景技術

従来、メモリを保有するデバイスとしては、テープメディア、フロッピ一ディスク、ハードディスク、光ディスク、半導体メディア等が利用されてきた。このうち、デバイス内のメモリをセキュアに管理できるものとして半導体メディァが注目されてきている。その理由は、半導体メモリは外部から容易にアクセスさせない構造、すなわち耐タンパ構造を実現しやすいからである。

耐タンパ構造は、例えばデバイスを半導体によるシングルチップ構成とし、該チップに制御部、メモリコントローラ、不揮発性メモリ、電圧検出手段、周波数検出手段等を備え、不揮発性メモリを外部から容易に読み書きができないようにアルミ層のようなダミー層に挟まれた構成とすることによって実現される。このようなセキュアデバイスの従来のメモリ構造について図 9 6 「従来のメモリ構造」を用いて説明する。図 9 6のメモリは、例えば電子マネ一として利用可能なメモリ構成を示している。図 9 6に示すように、メモリ領域は大きく 3つに別れている。すなわち、データ領域、メモリ管理領域、システム領域である。データ領域には各データ内の先頭に格納された「データ構造」に基づくデータが格納されており、この例では、利用者名前、住所、電話番号、金額、メモ、口グの各データが格納される。メモリ管理領域には、データ領域の各データにァクセスするための格納アドレス、アクセス方法、アクセス認証鍵等が格納されている。例えば、データ領域のデータ 1 (利用者名前）のアクセスは読み出し（R e a d ) のみが、アクセス認証鍵（0123……）の利用によって可能となることが示されている。また、システム領域には、デバイス識別子（ I D )、データ領域にメモリ領域を確保するための認証鍵であるメモリ管理鍵等が格納される。

図 9 6に示すメモリデバイスのデータ領域は複数に分割可能であり、これらの分割データ領域を、異なるサービス主体、例えば電子マネ一であればそれそれ別の電子マネーサービス提供主体（e x . 異なる銀行）が管理する構成とすることができる。各分割領域のデータは、個々のサービス提供主体の他、利用者、例えば電子マネーを利用した商品販売を行なう店舗に備えられたデバイスアクセス機器としてのリーダライタ（専用リーダライタまたは P Cなど）によりデータの読み出し、書き込み、（e x . 残金データの更新）が実行される。

図 9 6に示すような複数の分割されたデータ領域を持つセキュアデバイスの管理者と利用者の関係を図 9 7 「メモリ管理者 ·利用者」に示す。図 9 7に示すように、セキュアデバイスの発行主体であるメモリ管理者と、このメモリ管理者からメモリ領域を割り当ててもらい、その割り当てられたメモリを利用するメモリ利用者がいる。メモリ利用者としてデ一夕 1利用者〜データ 6利用者がいる。メモリ利用者とは例えば前述の電子マネ一の例によれば、銀行または店舗等である。メモリ管理者は、メモリ領域を確保するためのアクセスコントロ一ル用のメモリ管理鍵を知っており、このメモリ管理鍵を利用して、それそれのメモリ利用者のメモリ（分割データ領域）を割り当てる。また、メモリ利用者は各データ領域のデータにアクセスするためのアクセス認証鍵を知っており、このアクセス認証鍵を利用して、それそれ割り当てられたデータ領域内のメモリにアクセスすることができる。アクセスの態様としてはデータの読み出し（R e a d )、書き込み（W r i t e ), 残金の減額（D e c r e m e n t ) など、様々であり、それぞれの処理態様に応じてアクセス認証鍵を個別に設定して個別の処理の可否を設定することができる。

例えば図 96に示すメモリ中のデータ 4は、金額データであり、図 97に示すようにデータ 4の利用者はデータ 4に対して減額（D e c r eme nt) の処理と、読書き（R e a d/Wr i t e ) の処理が可能である。図 9 6の右下の表に示すように、データ 4の減額（D e c r eme nt ) の処理と、読書き（Re a d/Wr i t e ) の処理では、アクセスキーが異なり、各処理に対応したァクセスキーを使用してメモリにアクセスすることが必要となる。

図 98に、メモリ管理者がメモリ利用者に対してメモリデバイス内のあるデ一夕領域を割り当てるメモリ確保処理を説明する図を示す。図 98の「メモリの確保の方式」に示すように、メモリ管理者は、図の左側に示すメモリ確保用リーダ /ライタ（R/W： Reader/Writer) を用いて図の右側に示すメモリデバイスに対するデ一夕領域の確保処理を実行する。メモリ確保用リーダ/ライタ（R/W： Reader/Writer) には、メモリ管理鍵を保持するためのセキュアな N V R A M (Non-Volatile RAM) が備えられている。なお、メモリ確保用 RZWとしては、セキュアデバイスの専用の読み書き R/Wであっても、またセキュアデバイスが USB、 P CMC I Aなどの I /Fを持つデパイスである場合、これらのイン夕フェースを介して読み書き可能な装置例えば P Cであってもよい。

R/Wを用いてメモリを確保するためには、まずセキュアデバイスからデバイス I Dを読み出す。次に R/W内において、メモリ管理鍵とデバイス I Dを用いて認証鍵を生成し、生成した認証鍵を用いてセキュアデバイスと相互認証を実行する。相互認証処理は例えば共通鍵方式による相互認証（ex.IS0/IEC9798-2) に従って実行される。

相互認証に成功した後、 R/Wはデータ構造、データサイズ、アクセス方法、アクセス認証鍵をセッション鍵で暗号化し、必要に応じてデータ検証用の MA C (Message Authentication Code) 値を付加してセキュアデバイスにコマンドを送る。コマンドを受信したセキュアデバイスは、受信データを復号し、必要に応じてデータ改竄性の検証を MA C検証処理によって実行し、その後、受信データ内のデータサイズに応じてメモリのデ一夕領域にメモリ領域を確保し、確保した領域にデータ構造を書き込むとともに、メモリ管理領域に確保したメモリのァドレス、アクセス方法、アクセス認証鍵を書き込む。

このようにして、メモリデバイスには複数の分割データ領域が設定される。次に、図 9 9の「メモリアクセス方法」に従って、複数の分割データ領域を持つメモリデバイスに対するメモリアクセス方法について説明する。図 9 9の左側のリ —ダライタは、メモリ利用者の有するメモリアクセス用リーダライタ（R /W ) であり、上述のメモリ確保用 R /Wと同様、専用 R /Wあるいは P Cなどで構成される。メモリアクセス用リーダライタ（R /W ) には、アクセス認証鍵を保持するためのセキュアな N V R A Mが備えられている。 R /Wを用いてセキュアデバイスのデ一夕領域にアクセスするためには、まずセキユアデバィスからデバイス I Dを読み出す。次に R /W内において、アクセス認証鍵とデバイス I Dを用いて認証鍵を生成し、生成した認証鍵を用いてセキュアデバイスと相互認証を実行する。相互認証に成功した後、 R /Wはアクセス認証鍵に対応するデ一夕領域のデータに所定のアクセスを行なう。

このときメモリ管理領域にはアクセス方法が規定されているため、例えば、図 9 9の「メモリアクセス方法 j に示すように、データ 4 (金額データ）の減額 (Decrement)用のアクセス認証に成功した場合は、データ 4のデータの減額は可能であっても、加算、あるいは自由な書き換え処理はできない。このように認証処理に用いるアクセス認証鍵をそれそれのアクセス態様に応じて異なる設定とすることにより各データの安全性を高めることができる。例えば減額処理用 R /W が盗難にあい、盗難にあった減額処理用 R /W内の N V R A Mが見破られた場合であっても、図 9 9のセキュアデパイス内のデータ 4 (金額デ一夕）の不正な増加処理が行われる可能性を低減することができる。

一般に入金端末は A T Mと同様、セキュリティを高めることができるが、出金端末は店舗等で商品引き渡しの際の代金回収機として利用されることが多く、設置場所も様々であり、端末の盗難のリスクも高くセキュリティの度合いを高めることが困難である。従って、デ一夕アクセスに対してアクセス認証鍵を異ならせる構成が有効となる。

上述した従来の分割データ領域を持つメモリデバイスの利用形態において、メモリのデ一夕領域の確保処理、各データ領域のアクセス処理において、それそれ、メモリ管理鍵を用いた認証処理、あるいはアクセス認証鍵を用いた認証処理を実行することによりそれそれの処理を実行する構成としているが、これらは具体的には、例えば D E S暗号アルゴリズムによる共通鍵を適用する構成であり、公開鍵方式による認証、あるいは公開鍵方式による検証を想定したものとはなっていない。

上述のようにメモリ管理鍵、アクセス認証鍵に共通鍵を適用した構成では認証およびアクセス許諾が一処理で実行されるという利点はあるが、認証鍵の漏洩により、漏洩鍵によるメモリアクセスが可能となってしまうという欠点があり、セキュリティ上問題となる。

また、メモリデバイスに対するアクセスを実行するリ一ダライタ（R /W ) の低コスト化を実現するために、リーダライタ（R ZW) に暗号アルゴリズムを実装しない構成も想定されるが、このような構成とすれば、デパイス間との認証、通信データの暗号化の一切の処理が実行できず、ユーザの金額データ、その他ュ —ザのプライべ一ト情報などを保持するデバイスに対するリ一ダライタとしては不適である。発明の開示

本発明は、上述のような、従来技術の現状に鑑みてなされたものであり、複数のパーティションに分割されたメモリ領域のアクセスに対して、様々な種類のァクセス制御チケットを各デパイスまたはパーティション管理エンティティの管理の下に発行し、各チケットに記述されたルールに基づく処理をメモリ搭載デバィスにおいて実行する構成とすることにより、各パーティション内データの独立した管理構成を実現することを目的とする。

また、パーティション対応の認証、デバイス対象の認証を公開鍵、共通鍵のいずれか指定方式に従って実行することを可能とし、様々な環境下においてセキュァなデータ通信を実行可能としたメモリアクセス制御システム、デバイス管理装置、パーティション管理装置、メモリ搭載デバイス、およびメモリアクセス制御方法、並びにプログラム記憶媒体を提供することを目的とする。

本発明の第 1の側面は、データファイルを格納したメモリ部を有するメモリ搭載デパイスに対するメモリアクセス制御システムであり

前記メモリ搭載デバイスのメモリ部は、

前記データファイルを格納し、パーティションマネージャによって管理されるメモリ領域としての 1以上のパーティション領域と、該メモリ搭載デバイスの管理者としてのデバイスマネージャによって管理されるデバイスマネージャ管理領域とを有し、

前記メモリ搭載デバイスは、

前記メモリ部に対するアクセス制御チケットとして、前記デバイスマネージャの管理するアクセス制御チケット、または前記パーティションマネージャの管理するアクセス制御チケットをアクセス機器から受領し、受領チケットの記述に応じて処理を実行する構成を有することを特徴とするメモリアクセス制御システムにめ o

さらに、本発明のメモリアクセス制御システムの一実施態様において、前記ァクセス制御チケットは、前記メモリ搭載デバイスとチケットを出力したアクセス機器間において実行すべき相互認証態様を指定した相互認証指定データを含み、前記メモリ搭載デバイスは、該アクセス制御チケットの相互認証指定データに応じた相互認証を実行し、認証の成立を条件として受領チケットの記録に応じた処理を実行する構成を有することを特徴とする。

さらに、本発明のメモリアクセス制御システムの一実施態様において、前記ァクセス制御チケットは、前記メモリ搭載デバイスの受領したアクセス制御チケットの検証態様を指定したチケット検証指定データを含み、前記メモリ搭載デバィスは、該アクセス制御チケットのチケット検証指定データに応じたチケット検証処理を実行し、検証の成立を条件として受領チケットの記録に応じた処理を実行する構成を有することを特徴とする。

さらに、本発明のメモリアクセス制御システムの一実施態様において、前記ァクセス制御チケットは、該アクセス制御チケットの発行手段のカテゴリまたは識別子を含み、前記メモリ搭載デバイスは、アクセス機器から受領したアクセス制御チケットに記述された該アクセス制御チケットの発行手段のカテゴリまたは識別子に基づいて、チケットが正当な発行手段により発行されたチケットであることの確認処理を実行し、該確認を条件として受領チケットの記録に応じた処理を実行する構成を有することを特徴とする。

さらに、本発明のメモリアクセス制御システムの一実施態様において、前記ァクセス制御チケットは、該アクセス制御チケットの利用手段であるアクセス機器のカテゴリまたは識別子を含み、前記メモリ搭載デバイスは、アクセス機器から受領したアクセス制御チケットに記述された該アクセス制御チケットの利用手段であるアクセス機器のカテゴリまたは識別子に基づいて、チケヅトが正当な利用手段により提供されたチケットであることの確認処理を実行し、該確認を条件として受領チケッ卜の記録に応じた処理を実行する構成を有することを特徴とする ₍ さらに、本発明のメモリアクセス制御システムの一実施態様において、前記デバイスマネージャの管理するアクセス制御チケットには、前記メモリ搭載デバィスのメモリ部に対するパーティションの生成処理または削除処理を許容するパ一テイシヨン登録チケット（P R T ) を含み、前記メモリ搭載デバイスは、前記ァクセス機器からパーティション登録チケット（P R T ) を受領した場合は、受領パーティション登録チケット（P R T ) の記録に従ったパーティションの生成処理または削除処理を実行することを特徴とする。

さらに、本発明のメモリアクセス制御システムの一実施態様において、前記パ —テイシヨン登録チケット（P R T ) は、前記デバイスマネージャの管理するチケット発行手段から前記パーティションマネージャの管理するチケヅトュ一ザとしてのアクセス機器に対して発行される構成であることを特徴とする。

さらに、本発明のメモリアクセス制御システムの一実施態様において、前記パ —ティションマネージャの管理するアクセス制御チケットには、前記メモリ搭載デバイスのメモリ部内に生成されたパ一ティシヨン内に対するデータファイルの生成処理または削除処理を許容するファイル登録チケット（F R T ) を含み、前記メモリ搭載デバイスは、前記アクセス機器からファイル登録チケッ卜（F R T ) を受領した場合は、受領ファイル登録チケット（F R T ) の記録に従ったフアイルの生成処理または削除処理を実行することを特徴とする。

さらに、本発明のメモリアクセス制御システムの一実施態様において、前記フアイル登録チケット（FRT) は、前記パーティションマネージャの管理するチケット発行手段から前記パーティションマネージャの管理するチケットユーザとしてのアクセス機器に対して発行される構成であることを特徴とする。

さらに、本発明のメモリアクセス制御システムの一実施態様において、前記パ —テイシヨンマネージャの管理するアクセス制御チケットには、前記メモリ搭載デパイスのメモリ部内のパーティション内のデータファイルに対するアクセスを許容するサービス許可チケット（S PT) を含み、前記メモリ搭載デパイスは、前記アクセス機器からサービス許可チケット（S PT) を受領した場合は、受領サービス許可チケット（S PT) の記録に従ったデータファイルに対するァクセス処理を実行することを特徴とする。

さらに、本発明のメモリアクセス制御システムの一実施態様において、前記サ —ビス許可チケット（S PT) は、前記パーティションマネージャの管理するチケヅト発行手段から前記パーティションマネージャの管理するチケヅトュ一ザとしてのアクセス機器に対して発行される構成であることを特徴とする。

さらに、本発明のメモリアクセス制御システムの一実施態様において、前記デバイスマネージャまたは前記パーティションマネージャの管理するアクセス制御チケットには、前記メモリ搭載デバイスのメモリ部内の格納データの更新処理を許容するデ一夕アップデートチケット（DUT) を含み、前記メモリ搭載デバィスは、前記アクセス機器からデータアップデートチケット（DUT) を受領した場合は、受領デ一夕アップデートチケット（DUT) の記録に従ったデ一タ更新処理を実行することを特徴とする。

さらに、本発明のメモリアクセス制御システムの一実施態様において、前記デバイスマネージャの管理するデバイスマネージャ管理領域のデータ更新用のデ一夕アップデートチケット（DUT) は、前記デバイスマネージャの管理するチケット発行手段から前記デパイスマネージャの管理するチケットユーザとしてのァクセス機器に対して発行され、前記パーティシヨンマネージャの管理するパ一テイシヨン領域のデ一夕更新用のデ一夕アップデートチケット（DUT) は、前記パーティションマネージャの管理するチケヅト発行手段から前記パーティションマネージャの管理するチケットュ一ザとしてのアクセス機器に対して発行される構成であることを特徴とする。

さらに、本発明の第 2の側面は、

データファイルを格納し、パーティシヨン管理装置によって管理されるメモリ領域としての 1以上のパーティシヨン領域と、デバイス管理装置によって管理されるデバイスマネージャ管理領域とを有するメモリ搭載デバイスのデバイス管理を実行するデバイス管理装置であり、

前記メモリ搭載デバイスのメモリ部に対するパーティションの生成処理または削除処理を許容するメモリアクセス制御チケットとしてのパーティション登録チケット（P R T ) 発行手段を有することを特徴とするデバイス管理装置にある。さらに、本発明のデバイス管理装置の一実施態様において、前記メモリ搭載デバイスに対する公開鍵証明書の発行管理を実行する登録局構成を有することを特徴とする。

さらに、本発明のデバイス管理装置の一実施態様において、前記パーティション登録チケット（P R T ) は、前記メモリ搭載デバイスとチケットを出力したァクセス機器間において実行すべき相互認証態様を指定した相互認証指定データを含むことを特徴とする。

さらに、本発明のデバイス管理装置の一実施態様において、前記パーティション登録チケット（P R T ) は、前記メモリ搭載デバイスの受領したアクセス制御チケットの検証態様を指定したチケット検証指定デ一夕を含むことを特徴とする < さらに、本発明のデバイス管理装置の一実施態様において、前記パーティション登録チケット（P R T ) は、該アクセス制御チケットの発行手段のカテゴリまたは識別子を含むことを特徴とする。

さらに、本発明のデバイス管理装置の一実施態様において、前記パーティション登録チケット（P R T ) は、該アクセス制御チケットの利用手段であるァクセス機器のカテゴリまたは識別子を含むことを特徴とする。

さらに、本発明の第 3の側面は、

データファイルを格納し、パーティション管理装置によって管理されるメモリ領域としての 1以上のパーティション領域と、デバイス管理装置によって管理されるデパイスマネージャ管理領域とを有するメモリ搭載デバイスのパーティション管理を実行するパーティション管理装置であり、

前記メモリ搭載デバイスのメモリ部に対して生成されたパーティション内に対するアクセスを許容するアクセス制御チケット発行手段を有することを特徴とするパーティション管理装置にある。

さらに、本発明のパーティション管理装置の一実施態様において、前記ァクセス制御チケットは、前記メモリ搭載デバイスのメモリ部内に生成されたパーティション内に対するデ一夕ファイルの生成処理または削除処理を許容するファイル登録チケット（F R T ) であることを特徴とする。

さらに、本発明のパーティション管理装置の一実施態様において、前記ァクセス制御チケットは、前記メモリ搭載デバイスのメモリ部内のパーティション内のデ一夕ファイルに対するアクセスを許容するサービス許可チケット（S P T ) であることを特徴とする。

さらに、本発明のパーティション管理装置の一実施態様において、前記パ一ティシヨン管理装置は、前記メモリ搭載デバイスに対する公開鍵証明書の発行管理を実行する登録局構成を有することを特徴とする。

さらに、本発明のパーティション管理装置の一実施態様において、前記ァクセス制御チケットは、前記メモリ搭載デパイスとチケットを出力したアクセス機器間において実行すべき相互認証態様を指定した相互認証指定データを含むことを特徴とする。

さらに、本発明のパーティション管理装置の一実施態様において、前記ァクセス制御チケットは、前記メモリ搭載デパイスの受領したアクセス制御チケットの検証態様を指定したチケット検証指定データを含むことを特徴とする。

さらに、本発明のパーティション管理装置の一実施態様において、前記ァクセス制御チケットは、該アクセス制御チケットの発行手段のカテゴリまたは識別子を含むことを特徴とする。

さらに、本発明のパーティション管理装置の一実施態様において、前記ァクセス制御チケヅトは、該アクセス制御チケットの利用手段であるアクセス機器の力テゴリまたは識別子を含むことを特徴とする。

さらに、本発明の第 4の側面は、データ格納可能なメモリ部を有するメモリ搭載デバイスであり、

前記メモリ搭載デバイスのメモリ部は、

パ一ティションマネージャによって管理されるメモリ領域としての 1以上のパ一ティション領域と、該メモリ搭載デバイスの管理者としてのデバイスマネージャによって管理されるデバイスマネージャ管理領域とを有し、

前記メモリ搭載デバイスは、

前記メモリ部に対するアクセス制御チケットとして、前記デバイスマネージャの管理するアクセス制御チケット、または前記パーティションマネージャの管理するアクセス制御チケットをアクセス機器から受領し、受領チケットの記述に応じて処理を実行する制御手段を有することを特徴とするメモリ搭載デバイスにある。

さらに、本発明のメモリ搭載デバイスの一実施態様において、前記アクセス制御チケットは、前記メモリ搭載デバイスとチケットを出力したアクセス機器間において実行すべき相互認証態様を指定した相互認証指定データを含み、前記制御手段は、該アクセス制御チケットの相互認証指定データに応じた相互認証を実行し、認証の成立を条件として受領チケットの記録に応じた処理を実行する構成を有することを特徴とする。

さらに、本発明のメモリ搭載デバイスの一実施態様において、前記アクセス制御チケットは、前記メモリ搭載デバイスの受領したアクセス制御チケットの検証態様を指定したチケット検証指定デ一夕を含み、前記制御手段は、該アクセス制御チケットのチケット検証指定データに応じたチケット検証処理を実行し、検証の成立を条件として受領チケットの記録に応じた処理を実行する構成を有することを特徴とする。

さらに、本発明のメモリ搭載デバイスの一実施態様において、前記アクセス制御チケットは、該アクセス制御チケットの発行手段のカテゴリまたは識別子を含み、前記制御手段は、アクセス機器から受領したアクセス制御チケットに記述された該アクセス制御チケットの発行手段のカテゴリまたは識別子に基づいて、チケットが正当な発行手段により発行されたチケットであることの確認処理を実行し、該確認を条件として受領チケットの記録に応じた処理を実行する構成を有することを特徴とする。，

さらに、本発明のメモリ搭載デバイスの一実施態様において、前記アクセス制御チケヅトは、該アクセス制御チケヅトの利用手段であるアクセス機器のカテゴリまたは識別子を含み、前記制御手段は、アクセス機器から受領したアクセス制御チケットに記述された該アクセス制御チケットの利用手段であるアクセス機器のカテゴリまたは識別子に基づいて、チケットが正当な利用手段により提供されたチケットであることの確認処理を実行し、該確認を条件として受領チケットの記録に応じた処理を実行する構成を有することを特徴とする。

さらに、本発明の第 5の側面は、

データファイルを格納したメモリ部を有するメモリ搭載デバイスに対するメモリアクセス制御方法であり

前記メモリ搭載デバイスのメモリ部は、

前記メモリ搭載デバイスは、

前記メモリ部に対するアクセス制御チケッ卜として、前記デバイスマネージャの管理するアクセス制御チケット、または前記パーティションマネージャの管理するアクセス制御チケットをアクセス機器から受領し、受領チケットの記述に応じて処理を実行することを特徴とするメモリアクセス制御方法にある。

さらに、本発明のメモリアクセス制御方法の一実施態様において、前記ァクセス制御チケットは、前記メモリ搭載デバイスとチケットを出力したアクセス機器間において実行すべき相互認証態様を指定した相互認証指定デ一夕を含み、前記メモリ搭載デバイスは、該アクセス制御チケットの相互認証指定データに応じた相互認証を実行し、認証の成立を条件として受領チケットの記録に応じた処理を実行することを特徴とする。

さらに、本発明のメモリアクセス制御方法の一実施態様において、前記ァクセス制御チケットは、前記メモリ搭載デバイスの受領したアクセス制御チケットの検証態様を指定したチケット検証指定データを含み、前記メモリ搭載デバイスは、該アクセス制御チケットのチケット検証指定データに応じたチケット検証処理を実行し、検証の成立を条件として受領チケットの記録に応じた処理を実行することを特徴とする。

さらに、本発明のメモリアクセス制御方法の一実施態様において、前記ァクセス制御チケットは、該アクセス制御チケットの発行手段のカテゴリまたは識別子を含み、前記メモリ搭載デバイスは、アクセス機器から受領したアクセス制御チケットに記述された該アクセス制御チケットの発行手段のカテゴリまたは識別子に基づいて、チケットが正当な発行手段により発行されたチケットであることの確認処理を実行し、該確認を条件として受領チケットの記録に応じた処理を実行することを特徴とする。

さらに、本発明のメモリアクセス制御方法の一実施態様において、前記ァクセス制御チケヅトは、該アクセス制御チケットの利用手段であるアクセス機器の力テゴリまたは識別子を含み、前記メモリ搭載デバイスは、アクセス機器から受領したアクセス制御チケットに記述された該アクセス制御チケットの利用手段であるアクセス機器のカテゴリまたは識別子に基づいて、チケットが正当な利用手段により提供されたチケットであることの確認処理を実行し、該確認を条件として受領チケットの記録に応じた処理を実行することを特徴とする。

さらに、本発明のメモリアクセス制御方法の一実施態様において、前記デバィスマネージャの管理するアクセス制御チケットには、前記メモリ搭載デバイスのメモリ部に対するパーティションの生成処理または削除処理を許容するパ一ティシヨン登録チケット（P R T ) を含み、前記メモリ搭載デバイスは、前記ァクセス機器からパーティション登録チケット（P R T ) を受領した場合は、受領パーティション登録チケット（P R T ) の記録に従ったパーティションの生成処理または削除処理を実行することを特徴とする。

さらに、本発明のメモリアクセス制御方法の一実施態様において、前記パ一テイシヨン登録チケット（P R T ) は、前記デバイスマネージャの管理するチケット発行手段から前記パ一テイションマネージャの管理するチケットユーザとしてのアクセス機器に対して発行されることを特徴とする。さらに、本発明のメモリアクセス制御方法の一実施態様において、前記パ一ティシヨンマネージャの管理するアクセス制御チケットには、前記メモリ搭載デパイスのメモリ部内に生成されたパ一テイション内に対するデータファイルの生成処理または削除処理を許容するファイル登録チケット（FRT) を含み、前記メモリ搭載デバイスは、前記アクセス機器からファイル登録チケット（FRT) を受領した場合は、受領ファイル登録チケット（FRT) の記録に従ったファイルの生成処理または削除処理を実行することを特徴とする。

さらに、本発明のメモリアクセス制御方法の一実施態様において、前記フアイル登録チケット（FRT) は、前記パーティションマネージャの管理するチケット発行手段から前記パーティションマネージャの管理するチケットユーザとしてのアクセス機器に対して発行される構成であることを特徴とする。

さらに、本発明のメモリアクセス制御方法の一実施態様において、前記パ一ティシヨンマネージャの管理するアクセス制御チケヅトには、前記メモリ搭載デバイスのメモリ部内のパーティション内のデータファイルに対するアクセスを許容するサービス許可チケット（S PT) を含み、前記メモリ搭載デバイスは、前記アクセス機器からサービス許可チケット（S P T) を受領した場合は、受領サ一ビス許可チケット（S PT) の記録に従ったデータファイルに対するアクセス処理を実行することを特徴とする。

さらに、本発明のメモリアクセス制御方法の一実施態様において、前記サ一ビス許可チケット（SPT) は、前記パーティションマネージャの管理するチケヅト発行手段から前記パ一ティシヨンマネージャの管理するチケットュ一ザとしてのアクセス機器に対して発行されることを特徴とする。

さらに、本発明のメモリアクセス制御方法の一実施態様において、前記デバィスマネージャまたは前記パーティションマネージャの管理するアクセス制御チケットには、前記メモリ搭載デバイスのメモリ部内の格納データの更新処理を許容するデ一夕アツブデ一トチケット（D UT) を含み、前記メモリ搭載デバイスは、前記アクセス機器からデータアップデートチケット（DUT)を受領した場合は、受領デ一夕アップデートチケット（DUT) の記録に従ったデータ更新処理を実行することを特徴とする。さらに、本発明のメモリアクセス制御方法の一実施態様において、前記デバィスマネージャの管理するデバイスマネージャ管理領域のデータ更新用のデータァップデートチケット（D U T ) は、前記デバイスマネージャの管理するチケット発行手段から前記デバイスマネージャの管理するチケットュ一ザとしてのァクセス機器に対して発行され、前記パーティションマネージャの管理するパーティシヨン領域のデータ更新用のデ一夕アップデートチケット（D U T ) は、前記パ一ティションマネージャの管理するチケット発行手段から前記パーティシヨンマネ —ジャの管理するチケヅトユーザとしてのアクセス機器に対して発行されることを特徴とする。

さらに、本発明の第 6の側面は、

データファイルを格納し、パ一ティションマネ一ジャによって管理されるメモリ領域としての 1以上のパーティション領域と、該メモリ搭載デバイスの管理者としてのデバイスマネージャによって管理されるデバイスマネージャ管理領域とを有するメモリ部を有するメモリ搭載デバイスに対するメモリアクセス制御処理をコンピュータ · システム上で実行せしめるコンピュータ · プログラムを提供するプログラム記憶媒体であって、前記コンピュータ · プログラムは、

前記メモリ部に対するアクセス制御チケットとして、前記デバイスマネージャの管理するアクセス制御チケット、または前記パーティションマネージャの管理するアクセス制御チケットをアクセス機器から受領するステップと、

アクセス機器との相互認証を実行するステップと、

受領チケットの記述に応じたチケット検証処理を実行するステップと、受領チケットの記述に応じた処理を実行するステップと、

を有することを特徴とするプログラム記憶媒体にある。

なお、本発明のプログラム記憶媒体は、例えば、様々なプログラム ·コードを実行可能な汎用コンピュータ 'システムに対して、コンピュータ 'プログラムをコンピュー夕可読な形式で提供する媒体である。媒体は、 C D F D、 M Oなどの記録媒体、通信可能媒体など、その形態は特に限定されない。

このようなプログラム記憶媒体は、コンピュータ · システム上で所定のコンビュ―タ . プログラムの機能を実現するための、コンピュータ · プログラムと記憶媒体との構造上又は機能上の協働的関係を定義したものである。換言すれば、該記憶媒体を介してコンピュータ · プログラムをコンピュータ · システムにインストールすることによって、コンピュータ ·システム上では協働的作用が発揮され、本発明の他の側面と同様の作用効果を得ることができるのである。

本発明のさらに他の目的、特徴や利点は、後述する本発明の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。図面の簡単な説明

図 1は、本発明のシステム構成の概要を説明するシステム構成概略図（その 1) である。

図 2は、本発明のシステム構成の概要を説明するシステム構成概略図（その 2 ) である。

図 3は、本発明のシステム構成の具体例を説明するシステム構成概略図（その 3 ) である。

図 4は、本発明のシステムにおけるアクセス制御チケットの発行手段および利用手段との関係を説明する図である。

図 5は、本発明のシステムにおけるメモリ部を有するデバイス構成を示す図である。

図 6は、本発明のデバイスのメモリフォ一マットを示す図である。

図 7は、本発明のシステムにおけるデバイスマネージャ構成を示す図である。図 8は、本発明のシステムにおけるデバイスマネージャの制御手段構成を示す図である。

図 9は、本発明のシステムにおけるパーティションマネージャ構成を示す図である。

図 1 0は、本発明のシステムにおけるリーダライタ（R /W ) 構成を示す図である。

図 1 1は、本発明のシステムにおいて利用可能な公開鍵証明書のフォーマットを説明する図である。

図 1 2は、本発明のシステムにおいて利用可能な公開鍵方式の署名生成処理フ口一を示す図である。

図 1 3は、本発明のシステムにおいて利用可能な公開鍵方式の署名検証処理フ口一を示す図である。

図 1 4は、本発明のデバイスにおけるメモリ部に格納されるデータ中の製造情報プロックのデータ構成を示す図である。

図 1 5は、本発明のデバイスにおけるメモリ部に格納されるデータ中のデバイス管理情報プロックのデータ構成を示す図である。

図 1 6は、本発明のデバイスにおけるメモリ部に格納されるデ一夕中の公開鍵系デバイス鍵定義プロックのデータ構成を示す図である。

図 1 7は、本発明のデバイスにおけるメモリ部に格納されるデータ中の共通鍵系デバイス鍵定義プロックのデータ構成を示す図である。

図 1 8は、本発明のデバイスにおけるメモリ部に格納されるデータ中のデバィス鍵領域のデ一夕構成を示す図である。 .

図 1 9は、本発明のデバイスにおけるメモリ部に格納されるデ一夕中のパーテイション定義プロックのデータ構成を示す図である。

図 2 0は、本発明のデバイスにおけるメモリ部に格納されるデータ中のパ一ティシヨン管理情報プロックのデータ構成を示す図である。

図 2 1は、本発明のデバイスにおけるメモリ部に格納されるデータ中の公開鍵系パーティション鍵定義プロックのデ一夕構成を示す図である。

図 2 2は、本発明のデバイスにおけるメモリ部に格納されるデータ中の共通鍵系パーティション鍵定義プロックのデータ構成を示す図である。

図 2 3は、本発明のデバイスにおけるメモリ部に格納されるデータ中のパ一テイシヨン鍵領域のデータ構成を示す図である。

図 2 4は、本発明のデバイスにおけるメモリ部に格納されるデ一夕中のフアイル定義プロックのデータ構成を示す図である。

図 2 5は、本発明のデバイスにおけるメモリ部に格納されるデ一夕中のフアイルの構造のタイプについて説明する図である。図 26は、本発明のシステムにおいて適用されるアクセス制御チケットとしてのパ一ティション登録チケット（PRT) のフォーマットを示す図である。図 27は、本発明のシステムにおいて適用されるアクセス制御チケットとしてのファイル登録チケット（FRT) のフォーマットを示す図である。

図 28は、本発明のシステムにおいて適用されるアクセス制御チケットとしてのサービス許可チケット（S PT) のフォーマット（例 1 ) を示す図である。図 29は、本発明のシステムにおいて適用されるアクセス制御チケットとしてのサ一ビス許可チケット（S PT) を利用したファイルアクセスのモードの種別を説明する図である。

図 30は、本発明のシステムにおいて適用されるアクセス制御チケットとしてのサービス許可チケット（S PT) を利用したアクセス対象となるファイル構造を説明する図である。

図 3 1は、本発明のシステムにおいて適用されるアクセス制御チケットとしてのサービス許可チケット（S PT) のフォーマット（例 2 ) を示す図である。図 32は、本発明のシステムにおいて適用されるアクセス制御チケットとしてのデ一夕アツプデ一トチケット（DUT) のフォーマットを示す図である。図 33は、本発明のシステムにおいて適用されるアクセス制御チケットとしてのデ一夕アップデートチケット（DUT) を利用した更新対象となるデ一夕を説明する図である。

図 34は、本発明のシステムにおけるデバイス利用までの処理概略を説明する図である。

図 35は、本発明のシステムにおけるデバイス製造エンティティによるデパイスの初期登録処理フローを示す図である。

図 36は、本発明のシステムにおけるデバイスマネージャによるデバイスの初期登録処理フロー（その 1) を示す図である。

図 37は、本発明のシステムにおけるデバイスマネージャによるデバイスの初期登録処理フロー（その 2) を示す図である。

図 38は、本発明のシステムにおけるデバイスマネージャによるデバイスの初期登録処理フロー（その 3 ) を示す図である。図 3 9は、本発明のシステムにおけるデバイスマネージャによるデパイスの初期登録処理フロー（その 4 ) を示す図である。

図 4 0は、本発明のシステムにおけるデバイスマネージャによるデパイスの初期登録処理フロー（その 5 ) を示す図である。

図 4 1は、本発明のシステムにおけるデバイスマネージャによるデバイスの初期登録処理の後のデバイスの格納データを説明する図である。

図 4 2は、本発明のシステムにおけるデパイスマネージャによる公開鍵証明書発行処理フロ一（その 1 ) を示す図である。

図 4 3は、本発明のシステムにおけるデバイスマネージャによる公開鍵証明書発行処理フロー（その 2 ) を示す図である。

図 4 4は、本発明のシステムにおけるデバイスマネージャによる公開鍵証明書発行処理を説明する図である。

図 4 5は、本発明のシステムにおけるデバイスマネージャによる公開鍵証明書発行処理を説明する図である。

図 4 6は、本発明のシステムにおけるデバイスマネージャによる公開鍵証明書発行処理後のデバイスの格納データを説明する図である。

図 4 7は、本発明のシステムにおけるデバイスに対するパ一ティション生成、削除処理フローを示す図である。

図 4 8は、本発明のシステムにおけるデパイスとの相互認証処理について説明するフロー（その 1 ) である。

図 4 9は、本発明のシステムにおけるデバイスとの相互認証処理（デバイス認証）について説明するフロー（その 2 ) である。

図 5 0は、本発明のシステムにおけるデバイスとの公開鍵方式の相互認証処理について説明する図である。

図 5 1は、本発明のシステムにおけるデバイスとの相互認証処理後にデバイスに生成される認証テ一ブルの構成を説明する図である。

図 5 2は、本発明のシステムにおけるデバイスとの相互認証処理後にリ一ダラィタに生成される認証テーブルの構成を説明する図である。

図 5 3は、本発明のシステムにおけるデバイスとの共通鍵方式の相互認証処理について説明する図である。

図 5 4は、本発明のシステムにおけるデバイスとの共通鍵方式の相互認証処理について説明する図である。

図 5 5は、本発明のシステムにおけるデバイスとの相互認証処理（パーティシヨン認証）について説明するフロー（その 3 ) である。

図 5 6は、本発明のシステムにおけるデバイスとの相互認証処理（パーティシヨン認証）について説明するフロー（その 4 ) である。

図 5 7は、本発明のシステムにおけるチケットの正当性、利用者チェック処理について説明するフロー（その 1 ) である。

図 5 8は、本発明のシステムにおけるチケットの正当性、利用者チヱック処理について説明するフロー（その 2 ) である。

図 5 9は、本発明のシステムにおけるチケットの正当性で適用可能な M A C生成方式について説明するフロー（その 1 ) である。

図 6 0は、本発明のシステムにおけるパーティションの作成、削除操作について説明するフロー（その 1 ) である。

図 6 1は、本発明のシステムにおけるパーティションの作成、削除操作について説明するフロー（その 2 ) である。

図 6 2は、本発明のシステムにおけるパ一テイションの初期登録処理について説明するフロー（その 1 ) である。

図 6 3は、本発明のシステムにおけるパーティションの初期登録処理について説明するフロー（その 2 ) である。

図 6 4は、本発明のシステムにおけるパ一テイションの初期登録処理について説明するフロー（その 3 ) である。

図 6 5は、本発明のシステムにおけるパ一テイションの初期登録処理後のデバイス格納データについて説明する図である。

図 6 6は、本発明のシステムにおけるパーティションマネージャによる公開鍵証明書発行処理を説明する図（その 1 ) である。

図 6 7は、本発明のシステムにおけるパ一ティションマネージャによる公開鍵証明書発行処理を説明する図（その 2 ) である。図 68は、本発明のシステムにおけるパーティションマネージャによるパ一テイシヨン生成処理において、公開鍵方式認証、公開鍵方式チケット検証を実行した場合の処理を説明する図である。

図 69は、本発明のシステムにおけるパ一ティションマネージャによるパ一テイシヨン生成処理において、公開鍵方式認証、共通鍵方式チケット検証を実行した場合の処理を説明する図である。

図 70は、本発明のシステムにおけるパ一ティションマネージャによるパ一テイシヨン生成処理において、共通鍵方式認証、共通鍵方式チケット検証を実行した場合の処理を説明する図である。

図 7 1は、本発明のシステムにおけるパーティションマネージャによるパ一テイシヨン生成処理において、共通鍵方式認証、公開鍵方式チケット検証を実行した場合の処理を説明する図である。

図 72は、本発明のシステムにおけるファイル登録チケット（FRT) を適用したファイル生成消去処理について説明するフロー図である。

図 73は、本発明のシステムにおけるファイル登録チケット（FRT) を適用したファイル生成削除操作について説明するフロー図である。

図 74は、本発明のシステムにおけるファイル登録チケット（FRT) を適用したファイル生成後のデバィス格納デ一夕を説明する図である。

図 75は、本発明のシステムにおけるファイル登録チケット（FRT) によるファイル生成処理において、公開鍵方式認証、公開鍵方式チケット検証を実行した場合の処理を説明する図である。

図 7 6は、本発明のシステムにおけるファイル登録チケット（FRT) によるファイル生成処理において、公開鍵方式認証、共通鍵方式チケット検証を実行した場合の処理を説明する図である。

図 77は、本発明のシステムにおけるファイル登録チケット（FRT) によるファイル生成処理において、共通鍵方式認証、共通鍵方式チケット検証を実行した場合の処理を説明する図である。

図 78は、本発明のシステムにおけるファイル登録チケット（FRT) によるファイル生成処理において、共通鍵方式認証、公開鍵方式チケット検証を実行した場合の処理を説明する図である。

図 79は、本発明のシステムにおけるサービス許可チケット（S PT) を適用したファイルアクセス処理フ口一を示す図である。

図 80は、本発明のシステムにおけるサービス許可チケット（S PT) を適用したファイルオープン操作フロ一を示す図である。

図 8 1は、本発明のシステムにおけるサービス許可チケット（S PT) を適用したファイルオープン操作により生成されるファイルオープンテーブル構成を説明する図（例 1 ) である。

図 82は、本発明のシステムにおけるサービス許可チケット（S P T) を適用したファイルオープン操作により生成されるファイルオープンテーブル構成を説明する図（例 2 ) である。

図 83は、本発明のシステムにおけるサービス許可チケット（S PT) を適用したファイルアクセス処理例を説明する図（例 1 ) である。

図 84は、本発明のシステムにおけるサービス許可チケット（S P T) を適用したファイルアクセス処理例を説明する図（例 2) である。

図 85は、本発明のシステムにおける認証により生成されるセッション鍵の取扱について説明する図である。

図 86は、本発明のシステムにおけるサービス許可チケット（S PT) を適用したファイルアクセス処理例を説明するフロー図（例 1 ) である。

図 87は、本発明のシステムにおけるサービス許可チケット（S PT) を適用したファイルアクセス処理例を説明するフロー図（例 2) である。

図 88は、本発明のシステムにおけるサービス許可チケット（S PT) を適用した複合ファイルのアクセス処理例を説明する図である。

図 89は、本発明のシステムにおけるサービス許可チケット（S PT) によるファイルアクセス処理において、公開鍵方式認証、公開鍵方式チケット検証を実行した場合の処理を説明する図である。

図 90は、本発明のシステムにおけるサービス許可チケット（S PT) による処理において、公開鍵方式認証、共通鍵方式チケット検証を実行した場合の処理を説明する図である。図 9 1は、本発明のシステムにおけるサービス許可チケット（ S P T ) による処理において、共通鍵方式認証、共通鍵方式チケット検証を実行した場合の処理を説明する図である。

図 9 2は、本発明のシステムにおけるサービス許可チケット（S P T ) による処理において、共通鍵方式認証、公開鍵方式チケット検証を実行した場合の処理を説明する図である。

図 9 3は、本発明のシステムにおけるデ一夕アップデートチケット（D U T ) によるデ一夕更新処理フローを示す図である。

図 9 4は、本発明のシステムにおけるデータアップデートチケット（D U T ) によるデータ更新操作フローを示す図である。

図 9 5は、本発明のシステムにおけるデータアップデートチケット（D U T ) によるデータ更新処理例を説明する図である。

図 9 6は、従来のメモリ構造を示す図である。

図 9 7は、従来のメモリ管理者、利用者の関係を説明する図である。

図 9 8は、従来のメモリ領域確保処理について説明する図である。

図 9 9は、従来のメモリアクセス方式について説明する図である。発明を実施するための最良の形態

以下、図面を参照しながら、本発明の実施の形態について詳細に説明する。なお、説明は、以下の項目に従って行なう。

A . デバイスを利用したデータ処理システムの構成ェンティティおよびチケットに関する説明

A 1 . メモリ搭載デバイスを利用したデータ管理システムの概要

A 2 . デバイスの構成

A 3 . デバイスマネージャの構成

A . パーティションマネ一ジャの構成

A 5 . チケヅトュ一ザ（デバイスアクセス機器としてのリーダライ夕）の構成 A 6 . 公開鍵証明書

A 7 . デバイスのメモリ部における格納データ A 7. 1. デバイス固有情報およびデバイス内パーティション情報領域 A 7. 2. パーティション領域

A 8. 各チケットのデータフォーマット

A 8. 1. パーティション登録チケット（PRT)

A 8. 2. ファイル登録チケット（FRT)

A 8. 3. サービス許可チケット（S PT)

A 8. 4. データアップデートチケット（DUT)

B . ユーザに対するデバイスの配布、デバイスに対する各種設定、デバイス利用処理の詳細についての説明

B 1. デバイス初期登録から利用までの流れ

B 2. デバイス製造エンティティによる初期登録処理

B 3. デバイスマネージャの管轄処理

B 3. 1. デパイスマネージャによるデバイス登録処理

B 3. 2. デバイスマネージャ管理下における公開鍵証明書発行処理

B 4. パーティションマネージャの管轄処理

B 4. 1. パーティションマネ一ジャ管理下におけるパーティション登録チケット（PRT) を利用したパーティション設定登録、削除処理

B 4. 2. パーティションマネージャ管理下における公開鍵証明書発行処理 B 4. 3. パーティション生成処理各方式における処理手順

B 4. 4. ファイル登録チケット（FRT) を利用したファイル生成、消去処理

B 4. 5. ファイル生成処理各方式における処理手順

B 4. 6. サービス許可チケット（S P T) を利用したサービス（ファイルァクセス）処理

B 4. 7. サービス許可チケット（S PT) を利用したアクセス処理各方式における処理手順

B 5. データアップデートチケット（DUT) を利用したデバイスのデータ更新処理

[A 1. メモリ搭載デパイスを利用したデータ管理システムの概要] 図 1に本発明のデータ管理システムの概要を説明する図を示す。メモリ搭載デパイス（以下デバイス） 1 00はデバイス製造エンティティ（manufacturer) 5 00により製造され、デバイス管理エンティティとしてのデバイスマネージャ（D M： Device Manager) 200の管理の下にユーザに提供されて利用される。ュ一ザに対するデバイスの提供形態は、貸与または販売（譲渡を含む）など、いずれの形態でもよい。

デバイス 1 00は、メモリ領域が複数のデータ格納領域としてのパーティションに分割され、個々のパーティション（Partition Α,Β Ζ)は、様々なサ一ビス主体（A, Β, - Ζ ) 30 0Α〜 300 Ζとしてのパーティションマネージャの管理の下、様々なサービスに利用される。

デバイス 1 0 0に対するパーティションの設定登録処理、デバイスに設定されたパーティション内におけるファイルの設定登録処理、さらに、登録された各フアイルに対するアクセス処理にはそれぞれ正当なチケット発行手段（Ticket Issuer) の発行したデバイスに対するアクセスコントロールチケットを必要とする。

デバイス 1 0 0に対するパーティションの設定登録処理には、正当なチケット発行手段（Ticket Issuer) の発行したパ一テイション登録チケット（ P R T ： Partition Registration Ticket) が必要であり、デバイスに設定されたパ一ティション内に対するファイルの設定登録処理には、正当なチケット発行手段（Ticket Issuer) の発行したファイル登録チケット（ F R T ： File Registration Ticket) が必要であり、また、各ファイルに対するアクセスには正当なチケット発行手段 (Ticket Issuer)の発行したサービス許可チケット（ S P T： Service Permission Ticket) が必要となる。

各チケットには、デバイス 1 0 0に対するアクセスルール、例えばデバイスに対して読み書きなど各種処理を実行するリーダ/ライ夕とデバイス間の相互認証処理に関するルールの他、例えばパーティション登録チケット（PRT) であれば、設定できるパーティションサイズ、ファイル登録チケット（FRT) であれば、設定できるファイルサイズ、サービス許可チケット（S PT) であれば、実行可能なアクセス態様（ex. データ読み出し、書き込みなど）などが格納され、さらにチケット発行者、チケット利用者に関する情報、その他の情報が格納される。また、これらチケット格納データに対する改竄チェック用の I CV( Integrity Check Value) が記録され、チケットの改竄の無いことを条件としてチケットに記録された範囲内の処理が実行可能となる。これらチケットの詳細については後段で説明する。

図 1において示す例では、パーティション登録チケット（PRT) を発行するチケット発行手段（Ticket Issuer) はデバイスマネージャ（DM) 200内に設定され、パーティションマネージャとしてのサービス主体 A， 300 A内にファィル登録チケット（FRT)、およびサービス許可チケット（S PT) を発行するチケット発行手段（Ticket Issuer) が設定される。なお図 1の構成は、サービス主体 B Z， 3 00 B〜3 00 Zについても基本的にサービス主体 Aと同様の構成を持つものであり、各サービス主体にファイル登録チケット（F R T)、およびサービス許可チケット（S PT) を発行するチケット発行手段（Ticket Issuer) が設定される。

なお、図 1では、サービス主体とパーティションマネージャ（PM) を同一ェンティティとして示しているが、必ずしもこれらのエンティティは同一であることは必要でなく、デバイスに設定されるメモリ領域としてのパーティションを管理するパーティシヨンマネージャと、パ一ティションマネージャの管理するメモリ領域であるパーティションをパーティションマネージャから所定契約の下に借り受けて、借り受けたパーティション内に様々なファイルを格納してサービスを提供するサービス主体とが別エンティティとして存在してもよい。以下の説明では、説明を簡略化するためにサービス主体がパーティションマネージャとして機能する構成例について説明する。

各サービス主体 300 A~ 300 Zとしてのパーティションマネージャ（PM) は、デバイスマネージャ（DM) 200に対して、例えば相応の対価を支払うなど所定の契約の下に、パーティション登録チケット（PRT) の発行要求を行ない、デバイスマネージャ（DM) の許諾の下、デバイスマネージャ（DM) 内のチケヅト発行手段（Ticket Issuer) が各サービス主体としてのパーティションマネ一ジャ（PM) に対してパーティション登録チケット（PRT) を発行する。各サービス主体（パーティションマネージャ（PM)) 300は、通信ィンタフヱ一ス（I/F) を介してユーザの所有デバイス 1 00に対するアクセスを実行し、デバイスマネージャ（DM) 200から受領したパーティション登録チケット（PRT) に記録されたルールに従った認証、検証等の処理を実行し、かつパ —テイシヨン登録チケット（PRT) に記録された許可範囲内のパーティションの設定登録処理を実行する。この処理については後段で詳細に説明する。

通信 I/Fは、有線、無線を問わず、外部機器（デバイス）とのデータ通信可能なインタフヱースであればよく、例えば、デバイスが U S B接続構成を持つ場合は US B I/F、また、 I Cカード型であれは I Cカード用リーダライタ、さらに公衆回線、通信回線、イン夕一ネットなど各種の通信機能を持つデバイス、あるいはこれらの通信装置に接続可能なデバイスであれば、各通信方式に従ったデ一夕通信 I /Fとして構成される。

また、デバイス 1 0 0にサービス主体 300のパーティションが設定されると、各サービス主体 300は、通信インタフェース（ I/F) を介してユーザ所有のデバイス 1 00にアクセスし、各サービス主体 300のチケヅト発行手段（Ticket Issuer) の発行するファイル登録チケット（FRT) に記録されたルールに従つた認証、検証等の処理を実行し、かつファイル登録チケット（FRT) に記録された許可範囲内のファイルの設定登録処理を実行する。この処理については後段で詳細に説明する。

さらに、各サービス主体 300は、通信インタフェース（ I/F) を介してュ一ザの所有デバイス 1 0 0にアクセスし、各サービス主体のチケット発行手段 (Ticket Issuer) の発行するサービス許可チケット（S PT) に記録されたルールに従った認証、検証等の処理を実行し、かつサービス許可チケット（S PT) に記録された許可範囲内のアクセス（ex. データの読み取り、書き込みなど）処理を実行する。この処理については後段で詳細に説明する。

また、図 1に示すように、デバイスマネージャ 200、パーティションマネ一ジャ 300の上位にコ一ド管理機関 400が設定され、個々のデバイスマネージャ、パーティションマネージャに各エンティティの識別情報としてのコードを割り振る処理を行なっている。これら各マネージャに付与されたコードは、前述のパーティション登録チケット（PRT)、ファイル登録チケット（FRT)等のァクセスコントロールチケットの格納データとされる。

デバイス 1 0 0がユーザに提供（e x. 貸与、販売）されユーザが利用する以前に、提供デバイスを管理するデバイスマネージャ（DM) 20 0が設定され、その提供デパイス内にデバイスマネージヤコ一ド他、デバイスマネージャの管理情報が書き込まれる。これらのデ一夕詳細については後述する。

本発明のメモリデバイスを利用したデータ管理システムにおける公開鍵証明書の発行処理と各エンティティの関係について、図 2を用いて説明する。

図 2は、デバイス管理エンティティとしてのデバイスマネージャ、デバイスに設定された各パーティションの管理エンティティとして、 2つのパーティションマネ一ジャ 30 OA, 30 0 B、デバイスマネージャ 20 0に対して識別コードを付与するコード管理機関 400を示している。さらに、デバイスマネージャ 2 00の管轄する登録局 2 1 0からの公開鍵証明書発行要求に応じて、デバイスマネージャ 200、デバイスマネージャ管轄の各機器（パーティション登録チケット（P R T) 発行手段（P R T Issuer) 2 1 0、あるいはデバイス 1 00に対応するデバイス対応公開鍵証明書（CERT-DEV) を発行するデバイスマネージャ対応認証局（C A (D E V)： Certificate Authority) 6 1 0、パーティシヨンマネ —ジャ 300 A, 300 B管轄の各機器（ファイル登録チケット（ F R T) 発行手段（FRT Issuer) 3 1 0、サービス許可チケット発行手段（S PT) 320、チケヅトユーザであるデバイスアクセス機器としてのリーダライタ 7 1 1 - 7 1 4、あるいはデバイス 1 0 0のパ一テイションに対応するパ一ティション対応公開鍵証明書（CERT-PAR) を発行するパーティションマネージャ対応認証局（CA (PAR) : Certificate Authority) 620， 630が存在する。

なお、図 2には、認証局をデバイスマネージャ対応認証局： CA (Certificate Authority) f o r D M (または C A ( D E V )) 6 1 0と、パーティションマネージャ対応認証局： CA f o r PAR (または CA (PAR)) 620 , 63 0と個別に有する構成を示しているが、両機能を持つ唯一の認証局を設けたり、複数のパーティションマネージャに対応する共通の認証局とデバイスマネージャ対応認証局を別々に設けたり、その構成は自由である。デバイスマネージャ 2 0 0、パ一テイションマネージャ 3 0 0 A, 3 0 0 Bは、自己の公開鍵証明書、各マネージャの管理する各機器（チケット発行手段、チケットユーザ）の公開鍵証明書、または、デバイス 1 0 0からの公開鍵証明書発行要求を受理し、受理した発行要求の検証を行ない、検証の後、証明書発行要求を認証局に対して転送する処理を行なうとともに、発行された公開鍵証明書の管理処理を行なう登録局（R A ： Registration Authority) 2 2 0 , 3 3 0を有する。これら登録局（RA) 2 2 0 , 3 3 0を介して各認証局（C A) 6 1 0 , 6 2 0 , 6 3 0から発行された公開鍵証明書はデバイス 1 0 0に格納され、デバイス 1 0 0に対する処理としての例えばパ一テイションの設定処理、あるいはパ一テイシヨンに対する処理としての例えばファイル設定処理、さらにファイルに対するアクセス処理等の際の相互認証処理、あるいは前述した各チケットの正当性検証処理に使用される。これら公開鍵証明書の発行処理、公開鍵証明書を使用した各処理の詳細については後述する。

図 2において、デバイス 1 0 0は、パ一テイシヨンとしてパ一ティシヨンマネ —ジャ 1 , 3 0 O Aの管理パーティション： PM l Ar e a、パーティションマネージャ 2 , 3 0 0 Bの管理パーティション： PM 2 A r e aを有し、さらに、デバイスマネージャ 2 0 0の管理領域としての DMAr e aを有する。

デバイスマネージャ 2 0 0はパーティション登録チケヅト発行手段（P R T Issuer) 2 1 0を有し、パ一テイシヨンマネージャ 3 0 0は、フアイル登録チケット発行手段（F RT Issuer) 3 1 0、およびサービス許可チケット発行手段（S P T Issuer) 3 2 0を有しており、それそれ各チケットを発行する。

パーティションマネージャ 1， 3 0 0 Aは、 P RT、 F RT、 S P T各チケヅト每に異なる専用のリーダ/ライタ（デバイスに対するデータ読み出し書き込み用のインタフェース） 7 1 1 ~ 7 1 3を有した構成であり、パーティションマネージャ 2 , 3 0 0 Bは、各チケットに共通のリ一ダ /ライタ Ί 1 4を有した構成を示している。リーダ/ライタはこのように様々な構成をとることが可能である。さらに図 3を用いてエンティティの具体例について説明する。図 3には、デバイスに設定されたパーティションを利用したサービスを提供するサービス主体としてのパーティシヨンマネージャとして東西鉄道株式会社および南北鉄道株式会社の 2つのサービス主体を想定し、これらパーティションマネージャに対してパ —ティシヨンの設定登録を行なうデバイスマネージャとして日本鉄道グループという組織を想定したデバイス利用構成例を示している。

東西鉄道株式会社は、ユーザのデバイスに設定された自身の管理するパーティシヨン： PM 1内に複数のファイルを設定登録している。すなわち、定期券用フアイル、プリペイド用ファイル、その他用ファイルである。各サービス主体としてのパーティションマネージャは自己の提供するサービスに応じて設定されたデバイスマネージャによって割り当てられたパーティション内に様々なファイルを登録できる。ただし、ファイルの設定登録にはファイル登録チケット（FRT) が必要となる。

東西鉄道株式会社は、デバイスの 1つのパーティシヨン： PM l Ar e aを管理するパーティシヨンマネージャとして機能する。パーティシヨン： PM 1 A r e aは、デバイスマネージャとしての日本鉄道グループによって、日本鉄道グル —プの PRT I s s u e rの発行するパーティション登録チケット（PRT) に記録されたルールに従った認証、検証等の処理が実行され、かつパーティション登録チケット（PRT) に記録された許可範囲内のパーティションの設定登録処理によって設定されて、東西鉄道株式会社に付与される。

東西鉄道株式会社は、付与されたパーティシヨン： PM 1 Ar e aに自身の提供するサービスに応じて様々なファイルを設定する。例えば定期券ファイル、プリペイド用ファイルであり、定期券ファイル内のデータ格納エリアには例えば、定期券使用者名、使用期間、利用区間など定期券管理データとして必要な各種デ —夕を記録する。また、プリペイド用ファイルには、使用者名、プリペイド金額、残額データなどが記録される。このファイル設定処理には、東西鉄道の FRT I s s u e rの発行するファイル登録チケット（FRT) に記録されたルールに従つた認証、検証等の処理が実行され、かつファイル登録チケット（FRT) に記録された許可範囲内のファイルの設定登録処理によって設定される。

このように様々なファイルの設定されたデバイスがュ一ザによって使用される例えば、ユーザがデバイスを使用してデバイスアクセス機器としてのリーダライタを備えた改札にデバイスをセットして利用することが可能である。例えば改札に備えられた正当なリ一ダライタにより、定期券用ファイルのアクセスが実行されて、利用区間の読み取りが行われる。またプリペイド用ファイルにアクセスして、プリペイド用ファイル内の残金デ一夕の更新処理が実行される。

デバイス内の、いずれのファイルにアクセスしてどのような処理（読み取り、書き込み、、減額 e t c ) を実行するかは、東西鉄道のサービス許可チケット（S P T) 発行手段（S P T issuer) の発行するサービス許可チケット（S P T) に記録されている。例えば改札に備えられた正当なデバイスアクセス機器としてのリ一ダライタにはこれらのチケットが格納されており、チケットに記録されたルールに従ってデバイス間との認証処理、チケット検証等の処理が実行される。デバイスアクセス機器としてのリ一ダライタおよびデバイス相互が正当な機器であり、使用チケットが正当である場合にサービス許可チケット（S PT) に記録された許可範囲内の処理（ex. ファイル内のデータ読み取り、書き込み、、減額 e t c ) が実行されることになる。

パーティション登録チケット（PRT)、ファイル登録チケット（FRT)、およびサービス許可チケット（S PT) の各種チケットを発行するチケット発行手段（Ticket Issuer) とチケット発行手段によって発行されたチケットを利用するチケットユーザ（Ticket User) の一般的な対応関係を図 4に示す。

チケット発行手段（Ticket Issuer) は、図 1他で説明したように、デバイスマネ一ジャ、あるいはパーティションマネージャの管理下にあり、デバイスに対する処理に応じたパーティション登録チケット（PR T)、ファイル登録チケット（F RT)、およびサービス許可チケット（S P T) の各種チケットを発行する。チケットュ一ザ（Ticket User) は、チケット発行手段によって発行されたチケットを利用する機器、手段であり、具体的には例えばデバイスに対するデータ書き込み、読み取りなどの処理を実行するデバイスアクセス機器としてのリーダライタ等の機器が相当する。

図 4に示すように、チケットユーザは、複数のチケットを格納して使用することが可能である。また、単一のチケット、例えば図 3を用いて説明した定期券用ファイルの区間データ読み取りのみの実行を許可したサービス許可チケット（S PT) のみを格納し、区間データ読み取りのみの処理を実行する構成とすることも可能である。

例えば、あるサービス主体（パーティションマネージャ）である鉄道会社の定期券読み取り専用の改札には、上述の定期券用ファイルの区間データ読み取りのみの実行を許可したサービス許可チケット（S P T) のみを格納したデバイスァクセス機器としてのリーダライタを設定して、ユーザが所有するデバイスから区間データの読み取り処理を実行する。例えば、定期券、プリペイド双方の処理を実行する改札のデバイスアクセス機器としてのリ一ダライタには上述の定期券用ファイルの区間データ読み取りのみの実行を許可したサービス許可チケット（S P T)、およびプリペイド用ファイルの残金データ減額処理を許可したサービス許可チケット（S PT) を併せて格納し、定期券用ファイル、およびプリペイド用ファイル両ファイルに対する処理を実行可能とすることも可能である。

また、パーティション登録チケット（PRT)、ファイル登録チケヅト（FRT)、およびサービス許可チケット（S P T) を格納し、パーティション登録、フアイル登録、ファイル内のデータアクセス等のすべての処理を実行可能としたチケットュ一ザ（ex. リーダライタ）を構成することも可能である。このようにチケットユーザの実行可能な処理は、チケットュ一ザが適用可能なチケットによって決定されることになる。

[A 2. デバイスの構成]

次に、上述の複数のパーティシヨンにデ一夕格納領域を分割されたメモリを持つデバイスについて説明する。図 5にデバイスの構成図を示す。

図 5に示すように、デバイス 1 00は、プログラム実行機能、演算処理機能を持つ CPU (Central Processing Unit) 1 0 1を有し、デバイスアクセス機器としてのリーダライタ等、外部機器との通信処理用のィンタフエース機能を持つ通信インタフェース 1 02、 CPU 1 0 1によって実行される各種プログラム、例えば暗号処理プログラムなどを記憶した ROM (Read Only Memory) 1 03、実行プログラムのロード領域、また、各プログラム処理におけるワーク領域として機能する RAM (Random Access Memory) 1 04、外部機器との認証処理、電子署名の生成、検証処理、格納デ一夕の暗号化、復号処理等の暗号処理を実行する暗号処理部 1 0 5、前述したパーティシヨン、ファイルが設定格納されるとともに、各種鍵データを含むデバイスの固有情報を格納した例えば E E P R 0 M (Electrically Erasable Programmable ROM)によって構成されるメモリ部 1 0 6 を有する。メモリ部 1 06 (ex. EEPROM) 1 06に格納される情報については、後段で詳述する。 '

メモリ部 1 0 6のデータ格納構成を図 6に示す。メモリ部は例えば、 EEPR OM(Electrically Erasable Programmable ROM)と呼ばれる電気的に書き換え可能な不揮発性メモリの一形態であるフラッシュメモリである。

図 6に示すように、本実施例においては、 1ブロック 3 2バイト、ブロック数 0 X F F F Fのデータ格納領域を持ち、主要領域としてパーティション領域、未使用領域、デバイス固有情報およびデバイス内パーティション情報領域を持つ。パーティション領域には、前述のパ一ティションマネージャによる管理領域であるパーティションが設定登録される。なお、図 6に示すメモリは既にパーティシヨンが設定された例を示しているが、新規に製造されたデバイスには、パーテイションが設定されておらずパーティション領域は存在しない。パーティシヨンは、前述したように、デバイスマネージャの管理するパーティション登録チケヅト（P R T) 発行手段（P R T Issuer) の発行した P R Tチケットに基づいて各サ一ビス主体としてのパーティションマネージャが所定の手続き、すなわちパ一テイシヨン登録チケット（PRT) に設定されたルールに従ってデバイス内のメモリに設定する。

デパイス固有情報およびデバイス内パーティション情報領域には、デバイス製造エンティティの情報、デバイスマネージャに関する情報、設定パーティション情報、デバイスに対するアクセスを実行してパーティションの設定登録処理を実行する際に必要となる鍵情報などが格納される。これら格納情報の詳細については後述する。なお、デバイス固有情報領域の格納データは、後述する相互認証時に適用するデバイスの固有値としての I D mに対応するデ一夕として使用可能である。

また、図に示すようにパーティション領域は、さらに 1以上のファイル領域、未使用領域、パーティション固有情報およびパーティション内ファイル領域を有する。ファイル領域は、パーティションマネージャであるサービス主体が、例えば前述したような定期券用、プリペイド用などサービス毎に設定したファイルを格納する領域である。未使用領域は、さらにファイル設定可能な領域である。パ一ティション固有情報およびパ一テイション内ファイル情報領域は、例えばパーティション内のファイルに関する情報、ファイルアクセス処理に必要となる鍵情報などが格納される。これら格納情報の詳細については後述する。

[A3. デバイスマネージャの構成]

次に、デバイスマネージャの構成について図 7を用いて説明する。デバイスマネ一ジャは、ユーザに提供（販売または貸与）されるデバイスの管理ェンティティである。

デバイスマネージャ 2 0 0は、デバイス内のメモリ部の分割領域として設定されるパーティションを利用してサービスを提供するサ一ビス主体としてのパーテイションマネージャからの要求に応じてデパイスに対するパ一ティション設定を可能化するパーティション登録チケット（PRT) を発行するパーティション登録チケット（P R T) 発行手段（P R T Issuer) 2 1 0を有する。

さらに、デバイスマネージャ 200は、デバイスに対応するデバイス対応公開鍵証明書（CERT-DEV) を発行する。デバイスマネージャ 2 00は、デバイスからの公開鍵証明書発行要求を受理し、受理した発行要求の検証を行ない、検証の後、証明書発行要求を認証局（CA (D E V)： Certificate Authority) 6 1 0に対して転送する処理を行なうとともに、発行された公開鍵証明書の管理処理を行なう登録局（R A ： Registration Authority) 2 20としての機能を有する。

図 7に示すように、デバイスマネージャ 20 0のパ一テイション登録チケット (PRT) 発行手段（PRT Issuer) 2 1 0は、制御手段 2 1 1と、データべ一ス 2 1 2を有し、デ一夕べ一ス 2 1 2は、パーティション登録チケット（P RT) の発行管理データとして、チケットの発行管理用のデータ、例えば、チケット発行先のパーティションマネージャ識別子、チケット識別子、チケットユーザ（e X . リ一ダライタ， P C, e t c )識別子などを対応付けたデータが格納される。また、登録局（RA： Registration Authority) 2 20は、制御部 22 1、公開鍵証明書の発行管理用のデータベース 222を有し、公開鍵証明書の発行管理データとして、例えば公開鍵証明書を発行したデバイス識別子、公開鍵証明書の識別子（シリアルナンパ）等を対応付けたデ一夕が格納される。

デパイスマネージャ 20 0のパーティション登録チケット（P R T) 発行手段 (P R T Issuer) 2 1 0の制御手段 2 1 1は、'パ一ティションマネージャとのデ —夕通信により、パーティシヨン登録チケット（PRT)の発行処理を実行する。また、登録局（RA： Registration Authority) 220の制御手段 22 1は、デバイスに対する公開鍵証明書の発行処理を実行し、この際、デバイスとの通信、デバイスマネージャ対応認証局（CA (DEV)) 6 1 0との通信を実行する。これらの処理の詳細については後段で説明する。ここでは、制御手段 2 1 1， 22 1の構成について図 8を用いて説明する。

制御手段 2 1 1 , 22 1はいずれも例えばデ一夕処理手段としての P Cと同様の構成により実現され、具体的には例えば図 8に示すような構成を持つ。制御手段の構成について説明する。制御部 2 1 1 1は各種処理プログラムを実行する中央演算処理装置（CPU:Central Processing Unit) によって構成される。 RO M (Read only Memory) 2 1 1 2は、暗号処理プログラム等の実行処理プログラムを記憶したメモリである。 RAM (Random Access Memory) 2 1 1 3は、制御部 2 1 1 1が実行するプログラム、例えばデータベース管理プログラム、暗号処理プログラム、通信プログラム等、実行プログラムの格納領域、またこれら各プログラム処理におけるワークエリアとして使用される。

表示部 2 1 1 4は、液晶表示装置、 CRTなどの表示手段を有し、制御部 2 1 1 1の制御の下、様々なプログラム実行時のデータ、例えば処理対象のデータ内容等を表示する。入力部 2 1 1 5は、キーボードや、例えばマウス等のポインテイングデパイスを有し、これら各入力デバイスからのコマンド、デ一タ入力を制御部 2 1 1 1に出力する。 HDD (Hard Disk Drive) 2 1 1 6は、データベース管理プログラム、暗号処理プログラム、通信プログラム等のプログラム、さらに各種データが格納される。

ドライブ 2 1 1 7は、例えば HD (Hard Disk) や、 FD (Floppy Disk) 等の磁気ディスク、 CD— ROM (Compact Disk ROM) などの光ディスク、ミニディスク等の光磁気ディスク、 ROMやフラッシュメモリなどの半導体メモリ等の各種記録媒体に対するアクセスを制御する機能を持つ。磁気ディスク等の各種記録媒体はプログラム、データ等を記憶する。通信インタフヱ一ス 2 1 1 8は、ネヅトワーク、ケーブル接続、電話回線等の有線、無線を介した通信のインタフエ一スとして機能し、ュ一ザのデバイス、パーティションマネージャ、認証局等の各エンティティとの通信ィンタフエースとして機能する。

[A 4. パーティションマネージャの構成]

次に、パーティションマネージャの構成について図 9を用いて説明する。パ一テイシヨンマネージャは、ユーザに提供（販売または貸与）されるデバイスに設定されたパ一ティションの管理ェンティティである。

パーティションマネージャ 300は、デバイスマネージャから付与されたパ一テイシヨン登録チケット（PRT) を用いて、付与された P RTに記録されたル —ルに従って、ュ一ザのデバイス内のメモリ部に分割領域としてパーティシヨンを設定し、設定されたパーティションを利用したサービスを提供する。

設定されたパーティションにはサービス、デ一夕に応じたファイルを設定することが可能である。ただし、ファイル設定処理には、ファイル登録チケット（F RT) を取得することが必要であり、ファイル内のデータの読み出し、書き込みなどのデータアクセスにはサービス許可チケット（S PT) を取得することが必要である。ファイル設定、デ一夕アクセス処理はチケットユーザ、すなわち具体的には、例えば専用のデバイスアクセス機器としてのリーダライタなどがチケットを使用して実行する。

パーティションマネージャ 300は、このようなチケットユーザに対するチケット発行処理手段としてのファイル登録チケヅト（F RT) 発行手段（FR T Issuer) 3 1 0、およびサービス許可チケット（ S P T)発行手段（ S P T Issuer) 320を有する。

さらに、パーティションマネージャ 300は、デバイスの各パーティションに対応するパーティション対応公開鍵証明書（CERT- PAR) を発行する。パーティシヨンマネージャ 3 00は、デパイスからの公開鍵証明書発行要求を受理し、受理した発行要求の検証を行ない、検証の後、証明書発行要求を認証局（CA (P A R)： Certificate Authority) 620に対して転送する処理を行なうとともに、発行された公開鍵証明書の管理処理を行なう登録局（R A ： Registration Authority) 330としての機能を有する。

図 9に示すように、パーティションマネージャ 300のフアイル登録チケヅト (F R T) 発行手段（F R T Issuer) 3 1 0は、制御手段 3 1 1と、データべ一ス 3 1 2を有し、データベース 3 1 2は、ファイル登録チケット（F R T) の発行管理データとして、チケットの発行管理用のデ一夕、例えば、チケット発行先のチケットユーザ（ex. リーダライタ， P C, e t c) 識別子、チケット識別子などを対応付けたデータを格納する。

さらにパーティションマネージャ 3 00のサービス許可チケット（ S P T) 発行手段（ S P T Issuer) 3 20は、制御手段 32 1 と、デ一夕べ一ス 32 2を有し、データべ一ス 32 2は、サービス許可チケット（ S P T) の発行管理データとして、チケットの発行管理用のデータ、例えば、チケット発行先のチケットュ —ザ（ex. デバイスアクセス機器としてのリ一ダライタ， P C, e t c ) 識別子、チケット識別子などを対応付けたデータを格納する。

また、登録局（RA ： Registration Authority) 33 0は、公開鍵証明書の発行管理用のデータベース 3 32を有し、公開鍵証明書の発行管理デ一夕として、例えば公開鍵証明書を発行したデバイス識別子、パーティション識別子、公開鍵証明書の識別子（シリアルナンパ）等を対応付けたデータが格納される。

パーティションマネージャ 300のファイル登録チケヅト（FRT) 発行手段 (FRT Issuer) 3 1 0の制御手段 3 1 1は、チケットュ一ザ（ex. デバイスアクセス機器としてのリーダライタ， P C, e t c) とのデ一夕通信により、フアイル登録チケット（FRT) の発行処理を実行し、サービス許可チケット（S P T)発行手段（Ticket Issuer) 320の制御手段 32 1は、チケットュ一ザ（ e X . デバイスアクセス機器としてのリーダライタ， P C, e t c) とのデータ通信により、サービス許可チケット（S PT) の発行処理を実行する。また、登録局（R A： Registration Authority) 330の制御手段 33 1は、デパイスに対する公開鍵証明書の発行処理を実行し、この際、デバイスとの通信、パーティションマネージャ対応認証局（CA (PAR)) 620との通信を実行する。これらの処理の詳細については後段で説明する。

なお、パーテイションマネージャ 3 00の制御手段 3 1 1， 32 1 , 3 3 1の構成は、図 8を用いて説明した前述のデバイスマネージャにおける制御手段と同様の構成であるので説明を省略する。

[ A 5 . チケットュ一ザ（デバイスアクセス機器としてのリーダライタ）の構成]

デバイスアクセス機器としてのリーダライタはデバイスに対するパーティションの設定、ファイルの設定、データの読み取り、書き込み、金額データの減算、加算などの様々な処理を実行する機器として構成される。デバイスに対する処理は、処理の際に適用するパーティション登録チケヅト（P R T )、ファイル登録チケヅト（F R T )、またはサービス許可チケット（ S P T ) に記録されたルールに従う。すなわち、デバイスに対するすべての処理はこれら適用するチケットによつて制限される。

デバイスアクセス機器としてのリ一ダライタの構成例を図 1 0に示す。図 1 0 に示すように、リーダライタ 7 0 0は、プログラム実行機能、演算処理機能を持つ C P U ( Central Processing Uni t) 7 0 1を有し、デバイス、チケヅト発行手段（Ticket I ssuer) 等、外部機器との通信処理用のィンタフヱ一ス機能を持つ通信インタフェース 7 0 2、 C P U 7 0 1によって実行される各種プログラム、例えば暗号処理プログラムなどを記憶した R O M (Read Only Memory) 7 0 3、実行プログラムのロード領域、また、各プログラム処理におけるワーク領域として機能する R A M (Random Access Memory) 7 0 4、外部機器との認証処理、電子署名の生成、検証処理、格納データの暗号化、復号処理等の暗号処理を実行する暗号処理部 7 0 5、認証処理、暗号化、復号処理用の各種鍵データ、およびリーダライ夕の固有情報を格納した例えば E E P R 0 M (Electrical ly Erasable Programmable ROM)によって構成されるメモリ部 7 0 6を有する。

[ A 6 . 公開鍵証明書]

本発明のパーティション分割メモリ領域を持つデバイスの利用において、各ェンティティ、チケット発行手段、チケットユーザ、デバイス等の相互間におけるデータ通信においては、データ送信側とデ一夕受信側とが互いに正規なデータ送受信対象であることを確認した上で、必要な情報を転送する、データ転送の際のセキュリティ構成を実現する手法として、転送データの暗号化処理、データに対する署名生成、検証処理が適用される。

暗号化デ一夕は、所定の手続きによる復号化処理によって利用可能な復号デ一夕（平文）に戻すことができる。このような情報の暗号化処理に暗号化鍵を用い、復号化処理に復号化鍵を用いるデ一夕暗号化、復号化方法は従来からよく知られている。

暗号化鍵と復号化鍵を用いるデータ暗号化 ·復号化方法の態様には様々な種類があるが、その 1つの例としていわゆる公開鍵暗号方式と呼ばれる方式がある。公開鍵暗号方式は、発信者と受信者の鍵を異なるものとして、一方の鍵を不特定のユーザが使用可能な公開鍵として、他方を秘密に保つ秘密鍵とするものである。例えば、データ暗号化鍵を公開鍵とし、復号鍵を秘密鍵とする。あるいは、認証子生成鍵を秘密鍵とし、認証子検証鍵を公開鍵とする等の態様において使用される o

暗号化、復号化に共通の鍵を用いるいわゆる共通鍵暗号化方式と異なり、公開鍵暗号方式では秘密に保つ必要のある秘密鍵は、特定の 1ユーザが持てばよいため鍵の管理において有利である。ただし、公開鍵暗号方式は共通鍵暗号化方式に比較してデータ処理速度が遅く、秘密鍵の配送、ディジタル署名等のデータ量の少ない対象に多く用いられている。公開鍵暗号方式の代表的なものには R S A (Rivest- Shami r- Adleman) 暗号がある。これは非常に大きな 2つの素数（例えば 1 5 0桁）の積を用いるものであり、大きな 2つの素数（例えば 1 5 0桁）の積の素因数分解する処理の困難さを利用している。

公開鍵暗号方式では、不特定多数に公開鍵を使用可能とする構成であり、配布する公開鍵が正当なものであるか否かを証明する証明書、いわゆる公開鍵証明書を使用する方法が多く用いられている。例えば、利用者 Aが公開鍵、秘密鍵のぺァを生成して、生成した公開鍵を認証局に対して送付して公開鍵証明書を認証局から入手する。利用者 Aは公開鍵証明書を一般に公開する。不特定のユーザは公開鍵証明書から所定の手続きを経て公開鍵を入手して文書等を暗号化して利用者 Aに送付する。利用者 Aは秘密鍵を用いて暗号化文書等を復号する等のシステムである。また、利用者 Aは、秘密鍵を用いて文書等に署名を付け、不特定のユーザが公開鍵証明書から所定の手続きを経て公開鍵を入手して、その署名の検証を行なうシステムである。

公開鍵証明書は、公開鍵暗号方式における認証局（ C A ： Certif icate Authori ty) が発行する証明書であり、ユーザが自己の I D、公開鍵等を認証局に提出することにより、認証局側が認証局の I Dや有効期限等の情報を付加し、さらに認証局による署名を付加して作成される証明書である。

図 1 1に公開鍵証明書のフォーマツトの概略を示す。各データの概要について説明する。

証明書のバ一ジョン（version) 番号は、公開鍵証明書フォーマヅトのバ一ジョンを示す。

証明書の通し番号は、シリアルナンパ ( S N ： Serial Number) であり、公開鍵証明書発行局（認証局： C A ) によって設定される公開鍵証明書のシリアルナンパである。

署名アルゴリズム識別子フィールド（Signature algorithm I denti f ier) の署名アルゴリズム（algorithm), アルゴリズムパラメ一夕（parameters) は、公開鍵証明書の署名アルゴリズムとそのパラメ一タを記録するフィールドである。なお、署名アルゴリズムとしては、楕円曲線暗号および R S Aがあり、楕円曲線暗号が適用されている場合はパラメ一夕および鍵長が記録され、 R S Aが適用されている場合には鍵長が記録される。

発行局（認証局： C A ) の名前は、公開鍵証明書の発行者、すなわち公開鍵証明書発行局（C A ) の名称（I ssuer) が識別可能な形式（Di stinguished Name) で記録されるフィ一ルドである。

証明書の有効期限（val idity)は、証明書の有効期限である開始日時、終了日時が記録される。

公開鍵証明書の利用者名（Subject) は、ユーザである認証対象者の識別データが記録される。具体的には例えばユーザ機器の I Dや、サービス提供主体の I D 等の識別子またはカテゴリが記録される。

利用者公開鍵フィールド（subject Publ ic Key Info ) の鍵アルゴリズム ( algorithm) と鍵（subject Publ ic key) は、ユーザの公開鍵情報としての鍵ァルゴリズム、鍵情報そのものを格納するフィ一ルドである。オプション領域には、ユーザの属性データ、その他公開鍵証明書の発行、利用に伴うオプショナルデータを記録する。属性データとしては、ユーザの所属グル —プ情報としてのデバイスマネージヤコ一ド（DM C)、パーティションマネージヤコ一ド（PMC) が記録される。なお、ここでユーザは公開鍵証明書のユーザであり、例えばデバイスマネージャ、パーティションマネージャ、チケットユーザ、チケット発行手段、デバイスなどである。

オプション領域には、さらにカテゴリ情報として、チケットユーザ、チケット発行手段、デバイス、デバイスマネージャ、パーティションマネージャなどのェンティティ、機器種別を示すカテゴリが記録される。

なお、デバイスマネージャがパーティション登録チケット発行手段（PRT Issuer) を兼ねる場合は、後述するパーティション登録チケット発行手段コード ( P R T I C ： PRT Issuer Code) は、デパイスマネージャコード（DMC) として設定可能であり、また、パーティションマネージャがファイル登録チケット発行手段、サービス許可チケット発行手段を兼ねる場合は、ファイル登録チケット発行手段コード（ F R T I C ： FRT Issuer Code)、サービス許可チケット発行手段コード（ S P T I C： SPT Issuer Code)をパーティションマネ一ジヤコ一ド（ P MC) として設定可能である。なお、これらのコードは後述する各チケット（P RT, FRT, SPTなど）にも記録される。

また、各チケット発行手段にデバイスマネ一ジヤコ一ド（DMC)、パーティシヨンマネージャコード（PMC) と異なる独自のコードを割り当てる構成としてもよい。この場合のコード付与は、前述のコード管理機関が実行する。

発行局署名は、公開鍵証明書発行局（CA) の秘密鍵を用いて公開鍵証明書のデータに対して実行される電子署名であり、公閧鍵証明書の利用者は、公開鍵証明書発行局（CA) の公開鍵を用いて検証を行ない、公開鍵証明書の改竄有無がチェック可能となっている。

公閧鍵暗号方式を用いた電子署名の生成方法について、図 1 2を用いて説明する。図 1 2に示す処理は、 E C— D S A ((Elliptic Curve Digital Signature Algorithm), IEEE P1363/D3) を用いた電子署名データの生成処理フローである。なお、ここでは公開鍵暗号として楕円曲線暗号（Elliptic Curve Cryptography (以下、 E C Cと呼ぶ））を用いた例を説明する。なお、本発明のデータ処理装置においては、楕円曲線暗号以外にも、同様の公開鍵暗号方式における、例えば R SA暗号（（Rivest、 Shamir, Adleman) など（ANSI X9.31)) を用いることも可能である。

図 1 2の各ステップについて説明する。ステップ S 1において、 pを標数、 a、 bを楕円曲線の係数（楕円曲線： y² = x³ + ax + b, 4 a + 2 7 b²≠ 0 (m o d p))、 Gを楕円曲線上のベ一スポィント、 rを Gの位数、 K sを秘密鍵（ 0 < K s < r ) とする。ステップ S 2おいて、メヅセージ Mのハッシュ値を計算し、 f=Hash(M)とする。

ここで、ハッシュ関数を用いてハッシュ値を求める方法を説明する。ハッシュ関数とは、メッセージを入力とし、これを所定のビット長のデータに圧縮し、ハヅシュ値として出力する関数である。ハッシュ関数は、ハッシュ値（出力）から入力を予測することが難しく、ハッシュ関数に入力されたデータの 1ビットが変ィ匕したとき、ノヽッシュ値の多くのビットが変化し、また、同一のハッシュ値を持つ異なる入力データを探し出すことが困難である特徴を有する。ハッシュ関数としては、 MD 4、 MD 5、 S HA— 1などが用いられる場合もあるし、 DE S— C B Cが用いられる場合もある。この場合は、最終出力値となる MAC (チエツク値： I CVに相当する）がハヅシュ値となる。

続けて、ステップ S 3で、乱数 u ( 0 < u < r ) を生成し、ステップ S 4でべ —スポイントを u倍した座標 V (Xv, Y v) を計算する。なお、楕円曲線上の加算、 2倍算は次のように定義されている。

P=(X a , Ya),Q=(Xb， Y b )，R=( X c , Y c )=P+Qとすると、

P≠Qの時（加算）、

Xc=A^!-X a -X b

Y c = A x(Xa-X c )- Ya

A=(Yb-Ya)/(Xb-Xa)

P=Qの時（2倍算）、

X c = A^J- 2 X a

Y c=Ax(Xa-X c )-Ya A=(3(Xa)^!+a)/(2 Ya)

これらを用いて点 Gの u倍を計算する（速度は遅いが、最もわかりやすい演算方法として次のように行う。 G、 2 XG、 4 x G · · を計算し、 uを 2進数展開して 1 が立っているところに対応する 2 i X G (Gを i回 2倍算した値（ iは u の L S Bから数えた時のビット位置））を加算する。

ステップ S 5で、 c =Xvmo d rを計算し、ステップ S 6でこの値が 0になるかどうか判定し、 0でなければステップ S 7で d二 [(f + c K s) /u] mo d rを計算し、ステップ S 8で dが 0であるかどうか判定し、 dが 0でなければ、ステップ S 9で cおよび dを電子署名デ一夕として出力する。仮に、 rを 1 6 0 ビット長の長さであると仮定すると、電子署名デ一夕は 320ビット長となる。ステップ S 6において、 cが 0であった場合、ステップ S 3に戻って新たな乱数を生成し直す。同様に、ステップ S 8で dが 0であった場合も、ステップ S 3 に戻って乱数を生成し直す。

次に、公開鍵暗号方式を用いた電子署名の検証方法を、図 1 3を用いて説明する。ステップ S 1 1で、 Mをメッセージ、 pを標数、 a、 bを楕円曲線の係数（楕円曲線： y²=x³+ a X + b , 4 a³ + 2 7 b ²≠ 0 (mo d p))、 Gを楕円曲線上のベースポイント、 rを Gの位数、 Gおよび K s xGを公開鍵（ 0く K sく r ) とする。ステップ S 1 2で電子署名データ cおよび dが 0 < c<r、 0 < d< r を満たすか検証する。これを満たしていた場合、ステップ S 1 3で、メッセージ Mのハッシュ値を計算し、 f = H a s h (M) とする。次に、ステップ S 14で h=l/dmod rを計算し、ステップ S 1 5で h 1 = f h mo d r、 h 2 = c h m o d rを計算する。

ステップ S 1 6において、既に計算した h 1および h 2を用い、点 P= (X p , Yp) =h 1 xG + h 2 ' K s xGを計算する。電子署名検証者は、ベ一スポィント Gおよび K s xGを知っているので、図 1 2のステップ S 4と同様に楕円曲線上の点のスカラー倍の計算ができる。そして、ステップ S 1 7で点 Pが無限遠点かどうか判定し、無限遠点でなければステップ S 1 8に進む（実際には、無限遠点の判定はステップ S 1 6でできてしまう。つまり、 P = (X, Y)、 Q = (Χ， - Υ) の加算を行うと、人が計算できず、 Ρ + Qが無限遠点であることが判明している）。ステップ S 1 8で Xp mo d rを計算し、電子署名データ cと比較する。最後に、この値が一致していた場合、ステップ S 1 9に進み、電子署名が正しいと判定する。

電子署名が正しいと判定された場合、データは改竄されておらず、公開鍵に対応した秘密鍵を保持する者が電子署名を生成したことがわかる。

ステップ S 1 2において、電子署名デ一夕 cまたは dが、 0 < c<r、 0 < d < rを満たさなかった場合、ステップ S 20に進む。また、ステップ S 1 7において、点 Pが無限遠点であった場合もステップ S 20に進む。さらにまた、ステヅプ S 1 8において、 Xp mo d rの値が、電子署名データ cと一致していなかった場合にもステップ S 20に進む。

ステップ S 2 0において、電子署名が正しくないと判定された場合、デ一夕は改竄されているか、公開鍵に対応した秘密鍵を保持する者が電子署名を生成したのではないことがわかる。

本発明のシステムにおけるデバイスは、デバイスマネージャの管理登録局を介してデバイスに対して発行されるデバイス対応の公開鍵証明書（CERT- DEV) をデパイスに格納し、さらに、パーティションマネージャの管理登録局を介してデバイスのパーティションに対して発行されるパ一ティション対応の公開鍵証明書 (CERT-PAR) をデバイスの各パーティションに格納する。これらの公開鍵証明書は、デパイスに対する処理、すなわちパーティション登録チケット（PRT) を適用したパーティション登録設定処理、ファイル登録チケット（FRT) を適用したファイル登録設定処理、さらにサービス許可チケット（S PT) を適用したデ一夕処理において、チケットユーザ（ex. デバイスアクセス機器としてのリ —ダライタ）とデバイス間の相互認証、署名生成、検証処理等に適用される。これらの処理の具体例については、後段でフローを用いて説明する。

[A 7. デバイスのメモリ部における格納データ]

次に、本発明のパーティシヨン分割されたメモリ領域を持つデバイスの格納デ一夕について説明する。先に、図 6を用いて説明した通り、デバイスは例えば E E P ROMからなるメモリ部を持ち、主要領域としてパーティション領域、未使用領域、デバイス固有情報およびデバイス内パーティション情報領域を有する。これら各領域の格納データについて以下、図を参照して順次説明する。

( A 7 . 1 . デバイス固有情報およびデバイス内パーティション情報領域）まず、デバイス固有情報およびデパイス内パーティション情報領域の各データについて説明する。デバイス固有情報およびデバイス内パーティション情報領域には、デバイス製造エンティティの情報、デバイスマネージャに関する情報、設定パーティション情報、デパイスに対するアクセスを実行してパ一ティシヨンの設定登録処理を実行する際に必要となる鍵情報などが格納される。

図 1 4は、製造情報ブロック（Manufacture Information B lock) のデータ構成を示している。各領域の数値は、バイト数を示す。図 6を用いて説明したように、本実施例の構成では 1ブロック： 3 2バイト構成である。なお、図中グレー部分は暗号化されたデ一夕でも、暗号化されていなくてもよい。

製造情報ブロック（Manufacture Information B lock) には、以下のデータが格納される。

* Wri table Flag ：ブロックへ書き込みが許可されているかの判別フラグ（ex. Oxffff ：書込許可， others ：書込不可）

* Manufacture Code ：カード製造工場識別番号

* Manufacture Equipment Code ：力一ド製造ライン番号

* Manufacture Date ：力一ド製造日。例えば、 2001年 1月 1 日を 0x0000とする

* Manufacture Seri al Number ：カード製造シリアル番号

* Device Vender Code ： ICチップ供給会社番号

* Device Code ： ICチップの型番

* Device Parameter ：その他のノ、'ラメ一夕

これらのブロックに書かれる情報は一意になるので、これらの情報を基にデバイス（Device) 固有識別子として I D mと定義する。なお、デバイス（Device) 固有識別子は製造情報ブロック（Manufacture Information B lock) に書き込まれた情報全体、あるいは書き込まれた情報の一部、または書き込まれた情報に基づいて取得される演算データから取得する構成とすることも可能である。

図 1 5は、デバイス管理情報ブロック（Device Management Information Block) のデータ構成を示す。デバイス管理情報ブロック（Device Management Information Block) には以下のデ一夕が格納される。

* Writable Flag ：ブロックへ書き込みが許可されているかの判別フラグ（ex. Oxffff ：書込許可， others ：書込不可）

* DMC (Device Manager Code) ：デノ、'イスマネ一ジャ (DM： Device Manager) の識別番号

* DMC Version ：デバイスマネ一ジャコード（DMC) のバージョン。例えば、 DM Cを更新する時の比較条件として用いられる。

* Total Block Number in Device ：デバイス（Device) 内の全ブロック数 * Free Block Number in Device ：デバイス（Device) 内の空きブロック数

* Partition Number ：現在登録されているパーティション（Partition) 数

* Pointer of Free Area ：空き領域のポィン夕

図 1 6は、公開鍵系デバイス鍵定義ブロック（Device Key Definition Block (PUB)) のデータ構成を示す。公開鍵系デバイス鍵定義ブロック（Device Key Definition Block (PUB)) には以下のデータが格納される。

* PUB_CA(DEV) Pointer：デバイスマネージャの管轄する登録局を介して公開鍵証明書の発行を行なうデバイスマネージャ対応認証局（C A (D E V))の公開鍵が格納されているブロックへのポインタ

* PUB_CA(DEV) Size ：認証局 CA (D E V) の公開鍵のサイズ

* PRI_DEV Pointer：デバイス（Device) の秘密鍵が格納されているブロックへのポィンタ

* PRIJEV Size ：デバイス（Device) の秘密鍵のサイズ

* PARAM_DEV Pointer：デバイス（Device) の公開鍵パラメ一夕が格納されているブロックへのポインタ

* PARAM_DEV Size ：デバイス（Device) の公開鍵パラメ一夕のサイズ

* CERTJEV Pointer ：認証局 C A (D E V) が発行したデバイス（Device) の公開鍵証明書が格納されているプロックへのポインタ

* CERTJEV Size ：：認証局 C A (D E V) が発行したデバイス（Device) の公開鍵証明書のサイズ * CRL_DEV Pointer：デバイス（Device) のリボケ一シヨンリスト（Revocation List) が格納されているブロックへのポインタ

* CRLJEV Size：デバイス（Device)のリボケ一シヨンリスト（Revocation List) のサイズ

* PRTIC (PRT Issuer Category) ：パーティション登録チケット（PRT) 発行者カテゴリ

*PRTIC Version：パーティション登録チケット（PRT) 発行者カテゴリ（P R T I C) のパージョン

* DUTIC_DEV (DUT Issuer Category) ：データアップデートチケット（DUT ： Data Update Ticket) 発行者カテゴリ

* DUTIC— DEV Version ：データアップデートチケット（DUT ： Data Update Ticket) 発行者（DUT I C) のパージョン

なお、上記のデータ中のリポケーシヨンリストとは、不正デバイスのリストとして、例えばデバイス流通システムの管理者が発行するデバイス排除用リストであり、不正デバイスの識別データをリスト化したデ一夕である。デバイスァクセス機器としてのリ一ダライタにセットされたデバイスがリポケ一シヨンリストに記載されたデバイスである場合は処理を停止するなどの措置をとる。

例えばデバイスに対する処理を実行するすべてのデバイスアクセス機器としてのリ一ダライタに常に最新のリボケーシヨンリストを配布してデバイスに対して処理を実行する際にリストを参照して処理の実行または停止を判定する。あるいはデバイスアクセス機器としてのリーダライタの通信機能によりネットワークを介して最新のリポケーシヨンリストを閲覧することでリストに記載された不正デバイス情報を取得して処理の実行または停止を判定する。リボケーシヨンリストを利用した具体的処理については、フローを用いた説明中で後述する。

また、上記のデータ中のデ一夕アップデートチケット（ D U T ： Data Update Ticket) は、デバイスに格納された様々なデータの更新処理を実行する際に更新処理を許可し制限するためのアクセス制限チケットであり、前述の P RT, F R T, S P Tの各チケットと同様、デバイスに対するアクセスルールを記録したチケットである。このデ一夕アップデートチケット（D U T ： Data Update Ticket) については、後段でさらに詳細に説明する。

図 1 7は、共通鍵系デバイス鍵定義ブロック（Device Key Definition Block(Common))のデータ構成を示す。共通鍵系デバイス鍵定義プロック（Device Key Definition Block(Common)) には以下のデータが格納される。

* Mkauth_DEV_A Pointer ：双方向個別鍵認証用マスタ一鍵（MKauth_DEV— A)のポィンタ

* Mkauth_DEV_A Size：双方向個別鍵認証用マスタ一鍵（MKauth— DEV_A)のサイズ

* Kauth_DEV_B Pointer ：双方向個別鍵認証用鍵（Kauth_DEV_B)のポインタ

* Kauth_DEV_B Size ：双方向個別鍵認証用鍵（Kauth_DEV_B)のサイズ

* Kprt Pointer ：パ一テイション登録チケット（ P R T ) の M A C検証用鍵 (Kprt)が格納されているプロックへのポインタ

*Kprt Size：パーティション登録チケット（PRT) の M A C検証用鍵（Kprt) のサイズ

* Kdut_DEVl- 4 Pointer：デ一夕アップデートチケット（DUT) の MAC検証用鍵（Kdut)が格納されているプロヅクへのポィン夕

* Kdut_DEVl-4 Size ：データアップデ一トチケット（DUT) の MAC検証用鍵（Kdut)のサイズ

* IRL_DEV Pointer：デバイス（Device) のリポケ一シヨンリスト（Revocation List) として、不正デパイスのデバイス I D (Device ID)が格納されているブロックへのポインタ

* IRL_DEV Size：デバイス（Device)のリポケ一シヨンリスト（Revocation List) のサイズ

上述のデ一夕中に示される双方向個別鍵認証の方法、 MA C (Message Authenticate Code) 検証処理については、後段で詳細に説明する。

また、 Kdut_DEV は 4種類存在し、（Kdut_DEVl， Kdut_DEV2), (Kdut_DEV3, Kdut_DEV4)のペアで使われる。例えば、 Kdut_DEVl, 3は MAC生成用、 Kdut_DEV2, 4 は暗号用に使われる。

図 1 8は、デバイス鍵領域（Device Key Area) のデータ構成を示す。デバイス鍵領域（Device Key Area) には以下のデータが格納される。なお、デバイス鍵領域（Device Key Area) の各格納鍵には、パ一ジョン情報が併せて格納される。鍵の更新時には、バ一ジョンについても併せて更新される。

* IRL_DEV ：排除デバイス（Device)、排除機器（デバイスアクセス機器としてのリーダライタ、 P C等のチケットュ一ザ、チケット発行手段）の識別子（ I D) を登録したリポケ一シヨンリスト（Revocation List (Device ID))

* CRLJEV ：排除デバイス（Device)、排除機器（デバイスアクセス機器としてのリーダライタ、 P C等のチケットユーザ、チケット発行手段）の公開鍵証明書識別子（ e X . シリアルナンパ' ： S N ) を登録したリポケ一シヨンリスト

(Revocation List (Certmcate )

* Kdut— DEVI ：データアップデートチケット（D U T) の MA C検証用鍵

* Kdut_DEV2 ：データ更新用暗号鍵

* Kdut— DEV3 ：データアップデートチケット（DUT) の MAC検証用鍵

* Kdut_DEV4 ：データ更新用暗号鍵

* Kprt ：パ一ティション登録チケット（PRT) の MAC検証用鍵

* CERT—DEV ：デバイスマネージャ対応公開鍵を発行する認証局 C A (D E V) が発行したデバイス（Device) の公開鍵証明書

* PRI_DEV ：デバイス（Device) の秘密鍵

* PARAM_DEV ：デバイス（Device) の公開鍵パラメ一夕

*PUB_CA(DEV)：デバイスマネージャ対応公開鍵を発行する認証局 CA(D E V) の公開鍵

* Kauth_DEV_B ：双方向個別鍵認証用共通鍵

* MKauth_DEV_A ：双方向個別鍵認証用マスタ一鍵

なお、図に示すデバイス鍵領域（Device Key Area) には Kauth— DEV_A ：双方向個別鍵認証用共通鍵、 MKauth— DEV_B：双方向個別鍵認証用マスタ一鍵が格納されているが、これらの鍵は、デバイスが共通鍵認証処理を行なう要請が無い場合は格納しない構成としてもよく、また、 Kprt ：パーティション登録チケット（P RT) の MAC検証用鍵についても、デバイスがチケット検証処理を実行しない構成の場合には格納しない構成としてもよい。

また、 IRL_DEV：排除デバイス（Device) のデバイス識別子（ I D) を登録したリポケ一シヨンリスト（Revocation List (Device ID))、 CRL—DEV ：排除デバイス（Device) の公開鍵証明書識別子（ex. シリアルナンパ： SN) を登録したリボケ一シヨンリスト（Revocation List (Certificate) についても、リポーク (排除）されたデパイスが存在しない場合、あるいは他のソースを使用してリポケ一シヨンリストを取得する構成とする場合には、リボケ一シヨンリストを格納しない構成としてもよい。

図 1 9は、パーティション定義ブロック（Partition Definition Block) 'のデ —夕構成を示す。パーティション定義ブロック（Partition Definition Block) には以下のデータが格納される。

* PMC (Partition Manager Code) ：パ一ティシヨンマネージャ（Partition Manager) に割り当てられたコード（PMC)。例えば番号。

* PMC Version ：パーティションマネ一ジヤコ一ド（PMC) のバ一ジョン

* Partition Start Position ：パ一テイシヨン（ParUtion) 格納先スタートァドレス

* Partition Size ：パーテイシヨン（Partition) のサイズ

以上が、デバイスのメモリ部のデバイス固有情報およびデバイス内パ一ティション情報領域の各データである。

(A 7. 2. パーティション領域）

次に、パーティション領域の各データについて説明する。パーティション領域は、パーティションマネ一ジャの管理領域である。前述したように、デバイスマネージャの管理するパーティシヨン登録チケット（P RT) 発行手段（P R T Issuer) の発行した P R Tチケットに基づいて各サービス主体としてのパーティシヨンマネージャが所定の手続き、すなわちパーティション登録チケット（PR T) に設定されたルールに従ってデバイス内のメモリに設定する。以下、パーテイシヨン領域のデ一夕構成について説明する。

図 2 0は、パーティション管理情報ブロック（ Partition Management Information Block) のデータ構成を示す。パーティション管理情報ブロック (Partition Management Information Block) には以下のデータが格納される。

* PMC (Partition Manager Code) ：パーテイシヨン（Partition) 保有者の番号 * PMC Version ：パーティションマネ一ジヤコ一ド（PMC) のバ一ジョン

* Total Block Number in Partition ：パーティション（Partition) 内の全ブロック数

* Free Block Number in Partition ：ノ"？一ティシヨン (Partition) 内の空きブロック数

* Pointer of Free Area ：パーティション（Partition) 内の未使用領域のポインタ

* File Number ：パ一ティションに現在登録されているファイル（File) 数図 2 1は、公開鍵系パ一ティション鍵情報プロヅク（Partition Key Definition Block(PUB)) のデ一夕構成を示す。公開鍵系パーティション鍵情報ブロック (Partition Key Definition Block(PUB)) には以下のデ一夕が格納される。

* PUB_CA(PAR) Pointer：パ一ティションマネージャの管轄登録局を介して公開鍵証明書を発行する認証局 C A (PAR) の公開鍵が格納されているブロックへのポィン夕

* PUB_CA(PAR) Size ：認証局 C A (PAR) の公開鍵のサイズ

* PRし PAR Pointer ：パーティション（Partition) の秘密鍵が格納されているブロックへのポインタ

* PRI_PAR Size ：パ一テイシヨン（Partition) の秘密鍵のサイズ

* PARAM_PAR Pointer ：パーティション（Partition) の公開鍵パラメータが格納されているブロックへのポインタ

* PARAM— PAR Size：パーティション（Partition) の公開鍵パラメ一夕のサイズ

* CERT_PAR Pointer ：認証局 C A ( P A R) が発行したパーティション (Partition) の公開鍵証明書が格納されているプロックへのポィンタ

* CERT_PAR Size：認証局 C A (PAR)が発行したパーティシヨン（Partition) の公開鍵証明書のサイズ

* CRL_PAR Pointer ：パ一テイシヨン（Partition) のリボケ一シヨンリスト (Revocation List) が格納されているブロックへのポインタ

* CRL_PAR Size ：パーティション（Partition) のリポケ一シヨンリスト (Revocation List) のサイズ * FRTIC (FRT Issuer Category) ：ファイル登録チケット（F RT) 発行者カテゴリ

* FRTIC Version ：ファイル登録チケヅト（FRT) 発行者カテゴリ（FRT I C ) のバ一ジョン

* DUTIC— PAR (DUT Issuer Category) ：データアップデートチケット（DUT) 発行者カテゴリ

* DUTIC— PAR Version ：データアップデートチケット（DUT) 発行者カテゴリ（DUT I C) のバ一ジョン

図 22は、共通鍵系パーティション鍵情報プロヅク（Partition Key Definition Block(Common))デ一夕構成を示す。共通鍵系パーティション鍵情報ブロック (Partition Key Definition Block (Common)) には以下のデ一夕が格納される。

* Mkauth_PAR_A Pointer ：双方向個別鍵認証用マスタ一鍵（MKauth— PAR— A)のポインタ

* Mkauth_PAR_A Size：双方向個別鍵認証用マスタ一鍵（MKauth_PAR— A)のサイズ * Kauth_PAR_B Pointer ：双方向個別鍵認証用鍵（Kauth_PAR— B)のポインタ

* Kauth_PAR_B Size ：双方向個別鍵認証用鍵（Kauth_PAR— B)のサイズ

* Kfrt Pointer ：ファイル登録チケット（FRT) の M A C検証用鍵（Kf rt)が格納されているブロックへのポインタ

* Kfrt Size：ファイル登録チケット（FRT) の M A C検証用鍵（Kfrt)のサイズ

* Kdut_PAill- 4 Pointer：データアップデートチケット（DUT) の MAC検証用鍵（Kdut)が格納されているプロックへのポインタ

* Kdut_PARl-4 Size ：データアップデ一トチケット（DUT) の MAC検証用鍵（Kdut)のサイズ

* IRL_PAR Pointer ：パーティション（Partition) の排除デバイスの I Dを格納したリポケ一シヨンリスト（Revocation List— Device ID)が格納されているブロックへのポインタ

* IRL— PAR Size ：パーティション（Partition) のリボケ一シヨンリスト (Revocation List-Device ID)のサイズ上述のデータ中に示される双方向個別鍵認証の方法、 MA C ( Message Authenticate Code) 検証処理については、後段で詳細に説明する。

また、 Kdut— PAR は 4種類存在し、 (Kdut_PARl, Kdut— PAR2), (Kdut_PAR3, Kdut_PAR4)のペアで使われる。例えば、 Kdut_PARl， 3は MAC生成用、 Kdut_PAR2，は暗号用に使われる。

図 23は、パーティション鍵領域（Partition Key Area) のデータ構成を示す。パーティション鍵領域（Partition Key Area) には以下のデータが格納される。なお、パーティション鍵領域（Partition Key Area) の各格納鍵には、バ一ジョン情報が併せて格納される。鍵の更新時には、バージョンについても併せて更新される。

* IRL_PAR ：パーティションアクセス排除デバイス（Device)、排除機器（デバイスアクセス機器としてのリーダライタ、 P C等のチケットユーザ、チケット発行手段）の識別子（ I D) を登録したリボケーシヨンリスト（Revocation List (Device ID))

* CRL_PAR ：パーティションアクセス排除デバイス（Device)、排除機器（デバイスアクセス機器としてのリーダライタ、 P C等のチケットユーザ、チケット発行手段）の公開鍵証明書識別子（ex. シリアルナンパ： SN) を登録したリボケーシヨンリス卜 (Revocation List (Certificate)

* Kdut_PARl ：データアップデートチケット（DUT) の MAC検証用鍵 * Kdut_PAR2 ：データ更新用暗号鍵

* Kdut_PAR3 ：データアップデートチケット（DUT) の MAC検証用鍵

* Kdut_PAR4 ：データ更新用暗号鍵

* Kfrt ：ファイル登録チケット（FRT) の MAC検証用鍵

* CERT_PAR：認証局 C A (PAR) が発行したパーティション（Partition) の公開鍵証明書

* PRI_PAR ：パーティション（Partition) の秘密鍵

* PARAM_PAR ：パーティション（Partition) の公開鍵パラメ一夕

* PUB_CA(PAR) ：認証局 C A (PAR) の公開鍵

* Mkauth_PAR_A ：双方向個別鍵認証用マスタ一鍵 * Kauth_PAR_B ：双方向個別鍵認証用共通鍵

図 24は、ファイル定義ブロック（ F D B ： File DefinitionBlock) のデータ構成を示す。ファイル定義ブロック（File DefinitionBlock) には以下のデータが格納される。

* File ID ：ファイル（File) 識別名

* File Start Position ：ファイル（File) スタートアドレス

* File Size ：ファイル（File) サイズ

* SPTIC (SPT Issuer Category) ：サ一ビス許可チケット（ S P T) 発行者カテゴリ

* SPTIC Version ：サービス許可チケット（S PT) 発行者カテゴリ（SPTIC) のバ一ジョン

* File Structure Type Code ：ファイル構造タイプ（File Structure Type) のコード

* Acceptable Authentication Type ：許容認証タイプを示す。各ファイル構造タイプ（File Structure Type) に対して定義されるアクセスモードとこのフィ一ルドの各ビット（本例では最大 1 6個）が対応する。詳細は下記に説明する。

* Acceptable Verification Type:許容検証タイプを示す。各ファイル構造夕ィプ（File Structure Type) に対して、定義されるアクセスモードとこのフィ一ルドの各ビット（本例では最大 1 6個）が対応する。詳細は下記に説明する。

* Kspt ：サ一ビス許可チケット（S PT) の MA C検証用鍵（Kspt)

上記の許容認証タイプ（Acceptable Authentication Type) は、各ファイル構造タイプ（File Structure Type) に対して定義されるアクセスモードとこのフィ —ルドの各ビット（本例では最大 1 6個）が対応するように設定された許容認証タイプであり、例えばあるアクセスモードを実行する際に、そのモードに対応するビットに 1がたつている場合には、公開鍵認証が済んで認証済みでないと実行されれないものとする。これにより、より重要度の高いコマンド（例えば入金処理など）の実行の際には、公開鍵認証を義務づけ、安全性を確保できる。チケットを用いることで同様の制御も可能ではあるが、許容認証タイプ（Acceptable Authentication Type) は、チケットと異なり、フアイル定義プロック（ F D B ： Fi le Def inition Block) の一部としてデバイスに格納されることになるため、この情報はファイル生成後に変更されることがない。従って、絶対に許容認証タイプの変更を許さない強い制約を与えたいときに利用することにより、安全性の最低限の保証を与えることができる。

また上記の許容検証タイプ（Acceptable Verifi cation Type) は、各ファイル構造タイプ（Fi le Structure Type) に対して定義されるアクセスモードとこのフィ一ルドの各ビット（本例では最大 1 6個）が対応するように設定された許容検証タイプであり、例えばあるアクセスモードを実行する際に、そのモードに対応するビットに 1がたつている場合には、公開鍵方式によるチケット検証が済んでないと実行されれないものとする。この例では、各フィールドを 2バイトづつにしたため、最大 1 6個のアクセスモードとの対応付けしかできないが、必要に応じてフィ一ルドサイズを大きくとることにより、より多くのコマンドに対応付ける構成とすることができる。

また、本実施例構成においては、許容認証タイプ（Acceptabl e Authentication Type), 許容検証タイプ（Acceptable Verif ication Type) は設定が「 1」のときに公開鍵方式の認証または検証を必要とする設定としてあるが、これらの各フィ一ルドを 2ビット単位の構成として、値が「 1 1」の場合には公開鍵方式、「 0 1」の場合には共通鍵方式、「0 0」「 1 0」の場合には公開鍵方式、共通鍵方式のいずれでもは許容する、などの細分化した設定としてもよい。

上述のデータ中のファイル構造タイプ（Fi le Structure Type) は、パーティション内に生成されるファイルの構造を示すコ一ドである。ファイル構造とコ一ドの対応の一例を図 2 5に示す。

ファイル構造には、図 2 5に示す各種構造（F i l e Structure) があり、それそれにコード 0 0 0 1〜 0 0 0 7が割り当てられる。各構造の意味を以下に示す。

* Random ：本ファイル構造を持つデータはすべての読書きがランダムに可能なフアイルである。

* Purse：本ファイル構造を持つデータは、金額情報データであり、減算（Sub)、加算（Add) など金額の価値変更処理が可能であるデ一夕ファイルである。

* Cycl i c ：本ファイル構造を持つデ一夕は循環型（Cycl i c) のデータ書き込みが可能なファイル構造である。

* Log：本ファイル構造を持つデ一夕は、ログデータファイルであり、各データ処理情報についての記録情報ファイルである。

* Key：本ファイル構造を持つデータファイルは、鍵情報ファイルであることを示す。

*複合ファイル：上記各種ファイル構造の複合構造（E x . Purseと Log) を持つファイルである。複合ファイルには、その組み合わせパターンにより異なるコ ―ド（図では 0 0 0 6 :複合ファイル 1、 0 0 0 7 :複合ファイル 2 ) が割り当てられる。

以上、デバイスのメモリ部に格納されるデータについて説明した。これらのデ —夕を用いた具体的な処理については、後段で説明する。

[ A 8 . 各チケットのデ一タフォ一マット ]

前述したように、デバイスに対するパーティションの設定登録処理には、正当なチケット発行手段（Ticket Issuer)の発行したパ一テイション登録チケット（P R T ： Partition Regi stration Ticket), デバイスに設定されたパーティション内に対するフアイルの設定登録処理には、正当なチケット発行手段（Ticket Issuer) の発行したファイル登録チケット（ F R T ： Fi le Regi stration Ticket)、また、各ファイルに対するアクセスには正当なチケット発行手段（Ticket I ssuer) の発行したサービス許可チケット（ S P T ： Service Permi ssion Ticket) が必要となる。また、前述のデバイスのメモリ部のデータ説明の欄で簡単に説明したように、デバイス格納データの更新処理にはデータアップデートチケット（D U T ) を必要とする。

これらの各チケットはデバイスに対するアクセスルールをバイナリデータとして記述したデータ列によって構成される。チケットはデバイスに対する処理に応じて、チケットユーザである例えばデバイスアクセス機器としてのリーダライタからデバイスに送信される。チケットを受信したデバイスはチケットの正当性検証処理を実行し、正当性検証に成功した場合、チケットに記録されたルールに従つて各種の処理（e x . パーティション生成、ファイル生成、データアクセス）が実行される。以下、これらの各チケットのデータフォーマットについて説明する。

(A 8. 1. パーティション登録チケット（PR T))

パーティション登録チケット（ P R Τ ： Partition Registration Ticket) は、デバイスに対するパーティションの設定登録処理の際に適用されるアクセスコントロールチケットである。正当なデバイスマネージャ管轄下のチケット発行手段 (Ticket Issuer) の発行した PRTを用い、 P R Tに記録された手続きに従って、パーティションマネージャの管轄下のチケットユーザ（ex. デバイスアクセス機器としてのリーダライタ）によりデバイスにアクセスすることで、 PRTに記録された制限内でパーティシヨンを設定することができる。

図 2 6にパーティション登録チケット（ P R T ： Partition Registration Ticket) のデ一夕フォーマットを示す。パ一テイション登録チケット（ P R T ： Partition Registration Ticket) には以下に説明するデータが格納される。

* Ticket Type ：チケヅト（Ticket) の種別。

* Format Version ：チケット（Ticket) のフォーマットバージョン

* Ticket Issuer ：デバイスマネージャの識別子（ = DMC)

* Serial Number ：チケット（Ticket) のシリアル番号

* Size of Ticket ：チケヅト（Ticket) のサイズ

* Authentication Flag ：チケヅト（Ticket) の利用処理においてデバイス (Device) との相互認証が必要か否かを示すフラグ

* Ticket User の所属（Group) ：チケット（Ticket) 利用者の所属

* Authentication Type：デパイス（Device) の相互認証のタイプ（公開鍵認証、または、共通鍵認証、または、いずれでも可（Any))

* Ticket Userの識別子：チケット（Ticket) 利用者を判別する識別データ（力テゴリまたは識別子）

当フィールドは、 [ Authentication Type ] と連携したデータとされ、 [Authentication Type]が公開鍵認証の場合：識別名（ D N： Distinguished Name) またはカテゴリ（Category) またはシリアル番号（SN) が格納され，共通鍵認証の場合、：認証 I Dが格納される。認証不要の場合は格納は必須ではない。

* PMC:パーティションマネ一ジャコード（Partition Manager Code) として、パーティション定義ブロック（Partition Definition Block) に記述されるコ一 K

* PMC Version ：パ一ティションマネージヤコ一ド（PMC) のバ一ジョン

' * Operation Type ：パーティション（Partition) 作成か削除かの指定（作成 (Generate) / 削除（Delete))

* Partition Size ：パ一テイシヨン（Partition) のサイズ

* Integrity Check Type ：チケット（Ticket) の正当性検証値の種別（公開鍵方式（Public) /共通鍵方式（Common))

* Integrity Check Value ：チケット（Ticket) の正当性検証値（公開鍵方式：署名（Signature) 共通鍵方式： MAC)

なお、パ一テイション登録チケット（P R T) 発行手段（PRT Issuer) の発行したチケット（Ticket) を、チケットユーザに対して送信する際には、公開鍵方式の場合、パーティション登録チケット（PRT) 発行手段（PRT Issuer) の公開鍵証明書（CERT_PRTI) も一緒に送信する。 P R T発行手段の公開鍵証明書 (CERT_PRTI) の属性（Attribute) は、 PRT発行手段（PRT Issuer) の識別子（PRTIC)と一致する。

デバイス（Device) の相互認証のタイプ（公開鍵認証、または、共通鍵認証、または、いずれでも可（Any)) を記録した [Authentication Type] には、チケットを使用した相互認証として実行すべき認証タイプが記録される。具体的には、後段で詳細に説明するが、デバイス認証、パーティション認証のいずれか、または両方の認証を実行する指定、また公開鍵方式、共通鍵方式のどちらを実行するか、またはいずれの認証でも可能であるかについての情報が記録される。

チケット（Ticket) の正当性検証値（公開鍵方式：署名（Signature) 共通鍵方式： MAC) を記録する [Integrity Check Value] フィールドには、公開鍵方式であれば、パーティション登録チケット発行手段（PR T Issuer)の秘密鍵に基づく署名（図 1 2参照）が生成され格納される。デバイスマネージャ自体がパ —ティシヨン登録チケット発行手段（PRT Issuer) を兼ねる場合は、デバイスマネージャの秘密鍵を用いて署名が生成される。署名検証処理（図 1 3参照）の際は、対応の C A (D E V) の公開鍵が用いられる。従って、チケット検証を実行するデバイスは、チケット受領に際し、または前もってパーティション登録チケット発行手段（PRT Issuer) (ex. デバイスマネージャ）の公開鍵（公開鍵証明書）を取得することが必要である。

パーティション登録チケット（PRT) 発行手段（PRT Issuer) の公開鍵証明書（CERT_PRTI) の検証の後、公開鍵証明書（CERT_PRTI) から取り出したパ一テイション登録チケヅト（P RT) 発行手段（PRT Issuer) の公開鍵により I C V (Integrity Check Value) の署名検証が可能となる。これらの処理については、フローを用いて後段で説明する。

(A 8. 2. ファイル登録チケット（FRT))

ファイル登録チケット（ F R T ： File Registration Ticket) は、デバイスに対して設定されたパーティシヨンにファイルを設定登録する際に適用されるァクセスコントロールチケヅトである。正当なパ一ティションマネージャ管轄下のチケット発行手段（Ticket Issuer) の発行した FRTを用い、 FRTに記録された手続きに従ってチケットユーザ（ex. デバイスアクセス機器としてのリ一ダライタ）によりデバイスにアクセスすることで、 F R Tに記録された制限内でファィルを設定することができる。

図 27にフアイル登録チケット（ F R T ： File Registration Ticket) のデ一夕フォーマットを示す。ファイル登録チケット（F R T : File Registration Ticket) には以下に説明するデータが格納される。

* Ticket Type ：チケット（Ticket) の種別

* Format Version ：チケット (Ticket) のフォ一マツ卜ノ一ジョン

* Ticket Issuer ：パーティションマネージャの識別子（=PMC)

* Serial Number ：チケット（Ticket) のシリアル番号

* Size of Ticket ：チケット（Ticket) のサイズ

* Authentication Flag ：チケット（Ticket) の利用処理においてデバイス (Device) との相互認証が必要か否かを示すフラグ

* Ticket User の所属（Group) ：チケット（Ticket) 利用者の所属

* Authentication Type：デバイス（Device) の相互認証のタイプ（公閧鍵認証、または、共通鍵認証、または、いずれでも可（Any)) * Ticket Userの識別子：チケット（Ticket) 利用者を判別する識別デ一夕（力テゴリまたは識別子）

当フィールドは、 [ Authentication Type ] と連携したデータとされ、 [Authentication Type]が公開鍵認証の場合：識別名 (D N： Distinguished Name) またはカテゴリ（Category) またはシリアル番号（CN) が格納され，共通鍵認証の場合、：認証 I Dが格納される。認証不要の場合は格納は必須ではない。

* SPTIC ：サービス許可チケット発行手段のコード

* SPTIC Ver ：サービス許可チケット発行手段のコード（SPTIC) のバージョン

* File ID ：パ一ティション内に生成するファイル（File) の識別子（ I D) * Operation Type ：ファイルの作成か削除かの指定（生成（Generate) /削除

(Delete) )

* File Size ：生成するファイル（File) のサイズ

* File Structure ：生成するファイル（File) のファイル構造（Structure)

* Acceptable Authentication Type ：このチケヅトで定義されるファイルに対するアクセスモ一ドを実行する夕ために必要とする相互認証の種類（公開鍵方式、公開鍵、共通鍵いずれでも可）を表すビット列

* Acceptable Verification Type ：このチケヅトで定義されるフアイルに対するアクセスモ一ドを実行する夕ために必要とするサービス許可チケット（S P T) の検証の種類（公開鍵方式、公開鍵、共通鍵いずれでも可）を表すビット列

* Kspt_Encrypted ：ファイル定義ブロック（File Definition Block) に記載されるサ一ビス許可チケット（S P T) の M A C検証用鍵 Ksptをそのパ一テイシヨンのファイル登録チケットの MAC検証用鍵 Kfrt で暗号化したデータ Kfrt (Kspt)

* Integrity Check Value ：チケット（Ticket) の正当性検証値（公開鍵方式：署名（Signature), 共通鍵方式： MAC)

なお、ファイル登録チケット（FRT) 発行手段（FRT Issuer) の発行したチケヅト（Ticket) を、チケットユーザに対して送信する際には、公開鍵方式の場合、ファイル登録チケット（FR T) 発行手段（FRT Issuer) の公開鍵証明書 (CERT_FRTI) も一緒に送信する。 F R T発行手段の公開鍵証明書（CERT_FRTI) の属性（Attribute)は、ファイル登録チケット（F R T)発行手段（F R T Issuer) の識別子（FRTIC)と一致する。

チケット（Ticket) の正当性検証値（公開鍵方式：署名（Signature) 共通鍵方式： MAC) を記録する [Integrity Check Value] フィ一ルドには、公開鍵方式であれば、ファイル登録チケット発行手段（FRT Issuer)の秘密鍵に基づく署名（図 1 2参照）が生成され格納される。パーティションマネージャ自体がフアイル登録チケット発行手段（FRT issuer) を兼ねる場合は、パーティションマネージャの秘密鍵を用いて署名が生成される。署名検証処理（図 1 3参照）の際は、ファイル登録チケット発行手段の公開鍵が用いられる。従って、チケット検証を実行するデバイスは、チケット受領に際し、または前もってファイル登録チケット発行手段（ F R T Issuer) (ex. パーティションマネージャ）の公開鍵（公開鍵証明書）を取得することが必要である。

フアイル登録チケット（ F R T ) 発行手段（FRT Issuer) の公開鍵証明書 (CERT_FRTI) の検証の後、公開鍵証明書（CERT_FRTI) から取り出したファイル登録チケット（FRT)発行手段（FRT Issuer)の公開鍵により I C V (Integrity Check Value) の署名検証が可能となる。これらの処理については、フローを用いて後段で説明する。

(A 8. 3. サービス許可チケット（S P T))

サービス許可チケット（ S P T ： Service Permission Ticket) は、デパイスに対して設定されたパーティション内の各デ一夕に対してアクセスしてデータ読み出し、データ書き込み、金額データの減算、加算などの処理を実行する際に適用されるアクセスコントロールチケットである。正当なパーティションマネージャ管轄下のチケヅト発行手段（Ticket Issuer) の発行した S P Tを用い、 S PTに記録された手続きに従ってチケットユーザ（ex. デバイスアクセス機器としてのリーダライタ）によりデバイスにアクセスすることで、 S PTに記録された制限内でデータ処理を実行することができる。

なお、サービス許可チケット（ S P T ： Service Permission Ticket) は、パ一ティションに設定されたファィルの中から唯一.のフアイルに対してのみアクセスを許可する形式と、複数のファイルに対するアクセスを許可する形式とがあり、それそれの形式について説明する。

図 28に、パーティションに設定されたファイルの中から唯一のファイルに対してのみアクセスを許可する形式のサービス許可チケット（S P T ： Service Permission Ticket) のデータフォ一マットを示す。サ一ビス許可チケヅト（ S P T ： Service Permission Ticket) には以下に説明するデータが格納される。

* Ticket Type ：チケット（Ticket) の種別。

* Format Version ：チケット（Ticket) のフォーマツ卜ノ一ジョン

* Ticket Issuer ：パ一ティションマネージャの識別子（二 PMC)

* Serial Number ：チケット（Ticket) のシリアル番号

* Size of Ticket ：チケット（Ticket) のサイズ

* Ticket User の所属（Group) ：チケット（Ticket) 利用者の所属

* Authentication Type：デバイス（Device) の相互認証のタイプ（公開鍵認証、または、共通鍵認証、または、いずれでも可（Any))

当フィールドは、 [ Authentication Type ] と連携したデータとされ、 [Authentication Type]が公開鍵認証の場合：識別名（ D N： Distinguished Name) またはカテゴリ（Category) またはシリアル番号（CN) が格納され，共通鍵認証の場合、：認証 I Dが格納される。認証不要の場合は格納は必須ではない。 * File ID ：パーティション内のアクセスファイル（File) の識別子（ I D)

* File Access Mode ：アクセスを許諾するファイル（File) へのアクセスモード (Access Mode)

なお、サービス許可チケット（S P T) 発行手段（SPT Issuer) の発行したチケット（Ticket) を、チケットユーザに対して送信する際には、公開鍵方式の場合、サービス許可チケット（S P T) 発行手段（SPT Issuer) の公開鍵証明書 (CERT_SPTI) も一緒に送信する。 S P T発行手段の公開鍵証明書（CERT_SPTI) の属性（Attribute) は、（S PT) 発行手段（SPT Issuer) の識別子（SPTIC)と一致する。

サービス許可チケット（ S P T) 発行手段（SPT Issuer) を、パーティションマネージャが兼ねる構成においては、サービス許可チケット（SP T) 発行手段 (SPT Issuer) のコ一ドは、パ一ティションマネ一ジヤコ一ド（PMC) として設定することが可能である。

チケット（Ticket) の正当性検証値（公開鍵方式：署名（Signature) 共通鍵方式： MAC) を記録する [Integrity Check Value] フィールドには、公開鍵方式であれば、サービス許可チケット発行手段（ S P T Issuer)の秘密鍵に基づく署名（図 1 2参照）が生成され格納される。パーティションマネージャ自体がサ一ビス許可チケヅト発行手段（S P T Issuer) を兼ねる場合は、パーティシヨンマネージャの秘密鍵を用いて署名が生成される。署名検証処理（図 1 3参照）の際は、サービス許可チケット（S PT) 発行手段（SPT Issuer) の公開鍵が用いられる。従って、チケット検証を実行するデバイスは、チケット受領に際し、または前もってサービス許可チケット発行手段（S PT Issuer) (ex. パーティシヨンマネージャ）の公開鍵（公開鍵証明書）を取得することが必要である。サービス許可チケット（ S P T ) 発行手段（SPT Issuer) の公開鍵証明書 (CERT_SPTI) の検証の後、公開鍵証明書（CERT_SPTI) から取り出したサービス許可チケット（ S P T)発行手段（SPT Issuer)の公開鍵により I C V (Integrity Check Value) の署名検証が可能となる。これらの処理については、フローを用いて後段で説明する。

上述のチケット · フォーマツトの説明中、 File Access Mode ：アクセスを許諾するファイル（File) へのアクセスモード（Access Mode) に記録されるモードとアクセス態様について、図 29を用いて説明する。

ファイルとして生成されるデ一夕は、ユーザの識別データ、金額データ、暗号処理鍵データ、ログデータ、あるいは複合ファイルデータなど様々であり、各デ —夕に応じたアクセス処理、すなわちデータ読み取り、書き込み、消去、加算、減算、暗号化、復号…がアクセスデ一夕に対して実行されることになる。

サービス許可チケット（ S P T) の File Access Modeには、このような様々なアクセスの態様中、いずれのアクセスモードを許可しているものかを定義している。アクセスモードの一覧を図 2 9に示す。図 29に示すアクセスモードは一例であり、この他にもデバイスに格納されるデータに応じたアクセスモードを設定することができる。

サービス許可チケット（SPT) に設定された [File ID：パーティション内の -アクセスファイル（File) の識別子（ I D)] によって示されるファイルに対してファイルアクセスモード [File Access Mode] に定義された処理が実行できる。サービス許可チケット（S PT) に設定されたファイルアクセスモードが読み出し（Read) であればファイル内データの読み出しが実行できる。サービス許可チケット（S PT) に設定されたファイルアクセスモードが書き込み（Write) であればファイル内へのデータの書き込みが実行できる。

このようなアクセスモードは、前述したファイル構造（File Structure) (図 2 5参照）によって設定可能なモードが制限される。例えばファイル構造が purse であれば金額データであり、加算（add)、減算（Sub) 等のアクセスモードの設定が可能となる。このようなファイル構造と、設定可能なアクセスモード、さらに、デバイスアクセス機器としてのリーダライタからデバイスに対して送信されるコマンドの例を図 30に示す。

図 30には、ファイル構造が R a n d o mの場合と、複合ファイルの場合に設定可能なアクセスモード、およびコマンド例を示している。

例えばファイル構造が R a nd o mの場合において、アクセスモ一ドが読み出し（R e a d) である場合、デバイスが許容可能なコマンドは [R e ad] のみとなる。また、同様にファイル構造が R a n d o mの場合において、アクセスモ —ドが暗号化読み出し（R e a d) である場合、デバイスが許容可能なコマンドは暗号化読み出し [E n c R e a d] のみとなる。

また、ファイル構造が Purseおよび Logを含むような複合ファイルの場合において、アクセスモードが入金系である場合、デバイスが許容可能なコマンドは預け入れ [D e p o s i t] のみとなる。また、同様にファイル構造が Purseおよび Logを含むような複合ファイルの場合において、アクセスモ一ドが出金系である場合、デバイスが許容可能なコマンドは引き出し [Wi t hd r aw], レシ一ト生成 [Mak e R e c e i p t ]、レシート読み出し [ R e a d Re c e i P t ] となる。

ファイルアクセスモード（図 2 9参照）の入金系に対応する許容コマンド（図 30参照）として、上述の預け入れコマンド（Deposit Co匪 and) を定義し、ァクセス許可チケットのファイルアクセスモード（File Access Mode) に [入金系] を設定し、ファイル I D(File ID)として、電子マネーを構成する複合ファイルを指定したアクセス許可チケット（S P T) を生成して、ファイルアクセス装置からデパイスに対して送信し、預け入れコマンド（Deposit Command) とともに、預け入れ金額デ一夕を送信することにより、例えば、複合ファイル中のファイル [P u r s e ] に X円を加算し、複合ファイル中のファイル [L o g] に処理記録を書き込むなどのシーケンシャル処理を実行させることが可能となる。これらの処理についての詳細は、後述する。図 30に示す他にも、様々なアクセスモード、コマンドの組合わせが可能であり、実際のデバイスの利用形態に応じて設定されることになる。

デバイスは、メモリ部に格納された各ファイルに対して許容されるコマンドの定義データを図 3 0のようなテ一ブルとして保有し、前記アクセス機器から入力されるコマンドが前記定義データに定義されたコマンドである場合にのみコマンドを実行する。複合ファイルに対して許容されるコマンドの定義データには、上述したように複合ファイルに含まれる複数ファイルの各々に対応して実行可能な複数のコマンドからなるシーケンスコマンドを含む。

処理対象となる特定のファイルをサービス許可チケット（S P T) のファイル I D(File ID)欄に設定し、所定のアクセスモ一ドをサ一ビス許可チケヅト（S P T) のファイルアクセスモード（File Access Mode) に設定することで、当該サ —ビス許可チケット（S P T) を利用したファイルアクセスをコントロールすることが可能となる。具体的処理については、後段でフローを用いて説明する。次に、図 3 1に、パーティションに設定されたファイル中の複数ファイルに対してアクセスを許可する形式のサービス許可チケット（ S P T ： Service Permission Ticket) のデ一タフォ一マットを示す。サービス許可チケット（S P T ： Service Permission Ticket) には以下に説明するデ一夕が格納される。

* Ticket Type ：チケット（Ticket) の種別。

* Format Version ：チケット (Ticket) のフォ一マットノ、'一ジョン

* Ticket Issuer ：パ一ティションマネージャの識別子（=PMC)

* Serial Number ：チケット（Ticket) のシリアル番号

* Size of Ticket ：チケヅト（Ticket) のサイズ

* Ticket User の所属（Group) ：チケット（Ticket) 利用者の所属

* Authentication Type ：デバイス（Device) の相互認証のタイプ（公開鍵認証、または、共通鍵認証、または、いずれでも可（Any))

* Ticket Userの識別子：チケット（Ticket) 利用者を判別する識別データ（力テゴリまたは識別子）当フィールドは、 [ Authentication Type ] と連携したデ一夕とされ、 [Authentication Type]が公開鍵認証の場合：識別名 (D N： Distinguished Name) またはカテゴリ（Category) が格納され，共通鍵認証の場合、：認証 I Dが格納される。認証不要の場合は格納は必須ではない。

* File ID ：パーティション内のアクセスファイル（File) の識別子（I D)

* File Access Mode ：アクセスを許諾するファイル（File) へのアクセスモ一ド (Access Mode)

* Group of Target File：アクセスを許すファイル（File) のグループ（Group)

* Target File ID ：アクセスを許すファイル（File) の識別子（I D) * Read/Write Permission ：アクセスを許すフアイル（File) (夕一ゲットファィル（Target File)) に対する処理態様（読み出し（Read) ，書き込み（Write)) の許可

このように、 Group of Target File ：アクセスを許すファイル（File) のグル —プ（Group) を定義してチケットに記録することにより、パーティション内の複数のファイルに対するアクセスを唯一のサービス許可チケット（S PT) で許可することが可能となる。

なお、上述のサービス許可チケット（S PT) 発行手段（SPT Issuer) の発行したチケット（Ticket) を、チケットユーザに対して送信する際にも、公開鍵方式の場合、サービス許可チケット（S PT) 発行手段（SPT Issuer) の公開鍵証明書（CERT_SPTI)も一緒に送信する。 S P T発行手段の公開鍵証明書（CERT_SPTI) の属性（Attribute) は、サービス許可チケット（S P T)発行手段（SPT Issuer) の識別子（SPTIC)と一致する。

サービス許可チケット（ S P T) 発行手段（SPT Issuer) の公開鍵証明書 (CERT_SPTI) の検証の後、公開鍵証明書（CERT— SPTI) から取り出したサービス許可チケット（ S P T)発行手段（SPT Issuer)の公開鍵により I C V (Integrity Check Value) の署名検証が可能となる。これらの処理については、フロ一を用いて後段で説明する。

(A 8. 4. データアップデートチケット（DUT))

デ一夕アップデートチケット（D U T ： Data Update Ticket) は、デバイスに格納された様々なデータに対してアクセスしてデータの更新処理を実行する際に適用されるアクセスコントロールチケットである。正当なデ一夕アップデ一トチケット（D U T ) 発行手段（Ticket Issuer) の発行した D U Tを用い、 D U Tに記録された手続きに従ってチケットユーザ（e x. デバイスアクセス機器としてのリーダライタ）によりデバイスにアクセスすることで、 DUTに記録された制限内でデータ処理を実行することができる。

なお、データアップデートチケット（DUT ： Data Update Ticket) は、デバイスマネージャの管理するデータ項目の更新処理を実行するために適用されるチケット DUT (D E V) と、パーティションマネージャの管理するパ一ティション内のデータ項目の更新処理を実行するために適用されるチケット DUT (P A R) がある。チケット： DUT (D E V) 発行手段はデパイスマネージャの管理下にあり、チケット： DUT (PAR) 発行手段はパーティシヨンマネージャの管理下にある。

図 32に、 2つのデータアップデートチケット（DUT ： Data Update Ticket)、 DUT (DE V), DUT (PAR) のデ一夕フォーマツトを示す。データアップデートチケット（DUT ： Data Update Ticket) には以下に説明するデータが格納される。

* Ticket Type：チケヅト（Ticket) の種別（DUT (DEV) /DUT (P A R) * Format Version ：チケット (Ticket) のフォ一マットノヽ'一ジョン

* Ticket Issuer ：デパイス/パーティションマネージャの識別子。チケット (Ticket) の種別（Ticket Type) が DUT (D E V) なら DMC、 D U T (PA

R) なら PMCとなる

* Serial Number ：チケット（Ticket) のシリアル番号

* Size of Ticket ：チケット（Ticket) のサイズ

* Ticket User の所属（Group) ：チケット（Ticket) 利用者の所属

当フィールドは、 [ Authentication Type ] と連携したデータとされ、 [Authentication Type]が公開鍵認証の場合：識別名（ D N： Distinguished Name) またはカテゴリ（Category) が格納され，共通鍵認証の場合、：認証 I Dが格納される。認証不要の場合は格納は必須ではない。

* Encrypted Flag ：更新されるデータが暗号化されているか否か（暗号化： Encrypted /非暗号ィ匕： none)

* Old Data Code ：更新される古いデータのコード（Code)

* Data Version Rule ：デ一夕更新をする時のバ一ジョン条件

* Data Version Condition ：デ一夕更新をする時のバ一ジョン値

* Size of New Data ：更新する新しいデータのサイズ

* New Data ：更新する新しいデータ（暗号化される場合もある）。

* New Data Version ：更新するデータのバ一ジョン

* Integrity Check Value ：チケヅト（Ticket) の正当性検証値（公開鍵方式：署名（Signature) 共通鍵方式： MAC)

データアップデートチケット（DUT : Data Update Ticket) を適用したデー夕更新をする際に、 [Data Version Rule：データ更新をする時のバージョン条件] と、 [Data Version Condition ：デ一夕更新をする時のパージヨン値]、これら 2 つのフィ一ルドの組み合わせにより条件を表現する。

データ更新をする時のバージョン条件 [Data Version Rule] は、 Any, Exact, Older の 3種類が存在する。

Any はバ一ジョン（Version) 条件に無関係でデータ更新が可能、

Exactは、続く [Data Version Condition ] に指定された値と同じ場合にデ一タ更新が可能、

Olderは、 New Data Versionの方が新しい場合にのみデータ更新が可能となる _c なお、バ一ジョン条件 [Data Version Rule]が Any,または Olderの場合は、 [Data Version Condition] は使用しないかもしくは無視する。

デバイス（Device) の相互認証のタイプ（公開鍵認証、または、共通鍵認証、または、いずれでも可（Any)) を記録した [Authentication Type] には、チケヅトを使用した相互認証として実行すべき認証タイプが記録される。具体的には、後段で詳細に説明するが、デバイス認証、パーティション認証のいずれか、または両方の認証を実行する指定、また公開鍵方式、共通鍵方式のどちらを実行するか、またはいずれの認証でも可能であるかについての情報が記録される。

データアップデ一トチケット- DUT (D E V) 発行手段（DUT Issuer) を、デバイスマネージャが兼ねる構成においては、データアップデートチケットー D U T (DEV) 発行手段（DUT Issuer) のコード（チケットュ一ザ（Ticket User)) は、デパイスマネージャコード（DMC) として設定することが可能である。また、データアップデ一トチケット- DUT (PAR) 発行手段（DUT Issuer) を、パ一ティションマネージャが兼ねる構成においては、デ一夕アップデートチケット— DUT (PAR) 発行手段（DUT Issuer) のコードは、パーティションマネージャコード（PMC) として設定することが可能である。

デバイス（Device) の相互認証のタイプ（公開鍵認証、または、共通鍵認証、または、いずれでも可（Any)) を記録した [Authentication Type] には、チケットを使用した相互認証として実行すべき認証夕ィプが記録される。具体的には、後段で詳細に説明するが、デバイス認証、パーティション認証のいずれか、または両方の認証を実行する指定、また公開鍵方式、共通鍵方式のどちらを実行するか、またはいずれの認証でも可能であるかについての情報が記録される。

チケット（Ticket) の正当性検証値（公開鍵方式：署名（Signature) 共通鍵方式： MAC) を記録する [Integrity Check Value] フィールドには、公開鍵方式であれば、デバイスアップデ一トチケット発行手段（DUT Issuer)の秘密鍵に基づく署名（図 1 2参照）が生成され格納される。デパイスマネージャ自体がデバイスアップデート登録チケット発行手段（DUT Issuer)を兼ねる場合は、デバイスマネージャの秘密鍵を用いて署名が生成される。また、パーティションマネージャ自体がデバイスアップデ一ト登録チケット発行手段（DUT Issuer) を兼ねる場合は一ティションマネージャの秘密鍵を用いて署名が生成される。この場合、署名検証処理（図 1 3参照）の際は、デバイスマネージャまたはパ一ティションマネージャの公開鍵が用いられる。従って、チケット検証を実行するデバイスは、チケット受領に際し、または前もってデバイスアップデートチケット発行手段（DUT issuer) (ex. デパイスマネージャまたはパーティションマネージャ）の公開鍵（公開鍵証明書）を取得することが必要である。

デバイスアップデートチケット（DUT) 発行手段（DUT Issuer) の公開鍵証明書（CERT_DUTI) の検証の後、公開鍵証明書（CERT_DUTI) から取り出したデ一夕アップデ一トチケット（DUT) 発行手段（DUT Issuer) の公開鍵により I C V (Integrity Check Value) の署名検証が可能となる。

デ一夕アップデートチケット（D U T ： Data Update Ticket) を適用して更新されるデータ例を図 33に示す。

図 33に示すように更新対象データには、デバイスマネージャコード、デバイスマネージャコードバージョン、パーティションマネージャコード、パ一テイシヨンマネージャコードバージョン、各チケット発行手段コード、各チケットの M A C生成鍵およびバ一ジョン、リボケ一シヨンリストなどが含まれる。これら更新対象の各デ一夕がデータアップデートチケット（D U T ： Data Update Ticket) を適用して、 D U Tに記録されたルールに従って更新される。更新処理の具体的手順については、後段でフロ一を用いて説明する。なお、デバイスマネージヤコ ―ドハ'一ジョン、パーティションマネージヤコ一ドバ一ジョン他のバ一ジョン情報は、各パージョンの付加されたデータの更新処理の際に併せて更新されることになる。これらのパージヨン情報はデータアップデートチケット（DUT : Data Update Ticket) に格納される。

[B . ユーザに対するデバイスの配布、デバイスに対する各種設定、デバイス利用処理の詳細についての説明]

次に、上述したパーティション分割されたメモリ領域を持つデバイスの利用に至るまでの処理、さらにデバイスの利用処理の詳細についてフ口一チャート他の図面を参照しながら説明する。説明の手順は以下の項目に従って行なう。

B 1. デバイス初期登録から利用までの流れ

B 2. デバイス製造エンティティによる初期登録処理

B 3. デバイスマネージャの管轄処理

B 3. 1. デパイスマネージャによるデバイス登録処理

B 4. パーティションマネージャの管轄処理

B 4. 1. パーティションマネージャ管理下におけるパーティション登録チケット（PRT) を利用したパーティション設定登録、削除処理

B 4. 2. パーティションマネージャ管理下における公開鍵証明書発行処理 B 4. 3. ファイル登録チケット（FRT) を利用したファイル生成、消去処理

B 5. サービス許可チケット（S P T) を利用したサービス（ファイルァクセス）処理

B 6. データアップデートチケット（DUT) を利用したデバイスのデ一夕更新処理

[B 1. デバイス初期登録から利用までの流れ]

E EPROM (フラッシュメモリ）を有するデバイスは、デバイス製造ェンティティ（manufacturer) によって製造され、デバイスマネージャによる初期デ一夕の書き込みが実行され、ユーザに提供（ex. 販売、貸与）され利用されることになる。ユーザが様々なサービス主体からデバイスを利用したサービスを受けるためには、デバイスのメモリ部にパーティションマネージャによるパーティションが設定され、設定されたパーティション内にサービス提供用のデータを格納したファイルが設定される必要がある。

また、デバイスに対する様々な処理、すなわちパーティシヨン登録チケット（P RT) を利用したパーティションの設定、ファイル登録チケット（FRT) を利用したファイル設定、さらにサービス許可チケット（S P T) を利用したデータアクセスなどの様々な処理の際に、デバイスとデバイスに対して処理を実行するチケットュ一ザ（ex. デバイスアクセス機器としてのリーダライ夕）との間で様々な手続きが実行される。例えば双方が正当な機器、デバイスであることを確認する相互認証処理、あるいは転送データの正当性を保証し確認するための署名生成、検証処理、さらにデータ暗号化、復号処理などである。本発明の構成では、これらの処理に際して公開鍵証明書を用いた構成を提案している。従って、デバイスによるサービスの利用の前にデバイスに対する公開鍵証明書の発行処理、デバイス格納処理を実行する。

例えばデバイスとデバイスに対して処理を実行するチケットユーザ（ex. デバイスアクセス機器としてのリーダライタ）との間で公開鍵証明書を用いた相互認証処理が実行され、双方の正当性が確認されたことを条件としてパーティション登録チケット（PRT) を利用したパーティションの設定、ファイル登録チケット（FRT) を利用したファイル設定、さらにサービス許可チケット（S PT) を利用したデータアクセスなどの様々な処理が実行される。また、相互に転送されるデータには必要に応じて電子署名が付加され、検証が実行される。また転送データの暗号化、復号処理も必要に応じて実行されることになる。

図 34は、デバイスの製造から、利用に至るまでの流れを概略的に示した図である。これらの各処理については、フローを参照して後段で詳細に説明するが、全体的な処理の理解のために、図 34に示す各段階について簡単に説明する。

1. まず、デバイスは製造エンティティ（manufacturer) によって製造される。デパイスの製造時には、各デバイスの識別デ一夕（I D) としてのデパイスコードが各デバイスに付与される。デバイスには製造段階で、デパイスコード、製造コードなど、様々の製造情報（Manufacture Information Block (図 14参照））が書き込まれデバイスのメモリに格納される。

2. 次に、デバイスマネージャはユーザに対するデパイスの提供前に、自己の 1 D、認証局の公開鍵（PUB CA (D EV))など、デバイス管理情報（Device Management Information (図 1 5参照））、デパイス鍵（Device Key (図 1 8参照））などの情報をメモリに格納する。

3. デバイスマネージャによる管理情報が書き込まれたデバイスは、ユーザに提供される。

4. 次にユーザは、デバイス対応の公開鍵証明書の取得処理を実行し、取得したデバイス対応公開鍵証明書（ C E R T D E V)をデバイスのデバイス鍵領域（図 18参照）に格納する。

5. デバイスのメモリ部にパーティションを設定し、サービスを提供しようとするサ一ビス主体（パーティションマネージャ）は、パーティションの設定をデバイスマネージャに要求し、許諾を受けるとともにパーティション登録チケット

(PRT) を受領する。また、デバイスとの通信処理において使用する認証局の公開鍵（PUB CA (PAR)) を指定する。

6. デバイスは、パ一ティションマネージャの管理するチケットュ一ザ（ex. デバイスアクセス機器としてのリーダライタ）との間で通信を実行し、パーティシヨン登録チケット（PRT) を適用したパーティションの登録処理を行なうとともに、認証局の公開鍵（PUB CA (PAR)) をパーティション鍵領域（図

23参照）格納する。

7. パーティションの設定されたデバイスは、パーティション対応公開鍵証明書の発行要求をパーティションマネージャに送信し、取得したパーティション対応公開鍵証明書（CERT PAR) をパーティション鍵領域（図 2 3参照）に格納する。

上記 5〜 7のパーティション設定他の処理は、パーティションを設定してサ一ビスを提供しょうとするパーティションマネージャ各々について実行され、複数のパーティションがデバイスに登録される。

8. 次に、パーティションマネージャは、デバイスに設定したパーティション内に、例えばサービス対応のファイルの設定登録処理をファイル登録チケヅト（ F R T) を適用して実行する。

9. 1 0. 設定されたパーテイション内にファイルが登録されることにより、例えば電子マネ一、定期券などファイル内データによって定義される各種のサ一ビスが実行可能となる。ファイル内のデータ読み取り、データ書き込みなどの処理には、サービス許可チケット（S P T ) を適用する。すなわち正当なチケット発行手段が発行したサービス許可チケット（S P T ) を適用した場合に限り、 S P Tに記録されたルールに従ってデ一夕の読み取り、書き込みなどが実行される。また、図には示されていないが、必要に応じてデ一夕アップデ一トチケット（D U T ) を使用してデバイスの格納データ中の更新処理対象データ（e x . デバイスマネージャコード、デバイスマネージャコードバージョン、パーティションマネ一ジヤコ一ド、パーティションマネージャコードバージョン、各チケット発行手段コード、各チケットの M A C生成鍵およびバージョン、リポケーシヨンリストなど）の更新処理が実行される。なお、デバイスマネージャコードバ一ジョン、パ一テイシヨンマネージヤコ一ドバ一ジョン他のバ一ジョン情報は、各バ一ジョンの付加されたデータの更新処理の際に併せて更新されることになる。これらのパージョン情報はデ一夕アツプデートチケット（D U T ： Data Update Ticket) に格納される。

以下、各処理の詳細について、フロー、その他の図を参照しながら説明する。

[ B 2 . デバイス製造エンティティによる初期登録処理]

まず、デバイス製造エンティティによる初期登録処理について、図 3 5を用いて説明する。図 3 5の左側がデバイス製造ェンティティ（Manufacture )の登録装置の処理、右側がデパイス（図 5参照）の処理を示す。なお、デパイス製造ェンティティ（Manufacture )の登録装置は、デバイスに対するデータ読み取り書き込み処理可能な専用のデパイスアクセス機器としてのリ一ダライタ（図 1 0参照）として構成される。

まず、ステップ S 1 0 1において登録装置は、デバイスに対して製造情報プロック（M I B ： Manufacture Information Block (図 1 4参照））の書き込みフラグ（Wri table Flag) の読み出しコマンドを送信する。デバイスはコマンドを受信 ( S 1 2 1 ) すると、デバイスのメモリ部の製造情報プロック（M I B ) 内の書き込み（Writable) フラグを登録装置に送信（S 1 2 2 ) する。

製造情報プロック（M I B ) 内の書き込み（Wri table) フラグを受信（S 1 0 2 ) した登録装置は、書き込みフラグ（Writable Flag) が書き込み可（ 0 x f f f f )に設定されているか否かを判別（S 1 03 )する。書き込みフラグ（Writable Flag) が書き込み可（O x f f f f ) に設定されていない場合は、以下の製造情報ブロック（M I B ： Manufacture Information Block) の書き込み処理は実行できず、エラ一として終了する。

書き込みフラグ（Writable Flag) が書き込み可（ 0 x f f f f ) に設定されている場合は、デパイスの製造情報ブロック（M I B ： Manufacture Information Block (図 1 4参照））を生成（S I 04) して MI B書き込みコマンドとともに、 M I Bデータをデバイスに送信（ S 1 05 ) する。

MI B書き込みコマンド、および M I Bデータを受信（S 1 2 3) したデパイスは、 MI B書き込みフラグ（Writable Flag) を検証（S 1 24) し、書き込みフラグ（Writable Flag) が書き込み可（ 0 x f f f f ) に設定されていない場合は、以下の製造情報ブロック（MI B ： Manufacture Information Block) の書き込み処理は実行できず、エラ一として終了する。書き込みフラグ（Writable Flag) が書き込み可（ O x f f f f ) に設定されている場合は、受信した MI Bデ一夕を M I B領域に書き込む（ S 1 25 )。

M I Bデータ書き込み処理が終了すると書き込み終了通知を登録装置に送信 ( S 1 26 ) する。書き込み終了通知を受信（S 1 06) した登録装置は初期登録完了コマンドをデバイスに送信（S 1 07 ) し、初期登録完了コマンドを受信 ( S 1 27 )したデバイスは製造情報プロック（M I B： Manufacture Information Block) の書き込みフラグ（Writable Flag) を書き込み不可（ 0 x 000 0 ) にセット（S 1 2 8) し、書き込み終了通知を登録装置に送信（S 1 2 9) する。書き込み終了通知を受信（ S 1 08 ) した登録装置は、デバイスに対して製造情報ブロック（MI B ： Manufacture Information Block (図 1 4参照））の書き込みフラグ（Writable Flag) の読み出しコマンドを送信（S 1 0 9) する。デバイスはコマンドを受信（S 1 30) すると、デバイスのメモリ部の製造情報プロック（MI B) 内の書き込みフラグ（Writable Flag) を登録装置に送信（S 1 3 1 ) する。

製造情報プロック（MI B) 内の書き込みフラグ（Writable Flag) を受信（S 1 1 0) した登録装置は、書き込みフラグ（Writable Flag) が書き込み不可（0 X 0000 ) に設定されているか否かを判別（ S 1 1 1 ) する。書き込みフラグ (Writable Flag) が書き込み不可（ 0 x 0 000 ) に設定されていない場合は、正常な M I Bデータ書き込み処理が終了していないことを示し、エラ一として処理を終了する。書き込みフラグ（Writable Flag)が書き込み不可（ 0 x 0 00 0 ) に設定されている場合は、正常な M I Bデ一夕書き込み処理が終了したものとして処理を終了する。

[B 3. デバイスマネージャの管轄処理]

次に、デバイスマネージャの管轄処理について説明する。ここでは、デバイスの使用開始以前に実行される処理について説明する。デバイスの使用開始以前に実行されるデバイスマネージャの処理としては、デバイスのメモリ部のデバィス管理情報ブロック（DMI B ： Device Management Information Block), 公閧鍵系デバイスキ一定義ブロック（DKDB ： Device Key Definition Block(PUB)), 共通鍵系デバイスキ一定義ブロック（ D K D B ： Device Key Definition Block( Common)), デバイス鍵領域（Device Key Area) に対するデータ書き込み処理として実行するデバイス登録処理と、デバイスに対してデバイス対応公開鍵証明書（CERT D E V) を発行する処理がある。以下、これらの処理の詳細について説明する。

[B 3. 1. デバイスマネージャによるデバイス登録処理]

図 36以下のフローを用いて、デバイスマネージャによるデバイスに対するデバイス管理情報他の格納処理を伴う初期登録処理について説明する。図 3 6以下のフローにおいて、左側がデバイスマネージャ（DM) の初期登録装置の処理、右側がデバイス（図 5参照）の処理を示す。なお、デバイスマネージャ（DM) の初期登録装置は、デバイスに対するデータ読み取り書き込み処理可能な装置（ e X . デバイスアクセス機器としてのリーダライタ、 P C) であり、図 1 0のデバイスアクセス機器としてのリーダライタに相当する構成を有する。

まず、ステップ S 20 1において、デバイスの識別子 I D mの読み出し（Read) コマンドをデパイスに出力する。デパイスはコマンドを受信（S 2 1 1 ) し、デバイスの識別子 I Dmを登録装置に送信（ S 2 1 2 ) する。デバイスの識別子 I Dmを受信（S 202 ) した登録装置は、ステップ S 2 0 3において、デパイスに対してデパイス管理情報ブロック（DM I B ： Device Management Information Block (図 1 5参照））の書き込みフラグ（Writable Flag) の読み出しコマンドを送信する。デバイスはコマンドを受信（S 2 1 3)すると、デバイスのメモリ部のデバイス管理情報ブロック（DM I B) 内の書き込みフラグ（Writable Flag) を登録装置に送信（S 2 1 4) する。

デバイス管理情報プロック（DM I B) 内の書き込みフラグ（Writable Flag) を受信（S 204 ) した登録装置は、書き込みフラグ（Writable Flag) が書き込み可（O x f f f f ) に設定されているか否かを判別（S 205 ) する。書き込みフラグ（Writable Flag) が書き込み可（ 0 x f f f f ) に設定されていない場合は、以下のデバイス管理情報ブロック（ D M I B ： Device Management Information Block) の書き込み処理は実行できず、エラ一として終了する。書き込みフラグ（Writable Flag) が書き込み可（ 0 x f f f f ) に設定されている場合は、デバイスマネージヤコ一ド（DMC) および D M Cバージョンの書き込み（DMC Write) コマンドをデバイスに送信（S 206) する。このコ一ドは、コード管理機関（図 1〜図 3参照）によりデバイスマネージャに対して予め割り当てられたデ一夕である。

DMC Writeコマンドを受信（S 2 1 5) したデバイスは、 DM I B書き込みフラグ（Writable Flag) を検証（S 2 1 6 ) し、書き込みフラグ（Writable Flag) が書き込み可（ Ox f f f f ) に設定されていない場合は、以下のデバイス管理情報ブロック（DM I B ： Device Management Information Block) の書き込み処理は実行できず、エラ一として終了する。書き込みフラグ（Writable Flag) が書き込み可（O x f f f f ) に設定されている場合は、受信したデバイスマネージヤコ一ド（DMC) および DM Cバ一ジョンを DM I B領域に書き込む（S 2 1 7 )。

デバイスマネージャコード（DMC) および DMCバ一ジョンの書き込み処理が終了すると書き込み終了通知を登録装置に送信（S 2 1 8 ) する。書き込み終了通知を受信（S 207 ) した登録装置は、次にデバイス総ブロック数（Device Total Block Number) 書き込みコマンドをデバイスに送信（ S 208 ) する。デバイス総ブロック数（Device Total Block Number) 書き込みコマンドを受信 ( S 2 1 9 ) したデバイスは、 DM I B書き込みフラグ（Writable Flag) を検証 ( S 220 ) し、書き込みフラグ（Writable Flag) が書き込み可（ 0 x f f f f ) に設定されていない場合は、以下のデバイス管理情報プロヅク（DM I B： Device Management Information Block) の書き込み処理は実行できず、エラ一として終了する。書き込みフラグ（Writable Flag) が書き込み可（ 0 x f f f f ) に設定されている場合は、受信したデバイス総プロヅク数（Device Total Block Number) を DM I B領域に書き込む（S 22 1 )。さらに、デバイスは、 DM I B領域のデバイス空きブロック数情報領域（Free Block Number in Device) に TB— 4を書き込む（S 22 2 )。 T Bはデパイス総ブロック数（Device Total Block Number) を意味する。なお T B— 4の 4ブロックは、製造情報ブロック（M I B ： Manufacture Information Block), デバイス管理情報ブロック（DM I B :Device Management Information Block)、公開鍵系デパイスキー定義プロック（D K D B ： Device Key Definition Block(PUB)), 共通鍵系デバイスキ一定義ブロック（DK D B ： Device Key Definition Block( Common)) を示している。

次に、デバイスは、デバイス管理情報ブロック（DM I B) のパーティション数（Partition Number) 領域に 0を書き込む（S 223 )。この時点でデバイスにはパーティションは設定されていないからである。さらに DM I Bの空き領域のポインタ（Pointer of Free Area) に 0を書き込み（ S 224 )、書き込み処理完了を登録装置に送信（S 225 ) する。

書き込み処理完了通知をデバイスから受信（S 209 ) した登録装置は、次に、デバイス認証に共通鍵を用いるか否かを判定（S 23 1 ) する。認証処理については、後段で詳細に説明するが、公開鍵認証方式、共通鍵認証方式のいずれかを実行する構成が可能であり、デバイスマネージャは、デバイスに必要な認証方式を設定することが可能となる。デパイスが共通鍵認証を実行するデバイスであれば、デバイスマネージャは共通鍵認証に必要な情報（ex. 認証鍵生成用のマス夕一鍵他）をデバイスにセットし、デバイスが共通鍵認証を実行しないデバイスであれば、これらの情報をデバイスに格納しないことになる。デパイスマネージャは、デバイスの採用する認証方式に応じて共通鍵認証、公開鍵認証のいずれか、あるいは両方式を実行可能なデータをデバイスに設定する。

図 37に示すように、デバイス認証に共通鍵を用いる場合、ステップ S 23 2 〜S 23 3、 S 24 1〜S 245を実行し、デバイス認証に共通鍵を用いない場合、これらのステップは省略される。

デパイス認証に共通鍵を用いる場合、ステップ S 23 2において登録装置は、共通鍵認証データ書き込みコマンドとして、 MKauth— DEV_A：双方向個別鍵認証用マスタ一鍵、 Kauth— DEV— B：双方向個別鍵認証用共通鍵、 IRL_DEV：排除デバイス (Device)のデバイス識別子（ I D )を登録したリポケ一シヨンリスト（Revocation List (Device ID), およびこれらのパ一ジョン情報をデバイスに送信する。

ステップ S 24 1でデバイスは、上述の書き込みコマンドを受信し、ステップ S 242において、 DMI Bの書き込みフラグ（Writable Flag) が書き込み可であることを確認して受領デ一夕をデバイス鍵領域（図 1 8参照）に書き込む（S 243 )。次にデータ書き込みによって生じたポィン夕、サイズ、デバイス内のフリ—ブロック数の調整を実行 ( S 244 ) し、書き込み終了通知を登録装置に送信（ S 245 ) する。

書き込み終了通知を受信（S 233 ) した登録装置は、ステップ S 2 34においてデパイス認証に公開鍵を用いるか否かを判定する。図 3 7に示すように、デバイス認証に公開鍵を用いる場合、ステップ S 23 5〜S 2 39、 S 246〜S 254を実行し、デバイス認証に公開鍵を用いない場合、これらのステップは省略される。

デバイス認証に公開鍵を用いる場合、ステップ S 23 5において登録装置は、公開鍵認証データ書き込みコマンドとして、 PUB_CA(DEV)：デバイスマネージャ対応公閧鍵を発行する認証局 C A(D E V)の公開鍵、 PARAM_DEV：デバイス（Device) の公開鍵パラメ一夕、 CRL_DEV：排除デバイス（Device)の公開鍵証明書識別子（ e X . シリアルナンパ： S N) を登録したリポケ一シヨンリスト（Revocation List (Certificate), およびこれらのバージョン情報をデバイスに送信する。

ステヅプ S 246でデバイスは、上述の書き込みコマンドを受信し、ステップ S 247において、 DMI Bの書き込みフラグ（Writable Flag) が書き込み可であることを確認して受領データをデバイス鍵領域（図 1 8参照）に書き込む（S 248 )。次にデータ書き込みによって生じたポィンタ、サイズ、デパイス内のフリーブロック数の調整を実行（S 249 ) し、書き込み終了通知を登録装置に送信（ S 25 0 ) する。

書き込み終了通知を受信（S 236 ) した登録装置は、公開鍵と秘密鍵の鍵ぺァ生成コマンドをデバイスに送信（S 237 ) する。なお、この実施例では、鍵ペアの生成はデバイスが実行する構成としているが、例えば登録装置が実行してデバイスに提供する構成としてもよい。

鍵ペア生成コマンドを受信（S 25 1 ) したデバイスは、デバイス内の暗号処理部（図 5参照）において公開鍵（PUB D E V) と秘密鍵（PR I D EV) のペアを生成し、生成した鍵をデバイス鍵領域（図 1 8参照）に書き込む（S 2 52)。なお、公開鍵（PUB DEV)については、デバイス鍵領域の CERT · DEV領域に一時格納し、その後、公開鍵（PUB D EV) を格納した公開鍵証明書を受領した時点で公開鍵証明書（CERT) に置き換えられる。次にデータ書き込みによって生じたポインタ、サイズ、デパイス内のフリーブロック数の調整を実行（S 25 3 ) し、生成格納した公開鍵を登録装置に送信（S 254) する。

登録装置は、デバイスから公開鍵（PUB DEV) を受信し、先にデバイスから受信したデバイスの識別子 I Dmとともに、デバイスマネージャ内のデータべ —ス（DB (DEV) (図 7参照））に保存する。

次に、デバイスマネージャの登録装置は、パーティション登録チケット（PR T ： Partition Registration Ticket) の検証処理に共通鍵を用いるか否かを判定 (S 2 6 1 ) する。チケット検証には、後段で詳細に説明するが MA C値検証等による共通鍵方式と、前述の図 1 2、図 1 3を用いて説明した秘密鍵による署名生成、公開鍵による署名検証を行なう公開鍵方式のいずれかを適用することが可能であり、デバイスマネージャは、デバイスの採用する検証処理方式を設定することができる。デバイスマネージャは、デバイスの採用する P R Tチケット検証方式に応じて共通鍵、公開鍵のいずれか、あるいは両方式を実行可能なデータをデバイスに設定する。

デバイスマネージャは、デバイスが共通鍵認証を実行するデバイスであれば、デバイスマネージャは共通鍵方式の P R T検証に必要な情報（ex. PRT検証共通鍵）をデバイスにセットし、デバイスが共通鍵認証を実行しないデバイスであれば、これらの情報をデバイスに格納しないことになる。

図 38に示すように、 P R T検証に共通鍵方式を用いる場合、ステップ S 26 2〜263、 S 27 1〜S 275を実行し、 P R T検証に共通鍵を用いない場合、これらのステツプは省略される。

P R T検証に共通鍵を用いる場合、ステップ S 262において登録装置は、 P R T検証共通鍵書き込みコマンドとして、 Kprt：パ一ティション登録チケット（P RT) の MAC検証用鍵、およびバージョン情報をデバイスに送信する。

ステップ S 2 7 1でデバイスは、上述の書き込みコマンドを受信し、ステップ S 272において、 DM I Bの書き込みフラグ（Writable Flag) が書き込み可であることを確認して受領データをデバイス鍵領域（図 1 8参照）に書き込む（S 273 )。次にデータ書き込みによって生じたポインタ、サイズ、デバイス内のフリーブ口ック数の調整を実行（S 274 ) し、書き込み終了通知を登録装置に送信（ S 275 ) する。

書き込み終了通知を受信（ S 26 3 ) した登録装置は、ステップ S 264において P R T検証に公開鍵を用いるか否かを判定する。図 38に示すように、 P R T検証に公開鍵を用いる場合、ステップ S 26 5〜S 26 6、 S 276〜S 28 2を実行し、 P R T検証に公開鍵を用いない場合、これらのステップは省略される。

P R T検証に公開鍵を用いる場合、ステップ S 265において登録装置は、 P R T検証データ書き込みコマンドとして、 PRTIC (PRT Issuer Category) ：パ一テイション登録チケット（P RT) 発行者カテゴリ、 PUB_CA(DEV)：デバイスマネ一ジャ対応公開鍵を発行する認証局 C A (D E V) の公開鍵、 PARAM_DEV：デバイス (Device) の公開鍵パラメータ、 CRL— DEV：排除デバイス（Device) の公開鍵証明書識別子（e x . シリアルナンパ： S N ) を登録したリボケ一シヨンリスト (Revocation List (Certificate), およびこれらのバ一ジョン情報をデバイスに送信する。

ステップ S 276でデバイスは、上述の書き込みコマンドを受信し、ステップ S 277において、 DM I Bの書き込みフラグ（Writable Flag) が書き込み可であることを確認して、ステップ S 2 78において、受領データ中の PRTIC (PRT Issuer Category) ：パーティション登録チケット（ P R T ) 発行者カテゴリを公開鍵系デパイス鍵定義ブロック（DKDB ： Device Key Definition block (PUB) (図 1 6参照））に書き込みバ一ジョン情報を同プロヅクのバ一ジョン領域に書き込む。

次にデバイスは、ステップ S 2 7 9において、 PUB_CA(DEV)：デバイスマネ一ジャ対応公開鍵を発行する認証局 C A (DEV) の公開鍵デ一夕が書き込み済みか否かを判定し、書き込まれていない場合にステップ S 2 8 0において、 PUB_CA(DEV)、 PARAM_DEV、 CRL—DEVをデバイス鍵領域（図 1 8参照）に書き込む。次にデータ書き込みによって生じたポインタ、サイズ、デバイス内のフリープロック数の調整を実行（S 28 1 ) し、書き込み終了通知を登録装置に送信（S 2 82 ) する。

書き込み終了通知を受信（S 2 6 6 ) した登録装置は、次に、ステップ S 2 9 1において、共通鍵データの更新をサポートするデバイスであるか否かを判定する。デバイスに格納されたデータ中、そのいくつかは更新対象データとして前述したデ一夕アツプデ一トチケット（DUT : Data Update Ticket) (図 32参照）を用いて更新が可能である。更新対象となるデータは、先に図 33を用いて説明した通りである。このデータアップデ一トチケット（DUT： Data Update Ticket) を用いた更新処理においても共通鍵方式、または公開鍵方式のいずれかの方式が可能であり、デバイスマネージャはデバイスに応じていずれかの方式または両方式を実行可能なデータをデバイスに設定する。

デバイスマネージャは、デバイスが共通鍵方式によるデータ更新を実行するデパイスであれば、共通鍵方式のデータ更新処理に必要な情報（ex. データアツプデートチケット（DUT) の MAC検証用鍵他）をデバイスにセットし、デパイスが共通鍵認証を実行しないデバイスであれば、これらの情報をデバイスに格納しないことになる。

図 3 9に示すように、デ一タァップデ一トチケット（D UT : Data Update

Ticket) を用いたデ一夕更新処理に共通鍵方式を用いる場合、ステップ S 292 〜S 293、 S 30 1 ~S 305を実行し、データ更新に共通鍵方式を用いない場合、これらのステップは省略される。

データ更新に共通鍵を用いる場合、ステップ S 292において登録装置は、デ —タアップデ一トチケット（DUT : Data Update Ticket) 検証共通鍵書き込みコマンドとして、 Kdut_DEVl：デ一夕アツプデートチケット（DUT) の MAC検証用鍵、 Kdut— DEV2：データ更新用暗号鍵、 Kdut_DEV3：データアップデートチケット（DUT) の MAC検証用鍵、 Kdut_DEV4：データ更新用暗号鍵およびこれらのバ一ジョン情報をデバイスに送信する。

ステップ S 3 0 1でデバイスは、上述の書き込みコマンドを受信し、ステップ S 302において、 DM I Bの書き込みフラグ（Writable Flag) が書き込み可であることを確認して受領データをデバイス鍵領域（図 1 8参照）に書き込む（S 3 03 )。次にデータ書き込みによって生じたポィン夕、サイズ、デパイス内のフリーブ口ック数の調整を実行（S 3 04 ) し、書き込み終了通知を登録装置に送信（ S 305 ) する.。

書き込み終了通知を受信（S 293 ) した登録装置は、ステップ S 2 94において、デバイスが公開鍵方式を用いたデータアップデ一トチケット（DUT： Data Update Ticket) を使用したデ一夕更新処理をサポートするか否かを判定する。図 3 9に示すように、公開鍵方式をサポ一トする場合、ステップ S 295〜S 2 9 6、 S 306~S 3 1 0を実行し、公開鍵方式をサポ一トしない場合、これらのステップは省略される。

公開鍵方式をサポートする場合、ステップ S 295において登録装置は、デー夕アップデートチケット（DUT ： Data Update Ticket) 発行者コ一ド書き込みコマンドとして、 DUTIC_DEV (DUT Issuer Category) ：データアップデートチケット（D U T ： Data Update Ticket) 発行者カテゴリ、およびバージョン情報をデバイスに送信する。

ステップ S 3 06でデバイスは、上述の書き込みコマンドを受信し、ステップ S 307において、 DM I Bの書き込みフラグ（Writable Flag) が書き込み可であることを確認して、ステップ S 3 08において、受領デ一夕を公開鍵系デバイス鍵定義ブロック（DKDB (PUB) : Device Key Definition Block(PUB)) に書き込む（S 3 08 )。次にデータ書き込みによって生じたポインタ、サイズ、デパイス内のフリーブ口ック数の調整を実行（ S 309 ) し、書き込み終了通知を登録装置に送信（S 3 1 0 ) する。

書き込み終了通知を受信（ S 296 ) した登録装置は、次にステップ S 32 1 において、デバイスマネージャ（DM) 初期登録完了コマンドをデバイスに対して送信する。コマンドを受領（ S 33 1 ) したデバイスは、ステップ S 3 32において、相互認証、パーティション登録チケット（PRT) の検証、さらにデ一タアップデートチケット（DUT) の検証、それそれについて少なくとも公開鍵方式、共通鍵方式のいずれかの処理が実行可能なデータが設定済みであるか否かを判定する。これらのデータに不足がある場合は、いずれかの処理が実行できないことになり、デバイスマネージャによる初期登録はエラ一と判定され処理を終了する。

ステップ S 3 32において、相互認証、パーティション登録チケット（PRT) の検証、さらにデータアップデートチケット（DUT) の検証、それそれについて少なくとも公開鍵方式、共通鍵方式のいずれかの処理が実行可能なデータが設定済みであると判定した場合は、ステップ S 3 33においてデバイスは、デパイス管理情報ブロック（DM I B ： Device Management Information Block) の書き込み（Writable) フラグを書き込み不可（0 x 0000) にセットし、書き込み終了通知を登録装置に送信（S 3 34 )する。

書き込み終了通知を受信（S 322 ) した登録装置は、デバイスに対してデバイス管理情報ブロック（DM I B ： Device Management Information Block) (図 1 5参照））の書き込みフラグ（Writable Flag) の読み出しコマンドを送信（S 323 ) する。デバイスはコマンドを受信（S 3 35 ) すると、デパイスのメモリ部のデバイス管理情報ブロック（DM I B) 内の書き込みフラグ（Writable Flag) を登録装置に送信（S 336 ) する。

デバイス管理情報ブロック（DM I B) 内の書き込みフラグ（Writable Flag) を受信（S 324 ) した登録装置は、書き込みフラグ（Writable Flag) が書き込み不可（ 0 x 0 0 0 0 ) に設定されているか否かを判別する。書き込みフラグ (Writable Flag) が書き込み不可（ 0 x 0 000 ) に設定されていない場合は、正常な DM I Bデータ書き込み処理が終了していないことを示し、エラ一として処理を終了する。書き込みフラグ（Writable Flag) が書き込み不可（0 x 0 00 0) に設定されている場合は、正常な DM I Bデータ書き込み処理が終了したものとして処理を終了する。

デバイス製造ェンティティ（Manufacture)の登録装置による初期登録（図 35の処理フロー）および、デバイスマネージャによる初期登録処理（図 36〜図 40 の処理フロー）が完了した状態のデバイスのメモリ内格納データ構成例を図 4 1 に示す。図 4 1は、図 6、図 14乃至図 1 8を用いて説明した製造情報ブロック ( Manufacture Information Block), デバイス管理情報ブロック（Device Management Information Block)、公開鍵系デバイス鍵定義（Device Key Definition Block(PUB) ), 共通鍵系デバイス鍵定義ブロック（Device Key Definition Block(Common))、デバイス鍵領域（Device Key Area) を示すものである。この時点では、メモリにパ一テイションは形成されていない。

製造情報ブロック（Manufacture Information Block) には、図 14を用いて説明したように、デパイスの固有情報としてのデバイスコード他が書き込まれる。この製造情報ブロック（Manufacture Information Block) に書き込まれた情報、あるいは書き込まれた情報の一部、または書き込まれた情報に基づいて取得される演算データがデバイスの識別子（ I Dm) に相当する。

なお、図に示すデバイス鍵領域（Device Key Area) には Kauth— DEV_B ：双方向個別鍵認証用共通鍵、 MKauth— DEV— A ：双方向個別鍵認証用マスタ一鍵が格納されているが、これらの鍵は、デバイスが共通鍵認証処理を行なう要請が無い場合は格納しない構成としてもよく、また、 Kprt：パ一ティション登録チケヅト（P RT) の MAC検証用鍵についても、デバイスが共通鍵によるチケット検証処理を実行しない構成の場合には格納しない構成としてもよい。

また、 IRL_DEV：排除デバイス（Device) のデバイス識別子（ I D) を登録したリポケーシヨンリスト（Revocation List (Device ID))、 CRL_DEV ：排除デバイス (Device) の公開鍵証明書識別子（e x. シリアルナンパ： SN) を登録したリボケ一シヨンリスト（Revocation List (Certificate)についても、デバイス発行時点でリポーク（排除）されたデバイスが存在しない場合、あるいは他のソースを使用してリボケ一シヨンリストを取得する構成とする場合には、リポケ一ションリストを格納しない構成としてもよい。

[B 3. 2. デバイスマネージャ管理下における公開鍵証明書発行処理] 次に図 42以下を用いて、デパイスマネージャによるデバイス対応公開鍵証明書の発行処理について説明する。デバイスには、デパイス全体の認証、デバイスを単位とした処理に適用可能なデバイス対応公開鍵証明書（CERT D E V)と、デバイス内の特定のパーティションに対する処理の際の認証その他検証処理等に適用可能なパーティション対応公開鍵証明書（CERT PAR)が格納され得る。パーティション対応公開鍵証明書（CERT PAR) は、デバイスに設定されたパーティション毎に設定格納可能である。

デバイス対応公開鍵証明書（CERT DEV)は、デバイスマネージャの管轄するメモリ領域であるデバイス鍵領域（Device Key Area) (図 1 8参照）に格納され、パーティション対応公開鍵証明書（CERT PAR) は、各パーティションマネージャの管轄するメモリ領域であるパーティション鍵領域（Partition Key Area) (図 23参照）に格納される。

デバイス対応公開鍵証明書（CERT D E V)は、デバイスマネージャの管轄する登録局を介して認証局（CA f o r DM) (図 2、図 3参照）の発行した公開鍵証明書をデバイスに付与する手続きにより発行され、デバイスマネージャの管轄登録局が発行した公開鍵証明書（CERT DEV) についての管理（データベース 222 (図 7参照））を実行する。

またパーティション対応公開鍵証明書（CERT PAR) は、パーティシヨンマネージャの管轄する登録局を介して認証局（ C A f o r PM) (図 2、図 3参照）の発行した公開鍵証明書をデバイスに付与する手続きにより発行され、パーテイシヨンマネージャの管轄登録局が発行した公開鍵証明書（CERT PAR) についての管理（データベース 332 (図 9参照））を実行する。

図 42および図 43に従って、デバイスマネージャの管轄登録局によるデバィスに対するデバイス対応公開鍵証明書（CERT D EV)の発行処理の手順を説明する。なお、デバイスマネージャの登録局（RA) 構成のみを取り出した発行装置（DM)、認証局（CA)、ユーザデバイスとの関係を図 44に示した。図 4 4に示すように制御手段 2 2 1は暗号処理手段を有する。なお暗号処理は暗号処理に関するプログラムを制御部（CPU (図 8の 2 1 1 1 ) の制御下において実行することによって行われる。

図 42，図 43において、左側がデバイスマネージャの管轄登録局の C E R T (公開鍵証明書）発行装置、具体的には、図 7に示すデバイスマネージャの構成図における制御手段 2 2 1の処理、右側がデパイスの処理である。

まずステップ S 35 1において、 CERT発行装置は、デバイス対応公開鍵証明書（ C E R T D E V)の発行対象となるデバイスのユーザ情報を取得し、証明書発行の許可（判定）を行ない発行対象となるデバイスとの通信路を確保する。デパイス対応公開鍵証明書（ C E R T D EV)の発行対象となるデバイスのユーザ情報は、例えばデバイスの初期登録時に生成したデータから取得可能である。また、別途、別経路にてュ一ザの名前や住所、電話番号、 e— ma i lアドレスなどを取得するようにしてもよい。なお、ユーザ情報はデバイスとの通信路設定後、デバイスから取得してもよい。通信路は、有線、無線を問わずデータ送受信可能な通信路として確保されればよい。

次に CERT発行装置は、ステップ S 3 52において、乱数を含む認証データ生成コマンドをデバイスに対して送信する。認証データ生成コマンドを受信（S 3 6 1 ) したデバイスは、受信乱数 Rと、デバイス識別子（ I Dm) の結合デ一夕にデバイス秘密鍵（PR I D E V) を適用してデジタル署名（S)の生成処理 (図 1 2参照）を実行（S 362 )する。デバイスは、デバイスの識別デ一夕（ I Dm) と署名（S) を C E R T発行装置に送信する。

デバイスから識別データ（ I Dm) と署名（S) を受信（S 3 53 ) した CE RET発行装置は、受信したデバイス識別データ（I Dm) を検索キーとしてデ —夕べ一ス D B (D E V) 222から格納済みのデバイス公開鍵（ P U B D E V) を取得する。さらに、取得したデバイス公開鍵（P UB DEV) を適用して署名 (S) の検証処理（図 1 3参照）を実行（S 3 5 5 ) する。検証に成功しなかつた場合は、デバイスからの送信データは不正なデータであると判定し処理は終了する。

検証に成功した場合は、認証局（CA f o r DM) 6 1 0に対してデバイス対応公開鍵証明書（CERT D E V) の発行処理を依頼（ S 3 57 ) する。デバイスマネージャは認証局 6 1 0の発行したデバイス対応公開鍵証明書（CERT DEV) を受信（S 358 ) してデバイスに送信（S 35 9 ) する。

デバイスマネージャ（登録局）からデパイス対応公開鍵証明書（CERT D E V)を受信したデバイスは、予めデバイス鍵領域に格納済みの認証局の公開鍵（P UB C A (D E V)) を用いて受信したデバイス対応公開鍵証明書（ C E R T D E V) の署名検証を実行する。すなわち公開鍵証明書には認証局の秘密鍵で実行された署名があり（図 1 1参照）、この署名検証（S 366 ) を行なう。

署名検証に失敗した場合は、正当な公開鍵証明書でないと判定し、エラ一通知を CERT発行装置に対して実行（S 385 ) する。

署名検証に成功した場合は、デバイス対応公開鍵証明書（CERT D E V) に格納されたデバイス公開鍵（PUB DEV)と自デバイスに保管されたデバイス公開鍵（PUB D E V) の比較を実行（S 382 ) し、一致しない場合はエラ一通知を実行し、一致した場合は、受信したデバイス対応公開鍵証明書（C ERT D E V) をデバイス鍵領域（図 1 8参照）に格納（S 383 ) する。なお、デバイス対応公開鍵証明書（CE RT DEV)の発行以前は、この領域に自デバイスで生成した公開鍵（ P U B D E V )を格納し、正当なデバイス対応公開鍵証明書（ C ERT D E V) が発行された時点で、デパイス対応公開鍵証明書（CERT D E V) により上書きする処理として格納する。

デバイス対応公開鍵証明書（CERT D E V)の格納が終了すると格納処理終了通知を C E R T発行装置に送信（S 384) する。 CE R T発行装置は、格納処理終了通知を受信（S 3 7 1 ) し、格納成功を確認（S 372 ) して処理を終了する。格納成功の確認が得られない場合はエラーとして処理が終了する。図 45にデバイス対応公開鍵証明書（CERT D E V)の発行処理において、デパイスマネージャ 2 00、デバイス 1 00、認証局（ C A) 6 1 0各ェンティティ間のデ一夕送受信処理について説明した図を示す。

図 45中の No. 1〜 1 4の順に処理が実行される。なお、処理 N o . 1のデバイスマネージャ 200によるデバイス 1 00からのデバイス識別子（ I D m)、デバイス公開鍵（PUB D E V) の取得処理、および処理 N o . 2のデパイス識別子（ I Dm) の登録処理はデバイスマネージャによる初期登録において実行される処理である。

デバイス対応公開鍵証明書（CERT D E V) の発行手続きは、処理 N o . 3 からであり、 3. デバイスマネージャによるデバイスからの顧客情報取得、 4. 顧客情報の登録（登録済みである場合は不要）、 5. デバイスからのデパイス識別子（ I Dm) 取得、 6. 取得したデバイス識別子（ I Dm) にもとついてデータベース検索を実行して対応の公開鍵（PUB DEV) を取得、 7. デバイスとデバイスマネージャ間における認証処理、この処理は図 42、図 43の処理においては省略されていたが、図 42、図 43においてはデパイスからのデバイス識別子（ I Dm) 取得の際に署名検証を実行しており、通信相手の送信データの確認により、認証を省略した。図 42、図 43における署名検証、図 45の認証の少なくともいずれか、またはいずれをも実行することが望ましい。なお、認証処理の詳細については、後段の B. 4. パーティションマネージャの管轄処理の項目で説明する。

8. デバイスマネージャから認証局に対するデバイス対応公開鍵証明書の発行要求、 9. デバイス対応公開鍵証明書（ C E R T D EV) の生成、 1 0. 認証局における生成公開鍵証明書のデータ登録、 1 1. 認証局（CA) 6 1 0からデバイスマネージャ 200に対する公開鍵証明書の配布、 1 2. デバイスマネージャのデ—夕べ—ス更新（公開鍵証明書発行情報登録）、 1 3. デバイスマネージャからデバイスに対するデパイス対応公開鍵証明書（ C E R T DEV)の送信、 14. デバイスにおけるデバイス対応公開鍵証明書（CERT DEV)の保存、保存は、前述したようにデバイス鍵領域に書き込み保存される。

以上の処理により、デバイスは、デバイス対応公開鍵証明書（ C E R T D E V) を取得し、メモリ部に格納する。このデバイス対応公開鍵証明書（CERT D E V) をメモリのデバイス鍵格納領域に格納した後のメモリの各ブロックのデータ格納構成を図 46に示す。図 46は、先に図 6、図 14乃至図 1 8を用いて説明した製造情報ブロック（Manufacture Information Block), デパイス管理情報ブロック（Device Management Information Block)、公開鍵系デバイス鍵定義（Device Key Definition Block(PUB))、共通鍵系デバイス鍵定義ブロック（Device Key Definition Block(Common)) デバイス鍵領域（Device Key Area) を示すものである。この時点では、メモリにパーティションは形成されていない。

図 46に示すデバイス鍵領域（Device Key Area) にはデパイス対応公開鍵証明書（CERT DEV) が格納される。デバイス対応公開鍵証明書（CERT D E V)の発行前には、この領域には、デバイスが生成した公開鍵（P UB D E V) が格納され、デバイス対応公開鍵証明書（CE RT D EV) を受信すると、デバイス対応公開鍵証明書（CERT DEV) によって上書き処理がなされる。なお、この上書き処理によりポインタ、サイズ、管理データがある場合は必要な変更処理を実行する。

[B 4. パーティションマネージャの管轄処理]

次に、パーティションマネージャの管轄処理について説明する。ここでは、デバイスの使用開始以前に実行される処理について説明する。デバイスの使用開始以前に実行されるパ一ティションマネージャの処理としては、デバイスのメモリ部にパーティションを設定する処理と、デバイスに対してパーティション対応公開鍵証明書（CERT PAR) を発行する処理がある。以下、これらの処理の詳細について説明する。パーティションを設定する処理には、デバイスとパーティションマネージャ間における相互認証処理（デバイス認証またはパーティシヨン認証）、パーティション登録チケット（P R T ： Partition Registration Ticket) の正当性検証処理が含まれる。なお、パーティションの削除処理についても基本的にパーティション作成と同様の手続きに従って実行可能であるので併せて説明する。

[B 4. 1. パーティションマネージャ管理下におけるパーティション登録チケット（PRT) を利用したパーティション設定登録、削除処理]

まず、パーティシヨン登録チケット（PRT) (図 26参照）を利用したパ一テイシヨン設定登録、削除処理について説明する。図 47以下のフロー他の図面を参照して説明する。なお、上述のように、パーティション設定処理には、デパイスとパーティションマネージャ間における相互認証処理（デバイス認証またはパ —テイシヨン認証）、パーティション登録チケット（ P R T ： Partition Registration Ticket) の正当性検証処理が含まれ、これらの処理についても説明する。

図 4 7に示すパーティション設定登録、削除処理フローについて説明する。図 4 7において、左側がパーティションマネージャのパ一テイション作成 · 削除装置、右側がデバイス（図 5参照）の処理を示す。なお、パーティションマネージャのパーティション作成 · 削除装置は、デパイスに対するデータ読み取り書き込み処理可能な装置（e x . デバイスアクセス機器としてのリーダライタ、 P C ) であり、図 1 0のデバイスアクセス機器としてのリーダライ夕に相当する。まず、図 4 7を用いて、パーティション作成、削除処理の概要を説明し、その後、当処理に含まれる各処理の詳細を図 4 8以下のフローを用いて順次説明する。

まず、図 4 7のステップ S 4 0 1 と S 4 1 0において、パ一テイション作成 · 削除装置とデバイス間での相互認証処理が実行される。データ送受信を実行する 2つの手段間では、相互に相手が正しいデータ通信者であるか否かを確認して、その後に必要なデータ転送を行なうことが行われる。相手が正しいデータ通信者であるか否かの確認処理が相互認証処理である。相互認証処理時にセッシヨン鍵の生成を実行して、生成したセッション鍵を共有鍵として暗号化処理を実行してデータ送信を行なう構成が 1つの好ましいデ一夕転送方式である。

本発明のシステムにおける相互認証処理では、デバイス認証またはパーティシヨン認証のいずれかが実行される。また、それそれについて共通鍵方式認証、あるいは公開鍵方式認証処理のいずれかが適用される。これらについては後述する。なお、相互認証処理として実行すべき処理は、適用するパーティション登録チケヅト（P R T ) (図 2 6参照）の

* Authentication Flag ：チケット（Ticket ) の利用処理においてデバイス (Device) との相互認証が必要か否かを示すフラグ

* Authentication Type ：デバイス（Device) の相互認証のタイプ（公開鍵認証、または、共通鍵認証、または、いずれでも可（Any) )

によって決定される。

認証処理に失敗した場合（ S 4 0 2 , S 4 1 1で N o ) は、相互が正当な機器、デパイスであることの確認がとれないことを示し、以下の処理は実行されずエラ一として処理は終了する。認証処理に成功すると、パーティション作成 · 削除装置は、デバイスに対してパーティション登録チケット（ P R T ： Partition Registration Ticket) を送信する。パ一ティション登録チケット（PRT) は、パーティションマネージャの要求により、デバイスマネージャの管理するパーティション登録チケット（P R T) 発行手段（PRT Issuer) によりパーティションマネージャに対して発行されるチケットである。パ一ティション登録チケット（PRT) は、デバイスに対するアクセス制御チケヅトであり、先に説明した図 26のデータフォーマツト構成を持つチケットである。

なお、パーティション登録チケット（PRT) を、チケットユーザに対して送信する際には、公開鍵方式の場合、パーティション登録チケット（PRT) 発行手段（PRT Issuer) の公開鍵証明書（CERT_PRTI) も一緒に送信する。 PRT発行手段の公開鍵証明書（CERT— PRTI) の属性（Attribute) は、パーティション登録チケット（PRT) 発行手段（PRT User) の識別子（PRTIC )と一致する。パーティション登録チケット（PRT) を受信（S 4 1 2) したデバイスは、受信したチケット（PRT) の正当性と利用者チェック処理を実行（S 4 1 3 ) する。チケットの正当性の検証処理は、共通鍵方式による MA C検証、あるいは公開鍵方式による署名検証処理のいずれかを適用して実行される。利用者チエツクは、チケットを送信してきた機器（チケット利用者）の正当性をチヱックする処理であり、相互認証が成立済みであり、認証相手の識別データと、チケットに記録されているチケットユーザ識別子（図 26参照）との一致等を検証する処理として実行される。これらの処理の詳細については後述する。

デバイスにおいて、受信チケット（PRT) の正当性と利用者チェック処理の結果、チケットおよび利用者の正当なことが確認できなかった場合（S 4 14で No) は、パーティション登録チケット（PRT) 受理エラ一をパーティション作成 · 削除装置に通知（S 4 1 8) する。チケットおよび利用者の正当なことが確認できた場合（S 4 14で Ye s) は、受信したパーティション登録チケット (PRT) に記述されたルールに従いデパイス内のメモリ部におけるパーティシヨンの生成、または削除処理を実行する。この処理の詳細についても別フローを用いて後段で詳述する。パーティション登録チケット（PRT) の記述に従って、パーティションの生成または削除処理に成功（ S 4 1 6で Y e s ) すると、 P R T受理成功をパ一テイション作成 · 削除装置に通知（S 4 1 7 ) する。一方、パーティシヨンの生成または削除処理に失敗（S 4 1 6で N o) した場合は、 PRT受理エラ一をパーテイシヨン作成 ' 削除装置に通知（S 4 1 8) する。

パーティション作成 · 削除装置は、 PRT受理結果を受信（S 404 ) し、 P RT処理結果を判定し、 P R T受理結果がエラ一である場合（S 405で No) は、エラ一として処理を終了し、 P R T受理結果が成功（S 40 5で Ye s) であり、処理がパーティション生成である場合はパーティション初期データの書き込み処理（S 406 , S 4 1 9 ) を実行する。初期データの書き込み処理については、後段で別フローを用いて詳述する。パーティション初期デ一夕の書き込み処理が終了した場合、および P R T受理結果が成功（ S 40 5で Y e s )であり、処理がパ一テイション削除である場合はセッシヨンクリアコマンドの送受信（ S

407 , S 42 0 ) を実行し、デバイス側に生成した認証一ブルを破棄（S 42 1 ) し、処理を終了する。認証テ一ブルは、ステップ S 40 1， S 4 1 0の相互認証処理において生成されるテーブルであり、その詳細は後述する。

このようにパーティション登録チケット（PRT) を利用して、デバイス内に新たなパーティションの生成、または生成済みのパーティションの削除が実行される。以下、当処理に含まれる相互認証処理（ S 40 1 , S 4 1 0 )、チケットの正当性と利用者チヱック（S 4 1 3)、パーティションの生成、削除処理（S 4 1

5 )、パーティション初期デ一夕書き込み処理（S 40 6， S 4 1 9 )の各処理について詳述する。

(相互認証処理）

図 47のステップ S 40 1 , S 4 1 0において実行される相互認証処理について説明する。なお、以下に説明する相互認証処理は、他のチケット、すなわちフアイル登録チケット（ F R T ： File RegistrationTicket)、サ一ビス許可チケット（ S P T ： Service Permission Ticket)、デ一夕アップデートチケット（DU T ： Data Update Ticket) を使用したデバイスアクセス処理においても適宜必要に応じて行われる処理である。相互認証処理の処理フローを図 48に示す。図 48において、左側がパーティシヨンマネージャの認証装置、右側がデバイス（図 5参照）の処理を示す。なお、パーティシヨンマネージャの認証装置は、デバイスに対するデータ読み取り書き込み処理可能な装置（ex. デバイスアクセス機器としてのリーダライ夕、 P C) であり、図 1 0のリ一ダライダに相当する構成を有する。

図 48のステップ S 43 1において、認証装置は、パーティシヨン登録チケット（PRT)の利用に必要な認証方式をチケットから読み出して決定する。なお、認証態様は、チケット記載の認証方式に限らず、例えばアクセス機器（ex. リ一ダライタ）からの指定された方式に従ってデバイス認証、パーティション認証を決定してもよい。

決定した認証方式を A ( 1 ) ~A ( n) とする。パーティシヨン登録チケット (PRT) を適用したパーティションの設定登録、あるいは削除処理においては様々な認証処理態様が設定される。例えばパーティションの設定登録についてはデバイスを対象とするデバイス認証を必要とし、パーティション削除の場合にはデバイス認証と削除対象となるパーティション認証の双方を必要とするなどである。このように処理に応じていずれか一方の認証、または両者の認証を必要とする設定をパーティション登録チケット（PRT) に記述することができる。 PR T利用処理において必要とする認証方式については、パーティション登録チケット（PRT) の [Authentication Type] に記述され、認証装置は、パ一ティション登録チケット（P R T) の利用に必要な認証方式をチケットから読み出して決定し、認証処理手順を A ( i )： A ( 1 )〜A (n) として定義する。

ステップ S 432において、最初の認証処理方式 A ( 1 ) を読み出し、 A ( 1 ) の認証方式がデバイス認証、パーティション認証であるかについて判別（S 43 3) し、デバイス認証であればデバイス認証を実行（ S 434 , S 44 1 ) し、パーティション認証であればパーティション認証を実行（S 435 , S 442 ) する。デパイスとの認証処理の結果、認証が成功しない場合は、エラーとして処理を終了する。認証が成功した場合は、ステップ S 437において iをインクリメントしてステップ S 43 3に戻り、次の認証方式を判別して、方式に従って認証を実行する。これらの処理を A ( 1 ) 〜A ( n) まで実行して、全ての認証が成功した場合に次のステツプに進む。

デバイス認証処理について図 49のフローに従って説明する。図 49において、左側がパーティションマネージャのデバイス認証装置、右側がデパイス（図 5参照）の処理を示す。なお、パーティションマネージャのデバイス認証装置は、デバイスに対するデータ読み取り書き込み処理可能な装置（ex. デバイスァクセス機器としてのリーダライタ、 P C) であり、図 1 0のデバイスアクセス機器としてのリーダライタに相当する構成を有する。

デバイス認証装置は、ステップ S 45 1において、パーティション登録チケット（PRT) に基づいてデバイス認証処理に公開鍵を用いた公開鍵認証方式を適用するか否かを判定する。デパイス認証は、公開鍵方式または共通鍵方式のいずれかにおいて実行され、チケットにその実行方式についての指定が記述されている。

共通鍵方式の指定がある場合は、図 49のステップ S 452〜 S 455、 S 4 6 1〜 S 465の処理は実行されず、ステップ S 456に進む。公開鍵方式の指定である場合は、デバイス認証装置は、ステップ S 452において公閧鍵デバイス認証開始コマンドをデバイスに送信する。デバイスは、コマンドを受信（S 4 6 1 ) すると、デバイスのメモリ部の公開鍵系デバイス鍵定義ブロック（図 1 6 参照）を参照して、デバイス対応公開鍵証明書（CERT D E V) が格納されているか否かを検証（S 46 2 ) する。デバイス対応公開鍵証明書（CERT D E V) が格納されていない場合は、公開鍵方式の相互認証は実行できず、エラ一と判定され処理は終了される。

デバイス対応公開鍵証明書（CERT D E V)が格納されていることが確認されると、ステップ S 453、 S 463において、デバイスマネージャ対応認証局 (C A (D E V))の発行した公開鍵証明書を用いた相互認証および鍵共有処理が実行される。

公開鍵方式による相互認証および鍵共有処理について、図 5 0を用いて説明する。図 50は、公開鍵暗号方式である 1 60ビット長の楕円曲線暗号（E C C) を用いた相互認証シーケンスを示している。図 50では、公開鍵暗号方式として E C Cを用いているが、公開鍵暗号方式の他方式を適用することも可能である。また、鍵サイズも 1 60ビットでなくてもよい。図 50において、まず Bが、 6 4ビットの乱数 Rbを生成し、 Aに送信する。これを受信した Aは、新たに 64 ビットの乱数 R aおよび標数 pより小さい乱数 Akを生成する。そして、ベースポイント Gを Ak倍した点 Av = AkxGを求め、 Ra、 Rb、 A v (X座標と Y 座標）に対する電子署名 A. S i gを生成し、 Aの公開鍵証明書とともに Bに返送する。ここで、 Raおよび Rbはそれそれ 64ビット、 Avの X座標と Y座標がそれそれ 1 6 0ビヅトであるので、合計 448ビットに対する電子署名を生成する。

公開鍵証明書を利用する際には、利用者は自己が保持する公開鍵証明書発行局 (CA) の公開鍵を用い、当該公開鍵証明書の電子署名を検証し、電子署名の検証に成功した後に公開鍵証明書から公開鍵を取り出し、当該公開鍵を利用する。従って、公開鍵証明書を利用する全ての利用者は、共通の公開鍵証明書発行局（ C Α)の公開鍵を保持している必要がある。なお、電子署名の検証方法については、図 1 3で説明したのでその詳細は省略する。

Αの公開鍵証明書、 Ra、 Rb、 Av、電子署名 Α. 31 を受信した8は、 Aが送信してきた Rbが、 Bが生成したものと一致するか検証する。その結果、一致していた場合には、 Aの公開鍵証明書内の電子署名を認証局の公開鍵で検証し、 Aの公開鍵を取り出す。そして、取り出した Aの公開鍵を用い電子署名 A. S i gを検証する。電子署名の検証に成功した後、 Bは Aを正当なものとして認証する。

次に、 Bは、標数 pより小さい乱数 B kを生成する。そして、ベースポイント Gを B k倍した点 B V = B k X Gを求め、 Rb、 Ra、 B v (X座標と Y座標）に対する電子署名 Β. S i gを生成し、 Bの公開鍵証明書とともに Aに返送する。

Bの公開鍵証明書、 Rb、 Ra、 Bv、電子署名 B. S i gを受信した Αは、 Bが送信してきた Raが、 Aが生成したものと一致するか検証する。その結果、一致していた場合には、 Bの公開鍵証明書内の電子署名を認証局の公開鍵で検証し、 Bの公開鍵を取り出す。そして、取り出した Bの公開鍵を用い電子署名 B . S i gを検証する。電子署名の検証に成功した後、 Aは Bを正当なものとして認証する。両者が認証に成功した場合には、 Bは BkxAv (Bkは乱数だが、 Avは楕円曲線上の点であるため、楕円曲線上の点のスカラー倍計算が必要）を計算し、 Αは Ak X B Vを計算し、これら点の X座標の下位 64ビットをセッション鍵として以降の通信に使用する（共通鍵暗号を 64ビット鍵長の共通鍵暗号とした場合）。もちろん、 Y座標からセッション鍵を生成してもよいし、下位 64ビットでなくてもよい。なお、相互認証後の秘密通信においては、送信データはセッション鍵で暗号化されるだけでなく、電子署名も付されることがある。

電子署名の検証や受信データの検証の際に、不正、不一致が見つかった場合には、相互認証が失敗したものとして処理を中断する。

このような相互認証処理において、生成したセッション鍵を用いて、送信デー夕を暗号化して、相互にデータ通信を実行する。

図 49に戻りフローの説明を続ける。ステップ S 453 , S 463において上述のような相互認証、鍵共有処理に成功すると、デバイスは、ステップ S 464 において、デバイスのメモリ部のデバイス鍵領域（図 1 8参照）に格納された CRL_DEV ：排除デバイス（Device：)、排除機器（デバイスアクセス機器としてのリ一ダライタ、 P C等のチケットユーザ、チケット発行手段）の公開鍵証明書識別子（ e X . シリアルナンパ： S N) を登録したリポケ一シヨンリスト（Revocation List (Certificate)を参照して、通信相手であるデバイス認証装置がリボークされていないかを検証する。リボークされている場合は、パーティションの生成処理を許可できないので、エラ一として処理を終了する。

リポ一クされていない場合は、ステップ S 465において、相互認証および鍵共有処理において生成したセッション鍵 K s e sと、通信相手（デバイス認証装置を構成するデバイスアクセス機器としてのリーダライタ、 P Cなど）の公開鍵証明書中の識別名（D N： Distinguished Name)、シリアルナンバー、カテゴリーをデバイスマネージャコード（DMC) をキ一として対応付けた認証テーブルに保存する。

一方、デバイス認証装置も、ステップ S 454において、デバイスがリポークされていないかを CRL_DEV：排除デバイス（Device)、排除機器（デバイスァクセス機器としてのリーダライタ、 P C等のチケットユーザ、チケヅト発行手段）の公開鍵証明書識別子（ex. シリアルナンパ： SN) を登録したリポケ一シヨンリスト（Revocation List (Certificate)) を参照して判定する。デバイス認証装置は、リポケ一シヨンリスト（CR DEV) を登録局（RA (PAR)) から取得可能である。リボークされている場合は、パーティションの生成処理を許可できないので、エラ一として処理を終了する。

リボークされていない場合は、ステップ S 455において、相互認証および鍵共有処理において生成したセッション鍵 K s e sと、通信相手（デバイス）の公開鍵証明書中の識別名（D N： Distinguished Name)、シリアルナンバー、カテゴリーをデバイスマネージャコード（DMC) をキ一として対応付けた認証テ一ブルに保存する。

図 5 1にデバイス内に生成される認証テーブルの例を示し、図 52に認証装置としてのデバイスアクセス機器としてのリ一ダライタ（P Cも可）に生成される認証テ一ブルの例を示す。

図 5 1は、デバイス認証、および後段で説明するパーティション認証としてのパーティション 1， 2の認証が終了した時点のデバイス内に生成される認証テ一ブルの例である。グループ（Group) として、デバイス認証の場合はデバイスマネ —ジヤコ一ド（DMC)、パーティション認証の場合はパーティシヨンマネージャコード（PMC) が記録され、実行された各認証方式によってそれそれのデータが格納される。公開鍵認証方式の場合は、前述したようにセッション鍵 K s e s と、通信相手（デバイスアクセス機器としてのリーダライタ）の公開鍵証明書中の識別名（D N ： Distinguished Name)、シリアルナンパ一、カテゴリ一がテープルに格納され、共通鍵認証の場合は、セッション鍵 K s e sと、通信相手（デバイスアクセス機器としてのリーダライタ）の識別子（ I D RW) ガ格納される。認証テーブルはセッションのクリァ時点で破棄される。デバイスはテーブルの情報を参照することによってデバイスおよび各パーティションの認証状態を確認することができ、使用すべきセッション鍵の確認が可能となる。

一方、図 52は、デバイスアクセス機器としてのリーダライタ側の認証テープルを示している。この例もデバイス認証、およびパーティション認証としてのパーテイシヨン 1 , 2の認証が終了した時点の認証テーブルの例である。基本的構成は、デバイス内の認証テーブルと同様であり、グループ（Group) として、デバイス認証の場合はデバイスマネージヤコ一ド（D M C )、パーティション認証の場合はパーティションマネージャコード（P M C ) が記録され、実行された各認証方式によってそれぞれのデータが格納される。公開鍵認証方式の場合は、前述したようにセッション鍵 K s e sと、通信相手（デバイス）の公開鍵証明書中の識別名（D N ： Di stingui shed Name)、シリアルナンパ一、カテゴリ一がテ一ブルに格納され、共通鍵認証の場合は、セッション鍵 K s e sと、通信相手（デバイス）の識別子（ I D R W ) が格納される。リーダライタ側の認証テーブルもセッションのクリァ時点で破棄される。デバイスアクセス機器としてのリーダライタ側においても、認証テーブルの情報を参照することによってデバイスおよびパーティションの認証状態の有無を判定可能となり、使用すべきセッション鍵の確認が可能となる。

図 4 9に戻り、デバイス認証処理の説明を続ける。デバイス認証装置はステツプ S 4 5 1において、デバイス認証方式が公開鍵方式でないと判定されると、デバイス認証装置はステップ S 4 5 6において、共通鍵デバイス認証コマンドをデバイスに出力する。デバイスは、コマンドを受信（S 4 6 6 ) すると、デバイスのメモリ部の共通鍵系デバイス鍵定義ブロック（図 1 6参照）を参照して共通鍵認証に使用する双方向個別鍵認証用マスタ一鍵（MKauth— DEV)が格納されているか否かを検証（ S 4 6 7 ) する。双方向個別鍵認証用マスタ一鍵（MKauth— DEV) が格納されていない場合は、共通鍵方式の相互認証は実行できず、エラ一と判定され処理は終了される。

双方向個別鍵認証用マスタ一鍵（MKauth— DEV)が格納されていることが確認されると、ステップ S 4 5 7、 S 4 6 8において、マスタ一鍵を使用した相互認証および鍵共有処理が実行される。

マスター鍵を使用した共通鍵方式による相互認証および鍵共有処理について、図 5 3を用いて説明する。図 5 3では、 Aおよび Bがマスタ一鍵を使用した共通鍵方式の認証を実行するエンティティであり、 Aは、自己の識別子 I D a、双方向個別鍵認証用共通鍵 K a、双方向個別鍵認証用マスター鍵 M K bを有し、 Bは、自己の識別子 I D b、双方向個別鍵認証用共通鍵 K b、双方向個別鍵認証用マスター鍵 MK aを有する。なお、図 53の例では、共通鍵暗号方式として D E Sァルゴリズム（e x. DE S, トリプル DE S) を用いているが、同様な共通鍵暗号方式であれば他の暗号方式の適用も可能である。

まず、 Bが 64ビットの乱数 Rbを生成し、 R bおよび自己の I Dである I D bを Aに送信する。これを受信した Aは、新たに 64ビットの乱数 R aを生成し、双方向個別鍵認証用マスタ一鍵 MK bによる I D bの DE S暗号化処理により双方向個別鍵認証用共通鍵 K bを取得する。さらに、鍵 Ka、 Kbを用いて、 Ra， Rb， I D a , I Dbの順に、 D E Sの C B Cモードでデータを暗号化し、自己の識別子 I D aとともに Bに返送する。

これを受信した Bは、まず、双方向個別鍵認証用マスタ一鍵 MK aによる I D aの D E S暗号化処理により双方向個別鍵認証用共通鍵 K aを取得する。さらに、受信データを鍵 Ka， Kbで復号する。復号して得られた R a、 Rb、 I D a , I Dbの内、 Rbおよび I D bが、 Bが送信したものと一致するか検証する。この検証に通った場合、 Bは Aを正当なものとして認証する。

次に Bは、セッション鍵として使用する 64ビットの乱数 K s e sを生成し、鍵 Kb、 Kaを用いて、 Rb, Ra, I Db, I D a , K s e sの順に、 DE S の CB Cモードでデータを暗号化し、 Aに返送する。

これを受信した Aは、受信デ一夕を鍵 Ka, Kbで復号する。復号して得られた Ra、 Rb、 I D a, I D bが Aが送信したものと一致するか検証する。この検証に通った場合、 Aは Bを正当なものとして認証する。互いに相手を認証した後には、セッション鍵 K s e sは、認証後の秘密通信のための共通鍵として利用される。

なお、受信データの検証の際に、不正、不一致が見つかった場合には、相互認証が失敗したものとして処理を中止する。

本発明のシステムの格納データに対応付けたマスタ一鍵を使用した共通鍵認証について、デ一夕の流れを説明する図を図 54に示す。図 54に示すように、デパイスアクセス機器としてのリーダライタ（R/W) が 64ビットの乱数 Rbを生成し、 R bおよび自己の I Dである I D r wをデバイス（D ev i c e) に送信する。これを受信したデバイス（D e v i c e) は、新たに 64ビットの乱数 R aを生成し、双方向個別鍵認証用マスタ一鍵 MKauth— DEV_Aによる I D r wの D E S暗号化処理により双方向個別鍵認証用共通鍵 Kauth— DEV_Aを取得する。さらに、鍵 Kauth— DEV— A、 Kauth— DEV_Bを用いて、 Ra， Rb, I D rwの順に、暗号アルゴリズムとして、例えば D E S— C B Cモードでデータを暗号化し、自己の識別子 I Dmとともにデバイスアクセス機器としてのリーダライタ（R/W) に返送する。

これを受信したリ一ダライタ（R/W) は、まず、双方向個別鍵認証用マスタ —鍵 MKauth— DEV—Bによる I 0^1の0 E S暗号化処理により双方向個別鍵認証用共通鍵 Kauth— DEV_Bを取得する。さらに、受信データを鍵 Kauth— DEV_A、 Kauth — DEV_B で復号する。復号して得られた Rbおよび I D rwが、デバイスァクセス機器としてのリ一ダライタ（R/W) が送信したものと一致するか検証する。この検証に通った場合、リーダライタ（R/W) はデパイス（D ev i c e) を正当なものとして認証する。

次にリ一ダライタ（R/W) は、セッション鍵として使用する 64ビットの乱数 K s e sを生成し、双方向個別鍵認証用共通鍵 Kauth— DEV_A、 Kauth_DEV_B を用いて、 Rb, Ra， K s e sの順に、 D E Sアルゴリズムとしての例えばトリブル D E Sモードでデータを暗号化し、デバイス（D e v i c e) に返送する。これを受信したデバイスは、受信データを双方向個別鍵認証用共通鍵 Kauth一 DEV_A、 Kauth— DEV_Bで復号する。復号して得られた R a、 R b， I D rwがデバイス（D ev i c e) が送信したものと一致するか検証する。この検証に通つた場合、デバイス（D ev i c e) はリーダライタ（R/W) を正当なものとして認証し、認証後、セッション鍵 K s e sを秘密通信のための共通鍵として利用する。

なお、デバイスの固有値としての I Dmは、先に図 6のデバイスメモリフォーマットを使用して説明したようにデバイスマネージャ管理領域の格納データに基づく値を適用することができる。

上述したように、マスター鍵を使用した共通鍵方式による相互認証および鍵共有処理によれば、通信相手方のマスタ一鍵に基づく処理を実行して生成した通信相手の個別鍵と、自己の個別鍵の 2つの鍵を共通鍵として設定し、設定した 2つの鍵を用いて共通鍵方式による相互認証を実行する構成であるので、デバイスまたはアクセス装置に予め共通鍵が格納された従来の共通鍵認証構成に比較してよりセキュアな認証システムおよび方法が実現される。

図 49に戻りフローの説明を続ける。ステップ S 45 7 , S 468において上述のような相互認証、鍵共有処理に成功すると、デバイスは、ステップ S 46 9 において、デバイスのメモリ部のデバイス鍵領域（図 1 8参照）に格納された IRL_DEV ：排除デバイス（Device)、排除機器（デバイスアクセス機器としてのリ —ダライタ、 P C等のチケヅトュ一ザ、チケット発行手段）の識別子（ I D) を登録したリボケ一シヨンリスト（Revocation List (ID)) を参照して、通信相手であるデパイス認証装置がリポークされていないかを検証する。リポークされている場合は、パーティションの生成処理を許可できないので、エラーとして処理を終了する。

リボークされていない場合は、ステップ S 470において、相互認証および鍵共有処理において生成したセッション鍵 K s e sと、通信相手（デバイス認証装置を構成するデバイスアクセス機器としてのリ一ダライタ、 P Cなど）の識別情報（ I D rw) をデバイスマネ一ジヤコ一ド（DMC) をキ一として対応付けた認証テーブル（図 5 1参照）に保存する。

一方、デバイス認証装置も、ステップ S 458において、デバイスがリボークされていないかを I RL_DEV：排除デバイス（Device)、排除機器（デバイスァクセス機器としてのリーダライ夕、 P C等のチケットュ一ザ、チケット発行手段）の識別子（I D) を登録したリポケ一シヨンリスト（Revocation List (ID)) を参照して判定する。デバイス認証装置は、リポケ一シヨンリスト（IRL_DEV) を登録局（RA (PAR)) から取得可能である。リボークされている場合は、パーティションの生成処理を許可できないので、エラ一として処理を終了する。

リボークされていない場合は、ステップ S 459において、相互認証および鍵共有処理において生成したセッション鍵 K s e sと、通信相手（デバイス）の識別情報（I Dm) をデバイスマネージャコード（DMC) をキ一として対応付けた認証テーブル（図 52参照）に保存する。

以上の処理が、パーティションマネージャの管轄するデバイスアクセス機器としてのリーダライタとデバイス間において実行されるデバィス認証処理である。次に、図 4 8のステップ S 4 3 5、 S 4 4 2において実行されるパーティション認証処理について、図 5 5、図 5 6を用いて説明する。パ一ティション登録チケットを適用したパーティションの設定登録、または削除処理においては、先に説明したように処理に応じてデバイス認証、パーティション認証のいずれか、または両者の認証を必要とする。これらの設定はパーティション登録チケット（P R T ) に記述される。パーティション登録チケット（P R T ) にパーティシヨン認証を実行する記述がある場合は、パーティション認証が実行される。

図 5 5、図 5 6の処理フ口一の各ステツプについて説明する。図 5 5において、左側がパ一テイションマネージャのパーティション認証装置、右側がデバイス（図 5参照）の処理を示す。なお、パーティションマネージャのパーティション認証装置は、デバイスに対するデータ読み取り書き込み処理可能な装置（e x . デバイスアクセス機器としてのリーダライタ、 P C ) であり、図 1 0のデバイスァクセス機器としてのリーダライタに相当する構成を有する。

パーティション認証装置は、ステップ S 4 7 1において、デパイスに対して認証対象となるパ一テイション Aの存在確認を実行するパーテイション A存在チェックコマンドを出力する。コマンドを受領（S 4 8 1 ) したデバイスは、デバイスのメモリ部内にパーティション Aが存在するか否かをチェック（S 4 8 2 ) する。ここでパーティションの識別子 Aとしては例えばパーティションマネージャコード（P M C ) が使用され、デパイスは、例えばパーティション定義ブロック ( P D B ： Parti ti on Definition Block) の格納 P M Cに基づいてパ一ティションの有無を判定することができる。デバイスによるパ一テイションの有無が判定されると、チェック結果がパーティション認証装置に送信される。

チェック結果を受領（ S 4 7 2 ) したパ一テイション認証装置は、チヱック結果を検証（S 4 7 3 ) し、パーティションの存在しないとの結果を受領した場合は、認証不可であるので、エラ一終了する。チェック結果がパーティションが存在することを示した場合は、パーティション認証装置は、ステップ S 4 7 4において、パーティション登録チケット（P R T ) に基づいてパーティション認証処理に公開鍵を用いた公開鍵認証方式を適用するか否かを判定する。パーティション認証は、前述のデパイス認証と同様、公開鍵方式または共通鍵方式のいずれかにおいて実行され、チケットにその実行方式についての指定が記述されている。共通鍵方式の指定がある場合は、図 55のステップ S 47 5〜S 478、 S 4 84〜S 488の処理は実行されず、ステップ S 49 1に進む。公開鍵方式の指定である場合は、パーティション認証装置は、ステップ S 475において公開鍵パーティション A認証開始コマンドをデバイスに送信する。デバイスは、コマンドを受信（S 484) すると、デバイスのメモリ部の公開鍵系パーティション鍵定義プロック（図 2 1参照）を参照して、パ一テイション A対応公開鍵証明書（ C ERT PAR) が格納されているか否かを検証（S 485 ) する。パーティション A対応公開鍵証明書（ C E R T P AR) が格納されていない場合は、公開鍵方式の相互認証は実行できず、エラ一と判定され処理は終了される。

パーティション A対応公開鍵証明書（CERT PAR)が格納されていることが確認されると、ステップ S 476、 S 486において、パーティションマネージャ対応認証局（CA (PAR))の発行した公開鍵証明書を用いた相互認証および鍵共有処理が実行される。

公開鍵方式による相互認証および鍵共有処理については、先のデバイス認証処理において説明した図 50に示すシーケンスと同様であるので説明を省略する。ただし、パーティション認証において利用する公開鍵証明書は、パーティションマネージャ対応認証局（CA (PAR)) の発行した公開鍵証明書であり、この公開鍵証明書の署名検証には、パーティションマネージャ対応認証局（CA (P A R)) の公開鍵（PUB CA (PAR)) を用いる。公開鍵（PUB CA (PA R)) は、パーティシヨン鍵領域（図 2 3参照）に格納されている。このような相互認証処理において、生成したセッション鍵を用いて、送信データを暗号化して、相互にデータ通信を実行する。

ステップ S 476， S 486において図 50に示すシーケンスに従った相互認証、鍵共有処理に成功すると、デバイスは、ステップ S 487において、デパイスのメモリ部のパーティション鍵領域（図 23参照）に格納された CRL_PAR ：排除デバイス（Device；)、排除機器（デバイスアクセス機器としてのリーダライタ、 P C等のチケットユーザ、チケット発行手段）の公開鍵証明書識別子（ex. シリアルナンパ： S N ) を登録したリポケ一シヨンリスト（ Revocation List (Certificate)を参照して、通信相手であるパーティション認証装置がリポークされていないかを検証する。リポークされている場合は、パーティションの生成処理あるいは削除処理を許可できないので、エラ一として処理を終了する。

リポークされていない場合は、ステップ S 488において、相互認証および鍵共有処理において生成したセヅション鍵 K s e sと、通信相手（パーティシヨン認証装置を構成するデバイスアクセス機器としてのリ一ダライタ、 P Cなど）の公閧鍵証明書中の識別名（D N： Distinguished Name)、シリアルナンパ一、カテゴリーをパーティションマネージャコード（PMC) をキ一として対応付けた認証テ一ブルに保存する。

一方、パーティション認証装置も、ステップ S 477において、デバイスがリポークされていないかを CRL_PAR：排除デバイス（Device)、排除機器（デバイスアクセス機器としてのリ一ダライタ、 P C等のチケットユーザ、チケット発行手段）の公開鍵証明書識別子（ex. シリアルナンパ： SN) を登録したリポケ一シヨンリスト（Revocation List (Certificate)) を参照して判定する。デバイス認証装置は、リポケ一シヨンリスト（CRL_PAR) を登録局（RA (PAR)) から取得可能である。リポークされている場合は、パーティションの生成処理あるいは削除処理を許可できないので、エラ一として処理を終了する。

リボークされていない場合は、ステップ S 478において、相互認証および鍵共有処理において生成したセッション鍵 K s e sと、通信相手（デパイス）の公開鍵証明書中の識別名（D N： Distinguished Name)、シリアルナンパ一、カテゴリ一をパーティションマネージャコード（PMC) をキ一として対応付けた認証テ一ブルに保存する。この結果、例えば図 5 1に示す認証テ一ブルがデバイス内に生成され、図 52に示す認証テ一ブルがパーティション認証装置としてのデバイスアクセス機器としてのリーダライタ（P Cも可）に生成される。図 5 1、図 52は、デバイス認証、およびパーティション認証としてのパーティション 1， 2の認証が終了した時点のデバイス内およびデパイスアクセス機器としてのリ一ダライタ内に生成される認証テーブルの例である。

パーティション認証の場合はパーティションマネージヤコ一ド（PMC) が記録され、実行された各認証方式によってそれそれのデータが格納される。公開鍵認証方式の場合は、前述したようにセッション鍵 K s e s と、通信相手の公開鍵証明書中の識別名（D N ： Di stinguished Name)、シリアルナンパ一、カテゴリ一がテーブルに格納され、共通鍵認証の場合は、セッション鍵 K s e sと、通信相手の識別子が格納される。認証テーブルはセッションのクリァ時点で破棄される。デバイスおよびデバイスアクセス機器としてのリーダライタはテ一ブルの情報を参照することによってデバイスおよび各パ一テイションの認証状態を確認することができ、使用すべきセッション鍵の確認が可能となる。

図 5 5，図 5 6のフローを用いて、パーティション認証処理の説明を続ける。パーティション認証装置はステップ S 4 7 4において、パーティション認証方式が公開鍵方式でないと判定されると、パーティション認証装置はステップ S 4 9 1において、共通鍵パーティション A認証コマンドをデバイスに出力する。デバイスは、コマンドを受信（ S 5 0 1 ) すると、デバイスのメモリ部の共通鍵系パ —テイシヨン鍵定義ブロック（図 2 2参照）を参照して共通鍵認証に使用する双方向個別鍵認証用マスタ—鍵（MKauth— PAR_A)が格納されているか否かを検証（ S 5 0 2 ) する。双方向個別鍵認証用マスタ一鍵（MKauth— PAR_A) が格納されていない場合は、共通鍵方式の相互認証は実行できず、エラーと判定され処理は終了される。

双方向個別鍵認証用マスター鍵（MKauth— PAR_A)が格納されていることが確認されると、ステップ S 4 9 2、 S 5 0 3において、マスタ一鍵を使用した相互認証および鍵共有処理が実行される。共通鍵方式による相互認証および鍵共有処理については、先のデバイス認証において、図 5 3、図 5 4を用いて説明したシーケンスと同様であるので、説明を省略する。ただし、パーティション認証の場合に適用する鍵は、パーティション鍵定義ブロック（図 2 2参照）に定義され、ノ —テイシヨン鍵領域（図 2 3参照）に格納された双方向個別鍵認証用共通鍵（Kauth _PAR_B)、および双方向個別鍵認証用マスター鍵（MKauth— PAR_A) である。

ステップ S 4 9 2 , S 5 0 3において共通鍵方式の相互認証、鍵共有処理に成功すると、デバイスは、ステップ S 5 0 4において、デバイスのメモリ部のパーテイシヨン鍵領域（図 2 3参照）に格納された IRL_PAR：排除デバイス（Device), 排除機器（デバイスアクセス機器としてのリーダライタ、 P C等のチケットュ一ザ、チケット発行手段）の識別子（ I D) を登録したリポケーシヨンリスト (Revocation List (ID)) を参照して、通信相手であるパーティション認証装置がリボークされていないかを検証する。リポークされている場合は、パ一テイシヨンの生成処理または削除処理を許可できないので、エラ一として処理を終了する。

リボークされていない場合は、ステップ S 5 05において、相互認証および鍵共有処理において生成したセッション鍵 K s e sと、通信相手（デバイス認証装置を構成するデバイスアクセス機器としてのリーダライタ、 P Cなど）の識別情報（I D rw) をパーティションマネージヤコ一ド（PMC) をキーとして対応付けた認証テーブル（図 5 1参照）に保存する。

一方、パーティション認証装置も、ステップ S 493において、デバイスがリポークされていないかを I RL_PAR：排除デバイス（Device), 排除機器（デバイスアクセス機器としてのリ一ダライタ、 P C等のチケットユーザ、チケット発行手段）の識別子（ I D) を登録したリボケ一シヨンリスト（Revocation List (ID)) を参照して判定する。パーティション認証装置は、リボケ一シヨンリスト (IRL_PAR) を登録局（RA (PAR)) から取得可能である。リボークされている場合は、パーティションの生成処理または削除処理を許可できないので、エラ —として処理を終了する。

リポークされていない場合は、ステップ S 494において、相互認証および鍵共有処理において生成したセッション鍵 K s e sと、通信相手（デバイス）の識別情報（I Dm) をパーティションマネージャコード（DMC) をキ一として対応付けた認証テーブル（図 52参照）に保存する。

以上の処理が、パーティションマネージャの管轄するデバイスアクセス機器としてのリーダライタとデバイス間において実行されるパーティション認証処理である。このような相互認証により、デバイスまたはパーティションとデバイスァクセス機器としてのリ一ダライタ間の認証が成立し、セッション鍵の共有が達成され、通信データのセッション鍵による暗号化通信が可能となる。

なお、上述したデバイス認証処理、パーティション認証処理は、他のチケット、すなわちファイル登録チケット（ F R T ： File RegistrationTicke 、サービス許可チケット（ S P T ： Service Permission Ticket)、データアップデートチケット（D U T ： Data Update Ticket) を使用したデバイスアクセスを実行する際にも適宜必要に応じて行われる処理である。これらについては、後段の各チケットを利用した処理の説明中で述べる。

(チケットの正当性と利用者チェック）

次に、図 47のパーテイションの作成、削除処理フロ一中のステップ S 4 1 3 のデバイスにおけるチケットの正当性と利用者チェック処理の詳細について図 5 7、図 58のフローを用いて説明する。

なお、以下に説明するチケットの正当性と利用者チェック処理は、他のチケット、すなわちファイル登録チケット（ F R T ： File Registration Ticket), サ一ビス許可チケット（ S P T ： Service Permission Ticket)、デ一夕アップデートチケット（D U T ： Data Update Ticket) を使用したデバイスアクセス処理においても適宜必要に応じて行われる処理であり、図 57、図 58のフローは、各チケットに共通の処理フローとして構成してある。

チケットの正当性と利用者チェック処理は、デバイスとの通信を実行しているチケットユーザ（_{e x} . デバイスアクセス機器としてのリーダライタ、 P C等）から受信したチケットに基づいてデバイス（図 5参照）が実行する処理である。デバイスは、チケットの正当性と利用者チェック処理においてチケットおよびチケットユーザ（ex. デバイスアクセス機器としてのリーダライタ、 P C等）である利用者の正当性を確認した後、チケットに記述された制限範囲内の処理を許可する。

図 57、図 58のフローを用いてチケットの正当性と利用者チェック処理の詳細について説明する。チケットをチケットュ一ザ（ex. デバイスアクセス機器としてのリーダライタ、 P C等）から受信したデバイスは、図 57のステップ S 5 1 1において、チケットタイプを検証しチケットがパーティション登録チケット（PRT ： Partition Registration Ticket) であるか否かを判定する。チケットタイプは、各チケットに記録されている（図 26、図 2 7、図 28、図 3 1、図 32参照）。チケットタイプがパーティション登録チケット（ P R T ： Partition Registration Ticket) である場合は、ステップ S 5 1 2〜S 5 1 4を実行し、パ —テイシヨン登録チケット（ P R T ： Partition Registration Ticket) でない場合は、ステップ S 5 1 5に進む。

チケットタイプがパーティション登録チケット（ P R T : Partition Registration Ticket) である場合は、ステップ S 5 1 2において、チケットに記述された Integrity Check Type (チケット（Ticket) の正当性検証値の種別（公開鍵方式（Public) /共通鍵方式（Co匪 on)))の設定が公開鍵方式（Publ ic)であるか否かを判定する。

正当性検証値の種別（Integrity Check Type) が公開鍵方式（Public)である場合、ステップ S 5 1 3に進み、各種処理を実行する。ステップ S 5 1 3で実行する処理は、まず、デバイスマネージャ対応認証局（CA (D E V)) の公開鍵 PU B C A (D E V) を用いたチケット発行者（Ticket Issuer) の公開鍵証明書（ C ERT) の検証処理である。

前述したように、パーティション登録チケット（PRT)発行手段（PRT Issuer) の発行したチケット（Ticket) を、チケットユーザに対して送信する際には、公開鍵方式の場合、パーティシヨン登録チケット（PRT) 発行手段（PRT Issuer) の公開鍵証明書（CERT_PRTI) も一緒にデバイスに送信される。なお、 PRT発行手段の公開鍵証明書（CERT_PRTI) の属性（Attribute) は、パーティション登録チケット（PRT) 発行手段（PRT User) の識別子（PRTIC )と一致する。

公開鍵証明書（図 1 1参照）にはデバイスマネージャ対応認証局（CA (D E V))の秘密鍵で実行された署名が付加されており、この署名をデバイスマネージャ対応認証局（CA (DEV)) の公開鍵 PUB CA (D E V) を用いて検証する。署名生成、検証は、例えば先に説明した図 1 2、図 1 3のフローに従った処理として実行される。この署名検証により、チケット発行者の公開鍵証明書（C ERT) が改竄されたものでない正当な公開鍵証明書（C ERT) であるか否かが判定される。

さらに、ステップ S 5 1 3では、署名検証により正当性が確認されたチケット発行手段の公開鍵証明書（CERT) のオプション領域に記録されたユーザの力テゴリとしてのコードが、デバイス内の DKDB (Device Key Definition Block) (PUB)に記録されたチケット発行手段コード（P RT I C ： PRT Issuer Code) と一致するか否かを判定する。

公開鍵証明書には、図 1 1の公開鍵証明書の説明の欄で記述したように、各チケット（PRT, FRT、 S P Tなど）の発行手段であるチケット発行手段（Ticket Issuer) の所属コード、この場合、 PRT I C (PRT Issuer Code) が記録されている。このオプション領域のコードとデバイス内の D K D B ( Device Key Definition Block) (PUB)に記録されたチケット発行手段コ一ド（ P R T I C： PRT Issuer Code) の一致を確認することで、受信チケット（PRT) が正当なチケット発行手段によって発行されたチケットであることを確認する。

さらに、デバイスは、デバイスのメモリ部内のデバイス鍵領域（図 1 8参照）に格納された CRL_DEV (排除デバイス（Device)、排除機器（デバイスアクセス機器としてのリ一ダライタ、 P C等のチケットュ一ザ、チケット発行手段）の公開鍵証明書識別子（ex. シリアルナンパ： SN) を登録したリポケ一シヨンリスト（Revocation List (Certificate))) を参照して、チケット発行手段（Ticket Issuer) がリポークされていないかを判定する。

さらに、受信チケットであるパーティション登録チケット（ 11丁）（図26参照）に記録された署名、すなわち Integrity Check Value (チケット（Ticket) の正当性検証値（公開鍵方式：署名（Signature))) の検証を実行し、チケットが改竄されていないかを確認する。署名検証は、先の公開鍵証明書の署名検証と同様、例えば図 1 3のフローと同様のシーケンスに従って実行される。

以上、（ 1 ) チケット発行者（Ticket Issuer) の公開鍵証明書（CERT) が改竄されたものでない正当な公開鍵証明書（CERT)であること、（2)チケット発行者（Ticket Issuer) の公開鍵証明書（CERT) のオプション領域に記録されたコードと、デバイス内の DKDB (Device Key Definition Block) (PUB) に記録されたチケット発行手段コ一ド（P R T I C ： PRT Issuer Code) の一致、 ( 3 ) チケット発行手段（Ticket Issuer) がリポークされていないこと、（ 4 ) 受信チケヅト（PRT) の署名（Signature) の検証によりチケヅトが改竄のないことの確認。以上のすべての確認がなされたことを条件としてチケットの正当性検証成功とする。上記（ 1 ) 〜（4) のいずれかが確認されない場合は、チケットの正当性の確認が得られないと判定され、パーティション登録チケット（PR T ： Partition Registration Ticket) を利用した処理は中止される。

また、ステップ S 5 1 2において、チケットに記述された Integrity Check Type (チケット（Ticket) の正当性検証値の種別（公開鍵方式（Public) /共通鍵方式 (Co隨 on)))の設定が共通鍵方式（Common)であると判定された場合は、ステップ S 5 1 4に進み MAC (Message Authentication Code) 検証を実行する。デバイスは、デバイスのデバイス鍵領域（図 1 8参照）に格納されたパーティション登録チケット（PRT) の MA C検証用鍵： Kp r tを使用してチケットの MAC検証処理を実行する。

図 59に D E S暗号処理構成を用いた M A C値生成例を示す。図 5 9の構成に示すように対象となるメッセージを 8バイト単位に分割し、（以下、分割されたメッセ一ジを M 1、 M 2、 · · ·、 MNとする）、まず、初期値（Initial Value (以下、 I Vとする））と M 1を排他的論理和する（その結果を I 1とする）。次に、 I 1を D E S暗号化部に入れ、 MA C検証用鍵： K p r tを用いて暗号化する（出力を E 1とする）。続けて、 E 1および M 2を排他的論理和し、その出力 I 2を D E S暗号化部へ入れ、鍵 K p r tを用いて暗号化する（出力 E 2 )。以下、これを繰り返し、全てのメッセージに対して暗号化処理を施す。最後に出てきた ENがメッセ一ジ認証符号（MAC (Message Authentication Code)) となる。なお、メッセージとしては、検証対象となるデータを構成する部分データが使用可能である。

改竄のないことが保証された例えばデータ送信側がデ一夕生成時に生成した I C V (Integrity Check Value) と、データ受信側が受信データに基づいて生成した I CVとを比較して同一の I CVが得られればデータに改竄のないことが保証され、 I CVが異なれば、改竄があつたと判定される。改竄のないことが保証された例えばデ一夕送信側がデータ生成時に生成した I CVは、図 26のパーティション登録チケヅト（PRT) のフォーマットに関する記述において説明したように、 PRTの I CV (Integrity Check Value) フィールドに格納されている。デパイスが生成した I CVと受信チケット（P RT) に格納された I CVとを比較して一致していればチケットの正当性ありと判定し、不一致の場合はチケット改竄ありと判定し、チケットを利用した処理を中止する。

上述の処理によってチケットに記述された Integrity Check Typeが共通鍵方式である場合のチケット検証処理が完了する。

図 57のフローに戻り、チケットの正当性と利用者チェック処理について説明を続ける。ステップ S 5 1 1において、チケットタイプがパーティション登録チケヅト（P R T ： Partition Registration Ticket) でないと判定された場合は、ステップ S 5 1 5においてチケットタイプを検証しチケットがファイル登録チケット（F R T ： File Registration Ticket) であるか否かを判定する。

チケットタイプがファイル登録チケット（ F R T ： File Registration Ticket) である場合は、ステップ S 5 1 6〜S 5 1 8を実行し、ファイル登録チケット（F R T ： File Registration Ticket) でない場合は、ステップ S 5 1 9に進む。チケットタイプがフアイル登録チケット（ F R T ： File Registration Ticket) である場合は、ステップ S 5 1 6において、チケットに記述された Integrity Check Type (チケット（Ticket) の正当性検証値の種別（公開鍵方式（Public) / 共通鍵方式（Common))) の設定が公開鍵方式（Public)であるか否かを判定する。正当性検証値の種別（Integrity Check Type) が公開鍵方式 (Public)である場合、ステップ S 5 1 7に進み、各種処理を実行する。ステップ S 5 1 7で実行する処理は、まず、パーティシヨンマネージャ対応認証局（C A (PAR)) の公開鍵 PUB C A (PAR) を用いたチケット発行者（Ticket Issuer) の公開鍵証明書（CERT) の検証処理である。

ファイル登録チケット（FRT) 発行手段（FRT Issuer) の発行したチケヅト (Ticket) を、チケットユーザに対して送信する際には、公開鍵方式の場合、フアイル登録チケット（ F R T )発行手段（FRT Issuer)の公開鍵証明書（CERT_FRTI) も一緒にデバイスに送信される。なお、 F R T発行手段の公開鍵証明書 (CERTJRTI) の属性（Attribute) は、、ファイル登録チケット（FRT) 発行手段（FRT Issuer) の識別子（FRTIC)と一致する。

公開鍵証明書（図 1 1参照）にはパーティションマネージャ対応認証局（CA (PAR))の秘密鍵で実行された署名が付加されており、この署名をパーティシヨンマネージャ対応認証局（CA (PAR)) の公開鍵 PUB C A (PAR) を用いて検証する。署名生成、検証は、例えば先に説明した図 1 2、図 1 3のフロ —に従った処理として実行される。この署名検証により、チケット発行者の公開鍵証明書（CERT) が改竄されたものでない正当な公開鍵証明書（CERT) であるか否かが判定される。

さらに、ステップ S 5 1 7では、署名検証により正当性が確認されたチケット発行手段の公開鍵証明書（CERT) のオプション領域に記録されたユーザの所属コードと、デバイス内の PKD B (Partition Key Definition Block) (PUB) に記録されたチケット発行手段コード（F R T I C ： FRT IssuerCode) と一致するか否かを判定する。

公開鍵証明書には、図 1 1の公開鍵証明書の説明の欄で記述したように、各チケヅト（PRT， FRT、 S P Tなど）の発行手段であるチケット発行手段（Ticket Issuer) の所属コード、この場合、 FRT I C (FRT Issuer Code) が記録されている。このオプション領域のコードとデバイス内の P K D B (Partition Key Definition Block) (PUB)に記録されたチケット発行手段コ一ド（ F R T I C： FRT Issuer Code) の一致を確認しすることで、受信チケヅト（FRT) が正当なチケット発行手段によって発行されたチケットであることを確認する。

さらに、デバイスは、デバイスのメモリ部内のパーティション鍵領域（図 2 3 参照）に格納された CRL_PAR (排除デバイス（Device), 排除機器（デバイスァクセス機器としてのリーダライタ、 P C等のチケットユーザ、チケット発行手段）の公開鍵証明書識別子（ex. シリアルナンパ： SN) を登録したリポケ一ションリスト（Revocation List (Certificate))を参照して、チケット発行手段（Ticket Issuer) がリボ一クされていないかを判定する。

さらに、受信チケットであるファイル登録チケット（FRT) (図 27参照）に記録された署名、すなわち Integrity Check Value (チケット（Ticket) の正当性検証値（公開鍵方式：署名（Signature))) の検証を実行し、チケットが改竄されていないかを確認する。署名検証は、先の公開鍵証明書の署名検証と同様、例えば図 1 3のフローと同様のシーケンスに従って実行される。

以上、（ 1 ) チケット発行者（Ticket Issuer) の公開鍵証明書（CERT) が改竄されたものでない正当な公開鍵証明書（CERT)であること、（2)チケット発行者（Ticket Issuer) の公開鍵証明書（CERT) のオプション領域に記録されたコードと、デバイス内の P K D B (Partition Key Definition Block) (PUB) に記録されたチケット発行手段コ一ド（F R T I C ： FRT Issuer Code) の一致、 (3) チケット発行手段（Ticket Issuer) がリボークされていないこと、（4) 受信チケット（FRT) の署名（Signature) の検証によりチケットが改竄のないことの確認。以上のすべての確認がなされたことを条件としてファイル登録チケット（FRT) の正当性検証成功とする。上記（ 1 ) 〜（4) のいずれかが確認されない場合は、ファイル登録チケット（FRT) の正当性の確認が得られないと判定され、ファイル登録チケット（FRT) を利用した処理は中止される。また、ステップ S 5 1 6において、チケットに記述された Integrity Check Type (チケット（Ticket) の正当性検証値の種別（公開鍵方式（Public) /共通鍵方式 (Common)))の設定が共通鍵方式（Co匪 on)であると判定された場合は、ステップ S 5 1 8に進み MAC (Message Authentication Code) 検証を実行する。デバイスは、デバイスのパーティション鍵領域（図 23参照）に格納されたファイル登録チケット（ F R T) の M A C検証用鍵： Kf r tを使用してチケットの MAC検証処理を実行する。 M A C検証処理は、先に説明した図 5 9の D E S暗号処理構成を用いた M A C値生成処理に従って実行される。

改竄のないことが保証された例えばデータ送信側がデータ生成時に生成した I C V (Integrity Check Value) と、データ受信側が受信デ一夕に基づいて生成した I CVとを比較して同一の I CVが得られればデータに改竄のないことが保証され、 I CVが異なれば、改竄があつたと判定される。改竄のないことが保証された例えばデータ送信側がデータ生成時に生成した I CVは、図 27のファイル登録チケット（ F R T) のフォーマットに関する記述において説明したように、 FRTの I CV (Integrity Check Value) フィールドに格納されている。デバイスが生成した I CVと受信チケット（FRT) に格納された I CVとを比較して一致していればチケットの正当性ありと判定し、不一致の場合はチケット改竄ありと判定し、チケットを利用した処理を中止する。

上述の処理によってチケッ卜に記述された Integrity Check Typeが共通鍵方式である場合のファイル登録チケット（FRT) 検証処理が完了する。

ステップ S 5 1 5において、チケットタイプがファイル登録チケット（FRT ： File Registration Ticket) でないと判定された場合は、ステップ S 5 1 9においてチケットタイプを検証しチケットがサービス許可チケット（ S P T： Service Permission Ticket) であるか否かを判定する。

チケットタイプがサ一ビス許可チケット（ S P T： Service Permission Ticket) である場合は、ステップ S 520〜S 522を実行し、サービス許可チケット（S P T ： Service Permission Ticket) でない場合は、ステップ S 5 23に進む。チケットタイプがサ一ビス許可チケット（ S P T： Service Permission Ticket) である場合は、ステップ S 5 2 0において、チケットに記述された Integrity Check Type (チケット（Ticket) の正当性検証値の種別（公開鍵方式（Publ ic) / 共通鍵方式（Common))) の設定が公開鍵方式（Public)であるか否かを判定する。正当性検証値の種別（Integrity Check Type) が公開鍵方式（Public)である場合、ステップ S 52 1に進み、各種処理を実行する。ステップ S 52 1で実行する処理は、まず、パーティションマネージャ対応認証局（C A (PAR)) の公開鍵 PUB C A (PAR) を用いたチケット発行者（Ticket Issuer) の公開鍵証明書（CERT) の検証処理である。

サービス許可チケット（S PT) 発行手段（SPT Issuer) の発行したチケット (Ticket) を、チケットユーザに対して送信する際には、公開鍵方式の場合、サ —ビス許可チケット（ S R T)発行手段（SPT Issuer)の公開鍵証明書（CERT_SPTI) も一緒にデバイスに送信される。なお、 S P T発行手段の公開鍵証明書 (CERT_SPTI) の属性（Attribute) は、サービス許可チケット（S PT) 発行手段（SPT Issuer) の識別子（SPTIC)と一致する。

公開鍵証明書（図 1 1参照）にはパーティションマネージャ対応認証局（CA (PAR))の秘密鍵で実行された署名が付加されており、この署名をパーティシヨンマネージャ対応認証局（CA (PAR)) の公開鍵 PUB CA (PAR) を用いて検証する。署名生成、検証は、例えば先に説明した図 1 2、図 1 3のフロ一に従った処理として実行される。この署名検証により、チケット発行者の公開鍵証明書（CERT) が改竄されたものでない正当な公開鍵証明書（CERT) であるか否かが判定される。

さらに、ステップ S 52 1では、署名検証により正当性が確認されたチケット発行手段の公開鍵証明書（CERT) のオプション領域に記録されたユーザの所属コードと、デバイス内のファイル定義ブロック（FDB:File Definition Block) に記録されたチケット発行手段コード（S P T I C ： SPT Issuer Code) と一致するか否かを判定する。

公開鍵証明書には、図 1 1の公開鍵証明書の説明の欄で記述したように、各チケット（PRT, FRT、 S P Tなど）の発行手段であるチケット発行手段（Ticket Issuer) の所属コード、この場合、 S PT I C (SPT Issuer Code) が記録されている。このオプション領域のコードとデバイス内の F D B (File Definition Block) に記録されたチケット発行手段コード（S P T I C : SPT Issuer Code) の一致を確認しすることで、受信チケット（S P T) が正当なチケット発行手段によって発行されたチケットであることを確認する。

さらに、デバイスは、デバイスのメモリ部内のパーティション鍵領域（図 2 3 参照）に格納された CRL_PAR (排除デバイス（Device)、排除機器（デバイスァクセス機器としてのリーダライタ、 P C等のチケットユーザ、チケット発行手段）の公開鍵証明書識別子（ex. シリアルナンパ： S N) を登録したリボケ一ションリスト（Revocation List (Certificate))) を参照して、チケット発行手段 (Ticket Issuer) がリポークされていないかを判定する。

さらに、受信チケットであるサービス許可チケット（S PT) (図 28、図 3 1 参照）に記録された署名、すなわち Integrity Check Value (チケット（Ticket) の正当性検証値（公開鍵方式：署名（Signature)) の検証を実行し、チケットが改竄されていないかを確認する。署名検証は、先の公開鍵証明書の署名検証と同様、例えば図 1 3のフローと同様のシーケンスに従って実行される。

以上、（ 1 ) チケット発行者（Ticket Issuer) の公開鍵証明書（CERT) が改竄されたものでない正当な公開鍵証明書（CERT)であること、（2)チケット発行者（Ticket Issuer) の公開鍵証明書（CERT) のオプション領域に記録されたコードと、デバイス内の FDB (File Definition Block) に記録されたチケット発行手段コ一ド（S PT I C ： SPT Issuer Code) の一致、（3) チケット発行手段（Ticket Issuer)がリボークされていないこと、（4)受信チケット（S P T) の署名（Signature) の検証によりチケットが改竄のないことの確認。以上のすベての確認がなされたことを条件としてサービス許可チケット（S PT) の正当性検証成功とする。上記（ 1 ) ~ (4) のいずれかが確認されない場合は、サービス許可チケット（S PT) の正当性の確認が得られないと判定され、サービス許可チケット（S P T) を利用した処理は中止される。

また、ステップ S 52 0において、チケットに記述された Integrity Check Type (チケット（Ticket) の正当性検証値の種別（公開鍵方式（Public) /共通鍵方式 (Common)))の設定が共通鍵方式（Co醒 on)であると判定された場合は、ステップ S 522に進み MAC (Message Authentication Code) 検証を実行する。デバイスは、デバイスのファイル定義ブロック（図 24参照）に格納されたサービス許可チケット（S PT) の MA C検証用鍵： K s p tを使用してチケットの MAC検証処理を実行する。 MAC検証処理は、先に説明した図 59の DE S暗号処理構成を用いた M A C値生成処理に従って実行される。

改竄のないことが保証された例えばデータ送信側がデータ生成時に生成した I C V (Integrity Check Value) と、データ受信側が受信データに基づいて生成した I CVとを比較して同一の I CVが得られればデータに改竄のないことが保証され、 I CVが異なれば、改竄があつたと判定される。改竄のないことが保証された例えばデータ送信側がデータ生成時に生成した I CVは、図 28、図 3 1のサービス許可チケット（ S P T) のフォーマットに関する記述において説明したように、 S PTの I CV (Integrity Check Value) フィールドに格納されている。デバイスが生成した I CVと受信チケット（S PT) に格納された I CVとを比較して一致していればチケットの正当性ありと判定し、不一致の場合はチケット改竄ありと判定し、サービス許可チケット（ S P T) を利用した処理を中止する。上述の処理によってサービス許可チケット（S PT) に記述された Integrity Check Typeが共通鍵方式である場合のサービス許可チケット（S P T) 検証処理が完了する。

ステップ S 5 1 9において、チケットタイプがサービス許可チケット（S PT ： Service Permission Ticket) でないと判定された場合は、ステップ S 52 3においてチケットタイプを検証しチケットがデータアップデ一トチケット- D EV(D UT ： Data Update Ticket(DEV)) (図 32参照）であるか否かを判定する。デ一夕アップデートチケット（DUT) は前述したようにデバイスのメモリ部に格納された各種データの更新処理を実行する際のアクセス許可チケットであり、デバイスマネージャの管理データを更新する処理に適用するデータアップデ一トチケット- DEV (DUT (D E V)) とパーティションマネージャの管理デ一夕を更新する処理に適用するデータアップデートチケット- P AR (DUT (PAR)) とがある。

チケットタイプがデータアップデートチケット- D EV (DUT (DEV)) である場合は、ステップ S 5 24〜S 528を実行し、デ一夕アップデ一トチケット（D E V) (D U T ： Data Update Ticket(DEV)) でない場合は、ステップ S 5 29に進む。

チケットタイプがデータアップデ一トチケット- D EV (DUT (D E V)) である場合は、ステップ S 5 24において、チケヅトに記述された Integrity Check Type (チケット（Ticket) の正当性検証値の種別（公開鍵方式（Public) /共通鍵方式（Co隱 on))) の設定が公開鍵方式（Public)であるか否かを判定する。

正当性検証値の種別（Integrity Check Type) が公開鍵方式（Public)である場合、ステップ S 525に進み、各種処理を実行する。ステップ S 525で実行する処理は、まず、デバイスマネージャ対応認証局（CA (D E V)) の公開鍵 PU B C A (DEV) を用いたチケット発行者（Ticket Issuer) の公開鍵証明書（C ERT) の検証処理である。

データアップデ一トチケット- D E V (D UT (D E V))発行手段（DUT Issuer) の発行したチケット（Ticket) を、チケットユーザに対して送信する際には、公開鍵方式の場合、データアップデートチケット（DUT) 発行手段（DUT Issuer) の公開鍵証明書（CERT_DUTI) も一緒にデバイスに送信される。なお、 DUT発行手段の公開鍵証明書（CERT_DUTI) の属性（Attribute) は、デバイス内の DKD B (PUB) (Device Key Definition Block) (PUB)に記録されたチケット発行手段コード（DUTIC_DEV) の識別子（DUTIC)と一致する。

公開鍵証明書（図 1 1参照）にはデバイスマネージャ対応認証局（CA (D E V))の秘密鍵で実行された署名が付加されており、この署名をデパイスマネージャ対応認証局（CA (D E V)) の公開鍵 PUB C A (D E V) を用いて検証する。署名生成、検証は、例えば先に説明した図 1 2、図 1 3のフローに従った処理として実行される。この署名検証により、チケット発行者の公開鍵証明書（C ERT) が改竄されたものではない正当な公開鍵証明書（CERT) であるか否かが判定される。

さらに、ステップ S 52 5では、署名検証により正当性が確認されたチケット発行手段の公開鍵証明書（CERT) のオプション領域に記録されたユーザの所属コードと、デバイス内の DKDB (PUB) (Device Key Definition Block) (PUB)に記録されたチケット発行手段コード（DUTIC—DEV： MT Issuer Category for Device) と一致するか否かを判定する。

公開鍵証明書には、図 1 1の公開鍵証明書の説明の欄で記述したように、各チケット（PRT, FRT、 S PT、 DUT) の発行手段であるチケット発行手段 (Ticket Issuer) の所属コード、この場合、 DUT I C (DUT Issuer Code) が記録されている。このォプション領域のコ一ドとデバイス内の D KD B (PUB) (Device Key Definition Block) (PUB)に記録されたチケヅト発行手段コ一ド (DUTIC— DEV： DUT Issuer Category for Device) (図 1 6参照）の一致を確認することで、受信チケット（DUT) が正当なチケット発行手段によって発行されたチケットであることを確認する。

さらに、デバイスは、デバイスのメモリ部内のデバイス鍵領域（図 1 8参照）に格納された CRL_DEV (排除デバイス（Device)、排除機器（デバイスアクセス機器としてのリーダライタ、 P C等のチケットュ一ザ、チケット発行手段）の公開鍵証明書識別子（ex. シリアルナンパ： SN) を登録したリボケ一シヨンリスト（Revocation List (Certificate))) を参照して、チケット発行手段（Ticket Issuer) がリポークされていないかを判定する。

さらに、受信チケットであるデ一夕アップデ一トチケット- D EV (DUT (D E V)) (図 32参照）に記録された署名、すなわち Integrity Check Value (チケット（Ticket) の正当性検証値（公開鍵方式：署名（Signature)) の検証を実行し、チケットが改竄されていないかを確認する。署名検証は、先の公開鍵証明書の署名検証と同様、例えば図 1 3のフローと同様のシーケンスに従って実行される。

以上、（ 1 ) チケット発行者（Ticket Issuer) の公開鍵証明書（C E RT) が改竄されたものでない正当な公開鍵証明書（C E R T) であること、（2 ) チケット発行者（Ticket Issuer) の公開鍵証明書（C E R T) のオプション領域に記録されたコードと、デバイス内の D K D B (P UB) (Device Key Definition Block) (PUB)に記録されたチケット発行手段コード（DUTIC— DEV： DUT Issuer Category for Device) の一致、（ 3 ) チケット発行手段（Ticket Issuer) がリポークされていないこと、（4 ) 受信チケット（DUT) の署名（Signature) の検証によりチケットが改竄のないことの確認。以上のすべての確認がなされたことを条件としてデータアップデートチケット- D EV (DUT (D E V)) の正当性検証成功とする。上記（ 1 ) 〜（4 ) のいずれかが確認されない場合は、データアップデ —トチケット- D E V (D UT (D E V)) の正当性の確認が得られないと判定され、データアップデートチケット- D EV (DUT (D E V)) を利用した処理は中止される。

また、ステップ S 5 2 4において、チケットに記述された Integrity Check Type (チケット（Ticket) の正当性検証値の種別（公開鍵方式（Public) /共通鍵方式 (Co隨 on)))の設定が共通鍵方式（Co匪 on)であると判定された場合は、ステップ S 5 2 6において、データアップデートチケット- D E V (DUT (D E V)) に記述された Old Data Codeの示すデータがデバイス鍵領域（図 1 8参照）に格納された KdutJEVl (データアップデートチケット（D UT) の MAC検証用鍵）または、 Kdut_DEV2 (デ一夕更新用暗号鍵）であるか否かを判定する。

データアツプデ一卜チケット- D E V (D U T (D E V))に記述された Old Data Code (更新される古いデータのコード）の示すデータがデバイス鍵領域（図 1 8 参照）に格納された Kdut_DEVl (データアップデートチケット（DUT) の MA C検証用鍵）または、 Kdut_DEV2 (デ一夕更新用暗号鍵）である場合は、ステップ S 5 2 8において、デバイス鍵領域（図 1 8参照）に格納された Kdut_DEV3 (デ一夕アップデートチケット（DUT) の MAC検証用鍵）を用いて MA C検証処理を実行し、データアップデートチケット- D EV (D UT (D E V)) に記述された Old Data Code (更新される古いデータのコード）の示すデータがデバイス鍵領域（図 1 8参照）に格納された Kdut— DEVI (データアップデ一トチケット（D UT) の MAC検証用鍵）または、 Kdut_DEV2 (データ更新用暗号鍵）でない場合は、ステップ S 5 2 7において、デバイス鍵領域（図 1 8参照）に格納された KdutJEVl (デ一夕アップデートチケット（DUT) の MAC検証用鍵）を用いて MA C検証処理を実行する。

上述のように M A C検証鍵の使い分けを実行するのは、更新対象となっているデータが、 Kdut_DEVl (デ一夕アップデートチケット（DUT)の MAC検証用鍵）または、 Kdut_DEV2 (デ一夕更新用暗号鍵）である場合は、これらの鍵デ一夕が何らかの理由、例えば鍵情報の漏洩等により、使用を停止される予定の情報であるため、これらの更新対象データを用いた MAC検証を避けるためである。 MAC 検証処理は、先に説明した図 59の D E S暗号処理構成を用いた M A C値生成処理に従って実行される。

なお、デバイスは、デバイスのデバイス鍵領域（図 1 8参照）に新規に Kdut_DEVl (データアップデートチケット（DUT) の MAC検証用鍵）を格納する場合、以前に格納済みの Kdut_DEV3 (データアップデートチケット（DUT) の MAC 検証用鍵）とのスワップ、すなわち入れ替え処理を行なう。さらに、新規に Kdut_DEV2(データ更新用暗号鍵）を格納する場合も、以前に格納済みの Kdut_DEV4 (データ更新用暗号鍵）とのスワップ、すなわち入れ替え処理を行なう。

この、 Kdut— DEVIと、 Kdut_DEV3とのスワップ、および、 Kdut_DEV2と、 Kdut_DEV4 とのスワップ処理によって、常に Kdut_DEV3 (データアップデートチケット（D UT)の MAC検証用鍵）、 Kdut_DEV4 (デ一夕更新用暗号鍵）のペアが Kdut_DEVl (デ一夕アップデートチケット（DUT) の MAC検証用鍵）、 Kdut— DEV2 (デ一夕更新用暗号鍵）のペアよりも新しいバージョンのものに維持される。つまり、 KdutJEVl と、 Kdut_DEV2の鍵は常に使用される鍵で、 Kdut_DEV3 と、 Kdut— DEV4 は、非常時に Kdut_DEVl と、 Kdut_DEV2を更新するとともに、現在使用されている Kdut— DEVI と、 Kdut_DEV2の鍵に置き換えられるバックアップ用の鍵としての役割がある。なお、これらの処理については、後段のデータアップデートチケット（DUT) を用いたデ一夕更新処理の説明において、さらに説明する。改竄のないことが保証された例えばデータ送信側がデータ生成時に生成した I C V (Integrity Check Value) と、データ受信側が受信データに基づいて生成した I CVとを比較して同一の I CVが得られればデータに改竄のないことが保証され、 I CVが異なれば、改竄があつたと判定される。改竄のないことが保証された例えばデータ送信側がデータ生成時に生成した I CVは、図 32のデ一夕ァップデートチケット（DUT) のフォーマットに関する記述において説明したように、データアップデ一トチケット（DUT) の I CV (Integrity Check Value) フィ一ルドに格納されている。

デバイスが生成した I CVと受信チケットであるデータアップデ一トチケット -D E V (DUT (D E V)) に格納された I C Vとを比較して一致していればチケットの正当性ありと判定し、不一致の場合はチケット改竄ありと判定し、デ一夕アップデートチケヅト- DEV (DUT (D EV)) を利用した処理を中止する。上述の処理によってデータアップデートチケット- D E V (DUT (D E V)) に記述された Integrity Check Typeが共通鍵方式である場合のデータアツプデ一トチケット- D EV (D U T (D E V)) 検証処理が完了する。

ステップ S 5 2 3において、チケットタイプがデータアップデ一トチケット- DEV (D UT (D E V)) でないと判定された場合は、チケットは、データアツプデートチケット- PAR (DUT (PAR)) (図 3 2参照））であると判定される。データアップデートチケット- PAR (DUT (PAR)) は、パーティションマネージャの管理データを更新する処理に適用するチケットである。

この場合、ステップ S 52 9において、チケットに記述された Integrity Check Type (チケット（Ticket) の正当性検証値の種別（公開鍵方式（Public) /共通鍵方式（Co匪 on))) の設定が公開鍵方式（Public)であるか否かを判定する。

正当性検証値の種別（Integrity Check Type) が公開鍵方式（Public)である場合、ステップ S 530に進み、各種処理を実行する。ステップ S 530で実行する処理は、まず、パ一ティションマネージャ対応認証局（ C A (PAR)) の公開鍵 PUB C A (PAR) を用いたチケット発行者（Ticket Issuer) の公開鍵証明書（CERT) の検証処理である。

データアップデ一トチケット- PAR (DUT (P AR))発行手段（DUT Issuer) の発行したチケット（Ticket) を、チケットユーザに対して送信する際には、公開鍵方式の場合、データアップデートチケット（DUT) 発行手段（DUT Issuer) の公開鍵証明書（CERTJUTI) も一緒にデバイスに送信される。なお、 DUT発行手段の公閧鍵証明書（CERT_DUTI) の属性（Attribute) は、デバイス内の PKD B (PUB) (Pqrtition Key Definition block) に記録されたチケット発行手段コード（DUTIC_PAR)と一致する。

公開鍵証明書（図 1 1参照）にはパーティションマネージャ対応認証局（CA (PAR))の秘密鍵で実行された署名が付加されており、この署名をパーティシヨンマネージャ対応認証局（CA (PAR)) の公開鍵 PUB CA (PAR) を用いて検証する。署名生成、検証は、例えば先に説明した図 1 2、図 1 3のフロ —に従った処理として実行される。この署名検証により、チケット発行者の公開鍵証明書（CERT) が改竄されたものでない正当な公開鍵証明書（CERT) であるか否かが判定される。

さらに、ステップ S 53 0では、署名検証により正当性が確認されたチケット発行手段の公開鍵証明書（CERT) のオプション領域に記録されたユーザの所属コードと、デバイス内の PKDB (PUB) (Pqrtition Key Definition block) に記録されたチケット発行手段コード（DUTIC_PAR:DUT Issuer Category for Partition)と一致するか否かを判定する。

公開鍵証明書には、図 1 1の公開鍵証明書の説明の欄で記述したように、各チケット（PRT, FRT、 S PT、 DUT) の発行手段であるチケット発行手段 (Ticket Issuer) の所属コード、この場合、 DUT I C (DUT Issuer Code) が記録されている。このォプション領域のコ一ドとデバイス内の P K D B (PUB) (Pqrtition Key Definition block) に記録されたチケット発行手段コード (DUTIC:DUT Issuer Category) (図 2 1参照）の一致を確認しすることで、受信チケット（DUT) が正当なチケット発行手段によって発行されたチケットであることを確認する。

さらに、デバイスは、デバイスのメモリ部内のデバイス鍵領域（図 1 8参照）に格納された CRL_DEV (排除デパイス（Device), 排除機器（デバイスアクセス機器としてのリーダライ夕、 P C等のチケットユーザ、チケット発行手段）の公開鍵証明書識別子（ex. シリアルナンパ： SN) を登録したリポケ一シヨンリスト（Revocation List (Certificate))) を参照して、チケット発行手段（Ticket Issuer) がリポークされていないかを判定する。

さらに、受信チケヅトであるデータアップデートチケット- P A R (D U T (P AR)) (図 3 2参照）に記録された署名、すなわち Integrity Check Value (チケット（Ticket) の正当性検証値（公開鍵方式：署名（Signature)) の検証を実行し、チケットが改竄されていないかを確認する。署名検証は、先の公開鍵証明書の署名検証と同様、例えば図 1 3のフローと同様のシーケンスに従って実行される。

以上、（ 1 ) チケット発行者（Ticket Issuer) の公開鍵証明書（CERT) が改竄されたものでない正当な公開鍵証明書（CERT) であること、（2)チケット発行者（Ticket Issuer) の公開鍵証明書（CERT) のオプション領域に記録されたコ一ドと、デバイス内の P K D B (PUB) (Pqrtition Key Definition block) に記録されたチケット発行手段コード（DUTIC_PAR:DUT Issuer Category for Partition)の一致、（3) チケット発行手段（Ticket Issuer) がリボ一クされていないこと、（4) 受信チケット（DUT) の署名（Signature) の検証によりチケットが改竄のないことの確認。以上のすべての確認がなされたことを条件としてデータアップデートチケット- PAR (DUT)の正当性検証成功とする。上記（ 1 ) ~ (4) のいずれかが確認されない場合は、データアップデートチケット -PAR (DUT (PAR)) の正当性の確認が得られないと判定され、デ一夕アップデートチケット- PAR (DUT (PAR)) を利用した処理は中止される。

また、ステップ S 529において、チケッ卜に記述された Integrity Check Type (チケット（Ticket) の正当性検証値の種別（公開鍵方式（Public) /共通鍵方式 (Common)))の設定が共通鍵方式（Co瞧 on)であると判定された場合は、ステップ S 53 1において、データアップデ一トチケット- PAR (DUT (PAR)) に記述された Old Data Code (更新される古いデ一夕のコード）の示すデータがパーテイシヨン鍵領域（図 23参照）に格納された Kdut_PARl (データアップデートチケット（DUT)の MAC検証用鍵）または、 Kdut_PAR2 (データ更新用暗号鍵）であるか否かを判定する。

データアップデ一トチケット- PAR (DUT (PAR))に記述された Old Data Code (更新される古いデ一夕のコ一ド）の示すデータがパーティション鍵領域（図 23参照）に格納された Kdut_PARl (データアップデートチケット（DUT) の MAC検証用鍵）または、 Kdut_PAR2 (データ更新用暗号鍵）である場合は、ステヅプ S 5 3 3において、パーティション鍵領域（図 2 3参照）に格納された Kdut_PAR3 (データアツプデ一トチケット（D U T) の MA C検証用鍵）を用いて M A C検証処理を実行し、データアップデートチケット- PAR(DUT(PAR)) に記述された Old Data Code (更新される古いデータのコード）の示すデ一夕がパーティション鍵領域（図 23参照）に格納された Kdut_PARl (デ一夕アップデ —トチケット（DUT) の MAC検証用鍵）または、 Kdut_PAR2 (データ更新用暗号鍵）でない場合は、ステップ S 5 3 2において、パ一テイション鍵領域（図 2 3参照）に格納された Kdut_PARl (データアップデートチケット（DUT) の M AC検証用鍵）を用いて MA C検証処理を実行する。

上述のように MA C検証鍵の使い分けを実行するのは、更新対象となっているデータが、 Kdut_PARl (データアップデ一トチケット（DUT)の MAC検証用鍵）または、 Kdut_PAR2 (デ一夕更新用暗号鍵）である場合は、これらの鍵データが何らかの理由、例えば鍵情報の漏洩等により、使用を停止される予定の情報であるため、これらの更新対象データを用いた MA C検証を避けるためである。 MAC 検証処理は、先に説明した図 59の D E S暗号処理構成を用いた MA C値生成処理に従って実行される。

改竄のないことが保証された例えばデ一夕送信側がデータ生成時に生成した I C V (Integrity Check Value) と、データ受信側が受信データに基づいて生成した I CVとを比較して同一の I CVが得られればデータに改竄のないことが保証され、 I CVが異なれば、改竄があつたと判定される。改竄のないことが保証された例えばデータ送信側がデータ生成時に生成した I C Vは、図 32のデータァップデートチケット（DUT) のフォーマットに関する記述において説明したように、データアップデートチケット（DUT) の I CV (Integrity Check Value) フィールドに格納されている。デバイスが生成した I CVと受信チケットであるデータアップデ一トチケット -PAR (DUT (PAR)) に格納された I C Vとを比較して一致していればチケットの正当性ありと判定し、不一致の場合はチケット改竄ありと判定し、デ一夕アップデ一トチケット- PAR (DUT (PAR))を利用した処理を中止する。上述の処理によってデータアップデートチケット- PAR (DUT (PAR)) に記述された Integrity Check Typeが共通鍵方式である場合のデータアツプデートチケット- PAR (DUT (PAR)) 検証処理が完了する。

以上の処理においてチケットの正当性が確認された後、図 58のステップ S 5 4 1に進み、以下、利用者チェック、すなわちチケットユーザとしてデパイスとの通信を実行中のデバイスアクセス機器としてのリーダライタ（または P C等）のチヱックを実行する。

ステップ S 54 1において、デバイスは、受信チケット（PRT, FRT， S P T , または D.UT) の Authentication Flag (チケット（Ticket) の利用処理においてデバイス（Device) との相互認証が必要か否かを示すフラグ）をチエツクする。フラグが認証不要を示している場合は、処理を実行することなく終了する。

ステップ S 541におけるフラグチェック処理において、フラグが認証必要を示している場合は、ステップ S 542に進み、チケットユーザ（デバイスに対するチケットを適用した処理を実行しょうとするデパイスアクセス機器としてのリ一ダライタ、 P C等）の所属（グループ）をキーとして認証テーブル（図 5 1参照）を参照する。

次に、ステップ S 543において、受信チケットの Authentication Type (デバイス（Device) の相互認証のタイプ（公開鍵認証、または、共通鍵認証、または、いずれでも可（Any)) を記録したデータ）をチェックし、いずれでも可（Any) である場合、ステップ S 544に進み、ステップ S 542でチェックしたグループの相互認証データが認証テーブル（図 5 1参照）に格納されているか否かを判定する。テーブルに対応グループの相互認証情報が格納され、チケットユーザ（デバイスに対するチケットを適用した処理を実行しょうとするデバイスアクセス機器としてのリーダライタ、 P C等）とデバイス間の相互認証済みであることが判定されれば、チケット利用者（ex. デバイスアクセス機器としてのリーダライ夕）の正当性が確認されたものとして処理を利用者チヱック成功と判定して終了する。認証テーブル（図 5 1参照）に対応グループの相互認証情報が格納されていない場合は、利用者チェックが未了であると判定され、エラ一終了とする。ステップ S 543において、受信チケットの Authentication Type (デバイス (Device) の相互認証のタイプ（公開鍵認証、または、共通鍵認証、または、いずれでも可（Any)) を記録したデ一夕）がいずれでも可（Any) でない場合、ステップ 545において、 Authentication Type が公閧鍵認証であるか否かを判定する。

Authentication Type が公開鍵認証である場合、ステップ S 546に進み、ステツプ S 542でチェックしたグループの公開鍵相互認証データが認証テーブル (図 5 1参照）に格納されているか否かを判定する。テ一ブルに対応グループの公開鍵相互認証情報が格納され、チケットユーザ（デバイスに対するチケットを適用した処理を実行しょうとするデバイスアクセス機器としてのリーダライタ、 P C等）とデバイス間の相互認証が公開鍵認証処理として成立済みであることが判定された場合は、ステップ S 547に進み、処理対象チケット（PRT， F R T, S PTまたは DUT) にチケットユーザの識別子が存在するか否かを判定して存在する場合は、ステップ S 548において認証相手（チケットユーザであるデバイスアクセス機器としてのリ一ダライタなど）の公開鍵証明書中の識別デ一タ（DN) として記録された識別子またはカテゴリまたはシリアル（SN) とチケットに格納されたチケットュ一ザの識別データとして記録された識別子またはカテゴリまたはシリアル（SN)がー致するか否かを判定する。一致する場合は、利用者確認成功として処理を終了する。

ステップ S 546において、ステップ S 542でチェックしたグループの公開鍵相互認証データが認証テーブル（図 5 1参照）に格納されておらず、チケットユーザ（デバイスに対するチケットを適用した処理を実行しょうとするデバイスアクセス機器としてのリ一ダライタ、 P C等）とデバイス間の相互認証が公開鍵認証処理として成立済みでないと判定された場合は、利用者チェック未了と判定されエラー終了する。また、ステップ S 548において認証相手（チケットュ一ザであるデバイスァクセス機器としてのリ一ダライタなど）の公開鍵証明書中の識別デ一夕（DN) として記録された識別子またはカテゴリまたはシリアル（SN) とチケットに格納されたチケットユーザの識別子が一致しないと判定された場合も利用者チエツク未了と判定されエラ一終了する。

なお、チケットにチケットユーザの識別子が存在しない場合は、ステップ S 5 48の処理は実行せず、利用者確認成功として処理を終了する。

ステップ S 545において、受信チケットの Authentication Type (デバイス (Device) の相互認証のタイプ（公開鍵認証、または、共通鍵認証、または、いずれでも可（Any)) を記録したデータ）が公開鍵認証でないと判定された場合、ステップ S 549に進み、ステップ S 542でチェックしたグループの共通鍵相互認証データが認証テーブル（図 5 1参照）に格納されているか否かを判定する。テーブルに対応グループの共通鍵相互認証情報が格納され、チケットユーザ（デバイスに対するチケットを適用した処理を実行しょうとするデバイスアクセス機器としてのリーダライタ、 P C等）とデバイス間の相互認証が共通鍵認証処理として成立済みであることが判定された場合は、ステップ S 550に進み、処理対象チケット（PRT, FRT， 3 ?丁または011丁）にチケットユーザの識別子が存在するか否かを判定して存在する場合は、ステップ S 55 1において認証相手（チケットユーザであるデバイスアクセス機器としてのリーダライタなど）の識別データ（I D rw) とチケットに格納されたチケットユーザの識別子が一致するか否かを判定する。一致する場合は、利用者確認成功として処理を終了する。ステップ S 549において、ステップ S 542でチェックしたグループの共通鍵相互認証デ一夕が認証テーブル（図 5 1参照）に格納されておらず、チケットユーザ（デバイスに対するチケットを適用した処理を実行しょうとするデバイスアクセス機器としてのリーダライタ、 P C等）とデバイス間の相互認証が共通鍵認証処理として成立済みでないと判定された場合は、利用者チェック未了と判定されエラ一終了する。

また、ステップ S 55 1において認証相手（チケヅトュ一ザであるデバイスァクセス機器としてのリーダライタなど）の識別データ（ I D rw) とチケットに格納されたチケットュ一ザの識別子が一致しないと判定された場合も利用者チェック未了と判定されエラ一終了する。

なお、チケットにチケットユーザの識別子が存在しないか、すべてのチケットユーザが利用可能の場合は、ステップ S 550の処理は実行せず、利用者確認成功として処理を終了する。

以上が、図 47のフ口一中のステップ S 4 1 3においてデパイスが実行するチケヅトの正当性および利用者チェック処理である。

(パ一テイション作成削除処理）

次に、図 47のフローに示すステップ S 4 1 5において実行されるパ一ティシヨン登録チケット（PRT) に基づくパーティションの生成、削除処理の詳細について、図 60、図 6 1の処理フ口一を用いて説明する。パ一ティションの作成、削除処理は、チケットユーザ（ex. デバイスアクセス機器としてのリーダライ夕、 P C等）からパーティション登録チケット（P RT) を受信したデバイスが、パーティション登録チケット（PRT) に基づいて実行する処理である。

図 60のステップ S 60 1において、デバイスは、受信したパ一テイシヨン登録チケット（ P R T Partition Registration ticket) に記録された処理タイプ、すなわち Operation Type (パーティシヨン（Part ion)作成か削除かの指定（作成（Generate) / 削除（Delete))) を検証する。処理タイプ（Operation Type) が、パ一テイシヨン（Partition)作成である場合、ステップ S 602以下を実行し、パーティション（Partition) 削除である場合、ステップ S 62 1以下を実行する。

まず、パーティション作成処理について説明する。デバイスはステップ S 6 0 2において、パーティション登録チケット（PRT) に記述されたパーティションマネージャコード（PMC) と同一コードのパーティションがデバイスのメモリ部に存在するか否かを検証する。この判定は、デバイスのメモリ部のパ一ティション定義プロヅク（図 1 9参照）に受信チケヅト（P R T) の記述コ一ドと同一のコードが記述されているか否かを検証することによって判定可能である。すでにデバイスに同一コード（PMC) のパーティションが存在する場合は、同一コードを持つ重複パ一テイションの存在は許されず、パ一テイションの生成は実行せず、エラ一終了とする。同一コードのパーティションがデバイスに存在しない場合は、ステップ S 603において、デバイス管理情報ブロック（図 1 5 参照）のデバイス（Device) 内の空きブロック数（Free Block Number in Device) と、パーティション登録チケット（P RT) に記述されたパーティションサイズ (Partion Size) とを比較し、チケット（PRT) に記述されたパーティションサイズ（Partion Size) 以上の空きブロック領域がデバイスのメモリ部に存在するか否かを判定する。存在しない場合は、 PRTに記述されたサイズのパーティシヨンの生成はできないので、エラ一終了とする。

チケット（P RT) に記述されたパーティションサイズ（Partion Size) 以上の空きブロック領域がデバイスのメモリ部に存在すると判定された場合は、ステップ S 604に進み、デバイス管理情報プロックの空き領域ポィンタ（Pointer of Free Area) を参照してデバイスの空き領域（Free Area in Device) の最上位ブロックにパ一テイション定義プロック（P D B ) エリア（図 1 9参照）を確保する。

次に、デバイスは、確保したパーテイション定義プロック（P D B ) エリアに、パーティション登録チケット（PRT) に記述されたパーティションマネージャコード（PMC) のコピー（S 605 )、 PRTに記述された P M Cバージョンのコピ一、（S 606 ) を実行する。

さらに、パーティション定義ブロック（PDB) エリアのパーティションスタ —ト位置（Partition Start Position) に、デバイス管理情報ブロック（図 1 5 参照）の空き領域ポインタ（Pointer of Free Area) のコピー処理を実行（S 6 0 7) し、さらに、パ一テイション定義プロック（P D B ) エリァのパ一ティションサイズ（Partion Size) にパーティション登録チケヅト（PRT) に記述されたパ一テイションサイズ（Partion Size) のコピー処理を実行（ S 6 08 ) する。

次に、デバイス管理情報ブロック（図 1 5参照）の空き領域ポインタ（Pointer of Free Area) にパ一テイション定義プロック（ P D B ) エリァのパ一テイションサイズ（Partion Size) にコピーした値を加算（S 60 9 ) し、デバイス管理情報プロック（図 1 5参照）のデパイス（Device)内の空きプロック数（Free Block Number in Device) からパーティションサイズ（Partion Size) + 1を減算する ( S 6 1 0 )。なお、 + 1は、パ一テイション定義ブロック（PDB) 用のブロックを意味する。

次にデパイス管理情報ブロック（図 1 5参照）のパ一テイション数（Partition Number) に 1を加算、すなわち生成したパーティション数（ 1) を加算する（S 6 1 1 )₀

次に、図 6 1のステップ S 63 1において、生成したパーティション領域の最上位ブロックをパーティション管理情報ブロック（ P M I B ： partition Management Information Block) (図 20参照）として設定し、設定したパ一ティシヨン管理情報ブロック（PMI B) のパーティションマネージャコード（PM C) フィールドにパーティション登録チケット（PRT) の PMCのコピー処理を実行（S 632 ) し、パーティション管理情報プロック（PM I B) の PMC バ一ジョンフィールドにパーティション登録チケット（PRT) の PMCバージョンのコピー処理を実行（S 633) し、パーティション管理情報プロック（P M I B) のパーティション総ブロック数（Total Block number in Partition) フィ一ルドにパーティション登録チケット（P R T) のパーティションサイズ (Partion Size) のコピー処理を実行（S 6 34 ) する。

さらに、パーティション管理情報ブロック（PM I B) のパーティション空きブロック数（Free Block number in Partition) フィールドにパーティション登録チケヅト（PRT) のパ一ティションサイズ（Partion Size) 一 3を記録（S 6 35 ) する。なお、一 3の意味は、既に使用が予定されているパ一テイシヨン管理情報プロック（P M I B )、共通鍵系パ一テイション鍵定義プロック（ P KD B(co匪 on))、公開鍵系パーティション鍵定義ブロック（PKDB(PUB)) の 3ブロックを差し引くことを意味している。

さらに、パーティション管理情報ブロック（PM I B) のファイル数（File Number) に 0を記入（ S 6 36 ) する。この時点ではパーテイシヨン内にはファィルは設定されていない。ファイル設定はファイル登録チケット（FRT) を使用して設定可能である。このファイル登録チケット（FRT) を使用したフアイル登録処理については後述する。さらに、パーティション管理情報ブロック（PM I B) の空き領域ポインタ (Pointer of Free Area) にパ一テイション定義プロック（ P D B ) のスタートポジション（Start Position) をコピーしてパーティションの設定登録を終了する o

次に図 60のステップ S 62 1〜S 628のパ一テイション削除処理について説明する。ステップ S 6 2 1では、パ一ティシヨン登録チケット（PRT) に記述されたパーティションマネージャコード（PMC) と同一コードのパ一テイシヨンがデバイスのメモリ部に存在するか否かを検証する。この判定は、デバイスのメモリ部のパーティション定義ブロック（図 1 9参照）に受信チケット（P R T) の記述コードと同一のコードが記述されているか否かを検証することによつて判定可能である。

デバイスに同一コード（PMC) のパーティションが存在しない場合は、パーテイシヨンの削除は不可能であるので、エラー終了とする。同一コードのパーテイシヨンがデバイスに存在する場合は、ステップ S 622において、削除対象のパーティシヨンより後に生成されたパーティションがデバイスに存在するか否かを判定する。存在しない場合は、削除対象のパーティションが最新のパ一テイションであり、ステップ S 6 29において削除対象のパ一テイションのパーティション定義プロック（P D B ) (図 1 9参照）を削除する。

ステップ S 622において、削除対象のパーティシヨンより後に生成されたパ —テイシヨンがデバイスに存在すると判定された場合は、後に生成されたパーテイシヨン（後パ一ティション）のデ一夕を削除対象のパーティシヨンのサイズ（P

5 ) 分、下位にずらす処理を実行（S 623 ) し、さらに、後パーティションのパーティション定義ブロック（PD B)を 1ブロック上位にずらす処理を実行（S

6 24 ) する。また、後パ一テイシヨンのパーティション定義プロック（P D B ) に記録されたパーティション開始位置（Partition Start Portion) から削除パ一テイシヨンのサイズ（P S) を減算する処理を実行する（S 625 )。

ステップ S 625または S 629の処理の後、ステップ S 626において、デバイス管理情報プロック（DMI B) (図 1 5参照）のデバイス（Device) 内の空きブロック数（Free Block Number in Device) に削除パ一テイシヨンのサイズ（P S) + 1を加算する。 + 1は、削除パーティションのパーティション定義ブロヅク（PDB) 用のブロックを意味する。

次にステップ S 627において、デバイス管理情報ブロック（図 1 5参照）の空き領域ポインタ（Pointer of Free Area) の値から削除パーティションのサイズ（P S) を減算する。さらに、ステップ S 6 28において、デバイス管理情報ブロック（図 1 5参照）のパ一テイション数（Partition Number) から 1を減算、すなわち削除したパーティション数（ 1 ) を減算してパーティション登録チケヅト（PRT) に基づくパーティション削除処理が終了する。

以上が、図 47の処理フ口一におけるステップ S 4 1 5のパーティション登録チケット（PR T) に基づくパーティション生成、削除処理である。

(パーティシヨン初期登録）

次に、図 47の処理フ口一におけるステップ S 406， S 4 1 9のパーティシヨン初期データ書き込み処理、すなわちパーティション登録チケット（PRT) に基づくパーティション初期登録処理の詳細について図 6 2以下のフ口一を用いて説明する。

図 62、図 6 3、図 64に示す処理フローにおいて、左側がパーテイシヨンマネージャの管轄する初期登録装置の処理、右側がデバイス（図 5参照）の処理を示す。なお、パーティションマネージャの管轄する初期登録装置は、デバイスに対するデータ読み取り書き込み処理可能な装置（ex. デバイスアクセス機器としてのリーダライタ、 P C) であり、図 1 0のデバイスアクセス機器としてのリ —ダライタに相当する構成を有する。図 47の処理フローに示すように、図 6 2 の処理開始以前に、初期登録装置とデバイス間では、相互認証が成立し、チケットの正当性、利用者チェックにおいてチケットおよび利用者（チケットユーザであるデバイスアクセス機器としてのリーダライタなど）の正当性が確認され、さらにパーティション登録チケット（P RT) に基づくパーティション生成処理が終了しているものとする。また、図 6 2、図 6 3、図 64の初期登録装置と、デバイス間のデータの送受信は、相互認証時に生成したセッション鍵 K s e sを用いて暗号化されたデ一夕として送受信される。

図 62のステップ S 6 1において、初期登録装置は、パーティション認証に共通鍵を用いるか否かを判定する。この判定は、使用するパーティション登録チケット（PRT) (図 26参照）の Authentication Type (デバイス（Device) の相互認証のタイプ（公開鍵認証、または、共通鍵認証、または、いずれでも可（Any))) フィ一ルドを参照して行われる。

図 62に示すように、パーティション認証に共通鍵を用いる場合、ステップ S 642〜 643、 S 65 1〜S 6 54を実行し、パ一テイション認証に共通鍵を用いない場合、これらのステップは省略される。

パーティション認証に共通鍵を用いる場合、ステップ S 642において初期登録装置は、共通鍵認証データ書き込みコマンドとして、 MKauth— PAR_A：双方向個別鍵認証用マスタ一鍵、 Kauth— PAR_B ：双方向個別鍵認証用共通鍵、 IRL— PAR ：排除デバイス（Device) のデパイス識別子（I D) を登録したリボケ一シヨンリスト（Revocation List (Device ID)), およびこれらのバ一ジョン情報をデバイスに送信する。

ステップ S 6 5 1でデバイスは、上述の書き込みコマンドを受信し、ステップ S 652において、受領データをパーティション鍵領域（図 23参照）に書き込む。次にデータ書き込みによって生じたポインタ、サイズ、デバイス内のフリープロック数の調整を実行（ S 65 3 ) し、書き込み終了通知を登録装置に送信（ S 6 54 ) する。

書き込み終了通知を受信（S 643 ) した登録装置は、ステップ S 644においてパーティション認証に公開鍵を用いるか否かを判定する。図 62に示すように、パーティション認証に公開鍵を用いる場合、ステップ S 645 ~ 649、 S 6 55〜S 66 2を実行し、パーティション認証に公開鍵を用いない場合、これらのステツプは省略される。

パーティション認証に公開鍵を用いる場合、ステップ S 645において登録装置は、公開鍵認証デ一夕書き込みコマンドとして、 PUB_CA(PAR)：パ一ティシヨンマネージャ対応公開鍵証明書を発行する認証局 C A ( P A R) の公開鍵、 PARAM_PAR：パーティション（Partition) の公開鍵パラメ一夕、 CRL_PAR：排除デバイス（Device) の公開鍵証明書識別子（ex. シリアルナンパ： SN) を登録したリボケ一シヨンリスト（Revocation List (Certificate)), およびこれらのバージョン情報をデパイスに送信する。

ステップ S 6 55でデパイスは、上述の書き込みコマンドを受信し、ステップ

5656において、受領データをパーティション鍵領域（図 23参照）に書き込む。次にデータ書き込みによって生じたポインタ、サイズ、デバイス内のフリ一ブロック数の調整を実行（S 657 ) し、書き込み終了通知を登録装置に送信（ S

658 ) する。

書き込み終了通知を受信（S 646 ) した登録装置は、公開鍵と秘密鍵の鍵ぺァ生成コマンドをデバイスに送信（S 647 ) する。なお、この実施例では、鍵ペアの生成はデバイスが実行する構成としているが、例えば登録装置が実行してデバイスに提供する構成としてもよい。

鍵ペア生成コマンドを受信（S 65 9 ) したデバイスは、デバイス内の暗号処理部（図 5参照）において公開鍵（PUB PAR) と秘密鍵（PR I PAR) のペアを生成し、生成した鍵をパーティション鍵領域（図 23参照）に書き込む ( S 660 )。次にデータ書き込みによって生じたポィンタ、サイズ、デバイス内のフリーブロック数の調整を実行（ S 66 1 ) し、生成格納した公開鍵を登録装置に送信（ S 6 62 ) する。

登録装置は、デバイスから公開鍵（PUB PAR) を受信（S 648) し、先にデバイスから受信したデバイスの識別子 I Dmとともに、パーティションマネ —ジャ内のデータベース（DB (PAR)) (図 9参照））に保存する。

次に、パーティションマネージャの登録装置は、ファイル登録チケット（FR T ： File Registration Ticket) の検証処理に共通鍵を用いるか否かを判定（S 67 1 ) する。チケット検証には、前述したように MAC値検証等による共通鍵方式と、秘密鍵による署名生成、公開鍵による署名検証を行なう公開鍵方式のいずれかを適用することが可能であり、パーティションマネージャは、デパイスの採用する検証処理方式を設定することができる。パーティションマネージャは、デバイスの採用する F R Tチケット検証方式に応じて共通鍵、公開鍵のいずれか、あるいは両方式を実行可能なデータをデバイスに設定する。

パーティションマネージャは、ファイル登録チケット（ F R T : File Registration Ticket) の検証処理に共通鍵認証を実行する設定とする場合は、共通鍵方式の F R T検証に必要な情報（ex. FRT検証共通鍵）をデバイスにセットし、デバイスが共通鍵認証を実行しないデバイスであれば、これらの情報をデバイスに格納しないことになる。

図 6 3に示すように、 F R T検証に共通鍵方式を用いる場合、ステップ S 67 2〜6 7 3、 S 68 1〜S 684を実行し、 F R T検証に共通鍵を用いない場合、これらのステツプは省略される。

F R T検証に共通鍵を用いる場合、ステップ S 672において登録装置は、 F RT検証共通鍵書き込みコマンドとして、 Kfrt：ファイル登録チケット（FRT) の M A C検証用鍵、およびパージョン情報をデバイスに送信する。

ステップ S 68 1でデバイスは、上述の書き込みコマンドを受信し、ステップ

5682において、受領データをパーティション鍵領域（図 23参照）に書き込む。次にデータ書き込みによって生じたポインタ、サイズ、デバイス内のフリープロック数の調整を実行（ S 683 ) し、書き込み終了通知を登録装置に送信（ S

684) する。

書き込み終了通知を受信（S 673 ) した登録装置は、ステップ S 674において F R T検証に公開鍵を用いるか否かを判定する。図 6 3に示すように、 FR T検証に公開鍵を用いる場合、ステップ S 6 7 5〜 676、 S 685〜S 6 90 を実行し、 F R T検証に公開鍵を用いない場合、これらのステップは省略される。

F R T検証に公開鍵を用いる場合、ステップ S 675において登録装置は、 F R T検証デ一夕書き込みコマンドとして、 FRTIC (FRT Issuer Category) ：フアイル登録チケット（FRT) 発行者カテゴリ、 PUB_CA(PAR)：パ一ティションマネ一ジャ対応公開鍵証明書を発行する認証局 C A (PAR)の公開鍵、 PARAM_PAR：パ —テイシヨン（Partition)の公開鍵パラメ一夕、 CRL_PAR：排除デバイス（Device) の公開鍵証明書識別子（ex. シリアルナンパ： S N) を登録したリボケ一ションリスト（Revocation List (Certificate)) およびこれらのパ一ジョン情報をデバイスに送信する。

ステップ S 685でデバイスは、上述の書き込みコマンドを受信し、ステップ S 686において、受領データ中の FRTIC (FRT Issuer Category) ：ファイル登録チケット（F R T) 発行者カテゴリを公開鍵系パーティション鍵定義プロック ( P K D B ： Partition Key Definition block (PUB) (図 22参照））に書き込みパージョン情報を同プロックのパージョン領域に書き込む。

次にデバイスは、ステップ S 687において、 PUB_CA(PAR)：パ一ティションマネ一ジャ対応公開鍵証明書を発行する認証局 C A (PAR) の公開鍵データが書き込み済みか否かを判定し、書き込まれていない場合にステップ S 688において、 PUB_CA(PAR)、 PARAM— PAR、 CRL_PAR をパーティション鍵領域（図 23参照）に書き込む。次にデータ書き込みによって生じたポインタ、サイズ、デバイス内のフリーブロック数の調整を実行（S 689 ) し、書き込み終了通知を登録装置に送信（S 69 0 ) する。

書き込み終了通知を受信（S 676 ) した登録装置は、次に、ステップ S 7 0 1において、共通鍵データの更新をサポ一トするデバィスとするか否かを判定する。デバイスに格納されたデータ中、そのいくつかは更新対象データとして前述したデ一夕アツプデ一トチケット（DUT : Data Update Ticket) (図 32参照）を用いて更新が可能である。更新対象となるデータは、先に図 33を用いて説明した通りである。このデータアツプデ一トチケット（DUT： Data Update Ticket) を用いた更新処理においても共通鍵方式、または公開鍵方式のいずれかの方式が可能であり、パーティションマネージャは設定したパーティションに応じていずれかの方式または両方式を実行可能なデ一夕をデバイスを設定する。

パーティションマネージャは、設定したパーティションを共通鍵方式によるデ一夕更新を実行する構成とする場合は、共通鍵方式のデータ更新処理に必要な情報（ex. データアップデ一トチケット（DUT) の MAC検証用鍵他）をデバイスのパーティション鍵領域にセットし、デバイスが共通鍵認証を実行しないデバイスであれば、これらの情報をデバイスのパーティション鍵領域に格納しない処理をする。

図 6 4に示すように、デ一夕アップデートチケット（D UT : Data Update Ticket) を用いたデータ更新処理に共通鍵方式を用いる場合、ステップ S 7 02 〜70 3、 S 7 1 1〜S 7 14を実行し、データ更新に共通鍵方式を用いない場合、これらのステップは省略される。

データ更新に共通鍵を用いる場合、ステップ S 702において登録装置は、デ —夕アップデ一トチケット（DUT ： Data Update Ticket) 検証共通鍵書き込みコマンドとして、 Kdut_PARl：デ一夕アップデートチケット（DUT) の MAC検証用鍵、 Kdut_PAR2：データ更新用暗号鍵、 Kdut_PAR3：データアップデートチケット（DUT) の MAC検証用鍵、 Kdut_PAR4：データ更新用暗号鍵およびこれらのバージョン情報をデバイスに送信する。

ステップ S 7 1 1でデパイスは、上述の書き込みコマンドを受信し、ステップ S 7 1 2において、受領デ一夕をパーティション鍵領域（図 23参照）に書き込む。次にデータ書き込みによって生じたポインタ、サイズ、デバイス内のフリ一プロック数の調整を実行（ S 7 1 3) し、書き込み終了通知を登録装置に送信（ S 7 1 4 ) する。

書き込み終了通知を受信（S 7 03 ) した登録装置は、ステップ S 704において、デバイスに設定したパーティションが公開鍵方式を用いたデ一夕アップデ —トチケット（D U T ： Data Update Ticket) を使用したデータ更新処理をサポ —トするか否かを判定する。図 64に示すように、公開鍵方式をサポートする場合、ステップ S 7 05〜 7 06、 S 7 1 5〜S 7 1 8を実行し、公開鍵方式をサポートしない場合、これらのステップは省略される。

公開鍵方式をサポートする場合、ステップ S 7 0 5において登録装置は、デ一夕アップデ一トチケット（DUT ： Data Update Ticket) 発行者コ一ド書き込みコマンドとして、 DUTIC— PAR (DUT Issuer Category) ：データアップデートチケヅト（DUT ： Data Update Ticket) 発行者カテゴリ、およびバ一ジョン情報をデバイスに送信する。

ステップ S 7 1 5でデバイスは、上述の書き込みコマンドを受信し、ステップ S 7 1 6において、受領デ一夕を公開鍵系パーティシヨン鍵定義プロック（P K D B (PUB)： Partition Key Definition Block(PUB)) に書き込む。次にデ一タ書き込みによって生じたポインタ、サイズ、デバイス内のフリ一ブロック数の調整を実行（S 7 1 7) し、書き込み終了通知を登録装置に送信（S 7 1 8) し、登録装置が書き込み終了通知を受信（S 706 ) して処理を終了する。

パ一ティションマネージャによる初期登録処理（図 62〜図 64の処理フ口一）が完了した状態のデバイスのメモリ内格納データ構成例を図 65に示す。図 6 5 に示すパ一ティション（Partition)領域中、パ一テイション鍵領域には、上記のフ口一（図 62〜図 64) において、登録装置から送信されて下記のデータが書き込まれる。

* IRL_PAR ：パーティションアクセス排除デバイス（Device), 排除機器（デバイスアクセス機器としてのリーダライタ、 P C等のチケットユーザ、チケット発行手段）の識別子（I D) を登録したリボケ一シヨンリスト（Revocation List (Device ID))

* CRL_PAR ：パーティションアクセス排除デパイス（Device), 排除機器（デバイスアクセス機器としてのリーダライタ、 P C等のチケットユーザ、チケット発行手段）の公開鍵証明書識別子（ex. シリアルナンパ： SN) を登録したリボケ一シヨンリスト (Revocation List (Certiticate)

* Kauth_PAR_B ：双方向個別鍵認証用共通鍵

* Mkauth_PAR_A ：双方向個別鍵認証用マスタ一鍵

* Kdut_PARl ：データアップデートチケット（D U T) の MA C検証用鍵 * Kdut_PAR2 ：データ更新用暗号鍵

* Kdut_PAR4 ：データ更新用暗号鍵

* Kfrt ：ファイル登録チケヅト（F RT) の MAC検証用鍵

また、

* PUB_PAR ：パーティション（Partition) の公開鍵

* PRし PAR ：パーティション（Partition) の秘密鍵

が、デバイスにおいて生成されて書き込まれる。

また、

* PARAM_PAR ：パーティション（Partition) の公開鍵パラメ一夕

* PUB_CA(PAR) ：認証局 C A (PAR) の公開鍵

共通鍵系パーティション鍵情報ブロック（ Partition Key Definition Block (Common))

公開鍵系パーティション鍵情報ブロック（ Partition Key Definition Block(PUB)) ノ一テイシヨン管理情報ブロック (Partition Management Information Block) の各データは、パ一テイションの生成時（処理フロー図 6 0、図 6 1参照）に書き込まれるデータである。

[B 4. 2. パーティションマネージャ管理下における公開鍵証明書発行処理]

次に図 66以下を用いて、パーティションマネージャによるパーティション対応公閧鍵証明書の発行処理について説明する。デバイスには、デバイス全体の認証、デパイスを単位とした処理に適用可能なデバイス対応公開鍵証明書（CER T D E V)と、デバイス内の特定のパ一テイションに対する処理の際の認証その他検証処理等に適用可能なパーティション対応公開鍵証明書（CERT PAR) が格納され得る。パーティション対応公開鍵証明書（CERT P AR) は、デバイスに設定されたパーティション毎に設定格納可能である。

パーティション対応公開鍵証明書（CERT PAR)は、パーティションマネ —ジャの管轄する登録局を介して認証局（CA f o r PM) (図 2、図 3参照）の発行した公開鍵証明書をデバイスに付与する手続きにより発行され、登録局はパ一テイションマネージャの管轄登録局が発行した公開鍵証明書（ CERT PA R) についての管理（デ一夕べ一ス 3 32 (図 9参照））を実行する。

図 66および図 67に従って、パーティションマネージャの管轄登録局による設定パーティションに対するパーティション対応公開鍵証明書（CERT PA R) の発行処理の手順を説明する。図 66 , 図 67において、左側がパーティションマネージャの管轄登録局の CERT (公開鍵証明書）発行装置、具体的には、図 9に示すパーティションマネージャの構成図における制御手段 3 3 1の処理、右側がデバイスの処理である。

まずステップ S 72 1において、 CERT発行装置は、パーティシヨン対応公開鍵証明書（CERT PAR)の発行対象となるデバイスのユーザ情報を取得し、証明書発行の許可（判定）を行ない発行対象となるデバイスとの通信路を確保する。パーティション対応公開鍵証明書（CERT PAR)の発行対象となるデバイスのユーザ情報は、例えばデパイスの初期登録時に生成したデータから取得可能である。なお、ユーザ情報はデバイスとの通信路設定後、デバイスから取得してもよい。通信路は、有線、無線を問わずデータ送受信可能な通信路として確保されればよい。

次に CERT発行装置は、ステップ S 722において、乱数 Rを含む認証デ一夕生成コマンドをデパイスに対して送信する。認証データ生成コマンドを受信（S 73 1 ) したデバイスは、受信乱数 Rと、デバイス識別子（ I Dm) の結合デ一夕にデバイス秘密鍵（PR I PAR) を適用してデジタル署名（S)の生成処理 (図 1 2参照）を実行（ S 732 ) する。デバイスは、デバイスの識別デ一タ（ I Dm) と署名（S) を CERT発行装置に送信する。

デバイスから識別データ（I Dm) と署名（S) を受信（S 723 ) した C E RT発行装置は、受信したデバイス識別デ一夕（ I Dm) を検索キ一としてデ一夕べ一ス DB (PAR) 3 32から格納済みのデバイス公閧鍵（PUB PAR) を取得する。さらに、取得したデバイス公開鍵（PUB PAR) を適用して署名 ( S ) の検証処理（図 1 3参照）を実行（ S 7 25 ) する。検証に成功しなかつた場合は、デバイスからの送信データは不正なデータであると判定し処理は終了する。

検証に成功した場合は、認証局（CA f o r PM) 6 20に対してパーティション対応公開鍵証明書（CERT PAR) の発行処理を依頼（ S 727 ) する < パーティションマネージャは認証局 6 20の発行したパーティション対応公開鍵証明書（CERT PAR) を受信（S 728 ) してデバイスに送信（S 729 ) する。

パーティションマネージャ（登録局）からパーティション対応公開鍵証明書（C E R T PAR)を受信したデバイスは、予めパ一テイション鍵領域（図 2 3参照）に格納済みの認証局の公開鍵（PUB CA (PAR)) を用いて受信したパーテイション対応公開鍵証明書（CERT PAR)の署名検証を実行する。すなわち公開鍵証明書には認証局の秘密鍵で実行され署名があり（図 1 1参照）、この署名検証（S 7 35 ) を行なう。

署名検証に失敗した場合は、正当な公開鍵証明書でないと判定し、エラ一通知を CERT発行装置に対して実行（S 745 ) する。

署名検証に成功した場合は、パーティション対応公開鍵証明書（CERT PA R) に格納されたデバイス公開鍵（P UB PAR) と自デバイスに保管されたデパイス公開鍵（PUB PAR) の比較を実行（S 7 4 1 ) し、一致しない場合はエラ一通知を実行し、一致した場合は、受信したパーティション対応公開鍵証明書（C E RT PAR) をパーティシヨン鍵領域（図 2 3参照）に格納（S 7 4 3 ) する。なお、パーティション対応公開鍵証明書（C E R T PAR) の発行以前は、この領域に自デバイスで生成した公開鍵（P UB PAR) を格納し、正当なパーティシヨン対応公開鍵証明書（C E R T PAR) が発行された時点で、パ一ティシヨン対応公開鍵証明書（ C ER T PAR)により上書きする処理として格納する。

パーティション対応公開鍵証明書（C E RT PAR)の格納が終了すると格納処理終了通知を C E R T発行装置に送信（S 7 44) する。 C E R T発行装置は、格納処理終了通知を受信（ S 7 5 1 ) し、格納成功を確認（ S 7 5 2 ) して処理を終了する。格納成功の確認が得られない場合はエラ一として処理が終了する。

[B 4. 3. パーティション生成処理各方式における処理手順]

上述したように、パーティションの設定登録処理において、パーティションマネージャの管理するデバイスアクセス機器としてのリ一ダライタとデバイス間において、相互認証が実行され、パーティション登録チケット（P RT) に基づくパーティションの設定がなされる。上述したように相互認証処理の態様は、公開鍵相互認証、共通鍵相互認証の 2種類のいずれかであり、またチケット（P RT) の検証処理も公開鍵系の署名検証、共通鍵系の MAC検証の 2種類のいずれかが実行されることになる。すなわち処理態様としては大きく分けて、

(A) 相互認証（公開鍵）、チケット（P RT) 検証（公開鍵）

(B) 相互認証（公開鍵）、チケット（P RT) 検証（共通鍵）

(C) 相互認証（共通鍵）、チケット（P RT) 検証（共通鍵）

(D) 相互認証（共通鍵）、チケット（P RT) 検証（公開鍵）

の 4態様がある。

これらの 4態様についての処理を、認証局（ CA (DM))、デバイスマネージャ（DM)、パーティションマネージャ（PM)、デバイス、各エンティティ間において実行されるデータ転送処理を中心として図を用いて簡潔に説明する。 (A) 相互認証（公開鍵）、チケット（PRT) 検証（公開鍵）まず、相互認証処理に公開鍵方式を適用し、チケット（PRT) 検証に公開鍵方式を適用する場合の各ェンティティ間のデータ転送について図 68を用いて説明する。なお以下では、説明を簡略化するために図 68に示すように、認証局（ C A) を 1つとし、登録局をデパイスマネージャ内に 1つ設定し、デバイスマネ一ジャ公開鍵証明書（C e r t · DM)、パーティションマネージャ公開鍵証明書（ C e r t . PM) の双方をこれらの各登録局、認証局を介して発行する構成とした。またパーティション登録チケット（P R T)の発行手段はデバイスマネージャ（D M) であり、パーティション登録チケット（PRT) に対する署名はデバイスマネージャの秘密鍵を用いて実行される。

図に示す番号順に各エンティティ間でデータ転送が実行される。以下、各番号に従って処理を説明する。

( 1 ) デバイスマネージャ（DM) の公開鍵証明書（C e r t . DM) の発行、公開鍵証明書（C e r t . DM) は、認証局（CA) によってデバイスマネ一ジャの発行要求により、登録局を介した証明書発行手続きによってデパイスマネージャに対して発行される。

(2) パーティションマネージャ（PM) の公開鍵証明書（C e r t . PM) の発行、

公開鍵証明書（C e r t . PM) は、認証局（C A) によってパーティションマネージャの発行要求により、登録局を介した証明書発行手続きによってパ一テイシヨンマネージャに対して発行される。

(3) パーティション登録チケット（PRT) の発行処理

パーティション登録チケット（PRT) は、デバイスマネージャの管理するパ

—ティション登録チケット発行手段（PRT Ticket Issuer) によりパーティシヨンマネージャ（PM) に対して発行される。この場合、公開鍵方式の署名生成、検証を実行するため、デバイスマネージャの秘密鍵による署名（Signature)が生成 (図 1 2参照）されて PRTに付加される。

(4) P R Tおよび DM公開鍵証明書（C e r t . DM) の PMに対する供給デパイスマネージャの管理するパ一テイション登録チケット発行手段（P R T Ticket Issuer) により発行されたパーティション登録チケット（PRT) は、 D M公開鍵証明書（C e r t . DM) とともにパーティションマネージャに対して送信される。

(5) PMとデバイス間の相互認証

発行された P RTに従ったパーティションを生成しょうとする対象のデバイスと、パーティションマネージャ（具体的にはチケットユーザであるデパイスァクセス機器としてのリ一ダライタ）は、公開鍵方式の相互認証（図 5 0参照）を実行する。

(6) P R Tおよび DM公開鍵証明書（C e r t . DM) のデバイスに対する供給

PMとデバイス間の相互認証が成立すると、パーティションマネージャ（PM) は、デバイスに対してパーティション登録チケット（PRT)、および DM公開鍵証明書（C e r t . DM) を送信する。

デバイスは、受信したパーティション登録チケット（PRT) について、（ 1 ) チケット発行者（Ticket Issuer) =DMの公開鍵証明書（CE RT) が改竄されたものでない正当な公開鍵証明書（CERT) であること、（2)チケット発行者 (Ticket Issuer) の公開鍵証明書（CERT) のオプション領域に記録されたコ —ドと、デバイス内の DKDB (Device Key Definition Block) (ΡϋΒ)に記録されたチケヅト発行手段コ一ド（P R T I C ： PRT Issuer Code) の一致、（ 3 ) チケット発行手段（Ticket Issuer) がリボークされていないこと、（4) 受信チケット（PRT) の署名（Signature) の検証によりチケットが改竄のないことの確認を実行し、さらに、 PRTチケットに格納された PRTユーザ（この場合は P M：チケットユーザであるデバイスアクセス機器としてのリ一ダライタ）と受信したパーティションマネージャの公開鍵証明書の識別データ（DN) として記録された識別子またはカテゴリまたはシリアル（SN) の一致を確認し、相互認証済みであることを確認することにより PRTユーザ（PM ：デバイスアクセス機器としてのリーダライタ）の検証（図 57、図 58参照）を実行する。

( 7 ) パ一テイションの生成

パーティション登録チケット（PRT) の検証、 PRT発行者（PRT Issuer), P R Tユーザの検証に成功すると、パーティション登録チケット（P R T) に記述されたルールに従ってパ一テイションがデパイスのメモリ部に生成（図 60、図 6 1参照）される。

( 8 ) 鍵データ書き込み

パーティションがデパイスのメモリ部に生成されると、生成されたパ一テイシヨン内に対する各種鍵の格納処理が実行される。

( 9 ) 公開鍵の読み出し、

( 1 0) 公開鍵証明書の発行

生成パーティションに対する各種サービス時の認証処理（パーティション生成、ファイル生成、ファイルアクセス、データアップデート等のサービス利用時の認証処理）に際し、公開鍵認証を行なう場合、デバイスは公開鍵、秘密鍵の鍵ペアを生成し、生成した公開鍵をパーティションマネージャに送信し、登録局、認証局を介して公開鍵証明書の発行処理を行ない、発行された公開鍵証明書をパーテイシヨン鍵領域（図 2 3参照）に格納する。この際、生成した公開鍵の格納領域に対して発行された公開鍵証明書を格納する。なお、この（9)、 ( 1 0) の処理は、作成パーティションに対する各種サービス時の認証処理（パーティション生成、ファイル生成、ファイルアクセス、データアップデート等のサービス利用時の認証処理）の際に公開鍵認証を行なう構成の場合に実行すればよい。

以上の処理によって、相互認証（公開鍵）、チケット（PRT) 検証（公開鍵）の各方式に従ったパ一テイションの生成処理が実行される。

(B) 相互認証（公開鍵）、チケット（P RT) 検証（共通鍵）

次に、相互認証処理に公開鍵方式を適用し、チケット（PRT) 検証に共通鍵方式を適用する場合の各ェンティティ間のデータ転送について図 69を用いて説明する。図に示す番号順に各エンティティ間でデータ転送が実行される。以下、各番号に従って処理を説明する。

( 1 ) パーティションマネージャ（PM) の公開鍵証明書（C e r t . PM) の発行、

公開鍵証明書（Ce r t . PM) は、認証局（CA) によってパーティションマネージャの発行要求により、登録局を介した証明書発行手続きによってデバイスマネージャに対して発行される。

(2) パーティション登録チケット（PRT) の発行処理

—ティション登録チケット発行手段（P RT Ticket Issuer) によりパ一ティシヨンマネージャ（PM) に対して発行される。この場合、共通鍵方式の検証値として M A C (Message Authentication Code) (図 59参照）が PRTに付加される _c

(3) PRTの PMに対ザる供給

デバイスマネージャの管理するパーティション登録チケット発行手段（P R T Ticket Issuer) により発行されたパーティション登録チケット（PRT) は、パ —テイシヨンマネージャに対して送信される。

(4) PMとデバイス間の相互認証

発行された P RTに従ったパーティションを生成しょうとする対象のデバイスと、パーティションマネージャ（具体的にはチケットユーザであるデバイスァクセス機器としてのリーダライタ）は、公開鍵方式の相互認証（図 50参照）を実行する。

(5 ) PRTの送信

パーティションマネージャは発行されたパーティション登録チケット（PRT) をデバイスに送付する。デバイスは、受信したパーティション登録チケット（P RT) について MA C検証処理を実行し、 PRT発行者（PRT Issuer) の検証、さらに、 PRTチケットに格納された PR Tユーザ（この場合は PM：チケットユーザであるデバイスアクセス機器としてのリーダライタ）と受信したパーティシヨンマネージャの公開鍵証明書の識別データ（DN) として記録された識別子またはカテゴリまたはシリアル（SN) の一致を確認し相互認証済みであることを確認することにより PRTユーザ（PM：デバイスアクセス機器としてのリーダライタ）の検証（図 57、図 58参照）を実行する。

( 6 ) パ一テイションの生成

パーティション登録チケット（PRT) の検証、 PRT発行者（PRTIssuer)、 P R Tユーザの検証に成功すると、パーティション登録チケット（PRT) に記述されたルールに従ってパ一テイションがデバイスのメモリ部に生成（図 60、図 6 1参照）される。

( 7 ) 鍵データ書き込み

パーティションがデバイスのメモリ部に生成されると、生成されたパーティション内に対する各種鍵の格納処理が実行される。

( 8 ) 公開鍵の読み出し、

(9) 公開鍵証明書の発行

生成パーティションに対する各種サービス時の認証処理（パーティション生成、ファイル生成、ファイルアクセス、データアップデート等のサービス利用時の認証処理）に際し、公開鍵認証を行なう場合、デバイスは公開鍵、秘密鍵の鍵ペアを生成し、生成した公開鍵をパーティションマネージャに送信し、登録局、認証局を介して公開鍵証明書の発行処理を行ない、発行された公開鍵証明書をパ一テイシヨン鍵領域（図 23参照）に格納する。この際、生成した公開鍵の格納領域に対して発行された公開鍵証明書を格納する。なお、この（ 8 )、 ( 9 ) の処理は、作成パ一テイションに対する各種サ一ビス時の認証処理（パ一テイション生成、ファイル生成、ファイルアクセス、データアップデート等のサービス利用時の認証処理）の際に公開鍵認証を行なう構成の場合に実行すればよい。

以上の処理によって、相互認証（公開鍵）、チケット（PRT) 検証（共通鍵）の各方式に従ったパーティションの生成処理が実行される。

(C) 相互認証（共通鍵）、チケット（P RT) 検証（共通鍵）

次に、相互認証処理に共通鍵方式を適用し、チケット（PRT) 検証に共通鍵方式を適用する場合の各エンティティ間のデータ転送について図 70を用いて説明する。図に示す番号順に各エンティティ間でデータ転送が実行される。以下、各番号に従って処理を説明する。

( 1 ) パーティション登録チケッ卜（PRT) の発行処理

パーティション登録チケット（PRT) は、デバイスマネージャの管理するパ —ティション登録チケット発行手段（PRT Ticket Issuer) によりパーティシヨンマネージャ（PM) に対して発行される。この場合、共通鍵方式の検証値として MAC (図 59参照）が PR Tに付加される。

(2) PRTの PMに対する供給デバイスマネージャの管理するパーティション登録チケット発行手段（PRT Ticket Issuer) により発行されたパーティション登録チケット（PRT) は、パ —テイシヨンマネージャに対して送信される。

(3) PMとデバイス間の相互認証

発行された P RTに従ったパーティションを生成しょうとする対象のデバイスと、パーティションマネージャ（具体的にはチケットュ一ザであるデバイスァクセス機器としてのリーダライタ）は、共通鍵方式の相互認証（図 53、図 54参照）を実行する。

(4) PRTの送信

パーティションマネージャは発行されたパーティション登録チケット（P RT) をデバイスに送付する。デバイスは、受信したパーティション登録チケット（P RT) について MA C検証処理を実行し、 PRT発行者（PRT Issuer) の検証、さらに、 PRTチケットに格納された P R Tユーザ（この場合は PM：チケットユーザであるデバイスアクセス機器としてのリーダライ夕）とパーティションマネ一ジャの識別子の一致を確認し、相互認証済みであることを確認することにより PRTユーザ（PM:デバイスアクセス機器としてのリ一ダライタ）の検証（図 57、図 58参照）を実行する。

( 5 ) パ一テイションの生成

パーティション登録チケット（PRT) の検証、 PRT発行者（PRT Issuer), P R Tユーザの検証に成功すると、パーティション登録チケット（PRT) に記述されたルールに従ってパーテイションがデバイスのメモリ部に生成（図 60、図 6 1参照）される。

(6) 鍵デ一夕書き込み

パーティションがデバイスのメモリ部に生成されると、生成されたパーティシヨン内に対する各種鍵の格納処理が実行される。

(7) 公開鍵の読み出し、

(8) 公開鍵証明書の発行

生成パーティションに対する各種サービス時の認証処理（パーティション生成、ファイル生成、ファイルアクセス、データアップデート等のサービス利用時の認証処理）に際し、公開鍵認証を行なう場合、デバイスは公開鍵、秘密鍵の鍵ペアを生成し、生成した公開鍵をパーティションマネージャに送信し、登録局、認証局を介して公開鍵証明書の発行処理を行ない、発行された公開鍵証明書をパーテイシヨン鍵領域（図 23参照）に格納する。この際、生成した公開鍵の格納領域に対して発行された公開鍵証明書を格納する。なお、この（7)、 (8)の処理は、作成パーティションに対する各種サービス時の認証処理（パーティション生成、ファイル生成、ファイルアクセス、データアップデート等のサービス利用時の認証処理）の際に公開鍵認証を行なう構成の場合に実行すればよい。

以上の処理によって、相互認証（共通鍵）、チケット（PRT) 検証（公開鍵）の各方式に従ったパ一ティションの生成処理が実行される。

(D) 相互認証（共通鍵）、チケット（PRT) 検証（公開鍵）

次に、相互認証処理に共通鍵方式を適用し、チケット（PRT) 検証に公開鍵方式を適用する場合の各ェンティティ間のデータ転送について図 7 1を用いて説明する。図に示す番号順に各エンティティ間でデ一タ転送が実行される。以下、各番号に従って処理を説明する。

( 1 ) デバイスマネージャ（DM) の公開鍵証明書（C e r t . DM) の発行、公開鍵証明書（C e r t . DM) は、認証局（CA) によってデバイスマネ一ジャの発行要求により、登録局を介した証明書発行手続きによってデバイスマネージャに対して発行される。

(2) パーティション登録チケット（PRT) の発行処理

パーティション登録チケット（PRT) は、デバイスマネージャの管理するパ一ティション登録チケット発行手段（PRT Ticket Issuer) によりパーティシヨンマネージャ（PM) に対して発行される。この場合、公開鍵方式の署名生成、検証を実行するため、デバイスマネージャの秘密鍵による署名（ Signature)が生成 (図 1 2参照）されて P R Tに付加される。

(3) P R Tおよび DM公開鍵証明書（C e r t . DM) の PMに対する供給デバイスマネージャの管理するパーティション登録チケット発行手段（PRT Ticket Issuer) により発行されたパーティション登録チケット（P RT) は、 D M公開鍵証明書（C e r t . DM) とともにパーティションマネージャに対して送信される。

(4) PMとデバイス間の相互認証

発行された P R Tに従ったパーティションを生成しょうとする対象のデバイスと、パーティションマネージャ（具体的にはチケットユーザであるデバイスァクセス機器としてのリーダライタ）は、共通鍵方式の相互認証（図 53、図 54参照）を実行する。

(5) P R Tおよび DM公開鍵証明書（C e r t . DM) のデバイスに対する供給

デバイスは、受信したパーティション登録チケット（PRT) について、（ 1 ) チケット発行者（Ticket Issuer) =DMの公開鍵証明書（CE RT) が改竄されたものでない正当な公開鍵証明書（CERT) であること、（2)チケット発行者 (Ticket Issuer) の公開鍵証明書（CERT) のオプション領域に記録されたコ —ドと、デパイス内の DKDB (Device Key Definition Block) (PUB)に記録されたチケット発行手段コ一ド（P R T I C ： PRT Issuer Code) の一致、（ 3 ) チケット発行手段（Ticket Issuer) がリボークされていないこと、（4) 受信チケヅト（PRT) の署名（Signature) の検証によりチケットが改竄のないことの確認を実行し、さらに、 P R Tチケットに格納された P R Tユーザ（この場合は P M：チケットユーザであるデバイスアクセス機器としてのリ一ダライタ）とパ一テイシヨンマネージャの公開鍵証明書中の識別デ一夕（DN) として記録された識別子またはカテゴリまたはシリアル（SN) の一致を確認し、相互認証済みであることを確認することにより P RTユーザ（PM：デバイスアクセス機器としてのリーダライタ）の検証（図 5 7、図 58参照）を実行する。

( 6 ) パ一テイションの生成

パーティション登録チケット（P R T) の検証、 P R T発行者（PRT Issuer), P R Tユーザの検証に成功すると、パーティション登録チケット（PRT) に記述されたルールに従ってパ一テイションがデバイスのメモリ部に生成（図 60、図 6 1参照）される。

( 7 ) 鍵データ書き込み

パ一テイションがデバイスのメモリ部に生成されると、生成されたパ一ティション内に対する各種鍵の格納処理が実行される。

( 8 ) 公開鍵の読み出し、

( 9 ) 公開鍵証明書の発行

生成パーティションに対する各種サービス時の認証処理（パーティション生成、ファイル生成、ファイルアクセス、データアップデート等のサービス利用時の認証処理）に際し、公開鍵認証を行なう場合、デバイスは公開鍵、秘密鍵の鍵ペアを生成し、生成した公開鍵をパーティションマネージャに送信し、登録局、認証局を介して公開鍵証明書の発行処理を行ない、発行された公開鍵証明書をパ一テイシヨン鍵領域（図 2 3参照）に格納する。この際、生成した公開鍵の格納領域に対して発行された公開鍵証明書を格納する。なお、この（ 8 )、（ 9 ) の処理は、作成パーティションに対する各種サービス時の認証処理（パーティション生成、ファイル生成、ファイルアクセス、データアップデート等のサ一ビス利用時の認証処理）の際に公開鍵認証を行なう構成の場合に実行すればよい。

以上の処理によって、相互認証（共通鍵）、チケット（P R T ) 検証（公開鍵）の各方式に従ったパーティションの生成処理が実行される。

[ B 4 . 4 . ファイル登録チケット（F R T ) を利用したファイル生成、削除処理]

次に、デバイスに生成したパ一テイシヨン内にファイル登録チケヅト（ F R T ) を適用してファイルを生成、または削除する処理について説明する。図 7 2以下のフロー他の図面を参照して説明する。なお、ファイル作成、削除処理には、デバイスとデバイスアクセス機器としてのリ一ダライタ（パーティションマネージャ）間における相互認証処理（デバイス認証またはパーティション認証）、パ一テイション登録チケット（F R T ： Fi le Regi stration Ti cket) の正当性検証処理が含まれる。

図 7 2に示すファイル生成、削除処理フローについて説明する。図 7 2において、左側がパーティションマネージャのファイル作成 · 削除装置、右側がデバイス（図 5参照）の処理を示す。なお、パーティションマネージャのファイル作成 · 削除装置は、デバイスに対するデータ読み取り書き込み処理可能な装置（e x . デバイスアクセス機器としてのリ一ダライタ、 P C ) であり、図 1 0のデバイスアクセス機器としてのリーダライタに相当する。まず、図 7 2を用いて、フアイル作成、削除処理の概要を説明し、その後、当処理に含まれるファイル作成、削除操作の詳細を図 7 3のフローを用いて説明する。

まず、図 7 2のステップ S 8 0 1 と S 8 1 0において、ファイル作成 · 削除装置とデバイス間にでの相互認証処理が実行される。データ送受信を実行する 2つの手段間では、相互に相手が正しいデータ通信者であるか否かを確認して、その後に必要なデータ転送を行なうことが行われる。相手が正しいデータ通信者であるか否かの確認処理が相互認証処理である。相互認証処理時にセッション鍵の生成を実行して、生成したセッション鍵を共有鍵として暗号化処理を実行してデ一夕送信を行なう。

相互認証処理については、先のパーティション生成、削除処理の欄で説明したと同様の処理であり、パーティション認証が実行される。それぞれについて共通鍵方式認証、あるいは公開鍵方式認証処理のいずれかが適用される。この相互認証処理は、前述の図 4 8〜図 5 6を用いて説明したと同様の処理であるので説明を省略する。

なお、相互認証処理として実行すべき処理は、適用するファイル登録チケット ( F R T ) (図 2 7参照）の

* Authenti cation Flag ：チケット（Ti cket ) の利用処理においてデバイス (Device) との相互認証が必要か否かを示すフラグ

* Authenti cation Type ：デパイス（Devi ce) の相互認証のタイプ（公開鍵認証、または、共通鍵認証、または、いずれでも可（Any) )

によって決定される。

認証処理に失敗した場合（S 8 0 2， S 8 1 1で N o ) は、相互が正当な機器、デバイスであることの確認がとれないことを示し、以下の処理は実行されずエラ一として処理は終了する。

認証処理に成功すると、ファイル作成 '削除装置は、デバイスに対してフアイル登録チケット（FRT : File Registration Ticket) を送信する。ファイル登録チケット（FRT) は、パーティションマネージャの管理下のファイル登録チケット（FRT) 発行手段（FRT Issuer) により発行されるチケヅトである。フアイル登録チケット（FRT) は、デバイスに対するアクセス制御チケットであり、先に説明した図 27のデータフォーマット構成を持つチケットである。

なお、ファイル登録チケット（FRT) を、チケットュ一ザに対して送信する際には、公開鍵方式の場合、ファイル登録チケット（ F R T )発行手段（FRT Issuer) の公開鍵証明書（CERT— FRTI) も一緒に送信する。 F RT発行手段の公開鍵証明書 (CERT_FRTI) の属性（Attribute) は、、ファイル登録チケット（FRT) 発行手段（FRT Issuer) の識別子（FRTIC)と一致する。

ファイル登録チケット（FRT) を受信（S 8 1 2) したデバイスは、受信したチケット（F RT) の正当性と利用者チェック処理を実行（S 8 1 3) する。チケットの正当性の検証処理は、共通鍵方式による MAC検証、あるいは公開鍵方式による署名検証処理のいずれかを適用して実行される。利用者チヱックは、チケヅトを送信してきた機器（チケット利用者）の正当性をチェックする処理であり、相互認証が成立済みであり、認証相手の識別データと、チケットに記録されているチケットュ一ザ識別子（図 2 7参照）との一致等を検証する処理として実行される。これらの処理は、先のパーティション登録チケット（PRT) の適用処理についての説明中、図 57〜図 59を用いて説明したと同様の処理であるので説明を省略する。

デバイスにおいて、受信チケット（FRT) の正当性と利用者チェック処理の結果、チケットおよび利用者の正当なことが確認できなかった場合（S 8 14で No) は、ファイル登録チケット（FRT) 受理エラ一をファイル作成 · 削除装置に通知（S 8 1 8) する。チケットおよび利用者の正当なことが確認できた場合（S 8 1 4で Ye s) は、受信したファイル登録チケット（FRT) に記述されたルールに従いデバイス内のメモリ部におけるファイルの生成、または削除処理を実行する。この処理の詳細については、別フローを用いて後段で詳述する。ファイル登録チケット（FRT) の記述に従って、ファイルの生成または削除処理に成功（S 8 1 6で Y e s) すると、 F R T受理成功をファイル作成 · 削除装置に通知（S 8 1 7 ) する。一方、ファイルの生成または削除処理に失敗（S 8 1 6で No) した場合は、 FRT受理エラ一をファイル作成 · 削除装置に通知 ( S 8 1 8 ) する。

ファイル作成 ·削除装置は、 F R T受理結果を受信（ S 804 ) し、 F R T処理結果を判定し、 FRT受理結果がエラ一である場合（S 805で No) は、ェラ一として処理を終了し、 FRT受理結果が成功（S 80 5で Ye s) である場合はセッションクリアコマンドの送受信（S 806 , S 8 1 9) を実行し、デバイス側に生成した認証テーブルを破棄（S 820 ) し、処理を終了する。認証テ一ブルは、ステップ S 80 1， S 8 1 0の相互認証処理において生成されるテ一ブルであり、前述したパーティション登録チケット（PRT) の適用処理の項目において説明した構成、すなわち、図 5 1の構成と同様のものである。

このようにファイル登録チケット（FRT) を利用して、デバイス内に設定されたパ一テイシヨン内にフアイルの生成、または生成済みのファィルの削除処理が実行される。以下、当処理に含まれるファイルの生成、削除処理（ S 8 1 5 ) について、図 7 3を用いて説明する。

(ファイル成 · 削除処理）

図 72のフローに示すステップ S 8 1 5において実行されるファイル登録チケット（FRT) に基づくパーティションの作成、削除処理の詳細について、図 7 3の処理フローを用いて説明する。ファイルの作成、削除処理は、チケットユーザ（ex. デパイスアクセス機器としてのリーダライタ、 P C等）からファイル登録チケヅト（FRT) を受 #したデバイスが、ファイル登録チケヅト（FRT) に基づいて実行する処理である。

図 7 3のステップ S 82 1において、デバイスは、受信したファイル登録チケット（FRT:File Registration ticket) に記録された処理タイプ、すなわち Operation Type (パーティション（Partition) 作成か削除かの指定（作成 (Generate) /削除（Delete))) を検証する。処理タイプ（Operation Type) が、ファイル作成である場合、ステップ S 822以下を実行し、ファイル削除である場合、ステップ S 84 1以下を実行する。

まず、ファイル作成処理について説明する。デバイスはステップ S 822において、ファイル登録チケット（FRT) に記述されたファイル識別子（I D) と同一 I Dのファイルがデバイスの処理対象パーティション内に存在するか否かを検証する。この判定は、デバイスのメモリ部に設定されたパーティション領域のファイル定義ブロック（図 24参照）に受信チケット（FRT) に記述されたフアイル I Dと同一のファイル I Dが記述されているか否かを検証することによつて判定可能である。

すでにデバイスに同一 I Dのファイルが存在する場合は、同一 I Dを持つ重複ファイルを同一のパ一ティション内に存在させることは許されないので、フアイルの生成は実行せず、エラ一終了とする。同一 I Dのファイルが処理対象パーテイシヨン内に存在しない場合は、ステップ S 823において、パーティション管理情報プロック（図 20参照）のパーティション内の空きブロック数（Free Block Number in Partition) と、ファイル登録チケット（FRT) に記述されたフアイルサイズ（FileSize) とを比較し、チケット（FRT) に記述されたファイルサィズ（FileSize)以上の空きプロック領域がデバイスの処理対象パーティシヨン内に存在するか否かを判定する。存在しない場合は、 FRTに記述されたサイズのファイルの生成はできないので、エラー終了とする。

チケット（F RT) に記述されたファイルサイズ（File Size) 以上の空きプロック領域がデバイスのメモリ部の処理対象パーティション内に存在すると判定された場合は、ステップ S 824に進み、パーティション管理情報ブロックの空き領域ポィンタ（Pointer of Free Area)を参照してパ一テイションの空き領域（Free Area in Partition) の最上位ブロックにファイル定義ブロック（FDB) エリア (図 24参照）を確保する。

次に、デバイスは、確保したファイル定義ブロック（FDB) エリアに、ファィル登録チケット（FRT) に記述されたファイル I Dのコピーを実行（S 82 5 ) し、さらに、ファイル定義ブロック（FDB) エリアのファイルスタート位置（File Start Position) に、パーティション管理情報ブロック（図 20参照）の空き領域ポィン夕（Pointer of Free Area) のコピ一処理を実行（ S 82 6 ) する。

さらに、ステップ S 82 7において、フアイル定義プロック（FDB) のファィルサイズ（FileSize)、サービス許可チケット発行手段コード（S PT I C)、およびパ一ジョン、（S PT I C Version)、ファイル構造タイプ（File Structure Type Code), ファイルアクセスを行う際に、指定する認証方式（Acceptable Authentication Type)、指定する検証方式 (Acceptable Verif icztion Type) のそれそれに、ファイル登録チケット（FRT) に記述された各対応データをコピ —する。

次に、ステップ S 828において、ファイル登録チケット（FRT) に格納された Kspt_Encrypted (ファイル定義ブロック（File Definition Block) に記載されるサービス許可チケット（S P T) の M A C検証用鍵 Ksptをそのパーティションのファイル登録チケヅトの MAC検証用鍵 Kfrtで暗号化したデータ Kfrt (Kspt))をファイル登録チケヅトの MAC検証用鍵 Kfrtを用いて復号してファィル定義ブロック（FDB) に格納する。なお、ファイル登録チケットの MA C 検証用鍵 Kfrt は、パ一テイションの生成時にパーティション鍵領域に格納済みである。

次に、ステップ S 829において、パーティション管理情報ブロック（図 2 0 参照）のパ一テイシヨン（Partition)内の空きブロック数（Free Block Number in Partition) からファイルサイズ（File Size) + 1を減算する。なお、 + 1は、ファイル定義ブロック（FDB) 用のブロックを意味する。

次に、ステップ S 830において、パーティション管理情報ブロック（図 2 0 参照）の空き領域ポインタ（Pointer of Free Area) に生成したファイルサイズ (File Size) を加算し、ステップ S 83 1において、パーティション管理情報ブ口ックのファイル数（File Number)に 1を加算、すなわち生成したファイル数（ 1 ) を加算する。

次に、ステップ S 832において、ファイル登録チケット（FRT) に格納された File Structure (生成するファイル（File) のファイル構造（Structure)) に応じた初期化処理を実行する。例えばファイル構造がランダム（Random)であれば、 0リセット、サイクリック（Cyslic) であれば、ポインタ、デ一夕を 0リセットするなどの処理を実行する。これらの処理により、生成したパーティション内に新たなファイルが生成される。次に図 7 3のステップ S 8 4 1〜S 8 4 8のファイル削除処理について説明する。ステップ S 8 4 1では、ファイル登録チケット（F R T) に記述されたファィル I Dと同一 I Dのファイルがデバイスのメモリ部の処理対象パーテイシヨン内に存在するか否かを検証する。この判定は、デパイスのメモリ部のファイル定義ブロック（図 2 4参照）に受信チケット（F RT) に記述されたファイル I D と同一のファイル I Dが記述されているか否かを検証することによって判定可能である。

デバイスの処理対象パ一ティション内に同一フアイル I Dのフアイルが存在しない場合は、ファイルの削除は不可能であるので、エラ一終了とする。同一 I D のファイルがデバイスの処理対象パーティション内に存在する場合は、ステップ S 8 4 2において、削除対象のファイルより後に生成されたファイルが処理対象パーティション内に存在するか否かを判定する。存在しない場合は、削除対象のフアイルが最新のフアイルであり、ステップ S 8 4 9において削除対象のフアイルのファイル定義プロック（ F D B) (図 2 4参照）を削除する。

ステップ S 8 4 2において、削除対象のファイルより後に生成されたファイルが処理対象パーティション内に存在すると判定された場合は、後に生成されたフアイル（後ファイル）のデータを削除対象のファイルのサイズ（F S) 分、下位にずらす処理を実行（S 8 4 3 ) し、さらに、後ファイルのファイル定義ブロック（FD B) を 1ブロック上位にずらす処理を実行（S 8 44) する。また、後ファイルのファイル定義プロヅク（FD B)に記録されたファイル開始位置（File Start Portion)から削除ファイルのサイズ（F S )を減算する処理を実行する（S 8 4 5 )。

ステップ S 8 4 5または S 84 9の処理の後、ステップ S 84 6において、 Λ —ティション管理情報プロック（PM I B) (図 2 0参照）のパーティション内の空きブロック数（Free Block Number in Partition) に削除ファイルのサイズ（F S ) + 1を加算する。 + 1は、削除ファイルのファイル定義ブロック（FD B) 用のブロックを意味する。

次にステップ S 8 4 7において、パーティション管理情報プロック（PM I B ) (図 2 0参照）の空き領域ポインタ（Pointer of Free Area) の値から削除ファィルのサイズ（F S) を減算する。さらに、ステップ S 848において、パ一テイション管理情報プロック（PM I B ) (図 20参照）のファイル数（File Number) から 1を減算、すなわち削除したファイル数（ 1 ) を減算してファイル登録チケット（FRT) に基づくファイル削除処理が終了する。

以上が、図 72の処理フローにおけるステップ S 8 1 5のファイル登録チケット（FRT) に基づくファイル生成、削除処理である。

パーティションマネージャによるファイル生成処理が完了した状態のデバイスのメモリ内格納データ構成例を図 7 4に示す。図 7 4に示すパーティシヨン (Partion)領域中、

ファイル定義ブロック（ 1〜N) (File Definition Block)

パ一ティション鍵領域（Partition Key Area)

共通鍵系パーティション鍵情報ブロック（ Partition Key Definition Block(Common))

公開鍵系パーティション鍵情報ブロック（ Partition Key Definition Block(PUB))

パーティション管理情報ブロック（Partition Management Information Block) の各デ一夕は、ファイル生成時、またはパーティション生成時に書き込まれるデ一夕である。ファイル領域（File Data Area 1〜N)は、ファイル生成処理によつて処理対象パーティション内にファイル領域として確保される。

[B 4. 5. ファイル生成処理各方式における処理手順]

上述したファイルの設定登録処理において、パーティシヨンマネージャが管理し、ファイル登録チケットュ一ザであるデバイスアクセス機器としてのリーダライタとデバイス間において、相互認証が実行され、ファイル登録チケット（F R T) に基づくファイルの設定がなされる。相互認証処理の態様は、公開鍵相互認証、共通鍵相互認証の 2種類のいずれかであり、またチケット（FRT) の検証処理も公開鍵系の署名検証、共通鍵系の M A C検証の 2種類のいずれかが実行されることになる。すなわち処理態様としては大きく分けて、

(A) 相互認証（公開鍵）、チケット（F RT) 検証（公開鍵）

(B) 相互認証（公開鍵）、チケット（F RT) 検証（共通鍵） (C) 相互認証（共通鍵）、チケット（FRT) 検証（共通鍵）

(D) 相互認証（共通鍵）、チケット（F R T) 検証（公開鍵）

の 4態様がある。

これらの 4態様についての処理を、認証局（CA (PM))、パーティションマネ一ジャ（PM)、デバイス、各エンティティ間において実行されるデータ転送処理を中心として図を用いて簡潔に説明する。

(A) 相互認証（公開鍵）、チケット（FRT) 検証（公開鍵）

まず、相互認証処理に公開鍵方式を適用し、チケット（FRT) 検証に公開鍵方式を適用する場合の各エンティティ間のデ一夕転送について図 75を用いて説明する。

( 1 ) ファイル登録チケット発行手段（F R T Issuer) の公開鍵証明書（ C e r t . FRT Issuer) の発行、

ファイル登録チケット発行手段（FRT Issuer) の公開鍵証明書（C e r t . FRT Issuer) は、ファイル登録チケット発行手段（FRT Issuer) からの発行要求により、登録局（RA) を介した証明書発行手続きによってパーティション対応認証局（CA (PAR)) から発行される。なお、パーティシヨンマネージャがファイル登録チケット発行手段（FRT Issuer)を兼ねる構成も可能であり、その場合は、ファイル登録チケット発行手段（FRT Issuer)の公開鍵証明書としてパーティションマネージャ（PM) の公閧鍵証明書を使用可能である。

(2) ファイル登録チケットュ一ザ（FRT User) の公開鍵証明書（C e r t . FRT User) の発行、

ファイル登録チケットュ一ザ（F R T User:具体的には、デバイスに対してチケットを送信するデバイスアクセス機器としてのリ一ダライタ）の公開鍵証明書 (C e r t . F RT User) は、ファイル登録チケットユーザ（ F R T User) からの発行要求により、登録局（RA) を介した証明書発行手続きによってパ一テイション対応認証局（C A (PAR)) によって発行される。なお、パーティションマネージャがファイル登録チケットュ一ザ（FRT User)を兼ねる構成も可能であり、その場合は、ファイル登録チケットユーザ（FRT User) の公開鍵証明書としてパーティションマネージャ（PM) の公開鍵証明書を使用可能である。

(3) ファイル登録チケット（FRT) の生成処理

ファイル登録チケット（FRT) は、パーティションマネージャの管理するフアイル登録チケット発行手段（FRT Ticket Issuer) により生成される。この場合、公開鍵方式の署名生成、検証を実行するため、ファイル登録チケット発行手段（FRT Ticket Issuer) の秘密鍵による署名（Signature)が生成（図 1 2参照）されて F R Tに付加される。

(4) F R Tおよびファイル登録チケット発行手段（FRT Ticket Issuer) 公開鍵証明書（Ce r t . FRT Issuer) のファイル登録チケヅトュ一ザ（F R

T User) に対する供給

パーティションマネージャの管理するファイル登録チケット発行手段（ F R T Ticket Issuer) により発行されたファイル登録チケット（ F R T) は、ファイル登録チケヅト発行手段（F R T Ticket Issuer) 公開鍵証明書（C e r t . F R T Issuer) とともにファイル登録チケットユーザ（ F R T User) すなわち、デバイスに対してチケットを送信する機器（ex. デバイスアクセス機器としてのリーダライタ）に対して送信される。

(5) ファイル登録チケット発行手段とデバイス間の相互認証

パーティションマネージャ（具体的にはファイル登録チケットユーザ（FRT User) であるデバイスアクセス機器としてのリ一ダライタ）は、ファイル登録チケヅト発行手段（FRT Ticket Issuer) の発行したファイル登録チケット（F RT) に従ったファイルを生成しょうとする対象のデバイスに対し、チケットュ一ザ（FRT User) の公開鍵証明書（C e r t . FRT User) をデバイスに送信し、公開鍵方式の相互認証（図 5 0参照）を実行する。

(6) FRTおよびファイル登録チケット発行手段（FRT Ticket Issuer) 公開鍵証明書（Ce r t . FRT Issuer) のデバイスに対する供給

パーティションマネージャ（PM) とデバイス間の相互認証が成立すると、パ —テイシヨンマネージャ（PM) (具体的にはファイル登録チケヅトュ一ザ（FR T User)であるデバイスアクセス機器としてのリーダライタ）は、デバイスに対してファイル登録チケット（FRT)、およびファイル登録チケット発行手段（F RT Ticket Issuer) 公開鍵証明書（C e r t . FRT Issuer) を送信する。デバイスは、受信したファイル登録チケット（FRT) について、（ 1 ) チケット発行者（Ticket Issuer) の公開鍵証明書（CERT FRT Issuer) が改竄されたものでない正当な公開鍵証明書（ C E R T) であること、（2)チケット発行者 (Ticket Issuer) の公開鍵証明書（ C E R T FRT Issuer) のオプション領域に記録されたコードと、デバイス内の PKDB (Partition Key Definition Block) (PUB)に記録されたチケット発行手段コード（FRTIC： FRT Issuer Category) の一致、（ 3 )チケット発行手段（Ticket Issuer)がリボークされていないこと、（4) 受信チケット（FRT) の署名（Signature) の検証によりチケットが改竄のないことの確認を実行し、さらに、 F R Tチケットに格納された F R Tユーザ（チケットュ一ザであるデバイスアクセス機器としてのリーダライタ）とチケットュ一ザ（FRT User) の公開鍵証明書（C e r t . FRT User) の識別データ（D N) として記録された識別子またはカテゴリまたはシリアル（SN) 名（DN) の一致を確認し、相互認証済みであることを確認することにより FRTユーザ（デバイスアクセス機器としてのリ一ダライタ）の検証（図 5 7、図 58参照）を実行する。

(7) FDBに S PT I Cおよび K s p tを登録

デバイスは、ファイル定義ブロック（ F D B ： File DefinitionBlock) にサ一ビス許可チケット（ S P T ) ユーザ（ S P T I C) ( e X . デバイスのファイル内のデータにアクセスを実行するデバイスアクセス機器としてのリーダライ夕）と Kspt (サービス許可チケヅト（S P T)の M A C検証用鍵（Kspt))を登録する（図 7 3のフローにおけるステップ S 82 7 , S 828)。

(8) ファイルデータ領域の確保

デバイスは、処理対象パーティションにファイル登録チケット（FRT) に記述されたサイズを持つファイル領域を確保する。

以上の処理によって、相互認証（公開鍵）、チケット（FRT) 検証（公開鍵）の各方式に従ったファイルの生成処理が実行される。

(B) 相互認証（公開鍵）、チケット（F RT) 検証（共通鍵）次に、相互認証処理に公開鍵方式を適用し、チケット（FRT) 検証に共通鍵方式を適用する場合の各エンティティ間のデ一夕転送について図 76を用いて説明する。

( 1 ) ファイル登録チケットュ一ザ（F R T User) の公開鍵証明書（C e r t . FRT User) の発行、

ファイル登録チケヅトュ一ザ（FRT User：具体的には、デバイスに対してチケットを送信するデバイスアクセス機器としてのリ一ダライタ）の公開鍵証明書 (C e r t . F RT User) は、ファイル登録チケットユーザ（ F R T User) からの発行要求により、登録局（RA) を介した証明書発行手続きによってパーテイション対応認証局（CA (PAR)) によって発行される。なお、パーティションマネージャがファイル登録チケットユーザ（ F R T User)を兼ねる構成も可能であり、その場合は、ファイル登録チケットュ一ザ（F R T User) の公開鍵証明書としてパーティションマネージャ（PM) の公開鍵証明書を使用可能である。

(2) ファイル登録チケット（FRT) の生成処理

ファイル登録チケット（FRT) は、パーティションマネージャの管理するフアイル登録チケット発行手段（F RT Ticket Issuer) により生成される。この場合、共通鍵方式の検証値として MA C(Message Authentication Code) (図 59 参照）が FR Tに付加される。

(3) FRTのファイル登録チケットユーザ（FRT User) に対する供給パーティションマネージャの管理するファイル登録チケット発行手段（FRT

Ticket Issuer) により発行されたファイル登録チケット（ F R T) は、ファイル登録チケットユーザ（FRT User)すなわち、デバイスに対してチケットを送信する機器（ex. デバイスアクセス機器としてのリーダライタ）に対して送信される。

(4) ファイル登録チケット発行手段とデパイス間の相互認証

パ一ティシヨンマネージャ（具体的にはファイル登録チケヅトュ一ザ（FRT User) であるデバイスアクセス機器としてのリーダライタ）は、ファイル登録チケヅト発行手段（FRT Ticket Issuer) の発行したファイル登録チケット（F RT) に従ったファイルを生成しょうとする対象のデバイスに対し、チケットュ一ザ（ F R T User) の公開鍵証明書（C e r t . FRT User) をデバイスに送信し、公開鍵方式の相互認証（図 50参照）を実行する。

(5) FRTのデバイスに対する供給

パーティションマネージャ（PM) とデバイス間の相互認証が成立すると、パ —テイシヨンマネージャ（PM) (具体的にはファイル登録チケットュ一ザ（FR T User)であるデバイスアクセス機器としてのリ一ダライタ）は、デバイスに対してファイル登録チケット（FRT) を送信する。デバイスは、受信したフアイル登録チケット（FRT) について M A C検証処理を実行し、 FRT発行者（FRT Issuer) の検証、さらに、 F R Tチケットに格納された F R Tュ一ザ（チケットユーザであるデバイスアクセス機器としてのリ一ダライタ）と受信したパーティシヨンマネージャの公開鍵証明書の識別データ（DN) として記録された識別子またはカテゴリまたはシリアル（SN) 名（DN) の一致を確認し相互認証済みであることを確認することにより FRTユーザ（PM：デバイスアクセス機器としてのリーダライタ）の検証（図 57、図 58参照）を実行する。

(6) FDBに S P T I Cおよび K s p tを登録

デバイスは、ファイル定義ブロック（ F D B ： File DefinitionBlock) にサ一ビス許可チケット（ S P T) 発行者カテゴリ（S PT I C) (e . デバイスのフアイル内のデータにアクセスを実行するデバイスアクセス機器としてのリーダライタ）と Kspt (サービス許可チケット（S P T) の M A C検証用鍵（Kspt)) を登録する（図 73のフローにおけるステップ S 827 , S 828 )o

(8) ファイルデータ領域の確保

以上の処理によって、相互認証（公開鍵）、チケット（FRT) 検証（共通鍵）の各方式に従ったファイルの生成処理が実行される。

(C) 相互認証（共通鍵）、チケット（F RT) 検証（共通鍵）

次に、相互認証処理に共通鍵方式を適用し、チケット（FRT) 検証に共通鍵方式を適用する場合の各エンティティ間のデ一夕転送について図 77を用いて説明する。

( 1 ) ファイル登録チケット（FRT) の生成処理

ファイル登録チケット（FRT) は、パーティションマネージャの管理するフアイル登録チケヅト発行手段（FRT Ticket Issuer) により生成される。この場合、共通鍵方式の検証値として MA C (Message Authentication Code) (図 59 参照）が FRTに付加される。

(2) FRTのファイル登録チケットユーザ（FRT User) に対する供給パーティションマネージャの管理するファイル登録チケット発行手段（FRT Ticket Issuer) により発行されたファイル登録チケット（FRT) は、ファイル登録チケットュ一ザ（FRT User)すなわち、デバイスに対してチケットを送信する機器（ex. デバイスアクセス機器としてのリ一ダライタ）に対して送信される。

( 3 ) ファイル登録チケット発行手段とデバイス間の相互認証

パーティションマネージャ（具体的にはファイル登録チケットユーザ（FRT

User) であるデバイスアクセス機器としてのリ一ダライタ）は、ファイル登録チケット発行手段（FRT Ticket Issuer) の発行したファイル登録チケット（F RT) に従ったファイルを生成しょうとする対象のデバイスとの間で、共通鍵方式の相互認証（図 53、図 54参照）を実行する。

(4) FRTのデバイスに対する供給

パーティションマネージャ（PM) とデバイス間の相互認証が成立すると、パ —テイシヨンマネージャ（PM) (具体的にはファイル登録チケットュ一ザ（FR T User)であるデバイスアクセス機器としてのリーダライ夕）は、デバイスに対してファイル登録チケット（FRT) を送信する。デバイスは、受信したフアイル登録チケット（FRT) について MA C検証処理を実行し、 FRT発行者（FRT Issuer) の検証、さらに、 F R Tチケットに格納された F R Tュ一ザ（チケットユーザであるデバイスアクセス機器としてのリーダライタ）と受信したパーティシヨンマネージャの識別子の一致を確認し相互認証済みであることを確認することにより F R Tユーザ（P M：デバイスアクセス機器としてのリ一ダライタ）の検証（図 57、図 58参照）を実行する。

(6) F D Bに S P T I Cおよび K s p tを登録

デバイスは、ファイル定義ブロック（ F D B ： File DefinitionBlock) にサ一ビス許可チケット（ S P T ) 発行者カテゴリ（S PT I C) (ex. デバイスのフアイル内のデータにアクセスを実行するデパイスアクセス機器としてのリーダライタ）と Kspt (サービス許可チケット（S PT) の MA C検証用鍵（Kspt)) を登録する（図 73のフローにおけるステップ S 827 , S 828 )o

(8) ファイルデータ領域の確保

デパイスは、処理対象パーティションにファイル登録チケット（FRT) に記述されたサイズを持つファイル領域を確保する。

以上の処理によって、相互認証（共通鍵）、チケット（FRT) 検証（共通鍵）の各方式に従ったファイルの生成処理が実行される。

(D) 相互認証（共通鍵）、チケット（F RT) 検証（公開鍵）

次に、相互認証処理に共通鍵方式を適用し、チケット（FRT) 検証に公開鍵方式を適用する場合の各ェンティティ間のデータ転送について図 78を用いて説明する。

( 1 ) ファイル登録チケット発行手段（FRT Issuer) の公開鍵証明書（C e r t . FRT Issuer) の発行、

ファイル登録チケット発行手段（FRT Issuer) の公開鍵証明書（C e r t . FRT Issuer) は、ファイル登録チケット発行手段（FRT Issuer) からの発行要求により、登録局（RA) を介した証明書発行手続きによってパーティション対応認証局（CA (PAR)) から発行される。なお、パーティションマネージャがファイル登録チケット発行手段（FRT Issuer)を兼ねる構成も可能であり、その場合は、ファイル登録チケット発行手段（FRT Issuer)の公開鍵証明書としてパーティションマネージャ（PM) の公開鍵証明書を使用可能である。 (2) ファイル登録チケット（FRT) の生成処理

ファイル登録チケット（FRT) は、パーティションマネージャの管理するフアイル登録チケット発行手段（FRT Ticket Issuer) により生成される。この場合、公開鍵方式の署名生成、検証を実行するため、ファイル登録チケット発行手段（FRT Ticket Issuer) の秘密鍵による署名（Signature)が生成（図 1 2参照）されて FRTに付加される。

(3) F R Tおよびファイル登録チケット発行手段（F R T Ticket Issuer) 公開鍵証明書（C e r t . FRT Issuer) のファイル登録チケットュ一ザ（ F R T User) に対する供給

パーティションマネージャの管理するファイル登録チケット発行手段（FRT Ticket Issuer) により発行されたファイル登録チケット（ F R T) は、ファイル登録チケット発行手段（ F R T Ticket Issuer) 公開鍵証明書（C e r t . F R T Issuer) とともにファイル登録チケットュ一ザ（ F R T User) すなわち、デバイスに対してチケットを送信する機器（ex. デバイスアクセス機器としてのリーダライタ）に対して送信される。

(4) ファイル登録チケット発行手段とデバイス間の相互認証

User) であるデバイスアクセス機器としてのリ一ダライタ）は、ファイル登録チケット発行手段（FRT Ticket Issuer) の発行したファイル登録チケット（F RT) に従ったファイルを生成しょうとする対象のデパイスとの間で、共通鍵方式の相互認証（図 53、図 54参照）を実行する。

(5) FRTおよびファイル登録チケヅト発行手段（FRT Ticket Issuer) 公開鍵証明書（C e r t . FRT Issuer) のデパイスに対する供給

パーティションマネージャ（PM) とデパイス間の相互認証が成立すると、パ —テイシヨンマネージャ（PM) (具体的にはファイル登録チケヅトュ一ザ（FR T User)であるデバイスアクセス機器としてのリーダライタ）は、デバイスに対してファイル登録チケヅト（FRT)、およびファイル登録チケット発行手段（F RT Ticket Issuer) 公開鍵証明書（C e r t . FRT Issuer) を送信する。デバイスは、受信したファイル登録チケヅト（FRT) について、（ 1 ) チケット発行者（Ticket Issuer) の公開鍵証明書（CERT FRT Issuer) が改竄されたものでない正当な公閧鍵証明書（CERT)であること、（2)チケット発行者 (Ticket Issuer) の公開鍵証明書（ C E R T FRT Issuer) のオプション領域に記録されたコードと、、デバイス内の PKDB (Partition Key Definition Block) (PUB)に記録されたチケット発行手段コード（FRTIC： FRT Issuer Category) の一致、（ 3 )チケット発行手段（Ticket Issuer)がリポークされていないこと、（4) 受信チケット（FRT) の署名（Signature) の検証によりチケッ卜が改竄のないことの確認を実行し、さらに、 FRTチケットに格納された FRTユーザ（チケットュ一ザであるデバイスアクセス機器としてのリ一ダライタ）とチケットュ一ザ（FRT User)の識別子の一致を確認し、相互認証済みであることを確認することにより FRTユーザ（デバイスアクセス機器としてのリーダライタ）の検証 (図 57、図 5 8参照）を実行する。

(6) FDBに S PT I Cおよび K s p tを登録

デパイスは、ファイル定義ブロック（FDB ： FileDefinitionBlock) にサ一ビス許可チケット（ S P T)発行者カテゴリ（S P T I C) (ex. デバイスのフアイル内のデータにアクセスを実行するデバイスアクセス機器としてのリーダライタ）と Kspt (サービス許可チケット（S P T) の MA C検証用鍵（Kspt)) を登録する（図 73のフローにおけるステップ S 827 , S 828 )o

(7) ファイルデータ領域の確保

以上の処理によって、相互認証（共通鍵）、チケット（FRT) 検証（公開鍵）の各方式に従ったファイルの生成処理が実行される。

[B 4. 6. サービス許可チケット（S P T) を利用したサービス（フアイルアクセス）処理]

次に、サービス許可チケヅト（SRT) (図 28、図 3 1参照）を利用したファィルアクセス処理について説明する。図 79以下のフロー他の図面を参照して説明する。なお、ファイルアクセス処理には、デバイスとファイルアクセス装置間における相互認証処理（デバイス認証またはパーティション認証）、サービス許可チケット（ S P T : Service Parmi ssion Ticket) の正当性検証処理が含まれる。図 7 9のフローにおいて、左側がファイルアクセス装置、右側がデバイス（図 5参照）の処理を示す。なお、ファイルアクセス装置は、パーティションマネ一ジャの管理装置であり、デバイスに対するデータ読み取り書き込み処理可能な装置（ e X . デバイスアクセス機器としてのリ一ダライタ、 P C ) であり、図 1 0 のデバイスアクセス機器としてのリーダライタに相当する。まず、図 7 9を用いて、ファイルアクセス装置によるファイルアクセス処理の概要を説明し、その後、当処理に含まれる各処理の詳細を図 8 0以下のフローを用いて順次説明する。まず、図 7 9のステップ S 8 5 1 と S 8 6 0において、ファイルアクセス装置とデバイス間にでの相互認証処理が実行される。データ送受信を実行する 2つの手段間では、相互に相手が正しいデータ通信者であるか否かを確認して、その後に必要なデータ転送を行なうことが行われる。相手が正しいデータ通信者であるか否かの確認処理が相互認証処理である。相互認証処理時にセッション鍵の生成を実行して、生成したセッション鍵を共有鍵として暗号化処理を実行してデータ送信を行なう。

相互認証処理については、先のパーティション生成、削除処理の欄で説明したと同様の処理であり、パーティション認証が実行される。それそれについて共通鍵方式認証、あるいは公開鍵方式認証処理のいずれかが適用される。この相互認証処理は、前述の図 4 8〜図 5 6を用いて説明したと同様の処理であるので説明を省略する。

なお、相互認証処理として実行すべき処理は、適用するサービス許可チケット ( S P T ) (図 2 8、図 3 1参照）の

* Authenti cation Flag ：チケット（Ticket ) の利用処理においてデバイス (Device) との相互認証が必要か否かを示すフラグ

によって決定される。

認証処理に失敗した場合（S 8 5 2， S 8 6 1で N o ) は、相互が正当な機器、デバイスであることの確認がとれないことを示し、以下の処理は実行されずエラ —として処理は終了する。

デパイスは、複数のサービス許可チケット（S PT) に基づく複数の異なるパ

—テイシヨン内のファイルアクセスを許容する処理も可能である。例えば、デバイス認証の成立を条件として、複数のサービス許可チケット（S PT) に基づく複数の異なるパーティション内のファイルアクセスを許容することが可能である c 各パーティション毎のファイルアクセスルールは、アクセス制御データとして構成されるサービス許可チケット（S P T) に記述され、デバイスは、アクセス機器から複数のサービス許可チケット（S P T) を受領し、各チケットがデバイス認証を要求している場合は、記述に従ってデバイス認証が成立したことを条件として各パーティション内のファイルアクセスを許容する。

また、デバイスは、複数のサービス許可チケット（S P T) の各々が異なる認証条件を定めている場合は、各サービス許可チケット（S P T) に設定されたパ —テイシヨン認証の認証成立を条件として、複数のサービス許可チケット（S P T) の指定ファイルに対するアクセスを許容する。

次にステップ S 853において、ファイルアクセス装置は、デバイスに対してサービス許可チケット（ S P T ： Service Parmission Ticket) を送信する。サービス許可チケット（S PT) は、パーティションマネージャの管理下のサービス許可チケット（S PT) 発行手段（SPT Issuer) により発行されるチケヅトである。サービス許可チケット（S PT) は、デバイスに対するアクセス制御チケットであり、先に説明した図 28、図 3 1のデ一夕フォーマット構成を持つチケットである。

なお、サービス許可チケット（S P T) を、チケットユーザに対して送信する際には、公開鍵方式の場合、サービス許可チケット（S P T)発行手段（SPT Issuer) の公開鍵証明書（CERT— SPTI) も一緒に送信する。 S P T発行手段の公開鍵証明書 (CERT_SPTI)の属性（Attribute)は、デバイス内の F D B (File Definition Block) に記録されたチケット発行手段コード（SPTIC)と一致する。

ファイル登録チケット（S PT) を受信（S 862) したデバイスは、受信したチケット（S RT) の正当性と利用者チェック処理を実行（S 86 3 ) する。チケットの正当性の検証処理は、共通鍵方式による MAC検証、あるいは公開鍵方式による署名検証処理のいずれかを適用して実行される。利用者チヱックは、チケットを送信してきた機器（チケット利用者）の正当性をチェックする処理であり、相互認証が成立済みであり、認証相手の識別データと、チケットに記録されているチケットユーザ識別子（図 28、図 3 1参照）との一致等を検証する処理として実行される。これらの処理は、先のパーティション登録チケット（PR T) の適用処理についての説明中、図 57〜図 59を用いて説明したと同様の処理であるので説明を省略する。 - デバイスにおいて、受信チケット（S PT) の正当性と利用者チヱヅク処理の結果、チケットおよび利用者の正当なことが確認できなかった場合（S 864で No) は、サービス許可チケット（S PT) 受理エラ一をファイルアクセス装置に通知（S 868) する。チケットおよび利用者の正当なことが確認できた場合 (S 864で Y e s ) は、受信したサービス許可チケット（S P T) に記述されたルールに従いデバイス内のメモリ部に格納されたファイルオープン処理が実行される。この処理の詳細については、別フローを用いて後段で詳述する。

サービス許可チケット（ S P T) の記述に従って、ファイルのオープン処理に成功（S 866で Ye s) すると、 S P T受理成功をファイルアクセス装置に通知（S 867) する。一方、ファイルのオープン処理に失敗（S 866で No) した場合は、 S P T受理エラーをファイルアクセス装置に通知（S 868 ) する。ファイルアクセス装置は、 S PT受理結果を受信（S 854 ) し、 S PT処理結果を判定し、 S P T受理結果がエラ一である場合（S 855で N o) は、エラ一として処理を終了し、 S P T受理結果が成功（S 85 5で Ye s) である場合は、すべての S P T送信が終了したか否かを判定（S 856 ) し、未送信 S P T がある場合は、ステップ S 853以下を繰り返し実行する。

すべての S P T送信が終了した場合は、ステップ S 857、 S 869においてサービス許可チケット（S PT) に従ったファイルアクセスを実行し、ファイルアクセス処理の終了の後、セッションクリアコマンドの送受信（ S 858 , S 8 70 ) を実行し、デバイス側に生成した認証テーブルを破棄（ S 87 1 ) し、処理を終了する。ファイルアクセス処理の詳細については、別フローを用いて後段で詳述する。なお、認証テーブルは、ステップ S 85 1， S 860の相互認証処理において生成されるテーブルであり、前述したパーティション登録チケット（P RT) の適用処理の項目において説明した構成、すなわち、図 5 1の構成と同様のものである。

このようにサービス許可チケット（S P T) を利用して、デバイス内に設定されたパーティション内のファイルに対するアクセス処理が実行される。以下、当処理に含まれるファイルオープン処理（ S 865 )、各種ファイルアクセス処理（ S 857 , S 86 9 ) について説明する。

(ファイルオープン処理）

図 80のフローに従って、フアイルオープン処理（図 79、 S 865 ) について説明する。ファイルオープン処理は、デバイスが受信したサービス許可チケット（S PT) に従って実行する処理である。

ステップ S 88 1において、デバイスは、受信したサービス許可チケット（S P T) に指定されたファイルがデバイス内に生成されて存在しているか否かを判定する。サービス許可チケット（S P T) には処理対象ファイルのファイル I D が記録（図 28、図 3 1参照）されており、同一の I Dを持つファイルの有無を例えばファイル定義ブロック（図 24) を参照して判定する。チケットに記述された I Dと同一 I Dのファイルが存在しない場合は、処理が不可能であるのでェラー終了する。

チケットに記述された I Dと同一 I Dのファイルが存在する場合は、ステップ S 882において、ファイルオープンテーブルにサービス許可チケット（ S P T) に記述されたチケット発行手段（Ticket issuer= PM C： Partition manager Code)と、サービス許可チケット（S PT) に記述されたファイル I Dとを対応付けたエントリを書き込む。

さらに、ステップ S 88 3において、ファイルオープンテーブルに生成したェントリに対応付けてサービス許可チケット（S PT) に記述されたファイルァクセスモード [File Access Mode ：アクセスを許諾するファイル（File) へのァクセスモード（Access Mode)] を書き込み、ステップ S 884において、サ一ビス許可チケット（S PT) に記述されたアクセス許可グループファイル [Group of Target File：アクセスを許すファイル（File) のグループ（Group)] を書き込み、ステップ S 885において、サービス許可チケット（S PT) に記述されたァクセス許可ファイル識別子 [Target File ID ：アクセスを許すファイル（File) の識別子（ I D)] の書き込み、さらにステップ S 88 6において、サービス許可チケット（ S P T ) に記述されたタ一ゲヅトファイル（Target File)) に対する処理態様デ一夕 [Read/Write Permission：アクセスを許すファイル（File) (夕一ゲットファイル（Target File)) に対する処理態様（読み出し（Read) ，書き込み (Write) の許可）] の書き込み処理を行なう。なお、ターゲットファイルに対する処理としては、読み出し（Read) ，書き込み（Write) に限らず、様々な処理を設定可能である。

ファイルオープンテ一ブルの構成例を図 8 1、図 82に示す。ファイルオーブンテーブルは、デバイスにおいてアクセス処理状態にあるファイルおよびァクセスモ一ド他の情報を記録したテーブルであり、デバイスが受信したサービス許可チケット（S P T) の記述情報を倉己録してデバイスの記憶手段に格納する。チケットが唯一のファイルに対してのみアクセスを許可する形式のサービス許可チケット（図 28参照）である場合は、ファイルオープンテーブルは、

Ticket Issuer ：チケット発行手段（Ticket Issuer) の識別子

* File Access Mode ：アクセスを許諾するファイル（File) へのアクセスモ一 F (Access Mode)

の情報を格納する。この場合のファイルオープンテ一ブルの構成例を図 8 1に示す。

図 8 1に示すように、ファイルオープンテーブルにはグループ情報である Ticket Issuer ：チケット発行手段（Ticket Issuer) の識別子として、パーティシヨンマネージャコード（PMC) が記述され、パーティションが判別され、フアイル I Dによりファイルが識別され、ファイルアクセスモードにより実行可能なアクセス態様（ex. 読み取り（READ)、書き込み（Wr i t e )、暗号化復号化（En c， D e c)) が判定可能となる。

また、サービス許可チケット（S PT) がパーティションに設定されたフアイル中の複数ファイルに対してアクセスを許可する形式のサービス許可チケット (図 3 1参照）の場合は、上記情報に加えて

* Target File ID ：アクセスを許すファイル（File) の識別子（ I D)

* Read/Write Permission ：アクセスを許すフアイル（File) (タ一ゲットファィル（Target File)) に対する処理態様（読み出し（Read) ，書き込み（Write)) の許可

の各情報がテーブルに書き込まれる。この場合のファイルオープンテーブルの構成例を図 82に示す。

図 82に示すように、複数ファイルに対してアクセスを許可する形式のサービス許可チケットに対応して設定されるファイルオープンテ一ブルには、図 8 1に示すデータの他に、アクセスを許すターゲットファイル（File) のグループとしてのパーティション識別デ一夕としてのパ一ティションマネ一ジヤコ一ド（PM C) と、アクセスを許す夕一ゲットファイル（File) の識別子（ I D) としてのファイル I Dと、ターゲットファイル（Target File)) に対する処理態様を示す [Read/Write Permission]データが格納され、複数ファイルに対する実行可能な処理が判定可能となる。

複数のファイルに対してアクセスを実行する処理とは、例えばファイル Aに格納された鍵を用いて、ファイル Bに格納されたデータを暗号化する処理を実行する場合などである。このためには、ファイル Bはファイル Aの読み出し要求に対して許可を与える必要がある。この場合、ファイル Bのことをソースファイル、許可を与える相手のファイルのことを夕一ゲットファイルと呼ぶ。

このように、デバイスは、アクセス機器とのセッション中に受領したサービス許可チケット（S PT) に基づいて、チケット発行手段（Ticket Issuer(PMC)) としてのパーティションマネージャコード（PMC)、ファイルオープン処理を実行したファイルの識別デ一夕としてのファイル識別子と、サービス許可チケット (S PT) に記述されたアクセスモ一ドを対応付けたファイルオープンテーブルを生成し、該ファイルオープンテーブルを参照して前記アクセス機器からの受領コマンドの実行の可否の判定が可能となる。

(ファイルアクセス処理）次に、図 79のステップ S 857、 S 869において実行されるファイルァクセス処理の詳細について説明する。

まず、図 8 1に示すファイルオープンテーブルが生成された場合のアクセス処理について、図 83を用いて説明する。図の左側に 2つのファイルアクセス装置 (R/W：デバイスアクセス機器としてのリーダライタ） 750、 760を示し、右側にファイルの生成されたデバイス 1 00のパーティション部分を示す。

ファイルアクセス装置（R/W：リーダライタ） 75 0は、デバイスとの相互認証の後、

ファイル I D : [ 0 x 0002 ]

ファイルアクセスモード： [読み取り： R e a d]

のアクセス許可チケットをデバイス 1 0 0に送信し、チケヅトの正当性検証、チケット発行者、利用者検証に成功したとする。

このとき、デバイスには図 8 1に示すファイルオープンテーブルの第 2行のェントリが生成される。このエントリは、パーティションマネージャコード（PM C 1 ) で識別されるパ一テイシヨン内のファイル I D [ 0 x 0002 ] に対してアクセスモード [読み取り： Re ad] の処理が実行可能であることを示している。

このとき、ファイルアクセス装置（R/W：リーダライタ） 750は、コマンドを生成してデバイスに対して送信する。例えばファイル I D [ 0 x 00 02 ] のデータ読み取りコマンド： R e a d C o mm a n d ( 0 x 00 02 ) をデバイスが受信すると、デバイスはファイルオープンテ一ブルのエントリを確認し、フアイル I D [ 0 x 0002 ] に対してアクセスモード [読み取り： R e a d] の処理が実行可能であることを確認し、読み取り処理を実行する。

また、ファイルアクセス装置（R/W：リーダライタ） 7 50が、例えばファィル I D [ 0 X 0002 ] のデータ書き込みコマンド： Wr i t e Co mm an d (0 x 000 2 )、あるいはファイル I D [ 0 x 0 00 1 ] のデータの暗号化処理コマンド： E n c r yp t i o n C omma nd (0 x 000 1 )をデパイスに送信した場合は、コマンドを受信したデバイスはファイルオープンテ一ブルのエントリを確認し、ファイル I D [ 0 x 0 002 ] に対する [書き込み： Wr i t e ] の処理、および、ファイル I D [0 x 0 00 1 ] の [暗号化処理] が、フアイルアクセス装置（R/W：リーダライタ） 750から受領したサービス許可チケット（S P T) によって許可されていないことを確認し、処理を停止する。また、ファイルアクセス装置（R/W：リーダライタ） 760は、デバイスとの相互認証の後、

ファイル I D : [0 x 000 1 ]

ファイルアクセスモード： [暗号化復号化処理： E n c & D e c ]

のアクセス許可チケットをデバイス 1 00に送信し、チケヅトの正当性検証、チケット発行者、利用者検証に成功したとする。

このとき、デバイスには図 8 1に示すファイルオープンテ一ブルの第 1行のェントリが生成される。このエントリは、パーティションマネ一ジヤコ一ド（PM C 1 ) で識別されるパーティション内のファイル I D [ 0 x 000 1 ] に対してアクセスモード [暗号化復号化処理： E n c & D e c ] の処理が実行可能であることを示している。

このとき、ファイルアクセス装置（ R/W：リ一ダライタ） 76 0は、コマンドを生成してデバイスに対して送信する。例えばファイル I D [ 0 x 000 1 ] の暗号化コマンド [E n c r yp t i o n Comma nd (0 x 000 1 )] をデバイスが受信すると、デバイスはフアイルオープンテ一ブルのェントリを確認し、ファイル I D ： 0 x 0 00 1に対してアクセスモード [暗号化復号化処理： E n c&D e c ]の処理が実行可能であることを確認し、暗号化処理を実行する。また、ファイルアクセス装置（RZW：リ一ダライタ） 760が、例えばファィル I D [0 x 0002]のデ一夕読み取りコマンド： R e ad C ommand ( 0 x 0002 ) をデバイスに送信した場合は、コマンドを受信したデバイスはファイルオープンテ一ブルのエントリを確認し、ファイル I D [ 0 x 0002 ] に対する [読み取り： Re ad] の処理が、ファイルアクセス装置（R/W：リ一ダライタ） 7 60から受領したサービス許可チケット（S PT) によって許可されていないことを確認し、処理を停止する。

このように、サービス許可チケットュ一ザであるデバイスアクセス機器としてのリーダライタからデバイスが受信したサービス許可チケット（S P T) に基づいて、デパイスは、前述の図 80の処理フローに従ってファイルオープンテ一ブルを生成し、生成したファイルオープンテ一ブルに基づいてファイルアクセス装置であるリ一ダライタからの各コマンドの実行可否を決定し、決定に従って処理を実行する。

次に、 2つのファイルに対する処理を実行する場合のアクセス処理について、図 84を用いて説明する。図の.左側に 2つのファイルアクセス装置（R/W : リ —ダライタ） 7 7 0、 780を示し、右側にファイルの生成されたデバイス 1 0 0のパーティション部分を示す。

まず、タ一ゲットファイルを指定したサービス許可チケット（S PT) (図 3 1 参照）を使用した処理の実行例を説明する。

ファイルアクセス装置（R/W：リ一ダライタ） 770は、デパスとの相互認証の後、

S P Tフォ一マツト 1

ファイル I D : [0 x 000 1 ]

および、 S P Tフォーマット 2

ファイル I D : [ 0 x 0002 ]

夕一ゲットファイル ' グループ： [PMC 1 ]

ターゲットファイル I D : [ 0 x 000 1 ]

読書き許可： [読み取り： R e a d]

の 2つのアクセス許可チケヅトをデバイス 1 00に送信し、チケットの正当性検証、チケット発行者、利用者検証に成功したとする。

このとき、デバイスには図 82に示すフアイルオープンテ一ブルのェントリが生成される。このエントリは、パーティションマネージヤコ一ド（PMC 1 ) で識別されるパ一ティシヨン内のファイル I D [0 x 000 1 ] は、鍵のファイルであり、暗号化、復号化が可能になるようにオープンされる。ファイル I D [ 0 X 0002 ] は、データのファイルであり、外部からの読み出しはファイルァクセスモード（File Access Mode) の欄が空白のため不可能であり、ファイル I D [0 x 000 1 ] に対して [読み取り： Re a d] を実行可能とする目的のためにオープンされて、フアイルオープンテーブルのェントリとして設定されていることを示している。

このとき、ファイルアクセス装置（R/W：リーダライタ） 770は、コマンドを生成してデバイスに対して送信する。例えばファイル I D [ 0 x 0002 ] の読み取り、ファイル I D [ 0 x 00 0 1 ] による内部暗号化コマンド： I n t e r n a 1 E n c r yp t i o n C omma nd 、0 x 0 00 1 , 0 x 00 0 2) を送信し、デバイスがコマンドを受信すると、デパイスはファイルオープンテーブルのエントリを確認し、ファイル I D [ 0 x 000 2 ] に対して、夕一ゲヅトファイルグループ [P M C 1 ]、夕一ゲットファイル [0 x 000 1 ] の [暗号化処理] に対して [読み取り： R e a d ] を実行可能であることを判定し、フアイル I D [0 x 0000 2] のデータを読み取り、ファイル I D [0 x 00 0 0 1 ] の鍵（k e y) による暗号化を実行して暗号化データをアクセス装置に送信する。

この夕一ゲヅトファイルを指定したサービス許可チケット（S P T) (図 3 1参照）を使用した処理によればあるファイルから読み出したデータを他のファイルに格納された暗号化鍵を用いて暗号化したデータを取得する処理が可能となり、復号デ一夕が外部に漏れるおそれがない。

次に、夕一ゲットファイルを指定したサービス許可チケット（S P T) (図 3 1 参照）ではなく、唯一のファイルに対する処理を指定したサービス許可チケット (SPT) (図 28参照）を複数用いた場合の処理について説明する。

ファイルアクセス装置（R/W：リ一ダライタ） 780は、デバイスとの相互認証の後、

S PTフォーマット 1として、

ファイル I D : [ 0 x 0002 ]

ファイルアクセスモード： [読み取り： R e a d]

また S PTフォーマット 2として、

ファイル I D : [ 0 x 000 1 ]

の 2つのアクセスチケットをデバイス 1 00に送信し、チケットの正当性検証、チケット発行者、利用者検証に成功したとする。

このとき、デパイスには図 8 1に示すファイルオープンテーブルの第 1行および第 2行の各エントリが生成される。このエントリは、パーティションマネ一ジヤコ一ド（PM C 1 ) で識別されるパ一テイシヨン内のファイル I D [0 0 0 0 1 ] に対してアクセスモード [暗号化復号化処理： E n c & D e c ] の処理が実行可能であり、パーティションマネージヤコ一ド（P M C 1 ) で識別されるパ —ティション内のファイル I D : 0 x 0002に対してアクセスモ一ド [読み取り： R e a d] の処理が実行可能であることを示している。

このとき、ファイルアクセス装置（R/W：リ一ダライタ） 780は、コマンドを生成してデバイスに対して送信する。まず、ファイル I D : [ 0 x 00 02 ] のデ一夕読み取りコマンド： Re a d C o mm a n d ( 0 x 0002 ) をデバイスが受信すると、デバイスはファイルオープンテーブルのエントリを確認し、フアイル I D : 0 x 0002に対してアクセスモード [読み取り： R e a d ] の処理が実行可能であることを確認し、読み取り処理を実行し、ファイルアクセス装置に読み取りデータを送信する。

次に、ファイルアクセス装置（R/W：リーダライタ） 780は、さらにコマンドを生成してデバイスに対して送信する。ファイル I D [ 0 x 000 1 ] によるデ一夕（D a t a)の暗号化コマンド [E n c r yp t i o n C omma nd (0 x 0 00 1 , D a t a)] をデバイスが受信すると、デバイスはフアイルオープンテーブルのェントリを確認し、ファイル I D [ 0 x 000 1 ] に対してァクセスモ一ド [暗号化複号化処理： E n c &D e c ] の処理が実行可能であることを確認し、暗号化処理を実行し暗号化データ [E n c r yp t i o n D a t a] をファイルアクセス装置（R/W：リーダライタ） 780に送信する。

このように、ターゲットファイルを指定したサービス許可チケット（S PT) (図 3 1参照）ではなく、唯一のファイルに対する処理を指定したサービス許可チケット（S P T) (図 28参照）を複数用いた場合は、暗号化対象データの読み出し処理が実行され、ファイルアクセス装置 780とデバイス間におけるデータ転送処理の回数が増加することになる。また、データが暗号化されずにデバイスの外に読み出されてしまう。一方、サービス許可チケット（S P T ) (図 3 1参照）に、アクセス対象とした複数のデータファイルを識別する複数のファイル識別子を含ませ、該複数のファィル識別子中、一方は夕一ゲットファイル識別子として設定するとともにタ一ゲットファイルに対する読み取りまたは書き込み許可デ一夕を格納し、他方のデー夕ファイルのアクセスモードとして該データファイルに格納した暗号鍵を用いた暗号化処理を設定した構成とすれば、メモリ搭載デバイスは、アクセス機器からサービス許可チケット（S P T ) を受領して、指定アクセスモードに従った処理として、ターゲットファイルの読み取りおよび暗号鍵による暗号化処理を実行することになり、メモリ搭載デバイス内における内部暗号化処理を実行することが可能となる。また、データが暗号化されずにデバイスの外に流出することを防止することができる。

サービス許可チケット（ S P T ) を発行するチケット発行手段は、メモリ搭載デバイスのメモリ領域を管理するェンティティであるパーティションマネージャの管理下にあるチケット発行手段であり、各アクセス機器に応じて各種のァクセスモードを設定したサービス許可チケット（S P T ) を個別に発行することにより、各アクセス機器に応じて異なる態様のアクセスを実行可能とした構成が実現される。

(セッション鍵の使用態様）

なお、ファイルアクセス装置とデバイス間において送受信されるデータは、デパイスのユーザ情報、あるいは金額情報など外部に対する漏洩を防止すべきデータであることが多い。従ってファイルアクセス装置とデバイス間において送受信されるデータは、暗号化処理を実行し、また改竄チヱック値としての M A C (Message Authentication Code) を付加したデータとするのが望ましい。

データの暗号化には、ファイルアクセス装置とデバイス間において実行される相互認証処理において生成されるセッション鍵を用いることが可能である。前述したように相互認証には、デバイスに対するデバイス認証、各パーティションに対する認証としてのパ一テイション認証がある。パーティションに生成済みのフアイルに対するアクセスを実行する場合、データ転送の際に適用する暗号化鍵としていずれを適用するかはいくつかの選択肢がある。例えば図 85に示すように、デパイス 1 00とアクセス装置 800との間において、デパイス認証によって生成されたセッション鍵 K s e s 1、パーティションマネージャコード（PMC 1 ) に対応するパーティションとのパーティション認証によって生成されたセッシヨン鍵 K s e s 2、パーティションマネ一ジヤコ —ド（PMC 2 ) に対応するパーティションとのパーティション認証によって生成されたセッション鍵 K s e s 3がある場合がある。

これらは、相互認証の際に生成される認証テーブル（図 5 1、図 52参照）にセッションクリアまで格納される。

デバイスとデバイスとの通信を実行するデバイスアクセス機器としてのリーダライタ（P C他の通信装置）は、これら複数のセッション鍵のいずれを適用して暗号化通信を実行するかを、ルールとして予め取り決めておき、決定されたル一ルに従ってセッション鍵を適用する構成が可能である。

複数の異なるパ一ティシヨン内のファイルアクセスを、複数の異なるパ一ティション各々に対応して設定された認証条件であるパーティション認証またはデパイス認証のすべての認証成立を条件として許容する場合、複数の認証処理の結果、取得された複数のセッション鍵に基づいて唯一の統合セヅション鍵を生成し、該統合セッション鍵に基づいてアクセス機器との通信デ一夕の暗号処理を実行する統合セッション鍵生成手法としての 1つの方法は、デバイスとデバイスとの通信を実行するデバイスアクセス機器としてのリ一ダライタ（P c他の通信装置）間における相互認証処理によって複数のセッション鍵 K s e s 1〜K s e s Nが生成された場合、これら複数のセヅシヨン鍵 K s e s l〜K s e s Nの排他論理和処理（ex. 8バイト処理）を実行し演算結果を通信データの暗号化用セッシヨン鍵とする方法である。すなわち、

Kses = Ksesl XOR Kses2 XOR Kses3- XO R ：排他論理和処理（ e x . 8バイト処理）

によって算出された K s e sをセッション鍵として用いる。

デバイスとデバイスとの通信を実行するデバイスアクセス機器としてのリーダライタ（P C他の通信装置）間では、双方の認証テーブルに格納されたセッション鍵を排他論理和演算しその出力値をセッション鍵として使用するというルールを定め、該ルールに基づいてセッション鍵を算出して通信データの暗号化に用いる構成とする。また、同様にして、相互認証時に同時に共有した別のセッション鍵、例えば公開鍵認証時において生成したセッション鍵、あるいはセッション鍵生成データ、例えば Y座標の下位 64ビットを用いてセッション中の通信データに MAC値を付加することができる。この MAC値を通信データ（暗号化データである場合もある）とともに送信し、受信側で MAC検証処理を行なうことで、通信路上のデータ改竄を防止することが可能となる。 MAC生成、検証処理については先に説明した図 5 9を参照されたい。

あるいは、デバイスとデバイスとの通信を実行するデパイスアクセス機器としてのリ一ダライタ（P C他の通信装置）間における相互認証処理によって取得された複数のセッション鍵 K s e s l〜K s e s Nの中で、いずれかの 1つの鍵（e X . 最新のセッション鍵）を選択してその後の通信処理におけるデータ暗号化鍵として適用するというルールを設定し、該ルールに従って、セッション鍵を選択して通信データの暗号化に用いる構成としてもよい。

なお、上述した複数のセッション鍵の演算による算出、あるいは選択処理は、ファイルアクセス装置とデバイス間の暗号化通信のみならず、すべてのチケット (PRT, FRT， S PT, DUT) ユーザ（デバイスアクセス機器としてのリ —ダライタなどのデバイスとのデータ通信を実行する機器）とデバイス間の暗号化通信処理において、相互認証により複数のセッション鍵が生成された場合に適用できる。各チケットユーザとデバイス相互において、どのようなルールに従つて、適用するセッション鍵を複数のセッション鍵から算出するかまたは選択するかについては予めルールとして取り決め、相互にルールを確認した後実行するか、あるいは各チケットにルールを記録しておくなどの措置が採用可能である。

次に、図 86、図 87を用いてファイルアクセス装置によるデバイスに対するアクセス処理（図 79の処理フローにおけるステップ S 8 57 , 869 ) 手順の代表的例について説明する。

図 8 6を用いて 1つのファイルのみに対してアクセスを実行する場合の処理 (No rma l) について説明し、図 87を用いて複数ファイルに対してァクセスを行なう場合の処理（C omb i na t i o n) について説明する。まず、図 86の 1つのファイルのみに対してアクセスを実行する場合の処理（N o r m a 1 ) について説明する。図 86のフローにおいて、左側がファイルァクセス装置、右側がデバイス（図 5参照）の処理を示す。なお、ファイルアクセス処理において、ファイルアクセス装置とデパイス間におけるデータ転送の際には、相互認証処理において取得したセッション鍵 K s e s、あるいは複数のセッション鍵から演算マ夕は選択されたセッション鍵を用いて暗号化され、また改竄チェック用の MACの生成、検証処理が実行される。

ファイルアクセス装置は、ステップ S 89 1において、アクセスコマンドをデパイスに送信する。このコマンドは、アクセス対象のファイル I D、アクセスモ —ドを指定したコマンドであり、例えば先に図 83を用いて説明したようなファィル I D [0 x 0002]のデータ読み取りコマンド： R e a d Comma nd ( 0 x 0002 )、あるいは、ファイル I D [0x 000 1 ]の暗号化コマンド [E n c r yp t i o n C ommand (0 x 000 1 )] などである。

デパイスは、ファイルアクセス装置からのコマンドを受信（S 90 1 )すると、コマンドに含まれるファイル I D、アクセスモードがファイルオープンテーブルに許可されたェントリとして記録されているか否かを判定（ S 9 02 ) する。フアイルオープンテ一ブルにコマンドに対応するファイル I D、アクセスモードのエントリが存在しない場合は、コマンドに従った処理を実行せず、アクセスエラ一をファイルアクセス装置に送信（S 908 ) する。

ファイルオープンテ一ブルにコマンドに対応するファイル I D、アクセスモ一ドのエントリが存在した場合は、ステップ S 903において、デパイスのメモリ内の対応パ一テイシヨンのフアイル定義プロック（ F D B ) (図 24参照）に記録されたファイルアクセス認証方式（Acceptable Authentication Type ：特定のフアイル（File) アクセスを行う際に、指定する認証方式）を参照し、アクセス対象のファイルに対するアクセスコマンドの実行に必要な認証レベル（公閧鍵認証を必要とするか）を確認する。

ステップ S 9 0 3において、ファイル定義ブロック（FDB) のファイルァクセス認証方式（Acceptable Authentication Type) が公開鍵認証を必要とする設定である場合は、ステップ S 904において、アクセスコマンドに必要な認証レベルの認証としての公開鍵認証が済んでいるか否かを判定し、認証未了の場合は、コマンドに従った処理を実行せず、アクセスエラ一をファイルアクセス装置に送信（S 908 ) する。認証の終了または未了は、相互認証時に設定される認証テ —ブル（図 5 1参照）に基づいて判定される。

ステップ S 9 03において、フアイル定義プロック（FDB) のファイルァクセス認証方式（Acceptable Authentication Type) が公開鍵認証を必要とする設定であり、ステップ S 904において、公開鍵認証が済んでいると判定された場合、あるいは、ファイル定義ブロック（FD B) のファイルアクセス認証方式 (Acceptable Authentication Type) が公開鍵認証を必要としない設定である場合は、次に、ステップ S 905において、デバイスのメモリ内の対応パ一テイションのファイル定義プロヅク（FDB) (図 24参照）に記録されたファイルァクセス検証方式（Acceptable Verification Type ：特定のファイル（File) ァクセスを行う際に、指定する検証方式）を参照し、アクセス対象のファイルに対するアクセスコマンドの実行に必要な検証レベル（公閧鍵方式の検証を必要とするか）を確認する。

ステップ S 9 05において、フアイル定義プロック（FDB) のファイルァクセス検証方式（Acceptable Verification Type) が公開鍵方式のチケット検証を必要とする設定である場合は、ステップ S 90 6において、アクセスコマンドに必要な検証レベルの検証としての公開鍵方式のチケット検証が済んでいるか否かを判定し、検証未了の場合は、コマンドに従った処理を実行せず、アクセスエラ —をファイルアクセス装置に送信（S 908 ) する。

ステップ S 9 05において、ファイル定義ブロック（FDB) のファイルァクセス検証方式（Acceptable Verification Type) が公開鍵方式のチケット検証を必要とする設定であり、ステップ S 9 06において、公開鍵方式のチケット検証が済んでいると判定された場合、あるいは、ファイル定義ブロック（FDB) のファイルアクセス検証方式（Acceptable Verification Type) が公開鍵方式のチケット検証を必要としない設定である場合は、ステップ S 907において、ファィルアクセス装置から受信したアクセスコマンドの処理を実行し、結果をフアイルアクセス装置に送信する。アクセスコマンド結果を受信（S 8 92 ) したファイルアクセス装置は、さらに他のファイルアクセスを実行するか否かを判定（S 89 3 ) し、他のファイルアクセスを実行する場合は、ステップ S 89 1以下を繰り返し実行し、他にファィルアクセスを実行しない場合は処理を終了する。

次に、図 87を用いて複数ファイルに対してアクセスを行なう場合の処理（C omb i na t i o n) について説明する。図 87のフローにおいて、左側がフアイルアクセス装置、右側がデパイス（図 5参照）の処理を示す。なお、フアイルアクセス処理において、ファイルアクセス装置とデバイス間におけるデータ転送の際には、相互認証処理において取得したセッション鍵 K s e s、あるいは複数のセッション鍵から演算または選択されたセッション鍵を用いて暗号化され、また改竄チェック用の MA Cの生成、検証処理が実行される。

ファイルアクセス装置は、ステップ S 9 1 1において、アクセスコマンドをデバイスに送信する。このコマンドは、アクセス対象のフアイル I D (ソース）、夕 —ゲットファイル I D、アクセスモードを指定したコマンドであり、例えば先に図 84を用いて説明したような、ソースファイル I D [ 0 x 0002]に対して、ターゲットファイル I D [ 0 x 000 1 ] の鍵による内部暗号化処理の実行を指定するコマンド [I nt e r na l E n c r yp t i o n Command ( 0 x 000 1 , 0 x 0002 )] などである。

デバイスは、ファイルアクセス装置からのコマンドを受信（S 92 1 ) すると、フアイルオープンテ一ブルの夕一ゲットファイル I Dのェントリにアクセスコマンドの許可があるか否かを判定（ S 9 22 ) する。ファイルオープンテ一ブルのターゲットファイル I Dのエントリにアクセスコマンドの許可が存在しない場合は、コマンドに従った処理を実行せず、アクセスエラ一をファイルアクセス装置に送信（S 934 ) する。

ファイルオープンテ一ブルの夕一ゲットファイル I Dのェントリにアクセスコマンドの許可が存在した場合は、ステップ S 92 3において、デバイスのメモリ内の対応パーティションのファイル定義プロヅク（FD B) (図 24参照）に記録されたファイルアクセス認証方式（Acceptable Authentication Type ：特定のフアイル（File) アクセスを行う際に、指定する認証方式）を参照し、アクセス対象の夕一ゲットファイルに対するアクセスコマンドの実行に必要な認証レベル (公開鍵認証を必要とするか）を確認する。

ステップ S 9 2 3において、アクセス対象のタ一ゲットファイルに対して設定されたファイル定義プロック（F D B )のファイルアクセス認証方式（Acceptable Authentication Type) が公開鍵認証を必要とする設定である場合は、ステップ S 9 2 4において、アクセスコマンドに必要な認証レベルの認証としての公開鍵認証が済んでいるか否かを判定し、認証未了の場合は、コマンドに従った処理を実行せず、アクセスエラ一をファイルアクセス装置に送信（S 9 3 4 ) する。認証の終了または未了は、相互認証時に設定される認証テーブル（図 5 1参照）に基づいて判定される。

ステップ S 9 2 3において、アクセス対象の夕一ゲットファイルに対して設定されたファイル定義プロック（F D B )のフアイルアクセス認証方式（Acceptable Authenticati on Type) が公開鍵認証を必要とする設定であり、ステップ S 9 2 4 において、公閧鍵認証が済んでいると判定された場合、あるいは、ファイル定義ブロック（ F D B ) のファイルアクセス認証方式（Acceptabl e Authentication Type) が公開鍵認証を必要としない設定である場合は、次に、ステップ S 9 2 5 において、デバイスのメモリ内の対応パーティションのフアイル定義プロック（F D B ) (図 2 4参照）に記録されたファイルァクセス検証方式（Acceptable Veri f ication Type：特定のファイル（F i le) アクセスを行う際に、指定する検証方式）を参照し、アクセス対象のターゲットファイルに対するアクセスコマンドの実行に必要な検証レベル（公開鍵方式の検証を必要とするか）を確認する。ステップ S 9 2 5において、アクセス対象のタ一ゲットファイルに対して設定されたファイル定義プロック（F D B )のフアイルアクセス検証方式（Acceptable Veri f ication Type)が公開鍵方式のチケット検証を必要とする設定である場合は、ステップ S 9 2 6において、アクセスコマンドに必要な検証レベルの検証としての公開鍵方式のチケット検証が済んでいるか否かを判定し、検証未了の場合は、コマンドに従った処理を実行せず、アクセスエラ一をファイルアクセス装置に送信（ S 9 3 4 ) する。

ステップ S 9 2 5において、アクセス対象の夕一ゲヅトファイルに対して設定されたファイル定義ブロヅク（FDB)のファイルアクセス検証方式（Acceptable Verification Type) が公開鍵方式のチケット検証を必要とする設定であり、ステップ S 926において、公開鍵方式のチケット検証が済んでいると判定された場合、あるいは、ファイル定義ブロック（FD B) のファイルアクセス検証方式 (Acceptable Verification Type) が公開鍵方式のチケット検証を必要としない設定である場合は、次に、ステップ S 927において、アクセスコマンドに含まれる夕一ゲットファイル I Dによって指定されるファイルのアクセス方法 (Read/Write) をコマンドに基づいて確認する。

デバイスは、ファイルアクセス装置からのコマンドに含まれるソースファイル I Dによって指定されるファイルがアクセスコマンドに含まれるアクセス方法 (Read/Write) に対してオープンしているか否かを判定（S 928 ) する。ファィルオープンテーブルにコマンド実行のためのアクセス方法（Read/Write) が存在しない場合は、コマンドに従った処理を実行せず、アクセスエラ一をファイルアクセス装置に送信（S 9 34) する。

ファイルオープンテーブルにコマンドに対応するアクセス方法（Read/Write) が存在した場合は、ステップ S 929において、デバイスのメモリ内の対応パーティションのファイル定義プロック（FDB) (図 24参照）に記録されたフアイルアクセス認証方式（Acceptable Authentication Type ：特定のファイル（File) アクセスを行う際に、指定する認証方式）を参照し、アクセス対象のソースファィルに対するアクセスコマンドの実行に必要な認証レベル（公開鍵認証を必要とするか）を確認する。

ステップ S 929において、アクセス対象のソースファイルに対して設定されたファイル定義ブロック（FD B) のファイルアクセス認証方式（Acceptable Authentication Type) が公開鍵認証を必要とする設定である場合は、ステップ S 930において、アクセスコマンドに必要な認証レベルの認証としての公閧鍵認証が済んでいるか否かを判定し、認証未了の場合は、コマンドに従った処理を実行せず、アクセスエラ一をファイルアクセス装置に送信（S 934 ) する。認証の終了または未了は、相互認証時に設定される認証テーブル（図 5 1参照）に基づいて判定される。ステップ S 929において、アクセス対象のソースファイルに対して設定されたファイル定義ブロック（FD B) のファイルアクセス認証方式（Acceptable Authentication Type) が公開鍵認証を必要とする設定であり、ステップ S 93 0 において、公開鍵認証が済んでいると判定された場合、あるいは、ファイル定義ブロック（FD B) のファイルアクセス認証方式（Acceptable Authentication Type) が公開鍵認証を必要としない設定である場合は、次に、ステップ S 93 1 において、デバイスのメモリ内の対応パ一テイションのフアイル定義プロック（ F D B) (図 2 4参照）に記録されたファイルアクセス検証方式（Acceptable Verification Type：特定のファイル（File) アクセスを行う際に、指定する検証方式）を参照し、アクセス対象のソースファイルに対するアクセスコマンドの実行に必要な検証レベル（公開鍵方式の検証を必要とするか）を確認する。

ステップ S 9 3 1において、アクセス対象のソースファイルに対して設定されたファイル定義ブロック（ FD B) のファイルアクセス検証方式（Acceptable Verification Type)が公開鍵方式のチケット検証を必要とする設定である場合は、ステップ S 93 2において、アクセスコマンドに必要な検証レベルの検証としての公開鍵方式のチケット検証が済んでいるか否かを判定し、検証未了の場合は、コマンドに従った処理を実行せず、アクセスエラ一をファイルアクセス装置に送信（ S 934 ) する。

ステップ S 9 3 1において、アクセス対象のソースフアイルに対して設定されたファイル定義ブロック（FD B) のファイルアクセス検証方式（Acceptable Verification Type) が公開鍵方式のチケヅト検証を必要とする設定であり、ステップ S 932において、公開鍵方式のチケット検証が済んでいると判定された場合、あるいは、ファイル定義ブロック（FD B) のファイルアクセス検証方式 (Acceptable Verification Type) が公開鍵方式のチケット検証を必要としない設定である場合は、ステップ S 933において、ファイルアクセス装置から受信したアクセスコマンドの処理を実行し、結果をファイルアクセス装置に送信する。アクセスコマンド結果を受信（S 9 1 2) したファイルアクセス装置は、さらに他のファイルアクセスを実行するか否かを判定（S 9 1 3) し、他のファイルアクセスを実行する場合は、ステップ S 9 1 1以下を繰り返し実行し、他にファィルアクセスを実行しない場合は処理を終了する。

上述したファイルアクセス処理は、ファイル内にある 1つのファイル構造によつて指定されるデータが格納された場合の処理を想定して説明しているが、異なるファイル構造データを 1つのファイル内に格納し、 1つのファイルに対する 1 つのコマンドにより、上述の複数ファイルに対するシーケンシャル処理と同様の処理を実行する構成も可能である。

図 88に 1つのファイルに対する 1つのコマンドにより、 1フアイル内のデ一夕に対してシーケンシャル処理を実行する構成を説明する図を示す。

ファイルは図に示すように、電子マネーファイルであり、金額データとしての [Pu r s e], 利用ログデータとしての「L o g」、データに対する暗号化または復号用の鍵データとしての [K e y] から構成される。

例えば、図 88 (a) に示すように、預け入れコマンド（Deposit Command) を規定し、ファイル内の金額データとしての [P u r s e] に X円を加算（S 94 1 ) し、さらに、ファイル内の利用ログデータとしての「L o g」に [Pu r s e] に X円を加算した記録を書き込む（S 942 ) という 2つの処理を実行させる構成とすることが可能である。

先に説明したファイルアクセスモード（図 2 9参照）の入金系に対応する許容コマンド（図 3 0参照）として、上述の預け入れコマンド（Deposit Command) を定義し、アクセス許可チケットのファイルアクセスモード（File Access Mode) に [入金系] を設定し、ファイル I D(File ID)として、電子マネ一を構成する複合ファイルを指定したアクセス許可チケット（S PT) を生成して、ファイルァクセス装置からデバイスに対して送信した後、預け入れコマンド（Deposit Co匪 and) とともに、預け入れ金額データを送信することにより、図 88 (a) に示すようなデパイスにおいて 1つのフアイル内のデ一夕に対するシ一ケンシャル処理を実行させることが可能となる。

また、図 88 (b)に示すように、レシ一ト生成コマンド（Make Receipt Command) を規定し、ファイル内の金額データとしての [P u r s e] から X円を減算（S 945 ) し、さらに、ファイル内の利用ログデータとしての「L o g」に [P u r s e ] から X円を減算した記録を書き込み（S 946 )、さらに「L o g」にデ —夕に対する暗号化鍵データとしての [Ke y] を適用して署名をつけて送信する（S 947 ) という 3ステップの処理を実行させる構成とすることも可能である。

この場合はファイルアクセスモード（図 29参照）の出金系に対応する許容コマンド（図 30参照）として、上述のレシート生成コマンド（Make Receipt Command) を定義し、アクセス許可チケットのファイルアクセスモード（File Access Mode) に [出金系] を設定し、ファイル I D(File ID)として、電子マネ一を構成する複合ファイルを指定したアクセス許可チケット（S P T) を生成して、ファイルァクセス装置からデバイスに対して送信した後、レシート生成コマンド（Make Receipt Co匪 and) とともに、引き出し金額データを送信することにより、図 88 (b ) に示すようなデバイスにおいて 1つのフアイル内のデータに対するシ一ケンシャル処理を実行させることが可能となる。

このようにデバイスは、サービス許可チケット（S PT) に指定された処理フアイルが複合ファイルである場合、アクセス機器からの受領コマンドの処理対象ファイルを複合ファイル内から選択して処理を実行する。アクセス機器からのデ —夕処理コマンドが一連の複数の処理を含むシーケンス処理コマンドである場合は、デバイスは、シーケンス処理コマンドに含まれる各コマンドの処理対象ファィルを、サービス許可チケット（SP T) によって指定された複合ファイル内から順次選択して実行する。

[B 4. 7. サービス許可チケット（S P T) を利用したアクセス処理各方式における処理手順]

上述したサービス許可チケット（S PT) を利用したアクセス処理ファイルの設定登録処理において、パーティションマネージャが管理し、サービス許可チケヅト（SPT) ユーザであるデバイスアクセス機器としてのリーダライタとデバイス間において、相互認証が実行され、サービス許可チケット（S PT) に基づくファイルアクセスがなされる。相互認証処理の態様は、公開鍵相互認証、共通鍵相互認証の 2種類のいずれかであり、またチケット（S PT) の検証処理も公開鍵系の署名検証、共通鍵系の MAC検証の 2種類のいずれかが実行されることになる。すなわち処理態様としては大きく分けて、 (A) 相互認証（公開鍵）、チ,ケット（S P T) 検証（公開鍵）

(B) 相互認証（公開鍵）、チケット（S P T) 検証（共通鍵）

(C) 相互認証（共通鍵）、チケット（S P T) 検証（共通鍵）

(D) 相互認証（共通鍵）、チケット（S P T) 検証（公開鍵）

の 4態様がある。

これらの 4態様についての処理を、認証局（CA (PM))、パーティションマネ一ジャ（PM)、 S PTチケヅトュ一ザであるデバイスアクセス機器としてのリ —ダライタ、デバイス、各エンティティ間において実行されるデータ転送処理を中心として図を用いて簡潔に説明する。

(A) 相互認証（公開鍵）、チケット（S P T) 検証（公開鍵）

まず、相互認証処理に公開鍵方式を適用し、チケット（S PT) 検証に公開鍵方式を適用する場合の各ェンティティ間のデータ転送について図 89を用いて説明する。

パーティションマネージャ（PM) の公開鍵証明書（C e r t . PM) は、パ —テイシヨンマネージャ（PM) からの発行要求により、登録局（RA) を介した証明書発行手続きによってパーティション対応認証局（ C A (PAR))から発行される。なお、本構成は、パーティションマネージャがサービス許可チケット発行手段（S P T Issuer) を兼ねる構成であり、サービス許可チケット発行手段 ( S P T Issuer)の公開鍵証明書としてパーティションマネージャ（PM)の公開鍵証明書を使用する構成である。

( 2 )サービス許可チケットュ一ザ（ S P T User)であるデバイスアクセス機器としてのリーダライタ（R/W) の公開鍵証明書（C e r t . RW) の発行、サービス許可チケットュ一ザ（S P T User:具体的には、デバイスに対してチケヅトを送信するデバイスアクセス機器としてのリーダライタ（R/W))の公開鍵証明書（C e r t . R/W) は、サ一ビス許可チケットュ一ザ（S P T User) であるリーダライタ（R/W) からの発行要求により、登録局（RA) を介した証明書発行手続きによってパーティション対応認証局（CA (PAR)) によって発行される。なお、パ一ティションマネージャがサービス許可チケットユーザ（ S PT User) を兼ねる構成も可能であり、その場合は、サービス許可チケットユーザ（S PT User) の公開鍵証明書としてパーティションマネージャ（PM) の公開鍵証明書を使用可能である。

( 3 ) サービス許可チケット（ S P T) の生成処理

サービス許可チケット（S PT) は、パーティションマネージャの管理するサ —ビス許可チケット発行手段（ S P T Ticket Issuer) により生成される。この場合、公開鍵方式の署名生成、検証を実行するため、サービス許可チケット発行手段（S P T Ticket Issuer) の秘密鍵による署名（Signature)が生成（図 1 2参照）されて S P Tに付加される。

(4) S PTおよびサービス許可チケット発行手段（S P T Ticket Issuer) としてのパーティションマネージャ公開鍵証明書（Ce r t . PM) のサービス許可チケットユーザ（ S P T User)であるデパイスアクセス機器としてのリーダライタ（R/W) に対する供給

パーティションマネージャの管理するサービス許可チケット発行手段（S P T

Ticket Issuer) により発行されたサービス許可チケット（S P T) は、サービス許可チケット発行手段（S P T Ticket Issuer) としてのパ一ティションマネ一ジャ公閧鍵証明書（C e r t . PM) とともにサービス許可チケットュ一ザ（S

PT User)であるデバイスアクセス機器としてのリ一ダライタ（R/W) に対して送信される。

( 5 ) デバイスアクセス機器としてのリ一ダライタ（R/W) とデバイス間の相互認証

サービス許可チケヅトュ一ザ（S P T User)であるリーダライタは、サービス許可チケット発行手段（S P T Ticket Issuer) の発行したサービス許可チケット（S PT) に従ったファイルアクセスを実行しょうとする対象のデバイスに対し、チケットユーザ（ S P T User) としてのリーダライタ（R/W) の公開鍵証明書（C e r t . RW) をデパイスに送信し、公開鍵方式の相互認証（図 50参照）を実行する。

(6) S P Tおよびサービス許可チケヅト発行手段（S P T Ticket Issuer) としてのパーティションマネージャ公開鍵証明書（C e r t . PM) のデバイスに対する供給

デバイスアクセス機器としてのリーダライタ（R/W) とデバイス間の相互認証が成立すると、チケットュ一ザ（S P T User)としてのリ一ダライタ（R/W) は、デバイスに対してサービス許可チケヅト（S PT)、およびサービス許可チケット発行手段（S PT Ticket Issuer) としてのパーティションマネージャ公開鍵証明書（C e r t . PM) を送信する。

デバイスは、受信したサービス許可チケット（ S P T) について、（ 1 ) チケット発行者（Ticket Issuer) としてのパーティションマネージャ公開鍵証明書（C e r t . PM) が改竄されたものでない正当な公開鍵証明書（CERT) であること、（ 2 ) チケット発行者（Ticket Issuer) の公開鍵証明書（CERT P M) のオプション領域に記録されたコードと、デバイス内の FDB (File Definition Block) に記録された（SPTIC) の一致、（3 ) チケット発行手段（Ticket Issuer) がリボークされていないこと、（ 4 ) 受信チケット（ S P T) の署名（Signature) の検証によりチケットが改竄のないことの確認を実行し、さらに、 S PTチケットに格納された S P Tユーザ（チケットュ一ザとしてのリ一ダライタ）とチケヅトュ一ザ（ S P T User)の公開鍵証明書（C e r t . RW) の識別データ（D N) として記録された識別子またはカテゴリまたはシリアル（SN) 名（DN) の一致を確認し、相互認証済みであることを確認することにより S P Tユーザ（デバイスアクセス機器としてのリーダライタ）の検証（図 57、図 58参照）を実行する。

(7) ファイルアクセス

デバイスは、処理対象ファイルにサービス許可チケット（S P T) に記述されたルールに従ってアクセスを実行する。

以上の処理によって、相互認証（公閧鍵）、チケット（S P T) 検証（公開鍵）の各方式に従ったファイルアクセス処理が実行される。

(B) 相互認証（公開鍵）、チケット（S P T) 検証（共通鍵）次に、相互認証処理に公開鍵方式を適用し、チケット（S PT) 検証に共通鍵方式を適用する場合の各ェンティティ間のデ一夕転送について図 90を用いて説明する。

( 1 ) サービス許可チケットュ一ザ（S P T User)であるデバイスアクセス機器としてのリーダライタ（R/W) の公開鍵証明書（C e r t . RW) の発行、サービス許可チケットュ一ザ（ S P T User：具体的には、デバイスに対してチケットを送信するデバイスアクセス機器としてのリーダライタ（R/W))の公開鍵証明書（Ce r t . R/W) は、サービス許可チケットュ一ザ（S P T User) であるリ一ダライタ（R/W) からの発行要求により、登録局（RA) を介した証明書発行手続きによってパーティション対応認証局（CA (PAR))によって発行される。なお、パーティションマネージャがサービス許可チケヅトュ一ザ（S PT User) を兼ねる構成も可能であり、その場合は、サービス許可チケットュ一ザ（ S P T User) の公開鍵証明書としてパーティションマネージャ（PM) の公開鍵証明書を使用可能である。

( 2 ) サービス許可チケヅト（ S P T) の生成処理

サ一ビス許可チケット（S P T) は、パーティションマネ一ジャの管理するサ —ビス許可チケット発行手段（S P T Ticket Issuer) により生成される。この場合、共通鍵方式の検証値として MA C(Message Authentication Code) (図 59 参照）が S P Tに付加される。

(3) S P Tのサ一ビス許可チケットユーザ（S P T User)であるデバイスァクセス機器としてのリーダライタ（R/W) に対する供給

パーティションマネージャの管理するサービス許可チケット発行手段（S P T Ticket Issuer) により発行されたサービス許可チケット（S P T) は、サービス許可チケヅトュ一ザ（S P T User) としてのリーダライタ（R/W) に対して送信される。

(4) リーダライタ（R/W) とデバイス間の相互認証

サービス許可チケットユーザ（S PT User)であるデバイスアクセス機器としてのリ一ダライタは、サービス許可チケット発行手段（S PT Ticket Issuer) の発行したサービス許可チケット（S PT) に従ったファイルアクセスを実行しようとする対象のデバイスに対し、チケットュ一ザ（ S P T User) としてのリ一ダライタ（R/W) の公開鍵証明書（ C e r t . RW) をデバイスに送信し、公閧鍵方式の相互認証（図 5 0参照）を実行する。

パーティションマネージャ（PM) の公開鍵証明書を使用可能である。

(5) S P Tのデパイスに対する供給

デバイスアクセス機器としてのリ一ダライタ（R/W) とデバイス間の相互認証が成立すると、サービス許可チケヅトユーザ（S P T User)であるリーダライタは、デバイスに対してサービス許可チケット（S P T) を送信する。デバイスは、受信したサービス許可チケット（S PT) について M A C検証処理を実行し、 S PT発行者（SPT Issuer) の検証、さらに、 S P Tチケットに格納された S P Tユーザ（チケヅトュ一ザとしてのリーダライ夕）とチケットユーザ（ S P T User) の公開鍵証明書（C e r t . RW) の識別データ（DN) として記録された識別子またはカテゴリまたはシリアル（SN) 名（DN) の一致を確認し、相互認証済みであることを確認することにより S PTユーザ（デバイスアクセス機器としてのリーダライタ）の検証（図 57、図 58参照）を実行する。

(6) ファイルアクセス

デバイスは、処理対象ファイルにサービス許可チケット（S PT) に記述されたルールに従ってアクセスを実行する。

以上の処理によって、相互認証（公開鍵）、チケット（S P T) 検証（共通鍵）の各方式に従ったファイルアクセス処理が実行される。

(C) 相互認証（共通鍵）、チケット（S PT) 検証（共通鍵）

次に、相互認証処理に共通鍵方式を適用し、チケット（S PT) 検証に共通鍵方式を適用する場合の各エンティティ間のデ一夕転送について図 9 1を用いて説明する。

( 1 ) サービス許可チケット（S P T) の生成処理サ一ビス許可チケット（ S P T) は、パ一ティションマネージャの管理するサ —ビス許可チケット発行手段（ S P T Ticket Issuer) により生成される。この場合、共通鍵方式の検証値として M A C (Message Authentication Code) (図 59 参照）が S P Tに付加される。

(2) S Ρ Τのサービス許可チケヅトュ一ザ（S PT User) に対する供給パーティションマネージャの管理するサービス許可チケヅト発行手段（S P T Ticket Issuer) により発行されたサービス許可チケット（S P T) は、サービス許可チケットユーザ（S P T User)であるデバイスアクセス機器としてのリーダライタに対して送信される。

( 3 ) デバイスアクセス機器としてのリーダライタ（R/W) とデバイス間の相互認証

サービス許可チケットユーザ（S P T User)であるデバイスアクセス機器としてのリーダライタ（R/W) は、サービス許可チケット発行手段（S PT Ticket Issuer) の発行したサ一ビス許可チケット（S PT) に従ったファイルを生成しようとする対象のデバイスとの間で、共通鍵方式の相互認証（図 53、図 54参照）を実行する。

(4) S P Tのデバイスに対する供給

デバイスアクセス機器としてのリーダライタ（R/W) とデバイス間の相互認証が成立すると、サービス許可チケットュ一ザ（S P T User)であるリーダライタは、デバイスに対してサービス許可チケット（S PT) を送信する。デバイスは、受信したサービス許可チケット（S PT) について M A C検証処理を実行し、 S PT発行者（SPT Issuer) の検証、さらに、 S P Tチケットに格納された S P Tユーザ（チケットユーザとしてのリ一ダライタ）とチケットユーザ（S P T User) の識別子の一致を確認し、相互認証済みであることを確認することにより S P Tユーザ（デバイスアクセス機器としてのリ一ダライタ）の検証（図 57、図 58参照）を実行する。

(5) ファイルアクセス

デバイスは、処理対象ファイルにサービス許可チケット（S P T) に記述されたルールに従ってアクセスを実行する。以上の処理によって、相互認証（共通鍵）、チケット（SPT) 検証（共通鍵）の各方式に従ったファイルアクセス処理が実行される。

(D) 相互認証（共通鍵）、チケット（S P T) 検証（公開鍵）

次に、相互認証処理に共通鍵方式を適用し、チケット（S PT) 検証に公開鍵方式を適用する場合の各エンティティ間のデータ転送について図 92を用いて説明する。

パーティションマネージャ（PM) の公開鍵証明書（C e r t . PM) は、パ —テイシヨンマネージャ（PM) からの発行要求により、登録局（RA) を介した証明書発行手続きによってパーティション対応認証局（CA (PAR))から発行される。なお、本構成は、パーティションマネージャがサービス許可チケット発行手段（S P T Issuer) を兼ねる構成であり、サービス許可チケット発行手段 ( S P T Issuer)の公開鍵証明書としてパーティションマネージャ（PM)の公開鍵証明書を使用する構成である。

( 2 ) サービス許可チケット（ S P T) の生成処理

サービス許可チケット（S PT) は、パーティションマネージャの管理するサ —ビス許可チケヅト発行手段（S P T Ticket Issuer) により生成される。この場合、公開鍵方式の署名生成、検証を実行するため、サービス許可チケット発行手段（S P T Ticket Issuer) の秘密鍵による署名（Signature)が生成（図 1 2参照）されて S P Tに付加される。

( 3 ) S P Tおよびサービス許可チケット発行手段（ S P T Ticket Issuer) としてのパーティションマネージャ公開鍵証明書（Ce r t . PM) のサービス許可チケットユーザ（S P T User)であるデバイスアクセス機器としてのリーダライタ（R/W) に対する供給

パーティションマネージャの管理するサービス許可チケット発行手段（S P T Ticket Issuer) により発行されたサービス許可チケット（S P T) は、サービス許可チケヅト発行手段（S P T Ticket Issuer) としてのパ一ティションマネ一ジャ公開鍵証明書（C e r t . PM) とともにサービス許可チケットュ一ザ（S PT User) すなわち、デパイスに対してチケットを送信する機器（ex. デパイスアクセス機器としてのリ一ダライタ）に対して送信される。

( 4 ) デバイスアクセス機器としてのリーダライタ（R/W) とデバイス間の相互認証

サービス許可チケットュ一ザ（S P T User)であるデバイスアクセス機器としてのリ一ダライタは、サービス許可チケット発行手段（S PT Ticket Issuer) の発行したサービス許可チケット（S PT) に従ったファイルアクセスを実行しようとする対象のデバイスとの間で、共通鍵方式の相互認証（図 53、図 54参照）を実行する。

(5) S P Tおよびサービス許可チケット発行手段（S PT Ticket Issuer) としてのパーティションマネージャ公開鍵証明書（C e r t . PM) のデバイスに対する供給

リーダライタ（R/W) とデバイス間の相互認証が成立すると、サービス許可チケットュ一ザ（S PT User)であるデバイスアクセス機器としてのリーダライ夕は、デパイスに対してサービス許可チケット（S PT)、およびサービス許可チケット発行手段（S P T Ticket Issuer) としてのパーティションマネージャ公閧鍵証明書（C e r t . PM) を送信する。

デバイスは、受信したサービス許可チケット（S PT) について、（ 1 ) チケット発行者（Ticket Issuer) としてのパーテイションマネージャ公開鍵証明書（ C e r t . PM) が改竄されたものでない正当な公開鍵証明書（CERT) であること、（2) チケット発行者（Ticket Issuer) としてのパーティションマネ一ジャ公閧鍵証明書（C e r t . PM) のオプション領域に記録されたコードと、デパイス内の FDB (File Definition Block) に記録されたチケット発行手段コ一ド（SPTIC) の一致、（3) チケット発行手段（Ticket Issuer) がリポークされていないこと、（4) 受信チケット（S PT) の署名（Signature) の検証によりチケットが改竄のないことの確認を実行し、さらに、 S P Tチケットに格納された S PTユーザ（チケットュ一ザとしてのリーダライタ）とチケットユーザ（S P T User)の識別子の一致を確認し、相互認証済みであることを確認することにより S PTユーザ（リーダライタ）の検証（図 5 7、図 58参照）を実行する。

(6) ファイルアクセス

以上の処理によって、相互認証（共通鍵）、チケット（S P T) 検証（公開鍵）の各方式に従ったファイルアクセス処理が実行される。

[B 5. デ一夕アップデートチケット（DUT) を利用したデバイスのデ一夕更新処理]

次に、データアップデートチケット（D U T ： Data Update Ticket) を利用したデバイスのデータ更新処理について説明する。デ一夕アップデ一トチケット（D UT ： Data Update Ticket) は、デバイスに格納された様々なデータの更新処理を実行する際に適用されるアクセスコントロールチケットである。正当なデータアップデ一トチケット（DUT) 発行手段（Ticket Issuer) の発行した DUTを用い、 DUTに記録された手続きに従ってチケットユーザ（ex. デバイスァクセス機器としてのリーダライタ）によりデバイスにアクセスすることで、 DUT に記録された制限内でデータ処理を実行することができる。

なお、前述したように、データアップデートチケット（DUT : Data Update Ticket) は、デバイスマネージャの管理するデータ項目の更新処理を実行するために適用されるチケット D UT (D E V) と、パーティションマネージャの管理するパーティション内のデータ項目の更新処理を実行するために適用されるチケット DUT (PAR) (図 32参照）がある。

デバイスに格納したデ一夕にデータアップデートチケット（DUT) を適用してデータ更新を実行する処理について説明する。図 93以下のフロー他の図面を参照して説明する。なお、データ更新処理には、デバイスとデータ更新を実行するデバイスアクセス機器としてのリ一ダライタ間における相互認証処理（デバイス認証またはパーティション認証）、データアップデ一トチケット（DUT： Data Update Ticket) の正当性検証処理が含まれる。

図 93に示すデータ更新処理フローについて説明する。図 93において、左側がデータ更新装置、右側がデバイス（図 5参照）の処理を示す。なお、データ更新装置は、デバイスに対するデータ読み取り書き込み処理可能な装置（e x . デバイスアクセス機器としてのリーダライタ、 P C ) であり、図 1 0のデバイスァクセス機器としてのリーダライタに相当する。まず、図 9 3を用いて、デ一タ更新処理の概要を説明し、その後、当処理に含まれるデータ更新操作の詳細を図 9 4のフ口一を用いて説明する。

まず、図 9 3のステップ S 9 5 1 と S 9 6 0において、データ更新装置とデバイス間にでの相互認証処理が実行される。データ送受信を実行する 2つの手段間では、相互に相手が正しいデータ通信者であるか否かを確認して、その後に必要なデータ転送を行なうことが行われる。相手が正しいデータ通信者であるか否かの確認処理が相互認証処理である。相互認証処理時にセッション鍵の生成を実行して、生成したセッション鍵を共有鍵として暗号化処理を実行してデータ送信を行なう。

相互認証処理については、先のパーティション生成、削除処理の欄で説明したと同様の処理であり、デバイス認証またはパーティション認証のいずれかが実行される。それそれについて共通鍵方式認証、あるいは公開鍵方式認証処理のいずれかが適用される。この相互認証処理は、前述の図 4 8〜図 5 6を用いて説明したと同様の処理であるので説明を省略する。

なお、相互認証処理として実行すべき処理は、適用するデータアップデートチケット（D U T ) (図 3 2参照）の

によって決定される。

認証処理に失敗した場合（ S 9 5 2 , S 9 6 1で N o ) は、相互が正当な機器、デバイスであることの確認がとれないことを示し、以下の処理は実行されずエラ —として処理は終了する。

認証処理に成功すると、データ更新装置は、デバイスに対してデータアップデ —トチケット（D U T ： Data Update Ticket) を送信する。データアップデートチケット（D U T ) は、デバイスマネージャまたはパーティションマネージャの管理下のデータアップデ一トチケット（DUT) 発行手段（DUT Issuer) により発行されるチケットである。デ一夕アップデ一トチケット（DUT) は、デバイスに対するアクセス制御チケットであり、先に説明した図 32のデータフォーマット構成を持つチケットである。

なお、データアップデートチケット（DUT) を、チケットユーザに対して送信する際には、公開鍵方式の場合、デ一夕アップデートチケット（DUT) 発行手段（DUT Issuer) の公開鍵証明書（CERT_DUTI) も一緒に送信する。 DUT発行手段の公開鍵証明書（CERT_DUTI) の属性（Attribute) は、デバイス内の DKD B (PUB) (Device Key Definition Block)に記録されたチケット発行手段コ一ド（DUTIC— DEV) や PKD B (PUB) (Partition Key Definition Block)に記録されたチケット発行手段コード（DUTIC— PAR) の識別子（DUTIC)と一致する。デ一夕アップデートチケット（D U T) を受信（ S 96 2 ) したデバイスは、受信したチケット（DUT) の正当性と利用者チヱック処理を実行（S 96 3 ) する。チケットの正当性の検証処理は、共通鍵方式による MA C検証、あるいは公開鍵方式による署名検証処理のいずれかを適用して実行される。利用者チエツクは、チケヅトを送信してきた機器（チケット利用者）の正当性をチェックする処理であり、相互認証が成立済みであり、認証相手の識別デ一夕と、チケットに記録されているチケットユーザ識別子（図 3 2参照）との一致等を検証する処理として実行される。これらの処理は、先のパ一ティション登録チケット（P RT) の適用処理についての説明中、図 57〜図 5 9を用いて説明したと同様の処理であるので説明を省略する。

デバイスにおいて、受信チケット（DUT) の正当性と利用者チェック処理の結果、チケヅトおよび利用者の正当なことが確認できなかった場合（S 964で No) は、デ一夕アップデートチケット（DUT) 受理エラーをデ一夕更新装置に通知（S 968 ) する。チケットおよび利用者の正当なことが確認できた場合 ( S 964で Y e s ) は、受信したデータアツプデ一トチケット（ D U T ) に記述されたルールに従いデバイス内のメモリ部に格納されたデ一夕（図 33参照）の更新処理を実行する。この処理の詳細については、別フローを用いて後段で詳述する。データアップデートチケット（DUT) の記述に従って、データの更新処理に成功（ S 966で Y e s ) すると、 D U T受理成功をデータ更新装置に通知（ S 967 ) する。一方、データの更新処理に失敗（S 96 6で No) した場合は、 DUT受理エラ一をデータ更新装置に通知（S 968 ) する。

データ更新装置は、 DUT受理結果を受信（S 954 ) し、 DUT処理結果を判定し、 D UT受理結果がエラ一である場合（S 955で No) は、エラ一として処理を終了し、 DUT受理結果が成功（S 9 55で Ye s) である場合はセッシヨンクリアコマンドの送受信（S 9 5 6, S 969 ) を実行し、デバイス側に生成した認証テーブルを破棄（S 97 0 ) し、処理を終了する。認証テーブルは、ステップ S 95 1，S 9 6 0の相互認証処理において生成されるテ一ブルであり、前述したパーティション登録チケット（PRT) の適用処理の項目において説明した構成、すなわち、図 5 1の構成と同様のものである。

このようにデータアップデートチケット（DUT) を利用して、デバイス内に格納されたデータの更新処理が実行される。以下、当処理に含まれるデータ更新操作（ S 965 ) について、図 94を用いて説明する。

図 94の処理フローは、デ一夕アップデートチケット（DUT) を受理したデパイスにおいて実行される処理であり、データアップデートチケット（DUT) を送信してきた機器との相互認証が成立し、チケットの検証にも成功した以後に実行される。

まず、ステップ S 97 1において、デバイスは、デ一夕アップデートチケット (DUT) の更新される古いデ一夕のコード（OldDataCode) から更新対象デ一タのバ一ジョンを検索する。バージョンは、例えば更新対象がデバイスマネージヤコ一ド（DMC) であれば、デバイス管理情報ブロック（図 1 5参照）にパ一ジョンが記録され、また、パーティションマネ一ジヤコ一ド（PMC)であれば、パーティション管理情報プロック（図 20参照）にパ一ジョンが記録されている。また、パーティション登録チケヅト（PRT) 発行手段（PRT Issuer) のバ一ジョンはデバイス定義ブロック（図 1 6参照）に含まれる。さらに、リポケ一シヨンリスト（ I RL D E V, C R L DEV)などは、リポケ一シヨンリスト中にバ一ジョン情報が含まれる。このように情報に応じてバ一ジョン情報の格納先が決まっており、デバイスは、更新される古いデータのコード（OldDataCode) から更新対象データのパージヨンを検索する。

次に、デパイスは、ステップ S 972において、データアップデートチケット (D U T) に記録されたデータ更新をする時のパ一ジョン条件 [Data Version Rule] を参照し、設定が [Any] であるか否かを判定する。

前述したように、データ更新をする時のバ一ジョン条件 [Data Version Rule] は、 Any, Exact, Olderの 3種類が存在する。 Anyはバージョン（Version) 条件に無関係でデータ更新が可能、 Exact は、続く [Data Version Condition] に指定された値と同じ場合にデータ更新が可能、 Olderは、 New Data Versionの方が新しい場合にのみデータ更新が可能となる。なお、バ一ジョン条件 [Data Version Rule] が Any，または Olderの場合は、 [Data Version Condition] は使用しないかもしくは無視する。

データァヅプデートチケット（DUT) の [Data Version Rule] の設定が [A n y ] でない場合は、バ一ジョン条件 [Data Version Rule] に従った処理を実行する。このステップが S 973〜S 9 75である。

ステップ S 973では、デ一夕アップデートチケット（DUT) のバージョン条件 [Data Version Rule] を参照し、設定が [EXACT] であるか否かを判定する。 [EXACT] は、 [Data Version Condition] に指定された値と同じ場合にデータ更新が可能なことを示す。設定が [EXACT] である場合、ステップ S 974で、更新対象データ [01 d D a t a] のバ一ジョンがデ一夕アップデートチケット（DUT) の [Data Version Condition] に記録されたバ一ジョン値と一致するか否かを判定する。一致する場合にのみ次ステップに進み、一致しない場合は、更新処理を実行せずエラー終了とする。

ステップ S 9 73で、データアップデ一トチケット（DUT) のパ一ジョン条件 [Data Version Rule]力⁵ [ E X A C T ] でないと判定された場合は、設定は [0 l d e r]である。 [O l d e r]の設定は、更新対象データ [O l d D a t a] のパ一ジョンより、データアップデートチケット（DUT) の新規デ一夕 [New Data] のバ一ジョンを示す [New Data Version] の方が新しい場合にのみ更新をする設定である。この [01 d e r ] の設定の場合、ステップ S 97 5において、更新対象データ [O l d D a t a] のバージョンより、データアップデ一トチケット（DUT)の新規データ [New Data]のバ一ジョンを示す [New Data Version] の方が新しいか否かを判定し、新しい場合にのみ次ステップに進み、一致しない場合は、更新処理を実行せずエラー終了とする。

次にデバイスは、ステップ S 9 7 6において、データアツプデートチケット（D UT) の [Encrypted Flag] を検証する。 [Encrypted Flag] は、更新されるデ一夕が暗号化されているか否か（暗号化： Encrypted /非暗号化： none)を示すデータである。 [Encrypted Flag]が更新対象データが非暗号化データであることを示している場合は、ステップ S 977において、デ一夕アップデートチケット（DU T) の新規デ一夕 [New Data] をデバイスのメモリ部に格納された更新対象旧デ —タ [Old Data] に置き換える処理を実行し、処理終了とする。なお、更新対象データに対してバ一ジョンが付加されている場合は、データアップデートチケット（D U T ： Data Update Ticket) に格納されている更新するデータのバ一ジョン（New Data Version) を、デパイス内の更新データに対応して設定されているバ一ジョン格納領域に格納する処理を実行する。

また、ステップ S 976において、データアツプデートチケット（DUT) の [Encrypted Flag]が、更新されるデータが暗号化されている（暗号化： Encrypted) ことを示していると判定された場合は、ステップ S 978において、データアツプデートチケット（DUT) の [Ticket Type] を検証する。 [Ticket Type] は、チケット（Ticket) の種別（DUT (D E V) /D U T (PAR)) を示すデ一夕である。 D U T ( D E V ) は、データアップデートチケット（ D U T ) が、デパイスマネージャの管理するデ一夕項目の更新処理を実行するチケットあることを示し、 DUT (PAR) は、パーティションマネージャの管理するパーティション内のデータ項目の更新処理を実行するために適用されるチケットであることを示してる。

チケットタイプ [Ticket Type] が、 DUT (D E V) を示している場合、ステップ S 97 9 ~ S 982を実行し、 DUT (PAR) を示している場合、ステツプ S 983〜S 986を実行する。

チケットタイプ [Ticket Type] が、 DUT (D E V) を示している場合、ステヅプ S 979において、データアップデートチケット（DUT (D E V)) に記述された Old Data Code (更新される古いデータのコード）の示すデータがデバィス鍵領域（図 1 8参照）に格納された Kdut_DEVl (データアップデートチケット (DUT) の MAC検証用鍵）または、 Kdut— DEV2 (デ一夕更新用暗号鍵）であるか否かを判定する。

データアップデートチケット（DUT (D E V)) に記述された Old Data Code (更新される古いデ一夕のコード）の示すデータがデバイス鍵領域（図 1 8参照）に格納された Kdut_DEVl (デ一夕アップデートチケット（DUT) の MAC検証用鍵）、 Kdut一 DEV2 (データ更新用暗号鍵）である場合は、ステップ S 980において、デバイスのデバイス鍵領域（図 1 8参照）に格納された Kdut_DEV4 (デ一夕更新用暗号鍵）を用いて、データァヅプデ一トチケット（DUT (D E V)) に格納された新規デ一夕 [New Data] としての Kdut_DEVl、 Kdut_DEV2を復号し、デバイスのデバイス鍵領域に格納された Kdut_DEVl、 Kdut_DEV2に上書きする。なお、デ一夕アップデートチケット（DUT (DEV)) に格納されている更新するデ一夕のパ一ジョン（New Data Version) を、デバイス内の更新デ一夕に対応して設定されているバ一ジョン格納領域、この場合は、デバイスのデバイス鍵領域（図 1 8参照）に格納する処理を併せて実行する。

次に、ステップ S 98 1において、デバイスのデバイス鍵領域（図 1 8参照）に格納された Kdut— DEVI (データアップデートチケット（DUT) の MAC検証用鍵）と、 Kdut— DEV3 (データアップデ一トチケット（DUT)の MAC検証用鍵）とのスワップ、すなわち入れ替え処理を行ない、また、 Kdut_DEV2 (データ更新用暗号鍵）と、 Kdut_DEV4 (データ更新用暗号鍵）とのスワップ、すなわち入れ替え処理を行なって処理を終了する。

なお、 Kdut_DEVlと、 Kdut_DEV3とのスワップ、および、 Kdut_DEV2と、 Kdut_DEV4 とのスワップ処理によって、常に Kdut_DEV3 (データアップデートチケット（D UT)の MAC検証用鍵）、 Kdut_DEV4 (データ更新用暗号鍵）のペアが Kdut_DEVl (データアップデートチケット（DUT) の MAC検証用鍵）、 Kdut_DEV2 (デ一夕更新用暗号鍵）のペアよりも新しいバージョンのものに維持され、書き換え対象を、常に Kdut DEV1、 Kdut_DEV2として設定した処理が可能となる。なお、ステップ S 97 9において、デ一夕アツプデートチケット（DUT (D E V)) に記述された Old Data Code (更新される古いデ一夕のコード）の示すデ —夕がデバイス鍵領域（図 18参照）に格納された Kdut_DEVl (データアップデ —トチケット（D U T) の MA C検証用鍵）、 Kdut_DEV2 (データ更新用暗号鍵）でない場合は、ステップ S 982において、デパイスのデバイス鍵領域（図 1 8 参照）に格納された Kdut_DEV2 (データ更新用暗号鍵）を用いて、デ一夕アップデートチケット（DUT (DEV)) に格納された新規データ [New Data] を復号し、データァップデートチケット（D U T (D E V)) の Old Data code (更新される古いデータのコード）の示すエリアに上書きする。なお、更新対象デ一夕に対してバ一ジョンが付加されている場合は、データアップデートチケット（DU T (D E V)) に格納されている更新するデータのバージョン（New Data Version) を、デバイス内の更新デ一夕に対応して設定されているパージョン格納領域に格納する処理を実行する。

一方、ステップ S 978において、チケットタイプ [Ticket Type] が、 DUT (PAR) を示している場合、ステップ S 983〜 S 986を実行する。

チケヅトタイプ [Ticket Type] が、 DUT (PAR) を示している場合、ステヅプ S 983において、データアップデートチケット（DUT (PAR)) に記述された Old Data Code (更新される古いデータのコード）の示すデータがパーテイシヨン鍵領域（図 23参照）に格納された Kdut_PARl (データアップデートチケット（DUT) の MAC検証用鍵）または、 Kdut_PAR2 (データ更新用暗号鍵）であるか否かを判定する。

デ一夕アップデートチケット（DUT (PAR)) に記述された Old Data Code (更新される古いデータのコード）の示すデ一夕がパーティション鍵領域（図 2 3参照）に格納された Kdut_PARl (データアップデートチケット（DUT) の M AC検証用鍵）、 Kdut_PAR2 (データ更新用暗号鍵）である場合は、ステップ S 9 84において、デバイスのパーティション鍵領域（図 2 3参照）に格納された Kdut_PAR4 (デ一夕更新用暗号鍵）を用いて、データアップデ一トチケット（DU T (PAR))に格納された新規データ [New Data]としての Kdut_PARl、 Kdut_PAR2 を復号し、デバイスのパーティション鍵領域に格納された Kdut PARK dut_PAR2 に上書きする。なお、データアップデ一トチケット（DUT (PAR)) に格納されている更新するデータのバ一ジョン（New Data Version) を、デバイス内の更新データに対応して設定されているバージョン格納領域、この場合は、デバイスのパーティシヨン鍵領域（図 23参照）に格納する処理を併せて実行する。

次に、ステップ S 985において、デバイスのパーティション鍵領域（図 2 3 参照）に格納された Kdut_PARl (データアップデートチケット（DUT) の MA C検証用鍵）と、 Kdut_PAR3 (データアップデ一トチケット（DUT) の MAC検証用鍵）とのスワップ、すなわち入れ替え処理を行ない、また、 Kdut_PAR2 (デ一夕更新用暗号鍵）と、 Kdut_PAR4 (データ更新用暗号鍵）とのスワップ、すなわち入れ替え処理を行なって処理を終了する。

なお、 Kdut_PARl と、 Kdut_PAR3とのスワップ、および、 Kdut_PARV2と、 Kdut— PAR4とのスヮップ処理によって、常に Kdut_PAR3 (データアップデ一トチケット (D UT) の MA C検証用鍵）、 Kdut_PAR4 (データ更新用暗号鍵）のペアが Kdut_PARl (データアップデートチケット（DUT)の MAC検証用鍵）、 Kdut_PAR2 (データ更新用暗号鍵）のペアよりも新しいバ一ジョンのものに維持され、書き換え対象を、常に Kdut_PARl、 Kdut_PAR2として設定した処理が可能となる。なお、ステップ S 983において、デ一夕アップデートチケット（DUT (P AR)) に記述された Old Data Code (更新される古いデータのコード）の示すデ —夕がデバイス鍵領域（図 1 8参照）に格納された Kdut_DEVl (デ一夕アップデ —トチケット（DUT) の MAC検証用鍵）、 Kdut— DEV2 (データ更新用暗号鍵）でない場合は、ステップ S 986において、デバイスのパ一テイション鍵領域（図 23参照）に格納された Kdut_PAR2 (データ更新用暗号鍵）を用いて、データァヅプデートチケット（DUT (PAR)) に格納された新規データ [New Data] を復号し、データアップデ一トチケット（DUT (PAR)) の Old Data Code (更新される古いデータのコード）の示すエリアに上書きする。なお、更新対象デ一タに対してパージョンが付加されている場合は、データアップデートチケヅト（D UT(P AR))に格納されている更新するデータのバ一ジョン（New Data Version) を、デパイス内の更新データに対応して設定されているパージョン格納領域に格納する処理を実行する。以上の処理がデバイスにおいて実行されるデ一タフップデ一トチケットに基づくデータ更新操作である。

上述したフローから理解されるように、更新対象データがデバイス鍵領域に格納された

Kdut_DEVl (データアップデートチケット（DUT) の MAC検証用鍵） Kdut_DEV2 (データ更新用暗号鍵）

または、パーティション鍵領域に格納された

Kdut— PARI (データアップデートチケット（DUT) の MAC検証用鍵） Kdut_PAR2 (データ更新用暗号鍵）

である場合には、他の更新処理と異なる処理を実行する。

これらの Kdut_DEVl (データアップデ一トチケット（DUT) の MAC検証用鍵）、 Kdut_DEV2 (デ一夕更新用暗号鍵）、 Kdut_PARl (データアップデートチケット（DUT) の MAC検証用鍵）、 Kdut_PAR2 (データ更新用暗号鍵）についての更新処理を簡潔にまとめた図を図 95に示し、処理について説明する。図 9 5の ( 1 ) ~ (3 ) の順に説明する。なお、処理は、 Kdut_DEVl,2 と、 Kdut— PARI, 2 とで同様のものであるので、 Kdut_DEVl，2を更新する場合について説明する。

( 1 )データアップデ一卜チケット（DUT)に格納する新規データ [New Data] としての Kdut_DEVl、 Kdut_DEV2をデバイスのデバイス鍵領域（図 1 8参照）に格納された Kdut_DEV4 (データ更新用暗号鍵）を用いて暗号化した後、データアツプデートチケット（DUT) に格納し、データアップデートチケット（DUT) をデバイスに送信する。このとき、 Kdut_DEVl、 Kdut_DEV2を更新できるチケット発行者は Kdut_DEV3、 Kdut_DEV を知らなくてはならない。

( 2 ) デ一夕アップデートチケット（DUT) を受信したデバイスは、デパイスのデバイス鍵領域に格納された KdutJ)EV4 (データ更新用暗号鍵）を用いて、データアップデートチケット（DUT) の格納新規データ [New Data] としての Kdut_DEVl、 Kdut_DEV2 を復号し、デバイスのデバイス鍵領域に格納された Kdut_DEVl、 Kdut_DEV2に上書きする。

(3) 次に、デバイスは、デバイスのデバイス鍵領域（図 1 8参照）に新規に格納された Kdut DEVI (データアップデートチケット（DUT) の MAC検証用鍵）と、以前に格納済みの Kdut_DEV3 (データアップデートチケット（D U T ) の M A C検証用鍵）とのスワップ、すなわち入れ替え処理を行なう。さらに、新規に格納された Kdut_DEV2(データ更新用暗号鍵）と、以前に格納済みの Kdut_DEV4

(デ一夕更新用暗号鍵）とのスワップ、すなわち入れ替え処理を行なう。

この、 Kdut—DEVI と、 Kdut_DEV3 とのスワップ、および、 Kdut_DEV2と、 Kdut_DEV4 とのスワップ処理によって、常に Kdut_DEV3 (データアップデートチケット（D U T ) の M A C検証用鍵）、 Kdut_DEV4 (データ更新用暗号鍵）のペアが Kdut_DEVl

(デ一夕アップデートチケット（D U T ) の M A C検証用鍵）、 Kdut_DEV2 (デ一夕更新用暗号鍵）のペアよりも新しいバージョンのものに維持される。つまり、 Kdut_DEVl と、 Kdut— DEV2の鍵は常に使用される鍵で、 Kdut—DEV3 と、 Kdut_DEV4 は、非常時に Kdut_DEVl と、 Kdut— DEV2 を更新するとともに、現在使用されている Kdut_DEVl と、 Kdut_DEV2 の鍵に置き換えられるバックアップ用の鍵としての役割がある。

なお、 Kdut— DEVI (データアップデ一トチケット（D U T ) の M A C検証用鍵）、 Kdut_DEV2 (データ更新用暗号鍵）はペアとして使用され、また、 Kdut_DEV3 (デ —夕アップデートチケット（D U T ) の M A C検証用鍵）、 Kdut_DEV4 (データ更新用暗号鍵）もペアとして使用される。

以上、特定の実施例を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本発明の要旨を判断するためには、冒頭に記載した特許請求の範囲の欄を参酌すべきである。

なお、明細書中において説明した一連の処理はハードウェア、またはソフトゥエア、あるいは両者の複合構成によって実行することが可能である。ソフトゥェァによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれたコンピュータ内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをィンストールして実行させることが可能である。

例えば、プログラムは記録媒体としてのハードディスクや R O M ( Read Onl y Memory)に予め記録しておくことができる。あるいは、プログラムはフロッピ一デイスク、 C D - R 0 M (Compact Disc Read Only Memory) , M 0 (Magneto optical ) ディスク， D V D (Digital Versati le Di sc ), 磁気ディスク、半導体メモリなどのリム一バブル記録媒体に、一時的あるいは永続的に格納（記録）しておくことができる。このようなリム一バブル記録媒体は、いわゆるパッケージソフトゥェァとして提供することができる。

なお、プログラムは、上述したようなリム一バブル記録媒体からコンピュータにインスト一ルする他、ダウン口一ドサイトから、コンピュータに無線転送したり、 L A N (Local Area Network )、インタ一ネットといったネットワークを介して、コンピュータに有線で転送し、コンピュータでは、そのようにして転送されてくるプログラムを受信し、内蔵するハ一ドディスク等の記録媒体にィンストールすることができる。

なお、明細書に記載された各種の処理は、記載に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。また、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。産業上の利用可能性

上述したように、本発明のメモリアクセス制御システム、デバイス管理装置、パーティション管理装置、メモリ搭載デバイス、およびメモリアクセス制御方法、並びにプログラム記憶媒体によれば、複数のパーティションに分割されたメモリ領域のアクセスに対して、様々な種類のアクセス制御チケットを各デバイスまたはパーティション管理ェンティティの管理の下に発行し、各チケットに記述されたルールに基づく処理をメモリ搭載デバイスにおいて実行する構成が可能となり、各パーティション内データの独立した管理構成が実現される。

さらに、本発明のメモリアクセス制御システム、デバイス管理装置、パーティシヨン管理装置、メモリ搭載デバイス、およびメモリアクセス制御方法、並びにプログラム記憶媒体によれば、パーティション対応の認証、デバイス対象の認証を公開鍵、共通鍵のいずれか指定方式に従って実行することが可能なデバイスとし、様々な環境下においてデバイスおよびアクセス装置間のセキュアなデータ通信が実行可能となる。

さらに、本発明のメモリアクセス制御システム、デバイス管理装置、パーティシヨン管理装置、メモリ搭載デバイス、およびメモリアクセス制御方法、並びにプログラム記憶媒体によれば、メモリ搭載デバイスのメモリ部は、デ一タフアイルを格納し、パ一ティションマネージャによって管理されるメモリ領域としての 1以上のパーテイション領域と、該メモリ搭載デバイスの管理者としてのデバイスマネージャによって管理されるデバイスマネ一ジャ管理領域とを有し、メモリ部に対するアクセス制御チケヅトとして、デバイスマネージャの管理するァクセス制御チケット、またはパ一ティションマネージャの管理するアクセス制御チケットをアクセス機器から受領し、受領チケットの記述に応じて処理を実行する構成とし、実行すべき相互認証態様、アクセス制御チケットの検証態様を指定し、各態様に従って処理を可能としたので様々な環境下においてデバイスおよびァクセス装置間のセキュアなデ一夕通信が実行可能となる。

さらに、本発明のメモリアクセス制御システム、デパイス管理装置、パーティシヨン管理装置、メモリ搭載デバイス、およびメモリアクセス制御方法、並びにプログラム記憶媒体によれば、デバイスマネージャ、パーティションマネージャの管理の下、パーティション登録チケット（P R T )、ファイル登録チケット、サ —ビス許可チケット（ S P T )、デ一夕アップデ一トチケット（D U T ) を発行し、それそれ認証、チケット検証の成立を条件としてデバイスでの処理を実行する構成としたので、様々な処理態様に応じたサービスの提供、データ管理が各サ一ビス主体の管理の下に実行可能となる。

Claims

請求の範囲

1 . データファイルを格納したメモリ部を有するメモリ搭載デバイスに対するメモリアクセス制御システムであり

前記メモリ搭載デバイスのメモリ部は、

前記メモリ搭載デバイスは、

前記メモリ部に対するアクセス制御チケットとして、前記デバイスマネージャの管理するアクセス制御チケット、または前記パーティシヨンマネージャの管理するアクセス制御チケットをアクセス機器から受領し、受領チケットの記述に応じて処理を実行する構成を有することを特徴とするメモリアクセス制御システム

2 . 前記アクセス制御チケットは、

前記メモリ搭載デバイスとチケットを出力したアクセス機器間において実行すべき相互認証態様を指定した相互認証指定データを含み、

前記メモリ搭載デバイスは、

該アクセス制御チケットの相互認証指定データに応じた相互認証を実行し、認証の成立を条件として受領チケットの記録に応じた処理を実行する構成を有することを特徴とする請求項 1に記載のメモリアクセス制御システム。

3 . 前記アクセス制御チケットは、

前記メモリ搭載デバイスの受領したアクセス制御チケッ卜の検証態様を指定したチケット検証指定データを含み、

前記メモリ搭載デバイスは、

該アクセス制御チケットのチケット検証指定データに応じたチケット検証処理を実行し、検証の成立を条件として受領チケットの記録に応じた処理を実行する構成を有することを特徴とする請求項 1に記載のメモリアクセス制御システム。

4 . 前記アクセス制御チケットは、

該アクセス制御チケットの発行手段のカテゴリまたは識別子を含み、前記メモリ搭載デバイスは、

アクセス機器から受領したアクセス制御チケットに記述された該アクセス制御チケットの発行手段のカテゴリまたは識別子に基づいて、チケットが正当な発行手段により発行されたチケットであることの確認処理を実行し、該確認を条件として受領チケットの記録に応じた処理を実行する構成を有することを特徴とする請求項 1に記載のメモリアクセス制御システム。

5 . 前記アクセス制御チケットは、

該アクセス制御チケットの利用手段であるアクセス機器のカテゴリまたは識別子を含み、

前記メモリ搭載デバイスは、

アクセス機器から受領したアクセス制御チケットに記述された該アクセス制御チケットの利用手段であるアクセス機器のカテゴリまたは識別子に基づいて、チケットが正当な利用手段により提供されたチケットであることの確認処理を実行し、該確認を条件として受領チケットの記録に応じた処理を実行する構成を有することを特徴とする請求項 1に記載のメモリアクセス制御システム。

6 . 前記デバイスマネージャの管理するアクセス制御チケヅトには、

前記メモリ搭載デバイスのメモリ部に対するパーティションの生成処理または削除処理を許容するパーティション登録チケット（P R T ) を含み、

前記メモリ搭載デバイスは、

前記アクセス機器からパーティション登録チケット（P R T ) を受領した場合は、

受領パーティション登録チケット（P R T ) の記録に従ったパーティションの生成処理または削除処理を実行することを特徴とする請求項 1に記載のメモリァクセス制御システム。

7. 前記パーティション登録チケット（PRT) は、前記デバイスマネージャの管理するチケット発行手段から前記パーティションマネージャの管理するチケットユーザとしてのアクセス機器に対して発行される構成であることを特徴とする請求項 6に記載のメモリアクセス制御システム。

8. 前記パ一ティションマネージャの管理するアクセス制御チケットには、前記メモリ搭載デバイスのメモリ部内に生成されたパーティシヨン内に対するデータファイルの生成処理または削除処理を許容するファイル登録チケット（F

RT) を含み、

前記メモリ搭載デパイスは、

前記アクセス機器からファイル登録チケット（FRT) を受領した場合は、受領ファイル登録チケット（FRT) の記録に従ったファイルの生成処理または削除処理を実行することを特徴とする請求項 1に記載のメモリアクセス制御システム。

9. 前記ファイル登録チケット（FRT) は、前記パーティションマネージャの管理するチケット発行手段から前記パーティションマネージャの管理するチケットュ一ザとしてのアクセス機器に対して発行される構成であることを特徴とする請求項 8に記載のメモリアクセス制御システム。

1 0. 前記パーティションマネージャの管理するアクセス制御チケットには、前記メモリ搭載デバイスのメモリ部内のパーティション内のデータファイルに対するアクセスを許容するサービス許可チケット（S PT) を含み、

前記メモリ搭載デバイスは、

前記アクセス機器からサービス許可チケット（S PT) を受領した場合は、受領サービス許可チケット（S PT) の記録に従ったデータファイルに対するアクセス処理を実行することを特徴とする請求項 1に記載のメモリアクセス制御システム。

1 1. 前記サービス許可チケット（S PT) は、前記パーティションマネージャの管理するチケヅト発行手段から前記パーティションマネージャの管理するチケットュ一ザとしてのアクセス機器に対して発行される構成であることを特徴とする請求項 1 0に記載のメモリアクセス制御システム。

1 2. 前記デバイスマネージャまたは前記パーティションマネージャの管理するアクセス制御チケットには、

前記メモリ搭載デバイスのメモリ部内の格納データの更新処理を許容するデ一夕アップデートチケット（DUT) を含み、

前記メモリ搭載デバイスは、

前記アクセス機器からデ一夕アップデートチケット（DUT) を受領した場合は、

受領データアップデートチケット（DUT) の記録に従ったデータ更新処理を実行することを特徴とする請求項 1に記載のメモリアクセス制御システム。

1 3. 前記デパイスマネージャの管理するデバイスマネージャ管理領域のデ一夕更新用のデータアップデートチケット（DUT) は、前記デバイスマネージャの管理するチケット発行手段から前記デバイスマネージャの管理するチケットュ

—ザとしてのアクセス機器に対して発行され、

前記パーティションマネージャの管理するパーティション領域のデータ更新用のデータアップデートチケヅト（DUT) は、前記パ一ティシヨンマネージャの管理するチケット発行手段から前記パーティションマネージャの管理するチケットユーザとしてのアクセス機器に対して発行される構成であることを特徴とする請求項 12に記載のメモリアクセス制御システム。

14. データファイルを格納し、パーティション管理装置によって管理されるメモリ領域としての 1以上のパーティシヨン領域と、デバイス管理装置によって管理されるデバイスマネージャ管理領域とを有するメモリ搭載デバイスのデバイス管理を実行するデバイス管理装置であり、

前記メモリ搭載デバイスのメモリ部に対するパーティションの生成処理または削除処理を許容するメモリアクセス制御チケヅトとしてのパーティション登録チケット（PRT) 発行手段を有することを特徴とするデバイス管理装置。

1 5. 前記デバイス管理装置は、

前記メモリ搭載デバイスに対する公開鍵証明書の発行管理を実行する登録局構成を有することを特徴とする請求項 1 4に記載のデバイス管理装置。

1 6. 前記パーティション登録チケット（P RT) は、

前記メモリ搭載デバィスとチケットを出力したアクセス機器間において実行すべき相互認証態様を指定した相互認証指定データを含むことを特徴とする請求項 14に記載のデバイス管理装置。

1 7. ,前記パ一テイション登録チケット（ P R T) は、

前記メモリ搭載デバイスの受領したアクセス制御チケットの検証態様を指定したチケット検証指定データを含むことを特徴とする請求項 1 4に記載のデバイス管理装置。

1 8. 前記パーティション登録チケット（PRT) は、

該アクセス制御チケットの発行手段のカテゴリまたは識別子を含むことを特徴とする請求項 1 4に記載のデバイス管理装置。

1 9. 前記パーティション登録チケット（P RT) は、

該アクセス制御チケットの利用手段であるアクセス機器のカテゴリまたは識別子を含むことを特徴とする請求項 1 4に記載のデバイス管理装置。

20. デ一夕ファイルを格納し、パーティション管理装置によって管理されるメモリ領域としての 1以上のパーティション領域と、デバイス管理装置によって管理されるデバイスマネージャ管理領域とを有するメモリ搭載デバイスのパ一テイション管理を実行するパーティション管理装置であり、

前記メモリ搭載デバイスのメモリ部に対して生成されたパーティシヨン内に対するアクセスを許容するアクセス制御チケット発行手段を有することを特徴とするパ一テイション管理装置。

2 1 . 前記アクセス制御チケットは、

前記メモリ搭載デバイスのメモリ部内に生成されたパーティション内に対するデータファイルの生成処理または削除処理を許容するファイル登録チケット（F R T ) であることを特徴とする請求項 2 0に記載のパーティシヨン管理装置。

2 2 . 前記アクセス制御チケットは、

前記メモリ搭載デバイスのメモリ部内のパ一ティション内のデータファイルに対するアクセスを許容するサービス許可チケット（S P T ) であることを特徴とする請求項 2 0に記載のパ一テイション管理装置。

2 3 . 前記パーティション管理装置は、

前記メモリ搭載デバイスに対する公開鍵証明書の発行管理を実行する登録局構成を有することを特徴とする請求項 2 0に記載のパーティション管理装置。

2 4 . 前記アクセス制御チケットは、

前記メモリ搭載デバイスとチケットを出力したアクセス機器間において実行すべき相互認証態様を指定した相互認証指定データを含むことを特徴とする請求項 2 0に記載のパーティション管理装置。

2 5 . 前記アクセス制御チケットは、

前記メモリ搭載デバイスの受領したアクセス制御チケッ卜の検証態様を指定したチケット検証指定デ一夕を含むことを特徴とする請求項 2 0に記載のパーティション管理装置。

2 6 . 前記アクセス制御チケットは、

該アクセス制御チケッ卜の発行手段のカテゴリまたは識別子を含むことを特徴とする請求項 2 0に記載のパーティション管理装置。

2 7 . 前記アクセス制御チケットは、

該アクセス制御チケットの利用手段であるアクセス機器のカテゴリまたは識別子を含むことを特徴とする請求項 2 0に記載のパ一テイション管理装置。

2 8 . データ格納可能なメモリ部を有するメモリ搭載デバイスであり、前記メモリ搭載デバイスのメモリ部は、

パーティションマネージャによって管理されるメモリ領域としての 1以上のパ —ティション領域と、該メモリ搭載デバイスの管理者としてのデバイスマネージャによって管理されるデパイスマネージャ管理領域とを有し、

前記メモリ搭載デバイスは、

前記メモリ部に対するアクセス制御チケットとして、前記デバイスマネージャの管理するアクセス制御チケット、または前記パーティションマネージャの管理するアクセス制御チケットをアクセス機器から受領し、受領チケットの記述に応じて処理を実行する制御手段を有することを特徴とするメモリ搭載デバイス。

2 9 . 前記アクセス制御チケットは、

前記制御手段は、

該アクセス制御チケットの相互認証指定デ一夕に応じた相互認証を実行し、認証の成立を条件として受領チケットの記録に応じた処理を実行する構成を有することを特徴とする請求項 2 8に記載のメモリ搭載デバイス。

3 0 . 前記アクセス制御チケットは、

前記メモリ搭載デバイスの受領したアクセス制御チケットの検証態様を指定したチケット検証指定データを含み、

前記制御手段は、

該アクセス制御チケットのチケット検証指定データに応じたチケット検証処理を実行し、検証の成立を条件として受領チケットの記録に応じた処理を実行する構成を有することを特徴とする請求項 2 8に記載のメモリ搭載デバイス。

3 1 . 前記アクセス制御チケットは、

該アクセス制御チケットの発行手段のカテゴリまたは識別子を含み、前記制御手段は、

アクセス機器から受領したアクセス制御チケットに記述された該アクセス制御チケットの発行手段のカテゴリまたは識別子に基づいて、チケットが正当な発行手段により発行されたチケットであることの確認処理を実行し、該確認を条件として受領チケットの記録に応じた処理を実行する構成を有することを特徴とする請求項 2 8に記載のメモリ搭載デバイス。

3 2 . 前記アクセス制御チケットは、

前記制御手段は、

アクセス機器から受領したアクセス制御チケットに記述された該アクセス制御チケットの利用手段であるアクセス機器のカテゴリまたは識別子に基づいて、チケッ卜が正当な利用手段により提供されたチケットであることの確認処理を実行し、該確認を条件として受領チケットの記録に応じた処理を実行する構成を有することを特徴とする請求項 2 8に記載のメモリ搭載デバイス。

3 3 . データファイルを格納したメモリ部を有するメモリ搭載デバイスに対するメモリアクセス制御方法であり前記メモリ搭載デバイスのメモリ部は、

前記データファイルを格納し、パ一ティションマネージャによって管理されるメモリ領域としての 1以上のパーティション領域と、該メモリ搭載デバイスの管理者としてのデバイスマネージャによって管理されるデバイスマネージャ管理領域とを有し、

前記メモリ搭載デバイスは、

前記メモリ部に対するアクセス制御チケットとして、前記デバイスマネージャの管理するアクセス制御チケヅト、または前記パーティションマネージャの管理するアクセス制御チケットをアクセス機器から受領し、受領チケットの記述に応じて処理を実行することを特徴とするメモリアクセス制御方法。

3 4 . 前記アクセス制御チケットは、

前記メモリ搭載デバイスは、

該アクセス制御チケットの相互認証指定データに応じた相互認証を実行し、認証の成立を条件として受領チケットの記録に応じた処理を実行することを特徴とする請求項 3 3に記載のメモリアクセス制御方法。

3 5 . 前記アクセス制御チケットは、

前記メモリ搭載デバイスは、

該アクセス制御チケットのチケット検証指定データに応じたチケット検証処理を実行し、検証の成立を条件として受領チケットの記録に応じた処理を実行することを特徴とする請求項 3 3に記載のメモリアクセス制御方法。

3 6 . 前記アクセス制御チケットは、

該アクセス制御チケットの発行手段のカテゴリまたは識別子を含み、前記メモリ搭載デパイスは、

アクセス機器から受領したアクセス制御チケットに記述された該アクセス制御チケットの発行手段のカテゴリまたは識別子に基づいて、チケットが正当な発行手段により発行されたチケットであることの確認処理を実行し、該確認を条件として受領チケットの記録に応じた処理を実行することを特徴とする請求項 3 3に記載のメモリアクセス制御方法。

3 7 . 前記アクセス制御チケットは、

前記メモリ搭載デバイスは、

ァクセス機器から受領したアクセス制御チケットに記述された該アクセス制御チケヅトの利用手段であるアクセス機器のカテゴリまたは識別子に基づいて、チケットが正当な利用手段により提供されたチケットであることの確認処理を実行し、該確認を条件として受領チケットの記録に応じた処理を実行することを特徴とする請求項 3 3に記載のメモリアクセス制御方法。

3 8 . 前記デバイスマネージャの管理するアクセス制御チケットには、前記メモリ搭載デバイスのメモリ部に対するパーティションの生成処理または削除処理を許容するパーティション登録チケット（P R T ) を含み、

前記メモリ搭載デバイスは、

受領パーティション登録チケット（P R T ) の記録に従ったパーティションの生成処理または削除処理を実行することを特徴とする請求項 3 3に記載のメモリアクセス制御方法。

3 9 . 前記パーティション登録チケット（P R T ) は、前記デバイスマネージャの管理するチケット発行手段から前記パーティションマネージャの管理するチケットユーザとしてのアクセス機器に対して発行されることを特徴とする請求項

38に記載のメモリアクセス制御方法。

40. 前記パーティションマネージャの管理するアクセス制御チケットには、前記メモリ搭載デバイスのメモリ部内に生成されたパーティション内に対するデータファイルの生成処理または削除処理を許容するファイル登録チケット（F RT) を含み、

前記メモリ搭載デバイスは、

前記アクセス機器からファイル登録チケット（FRT) を受領した場合は、受領ファイル登録チケット（F RT) の記録に従ったファイルの生成処理または削除処理を実行することを特徴とする請求項 33に記載のメモリアクセス制御方法。

41. 前記ファイル登録チケット（ F R T) は、前記パーティションマネージャの管理するチケット発行手段から前記パーティションマネージャの管理するチケットユーザとしてのアクセス機器に対して発行される構成であることを特徴とする請求項 40に記載のメモリアクセス制御方法。

42. 前記パ一ティションマネージャの管理するアクセス制御チケットには、前記メモリ搭載デバイスのメモリ部内のパーティション内のデータファイルに対するアクセスを許容するサービス許可チケット（S PT) を含み、

前記メモリ搭載デバイスは、

前記アクセス機器からサービス許可チケット（S PT) を受領した場合は、受領サービス許可チケット（S P T) の記録に従ったデータファイルに対するアクセス処理を実行することを特徴とする請求項 33に記載のメモリアクセス制御方法。

43. 前記サービス許可チケット（S PT) は、前記パーティションマネージャの管理するチケット発行手段から前記パ一テイションマネージャの管理するチケットユーザとしてのアクセス機器に対して発行されることを特徴とする請求項 4 2に記載のメモリアクセス制御方法。

4 4 . 前記デバイスマネージャまたは前記パーティションマネージャの管理するアクセス制御チケットには、

前記メモリ搭載デバイスのメモリ部内の格納データの更新処理を許容するデータアップデートチケット（D U T ) を含み、

前記メモリ搭載デバイスは、

前記アクセス機器からデータアップデートチケット（D U T ) を受領した場合は、

受領データアップデートチケット（D U T ) の記録に従ったデータ更新処理を実行することを特徴とする請求項 3 3に記載のメモリアクセス制御方法。

4 5 . 前記デバイスマネージャの管理するデバイスマネージャ管理領域のデ一タ更新用のデ一タアップデートチケット（D U T ) は、前記デバイスマネージャの管理するチケット発行手段から前記デバイスマネージャの管理するチケットュ

—ザとしてのアクセス機器に対して発行され、

前記パ一テイシヨンマネージャの管理するパーティション領域のデータ更新用のデータアップデートチケット（D U T ) は、前記パーティションマネージャの管理するチケット発行手段から前記パーティションマネージャの管理するチケットユーザとしてのアクセス機器に対して発行されることを特徴とする請求項 3 3 に記載のメモリアクセス制御方法。

4 6 . デ一夕ファイルを格納し、パーティションマネージャによって管理されるメモリ領域としての 1以上のパーティション領域と、該メモリ搭載デバイスの管理者としてのデパイスマネージャによって管理されるデバイスマネージャ管理領域とを有するメモリ部を有するメモリ搭載デバイスに対するメモリアクセス制御処理をコンピュータ · システム上で実行せしめるコンピュータ · プログラムを提供するプログラム記憶媒体であって、前記コンピュータ . プログラムは、前記メモリ部に対するアクセス制御チケットとして、前記デバイスマネージャの管理するアクセス制御'チケット、または前記パーティションマネージャの管理するアクセス制御チケットをアクセス機器から受領するステップと、

アクセス機器との相互認証を実行するステップと、

を有することを特徴とするプログラム記憶媒体。