JP2000078128A - 通信システム及びｉｃカード並びに記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 通信の一方から他方に対する情報メッセージ
がたとえ悪意の第三者に盗まれた場合でも、一度利用さ
れた通信メッセージを再利用するリプライアタック等の
不正使用を防止することができる。 【解決手段】 ネットワークを通してメッセージを送信
するとともに、そのメッセージに付加された検証用情報
を評価して当該メッセージの正当性を確認する通信シス
テムであって、メッセージ発信毎に異なった検証用情報
を生成し、メッセージに付加する送信側システム３２０
と、毎回異なる前記検証用情報の正当性を確認する受信
側システム３３０とを備えた通信システム。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は通信システム及び
記録媒体、更に詳しくはネットワーク等を介してやり取
りされる電子情報の不正使用を防止する部分に特徴のあ
る通信システム及びＩＣカード並びに記録媒体に関する
ものである。

【０００２】

【従来の技術】近年の計算機通信技術の発達により、イ
ンターネット等の開かれたネットワークを介して各種の
通信を行い、また、この通信により商取引さえも行われ
るようになってきている。

【０００３】公衆ネットワーク等を介して商取引通信を
行う場合、悪意の第三者から通信者を適切に保護するこ
とが特に重要になる。このため、その通信メッセージに
おいては、銀行口座番号やパスワードといったような重
要情報を暗号化することで不正使用を防止するのが一般
的である。

【０００４】図１５は従来の通信システムによる商取引
時のメッセージ授受を示す図である。同図に示すよう
に、商取引システムの利用者は、その通信メッセージの
うち、口座番号及びパスワードを暗号化し、これに商品
名、取引数量及びヘッダを暗号化せずに付加して通信メ
ッセージを作成する。こうして作成されたメッセージが
取引サーバに送信される。

【０００５】また、特開平９−８１６３４号公報（「ネ
ットワークの課金方法」）に開示されるように、使い切
り型の暗号情報そのものを取引情報の単位とするような
方法もある。

【０００６】

【発明が解決しようとする課題】このように、従来技術
では商取引に関する通信メッセージ等において、銀行口
座番号とパスワードや発注商品名、数量といった重要情
報を暗号化して使用する。

【０００７】しかし、情報に暗号化がなされていても、
当該メッセージ自体が第三者による悪用される場合があ
る。図１６は悪意の第三者が商取引システム利用者の通
信メッセージを悪用する様子を示す図である。

【０００８】商取引メッセージに暗号化がなされていて
も、ある元の情報に対する暗号結果が同一となる場合に
は、たとえ暗号化を行っても結果メッセージは不変であ
ることが問題である。この場合、悪意の第三者により暗
号化された取引きメッセージがネットワーク上で取得さ
れ盗まれてしまうと、この盗まれたメッセージ自体が悪
用される。つまり当該メッセージを送信先（商取引シス
テム）へ再度送り付けても、商取引システム側では悪意
の第三者が利用者になりすましていることがわからない
ので、利用者の意図しない商取引が成立してしまうこと
になる。

【０００９】このような妨害行為をリプライアタックと
いうが、リプライアタックが頻繁に行われてしまって
は、商取引の安全が介されることになり、当該公衆ネッ
トワークを介する商取引システムの存立自体が危ぶまれ
ることになる。図１５に示すように、口座番号等のみで
なく、発注情報等に暗号化がなされている場合でもリプ
ライアタックに対する防御としては有効性が低い。

【００１０】また、このようなリプライアタックによる
被害は、商取引システムのみで生じるものではない。一
般の通信システムにおいても、リプライアタックによる
なりすましが横行すると、公衆回線を介する便利な通信
システムを安全に運用することが困難になる。

【００１１】本発明は、このような実情を考慮してなさ
れたもので、通信の一方から他方に対する情報メッセー
ジがたとえ悪意の第三者に盗まれた場合でも、一度利用
された通信メッセージを再利用するリプライアタック等
の不正使用を防止することができる通信システム及びＩ
Ｃカード並びに記録媒体を提供することを目的とする。

【００１２】

【課題を解決するための手段】上記課題を解決するため
に、請求項１に対応する発明は、ネットワークを通して
メッセージを送信するとともに、そのメッセージに付加
された検証用情報を評価して当該メッセージの正当性を
確認する通信システムについてなされたものである。

【００１３】このシステムにおいては、送信側システム
にからメッセージ発信毎に異なった検証用情報が生成さ
れ、メッセージに付加される。一方、受信側システムで
は、毎回異なる検証用情報の正当性が確認される。

【００１４】このように１回限りの検証用情報を用いて
メッセージの正当性を確認するので、第三者の妨害行為
を有効に防止することができる。次に、請求項２に対応
する発明は、請求項１に対応する発明において、送信側
システムにおいては、検証用情報生成手段により元とな
る情報を変換することで検証用情報が生成される。

【００１５】また、この元となる情報には、送信側カウ
ンタ手段により、メッセージ発信毎にカウントされるカ
ウンタ値を少なくとも含められる。この元となる情報は
例えばカウンタ値自体であってもよいし、また例えば所
定のシードにカウンタ値を組み合わせたものでもよい。

【００１６】したがって、カウンタの進行により、検証
用情報の生成元となる情報自体がメッセージ発信毎に変
更され、通信の安全性が確保される。次に、請求項３に
対応する発明は、請求項２に対応する発明において、受
信側システムにおいては、受信側カウンタ手段により、
送信側システムでカウントされるカウント値と同期させ
たカウント値が管理されている。

【００１７】また、受信側システムには、検証情報再現
手段によって、受信側カウンタ手段に管理されたカウン
ト値を含めて得られる，元となる情報と同一の情報が変
換されて、検証用情報が生成される。

【００１８】こうして検証用情報再現手段で再現された
検証用情報とメッセージ内の検証用情報とが、正当性評
価手段により比較照合され、当該メッセージの正当性が
確認される。

【００１９】したがって、通信の一方から他方に対する
情報メッセージがたとえ悪意の第三者に盗まれた場合で
も、一度利用された通信メッセージを再利用するリプラ
イアタック等の不正使用を防止することができる。

【００２０】次に、請求項４に対応する発明は、請求項
１に対応する発明において、送信側システムにおいて
は、送信側カウンタ手段によって、メッセージの検証用
情報に、メッセージ発信毎にカウントされるカウンタ値
が少なくとも含められている。

【００２１】一方、受信側システムにおいては、受信側
カウンタ手段により、送信側システムでカウントされる
カウント値と同期させたカウント値が管理されている。
そして、正当性評価手段により、メッセージの検証用情
報からカウント値が取り出されるとともに、受信側カウ
ンタ手段に管理されるカウント値に基づき、受信メッセ
ージ内のカウント値が既にカウント済みの値であると判
断されたときには、当該メッセージが不正と判定され
る。

【００２２】したがって、通信の一方から他方に対する
情報メッセージがたとえ悪意の第三者に盗まれた場合で
も、一度利用された通信メッセージを再利用するリプラ
イアタック等の不正使用を防止することができる。

【００２３】次に、請求項５に対応する発明は、請求項
２に対応する発明における送信側システムをコンピュー
タに実現させるプログラムを記録した記録媒体である。
この記録媒体から読み出されたプログラムにより制御さ
れるコンピュータは、請求項２の通信システムのうち送
信側システムとして機能する。

【００２４】次に、請求項６に対応する発明は、請求項
３に対応する発明における受信側システムをコンピュー
タに実現させるプログラムを記録した記録媒体である。
この記録媒体から読み出されたプログラムにより制御さ
れるコンピュータは、請求項３の通信システムのうち受
信側システムとして機能する。

【００２５】次に、請求項７に対応する発明は、請求項
４に対応する発明における受信側システムをコンピュー
タに実現させるプログラムを記録した記録媒体である。
この記録媒体から読み出されたプログラムにより制御さ
れるコンピュータは、請求項４の通信システムのうち受
信側システムとして機能する。

【００２６】次に、請求項８に対応する発明は、請求項
２〜４に対応する発明における送信側システムの送信側
カウンタ手段を実現するＩＣカードである。したがっ
て、このＩＣカードが挿入されてなるコンピュータシス
テムは、請求項２〜４に対応する発明の送信システムを
実現する。

【００２７】次に、請求項９に対応する発明は、請求項
２又は３に対応する発明における送信側システムの検証
用情報生成手段及び送信側カウンタ手段を実現するＩＣ
カードである。したがって、このＩＣカードが挿入され
てなるコンピュータシステムは、請求項２又は３に対応
する発明の送信システムを実現する。

【００２８】

【発明の実施の形態】以下、本発明の実施の形態につい
て説明する。 （発明の第１の実施の形態）本実施形態の通信システム
では、銀行口座番号やパスワード等の重要情報を含む暗
号化メッセージが固定的なものとならず、１度の通信に
おいてのみ有効となる仕組みを設ける。これにより、暗
号化された重要情報を再使用するリプライアタックを不
可能とし、悪意の第三者による重要情報の不正使用を防
止するものである。

【００２９】図１は本発明の第１の実施の形態に係る通
信システムを適用した商取引システムの全体構成例を示
す図である。同図は物理的構成要素を示すハードウエア
構成図である。利用者側のパーソナルコンピュータであ
るクライアントＰＣ３０１は、実際に銀行や商店といっ
た商取引を提供するための計算機群３０６，３０８，３
１０，３１２（以下、単にサーバともいう）で構成され
た商取引サービスシステム３３０と取引を行う。利用者
であるクライアント側システム３２０と商取引サービス
システム３３０と間は、公衆ネットワークとしてのイン
ターネット３０４を介して接続されて通信システムを構
成し、取引メッセージがやり取りされる。

【００３０】クライアント側システム３２０は、クライ
アントＰＣ３０１，ＩＣカード読取／書込装置３０２及
びＩＣカード３０３から構成されている。一方、商取引
サービスシステム３３０は、ルータ３０５、公開用ＷＷ
Ｗサーバ３０６、ファイアウォール３０７、取引サーバ
３０８、認証サーバ３１０及びＩＣカード発行装置３１
２から構成されている。また、取引サーバ３０８には取
引データベース３０９が、認証サーバ３１０及びＩＣカ
ード発行装置３１２には認証データベース３１１が接続
される。

【００３１】以下に各要素の説明をする。クライアント
ＰＣ３０１は、商取引を利用する際に利用者が使用する
パーソナルコンピュータである。ワークステーション等
から構成されていてもよい。

【００３２】ＩＣカード読取／書込装置３０２は、ＩＣ
カード３０３と商取引サービスシステム３３０との情報
のやり取りを行う接点である。また、ＩＣカード３３０
は、利用者本人の利用であることを物理的に確認する手
段である。

【００３３】ルータ３０５は、インターネット３０４と
商取引サービスシステム３３０内のネットワークとの物
理的接点である。公開用ＷＷＷサーバ３０６は、商取引
サービスシステム３３０における外部からのアクセスを
受ける１次窓口である。商取引を行う取引サーバ３０８
等が直接不正攻撃されることを防ぐために設けられる。

【００３４】ファイアウォール３０７は、不正防止のた
め外部からのアクセスを制限する。取引サーバ３０８
は、インターネット３０４上で商取引サービスを提供す
る。また、取引データベース３０９は、商取引に関する
データを格納し、取引サーバ３０８と情報のやり取りを
する。

【００３５】認証サーバ３１０は、利用者から送信され
た認証用データをもとに利用者認証を行う。また、認証
データベース３１１は、利用者（ＩＣカード３０３）ご
とに認証に必要な情報を格納する。

【００３６】ＩＣカード発行装置３１２は、認証データ
ベース３１１と連携して新規のＩＣカード３０３を発行
する。次に各部の機能構成を説明する。

【００３７】図２は本実施形態の通信システムにおける
各部の機能構成を示すブロック図である。クライアント
ＰＣ３０１には、インターネットとの通信における各種
サービスを提供するブラウザ４０２、ＩＣカード読取／
書込装置３０２との入出力を行うＩＣカードＡＰＩ４０
４及びクライアント側プロキシ４０３とが設けられてい
る。また、クライアント側プロキシ４０３は、クライア
ントＰＣ３０１上のインターネット３０４への接続等の
処理を担当するとともに、本システムによる商取引を行
う際にメッセージに必要な加工等を行う。

【００３８】一方、取引サーバ３０８には、クライアン
ト側プロキシ４０３で加工されたメッセージに対応した
処理を行うサーバ側プロキシ４１１、暗号化／復号化処
理部４１４，ＨＴＴＰサーバ４１２及びＣＧＩプログラ
ム４１３が設けられている。

【００３９】また、認証サーバ３１０及びＩＣカード発
行装置３１２には、それぞれ認証プロセス４１６及び発
行情報生成プロセス４１９が設けられる。ファイアウォ
ール３０７にはＨＴＴＰプロキシ４２０が設けられてい
る。

【００４０】次に、以上のように構成された本実施形態
における通信システム動作について説明する。ネットワ
ーク上での商取引は一つの取引きに対して数段階ある手
続きごとにメッセージのやり取りを行い、すべての段階
が終了することで取引き完了となるのが通常である。本
実施形態ではこのうち本人認証を行う「本人認証処理」
を説明し、さらに、この本人認証の仕組みを用いた利用
者から商取引サービスシステム３３０へのメッセージ通
信について説明する。

【００４１】［本人認証処理］図３はクライアント側シ
ステムを操作する利用者が本人に間違いないことを確認
する本人認証処理の処理概要を示す図である。

【００４２】まず、クライアントＰＣ３０１上のブラウ
ザ４０２に表示される認証画面から利用者によりＩＣカ
ード３０３の所有者本人であることを証明するための暗
証番号（以下、ＰＩＮ（Ｐｅｒｓｏｎａｌ ｌｄｅｎｔ
ｉｆｉｃａｔｉｏｎ Ｎｕｍｂｅｒ）ともいう）と取引
サービスに登録されている利用者番号（以下、ユーザＩ
Ｄという）が入力される。この入力に対応し、ＩＣカー
ド３０３により、ＰＩＮを使用した利用者認証が行われ
る（ｓ１）。

【００４３】ＩＣカード３０３によって、クライアント
ＰＣ３０１を操作している者が本人であると認証される
と、次に、ＩＣカード認証要求データが作成、暗号化さ
れる（ｓ２，ｓ３）。これに必要なヘッダが付加されて
メッセージ送信されることで、認証サーバへＩＣカード
自体の認証が要求される（ｓ４）。

【００４４】このカード認証要求メッセージは、ファイ
アウォール３０７のＨＴＴＰプロキシ４２０により中継
され（ｓ５）、取引サーバ３０８にてカード認証データ
が取り出されて（ｓ６）、認証サーバ３１０にて認証さ
れる（ｓ７，ｓ８）。ＩＣカード認証後（ｓ８）、応答
データが作成され暗号化されて認証応答としてクライア
ントＰＣ３０１に返信される（ｓ９，ｓ１０，ｓ１
１）。

【００４５】このＩＣカード３０３の商取引サービスシ
ステム３３０による認証結果は、ブラウザ４０２から表
示される（ｓ１２）。なお、クライアントＰＣ３０１か
らの通信メッセージには、ＩＣカード３０３により生成
される毎回使い切り型のフレーズ（以下、ＯＴＰ（Ｏｎ
ｅ ＴｉｍｅＰｈｒａｓｅ）という）が組み込まれ、同
じパターンのメッセージが複数回流れないようになって
いる。

【００４６】次に、図３で説明した各処理についてさら
に詳しく説明する。 （ＰＩＮによるカード使用者の認証）図３におけるステ
ップｓ１の処理について説明する。

【００４７】図４はＰＩＮによるカード使用者の認証処
理を示す図である。まず、取引サーバ３０８に接続する
ためにブラウザ４０２から当該取引サーバのインターネ
ット（ｉｎｔｅｒｎｅｔ）アドレス（以下、“ＵＲＬ”
（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏ
ｒ）という）が利用者により入力される。この時、利用
者がＩＣカード３０３の正当な所有者であることの確認
をすることが必要となる。

【００４８】したがって、利用者がブラウザに取引サー
バのＵＲＬを入力し接続要求（以下、“ＨＴＴＰ ＧＥ
Ｔ要求”という）を出すと（ｔ１）、クライアント側プ
ロキシ４０３は、そのＵＲＬから取引サーバ３０８に接
続する要求であることを認識する。このときクライアン
ト側プロキシ４０３はブラウザ４０２からのＨＴＴＰＧ
ＥＴ要求を一時保管しておく。

【００４９】クライアント側プロキシ４０３は、接続要
求を出した利用者がＩＣカード読取／書込装置３０２に
装着されたＩＣカード３０３の所有者であり、かつ取引
システムの利用者であることを認識するために、ＩＣカ
ード３０３のＰＩＮとユーザＩＤを入力させる画面をブ
ラウザ４０２上に表示させる（ｔ２）。

【００５０】この表示に対応して、利用者がブラウザ４
０２からＰＩＮとユーザＩＤを入力すると（ｔ３）、ク
ライアント側プロキシ４０３は入力情報をＩＣカードＡ
ＰＩ４０４、ＩＣカード読取／書込装置３０２を介して
ＩＣカード３０３に送り、ＰＩＮによる利用者認証を要
求する（ｔ４）。

【００５１】ＩＣカード３０３は受け取ったＰＩＮによ
る利用者認証を行い（ｔ５）結果をクライアント側プロ
キシ４０３に送る。認証が成功した場合には個々のＩＣ
カード識別するためにＩＣカード３０３が生成する情報
（以下、“ＩＣカード識別情報”という）も上記結果と
一緒に送信する（ｔ６）。 （ＩＣカード認証要求メッセージの生成）主に図３にお
けるステップｓ２，ｓ３の処理について説明する。

【００５２】クライアントＰＣ３０１上のクライアント
側プロキシ４０３は、取引サーバ３０８にＩＣカード３
０３の認証を要求するために送信するデータ集合（以
下、“ＩＣカード認証要求メッセージ”という）を生成
する。

【００５３】生成したメッセージを取引サーバへ送信す
る際に悪意の第三者がメッセージを横取りし、再度取引
サーバへ送り付けるリプライアタックを受ける可能性が
ある。これを防ぐためにクライアント側プロキシ４０３
は同じ意味を持つメッセージを送信する場合でも毎回異
なるパターンを持つようにＯＴＰを組み込む。

【００５４】以下、ＩＣカード認証要求メッセージの生
成を順に説明する。図５はＩＣカード認証用データの生
成し、さらにＩＣカード認証要求メッセージを作成する
様子を示す図である。

【００５５】クライアント側プロキシ４０３は、まずＯ
ＴＰ生成要求を作成し（ｕ１）、ＩＣカード３０３に対
してこのＯＴＰ生成要求を通知する（ｕ２）。この要求
は、図４のＰＩＮ認証要求（ｔ４）を行う際に含められ
る。

【００５６】ＩＣカード３０３は、正当ユーザと認証し
た場合には（ｔ５）、ＯＴＰを生成する（図５：ｕ
３）。ＯＴＰの生成は次にように行われる。

【００５７】まず、ＩＣカード３０３はカード内に持っ
ているＯＴＰの種（以下、“シード”という）とカウン
タを備えている。このシードは商取引サービスシステム
３３０の認証サーバ３１０が保持するシード群の１つと
同一のものである。また、認証サーバ３１０には各ＩＣ
カード３０３に対応したカウンタも設けられており、後
述するように各ＯＴＰカウンタ値に対するＯＴＰ生成が
可能となっている。

【００５８】ＩＣカード３０３は、シードとカウンタ値
をもとにしてＯＴＰを生成する。このＯＴＰの生成では
例えば一方向性関数を用いる等し、当該ＯＴＰからシー
ドを復元できないようにしてシードの秘匿性を担保す
る。

【００５９】ＯＴＰ生成後、ＩＣカード３０３はＯＴＰ
カウンタの値を一つ減らし、ＯＴＰ及びその一つ減らし
たＯＰＴカウンタ値をクライアント側プロキシ５０１へ
送信する（図５：ｕ４）。

【００６０】ＯＴＰ及びＯＰＴカウンタ値を受け取った
クライアント側プロキシ４０３は、カード使用者の認証
処理のステップｔ３にて保存しておいたユーザＩＤ、Ｉ
Ｃカード識別情報等の取引サーバ３０８での認証に必要
なデータをこれに加え、ＩＣカード認証用データという
決められた形にまとめる（ｕ５）。

【００６１】図６はＩＣカード認証用データを示す図で
ある。このＩＣカード認証用データ５０１は、ユーザＩ
Ｄ５０２、ＩＣカード識別情報５０３、ＯＴＰ５０４及
びＯＴＰカウンタ５０５からなる。

【００６２】図７はＩＣカード認証要求メッセージフォ
ーマットを示す図である。ステップｕ５で作成されたＩ
Ｃカード認証用データ５０１は暗号化され、この暗号化
されたＩＣカード認証用データ６０５に識別文字６０
２、バージョン番号６０３及び要求内容６０４が付加さ
れてエクステンションヘッダ６０１（ｅｘｔｅｎｓｉｏ
ｎ−ｈｅａｄｅｒ）として生成される。

【００６３】なお、識別文字６０２は取引サーバへの要
求であることを識別させるための文字であり、バージョ
ン番号６０３は取引システムのバージョンを示すもので
ある。また、要求内容６０４は、メッセージの要求内容
を示すものであり、取引要求や認証要求等がある。この
場合は、ＩＣカード認証要求である。

【００６４】ここまでの処理は、クライアント側プロキ
シ４０３が行い、引き続き、ブラウザ４０２による処理
でＨＴＴＰに従うＩＣカード認証要求メッセージ６０６
が作成される（ｕ６）。

【００６５】なお、図７に示すように、ＩＣカード認証
要求メッセージ６０６は、リクエストライン６０８、ジ
ェネラルヘッダ６０９、リクエストヘッダ６１０、エン
ティティヘッダ６１１及びＣＲＬＦ６１２からなり、エ
クステンションヘッダ６は、エンティティヘッダ６１１
に組み込まれる。ＩＣカード認証要求メッセージ６０６
のエクステンションヘッダ６０１以外の部分はブラウザ
作成部分６０７である。 （ＩＣカード認証要求メッセージの送信）図３における
ステップｓ４，ｓ５の処理について説明する。

【００６６】図８はＩＣカード認証要求メッセージの送
信を示す図である。まず、クライアント側プロキシ４０
３はＩＣカード識別情報及び、ＰＩＮ認証の有効性を確
認した後、取引サーバ３０８へＩＣカード認証要求メッ
セージ６０６を送信する（ｖ１）。なお、ＩＣカード識
別情報等の有効性の確認というのは、例えば送信の直前
で利用者がＩＣカード３０３を抜いたり、違うカードに
変更していないかを確認する処理である。

【００６７】この送出されたメッセージ６０６は、ファ
イアウォール３０７のＨＴＴＰプロキシ４２０によって
中継され取引サーバ３０８に取得される（ｖ２）。な
お、ファイアウォール３０７には独自の利用者認証の機
能を持つ場合もあり、この機能が本実施形態に組み合わ
されていてもよい。 （ＩＣカード認証処理，認証応答処理）図３におけるス
テップｓ６〜ｓ１２の処理について説明する。

【００６８】図９は取引サーバ及び認証サーバによるＩ
Ｃカード認証処理を示す図である。図１０は同ＩＣカー
ド認証処理の流れ図である。なお、同図中ステップｘ１
〜ｘ３、ｘ８〜ｘ１０は取引サーバ３０８での処理、ｘ
４〜ｘ７は認証サーバ３１０での処理を示している。

【００６９】ＩＣカード認証要求メッセージ６０６を受
信した取引サーバ３０７は認証サーバ３１０と連携して
ＩＣカード認証処理を行う。このためにまず、取引サー
バ３０７上のサーバ側プロキシ４１１は受信したメッセ
ージ６０６のリクエストライン６０８より、ＨＴＴＰ
ＧＥＴ要求であることを判別する。つぎに、エクステン
ションヘッダ６１１の識別文字６０２から商取引サービ
スシステム３３０へのアクセスであることを判別する。
そして、バージョン番号６０３よりシステムのバージョ
ンと矛盾しないことを確認する。さらに、要求内容６０
４を見てＩＣカード３０３の認証要求であることを識別
する（図９：ｗ１，図１０：ｘ１）。

【００７０】次にサーバ側プロキシ４１１は暗号化され
ているＩＣカード３０３の認証のために必要な暗号化さ
れたＩＣカード認証用データ６０５を復号してＩＣカー
ド認証用データ５０１を取り出す（ｗ２，ｘ２）。

【００７１】復号されたＩＣカード認証用データ５０１
からユーザＩＤ５０２、ＩＣカード識別情報５０３、Ｏ
ＴＰカウンタ値５０５を取り出し認証サーバ３１０へＩ
Ｃカード認証を要求する（ｗ３，ｘ３）。

【００７２】要求を受信した認証サーバ３１０はユーザ
ＩＤ５０２、ＩＣカード識別情報５０３から利用者認証
（ＩＣカードの認証）を行う（ｗ４，ｘ４）。この認証
が成功した後（ｘ５）、自己管理しているその利用者
（ＩＣカード）のＯＴＰカウンタ値を含む認証用データ
（ＯＴＰシード）を認証データベース３１１より読み込
む。

【００７３】認証サーバ３１０は取引サーバ３０８より
受け取ったＯＴＰカウンタ値５０５が自己管理している
ＯＴＰカウンタ値より小さいことを確認する。ＯＴＰカ
ウンタ値が大きい場合は１度使用されたＯＴＰが再度送
信されてきた事を意味するので無効とする（ｗ５，ｘ
６）。

【００７４】ここで、各ＯＴＰカウンタ値は、次のよう
な意味を有する。もともとＩＣカードのＯＴＰカウンタ
値と、認証サーバ３１０が管理するＯＴＰカウンタ値と
は同一の値であり、同一シード及び同一カウンタ値から
ＯＴＰを作成した場合には、同一のＯＴＰが得られる。
しかし、メッセージ受信より得たカウンタ値５０５はＩ
Ｃカード３０３におけるＯＴＰ生成処理（図５：ｕ３）
により値が一つ減らされている。したがって、正当なメ
ッセージであれば、ＯＴＰカウンタ値５０５は自己が管
理するＯＴＰカウンタ値よりも１だけ小さな値となる。
そこで、この場合のみステップｘ７に進み、それ以外の
場合には、認証失敗として取引サーバ３０８に通知する
（ｘ１０）ようにしたのである。

【００７５】このＯＴＰカウンタ値は、クライアント側
システム３２０からメッセージが送信される度に減らさ
れ、このメッセージ受信に応じて認証サーバ３１０でも
減らされていく（ｘ７）。したがって、図１０のステッ
プｘ６又は後述するステップｘ８でＯＴＰ若しくはＯＴ
Ｐカウンタ値が正当であると評価されるのは、正当なク
ライアントＰＣ３０１から出力されたメッセージのもの
のみであり、なおかつ１回に限り正当であると評価され
る。

【００７６】さて、認証サーバ３１０は、上記ＯＴＰカ
ウンタ値の確認の後、ＯＴＰカウンタ値とＯＴＰシード
よりＩＣカード３０３における処理と同じ処理でＯＴＰ
を生成し、生成後自己が管理するＯＴＰカウンタ値を一
つ減らす（ｗ６，ｘ７）。そして、ＩＣカード認証結果
と再生成したＯＴＰを取引サーバ３０８へ送信する（ｗ
７）。

【００７７】ＯＴＰ等を受け取った取引サーバ３０８の
サーバ側プロキシ４１１は、クライアント側プロキシ４
０３より受け取ったＯＴＰ５０４と認証サーバ３１０に
より再生成されたＯＴＰとを比較し同一であるか否かを
確認する（ｗ８，ｘ８）。

【００７８】こうしてＩＣカード３０３の認証（＝本人
認証）が完了する。ここで、ステップｘ８でＩＣカード
の認証が成功した場合には、取引サーバ３０８は認証成
功の旨の応答メッセージを作成し（ｘ９）、その認証結
果をクライアントＰＣ３０１に送信する（ｘ１１，図
３：ｓ１１）。

【００７９】一方、ステップｘ５，ｘ６又はｘ８の何れ
かでカード認証が失敗した場合には、取引サーバ３０８
は認証失敗の旨の応答メッセージを作成し（ｘ１０）、
その認証結果をクライアントＰＣ３０１に送信する（ｘ
１１，図３：ｓ１１）。

【００８０】こうして、認証応答を受け取ったクライア
ントＰＣ３０１では、ブラウザ４０２より認証結果を表
示する（図３：ｓ１２）。ここで、認証成功の場合には
ＩＣカード認証段階は終了し、取引段階へ移行する。

【００８１】［取引処理］ＩＣカード認証段階及び取引
段階を含めて、本実施形態によるメッセージ通信が行わ
れる様子を説明し、さらに、リプライアタックを受けた
ときにどうなるかについて説明する。

【００８２】図１１は本実施形態の通信システムによっ
てメッセージ通信を行う様子を示す図である。まず、Ｉ
Ｃカード認証段階では、上記した手順により、ＩＣカー
ド認証要求メッセージ６０６が認証され、ＩＣカード３
０３の認証が行われる。このときの通信メッセージには
取引内容は不要であり、ＩＣカード認証要求メッセージ
６０６は取引時のヘッダ部分に相当する部分のみから構
成される。また、この認証によりＯＴＰカウンタ値
（ｉ）が確認される。

【００８３】ＩＣカード認証後、クライアント側システ
ム３２０から商取引サービスシステム３３０へ取引メッ
セージが出力され、商取引が行われる。ここでは、取引
メッセージ＃１，＃２，＃３が出力されたとする。

【００８４】各取引メッセージには、そのヘッダ部分に
ＯＴＰとＯＴＰカウンタが含まれている。これらは、最
初の認証要求メッセージのＯＴＰカウンタ値を（ｉ）と
すると、出力順に（ｉ−１）、（ｉ−２）、（ｉ−３）
と推移する。したがって、ＯＴＰ自体もカウンタに対応
してＹ、Ｚ、Ａと変化する。

【００８５】正当なクライアントＰＣ３０１から取引メ
ッセージ＃１，＃２，＃３が送信されたときは、各メッ
セージのヘッダ部部分からＯＴＰ及びＯＴＰカウンタ値
が取り出され、図９，図１０に示す上記した処理により
正当なメッセージであることが認証される。こうして、
クライアント側システム３２０と商取引サービスシステ
ム３３０と間で商取引が進行していくことになる（図１
１（２））。

【００８６】ここで、悪意の第三者がリプライアタック
をかけた場合を考える（図１１（３））。例えば悪意の
第三者はインターネット上で取引メッセージ＃２を取得
することに成功したとする。

【００８７】第三者は、この取引メッセージ＃２を商取
引サービスシステム３３０にそのまま流し、リプライア
タックをかけても、この時点では既に認証サーバ３１０
の管理するＯＴＰカウンタ値が取引メッセージ＃２に含
まれる（ｉ−２）よりも小さな値となっている。したが
って、このリプライアタックにかかわるメッセージは図
１０のステップｘ６により、不正なメッセージと判定さ
れる。

【００８８】また、不正者が本実施形態の仕組みを知
り、何らかの方法で通信メッセージ＃２の内のＯＴＰカ
ウンタ値を変更しても無駄である。つまり、たとえＯＴ
Ｐカウンタ値自体が正しくても、ＯＴＰ自体が不正な情
報であるとそのメッセージは図１０のステップｘ８によ
り、不正メッセージと判定されるからである。したがっ
て、ＯＴＰシード及びＯＴＰ生成関数自体がわからなけ
れば悪意の第三者は不正メッセージによる妨害行為を行
うことができない。

【００８９】上述したように、本発明の実施の形態に係
る通信システムは、通信メッセージ内にＯＴＰ及びＯＴ
Ｐカウンタ値を含ませるとともに、カウンタ値を送受信
側でメッセージ授受の度に進めるようにしたので、毎回
使い切り型のパスワード（ＯＴＰ）による通信を実現す
ることができる。

【００９０】このように使い切りにできるのは、送信側
でカウンタが進行して毎回ＯＴＰを変更してメッセージ
自体を解析困難にできるのみならず、受信側において
も、一度正当なメッセージを受け取るとカウンタが進
み、同一メッセージは以降不正なものと扱うためであ
る。

【００９１】このようにＩＣカードが生成したＯＴＰに
よりメッセージが最新のものであり認証サーバが自己管
理しているＩＣカード（＝利用者）に間違いないことを
確認することが可能であり、悪意の第三者による妨害を
非常に困難にすることができる。

【００９２】したがって、通信の一方から他方に対する
情報メッセージがたとえ悪意の第三者に盗まれた場合で
も、一度利用された通信メッセージを再利用するリプラ
イアタック等の不正使用を防止することができる。 （発明の第２の実施の形態）本実施形態は、第１の実施
形態において、エクステンションヘッダに含めるＩＣカ
ード認証用データに改竄防止用データを付加して通信に
おける安全性をより高めるものである。

【００９３】図１２は本発明の第２の実施の形態に係る
通信システムを概略構成及び処理手順の一例を示す図で
ある。また、本実施形態の各図においては、第１の実施
形態における図と同一部分には同一符号を付して説明を
省略し、ここでは異なる部分についてのみ述べる。

【００９４】本実施形態では、改竄防止用のデータとし
てＭＤ（Ｍｅｓｓａｇｅ Ｄｉｇｅｓｔ）を使用する。
本実施形態の通信システムはこのＭＤに関する部分以外
は第１の実施形態と同様に構成されている。

【００９５】図１３はＭＤを生成する様子を示す図であ
る。ＩＣカード認証用データ５０１は、クライアントＰ
Ｃ３０１のクライアント側プロキシ４０３におけるＭＤ
生成手段７０１によりＭＤ７０２に変換される（図１
２：ｙ１）。

【００９６】このＭＤ７０２は、元となる情報（ＩＣカ
ード認証用データ５０１）をハッシュ関数などを利用し
た一定の手続き（ＭＤ生成手段７０１）により生成され
る値である。ＭＤは元情報に対して一意に生成されるた
め元情報が変更されればＭＤも変化する性質を持つ。

【００９７】本実施形態ではＭＤをＩＣカード認証用デ
ータ５０１に実装する。図１４はＭＤをＩＣカード認証
用データに付加した様子を示す図である。まず、クライ
アント側プロキシ４０３にて組み立てられたＩＣカード
認証用データ５０１は、さらにＭＤ生成手段７０１によ
りＭＤ７０２に変換される。得られたＭＤ７０２は暗号
化され、この暗号化ＭＤ７０３がＩＣカード認証用デー
タ５０１に付加される。

【００９８】この暗号化ＭＤ７０３及びＩＣカード認証
用データ５０１の全体が暗号化されて暗号化ＩＣカード
認証用データ６０５′とされる。以下、第１の実施形態
と同様に処理され、エクステンションヘッダ６０１′、
ＩＣカード認証要求メッセージ６０６′が生成される
（図１２：ｙ２）。

【００９９】こうして生成されたＭＤを含むＩＣカード
認証要求メッセージ６０６′は、クライアントＰＣ３０
１から取引サーバ３０８に送信される（ｙ３）。取引サ
ーバ３０８のサーバ側プロキシ４１１においては、ＭＤ
７０２及びＩＣカード認証用データ５０１が取り出され
（ｙ４）、サーバ側プロキシ４１１の有するＭＤ生成手
段によってカード認証用データ５０１からＭＤが生成さ
れ（ｙ５）、受信したＭＤ７０２と比較照合される（ｙ
６）。

【０１００】両ＭＤが一致しない場合には、通信の過程
において情報（メッセージ内容）の改竄が行われたこと
を示す。したがって、このＭＤチェックにより情報改竄
をチェックできる。

【０１０１】上述したように、本発明の実施の形態に係
る通信システムは、第１の実施形態と同様な構成を設け
た他、メッセージにＭＤを付加してその受信側でその照
合を行うようにしたので、第１の実施形態と同様な効果
が得られる他、通信課程における情報改竄をチェックす
ることができ、ひいてはより強力に不正使用を防止する
ことができる。

【０１０２】なお、本発明は、上記各実施の形態に限定
されるものでなく、その要旨を逸脱しない範囲で種々に
変形することが可能である。例えば実施形態では、本通
信システムをインターネットに適用する場合で説明した
が本発明はこの場合に限られるものではなく、種々の通
信形態に適用できる。すなわち本発明は、利用するネッ
トワークのトポロジやシステムを構成する計算機やＯＳ
の種類に関係なく実現できるものである。

【０１０３】また、各実施形態の商取引システムでは、
ＩＣカードを用いたシステムについて説明したが、本発
明はこの場合に限定されるものではない。例えばカード
に入力すべき情報をハードディスクなどの計算機のハー
ドウエア資源に格納するようにしてもよい。また、実施
形態の商取引システムを、インターネットで商取引を行
うシステムであるＳＥＴ（セキュア エレクトロニック
トランザクション）等に適用させてもよい。

【０１０４】さらに、実施形態では商取引システムに適
用させる場合を説明したが、本発明の適用対象は商取引
システムに限られるものではなく、本人認証を行いつつ
通信を行う必要のある各種の通信システムに適用するこ
とができる。

【０１０５】また、実施形態に記載した手法は、計算機
（コンピュータ）に実行させることができるプログラム
（ソフトウエア手段）として、例えば磁気ディスク（フ
ロッピーディスク、ハードディスク等）、光ディスク
（ＣＤ−ＲＯＭ、ＤＶＤ等）、半導体メモリ等の記憶媒
体に格納し、また通信媒体により伝送して頒布すること
もできる。なお、媒体側に格納されるプログラムには、
計算機に実行させるソフトウエア手段（実行プログラム
のみならずテーブルやデータ構造も含む）を計算機内に
構成させる設定プログラムをも含むものである。本装置
を実現する計算機は、記憶媒体に記録されたプログラム
を読み込み、また場合により設定プログラムによりソフ
トウエア手段を構築し、このソフトウエア手段によって
動作が制御されることにより上述した処理を実行する。

【０１０６】

【発明の効果】以上詳記したように本発明によれば、同
じメッセージを正当なものとして扱うことができるのを
１度のみとする仕組みを設けたので、通信の一方から他
方に対する情報メッセージがたとえ悪意の第三者に盗ま
れた場合でも、一度利用された通信メッセージを再利用
するリプライアタック等の不正使用を防止することがで
きる通信システム及びＩＣカード並びに記録媒体を提供
することができる。

【図面の簡単な説明】

【図１】本発明の第１の実施の形態に係る通信システム
を適用した商取引システムの全体構成例を示す図。

【図２】同実施形態の通信システムにおける各部の機能
構成を示すブロック図。

【図３】クライアント側システムを操作する利用者が本
人に間違いないことを確認する本人認証処理の処理概要
を示す図。

【図４】ＰＩＮによるカード使用者の認証処理を示す
図。

【図５】ＩＣカード認証用データの生成し、さらにＩＣ
カード認証要求メッセージを作成する様子を示す図。

【図６】ＩＣカード認証用データを示す図。

【図７】ＩＣカード認証要求メッセージフォーマットを
示す図。

【図８】ＩＣカード認証要求メッセージの送信を示す
図。

【図９】取引サーバ及び認証サーバによるＩＣカード認
証処理を示す図。

【図１０】ＩＣカード認証処理の流れ図。

【図１１】同実施形態の通信システムによってメッセー
ジ通信を行う様子を示す図。

【図１２】本発明の第２の実施の形態に係る通信システ
ムを概略構成及び処理手順の一例を示す図。

【図１３】ＭＤを生成する様子を示す図。

【図１４】ＭＤをＩＣカード認証用データに付加した様
子を示す図。

【図１５】従来の通信システムによる商取引時のメッセ
ージ授受を示す図。

【図１６】悪意の第三者が商取引システム利用者の通信
メッセージを悪用する様子を示す図。

【符号の説明】

３０１…クライアントＰＣ ３０２…ＩＣカード読取／書込装置 ３０３…ＩＣカード ３０５…ルータ ３０６…公開用ＷＷＷサーバ ３０７…ファイアウォール ３０８…取引サーバ ３１０…認証サーバ ３１２…ＩＣカード発行装置 ３０９…取引データベース ３１１…認証データベース ３２０…クライアント側システム ３３０…商取引サービスシステム ４０２…ブラウザ ４０３…クライアント側プロキシ ４０４…ＩＣカードＡＰＩ ４１１…サーバ側プロキシ ４１２…ＨＴＴＰサーバ ４１３…ＣＧＩプログラム ４１４…暗号化／復号化処理部 ４１６…認証プロセス ４１９…発行情報生成プロセス ４２０…ＨＴＴＰプロキシ ５０１…ＩＣカード認証用データ ５０２…ユーザＩＤ ５０３…ＩＣカード識別情報 ５０４…ＯＴＰ ５０５…ＯＴＰカウンタ ６０１…エクステンションヘッダ ６０２…識別文字 ６０３…バージョン番号 ６０４…要求内容 ６０５…ＩＣカード認証用データ ６０６…ＩＣカード認証要求メッセージ ６０７…ブラウザ作成部分 ６０８…リクエストライン ６０９…ジェネラルヘッダ ６１０…リクエストヘッダ ６１１…エンティティヘッダ ６１２…ＣＲＬＦ ７０１…ＭＤ生成手段 ７０２…ＭＤ ７０３…暗号化ＭＤ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 衞藤 崇 東京都府中市東芝町１番地 株式会社東芝 府中工場内 (72)発明者 若井 千鶴子 東京都府中市東芝町１番地 株式会社東芝 府中工場内 Ｆターム(参考） 5J104 AA08 AA12 EA09 EA17 JA01 KA01 KA07 LA00 LA01 LA05 NA01 NA11 NA12 NA21 NA27 NA35 PA07 PA09 PA10

Claims (9)

【特許請求の範囲】
1. 【請求項１】 ネットワークを通してメッセージを送信
   するとともに、そのメッセージに付加された検証用情報
   を評価して当該メッセージの正当性を確認する通信シス
   テムであって、 前記メッセージ発信毎に異なった検証用情報を生成し、
   メッセージに付加する送信側システムと、 毎回異なる前記検証用情報の正当性を確認する受信側シ
   ステムとを備えたことを特徴とする通信システム。
2. 【請求項２】 前記送信側システムは、 元となる情報を変換することで前記検証用情報を生成す
   る検証用情報生成手段と、 前記元となる情報に、メッセージ発信毎にカウントされ
   るカウンタ値を少なくとも含める送信側カウンタ手段と
   を備えたことを特徴とする請求項１記載の通信システ
   ム。
3. 【請求項３】 前記受信側システムは、 前記送信側システムでカウントされるカウント値と同期
   させたカウント値を管理する受信側カウンタ手段と、 この受信側カウンタ手段に管理されたカウント値を含め
   て得られる，前記元となる情報と同一の情報を変換する
   ことにより、検証用情報を生成する検証用情報再現手段
   と、 前記検証用情報再現手段で再現された検証用情報とメッ
   セージ内の検証用情報とを比較照合することで当該メッ
   セージの正当性を確認する正当性評価手段とを備えたこ
   とを特徴とする請求項２記載の通信システム。
4. 【請求項４】 前記送信側システムは、前記メッセージ
   の検証用情報に、メッセージ発信毎にカウントされるカ
   ウンタ値を少なくとも含める送信側カウンタ手段を備
   え、 前記受信側システムは、 前記送信側システムでカウントされるカウント値と同期
   させたカウント値を管理する受信側カウンタ手段と、 前記メッセージの検証用情報からカウント値を取り出す
   とともに、前記受信側カウンタ手段に管理されるカウン
   ト値に基づき、受信メッセージ内のカウント値が既にカ
   ウント済みの値であると判断したときには、当該メッセ
   ージを不正と判定する正当性評価手段とを備えたことを
   特徴とする請求項１記載の通信システム。
5. 【請求項５】 ネットワークを通してメッセージを送信
   するとともに、そのメッセージに付加された検証用情報
   を評価して当該メッセージの正当性を確認する通信シス
   テムの送信側システムを制御するプログラムであって、
   元となる情報を変換することで前記検証用情報を生成す
   る検証用情報生成手段と、 前記元となる情報に、メッセージ発信毎にカウントされ
   るカウンタ値を少なくとも含める送信側カウンタ手段と
   してコンピュータを機能させるためのプログラムを記録
   したコンピュータ読み取り可能な記録媒体。
6. 【請求項６】 ネットワークを通してメッセージを送信
   するとともに、そのメッセージに付加された検証用情報
   を評価して当該メッセージの正当性を確認する通信シス
   テムの受信側システムを制御するプログラムであって、 送信側システムでカウントされるカウント値と同期させ
   たカウント値を管理する受信側カウンタ手段と、 この受信側カウンタ手段に管理されたカウント値を含め
   ることにより前記送信側システムにおいて検証用情報を
   生成した際の元となる情報と同一の情報を取得し、かつ
   同情報を変換することにより検証用情報を生成する検証
   用情報再現手段と、 前記検証用情報再現手段で再現された検証用情報とメッ
   セージ内の検証用情報とを比較照合することでメッセー
   ジの正当性を確認する正当性評価手段としてコンピュー
   タを機能させるためのプログラムを記録したコンピュー
   タ読み取り可能な記録媒体。
7. 【請求項７】 ネットワークを通してメッセージを送信
   するとともに、そのメッセージに付加された検証用情報
   を評価して当該メッセージの正当性を確認する通信シス
   テムの受信側システムを制御するプログラムであって、 送信側システムでカウントされるカウント値と同期させ
   たカウント値を管理する受信側カウンタ手段と、 前記メッセージの検証用情報からカウント値を取り出す
   とともに、前記受信側カウンタ手段に管理されるカウン
   ト値に基づき、受信メッセージ内のカウント値が既にカ
   ウント済みの値であると判断したときには、当該メッセ
   ージを不正と判定する正当性評価手段としてコンピュー
   タを機能させるためのプログラムを記録したコンピュー
   タ読み取り可能な記録媒体。
8. 【請求項８】 前記請求項２〜４のうち何れか１項記載
   の通信システムにおける送信側システムの送信側カウン
   タ手段として機能することを特徴とするＩＣカード。
9. 【請求項９】 前記請求項２又は３記載の通信システム
   における送信側システムの検証用情報生成手段及び送信
   側カウンタ手段として機能することを特徴とするＩＣカ
   ード。