JP2006244081A - 認証機能付きサーバ及び方法 - Google Patents

Abstract

【課題】鍵ペアやＩＣカードなど、ユーザが認証のために用いる秘密鍵を保持した手段が盗難にあった場合でも、その不正利用を抑制できる仕組みを提供する。
【解決手段】ユーザがサーバ装置の認証ＵＲＬにアクセスすると（Ｓ１０）、サーバ装置はユーザに対し証明書を提示させる（Ｓ２０）。ユーザが自分の証明書をサーバ装置に送信すると（Ｓ１２）、サーバ装置は、その証明書からそのユーザ（主体者）のメールアドレスを求め（Ｓ２４）、本人確認用のウェブページを生成し、このページのＵＲＬを記載した本人確認メールを（Ｓ２６）、そのメールアドレス宛に送信する（Ｓ２８）。これを受け取ったユーザは、自分が認証要求を行ったのであれば、本人確認メールに示されたＵＲＬにアクセスし（Ｓ１４）、認証許可の旨を入力すればよい（Ｓ１６）。認証許可の入力がなされると、サーバ装置２０はデジタル署名によるユーザ認証を行う。
【選択図】図２

Description

本発明は、電子商取引など、ネットワークを介した通信における本人確認のための方式に関する。

電子商取引等においては「なりすまし」などのユーザの不正行為を防ぐため各種の対策が講じられている。

例えば、特許文献１には、サーバのログイン時にパスワード等によりユーザの認証を行ったあと、ログイン中に継続的にそのユーザの指紋等のバイオメトリクス情報をユーザ端末側からサーバに送ることにより、ログイン中のなりすましを防止する技術が示される。

この方式は、ユーザ固有のバイオメトリクス情報を用いるためなりすまし防止には効果的であるが、システムのコスト高を招くという問題がある。

特許文献２に示されるシステムでは、ユーザ端末は当該ユーザ端末内のハードウエア固有の情報（例えばＭＡＣアドレス）が組み込まれたデジタル証明書を認証サーバから取得し、デジタル証明書を用いて電子商取引等のセッションを行う場合に、そのデジタル証明書に組み込まれたハードウエア固有情報と、ユーザ端末内のハードウエアから取得したハードウエア固有情報とを比較し、両者が一致した場合にのみそのセッションを認めることで、ユーザが不正取得したデジタル証明書を使用することを抑制している。

しかしながら、このシステムは、ユーザが利用できる端末を限定するものであり、ユーザに不便を強いる。

公開鍵基盤（ＰＫＩ）を利用した本人確認・ユーザ認証の仕組みとしては、上の特許文献２にも示したようにデジタル署名が広く利用されている。デジタル署名を用いたユーザ認証は、ユーザ端末に保存された鍵ペアやデジタル（公開鍵）証明書や、ユーザが携帯するＩＣカードに保持された秘密鍵とデジタル証明書を用いて行われる。このユーザ認証方式は適切に運用されていれば有効性が高いが、鍵ペアのファイルやＩＣカードが盗難などにより第三者の手に渡ってしまうと、不正利用が容易になされてしまうという問題がある。

特開２００４−０１３８３１号公報 特開２００３−１８８８７３号公報

本発明は、鍵ペアやＩＣカードなど、ユーザが認証のために用いる秘密鍵を保持した手段が盗難にあった場合でも、その不正利用を抑制できる仕組みを提供することを目的とする。

本発明では、ユーザの秘密鍵によるデジタル署名が施された認証データの署名を検証することによりユーザ認証を行う認証機能付きサーバにおいて、クライアント装置からユーザ認証要求を受けた場合に、そのユーザのメールアドレスに対して、本人確認のための電子メールである本人確認メールを送る。そして、その本人確認メールに応じて、ユーザから認証機能付きサーバに対し本人であることの確認の入力がなければ、ユーザ認証を失敗とする。すなわち、本人確認メールに対する本人の旨の確認の入力がなければ、認証データのデジタル署名が正当であるか否かに依らず、ユーザ認証を失敗とするのである。

ユーザの鍵ペアのデータや、ユーザの秘密鍵を内蔵したＩＣカード等のトークンを第三者が入手し、そのデータやトークンを用いてそのユーザ本人になりすまそうとした場合、デジタル署名に基づくユーザ認証だけでは認証が成功し、その第三者からのアクセスが正当なユーザからのアクセスと判断されてしまう。これに対し、本発明では、その正当なユーザのメールアドレスに本人確認メールを送り、それに対するユーザの確認が得られない場合にはユーザ認証失敗と判断するので、そのような不正利用を抑制できる。また、不正利用が試みられた場合、正当なユーザは認証機能付きサーバに対する身に覚えのないアクセスに対して本人確認メールを受け取るので、そのような不正が行われていることを知ることができる。

以下、図面を参照して、本発明を実施するための最良の形態（以下「実施形態」と呼ぶ）について説明する。

図１は、本発明が適用されたシステムの一実施形態を示す機能ブロック図である。

クライアントＰＣ１０は、ユーザが操作するコンピュータ装置であり、ユーザの公開鍵証明書（以下、単に証明書と呼ぶ）とこれに対応する秘密鍵とを登録した証明書ＤＢ（データベース）１２を有する。ＰＫＩ処理部１４は、それら証明書や秘密鍵を用いて、ＰＫＩ（公開鍵基盤）でのセキュリティのための処理を実行する機能モジュールである。この種の処理には、デジタル署名やその署名検証、データの暗号化、復号などがあるが、ＰＫＩ処理部１４は必ずしもその全てを実行するものでなくてもよい。ＰＫＩ処理部１４としては、例えば、ＳＳＬ(Secure Socket Layer)やＳ／ＭＩＭＥ(Secure Multipurpose Internet Mail Extension)などのプロトコルを例示することができるが、これに限られるものではない。クライアントＰＣ１０上のアプリケーションは、ＰＫＩ処理部１４を利用することで、インターネット等のネットワーク３０を介した装置（例えばサーバ装置２０）との通信において、なりすましや盗聴などの脅威に対処することができる。クライアントＰＣ１０で用いられるアプリケーションとして、図には電子メールの送受信を行うメールクライアント１６や、ＨＴＴＰ(HyperText Transfer Protocol)を利用した処理を行うウェブクライアント（例えばウェブブラウザ）１８を例示したが、これに限られるわけではない。

サーバ装置２０は、ネットワーク３０を介してクライアントＰＣ１０に対して所定のサービスを提供するコンピュータ装置である。サーバ装置２０が提供するサービスの１つの典型例は、図示したウェブサーバ２４によるウェブページやウェブアプリケーションの提供であるが、この他にもＦＴＰ(File Transfet Protocol)に依るファイル転送サービスなど様々な種類のサービスがある。本実施形態におけるサーバ装置２０の１つの特徴は、ユーザ（クライアント）認証における機能・処理内容（詳細は後述）にあり、この特徴は、サーバ装置２０がクライアントＰＣ１０のアプリケーションに対して提供するサービスの種類には基本的には依存しない。

サーバ装置２０の鍵ペア管理部２１には、そのサーバ装置２０自身の公開鍵と秘密鍵のペアが保存されている。公開鍵の代わりに、その公開鍵を含んだ公開鍵証明書を保存していてもよい。ＰＫＩ処理部２２は、クライアントＰＣ１０のＰＫＩ処理部１４と同様、ＰＫＩのための処理を実行する。

ウェブサーバ２４は、クライアントＰＣ１０に対しウェブページを提供するサーバである。このウェブページをユーザインタフェース（ＵＩ）としてユーザから指示を受け取り、その指示に対応するサービスを、ＣＧＩ(Common Gateway Interface)技術などにより提供することができる。そのサービスの処理の本体を実行するのが、サービス処理部２７である。サービス処理部２７がユーザに提供するサービスの内容自体は、本発明の本質とは基本的に関係がないので、説明は省略する。

メールサーバ２３は、本人確認メール（詳細は後述）をユーザ宛に送信するのに用いられる。

証明書アドレス解釈部２５は、クライアントＰＣ１０から送られてきた証明書から、その証明書の主体者であるユーザの電子メールアドレスを読み取る。

本人確認メール処理部２６は、ユーザからのユーザ認証要求に対して、その要求がそのユーザ本人のものか否かを確認する本人確認メールをそのユーザのメールアドレスに送り、そのメールをトリガとする本人確認のための処理を実行する。本人確認の処理の具体例については後述する。

図２は、このシステムにおけるユーザ認証処理の流れを示す図である。ここでは、ＳＳＬでのクライアント認証を例にとって説明する。

この処理では、まずクライアント装置１０のウェブクライアント１８が、ユーザの操作に応じて、サーバ装置２０のウェブサーバ２４が有する、クライアント認証を必要とするウェブページのＵＲＬにアクセスする（Ｓ１０）。このアクセスはＨＴＴＰＳを用いて行われる。

アクセスを受けたウェブサーバ２４は、ＰＫＩ処理部２２のプロトコルを用いて、ウェブクライアント１８に対して認証データを要求する（Ｓ２０）。このように、ウェブサーバ２４が必要とする認証に関する処理は、ＰＫＩ処理部２２により行われるのであるが、以下では煩雑さを避けるため、このような場合でも単に「ウェブサーバ２４が・・・を行う」と記載する場合もある。ウェブクライアント１８についても同様である。

Ｓ２０で要求する認証データは、ユーザの証明書と、Ｓ２０の要求の際にウェブクライアント１８に送ったメッセージ（Helloメッセージ）に対するユーザのデジタル署名である。証明書ＤＢ１２に当該ユーザの証明書が複数登録されていることを考慮する場合には、それら証明書の一覧を画面表示してその中から使用するものをユーザに選択させるようにしてもよい。この場合、その選択のためのＵＩとなるウェブページをＳ２０で提供する。なお、ユーザのＩＣカードを用いる場合は、クライアントＰＣ１０のカードリーダによりＩＣカードを読み取り、その中のユーザの証明書が証明書ＤＢ１２にコピーされ、証明書の一覧の中に表示されることになる。

認証データの要求を受け取ったウェブクライアント１８は、Ｓ２０で受け取ったHelloメッセージに対してそのユーザの秘密鍵によりデジタル署名を施すようＰＫＩ処理部１４に要求し、この要求に対してＰＫＩ処理部１４が返した署名済みのメッセージと、証明書ＤＢ１８から取り出した当該ユーザの証明書とを認証データとしてウェブサーバ２４に送信する（Ｓ１２）。

なお、ウェブサーバ２４から証明書指定のためのウェブページが提供された場合は、Ｓ１２ではウェブクライアント１８はそのウェブページをクライアントＰＣ１０の画面に表示する。このウェブページには、証明書ＤＢ１２に保持されている証明書の一覧を表示してその中からユーザの選択を受けるための入力手段が、例えばＪａｖａ（商標）スクリプトなどにより組み込まれており、ユーザはこの入力手段により自分の使用する証明書を選択する。すると、ＰＫＩ処理部１４が、選択された証明書に対応する秘密鍵により上述のHelloメッセージに署名を施し、ウェブクライアント１８はその署名済みのメッセージと、選択された証明書とを認証データとしてウェブサーバ２４に送信する（Ｓ１２）。

さて、従来のＳＳＬの認証セッションでは、ウェブサーバ２４は、この認証データに含まれるメッセージに付されたデジタル署名を、同じくその認証データに含まれる公開鍵証明書中の公開鍵を用いて検証することで、ユーザ認証を行っていたが、本実施形態では、署名検証に入る前に、認証要求元のユーザのメールアドレスに本人確認メールを送って本人確認を行う。この処理がＳ２４からＳ２８のステップである。なお、前述したＳ１０→Ｓ２０→Ｓ１２のＨＴＴＰＳのセッションは、デジタル署名ベースの認証処理のセッションの前半部に当たる。

Ｓ２４〜Ｓ２８の処理は、ＰＫＩ処理部２２からの依頼に応じて、本人確認メール処理部２６が実行する。以下、詳細に説明する。

Ｓ２４では、証明書アドレス解釈部２５が、ウェブクライアント１８から取得した証明書から当該ユーザのメールアドレスを取得する。通常、証明書のサブジェクト（主体者）フィールド、又はRFC3280(RFC2459の新版)の拡張プロファイルにおけるサブジェクト別名フィールドに、ユーザ（主体者）のメールアドレスが記載されているので、Ｓ２４ではそのメールアドレスを読み出すのである。

Ｓ２６では、そのメールアドレスに送る本人確認メールと、本人確認処理に用いるウェブページ（本人確認ページと呼ぶ）とを作成する。

ここで、本人確認ページのアドレス（ＵＲＬ）は、ユーザからの認証要求（Ｓ１０）の都度、動的に生成する一時的なものである。これは、不正を目論む者が本人確認ページのＵＲＬを知ったり、推測したりすることを極力防ぐためである。例えば、本人確認ページのＵＲＬを、ウェブサーバ２４が管理するアドレスの中の所定の範囲の中でランダムに決定する等すればよい。本人確認ページの内容は、本人確認メールを受け取ったユーザが、Ｓ１０の認証要求が確かに自分の出したものであることを入力できるようなものであればよく、例えば、「認証要求が行われました。許可しますか？」と言うメッセージと、許可の旨の意思表示を示すＧＵＩ（グラフィカルユーザインタフェース）ボタンと不許可の旨の意思表示を示すＧＵＩボタンとを表示したものでよい。

作成する本人確認メールは、Ｓ２４で求めたメールアドレスを宛先とし、本文等にこの本人確認ページのＵＲＬが記述される。もちろん、「下記ＵＲＬにアクセスして本人確認を行ってください。」などと言ったメッセージを含んでいてもよい。このメールを受け取ったユーザは、メールクライアント１６によるこのメールの表示画面に示された本人確認ページのＵＲＬをクリックするなどの操作で、本人確認ページにアクセスし、認証要求に対する許可、不許可の意思表示を行うことができる。なお、本人確認ページの作成処理とメールアドレスの取得処理の実行順序は例示のものに限られない。

このようにして本人確認ページ及び本人確認メールが作成できると、本人確認メールをメールサーバ２３に渡し、送信させる（Ｓ２８）。

なお、本人確認メールの処理（Ｓ２４〜Ｓ２８）を行う際に、ウェブサーバ２４は、クライアントＰＣ１０のウェブクライアント１８に対し、本人確認メールによる確認作業を行う旨の説明と、デジタル署名を用いた認証処理の開始を指示するＧＵＩボタン（「認証ボタン」と呼ぶ）とを含んだ認証指示用のウェブページを送信する（Ｓ２２）。このページに表示するメッセージは、例えば「本人確認のためにメールを送信しました。メールを受信して確認処理を行った後、『認証』ボタンを押してください。」等である。これにより、ウェブクライアント１８を操作するユーザに、現在の認証処理の進行状況を知らせるとともに、ユーザに対し本人確認メールに対する確認作業を促すことができる。

本人確認メールを受信した場合、ユーザはメールクライアント１６によりそのメールを閲覧し、そこに示されたＵＲＬにアクセスする（Ｓ１４）。これに応じ、サーバ装置２０のウェブサーバ２４がそのＵＲＬに対応する本人確認ページをウェブクライアント１８に送信すると（Ｓ３０）、ウェブクライアント１８がその本人確認ページを画面表示する。ユーザは、本人確認ページに示されたメッセージで言及されている認証要求が自分の発行したものだと判断した場合は、そのページに示される「認証許可」ボタンを押下する。一方、自分の発行した認証要求でない場合は、ユーザは「不許可」ボタンを押下すればよい。「認証許可」ボタン又は「不許可」ボタンが押下された場合、ウェブクライアント１８は押下されたボタンを示す情報をウェブサーバ２４に送信する（Ｓ１６）。なお、以上に説明したこの本人確認のためのセッションＳ１４，Ｓ３０，Ｓ１６，Ｓ３２を、サーバ認証によるＨＴＴＰＳのセッションとすることでより安全性を向上させることができる。

本人確認ページに対するユーザの入力を受け取ったウェブサーバ２４は、その入力が「不許可」であれば、当該認証要求に関するユーザ認証を失敗、すなわち認証を要求した者は正当なユーザではないと判定し（Ｓ３２）、認証失敗の旨のメッセージを示したウェブページをウェブクライアント１８に返し、認証要求に対する処理を終了する。一方、本人確認ページ対するユーザの入力が「許可」であれば、図示の認証セッションの後半部に進む（Ｓ３２）。なお、「許可」の場合、「認証指示用ページの『認証』ボタンをクリックしてください」などと言ったメッセージを示したウェブページをウェブクライアント１８に提供し、ユーザに認証セッションの続行を促すようにしてもよい。

認証セッションの後半部では、ユーザは、認証指示用ページに示される『認証』ボタンを押下すると（Ｓ１８）、その旨がウェブクライアント１８からウェブサーバ２４に伝えられ、ＰＫＩ処理部２２は、それまで中断していたＳＳＬのクライアント認証処理を再開し（Ｓ３４）、Ｓ１２で受け取った認証データに含まれるユーザのデジタル署名を、そのユーザの公開鍵証明書に含まれる公開鍵で検証する。そして、その検証により、そのデジタル署名がそのユーザのものと判明した場合はユーザ認証を成功とし、その旨をウェブサーバ２４に伝える。この場合、ユーザ認証が成功したので、サービス処理部２７によるサービスがユーザ側に提供される。一方、デジタル署名がそのユーザのものでないと判明した場合は、ユーザ認証を失敗とし、その旨を示したウェブページをウェブクライアント１８に送信する。

なお、Ｓ２２で提供された認証指示用ページ上の認証ボタンが、ユーザがＳ１６で本人確認メールに対して認証許可の回答をする前に押下された場合、ウェブサーバ２４は、ユーザ認証を失敗とするか、或いはその認証ボタンの押下を無視し、本人確認メールに基づく確認作業を再度促すウェブページをウェブクライアント１８に提供すればよい。

また、図２の手順では、デジタル署名に基づく認証セッション処理の続行を指示するための認証ボタンを含んだ認証指示用ページを、本人確認メールをトリガとした本人確認処理の前にユーザ側に送信した（Ｓ２２）。この代わりに、例えば本人確認セッションのＳ３２で本人であるとの確認がなされた場合に、そのような認証ボタンを含んだ認証指示用ページをユーザ側に送信するようにしてもよい。

また、図２の手順では、Ｓ２０でウェブサーバ２４がHelloメッセージをウェブクライアント１８に送信し、Ｓ１２でユーザの証明書とユーザ署名済みのHelloメッセージをウェブクライアント１８からウェブサーバ２４に返した。しかし、認証処理の流れはこれに限らない。例えば、この代わりに、Ｓ２０及びＳ１２では単に証明書の要求とそれに対するサーバへの証明書の提出のみを行い、Ｓ３２で本人であるとの確認がなされた場合に、Ｓ３４でサーバ側からHelloメッセージを提供し、クライアント側がそれに対し署名を施して返信して認証を受けるという流れにしてもよい。

また、図２の手順では、本人確認ページに対してユーザ本人から「認証許可」の旨の入力がなされた後、サーバ装置２０はクライアントＰＣ１０側から提出されたデジタル署名の検証を行ったが、このような流れは必須ではない。この代わりに、本人確認メール及びページによる本人確認処理と並行してデジタル署名の検証を済ませ、その検証が成功しても、即座にユーザ認証が成功とは判定せずに、保留状態として記憶しておく。そして、本人確認ページに対して「認証許可」の旨がユーザから入力されると、保留状態であったユーザ認証結果を有効にし、認証成功と判定する。なお、デジタル署名の検証が失敗したら、本人確認ページへの入力を待たずに、認証失敗と判定する。このような処理の流れで、図２の手順と同様の効果を得ることができる。

次に図３及び図４を参照して、本実施形態の効果について説明する。

まず、正当なユーザがユーザ認証を受けようとした場合について、図３を参照して説明する。

この場合、正当なユーザＡが、自分の証明書１２０及び秘密鍵１２２がインストールされたクライアントＰＣ１０からサーバ装置２０に対し、（１）自分の証明書（及び秘密鍵）でのユーザ認証を受けようとすると、（２）サーバ装置２０がその証明書に示されたメールアドレスに本人確認メールが送信される。この場合、正当なユーザＡのメールアドレスに本人確認メールが届けられるので、ユーザＡは、メールクライアント１６によりそのメールを閲覧し、（３）そのメールに示された本人確認ページのＵＲＬにアクセスして本人確認を行う。すると、この本人確認の後、（４）サーバ装置２０により証明書とデジタル署名によるユーザ認証が行われ、この場合ユーザＡは正しく自分の証明書及び秘密鍵を用いているので、ユーザ認証は成功する。

なお、サーバ装置２０は、自分の証明書２２０及び秘密鍵２２２を有しており、必要に応じ、クライアントＰＣ１０との間でこれらを用いて通信を行うことができる。

次に、ユーザＡの証明書１２０及び秘密鍵１２２を入手したユーザＢが、それらを不正利用してユーザＡになりすまそうとした場合について、図４を参照して説明する。

この場合、（１）不正なユーザＢがユーザＡの証明書をサーバ装置２０に提示して認証を受けようとすると、（２）その証明書に示されたユーザＡのメールアドレスに対して本人確認メールを送る。これにより、（３）正当なユーザＡは、自分の証明書等が不正使用されていることを知ることができる。また、この場合、その本人確認メールから本人確認ページにアクセスして「不許可」ボタンを押下することで、不正なユーザＢのユーザ認証を阻止できる。なお、サーバ装置２０は、本人確認ページに対してユーザが「認証許可」の旨を入力しない限り、証明書を用いたユーザ認証を成功にしないので、仮に正当なユーザＡが本人確認メールの到来に気づかなかったり、あるいは気づいても本人確認ページで「不許可」ボタンを押さなかったりしても、ユーザＢがユーザＡとして認証されてしまうことはない。

以上に説明した実施形態は、ユーザが本人確認メールに示された本人確認ページにアクセスして確認を行っていたが、この代わりに、本人確認メールに対する返信メールにより「認証許可」の意思表示を行えるようにしてもよい。すなわち、本人確認メールを受け取ったユーザは、認証処理を許可する場合には、メールクライアント１６により本人確認メールに対して返信を行う。サーバ装置２０は、本人確認メールに対する返信メールを受け取ったら、認証処理が許可されたものと判断し、デジタル署名に基づく認証処理を行う。この方式によれば、ユーザの操作するクライアントがウェブブラウザを備えない場合でも、本人確認を行うことができる。

また、上記実施形態では、証明書を用いたユーザ認証を必要とするクライアントアプリケーション（図１の例ではウェブクライアント１８）と、本人確認メールを受け取るメールクライアント１６とが、同一のクライアントＰＣ１０に組み込まれていたが、これは必須のことではない。例えば、図５に示す例では、証明書ベースの認証を必要とするクライアント装置としてデジタル複合機４０を、本人確認メールを受け取るメールクライアントとして携帯メール端末４５（例えば携帯電話機）を用いている。デジタル複合機４０は、プリンタ、スキャナ、コピー機の機能を併せ持った装置であり、ＬＡＮ、インターネット等のネットワークを介してサーバ装置２０に接続される。この例は、ユーザＡが複合機４０を介してサーバ装置２０のサービスを受ける場合のものである。例えば、複合機４０でスキャンした文書のデータを、文書サーバであるサーバ装置２０に登録する等の場合など、複合機４０からネットワーク上の各種サーバを利用することは、今後益々増えてくると予想される。図５のシステムでは、ユーザＡが自分の証明書１２０と秘密鍵１２２を保持したＩＣカード５０を複合機４０のカードリーダにセットし、複合機４０のＵＩ画面からサーバ装置２０のサービスを利用する旨を指示すると、（１）複合機４０にインストールされたＰＫＩ処理用のプロトコルが、ＩＣカード５０から読み出したユーザＡの証明書を用いてサーバ装置２０にアクセスし、ユーザ認証を受けようとする。すると、サーバ装置２０は、（２）その証明書からユーザＡのメールアドレスを取得し、そのアドレス宛に本人確認メールを送る。ユーザＡは、自分の携帯メール端末４５により本人確認メールを受信し、（３）そこに示されたＵＲＬにより本人確認ページにアクセスし、本人確認を行う。すると、（４）サーバ装置２０により証明書とデジタル署名によるユーザ認証が行われ、この場合ユーザＡは正しく自分の証明書及び秘密鍵を用いているので、ユーザ認証は成功する。なお、ステップ（３）の本人確認は、本人確認ページを用いる代わりに、本人確認メールに対する返信メールを以て行ってもよい。

また、図５の例では、ユーザＡの携帯メール端末４５からサーバ装置２０へアクセスして本人確認を行っていたが、この代わりに、例えば、携帯メール端末４５から複合機４０に本人確認メールの情報を受け渡し、複合機４０からサーバ装置２０へアクセスして本人確認処理を行うこともできる。すなわち、例えば、本人確認メールにＱＲコード（登録商標）やバーコードなどのような所定のコード方式で表現した本人確認用コード画像を組み込んでおく。本人確認用コード画像は、例えば、ユーザが本人確認をした旨を示す所定のコード（このコードは、サーバ装置２０が知っていればよい）を表現していればよい。本人確認メールは、例えば、この本人確認用コード画像と、「認証要求が行われました。許可される場合は、添付のコード画像を画面に表示し、複合機の原稿読取部の矢印の位置に画面を下に向けて置いて、スタートボタンを押してください」などと言った操作案内のメッセージを含む。この本人確認メールを受け取ったユーザは、そのメッセージに従って本人確認用コード画像を携帯メール端末４５の表示画面に表示させ、その表示画面を複合機４０のプラテンの所定位置にかざして読み取らせる。この操作が行われる時点では、複合機４０は、その前のステップ（１）（図５参照）でのユーザ認証要求に対する処理待ち状態にあるので、スタートボタンの押下を本人確認用コード画像の読取の指示と判断し、スキャンした画像の所定位置からコード画像を認識し、そのコード内容を識別してサーバ装置２０に送信する。サーバ装置２０は、そのコードを受け取ったことを以て、ユーザが本人確認を行ったものと判定する。この方式では、ユーザが本人確認メールに含まれるコード情報を複合機４０に読み取らせたという操作を以て、ユーザの本人確認とするわけである。

また、図２に示した処理手順は、ＳＳＬベースの認証セッションを途中で中断し、本人確認セッション（Ｓ１４，Ｓ３０，Ｓ１６，Ｓ３２）で本人確認が成功したら認証セッションを再開するという手順であったが、このような手順は一例に過ぎない。この代わりに、例えば図６に示すような手順も可能である。

図６の手順では、クライアントＰＣ１０が、ユーザの操作に応じて、サーバ装置２０の認証用の窓口ウェブページのＵＲＬにＨＴＴＰＳでアクセスする（Ｓ１１０）。すると、サーバ装置２０は、クライアントＰＣ１０に対して、ユーザの証明書の入力のためのＵＩとなるウェブページを提供する（Ｓ１２０）。クライアントＰＣ１０にて、ユーザがこのウェブページに対し自分の使用する証明書を選択して入力すると、その証明書がサーバ装置２０に送られる（Ｓ１１２）。これを受け取ったサーバ装置２０は、「認証のためにメールを送信しました。メールを受信して認証処理及びこの後の処理を行ってください。」等と言った操作案内用のメッセージを示した説明用ウェブページをクライアントＰＣ１０に送信する一方（Ｓ１２２）、本人確認メールの送信処理（Ｓ１２４〜Ｓ１２８）を行う。

すなわち、サーバ装置２０は、クライアントＰＣ１０から取得したユーザの証明書からそのユーザのメールアドレスを取得し（Ｓ１２４）、そのユーザ向けのＳＳＬクライアント認証用のウェブページを生成する（Ｓ１２６）。ＳＳＬクライアント認証用のウェブページのＵＲＬは、プロトコルとしてＨＴＴＰＳを用いるものであり、前述の本人確認ページのＵＲＬと同様、ユーザからの窓口ＵＲＬへのアクセスに応じて動的に生成することで、不正利用のリスクを低減することができる。そして、そのクライアント認証用ページのＵＲＬを含んだ本人確認メールを作成し（Ｓ１２６）、そのユーザのメールアドレス宛に送信する（Ｓ１２８）。本人確認メールには、そのＵＲＬの他に、「あなたから認証要求を受けました。認証を受けて処理を進めたい場合は、下記ＵＲＬにアクセスしてください。」などの操作説明のメッセージを含めておいてもよい。

この本人確認メールを受け取ったユーザは、その本人確認メールが自分の認証要求に応じたものであると分かれば、クライアントＰＣ１０（本人確認メールを受け取った別の端末でもよい）からそのメールに示されたＵＲＬにアクセスする（Ｓ１１４）。すると、サーバ装置２０は、従来から周知のＳＳＬクライアント認証処理を実行する（Ｓ１３０）。このクライアント認証では、サーバ装置２０はユーザに証明書の提示を求め、この証明書とそれに対応する秘密鍵によるデジタル署名付きのデータを受け取ってその署名を検証する。Ｓ１３０のＳＳＬクライアント認証が成功すると、クライアントＰＣ１０（ウェブクライアント１８）とサーバ装置２０（ウェブサーバ２４）との間に認証セッションを張り、以降その認証セッション下で、ユーザに対し、サービス処理部２７によるサービスを提供する。

このように、図６の手順では、本人確認メールに示されたクライアント認証用ＵＲＬへアクセスがなされたことを以て、ユーザの本人確認としている。この処理手順によれば、仮に第三者がユーザになりすまそうとしても、そのユーザは本人確認メールによりそのような不正アクセスの試みがなされていることを認知することができる。また、このような不正を試みた第三者には、実際にサーバ装置２０のサービスを受けるのに必要なＳＳＬクライアント認証用のページのＵＲＬが知らされないので、不正利用を防止することができる。

以上に説明した実施形態では、サーバ装置２０は、認証要求を行ったユーザのメールアドレスとして、そのユーザが提示した証明書から求めたメールアドレスを用いたが、ユーザによっては、証明書に記載されたアドレスとは違うアドレスに本人確認メールの送付を希望する者もあり得る。そのような希望に沿うための変形例として次のような者が考えられる。すなわちこの変形例では、サーバ装置２０に、各ユーザごとに、証明書に記載されたメールアドレスと、本人確認メールの送付先として希望するメールアドレスとを対応づけたテーブルを登録しておく。そして、サーバ装置２０は、ユーザから受け取った証明書から主体者のメールアドレスを求め、そのテーブルに、そのメールアドレスに対応する本人確認メールの送付先アドレスが登録されていれば、その送付先アドレスに対して本人確認メールを送信する。

また以上の例では、ユーザに証明書を提示させ、この証明書から本人確認メールを送信する宛先のメールアドレスを求めたが、これは必須のことではない。この代わりに、次のようなシステムを用いてもよい。すなわち、このシステムでは、サーバ装置２０にあらかじめ各ユーザのメールアドレスと、パスワードやバイオメトリクス情報等の認証情報を登録しておく。そして、ユーザがサーバ装置２０に自分の証明書を提示する代わりに、サーバ２０にアクセスし、パスワード等の認証情報による認証を受ける。この認証が成功すると、サーバ装置２０は、そのユーザのメールアドレス（これはサーバ装置２０に登録されている）に対して本人確認メールを送る。この本人確認メールには、図６の手順の場合と同様、ＳＳＬクライアント認証用のページのＵＲＬを組み込んでおけばよい。以降の処理は、図６の手順と同様でよい。

以上では、ＳＳＬ認証を例にとって説明したが、本実施形態の方式は、これだけでなく、ＰＫＩの枠組みでの証明書とデジタル署名を用いたユーザ認証一般に利用可能である。

本発明が適用されたシステムの一実施形態を示す機能ブロック図である。 実施形態のシステムにおけるユーザ認証処理の流れを示す図である。 正当なユーザがユーザ認証を受けようとした場合の実施形態のシステムの動作を示す図である。 不正なユーザがユーザ認証を受けようとした場合の実施形態のシステムの動作を示す図である。 本人確認メールをユーザの携帯メール端末に送信する場合のシステム構成を説明するための図である。 ユーザ認証処理の変形例の流れを示す図である。

符号の説明

１０ クライアントＰＣ、１２ 証明書ＤＢ、１４ ＰＫＩ処理部、１６ メールクライアント、１８ ウェブクライアント、２０ サーバ装置、２１ 鍵ペア管理部、２２ ＰＫＩ処理部、２３ メールサーバ、２４ ウェブサーバ、２５ 証明書アドレス解釈部、２６ 本人確認メール処理部、２７ サービス処理部。

Claims (7)

1. ネットワークを介してクライアント装置からユーザ認証要求を受け取ると共に、ユーザの秘密鍵によるデジタル署名が施された認証データをクライアント装置からそのユーザ認証要求に対応づけて受け取り、その認証データのデジタル署名を検証することでそのユーザ認証要求に対するユーザ認証を実行する認証機能付きサーバであって、
   クライアント装置からユーザ認証要求を受け取った場合に、当該ユーザのメールアドレスに対し、そのユーザ認証要求が当該ユーザ本人のものか否かの入力を促す本人確認メールを送信する確認メール送信手段と、
   送信した前記本人確認メールに対して、前記ユーザ認証要求が前記ユーザ本人のものである旨を示す入力が前記ユーザから得られない場合は、前記認証データに施されたデジタル署名が正当であるか否かに依らず、ユーザ認証を失敗とする認証制御手段と、
   を備える認証機能付きサーバ。
2. 前記確認メール送信手段は、前記ユーザ認証要求が当該ユーザ本人のものか否かを入力するための確認用ウェブページのアドレス情報を含んだ本人確認メールを生成して前記ユーザのメールアドレスに送信し、
   前記認証制御手段は、前記確認用ウェブページに対する前記ユーザの入力から前記ユーザ認証要求が前記ユーザ本人のものか否かを判定する、
   ことを特徴とする請求項１記載の認証機能付きサーバ。
3. 前記ユーザ認証要求を受け取った場合に、当該ユーザ認証要求に対する専用の前記確認用ウェブページを生成する確認用ウェブページ生成手段、
   を更に備え、
   前記確認用メール送信手段は、前記確認用ウェブページ生成手段が生成した前記確認用ウェブページのアドレス情報を含んだ本人確認メールを生成する、
   ことを特徴とする請求項２記載の認証機能付きサーバ。
4. 前記認証手段は、前記本人確認メールに対する前記ユーザからの返信メールに基づき、前記ユーザ認証要求が前記ユーザ本人のものであるか否かを判定する、ことを特徴とする請求項１記載の認証機能付きサーバ。
5. 前記ユーザ認証要求は、当該ユーザの公開鍵証明書のデータを含んでおり、
   前記確認メール送信手段は、前記公開鍵証明書から前記ユーザのメールアドレスを取得する、
   ことを特徴とする請求項１記載の認証機能付きサーバ。
6. ネットワークを介してクライアント装置からサーバ装置へ、ユーザ認証要求と、ユーザの秘密鍵によるデジタル署名が施された認証データとを送信し、サーバ装置がその認証データのデジタル署名を検証することでそのユーザ認証要求に対するユーザ認証を実行する、ユーザ認証方法であって、
   サーバ装置が、クライアント装置からユーザ認証要求を受け取った場合に、当該ユーザのメールアドレスに対し、そのユーザ認証要求が当該ユーザ本人のものか否かの入力を促す本人確認メールを送信するステップと、
   送信した前記本人確認メールに対して、前記ユーザ認証要求が前記ユーザ本人のものである旨を示す入力が前記ユーザから得られない場合は、サーバ装置が、前記認証データに施されたデジタル署名が正当であるか否かに依らず、ユーザ認証を失敗とするステップと、
   を有するユーザ認証方法。
7. ネットワークを介してクライアント装置からユーザ認証要求を受け取ると共に、ユーザの秘密鍵によるデジタル署名が施された認証データをクライアント装置からそのユーザ認証要求に対応づけて受け取り、その認証データのデジタル署名を検証することでそのユーザ認証要求に対するユーザ認証を実行する認証機能付きサーバ、としてコンピュータを機能させるためのプログラムであって、該コンピュータを、
   クライアント装置からユーザ認証要求を受け取った場合に、当該ユーザのメールアドレスに対し、そのユーザ認証要求が当該ユーザ本人のものか否かの入力を促す本人確認メールを送信する確認メール送信手段、
   送信した前記本人確認メールに対して、前記ユーザ認証要求が前記ユーザ本人のものである旨を示す入力が前記ユーザから得られない場合は、前記認証データに施されたデジタル署名が正当であるか否かに依らず、ユーザ認証を失敗とする認証制御手段、
   として機能させるためのプログラム。

Images