情報処理装置および方法、記録媒体、プログラム、並びに情報処理システム
【課題】安全かつ迅速に相互認証およびアクセス制御を行うことができるようにする。
【解決手段】ファイルアクセス処理部は、ステップＳ１１４において、第三のデータをルート鍵で暗号化して第四のデータを生成し、ステップＳ１１５において、第四のデータから、アクセス許諾チケットのチェック子を算出するためのアクセス許諾チケット生成鍵を作成し、ステップＳ１１６において、アクセス許諾チケットのチェック子（MAC値）を、アクセス許諾チケット生成鍵を用いて計算し、ステップＳ１１７において、生成したチェック子の値を、アクセス許諾チケットのチェック子の値と比較し、アクセス許諾チケットを検証する。本発明は、例えば、通信システムに適用することができる。
【解決手段】ファイルアクセス処理部は、ステップＳ１１４において、第三のデータをルート鍵で暗号化して第四のデータを生成し、ステップＳ１１５において、第四のデータから、アクセス許諾チケットのチェック子を算出するためのアクセス許諾チケット生成鍵を作成し、ステップＳ１１６において、アクセス許諾チケットのチェック子（MAC値）を、アクセス許諾チケット生成鍵を用いて計算し、ステップＳ１１７において、生成したチェック子の値を、アクセス許諾チケットのチェック子の値と比較し、アクセス許諾チケットを検証する。本発明は、例えば、通信システムに適用することができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置および方法、記録媒体、プログラム、並びに情報処理システムに関し、特に、安全かつ迅速に相互認証およびアクセス制御を行うことができるようにした情報処理装置および方法、記録媒体、プログラム、並びに情報処理システムに関する。
【背景技術】
【０００２】
近年、電子マネーに代表される、非接触IC（Integrated Circuit）カードが多方面で利用されるようになってきている。この非接触ICカードには、種々のアプリケーションが搭載されることが普通であり、それぞれ要求される情報セキュリティのレベルが異なっているのが普通である。そこで、必要の都度、アプリケーション毎にアクセス許諾チケットを提示してアクセス許諾を得て、そのアプリケーションに対応したファイルにアクセスする手法をとっている（例えば、特許文献１参照）。
【０００３】
【特許文献１】特開２００２−２８１０２３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来のアクセス許諾チケットにおいては、ファイルへのアクセス方法を複数種類指定することはできるものの、そのチケットが正当であるかどうかを判定するMAC（Message Authentication Code）値を計算するのに使う鍵が一つであるという問題点があった。つまり、各ファイルのアクセス方法に対して鍵を別々に設定してはいるものの、MACを計算するために使用する鍵は一つである。このため、チケットで正当性を判断しても、チェックできる鍵が一つということになり、結局はその鍵に対するファイルアクセス方法のみを判定しているに過ぎないという矛盾が残っていた。
【０００５】
本発明はこのような状況に鑑みてなされたものであり、安全かつ迅速に相互認証及びアクセス制御を行うことができるようにするものである。
【課題を解決するための手段】
【０００６】
本発明の第１の側面は、他の情報処理装置より、自分自身が保持するデータに対してアクセスを要求される情報処理装置であって、前記他の情報処理装置の認証処理を行う認証手段と、前記認証手段により正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信する受信手段と、予め保持する所定のデータ、ルートディレクトリに対応する鍵情報であるルート鍵、並びに、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成するアクセス許諾チケット生成鍵生成手段と、前記アクセス許諾チケット生成鍵生成手段により生成された前記アクセス許諾チケット生成鍵を用いて、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出するチェック子算出手段と、前記チェック子算出手段により算出された前記チェック子を用いて、前記受信手段により受信された前記アクセス許諾チケットを検証するアクセス許諾チケット検証手段とを備える情報処理装置である。
【０００７】
前記アクセス許諾チケットは、前記他の情報処理装置のIDをさらに含み、前記受信手段により受信された前記アクセス許諾チケットに記述される前記他の情報処理装置のIDが、前記認証手段により認証済みの他の情報処理装置のIDであるか否かを検証するID検証手段をさらに備えることができる。
【０００８】
所定のIDが特別なIDであるオールマイティIDとして予め設定されており、前記ID検証手段は、前記アクセス許諾チケットに前記オールマイティIDが記述されている場合、認証済みのIDの如何に関わらず、アクセス制御チケットの使用者を許諾させることができる。
【０００９】
前記アクセス許諾チケット生成鍵の生成に使用される前記所定のデータは、前記認証手段による認証処理において認証用の鍵情報の生成に用いられる所定のデータとは異なるデータとして予め保持することができる。
【００１０】
前記アクセス許諾チケットに記述されるアクセスコードが、前記認証処理においてアクセス先として認証されたディレクトリのアクセスコードであるか否かを確認する確認手段をさらに備えることができる。
【００１１】
前記確認手段により前記認証処理においてアクセス先として認証されていないディレクトリのアクセスコードが含まれることが確認された場合、アクセスを拒絶する拒絶手段をさらに備えることができる。
【００１２】
前記拒絶手段は、前記認証処理においてアクセス先として認証されていないディレクトリのアクセスコードについてのみアクセスを拒絶することができる。
【００１３】
前記アクセス許諾チケット生成鍵生成手段は、前記確認手段により前記認証処理においてアクセス先として認証されていない領域のアクセスコードが含まれることが確認された場合、前記アクセス許諾チケット生成鍵の生成において、さらに、前記アクセスコードに対応するディレクトリの鍵情報であるディレクトリ鍵を使用することができる。
【００１４】
前記アクセス許諾チケット生成鍵生成手段は、予め保持する前記所定のデータを前記ルート鍵で暗号化し、その暗号化結果をさらに各ディレクトリ鍵で１つずつ暗号化し、さらにその暗号化結果を、各アクセス制御鍵で１つずつ暗号化することにより、各鍵情報を縮退化して前記アクセス許諾チケット生成鍵を生成することができる。
【００１５】
本発明の第一の側面は、また、他の情報処理装置より、自分自身が保持するデータに対してアクセスを要求される情報処理装置の情報処理方法であって、前記他の情報処理装置の認証処理を行い、正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信し、予め保持する所定のデータ、ルートディレクトリに対応する鍵情報であるルート鍵、並びに、受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成し、生成された前記アクセス許諾チケット生成鍵を用いて、前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出し、算出された前記チェック子を用いて、前記アクセス許諾チケットを検証するステップを含む情報処理方法である。
【００１６】
本発明の第一の側面は、さらに、他の情報処理装置より、自分自身が保持するデータに対してアクセスを要求される情報処理装置を制御するプログラムであって、前記他の情報処理装置の認証処理を行い、正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信し、予め保持する所定のデータ、ルートディレクトリに対応する鍵情報であるルート鍵、並びに、受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成し、生成された前記アクセス許諾チケット生成鍵を用いて、前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出し、算出された前記チェック子を用いて、前記アクセス許諾チケットを検証するステップを含むコンピュータが読み取り可能なプログラムが記録されている記録媒体である。
【００１７】
本発明の第一の側面は、また、他の情報処理装置より、自分自身が保持するデータに対してアクセスを要求されるコンピュータに実行させるプログラムにおいて、前記他の情報処理装置の認証処理を行い、正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信し、予め保持する所定のデータ、ルートディレクトリに対応する鍵情報であるルート鍵、並びに、受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成し、生成された前記アクセス許諾チケット生成鍵を用いて、前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出し、算出された前記チェック子を用いて、前記アクセス許諾チケットを検証するステップを含む情報処理をコンピュータに実行させるプログラムである。
【００１８】
本発明の第二の側面は、第一の情報処理装置が、第二の情報処理装置が保持するデータに対してアクセスを要求する情報処理システムであって、前記第一の情報処理装置は、前記第二の情報処理装置と相互認証処理を行う第一の相互認証手段と、アクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを前記第二の情報処理装置に送信する送信手段とを備え、前記第二の情報処理装置は、前記第一の情報処理装置と相互認証処理を行う第二の相互認証手段と、前記第二の相互認証手段により正当な相手であると認証された前記第一の情報処理装置より、前記第一の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信する受信手段と、予め保持する所定のデータ、ルートディレクトリに対応する鍵情報であるルート鍵、並びに、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成するアクセス許諾チケット生成鍵生成手段と、前記アクセス許諾チケット生成鍵生成手段により生成された前記アクセス許諾チケット生成鍵を用いて、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出するチェック子算出手段と、前記チェック子算出手段により算出された前記チェック子を用いて、前記受信手段により受信された前記アクセス許諾チケットを検証するアクセス許諾チケット検証手段とを備える情報処理システムである。
【００１９】
本発明の第一の側面においては、他の情報処理装置の認証処理が行われ、正当な相手であると認証された他の情報処理装置より、他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットが受信され、予め保持する所定のデータ、ルートディレクトリに対応する鍵情報であるルート鍵、並びに、受信されたアクセス許諾チケットに記述されるアクセスコードに対応するデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵が使用されて、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵が生成され、生成されたアクセス許諾チケット生成鍵を用いて、アクセス許諾チケットに記述されるアクセスコードに対応するチェック子が算出され、算出されたチェック子を用いて、アクセス許諾チケットが検証される。
【００２０】
本発明の第二の側面においては、第一の情報処理装置において、第二の情報処理装置と相互認証処理が行われ、アクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットが第二の情報処理装置に送信され、第二の情報処理装置において、第一の情報処理装置と相互認証処理が行われ、正当な相手であると認証された第一の情報処理装置より、第一の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットが受信され、予め保持する所定のデータ、ルートディレクトリに対応する鍵情報であるルート鍵、並びに、受信されたアクセス許諾チケットに記述されるアクセスコードに対応するデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵が使用されて、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵が生成され、その生成されたアクセス許諾チケット生成鍵を用いて、アクセス許諾チケットに記述されるアクセスコードに対応するチェック子が算出され、その算出されたチェック子を用いて、アクセス許諾チケットが検証される。
【発明の効果】
【００２１】
本発明によれば、認証処理およびアクセス制御を行うことができる。特に、安全かつ迅速に相互認証およびアクセス制御を行うことができる。
【発明を実施するための最良の形態】
【００２２】
以下に本発明の実施の形態を説明するが、本発明の構成要件と、明細書または図面に記載の実施の形態との対応関係を例示すると、次のようになる。この記載は、本発明をサポートする実施の形態が、明細書または図面に記載されていることを確認するためのものである。従って、明細書または図面中には記載されているが、本発明の構成要件に対応する実施の形態として、ここには記載されていない実施の形態があったとしても、そのことは、その実施の形態が、その構成要件に対応するものではないことを意味するものではない。逆に、実施の形態が構成要件に対応するものとしてここに記載されていたとしても、そのことは、その実施の形態が、その構成要件以外の構成要件には対応しないものであることを意味するものでもない。
【００２３】
本発明の第１の側面は、他の情報処理装置（例えば、図１の情報処理端末１１）より、自分自身が保持するデータに対してアクセスを要求される情報処理装置（例えば、図１のICカード１２）であって、前記他の情報処理装置の認証処理を行う認証手段（例えば、図１の認証処理部３３）と、前記認証手段により正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信する受信手段（例えば、図２０のステップＳ１１１の処理を行う図１の通信部３８）と、予め保持する所定のデータ、ルートディレクトリに対応する鍵情報であるルート鍵、並びに、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成するアクセス許諾チケット生成鍵生成手段（例えば、図２０のステップＳ１１５の処理を行う図１のアクセス許諾チケット生成鍵生成部４２）と、前記アクセス許諾チケット生成鍵生成手段により生成された前記アクセス許諾チケット生成鍵を用いて、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出するチェック子算出手段（例えば、図２０のステップＳ１１６の処理を行う図１のファイルアクセス処理部３４）と、前記チェック子算出手段により算出された前記チェック子を用いて、前記受信手段により受信された前記アクセス許諾チケットを検証するアクセス許諾チケット検証手段（例えば、図２０のステップＳ１１７の処理を行う図１のファイルアクセス処理部３４）とを備える。
【００２４】
前記アクセス許諾チケットは、前記他の情報処理装置のIDをさらに含み、前記受信手段により受信された前記アクセス許諾チケットに記述される前記他の情報処理装置のIDが、前記認証手段により認証済みの他の情報処理装置のIDであるか否かを検証するID検証手段（例えば、図２０のステップＳ１１２の処理を行う図１のファイルアクセス処理部３４）をさらに備えることができる。
【００２５】
前記アクセス許諾チケット生成鍵の生成に使用される前記所定のデータ（例えば、図１８の第三のデータ）は、前記認証手段による認証処理において認証用の鍵情報の生成に用いられる所定のデータ（例えば、図１８の第一のデータ）とは異なるデータとして予め保持することができる。
【００２６】
前記アクセス許諾チケットに記述されるアクセスコードが、前記認証処理においてアクセス先として認証されたディレクトリのアクセスコードであるか否かを確認する確認手段（例えば、図２０のステップＳ１１３の処理を行う図１のファイルアクセス処理部３４）をさらに備えることができる。
【００２７】
本発明の第一の側面は、また、他の情報処理装置（例えば、図１の情報処理端末１１）より、自分自身が保持するデータに対してアクセスを要求される情報処理装置（例えば、図１のICカード１２）の情報処理方法、記録媒体、またはプログラムであって、前記他の情報処理装置の認証処理を行い（例えば、図１１および図１２の認証処理）、正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信し（例えば、図２０のステップＳ１１１）、予め保持する所定のデータ、ルートディレクトリに対応する鍵情報であるルート鍵、並びに、受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成し（例えば、図２０のステップＳ１１５）、生成された前記アクセス許諾チケット生成鍵を用いて、前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出し（例えば、図２０のステップＳ１１６）、算出された前記チェック子を用いて、前記アクセス許諾チケットを検証する（例えば、図２０のステップＳ１１７）ステップを含む。
【００２８】
以下、本発明の実施の形態について説明する。
【００２９】
図１は、本発明を適用した通信システムの主な構成例を示すブロック図である。
【００３０】
図１に示される通信システム１は、通信機能を有する情報処理端末１１およびIC（Integrated Circuit）カード１２の２つのデバイスよりなり、情報処理端末１１とICカード１２が互いに通信を行い、情報を授受するシステムである。情報処理端末１１は、例えば改札機や自動販売機等のような、ICカード１２のリーダ・ライタ機能を有する情報処理装置であり、ICカード１２に情報を供給して記憶させたり、ICカード１２に記憶されている情報を読み出したりする。ICカード１２は、例えば不揮発性メモリや通信回路を内蔵するICチップやループアンテナ等が埋め込まれたカード型のデバイスであり、情報処理端末１１と、通信可能範囲が約１０cm程度の近距離無線通信を行い、情報の授受を行う、所謂、非接触型のICカードである。
【００３１】
図１に示されるように、情報処理端末１１は、記憶部２１、認証処理部２３、ファイルアクセス処理部２４、乱数生成部２５、暗号化部２６、復号部２７、および通信部２８の機能ブロックを有する。記憶部２１は、例えばフラッシュメモリやハードディスク等の不揮発性のメモリデバイスよりなり、IDや暗号化用の鍵情報等各種情報を記憶する。認証処理部２３は、例えばCPU（Central Processing Unit）等の演算処理デバイスよりなり、情報処理端末１１とICカード１２との通信を開始する際に互いを認証させる認証処理を行う。ファイルアクセス処理部２４は、例えばCPU等の演算処理デバイスよりなり、相互認証を行ったICカード１２に対して、ファイルへのアクセス許諾を求める処理を行う。乱数生成部２５は、例えばCPU等の演算処理デバイスよりなり、認証処理等に必要な乱数を生成する。暗号化部２６は、例えばCPU等の演算処理デバイスよりなり、通信部２８を介してICカード１２に供給する情報を必要に応じて暗号化する。復号部２７は、例えばCPU等の演算処理デバイスよりなり、通信部２８を介してICカード１２より供給された、暗号化された情報を必要に応じて復号する。通信部２８は、例えば、通信回路等を含むICチップやループアンテナ等よりなり、通信可能範囲内に位置するICカード１２との近距離無線通信を行い、情報を授受する。もちろん、情報処理端末１１がこれら以外の機能ブロックを有していてもよい。
【００３２】
なお、図１においては矢印の記載を省略しているが、認証処理部２３およびファイルアクセス処理部２４は、乱数生成部２５、暗号化部２６、および復号部２７とも情報の授受を適宜行う。
【００３３】
ICカード１２は、記憶部３１、データ設定処理部３２、認証処理部３３、ファイルアクセス処理部３４、乱数生成部３５、暗号化部３６、復号部３７、および通信部３８の機能ブロックを有する。記憶部３１は、例えばフラッシュメモリやハードディスク等の不揮発性のメモリデバイスよりなり、情報処理端末１１等外部の機器より供給される情報等、各種情報を記憶する。データ設定処理部３２は、例えばCPU等の演算処理デバイスよりなり、ICカード１２の外部の機器より供給される命令や情報等に基づいて、記憶部３１の記憶領域にディレクトリやファイルを作成したり、鍵情報やID等の設定情報を書き込んだりするデータ設定処理を行う。認証処理部３３は、例えばCPU等の演算処理デバイスよりなり、情報処理端末１１とICカード１２との通信を開始する際に互いを認証させる認証処理を行う。認証処理部３３は、情報処理端末１１固有の鍵を生成する情報処理端末１１用のマスタ鍵を生成するマスタ鍵生成部４１を有する。ファイルアクセス処理部３４は、例えばCPU等の演算処理デバイスよりなり、情報処理端末１１による記憶部３１に書き込まれているファイルへのアクセスの制御に関する処理を行う。ファイルアクセス処理部３４は、情報処理端末１１より供給されるアクセス許諾チケットの検証を行うために、そのアクセス許諾チケットと同様の情報を作成可能な鍵情報であるアクセス許諾チケット生成鍵を生成するアクセス許諾チケット生成鍵生成部４２を有する。乱数生成部３５は、例えばCPU等の演算処理デバイスよりなり、認証処理等に必要な乱数を生成する。暗号化部３６は、例えばCPU等の演算処理デバイスよりなり、通信部３８を介して情報処理端末１１に供給する情報を必要に応じて暗号化する。復号部３７は、例えばCPU等の演算処理デバイスよりなり、通信部３８を介して情報処理端末１１より供給された、暗号化された情報を必要に応じて復号する。通信部３８は、例えば、通信回路等を含むICチップやループアンテナ等よりなり、通信可能範囲内に位置する情報処理端末１１との近距離無線通信を行い、情報を授受する。もちろん、ICカード１２がこれら以外の機能ブロックを有していてもよい。
【００３４】
なお、図１においては矢印の記載を省略しているが、データ設定処理部３２、認証処理部３３、およびファイルアクセス処理部３４は、それぞれ、乱数生成部３５、暗号化部３６、および復号部３７とも情報の授受を適宜行う。
【００３５】
以上の通信システム１に関わる存在（エンティティ）について説明する。以下においては、ICカード１２をユーザに提供する（あるいは販売し、管理する）エンティティをシステム管理者と称し、そのシステム管理者の許諾を得て、ICカード１２の記憶部３１の記憶領域の中にディレクトリを生成し、サービスを提供するエンティティを事業者と称する。当然、システム管理者も一事業者となり得る。
【００３６】
システム管理者は、ICカード１２に第一のデータと、ルートディレクトリを管理する鍵情報であるルート鍵を書き込み、ユーザにICカード１２を提供する。従って、同一のシステム管理者配下のICカード１２の記憶部３１には、全て同じ第一のデータおよびルート鍵が書かれている。換言するに、互いに異なるシステム管理者のICカードには、互いに異なる第一のデータおよびルート鍵がそれぞれ記憶される。
【００３７】
次に、情報処理端末１１およびICカード１２の間で行われる相互認証について説明する。図２は、情報処理端末１１の記憶部２１、および、ICカード１２の記憶部３１に記憶される、相互認証処理に関する情報の例を示す図である。
【００３８】
図２に示される例においては、通信システム１は、３台の情報処理端末１１と２枚のICカード１２により構成される。通信システム１を提供するシステム管理者（企業や団体等も含む）は１人（１社または１団体等）存在し（つまり、唯一のシステム管理者が存在し）、通信システム１を用いたサービスを提供する事業者（企業や団体等も含む）は２人（２社または２団体）存在し（つまり、２単位の事業者が存在し）、通信システム１を用いたサービスを享受するユーザは２人（２社または２団体）存在する（つまり、２単位のユーザが存在する）。事業者１は、情報処理端末１１−１−１および情報処理端末１１−１−２を所有し、事業者２は、情報処理端末１１−２−１を所有する。ICカード１２−１は、図示せぬ一方のユーザにより所有され、ICカード１２−２は、図示せぬ他方のユーザにより所有される。なお、情報処理端末１１−１−１、情報処理端末１１−１−２、および情報処理端末１１−２−１を互いに区別して説明する必要の無い場合、単に情報処理端末１１と称する。同様に、ICカード１２−１およびICカード１２−２を互いに区別して説明する必要の無い場合、単にICカード１２と称する。
【００３９】
システム管理者は、例えば出荷時に、ICカード１２−１の記憶部３１−１に第一のデータ（KSystem）とルート鍵（KRoot）を書き込む。同様に、システム管理者は、例えば出荷時に、ICカード１２−２の記憶部３１−２に第一のデータ（KSystem）とルート鍵（KRoot）を書き込む。
【００４０】
事業者１は、システム管理者の許諾を得てICカード１２−１の記憶部３１−１に、提供するサービス毎にディレクトリ（ディレクトリ１−１、ディレクトリ１−２、ディレクトリ１−３、およびディレクトリ１−３−２）を作成する。なお、本例ではディレクトリ１−３にはアクセスしないこととする。また、ディレクトリ１−３−２はディレクトリ１−３の下にある下位ディレクトリである（つまり、ルート直下ではない）。
【００４１】
同様に、事業者２は、システム管理者の許諾を得てICカード１２−２の記憶部３１−２に、提供するサービス毎にディレクトリ（ディレクトリ２−１、ディレクトリ２−２、ディレクトリ２−３、およびディレクトリ２−３−２）を作成する。なお、本例ではディレクトリ２−３にはアクセスしないこととする。また、ディレクトリ２−３−２はディレクトリ２−３の下にある下位ディレクトリである（つまり、ルート直下ではない）。
【００４２】
ディレクトリを作成する際、事業者は、そのサービスのディレクトリを管理する、サービス毎の鍵情報であるディレクトリ鍵（DirK）、そのICカード１２のそのディレクトリを識別するためのアプリケーションID（AppID）と、そのICカード１２のそのディレクトリを管理する鍵情報であるアプリケーション鍵（AppK）を、そのディレクトリに書き込む。
【００４３】
例えば、事業者１は、ディレクトリ１−１を作成すると、そのディレクトリ１−１に、ディレクトリ鍵（DirK１−１）、アプリケーションID（AppID１−１）、およびアプリケーション鍵（AppK１−１）を書き込む。同様に、事業者１は、ディレクトリ１−２を作成すると、そのディレクトリ１−２に、ディレクトリ鍵（DirK１−２）、アプリケーションID（AppID１−２）、およびアプリケーション鍵（AppK１−２）を書き込む。
【００４４】
同様に、事業者２は、ディレクトリ２−１を作成すると、そのディレクトリ２−１に、ディレクトリ鍵（DirK２−１）、アプリケーションID（AppID２−１）、およびアプリケーション鍵（AppK２−１）を書き込む。同様に、事業者２は、ディレクトリ２−２を作成すると、そのディレクトリ２−２に、ディレクトリ鍵（DirK２−２）、アプリケーションID（AppID２−２）、およびアプリケーション鍵（AppK２−２）を書き込む。
【００４５】
ディレクトリ鍵DirKの場合、書き込み先のICカード１２が異なっていても（つまり、異なるユーザが持つカードという意味）（例えば、ICカード１２−１の場合も、ICカード１２−２の場合も）、提供されるサービスが同一のディレクトリであれば、互いに同一の鍵が書き込まれる。これに対して、アプリケーションID（AppID）やアプリケーション鍵（AppK）の場合、サービスが同一のディレクトリであってもICカードが異なれば値が異なる。
【００４６】
また、例えば、ディレクトリ１−１のアプリケーション鍵AppK１−１は、情報処理端末１１−１−１の記憶部２１−１−１に保持されているマスタ鍵MK１−ICとアプリケーションID（AppID１−１）から生成できるものとする。つまり、ここには図示されていないが、事業者１が他のICカード１２（つまり、異なるユーザが持つカードという意味）に生成するディレクトリには、異なるアプリケーションID（AppID）（これがユーザIDとなる）とアプリケーション鍵（AppK）が書き込まれる。ただし、ディレクトリ鍵（DirK）は共通である。
【００４７】
同様に、事業者２によって各ディレクトリにディレクトリ鍵（DirK）、アプリケーションID（AppID）、およびアプリケーション鍵（AppK）が書き込まれる。
【００４８】
情報処理端末１１−１−１の記憶部２１−１−１には、情報処理端末１１−１−１固有の識別情報（ID１−１）、情報処理端末１１−１−１固有の鍵（K１−１）、ICカード１２−１の記憶部３１−１に記憶されるアプリケーション鍵（AppK）を生成するためのマスタ鍵（MK１−IC）が書き込まれている。この鍵は、事業者毎に異なるだけであるため、同一事業者内では同じ鍵となる。なお、マスタ鍵をディレクトリ毎に変えるようにしても良い（本例では、事業者につき固有としている）。その場合、アクセスするディレクトリ分のマスタ鍵を保持している必要がある。
【００４９】
同様に、情報処理端末１１−１−２の記憶部２１−１−２には、情報処理端末１１−１−２固有の識別情報（ID１−２）、情報処理端末１１−１−２固有の鍵（K１−２）、ICカード１２−１の記憶部（３１−１）に記憶されるアプリケーション鍵（AppK）を生成するためのマスタ鍵（MK１−IC）が書き込まれている。同様に、情報処理端末１１−２−１の記憶部２１−２−１には、情報処理端末１１−２−１固有の識別情報（ID２−１）、情報処理端末１１−２−１固有の鍵（K２−１）、ICカード１２−２の記憶部３１−２に記憶されるアプリケーション鍵（AppK）を生成するためのマスタ鍵（MK２−IC）が書き込まれている。
【００５０】
次に、ICカード１２の記憶部３１内に記憶されるデータの具体的な構成例を説明する。
【００５１】
図３は、記憶部３１の記憶領域内に書き込まれる情報の構成例（アドレスマップ）を示す図である。
【００５２】
図３において、まず、１ブロックのバイト数であるが、鍵長が１６バイト以上になることに伴い、３２バイトを想定している。もちろん、鍵長を８バイトとして、１ブロックを１６バイトとしてもよいし、１ブロックを６４バイトとしてもよい。記憶部３１には、鍵データ等のシステムデータが、メモリの上位アドレスから書き込まれる。逆に、ユーザデータは下位アドレスから書き込まれる。結果として、記憶部３１の中央領域が常に空き領域となるようになる。これらのデータを保持するICチップ（記憶部３１を含むICチップ）を、以降セキュリティICと呼称する。
【００５３】
記憶部３１の論理アドレスFFFFhのブロック（３２バイト）には、デバイスID（Device ID）と、デバイスパラメータ（Device Parameter）が記憶される。デバイスID（Device ID）は、デバイス固有のID、すなわちICカード１２のIDを示す。このデータは、ICベンダーによって書き込まれるか、システム管理者によって書き込まれる。このデータは、所定の手続きを取らない限り読み出すことができないようになされており、通常のアプリケーションでは使用することができない。これにより、プライバシー等の侵害を防ぐことが期待される。また、デバイスパラメータ（Device Parameter）は、返答時間など、種々のパラメータを規定する。
【００５４】
各ブロックの先頭の２バイト（FF FFhとFF FEh）は、それぞれ、ブロック種別を規定するデータである。この先頭の２バイトがFF FFhまたはFF FEhで始まるシステムブロック（論理アドレスFFFEhおよび論理アドレスFFFDhの２ブロック）は、システム管理者によって記憶部３１に最初に割り当てられ、システム全体を管理する鍵情報であるシステム鍵（System Key）の情報を格納している。このシステム鍵（System Key）はシステムデータ（System Data）を生成するための元になるデータである認証鍵用（System Key for Authentication）（後述する第一のデータ）とアクセス許諾チケット生成鍵用（System Key for Access Control Ticket）（後述する第三のデータ）の２つが設けられる。なお、このシステム鍵は、いずれか一方のみを設定し、その一方を用いて所定のロジックによって他方が生成されるようにしてもよいし、両者を同一としても良い。
【００５５】
この２ブロックに含まれるキーフォーマット（Key Format）は、システム鍵（System Key）を暗号鍵として使用する場合の共通鍵暗号アルゴリズム／鍵長を規定するものであり、システム鍵（System Key）をデータとして使用する場合には適応しない。また、キーバージョン（Key Version）は、そのブロックのシステム鍵（System Key）のバージョン情報を示す。
【００５６】
先頭の２バイトが00 00hで始まるシステムブロックは、ルートディレクトリ（Root Directory）の情報を格納している。３バイト目乃至６バイト目（00 00 00 00h）は、ルートディレクトリ（Root Directory）のディレクトリコード（Directory Code）（Directoryの名前）を示している。スタートアドレス（Start Address）は、通常00 00hから始まり、エンドアドレス（End Address）は、システムブロックの１つ手前を表す。なお、このアドレスは物理アドレスではなく、論理ブロック番号に該当する。トータルブロック数（Total Block）は、スタートアドレス（Start Address）とエンドアドレス（End Address）から計算できるため必要性はないが、メモリ上は確保しておく。キーフォーマット（Key Format）は、使用される共通鍵暗号アルゴリズム／鍵長を規定するもので、他の領域に保存されている共通鍵全てに適応する。キーバージョン（Key Version）は、ルート鍵（Root Directory Symmetric Key）の鍵のバージョンを示す。
【００５７】
先頭の２バイトが00 01hで始まるシステムブロックは、下位にサブディレクトリ（Sub-Directory）を構成することが可能なディレクトリ（Directory）に関する情報を格納し、先頭の２バイトが00 02hで始まるシステムブロックは、下位にサブディレクトリ（Sub-Directory）を構成することが不可能なディレクトリ（Directory）に関する情報を格納する。これらのシステムブロックのディレクトリコード（Directory Code）は、このディレクトリ（Directory）の名前を示し、他のコード（Code）と異なっている必要がある。ただし、このコード（Code）に値「FF FF FF FFh」および「00 00 00 00h」は使用することができないようになされている。また、これらのシステムブロックのスタートアドレス（Start Address）とエンドアドレス（End Address）は、上述したルートディレクトリ（Root Directory）に関するシステムブロックの場合と同様である。２回目に出てくるディレクトリコード（Directory Code）は、親ディレクトリのディレクトリコード（Directory Code）を示す。通常は、ルートディレクトリ（Root Directory）に属するため、このディレクトリコードには「00 00 00 00h」が書き込まれるが、それより下段のディレクトリでは、親ディレクトリのディレクトリコードが記述される。また、これらのシステムブロックのキーバージョン（Key Version）は、上述したルートディレクトリ（Root Directory）に関するシステムブロックの場合と同様である。先頭の２バイトが00 01hで始まるシステムブロックのディレクトリ鍵（Directory Symmetric Key with Sub-Directory）は、下位にサブディレクトリ（Sub-Directory）を構成することが可能なディレクトリ（Directory）のディレクトリ鍵のことである。また、先頭の２バイトが00 02hで始まるシステムブロックのディレクトリ鍵（Directory Symmetric Key without Sub-Directory）は、下位にサブディレクトリ（Sub-Directory）を構成することが不可能なディレクトリ（Directory）のディレクトリ鍵のことである。
【００５８】
先頭の２バイトが00 FFhで始まるシステムブロックは、ディレクトリ（Directory）に対するアプリケーション情報（Application Information）を示している。このシステムブロックのアプリケーションID（Application ID）は、そのディレクトリ（Directory）を管理する事業者がICカード１２に割り振った識別情報（ID）を示し、アプリケーション鍵（Application Symmetric Key）は、アプリケーションID（Application ID）とマスタ鍵（Master Application Key）とから算出される鍵を示す。またディレクトリコード（Directory Code）は、このアプリケーション情報（Application Information）に対応するディレクトリコード（Directory Code）を示す。
【００５９】
先頭の２バイト（ブロック種別）が01 00h乃至FE FFhの場合、それらの値はアクセスモード（Access Mode）、すなわち、ファイル（File）へのアクセス方法を示している。このブロックのアクセスコード（Access Code）はファイル（File）の名前を示している。ただし、他のコード（Code）と値が異なっている必要がある。また、このブロックのスタートアドレス（Start Address）とエンドアドレス（End Address）は、上述したルートディレクトリ（Root Directory）に関するシステムブロックの場合と同様である。このブロックのディレクトリコード（Directory Code）は、アクセス対象のファイル（File）が所属するディレクトリ（Directory）の名前を示す。さらに、このブロックのキーバージョン（Key Version）の値が「FF FFh」以外である場合、アクセス制御のための鍵であるアクセス制御鍵（Access Control Symmetric Key）が有効である。これに対して、キーバージョン（Key Version）の値が「FF FFh」である場合、このブロックの鍵情報、すなわちアクセス制御鍵（Access Control Symmetric Key）が無効である。つまり、キーバージョン（Key Version）の値が「FF FFh」であることは、暗号処理機能を使用しないことを示す。
【００６０】
なお、先頭の２バイトが00 FEhで始まるシステムブロックを、リボケーションリスト（Revocation List）とすることができる。この時、通常は鍵が書かれている領域にリボーク（Revoke）される情報処理端末のIDを記載する。
【００６１】
次に、このようなセキュリティIC内部のデータ（記憶部３１に書き込まれるデータ）の設定方法を規定する。このデータ設定を行うデータ設定処理の流れの例を図４のフローチャートを参照して説明する。必要に応じて図５および図６を参照して説明する。
【００６２】
ステップＳ１において、データ設定処理部３２は、チップベンダ（ICカード１２を作成する製品製造メーカを含む）より指示を受けると、記憶部３１の記憶領域を初期化する。つまり、チップ製造直後、チップベンダは、ICカード１２以外のデバイス（例えば、セキュリティIC検査装置など）を用いて全てのメモリデータをFFhに初期化するようセキュリティICに要求する。その後、このセキュリティICを組み込んだICカードを製造する。
【００６３】
ステップＳ２において、データ設定処理部３２は、チップベンダの指示（特別なコマンド）に基づいて、ICカード１２の外部の装置より供給されるデバイスIDおよびパラメータを記憶部３１に書き込む。なお、デバイスIDおよびパラメータの書き込みは、記憶部３１の全てのメモリエリアがFFh（もしくは、デバイスID（Device ID）およびパラメータ（Device Parameter）の領域のみがFFh）である場合のみ可能である。なお、この時点では値の読み出し（特別なコマンド）は自由に行えるようにしておく。また、何度でも変更ができるようにしておく。さらに、変更する場合には、上記書き込みシーケンスと同様のものを用い、それによって、以前のデータは消去され、上書きされるものとする。また、もしデバイスID（Device ID）およびパラメータ（Device Parameter）の領域のみがFFhであった場合、データ設定処理部３２は、ここで他の領域をFFhに初期化する。
【００６４】
ステップＳ３において、データ設定処理部３２は、システム管理者の指示に基づいてICカード１２の外部の装置より供給されるシステム鍵を記憶部３１に書き込む。なお、システム管理者がシステム管理者固有のシステム鍵（System Key）を書き込むために、チップベンダは、出荷時に仮のシステム鍵を記憶部３１に書き込む。このシステム鍵の書き込みは、デバイスID（Device ID）とパラメータ（Device Parameter）が書き込まれていることが条件となっている。また、通常の場合、システム鍵（System Key）の書き込みは一度しか行えず、書き替えるためには所定の変更手順に従って行う必要がある。ただし、その場合も、システム鍵（System Key）を書き替えるためには、デバイスID（Device ID）、パラメータ（Device Parameter）が書き込まれていること、およびシステム鍵（System Key）領域以外のデータが初期化されている（FFｈになっている）ことが条件となる。また、この更新に使う、古いシステム鍵の暗号方式は、メモリに書き込まれているキーフォーマット（Key Format）に従う。キーフォーマット（Key Format）には、暗号アルゴリズムや鍵ビット長の他に、例えば、所定の値をExor（排他的論理和）してから暗号化する、所定回数の暗号化を繰り返す、１回だけ暗号化する等といった暗号方法が記述されている。
【００６５】
これ以降の書き込み処理が進んだ状態においては、システム鍵（System Key）の変更は一切できないようになされている。実際の書き込み方法は、外部から所定のフォーマットに従ったデータをセキュリティICに送り込み、それに基づいてシステム鍵（System Key）、システムコード（System Code）、キーフォーマット（Key Format）、およびキーバージョン（Key Version）を書き込ませる。書き込みシーケンスは、上述したデバイスIDおよびパラメータの場合と同様であるが、適宜最適な方法を設定して良い。なお、このときの送信データは暗号化されていない。
【００６６】
ステップＳ４において、データ設定処理部３２は、システム管理者の指示に基づいて、ICカード１２の外部の装置より供給されるルート鍵を記憶部３１に書き込む。なお、このルート鍵（Root Key）の書き込みは、システム鍵（System Key）が書き込まれている場合のみ可能である。これは、ルート鍵（Root Key）の初期書き込みには、システム鍵（System Key）が使用されるからである。実際の書き込み方法は、ICカード１２の外部の装置から所定のフォーマットに従ったデータをICカード１２のセキュリティICに送り込み、それに基づいてルート鍵（Root Key）を書き込ませる。コマンドは上述した他のステップの場合と同じであるが、図５に示されるように、コマンドに含まれるデータ列５１は、システム鍵（System Key）で暗号化したルート鍵（Root Key）を含む。暗号化方法は、システム鍵（System Key）のキーフォーマット（Key Format）に従うものとする。なお、ルート鍵（Root Key）を更新する場合には、更新される前のルート鍵（Root Key）だけが必要となる。つまり、ルート鍵（Root Key）の更新時にはシステム鍵（System Key）は（鍵としては）使用されない。
【００６７】
ここまでの処理は、システム管理者またはチップベンダ等が指示することになっていることと、ここまで処理が進まない間は、これを組み込んだ製品そのものが動作しないことから、比較的安全なところで処理が行えることが期待できる（仮に、ルート鍵（Root Key）を未実装で製品に組み込む場合も、その後、安全な場所でルート鍵（Root Key）の書き込みを確実に行うことができるものとする）。このため、鍵の書き込みメカニズムは比較的簡易にしてある。
【００６８】
ステップＳ５において、ディレクトリを作成したい事業者は、システム管理者に依頼してディレクトリ生成チケットを作成してもらう。このディレクトリ生成チケットには、ディレクトリ情報及びアプリケーション情報を設定するのに必要なデータをルート鍵で暗号化したものと、システム鍵（System Key）を用いて生成されたICV（Integrity Check Value）が含まれている。このようになされる理由は、この時点では相互認証ができないことと、システム管理者の許諾なく、ルート直下にディレクトリを作成させないためである。なお、キーバージョン（Key Version）は00 00hとされ、ディレクトリ鍵（DirectoryKey）、アプリケーションID（Application ID）及びアプリケーション鍵（Application Key）は固定データとなる。必要に応じてステップＳ７で事業者が書き換えるものとする。
【００６９】
ステップＳ６において、サービスを提供したい事業者は、ステップＳ５でシステム管理者が生成したディレクトリ生成チケットを受領し、このディレクトリ生成チケットをデータ設定処理部３２に送ってディレクトリを仮作成する。これにより、自身のサービスを提供するためのディレクトリがICカード１２に仮作成される。
【００７０】
データ設定処理部３２は、受領したディレクトリ生成チケットのICVをシステム鍵で検証し、ICVが正当か否かを判定する。正当でないと判定された場合には、ディレクトリの生成は行われない。ICVが正当と判断された場合、ディレクトリ生成チケットに書かれているディレクトリ情報及びアプリケーション情報をルート鍵で復号化し、これらのデータを記憶部３１に書き込む。
【００７１】
ステップＳ７において、サービスを提供したい事業者は、仮作成されたディレクトリの内、必要な情報（ディレクトリ鍵（DirectoryKey）、アプリケーションID（Application ID）及びアプリケーション鍵（Application Key））を書き換える処理を行う。
【００７２】
このために、まず、情報処理端末１１とICカード１２間で相互認証を行う。相互認証の方法に関しては後述する。相互認証が終了した後、情報処理端末１１からICカード１２に対し、ディレクトリ鍵（Directory Key）変更コマンドを送信する。ディレクトリ鍵（Directory Key）変更コマンドには、付随データとして、新しい鍵のキーバージョン（Key Version）と、古いディレクトリ鍵（Directory Key）で暗号化された、新しいディレクトリ鍵（Directory Key）が含まれている。これを受信したICカード１２は、変更するディレクトリのディレクトリ鍵（Directory Key）を読み出し、この鍵でコマンドに添付されてきたデータを復号化する。そして、得られた新しいディレクトリ鍵（Directory Key）で古いディレクトリ鍵（Directory Key）を書き換え、キーバージョン（Key Version）を更新する。
【００７３】
同様に、情報処理端末１１とICカード１２間で相互認証を行い、相互認証が終了した後、情報処理端末１１からICカード１２に対し、アプリケーション情報変更コマンドを送信する。アプリケーション情報変更コマンドには、付随データとして新しい鍵のキーバージョン（Key Version）、アプリケーションID（Application ID）及びアプリケーション鍵（Application Key）が含まれている。ただし、アプリケーションID（Application ID）は、情報処理端末１１で新たに割り振ることとし、このIDとアプリケーション鍵（Application Key）を生成するためのマスタ鍵とからアプリケーションID（Application ID）に対応するアプリケーション鍵（Application Key）を生成することとする。
【００７４】
次に、これを受信したICカード１２は、受信したアプリケーションID（Application ID）及びアプリケーション鍵（Application Key）を書き換え、キーバージョン（Key Version）を更新する。
【００７５】
なお、通常、この情報処理端末１１は鍵変更処理専門の端末であり、複数のICカードの鍵を変更し、これらの情報を管理している。従って、この情報処理端末１１は、アプリケーションID（Application ID）を系統的に割り振って管理することが可能である。
【００７６】
また、アプリケーション情報変更処理時に別途相互認証すると説明したが、上記ディレクトリ鍵（Directory Key）変更処理に引き続き行う場合には不要である。
【００７７】
一方、後述するように、相互認証を終了した情報処理端末１１とICカード１２は、以降の通信路をセッション鍵で暗号化して秘匿化することができ、かつメッセージを改ざん防止できるよう整合性チェックを行っている。このため、更新するための新しいディレクトリ鍵を情報処理端末１１内部に保持していても、通信路上で漏洩する心配はない。しかし、情報処理端末１１が安全に管理される保証はないため、念のため古いディレクトリ鍵で更新する新しいディレクトリ鍵を暗号化しておくこととする。一方で、新しいアプリケーション鍵は古いアプリケーション鍵で暗号化しておくことはしていない。これは、情報処理端末１１にアプリケーション鍵を生成するためのマスタ鍵が記憶されており、鍵更新時にアプリケーション鍵の生成を行っていることと（あらかじめ古いアプリケーション鍵で暗号化しておくことができない）、仮に情報処理端末１１が安全に管理されなかった場合、このマスタ鍵が漏洩することになり、そこまで対策しても効果が薄いからである。
【００７８】
また、事業者は、上位ディレクトリ（Directory）が生成されている場合、ルートディレクトリ直下でなくても、その上位ディレクトリの下に新規サブディレクトリ（Sub-Directory）を生成することができる。この時、サブディレクトリ（Sub-Directory）のディレクトリ鍵（Directory Key）とアプリケーションID（Application ID）、およびアプリケーション鍵（Application Key）も書き込まれる。実際の書き込み方法は、システム鍵（System Key）、ルート鍵（Root Key）、および上位のディレクトリのディレクトリ鍵（Directory Key）、上位のディレクトリのアプリケーション鍵（Application Key）で相互認証を行い、所定のフォーマットに従ったデータをセキュリティICに送り込んで行う。サブディレクトリのディレクトリ鍵（Sub-Directory Key）は、上位のディレクトリのディレクトリ鍵（Dirctory Key）で暗号化されているため、比較的安全である。サブディレクトリのアプリケーションID（Application ID）とアプリケーション鍵（Application Key）は、予め設定しておくことが困難であるため、事前に上位ディレクトリのディレクトリ鍵（Directory Key）で暗号化しておくことができない。そのため、セッション鍵で保護するものとする。
【００７９】
なお、本例ではサブディレクトリ生成のための所定フォーマットコマンドを使用するとしたが、必要に応じてサブディレクトリ生成のためのアクセス許諾チケットを定義し、それを用いて行うようにしても良い。ただし、アクセス許諾チケットは事前生成が前提にもかかわらず、アプリケーション鍵が事前に生成することは難しく、所定のフォーマットコマンドを使用する方法の方が容易に実現可能である。
【００８０】
所定のフォーマットコマンドを使用する場合、相互認証後、アプリケーションIDを生成し、マスタ鍵でアプリケーション鍵を生成し、上位ディレクトリの鍵で暗号化されたサブディレクトリのディレクトリ鍵とアプリケーションID、アプリケーション鍵、その他必要な情報（バージョン等）をセッション鍵で秘匿化してICカードに送るようにする。
【００８１】
これに対して、アクセスチケットを使用する場合、予めアプリケーションIDを生成しておき、それに対するアプリケーション鍵もマスタ鍵から作っておく。これら一連のデータとサブディレクトリのディレクトリ鍵を上位ディレクトリのディレクトリ鍵で暗号化し、これを包含したアクセス許諾チケットを作るようにする。ただし、アクセス許諾チケットに付けるICVを生成する鍵を何にするか、検討する必要がある。通常は、アクセス制御鍵を使うのだが、ディレクトリにはその鍵はない（ファイルに対して作られているため）。そのため、暫定的にICVも上位ディレクトリのディレクトリ鍵で生成する方法が考えられる。
【００８２】
ステップＳ８において、データ設定処理部３２は、事業者の指示に基づいて、ディレクトリ内にファイル（File）を作成する。ディレクトリが作成されていれば、事業者は、ファイルアクセス方法を規定し、それに対応するデータをファイルとして記憶部３１に書き込ませることができる。実際のファイル生成方法は、事業者が、システム鍵（System Key）、ルート鍵（Root Key）、ディレクトリ鍵（Directory Key）、およびアプリケーション鍵（Application Key）を用いて相互認証を行い、所定のフォーマットに従ったデータをセキュリティICに送り込んで行う。なお、アクセス制御鍵はディレクトリ鍵で暗号化されているため、比較的安全である。また、ディレクトリ鍵で暗号化されたアクセス制御鍵を含む、システムブロック情報（アクセスモード、アクセスコード、スタート・エンドアドレス、ディレクトリコード等）は、セッション鍵で暗号化されて送り込まれる。
【００８３】
なお、サブディレクトリの生成時と同様に、必要に応じてファイル生成のためのアクセス許諾チケットを定義し、それを用いて行うようにしても良い。
【００８４】
ステップＳ９において、データ設定処理部３２は、事業者の指示に基づいて、アクセス制御鍵を書き込む。ステップＳ８で説明したように、アクセス制御鍵（Access Control Key）は、生成されるファイルが所属するディレクトリのディレクトリ鍵（Directory Key）で暗号化しておくものとする。
【００８５】
以上のようにして、例えば、図２に示されるように、記憶部３１内に各種データが書き込まれる。
【００８６】
次に、記憶部３１に記憶される上述した各種情報の更新方法（変更方法）について説明する。
【００８７】
システム鍵（System Key）を変更するためには、デバイスID（Device ID）、パラメータ（Device Parameter）、およびシステム鍵（System Key）領域以外が書き込まれていない必要がある。実際には、この、所定の領域以外書き込まれていない状態で、ICカード１２の外部の機器から、所定のフォーマットに従ったデータがセキュリティICに送り込まれ、それに基づいてシステム鍵（System Key）が変更される。このときのコマンドは鍵変更コマンドとして定義される。また、図７に示されるように、そのコマンドに含まれるデータ列５３には、新しいシステム鍵（System Key）を古いシステム鍵（System Key）で暗号化したものが含まれる。古いシステム鍵（System Key）の暗号方式は、ICカード１２のメモリ内に書き込まれているシステム鍵（System Key）のキーフォーマット（Key Format）に従って使用される。なお、鍵変更コマンドに添付されるデータには、新しいシステム鍵だけでなく、新しいシステム鍵の鍵フォーマット（Key Format）や鍵バージョン（Key Version）が含まれる。以降、全ての鍵更新コマンドにおいて同様である。
【００８８】
ルート鍵（Root Key）を変更するためには、ルート鍵（Root Key）が書き込まれている必要がある。Root Keyが書き込まれている条件で、この鍵が変更できる。実際には、この状態でICカード１２の外部の機器から、所定のフォーマットに従ったデータがセキュリティICに送り込まれ、それに基づいてルート鍵（Root Key）が変更される。このときコマンドは鍵変更コマンドとして定義される。また、そのコマンドに含まれるデータ列には、例えば、図８Ａに示されるように、新しいルート鍵（Root Key）５４Ａを古いルート鍵（Root Key）５４Ｂで暗号化した第一のデータと、図８Ｂに示されるように、システム鍵（System Key）５４Ｃを古いルート鍵（Root Key）５４Ｂで暗号化し、それをさらに再度新しいルート鍵（Root Key）５４Ａで暗号化した第二のデータが含まれる。古いルート鍵（Root Key）の暗号方式は、ICカード１２のメモリ内に書き込まれているルート鍵（Root Key）のキーフォーマット（Key Format）に従って使用される。新しいルート鍵の暗号方式は、鍵更新コマンドに添付されている新しいルート鍵のキーフォーマット（Key Format）に従って使用される。なお、鍵変更コマンドに添付されるデータには、新しいルート鍵だけではなく、新しいルート鍵の新しい鍵の（Key Format）や鍵バージョン（Key Version）が含まれるものの、ディレクトリコード（Directory Code）である「00 00 00 00h」、開始アドレス、終了アドレス、およびトータルのブロック数などは、変更されることが想定されていないため、含まれていなくてもよい。ただし、これらのデータを含めるようにしてもいっこうに差し支えない。
【００８９】
ところで、なぜ２つの暗号化されたデータを使用するかというと、ルート鍵（Root Key）の変更には相互認証が使えないこと、および、アクセス許諾チケットが使えないことが理由である。そのため、悪意の第三者が、リーダライタ等を用いて適当なデータを「新しいルート鍵（Root Key）を古いルート鍵（Root Key）で暗号化したもの」としてICカードに送り込んでしまうと、ICカードはデータが正しいか否かを判断できず、不正な鍵に変更してしまうというリスクがある。そこで、システム鍵（System Key）を古いルート鍵（Root Key）（これはシステム管理者等が知っている）で暗号化し、その結果を更に新しいルート鍵（Root Key）（これもシステム管理者等は知っている）で暗号化し、このデータも付加するようにした。セキュリティICでは、第一のデータを古いルート鍵（Root Key）で復号して新しいルート鍵（Root Key）を取得し、この鍵で第二のデータを復号し、その出力を再度古いルート鍵（Root Key）で復号化する。その結果がシステム鍵（System Key）に一致していた場合に、正しいシステム管理者が処理していると判定して鍵の変更を行うようにする。
【００９０】
また、ディレクトリ鍵（Directory Key）の変更は、ディレクトリが生成されていれば可能である。実際には、この状態で認証鍵（System Key、Root Key、Directory Key、Application Keyを使用）の生成を行い、必要なデータをセキュリティICに送り込んで行う。コマンドはディレクトリ鍵変更コマンドとして定義され、図９に示されるように、コマンドに含まれるデータ列５５には、新しいディレクトリ鍵（Directory Key）を古いディレクトリ鍵（Directory Key）で暗号化したものが含まれる。また、必要に応じて、ここに新しい鍵のキーバージョン（Key Version）を含めるようにしても良い。これを受信したICカード１２は、変更するディレクトリのディレクトリ鍵（Directory Key）を読み出し、この鍵でコマンドに添付されてきたデータを復号化する。そして、得られた新しいディレクトリ鍵（Directory Key）で古いディレクトリ鍵（Directory Key）を書き換え、キーバージョン（Key Version）を更新する。
【００９１】
同様に、アプリケーションID（Application ID）とアプリケーション鍵（Application Key）の変更は、ディレクトリが生成されていればよい（片方だけ変更することは通常ない）。実際には、この状態で認証鍵（システム鍵（System Key）、ルート鍵（Root Key）、ディレクトリ鍵（Directory Key）、およびアプリケーション鍵（Application Key）が使用される）の生成を行い、必要なデータをセキュリティICに送り込んで行う。コマンドはアプリケーション鍵変更コマンドとして定義され、コマンドに含まれるデータ列には、非暗号化アプリケーションID（Application ID）／非暗号化アプリケーション鍵（Application Key）が含まれている。また、必要に応じて、ここに新しい鍵のキーバージョン（Key Version）を含めるようにしても良い。ただし、アプリケーションID（Application ID）は、ICカード１２の外部の機器で新たに割り振ることとし、このIDとアプリケーション鍵（Application Key）を生成するためのマスタ鍵とからアプリケーションID（Application ID）に対応するアプリケーション鍵（Application Key）を生成することとする。
【００９２】
次に、これを受信したICカード１２は、受信したアプリケーションID（Application ID）及びアプリケーション鍵（Application Key）を書き換え、キーバージョン（Key Version）を更新する。
【００９３】
なお、通常、このICカード１２の外部の機器は、鍵変更処理専門の端末であり、複数のICカードの鍵を変更し、これらの情報を管理している。従って、この鍵変更処理専門の端末は、アプリケーションID（Application ID）を系統的に割り振って管理することが可能である。
【００９４】
また、アプリケーション情報変更処理時に認証鍵を生成すると説明したが、上記ディレクトリ鍵（Directory Key）変更処理に引き続き行う場合には不要である。
【００９５】
一方、後述するように、相互認証を終了した鍵変更処理専門の端末とICカード１２は、以降の通信路をセッション鍵で暗号化して秘匿化することができ、かつメッセージを改ざん防止できるよう整合性チェックを行っている。このため、更新するための新しいディレクトリ鍵を鍵変更処理専門の端末内部に保持していても、通信路上で漏洩する心配はない。しかし、鍵変更処理専門の端末が安全に管理される保証はないため、念のため古いディレクトリ鍵で更新する新しいディレクトリ鍵を暗号化しておくこととする。一方で、新しいアプリケーション鍵は古いアプリケーション鍵で暗号化しておくことはしていない。これは、鍵変更処理専門の端末にアプリケーション鍵を生成するためのマスタ鍵が記憶されており、鍵更新時にアプリケーション鍵の生成を行っていることと（あらかじめ古いアプリケーション鍵で暗号化しておくことができない）、仮に鍵変更処理専門の端末が安全に管理されなかった場合、このマスタ鍵が漏洩することになり、そこまで対策しても効果が薄いからである。
【００９６】
なお、本例では各種鍵変更のための所定フォーマットコマンドを使用するとしたが、必要に応じて各種鍵変更のためのアクセス許諾チケットを定義し、それを用いて行うようにしても良い。
【００９７】
アクセス制御鍵（Access Control Key）の変更は、ファイルが生成されていれば実行可能である。実際には、この状態で認証鍵（システム鍵（System Key）、ルート鍵（Root Key）、ディレクトリ鍵（Directory Key）、およびアプリケーション鍵（Application Key）が使用される）の生成を行い、必要なデータをセキュリティICに送り込んで行う。コマンドはアクセス制御鍵変更コマンドとして定義され、図１０に示されるように、コマンドに含まれるデータ列５６には、新しいアクセス制御鍵（Access Control Key）を古いアクセス制御鍵（Access Control Key）で暗号化したものが含まれる。また、必要に応じて、ここに新しい鍵のキーバージョン（Key Version）を含めるようにしても良い。これを受信したICカード１２は、変更するファイルのアクセス制御鍵（Access Control Key）を読み出し、この鍵でコマンドに添付されてきたデータを復号化する。そして、得られた新しいアクセス制御鍵（Access Control Key）で古いアクセス制御鍵（Access Control Key）を書き換え、キーバージョン（Key Version）を更新する。なお、アクセス制御鍵（Access Control Key）の変更はアプリケーション鍵（Application Key）変更時と異なり、事前にデータ列を用意することができることと、物理セキュリティリスクがあることから、データを暗号化しておくこととした。このため、本例ではアクセス制御鍵変更のための所定フォーマットコマンドを使用するとしたが、必要に応じてサアクセス制御鍵変更のためのアクセス許諾チケットを定義し、それを用いて行うようにしても良い（このチケットは事前に作成できる）。
【００９８】
相互認証後、情報処理端末１１とICカード１２との間でセッション鍵が共有化される。通信されるパケットは全てセッション鍵で暗号化されると共に、改ざん防止用としてメッセージ認証用のデータが付加される。OMAC(One-Key CBC MAC)は、CBC MAC(Cipher Block Chaining Message Authentication Code)の変種としてが知られている。もしくはCCM(Counter with CBC-MAC)を用いるようにしてもよい。
【００９９】
図１の通信システム１において、情報処理端末１１およびICカード１２は、通信を行うためにセッションを確立する。情報処理端末１１およびICカード１２は、通信開始時において、そのセッションの確立のために、お互いを認証させる相互認証処理を行う。
【０１００】
図１１および図１２のフローチャートを参照して、その相互認証処理の流れの例を説明する。なお、必要に応じて、図１３乃至図１６を参照して説明する。また、ここでは、説明の便宜上、図２の情報処理端末１１−１−１およびICカード１２−１が相互認証処理を行う場合を例に説明する。
【０１０１】
相互認証処理が開始されると、情報処理端末１１−１−１の認証処理部２３は、ステップＳ２１において、乱数生成部２５を制御して第一の乱数を生成する。
【０１０２】
ステップＳ２２において、認証処理部２３は、通信部２８を制御して、第一の相互認証開始コマンドを、情報処理端末１１−１−１のID（ID１−１）、アクセスするディレクトリを示すアクセス先ディレクトリ情報、および、ステップＳ２１の処理において生成された第一の乱数とともに、ICカード１２−１に送信させる。なお、アクセス先ディレクトリ情報においては、アクセス先のディレクトリが例えばディレクトリコード（Directory Code）によって示される。もちろん、アクセス先のディレクトリを特定することができる情報であれば、ディレクトリコード（Directory Code）以外の情報を用いるようにしてもよい。なお、ここではアクセス先ディレクトリの一例として、ディレクトリ１−１とディレクトリ１−２が指定されたものとして説明する。
【０１０３】
ステップＳ３１において、ICカード１２−１の通信部３８は、この第一の相互認証開始コマンド等を取得する。第一の相互認証開始コマンドを取得すると、認証処理部３３のマスタ鍵生成部４１は、ステップＳ３２において、相互認証の相手となる情報処理端末１１（この場合、情報処理端末１１−１−１）固有の鍵（この場合、鍵Ｋ１−１）を生成するための鍵情報であるマスタ鍵（この場合、マスタ鍵MK１−IT）を生成する処理を行う。マスタ鍵の生成は、第一のデータ、ルート鍵、および、アクセス先に指定されたディレクトリのディレクトリ鍵を縮退することにより生成される。
【０１０４】
より具体的な例は、図１３に示される。図１３に示されるように、マスタ鍵生成部４１は、暗号化処理部（AES）６１乃至暗号化処理部（AES）６３の機能ブロックを有する。暗号化処理部（AES）６１は、暗号化部３６を制御し、第一のデータとしてシステム鍵（ＫSystem）をルート鍵（ＫRoot）を用いてAES（Advanced Encryption Standard）方式で暗号化させ、第二のデータを生成する。暗号化処理部（AES）６２は、暗号化部３６を制御し、その第二のデータをディレクトリ１−１のディレクトリ鍵（DirK１−１）を用いてAES方式で暗号化させる。暗号化処理部（AES）６３は、暗号化部３６を制御し、暗号化処理部（AES）６２による暗号化結果をディレクトリ１−２のディレクトリ鍵（DirK１−２）を用いてAES方式で暗号化させ、マスタ鍵（MK１−IT）を生成する。なお、AESの代わりに、DES（Data Encryption Standard）等、その他の共通鍵暗号化方式を用いるようにしてもよい。
【０１０５】
このマスタ鍵生成処理の詳細な流れについては、後述する。マスタ鍵が生成されると認証処理部３３は、ステップＳ３３において、暗号化部３６を制御し、情報処理端末１１−１−１のID（ID１−１）を、ステップＳ３２の処理により生成されたマスタ鍵（MK１−IT）を用いて暗号化させ、情報処理端末１１−１−１固有の鍵（Ｋ１−１）を生成する。
【０１０６】
具体的な例を図１４に示す。図１４に示されるように、認証処理部３３は、暗号化処理部（AES）７１の機能ブロックを有する。暗号化処理部（AES）７１は、暗号化部３６を制御し、情報処理端末１１−１−１のID（ID１−１）をマスタ鍵（MK１−IT）を用いてAES方式で暗号化させ、情報処理端末１１−１−１固有の鍵（Ｋ１−１）を生成する。
【０１０７】
なお、この場合も、AESの代わりに、DES等、その他の共通鍵暗号化方式を用いるようにしてもよい。また、本例では暗号化する例で説明したが、ステップＳ３２の処理により生成されたマスタ鍵（MK１−IT）を用いて情報処理端末１１−１−１のID（ID１−１）を復号化し、情報処理端末１１−１−１固有の鍵（Ｋ１−１）を生成しても良い。あるいは、所定の固定値を情報処理端末１１−１−１のID（ID１−１）に対してEXORするなどして演算した後、ステップＳ３２の処理により生成されたマスタ鍵（MK１−IT）を用いて暗号化させて生成するようにしても良い。このように、情報処理端末１１−１−１に保持されている固有の鍵（Ｋ１−１）が復元できさえすれば、どのような演算方法を用いてもかまわない。
【０１０８】
この鍵Ｋ１−１は、情報処理端末１１−１−１固有の鍵である。図２の例において、事業者１の情報処理端末１１−１−２には、情報処理端末１１−１−１に割り当てられたID（ID１−１）と異なるID（ID１−２）が書き込まれているため、同じ情報処理端末用マスタ鍵（MK１−IT）を用いても、情報処理端末１１−１−１固有の鍵（Ｋ１−１）とは異なる情報処理端末１１−１−２固有の鍵（Ｋ１−２）が生成される。
【０１０９】
ステップＳ３４において、認証処理部３３は、暗号化部３６を制御し、アクセス先に指定されたディレクトリに書き込まれたアプリケーションID（AppID１−１とAppID１−２）を情報処理端末１１−１−１固有の鍵（Ｋ１−１）で暗号化させ、第一の返信文を作成する。このとき、アプリケーションID（AppID）の使用順は、情報処理端末１１−１−１より供給されたアクセス先ディレクトリ情報に従う。なお、このときの暗号化方法は、CBC（Cipher Block Chaining）モード等の暗号利用モードを用いることとする。また、本例では暗号化することを示していたが、復号するようにしてもよい。この場合、この第一の返信文を受け取った情報処理端末１１−１−１側では、同一の鍵を用いて暗号化する必要がある。
【０１１０】
第一の返信文を生成した後、認証処理部３３は、ステップＳ３５において、相互認証に利用される認証鍵（KAuth）の生成を行う。認証処理部３３は、暗号化部３６を制御し、情報処理端末１１−１−１固有の鍵（Ｋ１−１）を、アクセス先に指定されたディレクトリに書き込まれたアプリケーション鍵（AppK１−１およびAppK１−２）を用いて暗号化させて認証鍵（KAuth）を生成する。このような処理を鍵の縮退化とする。
【０１１１】
具体的な例を図１５に示す。図１５に示されるように、認証処理部３３は、暗号化処理部（AES）８１および暗号化処理部（AES）８２の機能ブロックを有する。暗号化処理部（AES）８１は、暗号化部３６を制御し、情報処理端末１１−１−１固有の鍵（Ｋ１−１）を、アクセス先に指定されたディレクトリ１−１に書き込まれているアプリケーション鍵（AppK１−１）を用いてAES方式で暗号化させる。暗号化処理部（AES）８２は、暗号化部３６を制御し、暗号化処理部（AES）８１による暗号化結果を、アクセス先に指定されたディレクトリ１−２に書き込まれているアプリケーション鍵（AppK１−２）を用いてさらにAES方式で暗号化させる。この暗号化処理部（AES）８２による暗号化結果が認証鍵（KAuth）とされる。
【０１１２】
なお、アプリケーション鍵（AppK）の使用順は、情報処理端末１１−１−１より供給されたアクセス先ディレクトリ情報に従う。また、この場合も、AESの代わりに、DES等、その他の共通鍵暗号化方式を用いるようにしてもよい。
【０１１３】
ステップＳ３６において、認証処理部３３は、乱数生成部３５を制御して第二の乱数を生成する。ステップＳ３７において、認証処理部３３は、認証鍵（KAuth）を暗号鍵とし、暗号化部３６を制御して、この第二の乱数、情報処理端末１１−１−１から送られてきた第一の乱数、および、情報処理端末１１−１−１のID（ID１−１）を所定の暗号利用モードで暗号化し、第二の返信文を生成する。なお、第二の乱数、第一の乱数、および、情報処理端末１１−１−１のID（ID１−１）は、予め定められた所定の順序で暗号化される。
【０１１４】
ここで、本例では第一の返信文は情報処理端末１１−１−１固有の鍵（Ｋ１−１）で暗号化させて生成し、第二の返信文は認証鍵（KAuth）で暗号化させて生成していたが、暗号化された第一の返信文及び暗号化前の第二の返信文を、認証鍵（KAuth）を用いて、所定の暗号利用モードで一括して暗号化するようにしても良い。更にまた、第二の返信文に情報処理端末１１−１−１のID（ID１−１）を含ませていたが、これ（情報処理端末１１−１−１のID）以外のデータを利用するようにしても良い。
【０１１５】
ステップＳ３８において、ICカード１２−１の認証処理部３３は、通信部３８を制御して、相互認証開始コマンドに対するレスポンスとして、第一の返信文と第二の返信文を、情報処理端末１１−１−１に返信させる。ステップＳ３８の処理を終了すると、ICカード１２−１の認証処理部３３は、図１２のステップＳ５１に処理を進める。
【０１１６】
また、情報処理端末１１−１−１の通信部２８は、ステップＳ２３においてそのレスポンス（第一の返信文と第二の返信文）を受信すると、処理を図１２のステップＳ４１に進める。
【０１１７】
図１２のステップＳ４１において、情報処理端末１１−１−１の認証処理部２３は、復号部２７を制御し、予め記憶部２１に記憶されている情報処理端末１１−１−１固有の鍵（Ｋ１−１）を用いて第一の返信文を、利用された暗号化方法に対応する復号方法で復号させ、アプリケーションID（AppID１−１とAppID１−２）を取り出す。ステップＳ４２において、認証処理部２３は、予め記憶部２１に記憶されているマスタ鍵（MK1−IC）を用いてアプリケーションID（AppID１−１）暗号化することによりアプリケーション鍵（AppK１−１）を生成し、さらに、マスタ鍵（MK1−IC）を用いてアプリケーションID（AppID１−２）を暗号化することによりアプリケーション鍵（AppK１−２）を生成する。
【０１１８】
具体的な例を図１６に示す。図１６に示されるように、認証処理部３３は、暗号化処理部（AES）９１の機能ブロックを有する。暗号化処理部（AES）９１は、暗号化部２６を制御し、ディレクトリ１−１のアプリケーションID（AppID１−１）を、マスタ鍵（MK1−IC）を用いてAES方式で暗号化してアプリケーション鍵（AppK１−１）を生成する。なお、図示は省略するが、この暗号化処理部（AES）９１は、アプリケーション鍵（AppK１−１）の場合と同様に、暗号化部３６を制御し、ディレクトリ１−２のアプリケーションID（AppID１−２）を、マスタ鍵（MK1−IC）を用いてAES方式で暗号化してアプリケーション鍵（AppK１−２）を生成する。
【０１１９】
なお、この場合も、AESの代わりに、DES等、その他の共通鍵暗号化方式を用いるようにしてもよい。また、例えば、ディレクトリ毎にマスタ鍵が異なる場合、各アプリケーションIDの暗号化は、それぞれのアプリケーションIDが対応するディレクトリのマスタ鍵を用いて行われるようにする。つまり、ディレクトリ１−１のアプリケーション鍵（AppK１−１）は、ディレクトリ１−１のアプリケーションID（AppID１−１）を、ディレクトリ１−１用のマスタ鍵（MK1−IC1）を用いて生成し、ディレクトリ１−２のアプリケーション鍵（AppK１−２）は、ディレクトリ１−２のアプリケーションID（AppID１−２）を、ディレクトリ１−２用のマスタ鍵（MK1−IC2）を用いて生成する、などの方法である。
【０１２０】
ステップＳ４３において、認証処理部２３は、暗号化部２６を制御して、情報処理端末１１−１−１固有の鍵（Ｋ１−１）を、ステップＳ４２で生成したアプリケーション鍵（AppK１−１およびAppK１−２を用いて暗号化させ、認証鍵（ＫAuth）を生成する。この認証鍵（ＫAuth）の生成方法は、ICカード１２において実行されるステップＳ３５の処理の場合と同様に実行される。つまり、図１５を参照して行った説明は、このステップＳ４３における認証鍵生成の説明にも適用することができる。つまり、認証処理部２３も、図１５に示されるように、暗号化処理部（AES）８１および暗号化処理部（AES）８２の機能ブロックを有し、その暗号化処理部（AES）８１は、暗号化部２６を制御し、情報処理端末１１−１−１固有の鍵（Ｋ１−１）をアプリケーション鍵（AppK１−１）を用いてAES方式で暗号化させ、暗号化処理部（AES）８２は、暗号化部２６を制御し、暗号化処理部（AES）８１による暗号化結果をアプリケーション鍵（AppK１−２）を用いてさらにAES方式で暗号化させる。この暗号化処理部（AES）８２による暗号化結果が認証鍵（KAuth）とされる。
【０１２１】
なお、アプリケーション鍵（AppK）の使用順は、アクセス先ディレクトリ情報において定義されるとおり（復号されたディレクトリID順）とする。また、この場合も、AESの代わりに、DES等、その他の共通鍵暗号化方式を用いるようにしてもよい。
【０１２２】
ステップＳ４４において、認証処理部２３は、復号部２７を制御し、ICカード１２−１より取得した第二の返信文を復号させ、第二の乱数、第一の乱数、および情報処理端末１１−１−１固有のID（ID１−１）を取り出す。
【０１２３】
ステップＳ４５において、認証処理部２３は、取り出した第一の乱数によりICカード１２−１の認証を行う。仮に、ICカード１２−１より取得した第二の返信文を復号して得られた第一の乱数が、ICカード１２−１に供給した第一の乱数と一致する（同一である）場合、ICカード１２−１においても同一の認証鍵が生成されていることになる。つまり、ICカード１２−１が、第一のデータ、ルート鍵（ＫRoot）、ディレクトリ鍵（DirK１−１およびDirK１−２）、アプリケーション鍵（AppK１−１およびAppK１−２）を保持している蓋然性が高い。従って、認証処理部２３は、相手（ICカード１２−１）を認証してもよいと判断することができる。逆に、第一の乱数が正しくない（一致しない）場合、認証処理部２３は、ICカード１２−１は不正であると判定することとなる。
【０１２４】
つまり、認証処理部２３は、第二の返信文より取り出した第一の乱数が図７のステップＳ２１において生成した第一の乱数と一致するか否かを判定することにより、ICカード１２−１を認証するか否かを判定する。そして、２つの第一の乱数の値が互いに一致した場合、認証処理部２３は、ICカード１２−１を認証する。逆に、２つの第一の乱数の値が互いに一致しなかった場合、認証処理部２３は、ICカード１２−１が不正であると判定し、相互認証処理をエラー終了する。つまり、この場合、情報処理端末１１−１−１とICカード１２−１との間の相互認証が行われないので、通信の確立に失敗する。
【０１２５】
２つの第一の乱数の値が互いに一致し、ICカード１２−１が認証されると、認証処理部２３は、ステップＳ４６において、乱数生成部２５を制御して乱数を生成させ、その乱数をセッション鍵とする。このセッション鍵は、相互認証完了後の通信路の秘匿化に使用される。
【０１２６】
ステップＳ４７において、認証処理部２３は、第一の乱数、第二の乱数、および、生成したセッション鍵を、認証鍵（ＫAuth）で暗号化する。暗号化は所定の暗号利用モードで行うこととする。なお、暗号化の順はこれに限らず任意である。
【０１２７】
ステップＳ４８において、認証処理部２３は、通信部２８を制御して、第二の相互認証コマンドを、認証鍵（ＫAuth）で暗号化された第一の乱数、第二の乱数、およびセッション鍵と共にICカード１２−１に送信させる。ICカード１２−１の通信部３８は、ステップＳ５１において、この第二の相互認証コマンドと、認証鍵（ＫAuth）で暗号化された第一の乱数、第二の乱数、およびセッション鍵を取得する。
【０１２８】
ステップＳ５２において、ICカード１２−１の認証処理部３３は、復号部３７を制御し、認証鍵（ＫAuth）を用いて認証鍵（ＫAuth）で暗号化された第一の乱数、第二の乱数、およびセッション鍵を復号させる。
【０１２９】
ステップＳ５３において、認証処理部３３は、取り出した第二の乱数により情報処理端末１１−１−１の認証を行う。仮に、情報処理端末１１−１−１より取得した第二の乱数が、図１１のステップＳ３６の処理において生成された第二の乱数と一致する（同一である）場合、情報処理端末１１−１−１においても同一の認証鍵が生成されていることになる。つまり、情報処理端末１１−１−１が情報処理端末１１−１−１固有の鍵Ｋ１−１と、ICカード１２−１用のマスタ鍵（MK１−IC）を保持している蓋然性が高い。従って、認証処理部３３は、相手（情報処理端末１１−１−１）を認証してもよいと判断することができる。逆に、第二の乱数が正しくない（一致しない）場合、認証処理部３３は、情報処理端末１１−１−１が不正であると判定することとなる。
【０１３０】
つまり、認証処理部３３は、第二の相互認証コマンドともに供給された第二の乱数が、図１１のステップＳ３６において生成した第二の乱数と一致するか否かを判定することにより、情報処理端末１１−１−１を認証するか否かを判定する。そして、２つの第二の乱数の値が互いに一致した場合、認証処理部３３は、情報処理端末１１−１−１を認証する。逆に、２つの第二の乱数の値が互いに一致しなかった場合、認証処理部３３は、情報処理端末１１−１−１が不正であると判定し、相互認証処理をエラー終了する。つまり、この場合、情報処理端末１１−１−１とICカード１２−１との間の相互認証が行われないので、通信の確立に失敗する。
【０１３１】
２つの第二の乱数の値が互いに一致し、情報処理端末１１−１−１が認証されると、認証処理部３３は、ステップＳ５４において、通信部３８を制御し、その認証結果をレスポンスとして送信させ、相互認証処理を正常終了する。
【０１３２】
ステップＳ４９において、情報処理端末１１−１−１の通信部２８は、そのレスポンス取得し、相互に認証されたことを把握し、相互認証処理を正常終了する。
【０１３３】
以上のようにして、相互に相手が認証されると、それ以降の電文は、全てセッション鍵により暗号化されて送受信される。
【０１３４】
次に、図１１のステップＳ３２において実行されるマスタ鍵生成処理の詳細な流れの例を図１７のフローチャートを参照して説明する。
【０１３５】
マスタ鍵生成処理が開始されると、マスタ鍵生成部４１は、ステップＳ７１において、情報処理端末１１−１−１より供給されたアクセス先ディレクトリ情報に基づいて、マスタ鍵（MK１−IT）の生成に使用するディレクトリ鍵（DirK１−１およびDirK１−２）を取得する。ステップＳ７２において、マスタ鍵生成部４１は、アクセス先ディレクトリ情報に示される順に、マスタ鍵（MK１−IT）の生成に使用するディレクトリ鍵（DirK１−１およびDirK１−２）を整列させる。整列が完了すると、マスタ鍵生成部４１は、ステップＳ７３において、まず、第一のデータ（ＫSystem）をルート鍵（ＫRoot）で暗号化する。
【０１３６】
ステップＳ７４において、マスタ鍵生成部４１は、ステップＳ７１において取得したディレクトリ鍵（DirK）の中に未使用のディレクトリ鍵（DirK）が存在するか否かを判定し、存在すると判定した場合、ステップＳ７５に処理を進め、次の順のディレクトリ鍵を用いて前回の暗号化結果を暗号化する。暗号化が終了すると、マスタ鍵生成部４１は、処理をステップＳ７４に戻す。
【０１３７】
以上のように、マスタ鍵生成部４１は、ステップＳ７４およびステップＳ７５の処理を繰り返し、取得した全てのディレクトリ鍵を用いて暗号化を繰り返す。そして、ステップＳ７４において全てのディレクトリ鍵を使用したと判定した場合、マスタ鍵生成部４１は、マスタ鍵生成処理を終了する。
【０１３８】
つまり、マスタ鍵生成部４１は、以上のように暗号化を繰り返すことにより、第一のデータとして利用されるシステム鍵（ＫSystem）、ルート鍵（ＫRoot）、取得したディレクトリ鍵を縮退化させてマスタ鍵（MK１−IT）を生成する。
【０１３９】
なお、以上においては、情報処理端末１１−１−１とICカード１２−１の間の相互認証処理について説明したが、情報処理端末１１−１−２、情報処理端末１１−２−１、ICカード１２−２等、通信システム１の他のデバイス間の相互認証処理も同様に実行される。
【０１４０】
以上のように、ICカード１２の記憶部３１には、ディレクトリ毎にアプリケーションIDが設けられており、各IDは、それぞれが対応する正当な事業者にしか提示されないようになされている。これにより、ユーザのプライバシーを守ることができるようになる。
【０１４１】
つまり、例えばICカード固有のIDが一つしかない場合、正当な情報処理端末では（事業者によらず）全て同一IDを読み出せてしまい、そのIDをトラッキングすることでユーザの居場所を追跡できてしまうという弊害があった。
【０１４２】
しかしながら、通信システム１においては、事業者毎にユーザに（ディレクトリ内に）IDを割り振る方式とし、更に、このIDは割り振った事業者のみが知り得る鍵で暗号化して返信することとした。このため、他の事業者ではIDを復号することができなくなった。つまり、自分のお客であるユーザは認識できるが、他のお客は認識できないことになり、他のお客までを含めてトラッキングされることを防止できるようにした。
【０１４３】
また、共通鍵認証よりも強度的に優れる個別鍵認証技術を導入すると共に、複数のディレクトリにアクセスすることを想定し、アクセス先ディレクトリに応じてディレクトリ鍵等を縮退化させたマスタ鍵を用いることにより、それらを一回の認証手順で処理できるようにした。これにより、認証処理時間を大幅に減らすことができるようになった。
【０１４４】
さらに、通信システム１においては、認証処理に情報処理端末１１のIDを用いるため、仮に情報処理端末１１が解析されて不正な情報処理端末１１’が作成されたとしても、情報処理端末１１’のIDは情報処理端末１１のIDと同一になるので、ICカード１２側においてそのIDをリボーク（Revoke）用のIDとして保持させておくことにより、ICカード１２は、情報処理端末１１’によるアクセスを阻止することができる。
【０１４５】
すなわち、通信システム１（情報処理端末１１およびICカード１２）は、安全かつ迅速に相互認証処理を行うことができる。
【０１４６】
以上を通し、相互認証が完了した。相互認証が完了すると、情報処理端末１１は、次に、ICカード１２に書き込まれているファイルにアクセスする。そのファイルアクセス方法について説明する。なお、本例では複数の主体が出てきても同じであるため、事業者１の情報処理端末１１−１−１、ICカード１２−１のみを定義するものとするが、当然他の事業者、他の情報処理端末１１、他のICカード１２が登場してもよい。また、誤解がない場合には、情報処理端末１１−１−１を情報処理端末１１、ICカード１２−１をICカード１２と表記する場合がある。
【０１４７】
情報処理端末１１−１−１がファイルにアクセスするためには、ICカード１２−１よりファイルアクセスの許諾を受けなければならない。正当な情報処理端末１１には、予めアクセス許諾に必要な情報を含むアクセス許諾チケットが配布されている。情報処理端末１１−１−１は、そのアクセス許諾チケットをICカード１２−１に提示することでファイルアクセスの許諾を求める。ICカード１２−１は、そのアクセス許諾チケットを検証し、正当なものであればアクセスを許諾する。
【０１４８】
次に、情報処理端末１１−１−１とICカード１２−１のそれぞれが有する、このようなアクセス制御に関する情報について、図１８を参照して説明する。
【０１４９】
図１８の例において、情報処理端末１１−１−１の記憶部２１―１−１には、情報処理端末１１のID（ID１−１）、情報処理端末固有の鍵（Ｋ１−１）、事業者１によるICカード１２全般用のマスタ鍵（MK１−IC）、および情報処理端末１１−１−１に割り当てられたアクセス許諾チケット（Ticket１−１）が書き込まれている。
【０１５０】
ICカード１２−１の記憶部３１−１には、第一のデータ（ＫSystem）、第三のデータ（ＫSystem2）、ルート鍵（ＫRoot）が書き込まれている。第三のデータ（ＫSystem2）は、基本的に第一のデータ（ＫSystem）と同様であるものの、システム管理者によって割り当てられる、アクセス許諾チケット生成鍵用のシステム鍵となる。つまり、ICカード１２には、認証鍵用のシステム鍵（ＫSystem）と、アクセス許諾チケット生成鍵用のシステム鍵（ＫSystem2）の２つのシステム鍵が登録される。これら２つのシステム鍵のフォーマットは任意であり、例えば、暗号化アルゴリズムや鍵長が互いに異なっていてもよいし、統一されていてもよい。また、各システム鍵の値が独立して決定されるようにしてもよいし、一方から他方を算出することができるようにして、片方のシステム鍵をメモリ上に保持しないようにしてもよい。
【０１５１】
ICカード１２−１の記憶部３１−１には、さらに、ディレクトリ１−１とディレクトリ１−２が作成されている。ディレクトリ１−１には、ディレクトリ鍵（Dir１−１）、アプリケーションID（AppID１−１）、アプリケーション鍵（AppK１−１）が書き込まれており、さらに、ファイル（File１）と、そのファイル（File１）に対するアクセス方法を定義するアクセス制御鍵（ACK１−１およびACK１−２）が書き込まれている。
【０１５２】
アクセス制御鍵は、所謂、ファイルに対するパーミッションを設定するものであり、読み出しや書き込み等の、アクセス者によるファイルに対する操作を制限するための鍵情報である。つまり、１つ目のアクセス制御鍵（ACK１−１）は、ファイル（File１）に対するアクセス方法１−１でのアクセスを許可するための鍵情報であり、２つ目のアクセス制御鍵（ACK１−２）は、ファイル（File１）に対するアクセス方法１−２でのアクセスを許可するための鍵情報である。
【０１５３】
また、ディレクトリ１−２には、ディレクトリ鍵（Dir１−２）、アプリケーションID（AppID１−２）、アプリケーション鍵（AppK１−２）が書き込まれており、さらに、ファイル（File２およびFile３）、その１つ目のファイル（File２）に対するアクセス方法を定義するアクセス制御鍵（ACK２−１、ACK２−２、およびACK２−３）、並びに、２つ目のファイル（File３）に対するアクセス方法を定義するアクセス制御鍵（ACK３−１およびACK３−２）が書き込まれている。
【０１５４】
図１９に、図１８に示されるアクセス制御チケット（Ticket１−１）の構成例を示す。
【０１５５】
アクセス許諾チケット１０１には、このチケットの使用者を示す情報として情報処理装置１１−１−１のID（ID１−１）、アクセス先のファイルおよびアクセス方法（すなわち、アクセス制御鍵）を示すアクセスコードのリスト（アクセスコード：１−２、アクセスコード：２−２、アクセスコード：２−３、アクセスコード：３−１）、および、MACよりなるチェック子が記述されている。
【０１５６】
つまり、ファイルへのアクセス許諾を求める情報処理端末１１−１−１は、誰がどのファイルに対してどのような処理をするかを示すアクセス許諾チケット１０１をICカード１２−１に送信し、ICカード１２−１においてそのアクセス許諾チケット１０１の検証を行い、正当であれば、そのチケットにより要求されるアクセス方法を許諾する。
【０１５７】
図２０のフローチャートを参照してこのようなアクセス制御の処理の流れの例を説明する。必要に応じて図２１および図２２を参照して説明する。
【０１５８】
アクセスの許諾を求める情報処理装置１１−１−１のファイルアクセス処理部２４は、ステップＳ１０１において、通信部２８を制御して、アクセス許諾チケット（Ticket１−１）を含むファイル許可命令をICカード１２−１に対して発行する。この時、命令文をセッション鍵により暗号化するようにしてもよい。ICカード１２−１の通信部３８は、ステップＳ１１１において、そのファイル許可命令を取得する。
【０１５９】
ファイル許可命令を取得すると、ICカード１２−１のファイルアクセス処理部３４は、ステップＳ１１２において、アクセス許諾チケット（Ticket１−１）に記述されているチケットの使用者のIDを検証する。情報処理端末１１−１−１（ID１−１）は、相互認証処理において認証済みであるので、ファイルアクセス処理部３４は、アクセス許諾チケット（Ticket１−１）に記述されている使用者IDがこの認証済みのIDと一致するか否かを検証し、一致する場合のみ、アクセス許諾チケット（Ticket１−１）の使用者を認証する。アクセス許諾チケット（Ticket１−１）の使用者のIDが認証済みのIDと一致しない場合、ファイルアクセス処理部３４は、このアクセス制御処理を強制終了し、アクセスの許諾要求を拒否する。このため、他の情報処理端末のチケットを不正に使用しても、アクセスは拒否される。
【０１６０】
なお、認証済みのIDに関わらず、アクセス制御チケットの使用者を許諾させる特別なID（オールマイティID）を設けるようにしてもよい。例えば、所定のIDをオールマイティIDとして予め用意しておき、IDカード１２のファイルアクセス処理部３４が、アクセス許諾チケットの使用者のIDがこのオールマイティIDである場合、認証済みのIDとの一致不一致に関わらず、使用者を認証するようにすればよい。つまり、このオールマイティIDが使用者のIDとして記述されることにより、そのアクセス制御チケットは、どの情報処理端末１１においても使用可能なチケットとなる。
【０１６１】
アクセス制御チケット（Ticket１−１）の使用者を認証すると、ファイルアクセス処理部３４は、ステップＳ１１３において、アクセス制御チケット（Ticket１−１）に記述されているアクセスコードが、相互認証処理において情報処理端末１１−１−１のアクセス先として認証済みのディレクトリのものであるか否かを確認する。相互認証時に指定したディレクトリ以外のディレクトリのアクセスコードが含まれている場合（すなわち、相互認証時に指定したディレクトリ以外のディレクトリへのアクセスを要求している場合）、ファイルアクセス処理部３４は、このアクセス制御処理を強制終了し、アクセスの許諾要求を拒否する。
【０１６２】
アクセス制御チケット（Ticket１−１）に記述されているアクセスコードが、相互認証処理において情報処理端末１１−１−１のアクセス先として認証済みのディレクトリのものである場合、ファイルアクセス処理部３４は、アクセス制御処理を継続する。なお、認証済みのディレクトリのアクセスコードと、認証済みでないディレクトリのアクセスコードの両方が含まれている場合、ファイルアクセス処理部３４が、このアクセス制御処理を強制終了し、アクセスの許諾要求を拒否するようにしてもよいし、認証済みでないディレクトリのアクセスコードについてのみ拒否し、認証済みのアクセスコードに対しては処理を継続するようにしてもよい。
【０１６３】
ステップＳ１１４において、ファイルアクセス処理部３４は、第三のデータ（ＫSystem2）をルート鍵（ＫRoot）で暗号化して第四のデータ（System Data）を生成する。
【０１６４】
図２１に示されるように、ファイルアクセス処理部３４は、暗号化処理部（AES）１１１の機能ブロックを有する。暗号化処理部（AES）１１１は、暗号化部３６を制御し、第三のデータとしてシステム鍵（ＫSystem2）をルート鍵（ＫRoot）を用いてAES方式で暗号化させ、第四のデータ（System Data）を生成する。なお、暗号化処理部（AES）１１１が、AESの代わりに、DES等、その他の共通鍵暗号化方式を用いるようにしてもよい。
【０１６５】
また、ここでは第一のデータと異なるデータを使用したが、第一のデータを使用するようにしてもよい。なお、ここでも第四のデータを事前に計算し、記憶部３１に保持しておくようにしてもよい。その場合、ステップＳ１１４の処理は省略される。
【０１６６】
ステップＳ１１５において、ファイルアクセス処理部３４のアクセス許諾チケット生成鍵生成部４２は、第四のデータから、アクセス許諾チケットのチェック子（MAC）を算出するためのアクセス許諾チケット生成鍵を作成する処理を行う。アクセス許諾チケット生成鍵生成部４２は、アクセス制御チケット（Ticket１−１）に記述されているアクセスコードに対応するアクセス制御鍵を記憶部３１−１より全て読み出し、第四のデータをこれらの鍵を使って順番に暗号化していく。
【０１６７】
図１９の例の場合、アクセス制御チケット（Ticket１−１）には、アクセスコード：１−２、アクセスコード：２−２、アクセスコード：２−３、およびアクセスコード：３−１が記述されている。従って、アクセス許諾チケット生成鍵生成部４２は、記憶部３１−１よりACK１−２、ACK２−２、ACK２−３、およびACK３−１を取得する。
【０１６８】
この場合、図２２に示されるように、アクセス許諾チケット生成鍵生成部４２は、暗号化処理部（AES）１２１乃至暗号化処理部（AES）１２４の機能ブロックを有する。暗号化処理部（AES）１２１は、暗号化部３６を制御し、第四のデータ（System Data）を、ACK１−２を用いてAES方式で暗号化させる。暗号化処理部（AES）１２２は、暗号化部３６を制御し、暗号化処理部（AES）１２１による暗号化結果を、ACK２−２を用いてAES方式で暗号化させる。暗号化処理部（AES）１２３は、暗号化部３６を制御し、暗号化処理部（AES）１２２による暗号化結果を、ACK２−３を用いてAES方式で暗号化させる。さらに、暗号化処理部（AES）１２４は、暗号化部３６を制御し、暗号化処理部（AES）１２３による暗号化結果を、ACK３−１を用いてAES方式で暗号化させ、アクセス許諾チケット生成鍵（A.C.Gen.Key）を生成する。なお、暗号化処理部（AES）１２１乃至暗号化処理部（AES）１２４が、AESの代わりに、DES等、その他の共通鍵暗号化方式を用いるようにしてもよい。なお、アクセス許諾チケット生成鍵生成処理の別な方法は、後述する（図２３参照）。
【０１６９】
アクセス許諾チケット生成鍵が生成されるとファイルアクセス処理部３４は、ステップＳ１１６において、アクセス許諾チケットのチェック子（MAC値）を、アクセス許諾チケット生成鍵を用いて計算する（例えば、暗号利用モードのCBCモードなどを利用する）。
【０１７０】
ステップＳ１１７において、ファイルアクセス処理部３４は、生成したチェック子の値を、アクセス許諾チケット（Ticket１−１）のチェック子の値と比較し、アクセス許諾チケット（Ticket１−１）を検証する。生成したチェック子の値がアクセス許諾チケット（Ticket１−１）に記述されるチェック子の値と一致しない場合、ファイルアクセス処理部３４は、アクセス許諾チケット（Ticket１−１）が不正である（改ざんされた）と判定し、このアクセス制御処理を強制終了し、アクセス許諾要求を拒否する。値が一致する場合、ファイルアクセス処理部３４は、アクセス許諾チケット（Ticket１−１）が正当であると判定し、認証する。
【０１７１】
チケットが正当であると言うことは、MAC値を生成するアクセス許諾チケット生成鍵を正しく生成していると言うことであり、それはつまり、第三のデータ、ルート鍵、アクセス方法に対する全てのアクセス制御鍵を知っている事業者がチケットを生成した蓋然性が高いということである。そしてそれは、正当な事業者が所有する情報処理端末であるということになる。
【０１７２】
従って、ファイルアクセス処理部３４は、アクセス許諾チケット（Ticket１−１）に従ったファイルへのアクセスを許可し、ステップＳ１１８において、その旨を通知する応答を、要求元の情報処理端末１１−１−１に供給する。
【０１７３】
情報処理端末１１−１−１の通信部２８は、ステップＳ１０２において、その応答を取得する。ファイルアクセス処理部２４は、アクセス許諾を得たアクセス方法に則りファイルにアクセスする。例えば、アクセス方法１−１がFile１に対するリード・ライト可、アクセス方法１−２がリードオンリーである場合、情報処理端末１１−１−１からICカード１２−１に対し、File１の読み出しコマンドは受け付けられても、書き換え命令は拒絶されることになる。このように、各ファイルに対してアクセス制御を複数設定することができ、多様な利用方法を安全に実現することが可能となる。
【０１７４】
次に、図２３のフローチャートを参照して、図２０のステップＳ１１５において実行されるアクセス許諾チケット生成鍵生成処理の流れの例を説明する。なお、以下においてはICカード１２−１において実行される場合について説明するが、以下の説明は、他のICカード１２において実行される場合も適用可能である。
【０１７５】
アクセス許諾チケット生成鍵生成処理が開始されると、アクセス許諾チケット生成鍵生成部４２は、ステップＳ１３１において、アクセス許諾チケット（Ticket１−１）に記述されているアクセスコードのリストを参照し、そのリストに含まれるアクセスコードに対応するアクセス制御鍵を記憶部３１−１より取得する。
【０１７６】
アクセス制御鍵を取得すると、アクセス許諾チケット生成鍵生成部４２は、ステップＳ１３２において、取得したアクセス制御鍵を、アクセス許諾チケット（Ticket１−１）に記述されているアクセスコードのリストと同順に整列させる。
【０１７７】
ステップＳ１３４において、アクセス許諾チケット生成鍵生成部４２は、取得したアクセス制御鍵の中に、未使用のアクセス制御鍵が存在するか否かを判定し、存在すると判定した場合、ステップＳ１３５に処理を進め、暗号化部３６を制御し、次の順のアクセス制御鍵を用いて前回の暗号化結果をさらに暗号化させる。なお、１回目の暗号化の場合、アクセス許諾チケット生成鍵生成部４２は、暗号化部３６を制御し、第四のデータ（System Data）を最初のアクセス制御鍵で暗号化させる。暗号化が終了すると、アクセス許諾チケット生成鍵生成部４２は、処理をステップＳ１３４に戻す。つまり、ステップＳ１３４およびステップＳ１３５を繰り返すことにより、アクセス許諾チケット生成鍵生成部４２は、取得したアクセス制御鍵の全てを、その整列順に縮退化してアクセス許諾チケット生成鍵を生成する。
【０１７８】
ステップＳ１３４において、未使用のアクセス制御鍵が存在しないと判定した場合、アクセス許諾チケット生成鍵生成部４２は、アクセス許諾チケット生成鍵生成処理を終了し、図２０のステップＳ１１５に処理を戻し、それ以降の処理を実行させる。
【０１７９】
このようにアクセス制御鍵を縮退化してアクセス許諾チケット生成鍵を生成することにより、ファイルアクセス処理部３４は、アクセス制御チケット（Ticket１−１）の検証をより正確かつ高速に行うことができる。つまり、ファイルへの複数のアクセス方法などを規定したアクセス許諾チケットに対し、複数の鍵を持って正当性検証を、１度の処理で行わせることができるようになり、セキュリティレベルの低下を防止するとともに、通信路を経由して複数回データの送受信を繰り返すことによる遅延を抑制し、高速に検証を行うことができる。
【０１８０】
なお、図２０のアクセス制御の処理において、ICカード１２−１のファイルアクセス処理部３４が、ステップＳ１１３において、アクセス許諾チケット（Ticket１−１）に記述されているアクセスコードが認証済みのディレクトリのものでない場合、許諾要求を拒否するように説明したが、これに限らず、アクセス許諾チケット（Ticket１−１）に記述されているアクセスコードが認証済みのディレクトリのものでない場合も構わず許諾するようにしてもよい。例えば、他事業者に自分の管理しているファイルにアクセスさせる必要があるような場合、アクセスを許諾する方が都合がよい。その場合、ステップＳ１１３の処理を省略すればよい。
【０１８１】
例えば、事業者１と事業者２があったとし、事業者１の管理するディレクトリに、顧客の名前などの個人情報を保持するファイルを持たせたとする。ある時、事業者１が事業者２と提携し、事業者１のお客には事業者２のサービスで便宜を図ってもらいたいとするなら、例えば、事業者１の顧客の名前を事業者２に読み出せるようにするのが好ましい。その場合、事業者２の情報処理端末１１が事業者１のディレクトリ内のデータにアクセスする必要が生じる。このとき、仮に、上述したように、アクセス許諾チケット（Ticket１−１）に記述されているアクセスコードが認証済みのディレクトリのものでない場合許諾要求が拒否されるとすると、相互認証時に事業者１のディレクトリを含めて相互認証しなければならないが、その場合、事業者１のディレクトリのアプリケーション鍵を生成するマスタ鍵を事業者２に教えなければならない。あるいは、事業者２の情報処理端末固有の鍵を生成する際に、事業者２に協力するか、事業者２の情報処理端末固有の鍵を作るために、事業者１のディレクトリ鍵を教える必要が生じる。
【０１８２】
より具体的な例を図２４に示す。図２４に示される情報処理端末１１−１−１は、事業者１の情報処理端末１１であり、情報処理端末１１−２−１は、事業者２の情報処理端末１１である。情報処理端末１１−１−１の記憶部２１−１−１には、情報処理端末１１−１−１のID（ID１−１）、情報処理端末１１−１−１固有の鍵（Ｋ１−１）、事業者１の情報処理端末１１のICカード１２用のマスタ鍵（MK１−１−ICおよびMK１−２−IC）、および情報処理端末１１−１−１に割り当てられたアクセス制御チケット（Ticket１−１）が書き込まれている。情報処理端末１１−２−１の記憶部２１−２−１には、情報処理端末１１−２−１のID（ID２−１）、情報処理端末１１−２−１固有の鍵（Ｋ２−１）、事業者２の情報処理端末１１のICカード１２用のマスタ鍵（MK２−２−IC）、および情報処理端末１１−２−１に割り当てられたアクセス制御チケット（Ticket２−１）が書き込まれている。
【０１８３】
アクセス制御チケット（Ticket２−１）には、このチケットの使用者のID（ID２−１）、アクセスコードのリスト（１−１−１，２−２−１）、および、チェック子（MAC）が記述されている。
【０１８４】
また、図２４に示されるICカード１２−１とICカード１２−２は、情報処理端末１１よりアクセスされる、ユーザが互いに異なるICカード１２である。
【０１８５】
ICカード１２−１の記憶部３１−１には、第一のデータ（ＫSystem）、第三のデータ（ＫSystem2）、およびルート鍵（ＫRoot）が書き込まれ、さらに、事業者１用のディレクトリとしてディレクトリ１−１およびディレクトリ１−２、事業者２用のディレクトリとしてディレクトリ２−２がそれぞれ形成されている。
【０１８６】
ディレクトリ１−１には、ディレクトリ鍵（DirK１−１）、アプリケーションID（AppID１−１−１）、およびアプリケーション鍵（AppＫ１−１−１）が書き込まれている。また、ディレクトリ１−１には、２つのアクセス制御鍵（ACK１−１−１およびACK１−１−２）が用意されている。ディレクトリ１−２には、ディレクトリ鍵（DirK１−２）、アプリケーションID（AppID１−２）、およびアプリケーション鍵（AppＫ１−２）が書き込まれている。また、ディレクトリ１−２には、２つのアクセス制御鍵（ACK１−２−１およびACK１−２−２）が用意されている。ディレクトリ２−２には、ディレクトリ鍵（DirK２−２）、アプリケーションID（AppID２−２−１）、およびアプリケーション鍵（AppＫ２−２−１）が書き込まれている。また、ディレクトリ２−２には、２つのアクセス制御鍵（ACK２−２−１およびACK２−２−２）が用意されている。
【０１８７】
ICカード１２−２の記憶部３１−２には、第一のデータ（ＫSystem）、第三のデータ（ＫSystem2）、およびルート鍵（ＫRoot）が書き込まれ、さらに、事業者１用のディレクトリとしてディレクトリ１−１、事業者２用のディレクトリとしてディレクトリ２−１およびディレクトリ２−２がそれぞれ形成されている。
【０１８８】
ディレクトリ１−１には、ディレクトリ鍵（DirK１−１）、アプリケーションID（AppID１−１−２）、およびアプリケーション鍵（AppＫ１−１−２）が書き込まれている。また、ディレクトリ１−１には、２つのアクセス制御鍵（ACK１−１−１およびACK１−１−２）が用意されている。ディレクトリ２−１には、ディレクトリ鍵（DirK２−１）、アプリケーションID（AppID２−１）、およびアプリケーション鍵（AppＫ２−１）が書き込まれている。また、ディレクトリ２−１には、２つのアクセス制御鍵（ACK２−１−１およびACK２−１−２）が用意されている。ディレクトリ２−２には、ディレクトリ鍵（DirK２−２）、アプリケーションID（AppID２−２−２）、およびアプリケーション鍵（AppＫ２−２−２）が書き込まれている。また、ディレクトリ２−２には、２つのアクセス制御鍵（ACK２−２−１およびACK２−２−２）が用意されている。
【０１８９】
このような例において、事業者２の情報処理端末１１−２−１が、図２４において矢印で示されるように、ICカード１２−１のディレクトリ１−１とディレクトリ２−２にアクセスするとする。
【０１９０】
事業者２（および事業者１）は、システム管理者から第二のデータと第四のデータの提示を受けている。事業者２が情報処理端末１１−２−１の鍵を設定する際には、情報処理端末１１用のマスタ鍵が必要であり、その情報処理端末１１用のマスタ鍵は、第二のデータを各ディレクトリ鍵で暗号化することにより得られる。つまり、相互認証において、ICカード１２−１のディレクトリ１−１とディレクトリ２−２にアクセスすることを認証してもらうためには、DirK１−１とDirK２−２が必要となる。そのためには、事業者１が事業者２にDirK１−１を教えるか、最初に、事業者２が第二のデータをDirK２−２で暗号化し、その暗号化出力を事業者１に提供し、事業者１によってその暗号化出力をDirK１−１で暗号化してもらうしかない。
【０１９１】
事業者１が事業者２にDirK１−１を教えるのは、ディレクトリ鍵の変更処理などが勝手になされる危険性があるため、セキュリティ上、事業者１にとって望ましくない。逆に、事業者２が暗号化出力を事業者１に提供する方法は、DirK２−２を教えたことにはならないが、その暗号化出力を教えているため、事業者２が運用する情報処理端末１１用のマスタ鍵を教えたことと略同義となってしまう。つまり、事業者１は、ディレクトリ２−２を含む情報処理端末１１用のマスタ鍵を生成し得ることになる。
【０１９２】
仮に、ディレクトリ鍵の問題が解決したとしても、事業者２の情報処理端末１１−２−１が事業者１の領域にアクセスするためには、事業者１のICカード１２用のマスタ鍵を知らなければならない。つまり、事業者１は、事業者２に対してMK１−１−ICを教えなければならない。
【０１９３】
以上から、相互認証において、情報処理端末１１−２−１が事業者１の領域へのアクセスを可能とするように、情報処理端末１１−２−１をICカード１２に認証させることは困難である。従って、ディレクトリ認証をパスしない領域にもアクセスすることができるようにしないと不都合が生じると考えられる。
【０１９４】
しかしながら、上述したように認証してない領域に無条件にアクセス可能とするのは論理上望ましくない。そこで、以下のように処理を行うようにしてもよい。
【０１９５】
まず、相互認証時において、事業者２の情報処理端末１１−２−１の記憶部２１−２−１には、ID２−１とK２−１が書き込まれている。Ｋ２−１を生成するマスタ鍵は、第二のデータをDirK２−２で暗号化して生成する。従って、相互認証はディレクトリ２−２だけで行うことになる。情報処理端末１１−２−１が送る相互認証開始コマンドには、ID２−１とディレクトリコード（Directory Code）である２−２と第一の乱数が添付される。
【０１９６】
これを受信したICカード１２−１は、第二のデータとDirK２−２とから情報処理端末１１−２−１固有の鍵を生成するマスタ鍵（MK２−１−IT）を生成する。このマスタ鍵（MK２−１−IT）とID２−１とからＫ２−１を生成する。そして、AppID２−２−１をＫ２−１で暗号化する（第一の返信文）。続けて、Ｋ２−１をAppK２−２−１で暗号化し、認証鍵（ＫAuth）を生成する。その後、ICカード１２−１は、第一の乱数、生成した第二の乱数、ID２−１を認証鍵で暗号化（第二の返信文）し、第一の返信文と共に情報処理端末１１−２−１に返信する。なお、このときの暗号化方法は、CBC（Cipher Block Chaining）モード等の暗号利用モードを用いることとする。
【０１９７】
第一の返信文および第二の返信文を受け取った情報処理端末１１−２−１は、自身の鍵Ｋ２−１で第一の返信文を復号し、AppID２−２−１を取り出す。そして、このAppID２−２−１とMK２−２−ICとから、AppK２−２−１を生成する。そして、自身の鍵Ｋ２−１をAppK２−２−１で暗号化し、認証鍵（ＫAuth）を生成する。さらに、その認証鍵（ＫAuth）で第二の返信文を復号し、第一の乱数の正当性を評価する。その後、セッション鍵を生成し、第一の乱数、第二の乱数と共に認証鍵（ＫAuth）で暗号化し、第二の相互認証コマンドに添付してICカード１２−１に送信する。
【０１９８】
これを受信したICカード１２−１は、乱数等を認証鍵（ＫAuth）で復号し、第二の乱数の正当性を評価し、レスポンスを返す。
【０１９９】
情報処理端末１１−２−１は、アクセス許諾チケット（Ticket２−１）を提示してファイルアクセス許可命令を発行する。これを受け取ったICカード１２−１は、使用者のチェック（Ticket２−１内のチケット使用者と、相互認証時に受け取った情報処理端末のID２−１の比較）後、アクセスコードをチェックする。アクセスコード２−２−１は相互認証時に検証したディレクトリだから認証されるが、アクセスコード１−１−１については検証していない。このような場合、ICカード１２−１（ファイルアクセス処理部３４のアクセス許諾チケット生成鍵生成部４２）が、アクセス許諾チケット生成鍵を作る際に、ディレクトリ鍵を含ませるようにする。
【０２００】
例えば、ICカード１２−１（ファイルアクセス処理部３４のアクセス許諾チケット生成鍵生成部４２）が、第四のデータをDirK１−１で暗号化した後、ACK１−１−１、ACK２−２−１で暗号化してアクセス許諾チケット生成鍵を生成するようにする。そして、ICカード１２−１（ファイルアクセス処理部３４のアクセス許諾チケット生成鍵生成部４２）は、このアクセス許諾チケット生成鍵でMAC値を検証し、正しければアクセスを許諾する。なお、アクセス許諾チケット生成鍵を生成するために、第四のデータをDirK１−１で暗号化するのは事業者１が行い、それをACK１−１−１で暗号化するのも事業者１が行う。その後、事業者２に引き渡し、ACK２−２−１で暗号化を行う。ただし、もっと多くのディレクトリが関与する場合、いろいろな事業者に鍵の中間値を引き渡す必要がある。
【０２０１】
このようにすることで、ICカード１２側としては、認証時にディレクトリの鍵は使っていなかったが、アクセス許諾チケットを検証する際に、必要なディレクトリの鍵の検証を間接的に行っているため、筋が通ることになる。なお、この例ではAppK１−１−１が使われていないが、アクセスチケット生成鍵を生成する際に、DirK１−１の後にAppK１−１−１を使用する（AppK１−１−１を用いて暗号化する）ようにしてもよい。
【０２０２】
なお、アクセスコード１−１−１とアクセスコード２−２−１にアクセスするアクセス許諾チケット生成鍵であるが、これを保有するものが事業者１の場合（つまり、事業者２が事業者１のために暗号化処理を行ってあげる場合）、事業者２のみが知り得るDirK２−２、ACK２−２−１を使ったアクセス許諾チケット生成鍵が事業者１に渡されることになる。ところが、DirK２−２、ACK２−２−１が教えられた訳ではない。また、上で説明したように、DirK２−２、ACK２−２−１は使われているが、AppK２−２―２は一切使用されていない。よって、このチケットを使って、勝手にディレクトリ２−２内の他のファイルにアクセスすることができないのである。つまり、事業者２からしてみると安全といえる。
【０２０３】
なお、上述した例では自身のディレクトリと他事業者のディレクトリを混載させていたが、わかりやすくするためにチケットを分けるようにしてもよい。つまり、認証済みの領域だけが入ったチケットと、認証が済んでいない領域（しかも、管理している事業者毎）だけが入ったチケットに分け、必要に応じてアクセス許諾命令を複数回出す。このようにすることで、アクセス許諾チケット生成鍵を生成する際に、途中結果をいろいろな人に引き渡す必要がなくなる。
【０２０４】
なお、以上においては、システム鍵を認証鍵用とアクセス許諾チケット生成鍵用の２種類用意するように説明した。上述したように、アクセス許諾チケット生成鍵を他事業者向けに生成する時、ディレクトリ鍵（DirK）を使用している。すると、第三のデータが第一のデータと同一であると、アクセス許諾チケット生成鍵生成過程において、情報処理端末１１のマスタ鍵生成過程と一部似ている状態が出てきてしまう。必ずACKを掛け合わせているものの、例えば、第四のデータをDirK１−１で事業者１が暗号化し、この中間値を事業者２に渡し、再度事業者１に渡してACK１−１−１で暗号化した後、再度事業者２に渡してACK２−２−１で暗号化する場合について想定する。このような場合において、仮に、第四のデータではなく、第二のデータであるとすると、事業者２は第二のデータをDir１−１で暗号化した出力を入手することができたことになり、この出力は、Dir1-1にアクセスする情報処理端末１１に対する個別鍵を生成するマスタ鍵であり、これを不正に入手できたことになってしまう。
【０２０５】
従って、そうならないためにも、必ずDirKのあとACKで暗号化するのが望ましい。また、マスタ鍵や認証鍵を生成する時の元データ（第一のデータ）と、アクセス許諾チケット生成鍵を生成する時の元データ（第三のデータ）を互いに異なるものにするのが望ましい（異なっていれば、認証系とチケット系でDirKをかけた出力が異なるので問題がなくなる）。
【０２０６】
なお、情報処理端末１１とICカード１２と間の通信の、通信可能範囲の広さは任意であり、例えば、数メートル以上であってもよいし、数センチメートル以下であってもよい。また、通信方式も任意であり、無線通信ではなく有線通信としてもよい。その場合、ICカードは所謂接触型のICカードであり、情報処理端末１１とICカード１２には、ループアンテナの代わりに、互いを電気的に接続するための外部接続端子が設けられる。
【０２０７】
また、以上においては、通信システム１の装置としてICカードと情報処理端末を例にして説明したが、互いに通信可能なデバイスなら何でもよい。例えば、ICカード１２は、カード形状のデバイスでなくてもよく、例えば、切手形状のものや、５００円玉形状のものでもよい。また、例えば、ICカード機能を搭載する携帯電話機、音楽プレーヤ、デジタルカメラ、ノート型パーソナルコンピュータ、またはPDA（Personal Digital Assistants）などであってもよい。さらに、例えばデスクトップ型のパーソナルコンピュータのように、携帯型デバイスでなくてもよい。また、ICカード１２は、ユーザ（人）が携帯するものであってもよいし、機器等に組み込まれ、その機器の移動処理などに活用するものであってもよい。
【０２０８】
同様に、情報処理端末１１も、上述した機能を有し、ICカード１２と通信可能なものであればどのようなデバイスであってもよい。例えば、自動改札機、自動販売機、施錠ドア等に組み込まれているリーダ・ライタ等であってもよいし、ノート型パーソナルコンピュータ、PDA、デスクトップ型のパーソナルコンピュータ等に組み込まれたカードアクセスポートや、USB（Universal Serial Bus）接続された簡易リーダ・ライタなどの他に、リーダ・ライタ機能を搭載した携帯電話機等でもよい。
【０２０９】
上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウエアにより実行させることもできる。この場合、例えば、図２５に示されるようなパーソナルコンピュータとして構成されるようにしてもよい。
【０２１０】
図２５において、パーソナルコンピュータ２００のCPU２０１は、ROM（Read Only Memory）２０２に記憶されているプログラム、または記憶部２１３からRAM（Random Access Memory）２０３にロードされたプログラムに従って各種の処理を実行する。RAM２０３にはまた、CPU２０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【０２１１】
CPU２０１、ROM２０２、およびRAM２０３は、バス２０４を介して相互に接続されている。このバス２０４にはまた、入出力インタフェース２１０も接続されている。
【０２１２】
入出力インタフェース２１０には、キーボード、マウスなどよりなる入力部２１１、CRT（Cathode Ray Tube）やLCD（Liquid Crystal Display）などよりなるディスプレイ、並びにスピーカなどよりなる出力部２１２、ハードディスクなどより構成される記憶部２１３、モデムなどより構成される通信部２１４が接続されている。通信部２１４は、インターネットを含むネットワークを介しての通信処理を行う。
【０２１３】
入出力インタフェース２１０にはまた、必要に応じてドライブ２１５が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア２２１が適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部２１３にインストールされる。
【０２１４】
上述した一連の処理をソフトウエアにより実行させる場合には、そのソフトウエアを構成するプログラムが、ネットワークや記録媒体からインストールされる。
【０２１５】
この記録媒体は、例えば、図２５に示されるように、装置本体とは別に、ユーザにプログラムを配信するために配布される、プログラムが記録されている磁気ディスク（フレキシブルディスクを含む）、光ディスク（CD-ROM（Compact Disc - Read Only Memory）,DVD（Digital Versatile Disc）を含む）、光磁気ディスク（MD（Mini Disc）を含む）、もしくは半導体メモリなどよりなるリムーバブルメディア１２１により構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに配信される、プログラムが記録されているROM２０２や、記憶部２１３に含まれるハードディスクなどで構成される。
【０２１６】
なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０２１７】
また、本明細書において、システムとは、複数のデバイス（装置）により構成される装置全体を表わすものである。
【０２１８】
なお、以上において、一つの装置として説明した構成を分割し、複数の装置として構成するようにしてもよい。逆に、以上において複数の装置として説明した構成をまとめて一つの装置として構成されるようにしてもよい。また、各装置の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置の構成の一部を他の装置の構成に含めるようにしてもよい。つまり、本発明の実施の形態は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。
【図面の簡単な説明】
【０２１９】
【図１】本発明を適用した通信システムの主な構成例を示すブロック図である。
【図２】各デバイスが保持する情報の例を示す図である。
【図３】ICカードの記憶部の記憶領域の構成例を説明する模式図である。
【図４】データ設定処理の流れの例を説明するフローチャートである。
【図５】データ列の構成例を示す図である。
【図６】データ列の構成例を示す図である。
【図７】データ列の構成例を示す図である。
【図８】データ列の構成例を示す図である。
【図９】データ列の構成例を示す図である。
【図１０】データ列の構成例を示す図である。
【図１１】相互認証処理の流れの例を説明するフローチャートである。
【図１２】相互認証処理の流れの例を説明する、図７に続くフローチャートである。
【図１３】認証処理部の詳細な構成例を説明する機能ブロック図である。
【図１４】認証処理部の詳細な構成例を説明する機能ブロック図である。
【図１５】認証処理部の詳細な構成例を説明する機能ブロック図である。
【図１６】認証処理部の詳細な構成例を説明する機能ブロック図である。
【図１７】マスタ鍵生成処理の流れの例を説明するフローチャートである。
【図１８】各デバイスが保持する情報の、他の例を示す図である。
【図１９】アクセス許諾チケットの記述例を示す模式図である。
【図２０】アクセス制御処理の流れ居の例を説明するフローチャートである。
【図２１】ファイルアクセス処理部の詳細な構成例を説明する機能ブロック図である。
【図２２】アクセス許諾チケット生成鍵生成部の詳細な構成例を説明する機能ブロック図である。
【図２３】アクセス許諾チケット生成鍵生成処理の流れ居の例を説明するフローチャートである。
【図２４】各デバイスが保持する情報の、さらに他の例を示す図である。
【図２５】本発明を適用したパーソナルコンピュータの構成例を示すブロック図である。
【符号の説明】
【０２２０】
１ 通信システム， １１ 情報処理端末， １２ ICカード， ２１ 記憶部， ２３ 認証処理部， ２４ ファイルアクセス処理部， ２５ 乱数生成部， ２６ 暗号化部， ２７ 復号部， ２８ 通信部， ３１ 記憶部， ３２ データ設定処理部， ３３ 認証処理部， ３４ ファイルアクセス処理部， ３５ 乱数生成部， ３６ 暗号化部， ３７ 復号部， ３８ 通信部， ４１ マスタ鍵生成部， ４２ アクセス許諾チケット生成鍵生成部
【技術分野】
【０００１】
本発明は、情報処理装置および方法、記録媒体、プログラム、並びに情報処理システムに関し、特に、安全かつ迅速に相互認証およびアクセス制御を行うことができるようにした情報処理装置および方法、記録媒体、プログラム、並びに情報処理システムに関する。
【背景技術】
【０００２】
近年、電子マネーに代表される、非接触IC（Integrated Circuit）カードが多方面で利用されるようになってきている。この非接触ICカードには、種々のアプリケーションが搭載されることが普通であり、それぞれ要求される情報セキュリティのレベルが異なっているのが普通である。そこで、必要の都度、アプリケーション毎にアクセス許諾チケットを提示してアクセス許諾を得て、そのアプリケーションに対応したファイルにアクセスする手法をとっている（例えば、特許文献１参照）。
【０００３】
【特許文献１】特開２００２−２８１０２３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来のアクセス許諾チケットにおいては、ファイルへのアクセス方法を複数種類指定することはできるものの、そのチケットが正当であるかどうかを判定するMAC（Message Authentication Code）値を計算するのに使う鍵が一つであるという問題点があった。つまり、各ファイルのアクセス方法に対して鍵を別々に設定してはいるものの、MACを計算するために使用する鍵は一つである。このため、チケットで正当性を判断しても、チェックできる鍵が一つということになり、結局はその鍵に対するファイルアクセス方法のみを判定しているに過ぎないという矛盾が残っていた。
【０００５】
本発明はこのような状況に鑑みてなされたものであり、安全かつ迅速に相互認証及びアクセス制御を行うことができるようにするものである。
【課題を解決するための手段】
【０００６】
本発明の第１の側面は、他の情報処理装置より、自分自身が保持するデータに対してアクセスを要求される情報処理装置であって、前記他の情報処理装置の認証処理を行う認証手段と、前記認証手段により正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信する受信手段と、予め保持する所定のデータ、ルートディレクトリに対応する鍵情報であるルート鍵、並びに、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成するアクセス許諾チケット生成鍵生成手段と、前記アクセス許諾チケット生成鍵生成手段により生成された前記アクセス許諾チケット生成鍵を用いて、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出するチェック子算出手段と、前記チェック子算出手段により算出された前記チェック子を用いて、前記受信手段により受信された前記アクセス許諾チケットを検証するアクセス許諾チケット検証手段とを備える情報処理装置である。
【０００７】
前記アクセス許諾チケットは、前記他の情報処理装置のIDをさらに含み、前記受信手段により受信された前記アクセス許諾チケットに記述される前記他の情報処理装置のIDが、前記認証手段により認証済みの他の情報処理装置のIDであるか否かを検証するID検証手段をさらに備えることができる。
【０００８】
所定のIDが特別なIDであるオールマイティIDとして予め設定されており、前記ID検証手段は、前記アクセス許諾チケットに前記オールマイティIDが記述されている場合、認証済みのIDの如何に関わらず、アクセス制御チケットの使用者を許諾させることができる。
【０００９】
前記アクセス許諾チケット生成鍵の生成に使用される前記所定のデータは、前記認証手段による認証処理において認証用の鍵情報の生成に用いられる所定のデータとは異なるデータとして予め保持することができる。
【００１０】
前記アクセス許諾チケットに記述されるアクセスコードが、前記認証処理においてアクセス先として認証されたディレクトリのアクセスコードであるか否かを確認する確認手段をさらに備えることができる。
【００１１】
前記確認手段により前記認証処理においてアクセス先として認証されていないディレクトリのアクセスコードが含まれることが確認された場合、アクセスを拒絶する拒絶手段をさらに備えることができる。
【００１２】
前記拒絶手段は、前記認証処理においてアクセス先として認証されていないディレクトリのアクセスコードについてのみアクセスを拒絶することができる。
【００１３】
前記アクセス許諾チケット生成鍵生成手段は、前記確認手段により前記認証処理においてアクセス先として認証されていない領域のアクセスコードが含まれることが確認された場合、前記アクセス許諾チケット生成鍵の生成において、さらに、前記アクセスコードに対応するディレクトリの鍵情報であるディレクトリ鍵を使用することができる。
【００１４】
前記アクセス許諾チケット生成鍵生成手段は、予め保持する前記所定のデータを前記ルート鍵で暗号化し、その暗号化結果をさらに各ディレクトリ鍵で１つずつ暗号化し、さらにその暗号化結果を、各アクセス制御鍵で１つずつ暗号化することにより、各鍵情報を縮退化して前記アクセス許諾チケット生成鍵を生成することができる。
【００１５】
本発明の第一の側面は、また、他の情報処理装置より、自分自身が保持するデータに対してアクセスを要求される情報処理装置の情報処理方法であって、前記他の情報処理装置の認証処理を行い、正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信し、予め保持する所定のデータ、ルートディレクトリに対応する鍵情報であるルート鍵、並びに、受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成し、生成された前記アクセス許諾チケット生成鍵を用いて、前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出し、算出された前記チェック子を用いて、前記アクセス許諾チケットを検証するステップを含む情報処理方法である。
【００１６】
本発明の第一の側面は、さらに、他の情報処理装置より、自分自身が保持するデータに対してアクセスを要求される情報処理装置を制御するプログラムであって、前記他の情報処理装置の認証処理を行い、正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信し、予め保持する所定のデータ、ルートディレクトリに対応する鍵情報であるルート鍵、並びに、受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成し、生成された前記アクセス許諾チケット生成鍵を用いて、前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出し、算出された前記チェック子を用いて、前記アクセス許諾チケットを検証するステップを含むコンピュータが読み取り可能なプログラムが記録されている記録媒体である。
【００１７】
本発明の第一の側面は、また、他の情報処理装置より、自分自身が保持するデータに対してアクセスを要求されるコンピュータに実行させるプログラムにおいて、前記他の情報処理装置の認証処理を行い、正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信し、予め保持する所定のデータ、ルートディレクトリに対応する鍵情報であるルート鍵、並びに、受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成し、生成された前記アクセス許諾チケット生成鍵を用いて、前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出し、算出された前記チェック子を用いて、前記アクセス許諾チケットを検証するステップを含む情報処理をコンピュータに実行させるプログラムである。
【００１８】
本発明の第二の側面は、第一の情報処理装置が、第二の情報処理装置が保持するデータに対してアクセスを要求する情報処理システムであって、前記第一の情報処理装置は、前記第二の情報処理装置と相互認証処理を行う第一の相互認証手段と、アクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを前記第二の情報処理装置に送信する送信手段とを備え、前記第二の情報処理装置は、前記第一の情報処理装置と相互認証処理を行う第二の相互認証手段と、前記第二の相互認証手段により正当な相手であると認証された前記第一の情報処理装置より、前記第一の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信する受信手段と、予め保持する所定のデータ、ルートディレクトリに対応する鍵情報であるルート鍵、並びに、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成するアクセス許諾チケット生成鍵生成手段と、前記アクセス許諾チケット生成鍵生成手段により生成された前記アクセス許諾チケット生成鍵を用いて、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出するチェック子算出手段と、前記チェック子算出手段により算出された前記チェック子を用いて、前記受信手段により受信された前記アクセス許諾チケットを検証するアクセス許諾チケット検証手段とを備える情報処理システムである。
【００１９】
本発明の第一の側面においては、他の情報処理装置の認証処理が行われ、正当な相手であると認証された他の情報処理装置より、他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットが受信され、予め保持する所定のデータ、ルートディレクトリに対応する鍵情報であるルート鍵、並びに、受信されたアクセス許諾チケットに記述されるアクセスコードに対応するデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵が使用されて、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵が生成され、生成されたアクセス許諾チケット生成鍵を用いて、アクセス許諾チケットに記述されるアクセスコードに対応するチェック子が算出され、算出されたチェック子を用いて、アクセス許諾チケットが検証される。
【００２０】
本発明の第二の側面においては、第一の情報処理装置において、第二の情報処理装置と相互認証処理が行われ、アクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットが第二の情報処理装置に送信され、第二の情報処理装置において、第一の情報処理装置と相互認証処理が行われ、正当な相手であると認証された第一の情報処理装置より、第一の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットが受信され、予め保持する所定のデータ、ルートディレクトリに対応する鍵情報であるルート鍵、並びに、受信されたアクセス許諾チケットに記述されるアクセスコードに対応するデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵が使用されて、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵が生成され、その生成されたアクセス許諾チケット生成鍵を用いて、アクセス許諾チケットに記述されるアクセスコードに対応するチェック子が算出され、その算出されたチェック子を用いて、アクセス許諾チケットが検証される。
【発明の効果】
【００２１】
本発明によれば、認証処理およびアクセス制御を行うことができる。特に、安全かつ迅速に相互認証およびアクセス制御を行うことができる。
【発明を実施するための最良の形態】
【００２２】
以下に本発明の実施の形態を説明するが、本発明の構成要件と、明細書または図面に記載の実施の形態との対応関係を例示すると、次のようになる。この記載は、本発明をサポートする実施の形態が、明細書または図面に記載されていることを確認するためのものである。従って、明細書または図面中には記載されているが、本発明の構成要件に対応する実施の形態として、ここには記載されていない実施の形態があったとしても、そのことは、その実施の形態が、その構成要件に対応するものではないことを意味するものではない。逆に、実施の形態が構成要件に対応するものとしてここに記載されていたとしても、そのことは、その実施の形態が、その構成要件以外の構成要件には対応しないものであることを意味するものでもない。
【００２３】
本発明の第１の側面は、他の情報処理装置（例えば、図１の情報処理端末１１）より、自分自身が保持するデータに対してアクセスを要求される情報処理装置（例えば、図１のICカード１２）であって、前記他の情報処理装置の認証処理を行う認証手段（例えば、図１の認証処理部３３）と、前記認証手段により正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信する受信手段（例えば、図２０のステップＳ１１１の処理を行う図１の通信部３８）と、予め保持する所定のデータ、ルートディレクトリに対応する鍵情報であるルート鍵、並びに、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成するアクセス許諾チケット生成鍵生成手段（例えば、図２０のステップＳ１１５の処理を行う図１のアクセス許諾チケット生成鍵生成部４２）と、前記アクセス許諾チケット生成鍵生成手段により生成された前記アクセス許諾チケット生成鍵を用いて、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出するチェック子算出手段（例えば、図２０のステップＳ１１６の処理を行う図１のファイルアクセス処理部３４）と、前記チェック子算出手段により算出された前記チェック子を用いて、前記受信手段により受信された前記アクセス許諾チケットを検証するアクセス許諾チケット検証手段（例えば、図２０のステップＳ１１７の処理を行う図１のファイルアクセス処理部３４）とを備える。
【００２４】
前記アクセス許諾チケットは、前記他の情報処理装置のIDをさらに含み、前記受信手段により受信された前記アクセス許諾チケットに記述される前記他の情報処理装置のIDが、前記認証手段により認証済みの他の情報処理装置のIDであるか否かを検証するID検証手段（例えば、図２０のステップＳ１１２の処理を行う図１のファイルアクセス処理部３４）をさらに備えることができる。
【００２５】
前記アクセス許諾チケット生成鍵の生成に使用される前記所定のデータ（例えば、図１８の第三のデータ）は、前記認証手段による認証処理において認証用の鍵情報の生成に用いられる所定のデータ（例えば、図１８の第一のデータ）とは異なるデータとして予め保持することができる。
【００２６】
前記アクセス許諾チケットに記述されるアクセスコードが、前記認証処理においてアクセス先として認証されたディレクトリのアクセスコードであるか否かを確認する確認手段（例えば、図２０のステップＳ１１３の処理を行う図１のファイルアクセス処理部３４）をさらに備えることができる。
【００２７】
本発明の第一の側面は、また、他の情報処理装置（例えば、図１の情報処理端末１１）より、自分自身が保持するデータに対してアクセスを要求される情報処理装置（例えば、図１のICカード１２）の情報処理方法、記録媒体、またはプログラムであって、前記他の情報処理装置の認証処理を行い（例えば、図１１および図１２の認証処理）、正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信し（例えば、図２０のステップＳ１１１）、予め保持する所定のデータ、ルートディレクトリに対応する鍵情報であるルート鍵、並びに、受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成し（例えば、図２０のステップＳ１１５）、生成された前記アクセス許諾チケット生成鍵を用いて、前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出し（例えば、図２０のステップＳ１１６）、算出された前記チェック子を用いて、前記アクセス許諾チケットを検証する（例えば、図２０のステップＳ１１７）ステップを含む。
【００２８】
以下、本発明の実施の形態について説明する。
【００２９】
図１は、本発明を適用した通信システムの主な構成例を示すブロック図である。
【００３０】
図１に示される通信システム１は、通信機能を有する情報処理端末１１およびIC（Integrated Circuit）カード１２の２つのデバイスよりなり、情報処理端末１１とICカード１２が互いに通信を行い、情報を授受するシステムである。情報処理端末１１は、例えば改札機や自動販売機等のような、ICカード１２のリーダ・ライタ機能を有する情報処理装置であり、ICカード１２に情報を供給して記憶させたり、ICカード１２に記憶されている情報を読み出したりする。ICカード１２は、例えば不揮発性メモリや通信回路を内蔵するICチップやループアンテナ等が埋め込まれたカード型のデバイスであり、情報処理端末１１と、通信可能範囲が約１０cm程度の近距離無線通信を行い、情報の授受を行う、所謂、非接触型のICカードである。
【００３１】
図１に示されるように、情報処理端末１１は、記憶部２１、認証処理部２３、ファイルアクセス処理部２４、乱数生成部２５、暗号化部２６、復号部２７、および通信部２８の機能ブロックを有する。記憶部２１は、例えばフラッシュメモリやハードディスク等の不揮発性のメモリデバイスよりなり、IDや暗号化用の鍵情報等各種情報を記憶する。認証処理部２３は、例えばCPU（Central Processing Unit）等の演算処理デバイスよりなり、情報処理端末１１とICカード１２との通信を開始する際に互いを認証させる認証処理を行う。ファイルアクセス処理部２４は、例えばCPU等の演算処理デバイスよりなり、相互認証を行ったICカード１２に対して、ファイルへのアクセス許諾を求める処理を行う。乱数生成部２５は、例えばCPU等の演算処理デバイスよりなり、認証処理等に必要な乱数を生成する。暗号化部２６は、例えばCPU等の演算処理デバイスよりなり、通信部２８を介してICカード１２に供給する情報を必要に応じて暗号化する。復号部２７は、例えばCPU等の演算処理デバイスよりなり、通信部２８を介してICカード１２より供給された、暗号化された情報を必要に応じて復号する。通信部２８は、例えば、通信回路等を含むICチップやループアンテナ等よりなり、通信可能範囲内に位置するICカード１２との近距離無線通信を行い、情報を授受する。もちろん、情報処理端末１１がこれら以外の機能ブロックを有していてもよい。
【００３２】
なお、図１においては矢印の記載を省略しているが、認証処理部２３およびファイルアクセス処理部２４は、乱数生成部２５、暗号化部２６、および復号部２７とも情報の授受を適宜行う。
【００３３】
ICカード１２は、記憶部３１、データ設定処理部３２、認証処理部３３、ファイルアクセス処理部３４、乱数生成部３５、暗号化部３６、復号部３７、および通信部３８の機能ブロックを有する。記憶部３１は、例えばフラッシュメモリやハードディスク等の不揮発性のメモリデバイスよりなり、情報処理端末１１等外部の機器より供給される情報等、各種情報を記憶する。データ設定処理部３２は、例えばCPU等の演算処理デバイスよりなり、ICカード１２の外部の機器より供給される命令や情報等に基づいて、記憶部３１の記憶領域にディレクトリやファイルを作成したり、鍵情報やID等の設定情報を書き込んだりするデータ設定処理を行う。認証処理部３３は、例えばCPU等の演算処理デバイスよりなり、情報処理端末１１とICカード１２との通信を開始する際に互いを認証させる認証処理を行う。認証処理部３３は、情報処理端末１１固有の鍵を生成する情報処理端末１１用のマスタ鍵を生成するマスタ鍵生成部４１を有する。ファイルアクセス処理部３４は、例えばCPU等の演算処理デバイスよりなり、情報処理端末１１による記憶部３１に書き込まれているファイルへのアクセスの制御に関する処理を行う。ファイルアクセス処理部３４は、情報処理端末１１より供給されるアクセス許諾チケットの検証を行うために、そのアクセス許諾チケットと同様の情報を作成可能な鍵情報であるアクセス許諾チケット生成鍵を生成するアクセス許諾チケット生成鍵生成部４２を有する。乱数生成部３５は、例えばCPU等の演算処理デバイスよりなり、認証処理等に必要な乱数を生成する。暗号化部３６は、例えばCPU等の演算処理デバイスよりなり、通信部３８を介して情報処理端末１１に供給する情報を必要に応じて暗号化する。復号部３７は、例えばCPU等の演算処理デバイスよりなり、通信部３８を介して情報処理端末１１より供給された、暗号化された情報を必要に応じて復号する。通信部３８は、例えば、通信回路等を含むICチップやループアンテナ等よりなり、通信可能範囲内に位置する情報処理端末１１との近距離無線通信を行い、情報を授受する。もちろん、ICカード１２がこれら以外の機能ブロックを有していてもよい。
【００３４】
なお、図１においては矢印の記載を省略しているが、データ設定処理部３２、認証処理部３３、およびファイルアクセス処理部３４は、それぞれ、乱数生成部３５、暗号化部３６、および復号部３７とも情報の授受を適宜行う。
【００３５】
以上の通信システム１に関わる存在（エンティティ）について説明する。以下においては、ICカード１２をユーザに提供する（あるいは販売し、管理する）エンティティをシステム管理者と称し、そのシステム管理者の許諾を得て、ICカード１２の記憶部３１の記憶領域の中にディレクトリを生成し、サービスを提供するエンティティを事業者と称する。当然、システム管理者も一事業者となり得る。
【００３６】
システム管理者は、ICカード１２に第一のデータと、ルートディレクトリを管理する鍵情報であるルート鍵を書き込み、ユーザにICカード１２を提供する。従って、同一のシステム管理者配下のICカード１２の記憶部３１には、全て同じ第一のデータおよびルート鍵が書かれている。換言するに、互いに異なるシステム管理者のICカードには、互いに異なる第一のデータおよびルート鍵がそれぞれ記憶される。
【００３７】
次に、情報処理端末１１およびICカード１２の間で行われる相互認証について説明する。図２は、情報処理端末１１の記憶部２１、および、ICカード１２の記憶部３１に記憶される、相互認証処理に関する情報の例を示す図である。
【００３８】
図２に示される例においては、通信システム１は、３台の情報処理端末１１と２枚のICカード１２により構成される。通信システム１を提供するシステム管理者（企業や団体等も含む）は１人（１社または１団体等）存在し（つまり、唯一のシステム管理者が存在し）、通信システム１を用いたサービスを提供する事業者（企業や団体等も含む）は２人（２社または２団体）存在し（つまり、２単位の事業者が存在し）、通信システム１を用いたサービスを享受するユーザは２人（２社または２団体）存在する（つまり、２単位のユーザが存在する）。事業者１は、情報処理端末１１−１−１および情報処理端末１１−１−２を所有し、事業者２は、情報処理端末１１−２−１を所有する。ICカード１２−１は、図示せぬ一方のユーザにより所有され、ICカード１２−２は、図示せぬ他方のユーザにより所有される。なお、情報処理端末１１−１−１、情報処理端末１１−１−２、および情報処理端末１１−２−１を互いに区別して説明する必要の無い場合、単に情報処理端末１１と称する。同様に、ICカード１２−１およびICカード１２−２を互いに区別して説明する必要の無い場合、単にICカード１２と称する。
【００３９】
システム管理者は、例えば出荷時に、ICカード１２−１の記憶部３１−１に第一のデータ（KSystem）とルート鍵（KRoot）を書き込む。同様に、システム管理者は、例えば出荷時に、ICカード１２−２の記憶部３１−２に第一のデータ（KSystem）とルート鍵（KRoot）を書き込む。
【００４０】
事業者１は、システム管理者の許諾を得てICカード１２−１の記憶部３１−１に、提供するサービス毎にディレクトリ（ディレクトリ１−１、ディレクトリ１−２、ディレクトリ１−３、およびディレクトリ１−３−２）を作成する。なお、本例ではディレクトリ１−３にはアクセスしないこととする。また、ディレクトリ１−３−２はディレクトリ１−３の下にある下位ディレクトリである（つまり、ルート直下ではない）。
【００４１】
同様に、事業者２は、システム管理者の許諾を得てICカード１２−２の記憶部３１−２に、提供するサービス毎にディレクトリ（ディレクトリ２−１、ディレクトリ２−２、ディレクトリ２−３、およびディレクトリ２−３−２）を作成する。なお、本例ではディレクトリ２−３にはアクセスしないこととする。また、ディレクトリ２−３−２はディレクトリ２−３の下にある下位ディレクトリである（つまり、ルート直下ではない）。
【００４２】
ディレクトリを作成する際、事業者は、そのサービスのディレクトリを管理する、サービス毎の鍵情報であるディレクトリ鍵（DirK）、そのICカード１２のそのディレクトリを識別するためのアプリケーションID（AppID）と、そのICカード１２のそのディレクトリを管理する鍵情報であるアプリケーション鍵（AppK）を、そのディレクトリに書き込む。
【００４３】
例えば、事業者１は、ディレクトリ１−１を作成すると、そのディレクトリ１−１に、ディレクトリ鍵（DirK１−１）、アプリケーションID（AppID１−１）、およびアプリケーション鍵（AppK１−１）を書き込む。同様に、事業者１は、ディレクトリ１−２を作成すると、そのディレクトリ１−２に、ディレクトリ鍵（DirK１−２）、アプリケーションID（AppID１−２）、およびアプリケーション鍵（AppK１−２）を書き込む。
【００４４】
同様に、事業者２は、ディレクトリ２−１を作成すると、そのディレクトリ２−１に、ディレクトリ鍵（DirK２−１）、アプリケーションID（AppID２−１）、およびアプリケーション鍵（AppK２−１）を書き込む。同様に、事業者２は、ディレクトリ２−２を作成すると、そのディレクトリ２−２に、ディレクトリ鍵（DirK２−２）、アプリケーションID（AppID２−２）、およびアプリケーション鍵（AppK２−２）を書き込む。
【００４５】
ディレクトリ鍵DirKの場合、書き込み先のICカード１２が異なっていても（つまり、異なるユーザが持つカードという意味）（例えば、ICカード１２−１の場合も、ICカード１２−２の場合も）、提供されるサービスが同一のディレクトリであれば、互いに同一の鍵が書き込まれる。これに対して、アプリケーションID（AppID）やアプリケーション鍵（AppK）の場合、サービスが同一のディレクトリであってもICカードが異なれば値が異なる。
【００４６】
また、例えば、ディレクトリ１−１のアプリケーション鍵AppK１−１は、情報処理端末１１−１−１の記憶部２１−１−１に保持されているマスタ鍵MK１−ICとアプリケーションID（AppID１−１）から生成できるものとする。つまり、ここには図示されていないが、事業者１が他のICカード１２（つまり、異なるユーザが持つカードという意味）に生成するディレクトリには、異なるアプリケーションID（AppID）（これがユーザIDとなる）とアプリケーション鍵（AppK）が書き込まれる。ただし、ディレクトリ鍵（DirK）は共通である。
【００４７】
同様に、事業者２によって各ディレクトリにディレクトリ鍵（DirK）、アプリケーションID（AppID）、およびアプリケーション鍵（AppK）が書き込まれる。
【００４８】
情報処理端末１１−１−１の記憶部２１−１−１には、情報処理端末１１−１−１固有の識別情報（ID１−１）、情報処理端末１１−１−１固有の鍵（K１−１）、ICカード１２−１の記憶部３１−１に記憶されるアプリケーション鍵（AppK）を生成するためのマスタ鍵（MK１−IC）が書き込まれている。この鍵は、事業者毎に異なるだけであるため、同一事業者内では同じ鍵となる。なお、マスタ鍵をディレクトリ毎に変えるようにしても良い（本例では、事業者につき固有としている）。その場合、アクセスするディレクトリ分のマスタ鍵を保持している必要がある。
【００４９】
同様に、情報処理端末１１−１−２の記憶部２１−１−２には、情報処理端末１１−１−２固有の識別情報（ID１−２）、情報処理端末１１−１−２固有の鍵（K１−２）、ICカード１２−１の記憶部（３１−１）に記憶されるアプリケーション鍵（AppK）を生成するためのマスタ鍵（MK１−IC）が書き込まれている。同様に、情報処理端末１１−２−１の記憶部２１−２−１には、情報処理端末１１−２−１固有の識別情報（ID２−１）、情報処理端末１１−２−１固有の鍵（K２−１）、ICカード１２−２の記憶部３１−２に記憶されるアプリケーション鍵（AppK）を生成するためのマスタ鍵（MK２−IC）が書き込まれている。
【００５０】
次に、ICカード１２の記憶部３１内に記憶されるデータの具体的な構成例を説明する。
【００５１】
図３は、記憶部３１の記憶領域内に書き込まれる情報の構成例（アドレスマップ）を示す図である。
【００５２】
図３において、まず、１ブロックのバイト数であるが、鍵長が１６バイト以上になることに伴い、３２バイトを想定している。もちろん、鍵長を８バイトとして、１ブロックを１６バイトとしてもよいし、１ブロックを６４バイトとしてもよい。記憶部３１には、鍵データ等のシステムデータが、メモリの上位アドレスから書き込まれる。逆に、ユーザデータは下位アドレスから書き込まれる。結果として、記憶部３１の中央領域が常に空き領域となるようになる。これらのデータを保持するICチップ（記憶部３１を含むICチップ）を、以降セキュリティICと呼称する。
【００５３】
記憶部３１の論理アドレスFFFFhのブロック（３２バイト）には、デバイスID（Device ID）と、デバイスパラメータ（Device Parameter）が記憶される。デバイスID（Device ID）は、デバイス固有のID、すなわちICカード１２のIDを示す。このデータは、ICベンダーによって書き込まれるか、システム管理者によって書き込まれる。このデータは、所定の手続きを取らない限り読み出すことができないようになされており、通常のアプリケーションでは使用することができない。これにより、プライバシー等の侵害を防ぐことが期待される。また、デバイスパラメータ（Device Parameter）は、返答時間など、種々のパラメータを規定する。
【００５４】
各ブロックの先頭の２バイト（FF FFhとFF FEh）は、それぞれ、ブロック種別を規定するデータである。この先頭の２バイトがFF FFhまたはFF FEhで始まるシステムブロック（論理アドレスFFFEhおよび論理アドレスFFFDhの２ブロック）は、システム管理者によって記憶部３１に最初に割り当てられ、システム全体を管理する鍵情報であるシステム鍵（System Key）の情報を格納している。このシステム鍵（System Key）はシステムデータ（System Data）を生成するための元になるデータである認証鍵用（System Key for Authentication）（後述する第一のデータ）とアクセス許諾チケット生成鍵用（System Key for Access Control Ticket）（後述する第三のデータ）の２つが設けられる。なお、このシステム鍵は、いずれか一方のみを設定し、その一方を用いて所定のロジックによって他方が生成されるようにしてもよいし、両者を同一としても良い。
【００５５】
この２ブロックに含まれるキーフォーマット（Key Format）は、システム鍵（System Key）を暗号鍵として使用する場合の共通鍵暗号アルゴリズム／鍵長を規定するものであり、システム鍵（System Key）をデータとして使用する場合には適応しない。また、キーバージョン（Key Version）は、そのブロックのシステム鍵（System Key）のバージョン情報を示す。
【００５６】
先頭の２バイトが00 00hで始まるシステムブロックは、ルートディレクトリ（Root Directory）の情報を格納している。３バイト目乃至６バイト目（00 00 00 00h）は、ルートディレクトリ（Root Directory）のディレクトリコード（Directory Code）（Directoryの名前）を示している。スタートアドレス（Start Address）は、通常00 00hから始まり、エンドアドレス（End Address）は、システムブロックの１つ手前を表す。なお、このアドレスは物理アドレスではなく、論理ブロック番号に該当する。トータルブロック数（Total Block）は、スタートアドレス（Start Address）とエンドアドレス（End Address）から計算できるため必要性はないが、メモリ上は確保しておく。キーフォーマット（Key Format）は、使用される共通鍵暗号アルゴリズム／鍵長を規定するもので、他の領域に保存されている共通鍵全てに適応する。キーバージョン（Key Version）は、ルート鍵（Root Directory Symmetric Key）の鍵のバージョンを示す。
【００５７】
先頭の２バイトが00 01hで始まるシステムブロックは、下位にサブディレクトリ（Sub-Directory）を構成することが可能なディレクトリ（Directory）に関する情報を格納し、先頭の２バイトが00 02hで始まるシステムブロックは、下位にサブディレクトリ（Sub-Directory）を構成することが不可能なディレクトリ（Directory）に関する情報を格納する。これらのシステムブロックのディレクトリコード（Directory Code）は、このディレクトリ（Directory）の名前を示し、他のコード（Code）と異なっている必要がある。ただし、このコード（Code）に値「FF FF FF FFh」および「00 00 00 00h」は使用することができないようになされている。また、これらのシステムブロックのスタートアドレス（Start Address）とエンドアドレス（End Address）は、上述したルートディレクトリ（Root Directory）に関するシステムブロックの場合と同様である。２回目に出てくるディレクトリコード（Directory Code）は、親ディレクトリのディレクトリコード（Directory Code）を示す。通常は、ルートディレクトリ（Root Directory）に属するため、このディレクトリコードには「00 00 00 00h」が書き込まれるが、それより下段のディレクトリでは、親ディレクトリのディレクトリコードが記述される。また、これらのシステムブロックのキーバージョン（Key Version）は、上述したルートディレクトリ（Root Directory）に関するシステムブロックの場合と同様である。先頭の２バイトが00 01hで始まるシステムブロックのディレクトリ鍵（Directory Symmetric Key with Sub-Directory）は、下位にサブディレクトリ（Sub-Directory）を構成することが可能なディレクトリ（Directory）のディレクトリ鍵のことである。また、先頭の２バイトが00 02hで始まるシステムブロックのディレクトリ鍵（Directory Symmetric Key without Sub-Directory）は、下位にサブディレクトリ（Sub-Directory）を構成することが不可能なディレクトリ（Directory）のディレクトリ鍵のことである。
【００５８】
先頭の２バイトが00 FFhで始まるシステムブロックは、ディレクトリ（Directory）に対するアプリケーション情報（Application Information）を示している。このシステムブロックのアプリケーションID（Application ID）は、そのディレクトリ（Directory）を管理する事業者がICカード１２に割り振った識別情報（ID）を示し、アプリケーション鍵（Application Symmetric Key）は、アプリケーションID（Application ID）とマスタ鍵（Master Application Key）とから算出される鍵を示す。またディレクトリコード（Directory Code）は、このアプリケーション情報（Application Information）に対応するディレクトリコード（Directory Code）を示す。
【００５９】
先頭の２バイト（ブロック種別）が01 00h乃至FE FFhの場合、それらの値はアクセスモード（Access Mode）、すなわち、ファイル（File）へのアクセス方法を示している。このブロックのアクセスコード（Access Code）はファイル（File）の名前を示している。ただし、他のコード（Code）と値が異なっている必要がある。また、このブロックのスタートアドレス（Start Address）とエンドアドレス（End Address）は、上述したルートディレクトリ（Root Directory）に関するシステムブロックの場合と同様である。このブロックのディレクトリコード（Directory Code）は、アクセス対象のファイル（File）が所属するディレクトリ（Directory）の名前を示す。さらに、このブロックのキーバージョン（Key Version）の値が「FF FFh」以外である場合、アクセス制御のための鍵であるアクセス制御鍵（Access Control Symmetric Key）が有効である。これに対して、キーバージョン（Key Version）の値が「FF FFh」である場合、このブロックの鍵情報、すなわちアクセス制御鍵（Access Control Symmetric Key）が無効である。つまり、キーバージョン（Key Version）の値が「FF FFh」であることは、暗号処理機能を使用しないことを示す。
【００６０】
なお、先頭の２バイトが00 FEhで始まるシステムブロックを、リボケーションリスト（Revocation List）とすることができる。この時、通常は鍵が書かれている領域にリボーク（Revoke）される情報処理端末のIDを記載する。
【００６１】
次に、このようなセキュリティIC内部のデータ（記憶部３１に書き込まれるデータ）の設定方法を規定する。このデータ設定を行うデータ設定処理の流れの例を図４のフローチャートを参照して説明する。必要に応じて図５および図６を参照して説明する。
【００６２】
ステップＳ１において、データ設定処理部３２は、チップベンダ（ICカード１２を作成する製品製造メーカを含む）より指示を受けると、記憶部３１の記憶領域を初期化する。つまり、チップ製造直後、チップベンダは、ICカード１２以外のデバイス（例えば、セキュリティIC検査装置など）を用いて全てのメモリデータをFFhに初期化するようセキュリティICに要求する。その後、このセキュリティICを組み込んだICカードを製造する。
【００６３】
ステップＳ２において、データ設定処理部３２は、チップベンダの指示（特別なコマンド）に基づいて、ICカード１２の外部の装置より供給されるデバイスIDおよびパラメータを記憶部３１に書き込む。なお、デバイスIDおよびパラメータの書き込みは、記憶部３１の全てのメモリエリアがFFh（もしくは、デバイスID（Device ID）およびパラメータ（Device Parameter）の領域のみがFFh）である場合のみ可能である。なお、この時点では値の読み出し（特別なコマンド）は自由に行えるようにしておく。また、何度でも変更ができるようにしておく。さらに、変更する場合には、上記書き込みシーケンスと同様のものを用い、それによって、以前のデータは消去され、上書きされるものとする。また、もしデバイスID（Device ID）およびパラメータ（Device Parameter）の領域のみがFFhであった場合、データ設定処理部３２は、ここで他の領域をFFhに初期化する。
【００６４】
ステップＳ３において、データ設定処理部３２は、システム管理者の指示に基づいてICカード１２の外部の装置より供給されるシステム鍵を記憶部３１に書き込む。なお、システム管理者がシステム管理者固有のシステム鍵（System Key）を書き込むために、チップベンダは、出荷時に仮のシステム鍵を記憶部３１に書き込む。このシステム鍵の書き込みは、デバイスID（Device ID）とパラメータ（Device Parameter）が書き込まれていることが条件となっている。また、通常の場合、システム鍵（System Key）の書き込みは一度しか行えず、書き替えるためには所定の変更手順に従って行う必要がある。ただし、その場合も、システム鍵（System Key）を書き替えるためには、デバイスID（Device ID）、パラメータ（Device Parameter）が書き込まれていること、およびシステム鍵（System Key）領域以外のデータが初期化されている（FFｈになっている）ことが条件となる。また、この更新に使う、古いシステム鍵の暗号方式は、メモリに書き込まれているキーフォーマット（Key Format）に従う。キーフォーマット（Key Format）には、暗号アルゴリズムや鍵ビット長の他に、例えば、所定の値をExor（排他的論理和）してから暗号化する、所定回数の暗号化を繰り返す、１回だけ暗号化する等といった暗号方法が記述されている。
【００６５】
これ以降の書き込み処理が進んだ状態においては、システム鍵（System Key）の変更は一切できないようになされている。実際の書き込み方法は、外部から所定のフォーマットに従ったデータをセキュリティICに送り込み、それに基づいてシステム鍵（System Key）、システムコード（System Code）、キーフォーマット（Key Format）、およびキーバージョン（Key Version）を書き込ませる。書き込みシーケンスは、上述したデバイスIDおよびパラメータの場合と同様であるが、適宜最適な方法を設定して良い。なお、このときの送信データは暗号化されていない。
【００６６】
ステップＳ４において、データ設定処理部３２は、システム管理者の指示に基づいて、ICカード１２の外部の装置より供給されるルート鍵を記憶部３１に書き込む。なお、このルート鍵（Root Key）の書き込みは、システム鍵（System Key）が書き込まれている場合のみ可能である。これは、ルート鍵（Root Key）の初期書き込みには、システム鍵（System Key）が使用されるからである。実際の書き込み方法は、ICカード１２の外部の装置から所定のフォーマットに従ったデータをICカード１２のセキュリティICに送り込み、それに基づいてルート鍵（Root Key）を書き込ませる。コマンドは上述した他のステップの場合と同じであるが、図５に示されるように、コマンドに含まれるデータ列５１は、システム鍵（System Key）で暗号化したルート鍵（Root Key）を含む。暗号化方法は、システム鍵（System Key）のキーフォーマット（Key Format）に従うものとする。なお、ルート鍵（Root Key）を更新する場合には、更新される前のルート鍵（Root Key）だけが必要となる。つまり、ルート鍵（Root Key）の更新時にはシステム鍵（System Key）は（鍵としては）使用されない。
【００６７】
ここまでの処理は、システム管理者またはチップベンダ等が指示することになっていることと、ここまで処理が進まない間は、これを組み込んだ製品そのものが動作しないことから、比較的安全なところで処理が行えることが期待できる（仮に、ルート鍵（Root Key）を未実装で製品に組み込む場合も、その後、安全な場所でルート鍵（Root Key）の書き込みを確実に行うことができるものとする）。このため、鍵の書き込みメカニズムは比較的簡易にしてある。
【００６８】
ステップＳ５において、ディレクトリを作成したい事業者は、システム管理者に依頼してディレクトリ生成チケットを作成してもらう。このディレクトリ生成チケットには、ディレクトリ情報及びアプリケーション情報を設定するのに必要なデータをルート鍵で暗号化したものと、システム鍵（System Key）を用いて生成されたICV（Integrity Check Value）が含まれている。このようになされる理由は、この時点では相互認証ができないことと、システム管理者の許諾なく、ルート直下にディレクトリを作成させないためである。なお、キーバージョン（Key Version）は00 00hとされ、ディレクトリ鍵（DirectoryKey）、アプリケーションID（Application ID）及びアプリケーション鍵（Application Key）は固定データとなる。必要に応じてステップＳ７で事業者が書き換えるものとする。
【００６９】
ステップＳ６において、サービスを提供したい事業者は、ステップＳ５でシステム管理者が生成したディレクトリ生成チケットを受領し、このディレクトリ生成チケットをデータ設定処理部３２に送ってディレクトリを仮作成する。これにより、自身のサービスを提供するためのディレクトリがICカード１２に仮作成される。
【００７０】
データ設定処理部３２は、受領したディレクトリ生成チケットのICVをシステム鍵で検証し、ICVが正当か否かを判定する。正当でないと判定された場合には、ディレクトリの生成は行われない。ICVが正当と判断された場合、ディレクトリ生成チケットに書かれているディレクトリ情報及びアプリケーション情報をルート鍵で復号化し、これらのデータを記憶部３１に書き込む。
【００７１】
ステップＳ７において、サービスを提供したい事業者は、仮作成されたディレクトリの内、必要な情報（ディレクトリ鍵（DirectoryKey）、アプリケーションID（Application ID）及びアプリケーション鍵（Application Key））を書き換える処理を行う。
【００７２】
このために、まず、情報処理端末１１とICカード１２間で相互認証を行う。相互認証の方法に関しては後述する。相互認証が終了した後、情報処理端末１１からICカード１２に対し、ディレクトリ鍵（Directory Key）変更コマンドを送信する。ディレクトリ鍵（Directory Key）変更コマンドには、付随データとして、新しい鍵のキーバージョン（Key Version）と、古いディレクトリ鍵（Directory Key）で暗号化された、新しいディレクトリ鍵（Directory Key）が含まれている。これを受信したICカード１２は、変更するディレクトリのディレクトリ鍵（Directory Key）を読み出し、この鍵でコマンドに添付されてきたデータを復号化する。そして、得られた新しいディレクトリ鍵（Directory Key）で古いディレクトリ鍵（Directory Key）を書き換え、キーバージョン（Key Version）を更新する。
【００７３】
同様に、情報処理端末１１とICカード１２間で相互認証を行い、相互認証が終了した後、情報処理端末１１からICカード１２に対し、アプリケーション情報変更コマンドを送信する。アプリケーション情報変更コマンドには、付随データとして新しい鍵のキーバージョン（Key Version）、アプリケーションID（Application ID）及びアプリケーション鍵（Application Key）が含まれている。ただし、アプリケーションID（Application ID）は、情報処理端末１１で新たに割り振ることとし、このIDとアプリケーション鍵（Application Key）を生成するためのマスタ鍵とからアプリケーションID（Application ID）に対応するアプリケーション鍵（Application Key）を生成することとする。
【００７４】
次に、これを受信したICカード１２は、受信したアプリケーションID（Application ID）及びアプリケーション鍵（Application Key）を書き換え、キーバージョン（Key Version）を更新する。
【００７５】
なお、通常、この情報処理端末１１は鍵変更処理専門の端末であり、複数のICカードの鍵を変更し、これらの情報を管理している。従って、この情報処理端末１１は、アプリケーションID（Application ID）を系統的に割り振って管理することが可能である。
【００７６】
また、アプリケーション情報変更処理時に別途相互認証すると説明したが、上記ディレクトリ鍵（Directory Key）変更処理に引き続き行う場合には不要である。
【００７７】
一方、後述するように、相互認証を終了した情報処理端末１１とICカード１２は、以降の通信路をセッション鍵で暗号化して秘匿化することができ、かつメッセージを改ざん防止できるよう整合性チェックを行っている。このため、更新するための新しいディレクトリ鍵を情報処理端末１１内部に保持していても、通信路上で漏洩する心配はない。しかし、情報処理端末１１が安全に管理される保証はないため、念のため古いディレクトリ鍵で更新する新しいディレクトリ鍵を暗号化しておくこととする。一方で、新しいアプリケーション鍵は古いアプリケーション鍵で暗号化しておくことはしていない。これは、情報処理端末１１にアプリケーション鍵を生成するためのマスタ鍵が記憶されており、鍵更新時にアプリケーション鍵の生成を行っていることと（あらかじめ古いアプリケーション鍵で暗号化しておくことができない）、仮に情報処理端末１１が安全に管理されなかった場合、このマスタ鍵が漏洩することになり、そこまで対策しても効果が薄いからである。
【００７８】
また、事業者は、上位ディレクトリ（Directory）が生成されている場合、ルートディレクトリ直下でなくても、その上位ディレクトリの下に新規サブディレクトリ（Sub-Directory）を生成することができる。この時、サブディレクトリ（Sub-Directory）のディレクトリ鍵（Directory Key）とアプリケーションID（Application ID）、およびアプリケーション鍵（Application Key）も書き込まれる。実際の書き込み方法は、システム鍵（System Key）、ルート鍵（Root Key）、および上位のディレクトリのディレクトリ鍵（Directory Key）、上位のディレクトリのアプリケーション鍵（Application Key）で相互認証を行い、所定のフォーマットに従ったデータをセキュリティICに送り込んで行う。サブディレクトリのディレクトリ鍵（Sub-Directory Key）は、上位のディレクトリのディレクトリ鍵（Dirctory Key）で暗号化されているため、比較的安全である。サブディレクトリのアプリケーションID（Application ID）とアプリケーション鍵（Application Key）は、予め設定しておくことが困難であるため、事前に上位ディレクトリのディレクトリ鍵（Directory Key）で暗号化しておくことができない。そのため、セッション鍵で保護するものとする。
【００７９】
なお、本例ではサブディレクトリ生成のための所定フォーマットコマンドを使用するとしたが、必要に応じてサブディレクトリ生成のためのアクセス許諾チケットを定義し、それを用いて行うようにしても良い。ただし、アクセス許諾チケットは事前生成が前提にもかかわらず、アプリケーション鍵が事前に生成することは難しく、所定のフォーマットコマンドを使用する方法の方が容易に実現可能である。
【００８０】
所定のフォーマットコマンドを使用する場合、相互認証後、アプリケーションIDを生成し、マスタ鍵でアプリケーション鍵を生成し、上位ディレクトリの鍵で暗号化されたサブディレクトリのディレクトリ鍵とアプリケーションID、アプリケーション鍵、その他必要な情報（バージョン等）をセッション鍵で秘匿化してICカードに送るようにする。
【００８１】
これに対して、アクセスチケットを使用する場合、予めアプリケーションIDを生成しておき、それに対するアプリケーション鍵もマスタ鍵から作っておく。これら一連のデータとサブディレクトリのディレクトリ鍵を上位ディレクトリのディレクトリ鍵で暗号化し、これを包含したアクセス許諾チケットを作るようにする。ただし、アクセス許諾チケットに付けるICVを生成する鍵を何にするか、検討する必要がある。通常は、アクセス制御鍵を使うのだが、ディレクトリにはその鍵はない（ファイルに対して作られているため）。そのため、暫定的にICVも上位ディレクトリのディレクトリ鍵で生成する方法が考えられる。
【００８２】
ステップＳ８において、データ設定処理部３２は、事業者の指示に基づいて、ディレクトリ内にファイル（File）を作成する。ディレクトリが作成されていれば、事業者は、ファイルアクセス方法を規定し、それに対応するデータをファイルとして記憶部３１に書き込ませることができる。実際のファイル生成方法は、事業者が、システム鍵（System Key）、ルート鍵（Root Key）、ディレクトリ鍵（Directory Key）、およびアプリケーション鍵（Application Key）を用いて相互認証を行い、所定のフォーマットに従ったデータをセキュリティICに送り込んで行う。なお、アクセス制御鍵はディレクトリ鍵で暗号化されているため、比較的安全である。また、ディレクトリ鍵で暗号化されたアクセス制御鍵を含む、システムブロック情報（アクセスモード、アクセスコード、スタート・エンドアドレス、ディレクトリコード等）は、セッション鍵で暗号化されて送り込まれる。
【００８３】
なお、サブディレクトリの生成時と同様に、必要に応じてファイル生成のためのアクセス許諾チケットを定義し、それを用いて行うようにしても良い。
【００８４】
ステップＳ９において、データ設定処理部３２は、事業者の指示に基づいて、アクセス制御鍵を書き込む。ステップＳ８で説明したように、アクセス制御鍵（Access Control Key）は、生成されるファイルが所属するディレクトリのディレクトリ鍵（Directory Key）で暗号化しておくものとする。
【００８５】
以上のようにして、例えば、図２に示されるように、記憶部３１内に各種データが書き込まれる。
【００８６】
次に、記憶部３１に記憶される上述した各種情報の更新方法（変更方法）について説明する。
【００８７】
システム鍵（System Key）を変更するためには、デバイスID（Device ID）、パラメータ（Device Parameter）、およびシステム鍵（System Key）領域以外が書き込まれていない必要がある。実際には、この、所定の領域以外書き込まれていない状態で、ICカード１２の外部の機器から、所定のフォーマットに従ったデータがセキュリティICに送り込まれ、それに基づいてシステム鍵（System Key）が変更される。このときのコマンドは鍵変更コマンドとして定義される。また、図７に示されるように、そのコマンドに含まれるデータ列５３には、新しいシステム鍵（System Key）を古いシステム鍵（System Key）で暗号化したものが含まれる。古いシステム鍵（System Key）の暗号方式は、ICカード１２のメモリ内に書き込まれているシステム鍵（System Key）のキーフォーマット（Key Format）に従って使用される。なお、鍵変更コマンドに添付されるデータには、新しいシステム鍵だけでなく、新しいシステム鍵の鍵フォーマット（Key Format）や鍵バージョン（Key Version）が含まれる。以降、全ての鍵更新コマンドにおいて同様である。
【００８８】
ルート鍵（Root Key）を変更するためには、ルート鍵（Root Key）が書き込まれている必要がある。Root Keyが書き込まれている条件で、この鍵が変更できる。実際には、この状態でICカード１２の外部の機器から、所定のフォーマットに従ったデータがセキュリティICに送り込まれ、それに基づいてルート鍵（Root Key）が変更される。このときコマンドは鍵変更コマンドとして定義される。また、そのコマンドに含まれるデータ列には、例えば、図８Ａに示されるように、新しいルート鍵（Root Key）５４Ａを古いルート鍵（Root Key）５４Ｂで暗号化した第一のデータと、図８Ｂに示されるように、システム鍵（System Key）５４Ｃを古いルート鍵（Root Key）５４Ｂで暗号化し、それをさらに再度新しいルート鍵（Root Key）５４Ａで暗号化した第二のデータが含まれる。古いルート鍵（Root Key）の暗号方式は、ICカード１２のメモリ内に書き込まれているルート鍵（Root Key）のキーフォーマット（Key Format）に従って使用される。新しいルート鍵の暗号方式は、鍵更新コマンドに添付されている新しいルート鍵のキーフォーマット（Key Format）に従って使用される。なお、鍵変更コマンドに添付されるデータには、新しいルート鍵だけではなく、新しいルート鍵の新しい鍵の（Key Format）や鍵バージョン（Key Version）が含まれるものの、ディレクトリコード（Directory Code）である「00 00 00 00h」、開始アドレス、終了アドレス、およびトータルのブロック数などは、変更されることが想定されていないため、含まれていなくてもよい。ただし、これらのデータを含めるようにしてもいっこうに差し支えない。
【００８９】
ところで、なぜ２つの暗号化されたデータを使用するかというと、ルート鍵（Root Key）の変更には相互認証が使えないこと、および、アクセス許諾チケットが使えないことが理由である。そのため、悪意の第三者が、リーダライタ等を用いて適当なデータを「新しいルート鍵（Root Key）を古いルート鍵（Root Key）で暗号化したもの」としてICカードに送り込んでしまうと、ICカードはデータが正しいか否かを判断できず、不正な鍵に変更してしまうというリスクがある。そこで、システム鍵（System Key）を古いルート鍵（Root Key）（これはシステム管理者等が知っている）で暗号化し、その結果を更に新しいルート鍵（Root Key）（これもシステム管理者等は知っている）で暗号化し、このデータも付加するようにした。セキュリティICでは、第一のデータを古いルート鍵（Root Key）で復号して新しいルート鍵（Root Key）を取得し、この鍵で第二のデータを復号し、その出力を再度古いルート鍵（Root Key）で復号化する。その結果がシステム鍵（System Key）に一致していた場合に、正しいシステム管理者が処理していると判定して鍵の変更を行うようにする。
【００９０】
また、ディレクトリ鍵（Directory Key）の変更は、ディレクトリが生成されていれば可能である。実際には、この状態で認証鍵（System Key、Root Key、Directory Key、Application Keyを使用）の生成を行い、必要なデータをセキュリティICに送り込んで行う。コマンドはディレクトリ鍵変更コマンドとして定義され、図９に示されるように、コマンドに含まれるデータ列５５には、新しいディレクトリ鍵（Directory Key）を古いディレクトリ鍵（Directory Key）で暗号化したものが含まれる。また、必要に応じて、ここに新しい鍵のキーバージョン（Key Version）を含めるようにしても良い。これを受信したICカード１２は、変更するディレクトリのディレクトリ鍵（Directory Key）を読み出し、この鍵でコマンドに添付されてきたデータを復号化する。そして、得られた新しいディレクトリ鍵（Directory Key）で古いディレクトリ鍵（Directory Key）を書き換え、キーバージョン（Key Version）を更新する。
【００９１】
同様に、アプリケーションID（Application ID）とアプリケーション鍵（Application Key）の変更は、ディレクトリが生成されていればよい（片方だけ変更することは通常ない）。実際には、この状態で認証鍵（システム鍵（System Key）、ルート鍵（Root Key）、ディレクトリ鍵（Directory Key）、およびアプリケーション鍵（Application Key）が使用される）の生成を行い、必要なデータをセキュリティICに送り込んで行う。コマンドはアプリケーション鍵変更コマンドとして定義され、コマンドに含まれるデータ列には、非暗号化アプリケーションID（Application ID）／非暗号化アプリケーション鍵（Application Key）が含まれている。また、必要に応じて、ここに新しい鍵のキーバージョン（Key Version）を含めるようにしても良い。ただし、アプリケーションID（Application ID）は、ICカード１２の外部の機器で新たに割り振ることとし、このIDとアプリケーション鍵（Application Key）を生成するためのマスタ鍵とからアプリケーションID（Application ID）に対応するアプリケーション鍵（Application Key）を生成することとする。
【００９２】
次に、これを受信したICカード１２は、受信したアプリケーションID（Application ID）及びアプリケーション鍵（Application Key）を書き換え、キーバージョン（Key Version）を更新する。
【００９３】
なお、通常、このICカード１２の外部の機器は、鍵変更処理専門の端末であり、複数のICカードの鍵を変更し、これらの情報を管理している。従って、この鍵変更処理専門の端末は、アプリケーションID（Application ID）を系統的に割り振って管理することが可能である。
【００９４】
また、アプリケーション情報変更処理時に認証鍵を生成すると説明したが、上記ディレクトリ鍵（Directory Key）変更処理に引き続き行う場合には不要である。
【００９５】
一方、後述するように、相互認証を終了した鍵変更処理専門の端末とICカード１２は、以降の通信路をセッション鍵で暗号化して秘匿化することができ、かつメッセージを改ざん防止できるよう整合性チェックを行っている。このため、更新するための新しいディレクトリ鍵を鍵変更処理専門の端末内部に保持していても、通信路上で漏洩する心配はない。しかし、鍵変更処理専門の端末が安全に管理される保証はないため、念のため古いディレクトリ鍵で更新する新しいディレクトリ鍵を暗号化しておくこととする。一方で、新しいアプリケーション鍵は古いアプリケーション鍵で暗号化しておくことはしていない。これは、鍵変更処理専門の端末にアプリケーション鍵を生成するためのマスタ鍵が記憶されており、鍵更新時にアプリケーション鍵の生成を行っていることと（あらかじめ古いアプリケーション鍵で暗号化しておくことができない）、仮に鍵変更処理専門の端末が安全に管理されなかった場合、このマスタ鍵が漏洩することになり、そこまで対策しても効果が薄いからである。
【００９６】
なお、本例では各種鍵変更のための所定フォーマットコマンドを使用するとしたが、必要に応じて各種鍵変更のためのアクセス許諾チケットを定義し、それを用いて行うようにしても良い。
【００９７】
アクセス制御鍵（Access Control Key）の変更は、ファイルが生成されていれば実行可能である。実際には、この状態で認証鍵（システム鍵（System Key）、ルート鍵（Root Key）、ディレクトリ鍵（Directory Key）、およびアプリケーション鍵（Application Key）が使用される）の生成を行い、必要なデータをセキュリティICに送り込んで行う。コマンドはアクセス制御鍵変更コマンドとして定義され、図１０に示されるように、コマンドに含まれるデータ列５６には、新しいアクセス制御鍵（Access Control Key）を古いアクセス制御鍵（Access Control Key）で暗号化したものが含まれる。また、必要に応じて、ここに新しい鍵のキーバージョン（Key Version）を含めるようにしても良い。これを受信したICカード１２は、変更するファイルのアクセス制御鍵（Access Control Key）を読み出し、この鍵でコマンドに添付されてきたデータを復号化する。そして、得られた新しいアクセス制御鍵（Access Control Key）で古いアクセス制御鍵（Access Control Key）を書き換え、キーバージョン（Key Version）を更新する。なお、アクセス制御鍵（Access Control Key）の変更はアプリケーション鍵（Application Key）変更時と異なり、事前にデータ列を用意することができることと、物理セキュリティリスクがあることから、データを暗号化しておくこととした。このため、本例ではアクセス制御鍵変更のための所定フォーマットコマンドを使用するとしたが、必要に応じてサアクセス制御鍵変更のためのアクセス許諾チケットを定義し、それを用いて行うようにしても良い（このチケットは事前に作成できる）。
【００９８】
相互認証後、情報処理端末１１とICカード１２との間でセッション鍵が共有化される。通信されるパケットは全てセッション鍵で暗号化されると共に、改ざん防止用としてメッセージ認証用のデータが付加される。OMAC(One-Key CBC MAC)は、CBC MAC(Cipher Block Chaining Message Authentication Code)の変種としてが知られている。もしくはCCM(Counter with CBC-MAC)を用いるようにしてもよい。
【００９９】
図１の通信システム１において、情報処理端末１１およびICカード１２は、通信を行うためにセッションを確立する。情報処理端末１１およびICカード１２は、通信開始時において、そのセッションの確立のために、お互いを認証させる相互認証処理を行う。
【０１００】
図１１および図１２のフローチャートを参照して、その相互認証処理の流れの例を説明する。なお、必要に応じて、図１３乃至図１６を参照して説明する。また、ここでは、説明の便宜上、図２の情報処理端末１１−１−１およびICカード１２−１が相互認証処理を行う場合を例に説明する。
【０１０１】
相互認証処理が開始されると、情報処理端末１１−１−１の認証処理部２３は、ステップＳ２１において、乱数生成部２５を制御して第一の乱数を生成する。
【０１０２】
ステップＳ２２において、認証処理部２３は、通信部２８を制御して、第一の相互認証開始コマンドを、情報処理端末１１−１−１のID（ID１−１）、アクセスするディレクトリを示すアクセス先ディレクトリ情報、および、ステップＳ２１の処理において生成された第一の乱数とともに、ICカード１２−１に送信させる。なお、アクセス先ディレクトリ情報においては、アクセス先のディレクトリが例えばディレクトリコード（Directory Code）によって示される。もちろん、アクセス先のディレクトリを特定することができる情報であれば、ディレクトリコード（Directory Code）以外の情報を用いるようにしてもよい。なお、ここではアクセス先ディレクトリの一例として、ディレクトリ１−１とディレクトリ１−２が指定されたものとして説明する。
【０１０３】
ステップＳ３１において、ICカード１２−１の通信部３８は、この第一の相互認証開始コマンド等を取得する。第一の相互認証開始コマンドを取得すると、認証処理部３３のマスタ鍵生成部４１は、ステップＳ３２において、相互認証の相手となる情報処理端末１１（この場合、情報処理端末１１−１−１）固有の鍵（この場合、鍵Ｋ１−１）を生成するための鍵情報であるマスタ鍵（この場合、マスタ鍵MK１−IT）を生成する処理を行う。マスタ鍵の生成は、第一のデータ、ルート鍵、および、アクセス先に指定されたディレクトリのディレクトリ鍵を縮退することにより生成される。
【０１０４】
より具体的な例は、図１３に示される。図１３に示されるように、マスタ鍵生成部４１は、暗号化処理部（AES）６１乃至暗号化処理部（AES）６３の機能ブロックを有する。暗号化処理部（AES）６１は、暗号化部３６を制御し、第一のデータとしてシステム鍵（ＫSystem）をルート鍵（ＫRoot）を用いてAES（Advanced Encryption Standard）方式で暗号化させ、第二のデータを生成する。暗号化処理部（AES）６２は、暗号化部３６を制御し、その第二のデータをディレクトリ１−１のディレクトリ鍵（DirK１−１）を用いてAES方式で暗号化させる。暗号化処理部（AES）６３は、暗号化部３６を制御し、暗号化処理部（AES）６２による暗号化結果をディレクトリ１−２のディレクトリ鍵（DirK１−２）を用いてAES方式で暗号化させ、マスタ鍵（MK１−IT）を生成する。なお、AESの代わりに、DES（Data Encryption Standard）等、その他の共通鍵暗号化方式を用いるようにしてもよい。
【０１０５】
このマスタ鍵生成処理の詳細な流れについては、後述する。マスタ鍵が生成されると認証処理部３３は、ステップＳ３３において、暗号化部３６を制御し、情報処理端末１１−１−１のID（ID１−１）を、ステップＳ３２の処理により生成されたマスタ鍵（MK１−IT）を用いて暗号化させ、情報処理端末１１−１−１固有の鍵（Ｋ１−１）を生成する。
【０１０６】
具体的な例を図１４に示す。図１４に示されるように、認証処理部３３は、暗号化処理部（AES）７１の機能ブロックを有する。暗号化処理部（AES）７１は、暗号化部３６を制御し、情報処理端末１１−１−１のID（ID１−１）をマスタ鍵（MK１−IT）を用いてAES方式で暗号化させ、情報処理端末１１−１−１固有の鍵（Ｋ１−１）を生成する。
【０１０７】
なお、この場合も、AESの代わりに、DES等、その他の共通鍵暗号化方式を用いるようにしてもよい。また、本例では暗号化する例で説明したが、ステップＳ３２の処理により生成されたマスタ鍵（MK１−IT）を用いて情報処理端末１１−１−１のID（ID１−１）を復号化し、情報処理端末１１−１−１固有の鍵（Ｋ１−１）を生成しても良い。あるいは、所定の固定値を情報処理端末１１−１−１のID（ID１−１）に対してEXORするなどして演算した後、ステップＳ３２の処理により生成されたマスタ鍵（MK１−IT）を用いて暗号化させて生成するようにしても良い。このように、情報処理端末１１−１−１に保持されている固有の鍵（Ｋ１−１）が復元できさえすれば、どのような演算方法を用いてもかまわない。
【０１０８】
この鍵Ｋ１−１は、情報処理端末１１−１−１固有の鍵である。図２の例において、事業者１の情報処理端末１１−１−２には、情報処理端末１１−１−１に割り当てられたID（ID１−１）と異なるID（ID１−２）が書き込まれているため、同じ情報処理端末用マスタ鍵（MK１−IT）を用いても、情報処理端末１１−１−１固有の鍵（Ｋ１−１）とは異なる情報処理端末１１−１−２固有の鍵（Ｋ１−２）が生成される。
【０１０９】
ステップＳ３４において、認証処理部３３は、暗号化部３６を制御し、アクセス先に指定されたディレクトリに書き込まれたアプリケーションID（AppID１−１とAppID１−２）を情報処理端末１１−１−１固有の鍵（Ｋ１−１）で暗号化させ、第一の返信文を作成する。このとき、アプリケーションID（AppID）の使用順は、情報処理端末１１−１−１より供給されたアクセス先ディレクトリ情報に従う。なお、このときの暗号化方法は、CBC（Cipher Block Chaining）モード等の暗号利用モードを用いることとする。また、本例では暗号化することを示していたが、復号するようにしてもよい。この場合、この第一の返信文を受け取った情報処理端末１１−１−１側では、同一の鍵を用いて暗号化する必要がある。
【０１１０】
第一の返信文を生成した後、認証処理部３３は、ステップＳ３５において、相互認証に利用される認証鍵（KAuth）の生成を行う。認証処理部３３は、暗号化部３６を制御し、情報処理端末１１−１−１固有の鍵（Ｋ１−１）を、アクセス先に指定されたディレクトリに書き込まれたアプリケーション鍵（AppK１−１およびAppK１−２）を用いて暗号化させて認証鍵（KAuth）を生成する。このような処理を鍵の縮退化とする。
【０１１１】
具体的な例を図１５に示す。図１５に示されるように、認証処理部３３は、暗号化処理部（AES）８１および暗号化処理部（AES）８２の機能ブロックを有する。暗号化処理部（AES）８１は、暗号化部３６を制御し、情報処理端末１１−１−１固有の鍵（Ｋ１−１）を、アクセス先に指定されたディレクトリ１−１に書き込まれているアプリケーション鍵（AppK１−１）を用いてAES方式で暗号化させる。暗号化処理部（AES）８２は、暗号化部３６を制御し、暗号化処理部（AES）８１による暗号化結果を、アクセス先に指定されたディレクトリ１−２に書き込まれているアプリケーション鍵（AppK１−２）を用いてさらにAES方式で暗号化させる。この暗号化処理部（AES）８２による暗号化結果が認証鍵（KAuth）とされる。
【０１１２】
なお、アプリケーション鍵（AppK）の使用順は、情報処理端末１１−１−１より供給されたアクセス先ディレクトリ情報に従う。また、この場合も、AESの代わりに、DES等、その他の共通鍵暗号化方式を用いるようにしてもよい。
【０１１３】
ステップＳ３６において、認証処理部３３は、乱数生成部３５を制御して第二の乱数を生成する。ステップＳ３７において、認証処理部３３は、認証鍵（KAuth）を暗号鍵とし、暗号化部３６を制御して、この第二の乱数、情報処理端末１１−１−１から送られてきた第一の乱数、および、情報処理端末１１−１−１のID（ID１−１）を所定の暗号利用モードで暗号化し、第二の返信文を生成する。なお、第二の乱数、第一の乱数、および、情報処理端末１１−１−１のID（ID１−１）は、予め定められた所定の順序で暗号化される。
【０１１４】
ここで、本例では第一の返信文は情報処理端末１１−１−１固有の鍵（Ｋ１−１）で暗号化させて生成し、第二の返信文は認証鍵（KAuth）で暗号化させて生成していたが、暗号化された第一の返信文及び暗号化前の第二の返信文を、認証鍵（KAuth）を用いて、所定の暗号利用モードで一括して暗号化するようにしても良い。更にまた、第二の返信文に情報処理端末１１−１−１のID（ID１−１）を含ませていたが、これ（情報処理端末１１−１−１のID）以外のデータを利用するようにしても良い。
【０１１５】
ステップＳ３８において、ICカード１２−１の認証処理部３３は、通信部３８を制御して、相互認証開始コマンドに対するレスポンスとして、第一の返信文と第二の返信文を、情報処理端末１１−１−１に返信させる。ステップＳ３８の処理を終了すると、ICカード１２−１の認証処理部３３は、図１２のステップＳ５１に処理を進める。
【０１１６】
また、情報処理端末１１−１−１の通信部２８は、ステップＳ２３においてそのレスポンス（第一の返信文と第二の返信文）を受信すると、処理を図１２のステップＳ４１に進める。
【０１１７】
図１２のステップＳ４１において、情報処理端末１１−１−１の認証処理部２３は、復号部２７を制御し、予め記憶部２１に記憶されている情報処理端末１１−１−１固有の鍵（Ｋ１−１）を用いて第一の返信文を、利用された暗号化方法に対応する復号方法で復号させ、アプリケーションID（AppID１−１とAppID１−２）を取り出す。ステップＳ４２において、認証処理部２３は、予め記憶部２１に記憶されているマスタ鍵（MK1−IC）を用いてアプリケーションID（AppID１−１）暗号化することによりアプリケーション鍵（AppK１−１）を生成し、さらに、マスタ鍵（MK1−IC）を用いてアプリケーションID（AppID１−２）を暗号化することによりアプリケーション鍵（AppK１−２）を生成する。
【０１１８】
具体的な例を図１６に示す。図１６に示されるように、認証処理部３３は、暗号化処理部（AES）９１の機能ブロックを有する。暗号化処理部（AES）９１は、暗号化部２６を制御し、ディレクトリ１−１のアプリケーションID（AppID１−１）を、マスタ鍵（MK1−IC）を用いてAES方式で暗号化してアプリケーション鍵（AppK１−１）を生成する。なお、図示は省略するが、この暗号化処理部（AES）９１は、アプリケーション鍵（AppK１−１）の場合と同様に、暗号化部３６を制御し、ディレクトリ１−２のアプリケーションID（AppID１−２）を、マスタ鍵（MK1−IC）を用いてAES方式で暗号化してアプリケーション鍵（AppK１−２）を生成する。
【０１１９】
なお、この場合も、AESの代わりに、DES等、その他の共通鍵暗号化方式を用いるようにしてもよい。また、例えば、ディレクトリ毎にマスタ鍵が異なる場合、各アプリケーションIDの暗号化は、それぞれのアプリケーションIDが対応するディレクトリのマスタ鍵を用いて行われるようにする。つまり、ディレクトリ１−１のアプリケーション鍵（AppK１−１）は、ディレクトリ１−１のアプリケーションID（AppID１−１）を、ディレクトリ１−１用のマスタ鍵（MK1−IC1）を用いて生成し、ディレクトリ１−２のアプリケーション鍵（AppK１−２）は、ディレクトリ１−２のアプリケーションID（AppID１−２）を、ディレクトリ１−２用のマスタ鍵（MK1−IC2）を用いて生成する、などの方法である。
【０１２０】
ステップＳ４３において、認証処理部２３は、暗号化部２６を制御して、情報処理端末１１−１−１固有の鍵（Ｋ１−１）を、ステップＳ４２で生成したアプリケーション鍵（AppK１−１およびAppK１−２を用いて暗号化させ、認証鍵（ＫAuth）を生成する。この認証鍵（ＫAuth）の生成方法は、ICカード１２において実行されるステップＳ３５の処理の場合と同様に実行される。つまり、図１５を参照して行った説明は、このステップＳ４３における認証鍵生成の説明にも適用することができる。つまり、認証処理部２３も、図１５に示されるように、暗号化処理部（AES）８１および暗号化処理部（AES）８２の機能ブロックを有し、その暗号化処理部（AES）８１は、暗号化部２６を制御し、情報処理端末１１−１−１固有の鍵（Ｋ１−１）をアプリケーション鍵（AppK１−１）を用いてAES方式で暗号化させ、暗号化処理部（AES）８２は、暗号化部２６を制御し、暗号化処理部（AES）８１による暗号化結果をアプリケーション鍵（AppK１−２）を用いてさらにAES方式で暗号化させる。この暗号化処理部（AES）８２による暗号化結果が認証鍵（KAuth）とされる。
【０１２１】
なお、アプリケーション鍵（AppK）の使用順は、アクセス先ディレクトリ情報において定義されるとおり（復号されたディレクトリID順）とする。また、この場合も、AESの代わりに、DES等、その他の共通鍵暗号化方式を用いるようにしてもよい。
【０１２２】
ステップＳ４４において、認証処理部２３は、復号部２７を制御し、ICカード１２−１より取得した第二の返信文を復号させ、第二の乱数、第一の乱数、および情報処理端末１１−１−１固有のID（ID１−１）を取り出す。
【０１２３】
ステップＳ４５において、認証処理部２３は、取り出した第一の乱数によりICカード１２−１の認証を行う。仮に、ICカード１２−１より取得した第二の返信文を復号して得られた第一の乱数が、ICカード１２−１に供給した第一の乱数と一致する（同一である）場合、ICカード１２−１においても同一の認証鍵が生成されていることになる。つまり、ICカード１２−１が、第一のデータ、ルート鍵（ＫRoot）、ディレクトリ鍵（DirK１−１およびDirK１−２）、アプリケーション鍵（AppK１−１およびAppK１−２）を保持している蓋然性が高い。従って、認証処理部２３は、相手（ICカード１２−１）を認証してもよいと判断することができる。逆に、第一の乱数が正しくない（一致しない）場合、認証処理部２３は、ICカード１２−１は不正であると判定することとなる。
【０１２４】
つまり、認証処理部２３は、第二の返信文より取り出した第一の乱数が図７のステップＳ２１において生成した第一の乱数と一致するか否かを判定することにより、ICカード１２−１を認証するか否かを判定する。そして、２つの第一の乱数の値が互いに一致した場合、認証処理部２３は、ICカード１２−１を認証する。逆に、２つの第一の乱数の値が互いに一致しなかった場合、認証処理部２３は、ICカード１２−１が不正であると判定し、相互認証処理をエラー終了する。つまり、この場合、情報処理端末１１−１−１とICカード１２−１との間の相互認証が行われないので、通信の確立に失敗する。
【０１２５】
２つの第一の乱数の値が互いに一致し、ICカード１２−１が認証されると、認証処理部２３は、ステップＳ４６において、乱数生成部２５を制御して乱数を生成させ、その乱数をセッション鍵とする。このセッション鍵は、相互認証完了後の通信路の秘匿化に使用される。
【０１２６】
ステップＳ４７において、認証処理部２３は、第一の乱数、第二の乱数、および、生成したセッション鍵を、認証鍵（ＫAuth）で暗号化する。暗号化は所定の暗号利用モードで行うこととする。なお、暗号化の順はこれに限らず任意である。
【０１２７】
ステップＳ４８において、認証処理部２３は、通信部２８を制御して、第二の相互認証コマンドを、認証鍵（ＫAuth）で暗号化された第一の乱数、第二の乱数、およびセッション鍵と共にICカード１２−１に送信させる。ICカード１２−１の通信部３８は、ステップＳ５１において、この第二の相互認証コマンドと、認証鍵（ＫAuth）で暗号化された第一の乱数、第二の乱数、およびセッション鍵を取得する。
【０１２８】
ステップＳ５２において、ICカード１２−１の認証処理部３３は、復号部３７を制御し、認証鍵（ＫAuth）を用いて認証鍵（ＫAuth）で暗号化された第一の乱数、第二の乱数、およびセッション鍵を復号させる。
【０１２９】
ステップＳ５３において、認証処理部３３は、取り出した第二の乱数により情報処理端末１１−１−１の認証を行う。仮に、情報処理端末１１−１−１より取得した第二の乱数が、図１１のステップＳ３６の処理において生成された第二の乱数と一致する（同一である）場合、情報処理端末１１−１−１においても同一の認証鍵が生成されていることになる。つまり、情報処理端末１１−１−１が情報処理端末１１−１−１固有の鍵Ｋ１−１と、ICカード１２−１用のマスタ鍵（MK１−IC）を保持している蓋然性が高い。従って、認証処理部３３は、相手（情報処理端末１１−１−１）を認証してもよいと判断することができる。逆に、第二の乱数が正しくない（一致しない）場合、認証処理部３３は、情報処理端末１１−１−１が不正であると判定することとなる。
【０１３０】
つまり、認証処理部３３は、第二の相互認証コマンドともに供給された第二の乱数が、図１１のステップＳ３６において生成した第二の乱数と一致するか否かを判定することにより、情報処理端末１１−１−１を認証するか否かを判定する。そして、２つの第二の乱数の値が互いに一致した場合、認証処理部３３は、情報処理端末１１−１−１を認証する。逆に、２つの第二の乱数の値が互いに一致しなかった場合、認証処理部３３は、情報処理端末１１−１−１が不正であると判定し、相互認証処理をエラー終了する。つまり、この場合、情報処理端末１１−１−１とICカード１２−１との間の相互認証が行われないので、通信の確立に失敗する。
【０１３１】
２つの第二の乱数の値が互いに一致し、情報処理端末１１−１−１が認証されると、認証処理部３３は、ステップＳ５４において、通信部３８を制御し、その認証結果をレスポンスとして送信させ、相互認証処理を正常終了する。
【０１３２】
ステップＳ４９において、情報処理端末１１−１−１の通信部２８は、そのレスポンス取得し、相互に認証されたことを把握し、相互認証処理を正常終了する。
【０１３３】
以上のようにして、相互に相手が認証されると、それ以降の電文は、全てセッション鍵により暗号化されて送受信される。
【０１３４】
次に、図１１のステップＳ３２において実行されるマスタ鍵生成処理の詳細な流れの例を図１７のフローチャートを参照して説明する。
【０１３５】
マスタ鍵生成処理が開始されると、マスタ鍵生成部４１は、ステップＳ７１において、情報処理端末１１−１−１より供給されたアクセス先ディレクトリ情報に基づいて、マスタ鍵（MK１−IT）の生成に使用するディレクトリ鍵（DirK１−１およびDirK１−２）を取得する。ステップＳ７２において、マスタ鍵生成部４１は、アクセス先ディレクトリ情報に示される順に、マスタ鍵（MK１−IT）の生成に使用するディレクトリ鍵（DirK１−１およびDirK１−２）を整列させる。整列が完了すると、マスタ鍵生成部４１は、ステップＳ７３において、まず、第一のデータ（ＫSystem）をルート鍵（ＫRoot）で暗号化する。
【０１３６】
ステップＳ７４において、マスタ鍵生成部４１は、ステップＳ７１において取得したディレクトリ鍵（DirK）の中に未使用のディレクトリ鍵（DirK）が存在するか否かを判定し、存在すると判定した場合、ステップＳ７５に処理を進め、次の順のディレクトリ鍵を用いて前回の暗号化結果を暗号化する。暗号化が終了すると、マスタ鍵生成部４１は、処理をステップＳ７４に戻す。
【０１３７】
以上のように、マスタ鍵生成部４１は、ステップＳ７４およびステップＳ７５の処理を繰り返し、取得した全てのディレクトリ鍵を用いて暗号化を繰り返す。そして、ステップＳ７４において全てのディレクトリ鍵を使用したと判定した場合、マスタ鍵生成部４１は、マスタ鍵生成処理を終了する。
【０１３８】
つまり、マスタ鍵生成部４１は、以上のように暗号化を繰り返すことにより、第一のデータとして利用されるシステム鍵（ＫSystem）、ルート鍵（ＫRoot）、取得したディレクトリ鍵を縮退化させてマスタ鍵（MK１−IT）を生成する。
【０１３９】
なお、以上においては、情報処理端末１１−１−１とICカード１２−１の間の相互認証処理について説明したが、情報処理端末１１−１−２、情報処理端末１１−２−１、ICカード１２−２等、通信システム１の他のデバイス間の相互認証処理も同様に実行される。
【０１４０】
以上のように、ICカード１２の記憶部３１には、ディレクトリ毎にアプリケーションIDが設けられており、各IDは、それぞれが対応する正当な事業者にしか提示されないようになされている。これにより、ユーザのプライバシーを守ることができるようになる。
【０１４１】
つまり、例えばICカード固有のIDが一つしかない場合、正当な情報処理端末では（事業者によらず）全て同一IDを読み出せてしまい、そのIDをトラッキングすることでユーザの居場所を追跡できてしまうという弊害があった。
【０１４２】
しかしながら、通信システム１においては、事業者毎にユーザに（ディレクトリ内に）IDを割り振る方式とし、更に、このIDは割り振った事業者のみが知り得る鍵で暗号化して返信することとした。このため、他の事業者ではIDを復号することができなくなった。つまり、自分のお客であるユーザは認識できるが、他のお客は認識できないことになり、他のお客までを含めてトラッキングされることを防止できるようにした。
【０１４３】
また、共通鍵認証よりも強度的に優れる個別鍵認証技術を導入すると共に、複数のディレクトリにアクセスすることを想定し、アクセス先ディレクトリに応じてディレクトリ鍵等を縮退化させたマスタ鍵を用いることにより、それらを一回の認証手順で処理できるようにした。これにより、認証処理時間を大幅に減らすことができるようになった。
【０１４４】
さらに、通信システム１においては、認証処理に情報処理端末１１のIDを用いるため、仮に情報処理端末１１が解析されて不正な情報処理端末１１’が作成されたとしても、情報処理端末１１’のIDは情報処理端末１１のIDと同一になるので、ICカード１２側においてそのIDをリボーク（Revoke）用のIDとして保持させておくことにより、ICカード１２は、情報処理端末１１’によるアクセスを阻止することができる。
【０１４５】
すなわち、通信システム１（情報処理端末１１およびICカード１２）は、安全かつ迅速に相互認証処理を行うことができる。
【０１４６】
以上を通し、相互認証が完了した。相互認証が完了すると、情報処理端末１１は、次に、ICカード１２に書き込まれているファイルにアクセスする。そのファイルアクセス方法について説明する。なお、本例では複数の主体が出てきても同じであるため、事業者１の情報処理端末１１−１−１、ICカード１２−１のみを定義するものとするが、当然他の事業者、他の情報処理端末１１、他のICカード１２が登場してもよい。また、誤解がない場合には、情報処理端末１１−１−１を情報処理端末１１、ICカード１２−１をICカード１２と表記する場合がある。
【０１４７】
情報処理端末１１−１−１がファイルにアクセスするためには、ICカード１２−１よりファイルアクセスの許諾を受けなければならない。正当な情報処理端末１１には、予めアクセス許諾に必要な情報を含むアクセス許諾チケットが配布されている。情報処理端末１１−１−１は、そのアクセス許諾チケットをICカード１２−１に提示することでファイルアクセスの許諾を求める。ICカード１２−１は、そのアクセス許諾チケットを検証し、正当なものであればアクセスを許諾する。
【０１４８】
次に、情報処理端末１１−１−１とICカード１２−１のそれぞれが有する、このようなアクセス制御に関する情報について、図１８を参照して説明する。
【０１４９】
図１８の例において、情報処理端末１１−１−１の記憶部２１―１−１には、情報処理端末１１のID（ID１−１）、情報処理端末固有の鍵（Ｋ１−１）、事業者１によるICカード１２全般用のマスタ鍵（MK１−IC）、および情報処理端末１１−１−１に割り当てられたアクセス許諾チケット（Ticket１−１）が書き込まれている。
【０１５０】
ICカード１２−１の記憶部３１−１には、第一のデータ（ＫSystem）、第三のデータ（ＫSystem2）、ルート鍵（ＫRoot）が書き込まれている。第三のデータ（ＫSystem2）は、基本的に第一のデータ（ＫSystem）と同様であるものの、システム管理者によって割り当てられる、アクセス許諾チケット生成鍵用のシステム鍵となる。つまり、ICカード１２には、認証鍵用のシステム鍵（ＫSystem）と、アクセス許諾チケット生成鍵用のシステム鍵（ＫSystem2）の２つのシステム鍵が登録される。これら２つのシステム鍵のフォーマットは任意であり、例えば、暗号化アルゴリズムや鍵長が互いに異なっていてもよいし、統一されていてもよい。また、各システム鍵の値が独立して決定されるようにしてもよいし、一方から他方を算出することができるようにして、片方のシステム鍵をメモリ上に保持しないようにしてもよい。
【０１５１】
ICカード１２−１の記憶部３１−１には、さらに、ディレクトリ１−１とディレクトリ１−２が作成されている。ディレクトリ１−１には、ディレクトリ鍵（Dir１−１）、アプリケーションID（AppID１−１）、アプリケーション鍵（AppK１−１）が書き込まれており、さらに、ファイル（File１）と、そのファイル（File１）に対するアクセス方法を定義するアクセス制御鍵（ACK１−１およびACK１−２）が書き込まれている。
【０１５２】
アクセス制御鍵は、所謂、ファイルに対するパーミッションを設定するものであり、読み出しや書き込み等の、アクセス者によるファイルに対する操作を制限するための鍵情報である。つまり、１つ目のアクセス制御鍵（ACK１−１）は、ファイル（File１）に対するアクセス方法１−１でのアクセスを許可するための鍵情報であり、２つ目のアクセス制御鍵（ACK１−２）は、ファイル（File１）に対するアクセス方法１−２でのアクセスを許可するための鍵情報である。
【０１５３】
また、ディレクトリ１−２には、ディレクトリ鍵（Dir１−２）、アプリケーションID（AppID１−２）、アプリケーション鍵（AppK１−２）が書き込まれており、さらに、ファイル（File２およびFile３）、その１つ目のファイル（File２）に対するアクセス方法を定義するアクセス制御鍵（ACK２−１、ACK２−２、およびACK２−３）、並びに、２つ目のファイル（File３）に対するアクセス方法を定義するアクセス制御鍵（ACK３−１およびACK３−２）が書き込まれている。
【０１５４】
図１９に、図１８に示されるアクセス制御チケット（Ticket１−１）の構成例を示す。
【０１５５】
アクセス許諾チケット１０１には、このチケットの使用者を示す情報として情報処理装置１１−１−１のID（ID１−１）、アクセス先のファイルおよびアクセス方法（すなわち、アクセス制御鍵）を示すアクセスコードのリスト（アクセスコード：１−２、アクセスコード：２−２、アクセスコード：２−３、アクセスコード：３−１）、および、MACよりなるチェック子が記述されている。
【０１５６】
つまり、ファイルへのアクセス許諾を求める情報処理端末１１−１−１は、誰がどのファイルに対してどのような処理をするかを示すアクセス許諾チケット１０１をICカード１２−１に送信し、ICカード１２−１においてそのアクセス許諾チケット１０１の検証を行い、正当であれば、そのチケットにより要求されるアクセス方法を許諾する。
【０１５７】
図２０のフローチャートを参照してこのようなアクセス制御の処理の流れの例を説明する。必要に応じて図２１および図２２を参照して説明する。
【０１５８】
アクセスの許諾を求める情報処理装置１１−１−１のファイルアクセス処理部２４は、ステップＳ１０１において、通信部２８を制御して、アクセス許諾チケット（Ticket１−１）を含むファイル許可命令をICカード１２−１に対して発行する。この時、命令文をセッション鍵により暗号化するようにしてもよい。ICカード１２−１の通信部３８は、ステップＳ１１１において、そのファイル許可命令を取得する。
【０１５９】
ファイル許可命令を取得すると、ICカード１２−１のファイルアクセス処理部３４は、ステップＳ１１２において、アクセス許諾チケット（Ticket１−１）に記述されているチケットの使用者のIDを検証する。情報処理端末１１−１−１（ID１−１）は、相互認証処理において認証済みであるので、ファイルアクセス処理部３４は、アクセス許諾チケット（Ticket１−１）に記述されている使用者IDがこの認証済みのIDと一致するか否かを検証し、一致する場合のみ、アクセス許諾チケット（Ticket１−１）の使用者を認証する。アクセス許諾チケット（Ticket１−１）の使用者のIDが認証済みのIDと一致しない場合、ファイルアクセス処理部３４は、このアクセス制御処理を強制終了し、アクセスの許諾要求を拒否する。このため、他の情報処理端末のチケットを不正に使用しても、アクセスは拒否される。
【０１６０】
なお、認証済みのIDに関わらず、アクセス制御チケットの使用者を許諾させる特別なID（オールマイティID）を設けるようにしてもよい。例えば、所定のIDをオールマイティIDとして予め用意しておき、IDカード１２のファイルアクセス処理部３４が、アクセス許諾チケットの使用者のIDがこのオールマイティIDである場合、認証済みのIDとの一致不一致に関わらず、使用者を認証するようにすればよい。つまり、このオールマイティIDが使用者のIDとして記述されることにより、そのアクセス制御チケットは、どの情報処理端末１１においても使用可能なチケットとなる。
【０１６１】
アクセス制御チケット（Ticket１−１）の使用者を認証すると、ファイルアクセス処理部３４は、ステップＳ１１３において、アクセス制御チケット（Ticket１−１）に記述されているアクセスコードが、相互認証処理において情報処理端末１１−１−１のアクセス先として認証済みのディレクトリのものであるか否かを確認する。相互認証時に指定したディレクトリ以外のディレクトリのアクセスコードが含まれている場合（すなわち、相互認証時に指定したディレクトリ以外のディレクトリへのアクセスを要求している場合）、ファイルアクセス処理部３４は、このアクセス制御処理を強制終了し、アクセスの許諾要求を拒否する。
【０１６２】
アクセス制御チケット（Ticket１−１）に記述されているアクセスコードが、相互認証処理において情報処理端末１１−１−１のアクセス先として認証済みのディレクトリのものである場合、ファイルアクセス処理部３４は、アクセス制御処理を継続する。なお、認証済みのディレクトリのアクセスコードと、認証済みでないディレクトリのアクセスコードの両方が含まれている場合、ファイルアクセス処理部３４が、このアクセス制御処理を強制終了し、アクセスの許諾要求を拒否するようにしてもよいし、認証済みでないディレクトリのアクセスコードについてのみ拒否し、認証済みのアクセスコードに対しては処理を継続するようにしてもよい。
【０１６３】
ステップＳ１１４において、ファイルアクセス処理部３４は、第三のデータ（ＫSystem2）をルート鍵（ＫRoot）で暗号化して第四のデータ（System Data）を生成する。
【０１６４】
図２１に示されるように、ファイルアクセス処理部３４は、暗号化処理部（AES）１１１の機能ブロックを有する。暗号化処理部（AES）１１１は、暗号化部３６を制御し、第三のデータとしてシステム鍵（ＫSystem2）をルート鍵（ＫRoot）を用いてAES方式で暗号化させ、第四のデータ（System Data）を生成する。なお、暗号化処理部（AES）１１１が、AESの代わりに、DES等、その他の共通鍵暗号化方式を用いるようにしてもよい。
【０１６５】
また、ここでは第一のデータと異なるデータを使用したが、第一のデータを使用するようにしてもよい。なお、ここでも第四のデータを事前に計算し、記憶部３１に保持しておくようにしてもよい。その場合、ステップＳ１１４の処理は省略される。
【０１６６】
ステップＳ１１５において、ファイルアクセス処理部３４のアクセス許諾チケット生成鍵生成部４２は、第四のデータから、アクセス許諾チケットのチェック子（MAC）を算出するためのアクセス許諾チケット生成鍵を作成する処理を行う。アクセス許諾チケット生成鍵生成部４２は、アクセス制御チケット（Ticket１−１）に記述されているアクセスコードに対応するアクセス制御鍵を記憶部３１−１より全て読み出し、第四のデータをこれらの鍵を使って順番に暗号化していく。
【０１６７】
図１９の例の場合、アクセス制御チケット（Ticket１−１）には、アクセスコード：１−２、アクセスコード：２−２、アクセスコード：２−３、およびアクセスコード：３−１が記述されている。従って、アクセス許諾チケット生成鍵生成部４２は、記憶部３１−１よりACK１−２、ACK２−２、ACK２−３、およびACK３−１を取得する。
【０１６８】
この場合、図２２に示されるように、アクセス許諾チケット生成鍵生成部４２は、暗号化処理部（AES）１２１乃至暗号化処理部（AES）１２４の機能ブロックを有する。暗号化処理部（AES）１２１は、暗号化部３６を制御し、第四のデータ（System Data）を、ACK１−２を用いてAES方式で暗号化させる。暗号化処理部（AES）１２２は、暗号化部３６を制御し、暗号化処理部（AES）１２１による暗号化結果を、ACK２−２を用いてAES方式で暗号化させる。暗号化処理部（AES）１２３は、暗号化部３６を制御し、暗号化処理部（AES）１２２による暗号化結果を、ACK２−３を用いてAES方式で暗号化させる。さらに、暗号化処理部（AES）１２４は、暗号化部３６を制御し、暗号化処理部（AES）１２３による暗号化結果を、ACK３−１を用いてAES方式で暗号化させ、アクセス許諾チケット生成鍵（A.C.Gen.Key）を生成する。なお、暗号化処理部（AES）１２１乃至暗号化処理部（AES）１２４が、AESの代わりに、DES等、その他の共通鍵暗号化方式を用いるようにしてもよい。なお、アクセス許諾チケット生成鍵生成処理の別な方法は、後述する（図２３参照）。
【０１６９】
アクセス許諾チケット生成鍵が生成されるとファイルアクセス処理部３４は、ステップＳ１１６において、アクセス許諾チケットのチェック子（MAC値）を、アクセス許諾チケット生成鍵を用いて計算する（例えば、暗号利用モードのCBCモードなどを利用する）。
【０１７０】
ステップＳ１１７において、ファイルアクセス処理部３４は、生成したチェック子の値を、アクセス許諾チケット（Ticket１−１）のチェック子の値と比較し、アクセス許諾チケット（Ticket１−１）を検証する。生成したチェック子の値がアクセス許諾チケット（Ticket１−１）に記述されるチェック子の値と一致しない場合、ファイルアクセス処理部３４は、アクセス許諾チケット（Ticket１−１）が不正である（改ざんされた）と判定し、このアクセス制御処理を強制終了し、アクセス許諾要求を拒否する。値が一致する場合、ファイルアクセス処理部３４は、アクセス許諾チケット（Ticket１−１）が正当であると判定し、認証する。
【０１７１】
チケットが正当であると言うことは、MAC値を生成するアクセス許諾チケット生成鍵を正しく生成していると言うことであり、それはつまり、第三のデータ、ルート鍵、アクセス方法に対する全てのアクセス制御鍵を知っている事業者がチケットを生成した蓋然性が高いということである。そしてそれは、正当な事業者が所有する情報処理端末であるということになる。
【０１７２】
従って、ファイルアクセス処理部３４は、アクセス許諾チケット（Ticket１−１）に従ったファイルへのアクセスを許可し、ステップＳ１１８において、その旨を通知する応答を、要求元の情報処理端末１１−１−１に供給する。
【０１７３】
情報処理端末１１−１−１の通信部２８は、ステップＳ１０２において、その応答を取得する。ファイルアクセス処理部２４は、アクセス許諾を得たアクセス方法に則りファイルにアクセスする。例えば、アクセス方法１−１がFile１に対するリード・ライト可、アクセス方法１−２がリードオンリーである場合、情報処理端末１１−１−１からICカード１２−１に対し、File１の読み出しコマンドは受け付けられても、書き換え命令は拒絶されることになる。このように、各ファイルに対してアクセス制御を複数設定することができ、多様な利用方法を安全に実現することが可能となる。
【０１７４】
次に、図２３のフローチャートを参照して、図２０のステップＳ１１５において実行されるアクセス許諾チケット生成鍵生成処理の流れの例を説明する。なお、以下においてはICカード１２−１において実行される場合について説明するが、以下の説明は、他のICカード１２において実行される場合も適用可能である。
【０１７５】
アクセス許諾チケット生成鍵生成処理が開始されると、アクセス許諾チケット生成鍵生成部４２は、ステップＳ１３１において、アクセス許諾チケット（Ticket１−１）に記述されているアクセスコードのリストを参照し、そのリストに含まれるアクセスコードに対応するアクセス制御鍵を記憶部３１−１より取得する。
【０１７６】
アクセス制御鍵を取得すると、アクセス許諾チケット生成鍵生成部４２は、ステップＳ１３２において、取得したアクセス制御鍵を、アクセス許諾チケット（Ticket１−１）に記述されているアクセスコードのリストと同順に整列させる。
【０１７７】
ステップＳ１３４において、アクセス許諾チケット生成鍵生成部４２は、取得したアクセス制御鍵の中に、未使用のアクセス制御鍵が存在するか否かを判定し、存在すると判定した場合、ステップＳ１３５に処理を進め、暗号化部３６を制御し、次の順のアクセス制御鍵を用いて前回の暗号化結果をさらに暗号化させる。なお、１回目の暗号化の場合、アクセス許諾チケット生成鍵生成部４２は、暗号化部３６を制御し、第四のデータ（System Data）を最初のアクセス制御鍵で暗号化させる。暗号化が終了すると、アクセス許諾チケット生成鍵生成部４２は、処理をステップＳ１３４に戻す。つまり、ステップＳ１３４およびステップＳ１３５を繰り返すことにより、アクセス許諾チケット生成鍵生成部４２は、取得したアクセス制御鍵の全てを、その整列順に縮退化してアクセス許諾チケット生成鍵を生成する。
【０１７８】
ステップＳ１３４において、未使用のアクセス制御鍵が存在しないと判定した場合、アクセス許諾チケット生成鍵生成部４２は、アクセス許諾チケット生成鍵生成処理を終了し、図２０のステップＳ１１５に処理を戻し、それ以降の処理を実行させる。
【０１７９】
このようにアクセス制御鍵を縮退化してアクセス許諾チケット生成鍵を生成することにより、ファイルアクセス処理部３４は、アクセス制御チケット（Ticket１−１）の検証をより正確かつ高速に行うことができる。つまり、ファイルへの複数のアクセス方法などを規定したアクセス許諾チケットに対し、複数の鍵を持って正当性検証を、１度の処理で行わせることができるようになり、セキュリティレベルの低下を防止するとともに、通信路を経由して複数回データの送受信を繰り返すことによる遅延を抑制し、高速に検証を行うことができる。
【０１８０】
なお、図２０のアクセス制御の処理において、ICカード１２−１のファイルアクセス処理部３４が、ステップＳ１１３において、アクセス許諾チケット（Ticket１−１）に記述されているアクセスコードが認証済みのディレクトリのものでない場合、許諾要求を拒否するように説明したが、これに限らず、アクセス許諾チケット（Ticket１−１）に記述されているアクセスコードが認証済みのディレクトリのものでない場合も構わず許諾するようにしてもよい。例えば、他事業者に自分の管理しているファイルにアクセスさせる必要があるような場合、アクセスを許諾する方が都合がよい。その場合、ステップＳ１１３の処理を省略すればよい。
【０１８１】
例えば、事業者１と事業者２があったとし、事業者１の管理するディレクトリに、顧客の名前などの個人情報を保持するファイルを持たせたとする。ある時、事業者１が事業者２と提携し、事業者１のお客には事業者２のサービスで便宜を図ってもらいたいとするなら、例えば、事業者１の顧客の名前を事業者２に読み出せるようにするのが好ましい。その場合、事業者２の情報処理端末１１が事業者１のディレクトリ内のデータにアクセスする必要が生じる。このとき、仮に、上述したように、アクセス許諾チケット（Ticket１−１）に記述されているアクセスコードが認証済みのディレクトリのものでない場合許諾要求が拒否されるとすると、相互認証時に事業者１のディレクトリを含めて相互認証しなければならないが、その場合、事業者１のディレクトリのアプリケーション鍵を生成するマスタ鍵を事業者２に教えなければならない。あるいは、事業者２の情報処理端末固有の鍵を生成する際に、事業者２に協力するか、事業者２の情報処理端末固有の鍵を作るために、事業者１のディレクトリ鍵を教える必要が生じる。
【０１８２】
より具体的な例を図２４に示す。図２４に示される情報処理端末１１−１−１は、事業者１の情報処理端末１１であり、情報処理端末１１−２−１は、事業者２の情報処理端末１１である。情報処理端末１１−１−１の記憶部２１−１−１には、情報処理端末１１−１−１のID（ID１−１）、情報処理端末１１−１−１固有の鍵（Ｋ１−１）、事業者１の情報処理端末１１のICカード１２用のマスタ鍵（MK１−１−ICおよびMK１−２−IC）、および情報処理端末１１−１−１に割り当てられたアクセス制御チケット（Ticket１−１）が書き込まれている。情報処理端末１１−２−１の記憶部２１−２−１には、情報処理端末１１−２−１のID（ID２−１）、情報処理端末１１−２−１固有の鍵（Ｋ２−１）、事業者２の情報処理端末１１のICカード１２用のマスタ鍵（MK２−２−IC）、および情報処理端末１１−２−１に割り当てられたアクセス制御チケット（Ticket２−１）が書き込まれている。
【０１８３】
アクセス制御チケット（Ticket２−１）には、このチケットの使用者のID（ID２−１）、アクセスコードのリスト（１−１−１，２−２−１）、および、チェック子（MAC）が記述されている。
【０１８４】
また、図２４に示されるICカード１２−１とICカード１２−２は、情報処理端末１１よりアクセスされる、ユーザが互いに異なるICカード１２である。
【０１８５】
ICカード１２−１の記憶部３１−１には、第一のデータ（ＫSystem）、第三のデータ（ＫSystem2）、およびルート鍵（ＫRoot）が書き込まれ、さらに、事業者１用のディレクトリとしてディレクトリ１−１およびディレクトリ１−２、事業者２用のディレクトリとしてディレクトリ２−２がそれぞれ形成されている。
【０１８６】
ディレクトリ１−１には、ディレクトリ鍵（DirK１−１）、アプリケーションID（AppID１−１−１）、およびアプリケーション鍵（AppＫ１−１−１）が書き込まれている。また、ディレクトリ１−１には、２つのアクセス制御鍵（ACK１−１−１およびACK１−１−２）が用意されている。ディレクトリ１−２には、ディレクトリ鍵（DirK１−２）、アプリケーションID（AppID１−２）、およびアプリケーション鍵（AppＫ１−２）が書き込まれている。また、ディレクトリ１−２には、２つのアクセス制御鍵（ACK１−２−１およびACK１−２−２）が用意されている。ディレクトリ２−２には、ディレクトリ鍵（DirK２−２）、アプリケーションID（AppID２−２−１）、およびアプリケーション鍵（AppＫ２−２−１）が書き込まれている。また、ディレクトリ２−２には、２つのアクセス制御鍵（ACK２−２−１およびACK２−２−２）が用意されている。
【０１８７】
ICカード１２−２の記憶部３１−２には、第一のデータ（ＫSystem）、第三のデータ（ＫSystem2）、およびルート鍵（ＫRoot）が書き込まれ、さらに、事業者１用のディレクトリとしてディレクトリ１−１、事業者２用のディレクトリとしてディレクトリ２−１およびディレクトリ２−２がそれぞれ形成されている。
【０１８８】
ディレクトリ１−１には、ディレクトリ鍵（DirK１−１）、アプリケーションID（AppID１−１−２）、およびアプリケーション鍵（AppＫ１−１−２）が書き込まれている。また、ディレクトリ１−１には、２つのアクセス制御鍵（ACK１−１−１およびACK１−１−２）が用意されている。ディレクトリ２−１には、ディレクトリ鍵（DirK２−１）、アプリケーションID（AppID２−１）、およびアプリケーション鍵（AppＫ２−１）が書き込まれている。また、ディレクトリ２−１には、２つのアクセス制御鍵（ACK２−１−１およびACK２−１−２）が用意されている。ディレクトリ２−２には、ディレクトリ鍵（DirK２−２）、アプリケーションID（AppID２−２−２）、およびアプリケーション鍵（AppＫ２−２−２）が書き込まれている。また、ディレクトリ２−２には、２つのアクセス制御鍵（ACK２−２−１およびACK２−２−２）が用意されている。
【０１８９】
このような例において、事業者２の情報処理端末１１−２−１が、図２４において矢印で示されるように、ICカード１２−１のディレクトリ１−１とディレクトリ２−２にアクセスするとする。
【０１９０】
事業者２（および事業者１）は、システム管理者から第二のデータと第四のデータの提示を受けている。事業者２が情報処理端末１１−２−１の鍵を設定する際には、情報処理端末１１用のマスタ鍵が必要であり、その情報処理端末１１用のマスタ鍵は、第二のデータを各ディレクトリ鍵で暗号化することにより得られる。つまり、相互認証において、ICカード１２−１のディレクトリ１−１とディレクトリ２−２にアクセスすることを認証してもらうためには、DirK１−１とDirK２−２が必要となる。そのためには、事業者１が事業者２にDirK１−１を教えるか、最初に、事業者２が第二のデータをDirK２−２で暗号化し、その暗号化出力を事業者１に提供し、事業者１によってその暗号化出力をDirK１−１で暗号化してもらうしかない。
【０１９１】
事業者１が事業者２にDirK１−１を教えるのは、ディレクトリ鍵の変更処理などが勝手になされる危険性があるため、セキュリティ上、事業者１にとって望ましくない。逆に、事業者２が暗号化出力を事業者１に提供する方法は、DirK２−２を教えたことにはならないが、その暗号化出力を教えているため、事業者２が運用する情報処理端末１１用のマスタ鍵を教えたことと略同義となってしまう。つまり、事業者１は、ディレクトリ２−２を含む情報処理端末１１用のマスタ鍵を生成し得ることになる。
【０１９２】
仮に、ディレクトリ鍵の問題が解決したとしても、事業者２の情報処理端末１１−２−１が事業者１の領域にアクセスするためには、事業者１のICカード１２用のマスタ鍵を知らなければならない。つまり、事業者１は、事業者２に対してMK１−１−ICを教えなければならない。
【０１９３】
以上から、相互認証において、情報処理端末１１−２−１が事業者１の領域へのアクセスを可能とするように、情報処理端末１１−２−１をICカード１２に認証させることは困難である。従って、ディレクトリ認証をパスしない領域にもアクセスすることができるようにしないと不都合が生じると考えられる。
【０１９４】
しかしながら、上述したように認証してない領域に無条件にアクセス可能とするのは論理上望ましくない。そこで、以下のように処理を行うようにしてもよい。
【０１９５】
まず、相互認証時において、事業者２の情報処理端末１１−２−１の記憶部２１−２−１には、ID２−１とK２−１が書き込まれている。Ｋ２−１を生成するマスタ鍵は、第二のデータをDirK２−２で暗号化して生成する。従って、相互認証はディレクトリ２−２だけで行うことになる。情報処理端末１１−２−１が送る相互認証開始コマンドには、ID２−１とディレクトリコード（Directory Code）である２−２と第一の乱数が添付される。
【０１９６】
これを受信したICカード１２−１は、第二のデータとDirK２−２とから情報処理端末１１−２−１固有の鍵を生成するマスタ鍵（MK２−１−IT）を生成する。このマスタ鍵（MK２−１−IT）とID２−１とからＫ２−１を生成する。そして、AppID２−２−１をＫ２−１で暗号化する（第一の返信文）。続けて、Ｋ２−１をAppK２−２−１で暗号化し、認証鍵（ＫAuth）を生成する。その後、ICカード１２−１は、第一の乱数、生成した第二の乱数、ID２−１を認証鍵で暗号化（第二の返信文）し、第一の返信文と共に情報処理端末１１−２−１に返信する。なお、このときの暗号化方法は、CBC（Cipher Block Chaining）モード等の暗号利用モードを用いることとする。
【０１９７】
第一の返信文および第二の返信文を受け取った情報処理端末１１−２−１は、自身の鍵Ｋ２−１で第一の返信文を復号し、AppID２−２−１を取り出す。そして、このAppID２−２−１とMK２−２−ICとから、AppK２−２−１を生成する。そして、自身の鍵Ｋ２−１をAppK２−２−１で暗号化し、認証鍵（ＫAuth）を生成する。さらに、その認証鍵（ＫAuth）で第二の返信文を復号し、第一の乱数の正当性を評価する。その後、セッション鍵を生成し、第一の乱数、第二の乱数と共に認証鍵（ＫAuth）で暗号化し、第二の相互認証コマンドに添付してICカード１２−１に送信する。
【０１９８】
これを受信したICカード１２−１は、乱数等を認証鍵（ＫAuth）で復号し、第二の乱数の正当性を評価し、レスポンスを返す。
【０１９９】
情報処理端末１１−２−１は、アクセス許諾チケット（Ticket２−１）を提示してファイルアクセス許可命令を発行する。これを受け取ったICカード１２−１は、使用者のチェック（Ticket２−１内のチケット使用者と、相互認証時に受け取った情報処理端末のID２−１の比較）後、アクセスコードをチェックする。アクセスコード２−２−１は相互認証時に検証したディレクトリだから認証されるが、アクセスコード１−１−１については検証していない。このような場合、ICカード１２−１（ファイルアクセス処理部３４のアクセス許諾チケット生成鍵生成部４２）が、アクセス許諾チケット生成鍵を作る際に、ディレクトリ鍵を含ませるようにする。
【０２００】
例えば、ICカード１２−１（ファイルアクセス処理部３４のアクセス許諾チケット生成鍵生成部４２）が、第四のデータをDirK１−１で暗号化した後、ACK１−１−１、ACK２−２−１で暗号化してアクセス許諾チケット生成鍵を生成するようにする。そして、ICカード１２−１（ファイルアクセス処理部３４のアクセス許諾チケット生成鍵生成部４２）は、このアクセス許諾チケット生成鍵でMAC値を検証し、正しければアクセスを許諾する。なお、アクセス許諾チケット生成鍵を生成するために、第四のデータをDirK１−１で暗号化するのは事業者１が行い、それをACK１−１−１で暗号化するのも事業者１が行う。その後、事業者２に引き渡し、ACK２−２−１で暗号化を行う。ただし、もっと多くのディレクトリが関与する場合、いろいろな事業者に鍵の中間値を引き渡す必要がある。
【０２０１】
このようにすることで、ICカード１２側としては、認証時にディレクトリの鍵は使っていなかったが、アクセス許諾チケットを検証する際に、必要なディレクトリの鍵の検証を間接的に行っているため、筋が通ることになる。なお、この例ではAppK１−１−１が使われていないが、アクセスチケット生成鍵を生成する際に、DirK１−１の後にAppK１−１−１を使用する（AppK１−１−１を用いて暗号化する）ようにしてもよい。
【０２０２】
なお、アクセスコード１−１−１とアクセスコード２−２−１にアクセスするアクセス許諾チケット生成鍵であるが、これを保有するものが事業者１の場合（つまり、事業者２が事業者１のために暗号化処理を行ってあげる場合）、事業者２のみが知り得るDirK２−２、ACK２−２−１を使ったアクセス許諾チケット生成鍵が事業者１に渡されることになる。ところが、DirK２−２、ACK２−２−１が教えられた訳ではない。また、上で説明したように、DirK２−２、ACK２−２−１は使われているが、AppK２−２―２は一切使用されていない。よって、このチケットを使って、勝手にディレクトリ２−２内の他のファイルにアクセスすることができないのである。つまり、事業者２からしてみると安全といえる。
【０２０３】
なお、上述した例では自身のディレクトリと他事業者のディレクトリを混載させていたが、わかりやすくするためにチケットを分けるようにしてもよい。つまり、認証済みの領域だけが入ったチケットと、認証が済んでいない領域（しかも、管理している事業者毎）だけが入ったチケットに分け、必要に応じてアクセス許諾命令を複数回出す。このようにすることで、アクセス許諾チケット生成鍵を生成する際に、途中結果をいろいろな人に引き渡す必要がなくなる。
【０２０４】
なお、以上においては、システム鍵を認証鍵用とアクセス許諾チケット生成鍵用の２種類用意するように説明した。上述したように、アクセス許諾チケット生成鍵を他事業者向けに生成する時、ディレクトリ鍵（DirK）を使用している。すると、第三のデータが第一のデータと同一であると、アクセス許諾チケット生成鍵生成過程において、情報処理端末１１のマスタ鍵生成過程と一部似ている状態が出てきてしまう。必ずACKを掛け合わせているものの、例えば、第四のデータをDirK１−１で事業者１が暗号化し、この中間値を事業者２に渡し、再度事業者１に渡してACK１−１−１で暗号化した後、再度事業者２に渡してACK２−２−１で暗号化する場合について想定する。このような場合において、仮に、第四のデータではなく、第二のデータであるとすると、事業者２は第二のデータをDir１−１で暗号化した出力を入手することができたことになり、この出力は、Dir1-1にアクセスする情報処理端末１１に対する個別鍵を生成するマスタ鍵であり、これを不正に入手できたことになってしまう。
【０２０５】
従って、そうならないためにも、必ずDirKのあとACKで暗号化するのが望ましい。また、マスタ鍵や認証鍵を生成する時の元データ（第一のデータ）と、アクセス許諾チケット生成鍵を生成する時の元データ（第三のデータ）を互いに異なるものにするのが望ましい（異なっていれば、認証系とチケット系でDirKをかけた出力が異なるので問題がなくなる）。
【０２０６】
なお、情報処理端末１１とICカード１２と間の通信の、通信可能範囲の広さは任意であり、例えば、数メートル以上であってもよいし、数センチメートル以下であってもよい。また、通信方式も任意であり、無線通信ではなく有線通信としてもよい。その場合、ICカードは所謂接触型のICカードであり、情報処理端末１１とICカード１２には、ループアンテナの代わりに、互いを電気的に接続するための外部接続端子が設けられる。
【０２０７】
また、以上においては、通信システム１の装置としてICカードと情報処理端末を例にして説明したが、互いに通信可能なデバイスなら何でもよい。例えば、ICカード１２は、カード形状のデバイスでなくてもよく、例えば、切手形状のものや、５００円玉形状のものでもよい。また、例えば、ICカード機能を搭載する携帯電話機、音楽プレーヤ、デジタルカメラ、ノート型パーソナルコンピュータ、またはPDA（Personal Digital Assistants）などであってもよい。さらに、例えばデスクトップ型のパーソナルコンピュータのように、携帯型デバイスでなくてもよい。また、ICカード１２は、ユーザ（人）が携帯するものであってもよいし、機器等に組み込まれ、その機器の移動処理などに活用するものであってもよい。
【０２０８】
同様に、情報処理端末１１も、上述した機能を有し、ICカード１２と通信可能なものであればどのようなデバイスであってもよい。例えば、自動改札機、自動販売機、施錠ドア等に組み込まれているリーダ・ライタ等であってもよいし、ノート型パーソナルコンピュータ、PDA、デスクトップ型のパーソナルコンピュータ等に組み込まれたカードアクセスポートや、USB（Universal Serial Bus）接続された簡易リーダ・ライタなどの他に、リーダ・ライタ機能を搭載した携帯電話機等でもよい。
【０２０９】
上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウエアにより実行させることもできる。この場合、例えば、図２５に示されるようなパーソナルコンピュータとして構成されるようにしてもよい。
【０２１０】
図２５において、パーソナルコンピュータ２００のCPU２０１は、ROM（Read Only Memory）２０２に記憶されているプログラム、または記憶部２１３からRAM（Random Access Memory）２０３にロードされたプログラムに従って各種の処理を実行する。RAM２０３にはまた、CPU２０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【０２１１】
CPU２０１、ROM２０２、およびRAM２０３は、バス２０４を介して相互に接続されている。このバス２０４にはまた、入出力インタフェース２１０も接続されている。
【０２１２】
入出力インタフェース２１０には、キーボード、マウスなどよりなる入力部２１１、CRT（Cathode Ray Tube）やLCD（Liquid Crystal Display）などよりなるディスプレイ、並びにスピーカなどよりなる出力部２１２、ハードディスクなどより構成される記憶部２１３、モデムなどより構成される通信部２１４が接続されている。通信部２１４は、インターネットを含むネットワークを介しての通信処理を行う。
【０２１３】
入出力インタフェース２１０にはまた、必要に応じてドライブ２１５が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア２２１が適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部２１３にインストールされる。
【０２１４】
上述した一連の処理をソフトウエアにより実行させる場合には、そのソフトウエアを構成するプログラムが、ネットワークや記録媒体からインストールされる。
【０２１５】
この記録媒体は、例えば、図２５に示されるように、装置本体とは別に、ユーザにプログラムを配信するために配布される、プログラムが記録されている磁気ディスク（フレキシブルディスクを含む）、光ディスク（CD-ROM（Compact Disc - Read Only Memory）,DVD（Digital Versatile Disc）を含む）、光磁気ディスク（MD（Mini Disc）を含む）、もしくは半導体メモリなどよりなるリムーバブルメディア１２１により構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに配信される、プログラムが記録されているROM２０２や、記憶部２１３に含まれるハードディスクなどで構成される。
【０２１６】
なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０２１７】
また、本明細書において、システムとは、複数のデバイス（装置）により構成される装置全体を表わすものである。
【０２１８】
なお、以上において、一つの装置として説明した構成を分割し、複数の装置として構成するようにしてもよい。逆に、以上において複数の装置として説明した構成をまとめて一つの装置として構成されるようにしてもよい。また、各装置の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置の構成の一部を他の装置の構成に含めるようにしてもよい。つまり、本発明の実施の形態は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。
【図面の簡単な説明】
【０２１９】
【図１】本発明を適用した通信システムの主な構成例を示すブロック図である。
【図２】各デバイスが保持する情報の例を示す図である。
【図３】ICカードの記憶部の記憶領域の構成例を説明する模式図である。
【図４】データ設定処理の流れの例を説明するフローチャートである。
【図５】データ列の構成例を示す図である。
【図６】データ列の構成例を示す図である。
【図７】データ列の構成例を示す図である。
【図８】データ列の構成例を示す図である。
【図９】データ列の構成例を示す図である。
【図１０】データ列の構成例を示す図である。
【図１１】相互認証処理の流れの例を説明するフローチャートである。
【図１２】相互認証処理の流れの例を説明する、図７に続くフローチャートである。
【図１３】認証処理部の詳細な構成例を説明する機能ブロック図である。
【図１４】認証処理部の詳細な構成例を説明する機能ブロック図である。
【図１５】認証処理部の詳細な構成例を説明する機能ブロック図である。
【図１６】認証処理部の詳細な構成例を説明する機能ブロック図である。
【図１７】マスタ鍵生成処理の流れの例を説明するフローチャートである。
【図１８】各デバイスが保持する情報の、他の例を示す図である。
【図１９】アクセス許諾チケットの記述例を示す模式図である。
【図２０】アクセス制御処理の流れ居の例を説明するフローチャートである。
【図２１】ファイルアクセス処理部の詳細な構成例を説明する機能ブロック図である。
【図２２】アクセス許諾チケット生成鍵生成部の詳細な構成例を説明する機能ブロック図である。
【図２３】アクセス許諾チケット生成鍵生成処理の流れ居の例を説明するフローチャートである。
【図２４】各デバイスが保持する情報の、さらに他の例を示す図である。
【図２５】本発明を適用したパーソナルコンピュータの構成例を示すブロック図である。
【符号の説明】
【０２２０】
１ 通信システム， １１ 情報処理端末， １２ ICカード， ２１ 記憶部， ２３ 認証処理部， ２４ ファイルアクセス処理部， ２５ 乱数生成部， ２６ 暗号化部， ２７ 復号部， ２８ 通信部， ３１ 記憶部， ３２ データ設定処理部， ３３ 認証処理部， ３４ ファイルアクセス処理部， ３５ 乱数生成部， ３６ 暗号化部， ３７ 復号部， ３８ 通信部， ４１ マスタ鍵生成部， ４２ アクセス許諾チケット生成鍵生成部
【特許請求の範囲】
【請求項１】
他の情報処理装置より、自分自身が保持するデータに対してアクセスを要求される情報処理装置であって、
前記他の情報処理装置の認証処理を行う認証手段と、
前記認証手段により正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信する受信手段と、
予め保持する所定のデータ、ルートディレクトリに対応する鍵情報であるルート鍵、並びに、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成するアクセス許諾チケット生成鍵生成手段と、
前記アクセス許諾チケット生成鍵生成手段により生成された前記アクセス許諾チケット生成鍵を用いて、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出するチェック子算出手段と、
前記チェック子算出手段により算出された前記チェック子を用いて、前記受信手段により受信された前記アクセス許諾チケットを検証するアクセス許諾チケット検証手段と
を備える情報処理装置。
【請求項２】
前記アクセス許諾チケットは、前記他の情報処理装置のIDをさらに含み、
前記受信手段により受信された前記アクセス許諾チケットに記述される前記他の情報処理装置のIDが、前記認証手段により認証済みの他の情報処理装置のIDであるか否かを検証するID検証手段をさらに備える
請求項１に記載の情報処理装置。
【請求項３】
所定のIDが特別なIDであるオールマイティIDとして予め設定されており、
前記ID検証手段は、前記アクセス許諾チケットに前記オールマイティIDが記述されている場合、認証済みのIDの如何に関わらず、アクセス制御チケットの使用者を許諾させる
請求項１に記載の情報処理装置。
【請求項４】
前記アクセス許諾チケット生成鍵の生成に使用される前記所定のデータは、前記認証手段による認証処理において認証用の鍵情報の生成に用いられる所定のデータとは異なるデータとして予め保持する
請求項１に記載の情報処理装置。
【請求項５】
前記アクセス許諾チケットに記述されるアクセスコードが、前記認証処理においてアクセス先として認証されたディレクトリのアクセスコードであるか否かを確認する確認手段をさらに備える
請求項１に記載の情報処理装置。
【請求項６】
前記確認手段により前記認証処理においてアクセス先として認証されていないディレクトリのアクセスコードが含まれることが確認された場合、アクセスを拒絶する拒絶手段をさらに備える
請求項５に記載の情報処理装置。
【請求項７】
前記拒絶手段は、前記認証処理においてアクセス先として認証されていないディレクトリのアクセスコードについてのみアクセスを拒絶する
請求項６に記載の情報処理装置。
【請求項８】
前記アクセス許諾チケット生成鍵生成手段は、前記確認手段により前記認証処理においてアクセス先として認証されていない領域のアクセスコードが含まれることが確認された場合、前記アクセス許諾チケット生成鍵の生成において、さらに、前記アクセスコードに対応するディレクトリの鍵情報であるディレクトリ鍵を使用する
請求項５に記載の情報処理装置。
【請求項９】
前記アクセス許諾チケット生成鍵生成手段は、予め保持する前記所定のデータを前記ルート鍵で暗号化し、その暗号化結果をさらに各ディレクトリ鍵で１つずつ暗号化し、さらにその暗号化結果を、各アクセス制御鍵で１つずつ暗号化することにより、各鍵情報を縮退化して前記アクセス許諾チケット生成鍵を生成する
請求項１に記載の情報処理装置。
【請求項１０】
他の情報処理装置より、自分自身が保持するデータに対してアクセスを要求される情報処理装置の情報処理方法であって、
前記他の情報処理装置の認証処理を行い、
正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信し、
予め保持する所定のデータ、ルートディレクトリに対応する鍵情報であるルート鍵、並びに、受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成し、
生成された前記アクセス許諾チケット生成鍵を用いて、前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出し、
算出された前記チェック子を用いて、前記アクセス許諾チケットを検証する
ステップを含む情報処理方法。
【請求項１１】
他の情報処理装置より、自分自身が保持するデータに対してアクセスを要求される情報処理装置を制御するプログラムであって、
前記他の情報処理装置の認証処理を行い、
正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信し、
予め保持する所定のデータ、ルートディレクトリに対応する鍵情報であるルート鍵、並びに、受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成し、
生成された前記アクセス許諾チケット生成鍵を用いて、前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出し、
算出された前記チェック子を用いて、前記アクセス許諾チケットを検証する
ステップを含むコンピュータが読み取り可能なプログラムが記録されている記録媒体。
【請求項１２】
他の情報処理装置より、自分自身が保持するデータに対してアクセスを要求されるコンピュータに実行させるプログラムにおいて、
前記他の情報処理装置の認証処理を行い、
正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信し、
予め保持する所定のデータ、ルートディレクトリに対応する鍵情報であるルート鍵、並びに、受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成し、
生成された前記アクセス許諾チケット生成鍵を用いて、前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出し、
算出された前記チェック子を用いて、前記アクセス許諾チケットを検証する
ステップを含む情報処理をコンピュータに実行させるプログラム。
【請求項１３】
第一の情報処理装置が、第二の情報処理装置が保持するデータに対してアクセスを要求する情報処理システムであって、
前記第一の情報処理装置は、
前記第二の情報処理装置と相互認証処理を行う第一の相互認証手段と、
アクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを前記第二の情報処理装置に送信する送信手段と
を備え、
前記第二の情報処理装置は、
前記第一の情報処理装置と相互認証処理を行う第二の相互認証手段と、
前記第二の相互認証手段により正当な相手であると認証された前記第一の情報処理装置より、前記第一の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信する受信手段と、
予め保持する所定のデータ、ルートディレクトリに対応する鍵情報であるルート鍵、並びに、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成するアクセス許諾チケット生成鍵生成手段と、
前記アクセス許諾チケット生成鍵生成手段により生成された前記アクセス許諾チケット生成鍵を用いて、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出するチェック子算出手段と、
前記チェック子算出手段により算出された前記チェック子を用いて、前記受信手段により受信された前記アクセス許諾チケットを検証するアクセス許諾チケット検証手段と
を備える情報処理システム。
【請求項１】
他の情報処理装置より、自分自身が保持するデータに対してアクセスを要求される情報処理装置であって、
前記他の情報処理装置の認証処理を行う認証手段と、
前記認証手段により正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信する受信手段と、
予め保持する所定のデータ、ルートディレクトリに対応する鍵情報であるルート鍵、並びに、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成するアクセス許諾チケット生成鍵生成手段と、
前記アクセス許諾チケット生成鍵生成手段により生成された前記アクセス許諾チケット生成鍵を用いて、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出するチェック子算出手段と、
前記チェック子算出手段により算出された前記チェック子を用いて、前記受信手段により受信された前記アクセス許諾チケットを検証するアクセス許諾チケット検証手段と
を備える情報処理装置。
【請求項２】
前記アクセス許諾チケットは、前記他の情報処理装置のIDをさらに含み、
前記受信手段により受信された前記アクセス許諾チケットに記述される前記他の情報処理装置のIDが、前記認証手段により認証済みの他の情報処理装置のIDであるか否かを検証するID検証手段をさらに備える
請求項１に記載の情報処理装置。
【請求項３】
所定のIDが特別なIDであるオールマイティIDとして予め設定されており、
前記ID検証手段は、前記アクセス許諾チケットに前記オールマイティIDが記述されている場合、認証済みのIDの如何に関わらず、アクセス制御チケットの使用者を許諾させる
請求項１に記載の情報処理装置。
【請求項４】
前記アクセス許諾チケット生成鍵の生成に使用される前記所定のデータは、前記認証手段による認証処理において認証用の鍵情報の生成に用いられる所定のデータとは異なるデータとして予め保持する
請求項１に記載の情報処理装置。
【請求項５】
前記アクセス許諾チケットに記述されるアクセスコードが、前記認証処理においてアクセス先として認証されたディレクトリのアクセスコードであるか否かを確認する確認手段をさらに備える
請求項１に記載の情報処理装置。
【請求項６】
前記確認手段により前記認証処理においてアクセス先として認証されていないディレクトリのアクセスコードが含まれることが確認された場合、アクセスを拒絶する拒絶手段をさらに備える
請求項５に記載の情報処理装置。
【請求項７】
前記拒絶手段は、前記認証処理においてアクセス先として認証されていないディレクトリのアクセスコードについてのみアクセスを拒絶する
請求項６に記載の情報処理装置。
【請求項８】
前記アクセス許諾チケット生成鍵生成手段は、前記確認手段により前記認証処理においてアクセス先として認証されていない領域のアクセスコードが含まれることが確認された場合、前記アクセス許諾チケット生成鍵の生成において、さらに、前記アクセスコードに対応するディレクトリの鍵情報であるディレクトリ鍵を使用する
請求項５に記載の情報処理装置。
【請求項９】
前記アクセス許諾チケット生成鍵生成手段は、予め保持する前記所定のデータを前記ルート鍵で暗号化し、その暗号化結果をさらに各ディレクトリ鍵で１つずつ暗号化し、さらにその暗号化結果を、各アクセス制御鍵で１つずつ暗号化することにより、各鍵情報を縮退化して前記アクセス許諾チケット生成鍵を生成する
請求項１に記載の情報処理装置。
【請求項１０】
他の情報処理装置より、自分自身が保持するデータに対してアクセスを要求される情報処理装置の情報処理方法であって、
前記他の情報処理装置の認証処理を行い、
正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信し、
予め保持する所定のデータ、ルートディレクトリに対応する鍵情報であるルート鍵、並びに、受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成し、
生成された前記アクセス許諾チケット生成鍵を用いて、前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出し、
算出された前記チェック子を用いて、前記アクセス許諾チケットを検証する
ステップを含む情報処理方法。
【請求項１１】
他の情報処理装置より、自分自身が保持するデータに対してアクセスを要求される情報処理装置を制御するプログラムであって、
前記他の情報処理装置の認証処理を行い、
正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信し、
予め保持する所定のデータ、ルートディレクトリに対応する鍵情報であるルート鍵、並びに、受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成し、
生成された前記アクセス許諾チケット生成鍵を用いて、前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出し、
算出された前記チェック子を用いて、前記アクセス許諾チケットを検証する
ステップを含むコンピュータが読み取り可能なプログラムが記録されている記録媒体。
【請求項１２】
他の情報処理装置より、自分自身が保持するデータに対してアクセスを要求されるコンピュータに実行させるプログラムにおいて、
前記他の情報処理装置の認証処理を行い、
正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信し、
予め保持する所定のデータ、ルートディレクトリに対応する鍵情報であるルート鍵、並びに、受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成し、
生成された前記アクセス許諾チケット生成鍵を用いて、前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出し、
算出された前記チェック子を用いて、前記アクセス許諾チケットを検証する
ステップを含む情報処理をコンピュータに実行させるプログラム。
【請求項１３】
第一の情報処理装置が、第二の情報処理装置が保持するデータに対してアクセスを要求する情報処理システムであって、
前記第一の情報処理装置は、
前記第二の情報処理装置と相互認証処理を行う第一の相互認証手段と、
アクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを前記第二の情報処理装置に送信する送信手段と
を備え、
前記第二の情報処理装置は、
前記第一の情報処理装置と相互認証処理を行う第二の相互認証手段と、
前記第二の相互認証手段により正当な相手であると認証された前記第一の情報処理装置より、前記第一の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信する受信手段と、
予め保持する所定のデータ、ルートディレクトリに対応する鍵情報であるルート鍵、並びに、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成するアクセス許諾チケット生成鍵生成手段と、
前記アクセス許諾チケット生成鍵生成手段により生成された前記アクセス許諾チケット生成鍵を用いて、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出するチェック子算出手段と、
前記チェック子算出手段により算出された前記チェック子を用いて、前記受信手段により受信された前記アクセス許諾チケットを検証するアクセス許諾チケット検証手段と
を備える情報処理システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【公開番号】特開２００９−１０５８５６（Ｐ２００９−１０５８５６Ａ）
【公開日】平成２１年５月１４日（２００９．５．１４）
【国際特許分類】
【出願番号】特願２００７−２７８１１８（Ｐ２００７−２７８１１８）
【出願日】平成１９年１０月２５日（２００７．１０．２５）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
【公開日】平成２１年５月１４日（２００９．５．１４）
【国際特許分類】
【出願日】平成１９年１０月２５日（２００７．１０．２５）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
[ Back to top ]