JP3634279B2 - 複数ｉｃカード間及び同一ｉｃカード内のアプリケーション連携方法 - Google Patents
複数ｉｃカード間及び同一ｉｃカード内のアプリケーション連携方法 Download PDFInfo
- Publication number
- JP3634279B2 JP3634279B2 JP2001074144A JP2001074144A JP3634279B2 JP 3634279 B2 JP3634279 B2 JP 3634279B2 JP 2001074144 A JP2001074144 A JP 2001074144A JP 2001074144 A JP2001074144 A JP 2001074144A JP 3634279 B2 JP3634279 B2 JP 3634279B2
- Authority
- JP
- Japan
- Prior art keywords
- card
- application
- memory unit
- signature
- challenge
- 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.)
- Expired - Lifetime
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は、複数のICカード及び同一のICカードに搭載された種々のサービスに供する複数のアプリケーションの連携方法に関するものである。
【０００２】
【従来の技術】
近年、公共、金融、通信、交通、医療の分野、そしてインターネット上の電子商取引等において、セキュリティ上安全で大きな記憶容量を有する耐タンパ性のICカードの利用が広まりつつある。1枚のICカードに複数のサービス提供者からのアプリケーションを搭載し、複数のサービスを利用することができるようにしたマルチアプリケーションICカードシステムも出現している。斯種のICカードシステムでは、カード発行者、サービス提供者及びアプリケーションを審査・保証するための登録・認定機関を核として、サービス提供者及びカード発行者が相互に自由に連携して、利用者に様々なサービスを安全に提供できるようにしている。
【０００３】
斯種のICカードでは、カード内のプログラムと端末・サーバ内のプログラムが高いセキュリティの基で連携して業務処理し得るようになっている。また、カードにはカード発行後にも、それに適応した複数のアプリケーションをダウンロードしたり、ネットワーク端末/ローカル端末などの構成に応じたアプリケーションのダウンロードを可能としている。しかしながら、現状ではまだ、カード発行者、サービス提供者及び登録・認定機関を核としての、各サービス提供者と各カード発行者との相互連携が完全に自由にできるようになっていないため、カード利用者は、異なるサービス提供者からの利用目的に応じたそれぞれ複数のアプリケーションが搭載された複数枚のICカードを利用しなければならない。また、カード利用者によっては１枚のICカードに多数のアプリケーションを搭載することを望まない場合もある。このため、例えばICカードでチケットを購入しようとする場合に、一方のカードには電子マネーサービスを受けるアプリケーションが搭載されているも、電子チケットサービスを受けるためのアプリケーションは別のカードに搭載されている場合には、先ず、これら別個のカードのアプリケーションを認証して、相手のアプリケーションが認証しても良い相手であるかどうかを確認してから連携させなければならない。
【０００４】
また、例えば、電子マネーサービスアプリケーション及び電子チケットサービスアプリケーションが他の複数のアプリケーションと一緒に1枚のICカードに搭載されている場合でも、これらのアプリケーションをお互いに認証してから連携させなければならない。そこで、従来は、耐タンパ性の複数及び同一ICカードにて複数のアプリケーションが連携を行なう場合には、アプリケーションのプログラム内に予め決められた相手とのみ連携を行なうか、又は特に連携先のアプリケーションを特定せずに、制限をつけない場合には、全ての各アプリケーションが他のアプリケーションと連携を行なうことができるようにするか、或いは全ての連携に関してアプリケーション間にて連携について、アプリケーションプログラム内にて予め規定しなければならないと云う制約があった。
【０００５】
【発明が解決しようとする課題】
本発明の目的は、上述したような複数ICカード及び同一カード内のアプリケーションの連携の自由度を向上させることにある。
【０００６】
【課題を解決するための手段】
本発明では、複数の各ICカードに搭載された種々のサービスに供するアプリケーションの連携方法において、各ICカードに搭載される各アプリケーションが予め公開鍵及び秘密鍵を所有し、互いに連携相手のICカードの公開鍵は既知のものとして、各ICカードのアプリケーション用のメモリ部同士間にて証明書及び署名を用いたチャレンジ＆レスポンスを元にした認証作業を行なってアプリケーションの連携を行なうにあたり、先ず連携させるアプリケーションの一方が搭載されている一方のICカードのメモリ部から、乱数又は乱数と時刻により生成したチャレンジを、連携相手のアプリケーションが搭載されている他方のICカードのメモリ部に送信し、該他方のICカードのメモリ部では、送信された前記チャレンジと前記連携相手のアプリケーションの識別子とを当該アプリケーションの秘密鍵で暗号化して、当該アプリケーションの署名を生成すると共に、当該ICカードのメモリ部でも乱数等によりチャレンジを生成し、該チャレンジと前記署名を少なくとも前記当該アプリケーションの証明書、公開鍵及び識別子や、当該カードの公開鍵と共に前記一方のICカードのメモリ部にレスポンスとして送信し、該一方のICカードのメモリ部にて前記他方のICカード側から送信された前記チャレンジや署名に基づいて、前記他方のICカードにおける連携相手のアプリケーションの証明書及び署名をそれぞれ署名検証して、前記一方のICカードにおける前記アプリケーションにとって前記他方のICカードにおける前記連携相手のアプリケーションは信頼できることが認証されたら、前記一方のICカードのメモリ部にて、前記他方のカードのメモリ部にて生成されて送信された前記チャレンジと格納済みの前記一方のICカード側の前記アプリケーションの識別子とを当該アプリケーションの秘密鍵で暗号化して、当該アプリケーションの署名を生成すると共に、該署名を少なくとも当該アプリケーションの識別子、証明書及び公開鍵や当該カードの公開鍵と共に前記他方のICカードのメモリ部に送信し、該他方のICカードのメモリ部では、前記一方のICカード側から送信された少なくとも前記署名、アプリケーションの識別子、証明書及び公開鍵やカードの公開鍵に基づいて、前記他方のICカードにおけるメモリ部にて行なったと同様に署名検証して、双方のアプリケーションを連携させる。
【０００７】
本発明の他の例では、複数の各ICカードに搭載された種々のサービスに供するアプリケーションの連携方法において、互いに連携相手のICカードに搭載されているアプリケーションの識別子は既知のものとして、各ICカードのカードマネージャ同士間にて証明書及び署名を用いたチャレンジ＆レスポンスを元にした認証を行なってアプリケーション間の連携を行なうにあたり、先ず連携させるアプリケーションの一方が搭載されている一方のICカードのカードマネージャから、乱数又は乱数と時刻により生成したチャレンジを連携相手のアプリケーションの識別子と、当該ICカードにおける前記一方のアプリケーションの識別子と共に、前記連携相手のアプリケーションが搭載されている他方のICカードのカードマネージャに送信し、該他方のICカードのカードマネージャでは、前記一方のICカードのカードマネージャから送信された前記一方のICカードにおける前記アプリケーションの識別子を前記他方のICカードにおける連携相手のアプリケーションのメモリリストにて認証して、前記一方のICカードのアプリケーションが認証できる相手であることが確認できたら、前記一方のICカード側から送信された前記チャレンジと前記他方のICカードにおける前記連携相手のアプリケーションの識別子とを前記他方のICカードの秘密鍵で暗号化して、当該カードの署名を生成すると共に、当該ICカード側のカードマネージャでも乱数等によりチャレンジを生成し、該チャレンジと前記署名を前記他方のICカードの証明書及び公開鍵と共に前記一方のICカードのカードマネージャにレスポンスとして送信し、該一方のICカードにおけるカードマネージャでは、前記他方のICカード側から送信された少なくとも前記チャレンジや署名に基づいて、前記他方のICカードの証明書及び前記一方のICカード側から送信した前記チャレンジをそれぞれ署名検証して、前記他方のICカードにおける前記アプリケーションが認証しても良い相手であることが前記一方のアプリケーションのメモリリストにて確認されたら、前記一方のICカード側のカードマネージャにて前記他方のカード側にて生成されて送信された前記チャレンジと前記一方のICカード側の前記アプリケーションの識別子とを当該アプリケーションの秘密鍵で暗号化して、当該カードの署名を生成すると共に、該署名を当該カードの証明書及び公開鍵と共に前記他方のICカードにおけるカードマネージャに送信し、該他方のICカード側では、前記一方のICカード側から送信された少なくとも前記署名や当該カードの証明書及び公開鍵に基づいて、前記一方のICカードにで行なったのと同じようにして署名検証して、双方のアプリケーションを連携させる。
【０００８】
さらに本発明の他の例では、同一のICカードに搭載された種々のサービスに供する複数のアプリケーションの連携方法において、各アプリケーションが予め公開鍵及び秘密鍵を所有し、連携を行なう各アプリケーション用のメモリ部同士間にて証明書及び署名を用いたチャレンジ＆レスポンスを元に、お互いに認証しても良い相手かどうかどうかの認証作業を行なってアプリケーションの連携を行なうにあたり、先ず連携させるアプリケーションの一方が格納されている一方のメモリ部から、乱数又は乱数と時刻により生成したチャレンジを、連携相手のアプリケーションが格納されている他方のメモリ部に送信し、該他方のメモリ部では、送信された前記チャレンジと当該アプリケーションの識別子とを当該アプリケーションの秘密鍵で暗号化して、当該アプリケーションの署名を生成すると共に、当該メモリ部でも乱数等によりチャレンジを生成し、該チャレンジと前記署名を当該ICカードにおけるカードマネージャにて管理されている前記当該アプリケーションの証明書、公開鍵及び識別子と共に前記一方のメモリ部に送信し、該一方のメモリ部にて前記他方のメモリ部から送信された前記チャレンジや署名に基づいて、前記他方のメモリ部における連携相手のアプリケーションを署名検証して、前記一方のメモリ部における前記アプリケーションにとって前記他方のメモリ部における前記連携相手のアプリケーションは信頼できることが認証されたら、前記一方メモリ部にて前記他方のメモリ部にて生成されて送信された前記チャレンジと前記一方のメモリ部の前記アプリケーションの識別子とを当該アプリケーションの秘密鍵で暗号化して、当該アプリケーションの署名を生成すると共に、該署名を当該アプリケーションの証明書及び公開鍵や当該アプリケーションの識別子と共に前記他方のメモリ部に送信し、該他方のメモリ部では、前記一方のメモリ部から送信された少なくとも前記署名、アプリケーションの識別子、証明書及び公開鍵に基づいて前記一方のメモリ部におけるアプリケーションを署名検証して、双方のアプリケーションを連携させる。
【０００９】
本発明のさらに他の例では、同一のICカードに搭載された種々のサービスに供する複数のアプリケーションの連携方法において、連携を行なう各アプリケーション用のメモリ部同士間にてカードマネージャを経由してお互いに認証しても良い相手かどうかどうかの認証作業を行なってアプリケーションの連携を行なうにあたり、先ず連携させるアプリケーションの一方が格納されている一方のメモリ部から、認証先要求情報を前記カードマネージャに送信し、該カードマネージャでは前記一方のメモリ部から送信された前記認証先要求情報に応じて、前記一方のアプリケーションの識別子を連携相手の他方のアプリケーションが格納されているメモリ部へ送信し、該メモリ部では当該アプリケーションにとって前記一方のアプリケーションが認証しても良い相手であるかどうかを前記一方のアプリケーションの識別子により確認し、前記他方のアプリケーションにとって前記一方のアプリケーションが正当な相手であることが確認できたら、その旨を前記カードマネージャに送信し、次いで前記他方のアプリケーションが格納されている前記メモリ部から前記カードマネージャに前記他方のアプリケーションの認証先要求情報を送信し、該認証先要求情報に応じて、前記他方のアプリケーションの識別子を前記一方のアプリケーションが格納されているメモリ部へ送信し、該メモリ部でも同様に当該アプリケーションにとって前記他方のアプリケーションが認証しても良い相手であるかどうかを前記他方のアプリケーションの識別子により確認して、アプリケーションの連携を行なう。
【００１０】
このような本発明による方法によれば、複数カードのアプリケーション間の連携をかなりの自由度を持って行なうことができるようになり、また、同一カードの場合には、複数の認証レベルを持つことが可能である。
【００１１】
【発明の実施の形態】
次ぎに図面を参照して本発明を説明するに、図１は本発明による複数カード内のアプリケーション連携方法に適用するICカードの構成を示した図である。
【００１２】
図１に示すように、ICカード１には、鍵や乱数の生成、アプリケーション（AP）の圧縮演算、APの暗号化・復号化演算処理を行なう演算部１０と；カード１の秘密鍵SkC1、カード1の公開鍵PkC1、連携を行なう相手カード（この場合、ICカード2）の公開鍵PkC2及びカード発行者によりカード発行時にカード独自の公開鍵PkC1で設定されて、カード識別子（CID）と公開鍵との関係で認証されたカード公開鍵証明書L1を管理するカードマネージャ（CM）１１と；サービス提供者から提供されたアプリケーションAP1の秘密鍵SkAp1、公開鍵PkAp1、サービス提供者により認証されたこのアプリケーションAP1に対する公開鍵証明書Lap1及びこのアプリケーションの識別子IDであるAPid1を格納しているアプリケーションAP1用のメモリ部１２；とを用立てる。ICカード２にも同様に、演算部２０と、カードカードマネージャ（CM）２１と、アプリケーションAP2用のメモリ部２２とを用立てる。なお、各カードにはそれぞれ複数のアプリケーションを格納し得ることは明かである。
【００１３】
【実施例１】
図２は、複数カード、例えばICカード１と２との間でアプリケーションAP1とAP2が連携を行なう場合に、各カードのアプリケーション用のメモリ部同士間で証明書及び署名を用いたチャレンジ＆レスポンスを元にした認証を行なってアプリケーションの連携を行なう例のプロトコルを示した図である。なお、この場合には、お互いに相手カードの公開鍵PkCは各カードマネージャCMのメモリに予め記憶しており既知のものとする。
【００１４】
この例では、先ずAP2側にて乱数だけか、又は乱数と時刻等の適当なデータでチャレンジChalla2を生成して、これをカード１側の連携相手であるアプリケーションAP1のメモリ部へ送信する。
【００１５】
カード1のAP1側では、カード２からのチャレンジChalla2を受けると、このChalla2とAP1の識別子（ID）であるAPid1とをAP1の秘密鍵SkAp1で暗号化してAP1の（ディジタル）署名Sap1を生成して、この署名をメモリに格納すると共に、AP1側でも乱数だけか、又は乱数と時刻とでチャレンジChalla1を生成する。次いで、生成した署名Sap1及びチャレンジChalla1を、AP1のメモリ部１２に格納済みのAP1の公開鍵証明書Lap1及びAP1のIDであるAPid1と、カード１のカードマネージャ（CM）のメモリ部に格納済みのカード1の公開鍵証明書（PkC1に対するカード発行者の署名）L1、カード1の公開鍵PkC1、AP1の公開鍵PkAp1と共にAP2側へレスポンスとして送信する。
【００１６】
AP2側では、カード１から送信されたSap1、Lap1、L1、PkC1、PkAp1、APid1及びチャレンジChalla1に基づいて、カード１の公開鍵証明書L１、AP1の公開鍵証明書Lap1及びAP1の署名Sap1をそれぞれ署名検証をする。例えば、カード1の公開鍵証明書L1をカード発行者（I）の公開鍵PkIで検証して、カード１はカード発行者Iから本当に発行されたものであるか、否かを検証し、次ぎに、AP1の公開鍵証明書Lap1をカード１の公開鍵PkC1で検証して、AP1が本当に認証されてカード１に搭載されたアプリケーションであるか、否か等の検証をするのであって、図面ではこのような署名検証処理及び前述したような署名処理を表わすのに下記のような表記法を用いて示してある。
署名:署名＝sig＜署名で使用する鍵＞（署名対象）
署名検証：Verf＜検証用証明鍵＞（署名データ）?=｛署名対象｝
【００１７】
斯くして、カード２のAP2にとってカード１のAP1は信頼できることが認証されたら、今度はカード１側からカード２のAP2を認証するために、まずカード２側にてカード１からのChalla1とAP2のIDであるAPid2とをAP2の秘密鍵SkAp2で暗号化してAP2の（ディジタル）署名Sap2を生成して、この署名をメモリに格納する。次いで、AP2側では、生成した署名Sap2を、格納済みのAP2の公開鍵証明書Lap2及びAP2のIDであるAPid２と、カード２のカードマネージャCMのメモリ部に格納済みのカード２の公開鍵証明書L2、カード２の公開鍵PkC2、AP２の公開鍵PkAp2と共にカード１側へと送信する。
【００１８】
カード１の側では、カード２から送信されたSap2、Lap2、L2、PkC2、PkAp2及びAPid2に基づいて、カード２の公開鍵証明書L2、AP2の公開鍵証明書Lap2及びAP2の署名Sap2をそれぞれAP2側で行なったのと同じようにして署名検証し、AP2が認証しても良い相手であるかどうかを確認して、OK情報をAP２側に送ってからAP1とAP2との連携を行なうようにする。
【００１９】
【実施例２】
図３は、複数カード、例えばICカード１と２との間でアプリケーションAP1とAP2が連携を行なう場合に、各カードのカードマネージャ（CM）同士でチャレンジ＆レスポンスを元にした認証を行なって、アプリケーションの連携を行なう例のプロトコルを示した図である。なお、この例では、お互いに相手のアプリケーションAPのIDであるAPidを各アプリケーションのメモリに予め記憶しており既知のものとする。
【００２０】
この例では、先ずカード２のカードマネージャーCMにて乱数だけか、又は乱数と時刻等の適当なデータでチャレンジChallc2を生成して、これをAP2のメモリリストに予め記憶してある連携先の既知のAP1のIDであるAPid1と、AP2のIDであるApid2と一緒にカード１のカードマネージャCMへ送信する。
【００２１】
カード1のカードマネージャCMでは、カード２からのChalla2、APid1及びAPid2を受け取ると、先ずAPid2をカード1のAP1のメモリリスト等にてAPid2が認証して良い相手かどうかを確認する。APid2が認証できる相手であることが確認されたら、Challc2とAP1のIDであるAPid1とをカード1の秘密鍵SkC1で暗号化してカード1の（ディジタル）署名Sc1（レスポンス）を生成して、この署名をメモリに格納する。次いで、カード1側でも乱数だけか、又は乱数と時刻とでチャレンジChallc1を生成する。そして、カード1のカードマネージャCMは、生成した署名Sc1及びチャレンジChallc1を、カード１のカードマネージャCMのメモリ部に格納済みのカード1の公開鍵証明書L1及びカード1の公開鍵PkC1と共にカード2のカードマネージャCMへと送信する。
【００２２】
カード２のカードマネージャCMでは、カード１から送信されたSc1、L1、PkC1及びチャレンジChallc1に基づいて、カード１の公開鍵証明書L１及びカード1のAPid1とカード2から送ったChallc2をそれぞれ署名検証をする。例えば、カード1の公開鍵証明書L1をカード発行者Iの公開鍵PkIで復号化することによりカード1の公開鍵PkC1を検証して、カード１はカード発行者Iから本当に発行されたものであるか、否かを確かめ、次ぎに、Sc1をPkC1で復号化して、カード2側から送ったChallc2及びカード1からのAPid1を検証して、このAP1が認証しても良い相手であるかどうかをAP2のメモリリスト等にて確認し、AP1が本当に認証されてカード１に搭載されたアプリケーションであるか、否か等の検証をするのであって、図面ではこのような署名検証処理及び前述したような署名処理を表わすのに前記実施例１の場合と同じ表記法を用いて示してある。
【００２３】
斯くして、カード２のアプリケーションAP2にとってカード１のアプリケーションAP1は信頼できることが認証されたら、今度はカード１のカードマネージャCMがカード２のアプリケーションAP2を認証するために、先ずカード２側にてカード１からのChallc1とAP2のIDであるApid2とをカード2の秘密鍵SkC2で暗号化してカード2の（ディジタル）署名Sc2（レスポンス）を生成して、この署名を、カード２のカードマネージャCMのメモリ部に格納済みのカード2の公開鍵証明書L2及びカード２の公開鍵PkC2と共にカード１のカードマネージャCMへと送信する。
【００２４】
カード１のカードマネージャCMでは、カード２側から送信されたSc2、L2及びPkC2に基づいて、カード２の公開鍵PkC2及びカード1側から送ったChallc1とAP2のIDであるAPid2をそれぞれカード２側で行なったのと同じようにして署名検証し、カード２のアプリケーションAP2が認証しても良い相手であることが確認できたら、その旨をカード1のAP1のメモリ部１２へ送信して、レスポンスをAP2に送って、AP1とAP2の連携を行なうようにする。
【００２５】
【実施例３】
図４は、同一カード内のアプリケーションAP1とAP2用のメモリ部同士間でお互いにチャレンジ＆レスポンスを元に署名検証して、アプリケーションの連携を行なう例のプロトコルを示した図である。
【００２６】
この例でも、先ずAP2側にて乱数だけか、又は乱数と時刻等の適当なデータでAP2のチャレンジChalla2を先ず生成して、これを連携相手のAP1のメモリ部へ送信する。
【００２７】
AP1側では、AP2側からのChalla2を受け取ると、このChalla2とAP1のIDであるAPid1とをAP1の秘密鍵SkAp1で暗号化してAP1の（ディジタル）署名Sap1（レスポンス）を生成して、この署名をメモリに格納する。AP1側でも乱数だけか、又は乱数と時刻とでAP1のチャレンジChalla1を生成する。次いで、生成した署名Sap1及びチャレンジChalla1を、カードマネージャCMにて管理されてAP1用のメモリ部に格納済みのAP1の公開鍵証明書Lap1、AP1の公開鍵PkAp1及びAP1のIDであるAPid1と共にAP2側へと送信する。
【００２８】
AP2側では、AP1から送信されたSap1、Challa1、Lap1、PkAp1及びAPid1に基づいて、AP1の公開鍵PkAp1と、APid1及びAP2側から最初に送ったChallc2とをそれぞれ署名検証をする。このようなAP2側での署名検証処理及びAP1側での前記署名処理は、前記実施例１及び２の場合と同じ表記法を用いて図4に示したようにして行なう。斯くして、AP2側にてAP1が認証しても良い相手であることが確かめられたら、今度はAP1側にてアプリケーションAP2を認証するために、AP2側にて、AP1からのChalla1とAP2のIDであるApid2とをAP2の秘密鍵SkAp2で暗号化してAP2の（ディジタル）署名Sap2を生成して、この署名をメモリに格納し、次いでこの署名Sap2をAP2の公開鍵証明書Lap2、AP2の公開鍵PkAp2及びAP2のIDであるAPid2と共にAP1側へと送信する。
【００２９】
AP1側では、AP2から送信されたSsap2、Lap2、PkAp2及びAPid2に基づいて、AP2の公開鍵PkAp2及びAP1側から送ったChalla1とAP2のIDであるAPid2をそれぞれAP2側で行なったのと同じようにして署名検証し、アプリケーションAP2が認証しても良い相手であるかどうかを確認して、連携を行なうようにする。
【００３０】
【実施例４】
図５は、同一カード内のアプリケーションAP1とAP2が連携を行なう場合に、カードにおけるカードマネージャCMは信頼できるものとして、このカードマネージャCMを経由して同じくチャレンジ＆レスポンスを元にした認証を行なってアプリケーションの連携を行なう例のプロトコルを示した図である。この例でも前記実施例1と同様に各アプリケーションAP1及びAP2は予め秘密鍵及び公開鍵を所有するものとする。
【００３１】
この例では、先ずAP2側から認証先要求情報をAP間通信用カードマネージャCMへ送信する（１）。このカードマネージャCMでは、AP2側からの認証先要求に応じて、先ずAP1側にてAP2が認証しても良い相手かどうかをリスト等により確認させるために、AP2のIDであるAPid2をAP1へ送信する（２）。AP1側にてAP2が正当な相手であることが確認できたら、その旨をカードマネージャCMに送り（３）、次いでこのカードマネージャCMを経由してAP1の認証先要求情報をAP2へ送信して（４）、AP2側にてAP1が認証しても良い相手かどうかをリスト等により確認してから連携を行なうようにする。この例の場合には、認証先要求情報を前記他の実施例におけると同様な「チャレンジ＆レスポンス」としてやり取りさせる。
【００３２】
本発明は、上述した例のみに限定されるものでなく、幾多の変更を加え得ること勿論である。例えば、各アプリケーション間の認証をAP2側でAP1を、AP1側でAP2を認証する相互認証の例につき説明したが、連携相手のアプリケーションが信頼できるICカードに搭載されている場合には片側認証でも充分な場合もあることは明かである。また、上述した各実施例では、（ディジタル）署名の生成を秘密鍵を用いて暗号化する場合につき述べたが、ディジタル署名の生成は、署名生成を行なうか、ハッシュを作成することにより行なうこともできることは勿論である。
【００３３】
【発明の効果】
以上説明したように、本発明によれば、異なるICカード間や、同一カード上の複数のアプリケーション間にて認証を行ない、この認証結果に基づいてアプリケーションの連携を行なうことができる。同一カードの場合には、相手の署名を必要としたり、カードマネージャがお墨付けを与えたりするように、複数の認証レベルを持つことが可能である。
【図面の簡単な説明】
【図１】本発明による複数カード内のアプリケーション連携方法に適用するICカードの構成を示した図である。
【図２】複数カードのアプリケーション同士で認証確認して、アプリケーションの連携を行なう例のプロトコルを示した図である。
【図３】複数カードのカードマネージャCM同士で認証確認して、アプリケーションの連携を行なう例のプロトコルを示した図である。
【図４】同一カードのアプリケーション同士で認証確認して、アプリケーションの連携を行なう例のプロトコルを示した図である。
【図５】同一カードのアプリケーション間の認証を信頼できるカードマネージャCM経由で行なって、アプリケーションの連携を行なう例のプロトコルを示した図である。
【符号の説明】
１，２ ICカード
１０，２０ 演算部
１１，２１ カードマネージャCM
１２，２２ アプリケーションメモリ部
SkAp1 アプリケーションAP1の秘密鍵
PkAp1 アプリケーションAP1の公開鍵
Lap1 アプリケーションAP1の公開鍵証明書
Apid1 アプリケーションAP1のID
SkC1 カード１の秘密鍵
PkC2 カード２の公開鍵
L1 カード1の公開鍵証明書
PkC1 カード１の公開鍵
【発明の属する技術分野】
本発明は、複数のICカード及び同一のICカードに搭載された種々のサービスに供する複数のアプリケーションの連携方法に関するものである。
【０００２】
【従来の技術】
近年、公共、金融、通信、交通、医療の分野、そしてインターネット上の電子商取引等において、セキュリティ上安全で大きな記憶容量を有する耐タンパ性のICカードの利用が広まりつつある。1枚のICカードに複数のサービス提供者からのアプリケーションを搭載し、複数のサービスを利用することができるようにしたマルチアプリケーションICカードシステムも出現している。斯種のICカードシステムでは、カード発行者、サービス提供者及びアプリケーションを審査・保証するための登録・認定機関を核として、サービス提供者及びカード発行者が相互に自由に連携して、利用者に様々なサービスを安全に提供できるようにしている。
【０００３】
斯種のICカードでは、カード内のプログラムと端末・サーバ内のプログラムが高いセキュリティの基で連携して業務処理し得るようになっている。また、カードにはカード発行後にも、それに適応した複数のアプリケーションをダウンロードしたり、ネットワーク端末/ローカル端末などの構成に応じたアプリケーションのダウンロードを可能としている。しかしながら、現状ではまだ、カード発行者、サービス提供者及び登録・認定機関を核としての、各サービス提供者と各カード発行者との相互連携が完全に自由にできるようになっていないため、カード利用者は、異なるサービス提供者からの利用目的に応じたそれぞれ複数のアプリケーションが搭載された複数枚のICカードを利用しなければならない。また、カード利用者によっては１枚のICカードに多数のアプリケーションを搭載することを望まない場合もある。このため、例えばICカードでチケットを購入しようとする場合に、一方のカードには電子マネーサービスを受けるアプリケーションが搭載されているも、電子チケットサービスを受けるためのアプリケーションは別のカードに搭載されている場合には、先ず、これら別個のカードのアプリケーションを認証して、相手のアプリケーションが認証しても良い相手であるかどうかを確認してから連携させなければならない。
【０００４】
また、例えば、電子マネーサービスアプリケーション及び電子チケットサービスアプリケーションが他の複数のアプリケーションと一緒に1枚のICカードに搭載されている場合でも、これらのアプリケーションをお互いに認証してから連携させなければならない。そこで、従来は、耐タンパ性の複数及び同一ICカードにて複数のアプリケーションが連携を行なう場合には、アプリケーションのプログラム内に予め決められた相手とのみ連携を行なうか、又は特に連携先のアプリケーションを特定せずに、制限をつけない場合には、全ての各アプリケーションが他のアプリケーションと連携を行なうことができるようにするか、或いは全ての連携に関してアプリケーション間にて連携について、アプリケーションプログラム内にて予め規定しなければならないと云う制約があった。
【０００５】
【発明が解決しようとする課題】
本発明の目的は、上述したような複数ICカード及び同一カード内のアプリケーションの連携の自由度を向上させることにある。
【０００６】
【課題を解決するための手段】
本発明では、複数の各ICカードに搭載された種々のサービスに供するアプリケーションの連携方法において、各ICカードに搭載される各アプリケーションが予め公開鍵及び秘密鍵を所有し、互いに連携相手のICカードの公開鍵は既知のものとして、各ICカードのアプリケーション用のメモリ部同士間にて証明書及び署名を用いたチャレンジ＆レスポンスを元にした認証作業を行なってアプリケーションの連携を行なうにあたり、先ず連携させるアプリケーションの一方が搭載されている一方のICカードのメモリ部から、乱数又は乱数と時刻により生成したチャレンジを、連携相手のアプリケーションが搭載されている他方のICカードのメモリ部に送信し、該他方のICカードのメモリ部では、送信された前記チャレンジと前記連携相手のアプリケーションの識別子とを当該アプリケーションの秘密鍵で暗号化して、当該アプリケーションの署名を生成すると共に、当該ICカードのメモリ部でも乱数等によりチャレンジを生成し、該チャレンジと前記署名を少なくとも前記当該アプリケーションの証明書、公開鍵及び識別子や、当該カードの公開鍵と共に前記一方のICカードのメモリ部にレスポンスとして送信し、該一方のICカードのメモリ部にて前記他方のICカード側から送信された前記チャレンジや署名に基づいて、前記他方のICカードにおける連携相手のアプリケーションの証明書及び署名をそれぞれ署名検証して、前記一方のICカードにおける前記アプリケーションにとって前記他方のICカードにおける前記連携相手のアプリケーションは信頼できることが認証されたら、前記一方のICカードのメモリ部にて、前記他方のカードのメモリ部にて生成されて送信された前記チャレンジと格納済みの前記一方のICカード側の前記アプリケーションの識別子とを当該アプリケーションの秘密鍵で暗号化して、当該アプリケーションの署名を生成すると共に、該署名を少なくとも当該アプリケーションの識別子、証明書及び公開鍵や当該カードの公開鍵と共に前記他方のICカードのメモリ部に送信し、該他方のICカードのメモリ部では、前記一方のICカード側から送信された少なくとも前記署名、アプリケーションの識別子、証明書及び公開鍵やカードの公開鍵に基づいて、前記他方のICカードにおけるメモリ部にて行なったと同様に署名検証して、双方のアプリケーションを連携させる。
【０００７】
本発明の他の例では、複数の各ICカードに搭載された種々のサービスに供するアプリケーションの連携方法において、互いに連携相手のICカードに搭載されているアプリケーションの識別子は既知のものとして、各ICカードのカードマネージャ同士間にて証明書及び署名を用いたチャレンジ＆レスポンスを元にした認証を行なってアプリケーション間の連携を行なうにあたり、先ず連携させるアプリケーションの一方が搭載されている一方のICカードのカードマネージャから、乱数又は乱数と時刻により生成したチャレンジを連携相手のアプリケーションの識別子と、当該ICカードにおける前記一方のアプリケーションの識別子と共に、前記連携相手のアプリケーションが搭載されている他方のICカードのカードマネージャに送信し、該他方のICカードのカードマネージャでは、前記一方のICカードのカードマネージャから送信された前記一方のICカードにおける前記アプリケーションの識別子を前記他方のICカードにおける連携相手のアプリケーションのメモリリストにて認証して、前記一方のICカードのアプリケーションが認証できる相手であることが確認できたら、前記一方のICカード側から送信された前記チャレンジと前記他方のICカードにおける前記連携相手のアプリケーションの識別子とを前記他方のICカードの秘密鍵で暗号化して、当該カードの署名を生成すると共に、当該ICカード側のカードマネージャでも乱数等によりチャレンジを生成し、該チャレンジと前記署名を前記他方のICカードの証明書及び公開鍵と共に前記一方のICカードのカードマネージャにレスポンスとして送信し、該一方のICカードにおけるカードマネージャでは、前記他方のICカード側から送信された少なくとも前記チャレンジや署名に基づいて、前記他方のICカードの証明書及び前記一方のICカード側から送信した前記チャレンジをそれぞれ署名検証して、前記他方のICカードにおける前記アプリケーションが認証しても良い相手であることが前記一方のアプリケーションのメモリリストにて確認されたら、前記一方のICカード側のカードマネージャにて前記他方のカード側にて生成されて送信された前記チャレンジと前記一方のICカード側の前記アプリケーションの識別子とを当該アプリケーションの秘密鍵で暗号化して、当該カードの署名を生成すると共に、該署名を当該カードの証明書及び公開鍵と共に前記他方のICカードにおけるカードマネージャに送信し、該他方のICカード側では、前記一方のICカード側から送信された少なくとも前記署名や当該カードの証明書及び公開鍵に基づいて、前記一方のICカードにで行なったのと同じようにして署名検証して、双方のアプリケーションを連携させる。
【０００８】
さらに本発明の他の例では、同一のICカードに搭載された種々のサービスに供する複数のアプリケーションの連携方法において、各アプリケーションが予め公開鍵及び秘密鍵を所有し、連携を行なう各アプリケーション用のメモリ部同士間にて証明書及び署名を用いたチャレンジ＆レスポンスを元に、お互いに認証しても良い相手かどうかどうかの認証作業を行なってアプリケーションの連携を行なうにあたり、先ず連携させるアプリケーションの一方が格納されている一方のメモリ部から、乱数又は乱数と時刻により生成したチャレンジを、連携相手のアプリケーションが格納されている他方のメモリ部に送信し、該他方のメモリ部では、送信された前記チャレンジと当該アプリケーションの識別子とを当該アプリケーションの秘密鍵で暗号化して、当該アプリケーションの署名を生成すると共に、当該メモリ部でも乱数等によりチャレンジを生成し、該チャレンジと前記署名を当該ICカードにおけるカードマネージャにて管理されている前記当該アプリケーションの証明書、公開鍵及び識別子と共に前記一方のメモリ部に送信し、該一方のメモリ部にて前記他方のメモリ部から送信された前記チャレンジや署名に基づいて、前記他方のメモリ部における連携相手のアプリケーションを署名検証して、前記一方のメモリ部における前記アプリケーションにとって前記他方のメモリ部における前記連携相手のアプリケーションは信頼できることが認証されたら、前記一方メモリ部にて前記他方のメモリ部にて生成されて送信された前記チャレンジと前記一方のメモリ部の前記アプリケーションの識別子とを当該アプリケーションの秘密鍵で暗号化して、当該アプリケーションの署名を生成すると共に、該署名を当該アプリケーションの証明書及び公開鍵や当該アプリケーションの識別子と共に前記他方のメモリ部に送信し、該他方のメモリ部では、前記一方のメモリ部から送信された少なくとも前記署名、アプリケーションの識別子、証明書及び公開鍵に基づいて前記一方のメモリ部におけるアプリケーションを署名検証して、双方のアプリケーションを連携させる。
【０００９】
本発明のさらに他の例では、同一のICカードに搭載された種々のサービスに供する複数のアプリケーションの連携方法において、連携を行なう各アプリケーション用のメモリ部同士間にてカードマネージャを経由してお互いに認証しても良い相手かどうかどうかの認証作業を行なってアプリケーションの連携を行なうにあたり、先ず連携させるアプリケーションの一方が格納されている一方のメモリ部から、認証先要求情報を前記カードマネージャに送信し、該カードマネージャでは前記一方のメモリ部から送信された前記認証先要求情報に応じて、前記一方のアプリケーションの識別子を連携相手の他方のアプリケーションが格納されているメモリ部へ送信し、該メモリ部では当該アプリケーションにとって前記一方のアプリケーションが認証しても良い相手であるかどうかを前記一方のアプリケーションの識別子により確認し、前記他方のアプリケーションにとって前記一方のアプリケーションが正当な相手であることが確認できたら、その旨を前記カードマネージャに送信し、次いで前記他方のアプリケーションが格納されている前記メモリ部から前記カードマネージャに前記他方のアプリケーションの認証先要求情報を送信し、該認証先要求情報に応じて、前記他方のアプリケーションの識別子を前記一方のアプリケーションが格納されているメモリ部へ送信し、該メモリ部でも同様に当該アプリケーションにとって前記他方のアプリケーションが認証しても良い相手であるかどうかを前記他方のアプリケーションの識別子により確認して、アプリケーションの連携を行なう。
【００１０】
このような本発明による方法によれば、複数カードのアプリケーション間の連携をかなりの自由度を持って行なうことができるようになり、また、同一カードの場合には、複数の認証レベルを持つことが可能である。
【００１１】
【発明の実施の形態】
次ぎに図面を参照して本発明を説明するに、図１は本発明による複数カード内のアプリケーション連携方法に適用するICカードの構成を示した図である。
【００１２】
図１に示すように、ICカード１には、鍵や乱数の生成、アプリケーション（AP）の圧縮演算、APの暗号化・復号化演算処理を行なう演算部１０と；カード１の秘密鍵SkC1、カード1の公開鍵PkC1、連携を行なう相手カード（この場合、ICカード2）の公開鍵PkC2及びカード発行者によりカード発行時にカード独自の公開鍵PkC1で設定されて、カード識別子（CID）と公開鍵との関係で認証されたカード公開鍵証明書L1を管理するカードマネージャ（CM）１１と；サービス提供者から提供されたアプリケーションAP1の秘密鍵SkAp1、公開鍵PkAp1、サービス提供者により認証されたこのアプリケーションAP1に対する公開鍵証明書Lap1及びこのアプリケーションの識別子IDであるAPid1を格納しているアプリケーションAP1用のメモリ部１２；とを用立てる。ICカード２にも同様に、演算部２０と、カードカードマネージャ（CM）２１と、アプリケーションAP2用のメモリ部２２とを用立てる。なお、各カードにはそれぞれ複数のアプリケーションを格納し得ることは明かである。
【００１３】
【実施例１】
図２は、複数カード、例えばICカード１と２との間でアプリケーションAP1とAP2が連携を行なう場合に、各カードのアプリケーション用のメモリ部同士間で証明書及び署名を用いたチャレンジ＆レスポンスを元にした認証を行なってアプリケーションの連携を行なう例のプロトコルを示した図である。なお、この場合には、お互いに相手カードの公開鍵PkCは各カードマネージャCMのメモリに予め記憶しており既知のものとする。
【００１４】
この例では、先ずAP2側にて乱数だけか、又は乱数と時刻等の適当なデータでチャレンジChalla2を生成して、これをカード１側の連携相手であるアプリケーションAP1のメモリ部へ送信する。
【００１５】
カード1のAP1側では、カード２からのチャレンジChalla2を受けると、このChalla2とAP1の識別子（ID）であるAPid1とをAP1の秘密鍵SkAp1で暗号化してAP1の（ディジタル）署名Sap1を生成して、この署名をメモリに格納すると共に、AP1側でも乱数だけか、又は乱数と時刻とでチャレンジChalla1を生成する。次いで、生成した署名Sap1及びチャレンジChalla1を、AP1のメモリ部１２に格納済みのAP1の公開鍵証明書Lap1及びAP1のIDであるAPid1と、カード１のカードマネージャ（CM）のメモリ部に格納済みのカード1の公開鍵証明書（PkC1に対するカード発行者の署名）L1、カード1の公開鍵PkC1、AP1の公開鍵PkAp1と共にAP2側へレスポンスとして送信する。
【００１６】
AP2側では、カード１から送信されたSap1、Lap1、L1、PkC1、PkAp1、APid1及びチャレンジChalla1に基づいて、カード１の公開鍵証明書L１、AP1の公開鍵証明書Lap1及びAP1の署名Sap1をそれぞれ署名検証をする。例えば、カード1の公開鍵証明書L1をカード発行者（I）の公開鍵PkIで検証して、カード１はカード発行者Iから本当に発行されたものであるか、否かを検証し、次ぎに、AP1の公開鍵証明書Lap1をカード１の公開鍵PkC1で検証して、AP1が本当に認証されてカード１に搭載されたアプリケーションであるか、否か等の検証をするのであって、図面ではこのような署名検証処理及び前述したような署名処理を表わすのに下記のような表記法を用いて示してある。
署名:署名＝sig＜署名で使用する鍵＞（署名対象）
署名検証：Verf＜検証用証明鍵＞（署名データ）?=｛署名対象｝
【００１７】
斯くして、カード２のAP2にとってカード１のAP1は信頼できることが認証されたら、今度はカード１側からカード２のAP2を認証するために、まずカード２側にてカード１からのChalla1とAP2のIDであるAPid2とをAP2の秘密鍵SkAp2で暗号化してAP2の（ディジタル）署名Sap2を生成して、この署名をメモリに格納する。次いで、AP2側では、生成した署名Sap2を、格納済みのAP2の公開鍵証明書Lap2及びAP2のIDであるAPid２と、カード２のカードマネージャCMのメモリ部に格納済みのカード２の公開鍵証明書L2、カード２の公開鍵PkC2、AP２の公開鍵PkAp2と共にカード１側へと送信する。
【００１８】
カード１の側では、カード２から送信されたSap2、Lap2、L2、PkC2、PkAp2及びAPid2に基づいて、カード２の公開鍵証明書L2、AP2の公開鍵証明書Lap2及びAP2の署名Sap2をそれぞれAP2側で行なったのと同じようにして署名検証し、AP2が認証しても良い相手であるかどうかを確認して、OK情報をAP２側に送ってからAP1とAP2との連携を行なうようにする。
【００１９】
【実施例２】
図３は、複数カード、例えばICカード１と２との間でアプリケーションAP1とAP2が連携を行なう場合に、各カードのカードマネージャ（CM）同士でチャレンジ＆レスポンスを元にした認証を行なって、アプリケーションの連携を行なう例のプロトコルを示した図である。なお、この例では、お互いに相手のアプリケーションAPのIDであるAPidを各アプリケーションのメモリに予め記憶しており既知のものとする。
【００２０】
この例では、先ずカード２のカードマネージャーCMにて乱数だけか、又は乱数と時刻等の適当なデータでチャレンジChallc2を生成して、これをAP2のメモリリストに予め記憶してある連携先の既知のAP1のIDであるAPid1と、AP2のIDであるApid2と一緒にカード１のカードマネージャCMへ送信する。
【００２１】
カード1のカードマネージャCMでは、カード２からのChalla2、APid1及びAPid2を受け取ると、先ずAPid2をカード1のAP1のメモリリスト等にてAPid2が認証して良い相手かどうかを確認する。APid2が認証できる相手であることが確認されたら、Challc2とAP1のIDであるAPid1とをカード1の秘密鍵SkC1で暗号化してカード1の（ディジタル）署名Sc1（レスポンス）を生成して、この署名をメモリに格納する。次いで、カード1側でも乱数だけか、又は乱数と時刻とでチャレンジChallc1を生成する。そして、カード1のカードマネージャCMは、生成した署名Sc1及びチャレンジChallc1を、カード１のカードマネージャCMのメモリ部に格納済みのカード1の公開鍵証明書L1及びカード1の公開鍵PkC1と共にカード2のカードマネージャCMへと送信する。
【００２２】
カード２のカードマネージャCMでは、カード１から送信されたSc1、L1、PkC1及びチャレンジChallc1に基づいて、カード１の公開鍵証明書L１及びカード1のAPid1とカード2から送ったChallc2をそれぞれ署名検証をする。例えば、カード1の公開鍵証明書L1をカード発行者Iの公開鍵PkIで復号化することによりカード1の公開鍵PkC1を検証して、カード１はカード発行者Iから本当に発行されたものであるか、否かを確かめ、次ぎに、Sc1をPkC1で復号化して、カード2側から送ったChallc2及びカード1からのAPid1を検証して、このAP1が認証しても良い相手であるかどうかをAP2のメモリリスト等にて確認し、AP1が本当に認証されてカード１に搭載されたアプリケーションであるか、否か等の検証をするのであって、図面ではこのような署名検証処理及び前述したような署名処理を表わすのに前記実施例１の場合と同じ表記法を用いて示してある。
【００２３】
斯くして、カード２のアプリケーションAP2にとってカード１のアプリケーションAP1は信頼できることが認証されたら、今度はカード１のカードマネージャCMがカード２のアプリケーションAP2を認証するために、先ずカード２側にてカード１からのChallc1とAP2のIDであるApid2とをカード2の秘密鍵SkC2で暗号化してカード2の（ディジタル）署名Sc2（レスポンス）を生成して、この署名を、カード２のカードマネージャCMのメモリ部に格納済みのカード2の公開鍵証明書L2及びカード２の公開鍵PkC2と共にカード１のカードマネージャCMへと送信する。
【００２４】
カード１のカードマネージャCMでは、カード２側から送信されたSc2、L2及びPkC2に基づいて、カード２の公開鍵PkC2及びカード1側から送ったChallc1とAP2のIDであるAPid2をそれぞれカード２側で行なったのと同じようにして署名検証し、カード２のアプリケーションAP2が認証しても良い相手であることが確認できたら、その旨をカード1のAP1のメモリ部１２へ送信して、レスポンスをAP2に送って、AP1とAP2の連携を行なうようにする。
【００２５】
【実施例３】
図４は、同一カード内のアプリケーションAP1とAP2用のメモリ部同士間でお互いにチャレンジ＆レスポンスを元に署名検証して、アプリケーションの連携を行なう例のプロトコルを示した図である。
【００２６】
この例でも、先ずAP2側にて乱数だけか、又は乱数と時刻等の適当なデータでAP2のチャレンジChalla2を先ず生成して、これを連携相手のAP1のメモリ部へ送信する。
【００２７】
AP1側では、AP2側からのChalla2を受け取ると、このChalla2とAP1のIDであるAPid1とをAP1の秘密鍵SkAp1で暗号化してAP1の（ディジタル）署名Sap1（レスポンス）を生成して、この署名をメモリに格納する。AP1側でも乱数だけか、又は乱数と時刻とでAP1のチャレンジChalla1を生成する。次いで、生成した署名Sap1及びチャレンジChalla1を、カードマネージャCMにて管理されてAP1用のメモリ部に格納済みのAP1の公開鍵証明書Lap1、AP1の公開鍵PkAp1及びAP1のIDであるAPid1と共にAP2側へと送信する。
【００２８】
AP2側では、AP1から送信されたSap1、Challa1、Lap1、PkAp1及びAPid1に基づいて、AP1の公開鍵PkAp1と、APid1及びAP2側から最初に送ったChallc2とをそれぞれ署名検証をする。このようなAP2側での署名検証処理及びAP1側での前記署名処理は、前記実施例１及び２の場合と同じ表記法を用いて図4に示したようにして行なう。斯くして、AP2側にてAP1が認証しても良い相手であることが確かめられたら、今度はAP1側にてアプリケーションAP2を認証するために、AP2側にて、AP1からのChalla1とAP2のIDであるApid2とをAP2の秘密鍵SkAp2で暗号化してAP2の（ディジタル）署名Sap2を生成して、この署名をメモリに格納し、次いでこの署名Sap2をAP2の公開鍵証明書Lap2、AP2の公開鍵PkAp2及びAP2のIDであるAPid2と共にAP1側へと送信する。
【００２９】
AP1側では、AP2から送信されたSsap2、Lap2、PkAp2及びAPid2に基づいて、AP2の公開鍵PkAp2及びAP1側から送ったChalla1とAP2のIDであるAPid2をそれぞれAP2側で行なったのと同じようにして署名検証し、アプリケーションAP2が認証しても良い相手であるかどうかを確認して、連携を行なうようにする。
【００３０】
【実施例４】
図５は、同一カード内のアプリケーションAP1とAP2が連携を行なう場合に、カードにおけるカードマネージャCMは信頼できるものとして、このカードマネージャCMを経由して同じくチャレンジ＆レスポンスを元にした認証を行なってアプリケーションの連携を行なう例のプロトコルを示した図である。この例でも前記実施例1と同様に各アプリケーションAP1及びAP2は予め秘密鍵及び公開鍵を所有するものとする。
【００３１】
この例では、先ずAP2側から認証先要求情報をAP間通信用カードマネージャCMへ送信する（１）。このカードマネージャCMでは、AP2側からの認証先要求に応じて、先ずAP1側にてAP2が認証しても良い相手かどうかをリスト等により確認させるために、AP2のIDであるAPid2をAP1へ送信する（２）。AP1側にてAP2が正当な相手であることが確認できたら、その旨をカードマネージャCMに送り（３）、次いでこのカードマネージャCMを経由してAP1の認証先要求情報をAP2へ送信して（４）、AP2側にてAP1が認証しても良い相手かどうかをリスト等により確認してから連携を行なうようにする。この例の場合には、認証先要求情報を前記他の実施例におけると同様な「チャレンジ＆レスポンス」としてやり取りさせる。
【００３２】
本発明は、上述した例のみに限定されるものでなく、幾多の変更を加え得ること勿論である。例えば、各アプリケーション間の認証をAP2側でAP1を、AP1側でAP2を認証する相互認証の例につき説明したが、連携相手のアプリケーションが信頼できるICカードに搭載されている場合には片側認証でも充分な場合もあることは明かである。また、上述した各実施例では、（ディジタル）署名の生成を秘密鍵を用いて暗号化する場合につき述べたが、ディジタル署名の生成は、署名生成を行なうか、ハッシュを作成することにより行なうこともできることは勿論である。
【００３３】
【発明の効果】
以上説明したように、本発明によれば、異なるICカード間や、同一カード上の複数のアプリケーション間にて認証を行ない、この認証結果に基づいてアプリケーションの連携を行なうことができる。同一カードの場合には、相手の署名を必要としたり、カードマネージャがお墨付けを与えたりするように、複数の認証レベルを持つことが可能である。
【図面の簡単な説明】
【図１】本発明による複数カード内のアプリケーション連携方法に適用するICカードの構成を示した図である。
【図２】複数カードのアプリケーション同士で認証確認して、アプリケーションの連携を行なう例のプロトコルを示した図である。
【図３】複数カードのカードマネージャCM同士で認証確認して、アプリケーションの連携を行なう例のプロトコルを示した図である。
【図４】同一カードのアプリケーション同士で認証確認して、アプリケーションの連携を行なう例のプロトコルを示した図である。
【図５】同一カードのアプリケーション間の認証を信頼できるカードマネージャCM経由で行なって、アプリケーションの連携を行なう例のプロトコルを示した図である。
【符号の説明】
１，２ ICカード
１０，２０ 演算部
１１，２１ カードマネージャCM
１２，２２ アプリケーションメモリ部
SkAp1 アプリケーションAP1の秘密鍵
PkAp1 アプリケーションAP1の公開鍵
Lap1 アプリケーションAP1の公開鍵証明書
Apid1 アプリケーションAP1のID
SkC1 カード１の秘密鍵
PkC2 カード２の公開鍵
L1 カード1の公開鍵証明書
PkC1 カード１の公開鍵
Claims (9)
- 複数の各ICカードに搭載された種々のサービスに供するアプリケーションの連携方法において、各ICカードに搭載される各アプリケーションが予め公開鍵及び秘密鍵を所有し、互いに連携相手のICカードの公開鍵は既知のものとして、各ICカードのアプリケーション用のメモリ部同士間にて証明書及び署名を用いたチャレンジ＆レスポンスを元にした認証作業を行なってアプリケーションの連携を行なうにあたり、先ず連携させるアプリケーションの一方が搭載されている一方のICカードのメモリ部から、乱数又は乱数と時刻により生成したチャレンジを、連携相手のアプリケーションが搭載されている他方のICカードのメモリ部に送信し、該他方のICカードのメモリ部では、送信された前記チャレンジと前記連携相手のアプリケーションの識別子とを当該アプリケーションの秘密鍵で暗号化して、当該アプリケーションの署名を生成すると共に、当該ICカードのメモリ部でも乱数等によりチャレンジを生成し、該チャレンジと前記署名を少なくとも前記当該アプリケーションの証明書、公開鍵及び識別子や、当該カードの公開鍵と共に前記一方のICカードのメモリ部にレスポンスとして送信し、該一方のICカードのメモリ部にて前記他方のICカード側から送信された前記チャレンジや署名に基づいて、前記他方のICカードにおける連携相手のアプリケーションの証明書及び署名をそれぞれ署名検証して、前記一方のICカードにおける前記アプリケーションにとって前記他方のICカードにおける前記連携相手のアプリケーションは信頼できることが認証されたら、前記一方のICカードのメモリ部にて、前記他方のカードのメモリ部にて生成されて送信された前記チャレンジと格納済みの前記一方のICカード側の前記アプリケーションの識別子とを当該アプリケーションの秘密鍵で暗号化して、当該アプリケーションの署名を生成すると共に、該署名を少なくとも当該アプリケーションの識別子、証明書及び公開鍵や当該カードの公開鍵と共に前記他方のICカードのメモリ部に送信し、該他方のICカードのメモリ部では、前記一方のICカード側から送信された少なくとも前記署名、アプリケーションの識別子、証明書及び公開鍵やカードの公開鍵に基づいて、前記他方のICカードにおけるメモリ部にて行なったと同様に署名検証して、双方のアプリケーションを連携させることを特徴とする複数ICカード間のアプリケーション連携方法。
- 前記証明書を当該アプリケーションの公開鍵証明書とすることを特徴とする請求項1に記載の複数ICカード間のアプリケーション連携方法。
- 前記認証作業を片側認証だけとすることを特徴とする請求項１に記載の複数ICカード間のアプリケーション連携方法。
- 複数の各ICカードに搭載された種々のサービスに供するアプリケーションの連携方法において、互いに連携相手のICカードに搭載されているアプリケーションの識別子は既知のものとして、各ICカードのカードマネージャ同士間にて証明書及び署名を用いたチャレンジ＆レスポンスを元にした認証を行なってアプリケーション間の連携を行なうにあたり、先ず連携させるアプリケーションの一方が搭載されている一方のICカードのカードマネージャから、乱数又は乱数と時刻により生成したチャレンジを連携相手のアプリケーションの識別子と、当該ICカードにおける前記一方のアプリケーションの識別子と共に、前記連携相手のアプリケーションが搭載されている他方のICカードのカードマネージャに送信し、該他方のICカードのカードマネージャでは、前記一方のICカードのカードマネージャから送信された前記一方のICカードにおける前記アプリケーションの識別子を前記他方のICカードにおける連携相手のアプリケーションのメモリリストにて認証して、前記一方のICカードのアプリケーションが認証できる相手であることが確認できたら、前記一方のICカード側から送信された前記チャレンジと前記他方のICカードにおける前記連携相手のアプリケーションの識別子とを前記他方のICカードの秘密鍵で暗号化して、当該カードの署名を生成すると共に、当該ICカード側のカードマネージャでも乱数等によりチャレンジを生成し、該チャレンジと前記署名を前記他方のICカードの証明書及び公開鍵と共に前記一方のICカードのカードマネージャにレスポンスとして送信し、該一方のICカードにおけるカードマネージャでは、前記他方のICカード側から送信された少なくとも前記チャレンジや署名に基づいて、前記他方のICカードの証明書及び前記一方のICカード側から送信した前記チャレンジをそれぞれ署名検証して、前記他方のICカードにおける前記アプリケーションが認証しても良い相手であることが前記一方のアプリケーションのメモリリストにて確認されたら、前記一方のICカード側のカードマネージャにて前記他方のカード側にて生成されて送信された前記チャレンジと前記一方のICカード側の前記アプリケーションの識別子とを当該アプリケーションの秘密鍵で暗号化して、当該カードの署名を生成すると共に、該署名を当該カードの証明書及び公開鍵と共に前記他方のICカードにおけるカードマネージャに送信し、該他方のICカード側では、前記一方のICカード側から送信された少なくとも前記署名や当該カードの証明書及び公開鍵に基づいて、前記一方のICカードにで行なったのと同じようにして署名検証して、双方のアプリケーションを連携させることを特徴とする複数ICカード間のアプリケーション連携方法。
- 前記認証作業を片側認証だけとすることを特徴とする請求項４に記載の複数ICカード間のアプリケーション連携方法。
- 同一のICカードに搭載された種々のサービスに供する複数のアプリケーションの連携方法において、各アプリケーションが予め公開鍵及び秘密鍵を所有し、連携を行なう各アプリケーション用のメモリ部同士間にて証明書及び署名を用いたチャレンジ＆レスポンスを元に、お互いに認証しても良い相手かどうかどうかの認証作業を行なってアプリケーションの連携を行なうにあたり、先ず連携させるアプリケーションの一方が格納されている一方のメモリ部から、乱数又は乱数と時刻により生成したチャレンジを、連携相手のアプリケーションが格納されている他方のメモリ部に送信し、該他方のメモリ部では、送信された前記チャレンジと当該アプリケーションの識別子とを当該アプリケーションの秘密鍵で暗号化して、当該アプリケーションの署名を生成すると共に、当該メモリ部でも乱数等によりチャレンジを生成し、該チャレンジと前記署名を当該ICカードにおけるカードマネージャにて管理されている前記当該アプリケーションの証明書、公開鍵及び識別子と共に前記一方のメモリ部に送信し、該一方のメモリ部にて前記他方のメモリ部から送信された前記チャレンジや署名に基づいて、前記他方のメモリ部における連携相手のアプリケーションを署名検証して、前記一方のメモリ部における前記アプリケーションにとって前記他方のメモリ部における前記連携相手のアプリケーションは信頼できることが認証されたら、前記一方メモリ部にて前記他方のメモリ部にて生成されて送信された前記チャレンジと前記一方のメモリ部の前記アプリケーションの識別子とを当該アプリケーションの秘密鍵で暗号化して、当該アプリケーションの署名を生成すると共に、該署名を当該アプリケーションの証明書及び公開鍵や当該アプリケーションの識別子と共に前記他方のメモリ部に送信し、該他方のメモリ部では、前記一方のメモリ部から送信された少なくとも前記署名、アプリケーションの識別子、証明書及び公開鍵に基づいて前記一方のメモリ部におけるアプリケーションを署名検証して、双方のアプリケーションを連携させることを特徴とする同一ICカード内のアプリケーション連携方法。
- 前記認証作業を片側認証だけとすることを特徴とする請求項６に記載の同一ICカード内のアプリケーション連携方法。
- 同一のICカードに搭載された種々のサービスに供する複数のアプリケーションの連携方法において、連携を行なう各アプリケーション用のメモリ部同士間にてカードマネージャを経由してお互いに認証しても良い相手かどうかどうかの認証作業を行なってアプリケーションの連携を行なうにあたり、先ず連携させるアプリケーションの一方が格納されている一方のメモリ部から、認証先要求情報を前記カードマネージャに送信し、該カードマネージャでは前記一方のメモリ部から送信された前記認証先要求情報に応じて、前記一方のアプリケーションの識別子を連携相手の他方のアプリケーションが格納されているメモリ部へ送信し、該メモリ部では当該アプリケーションにとって前記一方のアプリケーションが認証しても良い相手であるかどうかを前記一方のアプリケーションの識別子により確認し、前記他方のアプリケーションにとって前記一方のアプリケーションが正当な相手であることが確認できたら、その旨を前記カードマネージャに送信し、次いで前記他方のアプリケーションが格納されている前記メモリ部から前記カードマネージャに前記他方のアプリケーションの認証先要求情報を送信し、該認証先要求情報に応じて、前記他方のアプリケーションの識別子を前記一方のアプリケーションが格納されているメモリ部へ送信し、該メモリ部でも同様に当該アプリケーションにとって前記他方のアプリケーションが認証しても良い相手であるかどうかを前記他方のアプリケーションの識別子により確認して、アプリケーションの連携を行なうことを特徴とする同一ICカード内のアプリケーション連携方法。
- 前記認証作業を片側認証だけとすることを特徴とする請求項８に記載の同一ICカード内のアプリケーション連携方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001074144A JP3634279B2 (ja) | 2001-03-15 | 2001-03-15 | 複数ｉｃカード間及び同一ｉｃカード内のアプリケーション連携方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001074144A JP3634279B2 (ja) | 2001-03-15 | 2001-03-15 | 複数ｉｃカード間及び同一ｉｃカード内のアプリケーション連携方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002279373A JP2002279373A (ja) | 2002-09-27 |
| JP3634279B2 true JP3634279B2 (ja) | 2005-03-30 |
Family
ID=18931463
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001074144A Expired - Lifetime JP3634279B2 (ja) | 2001-03-15 | 2001-03-15 | 複数ｉｃカード間及び同一ｉｃカード内のアプリケーション連携方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3634279B2 (ja) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7350079B2 (en) | 2003-11-20 | 2008-03-25 | International Business Machines Corporation | Apparatus and method for inter-program authentication using dynamically-generated public/private key pairs |
| JP2005157930A (ja) * | 2003-11-28 | 2005-06-16 | Matsushita Electric Ind Co Ltd | 機密情報処理システムおよびｌｓｉ |
| JP4735026B2 (ja) | 2004-10-01 | 2011-07-27 | ソニー株式会社 | 情報記憶装置 |
| JP5521803B2 (ja) | 2010-06-10 | 2014-06-18 | ソニー株式会社 | 通信装置、通信方法、及び、通信システム |
| JP5622668B2 (ja) * | 2011-06-16 | 2014-11-12 | 株式会社エヌ・ティ・ティ・データ | アプリケーション認証システム、アプリケーション認証方法 |
| JP2021170757A (ja) * | 2020-04-14 | 2021-10-28 | ＰａｙｌｅｓｓＧａｔｅ株式会社 | 認証検証システム、被認証装置、認証装置、認証検証方法、認証検証プログラム及びコンピュータで読み取り可能な記録媒体並びに記録した機器 |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4035873B2 (ja) * | 1997-11-21 | 2008-01-23 | 株式会社日立製作所 | Ｉｃカード及びｉｃカードシステム |
| JPH11168461A (ja) * | 1997-12-04 | 1999-06-22 | Nippon Conlux Co Ltd | 情報通信方法および装置 |
| JP2000099458A (ja) * | 1998-09-18 | 2000-04-07 | Kdd Corp | 個人情報提供システム |
| JP2001202332A (ja) * | 2000-01-17 | 2001-07-27 | Hitachi Ltd | 認証プログラム管理システム |
| JP4054535B2 (ja) * | 2001-01-19 | 2008-02-27 | 株式会社日立製作所 | Ｉｃカード・サービス提供方法、カード端末機、及びｉｃカード |
| JP3701571B2 (ja) * | 2001-03-02 | 2005-09-28 | 株式会社ジェーシービー | 集積回路、及びｉｃカード |
-
2001
- 2001-03-15 JP JP2001074144A patent/JP3634279B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002279373A (ja) | 2002-09-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| USRE36946E (en) | Method and apparatus for privacy and authentication in wireless networks | |
| US6993652B2 (en) | Method and system for providing client privacy when requesting content from a public server | |
| US8452961B2 (en) | Method and system for authentication between electronic devices with minimal user intervention | |
| JP4546240B2 (ja) | チャレンジ／レスポンス方式によるユーザー認証方法及びシステム | |
| CN109728909A (zh) | 基于USBKey的身份认证方法和系统 | |
| US6948061B1 (en) | Method and device for performing secure transactions | |
| US20060195402A1 (en) | Secure data transmission using undiscoverable or black data | |
| US20120137128A1 (en) | System and Method for Securing a Credential via User and Server Verification | |
| US20090144541A1 (en) | Method and apparatus of mutual authentication and key distribution for downloadable conditional access system in digital cable broadcasting network | |
| JP2004046430A (ja) | リモートアクセスシステム、リモートアクセス方法、リモートアクセスプログラム及びリモートアクセスプログラムが記録された記録媒体 | |
| WO2001084763A2 (en) | Method for transmitting payment information between a terminal and a third equipment | |
| WO2002087149A1 (fr) | Systeme de communication de terminaux | |
| WO2003067801A2 (en) | Key management with client verification of authorization | |
| WO2003101042A1 (fr) | Procede, systeme et dispositif de traitement d'informations, support d'enregistrement et programme | |
| CN114499898B (zh) | 一种区块链跨链安全接入方法及装置 | |
| CN110020524A (zh) | 一种基于智能卡的双向认证方法 | |
| JP2004247799A (ja) | 公開鍵証明書を利用したアクセス制御を行う情報システム | |
| JP2005529569A (ja) | サービス合意の否認防止（ｎｏｎ−ｒｅｐｕｄｉａｔｉｏｎ） | |
| JP3634279B2 (ja) | 複数ｉｃカード間及び同一ｉｃカード内のアプリケーション連携方法 | |
| JP4255046B2 (ja) | 暗号通信路の確立方法、プログラム及びプログラム媒体、並びに、暗号通信システム | |
| JP5537129B2 (ja) | 認証システム、認証方法およびプログラム | |
| JP4499575B2 (ja) | ネットワークセキュリティ方法およびネットワークセキュリティシステム | |
| JP3889660B2 (ja) | 認証方法及び認証システム | |
| KR100842838B1 (ko) | 엠피지 시스템을 이용한 모바일 단말을 통한무선공인인증서비스 시스템 및 방법 | |
| KR100649858B1 (ko) | 공중전화 스마트 카드 발급/인증 시스템 및 그 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20041026 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20041124 |
|
| 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: 20041214 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20041222 |
|
| R151 | Written notification of patent or utility model registration |
Ref document number: 3634279 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090107 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100107 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110107 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110107 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120107 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130107 Year of fee payment: 8 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| EXPY | Cancellation because of completion of term |