JP3872616B2 - 共有鍵暗号型のｉｃカードによるインターネット上のユーザー認証方式 - Google Patents
共有鍵暗号型のｉｃカードによるインターネット上のユーザー認証方式 Download PDFInfo
- Publication number
- JP3872616B2 JP3872616B2 JP24215399A JP24215399A JP3872616B2 JP 3872616 B2 JP3872616 B2 JP 3872616B2 JP 24215399 A JP24215399 A JP 24215399A JP 24215399 A JP24215399 A JP 24215399A JP 3872616 B2 JP3872616 B2 JP 3872616B2
- Authority
- JP
- Japan
- Prior art keywords
- authentication
- user
- server
- card
- encryption
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は、共有鍵暗号型のＩＣカード（スマートカード）を使用したユーザー認証システムの実現手段に関して、１枚のＩＣカードでインターネット上の広域的に分散したサーバー郡における安全なユーザー認証を実現する手段に関するものである。
【０００２】
【従来の技術】
従来のコンピュータシステムにおけるユーザー認証は、各サーバーのシステム管理者がそのユーザーをサーバーごとに登録することによって実現されていた。しかしインターネットでは、ユーザーの方が世界中にあるアプリケーションサーバーを選択して接続し、電子決済などのセキュリティが必要なサービスを要求する。また一つの組織内でも多数のサーバーが稼働するようになったため、サーバーごとにユーザー管理を行なう方法は現実的でなくなってきた。このめ、Ｘ．５０９公開鍵認証基盤に代表されるような広域的なユーザー認証手段が必要となっている。
【０００３】
インターネット上の広域的なユーザー認証は、インターネットを使った電子商取引の安全性確保や遠隔医療やワンストップ行政サービスなどにおけるプライバシー保護やデジタルコンテンツの著作権保護など多くの場面で必須のものになってきている。
【０００４】
広域的な認証基盤として、公開鍵暗号を利用する公開鍵証明書に基づくシステムが存在している。しかし公開鍵暗号は共有鍵暗号系に比べると計算量が非常に大きいために、性能や容量の点でＩＣカードとして実現することが困難でありコスト的に問題がある。フロッピーなどで公開鍵暗号の秘密鍵やデジタル証明書を配付する方法もあるが、運用や管理が困難であることがわかっている。
【０００５】
従来技術の技術的問題点について述べる前に、まず前提条件として共有鍵暗号に基づく一般的なチャレンジアンドレスポンスによる認証プロトコルについて述べておく。
データ−Ｍを暗号鍵Ｋによって暗号化した結果を［Ｍ］Kと書くことにする。また暗号化されたデータ−Ｘを暗号鍵Ｋで復号化した結果を｛Ｘ｝Kと書くことにする。
【０００６】
図７に示すように、Ａが通信の相手Ｂに対して本人認証を行なうときに次のような処理を行なう。
０．前提、ＡとＢは同じ暗号鍵Ｋを持っている。このＫはＢを確認するための鍵である。
１．Ａは、新しい乱数Ｒを生成して通信路を経由してＢに送る。
２．Ｂは、Ａから送られた乱数Ｒを自分の暗号鍵Ｋで暗号文を作り、Ａに送り返す。
３．ＡはＢから送られた［Ｒ］Kを暗号鍵Ｋで復号化し｛［Ｒ］K｝Kを計算し、これがＲと一致すれば、ともに同じ暗号鍵Ｋを所持していることが確認できるので認証が成功したものとする。また一致しなければ認証が失敗する。
【０００７】
ＩＳＯ７８１６などの一般的に普及しているＩＣカードの標準規格では、乱数の生成やチャレンジアンドレスポンスをＩＣカードから相手へ（外部認証）とサービス側からＩＣカードへ（内部認証）の機能を備えている。本発明では、このような機能を持ったＩＣカードの利用を前提とする。
【０００８】
本方式を実現する上で生ずる問題を以下に列挙する。
・認証用暗号鍵の分散の問題
ＤＥＳなどの共有鍵型の暗号によるＩＣカードを用いた認証システムは、アプリケーシヨンサーバー側とユーザーのＩＣカードが同じ暗号鍵を持ち、安全に管理する必要があるため、通常は特定のアプリケーションサーバーのユーザー認証に限定したクローズドシステムとして運用される。インターネットのような広域的な認証システムでは、アプリケーションサーバーがＩＣカードと同じ暗号鍵を使って暗号化や復号化が可能でなければならない。広域システムではすべてのアプリケーションサーバーが信頼できるとは限らないので、暗号鍵を分散管理することはセキュリティ上の問題がある。
【０００９】
・公開鍵暗号による認証システムの運用コストの問題
広域認証システムでは、鍵管理が容易なＲＳＡなどの公開鍵暗号を用いるのが普通である。しかし、公開鍵暗号による大規模な認証基盤の構築には大きなコストがかかるという問題がある。
例えば、公開鍵暗号の秘密鍵と公開鍵証明書とを一対のパッケージにしてユーザーに配付する手段としてＰＫＣＳ＃１２形式にして暗号化した鍵のデータをフロッピーなどの記録媒体に入れて配付する方法がすでに提案されているが、この方法では各ユーザーが自分のＰＣに手動で秘密鍵を復号化するパスワードを使ってブラウザなどのソフトに組み込む必要がある。この作業は初心者には困難であるために大規模な認証基盤を作るためには運用面で問題がある。また暗号鍵をパソコンのファイルに格納しなければならないためにセキュリティの上の問題もある。
【００１０】
・公開鍵暗号によるＩＣカードの問題
ＩＣカードは、フロッピーなどと異なり暗号化や復号化などの操作を行なうことなく物理的な物体を機械に差し込むだけで利用できるために利用や運用が簡単であり、安全性が高い。ＲＳＡなどの公開鍵暗号処理系を持ったＩＣカードを使う方法もある。
公開鍵暗号によるＩＣカードを利用する方法は、理想的であるが、公開鍵暗号処理系は共有鍵暗号系に比較して非常に計算量が大きいために、性能やコストの面での問題がある。
【００１１】
・アプリケーションサーバーによる認証システムの広域的な選択の問題
インターネットでは、ＩＣカードの発行者は一つではなく多数分散して存在する。このため、アプリケーションサーバーは、アクセスしてきたユーザーを認証するために、そのユーザーのＩＣカードを認証するためには、どの認証主体が管理している認証システムにアクセスすればよいのかわかる必要がある。そしてさらにインターネットを経由して安全にその認証システムにアクセスして利用できなければならない。
【００１２】
・信頼できないＩＣカード端末の問題
ＩＣカードの利点は、ユーザーが自分の認証情報を安全に持ち歩くことができることである。そうすることによって自宅のパソコンだけでなく職場や公共端末からでもＩＣカードを差し込むだけでユーザー認証が必要なアプリケーションサーバーを利用できるという利点がある。
しかし、公共の端末は一般に安全である保証はない。例えば、実際にはアプリケーションサーバーに接続していないにもかかわらずアプリケーションサーバーと接続していることを模倣したり、ユーザーのパスワードを盗んだり、ユーザーが入力したものと異なる金額などのデータをアプリケーションサーバーに送ったりするなどの不正を行なう可能性がある。
【００１３】
・ＩＣカードを暗号化機械として利用される問題（図８参照）
信頼できない端末がＩＣカードの認証機能を横取りして暗号化装置として利用する可能性がある。このような不正があると、例えばユーザーの意図しているアプリケーションサーバーとは異なるサーバーに背後で接続し、チャレンジアンドレスポンスによる認証成功の後に架空の取引をユーザーが知らないうちに行なったりするなどの危険性がある。
【００１４】
・信頼できないアプリケーションサーバーの問題（図９参照）
インターネット上のネットワーク上のアプリケーションサーバーは一般に信頼できるとは限らない。共有鍵暗号によるチャレンジアンドレスポンスによる認証は、双方が同じ暗号鍵を持つことが前提になる。アプリケーシヨンサーバーがユーザー認証をするためには、あらかじめユーザーのＩＣカードの中にある鍵と同じ鍵をアプリケーションサーバーにも登録しておく必要があるので、これは大きな問題である。
悪意のアプリケーションサーバーにユーザーの鍵を登録してしまうとアプリケーションサーバーがＩＣカードを持ったユーザーになりすまして他のアプリケーションサーバーにアクセスする危険性がある。
【００１５】
・認証サーバーを暗号化機械として利用される問題（図１０参照）
信頼できないアプリケーションサーバーに暗号鍵を管理させる代わりに、信頼できる認証サーバーを用意してアプリケーションサーバーから利用するという方法が考えられる。この方法を使うと暗号鍵そのものは安全に管理できるようになる。
認証サーバーを使ったアプリケーションサーバーによるユーザー認証では、アプリケーションサーバーは、ＩＣカードと認証サーバーを仲介して双方が同じ暗号鍵Ｋに基づく暗号化／復号化の能力を持っていることを検証すればよい。
しかし、共有鍵暗号系の暗号化と復号化は全く同じ操作であるため、このプロトコルにおける認証サーバーによる暗号文の復号化は任意の文の暗号化処理として利用できる。これは認証サーバーとユーザーのＩＣカードが全く同じ機能を持つことにほかならない。したがって、悪意のアプリケーションサーバーが認証サーバーをユーザーのＩＣカードと同じ機能を持つ暗号化装置として使用すると、なりすましが可能になる。
【００１６】
【発明が解決しようとする課題】
共有鍵暗号型のＩＣカードは安価であるが、認証を行なうサーバーと認証されるユーザーのＩＣカードに同一の暗号鍵がなければ認証処理が行なえない。したがって１枚のＩＣカードで複数のサーバーを認証付きで利用しようとすると、暗号鍵を複数のサーバー分散して管理しなければならないという問題が生じる。
【００１７】
広域的にサーバーが多数分散しているインターネット環境では、一般的にサーバーが信頼できるとは限らない。悪意のあるサーバーに認証用の暗号鍵を渡すと鍵が外部に漏洩する危険性があるだけでなぐユーザーになりすまして他のサービスを利用される危険性がある。また店舗などに設置されているＩＣカードリーダーが付いた公共端末のクライアントも一般的には信頼できない。悪意のＩＣカード端末のクライアントは、ユーザーが入力したパスワードを盗んだり、ユーザーの入力と異なるデータをサーバーに送るなどの不正を行なう可能性がある。またユーザーが挿入したＩＣカードを暗号化機械として利用されユーザーの意図と異なるサーバーへのユーザー認証を行ない悪用される可能性もある。
【００１８】
本発明は、共有鍵暗号型のＩＣカード（スマートカード）を使用したユーザー認証システムの実現手段に関して、１枚のＩＣカードでインターネット上の広域的に分散したサーバー群における安全なユーザー認証を実現することを目的としている。
【００１９】
【課題を解決するための手段】
前記課題を解決するため、本発明のユーザー認識方式は、ユーザーの一意名を記録したＩＣカードと、前記ユーザーの一意名と対応づけてユーザー固有の暗号鍵を安全に管理する機能と共有鍵暗号によるチャレンジアンドレスポンス型のユーザー認証機能を持つ認証サーバーとを備え、前記認証サーバーは公開鍵暗号に基づくサーバー認証機能を備え、広域的に分散しているアプリケーションサーバーがユーザー認証を行なうときに、まず公開鍵暗号により認証サーバーのサーバー認証を行なったうえで通信を行なう手段と、ユーザーのＩＣカードから読み出したユーザーの一意名をもとに認証サーバーのユーザー認証機能を利用することによって、ユーザー認証を行なう手段とを有することを特徴とする。
【００２０】
このユーザー認識方式における実施態様は、さらにユーザーの属性情報を統合的に管理する認証用ディレクトリーサーバーを備え、前記認証用ディレクトリーサーバーは、公開鍵暗号に基づくサーバー認証機能を備え、アプリケーションサーバーがユーザー認証時にまず公開鍵暗号により認証用ディレクトリーサーバーのサーバー認証を行なったうえで、アプリケーションサーバーは、認証用ディレクトリーサーバーに登録されているユーザーの属性情報をユーザーの一意名によって検索し、その情報に基づいてサービスの可否を判断する手段を備えたことを特徴とする。
【００２１】
さらに、他の実施態様は、ユーザーのＩＣカードに発行時にそのＩＣカードの発行主体の一意名を記録しておくとともに、そのＩＣカードを認証することができる認証サーバーのネットワークアドレスを発行主体の一意名と対応づけて認証用ディレクトリーサーバーに登録しておき、ユーザー認証時にアプリケーションサーバーがユーザーのＩＣカードの発行主体の一意名を参照して認証用ディレクトリーを検索してそのユーザーの認証に必要な認証サーバーのネットワークアドレスを知るようにすることを特徴とする。
【００２２】
さらに、他の実施態様は、ＩＣカード発行時に認証サーバーを認証するための共有鍵暗号の暗号鍵をＩＣカードに格納しておき、公共のＩＣカード端末クライアントには公開鍵暗号に基づくクライアント認証機能を持たせ、アプリケーションサーバーにも公開鍵暗号に基づくクライアント認証機能とサーバー認証機能を持たせ、ユーザー認証時に、まず、認証サーバーとアプリケーションサーバーの間の公開鍵暗号に基づく相互認証と、アプリケーションサーバーと公共のＩＣカード端末クライアントの間の公開鍵暗号に基づく相互認証を行ない、前記の両方の相互認証が成功している通信路を使ってユーザーのＩＣカード側からＩＳ〇７８１６の共有鍵暗号による外部認証プロトコルに準ずる方法によって認証サーバーの認証を行ない、以上のプロセスがすべて成功したときにのみ、認証サーバーおよびＩＣカードのユーザー認証の機能が使えるようになるように制限し、ユーザー認証プロセスのアプリケーションサーバーによるＩＣカードの認証プロセスにおいて認証サーバーは暗号化した結果を返す代わりに認証の成否の通知だけを返すことによって認証サーバーをユーザー鍵による暗号化装置や疑似的なＩＣカードとして利用されることを防止するようにしたことを特徴とする。
【００２３】
なお、自宅のパソコンなどの信頼できる端末クライアントの場合は、公開鍵暗号に基づくクライアント認証は不要である。
【００２４】
【発明の実施の形態】
以下、本発明の実施の形態について説明する。
図１は、本発明の全体構成を示すブロック図である。
図中、１はディレクトリーサーバー、２は認証サーバー、３はアプリケーションサーバー、４はクライアントマシン、５はＩＣカードである。
【００２５】
本発明においては、広域的に分散しているサーバーごとにユーザー管理を行なう代わりに、ユーザーの名前管理を行なうディレクトリーサーバー１による統合的ユーザー情報管理システムを備え、ＩＣカードの発行主体ごとに、ユーザーに発行されたＩＣカード５に格納されている共有鍵暗号の暗号鍵と同一の暗号鍵を保持しチャレンジアンドレスポンスによる認証機能を持つ認証サーバー２を備え、各サーバー３はユーザー認証を行なうときに、認証サーバー２を利用することにより、各サーバー２で暗号鍵を管理することなく広域的に分散されたサーバー群がＩＣカード５を持つユーザーの認証を行なうことができ、それによって信頼できないサーバーにユーザーの暗号鍵が漏洩することが避けられる。
【００２６】
サーバーマシンにおける不正やクライアントマシンにおける不正の問題は、信頼可能な認証サーバー２を起点にして、公開鍵暗号による広域認証システムを利用することによって、認証サーバー２とサーバーマシン３の相互認証と、サーバーマシン３とクライアントマシン４の相互認証をそれぞれ行ない、この両者が成功した後にユーザーのＩＣカード５から認証サーバー２までのセッションを確立することによって、この両者の不正を同時に防御することができる。
【００２７】
【発明の実施の形態】
以下、本発明の実施例について説明する。
【００２８】
（ａ）発行時にＩＣカードに登録される主な情報
＊ＤＮｓ：認証主体の一意名
＊ＤＮｕ：ＩＣカード所持者本人の一意名
以上の情報は、Ｘ．５０９公開鍵証明書のフォーマットを使って一体化して格納してもよい。
＊Ｋｓ：認証サーバーの認証用の暗号鍵
＊Ｋｕ：ユーザー認証用の暗号鍵
【００２９】
（ｂ）発行時にＩＣカードに設定されるアクセス条件
＊認証主体の一意名 （無条件に読み取り可）
＊ＩＣカード所持者本人の一意名 （無条件に読み取り可）
＊認証サーバーの認証用の暗号鍵 （外部認証コマンドに使用される）
＊ユーザー認証用の暗号鍵 （外部認証コマンドが成功したときのみアクセス可、内部認証コマンドに使用される）
【００３０】
（ｃ）ＩＣカード発行時に認証サーバーに登録される情報
検索キー 値
＊ＤＮｕ：ユーザーの一意名 −＞ Ｋｕ：ユーザー認証用の暗号鍵
【００３１】
（ｄ）ＩＣカード発行時に認証用ディレクトリーサーバーに登録される情報
検索キー 値
＊ＤＮｓ：認証主体の一名 −＞ Ｓａｄｄｒ：認証サーバーのネットワークアドレス
【００３２】
（ｅ）認証サーバーが保持している公開鍵暗号関係の情報
＊ＳＫｓ：認証サーバー自身の秘密鍵
＊ＰＫａ：アプリケーションサーバーの公開鍵証明書
【００３３】
（ｆ）アプリケーションサーバーが保持している公開鍵暗号関係の情報
＊ＳＫａ：アプリケーションサーバー自身の秘密鍵
＊ＰＫｓ：認証サーバーの公開鍵証明書
＊ＰＫｃ：ＩＣカード端末クライアントの公開鍵証明書
【００３４】
（ｇ）ＩＣカード端末クライアントが保持している公開鍵暗号関係の情報
＊ＳＫｃ：ＩＣカード端末クライアント自身の秘密鍵
＊ＰＫａ：アプリケーションサーバーの公開鍵証明書
【００３５】
以下に、本実施例における認証プロセスについて説明する。
（１）認証サーバーの選択
図２に示すように、アプリケーションサーバー３がＩＣカード５から認証サーバーの一意名ＤＮｕ／ＤＮｓを読み出し、ディレクトリーサーバー１が認証用ディレクトリーを検索することによって認証サーバー２のアドレスを得て、利用する認証サーバー２を決定する。
【００３６】
（２）アプリケーションサーバーと認証サーバーの相互認証
図３に示すように、公開鍵暗号に基づく認証によりアプリケーションサーバー３と認証サーバー２が双方とも正しいものであることを証明する。この実装は、公開鍵証明書としてはＸ．５０９を使用しプロトコルはＳＳＬやＴＬＳを想定している。
【００３７】
（３）アプリケーションサーバーとＩＣカード端末クライアントの相互認証
図４に示すように、公開鍵暗号に基づく認証によりアプリケーションサーバー３とＩＣカード端末クライアント４が双方とも正しいものであることを証明する。この実装は、公開鍵証明書としてはＸ．５０９を使用しプロトコルはＳＳＬやＴＬＳを想定している。
【００３８】
（４）ＩＣカードからの認証サーバーの外部認証
（３）までの相互認証が双方とも成功した場合、図５に示すように、ＩＣカード５から、認証サーバー２の鍵Ｋｓを使ったチャレンジアンドレスポンスで認証サーバー２の認証を行なう。乱数の暗号化と復号化の結果、同じ乱数に戻れば、双方が同じ暗号鍵を持っていることになるので認証が成功する。
【００３９】
（５）認証サーバーからＩＣカードの内部認証
（４）までの相互認証がすべて成功した場合、ＩＣカードの中のユーザー鍵による暗号化の機能がアクティベートされる。図６に示すように、まず、ＩＣカード５に格納されているユーザーの一意名ＤＮｕ／ＤＮｓがアプリケーションサーバー３経由で認証サーバー２に送られ、認証サーバー２はユーザーの暗号鍵Ｋｕを特定する。
認証サーバー２で発生させられた乱数のＩＣカード５による暗号化結果が認証サーバー２側の復号化の結果、同じ乱数に戻れば、双方が同じユーザーの暗号鍵を持っていることになるので認証が成功する。
ただし、この結果をそのままアプリケーションサーバー３に送ると、アプリケーションサーバー３が認証サーバー２を暗号化装置として利用する危険性があるので、認証サーバー２は認証の結果が成功したか失敗したかだけを通知する。
【００４０】
（６）アプリケーションサーバーによる認証用ディレクトリーの検索
認証プロセスが成功した後に、アプリケーションサーバーは、ディレクトリーサーバーによってユーザーの属性情報を得ることによって、サービスの権限を決定する。
【００４１】
【発明の効果】
上述したように、本発明によれば下記の効果を奏する。
（１）共有鍵暗号型のＩＣカード（スマートカード）を利用して、インターネット上でサービスを行なっているサーバー群を利用するための認証システムであるため、広域的に分散したアプリケーションサーバー群で安全に利用することができる。
【００４２】
（２）広域的に分散しているアプリケーションサーバーがユーザー認証を行なうときに、まず公開鍵暗号により認証サーバーのサーバー認証を行なったうえで通信を行ない、ユーザーのＩＣカードから読み出したユーザーの一意名をもとに認証サーバーのユーザー認証機能を利用することによって、アプリケーションサーバー側でユーザーの共有鍵暗号鍵を管理することなくユーザー認証を行なうことができることにより、認証サーバーのみを安全に管理するだけでユーザーの暗号鍵を守ることができる。
【００４３】
（３）認証用ディレクトリーサーバーは、公開鍵暗号に基づくサーバー認証機能を備え、アプリケーションサーバーがユーザー認証時にまず公開鍵暗号により認証用ディレクトリーサーバーのサーバー認証を行なったうえで、アプリケーションサーバーは、認証用ディレクトリーサーバーに登録されているユーザーの属性情報をユーザーの一意名によって検索し、その情報に基づいてサービスの可否を判断することによって、ユーザーは１枚のＩＣカードを持つのみで複数のアプリケーションサーバーを利用できる。
【００４４】
（４）前記のユーザー認証機能に加えて、ユーザーのＩＣカードに発行時にそのＩＣカードの発行主体の一名（ＤＮ）を記録しておくとともに、そのＩＣカードを認証することができる認証サーバーのネットワークアドレスを発行主体の一意名と対応づけて認証用ディレクトリーサーバーに登録しておき、ユーザー認証時にアプリケーションサーバーがユーザーのＩＣカードの発行主体の一意名を参照して認証用ディレクトリーを検索してそのユーザーの認証に必要な認証サーバーのネットワークアドレスを知ることによって、複数のＩＣカードの発行主体が発行したカードを統合的に利用できる。
【００４５】
（５）ＩＣカード発行時に認証サーバーを認証するための共有鍵暗号の暗号鍵をＩＣカードに格納しておき、公共のＩＣカード端末クライアントには公開鍵暗号に基づくクライアント認証機能を持たせ、アプリケーションサーバーにも公開鍵暗号に基づくクライアント認証機能とサーバー認証機能を持たせ、ユーザー認証時に、まず、認証サーバーとアプリケーションサーバーの間の公開鍵暗号に基づく相互認証と、アプリケーションサーバーと公共のＩＣカード端末クライアントの間の公開鍵暗号に基づく相互認証を行ない、の両方の相互認証が成功している通信路を使ってユーザーのＩＣカード側からＩＳ〇７８１６の共有鍵暗号による外部認証プロトコルに準ずる方法によって認証サーバーの認証を行ない、以上のプロセスがすべて成功したときにのみ、認証サーバーおよびＩＣカードのユーザー認証の機能が使えるようになるように制限し、ユーザー認証プロセスのアプリケーションサーバーによるＩＣカードの認証プロセスにおいて認証サーバーは暗号化した結果を返す代わりに認証の成否の通知だけを返すことによって認証サーバーをユーザー鍵による暗号化装置や疑似的なＩＣカードとして利用されることを防止することによって認証サーバーやＩＣカードを暗号化装置や認証装置として悪用されることを防ぐことができる。
【図面の簡単な説明】
【図１】 本発明の全体構成を示すブロック図である。
【図２】 本発明による認証手順を説明するブロック図である。
【図３】 本発明による認証手順を説明するブロック図である。
【図４】 本発明による認証手順を説明するブロック図である。
【図５】 本発明による認証手順を説明するブロック図である。
【図６】 本発明による認証手順を説明するブロック図である。
【図７】 従来の共有鍵暗号によるチャレンジアンドレスポンスプロトコルの説明図である。
【図８】 悪意の端末によるＩＣカードの暗号化機能の利用の説明図である。
【図９】 悪意のアプリケーションサーバーによるユーザーＩＣカードへのなりすましの説明図である。
【図１０】 認証サーバーを使ったユーザー認証プロトコルの説明図である。
【符号の説明】
１ ディレクトリーサーバー、２ 認証サーバー、３ アプリケーションサーバー、４ クライアントマシン、５ ＩＣカード
【発明の属する技術分野】
本発明は、共有鍵暗号型のＩＣカード（スマートカード）を使用したユーザー認証システムの実現手段に関して、１枚のＩＣカードでインターネット上の広域的に分散したサーバー郡における安全なユーザー認証を実現する手段に関するものである。
【０００２】
【従来の技術】
従来のコンピュータシステムにおけるユーザー認証は、各サーバーのシステム管理者がそのユーザーをサーバーごとに登録することによって実現されていた。しかしインターネットでは、ユーザーの方が世界中にあるアプリケーションサーバーを選択して接続し、電子決済などのセキュリティが必要なサービスを要求する。また一つの組織内でも多数のサーバーが稼働するようになったため、サーバーごとにユーザー管理を行なう方法は現実的でなくなってきた。このめ、Ｘ．５０９公開鍵認証基盤に代表されるような広域的なユーザー認証手段が必要となっている。
【０００３】
インターネット上の広域的なユーザー認証は、インターネットを使った電子商取引の安全性確保や遠隔医療やワンストップ行政サービスなどにおけるプライバシー保護やデジタルコンテンツの著作権保護など多くの場面で必須のものになってきている。
【０００４】
広域的な認証基盤として、公開鍵暗号を利用する公開鍵証明書に基づくシステムが存在している。しかし公開鍵暗号は共有鍵暗号系に比べると計算量が非常に大きいために、性能や容量の点でＩＣカードとして実現することが困難でありコスト的に問題がある。フロッピーなどで公開鍵暗号の秘密鍵やデジタル証明書を配付する方法もあるが、運用や管理が困難であることがわかっている。
【０００５】
従来技術の技術的問題点について述べる前に、まず前提条件として共有鍵暗号に基づく一般的なチャレンジアンドレスポンスによる認証プロトコルについて述べておく。
データ−Ｍを暗号鍵Ｋによって暗号化した結果を［Ｍ］Kと書くことにする。また暗号化されたデータ−Ｘを暗号鍵Ｋで復号化した結果を｛Ｘ｝Kと書くことにする。
【０００６】
図７に示すように、Ａが通信の相手Ｂに対して本人認証を行なうときに次のような処理を行なう。
０．前提、ＡとＢは同じ暗号鍵Ｋを持っている。このＫはＢを確認するための鍵である。
１．Ａは、新しい乱数Ｒを生成して通信路を経由してＢに送る。
２．Ｂは、Ａから送られた乱数Ｒを自分の暗号鍵Ｋで暗号文を作り、Ａに送り返す。
３．ＡはＢから送られた［Ｒ］Kを暗号鍵Ｋで復号化し｛［Ｒ］K｝Kを計算し、これがＲと一致すれば、ともに同じ暗号鍵Ｋを所持していることが確認できるので認証が成功したものとする。また一致しなければ認証が失敗する。
【０００７】
ＩＳＯ７８１６などの一般的に普及しているＩＣカードの標準規格では、乱数の生成やチャレンジアンドレスポンスをＩＣカードから相手へ（外部認証）とサービス側からＩＣカードへ（内部認証）の機能を備えている。本発明では、このような機能を持ったＩＣカードの利用を前提とする。
【０００８】
本方式を実現する上で生ずる問題を以下に列挙する。
・認証用暗号鍵の分散の問題
ＤＥＳなどの共有鍵型の暗号によるＩＣカードを用いた認証システムは、アプリケーシヨンサーバー側とユーザーのＩＣカードが同じ暗号鍵を持ち、安全に管理する必要があるため、通常は特定のアプリケーションサーバーのユーザー認証に限定したクローズドシステムとして運用される。インターネットのような広域的な認証システムでは、アプリケーションサーバーがＩＣカードと同じ暗号鍵を使って暗号化や復号化が可能でなければならない。広域システムではすべてのアプリケーションサーバーが信頼できるとは限らないので、暗号鍵を分散管理することはセキュリティ上の問題がある。
【０００９】
・公開鍵暗号による認証システムの運用コストの問題
広域認証システムでは、鍵管理が容易なＲＳＡなどの公開鍵暗号を用いるのが普通である。しかし、公開鍵暗号による大規模な認証基盤の構築には大きなコストがかかるという問題がある。
例えば、公開鍵暗号の秘密鍵と公開鍵証明書とを一対のパッケージにしてユーザーに配付する手段としてＰＫＣＳ＃１２形式にして暗号化した鍵のデータをフロッピーなどの記録媒体に入れて配付する方法がすでに提案されているが、この方法では各ユーザーが自分のＰＣに手動で秘密鍵を復号化するパスワードを使ってブラウザなどのソフトに組み込む必要がある。この作業は初心者には困難であるために大規模な認証基盤を作るためには運用面で問題がある。また暗号鍵をパソコンのファイルに格納しなければならないためにセキュリティの上の問題もある。
【００１０】
・公開鍵暗号によるＩＣカードの問題
ＩＣカードは、フロッピーなどと異なり暗号化や復号化などの操作を行なうことなく物理的な物体を機械に差し込むだけで利用できるために利用や運用が簡単であり、安全性が高い。ＲＳＡなどの公開鍵暗号処理系を持ったＩＣカードを使う方法もある。
公開鍵暗号によるＩＣカードを利用する方法は、理想的であるが、公開鍵暗号処理系は共有鍵暗号系に比較して非常に計算量が大きいために、性能やコストの面での問題がある。
【００１１】
・アプリケーションサーバーによる認証システムの広域的な選択の問題
インターネットでは、ＩＣカードの発行者は一つではなく多数分散して存在する。このため、アプリケーションサーバーは、アクセスしてきたユーザーを認証するために、そのユーザーのＩＣカードを認証するためには、どの認証主体が管理している認証システムにアクセスすればよいのかわかる必要がある。そしてさらにインターネットを経由して安全にその認証システムにアクセスして利用できなければならない。
【００１２】
・信頼できないＩＣカード端末の問題
ＩＣカードの利点は、ユーザーが自分の認証情報を安全に持ち歩くことができることである。そうすることによって自宅のパソコンだけでなく職場や公共端末からでもＩＣカードを差し込むだけでユーザー認証が必要なアプリケーションサーバーを利用できるという利点がある。
しかし、公共の端末は一般に安全である保証はない。例えば、実際にはアプリケーションサーバーに接続していないにもかかわらずアプリケーションサーバーと接続していることを模倣したり、ユーザーのパスワードを盗んだり、ユーザーが入力したものと異なる金額などのデータをアプリケーションサーバーに送ったりするなどの不正を行なう可能性がある。
【００１３】
・ＩＣカードを暗号化機械として利用される問題（図８参照）
信頼できない端末がＩＣカードの認証機能を横取りして暗号化装置として利用する可能性がある。このような不正があると、例えばユーザーの意図しているアプリケーションサーバーとは異なるサーバーに背後で接続し、チャレンジアンドレスポンスによる認証成功の後に架空の取引をユーザーが知らないうちに行なったりするなどの危険性がある。
【００１４】
・信頼できないアプリケーションサーバーの問題（図９参照）
インターネット上のネットワーク上のアプリケーションサーバーは一般に信頼できるとは限らない。共有鍵暗号によるチャレンジアンドレスポンスによる認証は、双方が同じ暗号鍵を持つことが前提になる。アプリケーシヨンサーバーがユーザー認証をするためには、あらかじめユーザーのＩＣカードの中にある鍵と同じ鍵をアプリケーションサーバーにも登録しておく必要があるので、これは大きな問題である。
悪意のアプリケーションサーバーにユーザーの鍵を登録してしまうとアプリケーションサーバーがＩＣカードを持ったユーザーになりすまして他のアプリケーションサーバーにアクセスする危険性がある。
【００１５】
・認証サーバーを暗号化機械として利用される問題（図１０参照）
信頼できないアプリケーションサーバーに暗号鍵を管理させる代わりに、信頼できる認証サーバーを用意してアプリケーションサーバーから利用するという方法が考えられる。この方法を使うと暗号鍵そのものは安全に管理できるようになる。
認証サーバーを使ったアプリケーションサーバーによるユーザー認証では、アプリケーションサーバーは、ＩＣカードと認証サーバーを仲介して双方が同じ暗号鍵Ｋに基づく暗号化／復号化の能力を持っていることを検証すればよい。
しかし、共有鍵暗号系の暗号化と復号化は全く同じ操作であるため、このプロトコルにおける認証サーバーによる暗号文の復号化は任意の文の暗号化処理として利用できる。これは認証サーバーとユーザーのＩＣカードが全く同じ機能を持つことにほかならない。したがって、悪意のアプリケーションサーバーが認証サーバーをユーザーのＩＣカードと同じ機能を持つ暗号化装置として使用すると、なりすましが可能になる。
【００１６】
【発明が解決しようとする課題】
共有鍵暗号型のＩＣカードは安価であるが、認証を行なうサーバーと認証されるユーザーのＩＣカードに同一の暗号鍵がなければ認証処理が行なえない。したがって１枚のＩＣカードで複数のサーバーを認証付きで利用しようとすると、暗号鍵を複数のサーバー分散して管理しなければならないという問題が生じる。
【００１７】
広域的にサーバーが多数分散しているインターネット環境では、一般的にサーバーが信頼できるとは限らない。悪意のあるサーバーに認証用の暗号鍵を渡すと鍵が外部に漏洩する危険性があるだけでなぐユーザーになりすまして他のサービスを利用される危険性がある。また店舗などに設置されているＩＣカードリーダーが付いた公共端末のクライアントも一般的には信頼できない。悪意のＩＣカード端末のクライアントは、ユーザーが入力したパスワードを盗んだり、ユーザーの入力と異なるデータをサーバーに送るなどの不正を行なう可能性がある。またユーザーが挿入したＩＣカードを暗号化機械として利用されユーザーの意図と異なるサーバーへのユーザー認証を行ない悪用される可能性もある。
【００１８】
本発明は、共有鍵暗号型のＩＣカード（スマートカード）を使用したユーザー認証システムの実現手段に関して、１枚のＩＣカードでインターネット上の広域的に分散したサーバー群における安全なユーザー認証を実現することを目的としている。
【００１９】
【課題を解決するための手段】
前記課題を解決するため、本発明のユーザー認識方式は、ユーザーの一意名を記録したＩＣカードと、前記ユーザーの一意名と対応づけてユーザー固有の暗号鍵を安全に管理する機能と共有鍵暗号によるチャレンジアンドレスポンス型のユーザー認証機能を持つ認証サーバーとを備え、前記認証サーバーは公開鍵暗号に基づくサーバー認証機能を備え、広域的に分散しているアプリケーションサーバーがユーザー認証を行なうときに、まず公開鍵暗号により認証サーバーのサーバー認証を行なったうえで通信を行なう手段と、ユーザーのＩＣカードから読み出したユーザーの一意名をもとに認証サーバーのユーザー認証機能を利用することによって、ユーザー認証を行なう手段とを有することを特徴とする。
【００２０】
このユーザー認識方式における実施態様は、さらにユーザーの属性情報を統合的に管理する認証用ディレクトリーサーバーを備え、前記認証用ディレクトリーサーバーは、公開鍵暗号に基づくサーバー認証機能を備え、アプリケーションサーバーがユーザー認証時にまず公開鍵暗号により認証用ディレクトリーサーバーのサーバー認証を行なったうえで、アプリケーションサーバーは、認証用ディレクトリーサーバーに登録されているユーザーの属性情報をユーザーの一意名によって検索し、その情報に基づいてサービスの可否を判断する手段を備えたことを特徴とする。
【００２１】
さらに、他の実施態様は、ユーザーのＩＣカードに発行時にそのＩＣカードの発行主体の一意名を記録しておくとともに、そのＩＣカードを認証することができる認証サーバーのネットワークアドレスを発行主体の一意名と対応づけて認証用ディレクトリーサーバーに登録しておき、ユーザー認証時にアプリケーションサーバーがユーザーのＩＣカードの発行主体の一意名を参照して認証用ディレクトリーを検索してそのユーザーの認証に必要な認証サーバーのネットワークアドレスを知るようにすることを特徴とする。
【００２２】
さらに、他の実施態様は、ＩＣカード発行時に認証サーバーを認証するための共有鍵暗号の暗号鍵をＩＣカードに格納しておき、公共のＩＣカード端末クライアントには公開鍵暗号に基づくクライアント認証機能を持たせ、アプリケーションサーバーにも公開鍵暗号に基づくクライアント認証機能とサーバー認証機能を持たせ、ユーザー認証時に、まず、認証サーバーとアプリケーションサーバーの間の公開鍵暗号に基づく相互認証と、アプリケーションサーバーと公共のＩＣカード端末クライアントの間の公開鍵暗号に基づく相互認証を行ない、前記の両方の相互認証が成功している通信路を使ってユーザーのＩＣカード側からＩＳ〇７８１６の共有鍵暗号による外部認証プロトコルに準ずる方法によって認証サーバーの認証を行ない、以上のプロセスがすべて成功したときにのみ、認証サーバーおよびＩＣカードのユーザー認証の機能が使えるようになるように制限し、ユーザー認証プロセスのアプリケーションサーバーによるＩＣカードの認証プロセスにおいて認証サーバーは暗号化した結果を返す代わりに認証の成否の通知だけを返すことによって認証サーバーをユーザー鍵による暗号化装置や疑似的なＩＣカードとして利用されることを防止するようにしたことを特徴とする。
【００２３】
なお、自宅のパソコンなどの信頼できる端末クライアントの場合は、公開鍵暗号に基づくクライアント認証は不要である。
【００２４】
【発明の実施の形態】
以下、本発明の実施の形態について説明する。
図１は、本発明の全体構成を示すブロック図である。
図中、１はディレクトリーサーバー、２は認証サーバー、３はアプリケーションサーバー、４はクライアントマシン、５はＩＣカードである。
【００２５】
本発明においては、広域的に分散しているサーバーごとにユーザー管理を行なう代わりに、ユーザーの名前管理を行なうディレクトリーサーバー１による統合的ユーザー情報管理システムを備え、ＩＣカードの発行主体ごとに、ユーザーに発行されたＩＣカード５に格納されている共有鍵暗号の暗号鍵と同一の暗号鍵を保持しチャレンジアンドレスポンスによる認証機能を持つ認証サーバー２を備え、各サーバー３はユーザー認証を行なうときに、認証サーバー２を利用することにより、各サーバー２で暗号鍵を管理することなく広域的に分散されたサーバー群がＩＣカード５を持つユーザーの認証を行なうことができ、それによって信頼できないサーバーにユーザーの暗号鍵が漏洩することが避けられる。
【００２６】
サーバーマシンにおける不正やクライアントマシンにおける不正の問題は、信頼可能な認証サーバー２を起点にして、公開鍵暗号による広域認証システムを利用することによって、認証サーバー２とサーバーマシン３の相互認証と、サーバーマシン３とクライアントマシン４の相互認証をそれぞれ行ない、この両者が成功した後にユーザーのＩＣカード５から認証サーバー２までのセッションを確立することによって、この両者の不正を同時に防御することができる。
【００２７】
【発明の実施の形態】
以下、本発明の実施例について説明する。
【００２８】
（ａ）発行時にＩＣカードに登録される主な情報
＊ＤＮｓ：認証主体の一意名
＊ＤＮｕ：ＩＣカード所持者本人の一意名
以上の情報は、Ｘ．５０９公開鍵証明書のフォーマットを使って一体化して格納してもよい。
＊Ｋｓ：認証サーバーの認証用の暗号鍵
＊Ｋｕ：ユーザー認証用の暗号鍵
【００２９】
（ｂ）発行時にＩＣカードに設定されるアクセス条件
＊認証主体の一意名 （無条件に読み取り可）
＊ＩＣカード所持者本人の一意名 （無条件に読み取り可）
＊認証サーバーの認証用の暗号鍵 （外部認証コマンドに使用される）
＊ユーザー認証用の暗号鍵 （外部認証コマンドが成功したときのみアクセス可、内部認証コマンドに使用される）
【００３０】
（ｃ）ＩＣカード発行時に認証サーバーに登録される情報
検索キー 値
＊ＤＮｕ：ユーザーの一意名 −＞ Ｋｕ：ユーザー認証用の暗号鍵
【００３１】
（ｄ）ＩＣカード発行時に認証用ディレクトリーサーバーに登録される情報
検索キー 値
＊ＤＮｓ：認証主体の一名 −＞ Ｓａｄｄｒ：認証サーバーのネットワークアドレス
【００３２】
（ｅ）認証サーバーが保持している公開鍵暗号関係の情報
＊ＳＫｓ：認証サーバー自身の秘密鍵
＊ＰＫａ：アプリケーションサーバーの公開鍵証明書
【００３３】
（ｆ）アプリケーションサーバーが保持している公開鍵暗号関係の情報
＊ＳＫａ：アプリケーションサーバー自身の秘密鍵
＊ＰＫｓ：認証サーバーの公開鍵証明書
＊ＰＫｃ：ＩＣカード端末クライアントの公開鍵証明書
【００３４】
（ｇ）ＩＣカード端末クライアントが保持している公開鍵暗号関係の情報
＊ＳＫｃ：ＩＣカード端末クライアント自身の秘密鍵
＊ＰＫａ：アプリケーションサーバーの公開鍵証明書
【００３５】
以下に、本実施例における認証プロセスについて説明する。
（１）認証サーバーの選択
図２に示すように、アプリケーションサーバー３がＩＣカード５から認証サーバーの一意名ＤＮｕ／ＤＮｓを読み出し、ディレクトリーサーバー１が認証用ディレクトリーを検索することによって認証サーバー２のアドレスを得て、利用する認証サーバー２を決定する。
【００３６】
（２）アプリケーションサーバーと認証サーバーの相互認証
図３に示すように、公開鍵暗号に基づく認証によりアプリケーションサーバー３と認証サーバー２が双方とも正しいものであることを証明する。この実装は、公開鍵証明書としてはＸ．５０９を使用しプロトコルはＳＳＬやＴＬＳを想定している。
【００３７】
（３）アプリケーションサーバーとＩＣカード端末クライアントの相互認証
図４に示すように、公開鍵暗号に基づく認証によりアプリケーションサーバー３とＩＣカード端末クライアント４が双方とも正しいものであることを証明する。この実装は、公開鍵証明書としてはＸ．５０９を使用しプロトコルはＳＳＬやＴＬＳを想定している。
【００３８】
（４）ＩＣカードからの認証サーバーの外部認証
（３）までの相互認証が双方とも成功した場合、図５に示すように、ＩＣカード５から、認証サーバー２の鍵Ｋｓを使ったチャレンジアンドレスポンスで認証サーバー２の認証を行なう。乱数の暗号化と復号化の結果、同じ乱数に戻れば、双方が同じ暗号鍵を持っていることになるので認証が成功する。
【００３９】
（５）認証サーバーからＩＣカードの内部認証
（４）までの相互認証がすべて成功した場合、ＩＣカードの中のユーザー鍵による暗号化の機能がアクティベートされる。図６に示すように、まず、ＩＣカード５に格納されているユーザーの一意名ＤＮｕ／ＤＮｓがアプリケーションサーバー３経由で認証サーバー２に送られ、認証サーバー２はユーザーの暗号鍵Ｋｕを特定する。
認証サーバー２で発生させられた乱数のＩＣカード５による暗号化結果が認証サーバー２側の復号化の結果、同じ乱数に戻れば、双方が同じユーザーの暗号鍵を持っていることになるので認証が成功する。
ただし、この結果をそのままアプリケーションサーバー３に送ると、アプリケーションサーバー３が認証サーバー２を暗号化装置として利用する危険性があるので、認証サーバー２は認証の結果が成功したか失敗したかだけを通知する。
【００４０】
（６）アプリケーションサーバーによる認証用ディレクトリーの検索
認証プロセスが成功した後に、アプリケーションサーバーは、ディレクトリーサーバーによってユーザーの属性情報を得ることによって、サービスの権限を決定する。
【００４１】
【発明の効果】
上述したように、本発明によれば下記の効果を奏する。
（１）共有鍵暗号型のＩＣカード（スマートカード）を利用して、インターネット上でサービスを行なっているサーバー群を利用するための認証システムであるため、広域的に分散したアプリケーションサーバー群で安全に利用することができる。
【００４２】
（２）広域的に分散しているアプリケーションサーバーがユーザー認証を行なうときに、まず公開鍵暗号により認証サーバーのサーバー認証を行なったうえで通信を行ない、ユーザーのＩＣカードから読み出したユーザーの一意名をもとに認証サーバーのユーザー認証機能を利用することによって、アプリケーションサーバー側でユーザーの共有鍵暗号鍵を管理することなくユーザー認証を行なうことができることにより、認証サーバーのみを安全に管理するだけでユーザーの暗号鍵を守ることができる。
【００４３】
（３）認証用ディレクトリーサーバーは、公開鍵暗号に基づくサーバー認証機能を備え、アプリケーションサーバーがユーザー認証時にまず公開鍵暗号により認証用ディレクトリーサーバーのサーバー認証を行なったうえで、アプリケーションサーバーは、認証用ディレクトリーサーバーに登録されているユーザーの属性情報をユーザーの一意名によって検索し、その情報に基づいてサービスの可否を判断することによって、ユーザーは１枚のＩＣカードを持つのみで複数のアプリケーションサーバーを利用できる。
【００４４】
（４）前記のユーザー認証機能に加えて、ユーザーのＩＣカードに発行時にそのＩＣカードの発行主体の一名（ＤＮ）を記録しておくとともに、そのＩＣカードを認証することができる認証サーバーのネットワークアドレスを発行主体の一意名と対応づけて認証用ディレクトリーサーバーに登録しておき、ユーザー認証時にアプリケーションサーバーがユーザーのＩＣカードの発行主体の一意名を参照して認証用ディレクトリーを検索してそのユーザーの認証に必要な認証サーバーのネットワークアドレスを知ることによって、複数のＩＣカードの発行主体が発行したカードを統合的に利用できる。
【００４５】
（５）ＩＣカード発行時に認証サーバーを認証するための共有鍵暗号の暗号鍵をＩＣカードに格納しておき、公共のＩＣカード端末クライアントには公開鍵暗号に基づくクライアント認証機能を持たせ、アプリケーションサーバーにも公開鍵暗号に基づくクライアント認証機能とサーバー認証機能を持たせ、ユーザー認証時に、まず、認証サーバーとアプリケーションサーバーの間の公開鍵暗号に基づく相互認証と、アプリケーションサーバーと公共のＩＣカード端末クライアントの間の公開鍵暗号に基づく相互認証を行ない、の両方の相互認証が成功している通信路を使ってユーザーのＩＣカード側からＩＳ〇７８１６の共有鍵暗号による外部認証プロトコルに準ずる方法によって認証サーバーの認証を行ない、以上のプロセスがすべて成功したときにのみ、認証サーバーおよびＩＣカードのユーザー認証の機能が使えるようになるように制限し、ユーザー認証プロセスのアプリケーションサーバーによるＩＣカードの認証プロセスにおいて認証サーバーは暗号化した結果を返す代わりに認証の成否の通知だけを返すことによって認証サーバーをユーザー鍵による暗号化装置や疑似的なＩＣカードとして利用されることを防止することによって認証サーバーやＩＣカードを暗号化装置や認証装置として悪用されることを防ぐことができる。
【図面の簡単な説明】
【図１】 本発明の全体構成を示すブロック図である。
【図２】 本発明による認証手順を説明するブロック図である。
【図３】 本発明による認証手順を説明するブロック図である。
【図４】 本発明による認証手順を説明するブロック図である。
【図５】 本発明による認証手順を説明するブロック図である。
【図６】 本発明による認証手順を説明するブロック図である。
【図７】 従来の共有鍵暗号によるチャレンジアンドレスポンスプロトコルの説明図である。
【図８】 悪意の端末によるＩＣカードの暗号化機能の利用の説明図である。
【図９】 悪意のアプリケーションサーバーによるユーザーＩＣカードへのなりすましの説明図である。
【図１０】 認証サーバーを使ったユーザー認証プロトコルの説明図である。
【符号の説明】
１ ディレクトリーサーバー、２ 認証サーバー、３ アプリケーションサーバー、４ クライアントマシン、５ ＩＣカード
Claims (4)
- ユーザーの一意名を記録したＩＣカードと、前記ユーザーの一意名と対応づけてユーザー固有の暗号鍵を安全に管理する機能と共有鍵暗号によるチャレンジアンドレスポンス型のユーザー認証機能を持つ認証サーバーとを備え、前記認証サーバーは公開鍵暗号に基づくサーバー認証機能を備え、広域的に分散しているアプリケーションサーバーがユーザー認証を行なうときに、まず公開鍵暗号により認証サーバーのサーバー認証を行なったうえで通信を行なう手段と、ユーザーのＩＣカードから読み出したユーザーの一意名をもとに認証サーバーのユーザー認証機能を利用することによって、ユーザー認証を行なう手段とを有することを特徴とするユーザー認証方式。
- ユーザーの属性情報を統合的に管理する認証用ディレクトリーサーバーを備え、前記認証用ディレクトリーサーバーは、公開鍵暗号に基づくサーバー認証機能を備え、アプリケーションサーバーがユーザー認証時にまず公開鍵暗号により認証用ディレクトリーサーバーのサーバー認証を行なったうえで、アプリケーションサーバーは、認証用ディレクトリーサーバーに登録されているユーザーの属性情報をユーザーの一意名によって検索し、その情報に基づいてサービスの可否を判断する手段をさらに備えたことを特徴とする請求項１記載のユーザー認証方式。
- ユーザーのＩＣカードに発行時にそのＩＣカードの発行主体の一意名を記録しておくとともに、そのＩＣカードを認証することができる認証サーバーのネットワークアドレスを発行主体の一意名と対応づけて認証用ディレクトリーサーバーに登録しておき、ユーザー認証時にアプリケーションサーバーがユーザーのＩＣカードの発行主体の一意名を参照して認証用ディレクトリーを検索してそのユーザーの認証に必要な認証サーバーのネットワークアドレスを知るようにしたことを特徴とする請求項１または２記載のユーザー認証方式。
- ＩＣカード発行時に認証サーバーを認証するための共有鍵暗号の暗号鍵をＩＣカードに格納しておき、公共のＩＣカード端末クライアントには公開鍵暗号に基づくクライアント認証機能を持たせ、アプリケーションサーバーにも公開鍵暗号に基づくクライアント認証機能とサーバー認証機能を持たせ、ユーザー認証時に、まず、認証サーバーとアプリケーションサーバーの間の公開鍵暗号に基づく相互認証と、アプリケーションサーバーと公共のＩＣカード端末クライアントの間の公開鍵暗号に基づく相互認証を行ない、前記の両方の相互認証が成功している通信路を使ってユーザーのＩＣカード側からＩＳ〇７８１６の共有鍵暗号による外部認証プロトコルに準ずる方法によって認証サーバーの認証を行ない、以上のプロセスがすべて成功したときにのみ、認証サーバーおよびＩＣカードのユーザー認証の機能が使えるようになるように制限し、ユーザー認証プロセスのアプリケーションサーバーによるＩＣカードの認証プロセスにおいて認証サーバーは暗号化した結果を返す代わりに認証の成否の通知だけを返すことによって認証サーバーをユーザー鍵による暗号化装置や疑似的なＩＣカードとして利用されることを防止するようにしたことを特徴とする請求項１から３のいずれかの項に記載のユーザー認証方式。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP24215399A JP3872616B2 (ja) | 1999-08-27 | 1999-08-27 | 共有鍵暗号型のｉｃカードによるインターネット上のユーザー認証方式 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP24215399A JP3872616B2 (ja) | 1999-08-27 | 1999-08-27 | 共有鍵暗号型のｉｃカードによるインターネット上のユーザー認証方式 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001069138A JP2001069138A (ja) | 2001-03-16 |
| JP3872616B2 true JP3872616B2 (ja) | 2007-01-24 |
Family
ID=17085125
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP24215399A Expired - Fee Related JP3872616B2 (ja) | 1999-08-27 | 1999-08-27 | 共有鍵暗号型のｉｃカードによるインターネット上のユーザー認証方式 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3872616B2 (ja) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20030000749A (ko) * | 2001-06-27 | 2003-01-06 | 가부시키가이샤 웹톱 | 인터넷에 있어서의 유저의 확인방법 및 장치 |
| KR20030010241A (ko) * | 2001-07-26 | 2003-02-05 | 주식회사 텔사인 | 아이씨칩내장카드를 이용한 초고속 인터넷 불법 접속 및사용 방지시스템 |
| JP4151246B2 (ja) | 2001-08-22 | 2008-09-17 | ソニー株式会社 | 情報配信端末，コンピュータプログラムおよび情報提供方法 |
| AU2003227747A1 (en) * | 2003-05-12 | 2004-11-26 | Docomo Communications Laboratories Europe Gmbh | Network security method and system |
| JP5207965B2 (ja) * | 2005-05-06 | 2013-06-12 | ベリサイン・インコーポレイテッド | トークン共有システムおよび方法 |
| JP5035521B2 (ja) * | 2007-03-27 | 2012-09-26 | 大日本印刷株式会社 | 認証システム |
| JP2010171721A (ja) * | 2009-01-22 | 2010-08-05 | Fuji Electric Holdings Co Ltd | Ｉｃカードシステム、その上位機器、プログラム |
| JP2011028767A (ja) * | 2010-09-08 | 2011-02-10 | Sony Corp | セキュリティシステム、ネットワークアクセス方法及びセキュリティ処理実行許可方法 |
| JP5613532B2 (ja) * | 2010-11-11 | 2014-10-22 | 株式会社日立システムズ | クラウドサービス間の信頼関係構築方法及びシステム |
| CN111063063B (zh) * | 2019-11-29 | 2022-01-25 | 上海钧正网络科技有限公司 | 共享车辆解锁方法、装置、计算机设备和存储介质 |
-
1999
- 1999-08-27 JP JP24215399A patent/JP3872616B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001069138A (ja) | 2001-03-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2551113C (en) | Authentication system for networked computer applications | |
| Bellovin et al. | Limitations of the Kerberos authentication system | |
| EP2098006B1 (en) | Authentication delegation based on re-verification of cryptographic evidence | |
| US6246771B1 (en) | Session key recovery system and method | |
| US10554393B2 (en) | Universal secure messaging for cryptographic modules | |
| US6985953B1 (en) | System and apparatus for storage and transfer of secure data on web | |
| US6073237A (en) | Tamper resistant method and apparatus | |
| US8209753B2 (en) | Universal secure messaging for remote security tokens | |
| US8019881B2 (en) | Secure cookies | |
| RU2584500C2 (ru) | Криптографический способ аутентификации и идентификации с шифрованием в реальном времени | |
| US20020031225A1 (en) | User selection and authentication process over secure and nonsecure channels | |
| KR20030095341A (ko) | 전자티켓 유통시스템에서의 인증방법 및 ｉｃ 카드 | |
| WO2000030292A1 (en) | Method and system for authenticating and utilizing secure resources in a computer system | |
| JP4107420B2 (ja) | 安全なバイオメトリック認証／識別方法、バイオメトリックデータ入力モジュールおよび検証モジュール | |
| JP2003044436A (ja) | 認証処理方法、および情報処理装置、並びにコンピュータ・プログラム | |
| US20020018570A1 (en) | System and method for secure comparison of a common secret of communicating devices | |
| WO2008053279A1 (en) | Logging on a user device to a server | |
| JP3872616B2 (ja) | 共有鍵暗号型のｉｃカードによるインターネット上のユーザー認証方式 | |
| KR100761531B1 (ko) | 디지털 전자복권 판매 시스템 | |
| JP4372403B2 (ja) | 認証システム | |
| Bakker | Mutual authentication with smart cards | |
| KR100649858B1 (ko) | 공중전화 스마트 카드 발급/인증 시스템 및 그 방법 | |
| Ng et al. | A novel JavaCard-based authentication system for secured transactions on the Internet | |
| JP4626001B2 (ja) | 暗号化通信システム及び暗号化通信方法 | |
| Auyong et al. | Authentication services for computer networks and electronic messaging systems |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060623 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060809 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060922 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20061020 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091027 Year of fee payment: 3 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313117 |
|
| S533 | Written request for registration of change of name |
Free format text: JAPANESE INTERMEDIATE CODE: R313533 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091027 Year of fee payment: 3 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101027 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101027 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111027 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111027 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121027 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121027 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131027 Year of fee payment: 7 |
|
| LAPS | Cancellation because of no payment of annual fees |