JP2004013748A - 自律型ｉｃカード - Google Patents
自律型ｉｃカード Download PDFInfo
- Publication number
- JP2004013748A JP2004013748A JP2002169315A JP2002169315A JP2004013748A JP 2004013748 A JP2004013748 A JP 2004013748A JP 2002169315 A JP2002169315 A JP 2002169315A JP 2002169315 A JP2002169315 A JP 2002169315A JP 2004013748 A JP2004013748 A JP 2004013748A
- Authority
- JP
- Japan
- Prior art keywords
- chip
- present
- card
- communication
- key
- 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.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
- G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
- G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
- G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
- G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
- G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
- G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
- G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
- G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
- G06K19/073—Special arrangements for circuits, e.g. for protecting identification code in memory
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K7/00—Methods or arrangements for sensing record carriers, e.g. for reading patterns
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/409—Device specific authentication in transaction processing
- G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
- G06Q20/40975—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
- G07F7/0806—Details of the card
- G07F7/0833—Card having specific functional components
- G07F7/084—Additional components relating to data transfer and storing, e.g. error detection, self-diagnosis
Abstract
【課題】ＩＣカードと他の通信装置との間における正確な情報の安全な通信を保証する。
【解決手段】自律型ＩＣカード１は、ＩＣカードリーダ／ライター２と物理層を介して接続されるホストデバイスインターフェース１７に加えて、ＩＣカード端末本体３にネットワークを介して接続される通信装置５と直接的に通信を行うための論理的な外部通信インターフェース１６を備えている。通信制御部１５は、外部通信インターフェース１６を介して通信装置５と直接的に通信を行うためのソフトウェアモジュールで構成される。ＣＰＵ１０は、通信制御部１５を介して認証すると共に、不揮発性メモリ１３に記憶された価値情報を読み出し、暗号処理部１４を介して暗号化を行い、暗号化された価値情報を通信制御部１５及び外部通信インターフェース１６を介して直接的に通信装置５に送る。
【選択図】 図１
【解決手段】自律型ＩＣカード１は、ＩＣカードリーダ／ライター２と物理層を介して接続されるホストデバイスインターフェース１７に加えて、ＩＣカード端末本体３にネットワークを介して接続される通信装置５と直接的に通信を行うための論理的な外部通信インターフェース１６を備えている。通信制御部１５は、外部通信インターフェース１６を介して通信装置５と直接的に通信を行うためのソフトウェアモジュールで構成される。ＣＰＵ１０は、通信制御部１５を介して認証すると共に、不揮発性メモリ１３に記憶された価値情報を読み出し、暗号処理部１４を介して暗号化を行い、暗号化された価値情報を通信制御部１５及び外部通信インターフェース１６を介して直接的に通信装置５に送る。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
本発明は、ＩＣカードに関し、特に、ＩＣカード端末に直接又はネットワークを介して接続される他の装置と、直接かつ自律的に通信を行う自律型ＩＣカードに関する。
【０００２】
【従来の技術】
図４は、従来におけるＩＣカードとＩＣカード端末との信号のやり取りを説明するための図である。
ここで、ＩＣカード端末は、ＩＣカードリーダ／ライター２００とＩＣカード端末本体３００とで構成される。尚、ここではＩＣカード１００とＩＣカードリーダ／ライター２００とは模式的に離れて示されているが、このように非接触型であってもよいし、勿論、ＩＣカード１００がＩＣカードリーダ／ライター２００に典型的には挿入される接触型であってもよい。
【０００３】
このようなＩＣカード１００を利用した処理においては、ＩＣカード端末本体３００がマスター装置であり、ＩＣカード１００がスレーブ装置となっている。すなわち、ＩＣカード１００を利用した処理を行いたい場合、先ずＩＣカード端末本体３００に備えられた入力端末（図示せず）に操作者は指示入力する。それに応じて、マスター装置たるＩＣカード端末本体３００は、ＩＣカードリーダ／ライター２００を介して命令をＩＣカード１００に送る。その命令を受け取ったスレーブ装置たるＩＣカード１００はその命令に応じた処理を行い、その実行結果をＩＣカードリーダ／ライター２００を介してＩＣカード端末本体３００に返す。
【０００４】
図５は、従来において、２枚のＩＣカードが互いに通信を行う場合の信号のやり取りを示す図である。
同図において、図４に示した構成に加えて、ＩＣカードリーダ／ライター２００ｂがＩＣカード端末本体３００に接続されており、そのＩＣカードリーダ／ライター２００ｂにＩＣカード１００ｂが接触式又は非接触式で接続される形態になっている。
【０００５】
そこで、図４の場合と同様、先ずＩＣカード端末本体３００に備えられた入力端末（図示せず）に操作者はカード間通信に係る指示入力する。それに応じて、ＩＣカード端末本体３００は、ＩＣカードリーダ／ライター２００ａを介して命令をＩＣカード１００ａに送る。その命令を受け取ったＩＣカード１００ａはその命令に応じた処理を行い、その結果である返答Ａを出力する。ＩＣカード１００ａから出力された返答Ａは、ＩＣカードリーダ／ライター２００ａを介してＩＣカード端末本体３００に入力される。ＩＣカード端末本体３００は、その返答Ａたる情報に対しての中継動作を行う。ＩＣカード端末本体３００から出力された返答Ａは、ＩＣカードリーダ／ライター２００ｂを介してＩＣカード１００ｂに入力される。ＩＣカード１００ｂは、入力された返答Ａに応じた処理を行い、その結果として返答Ｂを出力する。ＩＣカード１００ｂから出力された返答Ｂは、ＩＣカードリーダ／ライター２００ｂを介してＩＣカード端末本体３００に入力される。ＩＣカード端末本体３００は、その返答Ｂたる情報に対しての中継動作を行う。ＩＣカード端末本体３００から出力された返答Ｂは、ＩＣカードリーダ／ライター２００ａ介してＩＣカード１００ａに入力される。
【０００６】
以上のようなＩＣカード１００ａとＩＣカード１００ｂとの間のやりとりが更に続いても、基本的には動作は同じである。すなわち、ＩＣカード端末本体３００は、ＩＣカード１００ａＩＣカード１００ｂとの間でやりとりされる情報に対する中継動作を行うという役目を必ず担っている。
【０００７】
【発明が解決しようとする課題】
ところで、従来におけるＩＣカード間通信においては、上述のようにＩＣカード端末本体が必ずＩＣカード間通信に係る情報の中継動作を行っている。従って、従来においては、ＩＣカード端末本体に代表される介在装置が、ＩＣカード間の通信情報を改竄したり盗聴したりすることが可能であった。故に、従来においては、ＩＣカード間の正確な情報の通信が保証されないという課題があった。
【０００８】
本発明は、上述のような事情を鑑みて為されたものであり、本発明の目的は、ＩＣカードがＩＣカード端末に直接又はネットワークを介して接続される他の通信装置と通信を行うに際し、ＩＣカードと他の通信装置との間に介在するＩＣカード端末等の装置を見かけ上介在させることなく、他の通信装置と直接通信を行うことにより、正確な情報の安全な通信を保証することができる自律型ＩＣカードを提供することにある。
【０００９】
【課題を解決するための手段】
上記目的を達成するため、請求項１の自律型ＩＣカードは、ＩＣカード端末と物理層を介して接続される論理ホストインターフェースと、前記ＩＣカード端末を物理的に介して接続される通信装置と通信を行うための論理外部通信インターフェースと、前記論理外部通信インターフェースを介し、前記通信装置の接続を認識し、前記通信装置と直接的に通信を行うように構成されたＩＣチップと、を備えることを要旨とする。
【００１０】
本発明によれば、本発明の自律型ＩＣカードは、ＩＣカード端末を介して接続される通信装置を自ら認識し、その通信装置と直接的に通信を行うことができる。
【００１１】
また、請求項２の発明は、請求項１の自律型ＩＣカードにおいて、前記ＩＣチップは、前記論理外部通信インターフェースを介して前記通信装置と直接的に通信を行うためのソフトウェアモジュールたる通信制御部を有することを要旨とする。
【００１２】
本発明によれば、通信制御部は、接続されているＩＣカード端末を意識しないソフトウェアモジュールによりその処理を行うことができる。
【００１３】
また、請求項３の発明は、請求項２の自律型ＩＣカードにおいて、前記通信制御部は、前記通信装置に対してセッション通信路を構築するセッション管理命令群と、前記通信装置に対してトランザクションセッションを構築するトランザクション管理命令群と、を有することを要旨とする。
【００１４】
また、請求項４の発明は、請求項１の自律型ＩＣカードにおいて、前記ＩＣチップは、前記通信装置と相互に認証処理を行うと共に、前記通信装置との通信に係る情報に対して暗号化／復号化を施す暗号処理部を有することを要旨とする。
【００１５】
本発明によれば、暗号処理部は、通信装置と相互に認証処理を行うと共に、通信装置との通信に係る情報に対して暗号化／復号化を施す。
【００１６】
また、請求項５の発明は、請求項４の自律型ＩＣカードにおいて、前記ＩＣチップは、割り当てられた固有の識別子を有し、その識別子に基づき、前記通信装置を識別し、相互の認証処理を行うことを要旨とする。
【００１７】
また、請求項６の発明は、請求項４の自律型ＩＣカードにおいて、前記暗号処理部は、認識された前記通信装置の種別に応じて、複数の認証処理及び複数の暗号処理の中から適した認証処理及び暗号処理を選択してそれらの処理を行うことを要旨とする。
【００１８】
また、請求項７の発明は、請求項１乃至６の自律型ＩＣカードにおいて、前記ＩＣチップは、価値情報が格納される記憶部を有し、前記他の通信装置とその価値情報に係る通信を行うことを要旨とする。
【００１９】
また、請求項８の発明は、請求項１乃至７の自律型ＩＣカードにおいて、前記ＩＣカード端末と前記他の通信装置は、ネットワークを介して接続されていることを要旨とする。
【００２０】
また、請求項９の発明は、請求項１乃至８の自律型ＩＣカードにおいて、前記論理ホストインターフェース及び前記論理外部通信インターフェースと、前記ＩＣカード端末とは、非接触で接続されることを要旨とする。
【００２１】
【発明の実施の形態】
以下、図面に基づいて、本発明における自律型ＩＣカードの実施形態について詳細に説明する。
【００２２】
図１は、本発明における自律型ＩＣカードの一実施形態の論理的な構成を示す図である。
【００２３】
図１において、本発明の自律型ＩＣカード１は、ＣＰＵ１０と、ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）１１と、ＲＡＭ（ｒａｎｄａｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）１２と、不揮発性メモリ１３と、暗号処理部１４と、通信制御部１５と、外部通信インターフェース１６と、ホストデバイスインターフェース１７とで構成される。
【００２４】
尚、上記構成においては、物理的な構成（ハードウェア）と論理的な構成（ソフトウェア）が混在しているが、以下それぞれについて説明する。
【００２５】
ホストデバイスインターフェース１７は、従来から備わっている物理的インターフェースであり、外部との通信を行うためのものである。従来と同様、接触型と非接触型がある。ＣＰＵ１０は、一部の浮動小数点演算を除き、全ての演算を行う中央演算装置である。尚、浮動小数点演算については別途浮動小数点演算装置が備わっている（図示せず）。ＲＯＭ１１は、読み出し専用メモリであり、当該自律型ＩＣカード１用の固有のソフトウェア（ＯＳ、プログラム）や後述する本発明チップＩＤが格納されている。ＲＡＭ１２は、読み書き可能メモリであり、当該自律型ＩＣカード１内で動作するソフトウェアが扱うデータが一時的に記憶されるメモリである。尚、ＩＣカードへの電力供給が絶たれると内容全て消去される。
【００２６】
不揮発性メモリ１３は、後述する価値情報が格納される。価値情報とは、電子チケット、電子マネー等の価値を含むデータをいう。尚、不揮発性メモリ１３は、内容保持型メモリなので電力の供給が絶たれても内容が保持される。
以上が物理的な構成部分である。
【００２７】
外部通信インターフェース１６は、上記ＣＰＵ１０等で構成される後述する本発明チップが外部との直接通信を行う論理的なインターフェースである。従来のＩＣカードは、それが物理的に接続されている装置、典型的にはＩＣカード端末、とのみ通信を行う論理インターフェースしか持たなかったが、本発明の自律型ＩＣカード１は、論理ホストインターフェースの他に、外部の装置（後述の本発明チップ搭載サービスクライアント）と直接通信を行う外部通信インターフェース１６を備えている。尚、この外部通信インターフェース１６は、後の「４．本発明チップ ＡＰＩプロトコル」で詳述するプロトコルに従って通信を行うインターフェースである。
【００２８】
通信制御部１５は、外部通信インターフェース１６を介して外部の装置との間で行われる通信を制御するソフトウェアモジュールである。後述する「１０．本発明チップ ＡＰＩ仕様」全体を実現するソフトウェアモジュールであるが、特に「１０．１セッション管理命令群」及び「１０．２トランザクション管理命令群」と関わりが深いソフトウェアモジュールである。このモジュールにより外部の装置との間で直接的に通信が行われる。
【００２９】
暗号処理部１４は、後述する「３．４認証・アクセス制御・暗号」、「５．ｅＴＰ鍵証明書」及び「６．鍵実体」において定義された多様な種類の相互認証及び暗号通信を可能にするためのモジュールである。暗号処理部１４は、通信を行う相手装置に応じて、複数の相互認証及び複数の暗号通信の中から適したものを選択切替している。尚、通信制御部１５に基づく直接通信の上に、暗号処理部１４による相互認証及び暗号通信を行えば、間に介在する装置、例えばＩＣカード端末、によりデータ内容が盗まれたり、データが改竄されるという危険性が更に低くなる。
【００３０】
尚、図１に示された本発明に係る構成部は、好適には、最後に詳細にその仕様が列記されるワンチップマイクロコンピュータ（以下、ＩＣチップと称する）で具現化される。
【００３１】
ここで、本発明の自律型ＩＣカードに搭載されるＩＣチップの全体的な特徴を説明する。
【００３２】
本発明に係るＩＣチップは、分散環境におけるノードとして機能するように設計されている。従って、本発明のＩＣカードがＩＣカードリーダ／ライターを有するＩＣカード端末本体に接触式又は非接触式で接続されて機能している装置が、ネットワークを介して、例えば他のＩＣカードと物理的に通信できるように構成されている場合、本発明に係るＩＣチップを有するそれらのＩＣカードは通信ネットワーク上でノードとしての機能を有する。そして、このときＩＣカードリーダ／ライター及びＩＣカード端末本体は、ネットワークとコンタクトレス通信の物理層を橋渡しするゲートウェイ（ブリッジ）の役割を果たしている。すなわち、前述の外部通信インターフェース１６が、分散システムにおけるノードとしてのＩＣカードの通信を司っており、ホストデバイスインターフェース１７が、コンタクトレス通信の物理層を橋渡しする役割を担っている。
【００３３】
そこで、分散環境におけるノードとして機能するために、本発明に係るＩＣチップは、上述のようなネットワークを最も簡単な例とする分散システム全体において固有の識別子（ＩＤ）を有している。
【００３４】
また、本発明の自律型ＩＣカードに搭載されるＩＣチップは、ネットワークを介して接続された、同様のＩＣチップを搭載した複数の装置を識別し、それらの装置との相互認証を先ず行う。そして、それらの装置が正規の実体であると確認した後にそれらの装置との通信を行うように設計されている。その認証においては、２つのモード、すなわち（情報）発行者モード及び所有者モードがある。これは後に詳述する。
【００３５】
更に、本発明に係るＩＣチップにおいては、それが有する資源を保護するために、前述のＩＤに基づいたアクセス制御リストが採用されている。つまり、チップ、ファイル（、レコード）にはアクセス制御リストが付加されている。
【００３６】
本発明に係るＩＣチップでは、アクセス制御リストの中で、「所有者」、「発行者」、「その他」のサービスクライアントを統一的に扱い、それぞれの持つ権限に応じて、アクセス制御リストを変更するＡＰＩを発行することによって、アクセス権限の制限や解放、移譲といった制御を柔軟に行うことを可能にしている。
【００３７】
また、本発明に係るＩＣチップにおいては、コンテンツを複数のコンテンツホールダ、例えば、本発明チップとネットワーク上の価値情報格納サーバー、の間で分散して保持する、ハイブリッド方式をサポートし、そのための機構として、コンテンツ間のリンク機能を提供している。
【００３８】
次に、本発明の自律型ＩＣカードによる通信の具体例について説明する。
図２は、本発明の自律型ＩＣカードによるＩＣカード間通信を行うシステムの構成を示す図である。
同図において、自律型ＩＣカード１ａは、ＩＣカード端末本体３に備わったＩＣカードリーダ／ライター２ａに対して接触式又は非接触式に接続されている。また、同様に、自律型ＩＣカード１ｂは、ＩＣカード端末本体３に備わったＩＣカードリーダ／ライター２ｂに対して接触式又は非接触式に接続されている。
【００３９】
かかる構成において、自律型ＩＣカード１ａに対して自律型ＩＣカード１ｂと通信を行わせたい場合、操作者は、ＩＣカード端末本体３に備えられた入力端末（図示せず）にカード間通信に係る指示入力する。それに応じて、ＩＣカード端末本体３は、ＩＣカードリーダ／ライター２ａを介して命令を自律型ＩＣカード１ａに送る。その命令を受け取った自律型ＩＣカード１ａは、図１に示した外部通信インターフェース１６を介して、ソフトウェア的に、直接かつ自律的に、自律型ＩＣカード１ｂと通信を行う。自律型ＩＣカード１ａがこのように自律型ＩＣカード１ｂと直接通信できるのは、前述のように、自律型ＩＣカード１ａが分散環境におけるノードとして機能することができるからである。かかる通信において、図１に示した暗号処理部１４により通信データに対して暗号化及び復号化を行えば、通信途中における改竄や盗聴という危険を確実に回避できる。
【００４０】
図３は、本発明の自律型ＩＣカードによる通信を行う他のシステムの構成を示す図である。
本発明の自律型ＩＣカードによる通信においては、通信の相手がＩＣカードである必要はなく他の通信装置であってもよい。同図において、ＩＣカード端末本体３はネットワーク４を介して他の通信装置５と接続されている。自律型ＩＣカード１ａがネットワーク４を介して通信装置５と通信を行う場合、ＩＣカード端末本体３から命令を受けた自律型ＩＣカード１ａは、ソフトウェア的に、直接かつ自律的に、通信装置５と通信を行う。
【００４１】
以下、本発明の自律型ＩＣカードに搭載されるＩＣチップ（以下、単に、本発明チップと称する）の詳細仕様を説明する。以下の説明中、Ｃｏｎｔｅｎｔｓ Ｈｏｌｄｅｒ（ＣＨｓ）が上述の自律型ＩＣカード１，１ａに対応しており、Ｓｅｒｖｉｃｅ Ｃｌｉｅｎｔ（ＳＣｓ）が、自律型ＩＣカード１，１ａと通信を行う全ての装置、すなわち上述のＩＣカード端末本体３、自律型ＩＣカード１ｂ及び他の通信装置５に対応している。
【００４２】
尚、全体像を容易に把握できるようにするため、目次を付し、説明本体には各構成ごとに見出しを付けた。
【００４３】
目次
１．はじめに
１．１分散環境ノードとしての本発明チップ
１．２本発明チップＩＤで特定する相互認証方式
１．３本発明チップＩＤに基づいたアクセス制御リスト方式による資源保護機構
１．４チップ所有者・価値情報発行者・価値情報利用者に対する総合的アクセス制御の実現
１．５ロールバック可能なトランザクション機構
１．６リンク機能を持った記憶構造
１．７関連チップ体系との整合性
１．８多様なチップに対応したゆるやかな標準化
２．システム仕様
２．１システムアーキテクチャ
２．２本発明チップ識別子（本発明チップＩＤ）
３．本発明チップ概要
３．１本発明チップ
３．２データ構造モデル
３．３本発明チップ ＡＰＩ
３．４認証・アクセス制御・暗号
４．本発明チップ ＡＰＩプロトコル
４．１パケット形式
４．２命令識別子（コマンドＩＤ）一覧
４．３エラーコード一覧
４．４ ＭＡＣ・トレーラ
４．５セッション通信と非セッション型通信
５．ｅＴＰ鍵証明書
セッション構築時における認証時の証明書の利用
１．概要
６．鍵実体
７．本発明標準コンテンツ形式
８．鍵実体による本発明標準コンテンツ操作時の決算処理
９．本発明チップ ＡＰＩ仕様（データ型定義）
１０．本発明チップ ＡＰＩ仕様（命令定義）
１０．１セッション管理命令群
１０．２トランザクション管理命令群
１０．３ファイル管理命令群
１０．４レコード管理命令群
１０．５鍵実体管理命令群
１０．６認証補助管理命令群
暗号実装仕様
１．はじめに
本発明チップ（価値情報付加チップ）は、本発明関連プロジェクトが目指す、超機能分散システムにおいて、価値情報の格納媒体となるコンピュータシステム（例えばＩＣカード等）および、その外部仕様である。今後の技術の進展を想定し、８ビットＣＰＵ版、１６ビットＣＰＵ版、３２ビットＣＰＵ版とそれぞれシリーズ化されており、共通する操作に関しては共通のコマンド及びメッセージフォーマットを提供する。本書は、特に本発明チップ仕様体系の中でも１６ビットＣＰＵ版ＩＣチップを対象ハードウェアとした仕様の概要を説明したものである。
【００４４】
本章では、既存の他の耐タンパーチップと比べた場合の、本発明チップの特長を述べる。
【００４５】
１．１分散環境ノードとしての本発明チップ
本発明チップは従来型のＩＣチップのように、コンピュータの周辺機器として、リーダライタを通して操作されるものではなく、分散環境におけるノードとして設計されている。ネットワーク上のサービス提供モジュールとチップ、チップとカードが対等にｐｅｅｒ−ｔｏ−ｐｅｅｒで通信する。リーダライタ装置は、ＬＡＮとコンタクトレス通信の物理層を橋渡しするゲートウェイ（ブリッジ）となる。
【００４６】
本発明チップアーキテクチャでは、本発明チップは分散システム全体でユニークな識別子（本発明チップＩＤ）を持つ。本発明チップＩＤは、チップを物理的に識別するだけでなく、分散環境上での経路制御にも利用され、認証通信における相手に識別子として利用される。
【００４７】
従って本発明チップの認証の対象は例えば、リーダライタではなく、ネットワークとリーダライタを経由して、チップと情報交換をするネットワーク上の計算実体（Ｃｏｎｔｅｎｔｓ Ｈｏｌｄｅｒｓ）である。
【００４８】
１．２本発明チップＩＤで特定する相互認証方式
本発明チップは、相互認証を行い、正規な実体であることを確認してから通信を行う。本発明チップアーキテクチャでは、アクセス対象である本発明チップ搭載Ｃｏｎｔｅｎｔｓ Ｈｏｌｄｅｒ（ＣＨｓ）も、アクセス側である本発明チップ搭載Ｓｅｒｖｉｃｅ Ｃｌｉｅｎｔ（ＳＣｓ）も、ともに一貫したユニークな識別子（本発明チップＩＤ）を備え、相互認証後には、相手の本発明チップＩＤを確実に把握する。
【００４９】
１．３本発明チップＩＤに基づいたアクセス制御リスト方式による資源確保機構
本発明チップは、相互認証によって本発明チップ ＡＰＩを発行するＳＣを特定する。そこで、本発明チップが持つ資源を保護するために、この本発明チップＩＤに基づいたアクセス制御リストを使う。現在の本発明チップでは、資源に対して、「発行者」（ＩＳＳＵＥＲ）、「所有者」（ＯＷＮＥＲ）といった属性を、本発明チップＩＤで表現している。さらに、アクセス制御リストによって、「発行者」・「所有者」・「それ以外」のＳＣｓが発行できる命令を指定できる。
【００５０】
１．４チップ所有者・価値情報発行者・価値情報利用者に対する統合的アクセス制御の実現
本発明チップでは、価値情報を格納する多様なアプリケーションが実装される可能性がある。価値情報には様々なタイプがあり、例えば、チップ上にある情報でも、以下のようなものが考えられる。
【００５１】
−チップの所有者は変更できずに情報の発行者だけが変更できる情報
（例：電子チケットの座席番号）
−チップの所有者でさえ見せない情報（例：電子チケット変更の鍵）
−チップの所有者だけが完全に制御できる情報（例：所有者の個人情報）
−読むことはだれでもできる情報
本発明チップでは、アクセス制御リストの中で、「所有者」、「発行者」、「その他」のＳＣｓを統一的に扱い、それぞれのもつ権限に応じて、アクセス制御リストを変更するＡＰＩを発行することによって、アクセス権限の制御や解放、委譲といった制御を柔軟に行うことを可能にしている。
【００５２】
１．５ロールバック可能なトランザクション機構
本発明チップに価値情報を移動する時は、安全に行う必要がある。そこで、本発明チップでは、特に価値情報の作成と削除に関しては、処理のＡｔｏｍｉｃｉｔｙを保証するために、トランザクション機構を提供している。トランザクションを開始したあと、発行された命令による操作は、トランザクション終了時のコミット命令によって反映される。アボート命令が発行された場合、また規定したタイムアウト時間に達するまでコミット命令が到着しない場合は、発行された命令に関してロールバック（ｒｏｌｌ−ｂａｃｋ）される。同様に、トランザクション途中に、何らかのトラブルによって、本発明チップが電源遮断された場合は、次に本発明チップがアクティブになった初期時にロールバック処理が行われる。
【００５３】
１．６リンク機能を持った記憶構造
現在、耐タンパーチップは、情報処理能力においても記憶容量などの資源においても多様なものが存在する。その中でも、資源に乏しいハードウェアでは、想定するアプリケーションの全ての価値情報をチップに格納できないケースもある。一方、チップがそれぞれ分散して価値情報を保持する方式も、処理効率の観点から望ましい。そこで、本発明ではコンテンツを複数の本発明コンテンツホールダ、例えば、本発明チップとネットワーク上の価値情報格納サーバー、の間で分散して保持する、ハイブリッド方式をサポートし、そのための機構として、コンテンツ間のリンク機能を提供している。
【００５４】
１．７関連チップ体系との整合性
本発明チップはＡＰＩのコマンドコンベンション、エラーコード、資源の静的・動的な扱い方の方法などを本発明関連プロジェクトの他のアーキテクチャと整合性を持たせている。例えば、エラーコードの一般的な部分は関連チップと本発明チップは共通である。これによって、関連チップアーキテクチャ上での開発経験のある技術者が本発明チップアプリケーションを開発することを支援する。
【００５５】
１．８多様なチップに対応したゆるやかな標準化
本発明チップは、８ｂｉｔＣＰＵ〜３２ｂｉｔＣＰＵ、Ｃｏｎｔａｃｔ／Ｃｏｎｔａｃｔ−ｌｅｓｓ／Ｄｕａｌ Ｉｎｔｅｒｆａｃｅ、スマートカード〜ＲＦ ＩＤと、様々なＩＣカードに対して、整合性のある一貫したＡＰＩの体系を提供する。
【００５６】
２．システム仕様
２．１システムアーキテクチャ
本発明チップアーキテクチャは、耐タンパ性を有する価値情報を安全に格納し、コンピュータネットワーク上を安全に交換するための分散システムアーキテクチャであり、主に、以下の要素から構成される。
【００５７】
（Ａ）価値情報ネットワーク系（Ｅｎｔｉｔｙ Ｎｅｔｗｏｒｋ Ｉｎｆｒａｓｔｒｕｃｔｕｅｒ）
価値情報を交換するためのアーキテクチャ。以下の二つの要素から構成される。
【００５８】
Ａ−ｉ）本発明チップ搭載コンテンツホールダ（ＣＨｓ）
本発明チップ搭載コンテンツホールダは、価値情報を格納し、本発明チップ搭載 ＡＰＩを提供してこの価値情報を外部から操作させる、分散システム上の計算実体で。例として、以下のようなものがある。
【００５９】
本発明チップ：
価値情報を安全に格納する、耐タンパ性を有するＬＳＩチップである。
【００６０】
本発明チップボックス：
価値情報を安全に格納する、耐タンパをもった筺体に収められた大容電子金庫。
【００６１】
Ａ−ｉｉ）本発明チップ搭載サービスクライアント（ＳＣｓ）
本発明チップ搭載コンテンツホールダに格納された価値情報に本発明チップ ＡＰＩを介してする計算実体。例えば、以下のようなタイプがある。
【００６２】
本発明チップ：
本発明チップ自体も高度なものはクライアントとしての機能ももつ。
【００６３】
発行サーバ：
価値情報を発行し本発明チップ搭載コンテンツホールダに格納する。
【００６４】
サービス現場システム：
本発明チップに格納された価値情報を用いたアプリケーションシステム。電子チケットのゲートなどが含まれる。
【００６５】
※本発明チップ搭載サービスクライアント且つ本発明チップボックスである計算実体も存在することに注意。
【００６６】
（Ｂ）暗号／認証ネットワーク系（ＡＥＮＩ：Ａｕｔｈｅｎｔｉｃａｔｉｏｎ／Ｅｎｃｒｙｐｔｉｏｎ Ｎｅｔｗｏｒｋ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）
本発明チップが公開鍵暗号系の認証及び暗号を実装した場合の、認証系。認証局が主な役割となる
（Ｃ）アプリケーションネットワーク系（ＡＮＩ：Ａｐｐｌｉｃａｔｉｏｎ Ｎｅｔｗｏｒｋ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）
アプリケーションに依存した各種通信系。例えば、電子チケットであれば、チケットの検索や購入を指示するネットワークプロトコルなどが含まれる。この購入の指示までがＡＮＩの枠組みで行われ、その後、価値情報であるチケット本体の移動は、本発明チップの機能を使ったＥＮＩで行われる。
【００６７】
２．２本発明チップ識別子（本発明チップＩＤ）
本発明チップ搭載コンテンツホールダとサービスクライアントは、ユニークな識別子をもち、それぞれ本発明チップ識別子（本発明チップＩＤ）と呼ぶ。本発明チップ識別子は、ネットワーク上で、本発明チップコンテンツホールダやサービスクライアントの認証、メッセージの経路制御などに用いられる。本発明チップＩＤは、１６オクテット（１２８ビット）数で表現される。
【００６８】
※本発明チップＩＤは、ＥＮＩでの通信プロトコルで用いられる識別子の交換フォーマットであり、その本発明チップ内での内部保存形式を定めるものではない。
【００６９】
※経路制御の実装の容易性を考慮すると、ＥＮＩのネットワーク層のプロトコルにおける識別子を直接本発明チップＩＤとする実装方法も考えられる。たとえば、ネットワークアドレスの下位ビットがそのまま本発明チップＩＤであるなど。
【００７０】
※所有者の本発明チップＩＤは、「０ｘ００〜００」（ａｌｌ”０”）とする。
【００７１】
例えば、Ｘという本発明チップＩＤをもった本発明チップ搭載サービスクライアントが所有者認証モードで認証されてセッションをはり、そのセッションの中でファイルを作ったとき、そのファイルの発行者ＩＤ欄は「０」が格納されるものとする。
【００７２】
※管理運用のスーパーユーザの本発明チップＩＤは「０ｘｆｆ〜ｆｆ」（ａｌｌ”１”）とする。
【００７３】
３．本発明チップ概要
３．１本発明チップ
本発明チップは、価値情報を用いた各種会社サービスを直接享受する利用者が価値情報を携帯するために用いる小型計算実体であり、本仕様書が主に扱う対象である。通常、ＩＣカード、スマートカード、携帯型端末といったハードウェア上に実装されることが多いと考えられている。これらのハードウェアには、備えている情報処理能力や資源の差が大きいこと、耐タンパーチップ技術が発展段階であることを考慮し、本発明チップの仕様は、様々なハードウェアに応じた、多様な仕様を提供し、インタフェースのみを共通化し、シリーズ化を図る。
【００７４】
【表１】
表：本発明チップ仕様のシリーズ
３．２データ構造モデル
本発明チップボックスや本発明チップに格納される価値情報は、次の階層的なデータ構造として外部から見えるものとする。
【００７５】
●フォールダ
複数のファイルのセットをまとめる構造。
【００７６】
本発明チップ／１６にルートフォルダだけが存在する。
【００７７】
●ファイル
価値情報を格納する資源。ファイルの中にはレコードが格納されるが、本発明チップ／１６では、一つのファイルに単一のレコードだけが格納される構造をとる。
【００７８】
３．３本発明チップ ＡＰＩ
本発明チップは、本発明チップ搭載サービスクライアントから、本発明チップＡＰＩによって動作する。
【００７９】
本発明チップ ＡＰＩは、基本的に、以下の手順によるセッションベースのプロトコルである。
【００８０】
−本発明チップと本発明チップ搭載サービスクライアントの相互認証と暗号通信路の確立
→セッション（トランザクション）の確立
−命令メッセージの送付
−セッション（トランザクション）の切断
※セッション／トランザクション方式はメッセージ交換回数が多くなるため、＆ゴーのような高応答性が求められる応用に適さないことがある。そこで、命令メッセージ毎に認証や暗号を適用する。非セッションプロトコルも一部の命令に関して取り入れる。
【００８１】
※ ｓｅｓｓｉｏｎ ＩＤ＝０で発行した命令は、非セッションモードとして扱われる。
【００８２】
■セッション命令
ｅｏｐｎ ｓｅｓ Ｏｐｅｎ Ｓｅｓｓｉｏｎ
ｅｃｆｍ ｓｅｓ Ｃｏｎｆｉｒｍ Ｓｅｓｓｉｏｎ
ｅｃｌｓ ｓｅｓ Ｃｌｏｓｅ Ｓｅｓｓｉｏｎ
■トランザクション命令
ｅｏｐｎ ｔｒａ Ｏｐｅｎ Ｔｒａｎｓａｃｔｉｏｎ
ｅｃｆｍ ｔｒａ Ｃｏｎｆｉｒｍ Ｔｒａｎｓａｃｔｉｏｎ
ｅｃｏｍ ｔｒａ Ｃｏｍｍｉｔ Ｔｒａｎｓａｃｔｉｏｎ
ｅａｂｏ ｔｒａ Ａｂｏｒｔ Ｔｒａｎｓａｃｔｉｏｎ
■ファイル操作命令
ｅｃｒｅ ｆｉｌ Ｃｒｅａｔｅ Ｆｉｌｅ
ｅｄｅｌ ｆｉｌ Ｄｅｌｅｔｅ Ｆｉｌｅ
ｅｔｒａ ｆｉｌ Ｔｒａｎｓｆｅｒ Ｆｉｌｅ
ｅｕｐｄ ｆｉｍ Ｕｐｄａｔｅ Ｆｉｌｅ Ｍｏｄｅ
ｅｅｎｃ ｆｉｌ Ｅｎｃｏｄｅ Ｆｉｌｅ
ｅｄｅｃ ｆｉｌ Ｄｅｃｏｄｅ Ｆｉｌｅ
■レコード操作命令
ｅｕｐｄ ｒｅｃ Ｕｐｄａｔｅ Ｒｅｃｏｒｄ
ｅｒｅａ ｒｅｃ Ｒｅａｄ Ｒｅｃｏｒｄ
■鍵実体操作命令
ｅｃｒｅ ｋｅｙ Ｃｒｅａｔｅ Ｋｅｙ
ｅｄｅｌ ｋｅｙ Ｄｅｌｅｔｅ Ｋｅｙ
ｅｕｐｄ ｋｅｙ Ｕｐｄａｔｅ Ｋｅｙ
■認証補助命令
ｅｃｆｍ ｃｅｒ Ｃｏｎｆｉｒｍ Ｃｅｒｔｉｆｉｃａｔｅ
■制御命令
ｅｐｏｌ ｃｈｐ Ｐｏｌｌｉｎｇ Ｃｈｉｐ
ｅｉｎｉ ｃａｒ Ｉｎｉｔｉａｌｉｚｅ Ｃａｒｄ
ｅｕｐｄ ｃｅｒ Ｕｐｄａｔｅ Ｍｙ Ｃｅｒｔｉｆｉｃａｔｅ
ｅｕｐｄ ｃｐｋ Ｕｐｄａｔｅ ＣＡ Ｐｕｂｌｉｃ Ｋｅｙ
３．４認証・アクセス制御・暗号
セッションを構築するときに、本発明チップと本発明チップ搭載サービスクライアントが相互認証を行う。この認証の具体的アルゴリズムは、チップに搭載されているハードウェア等に特化して、多様なものが使えるものとする。
【００８３】
●認証モード
認証には（情報）発行者モードと所有者モードのモードがあり、認証時に指定され、各モードによって認証アルゴリズムが（一般的には）異なる。
【００８４】
（情報）発行者モード：
本発明チップ搭載サービスクライアントをファイルの発行者として認証するモード。発行者のモードで認証された後は、その本発明チップサービスクライアントが作成したファイルには、発行者権限でアクセスでき、それ以外の資源には、その他権限でアクセスすることができる。
【００８５】
所有者のモード：
本発明チップ搭載サービスクライアントをチップの所有者として認証するモード。通常、パスワード等、人間にとって扱いやすい認証方法が使われる。所有者モードで認証された本発明チップ搭載サービスクライアントは所有者権限を持つ。
【００８６】
●相互認証後の本発明チップの状態
認証が終了すると、本発明チップは、以下の情報を保持することになる。
【００８７】
−正規に認証された本発明チップ搭載サービスクライアントの本発明チップＩＤ −本発明チップ搭載サービスクライアントへ送るメッセージの暗号共通鍵
−本発明チップ搭載サービスクライアントから来たメッセージの復号共通鍵
−セッションＩＤ
−セッションモード（発行者モード／所有者モード）
●アクセス制御
チップ、ファイル（、レコード）には、
−発行者を表す本発明チップＩＤ
−アクセス制御リスト（権限毎に許可されている操作）
がつけられており、以下で定めるセッションがもつ権限に応じて、アクセスが制限される。
【００８８】
●ファイルアクセスモード
本発明チップＩＤ＝ｅｉｄのＳＣが、本発明チップ内のファイルＦ（Ｆを作成した本発明チップＳＣの本発明チップＩＤ＝Ｆ．ｅｉｄ）をアクセスするモードには、以下の３種類がある。
【００８９】
１．所有者アクセス
所有者認証を通過してセッション中でのアクセス。
【００９０】
※この場合、ｅｉｄ＝０ｘ００（ａｌｌ”０）である。
【００９１】
２．（情報）発行者アクセス
（情報）発行者認証を通過したセッション中から、
ｅｉｄ＝＝Ｆ．ｅｉｄの場合のアクセス。
【００９２】
３．その他のアクセス
（情報）作成者認証を通過したセッション中で、
ｅｉｄ ！＝Ｆ．ｅｉｄの場合のアクセス、
もしくは、
非セッションモードによるアクセス。
【００９３】
●ルートフォルダへのアクセス制御リスト
【表２】
ＡＣＬ０ ＝０／１ ｅｃｒｅ ｆｉｌ所有者アクセス不可／可
※所有者アクセスで、ルートフォルダーにファイルを作ることを許可するか
ＡＣＬ１ ＝０／１ ｅｃｒｅ ｆｉｌその他アクセス不可／可
※所有者アクセス以外で、ルートフォルダーにファイルを作ることを許可するかどうか
ＡＣＬ２ ＝０／１ ｅｄｅｌ ｆｉｌ所有者アクセス不可／可
※所有者アクセスで、ルートフォルダーからファイルを消すことを許可するか
ＡＣＬ３ ＝０／１ ｅｄｅｌ ｆｉｌその他アクセス不可／可
※所有者アクセス以外で、ルートフォルダからファイルを消すことを許可するかどうか
ＡＣＬ４ ＝０／１ ｅｔｒａ ｆｉｌ所有者アクセス不可／可
※所有者アクセスで、ルートフォルダーからファイルを転送することを許可するかどうか
ＡＣＬ５ ＝０／１ ｅｔｒａ ｆｉｌその他アクセス不可／可
※所有者アクセス以外で、ルートフォルダからファイルを転送することを許可するかどうか
【表３】
※ルートフォルダの（情報）発行者は所有者として運用する。
【００９４】
※つまり、価値情報をルートフォルダにファイル／鍵実体を作成する一般の価値情報サーバは、ルートフォルダによっては、「その他アクセス」に相当する
●ファイルへのアクセス制御リスト
【表４】
ＡＣＬ０ ＝０／１ ｅｕｐｄ ｒｅｃ所有者アクセス不可／可
ＡＣＬ１ ＝０／１ ｅｕｐｄ ｒｅｃその他アクセス不可／可
ＡＣＬ２ ＝０／１ ｅｒｅａ ｒｅｃ所有者アクセス不可／可
ＡＣＬ３ ＝０／１ ｅｒｅａ ｒｅｃその他アクセス不可／可
ＡＣＬ４ ＝０／１ ｅｕｐｄ ｆｉｍ所有者アクセス不可／可
ＡＣＬ５ ＝０／１ ｅｕｐｄ ｆｉｍその他アクセス不可／可
ＡＣＬ６ ＝０／１ ｅｌｓｔ ｆｉｌ所有者アクセス不可／可
ＡＣＬ７ ＝０／１ ｅｌｓｔ ｆｉｌその他アクセス不可／可
ＡＣＬ８ ＝０／１ ｅｄｅｌ ｆｉｌ所有者アクセス不可／可
ＡＣＬ９ ＝０／１ ｅｄｅｌ ｆｉｌその他アクセス不可／可
ＡＣＬａ ＝０／１ ｅｔｒａ ｆｉｌ所有者アクセス不可／可
ＡＣＬｂ ＝０／１ ｅｔｒａ ｆｉｌその他アクセス不可／可
ＡＣＬｃ ＝０／１ ｅｅｎｃ ｆｉｌ所有者アクセス不可／可
ＡＣＬｄ ＝０／１ ｅｅｎｃ ｆｉｌその他アクセス不可／可
ＡＣＬｅ ＝０／１ ｅｄｅｃ ｆｉｌ所有者アクセス不可／可
ＡＣＬｆ ＝０／１ ｅｄｅｃ ｆｉｌその他アクセス不可／可
【表５】
●鍵実体のアクセス制御リスト
【表６】
ＡＣＬ０ ＝０／１ ｅｕｐｄ ｋｅｙ所有者アクセス不可／可
ＡＣＬ１ ＝０／１ ｅｕｐｄ ｋｅｙその他アクセス不可／可
ＡＣＬ２ ＝０／１ ｅｒｅａ ｋｅｙ所有者アクセス不可／可
ＡＣＬ３ ＝０／１ ｅｒｅａ ｋｅｙその他アクセス不可／可
ＡＣＬ４ ＝０／１ ｅｕｐｄ ｋｙｍ所有者アクセス不可／可
ＡＣＬ５ ＝０／１ ｅｕｐｄ ｆｉｍその他アクセス不可／可
ＡＣＬ８ ＝０／１ ｅｄｅｌ ｋｅｙ所有者アクセス不可／可
ＡＣＬ９ ＝０／１ ｅｄｅｌ ｋｅｙその他アクセス不可／可
ＡＣＬｃ ＝０／１ ｅｅｎｃ ｆｉｌ所有者アクセス不可／可
ＡＣＬｄ ＝０／１ ｅｅｎｃ ｆｉｌその他アクセス不可／可
ＡＣＬｅ ＝０／１ ｅｄｅｃ ｆｉｌ所有者アクセス不可／可
ＡＣＬｆ ＝０／１ ｅｄｅｃ ｆｉｌその他アクセス不可／可
【表７】
４．本発明チップ ＡＰＩプロトコル
４．１パケット形式
※パケット形式右に、「□」は暗号セッション時に、非暗号化部分、
「■」は暗号化する部分、
※オクテット以上の数値データは、Ｌｉｔｔｌｅ Ｅｎｄｉａｎで格納する。
【００９５】
ルーティング・ヘッダ
【表８】
本発明チップセッション部（往）
【表９】
本発明チップセッション部（復）
【表１０】
ＭＡＣ・トレーラ
【表１１】
※ ＭＡＣは、暗号化された後のデータに対してつけられる。
【００９６】
４．２命令識別子（コマンドＩＤ）一覧
本発明チップ ＡＰＩの命令識別子（コマンドＩＤ）は正の１バイト整数で表現される。
【００９７】
本発明チップ／８，１６，３２のシリーズで共通に定められており、以下の通りである。
【００９８】
【表１２】
表：本発明チップ ＡＰＩの命令識別子一覧
※本発明チップ／１６第一バージョンでは実装せず。
【００９９】
４．３エラーコード一覧
本発明チップにおける命令のエラーコードは、符号付き整数で表される。操作が正常に終了したときは、Ｅ＿ＯＫ＝０または、操作の結果を表す正の数が返される。正常に終了せず、何かのエラーがあった場合には、負の数を返す。エラーコードは以下のコンベンションで表現される。
【０１００】
・”Ｅ＿”と書かれたものは、チップ中のローカルな命令処理時に起きる一般的なエラーを表す（関連チップのエラーコードと共通）。
【０１０１】
・”ＥＮ＿”と書かれたものは、通信関連の一般的なエラーを表す（セッションエラー以外は、関連チップのエラーコードと共通）。
【０１０２】
・”ＥＥ＿”と書かれたものは、主に、セキュリティー関連の一般的なエラーを表す（本発明チップ専用）。
【０１０３】
【表１３】
表：本発明チップ ＡＰＩのエラーコード一覧
４．４ ＭＡＣ・トレーラ
【表１４】
１チェックサム
【表１５】
２ＣＲＣ−ＣＣＩＴＴ
ＣＲＣ−ＣＣＩＴＴにおける生成多項式
Ｇ（Ｘ）＝Ｘ＾１６＋Ｘ＾１２＋Ｘ＾５＋１
※パケットサイズが奇数の場合、後ろのバイトをｎｕｌｌ ｐａｄｄｉｎｇしてからＣＲＣをとる。
【０１０４】
【表１６】
５ ＨＭＡＣ ｗｉｔｈ ＭＤ５ ［ＲＦＣ ２０８５］
セッション／トランザクション暗号通信路で用いる
暗号通信路の秘密鍵暗号の鍵の始めの６４バイトを鍵Ｋとして用いる、
ＨＭＡＣは以下の式で計算する。
【０１０５】
※セッション確立後、暗号通信を行なっている場合、６４バイトの秘密鍵として、１６バイト暗号鍵を４回繰り返したもの、つまり、ｅｏｐｎ ｓｅｓ（）のＲＳＡ認証による場合、交換された乱数を以下のようにアペンドしてを用いる。
【０１０６】
Ｋ＝Ｒａ｜Ｒｂ｜Ｒａ｜Ｒｂ｜Ｒａ｜Ｒｂ｜Ｒａ｜Ｒｂ
【表１７】
４．５セッション通信と非セッション型通信
本発明チップとの通信では、「相互認証」後に「暗号」通信路としてのセッション／トランザクションが確立し、以後「暗号」化されたメッセージ通信を行う。ｅｒｅａ ｒｅｃ命令（レコードの内容を読む）に関しては、「認証」のフェーズを経ずに、直接実行する非セッション型通信をサポートする。この時、セッションを張らずに命令をｓｅｓｓｉｏｎ ＩＤ＝０で呼び出すことで起動できる。この非セッション型通信によるアクセスは、そのファイルが「その他アクセス」を許可していれば成功する。この時、アクセスパケットは暗号化されない。これは、チケットのゲーティングなどの、タッチ＆ゴー応用の必要性が高い場所で用いられる。
【０１０７】
※サービス提供者は、このモードを使うことにより、リスクは高くなる。以下の音源チップを搭載しています。
【０１０８】
５．ｅＴＰ鍵証明書
セッション構築時における認証時の証明書の利用
１．概要
本発明チップ／１６ではセッションを構築する時に相互認証は、公開鍵ベースかつ、ＰＫＩの存在を前提とする。
【０１０９】
−本発明チップ搭載ＣＨｓ、本発明チップ搭載ＳＣｓには、それぞれ本発明チップＩＤが割り振られ、発行時に、認証用の公開鍵／秘密鍵の対が割り当てられている。
【０１１０】
−セッション・トランザクション構築時に、正規に発行された（本発明チップＩＤ、公開鍵）対を持っていることを相互に示すことができるように、常に本発明チップ搭載ＣＨ、本発明チップ搭載ＳＣ内部に本発明チップ搭載ＣＡの署名付の証明書を格納している。
【０１１１】
※本発明チップ搭載ＣＡは、将来的には複数あることが想定されるが、本バージョンでは一つに制限する。
【０１１２】
−証明書は、本発明チップＩＤ、公開鍵のペア、（ｉｄ，ＰＫ ｉｄ）が正規に発行されたものであることを、本発明チップ搭載ＣＡの署名（Ｓ ｃａ（ｉｄ，ＰＫ ｉｄ））が証明する。
【０１１３】
２．詳細
本発明チップ搭載ノード（ここで、本発明チップ搭載ＳＣと本発明チップ搭載ＣＨ両方を総称してそう呼ぶ）は、認証段階の前段階として、相手のデバイスとの間で、相互に自らの本発明チップの公開鍵を本発明チップデバイス発行者の署名つき証明書として送付する※注１）。
【０１１４】
本発明チップ搭載ノードは、証明書発行者の署名鍵の公開鍵を証明書形式で所有する。この鍵を使って正当性を確認する。
【０１１５】
「相手ノードから送られてきた公開鍵の正当性」
＝「発行者の正規な署名があること」＋「証明書が有効期間内であること」
を検証する※注２）。
【０１１６】
正当であることが確認できない場合にはセッションを確立せずに、通信を打ち切る※注３）。
【０１１７】
※注１）
公開鍵ベースの認証において、その後のセッションで、高価な価値の転送／交換の場合には、証明書が「廃止・破棄」されている場合も考慮する。本発明チップ／１６では、
１． ＣＲＬ（破棄リスト）を使う（ただしデータが大きくなる）
または
２．特定の証明書が「廃止・破棄」されているかを照会するサーバーアクセスの利用を行なう。
【０１１８】
※注２）
注１で述べた用に、これに加えて証明書の「廃止・破棄」の問い合わせを行なうこともできる。
【０１１９】
※注３）
証明書の正当性の確認が終了する前に、とりあえず認証のステップを開始して、相手に認証に必要なパケットを送信している間、あるいは相手からの認証に必要なパケットを待っている間に別タスクによっての正当性を確認する実装が有効である。チップ内で割り込みやマルチタスクＯＳが実現されている必要があるが、認証全体の処理時間を短く実装するために有効な手段である。
【０１２０】
上の説明は、本発明チップやカードのようなノードの通信の初期の設定にかかる時間の減らす工夫である。サーバーマシン上に実装されたノードは、不正な証明書をもつ装置から不正は証明書の送付によるサーバ問い合わせ処理の浪費というＤｏＳを防ぐため、必ず最初に証明書の署名確認をオフラインで済ませてから「廃止・破棄」を確認した方が良い。
【０１２１】
ｅＴＰ鍵証明書のフォーマット（ｖｅｒ．０．１）
【表１８】
・ｖｅｒ：
証明書形式のバージョン番号。ｖｅｒ．０．１ではｖｅｒ＝”１”とする。
【０１２２】
・証明書番号：
その本発明チップＩＤに対する鍵の証明書シリアル番号。
【０１２３】
・署名法：
署名アルゴリズム指定子
０：証明書のｋｅｙフィールド部分までをＳＨＡ−１ハッシュし、結果をＲＳＡ暗号化（実装）
１：予約
２：予約
３：予約
・発行者ＩＤ：
証明書の発行者（ＣＡ局）ＩＤ。ｖｅｒ．０．１では”０”に固定。
【０１２４】
・有効期間開始、有効期限終了：
証明書の有効期間。
【０１２５】
符号なし４オクテット整数（２０００年１月１日ＡＭ０：００からの秒数の積算）
・ＣＡＫＥＹ＃：
ＣＡが鍵の署名に複数の鍵を使っている場合に、それを区別するための鍵のＩＤ番号。ｖｅｒ．０．１では”０”に固定。
【０１２６】
・キー長さ：
後ろのつく鍵のビット長サイズ
※証明書中で、鍵が８オクテットの倍数にならない場合、それを格納するｋｅｙフィールドの最後に”０”を付加し（ｎｕｌｌ ｐａｄｄｉｎｇ）８オクテットの倍数データとして格納する。ｋｅｙフィールドの中の「キー長さ」ビットが有効な鍵である。
【０１２７】
・署名長：
最後につく署名に使うハッシュ（ｓｈａ−１など）のビット長
※ハッシュは、必要であれば最後にｎｕｌｌ ｐａｄｄｉｎｇして８オクテットの倍数のデータとしてから、ＣＡの鍵で暗号化して署名を作成する。
【０１２８】
署名を確認する時には、最後につくこの８オクテットの整数倍のデータを、本発明チップ搭載ノードが保存するＣＡサーバーの公開鍵で復号する。その復号値の中で、先頭の署名長ビットが確認に用いるハッシュ値となる。
【０１２９】
・具体的な長さの例：（ＲＳＡ／ｓｈａ−１署名を使った場合）
−ＲＳＡ
本発明チップ認証公開鍵はＲＳＡで１０２４ビットとする。
【０１３０】
１０２４ｂｉｔｓ＝１２８ｂｙｔｅｓ＝１６×８ｂｙｔｅｓである。
【０１３１】
ｓｈａ−１を署名のためのハッシュ関数として使う。
【０１３２】
− ｓｈａ−１
ｓｈａ−１の出力は１６０ｂｉｔｓ．
１６０ｂｉｔｓ＝２０ｂｙｔｅｓ．
このバイト長をｎｕｌｌ ｐａｄｄｉｎｇして８の倍数にして２４バイトデータをＲＳＡ暗号で署名する。
【０１３３】
証明書全体の長さは以下のように計算できる。
【０１３４】
証明書の長さは
・固定長部分（４０バイト）
鍵の部分の部分の長さ
・署名部分（１２８バイト）
の和（１６８バイト）になる。
【０１３５】
署名の部分は暗号結果は１０２４ビットを必要とするので、１２８バイトの長さを使う。
【０１３６】
ただし、鍵の部分は単純に１２８バイトとはならないので注意されたい。
【０１３７】
これはＲＳＡ鍵の場合、公開鍵として１０２４ビットと俗称している場合には１０２４ｂｉｔｓのＮと指数ｅ（ｅ，Ｎ）の対を念頭においており、鍵の部分には（ｅ，Ｎ）両方を入れる必要があるためである。
【０１３８】
ＲＳＡの場合、鍵フィールドには以下のようにｅ，Ｎを入れることにする。
【０１３９】
ｅのバイト長：（１バイト）
ｅの値そのもの：必要に応じてバイト単位まで広げてバイト列として埋める。これに続けてＮの値をバイト列として埋める。
【０１４０】
（ｅ，Ｎ）でｅ＝３の場合を例として考えてみると、鍵のフィールドには以下のように１３０バイトのバイトデータが入る。
【０１４１】
公開鍵＝０ｘ０１｜０ｘ０３｜Ｎのバイト列（１２８バイト）
１３０は、８の倍数でないので、１３６バイトまでパディングされて鍵データの占めるバイトは１３６となる。
【０１４２】
これで全体長が計算できる。
【０１４３】
固定長部分 （ ４０バイト）
＋鍵の部分の占める長さ（１３６バイト）
＋署名部分 （１２８バイト）
＝３０４バイト
このようにｅ＝３の場合には、長さは総計で３０４バイトとなる。
【０１４４】
６．鍵実体
鍵実体は、本発明チップが通常のファイルに格納する、暗号鍵及び暗号鍵を使った価値情報操作に必要な情報をまとめたシステムデータ形式である。
【０１４５】
【表１９】
暗号方式指定子：
ＫＥＹ（１）、ＫＥＹ（２）が、どの暗号アルゴリズムの鍵であるかを指定する。以下の通り、ｅｏｐｎ ｓｅｓにおける暗号通信路の暗号アルゴリズム指定と同じ方式で指定する。
【０１４６】
【表２０】
７．本発明標準コンテンツ形式
標準コンテンツ形式は、本発明チップ内で価値情報操作を行なうことができる。標準コンテンツデータ形式である。鍵実体を操作することによって、暗号／復号操作を加え、その際に鍵実体の内部の課金情報をアトミックに変更することができる。
【０１４７】
基本的に、暗号化されたコンテンツを復号化する時に課金するという販売モデムを本発明チップの内部で確実に行なうことを想定している。
【０１４８】
■コンテンツ形式全体
【表２１】
（Ａ）コンテンツヘッダ
【表２２】
（Ｂ）課金ヘッダ
【表２３】
（Ｃ）暗号化コンテンツ
【表２４】
※暗号化ＫＥＹ（１），（２）は、そのコンテンツの解読に必要な鍵実体に格納されている鍵を使って暗号化されている。本発明チップ／１６ではファイル容量の問題から、鍵実体の暗号として、共通鍵暗号だけを考え、公開鍵暗号は扱わないものとする。（ここの暗号化キーのデータ長が暗号後に、伸長してしまうため）
（Ｄ）署名トレーラ
【表２５】
※署名の方式は、ｅＴＰパケットの署名トレーラと同じ形式とする。
【０１４９】
ＨＭＡＣ ｗｉｔｈ ＭＤ５［ＲＦＣ ２０８５］の場合の６４バイトの秘密鍵として、本コンテンツに含まれている暗号化ＫＥＹ（１）と暗号化ＫＥＹ（２）を、鍵実身の鍵で復号したＫ１、Ｋ２を使い、Ｋを以下の方法で生成する。
【０１５０】
Ｋ＝Ｋ１｜Ｋ２｜Ｋ１｜Ｋ２｜Ｋ１｜Ｋ２｜Ｋ１｜Ｋ２
■課金ヘッダ
【表２６】
■暗号化コンテンツ
【表２７】
■署名トレーラ
本発明チップのパケットと同様の仕様
８．鍵実体による本発明標準コンテンツ操作時の決算処理
鍵実体を使った計算方法は、以下の方式をとる。
【０１５１】
（１）本発明暗号化コンテンツの課金ヘッダの課金額（本発明チップ／１６では、固定額のみ）を算出
（２）鍵実体のＭＯＮＥＹフィールドから、決算額の減算処理を行なう。
【０１５２】
９．本発明チップ ＡＰＩ仕様（データ型定義）
Ｂ 符号付き１バイト整数
ＵＢ 符号なし１バイト整数
Ｈ 符号付き２バイト整数
ＵＨ 符号なし２バイト整数
本発明チップＩＤ １６バイト整数
ＳＩＤ 符号なし１バイト整数（Ｓｅｓｓｉｏｎ Ｉｄ）
ＦＩＤ 符号なし２バイト整数（Ｆｉｌｅ／Ｆｏｌｄｅｒ Ｉｄ）
ＲＩＤ 符号なし２バイト整数（Ｒｅｃｏｒｄ Ｉｄ）
ＣＡＣＬ 符号なし２バイト整数（Ｃｈｉｐ Ａｃｃｅｓｓ Ｃｏｎｔｏｒｌ Ｌｉｓｔ）
ＦＡＣＬ 符号なし２バイト整数（Ｆｉｌｅ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｌｉｓｔ）
ＫＥＹＡＣＬ 符号なし２バイト整数（Ｋｅｙ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｌｉｓｔ）
ＴＩＭＥ 符号なし４バイト整数（２０００年１月１日ＡＭ０：００からの秒数の積算）
ＥＲＲ 符号つき２バイト整数
●Ｃ言語表現による定義例
１０．本発明チップ ＡＰＩ仕様（命令定義）
１０．１セッション管理命令群
セッション構築
Ｏｐｅｎ／Ｃｏｎｆｉｒｍ Ｓｅｓｓｉｏｎ
［機能概要］
本発明チップに対して安全なセッション通信路を構築する。１パスで済む認証を用いる場合は、ｅｏｐｎ ｓｅｓを、２パス必要な認証を用いる場合はｅｏｐｎ ｓｅｓとｅｃｎｆ ｓｅｓをこの順序で用いる。
【０１５３】
このセッション構築によって、Ｃａｌｌｅｒである本発明チップ搭載サービスクライアント側と、Ｃａｌｌｅｅ側である本発明チップ側とでセッション中のみ有効な一時的な共通暗号鍵が共有される。
【０１５４】
認証の方式、暗号の種類は、パケット内のパラメータよって選択可能。本発明チップ側で利用できない認証／暗号が指定された場合はエラーとなる。
【０１５５】
［関数表記］
ｓｒｃＩｄ 本命令を呼び出す本発明チップ搭載サービスクライアントの本発明チップ
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ａｕｔｈＭｏｄｅ 認証モードを指定
ａｕｔｈＡｌｇｏｒｉｔｈｍ 認証に使うアルゴリズムの指定子
ｓｅｓｓｉｏｎＡｌｇｏｒｉｔｈｍ 認証後のセッションにおける暗号アルゴリズムの指定子
ｌｅｎ 行きのパケット長（オクテット数）
ａｕｔｈＤａｔａ 認証用に本発明チップ搭載サービスクライアントから本発明チップに渡すデータ（ｌｅｎ−１６）
ｒｌｅｎ 戻りパケット長（オクテット長）
ｒＡｕｔｈＤａｔａ 認証用に本発明チップから本発明チップ搭載サービスクライアントに戻されたデータ（ｒｌｅｎ−８）
［パラメーター値］
□ａｕｔｈＭｏｄｅ
０ｘ０１ ＩＳＳＵＥＲ 発行者モード
０ｘ０２ ＯＷＮＥＲ 所有者モード
□ａｕｔｈＡｌｇｏｒｉｔｈｍ
０ｘ０１ 予約
０ｘ０２ ＲＳＡ（証明書を使ったオフライン認証）
０ｘ０３ ＲＳＡ（ＣＲＬを確認するオンライン認証）
０ｘ０４ 予約
□ｓｅｓｓｉｏｎＡｌｇｏｒｉｔｈｍ
０ｘ０１ ＤＥＳ
０ｘ０２ ３ＤＥＳ
０ｘ０３ 予約
０ｘ０４ 予約
０ｘ０５ 予約
［返り値］
１パス認証の場合
＞ ０ セッションＩＤ（正常終了時）
＜ ０ エラーコード
２パス認証の場合
＜＝ ０ エラーコード
［送りパケット形式］
【表２８】
【表２９】
［戻りパケット形式］
【表３０】
【表３１】
［関数表記］
ｓｒｃＩｄ 本命令を呼び出す本発明チップ搭載サービスクライアントの本発明チップＩＤ
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｌｅｎ 行きのパケット長（オクテット数）
ａｕｔｈＤａｔａ 認証用に本発明チップ搭載サービスクライアントから本発明チップに渡すデータ（ｌｅｎ−１２）
ｒｌｅｎ 戻りパケット長（オクテット数）
ｒＡｕｔｈＤａｔａ 認証用に本発明チップから本発明チップ搭載サービスクライアントに戻されたデータ（ｒｌｅｎ−８）
［返り値］
＞ ０ セッションＩＤ（正常終了時）
＜ ０ ラーコード
［送りパケット形式］
【表３２】
【表３３】
［戻りパケット形式］
【表３４】
【表３５】
［機能詳細］
ｏｐｅｎ／ｃｏｎｆｉｒｍ ｓｅｓｓｉｏｎ命令は、本発明チップ搭載サービスクライアントと本発明チップが相互認証した上で安全な暗号通信路としてのセッションを確立する。具体的な動作は、認証・暗号方式に依存し、その方式は多くの場合本発明Ｎチップハードウェアの暗号支援機能に依存する（実装依存）。セッション確立プロトコルは、発行者モードによる認証と、所有者モードによる認証があり、ｏｐｅｎ ｓｅｓｓｉｏｎ命令のａｕｔｈｍｏｄｅパラメータによって区別される。
【０１５６】
■公開鍵暗号による発行者モード（ａｕｔｈｍｏｄｅ＝ＩＳＳＵＥＲ）認証
【表３６】
（１）ｅｏｐｎ ｓｅｓ（Ａ→Ｂ）
《パラメータ例》
・ａｕｔｈＭｏｄｅ ０ｘ０２ （ＩＳＳＵＥＲ）
・ａｕｔｈＡｌｇｏｒｉｔｈｍ ０ｘ０３ （ＲＳＡ：ＣＲＬを確認するオンライン認証）
・ｓｅｓｓｉｏｎＡｌｇｏｒｉｔｈｍ ０ｘ０２ （３ＤＥＳ）
・ａｕｔｈＤａｔａ ＡのｅＴＰ公開鍵証明書
・ＭＡＣトレーラ チェックサム
《Ｂの動作》
・ＡのｅＴＰ証明書の正当性の確認
− ｅＴＰ証明書の期限確認
− ＣＡ局の公開鍵でｅＴＰ証明書の署名を確認→（２）へ
− ＣＲＬリストを確認
・Ａの公開鍵を取り出す
（２）ｅｃｆｍ ｃｅｒ（Ｂ→ＣＲＬ Ｒｅｐ．Ｓｅｒｖｅｒ）
《パラメータ例》
・ｃｈｅｃｋＭｏｄｅ ０ｘ００
・ｃｅｒｔｉｆｉｃａｔｅＩｄ ＊＊＊＊＊＊＊＊＊＊＊
・ＭＡＣトレーラ チェックサム
（３）ｅｃｆｍ ｃｅｒ（Ｂ←ＣＲＬ Ｒｅｐ．Ｓｅｒｖｅｒ）
《パラメータ例》
・Ｅｒｒｏｒ Ｃｏｄｅ Ｅ＿ＯＫ ｏｒ ｎｏｔ
・ＭＡＣトレーラ チェックサム
（４）ｅｏｐｎ ｓｅｓ（Ａ←Ｂ）
《パラメータ例》
・Ｅｒｒｏｒ Ｃｏｄｅ Ｅ＿ＯＫ ｏｒ ｎｏｔ
・ａｕｔｈＭｏｄｅ ０ｘ０２（ＩＳＳＵＥＲ）
・ａｕｔｈＡｌｇｏｒｉｔｈｍ ０ｘ０３（ＲＳＡ：ＣＲＬを確認するオンライン認証）
・ｓｅｓｓｉｏｎＡｌｇｏｒｉｔｈｍ ０ｘ０２（３ＤＥＳ）
・ａｕｔｈＤａｔａ １．ＢのｔＴＰ公開鍵証明書
２．６４ビットの乱数ＲｂをＡの公開鍵でＲＳＡ暗号化したもの
・ＭＡＣトレーラ チェックサム
《Ａ側の動作》
・ＲのｅＴＰ証明書の正当性の確認
− ｅＴＰ証明書の期限確認
− ＣＲＬリストを確認→（５）へ
− ＣＡ局の公開鍵でｅＴＰ証明書の署名を確認
・証明書からＢの公開鍵を取り出す
・ａｕｔｈＤａｔａ２．で受信した乱数ＲｂをＡの秘密鍵で復号化して取り出す
・取り出した乱数Ｒｂはセッション暗号の３ＤＥＳの秘密鍵の一部にする。
【０１５７】
・取り出した乱数Ｒｂのデジタル署名をＡの秘密鍵で作成する。
【０１５８】
（５）ｅｃｆｍ ｃｅｒ（Ａ→ＣＲＬ Ｒｅｐ．Ｓｅｒｖｅｒ）
《パラメータ例》
・ｃｈｅｃｋＭｏｄｅ ０ｘ００
・ｃｅｒｔｉｆｉｃａｔｅＩｄ ＊＊＊＊＊＊＊＊＊＊＊
・ＭＡＣトレーラ チェックサム
（６）ｅｃｆｍ ｃｅｒ（Ａ←ＣＲＬ Ｒｅｐ．Ｓｅｒｖｅｒ）
《パラメータ例》
・Ｅｒｒｏｒ Ｃｏｄｅ Ｅ＿ＯＫ ｏｒ ｎｏｔ
・ＭＡＣトレーラ チェックサム
（７）ｅｃｆｍ ｓｅｓ（Ａ→Ｂ）
《パラメータ例》
・ａｕｔｈＤａｔａ １．６４ビットのＲａをＢの公開鍵でＲＳＡ暗号化したもの、
と、
２．Ｂから受け取った乱数の、Ａの秘密鍵によるデジタル署名を、Ｂの公開鍵でＲＳＡ暗号化したものを、アペンドして送る
・ＭＡＣトレーラ チェックサム
《Ｂ側の動作》
・ａｕｔｈＤａｔａで受信したデータをＡの公開鍵で復号化してＲａとデジタル署名を取り出す
・取り出したＲａはセッション暗号の３ＤＥＳの秘密鍵の一部にする。
【０１５９】
・取り出したＲａのデジタル署名をＢの秘密鍵で作成する。
【０１６０】
・取り出した署名をＡの公開鍵で確認する。
【０１６１】
（８）ｅｃｆｍ ｓｅｓ（Ｃａｌｌｅｒ←Ｃａｌｌｅｅ）
《パラメータ例》
・Ｅｒｒｏｒ Ｃｏｄｅ Ｅ＿ＯＫ ｏｒ ｎｏｔ
・ａｕｔｈＤａｔａ Ａから受け取った乱数Ｒａの、Ｂの秘密鍵によるデジタル署名
・ＭＡＣトレーラ チェックサム
《Ａ側の動作》
・受け取った署名をＢの公開鍵で確認する。
【０１６２】
■（補足）認証アルゴリズムの詳細
■アルゴリズム詳細
・暗号・認証の鍵
秘密鍵ｓｋ＝ｄ
公開鍵ｐｋ＝（ｅ，ｎ）
・平文ｍに対する暗号アルゴリズム
Ｅ ｐｋ（ｍ）＝ｍ＾ｅ ｍｏｄｎ
・暗号文ｃに対する復号アルゴリズム
Ｄ ｓｋ（Ｃ）＝ｃ＾ｄ ｍｏｄｎ
・メッセージＭに対する署名生成アルゴリズム
ｆ ｓｋ（Ｍ）＝（ｈ（Ｍ））＾ｄ ｍｏｄｎ
※但し、ここでｈ（Ｍ）はＭＤ５やＳＨＡ−１などのハッシュ関数
・メッセージＭに対する署名ｓの検証アルゴリズム
ｇ ｐｋ（Ｍ，ｓ）＝ｉｆ（ｈ（Ｍ）＝＝ｓ＾ｅ ｍｏｄｎ）ｔｈｅｎ １ ｅｌｓｅ ０ ｅｎｄｉｆ
■各ノードが所有する情報一覧
・ＣＡ局（Ｃ）
ＣＡの公開鍵 ｐｋ ｃ （１３０Ｂ）
ＣＡの秘密鍵 ｓｋ ｃ （１２８Ｂ）
・Ｃａｌｌｅｒ側（Ａ）
Ａの公開鍵 ｐｋ ａ （１３０Ｂ）
Ａの秘密鍵 ｓｋ ａ （１２８Ｂ）
Ａの証明書 ｃｅｒ ａ （３０４Ｂ）
Ａの証明書におけるＣＡ局の署名 ｓ （ａ，ｃ） （１２８Ｂ）
ＣＡ局の公開鍵 ｐｋ ｃ （１３０Ｂ）
相互認証中に発生する乱数 Ｒａ （８Ｂ）
・Ｃａｌｌｅｅ側（Ｂ）
Ｂの公開鍵 ｐｋ ｂ （１３０Ｂ）
Ｂの秘密鍵 ｓｋ ｂ （１２８Ｂ）
Ｂの証明書 ｃｅｒ ｂ （３０４Ｂ）
Ｂの証明書におけるＣＡ局の署名 ｓ （ｂ，ｃ） （１２８Ｂ）
ＣＡ局の公開鍵 ｐｋ ｃ （１３０Ｂ）
相互認証中に発生する乱数Ｒｂ （８Ｂ）
■ｅＴＰによるＲＳＡベースの認証アルゴリズム詳細
ｅｏｐｎ ｓｅｓ：（Ａ）→（Ｂ）
［送信情報］ （ｃｅｒ ａ）※計３０４バイト
［Ｂの動作］
証明書の期限確認
証明書の署名確認 ｇ （ｐｋ ｃ）（ｃｅｒ ａ，ｓ （ａ，ｃ））証明書のＣＲＬを確認
ｅｏｐｎ ｓｅｓ：（Ａ）←（Ｂ）
［送信情報］ （ｃｅｒ ｂ｜ｒｂ） ※計４３２バイト
Ｂで生成した乱数（Ｒｂ） ｒｂ＝Ｅ （ｐｋ ａ）（Ｒｂ）
［Ａの動作］
証明書の期限確認
証明書の署名確認 ｇ （ｐｋ ｃ）（ｃｅｒ ｂ，ｓ （ｂ，ｃ）） 証明書のＣＲＬを確認
メッセージ（ｒｂ）の復号 Ｒｂ’＝Ｄ （ｓｋ ａ）（ｒｂ）
受け取った乱数（Ｒｂ’）の署名作成 ｓｒｂ＝ｆ （ｓｋ ａ）（Ｒｂ’）
ｅｃｆｍ ｓｅｓ：（Ａ）→（Ｂ）
［送信情報］ （ｘ ａｌ｜ｘ ａ２） ※計２５６バイト
［Ｂの動作］
受け取った署名（ｓｒｂ）の検証 ｇ （ｐｋ ａ）（Ｒｂ，ｓｒｂ’） 受け取った乱数（Ｒａ’）の署名作成 ｓｒａ＝ｆ （ｓｋ ｂ）（Ｒａ’）
ｅｃｆｍ ｓｅｓ：（Ａ）←（Ｂ）
［送信情報］ （ｘ ｂ） ※計１２８バイト
Ｂで生成した署名（ｓｒａ） ｘ ｂ＝Ｅ （ｐｋ ａ）（ｓｒａ） ［Ａの動作］
※これで、Ａ、Ｂ双方に（Ｒａ，Ｒｂ）のペアが残され、ここから、一定のアルゴリズムでセッション共通鍵を生成する。
【０１６３】
■セッション確立後の暗号通信パラメータの設定
（例）３ＤＥＳの場合
Ｒａ−Ｒｂ−ＲａによるＥ−Ｄ−Ｅ方式による３ＤＥＳ暗号とする。この時セッションＩＤはｅｏｐｎ ｓｅｓ（）の往パケットのｓｉｄ欄に格納されていた値を利用する。つまり最初の呼び出したｃａｌｌｅｒが指定したｓｅｓｓｉｏｎ ｉｄをそのまま利用することになる。
【０１６４】
（例）ＤＥＳの場合
Ｒｂを鍵としたＤＥＳ暗号とする。
【０１６５】
この時セッションＩＤはＲａを利用する。
【０１６６】
■秘密鍵暗号による所有者モード（ａｕｔｈｍｏｄｅ＝ＯＷＮＥＲ）認証
ｅｏｐｎ ｓｅｓ、ｅｃｆｍ ｓｅｓを用いた２パス式の所有者認証によるセッションの確立動作の例を以下に示す。ここでの方法は、本発明チップが所有者に依存したパスワードを保持し、それを利用して認証を行う。認証が開始された時に、本発明チップが乱数を発生してＲ／Ｗに送信する。その後、Ｒ／Ｗ側でその乱数を用いてパスワードを暗号化して、本発明チップに送る方式を基本とする。
【０１６７】
【表３７】
（１）ｅｏｐｎ ｓｅｓ（Ａ→Ｂ）
乱数Ｒａを生成し、
・ＩＤ Ａ
・Ｒａ
をＢに送る。
【０１６８】
（２）ｅｏｐｎ ｓｅｓ（Ａ←Ｂ）
乱数Ｒｂを生成し、
・Ｘ１＝Ｅ１ Ｋｅｙ（ＩＤ Ａ｜Ｒａ）
・Ｘ２＝Ｅ２ Ｐ（Ｐｂ）
を計算し、Ａに戻す
（３）ｅｃｆｍ ｓｅｓ（Ａ→Ｂ）
ア．Ｄ１ Ｋｅｙ（Ｘ１）で復号して、Ｒａを確認する
（正しい本発明チップであることを認証）。
【０１６９】
イ．Ｒ Ｂ＝Ｄ２ Ｐ（Ｘ２）を計算しＸ２を復号してＲｂを取り出す。
【０１７０】
ウ．Ｒ Ｂを部分ビット反転などで変形したＲ’ｂを生成し、
・Ｙ＝Ｅ３ Ｐ（Ｒ’ｂ）
を生成しＢに送る。
【０１７１】
（４）ｃｅｆｍ ｓｅｓ（Ａ←Ｂ）
Ｄ３ ｐ（Ｙ）で復号して、Ｒ’ｂを確認（正しい所有者が本発明チップ搭載サービスクライアントを経由して操作していることを認証）。
【０１７２】
ＲａからセッションＩＤ（ｓｉｄ）を生成し、Ａに戻す
※ここで、”｜”は、ビット列をａｐｐｅｎｄしてつなげるという意味。例えば、
Ａ＝”０１００１００１１”、Ｂ＝”００１００１０１”であれば、
（Ａ｜Ｂ）＝”０１００１００１１００１００１０１”である。
【０１７３】
※ ＩＤ Ａ，ＩＤ Ｂはそれぞれ、本発明チップ搭載サービスクライアント（Ａ）、本発明チップ
（Ｂ）の本発明チップＩＤ（１２８ビット）である。
【０１７４】
※ Ｅ２をＤＥＳだとするならば、Ｅ３は引数をビット反転してＤＥＳする。
【０１７５】
セッション終了
Ｃｌｏｓｅ Ｓｅｓｓｉｏｎ
［機能概要］
セッションを終了する。
【０１７６】
［関数表記］
ｓｒｃＩｄ 本命令を呼び出す本発明チップ搭載サービスクライアントの本発明チップＩＤ
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝０ エラーコード
［送りパケット形式］
【表３８】
【表３９】
［戻りパケット形式］
【表４０】
【表４１】
［アクセス制御］
この命令は、セッションを構築した本発明チップ搭載クライアントであれば、常に利用できる。
【０１７７】
［機能詳細］
確立しているセッションを終了する。
【０１７８】
１０．２トランザクション管理命令群
トランザクションセッションの構築
Ｏｐｅｎ／Ｃｏｎｆｉｒｍ Ｔｒａｎｓａｃｔｉｏｎ
［機能概要］
本発明チップに対してトランザクションセッションを構築する。１パスで済む認証を用いる場合は、ｅｏｐｎ ｔｒａを、２パス必要な認証を用いる場合はｅｏｐｎ ｔｒａとｅｃｎｆ ｔｒａとをこの順序で用いる。
【０１７９】
※基本的な動作は、ｅｏｐｎ ｓｅｓ，ｅｃｆｍ ｓｅｓと同様である。ただ、その後の処理のロールバックが可能になるようになってるところが異なる。
【０１８０】
［関数表記］
ｓｒｃＩｄ 本命令を呼び出す本発明チップ搭載サービスクライアントの本発明チップ
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ａｕｔｈＭｏｄｅ 認証モードを指定
ａｕｔｈＡｌｇｏｒｉｔｈｍ 認証に使うアルゴリズムの指定子
ｓｅｓｓｉｏｎＡｌｇｏｒｉｔｈｍ 認証後のセッションにおける暗号アルゴリズムの指定子
ｌｅｎ 行きのパケット長（オクテット数）
ａｕｔｈＤａｔａ 認証用に本発明チップ搭載サービスクライアントから本発明チップに渡すデータ（ｌｅｎ−１６）
ｒｌｅｎ 戻りパケット長（オクテット数）
ｒＡｕｔｈＤａｔａ 認証用に本発明チップから本発明チップ搭載サービスクライアントに戻されたデータ（ｒｌｅｎ−８）
［パラメーター値］
ｅｏｐｎ ｓｅｓ参照
［返り値］
１パス認証の場合
＞０ セッションＩＤ（正常終了時）
＜０ エラーコード
２パス認証の場合
＜＝０ エラーコード
［送りパケット形式］
【表４２】
【表４３】
［戻りパケット形式］
【表４４】
【表４５】
［関数表記］
ｓｒｃＩｄ 本命令を呼び出す本発明チップ搭載サービスクライアントの本発明チップＩＤ
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｌｅｎ 行きのパケット長（オクテット数）
ａｕｔｈＤａｔａ 認証用に本発明チップ搭載サービスクライアントから本発明チップに渡すデータ（ｌｅｎ−１２）
ｒｌｅｎ 戻りパケット長（オクテット数）
ｒＡｕｔｈＤａｔａ 認証用に本発明チップから本発明チップ搭載サービスクライアントに戻されたデータ（ｒｌｅｎ−８）
［返り値］
＞ ０ セッションＩＤ（正常終了時）
＜ ０ エラーコード
［送りパケット形式］
【表４６】
【表４７】
［戻りパケット形式］
【表４８】
【表４９】
［機能詳細］
認証、暗号化に関しては、ｅｏｐｎ ｓｅｓ、ｅｃｆｍ ｓｅｓと同様。
【０１８１】
但し、トランザクションが確立した後は、以下の本発明チップ ＡＰＩだけが発行可能で、その他のものを発行すると、エラーになる。
【０１８２】
・Ｃｒｅａｔｅ Ｆｉｌｅ ｅｃｒｅ ｆｉｌ
．Ｄｅｌｅｔｅ Ｆｉｌｅ ｅｄｅｌ ｆｉｌ
・Ｃｒｅａｔｅ Ｒｅｃｏｒｄ ｅｃｒｅ ｒｅｃ
・Ｄｅｌｅｔｅ Ｒｅｃｏｒｄ ｅｄｅｌ ｒｅｃ
・Ｕｐｄａｔｅ Ｒｅｃｏｒｄ ｅｕｐｄ ｒｅｃ
ここで発行された命令列は、ｅｃｏｍ ｔｒａが発行された時に反映され、ｅａｂｏ ｔｒａが発行された時、または一定時間待ってｅｃｏｍ ｔｒａが発行されずタイムアウトしたときには完全にロールバックすることが保証されなければならない。
【０１８３】
トランザクション終了
Ｃｏｍｍｉｔ／Ａｂｏｒｔ Ｔｒａｎｓａｃｔｉｏｎ
［機能概要］
トランザクションを終了する。コミットして終了する場合、ｅｃｏｍ ｔｒａ、アボートして終了する場合は、ｃａｂｏ ｔａｒを使う。
【０１８４】
［関数表記］
ｓｒｃＩｄ 本命令を呼び出す本発明チップ搭載サービスクライアントの本発明チップＩＤ
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［送りパケット形式］
【表５０】
【表５１】
［戻りパケット形式］
【表５２】
【表５３】
［関数表記］
ｓｒｃＩｄ 本命令を呼び出す本発明チップ搭載サービスクライアントの本発明チップＩＤ
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［送りパケット形式］
【表５４】
【表５５】
［戻りパケット形式］
【表５６】
【表５７】
［アクセス制御］
この命令は、トランザクションを構築した本発明チップ搭載サービスクライアントであれば、常に利用できる。
【０１８５】
［機能詳細］
・確立しているトランザクションをコミット／アボートする。
【０１８６】
・コミットされた場合は、ｅｃｆｍ ｔｒａ〜ｅｃｏｍ ｔｒａの間で発行された命令をすべて、本発明チップの不揮発性記憶に反映させる。
【０１８７】
・アボートされた場合、または一定時間待ってもコミットが来ない時は、 ｔｒａ〜ｅｃｏｍ ｔｒａの間で発行された命令をすべて、本発明チップの不揮発性記憶に反映させる。
【０１８８】
１０．３ファイル管理命令群
［実装制限事項］
本システムにおけるファイルは、以下の制限を持つ。
【０１８９】
・使えるファイルの数の上限 ５０
・ファイルＩＤ ０〜４９
・ファイルのサイズ上限 ２５６（オクテット）
ファイルの作成
Ｃｒｅａｔｅ Ｆｉｌｅ
［機能概要］
（空）ファイルを作成する。
【０１９０】
［関数表記］
ｓｉｄ セッションＩＤ
ｓｒｃＩｄ 本命令を呼び出す本発明チップ搭載サービスクライアントの本発明チップＩＤ
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｆｉｄ 作成するファイルＩＤ
ｆａｃｌ ファイルアクセス制御リストの初期値
ｂｌｋ ファイルのスタートアドレス（今回は”１”固定）
ｃｎｔ ファイル長（オクテット数）
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＞ ０ 作成されたファイルＩＤ（正常終了）
＜ ０ エラーコード
［送りパケット形式］
【表５８】
【表５９】
［戻りパケット形式］
【表６０】
【表６１】
［アクセス制御］
・発行者モード（親フォルダのＩＳＳＵＥＲ本発明チップＩＤ＝Ｓｅｓｓｉｏｎを構築したＳＣの本発明チップＩＤ）であればいつでも利用できる。
【０１９１】
・親フォルダのアクセス制御リストで許可されていれば、所有者モード・他者モードで利用できる。
【０１９２】
［動作の詳細］
ｆｉｄで指定したファイルＩＤを持ったファイルを作成する。指定したｆｉｄが既に利用されている場合はエラーとなる。
【０１９３】
ファイルの削除
Ｄｅｌｅｔｅ Ｆｉｌｅ
［機能概要］
ファイルを削除する。
【０１９４】
［関数表記］
ｓｉｄ セッションＩＤ
ｓｒｃＩｄ 本命令を呼び出す本発明チップ搭載サービスクライアントの本発明チップＩＤ
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｆｉｄ 削除するファイルＩＤ
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［送りのパケット形式］
【表６２】
【表６３】
［戻りパケット形式］
【表６４】
【表６５】
［アクセス制御］
・ｅｄｅｌ ｆｉｌが実行できるためには、以下の条件を満たす必要がある。二種類のアクセス制御リストが関連するので注意が必要である。
【０１９５】
（ＣＡＳＥ１）所有者認証アクセスの場合
１．ルートフォルダが「所有者アクセス」でｅｄｅｌ ｆｉｌできるように許可されてなければならない。つまりルートフォルダのＡＣＬ２＝＝１でなければならない。
【０１９６】
２．対象ファイルが「所有者アクセス」でｅｄｅｌ ｆｉｌできるように許可されてなければならない。つまりそのファイルのＡＣＬ８＝＝１でなければならない。
【０１９７】
（ＣＡＳＥ２）発行者認証アクセスの場合
１．ルートフォルダが「その他アクセス」でｅｄｅｌ ｆｉｌできるように許可されてなければならない。つまりルートフォルダのＡＣＬ３＝＝１でなければならない。
【０１９８】
２．対象ファイル側のＡＣＬには関係しない。（常にＯＫ）
（ＣＡＳＥ３）その他アクセスの場合
１．ルートフォルダが「その他アクセス」でｅｄｅｌ ｆｉｌできるように許可されてなければならない。つまりルートフォルダのＡＣＬ３＝＝１でなければならない。
【０１９９】
２．対象ファイルが「その他アクセス」でｅｄｅｌ ｆｉｌできるように許可されてなければならない。つまりそのファイルのＡＣＬ９＝＝１でなければならない。
【０２００】
［動作の詳細］
ｆｉｄで指定したファイルＩＤを持ったファイルを削除する。ファイルの物理的位置を指す制御ブロックをクリアし、不揮発性記憶領域を解放するだけでなく、中を必ず０クリアまたは１クリアする。
【０２０１】
ファイルの譲渡要求
Ｒｅｑｕｅｓｔ Ｆｉｌｅ Ｔｒａｎｓｆｅｒ
［機能概要］
ファイルの内容を他の本発明チップ搭載コンテンツホールダに譲渡する。
【０２０２】
［関数表記］
ｓｉｄ セッションＩＤ
ｓｒｃＩｄ 本命令を呼び出す本発明チップ搭載サービスクライアントの本発明チップＩＤ
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｆｉｄ 作成するファイルＩＤ
ｔａｒｇｅｔＩｄ ファイルの譲渡先の本発明チップＩＤ
ｔａｒｇｅｔＦｉｄ 譲渡するファイルの譲渡先でのファイルＩＤ
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＞ ０ 実際に更新したデータ長（正常終了）
＜ ０ エラーコード
［パケット形式］
【表６６】
【表６７】
［戻りパケット形式］
【表６８】
【表６９】
［動作詳細］
このシステムコールが呼ばれたチップは、以下の一連の処理を行う。
【０２０３】
譲渡相手のチップに対して、以下の本発明チップ ＡＰＩ列を発行する。
【０２０４】
・トランザクションセッションをはる。 ｅｏｐｎ ｔｒａ
ｅｃｆｍ ｔｒａ
・ファイルを作成する。 ｅｃｒｅ ｆｉｌ
・レコードを作成する。 ｅｃｒｅ ｒｅｃ
： ：
・トランザクションをコミットする ｅｃｏｍ ｔｒａ
途中で何らかの異常が検知された場合は、トランザクションはアボートされる。また、正常にコミット命令が到達しない限りセッション中の命令が反映されることもない。
【０２０５】
ファイルのデータを暗号化・復号化する
Ｅｎｃｏｄｅ／Ｄｅｃｏｄｅ Ｆｉｌｅ
［機能概要］
本発明暗号化コンテンツが格納されているファイルを復号する。
【０２０６】
［関数表記］
ｓｉｄ セッションＩＤ
ｓｒｃＩｄ 本命令を呼び出す本発明チップ搭載サービスクライアントの本発明チップＩＤ
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｓｒｃＦｉｄ 暗号化コンテンツが格納されているファイルＩＤ
ｄｅｓｔＦｉｄ 復号されたコンテンツを格納するファイルＩＤ
ｋｅｙＩｄ 復号処理に使う鍵実体が格納されているファイルＩＤ
ｃｕｒｒｅｎｔＭｏｎｅｙ 鍵実体中に残されている金額残高
ｐａｙｅｄＭｏｎｅｙ 今回決裁した金額
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［パケット形式］
【表７０】
【表７１】
［戻りパケット形式］
【表７２】
【表７３】
［機能詳細］
■ｅｄｅｃ ｆｉｌ（）の動作
【表７４】
■ｅｅｎｃ ｆｉｌ（）の動作
【表７５】
※コンテンツの暗号化は、「元のＫＥＹ」で行なう。
【０２０７】
※ＫＥＹの暗号化は、指定した鍵実体の鍵で行なう。
【０２０８】
※署名は、暗号化が終了したデータに関して作用する。
【０２０９】
※ ＨＭＡＣ ｗｉｔｈ ＭＤ５の時の６４ビット秘密鍵Ｋは、元のＫＥＹを４回繰り返したものを使う。
【０２１０】
ファイルのアクセス制御リストの変更
Ｕｐｄａｔｅ Ｆｉｌｅ Ｍｏｄｅ
［機能概要］
ファイルのアクセス制御リストを変更する。
【０２１１】
［関数表記］
ｓｉｄ セッションＩＤ
ｓｒｃＩｄ 本命令を呼び出す本発明チップ搭載サービスクライアントの本発明チップＩＤ
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｆｉｄ アクセス制御リストの変更対象のファイルＩＤ
ｆｉｌａｃｌ ファイルアクセス制御リストの更新データ
ｃａｌｌｅｒＩｄ 本命令を呼び出す本発明チップ搭載サービスクライアントの本発明チップＩＤ
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［送りパケット形式］
【表７６】
【表７７】
［戻りパケット形式］
【表７８】
【表７９】
［アクセス制御］
・対象ファイルに対して発行者モード（ファイルのＩＳＳＵＥＲ本発明チップＩＤ＝ｓｅｓｓｉｏｎを構築したＳＣの本発明チップＩＤ）であればいつでも利用できる。
【０２１２】
・対象ファイルのアクセス制御リストで許可されていれば、所有者モード・他者モードで利用できる。
【０２１３】
［機能概要］
ファイルのアクセス制御リストを、指定した値に変更する。
【０２１４】
定義済ファイルのリストを得る
Ｌｉｓｔ Ｆｉｌｅ ＩＤ
［機能概要］
定義済ファイルのリストを得る
［関数表記］
ｓｉｄ セッションＩＤ
ｓｒｃＩｄ 本命令を呼び出す本発明チップ搭載サービスクライアントの本発明チップＩＤ
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｆｉｄ 対象のファイルＩＤ
ｆｉｌｅＣｔｒｌＢｌｋ 対象のファイルの制御ブロック
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［送りパケット形式］
【表８０】
【表８１】
［戻りパケット形式］
【表８２】
【表８３】
［アクセス制御］
・対象ファイルに対して発行者モード（ファイルのＩＳＳＵＥＲ本発明チップＩＤ＝Ｓｅｓｓｉｏｎを構築したＳＣの本発明チップＩＤ）であればいつでも利用できる。
【０２１５】
・対象ファイルのアクセス制御リストで許可されていれば、所有者モード・他者モードで利用できる。
【０２１６】
１０．４レコード管理命令群
レコードのデータを更新
Ｕｐｄａｔｅ Ｒｅｃｏｒｄ
［機能概要］
レコードの内容を変更する。
【０２１７】
［関数表記］
ｓｉｄ セッションＩＤ
ｓｒｃＩｄ 本命令を呼び出す本発明チップ搭載サービスクライアントの本発明チップＩＤ
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｆｉｄ 変更するファイルＩＤ
ｂｌｋ 変更するレコード番号（今回は＝１固定）
ｃｎｔ 変更するレコードデータ長（オクテット数）
ｄａｔａ 変更するデータの内容（ｃｎｔオクテット）
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＞ ０ 実際に更新したデータ長（正常終了）
＜ ０ エラーコード
［パケット形式］
【表８４】
【表８５】
［戻りパケット形式］
【表８６】
【表８７】
［アクセス制御］
・対象レコードに対して発行者モード（レコードのＩＳＳＵＥＲ本発明チップＩＤ＝Ｓｅｓｓｉｏｎを構築したＳＣの本発明チップＩＤ）であればいつでも利用できる。
【０２１８】
・対象レコードのアクセス制御リストで許可されていれば、所有者モード・他で利用できる。
【０２１９】
［動作の詳細］
ｂｌｋレコードで、始めからｃｎｔオクテット分のデータを書き込む要求を出す。ｃｎｔは、ハードウェアの条件によって上限が設けられることがある。実際に書き込まれたオクテット数がｒＣｎｔに返る。
【０２２０】
レコードからデータを読む
Ｒｅａｄ Ｒｅｃｏｒｄ
［機能概要］
レコードの内容を読み出す。
【０２２１】
［関数表記］
ｓｉｄ セッションＩＤ
ｓｒｃＩｄ 本命令を呼び出す本発明チップ搭載サービスクライアントの本発明チップＩＤ
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｆｉｄ 読み出すファイルＩＤ
ｂｌｋ 読み出すレコードレＩＤ
ｃｎｔ 読み出すデータの長さ（オクテット数）
ｒＣｎｔ 実際に読み出したデータの長さ（オクテット数）
ｒＤａｔａ 読み出したデータ（ｒＣｎｔオクテット）
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［パケット形式］
【表８８】
【表８９】
［戻りパケット形式］
【表９０】
【表９１】
［アクセス制御］
・対象レコードに対して発行者モード（レコードのＩＳＳＵＥＲ本発明チップＩＤ ＝Ｓｅｓｓｉｏｎを構築したＳＣの本発明チップＩＤ）であればいつでも利用できる。
【０２２２】
・対象レコードのアクセス制御リストで許可されていれば、所有者モード・他者モードで利用できる。
【０２２３】
［動作の詳細］
ｂｌｋレコードの最初から、ｃｎｔオクテット分のデータを読み込む要求を出す。ｃｎｔは、ハードウェアの条件によって上限が設けられることがある。実際に読み込まれたオクテット数がｒＣｎｔに返る。
【０２２４】
通常は、セッションが確立したところで発行されて実行されるが、タッチ＆ゴー応用の特化し、セッションを確立していない本発明チップ搭載サービスクライアントでも、ｓｉｄ＝０で本命令を呼び出すことができる。この場合、レコードのアクセス制御リストで、その他権限での読み出しが許可されていると、命令の実行は成功する。
【０２２５】
１０．５鍵実体管理命令群
［実装制限事項］
本システムにおける鍵実体は、以下の制限を持つ。
【０２２６】
・使えるファイル数の上限 １０
・鍵実体ＩＤ ０〜９
・鍵実体のサイズ上限 ２５６（オクテット）
鍵実体を作成する
Ｃｒｅａｔｅ Ｋｅｙ Ｏｂｊｅｃｔ
［機能概要］
［関数表記］
ｓｉｄ セッションＩＤ
ｓｒｃＩｄ 本命令を呼び出す本発明チップ搭載サービスクライアントの本発明チップＩＤ
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｋｉｄ 鍵実体ＩＤ
ＫｅｙＡｌｇｏｒｉｔｈｍ 暗号アルゴリズム指定子
ｋｅｙ 暗号鍵
ｂａｎｋｌｄ 銀行ＩＤ
ｉｎｉｔＭｏｎｅｙ Ｖａｌ 初期金額
ａｃｌ 初期アクセス制御リスト値（最初のバージョンでは未使用）
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［パケット形式］
【表９２】
【表９３】
［戻りパケット形式］
【表９４】
【表９５】
鍵実体を削除する
Ｄｅｌｅｔｅ Ｋｅｙ Ｏｂｊｅｃｔ
［機能概要］
［関数表記］
ｓｉｄ セッションＩＤ
ｓｒｃＩｄ 本命令を呼び出す本発明チップ搭載サービスクライアントの本発明チップＩＤ
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｋｉｄ 削除する鍵実体ＩＤ
ｂａｎｋＩｄ 銀行ＩＤ
ｒｅｍａｉｎｉｎｇＭｏｎｅｙ 残金
ｒｓｉｚｅ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｌｉｓｔの長さ
ｂｏｏｋＬｉｓｔ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｌｉｓｔ
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［パケット形式］
【表９６】
【表９７】
［戻りパケット形式］
【表９８】
【表９９】
鍵実体を更新する
Ｕｐｄａｔｅ Ｋｅｙ Ｏｂｊｅｃｔ
［機能概要］
指定した鍵実体の金額を更新する。
【０２２７】
［関数表記］
ｓｉｄ セッションＩＤ
ｓｒｃＩｄ 本命令を呼び出す本発明チップ搭載サービスクライアントの本発明チップＩＤ
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｋｉｄ 更新する鍵実体ＩＤ
ａｄｄＭｏｎｅｙ 加算される金額
ｃｕｒｒｅｎｔＭｏｎｅｙ 加算後の金額
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［パケット形式］
【表１００】
【表１０１】
［戻りパケット形式］
【表１０２】
【表１０３】
鍵実体の情報を読む
Ｒｅａｄ Ｋｅｙ Ｏｂｊｅｃｔ
［機能概要］
指定した鍵実体の金額情報を読み出す。
【０２２８】
［関数表記］
ｓｉｄ セッションＩＤ
ｓｒｃＩｄ 本命令を呼び出す本発明チップ搭載サービスクライアントの本発明チップＩＤ
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｋｉｄ 金額情報を読み出す対象である鍵実体ＩＤ
ｃｕｒｒｅｎｔＭｏｎｅｙ 現在の金額
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［パケット形式］
【表１０４】
【表１０５】
［戻りパケット形式］
【表１０６】
【表１０７】
鍵実体のアクセス制御リストを更新する
Ｕｐｄａｔｅ Ｋｅｙ Ｍｏｄｅ
［機能概要］
鍵実体のアクセス制御リストを更新する。
【０２２９】
※最初のバージョンでは未実装
［関数表記］
ｓｉｄ セッションＩＤ
ｓｒｃＩｄ 本命令を呼び出す本発明チップ搭載サービスクライアントの本発明チップＩＤ
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｋｉｄ アクセス制御リスト更新する対象である鍵実体ＩＤ
ｋｅｙａｃｌ 更新する鍵実体アクセス制御リスト
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［パケット形式］
【表１０８】
【表１０９】
［戻りパケット形式］
【表１１０】
【表１１１】
定義済鍵実体のリストを得る
Ｌｉｓｔ Ｋｅｙ Ｏｂｊｅｃｔ ＩＤ
［機能概要］
定義済鍵実体のリストを得る
［関数表記］
ｓｉｄ セッションＩＤ
ｓｒｃＩｄ 本命令を呼び出す本発明チップ搭載サービスクライアントの本発明チップＩＤ
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｋｉｄ 対象の鍵実体ＩＤ
ｋｅｙＣｔｒｌＢｌｋ 対象の鍵実体の制御ブロック
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［送りパケット形式］
【表１１２】
【表１１３】
［戻りパケット形式］
【表１１４】
【表１１５】
［アクセス制御］
・対象鍵実体に対して発行者モード（ファイルのＩＳＳＵＥＲ本発明チップＩＤ ＝Ｓｅｓｓｉｏｎを構築したＳＣの本発明チップＩＤ）であればいつでも利用できる。
【０２３０】
・対象鍵実体のアクセス制御リストで許可されていれば、所有者モード・他者モードで利用できる。
【０２３１】
１０．６認証補助管理命令群
ｅＴＰ証明書をチェックする
Ｃｏｎｆｉｒｍ Ｃｅｒｔｉｆｉｃａｔｅ
［関数表記］
ｓｉｄ セッションＩＤ
ｓｒｃＩｄ 本命令を呼び出す本発明チップ搭載サービスクライアントの本発明チップＩＤ
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｃｈｅｃｋＭｏｄｅ 破棄リストのチェックモード
ｓｅｒｉａｌ 確認する証明書の証明書番号
ｃａＩｄ 確認する証明書の発行者ＩＤ
ｃｒｌ 破棄リスト（本発明チップ形式）
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［ｃｈｅｃｋＭｏｄｅ］
０ｘ００ チェックだけを返す
０ｘ０１ 対応する破棄リストを得る
［返り値］
＞ ０ セッションＩＤ（正常終了時）
＜ ０ エラーコード
［パケット形式］
【表１１６】
【表１１７】
［戻りパケット形式］
【表１１８】
【表１１９】
■５．３準本発明チップ ＡＰＩ命令定義
次に記述するＡＰＩ命令は、その形式は本発明チップ ＡＰＩ命令に準ずるが、必ずしも本発明チップ搭載サービスクライアントだけが発行する命令でなく、他の実体が発行する命令である。主に、ハードウェアに依存した管理、運用、また通信の下位階層をサポートするためのインタフェースが中心である。チップリーダライタユニットが発行したり、製造時のコンピュータが発行するケースがある。
【０２３２】
チップをポリングする
Ｐｏｌｌ ＣＨＩＰ
［機能概要］
本発明チップの状態を読み出す（実装依存、運用依存）。
【０２３３】
［関数表記］
ＥＲＲ ｅｐｏｌ ｃａｒ（ＥＴＲＯＮＩＤ＊ ｄｅｓｔＩｄ，ＥＴＲＯＮＩＤ ｓｒｃＩｄ，ＴＩＭＥ ｔ）； ｄｅｓｔＩｄ ポリングしたときに返されるチップＩＤ
ｓｒｃＩｄ 本命令を呼び出す本発明チップ搭載サービスクライアントの本発明チップＩＤ
ｔ 時刻
［返り値（例）］
＜＝ ０ エラーコード
［パケット形式］
【表１２０】
【表１２１】
［戻りパケット形式］
【表１２２】
【表１２３】
※ ｅａｒｄＩｄ、ｃｌｉｅｎｔＩｄともにチップヘッダにつくので、本体の中には入らない。
【０２３４】
［アクセス制御］
このＡＰＩは、常に利用できる。
【０２３５】
セッション中でなくてもよい。
【０２３６】
［機能の詳細］
ｅｐｏｌ ｃａｒの戻りパケットのルーティングヘッダ部分のｓｒｃＩｄ部分に、チップの本発明チップＩＤを格納して戻すため、誰でも本発明チップのＩＤを最初に取得するために用いることができる。
【０２３７】
セッションの中でなく、誰でも発行できる。
【０２３８】
チップを初期化する
Ｉｎｉｔｉａｌｉｚｅ ＣＨＩＰ
［機能概要］
本発明チップを初期化するために、チップ管理部を作成する。
【０２３９】
［関数表記（例）］
ｓｒｃＩｄ ａｌｌ”１”
ｔ 時刻
ｉｎｉｔＫｅｙ１ 認証用共通鍵（１）
ｉｎｉｔＫｅｙ２ 認証用共通鍵（２）
ｉｎｉｔＰａｓｓｗｄ 初期パスワード
ｆｉｌｅＮｕｍ チップ内に作成可能なファイル数の上限
ｋｅｙＯｂｊＮｕｍ 鍵実体数の上限
ｓｗａｐＬｅｎ 不揮発性記憶の中のスワップ領域の大きさ
ｃａｃｌ チップのアクセス制御リスト
ｒｓａＳｅｃｒｅｔＫｅｙ 自カードの認証用（ＲＳＡ）秘密鍵
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［パケット形式］
【表１２４】
【表１２５】
［戻りパケット形式］
【表１２６】
【表１２７】
［動作の詳細］
与えられた引数に応じて、システム制御ブロックを初期化する。
【０２４０】
その他のメモリ領域は、すべて０クリアする。
【０２４１】
［アクセス制御］
本発明チップのｓｏｕｒｃｅ本発明チップＩＤ＝Ｏｘｆｆ…ｆｆ（ａｌｌ”１”）の時のみ受け付ける。
【０２４２】
自認証公開鍵証明書入換
Ｕｐｄａｔｅ Ｍｙ Ｃｅｒｔｉｆｉｃａｔｅ
［機能概要］
本発明チップ自身の証明書を更新する。
【０２４３】
［関数表記］
ｓｉｄ セッションＩＤ
ｓｒｃＩｄ 本命令を呼び出す本発明チップ搭載サービスクライアントの本発明チップＩＤ
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｃｅｒｔｉｆｉｃａｔｅ 証明書
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［パケット形式］
【表１２８】
【表１２９】
［戻りパケット形式］
【表１３０】
［戻りパケット形式（例）］
【表１３１】
ＣＡ局公開鍵入換
Ｕｐｄａｔｅ ＣＡ Ｐｕｂｌｉｃ Ｋｙｅ
［機能概要］
ＣＡ局の公開鍵交換する。
【０２４４】
［関数表記］
ｓｉｄ セッションＩＤ
ｓｒｃＩｄ 本命令を呼び出す本発明チップ搭載サービスクライアントの本発明チップＩＤ
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｃａＰｕｂｌｉｃＫｅｙ ＣＡ局の公開鍵
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［パケット形式］
【表１３２】
【表１３３】
［戻りパケット形式］
【表１３４】
［戻りパケット形式（例）］
【表１３５】
暗号実装仕様
■ＤＥＳ
６４ビットの秘密鍵から５６ビットのＤＥＳ鍵の生成方法
以下の通り、各オクテットの最下位ビットをパリティビットとする（しかしチップでは無視するだけでチェックはしない）。上位７ビットを８オクテット分足した５６ビットをＤＥＳとして利用する。
【０２４５】
■ＲＳＡ
ＲＳＡ鍵のデータ形式
鍵について、以下のように表現する。
【０２４６】
ｄ＝１０２４ビット（１２８オクテット）
ｎ＝１０２４ビット（１２８オクテット）
ｅ＝０ｘ０００３固定（１オクテット）
秘密鍵ｓｋ＝ｄ（１２８オクテット）
公開鍵ｐｋ＝ｅの長さ（１オクテット）｜ｅ（１オクテット）｜ｎ（１２８オクテット）
【０２４７】
【発明の効果】
以上説明したように、本発明によれば、本発明の自律型ＩＣカードは、ＩＣカード端末を介して接続される通信装置を自ら認識し、その通信装置と直接的に通信を行うので、正確な情報の安全な通信を保証することができる。また、本発明の自律型ＩＣカードが、通信装置と相互に認証処理を行うと共に通信装置との通信に係る情報に対して暗号化／復号化を施す暗号処理部を有する構成とした場合、更に、通信装置の正規性を判断できると共に、その自律型ＩＣカードと、その通信装置との間に物理的に介在する装置によるデータ内容の盗難やデータの改竄の可能性を十分に低減することができる。特に、そのデータが電子チケット等のいわゆる価値情報にかかるものである場合、その意義は大きい。また、暗号処理部が、認識された通信装置の種別に応じて、複数の認証処理及び複数の暗号処理の中から適した認証処理及び暗号処理を選択してそれらの処理を行う場合、認識された通信装置に適した処理を行うことができる。
【図面の簡単な説明】
【図１】本発明におけるＩＣカードの一実施形態の論理的な構成を示す図である。
【図２】本発明の自律型ＩＣカードによるＩＣカード間通信を行うシステムの構成を示す図である。
【図３】本発明の自律型ＩＣカードによる通信を行う他のシステムの構成を示す図である。
【図４】従来におけるＩＣカードとＩＣカード端末との信号のやり取りを説明するための図である。
【図５】従来において、２枚のＩＣカードが互いに通信を行う場合の信号のやり取りを示す図である。
【符号の説明】
１，１ａ，１ｂ 自律型ＩＣカード
２，２ａ，２ｂ ＩＣカードリーダ／ライター
３ ＩＣカード端末本体
４ ネットワーク
５ 通信装置
１０ ＣＰＵ
１１ ＲＯＭ
１２ ＲＡＭ
１３ 不揮発性メモリ
１４ 暗号処理部
１５ 通信制御部
１６ 外部通信インターフェース
１７ ホストデバイスインターフェース
１００ ＩＣカード
１００ａ ＩＣカード
１００ｂ ＩＣカード
２００ ＩＣカードリーダ／ライター
２００ａ ＩＣカードリーダ／ライター
２００ｂ ＩＣカードリーダ／ライター
３００ ＩＣカード端末本体
【発明の属する技術分野】
本発明は、ＩＣカードに関し、特に、ＩＣカード端末に直接又はネットワークを介して接続される他の装置と、直接かつ自律的に通信を行う自律型ＩＣカードに関する。
【０００２】
【従来の技術】
図４は、従来におけるＩＣカードとＩＣカード端末との信号のやり取りを説明するための図である。
ここで、ＩＣカード端末は、ＩＣカードリーダ／ライター２００とＩＣカード端末本体３００とで構成される。尚、ここではＩＣカード１００とＩＣカードリーダ／ライター２００とは模式的に離れて示されているが、このように非接触型であってもよいし、勿論、ＩＣカード１００がＩＣカードリーダ／ライター２００に典型的には挿入される接触型であってもよい。
【０００３】
このようなＩＣカード１００を利用した処理においては、ＩＣカード端末本体３００がマスター装置であり、ＩＣカード１００がスレーブ装置となっている。すなわち、ＩＣカード１００を利用した処理を行いたい場合、先ずＩＣカード端末本体３００に備えられた入力端末（図示せず）に操作者は指示入力する。それに応じて、マスター装置たるＩＣカード端末本体３００は、ＩＣカードリーダ／ライター２００を介して命令をＩＣカード１００に送る。その命令を受け取ったスレーブ装置たるＩＣカード１００はその命令に応じた処理を行い、その実行結果をＩＣカードリーダ／ライター２００を介してＩＣカード端末本体３００に返す。
【０００４】
図５は、従来において、２枚のＩＣカードが互いに通信を行う場合の信号のやり取りを示す図である。
同図において、図４に示した構成に加えて、ＩＣカードリーダ／ライター２００ｂがＩＣカード端末本体３００に接続されており、そのＩＣカードリーダ／ライター２００ｂにＩＣカード１００ｂが接触式又は非接触式で接続される形態になっている。
【０００５】
そこで、図４の場合と同様、先ずＩＣカード端末本体３００に備えられた入力端末（図示せず）に操作者はカード間通信に係る指示入力する。それに応じて、ＩＣカード端末本体３００は、ＩＣカードリーダ／ライター２００ａを介して命令をＩＣカード１００ａに送る。その命令を受け取ったＩＣカード１００ａはその命令に応じた処理を行い、その結果である返答Ａを出力する。ＩＣカード１００ａから出力された返答Ａは、ＩＣカードリーダ／ライター２００ａを介してＩＣカード端末本体３００に入力される。ＩＣカード端末本体３００は、その返答Ａたる情報に対しての中継動作を行う。ＩＣカード端末本体３００から出力された返答Ａは、ＩＣカードリーダ／ライター２００ｂを介してＩＣカード１００ｂに入力される。ＩＣカード１００ｂは、入力された返答Ａに応じた処理を行い、その結果として返答Ｂを出力する。ＩＣカード１００ｂから出力された返答Ｂは、ＩＣカードリーダ／ライター２００ｂを介してＩＣカード端末本体３００に入力される。ＩＣカード端末本体３００は、その返答Ｂたる情報に対しての中継動作を行う。ＩＣカード端末本体３００から出力された返答Ｂは、ＩＣカードリーダ／ライター２００ａ介してＩＣカード１００ａに入力される。
【０００６】
以上のようなＩＣカード１００ａとＩＣカード１００ｂとの間のやりとりが更に続いても、基本的には動作は同じである。すなわち、ＩＣカード端末本体３００は、ＩＣカード１００ａＩＣカード１００ｂとの間でやりとりされる情報に対する中継動作を行うという役目を必ず担っている。
【０００７】
【発明が解決しようとする課題】
ところで、従来におけるＩＣカード間通信においては、上述のようにＩＣカード端末本体が必ずＩＣカード間通信に係る情報の中継動作を行っている。従って、従来においては、ＩＣカード端末本体に代表される介在装置が、ＩＣカード間の通信情報を改竄したり盗聴したりすることが可能であった。故に、従来においては、ＩＣカード間の正確な情報の通信が保証されないという課題があった。
【０００８】
本発明は、上述のような事情を鑑みて為されたものであり、本発明の目的は、ＩＣカードがＩＣカード端末に直接又はネットワークを介して接続される他の通信装置と通信を行うに際し、ＩＣカードと他の通信装置との間に介在するＩＣカード端末等の装置を見かけ上介在させることなく、他の通信装置と直接通信を行うことにより、正確な情報の安全な通信を保証することができる自律型ＩＣカードを提供することにある。
【０００９】
【課題を解決するための手段】
上記目的を達成するため、請求項１の自律型ＩＣカードは、ＩＣカード端末と物理層を介して接続される論理ホストインターフェースと、前記ＩＣカード端末を物理的に介して接続される通信装置と通信を行うための論理外部通信インターフェースと、前記論理外部通信インターフェースを介し、前記通信装置の接続を認識し、前記通信装置と直接的に通信を行うように構成されたＩＣチップと、を備えることを要旨とする。
【００１０】
本発明によれば、本発明の自律型ＩＣカードは、ＩＣカード端末を介して接続される通信装置を自ら認識し、その通信装置と直接的に通信を行うことができる。
【００１１】
また、請求項２の発明は、請求項１の自律型ＩＣカードにおいて、前記ＩＣチップは、前記論理外部通信インターフェースを介して前記通信装置と直接的に通信を行うためのソフトウェアモジュールたる通信制御部を有することを要旨とする。
【００１２】
本発明によれば、通信制御部は、接続されているＩＣカード端末を意識しないソフトウェアモジュールによりその処理を行うことができる。
【００１３】
また、請求項３の発明は、請求項２の自律型ＩＣカードにおいて、前記通信制御部は、前記通信装置に対してセッション通信路を構築するセッション管理命令群と、前記通信装置に対してトランザクションセッションを構築するトランザクション管理命令群と、を有することを要旨とする。
【００１４】
また、請求項４の発明は、請求項１の自律型ＩＣカードにおいて、前記ＩＣチップは、前記通信装置と相互に認証処理を行うと共に、前記通信装置との通信に係る情報に対して暗号化／復号化を施す暗号処理部を有することを要旨とする。
【００１５】
本発明によれば、暗号処理部は、通信装置と相互に認証処理を行うと共に、通信装置との通信に係る情報に対して暗号化／復号化を施す。
【００１６】
また、請求項５の発明は、請求項４の自律型ＩＣカードにおいて、前記ＩＣチップは、割り当てられた固有の識別子を有し、その識別子に基づき、前記通信装置を識別し、相互の認証処理を行うことを要旨とする。
【００１７】
また、請求項６の発明は、請求項４の自律型ＩＣカードにおいて、前記暗号処理部は、認識された前記通信装置の種別に応じて、複数の認証処理及び複数の暗号処理の中から適した認証処理及び暗号処理を選択してそれらの処理を行うことを要旨とする。
【００１８】
また、請求項７の発明は、請求項１乃至６の自律型ＩＣカードにおいて、前記ＩＣチップは、価値情報が格納される記憶部を有し、前記他の通信装置とその価値情報に係る通信を行うことを要旨とする。
【００１９】
また、請求項８の発明は、請求項１乃至７の自律型ＩＣカードにおいて、前記ＩＣカード端末と前記他の通信装置は、ネットワークを介して接続されていることを要旨とする。
【００２０】
また、請求項９の発明は、請求項１乃至８の自律型ＩＣカードにおいて、前記論理ホストインターフェース及び前記論理外部通信インターフェースと、前記ＩＣカード端末とは、非接触で接続されることを要旨とする。
【００２１】
【発明の実施の形態】
以下、図面に基づいて、本発明における自律型ＩＣカードの実施形態について詳細に説明する。
【００２２】
図１は、本発明における自律型ＩＣカードの一実施形態の論理的な構成を示す図である。
【００２３】
図１において、本発明の自律型ＩＣカード１は、ＣＰＵ１０と、ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）１１と、ＲＡＭ（ｒａｎｄａｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）１２と、不揮発性メモリ１３と、暗号処理部１４と、通信制御部１５と、外部通信インターフェース１６と、ホストデバイスインターフェース１７とで構成される。
【００２４】
尚、上記構成においては、物理的な構成（ハードウェア）と論理的な構成（ソフトウェア）が混在しているが、以下それぞれについて説明する。
【００２５】
ホストデバイスインターフェース１７は、従来から備わっている物理的インターフェースであり、外部との通信を行うためのものである。従来と同様、接触型と非接触型がある。ＣＰＵ１０は、一部の浮動小数点演算を除き、全ての演算を行う中央演算装置である。尚、浮動小数点演算については別途浮動小数点演算装置が備わっている（図示せず）。ＲＯＭ１１は、読み出し専用メモリであり、当該自律型ＩＣカード１用の固有のソフトウェア（ＯＳ、プログラム）や後述する本発明チップＩＤが格納されている。ＲＡＭ１２は、読み書き可能メモリであり、当該自律型ＩＣカード１内で動作するソフトウェアが扱うデータが一時的に記憶されるメモリである。尚、ＩＣカードへの電力供給が絶たれると内容全て消去される。
【００２６】
不揮発性メモリ１３は、後述する価値情報が格納される。価値情報とは、電子チケット、電子マネー等の価値を含むデータをいう。尚、不揮発性メモリ１３は、内容保持型メモリなので電力の供給が絶たれても内容が保持される。
以上が物理的な構成部分である。
【００２７】
外部通信インターフェース１６は、上記ＣＰＵ１０等で構成される後述する本発明チップが外部との直接通信を行う論理的なインターフェースである。従来のＩＣカードは、それが物理的に接続されている装置、典型的にはＩＣカード端末、とのみ通信を行う論理インターフェースしか持たなかったが、本発明の自律型ＩＣカード１は、論理ホストインターフェースの他に、外部の装置（後述の本発明チップ搭載サービスクライアント）と直接通信を行う外部通信インターフェース１６を備えている。尚、この外部通信インターフェース１６は、後の「４．本発明チップ ＡＰＩプロトコル」で詳述するプロトコルに従って通信を行うインターフェースである。
【００２８】
通信制御部１５は、外部通信インターフェース１６を介して外部の装置との間で行われる通信を制御するソフトウェアモジュールである。後述する「１０．本発明チップ ＡＰＩ仕様」全体を実現するソフトウェアモジュールであるが、特に「１０．１セッション管理命令群」及び「１０．２トランザクション管理命令群」と関わりが深いソフトウェアモジュールである。このモジュールにより外部の装置との間で直接的に通信が行われる。
【００２９】
暗号処理部１４は、後述する「３．４認証・アクセス制御・暗号」、「５．ｅＴＰ鍵証明書」及び「６．鍵実体」において定義された多様な種類の相互認証及び暗号通信を可能にするためのモジュールである。暗号処理部１４は、通信を行う相手装置に応じて、複数の相互認証及び複数の暗号通信の中から適したものを選択切替している。尚、通信制御部１５に基づく直接通信の上に、暗号処理部１４による相互認証及び暗号通信を行えば、間に介在する装置、例えばＩＣカード端末、によりデータ内容が盗まれたり、データが改竄されるという危険性が更に低くなる。
【００３０】
尚、図１に示された本発明に係る構成部は、好適には、最後に詳細にその仕様が列記されるワンチップマイクロコンピュータ（以下、ＩＣチップと称する）で具現化される。
【００３１】
ここで、本発明の自律型ＩＣカードに搭載されるＩＣチップの全体的な特徴を説明する。
【００３２】
本発明に係るＩＣチップは、分散環境におけるノードとして機能するように設計されている。従って、本発明のＩＣカードがＩＣカードリーダ／ライターを有するＩＣカード端末本体に接触式又は非接触式で接続されて機能している装置が、ネットワークを介して、例えば他のＩＣカードと物理的に通信できるように構成されている場合、本発明に係るＩＣチップを有するそれらのＩＣカードは通信ネットワーク上でノードとしての機能を有する。そして、このときＩＣカードリーダ／ライター及びＩＣカード端末本体は、ネットワークとコンタクトレス通信の物理層を橋渡しするゲートウェイ（ブリッジ）の役割を果たしている。すなわち、前述の外部通信インターフェース１６が、分散システムにおけるノードとしてのＩＣカードの通信を司っており、ホストデバイスインターフェース１７が、コンタクトレス通信の物理層を橋渡しする役割を担っている。
【００３３】
そこで、分散環境におけるノードとして機能するために、本発明に係るＩＣチップは、上述のようなネットワークを最も簡単な例とする分散システム全体において固有の識別子（ＩＤ）を有している。
【００３４】
また、本発明の自律型ＩＣカードに搭載されるＩＣチップは、ネットワークを介して接続された、同様のＩＣチップを搭載した複数の装置を識別し、それらの装置との相互認証を先ず行う。そして、それらの装置が正規の実体であると確認した後にそれらの装置との通信を行うように設計されている。その認証においては、２つのモード、すなわち（情報）発行者モード及び所有者モードがある。これは後に詳述する。
【００３５】
更に、本発明に係るＩＣチップにおいては、それが有する資源を保護するために、前述のＩＤに基づいたアクセス制御リストが採用されている。つまり、チップ、ファイル（、レコード）にはアクセス制御リストが付加されている。
【００３６】
本発明に係るＩＣチップでは、アクセス制御リストの中で、「所有者」、「発行者」、「その他」のサービスクライアントを統一的に扱い、それぞれの持つ権限に応じて、アクセス制御リストを変更するＡＰＩを発行することによって、アクセス権限の制限や解放、移譲といった制御を柔軟に行うことを可能にしている。
【００３７】
また、本発明に係るＩＣチップにおいては、コンテンツを複数のコンテンツホールダ、例えば、本発明チップとネットワーク上の価値情報格納サーバー、の間で分散して保持する、ハイブリッド方式をサポートし、そのための機構として、コンテンツ間のリンク機能を提供している。
【００３８】
次に、本発明の自律型ＩＣカードによる通信の具体例について説明する。
図２は、本発明の自律型ＩＣカードによるＩＣカード間通信を行うシステムの構成を示す図である。
同図において、自律型ＩＣカード１ａは、ＩＣカード端末本体３に備わったＩＣカードリーダ／ライター２ａに対して接触式又は非接触式に接続されている。また、同様に、自律型ＩＣカード１ｂは、ＩＣカード端末本体３に備わったＩＣカードリーダ／ライター２ｂに対して接触式又は非接触式に接続されている。
【００３９】
かかる構成において、自律型ＩＣカード１ａに対して自律型ＩＣカード１ｂと通信を行わせたい場合、操作者は、ＩＣカード端末本体３に備えられた入力端末（図示せず）にカード間通信に係る指示入力する。それに応じて、ＩＣカード端末本体３は、ＩＣカードリーダ／ライター２ａを介して命令を自律型ＩＣカード１ａに送る。その命令を受け取った自律型ＩＣカード１ａは、図１に示した外部通信インターフェース１６を介して、ソフトウェア的に、直接かつ自律的に、自律型ＩＣカード１ｂと通信を行う。自律型ＩＣカード１ａがこのように自律型ＩＣカード１ｂと直接通信できるのは、前述のように、自律型ＩＣカード１ａが分散環境におけるノードとして機能することができるからである。かかる通信において、図１に示した暗号処理部１４により通信データに対して暗号化及び復号化を行えば、通信途中における改竄や盗聴という危険を確実に回避できる。
【００４０】
図３は、本発明の自律型ＩＣカードによる通信を行う他のシステムの構成を示す図である。
本発明の自律型ＩＣカードによる通信においては、通信の相手がＩＣカードである必要はなく他の通信装置であってもよい。同図において、ＩＣカード端末本体３はネットワーク４を介して他の通信装置５と接続されている。自律型ＩＣカード１ａがネットワーク４を介して通信装置５と通信を行う場合、ＩＣカード端末本体３から命令を受けた自律型ＩＣカード１ａは、ソフトウェア的に、直接かつ自律的に、通信装置５と通信を行う。
【００４１】
以下、本発明の自律型ＩＣカードに搭載されるＩＣチップ（以下、単に、本発明チップと称する）の詳細仕様を説明する。以下の説明中、Ｃｏｎｔｅｎｔｓ Ｈｏｌｄｅｒ（ＣＨｓ）が上述の自律型ＩＣカード１，１ａに対応しており、Ｓｅｒｖｉｃｅ Ｃｌｉｅｎｔ（ＳＣｓ）が、自律型ＩＣカード１，１ａと通信を行う全ての装置、すなわち上述のＩＣカード端末本体３、自律型ＩＣカード１ｂ及び他の通信装置５に対応している。
【００４２】
尚、全体像を容易に把握できるようにするため、目次を付し、説明本体には各構成ごとに見出しを付けた。
【００４３】
目次
１．はじめに
１．１分散環境ノードとしての本発明チップ
１．２本発明チップＩＤで特定する相互認証方式
１．３本発明チップＩＤに基づいたアクセス制御リスト方式による資源保護機構
１．４チップ所有者・価値情報発行者・価値情報利用者に対する総合的アクセス制御の実現
１．５ロールバック可能なトランザクション機構
１．６リンク機能を持った記憶構造
１．７関連チップ体系との整合性
１．８多様なチップに対応したゆるやかな標準化
２．システム仕様
２．１システムアーキテクチャ
２．２本発明チップ識別子（本発明チップＩＤ）
３．本発明チップ概要
３．１本発明チップ
３．２データ構造モデル
３．３本発明チップ ＡＰＩ
３．４認証・アクセス制御・暗号
４．本発明チップ ＡＰＩプロトコル
４．１パケット形式
４．２命令識別子（コマンドＩＤ）一覧
４．３エラーコード一覧
４．４ ＭＡＣ・トレーラ
４．５セッション通信と非セッション型通信
５．ｅＴＰ鍵証明書
セッション構築時における認証時の証明書の利用
１．概要
６．鍵実体
７．本発明標準コンテンツ形式
８．鍵実体による本発明標準コンテンツ操作時の決算処理
９．本発明チップ ＡＰＩ仕様（データ型定義）
１０．本発明チップ ＡＰＩ仕様（命令定義）
１０．１セッション管理命令群
１０．２トランザクション管理命令群
１０．３ファイル管理命令群
１０．４レコード管理命令群
１０．５鍵実体管理命令群
１０．６認証補助管理命令群
暗号実装仕様
１．はじめに
本発明チップ（価値情報付加チップ）は、本発明関連プロジェクトが目指す、超機能分散システムにおいて、価値情報の格納媒体となるコンピュータシステム（例えばＩＣカード等）および、その外部仕様である。今後の技術の進展を想定し、８ビットＣＰＵ版、１６ビットＣＰＵ版、３２ビットＣＰＵ版とそれぞれシリーズ化されており、共通する操作に関しては共通のコマンド及びメッセージフォーマットを提供する。本書は、特に本発明チップ仕様体系の中でも１６ビットＣＰＵ版ＩＣチップを対象ハードウェアとした仕様の概要を説明したものである。
【００４４】
本章では、既存の他の耐タンパーチップと比べた場合の、本発明チップの特長を述べる。
【００４５】
１．１分散環境ノードとしての本発明チップ
本発明チップは従来型のＩＣチップのように、コンピュータの周辺機器として、リーダライタを通して操作されるものではなく、分散環境におけるノードとして設計されている。ネットワーク上のサービス提供モジュールとチップ、チップとカードが対等にｐｅｅｒ−ｔｏ−ｐｅｅｒで通信する。リーダライタ装置は、ＬＡＮとコンタクトレス通信の物理層を橋渡しするゲートウェイ（ブリッジ）となる。
【００４６】
本発明チップアーキテクチャでは、本発明チップは分散システム全体でユニークな識別子（本発明チップＩＤ）を持つ。本発明チップＩＤは、チップを物理的に識別するだけでなく、分散環境上での経路制御にも利用され、認証通信における相手に識別子として利用される。
【００４７】
従って本発明チップの認証の対象は例えば、リーダライタではなく、ネットワークとリーダライタを経由して、チップと情報交換をするネットワーク上の計算実体（Ｃｏｎｔｅｎｔｓ Ｈｏｌｄｅｒｓ）である。
【００４８】
１．２本発明チップＩＤで特定する相互認証方式
本発明チップは、相互認証を行い、正規な実体であることを確認してから通信を行う。本発明チップアーキテクチャでは、アクセス対象である本発明チップ搭載Ｃｏｎｔｅｎｔｓ Ｈｏｌｄｅｒ（ＣＨｓ）も、アクセス側である本発明チップ搭載Ｓｅｒｖｉｃｅ Ｃｌｉｅｎｔ（ＳＣｓ）も、ともに一貫したユニークな識別子（本発明チップＩＤ）を備え、相互認証後には、相手の本発明チップＩＤを確実に把握する。
【００４９】
１．３本発明チップＩＤに基づいたアクセス制御リスト方式による資源確保機構
本発明チップは、相互認証によって本発明チップ ＡＰＩを発行するＳＣを特定する。そこで、本発明チップが持つ資源を保護するために、この本発明チップＩＤに基づいたアクセス制御リストを使う。現在の本発明チップでは、資源に対して、「発行者」（ＩＳＳＵＥＲ）、「所有者」（ＯＷＮＥＲ）といった属性を、本発明チップＩＤで表現している。さらに、アクセス制御リストによって、「発行者」・「所有者」・「それ以外」のＳＣｓが発行できる命令を指定できる。
【００５０】
１．４チップ所有者・価値情報発行者・価値情報利用者に対する統合的アクセス制御の実現
本発明チップでは、価値情報を格納する多様なアプリケーションが実装される可能性がある。価値情報には様々なタイプがあり、例えば、チップ上にある情報でも、以下のようなものが考えられる。
【００５１】
−チップの所有者は変更できずに情報の発行者だけが変更できる情報
（例：電子チケットの座席番号）
−チップの所有者でさえ見せない情報（例：電子チケット変更の鍵）
−チップの所有者だけが完全に制御できる情報（例：所有者の個人情報）
−読むことはだれでもできる情報
本発明チップでは、アクセス制御リストの中で、「所有者」、「発行者」、「その他」のＳＣｓを統一的に扱い、それぞれのもつ権限に応じて、アクセス制御リストを変更するＡＰＩを発行することによって、アクセス権限の制御や解放、委譲といった制御を柔軟に行うことを可能にしている。
【００５２】
１．５ロールバック可能なトランザクション機構
本発明チップに価値情報を移動する時は、安全に行う必要がある。そこで、本発明チップでは、特に価値情報の作成と削除に関しては、処理のＡｔｏｍｉｃｉｔｙを保証するために、トランザクション機構を提供している。トランザクションを開始したあと、発行された命令による操作は、トランザクション終了時のコミット命令によって反映される。アボート命令が発行された場合、また規定したタイムアウト時間に達するまでコミット命令が到着しない場合は、発行された命令に関してロールバック（ｒｏｌｌ−ｂａｃｋ）される。同様に、トランザクション途中に、何らかのトラブルによって、本発明チップが電源遮断された場合は、次に本発明チップがアクティブになった初期時にロールバック処理が行われる。
【００５３】
１．６リンク機能を持った記憶構造
現在、耐タンパーチップは、情報処理能力においても記憶容量などの資源においても多様なものが存在する。その中でも、資源に乏しいハードウェアでは、想定するアプリケーションの全ての価値情報をチップに格納できないケースもある。一方、チップがそれぞれ分散して価値情報を保持する方式も、処理効率の観点から望ましい。そこで、本発明ではコンテンツを複数の本発明コンテンツホールダ、例えば、本発明チップとネットワーク上の価値情報格納サーバー、の間で分散して保持する、ハイブリッド方式をサポートし、そのための機構として、コンテンツ間のリンク機能を提供している。
【００５４】
１．７関連チップ体系との整合性
本発明チップはＡＰＩのコマンドコンベンション、エラーコード、資源の静的・動的な扱い方の方法などを本発明関連プロジェクトの他のアーキテクチャと整合性を持たせている。例えば、エラーコードの一般的な部分は関連チップと本発明チップは共通である。これによって、関連チップアーキテクチャ上での開発経験のある技術者が本発明チップアプリケーションを開発することを支援する。
【００５５】
１．８多様なチップに対応したゆるやかな標準化
本発明チップは、８ｂｉｔＣＰＵ〜３２ｂｉｔＣＰＵ、Ｃｏｎｔａｃｔ／Ｃｏｎｔａｃｔ−ｌｅｓｓ／Ｄｕａｌ Ｉｎｔｅｒｆａｃｅ、スマートカード〜ＲＦ ＩＤと、様々なＩＣカードに対して、整合性のある一貫したＡＰＩの体系を提供する。
【００５６】
２．システム仕様
２．１システムアーキテクチャ
本発明チップアーキテクチャは、耐タンパ性を有する価値情報を安全に格納し、コンピュータネットワーク上を安全に交換するための分散システムアーキテクチャであり、主に、以下の要素から構成される。
【００５７】
（Ａ）価値情報ネットワーク系（Ｅｎｔｉｔｙ Ｎｅｔｗｏｒｋ Ｉｎｆｒａｓｔｒｕｃｔｕｅｒ）
価値情報を交換するためのアーキテクチャ。以下の二つの要素から構成される。
【００５８】
Ａ−ｉ）本発明チップ搭載コンテンツホールダ（ＣＨｓ）
本発明チップ搭載コンテンツホールダは、価値情報を格納し、本発明チップ搭載 ＡＰＩを提供してこの価値情報を外部から操作させる、分散システム上の計算実体で。例として、以下のようなものがある。
【００５９】
本発明チップ：
価値情報を安全に格納する、耐タンパ性を有するＬＳＩチップである。
【００６０】
本発明チップボックス：
価値情報を安全に格納する、耐タンパをもった筺体に収められた大容電子金庫。
【００６１】
Ａ−ｉｉ）本発明チップ搭載サービスクライアント（ＳＣｓ）
本発明チップ搭載コンテンツホールダに格納された価値情報に本発明チップ ＡＰＩを介してする計算実体。例えば、以下のようなタイプがある。
【００６２】
本発明チップ：
本発明チップ自体も高度なものはクライアントとしての機能ももつ。
【００６３】
発行サーバ：
価値情報を発行し本発明チップ搭載コンテンツホールダに格納する。
【００６４】
サービス現場システム：
本発明チップに格納された価値情報を用いたアプリケーションシステム。電子チケットのゲートなどが含まれる。
【００６５】
※本発明チップ搭載サービスクライアント且つ本発明チップボックスである計算実体も存在することに注意。
【００６６】
（Ｂ）暗号／認証ネットワーク系（ＡＥＮＩ：Ａｕｔｈｅｎｔｉｃａｔｉｏｎ／Ｅｎｃｒｙｐｔｉｏｎ Ｎｅｔｗｏｒｋ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）
本発明チップが公開鍵暗号系の認証及び暗号を実装した場合の、認証系。認証局が主な役割となる
（Ｃ）アプリケーションネットワーク系（ＡＮＩ：Ａｐｐｌｉｃａｔｉｏｎ Ｎｅｔｗｏｒｋ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）
アプリケーションに依存した各種通信系。例えば、電子チケットであれば、チケットの検索や購入を指示するネットワークプロトコルなどが含まれる。この購入の指示までがＡＮＩの枠組みで行われ、その後、価値情報であるチケット本体の移動は、本発明チップの機能を使ったＥＮＩで行われる。
【００６７】
２．２本発明チップ識別子（本発明チップＩＤ）
本発明チップ搭載コンテンツホールダとサービスクライアントは、ユニークな識別子をもち、それぞれ本発明チップ識別子（本発明チップＩＤ）と呼ぶ。本発明チップ識別子は、ネットワーク上で、本発明チップコンテンツホールダやサービスクライアントの認証、メッセージの経路制御などに用いられる。本発明チップＩＤは、１６オクテット（１２８ビット）数で表現される。
【００６８】
※本発明チップＩＤは、ＥＮＩでの通信プロトコルで用いられる識別子の交換フォーマットであり、その本発明チップ内での内部保存形式を定めるものではない。
【００６９】
※経路制御の実装の容易性を考慮すると、ＥＮＩのネットワーク層のプロトコルにおける識別子を直接本発明チップＩＤとする実装方法も考えられる。たとえば、ネットワークアドレスの下位ビットがそのまま本発明チップＩＤであるなど。
【００７０】
※所有者の本発明チップＩＤは、「０ｘ００〜００」（ａｌｌ”０”）とする。
【００７１】
例えば、Ｘという本発明チップＩＤをもった本発明チップ搭載サービスクライアントが所有者認証モードで認証されてセッションをはり、そのセッションの中でファイルを作ったとき、そのファイルの発行者ＩＤ欄は「０」が格納されるものとする。
【００７２】
※管理運用のスーパーユーザの本発明チップＩＤは「０ｘｆｆ〜ｆｆ」（ａｌｌ”１”）とする。
【００７３】
３．本発明チップ概要
３．１本発明チップ
本発明チップは、価値情報を用いた各種会社サービスを直接享受する利用者が価値情報を携帯するために用いる小型計算実体であり、本仕様書が主に扱う対象である。通常、ＩＣカード、スマートカード、携帯型端末といったハードウェア上に実装されることが多いと考えられている。これらのハードウェアには、備えている情報処理能力や資源の差が大きいこと、耐タンパーチップ技術が発展段階であることを考慮し、本発明チップの仕様は、様々なハードウェアに応じた、多様な仕様を提供し、インタフェースのみを共通化し、シリーズ化を図る。
【００７４】
【表１】
３．２データ構造モデル
本発明チップボックスや本発明チップに格納される価値情報は、次の階層的なデータ構造として外部から見えるものとする。
【００７５】
●フォールダ
複数のファイルのセットをまとめる構造。
【００７６】
本発明チップ／１６にルートフォルダだけが存在する。
【００７７】
●ファイル
価値情報を格納する資源。ファイルの中にはレコードが格納されるが、本発明チップ／１６では、一つのファイルに単一のレコードだけが格納される構造をとる。
【００７８】
３．３本発明チップ ＡＰＩ
本発明チップは、本発明チップ搭載サービスクライアントから、本発明チップＡＰＩによって動作する。
【００７９】
本発明チップ ＡＰＩは、基本的に、以下の手順によるセッションベースのプロトコルである。
【００８０】
−本発明チップと本発明チップ搭載サービスクライアントの相互認証と暗号通信路の確立
→セッション（トランザクション）の確立
−命令メッセージの送付
−セッション（トランザクション）の切断
※セッション／トランザクション方式はメッセージ交換回数が多くなるため、＆ゴーのような高応答性が求められる応用に適さないことがある。そこで、命令メッセージ毎に認証や暗号を適用する。非セッションプロトコルも一部の命令に関して取り入れる。
【００８１】
※ ｓｅｓｓｉｏｎ ＩＤ＝０で発行した命令は、非セッションモードとして扱われる。
【００８２】
■セッション命令
ｅｏｐｎ ｓｅｓ Ｏｐｅｎ Ｓｅｓｓｉｏｎ
ｅｃｆｍ ｓｅｓ Ｃｏｎｆｉｒｍ Ｓｅｓｓｉｏｎ
ｅｃｌｓ ｓｅｓ Ｃｌｏｓｅ Ｓｅｓｓｉｏｎ
■トランザクション命令
ｅｏｐｎ ｔｒａ Ｏｐｅｎ Ｔｒａｎｓａｃｔｉｏｎ
ｅｃｆｍ ｔｒａ Ｃｏｎｆｉｒｍ Ｔｒａｎｓａｃｔｉｏｎ
ｅｃｏｍ ｔｒａ Ｃｏｍｍｉｔ Ｔｒａｎｓａｃｔｉｏｎ
ｅａｂｏ ｔｒａ Ａｂｏｒｔ Ｔｒａｎｓａｃｔｉｏｎ
■ファイル操作命令
ｅｃｒｅ ｆｉｌ Ｃｒｅａｔｅ Ｆｉｌｅ
ｅｄｅｌ ｆｉｌ Ｄｅｌｅｔｅ Ｆｉｌｅ
ｅｔｒａ ｆｉｌ Ｔｒａｎｓｆｅｒ Ｆｉｌｅ
ｅｕｐｄ ｆｉｍ Ｕｐｄａｔｅ Ｆｉｌｅ Ｍｏｄｅ
ｅｅｎｃ ｆｉｌ Ｅｎｃｏｄｅ Ｆｉｌｅ
ｅｄｅｃ ｆｉｌ Ｄｅｃｏｄｅ Ｆｉｌｅ
■レコード操作命令
ｅｕｐｄ ｒｅｃ Ｕｐｄａｔｅ Ｒｅｃｏｒｄ
ｅｒｅａ ｒｅｃ Ｒｅａｄ Ｒｅｃｏｒｄ
■鍵実体操作命令
ｅｃｒｅ ｋｅｙ Ｃｒｅａｔｅ Ｋｅｙ
ｅｄｅｌ ｋｅｙ Ｄｅｌｅｔｅ Ｋｅｙ
ｅｕｐｄ ｋｅｙ Ｕｐｄａｔｅ Ｋｅｙ
■認証補助命令
ｅｃｆｍ ｃｅｒ Ｃｏｎｆｉｒｍ Ｃｅｒｔｉｆｉｃａｔｅ
■制御命令
ｅｐｏｌ ｃｈｐ Ｐｏｌｌｉｎｇ Ｃｈｉｐ
ｅｉｎｉ ｃａｒ Ｉｎｉｔｉａｌｉｚｅ Ｃａｒｄ
ｅｕｐｄ ｃｅｒ Ｕｐｄａｔｅ Ｍｙ Ｃｅｒｔｉｆｉｃａｔｅ
ｅｕｐｄ ｃｐｋ Ｕｐｄａｔｅ ＣＡ Ｐｕｂｌｉｃ Ｋｅｙ
３．４認証・アクセス制御・暗号
セッションを構築するときに、本発明チップと本発明チップ搭載サービスクライアントが相互認証を行う。この認証の具体的アルゴリズムは、チップに搭載されているハードウェア等に特化して、多様なものが使えるものとする。
【００８３】
●認証モード
認証には（情報）発行者モードと所有者モードのモードがあり、認証時に指定され、各モードによって認証アルゴリズムが（一般的には）異なる。
【００８４】
（情報）発行者モード：
本発明チップ搭載サービスクライアントをファイルの発行者として認証するモード。発行者のモードで認証された後は、その本発明チップサービスクライアントが作成したファイルには、発行者権限でアクセスでき、それ以外の資源には、その他権限でアクセスすることができる。
【００８５】
所有者のモード：
本発明チップ搭載サービスクライアントをチップの所有者として認証するモード。通常、パスワード等、人間にとって扱いやすい認証方法が使われる。所有者モードで認証された本発明チップ搭載サービスクライアントは所有者権限を持つ。
【００８６】
●相互認証後の本発明チップの状態
認証が終了すると、本発明チップは、以下の情報を保持することになる。
【００８７】
−正規に認証された本発明チップ搭載サービスクライアントの本発明チップＩＤ −本発明チップ搭載サービスクライアントへ送るメッセージの暗号共通鍵
−本発明チップ搭載サービスクライアントから来たメッセージの復号共通鍵
−セッションＩＤ
−セッションモード（発行者モード／所有者モード）
●アクセス制御
チップ、ファイル（、レコード）には、
−発行者を表す本発明チップＩＤ
−アクセス制御リスト（権限毎に許可されている操作）
がつけられており、以下で定めるセッションがもつ権限に応じて、アクセスが制限される。
【００８８】
●ファイルアクセスモード
本発明チップＩＤ＝ｅｉｄのＳＣが、本発明チップ内のファイルＦ（Ｆを作成した本発明チップＳＣの本発明チップＩＤ＝Ｆ．ｅｉｄ）をアクセスするモードには、以下の３種類がある。
【００８９】
１．所有者アクセス
所有者認証を通過してセッション中でのアクセス。
【００９０】
※この場合、ｅｉｄ＝０ｘ００（ａｌｌ”０）である。
【００９１】
２．（情報）発行者アクセス
（情報）発行者認証を通過したセッション中から、
ｅｉｄ＝＝Ｆ．ｅｉｄの場合のアクセス。
【００９２】
３．その他のアクセス
（情報）作成者認証を通過したセッション中で、
ｅｉｄ ！＝Ｆ．ｅｉｄの場合のアクセス、
もしくは、
非セッションモードによるアクセス。
【００９３】
●ルートフォルダへのアクセス制御リスト
【表２】
※所有者アクセスで、ルートフォルダーにファイルを作ることを許可するか
ＡＣＬ１ ＝０／１ ｅｃｒｅ ｆｉｌその他アクセス不可／可
※所有者アクセス以外で、ルートフォルダーにファイルを作ることを許可するかどうか
ＡＣＬ２ ＝０／１ ｅｄｅｌ ｆｉｌ所有者アクセス不可／可
※所有者アクセスで、ルートフォルダーからファイルを消すことを許可するか
ＡＣＬ３ ＝０／１ ｅｄｅｌ ｆｉｌその他アクセス不可／可
※所有者アクセス以外で、ルートフォルダからファイルを消すことを許可するかどうか
ＡＣＬ４ ＝０／１ ｅｔｒａ ｆｉｌ所有者アクセス不可／可
※所有者アクセスで、ルートフォルダーからファイルを転送することを許可するかどうか
ＡＣＬ５ ＝０／１ ｅｔｒａ ｆｉｌその他アクセス不可／可
※所有者アクセス以外で、ルートフォルダからファイルを転送することを許可するかどうか
【表３】
【００９４】
※つまり、価値情報をルートフォルダにファイル／鍵実体を作成する一般の価値情報サーバは、ルートフォルダによっては、「その他アクセス」に相当する
●ファイルへのアクセス制御リスト
【表４】
ＡＣＬ１ ＝０／１ ｅｕｐｄ ｒｅｃその他アクセス不可／可
ＡＣＬ２ ＝０／１ ｅｒｅａ ｒｅｃ所有者アクセス不可／可
ＡＣＬ３ ＝０／１ ｅｒｅａ ｒｅｃその他アクセス不可／可
ＡＣＬ４ ＝０／１ ｅｕｐｄ ｆｉｍ所有者アクセス不可／可
ＡＣＬ５ ＝０／１ ｅｕｐｄ ｆｉｍその他アクセス不可／可
ＡＣＬ６ ＝０／１ ｅｌｓｔ ｆｉｌ所有者アクセス不可／可
ＡＣＬ７ ＝０／１ ｅｌｓｔ ｆｉｌその他アクセス不可／可
ＡＣＬ８ ＝０／１ ｅｄｅｌ ｆｉｌ所有者アクセス不可／可
ＡＣＬ９ ＝０／１ ｅｄｅｌ ｆｉｌその他アクセス不可／可
ＡＣＬａ ＝０／１ ｅｔｒａ ｆｉｌ所有者アクセス不可／可
ＡＣＬｂ ＝０／１ ｅｔｒａ ｆｉｌその他アクセス不可／可
ＡＣＬｃ ＝０／１ ｅｅｎｃ ｆｉｌ所有者アクセス不可／可
ＡＣＬｄ ＝０／１ ｅｅｎｃ ｆｉｌその他アクセス不可／可
ＡＣＬｅ ＝０／１ ｅｄｅｃ ｆｉｌ所有者アクセス不可／可
ＡＣＬｆ ＝０／１ ｅｄｅｃ ｆｉｌその他アクセス不可／可
【表５】
【表６】
ＡＣＬ１ ＝０／１ ｅｕｐｄ ｋｅｙその他アクセス不可／可
ＡＣＬ２ ＝０／１ ｅｒｅａ ｋｅｙ所有者アクセス不可／可
ＡＣＬ３ ＝０／１ ｅｒｅａ ｋｅｙその他アクセス不可／可
ＡＣＬ４ ＝０／１ ｅｕｐｄ ｋｙｍ所有者アクセス不可／可
ＡＣＬ５ ＝０／１ ｅｕｐｄ ｆｉｍその他アクセス不可／可
ＡＣＬ８ ＝０／１ ｅｄｅｌ ｋｅｙ所有者アクセス不可／可
ＡＣＬ９ ＝０／１ ｅｄｅｌ ｋｅｙその他アクセス不可／可
ＡＣＬｃ ＝０／１ ｅｅｎｃ ｆｉｌ所有者アクセス不可／可
ＡＣＬｄ ＝０／１ ｅｅｎｃ ｆｉｌその他アクセス不可／可
ＡＣＬｅ ＝０／１ ｅｄｅｃ ｆｉｌ所有者アクセス不可／可
ＡＣＬｆ ＝０／１ ｅｄｅｃ ｆｉｌその他アクセス不可／可
【表７】
４．１パケット形式
※パケット形式右に、「□」は暗号セッション時に、非暗号化部分、
「■」は暗号化する部分、
※オクテット以上の数値データは、Ｌｉｔｔｌｅ Ｅｎｄｉａｎで格納する。
【００９５】
ルーティング・ヘッダ
【表８】
【表９】
【表１０】
【表１１】
【００９６】
４．２命令識別子（コマンドＩＤ）一覧
本発明チップ ＡＰＩの命令識別子（コマンドＩＤ）は正の１バイト整数で表現される。
【００９７】
本発明チップ／８，１６，３２のシリーズで共通に定められており、以下の通りである。
【００９８】
【表１２】
※本発明チップ／１６第一バージョンでは実装せず。
【００９９】
４．３エラーコード一覧
本発明チップにおける命令のエラーコードは、符号付き整数で表される。操作が正常に終了したときは、Ｅ＿ＯＫ＝０または、操作の結果を表す正の数が返される。正常に終了せず、何かのエラーがあった場合には、負の数を返す。エラーコードは以下のコンベンションで表現される。
【０１００】
・”Ｅ＿”と書かれたものは、チップ中のローカルな命令処理時に起きる一般的なエラーを表す（関連チップのエラーコードと共通）。
【０１０１】
・”ＥＮ＿”と書かれたものは、通信関連の一般的なエラーを表す（セッションエラー以外は、関連チップのエラーコードと共通）。
【０１０２】
・”ＥＥ＿”と書かれたものは、主に、セキュリティー関連の一般的なエラーを表す（本発明チップ専用）。
【０１０３】
【表１３】
４．４ ＭＡＣ・トレーラ
【表１４】
【表１５】
ＣＲＣ−ＣＣＩＴＴにおける生成多項式
Ｇ（Ｘ）＝Ｘ＾１６＋Ｘ＾１２＋Ｘ＾５＋１
※パケットサイズが奇数の場合、後ろのバイトをｎｕｌｌ ｐａｄｄｉｎｇしてからＣＲＣをとる。
【０１０４】
【表１６】
セッション／トランザクション暗号通信路で用いる
暗号通信路の秘密鍵暗号の鍵の始めの６４バイトを鍵Ｋとして用いる、
ＨＭＡＣは以下の式で計算する。
【０１０５】
【０１０６】
Ｋ＝Ｒａ｜Ｒｂ｜Ｒａ｜Ｒｂ｜Ｒａ｜Ｒｂ｜Ｒａ｜Ｒｂ
【表１７】
本発明チップとの通信では、「相互認証」後に「暗号」通信路としてのセッション／トランザクションが確立し、以後「暗号」化されたメッセージ通信を行う。ｅｒｅａ ｒｅｃ命令（レコードの内容を読む）に関しては、「認証」のフェーズを経ずに、直接実行する非セッション型通信をサポートする。この時、セッションを張らずに命令をｓｅｓｓｉｏｎ ＩＤ＝０で呼び出すことで起動できる。この非セッション型通信によるアクセスは、そのファイルが「その他アクセス」を許可していれば成功する。この時、アクセスパケットは暗号化されない。これは、チケットのゲーティングなどの、タッチ＆ゴー応用の必要性が高い場所で用いられる。
【０１０７】
※サービス提供者は、このモードを使うことにより、リスクは高くなる。以下の音源チップを搭載しています。
【０１０８】
５．ｅＴＰ鍵証明書
セッション構築時における認証時の証明書の利用
１．概要
本発明チップ／１６ではセッションを構築する時に相互認証は、公開鍵ベースかつ、ＰＫＩの存在を前提とする。
【０１０９】
−本発明チップ搭載ＣＨｓ、本発明チップ搭載ＳＣｓには、それぞれ本発明チップＩＤが割り振られ、発行時に、認証用の公開鍵／秘密鍵の対が割り当てられている。
【０１１０】
−セッション・トランザクション構築時に、正規に発行された（本発明チップＩＤ、公開鍵）対を持っていることを相互に示すことができるように、常に本発明チップ搭載ＣＨ、本発明チップ搭載ＳＣ内部に本発明チップ搭載ＣＡの署名付の証明書を格納している。
【０１１１】
※本発明チップ搭載ＣＡは、将来的には複数あることが想定されるが、本バージョンでは一つに制限する。
【０１１２】
−証明書は、本発明チップＩＤ、公開鍵のペア、（ｉｄ，ＰＫ ｉｄ）が正規に発行されたものであることを、本発明チップ搭載ＣＡの署名（Ｓ ｃａ（ｉｄ，ＰＫ ｉｄ））が証明する。
【０１１３】
２．詳細
本発明チップ搭載ノード（ここで、本発明チップ搭載ＳＣと本発明チップ搭載ＣＨ両方を総称してそう呼ぶ）は、認証段階の前段階として、相手のデバイスとの間で、相互に自らの本発明チップの公開鍵を本発明チップデバイス発行者の署名つき証明書として送付する※注１）。
【０１１４】
本発明チップ搭載ノードは、証明書発行者の署名鍵の公開鍵を証明書形式で所有する。この鍵を使って正当性を確認する。
【０１１５】
「相手ノードから送られてきた公開鍵の正当性」
＝「発行者の正規な署名があること」＋「証明書が有効期間内であること」
を検証する※注２）。
【０１１６】
正当であることが確認できない場合にはセッションを確立せずに、通信を打ち切る※注３）。
【０１１７】
※注１）
公開鍵ベースの認証において、その後のセッションで、高価な価値の転送／交換の場合には、証明書が「廃止・破棄」されている場合も考慮する。本発明チップ／１６では、
１． ＣＲＬ（破棄リスト）を使う（ただしデータが大きくなる）
または
２．特定の証明書が「廃止・破棄」されているかを照会するサーバーアクセスの利用を行なう。
【０１１８】
※注２）
注１で述べた用に、これに加えて証明書の「廃止・破棄」の問い合わせを行なうこともできる。
【０１１９】
※注３）
証明書の正当性の確認が終了する前に、とりあえず認証のステップを開始して、相手に認証に必要なパケットを送信している間、あるいは相手からの認証に必要なパケットを待っている間に別タスクによっての正当性を確認する実装が有効である。チップ内で割り込みやマルチタスクＯＳが実現されている必要があるが、認証全体の処理時間を短く実装するために有効な手段である。
【０１２０】
上の説明は、本発明チップやカードのようなノードの通信の初期の設定にかかる時間の減らす工夫である。サーバーマシン上に実装されたノードは、不正な証明書をもつ装置から不正は証明書の送付によるサーバ問い合わせ処理の浪費というＤｏＳを防ぐため、必ず最初に証明書の署名確認をオフラインで済ませてから「廃止・破棄」を確認した方が良い。
【０１２１】
ｅＴＰ鍵証明書のフォーマット（ｖｅｒ．０．１）
【表１８】
証明書形式のバージョン番号。ｖｅｒ．０．１ではｖｅｒ＝”１”とする。
【０１２２】
・証明書番号：
その本発明チップＩＤに対する鍵の証明書シリアル番号。
【０１２３】
・署名法：
署名アルゴリズム指定子
０：証明書のｋｅｙフィールド部分までをＳＨＡ−１ハッシュし、結果をＲＳＡ暗号化（実装）
１：予約
２：予約
３：予約
・発行者ＩＤ：
証明書の発行者（ＣＡ局）ＩＤ。ｖｅｒ．０．１では”０”に固定。
【０１２４】
・有効期間開始、有効期限終了：
証明書の有効期間。
【０１２５】
符号なし４オクテット整数（２０００年１月１日ＡＭ０：００からの秒数の積算）
・ＣＡＫＥＹ＃：
ＣＡが鍵の署名に複数の鍵を使っている場合に、それを区別するための鍵のＩＤ番号。ｖｅｒ．０．１では”０”に固定。
【０１２６】
・キー長さ：
後ろのつく鍵のビット長サイズ
※証明書中で、鍵が８オクテットの倍数にならない場合、それを格納するｋｅｙフィールドの最後に”０”を付加し（ｎｕｌｌ ｐａｄｄｉｎｇ）８オクテットの倍数データとして格納する。ｋｅｙフィールドの中の「キー長さ」ビットが有効な鍵である。
【０１２７】
・署名長：
最後につく署名に使うハッシュ（ｓｈａ−１など）のビット長
※ハッシュは、必要であれば最後にｎｕｌｌ ｐａｄｄｉｎｇして８オクテットの倍数のデータとしてから、ＣＡの鍵で暗号化して署名を作成する。
【０１２８】
署名を確認する時には、最後につくこの８オクテットの整数倍のデータを、本発明チップ搭載ノードが保存するＣＡサーバーの公開鍵で復号する。その復号値の中で、先頭の署名長ビットが確認に用いるハッシュ値となる。
【０１２９】
・具体的な長さの例：（ＲＳＡ／ｓｈａ−１署名を使った場合）
−ＲＳＡ
本発明チップ認証公開鍵はＲＳＡで１０２４ビットとする。
【０１３０】
１０２４ｂｉｔｓ＝１２８ｂｙｔｅｓ＝１６×８ｂｙｔｅｓである。
【０１３１】
ｓｈａ−１を署名のためのハッシュ関数として使う。
【０１３２】
− ｓｈａ−１
ｓｈａ−１の出力は１６０ｂｉｔｓ．
１６０ｂｉｔｓ＝２０ｂｙｔｅｓ．
このバイト長をｎｕｌｌ ｐａｄｄｉｎｇして８の倍数にして２４バイトデータをＲＳＡ暗号で署名する。
【０１３３】
証明書全体の長さは以下のように計算できる。
【０１３４】
証明書の長さは
・固定長部分（４０バイト）
鍵の部分の部分の長さ
・署名部分（１２８バイト）
の和（１６８バイト）になる。
【０１３５】
署名の部分は暗号結果は１０２４ビットを必要とするので、１２８バイトの長さを使う。
【０１３６】
ただし、鍵の部分は単純に１２８バイトとはならないので注意されたい。
【０１３７】
これはＲＳＡ鍵の場合、公開鍵として１０２４ビットと俗称している場合には１０２４ｂｉｔｓのＮと指数ｅ（ｅ，Ｎ）の対を念頭においており、鍵の部分には（ｅ，Ｎ）両方を入れる必要があるためである。
【０１３８】
ＲＳＡの場合、鍵フィールドには以下のようにｅ，Ｎを入れることにする。
【０１３９】
ｅのバイト長：（１バイト）
ｅの値そのもの：必要に応じてバイト単位まで広げてバイト列として埋める。これに続けてＮの値をバイト列として埋める。
【０１４０】
（ｅ，Ｎ）でｅ＝３の場合を例として考えてみると、鍵のフィールドには以下のように１３０バイトのバイトデータが入る。
【０１４１】
公開鍵＝０ｘ０１｜０ｘ０３｜Ｎのバイト列（１２８バイト）
１３０は、８の倍数でないので、１３６バイトまでパディングされて鍵データの占めるバイトは１３６となる。
【０１４２】
これで全体長が計算できる。
【０１４３】
固定長部分 （ ４０バイト）
＋鍵の部分の占める長さ（１３６バイト）
＋署名部分 （１２８バイト）
＝３０４バイト
このようにｅ＝３の場合には、長さは総計で３０４バイトとなる。
【０１４４】
６．鍵実体
鍵実体は、本発明チップが通常のファイルに格納する、暗号鍵及び暗号鍵を使った価値情報操作に必要な情報をまとめたシステムデータ形式である。
【０１４５】
【表１９】
ＫＥＹ（１）、ＫＥＹ（２）が、どの暗号アルゴリズムの鍵であるかを指定する。以下の通り、ｅｏｐｎ ｓｅｓにおける暗号通信路の暗号アルゴリズム指定と同じ方式で指定する。
【０１４６】
【表２０】
標準コンテンツ形式は、本発明チップ内で価値情報操作を行なうことができる。標準コンテンツデータ形式である。鍵実体を操作することによって、暗号／復号操作を加え、その際に鍵実体の内部の課金情報をアトミックに変更することができる。
【０１４７】
基本的に、暗号化されたコンテンツを復号化する時に課金するという販売モデムを本発明チップの内部で確実に行なうことを想定している。
【０１４８】
■コンテンツ形式全体
【表２１】
【表２２】
【表２３】
【表２４】
（Ｄ）署名トレーラ
【表２５】
【０１４９】
ＨＭＡＣ ｗｉｔｈ ＭＤ５［ＲＦＣ ２０８５］の場合の６４バイトの秘密鍵として、本コンテンツに含まれている暗号化ＫＥＹ（１）と暗号化ＫＥＹ（２）を、鍵実身の鍵で復号したＫ１、Ｋ２を使い、Ｋを以下の方法で生成する。
【０１５０】
Ｋ＝Ｋ１｜Ｋ２｜Ｋ１｜Ｋ２｜Ｋ１｜Ｋ２｜Ｋ１｜Ｋ２
■課金ヘッダ
【表２６】
【表２７】
本発明チップのパケットと同様の仕様
８．鍵実体による本発明標準コンテンツ操作時の決算処理
鍵実体を使った計算方法は、以下の方式をとる。
【０１５１】
（１）本発明暗号化コンテンツの課金ヘッダの課金額（本発明チップ／１６では、固定額のみ）を算出
（２）鍵実体のＭＯＮＥＹフィールドから、決算額の減算処理を行なう。
【０１５２】
９．本発明チップ ＡＰＩ仕様（データ型定義）
Ｂ 符号付き１バイト整数
ＵＢ 符号なし１バイト整数
Ｈ 符号付き２バイト整数
ＵＨ 符号なし２バイト整数
本発明チップＩＤ １６バイト整数
ＳＩＤ 符号なし１バイト整数（Ｓｅｓｓｉｏｎ Ｉｄ）
ＦＩＤ 符号なし２バイト整数（Ｆｉｌｅ／Ｆｏｌｄｅｒ Ｉｄ）
ＲＩＤ 符号なし２バイト整数（Ｒｅｃｏｒｄ Ｉｄ）
ＣＡＣＬ 符号なし２バイト整数（Ｃｈｉｐ Ａｃｃｅｓｓ Ｃｏｎｔｏｒｌ Ｌｉｓｔ）
ＦＡＣＬ 符号なし２バイト整数（Ｆｉｌｅ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｌｉｓｔ）
ＫＥＹＡＣＬ 符号なし２バイト整数（Ｋｅｙ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｌｉｓｔ）
ＴＩＭＥ 符号なし４バイト整数（２０００年１月１日ＡＭ０：００からの秒数の積算）
ＥＲＲ 符号つき２バイト整数
●Ｃ言語表現による定義例
１０．１セッション管理命令群
セッション構築
Ｏｐｅｎ／Ｃｏｎｆｉｒｍ Ｓｅｓｓｉｏｎ
［機能概要］
本発明チップに対して安全なセッション通信路を構築する。１パスで済む認証を用いる場合は、ｅｏｐｎ ｓｅｓを、２パス必要な認証を用いる場合はｅｏｐｎ ｓｅｓとｅｃｎｆ ｓｅｓをこの順序で用いる。
【０１５３】
このセッション構築によって、Ｃａｌｌｅｒである本発明チップ搭載サービスクライアント側と、Ｃａｌｌｅｅ側である本発明チップ側とでセッション中のみ有効な一時的な共通暗号鍵が共有される。
【０１５４】
認証の方式、暗号の種類は、パケット内のパラメータよって選択可能。本発明チップ側で利用できない認証／暗号が指定された場合はエラーとなる。
【０１５５】
［関数表記］
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ａｕｔｈＭｏｄｅ 認証モードを指定
ａｕｔｈＡｌｇｏｒｉｔｈｍ 認証に使うアルゴリズムの指定子
ｓｅｓｓｉｏｎＡｌｇｏｒｉｔｈｍ 認証後のセッションにおける暗号アルゴリズムの指定子
ｌｅｎ 行きのパケット長（オクテット数）
ａｕｔｈＤａｔａ 認証用に本発明チップ搭載サービスクライアントから本発明チップに渡すデータ（ｌｅｎ−１６）
ｒｌｅｎ 戻りパケット長（オクテット長）
ｒＡｕｔｈＤａｔａ 認証用に本発明チップから本発明チップ搭載サービスクライアントに戻されたデータ（ｒｌｅｎ−８）
［パラメーター値］
□ａｕｔｈＭｏｄｅ
０ｘ０１ ＩＳＳＵＥＲ 発行者モード
０ｘ０２ ＯＷＮＥＲ 所有者モード
□ａｕｔｈＡｌｇｏｒｉｔｈｍ
０ｘ０１ 予約
０ｘ０２ ＲＳＡ（証明書を使ったオフライン認証）
０ｘ０３ ＲＳＡ（ＣＲＬを確認するオンライン認証）
０ｘ０４ 予約
□ｓｅｓｓｉｏｎＡｌｇｏｒｉｔｈｍ
０ｘ０１ ＤＥＳ
０ｘ０２ ３ＤＥＳ
０ｘ０３ 予約
０ｘ０４ 予約
０ｘ０５ 予約
［返り値］
１パス認証の場合
＞ ０ セッションＩＤ（正常終了時）
＜ ０ エラーコード
２パス認証の場合
＜＝ ０ エラーコード
［送りパケット形式］
【表２８】
【表３０】
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｌｅｎ 行きのパケット長（オクテット数）
ａｕｔｈＤａｔａ 認証用に本発明チップ搭載サービスクライアントから本発明チップに渡すデータ（ｌｅｎ−１２）
ｒｌｅｎ 戻りパケット長（オクテット数）
ｒＡｕｔｈＤａｔａ 認証用に本発明チップから本発明チップ搭載サービスクライアントに戻されたデータ（ｒｌｅｎ−８）
［返り値］
＞ ０ セッションＩＤ（正常終了時）
＜ ０ ラーコード
［送りパケット形式］
【表３２】
【表３４】
ｏｐｅｎ／ｃｏｎｆｉｒｍ ｓｅｓｓｉｏｎ命令は、本発明チップ搭載サービスクライアントと本発明チップが相互認証した上で安全な暗号通信路としてのセッションを確立する。具体的な動作は、認証・暗号方式に依存し、その方式は多くの場合本発明Ｎチップハードウェアの暗号支援機能に依存する（実装依存）。セッション確立プロトコルは、発行者モードによる認証と、所有者モードによる認証があり、ｏｐｅｎ ｓｅｓｓｉｏｎ命令のａｕｔｈｍｏｄｅパラメータによって区別される。
【０１５６】
■公開鍵暗号による発行者モード（ａｕｔｈｍｏｄｅ＝ＩＳＳＵＥＲ）認証
【表３６】
《パラメータ例》
・ａｕｔｈＭｏｄｅ ０ｘ０２ （ＩＳＳＵＥＲ）
・ａｕｔｈＡｌｇｏｒｉｔｈｍ ０ｘ０３ （ＲＳＡ：ＣＲＬを確認するオンライン認証）
・ｓｅｓｓｉｏｎＡｌｇｏｒｉｔｈｍ ０ｘ０２ （３ＤＥＳ）
・ａｕｔｈＤａｔａ ＡのｅＴＰ公開鍵証明書
・ＭＡＣトレーラ チェックサム
《Ｂの動作》
・ＡのｅＴＰ証明書の正当性の確認
− ｅＴＰ証明書の期限確認
− ＣＡ局の公開鍵でｅＴＰ証明書の署名を確認→（２）へ
− ＣＲＬリストを確認
・Ａの公開鍵を取り出す
（２）ｅｃｆｍ ｃｅｒ（Ｂ→ＣＲＬ Ｒｅｐ．Ｓｅｒｖｅｒ）
《パラメータ例》
・ｃｈｅｃｋＭｏｄｅ ０ｘ００
・ｃｅｒｔｉｆｉｃａｔｅＩｄ ＊＊＊＊＊＊＊＊＊＊＊
・ＭＡＣトレーラ チェックサム
（３）ｅｃｆｍ ｃｅｒ（Ｂ←ＣＲＬ Ｒｅｐ．Ｓｅｒｖｅｒ）
《パラメータ例》
・Ｅｒｒｏｒ Ｃｏｄｅ Ｅ＿ＯＫ ｏｒ ｎｏｔ
・ＭＡＣトレーラ チェックサム
（４）ｅｏｐｎ ｓｅｓ（Ａ←Ｂ）
《パラメータ例》
・Ｅｒｒｏｒ Ｃｏｄｅ Ｅ＿ＯＫ ｏｒ ｎｏｔ
・ａｕｔｈＭｏｄｅ ０ｘ０２（ＩＳＳＵＥＲ）
・ａｕｔｈＡｌｇｏｒｉｔｈｍ ０ｘ０３（ＲＳＡ：ＣＲＬを確認するオンライン認証）
・ｓｅｓｓｉｏｎＡｌｇｏｒｉｔｈｍ ０ｘ０２（３ＤＥＳ）
・ａｕｔｈＤａｔａ １．ＢのｔＴＰ公開鍵証明書
２．６４ビットの乱数ＲｂをＡの公開鍵でＲＳＡ暗号化したもの
・ＭＡＣトレーラ チェックサム
《Ａ側の動作》
・ＲのｅＴＰ証明書の正当性の確認
− ｅＴＰ証明書の期限確認
− ＣＲＬリストを確認→（５）へ
− ＣＡ局の公開鍵でｅＴＰ証明書の署名を確認
・証明書からＢの公開鍵を取り出す
・ａｕｔｈＤａｔａ２．で受信した乱数ＲｂをＡの秘密鍵で復号化して取り出す
・取り出した乱数Ｒｂはセッション暗号の３ＤＥＳの秘密鍵の一部にする。
【０１５７】
・取り出した乱数Ｒｂのデジタル署名をＡの秘密鍵で作成する。
【０１５８】
（５）ｅｃｆｍ ｃｅｒ（Ａ→ＣＲＬ Ｒｅｐ．Ｓｅｒｖｅｒ）
《パラメータ例》
・ｃｈｅｃｋＭｏｄｅ ０ｘ００
・ｃｅｒｔｉｆｉｃａｔｅＩｄ ＊＊＊＊＊＊＊＊＊＊＊
・ＭＡＣトレーラ チェックサム
（６）ｅｃｆｍ ｃｅｒ（Ａ←ＣＲＬ Ｒｅｐ．Ｓｅｒｖｅｒ）
《パラメータ例》
・Ｅｒｒｏｒ Ｃｏｄｅ Ｅ＿ＯＫ ｏｒ ｎｏｔ
・ＭＡＣトレーラ チェックサム
（７）ｅｃｆｍ ｓｅｓ（Ａ→Ｂ）
《パラメータ例》
・ａｕｔｈＤａｔａ １．６４ビットのＲａをＢの公開鍵でＲＳＡ暗号化したもの、
と、
２．Ｂから受け取った乱数の、Ａの秘密鍵によるデジタル署名を、Ｂの公開鍵でＲＳＡ暗号化したものを、アペンドして送る
・ＭＡＣトレーラ チェックサム
《Ｂ側の動作》
・ａｕｔｈＤａｔａで受信したデータをＡの公開鍵で復号化してＲａとデジタル署名を取り出す
・取り出したＲａはセッション暗号の３ＤＥＳの秘密鍵の一部にする。
【０１５９】
・取り出したＲａのデジタル署名をＢの秘密鍵で作成する。
【０１６０】
・取り出した署名をＡの公開鍵で確認する。
【０１６１】
（８）ｅｃｆｍ ｓｅｓ（Ｃａｌｌｅｒ←Ｃａｌｌｅｅ）
《パラメータ例》
・Ｅｒｒｏｒ Ｃｏｄｅ Ｅ＿ＯＫ ｏｒ ｎｏｔ
・ａｕｔｈＤａｔａ Ａから受け取った乱数Ｒａの、Ｂの秘密鍵によるデジタル署名
・ＭＡＣトレーラ チェックサム
《Ａ側の動作》
・受け取った署名をＢの公開鍵で確認する。
【０１６２】
■（補足）認証アルゴリズムの詳細
■アルゴリズム詳細
・暗号・認証の鍵
秘密鍵ｓｋ＝ｄ
公開鍵ｐｋ＝（ｅ，ｎ）
・平文ｍに対する暗号アルゴリズム
Ｅ ｐｋ（ｍ）＝ｍ＾ｅ ｍｏｄｎ
・暗号文ｃに対する復号アルゴリズム
Ｄ ｓｋ（Ｃ）＝ｃ＾ｄ ｍｏｄｎ
・メッセージＭに対する署名生成アルゴリズム
ｆ ｓｋ（Ｍ）＝（ｈ（Ｍ））＾ｄ ｍｏｄｎ
※但し、ここでｈ（Ｍ）はＭＤ５やＳＨＡ−１などのハッシュ関数
・メッセージＭに対する署名ｓの検証アルゴリズム
ｇ ｐｋ（Ｍ，ｓ）＝ｉｆ（ｈ（Ｍ）＝＝ｓ＾ｅ ｍｏｄｎ）ｔｈｅｎ １ ｅｌｓｅ ０ ｅｎｄｉｆ
■各ノードが所有する情報一覧
・ＣＡ局（Ｃ）
ＣＡの公開鍵 ｐｋ ｃ （１３０Ｂ）
ＣＡの秘密鍵 ｓｋ ｃ （１２８Ｂ）
・Ｃａｌｌｅｒ側（Ａ）
Ａの公開鍵 ｐｋ ａ （１３０Ｂ）
Ａの秘密鍵 ｓｋ ａ （１２８Ｂ）
Ａの証明書 ｃｅｒ ａ （３０４Ｂ）
Ａの証明書におけるＣＡ局の署名 ｓ （ａ，ｃ） （１２８Ｂ）
ＣＡ局の公開鍵 ｐｋ ｃ （１３０Ｂ）
相互認証中に発生する乱数 Ｒａ （８Ｂ）
・Ｃａｌｌｅｅ側（Ｂ）
Ｂの公開鍵 ｐｋ ｂ （１３０Ｂ）
Ｂの秘密鍵 ｓｋ ｂ （１２８Ｂ）
Ｂの証明書 ｃｅｒ ｂ （３０４Ｂ）
Ｂの証明書におけるＣＡ局の署名 ｓ （ｂ，ｃ） （１２８Ｂ）
ＣＡ局の公開鍵 ｐｋ ｃ （１３０Ｂ）
相互認証中に発生する乱数Ｒｂ （８Ｂ）
■ｅＴＰによるＲＳＡベースの認証アルゴリズム詳細
ｅｏｐｎ ｓｅｓ：（Ａ）→（Ｂ）
［送信情報］ （ｃｅｒ ａ）※計３０４バイト
証明書の期限確認
証明書の署名確認 ｇ （ｐｋ ｃ）（ｃｅｒ ａ，ｓ （ａ，ｃ））証明書のＣＲＬを確認
ｅｏｐｎ ｓｅｓ：（Ａ）←（Ｂ）
［送信情報］ （ｃｅｒ ｂ｜ｒｂ） ※計４３２バイト
［Ａの動作］
証明書の期限確認
証明書の署名確認 ｇ （ｐｋ ｃ）（ｃｅｒ ｂ，ｓ （ｂ，ｃ）） 証明書のＣＲＬを確認
メッセージ（ｒｂ）の復号 Ｒｂ’＝Ｄ （ｓｋ ａ）（ｒｂ）
受け取った乱数（Ｒｂ’）の署名作成 ｓｒｂ＝ｆ （ｓｋ ａ）（Ｒｂ’）
ｅｃｆｍ ｓｅｓ：（Ａ）→（Ｂ）
［送信情報］ （ｘ ａｌ｜ｘ ａ２） ※計２５６バイト
ｅｃｆｍ ｓｅｓ：（Ａ）←（Ｂ）
［送信情報］ （ｘ ｂ） ※計１２８バイト
Ｂで生成した署名（ｓｒａ） ｘ ｂ＝Ｅ （ｐｋ ａ）（ｓｒａ） ［Ａの動作］
【０１６３】
■セッション確立後の暗号通信パラメータの設定
（例）３ＤＥＳの場合
Ｒａ−Ｒｂ−ＲａによるＥ−Ｄ−Ｅ方式による３ＤＥＳ暗号とする。この時セッションＩＤはｅｏｐｎ ｓｅｓ（）の往パケットのｓｉｄ欄に格納されていた値を利用する。つまり最初の呼び出したｃａｌｌｅｒが指定したｓｅｓｓｉｏｎ ｉｄをそのまま利用することになる。
【０１６４】
（例）ＤＥＳの場合
Ｒｂを鍵としたＤＥＳ暗号とする。
【０１６５】
この時セッションＩＤはＲａを利用する。
【０１６６】
■秘密鍵暗号による所有者モード（ａｕｔｈｍｏｄｅ＝ＯＷＮＥＲ）認証
ｅｏｐｎ ｓｅｓ、ｅｃｆｍ ｓｅｓを用いた２パス式の所有者認証によるセッションの確立動作の例を以下に示す。ここでの方法は、本発明チップが所有者に依存したパスワードを保持し、それを利用して認証を行う。認証が開始された時に、本発明チップが乱数を発生してＲ／Ｗに送信する。その後、Ｒ／Ｗ側でその乱数を用いてパスワードを暗号化して、本発明チップに送る方式を基本とする。
【０１６７】
【表３７】
乱数Ｒａを生成し、
・ＩＤ Ａ
・Ｒａ
をＢに送る。
【０１６８】
（２）ｅｏｐｎ ｓｅｓ（Ａ←Ｂ）
乱数Ｒｂを生成し、
・Ｘ１＝Ｅ１ Ｋｅｙ（ＩＤ Ａ｜Ｒａ）
・Ｘ２＝Ｅ２ Ｐ（Ｐｂ）
を計算し、Ａに戻す
（３）ｅｃｆｍ ｓｅｓ（Ａ→Ｂ）
ア．Ｄ１ Ｋｅｙ（Ｘ１）で復号して、Ｒａを確認する
（正しい本発明チップであることを認証）。
【０１６９】
イ．Ｒ Ｂ＝Ｄ２ Ｐ（Ｘ２）を計算しＸ２を復号してＲｂを取り出す。
【０１７０】
ウ．Ｒ Ｂを部分ビット反転などで変形したＲ’ｂを生成し、
・Ｙ＝Ｅ３ Ｐ（Ｒ’ｂ）
を生成しＢに送る。
【０１７１】
（４）ｃｅｆｍ ｓｅｓ（Ａ←Ｂ）
Ｄ３ ｐ（Ｙ）で復号して、Ｒ’ｂを確認（正しい所有者が本発明チップ搭載サービスクライアントを経由して操作していることを認証）。
【０１７２】
ＲａからセッションＩＤ（ｓｉｄ）を生成し、Ａに戻す
※ここで、”｜”は、ビット列をａｐｐｅｎｄしてつなげるという意味。例えば、
Ａ＝”０１００１００１１”、Ｂ＝”００１００１０１”であれば、
（Ａ｜Ｂ）＝”０１００１００１１００１００１０１”である。
【０１７３】
※ ＩＤ Ａ，ＩＤ Ｂはそれぞれ、本発明チップ搭載サービスクライアント（Ａ）、本発明チップ
（Ｂ）の本発明チップＩＤ（１２８ビット）である。
【０１７４】
※ Ｅ２をＤＥＳだとするならば、Ｅ３は引数をビット反転してＤＥＳする。
【０１７５】
セッション終了
Ｃｌｏｓｅ Ｓｅｓｓｉｏｎ
［機能概要］
セッションを終了する。
【０１７６】
［関数表記］
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝０ エラーコード
［送りパケット形式］
【表３８】
【表４０】
この命令は、セッションを構築した本発明チップ搭載クライアントであれば、常に利用できる。
【０１７７】
［機能詳細］
確立しているセッションを終了する。
【０１７８】
１０．２トランザクション管理命令群
トランザクションセッションの構築
Ｏｐｅｎ／Ｃｏｎｆｉｒｍ Ｔｒａｎｓａｃｔｉｏｎ
［機能概要］
本発明チップに対してトランザクションセッションを構築する。１パスで済む認証を用いる場合は、ｅｏｐｎ ｔｒａを、２パス必要な認証を用いる場合はｅｏｐｎ ｔｒａとｅｃｎｆ ｔｒａとをこの順序で用いる。
【０１７９】
※基本的な動作は、ｅｏｐｎ ｓｅｓ，ｅｃｆｍ ｓｅｓと同様である。ただ、その後の処理のロールバックが可能になるようになってるところが異なる。
【０１８０】
［関数表記］
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ａｕｔｈＭｏｄｅ 認証モードを指定
ａｕｔｈＡｌｇｏｒｉｔｈｍ 認証に使うアルゴリズムの指定子
ｓｅｓｓｉｏｎＡｌｇｏｒｉｔｈｍ 認証後のセッションにおける暗号アルゴリズムの指定子
ｌｅｎ 行きのパケット長（オクテット数）
ａｕｔｈＤａｔａ 認証用に本発明チップ搭載サービスクライアントから本発明チップに渡すデータ（ｌｅｎ−１６）
ｒｌｅｎ 戻りパケット長（オクテット数）
ｒＡｕｔｈＤａｔａ 認証用に本発明チップから本発明チップ搭載サービスクライアントに戻されたデータ（ｒｌｅｎ−８）
［パラメーター値］
ｅｏｐｎ ｓｅｓ参照
［返り値］
１パス認証の場合
＞０ セッションＩＤ（正常終了時）
＜０ エラーコード
２パス認証の場合
＜＝０ エラーコード
［送りパケット形式］
【表４２】
【表４４】
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｌｅｎ 行きのパケット長（オクテット数）
ａｕｔｈＤａｔａ 認証用に本発明チップ搭載サービスクライアントから本発明チップに渡すデータ（ｌｅｎ−１２）
ｒｌｅｎ 戻りパケット長（オクテット数）
ｒＡｕｔｈＤａｔａ 認証用に本発明チップから本発明チップ搭載サービスクライアントに戻されたデータ（ｒｌｅｎ−８）
［返り値］
＞ ０ セッションＩＤ（正常終了時）
＜ ０ エラーコード
［送りパケット形式］
【表４６】
【表４８】
認証、暗号化に関しては、ｅｏｐｎ ｓｅｓ、ｅｃｆｍ ｓｅｓと同様。
【０１８１】
但し、トランザクションが確立した後は、以下の本発明チップ ＡＰＩだけが発行可能で、その他のものを発行すると、エラーになる。
【０１８２】
・Ｃｒｅａｔｅ Ｆｉｌｅ ｅｃｒｅ ｆｉｌ
．Ｄｅｌｅｔｅ Ｆｉｌｅ ｅｄｅｌ ｆｉｌ
・Ｃｒｅａｔｅ Ｒｅｃｏｒｄ ｅｃｒｅ ｒｅｃ
・Ｄｅｌｅｔｅ Ｒｅｃｏｒｄ ｅｄｅｌ ｒｅｃ
・Ｕｐｄａｔｅ Ｒｅｃｏｒｄ ｅｕｐｄ ｒｅｃ
ここで発行された命令列は、ｅｃｏｍ ｔｒａが発行された時に反映され、ｅａｂｏ ｔｒａが発行された時、または一定時間待ってｅｃｏｍ ｔｒａが発行されずタイムアウトしたときには完全にロールバックすることが保証されなければならない。
【０１８３】
トランザクション終了
Ｃｏｍｍｉｔ／Ａｂｏｒｔ Ｔｒａｎｓａｃｔｉｏｎ
［機能概要］
トランザクションを終了する。コミットして終了する場合、ｅｃｏｍ ｔｒａ、アボートして終了する場合は、ｃａｂｏ ｔａｒを使う。
【０１８４】
［関数表記］
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［送りパケット形式］
【表５０】
【表５２】
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［送りパケット形式］
【表５４】
【表５６】
この命令は、トランザクションを構築した本発明チップ搭載サービスクライアントであれば、常に利用できる。
【０１８５】
［機能詳細］
・確立しているトランザクションをコミット／アボートする。
【０１８６】
・コミットされた場合は、ｅｃｆｍ ｔｒａ〜ｅｃｏｍ ｔｒａの間で発行された命令をすべて、本発明チップの不揮発性記憶に反映させる。
【０１８７】
・アボートされた場合、または一定時間待ってもコミットが来ない時は、 ｔｒａ〜ｅｃｏｍ ｔｒａの間で発行された命令をすべて、本発明チップの不揮発性記憶に反映させる。
【０１８８】
１０．３ファイル管理命令群
［実装制限事項］
本システムにおけるファイルは、以下の制限を持つ。
【０１８９】
・使えるファイルの数の上限 ５０
・ファイルＩＤ ０〜４９
・ファイルのサイズ上限 ２５６（オクテット）
ファイルの作成
Ｃｒｅａｔｅ Ｆｉｌｅ
［機能概要］
（空）ファイルを作成する。
【０１９０】
［関数表記］
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｆｉｄ 作成するファイルＩＤ
ｆａｃｌ ファイルアクセス制御リストの初期値
ｂｌｋ ファイルのスタートアドレス（今回は”１”固定）
ｃｎｔ ファイル長（オクテット数）
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＞ ０ 作成されたファイルＩＤ（正常終了）
＜ ０ エラーコード
［送りパケット形式］
【表５８】
【表６０】
・発行者モード（親フォルダのＩＳＳＵＥＲ本発明チップＩＤ＝Ｓｅｓｓｉｏｎを構築したＳＣの本発明チップＩＤ）であればいつでも利用できる。
【０１９１】
・親フォルダのアクセス制御リストで許可されていれば、所有者モード・他者モードで利用できる。
【０１９２】
［動作の詳細］
ｆｉｄで指定したファイルＩＤを持ったファイルを作成する。指定したｆｉｄが既に利用されている場合はエラーとなる。
【０１９３】
ファイルの削除
Ｄｅｌｅｔｅ Ｆｉｌｅ
［機能概要］
ファイルを削除する。
【０１９４】
［関数表記］
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｆｉｄ 削除するファイルＩＤ
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［送りのパケット形式］
【表６２】
【表６４】
・ｅｄｅｌ ｆｉｌが実行できるためには、以下の条件を満たす必要がある。二種類のアクセス制御リストが関連するので注意が必要である。
【０１９５】
（ＣＡＳＥ１）所有者認証アクセスの場合
１．ルートフォルダが「所有者アクセス」でｅｄｅｌ ｆｉｌできるように許可されてなければならない。つまりルートフォルダのＡＣＬ２＝＝１でなければならない。
【０１９６】
２．対象ファイルが「所有者アクセス」でｅｄｅｌ ｆｉｌできるように許可されてなければならない。つまりそのファイルのＡＣＬ８＝＝１でなければならない。
【０１９７】
（ＣＡＳＥ２）発行者認証アクセスの場合
１．ルートフォルダが「その他アクセス」でｅｄｅｌ ｆｉｌできるように許可されてなければならない。つまりルートフォルダのＡＣＬ３＝＝１でなければならない。
【０１９８】
２．対象ファイル側のＡＣＬには関係しない。（常にＯＫ）
（ＣＡＳＥ３）その他アクセスの場合
１．ルートフォルダが「その他アクセス」でｅｄｅｌ ｆｉｌできるように許可されてなければならない。つまりルートフォルダのＡＣＬ３＝＝１でなければならない。
【０１９９】
２．対象ファイルが「その他アクセス」でｅｄｅｌ ｆｉｌできるように許可されてなければならない。つまりそのファイルのＡＣＬ９＝＝１でなければならない。
【０２００】
［動作の詳細］
ｆｉｄで指定したファイルＩＤを持ったファイルを削除する。ファイルの物理的位置を指す制御ブロックをクリアし、不揮発性記憶領域を解放するだけでなく、中を必ず０クリアまたは１クリアする。
【０２０１】
ファイルの譲渡要求
Ｒｅｑｕｅｓｔ Ｆｉｌｅ Ｔｒａｎｓｆｅｒ
［機能概要］
ファイルの内容を他の本発明チップ搭載コンテンツホールダに譲渡する。
【０２０２】
［関数表記］
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｆｉｄ 作成するファイルＩＤ
ｔａｒｇｅｔＩｄ ファイルの譲渡先の本発明チップＩＤ
ｔａｒｇｅｔＦｉｄ 譲渡するファイルの譲渡先でのファイルＩＤ
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＞ ０ 実際に更新したデータ長（正常終了）
＜ ０ エラーコード
［パケット形式］
【表６６】
【表６８】
このシステムコールが呼ばれたチップは、以下の一連の処理を行う。
【０２０３】
譲渡相手のチップに対して、以下の本発明チップ ＡＰＩ列を発行する。
【０２０４】
・トランザクションセッションをはる。 ｅｏｐｎ ｔｒａ
ｅｃｆｍ ｔｒａ
・ファイルを作成する。 ｅｃｒｅ ｆｉｌ
・レコードを作成する。 ｅｃｒｅ ｒｅｃ
： ：
・トランザクションをコミットする ｅｃｏｍ ｔｒａ
途中で何らかの異常が検知された場合は、トランザクションはアボートされる。また、正常にコミット命令が到達しない限りセッション中の命令が反映されることもない。
【０２０５】
ファイルのデータを暗号化・復号化する
Ｅｎｃｏｄｅ／Ｄｅｃｏｄｅ Ｆｉｌｅ
［機能概要］
本発明暗号化コンテンツが格納されているファイルを復号する。
【０２０６】
［関数表記］
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｓｒｃＦｉｄ 暗号化コンテンツが格納されているファイルＩＤ
ｄｅｓｔＦｉｄ 復号されたコンテンツを格納するファイルＩＤ
ｋｅｙＩｄ 復号処理に使う鍵実体が格納されているファイルＩＤ
ｃｕｒｒｅｎｔＭｏｎｅｙ 鍵実体中に残されている金額残高
ｐａｙｅｄＭｏｎｅｙ 今回決裁した金額
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［パケット形式］
【表７０】
【表７２】
■ｅｄｅｃ ｆｉｌ（）の動作
【表７４】
【表７５】
【０２０７】
※ＫＥＹの暗号化は、指定した鍵実体の鍵で行なう。
【０２０８】
※署名は、暗号化が終了したデータに関して作用する。
【０２０９】
※ ＨＭＡＣ ｗｉｔｈ ＭＤ５の時の６４ビット秘密鍵Ｋは、元のＫＥＹを４回繰り返したものを使う。
【０２１０】
ファイルのアクセス制御リストの変更
Ｕｐｄａｔｅ Ｆｉｌｅ Ｍｏｄｅ
［機能概要］
ファイルのアクセス制御リストを変更する。
【０２１１】
［関数表記］
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｆｉｄ アクセス制御リストの変更対象のファイルＩＤ
ｆｉｌａｃｌ ファイルアクセス制御リストの更新データ
ｃａｌｌｅｒＩｄ 本命令を呼び出す本発明チップ搭載サービスクライアントの本発明チップＩＤ
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［送りパケット形式］
【表７６】
【表７８】
・対象ファイルに対して発行者モード（ファイルのＩＳＳＵＥＲ本発明チップＩＤ＝ｓｅｓｓｉｏｎを構築したＳＣの本発明チップＩＤ）であればいつでも利用できる。
【０２１２】
・対象ファイルのアクセス制御リストで許可されていれば、所有者モード・他者モードで利用できる。
【０２１３】
［機能概要］
ファイルのアクセス制御リストを、指定した値に変更する。
【０２１４】
定義済ファイルのリストを得る
Ｌｉｓｔ Ｆｉｌｅ ＩＤ
［機能概要］
定義済ファイルのリストを得る
［関数表記］
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｆｉｄ 対象のファイルＩＤ
ｆｉｌｅＣｔｒｌＢｌｋ 対象のファイルの制御ブロック
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［送りパケット形式］
【表８０】
【表８２】
・対象ファイルに対して発行者モード（ファイルのＩＳＳＵＥＲ本発明チップＩＤ＝Ｓｅｓｓｉｏｎを構築したＳＣの本発明チップＩＤ）であればいつでも利用できる。
【０２１５】
・対象ファイルのアクセス制御リストで許可されていれば、所有者モード・他者モードで利用できる。
【０２１６】
１０．４レコード管理命令群
レコードのデータを更新
Ｕｐｄａｔｅ Ｒｅｃｏｒｄ
［機能概要］
レコードの内容を変更する。
【０２１７】
［関数表記］
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｆｉｄ 変更するファイルＩＤ
ｂｌｋ 変更するレコード番号（今回は＝１固定）
ｃｎｔ 変更するレコードデータ長（オクテット数）
ｄａｔａ 変更するデータの内容（ｃｎｔオクテット）
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＞ ０ 実際に更新したデータ長（正常終了）
＜ ０ エラーコード
［パケット形式］
【表８４】
【表８６】
・対象レコードに対して発行者モード（レコードのＩＳＳＵＥＲ本発明チップＩＤ＝Ｓｅｓｓｉｏｎを構築したＳＣの本発明チップＩＤ）であればいつでも利用できる。
【０２１８】
・対象レコードのアクセス制御リストで許可されていれば、所有者モード・他で利用できる。
【０２１９】
［動作の詳細］
ｂｌｋレコードで、始めからｃｎｔオクテット分のデータを書き込む要求を出す。ｃｎｔは、ハードウェアの条件によって上限が設けられることがある。実際に書き込まれたオクテット数がｒＣｎｔに返る。
【０２２０】
レコードからデータを読む
Ｒｅａｄ Ｒｅｃｏｒｄ
［機能概要］
レコードの内容を読み出す。
【０２２１】
［関数表記］
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｆｉｄ 読み出すファイルＩＤ
ｂｌｋ 読み出すレコードレＩＤ
ｃｎｔ 読み出すデータの長さ（オクテット数）
ｒＣｎｔ 実際に読み出したデータの長さ（オクテット数）
ｒＤａｔａ 読み出したデータ（ｒＣｎｔオクテット）
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［パケット形式］
【表８８】
【表９０】
・対象レコードに対して発行者モード（レコードのＩＳＳＵＥＲ本発明チップＩＤ ＝Ｓｅｓｓｉｏｎを構築したＳＣの本発明チップＩＤ）であればいつでも利用できる。
【０２２２】
・対象レコードのアクセス制御リストで許可されていれば、所有者モード・他者モードで利用できる。
【０２２３】
［動作の詳細］
ｂｌｋレコードの最初から、ｃｎｔオクテット分のデータを読み込む要求を出す。ｃｎｔは、ハードウェアの条件によって上限が設けられることがある。実際に読み込まれたオクテット数がｒＣｎｔに返る。
【０２２４】
通常は、セッションが確立したところで発行されて実行されるが、タッチ＆ゴー応用の特化し、セッションを確立していない本発明チップ搭載サービスクライアントでも、ｓｉｄ＝０で本命令を呼び出すことができる。この場合、レコードのアクセス制御リストで、その他権限での読み出しが許可されていると、命令の実行は成功する。
【０２２５】
１０．５鍵実体管理命令群
［実装制限事項］
本システムにおける鍵実体は、以下の制限を持つ。
【０２２６】
・使えるファイル数の上限 １０
・鍵実体ＩＤ ０〜９
・鍵実体のサイズ上限 ２５６（オクテット）
鍵実体を作成する
Ｃｒｅａｔｅ Ｋｅｙ Ｏｂｊｅｃｔ
［機能概要］
［関数表記］
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｋｉｄ 鍵実体ＩＤ
ＫｅｙＡｌｇｏｒｉｔｈｍ 暗号アルゴリズム指定子
ｋｅｙ 暗号鍵
ｂａｎｋｌｄ 銀行ＩＤ
ｉｎｉｔＭｏｎｅｙ Ｖａｌ 初期金額
ａｃｌ 初期アクセス制御リスト値（最初のバージョンでは未使用）
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［パケット形式］
【表９２】
【表９４】
Ｄｅｌｅｔｅ Ｋｅｙ Ｏｂｊｅｃｔ
［機能概要］
［関数表記］
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｋｉｄ 削除する鍵実体ＩＤ
ｂａｎｋＩｄ 銀行ＩＤ
ｒｅｍａｉｎｉｎｇＭｏｎｅｙ 残金
ｒｓｉｚｅ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｌｉｓｔの長さ
ｂｏｏｋＬｉｓｔ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｌｉｓｔ
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［パケット形式］
【表９６】
【表９８】
Ｕｐｄａｔｅ Ｋｅｙ Ｏｂｊｅｃｔ
［機能概要］
指定した鍵実体の金額を更新する。
【０２２７】
［関数表記］
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｋｉｄ 更新する鍵実体ＩＤ
ａｄｄＭｏｎｅｙ 加算される金額
ｃｕｒｒｅｎｔＭｏｎｅｙ 加算後の金額
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［パケット形式］
【表１００】
【表１０２】
Ｒｅａｄ Ｋｅｙ Ｏｂｊｅｃｔ
［機能概要］
指定した鍵実体の金額情報を読み出す。
【０２２８】
［関数表記］
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｋｉｄ 金額情報を読み出す対象である鍵実体ＩＤ
ｃｕｒｒｅｎｔＭｏｎｅｙ 現在の金額
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［パケット形式］
【表１０４】
【表１０６】
Ｕｐｄａｔｅ Ｋｅｙ Ｍｏｄｅ
［機能概要］
鍵実体のアクセス制御リストを更新する。
【０２２９】
※最初のバージョンでは未実装
［関数表記］
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｋｉｄ アクセス制御リスト更新する対象である鍵実体ＩＤ
ｋｅｙａｃｌ 更新する鍵実体アクセス制御リスト
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［パケット形式］
【表１０８】
【表１１０】
Ｌｉｓｔ Ｋｅｙ Ｏｂｊｅｃｔ ＩＤ
［機能概要］
定義済鍵実体のリストを得る
［関数表記］
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｋｉｄ 対象の鍵実体ＩＤ
ｋｅｙＣｔｒｌＢｌｋ 対象の鍵実体の制御ブロック
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［送りパケット形式］
【表１１２】
【表１１４】
・対象鍵実体に対して発行者モード（ファイルのＩＳＳＵＥＲ本発明チップＩＤ ＝Ｓｅｓｓｉｏｎを構築したＳＣの本発明チップＩＤ）であればいつでも利用できる。
【０２３０】
・対象鍵実体のアクセス制御リストで許可されていれば、所有者モード・他者モードで利用できる。
【０２３１】
１０．６認証補助管理命令群
ｅＴＰ証明書をチェックする
Ｃｏｎｆｉｒｍ Ｃｅｒｔｉｆｉｃａｔｅ
［関数表記］
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｃｈｅｃｋＭｏｄｅ 破棄リストのチェックモード
ｓｅｒｉａｌ 確認する証明書の証明書番号
ｃａＩｄ 確認する証明書の発行者ＩＤ
ｃｒｌ 破棄リスト（本発明チップ形式）
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［ｃｈｅｃｋＭｏｄｅ］
０ｘ００ チェックだけを返す
０ｘ０１ 対応する破棄リストを得る
［返り値］
＞ ０ セッションＩＤ（正常終了時）
＜ ０ エラーコード
［パケット形式］
【表１１６】
【表１１８】
次に記述するＡＰＩ命令は、その形式は本発明チップ ＡＰＩ命令に準ずるが、必ずしも本発明チップ搭載サービスクライアントだけが発行する命令でなく、他の実体が発行する命令である。主に、ハードウェアに依存した管理、運用、また通信の下位階層をサポートするためのインタフェースが中心である。チップリーダライタユニットが発行したり、製造時のコンピュータが発行するケースがある。
【０２３２】
チップをポリングする
Ｐｏｌｌ ＣＨＩＰ
［機能概要］
本発明チップの状態を読み出す（実装依存、運用依存）。
【０２３３】
［関数表記］
ＥＲＲ ｅｐｏｌ ｃａｒ（ＥＴＲＯＮＩＤ＊ ｄｅｓｔＩｄ，ＥＴＲＯＮＩＤ ｓｒｃＩｄ，ＴＩＭＥ ｔ）； ｄｅｓｔＩｄ ポリングしたときに返されるチップＩＤ
ｓｒｃＩｄ 本命令を呼び出す本発明チップ搭載サービスクライアントの本発明チップＩＤ
ｔ 時刻
［返り値（例）］
＜＝ ０ エラーコード
［パケット形式］
【表１２０】
【表１２２】
【０２３４】
［アクセス制御］
このＡＰＩは、常に利用できる。
【０２３５】
セッション中でなくてもよい。
【０２３６】
［機能の詳細］
ｅｐｏｌ ｃａｒの戻りパケットのルーティングヘッダ部分のｓｒｃＩｄ部分に、チップの本発明チップＩＤを格納して戻すため、誰でも本発明チップのＩＤを最初に取得するために用いることができる。
【０２３７】
セッションの中でなく、誰でも発行できる。
【０２３８】
チップを初期化する
Ｉｎｉｔｉａｌｉｚｅ ＣＨＩＰ
［機能概要］
本発明チップを初期化するために、チップ管理部を作成する。
【０２３９】
［関数表記（例）］
ｔ 時刻
ｉｎｉｔＫｅｙ１ 認証用共通鍵（１）
ｉｎｉｔＫｅｙ２ 認証用共通鍵（２）
ｉｎｉｔＰａｓｓｗｄ 初期パスワード
ｆｉｌｅＮｕｍ チップ内に作成可能なファイル数の上限
ｋｅｙＯｂｊＮｕｍ 鍵実体数の上限
ｓｗａｐＬｅｎ 不揮発性記憶の中のスワップ領域の大きさ
ｃａｃｌ チップのアクセス制御リスト
ｒｓａＳｅｃｒｅｔＫｅｙ 自カードの認証用（ＲＳＡ）秘密鍵
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［パケット形式］
【表１２４】
【表１２６】
与えられた引数に応じて、システム制御ブロックを初期化する。
【０２４０】
その他のメモリ領域は、すべて０クリアする。
【０２４１】
［アクセス制御］
本発明チップのｓｏｕｒｃｅ本発明チップＩＤ＝Ｏｘｆｆ…ｆｆ（ａｌｌ”１”）の時のみ受け付ける。
【０２４２】
自認証公開鍵証明書入換
Ｕｐｄａｔｅ Ｍｙ Ｃｅｒｔｉｆｉｃａｔｅ
［機能概要］
本発明チップ自身の証明書を更新する。
【０２４３】
［関数表記］
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｃｅｒｔｉｆｉｃａｔｅ 証明書
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［パケット形式］
【表１２８】
【表１３０】
【表１３１】
Ｕｐｄａｔｅ ＣＡ Ｐｕｂｌｉｃ Ｋｙｅ
［機能概要］
ＣＡ局の公開鍵交換する。
【０２４４】
［関数表記］
（Ｓｏｕｒｃｅ本発明チップＩＤ）
ｔ 時刻
ｃａＰｕｂｌｉｃＫｅｙ ＣＡ局の公開鍵
ｌｅｎ 行きのパケット長（オクテット数）
ｒｌｅｎ 返りのパケット長（オクテット数）
［返り値］
＜＝ ０ エラーコード
［パケット形式］
【表１３２】
【表１３４】
【表１３５】
■ＤＥＳ
６４ビットの秘密鍵から５６ビットのＤＥＳ鍵の生成方法
以下の通り、各オクテットの最下位ビットをパリティビットとする（しかしチップでは無視するだけでチェックはしない）。上位７ビットを８オクテット分足した５６ビットをＤＥＳとして利用する。
【０２４５】
ＲＳＡ鍵のデータ形式
鍵について、以下のように表現する。
【０２４６】
ｄ＝１０２４ビット（１２８オクテット）
ｎ＝１０２４ビット（１２８オクテット）
ｅ＝０ｘ０００３固定（１オクテット）
秘密鍵ｓｋ＝ｄ（１２８オクテット）
公開鍵ｐｋ＝ｅの長さ（１オクテット）｜ｅ（１オクテット）｜ｎ（１２８オクテット）
【０２４７】
【発明の効果】
以上説明したように、本発明によれば、本発明の自律型ＩＣカードは、ＩＣカード端末を介して接続される通信装置を自ら認識し、その通信装置と直接的に通信を行うので、正確な情報の安全な通信を保証することができる。また、本発明の自律型ＩＣカードが、通信装置と相互に認証処理を行うと共に通信装置との通信に係る情報に対して暗号化／復号化を施す暗号処理部を有する構成とした場合、更に、通信装置の正規性を判断できると共に、その自律型ＩＣカードと、その通信装置との間に物理的に介在する装置によるデータ内容の盗難やデータの改竄の可能性を十分に低減することができる。特に、そのデータが電子チケット等のいわゆる価値情報にかかるものである場合、その意義は大きい。また、暗号処理部が、認識された通信装置の種別に応じて、複数の認証処理及び複数の暗号処理の中から適した認証処理及び暗号処理を選択してそれらの処理を行う場合、認識された通信装置に適した処理を行うことができる。
【図面の簡単な説明】
【図１】本発明におけるＩＣカードの一実施形態の論理的な構成を示す図である。
【図２】本発明の自律型ＩＣカードによるＩＣカード間通信を行うシステムの構成を示す図である。
【図３】本発明の自律型ＩＣカードによる通信を行う他のシステムの構成を示す図である。
【図４】従来におけるＩＣカードとＩＣカード端末との信号のやり取りを説明するための図である。
【図５】従来において、２枚のＩＣカードが互いに通信を行う場合の信号のやり取りを示す図である。
【符号の説明】
１，１ａ，１ｂ 自律型ＩＣカード
２，２ａ，２ｂ ＩＣカードリーダ／ライター
３ ＩＣカード端末本体
４ ネットワーク
５ 通信装置
１０ ＣＰＵ
１１ ＲＯＭ
１２ ＲＡＭ
１３ 不揮発性メモリ
１４ 暗号処理部
１５ 通信制御部
１６ 外部通信インターフェース
１７ ホストデバイスインターフェース
１００ ＩＣカード
１００ａ ＩＣカード
１００ｂ ＩＣカード
２００ ＩＣカードリーダ／ライター
２００ａ ＩＣカードリーダ／ライター
２００ｂ ＩＣカードリーダ／ライター
３００ ＩＣカード端末本体
Claims (9)
- ＩＣカード端末と物理層を介して接続される論理ホストインターフェースと、
前記ＩＣカード端末を物理的に介して接続される通信装置と通信を行うための論理外部通信インターフェースと、
前記論理外部通信インターフェースを介し、前記通信装置の接続を認識し、前記通信装置と直接的に通信を行うように構成されたＩＣチップと、
を備えることを特徴とする自律型ＩＣカード。 - 前記ＩＣチップは、前記論理外部通信インターフェースを介して前記通信装置と直接的に通信を行うためのソフトウェアモジュールたる通信制御部を有することを特徴とする請求項１に記載の自律型ＩＣカード。
- 前記通信制御部は、前記通信装置に対してセッション通信路を構築するセッション管理命令群と、前記通信装置に対してトランザクションセッションを構築するトランザクション管理命令群と、を有することを特徴とする請求項２に記載の自律型ＩＣカード。
- 前記ＩＣチップは、前記通信装置と相互に認証処理を行うと共に、前記通信装置との通信に係る情報に対して暗号化／復号化を施す暗号処理部を有することを特徴とする請求項１に記載の自律型ＩＣカード。
- 前記ＩＣチップは、割り当てられた固有の識別子を有し、その識別子に基づき、前記通信装置を識別し、相互の認証処理を行うことを特徴とする請求項４に記載の自律型ＩＣカード。
- 前記暗号処理部は、認識された前記通信装置の種別に応じて、複数の認証処理及び複数の暗号処理の中から適した認証処理及び暗号処理を選択してそれらの処理を行うことを特徴とする請求項４に記載の自律型ＩＣカード。
- 前記ＩＣチップは、価値情報が格納される記憶部を有し、前記他の通信装置とその価値情報に係る通信を行うことを特徴とする請求項１乃至６に記載の自律型ＩＣカード。
- 前記ＩＣカード端末と前記他の通信装置は、ネットワークを介して接続されていることを特徴とする請求項１乃至７に記載の自律型ＩＣカード。
- 前記論理ホストインターフェース及び前記論理外部通信インターフェースと、前記ＩＣカード端末とは、非接触で接続されることを特徴とする請求項１乃至８に記載の自律型ＩＣカード。
Priority Applications (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002169315A JP4326189B2 (ja) | 2002-06-10 | 2002-06-10 | 自律型ｉｃカード及び通信システム |
| US10/457,512 US7346718B2 (en) | 2002-06-10 | 2003-06-10 | Autonomous integrated-circuit card |
| CNB031379745A CN1241144C (zh) | 2002-06-10 | 2003-06-10 | 自主型集成电路卡 |
| EP03012241A EP1376459A3 (en) | 2002-06-10 | 2003-06-10 | Autonomous integrated-circuit card |
| KR1020030037059A KR100544991B1 (ko) | 2002-06-10 | 2003-06-10 | 자율형 집적회로 카드 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002169315A JP4326189B2 (ja) | 2002-06-10 | 2002-06-10 | 自律型ｉｃカード及び通信システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004013748A true JP2004013748A (ja) | 2004-01-15 |
| JP4326189B2 JP4326189B2 (ja) | 2009-09-02 |
Family
ID=29717429
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002169315A Expired - Fee Related JP4326189B2 (ja) | 2002-06-10 | 2002-06-10 | 自律型ｉｃカード及び通信システム |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US7346718B2 (ja) |
| EP (1) | EP1376459A3 (ja) |
| JP (1) | JP4326189B2 (ja) |
| KR (1) | KR100544991B1 (ja) |
| CN (1) | CN1241144C (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008530936A (ja) * | 2005-02-17 | 2008-08-07 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | デバイスを動作させることのデバイスおよび方法 |
| JP2013011986A (ja) * | 2011-06-28 | 2013-01-17 | Toshiba Corp | メモリデバイス |
Families Citing this family (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7409543B1 (en) * | 2000-03-30 | 2008-08-05 | Digitalpersona, Inc. | Method and apparatus for using a third party authentication server |
| JP3956130B2 (ja) * | 2002-12-25 | 2007-08-08 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 認証装置、認証システム、認証方法、プログラム、及び記録媒体 |
| FR2867930A1 (fr) * | 2004-03-16 | 2005-09-23 | France Telecom | Procede d'authentification anonyme |
| NZ549543A (en) * | 2004-03-22 | 2008-06-30 | Samsung Electronics Co Ltd | Authentication between device and portable storage for digital rights management ( DRM ) |
| US20060047955A1 (en) * | 2004-08-30 | 2006-03-02 | Axalto Inc. | Application code integrity check during virtual machine runtime |
| JP4706220B2 (ja) | 2004-09-29 | 2011-06-22 | ソニー株式会社 | 情報処理装置および方法、記録媒体、並びにプログラム |
| US8281132B2 (en) * | 2004-11-29 | 2012-10-02 | Broadcom Corporation | Method and apparatus for security over multiple interfaces |
| JP5430050B2 (ja) | 2005-06-24 | 2014-02-26 | フェリカネットワークス株式会社 | データ通信システム、ｉｃカード機能を実行するデバイス及びその制御方法、並びに情報処理端末 |
| JP4435084B2 (ja) * | 2005-12-27 | 2010-03-17 | フェリカネットワークス株式会社 | 通信システム，リーダライタ，認証方法，およびコンピュータプログラム |
| JP4896595B2 (ja) * | 2006-01-18 | 2012-03-14 | 株式会社Ｐｆｕ | 画像読取装置およびプログラム |
| JP2008098792A (ja) * | 2006-10-10 | 2008-04-24 | Hitachi Ltd | コンピュータシステムとの暗号化通信方法及びシステム |
| US9082055B2 (en) * | 2008-09-30 | 2015-07-14 | Deutsche Telekom Ag | Method and communication system for the authorization-dependent control of a contactless interface device |
| CN104102611A (zh) * | 2013-04-01 | 2014-10-15 | 深圳市天方信安电子科技有限公司 | 一种具有双系统的电子装置 |
| US10832229B2 (en) * | 2015-12-03 | 2020-11-10 | Mastercard International Incorporated | Translating data signals between a frontend interface and a backend server |
| US10262164B2 (en) | 2016-01-15 | 2019-04-16 | Blockchain Asics Llc | Cryptographic ASIC including circuitry-encoded transformation function |
| KR102436485B1 (ko) * | 2017-11-20 | 2022-08-26 | 삼성전자주식회사 | 전자 장치 및 전자 장치에서 보안 운영체제 기반 데이터 송수신 방법 |
| US10372943B1 (en) | 2018-03-20 | 2019-08-06 | Blockchain Asics Llc | Cryptographic ASIC with combined transformation and one-way functions |
| US10256974B1 (en) * | 2018-04-25 | 2019-04-09 | Blockchain Asics Llc | Cryptographic ASIC for key hierarchy enforcement |
| CN110866291B (zh) * | 2019-11-15 | 2023-03-24 | 北京工业大学 | 一种基于双重安全机制的废旧电子产品信息清除方法 |
Family Cites Families (34)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2601535B1 (fr) * | 1986-07-11 | 1988-10-21 | Bull Cp8 | Procede pour certifier l'authenticite d'une donnee echangee entre deux dispositifs connectes en local ou a distance par une ligne de transmission |
| JPH03144823A (ja) * | 1989-10-31 | 1991-06-20 | N T T Data Tsushin Kk | Ｉｃカードとホスト装置間の通信制御装置 |
| FR2661762B1 (fr) * | 1990-05-03 | 1992-07-31 | Storck Jean | Procede et dispositif de transaction entre un premier et au moins un deuxieme supports de donnees et support a cette fin. |
| GB9112898D0 (en) * | 1991-06-14 | 1991-07-31 | Digital Equipment Int | Communication networks |
| FR2707408B1 (fr) * | 1993-07-09 | 1995-08-18 | Cga Hbs | Procédé pour la transmission rapide et sûre de données contenues dans une carte à puce lors d'une télétransaction. |
| FR2717286B1 (fr) * | 1994-03-09 | 1996-04-05 | Bull Cp8 | Procédé et dispositif pour authentifier un support de données destiné à permettre une transaction ou l'accès à un service ou à un lieu, et support correspondant. |
| US5778071A (en) * | 1994-07-12 | 1998-07-07 | Information Resource Engineering, Inc. | Pocket encrypting and authenticating communications device |
| US5537474A (en) * | 1994-07-29 | 1996-07-16 | Motorola, Inc. | Method and apparatus for authentication in a communication system |
| EP0731583A1 (en) * | 1995-03-08 | 1996-09-11 | International Business Machines Corporation | Method and system for routing messages in a multi-node data communication network |
| JP3519491B2 (ja) * | 1995-03-31 | 2004-04-12 | 株式会社東海理化電機製作所 | Ｉｃカード |
| JP3565967B2 (ja) * | 1995-12-21 | 2004-09-15 | 富士通株式会社 | Ｉｃカード読み取り／書き込み装置及びｉｃカードシステム |
| JPH09190515A (ja) * | 1996-01-11 | 1997-07-22 | Toppan Printing Co Ltd | Ｉｃカードシステムおよびそのデータ伝送方法 |
| FR2743647B1 (fr) * | 1996-01-12 | 1998-02-13 | Bull Cp8 | Coupleur pour gerer une communication entre un support de donnees portable et un dispositif d'echange de donnees, et dispositif d'echange de donnees associe |
| US6073236A (en) * | 1996-06-28 | 2000-06-06 | Sony Corporation | Authentication method, communication method, and information processing apparatus |
| US5923884A (en) * | 1996-08-30 | 1999-07-13 | Gemplus S.C.A. | System and method for loading applications onto a smart card |
| US5901303A (en) * | 1996-12-27 | 1999-05-04 | Gemplus Card International | Smart cards, systems using smart cards and methods of operating said cards in systems |
| US6212649B1 (en) * | 1996-12-30 | 2001-04-03 | Sentar, Inc. | System and method for providing highly-reliable coordination of intelligent agents in a distributed computing system |
| US6182215B1 (en) * | 1997-02-28 | 2001-01-30 | Matsushita Electric Industrial Co., Ltd. | Information devices which select and use one out of plurality of encryption utilization protocols for protecting copyrights of digital productions |
| US6157966A (en) * | 1997-06-30 | 2000-12-05 | Schlumberger Malco, Inc. | System and method for an ISO7816 complaint smart card to become master over a terminal |
| US6073198A (en) * | 1998-03-31 | 2000-06-06 | Micron Electronics, Inc. | System for peer-to-peer mastering over a computer bus |
| US6247644B1 (en) * | 1998-04-28 | 2001-06-19 | Axis Ab | Self actuating network smart card device |
| US6185681B1 (en) * | 1998-05-07 | 2001-02-06 | Stephen Zizzi | Method of transparent encryption and decryption for an electronic document management system |
| JP3713141B2 (ja) * | 1998-05-19 | 2005-11-02 | インターナショナル・ビジネス・マシーンズ・コーポレーション | プログラムの不正実行防止方法 |
| FR2782435B1 (fr) * | 1998-08-13 | 2000-09-15 | Bull Cp8 | Procede de communication entre une station d'utilisateur et un reseau, notamment de type internet, et architecture de mise en oeuvre |
| FR2784479B1 (fr) * | 1998-10-09 | 2000-11-17 | Bull Cp8 | Protocole d'echange interne de donnees entre applications d'un objet portatif multi-applications et objet portatif multi-applications correspondant |
| JP2000353225A (ja) * | 1999-06-11 | 2000-12-19 | Dainippon Printing Co Ltd | Ｉｃカード |
| EP1195713B1 (en) * | 1999-06-23 | 2005-01-12 | Fujitsu Limited | Portable card unit handler |
| US7149816B1 (en) * | 2000-05-16 | 2006-12-12 | Lucent Technologies Inc. | System and method for peer-level communication with a network interface card |
| US20010050989A1 (en) * | 2000-06-07 | 2001-12-13 | Jabari Zakiya | Systems and methods for implementing encryption algorithms |
| US6516997B1 (en) * | 2000-10-30 | 2003-02-11 | Fuji Electric Co., Ltd. | User authentication system |
| US7340748B2 (en) * | 2000-12-21 | 2008-03-04 | Gemplus | Automatic client proxy configuration for portable services |
| DE60128007T2 (de) * | 2000-12-25 | 2007-12-27 | Matsushita Electric Industrial Co., Ltd., Kadoma | Vorrichtung und verfahren zur sicherheitsbearbeitung von kommunikationspaketen |
| EP1237129B1 (en) * | 2001-03-02 | 2004-08-18 | Hitachi, Ltd. | Service providing method |
| US20030037191A1 (en) * | 2001-08-13 | 2003-02-20 | Robert Baranowski | Wireless module |
-
2002
- 2002-06-10 JP JP2002169315A patent/JP4326189B2/ja not_active Expired - Fee Related
-
2003
- 2003-06-10 EP EP03012241A patent/EP1376459A3/en not_active Withdrawn
- 2003-06-10 CN CNB031379745A patent/CN1241144C/zh not_active Expired - Fee Related
- 2003-06-10 KR KR1020030037059A patent/KR100544991B1/ko active IP Right Grant
- 2003-06-10 US US10/457,512 patent/US7346718B2/en not_active Expired - Fee Related
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008530936A (ja) * | 2005-02-17 | 2008-08-07 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | デバイスを動作させることのデバイスおよび方法 |
| JP2013011986A (ja) * | 2011-06-28 | 2013-01-17 | Toshiba Corp | メモリデバイス |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4326189B2 (ja) | 2009-09-02 |
| US20040034766A1 (en) | 2004-02-19 |
| CN1241144C (zh) | 2006-02-08 |
| EP1376459A3 (en) | 2005-09-07 |
| KR20030095344A (ko) | 2003-12-18 |
| US7346718B2 (en) | 2008-03-18 |
| CN1487468A (zh) | 2004-04-07 |
| EP1376459A2 (en) | 2004-01-02 |
| KR100544991B1 (ko) | 2006-01-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP7436568B2 (ja) | ブロックチェーンにより実現される方法及びシステム | |
| JP4326189B2 (ja) | 自律型ｉｃカード及び通信システム | |
| US7844819B2 (en) | Application authentication system | |
| US6484259B1 (en) | Methods and arrangements for mapping widely disparate portable tokens to a static machine concentric cryptographic environment | |
| US8417964B2 (en) | Software module management device and program | |
| CN109479049B (zh) | 用于密钥供应委托的系统、设备和方法 | |
| US8495383B2 (en) | Method for the secure storing of program state data in an electronic device | |
| US20220109667A1 (en) | Cryptographic trust enabled devices of cybersecurity systems | |
| JP5062870B2 (ja) | 任意通信サービスのセキュリティ確保 | |
| JP2004104539A (ja) | メモリカード | |
| JP2003085321A (ja) | コンテンツ利用権限管理システム、コンテンツ利用権限管理方法、および情報処理装置、並びにコンピュータ・プログラム | |
| CN115066863A (zh) | 用于利益拒绝系统中的跨账户设备密钥转移的系统和技术 | |
| JP5391743B2 (ja) | 決済処理セキュリティ情報配信方法、決済処理セキュリティ情報配信システム、そのセンタ装置、サーバ装置、決済端末、及びプログラム | |
| CN116210199A (zh) | 分布式计算系统中的数据管理和加密 | |
| TWI766171B (zh) | 帳戶資料處理方法及帳戶資料處理系統 | |
| JP2003087237A (ja) | コンテンツ利用管理システム、コンテンツ利用管理方法、および情報処理装置、並びにコンピュータ・プログラム | |
| JP2003085143A (ja) | パスワード管理システム、パスワード管理方法、および情報処理装置、並びにコンピュータ・プログラム | |
| JP2004288080A (ja) | Ｉｃカードシステムおよびｉｃカード発行方法 | |
| JP2004252578A (ja) | 提供元のｉｃカード、提供先のｉｃカード、情報授受媒介装置、ｉｃカード間情報授受システム、ｉｃカードプログラム、プログラム及びｉｃカード間情報授受方法 | |
| JP2002217895A (ja) | データ・アプリケーション格納方法及び、コマンド実行方法及びシステム及びデータ・アプリケーション格納プログラム及びデータ・アプリケーション格納プログラムを格納した記憶媒体及びコマンド実行プログラム及びコマンド実行プログラムを格納した記憶媒体 | |
| CN117909961A (zh) | 基于金融软件供应链的程序发布方法及装置 | |
| CN115102737A (zh) | 面向交通一卡通的esam远程发行方法及系统 | |
| JP2005165649A (ja) | データ授受装置 | |
| EP1505473A1 (en) | Methods and arrangements for mapping widely disparate portable tokens to a static machine concentric cryptographic environment | |
| KR20150037787A (ko) | 전자 거래 내역 처리를 직접 수행하는 샘카드를 이용한 전자 거래 수행 장치 및 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050518 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070705 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080722 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080922 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081021 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081222 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20090127 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090330 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20090408 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090512 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090609 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120619 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 4326189 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120619 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130619 Year of fee payment: 4 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313117 |
|
| S533 | Written request for registration of change of name |
Free format text: JAPANESE INTERMEDIATE CODE: R313533 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |