WO2002076013A1

WO2002076013A1 - Systeme de gestion d'acces aux donnees et procede de gestion utilisant un billet de commande d'acces

Info

Publication number: WO2002076013A1
Application number: PCT/JP2002/002113
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: US20030188117A1; KR20030005354A; EP1303075A4; JP2002278839A; KR100860162B1; HK1062971A1; CN1465160A; CN100483991C; EP1303075A1

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 ) の処理が可能である。図 96の右下の表に示すように、データ 4の減額（D e c r eme n t) の処理と、読書き（R e a d/Wr i t e ) の処理では、アクセスキーが異なり、各処理に対応したァクセスキーを使用してメモリにアクセスすることが必要となる。

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

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

相互認証に成功した後、 RZWはデータ構造、デ一夕サイズ、アクセス方法、アクセス認証鍵をセッション鍵で暗号化し、必要に応じてデータ検証用の 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の「メモリアクセス方法」に示すように、データ 4 (金額データ）の減額 (Decrement)用のアクセス認証に成功した場合は、データ 4のデータの減額は可能であっても、加算、あるいは自由な書き換え処理はできない。このように認証処理に用いるアクセス認証鍵をそれそれのアクセス態様に応じて異なる設定とすることにより各データの安全性を高めることができる。例えば減額処理用 R /W が盗難にあい、盗難にあった減額処理用 R /W内の N V R A Mが見破られた場合であっても、図 9 9のセキュアデバイス内のデータ 4 (金額データ）の不正な增加処理が行われる可能性を低減することができる。

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

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

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

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

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

特に、本発明は、アクセス機器に対して許容されるアクセスモードを設定したアクセス制御チケットとしてのサービス許可チケット（S P T ) を、各アクセス機器に応じて個別に発行することにより、各アクセス機器に応じて異なる態様のアクセスを実行可能とした構成を実現するデ一夕アクセス管理システム、メモリ搭載デバイス、およびデータアクセス管理方法、並びにプログラム記憶媒体を提供することを目的とする。

また、メモリ搭載デバイスが、アクセス機器からの指定または受領したァクセス制御チケットの記述に基づいて、アクセス機器との相互認証の方式として例えば公開鍵方式、または共通鍵方式のいずれかを決定して実行するとともに、受領したアクセス制御チケットの記述に基づいて、アクセス制御チケヅトの検証方式についても例えば公開鍵方式、または共通鍵方式のいずれかを決定して実行する構成とすることにより、様々な環境下において、また様々なアクセス制御チケットの態様に対して、デバイスおよびアクセス装置間のセキュアなデータ通信を可能としたデータ処理システム、メモリ搭載デバイス、およびデータ処理方法、並びにプログラム記憶媒体を提供することを目的とする。

また、メモリ搭載デバイスが、アクセス機器からアクセス制御データとして構成されるアクセス制御チケットを受領して、アクセス制御チケットに記述された認証ルールに基づく認証、および該アクセス制御チケットに記述されたアクセス機器の識別デ一夕の確認を条件としてデータアクセスを許容する構成とすることにより、メモリに対するアクセスをよりセキュアな管理下において実行可能とし、各アクセス毎に様々な認証態様、チケット態様を設定可能として、メモリァクセス処理に応じたセキュリティレベルを設定したアクセス管理が実現するデ一タァクセス制御システム、メモリ搭載デバイス、およびデータアクセス制御方法、並びにプログラム記憶媒体を提供することを目的とする。

本発明は、上述のような、従来技術の現状に鑑みてなされたものであり、複数のパーティションに分割されたメモリ領域のアクセスに対して、アクセス機器からアクセス制御チケットを受領し、該アクセス制御チケットの記述に従って、デ —夕ファイルに対するアクセス処理を実行する構成とし、複数のアクセス制御チケヅトに基づく複数のデータファイルに対するアクセス処理を、デパイスの処理を軽減した態様として実行可能としたメモリアクセス制御システム、メモリ搭載デバイス、およびメモリアクセス制御方法、並びにプログラム記憶媒体を提供することを目的とする。

本発明の第 1の側面は、

データ格納可能なメモリ部を有するメモリ搭載デバイスに対する、アクセス機器からの前記メモリ部格納データファイルに対するアクセス処理を管理するデ一タアクセス管理システムであり、前記アクセス機器は、該アクセス機器に対して許容されるアクセスモードを設定したアクセス制御チケットとしてのサービス許可チケット（S PT) をチケヅト発行手段から受領して該受領したサービス許可チケット（S PT) を前記メモリ搭載デバィスに対して出力し、

前記メモリ搭載デバイスは、前記アクセス機器から、前記サービス許可チケット（S PT) を受領して、該サ一ビス許可チケット（S P T) に記述されたァクセスモ一ドに従った処理を実行する構成を有することを特徴とするデ一夕ァクセス管理システムにある。

さらに、本発明のデータアクセス管理システムの一実施態様において、前記サ —ビス許可チケット（S P T) は、アクセス対象としたデ一夕ファイルを識別するファイル識別子を含み、前記メモリ搭載デバイスは、前記アクセス機器から、前記サービス許可チケット（S PT) を受領して、該サ一ビス許可チケット（S P T) に記述されたファイル識別子に従ってデータファイルを選択し、該選択したファイルに対して前記アクセスモードに従った処理を実行する構成を有することを特徴とする。

さらに、本発明のデータアクセス管理システムの一実施態様において、前記サ

—ビス許可チケット（S P T) は、アクセス対象とした複数のデータファイルを識別する複数のファイル識別子を含む構成を有し、該複数のファイル識別子中、一方はタ一ゲットファイル識別子として設定するとともにターゲットファイルに対する読み取りまたは書き込み許可データを格納した構成を有し、前記メモリ搭載デバイスは、前記アクセス機器から、前記サービス許可チケット（S PT) を受領して、前記アクセスモードに従った処理を実行するとともに、該サービス許可チケット（S PT) にターゲットファイル識別子として設定されたターゲットファイルに対して、該サ一ビス許可チケット（S PT) に設定された読み取りまたは書き込み許可データに従った読み取りまたは書き込み処理を実行する構成を有することを特徴とする。

さらに、本発明のデータアクセス管理システムの一実施態様において、前記サ —ビス許可チケット（S P T) は、アクセス対象とした複数のデータファイルを識別する複数のファイル識別子を含む構成を有し、該複数のファイル識別子中、一方はターゲットファイル識別子として設定するとともにターゲットファイルに対する読み取りまたは書き込み許可データを格納し、他方のデータファイルのァクセスモードとして該データファイルに格納した暗号鍵を用いた暗号化処理を設定した構成を有し、前記メモリ搭載デバイスは、前記アクセス機器から、前記サ —ビス許可チケット（S P T ) を受領して、前記アクセスモードに従った処理として、前記夕一ゲットファイルの読み取りおよび前記暗号鍵による暗号化処理を実行することにより、前記メモリ搭載デバイス内における内部暗号化処理を実行する構成としたことを特徴とする。

さらに、本発明のデータアクセス管理システムの一実施態様において、前記サ —ビス許可チケット（S P T ) を発行するチケット発行手段は、前記メモリ搭載デバイスのメモリ領域を管理するエンティティの管理下にあるチケット発行手段であり、該チケット発行手段は、各アクセス機器に応じて各種のアクセスモードを設定したサービス許可チケット（S P T ) を個別に発行することにより、各ァクセス機器に応じて異なる態様のアクセスを実行可能とした構成を有することを特徴とする。

さらに、本発明のデータアクセス管理システムの一実施態様において、前記メモリ搭載デバイスは、アクセス機器とのセッション中に受領したサービス許可チケット（S P T ) に基づいてファイルオープン処理を実行したファイルの識別デ一夕としてのファイル識別子と、前記サービス許可チケット（S P T ) に記述されたアクセスモードを対応付けたファイルオープンテーブルを生成し、該フアイルオープンテーブルを参照して前記アクセス機器からの受領コマンドの実行の可否を判定する構成を有することを特徴とする。

さらに、本発明のデ一夕アクセス管理システムの一実施態様において、前記メモリ搭載デバイスのメモリ部は、各々が対応するパーティシヨンマネージャによつて管理されるメモリ領域としての 1以上のパーティション領域を有し、前記デ一夕ファイルは前記 1以上のパーティション領域のいずれかに格納され、前記メモリ搭載デバイスは、各パーティション内のデータファイルに対するアクセス要求に対する処理を、パーティションマネージャ管理下のチケット発行手段が発行し、チケット利用手段としての前記アクセス機器から前記メモリ搭載デバイスに対して入力されるサービス許可チケット（S P T) の記述に基づいて実行する構成であることを特徴とする。

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

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

データ格納可能なメモリ部を有するメモリ搭載デバイスであり、

アクセス機器からの前記メモリ部格納データファイルに対するアクセス処理を制御する制御手段を有し、

前記制御手段は、

前記アクセス機器から、受領するサービス許可チケット（S P T) に記述されたファイル識別子に従ってデータファイルを選択し、該選択したファイルに対して、サービス許可チケット（S P T) に記述されたアクセスモードに従った処理を実行する構成を有することを特徴とするメモリ搭載デバイスにある。

さらに、本発明のメモリ搭載デバイスの一実施態様において、前記サービス許可チケット（S PT) は、アクセス対象としたデータファイルを識別するフアイル識別子を含み、前記制御手段は、前記アクセス機器から、前記サービス許可チケット（S P T) を受領して、該サ一ビス許可チケット（S PT) に記述されたファイル識別子に従ってデータファイルを選択し、該選択したファイルに対して前記アクセスモードに従った処理を実行する構成を有することを特徴とする。さらに、本発明のメモリ搭載デバイスの一実施態様において、前記サービス許可チケット（S PT) は、アクセス対象とした複数のデータファイルを識別する複数のファイル識別子を含む構成を有し、該複数のファイル識別子中、一方は夕 —ゲットファイル識別子として設定するとともにターゲットファイルに対する読み取りまたは書き込み許可データを格納した構成を有し、前記制御手段は、前記アクセス機器から、前記サービス許可チケット（S PT) を受領して、前記ァクセスモ一ドに従った処理を実行するとともに、該サ一ビス許可チケット（S P T) に夕ーゲットファイル識別子として設定された夕一ゲットファイルに対して、該サービス許可チケット（S PT) に設定された読み取りまたは書き込み許可デ一夕に従った読み取りまたは書き込み処理を実行する構成を有することを特徴とする。

さらに、本発明のメモリ搭載デバイスの一実施態様において、前記サービス許可チケット（S PT) は、アクセス対象とした複数のデータファイルを識別する複数のファイル識別子を含む構成を有し、該複数のファイル識別子中、一方はタ —ゲットファイル識別子として設定するとともにターゲヅトファイルに対する読み取りまたは書き込み許可デ一夕を格納し、他方のデータファイルのアクセスモードとして該データファイルに格納した暗号鍵を用いた暗号化処理を設定した構成を有し、前記制御手段は、前記アクセス機器から、前記サービス許可チケット (S P T) を受領して、前記アクセスモードに従った処理として、前記夕一ゲヅトファイルの読み取りおよび前記暗号鍵による暗号化処理を実行することにより、前記メモリ搭載デバイス内における内部暗号化処理を実行する構成としたことを特徴とする。

さらに、本発明のメモリ搭載デバイスの一実施態様において、前記制御手段は、アクセス機器とのセッション中に受領したサービス許可チケット（S PT) に基づいてファイルオープン処理を実行したファイルの識別データとしてのファイル識別子と、前記サービス許可チケット（S PT) に記述されたアクセスモードを対応付けたファイルオープンテーブルを生成し、該ファイルオープンテーブルを参照して前記アクセス機器からの受領コマンドの実行の可否を判定する構成を有することを特徴とする。さらに、本発明のメモリ搭載デバイスの一実施態様において、前記メモリ搭載デパイスのメモリ部は、各々が対応するパーティションマネージャによって管理されるメモリ領域としての 1以上のパ一テイション領域を有し、前記データファィルは前記 1以上のパーティシヨン領域のいずれかに格納され、前記制御手段は、各パーティション内のデータファイルに対するアクセス要求に対する処理を、パ —ティションマネージャ管理下のチケット発行手段が発行し、チケット利用手段としての前記アクセス機器から前記メモリ搭載デバイスに対して入力されるサ一ビス許可チケット（S P T ) の記述に基づいて実行する構成であることを特徴とする。

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

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

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

データ格納可能なメモリ部を有するメモリ搭載デバイスに対する、アクセス機器からの前記メモリ部格納データファイルに対するアクセス処理を管理するデ一夕アクセス管理方法であり、

前記アクセス機器は、該アクセス機器に対して許容されるアクセスモードを設定したアクセス制御チケットとしてのサービス許可チケット（S P T ) をチケット発行手段から受領して該受領したサービス許可チケット（S P T ) を前記メモリ搭載デバイスに対して出力し、前記メモリ搭載デバイスは、前記アクセス機器から、前記サービス許可チケット（S PT) を受領して、該サービス許可チケット（S PT) に記述されたァクセスモ一ドに従った処理を実行することを特徴とするデータアクセス管理方法にある。

さらに、本発明のデータアクセス管理方法の一実施態様において、前記サ一ビス許可チケット（S PT) は、アクセス対象としたデータファイルを識別するフアイル識別子を含み、前記メモリ搭載デバイスは、前記アクセス機器から、前記サービス許可チケヅト（S PT) を受領して、該サ一ビス許可チケヅト（S P T) に記述されたファイル識別子に従ってデータファイルを選択し、該選択したファィルに対して前記アクセスモードに従った処理を実行することを特徴とする。さらに、本発明のデータアクセス管理方法の一実施態様において、前記サ一ビス許可チケット（S PT) は、アクセス対象とした複数のデータファイルを識別する複数のファイル識別子を含む構成を有し、該複数のファイル識別子中、一方はターゲットファイル識別子として設定するとともにターゲットファイルに対する読み取りまたは書き込み許可データを格納した構成を有し、前記メモリ搭載デバイスは、前記アクセス機器から、前記サービス許可チケット（S PT) を受領して、前記アクセスモードに従った処理を実行するとともに、該サ一ビス許可チケヅト（S P T) にターゲットファイル識別子として設定されたターゲットファィルに対して、該サ一ビス許可チケット（S P T) に設定された読み取りまたは書き込み許可データに従った読み取りまたは書き込み処理を実行することを特徴とする。

さらに、本発明のデ一夕アクセス管理方法の一実施態様において、前記サ一ビス許可チケット（S PT) は、アクセス対象とした複数のデータファイルを識別する複数のファイル識別子を含む構成を有し、該複数のファイル識別子中、一方はタ一ゲットファイル識別子として設定するとともに夕一ゲットファイルに対する読み取りまたは書き込み許可データを格納し、他方のデータファイルのァクセスモードとして該データファイルに格納した暗号鍵を用いた暗号化処理を設定した構成を有し、前記メモリ搭載デバイスは、前記アクセス機器から、前記サービス許可チケット（S PT) を受領して、前記アクセスモ一ドに従った処理として、前記夕一ゲットファイルの読み取りおよび前記暗号鍵による暗号化処理を実行することにより、前記メモリ搭載デバイス内における内部暗号化処理を実行することを特徴とする。

さらに、本発明のデータアクセス管理方法の一実施態様において、前記サ一ビス許可チケット（S P T ) を発行するチケット発行手段は、前記メモリ搭載デバイスのメモリ領域を管理するェンティティの管理下にあるチケット発行手段であり、該チケット発行手段は、各アクセス機器に応じて各種のアクセスモードを設定したサービス許可チケット（S P T ) を個別に発行することにより、各ァクセス機器に応じて異なる態様のアクセスを実行可能としたことを特徴とする。さらに、本発明のデータアクセス管理方法の一実施態様において、前記メモリ搭載デバイスは、アクセス機器とのセッション中に受領したサービス許可チケット（S P T ) に基づいてファイルオープン処理を実行したファイルの識別データとしてのファイル識別子と、前記サービス許可チケット（S P T ) に記述されたアクセスモードを対応付けたファイルオープンテ一ブルを生成し、該ファイルォ —プンテーブルを参照して前記アクセス機器からの受領コマンドの実行の可否を判定することを特徴とする。

さらに、本発明のデータアクセス管理方法の一実施態様において、前記メモリ搭載デバイスのメモリ部は、各々が対応するパーティションマネージャによって管理されるメモリ領域としての 1以上のパーティション領域を有し、前記デ一夕ファイルは前記 1以上のパーティション領域のいずれかに格納され、前記メモリ搭載デバイスは、各パーティション内のデ一夕ファイルに対するアクセス要求に対する処理を、パーティシヨンマネージャ管理下のチケット発行手段が発行し、チケット利用手段としての前記アクセス機器から前記メモリ搭載デパイスに対して入力されるサービス許可チケット（ S P T ) の記述に基づいて実行することを特徴とする。

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

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

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

データ格納可能なメモリ部を有するメモリ搭載デバイスに対する、アクセス機器からの前記メモリ部格納データファイルに対するアクセス処理を管理するデ一夕アクセス管理処理をコンピュータ · システム上で実行せしめるコンピュータ · プログラムを提供するプログラム記憶媒体であって、前記コンピュータ · プログラムは、

前記メモリ搭載デバイスにアクセスを実行するアクセス機器において許容されるアクセスモ一ドを設定したアクセス制御チケットとしてのサービス許可チケット（S P T ) を受領して、該サ一ビス許可チケット（S P T ) に記述されたァクセスモードに従った処理を実行するステップを有することを特徴とするプログラム記憶媒体にある。

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

データ格納可能なメモリ部を有するメモリ搭載デバイスに対するアクセス機器からのアクセス要求に応じて、前記メモリ部に対するデータ処理を実行するデ一タ処理システムであり、

前記メモリ搭載デバイスは、前記メモリ部に対するデータ処理に対応して構成されるアクセス制御チケットを前記アクセス機器から受領して、該アクセス制御チケットに記述されたルールに基づくデータ処理を実行する構成であるとともに、前記アクセス機器からの指定または受領したアクセス制御チケットの記述に基づいて、前記アクセス機器との相互認証の方式を決定して実行するとともに、受領したアクセス制御チケットの記述に基づいて、アクセス制御チケットの検証方式を決定して実行し、相互認証およびチケット検証の双方の成立を条件として前記アクセス機器からのアクセス要求に応じる構成を有することを特徴とするデ一夕処理システムにある。

さらに、本発明のデータ処理システムの一実施態様において、前記相互認証の方式は、公開鍵方式または共通鍵方式のいずれかであり、アクセス制御チケットの検証方式は、公開鍵方式または共通鍵方式のいずれかであることを特徴とする。さらに、本発明のデータ処理システムの一実施態様において、前記メモリ搭載デパイスは、前記アクセス制御チケットの検証を実行するための M A C検証用鍵を保有し、前記アクセス機器から受領したアクセス制御チケットの検証を共通鍵方式に従って実行する場合には、該 M A C検証用鍵を適用した改竄チヱック処理を実行し、アクセス制御チケットの検証を公開鍵方式に従って実行する場合には、チケット発行手段の公開鍵証明書から取得したチケット発行手段の公開鍵に基づく署名検証処理を実行する構成であることを特徴とする。

さらに、本発明のデータ処理システムの一実施態様において、前記メモリ搭載デバイスは、前記アクセス制御チケットの検証を実行するための M A C検証用鍵を複数保有し、前記アクセス機器から受領したアクセス制御チケットに記録された情報に従って適用すべき M A C検証用鍵を選択する構成であることを特徴とする。

さらに、本発明のデータ処理システムの一実施態様において、前記アクセス制御チケットには、前記メモリ搭載デバイスのメモリ部内の格納データの更新処理を許容するデータアップデートチケット（D U T ) を含み、前記メモリ搭載デバイスは、前記アクセス制御チケットの検証を実行するための M A C検証用鍵を複数保有し、前記メモリ搭載デバイスは、前記アクセス機器から受領したデータァップデートチケット（D U T ) に指定された更新対象デ一夕がアクセス制御チケットの検証を実行するための M A C検証用鍵である場合は、複数の M A C検証用鍵から更新対象に該当しない M A C検証用鍵を選択して受領したデータアツプデートチケット（D U T ) の検証処理を実行することを特徴とする。

さらに、本発明のデータ処理システムの一実施態様において、前記メモリ搭載デパイスのメモリ部は、各々が対応するパ一ティションマネージャによって管理されるメモリ領域としての 1以上のパーティション領域を有し、前記メモリ搭載デパイスは、前記アクセス機器からの各パーティション内のデータに対するァクセス要求に対する処理を、各パーティションマネージャの管理下のチケット発行手段が発行し、チケット利用手段としての前記アクセス機器から前記メモリ搭載デバイスに対して入力されるアクセス制御チケヅトの記述に基づいて実行する構成であることを特徴とする。

さらに、本発明のデータ処理システムの一実施態様において、前記メモリ搭載デバイスのメモリ部は、各々が対応するパーティションマネージャによって管理されるメモリ領域としての 1以上のパーティシヨン領域を有し、前記メモリ搭載デバイスは、前記アクセス機器とのセッション中に実行したパーティション認証またはデバイス認証によって取得した公開鍵方式認証情報およびセッション鍵、または共通鍵方式認証情報およびセッション鍵を対応付けた認証テーブルを生成して、当該セッション期間、保持する構成を有することを特徴とする。

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

デ一夕格納可能なメモリ部を有するメモリ搭載デバイスであり、

アクセス機器からのアクセス要求に応じて、前記メモリ部に対するデータ処理を実行する制御手段を有し、

前記制御手段は、前記メモリ部に対するデータ処理に対応して構成されるァクセス制御チケットを前記アクセス機器から受領して、該アクセス制御チケットに記述されたルールに基づくデータ処理を実行する構成であるとともに、

前記アクセス機器からの指定または受領したアクセス制御チケヅトの記述に基づいて、前記アクセス機器との相互認証の方式を決定して実行するとともに、受領したアクセス制御チケットの記述に基づいて、アクセス制御チケットの検証方式を決定して実行し、相互認証およびチケット検証の双方の成立を条件として前記アクセス機器からのアクセス要求に応じる構成を有することを特徴とするメモリ搭載デバイスにある。

さらに、本発明のメモリ搭載デバイスの一実施態様において、前記制御手段は、前記相互認証の方式として、公開鍵方式または共通鍵方式のいずれかを選択的に実行し、アクセス制御チケットの検証方式として、公開鍵方式または共通鍵方式のいずれかを選択的に実行する構成であることを特徴とする。

さらに、本発明のメモリ搭載デバイスの一実施態様において、前記メモリ搭載デバイスは、前記アクセス制御チケットの検証を実行するための M A C検証用鍵を保有し、前記制御手段は、前記アクセス機器から受領したアクセス制御チケットの検証を共通鍵方式に従って実行する場合には、該 M A C検証用鍵を適用した改竄チヱック処理を実行し、

アクセス制御チケットの検証を公開鍵方式に従って実行する場合には、チケット発行手段の公開鍵証明書から取得したチケット発行手段の公開鍵に基づく署名検証処理を実行する構成であることを特徴とする。

さらに、本発明のメモリ搭載デバイスの一実施態様において、前記メモリ搭載デバイスは、前記アクセス制御チケットの検証を実行するための M A C検証用鍵を複数保有し、前記制御手段は、前記アクセス機器から受領したアクセス制御チケットに記録された情報に従って適用すべき M A C検証用鍵を選択する構成であることを特徴とする。

さらに、本発明のメモリ搭載デバイスの一実施態様において、前記アクセス制御チケットには、前記メモリ搭載デバイスのメモリ部内の格納データの更新処理を許容するデータアップデートチケット（D U T ) を含み、前記メモリ搭載デバイスは、前記アクセス制御チケットの検証を実行するための M A C検証用鍵を複数保有し、前記制御手段は、前記アクセス機器から受領したデータアップデートチケット（D U T ) に指定された更新対象データがアクセス制御チケットの検証を実行するための M A C検証用鍵である場合は、複数の M A C検証用鍵から更新対象に該当しない M A C検証用鍵を選択して受領したデータアップデートチケット（D U T ) の検証処理を実行することを特徴とする。

さらに、本発明のメモリ搭載デバイスの一実施態様において、前記メモリ搭載デバイスのメモリ部は、各々が対応するパーティションマネージャによって管理されるメモリ領域としての 1以上のパーティション領域を有し、前記制御手段は、前記アクセス機器からの各パーティシヨン内のデータに対するアクセス要求に対する処理を、各パーティションマネージャの管理下のチケット発行手段が発行し、チケット利用手段としての前記アクセス機器から前記メモリ搭載デバイスに対して入力されるアクセス制御チケットの記述に基づいて実行する構成であることを特徴とする。

さらに、本発明のメモリ搭載デバイスの一実施態様において、前記メモリ搭載デバイスのメモリ部は、各々が対応するパーティションマネージャによって管理されるメモリ領域としての 1以上のパーティション領域を有し、前記制御手段は、前記アクセス機器とのセッション中に実行したパーティション認証またはデバイス認証によって取得した公開鍵方式認証情報およびセッション鍵、または共通鍵方式認証情報およびセッション鍵を対応付けた認証テーブルを生成して、当該セッシヨン期間、保持する構成を有することを特徴とする。

さらに、第 7の側面は、

データ格納可能なメモリ部を有するメモリ搭載デバイスに対するアクセス機器からのアクセス要求に応じて、前記メモリ部に対するデータ処理を実行するデ一夕処理方法であり、

前記メモリ搭載デバイスにおいて、

前記メモリ部に対するデータ処理に対応して構成されるアクセス制御チケットを前記アクセス機器から受領して、該アクセス制御チケットに記述されたルールに基づくデータ処理を実行し、

前記アクセス機器からの指定または受領したアクセス制御チケットの記述に基づいて、前記アクセス機器との相互認証の方式を決定して実行するとともに、受領したアクセス制御チケットの記述に基づいて、アクセス制御チケットの検証方式を決定して実行し、相互認証およびチケット検証の双方の成立を条件として前記アクセス機器からのアクセス要求を実行することを特徴とするデ一夕処理方法にめる。

さらに、本発明のデータ処理方法の一実施態様において、前記相互認証の方式は、公閧鍵方式または共通鍵方式のいずれかであり、アクセス制御チケットの検証方式は、公開鍵方式または共通鍵方式のいずれかであることを特徴とする。さらに、本発明のデータ処理方法の一実施態様において、前記メモリ搭載デバイスは、前記アクセス制御チケットの検証を実行するための M A C検証用鍵を保有し、前記アクセス機器から受領したアクセス制御チケットの検証を共通鍵方式に従って実行する場合には、該 M A C検証用鍵を適用した改竄チェック処理を実行し、アクセス制御チケットの検証を公開鍵方式に従って実行する場合には、チケット発行手段の公開鍵証明書から取得したチケット発行手段の公開鍵に基づく署名検証処理を実行することを特徴とする。

さらに、本発明のデータ処理方法の一実施態様において、前記メモリ搭載デバイスは、前記アクセス制御チケットの検証を実行するための M A C検証用鍵を複数保有し、前記アクセス機器から受領したアクセス制御チケットに記録された情報に従って適用すべき M A C検証用鍵を選択することを特徴とする。

さらに、本発明のデータ処理方法の一実施態様において、前記アクセス制御チケットには、前記メモリ搭載デバイスのメモリ部内の格納デ一夕の更新処理を許容するデ一夕アップデートチケット（D U T ) を含み、前記メモリ搭載デバイスは、前記アクセス制御チケットの検証を実行するための M A C検証用鍵を複数保有し、前記メモリ搭載デバイスは、前記アクセス機器から受領したデータアップデートチケット（D U T ) に指定された更新対象データがアクセス制御チケットの検証を実行するための M A C検証用鍵である場合は、複数の M A C検証用鍵から更新対象に該当しない M A C検証用鍵を選択して受領したデータアツプデ一トチケット（D U T ) の検証処理を実行することを特徴とする。

さらに、本発明のデ一夕処理方法の一実施態様において、前記メモリ搭載デバイスのメモリ部は、各々が対応するパーティションマネージャによって管理されるメモリ領域としての 1以上のパーティション領域を有し、前記メモリ搭載デバイスは、前記アクセス機器からの各パーティション内のデータに対するアクセス要求に対する処理を、各パーティションマネージャの管理下のチケット発行手段が発行し、チケット利用手段としての前記アクセス機器から前記メモリ搭載デバイスに対して入力されるアクセス制御チケットの記述に基づいて実行することを特徴とする。

さらに、本発明のデータ処理方法の一実施態様において、前記メモリ搭載デバイスのメモリ部は、各々が対応するパーティションマネージャによって管理されるメモリ領域としての 1以上のパーティシヨン領域を有し、前記メモリ搭載デバイスは、前記アクセス機器とのセッション中に実行したパーティション認証またはデバイス認証によって取得した公開鍵方式認証情報およびセッション鍵、または共通鍵方式認証情報およびセッション鍵を対応付けた認証テーブルを生成して、当該セッション期間、保持することを特徴とする。

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

データ格納可能なメモリ部を有するメモリ搭載デパイスに対するアクセス機器からのアクセス要求に応じて、前記メモリ部に対するデータ処理をコンピュータ · システム上で実行せしめるコンピュータ . プログラムを提供するプログラム記憶媒体であって、前記コンピュ一夕 · プログラムは、

前記メモリ部に対するデータ処理に対応して構成されるアクセス制御チケットを前記アクセス機器から受領するステップと、

前記アクセス機器からの指定または受領したアクセス制御チケットの記述に基づいて、前記アクセス機器との相互認証の方式を決定して実行するステップと、受領したアクセス制御チケットの記述に基づいて、アクセス制御チケットの検証方式を決定して実行するステップと、

相互認証およびチケット検証の双方の成立を条件として前記アクセス機器からのアクセス要求を実行するステップと、

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

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

デ一夕格納可能なメモリ部を有するメモリ搭載デバイスに対して、アクセス機器からコマンドを発行して前記メモリ部に格納されたデータに対する処理を実行するデータアクセス制御システムであり、

前記メモリ搭載デバイスは、前記アクセス機器から、前記メモリ部に格納されたデ一夕に対するアクセス制御データとして構成されるアクセス制御チケットを受領して、該アクセス制御チケットに記述された認証ルールに基づく認証の成立、および該アクセス制御チケットに記述されたアクセス機器の識別データの確認を条件としてデータアクセスを許容する構成であることを特徴とするデータァクセス制御システムにある。

さらに、本発明のデータアクセス制御システムの一実施態様において、前記ァクセス制御チケットには、認証方式として公開鍵認証方式または共通鍵認証方式のいずれかまたはいずれでも許容する旨の認証方式指定情報としての認証タイプが記述され、前記メモリ搭載デバイスは、アクセス機器から受領したアクセス制御チケットに記述された認証タイプに従って認証処理を実行する構成であることを特徴とする。

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

さらに、本発明のデータアクセス制御システムの一実施態様において、前記ァクセス制御チケットには、該アクセス制御チケットの発行手段のカテゴリまたは識別子が格納され、前記メモリ搭載デバイスは、アクセス機器から受領したァクセス制御チケットに記述された該アクセス制御チケットの発行手段のカテゴリまたは識別子と、該アクセス制御チケットの発行手段の公開鍵証明書に格納されたユーザ情報との対比に基づいてチケットが正当な発行手段により発行されたチケットであることの確認処理を実行し、該確認を条件としてデータアクセスを許容する構成であることを特徴とする。

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

さらに、本発明のデータアクセス制御システムの一実施態様において、前記ァクセス制御チケットには、該アクセス制御チケットの利用手段のカテゴリまたは識別子が格納され、前記メモリ搭載デバイスは、アクセス機器から受領したァクセス制御チケヅトに記述された該アクセス制御チケットの利用手段であるァクセス機器のカテゴリまたは識別子と、該アクセス制御チケットの利用手段の公開鍵証明書に格納されたユーザ情報との対比に基づいて、チケットが正当な利用手段により提供されたチケットであることの確認処理を実行し、該確認を条件としてデータアクセスを許容する構成であることを特徴とする。

さらに、本発明のデータアクセス制御システムの一実施態様において、前記メモリ搭載デバイスのメモリ部は、各々が対応するパーティションマネージャによつて管理されるメモリ領域としての 1以上のパーティション領域を有し、前記メモリ搭載デバイスは、前記アクセス機器とのセッシヨン中に実行したパーティション認証またはデバイス認証によって取得した公開鍵方式認証情報およびセッション鍵、または共通鍵方式認証情報およびセッション鍵を対応付けた認証テープルを生成する構成を有することを特徴とする。

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

アクセス機器からコマンドを発行して前記メモリ部に格納されたデータに対する処理を実行する制御手段を有し、

前記制御手段は、

前記アクセス機器から、前記メモリ部に格納されたデータに対するアクセス制御データとして構成されるアクセス制御チケットを受領して、該アクセス制御チケットに記述された認証ルールに基づく認証の成立、および該アクセス制御チケットに記述されたアクセス機器の識別デ一夕の確認を条件としてデータアクセスを許容する構成であることを特徴とするメモリ搭載デバイスにある。

さらに、本発明のメモリ搭載デバイスの一実施態様において、前記アクセス制御チケットには、認証方式として公開鍵認証方式または共通鍵認証方式のいずれかまたはいずれでも許容する旨の認証方式指定情報としての認証タイプが記述され、前記制御手段は、アクセス機器から受領したアクセス制御チケットに記述された認証タイプに従って認証処理を実行する構成であることを特徴とする。さらに、本発明のメモリ搭載デパイスの一実施態様において、前記アクセス制御チケットには、該アクセス制御チケットの発行手段のカテゴリまたは識別子が格納され、前記制御手段は、アクセス機器から受領したアクセス制御チケットに記述された該アクセス制御チケットの発行手段のカテゴリまたは識別子に基づいて、チケットが正当な発行手段により発行されたチケットであることの確認処理を実行し、該確認を条件としてデータアクセスを許容する構成であることを特徴とする。

さらに、本発明のメモリ搭載デバイスの一実施態様において、前記アクセス制御チケットには、該アクセス制御チケットの発行手段のカテゴリまたは識別子が格納され、前記制御手段は、アクセス機器から受領したアクセス制御チケットに記述された該アクセス制御チケットの発行手段のカテゴリまたは識別子と、該ァクセス制御チケットの発行手段の公開鍵証明書に格納されたユーザ情報との対比に基づいてチケットが正当な発行手段により発行されたチケットであることの確認処理を実行し、該確認を条件としてデ一夕アクセスを許容する構成であることを特徴とする。

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

さらに、本発明のメモリ搭載デバイスの一実施態様において、前記アクセス制御チケットには、該アクセス制御チケットの利用手段のカテゴリまたは識別子が格納され、前記制御手段は、アクセス機器から受領したアクセス制御チケットに記述された該アクセス制御チケットの利用手段であるアクセス機器のカテゴリまたは識別子と、該アクセス制御チケットの利用手段の公開鍵証明書に格納されたユーザ情報との対比に基づいて、チケットが正当な利用手段により提供されたチケットであることの確認処理を実行し、該確認を条件としてデ一夕アクセスを許容する構成であることを特徴とする。

さらに、本発明のメモリ搭載デバイスの一実施態様において、前記メモリ搭載デバイスのメモリ部は、各々が対応するパーティションマネージャによって管理されるメモリ領域としての 1以上のパーティション領域を有し、前記制御手段は、前記アクセス機器とのセヅション中に実行したパーティション認証またはデバイス認証によって取得した公開鍵方式認証情報およびセッション鍵、または共通鍵方式認証情報およびセッシヨン鍵を対応付けた認証テーブルを生成する構成を有することを特徴とする。

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

デ一夕格納可能なメモリ部を有するメモリ搭載デバイスに対して、アクセス機器からコマンドを発行して前記メモリ部に格納されたデータに対する処理を実行するデータアクセス制御方法であり、

前記メモリ搭載デバイスは、前記アクセス機器から、前記メモリ部に格納されたデータに対するアクセス制御データとして構成されるアクセス制御チケットを受領して、該アクセス制御チケットに記述された認証ルールに基づく認証の成立、および該アクセス制御チケットに記述されたアクセス機器の識別データの確認を条件としてデータアクセスを許容することを特徴とするデータアクセス制御方法にめ。

さらに、本発明のデータアクセス制御方法の一実施態様において、前記ァクセス制御チケットには、認証方式として公開鍵認証方式または共通鍵認証方式のいずれかまたはいずれでも許容する旨の認証方式指定情報としての認証タイプが記述され、前記メモリ搭載デバイスは、アクセス機器から受領したアクセス制御チケットに記述された認証タィプに従って認証処理を実行することを特徴とする。さらに、本発明のデータアクセス制御方法の一実施態様において、前記ァクセス制御チケットには、該アクセス制御チケットの発行手段のカテゴリまたは識別子が格納され、前記メモリ搭載デパイスは、アクセス機器から受領したアクセス制御チケットに記述された該アクセス制御チケッ卜の発行手段のカテゴリまたは識別子に基づいて、チケットが正当な発行手段により発行されたチケットである ÷との確認処理を実行し、該確認を条件としてデータアクセスを許容することを特徴とする。

さらに、本発明のデ一夕アクセス制御方法の一実施態様において、前記ァクセス制御チケットには、該アクセス制御チケットの発行手段のカテゴリまたは識別子が格納され、前記メモリ搭載デバイスは、アクセス機器から受領したアクセス制御チケットに記述された該アクセス制御チケットの発行手段のカテゴリまたは識別子と、該アクセス制御チケットの発行手段の公開鍵証明書に格納されたュ一ザ情報との対比に基づいてチケットが正当な発行手段により発行されたチケットであることの確認処理を実行し、該確認を条件としてデータアクセスを許容することを特徴とする。

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

さらに、本発明のデータアクセス制御方法の一実施態様において、前記ァクセス制御チケットには、該アクセス制御チケットの利用手段のカテゴリまたは識別子が格納され、前記メモリ搭載デバイスは、アクセス機器から受領したアクセス制御チケットに記述された該アクセス制御チケヅ卜の利用手段であるアクセス機器のカテゴリまたは識別子と、該アクセス制御チケットの利用手段の公開鍵証明書に格納されたユーザ情報との対比に基づいて、チケットが正当な利用手段により提供されたチケットであることの確認処理を実行し、該確認を条件としてデ一タアクセスを許容することを特徴とする。

さらに、本発明のデータアクセス制御方法の一実施態様において、前記メモリ搭載デバイスのメモリ部は、各々が対応するパーティションマネージャによって管理されるメモリ領域としての 1以上のパーティション領域を有し、前記メモリ搭載デバイスは、前記アクセス機器とのセッション中に実行したパーティシヨン認証またはデバイス認証によって取得した公開鍵方式認証情報およびセッション鍵、または共通鍵方式認証情報およびセッション鍵を対応付けた認証テーブルを生成することを特徴とする。さらに、本発明の第 1 2の側面は、

データ格納可能なメモリ部を有するメモリ搭載デバイスにおいて、アクセス機器からコマンドを発行して前記メモリ部に格納されたデータに対する処理をコンピュー夕 . システム上で実行せしめるコンピュータ · プログラムを提供するプログラム記憶媒体であって、前記コンピュータ · プログラムは、

前記アクセス機器から、前記メモリ部に格納されたデータに対するアクセス制御デ一夕として構成されるアクセス制御チケットを受領するステップと、該アクセス制御チケットに記述された認証ルールに基づく認証の成立、および該アクセス制御チケットに記述されたアクセス機器の識別データの確認を条件としてデータアクセスを許容するステップと、

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

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

複数のデ一夕ファイルを格納したメモリ部を有するメモリ搭載デバイスに対するァクセス機器からのメモリアクセスを制御するメモリアクセス制御システムであり

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

各々が対応するパーティションマネージャによって管理されるメモリ領域としての 1以上のパ一テイション領域を有し、前記データファイルは前記 1以上のパ —ティション領域のいずれかに格納され、

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

前記アクセス機器からアクセス制御チケットを受領し、該アクセス制御チケッ卜の記述に従って、データファイルに対するアクセス処理を実行する構成を有し、複数のアクセス制御チケヅトに基づく複数のデータファイルに対するアクセス処理を、前記メモリ搭載デバイスに対する認証としてのデバイス認証、またはァクセス対象のデータファイルの格納された各パーティションに対する認証としてのパーティシヨン認証の成立を条件として実行する構成を有することを特徴とするメモリアクセス制御システムにある。

さらに、本発明のメモリアクセス制御システムの一実施態様において、前記各パーティシヨン毎に設定可能な認証態様は、アクセス制御データとして構成されるアクセス制御チケットに記述され、前記メモリ搭載デバイスは、前記アクセス機器から該アクセス制御チケットを受領し、該アクセス制御チケットの記述に従つて、各パーティシヨン毎に必要な認証態様の判別を行なう構成であることを特徴とする。

さらに、本発明のメモリアクセス制御システムの一実施態様において、前記メモリ搭載デバイスは、前記デバイス認証の成立を条件として、複数のアクセス制御チケットに基づく複数の異なるパーティシヨン内のフアイルアクセスを許容する構成であることを特徴とする。

さらに、本発明のメモリアクセス制御システムの一実施態様において、前記メモリ搭載デバイスは、複数のアクセス制御チケットに基づく複数の異なるパ一テイシヨン内のファイルアクセスを、前記異なるパ一ティション各々に対応して設定された認証条件であるパ一テイション認証またはデバイス認証のすべての認証成立を条件として、許容する構成であることを特徴とする。

さらに、本発明のメモリアクセス制御システムの一実施態様において、前記メモリ搭載デバイスは、複数の異なるパーティション内のファイルアクセス条件として実行した複数の認証処理の結果、取得された複数のセッション鍵に基づいて唯一の統合セヅション鍵を生成し、該統合セッション鍵に基づいて前記アクセス機器との通信データの暗号処理を実行する構成としたことを特徴とする。

さらに、本発明のメモリアクセス制御システムの一実施態様において、前記メモリ搭載デバイスは、複数の異なるパーティション内のファイルアクセス条件として実行した複数の認証処理の結果、取得された複数のセッション鍵に基づいて唯一の統合セッション鍵を各セッション鍵の排他論理和演算によって生成し、該統合セッシヨン鍵に基づいて前記アクセス機器との通信データの暗号処理を実行する構成としたことを特徴とする。

さらに、本発明のメモリアクセス制御システムの一実施態様において、前記メモリ搭載デバイスは、複数の異なるパーティション内のファイルアクセス条件として実行した複数の認証処理の結果、取得された複数のセッシヨン鍵の中から唯一のセヅシヨン鍵を選択し、該選択セッシヨン鍵に基づいて前記アクセス機器との通信デ一夕の暗号処理を実行する構成としたことを特徴とする。さらに、本発明のメモリアクセス制御システムの一実施態様において、前記メモリ搭載デバイスは、前記アクセス機器との間で実行したパーティション認証またはデバイス認証によって取得した公開鍵方式認証情報およびセッシヨン鍵、または共通鍵方式認証情報およびセッション鍵を対応付けた認証テーブルを生成して、当該セッション期間、保持する構成を有することを特徴とする。

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

複数のデータファイルを格納したメモリ部を有するメモリ搭載デバイスであり、アクセス機器からのメモリアクセスを制御する制御手段を有し、

前記メモリ部は、

各々が対応するパーティションマネージャによって管理されるメモリ領域としての 1以上のパ一ティション領域を有し、前記データファイルは前記 1以上のパ

—ティション領域のいずれかに格納され、

前記制御手段は、

前記アクセス機器からアクセス制御チケットを受領し、該アクセス制御チケットの記述に従って、データファイルに対するアクセス処理を実行する構成を有し、複数のアクセス制御チケットに基づく複数のデ一夕ファイルに対するアクセス処理を、前記メモリ搭載デバイスに対する認証としてのデバイス認証、またはァクセス対象のデータファイルの格納された各パーティジョンに対する認証としてのパーティシヨン認証の成立を条件として実行する構成を有することを特徴とするメモリ搭載デバイスにある。

さらに、本発明のメモリ搭載デバイスの一実施態様において、前記各パーティシヨン毎に設定可能な認証態様は、アクセス制御データとして構成されるァクセス制御チケットに記述され、前記メモリ搭載デバイスは、前記アクセス機器から該アクセス制御チケットを受領し、前記制御手段は、該アクセス制御チケットの記述に従って、各パーティション毎に必要な認証態様の判別を行なう構成であることを特徴とする。

さらに、本発明のメモリ搭載デバイスの一実施態様において、前記制御手段は、前記デバイス認証の成立を条件として、複数のアクセス制御チケットに基づく複数の異なるパーティション内のファイルアクセスを許容する構成であることを特徴とする。

さらに、本発明のメモリ搭載デバイスの一実施態様において、前記制御手段は、複数のアクセス制御チケットに基づく複数の異なるパーティシヨン内のファイルアクセスを、前記異なるパーティション各々に対応して設定された認証条件であるパーティション認証またはデバイス認証のすべての認証成立を条件として、許容する構成であることを特徴とする。

さらに、本発明のメモリ搭載デバイスの一実施態様において、前記制御手段は、複数の異なるパーティション内のファイルアクセス条件として実行した複数の認証処理の結果、取得された複数のセッション鍵に基づいて唯一の統合セッション鍵を生成し、該統合セッション鍵に基づいて前記アクセス機器との通信デ一夕の暗号処理を実行する構成としたことを特徴とする。

さらに、本発明のメモリ搭載デバイスの一実施態様において、前記制御手段は、複数の異なるパーティション内のファイルアクセス条件として実行した複数の認証処理の結果、取得された複数のセッション鍵に基づいて唯一の統合セッシヨン鍵を各セッション鍵の排他論理和演算によって生成し、該統合セッション鍵に基づいて前記アクセス機器との通信データの暗号処理を実行する構成としたことを特徴とする。

、さらに、本発明のメモリ搭載デバイスの一実施態様において、前記制御手段は、複数の異なるパーティション内のファイルアクセス条件として実行した複数の認証処理の結果、取得された複数のセッション鍵の中から唯一のセッション鍵を選択し、該選択セッション鍵に基づいて前記アクセス機器との通信デ一夕の暗号処理を実行する構成としたことを特徴とする。

さらに、本発明のメモリ搭載デバイスの一実施態様において、前記制御手段は、前記アクセス機器との間で実行したパーティション認証またはデバイス認証によつて取得した公開鍵方式認証情報およびセッション鍵、または共通鍵方式認証情報およびセッション鍵を対応付けた認証テーブルを生成して、当該セッション期間、保持する構成を有することを特徴とする。

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

複数のデータファイルを格納したメモリ部を有するメモリ搭載デパイスに対するアクセス機器からのメモリアクセスを制御するメモリアクセス制御方法であり前記メモリ搭載デバイスのメモリ部は、

各々が対応するパーティションマネージャによって管理されるメモリ領域としての 1以上のパーテイション領域を有し、前記デ一夕ファイルは前記 1以上のパーテイシヨン領域のいずれかに格納され、

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

前記アクセス機器からアクセス制御チケットを受領し、該アクセス制御チケットの記述に従って、データファイルに対するアクセス処理を実行する構成を有し、複数のアクセス制御チケットに基づく複数のデータファイルに対するアクセス処理を、前記メモリ搭載デバイスに対する認証としてのデバイス認証、またはァクセス対象のデ一夕ファイルの格納された各パーティシヨンに対する認証としてのパーティション認証の成立を条件として実行することを特徴とするメモリアクセス制御方法にある。

さらに、本発明のメモリアクセス制御方法の一実施態様において、前記各パ一テイシヨン毎に設定可能な認証態様は、アクセス制御データとして構成されるァクセス制御チケットに記述され、前記メモリ搭載デバイスは、前記アクセス機器から該アクセス制御チケットを受領し、該アクセス制御チケットの記述に従って、各パーティション每に必要な認証態様の判別を行なうことを特徴とする。

さらに、本発明のメモリアクセス制御方法の一実施態様において、前記メモリ搭載デパイスは、前記デバイス認証の成立を条件として、複数のアクセス制御チケヅトに基づく複^ (の異なるパーティション内のファイルアクセスを許容することを特徴とする。

さらに、本発明のメモリアクセス制御方法の一実施態様において、前記メモリ搭載デバイスは、複数のアクセス制御チケヅトに基づく複数の異なるパーティシヨン内のファイルアクセスを、前記異なるパーティション各々に対応して設定された認証条件であるパ一テイション認証またはデバイス認証のすべての認証成立を条件として、許容することを特徴とする。

さらに、本発明のメモリアクセス制御方法の一実施態様において、前記メモリ搭載デバイスは、複数の異なるパ一テイション内のファイルアクセス条件として実行した複数の認証処理の結果、取得された複数のセッション鍵に基づいて唯一の統合セッション鍵を生成し、該統合セッション鍵に基づいて前記アクセス機器との通信データの暗号処理を実行することを特徴とする。

さらに、本発明のメモリアクセス制御方法の一実施態様において、前記メモリ搭載デバイスは、複数の異なるパーティション内のファイルアクセス条件として実行した複数の認証処理の結果、取得された複数のセッション鍵に基づいて唯一の統合セッション鍵を各セッション鍵の排他論理和演算によって生成し、該統合セッション鍵に基づいて前記アクセス機器との通信データの暗号処理を実行することを特徴とする。

さらに、本発明のメモリアクセス制御方法の一実施態様において、前記メモリ搭載デバイスは、複数の異なるパ一テイション内のファイルアクセス条件として実行した複数の認証処理の結果、取得された複数のセッション鍵の中から唯一のセッション鍵を選択し、該選択セッション鍵に基づいて前記アクセス機器との通信デ一夕の暗号処理を実行することを特徴とする。

さらに、本発明のメモリアクセス制御方法の一実施態様において、前記メモリ搭載デバイスは、前記アクセス機器との間で実行したパ一テイション認証またはデバイス認証によって取得した公開鍵方式認証情報およびセッシヨン鍵、または共通鍵方式認証情報およびセッション鍵を対応付けた認証テーブルを生成して、当該セッション期間、保持することを特徴とする。

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

複数のデータファイルを格納したメモリ部を有するメモリ搭載デバイスに対するアクセス機器からのメモリアクセスを制御するメモリアクセス制御処理をコンピュー夕 · システム上で実行せしめるコンピュータ · プログラムを提供するプログラム記憶媒体であって、前記コンピュータ · プログラムは、

前記メモリ搭載デバイスに対する認証としてのデパイス認証、またはアクセス対象のデータファイルの格納された各パ一テイシヨンに対する認証としてのパーティション認証のいずれかを実行する認証ステップと、

前記認証ステツブにおける認証成立を条件として前記アクセス機器から受領したアクセス制御チケットに基づく複数のデータファイルに対するアクセス処理を実行するステップと、

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

なお、本発明のプログラム記憶媒体は、例えば、様々なプログラム ·コードを実行可能な汎用コンピュータ 'システムに対して、コンピュータ 'プログラムをコンピュー夕可読な形式で提供する媒体である。媒体は、 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は、本発明のデバイスにおけるメモリ部に格納されるデータ中の公開鍵系パーティション鍵定義プロックのデータ構成を示す図である。図 22は、本発明のデバイスにおけるメモリ部に格納されるデータ中の共通鍵系パーティション鍵定義プロックのデ一夕構成を示す図である。

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

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

図 25は、本発明のデバイスにおけるメモリ部に格納されるデータ中のフアイルの構造のタイプについて説明する図である。

図 26は、本発明のシステムにおいて適用されるアクセス制御チケットとしてのパーティション登録チケット（PRT) のフォーマットを示す図である。図 27は、本発明のシステムにおいて適用されるアクセス制御チケットとしてのファイル登録チケット（FRT) のフォーマットを示す図である。

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

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

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

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

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

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

図 3 8は、本発明のシステムにおけるデバイスマネージャによるデバイスの初期登録処理フロー（その 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 ) である。

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

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

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

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

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

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

図 7 4は、本発明のシステムにおけるファイル登録チケット（F R T ) を適用したファイル生成後のデバイス格納データを説明する図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図 93は、本発明のシステムにおけるデータアップデートチケット（DUT) によるデータ更新処理フローを示す図である。

図 94は、本発明のシステムにおけるデ一夕アップデートチケット（DUT) によるデ一夕更新操作フローを示す図である。

図 95は、本発明のシステムにおけるデ一夕アップデートチケット（DUT) によるデ一夕更新処理例を説明する図である。

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

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

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

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

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

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

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

A 2. デバイスの構成

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

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

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 P T) を利用したアクセス処理各方式における処理手順

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図 2は、デバイス管理エンティティとしてのデバイスマネージャ、デバイスに設定された各パーティションの管理エンティティとして、 2つのパーティションマネージャ 300 A, 30 0 B、デバイスマネージャ 20 0に対して識別コードを付与するコード管理機関 400を示している。さらに、デバイスマネージャ 2 00の管轄する登録局 2 1 0からの公開鍵証明書発行要求に応じて、デバイスマネージャ 200、デバイスマネージャ管轄の各機器（パーティション登録チケヅト（PRT) 発行手段（PRT Issuer) 2 1 0、あるいはデバイス 1 00に対応するデバイス対応公開鍵証明書（CERT-DEV) を発行するデバイスマネージャ対応認証局（ C A (D E V)： Certificate Authority) 6 1 0、パ一テイシヨンマネ —ジャ 300A， 300 B管轄の各機器（ファイル登録チケット（FRT) 発行手段（FRT Issuer) 3 1 0、サ一ビス許可チケット発行手段（S PT) 32 0、チケヅトユーザであるデバイスアクセス機器としてのリーダライタ 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 , 6 3 0と個別に有する構成を示しているが、両機能を持つ唯一の認証局を設けたり、複数のパ一テイシヨンマネージャに対応する共通の認証局とデパイスマネージャ対応認証局を別々に設けたり、その構成は自由である。

デバイスマネージャ 20 0、パーティションマネージャ 3 00A， 30 0 Bは、自己の公開鍵証明書、各マネージャの管理する各機器（チケット発行手段、チケットュ一ザ）の公開鍵証明書、または、デバイス 1 00からの公開鍵証明書発行要求を受理し、受理した発行要求の検証を行ない、検証の後、証明書発行要求を認証局に対して転送する処理を行なうとともに、発行された公開鍵証明書の管理処理を行なう登録局（R A ： Registration Authority) 2 2 0 , 3 30を有する。これら登録局（RA) 2 2 0， 33 0を介して各認証局（ C A ) 6 1 0 , 6 2 0， 630から発行された公開鍵証明書はデバイス 1 00に格納され、デバイス 1 00に対する処理としての例えばパーティションの設定処理、あるいはパ一テイションに対する処理としての例えばファイル設定処理、さらにファイルに対するアクセス処理等の際の相互認証処理、あるいは前述した各チケットの正当性検証処理に使用される。これら公開鍵証明書の発行処理、公開鍵証明書を使用した各処理の詳細については後述する。

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

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

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

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

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

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

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

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

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

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

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

例えば、あるサービス主体（パーティションマネージャ）である鉄道会社の定期券読み取り専用の改札には、上述の定期券用ファイルの区間データ読み取りのみの実行を許可したサービス許可チケット（S PT) のみを格納したデバイスァクセス機器としてのリーダライタを設定して、ユーザが所有するデバイスから区間データの読み取り処理を実行する。例えば、定期券、プリペイド双方の処理を実行する改札のデバイスアクセス機器としてのリーダライタには上述の定期券用ファイルの区間データ読み取りのみの実行を許可したサービス許可チケット（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 OM (Electrically Erasable Programmable ROM)によって構成されるメモリ部 1 0 6 を有する。メモリ部 1 06 (ex. E EPROM) 1 0 6に格納される情報については、後段で詳述する。

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

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

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

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

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

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

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

さらに、デバイスマネージャ 2 0 0は、デバイスに対応するデバイス対応公開鍵証明書（CERT-DEV) を発行する。デバイスマネージャ 2 0 0は、デバイスからの公開鍵証明書発行要求を受理し、受理した発行要求の検証を行ない、検証の後、証明書発行要求を認証局（C A ( D E V ) ： Certif icate Authori ty) 6 1 0に対して転送する処理を行なうとともに、発行された公開鍵証明書の管理処理を行なう登録局（R A ： Regi stration Authority) 2 2 0としての機能を有する。図 7に示すように、デバイスマネージャ 20 0のパーテイション登録チケット (PRT) 発行手段（PRT Issuer) 2 1 0は、制御手段 2 1 1と、データべ一ス 2 1 2を有し、データべ一ス 2 1 2は、パーティション登録チケヅト（P R T) の発行管理デ一夕として、チケットの発行管理用のデータ、例えば、チケット発行先のパーティションマネージャ識別子、チケット識別子、チケットユーザ（e X . リ一ダライタ， P C, e t c )識別子などを対応付けたデータが格納される。また、登録局（RA： Registration Authority) 220は、制御部 22 1、公閧鍵証明書の発行管理用のデータベース 222を有し、公開鍵証明書の発行管理デ一夕として、例えば公開鍵証明書を発行したデバイス識別子、公開鍵証明書の識別子（シリアルナンパ）等を対応付けたデ一夕が格納される。

デバイスマネージャ 20 0のパーティシヨン登録チケット（PRT) 発行手段 (P R T Issuer) 2 1 0の制御手段 2 1 1は、パ一テイションマネージャとのデ —夕通信により、パーティシヨン登録チケット（PRT)の発行処理を実行する。また、登録局（RA： Registration Authority) 22 0の制御手段 22 1は、デバイスに対する公開鍵証明書の発行処理を実行し、この際、デバイスとの通信、デバイスマネージャ対応認証局（CA (D E V)) 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) によって構成される。 R0 M (Read only Memory) 2 1 1 2は、暗号処理プログラム等の実行処理プログラムを記憶したメモリである。 RAM (Random Access Memory) 2 1 1 3は、制御部 2 1 1 1が実行するプログラム、例えばデータベース管理プログラム、暗号処理プログラム、通信プログラム等、実行プログラムの格納領域、またこれら各プログラム処理におけるワークエリアとして使用される。

表示部 2 1 1 4は、液晶表示装置、 C R Tなどの表示手段を有し、制御部 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 18は、ネヅトワーク、ケーブル接続、電話回線等の有線、無線を介した通信のインタフヱ一スとして機能し、ュ一ザのデバイス、パーティションマネージャ、認証局等の各エンティティとの通信ィンタフエースとして機能する。

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

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

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

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

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

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

図 9に示すように、パーティションマネージャ 300のフアイル登録チケット (FRT) 発行手段（FRT 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と、データベース 322を有し、デ一夕ベース 322は、サービス許可チケット（ S P T) の発行管理デ一夕として、チケットの発行管理用のデータ、例えば、チケット発行先のチケットュ —ザ（ex. デバイスアクセス機器としてのリーダライタ， P C, e t c) 識別子、チケット識別子などを対応付けたデータを格納する。

また、登録局（RA ： Registration Authority) 330は、公開鍵証明書の発行管理用のデータベース 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の制御手段 3 3 1は、デバイスに対する公開鍵証明書の発行処理を実行し、この際、デバイスとの通信、パーティションマネージャ対応認証局（CA (PAR)) 620との通信を実行する。これらの処理の詳細については後段で説明する。

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

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

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

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

[ A 6 . 公開鍵証明書]

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

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

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

暗号化、復号化に共通の鍵を用いるいわゆる共通鍵暗号化方式と異なり、公開鍵暗号方式では秘密に保つ必要のある秘密鍵は、特定の 1ユーザが持てばよいため鍵の管理において有利である。ただし、公開鍵暗号方式は共通鍵暗号化方式に比較してデータ処理速度が遅く、秘密鍵の配送、ディジタル署名等のデータ量の少ない対象に多く用いられている。公開鍵暗号方式の代表的なものには R S A ( Rivest- Shamir- 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に公開鍵証明書のフォーマツトの概略を示す。各データの概要について説明する。

証明書のバージョン（versi on) 番号は、公閧鍵証明書フォ一マツトのバージョンを示す。

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

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

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

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

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

利用者公開鍵フィールド（subject Public Key Info) の鍵アルゴリズム (algorithm) と鍵（subject Public key) は、ュ一ザの公開鍵情報としての鍵ァルゴリズム、鍵情報そのものを格納するフィールドである。

オプション領域には、ユーザの属性データ、その他公開鍵証明書の発行、利用に伴うオプショナルデータを記録する。属性データとしては、ユーザの所属グル —プ情報としてのデバイスマネ一ジヤコ一ド（DM C)、パ一ティションマネージャコード（P M C) が記録される。なお、ここでユーザは公開鍵証明書のユーザであり、例えばデバイスマネージャ、パーティションマネージャ、チケットユーザ、チケット発行手段、デバイスなどである。

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

なお、デバイスマネージャがパ一テイション登録チケット発行手段（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 M C ) として設定可能である。なお、これらのコードは後述する各チケット（P R T, F R T， S P Tなど）にも記録される。

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

発行局署名は、公開鍵証明書発行局（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 H A— 1などが用いられる場合もあるし、 DE S— CB Cが用いられる場合もある。この場合は、最終出力値となる MAC (チエツク値： I CVに相当する）がハッシュ値となる。

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

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

P≠Qの時（加算）、

Xc = A^!-X a -X b

Yc二え x(Xa - X c) - Ya

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

P=Qの時（2倍算）、

X c = A^!- 2 X a

Yc = Ax(Xa-Xc)-Ya

λ=( 3 (X a )^J+ a )/( 2 Y a )

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

ステップ S 5で、 c = X V m o 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³+ax + b， 4 a³ + 27 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 1 4で 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 l 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 = (X， —Y) の加算を行うと、人が計算できず、 P + 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 P T ) を適用したデータ処理において、チケットユーザ（e x . デバイスアクセス機器としてのリ一ダライタ）とデバイス間の相互認証、署名生成、検証処理等に適用される。これらの処理の具体例については、後段でフローを用いて説明する。

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

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

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

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

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

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

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

* Manufacture Equipment Code ：カード製造ライン番号

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

* Manufacture Serial 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) のデータ構成を示す。デバイス管理情報ブロック（Devi ce Management Information Block) には以下のデ一夕が格納される。

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

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

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

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

* Free Block Number in Device ：デノ、'イス (Device) 内の空きブロック数 * Partition Number ：現在登録されているパーティション（Partition) 数

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

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

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

* PUB_CA(DEV) Si ze ：認証局 C A ( 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) の公開鍵証明書が格納されているプロックへのポインタ

* CERT— DEV Size ：：認証局 C A (D E V) が発行したデバイス（Device) の公開鍵証明書のサイズ

* CRL—DEV Pointer：デバイス（Device) のリボケ一シヨンリスト（Revocation List) が格納されているブロックへのポインタ

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

* PRTIC (PRT Issuer Category) ：パ一テイション登録チケット（ P R T ) 発行者カテゴリ

*PRTIC Version：パーティション登録チケット（PR T) 発行者カテゴリ（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) は、デバイスに格納された様々なデ一夕の更新処理を実行する際に更新処理を許可し制限するためのアクセス制限チケットであり、前述の PRT, FR 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 RT) の MA C検証用鍵 (Kprt)が格納されているブロックへのポインタ

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

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

* Kdut— DEV卜 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— DEVI, 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.DEVl ：デ一夕アップデートチケット（DUT) の MAC検証用鍵 * Kdut_DEV2 ：データ更新用暗号鍵

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

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

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

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

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

* PARAMJEV ：デパイス（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) の MA C検証用鍵についても、デバイスがチケット検証処理を実行しない構成の場合には格納しない構成としてもよい。

また、 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 ：パーテイシヨン（Partition) 格納先スタートァドレス

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

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

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

次に、パーティション領域の各データについて説明する。パーティション領域は、パーティションマネージャの管理領域である。前述したように、デパイスマネ一ジャの管理するパーティシヨン登録チケット（P RT) 発行手段（PRT Issuer) の発行した PRTチケヅトに基づいて各サービス主体としてのパーティシヨンマネージャが所定の手続き、すなわちパーティション登録チケット（P R 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) の公開鍵のサイズ

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

* PRし 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) ：ファイル登録チケット（FRT) 発行者カテゴリ

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

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

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

図 22は、共通鍵系パ一テイション鍵情報プロック（Partition Key Definition Block(Co匪 on))デ一夕構成を示す。共通鍵系パーティション鍵情報ブロック (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検証用鍵（Kfrt)が格納されているプロックへのポインタ

* Kfrt Size：ファイル登録チケット（FRT) の M A C検証用鍵（Kfrt)のサイズ * Kdut_PAIU-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— PARI, 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. シリアルナンパ： S N) を登録したリポケ一シヨンリス卜 (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 ：双方向個別鍵認証用共通鍵

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

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

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

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

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

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

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

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

* 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 ： F i le Regi stration Ticket)ヽまた、各ファイルに対するアクセスには正当なチケット発行手段（Ti cket I ssuer) の発行したサ一ビス許可チケット（ S P T ： Service Permi ssion Ticket) が必要となる。また、前述のデバイスのメモリ部のデータ説明の欄で簡単に説明したように、デパイス格納データの更新処理にはデータアップデートチケット（DUT) を必要とする。

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

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

パーティション登録チケット（ P R T ： Partition Registration Ticket) は、デバイスに対するパ一テイションの設定登録処理の際に適用されるアクセスコントロールチケットである。正当なデバイスマネージャ管轄下のチケット発行手段 (Ticket Issuer) の発行した P RTを用い、 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) に記述されるコ一ド

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

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

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

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

* 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] フィールドには、公開鍵方式であれば、パーティション登録チケット発行手段（P R T Issuer)の秘密鍵に基づく署名（図 1 2参照）が生成され格納される。デバイスマネージャ自体がパ —ティシヨン登録チケット発行手段（PRT Issuer) を兼ねる場合は、デバイスマネージャの秘密鍵を用いて署名が生成される。署名検証処理（図 1 3参照）の際は、対応の CA (DE 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))

ファイル登録チケット（FRT : 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))

当フィールドは、 [ 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 ：ファイル定義ブロック（Fi le Definition Block) に記載されるサービス許可チケット（SPT) の MAC検証用鍵 Ksptをそのパーティシヨンのファイル登録チケットの MAC検証用鍵 Kfrt で暗号化したデータ Kfrt (Kspt)

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

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

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

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

チケット（Ticket) の正当性検証値（公開鍵方式：署名（Signature) 共通鍵方式： MAC) を記録する [Integrity Check Value] フィールドには、公開鍵方式であれば、ファイル登録チケット発行手段（FRT Issuer)の秘密鍵に基づく署名（図 1 2参照）が生成され格納される。パーティションマネージャ自体がフアイル登録チケッ卜発行手段（FRT issuer) を兼ねる場合は、パーティシヨンマネージャの秘密鍵を用いて署名が生成される。署名検証処理（図 1 3参照）の際は、ファイル登録チケット発行手段の公開鍵が用いられる。従って、チケット検証を実行するデバイスは、チケット受領に際し、または前もってファイル登録チケヅト発行手段（FRT Issuer) (ex, パーティションマネージャ）の公開鍵（公開鍵証明書）を取得することが必要である。ファイル登録チケット（F R T) 発行手段（FRT Issuer) の公開鍵証明書 (CERT_FRTI) の検証の後、公開鍵証明書（CERT_FRTI) から取り出したファイル登録チケット（ F R T)発行手段（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 P Tに記録された手続きに従ってチケットユーザ（e x. デバイスアクセス機器としてのリーダライタ）によりデバイスにアクセスすることで、 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) のサイズ

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

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

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

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

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

なお、サービス許可チケット（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) を、パーティシヨンマネージャが兼ねる構成においては、サービス許可チケット（S PT) 発行手段 (SPT Issuer) のコードは、パーティションマネージャコード（PMC) として設定することが可能である。

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

チケット（Ticket) の正当性検証値（公開鍵方式：署名（Signature) 共通鍵方式： MAC) を記録する [Integrity Check Value] フィールドには、公開鍵方式であれば、サービス許可チケット発行手段（ S P T Issuer)の秘密鍵に基づく署名（図 1 2参照）が生成され格納される。パーティションマネージャ自体がサ —ビス許可チケット発行手段（ S P T Issuer) を兼ねる場合は、パーテイシヨンマネージャの秘密鍵を用いて署名が生成される。署名検証処理（図 1 3参照）の際は、サービス許可チケット（S PT) 発行手段（SPT Issuer) の公開鍵が用いられる。従って、チケット検証を実行するデパイスは、チケット受領に際し、または前もってサービス許可チケット発行手段（ S P T Issuer) (e . パーティシヨンマネージャ）の公開鍵（公開鍵証明書）を取得することが必要である。サービス許可チケット（ 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に示すアクセスモードは一例であり、この他にもデバイスに格納されるデータに応じたアクセスモ一ドを設定することができる。

サービス許可チケット（S PT) に設定された [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 and o mの場合において、アクセスモ一ドが読み出し（Re ad) である場合、デパイスが許容可能なコマンドは [R e a d] のみとなる。また、同様にファイル構造が Rand omの場合において、アクセスモ —ドが暗号化読み出し（R e a d) である場合、デバイスが許容可能なコマンドは暗号化読み出し [E n c Re ad] のみとなる。

また、ファイル構造が 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 R e c e i p t ] となる。

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

図 30に示す他にも、様々なアクセスモード、コマンドの組合わせが可能であり、実際のデパイスの利用形態に応じて設定されることになる。

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

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

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

このように、 Group of Target File ：アクセスを許すファイル（File) のグループ（Group) を定義してチケットに記録することにより、パーティション内の複数のファイルに対するアクセスを唯一のサービス許可チケット（S P T) で許可することが可能となる。なお、上述のサービス許可チケット（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 Τに記録された手続きに従ってチケヅトュ一ザ（ex. デバイスアクセス機器としてのリーダライタ）によりデバイスにアクセスすることで、 DUTに記録された制限内でデータ処理を実行することができる。

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

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

* Ticket Type：チケヅト（Ticket) の種別（DUT (D E V) /DUT ( P A R)

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

* Ticket Issuer ：デバイス /パーティションマネージャの識別子。チケット (Ticket) の種別（Ticket Type) が DUT (DEV) なら DMC、 DUT (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が格納される。認証不要の場合は格納は必須ではない。

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

* Encrypted F'lag ：更新されるデータが暗号化されているか否か（暗号化： 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 (D E V) 発行手段（DUTIssuer) のコード（チケットュ一ザ（Ticket User¹)) は、デバイスマネージャコード（DMC) として設定することが可能である。また、データアップデートチケット -DUT (PAR) 発行手段（DUT Issuer) を、パ一ティションマネージャが兼ねる構成においては、データアップデ一トチケヅトー DUT (PAR) 発行手段（DUT Issuer) のコードは、パーティションマネ —ジヤコ一ド（PMC) として設定することが可能である。

チケット（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) の署名検証が可能となる。

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

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

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

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

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

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

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

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

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

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

B 5. サービス許可チケット（S P T) を利用したサービス（ファイルァクセス）処理 B 6. デ一夕アップデートチケット（DUT) を利用したデバイスのデ一タ更新処理

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

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

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

例えばデバイスとデバイスに対して処理を実行するチケットユーザ（ex. デバイスアクセス機器としてのリーダライ夕）との間で公開鍵証明書を用いた相互認証処理が実行され、双方の正当性が確認されたことを条件としてパーティション登録チケット（PRT) を利用したパーティションの設定、ファイル登録チケット（FRT) を利用したファイル設定、さらにサ一ビス許可チケット（S P T) を利用したデータアクセスなどの様々な処理が実行される。また、相互に転送されるデータには必要に応じて電子署名が付加され、検証が実行される。また転送デ一夕の暗号化、復号処理も必要に応じて実行されることになる。図 34は、デバイスの製造から、利用に至るまでの流れを概略的に示した図である。これらの各処理については、フローを参照して後段で詳細に説明するが、全体的な処理の理解のために、図 34に示す各段階について簡単に説明する。

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

2. 次に、デバイスマネージャはユーザに対するデバイスの提供前に、自己の I D、認証局の公開鍵（P UB C A (D E V)) など、デバイス管理情報（Device

Management Information (図 1 5参照））、デバイス鍵（Device Key (図 1 8参照））などの情報をメモリに格納する。

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

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

5. デバイスのメモリ部にパーティションを設定し、サービスを提供しようとするサービス主体（パーティションマネージャ）は、パーティションの設定をデパイスマネージャに要求し、許諾を受けるとともにパーティション登録チケット (PRT) を受領する。また、デバイスとの通信処理において使用する認証局の公開鍵（PUB C A (PAR)) を指定する。

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

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

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

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

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

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

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

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

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

製造情報プロック（M I B) 内の書き込み（Writable) フラグを受信（S 1 0 2) した登録装置は、書き込みフラグ（WritableFlag) が書き込み可（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 1 04 ) して M I B書き込みコマンドとともに、 M I Bデータをデバイスに送信（ S 1 05 ) する。

M I B書き込みコマンド、および M I Bデータを受信（ S 1 23 ) したデパイスは、 MI B書き込みフラグ（Writable Flag) を検証（ S 1 24 ) し、書き込みフラグ（Writable Flag) が書き込み可（ 0 x f f f f ) に設定されていない場合は、以下の製造情報ブロック（M I 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 0 6) した登録装置は初期登録完了コマンドをデバイスに送信（S 1 0 7) し、初期登録完了コマンドを受信 ( S 1 27 )したデパイスは製造情報プロック（M I B： Manufacture Information Block) の書き込みフラグ（Writable Flag) を書き込み不可（ 0 x 0000 ) にセット（S 1 28) し、書き込み終了通知を登録装置に送信（S 1 29) する。書き込み終了通知を受信（S 1 08 ) した登録装置は、デバイスに対して製造情報ブロック（MI B ： Manufacture Information Block (図 1 4参照））の書き込みフラグ（Writable Flag) の読み出しコマンドを送信（S 1 09) する。デバイスはコマンドを受信（S 1 30) すると、デバイスのメモリ部の製造情報プロヅク（M I 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 00 0 ) に設定されていない場合は、正常な M I Bデータ書き込み処理が終了していないことを示し、エラ一として処理を終了する。書き込みフラグ（Writable Flag)が書き込み不可（ 0 x 0 00 0 ) に設定されている場合は、正常な M I Bデータ書き込み処理が終了したものとして処理を終了する。

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

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

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

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

まず、ステップ S 2 0 1において、デバイスの識別子 I D mの読み出し（Read) コマンドをデバイスに出力する。デバイスはコマンドを受信（S 2 1 1 ) し、デバイスの識別子 I Dmを登録装置に送信（S 2 1 2) する。

デバイスの識別子 I D mを受信（ 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 14) する。

デバイス管理情報ブロック（DM I B) 内の書き込みフラグ（Writable Flag) を受信（S 204 ) した登録装置は、書き込みフラグ（Writable Flag) が書き込み可（ 0 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) および DMCバ一ジョンの書き込み（DMC Write) コマンドをデバイスに送信（S 206) する。このコ一ドは、コード管理機関（図 1〜図 3参照）によりデバイスマネージャに対して予め割り当てられたデータである。

DMC Writeコマンドを受信（ S 2 1 5 ) したデバイスは、 DM I B書き込みフラグ（Writable Flag) を検証（S 2 1 6) し、書き込みフラグ（Writable Flag) が書き込み可（ O x f f f f ) に設定されていない場合は、以下のデバイス管理情報ブロック（DM I B ： Device Management Information Block) の書き込み処理は実行できず、エラ一として終了する。書き込みフラグ（Writable Flag) が書き込み可（O x f f f f ) に設定されている場合は、受信したデバイスマネージヤコ一ド（DMC) および DMCバ一ジョンを DMI B領域に書き込む（S 2 1 デバイスマネージャコード（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 )。さらに、デバイスは、 DMI B領域のデバイス空きブロック数情報領域（Free Block Number in Device) に TB— 4を書き込む（S 222 )。 T Bはデバイス総ブロック数（Device Total Block Number) を意味する。なお T B— 4の 4ブロックは、製造情報ブロック（M I B ： Manufacture Information Block), デバイス管理情報ブロック（DM I B ： Device Management Information Block)、公開鍵系デバイスキ一定義ブロック（D KD 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 2 25 ) する。書き込み処理完了通知をデバイスから受信（ S 20 9 ) した登録装置は、次に、デバイス認証に共通鍵を用いるか否かを判定（S 23 1 ) する。認証処理については、後段で詳細に説明するが、公開鍵認証方式、共通鍵認証方式のいずれかを実行する構成が可能であり、デバイスマネージャは、デバイスに必要な認証方式を設定することが可能となる。デバイスが共通鍵認証を実行するデバイスであれば、デバイスマネージャは共通鍵認証に必要な情報（ex. 認証鍵生成用のマス夕一鍵他）をデバイスにセットし、デバイスが共通鍵認証を実行しないデバイスであれば、これらの情報をデバイスに格納しないことになる。デパイスマネージャは、デバイスの採用する認証方式に応じて共通鍵認証、公開鍵認証のいずれか、あるいは両方式を実行可能なデータをデバイスに設定する。

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

デバイス認証に共通鍵を用いる場合、ステップ S 232において登録装置は、共通鍵認証データ書き込みコマンドとして、 MKauth— DEV_A：双方向個別鍵認証用マスタ一鍵、 Kauth— DEV— B：双方向個別鍵認証用共通鍵、 IRL— DEV：排除デバイス (Device)のデバイス識別子（ I D )を登録したリボケ一シヨンリスト（Revocation List (Device ID)、およびこれらのバ一ジョン情報をデバイスに送信する。ステップ S 24 1でデバイスは、上述の書き込みコマンドを受信し、ステップ S 242において、 DM I Bの書き込みフラグ（Writable Flag) が書き込み可であることを確認して受領データをデパイス鍵領域（図 1 8参照）に書き込む（S 243 )。次にデータ書き込みによって生じたポインタ、サイズ、デバイス内のフリーブロック数の調整を実行（S 244) し、書き込み終了通知を登録装置に送信（S 245 ) する。

書き込み終了通知を受信（S 233 ) した登録装置は、ステップ S 234においてデバイス認証に公開鍵を用いるか否かを判定する。図 37に示すように、デバイス認証に公開鍵を用いる場合、ステップ S 235 ~ S 2 39、 S 246〜S 254を実行し、デパイス認証に公開鍵を用いない場合、これらのステップは省略される。デバイス認証に公開鍵を用いる場合、ステップ S 2 3 5において登録装置は、公開鍵認証データ書き込みコマンドとして、 PUB_CA(DEV) ：デパイスマネージャ対応公開鍵を発行する認証局 C A(D E V)の公開鍵、 PARAM_DEV：デバイス（Device) の公開鍵パラメ一夕、 CRL— DEV：排除デパイス（Device)の公開鍵証明書識別子（ e X . シリアルナンパ： S N) を登録したリボケ一シヨンリスト（Revocation List (Certificate), およびこれらのバ一ジョン情報をデバイスに送信する。

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

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

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

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

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

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

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

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

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

書き込み終了通知を受信（ S 263 ) した登録装置は、ステップ S 264において P R T検証に公開鍵を用いるか否かを判定する。図 38に示すように、 PR T検証に公開鍵を用いる場合、ステップ S 265〜 S 2 6 6、 S 276〜S 28 2を実行し、 P R T検証に公開鍵を用いない場合、これらのステップは省略される。 P R T検証に公開鍵を用いる場合、ステップ S 26 5において登録装置は、 Ρ R Τ検証データ書き込みコマンドとして、 PRTIC (PUT Issuer Category) ：パ一テイション登録チケット（P RT) 発行者カテゴリ、 PUB_CA(DEV)：デバイスマネ一ジャ対応公開鍵を発行する認証局 C A (DEV) の公開鍵、 PARAM_DEV：デバイス (Device) の公開鍵パラメータ、 CRL— DEV：排除デバイス（Device) の公開鍵証明書識別子（e x . シリアルナンパ： S N ) を登録したリボケ一シヨンリスト (Revocation List (Certificate), およびこれらのパージョン情報をデバイスに送信する。

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

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

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

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

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

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

データ更新に共通鍵を用いる場合、ステップ S 2 92において登録装置は、デ

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

ステップ S 3 0 1でデバイスは、上述の書き込みコマンドを受信し、ステップ

S 3 02において、 DM I Bの書き込みフラグ（Writable Flag) が書き込み可であることを確認して受領データをデバイス鍵領域（図 1 8参照）に書き込む（ S

30 3 )。次にデータ書き込みによって生じたポインタ、サイズ、デバイス内のフリーブロック数の調整を実行（S 304 ) し、書き込み終了通知を登録装置に送信（ S 305 ) する。

書き込み終了通知を受信（ S 293 ) した登録装置は、ステップ S 2 94において、デバイスが公開鍵方式を用いたデータアップデ一トチケット（DUT： Data

Update Ticket) を使用したデ一夕更新処理をサポ一トするか否かを判定する。図

3 9に示すように、公開鍵方式をサポ一トする場合、ステップ S 2 95〜S 29

6、 S 306〜S 3 1 0を実行し、公開鍵方式をサポ一トしない場合、これらのステツプは省略される。公開鍵方式をサポートする場合、ステップ S 295において登録装置は、デ一夕アップデートチケット（DUT ： Data Update Ticket) 発行者コード書き込みコマンドとして、 DUTIC_DEV (DUT Issuer Category) ：データアップデートチケヅト（DUT ： Data Update Ticket) 発行者カテゴリ、およびバージョン情報をデバイスに送信する。

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

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

ステップ S 332において、相互認証、パーティション登録チケヅト（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 335 ) すると、デバイスのメモリ部のデバイス管理情報ブロック（DM I B) 内の書き込みフラグ（Writable Flag) を登録装置に送信（S 33 6 ) する。

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

デバイス製造エンティティ（Manufacture)の登録装置による初期登録（図 35の処理フロー）および、デバイスマネージャによる初期登録処理（図 3 6〜図 40 の処理フロー）が完了した状態のデバイスのメモリ内格納データ構成例を図 4 1 に示す。図 4 1は、図 6、図 1 4乃至図 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) には、図 1 4を用いて説明したように、デバイスの固有情報としてのデバイスコ一ド他が書き込まれる。この製造情報ブロック（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))、 CRLJEV ：排除デバイス (Device) め公開鍵証明書識別子（e x. シリアルナンパ： SN) を登録したリボケ一シヨンリスト（RevocationList (Certificate)についても、デバイス発行時点でリポーク（排除）されたデバイスが存在しない場合、あるいは他のソースを使用してリボケ一シヨンリストを取得する構成とする場合には、リボケ一ションリストを格納しない構成としてもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以上の処理により、デバイスは、デバイス対応公開鍵証明書（C E RT 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 D E V) が格納される。デバイス対応公開鍵証明書（CERT D E V)の発行前には、この領域には、デバイスが生成した公開鍵（P UB D E V) が格納され、デバイス対応公開鍵証明書（CERT D E V) を受信すると、デパイス対応公開鍵証明書（CERT D E V) によって上書き処理がなされる。なお、この上書き処理によりポインタ、サイズ、管理データがある場合は必要な変更処理を実行する。

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

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

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

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

図 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つの好ましいデータ転送方式である。

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

によって決定される。

認証処理に失敗した場合（S 402 , S 4 1 1で N o) は、相互が正当な機器、デバイスであることの確認がとれないことを示し、以下の処理は実行されずエラ —として処理は終了する。

認証処理に成功すると、パーティション作成 · 削除装置は、デバイスに対してパーティション登録チケット（P R T ： Partition Registration Ticket) を送信する。パ一ティション登録チケット（PRT) は、パーティションマネージャの要求により、デパイスマネージャの管理するパーティション登録チケット（PR T) 発行手段（PRT Issuer) によりパーティションマネージャに対して発行されるチケットである。パーティション登録チケット（P R T) は、デパイスに対するアクセス制御チケットであり、先に説明した図 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) は、パーティション登録チケット（P R T) 受理エラ一をパーティシヨン作成 · 削除装置に通知（S 4 1 8) する。チケヅトおよび利用者の正当なことが確認できた場合（S 4 1 4で Ye s) は、受信したパーティション登録チケット (P R T) に記述されたルールに従いデバイス内のメモリ部におけるパ一ティシヨンの生成、または削除処理を実行する。この処理の詳細についても別フローを用いて後段で詳述する。

パーティション登録チケット（P R T) の記述に従って、パーティションの生成または削除処理に成功（S 4 1 6で Ye s) すると、 P R T受理成功をパ一テイション作成 · 削除装置に通知（S 4 1 7 ) する。一方、パーティションの生成または削除処理に失敗（S 4 1 6で N o) した場合は、 PRT受理エラ一をパ一ティシヨン作成 . 削除装置に通知（S 4 1 8) する。

パーティション作成 . 削除装置は、 P R T受理結果を受信（ 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で Ye s)であり、処理がパーティション削除である場合はセッションクリアコマンドの送受信（S 407 , S 42 0 ) を実行し、デバイス側に生成した認証一ブルを破棄（S 42 1 ) し、処理を終了する。認証テーブルは、ステップ S 40 1 , S 4 1 0の相互認証処理において生成されるテーブルであり、その詳細は後述する。

このようにパーティション登録チケット（P RT) を利用して、デバイス内に新たなパーティションの生成、または生成済みのパーティションの削除が実行される。以下、当処理に含まれる相互認証処理（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 Registration Ticket)、サ一ビス許可チケット（ S P T ： Service Permission Ticket)、データアップデートチケット（DU T ： Data Update Ticket) を使用したデバイスアクセス処理においても適宜必要に応じて行われる処理である。

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

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

決定した認証方式を A ( 1 ) 〜A ( n) とする。パーティション登録チケット (PRT) を適用したパーティションの設定登録、あるいは削除処理においては様々な認証処理態様が設定される。例えばパーティシヨンの設定登録についてはデバイスを対象とするデバイス認証を必要とし、パーティシヨン削除の場合にはデバイス認証と削除対象となるパーティション認証の双方を必要とするなどである。このように処理に応じていずれか一方の認証、または両者の認証を必要とする設定をパーティション登録チケット（PRT) に記述することができる。 PR T利用処理において必要とする認証方式については、パーティション登録チケット（PRT) の [Authentication Type] に記述され、認証装置は、パ一ティション登録チケット（PRT) の利用に必要な認証方式をチケットから読み出して決定し、認証処理手順を 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 46 3において、デパイスマネージャ対応認証局 (C A (D E V))の発行した公開鍵証明書を用いた相互認証および鍵共有処理が実行される。

公開鍵方式による相互認証および鍵共有処理について、図 5 0を用いて説明する。図 5 0は、公開鍵暗号方式である 1 60ビット長の楕円曲線暗号（E C C) を用いた相互認証シーケンスを示している。図 50では、公開鍵暗号方式として E C Cを用いているが、公開鍵暗号方式の他方式を適用することも可能である。また、鍵サイズも 1 60ビットでなくてもよい。図 50において、まず Bが、 6 4ビットの乱数 R bを生成し、 Aに送信する。これを受信した Aは、新たに 64 ビットの乱数 R aおよび標数 pより小さい乱数 Akを生成する。そして、ベースポイント Gを Ak倍した点 Av二 AkxGを求め、 Ra、 b, A v (X座標と Y 座標）に対する電子署名 A. S i gを生成し、 Aの公開鍵証明書とともに Bに返送する。ここで、 R aおよび 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 xB Vを計算し、これら点の X座標の下位 64ビットをセッション鍵として以降の通信に使用する（共通鍵暗号を 64ビット鍵長の共通鍵暗号とした場合）。もちろん、 Y座標からセヅション鍵を生成してもよいし、下位 64ビットでなくてもよい。なお、相互認証後の秘密通信においては、送信データはセッション鍵で暗号化されるだけでなく、電子署名も付されることがある。

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

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

図 49に戻りフローの説明を続ける。ステップ S 453 , S 46 3において上述のような相互認証、鍵共有処理に成功すると、デバイスは、ステップ 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)) を参照して判定する。デバイス認証装置は、リポケ一シヨンリスト（CRL— 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 ： Di stingui shed Name)、シリアルナンパ一、カテゴリ一がテープルに格納され、共通鍵認証の場合は、セッション鍵 K s e sと、通信相手（デパイスアクセス機器としてのリ一ダライタ）の識別子（ I D R W ) ガ格納される。認証テーブルはセッションのクリァ時点で破棄される。デバイスはテーブルの情報を参照することによってデバイスおよび各パーティションの認証状態を確認することができ、使用すべきセッション鍵の確認が可能となる。

一方、図 5 2は、デバイスアクセス機器としてのリーダライタ側の認証テ一ブルを示している。この例もデバイス認証、およびパーティション認証としてのパ —テイシヨン 1 , 2の認証が終了した時点の認証テーブルの例である。基本的構成は、デバイス内の認証テ一ブルと同様であり、グループ（Group) として、デバイス認証の場合はデバイスマネージヤコ一ド（D M C )、パーティシヨン認証の場合はパーティションマネージャコード（P M C ) が記録され、実行された各認証方式によってそれそれのデータが格納される。公開鍵認証方式の場合は、前述したようにセッション鍵 K s e s と、通信相手（デバイス）の公開鍵証明書中の識別名（D N ： Di stinguished 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 457、 S 468において、マスタ一鍵を使用した相互認証および鍵共有処理が実行される。

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

まず、 Bが 64ビットの乱数 R bを生成し、 R bおよび自己の I Dである I D bを Aに送信する。これを受信した Aは、新たに 64ビットの乱数 R aを生成し、双方向個別鍵認証用マスタ一鍵 MKbによる I D bの D E 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で復号する。復号して得られた Ra、 Rb、 I D a , I Dbの内、 Rbおよび I Dbが、 Bが送信したものと一致するか検証する。この検証に通った場合、 Bは Aを正当なものとして認証する。

次に Bは、セッション鍵として使用する 64ビットの乱数 K s e sを生成し、鍵 Kb、 Kaを用いて、 Rb, Ra， I Db, I D a , K s e sの順に、 DE S の C B 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 e v 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を用いて、 R a, Rb， I D rwの順に、暗号アルゴリズムとして、例えば D E S— C B Cモードでデ一タを暗号化し、自己の識別子 I Dmとともにデバイスアクセス機器としてのリーダライタ（R/W) に返送する。

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

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

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

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

図 49に戻りフローの説明を続ける。ステップ S 457 , 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参照）に保存する。

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

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

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

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

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

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

ステップ 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 ： D i stingui shed Name)、シリアルナンパ一、カテゴリーをパーティションマネージャコード（P M C ) をキーとして対応付けた認証テーブルに保存する。この結果、例えば図 5 1に示す認証テーブルがデバイス内に生成され、図 5 2に示す認証テ一ブルがパーティション認証装置としてのデパイスアクセス機器としてのリーダライタ（P Cも可）に生成される。図 5 1、図 5 2は、デバイス認証、およびパーティション認証としてのパーティション 1 , 2の認証が終了した時点のデバイス内およびデバイスアクセス機器としてのリーダライタ内に生成される認証テーブルの例である。

パーティション認証の場合はパーティションマネージャコード（P M C ) が記録され、実行された各認証方式によってそれそれのデ一夕が格納される。公開鍵認証方式の場合は、前述したようにセッション鍵 K s e s と、通信相手の公開鍵証明書中の識別名（D N ： Di stingui shed 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、図 54を用いて説明したシ一ケンスと同様であるので、説明を省略する。ただし、パーティション認証の場合に適用する鍵は、パーティション鍵定義ブロック（図 22参照）に定義され、 ) —テイシヨン鍵領域（図 2 3参照）に格納された双方向個別鍵認証用共通鍵（Kauth — PAR_B)、および双方向個別鍵認証用マスタ一鍵（MKauth— PAR_A) である。

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

リポークされていない場合は、ステップ S 5 0 5において、相互認証および鍵共有処理において生成したセッション鍵 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 D m ) をパーティションマネージャコード（D M C ) をキ一として対応付けた認証テーブル（図 5 2参照）に保存する。

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

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

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

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

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

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

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

チケットタイプがパーティション登録チケット（ 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) /共通鍵方式（Common)))の設定が公開鍵方式（Public)であるか否かを判定する。

正当性検証値の種別（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) の検証処理である。

前述したように、パーティシヨン登録チケット（P R T)発行手段（PRT Issuer) の発行したチケット（Ticket) を、チケットユーザに対して送信する際には、公開鍵方式の場合、パーティシヨン登録チケット（P R T) 発行手段（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) が改竄されたものでない正当な公開鍵証明書（CERT) であるか否かが判定される。

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

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

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

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

以上、（ 1 ) チケット発行者（Ticket Issuer) の公開鍵証明書（CERT) が改竄されたものでない正当な公開鍵証明書（CERT)であること、（2)チケット発行者（Ticket Issuer) の公開鍵証明書（CERT) のオプション領域に記録されたコードと、デバイス内の DKDB (Device Key Definition Block) (PUB) に記録されたチケット発行手段コ一ド（P RT 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)))の設定が共通鍵方式（Co匪 on)であると判定された場合は、ステップ S 5 14に進み MAC (Message Authentication Code) 検証を実行する。デバイスは、デバイスのデバイス鍵領域（図 1 8参照）に格納されたパーティション登録チケット（P R T) の M A C検証用鍵： Kp r tを使用してチケットの MAC検証処理を実行する。

図 59に D E S暗号処理構成を用いた MA C値生成例を示す。図 5 9の構成に示すように対象となるメッセージを 8バイト単位に分割し、（以下、分割されたメヅセージを M l、 Μ2、 · · ·、 ΜΝとする）、まず、初期値（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と受信チケット（PRT) に格納された I CVとを比較して一致していればチケットの正当性ありと判定し、不一致の場合はチケット改竄ありと判定し、チケットを利用した処理を中止する。

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

図 57のフローに戻り、チケットの正当性と利用者チェック処理について説明を続ける。ステップ S 5 1 1において、チケヅトタイブがパ一ティション登録チケヅト（P R T ： PartitionRegistration 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) の正当性検証値の種別（公開鍵方式（Publ ic) / 共通鍵方式（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発行手段の公開鍵証明書 (CERT_FRTI) の属性（Attribute) は、、ファイル登録チケット（FRT) 発行手段（FRT Issuer) の識別子（FRTIC)と一致する。

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

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

公開鍵証明書には、図 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等のチケットユーザ、チケット発行手段）の公開鍵証明書識別子（e x. シリアルナンパ： S N) を登録したリポケ一ションリスト（Revocation List (Certificate))を参照して、チケット発行手段（Ticket Issuer) がリポークされていないかを判定する。

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

以上、（ 1 ) チケット発行者（Ticket Issuer) の公開鍵証明書（CERT) が改竄されたものでない正当な公開鍵証明書（ C E R T)であること、（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)))の設定が共通鍵方式（Common)であると判定された場合は、ステップ S 5 1 8に進み MAC (Message Authentication Code) 検証を実行する。デバイスは、デバイスのパーティション鍵領域（図 23参照）に格納されたファイル登録チケット（FRT) の MAC検証用鍵： 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のファイル登録チケット（FRT) のフォーマットに関する記述において説明したように、 FRTの I CV (Integrity Check Value) フィールドに格納されている。デバイスが生成した I CVと受信チケット（FRT) に格納された I CVとを比較して一致していればチケットの正当性ありと判定し、不一致の場合はチケット改竄ありと判定し、チケットを利用した処理を中止する。

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

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

サービス許可チケット（S PT) 発行手段（SPT Issuer) の発行したチケット (Ticket) を、チケットユーザに対して送信する際には、公開鍵方式の場合、サ —ビス許可チケット（ S R T)発行手段（SPT Issuer)の公開鍵証明書（CERT_SPTI) も一緒にデバイスに送信される。なお、 S P T発行手段の公開鍵証明書 (CERT_SPTI) の属性（Attribute) は、サービス許可チケット（S P T) 発行手段（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 PT) が正当なチケット発行手段によって発行されたチケットであることを確認する。

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

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

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

また、ステップ S 520において、チケットに記述された Integrity Check Type (チケット（Ticket) の正当性検証値の種別（公開鍵方式（Public) /共通鍵方式 (Co匪 on)))の設定が共通鍵方式（Common)であると判定された場合は、ステップ S 522に進み MAC (Message Authentication Code) 検証を実行する。デバイスは、デバイスのファイル定義ブロック（図 24参照）に格納されたサービス許可チケット（S P T) の M A C検証用鍵： K s p 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 C Vは、図 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 P T ： Service Permission Ticket) でないと判定された場合は、ステップ S 52 3においてチケットタイプを検証しチケヅトがデータァップデ一トチケット- D E V(D UT ： Data Update Ticket(DEV)) (図 32参照）であるか否かを判定する。データアップデートチケット（DUT) は前述したようにデパイスのメモリ部に格納された各種データの更新処理を実行する際のアクセス許可チケットであり、デバイスマネージャの管理データを更新する処理に適用するデ一夕ァップデ一トチケット- DEV (DUT (D E V)) とパーティションマネージャの管理デ一夕を更新する処理に適用するデータアップデートチケット- PAR (DUT (PAR)) とがある。

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

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

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

データァヅプデ一トチケット- D E V (D U T (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 CA (D EV) を用いて検証する。署名生成、検証は、例えば先に説明した図 1 2、図 1 3のフローに従った処理として実行される。この署名検証により、チケット発行者の公開鍵証明書（C ERT) が改竄されたものではない正当な公開鍵証明書（CERT) であるか否かが判定される。

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

公開鍵証明書には、図 1 1の公開鍵証明書の説明の欄で記述したように、各チケット（PRT， FRT、 S PT、 DUT) の発行手段であるチケット発行手段 (Ticket Issuer) の所属コード、この場合、 DUT I C (DUT Issuer Code) が記録されている。このォプション領域のコ一ドとデバイス内の D K D 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 (D U T (D E V)) (図 32参照）に記録された署名、すなわち Integrity Check Value (チケット（Ticket) の正当性検証値（公開鍵方式：署名（Signature)) の検証を実行し、チケットが改竄されていないかを確認する。署名検証は、先の公開鍵証明書の署名検証と同様、例えば図 1 3のフローと同様のシーケンスに従って実行される。

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

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

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

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

なお、デパイスは、デバイスのデバイス鍵領域（図 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 (デ一タ更新用暗号鍵）のペアよりも新しいパ一ジョンのものに維持される。つまり、 Kdut_DEVl と、 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 C Vは、図 32のデ一タァップデートチケット（DUT) のフォーマットに関する記述において説明したように、データアップデ一トチケット（DUT) の I CV (Integrity Check Value) フィ一ルドに格納されている。

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

ステップ S 5 23において、チケットタイプがデ一夕ァップデートチケット- D E V (DUT (D E V)) でないと判定された場合は、チケットは、データアツプデートチケヅト- PAR (DUT (PAR)) (図 32参照））であると判定される。データアップデ一トチケット- PAR (DUT (PAR)) は、パーティションマネージャの管理データを更新する処理に適用するチケヅトである。この場合、ステップ S 5 29において、チケットに記述された Integrity Check Type (チケット（Ticket) の正当性検証値の種別（公開鍵方式（Public) /共通鍵方式（Co皿 on))) の設定が公開鍵方式（Public)であるか否かを判定する。

正当性検証値の種別（Integrity Check Type) が公開鍵方式（Public)である場合、ステップ S 530に進み、各種処理を実行する。ステップ S 530で実行する処理は、まず、パーティションマネージャ対応認証局（CA (PAR)) の公開鍵 PUB CA (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)と一致する。

さらに、ステップ S 5 3 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 KD B (PUB)

(Pqrtition Key Definition block) に記録されたチケット発行手段コード (DUTIC:DUT Issuer Category) (図 2 1参照）の一致を確認しすることで、受信チケヅト（DUT) が正当なチケット発行手段によって発行されたチケットであることを確認する。

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

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

以上、（ 1 ) チケット発行者（Ticket Issuer) の公開鍵証明書（C E R T) が改竄されたものでない正当な公開鍵証明書（ C E R T) であること、（2 ) チケット発行者（Ticket Issuer) の公開鍵証明書（C E R T) のオプション領域に記録されたコードと、デバイス内の P KD B (PU B) (Pqrtition Key Definition block) に記録されたチケット発行手段コード（MTIC_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— PARI (データアップデートチケット（DUT) の MAC検証用鍵）または、 Kdut_PAR2 (データ更新用暗号鍵）である場合は、ステッブ S 5 3 3において、パーティション鍵領域（図 2 3参照）に格納された Kdut_PAR3 (データアップデ一卜チケット（DUT) の MAC検証用鍵）を用いて M A C検証処理を実行し、データアップデ一トチケット- PAR(DUT(PAR)) に記述された Old Data Code (更新される古いデータのコード）の示すデータがパーティション鍵領域（図 23参照）に格納された Kdut_PARl (データアップデ —トチケット（DUT) の MA C検証用鍵）または、 Kdut— PAR2 (デ一夕更新用暗号鍵）でない場合は、ステップ S 532において、パ一ティション鍵領域（図 2 3参照）に格納された Kdut_PARl (デ一夕アップデートチケット（DUT) の M AC検証用鍵）を用いて MAC検証処理を実行する。

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

改竄のないことが保証された例えばデータ送信側がデータ生成時に生成した I C V (Integrity Check Value) と、デ一夕受信側が受信デ一夕に基づいて生成した I CVとを比較して同一の I CVが得られればデータに改竄のないことが保証され、 I CVが異なれば、改竄があつたと判定される。改竄のないことが保証された例えばデータ送信側がデータ生成時に生成した I C Vは、図 32のデータァップデートチケット（DUT) のフォーマットに関する記述において説明したように、データァップデ一トチケット（DUT) の I CV (Integrity Check Value) フィ一ルドに格納されている。

デバイスが生成した I C Vと受信チケットであるデータアツプデ一トチケット - 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 PT，または DUT) の Authentication Flag (チケット（Ticket) の利用処理においてデバイス（Device) との相互認証が必要か否かを示すフラグ）をチエツクする。フラグが認証不要を示している場合は、処理を実行することなく終了する。

ステップ S 54 1におけるフラグチェック処理において、フラグが認証必要を示している場合は、ステップ S 542に進み、チケットユーザ（デバイスに対するチケットを適用した処理を実行しょうとするデバイスアクセス機器としてのリ —ダライタ、 P C等）の所属（グループ）をキーとして認証テーブル（図 5 1参照）を参照する。

次に、ステップ S 5 4 3において、受信チケットの Authentication Type (デパイス（Device) の相互認証のタイプ（公開鍵認証、または、共通鍵認証、または、いずれでも可（Any) ) を記録したデータ）をチェックし、いずれでも可（Any) である場合、ステップ S 5 4 4に進み、ステップ S 5 4 2でチェックしたグループの相互認証デ一夕が認証テーブル（図 5 1参照）に格納されているか否かを判定する。テ一ブルに対応グループの相互認証情報が格納され、チケットユーザ（デバイスに対するチケットを適用した処理を実行しょうとするデバイスアクセス機器としてのリ一ダライタ、 P C等）とデパイス間の相互認証済みであることが判定されれば、チケット利用者（e x . デパイスアクセス機器としてのリーダライ夕）の正当性が確認されたものとして処理を利用者チェック成功と判定して終了する。認証テーブル（図 5 1参照）に対応グループの相互認証情報が格納されていない場合は、利用者チェックが未了であると判定され、エラ一終了とする。ステップ S 5 4 3において、受信チケヅトの Authentication Type (デバイス (Device) の相互認証のタイプ（公開鍵認証、または、共通鍵認証、または、いずれでも可（Any) ) を記録したデータ）がいずれでも可（Any) でない場合、ステッブ 5 4 5において、 Authentication Type が公開鍵認証であるか否かを判定する。

Authentication Type が公開鍵認証である場合、ステップ S 5 4 6に進み、ステヅプ S 5 4 2でチェックしたグループの公開鍵相互認証デ一夕が認証テーブル (図 5 1参照）に格納されているか否かを判定する。テーブルに対応グループの公開鍵相互認証情報が格納され、チケットユーザ（デバイスに対するチケットを適用した処理を実行しょうとするデバイスアクセス機器としてのリ一ダライタ、 P C等）とデバイス間の相互認証が公開鍵認証処理として成立済みであることが判定された場合は、ステップ S 5 4 7に進み、処理対象チケット（P R T , F R T , S P Tまたは D U T ) にチケットユーザの識別子が存在するか否かを判定して存在する場合は、ステップ S 5 4 8において認証相手（チケットュ一ザであるデバイスアクセス機器としてのリーダライタなど）の公開鍵証明書中の識別デ一タ（D N ) として記録された識別子またはカテゴリまたはシリアル（S N ) とチケットに格納されたチケットュ一ザの識別デ一夕として記録された識別子またはカテゴリまたはシリアル（ S N)がー致するか否かを判定する。一致する場合は、利用者確認成功として処理を終了する。

ステップ 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 5 50に進み、処理対象チケット（P RT， F R T, S PTまたは DUT) にチケットユーザの識別子が存在するか否かを判定して存在する場合は、ステップ 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等）からパーティシヨン登録チケヅト（PRT) を受信したデバイスが、パーティション登録チケット（PRT) に基づいて実行する処理である。

図 60のステップ S 60 1において、デバイスは、受信したパ一テイシヨン登録チケット（P R T :PartitionRegistrationticket) に記録された処理タイプ、すなわち Operation Type (パーティション（Partition)作成か削除かの指定（作成（Generate) / 削除（Delete))) を検証する。処理タイプ（Operation Type) が、パーティシヨン（Partition)作成である場合、ステップ S 602以下を実行し、パーティシヨン（Partition) 削除である場合、ステップ S 62 1以下を実行する。

まず、パーティション作成処理について説明する。デバイスはステップ S 6 0 2において、パーティション登録チケット（PRT) に記述されたパーティションマネ一ジヤコ一ド（PMC) と同一コードのパーティションがデバイスのメモリ部に存在するか否かを検証する。この判定は、デパイスのメモリ部のパーティシヨン定義ブロック（図 1 9参照）に受信チケヅト（PRT) の記述コードと同一のコ一ドが記述されているか否かを検証することによって判定可能である。すでにデバイスに同一コード（PMC) のパーティションが存在する場合は、同一コ一ドを持つ重複パーティションの存在は許されず、パーティションの生成は実行せず、エラ一終了とする。同一コードのパーティションがデバイスに存在しない場合は、ステップ S 603において、デバイス管理情報ブロック（図 1 5 参照）のデバイス（Device) 内の空きブロック数（Free Block Number in Device) と、パーティション登録チケット（PRT) に記述されたパーティションサイズ (Partion Size) とを比較し、チケット（PRT) に記述されたパーティションサイズ（Partion Size) 以上の空きブロック領域がデバイスのメモリ部に存在するか否かを判定する。存在しない場合は、 PRTに記述されたサイズのパーティシヨンの生成はできないので、エラ一終了とする。

チケット（PRT) に記述されたパーティションサイズ（Partion Size) 以上の空きプロック領域がデパイスのメモリ部に存在すると判定された場合は、ステップ S 604に進み、デバイス管理情報プロックの空き領域ポィンタ（Pointer of Free Area) を参照してデバイスの空き領域（Free Area in Device) の最上位ブロックにパ一テイション定義プロック（P D B ) エリア（図 1 9参照）を確保する。

次に、デバイスは、確保したパ一テイション定義プロヅク（P D B ) ェリアに、パーティション登録チケット（P R T) に記述されたパーティションマネージャコード（PM C) のコピー（ S 60 5 )、 P R Tに記述された P M Cバージョンのコピ一、（ S 606 ) を実行する。

さらに、パーティション定義ブロック（PDB) エリアのパーティションス夕 —ト位置（Partition Start Position) に、デバイス管理情報ブロック（図 1 5 参照）の空き領域ポインタ（Pointer of Free Area) のコピ一処理を実行（S 6 07) し、さらに、パ一テイション定義プロック（P D B ) ェリアのパ一ティシヨンサイズ（Partion Size) にパーティション登録チケット（PRT) に記述されたパ一テイションサイズ（Partion Size) のコピ一処理を実行（ S 608 ) する。

次に、デバイス管理情報ブロック（図 1 5参照）の空き領域ポインタ（Pointer of Free Area) にパーティション定義プロック（PDB) エリアのパ一ティションサイズ（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 )o

次に、図 6 1のステップ S 63 1において、生成したパーティション領域の最上位ブロックをパーティション管理情報ブロック（ P M I B ： partition Management Information Block) (図 20参照）として設定し、設定したパ一ティシヨン管理情報ブロック（PMI B) のパーティションマネージャコード（PM C ) フィールドにパーティション登録チケット（PRT) の PMCのコピー処理を実行（S 6 3 2 ) し、パーティション管理情報プロヅク（PM I B) の PMC バ一ジヨンフィールドにパ一テイション登録チケッ卜（P R T) の P M Cパージョンのコピ一処理を実行（ S 633 ) し、パ一ティション管理情報プロック（ P M I B) のパーティション総ブロック数（Total Block number in Partition) フィ一ルドにパーテイション登録チケット（ P R T ) のパーティシヨンサイズ (Partion Size) のコピー処理を実行（S 634 ) する。

さらに、パーティション管理情報ブロック（PMI B) のパーティション空きブロック数（Free Block number in Partition) フィールドにパーティション登録チケット（PRT) のパーティションサイズ（Partion Size) - 3を記録（S 635 ) する。なお、一3の意味は、既に使用が予定されているパーティション管理情報ブロック（PM I B)、共通鍵系パーティシヨン鍵定義ブロック（PKD B(co瞧 on))、公開鍵系パーティション鍵定義ブロック（PKDB(PUB)) の 3ブロックを差し引くことを意味している。

さらに、パ一テイシヨン管理情報ブロック（PM I B) のファイル数（File Number) に 0を記入（ S 6 36 ) する。この時点ではパ一テイション内にはファィルは設定されていない。ファイル設定はファイル登録チケット（FRT) を使用して設定可能である。このファイル登録チケット（FRT) を使用したフアイル登録処理については後述する。

さらに、パーティション管理情報ブロック（PM I B) の空き領域ポインタ (Pointer of Free Area) にパーティション定義プロック（PDB) のス夕一トポジション（Start Position) をコピーしてパーティションの設定登録を終了する。

次に図 60のステップ S 62 1〜 S 628のパ一テイション削除処理について説明する。ステップ S 62 1では、パーティション登録チケット（PRT) に記述されたパーティションマネージャコード（PMC) と同一コードのパーティシヨンがデパイスのメモリ部に存在するか否かを検証する。この判定は、デバイスのメモリ部のパーティション定義プロック（図 1 9参照）に受信チケヅト（P R T) の記述コ一ドと同一のコ一ドが記述されているか否かを検証することによつて判定可能である。

デバイスに同一コード（PMC) のパーティションが存在しない場合は、パ一テイシヨンの削除は不可能であるので、エラ一終了とする。同一コードのパ一テイシヨンがデバイスに存在する場合は、ステップ S 622において、削除対象のパーティシヨンより後に生成されたパーティションがデバイスに存在するか否かを判定する。存在しない場合は、削除対象のパーティションが最新のパーティションであり、ステップ S 629において削除対象のパ一テイションのパ一ティシヨン定義ブロック（PDB) (図 1 9参照）を削除する。

ステップ S 6 22において、削除対象のパーティションょり後に生成されたパ一ティションがデバイスに存在すると判定された場合は、後に生成されたパ一テイシヨン（後パ一テイション）のデータを削除対象のパーティションのサイズ（ P S) 分、下位にずらす処理を実行（S 623 ) し、さらに、後パーティシヨンのパーティション定義ブロック（PD B)を 1プロック上位にずらす処理を実行（S 624 ) する。また、後パーティションのパ一ティション定義プロヅク（PD B) に記録されたパーティション開始位置（Partition Start Portion) から削除パ一テイシヨンのサイズ（P S) を減算する処理を実行する（S 625 )。

ステップ S 6 25または S 62 9の処理の後、ステップ 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 628において、デバイス管理情報ブロック（図 1 5参照）のパ一テイション数（Partition Number) から 1を減算、すなわち削除したパーティション数（ 1 ) を減算してパーティション登録チケット（PRT) に基づくパーティション削除処理が終了する。

以上が、図 47の処理フローにおけるステップ S 4 1 5のパ一テイション登録チケット（PRT) に基づくパーティション生成、削除処理である。

(パーティション初期登録）

次に、図 47の処理フローにおけるステップ S 406 , S 4 1 9のパ一テイシヨン初期データ書き込み処理、すなわちパーティション登録チケット（PRT) に基づくパーティション初期登録処理の詳細について図 6 2以下のフ口一を用いて説明する。

図 62、図 6 3、図 64に示す処理フローにおいて、左側がパ一ティシヨンマネージャの管轄する初期登録装置の処理、右側がデバイス（図 5参照）の処理を示す。なお、パーティションマネージャの管轄する初期登録装置は、デバイスに対するデータ読み取り書き込み処理可能な装置（ex. デバイスアクセス機器としてのリ一ダライタ、 P C) であり、図 1 0のデバイスアクセス機器としてのリ一ダライタに相当する構成を有する。図 47の処理フローに示すように、図 6 2 の処理開始以前に、初期登録装置とデパイス間では、相互認証が成立し、チケットの正当性、利用者チェックにおいてチケットおよび利用者（チケットユーザであるデバイスアクセス機器としてのリーダライタなど）の正当性が確認され、さらにパーティション登録チケット（P R T) に基づくパーティション生成処理が終了しているものとする。また、図 6 2、図 6 3、図 64の初期登録装置と、デバイス間のデータの送受信は、相互認証時に生成したセッション鍵 K s e sを用いて暗号化されたデータとして送受信される。

図 62のステップ S 64 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でデバイスは、上述の書き込みコマンドを受信し、ステップ

5652において、受領デ一夕をパーティション鍵領域（図 23参照）に書き込む。次にデ一夕書き込みによって生じたポインタ、サイズ、デバイス内のフリープロック数の調整を実行（ S 653 ) し、書き込み終了通知を登録装置に送信（ S

654 ) する。

書き込み終了通知を受信（S 643 ) した登録装置は、ステップ S 644においてパーティション認証に公開鍵を用いるか否かを判定する。図 62に示すように、パーティション認証に公開鍵を用いる場合、ステップ S 645 ~ 649、 S 65 5〜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でデバイスは、上述の書き込みコマンドを受信し、ステップ S 656において、受領デ一夕をパーティション鍵領域（図 23参照）に書き込む。次にデータ書き込みによって生じたポインタ、サイズ、デバイス内のフリープロック数の調整を実行（ S 6 57 ) し、書き込み終了通知を登録装置に送信（ 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参照））に保存する。

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

パーティションマネージャは、ファイル登録チケット（ F R T : File Registration Ticket) の検証処理に共通鍵認証を実行する設定とする場合は、共通鍵方式の F R T検証に必要な情報（ex. F RT検証共通鍵）をデバイスにセットし、デバイスが共通鍵認証を実行しないデバイスであれば、これらの情報をデバイスに格納しないことになる。

図 63に示すように、 F R T検証に共通鍵方式を用いる場合、ステップ S 6 7 2〜67 3、 S 68 1 -S 684を実行し、 F R T検証に共通鍵を用いない場合、これらのステップは省略される。

F R T検証に共通鍵を用いる場合、ステップ S 672において登録装置は、 F RT検証共通鍵書き込みコマンドとして、 Kfrt：ファイル登録チケッ卜（FRT) の MA C検証用鍵、およびバ一ジョン情報をデバイスに送信する。

ステップ S 6 8 1でデバイスは、上述の書き込みコマンドを受信し、ステップ S 682において、受領データをパーティション鍵領域（図 2 3参照）に書き込む。次にデータ書き込みによって生じたポインタ、サイズ、デバイス内のフリーブロック数の調整を実行（S 683 ) し、書き込み終了通知を登録装置に送信（S 684 ) する。

書き込み終了通知を受信（S 673 ) した登録装置は、ステップ S 674において F R T検証に公開鍵を用いるか否かを判定する。図 63に示すように、 FR T検証に公開鍵を用いる場合、ステップ S 67 5〜676、 S 685〜S 6 9 0 を実行し、 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. シリアルナンパ： SN) を登録したリボケ一ションリスト（Revocation List (Certificate))、およびこれらのバ一ジョン情報をデパイスに送信する。

ステップ S 685でデバイスは、上述の書き込みコマンドを受信し、ステップ S 686において、受領データ中の FRTIC (FRT Issuer Category) ：ファイル登録チケット（FRT) 発行者カテゴリを公開鍵系パーティシヨン鍵定義ブロック ( 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において、共通鍵データの更新をサポートするデバイスとするか否かを判定する。デバイスに格納されたデータ中、そのいくつかは更新対象データとして前述したデータアップデートチケット（D U T ： Data Update Ticket) (図 32参照）を用いて更新が可能である。更新対象となるデータは、先に図 33を用いて説明した通りである。このデータァップデ一トチケット（DUT： Data Update Ticket) を用いた更新処理においても共通鍵方式、または公開鍵方式のいずれかの方式が可能であり、パ一ティションマネージャは設定したパ一ティシヨンに応じていずれかの方式または両方式を実行可能なデ一夕をデバイスを設定する。

パーティションマネージャは、設定したパーティションを共通鍵方式によるデ一夕更新を実行する構成とする場合は、共通鍵方式のデータ更新処理に必要な情報（ex. データアップデ一トチケット（DUT) の MAC検証用鍵他）をデバイスのパーティション鍵領域にセットし、デバイスが共通鍵認証を実行しないデバイスであれば、これらの情報をデバイスのパーティション鍵領域に格納しない処理をする。

図 6 4に示すように、データアップデートチケット（D UT : Data Update Ticket) を用いたデータ更新処理に共通鍵方式を用いる場合、ステップ S 7 0 2 - 703 , S 7 1 1〜S 7 1 4を実行し、データ更新に共通鍵方式を用いない場合、これらのステップは省略される。

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

ステップ S 7 1 1でデバイスは、上述の書き込みコマンドを受信し、ステップ S 7 1 2において、受領データをパーティション鍵領域（図 23参照）に書き込む。次にデータ書き込みによって生じたポインタ、サイズ、デバイス内のフリ一プロック数の調整を実行（ S 7 1 3 ) し、書き込み終了通知を登録装置に送信（ S 7 14) する。

書き込み終了通知を受信（S 703 ) した登録装置は、ステップ S 704において、デバイスに設定したパーティションが公開鍵方式を用いたデータアップデ —トチケット（D U T ： Data Update Ticket) を使用したデータ更新処理をサポ —トするか否かを判定する。図 64に示すように、公開鍵方式をサポートする場合、ステップ S 7 05〜7 06、 S 7 1 5~S 7 1 8を実行し、公開鍵方式をサポートしない場合、これらのステップは省略される。

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

ステップ S 7 1 5でデバイスは、上述の書き込みコマンドを受信し、ステップ S 7 1 6において、受領デ一夕を公開鍵系パーティション鍵定義ブロック（PK DB (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. シリアルナンパ： S N) を登録したリボケ一シヨンリス卜（Revocation List (Certificate)

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

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

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

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

* Kdut一 PAR4 ：データ更新用暗号鍵

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

また、

* PUB PAR ：パーティション（Partition) の公開鍵 * PRI_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) の各データは、パーティションの生成時（処理フロー図 60、図 6 1参照）に書き込まれるデータである。

[B 4. 2. パーティションマネージャ管理下における公開鍵証明書発行処理]

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

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

図 66および図 67に従って、パ一ティションマネージャの管轄登録局による設定パーティションに対するパーティション対応公開鍵証明書（CERT PA R) の発行処理の手順を説明する。図 66 , 図 67において、左側がパーティションマネージャの管轄登録局の C E R T (公開鍵証明書）発行装置、具体的には、図 9に示すパーティションマネージャの構成図における制御手段 33 1の処理、右側がデバイスの処理である。

まずステップ S 72 1において、 CERT発行装置は、パ一ティシヨン対応公開鍵証明書（CERT PAR)の発行対象となるデバイスのユーザ情報を取得し、証明書発行の許可（判定）を行ない発行対象となるデバイスとの通信路を確保する。パーティション対応公開鍵証明書（CERT PAR)の発行対象となるデパイスのユーザ情報は、例えばデバイスの初期登録時に生成したデータから取得可能である。なお、ユーザ情報はデバイスとの通信路設定後、デバイスから取得してもよい。通信路は、有線、無線を問わずデータ送受信可能な通信路として確保されればよい。

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

デバイスから識別データ（ I Dm) と署名（S) を受信（S 72 3 ) した C E RT発行装置は、受信したデバイス識別データ（ I Dm) を検索キーとしてデー夕ベース DB (PAR) 3 32から格納済みのデパイス公開鍵（PUB PAR) を取得する。さらに、取得したデバイス公開鍵（PUB PAR) を適用して署名 (S) の検証処理（図 1 3参照）を実行（S 725 ) する。検証に成功しなかつた場合は、デバイスからの送信データは不正なデ一夕であると判定し処理は終了する。

検証に成功した場合は、認証局（CA f o r PM) 620に対してパーティシヨン対応公開鍵証明書（CERT P A-R) の発行処理を依頼（S 727 ) する _c パーティションマネージャは認証局 620の発行したパーティション対応公開鍵証明書（CERT PAR) を受信（S 72 8 ) してデバイスに送信（S 7 29 ) する。パーティションマネージャ（登録局）からパーティション対応公開鍵証明書（C ERT PAR)を受信したデバイスは、予めパーティシヨン鍵領域（図 2 3参照）に格納済みの認証局の公開鍵（PUB C A (PAR)) を用いて受信したパ一ティシヨン対応公開鍵証明書（CERT PAR)の署名検証を実行する。すなわち公開鍵証明書には認証局の秘密鍵で実行され署名があり（図 1 1参照）、この署名検証（S 73 5 ) を行なう。

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

署名検証に成功した場合は、パーティション対応公開鍵証明書（CERT PA R) に格納されたデバイス公開鍵（P UB PAR) と自デバイスに保管されたデバイス公開鍵（PUB P AR) の比較を実行（ S 74 1 ) し、一致しない場合はエラ一通知を実行し、一致した場合は、受信したパーティション対応公開鍵証明書（CERT PAR)をパーティション鍵領域（図 2 3参照）に格納（S 743 ) する。なお、パーティション対応公開鍵証明書（CERT PAR) の発行以前は、この領域に自デバイスで生成した公開鍵（PUB P AR) を格納し、正当なパ一ティション対応公開鍵証明書（CERT PAR)が発行された時点で、パーティション対応公開鍵証明書（CERT PAR)により上書きする処理として格納する。

パーティション対応公開鍵証明書（CERT PAR)の格納が終了すると格納処理終了通知を C E R T発行装置に送信（S 744 ) する。 CERT発行装置は、格納処理終了通知を受信（ S 75 1 ) し、格納成功を確認（S 752 ) して処理を終了する。格納成功の確認が得られない場合はエラ一として処理が終了する。

[B 4. 3. パーティション生成処理各方式における処理手順]

上述したように、パーティションの設定登録処理において、パーティションマネ一ジャの管理するデバイスアクセス機器としてのリ一ダライタとデバイス間において、相互認証が実行され、パーティション登録チケット（PRT) に基づくパーティションの設定がなされる。上述したように相互認証処理の態様は、公開鍵相互認証、共通鍵相互認証の 2種類のいずれかであり、またチケット（PRT) の検証処理も公開鍵系の署名検証、共通鍵系の MA C検証の 2種類のいずれかが実行されることになる。すなわち処理態様としては大きく分けて、

(A) 相互認証（公開鍵）、チケット（P RT) 検証（公開鍵）

(B) 相互認証（公開鍵）、チケット（P RT) 検証（共通鍵）

(C) 相互認証（共通鍵）、チケット（P RT) 検証（共通鍵）

(D) 相互認証（共通鍵）、チケット（P RT) 検証（公開鍵）

の 4態様がある。

これらの 4態様についての処理を、認証局（CA (DM)), デバイスマネージャ（DM)、パーティションマネージャ（PM)、デバイス、各エンティティ間において実行されるデータ転送処理を中心として図を用いて簡潔に説明する。

(A) 相互認証（公開鍵）、チケット（P RT) 検証（公開鍵）

まず、相互認証処理に公開鍵方式を適用し、チケット（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) は、認証局（CA) によってパーティションマネージャの発行要求により、登録局を介した証明書発行手続きによってパ一テイシヨンマネージャに対して発行される。

(3 ) パーティション登録チケヅト（PRT) の発行処理

パーティション登録チケット（PRT) は、デバイスマネージャの管理するパ —ティション登録チケット発行手段（PRT Ticket Issuer) によりパーティシヨンマネージャ（PM) に対して発行される。この場合、公開鍵方式の署名生成、検証を実行するため、デパイスマネージャの秘密鍵による署名（Signature)が生成 (図 1 2参照）されて P R Tに付加される。

(4) PRTおよび DM公開鍵証明書（C e r t . DM) の PMに対する供給デバイスマネージャの管理するパーティション登録チケット発行手段（PRT Ticket Issuer) により発行されたパーティション登録チケット（PRT) は、 D M公開鍵証明書（C e r t . DM) とともにパーティションマネージャに対して送信される。

(5) PMとデバイス間の相互認証

発行された P R Tに従ったパーティションを生成しょうとする対象のデパイスと、パーティションマネージャ（具体的にはチケットュ一ザであるデバイスァクセス機器としてのリーダライタ）は、公開鍵方式の相互認証（図 50参照）を実行する。

(6) P R Tおよび DM公開鍵証明書（C e r t . DM) のデバイスに対する供給

PMとデバイス間の相互認証が成立すると、パーティションマネージャ（PM) は、デバイスに対してパーティ.ション登録チケット（PRT)、および DM公開鍵証明書（C e r t . DM) を送信する。

デバイスは、受信したパーティション登録チケット（PRT) について、（ 1 ) チケット発行者（Ticket Issuer) = DMの公開鍵証明書（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) の検証によりチケヅトが改竄のないことの確認を実行し、さらに、 PRTチケットに格納された PRTユーザ（この場合は P M：チケットユーザであるデバイスアクセス機器としてのリ一ダライタ）と受信したパーティションマネージャの公開鍵証明書の識別データ（DN) として記録された識別子またはカテゴリまたはシリアル（SN) の一致を確認し、相互認証済みであることを確認することにより PRTユーザ（PM：デバイスアクセス機器としてのリ一ダライタ）の検証（図 57、図 58参照）を実行する。

( 7 ) パ一テイションの生成

パーティション登録チケット（PRT) の検証、 PRT発行者（PRT Issuer)ヽ P R Tユーザの検証に成功すると、パーティション登録チケット（PRT) に記述されたルールに従ってパ一ティションがデバイスのメモリ部に生成（図 60、図 6 1参照）される。

(8) 鍵データ書き込み

パーティションがデバイスのメモリ部に生成されると、生成されたパ一ティシヨン内に対する各種鍵の格納処理が実行される。

( 9 ) 公開鍵の読み出し、

( 1 0) 公開鍵証明書の発行

生成パーティションに対する各種サービス時の認証処理（パーティション生成、ファイル生成、ファイルアクセス、データアップデート等のサービス利用時の認証処理）に際し、公開鍵認証を行なう場合、デバイスは公開鍵、秘密鍵の鍵ペアを生成し、生成した公開鍵をパーティションマネージャに送信し、登録局、認証局を介して公開鍵証明書の発行処理を行ない、発行された公開鍵証明書をパ一テイシヨン鍵領域（図 23参照）に格納する。この際、生成した公開鍵の格納領域に対して発行された公開鍵証明書を格納する。なお、この（ 9 )、 ( 1 0) の処理は、作成パーティションに対する各種サービス時の認証処理（パーティション生成、ファイル生成、ファイルアクセス、データアップデート等のサ一ビス利用時の認証処理）の際に公開鍵認証を行なう構成の場合に実行すればよい。

以上の処理によって、相互認証（公開鍵）、チケット（PRT) 検証（公開鍵）の各方式に従ったパーティションの生成処理が実行される。 (B) 相互認証（公開鍵）、チケット（P RT) 検証（共通鍵）次に、相互認証処理に公開鍵方式を適用し、チケット（PRT) 検証に共通鍵方式を適用する場合の各エンティティ間のデータ転送について図 69を用いて説明する。図に示す番号順に各エンティティ間でデータ転送が実行される。以下、各番号に従って処理を説明する。

( 1 ) パーティションマネージャ（PM) の公開鍵証明書（C e r t . PM) の発行、

公開鍵証明書（C e r t . PM) は、認証局（CA) によってパーティションマネージャの発行要求により、登録局を介した証明書発行手続きによってデバイスマネージャに対して発行される。

(2) パーティション登録チケット（PRT) の発行処理

パーティション登録チケット（PRT) は、デバイスマネージャの管理するパ

—テイシヨン登録チケット発行手段（PRT Ticket Issuer) によりパ一テイシヨンマネージャ（PM) に対して発行される。この場合、共通鍵方式の検証値として M A C (Message Authentication Code) (図 59参照）が PRTに付加される (

( 3 ) P R Tの PMに対する供給

デバイスマネージャの管理するパーティション登録チケット発行手段（PRT Ticket Issuer) により発行されたパーティション登録チケヅト（PRT) は、パ —ティションマネージャに対して送信される。

(4) PMとデバイス間の相互認証

発行された P RTに従ったパーティションを生成しょうとする対象のデパイスと、パーティションマネージャ（具体的にはチケットユーザであるデバイスァクセス機器としてのリーダライタ）は、公開鍵方式の相互認証（図 5 0参照）を実行する。

(5) PRTの送信

パーティションマネージャは発行されたパ一ティション登録チケヅト（PRT) をデバイスに送付する。デバイスは、受信したパーティション登録チケット（P RT) について MA C検証処理を実行し、 PRT発行者（PRT Issuer) の検証、さらに、 P R Tチケットに格納された P R Tユーザ（この場合は PM：チケットユーザであるデバイスアクセス機器としてのリーダライタ）と受信したパーティシヨンマネージャの公開鍵証明書の識別データ（DN) として記録された識別子またはカテゴリまたはシリアル（SN) の一致を確認し相互認証済みであることを確認することにより P R Tユーザ（PM：デバイスアクセス機器としてのリーダライタ）の検証（図 57、図 58参照）を実行する。

( 6 ) パーテイションの生成

パーティション登録チケット（PRT) の検証、 PRT発行者（PRT Issuer), P RTユーザの検証に成功すると、パーティション登録チケヅト（PRT) に記述されたルールに従ってパ一ティションがデバイスのメモリ部に生成（図 60、図 6 1参照）される。

( 7 ) 鍵デ一夕書き込み

パ一テイションがデバイスのメモリ部に生成されると、生成されたパ一ティション内に対する各種鍵の格納処理が実行される。

(8) 公開鍵の読み出し、

(9) 公開鍵証明書の発行

生成パーティシヨンに対する各種サービス時の認証処理（パーティション生成、ファイル生成、ファイルアクセス、データアップデート等のサービス利用時の認証処理）に際し、公開鍵認証を行なう場合、デバイスは公開鍵、秘密鍵の鍵ペアを生成し、生成した公開鍵をパーティションマネージャに送信し、登録局、認証局を介して公開鍵証明書の発行処理を行ない、発行された公開鍵証明書をパ一テイシヨン鍵領域（図 2 3参照）に格納する。この際、生成した公開鍵の格納領域に対して発行された公開鍵証明書を格納する。なお、この（8)、（9)の処理は、作成パーティションに対する各種サービス時の認証処理（パーティション生成、ファイル生成、ファイルアクセス、デ一タアップデート等のサービス利用時の認証処理）の際に公開鍵認証を行なう構成の場合に実行すればよい。

以上の処理によって、相互認証（公開鍵）、チケット（PRT) 検証（共通鍵）の各方式に従ったパーティシヨンの生成処理が実行される。

(C) 相互認証（共通鍵）、チケット（P RT) 検証（共通鍵）

次に、相互認証処理に共通鍵方式を適用し、チケット（PRT) 検証に共通鍵方式を適用する場合の各エンティティ間のデータ転送について図 70を用いて説明する。図に示す番号順に各エンティティ間でデータ転送が実行される。以下、各番号に従って処理を説明する。

( 1 ) パーティション登録チケット（PRT) の発行処理

パーティション登録チケット（PRT) は、デバイスマネージャの管理するパ —テイシヨン登録チケット発行手段（PRT Ticket Issuer) によりパ一テイシヨンマネージャ（PM) に対して発行される。この場合、共通鍵方式の検証値として MAC (図 59参照）が PRTに付加される。

(2) PRTの PMに対する供給

デパイスマネージャの管理するパーティション登録チケット発行手段（PRT Ticket Issuer) により発行されたパーティション登録チケット（PRT) は、パ —テイシヨンマネージャに対して送信される。

(3) PMとデバイス間の相互認証

発行された P RTに従ったパーティシヨンを生成しょうとする対象のデバイスと、パーティションマネージャ（具体的にはチケットュ一ザであるデバイスァクセス機器としてのリーダライタ）は、共通鍵方式の相互認証（図 53、図 54参照）を実行する。

(4) PRTの送信

パーティションマネージャは発行されたパ一ティション登録チケヅト（PRT) をデバイスに送付する。デバイスは、受信したパーティション登録チケット（P RT) について MA C検証処理を実行し、 PRT発行者（PRT Issuer) の検証、さらに、 PRTチケットに格納された PR Tユーザ（この場合は PM：チケットユーザであるデバイスアクセス機器としてのリーダライタ）とパーティションマネージャの識別子の一致を確認し、相互認証済みであることを確認することにより PRTユーザ（PM:デバイスアクセス機器としてのリーダライタ）の検証（図 57、図 58参照）を実行する。

( 5 ) パ一テイションの生成

パーティション登録チケット（PRT) の検証、 PRT発行者（PRTIssuer)、 P R Tユーザの検証に成功すると、パーティション登録チケット（PRT) に記述されたルールに従ってパ一テイションがデパイスのメモリ部に生成（図 6 0、図 6 1参照）される。

( 6 ) 鍵データ書き込み

パーティションがデバイスのメモリ部に生成されると、生成されたパーティシヨン内に対する各種鍵の格納処理が実行される。

( 7 ) 公開鍵の読み出し、

(8) 公開鍵証明書の発行

生成パーティションに対する各種サービス時の認証処理（パーティション生成、ファイル生成、ファイルアクセス、データアップデート等のサービス利用時の認証処理）に際し、公開鍵認証を行なう場合、デバイスは公開鍵、秘密鍵の鍵ペアを生成し、生成した公開鍵をパーティションマネージャに送信し、登録局、認証局を介して公開鍵証明書の発行処理を行ない、発行された公開鍵証明書をパ一テイシヨン鍵領域（図 23参照）に格納する。この際、生成した公開鍵の格納領域に対して発行された公開鍵証明書を格納する。なお、この（7)、（8)の処理は、作成パーティションに対する各種サービス時の認証処理（パーティション生成、ファイル生成、ファイルアクセス、デ一夕アップデート等のサービス利用時の認証処理）の際に公開鍵認証を行なう構成の場合に実行すればよい。

以上の処理によって、相互認証（共通鍵）、チケット（PRT) 検証（公開鍵）の各方式に従ったパーティシヨンの生成処理が実行される。

(D) 相互認証（共通鍵）、チケット（P RT) 検証（公開鍵）

次に、相互認証処理に共通鍵方式を適用し、チケット（PRT) 検証に公開鍵方式を適用する場合の各エンティティ間のデータ転送について図 7 1を用いて説明する。図に示す番号順に各エンティティ間でデ一夕転送が実行される。以下、各番号に従って処理を説明する。

( 1 ) デバイスマネージャ（DM) の公開鍵証明書（C e r t . DM) の発行、公開鍵証明書（C e r t . DM) は、認証局（CA) によってデバイスマネ一ジャの発行要求により、登録局を介した証明書発行手続きによってデバイスマネージャに対して発行される。

(2) パーティション登録チケット（PRT) の発行処理パーティション登録チケット（PRT) は、デバイスマネージャの管理するパ一ティション登録チケット発行手段（P RT Ticket Issuer) によりパーティシヨンマネージャ（PM) に対して発行される。この場合、公開鍵方式の署名生成、検証を実行するため、デバイスマネージャの秘密鍵による署名（Signature)が生成 (図 1 2参照）されて PRTに付加される。

(3) P R Tおよび DM公開鍵証明書（C e r t . DM) の PMに対する供給デバイスマネージャの管理するパ一テイション登録チケット発行手段（P R T

Ticket Issuer) により発行されたパーティション登録チケット（PRT) は、 D M公開鍵証明書（C e r t . DM) とともにパーティションマネージャに対して送信される。

(4) PMとデバイス間の相互認証

発行された P R Tに従ったパーティシヨンを生成しょうとする対象のデバイスと、パーティションマネージャ（具体的にはチケットュ一ザであるデバイスァクセス機器としてのリーダライタ）は、共通鍵方式の相互認証（図 53、図 54参照）を実行する。

(5) P R Tおよび DM公開鍵証明書（C e r t . DM) のデバイスに対する供給

PMとデバイス間の相互認証が成立すると、パーティションマネージャ（PM) は、デバイスに対してパーティション登録チケット（P R T)、および DM公開鍵証明書（C e r t . DM) を送信する。

デバイスは、受信したパーティション登録チケット（PRT) について、（ 1 ) チケット発行者（Ticket Issuer) = DMの公開鍵証明書（CERT) が改竄されたものでない正当な公開鍵証明書（CERT) であること、（2)チケヅト発行者 (Ticket Issuer) の公開鍵証明書（CERT) のオプション領域に記録されたコ —ドと、デパイス内の DKDB (Device Key Definition Block) (PUB)に記録されたチケット発行手段コ一ド（P RT I C ： PRT Issuer Code) の一致、（ 3 ) チケット発行手段（Ticket Issuer) がリボークされていないこと、（4) 受信チケヅト（PRT) の署名（Signature) の検証によりチケットが改竄のないことの確認を実行し、さらに、 PRTチケットに格納された PRTユーザ（この場合は P M：チケットユーザであるデバイスアクセス機器としてのリーダライタ）とパ一テイシヨンマネージャの公開鍵証明書中の識別データ（DN) として記録された識別子またはカテゴリまたはシリアル（SN) の一致を確認し、相互認証済みであることを確認することにより PRTユーザ（PM：デバイスアクセス機器としてのリーダライタ）の検証（図 57、図 58参照）を実行する。

( 6 ) パ一テイションの生成

パーティション登録チケット（PRT) の検証、 PRT発行者（PRTIssuer)、 P R Tユーザの検証に成功すると、パーティション登録チケット（PRT) に記述されたルールに従ってパーティションがデバイスのメモリ部に生成（図 60、図 6 1参照）される。

(7) 鍵デ一夕書き込み

(8) 公開鍵の読み出し、

(9) 公開鍵証明書の発行

生成パーティションに対する各種サービス時の認証処理（パーティション生成、ファイル生成、ファイルアクセス、デ一夕アップデート等のサービス利用時の認証処理）に際し、公開鍵認証を行なう場合、デバイスは公開鍵、秘密鍵の鍵ペアを生成し、生成した公開鍵をパーティションマネージャに送信し、登録局、認証局を介して公開鍵証明書の発行処理を行ない、発行された公開鍵証明書をパ一テイシヨン鍵領域（図 23参照）に格納する。この際、生成した公開鍵の格納領域に対して発行された公開鍵証明書を格納する。なお、この（ 8 )、 ( 9 ) の処理は、作成パーティションに対する各種サービス時の認証処理（パーティション生成、ファイル生成、ファイルアクセス、デ一夕アップデート等のサービス利用時の認証処理）の際に公開鍵認証を行なう構成の場合に実行すればよい。

[B 4. 4. ファイル登録チケット（FRT) を利用したファイル生成、削除処理] 次に、デバイスに生成したパーテイション内にファイル登録チケット（ F R T ) を適用してファイルを生成、または削除する処理について説明する。図 7 2以下のフロー他の図面を参照して説明する。なお、ファイル作成、削除処理には、デバイスとデバイスアクセス機器としてのリーダライタ（パーティションマネージャ）間における相互認証処理（デバイス認証またはパーティション認証）、パーテイシヨン登録チケット（ F R T ： Fi le Regi stration Ticket) の正当性検証処理が含まれる。

図 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参照）の * Authentication Flag ：チケット（Ticket) の利用処理においてデバイス (Device) との相互認証が必要か否かを示すフラグ

によって決定される。

認証処理に失敗した場合（S 802 , S 8 1 1で N o) は、相互が正当な機器、デバイスであることの確認がとれないことを示し、以下の処理は実行されずエラ —として処理は終了する。

認証処理に成功すると、ファイル作成 · 削除装置は、デバイスに対してフアイル登録チケット（ F R T ： File Registration Ticket) を送信する。ファイル登録チケット（FRT) は、パーティションマネージャの管理下のファイル登録チケット（FRT) 発行手段（FRT Issuer) により発行されるチケットである。フアイル登録チケット（FRT) は、デバイスに対するアクセス制御チケットであり、先に説明した図 27のデ一夕フォーマツト構成を持つチケットである。

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

ファイル登録チケヅト（FRT) を受信（S 8 1 2) したデバイスは、受信したチケット（F RT) の正当性と利用者チェック処理を実行（S 8 1 3) する。チケットの正当性の検証処理は、共通鍵方式による MAC検証、あるいは公開鍵方式による署名検証処理のいずれかを適用して実行される。利用者チェックは、チケットを送信してきた機器（チケット利用者）の正当性をチェックする処理であり、相互認証が成立済みであり、認証相手の識別デ一夕と、チケットに記録されているチケットユーザ識別子（図 27参照）との一致等を検証する処理として実行される。これらの処理は、先のパーティション登録チケット（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) すると、 FRT受理成功をファイル作成 · 削除装置に通知（S 8 1 7 ) する。一方、ファイルの生成または削除処理に失敗（ S 8 1 6で No) した場合は、 FRT受理エラーをファイル作成 ' 削除装置に通知 ( S 8 1 8 ) する。

ファイル作成 . 削除装置は、 F R T受理結果を受信（ S 804 ) し、 FRT処理結果を判定し、 F R T受理結果がエラーである場合（S 805で No) は、ェラーとして処理を終了し、 F R T受理結果が成功（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 ) について、図 73を用いて説明する。

(ファイル作成 · 削除処理）

図 72のフローに示すステップ S 8 1 5において実行されるファイル登録チケット（FRT) に基づくパーティションの作成、削除処理の詳細について、図 7 3の処理フローを用いて説明する。ファイルの作成、削除処理は、チケットユーザ（ex. デバイスアクセス機器としてのリーダライタ、 P C等）からファイル登録チケヅト（FRT) を受信したデバイスが、ファイル登録チケヅト（FRT) に基づいて実行する処理である。

図 73のステップ 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) に記述されたフアイルサイズ（File Size) とを比較し、チケット（FRT) に記述されたファイルサィズ（File Size) 以上の空きプロック領域がデバイスの処理対象パ一テイシヨン内に存在するか否かを判定する。存在しない場合は、 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 827において、ファイル定義プロック（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) の MAC検証用鍵 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リセットするなどの処理を実行する。これらの処理により、生成したパーティション内に新たなファイルが生成される。

次に図 73のステップ S 84 1〜S 848のファイル削除処理について説明する。ステップ S 84 1では、ファイル登録チケット（ F R T) に記述されたファィル I Dと同一 I Dのファイルがデバイスのメモリ部の処理対象パ一テイシヨン内に存在するか否かを検証する。この判定は、デバイスのメモリ部のファイル定義ブロック（図 24参照）に受信チケット（FRT) に記述されたファイル I D と同一のファイル I Dが記述されているか否かを検証することによって判定可能である。

デバイスの処理対象パ一ティシヨン内に同一ファイル I Dのフアイルが存在しない場合は、ファイルの削除は不可能であるので、エラ一終了とする。同一 I D のファイルがデバイスの処理対象パ一ティション内に存在する場合は、ステツプ S 842において、削除対象のファイルより後に生成されたファイルが処理対象パーティション内に存在するか否かを判定する。存在しない場合は、削除対象のファイルが最新のファイルであり、ステップ S 849において削除対象のフアイルのファイル定義ブロック（FDB) (図 24参照）を削除する。

ステップ S 842において、削除対象のファイルより後に生成されたファイルが処理対象パーティション内に存在すると判定された場合は、後に生成されたフアイル（後ファイル）のデータを削除対象のファイルのサイズ（F S) 分、下位にずらす処理を実行（S 843 ) し、さらに、後ファイルのファイル定義ブロック（FDB) を 1ブロック上位にずらす処理を実行（S 844) する。また、後ファイルのファイル定義ブロック（ F D B )に記録されたファイル開始位置（File Start Portion)から削除ファイルのサイズ（ F S )を減算する処理を実行する（ S 845 )。

ステップ S 845または S 849の処理の後、ステップ S 846において、ノ —ティション管理情報プロック（PM I B) (図 20参照）のパーティション内の空きブロック数（Free Block Number in Partition) に削除ファイルのサイズ（F S ) + 1を加算する。 + 1は、削除ファイルのファイル定義ブロック（FDB) 用のブロックを意味する。

次にステップ S 847において、パーティション管理情報プロヅク（PM I B) (図 20参照）の空き領域ポインタ（Pointer of Free Area) の値から削除ファィルのサイズ（F S) を減算する。さらに、ステップ S 848において、パ一テイション管理情報プロック（PM I B) (図 20参照）のファイル数（File Number) から 1を減算、すなわち削除したファイル数（ 1 ) を減算してファイル登録チケッ卜（FRT) に基づくファイル削除処理が終了する。

以上が、図 7 2の処理フローにおけるステップ S 8 1 5のファイル登録チケット（FRT) に基づくファイル生成、削除処理である。

パーティションマネージャによるファイル生成処理が完了した状態のデバイスのメモリ内格納デ一夕構成例を図 7 4に示す。図 7 4に示すパーティション (Partion)領域中、

フアイル定義プロック（ 1〜N) (File Definition Block)

パ一テイション鍵領域（Partition Key Area)

共通鍵系パーティション鍵情報ブロック（ Partition Key Definition Block(Common) )

パーティション管理情報ブロック（Partition Management Information Block) の各データは、ファイル生成時、またはパーティション生成時に書き込まれるデータである。ファイル領域（File DataArea 1〜N)は、ファイル生成処理によつて処理対象パーティション内にファイル領域として確保される。

[B 4. 5. ファイル生成処理各方式における処理手順] 上述したファイルの設定登録処理において、パーティシヨンマネージャが管理し、ファイル登録チケットュ一ザであるデバイスアクセス機器としてのリーダライタとデバイス間において、相互認証が実行され、ファイル登録チケット（F R T) に基づくファイルの設定がなされる。相互認証処理の態様は、公開鍵相互認証、共通鍵相互認証の 2種類のいずれかであり、またチケット（F R T) の検証処理も公開鍵系の署名検証、共通鍵系の MA C検証の 2種類のいずれかが実行されることになる。すなわち処理態様としては大きく分けて、

(A) 相互認証（公開鍵）、チケット（F R T) 検証（公開鍵）

(B ) 相互認証（公開鍵）、チケット（F R T) 検証（共通鍵）

( C) 相互認証（共通鍵）、チケット（F R T) 検証（共通鍵）

(D ) 相互認証（共通鍵）、チケット（F R T) 検証（公開鍵）

の 4態様がある。

これらの 4態様についての処理を、認証局（ CA (P M))、パーティションマネ一ジャ（P M)、デバイス、各エンティティ間において実行されるデータ転送処理を中心として図を用いて簡潔に説明する。

(A) 相互認証（公開鍵）、チケット（F R T) 検証（公開鍵）

まず、相互認証処理に公開鍵方式を適用し、チケット（F R T) 検証に公開鍵方式を適用する場合の各ェンティティ間のデータ転送について図 7 5を用いて説明する。

( 1 ) ファイル登録チケット発行手段（F R T Issuer) の公開鍵証明書（ C e r t . F R T Issuer) の発行、

ファイル登録チケット発行手段（F R T Issuer) の公開鍵証明書（C e r t . F R T Issuer) は、ファイル登録チケット発行手段（F R T Issuer) からの発行要求により、登録局（RA) を介した証明書発行手続きによってパーティション対応認証局（ C A (P AR)) から発行される。なお、パーティションマネージャがファイル登録チケット発行手段（F R T Issuer) を兼ねる構成も可能であり、その場合は、ファイル登録チケット発行手段（F R T Issuer) の公開鍵証明書としてパーティションマネージャ（PM) の公開鍵証明書を使用可能である。

(2) ファイル登録チケットユーザ（FRT User) の公開鍵証明書（C e r t . FRT User) の発行、

ファイル登録チケットユーザ（ F R T User：具体的には、デバイスに対してチケットを送信するデバイスアクセス機器としてのリーダライタ）の公開鍵証明書 (C e r t . F RT User) は、ファイル登録チケヅトュ一ザ（FRT User) からの発行要求により、登録局（RA) を介した証明書発行手続きによってパーテイション対応認証局（CA (PAR)) によって発行される。なお、パーティションマネージャがファイル登録チケヅトュ一ザ（FRT User)を兼ねる構成も可能であり、その場合は、ファイル登録チケットユーザ（FRT User) の公開鍵証明書としてパーティションマネージャ（PM) の公開鍵証明書を使用可能である。

(3) ファイル登録チケヅト（FRT) の生成処理

ファイル登録チケット（FRT) は、パーティションマネージャの管理するフアイル登録チケット発行手段（FRT Ticket Issuer) により生成される。この場合、公開鍵方式の署名生成、検証を実行するため、ファイル登録チケット発行手段（FRT Ticket Issuer) の秘密鍵による署名（Signature)が生成（図 1 2参照）されて F R Tに付加される。

(4) FRTおよびファイル登録チケット発行手段（FRT Ticket Issuer) 公開鍵証明書（C e r t . FRT Issuer) のファイル登録チケヅトユーザ（ F R T User) に対する供給

パーティションマネージャの管理するファイル登録チケヅト発行手段（FRT Ticket Issuer) により発行されたファイル登録チケット（ F R T) は、ファイル登録チケヅト発行手段（F RT 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) をデバイスに送信し、公開鍵方式の相互認証（図 50参照）を実行する。

(6) F RTおよびファイル登録チケット発行手段（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) が改竄されたものでない正当な公開鍵証明書（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) の検証によりチケヅトが改竄のないことの確認を実行し、さらに、 F R Tチケットに格納された F R Tユーザ（チケットュ一ザであるデバイスアクセス機器としてのリ一ダライタ）とチケットュ一ザ（FRT User) の公開鍵証明書（C e r t . FRT User) の識別データ（D N) として記録された識別子またはカテゴリまたはシリアル（SN) 名（DN) の一致を確認し、相互認証済みであることを確認することにより F R Tユーザ（デバイスアクセス機器としてのリ一ダライタ）の検証（図 57、図 58参照）を実行する。

(7) FDBに S P T I Cおよび K s p tを登録

デバイスは、ファイル定義ブロック（F D B ： File DefinitionBlock) にサ一ビス許可チケット（ S P T) ユーザ（ S P T I C) (ex. デバイスのフアイル内のデータにアクセスを実行するデバイスアクセス機器としてのリーダライタ）と Kspt (サービス許可チケット（S P T)の MA C検証用鍵（Kspt))を登録する（図 7 3のフローにおけるステップ S 82 7, S 828 )o

(8) ファイルデータ領域の確保

デバイスは、処理対象パーティションにファイル登録チケット（FRT) に記述されたサイズを持つファイル領域を確保する。

以上の処理によって、相互認証（公開鍵）、チケット（FRT) 検証（公開鍵）の各方式に従ったファイルの生成処理が実行される。

(B) 相互認証（公開鍵）、チケット（F R T) 検証（共通鍵）

次に、相互認証処理に公開鍵方式を適用し、チケット（FRT) 検証に共通鍵方式を適用する場合の各エンティティ間のデータ転送について図 76を用いて説明する。

図に示す番号順に各エンティティ間でデ一夕転送が実行される。以下、各番号に従って処理を説明する。

( 1 ) ファイル登録チケットュ一ザ（F R T User) の公開鍵証明書（C e r t ,

FRT User) の発行、

ファイル登録チケットュ一ザ（FRT User:具体的には、デバイスに対してチケットを送信するデバイスアクセス機器としてのリーダライタ）の公開鍵証明書 (C e r t . FRT User) は、ファイル登録チケットュ一ザ（FRT User) からの発行要求により、登録局（RA) を介した証明書発行手続きによってパーテイション対応認証局（C A (PAR)) によって発行される。なお、パーティションマネージャがファイル登録チケットュ一ザ（FRT User)を兼ねる構成も可能であり、その場合は、ファイル登録チケットュ一ザ（F R T User) の公開鍵証明書としてパーティションマネージャ（PM) の公開鍵証明書を使用可能である。

(2) ファイル登録チケット（FRT) の生成処理

ファイル登録チケット（FRT) は、パーティションマネージャの管理するフアイル登録チケット発行手段（FRT Ticket Issuer) により生成される。この場合、共通鍵方式の検証値として M A C (Message Authentication Code) (図 5 9 参照）が FR Tに付加される。 (3) FRTのファイル登録チケットユーザ（FRT User) に対する供給パーティションマネージャの管理するファイル登録チケット発行手段（FRT

Ticket Issuer) により発行されたファイル登録チケット（FRT) は、ファイル登録チケットュ一ザ（FRT User)すなわち、デバイスに対してチケヅトを送信する機器（ex. デバイスアクセス機器としてのリーダライタ）に対して送信される。

(4) ファイル登録チケット発行手段とデバイス間の相互認証

パーティションマネージャ（具体的にはファイル登録チケットユーザ（FRT User) であるデバイスアクセス機器としてのリ一ダライタ）は、ファイル登録チケット発行手段（FRT Ticket Issuer) の発行したファイル登録チケヅト（F RT) に従ったファイルを生成しょうとする対象のデバイスに対し、チケットュ —ザ（FRT User) の公開鍵証明書（C e r t . F RT User) をデバイスに送信し、公開鍵方式の相互認証（図 50参照）を実行する。

(5) FRTのデバイスに対する供給

パーティションマネージャ（PM) とデバイス間の相互認証が成立すると、パ —テイシヨンマネージャ（PM) (具体的にはファイル登録チケットユーザ（FR T User)であるデバイスアクセス機器としてのリーダライタ）は、デバイスに対してファイル登録チケット（FRT) を送信する。デバイスは、受信したフアイル登録チケット（FRT) について MAC検証処理を実行し、 FRT発行者（FRT Issuer) の検証、さらに、 F R Tチケットに格納された F R Tュ一ザ（チケットユーザであるデバイスアクセス機器としてのリーダライタ）と受信したパーティシヨンマネージャの公開鍵証明書の識別データ（DN) として記録された識別子またはカテゴリまたはシリアル（SN) 名（DN) の一致を確認し相互認証済みであることを確認することにより FRTユーザ（PM：デパイスアクセス機器としてのリーダライタ）の検証（図 57、図 58参照）を実行する。

(6) FDBに S PT I Cおよび K s p tを登録

デバイスは、ファイル定義ブロック（ F D B ： File DefinitionBlock) にサ一ビス許可チケット（S PT) 発行者カテゴリ（S PT I C) (ex. デバイスのフアイル内のデータにアクセスを実行するデパイスアクセス機器としてのリーダライタ）と Kspt (サービス許可チケヅト（S P T) の MA C検証用鍵（Kspt)) を登録する（図 73のフローにおけるステップ S 827 , S 828 )o

(8) ファイルデータ領域の確保

以上の処理によって、相互認証（公開鍵）、チケット（FRT) 検証（共通鍵）の各方式に従ったファイルの生成処理が実行される。

(C) 相互認証（共通鍵）、チケット（F RT) 検証（共通鍵）

次に、相互認証処理に共通鍵方式を適用し、チケット（FRT) 検証に共通鍵方式を適用する場合の各ェンティティ間のデータ転送について図 77を用いて説明する。

( 1 ) ファイル登録チケット（FRT) の生成処理

ファイル登録チケット（FRT) は、パーティションマネージャの管理するフアイル登録チケット発行手段（ F R T Ticket Issuer) により生成される。この場合、共通鍵方式の検証値として M A C (Message Authentication Code) (図 59 参照）が FRTに付加される。

(2 ) FRTのファイル登録チケットュ一ザ（FRT User) に対する供給パーティションマネージャの管理するファイル登録チケヅト発行手段（FRT Ticket Issuer) により発行されたファイル登録チケット（F R T) は、ファイル登録チケットュ一ザ（FRT User) すなわち、デバイスに対してチケットを送信する機器（ex. デバイスアクセス機器としてのリーダライタ）に対して送信される。

(3) ファイル登録チケット発行手段とデバイス間の相互認証

パーティションマネージャ（具体的にはファイル登録チケットユーザ（FRT User) であるデバイスアクセス機器としてのリーダライタ）は、ファイル登録チケット発行手段（FRT Ticket Issuer) の発行したファイル登録チケット（F RT) に従ったファイルを生成しょうとする対象のデバイスとの間で、共通鍵方式の相互認証（図 53、図 54参照）を実行する。

(4) F R Tのデバイスに対する供給

パーティションマネージャ（PM) とデバイス間の相互認証が成立すると、ノ —テイシヨンマネージャ（PM) (具体的にはファイル登録チケットュ一ザ（FR T User)であるデバイスアクセス機器としてのリーダライタ）は、デバイスに対してファイル登録チケット（FRT) を送信する。デバイスは、受信したフアイル登録チケヅト（FRT) について M A C検証処理を実行し、 FRT発行者（FRT Issuer) の検証、さらに、 FRTチケットに格納された FRTユーザ（チケットユーザであるデバイスアクセス機器としてのリ一ダライタ）と受信したパーティションマネージャの識別子の一致を確認し相互認証済みであることを確認することにより F R Tユーザ（PM：デバイスアクセス機器としてのリ一ダライタ）の検証（図 5 7、図 58参照）を実行する。

(6) FDBに S PT I Cおよび K s p tを登録

デバイスは、ファイル定義ブロック（ F D B ： File DefinitionBlock) にサ一ビス許可チケット（S PT) 発行者カテゴリ（S P T I C) (ex. デバイスのフアイル内のデータにアクセスを実行するデバイスアクセス機器としてのリ一ダライタ）と Kspt (サービス許可チケヅト（S PT) の M A C検証用鍵（Kspt)) を登録する（図 73のフローにおけるステップ S 827 , S 828 )o

(8) ファイルデータ領域の確保

以上の処理によって、相互認証（共通鍵）、チケット（FRT) 検証（共通鍵）の各方式に従ったファイルの生成処理が実行される。

(D) 相互認証（共通鍵）、チケット（F RT) 検証（公開鍵）

次に、相互認証処理に共通鍵方式を適用し、チケット（FRT) 検証に公開鍵方式を適用する場合の各エンティティ間のデータ転送について図 78を用いて説明する。

図に示す番号順に各エンティティ間でデータ転送が実行される。以下、各番号に従って処理を説明する。 ( 1 ) ファイル登録チケット発行手段（F R T Issuer) の公開鍵証明書（C e r t . FRT Issuer) の発行、

ファイル登録チケット発行手段（F RT Issuer) の公開鍵証明書（C e r t . FRT Issuer) は、ファイル登録チケット発行手段（FRT Issuer) からの発行要求により、登録局（RA) を介した証明書発行手続きによってパーティション対応認証局（CA (PAR)) から発行される。なお、パーティシヨンマネージャがファイル登録チケット発行手段（FRT Issuer)を兼ねる構成も可能であり、その場合は、ファイル登録チケット発行手段（F RT Issuer)の公開鍵証明書としてパーティションマネージャ（PM) の公開鍵証明書を使用可能である。

(2) ファイル登録チケット（FRT) の生成処理

ファイル登録チケット（FRT) は、パーティションマネージャの管理するフアイル登録チケヅト発行手段（FRT Ticket Issuer) により生成される。この場合、公開鍵方式の署名生成、検証を実行するため、ファイル登録チケット発行手段（FRT Ticket Issuer) の秘密鍵による署名（Signature)が生成（図 1 2参照）されて F R Tに付加される。

(3) FRTおよびファイル登録チケヅト発行手段（FRT Ticket Issuer) 公開鍵証明書（C e r t . FRT Issuer) のファイル登録チケットュ一ザ（FR T User) に対する供給

パーティションマネージャの管理するファイル登録チケット発行手段（FRT Ticket Issuer) により発行されたファイル登録チケット（FRT) は、ファイル登録チケヅト発行手段（F RT Ticket Issuer) 公開鍵証明書（C e r t . F R T Issuer) とともにファイル登録チケットユーザ（FRT User) すなわち、デバイスに対してチケヅトを送信する機器（ex. デバイスアクセス機器としてのリーダライタ）に対して送信される。

(4) ファイル登録チケット発行手段とデバイス間の相互認証

パーティションマネージャ（具体的にはファイル登録チケットユーザ（FRT User) であるデバイスアクセス機器としてのリ一ダライタ）は、ファイル登録チケヅト発行手段（FRT Ticket Issuer) の発行したファイル登録チケット（F RT) に従ったファイルを生成しょうとする対象のデバイスとの間で、共通鍵方式の相互認証（図 5 3、図 54参照）を実行する。

(5) FRTおよびファイル登録チケット発行手段（FRT Ticket Issuer) 公開鍵証明書（C e r t . FRT Issuer) のデバイスに対する供給

パーティションマネージャ（PM) とデバイス間の相互認証が成立すると、パ —テイシヨンマネージャ（PM) (具体的にはファイル登録チケットユーザ（FR T User)であるデバイスアクセス機器としてのリーダライタ）は、デバイスに対してファイル登録チケヅト（FRT)、およびファイル登録チケット発行手段（F RT Ticket Issuer) 公開鍵証明書（Ce 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)の検証によりチケヅトが改竄のないことの確認を実行し、さらに、 F R Tチケットに格納された F R Tユーザ（チケットュ一ザであるデバイスアクセス機器としてのリーダライタ）とチケットユーザ（F R T User)の識別子の一致を確認し、相互認証済みであることを確認することにより FRTユーザ（デバイスアクセス機器としてのリ一ダライタ）の検証 (図 5 7、図 58参照）を実行する。

(6 ) FDBに S PT I Cおよび K s p tを登録

デパイスは、ファイル定義ブロック（F D B ： File DefinitionBlock) にサ一ビス許可チケッ卜（S PT)発行者カテゴリ（S PT I C) (ex. デバイスのフアイル内のデータにアクセスを実行するデバイスアクセス機器としてのリーダライタ）と Kspt (サービス許可チケット（S PT) の M A C検証用鍵（Kspt)) を登録する（図 73のフローにおけるステップ S 82 7 , S 828 )o

( 7 ) ファイルデータ領域の確保

以上の処理によって、相互認証（共通鍵）、チケット（FRT) 検証（公開鍵）の各方式に従ったファイルの生成処理が実行される。

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

次に、サービス許可チケット（SRT) (図 28、図 3 1参照）を利用したファィルアクセス処理について説明する。図 79以下のフロー他の図面を参照して説明する。なお、ファイルアクセス処理には、デパイスとファイルアクセス装置間における相互認証処理（デバイス認証またはパーティション認証）、サービス許可チケット（ S P T ： Service ParmissionTicket) の正当性検証処理が含まれる。図 79のフローにおいて、左側がファイルアクセス装置、右側がデバイス（図 5参照）の処理を示す。なお、ファイルアクセス装置は、パーティションマネ一ジャの管理装置であり、デバイスに対するデ一夕読み取り書き込み処理可能な装置（ex. デバイスアクセス機器としてのリーダライタ、 P C) であり、図 1 0 のデバイスアクセス機器としてのリーダライタに相当する。まず、図 7 9を用いて、ファイルアクセス装置によるファイルアクセス処理の概要を説明し、その後、当処理に含まれる各処理の詳細を図 80以下のフローを用いて順次説明する。まず、図 79のステップ S 85 1と S 860において、ファイルアクセス装置とデバイス間にでの相互認証処理が実行される。データ送受信を実行する 2つの手段間では、相互に相手が正しいデータ通信者であるか否かを確認して、その後に必要なデータ転送を行なうことが行われる。相手が正しいデータ通信者であるか否かの確認処理が相互認証処理である。相互認証処理時にセッション鍵の生成を実行して、生成したセッション鍵を共有鍵として暗号化処理を実行してデータ送信を行なう。

相互認証処理については、先のパーティション生成、削除処理の欄で説明したと同様の処理であり、パーティション認証が実行される。それそれについて共通鍵方式認証、あるいは公開鍵方式認証処理のいずれかが適用される。この相互認証処理は、前述の図 48〜図 56を用いて説明したと同様の処理であるので説明を省略する。なお、相互認証処理として実行すべき処理は、適用するサービス許可チケット (S PT) (図 28、図 3 1参照）の

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

によって泱定される。

認証処理に失敗した場合（ S 852， S 86 1で N o ) は、相互が正当な機器、デバイスであることの確認がとれないことを示し、以下の処理は実行されずエラ —として処理は終了する。

デバイスは、複数のサービス許可チケット（S PT) に基づく複数の異なるパ

—テイシヨン内のファイルアクセスを許容する処理も可能である。例えば、デバイス認証の成立を条件としそ、複数のサービス許可チケット（S PT) に基づく複数の異なるパーティション内のファイルアクセスを許容することが可能である < 各パーティション毎のファイルアクセスルールは、アクセス制御データとして構成されるサービス許可チケット（SP T) に記述され、デバイスは、アクセス機器から複数のサ一ビス許可チケット（S PT) を受領し、各チケットがデバイス認証を要求している場合は、記述に従ってデバイス認証が成立したことを条件として各パ一ティション内のファイルアクセスを許容する。

また、デバイスは、複数のサービス許可チケット（S P T) の各々が異なる認証条件を定めている場合は、各サービス許可チケット（S PT) に設定されたパーテイシヨン認証の認証成立を条件として、複数のサービス許可チケット（S P T) の指定ファイルに対するアクセスを許容する。

次にステップ S 85 3において、ファイルアクセス装置は、デバイスに対してサ一ビス許可チケット（ S P T ： Service Parmission Ticket) を送信する。サ一ビス許可チケット（S PT) は、パーティションマネージャの管理下のサービス許可チケット（ S P T) 発行手段（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 P T) を受信（ S 862 ) したデバイスは、受信したチケット（S RT) の正当性と利用者チェック処理を実行（S 863 ) する。チケットの正当性の検証処理は、共通鍵方式による MA C検証、あるいは公開鍵方式による署名検証処理のいずれかを適用して実行される。利用者チヱックは、チケヅトを送信してきた機器（チケット利用者）の正当性をチェックする処理であり、相互認証が成立済みであり、認証相手の識別データと、チケットに記録されているチケットュ一ザ識別子（図 28、図 3 1参照）との一致等を検証する処理として実行される。これらの処理は、先のパーティション登録チケット（P R 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で Y e s ) すると、 S P T受理成功をファイルアクセス装置に通知（S 867) する。一方、ファイルのオープン処理に失敗（ S 866で N o ) した場合は、 S P T受理エラ一をファイルアクセス装置に通知（S 868 ) する。ファイルアクセス装置は、 S P T受理結果を受信（ S 8 54 ) し、 S PT処理結果を判定し、 S P T受理結果がエラ一である場合（S 8 55で N o) は、エラ —として処理を終了し、 S P T受理結果が成功（S 855で Ye s) である場合は、すべての S P T送信が終了したか否かを判定（S 85 6 ) し、未送信 S P T がある場合は、ステップ S 853以下を繰り返し実行する。

すべての S P T送信が終了した場合は、ステヅプ S 85 7、 S 869においてサービス許可チケット（S P T) に従ったファイルアクセスを実行し、ファイルアクセス処理の終了の後、セッションクリアコマンドの送受信（ S 858 , S 8

7 0) を実行し、デバイス側に生成した認証テーブルを破棄（S 87 1 ) し、処理を終了する。ファイルアクセス処理の詳細については、別フ口一を用いて後段で詳述する。なお、認証テ一ブルは、ステップ S 85 1， S 860の相互認証処理において生成されるテーブルであり、前述したパーティション登録チケット（ P R T) の適用処理の項目において説明した構成、すなわち、図 5 1の構成と同様のものである。

このようにサービス許可チケット（SP T) を利用して、デバイス内に設定されたパーティション内のファイルに対するアクセス処理が実行される。以下、当処理に含まれるファイルオープン処理（ S 86 5 )、各種ファイルアクセス処理（ S

857 , S 86 9 ) について説明する。

(フアイルオープン処理）

図 80のフローに従って、フアイルオープン処理（図 7 9、 S 86 5 ) について説明する。ファイルオープン処理は、デバイスが受信したサービス許可チケット（S PT) に従って実行する処理である。

ステップ S 88 1において、デバイスは、受信したサービス許可チケット（S P T) に指定されたファイルがデバイス内に生成されて存在しているか否かを判定する。サービス許可チケット（ S P T) には処理対象ファイルのファイル I D が記録（図 2 8、図 3 1参照）されており、同一の I Dを持つファイルの有無を例えばファイル定義ブロック（図 24) を参照して判定する。チケットに記述された I Dと同一 I Dのファイルが存在しない場合は、処理が不可能であるのでェラ一終了する。

チケットに記述された I Dと同一 I Dのフアイルが存在する場合は、ステップ S 882において、ファイルオープンテ一ブルにサービス許可チケヅト（ S P T ) に記述されたチケット発行手段（Ticket issuers PMC： Partition manager Code)と、サービス許可チケット（S P T) に記述されたファイル I Dとを対応付けたェントリを書き込む。

さらに、ステップ S 883において、ファイルォプンテーブルに生成したェントリに対応付けてサービス許可チケット（S PT) に記述されたファイルァクセスモード [File Access Mode ：アクセスを許諾するファイル（File) へのァクセスモード（Access Mode)] を書き込み、ステヅプ S 884において、サービス許可チケット（S P T) に記述されたアクセス許可グループファイル [Group of Target File：アクセスを許すファイル（File) のグループ（Group)] を書き込み、ステップ S 885において、サービス許可チケット（S P T) に記述されたァクセス許可ファイル識別子 [Target File ID ：アクセスを許すファイル（File) の識別子（ I D)] の書き込み、さらにステップ S 886において、サービス許可チケット（S PT) に記述されたタ一ゲヅトファイル（Target File)) に対する処理態様データ [Read/Write Permission：アクセスを許すファイル（File) (夕一ゲヅトファイル（Target File)) に対する処理態様（読み出し（Read) ，書き込み (Write) の許可）] の書き込み処理を行なう。なお、ターゲットファイルに対する処理としては、読み出し（Read) ，書き込み（Write) に限らず、様々な処理を設定可能である。

ファイルオープンテ一ブルの構成例を図 8 1、図 82に示す。ファイルォ一プンテ一ブルは、デバイスにおいてアクセス処理状態にあるファイルおよびァクセスモ一ド他の情報を記録したテーブルであり、デバイスが受信したサービス許可チケット（SP T) の記述情報を記録してデバイスの記憶手段に格納する。

チケットが唯一のファイルに対してのみアクセスを許可する形式のサービス許可チケット（図 28参照）である場合は、ファイルオープンテーブルは、

*Ticket Issuer ：チケット発行手段（Ticket Issuer) の識別子

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

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

の情報を格納する。この場合のファイルオープンテーブルの構成例を図 8 1に示す。

図 8 1に示すように、ファイルオープンテ一ブルにはグループ情報である Ticket Issuer ：チケット発行手段（Ticket Issuer) の識別子として、パ一ティシヨンマネージャコード（PMC) が記述され、パーティションが判別され、フアイル I Dによりファイルが識別され、ファイルアクセスモードにより実行可能なアクセス態様（ex. 読み取り（READ)、書き込み（Wr i t e；)、暗号化復号化（E n c , D e c)) が判定可能となる。

また、サービス許可チケット（S P T) がパーティションに設定されたフアイル中の複数ファィルに対してアクセスを許可する形式のサービス許可チケット (図 3 1参照）の場合は、上記情報に加えて

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

の各情報がテ一ブルに書き込まれる。この場合のファイルオープンテーブルの構成例を図 82に示す。

図 82に示すように、複数ファイルに対してアクセスを許可する形式のサ一ビス許可チケットに対応して設定されるファイルオープンテ一ブルには、図 8 1に示すデータの他に、アクセスを許すターゲットファイル（File) のグループとしてのパ一テイション識別データとしてのパ一テイションマネージヤコ一ド（P M C) と、アクセスを許すターゲットファイル（File) の識別子（ I D) としてのファイル I Dと、ターゲットファイル（Target File)) に対する処理態様を示す [Read/Write Permission]データが格納され、複数ファイルに対する実行可能な処理が判定可能となる。

複数のファイルに対してアクセスを実行する処理とは、例えばファイル Aに格納された鍵を用いて、ファイル Bに格納されたデータを暗号化する処理を実行する場合などである。このためには、ファイル Bはファイル Aの読み出し要求に対して許可を与える必要がある。この場合、ファイル Bのことをソースファイル、許可を与える相手のフアイルのことを夕一ゲットフアイルと呼ぶ。

このように、デバイスは、アクセス機器とのセッション中に受領したサービス許可チケット（ S P T) に基づいて、チケット発行手段（Ticket Issuer(PMC)) としてのパーティションマネージヤコ一ド（P M C)、ファイルオープン処理を実行したファイルの識別データとしてのファイル識別子と、サービス許可チケット ( S P T) に記述されたアクセスモードを対応付けたファイルオープンテーブルを生成し、該ファイルオープンテーブルを参照して前記アクセス機器からの受領コマンドの実行の可否の判定が可能となる。

(ラアイルアクセス処理）

次に、図 7 9のステップ S 8 5 7、 S 8 6 9において実行されるファイルァクセス処理の詳細について説明する。

まず、図 8 1に示すファイルオープンテーブルが生成された場合のアクセス処理について、図 8 3を用いて説明する。図の左側に 2つのファイルアクセス装置 (R/W：デバイスアクセス機器としてのリーダライタ） 7 5 0、 7 6 0を示し、右側にファイルの生成されたデバイス 1 0 0のパ一ティション部分を示す。

ファイルアクセス装置（R/W：リ一ダライタ） 7 5 0は、デバイスとの相互認証の後、

ファイル I D : [ 0 x 0 0 0 2 ]

ファイルアクセスモード： [読み取り： R e a d ]

のアクセス許可チケヅトをデバイス 1 0 0に送信し、チケットの正当性検証、チケット発行者、利用者検証に成功したとする。

このとき、デバイスには図 8 1に示すファイルオープンテーブルの第 2行のェントリが生成される。このエントリは、パーティションマネージャコード（P M C 1 ) で識別されるパ一テイシヨン内のファイル I D [ 0 x 0 0 0 2 ] に対してアクセスモード [読み取り： R e a d ] の処理が実行可能であることを示している。

このとき、ファイルアクセス装置（R/W：リーダライタ） 7 5 0は、コマンドを生成してデバイスに対して送信する。例えばファイル I D [ 0 x 0 0 0 2 ] のデータ読み取りコマンド： R e a d C o mm a n d ( 0 x 0 0 0 2 ) をデバイスが受信すると、デバイスはファイルオープンテーブルのエントリを確認し、フアイル I D [ 0 x 0002 ] に対してアクセスモード [読み取り： R e a d] の処理が実行可能であることを確認し、読み取り処理を実行する。

また、ファイルアクセス装置（R/W：リ一ダライタ） 750が、例えばファィル I D [ 0 X 0002 ] のデータ書き込みコマンド： Wr i t e Co mm an d (0 x 0002 )、あるいはファイル I D [ 0 x 0 0 0 1 ] のデータの暗号化処理コマンド： E n c r yp t i o n C omma nd (0 x 00 0 1 )をデバイスに送信した場合は、コマンドを受信したデバイスはファイルオープンテ一ブルのエントリを確認し、ファイル I D [ 0 x 0 002 ] に対する [書き込み： Wr i t e ] の処理、および、ファイル I D [ 0 X 0 00 1 ] の [暗号化処理] が、フアイルアクセス装置（R/W：リーダライタ） 750から受領したサービス許可チケット（S PT) によって許可されていないことを確認し、処理を停止する。また、ファイルアクセス装置（R/W：リ一ダライタ） 7 60は、デバイスとの相互認証の後、

ファイル 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 000 1に対してアクセスモード [暗号化復号化処理： En c &D e c ]の処理が実行可能であることを確認し、暗号化処理を実行する。また、ファイルアクセス装置（R/W：リーダライタ） 7 60が、例えばファィル I D [0 x 0002]のデ一夕読み取りコマンド： R e ad C omma nd ( 0 x 0002 ) をデバイスに送信した場合は、コマンドを受信したデバイスはファイルオープンテ一ブルのエントリを確認し、ファイル I D [ 0 x 0002 ] に対する [読み取り： R e a d] の処理が、ファイルアクセス装置（R/W：リ —ダライタ） 7 6 0から受領したサービス許可チケット（S PT) によって許可されていないことを確認し、処理を停止する。

このように、サービス許可チケットュ一ザであるデバイスアクセス機器としてのリーダライタからデバイスが受信したサービス許可チケット（S PT) に基づいて、デバイスは、前述の図 80の処理フローに従ってファイルオープンテ一ブルを生成し、生成したファイルオープンテ一ブルに基づいてファイルアクセス装置であるリ一ダライタからの各コマンドの実行可否を決定し、決定に従って処理を実行する。

次に、 2つのファイルに対する処理を実行する場合のアクセス処理について、図 84を用いて説明する。図の左側に 2つのファイルアクセス装置（R/W : リ —ダライタ） 7 7 0、 780を示し、右側にファイルの生成されたデバイス 1 0 0のパーティション部分を示す。

まず、ターゲットファイルを指定したサービス許可チケット（S P T) (図 3 1 参照）を使用した処理の実行例を説明する。

ファイルアクセス装置（R/W：リーダライタ） 770は、デバイスとの相互認証の後、

S P Tフォーマツト 1

ファイル I D : [0 x 000 1 ]

および、 S PTフォーマット 2

ファイル I D : [0 x 0002]

夕一ゲットファイル ' グループ： [PMC 1 ]

ターゲットファイル I D : [ 0 x 000 1 ]

読書き許可： [読み取り： Re ad] の 2つのアクセス許可チケットをデバイス 1 00に送信し、チケヅトの正当性検証、チケット発行者、利用者検証に成功したとする。

このとき、デパイスには図 82に示すファイルオープンテーブルのエントリが生成される。このエントリは、パーティションマネージャコード（PMC 1 ) で識別されるパ一ティシヨン内のファイル I D [0 x 0 00 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 0 0 02 ] の読み取り、ファイル 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 000 1 , 0 x 00 0 2) を送信し、デバイスがコマンドを受信すると、デバイスはファイルオープンテ一ブルのェントリを確認し、ファイル I D [ 0 X 0 002 ] に対して、タ一ゲットフアイルグループ [P M C 1 ]、夕一ゲヅトファイル [0 x 000 1 ] の [暗号化処理] に対して [読み取り： R e a d] を実行可能であることを判定し、フアイル I D [0 x 0000 2] のデ一夕を読み取り、ファイル I D [0 00 0 0 1 ] の鍵（k e y) による暗号化を実行して暗号化データをアクセス装置に送信する。

この夕一ゲットファイルを指定したサービス許可チケット（SPT) (図 3 1参照）を使用した処理によればあるファイルから読み出したデータを他のファイルに格納された暗号化鍵を用いて暗号化したデータを取得する処理が可能となり、復号データが外部に漏れるおそれがない。

次に、ターゲットファイルを指定したサービス許可チケット（S PT) (図 3 1 参照）ではなく、唯一のファイルに対する処理を指定したサービス許可チケット (S PT) (図 28参照）を複数用いた場合の処理について説明する。ファイルアクセス装置（R/W：リ一ダライタ） 780は、デバイスとの相互認証の後、

S PTフォ一マツト 1として、

ファイル I D : [ 0 x 0002 ]

ファイルアクセスモード： [読み取り： R e a d]

また SPTフォーマツト 2として、

ファイル I D : [0 x 0 00 1 ]

の 2つのアクセスチケットをデバイス 1 00に送信し、チケヅトの正当性検証、チケット発行者、利用者検証に成功したとする。

このとき、デバイスには図 8 1に示すファイルオープンテーブルの第 1行および第 2行の各エントリが生成される。このエントリは、パーティションマネージヤコ一ド（ P M C 1 ) で識別されるパーテイシヨン内のファイル I D [0 x 00 0 1 ] に対してアクセスモード [暗号化復号化処理： E n c & D e c] の処理が実行可能であり、パーティションマネージャコード（PM C 1 ) で識別されるパ —テイシヨン内のファイル I D ： 0x 0002に対してアクセスモード [読み取り： R e a d] の処理が実行可能であることを示している。

このとき、フアイルアクセス装置（R/W：リ一ダライタ） 780は、コマンドを生成してデバイスに対して送信する。まず、ファイル I D : [0 x 0002] のデータ読み取りコマンド： R e a d C o mm a n d ( 0 x 0 002 ) をデパイスが受信すると、デバイスはファイルオープンテーブルのエントリを確認し、フアイル 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 ommand (0 x 000 1 , D a t a)] をデバイスが受信すると、デバイスはファイルォ一プンテ一ブルのェントリを確認し、ファイル I D [ 0 x 0 00 1 ] に対してァクセスモ一ド [暗号化復号化処理： E n c &D e c ] の処理が実行可能であることを確認し、暗号化処理を実行し暗号化データ [E nc r yp t i o n D a t a] をファイルアクセス装置（R/W：リ一ダライタ） 780に送信する。

このように、ターゲットファイルを指定したサービス許可チケット（S PT) (図 3 1参照）ではなく、唯一のファイルに対する処理を指定したサービス許可チケット（S P T) (図 28参照）を複数用いた場合は、暗号化対象データの読み出し処理が実行され、ファイルアクセス装置 7 80とデバイス間におけるデータ転送処理の回数が増加することになる。また、デ一夕が暗号化されずにデバイスの外に読み出されてしまう。

一方、サービス許可チケット（ S P T) (図 3 1参照）に、アクセス対象とした複数のデータファイルを識別する複数のファイル識別子を含ませ、該複数のファィル識別子中、一方は夕一ゲットファイル識別子として設定するとともにタ一ゲットファイルに対する読み取りまたは書き込み許可データを格納し、他方のデ一夕ファイルのアクセスモードとして該データファイルに格納した暗号鍵を用いた暗号化処理を設定した構成とすれば、メモリ搭載デバイスは、アクセス機器からサービス許可チケット（S PT) を受領して、指定アクセスモードに従った処理として、ターゲットファイルの読み取りおよび暗号鍵による暗号化処理を実行することになり、メモリ搭載デバイス内における内部暗号化処理を実行することが可能となる。また、データが暗号化されずにデバイスの外に流出することを防止することができる。

サービス許可チケット（S PT) を発行するチケット発行手段は、メモリ搭載デパイスのメモリ領域を管理するェンティティであるパーティションマネージャの管理下にあるチケット発行手段であり、各アクセス機器に応じて各種のァクセスモードを設定したサービス許可チケット（S PT) を個別に発行することにより、各アクセス機器に応じて異なる態様のアクセスを実行可能とした構成が実現される。

(セッション鍵の使用態様）

なお、ファイルアクセス装置とデバイス間において送受信されるデータは、デバイスのユーザ情報、あるいは金額情報など外部に対する漏洩を防止すべきデ一夕であることが多い。従ってファイルアクセス装置とデパイス間において送受信されるデータは、暗号化処理を実行し、また改竄チェック値としての M A C (Message Authenticati on Code) を付加したデータとするのが望ましい。

データの暗号化には、ファイルアクセス装置とデバイス間において実行される相互認証処理において生成されるセッション鍵を用いることが可能である。前述したように相互認証には、デバイスに対するデバイス認証、各パーティションに対する認証としてのパーティション認証がある。パーティションに生成済みのフアイルに対するアクセスを実行する場合、データ転送の際に適用する暗号化鍵としていずれを適用するかはいくつかの選択肢がある。

例えば図 8 5に示すように、デバイス 1 0 0 とアクセス装置 8 0 0との間において、デバイス認証によって生成されたセヅション鍵 K s e s 1、パーティションマネージヤコ一ド（P M C 1 ) に対応するパーティションとのパーティション認証によって生成されたセッシヨン鍵 K s e s 2、パーティションマネージヤコ —ド（P M C 2 ) に対応するパーティションとのパーティション認証によって生成されたセッション鍵 K s e s 3がある場合がある。

これらは、相互認証の際に生成される認証テ一ブル（図 5 1、図 5 2参照）にセッションクリアまで格納される。

デバイスとデバイスとの通信を実行するデバイスアクセス機器としてのリ一ダライタ（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- XOR ：排他論理和処理（ex. 8バイト処理）

によって算出された K s e sをセッション鍵として用いる。

デバイスとデパイスとの通信を実行するデバイスアクセス機器としてのリーダライタ（P C他の通信装置）間では、双方の認証テ一ブルに格納されたセッション鍵を排他論理和演算しその出力値をセッシヨン鍵として使用するというルールを定め、該ルールに基づいてセッション鍵を算出して通信データの暗号化に用いる構成とする。また、同様にして、相互認証時に同時に共有した別のセッション鍵、例えば公開鍵認証時において生成したセッション鍵、あるいはセッション鍵生成データ、例えば Y座標の下位 64ビットを用いてセッション中の通信データに MAC値を付加することができる。この MAC値を通信データ（暗号化データである場合もある）とともに送信し、受信側で MA C検証処理を行なうことで、通信路上のデータ改竄を防止することが可能となる。 MAC生成、検証処理については先に説明した図 59を参照されたい。

あるいは、デバイスとデバイスとの通信を実行するデバイスアクセス機器としてのリ一ダライタ（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 C ommand (0 x 0002 )、あるいは、ファイル I D [0 x 0 00 1 ]の暗号化コマンド [E n c r yp t i o n C ommand (0 x 000 1 )] などである。

デバイスは、ファイルアクセス装置からのコマンドを受信（S 9 0 1 ) すると、コマンドに含まれるファイル I D、アクセスモードがフアイルオープンテーブルに許可されたェントリとして記録されているか否かを判定（ S 902 ) する。フアイルオープンテ一ブルにコマンドに対応するファイル I D、アクセスモードのエントリが存在しない場合は、コマンドに従った処理を実行せず、アクセスエラ —をファイルアクセス装置に送信（S 908) する。

ファイルオープンテ一ブルにコマンドに対応するファイル I D、アクセスモ一ドのエントリが存在した場合は、ステップ S 9 0 3において、デバイスのメモリ内の対応パーティションのファイル定義プロヅク（ F D B ) (図 2 4参照）に記録されたファイルアクセス認証方式（Acceptable Authentication Type ：特定のフアイル（Fi le) アクセスを行う際に、指定する認証方式）を参照し、アクセス対象のファイルに対するアクセスコマンドの実行に必要な認証レベル（公開鍵認証を必要とするか）を確認する。

ステップ S 9 0 3において、ファイル定義ブロック（F D B ) のファイルァクセス認証方式（Acceptabl e Authentication Type) が公開鍵認証を必要とする設定である場合は、ステップ S 9 0 4において、アクセスコマンドに必要な認証レベルの認証としての公開鍵認証が済んでいるか否かを判定し、認証未了の場合は、コマンドに従った処理を実行せず、アクセスエラ一をファイルアクセス装置に送信（S 9 0 8 ) する。認証の終了または未了は、相互認証時に設定される認証テ —ブル（図 5 1参照）に基づいて判定される。

ステップ S 9 0 3において、ファイル定義ブロック（F D B ) のファイルァクセス認証方式（Acceptable Authentication Type) が公閧鍵認証を必要とする設定であり、ステップ S 9 0 4において、公開鍵認証が済んでいると判定された場合、あるいは、ファイル定義ブロック（F D B ) のファイルアクセス認証方式 (Acceptable Authenticati on Type) が公開鍵認証を必要としない設定である場合は、次に、ステップ S 9 0 5において、デバイスのメモリ内の対応パ一テイションのファイル定義プロヅク（F D B ) (図 2 4参照）に記録されたファイルァクセス検証方式（Acceptable Veri f ication Type ：特定のファイル（Fi le) ァクセスを行う際に、指定する検証方式）を参照し、アクセス対象のファイルに対するアクセスコマンドの実行に必要な検証レベル（公開鍵方式の検証を必要とするか）を確認する。

ステップ S 9 0 5において、フアイル定義プロヅク（F D B ) のファイルァクセス検証方式（Acceptable Verif ication Type) が公開鍵方式のチケット検証を必要とする設定である場合は、ステップ S 9 0 6において、アクセスコマンドに必要な検証レベルの検証としての公開鍵方式のチケット検証が済んでいるか否かを判定し、検証未了の場合は、コマンドに従った処理を実行せず、アクセスエラ —をファイルアクセス装置に送信（S 908) する。

ステップ S 905において、ファイル定義ブロック（FDB) のファイルァクセス検証方式（Acceptable Verification Type) が公開鍵方式のチケット検証を必要とする設定であり、ステップ S 9 06において、公開鍵方式のチケット検証が済んでいると判定された場合、あるいは、ファイル定義ブロック（FDB) のファイルアクセス検証方式（Acceptable Verification Type) が公開鍵方式のチケット検証を必要としない設定である場合は、ステップ S 907において、ファィルアクセス装置から受信したアクセスコマンドの処理を実行し、結果をフアイルアクセス装置に送信する。

アクセスコマンド結果を受信（S 892 ) したファイルアクセス装置は、さらに他のファイルアクセスを実行するか否かを判定（S 893 ) し、他のファイルアクセスを実行する場合は、ステップ 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 0 00 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 9 2 1)すると、ファイルオープンテーブルのターゲットファイル I Dのエントリにアクセスコマンドの許可があるか否かを判定（ S 9 2 2 ) する。ファイルオープンテ一ブルの夕一ゲットファイル I Dのェントリにアクセスコマンドの許可が存在しない場合は、コマンドに従った処理を実行せず、アクセスエラ一をファイルアクセス装置に送信（S 9 3 4 ) する。

ファイルオープンテ一ブルの夕一ゲットファイル I Dのェントリにアクセスコマンドの許可が存在した場合は、ステップ S 9 2 3において、デバイスのメモリ内の対応パ一テイションのファイル定義プロック（ F D B ) (図 2 4参照）に記録されたファイルアクセス認証方式（Acceptable Authentication Type ：特定のフアイル（Fi le) アクセスを行う際に、指定する認証方式）を参照し、アクセス対象のターゲットファイルに対するアクセスコマンドの実行に必要な認証レベル (公開鍵認証を必要とするか）を確認する。

ステップ S 9 2 3において、アクセス対象のタ一ゲットファイルに対して設定されたフアイル定義プロック（F D B )のフアイルアクセス認証方式（Acceptable Authenticati on Type) が公開鍵認証を必要とする設定である場合は、ステップ S 9 2 4において、アクセスコマンドに必要な認証レベルの認証としての公開鍵認証が済んでいるか否かを判定し、認証未了の場合は、コマンドに従った処理を実行せず、アクセスエラ一をファイルアクセス装置に送信（S 9 3 4 ) する。認証の終了または未了は、相互認証時に設定される認証テーブル（図 5 1参照）に基づいて判定される。

ステップ S 9 2 3において、アクセス対象のターゲットファイルに対して設定されたファイル定義プロック（F D B )のフアイルアクセス認証方式（Acceptable Authentication 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：特定のファイル（Fi 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において、アクセス対象の夕一ゲットファイルに対して設定されたファイル定義プロヅク（F D B )のファイルアクセス検証方式（Acceptable Veri f ication Type) が公開鍵方式のチケット検証を必要とする設定であり、ステップ S 9 2 6において、公開鍵方式のチケット検証が済んでいると判定された場合、あるいは、ファイル定義ブロック（F D B ) のファイルアクセス検証方式 (Acceptable Verif ication Type) が公開鍵方式のチケット検証を必要としない設定である場合は、次に、ステップ S 9 2 7において、アクセスコマンドに含まれる夕一ゲットファイル I Dによって指定されるファイルのアクセス方法 (Read/Wri te) をコマンドに基づいて確認する。

デバイスは、ファイルアクセス装置からのコマンドに含まれるソースファイル I Dによって指定されるファイルがアクセスコマンドに含まれるアクセス方法 (Read/Write) に対してオープンしているか否かを判定（ S 9 2 8 ) する。ファィルオープンテ一ブルにコマンド実行のためのアクセス方法（Read/Write) が存在しない場合は、コマンドに従った処理を実行せず、アクセスエラーをファイルアクセス装置に送信（S 9 3 4 ) する。

ファイルオープンテーブルにコマンドに対応するアクセス方法（Read/Write) が存在した場合は、ステップ S 9 2 9において、デバイスのメモリ内の対応パーティシヨンのファイル定義ブロック（F D B ) (図 2 4参照）に記録されたフアイルアクセス認証方式（Acceptable Authenti cation Type ：特定のファイル（Fi le) アクセスを行う際に、指定する認証方式）を参照し、アクセス対象のソースファィルに対するアクセスコマンドの実行に必要な認証レベル（公開鍵認証を必要とするか）を確認する。

ステップ S 92 9において、アクセス対象のソースファイルに対して設定されたファイル定義ブロック（FD B) のファイルアクセス認証方式（Acceptable Authentication Type) が公開鍵認証を必要とする設定である場合は、ステップ S 930において、アクセスコマンドに必要な認証レベルの認証としての公開鍵認証が済んでいるか否かを判定し、認証未了の場合は、コマンドに従った処理を実行せず、アクセスエラ一をファイルアクセス装置に送信（S 934) する。認証の終了または未了は、相互認証時に設定される認証テーブル（図 5 1参照）に基づいて判定される。

ステップ S 9 29において、アクセス対象のソースファイルに対して設定されたファイル定義ブロック（FD B) のファイルアクセス認証方式（Acceptable Authentication Type) が公開鍵認証を必要とする設定であり、ステップ S 9 3 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 9 3 2において、アクセスコマンドに必要な検証レベルの検証としての公開鍵方式のチケット検証が済んでいるか否かを判定し、検証未了の場合は、コマンドに従った処理を実行せず、アクセスエラーをファイルアクセス装置に送信（S 934 ) する。

ステップ S 93 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) を規定し、ファイル内の金額データとしての [Pu 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 PT) を生成して、ファイルァクセス装置からデバイスに対して送信した後、レシート生成コマンド（Make Receipt Co匪 and) とともに、引き出し金額データを送信することにより、図 88 (b) に示すようなデパイスにおいて 1つのファイル内のデータに対するシ一ケンシャル処理を実行させることが可能となる。

このようにデバイスは、サービス許可チケット（S P T) に指定された処理フアイルが複合ファイルである場合、アクセス機器からの受領コマンドの処理対象ファイルを複合ファイル内から選択して処理を実行する。アクセス機器からのデ —夕処理コマンドが一連の複数の処理を含むシーケンス処理コマンドである場合は、デバイスは、シーケンス処理コマンドに含まれる各コマンドの処理対象ファィルを、サービス許可チケット（S P T) によって指定された複合ファイル内から順次選択して実行する。

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

上述したサービス許可チケット（S PT) を利用したアクセス処理ファイルの設定登録処理において、パーティションマネージャが管理し、サービス許可チケット（S P T) ユーザであるデパイスアクセス機器としてのリーダライタとデバイス間において、相互認証が実行され、サービス許可チケット（S PT) に基づくファイルアクセスがなされる。相互認証処理の態様は、公開鍵相互認証、共通鍵相互認証の 2種類のいずれかであり、またチケット（S PT) の検証処理も公開鍵系の署名検証、共通鍵系の M A C検証の 2種類のいずれかが実行されることになる。すなわち処理態様としては大きく分けて、

(A) 相互認証（公開鍵）、チケット（S PT) 検証（公開鍵）

(B) 相互認証（公開鍵）、チケット（S P T) 検証（共通鍵）

( C) 相互認証（共通鍵）、チケット（S P T) 検証（共通鍵）

(D) 相互認証（共通鍵）、チケット（S P T) 検証（公開鍵）

の 4態様がある。

これらの 4態様についての処理を、認証局（CA (PM))、パーティションマネ一ジャ（PM)、 S P Tチケットュ一ザであるデバイスアクセス機器としてのリ —ダライタ、デバイス、各エンティティ間において実行されるデ一夕転送処理を中心として図を用いて簡潔に説明する。

(A) 相互認証（公開鍵）、チケット（S P T) 検証（公開鍵）

まず、相互認証処理に公開鍵方式を適用し、チケット（S PT) 検証に公開鍵方式を適用する場合の各エンティティ間のデータ転送について図 89を用いて説明する。

( 1 ) パーティションマネージャ（PM) の公開鍵証明書（Ce r t . PM) の発行、

パ一テイシヨンマネージャ（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 P T User) を兼ねる構成も可能であり、その場合は、サービス許可チケットュ一ザ（ S P T 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 P Tおよびサービス許可チケット発行手段（S P T Ticket Issuer) としてのパーティションマネージャ公開鍵証明書（C e 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 P T User)であるデバイスアクセス機器としてのリ一ダライタ（R/W) に対して送信される。

(5) デパイスアクセス機器としてのリーダライタ（R/W) とデバイス間の相互認証

サービス許可チケットユーザ（S P T User) であるリーダライタは、サービス許可チケット発行手段（S PT 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 P T)、およびサービス許可チケヅト発行手段（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 PM) のオプション領域に記録されたコードと、デバイス内の 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 PTユーザ（デパイスアクセス機器としてのリ一ダライタ）の検証（図 57、図 58参照）を実行する。

(7) ファイルアクセス

デバイスは、処理対象ファイルにサービス許可チケット（S PT) に記述されたルールに従ってアクセスを実行する。

以上の処理によって、相互認証（公開鍵）、チケット（S P T) 検証（公開鍵）の各方式に従ったファイルアクセス処理が実行される。

(B) 相互認証（公開鍵）、チケット（S P T) 検証（共通鍵）

次に、相互認証処理に公開鍵方式を適用し、チケット（S PT) 検証に共通鍵方式を適用する場合の各エンティティ間のデータ転送について図 90を用いて説明する。

( 1 )サービス許可チケットュ一ザ（ S P T User)であるデバイスアクセス機器としてのリーダライタ（R/W) の公開鍵証明書（Ce r t . RW) の発行、サービス許可チケットュ一ザ（ S P T User：具体的には、デバイスに対してチケットを送信するデバイスアクセス機器としてのリーダライタ（R/W))の公開鍵証明書（C e r t . R/W) は、サ一ビス許可チケヅトユーザ（S P T User) であるリ一ダライタ（RZW) からの発行要求により、登録局（RA) を介した証明書発行手続きによってパーティション対応認証局（CA (PAR)) によって発行される。なお、パーティションマネージャがサービス許可チケットユーザ（ S PT User) を兼ねる構成も可能であり、その場合は、サービス許可チケットュ一ザ（S PT User) の公開鍵証明書としてパーティションマネージャ（PM)の公開鍵証明書を使用可能である。

( 2 ) サービス許可チケヅト（ S P T) の生成処理

サービス許可チケット（S PT) は、パーティションマネージャの管理するサ —ビス許可チケット発行手段（S P T Ticket Issuer) により生成される。この場合、共通鍵方式の検証値として M A C (Message Authentication Code) (図 5 9 参照）が S P Tに付加される。

(3) S Ρ Τのサ一ビス許可チケットュ一ザ（ S P T User)であるデパイスァクセス機器としてのリーダライタ（R/W) に対する供給

パーティションマネージャの管理するサービス許可チケット発行手段（S P T Ticket Issuer) により発行されたサービス許可チケット（S P T) は、サービス許可チケットユーザ（S P T User) としてのリーダライタ（R/W) に対して送信される。

(4) リーダライタ（R/W) とデパイス間の相互認証

サービス許可チケットユーザ（S P T User)であるデバイスアクセス機器としてのリーダライタは、サービス許可チケット発行手段（ S P T 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 PT) を送信する。デバイスは、受信したサービス許可チケット（S P T) について M A C検証処理を実行し、 S P T発行者（SPT Issuer) の検証、さらに、 S P Tチケットに格納された S P Tユーザ（チケットユーザとしてのリ一ダライタ）とチケットユーザ（S P T User) の公開鍵証明書（C e r t . RW) の識別データ（DN) として記録された識別子またはカテゴリまたはシリアル（SN) 名（DN) の一致を確認し、相互認証済みであることを確認することにより S P Tユーザ（デバイスアクセス機器としてのリーダライ夕）の検証（図 57、図 58参照）を実行する。

(6) ファイルアクセス

デパイスは、処理対象ファイルにサービス許可チケット（S PT) に記述されたルールに従ってアクセスを実行する。以上の処理によって、相互認証（公開鍵）、チケット（S PT) 検証（共通鍵）の各方式に従ったファイルアクセス処理が実行される。

(C) 相互認証（共通鍵）、チケット（S P T) 検証（共通鍵）

次に、相互認証処理に共通鍵方式を適用し、チケット（S PT) 検証に共通鍵方式を適用する場合の各エンティティ間のデ一夕転送について図 9 1を用いて説明する。

( 1 ) サービス許可チケヅト（S P T) の生成処理

サ一ビス許可チケット（S P T) は、パーティションマネージャの管理するサ —ビス許可チケット発行手段（S PT Ticket Issuer) により生成される。この場合、共通鍵方式の検証値として M A C (Message Authentication Code) (図 59 参照）が S P Tに付加される。

( 2 ) S Ρ Τのサービス許可チケットュ一ザ（ S P T User) に対する供給パーティションマネージャの管理するサービス許可チケヅト発行手段（S P T Ticket Issuer) により発行されたサービス許可チケット（S P T) は、サービス許可チケットュ一ザ（S P T User)であるデバイスアクセス機器としてのリーダライタに対して送信される。

( 3 ) デバイスアクセス機器としてのリーダライタ（R/W) とデバイス間の相互認証

サ一ビス許可チケットュ一ザ（S P T User)であるデバイスアクセス機器としてのリーダライタ（R/W) は、サービス許可チケヅト発行手段（S P T Ticket Issuer) の発行したサービス許可チケット（S P T) に従ったファイルを生成しようとする対象のデバイスとの間で、共通鍵方式の相互認証（図 5 3、図 54参照）を実行する。

(4) S P Tのデバイスに対する供給

デバイスアクセス機器としてのリ一ダライタ（R/W) とデバイス間の相互認証が成立すると、サービス許可チケットユーザ（ S P T User)であるリ一ダライ夕は、デバイスに対してサービス許可チケット（S PT) を送信する。デバイスは、受信したサービス許可チケット（S P T) について M A C検証処理を実行し、 S PT発行者（SPT Issuer) の検証、さらに、 S P Tチケットに格納された S P Tュ一ザ（チケットユーザとしてのリーダライタ）とチケットユーザ（S P T User) の識別子の一致を確認し、相互認証済みであることを確認することにより S PTユーザ（デバイスアクセス機器としてのリーダライタ）の検証（図 57、図 58参照）を実行する。

(5) ファイルアクセス

デバイスは、処理対象ファイルにサービス許可チケット（S P T) に記述されたル一ルに従ってアクセスを実行する。

以上の処理によって、相互認証（共通鍵）、チケット（S PT) 検証（共通鍵）の各方式に従ったファイルアクセス処理が実行される。

(D) 相互認証（共通鍵）、チケット（S P T) 検証（公開鍵）

次に、相互認証処理に共通鍵方式を適用し、チケット（S PT) 検証に公開鍵方式を適用する場合の各エンティティ間のデータ転送について図 92を用いて説明する。

パーティションマネージャ（PM) の公開鍵証明書（C e r t . PM) は、パ —テイシヨンマネージャ（PM) からの発行要求により、登録局（RA) を介した証明書発行手続きによってパーティシヨン対応認証局（C A (PAR))から発行される。なお、本構成は、パーティションマネージャがサービス許可チケット発行手段（S P T Issuer) を兼ねる構成であり、サービス許可チケット発行手段 (SPT Issuer)の公開鍵証明書としてパーティションマネージャ（P M)の公開鍵証明書を使用する構成である。

(2) サービス許可チケット（S P T) の生成処理

サービス許可チケット（S PT) は、パーティションマネージャの管理するサ一ビス許可チケット発行手段（S P T Ticket Issuer) により生成される。この場合、公開鍵方式の署名生成、検証を実行するため、サービス許可チケット発行手段（S P T Ticket Issuer) の秘密鍵による署名（Signature)が生成（図 1 2参照）されて S P Tに付加される。

( 3) S PTおよびサービス許可チケット発行手段（S PT Ticket Issuer) としてのパーティションマネージャ公開鍵証明書（C e 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 P T Ticket Issuer) の発行したサービス許可チケット（S PT) に従ったファイルアクセスを実行しようとする対象のデバイスとの間で、共通鍵方式の相互認証（図 53、図 54参照）を実行する。

( 5 ) S P Tおよびサービス許可チケット発行手段（S P T Ticket Issuer) としてのパーティションマネージャ公開鍵証明書（C e r t . PM) のデバイスに対する供給

リーダライタ（R/W) とデバイス間の相互認証が成立すると、サービス許可チケットユーザ（S P T User)であるデバイスアクセス機器としてのリーダライタは、デバイスに対してサービス許可チケット（S PT)、およびサービス許可チケット発行手段（S P T Ticket Issuer) としてのパーティションマネージャ公閧鍵証明書（C e r t . PM) を送信する。

デパイスは、受信したサービス許可チケット（S P T) について、（ 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 P T) の署名（Signature) の検証によりチケットが改竄のないことの確認を実行し、さらに、 'S PTチケットに格納された S P Tユーザ（チケットユーザとしてのリーダライタ）とチケットユーザ（S P T User)の識別子の一致を確認し、相互認証済みであることを確認することにより S PTユーザ（リーダライタ）の検証（図 5 7、図 58参照）を実行する。

( 6) ファイルアクセス

デバイスは、処理対象ファイルにサービス許可チケット（S P T) に記述されたルールに従ってアクセスを実行する。

以上の処理によって、相互認証（共通鍵）、チケット（S P T) 検証（公開鍵）の各方式に従ったファイルアクセス処理が実行される。

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

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

なお、前述したように、データアップデートチケット（DUT : Data Update Ticket) は、デバイスマネージャの管理するデータ項目の更新処理を実行するために適用されるチケット D U T (D E V) と、パーティションマネージャの管理するパーティション内のデータ項目の更新処理を実行するために適用されるチケット DUT (PAR) (図 32参照）がある。

デバイスに格納したデ一夕にデ一夕アップデートチケット（DUT) を適用してデータ更新を実行する処理について説明する。図 93以下のフロー他の図面を参照して説明する。なお、データ更新処理には、デバイスとデータ更新を実行するデバイスアクセス機器としてのリーダライタ間における相互認証処理（デパイス認証またはパーティション認証）、データアップデ一トチケット（DUT： Data Update Ticket) の正当性検証処理が含まれる。

図 93に示すデータ更新処理フローについて説明する。図 93において、左側がデ一夕更新装置、右側がデバイス（図 5参照）の処理を示す。なお、データ更新装置は、デバイスに対するデータ読み取り書き込み処理可能な装置（ex. デバイスアクセス機器としてのリ一ダライタ、 P C) であり、図 1 0のデバイスァクセス機器としてのリ一ダライタに相当する。まず、図 9 3を用いて、デ一夕更新処理の概要を説明し、その後、当処理に含まれるデータ更新操作の詳細を図 9 4のフローを用いて説明する。

まず、図 93のステップ S 95 1と S 960において、データ更新装置とデバイス間にでの相互認証処理が実行される。データ送受信を実行する 2つの手段間では、相互に相手が正しいデータ通信者であるか否かを確認して、その後に必要なデータ転送を行なうことが行われる。相手が正しいデータ通信者であるか否かの確認処理が相互認証処理である。相互認証処理時にセッション鍵の生成を実行して、生成したセッション鍵を共有鍵として暗号化処理を実行してデータ送信を行なう。

相互認証処理については、先のパーティション生成、削除処理の欄で説明したと同様の処理であり、デバイス認証またはパーティション認証のいずれかが実行される。それそれについて共通鍵方式認証、あるいは公開鍵方式認証処理のいずれかが適用される。この相互認証処理は、前述の図 48〜図 56を用いて説明したと同様の処理であるので説明を省略する。

なお、相互認証処理として実行すべき処理は、適用するデータアップデートチケット（DUT) (図 32参照）の * Authentication Type：デバイス（Device) の相互認証のタイプ（公開鍵認証、または、共通鍵認証、または、いずれでも可（Any))

によって決定される。

認証処理に失敗した場合（S 952 , S 96 1で No) は、相互が正当な機器、デバイスであることの確認がとれないことを示し、以下の処理は実行されずエラ —として処理は終了する。

認証処理に成功すると、データ更新装置は、デバイスに対してデータアップデ —トチケット（D U T ： Data Update Ticket) を送信する。データアップデートチケット（DUT) は、デバイスマネージャまたはパーティションマネージャの管理下のデータアップデートチケット（DUT) 発行手段（DUT Issuer) により発行されるチケットである。データアップデートチケット（ D U T ) は、デパイスに対するアクセス制御チケットであり、先に説明した図 32のデータフォーマット構成を持つチケットである。

なお、データアップデートチケット（DUT) を、チケットユーザに対して送信する際には、公開鍵方式の場合、データアップデートチケット（DUT) 発行手段（DUT Issuer) の公開鍵証明書（CERT_DUTI) も一緒に送信する。 DUT発行手段の公開鍵証明書（CERT— DUTI) の属性（Attribute) は、デバイス内の DKD B (PUB) (Device Key Definition Block)に記録されたチケット発行手段コ一ド（MTIC— DEV) や PKDB (PUB) (Partition Key Definition Block)に記録されたチケット発行手段コード（DUTIC— PAR) の識別子（DUTIC)と一致する。データアップデートチケット（DUT) を受信（S 962 ) したデバイスは、受信したチケット（DUT) の正当性と利用者チヱヅク処理を実行（S 963 ) する。チケットの正当性の検証処理は、共通鍵方式による MA C検証、あるいは公開鍵方式による署名検証処理のいずれかを適用して実行される。利用者チエツクは、チケットを送信してきた機器（チケット利用者）の正当性をチェックする処理であり、相互認証が成立済みであり、認証相手の識別データと、チケットに記録されているチケットユーザ識別子（図 32参照）との一致等を検証する処理として実行される。これらの処理は、先のパ一ティション登録チケット（PRT) の適用処理についての説明中、図 57〜図 59を用いて説明したと同様の処理であるので説明を省略する。

デバイスにおいて、受信チケット（DUT) の正当性と利用者チェック処理の結果、チケットおよび利用者の正当なことが確認できなかった場合（S 964で No) は、デ一夕アップデ一トチケット（DUT) 受理エラ一をデータ更新装置に通知（S 968 ) する。チケットおよび利用者の正当なことが確認できた場合 ( S 9 64で Y e s ) は、受信したデータアツプデートチケット（D U T) に記述されたルールに従いデバイス内のメモリ部に格納されたデータ（図 33参照）の更新処理を実行する。この処理の詳細については、別フローを用いて後段で詳述する。

データァヅプデートチケット（DUT) の記述に従って、デ一夕の更新処理に成功（S 966で Ye s) すると、 D U T受理成功をデータ更新装置に通知（S 96 7 ) する。一方、データの更新処理に失敗（ S 966で N o ) した場合は、 DUT受理エラ一をデータ更新装置に通知（S 968 ) する。

データ更新装置は、 DUT受理結果を受信（S 954 ) し、 DUT処理結果を判定し、 DUT受理結果がエラ一である場合（S 955で No) は、エラ一として処理を終了し、 DUT受理結果が成功（S 9 5 5で Ye s) である場合はセッシヨンクリアコマンドの送受信（S 9 56 , S 969 ) を実行し、デバイス側に生成した認証テーブルを破棄（S 97 0 ) し、処理を終了する。認証テーブルは、ステップ S 95 1 , S 960の相互認証処理において生成されるテ一ブルであり、前述したパーティション登録チケット（P RT) の適用処理の項目において説明した構成、すなわち、図 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 R L D E V, C R L D E V ) などは、リボケ一シヨンリスト中にバージョン情報が含まれる。このように情報に応じてバ一ジョン情報の格納先が決まっており、デバイスは、更新される古いデータのコード（OldDataCode) から更新対象データのパージヨンを検索する。

次に、デパイスは、ステップ S 97 2において、データアップデートチケット (DUT) に記録されたデータ更新をする時のバージョン条件 [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 9 73〜S 9 75である。

ステップ S 9 73では、データアップデートチケット（ D U T ) のバージョン条件 [Data Version Rule] を参照し、設定が [EXACT] であるか否かを判定する。 [EXACT] は、 [Data Version Condition] に指定された値と同じ場合にデータ更新が可能なことを示す。設定が [EXACT] である場合、ステップ S 974で、更新対象データ [O l 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] の方が新しい場合にのみ更新をする設定である。この [O l d e r] の設定の場合、ステップ S 9 75において、更新対象デ一夕 [O l d D a t a] のバージョンより、デ一夕アップデートチケット（DUT)の新規データ [New Data]のバ一ジョンを示す [New Data Version] の方が新しいか否かを判定し、新しい場合にのみ次ステップに進み、一致しない場合は、更新処理を実行せずエラ一終了とする。

次にデバイスは、ステップ S 976において、デ一夕ァップデ一トチケット（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 97 6において、データアップデートチケット（ D U T ) の [Encrypted Flag]が、更新されるデ一夕が暗号化されている（暗号化： Encrypted) ことを示していると判定された場合は、ステップ S 978において、データアツプデートチケット（DUT) の [Ticket Type] を検証する。 [Ticket Type] は、チケット（Ticket) の種別（DUT (D E V) /DUT (PAR)) を示すデ一夕である。 D U T (D E V) は、データアップデートチケット（ D U T ) が、デパイスマネージャの管理するデータ項目の更新処理を実行するチケットあることを示し、 DUT (PAR) は、パーティションマネージャの管理するパーティション内のデータ項目の更新処理を実行するために適用されるチケットであることを示してる。

チケットタイプ [Ticket Type] が、 DUT (D E V) を示している場合、ステップ S 979〜 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) の MA C検証用鍵）、 Kdut_DEV2 (デ一夕更新用暗号鍵）である場合は、ステップ S 980において、デバイスのデバイス鍵領域（図 1 8参照）に格納された Kdut_DEV4 (データ更新用暗号鍵）を用いて、データアップデ一トチケット（DUT (D E V)) に格納された新規デ一夕 [New Data] としての Kdut_DEVl、 Kdut_DEV2を復号し、デバイスのデバイス鍵領域に格納された Kdut_DEVl、 Kdut_DEV2に上書きする。なお、データアップデートチケヅト（DUT (D E V)) に格納されている更新するデー夕のバ一ジョン（New Data Version) を、デバイス内の更新データに対応して設定されているバージョン格納領域、この場合は、デバイスのデバイス鍵領域（図 1 8参照）に格納する処理を併せて実行する。

次に、ステップ S 98 1において、デバイスのデバイス鍵領域（図 1 8参照）に格納された Kdut_DEVl (データアップデートチケット（DUT) の MAC検証用鍵）と、 Kdut DEV3 (データアツプチ一トチケット（DUT)の M A C検証用鍵）とのスワップ、すなわち入れ替え処理を行ない、また、 Kdut_DEV2 (デ一夕更新用暗号鍵）と、 Kdut_DEV4 (デ一夕更新用暗号鍵）とのスワップ、すなわち入れ替え処理を行なって処理を終了する。

なお、 Kdut_DEVlと、 Kdut_DEV3とのスワップ、および、 Kdut— DEV2と、 Kdut— DEV4 とのスワップ処理によって、常に Kdut_DEV3 (データアップデートチケット（D UT)の MA C検証用鍵）、 Kdut_DEV4 (データ更新用暗号鍵）のペアが Kdut— DEVI (データァップデ一トチケット（D U T) ,の M A C検証用鍵）、 Kdut_DEV2 (デ一夕更新用暗号鍵）のペアよりも新しいバージョンのものに維持され、書き換え対象を、常に Kdut_DEVl、 Kdut_DEV2として設定した処理が可能となる。

なお、ステップ S 979において、デ一夕アップデートチケット（DUT (D E V)) に記述された Old Data Code (更新される古いデータのコード）の示すデ —夕がデバイス鍵領域（図 1 8参照）に格納された Kdut_DEVl (データアップデ —トチケット（DUT) の MAC検証用鍵）、 Kdut_DEV2 (データ更新用暗号鍵）でない場合は、ステップ S 982において、デバイスのデバイス鍵領域（図 1 8 参照）に格納された Kdut_DEV2 (データ更新用暗号鍵）を用いて、デ一夕アップデートチケット（DUT (D E V)) に格納された新規データ [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_PARl、 Kdut_PAR2 に上書きする。なお、データアップデートチケット（D U T (PAR)) に格納されている更新するデータのバ一ジョン（New Data Version) を、デバイス内の更新データに対応して設定されているバージョン格納領域、この場合は、デバイスのパーティション鍵領域（図 2 3参照）に格納する処理を併せて実行する。

次に、ステップ S 985において、デバイスのパ一テイション鍵領域（図 2 3 参照）に格納された Kdut_PARl (データアップデートチケット（DUT) の MA C検証用鍵）と、 Kdut_PAR3 (データアップデ一トチケット（DUT) の MAC検証用鍵）とのスワップ、すなわち入れ替え処理を行ない、また、 Kdut_PAI^ (デー夕更新用暗号鍵）と、 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 (データアップデ —トチケット（D U T) の MA C検証用鍵）、 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_PARl (データアップデートチケット（DUT) の MAC検証用鍵） Kdut_PAR2 (データ更新用暗号鍵）

である場合には、他の更新処理と異なる処理を実行する。

これらの Kdut— DEVI (データアップデートチケット（DUT) の MAC検証用鍵）、 Kdut_DEV2 (データ更新用暗号鍵）、 Kdut_PARl (デ一夕アップデートチケヅト（DUT) の MAC検証用鍵）、 Kdut_PAR2 (データ更新用暗号鍵）についての更新処理を簡潔にまとめた図を図 95に示し、処理について説明する。図 95の ( 1 ) 〜（ 3) の順に説明する。なお、処理は、 Kdut_DEVl,2 と、 Kdut— PAR1，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) を受信したデバイスは、デバイスのデバイス鍵領域に格納された Kdut_DEV4 (データ更新用暗号鍵）を用いて、データアップデートチケット（DUT) の格納新規データ [New Data] としての Kdut_DEVl、 Kdut_DEV2 を復号し、デバイスのデバイス鍵領域に格納された Kdut_DEVl、 Kdut_DEV2に上書きする。

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

この、 Kdut— DEVI と、 Kdut— DEV3とのスワップ、および、 Kdut_DEV2と、 Kdut— DEV4 とのスワップ処理によって、常に Kdut_DEV3 (データアップデ一トチケット（D U T)の MA C検証用鍵）、 dut_DEV4 (データ更新用暗号鍵）のペアが Kdut— DEVI (データアップデートチケット（DUT) の MAC検証用鍵）、 Kdut— DEV2 (デ一タ更新用暗号鍵）のペアよりも新しいバ一ジョンのものに維持される。つまり、 Kdut_DEVl と、 Kdut_DEV2の鍵は常に使用される鍵で、 Kdut_DEV3 と、 KdutJ)EV4 は、非常時に Kdut_DEVl と、 Kdut_DEV2 を更新するとともに、現在使用されている Kdut_DEVl と、 Kdut_DEV2の鍵に置き換えられるバックアップ用の鍵としての役割がある。

なお、 Kdut— DEVI (データアップデ一トチケット（DUT) の MAC検証用鍵）、 Kdut_DEV2 (データ更新用暗号鍵）はペアとして使用され、また、 Kdut_DEV3 (デ —夕アップデートチケット（DUT) の MAC検証用鍵）、 Kdut— DEV4 (データ更新用暗号鍵）もペアとして使用される。

以上、特定の実施例を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本発明の要旨を判断するためには、冒頭に記載した特許請求の範囲の欄を参酌すべきである。

なお、明細書中において説明した一連の処理はハードウェア、またはソフトゥエア、あるいは両者の複合構成によって実行することが可能である。ソフトゥェァによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハ一ドウエアに組み込まれたコンピュー夕内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをィンスト一ルして実行させることが可能である。

例えば、プログラムは記録媒体としてのハードディスクや R O M ( Read Only Memory)に予め記録しておくことができる。あるいは、プログラムはフロッピ一デイスク、 C D - R 0 M ( Compact D isc Read Only Memory) , M 0 (Magneto optical ) ディスク， D V D (Digital Versati le Di sc ), 磁気ディスク、半導体メモリなどのリム一バブル記録媒体に、一時的あるいは永続的に格納（記録）しておくことができる。このようなリム一バブル記録媒体は、いわゆるパッケージソフトゥェァとして提供することができる。

なお、プログラムは、上述したようなリム一バブル記録媒体からコンピュータにインスト一ルする他、ダウン口一ドサイトから、コンピュータに無線転送したり、 L A N (Local Area Network), インタ一ネットとレヽつたネットワークを介して、コンピュータに有線で転送し、コンピュータでは、そのようにして転送されてくるプログラムを受信し、内蔵するハードディスク等の記録媒体にインスト一ルすることができる。

なお、明細書に記載された各種の処理は、記載に従って時系列に実行されるのみならず、処¾を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。また、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。産業上の利用可能性

上述したように、本発明のデータアクセス管理システム、メモリ搭載デバイス、およびデ一夕アクセス管理方法、並びにプログラム記憶媒体によれば、複数のパ —ティションに分割されたメモリ領域のアクセスに対して、様々な種類のァクセス制御チケットを各デバイスまたはパーティシヨン管理エンティティの管理の下に発行し、各チケットに記述されたルールに基づく処理をメモリ搭載デバイスにおいて実行する構成が可能となり、各パーティシヨン内データの独立した管理構成が実現される。

さらに、本発明のデータアクセス管理システム、メモリ搭載デバイス、およびデータアクセス管理方法、並びにプログラム記憶媒体によれば、アクセス機器に対して許容されるアクセスモードを設定したアクセス制御チケットとしてのサ一ビス許可チケット（S P T ) を、各アクセス機器に応じて個別に発行する構成としたので、各アクセス機器に応じて異なる態様のアクセスを実行可能とした構成が実現される。

さらに、本発明のデータ処理システム、メモリ搭載デバイス、およびデータ処理方法、並びにプログラム記憶媒体によれば、複数のパーティションに分割されたメモリ領域のアクセスに対して、様々な種類のアクセス制御チケットを各デバイスまたはパーティション管理エンティティの管理の下に発行し、各チケットに記述されたルールに基づく処理をメモリ搭載デバイスにおいて実行する構成が可能となり、各パーティション内デ一夕の独立した管理構成が実現される。

さらに、本発明のデータ処理システム、メモリ搭載デバイス、およびデータ処理方法、並びにプログラム記憶媒体によれば、パーティション対応の認証、デバイス対象の認証を公開鍵、共通鍵のいずれか指定方式に従って実行することが可能なデバィスとし、様々な環境下においてデバイスおよびアクセス装置間のセキユアなデータ通信が実行可能となる。

さらに、本発明のデータ処理システム、メモリ搭載デバイス、およびデ一夕処理方法、並びにプログラム記憶媒体によれば、メモリ搭載デバイスが、アクセス機器からの指定または受領したアクセス制御チケットの記述に基づいて、ァクセス機器との相互認証の方式としてえば公開鍵方式、または共通鍵方式のいずれかを決定して実行するとともに、受領したアクセス制御チケットの記述に基づいて、アクセス制御チケットの検証方式についても例えば公開鍵方式、または共通鍵方式のいずれかを決定して実行する構成としたことにより、様々な環境下において、また様々なアクセス制御チケットの態様に対して、デバイスおよびァクセス装置間のセキュアなデータ通信が可能となる。

さらに、本発明のデータアクセス制御システム、メモリ搭載デバイス、およびデータアクセス制御方法、並びにプログラム記憶媒体によれば、メモリ搭載デパイスは、アクセス機器からアクセス制御チケットを受領して、該アクセス制御チケットに記述された認証ルールに基づく認証の成立、および該アクセス制御チケットに記述されたアクセス機器の識別データの確認を条件としてデ一夕アクセスを許容する構成としたので、各アクセス毎に様々な認証態様、チケット態様を設定可能となり、メモリアクセス処理に応じたセキュリティレベルを設定したァクセス管理が実現される。

さらに、本発明のデ一夕アクセス制御システム、メモリ搭載デバイス、およびデ一夕アクセス制御方法、並びにプログラム記憶媒体によれば、アクセス制御チケットにチケットの発行手段および利用手段のカテゴリまたは識別子を格納し、デバイスにおいて検証可能な構成としたので、高度なセキュリティレベルでのァクセス管理が可能となる。

さらに、本発明のデ一夕アクセス制御システム、メモリ搭載デバイス、およびデ一夕アクセス制御方法、並びにプログラム記憶媒体によれば、複数のパーティションに分割されたメモリ領域のアクセスに対して、様々な種類のアクセス制御チケットを各デバイスまたはパーティション管理ェンティティの管理の下に発行し、各チケットに記述されたルールに基づく処理をメモリ搭載デバイスにおいて実行する構成が可能となり、各パーティシヨン内デ一夕の独立した管理構成が実現される。

さらに、本発明のメモリアクセス制御システム、メモリ搭載デバイス、およびメモリアクセス制御方法、並びにプログラム記憶媒体によれば、複数のパーティシヨンに分割されたメモリ領域のアクセスに対して、複数のアクセス制御チケットに基づく複数のデータファイルに対するアクセス処理を、メモリ搭載デバイスに対する認証としてのデバイス認証、またはアクセス対象のデータファイルの格納された各パーティションに対する認証としてのパーティション認証の成立を条件として実行する構成としたので、アクセス態様にに応じて生成されるチケットに認証態様を記述することでデバイス認証のみ、あるいは各パ一テイション認証を実行するなど、各種の設定が可能となる。

さらに、本発明のメモリアクセス制御システム、メモリ搭載デバイス、およびメモリアクセス制御方法、並びにプログラム記憶媒体によれば、メモリ搭載デバイスは、複数の異なるパーティション内のファイルアクセス条件として実行した複数の認証処理の結果、取得された複数のセッション鍵に基づいて唯一の統合セッション鍵を生成し、統合セッション鍵に基づいてアクセス機器との通信デ一夕の暗号処理を実行する構成としたので、異なるパーティション内のファイルに対するアクセス時にセッション鍵を切り替えるなどの処理が不要となる。

さらに、本発明のメモリアクセス制御システム、メモリ搭載デパイス、およびメモリアクセス制御方法、並びにプログラム記憶媒体によれば、各パーティション内のデータフアイルに対するアクセス要求に対する処理を、各パーティション毎に設定される認証態様に従ったアクセス機器との認証の成立を条件として実行する構成とし、認証態様として、メモリ搭載デバイスに対する認証としてのデバイス認証、各パーティションに対する認証としてのパ一ティション認証の少なくとも 2つの態様を有する構成としたので、様々なアクセスチケットに応じた認証を選択的に実行可能となる。

Claims

請求の範囲

1. データ格納可能なメモリ部を有するメモリ搭載デバイスに対する、ァクセス機器からの前記メモリ部格納データファイルに対するアクセス処理を管理するデ一夕アクセス管理システムであり、

前記アクセス機器は、該アクセス機器に対して許容されるアクセスモードを設定したアクセス制御チケットとしてのサービス許可チケット（S PT) をチケヅト発行手段から受領して該受領したサービス許可チケット（SP T) を前記メモリ搭載デバイスに対して出力し、

前記メモリ搭載デバイスは、前記アクセス機器から、前記サービス許可チケット（S PT) を受領して、該サ一ビス許可チケット（S P T) に記述されたァクセスモードに従った処理を実行する構成を有することを特徴とするデータァクセス管理システム。

2. 前記サービス許可チケット（S PT) は、

アクセス対象としたデータファイルを識別するファイル識別子を含み、前記メモリ搭載デバイスは、前記アクセス機器から、前記サービス許可チケット（S PT) を受領して、該サ一ビス許可チケット（S P T) に記述されたファィル識別子に従ってデータファイルを選択し、該選択したファイルに対して前記アクセスモードに従った処理を実行する構成を有することを特徴とする請求項 1 に記載のデータアクセス管理システム。

3. 前記サービス許可チケット（S P T) は、

アクセス対象とした複数のデータファイルを識別する複数のファイル識別子を含む構成を有し、該複数のファイル識別子中、一方はターゲットファイル識別子として設定するとともにタ一ゲットファイルに対する読み取りまたは書き込み許可データを格納した構成を有し、

前記メモリ搭載デバイスは、前記アクセス機器から、前記サービス許可チケット（S PT) を受領して、前記アクセスモードに従った処理を実行するとともに、該サ一ビス許可チケット（S PT) にターゲットファイル識別子として設定されたターゲットファイルに対して、該サ一ビス許可チケット（S PT) に設定された読み取りまたは書き込み許可データに従った読み取りまたは書き込み処理を実行する構成を有することを特徴とする請求項 1に記載のデータアクセス管理システム。

4. 前記サービス許可チケット（S P T) は、

アクセス対象とした複数のデータファイルを識別する複数のファイル識別子を含む構成を有し、該複数のファイル識別子中、一方はターゲットファイル識別子として設定するとともに夕一ゲットファイルに対する読み取りまたは書き込み許可データを格納し、他方のデ一夕ファイルのアクセスモードとして該データファィルに格納した暗号鍵を用いた暗号化処理を設定した構成を有し、

前記メモリ搭載デバイスは、前記アクセス機器から、前記サービス許可チケット（S PT) を受領して、前記アクセスモードに従った処理として、前記タ一ゲットファイルの読み取りおよび前記暗号鍵による暗号化処理を実行することにより、前記メモリ搭載デバイス内における内部暗号化処理を実行する構成としたことを特徴とする請求項 1に記載のデ一夕アクセス管理システム。

5. 前記サービス許可チケット（S PT) を発行するチケット発行手段は、前記メモリ搭載デバイスのメモリ領域を管理するエンティティの管理下にあるチケット発行手段であり、

該チケット発行手段は、

各アクセス機器に応じて各種のアクセスモードを設定したサービス許可チケット（S PT) を個別に発行することにより、各アクセス機器に応じて異なる態様のアクセスを実行可能とした構成を有することを特徴とする請求項 1に記載のデ —夕アクセス管理システム。

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

アクセス機器とのセッション中に受領したサービス許可チケット（S PT) に基づいてファイルオープン処理を実行したファイルの識別デ一夕としてのフアイル識別子と、前記サービス許可チケット（S P T ) に記述されたアクセスモードを対応付けたフアイルオープンテーブルを生成し、該ファイルオープンテ一ブルを参照して前記アクセス機器からの受領コマンドの実行の可否を判定する構成を有することを特徴とする請求項 1に記載のデータアクセス管理システム。

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

各々が対応するパーティシヨンマネージャによって管理されるメモリ領域としての 1以上のパーティション領域を有し、前記データファイルは前記 1以上のパ —ティション領域のいずれかに格納され、

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

各パ一テイション内のデータフアイルに対するアクセス要求に対する処理を、パーティションマネージャ管理下のチケット発行手段が発行し、チケット利用手段としての前記アクセス機器から前記メモリ搭載デバイスに対して入力されるサ —ビス許可チケット（S P T ) の記述に基づいて実行する構成であることを特徴とする請求項 1に記載のデータアクセス管理システム。

8 . 前記サ一ビス許可チケット（S P T ) は、

前記メモリ搭載デバィスとチケットを出力したアクセス機器との間において実行すべき相互認証態様を指定した相互認証態様指定データを含み、

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

該サービス許可チケット（S P T ) の相互認証態様指定データに応じた相互認証を実行し、認証の成立を条件として受領チケットの記録に応じた処理を実行する構成を有することを特徴とする請求項 1に記載のデータアクセス管理システム ₍

9 . 前記サービス許可チケット（S P T ) は、

前記メモリ搭載デバイスの受領したサービス許可チケット（S P T ) の検証態様を指定したチケット検証指定データを含み、

前記メモリ搭載デバイスは、該サ一ビス許可チケット（S PT) のチケット検証指定データに応じたチケット検証処理を実行し、検証の成立を条件として受領チケットの記録に応じた処理を実行する構成を有することを特徴とする請求項 1に記載のデータアクセス管理システム。

1 0. データ格納可能なメモリ部を有するメモリ搭載デバイスであり、アクセス機器からの前記メモリ部格納データファイルに対するアクセス処理を制御する制御手段を有し、

前記制御手段は、

前記アクセス機器から、受領するサービス許可チケット（S PT) に記述されたファイル識別子に従ってデータファイルを選択し、該選択したファイルに対して、サービス許可チケット（S PT) に記述されたアクセスモードに従った処理を実行する構成を有することを特徴とするメモリ搭載デバイス。

1 1. 前記サービス許可チケット（S P T) は、

アクセス対象としたデータファイルを識別するファイル識別子を含み、前記制御手段は、

前記アクセス機器から、前記サービス許可チケット（S PT) を受領して、該サービス許可チケット（S PT) に記述されたファイル識別子に従ってデ一タフアイルを選択し、該選択したファイルに対して前記アクセスモードに従った処理を実行する構成を有することを特徴とする請求項 1 0に記載のメモリ搭載デバィス。

1 2. 前記サービス許可チケット（S P T) は、

アクセス対象とした複数のデータファイルを識別する複数のファイル識別子を含む構成を有し、該複数のファイル識別子中、一方はターゲットファイル識別子として設定するとともにターゲットファイルに対する読み取りまたは書き込み許可データを格納した構成を有し、

前記制御手段は、前記アクセス機器から、前記サービス許可チケット（S P T) を受領して、前記アクセスモ一ドに従った処理を実行するとともに、該サ一ビス許可チケヅト（S P T) にターゲットファイル識別子として設定されたターゲットファイルに対して、該サービス許可チケット（S PT) に設定された読み取りまたは書き込み許可データに従った読み取りまたは書き込み処理を実行する構成を有することを特徴とする請求項 1 0に記載のメモリ搭載デバイス。

1 3. 前記サービス許可チケット（ S P T) は、

アクセス対象とした複数のデータフアイルを識別する複数のファイル識別子を含む構成を有し、該複数のファイル識別子中、一方はターゲットファイル識別子として設定するとともにターゲットフアイルに対する読み取りまたは書き込み許可データを格納し、他方のデ一夕ファイルのアクセスモードとして該デ一タファィルに格納した暗号鍵を用いた暗号化処理を設定した構成を有し、

前記制御手段は、

前記アクセス機器から、前記サービス許可チケット（S P T) を受領して、前記アクセスモ一ドに従った処理として、前記夕一ゲットファイルの読み取りおよび前記暗号鍵による暗号化処理を実行することにより、前記メモリ搭載デバィス内における内部暗号化処理を実行する構成としたことを特徴とする請求項 1 0に記載のメモリ搭載デバイス。

14. 前記制御手段は、

アクセス機器とのセッション中に受領したサービス許可チケット（S P T) に基づいてファイルオープン処理を実行したファイルの識別データとしてのフアイル識別子と、前記サービス許可チケット（S P T) に記述されたアクセスモードを対応付けたファイルオープンテ一ブルを生成し、該ファイルオープンテーブルを参照して前記アクセス機器からの受領コマンドの実行の可否を判定する構成を有することを特徴とする請求項 1 0に記載のメモリ搭載デバイス。

1 5. 前記メモリ搭載デバイスのメモリ部は、各々が対応するパーティシヨンマネージャによって管理されるメモリ領域としての 1以上のパーテイション領域を有し、前記デ一夕ファイルは前記 1以上のパ —ティション領域のいずれかに格納され、

前記制御手段は、

各パ一テイシヨン内のデ一タフアイルに対するアクセス要求に対する処理を、パーティションマネージャ管理下のチケット発行手段が発行し、チケット利用手段としての前記アクセス機器から前記メモリ搭載デバイスに対して入力されるサ —ビス許可チケット（S P T) の記述に基づいて実行する構成であることを特徴とする請求項 1 0に記載のメモリ搭載デバイス。

1 6. 前記サービス許可チケット（ S P T) は、

前記メモリ搭載デバィスとチケヅトを出力したアクセス機器との間において実行すべき相互認証態様を指定した相互認証態様指定データを含み、

前記制御手段は、

該サ一ビス許可チケット（S P T) の相互認証態様指定デ一夕に応じた相互認証を実行し、認証の成立を条件として受領チケットの記録に応じた処理を実行する構成を有することを特徴とする請求項 1 0に記載のメモリ搭載デバイス。

1 7. 前記サ一ビス許可チケット（ S P T) は、

前記メモリ搭載デバイスの受領したサービス許可チケット（S PT) の検証態様を指定したチケット検証指定データを含み、

前記制御手段は、

該サ一ビス許可チケット（S PT) のチケット検証指定データに応じたチケット検証処理を実行し、検証の成立を条件として受領チケットの記録に応じた処理を実行する構成を有することを特徴とする請求項 1 0に記載のメモリ搭載デバィス。

1 8. データ格納可能なメモリ部を有するメモリ搭載デバイスに対する、ァクセス機器からの前記メモリ部格納デ一夕ファイルに対するアクセス処理を管理するデータアクセス管理方法であり、

前記アクセス機器は、該アクセス機器に対して許容されるアクセスモ一ドを設定したアクセス制御チケットとしてのサービス許可チケット（S PT) をチケット発行手段から受領して該受領したサービス許可チケット（S PT) を前記メモリ搭載デバイスに対して出力し、

前記メモリ搭載デバイスは、前記アクセス機器から、前記サービス許可チケット（SPT) を受領して、該サ一ビス許可チケット（S P T) に記述されたァクセスモ一ドに従った処理を実行することを特徴とするデータアクセス管理方法。

1 9. 前記サービス許可チケット（ S P T) は、

アクセス対象としたデータファイルを識別するファイル識別子を含み、前記メモリ搭載デバイスは、前記アクセス機器から、前記サービス許可チケット（SPT) を受領して、該サ一ビス許可チケット（S PT) に記述されたファィル識別子に従ってデータファイルを選択し、該選択したファイルに対して前記アクセスモードに従った処理を実行することを特徴とする請求項 1 8に記載のデ —タアクセス管理方法。

20. 前記サービス許可チケット（ S P T) は、

アクセス対象とした複数のデ一タフアイルを識別する複数のファイル識別子を含む構成を有し、該複数のファイル識別子中、一方はターゲットファイル識別子として設定するとともにターゲットファイルに対する読み取りまたは書き込み許可デ一夕を格納した構成を有し、

前記メモリ搭載デバイスは、前記アクセス機器から、前記サービス許可チケット（S PT) を受領して、前記アクセスモードに従った処理を実行するとともに、該サ一ビス許可チケット（ S P T) にターゲットファイル識別子として設定された夕一ゲヅトファイルに対して、該サービス許可チケット（S PT) に設定された読み取りまたは書き込み許可データに従った読み取りまたは書き込み処理を実行することを特徴とする請求項 1 8に記載のデータアクセス管理方法。

2 1. 前記サービス許可チケット（ S P T) は、

アクセス対象とした複数のデータファイルを識別する複数のファイル識別子を含む構成を有し、該複数のファイル識別子中、一方はターゲットファイル識別子として設定するとともにターゲットファイルに対する読み取りまたは書き込み許可データを格納し、他方のデータファイルのアクセスモードとして該デ一タファィルに格納した暗号鍵を用いた暗号化処理を設定した構成を有し、

前記メモリ搭載デバイスは、前記アクセス機器から、前記サービス許可チケット（S PT) を受領して、前記アクセスモードに従った処理として、前記タ一ゲットファイルの読み取りおよび前記暗号鍵による暗号化処理を実行することにより、前記メモリ搭載デバイス内における内部暗号化処理を実行することを特徴とする請求項 1 8に記載のデータアクセス管理方法。

22. 前記サービス許可チケット（S P T) を発行するチケット発行手段は、前記メモリ搭載デバイスのメモリ領域を管理するェンティティの管理下にあるチケット発行手段であり、

該チケット発行手段は、

各アクセス機器に応じて各種のアクセスモードを設定したサービス許可チケット（S PT) を個別に発行することにより、各アクセス機器に応じて異なる態様のアクセスを実行可能としたことを特徴とする請求項 18に記載のデ一夕ァクセス管理方法。

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

アクセス機器とのセッション中に受領したサービス許可チケット（S PT) に基づいてファイルオープン処理を実行したファイルの識別データとしてのフアイル識別子と、前記サービス許可チケット（S P T) に記述されたアクセスモードを対応付けたファイルオープンテーブルを生成し、該ファイルオープンテーブルを参照して前記アクセス機器からの受領コマンドの実行の可否を判定することを特徴とする請求項 1 8に記載のデータアクセス管理方法。

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

各々が対応するパ一ティシヨンマネージャによって管理されるメモリ領域としての 1以上のパ一テイション領域を有し、前記デ一夕ファイルは前記 1以上のパ —ティション領域のいずれかに格納され、

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

各パ一ティション内のデ一夕ファイルに対するアクセス要求に対する処理を、パーティションマネージャ管理下のチケヅト発行手段が発行し、チケット利用手段としての前記アクセス機器から前記メモリ搭載デバイスに対して入力されるサ —ビス許可チケット（S P T) の記述に基づいて実行することを特徴とする請求項 1 8に記載のデータアクセス管理方法。

25. 前記サービス許可チケット（ S P T) は、

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

該サービス許可チケット（S PT) の相互認証態様指定データに応じた相互認証を実行し、認証の成立を条件として受領チケットの記録に応じた処理を実行することを特徴とする請求項 1 8に記載のデータアクセス管理方法。

26. 前記サービス許可チケット（S P T) は、

前記メモリ搭載デバイスの受領したサービス許可チケット（S P T) の検証態様を指定したチケット検証指定データを含み、

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

該サ一ビス許可チケット（S PT) のチケット検証指定データに応じたチケット検証処理を実行し、検証の成立を条件として受領チケットの記録に応じた処理を実行する構成を有することを特徴とする請求項 1 8に記載のデータアクセス管理方法。

27. データ格納可能なメモリ部を有するメモリ搭載デバイスに対する、ァクセス機器からの前記メモリ部格納データファイルに対するアクセス処理を管理するデータアクセス管理処理をコンピュータ · システム上で実行せしめるコンビュ —夕 · プログラムを提供するプログラム記憶媒体であって、前記コンピュータ · プログラムは、

前記メモリ搭載デバイスにアクセスを実行するアクセス機器において許容されるアクセスモードを設定したアクセス制御チケットとしてのサービス許可チケット（S P T ) を受領して、該サ一ビス許可チケット（S P T ) に記述されたァクセスモードに従った処理を実行するステップを有することを特徴とするプログラム記憶媒体。

2 8 . データ格納可能なメモリ部を有するメモリ搭載デバイスに対するァクセス機器からのアクセス要求に応じて、前記メモリ部に対するデータ処理を実行するデータ処理システムであり、

前記メモリ搭載デバイスは、前記メモリ部に対するデータ処理に対応して構成されるアクセス制御チケットを前記アクセス機器から受領して、該アクセス制御チケットに記述されたルールに基づくデータ処理を実行する構成であるとともに、前記アクセス機器からの指定または受領したアクセス制御チケットの記述に基づいて、前記アクセス機器との相互認証の方式を決定して実行するとともに、受領したアクセス制御チケットの記述に基づいて、アクセス制御チケットの検証方式を決定して実行し、相互認証およびチケット検証の双方の成立を条件として前記アクセス機器からのアクセス要求に応じる構成を有することを特徴とするデータ処理システム。

2 9 . 前記相互認証の方式は、公開鍵方式または共通鍵方式のいずれかであり、アクセス制御チケットの検証方式は、公開鍵方式または共通鍵方式のいずれかであることを特徴とする請求項 2 8に記載のデータ処理システム。

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

前記アクセス制御チケットの検証を実行するための M A C検証用鍵を保有し、前記アクセス機器から受領したアクセス制御チケットの検証を共通鍵方式に従つて実行する場合には、該 MAC検証用鍵を適用した改竄チェック処理を実行し、アクセス制御チケットの検証を公開鍵方式に従って実行する場合には、チケット発行手段の公開鍵証明書から取得したチケット発行手段の公開鍵に基づく署名検証処理を実行する構成であることを特徴とする請求項 28に記載のデータ処理システム。

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

前記アクセス制御チケットの検証を実行するための M A C検証用鍵を複数保有し、前記アクセス機器から受領したアクセス制御チケヅトに記録された情報に従つて適用すべき MA C検証用鍵を選択する構成であることを特徴とする請求項 2 8に記載のデ一夕処理システム。

32. 前記アクセス制御チケットには、

前記メモリ搭載デバイスのメモリ部内の格納デ一夕の更新処理を許容するデ一夕アップデートチケット（DUT) を含み、

前記メモリ搭載デバイスは、前記アクセス制御チケットの検証を実行するための MA C検証用鍵を複数保有し、

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

前記アクセス機器から受領したデータアップデートチケット（DUT) に指定された更新対象データがアクセス制御チケットの検証を実行するための M A C検証用鍵である場合は、複数の MA C検証用鍵から更新対象に該当しない MAC検証用鍵を選択して受領したデータアップデートチケット（DUT) の検証処理を実行することを特徴とする請求項 28に記載のデータ処理システム。

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

各々が対応するパーティシヨンマネージャによって管理されるメモリ領域としての 1以上のパ一テイション領域を有し、

前記メモリ搭載デバイスは、 B'J ί記アクセス機器からの各パーティシヨン内のデータに対するアクセス要求に対する処理を、各パーティシヨンマネージャの管理下のチケット発行手段が発行し、チケット利用手段としての前記アクセス機器から前記メモリ搭載デバィスに対して入力されるアクセス制御チケッ卜の記述に基づいて実行する構成であることを特徴とする請求項 2 8に記載のデ一夕処理システム。

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

各々が対応するパーティションマネージャによって管理されるメモリ領域としての 1以上のパーティション領域を有し、

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

前記アクセス機器とのセッション中に実行したパーティシヨン認証またはデバィス認証によって取得した公開鍵方式認証情報およびセッション鍵、または共通鍵方式認証情報およびセッション鍵を対応付けた認証テーブルを生成して、当該セッシヨン期間、保持する構成を有することを特徴とする請求項 2 8に記載のデ —夕処理システム。

3 5 . データ格納可能なメモリ部を有するメモリ搭載デバイスであり、アクセス機器からのアクセス要求に応じて、前記メモリ部に対するデータ処理を実行する制御手段を有し、

前記アクセス機器からの指定または受領したアクセス制御チケットの記述に基づいて、前記アクセス機器との相互認証の方式を決定して実行するとともに、受領したアクセス制御チケヅトの記述に基づいて、アクセス制御チケットの検証方式を決定して実行し、相互認証およびチケット検証の双方の成立を条件として前記アクセス機器からのアクセス要求に応じる構成を有することを特徴とするメモリ搭載デバイス。

3 6 . 前記制御手段は、

前記相互認証の方式として、公開鍵方式または共通鍵方式のいずれかを選択的に実行し、

アクセス制御チケットの検証方式として、公開鍵方式または共通鍵方式のいずれかを選択的に実行する構成であることを特徴とする請求項 3 5に記載のメモリ搭載デバイス。

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

前記アクセス制御チケットの検証を実行するための M A C検証用鍵を保有し、前記制御手段は、

前記アクセス機器から受領したアクセス制御チケットの検証を共通鍵方式に従つて実行する場合には、該 M A C検証用鍵を適用した改竄チェック処理を実行し、アクセス制御チケットの検証を公開鍵方式に従って実行する場合には、チケット発行手段の公開鍵証明書から取得したチケット発行手段の公開鍵に基づく署名検証処理を実行する構成であることを特徴とする請求項 3 5に記載のメモリ搭載デバイス。

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

前記アクセス制御チケットの検証を実行するための M A C検証用鍵を複数保有し、

前記制御手段は、

前記アクセス機器から受領したアクセス制御チケットに記録された情報に従つて適用すべき M A C検証用鍵を選択する構成であることを特徴とする請求項 3 5 に記載のメモリ搭載デバイス。

3 9 . 前記アクセス制御チケットには、

前記メモリ搭載デバイスのメモリ部内の格納データの更新処理を許容するデ一タアップデートチケット（D U T ) を含み、

前記メモリ搭載デバイスは、前記アクセス制御チケットの検証を実行するための M A C検証用鍵を複数保有し、

前記制御手段は、

前記アクセス機器から受領したデータアップデートチケット（D U T ) に指定された更新対象データがアクセス制御チケットの検証を実行するための M A C検証用鍵である場合は、複数の M A C検証用鍵から更新対象に該当しない M A C検証用鍵を選択して受領したデータアップデートチケット（D U T ) の検証処理を実行することを特徴とする請求項 3 5に記載のメモリ搭載デバイス。

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

各々が対応するパーティションマネージャによって管理されるメモリ領域としての 1以上のパーテイション領域を有し、

前記制御手段は、

前記アクセス機器からの各パーティション内のデ一夕に対するアクセス要求に対する処理を、各パーティションマネージャの管理下のチケット発行手段が発行し、チケット利用手段としての前記アクセス機器から前記メモリ搭載デバイスに対して入力されるアクセス制御チケットの記述に基づいて実行する構成であることを特徴とする請求項 3 5に記載のメモリ搭載デバイス。

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

前記制御手段は、

前記アクセス機器とのセヅション中に実行したパーティション認証またはデバイス認証によって取得した公開鍵方式認証情報およびセッシヨン鍵、または共通鍵方式認証情報およびセッション鍵を対応付けた認証テーブルを生成して、当該セッション期間、保持する構成を有することを特徴とする請求項 3 5に記載のメモリ搭載デバイス。

4 2 . データ格納可能なメモリ部を有するメモリ搭載デバイスに対するァクセス機器からのアクセス要求に応じて、前記メモリ部に対するデータ処理を実行するデータ処理方法であり、

前記メモリ搭載デバイスにおいて、

前記アクセス機器からの指定または受領したアクセス制御チケットの記述に基づいて、前記アクセス機器との相互認証の方式を決定して実行するとともに、受領したアクセス制御チケットの記述に基づいて、アクセス制御チケットの検証方式を決定して実行し、相互認証およびチケット検証の双方の成立を条件として前記アクセス機器からのアクセス要求を実行することを特徴とするデータ処理方法

4 3 . 前記相互認証の方式は、公開鍵方式または共通鍵方式のいずれかであり、アクセス制御チケットの検証方式は、公開鍵方式または共通鍵方式のいずれかであることを特徴とする請求項 4 2に記載のデータ処理方法。

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

前記アクセス制御チケットの検証を実行するための M A C検証用鍵を保有し、前記アクセス機器から受領したアクセス制御チケットの検証を共通鍵方式に従つて実行する場合には、該 M A C検証用鍵を適用した改竄チェック処理を実行し、アクセス制御チケットの検証を公開鍵方式に従って実行する場合には、チケット発行手段の公開鍵証明書から取得したチケット発行手段の公開鍵に基づく署名検証処理を実行することを特徴とする請求項 4 2に記載のデータ処理方法。

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

前記アクセス制御チケットの検証を実行するための M A C検証用鍵を複数保有し、前記アクセス機器から受領したアクセス制御チケットに記録された情報に従つて適用すべき M A C検証用鍵を選択することを特徴とする請求項 4 2に記載のデータ処理方法。

4 6 . 前記アクセス制御チケットには、

前記メモリ搭載デバイスのメモリ部内の格納データの更新処理を許容するデー夕アップデートチケット（D U T ) を含み、

前記メモリ搭載デパイスは、前記アクセス制御チケットの検証を実行するための M A C検証用鍵を複数保有し、

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

前記アクセス機器から受領したデータアップデートチケット（D U T ) に指定された更新対象データがアクセス制御チケットの検証を実行するための M A C検証用鍵である場合は、複数の M A C検証用鍵から更新対象に該当しない M A C検証用鍵を選択して受領したデータアップデートチケット（D U T ) の検証処理を実行することを特徴とする請求項 4 2に記載のデータ処理方法。

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

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

前記アクセス機器からの各パーティシヨン内のデータに対するアクセス要求に対する処理を、各パーティシヨンマネージャの管理下のチケット発行手段が発行し、チケット利用手段としての前記アクセス機器から前記メモリ搭載デバイスに対して入力されるアクセス制御チケットの記述に基づいて実行することを特徴とする請求項 4 2に記載のデータ処理方法。

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

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

前記アクセス機器とのセッション中に実行したパーティション認証またはデバィス認証によって取得した公開鍵方式認証情報およびセッション鍵、または共通鍵方式認証情報およびセッシヨン鍵を対応付けた認証テーブルを生成して、当該セッシヨン期間、保持することを特徴とする請求項 4 2に記載のデータ処理方法。

4 9 . デ一夕格納可能なメモリ部を有するメモリ搭載デバイスに対するァクセス機器からのアクセス要求に応じて、前記メモリ部に対するデータ処理をコンビュ一タ · システム上で実行せしめるコンピュータ · プログラムを提供するプログラム記憶媒体であって、前記コンピュータ · プログラムは、

前記メモリ部に対するデータ処理に対応して構.成されるアクセス制御チケットを前記アクセス機器から受領するステップと、

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

5 0 . データ格納可能なメモリ部を有するメモリ搭載デバイスに対して、ァクセス機器からコマンドを発行して前記メモリ部に格納されたデータに対する処理を実行するデータアクセス制御システムであり、

前記メモリ搭載デバイスは、前記アクセス機器から、前記メモリ部に格納されたデータに対するアクセス制御データとして構成されるアクセス制御チケットを受領して、該アクセス制御チケットに記述された認証ルールに基づく認証の成立、および該アクセス制御チケットに記述されたアクセス機器の識別データの確認を条件としてデータアクセスを許容する構成であることを特徴とするデータァクセス制御システム。

5 1 . 前記アクセス制御チケットには、認証方式として公開鍵認証方式または共通鍵認証方式のいずれかまたはいずれでも許容する旨の認証方式指定情報としての認証タイプが記述され、

前記メモリ搭載デバイスは、アクセス機器から受領したアクセス制御チケットに記述された認証タイプに従って認証処理を実行する構成であることを特徴とする請求項 5 0に記載のデータアクセス制御システム。

5 2 . 前記アクセス制御チケットには、該アクセス制御チケットの発行手段のカテゴリまたは識別子が格納され、

前記メモリ搭載デバイスは、アクセス機器から受領したアクセス制御チケットに記述された該アクセス制御チケットの発行手段のカテゴリまたは識別子に基づいて、チケットが正当な発行手段により発行されたチケットであることの確認処理を実行し、該確認を条件としてデータアクセスを許容する構成であることを特徴とする請求項 5 0に記載のデータアクセス制御システム。

5 3 . 前記アクセス制御チケットには、該アクセス制御チケットの発行手段のカテゴリまたは識別子が格納され、

前記メモリ搭載デバイスは、アクセス機器から受領したアクセス制御チケットに記述された該アクセス制御チケットの発行手段のカテゴリまたは識別子と、該アクセス制御チケットの発行手段の公開鍵証明書に格納されたユーザ情報との対比に基づいてチケットが正当な発行手段により発行されたチケットであることの確認処理を実行し、該確認を条件としてデータアクセスを許容する構成であることを特徴とする請求項 5 0に記載のデ一夕アクセス制御システム。

5 4 . 前記アクセス制御チケットには、該アクセス制御チケットの利用手段であるアクセス機器のカテゴリまたは識別子が格納され、

前記メモリ搭載デバイスは、アクセス機器から受領したアクセス制御チケットに記述された該アクセス制御チケットの利用手段であるアクセス機器のカテゴリまたは識別子に基づいて、チケットが正当な利用手段により提供されたチケットであることの確認処理を実行し、該確認を条件としてデータアクセスを許容する構成であることを特徴とする請求項 5 0に記載のデータアクセス制御システム。

5 5 . 前記アクセス制御チケットには、該アクセス制御チケットの利用手段のカテゴリまたは識別子が格納され、

前記メモリ搭載デバイスは、アクセス機器から受領したアクセス制御チケットに記述された該アクセス制御チケヅトの利用手段であるアクセス機器のカテゴリまたは識別子と、該アクセス制御チケットの利用手段の公開鍵証明書に格納されたユーザ情報との対比に基づいて、チケットが正当な利用手段により提供されたチケットであることの確認処理を実行し、該確認を条件としてデータアクセスを許容する構成であることを特徴とする請求項 5 0に記載のデータアクセス制御システム。

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

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

前記アクセス機器とのセヅション中に実行したパーティション認証またはデバイス認証によって取得した公開鍵方式認証情報およびセッション鍵、または共通鍵方式認証情報およびセッシヨン鍵を対応付けた認証テーブルを生成する構成を有することを特徴とする請求項 5 0に記載のデータアクセス制御システム。

5 7 . データ格納可能なメモリ部を有するメモリ搭載デパイスであり、アクセス機器からコマンドを発行して前記メモリ部に格納されたデータに対する処理を実行する制御手段を有し、

前記制御手段は、

前記アクセス機器から、前記メモリ部に格納されたデータに対するアクセス制御データとして構成されるアクセス制御チケットを受領して、該アクセス制御チケットに記述された認証ルールに基づく認証の成立、および該アクセス制御チケットに記述されたアクセス機器の識別データの確認を条件としてデータアクセスを許容する構成であることを特徴とするメモリ搭載デバイス。

5 8 . 前記アクセス制御チケットには、認証方式として公開鍵認証方式または共通鍵認証方式のいずれかまたはいずれでも許容する旨の認証方式指定情報としての認証タイプが記述され、

前記制御手段は、

アクセス機器から受領したアクセス制御チケットに記述された認証タイプに従つて認証処理を実行する構成であることを特徴とする請求項 5 7に記載のメモリ搭載デバイス。

5 9 . 前記アクセス制御チケットには、該アクセス制御チケットの発行手段のカテゴリまたは識別子が格納され、

前記制御手段は、

アクセス機器から受領したアクセス制御チケットに記述された該アクセス制御チケットの発行手段のカテゴリまたは識別子に基づいて、チケットが正当な発行手段により発行されたチケットであることの確認処理を実行し、該確認を条件としてデータアクセスを許容する構成であることを特徴とする請求項 5 7に記載のメモリ搭載デバイス。

6 0 . 前記アクセス制御チケットには、該アクセス制御チケットの発行手段のカテゴリまたは識別子が格納され、

前記制御手段は、

アクセス機器から受領したアクセス制御チケットに記述された該アクセス制御チケットの発行手段のカテゴリまたは識別子と、該アクセス制御チケットの発行手段の公開鍵証明書に格納されたユーザ情報との対比に基づいてチケットが正当な発行手段により発行されたチケットであることの確認処理を実行し、該確認を条件としてデータアクセスを許容する構成であることを特徴とする請求項 5 7に記載のメモリ搭載デバイス。

6 1 . 前記アクセス制御チケットには、該アクセス制御チケットの利用手段であるアクセス機器のカテゴリまたは識別子が格納され、

前記制御手段は、

アクセス機器から受領したアクセス制御チケットに記述された該アクセス制御チケットの利用手段であるアクセス機器のカテゴリまたは識別子に基づいて、チケットが正当な利用手段により提供されたチケットであることの確認処理を実行し、該確認を条件としてデータアクセスを許容する構成であることを特徴とする請求項 5 7に記載のメモリ搭載デバイス。

6 2 . 前記アクセス制御チケットには、該アクセス制御チケットの利用手段のカテゴリまたは識別子が格納され、

前記制御手段は、

アクセス機器から受領したアクセス制御チケットに記述された該アクセス制御チケットの利用手段であるアクセス機器のカテゴリまたは識別子と、該アクセス制御チケットの利用手段の公開鍵証明書に格納されたユーザ情報との対比に基づいて、チケットが正当な利用手段により提供されたチケットであることの確認処理を実行し、該確認を条件としてデータアクセスを許容する構成であることを特徴とする請求項 5 7に記載のメモリ搭載デバイス。

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

前記制御手段は、

前記アクセス機器とのセッション中に実行したパーティション認証またはデバイス認証によって取得した公開鍵方式認証情報およびセッション鍵、または共通鍵方式認証情報およびセッション鍵を対応付けた認証テーブルを生成する構成を有することを特徴とする請求項 5 7に記載のメモリ搭載デバイス。

6 4 . データ格納可能なメモリ部を有するメモリ搭載デバイスに対して、ァクセス機器からコマンドを発行して前記メモリ部に格納されたデ一夕に対する処理を実行するデータアクセス制御方法であり、

前記メモリ搭載デバイスは、前記アクセス機器から、前記メモリ部に格納されたデータに対するアクセス制御データとして構成されるアクセス制御チケットを受領して、該アクセス制御チケットに記述された認証ルールに基づく認証の成立、および該アクセス制御チケットに記述されたアクセス機器の識別デ一夕の確認を条件としてデータアクセスを許容することを特徴とするデータアクセス制御方法

6 5 . 前記アクセス制御チケットには、認証方式として公開鍵認証方式または共通鍵認証方式のいずれかまたはいずれでも許容する旨の認証方式指定情報としての認証タイプが記述され、

前記メモリ搭載デバイスは、アクセス機器から受領したアクセス制御チケットに記述された認証タイプに従って認証処理を実行することを特徴とする請求項 6 4に記載のデータアクセス制御方法。

6 6 . 前記アクセス制御チケットには、該アクセス制御チケットの発行手段のカテゴリまたは識別子が格納され、

前記メモリ搭載デバイスは、アクセス機器から受領したアクセス制御チケヅトに記述された該アクセス制御チケットの発行手段のカテゴリまたは識別子に基づいて、チケットが正当な発行手段により発行されたチケットであることの確認処理を実行し、該確認を条件としてデータアクセスを許容することを特徴とする請求項 6 4に記載のデータアクセス制御方法。

6 7 . 前記アクセス制御チケットには、該アクセス制御チケットの発行手段のカテゴリまたは識別子が格納され、

前記メモリ搭載デバイスは、アクセス機器から受領したアクセス制御チケットに記述された該アクセス制御チケットの発行手段のカテゴリまたは識別子と、該アクセス制御チケットの発行手段の公開鍵証明書に格納されたユーザ情報との対比に基づいてチケットが正当な発行手段により発行されたチケットであることの確認処理を実行し、該確認を条件としてデ一夕アクセスを許容することを特徴とする請求項 6 4に記載のデータアクセス制御方法。

6 8 . 前記アクセス制御チケットには、該アクセス制御チケットの利用手段であるアクセス機器のカテゴリまたは識別子が格納され、

前記メモリ搭載デバイスは、アクセス機器から受領したアクセス制御チケヅトに記述された該アクセス制御チケットの利用手段であるアクセス機器のカテゴリまたは識別子に基づいて、チケットが正当な利用手段により提供されたチケットであることの確認処理を実行し、該確認を条件としてデータアクセスを許容することを特徴とする請求項 6 4に記載のデ一夕アクセス制御方法。

6 9 . 前記アクセス制御チケットには、該アクセス制御チケットの利用手段のカテゴリまたは識別子が格納され、

前記メモリ搭載デバイスは、アクセス機器から受領したアクセス制御チケットに記述された該アクセス制御チケットの利用手段であるアクセス機器のカテゴリまたは識別子と、該アクセス制御チケットの利用手段の公開鍵証明書に格納されたユーザ情報との対比に基づいて、チケットが正当な利用手段により提供されたチケットであることの確認処理を実行し、該確認を条件としてデータアクセスを許容することを特徴とする請求項 6 4に記載のデータアクセス制御方法。

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

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

前記アクセス機器とのセッション中に実行したパーティション認証またはデバイス認証によって取得した公開鍵方式認証情報およびセッション鍵、または共通鍵方式認証情報およびセッション鍵を対応付けた認証テーブルを生成することを特徴とする請求項 6 4に記載のデ一夕アクセス制御方法。

7 1 . データ格納可能なメモリ部を有するメモリ搭載デバイスにおいて、ァクセス機器からコマンドを発行して前記メモリ部に格納されたデータに対する処理をコンピュータ · システム上で実行せしめるコンピュータ · プログラムを提供するプログラム記憶媒体であって、前記コンピュータ · プログラムは、

前記アクセス機器から、前記メモリ部に格納されたデ一夕に対するアクセス制御データとして構成されるアクセス制御チケットを受領するステップと、該アクセス制御チケットに記述された認証ルールに基づく認証の成立、および該アクセス制御チケットに記述されたアクセス機器の識別デ一夕の確認を条件としてデ一夕アクセスを許容するステップと、

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

7 2 . 複数のデータファイルを格納したメモリ部を有するメモリ搭載デバイスに対するアクセス機器からのメモリアクセスを制御するメモリアクセス制御システムであり

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

各々が対応するパーティションマネージャによって管理されるメモリ領域としての 1以上のパーティション領域を有し、前記データファイルは前記 1以上のパ —ティション領域のいずれかに格納され、

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

前記アクセス機器からアクセス制御チケットを受領し、該アクセス制御チケットの記述に従って、データファイルに対するアクセス処理を実行する構成を有し、複数のアクセス制御チケットに基づく複数のデータファイルに対するアクセス処理を、前記メモリ搭載デバイスに対する認証としてのデバイス認証、またはァクセス対象のデータファイルの格納された各パーティションに対する認証としてのパーティシヨン認証の成立を条件として実行する構成を有することを特徴とするメモリアクセス制御システム。

7 3 . 前記各パーティション毎に設定可能な認証態様は、アクセス制御データとして構成されるアクセス制御チケットに記述され、前記メモリ搭載デバイスは、前記アクセス機器から該アクセス制御チケヅトを受領し、該アクセス制御チケットの記述に従って、各パーティシヨン毎に必要な認証態様の判別を行なう構成であることを特徴とする請求項 7 2に記載のメモリアクセス制御システム。

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

前記デバイス認証の成立を条件として、

複数のアクセス制御チケットに基づく複数の異なるパーティシヨン内のフアイルアクセスを許容する構成であることを特徴とする請求項 7 2に記載のメモリァクセス制御システム。

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

複数のアクセス制御チケットに基づく複数の異なるパ一テイシヨン内のフアイルアクセスを、前記異なるパーティション各々に対応して設定された認証条件であるパーテイション認証またはデバイス認証のすべての認証成立を条件として、許容する構成であることを特徴とする請求項 7 2に記載のメモリアクセス制御システム。

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

複数の異なるパーティション内のファイルアクセス条件として実行した複数の認証処理の結果、取得された複数のセッション鍵に基づいて唯一の統合セッション鍵を生成し、該統合セッション鍵に基づいて前記アクセス機器との通信デ一夕の暗号処理を実行する構成としたことを特徴とする請求項 7 2に記載のメモリァクセス制御システム。

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

複数の異なるパーティション内のファイルアクセス条件として実行した複数の認証処理の結果、取得された複数のセッション鍵に基づいて唯一の統合セッション鍵を各セッション鍵の排他論理和演算によって生成し、該統合セッシヨン鍵に基づいて前記アクセス機器との通信データの暗号処理を実行する構成としたことを特徴とする請求項 7 2に記載のメモリアクセス制御システム。

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

複数の異なるパーティシヨン内のファイルアクセス条件として実行した複数の認証処理の結果、取得された複数のセッション鍵の中から唯一のセッション鍵を選択し、該選択セッション鍵に基づいて前記アクセス機器との通信デ一夕の暗号処理を実行する構成としたことを特徴とする請求項 7 2に記載のメモリアクセス制御システム。

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

前記アクセス機器との間で実行したパーティション認証またはデバイス認証によって取得した公開鍵方式認証情報およびセッション鍵、または共通鍵方式認証情報およびセッション鍵を対応付けた認証テーブルを生成して、当該セッション期間、保持する構成を有することを特徴とする請求項 7 2に記載のメモリァクセス制御システム。

8 0 . 複数のデータファイルを格納したメモリ部を有するメモリ搭載デバイスであり、

アクセス機器からのメモリアクセスを制御する制御手段を有し、

前記メモリ部は、

前記制御手段は、

前記アクセス機器からアクセス制御チケットを受領し、該アクセス制御チケットの記述に従って、データファイルに対するアクセス処理を実行する構成を有し、複数のアクセス制御チケヅ卜に基づく複数のデータファイルに対するアクセス処理を、前記メモリ搭載デバイスに対する認証としてのデバイス認証、またはァクセス対象のデータファイルの格納された各パーティションに対する認証としてのパーティシヨン認証の成立を条件として実行する構成を有することを特徴とするメモリ搭載デバイス。

8 1 . 前記各パーティション毎に設定可能な認証態様は、アクセス制御データとして構成されるアクセス制御チケットに記述され、前記メモリ搭載デバイスは、前記アクセス機器から該アクセス制御チケットを受領し、前記制御手段は、該ァクセス制御チケットの記述に従って、各パーティション毎に必要な認証態様の判別を行なう構成であることを特徴とする請求項 8 0に記載のメモリ搭載デパイス c

8 2 . 前記制御手段は、

前記デバイス認証の成立を条件として、

複数のアクセス制御チケットに基づく複数の異なるパ一テイシヨン内のフアイルアクセスを許容する構成であることを特徴とする請求項 8 0に記載のメモリ搭載デバイス。

8 3 . 前記制御手段は、

複数のアクセス制御チケットに基づく複数の異なるパ一テイシヨン内のフアイルアクセスを、前記異なるパーティション各々に対応して設定された認証条件であるパーティション認証またはデバイス認証のすべての認証成立を条件として、許容する構成であることを特徴とする請求項 8 0に記載のメモリ搭載デバイス。

8 4 . 前記制御手段は、

複数の異なるパーティシヨン内のファイルアクセス条件として実行した複数の認証処理の結果、取得された複数のセッション鍵に基づいて唯一の統合セッション鍵を生成し、該統合セッション鍵に基づいて前記アクセス機器との通信データの暗号処理を実行する構成としたことを特徴とする請求項 8 0に記載のメモリ搭載デバイス。

8 5 . 前記制御手段は、

複数の異なるパーティション内のファイルアクセス条件として実行した複数の認証処理の結果、取得された複数のセッション鍵に基づいて唯一の統合セッション鍵を各セッション鍵の排他論理和演算によって生成し、該統合セッション鍵に基づいて前記アクセス機器との通信データの暗号処理を実行する構成としたことを特徴とする請求項 8 0に記載のメモリ搭載デバイス。

8 6 . 前記制御手段は、

複数の異なるパ一テイション内のファイルアクセス条件として実行した複数の認証処理の結果、取得された複数のセッション鍵の中から唯一のセッション鍵を選択し、該遗択セッション鍵に基づいて前記アクセス機器との通信デ一夕の暗号処理を実行する構成としたことを特徴とする請求項 8 0に記載のメモリ搭載デバイス。

8 7 . 前記制御手段は、

前記アクセス機器との間で実行したパーティション認証またはデバイス認証によって取得した公開鍵方式認証情報およびセッション鍵、または共通鍵方式認証情報およびセッション鍵を対応付けた認証テ一ブルを生成して、当該セッション期間、保持する構成を有することを特徴とする請求項 8 0に記載のメモリ搭載デバイス。

8 8 . 複数のデ一夕ファイルを格納したメモリ部を有するメモリ搭載デバイスに対するアクセス機器からのメモリアクセスを制御するメモリアクセス制御方法であり

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

各々が対応するパーティシヨンマネージャによって管理されるメモリ領域としての 1以上のパーティション領域を有し、前記デ一夕ファイルは前記 1以上のパ —テイシヨン領域のいずれかに格納され、

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

前記アクセス機器からアクセス制御チケットを受領し、該アクセス制御チケットの記述に従って、データファイルに対するアクセス処理を実行する構成を有し、複数のアクセス制御チケットに基づく複数のデータファイルに対するアクセス処理を、前記メモリ搭載デバイスに対する認証としてのデバイス認証、またはァクセス対象のデ一夕ファイルの格納された各パーティションに対する認証としてのパーティシヨン認証の成立を条件として実行することを特徴とするメモリァクセス制御方法。

8 9 . 前記各パーティション毎に設定可能な認証態様は、アクセス制御データとして構成されるアクセス制御チケットに記述され、前記メモリ搭載デバイスは、前記アクセス機器から該アクセス制御チケットを受領し、該アクセス制御チケットの記述に従って、各パーティション每に必要な認証態様の判別を行なうことを特徴とする請求項 8 8に記載のメモリアクセス制御方法。

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

前記デバイス認証の成立を条件として、

複数のアクセス制御チケットに基づく複数の異なるパーティシヨン内のフアイルアクセスを許容することを特徴とする請求項 8 8に記載のメモリアクセス制御方法。

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

複数のアクセス制御チケットに基づく複数の異なるパ一ティシヨン内のフアイルアクセスを、前記異なるパーティション各々に対応して設定された認証条件であるパーティシヨン認証またはデバイス認証のすべての認証成立を条件として、許容することを特徴とする請求項 8 8に記載のメモリアクセス制御方法。

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

複数の異なるパーティション内のファイルアクセス条件として実行した複数の認証処理の結果、取得された複数のセッション鍵に基づいて唯一の統合セッション鍵を生成し、該統合セッシヨン鍵に基づいて前記アクセス機器との通信デ一夕の暗号処理を実行することを特徴とする請求項 8 8に記載のメモリアクセス制御方法。

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

複数の異なるパーティシヨン内のファイルアクセス条件として実行した複数の認証処理の結果、取得された複数のセッシヨン鍵に基づいて唯一の統合セッション鍵を各セッション鍵の排他論理和演算によって生成し、該統合セッション鍵に基づいて前記アクセス機器との通信データの暗号処理を実行することを特徴とする請求項 8 8に記載のメモリアクセス制御方法。

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

複数の異なるパーティション内のファイルアクセス条件として実行した複数の認証処理の結果、取得された複数のセッション鍵の中から唯一のセッション鍵を選択し、該選択セッション鍵に基づいて前記アクセス機器との通信データの暗号処理を実行することを特徴とする請求項 8 8に記載のメモリアクセス制御方法。

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

前記アクセス機器との間で実行したパーティション認証またはデバイス認証によって取得した公開鍵方式認証情報およびセッション鍵、または共通鍵方式認証情報およびセッション鍵を対応付けた認証テーブルを生成して、当該セヅション期間、保持することを特徴とする請求項 8 8に記載のメモリアクセス制御方法。

9 6 . 複数のデータファイルを格納したメモリ部を有するメモリ搭載デバィスに対するアクセス機器からのメモリアクセスを制御するメモリアクセス制御処理をコンピュータ · システム上で実行せしめるコンピュータ · プログラムを提供するプログラム記憶媒体であって、前記コンピュータ · プログラムは、

前記メモリ搭載デバイスに対する認証としてのデバイス認証、またはアクセス対象のデータファイルの格納された各パーティシヨンに対する認証としてのパ一ティション認証のいずれかを実行する認証ステップと、

前記認証ステップにおける認証成立を条件として前記アクセス機器から受領したアクセス制御チケットに基づく複数のデータファイルに対するアクセス処理を実行するステツプと、

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