JP2009258860A - 情報処理装置および方法、記録媒体、プログラム、並びに情報処理システム - Google Patents

情報処理装置および方法、記録媒体、プログラム、並びに情報処理システム Download PDF

Info

Publication number
JP2009258860A
JP2009258860A JP2008105023A JP2008105023A JP2009258860A JP 2009258860 A JP2009258860 A JP 2009258860A JP 2008105023 A JP2008105023 A JP 2008105023A JP 2008105023 A JP2008105023 A JP 2008105023A JP 2009258860 A JP2009258860 A JP 2009258860A
Authority
JP
Japan
Prior art keywords
key
access
information processing
information
permission ticket
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2008105023A
Other languages
English (en)
Inventor
Yoshito Ishibashi
義人 石橋
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Priority to JP2008105023A priority Critical patent/JP2009258860A/ja
Priority to US12/419,730 priority patent/US8239681B2/en
Publication of JP2009258860A publication Critical patent/JP2009258860A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H04L9/3273—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response for mutual authentication

Abstract

【課題】複数のセキュア管理領域に対し、安全かつ確実に相互認証及びアクセス制御を行うことができるようにする。
【解決手段】アクセス許諾チケット生成鍵生成部の暗号化処理部（AES）３５１は、第三のデータ（ＫSystem2）を、ルート鍵（ＫRoot）により暗号化し、第四のデータ（System Data）を生成する。暗号化処理部（AES）３５２は、第四のデータ（System Data）を、エリア鍵AK１を用いて暗号化する。暗号化処理部（AES）３５３は、その暗号化結果を、サービス鍵SK１−２を用いて暗号化する。暗号化処理部（AES）３５４は、その暗号化結果を、ACK７−２を用いて暗号化し、アクセス許諾チケット生成鍵（A.C.Gen.Key）を生成する。本発明は、例えば、通信システムに適用することができる。
【選択図】図３２

Description

本発明は、情報処理装置および方法、記録媒体、プログラム、並びに情報処理システムに関し、特に、複数のセキュア管理領域に対し、安全かつ確実に相互認証及びアクセス制御を行うことができるようにした情報処理装置および方法、記録媒体、プログラム、並びに情報処理システムに関する。
近年、電子マネーに代表される、非接触IC（Integrated Circuit）カードが多方面で利用されるようになってきている。特に、リーダ・ライタ等の店舗設備、ユーザが持つ非接触ＩＣカードが広範に保持されるようになり、生活の基本インフラになりつつある（例えば、特許文献１参照）。
このような中でも、現在の非接触ICカードだけでは（その性能において）満足できないことも多々あり、技術革新が待たれている。例えば、処理速度、通信距離、情報セキュリティ強度などである。
ところが、これだけ広範に広まってくると、一朝一夕にシステムを変更することは容易ではない。そこで、従来から行われてきたように、当面はシステムを二重化し、徐々に移行していくと言うことが考えられる。
特許３７０２９２３号公報
しかしながら、従来の方式と新しい方式においては、情報セキュリティレベル及び方式が異なっていることが普通であり、同時に両方の領域をアクセスすると言うことが難しかった。特に、両方の処理が完結した時のみ、その処理を有効とするなどが困難であった。
一方、従来の技術においては、電子マネーの残高を減額し、それで購入した電子チケットをICカードに書き込むと言う処理を行う際に、電子チケットが書き込めなかったら電子マネーの残高減額が無効になる、などの処理がきちんと行えていた。
ところが、新しい管理方式で管理された領域の電子マネーを、古い管理方式で管理された領域の電子マネーに移動しようとした場合などにおいては、一旦新しい電子マネーから移動金額を引き出し、この値をシステム等に保持し、再度古い電子マネーに移し替える必要が生じる。これは、それぞれの認証方式、情報管理方式が異なっているからである。しかしながら、古い電子マネーに値を移し替える前にICカードが通信可能領域から離脱してしまった場合、移動すべき電子マネーの行き場所がなくなってしまうという問題点が残ってしまう。
本発明はこのような状況に鑑みてなされたものであり、複数のセキュア管理領域に対し、安全かつ確実に相互認証及びアクセス制御を行うことができるようにするものである。
本発明の第１の側面は、他の情報処理装置より、自分自身が保持する、情報管理方式が互いに異なる複数の領域のデータに対してアクセスを要求される情報処理装置であって、前記他の情報処理装置のアクセス先のうち、前記複数の領域の中の所定の領域に対するアクセス先について、前記所定の領域の情報管理方式による前記他の情報処理装置の認証処理を行う認証手段と、前記認証手段により正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信する受信手段と、前記所定の領域に予め保持する所定のデータ、前記所定の領域のルートディレクトリに対応する鍵情報であるルート鍵、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応する、前記所定の領域内のデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵、並びに、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応する、前記所定の領域以外の領域のデータを管理する鍵情報であって、前記領域の情報管理方式による認証処理に使用される他の鍵情報を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成するアクセス許諾チケット生成鍵生成手段と、前記アクセス許諾チケット生成鍵生成手段により生成された前記アクセス許諾チケット生成鍵を用いて、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出するチェック子算出手段と、前記チェック子算出手段により算出された前記チェック子を用いて、前記受信手段により受信された前記アクセス許諾チケットを検証するアクセス許諾チケット検証手段とを備える情報処理装置である。
前記アクセス許諾チケット生成鍵生成手段は、前記他の鍵情報として、前記領域に対応する鍵情報であるエリア鍵と、アクセス先とされるデータのアクセス方法を制御するサービス鍵を使用することができる。
前記アクセス許諾チケット生成鍵生成手段は、前記アクセス制御鍵と、前記サービス鍵とで、鍵ビット長が互いに異なる場合、前記鍵ビット長が短いほうを、前記鍵ビット長が長い方に合わせるように前記鍵情報を整形することができる。
前記アクセス許諾チケット生成鍵生成手段は、前記所定のデータを前記ルート鍵で暗号化し、その暗号化結果をさらに、各他の鍵情報で１つずつ暗号化し、さらにその暗号化結果を、各アクセス制御鍵で１つずつ暗号化することにより、各鍵情報を縮退化して前記アクセス許諾チケット生成鍵を生成することができる。
本発明の第一の側面は、また、他の情報処理装置より、自分自身が保持する、情報管理方式が互いに異なる複数の領域のデータに対してアクセスを要求される情報処理装置の情報処理方法であって、前記他の情報処理装置のアクセス先のうち、前記複数の領域の中の所定の領域に対するアクセス先について、前記所定の領域の情報管理方式による前記他の情報処理装置の認証処理を行い、正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信し、前記所定の領域に予め保持する所定のデータ、前記所定の領域のルートディレクトリに対応する鍵情報であるルート鍵、受信された前記アクセス許諾チケットに記述されるアクセスコードに対応する、前記所定の領域内のデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵、並びに、受信された前記アクセス許諾チケットに記述されるアクセスコードに対応する、前記所定の領域以外の領域のデータを管理する鍵情報であって、前記領域の情報管理方式による認証処理に使用される他の鍵情報を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成し、生成された前記アクセス許諾チケット生成鍵を用いて、前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出し、算出された前記チェック子を用いて、前記アクセス許諾チケットを検証するステップステップを含む情報処理方法である。
本発明の第一の側面は、さらに、他の情報処理装置より、自分自身が保持する、情報管理方式が互いに異なる複数の領域のデータに対してアクセスを要求される情報処理装置を制御するプログラムであって、前記他の情報処理装置のアクセス先のうち、前記複数の領域の中の所定の領域に対するアクセス先について、前記所定の領域の情報管理方式による前記他の情報処理装置の認証処理を行い、正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信し、前記所定の領域に予め保持する所定のデータ、前記所定の領域のルートディレクトリに対応する鍵情報であるルート鍵、受信された前記アクセス許諾チケットに記述されるアクセスコードに対応する、前記所定の領域内のデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵、並びに、受信された前記アクセス許諾チケットに記述されるアクセスコードに対応する、前記所定の領域以外の領域のデータを管理する鍵情報であって、前記領域の情報管理方式による認証処理に使用される他の鍵情報を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成し、生成された前記アクセス許諾チケット生成鍵を用いて、前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出し、算出された前記チェック子を用いて、前記アクセス許諾チケットを検証するステップを含むコンピュータが読み取り可能なプログラムが記録されている記録媒体である。
本発明の第一の側面は、また、他の情報処理装置より、自分自身が保持する、情報管理方式が互いに異なる複数の領域のデータに対してアクセスを要求されるコンピュータに実行させるプログラムにおいて、前記他の情報処理装置のアクセス先のうち、前記複数の領域の中の所定の領域に対するアクセス先について、前記所定の領域の情報管理方式による前記他の情報処理装置の認証処理を行い、正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信し、前記所定の領域に予め保持する所定のデータ、前記所定の領域のルートディレクトリに対応する鍵情報であるルート鍵、受信された前記アクセス許諾チケットに記述されるアクセスコードに対応する、前記所定の領域内のデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵、並びに、受信された前記アクセス許諾チケットに記述されるアクセスコードに対応する、前記所定の領域以外の領域のデータを管理する鍵情報であって、前記領域の情報管理方式による認証処理に使用される他の鍵情報を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成し、生成された前記アクセス許諾チケット生成鍵を用いて、前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出し、算出された前記チェック子を用いて、前記アクセス許諾チケットを検証するステップを含む情報処理をコンピュータに実行させるプログラムである。
本発明の第二の側面は、第一の情報処理装置が、第二の情報処理装置が保持する、情報管理方式が互いに異なる複数の領域のデータに対してアクセスを要求する情報処理システムであって、前記第一の情報処理装置は、前記第二の情報処理装置と相互認証処理を行う第一の相互認証手段と、アクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを前記第二の情報処理装置に送信する送信手段とを備え、前記第二の情報処理装置は、前記第一の情報処理装置のアクセス先のうち、前記複数の領域の中の所定の領域に対するアクセス先について、前記所定の領域の情報管理方式による前記第一の情報処理装置の認証処理を行う認証手段と、前記認証手段により正当な相手であると認証された前記第一の情報処理装置より、前記アクセス許諾チケットを受信する受信手段と、前記所定の領域に予め保持する所定のデータ、前記所定の領域のルートディレクトリに対応する鍵情報であるルート鍵、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応する、前記所定の領域内のデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵、並びに、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応する、前記所定の領域以外の領域のデータを管理する鍵情報であって、前記領域の情報管理方式による認証処理に使用される他の鍵情報を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成するアクセス許諾チケット生成鍵生成手段と、前記アクセス許諾チケット生成鍵生成手段により生成された前記アクセス許諾チケット生成鍵を用いて、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出するチェック子算出手段と、前記チェック子算出手段により算出された前記チェック子を用いて、前記受信手段により受信された前記アクセス許諾チケットを検証するアクセス許諾チケット検証手段とを備える情報処理システムである。
本発明の第一の側面においては、他の情報処理装置のアクセス先のうち、複数の領域の中の所定の領域に対するアクセス先について、所定の領域の情報管理方式による他の情報処理装置の認証処理が行われ、正当な相手であると認証された他の情報処理装置より、他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットが受信され、所定の領域に予め保持する所定のデータ、所定の領域のルートディレクトリに対応する鍵情報であるルート鍵、受信されたアクセス許諾チケットに記述されるアクセスコードに対応する、所定の領域内のデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵、並びに、受信されたアクセス許諾チケットに記述されるアクセスコードに対応する、所定の領域以外の領域のデータを管理する鍵情報であって、領域の情報管理方式による認証処理に使用される他の鍵情報が使用されて、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵が生成され、生成されたアクセス許諾チケット生成鍵を用いて、アクセス許諾チケットに記述されるアクセスコードに対応するチェック子が算出され、算出されたチェック子を用いて、アクセス許諾チケットが検証される。
本発明の第二の側面においては、第一の情報処理装置において、第二の情報処理装置と相互認証処理が行われ、アクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットが第二の情報処理装置に送信され、第二の情報処理装置において、第一の情報処理装置のアクセス先のうち、複数の領域の中の所定の領域に対するアクセス先について、所定の領域の情報管理方式による第一の情報処理装置の認証処理が行われ、正当な相手であると認証された第一の情報処理装置より、アクセス許諾チケットが受信され、所定の領域に予め保持する所定のデータ、所定の領域のルートディレクトリに対応する鍵情報であるルート鍵、アクセス許諾チケットに記述されるアクセスコードに対応する、所定の領域内のデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵、並びに、アクセス許諾チケットに記述されるアクセスコードに対応する、所定の領域以外の領域のデータを管理する鍵情報であって、領域の情報管理方式による認証処理に使用される他の鍵情報が使用されて、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵が生成され、その生成されたアクセス許諾チケット生成鍵を用いて、アクセス許諾チケットに記述されるアクセスコードに対応するチェック子が算出され、その算出されたチェック子を用いて、アクセス許諾チケットが検証される。
本発明によれば、認証処理およびアクセス制御を行うことができる。特に、複数のセキュア管理領域に対し、安全かつ迅速に相互認証およびアクセス制御を行うことができる。
以下に本発明の実施の形態を説明するが、本発明の構成要件と、明細書または図面に記載の実施の形態との対応関係を例示すると、次のようになる。この記載は、本発明をサポートする実施の形態が、明細書または図面に記載されていることを確認するためのものである。従って、明細書または図面中には記載されているが、本発明の構成要件に対応する実施の形態として、ここには記載されていない実施の形態があったとしても、そのことは、その実施の形態が、その構成要件に対応するものではないことを意味するものではない。逆に、実施の形態が構成要件に対応するものとしてここに記載されていたとしても、そのことは、その実施の形態が、その構成要件以外の構成要件には対応しないものであることを意味するものでもない。
本発明の第１の側面は、他の情報処理装置（例えば、図２８の情報処理端末３１１）より、自分自身が保持する、情報管理方式が互いに異なる複数の領域のデータに対してアクセスを要求される情報処理装置（例えば、図２８のICカード３１２）であって、前記他の情報処理装置のアクセス先のうち、前記複数の領域の中の所定の領域に対するアクセス先について、前記所定の領域の情報管理方式による前記他の情報処理装置の認証処理を行う認証手段（例えば、図２８の認証処理部３２３）と、前記認証手段により正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信する受信手段（例えば、図３１のステップＳ３７１の処理を実行する図２８の通信部３３８）と、前記所定の領域に予め保持する所定のデータ、前記所定の領域のルートディレクトリに対応する鍵情報であるルート鍵、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応する、前記所定の領域内のデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵、並びに、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応する、前記所定の領域以外の領域のデータを管理する鍵情報であって、前記領域の情報管理方式による認証処理に使用される他の鍵情報を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成するアクセス許諾チケット生成鍵生成手段（例えば、図３１のステップＳ３７５の処理を実行する図２８のアクセス許諾チケット生成鍵生成部３４２）と、前記アクセス許諾チケット生成鍵生成手段により生成された前記アクセス許諾チケット生成鍵を用いて、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出するチェック子算出手段（例えば、図３１のステップＳ３７６の処理を実行する図２８のファイルアクセス処理部３３４）と、前記チェック子算出手段により算出された前記チェック子を用いて、前記受信手段により受信された前記アクセス許諾チケットを検証するアクセス許諾チケット検証手段（例えば、図３１のステップＳ３７７の処理を実行する図２８のファイルアクセス処理部３３４）とを備える。
前記アクセス許諾チケット生成鍵生成手段は、前記他の鍵情報として、前記領域に対応する鍵情報であるエリア鍵（例えば、図２７のAK１）と、アクセス先とされるデータのアクセス方法を制御するサービス鍵（例えば、図２７のSK１−１）を使用することができる。
本発明の第一の側面は、また、他の情報処理装置（例えば、図２８の情報処理端末３１１）より、自分自身が保持する、情報管理方式が互いに異なる複数の領域のデータに対してアクセスを要求される情報処理装置（例えば、図２８のICカード３１２）の情報処理方法、記録媒体、またはプログラムであって、前記他の情報処理装置のアクセス先のうち、前記複数の領域の中の所定の領域に対するアクセス先について、前記所定の領域の情報管理方式による前記他の情報処理装置の認証処理を行い（例えば、図２９および図３０の認証処理）、正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信し（例えば、図３１のステップＳ３７１）、前記所定の領域に予め保持する所定のデータ、前記所定の領域のルートディレクトリに対応する鍵情報であるルート鍵、受信された前記アクセス許諾チケットに記述されるアクセスコードに対応する、前記所定の領域内のデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵、並びに、受信された前記アクセス許諾チケットに記述されるアクセスコードに対応する、前記所定の領域以外の領域のデータを管理する鍵情報であって、前記領域の情報管理方式による認証処理に使用される他の鍵情報を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成し（例えば、図３１のステップＳ３７５）、生成された前記アクセス許諾チケット生成鍵を用いて、前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出し（例えば、図３１のステップＳ３７６）、算出された前記チェック子を用いて、前記アクセス許諾チケットを検証する（例えば、図３１のステップＳ３７７）ステップステップを含む。
以下、本発明の実施の形態について説明する。以下において、管理方式が互いに異なる複数のセキュア管理領域に対し、安全かつ確実に相互認証及びアクセス制御を行うことができるようにし、両領域においてデータの書き換えを行う際に、両領域間でデータの整合性を容易に保証することができるようにする方法について説明するが、最初に、相互認証およびファイルアクセス制御の各方法について説明する。
図１は、第一の方法で相互認証およびファイルアクセス制御を行う通信システムの主な構成例を示すブロック図である。
図１に示される通信システム１は、通信機能を有する情報処理端末１１およびIC（Integrated Circuit）カード１２の２つのデバイスよりなり、情報処理端末１１とICカード１２が互いに通信を行い、情報を授受するシステムである。情報処理端末１１は、例えば改札機や自動販売機等のような、ICカード１２のリーダ・ライタ機能を有する情報処理装置であり、ICカード１２に情報を供給して記憶させたり、ICカード１２に記憶されている情報を読み出したりする。ICカード１２は、例えば不揮発性メモリや通信回路を内蔵するICチップやループアンテナ等が埋め込まれたカード型のデバイスであり、情報処理端末１１と、通信可能範囲が約１０cm程度の近距離無線通信を行い、情報の授受を行う、所謂、非接触型のICカードである。
図１に示されるように、情報処理端末１１は、記憶部２１、共通鍵認証処理部２３、乱数生成部２５、暗号化部２６、復号部２７、および通信部２８の機能ブロックを有する。記憶部２１は、例えばフラッシュメモリやハードディスク等の不揮発性のメモリデバイスよりなり、IDや暗号化用の鍵情報等各種情報を記憶する。共通鍵認証処理部２３は、例えばCPU（Central Processing Unit）等の演算処理デバイスよりなり、情報処理端末１１とICカード１２との通信を開始する際に、共通鍵を用いて互いを認証させる共通鍵方式の認証処理を行う。乱数生成部２５は、例えばCPU等の演算処理デバイスよりなり、共通鍵方式の認証処理等に必要な乱数を生成する。暗号化部２６は、例えばCPU等の演算処理デバイスよりなり、通信部２８を介してICカード１２に供給する情報を必要に応じて暗号化する。復号部２７は、例えばCPU等の演算処理デバイスよりなり、通信部２８を介してICカード１２より供給された、暗号化された情報を必要に応じて復号する。通信部２８は、例えば、通信回路等を含むICチップやループアンテナ等よりなり、通信可能範囲内に位置するICカード１２との近距離無線通信を行い、情報を授受する。もちろん、情報処理端末１１がこれら以外の機能ブロックを有していてもよい。
なお、図１においては矢印の記載を省略しているが、共通鍵認証処理部２３は、乱数生成部２５、暗号化部２６、および復号部２７とも情報の授受を適宜行う。
ICカード１２は、記憶部３１、共通鍵認証処理部３３、乱数生成部３５、暗号化部３６、復号部３７、および通信部３８の機能ブロックを有する。記憶部３１は、例えばフラッシュメモリやハードディスク等の不揮発性のメモリデバイスよりなり、情報処理端末１１等外部の機器より供給される情報等、各種情報を記憶する。共通鍵認証処理部３３は、例えばCPU等の演算処理デバイスよりなり、情報処理端末１１とICカード１２との通信を開始する際に、共通鍵を用いて互いを認証させる共通鍵方式の認証処理を行う。乱数生成部３５は、例えばCPU等の演算処理デバイスよりなり、共通鍵方式の認証処理等に必要な乱数を生成する。暗号化部３６は、例えばCPU等の演算処理デバイスよりなり、通信部３８を介して情報処理端末１１に供給する情報を必要に応じて暗号化する。復号部３７は、例えばCPU等の演算処理デバイスよりなり、通信部３８を介して情報処理端末１１より供給された、暗号化された情報を必要に応じて復号する。通信部３８は、例えば、通信回路等を含むICチップやループアンテナ等よりなり、通信可能範囲内に位置する情報処理端末１１との近距離無線通信を行い、情報を授受する。もちろん、ICカード１２がこれら以外の機能ブロックを有していてもよい。
なお、図１においては矢印の記載を省略しているが、共通鍵認証処理部３３は、乱数生成部３５、暗号化部３６、および復号部３７とも情報の授受を適宜行う。
以上の通信システム１に関わる存在（エンティティ）について説明する。以下においては、ICカード１２をユーザに提供する（あるいは販売し、管理する）エンティティをシステム管理者と称し、そのシステム管理者の許諾を得て、ICカード１２の記憶部３１の記憶領域の中にディレクトリを生成し、サービスを提供するエンティティを事業者と称する。当然、システム管理者も一事業者となり得る。
情報処理端末１１がICカード１２の記憶部３１に設けられたファイル（またはディレクトリ）にアクセスするためには、所定の鍵情報を用いて情報処理端末自身を認証させる必要があり、また、アクセス先のファイル（またはディレクトリ）毎に必要な鍵情報が異なる。情報処理端末１１の記憶部２１には、認証用の鍵情報である縮退鍵Ksを有している。
ICカード１２の記憶部３１には、ICカード１２固有のID、３つのファイル（File１、File２、およびFile３）、並びに、各ファイルに対応する認証用の鍵情報（Ｋ１、Ｋ２、およびＫ３）が記憶されている。
縮退鍵Ksは、これらの鍵Ｋ１、Ｋ２、およびＫ３を縮退化したものであり、File１、File２、およびFile３の全てにアクセスするための認証処理に用いられる。縮退化とは、複数の鍵情報をなんらかの方法で１つにまとめることである。例えば、図２に示されるように、暗号化処理部４１が、Ｋ２を用いてＫ１を、例えばAES（Advanced Encryption Standard）やDES（Data Encryption Standard）等のような所定の暗号化方式により暗号化し、さらにその暗号化結果を、暗号化処理部４２がＫ３を用いてさらに暗号化し、縮退鍵Ksを生成する。
つまり、縮退鍵Ksには、Ｋ１、Ｋ２、およびＫ３の全ての情報が含まれているので、情報処理端末１１は、この縮退鍵Ksを用いて認証処理を行うことにより、３つのファイル（File１、File２、およびFile３）全てに対する認証を１度の処理により行うことができる。
この認証処理の具体的な流れの例を図３のフローチャートを参照して説明する。
情報処理端末１１の共通鍵認証処理部２３は、ステップＳ１において、乱数生成部２５を制御し、第一の乱数を生成する。ステップＳ２において、共通鍵認証処理部２３は、通信部２８を制御し、アクセス先のファイルを指定するファイル番号と第一の乱数をICカード１２に送信する。ICカード１２の通信部３８は、ステップＳ１１において、そのファイル番号と第一の乱数を受信する。
ICカード１２の共通鍵認証処理部３３は、ステップＳ１２において、乱数生成部３５を制御し、第二の乱数を生成させ、ステップＳ１３において、ファイル番号によりアクセス先として指定されたファイル（File１、File２、およびFile３）の鍵情報（Ｋ１、Ｋ２、およびＫ３）を記憶部３１より取得し、それらを用いて、図２に示されるようにＫ１、Ｋ２、およびＫ３を縮退化し、縮退鍵Ksを生成する。
ステップＳ１４において、共通鍵認証処理部３３は、記憶部３１に記憶されているICカード１２のIDを取得し、暗号化部３６を制御し、第二の乱数、第一の乱数、およびそのICカード１２のIDを、縮退鍵Ksで暗号化させる。
ステップＳ１５において、共通鍵認証処理部３３は、通信部３８を制御し、縮退鍵で暗号化された第二の乱数、第一の乱数、およびIDを情報処理端末１１に送信させる。情報処理端末１１の通信部２８は、ステップＳ３において、その縮退鍵で暗号化された第二の乱数、第一の乱数、およびIDを取得する。
ステップＳ４において、情報処理端末１１の共通鍵認証処理部２３は、復号部２７を制御し、暗号化された第二の乱数、第一の乱数、およびIDを、記憶部２１より読み出した縮退鍵Ksで復号する。ステップＳ５において共通鍵認証処理部２３は、復号して得られた第一の乱数を、ステップＳ１において生成した第一の乱数と比較することにより、ICカード１２を認証する。復号して得られた第一の乱数が、ステップＳ１において生成した第一の乱数と一致しない場合、共通鍵認証処理部２３は、暗号化された第二の乱数、第一の乱数、およびIDを送信したICカード１２が不正なICカード１２であると判定し、認証処理を強制終了する。復号して得られた第一の乱数が、ステップＳ１において生成した第一の乱数と一致する場合、共通鍵認証処理部２３は、ICカード１２が正当であると認証し、ステップＳ６に処理を進める。
共通鍵認証処理部２３は、ステップＳ６において、乱数生成部２５を制御してセッション鍵を生成し、ステップＳ７において、暗号化部２６を制御し、第一の乱数、第二の乱数、およびセッション鍵を縮退鍵Ksで暗号化させ、ステップＳ８において、通信部２８を制御し、その縮退鍵Ksで暗号化された第一の乱数、第二の乱数、およびセッション鍵をICカード１２に送信させる。ICカード１２の通信部３８は、ステップＳ１６において、その縮退鍵Ksで暗号化された第一の乱数、第二の乱数、およびセッション鍵を取得する。
ICカード１２の共通鍵認証処理部３３は、ステップＳ１７において、復号部３７を制御し、その暗号化された第一の乱数、第二の乱数、およびセッション鍵を、ステップＳ１３において生成した縮退鍵Ksで復号する。
ステップＳ１８において、共通鍵認証処理部３３は、復号して得られた第二の乱数を、ステップＳ１２において生成した第二の乱数と比較することにより、情報処理端末１１を認証する。復号して得られた第二の乱数が、ステップＳ１２において生成した第二の乱数と一致しない場合、共通鍵認証処理部３３は、暗号化された第一の乱数、第二の乱数、およびセッション鍵を送信した情報処理端末１１が不正な情報処理端末１１であると判定し、認証処理を強制終了する。復号して得られた第二の乱数が、ステップＳ１２において生成した第二の乱数と一致する場合、共通鍵認証処理部３３は、情報処理端末１１が正当であると認証し、認証処理を正常終了する。
認証処理が正常に終了された後、情報処理端末１１およびICカード１２は、送信する情報を、セッション鍵を用いて暗号化してから送信する。
相互認証に成功した後、例えば、情報処理端末１１はICカード１２に対して書き込み命令を発効する。例えば、File１から所定の金額を減額し、それと同時にFile２にチケットを書き込み、File３に履歴を残すような処理を行うとする。File１乃至File３に対する認証処理及びファイルへのアクセス処理をそれぞれ個別に行う場合、このような処理の途中においてエラーが発生すると、ファイル間でデータの整合性が取れなくなる恐れがある。
また、File１乃至File３に対する認証処理は個別に行うものの、各ファイルへのアクセス処理は一括して行うようにした場合、セッション鍵が認証処理分発生していることになるだけでなく、コマンド及びデータの送受信時に使用するセッション鍵をいずれにすべきかという課題が残ってしまう。更に、一般にはICカードのリソースが不足しており、セッション鍵を複数ハンドリングすることは非常に難しくなっている。
これに対して、上述したように縮退鍵を用いて認証処理を行う場合、３つのファイルに対するアクセス処理が完結した時のみ、上述した書き込み処理結果が有効となるようにすることで、データの整合性を確保するができる。つまり、同時書き込み保証が可能になり、ファイル間でのデータの整合性を確保することができる。
また、以上のように認証を行うことにより、情報処理端末１１がICカード１２の３つのファイルに同時にアクセスするのに必要な認証処理を１度で行うことができる。なお、ICカード１２の全ての鍵が露見すると、情報セキュリティシステムは崩壊し、通信システム１は、通信の安全性を保つことができなくなる。しかしながら、情報処理端末１１の縮退鍵が露見しただけの場合、その縮退鍵に対応したファイルへのアクセスがリスクに犯されるだけで、それ以外のファイルに対するアクセスは安全である。
以上が相互認証およびファイルアクセス制御の第一の方法である。次に第二の方法について説明する。図４は、第二の方法で相互認証およびファイルアクセス制御を行う通信システムの主な構成例を示すブロック図である。
図４に示される通信システム１００は、通信機能を有する情報処理端末１１１およびICカード１１２の２つのデバイスよりなり、情報処理端末１１１とICカード１１２が互いに通信を行い、情報を授受するシステムである。情報処理端末１１１は、図１の情報処理端末１１と同様に、例えば改札機や自動販売機等のような、ICカード１１２のリーダ・ライタ機能を有する情報処理装置であり、ICカード１１２に情報を供給して記憶させたり、ICカード１１２に記憶されている情報を読み出したりする。ICカード１１２は、図１のICカード１２と同様に、例えば不揮発性メモリや通信回路を内蔵するICチップやループアンテナ等が埋め込まれたカード型のデバイスであり、情報処理端末１１１と、通信可能範囲が約１０cm程度の近距離無線通信を行い、情報の授受を行う、所謂、非接触型のICカードである。
図４に示されるように、情報処理端末１１１は、記憶部１２１、認証処理部１２３、ファイルアクセス処理部１２４、乱数生成部１２５、暗号化部１２６、復号部１２７、および通信部１２８の機能ブロックを有する。記憶部１２１は、例えばフラッシュメモリやハードディスク等の不揮発性のメモリデバイスよりなり、IDや暗号化用の鍵情報等各種情報を記憶する。認証処理部１２３は、例えばCPU等の演算処理デバイスよりなり、情報処理端末１１１と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方式で暗号化させ、第二のデータを生成する。暗号化処理部（AES）１６２は、暗号化部１３６を制御し、その第二のデータをディレクトリ１−１のディレクトリ鍵（DirK１−１）を用いてAES方式で暗号化させる。暗号化処理部（AES）１６３は、暗号化部１３６を制御し、暗号化処理部（AES）１６２による暗号化結果をディレクトリ１−２のディレクトリ鍵（DirK１−２）を用いてAES方式で暗号化させ、マスタ鍵（MK１−IT）を生成する。なお、AESの代わりに、DES等、その他の共通鍵暗号化方式を用いるようにしてもよい。
このマスタ鍵生成処理の詳細な流れについては、後述する。マスタ鍵が生成されると認証処理部１３３は、ステップＳ１３３において、暗号化部１３６を制御し、情報処理端末１１１−１−１の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カード１１２−１の認証処理部３３は、図１５のステップＳ１５１に処理を進める。
また、情報処理端末１１１−１−１の通信部１２８は、ステップＳ１２３においてそのレスポンス（第一の返信文と第二の返信文）を受信すると、処理を図１５のステップＳ１４１に進める。
図１５のステップＳ１４１において、情報処理端末１１１−１−１の認証処理部１２３は、復号部１２７を制御し、予め記憶部１２１に記憶されている情報処理端末１１１−１−１固有の鍵（Ｋ１−１）を用いて第一の返信文を、利用された暗号化方法に対応する復号方法で復号させ、アプリケーション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１−１）に記述されているアクセスコードが認証済みのディレクトリのものでない場合も構わず許諾するようにしてもよい。例えば、他事業者に自分の管理しているファイルにアクセスさせる必要があるような場合、アクセスを許諾する方が都合がよい。その場合、ステップＳ２１３の処理を省略すればよい。
また、以上においては、システム鍵を認証鍵用とアクセス許諾チケット生成鍵用の２種類用意するように説明した。上述したように、アクセス許諾チケット生成鍵を他事業者向けに生成する時、ディレクトリ鍵（DirK）を使用している。すると、第三のデータが第一のデータと同一であると、アクセス許諾チケット生成鍵生成過程において、情報処理端末１１１のマスタ鍵生成過程と一部似ている状態が出てきてしまう。必ずACKを掛け合わせているものの、例えば、第四のデータをDirK１−１で事業者１が暗号化し、この中間値を事業者２に渡し、事業者２が事業者２のアクセス制御鍵で暗号化した後、再度事業者１に渡して事業者１のアクセス制御鍵で暗号化する場合について想定する。このような場合において、仮に、第四のデータではなく、第二のデータであるとすると、事業者２は事業者１のマスタ鍵を得てしまうことになる。
従って、そうならないためにも、必ずディレクトリ鍵（DirK）のあとアクセス制御鍵（ACK）で暗号化するのが望ましい。また、マスタ鍵や認証鍵を生成する時の元データ（第一のデータ）と、アクセス許諾チケット生成鍵を生成する時の元データ（第三のデータ）を互いに異なるものにするのが望ましい。
以上に説明した第二の方式においても、アクセス許諾を得た後、第一の方式と同様な処理を実行するに当たって、同時書き込み保証が可能になる。つまり、ファイル構造を第一の方式の場合と同じように、例えば、ファイル１（File１）は電子マネーの保存領域とし、ファイル２（File２）はチケットの保存領域とし、ファイル３（File３）は履歴の保存領域としておき、書き込みコマンドでファイル１から残高を減額し、ファイル２にチケット情報を書き込み、同時にファイル３に履歴を書き込む。このとき、通信システム１００は、第一の方式と同様に、ファイル間においてデータの整合性を確保しながら、上述した処理を行うことができる。
次に、第一の方式と第二の方式が混載したシステム（認証方式・アクセス制御方式の異なる２つの領域が共存するシステム）についても同時書き込み保証を行うようにする相互認証およびアクセス制御の方法について説明する。
上述した第一の方式では、認証処理がそのままアクセス制御となっている。つまり、情報処理端末は、鍵を使って認証さえ通せば、アクセス制御をパスすることができる。これに対して上述した第二の方式では、認証処理とアクセス制御が異なっている。そこで、第一の方式と第二の方式の管理する領域に同時にアクセスする場合、基本的に第二の方式を採用し、そのアクセス許諾チケット生成鍵を生成する際に、第一の認証方式におけるサービス鍵（図１の鍵Ｋ１乃至Ｋ３）も使用するようにする。ただし、第一の方式と第二の方式では鍵ビット長が異なるため、少ない方の鍵を長い方の鍵に合わせる（鍵情報を整形する）ようにする。例えば、第一の方式の鍵の鍵ビット長が６４ビットで、第二の方式の鍵の鍵ビット長が１２８ビットである場合、第一の方式の鍵の上位に固定データ（例えば０）を６４ビット分付加し、全体として１２８ビットとする。
このように、アクセス許諾チケット生成鍵を生成（縮退）する際に、第一の方式のサービス鍵と第二の方式のアクセス制御鍵を共に利用するようにする。ただし、認証方式は第二の方式を採用する。このようにすることにより、認証によるセキュアパスは構築でき、アクセス制御による鍵認証は、第一の方式と第二の方式の両方についてできたことになる。これで、一つの書き込みコマンドで両方のサービスを完結させることが可能となる。
以下に、具体的に説明する。なお、エンティティについては、上述した通信システム１および通信システム１００の場合と同様である。
図２７は、本発明を適用した通信システムの構成例を示す図である。
図２７において、通信システム３００は、上述した通信システム１および通信システム１００と同様に、通信機能を有する情報処理端末とICカードが互いに通信を行うシステムである。通信システム３００は、上述した情報処理端末１１および情報処理端末１１１の他に、情報処理端末３１１およびICカード３１２を有する。
ICカード３１２は、基本的に上述したICカード１２およびICカード１１２と同様のデバイスであり、例えば不揮発性メモリや通信回路を内蔵するICチップやループアンテナ等が埋め込まれたカード型のデバイスであり、情報処理端末１１１と、通信可能範囲が約１０cm程度の近距離無線通信を行い、情報の授受を行う、所謂、非接触型のICカードである。ただし、その記憶部３３１には、第一の方式により認証処理およびアクセス制御を行う第一領域と、第二の方式により認証処理およびアクセス制御を行う第二領域とを有する。
第一領域には、システム鍵とマスタエリア鍵が書き込まれており、さらに、第一のエリアと第二のエリアが形成されている。第一のエリアには、エリア鍵（AK１）と、３つのファイル（File１、File２、およびFile３）が書き込まれている。第一のエリアには、さらに、ファイル１（File１）用のサービス鍵として、読み出しと書き込みの両方を許可する（Read/Write）ためのサービス鍵（SK１−１）と、減額処理を許可する（Reduction）ためのサービス鍵（SK１−２）が書き込まれている。第一のエリアには、さらに、ファイル２（File２）用のサービス鍵として、読み出しのみを許可する（Read Only）ためのサービス鍵（SK２−１）と、読み出しと書き込みの両方を許可する（Read/Write）ためのサービス鍵（SK２−２）が書き込まれている。第一のエリアには、さらに、ファイル３（File３）用のサービス鍵として、読み出しのみを許可する（Read Only）ためのサービス鍵（SK３−１）と、読み出しと書き込みの両方を許可する（Read/Write）ためのサービス鍵（SK３−２）が書き込まれている。
第二のエリアには、エリア鍵（AK２）と、３つのファイル（File４、File５、およびFile６）が書き込まれている。第二のエリアには、さらに、ファイル４（File４）用のサービス鍵として、読み出しと書き込みの両方を許可する（Read/Write）ためのサービス鍵（SK４−１）と、減額処理を許可する（Reduction）ためのサービス鍵（SK４−２）が書き込まれている。第二のエリアには、さらに、ファイル５（File５）用のサービス鍵として、読み出しのみを許可する（Read Only）ためのサービス鍵（SK５−１）と、読み出しと書き込みの両方を許可する（Read/Write）ためのサービス鍵（SK５−２）が書き込まれている。第二のエリアには、さらに、ファイル６（File６）用のサービス鍵として、読み出しのみを許可する（Read Only）ためのサービス鍵（SK６−１）と、読み出しと書き込みの両方を許可する（Read/Write）ためのサービス鍵（SK６−２）が書き込まれている。
第二領域には、第一のデータ、第三のデータ、およびルート鍵が書き込まれており、さらに、ディレクトリ１とディレクトリ２が形成されている。ディレクトリ１には、ディレクトリ鍵（DirK１）、アプリケーションID（AppID１）、およびアプリケーション鍵（AppK１）とともに、３つのファイル（File７、File８、およびFile９）が書き込まれている。ディレクトリ１には、さらに、ファイル７（File７）用のアクセス制御鍵として、読み出しと書き込みの両方を許可する（Read/Write）ためのアクセス制御鍵（ACK７−１）と、減額処理を許可する（Reduction）ためのアクセス制御鍵（ACK７−２）が書き込まれている。ディレクトリ１には、さらに、ファイル８（File８）用のアクセス制御鍵として、読み出しのみを許可する（Read Only）ためのアクセス制御鍵（ACK８−１）と、読み出しと書き込みの両方を許可する（Read/Write）ためのアクセス制御鍵（ACK８−２）が書き込まれている。ディレクトリ１には、さらに、ファイル９（File９）用のアクセス制御鍵として、読み出しのみを許可する（Read Only）ためのアクセス制御鍵（ACK９−１）と、読み出しと書き込みの両方を許可する（Read/Write）ためのアクセス制御鍵（ACK９−２）が書き込まれている。
ディレクトリ２には、ディレクトリ鍵（DirK２）、アプリケーションID（AppID２）、およびアプリケーション鍵（AppK２）とともに、３つのファイル（File１０、File１１、およびFile１２）が書き込まれている。ディレクトリ２には、さらに、ファイル１０（File１０）用のアクセス制御鍵として、読み出しと書き込みの両方を許可する（Read/Write）ためのアクセス制御鍵（ACK１０−１）と、減額処理を許可する（Reduction）ためのアクセス制御鍵（ACK１０−２）が書き込まれている。ディレクトリ２には、さらに、ファイル１１（File１１）用のアクセス制御鍵として、読み出しのみを許可する（Read Only）ためのアクセス制御鍵（ACK１１−１）と、読み出しと書き込みの両方を許可する（Read/Write）ためのアクセス制御鍵（ACK１１−２）が書き込まれている。ディレクトリ２には、さらに、ファイル１２（File１２）用のアクセス制御鍵として、読み出しのみを許可する（Read Only）ためのアクセス制御鍵（ACK１２−１）と、読み出しと書き込みの両方を許可する（Read/Write）ためのアクセス制御鍵（ACK１２−２）が書き込まれている。
ICカード３１２の記憶部３３１の第一領域の各データにアクセスするためには、サービス鍵による認証を必要とする（サービス鍵を持っているまたは知っていることを認証する必要がある）。そして、サービス鍵とファイルへのアクセス方法が一対一に対応しており、あるサービス鍵（SK）を含む縮退鍵での認証が成功すると、そのサービス鍵（SK）に割り振られたアクセス方法が許諾される。
また、ICカード３１２の記憶部３３１の第二領域にアクセスするためには、相互認証の後、アクセス許諾チケットの提示を必要とする。このアクセス許諾チケットに付随するMAC値は、アクセス許諾チケット生成鍵で作成され、アクセス許諾チケット生成鍵は第四のデータ（第三のデータをルート鍵で暗号化する）をアクセス制御鍵（ACK）で暗号化（縮退化）して生成する。従って、正当なアクセス許諾チケットが提示されたということは、アクセス制御鍵（ACK）を持っているまたは知っている者がアクセス許諾チケット生成鍵を作成したとみなすことができ、アクセス制御鍵（ACK）に対応するファイルアクセス方法が許諾される。以上の点でみれば、アクセス制御鍵（ACK）とサービス鍵（SK）の役割は同じである。
情報処理端末１１は、ICカード３１２の第一領域にのみアクセスする端末であり、その記憶部２１には、２つの縮退鍵（縮退鍵１および縮退鍵２）が書き込まれている。縮退鍵１は、システム鍵（第二領域の第一のデータに相当）をマスタエリア鍵（第二領域のルート鍵に相当）で暗号化し、その結果をアクセス先の２つのエリア鍵（AK１およびAK２）で順次暗号化したものである。縮退鍵２は、その縮退鍵１をさらに３つのサービス鍵（SK１−２、SK２−２、およびSK４−１）で暗号化したものである。
File１が電子マネーを保存し、File２がチケット情報を保存し、File４は履歴を保存するとすると、上述した２つの縮退鍵（縮退鍵１および縮退鍵２）で相互認証することにより、情報処理端末１１は、File１から減額処理が行え、File２にチケットを書き込め、File４に履歴を残すことができるようになる。
情報処理端末１１１は、ICカード３１２の第二領域にのみアクセスする端末であり、その記憶部１２１には、情報処理端末１１１のID（ID３）、情報処理端末１１１固有の鍵（Ｋ３）、ICカード３１２用のマスタ鍵（MK２−IC）、および、情報処理端末１１１に割り当てられたアクセス許諾チケット（Ticket３）が書き込まれている。
相互認証時において、ICカード３１２は、第一のデータをルート鍵で暗号化して第二のデータを生成し、これをディレクトリ鍵であるDirK１とDirK２で暗号化して、情報処理端末１１１のマスタ鍵（MK２−IT）を生成する。ICカード３１２は、さらに、情報処理端末１１１のマスタ鍵（MK２−IT）と情報処理端末１１１のID（ID３）を用いれば、情報処理端末１１１の鍵（Ｋ３）を生成することができる。ICカード３１２は、情報処理端末１１１がアクセスするディレクトリのアプリケーションID（AppID１とAppID２）を、この情報処理端末１１１の鍵（Ｋ３）で暗号化して返信する。また、ICカード３１２は、情報処理端末１１１の鍵（Ｋ３）を、情報処理端末１１１がアクセスするディレクトリのアプリケーション鍵（AppK１とAppK２）で暗号化し、認証鍵を生成する。情報処理端末１１１は、送られてきたアプリケーションID（AppID１およびAppID２）を情報処理端末１１１の鍵（Ｋ３）で復号し、アプリケーションID（AppID１およびAppID２）をICカード３１２用のマスタ鍵（MK２−IC）で暗号化してアプリケーション鍵（AppK１およびAppK２）を生成する。そして、情報処理端末１１１の鍵（Ｋ３）とアプリケーション鍵（AppK１およびAppK２）を用いて認証鍵を生成し、相互認証を行う。相互認証の後、情報処理端末１１１はアクセス許諾チケット（Ticket３）を提示する。アクセス許諾チケットにはMAC値が保持されている。ICカード３１２は、これを生成するアクセス許諾チケット生成鍵を、第三のデータをルート鍵で暗号化し、その暗号化結果をさらにアクセス制御鍵（ACK７−２、ACK８−２、およびACK１０−１）で順次暗号化することにより生成する。
なお、このとき、File7、File8、およびFile10のそれぞれに、上述したFile1、File2、およびFile4と同じ機能を割り振っていれば、上述した第一領域の場合と同じような処理が行える。
情報処理端末３１１は、基本的に上述した情報処理端末１１および情報処理端末１１１と同様のデバイスであり、例えば改札機や自動販売機等のような、ICカード３１２のリーダ・ライタ機能を有する情報処理装置であり、ICカード３１２に情報を供給して記憶させたり、ICカード３１２に記憶されている情報を読み出したりする。
この情報処理端末３１１は、ICカード３１２の記憶部３３１第一領域と第二領域の両方にアクセスする端末であり、その記憶部３２１には、情報処理端末１１１のID（ID２）、情報処理端末３１１固有の鍵（Ｋ２）、ICカード３１２用のマスタ鍵（MK２−IC）、および、情報処理端末３１１に割り当てられたアクセス許諾チケット（Ticket２）が書き込まれている。
以下において、この情報処理端末３１１がICカード３１２のICカード３１２の記憶部３３１第一領域と第二領域の両方にアクセスするための認証処理およびアクセス制御の方法について具体的に説明する。
最初に、情報処理端末３１１およびICカード３１２のそれぞれが有する機能ブロックについて説明する。図２８は、情報処理端末３１１およびICカード３１２のそれぞれが有する機能ブロックの構成例を示す機能ブロック図である。
図２８に示されるように、情報処理端末３１１は、基本的に情報処理端末１１１と同様の構成を有し、記憶部３２１、認証処理部３２３、ファイルアクセス処理部３２４、乱数生成部３２５、暗号化部３２６、復号部３２７、および通信部３２８を有する。記憶部３２１は、例えばフラッシュメモリやハードディスク等の不揮発性のメモリデバイスよりなり、IDや暗号化用の鍵情報等各種情報を記憶する。認証処理部３２３は、例えばCPU等の演算処理デバイスよりなり、情報処理端末３１１とICカード３１２との通信を開始する際に互いを認証させる認証処理を行う。ファイルアクセス処理部３２４は、例えばCPU等の演算処理デバイスよりなり、相互認証を行ったICカード３１２に対して、ファイルへのアクセス許諾を求める処理を行う。乱数生成部３２５は、例えばCPU等の演算処理デバイスよりなり、認証処理等に必要な乱数を生成する。暗号化部３２６は、例えばCPU等の演算処理デバイスよりなり、通信部３２８を介してICカード３１２に供給する情報を必要に応じて暗号化する。復号部３２７は、例えばCPU等の演算処理デバイスよりなり、通信部３２８を介してICカード３１２より供給された、暗号化された情報を必要に応じて復号する。通信部３２８は、例えば、通信回路等を含むICチップやループアンテナ等よりなり、通信可能範囲内に位置するICカード３１２との近距離無線通信を行い、情報を授受する。もちろん、情報処理端末３１１がこれら以外の機能ブロックを有していてもよい。
なお、図２８においては矢印の記載を省略しているが、認証処理部３２３およびファイルアクセス処理部３２４は、乱数生成部３２５、暗号化部３２６、および復号部３２７とも情報の授受を適宜行う。
ICカード３１２は、基本的にICカード１１２と同様の構成を有し、記憶部３３１、データ設定処理部３３２、共通鍵認証処理部３３３Ａ、認証処理部３３３Ｂ、ファイルアクセス処理部３３４、乱数生成部３３５、暗号化部３３６、復号部３３７、および通信部３３８を有する。記憶部３３１は、例えばフラッシュメモリやハードディスク等の不揮発性のメモリデバイスよりなり、情報処理端末３１１等外部の機器より供給される情報等、各種情報を記憶する。データ設定処理部３３２は、例えばCPU等の演算処理デバイスよりなり、ICカード３１２の外部の機器より供給される命令や情報等に基づいて、記憶部３３１の記憶領域にディレクトリやファイルを作成したり、鍵情報やID等の設定情報を書き込んだりするデータ設定処理を行う。
共通鍵認証処理部３３３Ａは、例えばCPU等の演算処理デバイスよりなり、上述した第一の方式による認証処理を行う。これに対して、認証処理部３３３Ｂは、例えばCPU等の演算処理デバイスよりなり、上述した第二の方式による認証処理を行う。認証処理部３３３Ｂは、情報処理端末３１１固有の鍵を生成するマスタ鍵を生成するマスタ鍵生成部３４１を有する。ファイルアクセス処理部３３４は、例えばCPU等の演算処理デバイスよりなり、情報処理端末３１１による記憶部３３１の第二領域に書き込まれているファイルへのアクセスの制御に関する処理を行う。ファイルアクセス処理部３３４は、情報処理端末３１１より供給されるアクセス許諾チケットの検証を行うために、そのアクセス許諾チケットと同様の情報を作成可能な鍵情報であるアクセス許諾チケット生成鍵を生成するアクセス許諾チケット生成鍵生成部３４２を有する。
乱数生成部３３５は、例えばCPU等の演算処理デバイスよりなり、認証処理等に必要な乱数を生成する。暗号化部３３６は、例えばCPU等の演算処理デバイスよりなり、通信部３３８を介して情報処理端末３１１に供給する情報を必要に応じて暗号化する。復号部３３７は、例えばCPU等の演算処理デバイスよりなり、通信部３３８を介して情報処理端末３１１より供給された、暗号化された情報を必要に応じて復号する。通信部３３８は、例えば、通信回路等を含むICチップやループアンテナ等よりなり、通信可能範囲内に位置する情報処理端末３１１との近距離無線通信を行い、情報を授受する。もちろん、ICカード３１２がこれら以外の機能ブロックを有していてもよい。
なお、図２８においては矢印の記載を省略しているが、データ設定処理部３３２、認証処理部３３３Ａ、認証処理部３３３Ｂ、およびファイルアクセス処理部３３４は、それぞれ、乱数生成部３３５、暗号化部３３６、および復号部３３７とも情報の授受を適宜行う。
次に、この情報処理端末３１１がICカード３１２の第一領域および第二領域の両方にアクセスする際の相互認証処理およびアクセス制御処理の流れの例を、図２９乃至図３１のフローチャートを参照して説明する。なお、ここでは、具体的な例として、情報処理端末３１１がICカード３１２のFile７にある電子マネーからFile１にある電子マネーに値を移動する場合について説明する。
相互認証処理が開始されると、情報処理端末３１１の認証処理部３２３は、ステップＳ３０１において、乱数生成部３２５を制御して第一の乱数を生成させ、ステップＳ３０２において、通信部３２８を制御して、第一の相互認証開始コマンドを、情報処理端末３１１のID（ID２）、アクセス先ディレクトリ情報（ディレクトリ１）、および第一の乱数とともに、ICカード３１２に送信させる。
ステップＳ３１１において、ICカード３１２の通信部３３８は、この第一の相互認証開始コマンド等を取得する。第一の相互認証開始コマンドを取得すると、認証処理部３３３Ｂのマスタ鍵生成部３４１は、ステップＳ３１２において、第一のデータをルート鍵で暗号化して第二のデータを作り、さらにその第二のデータをディレクトリ鍵（DirK１）で暗号化して情報処理端末３１１のマスタ鍵（MK２−IT）を生成する。このマスタ鍵生成処理の詳細な流れは、図２０のフローチャートを参照して説明した場合と同様であるので、ここではその説明を省略する。
マスタ鍵が生成されると認証処理部３３３Ｂは、ステップＳ３１３において、暗号化部３３６を制御し、情報処理端末３１１のID（ID２）をマスタ鍵（MK２−IT）を用いて暗号化させ、情報処理端末３１１固有の鍵（Ｋ２）を生成する。ステップＳ３１４において、認証処理部３３３Ｂは、暗号化部３３６を制御し、アクセス先ディレクトリ（ディレクトリ１）のアプリケーションID（AppID１）を情報処理端末３１１固有の鍵（Ｋ２）で暗号化させ、第一の返信文を作成する。このとき、アプリケーションID（AppID）の使用順は、情報処理端末３１１より供給されたアクセス先ディレクトリ情報に従う。なお、このときの暗号化方法は、CBCモード等の暗号利用モードを用いることとする。また、本例では暗号化することを示していたが、復号するようにしてもよい。この場合、この第一の返信文を受け取った情報処理端末３１１側では、同一の鍵を用いて暗号化する必要がある。
第一の返信文を生成した後、認証処理部３３３Ｂは、ステップＳ３１５において、相互認証に利用される認証鍵（KAuth）の生成を行う。認証処理部３３３Ｂは、暗号化部３３６を制御し、情報処理端末３１１固有の鍵（Ｋ２）を、アクセス先ディレクトリ（ディレクトリ１）のアプリケーション鍵（AppK１）を用いて暗号化させて（すなわち、各鍵を縮退化させて）認証鍵（KAuth）を生成する。
ステップＳ３１６において、認証処理部３３３Ｂは、乱数生成部３３５を制御して第二の乱数を生成させる。ステップＳ３１７において、認証処理部３３３Ｂは、認証鍵（KAuth）を暗号鍵とし、暗号化部３３６を制御して、この第二の乱数、第一の乱数、および、情報処理端末３１１のID（ID２）を所定の暗号利用モードで暗号化し、第二の返信文を生成する。なお、第二の乱数、第一の乱数、および、情報処理端末３１１のID（ID２）は、予め定められた所定の順序で暗号化される。
ここで、本例では第一の返信文は情報処理端末３１１固有の鍵（Ｋ２）で暗号化させて生成し、第二の返信文は認証鍵（KAuth）で暗号化させて生成していたが、暗号化された第一の返信文及び暗号化前の第二の返信文を、認証鍵（KAuth）を用いて、所定の暗号利用モードで一括して暗号化するようにしても良い。更にまた、第二の返信文に情報処理端末３１１のID（ID２）を含ませていたが、これ（情報処理端末３１１のID）以外のデータを利用するようにしても良い。
ステップＳ３１８において、認証処理部３３３Ｂは、通信部３３８を制御し、第一の返信文と第二の返信文を、情報処理端末３１１に返信させる。ステップＳ３１８の処理を終了すると、ICカード３１２の認証処理部３３３Ｂは、図３０のステップＳ３４１に処理を進める。
また、情報処理端末３１１の通信部３２８は、ステップＳ３０３においてそのレスポンス（第一の返信文と第二の返信文）を受信すると、処理を図３０のステップＳ３３１に進める。
図３０のステップＳ３３１において、情報処理端末３１１の認証処理部３２３は、復号部３２７を制御し、予め記憶部３２１に記憶されている情報処理端末３１１固有の鍵（Ｋ２）を用いて第一の返信文を、利用された暗号化方法に対応する復号方法で復号させ、アプリケーションID（AppID１）を取り出す。ステップＳ３３２において、認証処理部３２３は、予め記憶部３２１に記憶されているマスタ鍵（MK２−IC）を用いてアプリケーションID（AppID１）を暗号化することによりアプリケーション鍵（AppK１）を生成する。
ステップＳ３３３において、認証処理部３２３は、暗号化部３２６を制御して、情報処理端末３１１固有の鍵（Ｋ２）を、ステップＳ３３２で生成したアプリケーション鍵（AppK１）を用いて暗号化させ、認証鍵（ＫAuth）を生成する。ステップＳ３３４において、認証処理部３２３は、復号部３２７を制御し、ICカード３１２より取得した第二の返信文を復号させ、第二の乱数、第一の乱数、および情報処理端末３１１固有のID（ID２）を取り出す。
ステップＳ３３５において、認証処理部３２３は、取り出した第一の乱数によりICカード３１２の認証を行う。認証処理部３２３は、第二の返信文より取り出した第一の乱数が図２９のステップＳ３０１において生成した第一の乱数と一致するか否かを判定し、２つの第一の乱数の値が互いに一致した場合、ICカード３１２を認証する。逆に、２つの第一の乱数の値が互いに一致しなかった場合、認証処理部３２３は、ICカード３１２が不正であると判定し、相互認証処理をエラー終了する。
２つの第一の乱数の値が互いに一致し、ICカード３１２が認証されると、認証処理部３２３は、ステップＳ３３６において、乱数生成部３２５を制御して乱数を生成させ、その乱数をセッション鍵とする。このセッション鍵は、相互認証完了後の通信路の秘匿化に使用される。ステップＳ３３７において、認証処理部３２３は、第一の乱数、第二の乱数、および、生成したセッション鍵を、認証鍵（ＫAuth）を用いて所定の暗号利用モードで暗号化する。ステップＳ３３８において、認証処理部３２３は、通信部３２８を制御し、第二の相互認証コマンドを、認証鍵（ＫAuth）で暗号化された第一の乱数、第二の乱数、およびセッション鍵と共にICカード３１２に送信させる。ICカード３１２の通信部３３８は、ステップＳ３４１において、この第二の相互認証コマンドと、認証鍵（ＫAuth）で暗号化された第一の乱数、第二の乱数、およびセッション鍵を取得する。
ステップＳ３４２において、ICカード３１２の認証処理部３３３Ｂは、復号部３３７を制御し、認証鍵（ＫAuth）を用いて認証鍵（ＫAuth）で暗号化された第一の乱数、第二の乱数、およびセッション鍵を復号させる。ステップＳ３４３において、認証処理部３３３Ｂは、取り出した第二の乱数により情報処理端末３１１の認証を行う。認証処理部３３３Ｂは、第二の相互認証コマンドともに供給された第二の乱数が、図２９のステップＳ３１６において生成した第二の乱数と一致するか否かを判定し、２つの第二の乱数の値が互いに一致した場合、情報処理端末３１１を認証する。逆に、２つの第二の乱数の値が互いに一致しなかった場合、認証処理部３３３Ｂは、情報処理端末３１１が不正であると判定し、相互認証処理をエラー終了する。
２つの第二の乱数の値が互いに一致し、情報処理端末３１１が認証されると、認証処理部３３３Ｂは、ステップＳ３４４において、通信部３３８を制御し、その認証結果をレスポンスとして送信させ、処理を図３１のステップＳ３７１に進める。
ステップＳ３３９において、情報処理端末３１１の通信部３２８は、そのレスポンス取得し、相互に認証されたことを把握し、処理を図３１のステップＳ３６１に進める。
ステップＳ３６１において、情報処理端末３１１のファイルアクセス処理部３２４は、通信部３２８を制御して、アクセス許諾チケット（Ticket２）を含むファイル許可命令をICカード３１２に対して発行する。この時、命令文をセッション鍵により暗号化するようにしてもよい。ICカード３１２の通信部３３８は、ステップＳ３７１において、そのファイル許可命令を取得する。
ファイル許可命令を取得すると、ICカード３１２のファイルアクセス処理部３３４は、ステップＳ３７２において、アクセス許諾チケット（Ticket２）に記述されているチケットの使用者のIDを検証する。情報処理端末３１１（ID２）は既に認証済みであるので、ファイルアクセス処理部３３４は、アクセス許諾チケット（Ticket２）に記述されている使用者IDがこの認証済みのIDと一致するか否かを検証し、一致する場合のみ、アクセス許諾チケット（Ticket２）の使用者を認証する。アクセス許諾チケット（Ticket２）の使用者のIDが認証済みのIDと一致しない場合、ファイルアクセス処理部３３４は、このアクセス制御処理を強制終了し、アクセスの許諾要求を拒否する。
なお、認証済みのIDに関わらず、アクセス制御チケットの使用者を許諾させる特別なID（オールマイティID）を設けるようにしてもよい。例えば、所定のIDをオールマイティIDとして予め用意しておき、ICカード３１２のファイルアクセス処理部３３４が、アクセス許諾チケットの使用者のIDがこのオールマイティIDである場合、認証済みのIDとの一致不一致に関わらず、使用者を認証するようにすればよい。つまり、このオールマイティIDが使用者のIDとして記述されることにより、そのアクセス制御チケットは、どの情報処理端末３１１においても使用可能なチケットとなる。
アクセス制御チケット（Ticket２）の使用者を認証すると、ファイルアクセス処理部３３４は、ステップＳ３７３において、アクセス制御チケット（Ticket２）に記述されているアクセスコードが、相互認証処理において情報処理端末３１１のアクセス先として認証済みのディレクトリのものであるか否かを確認する。相互認証時に指定したディレクトリ以外のディレクトリのアクセスコードが含まれている場合（すなわち、相互認証時に指定したディレクトリ以外のディレクトリへのアクセスを要求している場合）、ファイルアクセス処理部３３４は、このアクセス制御処理を強制終了し、アクセスの許諾要求を拒否する。
アクセス制御チケット（Ticket２）に記述されているアクセスコードが、相互認証処理において情報処理端末３１１のアクセス先として認証済みのディレクトリのものである場合、ファイルアクセス処理部３３４は、アクセス制御処理を継続する。なお、認証済みのディレクトリのアクセスコードと、認証済みでないディレクトリのアクセスコードの両方が含まれている場合、ファイルアクセス処理部３３４が、このアクセス制御処理を強制終了し、アクセスの許諾要求を拒否するようにしてもよいし、認証済みでないディレクトリのアクセスコードについてのみ拒否し、認証済みのアクセスコードに対しては処理を継続するようにしてもよい。
なお、この処理において検証されるのは第二領域のディレクトリについてのみであり、第一領域については検証されない。また、このステップＳ３７３の処理を省略するようにしてもよい。
ステップＳ３７４において、ファイルアクセス処理部３３４は、第三のデータ（ＫSystem2）をルート鍵（ＫRoot）で暗号化して第四のデータ（System Data）を生成する。
また、ここでは第一のデータと異なるデータを使用したが、第一のデータを使用するようにしてもよい。なお、ここでも第四のデータを事前に計算し、記憶部３３１に保持しておくようにしてもよい。その場合、ステップＳ３７４の処理は省略される。
ステップＳ３７５において、ファイルアクセス処理部３３４のアクセス許諾チケット生成鍵生成部３４２は、第四のデータから、アクセス許諾チケットのチェック子（MAC）を算出するためのアクセス許諾チケット生成鍵を作成する処理を行う。
このとき、アクセス許諾チケット生成鍵生成部３４２は、アクセス制御チケット（Ticket２）に記述されているアクセスコードに対応するアクセス制御鍵の他に、さらに、第一領域のアクセス先（File１）に関するエリア鍵（AK１）とサービス鍵（SK１−２）も用いてアクセス許諾チケット生成鍵を生成する。
つまり、アクセス許諾チケット生成鍵生成部３４２は、ステップＳ３７４およびステップＳ３７５の処理により、記憶部３３１−１より、第三のデータ（ＫSystem2）、ＫRoot、AK１、SK１−２、およびACK７−２を取得し、図３２に示されるように、これらの鍵を縮退化する。図３２において、アクセス許諾チケット生成鍵生成部３４２は、暗号化処理部（AES）３５１乃至暗号化処理部（AES）３５４の機能ブロックを有する。暗号化処理部（AES）３５１は、暗号化部３３６を制御し、第三のデータ（ＫSystem2）を、ルート鍵（ＫRoot）によりAES方式で暗号化させ、第四のデータ（System Data）を生成する（ステップＳ３７４）。暗号化処理部（AES）３５２は、暗号化部３３６を制御し、第四のデータ（System Data）を、エリア鍵AK１を用いてAES方式で暗号化させる。暗号化処理部（AES）３５３は、暗号化部３３６を制御し、暗号化処理部（AES）３５２による暗号化結果を、サービス鍵SK１−２を用いてAES方式で暗号化させる。さらに、暗号化処理部（AES）３５４は、暗号化部３３６を制御し、暗号化処理部（AES）３５３による暗号化結果を、ACK７−２を用いてAES方式で暗号化させ、アクセス許諾チケット生成鍵（A.C.Gen.Key）を生成する。なお、暗号化処理部（AES）３５１乃至暗号化処理部（AES）３５４が、AESの代わりに、DES等、その他の共通鍵暗号化方式を用いるようにしてもよい。なお、アクセス許諾チケット生成鍵生成処理の別な方法は、後述する（図３３参照）。
アクセス許諾チケット生成鍵が生成されるとファイルアクセス処理部３３４は、ステップＳ３７６において、アクセス許諾チケットのチェック子（MAC値）を、アクセス許諾チケット生成鍵を用いて計算する（例えば、暗号利用モードのCBCモードなどを利用する）。
ステップＳ３７７において、ファイルアクセス処理部３３４は、生成したチェック子の値を、アクセス許諾チケット（Ticket２）のチェック子の値と比較し、アクセス許諾チケット（Ticket２）を検証する。生成したチェック子の値がアクセス許諾チケット（Ticket２）に記述されるチェック子の値と一致しない場合、ファイルアクセス処理部３３４は、アクセス許諾チケット（Ticket２）が不正である（改ざんされた）と判定し、このアクセス制御処理を強制終了し、アクセス許諾要求を拒否する。値が一致する場合、ファイルアクセス処理部３３４は、アクセス許諾チケット（Ticket２）が正当であると判定し、認証する。
ファイルアクセス処理部３３４は、アクセス許諾チケット（Ticket２）に従ったファイルへのアクセスを許可し、ステップＳ３７８において、その旨を通知する応答を、要求元の情報処理端末３１１に供給する。つまり、ファイルアクセス処理部３３４は、File１に対するRead/Write、File7に対する減額処理を許諾する。
情報処理端末３１１の通信部３２８は、ステップＳ３６２において、その応答を取得する。ファイルアクセス処理部３２４は、アクセス許諾を得たアクセス方法に則りファイルにアクセスする。例えば、情報処理端末３１１は、書き込み命令を発行し、File7からxxx円減額、File１にxxx円加算処理する。これらのうち、一方でも処理がうまくいかない場合、コマンド結果は全て無効となる。なお、書き込みコマンドは、複数ファイルに対していっぺんに処理できるように、必要な引数データは全て送っておくのが望ましい。
以上のように認証処理およびファイルアクセス制御処理を行うことにより、管理方式が互いに異なる複数の領域へアクセスする場合であっても、情報処理端末３１１は、データの整合性を維持したまま書き換え処理を行うことができる。
なお、本説明ではシステム鍵とマスタエリア鍵が使用されていないが、第一領域を管理している鍵には変わりないため、アクセス許諾チケット作成鍵を作る際に、この鍵も含めるようにしても良い（つまり、AK1、SK1-2と同じように使用する）。また、SKとACKは鍵ビットサイズが異なっていることが想定される。また、暗号アルゴリズムも異なっている可能性がある。そこで、鍵サイズは長い方に合わせ、短い鍵には適当な固定データを付加して長い鍵と同じビット数にするようにする。暗号アルゴリズムは、強い方を使うこととする。そもそも、アクセス制御、認証処理は、正当な鍵を持っているかどうかをチェックしているだけであるため、弱い暗号アルゴリズムから強い暗号アルゴリズムに代わること自体は、問題がない。
また、以上のように、二つの方式の管理する領域（第一領域および第二領域）に同時にアクセスする場合、相互認証時において、アクセス先として、第二領域のディレクトリだけでなく、第一領域のエリアも指定するようにしてもよい。つまり、この場合、情報処理端末３１１は、図２９のステップＳ３０２の処理において、第一領域のエリアを第二領域のディレクトリと同様に見立て、送信するアクセス先ディレクトリ情報によって第一領域のエリアも指定する。
ICカード３１２の認証処理部３３３Ｂは、ステップＳ３１５において、認証鍵の生成に、そのアクセス先に指定された第一領域のエリアのエリア鍵（AK１）を使用する。つまり、認証処理部３３３Ｂは、暗号化部３３６を制御し、情報処理端末３１１固有の鍵（Ｋ２）を、アクセス先エリアのエリア鍵（AK１）を用いて暗号化させ、さらに、その暗号化結果を、アクセス先ディレクトリ（ディレクトリ１）のアプリケーション鍵（AppK１）を用いて暗号化させて認証鍵（KAuth）を生成する。
同様に、情報処理端末３１１の認証処理部３２３も、ステップＳ３３３において、暗号化部３２６を制御して、情報処理端末３１１固有の鍵（Ｋ２）を、アクセス先エリアのエリア鍵（AK１）を用いて暗号化させ、さらに、その暗号化結果を、アクセス先ディレクトリ（ディレクトリ１）のアプリケーション鍵（AppK１）を用いて暗号化させて認証鍵（KAuth）を生成する。
情報処理端末３１１およびICカード３１２は、これらの認証鍵を用いて上述したように相互認証を行う。このようにすることにより、第一領域のエリアも、第二領域の場合と同様にアクセス先として認証させることができる。
なお、このように第一領域のエリアをアクセス先として認証させる場合、アクセス許諾チケットを生成する際に、エリア鍵の使用を省略することができる。すなわち、アクセス許諾チケット生成鍵生成部３４２は、図３１のステップＳ３７５において、アクセス制御チケット（Ticket２）に記述されているアクセスコードに対応するアクセス制御鍵と、第一領域のアクセス先（File１）に関するサービス鍵（SK１−２）を使用して（上述したように各鍵を縮退化して）アクセス許諾チケット生成鍵を生成する。
次に、図３３のフローチャートを参照して、図３１のステップＳ３７５において実行されるアクセス許諾チケット生成鍵生成処理の流れの例を説明する。なお、以下においてはICカード３１２において実行される場合について説明するが、以下の説明は、他のICカード３１２において実行される場合も適用可能である。
アクセス許諾チケット生成鍵生成処理が開始されると、アクセス許諾チケット生成鍵生成部３４２は、ステップＳ４０１において、アクセス許諾チケット（Ticket２）に記述されているアクセスコードのリストを参照し、そのアクセスコードに第一領域のファイルが含まれているか否かを判定する。
アクセス先を示すアクセスコードに第一領域のファイルが含まれていると判定した場合、アクセス許諾チケット生成鍵生成部３４２は、処理をステップＳ４０２に進め、アクセス許諾チケット（Ticket２）のアクセスコードに基づいて、アクセス先のエリア鍵とサービス鍵を全て取得する。ステップＳ４０２の処理が終了すると、アクセス許諾チケット生成鍵生成部３４２は、処理をステップＳ４０３に進める。また、ステップＳ４０１において、アクセスコードに第一領域のファイルが含まれていないと判定した場合、アクセス許諾チケット生成鍵生成部３４２は、ステップＳ４０２の処理を省略し、処理をステップＳ４０３に進める。
ステップＳ４０３において、アクセス許諾チケット生成鍵生成部３４２は、アクセス許諾チケット（Ticket２）に記述されているアクセスコードのリストを参照し、そのリストに含まれるアクセスコードに対応するアクセス制御鍵を記憶部３３１より取得する。
アクセス制御鍵を取得すると、アクセス許諾チケット生成鍵生成部３４２は、ステップＳ４０４において、取得したアクセス制御鍵を、アクセス許諾チケット（Ticket２）に記述されているアクセスコードのリストと同順に整列させる。なお、アクセス先を示すアクセスコードに第一領域のファイルが含まれている場合、エリア鍵とサービス鍵も整列させる。
ステップＳ４０５において、アクセス許諾チケット生成鍵生成部３４２は、取得した各種鍵の中に、未使用の鍵が存在するか否かを判定し、存在すると判定した場合、ステップＳ４０６に処理を進め、暗号化部３３６を制御し、次の順のアクセス制御鍵を用いて前回の暗号化結果をさらに暗号化させる。なお、１回目の暗号化の場合、アクセス許諾チケット生成鍵生成部３４２は、暗号化部３３６を制御し、第四のデータ（System Data）を最初の鍵で暗号化させる。暗号化が終了すると、アクセス許諾チケット生成鍵生成部３４２は、処理をステップＳ４０５に戻す。つまり、ステップＳ４０５およびステップＳ４０６を繰り返すことにより、アクセス許諾チケット生成鍵生成部３４２は、取得したアクセス制御鍵、エリア鍵及びサービス鍵の全てを、その整列順に縮退化してアクセス許諾チケット生成鍵を生成する。
ステップＳ４０５において、未使用の鍵が存在しないと判定した場合、アクセス許諾チケット生成鍵生成部３４２は、アクセス許諾チケット生成鍵生成処理を終了し、図３１のステップＳ３７５に処理を戻し、それ以降の処理を実行させる。
このようにアクセス制御鍵を縮退化してアクセス許諾チケット生成鍵を生成することにより、ファイルアクセス処理部３３４は、管理方式が互いに異なる複数の領域にアクセスする場合も、アクセス制御チケット（Ticket２）の検証をより正確かつ高速に行うことができる。つまり、ファイルへの複数のアクセス方法などを規定したアクセス許諾チケットに対し、複数の鍵を持って正当性検証を、１度の処理で行わせることができるようになり、セキュリティレベルの低下を防止するとともに、処理が増大するのを抑制し、高速に検証を行うことができる。
以上のように認証処理およびファイルアクセス制御を行うことにより、情報処理端末３１１は、ICカード３１２の記憶部３３１へに、管理方式の異なる２つ以上のデータ領域がある場合であっても、これらをまたがってデータアクセスして書き換え更新を行う際に、データの整合性を保証することができるようになる。
なお、上述した情報処理端末と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カード， １２１ 記憶部， １２３ 認証処理部， １２４ ファイルアクセス処理部， １２５ 乱数生成部， １２６ 暗号化部， １２７ 復号部， １２８ 通信部， １３１ 記憶部， １３２ データ設定処理部， １３３ 認証処理部， １３４ ファイルアクセス処理部， １３５ 乱数生成部， １３６ 暗号化部， １３７ 復号部， １３８ 通信部， １４１ マスタ鍵生成部， １４２ アクセス許諾チケット生成鍵生成部， ３００ 通信システム， ３１１ 情報処理端末， ３１２ ICカード， ３２１ 記憶部， ３２３ 認証処理部， ３２４ ファイルアクセス処理部， ３２５ 乱数生成部， ３２６ 暗号化部， ３２７ 復号部， ３２８ 通信部， ３３１ 記憶部， ３３２ データ設定処理部， ３３３Ａ 共通鍵認証処理部， ３３３Ｂ 認証処理部， ３３４ ファイルアクセス処理部， ３３５ 乱数生成部， ３３６ 暗号化部， ３３７ 復号部， ３３８ 通信部， ３４１ マスタ鍵生成部， ３４２ アクセス許諾チケット生成鍵生成部

Claims (8)

  1. 他の情報処理装置より、自分自身が保持する、情報管理方式が互いに異なる複数の領域のデータに対してアクセスを要求される情報処理装置であって、
    前記他の情報処理装置のアクセス先のうち、前記複数の領域の中の所定の領域に対するアクセス先について、前記所定の領域の情報管理方式による前記他の情報処理装置の認証処理を行う認証手段と、
    前記認証手段により正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信する受信手段と、
    前記所定の領域に予め保持する所定のデータ、前記所定の領域のルートディレクトリに対応する鍵情報であるルート鍵、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応する、前記所定の領域内のデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵、並びに、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応する、前記所定の領域以外の領域のデータを管理する鍵情報であって、前記領域の情報管理方式による認証処理に使用される他の鍵情報を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成するアクセス許諾チケット生成鍵生成手段と、
    前記アクセス許諾チケット生成鍵生成手段により生成された前記アクセス許諾チケット生成鍵を用いて、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出するチェック子算出手段と、
    前記チェック子算出手段により算出された前記チェック子を用いて、前記受信手段により受信された前記アクセス許諾チケットを検証するアクセス許諾チケット検証手段と
    を備える情報処理装置。
  2. 前記アクセス許諾チケット生成鍵生成手段は、前記他の鍵情報として、前記領域に対応する鍵情報であるエリア鍵と、アクセス先とされるデータのアクセス方法を制御するサービス鍵を使用する
    請求項１に記載の情報処理装置。
  3. 前記アクセス許諾チケット生成鍵生成手段は、前記アクセス制御鍵と、前記サービス鍵とで、鍵ビット長が互いに異なる場合、前記鍵ビット長が短いほうを、前記鍵ビット長が長い方に合わせるように前記鍵情報を整形する
    請求項２に記載の情報処理装置。
  4. 前記アクセス許諾チケット生成鍵生成手段は、前記所定のデータを前記ルート鍵で暗号化し、その暗号化結果をさらに、各他の鍵情報で１つずつ暗号化し、さらにその暗号化結果を、各アクセス制御鍵で１つずつ暗号化することにより、各鍵情報を縮退化して前記アクセス許諾チケット生成鍵を生成する
    請求項１に記載の情報処理装置。
  5. 他の情報処理装置より、自分自身が保持する、情報管理方式が互いに異なる複数の領域のデータに対してアクセスを要求される情報処理装置の情報処理方法であって、
    前記他の情報処理装置のアクセス先のうち、前記複数の領域の中の所定の領域に対するアクセス先について、前記所定の領域の情報管理方式による前記他の情報処理装置の認証処理を行い、
    正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信し、
    前記所定の領域に予め保持する所定のデータ、前記所定の領域のルートディレクトリに対応する鍵情報であるルート鍵、受信された前記アクセス許諾チケットに記述されるアクセスコードに対応する、前記所定の領域内のデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵、並びに、受信された前記アクセス許諾チケットに記述されるアクセスコードに対応する、前記所定の領域以外の領域のデータを管理する鍵情報であって、前記領域の情報管理方式による認証処理に使用される他の鍵情報を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成し、
    生成された前記アクセス許諾チケット生成鍵を用いて、前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出し、
    算出された前記チェック子を用いて、前記アクセス許諾チケットを検証する
    ステップを含む情報処理方法。
  6. 他の情報処理装置より、自分自身が保持する、情報管理方式が互いに異なる複数の領域のデータに対してアクセスを要求される情報処理装置を制御するプログラムであって、
    前記他の情報処理装置のアクセス先のうち、前記複数の領域の中の所定の領域に対するアクセス先について、前記所定の領域の情報管理方式による前記他の情報処理装置の認証処理を行い、
    正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信し、
    前記所定の領域に予め保持する所定のデータ、前記所定の領域のルートディレクトリに対応する鍵情報であるルート鍵、受信された前記アクセス許諾チケットに記述されるアクセスコードに対応する、前記所定の領域内のデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵、並びに、受信された前記アクセス許諾チケットに記述されるアクセスコードに対応する、前記所定の領域以外の領域のデータを管理する鍵情報であって、前記領域の情報管理方式による認証処理に使用される他の鍵情報を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成し、
    生成された前記アクセス許諾チケット生成鍵を用いて、前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出し、
    算出された前記チェック子を用いて、前記アクセス許諾チケットを検証する
    ステップを含むコンピュータが読み取り可能なプログラムが記録されている記録媒体。
  7. 他の情報処理装置より、自分自身が保持する、情報管理方式が互いに異なる複数の領域のデータに対してアクセスを要求されるコンピュータに実行させるプログラムにおいて、
    前記他の情報処理装置のアクセス先のうち、前記複数の領域の中の所定の領域に対するアクセス先について、前記所定の領域の情報管理方式による前記他の情報処理装置の認証処理を行い、
    正当な相手であると認証された前記他の情報処理装置より、前記他の情報処理装置がアクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを受信し、
    前記所定の領域に予め保持する所定のデータ、前記所定の領域のルートディレクトリに対応する鍵情報であるルート鍵、受信された前記アクセス許諾チケットに記述されるアクセスコードに対応する、前記所定の領域内のデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵、並びに、受信された前記アクセス許諾チケットに記述されるアクセスコードに対応する、前記所定の領域以外の領域のデータを管理する鍵情報であって、前記領域の情報管理方式による認証処理に使用される他の鍵情報を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成し、
    生成された前記アクセス許諾チケット生成鍵を用いて、前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出し、
    算出された前記チェック子を用いて、前記アクセス許諾チケットを検証する
    ステップを含む情報処理をコンピュータに実行させるプログラム。
  8. 第一の情報処理装置が、第二の情報処理装置が保持する、情報管理方式が互いに異なる複数の領域のデータに対してアクセスを要求する情報処理システムであって、
    前記第一の情報処理装置は、
    前記第二の情報処理装置と相互認証処理を行う第一の相互認証手段と、
    アクセスするデータを示すアクセスコード、および、チェック子を含むアクセス許諾チケットを前記第二の情報処理装置に送信する送信手段と
    を備え、
    前記第二の情報処理装置は、
    前記第一の情報処理装置のアクセス先のうち、前記複数の領域の中の所定の領域に対するアクセス先について、前記所定の領域の情報管理方式による前記第一の情報処理装置の認証処理を行う認証手段と、
    前記認証手段により正当な相手であると認証された前記第一の情報処理装置より、前記アクセス許諾チケットを受信する受信手段と、
    前記所定の領域に予め保持する所定のデータ、前記所定の領域のルートディレクトリに対応する鍵情報であるルート鍵、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応する、前記所定の領域内のデータの、アクセス方法を制御する鍵情報であるアクセス制御鍵、並びに、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応する、前記所定の領域以外の領域のデータを管理する鍵情報であって、前記領域の情報管理方式による認証処理に使用される他の鍵情報を使用して、チェック子を算出するための鍵情報であるアクセス許諾チケット生成鍵を生成するアクセス許諾チケット生成鍵生成手段と、
    前記アクセス許諾チケット生成鍵生成手段により生成された前記アクセス許諾チケット生成鍵を用いて、前記受信手段により受信された前記アクセス許諾チケットに記述されるアクセスコードに対応するチェック子を算出するチェック子算出手段と、
    前記チェック子算出手段により算出された前記チェック子を用いて、前記受信手段により受信された前記アクセス許諾チケットを検証するアクセス許諾チケット検証手段と
    を備える情報処理システム。
JP2008105023A 2008-04-14 2008-04-14 情報処理装置および方法、記録媒体、プログラム、並びに情報処理システム Pending JP2009258860A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2008105023A JP2009258860A (ja) 2008-04-14 2008-04-14 情報処理装置および方法、記録媒体、プログラム、並びに情報処理システム
US12/419,730 US8239681B2 (en) 2008-04-14 2009-04-07 Information processing device and method, recording medium, program and information processing system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008105023A JP2009258860A (ja) 2008-04-14 2008-04-14 情報処理装置および方法、記録媒体、プログラム、並びに情報処理システム

Publications (1)

Publication Number Publication Date
JP2009258860A true JP2009258860A (ja) 2009-11-05

Family

ID=41164954

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008105023A Pending JP2009258860A (ja) 2008-04-14 2008-04-14 情報処理装置および方法、記録媒体、プログラム、並びに情報処理システム

Country Status (2)

Country Link
US (1) US8239681B2 (ja)
JP (1) JP2009258860A (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013251609A (ja) * 2012-05-30 2013-12-12 Sony Corp 情報処理装置、ｉｃチップ及び情報処理方法

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2445573A1 (en) * 2001-04-27 2002-11-07 Massachusetts Institute Of Technology Method and system for micropayment transactions
JP2009276916A (ja) 2008-05-13 2009-11-26 Sony Corp 通信装置、通信方法、リーダライタ及び通信システム
CN102103651B (zh) * 2009-12-21 2012-11-14 中国移动通信集团公司 一种一卡通系统的实现方法和系统以及一种智能卡
US20110178903A1 (en) * 2010-01-15 2011-07-21 Bank Of America Corporation Personal identification number changing system and method
US8707413B2 (en) * 2010-01-15 2014-04-22 Bank Of America Corporation Authenticating a chip card interface device
US9038188B2 (en) * 2010-01-15 2015-05-19 Bank Of America Corporation Protecting data stored in a chip card interface device in the event of compromise
FR2957444B1 (fr) * 2010-03-15 2012-03-09 Citizengate Support de donnees pour le controle d'entites, dispositif et procede de controle d'entites
US8886935B2 (en) * 2010-04-30 2014-11-11 Kabushiki Kaisha Toshiba Key management device, system and method having a rekey mechanism
JP4909431B2 (ja) * 2010-05-14 2012-04-04 株式会社エヌ・ティ・ティ・ドコモ ライセンス発行システム、クライアント端末、サーバ、及びライセンス発行方法
JP5824849B2 (ja) * 2011-04-22 2015-12-02 ソニー株式会社 情報処理装置および情報処理方法
JP5113936B1 (ja) * 2011-11-24 2013-01-09 楽天株式会社 情報処理装置、情報処理方法、情報処理装置用プログラム、および、記録媒体
CN104145446B (zh) * 2012-02-29 2018-06-05 黑莓有限公司 操作计算设备的方法、计算设备及计算机程序
CN104137466B (zh) 2012-02-29 2018-03-30 黑莓有限公司 操作计算设备的方法及计算设备
CN104145444B (zh) 2012-02-29 2018-07-06 黑莓有限公司 操作计算设备的方法、计算设备及计算机程序
CN102737185B (zh) * 2012-06-08 2015-07-01 杭州华澜微科技有限公司 数字版权保护方法
JP2016001454A (ja) * 2014-05-20 2016-01-07 株式会社東芝 携帯可能電子装置、プログラム、端末および方法
JP6561436B2 (ja) * 2014-07-17 2019-08-21 セイコーエプソン株式会社 情報処理装置、情報処理装置を制御する方法、コンピュータープログラム
US9954834B2 (en) 2015-04-15 2018-04-24 Blackberry Limited Method of operating a computing device, computing device and computer program
US9768966B2 (en) * 2015-08-07 2017-09-19 Google Inc. Peer to peer attestation
WO2017122361A1 (ja) * 2016-01-15 2017-07-20 富士通株式会社 セキュリティ装置および制御方法
JP6753713B2 (ja) * 2016-07-15 2020-09-09 株式会社東芝 Ｉｃモジュール、ｉｃカード、及び照合装置
SG10201906806XA (en) * 2019-07-23 2021-02-25 Mastercard International Inc Methods and computing devices for auto-submission of user authentication credential
US11374770B2 (en) * 2019-11-25 2022-06-28 Texas Instruments Incorporated Data integrity validation via degenerate keys
US11469890B2 (en) * 2020-02-06 2022-10-11 Google Llc Derived keys for connectionless network protocols
CN112073194B (zh) * 2020-09-10 2021-06-22 四川长虹电器股份有限公司 一种抵抗密钥泄露的安全管理方法
US11895251B2 (en) * 2020-09-18 2024-02-06 Assa Abloy Ab Mutual authentication with pseudo random numbers

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10327142A (ja) * 1997-03-26 1998-12-08 Sony Corp 認証システムおよび方法、並びに認証装置および方法
JP2002278838A (ja) * 2001-03-15 2002-09-27 Sony Corp メモリアクセス制御システム、デバイス管理装置、パーティション管理装置、メモリ搭載デバイス、およびメモリアクセス制御方法、並びにプログラム記憶媒体
JP2005135251A (ja) * 2003-10-31 2005-05-26 Fujitsu Ltd Ｉｄタグを読み取る情報処理装置、ｉｄタグを読み取るためのプログラム、およびｉｄタグに書き込むためのプログラム

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3702923B2 (ja) 1997-02-28 2005-10-05 ソニー株式会社 情報処理方法および情報処理装置
US6061692A (en) * 1997-11-04 2000-05-09 Microsoft Corporation System and method for administering a meta database as an integral component of an information server
JP4204133B2 (ja) * 1999-02-26 2009-01-07 ローム株式会社 通信システム
JP2002108710A (ja) * 2000-07-24 2002-04-12 Sony Corp 情報処理システム、情報処理方法、および情報処理装置、並びにプログラム提供媒体
WO2003003194A1 (fr) * 2001-06-27 2003-01-09 Sony Corporation Dispositif a circuit integre, dispositif de traitement de l'information, procede de gestion de memoire de support d'information, terminal mobile, dispositif a circuit integre a semi-conducteur, et procede de communication par terminal mobile
AU2003202815A1 (en) * 2002-01-12 2003-07-24 Coretrust, Inc. Method and system for the information protection of digital content
US7313705B2 (en) * 2002-01-22 2007-12-25 Texas Instrument Incorporated Implementation of a secure computing environment by using a secure bootloader, shadow memory, and protected memory
US7770212B2 (en) * 2002-08-15 2010-08-03 Activcard System and method for privilege delegation and control
JP2006140625A (ja) * 2004-11-10 2006-06-01 Toshiba Corp 情報処理装置
US20070262138A1 (en) * 2005-04-01 2007-11-15 Jean Somers Dynamic encryption of payment card numbers in electronic payment transactions
JP5205720B2 (ja) * 2006-05-12 2013-06-05 ソニー株式会社 通信システムおよび通信方法、デバイス、情報処理装置、並びにプログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10327142A (ja) * 1997-03-26 1998-12-08 Sony Corp 認証システムおよび方法、並びに認証装置および方法
JP2002278838A (ja) * 2001-03-15 2002-09-27 Sony Corp メモリアクセス制御システム、デバイス管理装置、パーティション管理装置、メモリ搭載デバイス、およびメモリアクセス制御方法、並びにプログラム記憶媒体
JP2005135251A (ja) * 2003-10-31 2005-05-26 Fujitsu Ltd Ｉｄタグを読み取る情報処理装置、ｉｄタグを読み取るためのプログラム、およびｉｄタグに書き込むためのプログラム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013251609A (ja) * 2012-05-30 2013-12-12 Sony Corp 情報処理装置、ｉｃチップ及び情報処理方法

Also Published As

Publication number Publication date
US8239681B2 (en) 2012-08-07
US20090259850A1 (en) 2009-10-15

Similar Documents

Publication Publication Date Title
JP2009258860A (ja) 情報処理装置および方法、記録媒体、プログラム、並びに情報処理システム
JP2009100394A (ja) 情報処理装置および方法、記録媒体、プログラム、並びに情報処理システム
JP4118092B2 (ja) 記憶装置および情報処理装置
CN110417750B (zh) 基于区块链技术的文件读取和存储的方法、终端设备和存储介质
JP4907895B2 (ja) プライベートデータを露出せずに通信ネットワークを介してパスワードで保護されたプライベートデータを回復する方法およびシステム
KR102205654B1 (ko) 분산 환경에서의 신원 인증 방법
TWI454111B (zh) 用於確保通訊之鑑別及完備性的技術
US11184161B2 (en) Method and devices for verifying authorization of an electronic device
US11258591B2 (en) Cryptographic key management based on identity information
US20130219481A1 (en) Cyberspace Trusted Identity (CTI) Module
US20130007465A1 (en) Apparatus, Systems and Method for Virtual Desktop Access and Management
US20200059470A1 (en) Industrial internet encryption system
WO2005098639A9 (ja) ログインシステム及び方法
JP2006080636A (ja) 情報処理装置
WO2005096158A1 (ja) 利用認証方法、利用認証プログラム、情報処理装置および記録媒体
JP2005122402A (ja) Ｉｃカードシステム
JP2005260676A (ja) セキュリティ装置、情報処理装置、セキュリティ装置の制御方法、情報処理装置の制御方法、該制御方法を実行させるための装置実行可能なプログラムおよびチケット・システム
KR20080065661A (ko) 파일 시스템으로의 접근을 제어하기 위한 방법, 파일시스템에 사용하기 위한 관련 시스템, ｓｉｍ 카드 및컴퓨터 프로그램 제품
US20150303964A1 (en) Telecommunications chip card
CN104868998A (zh) 一种向电子设备供应加密数据的系统、设备和方法
JP2004013748A (ja) 自律型ｉｃカード
US20130173923A1 (en) Method and system for digital content security cooperation
JP4187285B2 (ja) 認証子付与方法および認証子付与装置
CN116783864A (zh) 使用非接触式卡安全验证医疗状态
JP2009105856A (ja) 情報処理装置および方法、記録媒体、プログラム、並びに情報処理システム

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100323

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100517

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110210

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20110816