(57)【要約】【課題】オフラインで利用することを想定したＩＣカードを、サーバにバリューを保持した形態に流用する際に、安全にＩＣカードの認証を行うことが可能なサーバを提供する。【解決手段】ＩＣチップを備えた無線通信装置との間で近接非接触通信を行う端末に対して該無線通信装置の認証のための認証データを提供する提供部と、前記端末から、前記認証データの利用回数を含んだ、前記無線通信装置との間の近接非接触通信により受信した受信データを取得する取得部と、前記認証データと前記受信データとを用いて前記無線通信装置の認証を行う認証部と、を備える、サーバが提供される。【選択図】図１
2018150931.tif 000002
【特許請求の範囲】
【請求項１】
ＩＣチップを備えた無線通信装置との間で近接非接触通信を行う端末に対して該無線通信装置の認証のための認証データを提供する提供部と、
前記端末から、前記認証データの利用回数を含んだ、前記無線通信装置との間の近接非接触通信により受信した受信データを取得する取得部と、
前記認証データと前記受信データとを用いて前記無線通信装置の認証を行う認証部と、
を備える、サーバ。
【請求項２】
前記提供部は、前記無線通信装置の認証に先立ち、複数の前記認証データを事前に前記端末に提供する、請求項１に記載のサーバ。
【請求項３】
前記提供部が提供する前記認証データは、最後に認証が行われた際の認証データに基づいて生成されたものである、請求項１に記載のサーバ。
【請求項４】
前記提供部は、認証の対象となる無線通信装置の認証時に前記端末から該無線通信装置へ提供するチャレンジと、前記チャレンジに応じて該無線通信装置から前記端末へ返答されるレスポンスとの組を、前記無線通信装置の認証に先立ち前記端末に提供する、請求項１に記載のサーバ。
【請求項５】
前記認証部は、第１の無線通信装置からの第１の受信データと、第２の無線通信装置からの第２の受信データとを用いて前記第１の無線通信装置及び前記第２の無線通信装置の認証を行う、請求項１に記載のサーバ。
【請求項６】
前記認証部は、前記第１の無線通信装置及び前記第２の無線通信装置の認証結果に基づき、前記第１の無線通信装置のユーザと前記第２の無線通信装置のユーザとの間の送金処理の可否を決定する、請求項５に記載のサーバ。
【請求項７】
前記認証部は、前記無線通信装置からの受信データと、取引データと、を用いて、前記取引データの真正性の確認を行う、請求項１に記載のサーバ。
【請求項８】
前記無線通信装置は、ＩＣチップを内蔵したＩＣカードである、請求項１に記載のサーバ。
【請求項９】
前記無線通信装置は、ＩＣチップを内蔵した携帯端末である、請求項１に記載のサーバ。
【請求項１０】
ＩＣチップを備えた無線通信装置との間で近接非接触通信を行う端末に対して提供する、該無線通信装置の認証のための認証データを、前記認証データを生成する装置より取得し、取得した前記認証データを前記端末への提供に先立ってキャッシュする、サーバ。
【請求項１１】
前記端末が前記無線通信装置を認証する際に、キャッシュした前記認証データを前記端末へ提供する、請求項１０に記載のサーバ。
【請求項１２】
前記無線通信装置の認証に際して、前記装置との通信が出来ない場合において、キャッシュした前記認証データを前記端末へ提供する、請求項１１に記載のサーバ。
【請求項１３】
所定のタイミングでキャッシュした前記認証データを削除する、請求項１０に記載のサーバ。
【請求項１４】
所定のタイミングとして前記認証データの有効期限が経過した時点でキャッシュした前記認証データを削除する、請求項１３に記載のサーバ。
【請求項１５】
所定のタイミングとして前記装置との通信が回復するとキャッシュした前記認証データを削除する、請求項１３に記載のサーバ。
【請求項１６】
前記無線通信装置は、ＩＣチップを内蔵したＩＣカードである、請求項１０に記載のサーバ。
【請求項１７】
前記無線通信装置は、ＩＣチップを内蔵した携帯端末である、請求項１０に記載のサーバ。
【請求項１８】
ＩＣチップを備えた無線通信装置との間で近接非接触通信を行う端末に対して該無線通信装置の認証のための認証データを提供することと、
前記端末から、前記認証データの利用回数を含んだ、前記無線通信装置との間の近接非接触通信により受信した受信データを取得することと、
前記認証データと前記受信データとを用いて前記無線通信装置の認証を行うことと、
を含む、認証方法。
【請求項１９】
ＩＣチップを備えた無線通信装置と、
前記無線通信装置との間で近接非接触通信を行う端末と、
前記端末に対して該無線通信装置の認証のための認証データを提供するサーバと、
を備え、
前記サーバは、
前記認証データを提供する提供部と、
前記端末から、前記認証データの利用回数を含んだ、前記無線通信装置との間の近接非接触通信により受信した受信データを取得する取得部と、
前記認証データと前記受信データとを用いて前記無線通信装置の認証を行う認証部と、
を備える、認証システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、サーバ及び認証方法に関する。
【背景技術】
【０００２】
近接非接触通信によって通信するＩＣカードにバリューを持たせることが広く行われてきている（例えば特許文献１等参照）。その際、オフラインでサービスを提供するために、セキュアにバリューを保持するＩＣカードと、そのバリューを操作するためのタンパ耐性をもったセキュアな端末とを活用してきた。一方、昨今、ネットワークが普及し、サーバにバリューを保持する形態が増え、正しいカードであることを確認することでサーバのバリューの持ち主であることを認証するＩＣカードの利用形態が考えられる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００９−１１０２０２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
オフラインで利用することを想定したＩＣカードを、サーバにバリューを保持した形態に流用する場合にはＩＣカードの認証において考慮すべき点がある。【０００５】
そこで、本開示では、オフラインで利用することを想定したＩＣカードを、サーバにバリューを保持した形態に流用する際に、安全にＩＣカードの認証を行うことが可能な、新規かつ改良されたサーバ及び認証方法を提案する。
【課題を解決するための手段】
【０００６】
本開示によれば、ＩＣカードとの間で近接非接触通信を行う端末に対して該ＩＣカードの認証のための認証データを提供する提供部と、前記端末から、前記認証データの利用回数を含んだ、前記ＩＣカードとの間の近接非接触通信により受信した受信データを取得する取得部と、前記認証データと前記受信データとを用いて前記ＩＣカードの認証を行う認証部と、を備える、サーバが提供される。【０００７】
また本開示によれば、ＩＣカードとの間で近接非接触通信を行う端末に対して該ＩＣカードの認証のための認証データを提供することと、前記端末から、前記認証データの利用回数を含んだ、前記ＩＣカードとの間の近接非接触通信により受信した受信データを取得することと、前記認証データと前記受信データとを用いて前記ＩＣカードの認証を行うことと、を含む、認証方法が提供される。
【発明の効果】
【０００８】
以上説明したように本開示によれば、オフラインで利用することを想定したＩＣカードを、サーバにバリューを保持した形態に流用する際に、安全にＩＣカードの認証を行うことが可能な、新規かつ改良されたサーバ及び認証方法を提供することが出来る。【０００９】
なお、上記の効果は必ずしも限定的なものではなく、上記の効果とともに、または上記の効果に代えて、本明細書に示されたいずれかの効果、または本明細書から把握され得る他の効果が奏されてもよい。
【図面の簡単な説明】
【００１０】
【図１】本開示の実施の形態に係る認証システムの構成例を示す説明図である。
【図２】ＩＤｃｄ認証サーバの機能構成例を示す説明図である。
【図３】ＩＤｃｄ認証サーバ及びＩＣカードの動作例を示す流れ図である。
【図４】ＩＤｃｄ認証サーバ及び端末の動作例を示す流れ図である。
【図５】ＩＤｃｄ認証サーバ及びサービス事業者の動作例を示す流れ図である。
【図６】ＩＤｃｄ認証サーバ、端末及びサービス事業者の動作例を示す流れ図である。
【図７】サービス事業者、端末及びＩＣカードの動作例を示す流れ図である。
【図８】ＩＣカードでの処理を説明するための説明図である。
【図９】ＩＤｃｄ認証サーバ及びサービス事業者の動作例を示す流れ図である。
【図１０】ＩＣカード認証部の処理を説明するための説明図である。
【図１１】ＩＤｃｄ認証サーバ、サービス事業者及び端末の動作例を示す流れ図である。
【図１２】端末及びＩＣカードの動作例を示す流れ図である。
【図１３】サービス事業者と、端末と、ＩＣカードと、の動作例を示す流れ図である。
【図１４】端末が生成する要求文の構造を示す説明図である。
【図１５】ＩＤｃｄ認証サーバと、サービス事業者と、の動作例を示す流れ図である。
【図１６】ＩＤｃｄ認証サーバと、サービス事業者と、その他事業者と、の動作例を示す流れ図である。
【図１７】ＩＤｃｄ認証サーバと、サービス事業者と、端末と、ＩＣカードと、の動作例を示す流れ図である。
【図１８】サービス事業者と、端末と、ＩＣカードと、の動作例を示す流れ図である。
【図１９】決済する側が不正により決済額を変更する様子を示す説明図である。
【図２０】決済する側の不正を防止することを目的とした仕組みを示す説明図である。
【図２１】ＩＣカードによる認証を利用した個人間の送金処理を説明する説明図である。
【発明を実施するための形態】
【００１１】
以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【００１２】
なお、説明は以下の順序で行うものとする。
１．本開示の実施の形態
１．１．概要
１．２．構成例
１．３．動作例
２．まとめ
【００１３】
＜１．本開示の実施の形態＞
［１．１．概要］
まず、本開示の実施の形態について説明する前に、本開示の実施の形態に至った経緯を説明する。
【００１４】
オフラインでサービスを提供するために、セキュアにバリューを保持するＩＣカードと、そのバリューを操作するためのタンパ耐性をもったセキュアな端末とを活用してきた。一方、昨今、ネットワークが普及し、サーバにバリューを保持する形態が増え、正しいカードであることを確認することでサーバのバリューの持ち主であることを認証するＩＣカードの利用形態が考えられる。
【００１５】
従来オフラインで利用することを想定したＩＣカードを、サーバにバリューを保持した形態に流用する場合に以下に示す点をクリアにする必要がある。
【００１６】
ＩＣカードとの相互認証に、多くの通信が発生し、端末の実装が煩雑となっていた。
【００１７】
もし秘匿の鍵が漏えいしたとしても検知できず、漏えいされた鍵を使っているのか、そうでないのかの区別ができず、サービス継続を止めるべきかどうかが分からなかった
【００１８】
また、ＩＣカードが正しいことを判別するために、端末側に秘匿の鍵とそれを格納するセキュアチップが必要であり、端末側のコスト増や管理の煩雑さに繋がっていた。また、サーバ側に秘匿の鍵やセキュアチップを配置したとしても、多くの通信が必要となるため、通信経路上のサーバや端末の開発コストがかさんでいた。既存の環境によっては、専用の通信路を別途設ける必要があった。
【００１９】
セキュアチップを利用してＩＣカードおよびそのＩＤｃｄが正しいことを判別したとしても、その結果の転送を受けつけた別の人やシステムは、それが正しいかどうか判別できず、転送元を信じるしかなかった。
【００２０】
判別したＩＣカードおよびそのＩＤｃｄを使った各サービスの兌換性やセキュリティ保護レベルに関わらず、秘匿の鍵とセキュアチップは高度に保護する必要があった。
【００２１】
新たにＩＣカードおよびＩＤｃｄの証明が必要となった場合、証明のための専用のＩＣカードやＩＤｃｄの発行を行っていた。加えて、ＩＣカードの秘匿の鍵を格納したセキュリティチップおよびリーダライタを各端末に都度用意する必要があった。
【００２２】
そこで本件開示者は、上述した点をクリアにするための技術について鋭意検討を行った。その結果、本件開示者は、以下で説明するように、オンラインだけでなく、オフラインで利用することを想定したＩＣカードを、サーバにバリューを保持した形態に流用する際に、安全にＩＣカードの認証を行うことが可能となる技術を考案するに至った。
【００２３】
［１．２．構成例］
図１は、本開示の実施の形態に係る認証システムの構成例を示す説明図である。このシステムでは、サーバにバリューを保持する形態が増え、正しいカードであることを確認することでサーバのバリューの持ち主であることを認証するＩＣカードの利用形態を想定する。図１には、ＩＤｃｄ認証サーバ１００と、ＩＣカード３００との間で近接非接触通信によって通信を行うリーダライタを有する端末２００と、ＩＣチップを内蔵したＩＣカード３００と、が示されている。また図１には、ＩＣカード３００に対してサービスを提供するサービス事業者４００と、その他事業者５００と、も示されている。サービス事業者４００と、その他事業者５００とは、例えばサーバの形態であり得る。
【００２４】
図２は、ＩＤｃｄ認証サーバ１００の機能構成例を示す説明図である。ＩＤｃｄ認証サーバ１００は、ＩＣカード認証部１１０と、回数券データ管理部１２０と、通信データ復元部１３０と、外部通信部１４０と、を含んで構成される。
【００２５】
ＩＣカード認証部１１０は、ＩＣカード３００の認証を行う。ＩＣカード認証部１１０は、レスポンス検証器１１１と、ＩＣカード鍵テーブル１１２と、を含んで構成される。レスポンス検証器１１１は、ＩＣカード３００で生成されたチャレンジに対するレスポンスが正しいものであるかどうかを検証する。レスポンス検証器１１１は、ＩＣカード３００におけるレスポンスの生成の仕組みと同じ仕組みを持っている。ＩＣカード鍵テーブル１１２は、ＩＣカード３００を認証するために必要な鍵情報を保持する。具体的には、ＩＣカード鍵テーブル１１２は、ＩＣカード鍵ＩＤと、ＩＣカード鍵情報とを、ＩＣカード鍵ごとに保持する。ＩＣカード鍵ＩＤは、ＩＣカード鍵を識別するためのＩＤである。ＩＣカード鍵情報は、ＩＣカードに格納されている秘匿の鍵を認証するために必要な鍵情報である。
【００２６】
回数券データ管理部１２０は、回数券データとサービス定義を管理する。回数券データとは、ＩＣカード３００の認証のために必要となる情報が端末２００ごとに規定されたユニークなデータである。回数券データは、後述するように、チャレンジと、ＩＤトークン化鍵と、を有するデータ列である。ＩＤｃｄ認証サーバ１００は、端末２００に対して複数個の回数券データを一括して提供しても良く、端末２００での認証に応じて送られる要求の度に生成して端末２００に提供しても良い。
【００２７】
回数券データ管理部１２０は、回数券データ生成器１２１と、回数券テーブル１２２と、を含んで構成される。回数券データ生成器１２１は、所定のルールに基づいて回数券データを生成する。回数券テーブル１２２は、ＩＣカード３００にアクセスする端末２００を管理し、端末２００ごとに回数券データを生成するために必要なデータを保持する。回数券テーブル１２２は、具体的には、端末ＩＤ、初期回数券データ、回数券データ派生鍵、現在利用回数、現在払出回数、最終回数券データを保持する。端末ＩＤは、端末２００を識別するためのＩＤである。初期回数券データは、回数券データを派生させる最初の鍵である。回数券データ派生鍵は、回数券データから、次の回数券データを派生生成するための鍵である。現在利用回数は、これまで何個目の回数券データまでが使われたかを示す回数である。現在払出回数は、これまで何個目の回数券データが払い出されたかを示す回数である。最終回数券データは、最後に認証した回数券データである。
【００２８】
通信データ復元部１３０は、端末２００から所定のルールにより暗号化されたデータを復元する。通信データ復元部１３０は、トークン化ＩＤｃｄ復元器１３１と、ハッシュ生成１３２と、を含んで構成される。トークン化ＩＤｃｄ復元器１３１は、トークン化されたＩＤｃｄを復元する。
【００２９】
ＩＤｃｄ認証サーバ１００は、他にサービス事業者４００を管理するサービス定義テーブル１２３を保持する。サービス定義テーブル１２３は、サービス事業者を管理し、サービス事業者が利用する端末のリストと、受け入れるＩＣカードの鍵の種類を保持する。サービス定義テーブル１２３は、サービス事業者４００ごとに、サービスＩＤ、端末ＩＤリスト、鍵ＩＤリストを保持する。サービスＩＤは、サービス事業者を識別するためのＩＤである。端末ＩＤリストは、サービス事業者が利用している端末の端末ＩＤリストである。鍵ＩＤリストは、各端末が受け入れ可能なＩＣカード鍵のＩＣカード鍵ＩＤリストである。
【００３０】
外部通信部１４０は、ＩＤｃｄ認証サーバ１００の外部の装置との間で、任意の通信プロトコルによる通信処理を実行する。
【００３１】
［１．３．動作例］
続いて、認証システムの動作例を説明する。
【００３２】
（実施例１）
１つ目の実施例として、事前に端末ごとに複数の回数券データを送付し、ＩＣカード３００が翳されるたびにレスポンスをＩＤｃｄ認証サーバ１００に送信して認証を行う例を示す。端末２００がセキュアでない場合を想定して、ＩＣカード３００が翳されるごとに端末２００がサービス事業者４００を介してＩＤｃｄ認証サーバ１００から回数券データを取得する場合も該当する。
【００３３】
（１−１）ＩＣカード鍵情報の登録
まずＩＣカード３００に保持されているＩＣカード鍵情報をＩＤｃｄ認証サーバ１００に登録する際の動作例を説明する。図３は、ＩＤｃｄ認証サーバ１００及びＩＣカード３００の動作例を示す流れ図である。ＩＣカード３００からは、所定の方法、例えばＩＣカード鍵情報をＩＤｃｄ認証サーバ１００に登録するための端末２００にＩＣカード３００がかざされたことに応じて、ＩＣカード鍵情報をＩＤｃｄ認証サーバ１００に送信する（ステップＳ１０１）。この際、必要に応じてＩＣカード３００を保持する登録者の本人認証や、ＩＤｃｄ認証サーバ１００との間の通信路の暗号化を行う。ＩＤｃｄ認証サーバ１００は、ＩＣカード３００から送信されたＩＣカード鍵情報をＩＣカード鍵テーブル１１２に登録し、ＩＣカード鍵ＩＤをＩＣカード３００へ返す（ステップＳ１０２）。このＩＣカード鍵ＩＤは、ＩＣカード３００のユーザが何らかの方法で管理しても良い。例えばＩＣカード鍵ＩＤは、ＩＣカード３００のユーザが保持する情報通信機器の内部で保存されていても良い。
【００３４】
（１−２）端末の登録
次に端末２００の情報をＩＤｃｄ認証サーバ１００に登録する際の動作例を説明する。図４は、ＩＤｃｄ認証サーバ１００及び端末２００の動作例を示す流れ図である。端末２００は、所定のタイミングでＩＤｃｄ認証サーバ１００に登録するリクエストを送る（ステップＳ１１１）。この際、必要に応じて登録者の本人認証や、ＩＤｃｄ認証サーバ１００との間の通信路の暗号化を行う。ＩＤｃｄ認証サーバ１００は、このリクエストに応じて、ユニークな端末ＩＤを採番し、端末ＩＤに初期回数券データ、回数券データ派生鍵を生成する。ＩＤｃｄ認証サーバ１００は、生成した初期回数券データを、回数券テーブル１２２の初期回数券データと最終回数券データに割り当てる。またＩＤｃｄ認証サーバ１００は、生成した回数券データ派生鍵を回数券テーブル１２２の回数券データ派生鍵に割り当てる。またＩＤｃｄ認証サーバ１００は、回数券テーブル１２２の現在利用回数と現在払出回数の数をいずれも０とする。ＩＤｃｄ認証サーバ１００は、端末ＩＤを端末２００に提供する（ステップＳ１１２）。端末２００は、端末ＩＤと後述する回数券データリストに加えて、現在利用回数を保持する。現在利用回数の初期値を０とする。
【００３５】
（１−３）サービス事業者の登録
次にサービス事業者４００の情報をＩＤｃｄ認証サーバ１００に登録する際の動作例を説明する。図５は、ＩＤｃｄ認証サーバ１００及びサービス事業者４００の動作例を示す流れ図である。サービス事業者４００は、サービス定義をＩＤｃｄ認証サーバ１００に登録するリクエストを送る（ステップＳ１２１）。この際、必要に応じて、登録者の本人認証や、ＩＤｃｄ認証サーバ１００との間の通信路の暗号化を行う。サービス事業者４００は、ＩＤｃｄ認証サーバ１００に対して、端末ＩＤリスト及びＩＣカード鍵ＩＤリストを送信する。ＩＤｃｄ認証サーバ１００は、このリクエストに応じてユニークなサービスＩＤを採番し、サービス定義テーブル１２３に情報を登録する。ＩＤｃｄ認証サーバ１００は、サービス事業者４００へ、採番したサービスＩＤを提供する（ステップＳ１２２）。サービス事業者４００は、サービスを利用する端末２００（端末ＩＤリストに含まれる端末ＩＤに対応する端末２００）に、サービスＩＤとＩＣカード鍵ＩＤリストを通知する（ステップＳ１２３）。
【００３６】
（１−４）回数券データリストの出力（払い出し）
次に、ＩＤｃｄ認証サーバ１００が回数券データリストを出力する（払い出す）際の動作例を説明する。図６は、ＩＤｃｄ認証サーバ１００、端末２００及びサービス事業者４００の動作例を示す流れ図である。
【００３７】
サービス事業者４００は、回数券データリストを払い出したい端末２００ごとに、回数券データリストの払い出しをＩＤｃｄ認証サーバ１００に要求する（ステップＳ１３１）。サービス事業者４００は、ＩＤｃｄ認証サーバ１００に対し、自身のサービスＩＤ、回数券データリストを払い出す端末の端末ＩＤ、回数券データ払い出し数の情報を送信する。
【００３８】
ＩＤｃｄ認証サーバ１００は、この払い出し要求に対して、回数券データ生成器１２１を使って、下記の手順で、入力された回数券データ払い出し数分、回数券データを生成する。まずＩＤｃｄ認証サーバ１００は、サービス事業者４００から入力された端末ＩＤから、回数券テーブルの端末ＩＤを特定する。次にＩＤｃｄ認証サーバ１００は、回数券データ生成器１２１に、最終回数券データと回数券データ派生鍵を入力し、新しい回数券データを生成する。そしてＩＤｃｄ認証サーバ１００は、現在払出回数と生成した回数券データリストをサービス事業者４００に出力し、払い出した回数分だけ、回数券テーブル１２２の現在払出回数を加算する（ステップＳ１３２）。
【００３９】
サービス事業者４００は、ＩＤｃｄ認証サーバ１００から取得した現在払出回数、回数券データリストを、端末ＩＤに対応する端末２００に転送する（ステップＳ１３３）。端末ＩＤに対応する端末２００は、自身が保持している回数券データリストに、取得した回数券データリストを追加する。
【００４０】
（１−５）カードレスポンスの取得
端末２００は、ＩＣカード３００が翳され認証が必要となるたびに、以下のカードレスポンス取得を行う。図７は、サービス事業者４００、端末２００及びＩＣカード３００の動作例を示す流れ図である。端末２００は、ＩＣカード３００が翳され、ＩＣカード３００の認証が必要となるたびに、以下のカードレスポンス取得を行う。まず端末２００は、保持している回数券データリストのうち一番若いデータを取り出し、その回数券データを回数券データリストから削除するとともに、現在利用回数を１インクリメントする。次に端末２００は、取り出した回数券データから、チャレンジと、ＩＤトークン化鍵と、を取り出す。例えば、回数券データの先頭８バイトまたは１６バイトをチャレンジ、次の８バイトをＩＤトークン化鍵とする。もちろんチャレンジと、ＩＤトークン化鍵との定義はこの例に限られるものでは無い。
【００４１】
端末２００は、ＩＣカード３００が翳されたとき、ＩＣカード鍵ＩＤごとに決められた情報を用いて、利用するＩＣカード鍵ＩＤを特定する。この際、端末２００は、ＩＣカード３００の片側認証コマンドを発行する。その際に、端末２００は、近接非接触通信によってチャレンジをＩＣカード３００に入力し（ステップＳ１４１）、ＩＣカード３００からＩＤｃｄと、チャレンジに対してＩＣカード３００が生成したレスポンスを取得する（ステップＳ１４２）。
【００４２】
図８は、ＩＣカード３００での処理を説明するための説明図である。ＩＣカード３００は、端末２００からチャレンジを取得すると、内部で保持しているＩＣカード鍵情報及びＩＤｃｄを用いて所定の演算を行って、チャレンジに対するレスポンスを生成する。そしてＩＣカード３００は、ＩＤｃｄと、チャレンジに対して生成したレスポンスを出力する。
【００４３】
続いて端末２００は、ＩＤｃｄ認証サーバ１００に対して、ＩＤトークン化鍵を使って、トークン化ＩＤｃｄを生成する。例えば端末２００は、ＩＤｃｄとＩＤトークン化鍵で排他的論理和を取ることで、トークン化ＩＤｃｄを生成する。もちろんトークン化ＩＤｃｄの生成方法は係る例に限定されるものでは無い。また端末２００は、レスポンス等に対して、ＳＳＬ（Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔｓ  Ｌａｙｅｒ）等の所定の暗号化方式を使って暗号化レスポンスを生成する。そして端末２００は、生成した情報をサービス事業者４００に送信する（ステップＳ１４３）。ここで端末２００は、サービス事業者４００へ、端末ＩＤ、トークン化ＩＤｃｄ、レスポンス、現在利用回数、ＩＣカード鍵ＩＤを送信する。
【００４４】
（１−６）ＩＣカードの認証
図９は、ＩＤｃｄ認証サーバ１００及びサービス事業者４００の動作例を示す流れ図である。サービス事業者４００は、端末２００から取得したレスポンス情報をＩＤｃｄ認証サーバ１００に送信し、レスポンスが正しいことの認証を依頼する（ステップＳ１５１）。ここでサービス事業者４００は、ＩＤｃｄ認証サーバ１００に、サービスＩＤ、端末ＩＤ、トークン化ＩＤｃｄ、レスポンス、現在利用回数、およびＩＣカード鍵ＩＤを送信する。
【００４５】
ＩＤｃｄ認証サーバ１００は、回数券データ管理部１２０で、以下の手順によって回数券データを生成する。まずＩＤｃｄ認証サーバ１００は、サービス事業者４００から入力された端末ＩＤから、回数券テーブル１２２の中のデータを特定し、最終回数券データを取得する。次にＩＤｃｄ認証サーバ１００は、サービス事業者４００から入力された現在利用回数から回数券データを生成する。回数券テーブル１２２にある初期回数券データからサービス事業者４００から入力された現在利用回数の数分だけ生成を繰り返すのではなく、回数券テーブル１２２にある現在利用回数との差分の数だけ、最終回数券データから回数券データ生成器１２１を使って回数券データの生成を繰り返す。
【００４６】
ＩＤｃｄ認証サーバ１００は、入力されたレスポンス情報と、回数券データ生成器１２１で生成した回数券データを使って、通信データ復元部１３０で、受信したデータの復号化を行う。まずＩＤｃｄ認証サーバ１００は、回数券データ生成器１２１で生成した回数券データから、チャレンジとトークン化鍵とを取得する。次にＩＤｃｄ認証サーバ１００は、ＩＤｃｄとトークン化鍵とをトークン化ＩＤｃｄ復元器１３１に入力して、ＩＤｃｄを取得する。
【００４７】
続いて、ＩＤｃｄ認証サーバ１００は、サービス事業者４００から入力されたレスポンス情報と、自身で生成した回数券データと、自身で復号化した情報を使って、サービス事業者４００から入力されたレスポンスが正しいことをＩＣカード認証部１１０で認証する。具体的には、ＩＤｃｄ認証サーバ１００は以下の手順で認証する。まずＩＤｃｄ認証サーバ１００は入力されたＩＣカード鍵ＩＤから、ＩＣカード鍵情報を取得する。次にＩＤｃｄ認証サーバ１００は、レスポンス検証器１１１に、復元したＩＤｃｄ、自身で生成したチャレンジ、及びＩＣカード鍵情報を入力してレスポンスを生成し、サービス事業者４００から入力されたレスポンスと比較して、両者が同じかどうか判別する。同じ場合は、ＩＤｃｄ認証サーバ１００は、端末２００にかざされたものは正しいＩＣカードおよびＩＤｃｄであるとみなす。そしてＩＤｃｄ認証サーバ１００は、自身で生成した回数券データを最終回数券データとし、現在利用回数を、入力された現在利用回数とする。一方、一致しない場合は、ＩＤｃｄ認証サーバ１００は、以降の処理は行わず、サービス事業者４００に不一致であったことを示す所定のエラーメッセージを返す。
【００４８】
図１０は、ＩＣカード認証部１１０の処理を説明するための説明図である。ＩＣカード認証部１１０は、ＩＣカード鍵ＩＤから、ＩＣカード鍵テーブル１１２を参照して、対象のＩＣカード鍵情報を抽出する。そしてＩＣカード認証部１１０は、復元したＩＤｃｄ、自身で生成したチャレンジ、及びＩＣカード鍵情報をレスポンス検証器１１１に入力してレスポンスを生成する。
【００４９】
端末２００は、認証のたびに回数券データを消費するため、足りなくなったらＩＤｃｄ認証サーバ１００から回数券データを追加で取得する。端末２００は、サービス事業者４００に、回数券データの追加を依頼する。サービス事業者４００は、ＩＤｃｄ認証サーバ１００へ、サービスＩＤ、端末ＩＤ、回数券データ払い出し数を入力して、ＩＤｃｄ認証サーバ１００に回数券データの追加生成を依頼する。ＩＤｃｄ認証サーバ１００は、上述した回数券データリストの払い出し処理と同じ処理を行って、生成した回数券データをサービス事業者４００に提供する。サービス事業者４００は、ＩＤｃｄ認証サーバ１００から取得した回数券データを、回数券データの追加を依頼した端末２００へ転送する。
【００５０】
（実施例２）
次の実施例として、端末２００にかざされるＩＣカードのＩＤｃｄのリストがあらかじめ分かっている場合に、ＩＤｃｄに対応するチャレンジとレスポンスを事前に払い出す例を示す。
【００５１】
（２−１）チャレンジレスポンスリストの取得
まずチャレンジレスポンスリストの取得処理を説明する。図１１は、ＩＤｃｄ認証サーバ１００、サービス事業者４００及び端末２００の動作例を示す流れ図である。サービス事業者４００は、端末２００にかざされる予定のＩＣカード３００のＩＤｃｄリストをＩＤｃｄ認証サーバ１００に送信する（ステップＳ２０１）。サービス事業者４００は、ＩＤｃｄ認証サーバ１００へ、サービスＩＤ及びＩＤｃｄ情報のリスト（ＩＤｃｄ及びＩＣカード鍵ＩＤを含む）を送信する。
【００５２】
ＩＤｃｄ認証サーバ１００のＩＣカード認証部１１０は、ＩＣカード鍵ＩＤからＩＣカード鍵情報を取得する。またＩＣカード認証部１１０は、チャレンジも生成する。このチャレンジの生成は、乱数生成等によって行われる。続いてＩＤｃｄ認証サーバ１００のレスポンス検証器１１１は、ＩＤｃｄ、ＩＣカード鍵情報、チャレンジを入力し、レスポンスを取得する。これを、ＩＤｃｄ情報のリストの数分だけ繰り返す。
【００５３】
そしてＩＤｃｄ認証サーバ１００は、サービス事業者４００に生成したリストを返送する（ステップＳ２０２）。具体的には、ＩＤｃｄ認証サーバ１００は、サービスＩＤ及びＩＤｃｄ情報のリスト（ＩＤｃｄ、ＩＣカード鍵ＩＤ、チャレンジ及びレスポンスを含む）を送信する。
【００５４】
サービス事業者４００は、ＩＤｃｄ認証サーバ１００から受領したリストを端末２００に送信する（ステップＳ２０３）。端末２００は、サービス事業者４００から送られたリストを保持しておく。
【００５５】
（２−２）カードレスポンスの確認
図１２は、端末２００及びＩＣカード３００の動作例を示す流れ図である。端末２００は、ＩＣカード３００が翳されたとき、ＩＣカード３００のＩＤｃｄを近接非接触通信によって取得する（ステップＳ２１１）。次に端末２００は、ＩＣカード３００のＩＤｃｄを確認したのち、ＩＤｃｄに対応するチャレンジを、ＩＣカード鍵ＩＤで特定される情報で持って、ＩＣカード３００の片側認証コマンドを発行して（ステップＳ２１２）、ＩＣカード３００からレスポンスを取得する（ステップＳ２１３）。
【００５６】
端末２００は、ＩＤｃｄに該当するレスポンスと、ＩＣカード３００から受信したレスポンスが同じかどうかを確認する。同じ場合には、端末２００は、翳されたＩＣカード３００が正しいＩＣカードおよびＩＤｃｄであるとみなし、以降の処理を実行する。異なる場合は、端末２００は、所定のエラー処理を実行する。
【００５７】
（実施例３）
３つ目の実施例として、ＩＣカード３００に入力するチャレンジを端末２００が生成して、ＩＤｃｄ認証サーバ１００は、そのレスポンスが、そのチャレンジとＩＣカードに入力した結果であることを証明する例を説明する。
【００５８】
（３−１）カードレスポンス取得
図１３は、サービス事業者４００と、端末２００と、ＩＣカード３００と、の動作例を示す流れ図である。端末２００は、まずＩＣカード３００に入力するチャレンジを生成する。端末２００は、サービスＩＤと、端末ＩＤと、ＩＣカード鍵ＩＤと、現在利用回数と、任意のテキストと、を結合した要求文を生成する。図１４は、端末２００が生成する要求文の構造を示す説明図である。
【００５９】
続いて端末２００は、生成した要求文に対するハッシュを生成する。そして端末２００は、現在利用回数を１インクリメントする。
【００６０】
端末２００にＩＣカード３００が翳されたとき、端末２００には、ＩＣカード鍵ＩＤで特定される情報で持って、ＩＣカード３００の片側認証コマンドを発行する。その際に、端末２００は、生成したハッシュをチャレンジとしてＩＣカード３００に近接非接触通信によって入力し（ステップＳ３０１）、ＩＣカード３００からＩＤｃｄとレスポンスを近接非接触通信によって取得する（ステップＳ３０２）。
【００６１】
続いて端末２００は、生成した要求文と、ＩＣカード３００から取得したＩＤｃｄ及びレスポンスと、をサービス事業者４００に送信する（ステップＳ３０３）。
【００６２】
（３−２）カードレスポンスの認証
図１５は、ＩＤｃｄ認証サーバ１００と、サービス事業者４００と、の動作例を示す流れ図である。サービス事業者４００は、ＩＤｃｄ認証サーバ１００に、レスポンスが正しいかの認証を依頼する（ステップＳ３１１）。この際、サービス事業者４００は、ＩＤｃｄ認証サーバ１００に、要求文、ＩＤｃｄ及びレスポンスを送信する。
【００６３】
ＩＤｃｄ認証サーバ１００は、受信した要求文から、ハッシュ生成器１３２を使って、ハッシュを生成し、チャレンジとする。さらに、ＩＤｃｄ認証サーバ１００は、受信した要求文から、サービスＩＤと、端末ＩＤと、ＩＣカード鍵ＩＤと、現在利用回数と、を取り出す。続いて、ＩＤｃｄ認証サーバ１００の回数券データ管理部１２０は、サービス定義テーブル１２３を参照して、サービスＩＤに対応するＩＣカード鍵ＩＤリストに、取り出されたＩＣカード鍵ＩＤがあるかを確認する。続いて、ＩＣカード認証部１１０において、ＩＣカード鍵テーブル１１２から、ＩＣカード鍵ＩＤに対応するＩＣカード鍵情報を特定する。ＩＤｃｄ認証サーバ１００は、レスポンス検証器１１１を使って、ＩＤｃｄ、チャレンジ、ＩＣカード鍵情報を入力して、レスポンスを生成する。そしてＩＤｃｄ認証サーバ１００は、生成したレスポンスを用いた認証結果をサービス事業者４００に送信する（ステップＳ３１２）。受信していたレスポンスと生成したレスポンスが等しい場合は、ＩＤｃｄ認証サーバ１００は、受信したレスポンスが、ＩＤｃｄで特定されるＩＣカード３００に、要求文を入力して生成されたものであるとみなす。
【００６４】
（３−３）認証結果の転送
サービス事業者４００は、認証結果を保持したり、その他事業者５００に転送したりする場合がある。図１６は、ＩＤｃｄ認証サーバ１００と、サービス事業者４００と、その他事業者５００と、の動作例を示す流れ図である。
【００６５】
その他事業者５００は、サービス事業者４００から、要求文、ＩＤｃｄ及びレスポンスを受信する（ステップＳ３２１）。その他事業者５００は、ＩＤｃｄ認証サーバ１００に、要求文、ＩＤｃｄ及びレスポンスを送信する（ステップＳ３２２）。ＩＤｃｄ認証サーバは、上記カードレスポンス認証と同様に、その他事業者５００から受信したレスポンスを認証し、結果をその他事業者５００に返す。
【００６６】
（実施例４）
４つ目の実施例として、ネットワーク切断時の耐性強化や、ネットワーク通信における応答性能の向上を目的とした実施例を説明する。
【００６７】
サービス事業者のサーバがクローズドなネットワークの中にある場合は、サービス事業者のサーバとＩＤｃｄ認証サーバ１００との間のインターネット通信が影響し、ネットワークの切断や輻輳などの影響を受けやすくなる。
【００６８】
そこで４つ目の実施例では、チャレンジとレスポンスとのペアを、サービス事業者４００のサーバにキャッシュとして事前に保持しておく。これにより、次の認証をサービス事業者４００と端末２００との間で完結させることが出来ると共に、サービス事業者のサーバとＩＤｃｄ認証サーバ１００との間のネットワークが切断していても、サービス事業者４００と端末２００との間で実施することができる。
【００６９】
図１７は、ＩＤｃｄ認証サーバ１００と、サービス事業者４００と、端末２００と、ＩＣカード３００と、の動作例を示す流れ図である。
【００７０】
端末２００は、ポーリングを定期的に送出している（ステップＳ４０１）。このポーリングには、ＩＣカード３００からＩＤｍ（ＩＣカード３００固有の情報）及び鍵バージョンを取得するためのRequest  Serviceコマンドが含まれる。ＩＣカード３００は、端末２００から送出されるポーリングを受信すると、Request  Serviceコマンドに応じて端末２００へＩＤｍ及び鍵バージョンを返答する（ステップＳ４０２）。
【００７１】
端末２００は、自装置の端末ＩＤ及び、ステップＳ４０２でＩＣカード３００から取得したＩＤｍ及び鍵バージョンをサービス事業者４００のサーバに送信する（ステップＳ４０３）。サービス事業者４００のサーバは、端末２００から受信した端末２００の端末ＩＤ、ＩＣカード３００のＩＤｍ及び鍵バージョンに基づいて認証鍵を選択し（ステップＳ４０４）、ＩＤｃｄ認証サーバ１００へ、端末２００から受信した情報を転送する（ステップＳ４０５）。
【００７２】
ＩＤｃｄ認証サーバ１００は、サービス事業者４００のサーバから受信した情報に基づいてチャレンジ及びレスポンスの生成を行う（ステップＳ４０６）。そしてＩＤｃｄ認証サーバ１００は、生成したチャレンジ及びレスポンスをサービス事業者４００のサーバに払い出す（ステップＳ４０７）。サービス事業者４００のサーバは、ＩＤｃｄ認証サーバ１００から払い出されたチャレンジ及びレスポンスを端末２００に提供する（ステップＳ４０８）。端末２００は、翳されたＩＣカード３００を認証するためにチャレンジをＩＣカード３００に送信し（ステップＳ４０９）、ＩＣカード３００はそのチャレンジに対するレスポンスを生成して端末２００に返す（ステップＳ４１０）。端末２００は、サービス事業者４００のサーバから取得したレスポンスと、ＩＣカード３００が生成したレスポンスとを比較し（ステップＳ４１１）、ＩＣカード３００の認証を行う（ステップＳ４１２）。
【００７３】
またサービス事業者４００のサーバは、ＩＣカード３００の次回の認証のためのチャレンジ・レスポンスをあらかじめ取得するために、ＩＤｃｄ認証サーバ１００へ、端末２００から受信した情報を転送する（ステップＳ４１３）。ＩＤｃｄ認証サーバ１００は、サービス事業者４００のサーバから受信した情報に基づいてチャレンジ及びレスポンスの生成を行う（ステップＳ４１４）。そしてＩＤｃｄ認証サーバ１００は、生成したチャレンジ及びレスポンスをサービス事業者４００のサーバに払い出す（ステップＳ４１５）。サービス事業者４００のサーバは、ＩＤｃｄ認証サーバ１００から払い出されたチャレンジ及びレスポンスをプリキャッシュする（ステップＳ４１６）。これにより、ＩＣカード３００の次回の認証時にサービス事業者４００と端末２００との間で完結させることが出来る。その様子を以下で説明する。
【００７４】
端末２００は、ポーリングを定期的に送出している（ステップＳ４１７）。このポーリングには、ＩＣカード３００からＩＤｍ及び鍵バージョンを取得するためのRequest  Serviceコマンドが含まれる。ＩＣカード３００は、端末２００から送出されるポーリングを受信すると、Request  Serviceコマンドに応じて端末２００へＩＤｍ及び鍵バージョンを返答する（ステップＳ４１８）。
【００７５】
端末２００は、自装置の端末ＩＤ及び、ステップＳ４０２でＩＣカード３００から取得したＩＤｍ及び鍵バージョンをサービス事業者４００のサーバに送信する（ステップＳ４１９）。サービス事業者４００のサーバは、端末２００から受信した端末２００の端末ＩＤ、ＩＣカード３００のＩＤｍ及び鍵バージョンに基づいて認証鍵を選択する（ステップＳ４２０）。そしてサービス事業者４００のサーバは、初回の認証時にはＩＤｃｄ認証サーバ１００へ、端末２００から受信した情報を転送していたが、ここでは、あらかじめ上記ステップＳ４１６でＩＤｃｄ認証サーバ１００から払い出されたチャレンジ及びレスポンスをプリキャッシュしているので、そのプリキャッシュしたチャレンジ及びレスポンスからチャレンジ及びレスポンスの選択を行う（ステップＳ４２１）。
【００７６】
サービス事業者４００のサーバは、プリキャッシュしたチャレンジ及びレスポンスから選択したチャレンジ及びレスポンスを端末２００に提供する（ステップＳ４２２）。端末２００は、翳されたＩＣカード３００を認証するためにチャレンジをＩＣカード３００に送信し（ステップＳ４２３）、ＩＣカード３００はそのチャレンジに対するレスポンスを生成して端末２００に返す（ステップＳ４２４）。端末２００は、サービス事業者４００のサーバから取得したレスポンスと、ＩＣカード３００が生成したレスポンスとを比較し（ステップＳ４２５）、ＩＣカード３００の認証を行う（ステップＳ４２６）。
【００７７】
またサービス事業者４００のサーバは、ＩＣカード３００の次回の認証のためのチャレンジ・レスポンスをあらかじめ取得するために、ＩＤｃｄ認証サーバ１００へ、端末２００から受信した情報を転送する（ステップＳ４２７）。ＩＤｃｄ認証サーバ１００は、サービス事業者４００のサーバから受信した情報に基づいてチャレンジ及びレスポンスの生成を行う（ステップＳ４２８）。そしてＩＤｃｄ認証サーバ１００は、生成したチャレンジ及びレスポンスをサービス事業者４００のサーバに払い出す（ステップＳ４２９）。サービス事業者４００のサーバは、ＩＤｃｄ認証サーバ１００から払い出されたチャレンジ及びレスポンスをプリキャッシュする（ステップＳ４３０）。
【００７８】
このように、ＩＣカード３００の認証時に、サービス事業者４００のサーバであらかじめプリキャッシュしたチャレンジおよびレスポンスを使用することで、サービス事業者４００と端末２００との間でＩＣカード３００の認証に関するやり取りを完結させることが出来る。
【００７９】
また、ＩＣカード３００の認証時に、サービス事業者４００のサーバであらかじめプリキャッシュしたチャレンジおよびレスポンスを使用することで、仮にサービス事業者４００のサーバとＩＤｃｄ認証サーバ１００との間の通信に問題があり、正常にデータの授受が出来ない場合であっても、ＩＣカード３００の認証が可能となる。
【００８０】
図１８は、ＩＤｃｄ認証サーバ１００と、サービス事業者４００と、端末２００と、ＩＣカード３００と、の動作例を示す流れ図である。
【００８１】
端末２００は、ポーリングを定期的に送出している（ステップＳ４３１）。このポーリングには、ＩＣカード３００からＩＤｍ及び鍵バージョンを取得するためのRequest  Serviceコマンドが含まれる。ＩＣカード３００は、端末２００から送出されるポーリングを受信すると、Request  Serviceコマンドに応じて端末２００へＩＤｍ及び鍵バージョンを返答する（ステップＳ４３２）。
【００８２】
端末２００は、自装置の端末ＩＤ及び、ステップＳ４０２でＩＣカード３００から取得したＩＤｍ及び鍵バージョンをサービス事業者４００のサーバに送信する（ステップＳ４３３）。サービス事業者４００のサーバは、端末２００から受信した端末２００の端末ＩＤ、ＩＣカード３００のＩＤｍ及び鍵バージョンに基づいて認証鍵を選択する（ステップＳ４３４）。続いて、サービス事業者４００のサーバはＩＤｃｄ認証サーバ１００へ、端末２００から受信した情報を転送するが、ここでサービス事業者４００のサーバとＩＤｃｄ認証サーバ１００との間の通信に問題があり、正常にデータの授受が出来ない状態が発生しているとする。するとサービス事業者４００のサーバは、あらかじめプリキャッシュしたチャレンジ及びレスポンスからチャレンジ及びレスポンスの選択を行う（ステップＳ４３５）。
【００８３】
サービス事業者４００のサーバは、プリキャッシュしたチャレンジ及びレスポンスから選択したチャレンジ及びレスポンスを端末２００に提供する（ステップＳ４３６）。端末２００は、翳されたＩＣカード３００を認証するためにチャレンジをＩＣカード３００に送信し（ステップＳ４３７）、ＩＣカード３００はそのチャレンジに対するレスポンスを生成して端末２００に返す（ステップＳ４３８）。端末２００は、サービス事業者４００のサーバから取得したレスポンスと、ＩＣカード３００が生成したレスポンスとを比較し（ステップＳ４３９）、ＩＣカード３００の認証を行う（ステップＳ４４０）。
【００８４】
このように、ＩＣカード３００の認証時に、サービス事業者４００のサーバであらかじめプリキャッシュしたチャレンジおよびレスポンスを使用することで、仮にサービス事業者４００のサーバとＩＤｃｄ認証サーバ１００との間の通信に問題があり、正常にデータの授受が出来ない場合であっても、ＩＣカード３００の認証が可能となる。
【００８５】
その後、サービス事業者４００のサーバとＩＤｃｄ認証サーバ１００との間の通信が回復すると、サービス事業者４００のサーバは、プリキャッシュしたチャレンジおよびレスポンスを削除し、また、ＩＤｃｄ認証サーバ１００から新たにチャレンジおよびレスポンスを取得しても良い。
【００８６】
なお、サービス事業者４００のサーバは、プリキャッシュしたチャレンジおよびレスポンスを、所定の時間が経過した時点で削除するようにしても良い。これにより、あまりにも古いチャレンジおよびレスポンスを認証に使用しないようにすることができる。例えば、サービス事業者４００のサーバは、定期的にプリキャッシュしたチャレンジおよびレスポンスを削除してもよい。また、サービス事業者４００のサーバは、所定のタイミングに達した時点でプリキャッシュしたチャレンジおよびレスポンスを削除してもよい。
【００８７】
例えば、電車やバス、飛行機などの交通機関の乗車の際にＩＣカード３００による認証を利用する場合、サービス事業者４００のサーバは、あらかじめ予約人数分だけチャレンジおよびレスポンスをプリキャッシュしておいてもよい。そしてサービス事業者４００のサーバは、プリキャッシュしたチャレンジおよびレスポンスを、発車時間を過ぎた時点で削除するようにしてもよい。従って、ＩＤｃｄ認証サーバ１００は、チャレンジおよびレスポンスを生成する際に、有効期限の情報を付加しても良い。また、サービス事業者４００のサーバは、チャレンジおよびレスポンスをプリキャッシュする際に、有効期限の情報を付加しても良い。
【００８８】
これにより、サービス事業者４００のサーバは、ＩＤｃｄ認証サーバ１００との間の通信をおこなわずにＩＣカード３００による認証を実施できる。さらにサービス事業者４００のサーバは、必要の無い、プリキャッシュしたチャレンジおよびレスポンスを削除することで、チャレンジおよびレスポンスの流出を防ぎ、セキュリティの向上を図ることができる。
【００８９】
（実施例５）
５つ目の実施例として、ＩＣカードによる認証を利用したＭＩＴＢ（Man  In  The  Browser）対策などの不正送金対策を目的とした実施例を説明する。
【００９０】
インターネットに接続可能な通信機器の爆発的な普及により、インターネットを経由したＥコマース決済や、可搬性のある端末での決済が可能なｍＰＯＳ決済が普及している。カード認証や本人認証はＥＭＶ仕様により厳格に決められているが、取引認証については整理途上の段階にあり、決済に使用されるインターネットブラウザや、ｍＰＯＳ決済を実行する端末の信頼性に依存する所が大きい。
【００９１】
そのため、決済する側が悪意を持って決済額を変更するような不正を行ってしまうと、決済される側に損害が与えられるおそれがある。例えば、ｍＰＯＳ端末を使用して１０００円の買い物をしたつもりが、実際には１万円の決済になってしまうという例が考えられる。図１９は、決済する側が不正により決済額を変更する様子を示す説明図である。実際には１０００円の買い物をしており、ユーザが決済額を確認して了承ボタンを押下したり、所定のセキュリティコードを入力したりした上で、カードをリーダライタに翳せば１０００円の決済が行われる。しかし、決済する側が実際には１万円で決済額を設定してしまっていれば、店舗から決済サーバに送られる取引情報としては１万円の取り引きとなってしまい、決済サーバ（サービス事業者４００のサーバ）では１万円の決済が行われてしまう。
【００９２】
そこで、以下の説明では、そのような不正を防止することが可能な仕組みについて説明する。図２０は、決済する側の不正を防止することを目的とした仕組みを示す説明図である。
【００９３】
例えば、１０００円をする場合、ｍＰＯＳ端末は、日付及び購入金額をバーコード化し、そのバーコード情報をハッシュ化した上で、Authentication1コマンドをリーダライタ（端末２００）からＩＣカード３００へ送信する。商品の購入者はｍＰＯＳ端末に所定のセキュリティコードを入力した上で、ＩＣカード３００をリーダライタ（端末２００）に翳す。これにより、ＩＣカード３００はAuthentication1コマンドに応じたレスポンスを生成する。
【００９４】
その後、商品の購入者は実際に代金を支払うために、例えば非接触通信機能を備えるクレジットカード等のＥＭＶカードをリーダライタに翳して決済する。ここで、決済する側が悪意を持って決済額を１万円に変更するような不正を行うと、取引情報の決済額が１万円となって決済サーバに送られる。しかし、あらかじめＩＣカード３００を使用した認証時に、１０００円の買い物をしたことに対するレスポンスが生成されているので、決済サーバは、レスポンスと取引情報とを照合して、決済額の不一致の検出が可能となる。なお、レスポンスと取引情報とを照合するのは決済サーバではなく、ＩＤｃｄ認証サーバ１００が実行しても良い。ＩＤｃｄ認証サーバ１００がレスポンスと取引情報とを照合する場合、決済サーバは、そのＩＤｃｄ認証サーバ１００による照合結果を受け取り、決済額が一致しているという判定が下された場合に決済処理を実行することになる。
【００９５】
（実施例６）
６つ目の実施例として、ＩＣカードによる認証を利用した個人間の安全かつ簡便な送金を目的とした実施例を説明する。
【００９６】
通常、個人間で送金取引を行う場合、それぞれの個人が使用する金融機関等で共通の決済サーバや取引サーバといった装置の介在が必要であった。しかし、インターネットに接続可能な通信機器の爆発的な普及により、インターネットを経由した決済の利便性が向上し、それに伴って安全かつ簡便な送金手法が求められている。
【００９７】
そこで、上述してきたＩＣカードによる認証を、本人認証だけでなく、取引内容の認証にも用いるようにすることで、それぞれの個人が使用する金融機関等で決済サーバや取引サーバが異なっていても、それぞれの金融機関で共通の認証機能として連携が可能となる。
【００９８】
図２１は、ＩＣカードによる認証を利用した個人間の送金処理を説明する説明図である。ここでは、第１のユーザから第２のユーザへ１０００円を送金する場合の送金処理について説明する。第１のユーザの端末２００は、第１のユーザのＩＣカード３００に対して、取引情報のハッシュを含んだチャレンジを送信する。第１のユーザのＩＣカード３００は、第１のユーザの端末２００から受信したチャレンジに対するレスポンスを生成する。このレスポンスには、第１のユーザから第２のユーザへ１０００円を送金するという取引情報の署名が含まれる。そして、第１のユーザの端末２００は、第２のユーザの端末２００へ、第１のユーザのＩＣカード３００が生成したレスポンスを送信する。
【００９９】
第２のユーザの端末２００は、第１のユーザのＩＣカード３００が生成したレスポンスを受信すると、第２のユーザのＩＣカード３００に対して、そのレスポンスに含まれる、第１のユーザのＩＣカード３００の署名が付いた取引情報のハッシュをチャレンジとして送信する。第２のユーザのＩＣカード３００は、第２のユーザの端末２００から受信したチャレンジに対するレスポンスを生成する。このレスポンスには、第１のユーザから第２のユーザへ１０００円を送金するという取引情報の署名が含まれる。そして、第２のユーザの端末２００は、決済サーバへ、第２のユーザのＩＣカード３００が生成したレスポンスを送信する。
【０１００】
決済サーバ（サービス事業者４００のサーバ）は、第１のユーザのＩＣカード３００が生成したレスポンス及び第２のユーザのＩＣカード３００が生成したレスポンスを受信する。決済サーバは、双方のレスポンスをＩＤｃｄ認証サーバ１００へ送信する。ＩＤｃｄ認証サーバ１００は、決済サーバから受信した２つのレスポンスを照合し、２つのＩＣカード３００の真正性の確認と、取引情報の署名の正当性の確認と、を行う。なお、ＩＤｃｄ認証サーバ１００は、あくまでＩＣカード３００の真正性の確認と、取引情報の署名の正当性の確認と、を行い、取引情報の内容には関知しない。そしてＩＤｃｄ認証サーバ１００は、決済サーバから受信した２つのレスポンスが正当であることが確認出来れば、決済サーバに対して、第１のユーザから第２のユーザへの送金を許可する旨のメッセージを送る。決済サーバは、第１のユーザから第２のユーザへの送金を許可する旨のメッセージをＩＤｃｄ認証サーバ１００から受信すると、第１のユーザの口座から第２のユーザの口座へ１０００円を送金する処理を実行する。
【０１０１】
このような一連の処理により、ＩＣカードによる認証を利用した個人間の安全かつ簡便な送金が可能となる。
【０１０２】
＜２．まとめ＞
以上説明したように本開示の実施の形態によれば、オンラインだけでなく、オフラインで利用することを想定したＩＣカードを、サーバにバリューを保持した形態に流用する際に、安全にＩＣカードの認証を行うことが可能なＩＤｃｄ認証サーバ１００を提供することが出来る。
【０１０３】
本明細書の各装置が実行する処理における各ステップは、必ずしもシーケンス図またはフローチャートとして記載された順序に沿って時系列に処理する必要はない。例えば、各装置が実行する処理における各ステップは、フローチャートとして記載した順序と異なる順序で処理されても、並列的に処理されてもよい。
【０１０４】
また、各装置に内蔵されるＣＰＵ、ＲＯＭおよびＲＡＭなどのハードウェアを、上述した各装置の構成と同等の機能を発揮させるためのコンピュータプログラムも作成可能である。また、該コンピュータプログラムを記憶させた記憶媒体も提供されることが可能である。また、機能ブロック図で示したそれぞれの機能ブロックをハードウェアで構成することで、一連の処理をハードウェアで実現することもできる。
【０１０５】
なお、上記の各実施例にはＩＣカードを示したが、ＩＣカードは、非接触通信機能を有するＩＣチップを備えたスマートフォン等の携帯端末であってもよい。
【０１０６】
以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
【０１０７】
また、本明細書に記載された効果は、あくまで説明的または例示的なものであって限定的ではない。つまり、本開示に係る技術は、上記の効果とともに、または上記の効果に代えて、本明細書の記載から当業者には明らかな他の効果を奏しうる。
【０１０８】
なお、以下のような構成も本開示の技術的範囲に属する。
（１）
ＩＣチップを備えた無線通信装置との間で近接非接触通信を行う端末に対して該無線通信装置の認証のための認証データを提供する提供部と、
前記端末から、前記認証データの利用回数を含んだ、前記無線通信装置との間の近接非接触通信により受信した受信データを取得する取得部と、
前記認証データと前記受信データとを用いて前記無線通信装置の認証を行う認証部と、
を備える、サーバ。
（２）
前記提供部は、前記無線通信装置の認証に先立ち、複数の前記認証データを事前に前記端末に提供する、前記（１）に記載のサーバ。
（３）
前記提供部が提供する前記認証データは、最後に認証が行われた際の認証データに基づいて生成されたものである、前記（１）または（２）に記載のサーバ。
（４）
前記提供部は、認証の対象となる無線通信装置の認証時に前記端末から該無線通信装置へ提供するチャレンジと、前記チャレンジに応じて該無線通信装置から前記端末へ返答されるレスポンスとの組を、前記無線通信装置の認証に先立ち前記端末に提供する、前記（１）〜（３）のいずれかに記載のサーバ。
（５）
前記認証部は、第１の無線通信装置からの第１の受信データと、第２の無線通信装置からの第２の受信データとを用いて前記第１の無線通信装置及び前記第２の無線通信装置の認証を行う、前記（１）〜（４）のいずれかに記載のサーバ。
（６）
前記認証部は、前記第１の無線通信装置及び前記第２の無線通信装置の認証結果に基づき、前記第１の無線通信装置のユーザと前記第２の無線通信装置のユーザとの間の送金処理の可否を決定する、前記（５）に記載のサーバ。
（７）
前記認証部は、前記無線通信装置からの受信データと、取引データと、を用いて、前記取引データの真正性の確認を行う、前記（１）〜（４）のいずれかに記載のサーバ。
（８）
前記無線通信装置は、ＩＣチップを内蔵したＩＣカードである、前記（１）〜（７）のいずれかに記載のサーバ。
（９）
前記無線通信装置は、ＩＣチップを内蔵した携帯端末である、前記（１）〜（７）のいずれかに記載のサーバ。
（１０）
ＩＣチップを備えた無線通信装置との間で近接非接触通信を行う端末に対して提供する、該無線通信装置の認証のための認証データを、前記認証データを生成する装置より取得し、取得した前記認証データを前記端末への提供に先立ってキャッシュする、サーバ。
（１１）
前記端末が前記無線通信装置を認証する際に、キャッシュした前記認証データを前記端末へ提供する、前記（１０）に記載のサーバ。
（１２）
前記無線通信装置の認証に際して、前記装置との通信が出来ない場合において、キャッシュした前記認証データを前記端末へ提供する、前記（１１）に記載のサーバ。
（１３）
所定のタイミングでキャッシュした前記認証データを削除する、前記（１０）に記載のサーバ。
（１４）
所定のタイミングとして前記認証データの有効期限が経過した時点でキャッシュした前記認証データを削除する、前記（１３）に記載のサーバ。
（１５）
所定のタイミングとして前記装置との通信が回復するとキャッシュした前記認証データを削除する、前記（１３）に記載のサーバ。
（１６）
前記無線通信装置は、ＩＣチップを内蔵したＩＣカードである、前記（１０）〜（１５）のいずれかに記載のサーバ。
（１７）
前記無線通信装置は、ＩＣチップを内蔵した携帯端末である、前記（１０）〜（１５）のいずれかに記載のサーバ。
（１８）
ＩＣチップを備えた無線通信装置との間で近接非接触通信を行う端末に対して該無線通信装置の認証のための認証データを提供することと、
前記端末から、前記認証データの利用回数を含んだ、前記無線通信装置との間の近接非接触通信により受信した受信データを取得することと、
前記認証データと前記受信データとを用いて前記無線通信装置の認証を行うことと、
を含む、認証方法。
（１９）
ＩＣチップを備えた無線通信装置と、
前記無線通信装置との間で近接非接触通信を行う端末と、
前記端末に対して該無線通信装置の認証のための認証データを提供するサーバと、
を備え、
前記サーバは、
前記認証データを提供する提供部と、
前記端末から、前記認証データの利用回数を含んだ、前記無線通信装置との間の近接非接触通信により受信した受信データを取得する取得部と、
前記認証データと前記受信データとを用いて前記無線通信装置の認証を行う認証部と、
を備える、認証システム。
【符号の説明】
【０１０９】
１００    ＩＤｃｄ認証サーバ
２００    端末
３００    ＩＣカード
【図１】
2018150931.tif 000003
【図２】
2018150931.tif 000004
【図３】
2018150931.tif 000005
【図４】
2018150931.tif 000006
【図５】
2018150931.tif 000007
【図６】
2018150931.tif 000008
【図７】
2018150931.tif 000009
【図８】
2018150931.tif 000010
【図９】
2018150931.tif 000011
【図１０】
2018150931.tif 000012
【図１１】
2018150931.tif 000013
【図１２】
2018150931.tif 000014
【図１３】
2018150931.tif 000015
【図１４】
2018150931.tif 000016
【図１５】
2018150931.tif 000017
【図１６】
2018150931.tif 000018
【図１７】
2018150931.tif 000019
【図１８】
2018150931.tif 000020
【図１９】
2018150931.tif 000021
【図２０】
2018150931.tif 000022
【図２１】
2018150931.tif 000023
【国際調査報告】
2018150931.tif 000024
2018150931.tif 000025
2018150931.tif 000026
2018150931.tif 000027