JP2005222321A - データ通信装置、サーバ及びデータ検証システム - Google Patents

Abstract

【課題】情報を継承するためのデータについての第三者による不正行為を防止することができ、かつ、第三者の不正行為と正当利用者の再リクエストとを識別することができる、データ通信装置、サーバ及びデータ検証システムを提供する。
【解決手段】本発明は、データ通信装置が、サーバに対する今回の要求と他の要求との識別可能な検証データを、要求データ及びサーバが認識している当該データ通信装置に関するセッション情報を識別するためのセッション識別データと共にサーバに送信し、サーバが、検証データを検証し、その検証結果が正当である場合に、応答情報を送信することを特徴とする。
【選択図】 図１

Description

本発明は、データ通信装置、サーバ及びデータ検証システムに関し、例えば、セッションを識別するためのデータ（特にＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）サービスで用いられるＣｏｏｋｉｅ等）の正当性を判定するためのデータ検証システム、及び、そのデータ検証システムを構成するデータ通信装置及びサーバに適用し得る。

ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）プロトコルを代表とするリクエストとレスポンスとで１つのセッションが終了するような通信手順で、ＷＷＷサービスを提供するＷＷＷサーバが、セッションの継続（今回のリクエストと前回のリクエストが同じ利用者端末（ＷＷＷブラウザ）からなされていることが判断でき、今回のリクエストが前回のセッションの継続とみなすことができる）を可能とするためには、セッションを識別するためのデータをＣｏｏｋｉｅに持たせ、これを用いることが一般的となっている（下記特許文献２、３及び４参照）。

Ｃｏｏｋｉｅは、利用者のＷＷＷブラウザがＷＷＷサーバにアクセスした（リクエストを出した）際に、ＷＷＷサーバからＷＷＷブラウザヘのレスポンスと共に送信されてＷＷＷブラウザに記録され、その後、再度、利用者のＷＷＷブラウザがＷＷＷサーバにアクセスした（リクエストを出した）ときに、そのリクエストと共にＷＷＷサーバに送信されるものである。

そして、ＷＷＷサーバは、ＷＷＷブラウザから受信したＣｏｏｋｉｅを参照することにより、どのセッションの継続であるかを判断することができる。

下記特許文献１には、不正者による、Ｃｏｏｋｉｅの書き換えや不正な入手あるいはコピー、又はＣｏｏｋｉｅの偽造による利用を防止する技術が記載されている。

具体的には、下記特許文献１には、ＷＷＷサーバがＣｏｏｋｉｅに一連番号を付与し、過去に利用されたＣｏｏｋｉｅを記憶しておくことにより、受信したＣｏｏｋｉｅの一連番号を確認することでＣｏｏｋｉｅの正当性を判断し、不正入手やコピー又は偽造によるＣｏｏｋｉｅを重複して利用するような不正利用を検出したり、Ｃｏｏｋｉｅにディジタル署名を付加することにより、Ｃｏｏｋｉｅの書き換えを検出したりする技術が記載されている。
特開平１１−９８１３４号公報 米国特許第５７７４６７０号明細書 米国特許第６１３４５９２号明細書 米国特許第５８２６２４２号明細書

しかしながら、例えば、ＷＷＷサーバからのレスポンスが非常に遅かったり、ＷＷＷサーバからの通信が何らかの原因で遮断されていたりする場合には、利用者が待ちきれずに再リクエストを出す（リロードする）状態が発生する場合がある。

このような場合、ＷＷＷサーバが重複した一連番号をもつ複数のＣｏｏｋｉｅを受信することとなるので、上記特許文献１に記載の技術では、正当な利用者からの（２度目の）リクエストであるか、又は不正者が盗聴などの不正手段によりＣｏｏｋｉｅを取得して送信されたリクエストであるかを判別することができないおそれがある。

そのため、Ｃｏｏｋｉｅ等のセッション識別データの正当性を検証し第三者による不正アクセスを防止することができ、かつ、正当利用者による再リクエストと第三者の不正アクセスとを識別することができるデータ検証システム、データ通信装置及びサーバが求められている。

かかる課題を解決するために、第1の本発明のデータ通信装置は、サーバから提供を受けた情報を継承するためのデータを送信するデータ通信装置において、（１）サーバに対する要求データの内容を生成する要求データ生成手段と、（２）サーバから取得した、サーバが認識している当該データ通信装置に関するセッション情報を識別するためのセッション識別情報を保持するセッション識別情報保持手段と、（３）今回のサーバに対する要求と他の要求との識別性を有する検証データを生成する検証データ生成手段と、（４）要求データ、セッション識別情報及び検証データを多重化して上記サーバに与える通信手段とを備えることを特徴とする。

また、第２の本発明のサーバは、受信した受信データに含まれる、提供情報を継承するためのデータに応じて情報を提供するサーバにおいて、（１）受信データの要求データの内容を解析する要求データ解析手段と、（２）受信データに含まれているセッション識別情報に基づいて要求してきたデータ通信装置のセッション情報を識別するセッション識別手段と、（３）受信データに含まれている、今回の要求と他の要求との識別性を有する検証データを検証する検証データ検証手段と、（４）検証データ検証手段の検証結果が正当である場合に、セッション識別手段の識別結果に基づく要求データに応じた情報を送信する通信手段とを備えることを特徴とする。

さらに、第３の本発明のデータ検証システムは、サーバから情報の提供を受けたデータ通信装置が送信する情報を継承するデータの正当性を検証するデータ検証システムにおいて、（１）データ通信装置が、第１の本発明のデータ通信装置であり、（２）サーバが、データ通信装置から与えられる検証データの態様に応じた第２の本発明のサーバであることを特徴とする。

本発明のデータ通信装置、サーバ及びデータ検証システムは、サーバに送信される、情報を継承するためのデータが、第三者の不正アクセスによるものであるかを否かの判定をすることができ、第三者の不正アクセスに応じた情報提供を防止することができる。

また、本発明のデータ通信装置、サーバ及びデータ検証システムは、データ通信装置からの要求が、何らかの事情により再リクエストした場合であっても、その再リクエストと第三者による不正アクセスとの別を判定することができるので、正当利用者の要求に対して正確なサービスを提供することができる。

本発明に係るデータ通信装置、サーバ及びデータ検証システムを実施するためにの最良の形態について説明する。

（Ａ）第１の実施形態
以下、本発明のデータ通信装置、サーバ及びデータ検証システムの第１の実施形態について図面を参照して説明する。

本実施形態は、利用者端末（ＷＷＷブラウザ）及びＷＷＷサーバ間のデータ通信システムであり、利用者端末は、リクエストと共に、時間情報を検証データとしてＷＷＷサーバ側に送り、ＷＷＷサーバ側が、その検証データである時間情報を検証することにより、当該リクエストが不正利用されたものであるか否かを判断する場合について説明する。

また、この検証データは、利用者端末とＷＷＷサーバ側との間でのみ利用できる暗号化方法で時間情報を暗号化したデータである。

（Ａ−１）第１の実施形態の構成
図１は、第１の実施形態に係る利用者端末がもつ主要な機能を示すブロック図である。また、以下で説明する利用者端末１の主要処理は、制御手段（例えばＣＰＵ等）により実行可能なプログラムで構成されており、このプログラムは、制御手段により読み取り可能な記録媒体に格納され得る。

利用者端末１は、例えば、ＨＴＴＰ等の所定の通信手順によりＷＷＷを閲覧することができる閲覧機能（例えばＷＷＷブラウザ）を有する通信端末である。

図１に示すように、本実施形態に係る利用者端末１は、リクエストデータ生成部１０１、セッションＩＤ保持部１０２、検証データ生成部１０３、多重化部１０４、レスポンスデータ処理部１０５、分離部１０６などを少なくとも備える。

リクエストデータ生成部１０１は、ＷＷＷサーバ２に対し、ＷＷＷサービスをリクエストするデータを生成するものであり、例えば、ＷＷＷ文書の取得をリクエストするＨＴＴＰリクエストデータを生成する。また、リクエストデータ生成部１０１は、生成したリクエストデータを多重化部１０４に与えるものである。

セッションＩＤ保持部１０２は、ＷＷＷサーバ２よりＷＷＷブラウザに対し送信されるセッションを識別するためのデータ（以後、セッションを識別するために用いるデータをセッションＩＤと呼ぶことにする）を保持するものであり、入力端子１１１から入力したＷＷＷサーバ２からのレスポンスデータのうち、分離部１０６により分離されたセッションＩＤを保持するものである。セッションＩＤ保持部１０２は、セッション毎のセッションＩＤを保持し、例えば、ＷＷＷサービスを複数利用するためには、ＷＷＷサービス毎のセッションＩＤを保持する。

また、セッションＩＤ保持部１０２は、リクエストデータ生成部１０１からリクエストデータが出力されると（リクエストデータ生成部１０１からの出力タイミング（図１では点線矢印で示す）を受け取ると）、保持内容を多重化部１０４に与えるものである。ただし、セッションＩＤ保持部１０２は、該当するセッションＩＤを保持していない場合には何も出力しない。

検証データ生成部１０３は、ＷＷＷサーバ２側で検証させるための検証データを生成するものである。ここで、検証データとは、ＷＷＷサーバ２側でセッションＩＤの正当性を検証させるためのデータであり、ＷＷＷサーバ２による検証が正当である場合に、検証データと同時に送信されたリクエストデータが正当であると判断させる。

検証データ生成部１０３は、リクエストデータ生成部１０１からリクエストデータが出力されると（リクエストデータ生成部１０１からの出力タイミング（図１では点線矢印で示す）を受け取ると）、検証データを生成し、生成したデータを多重化部１０４に与えるものである。ただし、検証データ生成部１０３は、該当するセッションＩＤがセッションＩＤ保持部１０２に保持されていない場合には何も出力しない。

また、検証データ生成部１０３は、図１に示すように、時間情報生成部１０３１と暗号化部１０３２を有する。

時間情報生成部１０３１は、時間に関する情報（以後、時間情報と呼ぶことにする）を生成し、その時間情報を暗号化部１０３２に与えるものである。

この時間情報は、利用者端末１からリクエストデータが出力された時間を示す情報であり、ＷＷＷサーバ２において、リクエストデータが利用者端末１からいつ出力されたかを判断できるような情報であれば、どんな形でもよい。例えば、利用者端末１が内蔵する時計機能の日時情報などを用いてもよいし、又は、ネットワークを通じて接続可能な外部標準時刻装置から得た時間情報を用いてもよい。

暗号化部１０３２は、時間情報生成部１０３１から時間情報を受け取り、その受け取った時間情報（データ）に対して所定の暗号化方法により暗号化を行ない、この暗号化により得た暗号化データを多重化部１０４に与えるものである。この暗号化部１０３２からの出力が、検証データ生成部１０３の出力となる。

暗号化部１０３２により暗号化されたデータは、受け取るＷＷＷサーバ２側において、セッションＩＤの正当性を検証（例えば、重複して使用されていないか等の検証）するための検証データとして用いられる。なお、以下では、セッションＩＤと検証データとを組み合わせたものをセッション識別データという。

また、暗号化部１０３２における暗号化方法は、ＷＷＷサーバ２とＷＷＷブラウザ間であらかじめ決められた方法を採用することができ、例えば、利用者端末１のみ、又はＷＷＷサーバ２と利用者端末１との間でのみ利用できる暗号化方法を採用できる。

多重化部１０４は、リクエストデータ生成部１０１により生成されたリクエストデータと、セッションＩＤ保持部１０２により保持されているセッションＩＤと、検証データ生成部１０３により生成された検証データとを受け取り、これら３つのデータの多重化を行ない、多重化したデータを出力端子１１０から出力するものである。

多重化の方法は、例えば、ＨＴＴＰプロトコルのＣｏｏｋｉｅとして、セッションＩＤと検証データをリクエストデータのヘッダに付加する方法を用いることができる。ＷＷＷサーバ２側で、リクエストデータ、セッションＩＤおよび検証データの分離が可能であれば、どのような方法を採ってもよい。

分離部１０６は、入力端子１１１を介してＷＷＷサーバ２からのレスポンスを受け取り、その入力されたレスポンスデータからセッションＩＤを分離し、セッションＩＤを除いたレスポンスデータをレスポンスデータ処理部１０５に与え、またレスポンスデータから分離したセッションＩＤをセッションＩＤ保持部１０２に与えるものである。なお、分離部１０６は、受信したレスポンスデータにセッションＩＤが多重化されてない場合、セッションＩＤを分離することができないので、セッションＩＤをセッションＩＤ保持部１０２に与えず、レスポンスデータ処理部１０５にレスポンスデータを与える。

レスポンスデータ処理部１０５は、分離部１０６によりセッションＩＤが除かれたレスポンスデータを受け取り、その受け取ったレスポンスデータの処理を行うものである。このレスポンスデータの処理は、例えば、レスポンスデータの内容をＷＷＷブラウザに表示を行うことである。

次に、本実施形態に係るＷＷＷサーバ２について説明する。図２は、ＷＷＷサーバ２の主要な機能を示すブロック図である。以下で説明するＷＷＷサーバ２の主要な処理は、制御手段により実行され得るプログラムであり、このプログラムは、制御手段により読み取り可能な記憶媒体に格納され得る。

ＷＷＷサーバ２は、利用者端末１（ＷＷＷブラウザ）から受信したリクエストデータに応じたＷＷＷサービスを提供するものである。また、ＷＷＷサーバ２は、リクエストデータに含まれている検証データを検証し、検証データが正当である場合に、リクエストデータ及びセッションＩＤに応じたレスポンスデータを利用者端末１（ＷＷＷブラウザ）に返信するものである。

図２に示すように、ＷＷＷサーバ２は、分離部２０１、リクエストデータ解析部２０２、セッション識別部２０３、検証部２０４、レスポンスデータ生成部２０５、セッションＩＤ生成部２０６、多重化部２０７を備える。

分離部２０１は、入力端子２１０を介して入力したリクエストデータから、セッションＩＤ及び検証データを分離し、分離したセッションＩＤをセッション識別部２０３に与え、また分離した検証データを検証部２０４に与え、さらにセッションＩＤ及び検証データを分離した残りのリクエストデータをリクエストデータ解析部２０２に与えるものである。なお、分離部２０１は、入力したリクエストデータに、セッションＩＤ及び検証データが多重化されていない場合には、セッションＩＤや検証データを分離することができないので、これらセッションＩＤ及び検証データを、セッション識別部２０３及び検証部２０４に与えず、リクエストデータ解析部２０２にリクエストデータを与える。

リクエストデータ解析部２０２は、分離部２０１からリクエストデータを受け取り、その受け取ったリクエストデータを解析し、レスポンスデータ生成部２０５へその解析結果を出力するものである。この解析結果は、レスポンスデータ生成部２０５において、レスポンスデータの生成に必要なデータであり、例えば、リクエストデータに書かれている複数ある変数を分離して記述しているデータである場合もあるし、リクエストデータに書かれているファイル名に相当するファイル本体である場合もあるし、その両方の場合もある。

セッション識別部２０３は、分離部２０１からセッションＩＤを受け取り、このリクエストがどのセッションを表しているかを判定し、その判定結果をレスポンスデータ生成部２０５に与えるものである。また、セッション識別部２０３は、判定結果（どのセッションであるかという情報）を、暗号復号部２０４１及び時間情報検証部２０４２にも与えて、それぞれに判定結果を知らせるものである。

検証部２０４は、分離部２０１から検証データを受け取り、受け取った検証データが正当なものであるかを検証し、レスポンスデータ生成部２０５へその検証結果を与える。

また、検証部２０４は、図２に示すように、暗号復号部２０４１、時間情報検証部２０４２および時間情報保持部２０４３を有する。

暗号復号部２０４１は、分離部２０１により分離された検証データを受け取り、その受け取った検証データの暗号復号を行い、その結果（時間情報）を時間情報検証部２０４２に与えるものである。また、暗号復号部２０４１は、セッション識別部２０３から判定結果（どのセッションであるかという情報）を受け取り（信号線は点線矢印で示している）、その判定結果に基づいてどの暗号復号鍵であるか、またどの暗号復号方法を用いて暗号復号すればよいのかが判り、これにより暗号復号を行なうことができる。

時間情報検証部２０４２は、暗号復号部２０４１により暗号復号された時間情報を受け取り、その時間情報が、時間情報保持部２０４３が保持する情報を参照して正当なものであるかを検証し、その検証結果をレスポンスデータ生成部２０５に出力するものである。また、時間情報検証部２０４２は、セッション識別部２０３から判定結果（どのセッションであるかという情報）を受け取り、その判定結果を用いて、時間情報保持部２０４３が保持する情報のうち、どのセッションの保持データを参照すればよいのかがわかる。この時間情報検証部２０４２からの出力が検証部２０４の出力となる。

時間情報保持部２０４３は、同じセッションのもので、過去に受け取ったリクエストデータと多重化されていた時間情報を保持しておく部分である。複数のセッションを取り扱っている場合には、それらのセッション毎に時間情報を保持している。

時間情報検証部２０４２では、暗号復号部２０４１からの時間情報（つまり、リクエストデータの送信時間）が、時間情報保持部２０４３に保持されている時間情報と一致した場合（すなわち、検証データが重複して用いられている）、時間情報保持部２０４３に保持されている最新の時間情報が表す時間よりも過去の時間を表すデータ場合、または、検証データが時間情報を表すデータでなかった場合、不正にセッション識別データを取得、コピー又は偽造をして用いられているものと判断し、検証結果として、サービスを提供する資格がない旨を出力する。

時間情報保持部２０４３は、時間情報検証部２０４２で時間情報を検証した結果が、正当なものであると判断されるならば、その正当な時間情報を追加して保持しておく。時間情報保持部２０４３の保持できる１個のセッションあたりの時間情報の個数が１個だけであったならば、すでに保持されているデータの上へ上書きする形になる。

レスポンスデータ生成部２０５は、リクエストデータ解析部２０２、セッション識別部２０３及び検証部２０４からの出力を受け取り、それらの受け取ったデータに基づき、ＷＷＷブラウザに送信するレスポンスデータを生成するものである。レスポンスデータ生成部２０５で生成されたレスポンスデータは多重化部２０７に与えられる。

セッションＩＤ生成部２０６は、必要であればセッションＩＤを生成し、多重化部２０７に与えるものである。セッションＩＤ生成部２０６からセッションＩＤを出力するタイミングは、レスポンスデータ生成部２０５からレスポンスデータが出力されるタイミングであり、図中では、点線矢印でそのタイミングを知らせる信号線を描いている。

多重化部２０７は、レスポンスデータ生成部２０５からレスポンスデータを、セッションＩＤ生成部２０６からセッションＩＤを受け取り（セッションＩＤの出力がなければなにも受け取らない）、それら２つのデータを多重化する。多重化の方法は、例えば、ＨＴＴＰプロトコルのＣｏｏｋｉｅとして、セッションＩＤをレスポンスデータのヘッダに付加する方法があるが、受け取るＷＷＷブラウザで、レスポンスデータおよびセッションＩＤの分離が可能であれば、どのような方法を採ってもよい。多重化部２０７で多重化されたデータは、出力端子２１１より出力される。

（Ａ−２）第１の実施形態の動作
図３は、第１の実施形態に係る利用者端末１とＷＷＷサーバ２との間で通信されるデータ検証システムの動作を示す説明図である。

以下では、利用者端末１がＷＷＷサーバ２に、ＷＷＷサービスを利用するためのリクエストを行い、ＷＷＷサーバ２は利用者認証を行うことによりサービスを受ける資格のある利用者からのリクエストかどうかを判定し、判定結果が正当であれば、後のセッションを継続させるという場合を考える。

まず、利用者端末１（ＷＷＷブラウザ）よりリクエストを行い、ＷＷＷサーバ２はそのリクエストが利用資格のある利用者のものかどうかの利用者認証を行なう（３０）。

この利用者認証方法は、特に限定されず広く適用することができ、例えば、リクエストに利用者のディジタル署名の入った証明書を付加して、ＷＷＷサーバ２側でその証明書を検証することにより利用資格があるかどうかの判定を行うようにしてもよい。

また例えば、図４で表しているように、利用者端末１からの要求（４１）に応じて、ＷＷＷサーバ２がＩＤとパスワードを入力させるぺ一ジを利用者端末１に送り返し（４２）、利用者の操作により入力されたＩＤとパスワードとを入力したページをＷＷＷサーバ２に返送（４３）し、そのＩＤ及びパスワードにより利用者認証を行うようにしてもよい。また例えば、利用者端末１とＷＷＷサーバ２との間で共通鍵を共有している場合、図４では、４２で乱数を伝送し、４３では共通鍵暗号の秘密鍵で暗号化して伝送するような、共通鍵暗号ベースの利用者認証を行うようにしてもよい。

ＷＷＷサーバ２において利用者認証が正当であると判定されると、ＷＷＷサーバ２はリクエストに応じたレスポンスデータをレスポンスとして利用者端末１に送信する。そして、利用者端末１は、そのレスポンスデータに含まれているセッションＩＤを保持する（３１）。

このとき、ＷＷＷサーバ２は、セッションＩＤであるデータＣも同時に送信（図２において、レスポンスデータ生成部２０５より出力されるレスポンスデータとセッションＩＤ生成部２０６より出力されるセッションＩＤとを多重化部２０７で多重化して送信）し、ＷＷＷブラウザ１にＣを保存するようにする（図１において、分離部１０６で分離されたセッションＩＤをセッションＩＤ保持部１０２で保持する）。

このようにセッションを識別するために用いられるデータは、一般的にはＣｏｏｋｉｅであるが、ＷＷＷサーバ２から送信されＷＷＷブラウザ１にＣを保存できるものであれば、Ｃｏｏｋｉｅに限定しない。

利用者端末１が、次にＷＷＷサーバ２にリクエストを行なう場合、利用者端末１は、リクエストデータ生成部１０１が生成したリクエストデータ、セッションＩＤ保持部１０２が保持するセッションＩＤ（Ｃ）、及び、検証データ生成部１０３が生成した検証データ（Ｅ）を多重化したリクエストデータを、ＷＷＷサーバ２に送信する（３２）。

ここで、検証データ生成部１０３では、リクエストを送信する時間に関する情報Ｔ（図１の時間情報生成部１０３１から出力される時間情報）を暗号化鍵Ｋｅで暗号化（図１の暗号化部１０３２での暗号化）を行なうことで、検証データ（Ｅ）を生成する。

暗号化鍵Ｋｅは、３０において用いられる利用者認証に依存するものでもよく、例えば、利用者認証にディジタル署名の入った証明書を用いる場合では、ディジタル署名を行う秘密鍵を暗号化鍵Ｋｅとして、１１（図１の暗号化部１０３２）の暗号化方法を公開鍵暗号（例えば、ＲＳＡ暗号）とすることもできる（後述する暗号復号鍵Ｋｄは、この場合、ディジタル署名の秘密鍵と対になる公開鍵となる）。また、ＩＤとパスワード入力による利用者認証の場合では、パスワードを暗号化鍵Ｋｅとして、１１（図１の暗号化部１０３２）における暗号化方法を共通鍵暗号（例えば、ＤＥＳ暗号）とすることもできる。また、共通鍵暗号ベースの認証の場合には、用いる秘密鍵を暗号化鍵Ｋｅとして１１（図１の暗号化部１０３２）に共通鍵暗号を用いることもできる。

また、暗号化鍵Ｋｅは利用者認証時に用いる値以外のものであってもよいが、（１）利用者のみ、もしくは、利用者とサーバとのみ、で知り得る値であること。（２）サーバ側において、その値で暗号化されたメッセージの暗号復号のための鍵が利用できるようになっていること。という条件を満たしていなければならない。

利用者端末１からリクエストがＷＷＷサーバ２に与えられると、ＷＷＷサーバ２の分離部２０１により、リクエストに含まれているセッションＩＤ（Ｃ）及び検証データ（Ｅ）とが分離され、セッションＩＤ（Ｃ）はセッション識別部２０３に与えられ、検証データ（Ｅ）は検証部２０４に与えられ、Ｃ及びＥを除くリクエストデータはリクエストデータ解析部２０２に与えられる（３２）。また、セッションＩＤ（Ｃ）及び検証データ（Ｅ）の送信（３２）は、Ｃｏｏｋｉｅとして送信することもできるが、ＷＷＷブラウザ１からＷＷＷサーバ２ヘ送信できるものであれば、Ｃｏｏｋｉｅに限定されない。

リクエストデータ解析部２０２では、リクエストデータの解析が行なわれ、その解析結果がレスポンスデータ生成部２０５に与えられる。

また、セッション識別部２０３では、セッションＩＤ（Ｃ）に基づいて、以前リクエストをして認証された利用者であることを識別し、どのセッションであるかを示す識別結果が、検証部２０４及びレスポンスデータ生成部２０５に与えられる。

また、検証部２０４では、検証データが暗号復号部２０４１に与えられ、暗号復号部２０４１により、セッション識別部２０３からの識別結果に基づく暗号復号鍵Ｋｄを用いて検証データ（Ｅ）が暗号復号され、時間情報Ｔが得られ、その時間情報Ｔが時間情報検証部２０４２に与えられる（２１）。

暗号復号鍵Ｋｄは、前述した暗号化鍵Ｋｅとは対になるもの、あるいは、同じものであり、暗号化鍵Ｋｅと同様３０において用いられる利用者認証に依存するものでもよい。

例えば、利用者認証にディジタル署名の入った証明書を用いる場合では、ディジタル署名を行う秘密鍵を暗号化鍵Ｋｅとして、１１（図１の暗号化部１０３２）および２１（図２の暗号復号部２０４１）で用いる暗号化方法を公開鍵暗号とし、さらに暗号復号鍵Ｋｄは、ディジタル署名の秘密鍵と対になる公開鍵とする。また、ＩＤとパスワード入力による利用者認証の場合では、パスワードを暗号化鍵Ｋｅおよび暗号復号鍵Ｋｄとして、１１（図１の暗号化部１０３２）および２１（図２の暗号復号部２０４１）で用いる暗号化方法を共通鍵暗号とすることもできる。さらに、共通鍵暗号べースの利用者認証の場合には、用いる秘密鍵を暗号化鍵Ｋｅおよび暗号復号鍵Ｋｄとして１１（図１の暗号化部１０３２）および２１（図２の暗号復号部２０４１）に共通鍵暗号を用いることもできる。

暗号復号部２０４１から時間情報Ｔが時間情報検証部２０４２に与えられると、時間情報検証部２０４２により、セッション識別部２０３からの識別結果を用いて、時間情報Ｔが、前回（３１）のリクエストの際に認証された利用者からのリクエストであるかどうかの判定がなされる（２２）。

つまり、３２で受け取ったリクエストが、時間情報Ｔから極めて限定された時間内であるならば正当な時間情報Ｔであることが判る。

また、時間情報検証部２０４２において時間情報Ｔの検証後、受け取った時間情報Ｔは、時間情報保持部２０４３に利用者毎に保持される。これにより、過去に受け取った時間情報を保持することができ、この時間情報Ｔが重複して利用されたものか又は重複利用されたものでないかを判別することができる。

セッションＩＤ（Ｃ）と時間情報（Ｔ）の正当性が判別される（図２の時間情報検証部２０４２において正当なリクエストであることが検証され、その検証結果が出力される）と、リクエストに応じたレスポンスデータが生成され、多重化部２０７により多重化され、レスポンスとしてＷＷＷサーバ２からＷＷＷブラウザ１に送信される（３３）。

（Ａ−３）第１の実施形態の効果
以上のように、第１の実施形態によれば、ＷＷＷブラウザ１からＷＷＷサーバ２ヘリクエストを送信する際に、リクエストデータと共に、セッションＩＤ及び検証データ（暗号化された時間情報）をも送信することにより、ＷＷＷサーバ２が、正当な利用者からのリクエスト、すなわち正当な利用者からのセッション識別データであるか、不正に取得、コピーまたは偽造されたセッション識別データであるかを判定することができる。

具体的には、リクエストを送信するときに、時間に関する情報をも送信されるので、過去に用いられたセッション識別データであるかどうかを判定することができる。

第１の実施形態では、リクエストを送信する時間に関する情報を用いていることで、利用者端末１がリロード（再リクエスト）を行ったとしても、その再リクエストには、前回（再リクエスト前の１回目のリクエスト）とは異なる時間に関する情報が付加されているので、その再リクエストを不正アクセスと間違えられることはない。

また、利用者端末１のみ、あるいは、利用者端末１とＷＷＷサーバ２のみが知る暗号化鍵で暗号化を行っているので、利用者以外の悪意のある第三者が不正にセッション識別データ（検証データ）を生成しようとしてもそれができず、第三者によるＷＷＷサービスの不正使用を防ぐことができる。

（Ｂ）第２の実施形態
次に、第２の実施形態について図面を参照して説明する。

第２の実施形態は、利用者端末１が、ＷＷＷサーバ２に対するリクエスト回数を記憶しておき、そのリクエスト回数を検証データとする場合について説明する。

（Ｂ−１）第２の実施形態の構成
図５は、第２の実施形態に係る利用者端末１の機能を説明する機能ブロック図である。

図５に示すように、第２の実施形態の利用者端末１が、図１に示す第１の実施形態の利用者端末１と異なる点は、検証データ生成部１０３の機能である。

従って、図５では、図１と対応する構成については対応する符号を付す。また、以下では、検証データ生成部１０３の機能について詳細に説明し、図１で既に説明した構成の機能については省略する。

検証データ生成部１０３は、図５に示すように、リクエスト回数保持部１０３３と、暗号化部１０３２とを有する。

リクエスト回数保持部１０３３は、ＷＷＷブラウザ１が目的とするＷＷＷサーバ（サービス）に対して送信したリクエスト回数に関する情報（以後、リクエスト回数と呼ぶことにする）を保持しており、そのリクエスト回数を暗号化部１０３２に与えるものである。リクエスト回数保持部１０３３は、セッション開始時、すなわち利用者が認証される前のリクエスト時に、保持内容を初期値に設定する。例えば、この初期値は通常０でもよいが、あらかじめ利用者端末１（ＷＷＷブラウザ）と目的とするＷＷＷサーバ２で合意した値であるならば、必ずしも０でなくともよい。

また、リクエスト回数保持部１０３３は、保持しているリクエスト回数を暗号化部１０３２に与え、そのリクエスト回数が暗号化部１０３２により暗号化される毎に、保持するリクエスト回数を増加させて保持内容を更新する。例えば、このリクエスト回数を増加させる方法は、一般的に１ずつ増加するようにしてもよいが、１ずつ増加させることに限らず、所定数ずつ増加させてもよい。

さらに、リクエスト回数保持部１０３３は、セッション毎のリクエスト回数を保持する。これにより、例えば、ＷＷＷブラウザ１が複数のＷＷＷサービスを利用する場合、ＷＷＷサービス毎のリクエスト回数を保持することができる。

暗号化部１０３２は、リクエスト回数保持部１０３３からリクエスト回数を受け取り、受け取ったリクエスト回数（データ）を暗号化するものである。暗号化部１０３２の暗号化方法は、第１の実施形態で説明したものと同様である。

また、暗号化部１０３２からの出力が、検証データ生成部１０３の出力となり、多重化部１０４へ出力される。

次に、図６を参照して、第２の実施形態のＷＷＷサーバ２について説明する。

第２の実施形態のＷＷＷサーバ２が第１の実施形態と異なる点は、検証部２０４の機能である。従って、図６において、図２での対応する構成については対応する符号を付す。以下では、検証部２０４の機能について詳細に説明する。

検証部２０４は、図６に示すように、暗号復号部２０４１、リクエスト回数検証部２０４４及びリクエスト回数保持部２０４５を有する。

暗号復号部２０４１は、分離部２０１により分離された検証データを受け取り、受け取った検証データの暗号復号を行い、その結果をリクエスト回数検証部２０４４に与えるものである。

暗号復号部２０４１は、セッション識別部２０３からセッションの識別結果を受け取り、これにより、どの暗号復号鍵、又はどの暗号復号方法を用いて暗号復号すればよいのかが判る。

リクエスト回数検証部２０４４は、暗号復号部２０４１により暗号復号されたリクエスト回数を受け取り、そのリクエスト回数について、リクエスト回数保持部２０４５に保持されている保持データを参照し、正当なものであるか否かを検証し、その検証結果を出力するものである。リクエスト回数検証部２０４４からの出力が検証部２０４の出力となり、レスポンスデータ生成部２０５に出力する。

リクエスト回数検証部２０４４は、セッション識別部２０３からセッションの識別結果を受け取り、その識別結果を用いてリクエスト回数保持部２０４５が保持するどのセッションの保持データを参照すればよいのかが判る。

リクエスト回数検証部２０４４は、暗号復号部２０４１により暗号復号されたリクエスト回数が、リクエスト回数保持部２０４５に保持されているリクエスト回数と一致する場合や（すなわち、検証データが重複して用いられている場合）、リクエスト回数保持部２０４５に保持されている最新のリクエスト回数よりも同じか少ない回数、又は、かけ離れて多いリクエスト回数を表している場合には、不正にセッション識別データを取得、コピーまたは偽造をして用いられているものと判断し、検証結果として、サービスを提供する資格がない旨を出力する。

リクエスト回数保持部２０４５は、セッション毎に、過去に受け取ったリクエストデータと多重化されていたデータリクエスト回数を保持しておく部分である。セッション開始時、すなわち利用者が認証される前のリクエスト時（図４における４１）に、リクエスト回数保持部２０４５の内容は初期値に設定される。初期値は通常０でもよいが、あらかじめ利用者（ＷＷＷブラウザ）と目的とするＷＷＷサーバで合意した値であるならば、必ずしも０でなくともよい。

また、リクエスト回数保持部２０４５は、複数のセッションを取り扱っている場合には、セッション毎にリクエスト回数を保持している。

また、リクエスト回数保持部２０４５は、リクエスト回数検証部２０４４でリクエスト回数を検証した結果が、正当なものであると判断されるならば、その正当なリクエスト回数を追加して保持しておく。リクエスト回数保持部２０４５の保持できる１つのセッションあたりのリクエスト回数の個数が１個だけであったならば、保持されているデータの上へ上書きする形になる。

（Ｂ−２）第２の実施形態の動作
図７は、第２の実施形態に係る利用者端末１とＷＷＷサーバ２との間で通信されるデータ検証システムの動作を示す説明図である。

利用者端末１（ＷＷＷブラウザ）からリクエストがあると（３０）、第１の実施形態と同様に、ＷＷＷサーバ２において利用者認証が行なわれ、ＷＷＷサーバ２から利用者端末１（ＷＷＷブラウザ）レスポンスが与えられる（３１）。

ここで、利用者端末１からＷＷＷサーバ２への初めて行われるリクエストを初期値（例えば「０」）とするリクエスト回数が、リクエスト回数保持部１０３３に保持され、その後のＷＷＷサーバ２とのセッション成立に従って、リクエスト回数は、所定規則に従って更新されてリクエスト回数保持部１０３３に保持される。

利用者端末１が、次にＷＷＷサーバ２にリクエストする際、利用者端末１において、リクエスト回数保持部１０３３に保持されているリクエスト回数Ｎが、暗号化部１０３２に与えられて、暗号化部１０３２により暗号化され検証データとして多重化部１０４に与えられる（１１）。

多重化部１０４により、リクエストデータ、セッションＩＤ（Ｃ）及び検証データ（Ｅ）が多重化されたリクエストは、利用者端末１からＷＷＷサーバ２に送信される（３２）。

ＷＷＷサーバ２にリクエストが与えられると、分離部２０１により、セッションＩＤ（Ｃ）及び検証データ（Ｅ）とが分離され、第１の実施形態と同様に、リクエストデータ解析部２０２、セッション識別部２０３及び検証部２０４に与えられる（３２）。

検証部２０４では、分離部２０１から検証データ（Ｅ）を受け取り、暗号復号部２０４１により、セッション識別部２０３から識別結果に基づいて検証データ（Ｅ）を暗号復号し、リクエスト回数Ｎを取り出す（２１）。

そして、リクエスト回数検証部２０４４により、セッション識別部２０３からの識別結果に基づいてリクエスト回数保持部２０４５が参照され、以前にリクエストをして認証された利用者からのリクエストであることが判定され、当該リクエスト回数Ｎと、前回のリクエスト回数とが比較されることにより、今回のリクエスト回数Ｎが正当であるかどうかを判定される（２３）。

例えば、リクエスト回数Ｎが、ＷＷＷサーバ２側でカウントされ保持されているリクエスト回数と一致あるいは少ない場合には、不正に取得またはコピーしたリクエスト回数Ｎを用いてリクエストを行っていると判断でき、または、ＷＷＷサーバ２側が保持しているリクエスト回数からかけ離れて多い場合には、偽造したリクエスト回数Ｎを用いてリクエストを行っていると判断できる。

また、検証部２０４において、検証されたリクエスト回数Ｎは、利用者毎にリクエスト回数保持部２０４５に保持される。これにより、リクエスト回数Ｎが重複して利用されたものかそうでないかを判別することができる。

セッションＩＤ（Ｃ）及びリクエスト回数（Ｎ）の正当性が判別されると、第１の実施形態と同様に、リクエストに応じたデータが、レスポンスとしてＷＷＷサーバ２から利用者端末１（ＷＷＷブラウザ）に送信される（３３）。

（Ｂ−３）第２の実施形態の効果
以上のように、第２の実施形態によれば、ＷＷＷブラウザ１からＷＷＷサーバ２ヘリクエストを送信する際に、リクエストデータと共に、セッションＩＤ及びリクエスト回数を暗号化した検証データも送信することにより、ＷＷＷサーバ２が、正当な利用者端末１からのリクエスト、すなわち正当な利用者からのセッション識別データであるか、不正に取得、コピーまたは偽造されたセッション識別データであるかを判定することができる。

具体的には、利用者端末１からリクエストを送信するときに、利用者のリクエスト回数に関する情報も送信されるので、過去に用いられたセッション識別データであるかどうかを判定することができる。

また、本実施形態では、ＷＷＷサーバ２側のレスポンスの回数ではなく、利用者のリクエスト回数に関する情報を用いているので、利用者端末１がリロード（再リクエスト）を行ったとしても、その再リクエストには、前回（再リクエスト前の１回目のリクエスト）とは異なる（前回よりも増加した）リクエスト回数が付加されているので、その再リクエストを不正アクセスと間違えられることはない。

また、利用者端末１のみ、又は、利用者端末１とＷＷＷサーバ２のみが知る暗号鍵で暗号化を行っているので、利用者以外の悪意のある第三者が不正にセッション識別データ（検証データ）を生成しようとしてもそれができず、第三者によるＷＷＷサービスの不正使用を防ぐことができる。

（Ｃ）第３の実施形態
次に、第３の実施形態について図面を参照して説明する。

（Ｃ−１）第３の実施形態の構成
図８は、第３の実施形態に係る利用者端末１の機能を示す機能ブロックである。

第３の実施形態が、第１の実施形態と異なる点は、検証データ生成部１０３の機能である。

図８では、図１の機能構成と対応するものについては対応する符号を付す。また、以下では、検証データ生成部１０３の機能について詳細に説明する。

検証データ生成部１０３は、図８に示すように、検証データ保持部１０３４、暗号化部１０３２を有する。

検証データ保持部１０３４は、ＷＷＷブラウザ１が目的とするＷＷＷサーバ２に対して、同じセッションについて、前回のリクエストの際に送信した検証データ（以後、保持検証データと呼ぶことにする）を保持するものであり、この保持検証データを暗号化部１０３２に出力する。セッション開始時にＷＷＷサーバ２からＷＷＷブラウザ１ヘセッションＩＤが送信されてきたとき（後述する図１０における３１）に、検証データ保持部１０３４は、そのセッションＩＤの値を初期値として設定する。なお、このセッションＩＤは、入力端子１１１から入力されたレスポンスを分離部１０６にて分離されたものである。

また、検証データ保持部１０３４は、初期値設定以降、ＷＷＷサーバ２とのセッションにより、ＷＷＷサーバ２から受け取った新たなセッションＩＤが送信されてきたとき（セッションＩＤの変更があったとき）に、そのセッションＩＤを更新する。なお、この更新すべきセッションＩＤは、入力端子１１１から入力されたレスポンスを分離部１０６にて分離されたものである。

また、検証データ保持部１０３４は、セッション毎の検証データが保持されている。これにより、検証データ保持部１０３４は、例えば、ＷＷＷサービスを複数利用する場合に、ＷＷＷサービス毎に保持検証データを保持することができる。

暗号化部１０３２は、検証データ保持部１０３４から保持検証データを受け取り、受け取った保持検証データを暗号化するものである。暗号化部１０３２の動作は、第１及び第２の実施形態と同様である。暗号化部１０３２からの出力が、検証データ生成部１０３の出力となり、多重化部１０４へ出力される。

また、暗号化部１０３２からの出力は、検証データ保持部１０３４にも渡されて、次のリクエストのときのために保持される。

次に、図９を参照して、ＷＷＷサーバ２の機能について説明する。図９において、図２の機能構成と対応するものは対応する符号を付す。

図９において、図２と異なる構成は、検証部２０４であるので、以下では、検証部２０４の機能について詳細に説明する。

検証部２０４は、図９に示すように、暗号復号部２０４１、検証データ検証部２０４６及び検証データ保持部２０４７を有する。

暗号復号部２０４１は、分離部２０１において分離された検証データを受け取り、受け取ったデータの暗号復号を行い、その結果を検証データ検証部２０４６に与えるものである。

暗号復号部２０４１は、第１及び第２の実施形態と同様に、セッション識別部２０３からの出力である識別結果を用いて、どの暗号復号鍵、どの暗号復号方法を用いて暗号復号すればよいのかが判る。

検証データ検証部２０４６は、暗号復号部２０４１により暗号復号された検証データを受け取り、セッション識別部２０３からの識別結果に基づいて検証データ保持部２０４７の内容を参照し、暗号復号部２０４１からの検証データが正当なものであるかを検証し、その検証結果を出力するものである。

検証データ検証部２０４６は、セッション識別部２０３からの出力である判定結果を用い、検証データ保持部２０４７における、どのセッションの保持データを参照すればよいのかがわかる。また、検証データ検証部２０４６からの出力が検証部２０４の出力となり、レスポンスデータ生成部２０５へ出力される。

また、検証データ検証部２０４６は、暗号復号部２０４１からの検証データが、検証データ保持部２０４７に保持されている最新のものと一致すれば、正当なリクエストとともに送信された検証データとして、検証成功の旨を出力する。また、検証成功の場合には、その検証データ（暗号復号していない受信したデータ）を保持しておくよう、検証データ保持部２０４７に与える。

また、検証データ検証部２０４６は、暗号復号部２０４１からの検証データが検証データ保持部２０４７に保持されている最新ではないものと一致（すなわち、検証データが重複して用いられている）しているならば、不正にセッション識別データを取得またはコピーをして用いられているものと判断し、検証結果として、サービスを提供する資格がない旨を出力する。

また、検証データ検証部２０４６は、暗号復号部２０４１からの検証データが、検証データ保持部２０４７に保持されている最新のものと一致しないと判断した場合には、再度、その検証データを暗号復号部２０４１に与えて再度の暗号復号を行なわせ、その再度の暗号復号された検証データについて再度検証する。

この検証データ検証部２０４６から暗号復号部２０４１への再度の暗号復号は、所定回数Ｍ回だけ繰り返しが可能であり、その都度得た検証データを検証することができる。

そして、検証データ検証部２０４６が、Ｍ回暗号復号を繰り返した検証データの検証が成功しなかった場合には、偽の検証データが送信されてきていると判断し、検証結果として、サービスを提供する資格がない旨を出力する。

検証データ保持部２０４７は、同じセッションのもので、過去に受け取ったリクエストデータと多重化されていたデータ検証データを保持しておく部分である。セッション開始時にＷＷＷサーバ２からＷＷＷブラウザ１ヘセッションＩＤを送信するとき（後述する図１０における３１）には、検証データ保持部２０４７は、そのセッションＩＤの値を初期値として保持しておくものである。このセッションＩＤは、セッションＩＤ生成部２０６から出力される。以降、ＷＷＷサーバ２からＷＷＷブラウザ１に新たなセッションＩＤが送信するとき（セッションＩＤの変更を行ったとき）には、検証データ保持部２０４７は、そのセッションＩＤを最新の保持検証データとして保持する。このセッションＩＤも、セッションＩＤ生成部２０６から出力される。複数のセッションを取り扱っている場合には、それらのセッション毎に検証データを保持する。

また、検証データ保持部２０４７は、この検証データ（暗号復号していない受信したデータ）を最新のものとして保持する。検証データ保持部２０４７の保持できる１つのセッションあたりの検証データの個数が１個だけであったならぱ、保持されているデータの上へ上書きする形になる。

（Ｃ−２）第３の実施形態の動作
図１０は、第３の実施形態に係る利用者端末とＷＷＷサーバとの間で通信されるデータ検証システムの動作を示す説明図である。

利用者端末１（ＷＷＷブラウザ）からリクエストがあると（３０）、第１及び第２の実施形態と同様に、ＷＷＷサーバ２において利用者認証が行なわれ、ＷＷＷサーバ２から利用者端末１（ＷＷＷブラウザ）レスポンスが与えられる（３１）。

このとき、ＷＷＷサーバ２では、セッションＩＤであるＣ０が多重化されており、レスポンスと同時に利用者端末１（ＷＷＷブラウザ）に送信されると共に、そのセッションＩＤであるＣ０が検証データ保持部２０４７に保持される。

また、利用者端末１（ＷＷＷブラウザ）では、ＷＷＷサーバ２からのレスポンスを分離して得たセッションＩＤ（Ｃ０）がセッションＩＤ保持部１０２及び検証データ保持部１０３４に保持される。

このようにセッションＩＤの送信には一般的にはＣｏｏｋｉｅが用いられるが、ＷＷＷサーバ２から送信されＷＷＷブラウザ１にＣ０のようなデータを保存できるものであれば、Ｃｏｏｋｉｅに限定しない。

利用者端末１が、次にＷＷＷサーバ２にリクエストを送信する場合（３２−１）、検証データ保持部１０３４に保持されている検証データＣ０が暗号化部１０３２に与えられ、暗号化部１０３２により、検証データＣ０は、暗号化鍵Ｋｅを暗号鍵として暗号化されて検証データＣ１が生成されて（１１−１）、暗号化されたデータＣ１が多重化部１０４に与えられる。なお、暗号化鍵Ｋｅは、第１及び第２のの実施形態で用いられるものと同様なものである。

また、リクエストデータ生成部１０１により生成されたリクエストデータ、及び、セッションＩＤ保持部１０２に保持されているセッションＩＤ（Ｃ０）も、第１及び第２の実施形態と同様に、多重化部１０４に与えられる。

そして、多重化部１０４により、リクエストデータ、セッションＩＤ（Ｃ０）及び暗号化された検証データ（Ｃ１）が多重化されてＷＷＷサーバ２に送信される（３２−１）。また、暗号化部１０３２の出力であるデータＣ１を検証データ保持部１０３４に保持する。

また、Ｃ０やＣ１はＣｏｏｋｉｅとして送信（３２−１）することもできるが、ＷＷＷブラウザからＷＷＷサーバヘ送信できるものであれば、Ｃｏｏｋｉｅに限定されない。

利用者端末１（ＷＷＷブラウザ）からのリクエストがＷＷＷサーバ２に与えられると、第１及び第２の実施形態と同様に、分離部２０１によりセッションＩＤ（Ｃ０）及び検証データ（Ｃ１）は分離され、リクエストデータ解析部２０２、セッション識別部２０３及び検証部２０４に与えられる。

検証部２０４では、分離部２０１から検証データＣ１を受け取り、暗号復号部２０４１により、セッション識別部２０３からの識別情報に基づいて検証データＣ１に対する暗号復号が行なわれる（２４−１）。なお、暗号復号鍵Ｋｄは、第１及び第２の実施形態と同様である。

また、検証データ検証部２０４６により、セッション識別部２０３からの識別情報に基づいて検証データ保持部２０４７が参照され、暗号復号部２０４１により暗号復号されたデータＣ１の検証が行なわれる（２４−１）。

検証データ検証部２０４６による検証が正当である（検証データ保持部２０４７の内容と一致する）場合、正当である旨の検証結果がレスポンスデータ生成部２０５に与えられる。レスポンスデータ生成部２０５では、リクエストデータ解析部２０２、セッション識別部２０３及び検証部２０４からの結果を受け取り、リクエストに応じたレスポンスデータを生成して、多重化部２０７により多重化されたレスポンスを利用者端末１（ＷＷＷブラウザ）に送信する（３３−１）。

このとき、データＣ１が、検証データ保持部２０４７に更新されて保持される。また、利用者端末１では、ＷＷＷサーバ２からのレスポンスを受け取る。

一方、検証データ検証部２０４６による検証が正当でない（検証データ保持部２０４７の内容と一致しない）場合、サービスを提供する資格がない旨の検証結果がレスポンスデータ生成部２０５に与えられ、その旨のレスポンスが利用者端末１（ＷＷＷブラウザ）に送信される（３３−１）。

その後、さらに利用者端末１（ＷＷＷブラウザ）からＷＷＷサーバ２にリクエストが行なわれると、上記と同様に、前回のＷＷＷサーバ２へのリクエストで暗号化され利用者端末１（ＷＷＷブラウザ）の検証データ保持部１０３４で保持されているデータＣ１が、暗号化部１０３２に与えられ、暗号化部１０３２により、データＣ１が暗号化鍵Ｋｅで暗号化されて、データＣ２が生成される（１１−２）。

そして、多重化部１０４により、リクエストデータと共に、セッションＩＤ（Ｃ０）とデータＣ２とが多重化されたリクエストが、ＷＷＷサーバ２に送信される（３２−２）。

このとき、ＷＷＷブラウザ１では、セッションＩＤ保持部１０２セッションＩＤ（Ｃ０）を保持すると共に、検証データ保持部１０３４で検証データＣ２を保持しておくようにする。

利用者端末１（ＷＷＷブラウザ）からＷＷＷサーバ２にリクエストが送信されると、上記と同様に、ＷＷＷサーバ２の分離部２０１により、セッションＩＤ（Ｃ０）と検証データ（Ｃ２）とが分離されて、リクエストデータ解析部２０２、セッション識別部２０３及び検証部２０４に与えられる。

リクエストデータ解析部２０２及びセッション識別部２０３での動作は上記と同様なので詳細な説明は省略する。

検証部２０４では、分離部２０１から検証データ（Ｃ２）が与えられ、暗号復号部２０４１により、セッション識別部２０３からの識別情報に基づいて、暗号復号鍵Ｋｄを用いて検証データ（Ｃ２）の暗号復号が行われる。

また、検証データ検証部２０４６により、検証データ保持部２０４７を参照して、暗号復号された検証データが検証される（２４−２）。

検証データ検証部２０４６による検証データの検証結果が正当である場合、すなわち、暗号復号された検証データがＣ１である場合、今回のリクエストが正当な利用者からのリクエストであると判断することができる。

検証データ検証部２０４６により、正当なリクエストであることが検証されると、その検証結果がレスポンスデータ生成部２０５に与えられ、リクエストに応じたレスポンスがＷＷＷサーバ２から利用者端末１（ＷＷＷブラウザ）に送信される（３３−２）。レスポンスの送信の際、ＷＷＷサーバ２では、検証データ保持部２０４７にデータＣ２が保持される。

さらに以降続くＷＷＷブラウザ１からＷＷＷサーバ２へのリクエストは、前回の送信した検証データＣ２（検証データ保持部１０３４で保持されているデータ）が、さらに暗号化部１０３２により暗号化されて、セッションＩＤ保持部１０２に保持されているＣ０及びリクエストデータと共に送信される（１１−３及び３２−３）。

それと同時にＷＷＷブラウザ１は、その暗号化した検証データＣ３を検証データ保持部１０３４に保持する（１１−３）。

さらに、ＷＷＷブラウザからのリクエストをＷＷＷサーバ２が受信すると、上記と同様にして、検証データＣ３の検証が行われ（２４−３）、リクエストに応じたレスポンスがＷＷＷブラウザ１に送信される（３３−３）。

ここで、ＷＷＷサーバ２の検証データ検証部２０４６では、検証データの検証について、複数回の暗号復号を多重に行うようにし、その複数回の暗号復号により得た検証データを用いて検証データの検証を行うようにしてもよい。

これにより、利用者端末１（ＷＷＷブラウザ）とＷＷＷサーバ２との間でのデータ通信において、例えば、保存している検証データの同期が採れなくなり、利用者端末１側とＷＷＷサーバ２側との間で保存している検証データが異なる値になった場合などにも検証データの検証を実現させることができる。

例えば、ＷＷＷブラウザ１からのリクエストが、何らかの理由でＷＷＷサーバ２へ届かなく、かつ、ＷＷＷブラウザ１で保存する検証データを届かなかったリクエストと共に送った検証データに書き換えてしまった場合、ＷＷＷブラウザ１とＷＷＷサーバ２との間で保存した検証データの同期がとれなくなってしまう。このような場合に、ＷＷＷサーバ２が受信した検証データについて多重に暗号復号を行うことで、その検証データの暗号化に係る変換履歴を知ることができ、その検証データの変換履歴を用いて検証データの検証を行う。

具体的には、例えば、図１０の３２−３の動作において、ＷＷＷブラウザ１からのリクエスト（Ｃ０及びＣ３を含むもの）がＷＷＷサーバ２に届かなかったとすると、ＷＷＷブラウザ１が保存している検証データはＣ３であり、リクエストが届かなかった側のＷＷＷサーバ２が保存している検証データはＣ２となる。

この後、再度、ＷＷＷブラウザ１がリクエストを送信する場合、ＷＷＷブラウザ１はＣ０及びＣ４（Ｃ３を暗号化したもの）を含むリクエストを送信することになるが、ＷＷＷサーバ２が保存している検証データはＣ２であるため、検証データＣ４を暗号復号してもＣ２を得ることはできず、検証が失敗してしまう。

この場合に、ＷＷＷサーバ２の検証データ検証部２０４６が検証したデータ（この場合Ｃ４を一度暗号復号したＣ３）を再度暗号復号部２０４１に与え、そのデータ（Ｃ３）について再度暗号復号させることで得たデータ（Ｃ２）について、検証データ検証部２０４６が再度検証をすることで、ＷＷＷサーバ２が保存しているデータ（Ｃ２）との一致した値を得ることができ検証に成功することができる。

このように、ＷＷＷサーバ２の検証データ検証部２０４６における検証データについて、Ｍ（Ｍは１以上の整数）回の暗号復号（Ｍ重の暗号復号）までの検証を許容することができる。なお、このＭの値は、固定でもよく、また、サーバの能力や利用者／セッション数、時間等に応じて可変となるようなものでもよい。

（Ｃ−３）第３の実施形態の効果
以上のように、第３の実施形態によれば、ＷＷＷブラウザ１がリクエストをする際に、リクエストデータと共に、セッションＩＤ及び前回のリクエストで得た暗号化された検証データを送信することにより、ＷＷＷサーバ２が、正当な利用者からのリクエスト、すなわち正当な利用者からのセッション識別データであるか、不正に取得、コピーまたは偽造されたセッション識別データであるかを判定することができる。

具体的には、ＷＷＷブラウザ１がリクエストを送信するときに、利用者の前回のセッションにおける検証データを暗号化したデータも送信されるので、過去に用いられたセッション識別データであるかどうかを判定することができる。利用者からのリクエストの毎に保持検証データを暗号化し、さらに、それをＷＷＷブラウザに保持するので、利用者がリロード（再リクエスト）を行ったとしても、その再リクエストには、前回（再リクエスト前の１回目のリクエスト）とは異なる（前回のものを暗号化している）検証データとともに送信されるので、その再リクエストを不正アクセスと間違えられることはない。また、利用者のみ、または利用者とＷＷＷサーバのみが知る暗号鍵で暗号化を行っているので、利用者以外の悪意のある第三者が不正にセッション識別データ（検証データ）を生成しようとしてもそれができず、第三者によるＷＷＷサービスの不正使用を防ぐことができる。

（Ｄ）第４の実施形態
次に、第４の実施形態について図面を参照して説明する。

第４の実施形態は、正当な利用者からの（再）リクエストと不正者のリクエストを判別するために、利用者端末は、リクエストデータと共に、利用者しか生成することができない検証データを一方向性関数を適用することにより作成して送り、サーバ側はその検証データを検証することにより不正利用かどうかを判別する場合について説明する。

（Ｄ−１）第４の実施形態の構成
図１１は、第４の実施形態に係る利用者端末１の機能を示す機能ブロックである。

第４の実施形態が、第１の実施形態と異なる点は、検証データ生成部１０３の機能である。

図１１では、図１の機能構成と対応するものについては対応する符号を付す。また、以下では、検証データ生成部１０３の機能について詳細に説明する。

検証データ生成部１０３は、図１１に示すように、乱数生成部１０３５、一方向性関数適用部１０３６およびｎ検証データ保持部１０３７を有する。

乱数生成部１０３５は、利用者の認証の際又は保持内容を新たに更新する際（例えば、ＷＷＷブラウザ１で保持している検証データを使いきってしまった場合など）、乱数を生成し、その乱数を一方向性関数適用部１０３６及びｎ検証データ保持部１０３７に与えるものである。なお、乱数生成部１０３５は、いわゆる厳密な乱数を発生させるものでなくともよく、例えば、利用者の操作により入力された値を乱数として出力するようにしてもよい。

一方向性関数適用部１０３６は、乱数生成部１０３５から乱数が入力されたとき、その乱数に対して一方向性関数を施すものである。また、一方向性関数適用部１０３６は、一方向性関数により得た値に対して、さらに一方向性関数を施していき、ｎ個の検証データを生成するものである。そして、一方向性関数適用部１０３６は、生成したｎ個の値を検証データとして順次ｎ検証データ保持部１０３７に与えて保持させるものである。

ここで、一方向性関数とは、関数に入力値を入力して出力値を得ることはできるが、逆に出力値から入力値を得ようとするためには、入力値をしらみつぶしに関数に入力して出力させてみる方法以外には有効な方法が存在しないような関数のことを指す。一方向性関数は、例えば、ハッシュ関数などを適用することができる。

ｎ検証データ保持部１０３７は、乱数生成部１０３５により生成された乱数及び一方向性関数適用部１０３６により生成されたｎ個の検証データを受け取り、これらを保持するものである。

ここで、ｎ検証データ保持部１０３７は、乱数生成部１０３５からの乱数を最初の保持データとして保持し、一方向性関数適用部１０３６からのｎ個検証データを、先入れ後出し（ＦＩＬＯ：ｆｉｒｓｔ−ｉｎ １ａｓｔ−ｏｕｔ）の方法で保持する。すなわち、生成される検証データを順番に保存していき、一番最後に入力され保持されたものから順番に出力する。また、ｎ検証データ保持部１０３７は、出力した検証データを保持内容から削除する。

さらに、ｎ検証データ保持部１０３７は、乱数生成部１０３５で乱数を生成したとき、すなわち、前述の利用者の認証の際又は保持内容を新たに更新する際には、最後にｎ検証データ保持部１０３７が保持している検証データを登録検証データとして多重部１０４に出力し、多重部１０４から送信させる。それ以外の場合（すなわち、乱数生成部１０３５が乱数を生成しない場合）は、リクエストデータ生成部１０１よりリクエストデータが出力されると（そのタイミングを知らせる信号線は点線矢印で示している）、ｎ検証データ保持部１０３７より検証データを出力する。ｎ検証データ保持部１０３７からの出力が、検証データ生成部１０３の出力となり、多重化部１０４で多重化されて送信される。

次に、本実施形態に係るＷＷＷサーバ２の機能について図１２を参照して説明する。

図１２に示すように、本実施形態のＷＷＷサーバ２が、第１の実施形態のＷＷＷサーバ２と異なる点は、検証部２０４の機能である。よって、以下では、検証部２０４の機能について詳細に説明する。なお、図１２では、図２と対応する構成については対応する符号を付す。

検証部２０４は、図１２に示すように、一方向性関数適用部１０３６、ｎ検証データ検証部２０４８および登録検証データ保持部２０４９を有する。

一方向性関数適用部１０３６は、ＷＷＷブラウザ１での一方向性関数適用部１０３６に対応するものであり、分離部２０１により分離された検証データを受け取り、その検証データに一方向性関数を施し、その結果をｎ検証データ検証部２０４８に与えるものである。

ｎ検証データ検証部２０４８は、セッション識別部２０３からの識別結果に基づいて登録検証データ保持部２０４９における、どのセッションの保持データ（登録検証データ）を参照すればよいのかがわかり、その登録検証データを参照して、一方向性関数適用部１０３６により一方向性関数が施されて得た検証データを検証し、その検証結果をレスポンスデータ生成部２０５に与えるものである。

つまり、ｎ検証データ検証部２０４８は、一方向性関数が施されて得た検証データが、登録検証データ保持部２０４９の最新の登録検証データと一致する場合、正当なリクエストと共に送信された検証データの検証が成功の旨の検証結果をレスポンスデータ生成部２０５に与え、また、最新の登録検証データでないものと一致する場合（検証データが重複して用いられている場合）、不正にセッション識別データを取得またはコピーをして用いられているものと判断し、サービスを提供する資格がない旨の検証結果をレスポンスデータ生成部２０５に与える。

また、ｎ検証データ検証部２０４８は、検証が成功した場合に、その検証データを登録検証データとして登録検証データ保持部２０４９に与えて保持させる。登録検証データ保持部２０４９への登録は、例えば、登録検証データ保持部２０４９が保持できる１つのセッションあたりの検証データの個数が１個だけであったならば、その保持している検証データに上書きすることで最新の検証データを登録させることができる。

また、ｎ検証データ検証部２０４８は、検証データが、登録検証データ保持部２０４９の保持データと異なる場合、その検証データを一方向性関数適用部１０３６に与えて、再度一方向性関数を施させて、それにより得た検証データの検証を行うようにしてもよい。そして、この一方向性関数の繰り返しをＭ（１以上の整数）回まで繰り返して、それでも成功しなかった場合に、偽の検証データが送信されてきたと判断し。検証結果としてサービスを提供する資格がない旨を出力する。

登録検証データ保持部２０４９は、同じセッションのもので、過去に受け取ったリクエストデータと多重化されていた検証データを保持しておくものである。登録検証データ保持部２０４９は、前述の利用者の認証の際又はＷＷＷブラウザ１側での保持内容の更新がなされた場合に、ＷＷＷブラウザ１から送信される登録検証データを初期値として保持する。

また、登録検証データ保持部２０４９は、ｎ検証データ検証部２０４８による検証が成功した場合に、ｎ検証データ検証部２０４８から検証データを受け取り、その検証データを最新の登録検証データとして保持するものである。

また、登録検証データ保持部２０４９は、複数のセッションを取り扱っている場合、それらのセッション毎に登録検証データを保持している。

（Ｄ−２）第４の実施形態の動作
図１３は、第４の実施形態に係る利用者端末とＷＷＷサーバとの間で通信されるデータ検証システムの動作を示す説明図である。

まず、ＷＷＷブラウザ１からＷＷＷサーバ２にリクエストを送信し、そのリクエストが利用資格のある利用者のものかどうかを判定する。ここでは、第１の実施形態と同様、リクエストに利用者のディジタル署名の入った証明書を付加して、ＷＷＷサーバ側でその証明書を検証することにより利用資格があるかどうかの判定を行うこともできる。また、図４で表しているように、ＩＤとパスワードを入力させるページを送り返し（４２）、ＩＤとパスワードを返送する（４３）ことにより行うこともできる。また、利用者とサーバ間で共通鍵を共有している場合、図４では、４２で乱数を伝送し、４３では共通鍵暗号の秘密鍵で暗号化して伝送するような、共通鍵暗号ベースの認証を行うこともできる。

第４の実施形態においては、ＷＷＷブラウザ１からＷＷＷサーバ２への認証情報提示時（すなわち、上記利用者のディジタル署名の入った証明書、パスワード、乱数を秘密鍵で共通鍵暗号化したもの等の送信時）に、利用者端末１において、以降のリクエストとともに送信する検証データをＷＷＷサーバ２側で検証するのに用いる検証データが生成され、その検証データを含むリクエストがＷＷＷサーバ２に送信されて、ＷＷＷサーバ２に登録検証データとして保存される（３０）。

ここで、３０における検証データの生成及びＷＷＷサーバ２への登録の動作について詳細に説明する。

（１）登録検証データを生成する際、利用者端末１において、乱数生成部１０３５により乱数（Ｋ１）が生成され、その乱数（Ｋ１）が一方向性関数適用部１０３６及びｎ検証データ保持部１０３７に与えられる。

（２）一方向性関数適用部１０３６において、乱数（Ｋ１）に対して一方向性関数が施され検証データ（Ｋ２）が得られ、検証データ（Ｋ２）がｎ検証データ保持部１０３７に与えられて保持される。

（３）このとき、一方向性関数適用部１０３６からの出力（Ｋ２）は、再度一方向性関数が施されて、検証データ（Ｋ３）が得られ、検証データ（Ｋ３）がｎ検証データ保持部１０３７に与えられて保持される。

（４）上記（３）と同様に、一方向性関数適用部１０３６により得られた検証データ（Ｋｉ）は、一方向性関数が施されて、検証データ（Ｋｉ＋１）が得られる。

（５）そして、ｉがｎになるまで、検証データは繰り返し一方向性関数が施される。

これにより、ｎ検証データ保持部１０３７では、乱数生成部１０３５からの乱数（Ｋ１）を最初に保存し、その後に、一方向性関数適用部１０３６からの検証データ（Ｋ２〜Ｋｎ＋１）が保存される。

そして、ｎ検証データ保持部１０３７に保持されている検証データ（Ｋ１〜Ｋｎ＋１）は、先入れ後出しにより、最後に入力された検証データ（Ｋｎ＋１）が最初に多重化部１０４に与えられ、リクエストデータ、及び検証データＫｎ＋１が多重化されてＷＷＷサーバ２に送信される。このとき、今回送信した検証データＫｎ＋１は、ｎ検証データ保持部１０３７から削除される。

ＷＷＷサーバ２には、利用者端末１と合意がとれている一方向性関数適用部１０３６を有している。利用者端末から送られてきたデータ（Ｋｎ＋１）が登録検証データとして登録検証データ保持部２０４９に登録される。

ＷＷＷサーバ２はリクエストに応じたデータをレスポンスとして送信する（３１）。このレスポンスは、レスポンスデータ及びセッションを識別するデータ（Ｃ）を多重化されたものである。このセッションを識別するために用いられるのは一般的にはＣｏｏｋｉｅであるが、ＷＷＷサーバ２から送信されＷＷＷブラウザにＣを保存できるものであれば、Ｃｏｏｋｉｅに限定しない。

次に、利用者端末１からＷＷＷサーバ２にリクエストを送信する場合、ｎ検証データ保持部１０３７に保存されている検証データ（Ｋｎ）が、多重化部１０４に与えられ、リクエストデータ、セッションＩＤ（Ｃ）及び検証データ（Ｋｎ）が多重化されて送信される（３２−１）。ここで、今回送信された検証データＫｎはｎ検証データ保持部１０３７から削除される。

Ｃ及びＫｎのＷＷＷサーバ２への送信は、Ｃｏｏｋｉｅとして送信することもできるが、ＷＷＷブラウザ１からＷＷＷサーバ２に送信できるものであれば、Ｃｏｏｋｉｅに限定されない。

ＷＷＷブラウザ１からのリクエストがＷＷＷサーバ２に与えられると、第１の実施形態と同様に、そのリクエストが分離部２０１により分離されて、それぞれのデータが、リクエストデータ解析部２０２、セッション識別部２０３及び検証部２０４に与えられる。

リクエストデータ解析部２０２及びセッション識別部２０３の動作は第１の実施形態と同様であるので動作説明を省略する。

検証部２０４では、分離部２０１から検証データ（Ｋｎ）が与えられ、その検証データ（Ｋｎ）に対して一方向性関数が施され、Ｋｎ＋１が得られる。そして、その検証データ（Ｋｎ＋１）がｎ検証データ検証部２０４８に与えられ、登録検証データ保持部２０４９が保持している登録検証データ（Ｋｎ＋１）と一致するかどうかの検証が行われる（２５−１）。

ｎ検証データ検証部２０４８により検証データの検証が正当である場合には、その旨がレスポンスデータ生成部２０５に与えられ、リクエストデータに応じたレスポンスデータが生成されてレスポンスが送信される（３３−１）。

また、ｎ検証データ検証部２０４８により検証データの検証が正当である場合には、今回受信した検証データ（Ｋｎ）が登録検証データとして登録検証データ保持部２０４９に保持される。

その後に続くＷＷＷブラウザ１からＷＷＷサーバ２へのリクエストは、上記と同様に、前回のリクエストで送信した検証データの１つ前に保持されたデータ（Ｋｎ−１）がリクエストと共にＷＷＷサーバ２に送信され（３２−２）、ＷＷＷサーバ２での検証データの検証は、上記と同様に行われる（２５−２）。

このように、ＷＷＷブラウザ１では、以前に用いた検証データを使い捨て、他の検証データを利用する。リクエストを送信する順番に、Ｋｎ、Ｋｎ−１、Ｋｎ−２、…、Ｋ１を検証データとして用いる。

ＷＷＷサーバ２における検証の過程では、ｎ検証データ検証部２０４８が受け取った検証データを一方向性関数適用部１０３６に与えて、複数回に渡って一方向性関数を施した検証データと、登録検証データ保持部２０４９に保持されている過去の検証データとを照合することにより、セッション識別データの重複使用を検出する。

これにより、第３の実施形態と同様に、ＷＷＷブラウザ１とＷＷＷサーバ２で、保存している検証データの同期がとれなくなって、その検証データがそれぞれ異なる値になった場合を考慮して検証データの検証を行うことができる。

例えば、ＷＷＷブラウザ１からのリクエストが、何らかの理由でＷＷＷサーバ２へ届かなった場合、ＷＷＷブラウザ１では、そのリクエストとともに送信した検証データは使い捨ててしまうので、ＷＷＷブラウザ１とＷＷＷサーバ２での保存した検証データの同期がとれなくなってしまう。

具体的に、図１３において、検証データ（Ｋｎ−２）を含むリクエストがＷＷＷサーバ２に届かず、その後の検証データ（Ｋｎ−３）を含むリクエストが利用者端末１から送信された場合、ＷＷＷサーバ２の登録検証データ保持部２０４９が保持している登録検証データがＫｎ−１であるため、検証データ（Ｋｎ−２）と登録検証データ（Ｋｎ−１）と一致せず、正当な検証が得られない。

しかし、この検証データ（Ｋｎ−２）を再度一方向関数適用部１０３６に与えて、再度一方向性関数を施すと検証データ（Ｋｎ−１）を得ることができるので、ＷＷＷサーバ２で保存されている登録検証データ（Ｋｎ−１）と一致し、正当な検証結果を得ることができる。

勿論、１回の一方向性関数の適用だけの検証ではなく、Ｍ回の一方向性関数の適用までの検証を許容するものとする。Ｍの値は、固定でもよく、また、サーバの能力や利用者／セッション数、時間等に応じて可変となるようなものでもよい。

また、ＷＷＷブラウザ１で保持している検証データを使いきってしまった場合には、その最後の検証データ（Ｋ１）を含むリクエストの送信時に、最初に利用者を認証するときと同様に、新たな値Ｌ１（Ｋ１に相当するもの）を生成して、ｎ個の検証データＬ１〜Ｌｎ（Ｋ１〜Ｋｎに相当するもの）および登録検証データＬｎ＋１（Ｋｎ＋１に相当するもの）を生成し、登録検証データＬｎ＋１をＷＷＷサーバ２へ送信することで、同様の動作をすることができる。

（Ｄ−３）第４の実施形態の効果
以上のように、第４の実施形態によれば、ＷＷＷブラウザ側１であらかじめ検証データをｎ個生成しておき、ＷＷＷサーバヘは検証時に利用する登録検証データを送信しておき、ＷＷＷブラウザからＷＷＷサーバヘリクエストを送信する際に、セッションＩＤ及び生成した検証データをも送信することにより、ＷＷＷサーバ２が、正当な利用者からのリクエスト、すなわち正当な利用者からのセッション識別データであるか、不正に取得、コピーまたは偽造されたセッション識別データであるかを判定することができる。

具体的には、リクエストを送信するときに、一度使用された検証データは使い捨て、正当なリクエストには使用しないようにしているので、過去に用いられたセッション識別データであるかどうかを判定することができる。利用者からのリクエストの毎に検証データを使い捨て、さらに、それをＷＷＷブラウザに保持するので、利用者がリロ一ド（再リクエスト）を行ったとしても、その再リクエストには、前回（再リクエスト前の１回目のリクエスト）とは異なる検証データとともに送信されるので、その再リクエストを不正アクセスと間違えられることはない。また、一方向性関数を施すことにより検証データを生成しており検証データを第三者が生成することはほとんど不可能であるので、利用者以外の悪意のある第三者が不正にセッション識別データ（検証データ）を生成しようとしてもそれができず、第三者によるＷＷＷサービスの不正使用を防ぐことができる。

（Ｅ）第５の実施形態
次に、本発明の第５の実施形態について図面を参照して説明する。

本実施形態は、正当な利用者からの（再）リクエストと不正者のリクエストを判別するために、利用者端末は、リクエストとともに、時間に関する情報に対して正当な利用者しか施すことのできないディジタル署名を施したデータを送り、サーバ側は検証データである時間に関する情報およびディジタル署名を検証することにより不正利用かどうかを判別する場合について説明する。

（Ｅ−１）第５の実施形態の構成
図１４及び図１５は、本実施形態に係る利用者端末１の機能を示すブロック図である。図１４及び図１５に示す本実施形態の利用者端末１は、検証データ生成部１０３がディジタル署名を施した検証データを送出する点で共通し、検証データ生成部１０３のディジタル署名を付与する情報が異なる。

以下では、図１４及び図１５を参照して、本実施形態の利用者端末１の機能について説明する。なお、図１４及び図１５において、図１に示す第１の実施形態の利用者端末１の構成と対応する構成については対応する符号を付す。

以下では、まず、図１４に示す利用者端末１の検証データ生成部１０３の機能について説明する。

図１４において、検証データ生成部１０３は、時間情報生成部１０３１、署名生成部１０３８を有する。

時間情報生成部１０３１は、第１の実施形態で説明したものに対応するものであるため、ここでの詳細な機能説明は省略する。また、時間情報生成部１０３１は、生成した時間情報（Ｔ）を署名生成部１０３８に与えるものである。

署名生成部１０３８は、時間情報生成部１０３１により生成された時間情報（Ｔ）を受け取り、その受け取った時間情報に対してディジタル署名を作成し、そのディジタル署名（以後、署名データ（Ｓ）と呼ぶ。）を、時間情報（Ｔ）と共に多重化部１０４に与えるものである。署名生成部１０３８から出力される検証データ（時間情報及び署名データ）が検証データ生成部１０３の出力となる。

また、署名生成部１０３８におけるディジタル署名作成方法は、ＷＷＷサーバ２とＷＷＷブラウザ１との間であらかじめ決められた方法を採用する。

例えば、図３で説明したような例を挙げると、利用者の認証において、ディジタル署名の入った証明書を用いる場合では、ディジタル署名を行う秘密鍵を用いた公開鍵暗号に基づくディジタル署名作成方式（例えば、ＲＳＡ署名）を採用することができ、また、ＩＤとパスワード入力による認証の場合では、パスワードを暗号化鍵とする共通鍵暗号に基づくディジタル署名作成方式（例えば、ｋｅｙｅｄ−ｈａｓｈを用いるＭＡＣ（ｍｅｓｓａｇｅ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｃｏｄｅ）メッセージ認証子）を採用することができる。さらに、共通鍵暗号ベースの認証の場合に用いる秘密鍵を共通鍵暗号に基づくディジタル署名作成方式を採用することができる。

なお、ＷＷＷサーバ２とＷＷＷブラウザ１との間で合意が取れているようなディジタル署名作成方式であればどんな方法であってもよい。また、以下では、ディジタル署名に用いる鍵を署名鍵Ｋｅと呼ぶことにする。

次に、図１５に示す利用者端末１の検証データ生成部１０３の機能について説明する。

図１５において、本実施形態の検証データ生成部１０３は、時間情報生成部１０３１、データ結合部１０３９、署名生成部１０３８を有する。

データ結合部１０３９は、時間情報生成部１０３１から時間情報を受け取り、またセッションＩＤ保持部１０２からセッションＩＤを受け取り、これら２つの入力情報を結合するものであり、その結合したデータを署名生成部１０３８に与えるものである。

データ結合部１０３９による結合方法は、ＷＷＷサーバ２において検証できる署名が作成できるよう、ＷＷＷブラウザ１とＷＷＷサーバ２との間で合意のとれている結合方法であればどのような方法でもよいが、例えば、単にセッションＩＤの後ろに時間情報を連接させる方法や、又例えば、セッションＩＤを２つに分割して間に時間情報を挿入して結合する等の方法を採用できる。

次に、本実施形態に係るＷＷＷサーバ２の機能について図１６及び図１７を参照して説明する。なお、図１６及び図１７において、図２に示すＷＷＷサーバ２の構成と対応する構成については対応する符号を付す。

図１６及び図１７のＷＷＷサーバ２は、検証部２０４が署名データ（Ｓ）の検証を行う点で共通し、検証部２０４が検証する検証データの内容が異なる点で異なる。

まず、図１６のＷＷＷサーバ２の検証部２０４の機能について説明する。

図１６において、本実施形態の検証部２０４は、署名検証部２０４０１、時間情報検証部２０４２、時間情報保持部２０４３を有する。

時間情報検証部２０４２及び時間情報保持部２０４３は、第１の実施形態のＷＷＷサーバ２の時間情報検証部２０４２及び時間情報保持部２０４３に対応するものであるため、既に説明した機能説明については省略する。

署名検証部２０４０１は、分離部２０１より分離された検証データ（時間情報及び署名データ）を受け取り、署名データＳに対してディジタル署名を検証するための鍵（以後、署名検証鍵という）Ｋｄを用いて、ディジタル署名検証を行うものである。また、署名検証部２０４０１は、署名データの検証結果と時間情報とを時間情報検証部２０４２に与えるものである。

署名データの検証方法は、例えば、受け取った検証データからＷＷＷブラウザ１側と同様の検証方法でディジタル署名を作成し、受け取った署名データと一致するかどうかで検証を行う。

署名検証部２０４０１は、セッション識別部２０３からの出力である判定結果を用い（信号線は点線矢印で示している）、どの暗号復号鍵、どのディジタル署名検証方法を用いて暗号復号すればよいのかが判る。

時間情報検証部２０４２は、署名検証部２０４０１から署名データの検証結果と時間情報とを受け取り、時間情報の検証については、第１の実施形態と同様にして検証を行うものである。

時間情報検証部２０４２は、署名検証部２０４０１による署名データの検証結果が正当であり、かつ、時間情報の検証結果が正当であると判断した場合に、検証が成功した旨をレスポンスデータ生成部２０５に与えるものである。

また、時間情報検証部２０４２は、署名データ及び又は時間情報の検証結果が不当である場合に、不正にセッション識別データを取得若しくはコピー、又は偽造をして用いられているものと判断し、サービスを提供する資格がない旨をレスポンスデータ生成部２０５に与えるものである。

次に、図１７に示すＷＷＷサーバ２の検証部２０４の機能について説明する。

図１７に示すように、検証部２０４は、データ結合部１０３９、署名検証部２０４０１、時間情報検証部２０４２、時間情報保持部２０４３を有する。

データ結合部１０３９は、分離部２０１から、検証データの時間情報とセッションＩＤとを受け取り、これら時間情報とセッションＩＤを結合するものである。また、データ結合部１０３９は、結合したデータを署名検証部２０４０１に与えるものである。

データ結合部１０３９によるデータの結合方法は、図１５の利用者端末１のデータ結合部１０３９と同様に、ＷＷＷサーバ２において、検証できる署名が作成できるよう、ＷＷＷブラウザ１とＷＷＷサーバ２との間で合意のとれている結合方法であれば、どのような方法でもよく、例えば、単にセッションＩＤの後ろに時間情報を連接させる方法や、また例えば、セッションＩＤを２つに分割して間に時間情報を挿入して結合する方法を採ることができる。

（Ｅ−２）第５の実施形態の動作
図１８は、第５の実施形態に係る利用者端末１とＷＷＷサーバ２との間で通信されるデータ検証システムの動作を示す説明図である。

第５の実施形態では、第１の実施形態と同様に、時間に関する情報を用いて検証データを作成する。また、「正当な人が検証データを作成した」という証明について、第１の実施形態では、利用者端末のみが使用できる暗号化鍵を用いて時間情報を暗号化することにより行う場合について説明したが、第５の実施形態では、利用者のみが使用できる暗号化鍵を用いたディジタル署名を用いることにする。

まず、図１４に示す利用者端末１から図１６に示すＷＷＷサーバ２に対してリクエストを行う場合について説明する。

利用者端末１からＷＷＷサーバ２にリクエストが送信されると、ＷＷＷサーバ２はそのリクエストが利用資格のある利用者のものかどうかを判定する（３０）。３０においては、第１の実施形態の場合と同様である。

次に、ＷＷＷサーバ２はリクエストに応じたデータをレスポンスとして送信する（３１）。

このとき、セッションを識別するためのセッションＩＤ（Ｃ）もレスポンスと同時に利用者端末１に送信される。また、ＷＷＷサーバ２から送信されたレスポンスは利用者端末１に受信され、セッションＩＤ（Ｃ）がセッションＩＤ保持部１０２に保存される。

利用者端末１が、次にＷＷＷサーバ２にリクエストを送信する場合、時間情報生成部１０３１により、リクエストを送出に係る時間情報Ｔが生成されて、署名生成部１０３８に与えられ、署名生成部１０３８により、時間情報Ｔに対する暗号化鍵Ｋｅでディジタル署名が作成される（１２）。

ディジタル署名された後のデータＳは、多重化部１０４に与えられ、多重化部１０４により、リクエストデータ、セッションＩＤ（Ｃ）、時間情報Ｔ、署名データＳが多重化され、リクエストとしてＷＷＷサーバ２に送信される（３２）。

ここで、署名鍵Ｋｅは、３０において用いられる利用者認証に依存するものでよく、例えば、利用者認証にディジタル署名の入った証明書を用いる場合では、利用者認証で用いるディジタル署名の秘密鍵を、時間情報のディジタル署名で用いるＫｅとして使用することもできるし、ＩＤとパスワード入力による認証の場合では、パスワードを署名鍵Ｋｅとして、１２におけるディジタル署名作成方法を共通鍵暗号に基づくものとすることもできる。また、共通鍵暗号ベースの認証の場合には、用いる秘密鍵を署名鍵Ｋｅとして１２に共通鍵暗号に基づくものを用いることもできる。

また、署名鍵Ｋｅは、利用者認証の際に用いる値以外のものであってもよいが、
（１）利用者のみ、もしくは利用者とサーバのみ、で知り得る値。

（２）サーバ側において、その値でディジタル署名検証のための鍵が利用できるようになっている。

という条件を満たす必要がある。

なお、セッションＩＤ（Ｃ）、時間情報Ｔ及び署名データＳのＷＷＷサーバ２への送信（３２）は、Ｃｏｏｋｉｅとして送信することもできるが、ＷＷＷブラウザ１からＷＷＷサーバ２に送信できるものであれば、Ｃｏｏｋｉｅに限定されない。

上記で説明した動作は、図１４の利用者端末１と図１６のＷＷＷサーバ２との間のデータ通信について説明したが、図１５の利用者端末１と図１７のＷＷＷサーバ２との間のデータ通信についても、上記と同様である。署名生成部１０３８は、データ結合部１０３９により結合された結合データ（時間情報とセクションＩＤとの結合）に対してディジタル署名を作成して出力する。

利用者端末１からのリクエストがＷＷＷサーバ２に与えられると、第１の実施形態と同様に、リクエストは分離部２０１により分離される（３２）。そして、検証データ（時間情報Ｔ及び署名データＳ）は、署名検証部２０４０１に与えられる。

署名検証部２０４０１において、署名データＳは、署名検証鍵Ｋｄを用いてディジタル署名検証が行なわれ、その検証結果及び時間情報Ｔが、時間情報検証部２０４２に与えられる（２６）。

署名検証鍵Ｋｄは、前述した暗号化鍵Ｋｅとは対になるものであり、あるいは、同じものであり、署名鍵Ｋｅと同様に、３０において用いられる認証に依存するものでもよい。署名検証鍵Ｋｄは、例えば、利用者認証にディジタル署名の入った証明書を用いる場合では、ディジタル署名を行う秘密鍵を署名鍵Ｋｅとして、１２（図１４の署名生成部１０３８）及び２６（図１６の署名検証部２０４０１）で用いるディジタル署名作成方法及びディジタル署名検証方法を公開鍵暗号に基づくものとし、さらに署名検証鍵Ｋｄは、ディジタル署名の秘密鍵と対になる公開鍵とする。また、ＩＤとパスワード入力による利用者認証の場合では、パスワードを署名鍵Ｋｅおよび署名検証鍵Ｋｄとして、１２（図１４の署名生成部１０３８）及び２６（図１６の署名検証部２０４０１）で用いるディジタル署名作成方法及びディジタル署名検証方法を共通鍵暗号に基づくものとすることもできる。さらに、共通鍵暗号ベースの利用者認証の場合には、利用者認証に用いる秘密鍵を署名鍵Ｋｅ及び署名検証鍵Ｋｄとして１２（図１４の署名生成部１０３８）及び２６（図１６の署名検証部２０４０１）に共通鍵暗号に基づくものを用いることもできる。

署名検証部２０４０１による検証結果と時間情報Ｔが時間情報検証部２０４２に与えられると、時間情報検証部２０４２により、第１の実施形態と同様に、時間情報Ｔの検証が行われる（２６）。

時間情報検証部２０４２において、署名データＳの検証結果が正当であり、かつ、時間情報Ｔの検証結果が正当である場合には、検証が成功した旨の検証結果がレスポンスデータ生成部２０５に与えられ、リクエストに応じたレスポンスデータが生成され、レスポンスが利用者端末１に送信される（３３）。

また、時間情報検証部２０４２が検証した時間情報Ｔは、時間情報保持部２０４３に与えられ、利用者毎に時間情報保持部２０４３に保持される。これにより、利用者毎の過去の時間情報を保持することができるので、時間情報Ｔが重複して利用されたものかそうでないかを判別することができる。

（Ｅ−３）第５の実施形態の効果
以上のように、第５の実施形態によれば、ＷＷＷブラウザからＷＷＷサーバヘリクエストを送信する際に、セッションＩＤ、時間に関する情報、時間に関する情報に対して作成したディジタル署名を送信することにより、ＷＷＷサーバが、正当な利用者からのリクエスト、すなわち正当な利用者からのセッション識別データであるか、不正に取得、コピーまたは偽造されたセッション識別データであるかを判定することができる。

具体的には、リクエストを送信するときに、時間に関する情報をも送信されるので、過去に用いられたセッション識別データであるかどうかを判定することができる。時間に関する情報を用いていることで、利用者がリロード（再リクエスト）を行ったとしても、その再リクエストには、前回（再リクエスト前の１回目のリクエスト）とは異なる時間に関する情報が付加されているので、その再リクエストを不正アクセスと間違えられることはない。さらに、時間情報（または、時間情報とセッションＩＤを結合させたもの）に対してディジタル署名を作成しているので、その時間情報が偽造であるかどうかが判り、このディジタル署名は、利用者のみ、または利用者とＷＷＷサーバのみが知る署名鍵で作成しているので、利用者以外の悪意のある第三者が不正にセッション識別データ（検証データ）を生成しようとしてもそれができず、第三者によるＷＷＷサービスの不正使用を防ぐことができる。第１の実施形態では、時間情報を暗号化しているが、第５の実施形態では、時間情報に対してディジタル署名を作成している。もし、時間情報が比較的大きなサイズのデータであった場合には、暗号化するよりもディジタル署名を作成するほうが効率がよい。

（Ｆ）第６の実施形態
次に、本発明の第６の実施形態について説明する。

第６の実施形態は、正当な利用者からの（再）リクエストと不正者のリクエストを判別するために、利用者端末は、リクエストとともに、利用者が出力したリクエスト回数に関する情報に対して正当な利用者しか施すことのできないディジタル署名を施したデータを送り、サーバ側は検証データであるリクエスト回数に関する情報およびディジタル署名を検証することにより不正利用かどうかを判別する場合について説明する。

（Ｆ−１）第６の実施形態の構成
図１９及び図２０は、第６の実施形態に係る利用者端末１の機能を示すブロック図である。

図１９及び図２０に示す本実施形態の利用者端末１は、検証データ生成部１０３がディジタル署名を施した検証データを送出する点で共通し、ディジタル署名の作成が、リクエスト回数のみ対するものであるか、リクエスト回数とセッションＩＤとを結合したものに対するものであるかが異なる。

以下では、図１９及び図２０を参照して、本実施形態の利用者端末１の機能について説明する。なお、図１９及び図２０において、図１に示す第１及び図５に示す第２の実施形態の利用者端末１の構成と対応する構成については対応する符号を付す。

以下では、まず、図１９に示す利用者端末１の検証データ生成部１０３の機能について説明する。

図１９において、検証データ生成部１０３は、リクエスト回数保持部１０３３、署名生成部１０３８を有する。

リクエスト回数保持部１０３３は、第２の実施形態で説明したリクエスト回数保持部１０３３に対応するものである。また、リクエスト回数保持部１０３３は、リクエスト回数を署名生成部１０３８に与えるものである。

署名生成部１０３８は、第５の実施形態の署名生成部に対応するものであり、リクエスト回数保持部１０３３からリクエスト回数を受け取り、そのリクエスト回数に対して署名鍵Ｋｅを用いてディジタル署名を作成するものである。また、署名生成部１０３８は、ディジタル署名により作成した署名データＳとリクエスト回数を多重化部１０４に与えるものである。

次に、図２０の利用者端末１の検証データ生成部１０３の機能について説明する。

図２０において、検証データ生成部１０３は、リクエスト回数保持部１０３３、データ結合部１０３９、署名生成部１０３８を有する。

データ結合部１０３９は、第５の実施形態で説明したデータ結合部に対応するものであり、リクエスト回数保持部１０３３からのリクエスト回数とセッションＩＤ保持部１０２からのセッションＩＤ（Ｃ）とを結合し、その結合したデータを署名生成部１０３８に与えるものである。

次に、第６の実施形態に係るＷＷＷサーバ２の機能について説明する。

図２１及び図２２は、第６の実施形態のＷＷＷサーバ２の機能を示すブロック図である。図２１及び図２２に示すＷＷＷサーバ２は、検証部２０４がディジタル署名検証を行う点で共通し、ディジタル署名の作成が、リクエスト回数だけに対するものであるか、セッションＩＤとリクエスト回数とを結合したものに対するものであるかの違いがある。

まず、図２１のＷＷＷサーバ２の検証部２０４の機能について説明する。

図２１において、検証部２０４は、署名検証部２０４０１、リクエスト回数検証部２０４４、リクエスト回数保持部２０４５を有する。

署名検証部２０４０１は、第５の実施形態の署名検証部に対応するものであり、分離部２０１より分離された検証データ（リクエスト回数及び署名データ）を受け取り、署名データに対して署名検証鍵Ｋｄを用いて署名データの検証を行うものである。署名検証部２０４０１は、署名データのディジタル署名検証結果とリクエスト回数とをリクエスト回数検証部２０４４に与えるものである。

署名検証部２０４０１では、セッション識別部２０３からの出力である判定結果を用い（信号線は点線矢印で示している）、どの暗号復号鍵、どのディジタル署名検証方法を用いて暗号復号すればよいのかが判る。

リクエスト回数検証部２０４４およびリクエスト回数保持部２０４５は、第２の実施形態のリクエスト回数検証部及びリクエスト回数保持部に対応するものである。

リクエスト回数検証部２０４４は、署名検証部２０４０１によるディジタル署名検証結果が正当であり、かつ、リクエスト回数検証部２０４４が行ったリクエスト回数に基づく検証結果が正当である場合に、検証データの検証が成功の旨をレスポンスデータ生成部２０５に与えるものである。また、リクエスト回数検証部２０４４は、ディジタル署名検証結果及び又はリクエスト回数に基づく検証結果が不当である場合に、不正にセッション識別データを取得若しくはコピー、又は偽造をして用いられているものと判断し、サービスを提供する資格がない旨をレスポンスデータ生成部２０５に与えるものである。

なお、リクエスト回数検証部２０４４からの出力が検証部２０４の出力となり、レスポンスデータ生成部２０５へ出力される。

次に、図２２のＷＷＷサーバ２の検証部２０４の機能について説明する。

図２２において、検証部２０４は、データ結合部１０３９、署名検証部２０４０１、リクエスト回数検証部２０４４、リクエスト回数保持部２０４５を有する。

データ結合部１０３９は、第５の実施形態のＷＷＷサーバ２のデータ結合部１０３９に対応するものであり、分離部２０１により分離されたリクエスト回数とセッションＩＤとを受け取り、それらリクエスト回数とセッションＩＤとを結合して、その結合したデータを署名検証部２０４０１に与えるものである。

（Ｆ−２）第６の実施形態の動作
図２３は、第６の実施形態に係る利用者端末１とＷＷＷサーバ２との間で通信されるデータ検証システムの動作を示す説明図である。

第６の実施形態では、第２の実施形態と同様に、リクエスト回数に関する情報を用いて検証データを作成する。また、「正当な人が検証データを作成した」という証明について、第２の実施形態では、利用者端末のみが使用できる暗号化鍵を用いてリクエスト回数を暗号化することにより行う場合について説明したが、第６の実施形態では、利用者のみが使用できる暗号化鍵を用いたディジタル署名を用いることにする。

なお、以下では、図１９の利用者端末１と図２１のＷＷＷサーバ２との間でのデータ通信の動作について説明する。

まず、ＷＷＷブラウザ１よりリクエストを行い、ＷＷＷサーバ２はそのリクエストが利用資格のある利用者のものかどうかを判定する（３０）。３０においては、第２の実施例の説明と同様である。

ＷＷＷサーバ２はリクエストに応じたデータをレスポンスとして送信する（３１）。ここでの動作は、第２及び第５の実施形態の動作と同様であり、利用者端末１では、ＷＷＷサーバ２からのセッションＩＤ（Ｃ）がセッションＩＤ保持部１０２に保持される。

次に、利用者端末１からＷＷＷサーバ２にリクエストを送信する場合、リクエスト回数保持部１０３３に保持されているリクエスト回数Ｎ（今回のリクエストまでにＷＷＷサーバ２に対する送信したリクエスト回数）が署名生成部１０３８に与えられ、署名生成部１０３８により、リクエスト回数Ｎに対して署名鍵Ｋｅでディジタル署名が作成され、その署名データＳが多重化部１０４に与えられる。そして、多重化部１０４により、リクエストデータ、セッションＩＤ（Ｃ）、検証データ（リクエスト回数Ｎ及び署名データＳ）が多重化されてＷＷＷサーバ２に送信される（３２）。なお、ディジタル署名の作成方法は、第５の実施形態と同様である。

上記で説明した動作は、図１９の利用者端末１と図２１のＷＷＷサーバ２との間のデータ通信について説明したが、図２０の利用者端末１と図２２のＷＷＷサーバ２との間のデータ通信についても、上記と同様である。署名生成部１０３８は、データ結合部１０３９により結合された結合データ（時間情報とセクションＩＤとの結合）に対してディジタル署名を作成して出力する。

利用者端末１からのリクエストがＷＷＷサーバ２に与えられると、第２及び第５の実施形態と同様に、分離部２０１により分離される。

検証部２０４では、分離部２０１からの署名データＳに対して署名検証鍵Ｋｄを用いてディジタル署名検証を行い、そのディジタル署名検証結果とリクエスト回数が、リクエスト回数検証部２０４４に与えられる（２６）。

また、リクエスト回数検証部２０４４では、リクエスト回数に基づく検証が行われ、ディジタル署名検証結果が正当であり、かつ、リクエスト回数に基づく検証結果が正当である場合に、検証データの検証が成功した旨がレスポンスデータ生成部２０５に与えられ、リクエストに応じたレスポンスが利用者端末１に送信される（３３）。

また、ディジタル署名検証結果及び又はリクエスト回数に基づく検証結果が不当である場合には、不正に取得またはコピーしたＮを用いてリクエストを行っていると判断し、不正である旨がレスポンスデータ生成部２０５に与えられる。

また、リクエスト回数検証部２０４４において、リクエスト回数が、各利用者毎にリクエスト回数保持部２０４５に与えられ、リクエスト回数保持部２０４５に利用者毎で保持される。

（Ｆ−３）第６の実施形態の効果
以上のように、第６の実施形態によれば、ＷＷＷブラウザからＷＷＷサーバヘリクエストを送信する際に、セッションＩＤ、ＷＷＷブラウザが出力したリクエスト回数に関する情報、リクエスト回数に対して作成したディジタル署名を送信することにより、ＷＷＷサーバが、正当な利用者からのリクエスト、すなわち正当な利用者からのセッション識別データであるか、不正に取得、コピーまたは偽造されたセッション識別データであるかを判定することができる。

具体的には、リクエストを送信するときに、利用者のリクエスト回数に関する情報をも送信されるので、過去に用いられたセッション識別データであるかどうかを判定することができる。サーバ側のレスポンスの回数ではなく、利用者のリクエスト回数に関する情報を用いているので、利用者がリロード（再リクエスト）を行ったとしても、その再リクエストには、前回（再リクエスト前の１回目のリクエスト）とは異なる（前回よりも増加した）リクエスト回数が付加されているので、その再リクエストを不正アクセスと間違えられることはない。さらに、リクエスト回数（または、リクエスト回数とセッションＩＤを結合させたもの）に対してディジタル署名を作成しているので、そのリクエスト回数が偽造であるかどうかが判り、このディジタル署名は、利用者のみ、または利用者とＷＷＷサーバのみが知る暗号化鍵で作成しているので、利用者以外の悪意のある第三者が不正にセッション識別データ（検証データ）を生成しようとしてもそれができず、第三者によるＷＷＷサービスの不正使用を防ぐことができる。第２の実施形態では、リクエスト回数を暗号化しているが、第６の実施形態では、リクエスト回数に対してディジタル署名を作成している。もし、リクエスト回数が比較的大きなサイズのデータであった場合には、暗号化するよりもディジタル署名を作成するほうが効率がよい。

（Ｇ）他の実施形態
（Ｇ−１）第３の実施形態では、ＷＷＷサーバ側で、受け取った検証データの暗号復号により、検証データの正当性の検証を行っていたが（暗号復号をして、それが前回の検証データまたはセッションＩＤになるかを確かめる）、前回の検証データの暗号化を行い（すなわち、ＷＷＷブラウザ側で検証データを作成するときと同じ変形を行う）、それが今受け取った検証データと一致するかどうかで検証することもできる。一致すれば正当なものとみなせる。その構成を図２４に示す。検証データ保持部２０４７から最新の検証データを暗号化部１０３２で暗号化を行い、その暗号化データと入力された検証データとを、検証データ検証部２０４６で比較し、一致したならば、検証成功の旨を出力する。また、一致しなかった場合は、暗号化データの暗号化を再度行い、入力された検証データとの比較をして検証する。Ｍ回暗号化を試してみて一致しなかった場合には、検証失敗とする。暗号化部１０３２は、図８におけるものと同じである。

（Ｇ−２）第４の実施形態において、ＷＷＷブラウザ側であらかじめ検証データを作成し、すべて記憶させていたが、記憶容量が少なくても済むように、ＷＷＷサーバ側に送信する登録検証データ（図１３におけるＫｎ＋１）を計算した後は、ＷＷＷブラウザ側で、Ｋ１と、何番目の検証データまで使用しているか（Ｋの添え字の数字）を記憶させているならば、Ｋ１以外のＫｉすべてを記憶させておく必要がなくなり、削除しておくことができる。したがって、リクエストをする度に、記憶させている何番目の検証データまで使用したかということ（ｉとする）をもとにＫ１をｉ−２回一方向性関数を施し、検証データを得るようにしてもよい。

第１の実施形態に係る利用者端末の機能を示すブロック図である。 第１の実施形態に係るＷＷＷサーバの機能を示すブロック図である。 第１の実施形態に係るデータ認証システムの動作を示す説明図である。 第１の実施形態に係るデータ通信を示す説明図である。 第２の実施形態に係る利用者端末の機能を示すブロック図である。 第２の実施形態に係るＷＷＷサーバの機能を示すブロック図である。 第２の実施形態に係るデータ認証システムの動作を示す説明図である。 第３の実施形態に係る利用者端末の機能を示すブロック図である。 第３の実施形態に係るＷＷＷサーバの機能を示すブロック図である。 第３の実施形態に係るデータ認証システムの動作を示す説明図である。 第４の実施形態に係る利用者端末の機能を示すブロック図である。 第４の実施形態に係るＷＷＷサーバの機能を示すブロック図である。 第４の実施形態に係るデータ認証システムの動作を示す説明図である。 第５の実施形態に係る利用者端末の機能を示すブロック図である。 第５の実施形態に係る利用者端末の機能を示すブロック図である。 第５の実施形態に係るＷＷＷサーバの機能を示すブロック図である。 第５の実施形態に係るＷＷＷサーバの機能を示すブロック図である。 第５の実施形態に係るデータ認証システムの動作を示す説明図である。 第６の実施形態に係る利用者端末の機能を示すブロック図である。 第６の実施形態に係る利用者端末の機能を示すブロック図である。 第６の実施形態に係るＷＷＷサーバの機能を示すブロック図である。 第６の実施形態に係るＷＷＷサーバの機能を示すブロック図である。 第６の実施形態に係るデータ認証システムの動作を示す説明図である。 第３の実施形態に係る検証部の変形例を説明するブロック図である。

符号の説明

１…利用者端末、１０１…リクエストデータ生成部、
１０２…セッションＩＤ保持部、１０３…検証データ生成部、
１０４…多重化部、２…ＷＷＷサーバ、２０１…分離部、
２０２…リクエストデータ解析部、２０３…セッション識別部、
２０４…検証部、２０５…レスポンスデータ生成部。

Claims (17)

1. サーバから提供を受けた情報を継承するためのデータを送信するデータ通信装置において、
   上記サーバに対する要求データの内容を生成する要求データ生成手段と、
   上記サーバから取得した、上記サーバが認識している当該データ通信装置に関するセッション情報を識別するためのセッション識別情報を保持するセッション識別情報保持手段と、
   今回の上記サーバに対する要求と他の要求との識別性を有する検証データを生成する検証データ生成手段と、
   上記要求データ、上記セッション識別情報及び上記検証データを多重化して上記サーバに与える通信手段と
   を備えることを特徴とするデータ通信装置。
2. 上記検証データ生成手段が、上記要求データの送信時間情報を暗号化して検証データを生成することを特徴とする請求項１に記載のデータ通信装置。
3. 上記検証データ生成手段が、上記サーバに対する要求回数を暗号化して検証データを生成することを特徴とする請求項１に記載のデータ通信装置。
4. 上記検証データ生成手段が、第１回目の要求の際に、上記サーバから取得した上記セッション識別情報を暗号化して検証データを生成し、第ｍ（ｍは２以上の整数）回目以降の要求の際に、第（ｍ−１）回目の要求の際に生成した検証データを更に暗号化して検証データを生成することを特徴とする請求項１に記載のデータ通信装置。
5. 上記検証データ生成手段が、
   乱数を生成する乱数生成部と、
   上記乱数生成部が生成した乱数に所定の一方向性関数を施した値を生成すると共に、更に生成した値に所定の一方向性関数を施していき、ｎ（ｎは1以上の整数）個の値を生成する一方向性関数適用部と、
   上記乱数生成部により生成された乱数と、上記一方向性関数により生成されたｎ個の値とを順次保持していき、先入れ後出しの順序で保持している値を検証データとして出力する検証データ出力部と
   を有することを特徴とする請求項１に記載のデータ通信装置。
6. 上記検証データ生成手段が、
   乱数を生成する乱数生成部と、
   前回送信した検証データの一方向性関数適用回数から１を引いた値を保持する回数保持部と、
   上記乱数生成部が生成した乱数に、上記回数保持部に保持されている回数分だけ所定の一方向性乱数を施した値を生成する一方向性関数適用部と、
   上記一方向性関数適用部で生成した値を検証データとして出力する検証データ出力部と
   を有することを特徴とする請求項１に記載のデータ通信装置。
7. 上記検証データ生成手段が、少なくとも上記要求データの送信時間情報に対してディジタル署名を作成した署名データを検証データとして生成することを特徴とする請求項１に記載のデータ通信装置。
8. 上記検証データ生成手段が、少なくとも上記サーバへの要求回数に対してディジタル署名を作成した署名データを検証データとして生成することを特徴とする請求項１に記載のデータ通信装置。
9. 受信した受信データに含まれる、提供情報を継承するためのデータに応じて情報を提供するサーバにおいて、
   上記受信データの要求データの内容を解析する要求データ解析手段と、
   上記受信データに含まれているセッション識別情報に基づいて要求してきたデータ通信装置のセッション情報を識別するセッション識別手段と、
   上記受信データに含まれている、今回の要求と他の要求との識別性を有する検証データを検証する検証データ検証手段と、
   上記検証データ検証手段の検証結果が正当である場合に、上記セッション識別手段の識別結果に基づく上記要求データに応じた情報を送信する通信手段と
   を備えることを特徴とするサーバ。
10. 上記検証データが上記要求データの送信時間情報を暗号化したデータである場合に、
    上記検証データ検証手段が、
    過去にアクセスしてきた各データ通信装置に係るセッション毎に、要求データの送信時間情報を保持する時間情報保持部と、
    上記検証データを暗号復号する暗号復号部と、
    上記暗号復号部により暗号復号された送信時間情報と、上記セッション識別手段の識別結果に応じた上記時間情報保持部の最新の送信時間情報とを比較して、上記検証データの正当性を判定する検証データ判定部と
    を有することを特徴とする請求項９に記載のサーバ。
11. 上記検証データがデータ通信装置からの要求回数を暗号化したデータである場合に、
    上記検証データ検証手段が、
    過去にアクセスしてきた各データ通信装置に係るセッション毎に、要求回数を保持する要求回数保持部と、
    上記検証データを暗号復号する暗号復号部と、
    上記暗号復号部により暗号復号された要求回数と、上記セッション識別手段の識別結果に応じた上記要求回数保持部の要求回数とを比較して、上記検証データの正当性を判定する検証データ判定部と
    を有することを特徴とする請求項９に記載のサーバ。
12. 上記検証データが前回の検証データを暗号化したデータである場合に、
    上記検証データ検証手段が、
    過去にアクセスしてきた各データ通信装置に係るセッション毎に、前回の検証データを保持する検証データ保持部と、
    上記検証データを暗号復号する暗号復号部と、
    上記暗号復号部の暗号復号により得た検証データと、上記セッション識別手段の識別結果に応じた上記検証データ保持部の前回の検証データとを比較して、上記検証データの正当性を判定する検証データ判定部と
    を有することを特徴とする請求項９に記載のサーバ。
13. 上記検証データが前回の検証データを暗号化したデータである場合に、
    上記検証データ検証手段が、
    過去にアクセスしてきた各データ通信装置に係るセッション毎に、前回の検証データを保持する検証データ保持部と、
    上記検証データ保持部の内容を暗号化する暗号化部と、
    上記暗号化部の暗号化により得たデータと、今回受け取った検証データとを比較して、上記検証データの正当性を判定する検証データ判定部と
    を有することを特徴とする請求項９に記載のサーバ
14. 上記検証データが乱数に一方向性関数を施すことにより得られた値である場合に、
    上記検証データ検証手段が、
    上記検証データとして最初に取得した値を登録検証データとして保持し、上記検証データの正当性が判断された場合に、上記正当性が得られた検証データを更新して登録する登録検証データ保持部と、
    上記検証データに一方向性関数を施す一方向性適用部と、
    上記一方向性適用部により得られたデータと、上記登録検証データの最新の検証データとを比較して、検証データの正当性を判定する検証データ判定部と
    を有することを特徴とする請求項９に記載のサーバ。
15. 上記検証データが、少なくとも上記要求データの送信時間情報に対してディジタル署名を作成した署名データである場合に、
    上記検証データ検証手段が、
    過去にアクセスしてきた各データ通信装置に係るセッション毎に、要求データの送信時間情報を保持する時間情報保持部と、
    上記検証データのディジタル署名を検証する署名検証部と、
    上記検証データの送信時間情報と、上記セッション識別手段の識別結果に応じた上記時間情報保持部の最新の送信時間情報とを比較して、上記検証データの正当性を判定する検証データ判定部と
    を有することを特徴とする請求項９に記載のサーバ。
16. 上記検証データが、少なくともデータ通信装置からの要求回数に対してディジタル署名を作成した署名データである場合に、
    上記検証データ検証手段が、
    過去にアクセスしてきた各データ通信装置に係るセッション毎に、要求回数を保持する要求回数保持部と、
    上記検証データのディジタル署名を検証する署名検証部と、
    上記検証データに含まれている要求回数と、上記セッション識別手段の識別結果に応じた上記要求回数保持部の要求回数とを比較して、上記検証データの正当性を判定する検証データ判定部と
    を有することを特徴とする請求項９に記載のサーバ。
17. サーバから情報の提供を受けたデータ通信装置が送信する情報を継承するデータの正当性を検証するデータ検証システムにおいて、
    上記データ通信装置が、請求項１〜請求項８のいずれかに記載のデータ通信装置であり、
    上記サーバが、上記データ通信装置から与えられる検証データの態様に応じた請求項９〜請求項１６のいずれかに記載のサーバである
    ことを特徴とするデータ検証システム。
    

Images