JP2002281023A - データ処理システム、メモリ搭載デバイス、およびデータ処理方法、並びにプログラム記憶媒体 - Google Patents

Abstract

(57)【要約】 【課題】 メモリ搭載デバイスとアクセス機器間におけ
るフレキシブルな認証およびアクセス制御チケットの検
証を可能としたデータ処理システムを提供する。 【解決手段】 デバイスが受領したアクセス制御チケッ
トの記述またはアクセス機器からの指定に基づいて、ア
クセス機器との相互認証の方式として公開鍵方式、また
は共通鍵方式のいずれかを決定して実行するとともに、
受領したアクセス制御チケットの記述に基づいて、アク
セス制御チケットの検証方式として公開鍵方式、または
共通鍵方式のいずれかを決定して実行する。本構成によ
り、様々な環境下において、また様々なアクセス制御チ
ケットの態様に対して、デバイスおよびアクセス装置間
のセキュアなデータ通信が可能となる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、データ処理システ
ム、メモリ搭載デバイス、およびデータ処理方法、並び
にプログラム記憶媒体に関する。さらに、詳細には、１
つのメモリを複数の領域（パーティション）に区分け
し、各パーティション内にサービス提供者あるいは関係
エンティテイの管理するデータを格納して、ユーザが１
つのメモリ搭載デバイスを用いて様々なサービスに供用
することを可能としたデータ処理システム、メモリ搭載
デバイス、およびデータ処理方法、並びにプログラム記
憶媒体に関する。

【０００２】

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

【０００３】耐タンパ構造は、例えばデバイスを半導体
によるシングルチップ構成とし、該チップに制御部、メ
モリコントローラ、不揮発性メモリ、電圧検出手段、周
波数検出手段等を備え、不揮発性メモリを外部から容易
に読み書きができないようにアルミ層のようなダミー層
に挟まれた構成とすることによって実現される。

【０００４】このようなセキュアデバイスの従来のメモ
リ構造について図９６「従来のメモリ構造」を用いて説
明する。図９６のメモリは、例えば電子マネーとして利
用可能なメモリ構成を示している。図９６に示すよう
に、メモリ領域は大きく３つに別れている。すなわち、
データ領域、メモリ管理領域、システム領域である。

【０００５】データ領域には各データ内の先頭に格納さ
れた「データ構造」に基づくデータが格納されており、
この例では、利用者名前、住所、電話番号、金額、メ
モ、ログの各データが格納される。メモリ管理領域に
は、データ領域の各データにアクセスするための格納ア
ドレス、アクセス方法、アクセス認証鍵等が格納されて
いる。例えば、データ領域のデータ１（利用者名前）の
アクセスは読み出し（Ｒｅａｄ）のみが、アクセス認証
鍵（0123……）の利用によって可能となることが示され
ている。また、システム領域には、デバイス識別子（Ｉ
Ｄ）、データ領域にメモリ領域を確保するための認証鍵
であるメモリ管理鍵等が格納される。

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

【０００７】図９６に示すような複数の分割されたデー
タ領域を持つセキュアデバイスの管理者と利用者の関係
を図９７「メモリ管理者・利用者」に示す。図９７に示
すように、セキュアデバイスの発行主体であるメモリ管
理者と、このメモリ管理者からメモリ領域を割り当てて
もらい、その割り当てられたメモリを利用するメモリ利
用者がいる。メモリ利用者としてデータ１利用者〜デー
タ６利用者がいる。メモリ利用者とは例えば前述の電子
マネーの例によれば、銀行または店舗等である。

【０００８】メモリ管理者は、メモリ領域を確保するた
めのアクセスコントロール用のメモリ管理鍵を知ってお
り、このメモリ管理鍵を利用して、それぞれのメモリ利
用者のメモリ（分割データ領域）を割り当てる。また、
メモリ利用者は各データ領域のデータにアクセスするた
めのアクセス認証鍵を知っており、このアクセス認証鍵
を利用して、それぞれ割り当てられたデータ領域内のメ
モリにアクセスすることができる。アクセスの態様とし
てはデータの読み出し（Ｒｅａｄ）、書き込み（Ｗｒｉ
ｔｅ）、残金の減額（Ｄｅｃｒｅｍｅｎｔ）など、様々
であり、それぞれの処理態様に応じてアクセス認証鍵を
個別に設定して個別の処理の可否を設定することができ
る。

【０００９】例えば図９６に示すメモリ中のデータ４
は、金額データであり、図９７に示すようにデータ４の
利用者はデータ４に対して減額（Ｄｅｃｒｅｍｅｎｔ）
の処理と、読書き（Ｒｅａｄ／Ｗｒｉｔｅ）の処理が可
能である。図９６の右下の表に示すように、データ４の
減額（Ｄｅｃｒｅｍｅｎｔ）の処理と、読書き（Ｒｅａ
ｄ／Ｗｒｉｔｅ）の処理では、アクセスキーが異なり、
各処理に対応したアクセスキーを使用してメモリにアク
セスすることが必要となる。

【００１０】図９８に、メモリ管理者がメモリ利用者に
対してメモリデバイス内のあるデータ領域を割り当てる
メモリ確保処理を説明する図を示す。図９８の「メモリ
の確保の方式」に示すように、メモリ管理者は、図の左
側に示すメモリ確保用リーダ／ライタ（Ｒ／Ｗ：Reader
／Writer）を用いて図の右側に示すメモリデバイスに対
するデータ領域の確保処理を実行する。メモリ確保用リ
ーダ／ライタ（Ｒ／Ｗ：Reader／Writer）には、メモリ
管理鍵を保持するためのセキュアなＮＶＲＡＭ（Non-Vo
latile RAM）が備えられている。なお、メモリ確保用Ｒ
／Ｗとしては、セキュアデバイスの専用の読み書きＲ／
Ｗであっても、またセキュアデバイスがＵＳＢ、ＰＣＭ
ＣＩＡなどのＩ／Ｆを持つデバイスである場合、これら
のインタフェースを介して読み書き可能な装置例えばＰ
Ｃであってもよい。

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

【００１２】相互認証に成功した後、Ｒ／Ｗはデータ構
造、データサイズ、アクセス方法、アクセス認証鍵をセ
ッション鍵で暗号化し、必要に応じてデータ検証用のＭ
ＡＣ（Message Authentication Code）値を付加してセ
キュアデバイスにコマンドを送る。コマンドを受信した
セキュアデバイスは、受信データを復号し、必要に応じ
てデータ改竄性の検証をＭＡＣ検証処理によって実行
し、その後、受信データ内のデータサイズに応じてメモ
リのデータ領域にメモリ領域を確保し、確保した領域に
データ構造を書き込むとともに、メモリ管理領域に確保
したメモリのアドレス、アクセス方法、アクセス認証鍵
を書き込む。

【００１３】このようにして、メモリデバイスには複数
の分割データ領域が設定される。次に、図９９の「メモ
リアクセス方法」に従って、複数の分割データ領域を持
つメモリデバイスに対するメモリアクセス方法について
説明する。図９９の左側のリーダライタは、メモリ利用
者の有するメモリアクセス用リーダライタ（Ｒ／Ｗ）で
あり、上述のメモリ確保用Ｒ／Ｗと同様、専用Ｒ／Ｗあ
るいはＰＣなどで構成される。メモリアクセス用リーダ
ライタ（Ｒ／Ｗ）には、アクセス認証鍵を保持するため
のセキュアなＮＶＲＡＭが備えられている。Ｒ／Ｗを用
いてセキュアデバイスのデータ領域にアクセスするため
には、まずセキュアデバイスからデバイスＩＤを読み出
す。次にＲ／Ｗ内において、アクセス認証鍵とデバイス
ＩＤを用いて認証鍵を生成し、生成した認証鍵を用いて
セキュアデバイスと相互認証を実行する。相互認証に成
功した後、Ｒ／Ｗはアクセス認証鍵に対応するデータ領
域のデータに所定のアクセスを行なう。

【００１４】このときメモリ管理領域にはアクセス方法
が規定されているため、例えば、図９９の「メモリアク
セス方法」に示すように、データ４（金額データ）の減
額（Decrement）用のアクセス認証に成功した場合は、
データ４のデータの減額は可能であっても、加算、ある
いは自由な書き換え処理はできない。このように認証処
理に用いるアクセス認証鍵をそれぞれのアクセス態様に
応じて異なる設定とすることにより各データの安全性を
高めることができる。例えば減額処理用Ｒ／Ｗが盗難に
あい、盗難にあった減額処理用Ｒ／Ｗ内のＮＶＲＡＭが
見破られた場合であっても、図９９のセキュアデバイス
内のデータ４（金額データ）の不正な増加処理が行われ
る可能性を低減することができる。

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

【００１６】

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

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

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

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

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

【００２１】

【課題を解決するための手段】本発明の第１の側面は、
データ格納可能なメモリ部を有するメモリ搭載デバイス
に対するアクセス機器からのアクセス要求に応じて、前
記メモリ部に対するデータ処理を実行するデータ処理シ
ステムであり、前記メモリ搭載デバイスは、前記メモリ
部に対するデータ処理に対応して構成されるアクセス制
御チケットを前記アクセス機器から受領して、該アクセ
ス制御チケットに記述されたルールに基づくデータ処理
を実行する構成であるとともに、前記アクセス機器から
の指定または受領したアクセス制御チケットの記述に基
づいて、前記アクセス機器との相互認証の方式を決定し
て実行するとともに、受領したアクセス制御チケットの
記述に基づいて、アクセス制御チケットの検証方式を決
定して実行し、相互認証およびチケット検証の双方の成
立を条件として前記アクセス機器からのアクセス要求に
応じる構成を有することを特徴とするデータ処理システ
ムにある。

【００２２】さらに、本発明のデータ処理システムの一
実施態様において、前記相互認証の方式は、公開鍵方式
または共通鍵方式のいずれかであり、アクセス制御チケ
ットの検証方式は、公開鍵方式または共通鍵方式のいず
れかであることを特徴とする。

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

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

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

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

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

【００２８】さらに、本発明の第２の側面は、データ格
納可能なメモリ部を有するメモリ搭載デバイスであり、
アクセス機器からのアクセス要求に応じて、前記メモリ
部に対するデータ処理を実行する制御手段を有し、前記
制御手段は、前記メモリ部に対するデータ処理に対応し
て構成されるアクセス制御チケットを前記アクセス機器
から受領して、該アクセス制御チケットに記述されたル
ールに基づくデータ処理を実行する構成であるととも
に、前記アクセス機器からの指定または受領したアクセ
ス制御チケットの記述に基づいて、前記アクセス機器と
の相互認証の方式を決定して実行するとともに、受領し
たアクセス制御チケットの記述に基づいて、アクセス制
御チケットの検証方式を決定して実行し、相互認証およ
びチケット検証の双方の成立を条件として前記アクセス
機器からのアクセス要求に応じる構成を有することを特
徴とするメモリ搭載デバイスにある。

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

【００３０】さらに、本発明のメモリ搭載デバイスの一
実施態様において、前記メモリ搭載デバイスは、前記ア
クセス制御チケットの検証を実行するためのＭＡＣ検証
用鍵を保有し、前記制御手段は、前記アクセス機器から
受領したアクセス制御チケットの検証を共通鍵方式に従
って実行する場合には、該ＭＡＣ検証用鍵を適用した改
竄チェック処理を実行し、アクセス制御チケットの検証
を公開鍵方式に従って実行する場合には、チケット発行
手段の公開鍵証明書から取得したチケット発行手段の公
開鍵に基づく署名検証処理を実行する構成であることを
特徴とする。

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

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

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

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

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

【００３６】さらに、本発明のデータ処理方法の一実施
態様において、前記相互認証の方式は、公開鍵方式また
は共通鍵方式のいずれかであり、アクセス制御チケット
の検証方式は、公開鍵方式または共通鍵方式のいずれか
であることを特徴とする。

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

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

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

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

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

【００４２】さらに、本発明の第４の側面は、データ格
納可能なメモリ部を有するメモリ搭載デバイスに対する
アクセス機器からのアクセス要求に応じて、前記メモリ
部に対するデータ処理をコンピュータ・システム上で実
行せしめるコンピュータ・プログラムを提供するプログ
ラム記憶媒体であって、前記コンピュータ・プログラム
は、前記メモリ部に対するデータ処理に対応して構成さ
れるアクセス制御チケットを前記アクセス機器から受領
するステップと、前記アクセス機器からの指定または受
領したアクセス制御チケットの記述に基づいて、前記ア
クセス機器との相互認証の方式を決定して実行するステ
ップと、受領したアクセス制御チケットの記述に基づい
て、アクセス制御チケットの検証方式を決定して実行す
るステップと、相互認証およびチケット検証の双方の成
立を条件として前記アクセス機器からのアクセス要求を
実行するステップと、を有することを特徴とするプログ
ラム記憶媒体にある。

【００４３】なお、本発明のプログラム記憶媒体は、例
えば、様々なプログラム・コードを実行可能な汎用コン
ピュータ・システムに対して、コンピュータ・プログラ
ムをコンピュータ可読な形式で提供する媒体である。媒
体は、ＣＤやＦＤ、ＭＯなどの記録媒体、通信可能媒体
など、その形態は特に限定されない。

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

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

【００４６】

【発明の実施の形態】以下、図面を参照しながら、本発
明の実施の形態について詳細に説明する。なお、説明
は、以下の項目に従って行なう。 Ａ．デバイスを利用したデータ処理システムの構成エン
ティテイおよびチケットに関する説明 Ａ１．メモリ搭載デバイスを利用したデータ管理システ
ムの概要 Ａ２．デバイスの構成 Ａ３．デバイスマネージャの構成 Ａ４．パーティションマネージャの構成 Ａ５．チケットユーザ（デバイスアクセス機器としての
リーダライタ）の構成 Ａ６．公開鍵証明書 Ａ７．デバイスのメモリ部における格納データ Ａ７．１．デバイス固有情報およびデバイス内パーティ
ション情報領域 Ａ７．２．パーティション領域 Ａ８．各チケットのデータフォーマット Ａ８．１．パーティション登録チケット（ＰＲＴ） Ａ８．２．ファイル登録チケット（ＦＲＴ） Ａ８．３．サービス許可チケット（ＳＰＴ） Ａ８．４．データアップデートチケット（ＤＵＴ） Ｂ．ユーザに対するデバイスの配布、デバイスに対する
各種設定、デバイス利用処理の詳細についての説明 Ｂ１．デバイス初期登録から利用までの流れ Ｂ２．デバイス製造エンティテイによる初期登録処理 Ｂ３．デバイスマネージャの管轄処理 Ｂ３．１．デバイスマネージャによるデバイス登録処理 Ｂ３．２．デバイスマネージャ管理下における公開鍵証
明書発行処理 Ｂ４．パーティションマネージャの管轄処理 Ｂ４．１．パーティションマネージャ管理下におけるパ
ーティション登録チケット（ＰＲＴ）を利用したパーテ
ィション設定登録、削除処理 Ｂ４．２．パーティションマネージャ管理下における公
開鍵証明書発行処理 Ｂ４．３．パーティション生成処理各方式における処理
手順 Ｂ４．４．ファイル登録チケット（ＦＲＴ）を利用した
ファイル生成、消去処理 Ｂ４．５．ファイル生成処理各方式における処理手順 Ｂ４．６．サービス許可チケット（ＳＰＴ）を利用した
サービス（ファイルアクセス）処理 Ｂ４．７．サービス許可チケット（ＳＰＴ）を利用した
アクセス処理各方式における処理手順 Ｂ５．データアップデートチケット（ＤＵＴ）を利用し
たデバイスのデータ更新処理

【００４７】

【実施例】［Ａ１．メモリ搭載デバイスを利用したデー
タ管理システムの概要］図１に本発明のデータ管理シス
テムの概要を説明する図を示す。メモリ搭載デバイス
（以下デバイス）１００はデバイス製造エンティテイ
（manufacturer）５００により製造され、デバイス管理
エンティテイとしてのデバイスマネージャ（ＤＭ：Devi
ce Manager）２００の管理の下にユーザに提供されて利
用される。ユーザに対するデバイスの提供形態は、貸与
または販売（譲渡を含む）など、いずれの形態でもよ
い。

【００４８】デバイス１００は、メモリ領域が複数のデ
ータ格納領域としてのパーティションに分割され、個々
のパーティション(Partition A,B…Ｚ)は、様々なサー
ビス主体（Ａ，Ｂ，…Ｚ）３００Ａ〜３００Ｚとしての
パーティションマネージャの管理の下、様々なサービス
に利用される。

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

【００５０】デバイス１００に対するパーティションの
設定登録処理には、正当なチケット発行手段（Ticket I
ssuer）の発行したパーティション登録チケット（ＰＲ
Ｔ：Partition Registration Ticket）が必要であり、
デバイスに設定されたパーティション内に対するファイ
ルの設定登録処理には、正当なチケット発行手段（Tick
et Issuer）の発行したファイル登録チケット（ＦＲ
Ｔ：File Registration Ticket）が必要であり、また、
各ファイルに対するアクセスには正当なチケット発行手
段（Ticket Issuer）の発行したサービス許可チケット
（ＳＰＴ：Service Permission Ticket）が必要とな
る。

【００５１】各チケットには、デバイス１００に対する
アクセスルール、例えばデバイスに対して読み書きなど
各種処理を実行するリーダ／ライタとデバイス間の相互
認証処理に関するルールの他、例えばパーティション登
録チケット（ＰＲＴ）であれば、設定できるパーティシ
ョンサイズ、ファイル登録チケット（ＦＲＴ）であれ
ば、設定できるファイルサイズ、サービス許可チケット
（ＳＰＴ）であれば、実行可能なアクセス態様（ｅｘ．
データ読み出し、書き込みなど）などが格納され、さら
にチケット発行者、チケット利用者に関する情報、その
他の情報が格納される。また、これらチケット格納デー
タに対する改竄チェック用のＩＣＶ（Integrity Check
Value）が記録され、チケットの改竄の無いことを条件
としてチケットに記録された範囲内の処理が実行可能と
なる。これらチケットの詳細については後段で説明す
る。

【００５２】図１において示す例では、パーティション
登録チケット（ＰＲＴ）を発行するチケット発行手段
（Ticket Issuer）はデバイスマネージャ（ＤＭ）２０
０内に設定され、パーティションマネージャとしてのサ
ービス主体Ａ，３００Ａ内にファイル登録チケット（Ｆ
ＲＴ）、およびサービス許可チケット（ＳＰＴ）を発行
するチケット発行手段（Ticket Issuer）が設定され
る。なお図１の構成は、サービス主体Ｂ…Ｚ，３００Ｂ
〜３００Ｚについても基本的にサービス主体Ａと同様の
構成を持つものであり、各サービス主体にファイル登録
チケット（ＦＲＴ）、およびサービス許可チケット（Ｓ
ＰＴ）を発行するチケット発行手段（TicketIssuer）が
設定される。

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

【００５４】各サービス主体３００Ａ〜３００Ｚとして
のパーティションマネージャ（ＰＭ）は、デバイスマネ
ージャ（ＤＭ）２００に対して、例えば相応の対価を支
払うなど所定の契約の下に、パーティション登録チケッ
ト（ＰＲＴ）の発行要求を行ない、デバイスマネージャ
（ＤＭ）の許諾の下、デバイスマネージャ（ＤＭ）内の
チケット発行手段（Ticket Issuer）が各サービス主体
としてのパーティションマネージャ（ＰＭ）に対してパ
ーティション登録チケット（ＰＲＴ）を発行する。

【００５５】各サービス主体（パーティションマネージ
ャ（ＰＭ））３００は、通信インタフェース（Ｉ／Ｆ）
を介してユーザの所有デバイス１００に対するアクセス
を実行し、デバイスマネージャ（ＤＭ）２００から受領
したパーティション登録チケット（ＰＲＴ）に記録され
たルールに従った認証、検証等の処理を実行し、かつパ
ーティション登録チケット（ＰＲＴ）に記録された許可
範囲内のパーティションの設定登録処理を実行する。こ
の処理については後段で詳細に説明する。

【００５６】通信Ｉ／Ｆは、有線、無線を問わず、外部
機器（デバイス）とのデータ通信可能なインタフェース
であればよく、例えば、デバイスがＵＳＢ接続構成を持
つ場合はＵＳＢＩ／Ｆ、また、ＩＣカード型であれはＩ
Ｃカード用リーダライタ、さらに公衆回線、通信回線、
インターネットなど各種の通信機能を持つデバイス、あ
るいはこれらの通信装置に接続可能なデバイスであれ
ば、各通信方式に従ったデータ通信Ｉ／Ｆとして構成さ
れる。

【００５７】また、デバイス１００にサービス主体３０
０のパーティションが設定されると、各サービス主体３
００は、通信インタフェース（Ｉ／Ｆ）を介してユーザ
所有のデバイス１００にアクセスし、各サービス主体３
００のチケット発行手段（Ticket Issuer）の発行する
ファイル登録チケット（ＦＲＴ）に記録されたルールに
従った認証、検証等の処理を実行し、かつファイル登録
チケット（ＦＲＴ）に記録された許可範囲内のファイル
の設定登録処理を実行する。この処理については後段で
詳細に説明する。

【００５８】さらに、各サービス主体３００は、通信イ
ンタフェース（Ｉ／Ｆ）を介してユーザの所有デバイス
１００にアクセスし、各サービス主体のチケット発行手
段（Ticket Issuer）の発行するサービス許可チケット
（ＳＰＴ）に記録されたルールに従った認証、検証等の
処理を実行し、かつサービス許可チケット（ＳＰＴ）に
記録された許可範囲内のアクセス（ｅｘ．データの読み
取り、書き込みなど）処理を実行する。この処理につい
ては後段で詳細に説明する。

【００５９】また、図１に示すように、デバイスマネー
ジャ２００、パーティションマネージャ３００の上位に
コード管理機関４００が設定され、個々のデバイスマネ
ージャ、パーティションマネージャに各エンティテイの
識別情報としてのコードを割り振る処理を行なってい
る。これら各マネージャに付与されたコードは、前述の
パーティション登録チケット（ＰＲＴ）、ファイル登録
チケット（ＦＲＴ）等のアクセスコントロールチケット
の格納データとされる。

【００６０】デバイス１００がユーザに提供（ｅｘ．貸
与、販売）されユーザが利用する以前に、提供デバイス
を管理するデバイスマネージャ（ＤＭ）２００が設定さ
れ、その提供デバイス内にデバイスマネージャコード
他、デバイスマネージャの管理情報が書き込まれる。こ
れらのデータ詳細については後述する。

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

【００６２】図２は、デバイス管理エンティテイとして
のデバイスマネージャ、デバイスに設定された各パーテ
ィションの管理エンティテイとして、２つのパーティシ
ョンマネージャ３００Ａ，３００Ｂ、デバイスマネージ
ャ２００に対して識別コードを付与するコード管理機関
４００を示している。さらに、デバイスマネージャ２０
０の管轄する登録局２１０からの公開鍵証明書発行要求
に応じて、デバイスマネージャ２００、デバイスマネー
ジャ管轄の各機器（パーティション登録チケット（ＰＲ
Ｔ）発行手段（ＰＲＴ Issuer）２１０、あるいはデバ
イス１００に対応するデバイス対応公開鍵証明書（CERT
-DEV）を発行するデバイスマネージャ対応認証局（ＣＡ
（ＤＥＶ）：Certificate Authority）６１０、パーテ
ィションマネージャ３００Ａ，３００Ｂ管轄の各機器
（ファイル登録チケット（ＦＲＴ）発行手段（ＦＲＴ I
ssuer）３１０、サービス許可チケット発行手段（ＳＰ
Ｔ）３２０、チケットユーザであるデバイスアクセス機
器としてのリーダライタ７１１〜７１４、あるいはデバ
イス１００のパーティションに対応するパーティション
対応公開鍵証明書（CERT-PAR）を発行するパーティショ
ンマネージャ対応認証局（ＣＡ（ＰＡＲ）：Certificat
e Authority）６２０，６３０が存在する。

【００６３】なお、図２には、認証局をデバイスマネー
ジャ対応認証局：ＣＡ（Certificate Authority） ｆｏ
ｒ ＤＭ（またはＣＡ（ＤＥＶ））６１０と、パーティ
ションマネージャ対応認証局：ＣＡ ｆｏｒ ＰＡＲ（ま
たはＣＡ（ＰＡＲ））６２０，６３０と個別に有する構
成を示しているが、両機能を持つ唯一の認証局を設けた
り、複数のパーティションマネージャに対応する共通の
認証局とデバイスマネージャ対応認証局を別々に設けた
り、その構成は自由である。

【００６４】デバイスマネージャ２００、パーティショ
ンマネージャ３００Ａ，３００Ｂは、自己の公開鍵証明
書、各マネージャの管理する各機器（チケット発行手
段、チケットユーザ）の公開鍵証明書、または、デバイ
ス１００からの公開鍵証明書発行要求を受理し、受理し
た発行要求の検証を行ない、検証の後、証明書発行要求
を認証局に対して転送する処理を行なうとともに、発行
された公開鍵証明書の管理処理を行なう登録局（ＲＡ：
Registration Authority）２２０，３３０を有する。

【００６５】これら登録局（ＲＡ）２２０，３３０を介
して各認証局（ＣＡ）６１０，６２０，６３０から発行
された公開鍵証明書はデバイス１００に格納され、デバ
イス１００に対する処理としての例えばパーティション
の設定処理、あるいはパーティションに対する処理とし
ての例えばファイル設定処理、さらにファイルに対する
アクセス処理等の際の相互認証処理、あるいは前述した
各チケットの正当性検証処理に使用される。これら公開
鍵証明書の発行処理、公開鍵証明書を使用した各処理の
詳細については後述する。

【００６６】図２において、デバイス１００は、パーテ
ィションとしてパーティションマネージャ１，３００Ａ
の管理パーティション：ＰＭ１Ａｒｅａ、パーティショ
ンマネージャ２，３００Ｂの管理パーティション：ＰＭ
２Ａｒｅａを有し、さらに、デバイスマネージャ２００
の管理領域としてのＤＭＡｒｅａを有する。

【００６７】デバイスマネージャ２００はパーティショ
ン登録チケット発行手段（ＰＲＴ Issuer）２１０を有
し、パーティションマネージャ３００は、ファイル登録
チケット発行手段（ＦＲＴ Issuer）３１０、およびサ
ービス許可チケット発行手段（ＳＰＴ Issuer）３２０
を有しており、それぞれ各チケットを発行する。

【００６８】パーティションマネージャ１，３００Ａ
は、ＰＲＴ、ＦＲＴ、ＳＰＴ各チケット毎に異なる専用
のリーダ／ライタ（デバイスに対するデータ読み出し書
き込み用のインタフェース）７１１〜７１３を有した構
成であり、パーティションマネージャ２，３００Ｂは、
各チケットに共通のリーダ／ライタ７１４を有した構成
を示している。リーダ／ライタはこのように様々な構成
をとることが可能である。

【００６９】さらに図３を用いてエンティテイの具体例
について説明する。図３には、デバイスに設定されたパ
ーティションを利用したサービスを提供するサービス主
体としてのパーティションマネージャとして東西鉄道株
式会社および南北鉄道株式会社の２つのサービス主体を
想定し、これらパーティションマネージャに対してパー
ティションの設定登録を行なうデバイスマネージャとし
て日本鉄道グループという組織を想定したデバイス利用
構成例を示している。

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

【００７１】東西鉄道株式会社は、デバイスの１つのパ
ーティション：ＰＭ１Ａｒｅａを管理するパーティショ
ンマネージャとして機能する。パーティション：ＰＭ１
Ａｒｅａは、デバイスマネージャとしての日本鉄道グル
ープによって、日本鉄道グループのＰＲＴＩｓｓｕｅｒ
の発行するパーティション登録チケット（ＰＲＴ）に記
録されたルールに従った認証、検証等の処理が実行さ
れ、かつパーティション登録チケット（ＰＲＴ）に記録
された許可範囲内のパーティションの設定登録処理によ
って設定されて、東西鉄道株式会社に付与される。

【００７２】東西鉄道株式会社は、付与されたパーティ
ション：ＰＭ１Ａｒｅａに自身の提供するサービスに応
じて様々なファイルを設定する。例えば定期券ファイ
ル、プリペイド用ファイルであり、定期券ファイル内の
データ格納エリアには例えば、定期券使用者名、使用期
間、利用区間など定期券管理データとして必要な各種デ
ータを記録する。また、プリペイド用ファイルには、使
用者名、プリペイド金額、残額データなどが記録され
る。このファイル設定処理には、東西鉄道のＦＲＴＩｓ
ｓｕｅｒの発行するファイル登録チケット（ＦＲＴ）に
記録されたルールに従った認証、検証等の処理が実行さ
れ、かつファイル登録チケット（ＦＲＴ）に記録された
許可範囲内のファイルの設定登録処理によって設定され
る。

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

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

【００７５】パーティション登録チケット（ＰＲＴ）、
ファイル登録チケット（ＦＲＴ）、およびサービス許可
チケット（ＳＰＴ）の各種チケットを発行するチケット
発行手段（Ticket Issuer）とチケット発行手段によっ
て発行されたチケットを利用するチケットユーザ（Tick
et User）の一般的な対応関係を図４に示す。

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

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

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

【００７９】また、パーティション登録チケット（ＰＲ
Ｔ）、ファイル登録チケット（ＦＲＴ）、およびサービ
ス許可チケット（ＳＰＴ）を格納し、パーティション登
録、ファイル登録、ファイル内のデータアクセス等のす
べての処理を実行可能としたチケットユーザ（ｅｘ．リ
ーダライタ）を構成することも可能である。このように
チケットユーザの実行可能な処理は、チケットユーザが
適用可能なチケットによって決定されることになる。

【００８０】［Ａ２．デバイスの構成］次に、上述の複
数のパーティションにデータ格納領域を分割されたメモ
リを持つデバイスについて説明する。図５にデバイスの
構成図を示す。

【００８１】図５に示すように、デバイス１００は、プ
ログラム実行機能、演算処理機能を持つＣＰＵ（Centra
l Processing Unit）１０１を有し、デバイスアクセス
機器としてのリーダライタ等、外部機器との通信処理用
のインタフェース機能を持つ通信インタフェース１０
２、ＣＰＵ１０１によって実行される各種プログラム、
例えば暗号処理プログラムなどを記憶したＲＯＭ（Read
Only Memory）１０３、実行プログラムのロード領域、
また、各プログラム処理におけるワーク領域として機能
するＲＡＭ（Random Access Memory）１０４、外部機器
との認証処理、電子署名の生成、検証処理、格納データ
の暗号化、復号処理等の暗号処理を実行する暗号処理部
１０５、前述したパーティション、ファイルが設定格納
されるとともに、各種鍵データを含むデバイスの固有情
報を格納した例えばＥＥＰＲＯＭ(Electrically Erasab
le Programmable ROM)によって構成されるメモリ部１０
６を有する。メモリ部１０６（ｅｘ．ＥＥＰＲＯＭ）１
０６に格納される情報については、後段で詳述する。

【００８２】メモリ部１０６のデータ格納構成を図６に
示す。メモリ部は例えば、ＥＥＰＲＯＭ(Electrically
Erasable Programmable ROM)と呼ばれる電気的に書き換
え可能な不揮発性メモリの一形態であるフラッシュメモ
リである。

【００８３】図６に示すように、本実施例においては、
１ブロック３２バイト、ブロック数０ｘＦＦＦＦのデー
タ格納領域を持ち、主要領域としてパーティション領
域、未使用領域、デバイス固有情報およびデバイス内パ
ーティション情報領域を持つ。

【００８４】パーティション領域には、前述のパーティ
ションマネージャによる管理領域であるパーティション
が設定登録される。なお、図６に示すメモリは既にパー
ティションが設定された例を示しているが、新規に製造
されたデバイスには、パーティションが設定されておら
ずパーティション領域は存在しない。パーティション
は、前述したように、デバイスマネージャの管理するパ
ーティション登録チケット（ＰＲＴ）発行手段（ＰＲＴ
Issuer）の発行したＰＲＴチケットに基づいて各サー
ビス主体としてのパーティションマネージャが所定の手
続き、すなわちパーティション登録チケット（ＰＲＴ）
に設定されたルールに従ってデバイス内のメモリに設定
する。

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

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

【００８７】［Ａ３．デバイスマネージャの構成］次
に、デバイスマネージャの構成について図７を用いて説
明する。デバイスマネージャは、ユーザに提供（販売ま
たは貸与）されるデバイスの管理エンティテイである。

【００８８】デバイスマネージャ２００は、デバイス内
のメモリ部の分割領域として設定されるパーティション
を利用してサービスを提供するサービス主体としてのパ
ーティションマネージャからの要求に応じてデバイスに
対するパーティション設定を可能化するパーティション
登録チケット（ＰＲＴ）を発行するパーティション登録
チケット（ＰＲＴ）発行手段（ＰＲＴ Issuer）２１０
を有する。

【００８９】さらに、デバイスマネージャ２００は、デ
バイスに対応するデバイス対応公開鍵証明書（CERT-DE
V）を発行する。デバイスマネージャ２００は、デバイ
スからの公開鍵証明書発行要求を受理し、受理した発行
要求の検証を行ない、検証の後、証明書発行要求を認証
局（ＣＡ（ＤＥＶ）：Certificate Authority）６１０
に対して転送する処理を行なうとともに、発行された公
開鍵証明書の管理処理を行なう登録局（ＲＡ：Registra
tion Authority）２２０としての機能を有する。

【００９０】図７に示すように、デバイスマネージャ２
００のパーティション登録チケット（ＰＲＴ）発行手段
（ＰＲＴ Issuer）２１０は、制御手段２１１と、デー
タベース２１２を有し、データベース２１２は、パーテ
ィション登録チケット（ＰＲＴ）の発行管理データとし
て、チケットの発行管理用のデータ、例えば、チケット
発行先のパーティションマネージャ識別子、チケット識
別子、チケットユーザ（ｅｘ．リーダライタ，ＰＣ，ｅ
ｔｃ）識別子などを対応付けたデータが格納される。

【００９１】また、登録局（ＲＡ：Registration Autho
rity）２２０は、制御部２２１、公開鍵証明書の発行管
理用のデータベース２２２を有し、公開鍵証明書の発行
管理データとして、例えば公開鍵証明書を発行したデバ
イス識別子、公開鍵証明書の識別子（シリアルナンバ）
等を対応付けたデータが格納される。

【００９２】デバイスマネージャ２００のパーティショ
ン登録チケット（ＰＲＴ）発行手段（ＰＲＴ Issuer）
２１０の制御手段２１１は、パーティションマネージャ
とのデータ通信により、パーティション登録チケット
（ＰＲＴ）の発行処理を実行する。また、登録局（Ｒ
Ａ：Registration Authority）２２０の制御手段２２１
は、デバイスに対する公開鍵証明書の発行処理を実行
し、この際、デバイスとの通信、デバイスマネージャ対
応認証局（ＣＡ（ＤＥＶ））６１０との通信を実行す
る。これらの処理の詳細については後段で説明する。こ
こでは、制御手段２１１，２２１の構成について図８を
用いて説明する。

【００９３】制御手段２１１，２２１はいずれも例えば
データ処理手段としてのＰＣと同様の構成により実現さ
れ、具体的には例えば図８に示すような構成を持つ。制
御手段の構成について説明する。制御部２１１１は各種
処理プログラムを実行する中央演算処理装置（ＣＰＵ:C
entral Processing Unit）によって構成される。ＲＯＭ
（Read only Memory）２１１２は、暗号処理プログラム
等の実行処理プログラムを記憶したメモリである。ＲＡ
Ｍ（Random Access Memory）２１１３は、制御部２１１
１が実行するプログラム、例えばデータベース管理プロ
グラム、暗号処理プログラム、通信プログラム等、実行
プログラムの格納領域、またこれら各プログラム処理に
おけるワークエリアとして使用される。

【００９４】表示部２１１４は、液晶表示装置、ＣＲＴ
などの表示手段を有し、制御部２１１１の制御の下、様
々なプログラム実行時のデータ、例えば処理対象のデー
タ内容等を表示する。入力部２１１５は、キーボード
や、例えばマウス等のポインティングデバイスを有し、
これら各入力デバイスからのコマンド、データ入力を制
御部２１１１に出力する。ＨＤＤ（Hard Disk Drive）
２１１６は、データベース管理プログラム、暗号処理プ
ログラム、通信プログラム等のプログラム、さらに各種
データが格納される。

【００９５】ドライブ２１１７は、例えばＨＤ（Hard D
isk）や、ＦＤ（Floppy Disk）等の磁気ディスク、ＣＤ
−ＲＯＭ（Compact Disk ROM）などの光ディスク、ミニ
ディスク等の光磁気ディスク、ＲＯＭやフラッシュメモ
リなどの半導体メモリ等の各種記録媒体に対するアクセ
スを制御する機能を持つ。磁気ディスク等の各種記録媒
体はプログラム、データ等を記憶する。通信インタフェ
ース２１１８は、ネットワーク、ケーブル接続、電話回
線等の有線、無線を介した通信のインタフェースとして
機能し、ユーザのデバイス、パーティションマネージ
ャ、認証局等の各エンティテイとの通信インタフェース
として機能する。

【００９６】［Ａ４．パーティションマネージャの構
成］次に、パーティションマネージャの構成について図
９を用いて説明する。パーティションマネージャは、ユ
ーザに提供（販売または貸与）されるデバイスに設定さ
れたパーティションの管理エンティテイである。

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

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

【００９９】パーティションマネージャ３００は、この
ようなチケットユーザに対するチケット発行処理手段と
してのファイル登録チケット（ＦＲＴ）発行手段（ＦＲ
Ｔ Issuer）３１０、およびサービス許可チケット（Ｓ
ＰＴ）発行手段（ＳＰＴ Issuer）３２０を有する。

【０１００】さらに、パーティションマネージャ３００
は、デバイスの各パーティションに対応するパーティシ
ョン対応公開鍵証明書（CERT-PAR）を発行する。パーテ
ィションマネージャ３００は、デバイスからの公開鍵証
明書発行要求を受理し、受理した発行要求の検証を行な
い、検証の後、証明書発行要求を認証局（ＣＡ（ＰＡ
Ｒ）：Certificate Authority）６２０に対して転送す
る処理を行なうとともに、発行された公開鍵証明書の管
理処理を行なう登録局（ＲＡ：Registration Authorit
y）３３０としての機能を有する。

【０１０１】図９に示すように、パーティションマネー
ジャ３００のファイル登録チケット（ＦＲＴ）発行手段
（ＦＲＴ Issuer）３１０は、制御手段３１１と、デー
タベース３１２を有し、データベース３１２は、ファイ
ル登録チケット（ＦＲＴ）の発行管理データとして、チ
ケットの発行管理用のデータ、例えば、チケット発行先
のチケットユーザ（ｅｘ．リーダライタ，ＰＣ，ｅｔ
ｃ）識別子、チケット識別子などを対応付けたデータを
格納する。

【０１０２】さらにパーティションマネージャ３００の
サービス許可チケット（ＳＰＴ）発行手段（ＳＰＴ Iss
uer）３２０は、制御手段３２１と、データベース３２
２を有し、データベース３２２は、サービス許可チケッ
ト（ＳＰＴ）の発行管理データとして、チケットの発行
管理用のデータ、例えば、チケット発行先のチケットユ
ーザ（ｅｘ．デバイスアクセス機器としてのリーダライ
タ，ＰＣ，ｅｔｃ）識別子、チケット識別子などを対応
付けたデータを格納する。

【０１０３】また、登録局（ＲＡ：Registration Autho
rity）３３０は、公開鍵証明書の発行管理用のデータベ
ース３３２を有し、公開鍵証明書の発行管理データとし
て、例えば公開鍵証明書を発行したデバイス識別子、パ
ーティション識別子、公開鍵証明書の識別子（シリアル
ナンバ）等を対応付けたデータが格納される。

【０１０４】パーティションマネージャ３００のファイ
ル登録チケット（ＦＲＴ）発行手段（ＦＲＴ Issuer）
３１０の制御手段３１１は、チケットユーザ（ｅｘ．デ
バイスアクセス機器としてのリーダライタ，ＰＣ，ｅｔ
ｃ）とのデータ通信により、ファイル登録チケット（Ｆ
ＲＴ）の発行処理を実行し、サービス許可チケット（Ｓ
ＰＴ）発行手段（Ticket Issuer）３２０の制御手段３
２１は、チケットユーザ（ｅｘ．デバイスアクセス機器
としてのリーダライタ，ＰＣ，ｅｔｃ）とのデータ通信
により、サービス許可チケット（ＳＰＴ）の発行処理を
実行する。また、登録局（ＲＡ：Registration Authori
ty）３３０の制御手段３３１は、デバイスに対する公開
鍵証明書の発行処理を実行し、この際、デバイスとの通
信、パーティションマネージャ対応認証局（ＣＡ（ＰＡ
Ｒ））６２０との通信を実行する。これらの処理の詳細
については後段で説明する。

【０１０５】なお、パーティションマネージャ３００の
制御手段３１１，３２１，３３１の構成は、図８を用い
て説明した前述のデバイスマネージャにおける制御手段
と同様の構成であるので説明を省略する。

【０１０６】［Ａ５．チケットユーザ（デバイスアクセ
ス機器としてのリーダライタ）の構成］デバイスアクセ
ス機器としてのリーダライタはデバイスに対するパーテ
ィションの設定、ファイルの設定、データの読み取り、
書き込み、金額データの減算、加算などの様々な処理を
実行する機器として構成される。デバイスに対する処理
は、処理の際に適用するパーテイション登録チケット
（ＰＲＴ）、ファイル登録チケット（ＦＲＴ）、または
サービス許可チケット（ＳＰＴ）に記録されたルールに
従う。すなわち、デバイスに対するすべての処理はこれ
ら適用するチケットによって制限される。

【０１０７】デバイスアクセス機器としてのリーダライ
タの構成例を図１０に示す。図１０に示すように、リー
ダライタ７００は、プログラム実行機能、演算処理機能
を持つＣＰＵ（Central Processing Unit）７０１を有
し、デバイス、チケット発行手段（Ticket Issuer）
等、外部機器との通信処理用のインタフェース機能を持
つ通信インタフェース７０２、ＣＰＵ７０１によって実
行される各種プログラム、例えば暗号処理プログラムな
どを記憶したＲＯＭ（Read Only Memory）７０３、実行
プログラムのロード領域、また、各プログラム処理にお
けるワーク領域として機能するＲＡＭ（Random Access
Memory）７０４、外部機器との認証処理、電子署名の生
成、検証処理、格納データの暗号化、復号処理等の暗号
処理を実行する暗号処理部７０５、認証処理、暗号化、
復号処理用の各種鍵データ、およびリーダライタの固有
情報を格納した例えばＥＥＰＲＯＭ(Electrically Eras
ableProgrammable ROM)によって構成されるメモリ部７
０６を有する。

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

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

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

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

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

【０１１３】公開鍵証明書は、公開鍵暗号方式における
認証局（ＣＡ：Certificate Authority）が発行する証
明書であり、ユーザが自己のＩＤ、公開鍵等を認証局に
提出することにより、認証局側が認証局のＩＤや有効期
限等の情報を付加し、さらに認証局による署名を付加し
て作成される証明書である。

【０１１４】図１１に公開鍵証明書のフォーマットの概
略を示す。各データの概要について説明する。証明書の
バージョン（version）番号は、公開鍵証明書フォーマ
ットのバージョンを示す。証明書の通し番号は、シリア
ルナンバ（ＳＮ：Serial Number）であり、公開鍵証明
書発行局（認証局：ＣＡ）によって設定される公開鍵証
明書のシリアルナンバである。署名アルゴリズム識別子
フィールド（Signature algorithm Identifier）の署名
アルゴリズム（algorithm）、アルゴリズムパラメータ
（parameters）は、公開鍵証明書の署名アルゴリズムと
そのパラメータを記録するフィールドである。なお、署
名アルゴリズムとしては、楕円曲線暗号およびＲＳＡが
あり、楕円曲線暗号が適用されている場合はパラメータ
および鍵長が記録され、ＲＳＡが適用されている場合に
は鍵長が記録される。発行局（認証局：ＣＡ）の名前
は、公開鍵証明書の発行者、すなわち公開鍵証明書発行
局（ＣＡ）の名称（Issuer）が識別可能な形式（Distin
guished Name）で記録されるフィールドである。証明書
の有効期限(validity)は、証明書の有効期限である開始
日時、終了日時が記録される。公開鍵証明書の利用者名
（Subject）は、ユーザである認証対象者の識別データ
が記録される。具体的には例えばユーザ機器のＩＤや、
サービス提供主体のＩＤ等の識別子またはカテゴリが記
録される。利用者公開鍵フィールド（subject Public K
ey Info）の鍵アルゴリズム（algorithm）と鍵（subjec
t Public key）は、ユーザの公開鍵情報としての鍵アル
ゴリズム、鍵情報そのものを格納するフィールドであ
る。オプション領域には、ユーザの属性データ、その他
公開鍵証明書の発行、利用に伴うオプショナルデータを
記録する。属性データとしては、ユーザの所属グループ
情報としてのデバイスマネージャコード（ＤＭＣ）、パ
ーティションマネージャコード（ＰＭＣ）が記録され
る。なお、ここでユーザは公開鍵証明書のユーザであ
り、例えばデバイスマネージャ、パーティションマネー
ジャ、チケットユーザ、チケット発行手段、デバイスな
どである。

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

【０１１６】なお、デバイスマネージャがパーティショ
ン登録チケット発行手段（PRT Issuer）を兼ねる場合
は、後述するパーティション登録チケット発行手段コー
ド（ＰＲＴＩＣ：PRT Issuer Code）は、デバイスマネ
ージャコード（ＤＭＣ）として設定可能であり、また、
パーティションマネージャがファイル登録チケット発行
手段、サービス許可チケット発行手段を兼ねる場合は、
ファイル登録チケット発行手段コード（ＦＲＴＩＣ：FR
T Issuer Code）、サービス許可チケット発行手段コー
ド（ＳＰＴＩＣ：SPT Issuer Code）をパーティション
マネージャコード（ＰＭＣ）として設定可能である。な
お、これらのコードは後述する各チケット（ＰＲＴ，Ｆ
ＲＴ，ＳＰＴなど）にも記録される。

【０１１７】また、各チケット発行手段にデバイスマネ
ージャコード（ＤＭＣ）、パーティションマネージャコ
ード（ＰＭＣ）と異なる独自のコードを割り当てる構成
としてもよい。この場合のコード付与は、前述のコード
管理機関が実行する。

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

【０１１９】公開鍵暗号方式を用いた電子署名の生成方
法について、図１２を用いて説明する。図１２に示す処
理は、ＥＣ−ＤＳＡ（（Elliptic Curve Digital Signa
tureAlgorithm）、IEEE P1363/D3）を用いた電子署名デ
ータの生成処理フローである。なお、ここでは公開鍵暗
号として楕円曲線暗号（Elliptic Curve Cryptography
（以下、ＥＣＣと呼ぶ））を用いた例を説明する。な
お、本発明のデータ処理装置においては、楕円曲線暗号
以外にも、同様の公開鍵暗号方式における、例えばＲＳ
Ａ暗号（（Rivest、Shamir、Adleman）など（ANSI X9.3
1））を用いることも可能である。

【０１２０】図１２の各ステップについて説明する。ス
テップＳ１において、ｐを標数、a、bを楕円曲線の係数
（楕円曲線：ｙ²＝ｘ³＋ａｘ＋ｂ，４ａ³＋２７ｂ²≠０
（ｍｏｄ ｐ））、Ｇを楕円曲線上のベースポイント、r
をＧの位数、Ｋｓを秘密鍵（０＜Ｋｓ＜ｒ）とする。ス
テップＳ２おいて、メッセージＭのハッシュ値を計算
し、f=Hash(M)とする。

【０１２１】ここで、ハッシュ関数を用いてハッシュ値
を求める方法を説明する。ハッシュ関数とは、メッセー
ジを入力とし、これを所定のビット長のデータに圧縮
し、ハッシュ値として出力する関数である。ハッシュ関
数は、ハッシュ値（出力）から入力を予測することが難
しく、ハッシュ関数に入力されたデータの1ビットが変
化したとき、ハッシュ値の多くのビットが変化し、ま
た、同一のハッシュ値を持つ異なる入力データを探し出
すことが困難である特徴を有する。ハッシュ関数として
は、ＭＤ４、ＭＤ５、ＳＨＡ−１などが用いられる場合
もあるし、ＤＥＳ−ＣＢＣが用いられる場合もある。こ
の場合は、最終出力値となるＭＡＣ（チェック値：ＩＣ
Ｖに相当する）がハッシュ値となる。

【０１２２】続けて、ステップＳ３で、乱数ｕ（０＜ｕ
＜ｒ）を生成し、ステップＳ４でベースポイントをｕ倍
した座標Ｖ（Ｘｖ，Ｙｖ）を計算する。なお、楕円曲線
上の加算、２倍算は次のように定義されている。

【０１２３】

【数１】P=(Ｘａ，Ｙａ),Q=(Ｘｂ，Ｙｂ),R=(Ｘｃ,Ｙ
ｃ)=P+Qとすると、 P≠Qの時（加算）、 Xｃ=λ²−Ｘａ−Ｘｂ Ｙｃ=λ×(Ｘａ−Ｘｃ)−Ｙａ λ=(Ｙｂ−Ｙａ)／(Ｘｂ−Ｘａ) P=Qの時（2倍算）、 Ｘｃ=λ²−２Ｘａ Ｙｃ=λ×(Ｘａ−Ｘｃ)−Ｙａ λ=(３(Ｘａ)²＋ａ)／(２Ｙａ)

【０１２４】これらを用いて点Ｇのｕ倍を計算する（速
度は遅いが、最もわかりやすい演算方法として次のよう
に行う。Ｇ、２×Ｇ、４×Ｇ・・を計算し、uを2進数展
開して1が立っているところに対応する２ⁱ×Ｇ（Ｇをｉ
回２倍算した値（ｉはｕのＬＳＢから数えた時のビット
位置））を加算する。

【０１２５】ステップＳ５で、ｃ＝Ｘｖｍｏｄ ｒを計
算し、ステップＳ６でこの値が０になるかどうか判定
し、０でなければステップＳ７でｄ＝［（ｆ＋ｃＫｓ）
／ｕ］ｍｏｄ ｒを計算し、ステップＳ８でｄが０であ
るかどうか判定し、ｄが０でなければ、ステップＳ９で
ｃおよびｄを電子署名データとして出力する。仮に、ｒ
を１６０ビット長の長さであると仮定すると、電子署名
データは３２０ビット長となる。

【０１２６】ステップＳ６において、ｃが０であった場
合、ステップＳ３に戻って新たな乱数を生成し直す。同
様に、ステップＳ８でｄが０であった場合も、ステップ
Ｓ３に戻って乱数を生成し直す。

【０１２７】次に、公開鍵暗号方式を用いた電子署名の
検証方法を、図１３を用いて説明する。ステップＳ１１
で、Ｍをメッセージ、pを標数、a、bを楕円曲線の係数
（楕円曲線：ｙ²=ｘ³＋ａｘ＋ｂ，４ａ³＋２７ｂ²≠０
（ｍｏｄ ｐ））、Ｇを楕円曲線上のベースポイント、r
をＧの位数、ＧおよびＫｓ×Gを公開鍵（０＜Ｋｓ＜
ｒ）とする。ステップＳ１２で電子署名データｃおよび
ｄが０＜ｃ＜ｒ、０＜ｄ＜ｒを満たすか検証する。これ
を満たしていた場合、ステップＳ１３で、メッセージＭ
のハッシュ値を計算し、ｆ＝Ｈａｓｈ（Ｍ）とする。次
に、ステップＳ１４でh=1/d mod rを計算し、ステップ
Ｓ１５でｈ１＝ｆｈ ｍｏｄ ｒ、ｈ２=ｃｈｍｏｄ
ｒを計算する。

【０１２８】ステップＳ１６において、既に計算したｈ
１およびｈ２を用い、点Ｐ＝（Ｘｐ，Ｙｐ）＝ｈ１×Ｇ
＋ｈ２・Ｋｓ×Ｇを計算する。電子署名検証者は、ベー
スポイントＧおよびＫｓ×Ｇを知っているので、図１２
のステップＳ４と同様に楕円曲線上の点のスカラー倍の
計算ができる。そして、ステップＳ１７で点Ｐが無限遠
点かどうか判定し、無限遠点でなければステップＳ１８
に進む（実際には、無限遠点の判定はステップＳ１６で
できてしまう。つまり、Ｐ＝（Ｘ，Ｙ）、Ｑ＝（Ｘ，−
Ｙ）の加算を行うと、λが計算できず、Ｐ＋Ｑが無限遠
点であることが判明している）。ステップＳ１８でＸｐ
ｍｏｄ ｒを計算し、電子署名データｃと比較する。最
後に、この値が一致していた場合、ステップＳ１９に進
み、電子署名が正しいと判定する。

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

【０１３０】ステップＳ１２において、電子署名データ
ｃまたはｄが、０＜ｃ＜ｒ、０＜ｄ＜ｒを満たさなかっ
た場合、ステップＳ２０に進む。また、ステップＳ１７
において、点Ｐが無限遠点であった場合もステップＳ２
０に進む。さらにまた、ステップＳ１８において、Ｘｐ
ｍｏｄ ｒの値が、電子署名データｃと一致していなか
った場合にもステップＳ２０に進む。

【０１３１】ステップＳ２０において、電子署名が正し
くないと判定された場合、データは改竄されているか、
公開鍵に対応した秘密鍵を保持する者が電子署名を生成
したのではないことがわかる。

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

【０１３３】［Ａ７．デバイスのメモリ部における格納
データ］次に、本発明のパーティション分割されたメモ
リ領域を持つデバイスの格納データについて説明する。
先に、図６を用いて説明した通り、デバイスは例えばＥ
ＥＰＲＯＭからなるメモリ部を持ち、主要領域としてパ
ーティション領域、未使用領域、デバイス固有情報およ
びデバイス内パーティション情報領域を有する。これら
各領域の格納データについて以下、図を参照して順次説
明する。

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

【０１３５】図１４は、製造情報ブロック（Manufactur
e Information Block）のデータ構成を示している。各
領域の数値は、バイト数を示す。図６を用いて説明した
ように、本実施例の構成では１ブロック：３２バイト構
成である。なお、図中グレー部分は暗号化されたデータ
でも、暗号化されていなくてもよい。

【０１３６】製造情報ブロック（Manufacture Informat
ion Block）には、以下のデータが格納される。 * Writable Flag : ブロックへ書き込みが許可されてい
るかの判別フラグ(ex.0xffff : 書込許可, 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）固有
識別子としてＩＤｍと定義する。なお、デバイス（Devi
ce）固有識別子は製造情報ブロック（Manufacture Info
rmation Block）に書き込まれた情報全体、あるいは書
き込まれた情報の一部、または書き込まれた情報に基づ
いて取得される演算データから取得する構成とすること
も可能である。

【０１３８】図１５は、デバイス管理情報ブロック（De
vice Management Information Block）のデータ構成を
示す。デバイス管理情報ブロック（Device Management
Information Block）には以下のデータが格納される。

【０１３９】* Writable Flag : ブロックへ書き込みが
許可されているかの判別フラグ (ex. 0xffff : 書込許
可, others : 書込不可） * DMC (Device Manager Code) :デバイスマネージャ
（ＤＭ：Device Manager）の識別番号 * DMC Version : デバイスマネージャコード（ＤＭＣ）
のバージョン。例えば、ＤＭＣを更新する時の比較条件
として用いられる。 * Total Block Number in Device :デバイス（Device）
内の全ブロック数 * Free Block Number in Device :デバイス（Device）
内の空きブロック数 * Partition Number : 現在登録されているパーティシ
ョン（Partition）数 * Pointer of Free Area :空き領域のポインタ

【０１４０】図１６は、公開鍵系デバイス鍵定義ブロッ
ク（Device Key Definition Block（PUB））のデータ構
成を示す。公開鍵系デバイス鍵定義ブロック（Device K
eyDefinition Block（PUB））には以下のデータが格納
される。

【０１４１】* PUB_CA(DEV) Pointer :デバイスマネー
ジャの管轄する登録局を介して公開鍵証明書の発行を行
なうデバイスマネージャ対応認証局（ＣＡ（ＤＥＶ））
の公開鍵が格納されているブロックへのポインタ * PUB_CA(DEV) Size :認証局ＣＡ（ＤＥＶ）の公開鍵の
サイズ * PRI_DEV Pointer :デバイス（Device）の秘密鍵が格
納されているブロックへのポインタ * PRI_DEV Size :デバイス（Device）の秘密鍵のサイズ * PARAM_DEV Pointer :デバイス（Device）の公開鍵パ
ラメータが格納されているブロックへのポインタ * PARAM_DEV Size :デバイス（Device）の公開鍵パラメ
ータのサイズ * CERT_DEV Pointer :認証局ＣＡ（ＤＥＶ）が発行した
デバイス（Device）の公開鍵証明書が格納されているブ
ロックへのポインタ * CERT_DEV Size : :認証局ＣＡ（ＤＥＶ）が発行した
デバイス（Device）の公開鍵証明書のサイズ * CRL_DEV Pointer :デバイス（Device）のリボケーシ
ョンリスト（Revocation List）が格納されているブロ
ックへのポインタ * CRL_DEV Size :デバイス（Device）のリボケーション
リスト（Revocation List）のサイズ * PRTIC（PRT Issuer Category) :パーティション登録
チケット（ＰＲＴ）発行者カテゴリ * PRTIC Version : パーティション登録チケット（ＰＲ
Ｔ）発行者カテゴリ（ＰＲＴＩＣ）のバージョン * DUTIC_DEV（DUT Issuer Category) :データアップデ
ートチケット（ＤＵＴ：Data Update Ticket）発行者カ
テゴリ * DUTIC_DEV Version :データアップデートチケット
（ＤＵＴ：Data Update Ticket）発行者（ＤＵＴＩＣ）
のバージョン

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

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

【０１４４】また、上記のデータ中のデータアップデー
トチケット（ＤＵＴ：Data UpdateTicket）は、デバイ
スに格納された様々なデータの更新処理を実行する際に
更新処理を許可し制限するためのアクセス制限チケット
であり、前述のＰＲＴ，ＦＲＴ，ＳＰＴの各チケットと
同様、デバイスに対するアクセスルールを記録したチケ
ットである。このデータアップデートチケット（ＤＵ
Ｔ：Data Update Ticket）については、後段でさらに詳
細に説明する。

【０１４５】図１７は、共通鍵系デバイス鍵定義ブロッ
ク（Device Key Definition Block(Common)）のデータ
構成を示す。共通鍵系デバイス鍵定義ブロック（Device
KeyDefinition 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 :パーティション登録チケット（ＰＲ
Ｔ）のＭＡＣ検証用鍵(Kprt)が格納されているブロック
へのポインタ * Kprt Size : パーティション登録チケット（ＰＲＴ）
のＭＡＣ検証用鍵(Kprt)のサイズ * Kdut_DEV1-4 Pointer :データアップデートチケット
（ＤＵＴ）のＭＡＣ検証用鍵(Kdut)が格納されているブ
ロックへのポインタ * Kdut_DEV1-4 Size : データアップデートチケット
（ＤＵＴ）のＭＡＣ検証用鍵(Kdut)のサイズ * IRL_DEV Pointer :デバイス（Device）のリボケーシ
ョンリスト（Revocation List）として、不正デバイス
のデバイスＩＤ(Device ID)が格納されているブロック
へのポインタ * IRL_DEV Size :デバイス（Device）のリボケーション
リスト（Revocation List）のサイズ

【０１４７】上述のデータ中に示される双方向個別鍵認
証の方法、ＭＡＣ（Message Authenticate Code）検証
処理については、後段で詳細に説明する。また、Kdut_D
EV は４種類存在し、(Kdut_DEV1, Kdut_DEV2), (Kdut_D
EV3, Kdut_DEV4) のペアで使われる。例えば、Kdut_DEV
1, 3 はMAC生成用、Kdut_DEV2, 4は暗号用に使われる。

【０１４８】図１８は、デバイス鍵領域（Device Key A
rea）のデータ構成を示す。デバイス鍵領域（Device Ke
y Area）には以下のデータが格納される。なお、デバイ
ス鍵領域（Device Key Area）の各格納鍵には、バージ
ョン情報が併せて格納される。鍵の更新時には、バージ
ョンについても併せて更新される。

【０１４９】* IRL_DEV :排除デバイス（Device）、排
除機器（デバイスアクセス機器としてのリーダライタ、
ＰＣ等のチケットユーザ、チケット発行手段）の識別子
（ＩＤ）を登録したリボケーションリスト（Revocation
List (Device ID)） * CRL_DEV :排除デバイス（Device）、排除機器（デバ
イスアクセス機器としてのリーダライタ、ＰＣ等のチケ
ットユーザ、チケット発行手段）の公開鍵証明書識別子
（ｅｘ．シリアルナンバ：ＳＮ）を登録したリボケーシ
ョンリスト（Revocation List (Certificate)） * Kdut_DEV1 :データアップデートチケット（ＤＵＴ）
のＭＡＣ検証用鍵 * Kdut_DEV2 :データ更新用暗号鍵 * Kdut_DEV3 :データアップデートチケット（ＤＵＴ）
のＭＡＣ検証用鍵 * Kdut_DEV4 :データ更新用暗号鍵 * Kprt :パーティション登録チケット（ＰＲＴ）のＭＡ
Ｃ検証用鍵 * CERT_DEV : デバイスマネージャ対応公開鍵を発行す
る認証局ＣＡ（ＤＥＶ）が発行したデバイス（Device）
の公開鍵証明書 * PRI_DEV :デバイス（Device）の秘密鍵 * PARAM_DEV :デバイス（Device）の公開鍵パラメータ * PUB_CA(DEV) :デバイスマネージャ対応公開鍵を発行
する認証局ＣＡ（ＤＥＶ）の公開鍵 * Kauth＿DEV_B :双方向個別鍵認証用共通鍵 * MKauth＿DEV_A :双方向個別鍵認証用マスター鍵

【０１５０】なお、図に示すデバイス鍵領域（Device K
ey Area）には Kauth＿DEV_A :双方向個別鍵認証用共通
鍵、MKauth＿DEV_B :双方向個別鍵認証用マスター鍵が
格納されているが、これらの鍵は、デバイスが共通鍵認
証処理を行なう要請が無い場合は格納しない構成として
もよく、また、Kprt :パーティション登録チケット（Ｐ
ＲＴ）のＭＡＣ検証用鍵についても、デバイスがチケッ
ト検証処理を実行しない構成の場合には格納しない構成
としてもよい。

【０１５１】また、IRL_DEV :排除デバイス（Device）
のデバイス識別子（ＩＤ）を登録したリボケーションリ
スト（Revocation List (Device ID)）、 CRL_DEV :排
除デバイス（Device）の公開鍵証明書識別子（ｅｘ．シ
リアルナンバ：ＳＮ）を登録したリボケーションリスト
（Revocation List (Certificate)、についても、リボ
ーク（排除）されたデバイスが存在しない場合、あるい
は他のソースを使用してリボケーションリストを取得す
る構成とする場合には、リボケーションリストを格納し
ない構成としてもよい。

【０１５２】図１９は、パーティション定義ブロック
（Partition Definition Block）のデータ構成を示す。
パーティション定義ブロック（Partition Definition B
lock）には以下のデータが格納される。

【０１５３】* PMC (Partition Manager Code) :パーテ
ィションマネージャ（Partition Manager）に割り当て
られたコード（ＰＭＣ）。例えば番号。 * PMC Version : パーティションマネージャコード（Ｐ
ＭＣ）のバージョン * Partition Start Position :パーティション（Partit
ion）格納先スタートアドレス * Partition Size :パーティション（Partition）のサ
イズ

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

【０１５５】（Ａ７．２．パーティション領域）次に、
パーティション領域の各データについて説明する。パー
ティション領域は、パーティションマネージャの管理領
域である。前述したように、デバイスマネージャの管理
するパーティション登録チケット（ＰＲＴ）発行手段
（ＰＲＴ Issuer）の発行したＰＲＴチケットに基づい
て各サービス主体としてのパーティションマネージャが
所定の手続き、すなわちパーティション登録チケット
（ＰＲＴ）に設定されたルールに従ってデバイス内のメ
モリに設定する。以下、パーティション領域のデータ構
成について説明する。

【０１５６】図２０は、パーティション管理情報ブロッ
ク（Partition Management Information Block）のデー
タ構成を示す。パーティション管理情報ブロック（Part
ition Management Information Block）には以下のデー
タが格納される。

【０１５７】* PMC (Partition Manager Code) :パーテ
ィション（Partition）保有者の番号 * PMC Version :パーティションマネージャコード（Ｐ
ＭＣ）のバージョン * Total Block Number in Partition :パーティション
（Partition）内の全ブロック数 * Free Block Number in Partition : パーティション
（Partition）内の空きブロック数 * Pointer of Free Area : パーティション（Partitio
n）内の未使用領域のポインタ * File Number :パーティションに現在登録されている
ファイル（File）数

【０１５８】図２１は、公開鍵系パーティション鍵情報
ブロック（Partition Key Definition Block(PUB)）の
データ構成を示す。公開鍵系パーティション鍵情報ブロ
ック（Partition Key Definition Block(PUB)）には以
下のデータが格納される。

【０１５９】* PUB_CA(PAR) Pointer :パーティション
マネージャの管轄登録局を介して公開鍵証明書を発行す
る認証局ＣＡ（ＰＡＲ）の公開鍵が格納されているブロ
ックへのポインタ * PUB_CA(PAR) Size :認証局ＣＡ（ＰＡＲ）の公開鍵の
サイズ * PRI_PAR Pointer :パーティション（Partition）の秘
密鍵が格納されているブロックへのポインタ * PRI_PAR Size :パーティション（Partition）の秘密
鍵のサイズ * PARAM_PAR Pointer :パーティション（Partition）の
公開鍵パラメータが格納されているブロックへのポイン
タ * PARAM_PAR Size :パーティション（Partition）の公
開鍵パラメータのサイズ * CERT_PAR Pointer :認証局ＣＡ（ＰＡＲ）が発行した
パーティション（Partition）の公開鍵証明書が格納さ
れているブロックへのポインタ * CERT_PAR Size :認証局ＣＡ（ＰＡＲ）が発行したパ
ーティション（Partition）の公開鍵証明書のサイズ * CRL_PAR Pointer :パーティション（Partition）のリ
ボケーションリスト（Revocation List）が格納されて
いるブロックへのポインタ * CRL_PAR Size :パーティション（Partition）のリボ
ケーションリスト（Rev ocation List）のサイズ* FRTIC（FRT Issuer Categor
y) :ファイル登録チケット（ＦＲＴ）発行者カテゴリ * FRTIC Version : ファイル登録チケット（ＦＲＴ）発
行者カテゴリ（ＦＲＴＩＣ）のバージョン * DUTIC_PAR（DUT Issuer Category) :データアップデ
ートチケット（ＤＵＴ）発行者カテゴリ * DUTIC_PAR Version : データアップデートチケット
（ＤＵＴ）発行者カテゴリ（ＤＵＴＩＣ）のバージョン

【０１６０】図２２は、共通鍵系パーティション鍵情報
ブロック（Partition Key Definition Block(Common))
データ構成を示す。共通鍵系パーティション鍵情報ブロ
ック（Partition Key Definition Block(Common)）には
以下のデータが格納される。

【０１６１】* Mkauth_PAR_A Pointer : 双方向個別鍵
認証用マスター鍵(MKauth_PAR_A)のポインタ * Mkauth_PAR_A Size :双方向個別鍵認証用マスター鍵
(MKauth_PAR_A)のサイズ * Kauth_PAR_B Pointer :双方向個別鍵認証用鍵(Kauth_
PAR_B)のポインタ * Kauth_PAR_B Size :双方向個別鍵認証用鍵(Kauth_PAR
_B)のサイズ * Kfrt Pointer :ファイル登録チケット（ＦＲＴ）のＭ
ＡＣ検証用鍵(Kfrt)が格納されているブロックへのポイ
ンタ * Kfrt Size :ファイル登録チケット（ＦＲＴ）のＭＡ
Ｃ検証用鍵(Kfrt)のサイズ * Kdut_PAR1-4 Pointer :データアップデートチケット
（ＤＵＴ）のＭＡＣ検証用鍵(Kdut)が格納されているブ
ロックへのポインタ * Kdut_PAR1-4 Size : データアップデートチケット
（ＤＵＴ）のＭＡＣ検証用鍵(Kdut)のサイズ * IRL_PAR Pointer :パーティション（Partition）の排
除デバイスのＩＤを格納したリボケーションリスト（Re
vocation List−Device ID)が格納されているブロック
へのポインタ * IRL_PAR Size :パーティション（Partition）のリボ
ケーションリスト（Revocation List−Device ID)のサ
イズ

【０１６２】上述のデータ中に示される双方向個別鍵認
証の方法、ＭＡＣ（Message Authenticate Code）検証
処理については、後段で詳細に説明する。また、Kdut_P
AR は４種類存在し、(Kdut_PAR1, Kdut_PAR2), (Kdut_P
AR3, Kdut_PAR4) のペアで使われる。例えば、Kdut_PAR
1, 3 はMAC生成用、Kdut_PAR2, 4は暗号用に使われる。

【０１６３】図２３は、パーティション鍵領域（Partit
ion Key Area）のデータ構成を示す。パーティション鍵
領域（Partition Key Area）には以下のデータが格納さ
れる。なお、パーティション鍵領域（Partition Key Ar
ea）の各格納鍵には、バージョン情報が併せて格納され
る。鍵の更新時には、バージョンについても併せて更新
される。

【０１６４】* IRL_PAR :パーティションアクセス排除
デバイス（Device）、排除機器（デバイスアクセス機器
としてのリーダライタ、ＰＣ等のチケットユーザ、チケ
ット発行手段）の識別子（ＩＤ）を登録したリボケーシ
ョンリスト（Revocation List (Device ID)） * CRL_PAR :パーティションアクセス排除デバイス（Dev
ice）、排除機器（デバイスアクセス機器としてのリー
ダライタ、ＰＣ等のチケットユーザ、チケット発行手
段）の公開鍵証明書識別子（ｅｘ．シリアルナンバ：Ｓ
Ｎ）を登録したリボケーションリスト（Revocation Lis
t (Certificate) * Kdut_PAR1 :データアップデートチケット（ＤＵＴ）
のＭＡＣ検証用鍵* Kdut_PAR2 :データ更新用暗号鍵 * Kdut_PAR3 : データアップデートチケット（ＤＵＴ）
のＭＡＣ検証用鍵 * Kdut_PAR4 :データ更新用暗号鍵 * Kfrt :ファイル登録チケット（ＦＲＴ）のＭＡＣ検証
用鍵 * CERT_PAR :認証局ＣＡ（ＰＡＲ）が発行したパーティ
ション（Partition）の公開鍵証明書 * PRI_PAR :パーティション（Partition）の秘密鍵 * PARAM_PAR :パーティション（Partition）の公開鍵パ
ラメータ * PUB_CA(PAR) :認証局ＣＡ（ＰＡＲ）の公開鍵 * Mkauth_PAR_A :双方向個別鍵認証用マスター鍵 * Kauth_PAR_B :双方向個別鍵認証用共通鍵

【０１６５】図２４は、ファイル定義ブロック（ＦＤ
Ｂ：File Definition Block）のデータ構成を示す。フ
ァイル定義ブロック（File Definition Block）には以
下のデータが格納される。

【０１６６】* File ID :ファイル（File）識別名 * File Start Position :ファイル（File）スタートア
ドレス * File Size :ファイル（File）サイズ * SPTIC（SPT Issuer Category) :サービス許可チケッ
ト（ＳＰＴ）発行者カテゴリ * SPTIC Version : サービス許可チケット（ＳＰＴ）発
行者カテゴリ（SPTIC）のバージョン * File Structure Type Code :ファイル構造タイプ（Fi
le Structure Type）のコード * Acceptable Authentication Type :許容認証タイプを
示す。各ファイル構造タイプ（File Structure Type）
に対して定義されるアクセスモードとこのフィールドの
各ビット（本例では最大１６個）が対応する。詳細は下
記に説明する。 * Acceptable Verification Type:許容検証タイプを示
す。各ファイル構造タイプ（File Structure Type）に
対して、定義されるアクセスモードとこのフィールドの
各ビット（本例では最大１６個）が対応する。詳細は下
記に説明する。 * Kspt :サービス許可チケット（ＳＰＴ）のＭＡＣ検証
用鍵(Kspt)

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

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

【０１６９】また、本実施例構成においては、許容認証
タイプ（Acceptable Authentication Type）、許容検証
タイプ（Acceptable Verification Type）は設定が
「１」のときに公開鍵方式の認証または検証を必要とす
る設定としてあるが、これらの各フィールドを２ビット
単位の構成として、値が「１１」の場合には公開鍵方
式、「０１」の場合には共通鍵方式、「００」「１０」
の場合には公開鍵方式、共通鍵方式のいずれでもは許容
する、などの細分化した設定としてもよい。

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

【０１７１】ファイル構造には、図２５に示す各種構造
（File Structure）があり、それぞれにコード０００１
〜０００７が割り当てられる。各構造の意味を以下に示
す。

【０１７２】* Random :本ファイル構造を持つデータは
すべての読書きがランダムに可能なファイルである。 * Purse :本ファイル構造を持つデータは、金額情報デ
ータであり、減算（Sub）、加算（Add）など金額の価値
変更処理が可能であるデータファイルである。 * Cyclic :本ファイル構造を持つデータは循環型（Cycl
ic）のデータ書き込みが可能なファイル構造である。 * Log :本ファイル構造を持つデータは、ログデータフ
ァイルであり、各データ処理情報についての記録情報フ
ァイルである。 * Key :本ファイル構造を持つデータファイルは、鍵情
報ファイルであることを示す。 * 複合ファイル :上記各種ファイル構造の複合構造（Ｅ
ｘ．PurseとLog）を持つファイルである。複合ファイル
には、その組み合わせパターンにより異なるコード（図
では０００６：複合ファイル１、０００７：複合ファイ
ル２）が割り当てられる。

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

【０１７４】［Ａ８．各チケットのデータフォーマッ
ト］前述したように、デバイスに対するパーティション
の設定登録処理には、正当なチケット発行手段（Ticket
Issuer）の発行したパーティション登録チケット（Ｐ
ＲＴ：Partition Registration Ticket）、デバイスに
設定されたパーティション内に対するファイルの設定登
録処理には、正当なチケット発行手段（Ticket Issue
r）の発行したファイル登録チケット（ＦＲＴ：File Re
gistration Ticket）、また、各ファイルに対するアク
セスには正当なチケット発行手段（Ticket Issuer）の
発行したサービス許可チケット（ＳＰＴ：Service Perm
ission Ticket）が必要となる。また、前述のデバイス
のメモリ部のデータ説明の欄で簡単に説明したように、
デバイス格納データの更新処理にはデータアップデート
チケット（ＤＵＴ）を必要とする。

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

【０１７６】（Ａ８．１．パーティション登録チケット
（ＰＲＴ））パーティション登録チケット（ＰＲＴ：Pa
rtition Registration Ticket）は、デバイスに対する
パーティションの設定登録処理の際に適用されるアクセ
スコントロールチケットである。正当なデバイスマネー
ジャ管轄下のチケット発行手段（Ticket Issuer）の発
行したＰＲＴを用い、ＰＲＴに記録された手続きに従っ
て、パーティションマネージャの管轄下のチケットユー
ザ（ｅｘ．デバイスアクセス機器としてのリーダライ
タ）によりデバイスにアクセスすることで、ＰＲＴに記
録された制限内でパーティションを設定することができ
る。

【０１７７】図２６にパーティション登録チケット（Ｐ
ＲＴ：Partition Registration Ticket）のデータフォ
ーマットを示す。パーティション登録チケット（ＰＲ
Ｔ：Partition Registration Ticket）には以下に説明
するデータが格納される。

【０１７８】* Ticket Type :チケット（Ticket）の種
別。 * Format Version :チケット（Ticket）のフォーマット
バージョン * Ticket Issuer :デバイスマネージャの識別子（＝Ｄ
ＭＣ） * 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］が公開鍵認証
の場合：識別名（ＤＮ：Distinguished Name）またはカ
テゴリ（Category）またはシリアル番号（ＳＮ）が格納
され,共通鍵認証の場合、：認証ＩＤが格納される。認
証不要の場合は格納は必須ではない。 * PMC:パーティションマネージャコード（Partition Ma
nager Code）として、パーティション定義ブロック（Pa
rtition Definition Block）に記述されるコード * PMC Version : パーティションマネージャコード（Ｐ
ＭＣ）のバージョン * Operation Type :パーティション（Partition）作成
か削除かの指定 (作成（Generate） / 削除（Delete)） * Partition Size :パーティション（Partition）のサ
イズ * Integrity Check Type :チケット（Ticket）の正当性
検証値の種別（公開鍵方式(Public) /共通鍵方式(Commo
n)） * Integrity Check Value :チケット（Ticket）の正当
性検証値（公開鍵方式：署名（Signature）、共通鍵方
式：ＭＡＣ）

【０１７９】なお、パーティション登録チケット（ＰＲ
Ｔ）発行手段（PRT Issuer）の発行したチケット（Tick
et）を、チケットユーザに対して送信する際には、公開
鍵方式の場合、パーティション登録チケット（ＰＲＴ）
発行手段（PRT Issuer）の公開鍵証明書（CERT_PRTI）
も一緒に送信する。ＰＲＴ発行手段の公開鍵証明書（CE
RT_PRTI）の属性（Attribute）は、ＰＲＴ発行手段（Ｐ
ＲＴ Issuer）の識別子(PRTIC)と一致する。

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

【０１８１】チケット（Ticket）の正当性検証値（公開
鍵方式：署名（Signature）、共通鍵方式：ＭＡＣ）を
記録する［Integrity Check Value］フィールドには、
公開鍵方式であれば、パーティション登録チケット発行
手段（ＰＲＴ Issuer）の秘密鍵に基づく署名（図１２
参照）が生成され格納される。デバイスマネージャ自体
がパーティション登録チケット発行手段（ＰＲＴ Issue
r）を兼ねる場合は、デバイスマネージャの秘密鍵を用
いて署名が生成される。署名検証処理（図１３参照）の
際は、対応のＣＡ（ＤＥＶ）の公開鍵が用いられる。従
って、チケット検証を実行するデバイスは、チケット受
領に際し、または前もってパーティション登録チケット
発行手段（ＰＲＴ Issuer）（ｅｘ．デバイスマネージ
ャ）の公開鍵（公開鍵証明書）を取得することが必要で
ある。

【０１８２】パーティション登録チケット（ＰＲＴ）発
行手段（PRT Issuer）の公開鍵証明書（CERT_PRTI）の
検証の後、公開鍵証明書（CERT_PRTI）から取り出した
パーティション登録チケット（ＰＲＴ）発行手段（PRT
Issuer）の公開鍵によりＩＣＶ（Integrity Check Valu
e）の署名検証が可能となる。これらの処理について
は、フローを用いて後段で説明する。

【０１８３】（Ａ８．２．ファイル登録チケット（ＦＲ
Ｔ））ファイル登録チケット（ＦＲＴ：File Registrat
ion Ticket）は、デバイスに対して設定されたパーティ
ションにファイルを設定登録する際に適用されるアクセ
スコントロールチケットである。正当なパーティション
マネージャ管轄下のチケット発行手段（Ticket Issue
r）の発行したＦＲＴを用い、ＦＲＴに記録された手続
きに従ってチケットユーザ（ｅｘ．デバイスアクセス機
器としてのリーダライタ）によりデバイスにアクセスす
ることで、ＦＲＴに記録された制限内でファイルを設定
することができる。

【０１８４】図２７にファイル登録チケット（ＦＲＴ：
File Registration Ticket）のデータフォーマットを示
す。ファイル登録チケット（ＦＲＴ：File Registratio
n Ticket）には以下に説明するデータが格納される。

【０１８５】* Ticket Type :チケット（Ticket）の種
別 * Format Version :チケット（Ticket）のフォーマット
バージョン * Ticket Issuer :パーティションマネージャの識別子
（＝ＰＭＣ） * 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］が公開鍵認証
の場合：識別名（ＤＮ：Distinguished Name）またはカ
テゴリ（Category）またはシリアル番号（ＣＮ）が格納
され,共通鍵認証の場合、：認証ＩＤが格納される。認
証不要の場合は格納は必須ではない。 * SPTIC :サービス許可チケット発行手段のコード * SPTIC Ver : サービス許可チケット発行手段のコード
（SPTIC）のバージョン * File ID :パーティション内に生成するファイル（Fil
e）の識別子（ＩＤ） * Operation Type :ファイルの作成か削除かの指定
(生成（Generate）/削除（Delete）) * File Size :生成するファイル（File）のサイズ * File Structure :生成するファイル（File）のファイ
ル構造（Structure） * Acceptable Authentication Type :このチケットで定
義されるファイルに対するアクセスモードを実行するタ
ために必要とする相互認証の種類（公開鍵方式、公開
鍵、共通鍵いずれでも可）を表すビット列 * Acceptable Verification Type :このチケットで定義
されるファイルに対するアクセスモードを実行するタた
めに必要とするサービス許可チケット（ＳＰＴ）の検証
の種類（公開鍵方式、公開鍵、共通鍵いずれでも可）を
表すビット列 * Kspt_Encrypted :ファイル定義ブロック（File Defin
ition Block）に記載されるサービス許可チケット（Ｓ
ＰＴ）のＭＡＣ検証用鍵 Kspt を そのパーティション
のファイル登録チケットのＭＡＣ検証用鍵 Kfrt で暗号
化したデータKfrt（Kspt） * Integrity Check Type :チケット（Ticket）の正当性
検証値の種別（公開鍵方式(Public) /共通鍵方式(Commo
n)） * Integrity Check Value :チケット（Ticket）の正当
性検証値（公開鍵方式：署名（Signature）、共通鍵方
式：ＭＡＣ）

【０１８６】なお、ファイル登録チケット（ＦＲＴ）発
行手段（FRT Issuer）の発行したチケット（Ticket）
を、チケットユーザに対して送信する際には、公開鍵方
式の場合、ファイル登録チケット（ＦＲＴ）発行手段
（FRT Issuer）の公開鍵証明書（CERT_FRTI）も一緒に
送信する。ＦＲＴ発行手段の公開鍵証明書（CERT_FRT
I）の属性（Attribute）は、ファイル登録チケット（Ｆ
ＲＴ）発行手段（ＦＲＴ Issuer）の識別子(FRTIC)と一
致する。

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

【０１８８】チケット（Ticket）の正当性検証値（公開
鍵方式：署名（Signature）、共通鍵方式：ＭＡＣ）を
記録する［Integrity Check Value］フィールドには、
公開鍵方式であれば、ファイル登録チケット発行手段
（ＦＲＴ Issuer）の秘密鍵に基づく署名（図１２参
照）が生成され格納される。パーティションマネージャ
自体がファイル登録チケット発行手段（ＦＲＴ issue
r）を兼ねる場合は、パーティションマネージャの秘密
鍵を用いて署名が生成される。署名検証処理（図１３参
照）の際は、ファイル登録チケット発行手段の公開鍵が
用いられる。従って、チケット検証を実行するデバイス
は、チケット受領に際し、または前もってファイル登録
チケット発行手段（ＦＲＴ Issuer）（ｅｘ．パーティ
ションマネージャ）の公開鍵（公開鍵証明書）を取得す
ることが必要である。

【０１８９】ファイル登録チケット（ＦＲＴ）発行手段
（FRT Issuer）の公開鍵証明書（CERT_FRTI）の検証の
後、公開鍵証明書（CERT_FRTI）から取り出したファイ
ル登録チケット（ＦＲＴ）発行手段（FRT Issuer）の公
開鍵によりＩＣＶ（IntegrityCheck Value）の署名検証
が可能となる。これらの処理については、フローを用い
て後段で説明する。

【０１９０】（Ａ８．３．サービス許可チケット（ＳＰ
Ｔ））サービス許可チケット（ＳＰＴ：Service Permis
sion Ticket）は、デバイスに対して設定されたパーテ
ィション内の各データに対してアクセスしてデータ読み
出し、データ書き込み、金額データの減算、加算などの
処理を実行する際に適用されるアクセスコントロールチ
ケットである。正当なパーティションマネージャ管轄下
のチケット発行手段（Ticket Issuer）の発行したＳＰ
Ｔを用い、ＳＰＴに記録された手続きに従ってチケット
ユーザ（ｅｘ．デバイスアクセス機器としてのリーダラ
イタ）によりデバイスにアクセスすることで、ＳＰＴに
記録された制限内でデータ処理を実行することができ
る。

【０１９１】なお、サービス許可チケット（ＳＰＴ：Se
rvice Permission Ticket）は、パーティションに設定
されたファイルの中から唯一のファイルに対してのみア
クセスを許可する形式と、複数のファイルに対するアク
セスを許可する形式とがあり、それぞれの形式について
説明する。

【０１９２】図２８に、パーティションに設定されたフ
ァイルの中から唯一のファイルに対してのみアクセスを
許可する形式のサービス許可チケット（ＳＰＴ：Servic
e Permission Ticket）のデータフォーマットを示す。
サービス許可チケット（ＳＰＴ：Service Permission T
icket）には以下に説明するデータが格納される。

【０１９３】* Ticket Type :チケット（Ticket）の種
別。 * Format Version :チケット（Ticket）のフォーマット
バージョン * Ticket Issuer :パーティションマネージャの識別子
（＝ＰＭＣ） * 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］が公開鍵認証
の場合：識別名（ＤＮ：Distinguished Name）またはカ
テゴリ（Category）またはシリアル番号（ＣＮ）が格納
され,共通鍵認証の場合、：認証ＩＤが格納される。認
証不要の場合は格納は必須ではない。 * File ID :パーティション内のアクセスファイル（Fil
e）の識別子（ＩＤ） * File Access Mode :アクセスを許諾するファイル（Fi
le）へのアクセスモード（Access Mode） * Integrity Check Type :チケット（Ticket）の正当性
検証値の種別（公開鍵方式(Public) /共通鍵方式(Commo
n)） * Integrity Check Value :チケット（Ticket）の正当
性検証値（公開鍵方式：署名（Signature）、共通鍵方
式：ＭＡＣ）

【０１９４】なお、サービス許可チケット（ＳＰＴ）発
行手段（SPT Issuer）の発行したチケット（Ticket）
を、チケットユーザに対して送信する際には、公開鍵方
式の場合、サービス許可チケット（ＳＰＴ）発行手段
（SPT Issuer）の公開鍵証明書（CERT_SPTI）も一緒に
送信する。ＳＰＴ発行手段の公開鍵証明書（CERT_SPT
I）の属性（Attribute）は、（ＳＰＴ）発行手段（SPT
Issuer）の識別子(SPTIC)と一致する。

【０１９５】サービス許可チケット（ＳＰＴ）発行手段
（SPT Issuer）を、パーティションマネージャが兼ねる
構成においては、サービス許可チケット（ＳＰＴ）発行
手段（SPT Issuer）のコードは、パーティションマネー
ジャコード（ＰＭＣ）として設定することが可能であ
る。

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

【０１９７】チケット（Ticket）の正当性検証値（公開
鍵方式：署名（Signature）、共通鍵方式：ＭＡＣ）を
記録する［Integrity Check Value］フィールドには、
公開鍵方式であれば、サービス許可チケット発行手段
（ＳＰＴ Issuer）の秘密鍵に基づく署名（図１２参
照）が生成され格納される。パーティションマネージャ
自体がサービス許可チケット発行手段（ＳＰＴ Issue
r）を兼ねる場合は、パーティションマネージャの秘密
鍵を用いて署名が生成される。署名検証処理（図１３参
照）の際は、サービス許可チケット（ＳＰＴ）発行手段
（SPT Issuer）の公開鍵が用いられる。従って、チケッ
ト検証を実行するデバイスは、チケット受領に際し、ま
たは前もってサービス許可チケット発行手段（ＳＰＴ I
ssuer）（ｅｘ．パーティションマネージャ）の公開鍵
（公開鍵証明書）を取得することが必要である。

【０１９８】サービス許可チケット（ＳＰＴ）発行手段
（SPT Issuer）の公開鍵証明書（CERT_SPTI）の検証の
後、公開鍵証明書（CERT_SPTI）から取り出したサービ
ス許可チケット（ＳＰＴ）発行手段（SPT Issuer）の公
開鍵によりＩＣＶ（IntegrityCheck Value）の署名検証
が可能となる。これらの処理については、フローを用い
て後段で説明する。

【０１９９】上述のチケット・フォーマットの説明中、
File Access Mode :アクセスを許諾するファイル（Fil
e）へのアクセスモード（Access Mode）に記録されるモ
ードとアクセス態様について、図２９を用いて説明す
る。

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

【０２０１】サービス許可チケット（ＳＰＴ）のFile A
ccess Modeには、このような様々なアクセスの態様中、
いずれのアクセスモードを許可しているものかを定義し
ている。アクセスモードの一覧を図２９に示す。図２９
に示すアクセスモードは一例であり、この他にもデバイ
スに格納されるデータに応じたアクセスモードを設定す
ることができる。

【０２０２】サービス許可チケット（ＳＰＴ）に設定さ
れた［File ID :パーティション内のアクセスファイル
（File）の識別子（ＩＤ）］によって示されるファイル
に対してファイルアクセスモード［File Access Mode］
に定義された処理が実行できる。サービス許可チケット
（ＳＰＴ）に設定されたファイルアクセスモードが読み
出し（Read）であればファイル内データの読み出しが実
行できる。サービス許可チケット（ＳＰＴ）に設定され
たファイルアクセスモードが書き込み（Write）であれ
ばファイル内へのデータの書き込みが実行できる。

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

【０２０４】図３０には、ファイル構造がＲａｎｄｏｍ
の場合と、複合ファイルの場合に設定可能なアクセスモ
ード、およびコマンド例を示している。

【０２０５】例えばファイル構造がＲａｎｄｏｍの場合
において、アクセスモードが読み出し（Ｒｅａｄ）であ
る場合、デバイスが許容可能なコマンドは［Ｒｅａｄ］
のみとなる。また、同様にファイル構造がＲａｎｄｏｍ
の場合において、アクセスモードが暗号化読み出し（Ｒ
ｅａｄ）である場合、デバイスが許容可能なコマンドは
暗号化読み出し［ＥｎｃＲｅａｄ］のみとなる。

【０２０６】また、ファイル構造がPurseおよびLogを含
むような複合ファイルの場合において、アクセスモード
が入金系である場合、デバイスが許容可能なコマンドは
預け入れ［Ｄｅｐｏｓｉｔ］のみとなる。また、同様に
ファイル構造がPurseおよびLogを含むような複合ファイ
ルの場合において、アクセスモードが出金系である場
合、デバイスが許容可能なコマンドは引き出し［Ｗｉｔ
ｈｄｒａｗ］、レシート生成［Ｍａｋｅ Ｒｅｃｅｉｐ
ｔ］、レシート読み出し［Ｒｅａｄ Ｒｅｃｅｉｐｔ］
となる。

【０２０７】ファイルアクセスモード（図２９参照）の
入金系に対応する許容コマンド（図３０参照）として、
上述の預け入れコマンド（Deposit Command）を定義
し、アクセス許可チケットのファイルアクセスモード
（File Access Mode）に［入金系］を設定し、ファイル
ＩＤ(File ID)として、電子マネーを構成する複合ファ
イルを指定したアクセス許可チケット（ＳＰＴ）を生成
して、ファイルアクセス装置からデバイスに対して送信
し、預け入れコマンド（Deposit Command）とともに、
預け入れ金額データを送信することにより、例えば、複
合ファイル中のファイル［Ｐｕｒｓｅ］にＸ円を加算
し、複合ファイル中のファイル［Ｌｏｇ］に処理記録を
書き込むなどのシーケンシャル処理を実行させることが
可能となる。これらの処理についての詳細は、後述す
る。

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

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

【０２１０】処理対象となる特定のファイルをサービス
許可チケット（ＳＰＴ）のファイルＩＤ(File ID)欄に
設定し、所定のアクセスモードをサービス許可チケット
（ＳＰＴ）のファイルアクセスモード（File Access Mo
de）に設定することで、当該サービス許可チケット（Ｓ
ＰＴ）を利用したファイルアクセスをコントロールする
ことが可能となる。具体的処理については、後段でフロ
ーを用いて説明する。

【０２１１】次に、図３１に、パーティションに設定さ
れたファイル中の複数ファイルに対してアクセスを許可
する形式のサービス許可チケット（ＳＰＴ：Service Pe
rmission Ticket）のデータフォーマットを示す。サー
ビス許可チケット（ＳＰＴ：Service Permission Ticke
t）には以下に説明するデータが格納される。

【０２１２】* Ticket Type :チケット（Ticket）の種
別。 * Format Version :チケット（Ticket）のフォーマット
バージョン * Ticket Issuer :パーティションマネージャの識別子
（＝ＰＭＣ） * 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］が公開鍵認証
の場合：識別名（ＤＮ：Distinguished Name）またはカ
テゴリ（Category）が格納され,共通鍵認証の場合、：
認証ＩＤが格納される。認証不要の場合は格納は必須で
はない。 * File ID :パーティション内のアクセスファイル（Fil
e）の識別子（ＩＤ） * File Access Mode :アクセスを許諾するファイル（Fi
le）へのアクセスモード（Access Mode） * Group of Target File :アクセスを許すファイル（Fi
le）のグループ（Group） * Target File ID :アクセスを許すファイル（File）の
識別子（ＩＤ） * Read/Write Permission : アクセスを許すファイル
（File）（ターゲットファイル（Target File））に対
する処理態様（読み出し（Read）,書き込み（Write））
の許可 * Integrity Check Type :チケット（Ticket）の正当性
検証値の種別（公開鍵方式(Public) /共通鍵方式(Commo
n)） * Integrity Check Value :チケット（Ticket）の正当
性検証値（公開鍵方式：署名（Signature）、共通鍵方
式：ＭＡＣ）

【０２１３】このように、Group of Target File :アク
セスを許すファイル（File）のグループ（Group）を定
義してチケットに記録することにより、パーティション
内の複数のファイルに対するアクセスを唯一のサービス
許可チケット（ＳＰＴ）で許可することが可能となる。

【０２１４】なお、上述のサービス許可チケット（ＳＰ
Ｔ）発行手段（SPT Issuer）の発行したチケット（Tick
et）を、チケットユーザに対して送信する際にも、公開
鍵方式の場合、サービス許可チケット（ＳＰＴ）発行手
段（SPT Issuer）の公開鍵証明書（CERT_SPTI）も一緒
に送信する。ＳＰＴ発行手段の公開鍵証明書（CERT_SPT
I）の属性（Attribute）は、サービス許可チケット（Ｓ
ＰＴ）発行手段（SPT Issuer）の識別子(SPTIC)と一致
する。

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

【０２１６】サービス許可チケット（ＳＰＴ）発行手段
（SPT Issuer）の公開鍵証明書（CERT_SPTI）の検証の
後、公開鍵証明書（CERT_SPTI）から取り出したサービ
ス許可チケット（ＳＰＴ）発行手段（SPT Issuer）の公
開鍵によりＩＣＶ（IntegrityCheck Value）の署名検証
が可能となる。これらの処理については、フローを用い
て後段で説明する。

【０２１７】（Ａ８．４．データアップデートチケット
（ＤＵＴ））データアップデートチケット（ＤＵＴ：Da
ta Update Ticket）は、デバイスに格納された様々なデ
ータに対してアクセスしてデータの更新処理を実行する
際に適用されるアクセスコントロールチケットである。
正当なデータアップデートチケット（ＤＵＴ）発行手段
（Ticket Issuer）の発行したＤＵＴを用い、ＤＵＴに
記録された手続きに従ってチケットユーザ（ｅｘ．デバ
イスアクセス機器としてのリーダライタ）によりデバイ
スにアクセスすることで、ＤＵＴに記録された制限内で
データ処理を実行することができる。

【０２１８】なお、データアップデートチケット（ＤＵ
Ｔ：Data Update Ticket）は、デバイスマネージャの管
理するデータ項目の更新処理を実行するために適用され
るチケットＤＵＴ（ＤＥＶ）と、パーティションマネー
ジャの管理するパーティション内のデータ項目の更新処
理を実行するために適用されるチケットＤＵＴ（ＰＡ
Ｒ）がある。チケット：ＤＵＴ（ＤＥＶ）発行手段はデ
バイスマネージャの管理下にあり、チケット：ＤＵＴ
（ＰＡＲ）発行手段はパーティションマネージャの管理
下にある。

【０２１９】図３２に、２つのデータアップデートチケ
ット（ＤＵＴ：Data Update Ticket）、ＤＵＴ（ＤＥ
Ｖ）、ＤＵＴ（ＰＡＲ）のデータフォーマットを示す。
データアップデートチケット（ＤＵＴ：Data Update Ti
cket）には以下に説明するデータが格納される。

【０２２０】* Ticket Type :チケット（Ticket）の種
別（ＤＵＴ（ＤＥＶ）／ＤＵＴ（ＰＡＲ） * Format Version :チケット（Ticket）のフォーマット
バージョン * Ticket Issuer :デバイス／パーティションマネージ
ャの識別子。チケット（Ticket）の種別（Ticket Typ
e）がＤＵＴ（ＤＥＶ）ならＤＭＣ、ＤＵＴ（ＰＡＲ）
ならＰＭＣとなる * Serial Number :チケット（Ticket）のシリアル番号 * Size of Ticket :チケット（Ticket）のサイズ * Ticket User の所属(Group) :チケット（Ticket）利
用者の所属 * Ticket User の識別子 :チケット（Ticket）利用者を
判別する識別データ（カテゴリまたは識別子） 当フィールドは、［Authentication Type］と連携した
データとされ、［Authentication Type］が公開鍵認証
の場合：識別名（ＤＮ：Distinguished Name）またはカ
テゴリ（Category）が格納され,共通鍵認証の場合、：
認証ＩＤが格納される。認証不要の場合は格納は必須で
はない。 * Authentication Type :デバイス（Device）の相互認
証のタイプ（公開鍵認証、または、共通鍵認証、また
は、いずれでも可（Any）） * Encrypted Flag :更新されるデータが暗号化されてい
るか否か (暗号化：Encrypted /非暗号化：none) * Old Data Code :更新される古いデータのコード（Cod
e） * Data Version Rule :データ更新をする時のバージョ
ン条件 * Data Version Condition :データ更新をする時のバー
ジョン値 * Size of New Data : 更新する新しいデータのサイズ * New Data : 更新する新しいデータ（暗号化される場
合もある）。 * New Data Version : 更新するデータのバージョン * Integrity Check Type :チケット（Ticket）の正当性
検証値の種別（公開鍵方式(Public) /共通鍵方式(Commo
n)） * Integrity Check Value :チケット（Ticket）の正当
性検証値（公開鍵方式：署名（Signature）、共通鍵方
式：ＭＡＣ）

【０２２１】データアップデートチケット（ＤＵＴ：Da
ta Update Ticket）を適用したデータ更新をする際に、
［Data Version Rule :データ更新をする時のバージョ
ン条件］と、［Data Version Condition :データ更新を
する時のバージョン値］、これら２つのフィールドの組
み合わせにより条件を表現する。

【０２２２】データ更新をする時のバージョン条件［Da
ta Version Rule］は、Any, Exact,Older の３種類が存
在する。Any はバージョン（Version）条件に無関係で
データ更新が可能、Exact は、続く［Data Version Con
dition ］に指定された値と同じ場合にデータ更新が可
能、Older は、New Data Version の方が新しい場合に
のみデータ更新が可能となる。なお、バージョン条件
［Data Version Rule］がAny,または Older の場合は、
［Data Version Condition］は使用しないかもしくは無
視する。

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

【０２２４】データアップデートチケット-ＤＵＴ（Ｄ
ＥＶ）発行手段（DUT Issuer）を、デバイスマネージャ
が兼ねる構成においては、データアップデートチケット
−ＤＵＴ（ＤＥＶ）発行手段（DUT Issuer）のコード
（チケットユーザ（Ticket User））は、デバイスマネ
ージャコード（ＤＭＣ）として設定することが可能であ
る。また、データアップデートチケット-ＤＵＴ（ＰＡ
Ｒ）発行手段（DUT Issuer）を、パーティションマネー
ジャが兼ねる構成においては、データアップデートチケ
ット−ＤＵＴ（ＰＡＲ）発行手段（DUT Issuer）のコー
ドは、パーティションマネージャコード（ＰＭＣ）とし
て設定することが可能である。

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

【０２２６】チケット（Ticket）の正当性検証値（公開
鍵方式：署名（Signature）、共通鍵方式：ＭＡＣ）を
記録する［Integrity Check Value］フィールドには、
公開鍵方式であれば、デバイスアップデートチケット発
行手段（ＤＵＴ Issuer）の秘密鍵に基づく署名（図１
２参照）が生成され格納される。デバイスマネージャ自
体がデバイスアップデート登録チケット発行手段（ＤＵ
Ｔ Issuer）を兼ねる場合は、デバイスマネージャの秘
密鍵を用いて署名が生成される。また、パーティション
マネージャ自体がデバイスアップデート登録チケット発
行手段（ＤＵＴIssuer）を兼ねる場合は、パーティショ
ンマネージャの秘密鍵を用いて署名が生成される。この
場合、署名検証処理（図１３参照）の際は、デバイスマ
ネージャまたはパーティションマネージャの公開鍵が用
いられる。従って、チケット検証を実行するデバイス
は、チケット受領に際し、または前もってデバイスアッ
プデートチケット発行手段（ＤＵＴ issuer）（ｅｘ．
デバイスマネージャまたはパーティションマネージャ）
の公開鍵（公開鍵証明書）を取得することが必要であ
る。

【０２２７】デバイスアップデートチケット（ＤＵＴ）
発行手段（DUT Issuer）の公開鍵証明書（CERT_DUTI）
の検証の後、公開鍵証明書（CERT_DUTI）から取り出し
たデータアップデートチケット（ＤＵＴ）発行手段（DU
T Issuer）の公開鍵によりＩＣＶ（Integrity Check Va
lue）の署名検証が可能となる。

【０２２８】データアップデートチケット（ＤＵＴ：Da
ta Update Ticket）を適用して更新されるデータ例を図
３３に示す。

【０２２９】図３３に示すように更新対象データには、
デバイスマネージャコード、デバイスマネージャコード
バージョン、パーティションマネージャコード、パーテ
ィションマネージャコードバージョン、各チケット発行
手段コード、各チケットのＭＡＣ生成鍵およびバージョ
ン、リボケーションリストなどが含まれる。これら更新
対象の各データがデータアップデートチケット（ＤＵ
Ｔ：Data Update Ticket）を適用して、ＤＵＴに記録さ
れたルールに従って更新される。更新処理の具体的手順
については、後段でフローを用いて説明する。なお、デ
バイスマネージャコードバージョン、パーティションマ
ネージャコードバージョン他のバージョン情報は、各バ
ージョンの付加されたデータの更新処理の際に併せて更
新されることになる。これらのバージョン情報はデータ
アップデートチケット（ＤＵＴ：Data Update Ticket）
に格納される。

【０２３０】［Ｂ．ユーザに対するデバイスの配布、デ
バイスに対する各種設定、デバイス利用処理の詳細につ
いての説明］次に、上述したパーティション分割された
メモリ領域を持つデバイスの利用に至るまでの処理、さ
らにデバイスの利用処理の詳細についてフローチャート
他の図面を参照しながら説明する。説明の手順は以下の
項目に従って行なう。

【０２３１】Ｂ１．デバイス初期登録から利用までの流
れ Ｂ２．デバイス製造エンティテイによる初期登録処理 Ｂ３．デバイスマネージャの管轄処理 Ｂ３．１．デバイスマネージャによるデバイス登録処理 Ｂ３．２．デバイスマネージャ管理下における公開鍵証
明書発行処理 Ｂ４．パーティションマネージャの管轄処理 Ｂ４．１．パーティションマネージャ管理下におけるパ
ーティション登録チケット（ＰＲＴ）を利用したパーテ
ィション設定登録、削除処理 Ｂ４．２．パーティションマネージャ管理下における公
開鍵証明書発行処理 Ｂ４．３．ファイル登録チケット（ＦＲＴ）を利用した
ファイル生成、消去処理 Ｂ５．サービス許可チケット（ＳＰＴ）を利用したサー
ビス（ファイルアクセス）処理 Ｂ６．データアップデートチケット（ＤＵＴ）を利用し
たデバイスのデータ更新処理

【０２３２】［Ｂ１．デバイス初期登録から利用までの
流れ］ＥＥＰＲＯＭ（フラッシュメモリ）を有するデバ
イスは、デバイス製造エンティテイ（manufacturer）に
よって製造され、デバイスマネージャによる初期データ
の書き込みが実行され、ユーザに提供（ｅｘ．販売、貸
与）され利用されることになる。ユーザが様々なサービ
ス主体からデバイスを利用したサービスを受けるために
は、デバイスのメモリ部にパーティションマネージャに
よるパーティションが設定され、設定されたパーティシ
ョン内にサービス提供用のデータを格納したファイルが
設定される必要がある。

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

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

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

【０２３６】１．まず、デバイスは製造エンティテイ
（manufacturer）によって製造される。デバイスの製造
時には、各デバイスの識別データ（ＩＤ）としてのデバ
イスコードが各デバイスに付与される。デバイスには製
造段階で、デバイスコード、製造コードなど、様々の製
造情報（Manufacture Information Block（図１４参
照））が書き込まれデバイスのメモリに格納される。

【０２３７】２．次に、デバイスマネージャはユーザに
対するデバイスの提供前に、自己のＩＤ、認証局の公開
鍵（ＰＵＢ ＣＡ（ＤＥＶ））など、デバイス管理情報
（Device Management Information(図１５参照)）、デ
バイス鍵（Device Key（図１８参照））などの情報をメ
モリに格納する。

【０２３８】３．デバイスマネージャによる管理情報が
書き込まれたデバイスは、ユーザに提供される。

【０２３９】４．次にユーザは、デバイス対応の公開鍵
証明書の取得処理を実行し、取得したデバイス対応公開
鍵証明書（ＣＥＲＴ ＤＥＶ）をデバイスのデバイス鍵
領域（図１８参照）に格納する。

【０２４０】５．デバイスのメモリ部にパーティション
を設定し、サービスを提供しようとするサービス主体
（パーティションマネージャ）は、パーティションの設
定をデバイスマネージャに要求し、許諾を受けるととも
にパーティション登録チケット（ＰＲＴ）を受領する。
また、デバイスとの通信処理において使用する認証局の
公開鍵（ＰＵＢ ＣＡ（ＰＡＲ））を指定する。

【０２４１】６．デバイスは、パーティションマネージ
ャの管理するチケットユーザ（ｅｘ．デバイスアクセス
機器としてのリーダライタ）との間で通信を実行し、パ
ーティション登録チケット（ＰＲＴ）を適用したパーテ
ィションの登録処理を行なうとともに、認証局の公開鍵
（ＰＵＢ ＣＡ（ＰＡＲ））をパーティション鍵領域
（図２３参照）格納する。

【０２４２】７．パーティションの設定されたデバイス
は、パーティション対応公開鍵証明書の発行要求をパー
ティションマネージャに送信し、取得したパーティショ
ン対応公開鍵証明書（ＣＥＲＴ ＰＡＲ）をパーティシ
ョン鍵領域（図２３参照）に格納する。

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

【０２４４】８．次に、パーティションマネージャは、
デバイスに設定したパーティション内に、例えばサービ
ス対応のファイルの設定登録処理をファイル登録チケッ
ト（ＦＲＴ）を適用して実行する。

【０２４５】９．１０．設定されたパーティション内に
ファイルが登録されることにより、例えば電子マネー、
定期券などファイル内データによって定義される各種の
サービスが実行可能となる。ファイル内のデータ読み取
り、データ書き込みなどの処理には、サービス許可チケ
ット（ＳＰＴ）を適用する。すなわち正当なチケット発
行手段が発行したサービス許可チケット（ＳＰＴ）を適
用した場合に限り、ＳＰＴに記録されたルールに従って
データの読み取り、書き込みなどが実行される。

【０２４６】また、図には示されていないが、必要に応
じてデータアップデートチケット（ＤＵＴ）を使用して
デバイスの格納データ中の更新処理対象データ（ｅｘ．
デバイスマネージャコード、デバイスマネージャコード
バージョン、パーティションマネージャコード、パーテ
ィションマネージャコードバージョン、各チケット発行
手段コード、各チケットのＭＡＣ生成鍵およびバージョ
ン、リボケーションリストなど）の更新処理が実行され
る。なお、デバイスマネージャコードバージョン、パー
ティションマネージャコードバージョン他のバージョン
情報は、各バージョンの付加されたデータの更新処理の
際に併せて更新されることになる。これらのバージョン
情報はデータアップデートチケット（ＤＵＴ：Data Upd
ate Ticket）に格納される。

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

【０２４８】［Ｂ２．デバイス製造エンティテイによる
初期登録処理］まず、デバイス製造エンティテイによる
初期登録処理について、図３５を用いて説明する。図３
５の左側がデバイス製造エンティテイ(Manufacture)の
登録装置の処理、右側がデバイス（図５参照）の処理を
示す。なお、デバイス製造エンティテイ(Manufacture)
の登録装置は、デバイスに対するデータ読み取り書き込
み処理可能な専用のデバイスアクセス機器としてのリー
ダライタ（図１０参照）として構成される。

【０２４９】まず、ステップＳ１０１において登録装置
は、デバイスに対して製造情報ブロック（ＭＩＢ：Manu
facture Information Block（図１４参照））の書き込
みフラグ（Writable Flag）の読み出しコマンドを送信
する。デバイスはコマンドを受信（Ｓ１２１）すると、
デバイスのメモリ部の製造情報ブロック（ＭＩＢ）内の
書き込み（Writable）フラグを登録装置に送信（Ｓ１２
２）する。

【０２５０】製造情報ブロック（ＭＩＢ）内の書き込み
（Writable）フラグを受信（Ｓ１０２）した登録装置
は、書き込みフラグ（Writable Flag）が書き込み可
（０ｘｆｆｆｆ）に設定されているか否かを判別（Ｓ１
０３）する。書き込みフラグ（Writable Flag）が書き
込み可（０ｘｆｆｆｆ）に設定されていない場合は、以
下の製造情報ブロック（ＭＩＢ：Manufacture Informat
ion Block）の書き込み処理は実行できず、エラーとし
て終了する。

【０２５１】書き込みフラグ（Writable Flag）が書き
込み可（０ｘｆｆｆｆ）に設定されている場合は、デバ
イスの製造情報ブロック（ＭＩＢ：Manufacture Inform
ation Block（図１４参照））を生成（Ｓ１０４）して
ＭＩＢ書き込みコマンドとともに、ＭＩＢデータをデバ
イスに送信（Ｓ１０５）する。

【０２５２】ＭＩＢ書き込みコマンド、およびＭＩＢデ
ータを受信（Ｓ１２３）したデバイスは、ＭＩＢ書き込
みフラグ（Writable Flag）を検証（Ｓ１２４）し、書
き込みフラグ（Writable Flag）が書き込み可（０ｘｆ
ｆｆｆ）に設定されていない場合は、以下の製造情報ブ
ロック（ＭＩＢ：Manufacture Information Block）の
書き込み処理は実行できず、エラーとして終了する。書
き込みフラグ（Writable Flag）が書き込み可（０ｘｆ
ｆｆｆ）に設定されている場合は、受信したＭＩＢデー
タをＭＩＢ領域に書き込む（Ｓ１２５）。

【０２５３】ＭＩＢデータ書き込み処理が終了すると書
き込み終了通知を登録装置に送信（Ｓ１２６）する。書
き込み終了通知を受信（Ｓ１０６）した登録装置は初期
登録完了コマンドをデバイスに送信（Ｓ１０７）し、初
期登録完了コマンドを受信（Ｓ１２７）したデバイスは
製造情報ブロック（ＭＩＢ：Manufacture Information
Block）の書き込みフラグ（Writable Flag）を書き込み
不可（０ｘ００００）にセット（Ｓ１２８）し、書き込
み終了通知を登録装置に送信（Ｓ１２９）する。

【０２５４】書き込み終了通知を受信（Ｓ１０８）した
登録装置は、デバイスに対して製造情報ブロック（ＭＩ
Ｂ：Manufacture Information Block（図１４参照））
の書き込みフラグ（Writable Flag）の読み出しコマン
ドを送信（Ｓ１０９）する。デバイスはコマンドを受信
（Ｓ１３０）すると、デバイスのメモリ部の製造情報ブ
ロック（ＭＩＢ）内の書き込みフラグ（Writable Fla
g）を登録装置に送信（Ｓ１３１）する。

【０２５５】製造情報ブロック（ＭＩＢ）内の書き込み
フラグ（Writable Flag）を受信（Ｓ１１０）した登録
装置は、書き込みフラグ（Writable Flag）が書き込み
不可（０ｘ００００）に設定されているか否かを判別
（Ｓ１１１）する。書き込みフラグ（Writable Flag）
が書き込み不可（０ｘ００００）に設定されていない場
合は、正常なＭＩＢデータ書き込み処理が終了していな
いことを示し、エラーとして処理を終了する。書き込み
フラグ（Writable Flag）が書き込み不可（０ｘ０００
０）に設定されている場合は、正常なＭＩＢデータ書き
込み処理が終了したものとして処理を終了する。

【０２５６】［Ｂ３．デバイスマネージャの管轄処理］
次に、デバイスマネージャの管轄処理について説明す
る。ここでは、デバイスの使用開始以前に実行される処
理について説明する。デバイスの使用開始以前に実行さ
れるデバイスマネージャの処理としては、デバイスのメ
モリ部のデバイス管理情報ブロック（ＤＭＩＢ：Device
Management Information Block）、公開鍵系デバイス
キー定義ブロック（ＤＫＤＢ：Device Key Definition
Block(PUB)）、共通鍵系デバイスキー定義ブロック（Ｄ
ＫＤＢ：Device Key Definition Block(Common)）、デ
バイス鍵領域（Device Key Area）に対するデータ書き
込み処理として実行するデバイス登録処理と、デバイス
に対してデバイス対応公開鍵証明書（ＣＥＲＴ ＤＥ
Ｖ）を発行する処理がある。以下、これらの処理の詳細
について説明する。

【０２５７】［Ｂ３．１．デバイスマネージャによるデ
バイス登録処理］図３６以下のフローを用いて、デバイ
スマネージャによるデバイスに対するデバイス管理情報
他の格納処理を伴う初期登録処理について説明する。図
３６以下のフローにおいて、左側がデバイスマネージャ
（ＤＭ）の初期登録装置の処理、右側がデバイス（図５
参照）の処理を示す。なお、デバイスマネージャ（Ｄ
Ｍ）の初期登録装置は、デバイスに対するデータ読み取
り書き込み処理可能な装置（ｅｘ．デバイスアクセス機
器としてのリーダライタ、ＰＣ）であり、図１０のデバ
イスアクセス機器としてのリーダライタに相当する構成
を有する。

【０２５８】まず、ステップＳ２０１において、デバイ
スの識別子ＩＤｍの読み出し（Read)コマンドをデバイ
スに出力する。デバイスはコマンドを受信（Ｓ２１１）
し、デバイスの識別子ＩＤｍを登録装置に送信（Ｓ２１
２）する。

【０２５９】デバイスの識別子ＩＤｍを受信（Ｓ２０
２）した登録装置は、ステップＳ２０３において、デバ
イスに対してデバイス管理情報ブロック（ＤＭＩＢ：De
vice Management Information Block（図１５参照））
の書き込みフラグ（Writable Flag）の読み出しコマン
ドを送信する。デバイスはコマンドを受信（Ｓ２１３）
すると、デバイスのメモリ部のデバイス管理情報ブロッ
ク（ＤＭＩＢ）内の書き込みフラグ（Writable Flag）
を登録装置に送信（Ｓ２１４）する。

【０２６０】デバイス管理情報ブロック（ＤＭＩＢ）内
の書き込みフラグ（Writable Flag）を受信（Ｓ２０
４）した登録装置は、書き込みフラグ（Writable Fla
g）が書き込み可（０ｘｆｆｆｆ）に設定されているか
否かを判別（Ｓ２０５）する。書き込みフラグ（Writab
le Flag）が書き込み可（０ｘｆｆｆｆ）に設定されて
いない場合は、以下のデバイス管理情報ブロック（ＤＭ
ＩＢ：Device ManagementInformation Block）の書き込
み処理は実行できず、エラーとして終了する。

【０２６１】書き込みフラグ（Writable Flag）が書き
込み可（０ｘｆｆｆｆ）に設定されている場合は、デバ
イスマネージャコード（ＤＭＣ）およびＤＭＣバージョ
ンの書き込み（ＤＭＣ Write）コマンドをデバイスに送
信（Ｓ２０６）する。このコードは、コード管理機関
（図１〜図３参照）によりデバイスマネージャに対して
予め割り当てられたデータである。

【０２６２】ＤＭＣ Writeコマンドを受信（Ｓ２１５）
したデバイスは、ＤＭＩＢ書き込みフラグ（Writable F
lag）を検証（Ｓ２１６）し、書き込みフラグ（Writabl
e Flag）が書き込み可（０ｘｆｆｆｆ）に設定されてい
ない場合は、以下のデバイス管理情報ブロック（ＤＭＩ
Ｂ：Device Management Information Block）の書き込
み処理は実行できず、エラーとして終了する。書き込み
フラグ（Writable Flag）が書き込み可（０ｘｆｆｆ
ｆ）に設定されている場合は、受信したデバイスマネー
ジャコード（ＤＭＣ）およびＤＭＣバージョンをＤＭＩ
Ｂ領域に書き込む（Ｓ２１７）。

【０２６３】デバイスマネージャコード（ＤＭＣ）およ
びＤＭＣバージョンの書き込み処理が終了すると書き込
み終了通知を登録装置に送信（Ｓ２１８）する。書き込
み終了通知を受信（Ｓ２０７）した登録装置は、次にデ
バイス総ブロック数（DeviceTotal Block Number）書き
込みコマンドをデバイスに送信（Ｓ２０８）する。

【０２６４】デバイス総ブロック数（Device Total Blo
ck Number）書き込みコマンドを受信（Ｓ２１９）した
デバイスは、ＤＭＩＢ書き込みフラグ（Writable Fla
g）を検証（Ｓ２２０）し、書き込みフラグ（Writable
Flag）が書き込み可（０ｘｆｆｆｆ）に設定されていな
い場合は、以下のデバイス管理情報ブロック（ＤＭＩ
Ｂ：Device Management Information Block）の書き込
み処理は実行できず、エラーとして終了する。書き込み
フラグ（Writable Flag）が書き込み可（０ｘｆｆｆ
ｆ）に設定されている場合は、受信したデバイス総ブロ
ック数（Device Total Block Number）をＤＭＩＢ領域
に書き込む（Ｓ２２１）。さらに、デバイスは、ＤＭＩ
Ｂ領域のデバイス空きブロック数情報領域（Free Block
Number in Device）にＴＢ−４を書き込む（Ｓ２２
２）。ＴＢはデバイス総ブロック数（Device Total Blo
ck Number）を意味する。なおＴＢ−４の４ブロック
は、製造情報ブロック（ＭＩＢ：Manufacture Informat
ion Block）、デバイス管理情報ブロック（ＤＭＩＢ：D
evice Management Information Block)、公開鍵系デバ
イスキー定義ブロック（ＤＫＤＢ：Device Key Definit
ion Block(PUB)）、共通鍵系デバイスキー定義ブロック
（ＤＫＤＢ：Device Key Definition Block(Common)）
を示している。

【０２６５】次に、デバイスは、デバイス管理情報ブロ
ック（ＤＭＩＢ）のパーティション数（Partition Numb
er）領域に０を書き込む（Ｓ２２３）。この時点でデバ
イスにはパーティションは設定されていないからであ
る。さらにＤＭＩＢの空き領域のポインタ（Pointer of
Free Area）に０を書き込み（Ｓ２２４）、書き込み処
理完了を登録装置に送信（Ｓ２２５）する。

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

【０２６７】図３７に示すように、デバイス認証に共通
鍵を用いる場合、ステップＳ２３２〜Ｓ２３３、Ｓ２４
１〜Ｓ２４５を実行し、デバイス認証に共通鍵を用いな
い場合、これらのステップは省略される。

【０２６８】デバイス認証に共通鍵を用いる場合、ステ
ップＳ２３２において登録装置は、共通鍵認証データ書
き込みコマンドとして、MKauth＿DEV_A :双方向個別鍵
認証用マスター鍵、Kauth＿DEV_B :双方向個別鍵認証用
共通鍵、IRL_DEV :排除デバイス（Device）のデバイス
識別子（ＩＤ）を登録したリボケーションリスト（Revo
cation List (Device ID)、およびこれらのバージョン
情報をデバイスに送信する。

【０２６９】ステップＳ２４１でデバイスは、上述の書
き込みコマンドを受信し、ステップＳ２４２において、
ＤＭＩＢの書き込みフラグ（Writable Flag）が書き込
み可であることを確認して受領データをデバイス鍵領域
（図１８参照）に書き込む（Ｓ２４３）。次にデータ書
き込みによって生じたポインタ、サイズ、デバイス内の
フリーブロック数の調整を実行（Ｓ２４４）し、書き込
み終了通知を登録装置に送信（Ｓ２４５）する。

【０２７０】書き込み終了通知を受信（Ｓ２３３）した
登録装置は、ステップＳ２３４においてデバイス認証に
公開鍵を用いるか否かを判定する。図３７に示すよう
に、デバイス認証に公開鍵を用いる場合、ステップＳ２
３５〜Ｓ２３９、Ｓ２４６〜Ｓ２５４を実行し、デバイ
ス認証に公開鍵を用いない場合、これらのステップは省
略される。

【０２７１】デバイス認証に公開鍵を用いる場合、ステ
ップＳ２３５において登録装置は、公開鍵認証データ書
き込みコマンドとして、PUB_CA(DEV) :デバイスマネー
ジャ対応公開鍵を発行する認証局ＣＡ（ＤＥＶ）の公開
鍵、PARAM_DEV :デバイス（Device）の公開鍵パラメー
タ、CRL_DEV :排除デバイス（Device）の公開鍵証明書
識別子（ｅｘ．シリアルナンバ：ＳＮ）を登録したリボ
ケーションリスト（Revocation List (Certificate)、
およびこれらのバージョン情報をデバイスに送信する。

【０２７２】ステップＳ２４６でデバイスは、上述の書
き込みコマンドを受信し、ステップＳ２４７において、
ＤＭＩＢの書き込みフラグ（Writable Flag）が書き込
み可であることを確認して受領データをデバイス鍵領域
（図１８参照）に書き込む（Ｓ２４８）。次にデータ書
き込みによって生じたポインタ、サイズ、デバイス内の
フリーブロック数の調整を実行（Ｓ２４９）し、書き込
み終了通知を登録装置に送信（Ｓ２５０）する。

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

【０２７４】鍵ペア生成コマンドを受信（Ｓ２５１）し
たデバイスは、デバイス内の暗号処理部（図５参照）に
おいて公開鍵（ＰＵＢ ＤＥＶ）と秘密鍵（ＰＲＩ ＤＥ
Ｖ）のペアを生成し、生成した鍵をデバイス鍵領域（図
１８参照）に書き込む（Ｓ２５２）。なお、公開鍵（Ｐ
ＵＢ ＤＥＶ）については、デバイス鍵領域のＣＥＲＴ
・ＤＥＶ領域に一時格納し、その後、公開鍵（ＰＵＢ
ＤＥＶ）を格納した公開鍵証明書を受領した時点で公開
鍵証明書（ＣＥＲＴ）に置き換えられる。次にデータ書
き込みによって生じたポインタ、サイズ、デバイス内の
フリーブロック数の調整を実行（Ｓ２５３）し、生成格
納した公開鍵を登録装置に送信（Ｓ２５４）する。

【０２７５】登録装置は、デバイスから公開鍵（ＰＵＢ
ＤＥＶ）を受信し、先にデバイスから受信したデバイ
スの識別子ＩＤｍとともに、デバイスマネージャ内のデ
ータベース（ＤＢ（ＤＥＶ）（図７参照））に保存す
る。

【０２７６】次に、デバイスマネージャの登録装置は、
パーティション登録チケット（ＰＲＴ：Partition Regi
stration Ticket）の検証処理に共通鍵を用いるか否か
を判定（Ｓ２６１）する。チケット検証には、後段で詳
細に説明するがＭＡＣ値検証等による共通鍵方式と、前
述の図１２、図１３を用いて説明した秘密鍵による署名
生成、公開鍵による署名検証を行なう公開鍵方式のいず
れかを適用することが可能であり、デバイスマネージャ
は、デバイスの採用する検証処理方式を設定することが
できる。デバイスマネージャは、デバイスの採用するＰ
ＲＴチケット検証方式に応じて共通鍵、公開鍵のいずれ
か、あるいは両方式を実行可能なデータをデバイスに設
定する。

【０２７７】デバイスマネージャは、デバイスが共通鍵
認証を実行するデバイスであれば、デバイスマネージャ
は共通鍵方式のＰＲＴ検証に必要な情報（ｅｘ．ＰＲＴ
検証共通鍵）をデバイスにセットし、デバイスが共通鍵
認証を実行しないデバイスであれば、これらの情報をデ
バイスに格納しないことになる。

【０２７８】図３８に示すように、ＰＲＴ検証に共通鍵
方式を用いる場合、ステップＳ２６２〜２６３、Ｓ２７
１〜Ｓ２７５を実行し、ＰＲＴ検証に共通鍵を用いない
場合、これらのステップは省略される。

【０２７９】ＰＲＴ検証に共通鍵を用いる場合、ステッ
プＳ２６２において登録装置は、ＰＲＴ検証共通鍵書き
込みコマンドとして、Kprt :パーティション登録チケッ
ト（ＰＲＴ）のＭＡＣ検証用鍵、およびバージョン情報
をデバイスに送信する。

【０２８０】ステップＳ２７１でデバイスは、上述の書
き込みコマンドを受信し、ステップＳ２７２において、
ＤＭＩＢの書き込みフラグ（Writable Flag）が書き込
み可であることを確認して受領データをデバイス鍵領域
（図１８参照）に書き込む（Ｓ２７３）。次にデータ書
き込みによって生じたポインタ、サイズ、デバイス内の
フリーブロック数の調整を実行（Ｓ２７４）し、書き込
み終了通知を登録装置に送信（Ｓ２７５）する。

【０２８１】書き込み終了通知を受信（Ｓ２６３）した
登録装置は、ステップＳ２６４においてＰＲＴ検証に公
開鍵を用いるか否かを判定する。図３８に示すように、
ＰＲＴ検証に公開鍵を用いる場合、ステップＳ２６５〜
Ｓ２６６、Ｓ２７６〜Ｓ２８２を実行し、ＰＲＴ検証に
公開鍵を用いない場合、これらのステップは省略され
る。

【０２８２】ＰＲＴ検証に公開鍵を用いる場合、ステッ
プＳ２６５において登録装置は、ＰＲＴ検証データ書き
込みコマンドとして、PRTIC（PRT Issuer Category) :
パーティション登録チケット（ＰＲＴ）発行者カテゴ
リ、PUB_CA(DEV) :デバイスマネージャ対応公開鍵を発
行する認証局ＣＡ（ＤＥＶ）の公開鍵、PARAM_DEV :デ
バイス（Device）の公開鍵パラメータ、CRL_DEV :排除
デバイス（Device）の公開鍵証明書識別子（ｅｘ．シリ
アルナンバ：ＳＮ）を登録したリボケーションリスト
（Revocation List (Certificate)、およびこれらのバ
ージョン情報をデバイスに送信する。

【０２８３】ステップＳ２７６でデバイスは、上述の書
き込みコマンドを受信し、ステップＳ２７７において、
ＤＭＩＢの書き込みフラグ（Writable Flag）が書き込
み可であることを確認して、ステップＳ２７８におい
て、受領データ中のPRTIC（PRTIssuer Category) :パー
ティション登録チケット（ＰＲＴ）発行者カテゴリを公
開鍵系デバイス鍵定義ブロック（ＤＫＤＢ：Device Key
Definition block（PUB）（図１６参照））に書き込み
バージョン情報を同ブロックのバージョン領域に書き込
む。

【０２８４】次にデバイスは、ステップＳ２７９におい
て、PUB_CA(DEV) :デバイスマネージャ対応公開鍵を発
行する認証局ＣＡ（ＤＥＶ）の公開鍵データが書き込み
済みか否かを判定し、書き込まれていない場合にステッ
プＳ２８０において、PUB_CA(DEV)、PARAM_DEV、CRL_DE
Vをデバイス鍵領域（図１８参照）に書き込む。次にデ
ータ書き込みによって生じたポインタ、サイズ、デバイ
ス内のフリーブロック数の調整を実行（Ｓ２８１）し、
書き込み終了通知を登録装置に送信（Ｓ２８２）する。

【０２８５】書き込み終了通知を受信（Ｓ２６６）した
登録装置は、次に、ステップＳ２９１において、共通鍵
データの更新をサポートするデバイスであるか否かを判
定する。デバイスに格納されたデータ中、そのいくつか
は更新対象データとして前述したデータアップデートチ
ケット（ＤＵＴ：Data Update Ticket）（図３２参照）
を用いて更新が可能である。更新対象となるデータは、
先に図３３を用いて説明した通りである。このデータア
ップデートチケット（ＤＵＴ：Data Update Ticket）を
用いた更新処理においても共通鍵方式、または公開鍵方
式のいずれかの方式が可能であり、デバイスマネージャ
はデバイスに応じていずれかの方式または両方式を実行
可能なデータをデバイスに設定する。

【０２８６】デバイスマネージャは、デバイスが共通鍵
方式によるデータ更新を実行するデバイスであれば、共
通鍵方式のデータ更新処理に必要な情報（ｅｘ．データ
アップデートチケット（ＤＵＴ）のＭＡＣ検証用鍵他）
をデバイスにセットし、デバイスが共通鍵認証を実行し
ないデバイスであれば、これらの情報をデバイスに格納
しないことになる。

【０２８７】図３９に示すように、データアップデート
チケット（ＤＵＴ：Data Update Ticket）を用いたデー
タ更新処理に共通鍵方式を用いる場合、ステップＳ２９
２〜Ｓ２９３、Ｓ３０１〜Ｓ３０５を実行し、データ更
新に共通鍵方式を用いない場合、これらのステップは省
略される。

【０２８８】データ更新に共通鍵を用いる場合、ステッ
プＳ２９２において登録装置は、データアップデートチ
ケット（ＤＵＴ：Data Update Ticket）検証共通鍵書き
込みコマンドとして、Kdut_DEV1 :データアップデート
チケット（ＤＵＴ）のＭＡＣ検証用鍵、 Kdut_DEV2 :デ
ータ更新用暗号鍵、Kdut_DEV3 :データアップデートチ
ケット（ＤＵＴ）のＭＡＣ検証用鍵、Kdut_DEV4 :デー
タ更新用暗号鍵およびこれらのバージョン情報をデバイ
スに送信する。

【０２８９】ステップＳ３０１でデバイスは、上述の書
き込みコマンドを受信し、ステップＳ３０２において、
ＤＭＩＢの書き込みフラグ（Writable Flag）が書き込
み可であることを確認して受領データをデバイス鍵領域
（図１８参照）に書き込む（Ｓ３０３）。次にデータ書
き込みによって生じたポインタ、サイズ、デバイス内の
フリーブロック数の調整を実行（Ｓ３０４）し、書き込
み終了通知を登録装置に送信（Ｓ３０５）する。

【０２９０】書き込み終了通知を受信（Ｓ２９３）した
登録装置は、ステップＳ２９４において、デバイスが公
開鍵方式を用いたデータアップデートチケット（ＤＵ
Ｔ：Data Update Ticket）を使用したデータ更新処理を
サポートするか否かを判定する。図３９に示すように、
公開鍵方式をサポートする場合、ステップＳ２９５〜Ｓ
２９６、Ｓ３０６〜Ｓ３１０を実行し、公開鍵方式をサ
ポートしない場合、これらのステップは省略される。

【０２９１】公開鍵方式をサポートする場合、ステップ
Ｓ２９５において登録装置は、データアップデートチケ
ット（ＤＵＴ：Data Update Ticket）発行者コード書き
込みコマンドとして、DUTIC_DEV（DUT Issuer Categor
y) :データアップデートチケット（ＤＵＴ：Data Updat
e Ticket）発行者カテゴリ、およびバージョン情報をデ
バイスに送信する。

【０２９２】ステップＳ３０６でデバイスは、上述の書
き込みコマンドを受信し、ステップＳ３０７において、
ＤＭＩＢの書き込みフラグ（Writable Flag）が書き込
み可であることを確認して、ステップＳ３０８におい
て、受領データを公開鍵系デバイス鍵定義ブロック（Ｄ
ＫＤＢ（ＰＵＢ）：Device Key Definition Block(PU
B)）に書き込む（Ｓ３０８）。次にデータ書き込みによ
って生じたポインタ、サイズ、デバイス内のフリーブロ
ック数の調整を実行（Ｓ３０９）し、書き込み終了通知
を登録装置に送信（Ｓ３１０）する。

【０２９３】書き込み終了通知を受信（Ｓ２９６）した
登録装置は、次にステップＳ３２１において、デバイス
マネージャ（ＤＭ）初期登録完了コマンドをデバイスに
対して送信する。コマンドを受領（Ｓ３３１）したデバ
イスは、ステップＳ３３２において、相互認証、パーテ
ィション登録チケット（ＰＲＴ）の検証、さらにデータ
アップデートチケット（ＤＵＴ）の検証、それぞれにつ
いて少なくとも公開鍵方式、共通鍵方式のいずれかの処
理が実行可能なデータが設定済みであるか否かを判定す
る。これらのデータに不足がある場合は、いずれかの処
理が実行できないことになり、デバイスマネージャによ
る初期登録はエラーと判定され処理を終了する。

【０２９４】ステップＳ３３２において、相互認証、パ
ーティション登録チケット（ＰＲＴ）の検証、さらにデ
ータアップデートチケット（ＤＵＴ）の検証、それぞれ
について少なくとも公開鍵方式、共通鍵方式のいずれか
の処理が実行可能なデータが設定済みであると判定した
場合は、ステップＳ３３３においてデバイスは、デバイ
ス管理情報ブロック（ＤＭＩＢ：Device Management In
formation Block）の書き込み（Writable）フラグを書
き込み不可（０ｘ００００）にセットし、書き込み終了
通知を登録装置に送信(Ｓ３３４)する。

【０２９５】書き込み終了通知を受信（Ｓ３２２）した
登録装置は、デバイスに対してデバイス管理情報ブロッ
ク（ＤＭＩＢ：Device Management Information Bloc
k）（図１５参照））の書き込みフラグ（Writable Fla
g）の読み出しコマンドを送信（Ｓ３２３）する。デバ
イスはコマンドを受信（Ｓ３３５）すると、デバイスの
メモリ部のデバイス管理情報ブロック（ＤＭＩＢ）内の
書き込みフラグ（Writable Flag）を登録装置に送信
（Ｓ３３６）する。

【０２９６】デバイス管理情報ブロック（ＤＭＩＢ）内
の書き込みフラグ（Writable Flag）を受信（Ｓ３２
４）した登録装置は、書き込みフラグ（Writable Fla
g）が書き込み不可（０ｘ００００）に設定されている
か否かを判別する。書き込みフラグ（Writable Flag）
が書き込み不可（０ｘ００００）に設定されていない場
合は、正常なＤＭＩＢデータ書き込み処理が終了してい
ないことを示し、エラーとして処理を終了する。書き込
みフラグ（Writable Flag）が書き込み不可（０ｘ００
００）に設定されている場合は、正常なＤＭＩＢデータ
書き込み処理が終了したものとして処理を終了する。

【０２９７】デバイス製造エンティテイ(Manufacture)
の登録装置による初期登録（図３５の処理フロー）およ
び、デバイスマネージャによる初期登録処理（図３６〜
図４０の処理フロー）が完了した状態のデバイスのメモ
リ内格納データ構成例を図４１に示す。図４１は、図
６、図１４乃至図１８を用いて説明した製造情報ブロッ
ク（Manufacture Information Block）、デバイス管理
情報ブロック（Device Management Information Bloc
k）、公開鍵系デバイス鍵定義（Device Key Definition
Block(PUB)）、共通鍵系デバイス鍵定義ブロック（Dev
ice Key DefinitionBlock(Common)）、デバイス鍵領域
（Device Key Area）を示すものである。この時点で
は、メモリにパーティションは形成されていない。

【０２９８】製造情報ブロック（Manufacture Informat
ion Block）には、図１４を用いて説明したように、デ
バイスの固有情報としてのデバイスコード他が書き込ま
れる。この製造情報ブロック（Manufacture Informatio
n Block）に書き込まれた情報、あるいは書き込まれた
情報の一部、または書き込まれた情報に基づいて取得さ
れる演算データがデバイスの識別子（ＩＤｍ）に相当す
る。

【０２９９】なお、図に示すデバイス鍵領域（Device K
ey Area）には Kauth＿DEV_B :双方向個別鍵認証用共通
鍵、 MKauth＿DEV_A :双方向個別鍵認証用マスター鍵が
格納されているが、これらの鍵は、デバイスが共通鍵認
証処理を行なう要請が無い場合は格納しない構成として
もよく、また、Kprt :パーティション登録チケット（Ｐ
ＲＴ）のＭＡＣ検証用鍵についても、デバイスが共通鍵
によるチケット検証処理を実行しない構成の場合には格
納しない構成としてもよい。

【０３００】また、IRL_DEV :排除デバイス（Device）
のデバイス識別子（ＩＤ）を登録したリボケーションリ
スト（Revocation List (Device ID)）、CRL_DEV :排除
デバイス（Device）の公開鍵証明書識別子（ｅｘ．シリ
アルナンバ：ＳＮ）を登録したリボケーションリスト
（Revocation List (Certificate)についても、デバイ
ス発行時点でリボーク（排除）されたデバイスが存在し
ない場合、あるいは他のソースを使用してリボケーショ
ンリストを取得する構成とする場合には、リボケーショ
ンリストを格納しない構成としてもよい。

【０３０１】［Ｂ３．２．デバイスマネージャ管理下に
おける公開鍵証明書発行処理］次に図４２以下を用い
て、デバイスマネージャによるデバイス対応公開鍵証明
書の発行処理について説明する。デバイスには、デバイ
ス全体の認証、デバイスを単位とした処理に適用可能な
デバイス対応公開鍵証明書（ＣＥＲＴ ＤＥＶ）と、デ
バイス内の特定のパーティションに対する処理の際の認
証その他検証処理等に適用可能なパーティション対応公
開鍵証明書（ＣＥＲＴ ＰＡＲ）が格納され得る。パー
ティション対応公開鍵証明書（ＣＥＲＴ ＰＡＲ）は、
デバイスに設定されたパーティション毎に設定格納可能
である。

【０３０２】デバイス対応公開鍵証明書（ＣＥＲＴ Ｄ
ＥＶ）は、デバイスマネージャの管轄するメモリ領域で
あるデバイス鍵領域（Device Key Area）（図１８参
照）に格納され、パーティション対応公開鍵証明書（Ｃ
ＥＲＴ ＰＡＲ）は、各パーティションマネージャの管
轄するメモリ領域であるパーティション鍵領域（Partit
ion Key Area）（図２３参照）に格納される。

【０３０３】デバイス対応公開鍵証明書（ＣＥＲＴ Ｄ
ＥＶ）は、デバイスマネージャの管轄する登録局を介し
て認証局（ＣＡ ｆｏｒ ＤＭ）（図２、図３参照）の発
行した公開鍵証明書をデバイスに付与する手続きにより
発行され、デバイスマネージャの管轄登録局が発行した
公開鍵証明書（ＣＥＲＴ ＤＥＶ）についての管理（デ
ータベース２２２（図７参照））を実行する。

【０３０４】またパーティション対応公開鍵証明書（Ｃ
ＥＲＴ ＰＡＲ）は、パーティションマネージャの管轄
する登録局を介して認証局（ＣＡ ｆｏｒ ＰＭ）（図
２、図３参照）の発行した公開鍵証明書をデバイスに付
与する手続きにより発行され、パーティションマネージ
ャの管轄登録局が発行した公開鍵証明書（ＣＥＲＴ Ｐ
ＡＲ）についての管理（データベース３３２（図９参
照））を実行する。

【０３０５】図４２および図４３に従って、デバイスマ
ネージャの管轄登録局によるデバイスに対するデバイス
対応公開鍵証明書（ＣＥＲＴ ＤＥＶ）の発行処理の手
順を説明する。なお、デバイスマネージャの登録局（Ｒ
Ａ）構成のみを取り出した発行装置（ＤＭ）、認証局
（ＣＡ）、ユーザデバイスとの関係を図４４に示した。
図４４に示すように制御手段２２１は暗号処理手段を有
する。なお暗号処理は暗号処理に関するプログラムを制
御部（ＣＰＵ（図８の２１１１）の制御下において実行
することによって行われる。

【０３０６】図４２，図４３において、左側がデバイス
マネージャの管轄登録局のＣＥＲＴ（公開鍵証明書）発
行装置、具体的には、図７に示すデバイスマネージャの
構成図における制御手段２２１の処理、右側がデバイス
の処理である。

【０３０７】まずステップＳ３５１において、ＣＥＲＴ
発行装置は、デバイス対応公開鍵証明書（ＣＥＲＴ Ｄ
ＥＶ）の発行対象となるデバイスのユーザ情報を取得
し、証明書発行の許可（判定）を行ない発行対象となる
デバイスとの通信路を確保する。デバイス対応公開鍵証
明書（ＣＥＲＴ ＤＥＶ）の発行対象となるデバイスの
ユーザ情報は、例えばデバイスの初期登録時に生成した
データから取得可能である。また、別途、別経路にてユ
ーザの名前や住所、電話番号、ｅ−ｍａｉｌアドレスな
どを取得するようにしてもよい。なお、ユーザ情報はデ
バイスとの通信路設定後、デバイスから取得してもよ
い。通信路は、有線、無線を問わずデータ送受信可能な
通信路として確保されればよい。

【０３０８】次にＣＥＲＴ発行装置は、ステップＳ３５
２において、乱数を含む認証データ生成コマンドをデバ
イスに対して送信する。認証データ生成コマンドを受信
（Ｓ３６１）したデバイスは、受信乱数Ｒと、デバイス
識別子（ＩＤｍ）の結合データにデバイス秘密鍵（ＰＲ
Ｉ ＤＥＶ）を適用してデジタル署名（Ｓ）の生成処理
（図１２参照）を実行（Ｓ３６２）する。デバイスは、
デバイスの識別データ（ＩＤｍ）と署名（Ｓ）をＣＥＲ
Ｔ発行装置に送信する。

【０３０９】デバイスから識別データ（ＩＤｍ）と署名
（Ｓ）を受信（Ｓ３５３）したＣＥＲＥＴ発行装置は、
受信したデバイス識別データ（ＩＤｍ）を検索キーとし
てデータベースＤＢ（ＤＥＶ）２２２から格納済みのデ
バイス公開鍵（ＰＵＢ ＤＥＶ）を取得する。さらに、
取得したデバイス公開鍵（ＰＵＢ ＤＥＶ）を適用して
署名（Ｓ）の検証処理（図１３参照）を実行（Ｓ３５
５）する。検証に成功しなかった場合は、デバイスから
の送信データは不正なデータであると判定し処理は終了
する。

【０３１０】検証に成功した場合は、認証局（ＣＡ ｆ
ｏｒ ＤＭ）６１０に対してデバイス対応公開鍵証明書
（ＣＥＲＴ ＤＥＶ）の発行処理を依頼（Ｓ３５７）す
る。デバイスマネージャは認証局６１０の発行したデバ
イス対応公開鍵証明書（ＣＥＲＴ ＤＥＶ）を受信（Ｓ
３５８）してデバイスに送信（Ｓ３５９）する。

【０３１１】デバイスマネージャ（登録局）からデバイ
ス対応公開鍵証明書（ＣＥＲＴ ＤＥＶ）を受信したデ
バイスは、予めデバイス鍵領域に格納済みの認証局の公
開鍵（ＰＵＢ ＣＡ（ＤＥＶ））を用いて受信したデバ
イス対応公開鍵証明書（ＣＥＲＴ ＤＥＶ）の署名検証
を実行する。すなわち公開鍵証明書には認証局の秘密鍵
で実行された署名があり（図１１参照）、この署名検証
（Ｓ３６６）を行なう。

【０３１２】署名検証に失敗した場合は、正当な公開鍵
証明書でないと判定し、エラー通知をＣＥＲＴ発行装置
に対して実行（Ｓ３８５）する。

【０３１３】署名検証に成功した場合は、デバイス対応
公開鍵証明書（ＣＥＲＴ ＤＥＶ）に格納されたデバイ
ス公開鍵（ＰＵＢ ＤＥＶ）と自デバイスに保管された
デバイス公開鍵（ＰＵＢ ＤＥＶ）の比較を実行（Ｓ３
８２）し、一致しない場合はエラー通知を実行し、一致
した場合は、受信したデバイス対応公開鍵証明書（ＣＥ
ＲＴ ＤＥＶ）をデバイス鍵領域（図１８参照）に格納
（Ｓ３８３）する。なお、デバイス対応公開鍵証明書
（ＣＥＲＴ ＤＥＶ）の発行以前は、この領域に自デバ
イスで生成した公開鍵（ＰＵＢ ＤＥＶ）を格納し、正
当なデバイス対応公開鍵証明書（ＣＥＲＴ ＤＥＶ）が
発行された時点で、デバイス対応公開鍵証明書（ＣＥＲ
Ｔ ＤＥＶ）により上書きする処理として格納する。

【０３１４】デバイス対応公開鍵証明書（ＣＥＲＴ Ｄ
ＥＶ）の格納が終了すると格納処理終了通知をＣＥＲＴ
発行装置に送信（Ｓ３８４）する。ＣＥＲＴ発行装置
は、格納処理終了通知を受信（Ｓ３７１）し、格納成功
を確認（Ｓ３７２）して処理を終了する。格納成功の確
認が得られない場合はエラーとして処理が終了する。

【０３１５】図４５にデバイス対応公開鍵証明書（ＣＥ
ＲＴ ＤＥＶ）の発行処理において、デバイスマネージ
ャ２００、デバイス１００、認証局（ＣＡ）６１０各エ
ンティテイ間のデータ送受信処理について説明した図を
示す。

【０３１６】図４５中のＮｏ．１〜１４の順に処理が実
行される。なお、処理Ｎｏ．１のデバイスマネージャ２
００によるデバイス１００からのデバイス識別子（ＩＤ
ｍ）、デバイス公開鍵（ＰＵＢ ＤＥＶ）の取得処理、
および処理Ｎｏ．２のデバイス識別子（ＩＤｍ）の登録
処理はデバイスマネージャによる初期登録において実行
される処理である。

【０３１７】デバイス対応公開鍵証明書（ＣＥＲＴ Ｄ
ＥＶ）の発行手続きは、処理Ｎｏ．３からであり、３．
デバイスマネージャによるデバイスからの顧客情報取
得、４．顧客情報の登録（登録済みである場合は不
要）、５．デバイスからのデバイス識別子（ＩＤｍ）取
得、６．取得したデバイス識別子（ＩＤｍ）にもとつい
てデータベース検索を実行して対応の公開鍵（ＰＵＢ
ＤＥＶ）を取得、７．デバイスとデバイスマネージャ間
における認証処理、この処理は図４２、図４３の処理に
おいては省略されていたが、図４２、図４３においては
デバイスからのデバイス識別子（ＩＤｍ）取得の際に署
名検証を実行しており、通信相手の送信データの確認に
より、認証を省略した。図４２、図４３における署名検
証、図４５の認証の少なくともいずれか、またはいずれ
をも実行することが望ましい。なお、認証処理の詳細に
ついては、後段のＢ．４．パーティションマネージャの
管轄処理の項目で説明する。

【０３１８】８．デバイスマネージャから認証局に対す
るデバイス対応公開鍵証明書の発行要求、９．デバイス
対応公開鍵証明書（ＣＥＲＴ ＤＥＶ）の生成、１０．
認証局における生成公開鍵証明書のデータ登録、１１．
認証局（ＣＡ）６１０からデバイスマネージャ２００に
対する公開鍵証明書の配布、１２．デバイスマネージャ
のデータベース更新（公開鍵証明書発行情報登録）、１
３．デバイスマネージャからデバイスに対するデバイス
対応公開鍵証明書（ＣＥＲＴ ＤＥＶ）の送信、１４．
デバイスにおけるデバイス対応公開鍵証明書（ＣＥＲＴ
ＤＥＶ）の保存、保存は、前述したようにデバイス鍵
領域に書き込み保存される。

【０３１９】以上の処理により、デバイスは、デバイス
対応公開鍵証明書（ＣＥＲＴ ＤＥＶ）を取得し、メモ
リ部に格納する。このデバイス対応公開鍵証明書（ＣＥ
ＲＴＤＥＶ）をメモリのデバイス鍵格納領域に格納した
後のメモリの各ブロックのデータ格納構成を図４６に示
す。図４６は、先に図６、図１４乃至図１８を用いて説
明した製造情報ブロック（Manufacture Information Bl
ock）、デバイス管理情報ブロック（Device Management
Information Block）、公開鍵系デバイス鍵定義（Devi
ce Key Definition Block(PUB)）、共通鍵系デバイス鍵
定義ブロック（Device Key Definition Block(Commo
n)）、デバイス鍵領域（Device Key Area）を示すもの
である。この時点では、メモリにパーティションは形成
されていない。

【０３２０】図４６に示すデバイス鍵領域（Device Key
Area）にはデバイス対応公開鍵証明書（ＣＥＲＴ ＤＥ
Ｖ）が格納される。デバイス対応公開鍵証明書（ＣＥＲ
ＴＤＥＶ）の発行前には、この領域には、デバイスが生
成した公開鍵（ＰＵＢ ＤＥＶ）が格納され、デバイス
対応公開鍵証明書（ＣＥＲＴ ＤＥＶ）を受信すると、
デバイス対応公開鍵証明書（ＣＥＲＴ ＤＥＶ）によっ
て上書き処理がなされる。なお、この上書き処理により
ポインタ、サイズ、管理データがある場合は必要な変更
処理を実行する。

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

【０３２２】［Ｂ４．１．パーティションマネージャ管
理下におけるパーティション登録チケット（ＰＲＴ）を
利用したパーティション設定登録、削除処理］まず、パ
ーティション登録チケット（ＰＲＴ）（図２６参照）を
利用したパーティション設定登録、削除処理について説
明する。図４７以下のフロー他の図面を参照して説明す
る。なお、上述のように、パーティション設定処理に
は、デバイスとパーティションマネージャ間における相
互認証処理（デバイス認証またはパーティション認
証）、パーティション登録チケット（ＰＲＴ：Partitio
n Registration Ticket）の正当性検証処理が含まれ、
これらの処理についても説明する。

【０３２３】図４７に示すパーティション設定登録、削
除処理フローについて説明する。図４７において、左側
がパーティションマネージャのパーティション作成・削
除装置、右側がデバイス（図５参照）の処理を示す。な
お、パーティションマネージャのパーティション作成・
削除装置は、デバイスに対するデータ読み取り書き込み
処理可能な装置（ｅｘ．デバイスアクセス機器としての
リーダライタ、ＰＣ）であり、図１０のデバイスアクセ
ス機器としてのリーダライタに相当する。まず、図４７
を用いて、パーティション作成、削除処理の概要を説明
し、その後、当処理に含まれる各処理の詳細を図４８以
下のフローを用いて順次説明する。

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

【０３２５】本発明のシステムにおける相互認証処理で
は、デバイス認証またはパーティション認証のいずれか
が実行される。また、それぞれについて共通鍵方式認
証、あるいは公開鍵方式認証処理のいずれかが適用され
る。これらについては後述する。

【０３２６】なお、相互認証処理として実行すべき処理
は、適用するパーティション登録チケット（ＰＲＴ）
（図２６参照）の * Authentication Flag :チケット（Ticket）の利用処
理においてデバイス（Device）との相互認証が必要か否
かを示すフラグ * Authentication Type :デバイス（Device）の相互認
証のタイプ（公開鍵認証、または、共通鍵認証、また
は、いずれでも可（Any））によって決定される。

【０３２７】認証処理に失敗した場合（Ｓ４０２，Ｓ４
１１でＮｏ）は、相互が正当な機器、デバイスであるこ
との確認がとれないことを示し、以下の処理は実行され
ずエラーとして処理は終了する。

【０３２８】認証処理に成功すると、パーティション作
成・削除装置は、デバイスに対してパーティション登録
チケット（ＰＲＴ：Partition Registration Ticket）
を送信する。パーティション登録チケット（ＰＲＴ）
は、パーティションマネージャの要求により、デバイス
マネージャの管理するパーティション登録チケット（Ｐ
ＲＴ）発行手段（PRT Issuer）によりパーティションマ
ネージャに対して発行されるチケットである。パーティ
ション登録チケット（ＰＲＴ）は、デバイスに対するア
クセス制御チケットであり、先に説明した図２６のデー
タフォーマット構成を持つチケットである。

【０３２９】なお、パーティション登録チケット（ＰＲ
Ｔ）を、チケットユーザに対して送信する際には、公開
鍵方式の場合、パーティション登録チケット（ＰＲＴ）
発行手段（PRT Issuer）の公開鍵証明書（CERT_PRTI）
も一緒に送信する。ＰＲＴ発行手段の公開鍵証明書（CE
RT_PRTI）の属性（Attribute）は、パーティション登録
チケット（ＰＲＴ）発行手段（ＰＲＴ User）の識別子
(PRTIC)と一致する。

【０３３０】パーティション登録チケット（ＰＲＴ）を
受信（Ｓ４１２）したデバイスは、受信したチケット
（ＰＲＴ）の正当性と利用者チェック処理を実行（Ｓ４
１３）する。チケットの正当性の検証処理は、共通鍵方
式によるＭＡＣ検証、あるいは公開鍵方式による署名検
証処理のいずれかを適用して実行される。利用者チェッ
クは、チケットを送信してきた機器（チケット利用者）
の正当性をチェックする処理であり、相互認証が成立済
みであり、認証相手の識別データと、チケットに記録さ
れているチケットユーザ識別子（図２６参照）との一致
等を検証する処理として実行される。これらの処理の詳
細については後述する。

【０３３１】デバイスにおいて、受信チケット（ＰＲ
Ｔ）の正当性と利用者チェック処理の結果、チケットお
よび利用者の正当なことが確認できなかった場合（Ｓ４
１４でＮｏ）は、パーティション登録チケット（ＰＲ
Ｔ）受理エラーをパーティション作成・削除装置に通知
（Ｓ４１８）する。チケットおよび利用者の正当なこと
が確認できた場合（Ｓ４１４でＹｅｓ）は、受信したパ
ーティション登録チケット（ＰＲＴ）に記述されたルー
ルに従いデバイス内のメモリ部におけるパーティション
の生成、または削除処理を実行する。この処理の詳細に
ついても別フローを用いて後段で詳述する。

【０３３２】パーティション登録チケット（ＰＲＴ）の
記述に従って、パーティションの生成または削除処理に
成功（Ｓ４１６でＹｅｓ）すると、ＰＲＴ受理成功をパ
ーティション作成・削除装置に通知（Ｓ４１７）する。
一方、パーティションの生成または削除処理に失敗（Ｓ
４１６でＮｏ）した場合は、ＰＲＴ受理エラーをパーテ
ィション作成・削除装置に通知（Ｓ４１８）する。

【０３３３】パーティション作成・削除装置は、ＰＲＴ
受理結果を受信（Ｓ４０４）し、ＰＲＴ処理結果を判定
し、ＰＲＴ受理結果がエラーである場合（Ｓ４０５でＮ
ｏ）は、エラーとして処理を終了し、ＰＲＴ受理結果が
成功（Ｓ４０５でＹｅｓ）であり、処理がパーティショ
ン生成である場合はパーティション初期データの書き込
み処理（Ｓ４０６，Ｓ４１９）を実行する。初期データ
の書き込み処理については、後段で別フローを用いて詳
述する。パーティション初期データの書き込み処理が終
了した場合、およびＰＲＴ受理結果が成功（Ｓ４０５で
Ｙｅｓ）であり、処理がパーティション削除である場合
はセッションクリアコマンドの送受信（Ｓ４０７，Ｓ４
２０）を実行し、デバイス側に生成した認証ーブルを破
棄（Ｓ４２１）し、処理を終了する。認証テーブルは、
ステップＳ４０１，Ｓ４１０の相互認証処理において生
成されるテーブルであり、その詳細は後述する。

【０３３４】このようにパーティション登録チケット
（ＰＲＴ）を利用して、デバイス内に新たなパーティシ
ョンの生成、または生成済みのパーティションの削除が
実行される。以下、当処理に含まれる相互認証処理（Ｓ
４０１，Ｓ４１０）、チケットの正当性と利用者チェッ
ク（Ｓ４１３）、パーティションの生成、削除処理（Ｓ
４１５）、パーティション初期データ書き込み処理（Ｓ
４０６，Ｓ４１９）の各処理について詳述する。

【０３３５】（相互認証処理）図４７のステップＳ４０
１，Ｓ４１０において実行される相互認証処理について
説明する。なお、以下に説明する相互認証処理は、他の
チケット、すなわちファイル登録チケット（ＦＲＴ：Fi
le Registration Ticket）、サービス許可チケット（Ｓ
ＰＴ：Service Permission Ticket）、データアップデ
ートチケット（ＤＵＴ：Data Update Ticket）を使用し
たデバイスアクセス処理においても適宜必要に応じて行
われる処理である。

【０３３６】相互認証処理の処理フローを図４８に示
す。図４８において、左側がパーティションマネージャ
の認証装置、右側がデバイス（図５参照）の処理を示
す。なお、パーティションマネージャの認証装置は、デ
バイスに対するデータ読み取り書き込み処理可能な装置
（ｅｘ．デバイスアクセス機器としてのリーダライタ、
ＰＣ）であり、図１０のリーダライタに相当する構成を
有する。

【０３３７】図４８のステップＳ４３１において、認証
装置は、パーティション登録チケット（ＰＲＴ）の利用
に必要な認証方式をチケットから読み出して決定する。
なお、認証態様は、チケット記載の認証方式に限らず、
例えばアクセス機器（ｅｘ．リーダライタ）からの指定
された方式に従ってデバイス認証、パーティション認証
を決定してもよい。

【０３３８】決定した認証方式をＡ（１）〜Ａ（ｎ）と
する。パーティション登録チケット（ＰＲＴ）を適用し
たパーティションの設定登録、あるいは削除処理におい
ては様々な認証処理態様が設定される。例えばパーティ
ションの設定登録についてはデバイスを対象とするデバ
イス認証を必要とし、パーティション削除の場合にはデ
バイス認証と削除対象となるパーティション認証の双方
を必要とするなどである。このように処理に応じていず
れか一方の認証、または両者の認証を必要とする設定を
パーティション登録チケット（ＰＲＴ）に記述すること
ができる。ＰＲＴ利用処理において必要とする認証方式
については、パーティション登録チケット（ＰＲＴ）の
［Authentication Type］に記述され、認証装置は、パ
ーティション登録チケット（ＰＲＴ）の利用に必要な認
証方式をチケットから読み出して決定し、認証処理手順
をＡ（ｉ）：Ａ（１）〜Ａ（ｎ）として定義する。

【０３３９】ステップＳ４３２において、最初の認証処
理方式Ａ（１）を読み出し、Ａ（１）の認証方式がデバ
イス認証、パーティション認証であるかについて判別
（Ｓ４３３）し、デバイス認証であればデバイス認証を
実行（Ｓ４３４，Ｓ４４１）し、パーティション認証で
あればパーティション認証を実行（Ｓ４３５，Ｓ４４
２）する。デバイスとの認証処理の結果、認証が成功し
ない場合は、エラーとして処理を終了する。認証が成功
した場合は、ステップＳ４３７においてｉをインクリメ
ントしてステップＳ４３３に戻り、次の認証方式を判別
して、方式に従って認証を実行する。これらの処理をＡ
（１）〜Ａ（ｎ）まで実行して、全ての認証が成功した
場合に次のステップに進む。

【０３４０】デバイス認証処理について図４９のフロー
に従って説明する。図４９において、左側がパーティシ
ョンマネージャのデバイス認証装置、右側がデバイス
（図５参照）の処理を示す。なお、パーティションマネ
ージャのデバイス認証装置は、デバイスに対するデータ
読み取り書き込み処理可能な装置（ｅｘ．デバイスアク
セス機器としてのリーダライタ、ＰＣ）であり、図１０
のデバイスアクセス機器としてのリーダライタに相当す
る構成を有する。

【０３４１】デバイス認証装置は、ステップＳ４５１に
おいて、パーティション登録チケット（ＰＲＴ）に基づ
いてデバイス認証処理に公開鍵を用いた公開鍵認証方式
を適用するか否かを判定する。デバイス認証は、公開鍵
方式または共通鍵方式のいずれかにおいて実行され、チ
ケットにその実行方式についての指定が記述されてい
る。

【０３４２】共通鍵方式の指定がある場合は、図４９の
ステップＳ４５２〜Ｓ４５５、Ｓ４６１〜Ｓ４６５の処
理は実行されず、ステップＳ４５６に進む。公開鍵方式
の指定である場合は、デバイス認証装置は、ステップＳ
４５２において公開鍵デバイス認証開始コマンドをデバ
イスに送信する。デバイスは、コマンドを受信（Ｓ４６
１）すると、デバイスのメモリ部の公開鍵系デバイス鍵
定義ブロック（図１６参照）を参照して、デバイス対応
公開鍵証明書（ＣＥＲＴ ＤＥＶ）が格納されているか
否かを検証（Ｓ４６２）する。デバイス対応公開鍵証明
書（ＣＥＲＴＤＥＶ）が格納されていない場合は、公開
鍵方式の相互認証は実行できず、エラーと判定され処理
は終了される。

【０３４３】デバイス対応公開鍵証明書（ＣＥＲＴ Ｄ
ＥＶ）が格納されていることが確認されると、ステップ
Ｓ４５３、Ｓ４６３において、デバイスマネージャ対応
認証局（ＣＡ（ＤＥＶ））の発行した公開鍵証明書を用
いた相互認証および鍵共有処理が実行される。

【０３４４】公開鍵方式による相互認証および鍵共有処
理について、図５０を用いて説明する。図５０は、公開
鍵暗号方式である１６０ビット長の楕円曲線暗号（ＥＣ
Ｃ）を用いた相互認証シーケンスを示している。図５０
では、公開鍵暗号方式としてＥＣＣを用いているが、公
開鍵暗号方式の他方式を適用することも可能である。ま
た、鍵サイズも１６０ビットでなくてもよい。図５０に
おいて、まずＢが、６４ビットの乱数Ｒｂを生成し、Ａ
に送信する。これを受信したＡは、新たに６４ビットの
乱数Ｒａおよび標数ｐより小さい乱数Ａｋを生成する。
そして、ベースポイントＧをＡｋ倍した点Ａｖ＝Ａｋ×
Ｇを求め、Ｒａ、Ｒｂ、Ａｖ（X座標とY座標）に対する
電子署名Ａ．Ｓｉｇを生成し、Ａの公開鍵証明書ととも
にＢに返送する。ここで、ＲａおよびＲｂはそれぞれ６
４ビット、ＡｖのＸ座標とＹ座標がそれぞれ１６０ビッ
トであるので、合計４４８ビットに対する電子署名を生
成する。

【０３４５】公開鍵証明書を利用する際には、利用者は
自己が保持する公開鍵証明書発行局（ＣＡ）の公開鍵を
用い、当該公開鍵証明書の電子署名を検証し、電子署名
の検証に成功した後に公開鍵証明書から公開鍵を取り出
し、当該公開鍵を利用する。従って、公開鍵証明書を利
用する全ての利用者は、共通の公開鍵証明書発行局（Ｃ
Ａ）の公開鍵を保持している必要がある。なお、電子署
名の検証方法については、図１３で説明したのでその詳
細は省略する。

【０３４６】Ａの公開鍵証明書、Ｒａ、Ｒｂ、Ａｖ、電
子署名Ａ．Ｓｉｇを受信したＢは、Ａが送信してきたＲ
ｂが、Ｂが生成したものと一致するか検証する。その結
果、一致していた場合には、Ａの公開鍵証明書内の電子
署名を認証局の公開鍵で検証し、Ａの公開鍵を取り出
す。そして、取り出したＡの公開鍵を用い電子署名Ａ．
Ｓｉｇを検証する。電子署名の検証に成功した後、Ｂは
Ａを正当なものとして認証する。

【０３４７】次に、Ｂは、標数ｐより小さい乱数Ｂｋを
生成する。そして、ベースポイントＧをＢｋ倍した点Ｂ
ｖ＝Ｂｋ×Ｇを求め、Ｒｂ、Ｒａ、Ｂｖ（Ｘ座標とＹ座
標）に対する電子署名Ｂ．Ｓｉｇを生成し、Ｂの公開鍵
証明書とともにＡに返送する。

【０３４８】Ｂの公開鍵証明書、Ｒｂ、Ｒａ、Ｂｖ、電
子署名Ｂ．Ｓｉｇを受信したＡは、Ｂが送信してきたＲ
ａが、Ａが生成したものと一致するか検証する。その結
果、一致していた場合には、Ｂの公開鍵証明書内の電子
署名を認証局の公開鍵で検証し、Ｂの公開鍵を取り出
す。そして、取り出したＢの公開鍵を用い電子署名Ｂ．
Ｓｉｇを検証する。電子署名の検証に成功した後、Ａは
Ｂを正当なものとして認証する。

【０３４９】両者が認証に成功した場合には、ＢはＢｋ
×Ａｖ（Ｂｋは乱数だが、Ａｖは楕円曲線上の点である
ため、楕円曲線上の点のスカラー倍計算が必要）を計算
し、ＡはＡｋ×Ｂｖを計算し、これら点のＸ座標の下位
６４ビットをセッション鍵として以降の通信に使用する
（共通鍵暗号を６４ビット鍵長の共通鍵暗号とした場
合）。もちろん、Ｙ座標からセッション鍵を生成しても
よいし、下位６４ビットでなくてもよい。なお、相互認
証後の秘密通信においては、送信データはセッション鍵
で暗号化されるだけでなく、電子署名も付されることが
ある。

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

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

【０３５２】図４９に戻りフローの説明を続ける。ステ
ップＳ４５３，Ｓ４６３において上述のような相互認
証、鍵共有処理に成功すると、デバイスは、ステップＳ
４６４において、デバイスのメモリ部のデバイス鍵領域
（図１８参照）に格納されたCRL_DEV :排除デバイス（D
evice）、排除機器（デバイスアクセス機器としてのリ
ーダライタ、ＰＣ等のチケットユーザ、チケット発行手
段）の公開鍵証明書識別子（ｅｘ．シリアルナンバ：Ｓ
Ｎ）を登録したリボケーションリスト（Revocation Lis
t (Certificate)を参照して、通信相手であるデバイス
認証装置がリボークされていないかを検証する。リボー
クされている場合は、パーティションの生成処理を許可
できないので、エラーとして処理を終了する。

【０３５３】リボークされていない場合は、ステップＳ
４６５において、相互認証および鍵共有処理において生
成したセッション鍵Ｋｓｅｓと、通信相手（デバイス認
証装置を構成するデバイスアクセス機器としてのリーダ
ライタ、ＰＣなど）の公開鍵証明書中の識別名（ＤＮ：
Distinguished Name）、シリアルナンバー、カテゴリー
をデバイスマネージャコード（ＤＭＣ）をキーとして対
応付けた認証テーブルに保存する。

【０３５４】一方、デバイス認証装置も、ステップＳ４
５４において、デバイスがリボークされていないかをCR
L_DEV :排除デバイス（Device）、排除機器（デバイス
アクセス機器としてのリーダライタ、ＰＣ等のチケット
ユーザ、チケット発行手段）の公開鍵証明書識別子（ｅ
ｘ．シリアルナンバ：ＳＮ）を登録したリボケーション
リスト（Revocation List (Certificate)）を参照して
判定する。デバイス認証装置は、リボケーションリスト
（CRL_DEV）を登録局（ＲＡ（ＰＡＲ））から取得可能
である。リボークされている場合は、パーティションの
生成処理を許可できないので、エラーとして処理を終了
する。

【０３５５】リボークされていない場合は、ステップＳ
４５５において、相互認証および鍵共有処理において生
成したセッション鍵Ｋｓｅｓと、通信相手（デバイス）
の公開鍵証明書中の識別名（ＤＮ：Distinguished Nam
e）、シリアルナンバー、カテゴリーをデバイスマネー
ジャコード（ＤＭＣ）をキーとして対応付けた認証テー
ブルに保存する。

【０３５６】図５１にデバイス内に生成される認証テー
ブルの例を示し、図５２に認証装置としてのデバイスア
クセス機器としてのリーダライタ（ＰＣも可）に生成さ
れる認証テーブルの例を示す。

【０３５７】図５１は、デバイス認証、および後段で説
明するパーティション認証としてのパーティション１，
２の認証が終了した時点のデバイス内に生成される認証
テーブルの例である。グループ（Group）として、デバ
イス認証の場合はデバイスマネージャコード（ＤＭ
Ｃ）、パーティション認証の場合はパーティションマネ
ージャコード（ＰＭＣ）が記録され、実行された各認証
方式によってそれぞれのデータが格納される。公開鍵認
証方式の場合は、前述したようにセッション鍵Ｋｓｅｓ
と、通信相手（デバイスアクセス機器としてのリーダラ
イタ）の公開鍵証明書中の識別名（ＤＮ：Distinguishe
d Name）、シリアルナンバー、カテゴリーがテーブルに
格納され、共通鍵認証の場合は、セッション鍵Ｋｓｅｓ
と、通信相手（デバイスアクセス機器としてのリーダラ
イタ）の識別子（ＩＤ ＲＷ）ガ格納される。

【０３５８】認証テーブルはセッションのクリア時点で
破棄される。デバイスはテーブルの情報を参照すること
によってデバイスおよび各パーティションの認証状態を
確認することができ、使用すべきセッション鍵の確認が
可能となる。

【０３５９】一方、図５２は、デバイスアクセス機器と
してのリーダライタ側の認証テーブルを示している。こ
の例もデバイス認証、およびパーティション認証として
のパーティション１，２の認証が終了した時点の認証テ
ーブルの例である。基本的構成は、デバイス内の認証テ
ーブルと同様であり、グループ（Group）として、デバ
イス認証の場合はデバイスマネージャコード（ＤＭ
Ｃ）、パーティション認証の場合はパーティションマネ
ージャコード（ＰＭＣ）が記録され、実行された各認証
方式によってそれぞれのデータが格納される。公開鍵認
証方式の場合は、前述したようにセッション鍵Ｋｓｅｓ
と、通信相手（デバイス）の公開鍵証明書中の識別名
（ＤＮ：Distinguished Name）、シリアルナンバー、カ
テゴリーがテーブルに格納され、共通鍵認証の場合は、
セッション鍵Ｋｓｅｓと、通信相手（デバイス）の識別
子（ＩＤ ＲＷ）が格納される。リーダライタ側の認証
テーブルもセッションのクリア時点で破棄される。デバ
イスアクセス機器としてのリーダライタ側においても、
認証テーブルの情報を参照することによってデバイスお
よびパーティションの認証状態の有無を判定可能とな
り、使用すべきセッション鍵の確認が可能となる。

【０３６０】図４９に戻り、デバイス認証処理の説明を
続ける。デバイス認証装置はステップＳ４５１におい
て、デバイス認証方式が公開鍵方式でないと判定される
と、デバイス認証装置はステップＳ４５６において、共
通鍵デバイス認証コマンドをデバイスに出力する。デバ
イスは、コマンドを受信（Ｓ４６６）すると、デバイス
のメモリ部の共通鍵系デバイス鍵定義ブロック（図１６
参照）を参照して共通鍵認証に使用する双方向個別鍵認
証用マスター鍵（MKauth＿DEV）が格納されているか否
かを検証（Ｓ４６７）する。双方向個別鍵認証用マスタ
ー鍵（MKauth＿DEV）が格納されていない場合は、共通
鍵方式の相互認証は実行できず、エラーと判定され処理
は終了される。

【０３６１】双方向個別鍵認証用マスター鍵（MKauth＿
DEV）が格納されていることが確認されると、ステップ
Ｓ４５７、Ｓ４６８において、マスター鍵を使用した相
互認証および鍵共有処理が実行される。

【０３６２】マスター鍵を使用した共通鍵方式による相
互認証および鍵共有処理について、図５３を用いて説明
する。図５３では、ＡおよびＢがマスター鍵を使用した
共通鍵方式の認証を実行するエンティテイであり、Ａ
は、自己の識別子ＩＤａ、双方向個別鍵認証用共通鍵Ｋ
ａ、双方向個別鍵認証用マスター鍵ＭＫｂを有し、Ｂ
は、自己の識別子ＩＤｂ、双方向個別鍵認証用共通鍵Ｋ
ｂ、双方向個別鍵認証用マスター鍵ＭＫａを有する。な
お、図５３の例では、共通鍵暗号方式としてＤＥＳアル
ゴリズム（ｅｘ．ＤＥＳ，トリプルＤＥＳ）を用いてい
るが、同様な共通鍵暗号方式であれば他の暗号方式の適
用も可能である。

【０３６３】まず、Ｂが６４ビットの乱数Ｒｂを生成
し、Ｒｂおよび自己のＩＤであるＩＤｂをＡに送信す
る。これを受信したＡは、新たに６４ビットの乱数Ｒａ
を生成し、双方向個別鍵認証用マスター鍵ＭＫｂによる
ＩＤｂのＤＥＳ暗号化処理により双方向個別鍵認証用共
通鍵Ｋｂを取得する。さらに、鍵Ｋａ、Ｋｂを用いて、
Ｒａ，Ｒｂ，ＩＤａ，ＩＤｂの順に、ＤＥＳのＣＢＣモ
ードでデータを暗号化し、自己の識別子ＩＤａとともに
Ｂに返送する。

【０３６４】これを受信したＢは、まず、双方向個別鍵
認証用マスター鍵ＭＫａによるＩＤａのＤＥＳ暗号化処
理により双方向個別鍵認証用共通鍵Ｋａを取得する。さ
らに、受信データを鍵Ｋａ，Ｋｂで復号する。復号して
得られたＲａ、Ｒｂ、ＩＤａ，ＩＤｂの内、Ｒｂおよび
ＩＤｂが、Ｂが送信したものと一致するか検証する。こ
の検証に通った場合、ＢはＡを正当なものとして認証す
る。

【０３６５】次にＢは、セッション鍵として使用する６
４ビットの乱数Ｋｓｅｓを生成し、鍵Ｋｂ、Ｋａを用い
て、Ｒｂ，Ｒａ，ＩＤｂ，ＩＤａ，Ｋｓｅｓの順に、Ｄ
ＥＳのＣＢＣモードでデータを暗号化し、Ａに返送す
る。

【０３６６】これを受信したＡは、受信データを鍵Ｋ
ａ，Ｋｂで復号する。復号して得られたＲａ、Ｒｂ、Ｉ
Ｄａ，ＩＤｂがＡが送信したものと一致するか検証す
る。この検証に通った場合、ＡはＢを正当なものとして
認証する。互いに相手を認証した後には、セッション鍵
Ｋｓｅｓは、認証後の秘密通信のための共通鍵として利
用される。

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

【０３６８】本発明のシステムの格納データに対応付け
たマスター鍵を使用した共通鍵認証について、データの
流れを説明する図を図５４に示す。図５４に示すよう
に、デバイスアクセス機器としてのリーダライタ（Ｒ／
Ｗ）が６４ビットの乱数Ｒｂを生成し、Ｒｂおよび自己
のＩＤであるＩＤｒｗをデバイス（Ｄｅｖｉｃｅ）に送
信する。これを受信したデバイス（Ｄｅｖｉｃｅ）は、
新たに６４ビットの乱数Ｒａを生成し、双方向個別鍵認
証用マスター鍵MKauth＿DEV_AによるＩＤｒｗのＤＥＳ
暗号化処理により双方向個別鍵認証用共通鍵Kauth＿DEV
_Aを取得する。さらに、鍵Kauth＿DEV_A、Kauth＿DEV_B
を用いて、Ｒａ，Ｒｂ，ＩＤｒｗの順に、暗号アルゴリ
ズムとして、例えばＤＥＳ−ＣＢＣモードでデータを暗
号化し、自己の識別子ＩＤｍとともにデバイスアクセス
機器としてのリーダライタ（Ｒ／Ｗ）に返送する。

【０３６９】これを受信したリーダライタ（Ｒ／Ｗ）
は、まず、双方向個別鍵認証用マスター鍵MKauth＿DEV_
BによるＩＤｍのＤＥＳ暗号化処理により双方向個別鍵
認証用共通鍵Kauth＿DEV_Bを取得する。さらに、受信デ
ータを鍵Kauth＿DEV_A、Kauth＿DEV_Bで復号する。復号
して得られたＲｂおよびＩＤｒｗが、デバイスアクセス
機器としてのリーダライタ（Ｒ／Ｗ）が送信したものと
一致するか検証する。この検証に通った場合、リーダラ
イタ（Ｒ／Ｗ）はデバイス（Ｄｅｖｉｃｅ）を正当なも
のとして認証する。

【０３７０】次にリーダライタ（Ｒ／Ｗ）は、セッショ
ン鍵として使用する６４ビットの乱数Ｋｓｅｓを生成
し、双方向個別鍵認証用共通鍵Kauth＿DEV_A、 Kauth＿
DEV_Bを用いて、Ｒｂ，Ｒａ，Ｋｓｅｓの順に、ＤＥＳ
アルゴリズムとしての例えばトリプルＤＥＳモードでデ
ータを暗号化し、デバイス（Ｄｅｖｉｃｅ）に返送す
る。

【０３７１】これを受信したデバイスは、受信データを
双方向個別鍵認証用共通鍵Kauth＿DEV_A、 Kauth＿DEV_
Bで復号する。復号して得られたＲａ、Ｒｂ，ＩＤｒｗ
がデバイス（Ｄｅｖｉｃｅ）が送信したものと一致する
か検証する。この検証に通った場合、デバイス（Ｄｅｖ
ｉｃｅ）はリーダライタ（Ｒ／Ｗ）を正当なものとして
認証し、認証後、セッション鍵Ｋｓｅｓを秘密通信のた
めの共通鍵として利用する。

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

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

【０３７４】図４９に戻りフローの説明を続ける。ステ
ップＳ４５７，Ｓ４６８において上述のような相互認
証、鍵共有処理に成功すると、デバイスは、ステップＳ
４６９において、デバイスのメモリ部のデバイス鍵領域
（図１８参照）に格納されたIRL_DEV :排除デバイス（D
evice）、排除機器（デバイスアクセス機器としてのリ
ーダライタ、ＰＣ等のチケットユーザ、チケット発行手
段）の識別子（ＩＤ）を登録したリボケーションリスト
（Revocation List (ID)）を参照して、通信相手である
デバイス認証装置がリボークされていないかを検証す
る。リボークされている場合は、パーティションの生成
処理を許可できないので、エラーとして処理を終了す
る。

【０３７５】リボークされていない場合は、ステップＳ
４７０において、相互認証および鍵共有処理において生
成したセッション鍵Ｋｓｅｓと、通信相手（デバイス認
証装置を構成するデバイスアクセス機器としてのリーダ
ライタ、ＰＣなど）の識別情報（ＩＤｒｗ）をデバイス
マネージャコード（ＤＭＣ）をキーとして対応付けた認
証テーブル（図５１参照）に保存する。

【０３７６】一方、デバイス認証装置も、ステップＳ４
５８において、デバイスがリボークされていないかをＩ
RL_DEV :排除デバイス（Device）、排除機器（デバイス
アクセス機器としてのリーダライタ、ＰＣ等のチケット
ユーザ、チケット発行手段）の識別子（ＩＤ）を登録し
たリボケーションリスト（Revocation List (ID)）を参
照して判定する。デバイス認証装置は、リボケーション
リスト（IRL_DEV）を登録局（ＲＡ（ＰＡＲ））から取
得可能である。リボークされている場合は、パーティシ
ョンの生成処理を許可できないので、エラーとして処理
を終了する。

【０３７７】リボークされていない場合は、ステップＳ
４５９において、相互認証および鍵共有処理において生
成したセッション鍵Ｋｓｅｓと、通信相手（デバイス）
の識別情報（ＩＤｍ）をデバイスマネージャコード（Ｄ
ＭＣ）をキーとして対応付けた認証テーブル（図５２参
照）に保存する。

【０３７８】以上の処理が、パーティションマネージャ
の管轄するデバイスアクセス機器としてのリーダライタ
とデバイス間において実行されるデバイス認証処理であ
る。

【０３７９】次に、図４８のステップＳ４３５、Ｓ４４
２において実行されるパーティション認証処理につい
て、図５５、図５６を用いて説明する。パーティション
登録チケットを適用したパーティションの設定登録、ま
たは削除処理においては、先に説明したように処理に応
じてデバイス認証、パーティション認証のいずれか、ま
たは両者の認証を必要とする。これらの設定はパーティ
ション登録チケット（ＰＲＴ）に記述される。パーティ
ション登録チケット（ＰＲＴ）にパーティション認証を
実行する記述がある場合は、パーティション認証が実行
される。

【０３８０】図５５、図５６の処理フローの各ステップ
について説明する。図５５において、左側がパーティシ
ョンマネージャのパーティション認証装置、右側がデバ
イス（図５参照）の処理を示す。なお、パーティション
マネージャのパーティション認証装置は、デバイスに対
するデータ読み取り書き込み処理可能な装置（ｅｘ．デ
バイスアクセス機器としてのリーダライタ、ＰＣ）であ
り、図１０のデバイスアクセス機器としてのリーダライ
タに相当する構成を有する。

【０３８１】パーティション認証装置は、ステップＳ４
７１において、デバイスに対して認証対象となるパーテ
ィションＡの存在確認を実行するパーティションＡ存在
チェックコマンドを出力する。コマンドを受領（Ｓ４８
１）したデバイスは、デバイスのメモリ部内にパーティ
ションＡが存在するか否かをチェック（Ｓ４８２）す
る。ここでパーティションの識別子Ａとしては例えばパ
ーティションマネージャコード（ＰＭＣ）が使用され、
デバイスは、例えばパーティション定義ブロック（ＰＤ
Ｂ：Partition Definition Block）の格納ＰＭＣに基づ
いてパーティションの有無を判定することができる。デ
バイスによるパーティションの有無が判定されると、チ
ェック結果がパーティション認証装置に送信される。

【０３８２】チェック結果を受領（Ｓ４７２）したパー
ティション認証装置は、チェック結果を検証（Ｓ４７
３）し、パーティションの存在しないとの結果を受領し
た場合は、認証不可であるので、エラー終了する。チェ
ック結果がパーティションが存在することを示した場合
は、パーティション認証装置は、ステップＳ４７４にお
いて、パーティション登録チケット（ＰＲＴ）に基づい
てパーティション認証処理に公開鍵を用いた公開鍵認証
方式を適用するか否かを判定する。パーティション認証
は、前述のデバイス認証と同様、公開鍵方式または共通
鍵方式のいずれかにおいて実行され、チケットにその実
行方式についての指定が記述されている。

【０３８３】共通鍵方式の指定がある場合は、図５５の
ステップＳ４７５〜Ｓ４７８、Ｓ４８４〜Ｓ４８８の処
理は実行されず、ステップＳ４９１に進む。公開鍵方式
の指定である場合は、パーティション認証装置は、ステ
ップＳ４７５において公開鍵パーティションＡ認証開始
コマンドをデバイスに送信する。デバイスは、コマンド
を受信（Ｓ４８４）すると、デバイスのメモリ部の公開
鍵系パーティション鍵定義ブロック（図２１参照）を参
照して、パーティションＡ対応公開鍵証明書（ＣＥＲＴ
ＰＡＲ）が格納されているか否かを検証（Ｓ４８５）
する。パーティションＡ対応公開鍵証明書（ＣＥＲＴ
ＰＡＲ）が格納されていない場合は、公開鍵方式の相互
認証は実行できず、エラーと判定され処理は終了され
る。

【０３８４】パーティションＡ対応公開鍵証明書（ＣＥ
ＲＴ ＰＡＲ）が格納されていることが確認されると、
ステップＳ４７６、Ｓ４８６において、パーティション
マネージャ対応認証局（ＣＡ（ＰＡＲ））の発行した公
開鍵証明書を用いた相互認証および鍵共有処理が実行さ
れる。

【０３８５】公開鍵方式による相互認証および鍵共有処
理については、先のデバイス認証処理において説明した
図５０に示すシーケンスと同様であるので説明を省略す
る。ただし、パーティション認証において利用する公開
鍵証明書は、パーティションマネージャ対応認証局（Ｃ
Ａ（ＰＡＲ））の発行した公開鍵証明書であり、この公
開鍵証明書の署名検証には、パーティションマネージャ
対応認証局（ＣＡ（ＰＡＲ））の公開鍵（ＰＵＢ ＣＡ
（ＰＡＲ））を用いる。公開鍵（ＰＵＢ ＣＡ（ＰＡ
Ｒ））は、パーティション鍵領域（図２３参照）に格納
されている。このような相互認証処理において、生成し
たセッション鍵を用いて、送信データを暗号化して、相
互にデータ通信を実行する。

【０３８６】ステップＳ４７６，Ｓ４８６において図５
０に示すシーケンスに従った相互認証、鍵共有処理に成
功すると、デバイスは、ステップＳ４８７において、デ
バイスのメモリ部のパーティション鍵領域（図２３参
照）に格納されたCRL_PAR :排除デバイス（Device）、
排除機器（デバイスアクセス機器としてのリーダライ
タ、ＰＣ等のチケットユーザ、チケット発行手段）の公
開鍵証明書識別子（ｅｘ．シリアルナンバ：ＳＮ）を登
録したリボケーションリスト（Revocation List (Certi
ficate)を参照して、通信相手であるパーティション認
証装置がリボークされていないかを検証する。リボーク
されている場合は、パーティションの生成処理あるいは
削除処理を許可できないので、エラーとして処理を終了
する。

【０３８７】リボークされていない場合は、ステップＳ
４８８において、相互認証および鍵共有処理において生
成したセッション鍵Ｋｓｅｓと、通信相手（パーティシ
ョン認証装置を構成するデバイスアクセス機器としての
リーダライタ、ＰＣなど）の公開鍵証明書中の識別名
（ＤＮ：Distinguished Name）、シリアルナンバー、カ
テゴリーをパーティションマネージャコード（ＰＭＣ）
をキーとして対応付けた認証テーブルに保存する。

【０３８８】一方、パーティション認証装置も、ステッ
プＳ４７７において、デバイスがリボークされていない
かをCRL_PAR :排除デバイス（Device）、排除機器（デ
バイスアクセス機器としてのリーダライタ、ＰＣ等のチ
ケットユーザ、チケット発行手段）の公開鍵証明書識別
子（ｅｘ．シリアルナンバ：ＳＮ）を登録したリボケー
ションリスト（Revocation List (Certificate)）を参
照して判定する。デバイス認証装置は、リボケーション
リスト（CRL_PAR）を登録局（ＲＡ（ＰＡＲ））から取
得可能である。リボークされている場合は、パーティシ
ョンの生成処理あるいは削除処理を許可できないので、
エラーとして処理を終了する。

【０３８９】リボークされていない場合は、ステップＳ
４７８において、相互認証および鍵共有処理において生
成したセッション鍵Ｋｓｅｓと、通信相手（デバイス）
の公開鍵証明書中の識別名（ＤＮ：Distinguished Nam
e）、シリアルナンバー、カテゴリーをパーティション
マネージャコード（ＰＭＣ）をキーとして対応付けた認
証テーブルに保存する。この結果、例えば図５１に示す
認証テーブルがデバイス内に生成され、図５２に示す認
証テーブルがパーティション認証装置としてのデバイス
アクセス機器としてのリーダライタ（ＰＣも可）に生成
される。図５１、図５２は、デバイス認証、およびパー
ティション認証としてのパーティション１，２の認証が
終了した時点のデバイス内およびデバイスアクセス機器
としてのリーダライタ内に生成される認証テーブルの例
である。

【０３９０】パーティション認証の場合はパーティショ
ンマネージャコード（ＰＭＣ）が記録され、実行された
各認証方式によってそれぞれのデータが格納される。公
開鍵認証方式の場合は、前述したようにセッション鍵Ｋ
ｓｅｓと、通信相手の公開鍵証明書中の識別名（ＤＮ：
Distinguished Name）、シリアルナンバー、カテゴリー
がテーブルに格納され、共通鍵認証の場合は、セッショ
ン鍵Ｋｓｅｓと、通信相手の識別子が格納される。認証
テーブルはセッションのクリア時点で破棄される。デバ
イスおよびデバイスアクセス機器としてのリーダライタ
はテーブルの情報を参照することによってデバイスおよ
び各パーティションの認証状態を確認することができ、
使用すべきセッション鍵の確認が可能となる。

【０３９１】図５５，図５６のフローを用いて、パーテ
ィション認証処理の説明を続ける。パーティション認証
装置はステップＳ４７４において、パーティション認証
方式が公開鍵方式でないと判定されると、パーティショ
ン認証装置はステップＳ４９１において、共通鍵パーテ
ィションＡ認証コマンドをデバイスに出力する。デバイ
スは、コマンドを受信（Ｓ５０１）すると、デバイスの
メモリ部の共通鍵系パーティション鍵定義ブロック（図
２２参照）を参照して共通鍵認証に使用する双方向個別
鍵認証用マスター鍵（MKauth＿PAR_A）が格納されてい
るか否かを検証（Ｓ５０２）する。双方向個別鍵認証用
マスター鍵（MKauth＿PAR_A）が格納されていない場合
は、共通鍵方式の相互認証は実行できず、エラーと判定
され処理は終了される。

【０３９２】双方向個別鍵認証用マスター鍵（MKauth＿
PAR_A）が格納されていることが確認されると、ステッ
プＳ４９２、Ｓ５０３において、マスター鍵を使用した
相互認証および鍵共有処理が実行される。共通鍵方式に
よる相互認証および鍵共有処理については、先のデバイ
ス認証において、図５３、図５４を用いて説明したシー
ケンスと同様であるので、説明を省略する。ただし、パ
ーティション認証の場合に適用する鍵は、パーティショ
ン鍵定義ブロック（図２２参照）に定義され、パーティ
ション鍵領域（図２３参照）に格納された双方向個別鍵
認証用共通鍵（Kauth＿PAR_B）、および双方向個別鍵認
証用マスター鍵（MKauth＿PAR_A）である。

【０３９３】ステップＳ４９２，Ｓ５０３において共通
鍵方式の相互認証、鍵共有処理に成功すると、デバイス
は、ステップＳ５０４において、デバイスのメモリ部の
パーティション鍵領域（図２３参照）に格納されたIRL_
PAR :排除デバイス（Device）、排除機器（デバイスア
クセス機器としてのリーダライタ、ＰＣ等のチケットユ
ーザ、チケット発行手段）の識別子（ＩＤ）を登録した
リボケーションリスト（Revocation List (ID)）を参照
して、通信相手であるパーティション認証装置がリボー
クされていないかを検証する。リボークされている場合
は、パーティションの生成処理または削除処理を許可で
きないので、エラーとして処理を終了する。

【０３９４】リボークされていない場合は、ステップＳ
５０５において、相互認証および鍵共有処理において生
成したセッション鍵Ｋｓｅｓと、通信相手（デバイス認
証装置を構成するデバイスアクセス機器としてのリーダ
ライタ、ＰＣなど）の識別情報（ＩＤｒｗ）をパーティ
ションマネージャコード（ＰＭＣ）をキーとして対応付
けた認証テーブル（図５１参照）に保存する。

【０３９５】一方、パーティション認証装置も、ステッ
プＳ４９３において、デバイスがリボークされていない
かをＩRL_PAR :排除デバイス（Device）、排除機器（デ
バイスアクセス機器としてのリーダライタ、ＰＣ等のチ
ケットユーザ、チケット発行手段）の識別子（ＩＤ）を
登録したリボケーションリスト（Revocation List (I
D)）を参照して判定する。パーティション認証装置は、
リボケーションリスト（IRL_PAR）を登録局（ＲＡ（Ｐ
ＡＲ））から取得可能である。リボークされている場合
は、パーティションの生成処理または削除処理を許可で
きないので、エラーとして処理を終了する。

【０３９６】リボークされていない場合は、ステップＳ
４９４において、相互認証および鍵共有処理において生
成したセッション鍵Ｋｓｅｓと、通信相手（デバイス）
の識別情報（ＩＤｍ）をパーティションマネージャコー
ド（ＤＭＣ）をキーとして対応付けた認証テーブル（図
５２参照）に保存する。

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

【０３９８】なお、上述したデバイス認証処理、パーテ
ィション認証処理は、他のチケット、すなわちファイル
登録チケット（ＦＲＴ：File Registration Ticket）、
サービス許可チケット（ＳＰＴ：Service Permission T
icket）、データアップデートチケット（ＤＵＴ：Data
Update Ticket）を使用したデバイスアクセスを実行す
る際にも適宜必要に応じて行われる処理である。これら
については、後段の各チケットを利用した処理の説明中
で述べる。

【０３９９】（チケットの正当性と利用者チェック）次
に、図４７のパーティションの作成、削除処理フロー中
のステップＳ４１３のデバイスにおけるチケットの正当
性と利用者チェック処理の詳細について図５７、図５８
のフローを用いて説明する。

【０４００】なお、以下に説明するチケットの正当性と
利用者チェック処理は、他のチケット、すなわちファイ
ル登録チケット（ＦＲＴ：File Registration Ticke
t）、サービス許可チケット（ＳＰＴ：Service Permiss
ion Ticket）、データアップデートチケット（ＤＵＴ：
Data Update Ticket）を使用したデバイスアクセス処理
においても適宜必要に応じて行われる処理であり、図５
７、図５８のフローは、各チケットに共通の処理フロー
として構成してある。

【０４０１】チケットの正当性と利用者チェック処理
は、デバイスとの通信を実行しているチケットユーザ
（ｅｘ．デバイスアクセス機器としてのリーダライタ、
ＰＣ等）から受信したチケットに基づいてデバイス（図
５参照）が実行する処理である。デバイスは、チケット
の正当性と利用者チェック処理においてチケットおよび
チケットユーザ（ｅｘ．デバイスアクセス機器としての
リーダライタ、ＰＣ等）である利用者の正当性を確認し
た後、チケットに記述された制限範囲内の処理を許可す
る。

【０４０２】図５７、図５８のフローを用いてチケット
の正当性と利用者チェック処理の詳細について説明す
る。チケットをチケットユーザ（ｅｘ．デバイスアクセ
ス機器としてのリーダライタ、ＰＣ等）から受信したデ
バイスは、図５７のステップＳ５１１において、チケッ
トタイプを検証しチケットがパーティション登録チケッ
ト（ＰＲＴ：Partition Registration Ticket）である
か否かを判定する。チケットタイプは、各チケットに記
録されている（図２６、図２７、図２８、図３１、図３
２参照）。

【０４０３】チケットタイプがパーティション登録チケ
ット（ＰＲＴ：Partition Registration Ticket）であ
る場合は、ステップＳ５１２〜Ｓ５１４を実行し、パー
ティション登録チケット（ＰＲＴ：Partition Registra
tion Ticket）でない場合は、ステップＳ５１５に進
む。

【０４０４】チケットタイプがパーティション登録チケ
ット（ＰＲＴ：Partition Registration Ticket）であ
る場合は、ステップＳ５１２において、チケットに記述
されたIntegrity Check Type（チケット（Ticket）の正
当性検証値の種別（公開鍵方式(Public) /共通鍵方式(C
ommon)））の設定が公開鍵方式(Public)であるか否かを
判定する。

【０４０５】正当性検証値の種別（Integrity Check Ty
pe）が公開鍵方式(Public)である場合、ステップＳ５１
３に進み、各種処理を実行する。ステップＳ５１３で実
行する処理は、まず、デバイスマネージャ対応認証局
（ＣＡ（ＤＥＶ））の公開鍵ＰＵＢ ＣＡ（ＤＥＶ）を
用いたチケット発行者（Ticket Issuer）の公開鍵証明
書（ＣＥＲＴ）の検証処理である。

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

【０４０７】公開鍵証明書（図１１参照）にはデバイス
マネージャ対応認証局（ＣＡ（ＤＥＶ））の秘密鍵で実
行された署名が付加されており、この署名をデバイスマ
ネージャ対応認証局（ＣＡ（ＤＥＶ））の公開鍵ＰＵＢ
ＣＡ（ＤＥＶ）を用いて検証する。署名生成、検証
は、例えば先に説明した図１２、図１３のフローに従っ
た処理として実行される。この署名検証により、チケッ
ト発行者の公開鍵証明書（ＣＥＲＴ）が改竄されたもの
でない正当な公開鍵証明書（ＣＥＲＴ）であるか否かが
判定される。

【０４０８】さらに、ステップＳ５１３では、署名検証
により正当性が確認されたチケット発行手段の公開鍵証
明書（ＣＥＲＴ）のオプション領域に記録されたユーザ
のカテゴリとしてのコードが、デバイス内のＤＫＤＢ
（Device Key Definition Block）(PUB)に記録されたチ
ケット発行手段コード（ＰＲＴＩＣ：PRT Issuer Cod
e）と一致するか否かを判定する。

【０４０９】公開鍵証明書には、図１１の公開鍵証明書
の説明の欄で記述したように、各チケット（ＰＲＴ，Ｆ
ＲＴ、ＳＰＴなど）の発行手段であるチケット発行手段
（Ticket Issuer）の所属コード、この場合、ＰＲＴＩ
Ｃ（PRT Issuer Code）が記録されている。このオプシ
ョン領域のコードとデバイス内のＤＫＤＢ（Device Key
Definition Block）(PUB)に記録されたチケット発行手
段コード（ＰＲＴＩＣ：PRT Issuer Code）の一致を確
認することで、受信チケット（ＰＲＴ）が正当なチケッ
ト発行手段によって発行されたチケットであることを確
認する。

【０４１０】さらに、デバイスは、デバイスのメモリ部
内のデバイス鍵領域（図１８参照）に格納されたCRL_DE
V（排除デバイス（Device）、排除機器（デバイスアク
セス機器としてのリーダライタ、ＰＣ等のチケットユー
ザ、チケット発行手段）の公開鍵証明書識別子（ｅｘ．
シリアルナンバ：ＳＮ）を登録したリボケーションリス
ト（Revocation List (Certificate)））を参照して、
チケット発行手段（Ticket Issuer）がリボークされて
いないかを判定する。

【０４１１】さらに、受信チケットであるパーティショ
ン登録チケット（ＰＲＴ）（図２６参照）に記録された
署名、すなわちIntegrity Check Value （チケット（Ti
cket）の正当性検証値（公開鍵方式：署名（Signatur
e）））の検証を実行し、チケットが改竄されていない
かを確認する。署名検証は、先の公開鍵証明書の署名検
証と同様、例えば図１３のフローと同様のシーケンスに
従って実行される。

【０４１２】以上、（１）チケット発行者（Ticket Iss
uer）の公開鍵証明書（ＣＥＲＴ）が改竄されたもので
ない正当な公開鍵証明書（ＣＥＲＴ）であること、
（２）チケット発行者（Ticket Issuer）の公開鍵証明
書（ＣＥＲＴ）のオプション領域に記録されたコード
と、デバイス内のＤＫＤＢ（Device Key Definition Bl
ock）(PUB)に記録されたチケット発行手段コード（ＰＲ
ＴＩＣ：PRT Issuer Code）の一致、（３）チケット発
行手段（Ticket Issuer）がリボークされていないこ
と、（４）受信チケット（ＰＲＴ）の署名（Signatur
e）の検証によりチケットが改竄のないことの確認。以
上のすべての確認がなされたことを条件としてチケット
の正当性検証成功とする。上記（１）〜（４）のいずれ
かが確認されない場合は、チケットの正当性の確認が得
られないと判定され、パーティション登録チケット（Ｐ
ＲＴ：Partition Registration Ticket）を利用した処
理は中止される。

【０４１３】また、ステップＳ５１２において、チケッ
トに記述されたIntegrity Check Type（チケット（Tick
et）の正当性検証値の種別（公開鍵方式(Public) /共通
鍵方式(Common)））の設定が共通鍵方式(Common)である
と判定された場合は、ステップＳ５１４に進みＭＡＣ
（Message Authentication Code）検証を実行する。デ
バイスは、デバイスのデバイス鍵領域（図１８参照）に
格納されたパーティション登録チケット（ＰＲＴ）のＭ
ＡＣ検証用鍵：Ｋｐｒｔを使用してチケットのＭＡＣ検
証処理を実行する。

【０４１４】図５９にＤＥＳ暗号処理構成を用いたＭＡ
Ｃ値生成例を示す。図５９の構成に示すように対象とな
るメッセージを８バイト単位に分割し、（以下、分割さ
れたメッセージをＭ１、Ｍ２、・・・、ＭＮとする）、
まず、初期値（Initial Value（以下、ＩＶとする））
とＭ１を排他的論理和する（その結果をＩ１とする）。
次に、Ｉ１をＤＥＳ暗号化部に入れ、ＭＡＣ検証用鍵：
Ｋｐｒｔを用いて暗号化する（出力をＥ１とする）。続
けて、Ｅ１およびＭ２を排他的論理和し、その出力Ｉ２
をＤＥＳ暗号化部へ入れ、鍵Ｋｐｒｔを用いて暗号化す
る（出力Ｅ２）。以下、これを繰り返し、全てのメッセ
ージに対して暗号化処理を施す。最後に出てきたＥＮが
メッセージ認証符号（ＭＡＣ（Message Authentication
Code））となる。なお、メッセージとしては、検証対
象となるデータを構成する部分データが使用可能であ
る。

【０４１５】改竄のないことが保証された例えばデータ
送信側がデータ生成時に生成したＩＣＶ（Integrity Ch
eck Value）と、データ受信側が受信データに基づいて
生成したＩＣＶとを比較して同一のＩＣＶが得られれば
データに改竄のないことが保証され、ＩＣＶが異なれ
ば、改竄があったと判定される。改竄のないことが保証
された例えばデータ送信側がデータ生成時に生成したＩ
ＣＶは、図２６のパーティション登録チケット（ＰＲ
Ｔ）のフォーマットに関する記述において説明したよう
に、ＰＲＴのＩＣＶ（Integrity Check Value）フィー
ルドに格納されている。デバイスが生成したＩＣＶと受
信チケット（ＰＲＴ）に格納されたＩＣＶとを比較して
一致していればチケットの正当性ありと判定し、不一致
の場合はチケット改竄ありと判定し、チケットを利用し
た処理を中止する。

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

【０４１７】図５７のフローに戻り、チケットの正当性
と利用者チェック処理について説明を続ける。ステップ
Ｓ５１１において、チケットタイプがパーティション登
録チケット（ＰＲＴ：Partition Registration Ticke
t）でないと判定された場合は、ステップＳ５１５にお
いてチケットタイプを検証しチケットがファイル登録チ
ケット（ＦＲＴ：File Registration Ticket）であるか
否かを判定する。

【０４１８】チケットタイプがファイル登録チケット
（ＦＲＴ：File Registration Ticket）である場合は、
ステップＳ５１６〜Ｓ５１８を実行し、ファイル登録チ
ケット（ＦＲＴ：File Registration Ticket）でない場
合は、ステップＳ５１９に進む。

【０４１９】チケットタイプがファイル登録チケット
（ＦＲＴ：File Registration Ticket）である場合は、
ステップＳ５１６において、チケットに記述されたInte
grityCheck Type（チケット（Ticket）の正当性検証値
の種別（公開鍵方式(Public) /共通鍵方式(Common)））
の設定が公開鍵方式(Public)であるか否かを判定する。

【０４２０】正当性検証値の種別（Integrity Check Ty
pe）が公開鍵方式(Public)である場合、ステップＳ５１
７に進み、各種処理を実行する。ステップＳ５１７で実
行する処理は、まず、パーティションマネージャ対応認
証局（ＣＡ（ＰＡＲ））の公開鍵ＰＵＢ ＣＡ（ＰＡ
Ｒ）を用いたチケット発行者（Ticket Issuer）の公開
鍵証明書（ＣＥＲＴ）の検証処理である。

【０４２１】ファイル登録チケット（ＦＲＴ）発行手段
（FRT Issuer）の発行したチケット（Ticket）を、チケ
ットユーザに対して送信する際には、公開鍵方式の場
合、ファイル登録チケット（ＦＲＴ）発行手段（FRT Is
suer）の公開鍵証明書（CERT_FRTI）も一緒にデバイス
に送信される。なお、ＦＲＴ発行手段の公開鍵証明書
（CERT_FRTI）の属性（Attribute）は、、ファイル登録
チケット（ＦＲＴ）発行手段（ＦＲＴ Issuer）の識別
子(FRTIC)と一致する。

【０４２２】公開鍵証明書（図１１参照）にはパーティ
ションマネージャ対応認証局（ＣＡ（ＰＡＲ））の秘密
鍵で実行された署名が付加されており、この署名をパー
ティションマネージャ対応認証局（ＣＡ（ＰＡＲ））の
公開鍵ＰＵＢ ＣＡ（ＰＡＲ）を用いて検証する。署名
生成、検証は、例えば先に説明した図１２、図１３のフ
ローに従った処理として実行される。この署名検証によ
り、チケット発行者の公開鍵証明書（ＣＥＲＴ）が改竄
されたものでない正当な公開鍵証明書（ＣＥＲＴ）であ
るか否かが判定される。

【０４２３】さらに、ステップＳ５１７では、署名検証
により正当性が確認されたチケット発行手段の公開鍵証
明書（ＣＥＲＴ）のオプション領域に記録されたユーザ
の所属コードと、デバイス内のＰＫＤＢ（Partition Ke
y Definition Block）(PUB)に記録されたチケット発行
手段コード（ＦＲＴＩＣ：FRT Issuer Code）と一致す
るか否かを判定する。

【０４２４】公開鍵証明書には、図１１の公開鍵証明書
の説明の欄で記述したように、各チケット（ＰＲＴ，Ｆ
ＲＴ、ＳＰＴなど）の発行手段であるチケット発行手段
（Ticket Issuer）の所属コード、この場合、ＦＲＴＩ
Ｃ（FRT Issuer Code）が記録されている。このオプシ
ョン領域のコードとデバイス内のＰＫＤＢ（PartitionK
ey Definition Block）(PUB)に記録されたチケット発行
手段コード（ＦＲＴＩＣ：FRT Issuer Code）の一致を
確認しすることで、受信チケット（ＦＲＴ）が正当なチ
ケット発行手段によって発行されたチケットであること
を確認する。

【０４２５】さらに、デバイスは、デバイスのメモリ部
内のパーティション鍵領域（図２３参照）に格納された
CRL_PAR（排除デバイス（Device）、排除機器（デバイ
スアクセス機器としてのリーダライタ、ＰＣ等のチケッ
トユーザ、チケット発行手段）の公開鍵証明書識別子
（ｅｘ．シリアルナンバ：ＳＮ）を登録したリボケーシ
ョンリスト（Revocation List (Certificate)）を参照
して、チケット発行手段（Ticket Issuer）がリボーク
されていないかを判定する。

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

【０４２７】以上、（１）チケット発行者（Ticket Iss
uer）の公開鍵証明書（ＣＥＲＴ）が改竄されたもので
ない正当な公開鍵証明書（ＣＥＲＴ）であること、
（２）チケット発行者（Ticket Issuer）の公開鍵証明
書（ＣＥＲＴ）のオプション領域に記録されたコード
と、デバイス内のＰＫＤＢ（Partition Key Definition
Block）(PUB)に記録されたチケット発行手段コード
（ＦＲＴＩＣ：FRT Issuer Code）の一致、（３）チケ
ット発行手段（Ticket Issuer）がリボークされていな
いこと、（４）受信チケット（ＦＲＴ）の署名（Signat
ure）の検証によりチケットが改竄のないことの確認。
以上のすべての確認がなされたことを条件としてファイ
ル登録チケット（ＦＲＴ）の正当性検証成功とする。上
記（１）〜（４）のいずれかが確認されない場合は、フ
ァイル登録チケット（ＦＲＴ）の正当性の確認が得られ
ないと判定され、ファイル登録チケット（ＦＲＴ）を利
用した処理は中止される。

【０４２８】また、ステップＳ５１６において、チケッ
トに記述されたIntegrity Check Type（チケット（Tick
et）の正当性検証値の種別（公開鍵方式(Public) /共通
鍵方式(Common)））の設定が共通鍵方式(Common)である
と判定された場合は、ステップＳ５１８に進みＭＡＣ
（Message Authentication Code）検証を実行する。デ
バイスは、デバイスのパーティション鍵領域（図２３参
照）に格納されたファイル登録チケット（ＦＲＴ）のＭ
ＡＣ検証用鍵：Ｋｆｒｔを使用してチケットのＭＡＣ検
証処理を実行する。ＭＡＣ検証処理は、先に説明した図
５９のＤＥＳ暗号処理構成を用いたＭＡＣ値生成処理に
従って実行される。

【０４２９】改竄のないことが保証された例えばデータ
送信側がデータ生成時に生成したＩＣＶ（Integrity Ch
eck Value）と、データ受信側が受信データに基づいて
生成したＩＣＶとを比較して同一のＩＣＶが得られれば
データに改竄のないことが保証され、ＩＣＶが異なれ
ば、改竄があったと判定される。改竄のないことが保証
された例えばデータ送信側がデータ生成時に生成したＩ
ＣＶは、図２７のファイル登録チケット（ＦＲＴ）のフ
ォーマットに関する記述において説明したように、ＦＲ
ＴのＩＣＶ（Integrity Check Value）フィールドに格
納されている。デバイスが生成したＩＣＶと受信チケッ
ト（ＦＲＴ）に格納されたＩＣＶとを比較して一致して
いればチケットの正当性ありと判定し、不一致の場合は
チケット改竄ありと判定し、チケットを利用した処理を
中止する。

【０４３０】上述の処理によってチケットに記述された
Integrity Check Typeが共通鍵方式である場合のファイ
ル登録チケット（ＦＲＴ）検証処理が完了する。

【０４３１】ステップＳ５１５において、チケットタイ
プがファイル登録チケット（ＦＲＴ：File Registratio
n Ticket）でないと判定された場合は、ステップＳ５１
９においてチケットタイプを検証しチケットがサービス
許可チケット（ＳＰＴ：Service Permission Ticket）
であるか否かを判定する。

【０４３２】チケットタイプがサービス許可チケット
（ＳＰＴ：Service Permission Ticket）である場合
は、ステップＳ５２０〜Ｓ５２２を実行し、サービス許
可チケット（ＳＰＴ：Service Permission Ticket）で
ない場合は、ステップＳ５２３に進む。

【０４３３】チケットタイプがサービス許可チケット
（ＳＰＴ：Service Permission Ticket）である場合
は、ステップＳ５２０において、チケットに記述された
IntegrityCheck Type（チケット（Ticket）の正当性検
証値の種別（公開鍵方式(Public)/共通鍵方式(Commo
n)））の設定が公開鍵方式(Public)であるか否かを判定
する。

【０４３４】正当性検証値の種別（Integrity Check Ty
pe）が公開鍵方式(Public)である場合、ステップＳ５２
１に進み、各種処理を実行する。ステップＳ５２１で実
行する処理は、まず、パーティションマネージャ対応認
証局（ＣＡ（ＰＡＲ））の公開鍵ＰＵＢ ＣＡ（ＰＡ
Ｒ）を用いたチケット発行者（Ticket Issuer）の公開
鍵証明書（ＣＥＲＴ）の検証処理である。

【０４３５】サービス許可チケット（ＳＰＴ）発行手段
（SPT Issuer）の発行したチケット（Ticket）を、チケ
ットユーザに対して送信する際には、公開鍵方式の場
合、サービス許可チケット（ＳＲＴ）発行手段（SPT Is
suer）の公開鍵証明書（CERT_SPTI）も一緒にデバイス
に送信される。なお、ＳＰＴ発行手段の公開鍵証明書
（CERT_SPTI）の属性（Attribute）は、サービス許可チ
ケット（ＳＰＴ）発行手段（SPT Issuer）の識別子(SPT
IC)と一致する。

【０４３６】公開鍵証明書（図１１参照）にはパーティ
ションマネージャ対応認証局（ＣＡ（ＰＡＲ））の秘密
鍵で実行された署名が付加されており、この署名をパー
ティションマネージャ対応認証局（ＣＡ（ＰＡＲ））の
公開鍵ＰＵＢ ＣＡ（ＰＡＲ）を用いて検証する。署名
生成、検証は、例えば先に説明した図１２、図１３のフ
ローに従った処理として実行される。この署名検証によ
り、チケット発行者の公開鍵証明書（ＣＥＲＴ）が改竄
されたものでない正当な公開鍵証明書（ＣＥＲＴ）であ
るか否かが判定される。

【０４３７】さらに、ステップＳ５２１では、署名検証
により正当性が確認されたチケット発行手段の公開鍵証
明書（ＣＥＲＴ）のオプション領域に記録されたユーザ
の所属コードと、デバイス内のファイル定義ブロック
（ＦＤＢ：File Definition Block）に記録されたチケ
ット発行手段コード（ＳＰＴＩＣ：SPT Issuer Code）
と一致するか否かを判定する。

【０４３８】公開鍵証明書には、図１１の公開鍵証明書
の説明の欄で記述したように、各チケット（ＰＲＴ，Ｆ
ＲＴ、ＳＰＴなど）の発行手段であるチケット発行手段
（Ticket Issuer）の所属コード、この場合、ＳＰＴＩ
Ｃ（SPT Issuer Code）が記録されている。このオプシ
ョン領域のコードとデバイス内のＦＤＢ（File Definit
ion Block）に記録されたチケット発行手段コード（Ｓ
ＰＴＩＣ：SPT Issuer Code）の一致を確認しすること
で、受信チケット（ＳＰＴ）が正当なチケット発行手段
によって発行されたチケットであることを確認する。

【０４３９】さらに、デバイスは、デバイスのメモリ部
内のパーティション鍵領域（図２３参照）に格納された
CRL_PAR（排除デバイス（Device）、排除機器（デバイ
スアクセス機器としてのリーダライタ、ＰＣ等のチケッ
トユーザ、チケット発行手段）の公開鍵証明書識別子
（ｅｘ．シリアルナンバ：ＳＮ）を登録したリボケーシ
ョンリスト（Revocation List (Certificate)））を参
照して、チケット発行手段（Ticket Issuer）がリボー
クされていないかを判定する。

【０４４０】さらに、受信チケットであるサービス許可
チケット（ＳＰＴ）（図２８、図３１参照）に記録され
た署名、すなわちIntegrity Check Value （チケット
（Ticket）の正当性検証値（公開鍵方式：署名（Signat
ure））の検証を実行し、チケットが改竄されていない
かを確認する。署名検証は、先の公開鍵証明書の署名検
証と同様、例えば図１３のフローと同様のシーケンスに
従って実行される。

【０４４１】以上、（１）チケット発行者（Ticket Iss
uer）の公開鍵証明書（ＣＥＲＴ）が改竄されたもので
ない正当な公開鍵証明書（ＣＥＲＴ）であること、
（２）チケット発行者（Ticket Issuer）の公開鍵証明
書（ＣＥＲＴ）のオプション領域に記録されたコード
と、デバイス内のＦＤＢ（File Definition Block）に
記録されたチケット発行手段コード（ＳＰＴＩＣ：SPT
Issuer Code）の一致、（３）チケット発行手段（Ticke
t Issuer）がリボークされていないこと、（４）受信チ
ケット（ＳＰＴ）の署名（Signature）の検証によりチ
ケットが改竄のないことの確認。以上のすべての確認が
なされたことを条件としてサービス許可チケット（ＳＰ
Ｔ）の正当性検証成功とする。上記（１）〜（４）のい
ずれかが確認されない場合は、サービス許可チケット
（ＳＰＴ）の正当性の確認が得られないと判定され、サ
ービス許可チケット（ＳＰＴ）を利用した処理は中止さ
れる。

【０４４２】また、ステップＳ５２０において、チケッ
トに記述されたIntegrity Check Type（チケット（Tick
et）の正当性検証値の種別（公開鍵方式(Public) /共通
鍵方式(Common)））の設定が共通鍵方式(Common)である
と判定された場合は、ステップＳ５２２に進みＭＡＣ
（Message Authentication Code）検証を実行する。デ
バイスは、デバイスのファイル定義ブロック（図２４参
照）に格納されたサービス許可チケット（ＳＰＴ）のＭ
ＡＣ検証用鍵：Ｋｓｐｔを使用してチケットのＭＡＣ検
証処理を実行する。ＭＡＣ検証処理は、先に説明した図
５９のＤＥＳ暗号処理構成を用いたＭＡＣ値生成処理に
従って実行される。

【０４４３】改竄のないことが保証された例えばデータ
送信側がデータ生成時に生成したＩＣＶ（Integrity Ch
eck Value）と、データ受信側が受信データに基づいて
生成したＩＣＶとを比較して同一のＩＣＶが得られれば
データに改竄のないことが保証され、ＩＣＶが異なれ
ば、改竄があったと判定される。改竄のないことが保証
された例えばデータ送信側がデータ生成時に生成したＩ
ＣＶは、図２８、図３１のサービス許可チケット（ＳＰ
Ｔ）のフォーマットに関する記述において説明したよう
に、ＳＰＴのＩＣＶ（Integrity Check Value）フィー
ルドに格納されている。デバイスが生成したＩＣＶと受
信チケット（ＳＰＴ）に格納されたＩＣＶとを比較して
一致していればチケットの正当性ありと判定し、不一致
の場合はチケット改竄ありと判定し、サービス許可チケ
ット（ＳＰＴ）を利用した処理を中止する。

【０４４４】上述の処理によってサービス許可チケット
（ＳＰＴ）に記述されたIntegrityCheck Typeが共通鍵
方式である場合のサービス許可チケット（ＳＰＴ）検証
処理が完了する。

【０４４５】ステップＳ５１９において、チケットタイ
プがサービス許可チケット（ＳＰＴ：Service Permissi
on Ticket）でないと判定された場合は、ステップＳ５
２３においてチケットタイプを検証しチケットがデータ
アップデートチケット-ＤＥＶ（ＤＵＴ：Data Update T
icket(DEV)）(図３２参照)であるか否かを判定する。デ
ータアップデートチケット（ＤＵＴ）は前述したように
デバイスのメモリ部に格納された各種データの更新処理
を実行する際のアクセス許可チケットであり、デバイス
マネージャの管理データを更新する処理に適用するデー
タアップデートチケット-ＤＥＶ（ＤＵＴ（ＤＥＶ））
とパーティションマネージャの管理データを更新する処
理に適用するデータアップデートチケット-ＰＡＲ（Ｄ
ＵＴ（ＰＡＲ））とがある。

【０４４６】チケットタイプがデータアップデートチケ
ット-ＤＥＶ（ＤＵＴ（ＤＥＶ））である場合は、ステ
ップＳ５２４〜Ｓ５２８を実行し、データアップデート
チケット（ＤＥＶ）（ＤＵＴ：Data Update Ticket(DE
V)）でない場合は、ステップＳ５２９に進む。

【０４４７】チケットタイプがデータアップデートチケ
ット-ＤＥＶ（ＤＵＴ（ＤＥＶ））である場合は、ステ
ップＳ５２４において、チケットに記述されたIntegrit
y Check Type（チケット（Ticket）の正当性検証値の種
別（公開鍵方式(Public) /共通鍵方式(Common)））の設
定が公開鍵方式(Public)であるか否かを判定する。

【０４４８】正当性検証値の種別（Integrity Check Ty
pe）が公開鍵方式(Public)である場合、ステップＳ５２
５に進み、各種処理を実行する。ステップＳ５２５で実
行する処理は、まず、デバイスマネージャ対応認証局
（ＣＡ（ＤＥＶ））の公開鍵ＰＵＢ ＣＡ（ＤＥＶ）を
用いたチケット発行者（Ticket Issuer）の公開鍵証明
書（ＣＥＲＴ）の検証処理である。

【０４４９】データアップデートチケット-ＤＥＶ（Ｄ
ＵＴ（ＤＥＶ））発行手段（DUT Issuer）の発行したチ
ケット（Ticket）を、チケットユーザに対して送信する
際には、公開鍵方式の場合、データアップデートチケッ
ト（ＤＵＴ）発行手段（DUTIssuer）の公開鍵証明書（C
ERT_DUTI）も一緒にデバイスに送信される。なお、ＤＵ
Ｔ発行手段の公開鍵証明書（CERT_DUTI）の属性（Attri
bute）は、デバイス内のＤＫＤＢ（ＰＵＢ）（Device K
ey Definition Block）(PUB)に記録されたチケット発行
手段コード（DUTIC＿DEV）の識別子(DUTIC)と一致す
る。

【０４５０】公開鍵証明書（図１１参照）にはデバイス
マネージャ対応認証局（ＣＡ（ＤＥＶ））の秘密鍵で実
行された署名が付加されており、この署名をデバイスマ
ネージャ対応認証局（ＣＡ（ＤＥＶ））の公開鍵ＰＵＢ
ＣＡ（ＤＥＶ）を用いて検証する。署名生成、検証
は、例えば先に説明した図１２、図１３のフローに従っ
た処理として実行される。この署名検証により、チケッ
ト発行者の公開鍵証明書（ＣＥＲＴ）が改竄されたもの
ではない正当な公開鍵証明書（ＣＥＲＴ）であるか否か
が判定される。

【０４５１】さらに、ステップＳ５２５では、署名検証
により正当性が確認されたチケット発行手段の公開鍵証
明書（ＣＥＲＴ）のオプション領域に記録されたユーザ
の所属コードと、デバイス内のＤＫＤＢ（ＰＵＢ）（De
vice Key Definition Block）(PUB)に記録されたチケッ
ト発行手段コード（DUTIC＿DEV：DUT Issuer Category
for Device）と一致するか否かを判定する。

【０４５２】公開鍵証明書には、図１１の公開鍵証明書
の説明の欄で記述したように、各チケット（ＰＲＴ，Ｆ
ＲＴ、ＳＰＴ、ＤＵＴ）の発行手段であるチケット発行
手段（Ticket Issuer）の所属コード、この場合、ＤＵ
ＴＩＣ（DUT Issuer Code）が記録されている。このオ
プション領域のコードとデバイス内のＤＫＤＢ（ＰＵ
Ｂ）（Device Key Definition Block）(PUB)に記録され
たチケット発行手段コード（DUTIC＿DEV：DUT Issuer C
ategory for Device）(図１６参照)の一致を確認するこ
とで、受信チケット（ＤＵＴ）が正当なチケット発行手
段によって発行されたチケットであることを確認する。

【０４５３】さらに、デバイスは、デバイスのメモリ部
内のデバイス鍵領域（図１８参照）に格納されたCRL_DE
V（排除デバイス（Device）、排除機器（デバイスアク
セス機器としてのリーダライタ、ＰＣ等のチケットユー
ザ、チケット発行手段）の公開鍵証明書識別子（ｅｘ．
シリアルナンバ：ＳＮ）を登録したリボケーションリス
ト（Revocation List (Certificate)））を参照して、
チケット発行手段（Ticket Issuer）がリボークされて
いないかを判定する。

【０４５４】さらに、受信チケットであるデータアップ
デートチケット-ＤＥＶ（ＤＵＴ（ＤＥＶ））（図３２
参照）に記録された署名、すなわちIntegrity Check Va
lue（チケット（Ticket）の正当性検証値（公開鍵方
式：署名（Signature））の検証を実行し、チケットが
改竄されていないかを確認する。署名検証は、先の公開
鍵証明書の署名検証と同様、例えば図１３のフローと同
様のシーケンスに従って実行される。

【０４５５】以上、（１）チケット発行者（Ticket Iss
uer）の公開鍵証明書（ＣＥＲＴ）が改竄されたもので
ない正当な公開鍵証明書（ＣＥＲＴ）であること、
（２）チケット発行者（Ticket Issuer）の公開鍵証明
書（ＣＥＲＴ）のオプション領域に記録されたコード
と、デバイス内のＤＫＤＢ（ＰＵＢ）（Device Key Def
inition Block）(PUB)に記録されたチケット発行手段コ
ード（DUTIC＿DEV：DUT Issuer Category for Device）
の一致、（３）チケット発行手段（Ticket Issuer）が
リボークされていないこと、（４）受信チケット（ＤＵ
Ｔ）の署名（Signature）の検証によりチケットが改竄
のないことの確認。以上のすべての確認がなされたこと
を条件としてデータアップデートチケット-ＤＥＶ（Ｄ
ＵＴ（ＤＥＶ））の正当性検証成功とする。上記（１）
〜（４）のいずれかが確認されない場合は、データアッ
プデートチケット-ＤＥＶ（ＤＵＴ（ＤＥＶ））の正当
性の確認が得られないと判定され、データアップデート
チケット-ＤＥＶ（ＤＵＴ（ＤＥＶ））を利用した処理
は中止される。

【０４５６】また、ステップＳ５２４において、チケッ
トに記述されたIntegrity Check Type（チケット（Tick
et）の正当性検証値の種別（公開鍵方式(Public) /共通
鍵方式(Common)））の設定が共通鍵方式(Common)である
と判定された場合は、ステップＳ５２６において、デー
タアップデートチケット-ＤＥＶ（ＤＵＴ（ＤＥＶ））
に記述されたOld Data Codeの示すデータがデバイス鍵
領域（図１８参照）に格納されたKdut_DEV1（データア
ップデートチケット（ＤＵＴ）のＭＡＣ検証用鍵）また
は、Kdut_DEV2（データ更新用暗号鍵）であるか否かを
判定する。

【０４５７】データアップデートチケット-ＤＥＶ（Ｄ
ＵＴ（ＤＥＶ））に記述されたOld Data Code（更新さ
れる古いデータのコード）の示すデータがデバイス鍵領
域（図１８参照）に格納されたKdut_DEV1（データアッ
プデートチケット（ＤＵＴ）のＭＡＣ検証用鍵）また
は、Kdut_DEV2（データ更新用暗号鍵）である場合は、
ステップＳ５２８において、デバイス鍵領域（図１８参
照）に格納されたKdut_DEV3（データアップデートチケ
ット（ＤＵＴ）のＭＡＣ検証用鍵）を用いてＭＡＣ検証
処理を実行し、データアップデートチケット-ＤＥＶ
（ＤＵＴ（ＤＥＶ））に記述されたOld Data Code（更
新される古いデータのコード）の示すデータがデバイス
鍵領域（図１８参照）に格納されたKdut_DEV1（データ
アップデートチケット（ＤＵＴ）のＭＡＣ検証用鍵）ま
たは、Kdut_DEV2（データ更新用暗号鍵）でない場合
は、ステップＳ５２７において、デバイス鍵領域（図１
８参照）に格納されたKdut_DEV1（データアップデート
チケット（ＤＵＴ）のＭＡＣ検証用鍵）を用いてＭＡＣ
検証処理を実行する。

【０４５８】上述のようにＭＡＣ検証鍵の使い分けを実
行するのは、更新対象となっているデータが、Kdut_DEV
1（データアップデートチケット（ＤＵＴ）のＭＡＣ検
証用鍵）または、Kdut_DEV2（データ更新用暗号鍵）で
ある場合は、これらの鍵データが何らかの理由、例えば
鍵情報の漏洩等により、使用を停止される予定の情報で
あるため、これらの更新対象データを用いたＭＡＣ検証
を避けるためである。ＭＡＣ検証処理は、先に説明した
図５９のＤＥＳ暗号処理構成を用いたＭＡＣ値生成処理
に従って実行される。

【０４５９】なお、デバイスは、デバイスのデバイス鍵
領域（図１８参照）に新規にKdut_DEV1（データアップ
デートチケット（ＤＵＴ）のＭＡＣ検証用鍵）を格納す
る場合、以前に格納済みのKdut_DEV3（データアップデ
ートチケット（ＤＵＴ）のＭＡＣ検証用鍵）とのスワッ
プ、すなわち入れ替え処理を行なう。さらに、新規にKd
ut_DEV2（データ更新用暗号鍵）を格納する場合も、以
前に格納済みのKdut_DEV4（データ更新用暗号鍵）との
スワップ、すなわち入れ替え処理を行なう。

【０４６０】この、Kdut_DEV1と、Kdut_DEV3とのスワッ
プ、および、Kdut_DEV2と、Kdut_DEV4とのスワップ処理
によって、常にKdut_DEV3（データアップデートチケッ
ト（ＤＵＴ）のＭＡＣ検証用鍵）、Kdut_DEV4（データ
更新用暗号鍵）のペアがKdut_DEV1（データアップデー
トチケット（ＤＵＴ）のＭＡＣ検証用鍵）、Kdut_DEV2
（データ更新用暗号鍵）のペアよりも新しいバージョン
のものに維持される。つまり、Kdut_DEV1と、Kdut_DEV2
の鍵は常に使用される鍵で、Kdut_DEV3と、Kdut_DEV4
は、非常時にKdut_DEV1と、Kdut_DEV2を更新するととも
に、現在使用されているKdut_DEV1と、Kdut_DEV2の鍵に
置き換えられるバックアップ用の鍵としての役割があ
る。なお、これらの処理については、後段のデータアッ
プデートチケット（ＤＵＴ）を用いたデータ更新処理の
説明において、さらに説明する。

【０４６１】改竄のないことが保証された例えばデータ
送信側がデータ生成時に生成したＩＣＶ（Integrity Ch
eck Value）と、データ受信側が受信データに基づいて
生成したＩＣＶとを比較して同一のＩＣＶが得られれば
データに改竄のないことが保証され、ＩＣＶが異なれ
ば、改竄があったと判定される。改竄のないことが保証
された例えばデータ送信側がデータ生成時に生成したＩ
ＣＶは、図３２のデータアップデートチケット（ＤＵ
Ｔ）のフォーマットに関する記述において説明したよう
に、データアップデートチケット（ＤＵＴ）のＩＣＶ
（Integrity Check Value）フィールドに格納されてい
る。

【０４６２】デバイスが生成したＩＣＶと受信チケット
であるデータアップデートチケット-ＤＥＶ（ＤＵＴ
（ＤＥＶ））に格納されたＩＣＶとを比較して一致して
いればチケットの正当性ありと判定し、不一致の場合は
チケット改竄ありと判定し、データアップデートチケッ
ト-ＤＥＶ（ＤＵＴ（ＤＥＶ））を利用した処理を中止
する。

【０４６３】上述の処理によってデータアップデートチ
ケット-ＤＥＶ（ＤＵＴ（ＤＥＶ））に記述されたInteg
rity Check Typeが共通鍵方式である場合のデータアッ
プデートチケット-ＤＥＶ（ＤＵＴ（ＤＥＶ））検証処
理が完了する。

【０４６４】ステップＳ５２３において、チケットタイ
プがデータアップデートチケット-ＤＥＶ（ＤＵＴ（Ｄ
ＥＶ））でないと判定された場合は、チケットは、デー
タアップデートチケット-ＰＡＲ（ＤＵＴ（ＰＡＲ））
(図３２参照)）であると判定される。データアップデー
トチケット-ＰＡＲ（ＤＵＴ（ＰＡＲ））は、パーティ
ションマネージャの管理データを更新する処理に適用す
るチケットである。

【０４６５】この場合、ステップＳ５２９において、チ
ケットに記述されたIntegrity Check Type（チケット
（Ticket）の正当性検証値の種別（公開鍵方式(Public)
/共通鍵方式(Common)））の設定が公開鍵方式(Public)
であるか否かを判定する。

【０４６６】正当性検証値の種別（Integrity Check Ty
pe）が公開鍵方式(Public)である場合、ステップＳ５３
０に進み、各種処理を実行する。ステップＳ５３０で実
行する処理は、まず、パーティションマネージャ対応認
証局（ＣＡ（ＰＡＲ））の公開鍵ＰＵＢ ＣＡ（ＰＡ
Ｒ）を用いたチケット発行者（Ticket Issuer）の公開
鍵証明書（ＣＥＲＴ）の検証処理である。

【０４６７】データアップデートチケット-ＰＡＲ（Ｄ
ＵＴ（ＰＡＲ））発行手段（DUT Issuer）の発行したチ
ケット（Ticket）を、チケットユーザに対して送信する
際には、公開鍵方式の場合、データアップデートチケッ
ト（ＤＵＴ）発行手段（DUTIssuer）の公開鍵証明書（C
ERT_DUTI）も一緒にデバイスに送信される。なお、ＤＵ
Ｔ発行手段の公開鍵証明書（CERT_DUTI）の属性（Attri
bute）は、デバイス内のＰＫＤＢ（ＰＵＢ）（Pqrtitio
n Key Definition block）に記録されたチケット発行手
段コード(DUTIC_PAR)と一致する。

【０４６８】公開鍵証明書（図１１参照）にはパーティ
ションマネージャ対応認証局（ＣＡ（ＰＡＲ））の秘密
鍵で実行された署名が付加されており、この署名をパー
ティションマネージャ対応認証局（ＣＡ（ＰＡＲ））の
公開鍵ＰＵＢ ＣＡ（ＰＡＲ）を用いて検証する。署名
生成、検証は、例えば先に説明した図１２、図１３のフ
ローに従った処理として実行される。この署名検証によ
り、チケット発行者の公開鍵証明書（ＣＥＲＴ）が改竄
されたものでない正当な公開鍵証明書（ＣＥＲＴ）であ
るか否かが判定される。

【０４６９】さらに、ステップＳ５３０では、署名検証
により正当性が確認されたチケット発行手段の公開鍵証
明書（ＣＥＲＴ）のオプション領域に記録されたユーザ
の所属コードと、デバイス内のＰＫＤＢ（ＰＵＢ）（Pq
rtition Key Definition block）に記録されたチケット
発行手段コード(DUTIC_PAR:DUT Issuer Category forPa
rtition)と一致するか否かを判定する。

【０４７０】公開鍵証明書には、図１１の公開鍵証明書
の説明の欄で記述したように、各チケット（ＰＲＴ，Ｆ
ＲＴ、ＳＰＴ、ＤＵＴ）の発行手段であるチケット発行
手段（Ticket Issuer）の所属コード、この場合、ＤＵ
ＴＩＣ（DUT Issuer Code）が記録されている。このオ
プション領域のコードとデバイス内のＰＫＤＢ（ＰＵ
Ｂ）（Pqrtition Key Definition block）に記録された
チケット発行手段コード(DUTIC:DUT Issuer Category)
(図２１参照)の一致を確認しすることで、受信チケット
（ＤＵＴ）が正当なチケット発行手段によって発行され
たチケットであることを確認する。

【０４７１】さらに、デバイスは、デバイスのメモリ部
内のデバイス鍵領域（図１８参照）に格納されたCRL_DE
V（排除デバイス（Device）、排除機器（デバイスアク
セス機器としてのリーダライタ、ＰＣ等のチケットユー
ザ、チケット発行手段）の公開鍵証明書識別子（ｅｘ．
シリアルナンバ：ＳＮ）を登録したリボケーションリス
ト（Revocation List (Certificate)））を参照して、
チケット発行手段（Ticket Issuer）がリボークされて
いないかを判定する。

【０４７２】さらに、受信チケットであるデータアップ
デートチケット-ＰＡＲ（ＤＵＴ（ＰＡＲ））（図３２
参照）に記録された署名、すなわちIntegrity Check Va
lue（チケット（Ticket）の正当性検証値（公開鍵方
式：署名（Signature））の検証を実行し、チケットが
改竄されていないかを確認する。署名検証は、先の公開
鍵証明書の署名検証と同様、例えば図１３のフローと同
様のシーケンスに従って実行される。

【０４７３】以上、（１）チケット発行者（Ticket Iss
uer）の公開鍵証明書（ＣＥＲＴ）が改竄されたもので
ない正当な公開鍵証明書（ＣＥＲＴ）であること、
（２）チケット発行者（Ticket Issuer）の公開鍵証明
書（ＣＥＲＴ）のオプション領域に記録されたコード
と、デバイス内のＰＫＤＢ（ＰＵＢ）（Pqrtition Key
Definition block）に記録されたチケット発行手段コー
ド(DUTIC_PAR:DUT Issuer Category for Partition)の
一致、（３）チケット発行手段（Ticket Issuer）がリ
ボークされていないこと、（４）受信チケット（ＤＵ
Ｔ）の署名（Signature）の検証によりチケットが改竄
のないことの確認。以上のすべての確認がなされたこと
を条件としてデータアップデートチケット-ＰＡＲ（Ｄ
ＵＴ）の正当性検証成功とする。上記（１）〜（４）の
いずれかが確認されない場合は、データアップデートチ
ケット-ＰＡＲ（ＤＵＴ（ＰＡＲ））の正当性の確認が
得られないと判定され、データアップデートチケット-
ＰＡＲ（ＤＵＴ（ＰＡＲ））を利用した処理は中止され
る。

【０４７４】また、ステップＳ５２９において、チケッ
トに記述されたIntegrity Check Type（チケット（Tick
et）の正当性検証値の種別（公開鍵方式(Public) /共通
鍵方式(Common)））の設定が共通鍵方式(Common)である
と判定された場合は、ステップＳ５３１において、デー
タアップデートチケット-ＰＡＲ（ＤＵＴ（ＰＡＲ））
に記述されたOld Data Code（更新される古いデータの
コード）の示すデータがパーティション鍵領域（図２３
参照）に格納されたKdut_PAR1（データアップデートチ
ケット（ＤＵＴ）のＭＡＣ検証用鍵）または、Kdut_PAR
2（データ更新用暗号鍵）であるか否かを判定する。

【０４７５】データアップデートチケット-ＰＡＲ（Ｄ
ＵＴ（ＰＡＲ））に記述されたOld Data Code（更新さ
れる古いデータのコード）の示すデータがパーティショ
ン鍵領域（図２３参照）に格納されたKdut_PAR1（デー
タアップデートチケット（ＤＵＴ）のＭＡＣ検証用鍵）
または、Kdut_PAR2（データ更新用暗号鍵）である場合
は、ステップＳ５３３において、パーティション鍵領域
（図２３参照）に格納されたKdut_PAR3（データアップ
デートチケット（ＤＵＴ）のＭＡＣ検証用鍵）を用いて
ＭＡＣ検証処理を実行し、データアップデートチケット
-ＰＡＲ（ＤＵＴ（ＰＡＲ））に記述されたOld Data Co
de（更新される古いデータのコード）の示すデータがパ
ーティション鍵領域（図２３参照）に格納されたKdut_P
AR1（データアップデートチケット（ＤＵＴ）のＭＡＣ
検証用鍵）または、Kdut_PAR2（データ更新用暗号鍵）
でない場合は、ステップＳ５３２において、パーティシ
ョン鍵領域（図２３参照）に格納されたKdut_PAR1（デ
ータアップデートチケット（ＤＵＴ）のＭＡＣ検証用
鍵）を用いてＭＡＣ検証処理を実行する。

【０４７６】上述のようにＭＡＣ検証鍵の使い分けを実
行するのは、更新対象となっているデータが、Kdut_PAR
1（データアップデートチケット（ＤＵＴ）のＭＡＣ検
証用鍵）または、Kdut_PAR2（データ更新用暗号鍵）で
ある場合は、これらの鍵データが何らかの理由、例えば
鍵情報の漏洩等により、使用を停止される予定の情報で
あるため、これらの更新対象データを用いたＭＡＣ検証
を避けるためである。ＭＡＣ検証処理は、先に説明した
図５９のＤＥＳ暗号処理構成を用いたＭＡＣ値生成処理
に従って実行される。

【０４７７】改竄のないことが保証された例えばデータ
送信側がデータ生成時に生成したＩＣＶ（Integrity Ch
eck Value）と、データ受信側が受信データに基づいて
生成したＩＣＶとを比較して同一のＩＣＶが得られれば
データに改竄のないことが保証され、ＩＣＶが異なれ
ば、改竄があったと判定される。改竄のないことが保証
された例えばデータ送信側がデータ生成時に生成したＩ
ＣＶは、図３２のデータアップデートチケット（ＤＵ
Ｔ）のフォーマットに関する記述において説明したよう
に、データアップデートチケット（ＤＵＴ）のＩＣＶ
（Integrity Check Value）フィールドに格納されてい
る。

【０４７８】デバイスが生成したＩＣＶと受信チケット
であるデータアップデートチケット-ＰＡＲ（ＤＵＴ
（ＰＡＲ））に格納されたＩＣＶとを比較して一致して
いればチケットの正当性ありと判定し、不一致の場合は
チケット改竄ありと判定し、データアップデートチケッ
ト-ＰＡＲ（ＤＵＴ（ＰＡＲ））を利用した処理を中止
する。

【０４７９】上述の処理によってデータアップデートチ
ケット-ＰＡＲ（ＤＵＴ（ＰＡＲ））に記述されたInteg
rity Check Typeが共通鍵方式である場合のデータアッ
プデートチケット-ＰＡＲ（ＤＵＴ（ＰＡＲ））検証処
理が完了する。

【０４８０】以上の処理においてチケットの正当性が確
認された後、図５８のステップＳ５４１に進み、以下、
利用者チェック、すなわちチケットユーザとしてデバイ
スとの通信を実行中のデバイスアクセス機器としてのリ
ーダライタ（またはＰＣ等）のチェックを実行する。

【０４８１】ステップＳ５４１において、デバイスは、
受信チケット（ＰＲＴ，ＦＲＴ，ＳＰＴ，またはＤＵ
Ｔ）のAuthentication Flag（チケット（Ticket）の利
用処理においてデバイス（Device）との相互認証が必要
か否かを示すフラグ）をチェックする。フラグが認証不
要を示している場合は、処理を実行することなく終了す
る。

【０４８２】ステップＳ５４１におけるフラグチェック
処理において、フラグが認証必要を示している場合は、
ステップＳ５４２に進み、チケットユーザ（デバイスに
対するチケットを適用した処理を実行しようとするデバ
イスアクセス機器としてのリーダライタ、ＰＣ等）の所
属（グループ）をキーとして認証テーブル（図５１参
照）を参照する。

【０４８３】次に、ステップＳ５４３において、受信チ
ケットのAuthentication Type（デバイス（Device）の
相互認証のタイプ（公開鍵認証、または、共通鍵認証、
または、いずれでも可（Any））を記録したデータ）を
チェックし、いずれでも可（Any）である場合、ステッ
プＳ５４４に進み、ステップＳ５４２でチェックしたグ
ループの相互認証データが認証テーブル（図５１参照）
に格納されているか否かを判定する。テーブルに対応グ
ループの相互認証情報が格納され、チケットユーザ（デ
バイスに対するチケットを適用した処理を実行しようと
するデバイスアクセス機器としてのリーダライタ、ＰＣ
等）とデバイス間の相互認証済みであることが判定され
れば、チケット利用者（ｅｘ．デバイスアクセス機器と
してのリーダライタ）の正当性が確認されたものとして
処理を利用者チェック成功と判定して終了する。認証テ
ーブル（図５１参照）に対応グループの相互認証情報が
格納されていない場合は、利用者チェックが未了である
と判定され、エラー終了とする。

【０４８４】ステップＳ５４３において、受信チケット
のAuthentication Type（デバイス（Device）の相互認
証のタイプ（公開鍵認証、または、共通鍵認証、また
は、いずれでも可（Any））を記録したデータ）がいず
れでも可（Any）でない場合、ステップ５４５におい
て、Authentication Typeが公開鍵認証であるか否かを
判定する。

【０４８５】Authentication Typeが公開鍵認証である
場合、ステップＳ５４６に進み、ステップＳ５４２でチ
ェックしたグループの公開鍵相互認証データが認証テー
ブル（図５１参照）に格納されているか否かを判定す
る。テーブルに対応グループの公開鍵相互認証情報が格
納され、チケットユーザ（デバイスに対するチケットを
適用した処理を実行しようとするデバイスアクセス機器
としてのリーダライタ、ＰＣ等）とデバイス間の相互認
証が公開鍵認証処理として成立済みであることが判定さ
れた場合は、ステップＳ５４７に進み、処理対象チケッ
ト（ＰＲＴ，ＦＲＴ，ＳＰＴまたはＤＵＴ）にチケット
ユーザの識別子が存在するか否かを判定して存在する場
合は、ステップＳ５４８において認証相手（チケットユ
ーザであるデバイスアクセス機器としてのリーダライタ
など）の公開鍵証明書中の識別データ（ＤＮ）として記
録された識別子またはカテゴリまたはシリアル（ＳＮ）
とチケットに格納されたチケットユーザの識別データと
して記録された識別子またはカテゴリまたはシリアル
（ＳＮ）が一致するか否かを判定する。一致する場合
は、利用者確認成功として処理を終了する。

【０４８６】ステップＳ５４６において、ステップＳ５
４２でチェックしたグループの公開鍵相互認証データが
認証テーブル（図５１参照）に格納されておらず、チケ
ットユーザ（デバイスに対するチケットを適用した処理
を実行しようとするデバイスアクセス機器としてのリー
ダライタ、ＰＣ等）とデバイス間の相互認証が公開鍵認
証処理として成立済みでないと判定された場合は、利用
者チェック未了と判定されエラー終了する。

【０４８７】また、ステップＳ５４８において認証相手
（チケットユーザであるデバイスアクセス機器としての
リーダライタなど）の公開鍵証明書中の識別データ（Ｄ
Ｎ）として記録された識別子またはカテゴリまたはシリ
アル（ＳＮ）とチケットに格納されたチケットユーザの
識別子が一致しないと判定された場合も利用者チェック
未了と判定されエラー終了する。

【０４８８】なお、チケットにチケットユーザの識別子
が存在しない場合は、ステップＳ５４８の処理は実行せ
ず、利用者確認成功として処理を終了する。

【０４８９】ステップＳ５４５において、受信チケット
のAuthentication Type（デバイス（Device）の相互認
証のタイプ（公開鍵認証、または、共通鍵認証、また
は、いずれでも可（Any））を記録したデータ）が公開
鍵認証でないと判定された場合、ステップＳ５４９に進
み、ステップＳ５４２でチェックしたグループの共通鍵
相互認証データが認証テーブル（図５１参照）に格納さ
れているか否かを判定する。テーブルに対応グループの
共通鍵相互認証情報が格納され、チケットユーザ（デバ
イスに対するチケットを適用した処理を実行しようとす
るデバイスアクセス機器としてのリーダライタ、ＰＣ
等）とデバイス間の相互認証が共通鍵認証処理として成
立済みであることが判定された場合は、ステップＳ５５
０に進み、処理対象チケット（ＰＲＴ，ＦＲＴ，ＳＰＴ
またはＤＵＴ）にチケットユーザの識別子が存在するか
否かを判定して存在する場合は、ステップＳ５５１にお
いて認証相手（チケットユーザであるデバイスアクセス
機器としてのリーダライタなど）の識別データ（ＩＤｒ
ｗ）とチケットに格納されたチケットユーザの識別子が
一致するか否かを判定する。一致する場合は、利用者確
認成功として処理を終了する。

【０４９０】ステップＳ５４９において、ステップＳ５
４２でチェックしたグループの共通鍵相互認証データが
認証テーブル（図５１参照）に格納されておらず、チケ
ットユーザ（デバイスに対するチケットを適用した処理
を実行しようとするデバイスアクセス機器としてのリー
ダライタ、ＰＣ等）とデバイス間の相互認証が共通鍵認
証処理として成立済みでないと判定された場合は、利用
者チェック未了と判定されエラー終了する。

【０４９１】また、ステップＳ５５１において認証相手
（チケットユーザであるデバイスアクセス機器としての
リーダライタなど）の識別データ（ＩＤｒｗ）とチケッ
トに格納されたチケットユーザの識別子が一致しないと
判定された場合も利用者チェック未了と判定されエラー
終了する。

【０４９２】なお、チケットにチケットユーザの識別子
が存在しないか、すべてのチケットユーザが利用可能の
場合は、ステップＳ５５０の処理は実行せず、利用者確
認成功として処理を終了する。

【０４９３】以上が、図４７のフロー中のステップＳ４
１３においてデバイスが実行するチケットの正当性およ
び利用者チェック処理である。

【０４９４】（パーティション作成削除処理）次に、図
４７のフローに示すステップＳ４１５において実行され
るパーティション登録チケット（ＰＲＴ）に基づくパー
ティションの生成、削除処理の詳細について、図６０、
図６１の処理フローを用いて説明する。パーティション
の作成、削除処理は、チケットユーザ（ｅｘ．デバイス
アクセス機器としてのリーダライタ、ＰＣ等）からパー
ティション登録チケット（ＰＲＴ）を受信したデバイス
が、パーティション登録チケット（ＰＲＴ）に基づいて
実行する処理である。

【０４９５】図６０のステップＳ６０１において、デバ
イスは、受信したパーティション登録チケット（ＰＲ
Ｔ:Partition Registration ticket）に記録された処理
タイプ、すなわちOperation Type（パーティション（Pa
rtition）作成か削除かの指定(作成（Generate） / 削
除（Delete)））を検証する。処理タイプ（Operation T
ype）が、パーティション（Partition）作成である場
合、ステップＳ６０２以下を実行し、パーティション
（Partition）削除である場合、ステップＳ６２１以下
を実行する。

【０４９６】まず、パーティション作成処理について説
明する。デバイスはステップＳ６０２において、パーテ
ィション登録チケット（ＰＲＴ）に記述されたパーティ
ションマネージャコード（ＰＭＣ）と同一コードのパー
ティションがデバイスのメモリ部に存在するか否かを検
証する。この判定は、デバイスのメモリ部のパーティシ
ョン定義ブロック（図１９参照）に受信チケット（ＰＲ
Ｔ）の記述コードと同一のコードが記述されているか否
かを検証することによって判定可能である。

【０４９７】すでにデバイスに同一コード（ＰＭＣ）の
パーティションが存在する場合は、同一コードを持つ重
複パーティションの存在は許されず、パーティションの
生成は実行せず、エラー終了とする。同一コードのパー
ティションがデバイスに存在しない場合は、ステップＳ
６０３において、デバイス管理情報ブロック（図１５参
照）のデバイス（Device）内の空きブロック数（Free B
lock Number in Device）と、パーティション登録チケ
ット（ＰＲＴ）に記述されたパーティションサイズ（Pa
rtion Size）とを比較し、チケット（ＰＲＴ）に記述さ
れたパーティションサイズ（Partion Size）以上の空き
ブロック領域がデバイスのメモリ部に存在するか否かを
判定する。存在しない場合は、ＰＲＴに記述されたサイ
ズのパーティションの生成はできないので、エラー終了
とする。

【０４９８】チケット（ＰＲＴ）に記述されたパーティ
ションサイズ（Partion Size）以上の空きブロック領域
がデバイスのメモリ部に存在すると判定された場合は、
ステップＳ６０４に進み、デバイス管理情報ブロックの
空き領域ポインタ（Pointerof Free Area）を参照して
デバイスの空き領域（Free Area in Device）の最上位
ブロックにパーティション定義ブロック（ＰＤＢ）エリ
ア（図１９参照）を確保する。

【０４９９】次に、デバイスは、確保したパーティショ
ン定義ブロック（ＰＤＢ）エリアに、パーティション登
録チケット（ＰＲＴ）に記述されたパーティションマネ
ージャコード（ＰＭＣ）のコピー（Ｓ６０５）、ＰＲＴ
に記述されたＰＭＣバージョンのコピー、（Ｓ６０６）
を実行する。

【０５００】さらに、パーティション定義ブロック（Ｐ
ＤＢ）エリアのパーティションスタート位置（Partitio
n Start Position）に、デバイス管理情報ブロック（図
１５参照）の空き領域ポインタ（Pointer of Free Are
a）のコピー処理を実行（Ｓ６０７）し、さらに、パー
ティション定義ブロック（ＰＤＢ）エリアのパーティシ
ョンサイズ（Partion Size）にパーティション登録チケ
ット（ＰＲＴ）に記述されたパーティションサイズ（Pa
rtion Size）のコピー処理を実行（Ｓ６０８）する。

【０５０１】次に、デバイス管理情報ブロック（図１５
参照）の空き領域ポインタ（Pointer of Free Area）に
パーティション定義ブロック（ＰＤＢ）エリアのパーテ
ィションサイズ（Partion Size）にコピーした値を加算
（Ｓ６０９）し、デバイス管理情報ブロック（図１５参
照）のデバイス（Device）内の空きブロック数（FreeBl
ock Number in Device）からパーティションサイズ（Pa
rtion Size）＋１を減算する（Ｓ６１０）。なお、＋１
は、パーティション定義ブロック（ＰＤＢ）用のブロッ
クを意味する。

【０５０２】次にデバイス管理情報ブロック（図１５参
照）のパーティション数（Partition Number）に１を加
算、すなわち生成したパーティション数（１）を加算す
る（Ｓ６１１）。

【０５０３】次に、図６１のステップＳ６３１におい
て、生成したパーティション領域の最上位ブロックをパ
ーティション管理情報ブロック（ＰＭＩＢ：partition
Management Information Block）（図２０参照）として
設定し、設定したパーティション管理情報ブロック（Ｐ
ＭＩＢ）のパーティションマネージャコード（ＰＭＣ）
フィールドにパーティション登録チケット（ＰＲＴ）の
ＰＭＣのコピー処理を実行（Ｓ６３２）し、パーティシ
ョン管理情報ブロック（ＰＭＩＢ）のＰＭＣバージョン
フィールドにパーティション登録チケット（ＰＲＴ）の
ＰＭＣバージョンのコピー処理を実行（Ｓ６３３）し、
パーティション管理情報ブロック（ＰＭＩＢ）のパーテ
ィション総ブロック数（Total Block number in Partit
ion）フィールドにパーティション登録チケット（ＰＲ
Ｔ）のパーティションサイズ（Partion Size）のコピー
処理を実行（Ｓ６３４）する。

【０５０４】さらに、パーティション管理情報ブロック
（ＰＭＩＢ）のパーティション空きブロック数（Free B
lock number in Partition）フィールドにパーティショ
ン登録チケット（ＰＲＴ）のパーティションサイズ（Pa
rtion Size）−３を記録（Ｓ６３５）する。なお、−３
の意味は、既に使用が予定されているパーティション管
理情報ブロック（ＰＭＩＢ）、共通鍵系パーティション
鍵定義ブロック（ＰＫＤＢ(common)）、公開鍵系パーテ
ィション鍵定義ブロック（ＰＫＤＢ(PUB)）の３ブロッ
クを差し引くことを意味している。

【０５０５】さらに、パーティション管理情報ブロック
（ＰＭＩＢ）のファイル数（File Number）に０を記入
（Ｓ６３６）する。この時点ではパーティション内には
ファイルは設定されていない。ファイル設定はファイル
登録チケット（ＦＲＴ）を使用して設定可能である。こ
のファイル登録チケット（ＦＲＴ）を使用したファイル
登録処理については後述する。

【０５０６】さらに、パーティション管理情報ブロック
（ＰＭＩＢ）の空き領域ポインタ（Pointer of Free Ar
ea）にパーティション定義ブロック（ＰＤＢ）のスター
トポジション（Start Position）をコピーしてパーティ
ションの設定登録を終了する。

【０５０７】次に図６０のステップＳ６２１〜Ｓ６２８
のパーティション削除処理について説明する。ステップ
Ｓ６２１では、パーティション登録チケット（ＰＲＴ）
に記述されたパーティションマネージャコード（ＰＭ
Ｃ）と同一コードのパーティションがデバイスのメモリ
部に存在するか否かを検証する。この判定は、デバイス
のメモリ部のパーティション定義ブロック（図１９参
照）に受信チケット（ＰＲＴ）の記述コードと同一のコ
ードが記述されているか否かを検証することによって判
定可能である。

【０５０８】デバイスに同一コード（ＰＭＣ）のパーテ
ィションが存在しない場合は、パーティションの削除は
不可能であるので、エラー終了とする。同一コードのパ
ーティションがデバイスに存在する場合は、ステップＳ
６２２において、削除対象のパーティションより後に生
成されたパーティションがデバイスに存在するか否かを
判定する。存在しない場合は、削除対象のパーティショ
ンが最新のパーティションであり、ステップＳ６２９に
おいて削除対象のパーティションのパーティション定義
ブロック（ＰＤＢ）（図１９参照）を削除する。

【０５０９】ステップＳ６２２において、削除対象のパ
ーティションより後に生成されたパーティションがデバ
イスに存在すると判定された場合は、後に生成されたパ
ーティション（後パーティション）のデータを削除対象
のパーティションのサイズ（ＰＳ）分、下位にずらす処
理を実行（Ｓ６２３）し、さらに、後パーティションの
パーティション定義ブロック（ＰＤＢ）を１ブロック上
位にずらす処理を実行（Ｓ６２４）する。また、後パー
ティションのパーティション定義ブロック（ＰＤＢ）に
記録されたパーティション開始位置（Partition Start
Portion）から削除パーティションのサイズ（ＰＳ）を
減算する処理を実行する（Ｓ６２５）。

【０５１０】ステップＳ６２５またはＳ６２９の処理の
後、ステップＳ６２６において、デバイス管理情報ブロ
ック（ＤＭＩＢ）（図１５参照）のデバイス（Device）
内の空きブロック数（Free Block Number in Device）
に削除パーティションのサイズ（ＰＳ）＋１を加算す
る。＋１は、削除パーティションのパーティション定義
ブロック（ＰＤＢ）用のブロックを意味する。

【０５１１】次にステップＳ６２７において、デバイス
管理情報ブロック（図１５参照）の空き領域ポインタ
（Pointer of Free Area）の値から削除パーティション
のサイズ（ＰＳ）を減算する。さらに、ステップＳ６２
８において、デバイス管理情報ブロック（図１５参照）
のパーティション数（Partition Number）から１を減
算、すなわち削除したパーティション数（１）を減算し
てパーティション登録チケット（ＰＲＴ）に基づくパー
ティション削除処理が終了する。

【０５１２】以上が、図４７の処理フローにおけるステ
ップＳ４１５のパーティション登録チケット（ＰＲＴ）
に基づくパーティション生成、削除処理である。

【０５１３】（パーティション初期登録）次に、図４７
の処理フローにおけるステップＳ４０６，Ｓ４１９のパ
ーティション初期データ書き込み処理、すなわちパーテ
ィション登録チケット（ＰＲＴ）に基づくパーティショ
ン初期登録処理の詳細について図６２以下のフローを用
いて説明する。

【０５１４】図６２、図６３、図６４に示す処理フロー
において、左側がパーティションマネージャの管轄する
初期登録装置の処理、右側がデバイス（図５参照）の処
理を示す。なお、パーティションマネージャの管轄する
初期登録装置は、デバイスに対するデータ読み取り書き
込み処理可能な装置（ｅｘ．デバイスアクセス機器とし
てのリーダライタ、ＰＣ）であり、図１０のデバイスア
クセス機器としてのリーダライタに相当する構成を有す
る。図４７の処理フローに示すように、図６２の処理開
始以前に、初期登録装置とデバイス間では、相互認証が
成立し、チケットの正当性、利用者チェックにおいてチ
ケットおよび利用者（チケットユーザであるデバイスア
クセス機器としてのリーダライタなど）の正当性が確認
され、さらにパーティション登録チケット（ＰＲＴ）に
基づくパーティション生成処理が終了しているものとす
る。また、図６２、図６３、図６４の初期登録装置と、
デバイス間のデータの送受信は、相互認証時に生成した
セッション鍵Ｋｓｅｓを用いて暗号化されたデータとし
て送受信される。

【０５１５】図６２のステップＳ６４１において、初期
登録装置は、パーティション認証に共通鍵を用いるか否
かを判定する。この判定は、使用するパーティション登
録チケット（ＰＲＴ）（図２６参照）のAuthentication
Type（デバイス（Device）の相互認証のタイプ（公開
鍵認証、または、共通鍵認証、または、いずれでも可
（Any）））フィールドを参照して行われる。

【０５１６】図６２に示すように、パーティション認証
に共通鍵を用いる場合、ステップＳ６４２〜６４３、Ｓ
６５１〜Ｓ６５４を実行し、パーティション認証に共通
鍵を用いない場合、これらのステップは省略される。

【０５１７】パーティション認証に共通鍵を用いる場
合、ステップＳ６４２において初期登録装置は、共通鍵
認証データ書き込みコマンドとして、MKauth＿PAR_A :
双方向個別鍵認証用マスター鍵、Kauth＿PAR_B :双方向
個別鍵認証用共通鍵、IRL_PAR:排除デバイス（Device）
のデバイス識別子（ＩＤ）を登録したリボケーションリ
スト（Revocation List (Device ID)）、およびこれら
のバージョン情報をデバイスに送信する。

【０５１８】ステップＳ６５１でデバイスは、上述の書
き込みコマンドを受信し、ステップＳ６５２において、
受領データをパーティション鍵領域（図２３参照）に書
き込む。次にデータ書き込みによって生じたポインタ、
サイズ、デバイス内のフリーブロック数の調整を実行
（Ｓ６５３）し、書き込み終了通知を登録装置に送信
（Ｓ６５４）する。

【０５１９】書き込み終了通知を受信（Ｓ６４３）した
登録装置は、ステップＳ６４４においてパーティション
認証に公開鍵を用いるか否かを判定する。図６２に示す
ように、パーティション認証に公開鍵を用いる場合、ス
テップＳ６４５〜６４９、Ｓ６５５〜Ｓ６６２を実行
し、パーティション認証に公開鍵を用いない場合、これ
らのステップは省略される。

【０５２０】パーティション認証に公開鍵を用いる場
合、ステップＳ６４５において登録装置は、公開鍵認証
データ書き込みコマンドとして、PUB_CA(PAR) :パーテ
ィションマネージャ対応公開鍵証明書を発行する認証局
ＣＡ（ＰＡＲ）の公開鍵、PARAM_PAR :パーティション
（Partition）の公開鍵パラメータ、CRL_PAR :排除デバ
イス（Device）の公開鍵証明書識別子（ｅｘ．シリアル
ナンバ：ＳＮ）を登録したリボケーションリスト（Revo
cation List (Certificate)）、およびこれらのバージ
ョン情報をデバイスに送信する。

【０５２１】ステップＳ６５５でデバイスは、上述の書
き込みコマンドを受信し、ステップＳ６５６において、
受領データをパーティション鍵領域（図２３参照）に書
き込む。次にデータ書き込みによって生じたポインタ、
サイズ、デバイス内のフリーブロック数の調整を実行
（Ｓ６５７）し、書き込み終了通知を登録装置に送信
（Ｓ６５８）する。

【０５２２】書き込み終了通知を受信（Ｓ６４６）した
登録装置は、公開鍵と秘密鍵の鍵ペア生成コマンドをデ
バイスに送信（Ｓ６４７）する。なお、この実施例で
は、鍵ペアの生成はデバイスが実行する構成としている
が、例えば登録装置が実行してデバイスに提供する構成
としてもよい。

【０５２３】鍵ペア生成コマンドを受信（Ｓ６５９）し
たデバイスは、デバイス内の暗号処理部（図５参照）に
おいて公開鍵（ＰＵＢ ＰＡＲ）と秘密鍵（ＰＲＩ ＰＡ
Ｒ）のペアを生成し、生成した鍵をパーティション鍵領
域（図２３参照）に書き込む（Ｓ６６０）。次にデータ
書き込みによって生じたポインタ、サイズ、デバイス内
のフリーブロック数の調整を実行（Ｓ６６１）し、生成
格納した公開鍵を登録装置に送信（Ｓ６６２）する。

【０５２４】登録装置は、デバイスから公開鍵（ＰＵＢ
ＰＡＲ）を受信（Ｓ６４８）し、先にデバイスから受
信したデバイスの識別子ＩＤｍとともに、パーティショ
ンマネージャ内のデータベース（ＤＢ（ＰＡＲ））（図
９参照））に保存する。

【０５２５】次に、パーティションマネージャの登録装
置は、ファイル登録チケット（ＦＲＴ：File Registrat
ion Ticket）の検証処理に共通鍵を用いるか否かを判定
（Ｓ６７１）する。チケット検証には、前述したように
ＭＡＣ値検証等による共通鍵方式と、秘密鍵による署名
生成、公開鍵による署名検証を行なう公開鍵方式のいず
れかを適用することが可能であり、パーティションマネ
ージャは、デバイスの採用する検証処理方式を設定する
ことができる。パーティションマネージャは、デバイス
の採用するＦＲＴチケット検証方式に応じて共通鍵、公
開鍵のいずれか、あるいは両方式を実行可能なデータを
デバイスに設定する。

【０５２６】パーティションマネージャは、ファイル登
録チケット（ＦＲＴ：File Registration Ticket）の検
証処理に共通鍵認証を実行する設定とする場合は、共通
鍵方式のＦＲＴ検証に必要な情報（ｅｘ．ＦＲＴ検証共
通鍵）をデバイスにセットし、デバイスが共通鍵認証を
実行しないデバイスであれば、これらの情報をデバイス
に格納しないことになる。

【０５２７】図６３に示すように、ＦＲＴ検証に共通鍵
方式を用いる場合、ステップＳ６７２〜６７３、Ｓ６８
１〜Ｓ６８４を実行し、ＦＲＴ検証に共通鍵を用いない
場合、これらのステップは省略される。

【０５２８】ＦＲＴ検証に共通鍵を用いる場合、ステッ
プＳ６７２において登録装置は、ＦＲＴ検証共通鍵書き
込みコマンドとして、Kfrt :ファイル登録チケット（Ｆ
ＲＴ）のＭＡＣ検証用鍵、およびバージョン情報をデバ
イスに送信する。

【０５２９】ステップＳ６８１でデバイスは、上述の書
き込みコマンドを受信し、ステップＳ６８２において、
受領データをパーティション鍵領域（図２３参照）に書
き込む。次にデータ書き込みによって生じたポインタ、
サイズ、デバイス内のフリーブロック数の調整を実行
（Ｓ６８３）し、書き込み終了通知を登録装置に送信
（Ｓ６８４）する。

【０５３０】書き込み終了通知を受信（Ｓ６７３）した
登録装置は、ステップＳ６７４においてＦＲＴ検証に公
開鍵を用いるか否かを判定する。図６３に示すように、
ＦＲＴ検証に公開鍵を用いる場合、ステップＳ６７５〜
６７６、Ｓ６８５〜Ｓ６９０を実行し、ＦＲＴ検証に公
開鍵を用いない場合、これらのステップは省略される。

【０５３１】ＦＲＴ検証に公開鍵を用いる場合、ステッ
プＳ６７５において登録装置は、ＦＲＴ検証データ書き
込みコマンドとして、FRTIC（FRT Issuer Category) :
ファイル登録チケット（ＦＲＴ）発行者カテゴリ、PUB_
CA(PAR) :パーティションマネージャ対応公開鍵証明書
を発行する認証局ＣＡ（ＰＡＲ）の公開鍵、PARAM_PAR
: パーティション（Partition）の公開鍵パラメータ、
CRL_PAR :排除デバイス（Device）の公開鍵証明書識別
子（ｅｘ．シリアルナンバ：ＳＮ）を登録したリボケー
ションリスト（Revocation List (Certificate)）、お
よびこれらのバージョン情報をデバイスに送信する。

【０５３２】ステップＳ６８５でデバイスは、上述の書
き込みコマンドを受信し、ステップＳ６８６において、
受領データ中のFRTIC（FRT Issuer Category) :ファイ
ル登録チケット（ＦＲＴ）発行者カテゴリを公開鍵系パ
ーティション鍵定義ブロック（ＰＫＤＢ：Partition Ke
y Definition block（PUB）（図２２参照））に書き込
みバージョン情報を同ブロックのバージョン領域に書き
込む。

【０５３３】次にデバイスは、ステップＳ６８７におい
て、PUB_CA(PAR) :パーティションマネージャ対応公開
鍵証明書を発行する認証局ＣＡ（ＰＡＲ）の公開鍵デー
タが書き込み済みか否かを判定し、書き込まれていない
場合にステップＳ６８８において、PUB_CA(PAR)、PARAM
_PAR、CRL_PARをパーティション鍵領域（図２３参照）
に書き込む。次にデータ書き込みによって生じたポイン
タ、サイズ、デバイス内のフリーブロック数の調整を実
行（Ｓ６８９）し、書き込み終了通知を登録装置に送信
（Ｓ６９０）する。

【０５３４】書き込み終了通知を受信（Ｓ６７６）した
登録装置は、次に、ステップＳ７０１において、共通鍵
データの更新をサポートするデバイスとするか否かを判
定する。デバイスに格納されたデータ中、そのいくつか
は更新対象データとして前述したデータアップデートチ
ケット（ＤＵＴ：Data Update Ticket）（図３２参照）
を用いて更新が可能である。更新対象となるデータは、
先に図３３を用いて説明した通りである。このデータア
ップデートチケット（ＤＵＴ：Data Update Ticket）を
用いた更新処理においても共通鍵方式、または公開鍵方
式のいずれかの方式が可能であり、パーティションマネ
ージャは設定したパーティションに応じていずれかの方
式または両方式を実行可能なデータをデバイスを設定す
る。

【０５３５】パーティションマネージャは、設定したパ
ーティションを共通鍵方式によるデータ更新を実行する
構成とする場合は、共通鍵方式のデータ更新処理に必要
な情報（ｅｘ．データアップデートチケット（ＤＵＴ）
のＭＡＣ検証用鍵他）をデバイスのパーティション鍵領
域にセットし、デバイスが共通鍵認証を実行しないデバ
イスであれば、これらの情報をデバイスのパーティショ
ン鍵領域に格納しない処理をする。

【０５３６】図６４に示すように、データアップデート
チケット（ＤＵＴ：Data Update Ticket）を用いたデー
タ更新処理に共通鍵方式を用いる場合、ステップＳ７０
２〜７０３、Ｓ７１１〜Ｓ７１４を実行し、データ更新
に共通鍵方式を用いない場合、これらのステップは省略
される。

【０５３７】データ更新に共通鍵を用いる場合、ステッ
プＳ７０２において登録装置は、データアップデートチ
ケット（ＤＵＴ：Data Update Ticket）検証共通鍵書き
込みコマンドとして、Kdut_PAR1 :データアップデート
チケット（ＤＵＴ）のＭＡＣ検証用鍵、 Kdut_PAR2 :デ
ータ更新用暗号鍵、Kdut_PAR3 :データアップデートチ
ケット（ＤＵＴ）のＭＡＣ検証用鍵、Kdut_PAR4 :デー
タ更新用暗号鍵およびこれらのバージョン情報をデバイ
スに送信する。

【０５３８】ステップＳ７１１でデバイスは、上述の書
き込みコマンドを受信し、ステップＳ７１２において、
受領データをパーティション鍵領域（図２３参照）に書
き込む。次にデータ書き込みによって生じたポインタ、
サイズ、デバイス内のフリーブロック数の調整を実行
（Ｓ７１３）し、書き込み終了通知を登録装置に送信
（Ｓ７１４）する。

【０５３９】書き込み終了通知を受信（Ｓ７０３）した
登録装置は、ステップＳ７０４において、デバイスに設
定したパーティションが公開鍵方式を用いたデータアッ
プデートチケット（ＤＵＴ：Data Update Ticket）を使
用したデータ更新処理をサポートするか否かを判定す
る。図６４に示すように、公開鍵方式をサポートする場
合、ステップＳ７０５〜７０６、Ｓ７１５〜Ｓ７１８を
実行し、公開鍵方式をサポートしない場合、これらのス
テップは省略される。

【０５４０】公開鍵方式をサポートする場合、ステップ
Ｓ７０５において登録装置は、データアップデートチケ
ット（ＤＵＴ：Data Update Ticket）発行者コード書き
込みコマンドとして、DUTIC_PAR（DUT Issuer Categor
y) :データアップデートチケット（ＤＵＴ：Data Updat
e Ticket）発行者カテゴリ、およびバージョン情報をデ
バイスに送信する。

【０５４１】ステップＳ７１５でデバイスは、上述の書
き込みコマンドを受信し、ステップＳ７１６において、
受領データを公開鍵系パーティション鍵定義ブロック
（ＰＫＤＢ（ＰＵＢ）：Partition Key Definition Blo
ck(PUB)）に書き込む。次にデータ書き込みによって生
じたポインタ、サイズ、デバイス内のフリーブロック数
の調整を実行（Ｓ７１７）し、書き込み終了通知を登録
装置に送信（Ｓ７１８）し、登録装置が書き込み終了通
知を受信（Ｓ７０６）して処理を終了する。

【０５４２】パーティションマネージャによる初期登録
処理（図６２〜図６４の処理フロー）が完了した状態の
デバイスのメモリ内格納データ構成例を図６５に示す。
図６５に示すパーティション(Partition)領域中、パー
ティション鍵領域には、上記のフロー（図６２〜図６
４）において、登録装置から送信されて下記のデータが
書き込まれる。 * IRL_PAR :パーティションアクセス排除デバイス（Dev
ice）、排除機器（デバイスアクセス機器としてのリー
ダライタ、ＰＣ等のチケットユーザ、チケット発行手
段）の識別子（ＩＤ）を登録したリボケーションリスト
（Revocation List (Device ID)） * CRL_PAR :パーティションアクセス排除デバイス（Dev
ice）、排除機器（デバイスアクセス機器としてのリー
ダライタ、ＰＣ等のチケットユーザ、チケット発行手
段）の公開鍵証明書識別子（ｅｘ．シリアルナンバ：Ｓ
Ｎ）を登録したリボケーションリスト（Revocation Lis
t (Certificate) * Kauth_PAR_B :双方向個別鍵認証用共通鍵 * Mkauth_PAR_A :双方向個別鍵認証用マスター鍵 * Kdut_PAR1 :データアップデートチケット（ＤＵＴ）
のＭＡＣ検証用鍵 * Kdut_PAR2 :データ更新用暗号鍵 * Kdut_PAR3 : データアップデートチケット（ＤＵＴ）
のＭＡＣ検証用鍵 * Kdut_PAR4 :データ更新用暗号鍵 * Kfrt :ファイル登録チケット（ＦＲＴ）のＭＡＣ検証
用鍵

【０５４３】また、 * PUB_PAR :パーティション（Partition）の公開鍵 * PRI_PAR :パーティション（Partition）の秘密鍵 が、デバイスにおいて生成されて書き込まれる。

【０５４４】また、 * PARAM_PAR :パーティション（Partition）の公開鍵パ
ラメータ * PUB_CA(PAR) :認証局ＣＡ（ＰＡＲ）の公開鍵 共通鍵系パーティション鍵情報ブロック（Partition Ke
y Definition Block(Common)) 公開鍵系パーティション鍵情報ブロック（Partition Ke
y Definition Block(PUB)） パーティション管理情報ブロック（Partition Manageme
nt Information Block） の各データは、パーティションの生成時（処理フロー図
６０、図６１参照）に書き込まれるデータである。

【０５４５】［Ｂ４．２．パーティションマネージャ管
理下における公開鍵証明書発行処理］次に図６６以下を
用いて、パーティションマネージャによるパーティショ
ン対応公開鍵証明書の発行処理について説明する。デバ
イスには、デバイス全体の認証、デバイスを単位とした
処理に適用可能なデバイス対応公開鍵証明書（ＣＥＲＴ
ＤＥＶ）と、デバイス内の特定のパーティションに対
する処理の際の認証その他検証処理等に適用可能なパー
ティション対応公開鍵証明書（ＣＥＲＴ ＰＡＲ）が格
納され得る。パーティション対応公開鍵証明書（ＣＥＲ
Ｔ ＰＡＲ）は、デバイスに設定されたパーティション
毎に設定格納可能である。

【０５４６】パーティション対応公開鍵証明書（ＣＥＲ
Ｔ ＰＡＲ）は、パーティションマネージャの管轄する
登録局を介して認証局（ＣＡ ｆｏｒ ＰＭ）（図２、図
３参照）の発行した公開鍵証明書をデバイスに付与する
手続きにより発行され、登録局はパーティションマネー
ジャの管轄登録局が発行した公開鍵証明書（ＣＥＲＴＰ
ＡＲ）についての管理（データベース３３２（図９参
照））を実行する。

【０５４７】図６６および図６７に従って、パーティシ
ョンマネージャの管轄登録局による設定パーティション
に対するパーティション対応公開鍵証明書（ＣＥＲＴ
ＰＡＲ）の発行処理の手順を説明する。図６６，図６７
において、左側がパーティションマネージャの管轄登録
局のＣＥＲＴ（公開鍵証明書）発行装置、具体的には、
図９に示すパーティションマネージャの構成図における
制御手段３３１の処理、右側がデバイスの処理である。

【０５４８】まずステップＳ７２１において、ＣＥＲＴ
発行装置は、パーティション対応公開鍵証明書（ＣＥＲ
Ｔ ＰＡＲ）の発行対象となるデバイスのユーザ情報を
取得し、証明書発行の許可（判定）を行ない発行対象と
なるデバイスとの通信路を確保する。パーティション対
応公開鍵証明書（ＣＥＲＴ ＰＡＲ）の発行対象となる
デバイスのユーザ情報は、例えばデバイスの初期登録時
に生成したデータから取得可能である。なお、ユーザ情
報はデバイスとの通信路設定後、デバイスから取得して
もよい。通信路は、有線、無線を問わずデータ送受信可
能な通信路として確保されればよい。

【０５４９】次にＣＥＲＴ発行装置は、ステップＳ７２
２において、乱数Ｒを含む認証データ生成コマンドをデ
バイスに対して送信する。認証データ生成コマンドを受
信（Ｓ７３１）したデバイスは、受信乱数Ｒと、デバイ
ス識別子（ＩＤｍ）の結合データにデバイス秘密鍵（Ｐ
ＲＩ ＰＡＲ）を適用してデジタル署名（Ｓ）の生成処
理（図１２参照）を実行（Ｓ７３２）する。デバイス
は、デバイスの識別データ（ＩＤｍ）と署名（Ｓ）をＣ
ＥＲＴ発行装置に送信する。

【０５５０】デバイスから識別データ（ＩＤｍ）と署名
（Ｓ）を受信（Ｓ７２３）したＣＥＲＴ発行装置は、受
信したデバイス識別データ（ＩＤｍ）を検索キーとして
データベースＤＢ（ＰＡＲ）３３２から格納済みのデバ
イス公開鍵（ＰＵＢ ＰＡＲ）を取得する。さらに、取
得したデバイス公開鍵（ＰＵＢ ＰＡＲ）を適用して署
名（Ｓ）の検証処理（図１３参照）を実行（Ｓ７２５）
する。検証に成功しなかった場合は、デバイスからの送
信データは不正なデータであると判定し処理は終了す
る。

【０５５１】検証に成功した場合は、認証局（ＣＡ ｆ
ｏｒ ＰＭ）６２０に対してパーティション対応公開鍵
証明書（ＣＥＲＴ ＰＡＲ）の発行処理を依頼（Ｓ７２
７）する。パーティションマネージャは認証局６２０の
発行したパーティション対応公開鍵証明書（ＣＥＲＴ
ＰＡＲ）を受信（Ｓ７２８）してデバイスに送信（Ｓ７
２９）する。

【０５５２】パーティションマネージャ（登録局）から
パーティション対応公開鍵証明書（ＣＥＲＴ ＰＡＲ）
を受信したデバイスは、予めパーティション鍵領域（図
２３参照）に格納済みの認証局の公開鍵（ＰＵＢ ＣＡ
（ＰＡＲ））を用いて受信したパーティション対応公開
鍵証明書（ＣＥＲＴ ＰＡＲ）の署名検証を実行する。
すなわち公開鍵証明書には認証局の秘密鍵で実行され署
名があり（図１１参照）、この署名検証（Ｓ７３５）を
行なう。

【０５５３】署名検証に失敗した場合は、正当な公開鍵
証明書でないと判定し、エラー通知をＣＥＲＴ発行装置
に対して実行（Ｓ７４５）する。

【０５５４】署名検証に成功した場合は、パーティショ
ン対応公開鍵証明書（ＣＥＲＴ ＰＡＲ）に格納された
デバイス公開鍵（ＰＵＢ ＰＡＲ）と自デバイスに保管
されたデバイス公開鍵（ＰＵＢ ＰＡＲ）の比較を実行
（Ｓ７４１）し、一致しない場合はエラー通知を実行
し、一致した場合は、受信したパーティション対応公開
鍵証明書（ＣＥＲＴ ＰＡＲ）をパーティション鍵領域
（図２３参照）に格納（Ｓ７４３）する。なお、パーテ
ィション対応公開鍵証明書（ＣＥＲＴ ＰＡＲ）の発行
以前は、この領域に自デバイスで生成した公開鍵（ＰＵ
Ｂ ＰＡＲ）を格納し、正当なパーティション対応公開
鍵証明書（ＣＥＲＴ ＰＡＲ）が発行された時点で、パ
ーティション対応公開鍵証明書（ＣＥＲＴ ＰＡＲ）に
より上書きする処理として格納する。

【０５５５】パーティション対応公開鍵証明書（ＣＥＲ
Ｔ ＰＡＲ）の格納が終了すると格納処理終了通知をＣ
ＥＲＴ発行装置に送信（Ｓ７４４）する。ＣＥＲＴ発行
装置は、格納処理終了通知を受信（Ｓ７５１）し、格納
成功を確認（Ｓ７５２）して処理を終了する。格納成功
の確認が得られない場合はエラーとして処理が終了す
る。

【０５５６】［Ｂ４．３．パーティション生成処理各方
式における処理手順］上述したように、パーティション
の設定登録処理において、パーティションマネージャの
管理するデバイスアクセス機器としてのリーダライタと
デバイス間において、相互認証が実行され、パーティシ
ョン登録チケット（ＰＲＴ）に基づくパーティションの
設定がなされる。上述したように相互認証処理の態様
は、公開鍵相互認証、共通鍵相互認証の２種類のいずれ
かであり、またチケット（ＰＲＴ）の検証処理も公開鍵
系の署名検証、共通鍵系のＭＡＣ検証の２種類のいずれ
かが実行されることになる。すなわち処理態様としては
大きく分けて、 （Ａ）相互認証（公開鍵）、チケット（ＰＲＴ）検証
（公開鍵） （Ｂ）相互認証（公開鍵）、チケット（ＰＲＴ）検証
（共通鍵） （Ｃ）相互認証（共通鍵）、チケット（ＰＲＴ）検証
（共通鍵） （Ｄ）相互認証（共通鍵）、チケット（ＰＲＴ）検証
（公開鍵） の４態様がある。

【０５５７】これらの４態様についての処理を、認証局
（ＣＡ（ＤＭ））、デバイスマネージャ（ＤＭ）、パー
ティションマネージャ（ＰＭ）、デバイス、各エンティ
テイ間において実行されるデータ転送処理を中心として
図を用いて簡潔に説明する。

【０５５８】（Ａ）相互認証（公開鍵）、チケット（Ｐ
ＲＴ）検証（公開鍵） まず、相互認証処理に公開鍵方式を適用し、チケット
（ＰＲＴ）検証に公開鍵方式を適用する場合の各エンテ
ィテイ間のデータ転送について図６８を用いて説明す
る。なお以下では、説明を簡略化するために図６８に示
すように、認証局（ＣＡ）を１つとし、登録局をデバイ
スマネージャ内に１つ設定し、デバイスマネージャ公開
鍵証明書（Ｃｅｒｔ．ＤＭ）、パーティションマネージ
ャ公開鍵証明書（Ｃｅｒｔ．ＰＭ）の双方をこれらの各
登録局、認証局を介して発行する構成とした。またパー
ティション登録チケット（ＰＲＴ）の発行手段はデバイ
スマネージャ（ＤＭ）であり、パーティション登録チケ
ット（ＰＲＴ）に対する署名はデバイスマネージャの秘
密鍵を用いて実行される。

【０５５９】図に示す番号順に各エンティテイ間でデー
タ転送が実行される。以下、各番号に従って処理を説明
する。 （１）デバイスマネージャ（ＤＭ）の公開鍵証明書（Ｃ
ｅｒｔ．ＤＭ）の発行、 公開鍵証明書（Ｃｅｒｔ．ＤＭ）は、認証局（ＣＡ）に
よってデバイスマネージャの発行要求により、登録局を
介した証明書発行手続きによってデバイスマネージャに
対して発行される。 （２）パーティションマネージャ（ＰＭ）の公開鍵証明
書（Ｃｅｒｔ．ＰＭ）の発行、 公開鍵証明書（Ｃｅｒｔ．ＰＭ）は、認証局（ＣＡ）に
よってパーティションマネージャの発行要求により、登
録局を介した証明書発行手続きによってパーティション
マネージャに対して発行される。

【０５６０】（３）パーティション登録チケット（ＰＲ
Ｔ）の発行処理 パーティション登録チケット（ＰＲＴ）は、デバイスマ
ネージャの管理するパーティション登録チケット発行手
段（ＰＲＴ Ticket Issuer）によりパーティションマネ
ージャ（ＰＭ）に対して発行される。この場合、公開鍵
方式の署名生成、検証を実行するため、デバイスマネー
ジャの秘密鍵による署名(Signature)が生成（図１２参
照）されてＰＲＴに付加される。 （４）ＰＲＴおよびＤＭ公開鍵証明書（Ｃｅｒｔ．Ｄ
Ｍ）のＰＭに対する供給 デバイスマネージャの管理するパーティション登録チケ
ット発行手段（ＰＲＴTicket Issuer）により発行され
たパーティション登録チケット（ＰＲＴ）は、ＤＭ公開
鍵証明書（Ｃｅｒｔ．ＤＭ）とともにパーティションマ
ネージャに対して送信される。

【０５６１】（５）ＰＭとデバイス間の相互認証 発行されたＰＲＴに従ったパーティションを生成しよう
とする対象のデバイスと、パーティションマネージャ
（具体的にはチケットユーザであるデバイスアクセス機
器としてのリーダライタ）は、公開鍵方式の相互認証
（図５０参照）を実行する。

【０５６２】（６）ＰＲＴおよびＤＭ公開鍵証明書（Ｃ
ｅｒｔ．ＤＭ）のデバイスに対する供給 ＰＭとデバイス間の相互認証が成立すると、パーティシ
ョンマネージャ（ＰＭ）は、デバイスに対してパーティ
ション登録チケット（ＰＲＴ）、およびＤＭ公開鍵証明
書（Ｃｅｒｔ．ＤＭ）を送信する。デバイスは、受信し
たパーティション登録チケット（ＰＲＴ）について、
（１）チケット発行者（Ticket Issuer）＝ＤＭの公開
鍵証明書（ＣＥＲＴ）が改竄されたものでない正当な公
開鍵証明書（ＣＥＲＴ）であること、（２）チケット発
行者（Ticket Issuer）の公開鍵証明書（ＣＥＲＴ）の
オプション領域に記録されたコードと、デバイス内のＤ
ＫＤＢ（Device Key Definition Block）(PUB)に記録さ
れたチケット発行手段コード（ＰＲＴＩＣ：PRT Issuer
Code）の一致、（３）チケット発行手段（Ticket Issu
er）がリボークされていないこと、（４）受信チケット
（ＰＲＴ）の署名（Signature）の検証によりチケット
が改竄のないことの確認を実行し、さらに、ＰＲＴチケ
ットに格納されたＰＲＴユーザ（この場合はＰＭ：チケ
ットユーザであるデバイスアクセス機器としてのリーダ
ライタ）と受信したパーティションマネージャの公開鍵
証明書の識別データ（ＤＮ）として記録された識別子ま
たはカテゴリまたはシリアル（ＳＮ）の一致を確認し、
相互認証済みであることを確認することによりＰＲＴユ
ーザ（ＰＭ：デバイスアクセス機器としてのリーダライ
タ）の検証（図５７、図５８参照）を実行する。

【０５６３】（７）パーティションの生成 パーティション登録チケット（ＰＲＴ）の検証、ＰＲＴ
発行者（PRT Issuer）、ＰＲＴユーザの検証に成功する
と、パーティション登録チケット（ＰＲＴ）に記述され
たルールに従ってパーティションがデバイスのメモリ部
に生成（図６０、図６１参照）される。

【０５６４】（８）鍵データ書き込み パーティションがデバイスのメモリ部に生成されると、
生成されたパーティション内に対する各種鍵の格納処理
が実行される。 （９）公開鍵の読み出し、 （１０）公開鍵証明書の発行 生成パーティションに対する各種サービス時の認証処理
（パーティション生成、ファイル生成、ファイルアクセ
ス、データアップデート等のサービス利用時の認証処
理）に際し、公開鍵認証を行なう場合、デバイスは公開
鍵、秘密鍵の鍵ペアを生成し、生成した公開鍵をパーテ
ィションマネージャに送信し、登録局、認証局を介して
公開鍵証明書の発行処理を行ない、発行された公開鍵証
明書をパーティション鍵領域（図２３参照）に格納す
る。この際、生成した公開鍵の格納領域に対して発行さ
れた公開鍵証明書を格納する。なお、この（９）、（１
０）の処理は、作成パーティションに対する各種サービ
ス時の認証処理（パーティション生成、ファイル生成、
ファイルアクセス、データアップデート等のサービス利
用時の認証処理）の際に公開鍵認証を行なう構成の場合
に実行すればよい。

【０５６５】以上の処理によって、相互認証（公開
鍵）、チケット（ＰＲＴ）検証（公開鍵）の各方式に従
ったパーティションの生成処理が実行される。

【０５６６】（Ｂ）相互認証（公開鍵）、チケット（Ｐ
ＲＴ）検証（共通鍵） 次に、相互認証処理に公開鍵方式を適用し、チケット
（ＰＲＴ）検証に共通鍵方式を適用する場合の各エンテ
ィテイ間のデータ転送について図６９を用いて説明す
る。図に示す番号順に各エンティテイ間でデータ転送が
実行される。以下、各番号に従って処理を説明する。

【０５６７】（１）パーティションマネージャ（ＰＭ）
の公開鍵証明書（Ｃｅｒｔ．ＰＭ）の発行、 公開鍵証明書（Ｃｅｒｔ．ＰＭ）は、認証局（ＣＡ）に
よってパーティションマネージャの発行要求により、登
録局を介した証明書発行手続きによってデバイスマネー
ジャに対して発行される。

【０５６８】（２）パーティション登録チケット（ＰＲ
Ｔ）の発行処理 パーティション登録チケット（ＰＲＴ）は、デバイスマ
ネージャの管理するパーティション登録チケット発行手
段（ＰＲＴ Ticket Issuer）によりパーティションマネ
ージャ（ＰＭ）に対して発行される。この場合、共通鍵
方式の検証値としてＭＡＣ(Message Authentication Co
de)（図５９参照）がＰＲＴに付加される。 （３）ＰＲＴのＰＭに対する供給 デバイスマネージャの管理するパーティション登録チケ
ット発行手段（ＰＲＴTicket Issuer）により発行され
たパーティション登録チケット（ＰＲＴ）は、パーティ
ションマネージャに対して送信される。

【０５６９】（４）ＰＭとデバイス間の相互認証 発行されたＰＲＴに従ったパーティションを生成しよう
とする対象のデバイスと、パーティションマネージャ
（具体的にはチケットユーザであるデバイスアクセス機
器としてのリーダライタ）は、公開鍵方式の相互認証
（図５０参照）を実行する。

【０５７０】（５）ＰＲＴの送信 パーティションマネージャは発行されたパーティション
登録チケット（ＰＲＴ）をデバイスに送付する。デバイ
スは、受信したパーティション登録チケット（ＰＲＴ）
についてＭＡＣ検証処理を実行し、ＰＲＴ発行者（PRT
Issuer）の検証、さらに、ＰＲＴチケットに格納された
ＰＲＴユーザ（この場合はＰＭ：チケットユーザである
デバイスアクセス機器としてのリーダライタ）と受信し
たパーティションマネージャの公開鍵証明書の識別デー
タ（ＤＮ）として記録された識別子またはカテゴリまた
はシリアル（ＳＮ）の一致を確認し相互認証済みである
ことを確認することによりＰＲＴユーザ（ＰＭ：デバイ
スアクセス機器としてのリーダライタ）の検証（図５
７、図５８参照）を実行する。

【０５７１】（６）パーティションの生成 パーティション登録チケット（ＰＲＴ）の検証、ＰＲＴ
発行者（PRT Issuer）、ＰＲＴユーザの検証に成功する
と、パーティション登録チケット（ＰＲＴ）に記述され
たルールに従ってパーティションがデバイスのメモリ部
に生成（図６０、図６１参照）される。 （７）鍵データ書き込み パーティションがデバイスのメモリ部に生成されると、
生成されたパーティション内に対する各種鍵の格納処理
が実行される。

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

【０５７３】以上の処理によって、相互認証（公開
鍵）、チケット（ＰＲＴ）検証（共通鍵）の各方式に従
ったパーティションの生成処理が実行される。

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

【０５７５】（１）パーティション登録チケット（ＰＲ
Ｔ）の発行処理 パーティション登録チケット（ＰＲＴ）は、デバイスマ
ネージャの管理するパーティション登録チケット発行手
段（ＰＲＴ Ticket Issuer）によりパーティションマネ
ージャ（ＰＭ）に対して発行される。この場合、共通鍵
方式の検証値としてＭＡＣ（図５９参照）がＰＲＴに付
加される。

【０５７６】（２）ＰＲＴのＰＭに対する供給 デバイスマネージャの管理するパーティション登録チケ
ット発行手段（ＰＲＴTicket Issuer）により発行され
たパーティション登録チケット（ＰＲＴ）は、パーティ
ションマネージャに対して送信される。

【０５７７】（３）ＰＭとデバイス間の相互認証 発行されたＰＲＴに従ったパーティションを生成しよう
とする対象のデバイスと、パーティションマネージャ
（具体的にはチケットユーザであるデバイスアクセス機
器としてのリーダライタ）は、共通鍵方式の相互認証
（図５３、図５４参照）を実行する。

【０５７８】（４）ＰＲＴの送信 パーティションマネージャは発行されたパーティション
登録チケット（ＰＲＴ）をデバイスに送付する。デバイ
スは、受信したパーティション登録チケット（ＰＲＴ）
についてＭＡＣ検証処理を実行し、ＰＲＴ発行者（PRT
Issuer）の検証、さらに、ＰＲＴチケットに格納された
ＰＲＴユーザ（この場合はＰＭ：チケットユーザである
デバイスアクセス機器としてのリーダライタ）とパーテ
ィションマネージャの識別子の一致を確認し、相互認証
済みであることを確認することによりＰＲＴユーザ（Ｐ
Ｍ：デバイスアクセス機器としてのリーダライタ）の検
証（図５７、図５８参照）を実行する。

【０５７９】（５）パーティションの生成 パーティション登録チケット（ＰＲＴ）の検証、ＰＲＴ
発行者（PRT Issuer）、ＰＲＴユーザの検証に成功する
と、パーティション登録チケット（ＰＲＴ）に記述され
たルールに従ってパーティションがデバイスのメモリ部
に生成（図６０、図６１参照）される。

【０５８０】（６）鍵データ書き込み パーティションがデバイスのメモリ部に生成されると、
生成されたパーティション内に対する各種鍵の格納処理
が実行される。 （７）公開鍵の読み出し、 （８）公開鍵証明書の発行 生成パーティションに対する各種サービス時の認証処理
（パーティション生成、ファイル生成、ファイルアクセ
ス、データアップデート等のサービス利用時の認証処
理）に際し、公開鍵認証を行なう場合、デバイスは公開
鍵、秘密鍵の鍵ペアを生成し、生成した公開鍵をパーテ
ィションマネージャに送信し、登録局、認証局を介して
公開鍵証明書の発行処理を行ない、発行された公開鍵証
明書をパーティション鍵領域（図２３参照）に格納す
る。この際、生成した公開鍵の格納領域に対して発行さ
れた公開鍵証明書を格納する。なお、この（７）、
（８）の処理は、作成パーティションに対する各種サー
ビス時の認証処理（パーティション生成、ファイル生
成、ファイルアクセス、データアップデート等のサービ
ス利用時の認証処理）の際に公開鍵認証を行なう構成の
場合に実行すればよい。

【０５８１】以上の処理によって、相互認証（共通
鍵）、チケット（ＰＲＴ）検証（公開鍵）の各方式に従
ったパーティションの生成処理が実行される。

【０５８２】（Ｄ）相互認証（共通鍵）、チケット（Ｐ
ＲＴ）検証（公開鍵） 次に、相互認証処理に共通鍵方式を適用し、チケット
（ＰＲＴ）検証に公開鍵方式を適用する場合の各エンテ
ィテイ間のデータ転送について図７１を用いて説明す
る。図に示す番号順に各エンティテイ間でデータ転送が
実行される。以下、各番号に従って処理を説明する。

【０５８３】（１）デバイスマネージャ（ＤＭ）の公開
鍵証明書（Ｃｅｒｔ．ＤＭ）の発行、 公開鍵証明書（Ｃｅｒｔ．ＤＭ）は、認証局（ＣＡ）に
よってデバイスマネージャの発行要求により、登録局を
介した証明書発行手続きによってデバイスマネージャに
対して発行される。

【０５８４】（２）パーティション登録チケット（ＰＲ
Ｔ）の発行処理 パーティション登録チケット（ＰＲＴ）は、デバイスマ
ネージャの管理するパーティション登録チケット発行手
段（ＰＲＴ Ticket Issuer）によりパーティションマネ
ージャ（ＰＭ）に対して発行される。この場合、公開鍵
方式の署名生成、検証を実行するため、デバイスマネー
ジャの秘密鍵による署名(Signature)が生成（図１２参
照）されてＰＲＴに付加される。 （３）ＰＲＴおよびＤＭ公開鍵証明書（Ｃｅｒｔ．Ｄ
Ｍ）のＰＭに対する供給 デバイスマネージャの管理するパーティション登録チケ
ット発行手段（ＰＲＴTicket Issuer）により発行され
たパーティション登録チケット（ＰＲＴ）は、ＤＭ公開
鍵証明書（Ｃｅｒｔ．ＤＭ）とともにパーティションマ
ネージャに対して送信される。

【０５８５】（４）ＰＭとデバイス間の相互認証 発行されたＰＲＴに従ったパーティションを生成しよう
とする対象のデバイスと、パーティションマネージャ
（具体的にはチケットユーザであるデバイスアクセス機
器としてのリーダライタ）は、共通鍵方式の相互認証
（図５３、図５４参照）を実行する。

【０５８６】（５）ＰＲＴおよびＤＭ公開鍵証明書（Ｃ
ｅｒｔ．ＤＭ）のデバイスに対する供給 ＰＭとデバイス間の相互認証が成立すると、パーティシ
ョンマネージャ（ＰＭ）は、デバイスに対してパーティ
ション登録チケット（ＰＲＴ）、およびＤＭ公開鍵証明
書（Ｃｅｒｔ．ＤＭ）を送信する。デバイスは、受信し
たパーティション登録チケット（ＰＲＴ）について、
（１）チケット発行者（Ticket Issuer）＝ＤＭの公開
鍵証明書（ＣＥＲＴ）が改竄されたものでない正当な公
開鍵証明書（ＣＥＲＴ）であること、（２）チケット発
行者（Ticket Issuer）の公開鍵証明書（ＣＥＲＴ）の
オプション領域に記録されたコードと、デバイス内のＤ
ＫＤＢ（Device Key Definition Block）(PUB)に記録さ
れたチケット発行手段コード（ＰＲＴＩＣ：PRT Issuer
Code）の一致、（３）チケット発行手段（Ticket Issu
er）がリボークされていないこと、（４）受信チケット
（ＰＲＴ）の署名（Signature）の検証によりチケット
が改竄のないことの確認を実行し、さらに、ＰＲＴチケ
ットに格納されたＰＲＴユーザ（この場合はＰＭ：チケ
ットユーザであるデバイスアクセス機器としてのリーダ
ライタ）とパーティションマネージャの公開鍵証明書中
の識別データ（ＤＮ）として記録された識別子またはカ
テゴリまたはシリアル（ＳＮ）の一致を確認し、相互認
証済みであることを確認することによりＰＲＴユーザ
（ＰＭ：デバイスアクセス機器としてのリーダライタ）
の検証（図５７、図５８参照）を実行する。

【０５８７】（６）パーティションの生成 パーティション登録チケット（ＰＲＴ）の検証、ＰＲＴ
発行者（PRT Issuer）、ＰＲＴユーザの検証に成功する
と、パーティション登録チケット（ＰＲＴ）に記述され
たルールに従ってパーティションがデバイスのメモリ部
に生成（図６０、図６１参照）される。

【０５８８】（７）鍵データ書き込み パーティションがデバイスのメモリ部に生成されると、
生成されたパーティション内に対する各種鍵の格納処理
が実行される。 （８）公開鍵の読み出し、 （９）公開鍵証明書の発行 生成パーティションに対する各種サービス時の認証処理
（パーティション生成、ファイル生成、ファイルアクセ
ス、データアップデート等のサービス利用時の認証処
理）に際し、公開鍵認証を行なう場合、デバイスは公開
鍵、秘密鍵の鍵ペアを生成し、生成した公開鍵をパーテ
ィションマネージャに送信し、登録局、認証局を介して
公開鍵証明書の発行処理を行ない、発行された公開鍵証
明書をパーティション鍵領域（図２３参照）に格納す
る。この際、生成した公開鍵の格納領域に対して発行さ
れた公開鍵証明書を格納する。なお、この（８）、
（９）の処理は、作成パーティションに対する各種サー
ビス時の認証処理（パーティション生成、ファイル生
成、ファイルアクセス、データアップデート等のサービ
ス利用時の認証処理）の際に公開鍵認証を行なう構成の
場合に実行すればよい。

【０５８９】以上の処理によって、相互認証（共通
鍵）、チケット（ＰＲＴ）検証（公開鍵）の各方式に従
ったパーティションの生成処理が実行される。

【０５９０】［Ｂ４．４．ファイル登録チケット（ＦＲ
Ｔ）を利用したファイル生成、削除処理］次に、デバイ
スに生成したパーティション内にファイル登録チケット
（ＦＲＴ）を適用してファイルを生成、または削除する
処理について説明する。図７２以下のフロー他の図面を
参照して説明する。なお、ファイル作成、削除処理に
は、デバイスとデバイスアクセス機器としてのリーダラ
イタ（パーティションマネージャ）間における相互認証
処理（デバイス認証またはパーティション認証）、パー
ティション登録チケット（ＦＲＴ：File Registration
Ticket）の正当性検証処理が含まれる。

【０５９１】図７２に示すファイル生成、削除処理フロ
ーについて説明する。図７２において、左側がパーティ
ションマネージャのファイル作成・削除装置、右側がデ
バイス（図５参照）の処理を示す。なお、パーティショ
ンマネージャのファイル作成・削除装置は、デバイスに
対するデータ読み取り書き込み処理可能な装置（ｅｘ．
デバイスアクセス機器としてのリーダライタ、ＰＣ）で
あり、図１０のデバイスアクセス機器としてのリーダラ
イタに相当する。まず、図７２を用いて、ファイル作
成、削除処理の概要を説明し、その後、当処理に含まれ
るファイル作成、削除操作の詳細を図７３のフローを用
いて説明する。

【０５９２】まず、図７２のステップＳ８０１とＳ８１
０において、ファイル作成・削除装置とデバイス間にで
の相互認証処理が実行される。データ送受信を実行する
２つの手段間では、相互に相手が正しいデータ通信者で
あるか否かを確認して、その後に必要なデータ転送を行
なうことが行われる。相手が正しいデータ通信者である
か否かの確認処理が相互認証処理である。相互認証処理
時にセッション鍵の生成を実行して、生成したセッショ
ン鍵を共有鍵として暗号化処理を実行してデータ送信を
行なう。

【０５９３】相互認証処理については、先のパーティシ
ョン生成、削除処理の欄で説明したと同様の処理であ
り、パーティション認証が実行される。それぞれについ
て共通鍵方式認証、あるいは公開鍵方式認証処理のいず
れかが適用される。この相互認証処理は、前述の図４８
〜図５６を用いて説明したと同様の処理であるので説明
を省略する。

【０５９４】なお、相互認証処理として実行すべき処理
は、適用するファイル登録チケット（ＦＲＴ）（図２７
参照）の * Authentication Flag :チケット（Ticket）の利用処
理においてデバイス（Device）との相互認証が必要か否
かを示すフラグ * Authentication Type :デバイス（Device）の相互認
証のタイプ（公開鍵認証、または、共通鍵認証、また
は、いずれでも可（Any））によって決定される。

【０５９５】認証処理に失敗した場合（Ｓ８０２，Ｓ８
１１でＮｏ）は、相互が正当な機器、デバイスであるこ
との確認がとれないことを示し、以下の処理は実行され
ずエラーとして処理は終了する。

【０５９６】認証処理に成功すると、ファイル作成・削
除装置は、デバイスに対してファイル登録チケット（Ｆ
ＲＴ：File Registration Ticket）を送信する。ファイ
ル登録チケット（ＦＲＴ）は、パーティションマネージ
ャの管理下のファイル登録チケット（ＦＲＴ）発行手段
（FRT Issuer）により発行されるチケットである。ファ
イル登録チケット（ＦＲＴ）は、デバイスに対するアク
セス制御チケットであり、先に説明した図２７のデータ
フォーマット構成を持つチケットである。

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

【０５９８】ファイル登録チケット（ＦＲＴ）を受信
（Ｓ８１２）したデバイスは、受信したチケット（ＦＲ
Ｔ）の正当性と利用者チェック処理を実行（Ｓ８１３）
する。チケットの正当性の検証処理は、共通鍵方式によ
るＭＡＣ検証、あるいは公開鍵方式による署名検証処理
のいずれかを適用して実行される。利用者チェックは、
チケットを送信してきた機器（チケット利用者）の正当
性をチェックする処理であり、相互認証が成立済みであ
り、認証相手の識別データと、チケットに記録されてい
るチケットユーザ識別子（図２７参照）との一致等を検
証する処理として実行される。これらの処理は、先のパ
ーティション登録チケット（ＰＲＴ）の適用処理につい
ての説明中、図５７〜図５９を用いて説明したと同様の
処理であるので説明を省略する。

【０５９９】デバイスにおいて、受信チケット（ＦＲ
Ｔ）の正当性と利用者チェック処理の結果、チケットお
よび利用者の正当なことが確認できなかった場合（Ｓ８
１４でＮｏ）は、ファイル登録チケット（ＦＲＴ）受理
エラーをファイル作成・削除装置に通知（Ｓ８１８）す
る。チケットおよび利用者の正当なことが確認できた場
合（Ｓ８１４でＹｅｓ）は、受信したファイル登録チケ
ット（ＦＲＴ）に記述されたルールに従いデバイス内の
メモリ部におけるファイルの生成、または削除処理を実
行する。この処理の詳細については、別フローを用いて
後段で詳述する。

【０６００】ファイル登録チケット（ＦＲＴ）の記述に
従って、ファイルの生成または削除処理に成功（Ｓ８１
６でＹｅｓ）すると、ＦＲＴ受理成功をファイル作成・
削除装置に通知（Ｓ８１７）する。一方、ファイルの生
成または削除処理に失敗（Ｓ８１６でＮｏ）した場合
は、ＦＲＴ受理エラーをファイル作成・削除装置に通知
（Ｓ８１８）する。

【０６０１】ファイル作成・削除装置は、ＦＲＴ受理結
果を受信（Ｓ８０４）し、ＦＲＴ処理結果を判定し、Ｆ
ＲＴ受理結果がエラーである場合（Ｓ８０５でＮｏ）
は、エラーとして処理を終了し、ＦＲＴ受理結果が成功
（Ｓ８０５でＹｅｓ）である場合はセッションクリアコ
マンドの送受信（Ｓ８０６，Ｓ８１９）を実行し、デバ
イス側に生成した認証テーブルを破棄（Ｓ８２０）し、
処理を終了する。認証テーブルは、ステップＳ８０１，
Ｓ８１０の相互認証処理において生成されるテーブルで
あり、前述したパーティション登録チケット（ＰＲＴ）
の適用処理の項目において説明した構成、すなわち、図
５１の構成と同様のものである。

【０６０２】このようにファイル登録チケット（ＦＲ
Ｔ）を利用して、デバイス内に設定されたパーティショ
ン内にファイルの生成、または生成済みのファイルの削
除処理が実行される。以下、当処理に含まれるファイル
の生成、削除処理（Ｓ８１５）について、図７３を用い
て説明する。

【０６０３】（ファイル作成・削除処理）図７２のフロ
ーに示すステップＳ８１５において実行されるファイル
登録チケット（ＦＲＴ）に基づくパーティションの作
成、削除処理の詳細について、図７３の処理フローを用
いて説明する。ファイルの作成、削除処理は、チケット
ユーザ（ｅｘ．デバイスアクセス機器としてのリーダラ
イタ、ＰＣ等）からファイル登録チケット（ＦＲＴ）を
受信したデバイスが、ファイル登録チケット（ＦＲＴ）
に基づいて実行する処理である。

【０６０４】図７３のステップＳ８２１において、デバ
イスは、受信したファイル登録チケット（ＦＲＴ:File
Registration ticket）に記録された処理タイプ、すな
わちOperation Type（パーティション（Partition）作
成か削除かの指定 (作成（Generate） / 削除（Delet
e)））を検証する。処理タイプ（Operation Type）が、
ファイル作成である場合、ステップＳ８２２以下を実行
し、ファイル削除である場合、ステップＳ８４１以下を
実行する。

【０６０５】まず、ファイル作成処理について説明す
る。デバイスはステップＳ８２２において、ファイル登
録チケット（ＦＲＴ）に記述されたファイル識別子（Ｉ
Ｄ）と同一ＩＤのファイルがデバイスの処理対象パーテ
ィション内に存在するか否かを検証する。この判定は、
デバイスのメモリ部に設定されたパーティション領域の
ファイル定義ブロック（図２４参照）に受信チケット
（ＦＲＴ）に記述されたファイルＩＤと同一のファイル
ＩＤが記述されているか否かを検証することによって判
定可能である。

【０６０６】すでにデバイスに同一ＩＤのファイルが存
在する場合は、同一ＩＤを持つ重複ファイルを同一のパ
ーティション内に存在させることは許されないので、フ
ァイルの生成は実行せず、エラー終了とする。同一ＩＤ
のファイルが処理対象パーティション内に存在しない場
合は、ステップＳ８２３において、パーティション管理
情報ブロック（図２０参照）のパーティション内の空き
ブロック数（Free Block Number in Partition）と、フ
ァイル登録チケット（ＦＲＴ）に記述されたファイルサ
イズ（File Size）とを比較し、チケット（ＦＲＴ）に
記述されたファイルサイズ（File Size）以上の空きブ
ロック領域がデバイスの処理対象パーティション内に存
在するか否かを判定する。存在しない場合は、ＦＲＴに
記述されたサイズのファイルの生成はできないので、エ
ラー終了とする。

【０６０７】チケット（ＦＲＴ）に記述されたファイル
サイズ（File Size）以上の空きブロック領域がデバイ
スのメモリ部の処理対象パーティション内に存在すると
判定された場合は、ステップＳ８２４に進み、パーティ
ション管理情報ブロックの空き領域ポインタ（Pointer
of Free Area）を参照してパーティションの空き領域
（Free Area in Partition）の最上位ブロックにファイ
ル定義ブロック（ＦＤＢ）エリア（図２４参照）を確保
する。

【０６０８】次に、デバイスは、確保したファイル定義
ブロック（ＦＤＢ）エリアに、ファイル登録チケット
（ＦＲＴ）に記述されたファイルＩＤのコピーを実行
（Ｓ８２５）し、さらに、ファイル定義ブロック（ＦＤ
Ｂ）エリアのファイルスタート位置（File Start Posit
ion）に、パーティション管理情報ブロック（図２０参
照）の空き領域ポインタ（Pointer of Free Area）のコ
ピー処理を実行（Ｓ８２６）する。

【０６０９】さらに、ステップＳ８２７において、ファ
イル定義ブロック（ＦＤＢ）のファイルサイズ（File S
ize）、サービス許可チケット発行手段コード（ＳＰＴ
ＩＣ）、およびバージョン、（ＳＰＴＩＣ Version）、
ファイル構造タイプ（File Structure Type Code）、フ
ァイルアクセスを行う際に、指定する認証方式（Accept
able Authentication Type）、指定する検証方式（Acce
ptable VerificztionType）のそれぞれに、ファイル登
録チケット（ＦＲＴ）に記述された各対応データをコピ
ーする。

【０６１０】次に、ステップＳ８２８において、ファイ
ル登録チケット（ＦＲＴ）に格納されたKspt_Encrypted
（ファイル定義ブロック（File Definition Block）に
記載されるサービス許可チケット（ＳＰＴ）のＭＡＣ検
証用鍵 Kspt を そのパーティションのファイル登録チ
ケットのＭＡＣ検証用鍵 Kfrt で暗号化したデータKfrt
（Kspt））をファイル登録チケットのＭＡＣ検証用鍵 K
frtを用いて復号してファイル定義ブロック（ＦＤＢ）
に格納する。なお、ファイル登録チケットのＭＡＣ検証
用鍵 Kfrtは、パーティションの生成時にパーティショ
ン鍵領域に格納済みである。

【０６１１】次に、ステップＳ８２９において、パーテ
ィション管理情報ブロック（図２０参照）のパーティシ
ョン（Partition）内の空きブロック数（Free Block Nu
mberin Partition）からファイルサイズ（File Size）
＋１を減算する。なお、＋１は、ファイル定義ブロック
（ＦＤＢ）用のブロックを意味する。

【０６１２】次に、ステップＳ８３０において、パーテ
ィション管理情報ブロック（図２０参照）の空き領域ポ
インタ（Pointer of Free Area）に生成したファイルサ
イズ（File Size）を加算し、ステップＳ８３１におい
て、パーティション管理情報ブロックのファイル数（Fi
le Number）に１を加算、すなわち生成したファイル数
（１）を加算する。

【０６１３】次に、ステップＳ８３２において、ファイ
ル登録チケット（ＦＲＴ）に格納されたFile Structure
（生成するファイル（File）のファイル構造（Structur
e））に応じた初期化処理を実行する。例えばファイル
構造がランダム(Random)であれば、０リセット、サイク
リック（Cyslic）であれば、ポインタ、データを０リセ
ットするなどの処理を実行する。これらの処理により、
生成したパーティション内に新たなファイルが生成され
る。

【０６１４】次に図７３のステップＳ８４１〜Ｓ８４８
のファイル削除処理について説明する。ステップＳ８４
１では、ファイル登録チケット（ＦＲＴ）に記述された
ファイルＩＤと同一ＩＤのファイルがデバイスのメモリ
部の処理対象パーティション内に存在するか否かを検証
する。この判定は、デバイスのメモリ部のファイル定義
ブロック（図２４参照）に受信チケット（ＦＲＴ）に記
述されたファイルＩＤと同一のファイルＩＤが記述され
ているか否かを検証することによって判定可能である。

【０６１５】デバイスの処理対象パーティション内に同
一ファイルＩＤのファイルが存在しない場合は、ファイ
ルの削除は不可能であるので、エラー終了とする。同一
ＩＤのファイルがデバイスの処理対象パーティション内
に存在する場合は、ステップＳ８４２において、削除対
象のファイルより後に生成されたファイルが処理対象パ
ーティション内に存在するか否かを判定する。存在しな
い場合は、削除対象のファイルが最新のファイルであ
り、ステップＳ８４９において削除対象のファイルのフ
ァイル定義ブロック（ＦＤＢ）（図２４参照）を削除す
る。

【０６１６】ステップＳ８４２において、削除対象のフ
ァイルより後に生成されたファイルが処理対象パーティ
ション内に存在すると判定された場合は、後に生成され
たファイル（後ファイル）のデータを削除対象のファイ
ルのサイズ（ＦＳ）分、下位にずらす処理を実行（Ｓ８
４３）し、さらに、後ファイルのファイル定義ブロック
（ＦＤＢ）を１ブロック上位にずらす処理を実行（Ｓ８
４４）する。また、後ファイルのファイル定義ブロック
（ＦＤＢ）に記録されたファイル開始位置（File Start
Portion）から削除ファイルのサイズ（ＦＳ）を減算す
る処理を実行する（Ｓ８４５）。

【０６１７】ステップＳ８４５またはＳ８４９の処理の
後、ステップＳ８４６において、パーティション管理情
報ブロック（ＰＭＩＢ）（図２０参照）のパーティショ
ン内の空きブロック数（Free Block Number in Partiti
on）に削除ファイルのサイズ（ＦＳ）＋１を加算する。
＋１は、削除ファイルのファイル定義ブロック（ＦＤ
Ｂ）用のブロックを意味する。

【０６１８】次にステップＳ８４７において、パーティ
ション管理情報ブロック（ＰＭＩＢ）（図２０参照）の
空き領域ポインタ（Pointer of Free Area）の値から削
除ファイルのサイズ（ＦＳ）を減算する。さらに、ステ
ップＳ８４８において、パーティション管理情報ブロッ
ク（ＰＭＩＢ）（図２０参照）のファイル数（File Num
ber）から１を減算、すなわち削除したファイル数
（１）を減算してファイル登録チケット（ＦＲＴ）に基
づくファイル削除処理が終了する。

【０６１９】以上が、図７２の処理フローにおけるステ
ップＳ８１５のファイル登録チケット（ＦＲＴ）に基づ
くファイル生成、削除処理である。

【０６２０】パーティションマネージャによるファイル
生成処理が完了した状態のデバイスのメモリ内格納デー
タ構成例を図７４に示す。図７４に示すパーティション
(Partion)領域中、 ファイル定義ブロック（１〜Ｎ）(File Definition Blo
ck) パーティション鍵領域（Partition Key Area） 共通鍵系パーティション鍵情報ブロック（Partition Ke
y Definition Block(Common)) 公開鍵系パーティション鍵情報ブロック（Partition Ke
y Definition Block(PUB)） パーティション管理情報ブロック（Partition Manageme
nt Information Block） の各データは、ファイル生成時、またはパーティション
生成時に書き込まれるデータである。ファイル領域(Fil
e Data Area １〜Ｎ)は、ファイル生成処理によって処
理対象パーティション内にファイル領域として確保され
る。

【０６２１】［Ｂ４．５．ファイル生成処理各方式にお
ける処理手順］上述したファイルの設定登録処理におい
て、パーティションマネージャが管理し、ファイル登録
チケットユーザであるデバイスアクセス機器としてのリ
ーダライタとデバイス間において、相互認証が実行さ
れ、ファイル登録チケット（ＦＲＴ）に基づくファイル
の設定がなされる。相互認証処理の態様は、公開鍵相互
認証、共通鍵相互認証の２種類のいずれかであり、また
チケット（ＦＲＴ）の検証処理も公開鍵系の署名検証、
共通鍵系のＭＡＣ検証の２種類のいずれかが実行される
ことになる。すなわち処理態様としては大きく分けて、 （Ａ）相互認証（公開鍵）、チケット（ＦＲＴ）検証
（公開鍵） （Ｂ）相互認証（公開鍵）、チケット（ＦＲＴ）検証
（共通鍵） （Ｃ）相互認証（共通鍵）、チケット（ＦＲＴ）検証
（共通鍵） （Ｄ）相互認証（共通鍵）、チケット（ＦＲＴ）検証
（公開鍵） の４態様がある。

【０６２２】これらの４態様についての処理を、認証局
（ＣＡ（ＰＭ））、パーティションマネージャ（Ｐ
Ｍ）、デバイス、各エンティテイ間において実行される
データ転送処理を中心として図を用いて簡潔に説明す
る。

【０６２３】（Ａ）相互認証（公開鍵）、チケット（Ｆ
ＲＴ）検証（公開鍵） まず、相互認証処理に公開鍵方式を適用し、チケット
（ＦＲＴ）検証に公開鍵方式を適用する場合の各エンテ
ィテイ間のデータ転送について図７５を用いて説明す
る。

【０６２４】図に示す番号順に各エンティテイ間でデー
タ転送が実行される。以下、各番号に従って処理を説明
する。 （１）ファイル登録チケット発行手段（ＦＲＴ Issue
r）の公開鍵証明書（Ｃｅｒｔ．ＦＲＴ Issuer）の発
行、 ファイル登録チケット発行手段（ＦＲＴ Issuer）の公
開鍵証明書（Ｃｅｒｔ．ＦＲＴ Issuer）は、ファイル
登録チケット発行手段（ＦＲＴ Issuer）からの発行要
求により、登録局（ＲＡ）を介した証明書発行手続きに
よってパーティション対応認証局（ＣＡ（ＰＡＲ））か
ら発行される。なお、パーティションマネージャがファ
イル登録チケット発行手段（ＦＲＴ Issuer）を兼ねる
構成も可能であり、その場合は、ファイル登録チケット
発行手段（ＦＲＴ Issuer）の公開鍵証明書としてパー
ティションマネージャ（ＰＭ）の公開鍵証明書を使用可
能である。

【０６２５】（２）ファイル登録チケットユーザ（ＦＲ
Ｔ User）の公開鍵証明書（Ｃｅｒｔ．ＦＲＴ User）の
発行、 ファイル登録チケットユーザ（ＦＲＴ User：具体的に
は、デバイスに対してチケットを送信するデバイスアク
セス機器としてのリーダライタ）の公開鍵証明書（Ｃｅ
ｒｔ．ＦＲＴ User）は、ファイル登録チケットユーザ
（ＦＲＴ User）からの発行要求により、登録局（Ｒ
Ａ）を介した証明書発行手続きによってパーティション
対応認証局（ＣＡ（ＰＡＲ））によって発行される。な
お、パーティションマネージャがファイル登録チケット
ユーザ（ＦＲＴ User）を兼ねる構成も可能であり、そ
の場合は、ファイル登録チケットユーザ（ＦＲＴ Use
r）の公開鍵証明書としてパーティションマネージャ
（ＰＭ）の公開鍵証明書を使用可能である。

【０６２６】（３）ファイル登録チケット（ＦＲＴ）の
生成処理 ファイル登録チケット（ＦＲＴ）は、パーティションマ
ネージャの管理するファイル登録チケット発行手段（Ｆ
ＲＴ Ticket Issuer）により生成される。この場合、公
開鍵方式の署名生成、検証を実行するため、ファイル登
録チケット発行手段（ＦＲＴ Ticket Issuer）の秘密鍵
による署名(Signature)が生成（図１２参照）されてＦ
ＲＴに付加される。

【０６２７】（４）ＦＲＴおよびファイル登録チケット
発行手段（ＦＲＴ Ticket Issuer）公開鍵証明書（Ｃｅ
ｒｔ．ＦＲＴ Issuer）のファイル登録チケットユーザ
（ＦＲＴ User）に対する供給 パーティションマネージャの管理するファイル登録チケ
ット発行手段（ＦＲＴTicket Issuer）により発行され
たファイル登録チケット（ＦＲＴ）は、ファイル登録チ
ケット発行手段（ＦＲＴ Ticket Issuer）公開鍵証明書
（Ｃｅｒｔ．ＦＲＴ Issuer）とともにファイル登録チ
ケットユーザ（ＦＲＴ User）すなわち、デバイスに対
してチケットを送信する機器（ｅｘ．デバイスアクセス
機器としてのリーダライタ）に対して送信される。

【０６２８】（５）ファイル登録チケット発行手段とデ
バイス間の相互認証 パーティションマネージャ（具体的にはファイル登録チ
ケットユーザ（ＦＲＴUser）であるデバイスアクセス機
器としてのリーダライタ）は、ファイル登録チケット発
行手段（ＦＲＴ Ticket Issuer）の発行したファイル登
録チケット（ＦＲＴ）に従ったファイルを生成しようと
する対象のデバイスに対し、チケットユーザ（ＦＲＴ U
ser）の公開鍵証明書（Ｃｅｒｔ．ＦＲＴ User）をデバ
イスに送信し、公開鍵方式の相互認証（図５０参照）を
実行する。

【０６２９】（６）ＦＲＴおよびファイル登録チケット
発行手段（ＦＲＴ Ticket Issuer）公開鍵証明書（Ｃｅ
ｒｔ．ＦＲＴ Issuer）のデバイスに対する供給 パーティションマネージャ（ＰＭ）とデバイス間の相互
認証が成立すると、パーティションマネージャ（ＰＭ）
（具体的にはファイル登録チケットユーザ（ＦＲＴ Use
r）であるデバイスアクセス機器としてのリーダライ
タ）は、デバイスに対してファイル登録チケット（ＦＲ
Ｔ）、およびファイル登録チケット発行手段（ＦＲＴ T
icket Issuer）公開鍵証明書（Ｃｅｒｔ．ＦＲＴ Issue
r）を送信する。

【０６３０】デバイスは、受信したファイル登録チケッ
ト（ＦＲＴ）について、（１）チケット発行者（Ticket
Issuer）の公開鍵証明書（ＣＥＲＴ FRT Issuer）が改
竄されたものでない正当な公開鍵証明書（ＣＥＲＴ）で
あること、（２）チケット発行者（Ticket Issuer）の
公開鍵証明書（ＣＥＲＴFRT Issuer）のオプション領域
に記録されたコードと、デバイス内のＰＫＤＢ（Partit
ion Key Definition Block）(PUB)に記録されたチケッ
ト発行手段コード（FRTIC：FRT Issuer Category）の一
致、（３）チケット発行手段（Ticket Issuer）がリボ
ークされていないこと、（４）受信チケット（ＦＲＴ）
の署名（Signature）の検証によりチケットが改竄のな
いことの確認を実行し、さらに、ＦＲＴチケットに格納
されたＦＲＴユーザ（チケットユーザであるデバイスア
クセス機器としてのリーダライタ）とチケットユーザ
（ＦＲＴ User）の公開鍵証明書（Ｃｅｒｔ．ＦＲＴ Us
er）の識別データ（ＤＮ）として記録された識別子また
はカテゴリまたはシリアル（ＳＮ）名（ＤＮ）の一致を
確認し、相互認証済みであることを確認することにより
ＦＲＴユーザ（デバイスアクセス機器としてのリーダラ
イタ）の検証（図５７、図５８参照）を実行する。

【０６３１】（７）ＦＤＢにＳＰＴＩＣおよびＫｓｐｔ
を登録 デバイスは、ファイル定義ブロック（ＦＤＢ：File Def
inition Block）にサービス許可チケット（ＳＰＴ）ユ
ーザ（ＳＰＴＩＣ）（ｅｘ．デバイスのファイル内のデ
ータにアクセスを実行するデバイスアクセス機器として
のリーダライタ）とKspt（サービス許可チケット（ＳＰ
Ｔ）のＭＡＣ検証用鍵(Kspt)）を登録する（図７３のフ
ローにおけるステップＳ８２７，Ｓ８２８）。

【０６３２】（８）ファイルデータ領域の確保 デバイスは、処理対象パーティションにファイル登録チ
ケット（ＦＲＴ）に記述されたサイズを持つファイル領
域を確保する。

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

【０６３４】（Ｂ）相互認証（公開鍵）、チケット（Ｆ
ＲＴ）検証（共通鍵） 次に、相互認証処理に公開鍵方式を適用し、チケット
（ＦＲＴ）検証に共通鍵方式を適用する場合の各エンテ
ィテイ間のデータ転送について図７６を用いて説明す
る。

【０６３５】図に示す番号順に各エンティテイ間でデー
タ転送が実行される。以下、各番号に従って処理を説明
する。

【０６３６】（１）ファイル登録チケットユーザ（ＦＲ
Ｔ User）の公開鍵証明書（Ｃｅｒｔ．ＦＲＴ User）の
発行、 ファイル登録チケットユーザ（ＦＲＴ User：具体的に
は、デバイスに対してチケットを送信するデバイスアク
セス機器としてのリーダライタ）の公開鍵証明書（Ｃｅ
ｒｔ．ＦＲＴ User）は、ファイル登録チケットユーザ
（ＦＲＴ User）からの発行要求により、登録局（Ｒ
Ａ）を介した証明書発行手続きによってパーティション
対応認証局（ＣＡ（ＰＡＲ））によって発行される。な
お、パーティションマネージャがファイル登録チケット
ユーザ（ＦＲＴ User）を兼ねる構成も可能であり、そ
の場合は、ファイル登録チケットユーザ（ＦＲＴ Use
r）の公開鍵証明書としてパーティションマネージャ
（ＰＭ）の公開鍵証明書を使用可能である。

【０６３７】（２）ファイル登録チケット（ＦＲＴ）の
生成処理 ファイル登録チケット（ＦＲＴ）は、パーティションマ
ネージャの管理するファイル登録チケット発行手段（Ｆ
ＲＴ Ticket Issuer）により生成される。この場合、共
通鍵方式の検証値としてＭＡＣ(Message Authenticatio
n Code)（図５９参照）がFＲＴに付加される。

【０６３８】（３）ＦＲＴのファイル登録チケットユー
ザ（ＦＲＴ User）に対する供給 パーティションマネージャの管理するファイル登録チケ
ット発行手段（ＦＲＴTicket Issuer）により発行され
たファイル登録チケット（ＦＲＴ）は、ファイル登録チ
ケットユーザ（ＦＲＴ User）すなわち、デバイスに対
してチケットを送信する機器（ｅｘ．デバイスアクセス
機器としてのリーダライタ）に対して送信される。

【０６３９】（４）ファイル登録チケット発行手段とデ
バイス間の相互認証 パーティションマネージャ（具体的にはファイル登録チ
ケットユーザ（ＦＲＴUser）であるデバイスアクセス機
器としてのリーダライタ）は、ファイル登録チケット発
行手段（ＦＲＴ Ticket Issuer）の発行したファイル登
録チケット（ＦＲＴ）に従ったファイルを生成しようと
する対象のデバイスに対し、チケットユーザ（ＦＲＴ U
ser）の公開鍵証明書（Ｃｅｒｔ．ＦＲＴ User）をデバ
イスに送信し、公開鍵方式の相互認証（図５０参照）を
実行する。

【０６４０】（５）ＦＲＴのデバイスに対する供給 パーティションマネージャ（ＰＭ）とデバイス間の相互
認証が成立すると、パーティションマネージャ（ＰＭ）
（具体的にはファイル登録チケットユーザ（ＦＲＴ Use
r）であるデバイスアクセス機器としてのリーダライ
タ）は、デバイスに対してファイル登録チケット（ＦＲ
Ｔ）を送信する。デバイスは、受信したファイル登録チ
ケット（ＦＲＴ）についてＭＡＣ検証処理を実行し、Ｆ
ＲＴ発行者（FRT Issuer）の検証、さらに、ＦＲＴチケ
ットに格納されたＦＲＴユーザ（チケットユーザである
デバイスアクセス機器としてのリーダライタ）と受信し
たパーティションマネージャの公開鍵証明書の識別デー
タ（ＤＮ）として記録された識別子またはカテゴリまた
はシリアル（ＳＮ）名（ＤＮ）の一致を確認し相互認証
済みであることを確認することによりＦＲＴユーザ（Ｐ
Ｍ：デバイスアクセス機器としてのリーダライタ）の検
証（図５７、図５８参照）を実行する。

【０６４１】（６）ＦＤＢにＳＰＴＩＣおよびＫｓｐｔ
を登録 デバイスは、ファイル定義ブロック（ＦＤＢ：File Def
inition Block）にサービス許可チケット（ＳＰＴ）発
行者カテゴリ（ＳＰＴＩＣ）（ｅｘ．デバイスのファイ
ル内のデータにアクセスを実行するデバイスアクセス機
器としてのリーダライタ）とKspt（サービス許可チケッ
ト（ＳＰＴ）のＭＡＣ検証用鍵(Kspt)）を登録する（図
７３のフローにおけるステップＳ８２７，Ｓ８２８）。

【０６４２】（８）ファイルデータ領域の確保 デバイスは、処理対象パーティションにファイル登録チ
ケット（ＦＲＴ）に記述されたサイズを持つファイル領
域を確保する。

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

【０６４４】（Ｃ）相互認証（共通鍵）、チケット（Ｆ
ＲＴ）検証（共通鍵） 次に、相互認証処理に共通鍵方式を適用し、チケット
（ＦＲＴ）検証に共通鍵方式を適用する場合の各エンテ
ィテイ間のデータ転送について図７７を用いて説明す
る。

【０６４５】図に示す番号順に各エンティテイ間でデー
タ転送が実行される。以下、各番号に従って処理を説明
する。

【０６４６】（１）ファイル登録チケット（ＦＲＴ）の
生成処理 ファイル登録チケット（ＦＲＴ）は、パーティションマ
ネージャの管理するファイル登録チケット発行手段（Ｆ
ＲＴ Ticket Issuer）により生成される。この場合、共
通鍵方式の検証値としてＭＡＣ(Message Authenticatio
n Code)（図５９参照）がＦＲＴに付加される。

【０６４７】（２）ＦＲＴのファイル登録チケットユー
ザ（ＦＲＴ User）に対する供給 パーティションマネージャの管理するファイル登録チケ
ット発行手段（ＦＲＴTicket Issuer）により発行され
たファイル登録チケット（ＦＲＴ）は、ファイル登録チ
ケットユーザ（ＦＲＴ User）すなわち、デバイスに対
してチケットを送信する機器（ｅｘ．デバイスアクセス
機器としてのリーダライタ）に対して送信される。

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

【０６４９】（４）ＦＲＴのデバイスに対する供給 パーティションマネージャ（ＰＭ）とデバイス間の相互
認証が成立すると、パーティションマネージャ（ＰＭ）
（具体的にはファイル登録チケットユーザ（ＦＲＴ Use
r）であるデバイスアクセス機器としてのリーダライ
タ）は、デバイスに対してファイル登録チケット（ＦＲ
Ｔ）を送信する。デバイスは、受信したファイル登録チ
ケット（ＦＲＴ）についてＭＡＣ検証処理を実行し、Ｆ
ＲＴ発行者（FRT Issuer）の検証、さらに、ＦＲＴチケ
ットに格納されたＦＲＴユーザ（チケットユーザである
デバイスアクセス機器としてのリーダライタ）と受信し
たパーティションマネージャの識別子の一致を確認し相
互認証済みであることを確認することによりＦＲＴユー
ザ（ＰＭ：デバイスアクセス機器としてのリーダライ
タ）の検証（図５７、図５８参照）を実行する。

【０６５０】（６）ＦＤＢにＳＰＴＩＣおよびＫｓｐｔ
を登録 デバイスは、ファイル定義ブロック（ＦＤＢ：File Def
inition Block）にサービス許可チケット（ＳＰＴ）発
行者カテゴリ（ＳＰＴＩＣ）（ｅｘ．デバイスのファイ
ル内のデータにアクセスを実行するデバイスアクセス機
器としてのリーダライタ）とKspt（サービス許可チケッ
ト（ＳＰＴ）のＭＡＣ検証用鍵(Kspt)）を登録する（図
７３のフローにおけるステップＳ８２７，Ｓ８２８）。

【０６５１】（８）ファイルデータ領域の確保 デバイスは、処理対象パーティションにファイル登録チ
ケット（ＦＲＴ）に記述されたサイズを持つファイル領
域を確保する。

【０６５２】以上の処理によって、相互認証（共通
鍵）、チケット（ＦＲＴ）検証（共通鍵）の各方式に従
ったファイルの生成処理が実行される。

【０６５３】（Ｄ）相互認証（共通鍵）、チケット（Ｆ
ＲＴ）検証（公開鍵） 次に、相互認証処理に共通鍵方式を適用し、チケット
（ＦＲＴ）検証に公開鍵方式を適用する場合の各エンテ
ィテイ間のデータ転送について図７８を用いて説明す
る。

【０６５４】図に示す番号順に各エンティテイ間でデー
タ転送が実行される。以下、各番号に従って処理を説明
する。 （１）ファイル登録チケット発行手段（ＦＲＴ Issue
r）の公開鍵証明書（Ｃｅｒｔ．ＦＲＴ Issuer）の発
行、 ファイル登録チケット発行手段（ＦＲＴ Issuer）の公
開鍵証明書（Ｃｅｒｔ．ＦＲＴ Issuer）は、ファイル
登録チケット発行手段（ＦＲＴ Issuer）からの発行要
求により、登録局（ＲＡ）を介した証明書発行手続きに
よってパーティション対応認証局（ＣＡ（ＰＡＲ））か
ら発行される。なお、パーティションマネージャがファ
イル登録チケット発行手段（ＦＲＴ Issuer）を兼ねる
構成も可能であり、その場合は、ファイル登録チケット
発行手段（ＦＲＴ Issuer）の公開鍵証明書としてパー
ティションマネージャ（ＰＭ）の公開鍵証明書を使用可
能である。

【０６５５】（２）ファイル登録チケット（ＦＲＴ）の
生成処理 ファイル登録チケット（ＦＲＴ）は、パーティションマ
ネージャの管理するファイル登録チケット発行手段（Ｆ
ＲＴ Ticket Issuer）により生成される。この場合、公
開鍵方式の署名生成、検証を実行するため、ファイル登
録チケット発行手段（ＦＲＴ Ticket Issuer）の秘密鍵
による署名(Signature)が生成（図１２参照）されてＦ
ＲＴに付加される。

【０６５６】（３）ＦＲＴおよびファイル登録チケット
発行手段（ＦＲＴ Ticket Issuer）公開鍵証明書（Ｃｅ
ｒｔ．ＦＲＴ Issuer）のファイル登録チケットユーザ
（ＦＲＴ User）に対する供給 パーティションマネージャの管理するファイル登録チケ
ット発行手段（ＦＲＴTicket Issuer）により発行され
たファイル登録チケット（ＦＲＴ）は、ファイル登録チ
ケット発行手段（ＦＲＴ Ticket Issuer）公開鍵証明書
（Ｃｅｒｔ．ＦＲＴ Issuer）とともにファイル登録チ
ケットユーザ（ＦＲＴ User）すなわち、デバイスに対
してチケットを送信する機器（ｅｘ．デバイスアクセス
機器としてのリーダライタ）に対して送信される。

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

【０６５８】（５）ＦＲＴおよびファイル登録チケット
発行手段（ＦＲＴ Ticket Issuer）公開鍵証明書（Ｃｅ
ｒｔ．ＦＲＴ Issuer）のデバイスに対する供給 パーティションマネージャ（ＰＭ）とデバイス間の相互
認証が成立すると、パーティションマネージャ（ＰＭ）
（具体的にはファイル登録チケットユーザ（ＦＲＴ Use
r）であるデバイスアクセス機器としてのリーダライ
タ）は、デバイスに対してファイル登録チケット（ＦＲ
Ｔ）、およびファイル登録チケット発行手段（ＦＲＴ T
icket Issuer）公開鍵証明書（Ｃｅｒｔ．ＦＲＴ Issue
r）を送信する。

【０６５９】デバイスは、受信したファイル登録チケッ
ト（ＦＲＴ）について、（１）チケット発行者（Ticket
Issuer）の公開鍵証明書（ＣＥＲＴ FRT Issuer）が改
竄されたものでない正当な公開鍵証明書（ＣＥＲＴ）で
あること、（２）チケット発行者（Ticket Issuer）の
公開鍵証明書（ＣＥＲＴFRT Issuer）のオプション領域
に記録されたコードと、、デバイス内のＰＫＤＢ（Part
ition Key DefinitionBlock）(PUB)に記録されたチケッ
ト発行手段コード（FRTIC：FRT Issuer Category）の一
致、（３）チケット発行手段（Ticket Issuer）がリボ
ークされていないこと、（４）受信チケット（ＦＲＴ）
の署名（Signature）の検証によりチケットが改竄のな
いことの確認を実行し、さらに、ＦＲＴチケットに格納
されたＦＲＴユーザ（チケットユーザであるデバイスア
クセス機器としてのリーダライタ）とチケットユーザ
（ＦＲＴ User）の識別子の一致を確認し、相互認証済
みであることを確認することによりＦＲＴユーザ（デバ
イスアクセス機器としてのリーダライタ）の検証（図５
７、図５８参照）を実行する。

【０６６０】（６）ＦＤＢにＳＰＴＩＣおよびＫｓｐｔ
を登録 デバイスは、ファイル定義ブロック（ＦＤＢ：File Def
inition Block）にサービス許可チケット（ＳＰＴ）発
行者カテゴリ（ＳＰＴＩＣ）（ｅｘ．デバイスのファイ
ル内のデータにアクセスを実行するデバイスアクセス機
器としてのリーダライタ）とKspt（サービス許可チケッ
ト（ＳＰＴ）のＭＡＣ検証用鍵(Kspt)）を登録する（図
７３のフローにおけるステップＳ８２７，Ｓ８２８）。

【０６６１】（７）ファイルデータ領域の確保 デバイスは、処理対象パーティションにファイル登録チ
ケット（ＦＲＴ）に記述されたサイズを持つファイル領
域を確保する。

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

【０６６３】［Ｂ４．６．サービス許可チケット（ＳＰ
Ｔ）を利用したサービス（ファイルアクセス）処理］次
に、サービス許可チケット（ＳＲＴ）（図２８、図３１
参照）を利用したファイルアクセス処理について説明す
る。図７９以下のフロー他の図面を参照して説明する。
なお、ファイルアクセス処理には、デバイスとファイル
アクセス装置間における相互認証処理（デバイス認証ま
たはパーティション認証）、サービス許可チケット（Ｓ
ＰＴ：Service Parmission Ticket）の正当性検証処理
が含まれる。

【０６６４】図７９のフローにおいて、左側がファイル
アクセス装置、右側がデバイス（図５参照）の処理を示
す。なお、ファイルアクセス装置は、パーティションマ
ネージャの管理装置であり、デバイスに対するデータ読
み取り書き込み処理可能な装置（ｅｘ．デバイスアクセ
ス機器としてのリーダライタ、ＰＣ）であり、図１０の
デバイスアクセス機器としてのリーダライタに相当す
る。まず、図７９を用いて、ファイルアクセス装置によ
るファイルアクセス処理の概要を説明し、その後、当処
理に含まれる各処理の詳細を図８０以下のフローを用い
て順次説明する。

【０６６５】まず、図７９のステップＳ８５１とＳ８６
０において、ファイルアクセス装置とデバイス間にでの
相互認証処理が実行される。データ送受信を実行する２
つの手段間では、相互に相手が正しいデータ通信者であ
るか否かを確認して、その後に必要なデータ転送を行な
うことが行われる。相手が正しいデータ通信者であるか
否かの確認処理が相互認証処理である。相互認証処理時
にセッション鍵の生成を実行して、生成したセッション
鍵を共有鍵として暗号化処理を実行してデータ送信を行
なう。

【０６６６】相互認証処理については、先のパーティシ
ョン生成、削除処理の欄で説明したと同様の処理であ
り、パーティション認証が実行される。それぞれについ
て共通鍵方式認証、あるいは公開鍵方式認証処理のいず
れかが適用される。この相互認証処理は、前述の図４８
〜図５６を用いて説明したと同様の処理であるので説明
を省略する。

【０６６７】なお、相互認証処理として実行すべき処理
は、適用するサービス許可チケット（ＳＰＴ）（図２
８、図３１参照）の * Authentication Flag :チケット（Ticket）の利用処
理においてデバイス（Device）との相互認証が必要か否
かを示すフラグ * Authentication Type :デバイス（Device）の相互認
証のタイプ（公開鍵認証、または、共通鍵認証、また
は、いずれでも可（Any））によって決定される。

【０６６８】認証処理に失敗した場合（Ｓ８５２，Ｓ８
６１でＮｏ）は、相互が正当な機器、デバイスであるこ
との確認がとれないことを示し、以下の処理は実行され
ずエラーとして処理は終了する。

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

【０６７０】また、デバイスは、複数のサービス許可チ
ケット（ＳＰＴ）の各々が異なる認証条件を定めている
場合は、各サービス許可チケット（ＳＰＴ）に設定され
たパーティション認証の認証成立を条件として、複数の
サービス許可チケット（ＳＰＴ）の指定ファイルに対す
るアクセスを許容する。

【０６７１】次にステップＳ８５３において、ファイル
アクセス装置は、デバイスに対してサービス許可チケッ
ト（ＳＰＴ：Service Parmission Ticket）を送信す
る。サービス許可チケット（ＳＰＴ）は、パーティショ
ンマネージャの管理下のサービス許可チケット（ＳＰ
Ｔ）発行手段（SPT Issuer）により発行されるチケット
である。サービス許可チケット（ＳＰＴ）は、デバイス
に対するアクセス制御チケットであり、先に説明した図
２８、図３１のデータフォーマット構成を持つチケット
である。

【０６７２】なお、サービス許可チケット（ＳＰＴ）
を、チケットユーザに対して送信する際には、公開鍵方
式の場合、サービス許可チケット（ＳＰＴ）発行手段
（SPT Issuer）の公開鍵証明書（CERT_SPTI）も一緒に
送信する。ＳＰＴ発行手段の公開鍵証明書（CERT_SPT
I）の属性（Attribute）は、デバイス内のＦＤＢ（File
Definition Block）に記録されたチケット発行手段コ
ード(SPTIC)と一致する。

【０６７３】ファイル登録チケット（ＳＰＴ）を受信
（Ｓ８６２）したデバイスは、受信したチケット（ＳＲ
Ｔ）の正当性と利用者チェック処理を実行（Ｓ８６３）
する。チケットの正当性の検証処理は、共通鍵方式によ
るＭＡＣ検証、あるいは公開鍵方式による署名検証処理
のいずれかを適用して実行される。利用者チェックは、
チケットを送信してきた機器（チケット利用者）の正当
性をチェックする処理であり、相互認証が成立済みであ
り、認証相手の識別データと、チケットに記録されてい
るチケットユーザ識別子（図２８、図３１参照）との一
致等を検証する処理として実行される。これらの処理
は、先のパーティション登録チケット（ＰＲＴ）の適用
処理についての説明中、図５７〜図５９を用いて説明し
たと同様の処理であるので説明を省略する。

【０６７４】デバイスにおいて、受信チケット（ＳＰ
Ｔ）の正当性と利用者チェック処理の結果、チケットお
よび利用者の正当なことが確認できなかった場合（Ｓ８
６４でＮｏ）は、サービス許可チケット（ＳＰＴ）受理
エラーをファイルアクセス装置に通知（Ｓ８６８）す
る。チケットおよび利用者の正当なことが確認できた場
合（Ｓ８６４でＹｅｓ）は、受信したサービス許可チケ
ット（ＳＰＴ）に記述されたルールに従いデバイス内の
メモリ部に格納されたファイルオープン処理が実行され
る。この処理の詳細については、別フローを用いて後段
で詳述する。

【０６７５】サービス許可チケット（ＳＰＴ）の記述に
従って、ファイルのオープン処理に成功（Ｓ８６６でＹ
ｅｓ）すると、ＳＰＴ受理成功をファイルアクセス装置
に通知（Ｓ８６７）する。一方、ファイルのオープン処
理に失敗（Ｓ８６６でＮｏ）した場合は、ＳＰＴ受理エ
ラーをファイルアクセス装置に通知（Ｓ８６８）する。

【０６７６】ファイルアクセス装置は、ＳＰＴ受理結果
を受信（Ｓ８５４）し、ＳＰＴ処理結果を判定し、ＳＰ
Ｔ受理結果がエラーである場合（Ｓ８５５でＮｏ）は、
エラーとして処理を終了し、ＳＰＴ受理結果が成功（Ｓ
８５５でＹｅｓ）である場合は、すべてのＳＰＴ送信が
終了したか否かを判定（Ｓ８５６）し、未送信ＳＰＴが
ある場合は、ステップＳ８５３以下を繰り返し実行す
る。

【０６７７】すべてのＳＰＴ送信が終了した場合は、ス
テップＳ８５７、Ｓ８６９においてサービス許可チケッ
ト（ＳＰＴ）に従ったファイルアクセスを実行し、ファ
イルアクセス処理の終了の後、セッションクリアコマン
ドの送受信（Ｓ８５８，Ｓ８７０）を実行し、デバイス
側に生成した認証テーブルを破棄（Ｓ８７１）し、処理
を終了する。ファイルアクセス処理の詳細については、
別フローを用いて後段で詳述する。なお、認証テーブル
は、ステップＳ８５１，Ｓ８６０の相互認証処理におい
て生成されるテーブルであり、前述したパーティション
登録チケット（ＰＲＴ）の適用処理の項目において説明
した構成、すなわち、図５１の構成と同様のものであ
る。

【０６７８】このようにサービス許可チケット（ＳＰ
Ｔ）を利用して、デバイス内に設定されたパーティショ
ン内のファイルに対するアクセス処理が実行される。以
下、当処理に含まれるファイルオープン処理（Ｓ８６
５）、各種ファイルアクセス処理（Ｓ８５７，Ｓ８６
９）について説明する。

【０６７９】（ファイルオープン処理）図８０のフロー
に従って、ファイルオープン処理（図７９、Ｓ８６５）
について説明する。ファイルオープン処理は、デバイス
が受信したサービス許可チケット（ＳＰＴ）に従って実
行する処理である。

【０６８０】ステップＳ８８１において、デバイスは、
受信したサービス許可チケット（ＳＰＴ）に指定された
ファイルがデバイス内に生成されて存在しているか否か
を判定する。サービス許可チケット（ＳＰＴ）には処理
対象ファイルのファイルＩＤが記録（図２８、図３１参
照）されており、同一のＩＤを持つファイルの有無を例
えばファイル定義ブロック（図２４）を参照して判定す
る。チケットに記述されたＩＤと同一ＩＤのファイルが
存在しない場合は、処理が不可能であるのでエラー終了
する。

【０６８１】チケットに記述されたＩＤと同一ＩＤのフ
ァイルが存在する場合は、ステップＳ８８２において、
ファイルオープンテーブルにサービス許可チケット（Ｓ
ＰＴ）に記述されたチケット発行手段（Ticket issuer
＝ＰＭＣ:Partition managerCode)と、サービス許可チ
ケット（ＳＰＴ）に記述されたファイルＩＤとを対応付
けたエントリを書き込む。

【０６８２】さらに、ステップＳ８８３において、ファ
イルオープンテーブルに生成したエントリに対応付けて
サービス許可チケット（ＳＰＴ）に記述されたファイル
アクセスモード［File Access Mode :アクセスを許諾す
るファイル（File）へのアクセスモード（Access Mod
e）］を書き込み、ステップＳ８８４において、サービ
ス許可チケット（ＳＰＴ）に記述されたアクセス許可グ
ループファイル［Groupof Target File :アクセスを許
すファイル（File）のグループ（Group）］を書き込
み、ステップＳ８８５において、サービス許可チケット
（ＳＰＴ）に記述されたアクセス許可ファイル識別子
［Target File ID :アクセスを許すファイル（File）の
識別子（ＩＤ）］の書き込み、さらにステップＳ８８６
において、サービス許可チケット（ＳＰＴ）に記述され
たターゲットファイル（Target File））に対する処理
態様データ［Read/Write Permission : アクセスを許す
ファイル（File）（ターゲットファイル（Target Fil
e））に対する処理態様（読み出し（Read）,書き込み
（Write）の許可）］の書き込み処理を行なう。なお、
ターゲットファイルに対する処理としては、読み出し
（Read）,書き込み（Write）に限らず、様々な処理を設
定可能である。

【０６８３】ファイルオープンテーブルの構成例を図８
１、図８２に示す。ファイルオープンテーブルは、デバ
イスにおいてアクセス処理状態にあるファイルおよびア
クセスモード他の情報を記録したテーブルであり、デバ
イスが受信したサービス許可チケット（ＳＰＴ）の記述
情報を記録してデバイスの記憶手段に格納する。

【０６８４】チケットが唯一のファイルに対してのみア
クセスを許可する形式のサービス許可チケット（図２８
参照）である場合は、ファイルオープンテーブルは、 *Ticket Issuer :チケット発行手段（Ticket Issuer）
の識別子 * File ID :パーティション内のアクセスファイル（Fil
e）の識別子（ＩＤ） * File Access Mode :アクセスを許諾するファイル（Fi
le）へのアクセスモード（Access Mode） の情報を格納する。この場合のファイルオープンテーブ
ルの構成例を図８１に示す。

【０６８５】図８１に示すように、ファイルオープンテ
ーブルにはグループ情報であるTicket Issuer :チケッ
ト発行手段（Ticket Issuer）の識別子として、パーテ
ィションマネージャコード（ＰＭＣ）が記述され、パー
ティションが判別され、ファイルＩＤによりファイルが
識別され、ファイルアクセスモードにより実行可能なア
クセス態様（ｅｘ．読み取り（ＲＥＡＤ）、書き込み
（Ｗｒｉｔｅ）、暗号化復号化（Ｅｎｃ，Ｄｅｃ））が
判定可能となる。

【０６８６】また、サービス許可チケット（ＳＰＴ）が
パーティションに設定されたファイル中の複数ファイル
に対してアクセスを許可する形式のサービス許可チケッ
ト（図３１参照）の場合は、上記情報に加えて * Group of Target File :アクセスを許すファイル（Fi
le）のグループ（Group） * Target File ID :アクセスを許すファイル（File）の
識別子（ＩＤ） * Read/Write Permission : アクセスを許すファイル
（File）（ターゲットファイル（Target File））に対
する処理態様（読み出し（Read）,書き込み（Write））
の許可 の各情報がテーブルに書き込まれる。この場合のファイ
ルオープンテーブルの構成例を図８２に示す。

【０６８７】図８２に示すように、複数ファイルに対し
てアクセスを許可する形式のサービス許可チケットに対
応して設定されるファイルオープンテーブルには、図８
１に示すデータの他に、アクセスを許すターゲットファ
イル（File）のグループとしてのパーティション識別デ
ータとしてのパーティションマネージャコード（ＰＭ
Ｃ）と、アクセスを許すターゲットファイル（File）の
識別子（ＩＤ）としてのファイルＩＤと、ターゲットフ
ァイル（Target File））に対する処理態様を示す［Rea
d/Write Permission］データが格納され、複数ファイル
に対する実行可能な処理が判定可能となる。

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

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

【０６９０】（ファイルアクセス処理）次に、図７９の
ステップＳ８５７、Ｓ８６９において実行されるファイ
ルアクセス処理の詳細について説明する。

【０６９１】まず、図８１に示すファイルオープンテー
ブルが生成された場合のアクセス処理について、図８３
を用いて説明する。図の左側に２つのファイルアクセス
装置（Ｒ／Ｗ：デバイスアクセス機器としてのリーダラ
イタ）７５０、７６０を示し、右側にファイルの生成さ
れたデバイス１００のパーティション部分を示す。

【０６９２】ファイルアクセス装置（Ｒ／Ｗ：リーダラ
イタ）７５０は、デバイスとの相互認証の後、 ファイルＩＤ：［０ｘ０００２］ ファイルアクセスモード：［読み取り：Ｒｅａｄ］ のアクセス許可チケットをデバイス１００に送信し、チ
ケットの正当性検証、チケット発行者、利用者検証に成
功したとする。

【０６９３】このとき、デバイスには図８１に示すファ
イルオープンテーブルの第２行のエントリが生成され
る。このエントリは、パーティションマネージャコード
（ＰＭＣ１）で識別されるパーティション内のファイル
ＩＤ［０ｘ０００２］に対してアクセスモード［読み取
り：Ｒｅａｄ］の処理が実行可能であることを示してい
る。

【０６９４】このとき、ファイルアクセス装置（Ｒ／
Ｗ：リーダライタ）７５０は、コマンドを生成してデバ
イスに対して送信する。例えばファイルＩＤ［０ｘ００
０２］のデータ読み取りコマンド：Ｒｅａｄ Ｃｏｍｍ
ａｎｄ（０ｘ０００２）をデバイスが受信すると、デバ
イスはファイルオープンテーブルのエントリを確認し、
ファイルＩＤ［０ｘ０００２］に対してアクセスモード
［読み取り：Ｒｅａｄ］の処理が実行可能であることを
確認し、読み取り処理を実行する。

【０６９５】また、ファイルアクセス装置（Ｒ／Ｗ：リ
ーダライタ）７５０が、例えばファイルＩＤ［０ｘ００
０２］のデータ書き込みコマンド：Ｗｒｉｔｅ Ｃｏｍ
ｍａｎｄ（０ｘ０００２）、あるいはファイルＩＤ［０
ｘ０００１］のデータの暗号化処理コマンド：Ｅｎｃｒ
ｙｐｔｉｏｎ Ｃｏｍｍａｎｄ（０ｘ０００１）をデバ
イスに送信した場合は、コマンドを受信したデバイスは
ファイルオープンテーブルのエントリを確認し、ファイ
ルＩＤ［０ｘ０００２］に対する［書き込み：Ｗｒｉｔ
ｅ］の処理、および、ファイルＩＤ［０ｘ０００１］の
［暗号化処理］が、ファイルアクセス装置（Ｒ／Ｗ：リ
ーダライタ）７５０から受領したサービス許可チケット
（ＳＰＴ）によって許可されていないことを確認し、処
理を停止する。

【０６９６】また、ファイルアクセス装置（Ｒ／Ｗ：リ
ーダライタ）７６０は、デバイスとの相互認証の後、 ファイルＩＤ：［０ｘ０００１］ ファイルアクセスモード：［暗号化復号化処理：Ｅｎｃ
＆Ｄｅｃ］ のアクセス許可チケットをデバイス１００に送信し、チ
ケットの正当性検証、チケット発行者、利用者検証に成
功したとする。

【０６９７】このとき、デバイスには図８１に示すファ
イルオープンテーブルの第１行のエントリが生成され
る。このエントリは、パーティションマネージャコード
（ＰＭＣ１）で識別されるパーティション内のファイル
ＩＤ［０ｘ０００１］に対してアクセスモード［暗号化
復号化処理：Ｅｎｃ＆Ｄｅｃ］の処理が実行可能である
ことを示している。

【０６９８】このとき、ファイルアクセス装置（Ｒ／
Ｗ：リーダライタ）７６０は、コマンドを生成してデバ
イスに対して送信する。例えばファイルＩＤ［０ｘ００
０１］の暗号化コマンド［Ｅｎｃｒｙｐｔｉｏｎ Ｃｏ
ｍｍａｎｄ（０ｘ０００１）］をデバイスが受信する
と、デバイスはファイルオープンテーブルのエントリを
確認し、ファイルＩＤ：０ｘ０００１に対してアクセス
モード［暗号化復号化処理：Ｅｎｃ＆Ｄｅｃ］の処理が
実行可能であることを確認し、暗号化処理を実行する。

【０６９９】また、ファイルアクセス装置（Ｒ／Ｗ：リ
ーダライタ）７６０が、例えばファイルＩＤ［０ｘ００
０２］のデータ読み取りコマンド：Ｒｅａｄ Ｃｏｍｍ
ａｎｄ（０ｘ０００２）をデバイスに送信した場合は、
コマンドを受信したデバイスはファイルオープンテーブ
ルのエントリを確認し、ファイルＩＤ［０ｘ０００２］
に対する［読み取り：Ｒｅａｄ］の処理が、ファイルア
クセス装置（Ｒ／Ｗ：リーダライタ）７６０から受領し
たサービス許可チケット（ＳＰＴ）によって許可されて
いないことを確認し、処理を停止する。

【０７００】このように、サービス許可チケットユーザ
であるデバイスアクセス機器としてのリーダライタから
デバイスが受信したサービス許可チケット（ＳＰＴ）に
基づいて、デバイスは、前述の図８０の処理フローに従
ってファイルオープンテーブルを生成し、生成したファ
イルオープンテーブルに基づいてファイルアクセス装置
であるリーダライタからの各コマンドの実行可否を決定
し、決定に従って処理を実行する。

【０７０１】次に、２つのファイルに対する処理を実行
する場合のアクセス処理について、図８４を用いて説明
する。図の左側に２つのファイルアクセス装置（Ｒ／
Ｗ：リーダライタ）７７０、７８０を示し、右側にファ
イルの生成されたデバイス１００のパーティション部分
を示す。

【０７０２】まず、ターゲットファイルを指定したサー
ビス許可チケット（ＳＰＴ）（図３１参照）を使用した
処理の実行例を説明する。

【０７０３】ファイルアクセス装置（Ｒ／Ｗ：リーダラ
イタ）７７０は、デバイスとの相互認証の後、 ＳＰＴフォーマット１ ファイルＩＤ：［０ｘ０００１］ ファイルアクセスモード：［暗号化復号化処理：Ｅｎｃ
＆Ｄｅｃ］ および、ＳＰＴフォーマット２ ファイルＩＤ：［０ｘ０００２］ ターゲットファイル・グループ：［ＰＭＣ１］ ターゲットファイルＩＤ：［０ｘ０００１］ 読書き許可：［読み取り：Ｒｅａｄ］ の２つのアクセス許可チケットをデバイス１００に送信
し、チケットの正当性検証、チケット発行者、利用者検
証に成功したとする。

【０７０４】このとき、デバイスには図８２に示すファ
イルオープンテーブルのエントリが生成される。このエ
ントリは、パーティションマネージャコード（ＰＭＣ
１）で識別されるパーティション内のファイルＩＤ［０
ｘ０００１］は、鍵のファイルであり、暗号化、復号化
が可能になるようにオープンされる。ファイルＩＤ［０
ｘ０００２］は、データのファイルであり、外部からの
読み出しはファイルアクセスモード（File Access Mod
e）の欄が空白のため不可能であり、ファイルＩＤ［０
ｘ０００１］に対して［読み取り：Ｒｅａｄ］を実行可
能とする目的のためにオープンされて、ファイルオープ
ンテーブルのエントリとして設定されていることを示し
ている。

【０７０５】このとき、ファイルアクセス装置（Ｒ／
Ｗ：リーダライタ）７７０は、コマンドを生成してデバ
イスに対して送信する。例えばファイルＩＤ［０ｘ００
０２］の読み取り、ファイルＩＤ［０ｘ０００１］によ
る内部暗号化コマンド：Ｉｎｔｅｒｎａｌ Ｅｎｃｒｙ
ｐｔｉｏｎ Ｃｏｍｍａｎｄ（０ｘ０００１，０ｘ００
０２）を送信し、デバイスがコマンドを受信すると、デ
バイスはファイルオープンテーブルのエントリを確認
し、ファイルＩＤ［０ｘ０００２］に対して、ターゲッ
トファイルグループ［ＰＭＣ１］、ターゲットファイル
［０ｘ０００１］の［暗号化処理］に対して［読み取
り：Ｒｅａｄ］を実行可能であることを判定し、ファイ
ルＩＤ［０ｘ００００２］のデータを読み取り、ファイ
ルＩＤ［０ｘ００００１］の鍵（ｋｅｙ）による暗号化
を実行して暗号化データをアクセス装置に送信する。

【０７０６】このターゲットファイルを指定したサービ
ス許可チケット（ＳＰＴ）（図３１参照）を使用した処
理によればあるファイルから読み出したデータを他のフ
ァイルに格納された暗号化鍵を用いて暗号化したデータ
を取得する処理が可能となり、復号データが外部に漏れ
るおそれがない。

【０７０７】次に、ターゲットファイルを指定したサー
ビス許可チケット（ＳＰＴ）（図３１参照）ではなく、
唯一のファイルに対する処理を指定したサービス許可チ
ケット（ＳＰＴ）（図２８参照）を複数用いた場合の処
理について説明する。

【０７０８】ファイルアクセス装置（Ｒ／Ｗ：リーダラ
イタ）７８０は、デバイスとの相互認証の後、ＳＰＴフ
ォーマット１として、 ファイルＩＤ：［０ｘ０００２］ ファイルアクセスモード：［読み取り：Ｒｅａｄ］ またＳＰＴフォーマット２として、 ファイルＩＤ：［０ｘ０００１］ ファイルアクセスモード：［暗号化復号化処理：Ｅｎｃ
＆Ｄｅｃ］ の２つのアクセスチケットをデバイス１００に送信し、
チケットの正当性検証、チケット発行者、利用者検証に
成功したとする。

【０７０９】このとき、デバイスには図８１に示すファ
イルオープンテーブルの第１行および第２行の各エント
リが生成される。このエントリは、パーティションマネ
ージャコード（ＰＭＣ１）で識別されるパーティション
内のファイルＩＤ［０ｘ０００１］に対してアクセスモ
ード［暗号化復号化処理：Ｅｎｃ＆Ｄｅｃ］の処理が実
行可能であり、パーティションマネージャコード（ＰＭ
Ｃ１）で識別されるパーティション内のファイルＩＤ：
０ｘ０００２に対してアクセスモード［読み取り：Ｒｅ
ａｄ］の処理が実行可能であることを示している。

【０７１０】このとき、ファイルアクセス装置（Ｒ／
Ｗ：リーダライタ）７８０は、コマンドを生成してデバ
イスに対して送信する。まず、ファイルＩＤ：［０ｘ０
００２］のデータ読み取りコマンド：Ｒｅａｄ Ｃｏｍ
ｍａｎｄ（０ｘ０００２）をデバイスが受信すると、デ
バイスはファイルオープンテーブルのエントリを確認
し、ファイルＩＤ：０ｘ０００２に対してアクセスモー
ド［読み取り：Ｒｅａｄ］の処理が実行可能であること
を確認し、読み取り処理を実行し、ファイルアクセス装
置に読み取りデータを送信する。

【０７１１】次に、ファイルアクセス装置（Ｒ／Ｗ：リ
ーダライタ）７８０は、さらにコマンドを生成してデバ
イスに対して送信する。ファイルＩＤ［０ｘ０００１］
によるデータ（Ｄａｔａ）の暗号化コマンド［Ｅｎｃｒ
ｙｐｔｉｏｎ Ｃｏｍｍａｎｄ（０ｘ０００１，Ｄａｔ
ａ）］をデバイスが受信すると、デバイスはファイルオ
ープンテーブルのエントリを確認し、ファイルＩＤ［０
ｘ０００１］に対してアクセスモード［暗号化復号化処
理：Ｅｎｃ＆Ｄｅｃ］の処理が実行可能であることを確
認し、暗号化処理を実行し暗号化データ［Ｅｎｃｒｙｐ
ｔｉｏｎ Ｄａｔａ］をファイルアクセス装置（Ｒ／
Ｗ：リーダライタ）７８０に送信する。

【０７１２】このように、ターゲットファイルを指定し
たサービス許可チケット（ＳＰＴ）（図３１参照）では
なく、唯一のファイルに対する処理を指定したサービス
許可チケット（ＳＰＴ）（図２８参照）を複数用いた場
合は、暗号化対象データの読み出し処理が実行され、フ
ァイルアクセス装置７８０とデバイス間におけるデータ
転送処理の回数が増加することになる。また、データが
暗号化されずにデバイスの外に読み出されてしまう。

【０７１３】一方、サービス許可チケット（ＳＰＴ）
（図３１参照）に、アクセス対象とした複数のデータフ
ァイルを識別する複数のファイル識別子を含ませ、該複
数のファイル識別子中、一方はターゲットファイル識別
子として設定するとともにターゲットファイルに対する
読み取りまたは書き込み許可データを格納し、他方のデ
ータファイルのアクセスモードとして該データファイル
に格納した暗号鍵を用いた暗号化処理を設定した構成と
すれば、メモリ搭載デバイスは、アクセス機器からサー
ビス許可チケット（ＳＰＴ）を受領して、指定アクセス
モードに従った処理として、ターゲットファイルの読み
取りおよび暗号鍵による暗号化処理を実行することにな
り、メモリ搭載デバイス内における内部暗号化処理を実
行することが可能となる。また、データが暗号化されず
にデバイスの外に流出することを防止することができ
る。

【０７１４】サービス許可チケット（ＳＰＴ）を発行す
るチケット発行手段は、メモリ搭載デバイスのメモリ領
域を管理するエンティテイであるパーティションマネー
ジャの管理下にあるチケット発行手段であり、各アクセ
ス機器に応じて各種のアクセスモードを設定したサービ
ス許可チケット（ＳＰＴ）を個別に発行することによ
り、各アクセス機器に応じて異なる態様のアクセスを実
行可能とした構成が実現される。

【０７１５】（セッション鍵の使用態様）なお、ファイ
ルアクセス装置とデバイス間において送受信されるデー
タは、デバイスのユーザ情報、あるいは金額情報など外
部に対する漏洩を防止すべきデータであることが多い。
従ってファイルアクセス装置とデバイス間において送受
信されるデータは、暗号化処理を実行し、また改竄チェ
ック値としてのＭＡＣ（Message Authentication Cod
e）を付加したデータとするのが望ましい。

【０７１６】データの暗号化には、ファイルアクセス装
置とデバイス間において実行される相互認証処理におい
て生成されるセッション鍵を用いることが可能である。
前述したように相互認証には、デバイスに対するデバイ
ス認証、各パーティションに対する認証としてのパーテ
ィション認証がある。パーティションに生成済みのファ
イルに対するアクセスを実行する場合、データ転送の際
に適用する暗号化鍵としていずれを適用するかはいくつ
かの選択肢がある。

【０７１７】例えば図８５に示すように、デバイス１０
０とアクセス装置８００との間において、デバイス認証
によって生成されたセッション鍵Ｋｓｅｓ１、パーティ
ションマネージャコード（ＰＭＣ１）に対応するパーテ
ィションとのパーティション認証によって生成されたセ
ッション鍵Ｋｓｅｓ２、パーティションマネージャコー
ド（ＰＭＣ２）に対応するパーティションとのパーティ
ション認証によって生成されたセッション鍵Ｋｓｅｓ３
がある場合がある。

【０７１８】これらは、相互認証の際に生成される認証
テーブル（図５１、図５２参照）にセッションクリアま
で格納される。

【０７１９】デバイスとデバイスとの通信を実行するデ
バイスアクセス機器としてのリーダライタ（ＰＣ他の通
信装置）は、これら複数のセッション鍵のいずれを適用
して暗号化通信を実行するかを、ルールとして予め取り
決めておき、決定されたルールに従ってセッション鍵を
適用する構成が可能である。

【０７２０】複数の異なるパーティション内のファイル
アクセスを、複数の異なるパーティション各々に対応し
て設定された認証条件であるパーティション認証または
デバイス認証のすべての認証成立を条件として許容する
場合、複数の認証処理の結果、取得された複数のセッシ
ョン鍵に基づいて唯一の統合セッション鍵を生成し、該
統合セッション鍵に基づいてアクセス機器との通信デー
タの暗号処理を実行する。

【０７２１】統合セッション鍵生成手法としての１つの
方法は、デバイスとデバイスとの通信を実行するデバイ
スアクセス機器としてのリーダライタ（ＰＣ他の通信装
置）間における相互認証処理によって複数のセッション
鍵Ｋｓｅｓ１〜ＫｓｅｓＮが生成された場合、これら複
数のセッション鍵Ｋｓｅｓ１〜ＫｓｅｓＮの排他論理和
処理（ｅｘ．８バイト処理）を実行し演算結果を通信デ
ータの暗号化用セッション鍵とする方法である。すなわ
ち、 Kses＝Kses1 XOR Kses2 XOR Kses3… ＸＯＲ：排他論理和処理（ｅｘ．８バイト処理） によって算出されたＫｓｅｓをセッション鍵として用い
る。

【０７２２】デバイスとデバイスとの通信を実行するデ
バイスアクセス機器としてのリーダライタ（ＰＣ他の通
信装置）間では、双方の認証テーブルに格納されたセッ
ション鍵を排他論理和演算しその出力値をセッション鍵
として使用するというルールを定め、該ルールに基づい
てセッション鍵を算出して通信データの暗号化に用いる
構成とする。また、同様にして、相互認証時に同時に共
有した別のセッション鍵、例えば公開鍵認証時において
生成したセッション鍵、あるいはセッション鍵生成デー
タ、例えばＹ座標の下位６４ビットを用いてセッション
中の通信データにＭＡＣ値を付加することができる。こ
のＭＡＣ値を通信データ（暗号化データである場合もあ
る）とともに送信し、受信側でＭＡＣ検証処理を行なう
ことで、通信路上のデータ改竄を防止することが可能と
なる。ＭＡＣ生成、検証処理については先に説明した図
５９を参照されたい。

【０７２３】あるいは、デバイスとデバイスとの通信を
実行するデバイスアクセス機器としてのリーダライタ
（ＰＣ他の通信装置）間における相互認証処理によって
取得された複数のセッション鍵Ｋｓｅｓ１〜ＫｓｅｓＮ
の中で、いずれかの１つの鍵（ｅｘ．最新のセッション
鍵）を選択してその後の通信処理におけるデータ暗号化
鍵として適用するというルールを設定し、該ルールに従
って、セッション鍵を選択して通信データの暗号化に用
いる構成としてもよい。

【０７２４】なお、上述した複数のセッション鍵の演算
による算出、あるいは選択処理は、ファイルアクセス装
置とデバイス間の暗号化通信のみならず、すべてのチケ
ット（ＰＲＴ，ＦＲＴ，ＳＰＴ，ＤＵＴ）ユーザ（デバ
イスアクセス機器としてのリーダライタなどのデバイス
とのデータ通信を実行する機器）とデバイス間の暗号化
通信処理において、相互認証により複数のセッション鍵
が生成された場合に適用できる。各チケットユーザとデ
バイス相互において、どのようなルールに従って、適用
するセッション鍵を複数のセッション鍵から算出するか
または選択するかについては予めルールとして取り決
め、相互にルールを確認した後実行するか、あるいは各
チケットにルールを記録しておくなどの措置が採用可能
である。

【０７２５】次に、図８６、図８７を用いてファイルア
クセス装置によるデバイスに対するアクセス処理（図７
９の処理フローにおけるステップＳ８５７，８６９）手
順の代表的例について説明する。

【０７２６】図８６を用いて１つのファイルのみに対し
てアクセスを実行する場合の処理（Ｎｏｒｍａｌ）につ
いて説明し、図８７を用いて複数ファイルに対してアク
セスを行なう場合の処理（Ｃｏｍｂｉｎａｔｉｏｎ）に
ついて説明する。

【０７２７】まず、図８６の１つのファイルのみに対し
てアクセスを実行する場合の処理（Ｎｏｒｍａｌ）につ
いて説明する。図８６のフローにおいて、左側がファイ
ルアクセス装置、右側がデバイス（図５参照）の処理を
示す。なお、ファイルアクセス処理において、ファイル
アクセス装置とデバイス間におけるデータ転送の際に
は、相互認証処理において取得したセッション鍵Ｋｓｅ
ｓ、あるいは複数のセッション鍵から演算マタは選択さ
れたセッション鍵を用いて暗号化され、また改竄チェッ
ク用のＭＡＣの生成、検証処理が実行される。

【０７２８】ファイルアクセス装置は、ステップＳ８９
１において、アクセスコマンドをデバイスに送信する。
このコマンドは、アクセス対象のファイルＩＤ、アクセ
スモードを指定したコマンドであり、例えば先に図８３
を用いて説明したようなファイルＩＤ［０ｘ０００２］
のデータ読み取りコマンド：Ｒｅａｄ Ｃｏｍｍａｎｄ
（０ｘ０００２）、あるいは、ファイルＩＤ［０ｘ００
０１］の暗号化コマンド［Ｅｎｃｒｙｐｔｉｏｎ Ｃｏ
ｍｍａｎｄ（０ｘ０００１）］などである。

【０７２９】デバイスは、ファイルアクセス装置からの
コマンドを受信（Ｓ９０１）すると、コマンドに含まれ
るファイルＩＤ、アクセスモードがファイルオープンテ
ーブルに許可されたエントリとして記録されているか否
かを判定（Ｓ９０２）する。ファイルオープンテーブル
にコマンドに対応するファイルＩＤ、アクセスモードの
エントリが存在しない場合は、コマンドに従った処理を
実行せず、アクセスエラーをファイルアクセス装置に送
信（Ｓ９０８）する。

【０７３０】ファイルオープンテーブルにコマンドに対
応するファイルＩＤ、アクセスモードのエントリが存在
した場合は、ステップＳ９０３において、デバイスのメ
モリ内の対応パーティションのファイル定義ブロック
（ＦＤＢ）（図２４参照）に記録されたファイルアクセ
ス認証方式（Acceptable Authentication Type :特定の
ファイル（File）アクセスを行う際に、指定する認証方
式）を参照し、アクセス対象のファイルに対するアクセ
スコマンドの実行に必要な認証レベル（公開鍵認証を必
要とするか）を確認する。

【０７３１】ステップＳ９０３において、ファイル定義
ブロック（ＦＤＢ）のファイルアクセス認証方式（Acce
ptable Authentication Type）が公開鍵認証を必要とす
る設定である場合は、ステップＳ９０４において、アク
セスコマンドに必要な認証レベルの認証としての公開鍵
認証が済んでいるか否かを判定し、認証未了の場合は、
コマンドに従った処理を実行せず、アクセスエラーをフ
ァイルアクセス装置に送信（Ｓ９０８）する。認証の終
了または未了は、相互認証時に設定される認証テーブル
（図５１参照）に基づいて判定される。

【０７３２】ステップＳ９０３において、ファイル定義
ブロック（ＦＤＢ）のファイルアクセス認証方式（Acce
ptable Authentication Type）が公開鍵認証を必要とす
る設定であり、ステップＳ９０４において、公開鍵認証
が済んでいると判定された場合、あるいは、ファイル定
義ブロック（ＦＤＢ）のファイルアクセス認証方式（Ac
ceptable Authentication Type）が公開鍵認証を必要と
しない設定である場合は、次に、ステップＳ９０５にお
いて、デバイスのメモリ内の対応パーティションのファ
イル定義ブロック（ＦＤＢ）（図２４参照）に記録され
たファイルアクセス検証方式（Acceptable Verificatio
n Type :特定のファイル（File）アクセスを行う際に、
指定する検証方式）を参照し、アクセス対象のファイル
に対するアクセスコマンドの実行に必要な検証レベル
（公開鍵方式の検証を必要とするか）を確認する。

【０７３３】ステップＳ９０５において、ファイル定義
ブロック（ＦＤＢ）のファイルアクセス検証方式（Acce
ptable Verification Type）が公開鍵方式のチケット検
証を必要とする設定である場合は、ステップＳ９０６に
おいて、アクセスコマンドに必要な検証レベルの検証と
しての公開鍵方式のチケット検証が済んでいるか否かを
判定し、検証未了の場合は、コマンドに従った処理を実
行せず、アクセスエラーをファイルアクセス装置に送信
（Ｓ９０８）する。

【０７３４】ステップＳ９０５において、ファイル定義
ブロック（ＦＤＢ）のファイルアクセス検証方式（Acce
ptable Verification Type）が公開鍵方式のチケット検
証を必要とする設定であり、ステップＳ９０６におい
て、公開鍵方式のチケット検証が済んでいると判定され
た場合、あるいは、ファイル定義ブロック（ＦＤＢ）の
ファイルアクセス検証方式（Acceptable Verification
Type）が公開鍵方式のチケット検証を必要としない設定
である場合は、ステップＳ９０７において、ファイルア
クセス装置から受信したアクセスコマンドの処理を実行
し、結果をファイルアクセス装置に送信する。

【０７３５】アクセスコマンド結果を受信（Ｓ８９２）
したファイルアクセス装置は、さらに他のファイルアク
セスを実行するか否かを判定（Ｓ８９３）し、他のファ
イルアクセスを実行する場合は、ステップＳ８９１以下
を繰り返し実行し、他にファイルアクセスを実行しない
場合は処理を終了する。

【０７３６】次に、図８７を用いて複数ファイルに対し
てアクセスを行なう場合の処理（Ｃｏｍｂｉｎａｔｉｏ
ｎ）について説明する。図８７のフローにおいて、左側
がファイルアクセス装置、右側がデバイス（図５参照）
の処理を示す。なお、ファイルアクセス処理において、
ファイルアクセス装置とデバイス間におけるデータ転送
の際には、相互認証処理において取得したセッション鍵
Ｋｓｅｓ、あるいは複数のセッション鍵から演算または
選択されたセッション鍵を用いて暗号化され、また改竄
チェック用のＭＡＣの生成、検証処理が実行される。

【０７３７】ファイルアクセス装置は、ステップＳ９１
１において、アクセスコマンドをデバイスに送信する。
このコマンドは、アクセス対象のファイルＩＤ（ソー
ス）、ターゲットファイルＩＤ、アクセスモードを指定
したコマンドであり、例えば先に図８４を用いて説明し
たような、ソースファイルＩＤ［０ｘ０００２］に対し
て、ターゲットファイルＩＤ［０ｘ０００１］の鍵によ
る内部暗号化処理の実行を指定するコマンド［Ｉｎｔｅ
ｒｎａｌ Ｅｎｃｒｙｐｔｉｏｎ Ｃｏｍｍａｎｄ（０ｘ
０００１，０ｘ０００２）］などである。

【０７３８】デバイスは、ファイルアクセス装置からの
コマンドを受信（Ｓ９２１）すると、ファイルオープン
テーブルのターゲットファイルＩＤのエントリにアクセ
スコマンドの許可があるか否かを判定（Ｓ９２２）す
る。ファイルオープンテーブルのターゲットファイルＩ
Ｄのエントリにアクセスコマンドの許可が存在しない場
合は、コマンドに従った処理を実行せず、アクセスエラ
ーをファイルアクセス装置に送信（Ｓ９３４）する。

【０７３９】ファイルオープンテーブルのターゲットフ
ァイルＩＤのエントリにアクセスコマンドの許可が存在
した場合は、ステップＳ９２３において、デバイスのメ
モリ内の対応パーティションのファイル定義ブロック
（ＦＤＢ）（図２４参照）に記録されたファイルアクセ
ス認証方式（Acceptable Authentication Type :特定の
ファイル（File）アクセスを行う際に、指定する認証方
式）を参照し、アクセス対象のターゲットファイルに対
するアクセスコマンドの実行に必要な認証レベル（公開
鍵認証を必要とするか）を確認する。

【０７４０】ステップＳ９２３において、アクセス対象
のターゲットファイルに対して設定されたファイル定義
ブロック（ＦＤＢ）のファイルアクセス認証方式（Acce
ptable Authentication Type）が公開鍵認証を必要とす
る設定である場合は、ステップＳ９２４において、アク
セスコマンドに必要な認証レベルの認証としての公開鍵
認証が済んでいるか否かを判定し、認証未了の場合は、
コマンドに従った処理を実行せず、アクセスエラーをフ
ァイルアクセス装置に送信（Ｓ９３４）する。認証の終
了または未了は、相互認証時に設定される認証テーブル
（図５１参照）に基づいて判定される。

【０７４１】ステップＳ９２３において、アクセス対象
のターゲットファイルに対して設定されたファイル定義
ブロック（ＦＤＢ）のファイルアクセス認証方式（Acce
ptable Authentication Type）が公開鍵認証を必要とす
る設定であり、ステップＳ９２４において、公開鍵認証
が済んでいると判定された場合、あるいは、ファイル定
義ブロック（ＦＤＢ）のファイルアクセス認証方式（Ac
ceptable Authentication Type）が公開鍵認証を必要と
しない設定である場合は、次に、ステップＳ９２５にお
いて、デバイスのメモリ内の対応パーティションのファ
イル定義ブロック（ＦＤＢ）（図２４参照）に記録され
たファイルアクセス検証方式（Acceptable Verificatio
n Type :特定のファイル（File）アクセスを行う際に、
指定する検証方式）を参照し、アクセス対象のターゲッ
トファイルに対するアクセスコマンドの実行に必要な検
証レベル（公開鍵方式の検証を必要とするか）を確認す
る。

【０７４２】ステップＳ９２５において、アクセス対象
のターゲットファイルに対して設定されたファイル定義
ブロック（ＦＤＢ）のファイルアクセス検証方式（Acce
ptable Verification Type）が公開鍵方式のチケット検
証を必要とする設定である場合は、ステップＳ９２６に
おいて、アクセスコマンドに必要な検証レベルの検証と
しての公開鍵方式のチケット検証が済んでいるか否かを
判定し、検証未了の場合は、コマンドに従った処理を実
行せず、アクセスエラーをファイルアクセス装置に送信
（Ｓ９３４）する。

【０７４３】ステップＳ９２５において、アクセス対象
のターゲットファイルに対して設定されたファイル定義
ブロック（ＦＤＢ）のファイルアクセス検証方式（Acce
ptable Verification Type）が公開鍵方式のチケット検
証を必要とする設定であり、ステップＳ９２６におい
て、公開鍵方式のチケット検証が済んでいると判定され
た場合、あるいは、ファイル定義ブロック（ＦＤＢ）の
ファイルアクセス検証方式（Acceptable Verification
Type）が公開鍵方式のチケット検証を必要としない設定
である場合は、次に、ステップＳ９２７において、アク
セスコマンドに含まれるターゲットファイルＩＤによっ
て指定されるファイルのアクセス方法（Read/Write）を
コマンドに基づいて確認する。

【０７４４】デバイスは、ファイルアクセス装置からの
コマンドに含まれるソースファイルＩＤによって指定さ
れるファイルがアクセスコマンドに含まれるアクセス方
法（Read/Write）に対してオープンしているか否かを判
定（Ｓ９２８）する。ファイルオープンテーブルにコマ
ンド実行のためのアクセス方法（Read/Write）が存在し
ない場合は、コマンドに従った処理を実行せず、アクセ
スエラーをファイルアクセス装置に送信（Ｓ９３４）す
る。

【０７４５】ファイルオープンテーブルにコマンドに対
応するアクセス方法（Read/Write）が存在した場合は、
ステップＳ９２９において、デバイスのメモリ内の対応
パーティションのファイル定義ブロック（ＦＤＢ）（図
２４参照）に記録されたファイルアクセス認証方式（Ac
ceptable Authentication Type :特定のファイル（Fil
e）アクセスを行う際に、指定する認証方式）を参照
し、アクセス対象のソースファイルに対するアクセスコ
マンドの実行に必要な認証レベル（公開鍵認証を必要と
するか）を確認する。

【０７４６】ステップＳ９２９において、アクセス対象
のソースファイルに対して設定されたファイル定義ブロ
ック（ＦＤＢ）のファイルアクセス認証方式（Acceptab
le Authentication Type）が公開鍵認証を必要とする設
定である場合は、ステップＳ９３０において、アクセス
コマンドに必要な認証レベルの認証としての公開鍵認証
が済んでいるか否かを判定し、認証未了の場合は、コマ
ンドに従った処理を実行せず、アクセスエラーをファイ
ルアクセス装置に送信（Ｓ９３４）する。認証の終了ま
たは未了は、相互認証時に設定される認証テーブル（図
５１参照）に基づいて判定される。

【０７４７】ステップＳ９２９において、アクセス対象
のソースファイルに対して設定されたファイル定義ブロ
ック（ＦＤＢ）のファイルアクセス認証方式（Acceptab
le Authentication Type）が公開鍵認証を必要とする設
定であり、ステップＳ９３０において、公開鍵認証が済
んでいると判定された場合、あるいは、ファイル定義ブ
ロック（ＦＤＢ）のファイルアクセス認証方式（Accept
able AuthenticationType）が公開鍵認証を必要としな
い設定である場合は、次に、ステップＳ９３１におい
て、デバイスのメモリ内の対応パーティションのファイ
ル定義ブロック（ＦＤＢ）（図２４参照）に記録された
ファイルアクセス検証方式（Acceptable Verification
Type :特定のファイル（File）アクセスを行う際に、指
定する検証方式）を参照し、アクセス対象のソースファ
イルに対するアクセスコマンドの実行に必要な検証レベ
ル（公開鍵方式の検証を必要とするか）を確認する。

【０７４８】ステップＳ９３１において、アクセス対象
のソースファイルに対して設定されたファイル定義ブロ
ック（ＦＤＢ）のファイルアクセス検証方式（Acceptab
le Verification Type）が公開鍵方式のチケット検証を
必要とする設定である場合は、ステップＳ９３２におい
て、アクセスコマンドに必要な検証レベルの検証として
の公開鍵方式のチケット検証が済んでいるか否かを判定
し、検証未了の場合は、コマンドに従った処理を実行せ
ず、アクセスエラーをファイルアクセス装置に送信（Ｓ
９３４）する。

【０７４９】ステップＳ９３１において、アクセス対象
のソースファイルに対して設定されたファイル定義ブロ
ック（ＦＤＢ）のファイルアクセス検証方式（Acceptab
le Verification Type）が公開鍵方式のチケット検証を
必要とする設定であり、ステップＳ９３２において、公
開鍵方式のチケット検証が済んでいると判定された場
合、あるいは、ファイル定義ブロック（ＦＤＢ）のファ
イルアクセス検証方式（Acceptable Verification Typ
e）が公開鍵方式のチケット検証を必要としない設定で
ある場合は、ステップＳ９３３において、ファイルアク
セス装置から受信したアクセスコマンドの処理を実行
し、結果をファイルアクセス装置に送信する。

【０７５０】アクセスコマンド結果を受信（Ｓ９１２）
したファイルアクセス装置は、さらに他のファイルアク
セスを実行するか否かを判定（Ｓ９１３）し、他のファ
イルアクセスを実行する場合は、ステップＳ９１１以下
を繰り返し実行し、他にファイルアクセスを実行しない
場合は処理を終了する。

【０７５１】上述したファイルアクセス処理は、ファイ
ル内にある１つのファイル構造によって指定されるデー
タが格納された場合の処理を想定して説明しているが、
異なるファイル構造データを１つのファイル内に格納
し、１つのファイルに対する１つのコマンドにより、上
述の複数ファイルに対するシーケンシャル処理と同様の
処理を実行する構成も可能である。

【０７５２】図８８に１つのファイルに対する１つのコ
マンドにより、１ファイル内のデータに対してシーケン
シャル処理を実行する構成を説明する図を示す。

【０７５３】ファイルは図に示すように、電子マネーフ
ァイルであり、金額データとしての［Ｐｕｒｓｅ］、利
用ログデータとしての「Ｌｏｇ」、データに対する暗号
化または復号用の鍵データとしての［Ｋｅｙ］から構成
される。

【０７５４】例えば、図８８（ａ）に示すように、預け
入れコマンド（Deposit Command）を規定し、ファイル
内の金額データとしての［Ｐｕｒｓｅ］にＸ円を加算
（Ｓ９４１）し、さらに、ファイル内の利用ログデータ
としての「Ｌｏｇ」に［Ｐｕｒｓｅ］にＸ円を加算した
記録を書き込む（Ｓ９４２）という２つの処理を実行さ
せる構成とすることが可能である。

【０７５５】先に説明したファイルアクセスモード（図
２９参照）の入金系に対応する許容コマンド（図３０参
照）として、上述の預け入れコマンド（Deposit Comman
d）を定義し、アクセス許可チケットのファイルアクセ
スモード（File Access Mode）に［入金系］を設定し、
ファイルＩＤ(File ID)として、電子マネーを構成する
複合ファイルを指定したアクセス許可チケット（ＳＰ
Ｔ）を生成して、ファイルアクセス装置からデバイスに
対して送信した後、預け入れコマンド（DepositComman
d）とともに、預け入れ金額データを送信することによ
り、図８８（ａ）に示すようなデバイスにおいて１つの
ファイル内のデータに対するシーケンシャル処理を実行
させることが可能となる。

【０７５６】また、図８８（ｂ）に示すように、レシー
ト生成コマンド（Make Receipt Command）を規定し、フ
ァイル内の金額データとしての［Ｐｕｒｓｅ］からＸ円
を減算（Ｓ９４５）し、さらに、ファイル内の利用ログ
データとしての「Ｌｏｇ」に［Ｐｕｒｓｅ］からＸ円を
減算した記録を書き込み（Ｓ９４６）、さらに「Ｌｏ
ｇ」にデータに対する暗号化鍵データとしての［Ｋｅ
ｙ］を適用して署名をつけて送信する（Ｓ９４７）とい
う３ステップの処理を実行させる構成とすることも可能
である。

【０７５７】この場合はファイルアクセスモード（図２
９参照）の出金系に対応する許容コマンド（図３０参
照）として、上述のレシート生成コマンド（Make Recei
pt Command）を定義し、アクセス許可チケットのファイ
ルアクセスモード（File Access Mode）に［出金系］を
設定し、ファイルＩＤ(File ID)として、電子マネーを
構成する複合ファイルを指定したアクセス許可チケット
（ＳＰＴ）を生成して、ファイルアクセス装置からデバ
イスに対して送信した後、レシート生成コマンド（Make
Receipt Command）とともに、引き出し金額データを送
信することにより、図８８（ｂ）に示すようなデバイス
において１つのファイル内のデータに対するシーケンシ
ャル処理を実行させることが可能となる。

【０７５８】このようにデバイスは、サービス許可チケ
ット（ＳＰＴ）に指定された処理ファイルが複合ファイ
ルである場合、アクセス機器からの受領コマンドの処理
対象ファイルを複合ファイル内から選択して処理を実行
する。アクセス機器からのデータ処理コマンドが一連の
複数の処理を含むシーケンス処理コマンドである場合
は、デバイスは、シーケンス処理コマンドに含まれる各
コマンドの処理対象ファイルを、サービス許可チケット
（ＳＰＴ）によって指定された複合ファイル内から順次
選択して実行する。

【０７５９】［Ｂ４．７．サービス許可チケット（ＳＰ
Ｔ）を利用したアクセス処理各方式における処理手順］
上述したサービス許可チケット（ＳＰＴ）を利用したア
クセス処理ファイルの設定登録処理において、パーティ
ションマネージャが管理し、サービス許可チケット（Ｓ
ＰＴ）ユーザであるデバイスアクセス機器としてのリー
ダライタとデバイス間において、相互認証が実行され、
サービス許可チケット（ＳＰＴ）に基づくファイルアク
セスがなされる。相互認証処理の態様は、公開鍵相互認
証、共通鍵相互認証の２種類のいずれかであり、またチ
ケット（ＳＰＴ）の検証処理も公開鍵系の署名検証、共
通鍵系のＭＡＣ検証の２種類のいずれかが実行されるこ
とになる。すなわち処理態様としては大きく分けて、 （Ａ）相互認証（公開鍵）、チケット（ＳＰＴ）検証
（公開鍵） （Ｂ）相互認証（公開鍵）、チケット（ＳＰＴ）検証
（共通鍵） （Ｃ）相互認証（共通鍵）、チケット（ＳＰＴ）検証
（共通鍵） （Ｄ）相互認証（共通鍵）、チケット（ＳＰＴ）検証
（公開鍵） の４態様がある。

【０７６０】これらの４態様についての処理を、認証局
（ＣＡ（ＰＭ））、パーティションマネージャ（Ｐ
Ｍ）、ＳＰＴチケットユーザであるデバイスアクセス機
器としてのリーダライタ、デバイス、各エンティテイ間
において実行されるデータ転送処理を中心として図を用
いて簡潔に説明する。

【０７６１】（Ａ）相互認証（公開鍵）、チケット（Ｓ
ＰＴ）検証（公開鍵） まず、相互認証処理に公開鍵方式を適用し、チケット
（ＳＰＴ）検証に公開鍵方式を適用する場合の各エンテ
ィテイ間のデータ転送について図８９を用いて説明す
る。

【０７６２】図に示す番号順に各エンティテイ間でデー
タ転送が実行される。以下、各番号に従って処理を説明
する。 （１）パーティションマネージャ（ＰＭ）の公開鍵証明
書（Ｃｅｒｔ．ＰＭ）の発行、 パーティションマネージャ（ＰＭ）の公開鍵証明書（Ｃ
ｅｒｔ．ＰＭ）は、パーティションマネージャ（ＰＭ）
からの発行要求により、登録局（ＲＡ）を介した証明書
発行手続きによってパーティション対応認証局（ＣＡ
（ＰＡＲ））から発行される。なお、本構成は、パーテ
ィションマネージャがサービス許可チケット発行手段
（ＳＰＴ Issuer）を兼ねる構成であり、サービス許可
チケット発行手段（ＳＰＴ Issuer）の公開鍵証明書と
してパーティションマネージャ（ＰＭ）の公開鍵証明書
を使用する構成である。

【０７６３】（２）サービス許可チケットユーザ（ＳＰ
Ｔ User）であるデバイスアクセス機器としてのリーダ
ライタ（Ｒ／Ｗ）の公開鍵証明書（Ｃｅｒｔ．ＲＷ）の
発行、 サービス許可チケットユーザ（ＳＰＴ User：具体的に
は、デバイスに対してチケットを送信するデバイスアク
セス機器としてのリーダライタ（Ｒ／Ｗ））の公開鍵証
明書（Ｃｅｒｔ．Ｒ／Ｗ）は、サービス許可チケットユ
ーザ（ＳＰＴ User）であるリーダライタ（Ｒ／Ｗ）か
らの発行要求により、登録局（ＲＡ）を介した証明書発
行手続きによってパーティション対応認証局（ＣＡ（Ｐ
ＡＲ））によって発行される。なお、パーティションマ
ネージャがサービス許可チケットユーザ（ＳＰＴ Use
r）を兼ねる構成も可能であり、その場合は、サービス
許可チケットユーザ（ＳＰＴ User）の公開鍵証明書と
してパーティションマネージャ（ＰＭ）の公開鍵証明書
を使用可能である。

【０７６４】（３）サービス許可チケット（ＳＰＴ）の
生成処理 サービス許可チケット（ＳＰＴ）は、パーティションマ
ネージャの管理するサービス許可チケット発行手段（Ｓ
ＰＴ Ticket Issuer）により生成される。この場合、公
開鍵方式の署名生成、検証を実行するため、サービス許
可チケット発行手段（ＳＰＴ Ticket Issuer）の秘密鍵
による署名(Signature)が生成（図１２参照）されてＳ
ＰＴに付加される。

【０７６５】（４）ＳＰＴおよびサービス許可チケット
発行手段（ＳＰＴ Ticket Issuer）としてのパーティシ
ョンマネージャ公開鍵証明書（Ｃｅｒｔ．ＰＭ）のサー
ビス許可チケットユーザ（ＳＰＴ User）であるデバイ
スアクセス機器としてのリーダライタ（Ｒ／Ｗ）に対す
る供給 パーティションマネージャの管理するサービス許可チケ
ット発行手段（ＳＰＴTicket Issuer）により発行され
たサービス許可チケット（ＳＰＴ）は、サービス許可チ
ケット発行手段（ＳＰＴ Ticket Issuer）としてのパー
ティションマネージャ公開鍵証明書（Ｃｅｒｔ．ＰＭ）
とともにサービス許可チケットユーザ（ＳＰＴ User）
であるデバイスアクセス機器としてのリーダライタ（Ｒ
／Ｗ）に対して送信される。

【０７６６】（５）デバイスアクセス機器としてのリー
ダライタ（Ｒ／Ｗ）とデバイス間の相互認証 サービス許可チケットユーザ（ＳＰＴ User）であるリ
ーダライタは、サービス許可チケット発行手段（ＳＰＴ
Ticket Issuer）の発行したサービス許可チケット（Ｓ
ＰＴ）に従ったファイルアクセスを実行しようとする対
象のデバイスに対し、チケットユーザ（ＳＰＴ User）
としてのリーダライタ（Ｒ／Ｗ）の公開鍵証明書（Ｃｅ
ｒｔ．ＲＷ）をデバイスに送信し、公開鍵方式の相互認
証（図５０参照）を実行する。

【０７６７】（６）ＳＰＴおよびサービス許可チケット
発行手段（ＳＰＴ Ticket Issuer）としてのパーティシ
ョンマネージャ公開鍵証明書（Ｃｅｒｔ．ＰＭ）のデバ
イスに対する供給 デバイスアクセス機器としてのリーダライタ（Ｒ／Ｗ）
とデバイス間の相互認証が成立すると、チケットユーザ
（ＳＰＴ User）としてのリーダライタ（Ｒ／Ｗ）は、
デバイスに対してサービス許可チケット（ＳＰＴ）、お
よびサービス許可チケット発行手段（ＳＰＴ Ticket Is
suer）としてのパーティションマネージャ公開鍵証明書
（Ｃｅｒｔ．ＰＭ）を送信する。

【０７６８】デバイスは、受信したサービス許可チケッ
ト（ＳＰＴ）について、（１）チケット発行者（Ticket
Issuer）としてのパーティションマネージャ公開鍵証
明書（Ｃｅｒｔ．ＰＭ）が改竄されたものでない正当な
公開鍵証明書（ＣＥＲＴ）であること、（２）チケット
発行者（Ticket Issuer）の公開鍵証明書（ＣＥＲＴＰ
Ｍ）のオプション領域に記録されたコードと、デバイス
内のＦＤＢ（File Definition Block）に記録された（S
PTIC）の一致、（３）チケット発行手段（Ticket Issue
r）がリボークされていないこと、（４）受信チケット
（ＳＰＴ）の署名（Signature）の検証によりチケット
が改竄のないことの確認を実行し、さらに、ＳＰＴチケ
ットに格納されたＳＰＴユーザ（チケットユーザとして
のリーダライタ）とチケットユーザ（ＳＰＴ User）の
公開鍵証明書（Ｃｅｒｔ．ＲＷ）の識別データ（ＤＮ）
として記録された識別子またはカテゴリまたはシリアル
（ＳＮ）名（ＤＮ）の一致を確認し、相互認証済みであ
ることを確認することによりＳＰＴユーザ（デバイスア
クセス機器としてのリーダライタ）の検証（図５７、図
５８参照）を実行する。

【０７６９】（７）ファイルアクセス デバイスは、処理対象ファイルにサービス許可チケット
（ＳＰＴ）に記述されたルールに従ってアクセスを実行
する。

【０７７０】以上の処理によって、相互認証（公開
鍵）、チケット（ＳＰＴ）検証（公開鍵）の各方式に従
ったファイルアクセス処理が実行される。

【０７７１】（Ｂ）相互認証（公開鍵）、チケット（Ｓ
ＰＴ）検証（共通鍵） 次に、相互認証処理に公開鍵方式を適用し、チケット
（ＳＰＴ）検証に共通鍵方式を適用する場合の各エンテ
ィテイ間のデータ転送について図９０を用いて説明す
る。

【０７７２】図に示す番号順に各エンティテイ間でデー
タ転送が実行される。以下、各番号に従って処理を説明
する。

【０７７３】（１）サービス許可チケットユーザ（ＳＰ
Ｔ User）であるデバイスアクセス機器としてのリーダ
ライタ（Ｒ／Ｗ）の公開鍵証明書（Ｃｅｒｔ．ＲＷ）の
発行、 サービス許可チケットユーザ（ＳＰＴ User：具体的に
は、デバイスに対してチケットを送信するデバイスアク
セス機器としてのリーダライタ（Ｒ／Ｗ））の公開鍵証
明書（Ｃｅｒｔ．Ｒ／Ｗ）は、サービス許可チケットユ
ーザ（ＳＰＴ User）であるリーダライタ（Ｒ／Ｗ）か
らの発行要求により、登録局（ＲＡ）を介した証明書発
行手続きによってパーティション対応認証局（ＣＡ（Ｐ
ＡＲ））によって発行される。なお、パーティションマ
ネージャがサービス許可チケットユーザ（ＳＰＴ Use
r）を兼ねる構成も可能であり、その場合は、サービス
許可チケットユーザ（ＳＰＴ User）の公開鍵証明書と
してパーティションマネージャ（ＰＭ）の公開鍵証明書
を使用可能である。

【０７７４】（２）サービス許可チケット（ＳＰＴ）の
生成処理 サービス許可チケット（ＳＰＴ）は、パーティションマ
ネージャの管理するサービス許可チケット発行手段（Ｓ
ＰＴ Ticket Issuer）により生成される。この場合、共
通鍵方式の検証値としてＭＡＣ(Message Authenticatio
n Code)（図５９参照）がＳＰＴに付加される。

【０７７５】（３）ＳＰＴのサービス許可チケットユー
ザ（ＳＰＴ User）であるデバイスアクセス機器として
のリーダライタ（Ｒ／Ｗ）に対する供給 パーティションマネージャの管理するサービス許可チケ
ット発行手段（ＳＰＴTicket Issuer）により発行され
たサービス許可チケット（ＳＰＴ）は、サービス許可チ
ケットユーザ（ＳＰＴ User）としてのリーダライタ
（Ｒ／Ｗ）に対して送信される。

【０７７６】（４）リーダライタ（Ｒ／Ｗ）とデバイス
間の相互認証 サービス許可チケットユーザ（ＳＰＴ User）であるデ
バイスアクセス機器としてのリーダライタは、サービス
許可チケット発行手段（ＳＰＴ Ticket Issuer）の発行
したサービス許可チケット（ＳＰＴ）に従ったファイル
アクセスを実行しようとする対象のデバイスに対し、チ
ケットユーザ（ＳＰＴ User）としてのリーダライタ
（Ｒ／Ｗ）の公開鍵証明書（Ｃｅｒｔ．ＲＷ）をデバイ
スに送信し、公開鍵方式の相互認証（図５０参照）を実
行する。パーティションマネージャ（ＰＭ）の公開鍵証
明書を使用可能である。

【０７７７】（５）ＳＰＴのデバイスに対する供給 デバイスアクセス機器としてのリーダライタ（Ｒ／Ｗ）
とデバイス間の相互認証が成立すると、サービス許可チ
ケットユーザ（ＳＰＴ User）であるリーダライタは、
デバイスに対してサービス許可チケット（ＳＰＴ）を送
信する。デバイスは、受信したサービス許可チケット
（ＳＰＴ）についてＭＡＣ検証処理を実行し、ＳＰＴ発
行者（SPT Issuer）の検証、さらに、ＳＰＴチケットに
格納されたＳＰＴユーザ（チケットユーザとしてのリー
ダライタ）とチケットユーザ（ＳＰＴ User）の公開鍵
証明書（Ｃｅｒｔ．ＲＷ）の識別データ（ＤＮ）として
記録された識別子またはカテゴリまたはシリアル（Ｓ
Ｎ）名（ＤＮ）の一致を確認し、相互認証済みであるこ
とを確認することによりＳＰＴユーザ（デバイスアクセ
ス機器としてのリーダライタ）の検証（図５７、図５８
参照）を実行する。

【０７７８】（６）ファイルアクセス デバイスは、処理対象ファイルにサービス許可チケット
（ＳＰＴ）に記述されたルールに従ってアクセスを実行
する。

【０７７９】以上の処理によって、相互認証（公開
鍵）、チケット（ＳＰＴ）検証（共通鍵）の各方式に従
ったファイルアクセス処理が実行される。

【０７８０】（Ｃ）相互認証（共通鍵）、チケット（Ｓ
ＰＴ）検証（共通鍵） 次に、相互認証処理に共通鍵方式を適用し、チケット
（ＳＰＴ）検証に共通鍵方式を適用する場合の各エンテ
ィテイ間のデータ転送について図９１を用いて説明す
る。

【０７８１】図に示す番号順に各エンティテイ間でデー
タ転送が実行される。以下、各番号に従って処理を説明
する。

【０７８２】（１）サービス許可チケット（ＳＰＴ）の
生成処理 サービス許可チケット（ＳＰＴ）は、パーティションマ
ネージャの管理するサービス許可チケット発行手段（Ｓ
ＰＴ Ticket Issuer）により生成される。この場合、共
通鍵方式の検証値としてＭＡＣ(Message Authenticatio
n Code)（図５９参照）がＳＰＴに付加される。

【０７８３】（２）ＳＰＴのサービス許可チケットユー
ザ（ＳＰＴ User）に対する供給 パーティションマネージャの管理するサービス許可チケ
ット発行手段（ＳＰＴTicket Issuer）により発行され
たサービス許可チケット（ＳＰＴ）は、サービス許可チ
ケットユーザ（ＳＰＴ User）であるデバイスアクセス
機器としてのリーダライタに対して送信される。

【０７８４】（３）デバイスアクセス機器としてのリー
ダライタ（Ｒ／Ｗ）とデバイス間の相互認証 サービス許可チケットユーザ（ＳＰＴ User）であるデ
バイスアクセス機器としてのリーダライタ（Ｒ／Ｗ）
は、サービス許可チケット発行手段（ＳＰＴ Ticket Is
suer）の発行したサービス許可チケット（ＳＰＴ）に従
ったファイルを生成しようとする対象のデバイスとの間
で、共通鍵方式の相互認証（図５３、図５４参照）を実
行する。

【０７８５】（４）ＳＰＴのデバイスに対する供給 デバイスアクセス機器としてのリーダライタ（Ｒ／Ｗ）
とデバイス間の相互認証が成立すると、サービス許可チ
ケットユーザ（ＳＰＴ User）であるリーダライタは、
デバイスに対してサービス許可チケット（ＳＰＴ）を送
信する。デバイスは、受信したサービス許可チケット
（ＳＰＴ）についてＭＡＣ検証処理を実行し、ＳＰＴ発
行者（SPT Issuer）の検証、さらに、ＳＰＴチケットに
格納されたＳＰＴユーザ（チケットユーザとしてのリー
ダライタ）とチケットユーザ（ＳＰＴ User）の識別子
の一致を確認し、相互認証済みであることを確認するこ
とによりＳＰＴユーザ（デバイスアクセス機器としての
リーダライタ）の検証（図５７、図５８参照）を実行す
る。

【０７８６】（５）ファイルアクセス デバイスは、処理対象ファイルにサービス許可チケット
（ＳＰＴ）に記述されたルールに従ってアクセスを実行
する。

【０７８７】以上の処理によって、相互認証（共通
鍵）、チケット（ＳＰＴ）検証（共通鍵）の各方式に従
ったファイルアクセス処理が実行される。

【０７８８】（Ｄ）相互認証（共通鍵）、チケット（Ｓ
ＰＴ）検証（公開鍵） 次に、相互認証処理に共通鍵方式を適用し、チケット
（ＳＰＴ）検証に公開鍵方式を適用する場合の各エンテ
ィテイ間のデータ転送について図９２を用いて説明す
る。

【０７８９】図に示す番号順に各エンティテイ間でデー
タ転送が実行される。以下、各番号に従って処理を説明
する。 （１）パーティションマネージャ（ＰＭ）の公開鍵証明
書（Ｃｅｒｔ．ＰＭ）の発行、 パーティションマネージャ（ＰＭ）の公開鍵証明書（Ｃ
ｅｒｔ．ＰＭ）は、パーティションマネージャ（ＰＭ）
からの発行要求により、登録局（ＲＡ）を介した証明書
発行手続きによってパーティション対応認証局（ＣＡ
（ＰＡＲ））から発行される。なお、本構成は、パーテ
ィションマネージャがサービス許可チケット発行手段
（ＳＰＴ Issuer）を兼ねる構成であり、サービス許可
チケット発行手段（ＳＰＴ Issuer）の公開鍵証明書と
してパーティションマネージャ（ＰＭ）の公開鍵証明書
を使用する構成である。

【０７９０】（２）サービス許可チケット（ＳＰＴ）の
生成処理 サービス許可チケット（ＳＰＴ）は、パーティションマ
ネージャの管理するサービス許可チケット発行手段（Ｓ
ＰＴ Ticket Issuer）により生成される。この場合、公
開鍵方式の署名生成、検証を実行するため、サービス許
可チケット発行手段（ＳＰＴ Ticket Issuer）の秘密鍵
による署名(Signature)が生成（図１２参照）されてＳ
ＰＴに付加される。

【０７９１】（３）ＳＰＴおよびサービス許可チケット
発行手段（ＳＰＴ Ticket Issuer）としてのパーティシ
ョンマネージャ公開鍵証明書（Ｃｅｒｔ．ＰＭ）のサー
ビス許可チケットユーザ（ＳＰＴ User）であるデバイ
スアクセス機器としてのリーダライタ（Ｒ／Ｗ）に対す
る供給 パーティションマネージャの管理するサービス許可チケ
ット発行手段（ＳＰＴTicket Issuer）により発行され
たサービス許可チケット（ＳＰＴ）は、サービス許可チ
ケット発行手段（ＳＰＴ Ticket Issuer）としてのパー
ティションマネージャ公開鍵証明書（Ｃｅｒｔ．ＰＭ）
とともにサービス許可チケットユーザ（ＳＰＴ User）
すなわち、デバイスに対してチケットを送信する機器
（ｅｘ．デバイスアクセス機器としてのリーダライタ）
に対して送信される。

【０７９２】（４）デバイスアクセス機器としてのリー
ダライタ（Ｒ／Ｗ）とデバイス間の相互認証 サービス許可チケットユーザ（ＳＰＴ User）であるデ
バイスアクセス機器としてのリーダライタは、サービス
許可チケット発行手段（ＳＰＴ Ticket Issuer）の発行
したサービス許可チケット（ＳＰＴ）に従ったファイル
アクセスを実行しようとする対象のデバイスとの間で、
共通鍵方式の相互認証（図５３、図５４参照）を実行す
る。

【０７９３】（５）ＳＰＴおよびサービス許可チケット
発行手段（ＳＰＴ Ticket Issuer）としてのパーティシ
ョンマネージャ公開鍵証明書（Ｃｅｒｔ．ＰＭ）のデバ
イスに対する供給 リーダライタ（Ｒ／Ｗ）とデバイス間の相互認証が成立
すると、サービス許可チケットユーザ（ＳＰＴ User）
であるデバイスアクセス機器としてのリーダライタは、
デバイスに対してサービス許可チケット（ＳＰＴ）、お
よびサービス許可チケット発行手段（ＳＰＴ Ticket Is
suer）としてのパーティションマネージャ公開鍵証明書
（Ｃｅｒｔ．ＰＭ）を送信する。

【０７９４】デバイスは、受信したサービス許可チケッ
ト（ＳＰＴ）について、（１）チケット発行者（Ticket
Issuer）としてのパーティションマネージャ公開鍵証
明書（Ｃｅｒｔ．ＰＭ）が改竄されたものでない正当な
公開鍵証明書（ＣＥＲＴ）であること、（２）チケット
発行者（Ticket Issuer）としてのパーティションマネ
ージャ公開鍵証明書（Ｃｅｒｔ．ＰＭ）のオプション領
域に記録されたコードと、デバイス内のＦＤＢ（File D
efinition Block）に記録されたチケット発行手段コー
ド（SPTIC）の一致、（３）チケット発行手段（Ticket
Issuer）がリボークされていないこと、（４）受信チケ
ット（ＳＰＴ）の署名（Signature）の検証によりチケ
ットが改竄のないことの確認を実行し、さらに、ＳＰＴ
チケットに格納されたＳＰＴユーザ（チケットユーザと
してのリーダライタ）とチケットユーザ（ＳＰＴ Use
r）の識別子の一致を確認し、相互認証済みであること
を確認することによりＳＰＴユーザ（リーダライタ）の
検証（図５７、図５８参照）を実行する。

【０７９５】（６）ファイルアクセス デバイスは、処理対象ファイルにサービス許可チケット
（ＳＰＴ）に記述されたルールに従ってアクセスを実行
する。

【０７９６】以上の処理によって、相互認証（共通
鍵）、チケット（ＳＰＴ）検証（公開鍵）の各方式に従
ったファイルアクセス処理が実行される。

【０７９７】［Ｂ５．データアップデートチケット（Ｄ
ＵＴ）を利用したデバイスのデータ更新処理］次に、デ
ータアップデートチケット（ＤＵＴ：Data Update Tick
et）を利用したデバイスのデータ更新処理について説明
する。データアップデートチケット（ＤＵＴ：Data Upd
ate Ticket）は、デバイスに格納された様々なデータの
更新処理を実行する際に適用されるアクセスコントロー
ルチケットである。正当なデータアップデートチケット
（ＤＵＴ）発行手段（Ticket Issuer）の発行したＤＵ
Ｔを用い、ＤＵＴに記録された手続きに従ってチケット
ユーザ（ｅｘ．デバイスアクセス機器としてのリーダラ
イタ）によりデバイスにアクセスすることで、ＤＵＴに
記録された制限内でデータ処理を実行することができ
る。

【０７９８】なお、前述したように、データアップデー
トチケット（ＤＵＴ：Data UpdateTicket）は、デバイ
スマネージャの管理するデータ項目の更新処理を実行す
るために適用されるチケットＤＵＴ（ＤＥＶ）と、パー
ティションマネージャの管理するパーティション内のデ
ータ項目の更新処理を実行するために適用されるチケッ
トＤＵＴ（ＰＡＲ）（図３２参照）がある。

【０７９９】デバイスに格納したデータにデータアップ
デートチケット（ＤＵＴ）を適用してデータ更新を実行
する処理について説明する。図９３以下のフロー他の図
面を参照して説明する。なお、データ更新処理には、デ
バイスとデータ更新を実行するデバイスアクセス機器と
してのリーダライタ間における相互認証処理（デバイス
認証またはパーティション認証）、データアップデート
チケット（ＤＵＴ：Data Update Ticket）の正当性検証
処理が含まれる。

【０８００】図９３に示すデータ更新処理フローについ
て説明する。図９３において、左側がデータ更新装置、
右側がデバイス（図５参照）の処理を示す。なお、デー
タ更新装置は、デバイスに対するデータ読み取り書き込
み処理可能な装置（ｅｘ．デバイスアクセス機器として
のリーダライタ、ＰＣ）であり、図１０のデバイスアク
セス機器としてのリーダライタに相当する。まず、図９
３を用いて、データ更新処理の概要を説明し、その後、
当処理に含まれるデータ更新操作の詳細を図９４のフロ
ーを用いて説明する。

【０８０１】まず、図９３のステップＳ９５１とＳ９６
０において、データ更新装置とデバイス間にでの相互認
証処理が実行される。データ送受信を実行する２つの手
段間では、相互に相手が正しいデータ通信者であるか否
かを確認して、その後に必要なデータ転送を行なうこと
が行われる。相手が正しいデータ通信者であるか否かの
確認処理が相互認証処理である。相互認証処理時にセッ
ション鍵の生成を実行して、生成したセッション鍵を共
有鍵として暗号化処理を実行してデータ送信を行なう。

【０８０２】相互認証処理については、先のパーティシ
ョン生成、削除処理の欄で説明したと同様の処理であ
り、デバイス認証またはパーティション認証のいずれか
が実行される。それぞれについて共通鍵方式認証、ある
いは公開鍵方式認証処理のいずれかが適用される。この
相互認証処理は、前述の図４８〜図５６を用いて説明し
たと同様の処理であるので説明を省略する。

【０８０３】なお、相互認証処理として実行すべき処理
は、適用するデータアップデートチケット（ＤＵＴ）
（図３２参照）の * Authentication Type :デバイス（Device）の相互認
証のタイプ（公開鍵認証、または、共通鍵認証、また
は、いずれでも可（Any））によって決定される。

【０８０４】認証処理に失敗した場合（Ｓ９５２，Ｓ９
６１でＮｏ）は、相互が正当な機器、デバイスであるこ
との確認がとれないことを示し、以下の処理は実行され
ずエラーとして処理は終了する。

【０８０５】認証処理に成功すると、データ更新装置
は、デバイスに対してデータアップデートチケット（Ｄ
ＵＴ：Data Update Ticket）を送信する。データアップ
デートチケット（ＤＵＴ）は、デバイスマネージャまた
はパーティションマネージャの管理下のデータアップデ
ートチケット（ＤＵＴ）発行手段（DUT Issuer）により
発行されるチケットである。データアップデートチケッ
ト（ＤＵＴ）は、デバイスに対するアクセス制御チケッ
トであり、先に説明した図３２のデータフォーマット構
成を持つチケットである。

【０８０６】なお、データアップデートチケット（ＤＵ
Ｔ）を、チケットユーザに対して送信する際には、公開
鍵方式の場合、データアップデートチケット（ＤＵＴ）
発行手段（DUT Issuer）の公開鍵証明書（CERT_DUTI）
も一緒に送信する。ＤＵＴ発行手段の公開鍵証明書（CE
RT_DUTI）の属性（Attribute）は、デバイス内のＤＫＤ
Ｂ（ＰＵＢ）(Device Key Definition Block)に記録さ
れたチケット発行手段コード（DUTIC＿DEV）やＰＫＤＢ
（ＰＵＢ）(Partition Key Definition Block)に記録さ
れたチケット発行手段コード（DUTIC＿PAR）の識別子(D
UTIC)と一致する。

【０８０７】データアップデートチケット（ＤＵＴ）を
受信（Ｓ９６２）したデバイスは、受信したチケット
（ＤＵＴ）の正当性と利用者チェック処理を実行（Ｓ９
６３）する。チケットの正当性の検証処理は、共通鍵方
式によるＭＡＣ検証、あるいは公開鍵方式による署名検
証処理のいずれかを適用して実行される。利用者チェッ
クは、チケットを送信してきた機器（チケット利用者）
の正当性をチェックする処理であり、相互認証が成立済
みであり、認証相手の識別データと、チケットに記録さ
れているチケットユーザ識別子（図３２参照）との一致
等を検証する処理として実行される。これらの処理は、
先のパーティション登録チケット（ＰＲＴ）の適用処理
についての説明中、図５７〜図５９を用いて説明したと
同様の処理であるので説明を省略する。

【０８０８】デバイスにおいて、受信チケット（ＤＵ
Ｔ）の正当性と利用者チェック処理の結果、チケットお
よび利用者の正当なことが確認できなかった場合（Ｓ９
６４でＮｏ）は、データアップデートチケット（ＤＵ
Ｔ）受理エラーをデータ更新装置に通知（Ｓ９６８）す
る。チケットおよび利用者の正当なことが確認できた場
合（Ｓ９６４でＹｅｓ）は、受信したデータアップデー
トチケット（ＤＵＴ）に記述されたルールに従いデバイ
ス内のメモリ部に格納されたデータ（図３３参照）の更
新処理を実行する。この処理の詳細については、別フロ
ーを用いて後段で詳述する。

【０８０９】データアップデートチケット（ＤＵＴ）の
記述に従って、データの更新処理に成功（Ｓ９６６でＹ
ｅｓ）すると、ＤＵＴ受理成功をデータ更新装置に通知
（Ｓ９６７）する。一方、データの更新処理に失敗（Ｓ
９６６でＮｏ）した場合は、ＤＵＴ受理エラーをデータ
更新装置に通知（Ｓ９６８）する。

【０８１０】データ更新装置は、ＤＵＴ受理結果を受信
（Ｓ９５４）し、ＤＵＴ処理結果を判定し、ＤＵＴ受理
結果がエラーである場合（Ｓ９５５でＮｏ）は、エラー
として処理を終了し、ＤＵＴ受理結果が成功（Ｓ９５５
でＹｅｓ）である場合はセッションクリアコマンドの送
受信（Ｓ９５６，Ｓ９６９）を実行し、デバイス側に生
成した認証テーブルを破棄（Ｓ９７０）し、処理を終了
する。認証テーブルは、ステップＳ９５１，Ｓ９６０の
相互認証処理において生成されるテーブルであり、前述
したパーティション登録チケット（ＰＲＴ）の適用処理
の項目において説明した構成、すなわち、図５１の構成
と同様のものである。

【０８１１】このようにデータアップデートチケット
（ＤＵＴ）を利用して、デバイス内に格納されたデータ
の更新処理が実行される。以下、当処理に含まれるデー
タ更新操作（Ｓ９６５）について、図９４を用いて説明
する。

【０８１２】図９４の処理フローは、データアップデー
トチケット（ＤＵＴ）を受理したデバイスにおいて実行
される処理であり、データアップデートチケット（ＤＵ
Ｔ）を送信してきた機器との相互認証が成立し、チケッ
トの検証にも成功した以後に実行される。

【０８１３】まず、ステップＳ９７１において、デバイ
スは、データアップデートチケット（ＤＵＴ）の更新さ
れる古いデータのコード（Old Data Code）から更新対
象データのバージョンを検索する。バージョンは、例え
ば更新対象がデバイスマネージャコード（ＤＭＣ）であ
れば、デバイス管理情報ブロック（図１５参照）にバー
ジョンが記録され、また、パーティションマネージャコ
ード（ＰＭＣ）であれば、パーティション管理情報ブロ
ック（図２０参照）にバージョンが記録されている。ま
た、パーティション登録チケット（ＰＲＴ）発行手段
（ＰＲＴ Issuer）のバージョンはデバイス定義ブロッ
ク（図１６参照）に含まれる。さらに、リボケーション
リスト（ＩＲＬ ＤＥＶ,ＣＲＬ ＤＥＶ）などは、リボ
ケーションリスト中にバージョン情報が含まれる。この
ように情報に応じてバージョン情報の格納先が決まって
おり、デバイスは、更新される古いデータのコード（Ol
d Data Code）から更新対象データのバージョンを検索
する。

【０８１４】次に、デバイスは、ステップＳ９７２にお
いて、データアップデートチケット（ＤＵＴ）に記録さ
れたデータ更新をする時のバージョン条件［Data Versi
on Rule］を参照し、設定が［Ａｎｙ］であるか否かを
判定する。

【０８１５】前述したように、データ更新をする時のバ
ージョン条件［Data Version Rule］は、Any, Exact, O
lder の３種類が存在する。Any はバージョン（Versio
n）条件に無関係でデータ更新が可能、Exact は、続く
［Data Version Condition］に指定された値と同じ場合
にデータ更新が可能、Older は、New Data Versionの方
が新しい場合にのみデータ更新が可能となる。なお、バ
ージョン条件［DataVersion Rule］がAny,または Older
の場合は、［Data Version Condition］は使用しない
かもしくは無視する。

【０８１６】データアップデートチケット（ＤＵＴ）の
［Data Version Rule］の設定が［Ａｎｙ］でない場合
は、バージョン条件［Data Version Rule］に従った処
理を実行する。このステップがＳ９７３〜Ｓ９７５であ
る。

【０８１７】ステップＳ９７３では、データアップデー
トチケット（ＤＵＴ）のバージョン条件［Data Version
Rule］を参照し、設定が［ＥＸＡＣＴ］であるか否か
を判定する。［ＥＸＡＣＴ］は、［Data Version Condi
tion］に指定された値と同じ場合にデータ更新が可能な
ことを示す。設定が［ＥＸＡＣＴ］である場合、ステッ
プＳ９７４で、更新対象データ［Ｏｌｄ Ｄａｔａ］の
バージョンがデータアップデートチケット（ＤＵＴ）の
［Data Version Condition］に記録されたバージョン値
と一致するか否かを判定する。一致する場合にのみ次ス
テップに進み、一致しない場合は、更新処理を実行せず
エラー終了とする。

【０８１８】ステップＳ９７３で、データアップデート
チケット（ＤＵＴ）のバージョン条件［Data Version R
ule］が［ＥＸＡＣＴ］でないと判定された場合は、設
定は［Ｏｌｄｅｒ］である。［Ｏｌｄｅｒ］の設定は、
更新対象データ［Ｏｌｄ Ｄａｔａ］のバージョンよ
り、データアップデートチケット（ＤＵＴ）の新規デー
タ［New Data］のバージョンを示す［New Data Versio
n］の方が新しい場合にのみ更新をする設定である。こ
の［Ｏｌｄｅｒ］の設定の場合、ステップＳ９７５にお
いて、更新対象データ［Ｏｌｄ Ｄａｔａ］のバージョ
ンより、データアップデートチケット（ＤＵＴ）の新規
データ［New Data］のバージョンを示す［New Data Ver
sion］の方が新しいか否かを判定し、新しい場合にのみ
次ステップに進み、一致しない場合は、更新処理を実行
せずエラー終了とする。

【０８１９】次にデバイスは、ステップＳ９７６におい
て、データアップデートチケット（ＤＵＴ）の［Encryp
ted Flag］を検証する。［Encrypted Flag］は、更新さ
れるデータが暗号化されているか否か(暗号化：Encrypt
ed /非暗号化：none)を示すデータである。［Encrypted
Flag］が更新対象データが非暗号化データであること
を示している場合は、ステップＳ９７７において、デー
タアップデートチケット（ＤＵＴ）の新規データ［New
Data］をデバイスのメモリ部に格納された更新対象旧デ
ータ［Old Data］に置き換える処理を実行し、処理終了
とする。なお、更新対象データに対してバージョンが付
加されている場合は、データアップデートチケット（Ｄ
ＵＴ：Data Update Ticket）に格納されている更新する
データのバージョン（New Data Version）を、デバイス
内の更新データに対応して設定されているバージョン格
納領域に格納する処理を実行する。

【０８２０】また、ステップＳ９７６において、データ
アップデートチケット（ＤＵＴ）の［Encrypted Flag］
が、更新されるデータが暗号化されている(暗号化：Enc
rypted)ことを示していると判定された場合は、ステッ
プＳ９７８において、データアップデートチケット（Ｄ
ＵＴ）の［Ticket Type］を検証する。［Ticket Type］
は、チケット（Ticket）の種別（ＤＵＴ（ＤＥＶ）／Ｄ
ＵＴ（ＰＡＲ））を示すデータである。ＤＵＴ（ＤＥ
Ｖ）は、データアップデートチケット（ＤＵＴ）が、デ
バイスマネージャの管理するデータ項目の更新処理を実
行するチケットあることを示し、ＤＵＴ（ＰＡＲ）は、
パーティションマネージャの管理するパーティション内
のデータ項目の更新処理を実行するために適用されるチ
ケットであることを示してる。

【０８２１】チケットタイプ［Ticket Type］が、ＤＵ
Ｔ（ＤＥＶ）を示している場合、ステップＳ９７９〜Ｓ
９８２を実行し、ＤＵＴ（ＰＡＲ）を示している場合、
ステップＳ９８３〜Ｓ９８６を実行する。

【０８２２】チケットタイプ［Ticket Type］が、ＤＵ
Ｔ（ＤＥＶ）を示している場合、ステップＳ９７９にお
いて、データアップデートチケット（ＤＵＴ（ＤＥ
Ｖ））に記述されたOld Data Code（更新される古いデ
ータのコード）の示すデータがデバイス鍵領域（図１８
参照）に格納されたKdut_DEV1（データアップデートチ
ケット（ＤＵＴ）のＭＡＣ検証用鍵）または、Kdut_DEV
2（データ更新用暗号鍵）であるか否かを判定する。

【０８２３】データアップデートチケット（ＤＵＴ（Ｄ
ＥＶ））に記述されたOld Data Code（更新される古い
データのコード）の示すデータがデバイス鍵領域（図１
８参照）に格納されたKdut_DEV1（データアップデート
チケット（ＤＵＴ）のＭＡＣ検証用鍵）、Kdut_DEV2
（データ更新用暗号鍵）である場合は、ステップＳ９８
０において、デバイスのデバイス鍵領域（図１８参照）
に格納されたKdut_DEV4（データ更新用暗号鍵）を用い
て、データアップデートチケット（ＤＵＴ（ＤＥＶ））
に格納された新規データ［New Data］としてのKdut_DEV
1、Kdut_DEV2を復号し、デバイスのデバイス鍵領域に格
納されたKdut_DEV1、Kdut_DEV2に上書きする。なお、デ
ータアップデートチケット（ＤＵＴ（ＤＥＶ））に格納
されている更新するデータのバージョン（New Data Ver
sion）を、デバイス内の更新データに対応して設定され
ているバージョン格納領域、この場合は、デバイスのデ
バイス鍵領域（図１８参照）に格納する処理を併せて実
行する。

【０８２４】次に、ステップＳ９８１において、デバイ
スのデバイス鍵領域（図１８参照）に格納されたKdut_D
EV1（データアップデートチケット（ＤＵＴ）のＭＡＣ
検証用鍵）と、Kdut_DEV3（データアップデートチケッ
ト（ＤＵＴ）のＭＡＣ検証用鍵）とのスワップ、すなわ
ち入れ替え処理を行ない、また、Kdut_DEV2（データ更
新用暗号鍵）と、Kdut_DEV4（データ更新用暗号鍵）と
のスワップ、すなわち入れ替え処理を行なって処理を終
了する。

【０８２５】なお、Kdut_DEV1と、Kdut_DEV3とのスワッ
プ、および、Kdut_DEV2と、Kdut_DEV4とのスワップ処理
によって、常にKdut_DEV3（データアップデートチケッ
ト（ＤＵＴ）のＭＡＣ検証用鍵）、Kdut_DEV4（データ
更新用暗号鍵）のペアがKdut_DEV1（データアップデー
トチケット（ＤＵＴ）のＭＡＣ検証用鍵）、Kdut_DEV2
（データ更新用暗号鍵）のペアよりも新しいバージョン
のものに維持され、書き換え対象を、常にKdut_DEV1、K
dut_DEV2として設定した処理が可能となる。

【０８２６】なお、ステップＳ９７９において、データ
アップデートチケット（ＤＵＴ（ＤＥＶ））に記述され
たOld Data Code（更新される古いデータのコード）の
示すデータがデバイス鍵領域（図１８参照）に格納され
たKdut_DEV1（データアップデートチケット（ＤＵＴ）
のＭＡＣ検証用鍵）、Kdut_DEV2（データ更新用暗号
鍵）でない場合は、ステップＳ９８２において、デバイ
スのデバイス鍵領域（図１８参照）に格納されたKdut_D
EV2（データ更新用暗号鍵）を用いて、データアップデ
ートチケット（ＤＵＴ（ＤＥＶ））に格納された新規デ
ータ［New Data］を復号し、データアップデートチケッ
ト（ＤＵＴ（ＤＥＶ））のOld Data code（更新される
古いデータのコード）の示すエリアに上書きする。な
お、更新対象データに対してバージョンが付加されてい
る場合は、データアップデートチケット（ＤＵＴ（ＤＥ
Ｖ））に格納されている更新するデータのバージョン
（New Data Version）を、デバイス内の更新データに対
応して設定されているバージョン格納領域に格納する処
理を実行する。

【０８２７】一方、ステップＳ９７８において、チケッ
トタイプ［Ticket Type］が、ＤＵＴ（ＰＡＲ）を示し
ている場合、ステップＳ９８３〜Ｓ９８６を実行する。

【０８２８】チケットタイプ［Ticket Type］が、ＤＵ
Ｔ（ＰＡＲ）を示している場合、ステップＳ９８３にお
いて、データアップデートチケット（ＤＵＴ（ＰＡ
Ｒ））に記述されたOld Data Code（更新される古いデ
ータのコード）の示すデータがパーティション鍵領域
（図２３参照）に格納されたKdut_PAR1（データアップ
デートチケット（ＤＵＴ）のＭＡＣ検証用鍵）または、
Kdut_PAR2（データ更新用暗号鍵）であるか否かを判定
する。

【０８２９】データアップデートチケット（ＤＵＴ（Ｐ
ＡＲ））に記述されたOld Data Code（更新される古い
データのコード）の示すデータがパーティション鍵領域
（図２３参照）に格納されたKdut_PAR1（データアップ
デートチケット（ＤＵＴ）のＭＡＣ検証用鍵）、Kdut_P
AR2（データ更新用暗号鍵）である場合は、ステップＳ
９８４において、デバイスのパーティション鍵領域（図
２３参照）に格納されたKdut_PAR4（データ更新用暗号
鍵）を用いて、データアップデートチケット（ＤＵＴ
（ＰＡＲ））に格納された新規データ［New Data］とし
てのKdut_PAR1、Kdut_PAR2を復号し、デバイスのパーテ
ィション鍵領域に格納されたKdut_PAR1、Kdut_PAR2に上
書きする。なお、データアップデートチケット（ＤＵＴ
（ＰＡＲ））に格納されている更新するデータのバージ
ョン（New Data Version）を、デバイス内の更新データ
に対応して設定されているバージョン格納領域、この場
合は、デバイスのパーティション鍵領域（図２３参照）
に格納する処理を併せて実行する。

【０８３０】次に、ステップＳ９８５において、デバイ
スのパーティション鍵領域（図２３参照）に格納された
Kdut_PAR1（データアップデートチケット（ＤＵＴ）の
ＭＡＣ検証用鍵）と、Kdut_PAR3（データアップデート
チケット（ＤＵＴ）のＭＡＣ検証用鍵）とのスワップ、
すなわち入れ替え処理を行ない、また、Kdut_PAR2（デ
ータ更新用暗号鍵）と、Kdut_PAR4（データ更新用暗号
鍵）とのスワップ、すなわち入れ替え処理を行なって処
理を終了する。

【０８３１】なお、Kdut_PAR1と、Kdut_PAR3とのスワッ
プ、および、Kdut_ PARV2と、Kdut_PAR4とのスワップ処
理によって、常にKdut_PAR3（データアップデートチケ
ット（ＤＵＴ）のＭＡＣ検証用鍵）、Kdut_PAR4（デー
タ更新用暗号鍵）のペアがKdut_PAR1（データアップデ
ートチケット（ＤＵＴ）のＭＡＣ検証用鍵）、Kdut_PAR
2（データ更新用暗号鍵）のペアよりも新しいバージョ
ンのものに維持され、書き換え対象を、常にKdut_PAR
1、Kdut_PAR2として設定した処理が可能となる。

【０８３２】なお、ステップＳ９８３において、データ
アップデートチケット（ＤＵＴ（ＰＡＲ））に記述され
たOld Data Code（更新される古いデータのコード）の
示すデータがデバイス鍵領域（図１８参照）に格納され
たKdut_DEV1（データアップデートチケット（ＤＵＴ）
のＭＡＣ検証用鍵）、Kdut_DEV2（データ更新用暗号
鍵）でない場合は、ステップＳ９８６において、デバイ
スのパーティション鍵領域（図２３参照）に格納された
Kdut_PAR2（データ更新用暗号鍵）を用いて、データア
ップデートチケット（ＤＵＴ（ＰＡＲ））に格納された
新規データ［NewData］を復号し、データアップデート
チケット（ＤＵＴ（ＰＡＲ））のOld DataCode（更新さ
れる古いデータのコード）の示すエリアに上書きする。
なお、更新対象データに対してバージョンが付加されて
いる場合は、データアップデートチケット（ＤＵＴ（Ｐ
ＡＲ））に格納されている更新するデータのバージョン
（New Data Version）を、デバイス内の更新データに対
応して設定されているバージョン格納領域に格納する処
理を実行する。

【０８３３】以上の処理がデバイスにおいて実行される
データフップデートチケットに基づくデータ更新操作で
ある。

【０８３４】上述したフローから理解されるように、更
新対象データがデバイス鍵領域に格納された Kdut_DEV1（データアップデートチケット（ＤＵＴ）の
ＭＡＣ検証用鍵） Kdut_DEV2（データ更新用暗号鍵） または、パーティション鍵領域に格納された Kdut_PAR1（データアップデートチケット（ＤＵＴ）の
ＭＡＣ検証用鍵） Kdut_PAR2（データ更新用暗号鍵） である場合には、他の更新処理と異なる処理を実行す
る。

【０８３５】これらのKdut_DEV1（データアップデート
チケット（ＤＵＴ）のＭＡＣ検証用鍵）、Kdut_DEV2
（データ更新用暗号鍵）、Kdut_PAR1（データアップデ
ートチケット（ＤＵＴ）のＭＡＣ検証用鍵）、Kdut_PAR
2（データ更新用暗号鍵）についての更新処理を簡潔に
まとめた図を図９５に示し、処理について説明する。図
９５の（１）〜（３）の順に説明する。なお、処理は、
Kdut_DEV1,2と、Kdut_PAR1,2とで同様のものであるの
で、Kdut_DEV1,2を更新する場合について説明する。

【０８３６】（１）データアップデートチケット（ＤＵ
Ｔ）に格納する新規データ［New Data］としてのKdut_D
EV1、Kdut_DEV2をデバイスのデバイス鍵領域（図１８参
照）に格納されたKdut_DEV4（データ更新用暗号鍵）を
用いて暗号化した後、データアップデートチケット（Ｄ
ＵＴ）に格納し、データアップデートチケット（ＤＵ
Ｔ）をデバイスに送信する。このとき、Kdut_DEV1、Kdu
t_DEV2を更新できるチケット発行者はKdut_DEV3、Kdut_
DEV4を知らなくてはならない。

【０８３７】（２）データアップデートチケット（ＤＵ
Ｔ）を受信したデバイスは、デバイスのデバイス鍵領域
に格納されたKdut_DEV4（データ更新用暗号鍵）を用い
て、データアップデートチケット（ＤＵＴ）の格納新規
データ［New Data］としてのKdut_DEV1、Kdut_DEV2を復
号し、デバイスのデバイス鍵領域に格納されたKdut_DEV
1、Kdut_DEV2に上書きする。

【０８３８】（３）次に、デバイスは、デバイスのデバ
イス鍵領域（図１８参照）に新規に格納されたKdut_DEV
1（データアップデートチケット（ＤＵＴ）のＭＡＣ検
証用鍵）と、以前に格納済みのKdut_DEV3（データアッ
プデートチケット（ＤＵＴ）のＭＡＣ検証用鍵）とのス
ワップ、すなわち入れ替え処理を行なう。さらに、新規
に格納されたKdut_DEV2（データ更新用暗号鍵）と、以
前に格納済みのKdut_DEV4（データ更新用暗号鍵）との
スワップ、すなわち入れ替え処理を行なう。

【０８３９】この、Kdut_DEV1と、Kdut_DEV3とのスワッ
プ、および、Kdut_DEV2と、Kdut_DEV4とのスワップ処理
によって、常にKdut_DEV3（データアップデートチケッ
ト（ＤＵＴ）のＭＡＣ検証用鍵）、Kdut_DEV4（データ
更新用暗号鍵）のペアがKdut_DEV1（データアップデー
トチケット（ＤＵＴ）のＭＡＣ検証用鍵）、Kdut_DEV2
（データ更新用暗号鍵）のペアよりも新しいバージョン
のものに維持される。つまり、Kdut_DEV1と、Kdut_DEV2
の鍵は常に使用される鍵で、Kdut_DEV3と、Kdut_DEV4
は、非常時にKdut_DEV1と、Kdut_DEV2を更新するととも
に、現在使用されているKdut_DEV1と、Kdut_DEV2の鍵に
置き換えられるバックアップ用の鍵としての役割があ
る。

【０８４０】なお、Kdut_DEV1（データアップデートチ
ケット（ＤＵＴ）のＭＡＣ検証用鍵）、Kdut_DEV2（デ
ータ更新用暗号鍵）はペアとして使用され、また、Kdut
_DEV3（データアップデートチケット（ＤＵＴ）のＭＡ
Ｃ検証用鍵）、Kdut_DEV4（データ更新用暗号鍵）もペ
アとして使用される。

【０８４１】以上、特定の実施例を参照しながら、本発
明について詳解してきた。しかしながら、本発明の要旨
を逸脱しない範囲で当業者が該実施例の修正や代用を成
し得ることは自明である。すなわち、例示という形態で
本発明を開示してきたのであり、限定的に解釈されるべ
きではない。本発明の要旨を判断するためには、冒頭に
記載した特許請求の範囲の欄を参酌すべきである。

【０８４２】なお、明細書中において説明した一連の処
理はハードウェア、またはソフトウェア、あるいは両者
の複合構成によって実行することが可能である。ソフト
ウェアによる処理を実行する場合は、処理シーケンスを
記録したプログラムを、専用のハードウェアに組み込ま
れたコンピュータ内のメモリにインストールして実行さ
せるか、あるいは、各種処理が実行可能な汎用コンピュ
ータにプログラムをインストールして実行させることが
可能である。

【０８４３】例えば、プログラムは記録媒体としてのハ
ードディスクやＲＯＭ（Read OnlyMemory)に予め記録し
ておくことができる。あるいは、プログラムはフロッピ
ーディスク、ＣＤ−ＲＯＭ(Compact Disc Read Only Me
mory)，ＭＯ(Magneto optical)ディスク，ＤＶＤ(Digit
al Versatile Disc)、磁気ディスク、半導体メモリなど
のリムーバブル記録媒体に、一時的あるいは永続的に格
納（記録）しておくことができる。このようなリムーバ
ブル記録媒体は、いわゆるパッケージソフトウエアとし
て提供することができる。

【０８４４】なお、プログラムは、上述したようなリム
ーバブル記録媒体からコンピュータにインストールする
他、ダウンロードサイトから、コンピュータに無線転送
したり、ＬＡＮ(Local Area Network)、インターネット
といったネットワークを介して、コンピュータに有線で
転送し、コンピュータでは、そのようにして転送されて
くるプログラムを受信し、内蔵するハードディスク等の
記録媒体にインストールすることができる。

【０８４５】なお、明細書に記載された各種の処理は、
記載に従って時系列に実行されるのみならず、処理を実
行する装置の処理能力あるいは必要に応じて並列的にあ
るいは個別に実行されてもよい。また、本明細書におい
てシステムとは、複数の装置の論理的集合構成であり、
各構成の装置が同一筐体内にあるものには限らない。

【０８４６】

【発明の効果】上述したように、本発明のデータ処理シ
ステム、メモリ搭載デバイス、およびデータ処理方法、
並びにプログラム記憶媒体によれば、複数のパーティシ
ョンに分割されたメモリ領域のアクセスに対して、様々
な種類のアクセス制御チケットを各デバイスまたはパー
ティション管理エンティテイの管理の下に発行し、各チ
ケットに記述されたルールに基づく処理をメモリ搭載デ
バイスにおいて実行する構成が可能となり、各パーティ
ション内データの独立した管理構成が実現される。

【０８４７】さらに、本発明のデータ処理システム、メ
モリ搭載デバイス、およびデータ処理方法、並びにプロ
グラム記憶媒体によれば、パーティション対応の認証、
デバイス対象の認証を公開鍵、共通鍵のいずれか指定方
式に従って実行することが可能なデバイスとし、様々な
環境下においてデバイスおよびアクセス装置間のセキュ
アなデータ通信が実行可能となる。

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

【図面の簡単な説明】

【図１】本発明のシステム構成の概要を説明するシステ
ム構成概略図（その1）である。

【図２】本発明のシステム構成の概要を説明するシステ
ム構成概略図（その２）である。

【図３】本発明のシステム構成の具体例を説明するシス
テム構成概略図（その３）である。

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

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

【図６】本発明のデバイスのメモリフォーマットを示す
図である。

【図７】本発明のシステムにおけるデバイスマネージャ
構成を示す図である。

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

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

【図１０】本発明のシステムにおけるリーダライタ（Ｒ
／Ｗ）構成を示す図である。

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

【図１２】本発明のシステムにおいて利用可能な公開鍵
方式の署名生成処理フローを示す図である。

【図１３】本発明のシステムにおいて利用可能な公開鍵
方式の署名検証処理フローを示す図である。

【図１４】本発明のデバイスにおけるメモリ部に格納さ
れるデータ中の製造情報ブロックのデータ構成を示す図
である。

【図１５】本発明のデバイスにおけるメモリ部に格納さ
れるデータ中のデバイス管理情報ブロックのデータ構成
を示す図である。

【図１６】本発明のデバイスにおけるメモリ部に格納さ
れるデータ中の公開鍵系デバイス鍵定義ブロックのデー
タ構成を示す図である。

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

【図１８】本発明のデバイスにおけるメモリ部に格納さ
れるデータ中のデバイス鍵領域のデータ構成を示す図で
ある。

【図１９】本発明のデバイスにおけるメモリ部に格納さ
れるデータ中のパーティション定義ブロックのデータ構
成を示す図である。

【図２０】本発明のデバイスにおけるメモリ部に格納さ
れるデータ中のパーティション管理情報ブロックのデー
タ構成を示す図である。

【図２１】本発明のデバイスにおけるメモリ部に格納さ
れるデータ中の公開鍵系パーティション鍵定義ブロック
のデータ構成を示す図である。

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

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

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

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

【図２６】本発明のシステムにおいて適用されるアクセ
ス制御チケットとしてのパーティション登録チケット
（ＰＲＴ）のフォーマットを示す図である。

【図２７】本発明のシステムにおいて適用されるアクセ
ス制御チケットとしてのファイル登録チケット（ＦＲ
Ｔ）のフォーマットを示す図である。

【図２８】本発明のシステムにおいて適用されるアクセ
ス制御チケットとしてのサービス許可チケット（ＳＰ
Ｔ）のフォーマット（例１）を示す図である。

【図２９】本発明のシステムにおいて適用されるアクセ
ス制御チケットとしてのサービス許可チケット（ＳＰ
Ｔ）を利用したファイルアクセスのモードの種別を説明
する図である。

【図３０】本発明のシステムにおいて適用されるアクセ
ス制御チケットとしてのサービス許可チケット（ＳＰ
Ｔ）を利用したアクセス対象となるファイル構造を説明
する図である。

【図３１】本発明のシステムにおいて適用されるアクセ
ス制御チケットとしてのサービス許可チケット（ＳＰ
Ｔ）のフォーマット（例２）を示す図である。

【図３２】本発明のシステムにおいて適用されるアクセ
ス制御チケットとしてのデータアップデートチケット
（ＤＵＴ）のフォーマットを示す図である。

【図３３】本発明のシステムにおいて適用されるアクセ
ス制御チケットとしてのデータアップデートチケット
（ＤＵＴ）を利用した更新対象となるデータを説明する
図である。

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

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

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

【図３７】本発明のシステムにおけるデバイスマネージ
ャによるデバイスの初期登録処理フロー（その２）を示
す図である。

【図３８】本発明のシステムにおけるデバイスマネージ
ャによるデバイスの初期登録処理フロー（その３）を示
す図である。

【図３９】本発明のシステムにおけるデバイスマネージ
ャによるデバイスの初期登録処理フロー（その４）を示
す図である。

【図４０】本発明のシステムにおけるデバイスマネージ
ャによるデバイスの初期登録処理フロー（その５）を示
す図である。

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

【図４２】本発明のシステムにおけるデバイスマネージ
ャによる公開鍵証明書発行処理フロー（その1）を示す
図である。

【図４３】本発明のシステムにおけるデバイスマネージ
ャによる公開鍵証明書発行処理フロー（その２）を示す
図である。

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

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

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

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

【図４８】本発明のシステムにおけるデバイスとの相互
認証処理について説明するフロー（その１）である。

【図４９】本発明のシステムにおけるデバイスとの相互
認証処理（デバイス認証）について説明するフロー（そ
の２）である。

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

【図５１】本発明のシステムにおけるデバイスとの相互
認証処理後にデバイスに生成される認証テーブルの構成
を説明する図である。

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

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

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

【図５５】本発明のシステムにおけるデバイスとの相互
認証処理（パーティション認証）について説明するフロ
ー（その３）である。

【図５６】本発明のシステムにおけるデバイスとの相互
認証処理（パーティション認証）について説明するフロ
ー（その４）である。

【図５７】本発明のシステムにおけるチケットの正当
性、利用者チェック処理について説明するフロー（その
１）である。

【図５８】本発明のシステムにおけるチケットの正当
性、利用者チェック処理について説明するフロー（その
２）である。

【図５９】本発明のシステムにおけるチケットの正当性
で適用可能なＭＡＣ生成方式について説明するフロー
（その１）である。

【図６０】本発明のシステムにおけるパーティションの
作成、削除操作について説明するフロー（その１）であ
る。

【図６１】本発明のシステムにおけるパーティションの
作成、削除操作について説明するフロー（その２）であ
る。

【図６２】本発明のシステムにおけるパーティションの
初期登録処理について説明するフロー（その１）であ
る。

【図６３】本発明のシステムにおけるパーティションの
初期登録処理について説明するフロー（その２）であ
る。

【図６４】本発明のシステムにおけるパーティションの
初期登録処理について説明するフロー（その３）であ
る。

【図６５】本発明のシステムにおけるパーティションの
初期登録処理後のデバイス格納データについて説明する
図である。

【図６６】本発明のシステムにおけるパーティションマ
ネージャによる公開鍵証明書発行処理を説明する図（そ
の１）である。

【図６７】本発明のシステムにおけるパーティションマ
ネージャによる公開鍵証明書発行処理を説明する図（そ
の２）である。

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

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

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

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

【図７２】本発明のシステムにおけるファイル登録チケ
ット（ＦＲＴ）を適用したファイル生成消去処理につい
て説明するフロー図である。

【図７３】本発明のシステムにおけるファイル登録チケ
ット（ＦＲＴ）を適用したファイル生成削除操作につい
て説明するフロー図である。

【図７４】本発明のシステムにおけるファイル登録チケ
ット（ＦＲＴ）を適用したファイル生成後のデバイス格
納データを説明する図である。

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

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

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

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

【図７９】本発明のシステムにおけるサービス許可チケ
ット（ＳＰＴ）を適用したファイルアクセス処理フロー
を示す図である。

【図８０】本発明のシステムにおけるサービス許可チケ
ット（ＳＰＴ）を適用したファイルオープン操作フロー
を示す図である。

【図８１】本発明のシステムにおけるサービス許可チケ
ット（ＳＰＴ）を適用したファイルオープン操作により
生成されるファイルオープンテーブル構成を説明する図
（例１）である。

【図８２】本発明のシステムにおけるサービス許可チケ
ット（ＳＰＴ）を適用したファイルオープン操作により
生成されるファイルオープンテーブル構成を説明する図
（例２）である。

【図８３】本発明のシステムにおけるサービス許可チケ
ット（ＳＰＴ）を適用したファイルアクセス処理例を説
明する図（例１）である。

【図８４】本発明のシステムにおけるサービス許可チケ
ット（ＳＰＴ）を適用したファイルアクセス処理例を説
明する図（例２）である。

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

【図８６】本発明のシステムにおけるサービス許可チケ
ット（ＳＰＴ）を適用したファイルアクセス処理例を説
明するフロー図（例１）である。

【図８７】本発明のシステムにおけるサービス許可チケ
ット（ＳＰＴ）を適用したファイルアクセス処理例を説
明するフロー図（例２）である。

【図８８】本発明のシステムにおけるサービス許可チケ
ット（ＳＰＴ）を適用した複合ファイルのアクセス処理
例を説明する図である。

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

【図９０】本発明のシステムにおけるサービス許可チケ
ット（ＳＰＴ）による処理において、公開鍵方式認証、
共通鍵方式チケット検証を実行した場合の処理を説明す
る図である。

【図９１】本発明のシステムにおけるサービス許可チケ
ット（ＳＰＴ）による処理において、共通鍵方式認証、
共通鍵方式チケット検証を実行した場合の処理を説明す
る図である。

【図９２】本発明のシステムにおけるサービス許可チケ
ット（ＳＰＴ）による処理において、共通鍵方式認証、
公開鍵方式チケット検証を実行した場合の処理を説明す
る図である。

【図９３】本発明のシステムにおけるデータアップデー
トチケット（ＤＵＴ）によるデータ更新処理フローを示
す図である。

【図９４】本発明のシステムにおけるデータアップデー
トチケット（ＤＵＴ）によるデータ更新操作フローを示
す図である。

【図９５】本発明のシステムにおけるデータアップデー
トチケット（ＤＵＴ）によるデータ更新処理例を説明す
る図である。

【図９６】従来のメモリ構造を示す図である。

【図９７】従来のメモリ管理者、利用者の関係を説明す
る図である。

【図９８】従来のメモリ領域確保処理について説明する
図である。

【図９９】従来のメモリアクセス方式について説明する
図である。

【符号の説明】

１００ デバイス ２００ デバイスマネージャ ３００ パーティションマネージャ ４００ コード管理機関 ５００ デバイス製造エンティテイ ２１０ パーティション登録チケット（ＰＲＴ）発行手
段 ２２０ 登録局（ＲＡ） ３１０ ファイル登録チケット（ＦＲＴ）発行手段 ３２０ サービス許可チケット（ＳＰＴ）発行手段 ３３０ 登録局（ＲＡ） ６１０，６２０ 認証局（ＣＡ） ７１１〜７１４ リーダライタ（Ｒ／Ｗ） ７２１〜７２２ チケットユーザ １０１ ＣＰＵ １０２ 通信ＩＦ １０３ ＲＯＭ １０４ ＲＡＭ １０５ 暗号処理部 １０６ メモリ部（ＥＥＰＲＯＭ） ２１１，２２１ 制御手段 ２１２，２２２ データベース ２１１１ 制御部 ２１１２ ＲＯＭ ２１１３ ＲＡＭ ２１１４ 表示部 ２１１５ 入力部 ２１１６ ＨＤＤ ２１１７ ドライブ ２１１８ 通信Ｉ／Ｆ ３１１，３２１，３３１ 制御手段 ３１２，３２２，３３２ データベース ７０１ ＣＰＵ ７０２ 通信ＩＦ ７０３ ＲＯＭ ７０４ ＲＡＭ ７０５ 暗号処理部 ７０６ メモリ部（ＥＥＰＲＯＭ）

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｈ０４Ｌ 9/00 ６７３Ｅ ６７５Ｂ (72)発明者 白井 太三 東京都品川区北品川６丁目７番35号 ソニ ー株式会社内 (72)発明者 高田 昌幸 東京都品川区北品川６丁目７番35号 ソニ ー株式会社内 Ｆターム(参考） 5J104 AA07 AA08 AA09 AA16 EA05 KA02 KA06 LA01 LA03 LA06 NA02 NA03 NA35 NA36 NA37 NA40

Claims (22)

【特許請求の範囲】
1. 【請求項１】データ格納可能なメモリ部を有するメモリ
   搭載デバイスに対するアクセス機器からのアクセス要求
   に応じて、前記メモリ部に対するデータ処理を実行する
   データ処理システムであり、 前記メモリ搭載デバイスは、前記メモリ部に対するデー
   タ処理に対応して構成されるアクセス制御チケットを前
   記アクセス機器から受領して、該アクセス制御チケット
   に記述されたルールに基づくデータ処理を実行する構成
   であるとともに、 前記アクセス機器からの指定または受領したアクセス制
   御チケットの記述に基づいて、前記アクセス機器との相
   互認証の方式を決定して実行するとともに、受領したア
   クセス制御チケットの記述に基づいて、アクセス制御チ
   ケットの検証方式を決定して実行し、相互認証およびチ
   ケット検証の双方の成立を条件として前記アクセス機器
   からのアクセス要求に応じる構成を有することを特徴と
   するデータ処理システム。
2. 【請求項２】前記相互認証の方式は、公開鍵方式または
   共通鍵方式のいずれかであり、アクセス制御チケットの
   検証方式は、公開鍵方式または共通鍵方式のいずれかで
   あることを特徴とする請求項１に記載のデータ処理シス
   テム。
3. 【請求項３】前記メモリ搭載デバイスは、 前記アクセス制御チケットの検証を実行するためのＭＡ
   Ｃ検証用鍵を保有し、前記アクセス機器から受領したア
   クセス制御チケットの検証を共通鍵方式に従って実行す
   る場合には、該ＭＡＣ検証用鍵を適用した改竄チェック
   処理を実行し、 アクセス制御チケットの検証を公開鍵方式に従って実行
   する場合には、チケット発行手段の公開鍵証明書から取
   得したチケット発行手段の公開鍵に基づく署名検証処理
   を実行する構成であることを特徴とする請求項１に記載
   のデータ処理システム。
4. 【請求項４】前記メモリ搭載デバイスは、 前記アクセス制御チケットの検証を実行するためのＭＡ
   Ｃ検証用鍵を複数保有し、前記アクセス機器から受領し
   たアクセス制御チケットに記録された情報に従って適用
   すべきＭＡＣ検証用鍵を選択する構成であることを特徴
   とする請求項１に記載のデータ処理システム。
5. 【請求項５】前記アクセス制御チケットには、 前記メモリ搭載デバイスのメモリ部内の格納データの更
   新処理を許容するデータアップデートチケット（ＤＵ
   Ｔ）を含み、 前記メモリ搭載デバイスは、前記アクセス制御チケット
   の検証を実行するためのＭＡＣ検証用鍵を複数保有し、 前記メモリ搭載デバイスは、 前記アクセス機器から受領したデータアップデートチケ
   ット（ＤＵＴ）に指定された更新対象データがアクセス
   制御チケットの検証を実行するためのＭＡＣ検証用鍵で
   ある場合は、複数のＭＡＣ検証用鍵から更新対象に該当
   しないＭＡＣ検証用鍵を選択して受領したデータアップ
   デートチケット（ＤＵＴ）の検証処理を実行することを
   特徴とする請求項１に記載のデータ処理システム。
6. 【請求項６】前記メモリ搭載デバイスのメモリ部は、 各々が対応するパーティションマネージャによって管理
   されるメモリ領域としての１以上のパーティション領域
   を有し、 前記メモリ搭載デバイスは、 前記アクセス機器からの各パーティション内のデータに
   対するアクセス要求に対する処理を、各パーティション
   マネージャの管理下のチケット発行手段が発行し、チケ
   ット利用手段としての前記アクセス機器から前記メモリ
   搭載デバイスに対して入力されるアクセス制御チケット
   の記述に基づいて実行する構成であることを特徴とする
   請求項１に記載のデータ処理システム。
7. 【請求項７】前記メモリ搭載デバイスのメモリ部は、 各々が対応するパーティションマネージャによって管理
   されるメモリ領域としての１以上のパーティション領域
   を有し、 前記メモリ搭載デバイスは、 前記アクセス機器とのセッション中に実行したパーティ
   ション認証またはデバイス認証によって取得した公開鍵
   方式認証情報およびセッション鍵、または共通鍵方式認
   証情報およびセッション鍵を対応付けた認証テーブルを
   生成して、当該セッション期間、保持する構成を有する
   ことを特徴とする請求項１に記載のデータ処理システ
   ム。
8. 【請求項８】データ格納可能なメモリ部を有するメモリ
   搭載デバイスであり、 アクセス機器からのアクセス要求に応じて、前記メモリ
   部に対するデータ処理を実行する制御手段を有し、 前記制御手段は、前記メモリ部に対するデータ処理に対
   応して構成されるアクセス制御チケットを前記アクセス
   機器から受領して、該アクセス制御チケットに記述され
   たルールに基づくデータ処理を実行する構成であるとと
   もに、 前記アクセス機器からの指定または受領したアクセス制
   御チケットの記述に基づいて、前記アクセス機器との相
   互認証の方式を決定して実行するとともに、受領したア
   クセス制御チケットの記述に基づいて、アクセス制御チ
   ケットの検証方式を決定して実行し、相互認証およびチ
   ケット検証の双方の成立を条件として前記アクセス機器
   からのアクセス要求に応じる構成を有することを特徴と
   するメモリ搭載デバイス。
9. 【請求項９】前記制御手段は、 前記相互認証の方式として、公開鍵方式または共通鍵方
   式のいずれかを選択的に実行し、 アクセス制御チケットの検証方式として、公開鍵方式ま
   たは共通鍵方式のいずれかを選択的に実行する構成であ
   ることを特徴とする請求項８に記載のメモリ搭載デバイ
   ス。
10. 【請求項１０】前記メモリ搭載デバイスは、 前記アクセス制御チケットの検証を実行するためのＭＡ
    Ｃ検証用鍵を保有し、前記制御手段は、 前記アクセス機器から受領したアクセス制御チケットの
    検証を共通鍵方式に従って実行する場合には、該ＭＡＣ
    検証用鍵を適用した改竄チェック処理を実行し、 アクセス制御チケットの検証を公開鍵方式に従って実行
    する場合には、チケット発行手段の公開鍵証明書から取
    得したチケット発行手段の公開鍵に基づく署名検証処理
    を実行する構成であることを特徴とする請求項８に記載
    のメモリ搭載デバイス。
11. 【請求項１１】前記メモリ搭載デバイスは、 前記アクセス制御チケットの検証を実行するためのＭＡ
    Ｃ検証用鍵を複数保有し、 前記制御手段は、 前記アクセス機器から受領したアクセス制御チケットに
    記録された情報に従って適用すべきＭＡＣ検証用鍵を選
    択する構成であることを特徴とする請求項８に記載のメ
    モリ搭載デバイス。
12. 【請求項１２】前記アクセス制御チケットには、 前記メモリ搭載デバイスのメモリ部内の格納データの更
    新処理を許容するデータアップデートチケット（ＤＵ
    Ｔ）を含み、 前記メモリ搭載デバイスは、前記アクセス制御チケット
    の検証を実行するためのＭＡＣ検証用鍵を複数保有し、 前記制御手段は、 前記アクセス機器から受領したデータアップデートチケ
    ット（ＤＵＴ）に指定された更新対象データがアクセス
    制御チケットの検証を実行するためのＭＡＣ検証用鍵で
    ある場合は、複数のＭＡＣ検証用鍵から更新対象に該当
    しないＭＡＣ検証用鍵を選択して受領したデータアップ
    デートチケット（ＤＵＴ）の検証処理を実行することを
    特徴とする請求項８に記載のメモリ搭載デバイス。
13. 【請求項１３】前記メモリ搭載デバイスのメモリ部は、 各々が対応するパーティションマネージャによって管理
    されるメモリ領域としての１以上のパーティション領域
    を有し、 前記制御手段は、 前記アクセス機器からの各パーティション内のデータに
    対するアクセス要求に対する処理を、各パーティション
    マネージャの管理下のチケット発行手段が発行し、チケ
    ット利用手段としての前記アクセス機器から前記メモリ
    搭載デバイスに対して入力されるアクセス制御チケット
    の記述に基づいて実行する構成であることを特徴とする
    請求項８に記載のメモリ搭載デバイス。
14. 【請求項１４】前記メモリ搭載デバイスのメモリ部は、 各々が対応するパーティションマネージャによって管理
    されるメモリ領域としての１以上のパーティション領域
    を有し、 前記制御手段は、 前記アクセス機器とのセッション中に実行したパーティ
    ション認証またはデバイス認証によって取得した公開鍵
    方式認証情報およびセッション鍵、または共通鍵方式認
    証情報およびセッション鍵を対応付けた認証テーブルを
    生成して、当該セッション期間、保持する構成を有する
    ことを特徴とする請求項８に記載のメモリ搭載デバイ
    ス。
15. 【請求項１５】データ格納可能なメモリ部を有するメモ
    リ搭載デバイスに対するアクセス機器からのアクセス要
    求に応じて、前記メモリ部に対するデータ処理を実行す
    るデータ処理方法であり、 前記メモリ搭載デバイスにおいて、 前記メモリ部に対するデータ処理に対応して構成される
    アクセス制御チケットを前記アクセス機器から受領し
    て、該アクセス制御チケットに記述されたルールに基づ
    くデータ処理を実行し、 前記アクセス機器からの指定または受領したアクセス制
    御チケットの記述に基づいて、前記アクセス機器との相
    互認証の方式を決定して実行するとともに、受領したア
    クセス制御チケットの記述に基づいて、アクセス制御チ
    ケットの検証方式を決定して実行し、相互認証およびチ
    ケット検証の双方の成立を条件として前記アクセス機器
    からのアクセス要求を実行することを特徴とするデータ
    処理方法。
16. 【請求項１６】前記相互認証の方式は、公開鍵方式また
    は共通鍵方式のいずれかであり、アクセス制御チケット
    の検証方式は、公開鍵方式または共通鍵方式のいずれか
    であることを特徴とする請求項１５に記載のデータ処理
    方法。
17. 【請求項１７】前記メモリ搭載デバイスは、 前記アクセス制御チケットの検証を実行するためのＭＡ
    Ｃ検証用鍵を保有し、前記アクセス機器から受領したア
    クセス制御チケットの検証を共通鍵方式に従って実行す
    る場合には、該ＭＡＣ検証用鍵を適用した改竄チェック
    処理を実行し、 アクセス制御チケットの検証を公開鍵方式に従って実行
    する場合には、チケット発行手段の公開鍵証明書から取
    得したチケット発行手段の公開鍵に基づく署名検証処理
    を実行することを特徴とする請求項１５に記載のデータ
    処理方法。
18. 【請求項１８】前記メモリ搭載デバイスは、 前記アクセス制御チケットの検証を実行するためのＭＡ
    Ｃ検証用鍵を複数保有し、前記アクセス機器から受領し
    たアクセス制御チケットに記録された情報に従って適用
    すべきＭＡＣ検証用鍵を選択することを特徴とする請求
    項１５に記載のデータ処理方法。
19. 【請求項１９】前記アクセス制御チケットには、 前記メモリ搭載デバイスのメモリ部内の格納データの更
    新処理を許容するデータアップデートチケット（ＤＵ
    Ｔ）を含み、 前記メモリ搭載デバイスは、前記アクセス制御チケット
    の検証を実行するためのＭＡＣ検証用鍵を複数保有し、 前記メモリ搭載デバイスは、 前記アクセス機器から受領したデータアップデートチケ
    ット（ＤＵＴ）に指定された更新対象データがアクセス
    制御チケットの検証を実行するためのＭＡＣ検証用鍵で
    ある場合は、複数のＭＡＣ検証用鍵から更新対象に該当
    しないＭＡＣ検証用鍵を選択して受領したデータアップ
    デートチケット（ＤＵＴ）の検証処理を実行することを
    特徴とする請求項１５に記載のデータ処理方法。
20. 【請求項２０】前記メモリ搭載デバイスのメモリ部は、 各々が対応するパーティションマネージャによって管理
    されるメモリ領域としての１以上のパーティション領域
    を有し、 前記メモリ搭載デバイスは、 前記アクセス機器からの各パーティション内のデータに
    対するアクセス要求に対する処理を、各パーティション
    マネージャの管理下のチケット発行手段が発行し、チケ
    ット利用手段としての前記アクセス機器から前記メモリ
    搭載デバイスに対して入力されるアクセス制御チケット
    の記述に基づいて実行することを特徴とする請求項１５
    に記載のデータ処理方法。
21. 【請求項２１】前記メモリ搭載デバイスのメモリ部は、 各々が対応するパーティションマネージャによって管理
    されるメモリ領域としての１以上のパーティション領域
    を有し、 前記メモリ搭載デバイスは、 前記アクセス機器とのセッション中に実行したパーティ
    ション認証またはデバイス認証によって取得した公開鍵
    方式認証情報およびセッション鍵、または共通鍵方式認
    証情報およびセッション鍵を対応付けた認証テーブルを
    生成して、当該セッション期間、保持することを特徴と
    する請求項１５に記載のデータ処理方法。
22. 【請求項２２】データ格納可能なメモリ部を有するメモ
    リ搭載デバイスに対するアクセス機器からのアクセス要
    求に応じて、前記メモリ部に対するデータ処理をコンピ
    ュータ・システム上で実行せしめるコンピュータ・プロ
    グラムを提供するプログラム記憶媒体であって、前記コ
    ンピュータ・プログラムは、 前記メモリ部に対するデータ処理に対応して構成される
    アクセス制御チケットを前記アクセス機器から受領する
    ステップと、 前記アクセス機器からの指定または受領したアクセス制
    御チケットの記述に基づいて、前記アクセス機器との相
    互認証の方式を決定して実行するステップと、受領した
    アクセス制御チケットの記述に基づいて、アクセス制御
    チケットの検証方式を決定して実行するステップと、 相互認証およびチケット検証の双方の成立を条件として
    前記アクセス機器からのアクセス要求を実行するステッ
    プと、 を有することを特徴とするプログラム記憶媒体。